из электронной библиотеки / 887484694831074.pdf

Как видно из рисунка, все экземпляры имеют одинаковые атрибуты, но разные данные

(значения) каждого атрибута.

Идентификаторы (identifiers) - это атрибуты, с помощью которых экземпляры именуются или идентифицируются.

Идентификатор экземпляра сущности состоит из одного или более атрибутов сущности.

Идентификатор может быть уникальным (unique) либо неуникальным (nonunique). Если идентификатор является уникальным, его значение будет указывать на один и только на один экземпляр сущности. Если идентификатор является неуникальным, его значение будет указывать на некоторое множество экземпляров. Синонимом термину «идентификатор»

является термин «ключ».

Пример. В классе сущностей АВТОР идентификатором является атрибут ID. В случае,

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

Связь (relationships) – это взаимоотношения сущностей.

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

Класс связей может затрагивать несколько классов сущностей. Число классов сущностей,

участвующих в связи, называется степенью связи (relationship degree). Изображенная на рисунке 59

связь ПРОДАВЕЦ-ЗАКАЗ имеет степень 2, поскольку в ней участвуют два класса сущностей:

ПРОДАВЕЦ и ЗАКАЗ. Связь РОДИТЕЛЬ имеет степень 3, так как в ней участвуют три класса сущностей: МАТЬ, ОТЕЦ и РЕБЕНОК. Связи степени 2 весьма распространены, их часто называют еще бинарными связями (binary relationships).

Рисунок 59 - Типы связей

Типы бинарных связей

На рисунке 60 показаны три типа бинарных связей.

В связи 1:1 (один к одному) одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа. Связь СЛУЖЕБНЫЙ-АВ-ТОМОБИЛЬ связывает одиночную сущность класса СОТРУДНИК с одиночной сущностью класса АВТОМОБИЛЬ. В

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

Рисунке 60 - Три типа бинарных связей

В связи типа 1:N (один к N, или один ко многим) экземпляр сущности одного типа связан со многими экземплярами сущности другого типа. В нашем примере таким типом связи является связь ОБЩЕЖИТИЕ-СТУДЕНТ, где единичный экземпляр сущности класса ОБЩЕЖИТИЕ связан со многими экземплярами сущности класса СТУДЕНТ, то есть в общежитии может проживать много студентов, но каждый студент живет только в одном общежитии.

Позиции, в которой стоят символы 1 и N, имеют значение. Единица стоит на той стороне связи,

где располагается ОБЩЕЖИТИЕ, a N — на той, где располагается СТУДЕНТ Если бы символы 1 и N

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

Третьем типом бинарной связи является связь N:M (читается N К M, или многие ко многим). В

нашем примере это связь СТУДЕНТ-КЛУБ, связывающая экземпляры сущностей класса СТУДЕНТ с экземплярами сущностей класса КЛУБ. Один студент может быть членом нескольких клубов, а в одном клубе может состоять много студентов.

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

Преимущества ER-моделирования

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

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

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

Хорошая интеграция с реляционной моделью данных. ER-модель хорошо интегрируется с реляционной моделью БД. Такая интеграция помогает эффективно структурировать процесс проектирования реляционных БД.

Недостатки ER-моделирования

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

«автор может работать над несколькими книгами, или более чем над одной книгой, но не более чем над тремя книгами» легко изображаются средствами ER-модели. Однако некоторые ограничения,

например, «оплата автору может варьироваться в диапазоне от 4 до 25 %» или «автор не имеет права работать больше 10 часов подряд», в ER-модели представить невозможно, и они должны обрабатываться на уровне приложений.

Ограниченные возможности представления отношений. Связи представляются как нечто,

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

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

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

ВНИМАНИЕ ----------------------------------------------------------------

Все сказанное о недостатках ER-модели верно лишь в отношении теоретической модели. В

современных средствах моделирования данных (таких как программа ErWin Data Modeler) применяется расширенная ER-модель, практически лишенная всех перечисленных недостатков.

5.2.2. Реляционная модель данных

Наиболее популярным сейчас типом баз данных являются так называемые реляционные базы данных. Реляционная модель данных была предложена Е. Ф. Коддом (Е. Е Codd), известным исследователем в области баз данных, в 1969 г., когда он был сотрудником IBM.

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

2. Правило гарантированного доступа.

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

ПОЯСНЕНИЕ -------------------------------------------------------------

В наборе из 12 правил нет явного указания, что каждая строка в таблице должна иметь уникальный первичный ключ. Однако правило 2 неявным образом говорит об этом: ни одна таблица не может соответствовать правилу гарантированного доступа, если в ней нет первичного ключа.

3. Правило систематической трактовки значений null.

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

ПОЯСНЕНИЕ -------------------------------------------------------------

Во-первых, база данных должна поддерживать значения null для обозначения того, что атомарные данные являются неизвестными (null — это не 0, не пустая строка и не пробел); во-вторых, в

базе данных должно быть общее правило, определяющее, как обрабатывать значения null (например,

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

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

Описание базы данных представляется на логическом уровне так же, как обычные данные,

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

5. Правило наличия исчерпывающего подъязыка данных.

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

описания данных;

описания представлений;

манипуляций данными;

ограничений целостности;

границ транзакций (начала, завершения и отката).

6. Правило обновления представлений.

Все представления, обновляемые теоретически, должны обновляться практически.

7. Правило ввода, обновления и удаления данных на высоком уровне.

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

ПОЯСНЕНИЕ---------------------------------------------------------------

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

8. Правило физической независимости данных.

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

ПОЯСНЕНИЕ --------------------------------------------------------------

Это правило подразумевает возможность переноса физических данных из одного каталога (раздела,

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

9. Правило логической независимости данных.

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

ПОЯСНЕНИЕ --------------------------------------------------------------

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

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

10.Правило независимости целостности.

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

Для этого должны соблюдаться как минимум два ограничения:

сущностная целостность: ни один из компонентов первичного ключа не может принимать значения null;

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

11.Правило независимости распределения.

В реляционной СУБД распределение независимо.

ПОЯСНЕНИЕ --------------------------------------------------------------

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

12.Правило соблюдения правил {запрет обхода правил).

Если в реляционной системе имеется язык низкого уровня («одна запись за раз»), его нельзя использовать для нарушения или пропуска правил или ограничений целостности, установленных в реляционном языке более высокого уровня («несколько записей за раз»).

Ключи и связи

Рассмотрим стандартную для современных информационных систем задачу построения базы данных, которая содержит в себе информацию о клиентах и сделанных ими заказах

(покупках).

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

Рисунок 61 - Схема таблицы Клиенты и заказы

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

и их впишут в один счет). Значит, для того чтобы обеспечить уникальность каждой записи в таблице,

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

Первичный ключ – это поле, предназначенное для идентификации записи в таблице. Значения первичного ключа уникальны.

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

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

(в нашем случае — связи один ко многим).

Произведя разделение схемы таблицы на две, одна из которых содержит сведения о сделанном заказе, а другая — о каждом заказанном товаре, мы свяжем эти таблицы между собой при помощи связи один ко многим (на рисунке 62 это линия с цифрой 1 около одного конца и значком бесконечности около другого).

Рисунок 62 - Связь один ко многим

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

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

Ссылочная целостность

Как уже отмечалось, первичный ключ любой таблицы должен содержать уникальные непустые значения для данной таблицы. Это утверждение является одним из правил ссылочной целостности (referential integrity). Практически все современные СУБД контролируют уникальность первичных ключей. При попытке присвоить первичному ключу значение, уже имеющееся в другой записи, СУБД генерирует диагностическое сообщение, обычно содержащее словосочетание primary key violation (нарушение первичного ключа). Если две таблицы связаны соотношением один ко многим, внешний ключ второй таблицы должен содержать только те значения, которые уже имеются среди значений первичного ключа первой таблицы. Современные СУБД отслеживают попытки удалить запись в первой таблице, если во второй таблице есть связанные с ней записи, препятствуя этому и генерируя диагностические сообщения. Если бы этого не происходило, со временем вторая таблица переполнилась бы записями, не связанными ни с одной записью в первой таблице (а значит,

попросту бесполезными).

Нормализация данных

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

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

Вернемся к таблице Клиенты и заказы. Структура этой таблицы показана на рисунке 63.

Рисунок 63 - Таблица Клиенты и заказы в первой нормальной форме

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

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

может привести к некоторым негативным последствиям:

□до тех пор, пока клиент не сделал хотя бы один заказ, сведения о нем не появятся в базе

данных;

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

клиенте;

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

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

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

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

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