Упражнения к разделу

Упражнение 1. На рис. 3 показаны два отношения — Accounts ("счета") и Customers ("клиенты"), — которые могут служить частью базы данных банка. Назовите или изобразите следующее:

атрибуты каждого отношения;

кортежи каждого отношения;

компоненты одного кортежа из каждого отношения;

реляционную схему каждого отношения;

схему базы данных;

домен, соответствующий каждому атрибуту;

альтернативный способ представления каждого отношения.

acciNo	type	balance
12345	savings	12000
23456	checking	1000
34567	savings	25

Отношение Accounts

firstName	lastName	id No	account
Robbie	Banks	901-222	12345
Lena	Hand	805-333	12345
Lena	Hand	805-333	23456

Отношение Customers

Рис.3. Два отношения банковской базы данных

!! 2. Каким числом способов (зависящих от порядка следования атри­бутов и кортежей) может быть представлен экземпляр отношения, если он включает:

три атрибута и три кортежа (подобно отношению Accounts, изображенному на рис. 3)?

четыре атрибута и пять кортежей?

п атрибутов и т кортежей?

От ER-диаграмм к реляционным схемам

Рассмотрим процесс создания новой базы данных, подобной рассматриваемой на­ми базе данных о кинофильмах. На первой стадии процесса, связанной с проектиро­ванием, необходимо сформулировать следующие вопросы и найти ответы на них: ка­кая информация должна быть представлена в базе данных; каким образом элементы данных соотносятся друг с другом; какие ограничения (например, ключи и условия ссылочной целостности) должны быть введены и т.д. Эта стадия может протекать в течение длительного времени, пока все альтернативные варианты не будут рассмот­рены и сопоставлены, а все мнения — учтены и согласованы.

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

На практике, однако, зачастую проще приступить к проектированию, пользуясь ER-или другой аналогичной моделью, осуществить задуманное, а затем преобразовать ре­зультат в реляционную модель. Основной довод в пользу такого подхода связан с тем, что реляционная модель, основанная на единственном понятии "отношения", а не на совокупности различных взаимодополняющих понятий (таких как "множество сущно­стей" и "связь" в ER-модели), обладает определенными ограничениями в смысле гиб­кости, которые проще "обойти" уже по завершении начальной стадии проектирования.

В первом приближении процесс "превращения" ER-диаграммы в реляционную схему довольно прямолинеен:

преобразовать каждое множество сущностей в отношение с тем же набором атрибутов;

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

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

Слабые множества сущностей (weak entity sets) не могут быть преобразованы в отношения непосредственно.

Связи isa и подклассы (subclasses) требуют специального подхода.

Иногда целесообразно объединить в составе одного отношения два других — например, отношение для множества сущностей Е с отношением для связи ти­па "многие к одному", которая соединяет Е с другими множествами.

От множеств сущностей к отношениям

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

Схемы и экземпляры

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

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

Пример 1. Рассмотрим три множества сущностей — Movies ("кинофильмы"), Stars ("актеры") и Studios ("киностудии") — ER-диаграммы, которая в том же виде воспроизведена на рис. 4. Атрибутами множества Movies, например, являются title ("название"), year ("гол производства"), length ("продолжительность") и filmType ("тип пленки"). Отношение Movies может выглядеть так, как оно пред­ставлено на рис. 1.

Рис. 4. ER-диаграмма базы данных о кинофильмах

Теперь обратимся к другому множеству сущностей, Stars. Оно обладает двумя атрибутами, пате ("имя") и address ("адрес"). Схема соответствующего отноше­ния Stars может быть представлена как Stars (name, address), а его типичный экземпляр — как

name	address
Carrie Fisher	123 Maple St., Hollywood
Mark Hamill	456 Oak Rd., Brentwood
Harrison Ford	789 Palm Dr., Beverly Hills

Замечание по поводу качества примеров данных :—)

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

От ER-связей к отношениям

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

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

2. Если связь обладает собственными атрибутами, они также вводятся в набор ат­рибутов отношения для этой связи.

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

Пример 3.2. Рассмотрим связь Owns ("владеет") ER-диаграммы рис.4, со­единяющую множества сущностей Movies ("кинофильмы") и Studios ("киностудии"). В схему отношения Owns для связи Owns мы введем ключевые атрибуты множеств сущностей, соединяемых связью Owns: title ("название") и year ("год производства") множества Movies и пате ("название") — множества Studios (наименование атрибута пате для ясности уместно изменить, скажем, на studioName). Схема отношения Owns примет следующий вид:

Owns(title, year, studioName).

А так может выглядеть типичный экземпляр отношения Owns:

title	year	studioName
Star Wars	1977	FOX
Mighty Ducks	1991	Disney
Wayne's World	1992	Paramount

Пример 3.3. Связь Stars-in ("актеры-участники") ER-диаграммы рис. 4 подобным образом может быть преобразована в отношение с атрибутами title и year (служащими ключом для множества сущностей Movies) и атрибутом starName (аналогичным ключевому атрибуту поте множества Stars). На рис. 5 показан про­стой экземпляр отношения stars-in.

Поскольку названия кинофильмов в столбце title на рис.5 выглядят как уни­кальный ключ, может показаться, что атрибут year избыточен. Однако, если в базу дан­ных попадет информация о нескольких фильмах с одним и тем же названием (таким, на­пример, как "King Kong"), атрибут year приобретет существенное значение, поскольку позволит определить, в каких именно версиях фильма снимался тот или иной актер.

title	year	starName
Star Wars	1977	Carrie Fisher
Star Wars	1977	Mark Hamill
Star Wars	1977	Harrison Ford
Mighty Ducks	1991	Emilio Estevez
Wayne's World	1992	Dana Carvey
Wayne's World	1992	Mike Meyers

Рис. 5. Экземпляр отношения Stars-in

Рис. 6. Связь Contracts

Пример 3.4. Многосторонние связи также могут быть легко преобразованы в отноше­ния. Рассмотрим четырехстороннюю связь Contracts ("контракты") диаграммы рис. 2.6, вновь воспроизведенной на рис. 6. Связь охватывает сущности "актер" (Stars), "кинофильм" (Movies) и две сущности "киностудия" (Studios). Роль Studio-of-Star отображает долговременный контракт актера с некоторой студией, a Producing-Studio — контракт, оговаривающий условия участия актера в съемках фильма, выпус­каемого какой-либо другой студией. Связь Contracts представляется в виде отношения Contracts, схема которого состоит из следующих ключевых атрибутов:

1. атрибута starName, соответствующего ключу пате множества Stars;

2. атрибутов title и year ключа множества Movies;

3. атрибута studioOfstar, содержащего название студии-"владельца" актера; напомним, что атрибут "название" мы выбрали в качестве ключа множества сущностей Studios;

4. атрибута producingStudio, содержащего название студии, которая выпус­кает фильм с участием приглашенного актера.

5. Схема отношения Contracts, таким образом, примет вид

6. Contracts(starName, title, year, studioOfStar, producingStudio).

7. Обратите внимание — мы совершенно свободны в выборе имен атрибутов отно­шения: так, мы постарались избежать использования имени name, поскольку в про­тивном случае было бы далеко не очевидно, на какой объект оно указывает — на имя актера или на название киностудии (тем более, что схема предусматривает задание двух атрибутов-названий киностудии). Кроме того, если рассматривать вариант мно­госторонней связи Contracts с собственными атрибутами — такой, например, как изо­браженный на диаграмме рис. 2.7, — эти атрибуты (в данном случае, salary) пришлось бы ввести и в схему отношения Contracts.