Файл: ДИПЛОМ Аюпова-теория.doc

3.1.5. Перепроверкасвязей типа 1:1

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

На этапе 3.1.3. была введена новая связь типа 1:1, помещенная в модель с целью удаления рекурсивных связей. Это связь Подчиненный Принадлежит к Работник, показанная на рисунке 3.1.3. В данном случае сущностиРаботник иПодчиненный, по сути, не являются представлением одного и того же объекта. Различие между ними состоит в том, что работники, представленные сущностьюПодчиненный, имеют особые связи с сущностямиМенеджериСекретарь, а так же составляют только часть всего персонала. Исходя из этих соображений, мы принимаем решение, сохранить в модели сущности и их связи, показанные на рисунке 3.1.2.

3.1.6. Удаление избыточных связей

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

Связь Клиент Покупает Объектследует просто удалить из модели данных.

3.1.7. Создание диаграммы «сущность-связь»

ER-диаграмма, представляющая локальную концептуальную модель данных для представленияМенеджерприложенияРеалтэкс, была показана на рис. 2.8. При выполнении этапа 3.1 эта модель была пересмотрена и модифицирована с целью устранения структур данных, реализация которых в среде реляционных СУБД затруднительна. Вид модифицированной модели данных, с учетом всех изменений показан на рис. 3.1.7. Полученную в результате внесения изменений модель данных правильнее будет называть локальной логической моделью данных представленияМенеджерприложенияРеалтэкс.

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

1

М

Менеджер

1

1

Отдел

М 1 М 1

1

1

1 М

Договор

1

М

М

1 1

1

Владелец

1

1

Клиент

1

М

Осмотр

СМИ

Рис. 3.1.7. Локальная логическая модель данных для пользователя МенеджерприложенияРеалтэкс

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

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

Для описания структуры создаваемых отношений мы воспользуемся языком DBDL(DatabaseDefinitionLanguage), широко используемым в реляционных СУБД. Описание отношения на языкеDBDLначинается с присвоенного ему имени, за кото­рым следует помещенный в скобки список имен его простых полей. Затем указыва­ется первичный ключ отношения и все его альтернативные и/или внешние ключи. После описания внешних ключей может указываться ссылочный первичный ключ, если таковой имеется. Все имена отношений и полей мы будем писать в английской транскрипции.

Связи, которые сущность имеет с другими типами сущностей, представляются с помощью механизма первичных и внешних ключей. Для принятия решения о том, откуда взять и куда поместить значения атрибута (ов) внешнего ключа, предварительно следует установить, какая из участвующих в связи сущностей является родительской, а какая — дочерней. Родительской считается сущность, которая передает копию набора значений своего первичного ключа в отношение, представляющее дочернюю сущность, где эти значения будут играть роль внешнего ключа.

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

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

Otdel (Otdel_№, Otdel_Imya, Tel_№, Fax_№)

Primary Key Otdel_№

Alternate Key Tel_№

Rabotnik (Rab_№, Imya, Familiya, Adres, Tel_№, Pol, DR, Dolzhnost, Skorost_Pechati, Otdel_№)

Primary Key Rab_№

Foreign Key Otdel_№ reference Otdel (Otdel_№)

Object (Object_№, Tip, S, Komnaty, Cena, Rayon, Ulica, Dom, Kv,Otdel_№, Vladelec_№)

Primary Key Object_№

Foreign Key Otdel_№ reference Otdel (Otdel_№)

Foreign Key Vladelec_№ reference Vladelec (Vladelec_№)

Vladelec (Vladelec_№, Nazvanie, Adres, Tel_№, Kontakt)

Primary Key Vladelec_№

Klient (Klient_№, Imya, Familiya, Adres, Tel_Kl, Object_Tip, S_Max, Cena_Max )

Primary Key Klient_№

Dogovor (Dogovor_№, Data_Dogovor, Cena, Avans, Data_Avans, Data_Okonchanie, Okonchanie, Object_№, Rab_№, Klient_№ )

Primary Key Dogovor_№

Foreign Key Object_№ reference Object (Object_№)

Foreign Key Rab_№ reference Rabotnik (Rab_№)

Foreign Key Klient_№ reference Klient (Klient_№)

Objyavlenie (Objyavlenie_№, Data, Cena, Object_№, SMI_№ )

Primary Key Objyavlenie_№

Foreign Key Object_№ reference Object (Object_№)

Foreign Key SMI_№ reference SMI (SMI_№)

SMI (SMI_Imya, Adres, Tel_№, Kontakt )

Primary Key SMI_№

Alternate Key Tel_№

Osmotr (Data_Os, Kommentarii, Klient_№, Object_№ )

Primary Key Klient_№, Object_№, Data_Os

Foreign Key Object_№ reference Object (Object_№)

Foreign Key Klient_№ reference Klient (Klient_№)

Sobesedovanie (Data_Sob, Kommentarii, Rab_№, Klient_№ )

Primary Key Klient_№, Rab_№, Data_Sob

Foreign Key Rab_№ reference Rabotnik (Rab_№)

Foreign Key Klient_№ reference Klient (Klient_№)