Мартьянова А.Е. Базы данных и знаний. Учебное пособие

Подождите немного. Документ загружается.

Мартьянова А.Е. Базы данных и знаний 21

3. Назначьте ключевой атрибут для каждой сущности предмет-

ной области «Учебный процесс».

. Установите связи между сущностями, выясните тип каждой

связи М, М:М, обязательная, необязательная) между сущностями

для предметной области «Учебный процесс».

. Оформите отчет по работе.

(1:1, 1:

Мартьянова А.Е. Базы данных и знаний 22

Работа II. Инфологическо рование (продол-

жение). Даталогическ е. Получение

реляционной схемы и

Представим предметную «Учебный процесс» как взаимо-

действие следующих сущнос тудент» сдает экзамен или

зачет по некоторому предмет сно «Учебному плану». В учебном

процессе участвует «Препод осуществляет чтение

учебного курса и контроль зн бном процессе так-

же участвует «Кафедра», которая организовывает работу «Преподавате-

ля». Обучен

ногруппни-

ками.

На основании ед асти выделим следующие

сущности модели «с ity Relationship» - ER-модели):

«Студент», «Группа даватель», «Учебный план» и

изобразим их в вид ик, в верх-

ней части которого записано атри-

буты, приче

ием) – см.

рис. I.10 – I.14.

Следует отметить, что для ости устанавливается свой

код – ключевой атрибут, одн ктеризующий сущность. На-

пример, обычный номер сту может выполнять роль

ключа, поскольку для каждой и номера могут повторяться. Для

преподавателя атрибут Табел желательно брать в качестве

ключевого,

преподава-

телю присваивается уникальный номер идентификации.

е модели

ое проектировани

граммы з ER-диа

область

тей: каждый «С

у согла

аватель», который

аний «Студента». В уче

ие «Студента»

ведется в «Группе» совместно с од

изучения пр метной обл

ущность-связь» («Ent

о», «Кафедра», «Преп

е графических обозначений (прямоугольн

имя сущности, а ниже перечисляются

м ключевые атрибуты помечаются

подчеркиван

каждой сущн

означно хара

дента в группе не

группы эт

ьный номер не

поскольку ведется электронный учет

и каждому

СТУДЕНТ

Код студента

Номер зачетной книжки

Фамилия

Имя

Отчество

Год рождения

Адрес

Домашний телефон

Балл при поступлении

Рис. I.10. Определение сущности «Студент» в модели ER

Мартьянова А.Е. Базы данных и знаний 23

ГРУППА

Код группы

Обозначение группы

К дентов оличество сту

Средний балл в группе при поступлении

Рис. I.11. щности «Группа» в модели ER

КАФЕДРА

Определение су

Код кафедры

Название кафедры

Телефон

Заведующий

Рис. I.12. Определение сущности «Кафедра» в модели ER

ПРЕПОДАВАТЕЛЬ

Код преподавателя

Табельный номер

Фамилия

Имя

Отчество

Домашний адрес

Домашний телефон

Должность

Ученая степень

Ученое звание

Рис. I.13. Определение сущности «Преподаватель» в модели ER

УЧЕБНЫЙ ПЛАН

Код учебного плана

Наименование предмета

Программа

Часы

Вид занятия

Семестр

Вид сдачи

Оценка

Дата сдачи

Рис. I.14. Определение сущности «Учебный план» в модели ER

Мартьянова А.Е. Базы данных и знаний 24

Для реализации дополнительных функций базы может потребо-

ваться введение дополнительных атрибутов, например, номера зачетной

книжки и домашнего телефона студента, домашнего адреса и домашнего

телефона преподавателя, должности преподавателя, рабочей программы,

даты сдачи экзамена (зачета) и т.д.

Будем считать для простоты все связи обязательными. Между вы-

деленными сущностями можно выделить, например, следующие

связи:

1. «Студенты» объединены в «Группы» (связь М:1).

2. Работу «Преподавателей» организуют «Кафедры» (связь М:1).

3. «Преподаватели» преподают предметы согласно «Учебному

плану» (связь 1:М).

4. «Студенты» сдают предметы по «Учебному плану» (связь М:М).

Покажем теперь эти связи между всеми сущностями графически с

использованием нотации POWER DESIGNER.

Связь между сущностями «Студент» и «Группа» представлена

на

рис. I.15. Будем считать для простоты, что все студенты обязательно

объединены в группы.

СТУДЕНТ

Код студента

Номер зачетной

ГРУППА

Код группы

Количество студентов

Средний балл при поступлении

Обозначение группы

Объединяет

Объединение в группы

книжки

Фамилия

Имя

Отчество

Год рождения

Адрес

Домашний телефон

Входит в состав

Рис. I.15. Моделирование связи между сущностями «Студент» и «Группа»

Аналогичным образом выглядит связь «Преподаватель» и «Кафед-

ра». Изобразите ее самостоятельно. Для простоты предлагается считать,

что каждый преподаватель обязательно работает на какой-нибудь из ка-

федр.

Мартьянова А.Е. Базы данных и знаний 25

На рис. I.16 показана версия полной ER-модели для базы данных

«Учебный процесс».

ГРУППА

Код групп

Кол

алл при поступлении

Обозначение группы

ичество студентов

Средний б

СТУДЕНТ

Код студента

Номер зачетной книжки

Фамилия

Имя

Отчество

Год рождения

Адрес

Домашний телефон

Балл при поступлении

КАФЕДРА

Код кафедры

Заведующий

Название кафе ры

Телефон

ПРЕПОДАВАТЕЛЬ

Код преподавателя

Табельный номер

Фамилия

Имя

Отчество

Домашний адрес

Домашний телефон

Должность

Ученая степень

Ученое звание

УЧЕБНЫЙ ПЛАН

Код учебного плана

Наименование

предмета

Программа

Часы

Вид занятия

Семестр

Вид сдачи

Оценка

Дата сдачи

Рис. I.16. Инфологическая модель «Учебный процесс»

Даталогическое проектирование

Следующий этап проектирования – построение даталогической

модели [10]. В рассматриваемом случае задача этого типа – преобразова-

ние ER-диаграммы в реляционную схему.

В реляционных БД даталогическое или логическое проектирование

приво

ункциональные зависимо-

сти м

е значений неко-

торых атрибутов.

дит к разработке схемы БД, то есть совокупности схем отношений,

которые адекватно моделируют абстрактные объекты предметной облас-

ти и семантические связи между этими

объектами. Основой анализ кор-

ректности схемы являются так называемый ф

ежду атрибутами БД. Некоторые зависимости между атрибутами

отношений являются нежелательными из-за побочных эффектов и ано-

малий, которые они вызывают при модификации БД. При этом под про-

цессом модификации БД мы понимаем внесение новых данных в БД или

удаление

некоторых данных из БД, а также обновлени

Мартьянова А.Е. Базы данных и знаний 26

Однако этап логического или даталогического проектирования не

заканчивается проектированием схемы отношений. В общем случае в ре-

зультате выполнения этого этапа должны быть получены следующие ре-

•

выбранной СУБД.

•

троенную схему в терминах

выбра

чающая определение всех

инфор

и, а логическими понятиями

, связанными со структурой базы

путям

Например, частые обращения к совместно обраба-

зультирующие документы [10]:

Описание концептуальной схемы БД в терминах выбранной СУБД.

• Описание внешних моделей в терминах

Описание декларативных правил поддержки целостности базы

данных.

• Разработка процедур поддержки семантической целостности базы

данных.

• Однако перед тем как описывать пос

нной СУБД, нам надо выстроить эту схему.

• Мы должны построить корректную схему БД, ориентируясь на ре-

ляционную модель данных.

Модель предметной области разрабатываемой системы должна

быть представлена в терминах модели

данных концептуального уровня

выбранной конкретной СУБД. Эту стадию называют логическим (или

даталогическим) проектированием базы данных, а ее результатом явля-

ется концептуальная схема базы данных, вклю

мационных элементов (единиц) и связей, в том числе задание ти-

пов, характеристик и имен.

Хотя даталогическое проектирование оперирует не физическими

записям

данных, тем не менее особенности представления данных, правила и

языки агрегирования и манипулирования данными имеют определяющее

влияние. Не все виды связей, например, «многие ко многим», могут быть

непосредственно отображены в логической модели.

Кроме того, может быть много вариантов отображения инфологи-

ческой модели предметной области в даталогическую

модель базы. Здесь

следует учитывать влияние двух следующих значимых факторов, свя-

занных с практикой разработки базы данных.

Во-первых, связи предметной области могут отображаться двумя

и: как декларативным – в логической схеме, так и процедурным –

отработкой связей через программные модули, обрабатывающие (связы-

вающие) соответствующие хранимые данные.

Во-вторых, существенным фактором может оказаться

характер об-

работки информации.

тываемым данным, очевидно, предполагают их совместное хранение, а

Мартьянова А.Е. Базы данных и знаний 27

данные (особенно большого объема), к которым обращаются редко, це-

лесообразно хранить отдельно от часто используемы

х.

ся множественным,

то для

еется несколько возможных уникаль-

спользуемый. Если в со-

став цов

перви добавляется копия уникального идентификатора сущ-

ности

зи «многие-к-одному

» и «один-к-одному» становятся внеш-

ними есть создается копия уникального идентификатора с

конца

. Это дела-

ется в ециального дополнительного отношения, которое свя-

зано

исутствуют подтипы, то воз-

можн .

Рассмотрим по шагам общий подход к построению реляционной

базы данных на основе инфологической модели, представленной ER-

диаграммой [7].

Получение реляционной схемы из ER-диаграммы

1. Каждая простая сущность превращается в таблицу (отношение).

Имя сущности становится именем таблицы.

2. Каждый атрибут

становится возможным столбцом с тем же име-

нем. Столбцы, соответствующие необязательным атрибутам, могут со-

держать неопределенные значения; столбцы, соответствующие обяза-

тельным атрибутам, – не могут. Если атрибут являет

него строится отдельное отношение.

3. Компоненты уникального идентификатора сущности превраща-

ются в первичный ключ. Если им

ных идентификаторов

, выбирается наиболее и

уникального идентификатора входят связи, то к числу столб

чного ключа

, находящейся на дальнем конце связи (этот процесс может про-

должаться рекурсивно). Для именования этих столбцов используются

имена концов связей и/или имена сущностей.

4. Свя

ключами. То

связи «один», и соответствующие столбцы составляют внешний

ключ.

5. Разрешение связей типа «многие-ко-многим». Так как в реляци-

онной модели данных поддерживаются между отношениями только свя-

зи типа «один-ко-многим», а в ER- модели

допустимы связи «многие-ко-

многими», то необходим специальный механизм преобразования, кото-

рый позволит отразить множественные связи, неспецифические для ре-

ляционной модели, с помощью допустимых для нее категорий

ведением сп

с каждым исходным связью «один-ко-многим», атрибутами этого

отношения являются первичные ключи

связываемых отношений.

6. Индексы создаются для первичного ключа (уникальный индекс),

а также внешних ключей и тех атрибутов, которые будут часто исполь-

зоваться в запросах.

7. Если в концептуальной схеме пр

ы два варианта

Мартьянова А.Е. Базы данных и знаний 28

Все подтипы хранятся в одной таблице, которая создается для са-

мого внешнего супертипа, а для подтипов создаются представления. В

таблицу добавляется по крайней мере один столбец, содержащий код

ТИПА, и он становится частью первичного ключа.

Во втором случае для каждого подтипа создается отдельная табли-

ца (для более нижних – представления) и для

каждого подтипа первого

уровня супертип воссоздается с помощью представления UNION (из всех

табли ыбираются общие столбцы – столбцы супертипа).

е соответствующей связи.

ирующие внешние ключи не относятся к одному до-

мену,

сли

степень бинарной связи равна 1:1 и класс принадлежности

обеих является обязательным, то требуется только одна таб-

лица. быть ключ любой из двух

сущностей.

, а другой – необязательным, то

необходимо

м ключом для соответствующей таблицы. Кроме того,

ключ

енную для

сущности с

принадлежности

ни

одной су

блицах), и одной для

ц подтипов в

8. Если остающиеся внешние ключи все принадлежат одному до-

мену, то есть имеют общий формат, то создаются два столбца: иденти-

фикатор связи и идентификатор сущности. Столбец идентификатора свя-

зи используется для различения связей

. Столбец идентификатора сущно-

сти используется для хранения значений уникального идентификатора

сущности на дальнем конц

Если результ

то для каждой связи, покрываемой дугой исключения, создаются

явные столбцы внешних ключей.

Правила разрешения связей ER-диаграммы

Существует шесть простых правил генерации отношений [15].

Правило 1.

сущностей

Первичным ключом этой таблицы может

Правило 2.

Есл степень бинарной связи равна 1:1 и класс принадлежности

одной сущности является обязательным

построение двух таблиц. Под каждую

сущность необходимо

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

служить первичны

сущности, для которой класс принадлежности является необяза-

тельным, добавляется в качестве атрибута в таблицу, выдел

обязательным классом принадлежности.

Правило 3.

Если степень бинарной связи равна 1:1 и класс

из щностей не является обязательным, то необходимо использо-

вать три таблицы: по одной для каждой сущности (ключи сущностей

служат в качестве первичных в соответствующих та

Мартьянова А.Е. Базы данных и знаний 29

связи , будет

иметь од

ой сущности является обязательным, то достаточным является

испол ван

о в

первичным

ключом соответствующей таблицы, и

одной на иметь среди своих атрибутов

ключи обеих сущностей.

равило 6.

сли степень бинарной связи равна M:M, то для хранения данных

необходимы три таблицы: по одной для каждой сущности, причем ключ

каждой сущности используется в качестве первичного ключа соответст-

вующей таблицы, и одной таблицы для

связи. Последняя таблица должна

иметь числе своих атрибутов ключи обеих сущностей.

ОНТРОЛЬНЫЕ ВОПРОСЫ к заданию

. Сколько сущностей содержит ER-модель для БД «Учебный

процесс»? Перечислите их.

. Какие бинарные связи наблюдаются в ER-модели для БД

«Учебный процесс»? Перечислите их.

. Рассмотрите по шагам общий подход к построению реляци

онной базы данных на основе инфологической модели, представленной

ER-диаграммой.

. Сформулируйте шесть правил генерации отношений при ис-

пользовании исходных бинарных связей между сущностями.

ециального преобразова-

м?

. Среди своих атрибутов таблица, выделяемая для связи

по ному ключу каждой сущности.

Правило 4.

Если степень бинарной связи равна 1:M и класс принадлежности

M-связн

ьзо ие двух таблиц (по одной на каждую сущность), при усло-

вии, чт ключ каждой сущности служит в качест е первичного

ключа

для соответствующей таблицы. Помимо этого, ключ 1-связной сущности

должен быть обавлен как атрибут в таблицу, отводимую n-связной

сущности.

Правило 5.

Есл степень бинарной связи равна 1:M и класс принадлежности

M-связной сущности является необязательным, то необходимо формиро-

вание трех таблиц – по одной для каждой сущности, причем ключ каж-

дой сущности служит

таблицы для связи. Связь долж

5. Рассмотрите все бинарные связи ER-диаграммы «Учебный

процесс» типа M:M. Есть ли необходимость сп

ния связей согласно сформулированным правила

Мартьянова А.Е. Базы данных и знаний 30

6. Рассмотрите все бинарные связи ER-диаграммы «Учебный

проце

ИЕ на проектирование БД «Учебный процесс»

диагр

а» типа 1:M

имеет необязательный класс принадлежности M-

связно

сс» типа 1:M. Есть ли необходимость специального преобразова-

ния связей согласно сформулированным правилам?

ЗАДАН

1. Рассмотрите бинарную связь типа M:M между сущностями

«Студент» и «Учебный план». Попытайтесь разрешить ее введением

специального дополнительного отношения согласно изложенному пра-

вилу 6.

2. Рассмотрите все

бинарные связи типа 1:M обязательного

класса принадлежности M-связной сущности: между сущностями

«Группа» и «Студент», между сущностями «Кафедра» и «Преподава-

тель», между сущностями «Преподаватель» и «Учебный план» ER-

аммы «Учебный процесс». Разрешите эти связи согласно правилу 4.

3. Изобразите ER-модель БД «Учебный процесс».

4. Предположите, что связь между сущностями «Студент» и

«Групп

й сущности. По какому правилу разрешается такая связь? Попы-

тайтесь описать ее.

5. Оформите отчет по работе.