Существует ли связь?

Бывают ситуации, где связь остается неясной. Например, рассмотрим следующее описание пользователем желаемой базы данных:

Создать базу данных для КЛИЕНТОВ и ПОСТАВЩИКОВ.

У КЛИЕНТОВ будет имя, адрес, номер телефона и номер клиента. У ПОСТАВЩИКОВ будет номер поставщика, имя и адрес.

В этой базе данных есть два сущности — КЛИЕНТ и ПОСТАВЩИК. Мы хотим хранить информацию о клиентах (их имя, адрес и т.п.) и поставщиках (номер поставщика, имя и т.п.). Но что их связывает?

В данном случае мы имеем неполное, неопределенное пользователем описание того, с чего надо разрабатывать нашу базу данных. Для компании, которая хочет иметь базу данных, связь существует – она заключается в том, что у нее есть как клиенты, так и поставщики; тем не менее, компания не может понять, что связь от КЛИЕНТА до ПОСТАВЩИКА осуществляется через саму КОМПАНИЮ или ПРОДАВЦА, а не напрямую.

Поэтому пока что в этом описании имеется две различных части базы данных компании: клиентов и поставщиков. Если позже появится некоторая другая сущность, например, "оборудование" или "продавец", которая свяжет клиентов и поставщиков, то можно будет создать сущности и связи. А пока здесь нет явной связи, поэтому все, что можно сейчас сделать – оставить все как есть, пока у пользователя не появится больше информации. Эти сущности могут существовать в таком виде только в двух разных, несвязанных базах данных.

Атрибут или Связь?

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

Предположим, мы создаем базу данных библиотеки. Предположим также, что мы создаем первичную сущность КНИГА, которая имеет атрибут читатель. В некоторых случаях, атрибут создан так, что он не подходит для выражения дополнительной связи, которая в действительности должна быть между двумя объектами. В качестве решения, читатель может потребовать использование нулевых значений для тех сущностей КНИГА, которые не выдавались пользователям. В действительности, только малая часть библиотечных книг может быть выдана в данное время. Таким образом, атрибут "читатель" должен быть нулевым для большинства сущностей КНИГА. Повторение множества нулейуказывает на то, что атрибут имя_читателя мог бы являться сущностью.Если была создана сущность ЧИТАТЕЛЬ и была явно установлена связь сущности КНИГА и сущности ЧИТАТЕЛЬ, то разработчик базы данных будет ближе к тому, чтобы корректно расставить все атрибуты и связи.

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

Контрольная точка 3.2

1. Постоянна ли связь между двумя сущностями, или свойства этой связи могут меняться со временем?

2. Атрибуты любой сущности постоянны?

3. Всегда ли существует связь между двумя сущностями?

4. Что такое двоичная связь?

Наша методология ER-проектирования теперь такова:

Методология ER-проектирования

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

Шаг 2: Для описания базы данных использовать структурный английский язык для сущностей, атрибутов и ключей.

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

Шаг 3a: Если необходима информация об атрибуте, сделать атрибут сущностью и затем

Шаг 3b: Определите ее связь с родительской сущностью.

Шаг 4: Если можно выделить еще одну сущность, изобразить диаграмму для этой сущности и ее атрибутов. Повторить шаг 2 чтобы выяснить, возможно ли дальнейшее выделение сущностей.

Шаг 5: Определить связи между сущностями, если таковые существуют.

Шаг 6: Привести пример данных.

Итоги главы

Сущности, атрибуты и связи были определены в Главе 2. Тем не менее, на практике бывает трудно определить, что есть что. В этой главе мы обсудили методы определения сущностей, атрибутов и связей. Так же в этой главе была представлена концепция двоичных связей. Реальные БД как правило имеют более одной сущности, поэтому мы так же рассмотрели эволюцию ER диаграмм от диаграмм с одной сущностью к двум. Было показано, как определить и изобразить двоичные связи между двумя сущностями используя Chen-модель. По причине того что мы только начинаем знакомство с концепцией связей и структурные ограничения связей ещё не были рассмотрены, мы не включаем в эту главу правила преобразования.

Упражнения главы 3

Упражнение 3.1

Изобразите ER диаграмму (используя Chen модель) для сущности ОТЕЛЬ, включающей в себя не менее 5 атрибутов. Среди этих атрибутов должен быть хотя бы один составной и один многозначный.

Упражнение 3.2

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

Изобразите ER диаграмму используя краткую форму (как на Рис 2.1, внизу). Как бы вы назвали здесь связь между сущностями? Распишите грамматику связей между двумя сущностями.

Упражнение 3.3

Предположим, что колледж имеет общежитие (dormitory) с множеством комнат. Имеем сущность DORMITORY, точнее сущность «комната общежития», так как только комната обладает такими атрибутами, как номер и одно/двухместная. Предположим что сущность СТУДЕНТ обладает следующими атрибутами: номер, имя, домашний телефон. Изобразите ER диаграмму с указанием связи между двумя сущностями (используя Chen-модель). Назовите образовавшуюся связь и распишите его грамматику.

Упражнение 3.4

Имеется 2 сущности ПИЛОТ и САМОЛЕТ, и описание их связи таково: “ПИЛОТ летает на САМОЛЕТЕ." Как будет читаться связь с другой стороны (со стороны самолета)?

Упражнение 3.5

Завершите методологию добавив примеры данных для Рис 3.3, 3.5, а так же к Упражнениям 1-4.

Список литературы

Atzeni, P., Ceri, S., Paraboschi, S., and Torlone, R., Database Systems, McGraw-Hill, New York, 1999.

Elmasri, R. and Navathe, S.B., Fundamentals of Database Systems, 3rd ed., Addison-Wesley, Reading, MA, 2000.

Lochovsky, F.H., Ed., Entity-Relationship Approach to Database Design and Querying, Elsevier Science, New York, 1990.

Учебный Пример: Западно-Флоридский торговый

комплекс (продолжение)

В Главе 2 мы выбрали первичную сущность, ТОРГОВЫЙ КОМПЛЕКС, и использовали структурированный английский язык для описания её атрибутов и ключей. Затем мы преобразовали сущность ТОРГОВЫЙ КОМПЛЕКС в реляционную БД (с некоторыми примерами данных). В этой главе мы продолжим разрабатывать учебный пример и посмотрим на шаги 3-5 методологии. Затем преобразуем сущности, которые войдут в реляционную базу данных.

В Шаге 3 говорится:

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

Пересматривая атрибуты ТОРГОВЫЙ КОМПЛЕКС, выясняем, что нам необходима информация об атрибуте магазин. Смотрим шаг 3a, в котором говорится:

Шаг 3a: Если необходима информация об атрибуте, сделать атрибут сущностью и затем

Шаг 3b.

Итак, Преобразуя атрибут магазин в сущность, получаем следующее:

Сущность

Эта БД содержит информацию о складе (МАГАЗИНЕ). Для каждого МАГАЗИНА в БД мы запишем название (sname), номер (snum), адрес (sloc), отделы (dept).

Атрибуты STORE

Каждому МАГАЗИНУ всегда будет соответствовать одно и только одно название. Название не будет разделяться на составные части.

Каждому МАГАЗИНУ всегда будет соответствовать один и только один номер магазина. Значение номера будет являться уникальным и неделимым на составные части.

Каждому МАГАЗИНУ всегда будет соответствовать один и только один адрес. Адрес не будет разделяться на составные части.

Для каждого МАГАЗИНА будет иметься запись отделы, причем их может быть несколько для одного и того же МАГАЗИНА.

Ключи

Для каждого МАГАЗИНА будем считать номер магазина уникальным.

Отметки: Как только МАГАЗИН преобразуется в сущность, атрибут магазин удаляется из сущности ТОРГОВЫЙ КОМПЛЕКС, как показано на Рис 3.7.

Определив сущность МАГАЗИН, следуем Шагу 3b:

Шаг 3b: Определите связь с родительской сущностью

Связь «расположен» (located_in) между сущностями МАГАЗИН и ТОРГОВЫЙ КОМПЛЕКС изображена на Рис 3.7.

Рис 3.7: ER Диаграмма БД ТОРГОВЫЙ КОМПЛЕКС (на данной стадии)

Следующий шаг 4:

Шаг 4: Если можно выделить еще одну сущность, изображаем диаграмму для этой сущности и ее атрибутов. Повторяем шаг 2 чтобы выяснить, возможно ли дальнейшее выделение сущностей.

Введем ещё одну сущность МЕНЕДЖЕР_МАГАЗИНА. Повторяем шаг 2 для данной сущности:

Сущность

Эта БД содержит информацию о МЕНЕДЖЕРЕ_МАГАЗИНА. Для каждого МЕНЕДЖЕРА_МАГАЗИНА в БД запишем имя, номер социального обеспечения, и зарплату.

Следующий шаг 4:

Атрибуты сущности МЕНЕДЖЕР_МАГАЗИНА

Каждому МЕНЕДЖЕРУ_МАГАЗИНА всегда будет соответствовать одно и только одно имя. Имя не будет разделяться на составные части.

Каждому МЕНЕДЖЕРУ_МАГАЗИНА всегда будет соответствовать один и только один номер социального обеспечения. Значение номера будет являться уникальным и неделимым на составные части.

Каждому МЕНЕДЖЕРУ_МАГАЗИНА всегда будет соответствовать одна и только одна зарплата. Зарплата не будет разделяться на составные части

Ключи

Для каждого МЕНЕДЖЕРА_МАГАЗИНА будем считать номер социального обеспечения уникальным.

Определив сущность МЕНЕДЖЕР_МАГАЗИНА, следуем Шагу 5:

Шаг 5: Определите связи между сущностями, если таковые существуют.

Связь между сущностями МАГАЗИН и МЕНЕДЖЕР_МАГАЗИНА называется «управляет». Она изображена на Рис 3.8.

Рис 3.8: ER диаграмма БД ТОРГОВЫЙ КОМПЛЕКС в разработке

Выбираем следующую первичную сущность ВЛАДЕЛЕЦ_МАГАЗИНА. Повторяем Шаг 2 для неё.

Сущность

Эта БД содержит информацию о ВЛАДЕЛЬЦЕ_МАГАЗИНА. Для каждого ВЛАДЕЛЬЦА_МАГАЗИНА в БД запишем имя, номер социального обеспечения, рабочий телефон и адрес.

Атрибуты сущности ВЛАДЕЛЕЦ_МАГАЗИНА

Каждому ВЛАДЕЛЬЦУ_МАГАЗИНА всегда будет соответствовать одно и только одно имя. Имя не будет разделяться на составные части.

Каждому ВЛАДЕЛЬЦУ_МАГАЗИНА всегда будет соответствовать один и только один номер социального обеспечения. Значение номера будет являться уникальным и неделимым на составные части.

Каждому ВЛАДЕЛЬЦУ_МАГАЗИНА всегда будет соответствовать один и только один рабочий телефон. Рабочий телефон не будет разделяться на составные части

Каждому ВЛАДЕЛЬЦУ_МАГАЗИНА всегда будет соответствовать один и только один адрес. Адрес не будет разделяться на составные части

Ключи

Для каждого ВЛАДЕЛЬЦА_МАГАЗИНА будем считать номер социального обеспечения уникальным

Определив сущность ВЛАДЕЛЕЦ_МАГАЗИНА, следуем Шагу 5:

Шаг 5: Определите связи между сущностями, если таковые существуют

Связь между сущностями МАГАЗИН и ВЛАДЕЛЕЦ_МАГАЗИНА называется «владеет». Она изображена на Рис 3.9.

Рис 3.9: ER Диаграмма БД ТОРГОВЫЙ КОМПЛЕКС с 4 сущностями

Правила преобразования сущности в реляционную БД

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

Отношение для сущности ТОРГОВЫЙ_КОМПЛЕКС

Первые два отношения , МАГАЗИН и ТОРГОВЫЙ КОМПЛЕКС аналогичны тем, что были в Главе 2:

Отношение для сущности МАГАЗИН

Сущность МАГАЗИН имеет многозначный атрибут – отделы, так что нам снова придется использовать правила преобразования M1 и M1c (как это делалось в Главе 2) для преобразования этой сущности. Сперва, мы покажем связь с исключенным многозначным атрибутом, а затем покажем связь с этим многозначным атрибутом. (Примечание: Мы разрабатываем БД для западно-флоридского торгового комплекса, поэтому мы преобразуем только его магазины.)

Отношение с исключенным многозначным атрибутом

Отношение с многозначным атрибутом

Отношение для сущности МЕНЕДЖЕР_МАГАЗИНА (получено с помощью правил преобразования M1 и M1a)

Отношение для сущности ВЛАДЕЛЕЦ_МАГАЗИНА (получено с помощью правил преобразования M1 и M1a)

На данный момент наша БД выглядит следующим образом (без данных):

[Примечание:Первичные ключи подчеркнуты.]

Мы продолжим рассмотрение этого учебного примера в конце Главы 4.