Главная » SQL, Базы данных » ОБЩЕЕ ОПРЕДЕЛЕНИЕ БАЗЫ ДАННЫХ

0

1.2.     Перманентные данные

Обычно данные в базе данных называют перманентными или постоянно хранимыми

(хотя иногда на самом деле они недолго остаются таковыми!). Под словом перманентные

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

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

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

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

2.           Банк.

3.           Больница.

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

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

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

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

2.          Бухгалтерские данные.

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

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

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

Примечание. В первых шести изданиях этой книги вместо термина перманентные данные использовался термин операционные данные. Старый термин первоначально акцентировал внимание на особом значении оперативных, или производственных, приложений баз данных, т.е. рутинных, часто  выполняющихся  приложений, предназначенных для поддержки повседневной  работы предприятия (например, приложений для поддержки операций зачисления и списания средств на счетах в банковской системе). Для среды такого рода в последнее время используется термин оперативная обработка транзакций (On-Line Transaction Processing— OLTP). Однако теперь базы данных все чаще применяются и в приложениях другого рода, например, в приложениях  поддержки принятия решений (decision support), и термин операционные данные для них уже не подходит. На практике сегодняшние предприятия используют две отдельные базы данных — с операционными данными и с данными для  поддержки принятия решений; последнюю обычно называют хранилищем данных (data warehouse). В хранилищах данных часто содержится агрегированная информация (например, итоговые и средние значения), которая, в свою очередь, периодически (например, раз в сутки или раз в неделю) извлекается из операционной базы данных. Обсуждение баз данных и приложений, которые служат для поддержки принятия решений, будет продолжено в главе22.

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

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

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

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

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

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

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

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

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

Рис. 1.5 может также служить иллюстрацией для многих других важных понятий, описанных ниже.

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

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

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

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

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

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

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

1  Характерной особенностью реляционных баз данных (см. раздел 1.6) является то, что основные сущности и связи между ними представлены с помощью отношений (relation) или, иными словами, с помощью таблиц,  подобных показанной  в табл.  1.1.  Но следует  учитывать,  что термин связь (relationship), который используется в текущем разделе, и термин отношение, применяемый в контексте реляционных баз данных, обозначают разные понятия.

2  Применяемый в оригинале англоязычный термин statement имеет два разных значения: в данном случае он указывает на утверждение, касающееся некоторого факта (которое в логике принято называть высказыванием; см. подраздел "Данные и модели данных" ниже в этом разделе), а в другом контексте может служить синонимом термина command (команда).

выводы, сделанные на основании неполной информации, называются дефектом соединения (connection trap).

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

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

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

Свойства

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

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

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

(в частности, в главах 5, 6, 26 и 27), а пока в большинстве случаев (за исключением тех,

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

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

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

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

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

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

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

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

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

году".)

3 Точнее, с помощью кортежей в отношениях, как описано в главе 3.

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

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

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

реализации.

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

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

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

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

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

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии