Проектирование логической структуры базы данных

 

Основная цель проектирования БД – это сокращение избыточности хранимых данных, и, следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте.

Предположим, что проектирование базы данных "Питание" начинается с выявления всех атрибутов (табл. 1).

Таблица 1

Наз- вание блюда

Вид

Ре- цепт

Чис- ло пор- ций

Дата рас- хода

Название продукта

Число калорий

Мас- са про- дукта в блюде

Наз- вание постав- щика

Город

Страна

Масса поставки

Цена поставки

Дата поставки продукта

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

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

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

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

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

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

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

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

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

2.1. Основные понятия реляционных баз данных

 

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

Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего информацию о сотрудниках некоторой организации (рис. 4).

Рис. 4

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

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

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов «Номера пропусков» и «Номера отделов» относятся к типу целых чисел, но не являются сравнимыми.

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

Схема отношения – это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень, или «арность» схемы отношения – мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Схема БД (в структурном смысле) – это набор именованных схем отношений.

Кортеж – это набор именованных значений заданного типа.

Первичный ключ отношения – один или более атрибутов, однозначно идентифицирующих каждый кортеж.

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

Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками – кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят «столбец таблицы», имея в виду «атрибут отношения». Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД.

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