Добавил:
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Моделирование бизнес-процессов / Моделирование бизнес-процессов / ER-диаграмы / Проектирование реляционных БД с помощью ER-диаграмм_ver1.6.doc
Скачиваний:
184
Добавлен:
30.04.2013
Размер:
7.8 Mб
Скачать

Глава 3: После первой диаграммы сущности

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

Первый прием, применяемый в этой главе, имеет методологический характер. Мы проверяем нашу первичную сущность для того, чтобы выяснить, являются или нет наши «атрибуты» сами по себе отдельными сущностями. Далее мы ищем в описании другие части информации и: (1) добавляем их к существующей сущности в качестве атрибутов и проверяем существующую ER-диаграмму, или (2) создаем непосредственно новую сущность. После создания новой сущности следует определить тип связи между двумя сущностями. В данной главе описываются 3, 4, 5 шаги методологииER-проектирования. Шаг 3 проверяет атрибуты первичной сущности, шаг 4 определяет действия при необходимости добавления еще одной сущности, шаг 5 устанавливает связи между двумя сущностями.

Хотя в этой главе рассматривается понятие связи, мы не включаем в нее никаких новых правил преобразования, в силу того, что эти правила лучше усвоятся после наложения структурных ограничений на связи, которые обсуждаются в Главе 4. В конце этой главы, мы продолжаем изучение примера, которое начали в Главе 2.

Проверка Сущности — замена атрибута сущностью

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

Рисунок 3.1: Сущность СТУДЕНТ с многозначным атрибутом

Пользователь хочет нам сказать, что атрибут Школа должен в действительности быть сущностью. Вспомните, что определение сущности таково - что-то, о чем мы хотим записать информацию. Изначально мы записывали посещенные школы, а теперь говорим, что хотим записать информацию о школах. Первый признак того, что атрибут должен считаться сущностью - необходимость ввода информации об атрибуте.

Следовательно, преобразуем Рисунок 3.1 в Рисунок 3.2. На Рисунке 3.2 ШКОЛА является теперь самостоятельным объектом, итак, теперь у нас есть две различные сущности: ШКОЛА и СТУДЕНТ. Следующий шаг должен определить связь между двумя сущностями. Предположим, что название школы – уникально и выберем название_школы в качестве ключа для сущности ШКОЛА.

Рисунок 3.2: Две ER Диаграммы: СТУДЕНТ и ШКОЛА

Определение связи для новой сущности

Базы данных предназначены для хранения связанных данных. Например, нет ничего необычного в том, чтобы записывать данные о студентах и иностранной валюте или о полетах авиакомпании и рабочих на заводе по производству теннисных мячей в одной и той же базе данных. Эти понятия не связаны. В базе данных необходимо создавать совокупность связанных данных. Следуя нашему методу, мы прояснили ситуацию, в которой атрибут был частью сущности (школа считалась "частью" студента), но теперь школа стала самостоятельной сущностью. Теперь необходимо связать сущность ШКОЛА и сущность СТУДЕНТ.

На Рисунке 3.2 - две сущности, но они кажутся независимыми. Чтобы преобразовать сущность ШКОЛА и сущность СТУДЕНТ в базу данных, надо что-то добавить — связь сущности ШКОЛА и сущности СТУДЕНТ.

Связь в ER диаграмме – это соединение между собой двух и более сущностей или с самим собой. Последний тип связи, сам с собой, известен как рекурсивная связь, которую мы обсудим позже (в Главе 6). Название связи – обычно глагол или глагольная форма, которая обозначает связь между сущностями. Как только мы поймем, как обозначаются связи, у нас появится "инструмент" представления базы данных в форме ER диаграммы.

В Chen модели, связь изображена ромбом и линиями, соединяющими две сущности, как изображено на Рисунке 3.3.

Рисунок 3.3: Сущность СТУДЕНТ со связью к сущности ШКОЛА

На Рисунке 3.3, отношение изображено как «посещает». Значение связи является глаголом, соединяющим оба существительных (обе сущности). Связь является двухсторонней. Как видно, необходимо указывать все связи в обоих направлениях. Например, в Chen моделях, мы можем неформально сказать, "СТУДЕНТЫ посещают ШКОЛЫ" или "ШКОЛЫ посещаются СТУДЕНТАМИ".

Степень связи зависит от количества сущностей, которые участвуют в отношении. На Рисунке 3.3 две сущности участвуют в отношении «посещает», такая связь называется двоичной.

Теперь мы имеем средство, чтобы "изобразить" описание базы данных в виде ER диаграммы. Назначение наших диаграмм – в том, что мы записываем информацию об x и об y (x и y - сущности) и затем сообщаем, какова связь между x и y.

Наша дополненная и скорректированная методология теперь выглядит так