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

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

Информация > формализация >> данные

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

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

Функциональная зависимость: «правильное решение = программа (программист)» и условие: «непрерывное соответствие задаче» действительны в большинстве случаев, но только совместно. Но это не та математическая основа, которая применяется при создании баз данных.

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

и базы данных

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

Основные варианты хранения, отличающиеся вариантами использования данных:

• файлы;
• базы данных.

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

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

Личный опыт и коллективный разум

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

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

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

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

• солидный Oracle;
• требовательный MS SQL Server;
• популярный MySQL.

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

Особенности программирования и данных

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

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

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

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

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

БД: простая зависимость в данных

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

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

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

• «определить сущности»;
• «исключить избыточность»;
• «зафиксировать взаимосвязи»;
• «обеспечить достоверность».

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

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

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

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

Не обязательно, но вовсе не помешает представлять функциональную зависимость как:

F(x1, x2, …, xN) = (y1, y2, …, yN).

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

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

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

О старом добром Excel

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

• PHP, Perl, JavaScript, C++, Delphi.
• MySQL, Oracle, Visual FoxPro.

• Word.
• Excel.

Некоторые пользователи умудряют делать самостоятельно (без помощи программистов) в Word базы данных - реальный нонсенс.

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

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

Если учесть, что Excel - это совсем не база данных, но многие юзеры (не программисты) его именно так используют, а Oracle - это сложнейшее и мощнейшее достижение большого коллектива разработчиков именно в области баз данных, то становится естественным признать - база данных это представление конкретного программиста (коллектива) о конкретной задаче и ее решении.

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

О том, куда реляционные отношения идут

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

Как бы ни была прекрасна функциональная зависимость в контексте математики:

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

Вариантов отношений можно придумать великое множество. Это математика с логикой, и она строгая! Информация - это своя математика, особенная. В ней о формальности можно говорить только с очень большим минусом.

Можно формализовать работу отдела кадров, написать АСУ для добычи нефти или производства молока, хлеба, сделать выборку в огромной базе гугла, яндекса или рамблера, но результат будет всегда статичен и каждый момент времени одинаков!

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

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

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

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

Если сменить тон и прислушаться к пульсу динамики, то все можно расписать на объекты. В первом приближении имя колонки в таблице - это объект, список имен - тоже объект, короче таблица - это объект шапки и в нем имена колонок в шапке. И шапки может вовсе не быть...

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

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

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

Определение: Если даны два атрибута X и Y некоторого отношения, то говорят, что Y функционально зависит от X, если в любой момент времени каждому значению X соответствует ровно одно значение Y. Функциональная зависимость обозначается X -> Y. Отметим, что X и Y могут представлять собой не только единичные атрибуты, но и группы, составленные из нескольких атрибутов одного отношения. Можно сказать, что функциональные зависимости представляют собой связи типа "один ко многим", существующие внутри отношения.

2-аянормальная форма (2НФ) отношения. Определение полной функциональной зависимости и 2НФ. Характеристика отношения во 2НФ. Алгоритм приведения ко 2НФ. Теорема Хита. Примеры.

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

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

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

2NF - вторая нормальная форма.

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

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

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

1)не должны появляться ранее отсутствовавшие кортежи;

2)на отношениях новой схемы должно выполняться исходное множество функциональных зависимостей.

Теорема Хита

Пусть дано отношение .

Если r удовлетворяет функциональной зависимости , то оно равно соединению его проекцийи

3-я нормальная форма (3НФ) отношения. Определение транзитивной зависимости и 3НФ.Алгоритм приведения к 3НФ.Нормальная форма Бойса-Кодда (НФБК).Определение и алгоритм приведения к НФБК. Характеристика отношения в 3НФ и в НФБК. Примеры.

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

· каждый поставщик имеет только один адрес,

· каждый поставщик поставляет товар по определенной цене,

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

· каждый склад имеет свой объем.

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

· адрес функционально зависит от поставщика,

· цена функционально зависит от товара и поставщика,

· номер склада функционально зависит от товара и поставщика,

· объем функционально зависит от номера склада.

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

Пусть отношение r имеет схему R , X и Y – подмножества R . Отношение r удовлетворяет функциональной зависимости X→Y , если π Y (σ X=x (r)) имеет не более чем один кортеж для каждого значения xÎX , т. е. значения атрибутов X однозначно определяют значения атрибутов Y.

Функциональную зависимость будем обозначать следующим образом:

· Поставщик → Адрес,

· {Товар, Поставщик}→ Цена,

· {Товар, Поставщик}→ Склад,

· Склад → Объем.

А читаются они так:

· Поставщик определяет Адрес,

· Товар и Поставщик определяют Цену,

· Товар и Поставщик определяют Склад,

· Склад определяет Объем.

На языке функциональных зависимостей ключ для схемы R – это подмножество KÍR , такое, что K →R , и никакое собственное подмножество K¢ÍK этим свойством не обладает.

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

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

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

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

Например, атрибут ФИО является составным, состоит из трех данных: фамилии, имени и отчества.

Чтобы привести схему в 1НФ, нужно все составные атрибуты заменить простыми.

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

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

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

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

Чтобы привести схему, находящуюся в 1НФ, ко 2НФ, нужно разбить ее на несколько схем:

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

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

В примере с отношением Поставки в результате приведения схемы ко 2НФ получатся два отношения:

Поставки_1 (Товар , Поставщик , Цена, Склад, Объем ),

Поставки_2 (Поставщик , Адрес ).

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

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

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

Схема отношения Поставки_1 (Товар , Поставщик , Цена, Склад, Объем ) не находится в 3НФ, так как в ней присутствует транзитивная зависимость:

{Товар, Поставщик } → Склад , Склад → Объем .

Чтобы привести схему, находящуюся во 2НФ, в 3НФ, нужно:

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

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

В примере с отношением Поставки_1 в результате приведения схемы к 3НФ получатся два отношения:

Поставки_1_1 (Товар , Поставщик , Цена, Склад ),

Поставки_1_2 (Склад , Объем ).

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

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

В рассмотренном примере в результате декомпозиции вместо одного отношения Поставки мы получили три новых отношения:

Поставки_1_1 (Товар , Поставщик , Цена, Склад ),

Поставки_1_2 (Склад , Объем ),

Поставки_2 (Поставщик , Адрес ).

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

Как вы заметили, схема в 3НФ избавляет базу данных от дублирования информации и аномалий обновления, но не всегда.

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

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

· каждый преподаватель ведет только один предмет, но каждый предмет может вести несколько преподавателей.

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

· {Студент, Предмет} → Преподаватель;

· Преподаватель → Предмет.

Из функциональных зависимостей вытекает, что ключом отношения Лекции будет набор атрибутов {Студент , Предмет }.

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

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

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

Приведя отношение к НФБК, мы получим два отношения: Лекции_1 (Студент, Преподаватель ) и Лекции_2 (Преподаватель, Предмет ).

Многозначные зависимости

Атрибут X многозначно определяет атрибут Y в R (или Y многозначно зависит от X ), если каждому значению атрибута X соответствует множество (возможно, пустое) значений атрибута Y , никак не связанных с другими атрибутами R . То есть для наличия в отношении многозначной зависимости необходимо иметь как минимум три атрибута.

Многозначная зависимость обозначается двойной стрелкой: X→→Y .

Рассмотрим отношение Преподаватель (Номер , Имя_ребенка , Предмет , Должность ). Предметная область накладывает следующие ограничения:

· каждый преподаватель может иметь несколько детей,

· каждый преподаватель может вести несколько предметов,

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

· каждый предмет могут вести несколько преподавателей.

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

· Номер→→Имя_ребенка,

· Номер→→Предмет,

· Номер→Должность.

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

Для избавления от этих аномалий необходимо привести отношение к четвертой нормальной форме.

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

После приведения отношения Преподаватель к 4НФ мы получим три отношения:

Преподаватель_1 (Номер , Должность ),

Преподаватель_2 (Номер , Имя_ребенка ),

Преподаватель_3 (Номер , Предмет ).

Свойства декомпозиции

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

Определение: Если даны два атрибута X и Y некоторого отношения, то говорят, что Y функционально зависит от X, если в любой момент времени каждому значению X соответствует ровно одно значение Y. Функциональная зависимость обозначается X -> Y. Отметим, что X и Y могут представлять собой не только единичные атрибуты, но и группы, составленные из нескольких атрибутов одного отношения. Можно сказать, что функциональные зависимости представляют собой связи типа "один ко многим", существующие внутри отношения.

2-аянормальная форма (2НФ) отношения. Определение полной функциональной зависимости и 2НФ. Характеристика отношения во 2НФ. Алгоритм приведения ко 2НФ. Теорема Хита. Примеры.

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

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

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

2NF - вторая нормальная форма.

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

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

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

1)не должны появляться ранее отсутствовавшие кортежи;

2)на отношениях новой схемы должно выполняться исходное множество функциональных зависимостей.

Теорема Хита

Пусть дано отношение .

Если r удовлетворяет функциональной зависимости , то оно равно соединению его проекцийи

3-я нормальная форма (3НФ) отношения. Определение транзитивной зависимости и 3НФ.Алгоритм приведения к 3НФ.Нормальная форма Бойса-Кодда (НФБК).Определение и алгоритм приведения к НФБК. Характеристика отношения в 3НФ и в НФБК. Примеры.

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

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

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

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

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

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

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

Эта запись читается так:

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

Точно так же, если функция U зависит от двух аргументов то эта зависимость обозначается следующим образом:

Здесь буквы f, х и у также не являются сомножителями.

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

Вместо буквы употребляют и другие буквы чаще всего .

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

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

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

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

2) функцию можно задать графически;

3) функцию можно задать математической формулой.

f. Приведем примеры. Известно, что при вращении махового колеса возникают напряжения, которые стремятся разорвать его обод. Если обод колеса сделан из однородного материала, то напряжения зависят только от скорости вращения. Обозначая скорость через v, а напряжение в ободе через , мы можем записать что

Теория сопротивления материалов дает такую таблицу для значений функции (4), если обод сделан из литой стали:

Здесь v измеряется в метрах в секунду - в ньютонах на квадратный сантиметр.

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

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

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

h. От первых двух недостатков свободен графический способ задания функции.

Чтобы пояснить графический способ рассмотрим такой пример.

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

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

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

Для мягкой стали мы получим следующую кривую (рис. 31):

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

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

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

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

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

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

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

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

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

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

С другой стороны, математический анализ, получая эту прекрасную пищу, сам растет и совершенствуется.

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