Bazy_dannykh_Uchebnik_novy

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

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

Отношение находится в НФБК, если она находится в 3НФ, и при этом отсутствуют функциональные зависимости атрибутов первичного ключа от неключевых атрибутов.

Отношение может находиться в 3НФ, но не в НФБК, только в одном случае: если оно имеет, помимо первичного ключа, ещё по крайней мере, один возможный ключ.

Пример 10:

Выполнение нормализации

Таблица 6. Ненормализованная (исходная) схема базы

Шаг 1. Первая нормальная форма: устранение неатомарных атрибутов

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

Таблица 7. База данных в первой нормальной форме (вариант 1)

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

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

41

отношения. Вместо этого создайте другую таблицу в первой нормальной форме,

устранив повторяющуюся группу (Дисц):

Таблица 8. База данных в первой нормальной форме (вариант 2)

Шаг 2. Вторая нормальная форма: устранение избыточных данных

Обратите внимание на то, что в приведенной выше таблице каждое значение «N»

номера зачетки студента, сопоставлено с несколькими значениями атрибута

«Дисциплина». Значения атрибута «Дисциплина» функционально не зависят от значений «N» - номера зачетки, который является первичным ключем, а это означает, что данное отношение не нормализовано до второй нормальной формы.

Приводим отношение ко второй нормальной форме.

Таблица 9. База данных во второй нормальной форме.

Студенты

Шаг 3. Третья нормальная форма: устранение данных, не зависящих от

ключа

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

42

Таблица 10. База данных в третьей нормальной форме.

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

например, называть группу по году поступления ПИ-2011, либо продолжать усовершенствовать структуру базы. Готового рецепта, после которого можно остановиться и сказать: «Все, мы сделали свое дело – не существует». Все зависит от специфики задач от требований, которые предъявляются к базе данных. Именно поэтому в определении банка данных и информационной системы подчеркивалось,

что персонал, который занимается обслуживанием информационной системы,

является ее составной частью.

Пример 11:

Задача: разработать систему учета посетителей сайта. Эксперты, посовещавшись,

решили, что нужно хранить следующие данные.

it_date — дата посещения

43

referer — откуда пришли на наш сайт

url — на какую страницу нашего сайта пришли

visitor_id — идентификатор посетителя

http_user_agent

os — ОС посетителя

browser — браузер посетителя

browser_ver — версия браузера

screen_w — разрешения экрана по горизонтали посетителя

screen_h — разрешения экрана по вертикали

depth — глубина цвета

cookie — есть ли куки

java — есть ли поддержка java

js — версия js

lang — язык браузера

ip посетителя — один посетитель может зайти с разных IP, например, у него ноутбук

ip_country — страна

ip_city — город

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

visitor_id → cookie

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

{it_date, referer, url} → visitor_id}

Наличие такой зависимости означало бы, что на одну страницу нашего сайта (url) в

одно и то же время (it_date) с другого сайта (referer) приходит только один посетитель (visitor_id).

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

visitor_id → os

означала бы, что посетитель все время использует одну и ту же операционную систему.

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

44

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

Если затем, мы более тщательно проанализируем функциональные зависимости, то может придти к следующим выводам.

Зависимость visitor_id → cookie означает, что у пользователя в его браузере режим кукесов всегда включен. Это не всегда справедливо. Пользователь может обновить ОС с сохранением всех параметров. Пользователь также может обновить браузер и импортировать кукесы, если обладает навыками. Еще пользователь может поменять разрешение экрана. Например, при покупке нового монитора.

Пользователь может сменить IP-адрес, особенно, если у него ноутбук или провайдер меняет ему IP раз в сутки. Он может отключить поддержку javascript, java и т.д.). В результате нам придется создавать отдельное отношение

Режим_кукесов (visitor_id, cookie, it_date)

которое будет отслеживать наличие/отсутствие такого режима у пользователя.

Аналогично функциональная зависимость

{it_date, referer, url} → visitor_id}

Означающая, что на одну страницу нашего сайта в одно и то же время с другого сайта приходит только один посетитель тоже может нарушаться в случае, когда со страницы поисковой машины, yandex.ru/search... на наш сайт itsoft.ru может придти два разных посетителя. В этом случае также придется создавать отдельное отношение в нашей базе данных.

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

Создана ли оптимальная схема базы данных

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

45

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

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

46

5. Целостность баз данных

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

Целостность

Приведем несколько определений понятия целостности информации. В

руководящих документах Гостехкомиссии РФ целостность информации определяется следующим образом:

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

(разрушения).

Также распространено определение целостности информации как отсутствие ненадлежащих изменений. Смысл понятия “ненадлежащее изменение” раскрывается Д.

Кларком и Д. Вилсоном в их статье “A comparison of Commercial and Military Computer Security Policies”: ни одному пользователю АС, в том числе и авторизованному, не должны быть разрешены такие изменения данных, которые повлекут за собой их разрушение или потерю.

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

Поддержка целостности в реляционной модели данных включает в себя 3 аспекта:

семантическую целостность, структурную целостность, языковую целостность и

ссылочную целостность.

Семантическая поддержка целостности

Семантическая целостность - целостность базы данных, которая

обеспечивается на уровне концептуальной модели.

Все требования семантической целостности касаются содержания базы данных. Все требования и ограничения семантической целостности определяют содержимое базы данных. Требования семантической целостности вытекают из понятийной модели

47

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

Пример 12:

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

В библиотеке должны быть записаны читатели не моложе 17 лет.

В библиотеке присутствуют книги, изданные начиная с 1960 по текущий год.

Каждый читатель может держать на руках не более 5 книг.

Каждый читатель при регистрации в библиотеке должен дать телефон для

связи: он может быть рабочим или домашним.

Семантическая поддержка может быть обеспечена двумя путями: декларативным и

процедурным путем.

Декларативный способ обеспечения целостности Декларативный способ обеспечения целостности связан с наличием

механизмов в рамках СУБД, обеспечивающих проверку и выполнение ряда описательно заданных правил-ограничений, называемых чаще всего "бизнес-

правилами" (Business Rules) или декларативными ограничениями целостности.

Выделяются следующие виды декларативных ограничений целостности:

Ограничения целостности атрибута:

Могут выполнены следующими способами:

значение по умолчанию,

задание обязательности или необязательности значений (Null),

задание условий на значения атрибутов;

задание значения по умолчанию означает, что каждый раз при вводе новой строки

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

Пример 13:

Ограничения целостности текстового атрибута в MS Access – рисунок 15.

48

года до текущего года. Далее это выражение можно использовать для проверки правильности вводимых данных.

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

Для MS Access это выражение будет выглядеть следующим образом:

Between 1960 AND YEAR(NOW())

В СУБД MS SQL Server 7.0 значение по умолчанию записывается в качестве

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

YEAR_PUBL >= 1960 AND YEAR_PUBL <= YEAR(GETDATE())

Здесь GETDATE() — функция MS SQL Server7.0, возвращающая значение текущей даты, YEAR_PUBL — имя столбца, соответствующего году издания.

Ограничения целостности, задаваемые на уровне доменов.

Некоторые СУБД поддерживают доменную структуру, то есть разрешают определять отдельно домены, задавать тип данных для каждого домена и задавать соответственно ограничения в виде бизнес-правил для доменов. Так, например, в MS SQL Server 7.0 вместо понятия домена вводится понятие типа данных, определенных пользователем, но смысл этого типа данных фактически эквивалентен смыслу домена.

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

является минимизация избыточности, а это означает, что если возможно информацию о чем-то, в том числе и об ограничениях, хранить в одном месте, то это надо делать обязательно.

Ограничения на уровне домена в MS Access задаются при выборе вкладки

«Подстановка» при описании атрибута, как показано на рисунке 17.

50