1_mt11-ИОРиИ Курс лекций_2015 (Презентации лекций), страница 6

Рис.6

Рис.7

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

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

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

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

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

Рис.8

Трактовка изображенной диаграммы:

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

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

На следующем примере изображена рекурсивная связь, связывающая сущность ЧЕЛОВЕК с ней же самой. Конец связи с именем "сын" определяет тот факт, что у одного отца может быть более чем один сын. Конец связи с именем "отец" означает, что не у каждого человека могут быть сыновья.

Рис.9

Трактовка изображенной диаграммы:

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

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

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

Пример:

ЧЕЛОВЕК

имя

возраст

пол

Рис.10

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

Нормальные формы ER-схем

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

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

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

В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в уникальный идентификатор. Эти атрибуты являются основой отдельной сущности.

Более сложные элементы ER-модели

К числу более сложных элементов ER-модели относятся следующие:

• Подтипы и супертипы сущностей. Как в языках программирования с развитыми типовыми системами (например, в языках объектно-ориентированного программирования), вводится возможность наследования типа сущности, исходя из одного или нескольких супертипов.

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

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

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

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

Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, которое и составляет супертип. Иногда для полноты приходится определять дополнительный подтип ПРОЧИЕ.

Преобразование ER-схемы в реляционную модель

Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность – сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

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

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

Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи – столбцам, не допускающим неопределенные значения.

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

Методология IDEF1

Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия - методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

Рис.11. Сущности

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

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

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

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

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

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

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

Виды связей

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

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

3. Много-ко-многим.

1. Для связи «один-к-одному» каждому элементу одной стороны связи соответствует только один элемент другой стороны связи. Такой вариант связи не представляет какого-либо интереса для реляционной модели БД.

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

3. Связь «Много-ко-многим » является «ненормальной» с позиций теории БД и реальная такая связь из предметной области может быть перенесена в модель БД путем разбиения на две связи «один-ко-многим». Для этого создается таблица с кодами “N1” (ключевыми), содержащую первичную информацию одной стороны связи предметной области, затем создается вторая таблица с кодами “N2” (ключевыми), которая содержит справочную информацию для второй стороны отношения “многие”. И на заключительном этапе определяют таблицу связей, с полями “N1” и “N2” (неключевые), в каждой строке которой определена информация по связям. Для каждой из таблиц таблица связей находится на стороне отношения «многие».

Механизм «Транзакций» для обеспечения целостности БД

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

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

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

Механизм «Индексирования» для повышения быстродействия БД

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

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