К статьям Разработка → Отношения таблиц базы данных и Разработка → Проектирование баз данных хабравчанина ueasley хотелось бы сделать небольшое дополнение.

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

Правила эти применяются к ER-модели, то есть модели «сущность-связь».

ER-модель

ER -модель представляет собой схему, составными элементами которой являются:

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

Приведу пример:
Пусть необходимо хранить информацию о клиентах и их заказах. Построим диаграмму

Заметим, что со стороны сущности «ЗАКАЗ» связь обозначена дополнительным прямоугольником - это обозначение того, что каждому экземпляру сущности «ЗАКАЗ» соответствует экземпляр сущности «КЛИЕНТ» (для клиента же наличие заказа не обязательно). Степень «M» означает, что для каждого экземпляра сущности «КЛИЕНТ» могут существовать несколько экземпляров сущности «ЗАКАЗ» (но не наоборот, поскольку для каждого заказа всегда только один заказчик - ставим степень «1»)

Отношение (обычно оно соответствует таблице в базе данных) не следует путать с сущностью. Сущность переходит в отношение путем выделения её из ER-диаграммы.

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

1. Концептуальное проектирование

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

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

   У меня получилась следующая диаграмма.

   
   Рис. 2

2. Логическое проектирование

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

   Переход к реляционной структуре (построение набора отношений) производится по следующим правилам:

   1. Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей обязательный, то требуется только одно отношение. Первичным ключом этого отношения может быть ключ любой из этих двух сущностей. В этом случае гарантируется однократное появление каждого значения ключа в любом экземпляре отношения.
   2. Если степень бинарной связи равна 1:1 и класс одной из сущностей необязательный, то необходимо построение двух отношений, под каждую сущность необходимо выделение одного отношения. Ключ сущности, для которого класс принадлежности является необязательным, добавляется в качестве атрибута в отношение, выделенное для сущности с обязательным классом принадлежности.
   3. Если степень бинарной связи равна 1:1 и класс принадлежности ни одной из сущностей не является необязательным, то используется три отношения - по одному для каждой сущности - ключи которых служат в качестве первичных в соответствующих отношениях и одного для связи. Отношение, выделенное для связи, будет иметь по одному ключу сущности от каждой сущности.
   4. Если степень бинарной связи равна 1: М и класс принадлежности М-связной сущности обязательный, то достаточно использовать два отношения: по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Ключ же односвязной сущности должен быть добавлен как атрибут в отношение, отводимое М-связной сущности.
   5. Если степень бинарной связи равна 1: М и класс принадлежности М-связной сущности необязателен, то необходимо использовать три отношения: по одному на сущность и одно для связи. Связь должна иметь среди своих атрибутов ключ сущности от каждой сущности.
   6. Если степень бинарной связи равна М: М, то для хранения данных необходимо три отношения: по одному на сущность и одно для связи. Ключи сущности входят в связь. Если одна из сущностей вырождена, то - два отношения (т.е. достаточно будет двух таблиц).
   7. В случае трехсторонней связи необходимо использовать четыре отношения: по одному на сущность и одно для связи. Отношение, порождаемое связью, имеет в себе среди атрибутов ключи сущности от каждой сущности.

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

   Сущности	Номер правила	Отношения
   Клиент Заказ	4	Клиент(#Клиента Заказ(#Заказа, #Клиента
   Сотрудник Заказ	4	Сотрудник(#Сотрудника Заказ(#Заказа, #Сотрудника
   Заказ Элемент заказа	4	Заказ(#Заказа Элемент заказа(#Элемента заказа, #Заказа
   Бригада Элемент заказа	4	Бригада(#Бригады Элемент заказа(#Элемента, #Бригады
   Изделие Элемент заказа	4	Изделие(#Изделия Элемент заказа(#Элемента, #Изделия
   Клиент Заказ	6	Клиент(#Клиента Заказ(#Заказа Платеж(#Платежа, #Клиента, #Заказа
   Бригада Сотрудник	5	Бригада(#Бригады Сотрудник(#Сотрудника Сотрудник бригады(#Сотрудника бригады, #Сотрудника, #Бригады
   Элемент заказа Операция	5	Элемент заказа(#Элемента Операция(#Операции Запись операции(#Записи, #Элемента, #Операции
   Элемент заказа Материал	5	Элемент заказа(#Элемента Материал(#Материала Расход(#Записи, #Элемента, #Материала

   Табл. 1

   Распределив атрибуты по полученным отношениям, получим (в списке полей на первом месте - первичный ключ, остальные, помеченные «#», являются внешними ключами):

   БРИГАДА	(#Бригады, #Бригадира, Расположение)
   ДОЛЖНОСТЬ	(#Должности, Должность, Оклад)
   ЗАКАЗ	(#Заказа, #Клиента, #Сотрудника, ДатаРазмещения, ТребуемаяДата, ДатаИсполнения, Описание)
   КЛИЕНТ	(#Клиента, Название, Имя, Фамилия, ОрганизацияИлиОтдел, Адрес, НомерТелефона, АдресЭлектроннойПочты)
   ЗАПИСЬОПЕРАЦИИ	(#Записи, #Элемента,#Операции, #Сотрудника, Количество)
   ОПЛАТА	(#Оплаты, #Клиента, #Заказа, СуммаОплаты, ДатаОплаты, Заметки)
   РАСХОД	(#Записи, #РасхМат, #Елемента, Количество)
   СОСТАВ	(#Элемента, #Заказа, #Товара, #Бригады, Количество)
   СОТРБРИГАДЫ	(#СотрБригады, #Бригады,#Сотрудника)
   СОТРУДНИК	(#Сотрудника, НомерПаспорта, Фамилия, Имя, Отчество, #Должности, Адрес, ДомашнийТелефон, РабочийТелефон, ДатаРождения, ДатаНайма, ДатаОкончДоговора, Фотография, Заметки)
   ОПЕРАЦИЯ	(#Операции, Описание, Стоимость, Время, Оборудование, Выполнение)
   МАТЕРИАЛ	(#РасхМат, НаимРасхМат, Цена, Плотность, Тип, Состав)
   ТОВАР	(#Товара, Марка, Название, ОписаниеТовара, Тип, СерийныйНомер, НаСкладе, Цена)

   Табл. 2

Вот так нас учили делать в университете. Может будет кому-нибудь интересно. Насчет «нужно ли это», слушаю ваши мнения!

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

Но если требуется одновременно использовать термины ER-модели и реляционной модели данных, то, безусловно, требуется применять для терминов relation и relationship разные русские эквиваленты. За этими терминами стоят весьма различные понятия. В реляционной модели отношение ( relation ) – это единственная родовая структура данных . С помощью этого же механизма представляются "связанные" сущности (вспомните, например, про внешние ключи). Как мы увидим немного позже, в ER-модели для представления схемы базы данных используются два равноправных понятия – сущность и связь . Связи в ER-модели играют роль, отличную от той, какую играют отношения в реляционной модели данных.

Кроме того, в русскоязычную терминологию вошла и чистая транслитерация термина relation именно в смысле отношение . Мы говорим, например, про реляционную модель данных , реляционную алгебру и т. д., понимая модель данных , основанную на отношениях, алгебру отношений и т. п. По этому поводу, по крайней мере, в контексте баз данных, разумно окончательно зарезервировать термины relation и отношение для обозначения понятий реляционной модели данных, а для термина relationship использовать другой допустимый русскоязычный эквивалент – связь .

На использовании разных вариантов ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Питером Ченом (Peter Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. Простота и наглядность представления концептуальных схем баз данных в ER-модели привели к ее широкому распространению в CASE-системах , поддерживающих автоматизированное проектирование реляционных баз данных . Среди множества разновидностей ER-моделей одна из наиболее популярных и развитых применялась в системе CASE компании Oracle . Мы обсудим некоторый упрощенный вариант этой модели. Если говорить более точно, сосредоточимся на ее структурной и целостной частях.

Основные понятия ER-модели

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

Рис. 9.1.

На рис. 9.1 изображена сущность АЭРОПОРТ с примерными экземплярами "Шереметьево" и "Хитроу". Эта примитивная диаграмма тем не менее несет важную информацию. Во-первых, она показывает, что в базе данных будут содержаться однотипные структуры данных (экземпляры сущности ), описывающие аэропорты. Во-вторых, поскольку в жизни существует несколько точек зрения на аэропорты (например, точка зрения пилота, точка зрения пассажира, точка зрения администратора) и этим точкам зрения соответствуют разные структуры данных, то приведенные примеры аэропортов позволяют несколько сузить допустимый набор точек зрения. В нашем случае приведены примеры международных аэропортов, так что, скорее всего, имеется точка зрения пассажира или пилота международных авиарейсов.

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

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

Связь представляется в виде ненаправленной линии, соединяющей две сущности или ведущей от сущности к ней же самой. При этом в месте "стыковки" связи с сущностью используются:

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

Обязательный конец связи изображается сплошной линией, а необязательный – прерывистой линией.

Связь между сущностями БИЛЕТ и ПАССАЖИР , показанная на рис. 9.2 , связывает билеты и пассажиров. Конец связи с именем "для" позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец связи с именем "имеет" показывает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

Рис. 9.2.

• каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА ;
• каждый ПАССАЖИР может иметь один или более БИЛЕТОВ или не иметь вовсе.

На следующем примере (рис. 9.3) изображена рекурсивная связь , связывающая сущность МУЖЧИНА с ней же самой. Конец связи с именем " сын " определяет тот факт, что несколько людей могут быть сыновьями одного отца. Конец связи с именем " отец " означает, что не у каждого мужчины должны быть сыновья.

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

• каждый МУЖЧИНА является сыном одного и только одного МУЖЧИНЫ ;
• каждый МУЖЧИНА может являться отцом одного или более МУЖЧИН .

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

Логическая модель (Сущностная) данных является независимым логическим представлением данных.

Физическая модель (Табличная) данных содержит определения всех реализуемых объектов в конкретной базе данных для конкретной СУБД.

Модели являются краеугольным камнем проектирования. Инженеры должны построить модель автомобиля, проработать все детали, прежде чем запустить его в производство. Таким же образом, системные инженеры сперва разрабатывают модели для изучения бизнес-логики и углубления понимания структуры базы данных.

В прошлой лекции мы познакомились с методологиями IDEF0 и DFD которые позволяют описать бизнес-процессы протекающие в информационной системе. В модели DFD мы рассмотрели элемент - хранилище данных, который показывает типы информации, которой оперирует система. Однако эта методология не предназначена для описания структуры хранимой информации. Для этого больше подходят различные Entity Relationship - диаграммы (сущностные диаграммы), целью которых является описание структуры хранимых данных и взаимосвязей между ними. Разработаны методики, которые позволяют преобразовать такие данные в набор команд, который создаст необходимые хранилища (таблицы) внутри базы данных информационной системы.

ER-моделирование

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

Основные преимущества ER-моделей:

• Точный и понятный формат документирования структуры информации.
• Позволяет указать требования к данным и связям между ними.
• Позволяет наглядно показать структуру хранилища для облегчения проектирования базы данных.
• Существуют методы отображения ER-моделей в таблицы БД и обратно.
• Закладывают основу для интеграции с другими приложениями.

Основные типы объектов на ER-диаграмме:

• Сущность (Entity) - тип объектов, информация о которых будет хранится в БД. Например: отделы, сотрудники, товары, накладные.
• Атрибут (Attribute) - элементы из которых состоят сущности. Например, для сущности «товары» атрибутами могут быть «название», «описание», «количество», «цена» и другие, в зависимости от потребностей информационной системы. В зависимости от нотации ER-диаграммы рядом с атрибутом, кроме его имени указывают тип и обязательность заполнения. На слайде представлена ER-диаграмма в нотации «Information Engineering», согласно которой для атрибута указывается имя, тип, и является он внешним и/или первичным кличем.
• Связь (Relationship) показывают связи между сущностями. Например сотрудник работает в отделе, где «отдел» и «отдел» - сущности.

Сущность - набор объектов реального мира, каждый из которых имеет следующие характеристики:

• Уникален (может быть отделен от всех прочих каким-либо образом)
• Играет определенную роль в моделируемой системе
• Может быть описан одним или более элементом информации (Атрибутом)

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

Атрибут описывает некоторые свойства сущности. Сущность может иметь много атрибутов, но выбираются только те, которые важны для системы. Атрибуты делятся на ключевые (Entity Keys) и описательные (Entity Descriptors). Ключевые атрибуты должны уникальным образом идентифицировать экземпляры сущности. Для каждого атрибута должен быть указан домен (тип, предметная область).

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

Давайте подробнее разберёмся, что такое ключевые атрибуты. Это важно для понимания типов связей между сущностями.

Базовые термины

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

• " Тип данных " (type, domean - домен) - множество допустимых величин ("область определения") и операций. Для всех типов существуют операции сравнения и присвоения. Величинам не запрещено иметь структуру, например, объекта.
• " Отношение " (relation) - множество атрибутов: уникальных имен с уточнением типа данных; плюс множество "наборов величин" ("рядов"), соответствующих атрибутам. Величины в наборах могут быть представлены только единичными значениями соответствующих атрибутам типов, то есть быть скалярами ("1-я нормальная форма").
• " Ключ " (key) - группа атрибутов, значения которых во всех наборах в отношении различны, но ни одна подгруппа этих атрибутов таким свойством уже не обладает (свойство "минимальности" ключа). В частности, группа может состоять из единственного атрибута. Ключ в отношении обязан иметься всегда, а если их несколько, один из них обязан быть назначен "первичным" (primary).
• " Внешний ключ " (foreign key) - группа атрибутов, значения которых в каждом наборе величин отношения обязаны совпадать со значениями ключа возможно другого отношения. Внешние ключи в отношении не обязательны и провозглашаются по потребностям моделирования.
• " Операции " (operation) - множество общих действий над отношениями, дающих в результате опять-таки отношения ("замкнутость операций"). Используются для получения новых отношений в нуждах последующего моделирования или при извлечении из базы нужных данных. Перечень операций можно определять по-разному; в первых предложениях модели приводилось восемь операций (проекции, соединения, отбора и пр.), уже не минимальный набор, как компромисс между отсутствием избыточности и удобством употребления.
• " Реляционная база данных " (relational database) - набор отношений.

"Тип данных" иногда называют "доменом" (domain), но иногда под "доменом" разумеют только "область определения" величин. "Набор величин" (tuple) по-русски иначе называют "кортежем" или "n-кой".

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

Если отказаться от определительного слова-кальки "реляционный", то термин "реляционная БД" можно перевести как "БД отношений" (точнее, "БД построенная посредством отношений"; отношений как инструмента, а не объекта моделирования: иначе исходный термин был бы relation database). Точно так же термин "реляционная модель" можно перевести как "модель отношений", то есть "система понятий для построения модели предметной области в виде набора отношений". По ряду причин, в том числе исторического и языкового характеров, этого не было в свое время сделано.

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

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

Для терминов, перечисленных на предыдущем слайде есть неформальные эквиваленты, для того чтобы проще было понять и запомнить их смысл:

• Отношение → Таблица
• Кортеж → Строка, запись
• Кардинальность → Количество строк
• Атрибут → Столбец, поле
• Степень → Количество столбцов
• Первичный ключ → Идентификатор
• Домен → Область допустимых значений

Ключевые поля

Часть из атрибутов отношения является ключевыми или ключами. Выделяют несколько типов ключей:

• Простой ключ - состоит из одного атрибута, составной - из нескольких.
• Потенциальный ключ - атрибут или набор атрибутов, которые могут идентифицировать каждый из кортежей отношения. Например в отношении паспортный стол («Номер паспорта») и («ФИО» и «Дата рождения») - потенциальные ключи, которые позволяют уникальным образом идентифицировать каждого человека.
• В каждом отношении может быть только один первичный ключ - атрибут или набор атрибутов значения которого уникальным образом идентифицирую каждую запись. Если такими свойствами обладают несколько наборов атрибутов, то один из них выбирается первичным, а все остальные - альтернативными.
• Внешний ключ - хранит значение первичного ключа другого отношения. Внешние ключи используются для связи между отношениями.

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

• Каждое реляционное отношение имеет только 1 первичный ключ , все остальные - альтернативные.
• Значение всех атрибутов первичного ключа не может быть не определено. Например, отношение хранит информацию о жителях города. Первичный ключ - составной (ИМЯ, ФАМИЛИЯ, дата рождения). Информационную систему установили в Исландии, где не используют фамилий, значит атрибут «фамилия» для большинства кортежей будет незаполненным. Несмотря на это составной первичный ключ будет продолжат уникальным образом идентифицировать каждый из кортежей. Однако недопустимо, чтобы значения одновременно всех атрибутов первичного ключа были пустыми.
• Значение первичного ключа не влияет на расположение кортежей в табличном представлении отношения. Даже если значение первичного ключа - число (например 1,2,3 …) в общем случае это не гарантирует, что кортежи внутри БД хранятся в том же порядке и будут выводится в таком же порядке. В «общем случае» означает, что иногда из-за специфики конкретной СУБД строки могут хранится упорядочено по первичному ключу, но это скорее исключение. В случае вывода результатов запроса мы должны явно указывать порядок, в котором нужно выводить строки, если такой порядок важен. Результаты запроса «дай мне первых 5 человек» непредсказуем, если мы не укажем, по какому критерию они должны быть «первыми».
• Первичный ключ не влияет на доступ к атрибутам кортежа. Например в отношении «паспортный стол» вместе с ФИО и датой рождения хранится адрес регистрации человека. Мы можем попросить БД извлечь все адреса, не зная ФИО и дату рождения.

Внешний ключ

Внешний ключ используется для установления связей между отношениями. Например возьмем два отношения «Владельцы» (первичный ключ «номер паспорта») и «Недвижимость». Чтобы установить, кто владеет каждым из объектов недвижимости мы свяжем эти отношения по значению атрибута «номер паспорта». В отличии от первичного ключа значение внешнего ключа может быть неопределённо (строка 4 на слайде) - если мы не знаем владельца недвижимости мы его не указываем. В отличие от первичного ключа значение внешнего ключа может повторятся (стоки 1,3 на слайде) - у одного владельца может быть несколько объектов недвижимости. Однако то что атрибут «номер паспорта» в отношении «Недвижимость» является внешним ключом на первичный ключ отношения «Владелец» гарантирует что значением атрибута «номер пастора» могут быть только значения из первичного ключа. Мы не можем указать в качестве значения атрибута номер пастората человека, которого еще нет в отношении «Владелец» (строка 5).

Устанавливая внешний ключ можно явно задать поведение СУБД, если изменить значение первичного ключа или удалить кортеж. Однако при этом сохраняется правило «во внешнем ключе хранятся только значения, которые есть в первичном ключе или неопределённое значение (NULL)».

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

ЕR-модели: связи

На ER-моделях внешние ключи отображаются в виде связей.

Каждая связь характеризуется 4 свойствами - силой , мощностью , степенью и участием сущности в связи.

Разберем эти характеристики.

Участие сущности в связи

Обозначается на связи поперечной линией или кружком.

Поперечная линия означает обязательное (mandatory ) участие сущности в связи, а кружок - необязательное (optional ).

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

В отделе может работать несколько сотрудников. Сотрудник должен работать в каком-то из отделов.

Степень связи (relationship degree ) указывает на число ассоциированных сущностей . Бинарная связь (binary relationship ) описывает ассоциации двух сущностей. Тернарная связь (ternary relationship ) имеет место, когда связываются три сущности. Унарная связь (unary relationship ) описывает ассоциации внутри единственной сущности.

Наиболее распространены бинарные связи - они связываю две разные сущности («Отдел»- «Сотрудник», «Заказ»- «Товары», «Курс»- «Лекции», «Группа»- «Студенты»). Менее распространенными, но все-таки часто используемыми являются унарные связи. С их помощью обычно задают отношение вложенности на однотипных объектах (отношение «Детали» - можем указать составной частью какой детали является данная, отношение «Сотрудники» - можем указать, кто из сотрудников является начальником для данного).

Мощность связи показывает, какое число экземпляров одной сущности связано с экземплярами другой сущности.

Мощность может быть:

• один-к-одному (1:1) - в группе студентов один староста;
• один-ко-многим (1:N) - в одном отделе работает много сотрудников;
• многие-ко-многим (M:N) - один покупатель купил много товаров, товаров покупали много покупателей.

Сила связи : сильная связь (Identifying Relationship)

Дочерняя сущность не может существовать без родительской. (Не бывает ответа без вопроса; не бывает товара в корзине пользователя, если не существует самой корзины)

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

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

Сила связи: Слабая связь (Nonidentifying Relationship)

Родительская и дочерняя сущности связаны, но дочерняя сущность может быть создана раньше. (Груз принадлежит заказу, но груз может быть на складе, до того как создан заказ).

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

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

Рекурсивная-связь (унарная связь)

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

Поставщик МОЖЕТ работать с НУЛЕМ или БОЛЕЕ заказчиков (id_Customer).

Заказчик ДОЛЖЕН работать с одним поставщиком (id_Sup).

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

Связь многие-ко-многим.

Пример: поставщики могут поставлять много типов товаров. Разные поставщики могут поставлять одинаковые типы товаров.

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

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

ER-модели и реальность

При ближайшем рассмотрении связи типа "один к одному" почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты.

Представим, что А - поставщик, B - товар.

Mandatory-mandatory. Для примера, который приведен на слайде эта связь означает, что каждый поставщик (Supplier) должен поставлять только один уникальный набор товаров (Invoice). С точки зрения теории тут все хорошо. На практике это не допустимо: ни кто не будет искать нового поставщика, если проверенный вами поставщик может предоставить несколько номенклатур товара. А теперь об эмоциях, кот будет испытывать оператор при попытке ввода данных о новом поставщике. Он не сможет ввести данные ни в одну из таблиц. Так что весь багаж неприличной лексики будет направлен в ваш адрес.

Optional-mandatory. Пример связи приведен на слайде. Как видим у оператора теперь все хорошо: данные вводить он может. У бизнеса опять проблема: он должен искать нового поставщика, даже если проверенный вами поставщик может предоставить несколько номенклатур товара. А бизнесу нужны проблемы? Нет. Он должен функционировать. Как удовлетворить бизнес? Ответ простой. При проектировании БД нужно думать о нормализации. Если Supplier - сущность, то используйте связи типа optional-mandatory (mandatory-optional) или optional-optional. Хотя чаще всего связи один-к-одному - это ошибка.

Optional-optional. Как видим у оператора опять все хорошо, а у бизнеса опять проблема. Подведем итоги для связи один-к-одному. Если сущности участвуют в связи как: - mandatory-mandatory, то такая связь не имеет права на жизнь; - optional-mandatory (mandatory-optional) или optional-optional, то сопровождение бизнеса проблематично.

Связь один-ко-многим mandatory-mandatory - достаточно сильная конструкция, предполагающая, что вхождение сущности B не может быть создано без одновременного создания по меньшей мере одного связанного с ним вхождения сущности A. Чаще всего это неверная связь.

Связь один-ко-многим mandatory-optional - это наиболее часто встречающаяся форма связи. Она предполагает, что каждое и любое вхождение сущности A может существовать только в контексте одного (и только одного) вхождения сущности B. В свою очередь, вхождения B могут существовать как в связи с вхождениями A, так и без нее.

Связь один-ко-многим optional-optional - Как A, так и B могут существовать без связи между ними.

В терминах предыдущего слайда эти диаграммы можно проиллюстрировать на следующих примерах.

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

Mandatory-mandatory. Для примера, который приведен на слайде эта связь означает, что каждый поставщик (A) должен поставлять один или более наборов товаров (B). С точки зрения теории тут все хорошо. Однако на практике оператор не сможет ввести данные ни в одну из таблиц, поскольку записи необходимо одновременно вводить в обе таблицы.

Optional-mandatory. В этом случае у оператора теперь все хорошо: данные вводить он может, а у бизнеса могут возникнуть проблемы. Дело в том, что связь optional-mandatory предполагает, что поставщик (A) должен поставлять один или более наборов товаров (B), в то время как B может принадлежать поставщику. Другими словами, товары могут существовать без поставщика, в то время как у поставщика есть товары. Т.е. возможно неконтролируемое ведение бизнеса: кто поставил товар? С кого спрашивать? А бизнесу проблемы нужны? Нет. Он должен давать прибыль. В этом случае лучше использовать mandatory-optional: поставщик может поставлять один или более наборов товаров, в то время как товар должен принадлежать поставщику. Другими словами, у товара есть поставщик, а данные о поставщиках, которые когда-то поставляли товар будут сохранены. И овцы целы и волки сыты - оператор может вводить данные и бизнесмен в кусе дел.

Optional-optional. Как видим у оператора опять все хорошо, а у бизнеса проблема - безконтрольность: Товар может существовать без поставщика и поставщик без товара.
Подведем итоги для связи один-ко-многим. Если сущности участвуют в связи как: - mandatory-mandatory, то такая связь не имеет права на жизнь, поскольку вводить записи одновременно в обе таблицы невозможно; - optional-optional, то сопровождение бизнеса проблематично.

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

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

Многие-ко-многим mandatory-optional - применяется редко. Такие связи всегда подлежат дальнейшей детализации.

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

Optional-optional один-к-одному. Для примера, который приведен на слайде эта связь означает, что любой мужчина (женщина) может состоять в браке с одной женщиной (мужчиной). Эта связь удобна для отслеживания истории брачующихся: впервые, повторно, ... Другими словами, связь альтернативного типа.

Optional-optional один-ко-многим. Пример связи приведен на слайде. Это классическая иерархия (древовидная структура). Связь, приведенную на слайде можно интерпретировать, например, так: любой сотрудник может быть подчинен только одному менеджеру, в то время как менеджер может руководить одним или многими сотрудниками.

Optional-optional М:М Пример связи приведен на слайде 3. Это сетевая структура.

Контрольный список вопросов к сущностям

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

Контрольный список вопросов к атрибутам:

• Является ли наименование атрибута существительным единственного числа, отражающим суть обозначаемого атрибутом свойства?
• Не включает ли в себя наименование атрибута имя сущности (этого быть не должно)?
• Имеет ли атрибут только одно значение в каждый момент времени?
• Отсутствуют ли повторяющиеся значения (или группы)?
• Описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?
• Не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?
• Не может ли он быть пропущенной связью?
• Нет ли где-нибудь ссылки на атрибут как на "особенность проекта", которая при переходе на прикладной уровень должна исчезнуть?
• Есть ли необходимость в истории изменений?
• Зависит ли его значение только от данной сущности?
• Если значение атрибута является обязательным, всегда ли оно известно?
• Есть ли необходимость в создании домена для этого и ему подобных атрибутов?
• Зависит ли его значение только от какой-то части уникального идентификатора?
• Зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

Концептуальная модель базы данных это

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

Принятые определения в концептуальной базе данных

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

1. Объект или сущность . Это фактическая вещь или объект (для людей) за которой пользователь (заказчик) хочет наблюдать. Например, Иванов Иван Иванович;
2. Атрибут это характеристика объекта, соответствующая его сущности. Например. Задаем себе вопрос: Какую информацию нужно хранить об Иванове Иване Ивановиче? Ответы на этот вопрос и будут атрибуты объекта Иванов Иван Иванович;
3. Третье понятие в проектировании концептуальной базы данных это связь или отношения между объектами.

Лексически более правильно говорить связь между объектами КБД и отношения между сущностями КБД (концептуальная база данных), но встретить можно самые различные сочетания сущности, объекта, связи и отношения (огрехи переводов).

Концептуальная модель базы данных условные обозначения

Концептуальная модель базы данных: принятые графические обозначения

Диаграмма сущность/отношения (объект/связь) называют ER-диаграммой или EDR (entity-relationship diagram). Сама модель сущность-связь была предложена профессором Peter Pin-Shen Chen (Питер Чен) в 1976 году. Правила написания и условные обозначения ER-диаграммы называют нотацией. Распространены две основные нотации ER-диаграмм:

• Нотация Питера Чена;
• Нотация Gordon Everest (Гордона Эверста). Под назаванием Crow’s Foot или Fork (вилка).

Обозначения ER-диаграммы по Питеру Чену

Чен предложил и это приняли следующие условные обозначения для ER-диаграмм:

• Сущность или объект обозначать прямоугольником;
• Отношения обозначать ромбом;
• Атрибуты объектов, обозначаются овалом;
• Если сущность связана с отношением, то их связь обозначается прямой линией со стрелкой. Необязательная связь обозначается пунктирной линией. Мощная связь обозначается двойной линией.

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

Нотация Gordon Everest

Gordon Everest ввел новое обозначение связей, которые получили название вилка или воронья лапа. Также он ввел, что объект должен обозначаться прямоугольником с названием типа объекта в виде имени существительного внутри прямоугольника. Причем, это имя должно быть уникальным в пределах создаваемой базы данных.

Атрибуты не выделяются в отдельную фигуру, а вписываются в прямоугольник объекта именем существительным с уточняющим словом.

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

концептуальная модель базы данных ERD Fork

Дополнения

Атрибуты в ER диаграмме, могут иметь свои собственные атрибуты (композитный) атрибут.

Простую ER диаграмму нарисовать достаточно просто. Другое дело насыщенная, объемная ER диаграмма. Ниже приведены некоторые советы, которые помогут вам построить эффективные ER схемы:

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

[править]

Материал из Википедии - свободной энциклопедии

У этого термина существуют и другие значения, см. ER .

Модель сущность-связь (ER-модель) (англ. entity-relationship model , ERM) - модель данных, позволяющая описыватьконцептуальные схемы предметной области.

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram , ERD).

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

История создания[править]

Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen ) , американским профессором компьютерных наук в университете штата Луизиана .

Нотации[править]

Нотация Питера Чена[править]

Простая ER-модель MMORPG с использованием нотации Питера Чена

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

Crow"s Foot[править]

Пример отношения между сущностями согласно нотации Crow"s Foot

Данная нотация была предложена Гордоном Эверестом (англ. Gordon Everest ) под названием Inverted Arrow («перевёрнутая стрелка»), однако сейчас чаще называемая Crow"s Foot («воронья лапка») или Fork («вилка»).

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

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

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

6.2.2. Основные понятия модели Entity-Relationship (Сущность-Связи)

На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом (Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества разновидностей ER-моделей одна из наиболее развитых применяется в системе CASE фирмы ORACLE. Ее мы и рассмотрим. Более точно, мы сосредоточимся на структурной части этой модели.

Основными понятиями ER-модели являются сущность, связь и атрибут.

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

Ниже изображена сущность АЭРОПОРТ с примерными объектами Шереметьево и Хитроу:

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

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

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

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

В изображенном ниже примере связь между сущностями БИЛЕТ и ПАССАЖИР связывает билеты и пассажиров. При том конец сущности с именем "для" позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец сущности с именем "имеет" означает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

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

Каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА;

Каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.

Каждый ЧЕЛОВЕК является сыном одного и только одного ЧЕЛОВЕКА;

Каждый ЧЕЛОВЕК может являться отцом для одного или более ЛЮДЕЙ ("ЧЕЛОВЕКОВ").