Функциональная взаимозависимость. Если существует функциональная зависимость вида А->В и В->А, то между А и В имеется взаимно однозначное соответствие, или функциональная взаимозависимость, обозначаемая как А<->В или В<->А.
Если отношение находится в 1НФ, то все неключевые атрибуты функционально зависят от ключа с различной степенью зависимости.
Частичной функцио нальной зависимостью (частичной ФЗ) называется зависимость неключевого атрибута от части составного ключа. В рассматриваемом отношении атрибут Должн находится в функциональной зависимости от атрибута ФИО, являющегося частью ключа. Тем самым атрибут Должн находится в частичной зависимости от ключа отношения.
Альтернативным вариантом является полная функциональная зависи мость неключевого атрибута от всего составного ключа. В нашем примере атрибут ВидЗан находится в полной функциональной зависимости от составного ключа.
Атрибут С зависит от атрибута А транзитивно (существует транзитив ная зависимость), если для атрибутов А, В, С выполняются условия А->В и В->С, но обратная зависимость отсутствует. В отношении на рис. 4.4 транзитивной зависимостью связаны атрибуты:
Ф И О ->Д олжн -> Оклад
Между атрибутами может иметь место многозначная зависимость.
В отношении R атрибут В многозначно зависит от атрибута А, если каждому значению А соответствует множество значений В, не связанных с другими атрибутами из R,
Многозначные зависимости могут быть «один ко многим» (1:М), «многие к одному» (М:1) или «многие ко многим» (М:М), обозначаемые соответственно: А=>Б, А<=Би А<=>Б.
Например, пусть преподаватель ведет несколько предметов, а каждый предмет может вестись несколькими преподавателями, тогда имеет местозависимость ФИО<=>Предмет. Так, из таблицы, приведенной на рис. 4.4, видно, что преподаватель Иванов И.М. ведет занятия по двум предметам, а дисциплина СУБД - читается двумя преподавателями: Ивановым И.М. и Петровым М.И.
Замечание . В общем случае между двумя атрибутами одного отношения могут существовать зависимости: 1:1, 1:М, М:1 и М:М. Поскольку зависимость между атрибутами является причиной аномалий, стараются расчленить отношения с зависимостями атрибутов на несколько отношений. В результате образуется совокупность связанных отношений (таблиц) со связями вида 1:1, 1:М, М:1 и М:М (подраздел 3.2). Связи между таблицами отражают зависимости между атрибутами различных отношений.
Взаимно независимые атрибуты. Два или более атрибута называютсявзаимно независимыми, если ни один из этих атрибутов не является функционально зависимым от других атрибутов. В случае двух атрибутов отсутствие зависимости атрибута А от атрибута В можно обозначить так: A¬->B. Случай, когда A¬->В и B¬->A, можно обозначить А¬<->В.
Чтобы определить ключи и понять логические следствия функциональных зависимостей в общем случае, необходимо вычислить замыкание F + изF или по крайней мере знать для заданногоF и функциональной зависимостиX Y , содержится лиX Y вF + . Для этого необходимо иметь правила вывода, которые указывают, как из одной или более зависимостей выводить другие зависимости.
Множество таких правил называют аксиомами Армстронга . Предположим, что задана некоторая схема отношения с множеством атрибутовМ, универсальным множеством атрибутов, и множество функциональных зависимостейF , связывающих только атрибуты, принадлежащиеМ. Тогда имеем следующие правила вывода (аксиомы):
А1: (рефлексивность). ЕслиY ≤ X ≤ М, то X Y логически следует изF . Заметим, что это правило даеттривиальные зависимости, т. е. зависимости, правая часть которых содержится в левой части. Его использование не зависит отF .
А2: (пополнение). ЕслиX Y иZ≤ М , тоX UZ Y UZ . Важно напомнить, что данная зависимостьX Y либо принадлежитF , либо может быть выведена из принадлежащихF зависимостей с использованием описываемых аксиом.
A3:(транзитивность). ЕслиX Y иY Z, тоX Z .
Относительно легко доказывается, что аксиомы Армстронга являются надежными, т. е. приводят только к истинным заключениям. Это означает, что используя их, мы не можем вывести из F какую-либо зависимость, которая не принадлежитF + . Более сложно доказать их полноту, означающую, что эти аксиомы могут быть использованы для получения каждого справедливого следствия из зависимостей. Это означает, что при заданном множестве зависимостейF правила позволяют нам вывести все зависимости, принадлежащиеF + .
Из аксиом Армстронга выводятся еще 5 аксиом (расширения, продолжения, псевдотранзитивности, объединения и декомпозиции), используемых для построенияполного семейства ФЗ.
Функциональная зависимость описывает связь между атрибутами и является одним из основных понятий нормализации. Предположим, что реляционная схема имеет атрибуты (A, B, C,…, Z) и вся база может быть представлена в виде одного универсального отношения R=(A, B, C,…, Z). Следовательно, каждый атрибут в базе имеет уникальное имя.
Если A и B – атрибуты некоторого отношения R, и каждое значение А связано с одним и только одним значением В (причем каждый из атрибутов может состоять из одного или нескольких атрибутов), то атрибут В функционально зависим от атрибута А (ВàА).
Функциональная зависимость, справедливая при любых условиях, называется тривиальной . Нетривиальные зависимости определяют ограничения целостности для отношений.
Транзитивная зависимость для атрибутов A, B и C некоторого отношения означает следующее: если АàВ и ВàС, то С транзитивно зависит от атрибута А через атрибут В (при условии, что А функционально не зависит от В или С).
Для исключения избыточности данных, что может привести к потере целостности, необходимо использовать минимально достаточное множество зависимостей.
Проектирование базы данных с помощью нормализации начинают с определения функциональных зависимостей, очевидных с точки зрения семантики, т.е. приведение к первой нормальной форме.
Таблица, находящаяся в первой нормальной форме, должна отвечать следующим требованиям:
1) таблица не должна иметь повторяющихся записей;
2) в таблице должны отсутствовать повторяющиеся группы полей;
3) каждое поле должно быть семантически неделимым.
Таблица, находящаяся во второй нормальной форме, должна отвечать всем требованиям 1НФ, любое неключевое поле однозначно идентифицируется полным набором ключевых полей, то есть каждый атрибут отношения находится в полной или частичной функциональной зависимости от другого атрибута.
Функциональная зависимость АàВ является полной функциональной зависимостью, если удаление какого либо атрибута из А приводит к утрате этой зависимости. Функциональная зависимость АàВ называется частичной , если в А есть некий атрибут при удалении которого эта зависимость сохраняется.
Таблица, находящаяся в третьей нормальной форме, должна отвечать всем требованиям 2НФ, ни одно из неключевых полей не идентифицируется при помощи другого неключевого поля, то есть отношение, которое находится в первой и второй нормальных формах и не имеет атрибутов, не входящих в первичный ключ атрибутов, которые находились бы в транзитивной функциональной зависимости от этого первичного ключа.
Нормальная форма Бойса-Кода (НФБК) основана на функциональных зависимостях, в которых учитываются все потенциальные ключи отношения, но с более строгими ограничениями.
Детерминантом функциональной зависимости является атрибут (или группа атрибутов), от которого полностью функционально зависит некоторый другой атрибут.
Для проверки принадлежности отношения к НФБК необходимо найти все его детерминанты и убедиться в том, что они являются потенциальными ключами.
Различие между 3НФ и НФБК заключается в том, что функциональная зависимость АàВ допускается в отношении 3НФ, если атрибут В является первичным ключом, а атрибут А не обязательно является потенциальным ключом. В отношении НФБК эта зависимость допускается только тогда, когда атрибут А является потенциальным ключом. Следовательно, НФБК является более строгой версией 3НФ, поскольку каждое отношение НФБК является 3НФ, но не всякое отношение 3НФ является НФБК.
Отношения находятся в НФБК только в том случае, если каждый его детерминант является потенциальным ключом.
Четвертая нормальная форма (4НФ) – отношение в НФБК, которое не содержит нетривиальных многозначных зависимостей.
Многозначная зависимость представляет такую зависимость между атрибутами отношения (например А, В и С), что каждое значение А представляет собой множество значений для В и множество значений для С. Однако множество значений В и С не зависят друг от друга.
Многозначная зависимость может быть дополнительно определена как тривиальная или нетривиальная. Многозначная зависимость АàВ некоторого отношения R определяется как тривиальная, если атрибут В является подмножеством атрибута А или . И наоборот, многозначная зависимость определяется как нетривиальная, если ни то ни другое условие не выполняется. Тривиальная многозначная зависимость не накладывает никаких ограничений на данное отношение, а нетривиальная – накладывает.
При разбиении отношения с помощью операции проекции используемый метод декомпозиции определяется точно. Необходимо, чтобы при обратном соединении полученных отношений можно было восстановить исходное отношение. Такая декомпозиция называется декомпозицией соединения без потерь (или беспроигрышным или неаддитивным соединением), поскольку при ее выполнении сохраняются все данные исходного отношения, а также исключается создание дополнительных фиктивных строк.
Пятая нормальная форма (5НФ), которая также называется проективно-соединительной нормальной формой, означает, что отношение в такой форме не имеет зависимостей соединения. Отношение R с подмножеством атрибутов А,В,…,Z удовлетворяет зависимости соединения, если каждое допустимое значение R равно соединению его проекций на подмножества А,В,…,Z.
a. При рассмотрении количественной стороны различных процессов мы почти всегда наблюдаем, что переменные величины зависят друг от друга; например, путь проходимый свободно падающим в пустоте телом зависит только от времени, давление в паровом котле зависит только от температуры пара.
Глубина океана в одном пункте постоянна, но в различных пунктах различна, она зависит только от двух переменных - от географической долготы и географической широты места.
Высота растущего дерева зависим от многих переменных - от солнечного освещения, от влажности, от количества питательных веществ в почве и т. д.
Мы видим, что некоторые переменные изменяются независимо, они и называются независимыми переменными или аргументами, другие же от них зависят их называют функциями.
Сама зависимость называется функциональной. Между прочим, функциональная зависимость представляет собой одно из самых важных понятий математики.
b. Следует всегда различать, от какого числа независимых переменных зависит функция. Проще всего поддаются изучению функции одной переменной, ими мы будем заниматься в первую очередь. Изучение функций многих переменных сложнее, но так или иначе сводится к изучению функций одной переменной.
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. Ввиду того, что перевод на язык формул функциональных зависимостей не является непосредственной задачей математики, мы будем предполагать, что функции уже выражены формулами. Таким образом, в дальнейшем мы будем заниматься только функциями, заданными матетатически.
Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В.
Обозначение : A → B. Это значит, что во всех кортежах с одинаковым значением атрибута А атрибут В будет иметь также одно и то же значение.
Если существует функциональная зависимость вида A→B и В→А, то между А и В имеется взаимно однозначное соответствие , или функциональная зависимость . О
Обозначение : A↔B или В↔А.
Если отношение находится в 1НФ, то все неключевые атрибуты функционально зависят от ключа с различной степенью зависимости.
Частичная зависимость (частичная функциональная зависимость) – зависимость неключевого атрибута от части составного ключа.
Полная функциональная зависимость – зависимость неключевого атрибута от всего составного ключа.
Атрибут С зависит от атрибута А транзитивно (существует транзитивная зависимость ), если для атрибута А, В, С выполняются условия A→B и В→С, по обратной зависимости отсутствуют.
В отношении R атрибут В многозначно зависит от атрибута А, если каждому значению А соответствует множество значений В, не связанных с другими атрибутами R.
Обозначения : А=>B, A<=B, A<=>B.
Два и более атрибута называются взаимно независимыми , если ни один из этих атрибутов не является функционально зависимым от других атрибутов.
Обозначения : А →В, А=В.
Нормальные формы:
Первая нормальная форма (1НФ). Отношение находится в 1НФ, если все его атрибуты являются простыми (имеют единственное значение).
Вторая нормальная форма (2НФ). Отношение находится в 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально зависит от первичного ключа (составного).
Третья нормальная форма (3НФ). Отношение находится в 3НФ в том и только в том случае, если все атрибуты отношения взаимно независимы и полностью зависят от первичного ключа.
Нормальная форма Бойса-Кодда (НФБК). Отношения находится в НФБК, если оно находится в 3НФ и в нем отсутствуют зависимости ключей (атрибутов составного ключа) от неключевых атрибутов.
Четвертая нормальная форма (4НФ). Отношения находится в 4НФ в том и только в том случае, когда существует многозначная зависимость А=>B, а все остальные атрибуты отношения функционально зависят от А.
Пятая нормальная форма (5НФ). Отношения находится в 5НФ, если оно находится в 4НФ и удовлетворяет зависимости по соединению относительно своих проекций.
Шестая нормальная форма (6НФ). Отношение находится в 6НФ тогда и только тогда, когда она не может быть подвергнута дальнейшей декомпозиции без потерь.
Обеспечение непротиворечивости и целостности данных в базе данных
Ответ :
Целостность – это свойство БД, означающее, что она содержит полную, непротиворечивую и адекватно отражающую предметную область информацию.
Различают:
Физическую целостность – наличие физического доступа к данным и то, что данные не утрачены.
Логическую целостность – отсутствие логических ошибок в БД, к которым относятся нарушение структуры БД или ее объектов, удаление или изменение установленных связей между объектами и т.д.
Поддержание целостности БД включает:
Проверку (контроль) целостности
Восстановление в случае обнаружения противоречий в базе.
Целостное состояние задается с помощью ограничений целостности (условий, которыми должны удовлетворять данные). Два типа ограничений целостности :
Ограничение значений атрибутов отношений . Например : требование недопустимости NULL-значений, недопустимости повторяющихся значений в атрибутах, контроль принадлежности значений атрибутов заданного диапазона.
Структурные ограничения на кортежи отношений . Определяет требования целостности сущностей и целостности ссылок .
Требование целостности сущностей состоит в том, что любой кортеж отношения должен быть отличным от любого другого кортежа этого отношения , иными словами, любое отношение должно обладать первичным ключом .
Требование целостности ссылок состоит в том, что для каждого значения внешнего ключа родительской таблицы должна найтись строка в дочерней таблице с таким же значением первичного ключа.
Метод «сущность - связь»
Ответ :
Метод «сущность-связь» (метод «ER-диаграмм») – это метод, основанный на использование диаграмм, называемых соответственно диаграммами ER-экземпляров и диаграммами ER-типа.
Основные понятия
Сущность – это объект, информация о котором хранится в БД.
Атрибут – это свойство сущности.
Ключ сущности – это атрибут (набор атрибутов), используемый для идентификации экземпляра сущности.
Связь между сущностями – это зависимость между атрибутами этих сущностей.
Графические средства , используемые для получения наглядности и удобства проектирования:
Диаграмма ER- экземпляров ;
Диаграмма ER -типа или ER -диаграмма .
На основе анализа ER-диаграмм формируется отношения проектируемой БД. При этом учитывается степень связи сущностей и класс их принадлежности.
Степень связи – это характеристика связи между сущностями (1:1, 1:М; М:1; М:М).
Класс принадлежности сущности может быть: обязательным и необязательным .
Обязательный – если все экземпляры сущности обязательно участвуют в рассматриваемой связи.
Необязательный – не все экземпляры участвуют в рассматриваемой связи.
Этапы проектирования баз данных
Ответ :
I . Концептуальное проектирование – сбор, анализ и редактирование требований к данным.
Цель : создание концептуальной модели данных, исходя из представлений пользователя о предметной области.
Процедуры :
Определение сущностей и их документирование;
Определение связей между сущностями и их документирование;
Создание модели предметной области;
Определение значений атрибутов;
Определение первичных ключей для сущностей.
II . Логическое проектирование – на основе концептуальной модели создается структура данных.
Цель : преобразование концептуальной модели на основе выбранной модели данных в логическую модель, независимую от особенностей используемой в дальнейшем СУБД для физической реализации БД.
Процедуры :
Выбор модели данных;
Определение набора таблиц и их документирование;
Нормализация таблиц;
Определение требований к поддержке целостности данных и их документирование.
III . Физическое проектирование – определение особенностей данных и методов доступа.
Цель: описание конкретной реализации БД, размещение во внешней памяти компьютера.
Процедуры:
Проектирование таблиц БД;
Проектирование физической организации БД;
Разработка стратегии защиты БД.
Жизненный цикл базы данных
Ответ :
Жизненный цикл БД – это процесс проектирования, реализации и поддержания систем БД.
Стадии жизненного цикла БД:
Анализ – анализ предметной области и выявление требований к ней, оценка актуальности системы.
Проектирование – создание логической структуры БД, функциональное описание программных моделей и информационных запросов.
Реализация – разработка ПО для БД, проводится тестирование.
Эксплуатация и сопровождение .
Этапы жизненного цикла БД:
Предварительное планирование – планирование БД, выполнения стратегического плана разработки БД (какие приложения используются, какие функции они выполняют, какие файлы связаны с каждым из этих приложений и какие новые файлы и приложения находятся в процессе разработки).
Проверка осуществимости – проверка технологической, операционной и экономической осуществимостей.
Определение требований – выбор цели БД, выявление информационных требований к БД, требования к оборудованию и к ПО, определение пользовательских требований.
Концептуальное проектирование – создание концептуальной схемы.
Реализация – приведение концептуальной модели ф функциональную БД.
Выбор и приобретение необходимой СУБД.
Преобразование концептуальной модели в логическую и физическую модели.
На основе инфологической модели строится схема данных для конкретной СУБД.
Определяются какие прикладные процессы необходимо реализовать как хранимые процедуры.
Реализовать ограничения, предназначенные для обеспечения целостности данных.
Спроектировать триггеры.
Разработать стратегию индексирования и кластеризации, выполнить оценку размеров таблицы, кластеров и индексов.
Определить уровни доступа пользователей, разработать и внедрить правила безопасности.
Разработать сетевую топология БД.
Создание словаря данных.
Заполнение БД.
Создание прикладного ПО, контроль управления.
Обучение пользователя.
Оценка и усовершенствование схемы БД .
Правила формирования отношений
Ответ :
Правила формирования отношений основываются на учете следующего:
Степень связи между сущностями (1:1, 1:М, М:1, М:М);
Класса принадлежности экземпляров сущностей (обязательный и необязательный).
Информация всегда имела адекватный динамичный интерес. Развитие языков программирования, реляционных баз данных и информационных технологий кардинально изменило содержание и структуру интереса. Сложилась определенная строгая система представлений. Формализация, точная математика и бинарные отношения стали успешной и, стремительно развивающейся, областью знаний и опыта.
Естественный мир информации не поменял своей динамики и, развивая содержание и структуру, поднялся на новую высоту. Он имеет плавные формы, и в природе нет ничего «прямоугольного» . Информация, безусловно, поддается формализации, но у нее есть динамика, меняются не только данные и алгоритмы их обработки, меняются сами задачи и области их применения.
Информация, превращается в информационная структура, база данных…) так, как это видит программист. Нет никакой гарантии, что это видение правильно, но если его программа решает поставленную задачу, значит данные были представлены возможно надлежащим образом.
Вопрос о том, насколько была правильно формализована информация - вопрос времени. До сих пор понятие динамики (самоадаптации к изменяющимся условиям использования) - только лишь мечта программирования.
Функциональная зависимость: «правильное решение = программа (программист)» и условие: «непрерывное соответствие задаче» действительны в большинстве случаев, но только совместно. Но это не та математическая основа, которая применяется при создании баз данных.
Прямое утверждение: естественная и непрерывная динамика информации и алгоритмов решения задач действительно всегда. А это бинарные отношения + строгая математика + точные формальные конструкции, + ...
Как хранятся данные уже давно неважно: будь то оперативная память или внешнее устройство. Аппаратная составляющая достигла уверенных темпов развития и обеспечивает хорошее качество в больших объемах.
Основные варианты хранения, отличающиеся вариантами использования данных:
Первое отдано на откуп программисту (что записывать, в каком формате, как это делать, как читать…), второе сразу приносит необходимость познания простой функциональной зависимости.
Скорость выборки и записи информации при работе с файлами (разумного размера, а не астрономического) очень быстра, а скорость аналогичных операций с базой данных может порой быть заметно медленной.
В истории были попытки выйти за достигнутые пределы, но по сей день властвуют реляционные базы данных. Накоплен большой теоретический потенциал, практика применения обширная, а разработчики - высококвалифицированные.
Понятие функциональной зависимости разработчики баз данных навязывают программисту, даже если тот не намерен использовать богатый математическо-логический опыт построения сложных информационных структур, процессов работы с ними, выборки и записи информации.
Даже в самом простом случае программист зависит от логики базы данных, какую бы он ни выбрал для работы. Нет желания следовать канонам, можно использовать файлы, получится много файлов и много личного опыта. Будет потрачено много личного времени и задача будет решена за длительное время.
Какими бы сложными ни казались примеры функциональной зависимости, вовсе не обязательно погружаться в глубины смысла и логики. Часто следует признать, что коллективный разум сумел создать отличные базы данных, различного размера и функциональности:
Прекрасные реляционные базы данных с хорошей репутацией, удобные в использовании, быстрые в умелых руках. Их применение экономит время и избавляет от необходимости писать очередные простыни вспомогательного кода.
У программирования с давних пор болезнь что-то постоянно переписывать, повторять труд предшественников, чтобы как-то что-то адаптировать к изменившейся информации, задаче или условиями ее использования.
Особенность функциональной зависимости в том, что, как и в программировании, ошибка может стоить очень дорого. Задача редко бывает простой. Обычно, в ходе формализации информации, получается сложное представление данных. Обычно выделяются их элементы, потом они увязываются ключами в определенные отношения, потом налаживаются алгоритмы формирования таблиц, запросы, алгоритмы выборки информации.
Часто большое значение имеет привязка к кодировке. Не все базы данных предлагают мобильные решения, часто можно столкнуться с тем, как прекрасно настроенный MySQL, на котором лежит десяток баз данных, отлично и стабильно работающий, вынуждает разработчика делать одиннадцатую базу подобной тем, которые уже есть.
Бывают случаи, когда общий хостинг ограничивает функциональность PHP и это накладывает отпечаток на программирование доступа к базе данных.
В современном программировании ответственность за алгоритм программы эквивалентна ответственности за создание модели данных. Все должно работать, но не всегда следует погружаться в дебри теории.
Прежде всего, понятие БД - это и база данных как система управления (например, MySQL), так и некая информационная структура, отражающая данные задачи и связи между ними. Одна база MySQL «держит» на себе сколько угодно информационных структур по различным сферам применения. Одна база Oracle, может обеспечивать информационные процессы крупной компании или банка, контролировать вопросы безопасности и сохранности данных на высочайшем уровне, располагаясь на множестве компьютеров, находящихся на различном удалении, в различных инструментальных средах.
Принято полагать, что отношение есть основное в реляционной модели. Элементарное отношение - это множество колонок с именами и строк со значениями. Классический «прямоугольник» (таблица) - простое и эффективное достижение прогресса. Сложности и функциональная зависимость базы данных начинаются, когда «прямоугольники» начинают вступать в отношения друг с другом.
Имя каждой колонки в каждой таблице должно быть уникальным в контексте задачи. Одно и то же данное не может быть в двух таблицах. Знать смысл понятий:
Элементарная необходимость для использования базы данных и построения модели данных для конкретной задачи.
Нарушение любого из этих понятий - низкая эффективность алгоритма, медленная выборка данных, потеря данных, и другие неприятности.
Можно не читать про кортежи отношений, про то что функция - это соответствие множества аргументов множеству значений, а функция - это не только формула или график, но может быть задана множеством значений - таблицей.
Не обязательно, но вовсе не помешает представлять функциональную зависимость как:
F(x1, x2, …, xN) = (y1, y2, …, yN).
Но обязательно понимать, что на входе - таблица, на выходе тоже таблица или конкретное решение. Обычно функциональная зависимость устанавливает логику отношений между таблицами, запросами, привилегиями, триггерами, хранимыми процедурами и другими моментами (компонентами) базы данных.
Обычно, таблицы преобразуются друг в друга, потом в результат. Но использование функциональной зависимости не ограничивается только такой идеей. Программист сам строит свое представление картины данных, информационной структуры… неважно, как это именовать, но если оно работает на конкретной базе данных, оно должно строиться по ее логике, учитывать ее смысл и диалект используемого языка, как правило, SQL.
Можно утверждать, что свойства функциональных зависимостей базы данных доступны через диалект используемого языка SQL. Но гораздо важнее понимать: после всех перипетий развития, не так много баз данных выжило, но диалектов этого языка много и особенностей внутренних конструкций в базах тоже.
Когда компьютер показал себя с положительной стороны, мир сразу разделился на программистов и пользователей. Как правило, первые используют:
Некоторые пользователи умудряют делать самостоятельно (без помощи программистов) в Word базы данных - реальный нонсенс.
Опыт работы пользователей в Excel по созданию баз данных - практичен и интересен. Важно то, что Excel, сам по себе, функционален, красочен и практичен.
Табличная идея, определила понятие функциональной зависимости наглядно и доступно, но нюансы есть у каждой базы данных. У каждой свое «лицо», но все от Excel до Oracle манипулируют простыми квадратами, то есть таблицами.
Если учесть, что Excel - это совсем не база данных, но многие юзеры (не программисты) его именно так используют, а Oracle - это сложнейшее и мощнейшее достижение большого коллектива разработчиков именно в области баз данных, то становится естественным признать - база данных это представление конкретного программиста (коллектива) о конкретной задаче и ее решении.
Что такое функциональная зависимость, с чем, куда, почему… очевидно только автору или коллективу таковых.
Научно-технический прогресс - весьма мучительная процедура, а местами жестокая. Если вспомнить с чего начинались базы данных, что такое *.dbf, как клеймили кибернетику, потом полюбили информатику и стали устраивать препоны перемещению высоких технологий на уровне стран, становится ясно почему реляционные базы данных так живучи и хороши. Почему классический стиль программирования по сей день живет, а объектно-ориентированное программирование просто ценится, но еще не властвует.
Как бы ни была прекрасна функциональная зависимость в контексте математики:
Это не бинарные отношения, точнее, это повод переосмыслить идею устанавливать отношения между множеством атрибутов, исследовать связи «один к многим», «многие к одному», «многие ко многим» или «многие вообще, а одни в частности».
Вариантов отношений можно придумать великое множество. Это математика с логикой, и она строгая! Информация - это своя математика, особенная. В ней о формальности можно говорить только с очень большим минусом.
Можно формализовать работу отдела кадров, написать АСУ для добычи нефти или производства молока, хлеба, сделать выборку в огромной базе гугла, яндекса или рамблера, но результат будет всегда статичен и каждый момент времени одинаков!
Если функциональная зависимость = строгая логика и математика = основа для баз данных, то о какой динамике можно вести речь. Любое решение будет формальным, любая формальная модель данных + строгий алгоритм = точное и однозначное решение. Информация и область применения любой программы меняются всегда.
Выборка поисковой системы на одной и той же поисковой фразе не может быть одной и той же через час или через два и, однозначно, через день - если поисковая фраза относится к области информации, в которой количество сайтов, ресурсов, знаний, прочих элементов непрерывно меняется.
Даже если программа чисто математическая и ее база данных даже не мыслит о динамике, все всегда есть строки . А у строки есть длинна. И бесконечной она быть не может. Она не может быть даже переменной, только условно-переменной. Помимо всего прочего, любая база данных своим математическим и бинарным-бюрократическим аппаратом накладывает массу формальностей, а это скорость+качество выборки и обработки информации.
А если те или иные поля в базе данных числа, особенно вещественные то в ограничения добавятся: разрядность числа, наличие буквы "е", формата представления - короче везде и всегда имеем важные свойства функциональных зависимостей базы данных: строки условно-переменной длины с массой бинарных формальностей и строгих математических ограничений.
Если сменить тон и прислушаться к пульсу динамики, то все можно расписать на объекты. В первом приближении имя колонки в таблице - это объект, список имен - тоже объект, короче таблица - это объект шапки и в нем имена колонок в шапке. И шапки может вовсе не быть...
Но в таблице могут быть строки. И в строке могут быть значения. И почему их всегда должно быть одинаковое количество. Полная квадратная таблица - это частность, причем в большинстве случаев, частная.
Если представить все конструкции в базе данных объектами, то, быть может, не придется выстраивать строгие бинарные отношения. В этом есть естественный и реальный смысл хотя бы потому, что это по объективной (однозначно не математической) логике отражает динамику информации и среды, в которой существуют задачи.
