metBD (1084482), страница 3

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

1 М

Пример

1 М

Квартира может пустовать, в ней может жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

Пример Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК, то существует четыре возможных представления такой связи:

1. Традиционный брак

1 1

1

2. Многоженство

1 М

1

3. Многомужие

М 1

1

4. Групповой брак

М М

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

Пример.

• Множество связей между одними и теми же сущностями

1 М

N T

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

• Тренарные связи

М М

1

P

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

Пример

а)

1 1

1 1

б)

1 1

1

в)

1 1

1

г)

1 1

1

а) каждый автор пишет не более одной книги, и каждая книга пишется не более, чем одним автором

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

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

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

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

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

Ключи

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

ПОТЕНЦИАЛЬНЫЙ КЛЮЧ – это атрибут или набор атрибутов, который уникально идентифицирует каждый экземпляр сущности данного типа

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

ПЕРВИЧНЫЙ КЛЮЧ – это потенциальный ключ, который выбран в качестве первичного ключа.

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

СОСТАВНОЙ КЛЮЧ – это потенциальный ключ, который состоит из двух или более атрибутов

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

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

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

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

1. Может ли данный внешний ключ принимать неопределенные значения (NULL-значения)? Иначе говоря, может ли существовать некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом? В случае поставок это, вероятно, невозможно – поставка, осуществляемая неизвестным поставщиком, или поставка неизвестного продукта не имеют смысла. Но в случае с сотрудниками такая ситуация однако могла бы иметь смысл – вполне возможно, что какой-либо сотрудник в данный момент не зачислен вообще ни в какой отдел. Заметим, что ответ на данный вопрос не зависит от прихоти проектировщика базы данных, а определяется фактическим образом действий, принятым в той части реального мира, которая должна быть представлена в рассматриваемой базе данных. Подобные замечания имеют отношение и к вопросам, обсуждаемым ниже.

2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на которую ссылается внешний ключ? Например, при удалении поставщика, который осуществил по крайней мере одну поставку. Существует три возможности:

3. Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка. Этот случай для определенности снова рассмотрим подробнее. Имеются те же три возможности, как и при удалении:

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

Ограничения целостности

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7). Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений (не путать с незаконными изменениями и разрушениями, являющимися проблемой безопасности). Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же, как и средств обеспечения поддержания безопасности).

Выделяют три группы правил целостности:

1. Целостность по сущностям.

2. Целостность по ссылкам.

3. Целостность, определяемая пользователем.

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

Значение внешнего ключа должно либо:

• быть равным значению первичного ключа цели;

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

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

• уникальность тех или иных атрибутов,

• диапазон значений (экзаменационная оценка от 2 до 5),

• принадлежность набору значений (пол "М" или "Ж").

2.2 Модели данных

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

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

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

• Администратор базы данных должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния не пользовательские представления.

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

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

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

Характеристики

Список файлов книги