- •База данных
- •Введение
- •1.2 Выбор и описание автоматизируемых функций
- •1.3 Первичное описание информационного обеспечения
- •1.4 Вывод
- •2 Выявление ограничений и правил поддержания целостности
- •2.1 Уровень атрибутов
- •2.2.1 Функция 1 “Продажа билетов”.
- •2.2.2 Функция 2 “Возврат билетов”.
- •2.2.3 Функция 3 “Бронирование билетов”.
- •2.2.4 Функция 4 “Заказ транспортных средств”.
- •2.2.5 Функция 5 “Учет кадров”.
- •2.3 Уровень множеств кортежей
- •2.3.1 Функция 1 “Продажа билетов”.
- •2.3.2 Функция 2 “Возврат билетов”.
- •2.3.3. Функция 3 “Бронирование билетов”.
- •2.3.4 Функция 4 “Заказ транспортных средств”.
- •2.3.5 Функция 5 “Учет кадров”.
- •2.4 Уровень базы данных
- •2.4.1 Функция 1 “Продажа билетов”.
- •2.4.2 Функция 2 “Возврат билетов”.
- •2.4.3 Функция 3 “Бронирование билетов”.
- •2.4.4 Функция 4 “Заказ транспортных средств”.
- •2.4.5 Функция 5 “Учет кадров”.
- •2.5 Вывод
- •3.1.2 Функция 2 “Возврат билетов”
- •3.1.4 Функция 4 “Заказ транспортных средств”
- •3.1.5 Функция 5 “Учет кадров”
- •3.2.1 Функция 1 “Продажа билетов”
- •3.2.2 Функция 2 “Возврат билетов”
- •3.2.3 Функция 3 “Бронирование билетов”
- •3.2.4 Функция 4 “Заказ транспортных средств”
- •3.2.5 Функция 5 “Учет кадров”
- •3.3 Спецификация ограничений и правил поддержания целостности
- •5.2 Спецификация ограничений и правил поддержания целостности
- •5.3 Sql-код для создания реляционной модели
- •5.4 Вывод
- •6.2 Sql-код локальных просмотров для автоматизируемых функций
3.3 Спецификация ограничений и правил поддержания целостности
В данном подразделе ограничения и правила поддержания целостности, сформулированные в разд. 2 в описательной форме, трансформируются применительно к локальным ER-моделям. Анализируется необходимость дополнительных ограничений и правил, не учтенных ранее.
Ограничения доменов для атрибутов остались неизменными и здесь не затрагиваются. Ограничения обязательности значений атрибутов в кортежах сущностей отражены на диаграммах моделей в подразделе 3.2 (затемненные кружки).
Дополнительные ограничения и правила, не учтенные ранее не обнаружены.
В результате анализа информационного обеспечения функций выявлены и сформулированы ограничения и правила поддержания целостности данных, которые должны быть учтены при дальнейшем проектировании.
3.4 Вывод
В результате проектирования локальных ER-моделей, соответствующих отдельным автоматизируемым функциям, получены нормализованные локальных ER-модели, включающие от 5 до 9 сущностей в третьей нормальной форме. Разработанные спецификации ограничений и правил поддержания целостности включают все ограничения и правила, полученные на предыдущем этапе и трансформированные для локальных ER-моделей.
4 ПРОЕКТИРОВАНИЕ ГЛОБАЛЬНОЙ ER-МОДЕЛИ
Данный раздел посвящен проектированию глобальной ER-модели. Здесь производится выявление эквивалентных сущностей и их слияние, выявление категорий и синтез обобщающих сущностей, выявление и устранение дублирования атрибутов и связей. Строится графическое представление глобальной модели, специфицируются ограничения и правила поддержания целостности на уровне глобальной модели.
4.1 Выявление и устранение эквивалентных сущностей
В данном подразделе были выявлены и устранены следующие эквивалентные сущности: “Касса”, “Кассир”, “Пассажир”, “Билет”, “Пункт” и “Телефон”.
4.2 Выявление категорий и синтез обобщающих сущностей
В данном подразделе выявлена категория “Персона”, которая, в свою очередь, состоит из категории “Сотрудник” и двух сущностей: “Пассажир” и “Приемщик заказа”. Категория “Сотрудник” состоит из сущностей “Кассир” и “Администратор”.
4.3 Выявление и устранение дублирования атрибутов и связей
В данном подразделе выявлены и устранены несколько дублирующихся атрибутов, в частности, некоторые атрибуты сущностей “Пассажир”, “Сотрудник”, “Кассир”, “Администратор” и “Приемщик заказа”.
4.4 Графическое представление глобальной ER-модели
В данном подразделе, в результате выявления эквивалентных сущностей и их слияния, выявления категорий и синтеза обобщающих сущностей, выявления и устранения дублирования атрибутов, была построена глобальная ER – модель, представленная на рисунке 4.
4.5 Спецификация ограничений и правил поддержания целостности
В данном подразделе новые спецификации ограничений и правила поддержания целостности не выявлены.
4.6 Вывод
На данном этапе быласпроектирована глобальная ER-модель, соответствующая разрабатываемой информационной автоматизированной системе “Продажа автобусных билетов”, которая отражает деятельность автовокзала.
5 ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ SQL-МОДЕЛИ
Данный раздел посвящен проектированию реляционной SQL-модели. Здесь выполняется перевод глобальной ER-модели в реляционную форму, специфицируются ограничения и правила поддержания целостности на реляционном уровне, записывается SQL-код для создания реляционной модели.
5.1 Перевод глобальной ER-модели в реляционную форму
В данном подразделе для перевода глобальной ER – модели в реляционную форму сделано следующее:
избавление от связи “многие ко многим” путем превращения связи “Карьера” в сущность;
избавление от всех связей путем добавления первичных ключей в качестве внешних в соответствующие сущности;
разбиение катагории “Персона” на 3 сущности.
В разработанной реляционной форме глобальной модели используется 21 таблица:
“Персона_пассажир” с полями: документ_серия (первичный ключ), документ_вид документа, ФИО_фамилия, ФИО_имя, ФИО_отчество, адрес, номер телефона (внешний ключ);
“Продажа” с полями: документ_серия пассажира (внешний ключ), код кассира (внешний ключ), номер билета (внешний ключ);
“Возврат” с полями: документ_серия пассажира (внешний ключ), код кассира (внешний ключ), номер билета (внешний ключ);
“Бронирование” с полями: номер брони (первичный ключ), срок выкупа, документ_серия пассажира (внешний ключ), код кассира (внешний ключ), номер билета (внешний ключ);
“Телефон” с полями: номер (первичный ключ), код, тип;
“Билет” с полями: номер билета (первичный ключ), номер места, цена, номер рейса (внешний ключ);
“Касса” с полями: номер кассы (первичный ключ), вид кассы;
“Персона_сотрудник_кассир” с полями: код (первичный ключ), ФИО_фамилия, ФИО_имя, ФИО_отчество, паспорт_серия, паспорт_номер, адрес, номер телефона (внешний ключ), номер кассы (внешний ключ),;
“Персона_сотрудник_администратор” с полями: код сотрудника (первичный ключ), ФИО_фамилия, ФИО_имя, ФИО_отчество, паспорт_серия, паспорт_номер, адрес, номер телефона (внешний ключ);
“Должность” с полями: код должности (первичный ключ), название должности;
“Карьера” с полями: номер статьи (первичный ключ), дата назначения, код должности;
“Место работы” с полями: номер приказа (первичный ключ), дата приема, дата увольнения, номер статьи (внешний ключ), код организации (внешний ключ), код персоны_сотрудника_кассира (внешний ключ), код персоны_сотрудника_администратора;
“Организация” с полями: код организации (первичный ключ), название;
“Персона_приемщик заказа” с полями: код (первичный ключ), ФИО_фамилия, ФИО_имя, ФИО_отчество, шифр транспортного предприятия (внешний ключ);
“Транспортное предприятие” с полями: шифр (первичный ключ), название, адрес;
“Заказ” с полями: номер заказа (первичный ключ), дата заказа, код персоны_сотрудника_администратора (внешний ключ), код персоны_приемщика заказа (внешний ключ), номер транспортного средства (внешний ключ);
“Справочник транспортных средств” с полями: код транспортного средства (первичный ключ), марка;
“Транспортные средства” с полями: номер (первичный ключ), вид, код (внешний ключ);
“Рейс” с полями: номер рейса (первичный ключ), дата, водитель, время фактическое, номер транспортного средства (внешний ключ), номер выезда (внешний ключ);
“Выезд” с полями: номер выезда (первичный ключ), время по расписанию, номер маршрута (внешний ключ);
“Маршрут” с полями: номер маршрута (первичный ключ), пункт назначения, расстояние.