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

Постоянные данные

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

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

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

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

• База данных состоит из некоторого набора постоянных данных, которые исполь­зуются прикладными системами для какого-либо предприятия.

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

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

Замечание. В первых изданиях этой книги вместо термина "постоянные данные" использовался термин "операционные данные". Старый термин отражал первона­чальное особое значение операционных приложений в базах данных, т.е. рутинных, часто выполняющихся приложений, предназначенных для поддержки каждодневной работы предприятия (например, приложения для поддержки депозитов или изъятия наличных денег в банковской системе). Теперь же базы данных все чаще использу­ются в приложениях другого рода— приложениях принятия решений, и термин "операционные данные" для них уже не подходит. На практике сегодняшние пред­приятия используют две отдельные базы данных: с операционными данными и с дан­ными для поддержки принятия решений. Базы данных систем принятия решений час­то содержат отчетную информацию (например, итоги и средние результаты), кото­рую, в свою очередь, периодически (например, раз в день или раз в неделю) получают из операционной базы данных.

Объекты и отношения

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

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

• Задан поставщик, найти детали, поставляемые этим поставщиком.

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

Важное значение имеет то, что это отношение, как и другие отношения, пока­занные на рис. 1.6, подобно основным объектам является частью данных. По­этому вместе с основными объектами отношения тоже должны быть представле­ны в базе данных. Далее в книге рассматриваются способы, которыми это можно сделать. Схема, представленная на рис. 1.6, называется (по очевидным причинам) схемой объект/отношение (также ее называют диаграммой объект/отношение). Такие схемы более подробно рассматриваются далее в этой книге.

Рис. 1.6. Пример схемы объект/отношение

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

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

а) "Смит поставляет гаечные ключи для Манхэттенского проекта" говорит нам больше, чем следующие три:

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

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

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

Мы не можем наверняка утверждать (а), зная только (б), (в) и (г). Точнее, если мы зна­ем (б), (в) и (г), то мы можем утверждать, что Смит поставляет гаечные ключи для ка­кого-то проекта (скажем, проекта J), что какой-то поставщик (скажем, поставщик S) поставляет гаечные ключи для Манхэттенского проекта и что Смит поставляет ка­кую-то деталь (скажем, деталь Р) для Манхэттенского проекта, но мы не можем точно утверждать, что S — это Смит, Р — это гаечные ключи, а J — Манхэттенский проект. Такие ложные выводы называют ловушкой при соединении выражений.

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

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

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