Автоматизированное место сотрудника кинотеатра

Концептуальная модель данных – это наглядная диаграмма, нарисованная в принятых обозначениях и подробно показывающая связь между объектами и их характеристиками. Создается концептуальная модель для дальнейшего проектирования базы данных и перевод ее, например, в реляционную базу данных. На концептуальной модели в визуально удобном виде прописываются связи между объектами данных и их характеристиками[6].
Концептуальная модель данных состоит из следующих элементов:
– сущностей, которым соответствуют объекты предметной области;
– атрибутов сущностей, которым соответствуют свойства объектов предметной области;
– связей между сущностями.
На основании анализа предметной области были определены следующие сущности:
– фильм;
– сеанс;
– тип фильма;
– ограничения фильма;
– страна фильма;
– зал.
Свойствами сущности «фильм» были определены:
– наименование;
– описание;
– страна;
– тип фильма;
– ограничения фильма.
Свойствами сущности «сеанс» были определены:
– номер сеанса;
– наименование фильма;
– дата сеанса;
– время сеанса;
– зал;
– количество проданных мест.
Свойствами сущности «тип фильма» были определены:
– номер;
– наименование.
Свойствами сущности «ограничения фильма» были определены:
– номер;
– наименованиею
Свойствами сущности «страна фильма» были определены:
– номер;
– наименование.
Свойствами сущности «зал» были определены:
– номер;
– наименование.
Выделяют четыре вида связей:
– «один-к-одному»;
– «один-ко-многим»;
«многие-к-одному»;
«многие-ко-многим».
Связь «один-к-одному» образуется в том случае, когда все поля основной таблицы являются ключевыми полями подчиненной. При этой связи таблицы являются равноправными. Связь «один-ко-многим» применяется, когда одной записи основной таблицы соответствует несколько записей другой. Связь «многие-к-одному» – разновидность связи «один-ко-многим», только в другом направлении. Связь «многие-ко-многим» используется, когда нескольким записям одной соответствует несколько записей другой.
Для корректной работы базы данных на стадии проектирования необходимо добиться того состояния, когда все связи имеют вид «один-ко-многим» или «многие-к-одному».
Но на этапе концептуального проектирования допускается использование других видов связей при условии, что на последующих этапах проектирования они будут приведены к корректному виду.
Далее необходимо определить тип базы данных. Для уже определенной нами архитектуры проекта и поставленным требованиям к нему подходит тип реляционной базы данных.
На основании выбранного типа и концептуальной модели данных проведем логическое проектирование базы данных.
Логическое проектирование базы данных представляет собой процесс конструирования модели информационной структуры организации, выполняемый в соответствии с выбранной схемой организации информации[7].
Теперь необходимо произвести следующие преобразования концептуальной модели данных:
– перевести все сущности в соответствующие таблицы;
– перевести все атрибуты сущностей в соответствующие поля таблиц;
– произвести преобразования связей, исключая все кроме «один-ко-многим»;
– определить уникальные поля для каждой таблицы с ограничением первичного ключа;
– в каждой связи перенести первичный ключ родительской таблицы в дочернюю таблицу.
Далее проведем нормализацию данных.
Процесс преобразования базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация позволяет обезопасить базу данных от логических и структурных проблем, называемых аномалиями данных[8].
Отношение находится в первой нормальной форме, если все атрибуты являются простыми – имеют единственное значение и не содержат повторяющихся полей, то есть каждое значение любого атрибута должно быть неделимо на более мелкие поля[8].
Понятие второй нормальной формы основано на понятии первичного ключа. Так как первичный ключ – набор полей, которые могут идентифицировать запись, то может быть ситуация, что в одной таблице окажется несколько таких наборов полей. В этом случае любой выбранный их этих наборов будет являться первичным, а остальные будут альтернативными. Отношения находятся во второй нормальной форме, если они находятся в первой нормальной форме, при этом каждый не ключевой атрибут функционально полно зависит от первичного ключа. Следовательно, если такой зависимости нет, то следует выносить такие не ключевые атрибуты в отдельную таблицу[8].
Таблица находится в третьей нормальной форме, если таблица находится во второй нормальной форме и любой её не ключевой атрибут функционально зависит только от первичного ключа. Проще говоря, третье правило требует выносить все не ключевые поля, содержимое которых может относиться к нескольким записям таблицы в отдельные таблицы. Также по третьему правилу необходимо убедиться, что логическая связь “один-ко-многим” не может на практике интерпретироваться как “многие-ко-многим”, когда в обратном порядке одному значению атрибута не соответствует несколько значений атрибута первой сущности[8].
В нашем случае модель данных уже соответствует требованиям всех трех нормальных форм.
Далее произведем физическое проектирование путем выполнения следующих действий:
– определения вида СУБД;
– определение типов данных и ограничений для всех полей.
На основании определенного типа, архитектуры проекта и требований к нему была определена СУБД «Microsoft Access».
Теперь в соответствии с имеющимися в «Microsoft Access» типами данных определим типы данных для полей и их ограничения.
Ограничениями являются:
– длина поля;
– обязательность поля.
Физическая модель данных представлена на рисунке 5.