Презентация на тему: "1 базы данных функциональные зависимости и их использование в базах данных занятие 4 пугачёв ю.в. учитель информатики харьковская общеобразовательная школа.". скачать бесплатно и без регистрации

4 ответа

Транзитивная зависимость выражает зависимость A от C, когда A зависит от B, а B зависит от C.

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

Если A является определителем, а B является определенным, то мы говорим, что A функционально определяет B и графически представляем это как A -> B. Символы A à B· также могут быть выражены как B, функционально определяемый посредством A.

2015-10-23 04:26

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

Функциональная зависимость может быть определена как отношение, которое существует между атрибутами в отношении. Функциональные зависимости используются для создания отношений в нормальной форме Бойса Кодда, сокращенно BCNF. Если C и D являются атрибутами отношения R, а атрибут C функционально определяет атрибуты D, то функциональная зависимость между обоими атрибутами может быть выражена как C->D. то есть C-> D означает, что когда два кортежа в отношении R согласуются со всеми атрибутами X, они также должны согласовывать все атрибуты Y.

т.е. C-> D означает всякий раз, когда два кортежа в R согласуются

Пример: ниже схемы человека

лицо (национальный_ид, имя, адрес);

Здесь national_id функционально определяет person_name. Таким образом, функциональной зависимостью является national_id -> name;

Переходная зависимость

Транзитивная зависимость — это один вид функциональной зависимости, в котором непростой атрибут определяется другим непростым атрибутом. Предположим, что C и D являются непростыми атрибутами, а A является основным атрибутом отношения R .

Если функционал определяет C, а C функционально определяет D

А-> С

C-> D

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

А-> Г

Пример: ниже схемы ученика, в которой PostCode и City не являются простыми атрибутами.

студент (#Id, имя, возраст, почтовый индекс, город)

Здесь Id функционально определяет PostCode, а PostCode функционально определяет атрибут City. Таким образом, транзитивная функциональная зависимость

Id-> Город

2017-12-20 07:20

Взято из: Основы систем баз данных 6-е издание — Elmasri et al;

2015-10-23 04:20

Вы можете ссылаться на вики:

2015-10-23 04:15

К какой нормальной форме приведено исходное отношение?

Исходное отношение:

Преподаватель_предмет (Личный_#, Предмет, Часы, Фамилия, Должность, Оклад, Кафедра, Телефон )

Результирующие отношения:

Преподаватель (Личный_#, Фамилия, Должность, Оклад, Кафедра, Телефон )

Предмет(Личный_#, Предмет, Часы )

Комментарий к ответу: Отношение Преподаватель_Предмет содержит частичные ФЗ: пять последних неключевых атрибутов зависят от части ключа Личный_#. Это может привести к следующим аномалиям:

дублирование данных о преподавателе в случае, если он читает несколько предметов;
проблема контроля избыточности данных: обновление значения «Оклад»;
проблема нуль-значений: данные о преподавателе не могут быть включены, если они в настоящий момент не ведут обучения.

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

НФБД
1НФ
4НФ
(Правильный ответ) 2НФ
3НФ

Установите соответствие между типами денормализации и их определениями.

Тип денормализации

Определение

1.нисходящая денормализацияA— это процесс введения избыточных колонок в одной таблице с целью увеличения производительности запроса строки по производному значению2.восходящая денормализацияБ— это процесс введения избыточных колонок в родительских таблицах с целью устранения операций соединения с операциями агрегирования3.Внутритабличная денормализацияВ— это процесс введения избыточных колонок в подчиненных таблицах с целью устранения операций соединения4.Денормализация методом разделяй и властвуйГ— это процесс объединения одной или более нормализованных таблиц с целью устранения операций соединений или уменьшения в некоторых случаях числа операций вставки5.Денормализация методом слияния таблицД— это процесс разбиения нормализованной таблицы на две и более таблиц и создание между ними отношения «один к одному» с целью устранения дополнительных операций ввода-вывода или по техническим причинам

А, Б, В, Г, Д
(Правильный ответ) В, Б, А, Д, Г
А, Б, Г, В, Д
Б, Г, В, А, Д

Величины и зависимости между ними

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

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

Реализация математической модели на компьютере (компьютерная математическая модель) требует владения приемами представления зависимостей между величинами.

Рассмотрим различные методы представления зависимостей.

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

С понятием величины вы уже встречались в курсе информатики 7-9 классов. Напомним, что со всякой величиной связаны три основных свойства: имя, значение, тип.

Имя величины может быть смысловым и символическим. Примером смыслового имени является «давление газа», а символическое имя для этой же величины — Р. В базах данных величинами являются поля записей. Для них, как правило, используются смысловые имена, например: ФАМИЛИЯ, ВЕС, ОЦЕНКА и т. п. В физике и других науках, использующих математический аппарат, применяются символические имена для обозначения величин. Чтобы не терялся смысл, для определенных величин используются стандартные имена. Например, время обозначают буквой t, скорость — V, силу — F и пр.

Если значение величины не изменяется, то она называется постоянной величиной или константой. Пример константы — число Пифагора π = 3,14159… . Величина, значение которой может меняться, называется переменной. Например, в описании процесса падения тела переменными величинами являются высота Н и время падения t.

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

А теперь вернемся к примерам 1-3 (см. начало параграфа) и обозначим (поименуем) все переменные величины, зависимости между которыми нас будут интересовать. Кроме имен укажем размерности величин. Размерности определяют единицы, в которых представляются значения величин.

t (с) — время падения; Н (м) — высота падения. Зависимость будем представлять, пренебрегая учетом сопротивления воздуха; ускорение свободного падения g (м/с2) будем считать константой.
Р (н/м2) — давление газа (в единицах СИ давление измеряется в ньютонах на квадратный метр); t (0°С) — температура газа. Давление при нуле градусов Р будем считать константой для данного газа.
Загрязненность воздуха будем характеризовать концентрацией примесей (каких именно, будет сказано позже) — С (мг/м3). Единица измерения — масса примесей, содержащихся в 1 кубическом метре воздуха, выраженная в миллиграммах. Уровень заболеваемости будем характеризовать числом хронических больных астмой, приходящихся на 1000 жителей данного города — Р (бол./тыс.).

Отметим важное качественное различие между зависимостями, описанными в примерах 1 и 2, с одной стороны, и в примере 3, с другой. В первом случае зависимость между величинами является полностью определенной: значение Н однозначно определяет значение t (пример 1), значение t однозначно определяет значение Р (пример 2)

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

Нормальная форма элементарного ключа (НФЭК)

НФЭК предложена Карло Занионо в 1982 году в качестве “компромисса” между 3НФ и НФБК.

Элементарная ФЗ: Функциональная зависимость \(f \in G\), \(f = X\to A\) называется элементарной, если она нетривиальна и замыкание \(G^+\) не содержит ФЗ \(X’\to A\) такого, что \(X’ \subset X\).
Элементарный ключ: Суперключ \(X\) отношения \(R\) называется элементарным ключом, если \(R\) удовлетворяет элементарной ФЗ \(X\to A\), где \(A\) – некий атрибут \(R\).

Отношение находится в НФЭК, если

Оно находится в 3НФ
Любая его элементарная ФЗ имеет в левой части суперключ или в правой части находится подмножество какого-либо элементарного ключа.

Иначе, отношение находится в НФЭК, если для любой его ФЗ \(X\to A\) выполняется хотя бы одно из условий:

\(A\subset X\)
\(X\) является суперключом.
A входит в состав элементарного ключа

Декомпозиция без потерь

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

Декомпозиция: Составление проекций \(S\), \(T\) исходного отношения \(R\), таких, что объединение заголовков \(S\) и \(T\) совпадает с заголовком \(R\).

Однако, не всякая декомпозиция допустима.

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

Декомпозиция без потерь: Такая декомпозиция \(R\) в \((S,T)\), что \(R = S\bowtie T\).

Декомпозиция без потерь (lossless-join) позволяет восстановить исходное отношение при помощи операции соединения.

Как выбрать декомпозиции без потерь из всех возможных? Ответ на этот вопрос дает теорема Хита.

Теорема Хита: Пусть дано отношение \(R(A,B,C)\). Если \(R\) удовлетворяет функциональной зависимости \(A\to B\) , то \(R = \pi_{A,B} R \bowtie \pi_{A,C} R\).

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

Например, пусть дано отношение \(R(A,B,C)\), удовлетворяющее ФЗ \(F_R=\{(A,B)\to C,C\to A\}\). По теореме Хита, \(C\to A \Rightarrow R=S(B,C)\bowtie T(C,A)\). Тогда ФЗ отношения \(S\) \(F_S=\{B\to B, C\to C\}^+\), и ФЗ отношения \(T\) \(F_T=\{C\to A\}^+\). Но \(((A,B)→C)\notin (F_S\cup F_T)^+\), и в результате оказывается потеряна.

Всегда существует декомпозиция без потерь до НФБК.

Декомпозиция, сохраняющая зависимости: Такая декомпозиция \(R\) в \((S,T)\), что замыкание множества ФЗ отношения \(R\) совпадает с замыканием объединения ФЗ отношений \(S\) и \(T\).

Декомпозиция, сохраняющая зависимости (dependency-preserving) сохраняет неизменным замыкание ФЗ всех отношений БД.

Всегда существует декомпозиция до НФЭК, сохраняющая зависимости. Однако, не всегда возможна декомпозиция, сохраняющая зависимости, до НФБК.

I нормальная форма

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

Ненормализованное
отношение приводится к 1-ой НФ следующими способами:

—
Выравнивание таблиц или добавление строк;

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

Рассмотрим базу данных обработки заказов и создадим индексный кластер для хранения одной из таблиц базы данных — Customer.

CREATE CLUSTER cust_c (cust_id varchar(8))INDEX;CREATE INDEX cust_c_id ON CLUSTER cust_c;CREATE TABLE cust (cust_id varchar2(8) NOT NULL REFERENCES customers,ent# number NOT NULL,date_ent date NOT NULL,comment varchar2(60) NOT NULL,…PRIMARY KEY(cust_id, ent#)) CLUSTER cust_c (cust_id);

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

SELECT date_ent, comment FROM cust_c WHERE cust_id=:cur_cust;

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

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

нет
(Правильный ответ) да

Логическое (даталогическое) проектирование

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

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

Переход от ER-диаграмм к ФЗ

ER-диаграммы вполне естественным образом могут быть преобразованы к ФЗ.

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

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

Связи двух сущностей типа один-ко-многим и многие-к-одному естественным образом моделируют функциональную зависимость между ключевыми атрибутами соответствующих сущностей: в левой части ФЗ находятся ключевые атрибуты сущности, входящей в связь многократно, а в правой – ключевые атрибуты сущности, входящей в связь однократно, а так же атрибуты самой связи (если есть). Можно сказать, что ФЗ моделирует связь типа многие-к-одному.

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

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

Таким образом:

Каждая сущность \(E\) преобразуется к ФЗ вида \ где \(K_E\) – множество ключевых (идентифицирующих) атрибутов сущности \(E\), а \(A_E\) – множество всех атрибутов сущности \(E\).
Каждая связь \(R\) между сущностями \(E_1,\ldots,E_n\), входящими в связь многократно и \(S_1,\ldots,S_m\), входящими в связь однократно, преобразуется к ФЗ вида \ где \(K_i\) – ключи соответствующих сущностей, \(A_R\) – атрибуты связи, и ФЗ вида \.

Следует сделать одно важное замечание: если связь многие-ко-многим (возможно многозначная) не имеет атрибутов, то она даст исключительно тривиальные функциональные зависимости. Это, как правило, нежелательно, поскольку при формальном анализе в итоге приведет к потере этой связи

Это связано с тем, что связь многие-ко-многим является нефункциональной зависимостью. Решением этой проблемы может быть ввод фиктивного атрибута с пустым доменом, скажем, \(\theta\), уникального для данной связи. Это позволит формально анализировать функциональные зависимости для – фактически – неопределенной функции.

Диаграммы атрибутов

Кроме непосредственной записи ФЗ в столбик, существует более наглядный способ представления ФЗ отношений. Он так же может использоваться для нормализации отношения по крайней мере до 3НФ.

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

Например, построим диаграмму атрибутов для нашего примера с теннисными кортами.

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

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

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

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

Двойной линией обозначены внешние ключи.

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

Избегайте переходных зависимостей, чтобы помочь обеспечить нормализацию

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

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

Пример транзитивной зависимости

АВТОРЫ

Auth_001	Орсон Скотт Кард	Игра Эндера	Соединенные Штаты
Auth_001	Орсон Скотт Кард	Игра Эндера	Соединенные Штаты
Auth_002	Маргарет Этвуд	История о горничной	Канада

В примере АВТОРЫ выше:

Книга → Автор : . Здесь атрибут Книга определяет атрибут Автор . Если вы знаете название книги, вы можете узнать имя автора. Однако Автор не определяет Книгу , поскольку автор может написать несколько книг. Например, только потому, что мы знаем имя автора Орсон Скотт Кард, мы до сих пор не знаем название книги.
Автор → Author_Nationality : Аналогично, атрибут Author определяет Author_Nationality , но не наоборот; только то, что мы знаем национальность, не означает, что мы можем определить автора.

Но эта таблица вводит транзитивную зависимость:

Книга → Author_Nationality: Если мы знаем название книги, мы можем определить национальность через столбец Автор.

Избежание переходных зависимостей

Чтобы обеспечить третью нормальную форму, давайте удалим транзитивную зависимость.

Мы можем начать с удаления столбца Book из таблицы Authors и создания отдельной таблицы Books:

Книги

Book_001	Игра Эндера	Auth_001
Book_001	Дети разума	Auth_001
Book_002	История о горничной	Auth_002

АВТОРЫ

Auth_001	Орсон Скотт Кард	Соединенные Штаты
Auth_002	Маргарет Этвуд	Канада

Это исправило это? Давайте рассмотрим наши зависимости сейчас:

Стол BOOKS .

Book_ID → Книга: Книга зависит от Book_ID .

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

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

Таблица АВТОРОВ .

Нам нужно добавить третью таблицу для нормализации этих данных:

Страны

Coun_001	Соединенные Штаты
Coun_002	Канада

АВТОРЫ

Auth_001	Орсон Скотт Кард	Coun_001
Auth_002	Маргарет Этвуд	Coun_002

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

Внешний ключ таблицы BOOK Author_ID связывает книгу с автором в таблице AUTHORS.
Внешний ключ таблицы AUTHORS Country_ID связывает автора со страной в таблице COUNTRIES.
Таблица COUNTRIES не имеет внешнего ключа, поскольку в этом дизайне нет необходимости ссылаться на другую таблицу.

Почему транзитивные зависимости плохой дизайн базы данных

Какова ценность избегания транзитивных зависимостей, чтобы помочь обеспечить 3NF? Давайте снова рассмотрим нашу первую таблицу и посмотрим на проблемы, которые она создает:

АВТОРЫ

Auth_001	Орсон Скотт Кард	Игра Эндера	Соединенные Штаты
Auth_001	Орсон Скотт Кард	Дети разума	Соединенные Штаты
Auth_002	Маргарет Этвуд	История о горничной	Канада

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

Если вы удалили две книги «Дети разума» и «Игра Эндера», вы полностью удалили из базы данных автора «Карту Орсона Скотта» и его гражданство.
Вы не можете добавить нового автора в базу данных, если вы также не добавите книгу; Что делать, если автор еще не опубликован или вы не знаете название книги, которую она написала?
Если «Орсон Скотт Кард» изменил свое гражданство, вам придется изменить его во всех записях, в которых он появляется. Наличие нескольких записей с одним и тем же автором может привести к получению неточных данных: что, если лицо, занимающееся вводом данных, не понимает, что для него существует несколько записей, и изменяет данные только в одной записи?
Вы не можете удалить такую книгу, как «Сказка о служанке», не удалив также полностью автора.

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

Почему транзитивные зависимости плохой дизайн базы данных

Какова ценность избегания переходных зависимостей, чтобы помочь обеспечить 3NF? Давайте снова рассмотрим нашу первую таблицу и посмотрим на проблемы, которые она создает:

АВТОРЫ

aUTHOR_ID	автор	Книга	Author_Nationality
Auth_001	Орсон Скотт Кард	Игра Эндера	Соединенные Штаты
Auth_001	Орсон Скотт Кард	Дети Разума	Соединенные Штаты
Auth_002	Маргарет Этвуд	Сказка горничной	Канада

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

Если вы удалили две книги «Дети разума» и «Игра Эндера», вы полностью удалили из базы данных автора «Карту Орсона Скотта» и его гражданство.
Вы не можете добавить нового автора в базу данных, пока вы не добавите книгу; что если автор еще не опубликован или вы не знаете название книги, которую она написала?
Если «Орсон Скотт Кард» изменил свое гражданство, вам придется изменить его во всех записях, в которых он появляется. Наличие нескольких записей с одним и тем же автором может привести к получению неточных данных: что, если лицо, занимающееся вводом данных, не понимает, что для него существует несколько записей, и изменяет данные только в одной записи?
Вы не можете удалить книгу типа «Сказка о служанке», не удалив при этом и самого автора.

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

Обзор процесса нормализации

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

Результаты проверки
объектов недвижимости

N_объекта

Адрес

Дата

Время

Комментарий

N_сотрудника

ФИО_сотредника

N_маш

Ленина 6-31

8,01,03

22,11,03

15,04,04

10:00

20:00

12:00

Требуется ремонт

311

312

Лис

Крот

Кот

03-12

07-11

21-13

……

Первый этап НФ – приведем к
НФ. Для этого добавим новые строки. Определим потенциальные клюю отношения:

(N_объекта, Дата)

(N_сотрудника, Дата, Время)

(N_маш, Дата, Время)

Второй этап – приведение
отношения ко 2-ой НФ. Для этого выписываются функциональные зависимости и
устраняются частичные функциональные зависимости.

f1: N_объекта,
Дата -> Время, Комментарий, N_сотрудника,
ФИО_сотрудника, N_маш

f2: N_объекта
-> Адрес

f3: N_сотрудника
-> ФИО_сотрудника(транзитивная
зависимость)

f4: N_сотрудника,
Дата -> N_маш(частичная зависимость)

f5: N_маш,
Дата, Время -> N_объекта,
Адрес(для потенциальных ключей)

f6: N_сотрудника,
Дата, Время -> N_объекта,
Адрес, Комментарий.

Что бы привести отношение ко 2-ой
НФ его необходимо будет разбить на три отношения:

Объект ( N_объекта,Адрес)

Сотрудник (N_сотрудника, ФИО_сотрудника)

Проверка (N_объекта, Дата, Время, Комментарий, N_сотрудника, N_маш)

Полученное отношениеудовлетворяет не только 2-ой НФ, но и 3-ей
НФ.

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

Сотрудник – Машина

(N_сотрудника, N_маш, Дата)

Проверка – Дата

(N_объекта, Время, Комментарий, N_сотрудника)

Четвертый этап – отношение многозначных
зависимостей,которые позволяют
избавиться от избыточности.

Математические модели

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

Математическая модель — это совокупность количественных характеристик некоторого объекта (процесса) и связей между ними, представленных на языке математики.

Хорошо известны математические модели для первых двух примеров. Они отражают физические законы и представляются в виде формул:

Это примеры зависимостей, представленных в функциональной форме. Первую зависимость называют корневой (время пропорционально квадратному корню высоты), вторую — линейной.

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

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

2НФ — вторая нормальная форма

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

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

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

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

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