Замечание. В первых изданиях этой книги вместо термина перманентные данные использовался термин операционные данные . Старый термин отражал первоначальное особое значение операционных или производственных приложений баз данных, т.е. рутинных, часто выполняющихся приложений, предназначенных для поддержки каждодневной работы предприятия (например, приложений для поддержки депозитов или изъятия наличных денег в банковской системе). Для среды такого рода в последнее время используется термин оперативная обработка транзакции (online transaction processing - OLTP). Однако теперь базы данных все чаще используются и в приложениях другого рода, например в приложениях поддержки принятия решений (decision support), и термин операционные данные для них уже не подходит. На практике сегодняшние предприятия используют две отдельные базы данных: базу с операционными данными и базу с данными для поддержки принятия решений, которую обычно называют хранилищем данных (data warehouse). В хранилищах данных часто содержится обобщенная информация (например, итоговые и средние значения), которая, в свою очередь, периодически (например, раз в день или раз в неделю) извлекается из операционной базы данных. Обсуждение баз данных и приложений поддержки принятия решений будет продолжено в главе 21.

Сущности и связи

Рассмотрим пример некоторой промышленной компании ( KnowWare, Inc. ) более детально. Обычно подобному предприятию требуется записывать информацию об имеющихся проектах (Projects), используемых в этих проектах деталях (Parts), поставщиках (Suppliers) деталей, складах (Warehouses), на которых хранятся детали, служащих (Employees), работающих над проектами, и т.д. Проекты, детали, поставщики и т.д. представляют собой основные сущности (entity), о которых компании KnowWare, Inc. необходимо хранить информацию. Термин сущность обычно используется в теории баз данных для обозначения любого отличимого объекта, который может быть представлен в базе данных.

Кроме собственно основных сущностей (в данном примере это поставщики, детали и т.д.), существуют еще и связи (relationships) между ними, которые объединяют эти основные сущности. На рис. 1.5 связи представлены ромбами с соединительными линиями. Например, между поставщиками и деталями существует связь SP: каждый поставщик поставляет определенные детали, и, наоборот, каждая деталь поставляется определенными поставщиками. (Точнее, каждый поставщик поставляет определенные виды деталей и каждый вид деталей поставляется определенными поставщиками.) Аналогично детали используются в проектах, а для реализации проектов требуются детали (связь PJ); детали хранятся на складах, а склады хранят детали (связь WP) и т.д. Обратите внимание, что эти связи двусторонние, т.е. их можно рассматривать в обоих направлениях. В частности, используя связь SP между поставщиками и деталями, можно ответить на следующие вопросы.

Задан поставщик, и требуется определить поставляемые им детали.

Задана деталь, и необходимо найти поставщиков, поставляющих такую деталь.

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

Поставщики (Suppliers)

Проекты (Projects)

.SPJ

Puc. 1.5. Пример диаграммы сущность-связь (ER-диаграммы) для базы данных компании Know Ware, Inc.

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

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

Отметим еще несколько важных моментов, проиллюстрированных на рис. 1.5.

1. Хотя большинство связей на этой диаграмме связывает два типа сущностей (т.е. они являются бинарными), это вовсе не означает, что все связи должны быть бинарными. В примере есть одна связь (SPJ), связывающая три типа сущностей (Suppliers, Parts и Projects). Это пример тернарной (тройной) связи. Интерпретация данной связи такова: определенные поставщики поставляют определенные детали для определенных проектов. Обратите особое внимание на то, что в общем случае такая тернарная связь не эквивалентна простой комбинации из трех бинарных связей: поставщики поставляют детали , детали используются в проектах и проекты снабжаются поставщиками . В частности, приведенное ниже утверждение а говорит нам больше, чем последующие три утверждения.

а) Смит поставляет разводные гаечные ключи для Манхэттенского проекта ;

б) Смит поставляет разводные гаечные ключи ;

в) Разводные гаечные ключи используются в Манхэттенском проекте ;

г) Манхэттенский проект снабжается Смитом .

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

гаечные ключи для Манхэттенского проекта и что Смит поставляет какую-то деталь (скажем, деталь Ру) для Манхэттенского проекта. Однако мы не можем точно утверждать, что поставщик Sx - это Смит, деталь Ру - это разводной гаечный ключ, а проект Jz - это Манхэттенский проект. Такие ложные выводы называются ловушкой соединения (connection trap).

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

3. Вообще говоря, для заданного набора типов сущностей может существовать любое количество связей. В представленной на рис. 1.5 диаграмме присутствуют две различные связи между сущностями Projects и Employees: первая (EJ) представляет тот факт, что служащие заняты в проектах, а вторая (MJ) - что служащие управляют проектами.

Теперь мы убедились, что связь можно понимать как сущность особого типа. Если сущность определена как нечто, о чем необходимо записывать информацию , то понятие связи вполне подходит под такое определение. Например, связь деталь Р4 хранится на складе W8 - это сущность, о которой может потребоваться записать некоторую информацию, например соответствующее количество указанных деталей. Более того, существуют некоторые преимущества (их описание выходит за рамки этой главы) в том, что мы не делаем излищних различий между сущностями и связями. Поэтому в данной книге связи будут рассматриваться как особый тип сущности.

Свойства

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

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