Программирование >>  Реляционные базы данных 

1 ... 22 23 24 [ 25 ] 26 27 28 ... 125


пете

slreei : сЛу

Carrie Fisher 123 Maple St. I Hollywood

Carrie Fisher Mark Hamill

5 Locust Ln. I Malibu

456 Oak Rd.

Brentwood

Harrison Ford 789 Palm Dr. Beverly Hills

Рие. 3.8. Допущение множеаео адресов

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

Атомарные значения: технический дефект или характерное свойство?

Кажется, что реляционная модель создает проблемы, а ODL является более гибкой, допускал структурированные значения в качестве свойств. Конечно, можно вообще игнорировать реляционную модель или считать ее примггтиБным понятием, которое вытесняется более элегантными объектно-ориентированными подходами типа ODL. Однако реальность такова, что на рынке доминируют СУБД, основанные именно на реляционной модели. Одна из причин в том, что простота модели позволяет применять для запросов к БД элегантные и мощные языки программирования. В разделах 4.1 и 4.2 будут введены абстрактные языки программирования: реляционная алгебра и Datalog. Возможно, самое важяое значение имеет их внедрение в SQL. стандартный язык, применяемый в большинстве современных СУБД.

Пример 3.5. Допустим, что в определение класса Star добавляется атрибут birthdate и используется определение, описанное на рис. 3.9.

Interface Star {

attribute string name; attribute Set<

Struct Addr {string street, string city) > address; attribute Date birthdate;

Рис. 3.9 Кинозвезды с множеавом адресов и дотами рождения

Допустим также, что у Кэрри Фишер есть еше дом на побережье, а яве другие кинозвезды, названные на рис. З.б, имеют только по одному дому. Тогда можно создать два кортежа с атрибутом name, совпадающим с Came Fisher , как показано иа рис. 0.8. Другие кортежи остаются такими же, как на рис. 3.6. □



Мы просто добавили в рис. 3.7 атрибут birthdate типа Date - один из атомарных гнпон в ODL. Этот атрибут может принадлежать отношению Star, схема которого теперь выглядит так;

Star(name, street, city, birttidate)

Внесем eiuc одно изменение в данные на рис. 3.8. Поскольку множество адресов может быть иусты.м, предположи-м, что в БД нет адреса Харрисона Форда (Harrison l-ord). Результат Такого изменения показан на рис 3.10.

пате

Carrie Fislier Carrie Fistier Mark Hamill

street

city

! birthdate

; 123 Maple St. I 5 Locust Ln. : 456 Oal< Rd.

j Hollywood i Malibu

Brentwood

9/9/99 9/9/99 8/8/BB

Рис. 3.10. Добоегение дот рождений

У этого отношения два недостатка. Во-первых, дата рождения Кэрри Фишер повторяется дважл!,!. следовательно, в отношении присутствует избыточная инфор-.мзиия. За.метим, что ее имя тоже повторяется, но это повторение ие является настояшей избыточностью, так как без повторения имени в каждом кортеже невозможно определить, что оба адреса принадлежат Кэрри Фишер. Разница в том, что имя кинозвезды - это ключ для объекта, который представляется отношением ii должен появляться в каждом кортеже, представляющем кинозвезду. Дата рождения ~ это данные о кинозвезде, не входящие в ключ для представляемого объекта, поэтому их повторение избыточно.

Во-вторых, множеаво адресов Харррисона Форда пусто, информация о нем утрачена. В частности, дата его рождения не является частью отношения, даже если она появляется в объекте Star.

Читатель должен помнить, что методология конвертирования схем ODL в реляционные схемы позволяет исправить оба недостатка, но о подобных проблемах следует знать и исправить реляционную схему методами нормализации , описанными в разделе 3.7. □

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

3.2.3 Представ.тхенме других конструкторов типов

Для конструирования .5начеиий в опрепелении класса ODL, кроме структур lamiceii и мно.-ксств, .можно использовать мультимножества, массивы и списки. Для >рс.1сг;1вле11ия мульти.множсстпа. в котором единственный объект может встречаться раз. невозможно просто ввести в отношение п идентичных кортежей. Вместо

ючмее говори 11С.11>1я инолпть илснтишмс кортсжи в отношения абстрактной рмчипонноВ молсш. cniicjiiHOM II jTofi тлзнг. Однако оснопамные на SOL релчииониыс СУ15Л нпзвщтош АубГгирооа!i, кортежи, т.е. в SQL отношения являются яу.11.т11.чНожсгпа.м1. а lie множестиами (см. ра.;!1слы 4.6 и 5.4). Когда важно число кортожпк сопетлом 11спол1.;ои:1ть схемы, молобныс описанным в jroii главе, если даже пдш;, СьД НО .толчет .чуй.1Г1;х11дЗ п. кортежи.



этого можно добавить к реляционной схеме еще один атрибут count показывающий, сколько раз каждый элемент входит в мультимножество. Например, пусть address на рис. 3.7 - это мультимножество, а не множество. .Можно указать, что 123 Maple St., Hollywood япляегся ааресом Кэрри Фишер дважды, а 5 Locust Ln., Malibu трижды:

name

street

city

count

Carrie

Fisher

123 Mapla St

Hollywood

Carrie

Fisher

5 Locust Ln.

Malibu

Список адресов можно представить с помощью нового атрибута postion, обозначающего позицию в списке. Например, покажем адреса Кэрри Фишер, начиная с Голливуда, в виде списка:

пате

sfreet

city

position

Came Fisher

123 Maple St.

Hollywood

Carrie Fisher

5 Locust Ln.

Malibu

И наконец, массив адресов фиксированной длины можно представить с помощью атрибутов для каждой позиции в наборе. Например, если address - тибор, состоящий из двух структур улица-город, объекты Star представляются следующим образом:

пате

streetl

cityl

street2

Carrie Fisher

123 Maple St.

Hollywood

5 Locust Ln.

1 Malibu

3.2.4 Представление однозначных связей

Нередки случаи, когда одно определение класса ODL содержит связи с другими классами ODL. В качестве примера рассмотрим полное определение класса Movie, приведенное на рис. 2.6 и воспроизведенное здесь на рис. 3.11.

interface Movie { attribute string title; attribute integer year; attribute integer length;

attribute enumerat on{color, bIckAndWhite] filmType; relationship Set<Star> stars

inverse Star : starredin; relationship Studio ovi/nedBy.

inverse Studio:; owns;

Рис. З.П. Полное определение mo q Movie

Рассмотрим сначала связь ownedBy между каждым фильмом и создавшей его студией. На первый взгляд она похожа на афибут. Можно создать реляционный атрибут или несколько таких атрибутов для препставления объектов связанного класса по аналогии с тем. как мы представляем атрибут ODL. значением которого является структура или множество структур. В случае со связью ownedBy можно было бы внести в схему отношения Movie по одному атрибут для каждого свойства класса Studio.



1 ... 22 23 24 [ 25 ] 26 27 28 ... 125

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика