VAR SP VIEW

SSP { SI, PI, QTY } ;

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

CONSTRAINT DESIGN A

IS EMPTY ( SP { SI } MINUS S { St } ) ; CONSTRAINT DESIGN B

IS EMPTY ( SSP { SI } INTERSECT XSS { SI } ) ;

(Обратите внимание, что офаничение DESIGN A здесь иллюстрирует иной способ формулировки ссылочного Офаничения.)

Проект варианта а, очевидно, лучший по причинам, которые подробно объясняются в главе 11.

9.16. Приведенные ниже ответы пронумерованы как 9.\6.п, где п- номер исходного упражнения.

9.16.2. CREATE VIEW NON COLOCATED

AS SELECT S.SI, P.Pl FROM S, P

WHERE S.CITY <> P.CITY ;

9.16.3. CREATE VIEW LONDON SUPPLIER

AS SELECT S.SI, S.SNAME, S.STATUS FROM S

WHERE S.CITY = London ;

9.16.4. CREATE VIEW SP

AS SELECT SPJ.SI, SPJ.Pl, SUM ( SPJ. QTY ) AS QTY FROM SPJ

GROUP BY SPJ.SI, SPJ.Pl ;

9.16.5. CREATE VIEW JC

AS SELECT J.JI, J.CITY FROM J

WHERE J.JI IN ( SELECT SPJ.JI FROM SPJ

WHERE SPJ.SI = SI ) AND J.JI IN ( SELECT SPJ.JI FROM SPJ

WHERE SPJ.P = Pi ) ;

Часть III

Проектирование базы данных

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

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

Следует заметить, что речь здесь пойдет о логическом (или концептуачьном) проектировании, а не о разработке физического проекта. Это вовсе не значит, что физическое проектирование не имеет большого значения. Наоборот, создание физического проекта играет очень важную роль. Тем не менее необходимо сделать следующие оговорки.

а) Физическое проектирование может рассматриваться как отдельный последующий этап. Иначе говоря, для правильного проектирования базы данных прежде всего необходимо создать ее приемлемый логический (т.е. реляционный) проект. И лишь затем как отдельный этап разработки выполнить отображение этого логического проекта на определенные физические структуры, поддерживаемые конкретной СУБД. (Иначе говоря, как уже отмечалось в главе 2, физический проект создается на базе логического и никак иначе.)

б) Физическое проектирование по определению является зависимым от специфики конкретной целевой СУБД. Однако эта тема выходит за рамки учебника общего плана, к которым следует отнести настоящую книгу. Логический макет, наоборот, совершенно независим от СУБД, и для его реализации могут использоваться некоторые строгие теоретические принципы. Безусловно, именно эти принципы и должны описываться в книге подобного толка.

К сожалению, мы живем в несовершенном мире и на практике часто случается так, что решения, принятые в процессе физической реализации проекта, могут оказывать существенное обратное влияние на его логический уровень. (Если говорить точнее, то это имеет место, в основном, из-за того (как уже несколько раз отмечалось в этой книге), что в современных СУБД обычно поддерживаются только относительно простые средства