Основные недостатки (или аномалии), возникающие в проектах. Способы их исключения.

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

1. Более правильный: первичные отношения представляются единственной таблицей. Количество атрибутов составляет 3-4 десятка.

2. Когда в качестве первичных отношений берутся аналоговые варианты сущностей, полученные на этапе проектирования сущность-связь.

 

Предметная область: Необходимо создать ИБ для некоторого предприятия. Оно занимается производственной деятельностью и осуществляет выпуск некоторых изделий.

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

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

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

Изделие	Вид	Цена	Детали	ЦенаДетали	ФизХарактер	Поставщик	АдресПоставщика	Дата закупки
Изд1	Вид1	#	Деталь2	#	-	-	-	-
Изд1	Вид1	#	Деталь3	#	-	-	-	-
Изд1	Вид1	#	…			-	-	-
Изд1	Вид1	#	Деталь15	#	-	-	-	-
Изд3	Вид3

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

Если продублировать кое-какую информацию, то получится первичная таблица.

Такая таблица обладает недостатками:

1. Аномалия избыточности

2. Потенциальная противоречивость – Аномалия обновления

3. Аномалия включения информации (невозможно занести информацию о потенциальных поставщиках, например)

4. Аномалия удаления (потеря полезной информации при необходимости удалить какую-то строчку).

 

При проектировании РБД единственный способ – декомпозиция или разбиение на две и более таблиц.

Таблица 1 Изделия

Наименование	Вид	Цена
Изд.1	-	-
Изд.2	-	-

 

Таблица 2 Состав изделия

НаименованиеИзделя	КомплектующаяДеталь	СтоимостьДетали	ФизХарактер
Изд1	Деталь1

 

Таблица 3 Поставщики

НаименованиеПоставщика	Адрес
Пост1	-
Пост2	-

 

Таблица 4 Поставки

Поставщик	Деталь	Дата
Пост1	Деталь1	-
Пост1	Деталь3	-

 

Проведем анализ:

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

 

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

 

Таблица 1 Изделия

Код

Наименование

Вид

Цена

Код или шифр должен быть небольшого размера, чтобы не вносить избыточность. При добавлении информации код должен генерироваться автоматически. Код может быть числом или же строковым.

 

 

Таблица 2 Состав

Код Изделия

Детали

Стоимость Детали

ФизХар

 

Таблица 3 Поставщики

Код Поставщика

Наименование

Адрес

 

Таблица 4 Поставки

Код Поставщика

Деталь

Дата

 

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

Дальше нужно снова использовать декомпозицию.

 

Таблица 5 Детали

Код Детали

Наименование

Стоимость

Физ Характер

В таблице 2 Столбик Детали заменяется на Код детали. Избыточность уменьшилась. Кроме того, характеристики Стоимость и Физ Характеристики будут удалены из таблицы 2.

Анализ: Аномалии уменьшены на сколько возможно.

Можно еще выделить вид в отдельную таблицу.

Корректнее стоимость детали привязать к поставке, а из деталей удалить.

 

Таблица 6 Возможные виды изделий

Код вида

Наименование

 

Таблица 7 История цен

Код изделия

Дата

Цена

Но еще лучше следующее: Можно ориентироваться по дате продажи.

 

То, что мы сейчас проделали – интуитивная нормализация

02112011

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

Является наиболее распространенной. Почему?

1. Представление данных в виде таблиц является наиболее удобным форматом для пользователя.

2. Существует некоторый математический аппарат, который позволяет задавать и описывать процедуры манипулирования данными.

В теории множеств существует понятие отношений:

Если заданное множество Д1, Д2,..,Дn, то отношением R является декартовым произведением исходных множеств (оно состоит из кортежей, при чем каждый элемент является элементом соответствующего множества). При этом исходные множества называются доменами. n – степень соответствующего отношения.

 

Строки таблицы – кортежи. Столбцы – атрибуты Ai. Количество атрибутом равно количеству исходных множеств. Атрибуты – подмножество Д.

 

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

С другой стороны каждый атрибут Ai можно рассматривать как проекцию на соответствующую i-ую координату.

Записывается так R1(A1, A2)

Можно дать новое определение:

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

В РМД предполагается, что все отношения являются нормализованными (все атрибуты являются атомарными). Операции над отношениями осуществляются в РМД двумя способами: методы реляционного исчисления и методы реляционной алгебры.

МРИ базируются на теоретических основах исчисления предикатов. Использование РИ имеет следующее преимущество:

1. Появляется возможность манипулирования данных на уровне выходного документа.

2. РИ позволяет создавать языки манипулирования данными не процедурного типа (типа SQL).

3. Пользователю дается возможность создавать и описывать данные независимо от процедур поиска и доступа к данным.

p(x1, x2,…,xn)=0|1

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

В РИ принято связывать с каждым отношением вида R(A1, A2,…,An) некоторый предикат p(x1, x2,…,xn). При этом значение атрибутов и значение аргументов предиката имеют одну и ту же область определения. Тогда, если такая связь создана, если предикат p с конкретными значениями атрибутов (a1, a2, …, an) принимает истинное значение, то соответствующий кортеж <a1,an> входит в состав отношения R. Если значение ложь, кортеж не принадлежит исходному отношению.

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

R1={(12,1),(10,4),(8,6),(7,3)}

Соответствующий предикат p1(x1,x2). Область определения первого 12, 10,8,7. Второго 1,4,6,3.

Можно на основе существующего предиката задать новое выражение. p2(x1)=

Создаем новое отношение R2(A1)={10,8,7}

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

 

МРА

Любой алгебраический процесс предполагает наличие двух составляющих: операнды и операции. В РМД операнды – таблицы или отношения, возможные операции – операция над абстрактными множествами.

1. Операция объединения отношений. Если заданы два отношения А = {1,2,=,//} В= {8,10,+,-}. Результирующее отношение С состоит из элементов или отношения А, или отношения В. С= {1,2,=,//,8,10,+,-}.

2. Операция пересечения. Результат операции – это отношение С, состоящее из кортежей, который принадлежат и А, и В. В нашем примере отношение С пустое.

3. Операция вычитания. Результат вычитания В из А – это отношение С, состоящее из кортежей принадлежащих А, но не принадлежащих В.

4. Операция декартово произведения отношений. Результат – создание отношение С, полученное соединением каждого кортежа из отношения А с каждым кортежем из отношения В. Студенты*дисциплины = студент и какие дисциплины он изучает.

5. Операция проекция. Два операнда, но первый операнд – это отношение, а второй – это список атрибутов. A = {1,2,4,=,//,+} B={a1,a3}. С = {1,4,=,+}. Скрытие данных от отдельных видов пользователей.

6. Операция ограничения. Имеет два операнда: отношение и логическое выражение, задающее какое-то условие. Результирующее отношение – только те кортежи, которые соответствуют заданному логическому выражению. На этом основан Фильтр.

7. Операция соединения позволяет создать новое отношение из исходных А и В путем соединения однопорядковых строк из каждого отношения.

 

НОРМАЛИЗАЦИЯ.

 

Любая реляционная база данных включает в себя структурнуи и семантическую информацию.

Структура БД определяется множеством таблиц(отношений) и множеством связей.

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

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

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

 

Функциональная зависимость соответствует отношению 1 к 1 или 1 ко многим внутри таблицы.

 

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

 

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

 

Условия обратимости:

1. в новых таблицах не должны появляться ранее отсутствовашие кортежи.

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

 

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

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

 

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

 

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

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

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

сотр(фио, адрес, дети, ист. работы)

дети(имя, дата)

ист. раб.(дата приема на должность, должность, история зп)

ист. зп.(дата начисления, сумма)

В конечных отношениях все атрибуты - атомарные.

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

 

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

БД поставок товаров. Поставщики могут один и тот же товар, но существуют ограничения, что один и тот же товар поставляется всегда по одной и той же цене.

поставки(поставщик, товар, цена товара)

поставщик, товар -> цена

товар -> цена

тогда:

(поставщик, товар)

(товар, цена)

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

 

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

Для определения ТНФ вводится понятие транзитивной функциональной зависимости.

Допустим, атрибуты А, Б, С принадлежат одной и той же таблице и отношению. При этом в таблице есть отношение АкБ и БкС, обратной нет. В этом случае С транзитивно зависит от атрибута А. А, как правило, первичный ключ.

 

Пример:

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

1. каждая организация использует только одно складское помещение;

2. одно и то же складское помещение может разделяться между несколькими организациями.

Таблица Хранение_товаров (Организация, Склад, Объем склада)

Организация – первичный ключ. Недостатки или аномалии: Дублирование информации о складе и об объеме складского помещения.

Зависимости: Организация -> склад; склад->объем. Следовательно, орг->объем

Разбиваем на две таблицы: Хранение_товаров (Организация, склад) и Характеристики_склада (Склад, объем).

Недостатки исчезают.

 

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