Целостность данных. Условия целостности данных

Нормализация данных. Правила, примеры.

Процесс упорядочения, структурирования представления данных назы­вается нормализацией. Следствием нормализации будет набор таблиц с минимальным дублированием информации, достаточно гибкий и надежно работающий. Существует четыре формы нормализации, и любая нормализованная таблица автоматически считается нормализованной по первой форме. То, насколько нормализована таблица, определяется двумя зависимостями – функциональной, где поле А зависит от поля В одной и той же таблицы в случае, когда в любое время любое значение В принимает только одно значение А.А и В могут быть составными (Например, в таблице Блюда поля Блюдо и Вид функционально зависят от ключа БЛ, а в таблице Поставщики поле Страна функционально зависит от составного ключа (Поставщик, Город). Однако последняя зависимость не является функционально полной, так как Страна функционально зависит и от части ключа – поля Город), полной функциональной (если функционально поле полностью зависит от поля, но не от любого его подмножества), многозначной (дял каждого поля зависимость к другому полю).

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

целостность данных – правильность и полнота инфор­мации, содержащейся в бд. К нарушению целостности может привести некорректное модифицирование базы. Для контроля целосноти существуют условия:

1. Обязательность данных. Некоторые столбцы в базе данных должны содержать значения в каждой строке;. строки в таких столбцах не могут содержать значения NULL или не содержать никакого значения. Например, в учебной базе данных для каждого заказа должен существо­вать соответствующий клиент, разместивший этот заказ. Поэтому стол­бец CUST в таблице ORDERS является обязательным. (для заказа д.б. клиент)

2. Проверка на правильность. У каждого столбца в базе данных есть свой домен, Т.е. набор значений, которые допускается хранить в данном столбце. В учебной базе данных заказы нумеруются, начиная с числа 100001, поэтому доменом столбца ORDER_NUM являются положительные целые числа, большие 100000. Аналогично, идентифика­торы служащих в столбце EMPL _ NUM должны находиться в диапазоне от 101 до 999. Можно указать СУБд, что запись значений, не входящих в определенный диапазон, в такие столбцы недопустима. (например, отрицательные)

3. Целостность таблицы. Первичный ключ таблицы должен в каждой строке иметь уникальное значение, отличное от значений во всех остальных строках. Например, каждая строка таблицы PRODUCTS имеет уникальную комбинацию значений в столбцах MFR_ID и PRO­DUCT_ID, которая однозначно идентифицирует товар, представляемый данной строкой. Повторяющиеся значения в этих столбцах недопустимы, поскольку тогда база данных не сможет отличить один товар от другого.

4. Ссылочная целостность. В реляционной базе данных каждая строка таблицы-потомка с помощью внешнего ключа связана со строкой таблицы-предка, содержащей первичный ключ, значение кото­рого равно значению внешнего ключа. В учебной базе данных значение столбца REP_OFFICE таблицы SALESREPS связывает служащего с офи­сом, в котором он работает. Столбец REP_OFFICE должен содержать значение из столбца OFFICE таблицы OFFICES; в противном случае служащий будет закреплен за несуществующим офисом.

Ссылочная целостность данных. Проблемы, связанные со ссылочной целостностью. Правила удаления и обновления В реляционной базе данных каждая строка таблицы-потомка с помощью внешнего ключа связана со строкой таблицы-предка, содержащей первичный ключ, значение кото­рого равно значению внешнего ключа. В учебной базе данных значение столбца REP_OFFICE таблицы SALESREPS связывает служащего с офи­сом, в котором он работает. Столбец REP_OFFICE должен содержать значение из столбца OFFICE таблицы OFFICES; в противном случае служащий будет закреплен за несуществующим офисом.

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

Обновление внешнего ключа в строке-потомке. Это та же проблема, что и в предыдущей ситуации, но выраженная в иной форме. Если внешний ключ обновляется оператором UPDATE, то его новое зна­чение должно быть равно одному из значений первичного ключа в таблице-предке. В противном случае обновленная строка окажется сиротой.

Удаление строки-предка. Если из таблицы-предка будет удалена строка, у которой есть хотя бы один потомок, то строки-потомки станут сиротами. Значения внешних ключей в этих строках больше не будут равны ни одному из значений первичного ключа таблицы-предка. Обратите внима­ние на то, что удаление строки из таблицы-потомка не вызовет проблем; просто предок этой строки после удаления будет иметь на одного потомка меньше.

Обновление первичного ключа в строке-предке. Это иная форма проблемы, рассмотренной в предыдущем пункте. Если происходит изменение пер­вичного ключа некоторой строки в таблице-предке, все существующие потомки этой строки становятся сиротами, поскольку их внешние ключи больше не равны ни одному первичному ключу.

9. Связывание таблиц. Виды связей 1:1, 1:М, М:М.

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

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

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

Суть связывания состоит в установлении соответствия полей связи основной и дополнительной таблиц. Поля связи основной таблицы могут быть обычными и ключевыми. В качестве полей связи подчиненной таблицы чаще всего используют ключевые поля. В зависимости от того, как определены поля связи основной и дополнительной таблиц (как соотносятся ключевые поля с полями связи), между двумя таблицами в общем случае могут устанавливаться следующие четыре основные вида связи: один — один (1:1);один — много (1:М);много — один (М:1);много — много (М:М).

1:1 все поля связи основной и дополнитель­ной таблиц являются ключевыми. Поскольку значения в ключевых полях обеих таб­лиц не повторяются, обеспечивается взаимно-однозначное соответствие записей из этих таблиц. Сами таблицы, по сути, здесь становятся равноправными. 1 ФИО = дата рождения

1:М одной записи основной таблицы соответ­ствует несколько записей вспомогательной таблицы. 1 Фамилия = 1, 2, 3 … Имя

М:1 одной или нескольким записям основной таблицы ставится в соответствие одна запись дополнительной таблицы. 1 Имя = 1,2,3 … Фамилия

М:М нескольким записям ос­новной таблицы соответствует несколько записей дополнительной таблицы 1,2,3 … администрируют ПК 1,2,3 …

Дата добавления: 2015-05-10