Функциональная зависимость базы данных. Нормализация данных

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

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

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

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

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

Информация, данные, информационные системы

Понятие функциональной зависимости в данных

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

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

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

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

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

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

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

Определение 1. Пусть r (A 1 , A 2 , ..., A n) - схема отношения R , a X и Y - подмножества r . Говорят, что Х функционально определяет Y , если каждому значению атрибутов кортежа отношения из Х соответствует не более одного значения атрибутов того же кортежа отношения из Y . Такая ФЗ обозначается как .

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

Пример. Понятие функциональной зависимости Продемонстрируем понятие функциональной зависимости на примере графика полетов аэропорта. ГРАФИК_ПОЛЕТОВ (Пилот, Рейс, Дата_вылета, Время_вылета)

Иванов 100 8.07 10:20
Иванов 102 9.07 13:30
Исаев 90 7.07 6:00
Исаев 100 11.07 10:20
Исаев 103 10.07 19:30
Петров 100 12.07 10:20
Петров 102 11.07 13:30
Фролов 90 8.07 6:00
Фролов 90 12.07 6:00
Фролов 104 14.07 13:30

Известно, что:

  • каждому рейсу соответствует определенное время вылета;
  • для каждого пилота, даты и времени вылета возможен только один рейс;
  • на определенный день и рейс назначается определенный пилот.

Следовательно:

  • "Время_вылета" функционально зависим от "Рейс" : "Рейс" -> "Время_{} вылета" ;
  • "Рейс" функционально зависим от {"Пилот", "Дата_вылета", "Время_вылета"} : {"Пилот", "Дата_вылета", "Время_вылета"} -> "Рейс" ;
  • "Пилот" функционально зависим от {"Рейс", "Дата_вылета"} : {"Рейс", "Дата_вылета"} -> "Пилот" .

Важной задачей при выявлении функциональных зависимостей на атрибутах отношения, которое по определению является множеством, является выяснение, какой из атрибутов выступает как аргумент, а какой - как значение ФЗ. Наиболее подходящими кандидатами в аргументы ФЗ являются возможные ключи , так как кортежи представляют экземпляры сущности , которые идентифицируются значениями атрибутов своего ключа. Нестрого говоря, функциональная зависимость имеет место на отношении, когда значения кортежа на одном множестве атрибутов однозначным образом определяют значения кортежа на другом множестве атрибутов. Это рабочее определение ФЗ не содержит в себе тех формальных элементов, которые позволяют ответить на вопрос "А как проверить наличие ФЗ между атрибутами отношения?" Необходимый для этого формализм дает нам использование реляционных операций . Для получения формального (строгого) определения наличия ФЗ в отношении обратимся к реляционным операциям .

Определение 2. Пусть имеется отношение R со схемой r , X и Y - два подмножества R . ФЗ имеет место на R , если множество имеет не более одного кортежа для каждого значения х . Такая ФЗ называется также F -зависимостью.

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

Алгоритм, который проверяет, удовлетворяет ли отношение R ФЗ , состоит в сортировке отношения по значениям возможного ключа и установления факта однозначности между его значением и значениями других атрибутов. Этот алгоритм полезен, но он носит вспомогательный характер.

Ясно, что если семантика предметной области базы данных сложна, то проверить кортежи на принадлежность к ФЗ достаточно сложно. Сложно вообще установить наличие самой функциональной зависимости , отвечающей природе рассматриваемых данных. С помощью такого формального метода можно выявить ФЗ, которые не являются реальными и носят случайный характер. Проектировщику реляционных баз данных следует знать о таком методе проверки наличия ФЗ, но при проектировании новой базы данных его применение малоэффективно. Он может быть полезен при реинжиниринге существующей базы данных.

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

Здесь уместно высказать гипотезу о том, почему бывают хорошие и плохие проекты баз данных. Во-первых, в силу субъективности подходов к анализу предметной области аналитики могут упустить важные ФЗ. Это может привести к тому, что, работая на множестве заведомо неэквивалентных схем, проектировщик создаст неудовлетворительный проект базы данных. Во-вторых, неединственность представления предметной области отношениями приводит к проблеме выбора из множества альтернатив. При этом схема базы данных, выбранная из набора эквивалентных схем, является правильной, но может организовывать данные для пользователя непривычным образом. В-третьих, можно определить ("накроить") схемы баз данных таким образом, что в результате операций с ФЗ будут потеряны и ФЗ, и сами данные.

Метод нормальных форм

Преподаватель

ФИО Долж Оклад Стаж Надб Каф Предм Группа ВидЗан
Иванов И.М. преп СУБД Лабор
Иванов И.М. Преп Информ Лабор
Петров М.И. Ст.преп СУБД Лекция
Петров М.И. Ст.преп Графика Лабор
Сидоров Н.Г. Преп Информ Лекция
Сидоров Н.Г. Преп Графика Лекция
Егоров В.В. Преп ПЭВМ Лекция

Рис. 6.4. Исходное отношение ПРЕПОДАВАТЕЛЬ

Неявная избыточность проявляется в одинаковых окладах у всех преподавателей и в одинаковых надбавках к окладу за одинаковый стаж. Если оклад изменится с 500 руб. до 510руб., то это значение надо изменить у всех преподавателей. Если при этом будет пропущен Сидоров, то база станет противоречивой. Это пример аномалии редактирования отношения с неявной избыточностью.

Исключение избыточности состоит в нормализации отношений.

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

Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В. Математически функциональная зависимость В от А обозначается записью А ® В. Это означает, что во всех кортежах с одинаковым значением атрибута а АТРИБУТ в БУДЕТ ИМЕТЬ ТАКЖЕ ОДНО И ТО ЖЕ ЗНАЧЕНИЕ. Атрибуты А и В могут быть составными – состоять из двух и более атрибутов. В отношении Преподаватель Функциональные зависимости следующие: ФИО ® Каф, ФИО ® Долж, Долж ® Оклад и др.

Функциональная взаимозависимость. Если существует функциональная зависимость вида А ® В и В ® А, то между А и В имеется взаимно однозначное соответствие, или функциональная взаимозависимость. Математически взаимозависимость обозначается как А « В или В « А.

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

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

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

Атрибут С зависит от атрибута А транзитивно (существует транзитивная зависимость ), если для атрибутов А, В, С выполняются условия А ® В и В ® С, но обратная зависимость отсутствует. В примере транзитивной зависимостью связаны атрибуты:

ФИО ® Долж ® Оклад

В отношении R атрибут В многозначно зависит от атрибута А, если каждому значению А соответствует множество значений В, не связанных с другими атрибутами из R. Многозначные зависимости могут быть «один ко многим» (1:М), «многие к одному» (М:1) или «многие ко многим» (М:М), Обозначаемые соответственно: А Þ В, А Ü В и А Û В.

В рассматриваемом примере имеется многозначная зависимость М:М между атрибутами ФИО Û Предмет (один преподаватель может вести несколько предметов и один предмет могут вести несколько преподавателей).

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

Взаимно независимые атрибуты. Два или более атрибутов называются взаимно независимыми, если ни один из этих атрибутов не является функционально зависимым от других атрибутов. Математически отсутствие зависимости атрибута А от атрибута В обозначается как А Ø® В. Если имеет место А Ø® В и В Ø® А, то взаимная независимость обозначается А Ø= В.

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

Пример. Пусть задано отношение R со схемой R(А1, А2, А3) вида:

А1 А2 А3

Априори известно, сто существуют функциональные зависимости:

А1®А2 и А2®А3.

Из анализа видно, что в отношении существуют еще зависимости:

А1®А3, А1А2®А3, А1А2А3®А1А2, А1А2®А2А3 и т.п..

В отношении отсутствует функциональная зависимость атрибута А1 от атрибута А2 и от атрибута А3, т.е.

А2 Ø® А1, А3 Ø® А1.

Отсутствие зависимости А1 от А2 объясняется тем, что одному и тому же значению атрибута А2 (21) соответствуют разные значения атрибута А1 (12 и 17).

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

В отношении Преподаватель можно вывести следующие функциональные зависимости:

ФИО ® Оклад

ФИО ® Долж

ФИО ® Стаж

ФИО ® Надб

ФИО ® Каф

Стаж ® Надб

Долж ® Оклад

Оклад ® Долж

ФИО. Предм. Группа ® Оклад

Рис. 6.5. Зависимости между атрибутами.

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

Один преподаватель в одной группе по разным предметам может проводить разные виды занятий. Определение ВидаЗанятий связано с указанием ФИО, Предмета и Группы. Действительно, Петров М.И. в 256-й группе читает лекции и проводит лабораторные занятия, но лекции читает по СУБД, а лабораторные работы по Графике.

Зависимости между атрибутами ФИО, Предмет и Группа не выведены, т.к. они образуют составной ключ и не учитываются в процессе нормализации отношения (таблицы).

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

Выделяют следующую последовательность нормальных форм:

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

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

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

° Усиленная третья нормальная форма, или нормальная форма Бойса-Кодда (БКНФ);

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

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

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

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

Основной операцией метода декомпозиции является операция проекции.

Пример. Пусть в отношении R(A,B,C,D,E,…) имеется функциональная зависимость С ® D. Декомпозиция отношения R на два новых отношения R1(A, B,C,E,…) и R2(C,D) устранит функциональную зависимость атрибутов и переведет отношение R в следующую нормальную форму. Отношение R2 является проекцией отношения R на атрибуты C и D.

Исходное отношение Преподаватель имеет составной ключ ФИО, Предм, Группа и находится в 1НФ. Атрибуты Стаж, Надб, Каф, Долж, Оклад находятся в функциональной зависимости от части составного ключа – атрибута ФИО . Эта частичная зависимость приводит к явной и неявной избыточности данных, что создает проблемы их редактирования. Часть избыточности устраняется при переводе отношения во 2НФ.

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

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

° Построить проекцию без атрибутов, находящихся в частичной зависимости от первичного ключа;

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

Переведем отношение Преподаватель во 2НФ. В результате получим два отношения R1 и R2.

R1

ФИО Предм Группа ВидЗан
Иванов И.М. СУБД Лабор
Иванов И.М. Информ Лабор
Петров М.И. СУБД Лекция
Петров М.И. Графика Лабор
Сидоров Н.Г. Информ Лекция
Сидоров Н.Г. Графика Лекция
Егоров В.В. ПЭВМ Лекция

Рис. 6.6. Отношения базы данных ПРЕПОДАВАТЕЛЬ во 2 НФ

В отношении R1 первичный ключ составной ФИО, Предм, Группа , в отношении R2 ключ – ФИО. В результате исключена явная избыточность данных о преподавателях. В R2 по-прежнему имеет место неявное дублирование данных.

Для дальнейшего совершенствования переведем отношения в 3НФ.

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

Функциональная зависимость описывает связь между атрибутами и является одним из основных понятий нормализации. Предположим, что реляционная схема имеет атрибуты (A, B, C,…, Z) и вся база может быть представлена в виде одного универсального отношения R=(A, B, C,…, Z). Следовательно, каждый атрибут в базе имеет уникальное имя.

Если A и B – атрибуты некоторого отношения R, и каждое значение А связано с одним и только одним значением В (причем каждый из атрибутов может состоять из одного или нескольких атрибутов), то атрибут В функционально зависим от атрибута А (ВàА).

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

Транзитивная зависимость для атрибутов A, B и C некоторого отношения означает следующее: если АàВ и ВàС, то С транзитивно зависит от атрибута А через атрибут В (при условии, что А функционально не зависит от В или С).

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

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

Таблица, находящаяся в первой нормальной форме, должна отвечать следующим требованиям:

1) таблица не должна иметь повторяющихся записей;

2) в таблице должны отсутствовать повторяющиеся группы полей;

3) каждое поле должно быть семантически неделимым.

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

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

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

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

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

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

Различие между 3НФ и НФБК заключается в том, что функциональная зависимость АàВ допускается в отношении 3НФ, если атрибут В является первичным ключом, а атрибут А не обязательно является потенциальным ключом. В отношении НФБК эта зависимость допускается только тогда, когда атрибут А является потенциальным ключом. Следовательно, НФБК является более строгой версией 3НФ, поскольку каждое отношение НФБК является 3НФ, но не всякое отношение 3НФ является НФБК.

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

Четвертая нормальная форма (4НФ) – отношение в НФБК, которое не содержит нетривиальных многозначных зависимостей.

Многозначная зависимость представляет такую зависимость между атрибутами отношения (например А, В и С), что каждое значение А представляет собой множество значений для В и множество значений для С. Однако множество значений В и С не зависят друг от друга.

Многозначная зависимость может быть дополнительно определена как тривиальная или нетривиальная. Многозначная зависимость АàВ некоторого отношения R определяется как тривиальная, если атрибут В является подмножеством атрибута А или . И наоборот, многозначная зависимость определяется как нетривиальная, если ни то ни другое условие не выполняется. Тривиальная многозначная зависимость не накладывает никаких ограничений на данное отношение, а нетривиальная – накладывает.

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

Пятая нормальная форма (5НФ), которая также называется проективно-соединительной нормальной формой, означает, что отношение в такой форме не имеет зависимостей соединения. Отношение R с подмножеством атрибутов А,В,…,Z удовлетворяет зависимости соединения, если каждое допустимое значение R равно соединению его проекций на подмножества А,В,…,Z.

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

Обозначение : A → B. Это значит, что во всех кортежах с одинаковым значением атрибута А атрибут В будет иметь также одно и то же значение.

Если существует функциональная зависимость вида A→B и В→А, то между А и В имеется взаимно однозначное соответствие , или функциональная зависимость . О

Обозначение : A↔B или В↔А.

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

Частичная зависимость (частичная функциональная зависимость) – зависимость неключевого атрибута от части составного ключа.

Полная функциональная зависимость – зависимость неключевого атрибута от всего составного ключа.

Транзитивная зависимость

Атрибут С зависит от атрибута А транзитивно (существует транзитивная зависимость ), если для атрибута А, В, С выполняются условия A→B и В→С, по обратной зависимости отсутствуют.

Множественная зависимость

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

Обозначения : А=>B, A<=B, A<=>B.

Взаимно независимые атрибуты

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

Обозначения : А →В, А=В.

Нормальные формы:

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

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

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

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

    Четвертая нормальная форма (4НФ). Отношения находится в 4НФ в том и только в том случае, когда существует многозначная зависимость А=>B, а все остальные атрибуты отношения функционально зависят от А.

    Пятая нормальная форма (5НФ). Отношения находится в 5НФ, если оно находится в 4НФ и удовлетворяет зависимости по соединению относительно своих проекций.

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

    Обеспечение непротиворечивости и целостности данных в базе данных

Ответ :

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

Различают:

    Физическую целостность – наличие физического доступа к данным и то, что данные не утрачены.

    Логическую целостность – отсутствие логических ошибок в БД, к которым относятся нарушение структуры БД или ее объектов, удаление или изменение установленных связей между объектами и т.д.

Поддержание целостности БД включает:

    Проверку (контроль) целостности

    Восстановление в случае обнаружения противоречий в базе.

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

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

    Структурные ограничения на кортежи отношений . Определяет требования целостности сущностей и целостности ссылок .

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

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

    Метод «сущность - связь»

Ответ :

Метод «сущность-связь» (метод «ER-диаграмм») – это метод, основанный на использование диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа.

Основные понятия

Сущность – это объект, информация о котором хранится в БД.

Атрибут – это свойство сущности.

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

Связь между сущностями – это зависимость между атрибутами этих сущностей.

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

    Диаграмма ER- экземпляров ;

    Диаграмма ER -типа или ER -диаграмма .

На основе анализа ER-диаграмм формируется отношения проектируемой БД. При этом учитывается степень связи сущностей и класс их принадлежности.

Степень связи – это характеристика связи между сущностями (1:1, 1:М; М:1; М:М).

Класс принадлежности сущности может быть: обязательным и необязательным .

Обязательный – если все экземпляры сущности обязательно участвуют в рассматриваемой связи.

Необязательный – не все экземпляры участвуют в рассматриваемой связи.

    Этапы проектирования баз данных

Ответ :

I . Концептуальное проектирование – сбор, анализ и редактирование требований к данным.

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

Процедуры :

    Определение сущностей и их документирование;

    Определение связей между сущностями и их документирование;

    Создание модели предметной области;

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

    Определение первичных ключей для сущностей.

II . Логическое проектирование – на основе концептуальной модели создается структура данных.

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

Процедуры :

    Выбор модели данных;

    Определение набора таблиц и их документирование;

    Нормализация таблиц;

    Определение требований к поддержке целостности данных и их документирование.

III . Физическое проектирование – определение особенностей данных и методов доступа.

Цель: описание конкретной реализации БД, размещение во внешней памяти компьютера.

Процедуры:

    Проектирование таблиц БД;

    Проектирование физической организации БД;

    Разработка стратегии защиты БД.

    Жизненный цикл базы данных

Ответ :

Жизненный цикл БД – это процесс проектирования, реализации и поддержания систем БД.

Стадии жизненного цикла БД:

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

    Проектирование – создание логической структуры БД, функциональное описание программных моделей и информационных запросов.

    Реализация – разработка ПО для БД, проводится тестирование.

    Эксплуатация и сопровождение .

Этапы жизненного цикла БД:

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

    Проверка осуществимости – проверка технологической, операционной и экономической осуществимостей.

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

    Концептуальное проектирование – создание концептуальной схемы.

    Реализация – приведение концептуальной модели ф функциональную БД.

    Выбор и приобретение необходимой СУБД.

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

    На основе инфологической модели строится схема данных для конкретной СУБД.

    Определяются какие прикладные процессы необходимо реализовать как хранимые процедуры.

    Реализовать ограничения, предназначенные для обеспечения целостности данных.

    Спроектировать триггеры.

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

    Определить уровни доступа пользователей, разработать и внедрить правила безопасности.

    Разработать сетевую топология БД.

    Создание словаря данных.

    Заполнение БД.

    Создание прикладного ПО, контроль управления.

    Обучение пользователя.

    Оценка и усовершенствование схемы БД .

    Правила формирования отношений

Ответ :

Правила формирования отношений основываются на учете следующего:

    Степень связи между сущностями (1:1, 1:М, М:1, М:М);

    Класса принадлежности экземпляров сущностей (обязательный и необязательный).

  • Сергей Савенков

    какой то “куцый” обзор… как будто спешили куда то