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

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

Приступая к подробному изложению этой темы, отметим следующие особенности.

■ ■ Прежде всего следует заметить, что речь здесь пойдет о логическом,а не физическом макете. Это вовсе не значит, что физический макет не имеет большого значения, наоборот его значение очень велико. Однако, несмотря на это, нужно сделать следующие оговорки.

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

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

К сожалению, на практике часто случается так, что реализация макета на физическом уровне может оказывать существенное обратное влияние на логический макет. Иначе говоря, в таком случае для достижения компромисса следует выполнить несколько циклов проектирования "логический макет — физический макет". Тем не менее, изложение материала в этой части ведется исходя из необходимости создания логического макета без учета особенностей физической организации, т.е. без учета требований к высокой производительности. Таким образом, основная цель этой части книги — "первоочередное создание логического макета".

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

■ ■ После всего сказанного следует подчеркнуть, что проектирование базы данных скорее искусство, чем просто наука. Конечно, существуют некоторые научные принципы составления таких макетов, и они будут изложены в следующих трех главах. Однако при проектировании базы данных возникает множество других проблем, которые не всегда можно охватить этими принципами. В результате теоретики и практики в области создания баз данных разработали большое число методологий проектирования. Среди них есть как достаточно точные и строгие, так и не очень, однако все они специализированные и предназначены для решения именно той проблемы, которая считалась неразрешимой к моменту создания данной конкретной методики. Иными словами, они были задуманы для поиска такого логического макета, который был бы, бесспорно, лучшим в данной ситуации. Поскольку все эти методологии являются в большей или меньшей степени специализированными, существует мало объективных критериев для предпочтения одной из них. Все же, несмотря на это, в главе 12 будет описан один широко известный подход, менее специализированный, чем другие.

■ ■ Следует также отметить некоторые допущения, используемые в дальнейшем изложении.

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

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

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

В главе 9 описаны некоторые теоретические основы, а в главах 10, 11 — основные идеи дальнейшей нормализации, которые позволяют придать смысл неформальным утверждениям о преимуществах того или иного макета. Затем в главе 12 приведены концепции модели объект/отношение и показано, как эти концепции можно использовать для построения макета "сверху вниз" (начиная с реальных объектов и заканчивая формальным макетом базы данных).

Глава 9

Функциональные

Зависимости

Введение

В этой главе представлена концепция функциональной зависимости (functional dependency— FD), которая если "не совсем фундаментальна, то очень близка к таковой". Эта концепция лежит в основе обсуждаемых в следующих главах тем, включая, в частности, теорию проектирования базы данных, описанную в главе 10.

По сути, функциональная зависимость (далее для ее обозначения часто будет использоваться аббревиатура ФЗ) является связью типа многие-к-одному между множествами атрибутов внутри данного отношения. Например, для отношения поставок SP существует функциональная зависимость между множеством атрибутов (S#, P#} и {QTY}, т.е. многим значениям пары атрибутов S#—Р# соответствует одно значение атрибута QTY (для проверки этого утверждения можете обратиться §3 рис. 3.8).

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

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