Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
БД теория.doc
Скачиваний:
2
Добавлен:
01.03.2025
Размер:
421 Кб
Скачать
☆
  1. Проектирование баз данных. Определение взаимосвязи между сущностями.

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

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

Более сложные связи (не бинарные) следует сводить к бинарным. Для опи­сания взаимосвязей N объектов требуется N-1 таблиц связей. Транзитивных связей не должно быть. Избыток связей приводит к противоречиям Не следует включать в таблицы связей характеристики сущностей, иначе неизбежны аномалии. Их лучше хранить в отдельных таблицах сущностей.

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

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

ПРИМЕР

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

В рассматриваемой задаче по автоматизации управления работой дилера по продаже легковых автомобилей, если клиент производит заказ на покупку автомобиля впервые, осуществляется первичная регистрация его данных и сведений о сделанном заказе. Если же клиент производит заказ повторно, осуществляется регистрация только данного заказа. Вне зависимости от того, сколько раз данный клиент производил заказы, он имеет уникальный иденти­фикационный номер (уникальный ключ клиента). Информация о каждом клиенте включает наименование клиента, адрес, телефон, факс, фамилию, имя, отчество, признак юридического лица и примечание. Таким образом, атрибутами объекта КЛИЕНТ являются «УНИКАЛЬНЫЙ КЛЮЧ КЛИЕНТА», «НАИМЕ­НОВАНИЕ КЛИЕНТА», «АДРЕС КЛИЕНТА» и т. д.

Следующий представляющий для нас интерес объект — МОДЕЛЬ АВТОМО­БИЛЯ. Этот объект имеет атрибуты «УНИКАЛЬНЫЙ КЛЮЧ МОДЕЛИ», «НАИМЕНОВАНИЕ МОДЕЛИ» и т. д.

Третий рассматриваемый объект — ЗАКАЗ. Его атрибутами являются «НОМЕР ЗАКАЗА», «КЛЮЧ КЛИЕНТА» и «КЛЮЧ МОДЕЛИ».

И четвертый рассматриваемый объект — ПРОДАВЕЦ. Его атрибутами являют­ся «УНИКАЛЬНЫЙ КЛЮЧ ПРОДАВЦА», «ИМЯ ПРОДАВЦА», «ФАМИ­ЛИЯ» и «ОТЧЕСТВО».

Взаимосвязь «один к одному» (между двумя типами объектов)

Мысленно вернемся к временам планово-распределительной экономики. Допус­тим, в определенный момент времени один клиент может сделать только один заказ. В этом случае между объектами КЛИЕНТ и ЗАКАЗ устанавливается взаимосвязь «один к одному», обозначаемая одинарными стрелками, как это показано на рис. 2.2,а.

Рис. 2.2. Взаимосвязи между двумя объектами: а) «один к одному»;

б) «один ко многим»; в) «многие ко многими

Между данными, хранящимися в объектах КЛИЕНТ и ЗАКАЗ, будет сущест­вовать взаимосвязь, в которой каждая запись в одном объекте будет однозначно указывать на запись в другом объекте. На рис. 2.3 приведен пример такой взаимосвязи между данными. Ни в одном, ни в другом объекте не может существовать записи, не связанной с какой-либо записью в другом объекте.

Рис. 2.3. Взаимосвязь между данными при отношении «один к одному»

Взаимосвязь «один ко многим» (между двумя типами объектов)

В определенный момент времени один клиент может стать обладателем несколь­ких моделей автомобилей, при этом несколько клиентов не могут являться обладателями одного автомобиля. Взаимосвязь «один ко многим» можно обоз­начить с помощью одинарной стрелки в направлении к «одному» и двойной стрелки в направлении ко «многим», как это показано на рис. 2.2,6.

В этом случае одной записи данных первого объекта (его часто называют родительским или основным) будет соответствовать несколько записей второго объекта (дочернего или подчиненного). Взаимосвязь «один ко многим» очень распространена при разработке реляционных баз данных. В качестве родитель­ского объекта часто выступает справочник, а в дочернем хранятся уникальные ключи для доступа к записям справочника. В нашем примере в качестве такого справочника можно представить объект КЛИЕНТ, в котором хранятся сведения о всех клиентах. При обращении к записи для определенного клиента нам доступен список всех покупок, которые он сделал и сведения о которых хранятся в объекте МОДЕЛЬ АВТОМОБИЛЯ, как это показано на рис. 2.4. В случае, если в дочернем объекте будут какие-то записи, для которых нет соответствую­щих записей в объекте КЛИЕНТ, то мы их не увидим. В этом случае говорят, что объект содержит потерянные (одинокие) записи. Это не допустимо, и в дальнейшем вы узнаете, как избегать подобных ситуаций.

Рис. 2.4. Взаимосвязь между данными при отношении ^один ко многими

Если мы будем просматривать записи объекта МОДЕЛЬ АВТОМОБИЛЯ, то в объекте КЛИЕНТ мы сможем получить данные о клиенте, купившем данный автомобиль (см. рис. 2.4). Обратите внимание, что для потерянных записей сведений о клиенте мы не получим.