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

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

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

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

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

Примечание.

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

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

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

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

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

Примечание.

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

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

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

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

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

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

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

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

и базы данных

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

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

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

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

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

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

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

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

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

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

• солидный 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, как клеймили кибернетику, потом полюбили информатику и стали устраивать препоны перемещению высоких технологий на уровне стран, становится ясно почему реляционные базы данных так живучи и хороши. Почему классический стиль программирования по сей день живет, а объектно-ориентированное программирование просто ценится, но еще не властвует.

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

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

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

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

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

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

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

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

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

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

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

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

Пусть R - ϶ᴛᴏ отношение. С одной стороны, оно имеет конкретное (постоянное) значение в данный момент времени. С другой стороны, это переменная, которая в каждый момент времени может принять неĸᴏᴛᴏᴩᴏᴇ новое значение.

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

Определœение функциональной зависимости. Пусть R – переменная отношения. X и Y – произвольные подмножества множества атрибутов R . Тогда Y функционально зависит от X , что в символическом виде записывается как X → Y (читается как ʼʼX функционально определяет Y ʼʼ) тогда и только тогда, когда для любого допустимого значения R каждое значение X связано точно с одним значением Y .

Здесь X называют детерминантом ФЗ, а Y – зависимой частью ФЗ.

Пример : Пусть R - ϶ᴛᴏ отношение Students . X – код студента͵ а Y – множество всœех атрибутов студента. Тогда X → Y , т.к. X представляет собой первичный ключ, который уникально идентифицирует запись в таблице Students .

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

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

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

Пример :

{StudentID , FirstName , LastName , MiddleName } → {BirthDate } – приводимая ФЗ.

{StudentID } → {BirthDate } – неприводимая ФЗ.

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

1. Зависимая часть каждой функциональной зависимости содержит только один атрибут.

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

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

Рассмотрение множества неприводимых ФЗ важно для нормализации отношений.

Выделяют два вида ФЗ:

1. Тривиальные ФЗ - ϶ᴛᴏ ФЗ, в которых правая часть (Y ) является подмножеством левой части (X ). С практической точки зрения они не представляют значительного интереса, однако с точки зрения формальной теории зависимостей крайне важно учитывать их наличие.

2. Нетривиальные ФЗ . Οʜᴎ действительно являются ограничениями целостности данных, в связи с этим в дальнейшем мы будем рассматривать именно нетривиальные ФЗ.

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

Пусть A , B , C - ϶ᴛᴏ подмножества множества атрибутов отношения R , AB – объединœение этих подмножеств.

1. Правило рефлексивности . В случае если множество B является подмножеством множества А , то А → В . (По сути, это определœение тривиальной зависимости.)

2. Правило дополнения . В случае если А → B , то АС → ВС .

3. Правило транзитивности . В случае если А → B и B→C , то А → С .

Каждое из этих правил должна быть доказано на базе определœения ФЗ.

При этом в целях упрощения получения всœех ФЗ можно вывести еще несколько дополнительных правил (пусть D - ϶ᴛᴏ еще одно произвольное подмножество множества атрибутов R ):

4. Правило самоопределœения . А → А .

5. Правило декомпозиции . В случае если А → ВС , то А → B и A → C .

6. Правило объединœения . В случае если А → В и А → С , то А → ВС .

7. Правило композиции . В случае если А → B и С → D , то АС → BD .

8. Теорема всœеобщего объединœения . В случае если А→ B и C → D , то А(С – В) → BD .

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

При этом следует иметь в виду, что эти правила не обеспечивают чёткого алгоритма получения всœех ФЗ. Более того, такого алгоритма не существует. Единственный путь - ϶ᴛᴏ перебор всœех вариантов.

Понятие функциональной зависимости - понятие и виды. Классификация и особенности категории "Понятие функциональной зависимости" 2017, 2018.