Лекция Язык sql 46 вставка одного запроса внутрь другого 68 как работает подзапрос? 68 Лекция Распределенная обработка данных Архитектура распределенной обработки данных Архитектура «файл сервер»

Скачать 1.16 Mb.

Название	Лекция Язык sql 46 вставка одного запроса внутрь другого 68 как работает подзапрос? 68 Лекция Распределенная обработка данных Архитектура распределенной обработки данных Архитектура «файл сервер»
страница	4/9
Тип	Лекция

rykovodstvo.ru > Руководство эксплуатация > Лекция

1 2 3 4 5 6 7 8 9

Селекция
Операция селекции (выборки, ограничения) отношения выделяет из него некоторое подмножество кортежей, которые удовлетворяют некоторому условию. При работе с базами данных выборка из всей имеющейся совокупности только требуемых данных — это наиболее часто применяемая операция. Конкретное определение этой операции зависит от вида условия. Одной из частных разновидностей операции селекции является операция сужения отношения, которую мы здесь и рассмотрим.
(презентация)
Пример селекции
Рассмотрим в качестве примера отношение ЗАРПЛАТА (СОТРУДНИК, ВЫПЛАТА), которое можно представить в виде двухстолбцовой таблицы. В этой таблице в столбце сотрудник указаны имена сотрудников некоторой фирмы или какого-то ее подразделения, а в столбце выплата — денежная сумма, причитающаяся соответствующему сотруднику. Допустим, нас интересуют выплаты только Иванову и Петрову — элементам домена атрибута сотрудники. Обозначим через Сотрудник множество всех значений столбца сотрудник. Это и есть домен атрибута сотрудник. Аналогично, обозначим через Dz домен атрибута выплата. Тогда интересующее нас отношение можно определить следующим образом:

ЗАРПЛАТА (СОТРУДНИК, ВЫПЛАТА) {Иванов, Петров} х Dz.
Здесь через {Иванов, Петров} обозначено требуемое подмножество домена атрибута сотрудник.
На естественном языке запрос на получение указанного множества кортежей выглядит очень просто: "выбрать кортежи, в которых значение атрибута СОТРУДНИК равно "Иванов" ИЛИ "Петров".
Эквивалентный запрос можно сформулировать и так: "выбрать кортежи, в которых значение атрибута СОТРУДНИК равно "Иванов", и те кортежи, в которых значение атрибута сотрудник равно "Петров". Обратите внимание на использование союзов "или" и "и" в этих формулировках запросов. Если в первой формулировке "или" заменить на "и", то искомое множество кортежей будет заведомо пустым, поскольку атрибут сотрудник в одном и том же кортеже не может иметь два и более различных значения. Вторая формулировка допускает замену "и" на "или", поскольку в ней речь идет о различных значениях атрибута в различных кортежах. Применяя в обычной речи союзы "и" и "или", всегда следует отдавать себе отчет в том, что имеется в виду — объединение или пересечение соответствующих множеств.
Проекция
О

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

П

усть дано некоторое отношение

О

бозначим через А множество всех атрибутов отношения, а через X — некоторое его подмножество (т. е. ).
Тогда операция проекции отношения R(А) на множество атрибутов X приводит к отношению R[X], кортежи которого получаются из кортежей исходного отношения путем удаления значений тех атрибутов, которые не принадлежат X. Для любого кортежа z из отношения R(A) его проекция z[X] на множество атрибутов X означает, что в этом кортеже следует оставить значения только атрибутов из X. Обратите внимание, что квадратные скобки здесь указывают лишь на то, что рассматривается проекция отношения или кортежа на заключенные в эти скобки атрибуты.
Пример проекции (презентация)
Естественное соединение
Предположим, имеются два отношения, содержащие кроме прочих и одинаковые атрибуты. Рассмотрим, например, две таблицы R1 (ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА) и R2 (ПРЕПОДАВАТЕЛЬ, КАФЕДРА).
Отношение R1 содержит сведения об именах преподавателей и об учебных дисциплинах, занятия по которым они проводят. Вообще говоря, один и тот же преподаватель может заниматься несколькими дисциплинами, а по одной и той же дисциплине могут проводить занятия разные преподаватели.
Отношение R2 содержит сведения о приписке преподавателей к кафедрам. Предполагается, что каждый преподаватель может быть приписан только к одной кафедре.
Естественно, может возникнуть задача сведения этих двух отношений в одно (соединить две таблицы в одну) —
R3 (ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА).
Пример (презентация)
Операция естественного соединения
(презентация)
Язык SQL предоставляет специальные средства для различных типов соединения таблиц. Естественное соединение отношений R1 (ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА) и R2 (ПРЕПОДАВАТЕЛЬ, КАФЕДРА) можно выполнить с помощью следующего SQL-выражения:
SELECT R1.*, R2.КАФЕДРА FROM R1, R2

WHERE R1.ПРЕПОДАВАТЕЛЬ= R2.ПРЕПОДАВАТЕЛЬ
По-русски это выглядит так: "выбрать все столбцы таблицы R1 и столбец кафедра таблицы R2 из декартового произведения R1 и R2 при условии, что преподаватели из этих таблиц одинаковы".
Здесь подразумевается именно декартово произведение, т. к. после ключевого слова from указаны две таблицы. В SQL также можно использовать оператор natural join для явного указания операции естественного соединения.
(презентация)
Декомпозиция отношений
Таблица базы данных, представляющая некоторое отношение, может иметь очень большие размеры по количеству записей (строк) и столбцов, а также по общему объему содержащихся в них данных. Эффективность работы с таблицами по мере роста их объема уменьшается. Это обстоятельство вынуждает искать способы декомпозиции одной большой таблицы на несколько таблиц меньших размеров.
Так, в рассмотренном в предыдущем разделе отношении R3 (ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА) все атрибуты имеют повторяющиеся значения, а атрибут преподаватель однозначно определяет атрибут кафедра, поскольку каждый преподаватель приписан только к одной кафедре. Наличие такой зависимости между атрибутами преподаватель и дисциплина наталкивает на мысль, что декомпозиция возможна.
Отношения R1 (ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА) и R2 (ПРЕПОДАВАТЕЛЬ, КАФЕДРА) можно рассматривать как результат декомпозиции отношения R3, т. е. как операцию, обратную естественному соединению. Обратите внимание, что общий объем данных в отношениях R1 и R3 меньше объема данных в отношении RЗ. Кроме того, в отношении R2 атрибут преподаватель не имеет повторяющихся значений.
Очевидно, что отношения, получающиеся в результате декомпозиции исходного отношения, являются проекциями последнего на некоторые подмножества атрибутов. Напомню, что проекция отношения на заданные атрибуты получается из этого отношения путем удаления из него всех атрибутов, кроме заданных. Заметим также, что для декомпозиции отношения на две проекции необходимо, чтобы оно было определено не менее чем для трех атрибутов.
Декомпозиция может быть корректной или некорректной. Другими словами, она может быть обратимой или необратимой.
Обратимость декомпозиции означает, что она является эквивалентным преобразованием исходной информации (форма изменяется, а содержание нет).
Необратимость декомпозиции означает неэквивалентность преобразования: в содержание либо что-то вносится, либо что-то теряется. Далее мы дадим определение корректной декомпозиции и покажем пример некорректной декомпозиции.
Д

екомпозиция отношения на некоторые свои проекции называется корректной, если исходное отношение можно восстановить по этим проекциям с помощью операции естественного соединения. Точнее, отношение R(А) корректно декомпозируется на свои проекции R[X] и R[Y] ( ), если выполняется равенство
R(A) = R[X] * R[Y].
Например, декомпозиция отношения
R3 (ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА) на свои проекции:
R3 [ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА] = R1 (ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛНА) и R3 [ПРЕПОДАВАТЕЛЬ, КАФЕДРА] = R2 (ПРЕПОДАВАТЕЛЬ, КАФЕДРА) является корректной.
Это утверждение просто следует из того, что отношение R3 было получено из отношений R1 и R2 путем их естественного соединения.
(презентация)
Зависимости между атрибутами
Итак, отношение не всегда можно декомпозировать на две свои проекции. Критерием возможности декомпозиции является наличие в отношении некоторых зависимостей между его атрибутами. Это общий критерий. Если в чем-либо обнаруживаются какие-нибудь зависимости, то существует принципиальная возможность представить это нечто в более компактном виде.
Чтобы отношение можно было декомпозировать на две своих проекции, достаточно существования в нем так называемых функциональных зависимостей. Необходимым и достаточным условием декомпозиции отношения является наличие в нем многозначных зависимостей. Рассмотрим эти зависимости по порядку.
Функциональные зависимости
Функциональные зависимости просты для понимания и обычно легко обнаруживаются в отношении. Между атрибутами А и В существует функциональная зависимость, если любое значение атрибута А однозначно определяет значение атрибута В.
В отношении R2 (ПРЕПОДАВАТЕЛЬ, КАФЕДРА) между атрибутами ПРЕПОДАВАТЕЛЬ и КАФЕДРА имеется функциональная зависимость, поскольку каждый преподаватель может быть приписан лишь к одной кафедре (предполагается, что совместительство не допускается). Другими словами, по значению атрибута ПРЕПОДАВАТЕЛЬ можно однозначно определить, на какой кафедре он работает. Однако между атрибутами КАФЕДРА и ПРЕПОДАВАТЕЛЬ в отношении R1 нет функциональной зависимости: на одной и той же кафедре могут работать несколько преподавателей.
В отношении R1 (ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА) нет ни одной функциональной зависимости: один и тот же преподаватель может заниматься несколькими дисциплинами, а одну и ту же дисциплину могут вести несколько преподавателей.
В отношении R3 (ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА) существуют две функциональных зависимости:

между атрибутами ПРЕПОДАВАТЕЛЬ и КАФЕДРА;
между атрибутами ДИСЦИПЛИНА и КАФЕДРА.

Вообще говоря, функциональная зависимость может иметь место не только между отдельными атрибутами, но и между подмножествами атрибутов отношения. Для этого общего случая дадим определение функциональной зависимости.
Пусть дано некоторое отношение R(A) с атрибутами из множества А, т. е. А — это множество атрибутов, а не отдельный атрибут. Обозначим через X и Y некоторые подмножества атрибутов (ХÊА, YÊ A). В отношении R(A) выполняется функциональная зависимость между атрибутами X и Y, обозначаемая как X->Y, если для любых кортежей z1 и z2 этого отношения из равенства их проекций на множество атрибутов X следует равенство их проекций на множество атрибутов Y.
Иначе говоря, функциональная зависимость X->Y выполняется, если справедливо следующее высказывание:
для любых z1 и z2 из равенства z1[X] = z2[X] следует равенство z1[Y] = z2[Y].
Если выполняется функциональная зависимость X->Y, то говорят, что атрибуты X функционально (однозначно) определяют атрибуты Y.
Например, в отношении R3 (ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА) имеются следующие функциональные зависимости:

{ПРЕПОДАВАТЕЛЬ} -> {КАФЕДРА} — преподаватель функционально определяет кафедру;
{ДИСЦИПЛИНА} -> {КАФЕДРА} — дисциплина функционально определяет кафедру;
{ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА} -> {КАФЕДРА} — преподаватель и дисциплина функционально определяют кафедру.

Предположим, что отношение ПРОДАЖИ (товар, количество, цена, стоимость) содержит сведения о проданных товарах. Стоимость товара однозначно определяется его количеством и ценой, поскольку существует простая формула:
стоимость = количество х цена.
Поэтому в данном отношении имеется функциональная зависимость
количество, цена} -> {стоимость}.
(презентация)
В отношении R3 (преподаватель, дисциплина, кафедра) имеется функциональная зависимость {преподаватель} -> {кафедра}. Следовательно, это отношение можно декомпозировать на две проекции:

R3 [преподаватель, кафедра];
R3 [преподаватель, дисциплина].

В данном примере можно принять такие обозначения:
А = {преподаватель, дисциплина, кафедра};

X ={преподаватель};

Y = {кафедра};

XUY= {преподаватель, кафедра};

А -Y = {преподаватель, дисциплина};

XU(А - Y) = {преподаватель} U {преподаватель, дисциплина} = {преподаватель, дисциплина}.
(презентация)
Отношение ПРОДАЖИ (товар, количество, цена, стоимость), имеющее функциональную зависимость {количество, цена}-> {стоимость}, можно декомпозировать на такие проекции:

ПРОДАЖИ [количество, цена, стоимость];
ПРОДАЖИ [товар, количество, цена].

В любом отношении существует хотя бы одна функциональная зависимость. Например, для произвольного отношения R(A) всегда выполняется зависимость А->А, поскольку по определению в любом отношении не может быть одинаковых кортежей и, следовательно, любой кортеж однозначно определяет сам себя. Такая функциональная зависимость является тривиальной. Точнее, функциональная зависимость X->Y называется тривиальной, если YÊX.
Наличие в отношении нетривиальной функциональной зависимости является достаточным, но не необходимым условием корректной декомпозиции этого отношения на две проекции. Это означает, что если функциональная зависимость есть, то декомпозиция возможна. Однако корректная декомпозиция может быть выполнена и для некоторых отношений, в которых нет ни одной функциональной зависимости.
Приведем некоторые свойства функциональных зависимостей. Пусть Y = {А1,..., Ак) — некоторое подмножество атрибутов отношения. Если в этом отношении выполняется функциональная зависимость X->Y, то выполняется и множество функциональных зависимостей X->{Ai), где i = 1, ...,к.
Другими словами, коль скоро выполняется функциональная зависимость между множествами атрибутов X и Y, то выполняются и зависимости между X и одиночными атрибутами из Y. Обратное утверждение тоже верно: если в отношении выполняются функциональные зависимости X->{Ai) (i = l,..., к), то выполняется и функциональная зависимость X->Y, где Y = {A1,...,Ak}.
В отношении R(A) функциональная зависимость X->Y выполняется тогда и только тогда, когда она выполняется в проекции R[Z], где Z Ê X U Y.
Обобщением понятия функциональной (однозначной) зависимости является понятие многозначной зависимости. Наличие в отношении многозначной зависимости является необходимым и достаточным условием его декомпозиции на две проекции. Напомню, что выполнение функциональной зависимости обеспечивает лишь достаточное условие декомпозиции. Вот почему некоторые отношения без функциональных зависимостей все-таки могут быть декомпозированы.
Многозначная зависимость имеет смысл только для отношений с тремя и более атрибутами. Проще всего понятие многозначной зависимости объяснить для отношения с тремя атрибутами. Пусть дано некоторое отношение R(A1, A2, A3), для которого выполняются следующие условия:

атрибут А1 не определяет однозначно атрибут А2, т. е. нет функциональной зависимости {А1}-> {А2};
атрибуты А2 и A3 не зависят друг от друга, т. е. в отношении R(A1, А2, A3) любое значение А2 может сочетаться в кортежах с любым значением A3.

Тогда в отношении R(A1, A2, A3) выполняется многозначная зависимость между атрибутами А1 и А2, которая обозначается как {A1}->>{A2} . При этом говорят, что атрибут А1 многозначно определяет атрибут А2.
Пусть дано отношение R (преподаватель, дисциплина, увлечение), которое содержит сведения о преподавателях, дисциплинах, занятия по которым они проводят, и личных увлечениях (хобби). Предполагается, что один преподаватель может проводить занятия по нескольким дисциплинам, т. е. атрибут преподаватель не определяет однозначно атрибут дисциплина. Далее, мы считаем, что нет никакой связи между дисциплинами и увлечениями преподавателей. Иначе говоря, если известно, что преподаватель читает студентам, например, базы данных, то из этого нельзя однозначно определить, чем конкретно он увлекается. И наоборот, если мы знаем о конкретном увлечении преподавателя классической музыкой, то не можем однозначно сказать, какой именно дисциплиной он занимается. Все это означает, что в рассматриваемом отношении значения атрибутов дисциплина и увлечение могут сочетаться произвольным образом. Итак, атрибуты дисциплина и увлечение не зависят друг от друга, а атрибут преподаватель не однозначно определяет атрибут дисциплина.
(презентация)
Поскольку выполняется многозначная зависимость ПРЕПОДАВАТЕЛЬ-» ДИСЦИПЛИНА, атрибуты ДИСЦИПЛИНА И УВЛЕЧЕНИЕ не зависят друг от друга. Поэтому имеется возможность представить связи ПРЕПОДАВАТЕЛЬ—ДИСЦИПЛИНА и ПРЕПОДАВАТЕЛЬ—УВЛЕЧЕНИЕ в виде отдельных отношений, причем так, чтобы исходное отношение R(преподаватель, дисциплина, увлечение) полностью восстанавливалось с помощью операции естественного соединения.
Обобщим вышесказанное. Отношение R(A1, А2, A3), в котором выполняется многозначная зависимость {А1}-»{А2}, можно декомпозировать на две проекции: R1[A1,A2] и R2[A1,A3].
Это означает, что выполняется следующее равенство:
R(А1,А2,АЗ) = R1[А1,А2]*R2[A2,АЗ].
(презентация)
В общем случае многозначная зависимость определяется не только между одноэлементными множествами атрибутов.
Ранее уже отмечалось, что наличие многозначной зависимости в отношении является необходимым и достаточным условием декомпозиции отношения на две его проекции. Если в отношении R(A) выполняется многозначная зависимость X-»Y, то это отношение можно декомпозировать на две проекции — R1[X, Y] и R2[X, Z]. Это утверждение о том, что многозначная зависимость необходима для декомпозиции.
То, что наличие многозначной зависимости является еще и достаточным условием декомпозиции, вытекает из следующего.
Пусть отношение R(A) декомпозируется на две проекции — R1[X] и R2[Y] (это означает, что R(A) = R1[X]*R2[Y]). Тогда в отношении R(A) выполняются две многозначные зависимости - XÇY-»X-Y и XÇY-»Y-X. Иначе говоря, если удалось декомпозировать отношение на две проекции, то это означает, что в отношении выполняются, по крайней мере, многозначные зависимости.
На следующем слайде представлено некоторое отношение R(A1,A2,A3) и две его проекции — R1[A1,A2] и R2[A2,A3]. Нетрудно проверить, что выполняется равенство R(A1,A2,A3) = R1[A1,A2]*R2[A2, A3]. Следовательно, отношение декомпозируется на эти проекции.
Нетрудно заметить, что в определении многозначной зависимости множества атрибутов Y и Z играют симметричные роли: если что-либо справедливо для Y, то это же справедливо и для Z, и наоборот. Поэтому можно сформулировать следующее утверждение: многозначная зависимость X-»Y выполняется в отношении R(A) тогда и только тогда, когда в R(А) выполняется многозначная зависимость X-»Z.
Многозначные (а также и функциональные) зависимости сохраняются в проекциях отношения, которые не затрагивают их левой части. Другими словами, если в отношении R(A) выполнятся многозначная зависимость X-»Y, то в любой проекции R[V], для которой ХÍ V, выполняется и многозначная зависимость X-»YÇV.
Для функциональных зависимостей верно и обратное утверждение: если в проекции выполняется функциональная зависимость, то эта же зависимость выполняется и во всем отношении. Для многозначных зависимостей это утверждение не верно: из выполнимости многозначной зависимости некоторой проекции отношения еще не следует ее выполнимость во всем отношении.
Все утверждения, сформулированные для многозначных зависимостей, справедливы и для функциональных зависимостей. Поэтому далее мы будем рассматривать только многозначные зависимости.
Если в отношении было каким-либо образом замечено выполнение одних зависимостей, то другие могут быть выведены логически из тех, что обнаружены. В основе декомпозиции, как известно, находится та или иная зависимость. Таким образом, имея несколько зависимостей, мы имеем возможность выбора декомпозиции.
He всякая декомпозиция может оказаться удачной с точки зрения экономного представления данных. Не стоит также забывать и о том, что результаты декомпозиции (проекции исходного отношения) могут использоваться как исходный материал для дальнейшей декомпозиции: то, что хорошо на первом этапе декомпозиции, может плохо сказаться на всей многоэтапной декомпозиции. Иначе говоря, оптимизация декомпозиции в целом не означает, что каждый отдельный ее этап должен быть наилучшим.
Понятие ключа
При синтезе и анализе отношений (таблиц базы данных) важную роль играет понятие ключа отношения (таблицы). Это понятие производное от понятия функциональной зависимости, которое было рассмотрено в предыдущем разделе. Можно считать, что ключ является аргументом (левой, частью) функциональной зависимости между множествами атрибутов отношения.
Ключ (key) — это множество из одного или нескольких атрибутов, которое однозначно определяет (идентифицирует) всю запись в отношении. Таким образом, множество атрибутов X является ключом отношения R(A), если в этом отношении есть функциональная зависимость Х->А . И наоборот, если в отношении R(A) имеется функциональная зависимость Х->А, то множество атрибутов X является ключом этого отношения. Очевидно, что главным признаком ключа отношения является уникальность (неповторяемость) его значений.
Из самого определения отношения следует, что в любом отношении всегда найдется ключ. По крайней мере, ключом может быть множество всех атрибутов А, т. к. в любом отношении имеется тривиальная функциональная зависимость А->А, поскольку каждая запись встречается в отношении всего один раз и, следовательно, однозначно идентифицирует сама себя.
Однако при разработке таблиц базы данных обычно интересуются не тривиальными ключами, а состоящими из одного или небольшого количества атрибутов. Действительно, тривиальные зависимости не дают возможность получить декомпозицию отношения на две проекции.
Рассмотрим в качестве примера таблицу, представляющую отношение Студенты (Фамилия, Имя, Отчество, Учебная_группа). Какие атрибуты в этом отношении могут составить ключ? Предполагается, что каждый студент может находиться только в одной учебной группе. Казалось бы, что множество атрибутов {Фамилия, Имя, Отчество} должно однозначно идентифицировать студента, а следовательно, и группу. Это было бы верно, если бы мы исключили возможность существования в одной группе полных тезок (однофамильцев с одинаковыми именами и отчествами). Хотя это и маловероятно, но все же возможно.
Таким образом, множество атрибутов {Фамилия, Имя, Отчество} не подходит на роль нетривиального ключа. В подобных ситуациях создают специальный атрибут (столбец), предназначенный играть роль ключа. В нашем примере это может быть ID_студента (идентификатор студента). Значения этого атрибута могут быть какими угодно, но обязательно уникальными. В результате получается таблица Студенты (ID_студента, Фамилия, Имя, Отчество, Учебная_группа).
А если ID_студента является ключом, то в данном отношении имеется функциональная зависимость
{ID_студента} -> {ID_студента,Фамилия, Имя, Отчество, Учебная__группа},
а также зависимость {ID_студента}->{Фамилия, Имя, Отчество, Учебная_группа}.
Последнюю зависимость, очевидно, можно использовать для декомпозиции исходного отношения на следующие два:

Студенты_список(ID_студента, Фамилия, Имя, Отчество) и

Группы (ID_студента, Учебная_группа).
Ключ, состоящий из одного атрибута, называют простым, а из нескольких — составным. Ключи, рассмотренные здесь, также называют первичными (primary key).
Ограничения целостности отношений
До сих пор мы рассматривали отношения, представленные в виде таблиц своими кортежами (записями). Зависимости между атрибутами выражали некоторую целостность отношений, а корректная декомпозиция отношений на основе зависимостей рассматривалась как сохраняющая их целостность. Таким образом, мы изучали реляционные базы данных главным образом как теорию декомпозиции отношений, заданных экстенсионально, т. е. посредством наборов записей.
На практике приходится проектировать базу данных как набор из нескольких таблиц, которые изначально пусты и только со временем заполняются конкретными данными. Иначе говоря, довольно сложные базы данных проектируются путем разработки множества отдельных таблиц с последующей установкой связей между ними, т. е. путем композиции частей в некое целое. При этом не исключается и декомпозиция таблиц на свои проекции.
Однако каждая таблица в отдельности, а также совокупность таблиц обычно являются не случайными комбинациями атрибутов, произвольно распределенными между различными таблицами. Как отдельные таблицы, так и вся их совокупность, называемая базой данных, обладают некоторой целостностью, которая выражается через различного рода ограничения, накладываемые на значения столбцов и связи между ними.
Таким образом, при проектировании базы данных мы заняты не обнаружением зависимостей для использования их при декомпозиции, а наоборот, заданием их с целью объединения таблиц в целостную систему связанных таблиц, содержащих непротиворечивые данные.
Далее мы рассмотрим несколько видов целостности и способы их задания.
Семантическая целостность
При проектировании базы данных стремятся к тому, чтобы каждая таблица соответствовала некоторому объекту внешнего мира. Существование такого объекта, разумеется, не зависит от базы данных. Если таблица полностью соответствует некоторому объекту, то говорят, что она обладает семантической целостностью и моделирует (представляет) этот объект. При этом каждая запись таблицы моделирует некий элемент объекта.
В таблице, обладающей семантической целостностью, должен быть первичный ключ. Первичный ключ — это один столбец или группа столбцов, значения которых должны быть уникальными и определенными (не равными null). В языке SQL это ограничение целостности, выражающееся в виде ограничения на значения столбца или группы столбцов, задается ключевыми словами primary key.
Доменная целостность
С каждым атрибутом отношения связан домен — множество допустимых значений. При создании таблицы для каждого столбца кроме имени указывается и тип данных, которые он может содержать. Тип данных ограничивает множество допустимых значений столбца, однако во многих случаях такого ограничения оказывается недостаточно.
Например, если в числовом столбце возраст таблицы Сотрудники указано значение 1000, то мы не усомнимся, что это ошибочное значение. В той же таблице символьный столбец должность может принимать значения из определенного списка, предусмотренного штатным расписанием организации, а не произвольную комбинацию символов или наименования должностей с орфографическими ошибками.
Ограничения на допустимые значения для столбца таблицы предназначены для поддержания доменной целостности. В языке SQL риск нарушить доменную целостность возникает при добавлении и обновлении записей с помощью операторов insert и update соответственно.
Ограничения доменной целостности можно задать при создании таблицы с помощью оператора create table, а также предварительно, путем создания домена, применив оператор create domain.
Ссылочная целостность
В хорошо спроектированной базе из нескольких таблиц они связаны друг с другом. Так столбец в одной таблице может ссылаться на столбец другой таблицы этой же базы данных. Подобные ссылки представляют собой ограничения ссылочной целостности базы данных и играют важную роль при поддержке ее общей целостности. Вместе с тем, наличие ссылок порождает так называемую проблему аномалий модификации данных.
Связи между таблицами обычно несимметричны: одна таблица зависит от другой. Допустим, в базе данных имеются две таблицы:
Клиенты (Имя_клиента, Адрес, Телефон);

Продажи (ID,Товар,Количество, Цена, Стоимость, Имя_клиента).
В таблице Клиенты столбец Имя_клиента является ключом (primary key), т. е. имеет уникальные и определенные значения.
В таблице Продажи одноименный столбец не является ключом, его значения могут повторяться, т. к. один и тот же клиент может приобрести несколько товаров. Эта таблица связана с таблицей Клиенты по столбцу Имя_клиента, т. е. столбец Имя_клиента первой таблицы (продажи) ссылается на одноименный столбец второй таблицы (клиенты).
Другими словами, данные таблицы находятся в родительско-дочернем отношении: таблица Клиенты родительская, Продажи дочерняя.
Данная связь между таблицами организуется путем объявления столбца Имя_клиента таблицы Продажи внешним ключом (foreign key), ссылающимся на первичный ключ ID в таблице Клиенты.
Аномалии модификации могут возникнуть различными способами и при различных обстоятельствах, вызывая трудности.
Предположим, какой-то клиент перестал вас интересовать (например, он перестал делать у вас покупки). Если запись о нем удалить из таблицы Клиенты, то в дочерней таблице Продажи останутся записи, ссылающиеся на отсутствующую запись в родительской таблице.
Аналогичная ситуация возникает при попытке добавить в дочернюю таблицу запись, когда в родительскую таблицу еще не было сделано соответствующего добавления.
Нормализация таблиц
База данных может быть спроектирована хорошо или плохо. Сразу создать хороший проект довольно сложно, и на практике процесс проектирования обычно является итерационным: состав таблиц и их структура модифицируются в несколько этапов, пока не будет получен приемлемый результат.
В плохом проекте часто возникают аномалии модификации данных, устранить которые довольно трудно. Такие аномалии могут возникнуть даже в однотабличной базе данных.
Рассмотрим в качестве примера таблицу
Продажи (Клиент, Товар, Количество, Цена)

Клиент	Товар	Кол-во	Цена
Иванов	Хлеб	2	24,50
Петров	Молоко	3	30,00
ОАО «Рога и копыта»	Хвосты	25	120,00
ЗАО «Висант»	Молоко	1	30,00
Сидоров	Хлеб	3	24,50

В данной таблице, могут возникнуть аномалии модификации данных. Предположим, было решено удалить из нее запись о клиенте «ОАО Рога и копыта», поскольку теперь он ничего не приобретает в вашей фирме. Но тогда вы потеряете информацию и цене на "Хвосты". Если же вам потребуется добавить запись о каком-нибудь новом товаре, то необходимо добавить и сведения о покупателе и количестве этого товара. А если пока такого покупателя нет?
Аномалия модификации, возникшая в рассмотренном примере, обусловлена тем, что данная таблица содержит информацию, относящуюся к различным темам. В ней есть сведения и о том, что приобрели покупатели, и о цене товаров. Лучше разбить ее на две таблицы, посвященные двум различным темам:
Продажи_клиенты(Клиенты, Товар, количество) и

Прайс_лист(Товар, Цена).
Вообще говоря, любую таблицу, относящуюся к двум или более темам, следует разбить на две или более таблицы.
При определенных условиях, о которых говорилось ранее, можно декомпозировать и таблицу, посвященную одной теме. В этом случае каждая из результатных таблиц будет соответствовать какой-то части одной темы.
Этот процесс декомпозиции и составляет суть нормализации.
Обнаружив в таблице аномалию модификации, мы устраняем ее путем декомпозиции на две или более таблицы так, чтобы они были свободны от аномалий.
Однако, производя декомпозицию, мы вынуждены задавать ограничения ссылочной целостности.
Таблицы классифицируются по тем видам аномалий модификации, которым они подвержены. Это так называемые нормальные формы таблиц (отношений). В своей статье 1970 г. И. Кодд определил три источника аномалий и три формы таблиц, свободных от них. В последующие годы он и другие исследователи обнаружили другие виды аномалий и предложили формы таблиц, которые им не подвержены.
Далее приводится список всех специальных нормальных форм:
1. Первая нормальная форма (1НФ).

2. Вторая нормальная форма (2НФ).

3. Третья нормальная форма (ЗНФ).

4. Нормальная форма Бойса—Кодда (НФБК).

5. Четвертая нормальная форма (4НФ).

6. Пятая нормальная форма (5НФ).
Все нормальные формы вложены друг друга в следующем смысле: таблица в 2НФ является также и таблицей в 1НФ; таблица в ЗНФ является таблицей и в 2НФ, и в 1НФ, и т. д.
Каждая из перечисленных нормальных форм могла устранить определенные виды аномалий, и не было гарантии, что с их помощью можно устранить всевозможные аномалии, о которых пока просто не было известно.
В 1981 г. Р. Фагин ввел новую нормальную форму, названную доменно-ключевой (ДКНФ), и доказал, что таблица в ДКНФ свободна от всех аномалий модификации и наоборот: таблица, свободная от любых аномалий модификации, находится в ДКНФ. До появления этой важной теоремы теоретики реляционных баз данных должны были продолжать поиск не выявленных видов аномалий и соответствующих им нормальных форм. Теперь же было доказано, что для того, чтобы получить уверенность в отсутствии всех видов аномалий модификации, следует привести таблицу к ДКНФ.
Далее мы кратко рассмотрим первые три наиболее важные для практики нормальные формы, а также доменно-ключевую нормальную форму.
1НФ
Любая таблица, удовлетворяющая определению отношения, находится в 1НФ. Вот основные характеристики таблицы в 1НФ:

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

Таблица (отношение) в 1НФ свободна от некоторых аномалий, но все же подвержена многим другим. Например, таблица Продажи (Клиент, Товар, Количество, Цена) находится в 1НФ, но, как уже было отмечено, подвержена аномалиям удаления и добавления записей.
2НФ

ФИО	Секция	Плата
Иванов	Футбол	100
Иванов	Волейбол	120
Петров	Лыжи	170
Сидоров	Шахматы	200
Сидоров	Лыжи	170
Федоров	Лыжи	170
Федоров	Волейбол	120

Каждая таблица в 1НФ должна иметь первичный ключ. Он может состоять из одного или более столбцов (атрибутов). В последнем случае ключ называется составным. Чтобы таблица была в 2НФ, все ее неключевые столбцы должны однозначно определяться всем ключом, т. е. всеми его компонентами, а не некоторыми из них.
Ключом в данном отношении является {ФИО, Секция}, но оно содержит функциональную зависимость Секция-> Плата. Аргумент (левая часть) этой зависимости является лишь частью составного ключа. Отношение секции имеет аномалии удаления и добавления. Так, если мы захотим удалить записи с именем "Иванов", то потеряем стоимость шахматной секции. Мы не сможем добавить запись о новой секции, пока в нее кто-нибудь не запишется. Данных аномалий можно было бы избежать, если бы атрибут Плата зависел от всего ключа (однозначно определялся всем ключом).
Отношение Секции (ФИО, Секция, Плата) в 1НФ можно разбить на два отношения во 2НФ:

Секция__члены (Имя, Секция);

Секция__плата (Секция, Плата).
3НФ
В отношениях могут быть так называемые транзитивные зависимости, являющиеся источником аномалий модификации данных, против которых 2НФ бессильна. Транзитивная зависимость имеет место тогда, когда один атрибут однозначно определяет второй, второй однозначно определяет третий и т. д.
Рассмотрим в качестве примера отношение Гости(ID_гостя, Тип_номера, Плата), представляющее сведения о проживающих в гостинице. Ключом в этом отношении является ID_гостя, Плата однозначно определяется атрибутом Тип_номера (например, люкс, полулюкс и т. д.), т. е. имеется функциональная зависимость Тип_номера-> Плата. Поскольку каждый гость проживает только в одном номере определенного типа, в отношении есть и функциональная зависимость ID_гостя->Тип_номера.
Таким образом, возникает транзитивная (опосредованная) зависимость ID_гостя->Плата. Так как ключ состоит из единственного атрибута ID_гостя, то отношение находится в 2НФ.
В рассматриваемом отношении существует аномалия удаления. Удалив запись, мы потеряем не только информацию о каком-то госте (где он проживает), но и сведения о том, сколько стоит номер соответствующего типа.
Чтобы устранить указанную аномалию, следует декомпозировать исходное отношение Гости(ID_гостя, Тип_номера, Плата) на два:

Проживание (ID_гостя, Тип_номера);
Тип_плата (Тип_номера, Плата).

Эти отношения будут находиться в 2НФ и не содержать транзитивных зависимостей.
Таким образом, отношение находится в ЗНФ, если оно находится в 2НФ и не содержит транзитивных зависимостей.
Доменно-ключевая НФ
Если таблица находится в ЗНФ, то остается довольно мало шансов для возникновения аномалий модификации данных, но они все равно есть. Чтобы исключить все виды возможных аномалий, таблица должна находиться в доменно-ключевой нормальной форме (ДКНФ).
Понятие ДКНФ довольно просто: отношение находится в ДКНФ, если каждое ограничение, накладываемое на него, является логическим следствием определения доменов и ключей. Термин ограничение (constraint) здесь намеренно трактуется широко. Р. Фагин определяет ограничение как любое правило, регулирующее возможные статические значения атрибутов, достаточно точное, чтобы можно было проверить его выполнимость. Правила редактирования, ограничения взаимосвязей и структуры отношений, функциональные и многозначные зависимости являются примерами таких ограничений. Отсюда исключаются ограничения, связанные с изменением данных (ограничения, зависящие от времени). Другими словами, отношение находится в ДКНФ, если выполнение ограничений на домены и ключи влечет за собой выполнение всех ограничений.
Однако в настоящее время не известен алгоритм преобразования отношения в ДКНФ. Неизвестно также, какие отношения в принципе могут быть приведены к ДКНФ. Поиск и создание отношений в ДКНФ сейчас является искусством, а не наукой. В литературе обычно приводятся только примеры отношений в ДКНФ, которые мы здесь рассматривать не будем.

1 2 3 4 5 6 7 8 9

	Тема Архитектура предприятия Исторические аспекты архитектуры предприятия.... Ения. Комплекс проектов совершенствования деятельности. Пути развития архитектуры предприятия. Типичные пользователи. Архитектура...		План лекции Язык sql в субд. Структура команды sql. Типы данных. Выражения База данных (БД) – это информационная модель объекта – именованная совокупность данных, отображающая состояние объектов, их свойства...
	Пер с англ. — М. Издательский Архитектура системы баз данных 65 Глава Введение в реляционные базы данных 92		Программа фиэб направление подготовки 230100 «Информатика и вычислительная... Архитектура баз данных. Модели данных. Иерархические, сетевые, реляционные модели данных. Модель «сущность-связь». Уровни проектирования:...
	Лекция I и проблема языка и сознания лекция II 31 слово и его семантическое... Монография представляет собой изложение курса лекций, про* читанных автором на факультете психологии Московского государственного...		Лекция I и проблема языка и сознания лекция II 31 слово и его семантическое... Монография представляет собой изложение курса лекций, про* читанных автором на факультете психологии Московского государственного...
	Инструкция по переносу данных по «Луч» из бд ms access в бд ms sql server Москва, 2011 По «Луч») является техническим документом Небанковской кредитной организации закрытого акционерного общества «Национальный расчетный...		1. Показать развитие и классификацию однопроцессорных архитектур... Архитектура общая функциональная и структурная организация машины, определяющая методы кодирования данных, состав, назначение, принципы...
	Содержание Введение Лекция Базы данных и файловые системы Файловые системы 1 Структуры файлов Лекция Ранние подходы к организации бд. Системы, основанные на инвертированных списках, иерархические и сетевые субд. Примеры. Сильные...		Литература 58 Лекция №15 Понятия и сущность данных, информации, знаний.... Лекция № Поиск полных текстов научных документов в мировых издательских системах 33
	Многоканальный цифровой комплекс регистрации сигналов «фантом» руководство по эксплуатации ...		Управление ит-инфраструктурой Понятие «информационно-технологическая инфраструктура», связь с понятиями «архитектура предприятия», «архитектура информационной...
	Приказ о назначении ответственного лица в области обработки и защиты... Постановление Правительства Российской Федерации от 1 ноября 2012 г. №1119 «Об утверждении требований к защите персональных данных...		Лекция Предмет, задачи и методы перевода Лекция Общая характеристика современной теории перевода. Лекция Переводческая эквивалентность
	Лекция Основы процесса тестирования по 3 Лекция Как протестировать неизвестную программу или наращиваемый подход к первичному функциональному тестированию по. 17		Пояснительная записка Студент Организация данных. Sql дает пользователю возможность изменять структуру представления данных, а также устанавливать отношения между...

Похожие: