Главная страница

Лекции и практики (1). Курс лекций и материалы для практических занятий


Скачать 1.01 Mb.
НазваниеКурс лекций и материалы для практических занятий
Дата17.03.2023
Размер1.01 Mb.
Формат файлаdocx
Имя файлаЛекции и практики (1).docx
ТипКурс лекций
#996812
страница54 из 75
1   ...   50   51   52   53   54   55   56   57   ...   75

Преобразование ER–диаграммы в схему базы данных



База данных создаётся на основании схемы базы данных. Для схемы БД будем использовать обозначения, представленные на рис. 9.9.

Рис. 9.9. Обозначения, используемые на схеме базы данных
Для преобразования ER–диаграммы в схему БД приведём уточнённую ER–диаграмму, содержащую атрибуты сущностей (рис. 9.10).

Примечание. Многозначные атрибуты на рис. 9.10 выделены подчеркиванием.

Преобразование ER–диаграммы в схему БД выполняется путем сопостав- ления каждой сущности и каждой связи, имеющей атрибуты, отношения (таб- лицы) БД. Связь типа 1:n (один-ко-многим) между отношениями реализуется через внешний ключ. Ключ вводится для того отношения, к которому осу-

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

Связь участвоватьмежду ПРОЕКТАМИи СОТРУДНИКАМИпринадле- жит к типу n:m (многие-ко-многим). Этот тип связи реализуется через вспомо- гательное отношение Участие, которое содержит комбинации первичных клю- чей соответствующих исходных отношений.




Рис. 9.10. Уточнённая ER–диаграмма проектной организации

Полученная схема реляционной базы данных (РБД) приведена на рис. 9.11.


Рис. 9.11. Схема РБД, полученная из ER–диаграммы проектной организации
Бинарная связь между отношениями не может быть обязательной для обоих отношений. Такой тип связи означает, что, например, прежде чем доба- вить новый проект в отношение ПРОЕКТЫ, нужно добавить новую строку в отношение ЭТАПЫ, и наоборот. Поэтому для такой связи необходимо снять с одной стороны условие обязательности. Так как все эти связи будут реализова- ны с помощью внешнего ключа, снимем условие обязательности связей для от- ношений, содержащих первичные ключи.

Схема на рис. 9.11 содержит три цикла: "сотрудники–проекты–участие– сотрудники", "отделы–сотрудники–проекты–отделы" и "отделы–сотрудники– участие–проекты–отделы". Цикл допустим только в том случае, если связи, входящие в него, независимы друг от друга. Например, для нашей ПрО спра- ведливо такое правило: сотрудник любого отдела может быть участником (ис- полнителем или консультантом) проекта любого отдела. Эти связи независимы, поэтому цикл "отделы–сотрудники–участие–проекты–отделы" не будет приво- дить к нарушению логической целостности данных.

С другой стороны, только сотрудник отдела, отвечающего за выполнение проекта, может быть руководителем проекта. Но система не помешает нам назначить руководителем проекта сотрудника любого отдела. При добавлении проекта с внешним ключом Руководительсистема проверит только, что такой человек есть в таблице СОТРУДНИКИ. А значение внешних ключей Отделв таблицах СОТРУДНИКИи ПРОЕКТЫсравнивать не будет.

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

му: реализуем связь "руководить" через таблицу УЧАСТИЕ– это позволит не отвлекаться на малозначительные детали.

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

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

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



Рис. 9.12. Некоторые способы разрешения циклов в схеме базы данных
Другой способ разрешения цикла заключается в том, что в промежуточное отношение СОТРУДНИКИ – ПРОЕКТЫ, которое реализует связь многие-ко- многим, добавляются (мигрируют) внешние ключи Код отдела(D_id) из отно- шений СОТРУДНИКИи ПРОЕКТЫ(рис. 9.12,г). Эти ключи проверяются на равенство друг другу с помощью соответствующего ограничения целостности (check). Использование этого способа возможно в том случае, когда соответ- ствующие связи (отдел–проекти отдел–сотрудник) имеют тип один-ко- многим и являются обязательными.

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

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

Исходя из вышесказанного мы не будем разрывать связь, а примем реше- ние реализовать эту проверку программно. Приложение должно будет при назначении руководителя проекта выдавать список сотрудников того отдела, который отвечает за выполнение данного проекта. Руководителя можно будет выбрать только из этого списка, а не вводить вручную.
        1. 1   ...   50   51   52   53   54   55   56   57   ...   75


написать администратору сайта