Что означает потенциальная противоречивость в бд

Тема: «Поддержание непротиворечивости и целостности БД»

Тема: «Поддержание непротиворечивости и целостности БД»

1.Понятие целостности. Основные аспекты.

2. Правила соблюдения ссылочной целостности.

Целостность (от англ. integrity – нетронутость, неприкосновенность,

сохранность, целостность) – понимается как правильность данных в любой момент

Во-первых, это поддержка структурной целостности, которая трактуется как то, что реляционная СУБД должна допускать работу только с однородными структурами данных типа «реляционное отношение».

Во-вторых, это поддержка языковой целостности, которая состоит в том, что реляционная СУБД должна обеспечивать языки описания и манипулирования данными не ниже стандарта SQL. He должны быть доступны иные низкоуровневые средства манипулирования данными, не соответствующие стандарту.

Именно поэтому доступ к информации, хранимой в базе данных, и любые изменения этой информации могут быть выполнены только с использованием операторов языка SQL.

В-третьих, это поддержка ссылочной целостности, то есть поддержание связей между таблицами. Ссылочная целостность обеспечивает поддержку непротиворечивого состояния БД в процессе модификации данных при выполнении операций добавления, обновления или удаления.

Нарушение целостности данных может быть вызвано рядом причин:

сбои оборудования, физические воздействия или стихийные бедствия; ошибки санкционированных пользователей или умышленные действия несанкционированных пользователей; программные ошибки СУБД или ОС; ошибки в прикладных программах; совместное выполнение конфликтных запросов пользователей и др.

Нарушение целостности данных возможно и в хорошо отлаженных системах. Поэтому важно не только не допустить нарушения целостности, но и своевременно обнаружить факт нарушения целостности и оперативно восстановить целостность после нарушения.

2. Правила соблюдения ссылочной целостности.

Для каждого значения внешнего ключа должно существовать соответствующее значение первичного ключа в родительской таблице

Для родительской таблицы:

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

Для дочерней таблицы:

Вставка. Нельзя вставить запись в дочернюю таблицу, если для новой записи значение внешнего ключа некорректно. Операция может привести к нарушению ссылочной целостности. Обновление. При обновлении записи в дочерней таблице можно попытаться некорректно изменить значение внешнего ключа. Операция может привести к нарушению ссылочной целостности. Удаление. При удалении записи в дочерней таблице ссылочная целостность не нарушается.

Таким образом, ссылочная целостность в принципе может быть нарушена при выполнении одной из четырех операций:

3.Важнейшим средством механизма защиты целостности БД выступает транзакция.

Фиксация транзакции – это действие, обеспечивающее запись на диск изменений в БД, которые были сделаны в процессе выполнения транзакции.

Если в процессе выполнения транзакции случилось нечто такое, что делает невозможным ее нормальное завершение, БД должна быть возвращена в исходное состояние.

Откат транзакции – это действие, обеспечивающее аннулирование всех изменений данных, которые были сделаны в процессе текущей незавершенной транзакции.

Свойства транзакций

Журнал транзакций

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

Журнал транзакций предназначен для обеспечения надежного хранения данных в БД.

Источник

Ограничения целостности БД

Дата добавления: 2015-07-09 ; просмотров: 5491 ; Нарушение авторских прав

Обеспечение целостности БД составляет необходимое условие успешного функционирования БД, особенно при ее сетевом использовании. Целостность БД — это свойство базы данных, означающее, что в ней содержится полная, непротиворечивая и адекватно отражающая предметную область информация. Целостное состояние БД описывается с помощью ограничений целостности в виде условий, которым должны удовлетворять хранимые в базе данные [17].

Целостность сущностейописывается совокупностью ограничений которые должны выполняться для любых отношений в любых реляционных базах данных. Теоретики баз данных формулируют эти ограничения по-разному. Например, в [3] называют «Условиями целостности … будем называть особые, отдельно хранящиеся данные, которыми на концептуальном уровне … представлено … правило (закон, критерий) принадлежности кортежей отношению, представленному этими данными (записями) в базе данных. К уровням целостности базы данных, как правило, присоединяются также спецификации условий принадлежности значений каждого из атрибутов реляционной таблицы к соответствующему ему домену в базе данных».

Из данного определения можем извлечь следующие простые формулировки ограничений:

1. Все строки таблицы должны иметь одинаковую структуру, одно и то же количество атрибутов.

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

3. Значения атрибутов должны быть атомарными.

4. Значения каждого атрибута должны быть взяты из некоторого фиксированного множества значений (домена).

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

В [8] ограничения целостности сущностей заключаются в требовании уникальности кортежей отношения (записей таблицы), из которого вытекают следующие ограничения:

1. отсутствие кортежей-дубликатов (данное требование предъявляется лишь к атрибутам первичных ключей);

2. отсутствие атрибутов с множественным характером значений.

Задания для самостоятельной работы

1. Найти соответствие условий целостности из [8] условиям, названным выше, (1 – 4).

2. Составить перечень атрибутов для сведений об адресе отношения СОТРУДНИК, обеспечивающих атомарность.

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

Пример 1. Рассмотрим отношение СОТРУДНИКИ с внешним ключом «Код отдела» и связано с отношением ОТДЕЛЫ с первичным ключом «Код отдела» (см. рис. 8). Если существует сотрудник Волков И. И., работающий в отделе О1, то соответствующий отдел должен существовать и данные о нем должны храниться в таблице ОТДЕЛЫ [17].

Пример 2. Связь между таблицами Студент и Сдал осуществляется по полю НОМЕР_Зачетки, это связь типа один-ко-многим (1:М). Причем главной является таблица Студент, а подчиненной — таблица Сдал, т.к. в ней возможно любое количество записей со значением в поле НОМЕР_Зачетки, которое в таблице Студент может быть только один раз. Поле связи должно быть обязательно первичным ключом главной таблицы. Главную таблицу иногда называют родительской, а подчиненную — дочерней.

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

Большинство СУБД реляционного типа, но не все, осуществляют контроль ссылочной целостности данных. Контроль данных на непротиворечивость осуществляется СУБД автоматически в следующих случаях:

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

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

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

Задания для самостоятельной работы

1. Добавить в таблицу СОТРУДНИКИ запись о Фроловой О.А., работающей в отделе кадров. Изобразить отношения СОТРУДНИКИ и ОТДЕЛЫ.

2. Удалить из таблицы ОТДЕЛЫ запись со значением атрибута Краткое_наим_отдела «ЛИД». Изобразить отношения СОТРУДНИКИ и ОТДЕЛЫ.

1 Основное внимание в ограничениях целостности в иерархической модели уделяется целостности ссылок между предками и потомками с учетом основного правила: никакой потомок не может существовать без родителя.

2 В сетевой модели данных ослаблен контроль целостности связей из-за допустимости установления произвольных связей между записями.

Все операции над базой данных сводятся к манипуляциям с записями и полями таблиц. Обращаясь к нашему студенческому архиву (см. Таб.1), возможно, захочется узнать, кто из студентов учится в группе 407 – ответ: Сидоров (запись 3) и Соловьев (запись 4). Другой пример: кто среди студентов самый старший – ответ: Петров (запись 2). Это примеры простейших операций выборки.

В основу манипуляционной части модели положена теория множеств с некоторыми уточнениями. Основная идея состоит в том, что, поскольку отношение — это множество, то средства манипулирования отношениями могут базироваться на традиционных теоретико-множественных операциях, дополненных некоторыми операциями, специфичными для БД.

Набор операций, предложенный Коддом, содержит восемь операций:

1)теоретико-множественные операции, такие как объединение, пересечение, разность и декартово произведение, а ко второму — селекция, проекция, соединение и деление

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

Пример 1. Объединение. R3 = R1 È R2

Пусть отношение R1 — это таблица «Абитуриенты — победители олимпиады», а R2 — таблица «Абитуриенты, прошедшие по конкурсу на основании экзаменов».

Таблица Абитуриенты — победители олимпиады.

Таблица Абитуриенты, прошедшие по конкурсу на основании экзаменов.

Пусть основанием для зачисления в университет является победа в олимпиаде, либо успешная сдача вступительных экзаменов. Результат объединения (R3), который мы назовем «Абитуриенты, зачисленные в университет», включает все строки первой таблицы и недостающие строки из второй.

Таблица Абитуриенты, зачисленные в университет.

Пример 2. Пересечение. R3 = R1 Ç R2

Исходные данные те же, что и в случае объединения. Результат пересечения включает только те строки первой таблицы, которые есть во второй. В нашем случае результатом будет таблица, которую можно назвать «Абитуриенты, зачисленные в университет по двум показателям».

Таблица Абитуриенты, зачисленные в университет по двум показателям.

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

Для операции декартово произведение, применяемой к паре отношений, важно, чтобы схемы, т.е. имена атрибутов были разными.

При нарушениях условий целостности возможно возникновение аномалий. Существует несколько видов аномалий: избыточности, обновления, включения, удаления.

Пример 1. Рассмотрим БД «Объединение кооперативов». В отношении ПОСТАВЩИКИ (НАЗВАНИЕ ПОСТАВЩИКА, АДРЕС ПОСТАВЩИКА, ТОВАР, ЦЕНА), в связи с такой его схемой, могут возникают следующие проблемы:

1. Аномалия избыточность: адрес поставщика повторяется для каждого повторяемого товара.

2. Аномалия обновления (потенциальная противоречивость, может и не возникнуть): вследствие избыточности можно обновить адрес поставщика в одном кортеже, оставив его неизменным в другом. При этом может оказаться, что для некоторых поставщиков нет единого адреса.

3. Аномалия удаления: при необходимости удаления всех товаров, поставляемых данным поставщиком, непреднамеренно можно утратить его адрес.

4. Аномалия включения: в БД может быть записан адрес поставщика, который в настоящее время не поставляет товар, можно поместить неопределенные значения атрибутов ТОВАР и ЦЕНА. Но если он начнет поставлять некоторый товар, можно забыть удалить кортеж с неопределенными значениями. ТОВАР и НАЗВАНИЕ ТОВАРА образуют ключ данного отношения, а поиск кортежей с неопределенными значениями может быть затруднен или невозможен.

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

· Аномалии вставки (INSERT)

· Аномалии обновления (UPDATE)

· Аномалии удаления (DELETE)

Пример 2: Рассмотрим в качестве предметной области некоторую организацию, выполняющую некоторые проекты. В текущий момент состояние предметной области отражается следующими фактами:

· Сотрудник Иванов, работающий в 1 отделе, выполняет в первом проекте «Космос» задание 1 и во втором проекте «Климат» задание 1.

· Сотрудник Петров, работающий в 1 отделе, выполняет в первом проекте «Космос» задание 2.

· Сотрудник Сидоров, работающий во 2 отделе, выполняет в первом проекте «Космос» задание 3 и во втором проекте «Климат» задание 2.

Это состояние отражается в таблице СОТРУДНИКИ_ОТДЕЛЫ_ПРОЕКТЫ (курсивом выделены ключевые поля):

Не нашли то, что искали? Google вам в помощь!

Источник

Часть 2. Нормализация таблиц

Практическое занятие №3

«Даталогическое проектирование базы данных»

Цель:приобретение практических навыков по проектированию логической модели БД, минимизация избыточности данных на основе принципов нормализации

Время выполнения: 2 часа

Общие теоретические сведения

Часть 1. Построение реляционной схемы

Получение реляционной схемы из ER-диаграммы:

1.Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы.

2.Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, — не могут. Если атрибут является множественным, то для него строится отдельное отношение.

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

4.Связи «многие к одному» и «один к одному» становятся внешними ключами. Т.е. создается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ.

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

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

Пример

Рассмотрим следующую задачу: пусть необходимо обеспечить сбор и обработку данных по результатам сдачи экзаменов и зачетов студентами факультета. Организация данных должна поддерживать:

• выполнение текущего учебного плана;

• формирование ведомостей по отдельным дисциплинам для групп студентов;

• формирование листов зачетных книжек студентов;

• формирование сводной ведомости курса;

• расчет среднего балла по дисциплинам и т. п.

Рассмотрим этап построения даталогической модели (реляционной схемы) на основе имеющейся ER-диаграммы) для решения задачи.

ER-диаграмма рассматриваемой задачи представлена на рис.2.

Рис 2. ER-диаграмма предметной области

На данном этапе проектирования необходимо построить даталогическую модель. В рассматриваемом случае задача этого этапа — преобразование ER-диаграммы в реляционную схему.

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

После реализации этих шагов получаем реляционную схему, изображенную на рис. 3, где представлены таблицы «Студенты», «Сводная ведомость», «Учебный план» и «Кадровый состав», отображающие соответственно сущности «Студент», «Сводная ведомость», «Дисциплина учебного плана» и «Преподаватель».

Рис. 3. Реляционная схема после первого шага проектирования

Далее необходимо преобразовать связи во внешние ключи. Связь «многие ко многим», реализуемая отношением «Сводная ведомость», должна содержать уникальные идентификаторы сущностей — участников связи. При этом, если для однозначной идентификации студента достаточно добавить в таблицу столбец ID Студент, то однозначная идентификация дисциплины потребует добавления в таблицу столбцов Наименование, Семестр и Форма отчетности. Хранение всей этой информации явно приведет к избыточности данных и их потенциальной противоречивости (например, если при переносе дисциплины на другой семестр обновить только строку таблицы «Учебный план», то содержимое таблицы «Сводная ведомость» станет неактуальным).

Для ликвидации избыточности и потенциальной противоречивости данных добавим в таблицу «Учебный план» столбец ID_План, содержимое которого будет однозначно идентифицировать каждую строку таблицы. Теперь этот новый столбец станет первичным ключом, и одноименный столбец должен быть добавлен в таблицу «Сводная ведомость».

Связь «Читает» предполагает добавление в таблицу «Учебный план» столбца ID_Преподаватель. Реляционная схема со связями представлена на рис.4

Рис. 4. Реляционная схема со связями

Часть 2. Нормализация таблиц

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

В качестве примера рассмотрим универсальное отношение сотрудники, содержащее информацию о сотрудниках предприятия (табл. 1). Таблица 1

При использовании универсального отношения возникают две проблемы:

· потенциальная противоречивость (аномалии).

Под избыточностью понимают повторение данных в разных строках одной таблицы или в разных таблицах БД. Так, для каждого сотрудника отдела 128 повторяются данные «128, Отдел проектирования».

Аномалии – это проблемы, возникающие в данных из-за дефектов проектирования БД.

Существуют три вида аномалий: вставки, удаления и модификации.

Аномалии вставки проявляются при вводе данных в дефектную таблицу. Добавляя информацию о новом сотруднике, мы должны добавить номер и название отдела. Если ввести данные, не соответствующие имеющимся в таблице (например, 42, отдел проектирования), будет не ясно, какая из строк БД содержит правильную информацию.

Аномалии удаления возникают при удалении данных из дефектной схемы. Предположим, что все сотрудники отдела 128 уволились в один и тот же день. После удаления записей этих сотрудников в БД больше не будет ни одной записи, содержащей информацию об отделе 128.

Аномалии модификации возникают при изменении данных дефектной схемы. Предположим, что отдел 128 решили переименовать в отдел передовых технологий. Необходимо изменить соответствующие данные о каждом сотруднике отдела. Если мы пропустим хотя бы одну запись, возникнет аномалия модификации.

Решение перечисленных проблем состоит в разделении данных и связей, что обеспечивается процедурой нормализации. Концепции и методы нормализации были разработаны Э. Ф. Коддом.

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

Теория нормализации основана на наличии зависимостей между атрибутами отношения.

Основными видами зависимостей являются:

Базовым является понятие функциональной зависимости, поскольку на его основе формируются определения всех остальных видов зависимостей. Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В (ВàA). Это означает, что во всех кортежах с одинаковым значением атрибута А атрибут В будет иметь также одно и то же значение. При этом А и В могут быть составными, то есть состоять из двух и более атрибутов.

Зависимость, при которой каждый неключевой атрибут зависит от всего составного ключа и не зависит от его частей, называется полной функциональной зависимостью. Если атрибут А зависит от атрибута В, а атрибут В зависит от атрибута С (С à В à А), но обратная зависимость отсутствует, то зависимость А от С называется транзитивной.

Многозначная зависимость. Говорят, что один атрибут отношения многозначно определяет другой атрибут того же отношения, если для каждого значения первого атрибута существует множество соответствующих значений второго атрибута. Многозначные зависимости могут быть:

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

· первая нормальная форма (1НФ);

· вторая нормальная форма (2НФ);

· третья нормальная форма (3НФ);

· усиленная 3НФ или нормальная форма Бойса-Кодда (БКНФ);

· четвертая нормальная форма (4НФ);

· пятая нормальная форма (5НФ).

База данных считается нормализованной, если ее таблицы (по крайней мере, большинство таблиц) представлены как минимум в третьей нормальной форме.

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

В столбце Квалификация ненормализованной табл. 1 содержатся списки значений (С, Java и т. д.). Чтобы привести схему к 1НФ, необходимо разместить в этом столбце атомарные значения. Самый простой способ заключается в выделении по одной строке на каждый элемент квалификации (табл. 2).

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

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

Таблица Квалификации_сотрудников (табл. 2) находится в 1НФ, но не удовлетворяет 2НФ. Первичный ключ должен уникальным образом идентифицировать каждую строку. Единственным вариантом является использование в качестве первичного ключа комбинации Код сотрудника и Квалификация. Это порождает схему: Квалификации_сотрудников (Код сотрудника, ФИО, Должность, Номер отдела, Наименование отдела, Квалификация).

Одной из имеющихся здесь функциональных зависимостей будет:

Код сотрудника, КвалификацияàФИО, Должность, Номер отдела, Наименование отдела.

Но, кроме того, мы также имеем:

Код сотрудникаàФИО, Должность, Номер отдела, Наименование отдела.

Другими словами, можно определить имя, должность и отдел, используя только код сотрудника. Это значит, что указанные атрибуты функционально зависимы только от части первичного ключа, а не от всего первичного ключа. Следовательно, указанная схема не находится в 2НФ.

Для приведения этой схемы в 2НФ необходимо декомпозировать исходное отношение на два, в которых все неключевые атрибуты будут полностью функционально зависеть от ключа: сотрудники (Код сотрудника, ФИО, Должность, Номер отдела, Наименование отдела) и Квалификации_сотрудников (Код сотрудника, Квалификация) (табл. 3-4).

Отношение находится в третьей нормальной форме (ЗНФ), если оно находится во 2НФ и ни один из его неключевых атрибутов не связан функциональной зависимостью с любым другим неключевым атрибутом. Атрибуты, зависящие от других неключевых атрибутов, нормализуются путем перемещения зависимого атрибута и атрибута, от которого он зависит, в новое отношение.

Формально, для приведения схемы в 3НФ необходимо исключить все транзитивные зависимости. Схема отношения сотрудники (табл. 3) содержит следующие функциональные зависимости:

Код сотрудника àФИО, Должность, Номер отдела, Наименование отдела и

Номер отделаàНаименование отдела

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

Функциональная зависимость Код сотрудникаàНаименование отдела является транзитивной, поскольку содержит промежуточный шаг (зависимость Номер отделаàНаименование отдела). Для приведения в 3НФ необходимо исключить эту транзитивную зависимость, декомпозируя отношение на два:

сотрудники (Код сотрудника, ФИО, Должность, Номер отдела) и

отделы (Номер отдела, Наименование отдела) (табл. 5-6). Таблица 5

Таблица 6

Нормальная форма Бойса-Кодда (БКНФ) является развитием ЗНФ и требует, чтобы в отношении были только такие функциональные зависимости, левая часть которых является потенциальным ключом отношения. Потенциальный ключ представляет собой атрибут (или множество атрибутов), который может быть использован для данного отношения в качестве первичного ключа. Фактически первичный ключ – это один из потенциальных ключей, назначенный в качестве первичного. Детерминантом называется левая часть функциональной зависимости. Отношение находится в БКНФ тогда и только тогда, когда каждый детерминант отношения является потенциальным ключом.

На практике построение 3НФ в большинстве случаев является достаточным и приведением к ней процесс построения реляционной БД заканчивается. Нормальные формы высших порядков (4НФ и 5НФ) представляют больший интерес для теоретических исследований, чем для практики проектирования БД. В них учитываются многозначные зависимости между атрибутами.

Пример

Рассмотрим процедуру приведения таблиц рассмотренного выше примера к НФБК.

Все построенные таблицы (Рис.4) находятся в первой нормальной форме, так как каждый столбец таблицы неделим и в рамках одной таблицы нет столбцов с одинаковыми по смыслу значениями.

Ø Таблица «Сводная ведомость» через столбцы ID Студент и ID План связывает информацию о студенте с информацией о конкретной дисциплине и фиксирует оценку, полученную студентом, Оценка и дата сдачи экзамена (зачета) однозначно зависят от содержимого столбцов ID Студент и ID План, которые представляют собой составной первичный ключ. Таким образом, все таблицы имеют первичные ключи, которые однозначно определяют строки и не избыточны, и можно говорить о том, что таблицы находятся во второй нормальной форме.

Ø Рассмотрим подробнее таблицу «Учебный план», которая содержит перечень дисциплин текущего учебного плана. Первичным ключом таблицы служит столбец ID План, который однозначно характеризует каждую дисциплину учебного плана с точностью до семестра, т. е. для дисциплин, протяженность изучения которых более одного семестра, в таблице будет отведено столько строк, сколько семестров длится изучение дисциплины. Тогда хранение наименований дисциплин в таблице «Учебный план» становится избыточным: например, если изучение английского языка длится шесть семестров, то наименование «Английский язык» будет повторено в шести записях и есть вероятность сделать шесть различных ошибок при вводе одного и того же наименования. Чтобы избежать этого, проведем декомпозицию отношения «Учебный план», выделив наименования дисциплин в отдельное отношение. В результате получим дополнительную таблицу «Дисциплины» со столбцами ID Дисциплина и Наименование, а столбец Наименование в таблице «Учебный план» заменим столбцом Дисциплина, сформировав тем самым вторичный ключ, связывающий новую таблицу с таблицей «Учебный план».

Теперь можно говорить о базе данных «Сессия», реляционная схема которой представлена следующими пятью таблицами:

• «Студенты» — содержит по одной строке для каждого из студентов;

• «Учебный план» — содержит по одной строке для отдельной дисциплины отдельного семестра;

• «Дисциплины» — содержит по одной строке для наименования дисциплины;

• «Сводная ведомость» — содержит по одной строке для каждого результата сдачи отдельным студентом отдельной дисциплины;

• «Кадровый состав» — содержит по одной строке для каждого из преподавателей.

На рис. 2 в графической форме изображены перечисленные таблицы, их столбцы, первичные и внешние ключи. Задание первичных и внешних ключей сопровождается построением дополнительных структур — индексов, обеспечивающих быстрый доступ к данным через значение ключа.

Рис. 2. Структура базы данных «Сессия»

Все таблицы базы данных «Сессия» находятся в третьей нормальной форме:

• каждый столбец таблицы неделим, и в рамках одной таблицы нет столбцов с одинаковыми по смыслу значениями (1НФ);

• первичные ключи однозначно определяют запись и не избыточны, все поля каждой из таблиц зависят от ее первичного ключа (2НФ);

• значение любого поля, не входящего в первичный ключ, не зависит от значения другого поля, тоже не входящего в первичный ключ (ЗНФ).

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

Исходя из особенностей данных и их функционального назначения, требуется задать способ представления и границы возможных изменений для каждого из столбцов таблиц. При этом необходимо ответить на вопрос: данные каких типов должны храниться в столбцах и какова их максимальная длина (например, если в столбце предполагается хранить процентные значения, то достаточно будет целого типа данных длиной 1 байт, так как диапазон возможных значений — от 0 до 255; если для данных столбца выбирается тип «строка символов», то желательно указать максимальный размер данных столбца и т. п.).

Далее, в каждой таблице должны быть выделены столбцы, которые обязательно должны быть заполнены при создании отдельной строки таблицы. Задание такого ограничения целостности не позволит, например, ввести в таблицу «Студенты» строку, в которой не указан номер группы. Если подобные ограничения целостности не будут заданы, в таблице могут появиться строки, которые не будут учтены при выполнении функций по обработке данных: появление в таблице «Студенты» строки без номера группы приведет к ошибке при формировании ведомости.

Следующий важный момент — задание для столбцов значений по умолчанию. Значение по умолчанию впоследствии будет автоматически вводиться в указанный столбец для каждой строки таблицы. Например, в столбец Дата сдачи таблицы «Сводная ведомость» при заполнении очередной строки может автоматически заноситься текущая дата.

Ниже, на рис. 3 представлены таблицы базы данных «Сессия» с типами данных столбцов и предлагаемыми ограничениями целостности.

ЗАДАНИЕ НА практическую РАБОТУ:

1. Изучите методические указания к практической работе.

2. Выполните упражнения:

· из концептуальной ER- модели для своей задачи получите реляционную схему

· выполните нормализацию отношений

3. Оформите отчет по практической работе, описав выполнение упражнений и дав краткие ответы на контрольные вопросы.

1. Название и цель работы

2. Выполненные упражнения

3. Ответы на контрольные вопросы

4. Выводы по работе

1. Основные этапы получения реляционной схемы из ER-диаграммы

2. С чем связаны избыточность данных и потенциальная противоречивость (аномалии)? Дайте определение данным явлениям.

Источник