1.3. Что такое база данных Перманентные данные

Обычно данные в базе данных называют перманентными или постоянными (хотя на самом деле они могут недолго оставаться таковыми!). Под словом перманентные (persistent) подразумеваются данные, которые отличаются от других, более изменчивых данных, таких как промежуточные результаты, входные и выходные данные, управляю- щие операторы, рабочие очереди, программные управляющие блоки и вообще все вре- менные (transient) по своей сути данные. Точнее говоря, можно утверждать, что данные в базе остаются "перманентными", поскольку после того, как они были приняты средства- ми СУБД для помещения в базу, удалить их из нее впоследствии можно лишь с помо- щью соответствующего явного запроса к базе данных, но не как результат какого-либо побочного эффекта от выполнения некоторой программы. Подобный взгляд на понятие перманентности позволяет точнее определить термин "база данных".

■ База данных— это некоторый набор перманентных (постоянных) данных, ис- пользуемых прикладными системами какого-либо предприятия.

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

1. Промышленная компания.

2. Банк.

3. Больница.

4. Университет.

5. Министерство.

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

1. Данные о продукции.

2. Данные о состоянии счетов.

3. Данные о пациентах.

4. Данные о студентах.

5. Данные о планируемой деятельности.

Замечание. В первых изданиях этой книги вместо термина "перманентные данные" использовался термин "операционные данные". Старый термин отражал первоначальное особое значение операционных или производственных приложений баз данных, т.е. рутинных, часто выполняющихся приложений, предназначенных для поддержки каждо- дневной работы предприятия (например, приложений для поддержки депозитов или изъ- ятия наличных денег в банковской системе). Для среды такого рода в последнее время используется термин оперативная обработка транзакции (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)

<mj>

_<s>

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

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

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

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

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

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

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

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

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

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

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

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

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

Свойства

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

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

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

Данные и модели данных

Существует и другой, не менее важный, подход к пониманию данных и баз данных. Слово "данные" (data) происходит от латинского слова "давать", откуда следует, что данные на самом деле являются заданными фактами, из которых можно логически полу- чить другие факты. (Получение дополнительных фактов из заданных фактов— это в 'точности то, для чего используется СУБД, обслуживая запросы пользователя.) "Заданный факт", в свою очередь, соответствует тому, что в логике называется истин- ным высказыванием¹. Например, высказывание "Поставщик с номером 'S1' находится в Лондоне" вполне может быть таким истинным высказыванием. Отсюда следует, что база данных в действительности есть набор подобных истинных высказываний [1.2].

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

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

"В ячейке 72 находятся две бутылки вина Zinfandel, выпущенные компанией Rafanelli в 1995 году, которые будут готовы к употреблению в 2003 году."

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

"Некоторые бутылки вина Zinfandel будут готовы к употреблению в 2003 году."

(Точнее, "Некоторые бутылки вина Zinfandel в некоторой ячейке, произведенные некоторым производителем в некотором году, будут готовы к употреблению в 2003 году.")

Высказывание в логике — это нечто, что может быть недвусмысленно оценено как истина или ложь. Например, "Вильям Шекспир написал Гордость и предубеждение" — это высказывание (как видно, ложное).

Однако реляционная модель — не единственная возможная модель данных. Сущест- вуют и другие модели (раздел 1.6), хотя многие из них отличаются от реляционной мо- дели только тем, что они в определенной степени приспособлены для специальных слу- чаев, а не строго построены на формальной логике. Возникает вопрос, что же такое мо- дель данных? Это понятие можно определить следующим образом.

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

Используя это определение, можно эффективно разделить модель данных и ее реали- зацию.

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

Короче говоря, модель — это то, что пользователи должны знать, а реализация — это то, чего пользователи не должны знать.

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

В завершение этого раздела необходимо отметить, что в действительности термин мо- дель данных используется в литературе в двух различных смыслах. Первое значение терми- на описано выше. Второе значение относится к модели перманентных данных некоторого конкретного предприятия (например, промышленной компании KnowWare, Inc., упоми- наемой выше в этом разделе). Различие между этими двумя значениями можно описать так.

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

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

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