Проектирование и реализация информационной системы. Туристическая компания

           4.6 Уровень комфортности (количество звёзд)

     5 Клиенты

           5.1 Ф.И.О. клиента

           5.2 Номер российского паспорта

           5.3 Номер заграничного паспорта

           5.4 Дата рождения

           5.5 Контактный телефон

           5.6 Номер лицевого счёта в банке

     6 Компании-перевозчики (доставка клиентов)

           6.1 Название компании

           6.2 Номер лицензии

           6.3 Юридический адрес

           6.4 Факс

     7 Распределение путёвок

           7.1 Ф.И.О. клиента

           7.2 Номер путёвки

           7.3 Дата отправления

           7.4 Гостиница (в которой будет жить клиент)

           7.5 Компания, отвечающая за доставку клиента

     8 Типы валют

           8.1 Название валюты

           8.2 Обменный курс 

     2 Концептуальная модель

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

     Введём  условные обозначения сущности и их атрибутов:

     1 Resorts (места отдыха) = {idResorts, Countries, City, Currency},

     где

     idResorts – идентификационный номер;

     Countries – страна;

     City – город (населённый пункт);

     Currency – валюта. 

     2 WorkerPersonner (рабочий персонал - гиды) = {FIO, DateAcceptance, Phone, idResorts},

     где

     FIO – Ф.И.О. клиента;

     DateAcceptance – дата приёма на работу;

     Phone – отчество клиента

     idResorts – место нахождения; 

     3 Pass (путёвки) = {idPass, Class, Duration, Cost, WorkerPersonner},

     где

     idPass – номер путёвки;

     Class – класс комфортности;

     Duration – длительность;

     Cost - стоимость

     WorkerPersonner – гид. 

     4 Hotels (гостиницы) = {Names, Address, Phone, Fax, LevelComfort, idResorts},

     где

     Names – название гостиницы;

     Address – адрес;

     Phone – телефон;

     Fax – факс;

     LevelComfort – класс комфортности;

     idResorts – курорт. 

     5 Klient (клиенты) – {FIO, NumberRusPassport, NumberForeignPassport, DateBirths, Phone, NumberCount},

     где 
FIO – Ф.И.О. клиента;

     NumberRusPassport – номер русского пасспорта;

     NumberForeignPassport – номер заграничного паспорта;

     DateBirths – дата рождения;

     Phone – контактный телефон;

     NumberCount – номер банковского счёта. 

     6 TransportationCompany (компании, отвечающие за доставку клиентов) – {Names, NumberLicenses, LegalAddress, Fax}, 
где 
Names – название компании;

     NumberLicenses – номер лицензии, в соответствии с которой компания предоставляет свои услуги;

     LegalAddress - юридический адрес;

     Fax – факс. 

     7 DistributionPass (распределение путёвок) – {Klient, Pass, DateDeparture, Hotels, TransportationCompany},

     где

     Klient – Ф.И.О. клиента;

     Pass – номер путёвки;

     DateDeparture – дата отправления;

     Hotels – гостиница;

     TransportationCompany – компания, отвечающая за доставку клиента. 

     8 Currency (типы валют) – {Names, ExchangeCourse},

     где

     Names – название валюты;

     ExchangeCourse – обменный курс. 

     Теперь  построим предварительную концептуальную модель и покажем количественное значение мощностей связей Рис. 2.1

     Рисунок 2.1 Предварительная концептуальная модель

     3 Логическое моделирование

     3.1 Построение логической модели

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

     Например, в сущность «DistributionPass» добавляются атрибуты «Klient» (Ф.И.О. клиента – первичный ключ сущности «Klient»), «idPass» (номер путёвки – первичный ключ сущности «Pass»), «Hotels» (гостиница – первичный ключ сущности «Hotels») и атрибут «TransportationCompany» (компания-перевозчик – ключевое поле сущности «TransportationCompany»). Таким же образом добавляются атрибуты и в другие сущности.

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

     3.2. Нормализация отношений.

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

     Рисунок 3.1 Логическая модель до нормализации

будут ссылаться друг на друга через эти идентификационные поля. Например, в  таблице «Klient» теперь вместо «FIO» ключевым теперь будет поле «idKlient», и теперь отношение «DistributionPass» ,будет ссылаться не на «FIO»,а на «idKlient». Кроме того, для удобства и наглядности, ссылающиеся поля (внешние ключи) переназовём также как и первичные ключи. Для только что рассмотренного примера теперь поле «Klient» отношения «DistributionPass» будет называться также как и поле, на которое оно ссылается, т.е. «idKlient».

     Основные  недостатки в базе данных ликвидированы  и там, где это требовалось, она  была приведена к 1-й нормальной форме. 

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

     Выделим в каждом отношении ключевые атрибуты (первичные ключи):

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

     Далее построим уже нормализованную логическую модель. Она изображена на (рис.3.2). Здесь база данных выглядит так, как она будет реализована далее физически в СУБД. Поля со «*» - ключевые. 

     После нормализации, концептуальная модель изменится довольно существенно. Концептуальная модель после нормализации приведена на (рис.3.3). 

Рисунок 3.2 Логическая модель после нормализации

     3.3 Целостность данных

     3.3.1 Целостность объекта

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

     Например, в нашей базе данных в отношение  «Klient» при вставке информации о новом клиенте, необходимо сначала вставить значение в поле, являющееся первичным ключом («idKlient»), а затем уже заносить информацию в остальные поля. Аналогично и с удалением, например, при удалении картежа из таблицы «Hotels», необходимо сначала удалить информацию из вторичных атрибутов, а затем уже удалять значение первичного ключа. Целостность объекта реализуется самой СУБД, и обычно пользователю нет необходимости об этом беспокоиться. 

     3.3.2 Целостность приложения 

     Ограничения целостности приложения определяют отношения, в которые пользователь может вносить изменения, связанные  с удалением, обновлением и вставкой. Ведь в базе данных существуют и такие отношения, в которые изменения вноситься не должны (по крайней мере, пользователем) – эти отношения формируются один раз при создании базы данных и далее в течение долгого времени данные в них не меняются. Эти отношения называются «справочниками» (точнее, некоторые из них).

     В базе данных «Туристическая компания» это отношения «Currency» (хотя, возможность изменения этой  таблицы реализована в приложении).

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