bigpo.ru
добавить свой файл
1 2 ... 5 6

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


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

1) Мы будем говорить о логическом, а не физическом макете.

2) Хотя речь в основном пойдет о реляционном макете, рассматриваемые модели также в равной степени относятся к не реляционным базам данных.

3) Проектирование баз данных скорее искусство, чем наука.

Допущения в дальнейшем изложении.

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

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

2Функциональная зависимость (Ф.З.).


Является зависимостью типа «многие к одному» м/у множествами атрибутов внутри данного отношения.

Например, для отношения поставок SP существует ФЗ м/у {S#, P#} и {QTY}.

3Основные определения:


Для демонстрации дальнейшего мат-ла приведем видоизмененную версию отношения поставок, введя доп. атрибут CITY, представляющий город соотв-го поставщика.

SCP

S#

CITY

P#

QTY

S1

S1

S2

S2

S3

S4

S4

S4

London

London

Paris

Paris

Paris

London

London

London

P1

P2

P1

P2

P2

P2

P4

P5

100

100

200

200

300

400

400

400

Следует четко различать:

1)значение этого отношения (т.е. значение переменной отношения в определенный момент времени).

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

Дадим опр-е для 2-го случая, кот-ое явл-ся более общим:

опр. Пусть R явл-ся переменной отношения, а X и Y произвольными подмножествами мн-ва атрибутов отношения R, тогда Y функционально зависима от X, что в символическом виде записывается как X->Y(и читается как «X функционально определяет Y» или «X стрелка Y »), тогда и только тогда, когда для любого допустимого значения отношения R каждое значение X связанно в точности с одним знач-ем Y.

Иначе говоря, для любого допустимого значения отношения R, когда бы 2 кортежа отношения R ни совпали по значению X, они так же совпадут по знач-ю Y.

Приведем неск. ФЗ для пер-ой отнош-я SCP:

{S#, P#}->{QTY}

{S#, P#}->CITY

{S#, P#}->{CITY, QTY}

{S#, P#}->{S#, P#, CITY, QTY}

{S#}->CITY

Эта ФЗ кот-ая будет вып-ся всегда.

Обратим внимание на ФЗ, кот-я вып-ся для приведенной табл. SCP, но не вып-ся всегда.

S#->QTY

QTY->S#

Левую и правую стороны символич. записи ФЗ иногда наз-ют детерминантом и зависимой частью соответственно.

Как говорится в определении детерминант и зависимая часть явл-ся мн-вами атрибутов. Когда мн-во сод-ит один атрибут, он наз-ся одноэлементным мн-вом, скобки опускаются и символич. запись принимает вид:

S# ->CITY

Отметим, что если X явл-ся потенциальным ключом отношения R, напр-р, X явл-ся первичным ключом, то все атрибуты отношения R д/б обязательно ФЗ-мы от X(следует из определения потенц. ключа). Фактически, если отношение R удовл-ет ФЗ А->В и А не явл-ся потенц. Ключом, то R будет характеризоваться нек-ой избыточностью. Напр-р в случ. отнош-я SCP сведения о том, что каждый данный поставщик нах-ся в данном городе будут повторяться много раз.

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

Далее будем разбирать методы сокращения этого обширного мн-ва ФЗ до компактных р-ров. Эта цель явл-ся важной, т.к. ФЗ явл-ся ограничениями целостности, поэтому при кажд. обновлении данных СУБД все они д/б проверенны, сл-но для заданного мн-ва ФЗ S желательно найти такое мн-во T, кот-ое в идеальной ситуации было бы гораздо меньшего р-ра, чем мн-во, при чем каждая ФЗ мн-ва S м/б заменена ФЗ мн-ва T. Поэтому задача поиска подходящего мн-ва T представляет большой практический интерес.


следующая страница >>