Часть 3 Проектирование базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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