что такое универсальное отношение бд

Универсальное отношение

Предположим, что проектирование базы данных «Питание» (рис. 3.2) начинается с выявления атрибутов и подбора данных, образец которых (часть блюд изготовленных и реализованных 1/9/94 г.) показан на рис. 4.1.

Этот вариант таблицы «Питание» не является отношением, так как большинство ее строк не атомарны. Атомарными являются лишь значения полей Блюдо, Вид, Рецепт (хотя он и большой), Порций и Дата_Р остальные же поля таблицы рис. 4.1 – множественные. Для придания таким данным формы отношения необходимо реконструировать таблицу. Наиболее просто это сделать с помощью простого процесса вставки, результат которой показан на рис. 4.2. Однако такое преобразование приводит к возникновению большого объема избыточных данных.

Рис. 4.1. Данные, необходимые для создания базы данных «Питание»

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

Рис. 4.2. Универсальное отношение «Питание»

4.3. Почему проект БД может быть плохим?

Начинающий проектировщик будет использовать отношение «Питание» (рис. 4.2) в качестве завершенной БД. Действительно, зачем разбивать отношение «Питание» на несколько более мелких отношений (см. например, рис. 3.2), если оно заключает в себе все данные? А разбивать надо потому, что при использовании универсального отношения возникает несколько проблем:

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

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

3. Аномалии включения. В БД не может быть записан новый поставщик («Няринга», Вильнюс, Литва), если поставляемый им продукт (Огурцы) не используется ни в одном блюде. Можно, конечно, поместить неопределенные значения в столбцы Блюдо, Вид, Порций и Вес (г) для этого поставщика. Но если появится блюдо, в котором используется этот продукт, не забудем ли мы удалить строку с неопределенными значениями?

По аналогичным причинам нельзя ввести и новый продукт (например, Баклажаны), который предлагает существующий поставщик (например, «Полесье»). А как ввести новое блюдо, если в нем используется новый продукт (Крабы)?

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

Многие проблемы этого примера исчезнут, если выделить в отдельные таблицы сведения о блюдах, рецептах, расходе блюд, продуктах и их поставщиках, а также создать связующие таблицы «Состав» и «Поставки» (рис. 4.3).

Источник

Универсальное отношение

Рассмотрим задачу проектирования БД на базе следующей таблицы:

Таблица «Сессия»

Шкала оценок: 0 – незачет, 1 – зачет, 2, 3, 4, 5 – оценки.

Этот вариант таблицы «Сессия» не является отношением, т.к. большинство ее столбцов не атомарны. Значение любого атрибута реляционной таблицы является атомарным, если само это значение, в свою очередь, не является реляционной таблицей (отношением). Атомарными являются значения столбцов ФИО СТУДЕНТА, СЕМЕСТР. Остальные столбцы таблицы – множественные.

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

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

Универсальное отношение «СЕССИЯ»

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

Однако при использовании универсального отношения возникают следующие проблемы:

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

2. Потенциальная противоречивость. Если при вводе данных, например, количества часов для дисциплины АНГЛИЙСКИЙ ЯЗЫК, была допущена ошибка, то для ее исправления необходимо найти все строки, содержащие сведения об этой дисциплине, и во всех этих строках произвести изменения. Также при заполнении такой таблицы могут быть использованы различные формы записи одного и того же значения, например: АНГЛ. ЯЗЫК и АНГЛИЙСКИЙ ЯЗЫК, МАТ. АНАЛИЗ и МАТЕМАТИЧЕСКИЙ АНАЛИЗ.

3. Аномалии модификации:

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

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

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

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

В таблицах РЕЗУЛЬТАТЫ СЕССИИ и УЧЕБНЫЙ ПЛАН конкретные значения заменены на их номера в других таблицах. Это значительно упрощает процедуру модификации текстовых значений.

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

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

— данные легко обновлять или удалять;

— исключается возможность рассогласования копий данных;

— уменьшается возможность введения некорректных данных.

Источник

4.2. Универсальное отношение

Предположим, что проектирование базы данных «Питание» (рис. 3.2) начинается с выявления атрибутов и подбора данных, образец которых (часть блюд изготовленных и реализованных 1/9/94 г.) показан на рис. 4.1.

Этот вариант таблицы «Питание» не является отношением, так как большинство ее строк не атомарны. Атомарными являются лишь значения полей Блюдо, Вид, Рецепт (хотя он и большой), Порций и Дата_Р остальные же поля таблицы рис. 4.1 – множественные. Для придания таким данным формы отношения необходимо реконструировать таблицу. Наиболее просто это сделать с помощью простого процесса вставки, результат которой показан на рис. 4.2. Однако такое преобразование приводит к возникновению большого объема избыточных данных.

Рис. 4.1. Данные, необходимые для создания базы данных «Питание»

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

Рис. 4.2. Универсальное отношение «Питание»

Источник