Файл: Базы данных УП.pdf

16

деталей

определения

данных

. 

Предоставляя

доступ

к

множест

-

ву

общих

данных

и

поддерживая

мощные

языки

управления

данными

, 

информационные

системы

, 

использующие

базы

дан

-

ных

, 

позволяют

значительно

сократить

объем

работ

по

соз

-

данию

и

поддержке

программного

обеспечения

. 

1.5. 

Информационные

системы

, 

использующие

базы

данных

Информационные

системы

, 

использующие

базы

данных

, 

по

-

зволили

преодолеть

ограничения

файловых

систем

. 

Поддерживая

целостную

, 

централизованную

структуру

данных

, 

информацион

-

ные

системы

, 

использующие

базы

данных

, 

позволили

избавиться

от

проблем

избыточности

и

слабого

контроля

данных

. 

Доступ

к

централизованной

базе

данных

имеет

вся

компания

, 

и

если

, 

на

-

пример

, 

необходимо

внести

изменение

в

имя

клиента

, 

это

измене

-

ние

будет

известно

всем

пользователям

. 

Данные

контролируются

посредством

словаря

/

каталога

данных

 (data dictionary/directory, 

DD/D), 

которым

, 

в

свою

очередь

, 

управляет

группа

сотрудников

компании

, 

называемых

администраторами

базы

данных

 (

АБД

). 

Но

-

вые

методы

обращения

к

данным

сильно

упростили

процесс

свя

-

зывания

элементов

данных

, 

что

привело

к

расширению

возможно

-

стей

работы

с

данными

. 

Все

эти

характеристики

систем

управле

-

ния

базами

данных

упрощают

процесс

программирования

и

уменьшают

необходимость

программной

поддержки

. 

В

настоящее

время

процесс

создания

максимально

мощных

систем

управления

базами

данных

идет

полным

ходом

. 

За

не

-

сколько

десятилетий

последовательно

появлялись

системы

, 

ос

-

нованные

на

трех

базовых

моделях

данных

, 

или

концептуаль

-

ных

методах

структурирования

данных

: 

иерархическая

, 

сетевая

и

реляционная

. 

1.6. 

Иерархические

и

сетевые

модели

систем

Индексно

-

последовательные

файлы

решили

проблему

пря

-

мого

обращения

к

определенной

записи

в

файле

. 

Для

примера

посмотрим

снова

на

рис

. 1.2. 

Если

мы

прочли

первую

запись

о

продажах

в

файле

 SALE 

и

хотим

узнать

имя

и

адрес

клиента

, 

с

которым

была

заключена

эта

сделка

, 

мы

можем

просто

восполь

-

зоваться

идентификатором

клиента

 (100), 

чтобы

посмотреть

со

-

ответствующую

запись

в

файле

 CUSTOMER. 

Таким

образом

, 

мы

выясним

, 

что

заказ

был

сделан

компанией

братьев

Уотэйб

. 

Теперь

предположим

, 

что

нам

требуется

обратный

процесс

. 

Вместо

того

чтобы

выяснять

, 

с

каким

клиентом

заключена

сделка

, 

17

мы

хотим

найти

все

продажи

данному

клиенту

. 

Мы

начнем

с

записи

«

Братья

Уотэйб

» 

в

файле

 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, 

имеющие

иерархическую

структуру

18

На

рис

. 1.8 

показано

, 

как

выглядит

иерархия

отношений

меж

-

ду

клиентами

, 

счетами

и

строками

счетов

. 

Клиенту

 «

подчинены

» 

счета

, 

которым

, 

в

свою

очередь

, «

подчинены

» 

строки

. 

В

иерар

-

хической

базе

данных

эти

три

файла

будут

связаны

между

со

-

бой

физическими

указателями

, 

или

полями

данных

, 

добавлен

-

ными

к

отдельным

записям

. 

Указатель

−

это

физический

адрес

, 

означающий

, 

где

запись

находится

на

диске

. 

Каждая

запись

о

клиенте

будет

содержать

указатель

первой

записи

счета

этого

клиента

. 

В

свою

очередь

, 

записи

счетов

будут

содержать

указа

-

тели

на

другие

записи

счетов

и

на

записи

строк

счетов

. 

Таким

образом

, 

система

легко

сможет

извлечь

все

записи

счетов

и

строк

счетов

, 

относящихся

к

данному

клиенту

. 

Указатель

−

физический

адрес

, 

обозначающий

место

хранения

записи

на

диске

. 

Предположим

, 

что

мы

хотим

добавить

в

нашу

иерархическую

базу

данных

информацию

о

клиентах

. 

Например

, 

если

наши

клиенты

−

торговые

компании

, 

нам

может

понадобиться

список

магазинов

каждой

компании

. 

В

этом

случае

мы

расширим

диа

-

грамму

, 

приведенную

на

рис

. 1.8, 

придав

ей

вид

, 

представлен

-

ный

на

рис

. 1.9. 

Файл

 CUSTOMER 

по

-

прежнему

находится

над

файлом

 INVOICE, 

который

находится

над

файлом

 INVOICE 

LINE. 

Но

в

то

же

время

с

файлом

 CUSTOMER 

связан

файл

STORE (

МАГАЗИН

), 

а

с

ним

 — 

файл

 CONTACT (

ПРЕДСТАВИ

-

ТЕЛЬ

). 

Под

представителем

мы

подразумеваем

закупщика

, 

ко

-

торому

продаем

товары

для

конкретного

магазина

. 

Из

этой

диа

-

граммы

мы

видим

, 

что

клиент

является

вершиной

иерархии

, 

из

которой

мы

можем

извлечь

немало

информации

. 

Рис

. 1.8. 

Иерархическая

модель

отношений

между

файлами

CUSTOMER, INVOICE 

и

 INVOICE LINE 

CUS-

TOMER 

INVOICE 

INVOICE 

LINE 

19

На

этих

диаграммах

показаны

те

разновидности

связей

меж

-

ду

файлами

, 

которые

могут

быть

легко

реализованы

в

иерархи

-

ческой

модели

. 

Однако

быстро

стало

ясно

, 

что

у

такой

модели

есть

некоторые

существенные

ограничения

, 

поскольку

не

все

отношения

можно

представить

в

виде

иерархии

. 

Например

, 

вер

-

немся

к

нашему

примеру

и

сделаем

следующий

шаг

. 

Очевидно

, 

что

нас

могут

интересовать

связи

не

только

между

клиентами

и

счетами

, 

но

и

между

торговыми

агентами

и

счетами

. 

То

есть

мы

хотим

иметь

список

всех

счетов

на

продажи

, 

произведенные

оп

-

ределенным

торговым

агентом

, 

чтобы

подсчитать

сумму

причи

-

тающихся

ему

комиссионных

. 

Новые

связи

представлены

на

рис

. 1.10. 

Рис

. 1.9. 

Иерархическая

модель

отношений

между

файлами

CUSTOMER, INVOICE 

и

 STORE 

Однако

эта

диаграмма

не

является

иерархической

. 

В

иерар

-

хии

у

каждого

потомка

может

быть

только

один

предок

. 

На

рис

. 1.9 INVOICE 

−

потомок

, CUSTOMER 

−

его

предок

. 

Однако

на

рис

. 1.10 

у

 INVOICE 

имеется

два

предка

−

 SALES-

REPRESENTATIVE 

и

 CUSTOMER. 

Такого

рода

диаграммы

на

-

зываются

сетевыми

. 

В

связи

с

очевидной

необходимостью

об

-

рабатывать

такие

отношения

в

конце

шестидесятых

появились

сетевые

системы

управления

базами

данных

. 

Как

и

в

иерархи

-

ческих

, 

в

сетевых

системах

баз

данных

для

связывания

файлов

использовались

физические

указатели

. 

CUSTOMER 

INVOICE 

INVOICE LINE 

STORE 

CONTACT 

20

Рис

. 1.10. 

Сетевая

модель

отношений

между

файлами

SALESREP, CUSTOMER 

и

 INVOICE 

Потомок

−

подчиненная

запись

в

иерархии

. 

Предок

−

подчиняющая

запись

в

иерархии

. 

Сеть

−

отношения

между

данными

, 

когда

каждая

под

-

чинена

записям

более

, 

чем

из

одного

файла

. 

Основная

иерархическая

СУБД

−

система

 IMS 

фирмы

 IBM, 

созданная

в

середине

шестидесятых

годов

. 

В

конце

шестидеся

-

тых

−

начале

семидесятых

были

созданы

и

завоевали

рынок

несколько

сетевых

СУБД

; 

стандартом

для

такой

модели

, 

в

конце

концов

, 

стал

 CODASYL. 

В

последующих

главах

мы

обсудим

обе

эти

модели

данных

, 

требуемые

для

них

определения

данных

и

возможности

управления

данными

. 

1.7. 

Реляционные

системы

управления

базами

данных

Использование

физических

указателей

было

одновременно

и

сильной

, 

и

слабой

стороной

иерархических

и

сетевых

систем

управления

базами

данных

. 

Сильной

, 

поскольку

они

позволяли

извлекать

данные

, 

связанные

определенными

отношениями

. 

Слабой

, 

поскольку

эти

отношения

должны

быть

определены

до

запуска

системы

. 

Извлечь

данные

на

основе

других

отношений

было

сложно

, 

если

вообще

возможно

. 

CUSTOMER 

INVOICE 

INVOICE LINE 

STORE 

CONTACT 

SALESREP