Файл: Курсовая работа по теме Предметная область Кинотеатр.docx

Большие базы данных. Теперь максимальный размер экземпляра базы данных Oracle может достигать 8 экзабайт [6].

3. Обзор продуктов аналогов

В настоящее время на рынке информационных систем позиционируются продукты, имеющие аналогичные с разрабатываемой ИС цели объекты автоматизации.
Для обеспечения конкурентоспособности требуется ознакомится с возможностями конкурентов, узнать их слабые и сильные стороны.



Рисунок 2 - TS:Кинотеатр (SaaS)

TS:Кинотеатр (SaaS) – комплекс программ для управления кинотеатром.



Рисунок 3 - CARBIS

CARBIS - комплекс программ для управления кинотеатром официального дилера UCS.

4. Требования к разрабатываемой базе данных

С БД имеют возможность работать следующие группы пользователей:

• 
  Кассир
  
• 
  Администратор
  

При работе с БД кассир может выполнять следующие задачи:

• 
  добавлять клиентов (регистрировать их в бонусной программе)
  
• 
  вносить изменения в личные данные клиентов
  
• 
  редактировать или добавлять информацию опосещениях
  

При работе с БД администратор может выполнять следующие задачи:

• 
  просматривать любуюинформацию
  
• 
  вносить изменения в личные данные клиентов иработников
  
• 
  редактировать или добавлять информацию осеансах
  
• 
  просматривать информацию попосещениям сеансов
  

Для данной базы данных требуется предусмотреть следующие ограничения:

• 
  работники не моложе 18лет;
  
• 
  у каждого сотрудника должны быть обязательно заполнены все данные;
  
• 
  при заказе обязательно требуется заполнение поля ФИО посетителя.
  

5. Выводы

В главе проведен системный анализ предметной области, который включает в себя анализ объекта автоматизации, построение организационной диаграммы, описание бизнес-процессов, составление информационной модели. Также были рассмотрены технологии, которые будут применяться при разработке информационной системы, рассмотрены аналогичные готовые решения и сформулированы требования к разрабатываемой ИС.

---

ГЛАВА 2. ПРОЕКТИРВОАНИЕ БАЗЫ ДАННЫХ ДЛЯ ОБЪЕКТА АВТОМАТИЗАЦИИ СЕТИ КИНОТЕАТРОВ «КИНОМАН»

В данной главе разработаем инфологическую модель базы данных кинотеатра. Проанализируем существующие даталогические модели данных и обоснуем выбор реляционной модели. На основе построенной инфологической модели проведем логическое проектирование базы данных, опишем каждую сущность и построим реляционную модель базы данных кинотеатра.

1. 
   
   
2. 
   
   

6. Разработка инфологической модели БД

Целью инфологического проектирования является создание структурированной информационной модели предметной области, для которой будет разрабатываться база данных.
При проектировании на инфологическом уровне создается информационно-логическая модель, которая должна отвечать следующим требованиям:

• 
  обеспечение наиболее естественных для человека способов сбора и предоставления той информации, которую предполагается хранить в создаваемой базе данных;
  
• 
  корректность схемы БД (Адекватное отображение моделированной ПО);
  
• 
  простота и удобство использования на следующих этапах проектирования, то есть информационно-логическая модель может легко отображаться на модели базы данных, которые поддерживаются известным СУБД (Сетевые, иерархические, реляционные и др.);
  
• 
  информационно-логическая модель должна быть описана языком, понятным проектировщикам баз данных, программистам, администратору и будущим пользователям [7].
  

На основе проведенного системного анализа предметной области выделены следующие сущности:

1. 
   Сотрудник: содержит информацию о сотрудниках
   
2. 
   Клиент: содержит информацию о посетителях кинотеатра
   
3. 
   Карта: содержит информацию о зарегистрированных клиентах
   
4. 
   Фильм: содержит информацию о фильмах
   
5. 
   Сеанс: содержит информацию сеанс
   
6. 
   Расценки: содержит информацию о ценах на сеансы
   
7. 
   Посещения: содержит информацию о посещениях
   

Рисунок 4 - Инфологическая модель предметной области

7. Обоснование выбора модели данных

Под даталогической моделью понимается модель, отражающая логические взаимосвязи между элементами данных безотносительно их содержания и физические организации. При этом даталогическая (или просто логическая) модель строится на основе инфологической модели конкретной предметной области, с учётом её особенностей.

---

Существуют несколько типов даталогических моделей данных:

• 
  сетевая модель;
  
• 
  иерархическая модель;
  
• 
  объектно-ориентированная модель;
  
• 
  реляционная модель;
  

Необходимо выбрать один из приведенных выше типов и построить на основе инфологической модели, разработанной ранее, даталогическую модель данной ИС. Также необходимо выбрать СУБД, в которой, впоследствии, будет реализована данная БД, т.к. даталогическая модель строится в терминах выбранной СУБД [8].

8. Даталогическое проектирование БД

Для логического проектирования выбрана реляционная модель данных, т.к. она наиболее полно соответствует требованиям, предъявленным к разрабатываемой информационной системе:

• 
  отсутствие дублирующей информации;
  
• 
  поддержание целостности данных при вставке, удалении или изменении записей;
  
• 
  возможность организации всех видов связи между отношениями 1:1, 1:M и M:M.
  

В реляционной базе данных даталогическое проектирование приводит к разработке корректной схемы базы данных, т.е. такой схемы, в которой отсутствуют нежелательные зависимости между атрибутами. При этом можно использовать процесс проектирования с помощью декомпозиции, т.е. последовательно нормализовывать схему отношений, тем самым накладывая ограничения и избавляясь от нежелательных зависимостей между атрибутами.
В реляционных базах данных (РБД) даталогическое проектирование приводит к разработке схемы БД, т.е. совокупности схем отношений, адекватно моделирующих объекты ПО и семантических связей между ними.
Основой анализа корректности схемы являются функциональные зависимости между атрибутами БД. Некоторые могут быть нежелательными [9].
В конце этого этапа должно быть получено описание схемы БД в терминах выбранной СУБД. Целью даталогического проектирования является построение корректной схемы БД, ориентированную на реляционную модель. Корректной называется схема БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.
Процесс разработки корректной схемы РБД и является даталогическим проектированием. Возможны 2-а способа:

• 
  Декомпозиция (разбиение);
  
• 
  Синтез;
  

Для перехода от инфологической модели к реляционной существует специальный алгоритм:

1. 
   Каждой сущности ставится в соответствие отношение;
   
2. 
   Каждому атрибуту сущности ставится в соответствие соответствующий атрибут соответствующего отношения;
   
3. 
   Первичный ключ сущности становится PK соответствующего отношения, при этом атрибуты, входящие в PK, обязательны для заполнения (NOT NULL);
   
4. 
   В каждое отношение, соответствующее подчинённой сущности, добавляется набор атрибутов основной сущности, являющийся в ней первичным ключом. В отношении, соответствующее подчинённой сущности эти атрибуты становятся FK (внешним ключом);
   
5. 
   По умолчанию, все атрибуты, не входящие в PK, необязательны;
   
6. 
   Для отражения категоризации сущностей возможны несколько вариантов;
   
7. 
   Все связи М:М должны быть раскрыты [10];
   

---

Воспользуемся данным алгоритмом и опишем каждую сущность инфологической модели:
Сотрудник

• 
  Код сотрудника – int NOT NULL PK
  
• 
  ФИО - varchar(40) NOTNULL
  
• 
  Дата рождения - date NOTNULL
  
• 
  Паспортные данные - varchar(40) NOTNULL
  
• 
  Телефон - varchar(40) NOTNULL
  
• 
  Адрес - varchar(100) NOTNULL
  
• 
  Дата приема на работу- dateNOTNULL
  

Клиент

• 
  Кодклиента - int NOT NULL PK
  

• 
  ФИО - varchar(40) NOTNULL
  
• 
  Номер карты - int NULL FK
  

Карта

• 
  Номеркарты - int NOT NULL PK
  
• 
  Телефон - varchar(40) NOTNULL
  
• 
  Дата рождения - date NOTNULL
  

Фильм

• 
  Кодфильма - int NOT NULL PK
  

• 
  Название фильма - varchar(40) NOTNULL
  
• 
  Датапремьеры - date NOTNULL
  
• 
  Страна производства- varchar(40) NOTNULL
  

Сеанс

• 
  Кодсеанса - int NOT NULL PK
  

• 
  Кодфильма - int NOT NULL FK
  
• 
  Времясеанса - date NOTNULL
  
• 
  Формат 2D/3D - varchar(2) NOTNULL
  

Расценки

• 
  Стоимость билета - intNOTNULL
  

Посещение

• 
  Кодпосещения - int NOT NULLPK
  

• 
  Кодклиента- int NOT NULLFK
  
• 
  Кодфильма - int NOT NULL FK
  
• 
  Кодсеанса - int NOT NULL FK
  
• 
  Сумма - intNOTNULL
  
• 
  Код сотрудника - int NOT NULL FK
  
• 
  Дататранзакции - date NOTNULL
  

Исходя из приведенных выше отношений, построим схему получившейся БД:




Рисунок 5 - Схема реляционной БД "Кинотеатр" (в двух представлениях)

9. Выводы

Во второй главе курсовой работы приведена разработка информационно-логической модели. Выделены сущности, дано их описание и построена инфологическая модель предметной области.

Далее в ходе обоснования выбора модели данных описаны существующие модели данных (иерархическая, сетевая, реляционная, объектно-ориентированная), указаны их достоинства и недостатки, и сделан выбор в пользу реляционной модели.

Затем на основании инфологической модели построена реляционная модель данных, дан список атрибутов ее отношений. Таким образом, завершено проектирование базы данных и получена вся информация, необходимая для реализации проектируемой информационной системы в одной из реляционных СУБД.

ГЛАВА 3. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ БД СЕТИ КИНОТЕАТРОВ «КИНОМАН»

В главе рассматривается третий этап разработки базы данных, который включает в себя:

• 
  Выбор СУБД
  
• 
  Реализация базы данных в выбранной СУБД
  
• 
  Разработка форм, отчетов, представлений
  
• 
  Реализация ограничений
  

2. 
   
   

   1. Анализ и выбор СУБД

---

Oracle Datebase поддерживает самые большие базы данных. Большое количество пользователей для этой системы также не помеха. СУБД способна поддерживать любых пользователей, в любом количестве, которые при этом одновременно выполняют разные задачи. В Oracle не происходит соперничества между разными видами данных.
СУБД Oracle хорошо обрабатывает транзакции. Система сохраняет высокую производительность, в результате чего пользователи не страдают от низкой скорости обработки.
Система обладает высокой степенью готовности. В разных установках, продолжительность работы Oracle индивидуальная. Так, например, в некоторых, система способна работать круглосуточно. При этом откат БД или какие-либо сбои системы не приводят к остановке рабоÑ

---