Кудравцев Создание баз данных 2010

Рис. 1.21. Переход на «физический» уровень представления данных

При выборе пункта меню:

Database  Choose database…

появится окно выбора целевой СУБД (рис. 1.22), в качестве кото-

рой используется MS Access 2000/2002/2003.

Рис. 1.22. Выбор целевой СУБД

Этап 3. Создать реляционную схему данных путем выбора пункта меню:

Tools  Forward Engineer  Shema Generation…

В этом случае появляется окно генерации реляционной схемы

(рис. 1.23).

31

Рис. 1.23. Окно генерации реляционной схемы

При нажатии на кнопку «Generate…» появится окно соединения с ядром СУБД MS Access, в котором следует указать (рис. 1.24):

User Name: Admin

Password: <Пусто>

Database: D:\Books\Exams.mdb

System Database: D:\Books\Exams.mdb (место расположения на диске базы данных Exams.mdb)

Рис. 1.24. Окно соединения с ядром СУБД MS Access

32

После заполнения всех указанных полей следует нажать на кнопку «Connect» и произойдет генерация реляционной схемы данных. Результаты генерации выводятся в виде отчета, который можно впоследствии проанализировать.

Этап 4. Открыть в MS Access файл Exams.mdb и убедиться в том что там появились четыре таблицы соответствующие четырем сущностям ER-диаграммы (рис. 1.25).

Рис. 1.25. База данных Exams.mdb

На рис. 1.26 представлена схема данных, используемая в MS Access. Сравнивая ее с ER-диаграммой на рис. 1.21, легко обнаружить полную аналогию.

Рис. 1.26. Схема данных Exams.mdb

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

33

Примеры ER-диаграмм

Рассмотрим примеры построения ER-диаграмм для некоторых предметных областей.

ER-диаграмма «Обменный пункт валюты»

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

▪клиент;

▪валюта;

▪валютная операция;

▪курсы валют.

ER-диаграмма представлена на рис. 1.27.

Рис. 1.27. ER-диаграмма обменного пункта валют

34

Здесь следует обратить внимание на то, что между сущностями «Валютная операция» и «Валюта» установлено два отношения «один ко многим», так как в валютной операции участвует два вида валют. Для того чтобы отличить идентификатор входящей валюты от идентификатора исходящей, используется понятие «имя роли», которое является синонимом атрибута внешнего ключа. Для задания имени роли следует дважды щелкнуть соответствующей связи, в результате чего появится окно аналогичное рис. 1.19, в котором следует перейти на вкладку Rolename и ввести в соответствующее поле имя роли (на рис. 1.28 Rolename: ID_Valute_OUT). Для ото-

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

стного меню выбрать: Entity Display  Rolename Attribute.

В сущности «Курс валют» хранится информация о изменениях курсов валют по отношению к некоторой базовой валюте, как правило, к доллару США.

Рис. 1.28. Задание имени роли внешнего ключа

ER-диаграмма «Родственные отношения»

Рассмотрим генеалогическое дерево большой семьи, например династии Романовых.

35

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

▪Родственник (член семьи);

▪Тип родства;

▪Родственное отношение.

ER-диаграмма представлена на рис. 1.29.

Для учета родственных отношений используются два поля

ID_Type_Young_Old и ID_Type_Old_Young, в которых содержится отношение между младшим и старшим родственниками (например, сын) и между старшим и младшим родственниками (например, отец). Здесь, как и в предыдущем примере, используется понятие «имя роли».

Рис. 1.29. ER-диаграмма родственных отношений

ER-диаграмма «Теннисный турнир»

Рассмотрим теннисный турнир, например «Кубок Кремля». В базе данных должна храниться информация о результатах сыгран-

36

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

▪Игрок (теннисист);

▪Игра;

▪Стадия игры (1/8, 1/4, 1/2, Финал).

ER-диаграмма представлена на рис. 1.30.

Для учета пары игроков используются атрибуты ID_Gamer1 и ID_Gamer2, а для учета результата — Ball1 и Ball2. Кроме того, существует атрибут Winner, который принимает значение или 1 или 2, в зависимости от того, кто выиграл: первый или второй игрок. Однако это поле является избыточным, так как победитель определяется по анализу пары атрибутов Ball1 и Ball2, но в ряде случаев оно оказывается полезным.

Рис. 1.30. ER-диаграмма теннисного турнира

ER-диаграмма «Библиотека»

Рассмотрим учет книжного фонда и выдачу книг в библиотеке, например в библиотеке МИФИ. В базе данных должна храниться информация о так называемых концептуальных книгах и физиче-

37

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

▪Читатель;

▪Концептуальная книга (книга);

▪Физическая книга (том);

▪Формуляр;

▪Операция (выдача, возврат, списание, приход);

▪Автор;

▪Издательство.

ER-диаграмма представлена на рис. 1.31.

Так как у книги может быть несколько авторов, то между сущностями «Автор» и «Книга» устанавливается связь «многие ко многим». Для преобразования ее к типу «один ко многим» можно воспользоваться средствами ERWin.

Рис. 1.31. ER-диаграмма учета книг в библиотеке

Для этого необходимо:

1.Перейти на физический уровень представления,

2.Выделить связь «многие ко многим» и нажать правую кнопку мыши,

38

3. Выбрать пункт меню ―Create Association Entity‖. В результате запустится мастер создания ассоциированной сущности, который предложит дать название ассоциированной сущности (в данном случае был дано название «Автор_Книга»), и появится соответствующая сущность. Результаты представлены на рис. 1.32.

Рис. 1.32. ER-диаграмма учета книг в библиотеке с ассоциированной сущностью «Автор_Книга»

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

1.Что позволяет обеспечить трехуровневая модель системы управления базой данных, предложенная ANSI?

2.Что собой представляет функциональный подход к выбору состава и структуры предметной области?

3.Каким образом отражаются связи между объектами в иерархической модели данных?

4.Что означает связь «многие ко многим»?

5.Чем отличается логический уровень представление ER-диаграммы от физического уровня в редакторе ERWin?

6.Построить концептуальную модель предметной области «Бронирование авиабилетов».

39

Глава 2. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ

Реляционная модель данных была предложена Е. Коддом, известным американским специалистом в области баз данных. Основные концепции этой модели были впервые опубликованы в

1970 г. в статье «A Relational Model of Data for Large Shared Data Banks» (CACM, 1970, Vol. 13, № 6). Реляционная модель позволила решить одну из важнейших задач в управлении базами данных — обеспечить независимость представления и описания данных от прикладных программ. Поэтому после опубликования работ Кодда начались активные исследования по созданию реляционной системы управления базами данных. К основным достоинствам реляционного подхода к управлению базой данных следует отнести:

▪наличие небольшого набора абстракций, которые позволяют сравнительно просто моделировать бóльшую часть распространенных предметных областей и допускают точные формальные определения, оставаясь интуитивно понятными;

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

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

Внастоящее время реляционные СУБД остаются одними из наиболее распространенных, несмотря на некоторые присущие им недостатки.

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

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

40