§ Атрибуты, входящие в UID, помечаются символом “#”
Рисунок 3 Сущности с атрибутами в ER-диаграмме
Каждая сущность должна иметь связь, представляющую информационные потребности и правила организации. Связь (Relationship) – двунаправленная ассоциация между двумя сущностями или сущностью и ей самой (рекурсивная связь).
Каждое направление связи имеет (Рисунок 4):
§ Имя, например, “участвует в” или “закреплен за”
§ Опциональность (optionality):
§ “должно быть” – сплошная линия на ER-диаграмме
§ “может быть” – пунктирная линия на ER-диаграмме
§ Мощность (degree):
§ “один и только один” – одиночная линия на ER-диаграмме
§ “один или более” – куриная лапка на ER-диаграмме
Рекурсивная связь на ER-диаграмме обозначается петлей.
Синтаксис представления связей:
Каждая сущность {должна быть | может быть} имя связи {один и только один | один или более} конечная сущность.
Примеры:
Каждый Сотрудник может участвовать в одном или более Проектов.
Каждый Проект должен быть закреплен за одним или более Сотрудников.
Каждый Сотрудник может работать под руководством одного и только одного Сотрудника.
Каждый Сотрудник может руководить одним или более Сотрудниками.
Рисунок 4 Представление связей в ER-диаграмме
Уникальный идентификатор может состоять не только из атрибутов. Сущность может быть уникально различима, также, с помощью связи. Например, подпроект однозначно идентифицируется своим номером, но, если проектов несколько, тогда номера подпроектов могут повторяться. Чтобы, несмотря на это, подпроект можно было однозначно идентифицировать, номер проекта, содержащего данный подпроект, также, должен являться частью уникального идентификатора (UID). На ER-диаграмме вхождение связи в UID обозначается поперечной чертой. Связь, входящая в уникальный идентификатор, должна быть обязательной с мощностью “один и только один” в направлении, имеющем отношение к UID.
Существует три типа связей:
§ Один к одному
§ Многие к одному
§ Многие ко многим
Мощность “один и только один” в обоих направлениях. Отображает такой характер отношений между объектами, когда каждому экземпляру одной сущности соответствует только один экземпляр другой сущности и наоборот. Это довольно редкий вид связи. Если при проектировании базы данных появляется такой вид связи, рекомендуется рассмотреть вопрос, нельзя ли объединить эти две сущности. Например, если в нашем примере добавить еще одну сущность “Паспортные данные”, то связь между этой сущностью и сущностью “Сотрудник” будет “один к одному”. В этом случае будет лучше добавить атрибут “паспортные данные” к сущности “Сотрудник”.
Мощность “один или более” в одном направлении и “один и только один” в другом. Такая связь в реляционной модели встречается наиболее часто. В нашем примере такая связь реализована между сущностями “Подпроект” и “Проект”.
Мощность “один или более” в обоих направлениях. В нашем примере такая связь реализована между сущностями “Сотрудник” и ”Проект”. Реляционная модель не позволяет напрямую реализовать связь “многие ко многим”, т.к. в этом случае не избежать ситуации, когда множественные значения вынуждены храниться в одном столбце, а это противоречит принципу неделимости, согласно которому каждая ячейка должна содержать одну порцию данных. Таким образом, связь “многие ко многим” заменяется несколькими связями “многие к одному” и представляется с помощью сущности пересечения (Рисунок 5).
Рисунок 5 Практическая реализация связи «многие ко многим» в ER-диаграмме
Не забывайте, что при логическом проектировании системы необходимо нормализовать модель данных, чтобы устранить избыточность информации.
Условия целостности базы данных – это ограничения, направленные на сохранение базы данных правильной и согласованной. Соблюдение этих ограничений должно контролироваться сервером базы данных или прикладным приложением.
|
Тип ограничения |
Описание |
|
Целостность сущностей |
Ни одна часть первичного ключа не может иметь значение NULL. Первичный ключ должен быть уникальным |
|
Целостность ссылок |
Значения внешнего ключа должны совпадать с первичным ключом или быть NULL |
|
Целостность столбцов |
Значения данных в столбце должны соответствовать заданному типу данных |
|
Пользовательские ограничения |
Ограничения, обеспечивающие выполнение бизнес-правил (например, сотрудник определенного отдела не может участвовать в работе ни над одним проектом) |
Сервер базы данных контролирует целостность данных посредством ключей:
§ Первичные ключи
Первичный ключ (PK) служит для уникальной идентификации строки. Первичный ключ должен быть уникален и определен. Первичный ключ может состоять из нескольких столбцов (составной первичный ключ). В составном первичном ключе уникальной должна быть комбинация значений в столбцах, составляющих первичный ключ. Никакая часть первичного ключа не может содержать неопределенные значения.
§ Уникальные ключи
Таблица может иметь несколько колонок, претендующих на роль первичного ключа (уникальных колонок). Уникальный ключ – столбец или сочетание столбцов, которые могут использоваться в качестве первичного ключа. В этом случае один из таких уникальных ключей следует объявить первичным ключом, а остальные оставить уникальными (альтернативными) ключами.
§ Внешние ключи
Внешний ключ (FK) – столбец или сочетание столбцов в одной таблице, которые содержат ссылку на первичный или уникальный ключ в той же или другой таблице. Внешний ключ основан на значениях данных и является логическим указателем. Значения внешнего ключа должны совпадать со значениями соответствующих первичных или уникальных ключей или быть NULL. Если внешний ключ является частью первичного ключа, он должен быть определен.
После того, как построена ER-модель базы данных, необходимо преобразовать ее в табличную модель и предусмотреть дополнительные объекты, предназначенные для ускорения поиска информации (индексы) и удобства вывода данных (представления). Кроме того, необходимо продумать, как лучше хранить объекты базы данных: на каких носителях, какой объем памяти выделить. Именно физическое проектирование обеспечивает производительность системы.
Для отображения ER-модели в табличную модель используется бланк экземпляра таблицы базы данных. Бланк должен содержать имя таблицы базы данных, и представлять собой таблицу, колонки которой являются именами столбцов таблицы базы данных, а строки содержат информацию об этих столбцах: типы ключей, обязательность и уникальность, внешние ключи, типы данных и максимальная длина. Здесь же рекомендуется привести примеры данных, которые будут храниться в соответствующих столбцах таблиц базы данных.
При заполнении бланка экземпляра таблицы используется собственная система обозначений:
|
Символ обозначения |
Описание |
|
PK |
Первичный ключ |
|
FK |
Внешний ключ |
|
FK1, FK2 |
Два внешних ключа в одной таблице |
|
FK1, FK1 |
Два столбца одного составного внешнего ключа |
|
NN |
Столбец NOT NULL |
|
U |
Уникальный ключ |
|
U1, U1 |
Два столбца одного уникального ключа |
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.