39

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

1.5. Информационные системы, использующие базы данных

Информационные системы, использующие базы данных, позволили пре­одолеть ограничения файловых систем. Поддерживая целостную, централи­зованную структуру данных, информационные системы, использующие базы данных, позволили избавиться от проблем избыточности и слабого контроля данных. Доступ к централизованной базе данных имеет вся компания, и если, например, необходимо внести изменение в имя клиента, это изменение будет известно всем пользователям. Данные контролируются посредством словаря/каталога данных (data dictionary/directory, DD/D), которым, в свою очередь, управляет группа сотрудников компании, называемых администра­торами базы данных (АБД). Новые методы обращения к данным сильно уп­ростили процесс связывания элементов данных, что привело к расширению возможностей работы с данными. Все эти характеристики систем управления базами данных упрощают процесс программирования и уменьшают необходимость программной поддержки.

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

1.6. Иерархические и сетевые модели систем

Индексно-последовательные файлы решили проблему прямого обраще­ния к определенной записи в файле. Для примера посмотрим снова на рис. 1.2. Если мы прочли первую запись о продажах в файле SALE и хотим узнать имя и адрес клиента, с которым была заключена эта сделка, мы можем просто воспользоваться идентификатором клиента (100), чтобы посмотреть соответствующую запись в файле CUSTOMER. Таким образом, мы выясним, что заказ был сделан компанией братьев Уотэйб.

Теперь предположим, что нам требуется обратный процесс. Вместо того чтобы выяснять, с каким клиентом заключена сделка, мы хотим найти все продажи данному клиенту. Мы начнем с записи «Братья Уотэйб» в файле CUSTOMER, а затем найдем все продажи этой компании. В файловой сис­теме мы не сможем напрямую получить ответ на наш вопрос. Именно для подобных прикладных задач и были придуманы системы управления базами данных.

Первая информационная система, использующая базы данных, появив­шаяся в середине шестидесятых годов, была основана на иерархической мо­дели, что означает, что отношения между данными имеют иерархическую структуру. Для того чтобы пояснить это, слегка изменим базу данных, при­веденную на рис. 1.2. Вместо продаж, записанных в виде одной строки, у нас будут счета-фактуры, которые, в свою очередь, состоят из нескольких строк. К каждому клиенту может относиться несколько таких счетов, и ка­ждый счет может состоять из нескольких строк. Каждая строка обозначает продажу одного товара. На рис. 1.7 представлен пример. Теперь вместо файла SALE у нас есть файлы INVOICE (СЧЕТ) и INVOICE LINE (СТРОКА-СЧЕТА).

Иерархическая модельмодель данных, в которой связи между данными имеют вид иерархий.

CUSTOMER
CUST-ID	CUST-NAME		ADDRESS		COUNTRY		BALANCE
100 101 105 110	Уотэйб Мальтц Джефф Гомес		П/я 241 П/я 102 П/я 98 П/я 76		Япония Австрия США Чили		45 551 75 314 49 333 27 400
INVOICE
INVOICE-#		ДАТА		CUST-ID			SALREP-ID
1012 1015 1020		10.02 14.02 20.02		100 110 100			39 37 14
INVOICE LINE
INVOICE-#		LINE-#		PROD-ID		QTY	TOTAL-PRICE
1012 1012 1012 1015 1015 1020 1020		01 02 03 01 02 01 02		1035 2241 2518 1035 2518 2241 2518		100 200 300 150 200 10 150	2200.00 6650.00 6360.00 3300.00 4240.00 3325.00 3180.00

Рис. 1.7. Файлы IPD, имеющие иерархическую структуру

На рис. 1.8 показано, как выглядит иерархия отношений между клиен­тами, счетами и строками счетов. Клиенту «подчинены» счета, которым, в свою очередь, «подчинены» строки. В иерархической базе данных эти три файла будут связаны между собой физическими указателями, или полями данных, добавленными к отдельным записям. Указатель это физический адрес, означающий, где запись находится на диске. Каждая запись о клиенте будет содержать указатель первой записи счета этого клиента. В свою очередь, записи счетов будут содержать указатели на другие записи счетов и на записи строк счетов. Таким образом, система легко сможет извлечь все записи счетов и строк счетов, относящихся к данному клиенту.

Указательфизический адрес, обозначающий место хранения записи на диске.

Предположим, что мы хотим добавить в нашу иерархическую базу дан­ных информацию о клиентах. Например, если наши клиенты торговые компании, нам может понадобиться список магазинов каждой компании. В этом случае мы расширим диаграмму, приведенную на рис. 1.8, придав ей вид, представленный на рис. 1.9. Файл CUSTOMER по-прежнему находится над файлом INVOICE, который находится над файлом INVOICE LINE. Но в то же время с файлом CUSTOMER связан файл STORE (МАГАЗИН), а с ним — файл CONTACT (ПРЕДСТАВИТЕЛЬ). Под представителем мы подразумеваем закупщика, которому продаем товары для конкретного магазина. Из этой диаграммы мы видим, что клиент является вершиной иерархии, из ко­торой мы можем извлечь немало информации.

Рис. 1.8. Иерархическая модель отношений между файлами CUSTOMER, INVOICE и INVOICE LINE

На этих диаграммах показаны те разновидности связей между файлами, которые могут быть легко реализованы в иерархической модели. Однако бы­стро стало ясно, что у такой модели есть некоторые существенные ограниче­ния, поскольку не все отношения можно представить в виде иерархии. На­пример, вернемся к нашему примеру и сделаем следующий шаг. Очевидно, что нас могут интересовать связи не только между клиентами и счетами, но и между торговыми агентами и счетами. То есть мы хотим иметь список всех счетов на продажи, произведенные определенным торговым агентом, чтобы подсчитать сумму причитающихся ему комиссионных. Новые связи представлены на рис. 1.10.

Рис. 1.9. Иерархическая модель отношений между файлами CUSTOMER, INVOICE и STORE

Однако эта диаграмма не является иерархической. В иерархии у каж­дого потомка может быть только один предок. На рис. 1.9 INVOICE по­томок, CUSTOMERего предок. Однако на рис. 1.10 у INVOICE имеется два предкаSALES-REPRESENTATIVE и CUSTOMER. Такого рода диа­граммы называются сетевыми. В связи с очевидной необходимостью обраба­тывать такие отношения в конце шестидесятых появились сетевые системы управления базами данных. Как и в иерархических, в сетевых системах баз данных для связывания файлов использовались физические указатели.

Рис. 1.10. Сетевая модель отношений между файлами SALESREP, CUSTOMER и INVOICE

Потомокподчиненная запись в иерархии.

Предокподчиняющая запись в иерархии.

Сетьотношения между данными, когда каждая подчинена записям более, чем из одного файла.

Основная иерархическая СУБД система IMS фирмы IBM, созданная в середине шестидесятых годов. В конце шестидесятыхначале семидесятых были созданы и завоевали рынок несколько сетевых СУБД; стандартом для такой модели, в конце концов, стал CODASYL. В последующих главах мы обсудим обе эти модели данных, требуемые для них определения данных и возможности управления данными.