Для чего нужны сущности типа справочник
Для чего нужны сущности типа справочник
При проектировании информационных систем с входящими в их состав базами данных удобно пользоваться классификацией моделей изображённой на рис. 1. Все модели данных делятся на три вида, используемые на трёх этапах проектирования. На первом этапе исследуется предметная область, выявляются в ней объекты и процессы, которые нужно будет отобразить в информационной системе при решении задач, для которых разрабатывается информационная система. Модель, используемая на этом этапе, служит для наглядного представления семантических связей в предметной области. Строгая формализация структуры данных на этом этапе не обязательна. Такие модели называются инфологическими. В настоящее время наиболее распространённой инфологической моделью является модель сущность-связь.
| Рис. 1. Модели данных |
После того как закончено исследование предметной области и детально поставлена задача проектирования можно переходить ко второму этапу, на котором проектируется база данных. На этом этапе используются формальные модели данных, в которые нужно преобразовать инфологическую модель. Такие модели, непосредственно используемые в базах данных, называются даталогическими. На рис.1 показаны три вида датологических моделей: иерархические, сетевые и реляционные.
Иерархическая модель имеет древовидную структуру. Каждая ветвь в такой структуре имеет одну родительскую ветвь и много дочерних. Примерами иерархических систем служат завод, система каталогов с файлами в ЭВМ. Завод состоит из цехов, цеха из участков, участки из станков с рабочими.
В иерархической системе элементы одного уровня не связаны непосредственно между собой. В ней нельзя непосредственно указать, что участок механического цеха снабжает деталями участок сборочного цеха. Нужна горизонтальная связь между элементами одного уровня иерархии. Поэтому для завода лучше подходит сетевая модель, в которой можно указать непосредственную связь любого элемента с любым.
Наибольшее распространение получили реляционные модели баз данных, о которых подробно будет рассказано в следующей лекции.
Базу данных независимо от её даталогической модели можно по-разному разместить на разных внешних носителях. Например, можно использовать жёский диск или твёрдотельную внешнюю память. Для описания физического размещения базы даных служит физическая модель.
МОДЕЛЬ СУЩНОСТЬ-СВЯЗЬ
Инфологическое моделирование
Информационая система (ИС) создаётся для решения задач некоторой организации (завода, банка, вуза, библиотеки и т.д.). Для создания и эксплуатации ИС требуется её описание. Полное, исчерпывающее, описание ИС должно включать в себя не только саму ИС, но и окружающую среду, то есть, должно быть описанием предметной области.
Существенной, если не главной частью ИС являются хранящиеся в ней данные. При проектировании ИС данные нужно представить в виде простой модели, отображающей смысл данных, их взаимосвязь и не привязываться при этом к конкретному типу базы данных. Такие модели получили название инфологических.
Инфологическую модель можно построить, опираясь только на интуитивное представление о данных.
На рис. 2 приведён простой (вырожденный) пример инфологической модели.
| Рис. 2. Инфологическая модель преподавателя |
Если нужно более подробно описать дисциплины и иметь возможность, зная дисциплину, найти ведущего её преподавателя, то модель придётся уcложнить, выделив дисциплину отдельно и связав её с преподавателем (рис. 3)
| Рис. 3. Инфологическая модель преподаватель-дисциплина |
Один преподаватель может вести много дисциплин и одну дисциплину могут вести много преподавателей. Такая связь называется многие ко многим и обозначается как M:N, а на рисунках часто как ∞ ←→ ∞.
| Рис. 4. Инфологическая модель для построения расписания занятий |
На рис. 5 изображена инфологическая модель библиотеки
| Рис. 5. Инфологическая модель библиотеки |
В 1976 году Чен предложил термин сущность, а состоящая из связанных между собой сущностей модель получила название модель сущность-связь (entity-relation).
Определение
Сущность состоит из множества экземпляров, обладающих одинаковым набором свойств.
Совокупность свойств, необходимая для отличия одного экземпляра от других, называется идентификатором сущности.
Рассмотрим подробно, какими бывают сами сущности, их свойства и связи. В литературе часто вместо термина свойство сущности используют атрибут сущности. Но термин атрибут отношения (колонка, столбец таблицы) применяют в реляционной модели. При одновременном применении обеих моделей может возникнуть путаница.
Виды сущностей
| Рис. 6. Тип и подтип |
Связи между сущностями
| Рис. 7. Связь между детьми и родителями |
Полной связью между двумя сущностями называется такая связь, при которой каждому экземпляру одной сущности соответствует хотя бы один экземпляр другой сущности. Например, каждому студенту соответствует група (одна) и каждой группе соответствуют студенты.
При частичной связи некоторые экземпляры одной сущности не связаны ни с одним экземпляром другой сущности. Например, не все студенты живут в общежитии.
Связь типа 1:1 между сущностями встречается нечасто. Теоретически всегда такие сущности можно объединить в одну. Связь 1:1 создают для лучшего понимания модели. Напимер, директора и завод лучше рассматривать как разные сущности. Связь 1:1 коварна кажущейся очевидностью, Например, у государства один глава: император, президент, царь и т.д., но в древнем Риме правили два консула.
Связь типа M:N, M>1, N>1(или ∞ ←→ ∞) требует при переходе к реляционной модели строить дополнительное отношение (таблицу связей). Примеры связей типа M:N приведены на рисунках 3, 4, 5.
Рекурсивные связи между равноправными экземплярами сущности. На рис. 9 экземпляры сущности студенты, живущие в общежитии, объединены по признаку (свойству) номер комнаты, в которой они живут.
| Рис. 9. Рекурсивные связи между студентами, живущими в одной комнате |
Рекурсивные связи между неравноправными экземплярами сущности. Так связаны между собой сотрудники и начальник отдела как экземпляры сущности Сотрудники института.
В одной сущности тип и подтип. Несколько экземпляров сущности, связанные одинаковым значением одного свойства, можно выделить в подтип, т.е. в новую сущность, являющуюся подтипом исходной. На рис. 6 в подтип выделены сотрудники, имеющие должность программист.
Примеры рекурсивных связей показывают, что между сущностями, связями и свойствами существуют очень сложные зависимости.
Свойства сущностей:
Простое свойство: фамилия.
Многозначные: награды, специальности.
Ключевое: номер зачётной книжки.
ПРЕОБРАЗОВАНИЕ МОДЕЛИ СУЩНОСТЬ-СВЯЗЬ
В РЕЛЯЦИОННУЮ МОДЕЛЬ
Связь один ко многим
Для задания связи один ко многим в отношеннии со стороны многие создаётся дополнительный атрибут внешний ключ (рис. 10). Внешний ключ принимает значения только из множества значений первичного ключа отношения со стороны один.
| Рис. 10.Преобразование модели сущность-связь со свзью 1:N в реляционную модель |
Связь многие ко многим
Для задания связи многие ко многим необходимо создать дополнительную таблицу связей (рис. 11), атрибутами которой служат внешние ключи, соответствующие первичным ключам связываемых таблиц.
| Рис. 11.Преобразование модели сущность-связь со свзью M:N в реляционную модель |
На рис. 12 показаны заполненные таблицы Prep, Disc и PrepDisс. Для того, чтобы указать, что преподаватель Андреев ведёт дисциплину Фортран, в таблице PrepDisc создана строка со значеиями KodP=1 и kodD=3.
| Рис. 12. Пример заполнения таблицы связей в реляционной модели. |
Связь степени К
Для связи степени К в реляционной модели строится таблица связи с К внешними ключами. На рис. 13 построены модель сущность-связь и реляционная модель для связи степени К=5.
Предметная область базы данных и ее модели
Информационная модель предметной области базы данных
Одним из ключевых моментов создания ИС с целью автоматизации информационных процессов организации является всестороннее изучение объектов автоматизации, их свойств, взаимоотношений между этими объектами и представление полученной информации в виде информационной модели данных.
Информационная модель предметной области базы данных содержит следующие основные конструкции:
Сущности, атрибуты и идентификаторы (ключи) сущности, домены атрибутов
Предметом информационной модели является абстрагирование объектов или явлений реального мира в рамках предметной области, в результате которого выявляются сущности (entity) предметной области. Как правило, они обозначаются именем существительным естественного языка.
Внимание! При представлении сущности в базе данных хранятся только ее атрибуты.
Одним из основных компьютерных способов распознавания сущностей в базе данных является присвоение сущностям идентификаторов (Entity identifier). Часто идентификатор сущности называют ключом. Задача выбора идентификатора сущности является семантически субъективной задачей. Поскольку сущность определяется набором своих атрибутов, то для каждой сущности целесообразно выделить такое подмножество атрибутов, которое однозначно идентифицирует данную сущность.
Различают однозначные и многозначные атрибуты. Однозначными являются атрибуты, которые в пределах конкретного экземпляра сущности имеют только одно значение. В противном случае они считаются многозначными.
На уровне информационного моделирования данных назначение домена атрибуту носит общий характер. Например, атрибут текстовый, числовой, бинарный, дата или «не определен». В последнем случае аналитик должен дать описание домена. На последующих стадиях тип домена конкретизируется, смысл понятия домена в логической и физической моделях базы данных уже, чем его может понимать аналитик. Это связано с тем, что в рамках физической модели базы данных домен реализуется посредством механизма ограничения домена, СУБД не понимает неопределенных доменов.
Отношения, связи
Выявление слабых сущностей и связанных с ними обязательных отношений необходимо для обеспечения целостности и согласованности данных. Так, например, неизвестному клиенту невозможно приписать заказ.
Подтипы и супертипы
Супертип с порожденными им подтипами является примером так называемой составной сущности. Составная сущность является логической конструкцией модели для представления набора сущностей и связей между ними как единого целого.
Пример. Сущность Автомобиль можно разбить на следующие подтипы: автомобили с приводом на два колеса, автомобили с приводом на четыре колеса, автомобили с переключаемым приводом.
Поэтому важно на ранней стадии проектирования установить, является ли наличие супертипов в модели необходимым. Для этого можно предпринять следующие действия:
Сущности и их атрибуты
Дата добавления: 2015-07-04 ; просмотров: 25344 ; Нарушение авторских прав
Сущность – некоторый объект, явление из рассматриваемой предметной
области. Примеры сущностей: человек, автомобиль, сделка, визит к стоматоло-
Атрибуты – данные, описывающие свойства сущности. Примеры атрибу-
тов: фамилия, цвет, стоимость, дата.
В контексте различных предметных областей одно и то же явление может
считаться как сущностью, так и атрибутом.
Следует различать тип сущности и конкретные ее экземпляры.
Тип сущности – признак принадлежности к некоторому классу (множест-
ву) объектов (явлений). Тип сущности характеризуется множеством ее атрибу-
Экземпляр сущности – конкретный объект, принадлежащий определенно-
му классу объектов. Экземпляр сущности определяется значениями ее атрибу-
Фактически, в базе данных хранятся только наборы значений атрибутов.
Каждый такой набор определяет один экземпляр сущности.
Пример 2.1.
Экземпляр сущности «персона»
Обратим внимание, что атрибут «номер телефона» может иметь более од-
Многозначные атрибуты. Может оказаться, что некоторый атрибут сущ-
ности способен принимать одновременно несколько значений. Реляционная
модель, в которую должна быть впоследствии преобразована данная инфологи-
ческая модель, не допускает многозначности атрибутов. Данное противоречие
должно быть разрешено. Возможное решение – образование новой сущности.
В приведенном ранее примере атрибут «номер телефона» становится кан-
дидатом на создание сущности «номер телефона».
Другое решение – заменить название атрибута «номер телефона» на «пе-
речень номеров телефонов» и позволить хранить несколько номеров, пере-
численных через запятую, в виде одной текстовой строки. Кроме того, некото-
рые СУБД позволяют размещать в ячейках таблиц массивы, содержащие не-
сколько элементов. Однако при сохранении многозначного атрибута могут воз-
никнуть сложности с извлечением данных. Например, будет затруднительно
составить запрос следующего вида: «извлечь из БД сведения о персонах,
имеющих заданный номер телефона».
Кроме того, возможное решение зависит от общего контекста разрабаты-
ваемой БД. Если речь идет о контактных номерах телефонов сторонних клиен-
тов, номер, скорее всего, является атрибутом и возможные повторы маловеро-
ятны и несущественны. Если же ставится задача построения телефонного спра-
вочника некоторой организации, в которой, с одной стороны, один сотрудник
может быть доступен по нескольким номерам, а с другой – по одному номеру
может быть доступно несколько сотрудников, номер телефона, очевидно, ста-
новится самостоятельной сущностью.
Домен атрибута – множество значений, которые атрибут может прини-
мать. Доменом может быть, например, множество допустимых значений даты,
диапазон целых чисел или множество текстовых строк. Также это может быть
При реализации модели на языке конкретной СУБД домены приводятся в
соответствие с имеющимися типами данных.
Если в процессе разработки и анализа модели выявляются достаточно спе-
рассматриваться в качестве кандидатов на создание новых сущностей.
Идентификация сущностей. Для того чтобы экземпляры сущности можно
было отличить один от другого, следует описать способ их идентификации.
Роль идентификатора выполняет атрибут или группа атрибутов, совокуп-
ность значений которых уникальна для каждого экземпляра сущности. В реля-
ционной модели такой уникальный идентификатор называют первичным
ключом.
Во многих случаях для идентификации может быть использован специаль-
ный целочисленный атрибут (номер экземпляра сущности).
Связи между сущностями. После определения сущностей следует описать
связи (взаимоотношения) между ними.
Связь устанавливается между экземплярами сущностей, а не их типами.
Например, для сущностей «клиент» и «заказ» связь устанавливается между кон-
кретным клиентом и его заказами. Для связывания экземпляров сущностей ис-
пользуются их уникальные идентификаторы экземпляров сущности (первичные
Один-к-одному
Один-ко-многим
Многие-ко-многим
Вид связи определяется количеством экземпляров сущностей, участвующих
в связи с каждой из сторон.
При связи вида «один-к-одному», экземпляр каждой из сущностей может
быть связан не более чем с одним экземпляром другой сущности.
Возможное применение связи «один-к-одному» – хранить отдельно некото-
рый набор секретных атрибутов, для доступа к которым нужны более высокие
привилегии. Пример – связь между сущностями «клиент» и «кредитная карта».
При обнаружении связи вида «один-к-одному» следует проанализировать
причину ее возникновения. Часто такую связь лучше преобразовать в «один-ко-
многим» или уничтожить, объединив две сущности в одну (новая сущность бу-
дет содержать атрибуты обеих первоначальных сущностей).
Пример связи «один-ко-многим» – связь между клиентом и его заказами.
Клиент может сделать много заказов (или ни одного), но заказ может быть свя-
зан только с одним клиентом. Другой пример: в кошельке может одновременно
находиться много денежных банкнот, но каждая банкнота в определенный мо-
мент времени может находиться не более, чем в одном кошельке.
Между приведенными примерами есть отличие: заказ обязательно должен
быть связан с 1 клиентом (без клиента он не существует), а банкнота может
быть связана с 0 кошельков или с 1 кошельком (она способна существовать без
При связи между сущностями вида «многие-ко-многим» каждому экземп-
ляру первой сущности могут быть поставлены в соответствие несколько экзем-
пляров второй сущности (и наоборот).
Пример – связь между журналами и подписчиками. Подписчик может вы-
писать несколько журналов и каждому наименованию журнала могут соответ-
ствовать много подписчиков.
Реляционная модель баз данных не позволяет реализовать связь «многие-
ко-многим». Эта проблема может быть решена введением дополнительной
ER-диаграммы. Наименование диаграмм происходит от английского «En-
tity-Relationship» («сущность-связь»).
Классическая форма представления сущностей и их атрибутов использует
прямоугольники для обозначения самих сущностей и овалы – для обозначения
их атрибутов. Иногда в диаграммах атрибуты отдельных сущностей опускают,
чтобы более очевидной была структура в целом. Также зачастую удобным ока-
зывается применение компактной формы описания сущностей.
Пример. 2.2. На рис. 2.1 представлена рассмотренная ранее сущность «Пер-
сона» в двух формах – классической и компактной. Символом «*» помечен ат-
рибут, являющийся идентификатором сущности (иногда вместо использования
звездочки, имя такого атрибута подчеркивают).
Введение в проектирование баз данных
Термин «реляционный» означает «основанный на отношениях». Реляционная база данных состоит из сущностей (таблиц), находящихся в некотором отношении друг с другом. Название произошло от английского слова relation—отношение.
Проектирование базы данных состоит из двух основных фаз: логического и физического моделирования.
Во время логического моделирования вы собираете требования и разрабатываете модель базы данных, не зависящую от конкретной СУБД (системы управления реляционными базами данных). Это похоже на то, как если бы вы создавали чертежи вашего дома. Вы могли бы продумать и начертить все: где будет кухня, спальни, гостиная. Но это все на бумаге и в макетах.
Во время физического моделирования вы создаете модель, оптимизированную для конкретного приложения и СУБД. Именно эта модель реализуется на практике. Если вернуться к дому из предыдущего абзаца, на этом этапе вам придется строить где-нибудь дом — таскать бревна, кирпичи…
Процесс проектирования базы данных состоит из следующих этапов:
Первые 5 этапов образуют фазу логического проектирования, а остальные два — фазу физического моделирования.
Логическая фаза
Логическая фаза состоит из нескольких этапов. Далее они все рассмотрены.
Сбор требований
На этом этапе вам необходимо точно определить, как будет использоваться база данных и какая информация будет в ней храниться. Соберите как можно больше сведений о том, что система должна делать и чего не должна.
Определение сущностей
На этом этапе вам необходимо определить сущности, из которых будет состоять база данных.
Сущность — это объект в базе данных, в котором хранятся данные. Сущность может представлять собой нечто вещественное (дом, человек, предмет, место) или абстрактное (банковская операция, отдел компании, маршрут автобуса). В физической модели сущность называется таблицей.
Сущности состоят из атрибутов (столбцов таблицы) и записей (строк в таблице).
Обычно базы данных состоят из нескольких основных сущностей, связанных с большим количеством подчиненных сущностей. Основные сущности называются независимыми: они не зависят ни от какой-либо другой сущности. Подчиненные сущности называются зависимыми: для того чтобы существовала одна из них, должна существовать связанная с ней основная таблица.
На диаграммах сущности обычно представляются в виде прямоугольников. Имя сущности указывается внутри прямоугольника: 
Любая таблица имеет следующие характеристики:
На этом этапе вам необходимо выявить все категории информации (сущности), которые будут храниться в базе данных.
Определение атрибутов
Атрибут представляет свойство, описывающее сущность. Атрибуты часто бывают числом, датой или текстом. Все данные, хранящиеся в атрибуте, должны иметь одинаковый тип и обладать одинаковыми свойствами.
В физической модели атрибуты называют колонками.
После определения сущностей необходимо определить все атрибуты этих сущностей.
На диаграммах атрибуты обычно перечисляются внутри прямоугольника сущности. На рисунке вы найдете пример базы данных «Дома», только теперь для сущностей из этой базы определены некоторые атрибуты. 
Для каждого атрибута определяется тип данных, их размер, допустимые значения и любые другие правила. К их числу относятся правила обязательности заполнения, изменяемости и уникальности.
Правило обязательности заполнения определяет, является ли атрибут обязательной частью сущности. Если атрибут является необязательной частью сущности, то он может принимать NULL-значение, иначе — нет.
Также вы должны определить, является ли атрибут изменяемым. Значения некоторых атрибутов не могут измениться после создания записи.
И, наконец, вам нужно определить, является ли атрибут уникальным. Если это так, то значения атрибута не могут повторяться.
Ключи
Ключом (key) называется набор атрибутов, однозначно определяющий запись. Ключи делятся на два класса: простые и составные.
Простой ключ состоит только из одного атрибута. Например, в базе «Паспорта граждан страны» номер паспорта будет простым ключом: ведь не бывает двух паспортов с одинаковым номером.
Составной ключ состоит из нескольких атрибутов. В той же базе «Паспорта граждан страны» может быть составной ключ со следующими атрибутами:
фамилия, имя, отчество, дата рождения. Это — как пример, т. к. этот составной ключ, теоретически, не обеспечивает гарантированной уникальности записи.
Также существует несколько типов ключей, о которых рассказано далее.
Возможный ключ
Возможный ключ представляет собой любой набор атрибутов, однозначно идентифицирующих запись в таблице. Возможный ключ может быть простым или составным.
Каждая сущность должна иметь, по крайней мере, один возможный ключ, хотя таких ключей может быть и несколько. Ни один из атрибутов первичного ключа не может принимать неопределенное (NULL) значение.
Возможный ключ называется также суррогатным.
Первичные ключи
Первичным ключом называется совокупность атрибутов, однозначно идентифицирующих запись в таблице (сущности). Один из возможных ключей становится первичным ключом. На диаграммах первичные ключи часто изображаются выше основного списка атрибутов или выделяются специальными символами. Сущность на рисунке имеет как ключевые, так и обычные атрибуты. 
Альтернативные ключи
Любой возможный ключ, не являющийся первичным, называется альтернативным ключом. Сущность может иметь несколько альтернативных ключей.
Внешние ключи
Внешним ключом называется совокупность атрибутов, ссылающихся на первичный или альтернативный ключ другой сущности. Если внешний ключ не связан с первичной сущностью, то он может содержать только неопределенные значения. Если при этом ключ является составным, то все атрибуты внешнего ключа должны быть неопределенными.
На диаграммах атрибуты, объединяемые во внешние ключи, обозначаются специальными символами. На рисунке изображены две связанные сущности (Дома и их Хозяева) и образованные ими внешние ключи (ведь один человек может владеть больше, чем одним домом). 
Ключи являются логическими конструкциями, а не физическими объектами. В реляционных базах данных предусмотрены механизмы, обеспечивающие сохранение ключей.
Определение связей между сущностями
Реляционные базы данных позволяют объединять информацию, принадлежащую разным сущностям.
Отношение — это ситуация, при которой одна сущность ссылается на первичный ключ второй сущности. Как, например, сущности Дом и Хозяин на предыдущем рисунке.
Отношения определяются в процессе проектирования базы. Для этого следует проанализировать сущности и выявить логические связи, существующие между ними.
Тип отношения определяет количество записей сущности, связанных с записью другой сущности. Отношения делятся на три основных типа, о которых рассказано далее.
Один-к-одному
Каждой записи первой сущности соответствует только одна запись из второй сущности. А каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Люди и Свидетельства о рождении. И у одного человека может быть только одно свидетельство о рождении.
Один-ко-многим
Каждой записи первой сущности могут соответствовать несколько записей из второй сущности. Однако каждой записи второй сущности соответствует только одна запись из первой сущности. Например, есть две сущности: Заказ и Позиция заказа. И в одном заказе может быть много товаров.
Многие-ко-многим
Каждой записи первой сущности могут соответствовать несколько записей из второй сущности. Однако и каждой записи второй сущности может соответствовать несколько записей из первой сущности. Например, есть две сущности: Автор и Книга. Один автор может написать много книг. Но у книги может быть несколько авторов.
По критерию обязательности отношения делятся на обязательные и необязательные.
Нормализация
Нормализацией называется процесс удаления избыточных данных из базы данных. Каждый элемент данных должен храниться в базе в одном и только в одном экземпляре. Существует пять распространенных форм нормализации. Как правило, база данных приводится к третьей нормальной форме.
В процессе нормализации выполняются определенные действия по удалению избыточных данных. Нормализация повышает быстродействие, ускоряет сортировку и построение индекса, уменьшает количество индексов на сущность, ускоряет операции вставки и обновления.
Нормализованная база данных обычно отличается большей гибкостью. При модификации запросов или сохраняемых данных в нормализованную базу обычно приходится вносить меньше изменений, а внесение изменений имеет меньше последствий.
Первая нормальная форма
Чтобы преобразовать сущность в первую нормальную форму, следует исключить повторяющиеся группы значений и добиться того, чтобы каждый атрибут содержал только одно значение, списки значений не допускаются.
Другими словами, каждый атрибут в сущности должен храниться только в одном экземпляре.
Например, на рисунке сущность Дом не нормализована. Она содержит несколько атрибутов для хранения данных о владельцах дома (сущность Дом не соответствует первой нормальной форме). 
Для приведения сущности Дом в первую нормальную форму необходимо удалить повторяющиеся группы значений, т. е. удалить атрибуты Владелец 1—3, поместив их в отдельную сущность. Результат (Сущность Дом, приведенная к первой нормальной форме): 
Вторая нормальная форма
Таблица во второй нормальной форме содержит только те данные, которые к ней относятся. Значения не ключевых атрибутов сущности зависят от первичного ключа. Если более точно, то атрибуты зависят от первичного ключа, от всего первичного ключа и только от первичного ключа.
Для соответствия второй нормальной форме сущности должны быть в первой нормальной форме.
Например, у сущности Дом на рисунке есть атрибут Цена литра бензина, который не имеет ничего общего с домами. Этот атрибут удаляется (или вы можете перенести его в другую сущность). А также мы переносим атрибут Мэр в отдельную сущность — этот атрибут зависит от города, где находится дом, а не от дома.
На рисунке изображена сущность Дом во второй нормальной форме (Сущность Дом, приведенная ко второй нормальной форме). 
Третья нормальная форма
В третьей нормальной форме исключаются атрибуты, не зависящие от всего ключа. Любая сущность, находящаяся в третьей нормальной форме, находится также и во второй. Это самая распространенная форма базы данных.
В третьей нормальной форме каждый атрибут зависит от ключа, от всего ключа и ни от чего, кроме ключа.
Например, у сущности Владелец дома на рисунке есть атрибут Знак зодиака, который зависит от даты рождения владельца дома, а не от его имени (которое является ключом).
Для приведения сущности Владелец дома необходимо создать сущность Знаки зодиака и перенести туда атрибут Знак зодиака (Сущность Владелец дома, приведенная к третьей нормальной форме): 
Ограничения
Ограничения (constrains) — это правила, за соблюдением которых следит система управления базы данных. Ограничения определяют множество значений, которые можно вводить в столбец или столбцы.
Например, вы не хотите, чтобы сумма заказа в вашем очень крутом магазине была бы меньше 500 рублей. Вы просто устанавливаете ограничение на колонку Сумма заказа.
Хранимые процедуры
Хранимые процедуры (stored procedures) — это предварительно откомпилированные процедуры, хранящиеся в базе данных. Хранимые процедуры можно использовать для определения деловых правил, с их помощью можно осуществлять более сложные вычисления, чем с помощью одних лишь ограничений.
Хранимые процедуры могут содержать логику хода выполнения программы, а также запросы к базе данных. Они могут принимать параметры и возвращать результаты в виде таблиц или одиночных значений.
Хранимые процедуры похожи на обычные процедуры или функции в любой программе.
ПРИМЕЧАНИЕ
Хранимые процедуры находятся в базе данных и выполняются на сервере базы данных. Как правило, они быстрее операторов SQL, поскольку хранятся в компилированном виде.
Целостность данных
Организовав данные в таблицы и определив связи между ними, можно считать, что была создана модель, правильным образом отражающая бизнес-среду. Теперь нужно обеспечить, чтобы данные, вводимые в базу, давали правильное представление о состоянии дела. Иными словами, нужно обеспечить выполнение деловых правил и поддержку целостности (integrity) базы данных.
Например, ваша компания занимается доставкой книг. Вы вряд ли примете заказ от неизвестного клиента, ведь тогда вы даже не сможете доставить заказ. Отсюда бизнес-правило: заказы принимаются только от клиентов, информация о которых есть в базе данных.
Корректность данных в реляционных базах обеспечивается набором правил. Правила целостности данных делятся на четыре категории.
Триггеры
Триггер — это аналог хранимой процедуры, который вызывается автоматически при изменении данных в таблице.
Триггеры являются мощным механизмом для поддержания целостности базы данных. Триггеры вызываются до или после изменения данных в таблице.
С помощью триггеров вы можете не только отменить эти изменения, но и изменить данные в любой другой таблице.
Например, вы создаете интернет-форум, и вам необходимо сделать так, чтобы в списке форумов показывалось последнее сообщение форума. Конечно, вы можете брать сообщение из сущности Сообщения форума, но это увеличит сложность вашего запроса и время его выполнения. Проще добавить триггер к сущности Сообщения форума, который бы записывал последнее добавленное сообщение в сущность Форумы, в атрибут Последнее сообщение. Это сильно упростит запрос.
Деловые правила
Деловые правила определяют ограничения, накладываемые на данные в соответствии с требованиями бизнеса (тех, для кого вы создаете базу). Деловые правила могут состоять из набора шагов, необходимых для выполнения определенной задачи, или же они могут быть просто проверками, которые контролируют правильность введенных данных. Деловые правила могут включать правила целостности данных. В отличие от других правил, их главная цель — обеспечить правильное ведение деловых операций.
Например, в компании «Очень крутые парни» может быть так принято, что закупаются для служебных нужд только белые, синие и черные автомобили.
Тогда деловое правило для атрибута Цвет автомобиля сущности Служебные автомобили будет гласить, что автомобиль может быть только белым, синим или черным.
Большинство СУБД предоставляют средства:
Все эти возможности можно применять для реализации деловых правил в базе данных.
Физическая модель
Следующим шагом, после создания логической модели, является построение физической модели. Физическая модель — это практическая реализация базы данных. Физическая модель определяет все объекты, которые вам предстоит реализовать.
При переходе от логической модели к физической сущности преобразуются в таблицы, а атрибуты в столбцы.
Отношения между сущностями можно преобразовать в таблицы или оставить как внешние ключи.
Первичные ключи преобразуются в ограничения первичных ключей. Возможные ключи — в ограничения уникальности.
Денормализация
Денормализация — это умышленное изменение структуры базы, нарушающее правила нормальных форм. Обычно это делается с целью улучшения производительности базы данных.
Теоретически, надо всегда стремиться к полностью нормализованной базе, однако на практике полная нормализация базы почти всегда означает падение производительности. Чрезмерная нормализация базы данных может привести к тому, что при каждом извлечении данных придется обращаться к нескольким таблицам. Обычно в запросе должны участвовать четыре таблицы или менее.
Стандартными приемами денормализации являются: объединение нескольких таблиц в одну, сохранение одинаковых атрибутов в нескольких таблицах, а также хранение в таблице сводных или вычисляемых данных.