Введение в системы БД (542480), страница 97
Текст из файла (страница 97)
ЧАЕ Я Ч1ЕИ 33 101И ЯИС 101И ЯТ 1 Добавим также в определения переменных-отношений ЯИС и ЯТ определения внешнего ключа. РОВЕ16И КЕХ ( 34 ) ВЕРЕВЕИСЕЯ 33 ОИ ОЕЬЕТЕ САЯСАОЕ ОИ ОРОАТЕ САЯСАОЕ И наконец так изменим спецификацию внешнего ключа (3$) в переменной- отношении ЯР, чтобы этот ключ ссылался не на переменную-отношение Я, а на переменную-отношение ЯЯ. Замечание.
Идея позволить внешним ключам ссылаться на представления вместо базовых переменных-отношений требует более глубокого изучения. 9.14. Что касается п, а данного упражнения, то ниже приведен пример операции выборки из представления, которая, определенно, завершится ошибкой в некоторых программных продуктах, существовавших на момент написания книги. Рассмотрим следующее Я(3(.-определение представления (пример 3 из раздела 9.6). 393 Глава 9. Представления сеейте ч1еи Ро Ая яеьест БР.Р3, яом (БР.Отх ) йя тототх РВОМ ЯР ОЙООР ВХ ЯР.РЯ Проанализируем результат попытки выполнить следующий запрос.
яеьест йчо ( Ро.тототх ) йя Рт РВОМ Ро ! Если следовать обсуждавшейся в данной главе процедуре простой подстановки (т.е. попытаться заменить все ссылки на имя представления выражением, которое это представление определяет), то получим следующее. Беьест Ачя ( Бом ( ЗР.отх ) ) Ая Рт РВОМ ЯР ОЕООР ВХ ЯР.Р$! Однако этот оператор ЯЕБЕСт некорректен, поскольку (как отмечалось при обсуждении примера 7.7.7 в главе 7) язык БО) не допускает, чтобы обобщающие операторы были вложены подобным образом. Вот еше один пример запроса к тому же представлению РО, который также вызовет ошибку в некоторых продуктах и по той же причине.
Беьест РО.Р$ РВОМ РО иВеее Ро.тототх > 500 Именно в связи с затруднениями, продемонстрированными в приведенных выше примерах, некоторые программные продукты (в частности, СУБД РВ2 фирмы! ВМ) иногда овеществляют прелставление (вместо использования обычного в этих случаях процесса подстановки) и после этого выполняют запрос в уже овеществленной версии представления.
Этот прием, конечно, всегда дает правильные результаты, но существенно снижает производительность. Кроме того, в случае СУБД РВ2 для некоторых типов представлений все еще существуют отдельные операции выборки, которые не срабатывают, т.е. в СУБД РВ2 либо овеществление используется не во всех случаях, когда подстановка не срабатывает, либо возникают ситуации, когда система затрудняется точно сказать, сработает ли процедура подстановки. Например, второй из двух приведенных выше примеров завершался в СУБД РВ2 ошибкой (на время написания книги). См. (4.20), где этот вопрос освещен подробнее. 9.15.
Сначала приведем определение проекта варианта б в терминах проекта варианта а. ЧАЕ БЯР Ч1ЕИ Я 501М БР ЧАЕ ХЯЯ Ч1ЕИ я МХМОЯ ( я 001и яР ) ( Б), яийме, ятйтия, сттх Теперь приведем определение проекта варианта а в терминах проекта варианта б. ЧАЕ Я Ч1ЕИ хяя Вмтои ББР ( Б!), Яийме, ятйтия, сттх 394 Часть П. Реля!(ионная модель ЧАВ БР Ч1ЕИ ББР ( 3$, Р$, ОТ1 ) ; Для двух проектов были бы уместны следующие ограничения целостности базы данных.
СОНБТВА1НТ ОЕЯ16Н А 13 ЕМРТУ ( БР ( 3$ ) М1НОЯ Я ( 3$ ) ) СОНЯТВА1НТ ОЕ316Н Б 13 ЕМРТУ ( ББР ( 3$ ) 1НТЕКБЕСТ ХЯЯ ( 3$ ) ) (Обратите внимание, что ограничение ОЕ316Н А здесь иллюстрирует иной способ формулировки ссылочного ограничения.) Проект варианта а, очевидно, лучший по причинам, которые подробно объясняются в главе 1!. 9.16.
Приведенные ниже ответы пронумерованы как 9.16аЬ где л — номер исходного упражнения. 9.16.2. СКЕЙТЕ Ч1ЕИ НОН СОЬОСАТЕО АБ БЕЬЕСТ 3.3$, Р.Р$ РВОМ Б, Р ИНЕКЕ Б.С1ТУ <> Р.С1ТУ 9.16.3. СКЕАТЕ Ч1ЕИ ЬОНООН 30РРЬ?ЕВ АБ БЕЬЕСТ Я.3$, Б.ЯНАМЕ, Б.ЯТАТ03 РВОМ Я ИНЕВЕ Б.С1ТУ = 'Ьопг)оп' 9.16.4. СКЕАТЕ Ч1ЕИ БР АЯ БЕЬЕСТ ЯРЮ.3$, ЯРЮ.Р$, 30М ( ЯРЯ. ОТХ ) АБ ОТУ УКОМ ЯРЮ 6ВООР В1 БР1.3$, ЯРЯ.Р$ 9.16.3. СКЕАТЕ Ч1ЕИ ЮС АЯ БЕЬЕСТ 1.0$, Ю.С1ТУ РВОМ ИНЕКЕ 1.1$ 1Н ( БЕЬЕСТ ЯРЮ.1$ РВОМ ЯРЮ ИНЕВЕ ЯР1.3$ = '31' ) АНО Ю.Ю$ 1Н ( БЕЬЕСТ БРЯ.Р$ РВОМ БРЮ ИНЕКЕ БРЮ.Р = 'Р1' ) Глава 9.
Лредетавления 395 Часть 111 Проектирование базы данных В этой части книги речь пойдет о проектировании базы данных, точнее — о проектировании реляялонной базы данных. В общем эта задача формулируется следующим образом: выбрать подходящую логическую структуру для заданного массива данных, которые требуется поместить в базу данных.
Иначе говоря, нужно решить вопрос, какие необходимы базовые переменные-отношения и какой набор атрибутов они должны включать. Совершенно очевидно, что решение этой задачи имеет большое практическое значение. Прежде чем приступить к подробному изложению данной темы, сделаем несколько предварительных замечаний. ° Следует заметить, что речь здесь пойдет о логическом (или коннептуазьноч) проектировании, а не о разработке физического проекта.
Это вовсе не значит, что физическое проектирование ие имеет большого значения. Наоборот, создание физического проекта играет очень важную роль. Тем не менее необходимо сделать следующие оговорки. а) Физическое проектирование может рассматриваться как отдельный последующий этап. Иначе говоря, для "правильного" проектирования базы данных прежде всего необходимо создать ее приемлемый логический (т.е. реляционный) проект.
И лишь затем как отдельный этап разработки выполнить отображение этого логического проекта на определенные физические структуры, поддерживаемые конкретной СУБД, (Иначе говоря, как уже отмечалось в главе 2, физический проект создается иа базе логического и никак иначе.) б) Физическое проектирование по опрелелению является зависимым от специфики конкретной целевой СУБД. Однако эта тема выходит за рамки учебника общего плана, к которым следует отнести настоящую книгу. Логический макет, наоборот, совершенно независим от СУБД, и для его реализации могут использоваться некоторые строгие теоретические принципы. Безусловно, именно эти принципы и должны описываться в книге подобного толка. К сожалению, мы живем в несовершенном мире и на практике часто случается так, что решения, принятые в процессе физической реализации проекта, могут оказывать существенное обратное влияние на его логический уровень.
(Если говорить точнее, то это имеет место, в основном, из-за того (как уже несколько раэ отмечалось в этой книге), что в современных СУБД обычно поддерживаются только относительно простые средства 397 отображения между логическим и физическим уровнями.) Иначе говоря, для достижения компромисса может потребоваться выполнение нескольких итераций цикла "логическое проектирование — физическое проектирование".
Тем не менее изложение материала в этой части ведется исходя из того, что предварительно необходимо создать логический проект без учета особенностей его будущей физической реализации (например, без учета требований к определенному уровню производительности). Таким образом, материал этой части книги, в основном, нацелен на решение задачи предварительного создания логического проекта базы данных. ° Хотя, как отмечалось ранее, речь пойдет, главным образом, о проекте реляционной системы, представленные здесь идеи в равной степени относятся и к нереляционным базам данных.
Иначе говоря, мы считаем, что правильный способ создания проекта нереляционной системы состоит в предварительной разработке ее корректного реляционного проекта с его последующим отображением (в виде отдельного этапа) на любые нереляционные структуры (например, иерархии), поддерживаемые в целевой СУБД. ° После всего сказанного следует подчеркнуть, что проектирование базы данных— это скорее искусство, чем наука. Конечно, здесь снова следует повторить, что сугцествуют некоторые научные принципы такого проектирования, которые будут изложены в следующих четырех главах. Однако при проектировании базы данных возникает множество других проблем, которые не всегда можно решить, руководствуясь этими принципами.
В результате теоретики и практики в области создания баз данных разработали множество методологий' проектирования. Среди них есть как достаточно точные и строгие, так и не относящиеся к таковым. Однако все они в той или иной степени специализированы и предназначены для решения именно той проблемы, которая считалась неразрешимой на момент создания конкретной методики. Иными словами, они предназначались лля поиска такого варианта логического проекта, который был бы, бесспорно, лучшим в данной ситуации. Поскольку все эти методологии являются в большей или меньшей степени специализированными, существует мало объективных критериев для предпочтения одной из них. Все же, несмотря на это в главе 13 будет описан один широкоизвестный подход, менее специализированный, чем другие. Там же вы кратко ознакомитесь и с другими подходами, получившими коммерческую поддержку.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
