Термин «реляционный» означает «основанный на отношениях». Реляционная база данных состоит из сущностей (таблиц), находящихся в некотором отношении друг с другом. Название произошло от английского слова relation-отношение.
Проектирование базы данных состоит из двух основных фаз: логического и физического моделирования.
Во время логического моделирования вы собираете требования и разрабатываете модель базы данных, не зависящую от конкретной СУБД (системы управления реляционными базами данных). Это похоже на то, как если бы вы создавали чертежи вашего дома. Вы могли бы продумать и начертить все: где будет кухня, спальни, гостиная. Но это все на бумаге и в макетах.
Во время физического моделирования вы создаете модель, оптимизированную для конкретного приложения и СУБД. Именно эта модель реализуется на практике. Если вернуться к дому из предыдущего абзаца, на этом этапе вам придется строить где-нибудь дом - таскать бревна, кирпичи…

Процесс проектирования базы данных состоит из следующих этапов:

• сбор информации;
• определение сущностей;
• определение атрибутов для каждой сущности;
• определение связей между сущностями;
• нормализация;
• преобразование к физической модели;
• создание базы данных.

Первые 5 этапов образуют фазу логического проектирования, а остальные два - фазу физического моделирования.

Логическая фаза

Логическая фаза состоит из нескольких этапов. Далее они все рассмотрены.

Сбор требований

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

Определение сущностей

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

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

Сущности состоят из атрибутов (столбцов таблицы) и записей (строк в таблице).

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

Любая таблица имеет следующие характеристики:

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

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

Определение атрибутов

Атрибут представляет свойство, описывающее сущность. Атрибуты часто бывают числом, датой или текстом. Все данные, хранящиеся в атрибуте, должны иметь одинаковый тип и обладать одинаковыми свойствами.
В физической модели атрибуты называют колонками.
После определения сущностей необходимо определить все атрибуты этих сущностей.
На диаграммах атрибуты обычно перечисляются внутри прямоугольника сущности. На рисунке вы найдете пример базы данных «Дома», только теперь для сущностей из этой базы определены некоторые атрибуты.


Для каждого атрибута определяется тип данных, их размер, допустимые значения и любые другие правила. К их числу относятся правила обязательности заполнения, изменяемости и уникальности.
Правило обязательности заполнения определяет, является ли атрибут обязательной частью сущности. Если атрибут является необязательной частью сущности, то он может принимать NULL-значение, иначе - нет.
Также вы должны определить, является ли атрибут изменяемым. Значения некоторых атрибутов не могут измениться после создания записи.
И, наконец, вам нужно определить, является ли атрибут уникальным. Если это так, то значения атрибута не могут повторяться.

Ключи

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

Возможный ключ

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

Первичные ключи

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

Альтернативные ключи

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

Внешние ключи

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

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

Определение связей между сущностями

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

Один-к-одному

Каждой записи первой сущности соответствует только одна запись из второй сущности. А каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Люди и Свидетельства о рождении. И у одного человека может быть только одно свидетельство о рождении.

Один-ко-многим

Каждой записи первой сущности могут соответствовать несколько записей из второй сущности. Однако каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Заказ и Позиция заказа. И в одном заказе может быть много товаров.

Многие-ко-многим

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

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

Нормализация

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

Первая нормальная форма

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

Для приведения сущности Дом в первую нормальную форму необходимо удалить повторяющиеся группы значений, т. е. удалить атрибуты Владелец 1-3, поместив их в отдельную сущность. Результат (Сущность Дом, приведенная к первой нормальной форме):

Вторая нормальная форма

Таблица во второй нормальной форме содержит только те данные, которые к ней относятся. Значения не ключевых атрибутов сущности зависят от первичного ключа. Если более точно, то атрибуты зависят от первичного ключа, от всего первичного ключа и только от первичного ключа.
Для соответствия второй нормальной форме сущности должны быть в первой нормальной форме.
Например, у сущности Дом на рисунке есть атрибут Цена литра бензина, который не имеет ничего общего с домами. Этот атрибут удаляется (или вы можете перенести его в другую сущность). А также мы переносим атрибут Мэр в отдельную сущность - этот атрибут зависит от города, где находится дом, а не от дома.
На рисунке изображена сущность Дом во второй нормальной форме (Сущность Дом, приведенная ко второй нормальной форме).

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

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

Ограничения

Ограничения (constrains) - это правила, за соблюдением которых следит система управления базы данных. Ограничения определяют множество значений, которые можно вводить в столбец или столбцы.
Например, вы не хотите, чтобы сумма заказа в вашем очень крутом магазине была бы меньше 500 рублей. Вы просто устанавливаете ограничение на колонку Сумма заказа.

Хранимые процедуры

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

ПРИМЕЧАНИЕ
Хранимые процедуры находятся в базе данных и выполняются на сервере базы данных. Как правило, они быстрее операторов SQL, поскольку хранятся в компилированном виде.

Целостность данных

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

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

Триггеры

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

Деловые правила

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

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

Все эти возможности можно применять для реализации деловых правил в базе данных.

Физическая модель

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

Денормализация

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

Термин «реляционный» означает «основанный на отношениях». Реляционная база данных состоит из сущностей (таблиц), находящихся в некотором отношении друг с другом. Название произошло от английского слова relation-отношение.
Проектирование базы данных состоит из двух основных фаз: логического и физического моделирования.
Во время логического моделирования вы собираете требования и разрабатываете модель базы данных, не зависящую от конкретной СУБД (системы управления реляционными базами данных). Это похоже на то, как если бы вы создавали чертежи вашего дома. Вы могли бы продумать и начертить все: где будет кухня, спальни, гостиная. Но это все на бумаге и в макетах.
Во время физического моделирования вы создаете модель, оптимизированную для конкретного приложения и СУБД. Именно эта модель реализуется на практике. Если вернуться к дому из предыдущего абзаца, на этом этапе вам придется строить где-нибудь дом - таскать бревна, кирпичи…

Процесс проектирования базы данных состоит из следующих этапов:

• сбор информации;
• определение сущностей;
• определение атрибутов для каждой сущности;
• определение связей между сущностями;
• нормализация;
• преобразование к физической модели;
• создание базы данных.

Первые 5 этапов образуют фазу логического проектирования, а остальные два - фазу физического моделирования.

Логическая фаза

Логическая фаза состоит из нескольких этапов. Далее они все рассмотрены.

Сбор требований

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

Определение сущностей

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

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

Сущности состоят из атрибутов (столбцов таблицы) и записей (строк в таблице).

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

Любая таблица имеет следующие характеристики:

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

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

Определение атрибутов

Атрибут представляет свойство, описывающее сущность. Атрибуты часто бывают числом, датой или текстом. Все данные, хранящиеся в атрибуте, должны иметь одинаковый тип и обладать одинаковыми свойствами.
В физической модели атрибуты называют колонками.
После определения сущностей необходимо определить все атрибуты этих сущностей.
На диаграммах атрибуты обычно перечисляются внутри прямоугольника сущности. На рисунке вы найдете пример базы данных «Дома», только теперь для сущностей из этой базы определены некоторые атрибуты.


Для каждого атрибута определяется тип данных, их размер, допустимые значения и любые другие правила. К их числу относятся правила обязательности заполнения, изменяемости и уникальности.
Правило обязательности заполнения определяет, является ли атрибут обязательной частью сущности. Если атрибут является необязательной частью сущности, то он может принимать NULL-значение, иначе - нет.
Также вы должны определить, является ли атрибут изменяемым. Значения некоторых атрибутов не могут измениться после создания записи.
И, наконец, вам нужно определить, является ли атрибут уникальным. Если это так, то значения атрибута не могут повторяться.

Ключи

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

Возможный ключ

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

Первичные ключи

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

Альтернативные ключи

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

Внешние ключи

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

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

Определение связей между сущностями

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

Один-к-одному

Каждой записи первой сущности соответствует только одна запись из второй сущности. А каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Люди и Свидетельства о рождении. И у одного человека может быть только одно свидетельство о рождении.

Один-ко-многим

Каждой записи первой сущности могут соответствовать несколько записей из второй сущности. Однако каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Заказ и Позиция заказа. И в одном заказе может быть много товаров.

Многие-ко-многим

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

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

Нормализация

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

Первая нормальная форма

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

Для приведения сущности Дом в первую нормальную форму необходимо удалить повторяющиеся группы значений, т. е. удалить атрибуты Владелец 1-3, поместив их в отдельную сущность. Результат (Сущность Дом, приведенная к первой нормальной форме):

Вторая нормальная форма

Таблица во второй нормальной форме содержит только те данные, которые к ней относятся. Значения не ключевых атрибутов сущности зависят от первичного ключа. Если более точно, то атрибуты зависят от первичного ключа, от всего первичного ключа и только от первичного ключа.
Для соответствия второй нормальной форме сущности должны быть в первой нормальной форме.
Например, у сущности Дом на рисунке есть атрибут Цена литра бензина, который не имеет ничего общего с домами. Этот атрибут удаляется (или вы можете перенести его в другую сущность). А также мы переносим атрибут Мэр в отдельную сущность - этот атрибут зависит от города, где находится дом, а не от дома.
На рисунке изображена сущность Дом во второй нормальной форме (Сущность Дом, приведенная ко второй нормальной форме).

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

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

Ограничения

Ограничения (constrains) - это правила, за соблюдением которых следит система управления базы данных. Ограничения определяют множество значений, которые можно вводить в столбец или столбцы.
Например, вы не хотите, чтобы сумма заказа в вашем очень крутом магазине была бы меньше 500 рублей. Вы просто устанавливаете ограничение на колонку Сумма заказа.

Хранимые процедуры

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

ПРИМЕЧАНИЕ
Хранимые процедуры находятся в базе данных и выполняются на сервере базы данных. Как правило, они быстрее операторов SQL, поскольку хранятся в компилированном виде.

Целостность данных

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

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

Триггеры

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

Деловые правила

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

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

Все эти возможности можно применять для реализации деловых правил в базе данных.

Физическая модель

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

Денормализация

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

Сущность (Entity) - реальный или абстрактный объект, имеющий существенное значение для предметной области. Сущность должна иметь наименование, выраженное существительным в единственном числе

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

Экземпляр сущности - это конкретный представитель данной сущности. Например, экземпляром сущности Сотрудник может быть сотрудник Иванов.

Каждая сущность должна обладать следующими свойствами:

иметь уникальное имя;

обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;

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

Атрибут (Attribute) - характеристика сущности, значимая для рассматриваемой предметной области и предназначенная для идентификации, классификации, количественной характеристики или выражения состояния сущности.

Существуют следующие виды атрибутов:

простой - состоит из одного элемента данных;

составной - состоит из нескольких элементов данных;

однозначный - содержит одно значение для одной сущности;

многозначный - содержит несколько значений для одной сущности;

необязательный - может иметь пустое (неопределенное) значение;

производный - значение, производное от значения другого атрибута.

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

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

Связи между сущностями

Связь (Relationship) - поименованная ассоциация между сущностями, значимая для рассматриваемой предметной области.

Степенью связи называется количество сущностей, участвующих в связи.

Мощность связи - число экземпляров сущности, участвующих в связи.

В зависимости от значения мощности связь может иметь один из трех типов:

один-к-одному (обозначается 1:1).

один-ко-многим(обозначается 1:N).

многие-ко-многим(обозначается M:N).

Один к одному. Означает, что в такой связи сущности с одной ролью всегда соответствует не более одной сущности с другой ролью. Так как степень связи для каждой сущности равна 1, то они соединяются одной линией.

Один-ко-многим. Сущности с одной ролью может соответствовать любое число сущностей с другой ролью.

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

Пару лет назад среди прочих моих занятий были онлайн уроки по основам построения логической структуры базы данных и языку SQL. Уроками на данный момент не занимаюсь, а вот сами записи остались, так что решила я их выложить, чего добру пропадать зря? 🙂

Сегодня речь пойдет о модели «сущность-связь», или entity-relationship model.

Теория

Модель “сущность-связь” (Entity-Relationship model или ER – модель) представляет собой высокоуровневую концептуальную модель данных, кото­рая была разработана с целью упрощения задачи проектирова­ния структур баз данных.

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

Цель диаграмм “сущность-связь” — это создать точное и полное отображение ре­альной предметной области (ПрО), используемое в дальнейшем в ка­честве источника информации для построения базы данных автоматизированных систем обработки информации (БД АСОИ).

Эта диаграмма или концептуальная модель ПрО должна отвечать сле­дующим тре­бованиям:

• Обеспечивать адекватное отображение ПрО;
• Представлять на языке, понятном, как будущим пользователям АСОИ, так и разработ­чикам БД;
• Содержать информацию о ПрО, достаточную для дальнейшего проек­тирова­ния БД (разработка логической и физической моделей);
• Гарантировать однозначную интерпретацию или толкование модели ПрО.

Основные концепции этой модели — понятия сущность, атрибут и связь.

СУЩНОСТЬ – это множество объектов реального мира с одинаковыми свой­ствами. Сущ­ность характеризуется независимым существованием и может быть объектом с фи­зическим (или реальным) существова­нием или объектом с концептуальным (или абстрактным) существо­ванием.

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

Практика

ПРИМЕР. Предметная область “Заказ билетов в кинотеатре ”. В кинотеатре показывают фильмы, билеты на которые можно купить в день показа или забронировать их заранее. В базе данных находится информация обо всех Кинопоказах в данном кинотеатре, в том числе о старых. У каждого кинопоказа своя стоимость, т.е. билеты на один и тот же фильм, но в разное время, могут отличаться по цене. Кинопоказ состоит из Фильма, информация о котором так же хранится в БД.

Для ПрО “Заказ билетов в кинотеатре ” сущностями будут выступать следующие понятия:

Кинопоказ

Фильмы

Зритель

Билет

Бронь

Стоимость

Графически сущности на диаграммах “сущность-связь” представляются в виде пря­моугольников:

АТРИБУТ — это средство, с помощью которого определяются свойства сущности или связи. Атрибут — это поименованная характеристика сущности. Наименова­ние атрибута должно быть уникальным для кон­кретной сущности, но может быть одинаковым для разных сущностей.

Конкретный набор атрибутов для сущности определяется задачами, в ко­торых они используются. Например, сущности ПрО “Заказ билетов в кинотеатре” можно описать с помощью следующей совокупности атрибутов:

Кинопоказ (Номер кинопоказа, Номер Фильма, Дата показа, Номер Стоимости);

Фильм (Номер фильма, Название, Продолжительность, Краткое описание);

Зритель (Номер зрителя, ФИО, дата рождения);

Билет (Номер зрителя, Номер кинопоказа, Стоимость билета);

Бронь (Номер зрителя, Номер кинопоказа, дата брони);

Стоимость (Номер стоимости, Номер кинопоказа, стоимость).

Графически изображение атрибутов сущности представляются в виде вы­носок, в ко­торых перечисляется список имен атрибутов. Например:

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

СВЯЗЬ – это отношение между экземплярами двух (и более) разных сущностей. Механизм связей используется для того, чтобы опре­делить взаимоотноше­ния между сущностями в ПрО. Кроме этого, существуют отношения между атрибутами отдельной сущности (будут рассмотрены при построении логи­ческих моделей).

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

Наименование связи должно нести в себе определенный смысл, чтобы было легче разобраться в том, как соотносятся сущности. Например, взаимо­отношение между сущ­ностями Зритель и Билет можно определить как “Покупает”.

Для графического представления связи на диаграммах “сущность-связь” использу­ется ромб. Внутри ромба определяется имя связи, а с помощью ли­ний соединяются сущности, участвующие в данной связи.

Показатель кардинальности связи (характеристика однозначности) обозначает степень взаимосвязи сущностей и описывает количество возможных связей для каждой из сущ­ностей-участниц:

• один-к-одному (1:1);
• один-ко-многим (1:N);
• многие-ко-многим (N:M).

Создание БД начинается с проектирования.

Этапы проектирования БД:

· Исследование предметной области;

· Анализ данных (сущностей и их атрибутов);

· Определение отношений между сущностями и определение первичных и вторичных (внешних) ключей.

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

К базовым понятиями модели БД «сущность – связь» относятся: сущности, связи между ними и их атрибуты (свойства).

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

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

Связь – взаимосвязь между сущностями в предметной области. Связи представляют собой соединения между частями БД (в реляционной БД – это соединение между записями таблиц).

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

Рассмотрим предметную область: Деканат (Успеваемость студентов )
В БД «Деканат» должны храниться данные о студентах, группах студентов, об оценках студентов по различным дисциплинам, о преподавателях, о стипендиях и т.д. Ограничимся данными о студентах, группах студентов и об оценках студентов по различным дисциплинам. Определим сущности, атрибуты сущностей и основные требования к функциям БД с ограниченными данными.

Основными предметно-значимыми сущностями БД «Деканат» являются : Студенты, Группы студентов, Дисциплины, Успеваемость.

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

Основные требования к функциям БД:
-выбрать успеваемость студента по дисциплинам с указанием общего количества часов и вида контроля;
-выбрать успеваемость студентов по группам и дисциплинам;
-выбрать дисциплины, изучаемые группой студентов на определенном курсе или
определенном семестре.

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

Логическая связь между сущностями Группы – Студенты определена как один – ко – многим исходя из того, что в группе имеется много студентов, а каждый студент входит в состав одной группе. Логическая связь между сущностями Дисциплины – Успеваемость определена как один – ко – многим, потому что по каждой дисциплине может быть поставлено несколько оценок различным студентам.

На основе вышеизложенного составляем модель сущность – связь для БД «Деканат»

Стрелка является условным обозначением связи: один – ко – многим.

Для создания БД необходимо применить одну из известных СУБД, например СУБД Access.