Введение в системы БД (542480), страница 8
Текст из файла (страница 8)
Для среды такого рода в последнее время используется термин оперативная обработка транзакции (оп11пе 1гапзасгюп ргосезз)па — О(,ТР). Однако теперь базы данных все чаще используются и в приложениях другого рода, например в приложениях поддержки принятия решений (деспйоп зцрроп), и термин "операционные данные" для них уже не подходит.
На практике сегодняшние предприятия используют две отдельные базы данных: базу с операционными данными и базу с данными для поддержки принятия решений, которую обычно называют хранилищем данны» (да1а зчаге)зопзе). В хранилищах данных часто содержится обобщенная информация (например, итоговые и средние значения), которая, в свою очередь, периодически (например, раз в день или раз в неделю) извлекается из операционной базы данных. Обсуждение баз данных и приложений поддержки принятии решений будет прололжено в главе 21. СУ1ИИОСТИ И СВЯЗИ Рассмотрим пример некоторой промышленной компании ("Кпочг%аге, 1пср) более детально. Обычно подобному предприятию требуется записывать информацию об имеюшихся проектах (Рго]есГв), используемых в этих проектах деталях (РагГв), поставщиках (Бпрр11егв) деталей, складах (йагеЬопаев), на которых хранятся детали, служащих (Еяр1оуеев), работаюших над проектами, и т.д.
Проекты, детали, поставшики н т.д. представляют собой основные сушности (епг)гу), о которых компании Кпою%аге, !пс. необходимо хранить информацию. Термин "сушность" обычно используется в теории баз данных для обозначения любого отличимого объекта, который может быть представлен в базе данных. Кроме собственно основных сушностей (в данном примере это поставшики, летали и т.д.), сушествуют еше и связи (ге1аг(опзп(рз) между ними, которые объединяют эти основные сущности.
На рис. 1.5 связи представлены ромбами с соединительными линиями. Например, между поставщиками и деталями существует связь 5Р: каждый поставшик поставляет определенные детали, и, наоборот, каждая деталь поставляется определенными поставшикамн. (Точнее, каждый поставщик поставляет определенные виды деталей и каждый вид деталей поставляется определенными поставшнками.) Аналогично детали используются в проектах, а для реализации проектов требуются детали (связь РЮ); детали хранятся на складах, а склады хранят детали (связь яР) н т.д.
Обратите внимание, что эти связи двусторонние, т.е. их можно рассматривать в обоих направлениях. В частности, используя связь 5Р между поставшиками и деталями, можно ответить на следуюшие вопросы. ° Задан поставшик, и требуется определить поставляемые им детали. ° Задана деталь, и необходимо найти поставщиков, поставляюших такую деталь. Очень важно то, что эта связь (как и другие связи, представленные на рис. 1.5) является такой же частью данны» предприятия, как и основные сущности. Поэтому связи должны быть представлены в базе данных наравне с основными сушностями предметной области.
Глава 1. Базы данных и управление ими 41 Рис. К5, Пример диаграммы "суи!ность-связь" (Е)1-диаграммы) для базы данных компании КповУгаге, 1пс. Замечание. В реляционных базах данных и основные сущности, и связи между ними представляются с помощью таблиц, подобных табл, 1.1 (подробнее об этом речь пойдет в главе 3). Схема, представленная на рис. 1.5, называется (по очевидным причинам) диаграммой исушность-связь" (иначе ее называют Ей-диаграммой).
Более подробно такие схемы рассматриваются в главе 13. Отметим еще несколько важных моментов, проиллюстрированных на рис. 1.5. 1. Хотя большинство связей на этой диаграмме связывает два типа сущностей (т.е. они являются бинарными), это вовсе не означает, что все связи должны быть бинарными. В примере есть одна связь (ЯРЮ), связывающая три типа сущностей 1ьврр1зегв, Рагьв и Рго)ессв).
Это пример тернарной !тройной) связи. Интерпретация данной связи такова: определенные поставщики поставляют определенные детали лля определенных проектов. Обратите особое внимание на то, что в общем случае такая тернарная связь не эквивалентна простой комбинации из трех бинарных связей: "поставщики поставляют детали", "детали используются в проектах" и "проекты снабжаются поставщиками". В частности, приведенное ниже утверждение а говорит нам больше, чем последующие три утверждения. а) "Смит поставляет разводные гаечные ключи для Манхэттенского проекта"; б) "Смит поставляет разводные гаечные ключи"; в) "Разводные гаечные ключи используются в Манхэттенском проекте"; г) "Манхэттенский проект снабжается Смитом".
Зная только утверждения б, в и г, мы не сможем доказать справедливость утверждения а. Точнее, зная утверждения б, в и г, мы можем лишь сделать заключение, что Смит поставляет разводные гаечные ключи для какого-то проекта !скажем, проекта!а), что какой-то поставщик (скажем, поставщик Бх) поставляет разводные Часть 1. Основные понятия гаечные ключи для Манхэттенского проекта и что Смит поставляет какую-то деталь (скажем, деталь Рт) для Манхэттенского проекта.
Однако мы не можем точно утверждать, что поставщик Бх — это Смит, деталь Рт — это разводной гаечный ключ, а проект )г — это Манхэттенский проект. Такие ложные выводы называются ловушкой соединения (соппесз!оп !гар). 2. На схеме также есть одна связь (РР), которая связывает один тип сущности (Раста) с самим собой.
Эта связь означает, что одни детали содержат другие детали как собственные компоненты (так называемая связь спецификации материалов). Например, винт — это компонент шарнира, который тоже рассматривается как деталь и, в свою очередь, может быть компонентом какой-либо более сложной детали, например колпака. Обратите внимание, что эта связь также бинарная; просто она связывает две сущности совпадающего типа (в данном случае — сущность Рагдв), 3.
Вообще говоря, для заданного набора типов сущностей может существовать любое количество связей. В представленной на рис. !.5 диаграмме присутствуют две различные связи между сущностями Рго)ес1в и Епр1оуеев; первая (ЕЛ) представляет тот факт, что служащие заняты в проектах, а вторая (ИЮ) — что служащие управляют проектами. Теперь мы убедились, что связь можно понимать как сущность особого типа.
Если сущность определена как "нечто, о чем необходимо записывать информацию", то понятие связи вполне подходит под такое определение. Например, связь "деталь 'Р4' хранится иа складе 'я3'" — это сущность, о которой может потребоваться записать некоторую информацию, например соответствующее количество указанных деталей. Более того, сушествуют некоторые преимушества (их описание выходит за рамки этой главы) в том, что мы не делаем излишних различий между сущностями и связями.
Поэтому в данной книге связи будут рассматриваться как особый тип сущности. Свойства Как мы только что отметили, сущность — это то, о чем необходимо записывать информацию. Отсюда следует, что сущности (а значит, и связи) имеют некоторые свойства (ргорегз!ез), соответствующие тем данным о них, которые мы желаем записать. Например, у поставщиков есть.место расположения, у деталей — вес, у проектов — порядок очередности выполнения, закрепление служащих за проектами имеет начальную дату и т.д. Именно эти свойства должны сохраняться в базе данных. Например, в базе данных может быть таблица Я, представляющая тип сущности "поставщики", а в этой таблице может присутствовать тип поля С1Тз (город), представляющий свойство "место расположения". В общем случае свойства могут быть как простыми, так и сложными, причем настолько, насколько это потребуется. Например, свойство "место расположения поставшика*' относительно простое: оно состоит только из названия города и может быть описано как простая символьная строка.
В противоположность этому сущность "склад" может иметь свойство "схема этажей" с достаточно сложной структурой, включающей архитектурный план здания, дополненный соответствующим текстовым описанием. На момент написания этой книги большинство существующих СУБД лишь недавно начали поддерживать работу со сложными свойствами, подобными изображениям с текстовым описанием. Мы еше возвратимся к данному вопросу позже в этой книге (в частности, в Глава 1. Базы Данных и управление цми 43 главе 5 и части Ч!), а пока в большинстве случаев (за исключением тех моментов, когда существуют отличия) будем предполагать, что все свойства являются простыми и их можно представить простыми типами данных: числами, строками, датами, отметками времени и т.п. Данные и модели данных Существует и другой, не менее важный, подход к пониманию данных и баз данных. Слово "ланные" (е!а!а) происходит от латинского слова "давать", откуда следует, что данные на самом деле являются заданными фактами, из которых можно логически получить другие факты.
(Получение дополнительных фактов из заданных фактов — зто в 'точности то, для чего используется СУБД, обслуживая запросы пользователя.) "Заданный факт", в свою очередь, соответствует тому, что в логике называется истинным высказыванием'. Например, высказывание "Поставщик с номером 'Я!' находится в Лондоне" вполне может быть таким истинным высказыванием. Отсюда следует, что база данных в действительности есть набор подобных истинных высказываний (1.2).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
