Программирование >>  Хронологические базы данных 

1 ... 120 121 122 [ 123 ] 124 125 126 ... 348


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

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

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

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

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

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

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



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

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

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



Глава

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

10.1. Введение

В этой главе речь пойдет о концепции функциональной зависимости, которая если не совсем фундаментальна, то очень близка к таковой [10.7]. Эта концепция лежит в основе многих обсуждаемых в последующих главах тем, включая, в частности, теорию проектирования базы данных, описанную в главе 11.

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

Для любой заданной пары значений атрибутов SI и Р существует только одно соответствующее им значение атрибута QTY.

Многие разные пары значений атрибутов SI и Р могут иметь одно и то же соответствующее им значение атрибута QTY (в общем случае).

Обратите внимание, что в показанном на рис. 3.8 примере значения переменной-отношения SP удовлетворяют этим правилам.

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

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



1 ... 120 121 122 [ 123 ] 124 125 126 ... 348

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика