Федеральное Агентство Связи

Ордена Трудового Красного Знамени федеральное государственное

бюджетное образовательное учреждение высшего образования
«Московский технический университет связи и информатики»

Центр заочного обучения по программам бакалавриата

Кафедра «Интеллектуальные системы в управлении и автоматизации»

Дисциплина: Технологии баз данных

Курсовая работа
Разработка БД для АСУ «Кинотеатр»

Выполнил: Иванов Иван,

студент группы БСТ17xx
Тема №48

Проверил:

Москва, 2020
Оглавление
ВВЕДЕНИЕ..................................................................................................................................................3
ГЛАВА 1. СИСТЕМНЫЙ АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ АСУ «Кинотеатр».........................4
1.1. Анализ объекта автоматизации «Киноман»..............................................................................4
1.2. Обзор информационных технологий, подходящих для разработки БД.................................6
1.3. Обзор продуктов аналогов..........................................................................................................9
1.4. Требования к разрабатываемой базе данных..........................................................................11
1.5. Выводы.......................................................................................................................................11
ГЛАВА 2. ПРОЕКТИРВОАНИЕ БАЗЫ ДАННЫХ ДЛЯ ОБЪЕКТА АВТОМАТИЗАЦИИ СЕТИ
КИНОТЕАТРОВ «КИНОМАН»..............................................................................................................12
2.1. Разработка инфологической модели БД..................................................................................12
2.2. Обоснование выбора модели данных......................................................................................13
2.3. Даталогическое проектирование БД........................................................................................14
2.4. Выводы.......................................................................................................................................18
ГЛАВА 3. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ БД СЕТИ КИНОТЕАТРОВ «КИНОМАН»...............19
3.1. Анализ и выбор СУБД...............................................................................................................19
3.2. Физическое проектирование БД...............................................................................................20
3.3. Разработка представлений........................................................................................................22
3.4. Разработка форм........................................................................................................................24
3.5. Разработка отчетов....................................................................................................................26
3.6. Безопасность и контроль...........................................................................................................27
3.7. Выводы.......................................................................................................................................30
ЗАКЛЮЧЕНИЕ..........................................................................................................................................31
СПИСОК ИСТОЧНИКОВ И ЛИТЕРАТУРЫ.........................................................................................32

2
 ВВЕДЕНИЕ

Использование баз данных и информационных систем становится

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

Задачи курсового проекта:

 провести системный анализ предметной области сети
кинотеатров «Киноман»;
 провести обзор информационных технологий, подходящих для
разработки;
 изучить аналогичные информационные системы данной
предметной области;
 описать требования, предъявляемы е к разработке данной базы
данных;
 разработать инфологическую модель базы данных;
 обосновать выбор модели данных и осуществить логическое
проектирование базы данных;
 нормализовать спроектированную модель и составить схему базы
данных;
 осуществить реализацию БД на выбранной СУБД;

Данная тема актуальна, так как большое количество людей

заинтересовано в просмотре шедевров современного кинематографа «на
больших экранах».
Данная задача будет решаться с помощью анализа предметной области,
ее формализации с помощью функциональных зависимостей. Затем
необходимо провести этапы минимизации системы функциональных
зависимостей, описывающих предметную область, и на основании
полученной редуцированной системы спроектировать требуемую модель
базы данных [1].
3
 ГЛАВА 1. СИСТЕМНЫЙ АНАЛИЗ ПРЕДМЕТНОЙ
ОБЛАСТИ АСУ «Кинотеатр»

Кинотеатр должен предоставлять клиентам быстрый и удобный способ

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

1.1. Анализ объекта автоматизации «Киноман»

Предметом курсового проекта является сеть кинотеатров «Киноман»,

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

Рисунок 1 - Организационная структура

Руководитель производит общее руководство по организации

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

Кассир занимается продажей билетов на кассе, информация о продаже

вносится в БД.

Администратор контролирует работу кассиров, а так занимается

распределением сеансов на каждый день.

Посетитель кинотеатра проходит на кассу, где выбирает желаемый

фильм и сеанс на него. При желании посетитель может предъявить
клиентскую карту.

В кинотеатре ведется учет всех сотрудников, клиентов с бонусной

картой, фильмов, сеансов и их посещений.
4
Сотрудник кинотеатра имеет следующую информацию:
 ФИО
 Дата рождения
 Паспортные данные
 Телефон
 Адрес
 Дата приема на работу

Информация о клиенте:
 ID клиента (создается автоматически)
 ФИО
 Номер карты (при наличии)

Информация по бонусной карте:

 Номер карты
 Телефон
 Дата рождения

Информация о фильме:
 Название фильма
 Дата премьеры
 Страна производства

Информация о сеансах:
 Название фильма
 Время сеанса
 Формат 2D/3D

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

Информация о посещении сеанса:

 ID клиента
 Фильм
 Выбранный сеанс
 Сумма
 Сотрудник, оформивший покупку билета
 Дата транзакции

5
 1.2. Обзор информационных технологий, подходящих для разработки
БД

СУБД — комплекс программ, позволяющих создать базу данных (БД)

и манипулировать данными (вставлять, обновлять, удалять и выбирать).
Система обеспечивает безопасность, надёжность хранения и
целостность данных, а также предоставляет средства для администрирования
БД.

Классификация СУБД:

● Иерархические
● Сетевые
● Реляционные
● Объектно-ориентированные
● Объектно-реляционные

Современная СУБД содержит следующие компоненты:

Ядро, которое отвечает за управление данными во внешней и

оперативной памяти и журнализацию.

Процессор языка БД, обеспечивает оптимизацию запросов на

извлечение и изменение данных и создание, как правило, машинно-
независимого исполняемого внутреннего кода.

Подсистему поддержки времени исполнения, которая интерпретирует

программы манипуляции данными, создающие пользовательский интерфейс
с СУБД.

Сервисные программы (внешние утилиты), обеспечивающие ряд

дополнительных возможностей по обслуживанию информационной системы.

СУБД можно условно разделить на следующие классы:

домашние (настольные) СУБД – подходят для использования в

домашних условиях и создания небольших баз данных;

полупрофессиональные СУБД – в основном используются

предприятиями малого бизнеса для проектирования баз данных обычных
размеров;

профессиональные СУБД – пригодны для использования в любых

бизнес-предприятиях и крупных корпорациях, служат для создания баз
данных любых размеров.
6
 Примеры СУБД:

Microsoft Office Access — реляционная СУБД корпорации Microsoft.

Имеет широкий спектр функций, включая связанные запросы, связь с
внешними таблицами и базами данных. Благодаря встроенному языку VBA, в
самом Access можно писать приложения, работающие с базами данных.
Основные компоненты MS Access: построитель таблиц;
построитель экранных форм;

построитель SQL-запросов (язык SQL в MS Access не соответствует

стандарту ANSI);
построитель отчётов, выводимых на печать.

Они могут вызывать скрипты на языке VBA, поэтому MS Access

позволяет разрабатывать приложения и БД практически «с нуля» или
написать оболочку для внешней БД.

Microsoft Jet Database Engine, которая используется в качестве движка

базы данных MS Access является файл-серверной СУБД и потому применима
лишь к приложениям, работающим с небольшими объёмами данных и при
небольшом числе пользователей, одновременно работающих с этим
данными. Непосредственно в Access отсутствует ряд механизмов,
необходимых в многопользовательских БД, таких, например, как триггеры
[2].

Встроенные средства взаимодействия MS Access со внешними СУБД с

использованием интерфейса ODBC снимают ограничения, присущие
Microsoft Jet Database Engine. Инструменты MS Access, которые позволяют
реализовать такое взаимодействие называются «связанные таблицы» (связь с
таблицей СУБД) и «запросы к серверу» (запрос на диалектеSQL, который
«понимает» СУБД) [3].

Корпорация Microsoft для построения полноценных клиент-серверных

приложений на базе MS Access рекомендует использовать в качестве движка
базы данных СУБД MS SQL Server. При этом имеется возможность
совместить с присущей MS Access простотой инструменты для управления
БД и средства разработки.

Известны также реализации клиент-серверных приложений на базе

связки Access 2003 c другими СУБД, в частности, MySQL.

MySQL является собственностью компании Sun Microsystems,

осуществляющей разработку и поддержку приложения. Распространяется
под GNU General Public License и под собственной коммерческой лицензией,
7
на выбор. Помимо этого, компания MySQL AB разрабатывает
функциональность по заказу лицензионных пользователей, именно

благодаря такому заказу почти в самых ранних версиях появился

механизм репликации.

MySQL является решением для малых и средних приложений. Входит

в LAMP. Обычно MySQL используется в качестве сервера, к которому
обращаются локальные или удалённые клиенты, однако в дистрибутив
входит библиотека внутреннего сервера, позволяющая включать MySQL в
автономные программы.

Гибкость СУБД MySQL обеспечивается поддержкой большого

количества типов таблиц: пользователи могут выбрать как таблицы типа
MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB,
поддерживающие транзакции на уровне отдельных записей. Более того,
СУБД MySQL поставляется со специальным типом таблиц EXAMPLE,
демонстрирующим принципы создания новых типов таблиц. Благодаря
открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно
появляются новые типы таблиц [4].

MySQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl,
PHP, Python, Ruby, Smalltalk и Tcl, библиотеки для языков платформы
.NET, а также обеспечивает поддержку для ODBC посредством
ODBC-драйвера MyODBC.

Oracle Database - первая в мире база данных, разработанная

специально для работы в сетях распределенных вычислений. Oracle Database
предназначена для эффективного развертывания на базе различных типов
оборудования, от небольших серверов до Oracle Enterprise Grid мощных
многопроцессорных серверных систем, от отдельных кластеров до
корпоративных распределенных вычислительных систем.

Oracle Database позволяет пользователям виртуализировать

использование аппаратного обеспечения - серверов и систем хранения
данных. Oracle Database обладает технологиями, которые позволяют
администраторам надежно хранить и быстро распределять и извлекать
данные для пользователей и приложений, работающих в сетях Grid. Oracle
Database значительно повышает производительность обработки данных и
включает в себя удобные средства администрирования [5].

Oracle Database предоставляет возможность автоматической настройки

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

Некоторые ключевые возможности Oracle Database:

Real Application Cluster (RAC) обеспечивает работу одного экземпляра

базы данных на нескольких узлах grid, позволяя управлять нагрузкой и гибко
масштабировать систему в случае необходимости.

Automatic Storage Management (ASM) позволяет автоматически

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

Производительность. Oracle Database позволяет автоматически

управлять уровнями сервиса и тиражировать эталонные конфигурации в
рамках всей сети.

Простые средства разработки. Новый инструмент разработки

приложений HTML DB позволит простым пользователям создавать
эффективные приложения для работы с базами данных в короткие сроки.

Самоуправление. Специальные механизмы Oracle Database позволяют

самостоятельно перераспределять нагрузку на систему, оптимизировать и
корректировать SQL-запросы, выявлять и прогнозировать ошибки.

Большие базы данных. Теперь максимальный размер экземпляра базы

данных Oracle может достигать 8 экзабайт [6].

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

В настоящее время на рынке информационных систем

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

9
 Для обеспечения конкурентоспособности требуется ознакомится с
возможностями конкурентов, узнать их слабые и сильные стороны.

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

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

кинотеатром.

Рисунок 3 - CARBIS

CARBIS - комплекс программ для управления кинотеатром

официального дилера UCS.

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

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

 Кассир
 Администратор
При работе с БД кассир может выполнять следующие задачи:
 добавлять клиентов (регистрировать их в бонусной программе)
 вносить изменения в личные данные клиентов
 редактировать или добавлять информацию о посещениях

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

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

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

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

1.5. Выводы

В главе проведен системный анализ предметной области, который

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

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

В данной главе разработаем инфологическую модель базы данных

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

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

Целью инфологического проектирования является создание

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

При проектировании на инфологическом уровне создается

информационно-логическая модель, которая должна отвечать следующим
требованиям:

 обеспечение наиболее естественных для человека способов сбора

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

На основе проведенного системного анализа предметной области

выделены следующие сущности:

1. Сотрудник: содержит информацию о сотрудниках

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

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

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

Под даталогической моделью понимается модель, отражающая

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

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

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

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

Для логического проектирования выбрана реляционная модель данных,

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

 отсутствие дублирующей информации;

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

В реляционной базе данных даталогическое проектирование приводит

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

В реляционных базах данных (РБД) даталогическое проектирование

приводит к разработке схемы БД, т.е. совокупности схем отношений,
адекватно моделирующих объекты ПО и семантических связей между ними.

Основой анализа корректности схемы являются функциональные

зависимости между атрибутами БД. Некоторые могут быть нежелательными
[9].

В конце этого этапа должно быть получено описание схемы БД в

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

Процесс разработки корректной схемы РБД и является даталогическим

проектированием. Возможны 2-а способа:

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

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

специальный алгоритм:

1. Каждой сущности ставится в соответствие отношение;

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

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

инфологической модели:

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

Клиент
 Код клиента - int NOT NULL PK
 ФИО - varchar(40) NOT NULL
 Номер карты - int NULL FK

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

15
 Фильм
 Код фильма - int NOT NULL PK
 Название фильма - varchar(40) NOT NULL
 Дата премьеры - date NOT NULL
 Страна производства - varchar(40) NOT NULL

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

Расценки
 Стоимость билета - int NOT NULL

Посещение
 Код посещения - int NOT NULL PK
 Код клиента - int NOT NULL FK
 Код фильма - int NOT NULL FK
 Код сеанса - int NOT NULL FK
 Сумма - int NOT NULL
 Код сотрудника - int NOT NULL FK
 Дата транзакции - date NOT NULL

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

получившейся БД:

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

17
 1.9. Выводы

Во второй главе курсовой работы приведена разработка

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

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

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

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

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

Oracle Datebase поддерживает самые большие базы данных. Большое

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

СУБД Oracle хорошо обрабатывает транзакции. Система сохраняет

высокую производительность, в результате чего пользователи не страдают от
низкой скорости обработки.

Система обладает высокой степенью готовности. В разных установках,

продолжительность работы Oracle индивидуальная. Так, например, в
некоторых, система способна работать круглосуточно. При этом откат БД
или какие-либо сбои системы не приводят к остановке работы базы.

Эта система обладает локальной управляемостью. Например, чтобы

перезагрузить данные какого-то определенного приложения, не обязательно
отключать всю систему. Администратору достаточно выключить доступ к
нужному приложению и выполнить с ним требуемые манипуляции.

Данная СУБД легко переносится с одной ОС на другую. Приложения,

которые были разработаны специально для Oracle, легко переносятся на
любую операционную систему с минимальными изменениями, а иногда даже
без них [11].

19
1.11. Физическое проектирование БД

Рисунок 6 - Таблица EMPLOYEE (Сотрудник)

Рисунок 7 – MOVIE (Фильм)

Рисунок 8 - Таблица SESSIONS (Сеансы)

20
Рисунок 9 - Таблица PRICES (Расценки)

Рисунок 10 - Таблица CLIENT (Клиент)

Рисунок 11 - Таблица CARD (Карта)

21
 Рисунок 12 - Таблица VISIT (Посещение)

1.12. Разработка представлений

Создадим несколько представлений, которые в дальнейшем будут

использоваться при разработке отчетов.
Первое представление показывает информацию о фильмах,
производства США.

Рисунок 13 - Представление MOVIES_USA (SQL код)

Рисунок 14 - Представление MOVIES_USA (Результат)

22
 Второе представление показывает информацию о сеансах в формате 3D
17 октября 2020 года.

Рисунок 15 - Представление SESSION_3D_17OCT2020 (SQL код)

Рисунок 16 - Представление SESSION_3D_17OCT2020 (Результат)

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

с итоговой стоимостью выше 300 рублей.

Рисунок 17 - Представление VISIT_300MORE (SQL код)

Рисунок 18 - Представление VISIT_300MORE (Результат)

23
 1.13. Разработка форм

При помощи “Oracle Application Express” Application Builder создаем

приложение, в котором предусмотрено меню и страницы с информацией по
нашей БД. Для взаимодействия с данными в БД используются формы.

Рисунок 19 - Интерфейс разрабатываемого приложения

Рисунок 20 - Интерфейс разрабатываемого приложения

24
Рисунок 21 - Интерфейс разрабатываемого приложения

Рисунок 22 - Интерфейс разрабатываемого приложения

25
 Рисунок 23 - Интерфейс разрабатываемого приложения

1.14. Разработка отчетов

Создадим отчеты, используя ранее созданные представления.

Рисунок 24 - Пример отображения отчета в приложении

Рисунок 25 - Пример отображения отчета в приложении

26
 1.15. Безопасность и контроль

Средства безопасности в Oracle можно разделить на две категории:

 Безопасность доступа.
 Безопасность данных.

Безопасность доступа:
В Oracle имеется целый ряд механизмов для идентификации и
верификации пользователей. Самый простой из них – обязательное указание
пользователем своих имени и пароля при каждом подключении. Эта
верификация должна выполняться независимо от того, какое внешнее
интерфейсное средство используется для доступа к базе данных. Идея
состоит в том, чтобы допустить пользователей к работе со средствами базы
данных только после того, как он установит санкционированное соединение
с ней. Имя пользователя и пароль сверяются с указанными в таблице
SYS.USERS, куда пароль заносится в зашифрованной форме.
В большинстве приложений баз данных существуют разные категории
пользователей, которые работают с разными частями системы и имеют
разные права на просмотр и изменение данных. В простом случае может
быть всего два класса пользователей: те, кто вводит данные, и менеджеры,
выполняющие запросы к данным. Но в большинстве случаев существует
несколько категорий пользователей, и функциональные возможности, к
которым они должны иметь доступ, пересекаются. В таких ситуациях можно
избежать дублирования работы, создав одно приложение с меню или
панелью инструментов, вид и содержимое которой зависят от задач
конкретного пользователя.

Безопасность данных:
Если подключаться к базе данных могут лишь уполномоченные
пользователи, и они могут запускать только те модули, на выполнение
которых им явно предоставлено право, то нужно подумать о следующем
уровне безопасности – ограничении доступа этих пользователей к данным.
Для добавления пользователя в базу данных администратор базы
данных создает учетную запись с именем пользователя и паролем. Каждому
пользователю присваивается профиль — характеристика предельных
объемов системных ресурсов, которые могут быть выделены данному
пользователю. Сюда входит лимит совокупного процессорного времени,
предоставляемого в течение одного сеанса или за один вызов Oracle, и другие
подобные ограничения.
В Oracle имеются системные и объектные привилегии. Системные
привилегии — это права на выполнение общих задач, таких как SELECT
ANY TABLE и UPDATE ANY TABLE. Объектные привилегии относятся к
действиям с определенными элементами базы данных — таблицами,
27
представлениями и последовательностями. Для предоставления привилегий
другому пользователю можно использовать оператор GRANT [12].

У нас в приложение “Oracle Application Express” реализована

авторизация пользователей с помощью Authorization Schemes. Было создано
несколько схем авторизации. Первое, что нам нужно сделать - это понять,
какие уровни авторизации нужно будет реализовать в нашем приложении,
потому что это определит не только роли, которые мы создаем в общем
компоненте контроля доступа к приложениям, но также будет определять,
какие схемы авторизации мы определяем и могут применяться к различным
компонентам Application Express [13].

Мы будем использовать 2 разных уровня авторизации:

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

У администратора будет доступ ко всему. У кассира есть доступ ко

всем страницам кроме страницы Employee.

Рисунок 26 - Таблица Users

Сами по себе роли контроля доступа, по сути, ничего не делают, но

предоставляют возможность связать пользователя с ролью. Это связанные
схемы авторизации, которые обеспечивают логику, которая позволяет нам
связать роль с данным компонентом в Application Express. Далее создаются
схемы авторизации [14].

Для каждого пользователя используется свои привилегии пользования

над базой данных.

28
Рисунок 27 - Привелегии для ADMIN

Рисунок 28 - Привелегии для CASSIR

29
 1.16. Выводы

В первой главе проведен системный анализ предметной области

объекта автоматизации «Киноман», в ходе которого перечислены должности
работников и их функции.
В ходе обзора информационных технологий перечислены классы
СУБД, приведены примеры для каждого класса (Microsoft Access, MySQL,
Oracle Database).
Рассмотрены продукты-аналоги на рынке информационных систем и
даны описания данных систем.
Указаны требования к разрабатываемой базе данных со стороны
каждой из групп пользователей и перечислены выполняемые этими
пользователями задачи относительно базы данных. Также описаны
ограничения на разрабатываемую БД.
Во второй главе курсовой работы приведена разработка
информационно-логической модели. Выделены сущности, дано их описание
и построена инфологическая модель предметной области.
Далее в ходе обоснования выбора модели данных описаны
существующие модели данных (иерархическая, сетевая, реляционная,
объектно-ориентированная).
Затем на основании инфологической модели построена реляционная
модель данных, дан список атрибутов ее отношений и проведена
нормализация до третьей нормальной формы. Таким образом, завершено
проектирование базы данных и получена вся информация, необходимая для
реализации проектируемой информационной системы в одной из
реляционных СУБД.
В 3 главе произведено физическое проектирование базы данных
кинотеатра. Создано два триггера. Определены ограничения. Произведен
анализ безопасности в СУБД Oracle.

30
 ЗАКЛЮЧЕНИЕ

Курсовая работа посвящена разработке базы данных кинотеатра

“Киноман”. В процессе выполнения курсовой работы был произведен
системный анализ предметной области, были разработаны инфологическая и
даталогическая модель БД, а также была произведена программная
реализация базы данных и приложения в Oracle Application Express.

31
 СПИСОК ИСТОЧНИКОВ И ЛИТЕРАТУРЫ

1. Воронова Л.И. «Лабораторный практикум по дисциплине “базы

данных”» - Москва 2010г.
2. ГОСТ 2.105-95 Единая система конструкторской документации.
3. Общие требования к текстовым документам
4. Л.И. Воронова "Учебно-методическое пособие по подготовке и
оформлению курсовых проектов", Москва 2014
5. Карпова Т.С. «Базы Данных» - Питер, 2002г.
6. Крёнке Д. «Теория и практика построения баз данных» - Питер,
2003г.
7. Дэвидсон, Луис проектирование баз данных на SQL Server 2000;
Бином, 2009.
8. Вендров, А.М. CASE-технологии. Современные методы и
средства проектирования информационных систем [Электронный
ресурс] /А.М. Вендров. – Режим доступа:
http://casetech.h1.ru/library/vendrov/index.htm.
9. Дейт, К.Дж. Введение в системы баз данных [Текст] / К.Дж.
Дейт; пер. с англ. – 6-е изд. – Киев; М.; СПб.: Издательский дом
«Вильямс», 1999. – 848 с.
10.. Хомоненко, А.Д. Базы данных: учебник для высших учебных
заведений [Текст] / А.Д. Хомоненко, В.М. Цыганов, М.Г.
Мальцев; под ред. проф. А.Д. Хомоненко. – изд. 2-е, доп. и
перераб. – СПб.: КОРОНА принт, 2002. – 672 с.
11.Коннолли, Т. Базы данных: проектирование, реализация и
сопровождение. Теория и практика [Текст] / Т. Коннолли, К.
Бегг, А. Страчан; пер. с англ. – 2-е изд. – М.: Издательский дом
«Вильямс», 2000. – 1120 с.
12.Чен, П.П-Ш. Модель «сущность – связь» – шаг к единому
представлению о данных [Электронный ресурс] / П.П-Ш. Чен;
пер. М.Р. Когаловской. – Режим доступа:
http://citforum.ru/database/classics/chen/.
13.Смит, Д.М. Абстракции баз данных: агрегация и обобщение
[Электронный ресурс] / Д.М. Смит, Д.К. Смит, пер. М.Р.
Когаловской. – Режим доступа:
http://citforum.ru/database/classics/abstraction_generalization/.
14.Грошев, А.С. Использование методологии IDEF1X для
разработки концептуальной модели данных [Электронный
ресурс] / А.С. Грошев. Основы работы с базами данных: курс
лекций. – Режим доступа:
http://www.intuit.ru/department/database/basedbw/3/.

32