2.9 Литература к главе 2

Основополагающей работой по Е/К-моделям является [3]. В книгах 4] н [1] содержится обширный материал по проектированию в модели сущности-связи и в других полезных моделях.

Учебник [2] по ODL подготовила группа Object Data Management Group (ODMG). Доступ к новейшим материалам по ODL этой организации можно получить по адресу info@odnig.org и на Web-странице http: www.odmg.org.

1. Baiini, С, S. Ceri. and S. В. Navathe, Concephiol Database Design, Benjamin/Cummings, Redwood City, CA, 1992.

2. Cattell. R. C. G. (ed.), Г/ie Object Database Standard: ODMC-93 Release I 2, Morgan-Kaufmann, San Francisco, 1996.

3. Chen. P. P., The entity-relationship model: toward a unified view of data , ACM Trans, on Database Systems 1:1, pp. 9-36, 1966.

4 El Masri, R. and S. B. Navathe, Fundamentals of Database Systems, Benjamin Cummings, Menlo Park, 1994

Глава 3

Реляционные модели данных

Методы моделирования данных ODL и E/R, рассмотренные в главе 2. вполне подходят для описания структуры данных, однако современные реализации БД почти всегда базируются на другой модели - реляционной. Ее ценность заключается в том, что она основана на единственном понятии моделирования данных - отношении , двумерной таблице, в которой собраны данные. В главе 5 будет показано, как реляционная модель поддерживает язык программирования очень высокого уровня - SQL, позволяющий писать простые и мощные программы, которые манипулируют далиыми, хранящимися в отношениях.

Тем не менее иногда бывает легче проектировать БД с помощью моделей, изученных в главе 2. Поэтому необходимо знать, как перевести проекты из ODL или E/R в отношения. Реляционная модель имеет собственную теорию, которая часто называется нормализацией отношений и основана на функциональных зависимостях , расширяющих понятие ключ , неформально рассмотренное в разделе 2.5. L Теория нормализации часто облегчает выбор отношемий, представляющих конкретный проект БД.

3.1 Основы реляционной модели

Реляционная модель обеспечивает единственный способ представления данных в виде двумерной таблицы, называемой отношением. Пример отношения приведен на рис. 3 1.

Рис. 3.1. Отношение Movie

Это отношение имеет имя Movie и предназначено для хранения такой же информации, которая содержалась в простом определении ODL класса Movie на рис. 2.4 из примера 2.1 и воспроизводится здесь как рис. 3.2. Заметим, что данное определение не является окончательным определением класса Movie и имеет только атрибуты title, year, length и filmType.

1) interface Movie {

2) attribute string title;

3) attribute integer year;

4) attribute integer length;

5) attribute enumeration (color, blackAndWhite} filmType;

Рис. 3.2. О01-описомие классе Movie

3.1.1 Атрибуты

в верхней части рис. 3.1 расположены атрибуты title, year, length и filmType. Атрибуты отношения служ;гг именами его столбцов. Обычно атрибут отражает смысл того, что записано в лежащем иод ним столбце. Например, в столбце с атрибутом length указана длительность различных фильмов в минутах.

Заметим, что атрибуты отношения Movie на рис. 3.1 соответствуют эле.ч<снтам структуры, называемым атрибугами в определении ODL на рис. 2.4. Такой подход к выбору этрмбутов для отношения всгречается довольно часто. Однако не существует общего требования, чтобы атрибуты отношения соответствовали всем отдельным компонентам ODL или E/R-опнсания данных.

3.1.2 Схемы

Имя отношения н .множество его атрибутов образуют схему этого отношения. Схема обозначается и-менем отношения, за которым следует заключенный в Kpyi-лые скобки список его атрибутов. Схема отношения Movie на рис. 3.1:

Movie(title. year, legth. filmType)

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

В реляционной модели проект состоит из одной или нескольких схем отноше-1ГИЙ. Множест1Ю схем отношения в проекте называется схемой реляционной БД или просто схемой БД.

3.1.3 Кортежи

строки отношения, отличные от заглавной строки, состоящей из атрибутов, называются кортежтт. Кортеж содержит один компонент для каждого атрибута отношения. Например, первый из трех кортежей иа рис. 3.1 имеет четыре компонента Star Wars. 1977, 124 II color для атрибутов title, year, legth и filmType соответственно. При записи кортежа отдельно от отношения он обычно заключается в круглые скобки и его компоненты разделяются запятыми. Например.

(Star Wars, 1977, 124, color)

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

Можно поаумать. что кортежи представляют объекты, а отношения, которым pif жатшсс. 1>1мшно Tiii6crpnT дело в приведенном примере отно-