Полная функциональная зависимость реквизитов

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

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

Например,
отношение Студент = (Номер, Фамилия, Имя,
Отчество, Дата, Группа) находится в
первой нормальной форме.

1.10.2. Вторая нормальная форма

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

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

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

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

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

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

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

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

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

1. Таблица
должна содержать данные об одном типе
объектов;

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

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

Отношение
Студент = (Номер, Фамилия, Имя, Отчество,
Дата, Группа) находится в первой и во
второй нормальной форме одновременно,
так как описательные реквизиты однозначно
определены и функционально зависят от
ключа Номер.

Отношение
Успеваемость = (Номер, Фамилия, Имя,
Отчество, Дисциплина, Оценка) находится
в первой нормальной форме и имеет
составной ключ Номер + Дисциплина. Это
отношение не находится во второй
нормальной форме, так как атрибуты
Фамилия, Имя, Отчество не находятся в
полной функциональной зависимости с
составным ключом отношения.

Лекция 2. Продолжение прошлой лекции

  • Третья нормальная форма;

  • Отношения;

  • Ключ;

  • Пример выгрузки данных;

  • Заполнение таблиц;

  • Реляционные операции;

  • Соединение таблиц;

  • Изменение таблицы.

2.1. Третья нормальная форма

Понятие
третьей нормальной формы основывается
на понятии нетранзитивной зависимости.

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

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

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

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

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

Исходный
информационный объект Студент группы
можно представить в виде совокупности
правильно структурированных информационных
объектов (Студент и Группа), реквизитный
состав которых тождественен исходному
объекту.

Отношение
Студент = (НомерСтудента, Фамилия, Имя,
Отчество, Дата, НомерГруппы) и Группа =
(НомерГруппы, НомерСтаросты) находится
одновременно в первой, второй и третьей
нормальных формах.

Соседние файлы в папке Основное

  • #
  • #
  • #
  • #
  • #

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

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

Реляционная модель данных

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

Для реляционных отношений характерны следующие особенности.

  1. Любой тип записи содержит только простые (по структуре) элементы данных.
  2. Порядок кортежей в таблице несуществен.
  3. Упорядочение значащих атрибутов в кортеже должно соответствовать упорядочению атрибутов в реляционном отношении.
  4. Любое отношение должно содержать один атрибут или более, которые вместе составляют уникальный первичный ключ.
  5. Если между двумя реляционными отношениями существует зависимость, то одно отношение является исходным, второе — подчиненным.
  6. Чтобы между двумя реляционными отношениями существовала зависимость, атрибут, служащие первичным ключом в исходном отношении, должны также присутствовать в подчиненном отношении.

Пример 5.1. Представим БД «Учебный процесс»в виде реляционной модели (
таблица
5.1).

Таблица
5.1.

а) Отношение ГРУППА
Индекс ИГ Название группы НГ Количество ответов КОЛ Проходной балл ПБАЛЛ
1 А1 16 4,3
2 А2 28 4,0
3 А3 18 4,3
б) Отношение СТУДЕНТ
Номер зачетной книжки НЗ ИГ Фамилия И.О. СФИО Год рождения ГР

Понятие реляционный (англ. relationотношение) связано с разработками известного американского специалиста в области систем баз данных Е. Кодда.

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

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

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

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

Таблица
5.2.
Пример реляционной таблицы

№ личного дела Фамилия Имя Отчество Дата рождения Группа
16493 Сергеев Петр Михайлович 01.01.76 ИСТ 11
16593 Петрова Анна Владимировна 15.03.75 СК 12
16693 Анохин Андрей Борисович 14.04.76 ИСТ 11

Понятие информационного объекта

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

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

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

Пример 5.3 В таблице 5.2 представлен пример структуры и экземпляров информационного объекта Студент.

В информационном объекте Студент ключом является реквизит Номер (№ личного дела), к описательным реквизитам относятся: Фамилия (Фамилия студента), Имя (Имя студента), Отчество (Отчество студента), Дата (Дата рождения), Группа (№ группы). Если отсутствует реквизит Номер, то для однозначного определения характеристик конкретного студента необходимо использование составного ключа из трех реквизитов: Фамилия + Имя + Отчество.

Таблица
5.2.
Пример структуры и экземпляров информационного объекта

Структура Номер Фамилия Имя Отчество Дата Группа
Экземпляры инф.объекта Студент 16493 Сергеев Петр Михайлович 01.01.96 ИСТ 11
16593 Петрова Анна Викторович 15.03.95 СК 12
16693 Анохин Роман Борисович 14.04.96 ИСТ 11

Пример 5.4 На
рис.
5.1 изображен пример компактного представления информационного объекта Студент с обозначением имени объекта, ключа и указанием максимально возможного числа экземпляров записи.

Пример компактного представления информационного объекта

Рис.
5.1.
Пример компактного представления информационного объекта

Пример 5.5 Пример представления информационного объекта Студент в виде графа на
рис.
5.2.

Пример представления информационного объекта в виде графа

Рис.
5.2.
Пример представления информационного объекта в виде графа

Нормализация отношений

Понятие нормализации отношений

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

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

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

Е. Коддом выделены три нормальные формы отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей (самой совершенной) нормальной форме.

Первая нормальная форма

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

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

Например, отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) находится в первой нормальной форме.

Вторая нормальная форма

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

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

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

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

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

Графическое изображение функциональной зависимости реквизитов

Рис.
5.3.
Графическое изображение функциональной зависимости реквизитов

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

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

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

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

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

Пример 5.7

Отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) находится в первой и во второй нормальной форме одновременно, так как описательные реквизиты однозначно определены и функционально зависят от ключа Номер.
Отношение Успеваемость = (Номер, Фамилия, Имя, Отчество, Дисциплина, оценка) находится в первой нормальной форме и имеет составной ключ Номер + Дисциплина. Это отношение не находится во второй нормальной форме, так как атрибуты Фамилия, Имя, Отчество не находятся в полной функциональной зависимости с составным ключом отношения.

Третья нормальная форма

Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости.

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

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

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

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

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

Пример 5.9 «Расщепление» информационного объекта, содержащего транзитивную зависимость описательных реквизитов, показано на
рис.
5.4. Как видно из
рис.
5.4, исходный информационный объект Студент группы представляется в виде совокупности правильно структурированных информационных объектов (Студент и Группа), реквизитный состав которых тождественен исходному объекту.

Отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) находится одновременно в первой, второй и третьей нормальной форме.

Расщепление" информационного объекта, содержащего транзитивную зависимость описательных реквизитов

Рис.
5.4.
Расщепление» информационного объекта, содержащего транзитивную зависимость описательных реквизитов

Полная функциональная зависимость неключевых реквизитов ИО от ключа означает, что в каждый момент времени значение ключа однозначно определяет
 [c.515]

Для проведения анализа внутренней структуры — полной функциональной зависимости реквизитов от ключа и отсутствия транзитивной зависимости неключевых реквизитов обычно применяется графический анализ (рис. 7.1).
 [c.516]

Понятие функциональной зависимости позволяет определить ключевые признаки, однозначно идентифицирующие объекты учетных данных. Пример структуры функционально связанных схем отношений ТОВАР, ОТДЕЛ, СКЛАД приведен на схеме 14. Между некоторыми схемами отношений Sj и S,- существует функциональная связь, если найдется такой набор атрибутов К s AJ П AI, который является ключом схемы отношения 5,-. Функционально связанные схемы отношений обладают свойством соединения без потерь [62,. с. 165]. Это значит, что из нескольких исходных отношений можно получить новое отношение без изменения зависимостей, например функциональных, между атрибутами в результирующем отношении. Функциональную связь между схемой отношения Sj и схемой отношения 5,- обозначим Sj->-S/. В дальнейшем понятие функциональной связи положим в основу построений логической и физической структуры баз данных.
 [c.121]

Функциональные зависимости и ключи
 [c.76]

С помощью функциональных зависимостей определяется понятие ключа отношения, точнее ряд разновидностей ключей — вероятные, первичные и вторичные.
 [c.80]

В отношениях с большим числом строк нахождение первичного ключа путем непосредственного применения определения достаточно затруднено. Кроме того, на стадии проектирования ЭИС значения многих отношений просто неизвестны. Поэтому практически первичный ключ отношения определяется по известным функциональным зависимостям.
 [c.81]

Каждое значение первичного ключа встречается только в одной строке отношения. Значение любого атрибута в этой строке также единственное. Если через К обозначить атрибуты первичного ключа в отношении R(A,B, ,…, J), то справедливы следующие функциональные зависимости К — А, К — В, К -> С,. .., К -> J. Набор атрибутов первичного ключа функционально определяет любой атрибут отношения. Обратное также верно если найдена группа атрибутов, которая функционально определяет все атрибуты отношения по отдельности, и эту группу нельзя сократить, то найден первичный ключ отношения.
 [c.81]

Знание ключа отношения позволяет устанавливать ряд функциональных зависимостей, например, в ТЗ ZEN -> BIG, RAM, AST- BIG.
 [c.82]

Если заранее известно, что вероятный ключ в отношении только один, то его можно найти простым способом. Вероятный ключ (если он единственный, т.е. совпадает с первичным ключом) -это набор атрибутов, которые не встречаются в правых частях всех функциональных зависимостей. Иными словами, из полного списка атрибутов отношения необходимо вычеркнуть атрибуты, встречающиеся в правых частях всех функциональных зависимостей. Оставшиеся атрибуты образуют первичный ключ.
 [c.85]

Вероятным ключом в Т4 являются атрибуты Магазин, Изделие. Для доказательства можно сослаться на функциональные зависимости  [c.86]

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

Обозначим в R1 первичный ключ X через 1, неключевые атрибуты — через 2, в R2 X через 3, первичный ключ как 3,4, неключевые атрибуты — 5. Для R1 R2 будут справедливы функциональные зависимости
 [c.106]

Из аналогии определений веерного отношения и функциональной зависимости следует утверждение если существует веерное отношение, то ключ зависимого отношения функционально определяет ключ основного отношения, и наоборот, если ключ одного отношения функционально определяет ключ второго отношения, то первое отношение может быть зависимым, а второе — основным в некотором веерном отношении.
 [c.111]

Для доказательства достаточно заметить, что в формулировке каждое значение зависимого отношения связано с единственным значением основного отношения точным представителем значения отношения является значение его первичного ключа, и отсюда следует приведенная выше формулировка о функциональных зависимостях между ключами.
 [c.111]

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

Исходное множество функциональных зависимостей и атрибуты первичного ключа получаются так же, как при формировании множества отношений в ЗНФ. Алгоритм иллюстрируется тем же примером, что и в п. 2.2.2.
 [c.112]

Для каждой функциональной зависимости вида А — В создается файл Fi(A,B)- Каждый блок взаимно-однозначных соответствий также порождает файл с ключом, равным старшему по объему понятия атрибуту.
 [c.112]

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

Рассмотрим алгоритм формирования иерархической БД на основе известного множества атрибутов и функциональных зависимостей. Исходное множество функциональных зависимостей и атрибуты первичного ключа получаются так же, как при формировании множества отношений в ЗНФ. Алгоритм иллюстрируется тем же примером, что и в п. 2.2.2.
 [c.121]

В п. 2.2.1 приведен метод поиска вероятного ключа отношения (если он единственный). Из полного списка атрибутов отношения вычеркните те, которые встречаются в правых частях функциональных зависимостей. Оставшиеся атрибуты образуют вероятный ключ. Докажите корректность этого метода. Какое множество функциональных зависимостей необходимо использовать  [c.139]

Из каких атрибутов состоит первичный ключ отношения, в котором нет справедливых функциональных зависимостей  [c.140]

Применительно к ИО ЖХО все реквизиты принимают атомарное значение — отсутствует многозначность реквизитов. Неключевые реквизиты функционально полно зависят от составного ключа, поскольку в каждый момент времени одному значению ключа соответствует одно и только одно значение неключевого реквизита в экземпляре ИО. Отсутствует транзитивная зависимость неключевых реквизитов между собой.
 [c.516]

Хотя на основе функциональных зависимостей можно установить более сильную нормальную форму Бойса-Кодда (БКНФ), практически она применяется редко. Во-первых, база данных в БКНФ не всегда существует, во-вторых, ее отличие от ЗНФ обычно связано с наличием нескольких ключей в отношении, что в экономических приложениях встречается исключительно редко.
 [c.91]

Многие СУБД содержат средства проверки уникальности первичного ключа, а не соблюдения функциональных зависимостей. СУБД семейства DBASE не проверяют даже уникальность значений ключа. Таким образом, контроль за соблюдением функциональных зависимостей в отношении после его корректировки — обязанность прикладных программистов или администратора БД.
 [c.106]

Понравилась статья? Поделить с друзьями:
  • Польза приносимая обществу торговым бизнесом
  • Работа на такси бизнес класса на личном авто
  • Рабочий тормозной цилиндр газель бизнес 4216
  • Рейтинг страховых компаний по каско banki ru
  • Рейтинг страховых компаний по размеру выплат