Часть III

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

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

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

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

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

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

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

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

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

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

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

а) Проектирование базы данных заключается не только в создании правильной структуры данных. Другой и, вероятно, более важной задачей является обеспе- чение целостности данных. Это замечание будет неоднократно повторено и усилено в тексте последующих глав,

' Термин "методология" изначально означал изучение методов, но со временем стал исполь­зоваться и для обозначения "системы методов и правил, которые применяются для исследова­ний или выполнения работы в некоторой области науки или искусства" (см. Chambers Twentieth Century Dictionary*.

б) Далее в большинстве случаев проектирование рассматривается независимо от приложения. Иначе говоря, интерес представляют сами данные, а не то, как они будут использоваться. Независимость от приложения в этом смысле желательна

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

■ Как отмечалось выше, задача проектирования базы данных заключается в том, что­бы решить, какие базовые переменные-отношения и с каким набором атрибутов следует использовать. Фактически для этого также необходимо выяснить, какие сле­дует использовать домены или типы. На момент создания книги этой теме было по­священо совсем немного публикаций, поэтому освещение данного вопроса будет очень кратким (исключениями являются лишь публикации [13.11], [13.39]).

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

Глава

Функциональные зависимости