Этапы проектирования БД (требования при проектировании,

Базова

1. Андрейцев В.I., Пустовойт М.А., Калиновський С.В. Eкологiчна експертиза: право i практика. – К.: Урожай, 1992. – 205 с.

2. Бубнов А.Г., Гриневич В.И., Кувыкин Н.А. Оценка воздействия на окружающую среду и экологическая экспертиза: Учебно-метод. пособие; 2-е изд. доп. и перераб.; Под общ. ред. Кострова В.В.. Иван. гос. хим.-технол. ун-т. -Иваново, 2004. – 260 с.

3. Екологічна експертиза: Теорія та практика: Навч. Посібник / Смирнова В.Г., Костенюк Л.В. – Чернівці: Рута, 2008.- 104 с.

4. Лазор О. Я. Екологічна експертиза: Теорія, методологія, практика: Монографія./ За наук. Редакцією проф.. М.Д. Лесечка. – Львів: Ліга-Прес, 2002. – 364 с.

5. Матвеев А.В., Котов В.П. Оценка воздействия на окружающую среду и экологическая экспертиза: Учеб. пособие/ СПбГУАП. СПб., 2004. – 104 с.

6. Позаченюк Е.А. Экологическая экспертиза: природно-хозяйственные системы. Монография. - Симферополь: 2006. - 473 с.

Допоміжна

7. Андрейцев В.И. Правовое обеспечение экологической экспертизы проектов. – К.: Будівельник, 1990. – 167 с.

8. Боков В.А., Лущик А.В. Основы экологической безопасности. – Симферополь: Сонат, 1998. – 223 с.

9. Букс И.И., Фомин С.А. Экологическая экспертиза и оценка воздействия на окружающую среду (ОВОС); Международный независимый эколого-политологический университет. – М., 1998. – 77 с.

10. Географическое обоснование экологических экспертиз / Под ред. Т.В.Звонковой. – М: Изд-во МГУ, 1985. – 208 с.

11. Гродзинський М.Д. Стiйкiсть геосистем до антропогенних навантажень. – К.: Лiкей, 1995. – 233 с.

12. Дьяконов К. П., Дончева Л. В. Экологическое проектировагние и экспертиза: Учебник для
вузов / К. Н. Дьяконов, Л В. Дончева. — М.: Аспект Пресс,
2005. - 384 с.

13. Каштанов А.Н., Лисецкий Ф.Н., Швебс Г.И. Основы ландшафтно-экологического землеведения. – М.: Колос, 1994. – 127 с.

14. Лаженцев В.Н., Дмитриева Т.Е. Сущность географической экспертизы // География и практика территориального хозяйствования. – Екатеринбург: Наука. – 1993. – 136 с.

15. Методика расчета концентраций в атмосферном воздухе вредных веществ, содержащихся в выбросах предприятий. ОНД-86. Госкомгидромет. – Л.: Гидрометеоиздат, 1987. – 92 с.

16. Методические рекомендации по организации осуществления государственной экологической экспертизы в системе Минприроды Украины. – К., 1992. – Вып.1. – 15 с.

17. Методические указания по ландшафтным исследованиям для сельскохозяйственных целей / Г.И.Швебс, Г.П.Ковеза, И.Н.Волошин и др. / Под ред. Г.И.Швебса. – М., 1990. – 57 с.

18. Методические указания по организации осуществления государственной экологической экспертизы в системе Минприроды Украины. – К., 1992. – Вып.1. – 21 с.

19. Методические указания по проведению государственной экологической экспертизы. – М., 1990. – 68 с.

20. Методические указания по рассмотрению материалов предварительного согласования мест размещения объектов и проектов отведения земельных участков в органах Минприроды Украины. Сопроводительное письмо Минприроды Украины от 03.07.92г. – №6-8-528.

21. Нехорошков В.П., Попова Н.Д. Екологічна експертиза матеріалів ОВНС: посібник до практичних занять. Одеська державна академія холоду, 2011р. – 46 с.

22. Оценка воздействия на окружающую среду (ОВОС) при проектировании и строительстве предприятий, зданий и сооружений. Основные положения проектирования. ДБН А.2.2.-1-95. Государственные строительные нормы Украины. – К., 1995. – 15 с.

23. Ходулева М.В., Черп О.М., Виниченко В.Н. Как организовать общественную экологическую экспертизу. Рекомендации для общественных организаций. – М., 1997. – 44 с.

24. Швебс Г.И. Контурное земледелие. – Одесса, 1985. – 55 с.

25. Яцухно В.М., Мандер Ю.Г. Формирование агроландшафтов и охрана природной среды. – Минск, 1995. – 121 с.

инфологическая, концептуальная и физическая модели)

В жизненном цикле БД одним из наиболее важных этапов является этап проектирования, от результатов которого зависит эффективность дальнейшего использования БД в решении задач предметной области (ПО). Главная задача, которая решается в процессе проектирования - это организация данных: интегрирование, структурирование и определение взаимосвязей. Способ организации данных определяется логической моделью, которая отражает основные сущности ПО и их взаимосвязи. Наибольшую популярность приобрела реляционная модель в силу ее простоты и математической обоснованности. Как следствие большинство современных СУБД поддерживают эту модель.

При проектировании и эксплуатации БД к ней предъявляются следующие требования:

1. Адекватность отображения ПО (полнота, целостность, непро­тиворечивость, актуальность данных).

2. Возможность взаимодействия пользователей разных категорий; обеспечение высокой эффективности доступа.

3. Дружественность интерфейса.

4. Обеспечение секретности и конфиденциальности.

5. Обеспечение взаимной независимости программ и данных.

6. Обеспечение надежности БД; защита данных от случайного и преднамеренного разрушения; возможность быстрого и полного восстановления данных в случае сбоев в системе.

При проектировании БД организацию данных принято рассматривать на трех уровнях: информационно-логическом (инфологическом), даталогическом (концептуальном) и физическом. Этим уровням соответствуют инфологическая, концептуальная и физическая модели предметной области. Весь процесс проектирования может быть разбит на три этапа (рис. 4.1).

Рис. 4.1. Этапы проектирования БД

Модель данных - это правила, которые определяют структуру данных, допустимые реализации данных и допустимые операции над данными.

Инфологическая модель описывает предметную область (ПО) на содержательном уровне. На первом этапе при ее разработке осуществляется анализ ПО, решаемых задач, запросов пользователей и документов, отражающих события и процессы, протекающие в ПО. Результатом этого анализа являются списки объектов ПО, перечни их свойств или атрибутов, определение связей между объектами и описание структуры ПО в виде диаграммы. Для каждого из атрибутов указываются ограничения на их возможные значения, определяемые свойствами ПО. Такие ограничения называются ограничениями целостности данных. Инфологическая модель объединяет в единое «обобщенное представление» требования отдельных пользователей и служит средством общения между ними, поэтому разрабатывается без учета особенностей представления данных в памяти ЭВМ.

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

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

4.2. О сновные понятия РБД (отношение, сущность, атрибут, связь, ключ, домен, примеры)

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

Отношение задается своим именем и списком атрибутов - элементов, связанных этим отношением:

<имя отношения>(<список атрибутов>)

Имя отношения выбирается таким образом, чтобы оно поясняло смысл связи между элементами отношения (семантику отношения).

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

Атрибут характеризуется именем, типом, значением и другими свойствами.

Имя атрибута - это условное обозначение атрибута в процессах обработки данных. Оно должно быть уникальным в пределах одного и того же отношения.

Значение атрибута - величина, характеризующая некоторое свойство объекта и связи.

Атрибуты соответствуют классам сущностей, объединяемых данным отношением. Список имен атрибутов отношения и их характеристик называют схемой отношения.

Характеристики атрибутов задают область допустимых значений (ОДЗ) для каждого аргумента отношения.

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

Домен - множество возможных значений атрибута.

Пример 4. 1. БД «Детали и поставщики» о поставке деталей может быть описана следующими отношениями:

Деталь (< номер детали >, <название детали>, <цвет>, <вес>).

Поставщик (< код поставщика >. <фамилия>, <город>).

Поставка деталей (< код поставщика >. < номер детали >, <количество>).

Первичные ключи подчеркнуты.

Ограничения на значения атрибутов могут быть заданы типом данного для соответствующего атрибута (табл. 4.1).

Другая форма представления отношения - табличная. Каждому отношению соответствует таблица с таким же именем. Атрибуту в таблице соответствует столбец с именем атрибута, а каждому кортежу отношения - строка таблицы. Строка таблицы часто называется записью, а значение атрибута - полем записи.

Таблица 4.1

Задание ограничений на значения атрибутов

Имя атрибута	Тип
Код поставщика	Символьный (3)
Фамилия	Символьный (6)
Город	Символьный (10)
Номер детали	Целый
Название детали	Символьный (6)
Цвет	Символьный (6)
Вес	Целый
Количество	Целый

Пример 4. 2. Описание отношений БД «Детали и поставщики» с помощью табл. 4.2 - 4.4.

Таблица 4.2

Запись отношения «Деталь» в виде таблицы

Номер детали	Название детали	Цвет	Вес
	Болт	Черный
	Муфта	Синий

Таблица 4.3

Запись отношения «Поставщик» в виде таблицы

Код поставщика	Фамилия	Город
П1	Иванов	Ярцево
П2	Алексин	Курск

Таблица 4.4

Запись отношения «Поставка деталей» в виде таблицы

Код поставщика	Номер детали	Количество
П1
П2

Здесь в отношении Деталь атрибутами являются номер детали, название детали, цвет, вес. Значениями этих атрибутов в первой строке таблицы будут соответственно <101, Болт, Черный, 3>. Каждая строка таблицы является кортежом и описывает конкретный экземпляр сущности Деталь. Доменами атрибутов будут: для номера детали D₁ - множество целых чисел, для названия детали D₂ - множество символьных строк, названий предметов, для цвета D₃ - множество символьных строк, названий цветов, для веса D₄ - множество целых чисел. В отношении два кортежа, причем каждый состоит из четырех упорядоченных элементов. Для отношения Поставка деталей первичный ключ является составным <код поставщика, номер детали>.

4.3. Нормализация отношений (1, 2, 3 НФ; НФБК; ФЗ; потенциальный ключ; детерминант; пример)

В ходе разработки РБД должен быть определен состав взаимосвязанных реляционных таблиц и определен состав атрибутов каждого отношения с указанием ограничений на их допустимые значения. Состав атрибутов должен отвечать требованиям нормализации. Нормализация отношений производится на этапе концептуального проектирования БД.

Существует несколько нормальных форм (НФ) реляционной модели данных (РМД), которые позволяют исключить избыточное дублирование данных, обеспечить целостность и непротиворечивость данных.

При первой нормальной форме (1НФ) все атрибуты отношения должны быть простыми (атомарными, неделимыми) с точки зрения СУБД.

НФ более высокого порядка основаны на понятии функциональной зависимости (ФЗ), которая может быть определена следующим образом.

Пусть А и В - подмножества атрибутов отношения. Говорят, что В функционально зависит от А (А-->В), если для каждого значения А существует ровно одно связанное значение В. ФЗ можно выявить, исходя из базовых свойств самих атрибутов путем анализа.

При второй нормальной форме (2НФ) должна обеспечиваться 1НФ и каждый неключевой атрибут функционально полно зависит от ключа.

Полная ФЗ от ключа означает, что если ключ составной, то любой неключевой атрибут зависит от всего ключа и не зависит ни от какой его части.

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

Нормальная форма Бойса-Кодда (НФБК) является развитием ЗНФ и требует, чтобы в отношении были только такие ФЗ, левая часть которых является потенциальным ключом отношения. Потенциальным ключом называется такое подмножество атрибутов отношения, которое удовлетворяет определению первичного ключа отношения. Фактически первичный ключ - это один из потенциальных ключей, назначенный в качестве первичного.

Поясним эти определения на примере.

Пример 4. 3. Рассмотрим БД «Успеваемость студентов общежития». БД состоит из одного отношения, в котором представлена информация о студентах, проживающих в общежитии, и их оценках по изучаемым дисциплинам в различных семестрах.

Задано отношение:

Студент (<Сном>, <Сфам>, <Кном>, <Тном>, <Дисциплина>, <Семестр>, <Оценка>)

Основные атрибуты отношения: номер зачетной книжки студента (Сном); фамилия студента (Сфам); номер комнаты (Кном), где он проживает; номер телефона (Тном) в комнате (предполагается, что один телефон на одну комнату); дисциплина; семестр; оценка. Диаграмма (рис. 4.2) отражает ФЗ между атрибутами отношения: Сном-->Сфам, Сном-->Кном, Сном-->Тном, Кном-->Тном, Тном->Кном, <Сном,Дисциплина,Семестр --> Оценка.

Рис. 4.2. Диаграмма ФЗ отношения Студент

Рассмотрим некоторые определения.

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

Детерминантом называется левая часть ФЗ.

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

Существуют НФ более высокого уровня, которые накладывают более сильные ограничения; на практике в большинстве случаев достаточно получить отношения в НФБК.

В отношении Успеваемость студентов общежития один потенциальный ключ <Сном, Дисциплина, Семестр>. Детерминантами являются: <Сном, Дисциплина, Семестр>, <Сном>, <Кном>, <Тном>. Представим списки детерминантов и потенциальных ключей в виде таблицы (табл. 5).

Таблица 5

Списки детерминантов и потенциальных ключей

Потенциальные ключи	Детерминанты
<Сном, Дисциплина, Семестр>	<Сном, Дисциплина, Семестр> <Сном> <Кном> <Тном>

Очевидно, что данное отношение не находится в НФБК, так как детерминанты Сном, Кном, Тном не являются потенциальными ключами. Для приведения отношения к НФБК его следует разбить на три отношения:

Студент (Сном, Сфам, Кном)

Оценка (Сном, Дисциплина, Семестр, Оценка)

Телефон (Кном, Тном).

Каждое из этих отношений находится в НФБК, так как в них все детерминанты являются потенциальными ключами.

4.4. Целостность реляционных данных. Преимущества и недостатки РМД

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

Выделяют два основных вида ограничений: внутренние и явные.

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

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

В РМД существует два вида внутренних ограничений целостности:

1. Целостность по существованию - потенциальный ключ отношения не может иметь пустого (NULL) значения. Иными словами, так как потенциальный ключ отношения позволяет из всего множества экземпляров сущности выделить только один, то сущность, не имеющая идентификатора, не существует.

2. Целостность по связи - определяется понятием внешнего ключа (ВК) отношения: подмножество атрибутов отношения R2 называется внешним ключом для отношения R1, если каждому значению ВК отношения R2 найдется такое же значение первичного ключа в отношении R1. Внешний ключ является тем клеем, который обеспечивает связывание отдельных отношений РБД в единое целое. Целостность данных по связи означает систему правил, используемых в СУБД для поддержания связей между записями в связанных таблицах, а также обеспечивает защиту от случайного удаления или изменения связан­ных данных, от некорректного изменения ключевых полей.

Способы реализации внутренних ограничений целостности зависят от конкретной СУБД. Для СУБД Access они будут рассмотрены после общего знакомства с этой системой.

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

4.5. Реляционные операции. Операции над отношениями

Основными операциями над отношениями РМД являются 8 операций, входящих в реляционную алгебру Кодда (автора РМД). Реляционная алгебра Кодда включает традиционные операции над множествами: объединение, пересечение, вычитание, декартово произведение - и специальные операции: выбор, проекция, соединение и деление. Совокупность этих операций образует замкнутую алгебру отношений. Замкнутость определяется тем, что аргументами операции реляционной алгебры являются отношения и результатом обработки всегда является новое отношение, которое также может быть аргументом в другой операции (по аналогии с обычной алгеброй чисел).

Рассмотрим некоторые операции реляционной алгебры.

Объединение - операция выполняется над двумя совместными отношениями R₁, R₂ (с идентичной структурой - d₁, d₂, …, d_n). В результате операции объединения строится новое отношение R = R₁ U R₂. Отношение R имеет тот же состав атрибутов и совокупность кортежей исходных отношений. Причем в эту совокупность не включаются дубликаты по определению отношения.

Пример 4. 4. Ниже приведены исходные отношения: R₁ «Клиенты банка А» (табл. 4.6) и R₂ «Клиенты банка В» (табл. 4.7) и результат объединения - R (табл. 4.8).

Таблица 4.6

Отношение R₁ «Клиенты банка А»

	Город	Фамилия
К11	Москва	Петров
К12	Санкт-Петербург	Смирнов
К13	Воронеж	Соколов

Таблица 4.7

Отношение R₂ «Клиенты банка В»

	Город	Фамилия
К21	Самара	Петров
К22	Москва	Петров
К23	Тверь	Семенов

Таблица 4.8

Отношение R «Клиенты»

	Город	Фамилия
К11	Москва	Петров
К12	Санкт-Петербург	Смирнов
К13	Воронеж	Соколов
К21	Самара	Петров
К23	Тверь	Семенов

Пересечение - операция выполняется над двумя совместными отношениями R₁, R₂. Результирующее отношение RP = R₁ ∩ R₂ содержит кортежи, которые

есть в каждом из двух исходных. Результат пересечения имеет тот же состав атрибутов, что и в исходных отношениях.

Пересечение двух отношений – R₁, «Клиенты банка А» и R₂, «Клиенты банка В» дает одно отношение RP «Клиент» (табл. 4.9).

Таблица 4.9

Отношение RP «Пересечение отношений»

	Город	Фамилия
К11 (К22)	Москва	Петров

Вычитание - операция выполняется над двумя совместными отношениями R₁, R₂. В результате операции вычитания строится новое отношение RV = R₁ - -R₂ с идентичным набором атрибутов, содержащее только те кортежи первого отношения R₁, которые не входят в другое отношение R₂. Вычтем отношение R₂ «Клиенты банка В» из отношения R₁ «Клиенты банка А». Поскольку К11 = К22, вычитание дает отношение RV «Клиент только банка В»:

RV = R₁ - R₂ = {К11, К12, К13} – {К21, К22, К23} = {К12, К13}.

Рассмотренные выше операции в той или иной мере реализуются в языке манипулирования данными (ЯМД) СУБД, обеспечивающем обработку реляционных таблиц. К таким языкам относится, например, язык SQL (Structured Query Language), язык QBE (Query By Example) и другие языки запросов.

Развитие реляционного подхода привело к созданию реляционных языков. Например, язык SQL, реализованный в большинстве СУБД, является более чем реляционно-полным, так как кроме операций реляционной алгебры он содержит полный набор операторов над кортежами - Включить, Удалить, Изменить, а также реализует арифметические операции и операции сравнения.

Контрольные вопросы

1. Требования, предъявляемые к БД при проектировании и эксплуатации.

2. Этапы проектирования БД.

3. Дать определение инфологической модели БД.

4. Дать определение концептуальной модели БД.

5. Что такое модель данных?

6. Какие существуют модели данных?

7. Из каких элементов состоит любая модель данных?

8. Дать определение РМД.

9. Что представляют собой структуры РМД?

10. Каковы ограничения целостности РМД?

11. Операции РМД.

12. Дать определение отношения.

13. Дать определение первичного ключа отношения.

14. Дать определение внешнего ключа отношения.

15. Дать определение потенциального ключа отношения.

16.Что такое ФЗ?

17. В чем заключается процесс нормализации отношения?

18. Дать определение НФБК.

19. Почему отношение надо приводить к НФБК?

20. Дать определение 1, 2, 3 НФ.

4.6. Постановка задачи проектирования РБД с использованием

метода «сущность-связь» (с ущность, связь, атрибут, ER-диаграмма)

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

1. Возможности хранения всех необходимых данных в БД.

2. Исключения избыточных данных.

3. Сведения числа хранимых отношений в БД к минимуму.

4. Нормализации отношений для упрощения решения проблем, связанных с обновлением, добавлением и удалением данных.

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

Метод «сущность-связь». Разработку логической модели можно осуществлять различ­ными методами. Наиболее формализованным и простым для по­нимания является метод «сущность-связь», или ER-метод. Суть метода состоит в построении ER-диаграмм, отображающих в графической форме основные объекты предметной области (ПО) и связи между ними, и в определении характеристик этих связей. Затем по четким правилам делается переход от ER -диаграмм к таблицам БД, осуществляется наполнение таблиц атрибутами и проверка их на выполнение условий нормализации (НФБК). Определяются ключевые атрибуты таблиц и связи между таблицами. Результатом проектирования является схема данных БД.

Рассмотрим более подробно отдельные этапы метода «сущность-связь». Для этого вначале познакомимся с некоторыми понятиями в области анализа данных.

Сущности и связи. Сущность - это объект, информация о котором должна быть представлена в БД (обычно соответствует существительному). Экземпляр сущности - это информация о конкретном представителе объекта. Например, для сущности Студент экземпляром является Петухов В. В., а для сущности Группа - экземпляром является 144.

Связь - соединение между двумя и более сущностями (соответствует глаголу). Экземпляр связи - это конкретная связь между конкретными представителями объектов. Например, для связи Студент учится в группе экземпляром является Петухов В. В. учится в группе 144.

Атрибут - свойство сущности или связи. Например, Фамилия, Имя, Отчество есть атрибуты сущности Личность, а слова Терехин, Александр, Николаевич являются экземплярами этих атрибутов.

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

Пример 4.5. Рассмотрим БД о преподавателях и о дисциплинах, которые они читают.

Сущности ПО:	Преподаватель, Дисциплина.
Связь между ними:	Преподаватель читает Дисциплину.

4.7. Построение ER-диаграммы предметной области (ER-диаграммы экземпляров и классов; пример)

Рассмотрим построение ER-диаграммы, описывающей структуру предметной области (ПО). В ER-диаграмме для отображения сущностей используются прямоугольники, а для отображения связей - ромбы. Различают ER-диаграммы для экземпляров сущностей и ER-диаграммы для классов сущностей. Ниже приведены ER-диаграммы обоих типов для БД Преподаватель читает дисциплину (рис. 4.3 и 4.4).

Рис. 4.3. ER -диаграмма для экземпляров сущностей и связей

Здесь П1, П2, П3, П4 различные преподаватели, а Базы данных, Основы программирования, Информатика, Математика – названия дисциплин.

Рис. 4.4. ER -диаграмма классов

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

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

Чаще всего встречаются бинарные связи, т. е. связи между двумя сущностями, но могут быть и связи более высокого порядка, когда по смыслу неразрывно соединены несколько сущностей. Связь «Преподаватель читает дисциплину» является бинарной, она связывает только две сущности, а связь «Преподаватель читает дисциплину для специальности» является тройственной, она связывает три сущности, и т. д. Сначала рассмотрим наиболее простые и распространенные бинарные связи.

4.8. Бинарных связи и классы принадлежности. Случай 1 – связь 1:1, КП обеих сущностей обязательный

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

- один к одному (1:1);

- один ко многим (1:М или М: 1);

- многие ко многим (M:N).

Связь 1:1 означает, что каждый экземпляр первой сущности может быть связан только с одним экземпляром второй сущности и наоборот.

Связь 1 :М означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, а каждый экземпляр второй сущности может быть связан только с одним экземпляром первой сущности.

Связь M:N означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности и наоборот.

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

Для отображения характеристик связи на диаграмме может ис­пользоваться, например, символ «точка». Если точка внутри прямоугольника, то соответствующая прямоугольнику сущность имеет обязательный класс принадлежности. Если вне прямоугольника, то необязательный класс принадлежности. Цифры или буквы рядом с точками указывают на степень связи. Сочетание трех типов связей с двумя классами принадлежности дают возможность описания множества различных вариантов связей в предметной области. Чтобы лучше усвоить введенные понятия, рассмотрим на примерах некоторые случаи и для них построим ER -диаграммы.

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

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

Рис. 4.5. Отношение сущностей и ER -диаграммы для случая 1

Здесь Д1, Д2, ДЗ, Д4 - названия дисциплин. КП, КД - ключи сущностей соответственно Преподаватель и Дисциплина.

Дата добавления: 2014-01-06