БАЗЫ ДАННЫХ

Плеханова Экономический факультет
Кафедра вычислительной техники и информационных технологий

неформального словесного описания информационной структуры предметной области к формализованному описанию

объектов ПО в терминах некоторой модели и включает следующие этапы проектирования:
Системный анализ и словесное описание информационных объектов ПО.
Существуют два подхода к выбору состава и структуры предметной области:
Функциональный подход. Он реализует принцип движения «от задач» и применяется тогда, когда известны функции некоторой группы лиц и комплексов задач, для облуживания информационных потребностей которых создается БД. В этом случае можно четко выделить необходимый минимальный набор объектов, которые должны быть описаны.
Предметный подход. Информационные потребности будущих пользователей жестко не зафиксированы. Невозможно выделить необходимый минимальный набор объектов, которые необходимо описывать. В описание ПО в этом случае включаются такие объекты и взаимосвязи, которые наиболее характерны и существенны для нее. Проектируемая БД называется предметной и может быть использована для множества разнообразных, заранее неопределенных задач. Такой подход кажется наиболее перспективным, однако может привести к избыточности задач или потребностей пользователей, а с другой стороны, учитывает возможность наращивания новых приложений

данных (например, в терминах ER-моделей)., отображающих информационное содержание конкретной ПО.

Вначале выполняется выделение из воспринимаемой реальности требуемой части ПО, определяются ее границы, происходит абстрагирование от несущественных частей для конкретного применения БД. В результате определяются объекты, их свойства и связи, которые будут существенны для будущих пользователей системы.
Даталогическое или логическое проектирование БД: описание БД в терминах принятой даталогической модели данных (например, реляционной), организация данных, выделенных на предыдущем этапе, в такую форму, которая принята в выбранной конкретной СУБД, используя ее типы и модели данных. Даются рекомендации по выбору методов доступа к данным.
IV. Физическое проектирование БД: выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения, выбор рациональной структуры хранения данных и методов доступа к ним, исходя из того арсенала средств и методов, который предоставляет разработчику конкретная СУБД.

Каким образом отобразить объекты предметной области в абстрактные объекты модели

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

информации об объектах решаемой задачи в рамках одной таблицы и

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

подход - процесс проектирования производится в терминах реляционной модели данных

методом последовательных приближений к удовлетворительному набору схем отношений.
Исходной точкой является представление ПО в виде одного или нескольких отношений, и на каждом шаге проектирования производится некоторый набор схем отношений, обладающих лучшими свойствами.
Процесс проектирования представляет собой процесс нормализации схем отношений, причем каждая следующая нормальная форма обладает свойствами лучшими, чем предыдущая.
В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:
первая нормальная форма (1NF);
вторая нормальная форма (2NF);
третья нормальная форма (3NF);
нормальная форма Бойса-Кодда (BCNF);
четвертая нормальная форма (4NF);
пятая нормальная форма (5NF или PJ/NF).
Основные свойства нормальных форм:
каждая следующая нормальная форма в некотором смысле лучше предыдущей;
при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.

основе процесса проектирования лежит метод нормализации, декомпозиция отношения, находящегося в

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

Определение 1. Функциональная зависимость
В отношении R атрибут Y функционально зависит от атрибута X
(X и Y могут быть составными) в том и только в том случае,
если каждому значению X соответствует в точности одно значение Y:
R.X ->R.Y.

Определение 2. Полная функциональная зависимость
Функциональная зависимость R.X ->R.Y называется полной,
если атрибут Y не зависит функционально от любого точного подмножества X.

3. Транзитивная функциональная зависимость
Функциональная зависимость R.X -> R.Y называется

транзитивной,
если существует такой атрибут Z, что имеются функциональные зависимости R.X -> R.Z и R.Z -> R.Y
и отсутствует функциональная зависимость R.Z -/-> R.X.

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

Определение 5. Взаимно независимые атрибуты
Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является функционально зависимым от других.

6 Первая нормальная форма - все атрибуты сущности содержат атомарные

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

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

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

ходе дополнительного уточнения того, какие данные необходимо учитывать, выяснилось следующее:

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

видно, хотя первичным ключом является составной атрибут СОТР_НОМЕР, ПРО_НОМЕР, атрибуты

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

7. Вторая нормальная форма (в этом определении предполагается, что единственным

ключом отношения является первичный ключ): Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый не ключевой атрибут полностью зависит от первичного ключа.
Можно произвести следующую декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)
Первичный ключ: СОТР_НОМЕР
Функциональные зависимости: СОТР_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР -> ОТД_НОМЕР
ОТД_НОМЕР -> СОТР_ЗАРП
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Первичный ключ: СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
Каждое из этих двух отношений находится в 2NF, и в них устранены отмеченные выше аномалии (легко проверить, что все указанные операции выполняются без проблем).

2 Рассмотрим в качестве предметной области – учебный процесс.
Представим схему

отношения (вся информация в одной таблице):
СТУДЕНТЫ-ДИСЦИПЛИНЫ-ОЦЕНКИ
(ФИО, №_зач, группа, дисц, оценка)
Первичный ключ: №_зач, дисц
Функциональные зависимости: №_зач -> ФИО, №_зач -> группа
не зависят от атрибута дисц , т.е. зависят только от части первичного ключа и, следовательно, не находятся во второй нормальной форме.
Можно произвести следующую декомпозицию отношения
СТУДЕНТЫ-ДИСЦИПЛИНЫ-ОЦЕНКИ :

СТУДЕНТЫ (ФИО, №_зач, группа)
СТУДЕНТЫ-ОЦЕНКИ (№_зач, дисц, оценка)
Оба отношения находятся во второй нормальной форме.
Укажите , какие аномалии могут возникнуть, если не приводить отношение ко второй нормальной форме.

еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ, находящееся в 2NF. Заметим, что функциональная

зависимость СОТР_НОМЕР -> СОТР_ЗАРП является транзитивной;
она является следствием функциональных зависимостей
СОТР_НОМЕР -> ОТД_НОМЕР и ОТД_НОМЕР -> СОТР_ЗАРП.
Другими словами, заработная плата сотрудника на самом деле является характеристикой не сотрудника, а отдела, в котором он работает (это не очень естественное предположение, но достаточное для примера).
В результате мы не сможем занести в базу данных информацию, характеризующую заработную плату отдела, до тех пор, пока в этом отделе не появится хотя бы один сотрудник (первичный ключ не может содержать неопределенное значение). При удалении кортежа, описывающего последнего сотрудника данного отдела, мы лишимся информации о заработной плате отдела. Чтобы согласованным образом изменить заработную плату отдела, мы будем вынуждены предварительно найти все кортежи, описывающие сотрудников этого отдела. т.е. в отношении СОТРУДИКИ-ОТДЕЛЫ по-прежнему существуют аномалии.
Их можно устранить путем дальнейшей нормализации.
Определение 8. Третья нормальная форма (определение дается в предположении существования единственного ключа.) Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.

произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ:

СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> ОТД_НОМЕР
ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП)
Первичный ключ:
ОТД_НОМЕР
Функциональные зависимости:
ОТД_НОМЕР -> СОТР_ЗАРП
Каждое из этих двух отношений находится в 3NF и свободно от отмеченных аномалий.
Если отказаться от того ограничения, что отношение обладает единственным ключом, то определение 3NF примет следующую форму:
Определение 8*
Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF, и каждый не ключевой атрибут не является транзитивно зависимым от какого-либо ключа R (или другими словами не зависит функционально от какого-либо другого не ключевого атрибута).

3 Рассмотрим отношение
СТУДЕНТ-ФАКУЛЬТЕТ-КАФЕДРА
(ФИО, №_зач, группа, фак_т, спец, вып_каф)
В этом

отношении есть зависимости:
группа -> фак_т
группа -> спец
группа -> вып_каф
вып_каф -> фак_т
Проведем декомпозицию исходного отношения:
СТУДЕНТ-ГРУППА (№_зач , ФИО, спец, группа)
ГРУППА-КАФЕДРА (группа, вып_каф)
КАФЕДРА-ФАКУЛЬТЕТ (вып_каф, фак_т)

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

иногда полезно продолжить процесс нормализации.
Пример 3 Рассмотрим следующий пример

схемы отношения:
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ИМЯ, ПРО_НОМЕР, СОТР_ЗАДАН)
Возможные ключи:
СОТР_НОМЕР, ПРО_НОМЕР
СОТР_ИМЯ, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> CОТР_ИМЯ
СОТР_НОМЕР -> ПРО_НОМЕР
СОТР_ИМЯ -> CОТР_НОМЕР
СОТР_ИМЯ -> ПРО_НОМЕР
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
СОТР_ИМЯ, ПРО_НОМЕР -> CОТР_ЗАДАН
В этом примере мы предполагаем, что личность сотрудника полностью определяется как его номером, так и именем (это снова не очень жизненное предположение, но достаточное для примера).
В соответствии с определением 8* отношение СОТРУДНИКИ-ПРОЕКТЫ находится в 3NF. Однако тот факт, что имеются функциональные зависимости атрибутов отношения от атрибута, являющегося частью первичного ключа, приводит к аномалиям. Например, для того, чтобы изменить имя сотрудника с данным номером согласованным образом, нам потребуется модифицировать все кортежи, включающие его номер.

9. Детерминант . Детерминант - любой атрибут, от которого полностью

функционально зависит некоторый другой атрибут.
Определение 10. Нормальная форма Бойса-Кодда :Отношение R находится в нормальной форме Бойса-Кодда (BCNF) в том и только в том случае, если каждый детерминант является возможным ключом.
Очевидно, что это требование не выполнено для отношения СОТРУДНИКИ-ПРОЕКТЫ. Можно произвести его декомпозицию к отношениям СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ)
Возможные ключи: СОТР_НОМЕР
СОТР_ИМЯ
Функциональные зависимости:
СОТР_НОМЕР -> CОТР_ИМЯ
СОТР_ИМЯ -> СОТР_НОМЕР
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Возможный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
Возможна альтернативная декомпозиция, если выбрать за основу СОТР_ИМЯ. В обоих случаях получаемые отношения СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ находятся в BCNF, и им не свойственны отмеченные аномалии.

4 Рассмотрим пример следующей схемы отношения:
ПРОЕКТЫ (ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН)

Отношение ПРОЕКТЫ содержит номера проектов, для каждого проекта список сотрудников, которые могут выполнять проект, и список заданий, предусматриваемых проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания.
Каждый кортеж отношения связывает некоторый проект с сотрудником, участвующим в этом проекте, и заданием, который сотрудник выполняет в рамках данного проекта. По причине сформулированных выше условий единственным возможным ключом отношения является составной атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, и нет никаких других детерминантов. Следовательно, отношение ПРОЕКТЫ находится в BCNF. Но при этом оно обладает недостатками: если, например, некоторый сотрудник присоединяется к данному проекту, необходимо вставить в отношение ПРОЕКТЫ столько кортежей, сколько заданий в нем предусмотрено.
Определение 11. Многозначные зависимости: В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.
В отношении ПРОЕКТЫ существуют следующие две многозначные зависимости:
ПРО_НОМЕР -> -> ПРО_СОТР
ПРО_НОМЕР -> -> ПРО_ЗАДАН

показать, что в общем случае в отношении R (A, B,

C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, когда существует многозначная зависимость R.A -> -> R.C.
Дальнейшая нормализация отношений, подобных отношению ПРОЕКТЫ, основывается на следующей теореме:
Теорема Фейджина
Отношение R (A, B, C) можно спроецировать без потерь в отношения R1 (A, B) и R2 (A, C) в том и только в том случае, когда существует MVD (multi-valued dependency – MVD) A -> -> B | C.
Под проецированием без потерь понимается такой способ декомпозиции отношения, при котором исходное отношение полностью и без избыточности восстанавливается путем естественного соединения полученных отношений.
Определение 12. Четвертая нормальная форма
Отношение R находится в четвертой нормальной форме (4NF) в том и только в том случае, если в случае существования многозначной зависимости
A -> -> B все остальные атрибуты R функционально зависят от A.
В нашем примере можно произвести декомпозицию отношения ПРОЕКТЫ в два отношения ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ:
ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР)
ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН)
Оба эти отношения находятся в 4NF и свободны от отмеченных аномалий.

всех рассмотренных до этого момента нормализациях производилась декомпозиция одного отношения

в два. Иногда это сделать не удается, но возможна декомпозиция в большее число отношений, каждое из которых обладает лучшими свойствами.
Пример 5 Рассмотрим, например, отношение
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР, ОТД_НОМЕР, ПРО_НОМЕР)
Предположим, что один и тот же сотрудник может работать в нескольких отделах и работать в каждом отделе над несколькими проектами. Первичным ключом этого отношения является полная совокупность его атрибутов, отсутствуют функциональные и многозначные зависимости.
Поэтому отношение находится в 4NF. Однако в нем могут существовать аномалии, которые можно устранить путем декомпозиции в три отношения.
Определение 13. Зависимость соединения
Отношение R (X, Y, ..., Z) удовлетворяет зависимости соединения *
(X, Y, ..., Z) в том и только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y, ..., Z.

14. Пятая нормальная форма: Отношение R находится в пятой нормальной

форме (нормальной форме проекции-соединения - PJ/NF) в том и только в том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R.
Введем следующие имена составных атрибутов:
СО = {СОТР_НОМЕР, ОТД_НОМЕР}
СП = {СОТР_НОМЕР, ПРО_НОМЕР}
ОП = {ОТД_НОМЕР, ПРО_НОМЕР}
Предположим, что в отношении СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ существует зависимость соединения:
* (СО, СП, ОП)
На примерах легко показать, что при вставках и удалениях кортежей могут возникнуть проблемы. Их можно устранить путем декомпозиции исходного отношения в три новых отношения:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, ОТД_НОМЕР)
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР)
ОТДЕЛЫ-ПРОЕКТЫ (ОТД_НОМЕР, ПРО_НОМЕР)
Пятая нормальная форма - это последняя нормальная форма, которую можно получить путем декомпозиции. Ее условия достаточно нетривиальны, и на практике 5NF не используется.
Замечание. Если отношения не нормализованы, то возникает проблемы избыточности, потенциальной противоречивости (аномалии обновления), аномалии включения, аномалии удаления.
 

реляционной базы данных в терминах отношений на основе механизма нормализации

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

структуры базы данных при помощи алгоритма нормализации, имеет серьезные недостатки:

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

вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн

Ченом . В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.
Прежде, чем мы коротко рассмотрим особенности одной из распространенных семантических моделей, остановимся на их возможных применениях:
1. Наиболее часто на практике семантическое моделирование используется на первой стадии проектирования базы данных. При этом в терминах семантической модели производится концептуальная схема базы данных, которая затем вручную преобразуется к реляционной (или какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых достаточно четко оговорены все этапы такого преобразования.
2. Реализуется автоматизированная компиляция концептуальной CASE-схемы в реляционную. При этом известны два подхода:
на основе явного представления концептуальной схемы как исходной информации для компилятора;
построения интегрированных систем проектирования с автоматизированным созданием концептуальной схемы на основе интервью с экспертами предметной области.
И в том, и в другом случае в результате производится реляционная схема БД в третьей нормальной форме.

Работа с базой данных в семантической модели, т.е. СУБД, основанные

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

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

представитель данной сущности.
Например, представителем сущности «Сотрудник» может быть «Сотрудник

Иванов».
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.
Определение 3. Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.
Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательнми). Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т.п.

г.

прямоугольника, определяющего сущность (рис. 2).
Определение 4. Ключ сущности -

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

г.

различных ключей.
Ключевые атрибуты изображаются на диаграмме подчеркиванием (рис. 3).

Определение 5. Связь - это графически изображаемая ассоциация, устанавливаемая между двумя сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).
Связи позволяют по одной сущности находить другие сущности, связанные с нею.
Например, связи между сущностями могут выражаться следующими фразами – «СОТРУДНИК может иметь несколько ДЕТЕЙ», «каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ».
Графически связь изображается линией, соединяющей две сущности (рис. 4).

и одно или два наименования. Наименование обычно выражается в неопределенной

глагольной форме: "иметь", "принадлежать" и т.п.
Каждое из наименований относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.
Каждая связь может иметь один из следующих типов связи (рис.5):

г.

один экземпляр первой сущности (левой) связан с одним экземпляром второй

сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней. Характерный пример такой связи приведен на рис. 4.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот тип связи должен быть заменен двумя связями типа один-ко-многим путем создания промежуточной сущности.
Каждая связь может иметь одну из двух модальностей связи (рис. 6).

одной сущности может быть связан с одним или несколькими экземплярами

другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность «должен» означает, что экземпляр одной сущности обязан быть связан не менее чем с одним экземпляром другой сущности. Связь может иметь разную модальность с разных концов (как на рис. 4).
Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь следующей схемой построения фраз:
<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.
Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на рис.4 читается так:
Слева направо: «каждый сотрудник может иметь несколько детей».
Справа налево: «Каждый ребенок обязан принадлежать ровно одному сотруднику».

г.

и в реляционных схемах баз данных, в ER-схемах вводится понятие

нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Заметим, что формулировки нормальных форм ER-схем делают более понятным смысл нормализации реляционных схем:
В первой нормальной форме ER-схемы устраняются повторяющиеся атрибуты или группы атрибутов, т.е. производится выявление неявных сущностей, «замаскированных» под атрибуты.
Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального идентификатора. Эта часть уникального идентификатора определяет отдельную сущность.
В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности

разработки простой ER-модели
При разработке ER-моделей мы должны получить следующую информацию

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

разработки простой ER-модели
Выделим все существительные в этих предложениях - это

будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):
Покупатель - явный кандидат на сущность.
Накладная - явный кандидат на сущность.
Товар - явный кандидат на сущность
(?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.
(?)Наличие товара – это, скорее всего, атрибут, но атрибут какой сущности?
Сразу возникает очевидная связь между сущностями – «покупатели могут покупать много товаров» и «товары могут продаваться многим покупателям».
Первый вариант диаграммы выглядит так (рис. 7).

что фирма имеет несколько складов. Причем, каждый товар может храниться

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

г.

выглядеть следующим образом (рис. 8).
Пора подумать об атрибутах

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

разработки простой ER-модели
Снова выпишем все существительные, которые будут потенциальными атрибутами,

и проанализируем их:
юридическое лицо - термин ненужный, т.к.фирма не работает с физическими лицами. Не обращаем внимания;
наименование покупателя - явная характеристика покупателя;
адрес - явная характеристика покупателя;
банковские реквизиты - явная характеристика покупателя;
наименование товара - явная характеристика товара;
(?)цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?
единица измерения - явная характеристика товара;
номер накладной - явная уникальная характеристика накладной;
дата накладной - явная характеристика накладной;
(?)список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность;
(?)количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто «товара», а «товара в накладной»;

разработки простой ER-модели
(?)цена товара в накладной - опять же это

должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?
сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную;
наименование склада - явная характеристика склада.
В ходе дополнительной беседы с менеджером удалось прояснить различные понятия цен. Оказалось, что каждый товар имеет некоторую текущую цену. Эта цена, по которой товар продается в данный момент. Естественно, что эта цена может меняться со временем. Цена одного и того же товара в разных накладных, выписанных в разное время, может быть различной. Таким образом, имеется две цены - цена товара в накладной и текущая цена товара. С возникающим понятием «Список товаров в накладной» все довольно ясно. Сущности «Накладная» и «Товар» связаны друг с другом отношением типа много-ко-многим. Такая связь, как мы отмечали ранее, должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность «Список товаров в накладной».

разработки простой ER-модели
Связь ее с сущностями «Накладная» и «Товар» характеризуется

следующими фразами:
каждая накладная обязана иметь несколько записей из списка товаров в накладной;
каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную;
каждый товар может включаться в несколько записей из списка товаров в накладной;
каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром.
Атрибуты «Количество товара в накладной» и «Цена товара в накладной» являются атрибутами сущности «Список товаров в накладной».
Точно также поступим со связью, соединяющей сущности «Склад» и «Товар». Введем дополнительную сущность «Товар на складе». Атрибутом этой сущности будет «Количество товара на складе». Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.
Теперь можно внести все это в диаграмму «Оптовая фирма» (рис. 9).
Замечание. Утверждения, которые были сформулированы в ходе бесед с сотрудниками фирмы, например: «Каждый покупатель может получить несколько накладных», являются бизнес-правилами.
Бизнес-правила описывают правила работы данной организации и для БД это, по сути, ограничения целостности.

могут обобществить данные в одной полностью интегрированной базе данных. Чаще

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

из рассмотренных подходов к проектированию воздействует на результаты проектирования в

разных направлениях. Желание достичь и гибкости, и эффективности привело к формированию методологии проектирования, использующей как предметный, так и прикладной подходы.
В общем случае предметный подход используется для построения первоначальной информационной структуры, а прикладной – для ее совершенствования с целью повышения эффективности обработки данных.
Основная цель проектирования БД – это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте.
Так называемый, «чистый» проект БД («Каждый факт в одном месте») можно создать, используя методологию нормализации отношений.

нормализации часто заменяется применением практических методик и правил. Предлагаются 4

фундаментальных правила для проектирования БД с рациональной структурой:
В каждой таблице должен быть уникальный идентификатор (первичный ключ). Если это правило не выполняется, то добавьте столбец, уникально идентифицирующий каждую строку.
В таблице должны храниться сведения лишь об одном типе объектов. Например, если в таблице КНИГИ содержатся сведения о самих книгах (индекс_книги, название) и издательствах (название, адрес), то это данные о двух типах объектов. Такое хранение создает проблемы: если адрес издательства изменился, то коррективы придется вносить во все записи о книгах, изданных данным издательством.
Для нормализации следует разбить таблицу КНИГИ на две: КНИГИ и ИЗДАТЕЛЬСТВА.

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

учитывать названия и авторов книг в таблице КНИГИ. У книги может быть несколько авторов. Можно, конечно, хранить список всех авторов в одном столбце, но это затруднит обработку и поиск по отдельному автору. Другое решение – изменить структуру таблицы и добавить еще один или два столбца Автор1, Автор2. А если авторов три или больше?
Если необходимо хранить список значений, следует предусмотреть размещение дублирующих данных в другой таблице, связанной с главной. Для нашего примера получаем таблицы: КНИГИ(индекс_книги, название), АВТОРЫ(код_автора, ФИО), КНИГИ_АВТОРЫ(индекс_книги, код_автора). Такая структура позволяет описать книгу с любым числом авторов без изменения определения таблицы и не допускает наличия пустых мест при сохранении книги с одним автором.
В таблицах следует избегать столбцов, допускающих пустые значения.

дополнить практическими рекомендации, которые рекомендует Б. Послед :

Предусмотреть возможность добавления

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