Базы данных [Борис Яковлевич Советов] (pdf) читать онлайн

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ ЭЛЕКТРОТЕХНИЧЕСКИЙ
УНИВЕРСИТЕТ «ЛЭТИ» ИМ. В. И. УЛЬЯНОВА (ЛЕНИНА)

Á. ß. Ñîâåòîâ, Â. Â. Öåõàíîâñêèé, Â. Ä. ×åðòîâñêîé

ÁÀÇÛ ÄÀÍÍÛÕ
Ó×ÅÁÍÈÊ ÄËß ÏÐÈÊËÀÄÍÎÃÎ ÁÀÊÀËÀÂÐÈÀÒÀ
2-å èçäàíèå
Ðåêîìåíäîâàíî Ó÷åáíî-ìåòîäè÷åñêèì îòäåëîì âûñøåãî
îáðàçîâàíèÿ â êà÷åñòâå ó÷åáíèêà äëÿ ñòóäåíòîâ âûñøèõ
ó÷åáíûõ çàâåäåíèé, îáó÷àþùèõñÿ ïî èíæåíåðíî-òåõíè÷åñêèì
íàïðàâëåíèÿì è ñïåöèàëüíîñòÿì
Ðåêîìåíäîâàíî Ó÷åáíî-ìåòîäè÷åñêèì îáúåäèíåíèåì âóçîâ
ïî óíèâåðñèòåòñêîìó ïîëèòåõíè÷åñêîìó
îáðàçîâàíèþ â êà÷åñòâå ó÷åáíèêà äëÿ ñòóäåíòîâ
âóçîâ, îáó÷àþùèõñÿ ïî íàïðàâëåíèÿì
«Èíôîðìàòèêà è âû÷èñëèòåëüíàÿ òåõíèêà»
è «Èíôîðìàöèîííûå ñèñòåìû»
Êíèãà äîñòóïíà â ýëåêòðîííîé áèáëèîòå÷íîé ñèñòåìå
biblio-online.ru

Ìîñêâà Þðàéò 2015

УДК 002.52
ББК 32.81я73
С56
Рецензент:
Игнатьев М. Б. — доктор технических наук, профессор Санкт-Петербургского государственного университета аэрокосмического приборостроения,
лауреат Государственной премии РФ, заслуженный деятель науки и техники РФ.
С56

Советов, Б. Я.
Базы данных : учебник для прикладного бакалавриата / Б. Я. Советов,
В. В. Цехановский, В. Д. Чертовской. — 2-е изд. — М. : Издательство Юрайт,
2015. — 463 с. — Серия : Бакалавр. Прикладной курс.
ISBN 978-5-9916-4685-7
В работе изложены вопросы построения и использования технологии баз
данных в процессе выработки и принятия решений.
Рассмотрены как устоявшиеся теоретические вопросы, так и новые аспекты,
мало или несистемно отраженные в отечественной и переводной литературе.
Это относится к локальным, распределенным и объектно-ориентированным
базам данных, хранилищам данных. Подробно проанализирован режим
«клиент — сервер», в том числе в удаленном варианте.
Учебник отличается системным рассмотрением теоретических вопросов,
которые сопровождаются компьютерной реализацией. Это позволяет лучше
понять процедуры построения, работы и использования баз данных.
Соответствует актуальным требованиям Федерального государственного
образовательного стандарта высшего образования.
Для студентов вузов, обучающихся по направлениям «Информатика
и вычислительная техника» и «Информационные системы». Представляет
несомненный интерес для разработчиков и пользователей баз данных, преподавателей и научных сотрудников, сферой деятельности которых является
технология хранения и использования данных; менеджеров и руководителей
различного ранга, желающих самостоятельно ознакомиться с современным состоянием технологии баз данных.
УДК 002.52
ББК 32.81я73

ISBN 978-5-9916-4685-7

© Советов Б. Я., Цехановский В. В.,
Чертовской В. Д., 2005
© ООО «Издательство Юрайт», 2015

Глава

1

Общие сведения
Показана «табличная» суть базы данных на при мере процесса автома­
тизации табличных расчетов. Введены необходимые понятия и определе­

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

1.1.

БАЗА ДАННЫХ

И АВТОМАТИЗАЦИЯ ТАБЛИЧНЫХ РАСЧЕТОВ

Считается, что понS\тие «база данных» (БД), а тем более

-

«систе­

ма управления базами данных» (СУБД) достаточно сложно в усвоении.

Оно значительно упрощается, если понять «физическую сущность»
процессов, происходящих в изучаемом программном продукте.

Следует помнить, что многие программные продукты являются
средством автоматизации соответствующих ручных процедур, кото­

рые просты в понимании. В частности, база данных (при так назы­
ваемом традиционном подходе к проектированию) служит инстру­
ментом

автоматизации

расчетов,

в

которых

входные

и

выходные

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

Подтвердим сказанное простым конкретным примером. Начнем
с ручного расчета.

Пример

1.1.

ЗадаJlие. Имеется склад материалов (М 1, М2, М3), снабжающий
производство, выпускающее изделия И

12

1,

И2. Каждое из изделий

состоит из деталей Д 1, Д2 и ДЗ, количество которых в изделиях

(входимость) известно. Известны и нормы расхода материалов на

каждую деталь. Задан

- на протяжении месяца - ежедневный план

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

Длительность технологического цикла (производства) изделий

3 дня.

td

-

Рекомендуется создать страховой запас материалов на складе

на один день. Склад периодически заказывает материалы постав­

щикам. Время т выполнения заказа r по первому и третьему матери­
алам

- 2 дня,

по второму

1 день.

-

Поставки материалов произво­

дятся по первому и третьему материалам

второму

-

-

каждый третий день, по

каждый четвертый день.

Необходимо ежедневно на протяжении месяца определить (решить задачи):

1)
2)
3)
4)

запуск материалов под план производства;
заказы на материалы;
поставки материалов;
движение материалов на складе по дням.

Исходные данные получены из различных источников.
Решение. Поскольку исходные данные получены из разных ис­
точников, целесообразно упорядочить их в табличной форме. Вид
таблиц может быть различным.
Пусть данные упорядочены в виде системы таблиц: «Материа­
лы»), «Детали»), «Изделия»), «Нормы» (расхода), «Входимость», «План»

(выпуска изделий) (табл.

1.1-1.6).
Таблица

1.1

Материалы
Шифр маТСРI1'UШ

На3ВiJIIИС материала

[ЛlllllНLа IПМСРСIIИЯ

М!

СтаЛl,

KI'

М2

Чугун

кг

МЗ

Жслезо

кг

Таблица
Детали
ШифРДСnUlII

НазнаllИС ЛСТ,tЛИ

[Дl1l1ина И]МСРСIIН~

Д!

Втулка

IlIТ.

Д2

ФлаНСIl

ШТ.

ДЗ

ПалС'(

11/1'.

13

1.2

Таблица

1.3

Изделие
Шифр юдели}(

Н(:tИМСIЮВalIИС излслия

ЕДИllица измерения

ИI

Изделие

I

ШТ.

И2

Изделие

2

ШТ.

Таблица

1.4

Нормы
Шифр материала

Шифр ДС·I,UlИ

Единица измерения

Норма расхода

М\

Д\

кг/шт

2,\

М\

д2

кг/шт

\,8

М2

Д\

кг/шт

3,4

М2

ДЗ

кг/шт

4,3

М3

Д2

кг/шт

\ ,5

М3

ДЗ

кг/шт

3,7
Таблица

1.5

Входимость
ШифрдеТШIИ

Шифр издеJ/ИЯ

ЕдИllица измерения

КОЛИ'lесnю

Д\

И\

шт/изд

7

д2

И\

шт/изд

9

д2

И2

шт/изд

8

д3

И2

шт/изд

5
Таблица

План
дата

Шифр изделия

КОЛИ'lесТlIO изделий

\

И\

7

2

И\

\\

3

И\

8

4

И\

9

14

1.6

Продол.жеlluе табл.
Д~Ta

Шифр изделия

КОJlI!'IССПЮ I1Jлс}/иii

5

ИI

12

6

И\

\3

7

ИI

9

8

ИI

Х

9

ИI

7

10

И\

9

\1

ИI

14

12

ИI

I1

13

ИI

8

14

ИI

4

15

ИI

7

16

ИI

5

17

ИI

8

18

ИI

9

19

ИI

10

20

ИI

14

21

ИI

17

22

ИI

12

23

ИI

II

24

ИI

10

25

ИI

8

I

И2

5

2

и2

12

3

И2

8

4

и2

7

15

1.6

Продолжеllие табл.

дата

Шифр изделия

КОЛИ'IССТRО ИЗЛ:СJlИЙ

5

И2

4

6

И2

3

7

и2

15

R

И2

4

9

И2

8

10

и2

7

11

и2

4

12

и2

20

13

и2

25

14

и2

14

15

И2

11

16

И2

10

17

и2

15

1Х

и2

5

19

И2

7

20

и2

10

21

И2

8

22

И2

4

23

и2

12

24

и2

15

25

и2

IR

1.6

Структура (совокупность элементов и их связей) приведенных
таблиц является линейной.

Однако система исходных таблиц может быть представлена ина­
че. Например, вместо таблиц «Детали» и «Нормы» может быть пост­
роена одна таблица «Детали-Нормы» (табл.

16

1.7).

Таблица

1.7

Детали-Нормы

1/ ОРМ"
ШllфРНСТi

f<

м

r
~

М

N

з,
)j

Кафедра

N

Предмет

8)

t

1

Кафедра

м

Рис.
а

-

3.4.

Модель БД "Учебный процесс»:

исходная структура; б

начертании, чем на рис.

-

промеЖУТО'lНая структура; i/ -

3.3)

он может быть представлен в виде

отношений трех групп атрибутов (рис.

I:M.

Поскольку группы

вить в виде рис.

3.4,

результат

1и 3-

3.4,

а) со связями

M:N

и

множества, схему можно предста­

б. Известно, что ни одна модель данных не

может реализовать отношения

M:N.

В связи с этим схема связей

после преобразования окончательно выглядит, как показано на рис.

З.4, в.
Заметим, что перечисленные методы обладают следующими не­
достатками:

•

слабо ориентированы на использование компьютеров в проек­

тировании БД;

71

•

оперируют со статическими (неизменными) данными, тогда

как в реальных системах управления используются динамические

данные (потоки данных);

•

отражают потоки данных не системно.

Названные недостатки устранены в САSЕ-технологии

[25J.

3.2. CASE- ТЕХНОЛОГИЯ
Для решения задачи автоматизации управления в АСУ возникла
необходимость в системном описании процесс а управления, вклю­
чая и принятие решений. Одним из первых моделей в этом направ­

лении были так называемые форрестеровские модели. Позднее по­

явилась методология автоматизации (Structures Analysis Design
на основе которой построена САSЕ-технология .

Technique) SADT,

Модельными компонентами САSЕ-технологии (рис.
ются составляющие

ERD, DFD, STD.

3.5)

явля­

Их место в системном описа­

нии процесса управления показано на рис.

3.6.

САSЕ-технология представляет собой систему методов описа­

ния, рассчитанную на использование компьютеров при создании БД.

Computer-Aided Software/System Engineering

(САSЕ-технология)

Диаграмма
Несси- Шнейдера

Структур- Структур- Структурный
ный сис- ный анаанализ

темный

лиз и тех-

и проекти- анализ

ника

рование

проектирования

Рис.
А

-

3.5.

Классификация САSЕ-методов:

элементов много; Б

- описание элементов; УЧ - учебный процесс;
DFD - Data Flow Diagram; ERD - ЕпШу Relationship Diagram;
STD - State Transaction Diagram

72

-

Управляющий
процесс

STD
r--------------- 1 ---------------,

I.

Элемент

1

DFD
(структура)

I

Поток

.

данных

I

Словарь
данных

I

I Хранилище f----I Элемент 2

I
I

Спецификация
процесса

ERD

Управляемый процесс (объект управления)

Рис.

3.6.

Описание процесса в системе

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

CASE -

комплексом

взаимосвязанных

средств

автоматизации.

инструмент для системных аналитиков, разработчиков и

программистов.

САSЕ-технология базируется на методологии системного анали­
за. Под системным анализом понимают научную дисциплину, раз­

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

-

сосредоточить внимание на начальных этапах разработки.

В рамках САSЕ-технологии системный анализ предназначен для
отделения проектирования от программирования. В разработке в
соответствии с САSЕ-технологией выделяется построение архитек­
туры и ее последующая реализация, поэтому системный анализ на­
зывают структурным системным анализом или просто структурным
анализом.

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

1.

Принцип абстрагирования от несущественных деталей (с их

«упрятыванием») С контролем на присутствие лишних элементов.

2.
3.

Принцип формализации.
Принцип концептуальной общности (структурный анализ

структурное программирование

-

-

структурное тестирование). От­

сюда методология структурного анализа

-

метод исследования от

общего обзора через детализацию к иерархической структуре со все

большим числом уровней.

73

4.

Принцип непротиворечивости

-

обоснование и согласован­

ность элементов.

5.

Принцип логической и физической независимости данных.

6.

Принцип непосредственного доступа (без программирования)

конечного пользователя.

Эта технология положена в основу реализации программных

CAS Е-средств.
Формальным инструментом описания является система диаграмм
(см. рис.

3.5):

ЕR-диаграмм

(ERD), диаграмм потоков данных (DFD),
(STD), спецификация процесса, ко­

диаграмм переходов состояний
торые обсудим отдельно.

В описании процессов возможны два случая: сложные и про­

стые процессы. Во втором случае разработку БД удобнее вести с
использованием понятия «отношение». Рассмотрим поэтому только

сложные процессы, учитывая, что САSЕ-технология для него и разрабатывалась.
.

ЕR-диаграммы. Из рис. 3.6 видно, фактически первой разновид­
ностью методов системы САSЕ-моделей явились ЕR-модели Чена,
подробно рассмотренные в предыдущем параграфе. Здесь отметим
лишь ее разновидность - модель Баркера (рис. 3.7). В ней указыва­
ется имя сущности, степень множественности (например, l~M), обязательность

или необязательность

(---)

( ........... )

связи.

DF-диаграмма. Диаграммы при меняются для отображения про­
цессов вход-выход. Первоначально использовалась методология

SADT,

о которой говорилось ранее, затем перешли на схемы

DFD.

Применяются две основные разновидности нотаций: Иордана-Де­
марко и ГеЙна-Сарсона. Различия между ними невелики и потому

используем нотацию ГеЙна-Сарсона. В нотации используются сим­
волы, снабженные именами.

ОРО строится на основе декомпозиции и модель верхнего уров­
ня называют контекстной диаграммой. В любом конкретном проек­
те она одна. Такие модели описывают объект управления, а для от­

ражения управляющей части (УЧ) системы при меняют

[25]

расши-

Кредитная карточка

Принадлежатъ/ "

I Клиент !............................~
Владеть

l:М

Номер счета

ЛИМИТ денег
Код сортировки
Пароль

Рис. З. 7. Модель нотации Баркера

74

Среда

(претенденты)
Уволившиеся

Претенденты

Фирма
(компания)

Непринятые

t

I Среда I
Рис.

Контекстная диаграмма процесса приема на работу

3.8.

рение реального времени: перечисленные условные обозначения
рисуются пунктирными линиями или точками. Основными типами

управляющих потоков являются Т-поток (триггер), А-поток (про­
цесс непрерывен, пока поток не выключится), Е/D-поток (аналог
выключателя с двумя кнопками «включено» И «выключено»).

Иллюстрацию проведем на основе процесса приема на работу,
описанного в примере

2.2.

Контекстная диаграмма Гейна-Сарсона представлена на рис.

3.8:

она позволяет видеть входные и выходные потоки и внешние сущно­

сти (источники и/или приемники данных) «3аказчиК» и «Производи­
тель». Детализированная диаграмма рассматриваемого процесса мо­
жет быть представлена в виде, показанном на рис.

3.9

с процессами

Среда

Претенденты

Просмотр
штатного
расписания,
данных
претендентов

3
ринимаемые Просмотр

рекомендаций

Рис .

3.9. Детализированная

Н'при 'В
.......

диаграмма процесса приема на работу

75

Начало
просмотра

- - - - - - -,

г

.,. ____ _

,

Начало отбора

: ~KOHeц- - ~ - - - - - - :-< - - - -, Фиксация увольнения

Среда

1 1просмотра 1Управление 1- - - - -: - - - --,
Запуск п~!в~ приемом
I __ ~ 1
I

г -~I

I I

fкоиец,

,1
... - - - - - .,. отбора,
1 1Конец работы
1

11

Претенденты' ,

'

I~П~РLа~в~ил;=====~~г-~lГ~~==~~
'11

1 1
_._--L
..........

,'
11

Просмотр

11

штатного

h4,,==:-:--_tп

, I

расписания
данных

1 '

претендентов

,1

,1

11

l', : Прини­

маемые

1-----IПрИнИ-1 ,

·~3~_ _-1I+-t=-=-=-::::.__...

M~e~~e~ ,Просмотр
_____1

Рис.

1-5,

где БДl

3.10.

-

рекомеlЩаций

Непринятые

Среда

Расширенная диаграмма процесса приема на работу

данные или их часть, хранимые в памяти. В общем

случае каждый из процессов

1-3,

в свою очередь, может быть дета­

лизирован. Расширенная диаграмма отображена на рис.

3.10.

Частный случай алгоритма выработки решений, когда число ва­

кансий превышает количество принимаемых, показан на рис.
Рис.

3.8-3.11

3.11.

позволяют заметить, что потоки имеют поясне­

ния. Текстовые средства моделирования получили название словаря
данных.

8Т -диаграмма. Она используется для отображения процесса вы­

работки и результатов реализации решений. Вводится понятие «со­
стояние». Схематика (схема переходов) для блока «Правила» (рис.

3.11)

может быть такой, как показано на рис.

3.12.

Процесс измене­

ния состояния может быть отражен с помощью таблицы (табл.
или матрицы (табл. 3.3).

3.2)

После рассмотрения деталей САSЕ-технологии вернемся к сис­
темному аспекту. САSЕ-технологии могут быть классифицированы
по нескольким признакам.

1. По шкалам - Software Engineering (SE) и Information Engineering
(IE). Первая шкала предназначена для проектирования программ­
ного обеспечения и хорошо известна (фактически описана в данной
работе), вторая

-

новая, с более широкой областью применения

(для проектирования не только программного обеспечения).

76

Правила

Да

Нет

I

I
I

{-----------------------------------------~

Рис.
В

3.11.

Система правил приема на работу в научное учреждение:

G - вакансия; Н - претенденты на вакантные должности; А - принимаемый сделал открытие; С - средний балл учебы; D -

ученая степень;
опыт работы. лет

б)

а)

~Принимаемыеl~
Orказать

Тl:Пр'авила

Условия

3.12. STD
а

ТS:Правило

1

~ Претенденты ~

Действие

Рис.

Orказать

ДIIЯ процесса принятия на работу:
общая схема; б

-

5

-

при мер

Таблица

3.2

Таблица решений
Текущее СОСТОSlllие

УСЛОRие

Н~'lалЫlOе СОСТОЯllие

в II~Чалс ~ждого

действие

Активизируется

Следующее
состояние

ССЮlса

Претендент

Правило

I

Претендент

Правило

2

Претендент

Правило

3

Претендент

Правило

4

Претендент

Правило

5

2.

Отказать
Научный
сотрудник

Инженерконструктор

Инженер по
эксплуатации

Отказать

Принимаемый

Принимаемый

Принимаемый

Принимаемый

Принимаемый

По порядку построения модели: а) процедурно-ориентиро­

ванный (современный подход); б) ориентированный на данные (тра­
диционный подход).

3.

По типу целевых систем

-

для систем реального времени (уп­

равление сложными структурами большого объема данных с интен­

сивным вводом-выводом) и информационных систем (управление
событиями с малым количеством простых по структуре данных с
интенсивными вычислениями).

3.3.

САSЕ-СРЕДСТВА

САSЕ-технология поддерживается, как уже указывалось,

CASE-

средствами. Интегрированный пакет САSЕ-средств содержит четы­
ре основных компонента.

78

Таблица з.з
Матрица реwений
Состояние

Начальное
состояние

Условие
Активизируется

Правило

1

Правило

2

Правило

3

Правило

4

Правило

5

в начале каЖдОГО

сеанса

Отказать
Претендент

Принимаемый
Научный

Претендент

СОТРУДНИК

Принимаемый
Инженер-

Претендент

конструктор

I

Принимаемый

I

Инженер по

Претендент

эксплуатации

I

Принимаемый

Отказать
Претендент
Принимаемый
~--

-

1.

Средства централизованного хранения информации о всем

проекте (своеобразная база данных проекта).

2.
3.
4.

Средства ввода данных ДЛЯ хранения.

Средства анализа, проектирования и разработки.
Средства вывода.

для САSЕ-технологии характерны четыре основных типа графических диаграмм:

1) функциональное проектирование

2)
3)
4)

(DFD);

моделирование данных

(ERD);
моделирование поведения (STD);
структурные диаграммы (карты) -

отношения между модуля­

ми и внутримодульная структура.

САSЕ-средства (прежде всего фирмы

Oracle

и отдельных орга­

низаций) возможно классифицировать по категориям и по функци­
ональному признаку.

1.

По категориям. Выделяют уровень интеграции: вспомогатель­

ные программы

(tools); пакеты (toolkit); инструментальные средства
(workbench, АРМ).
2. По функциональному признаку. Для анализа и проектирования
возможно использовать САSЕ-аналитик (единственное отечествен­
ное средство первого поколения),

Application Development Workbench,

Easy CASE System Designer.
Проектирование БД существенно упрощается при применении

ERWin

(фирма

Logic Works), Designerj2000 (Oracle),

позволяющих

про водить логическое моделирование данных, автоматическое пре­

образование данных в 3НФ.

Программирование (кодогенерирование)

- DECACE (DEC), Del-

phi (Borland).
Сопровождение (поддержка системной документации) и реин­

жиниринг (анализ, корректировка, реинжиниринг существующей

системы)

- SuperStructure (Computer Data System).

Управление проектом (планирование, контроль, взаимодей­

ствие)

- Project Workbench (Applied Business Technology).

Рассмотрим одну из реальных систем автоматизации проектиро­
вания БД в рамках Oracle (Cooperative Development Environment CDE), в которую входят CASE*Dictionary, CASE*Designer, CASE*Generator.
CASE*Dictionary - хранилище информации (БД проекта).
CASE*Designer - средство моделирования процессов и данных в

системе через внешний интерфейс с помощью средств графическо­
го моделирования.

CASE*Designer полностью интегрирован с
CASE*Dictionary. CASE*Generator на основе информации CASE*De80

signer автоматически генерирует модули программного
формы, отчеты). CASE*Generator может генерировать

кода (меню,

и DLL-сце­

нарии (таблицы, представления, индексы, последовательности) в
схеме приложения.

Oracle7

был спроектирован с открытой архитектурой и потому

другие компании смогли создать дополняющие средства:

Application Development Workbench (разработка систем на мно­
- компания KnowledgeWare;
Easy CASE System Designer (графическое инструментальное сред­

гих платформах)

ство проектирования,

позволяющее

генерировать схемы

ния для одной или нескольких СУБД, включая

Oracle) -

приложе­

компания

Evergreen CASE Tools;
ERWinjERX (средство проектирования БД для MS Windows) компания Logic Works;
ADW - интегрированный набор средств для анализа, планиро­
вания и моделирования процессав, данных и автоматической гене­
рации приложений.

Несколько иначе выглядит теория реляционных баз данных.

Контрольные вопросы

\.
2.
3.

Какие модели представления даННblХ и знаний ВЬ! знаете?

Что такое САSЕ-технология?
Что такое ERD-, DFD-, SТD-составляюшие САSЕ-технологии? Укажите их

место в описании систеМbI.

4.
5.

б

- 4840

Какие Вам извеСТНbI методЬ!

ERD? DFD? STD?

Дайте классификацию САSЕ-технологий, CASE-среАств.

Глава

4

Теория реляционных БД
Использование компьютера для реализации какого-либо процесса воз­
можно лишь при наличии теоретического математического описания этого

процесса. Сказанное относится и к процессам в базах данных.

В теории реляционных баз данных выделяют представление процедур:
а) создания БД (с учетом целостности и защиты данных); б) использования
базы данных; в) функционирования БД, в том числе при многопользова­
тельском доступе к данным.

При строгом подходе рассмотрение третьей процедуры (как это
сделал Э. Кодц) является как бы автономным и не входит в теорию
реляционных БД. Однако, поскольку работа во все более широко ис­
пользуемом многопользовательском доступе к данным без теорети­
ческой проработки процедуры синхронизации невозможна, ее изуче­
ние также включим в теорию реляционных БД [4, 12].
Теоретические инструменты первых двух процедур

-

реляционная

алгебра и реляционное исчисление. Реляционная алгебра (РА) являет­
ся теоретической основой алгоритмических языков программирования,
сложных для

начинающего

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

тогда

как на

реляционном

исчислении (РИ) построены (см. § 1.1.) более удобные декларативные
языки программирования SQL и ОВЕ.
В то же время РА позволяет наглядно отобразить процессы преобра­
зования в базе данных одних таблиц в другие. Именно поэтому рассмотре­
ние теории начнем с реляционной алгебры.

4.1.

МАТЕМАТИЧЕСКИЕ ОСНОВЫ ТЕОРИИ

Полезно провести аналогию РА и школьного курса алгебры.
В последнем в качестве элементов априори вводятся буквы, а опе­
рации над ними

-

сложение, вычитание (прямые) и умножение,

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

ства, как коммутативность аЬ = Ьа, ассоциативность (аЬ)с = а(Ьс),
дистрибутивность (а

+ Ь)с = аЬ + Ьс,

идемпотентность а2

= а,

изуча­

ются в вузовском курсе высшей алгебры.

Сказанное можно отнести и к реляционной алгебре. Ее элемен­
тами служат таблицы, над столбцами и строками которых выполня-

82

ются девять операций

(§ 4.1.1.).

В то же время более глубокая фун­

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

§ 1.1.

ОСНОВЫ реляционной алгебры
Основные понятия. В основе реляционной БД лежит понятие
«отношение», «связы>.

Отношением r называется подмножество декартова произведе­
ния. Поля отношения (таблицы) могут располагаться в произволь­
ном порядке. Чтобы установить определенный порядок для какой­
R - множе­

либо конкретной реализации, вводят понятие «схема»

ство упорядоченных имен атрибутов R(A р ... , А п ). Говорят о схеме
R отношения r или r(R). Любому имени А. ставится в соответствие
множество D ,. (домен или dom(A .».
, CxeM~ - конечное множество
кортежей t Е r, при этом t(A.) = D ..
Парадигмой реляционны~ БД я'вляется ключ r отношения R подмножество К = {В р ... , Вт} R, m ~ n с ограничениями:
1) для любых двух кортежей t[ и t 2 существуют В Е К, такое, что

t.(B)

-:f. t 2 (В);

2) t.(K) -:f. t 2(K);
3) ни одно собственное

подмножество К' с К не обладает свой­

ством ключа.

Ключи, явно перечисленные вместе с реляционной схемой, на­
зываются явными; в противном случае

-

неявными. Один из выде­

ленных ключей называется nервичным. Если ключ К' с К с R, то К суперключ (составной ключ).
Возможен вариант [4], когда несколько минимальных множеств
атрибутов функционально определяют все атрибуты отношения.
Такие множества называют возможны.ми (альтернативными) ключа­
ми, поскольку любое из них можно выбрать в качестве составного
ключа.

Например, пусть имеется отношение

А(Город, Адрес, Почтовый_индекс).

Очевидно, что атрибуты: Город Адрес ~ Почтовый_индекс. В то
же время Почтовый_индекс ~ Город (хотя и не адрес). Оба множе­
ства могут быть возможными ключами.

Универсум

чей схема

R

U множество значений всех атрибутов. С учетом клю­
U - совокупность отношений {R р ... , R T }, где

над

n

R j ={Si'Kj;I~I~n}, ISj =и.
j..,l

6'

83

Тогда реляционной БД

d

со схемой данных

R

называется сово­

купность отношений {г" ''''Гп }' где для любой схемы R = {S, К}
существует отношение в

d,

являющееся отношением со схемой

S;

удовлетворяющее любому ключу.
В реляционной БД, как это видно, оперируют таблицами, про­
стейшим элементом является кортеж (запись).

При проектировании БД (независимо от применяемоro подхода

-

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

образования таблиц.
Фактически для таблиц выделяют следующие составляющие:

1)
2)
3)

создание;
обновление и запрос;
синхронизация процессов доступа.

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

Начнем обсуждение с операций преобразования таблиц.
Для оперирования с таблицами необходимо уметь описывать их
формально. Теоретическое описание может быть двух видов:

1)
2)

предикатами первого порядка;

использованием правил реляционной алгебры (РА) и реляци­

онного исчислении (РИ).
Первый вид специфичен и характерен для экспертных (интел­
лектуальных) систем, поэтому обсудим второй вид.

ОПИСАНИЕ ИСПОЛЬЗОВАНИЯ БД

Алгебра

-

рациями вида

исходное множество А с определенными на ней опе­

f:

Исчисление

-

Ап ~ А, где

n-

размерность.

совокупность правил оперирования с какими-либо

символами.

РИ по своей сути проще, но его применение оrpаничено следу­
ющими обстоятельствами:

•

практически не удается

-

в рамках РИ

про водимых операций преобразования;

84

-

доказать полноту

•

большая комбинаторная сложность реляционных схем не вскры­

вается РИ.
Все это возможно с помощью РА, программной реализацией
которой, как видно из самой постановки задачи, являются nроце­

дурные языки программирования.
Реляциоиная алгебра. Пусть
формул системы

el (L) -

множество всех замкнутых

L.

Если формула ер Е

el(L),

то говорят, что модель М удовлетворяет

ер(ср' М), если ер истинно на М.
Пусть у Е

(Ц. Формула \jf называется следствием у (выводима

CI

из у), если из \jf' м следует у = м для любой модели М.

Любое отношение, построенное правильно с помощью приня­
той системы операторов и отображений, называется алгебраическим
выражением. Пусть, по-прежнему,

рибутов);

U - универсум (множество ат­
dom - полная функция из U

множество доменов;

D -

(dom: U -7 О); R = {R p i = 1, р} - множество
d = {Гр i = 1, р} - множество всех отношений cj(R);

схем отношений;
в

= {#,~,~, } -

множество бинарных отношений (условий над доменами из О);
множество операторов (операций), использующих атрибуты из

0Uи

отношения из в.

Реляционная алгебра над
кортеж В

= {U,

О,

U, D, dom, R, d,

dom, R, d,

в есть семиместный

в, О}.

В реляционной алгебре выделяют следующие операции: проек­
ция (обозначается пили Р в разных источниках), селекция

соединение

(J),

объединение

(U),

«(1 или S),

разность (ор), деление, пересече­

иие, декартово произведеиие (ер). Пусть имеются два отношения

R(A,

В, С) и Р(О, Е, р). Объединения, пересечения и вычитания

(разность) выполняются над отношениями одинаковой арности.

1.

Операция объединения

R(A,

В, С)

u

U(R,

Р)

Р(О, Е,

F)

без повторений строк:

=

Q(A,

В, е)

а

Ь

с

d

е

f

h

g

h

k

j

k

а

Ь

с

m n

d

е

f

g

g
j

h

о

mп

85

о.

2.

Разность

(DF(R,

-

В, С)

R(A,

3.

Р»

из

R удаляются
Е,

DF P(D,

а

Ь

с

m n

d

е

f

g

g

h

j

k

Пересечение

Rn

R(A,

Р

-

В, С)

строки, имеющиеся в Р:

В, С)

F) = Q(A,
а

Ь

с

d

е

f

j

k

о

h

L

общие элементы множеств:

n P(D,

Е,

а

Ь

с

m n

d

е

f

g

g

h

j

k

F) = Q(A,

В, С)

g h I

о

h

4. Декартово произведение (ep(R, Р»: к каждой
R добавляется каждая запись отношения Р:

записи отноше­

ния

R(A,

В, е) еР

P(D,

Е,

а

Ь

с

m n

d

е

f

g h

F)
о

g h
j

5.

k

Проекция 1tS (A)(R), где

S(A) -

=

Q(A,

В, е, о, Е,

F)

а

Ь

с

m n

о

d

е

f m n

о

g

h

m n

о

j

k

m n

о

а

Ь

с

d

е

f g h

g h

g h

j

g

k

g h

h

список доменов результирующе­
R: выбираются и упоря­

го отношения из числа доменов отношения

дочиваются столбцы и удаляется избыточность из строк

86

В, С) п в c(R)

R(A,

= Q(B,

С)

а

Ь

с

Ь

с

d

Ь

с

dk

а

d k

6. Селекция (выбор) crF(R), где F(A;> 8, «константа») - исходное
i атрибут отношения R; 8 - логическое
условие
>, =, 7=, ~, ~, n, u, l).
отношение n-арности; А

«,

R(A,

В, С)

Q(A,

В, С)

а

Ь

с

а

Ь

d

Ь

с

а

d k.

а

d k

= crл = .(R)

с

7. Соединение Jлmi R , Р) = Q = SЛmВ:

R(A,

8.

В, С)

а

Ь

с

d

Ь

с

а

d k

P(D,

Е)

Q(A,

В, С,

D,

Е), где В 7=

d

с

а

Ь

с

d

с

d

а

d

Ь

с

d

с

ь

а

d k

Ь

а

а

d k

Ь

Ь.

в
ь

D

Если сравниваемые поля, имена которых лучше сделать оди­

наковыми, в результирующем отношении «считаются» только один

раз, то говорят о естественном соединении (слиянии)

NJ:

NJ(R, Р) = п,. 2•...• m(crs' ..... sn)(R х Р),
S. = (AR = АР; 1 = 1, п), А - список совпадающих атрибутов в
исходном отношении; 1, ... , m - упорядоченный список всех компонентов декартова произведения R х Р, за исключением А,Р, ... , АпР.
I

I

I

I

R(A,

В, С)

P(D,

А, В)

Q(A,

В, С,

D)

а

Ь

с

d d

Ь

а

Ь

с

а

d

Ь

с

а

а

Ь

d

Ь

с

d

а

d k

с

с

с

d

Ь

а

d.

d

Ь

а

87

Если отношение состоит из одного кортежа, то при естествен­
ном соединении получается селекция.

9.

Деленне (Х, У) + У = Х.

Операции идут на бинарном (делитель) и унарном (делимое)

отношениях, а результат (частное) получается унарным отношени­
ем. Элемент х появляется в результирующем отношении, если пара

имеется в делимом ДЛЯ всех значений элемента у, присуг­

ствующих В делителе. Частное

-

те левосторонние компоненты де­

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

Пусть имеется

(Х,У)=А,В)

У=(В)

а

Уl =е

Х=(А)
Х

1 =]

Ь

3

с

4

d

5

е

f

У2

=Ь

2

а

2

Ь

3

с

уз =а

3

е

Ь

4

Ь

с

4

d

d

4

е

е

5

е

f

Х2

=]
4

d

хз

=1

Наиболее часто используются операции селекции

(Р) и соединения

(J),

называемые SРJ-операциями .

88

(S),

проекции

Свойства реляционной алгебры
Рассмотрим свойства операций реляционной алгебры

1.

[4].

Коммутативность:

Унарные операции:

1) SF (SF (R» = SF (SF (R»;
I
2
2
I
2) Р л (Рл (R» = Рл (Рл (R», если А, = А 2 ;
I
2
1
I
3) SF (Рл (R» = Рл (SF (R», если Attr(F,)A,;
I

I

I

1

4) Р л I (SF(R»
= SF(Р
Л I (R», если Attr(F,)A,.
I
I
Бинарные операции:

5) JF(R, S) ~ JF(S, R);
6) U(R, S) ~ U(S, R);
7) CP(R, S) ~ CP(S, R).
Н. Ассоциативность бинарных операций:

1) U(U(R, S),

Т) ~

U(R, U(S,

Т»;

2) CP(CP(R, S), Т) ~ CP(R, CP(S, Т»;
3) J F (JF (R, S), т) ~ J F (R, J F (S, Т».
2
I
I
2
IJI.

Идемпотентность унарных операций:

1) Рл (R) ~ Рл «Рл(R», если А = А" А\",;;;; А 2 ;
I
2
2) SF (R) ~ SF «SF(R», если F = F, Г'\ F 2 •
I

IV.

2

Дистрибутивность бинарных операций между бинарными:

1) SF(U(R, S» ~ U(SF(R), SF(S»;

2) SF(DF(R, S» ~ DF(SF(R), SF(S»;
3) SF(CP(R, S» ~ CP(SF(R), S), если Attr(F) \",; ; Attr(S);
4) SF I (JF(R, S» ~ J F, (SF(R), SF(S», если Attr(F) \",; ; Attr(S);
5) Рл(U(R, S» ~ U(Рл(R), Рл(S»;

6) Рл(СР(R, S» ~ СР(Рл(R), Рл(S».
У. Факторизация унарных операций:

J) U(SF(R), SF(S» ~ SF(U(R, S»;
2) CP(SFR(R), SFS(S» ~ SF(CP(R, S», где F

=

FR Г'\ FS;

3) J F(S/R), SF(S» ~ SF(JF(R, S», где F = FR Г'\ FS;
89

4) DF(SFR(R), SFS(S» ~ SFR(DF(R, S», где FR ~ FS;
5) U(PA(R), P/S» ~ PA(U(R, S»;
6) CP(PAR(R), PAS(S» ~ PA(CP(R, S», где А = AR u AS.
Реляционная алгебра
в процедуре использования БД
Перечисленные правила используются прежде всего при форми­
ровании и оптимизации запросов.

ОПИСАНИЕ ПОСТРОЕНИЯ БД

Реляционная алгебра больше предназначена для описания про­
цедур запросов (выборки) и обновления. Дело в том, что РА (равно

как и РИ, как будет показано позднее) не затрагивают вопросы обес­
печения целостности при создании и обновлении БД. Иными сло­
вами, они непригодны для того, чтобы СУБД могла автоматически
про верить истинность или ложность следствий из заданных в схеме

БД

[9]

ограничений целостности.

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

Это удалось сделать с помощью функционального подхода (фор­
{l : 1, 1 : М} F -зависимостей и многозначных {l : М

мул однозначных
и прежде всего

-

М: М} МV-зависимостей) и, как следствие, путем

выполнения процедуры нормализации.

F-зависимости обеспечивают переход к первой (lНФ), второй

(2НФ), третьей (3НФ) нормальным формам представления данных.
МV-зависимости позволяют строить четвертую (4НФ) и пятую (5НФ)
нормальные формы.

Доказательства положений для р- и МV-зависимостей базиру­
ются на реляционной алгебре, в связи с чем их иногда относят к

аппарату реляционной алгебры.

Функциональные (однозначные) F-зависимости. Функциональные
зависимости являются обобщением понятия ключа: значения кор­
тежа на одном множестве Х атрибутов определяют значения на дру­
гом множестве У атрибутов; Х, У Е
Пусть имеется

r(R)

и Х, У Е

R; R -

схема отношения

R.

R.

Отношение удовлетворяет функциональной зависимости (ФЗ)

Х ~ У, если 1t у (О" х

= х (R»
имеет не более одного кортежа для
('v')x Е Х. Проверка проводится так (рис. 4.1): если корте­
t.(X) = t 2(X), то должно удовлетворяться условие t.(Y) = t2 (Y).

любого

жи

90

Такие однозначные зависимости

ся

F.

виде:

~~~----------I
Кортежи

I========I~- - - -- --- - -1

Иначе сказанное записывается в

F

у

х

называются F-зависимостями. Множе­
ство F-зависимостей также обозначает­
с Х ~ У влечет Х ~ У или го­

Рис.

ворят об аксиоме вывода.

4.1.

t2

F-зависимость

Аксиома вывода (правило): если отношение удовлетворяет не­
которым F-зависимостям, то оно должно удовлетворять и другим

F -зависимостям.
Пример 4.1. Пусть имеем расписание занятий «Расписание» (День,
Время, Аудитория, Преподаватель, Группа). Введем две ФЗ:

[,:

День Бремя Аудитория ~ Преподаватель Группа,

[2: День Бремя Преподаватель ~ Аудитория Группа.
Далее используем следующие ФЗ:

[,:

Студент ~ Курсовая_работа,

[2: Студент ~ Преподаватель,
[3: Преподаватель ~ Кафедра,
[4: Кафедра ~ Факультет,

[5: Студент ~ Факультет.
Пусть

R=

{а,

... , А};

Х, У,

Z, W

Е

R.

ДЛЯ любого

r(R)

справедли­

вы следующие аксиомы вывода.

Fl.

Рефлексивность: Х

=

Х. Проекция от селекции пХ>?
SQL вы

знаете?

универсальным языком реляционных СУБД?

Глава

5

Реляционные базы данных
Освоение свойств моделей данных (МД) осложняется тем, что в раз­
ных моделях данных используется своя терминология описания структур­

ных элементов и их связей. Для упрощения изучения МД ниже приведены
соответствующие термины в сравнении с понятиями, используемыми в ре­

ляционной модели данных.

Краткая характеристика структуры моделей данных
Модель данных

Реляционная

Элемент структуры

Таблицы: столбцы

-

Связь

Структура таблицы

По ключу

Линейная

По указателю

Линейная

ПОЛЯ,стро-

ки -записи

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

Сегменты: исходный и порожден-

- аналоги
таблиц
ный

Сетевая

Записи: владелец
и член

-

аналоги

таблиц

По указателю и

Линейная,

по ключу (связь

нелинейная

именуется);
совокупность

записей и связь

образуют набор

Объектно-реляционная

Объекты (таблицы,абстрактные
типы данных)

По ключу

Линейная,
нелинейная

Объектно-ориен-

Классы объектов

По объектной

Линейная,

тированная

(типов данных,

ссылке и объект-

нелинейная

данных): объект-

строка,столбцы
свойства (кон-

HoMy

-

стаНТЫ,встроен-

ные объекты,потоки данных,КОЛ-

лекции,МНОГОмерные пере-

менные,ссылки)

8 - 4840

113

указателю

При обсуждении моделей данных (гл.

5-9)

будем придерживаться

такой однотипной последовательности:

1) логическая

структура, включающая описание структуры (элементы,

связи):

2)
3)
4)

создание БД в рамках рассматриваемой модели данных (МД);

использование БД;
свойства модели данных (достоинства и недостатки). Сравнитель­
ная таблица свойств МД приведена в гл. 9.

5.1.

ЛОГИЧЕСКАЯ СТРУКТУРА

Реляционные базы данных получили широкое распространение
в персональных компьютерах. Наиболее известны такие локальные

СУБД, как

dBASE, Paradox и особенно - Access. СУБД Oracle, Sybase,
Informix, BTrieve, Ingress, InterBase были изначально предназначены

для работы в сети с большими объемами данных.
Воснове реляционной модели лежит математическое понятие

теоретико-множественного отношения, которое представляет собой
подмножество декартова про изведения списка доменов.

Домен

-

множество значений (например, множество целых чи­

сел). Декартовым произведением доменов D" D 2 , •• , D k (обознача­
ется как D, х О 2 Х ... Х DJ называется множество всех кортежей

(У" У2 ,

k = 2,
(1,

а),

(О, с),

Vk ) длины k, таких, что У; Е D p i = П. Например, если
{О, I} и О = {а, Ь, с}, то о, х D 2 есть {(О, а), (О, Ь), (О, с),
2
(1, Ь), (1, с)}, а отношением может быть, например, {(О, а),
••. ,

О,

=

(1,

Ь)}.

Элементы отношения называются кортежами и имеют арность k
(степень отношения), причем i-й компонентой является Vj • Отно­
шение удобно представлять таблицей

-

совокупностью всех корте­

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

определяет размерность таблицы. Столбцы называются атрибутами,
и им часто присваиваются имена. Упорядоченный список имен ат­
рибутов отношения называется схемой отношения. Если отноше­

ние называется «Студент» И его схема имеет атрибуты А" ~, ... , Ak,
то такую схему будем записывать как СТУДЕНТ(А" ~, ... , Ak ).
Совокупность схем отношений называется схемой (реляцион­
ной) БД, а текущие значения соответствующих отношений - БД,
Данные из диаграммы объектов-связей представляются двумя
видами отношений.

1.

Набор объектов может быть представлен отношением, содержа­

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

ния содержит дополнительно атрибуты ключа второго набора.

114

2.

Связь между наборами объектов Ер Е 2 ,

••• ,

Ek

представляется

отношением, схема которого состоит из атрибутов ключей каждого
из этих наборов.
Реляционная модель есть представление БД в виде совокупнос­
ти упорядоченных нормализованных отношений.

Для реляционных отношений характерны следующие особен­
ности.

1.

Любой тип записи содержит только простые (по структуре)

элементы данных.

2.
3.

Порядок кортежей в таблице несущественен.
Упорядочение значащих атрибутов в кортеже должно соответ­

ствовать упорядочению атрибутов в реляционном отношении.

4.

Любое отношение должно содержать один или более атрибу­

тов, которые вместе составляют уникальный первичный ключ.

5.

Если между двумя реляционными отношениями существует

зависимость, то одно отношение является исходным, второе

-

под­

чиненным.

6.

Чтобы между двумя реляционными отношениями существо­

вала зависимость, атрибуты, служащие первичным ключом в исход­
ном отношении, должны также присутствовать в подчиненном от­
ношении.

Э. Кодд первоначально предложил

12

(дюжину) правил, факти­

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

1.

Правило инФормации. Вся информация на логическом уровне

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

2.

Правило гарантированного доступа. Каждый атомарный эле­

мент таблицы доступен через комбинацию из имени таблицы, име­
ни поля и ключа.

3.

Системная поддержка Null-значениЙ. Для представления отсут­

ствующих данных с любым типом используют Null-значение.

4.

Динамический оперативный каталог на основе реляционной мо­

дели. Метаданные (словари) формируются теми же языками, что и
данные.

5.

Правило исчерпывающего подъязыка данных. В базе данных

возможно использовать несколько языков программирования,

нако один (чаще всего

6.

- SQL)

од­

должен быть главным.

Правило обновления представления (вида,

View).

Все теорети­

чески обновляемые представления может обновлять и система.

7.

Ввод, обновление и удаление данных на высоком уровне. Работа

с несколькими записями должна быть характерна не только запро­
сам на выборку, но и запросам на обновление.
8*

115

8.

Физическая независимость данных. Возможно изменение адре­

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

9. Логическая независимость данных. При добавлении или удале­
нии элементов (таблиц, полей) в структуре БД другие части базы
данных остаются неизменными.

10. Независимость целостности. Ключ
Null. Первичный и родительский ключи

не должен иметь значения

должны быть уникальны­

ми. Каждому значению внешнего ключа должно существовать зна­
чение родительского ключа. Ссылочная целостность уменьшает бы­
стродействие из-за проверки условий-связей через словарь.

11. Независимость распределения. В распределенной БД распо­
ложение данных независимо. Для пользователя такая БД должна
выступать как централизованная БД.

12. Правило соблюдения правил. Нельзя обходить ограничения,
введенные с помощью языка SQL.
При мер

5.1.

Представим БД «Учебный процесс» в виде реляци­
5.1, а)

онной модели (табл. 5.1). Далее отношения (например, табл.
будем записывать и в другой форме:

ГРУППА(Шифр группы, Название, Количество {студентов},
Средний_балл).
Подчеркнутый атрибут является ключевым.
Таблица
а) Отношение
ШИфРJРyrпrы

Названис

КОЛWIССТ80

СредНИЙ балл

1

И1

16

4,3

2

И2

23

4,0

3

И3

18

4,2

б) Отношение

5.1

.. Группа»

.. Студент»

HOMep_3a'I_KH

Шифр_группы

фио студента

Год рождсниSl

Средний балл

И-l746

1

Серов АЛ.

1979

4,1

И-l747

2

Киров П.Г.

1980

4,0

И-1748

3

Сухов п.н.

1981

4,5

116

В) Отношение
Код кафсдры

.. Кафедра»

Название

Телефон

Заи. кафедрой

1

ИиУС

154-12-86

Сорокин П.В.

2

АПП

171-12-05

БоРИСО8 Б.В.

3

ТПП

212-10-81

СтепаНО8 И.В.

г) Отношение

.. Преподаватель»

Табел_номер

ФИО преподавателя

У'l_степень

У'I_зиание

381

ШаталО8А.С

Д.Т.Н.

Профессор

1

101

Сидоров А.т.

К.Т.Н

Доцент

2

402

Тараканов П.Т.

к. ф.-м. н

Доцент

Код кафедры

-

3

д) Отношение "Предмет»
Код IIредмеrd

Назнание

Всеl'O '.асон

ПраКТ/Jlаборатор

Семестрон

Пl

Информатика

350

130

2

п2

Кибернетика

300

120

3

п3

Математика

600

200

4

е) Отношение «Изучение~
ШИфрJрyrnты

Код предмета

Табел_номер

Вид занятий

2

п2

402

Практические

2

п2

381

Лекции

1

п3

381

Лекции

1

п3

401

Практические

Часы

ж) Отношение «Успеваемость»
Шифр_

Номер_

Код

ГРУIlПЫ

за'!_кн

нредмета

1

И-1746

2
3

Табел -

Вид

Оценка

номер

занятий

п3

381

Экзамен

5

И-1747

п3

381

Экзамен

4

И-1748

п3

381

Экзамен

3

117

КАФЕДРА

ПРЕДМЕТ

ГРУППА
Шифр_группы

+--

Ко~предмета

....

Ко~кафедры

Название

Название

Название

Количество

Всего_часов

Телефон

Средний_балл

Лекции

Зав_кафедрой

~

Практ/лаборат
Семестр
ИЗУЧЕНИЕ

СТУДЕНТ
Номер _зач_кн

.-

Шифр_группы

,"

---.

Ко~предмета

~

Табел номер

,,,

~

Табел номер

Код...кафедры

Шифр группы

ФИ О_студента

Вид... занятий

ГОд...Рождения

Часы

Средний балл

ПРЕПОДАВАТЕЛЬ

+---

~

ФИО _преподавателя
Уч_степенъ
Уч_звание

~СПЕВАЕМОСТЬ

-"

Шифр_группы

Номер_зач_кн
'-- ~

4)

Ко~предмета
Табел_номер
Вид...занятиЙ

(f--

Оценка
Рис.

5.1.

Схема связей БД «Учебный процесс»

Процедуры создания и использования реляционных БД осно­

вываются на теории реляционных БД, подробно рассмотренной в
гл.

4.

Ее результаты используем в прикладных целях. При введении

структуры данных используют соответствующие форматы данных.

Для таблицы «Преподаватель» они представлены в табл.
(табл.

5.1)

5.2.

ВСЯ БД

представлена в 4НФ, поэтому отразим схему связей меж­

ду ее отношениями (рис.

5.1),

где подчеркнутые поля

-

первичные

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

-

в гл.

5.
118

1,

а схема

Таблица

5.2

Форматы типов данных отношения «Преподаватель»
Уникаль-

Обязатель-

Тин

нос поле

нос поле

лаlfНЫХ

Да

Да

Числовой

-

Нет

Да

- сте-

-

Нет

Нет

-

-

Нет

Нет

ВнеШIIИЙ

Нет

Да

Имя поля

Табсл

-

номер

Ключ

ПеРВИ'Iный

фио
препода-

вателя

Уч

пень

Уч

звание

Код
кафедры

5.2.

Размер

Целое

Текстовый

Текстовый

Текстовый

Текстовый

Подписи
IЮЛ51

Таб

N

30

ПФИО

12

У" - ст

12

У" _ЗВ

6

КО!Lкаф

СОЗДАНИЕ И ИСПОЛЬЗОВАНИЕ БД

Основная задача при проектировании реляционных БД

-

фор­

мирование оптимальных отношений.

Для формализации процесса построения оптимальной реляци­

онной БД используется теория нормализации, основанная на том,
что определенный набор отношений обладает лучшими свойствами
при включении, модификации и удалении данных, чем все осталь­

ные наборы отношений, с помощью которых MOryT быть представ­
лены те же данные (см. гл.

4).

Нормализация осуществляется последовательно с использованием

пяти нормальных форм, включая форму БоЙса-Кодда.
На этом «бумажное» построение БД заканчивается. Компью­
терная реализация БД определяется языками описания (ЯОД) и
манипулирования (ЯМД) данными. Они могут базироваться на
реляционной алгебре (процедурные языки) и реляционном ис­

числении кортежей и доменов (декларативные языки). На исчис­
лении кортежей основан язык
язык

SQL,

на исчислении доменов

-

QBE.

Рассмотрим возможности языков
использование описано в гл.

15.
119

SQL

и

QBE.

Прикладное их

Язык
Для

SQL

SQL

имеется много вариантов и диалектов. Здесь изложим

основные положения базового варианта: более подробное описание
языка приведено в

[2, 5, 6, 26, 33].
Иллюстрацию языка SQL проведем на примере
«Снабжение», представленной в табл . 5.3-5.5. Для нее
связей показана на рис. 5.2.

базы данных
схема

Access-

Таблица

5.3

«Продавцы»

КОММ

I!ИМИ

I'OPOH

1001

Строков

Москва

12

1002

КИРЮШИII

Пермь

13

1004

Аврорин

Москва

11

1007

УЩIJIOВ

Курск

15

((Ю3

Козлов

Орел

10

IIHOM

Таблица

«Заказчики»

ЗIIОМ

ЗИМЯ

город

реЙТИIIГ

ПlIOМ

2001

Иванов

Москва

100

1001

2002

Петров

С-Петербург

300

1003

2003

Ковров

Сочи

200

1002

2004

Сидоров

Кириши

300

1003

2006

Крабов

Русса

100

1001

2008

Конкин

Пермь

300

1007

2007

Красин

Луга

100

1004

120

5.4

Таблица

5.5

"Заказы»

пр"ом

сумпр

3001

IR.69

3003

датпр

'!IIОМ

ПlJOм

10.03.1990

2008

1007

767.19

10.03.1990

2001

1001

3{)()2

1900.10

10.03.1990

2007

I{)()4

3005

5160.46

10.03. 199О

2О03

1003

3006

1098.16

10.03.1990

2008

1007

3009

1713.23

1о.о4. 1990

20m

1003

3{)()7

75.75

10.04.1990

2004

1002

3008

47RЗ.00

10.05.1990

2006

1001

3010

1309.95

10.06.1990

2{)()4

1002

3011

9891.Rя

10.06.1990

2006

1001

Название полей таблиц

Таблица «Продавцы»:

город комм пном

уникальный номер продавца, первичный ключ;

пимя

имя продавца;
город расположения продавца;
комиссионные продавца.

Табл~ца «Заказчики»:
зном
зимя

-

рейтинг

уникальный номер заказчика, первичный ключ;
имя заказчика;

-

число, показывающее уровень предпочтения данного

заказчика перед другими;

пном

-

номер продавца, внешний ключ.

Таблица «Заказы»:

- уникальный номер заказа, первичный ключ;
- сумма (цена) заказа;
датпр дата получения заказа;
зном - номер заказчика, делающего заказ, внешний ключ;
пном - номер продавца, продающего заказ, внешний ключ.
прном

сумпр

121

Заказчики

Продавцы

I+-

пном

зном

пимя

зимя

город

город

комм

рейтинг

~

пном

Заказы
зном

~

"

ПНОМ

прном

сумпр

датпр

Рис.

5.2.

Схема связей

Выделяют статический и динамический языки программирова­

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

полнения программы из других таблиц (баз данных).

Статический язык nрограммированuя

SQL

SQL возможно выделить три основные группы опера­
(CREATE), обновление (INSERT, UPDATE, DELETE),
(SELECT). Они имеют следующие стандарты, в которых при­

В языке

ций: создание
запрос

няты обозначения:

1- все, что предшествует символу, можно заме­

нить тем, что следует за ним;
символа;

[] -

{} -

единое целое для применения

необязательное выражение;

вольное число раз;

., ... -

... -

повторяется произ­

повторяется произвольное число раз, но

любое вхождение отделяется запятой.
САЕАТЕ

TABLE
({ [размер]
[ ... ]}., ... );
[]., .. );

122

(5.1)

Типы данных могуг быть: INTEGER, CHARACTER, DECIMAL,
NUMERIC, SMALLINT, FLOAT, REAL, PREClSION, LONG,
VARCHAR, DATE, TIME. Четыре последние типа не входят в стан­
дарт SQL, но им могуг поддерживаться.
Тип столбца (и тип таблиц) может быть: UNIQUE, PRIMARY
КЕУ, СНЕСК , DEFAULT = < список полей>,
REFERENCE [«имя столбца > ., ... )] .

INSERT INTO [«имя столбца> . , ...)]

{VАLUЕS«список полей»., ... }

(5 .2)

DELETE
[WHERE
]WHERE CURRENT OF
(*только вложенный*)];

(5.3)

SELECT * ] [{DISТINСТ!АLL]
FROM []} ...
[WHERE ]
[GROUP ВУ {! }. , ... ]}
[HAVING ] [ORDER ВУ {}]! } ... ]
[{UNION}];
(5.4)
Выделяют три разновидности языка

SQL:

интерактивный, вло­

женный и встроенный.

Интерактивный

SQL

используется для функционирования не­

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

Встроенный

SQL

состоит из команд

SQL,

помещенных внутри

программ, которые обычно написаны на другом языке (типа ка­
БаЛА или Паскаля). Это делает такие программы более мощными
и эффективным.

Будем рассматривать преимущественно (при отсутствии упоми­
наний) интерактивный язык .

• ИНТЕРАКТИВНЫЙ ЯЗЫК SQL
в нем возможно выделить :

• DDL (Язык Описания Данных) ANSI он состоит из команд, создающих
сы , виды) в базе данных ;

123

язык описания схемы и в

объекты (таблицы , индек­

• DML

(Язык Манипулирования Данными)

-

набор команд,

определяющих, какие значения представлены в таблицах в любой
момент времени;

• DCD
рые

(Язык Управления Данными) состоит из средств, кото­

определяют

разрешение

пользователю

выполнять

определен­

ные действия.

По своей сути язык

SQL

является специфическим декларатив­

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

SELECT.

Однако более удобно располо­

жить команды по технологическому циклу работы с БД:

1)

создание БД

-

структуры таблиц, создание видов, заполне­

ние БД данными, обеспечение целостности, система доступа (раз­
решений), словарь данных, многопользовательский режим;

2)

использование БД

-

запрос в различных формах (в том числе

с обновлением).

Создание БД

Структура таблиц. Таблицы (пустые) создаются командой

CREATE TABLE

(выражение

(5.1».

CREATE TABLE Продавцы
(ПНОМ integer,
ПИМЯ char (10),
город char (10),
КОММ decimal);
Команда

CREATE TABLE

(5.5)
в основном определяет имя таблицы,

набор имен столбцов, указанных в определенном порядке, типы

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

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

SQL
которых

позволяет создавать временные таблицы, «время жизни»

-

сеанс работы БД (время от открытия до закрытия базы

данных).

Таблица может быть глобальной, т. е. доступной всей приклад­
ной программе, создавшей ее:

124

САЕАТЕ

GLOBAL ТЕМРОАААУ TABLE Продавцы
integer,
пимя char (10),
город char (1 О),
комм decimal);

(ПНОМ

Она может быть локальной, доступной только для модуля про­
граммы, в котором она была создана:

САЕАТЕ

LOCAL TEMPORARYTABLE Продавцы
integer,
ПИМЯ char (1 О),
город char (10),
КОММ decimal);

(пном

Изменение таблицы после ее создания осуществляется коман­

дой

ALTER TABLE.

Обычно, она добавляет столбцы к таблице.

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

Чтобы добавить столбец к таблице, используют формат:

ALTERTABLE АDD



;

Столбец будет добавлен последним и со значением

NULL

дЛЯ

всех строк таблицы.

Удаление проводится по команде

DАОР TABLE ;
Надо быть создателем таблицы, чтобы иметь возможность уда­
лить ее.

Аналогично создаются и удаляются индексы.

Базовая таблица

(5.5)

представлена в простейшем виде и будет

далее усовершенствована: другие таблицы будут созданы позднее.
Сейчас рассмотрим лишь создание вида.

Структура и содержание видов. Только что созданная таблица
называется базовой. Можно создавать представление (вид,

View) -

таблицы, содержимое которых берется или выводится из других таб­
лиц. Вид создается командой

CREATE VIEW:
125

САЕАТЕ

VIEW Москва1
ASSELECT*
FROM Продавцы
WHERE город = 'Москва';

Москва}

-

представление (вид). Оно используется для целей

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

чтения. Это означает, что их можно запрашивать, но они не могут
подвергаться действиям команд модификации.

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

новываться на одиночном запросе; ОБЪЕДИНЕНИЕ

ОБЪЕДИНЕНИЕ ВСЕГО

DISTINCT

(UNION ALL),

(UNION)

и

агрегатные функции,

в определении, вычисляемые поля не разрешаются в

работе с представлениями; упорядочение

(ORDER

ВУ) никогда не

используется в определении представлений.

Удаление представлений осуществляется (его владельцем) ко­
мандой

DRОРVIEW.

Заполнение БД да1lными. Значения могут быть помещены и уда­
лены из полей командами языка

Данными

-

выражения

ЯМД)

(5.2)

и

DML (Язык Манипулирования
INSERT (ВСТАВИТЬ), DELETE (УДАЛИТЬ) (5.3). Так, например, чтобы ввести строку в таб­

лицу «Продавцы» , можно использовать следующее условие:

INSERT INTO Продавцы
VALUES (1001, 'Строков',

'Москва',

Можно вставлять и пустое значение

.12);

(NULL).

Возможно указывать столбцы таблицы в любом порядке, на­
пример,

INSERT fNTO Заказчики (город, имя, номер)
VALUES ('Москва', 'Иванов', 2001);
126

Отметим, что столбцы «рейтинг» и «пном» отсугствуют: эти строки

автоматически установлены в значение

NULL

(по умолчанию).

Исключение строк, введенных по ошибке, про водится коман­

дой

DELETE.

Она может удалять только введенные строки, а не

индивидуальные значения полей, так что параметр поля является

необязательным или недоступным. Чтобы удалить все содержание
таблицы «Продавцы», надо ввести:

Продавцы;

DELETE FROM

Теперь таблица пуста и ее можно окончательно удалить коман­
дой

DROP TABLE.

Обычно нужно удалить только некоторые опре­

деленные строки из таблицы, ДЛЯ чего используется предикат. На­

пример, чтобы удалить данные продавца Козлова из таблицы «Про­
давцы», можно ввести

DELEТE

FROM Продавцы
WHERE пном = 1003;

Команды

INSERT, DELETE

совместно с командой

UPDATE

используются в процедуре обновления при эксплуатации БД.
Задание (обеспечение) целост1l0сти. Это разновидность команды

CREATE TABLE,

позволяющая устанавливать ограничения в таб­

лицах.

Ограничение столбца вставляется в конец имени столбца после

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

CREATE TABLE
«имя столбца> ,
«имя столбца> ,


[,



(

] ... );

Перечислим некоторые ограничения.

1. Исключение пустых (NULL) указателей введением
NOT NULL.
2. Уникальность данных и первичные ключи.
127

команды

Ограничение столбца

UNIQUE

в поле при создании таблицы

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

непустые

(NOT NULL).
3. SQL поддерживает первичные ключи непосредственно с огра­
ничением PRIMARY КЕУ (первичный ключ). Первичные ключи не
могут иметь значений NULL. Это означает, что, подобно полям в
ограничении UNIQUE, любое поле, используемое в ограничении
PRIMARY КЕУ, должно уже быть объявлено NOT NULL.
4. Ограничения на значения полей. Для этого используется ог­
раничение СНЕСК: чтобы предотвратить ошибку неправильного

введения значения «комм», наложим ограничение столбца
« 3000.00;
Аргументы в предложении

вилам, что и в предложении

пользующихся в

GROUP

HAVING
SELECT,

следуют тем же самым пра­

состоящем из команд, ис­

ВУ. Они должны иметь одно значение на

группу вывода. В строгой интерпретации

ANSI SQL нельзя

исполь­

зовать агрегат агрегата.

Если надо выполнить простые числовые вычисления данных (вы­

числяемые выражения) и затем поместить их в форму, более соот­

ветствующую потребностям, то

SQL

позволяет это сделать. Напри­

мер, если ввести команду

SELECT пном, пимя, город,
FROM Продавцы;
то в поле «комм»

комм

*100

появятся значения в процентах.

Возможно упорядочение вывода по одному или нескольким по­
лям, например, по убыванию:

SELECT *
FROM3AКA3bI
ОАОЕА ВУ зном

DESC,

сумпр

DESC;

Вместо имен столбца можно использовать их порядковые номе­

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

ORDER

SELECT

пер­

ВУ не зависит от того, каким по порядку оно

стоит в таблице. Например, команда упорядочения по убыванию
значения комиссионных такова:

SELECT пимя, комм
FROM Продавцы
GROUP ВУ 2 DESC;
пном

КОММ

Строков

0.17

Кирюшин

0.13
0.15

Удалов

141

До сих пор речь шла о работе с одной таблицей, однако возмож­

на работа и с несколькими таблицами. Формат команд меняется
мало, при этом можно использовать практически все, что применя­

лось для одиночных таблиц.

Создание объединения чаще всего осуществляется командой
вида

SELECT Заказчики.ЗИМЯ,

Продавцы.пимя,

Продавцы.город

FROM Продавцы, Заказчики
WHERE Продавцы.город = Заказчики.город;
Здесь после

SELECT

указываются через точку имя таблицы и

файла:
зимя

пимя

город

Иванов

Строков

Москва

Иванов

Строков

Москва

Ковров

Кирюшин

Пермь

Конкин

Кирюшин

Пермь

Иванов

Аврорин

Москва

Крабов

Аврорин

Москва

в указании полей могут использоваться и другие условия, на­
пример,

SELECT пимя, зимя
FROM Продавцы, Заказчики
WHERE пимя < зимя
AND рейтинг < 200;
пимя

зимя

Строков

Красин

Аврорин

Красин

Козлов

Иванов

Козлов

Крабов
Красин

Козлов

Аналогично выглядит и команда соединения трех и более таблиц.

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

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

142

SELECT

перв.ЗИМЯ, втор.ЗИМЯ, перв.реЙтинг

FROM Заказчики

перв, Заказчики втор

WHERE перв.реЙтинг = перв.реЙтинг;
Петров
Петров
200
Петров

Ковров

200

Ковров

Петров

200

Ковров

Ковров

200

Квакин

Квакин

Квакин

Конкин

Крабов
Крабов
Крабов

Иванов

Конкин

Квакин

Конкин

Конкин

Красин

Иванов

Красин

Крабов

Красин

Красин

300
300
100
100
100
300
300
100
100
100

Крабов
Красин

В вышеупомянутой команде

SQL

ведет себя так, как если бы он

соединял две таблицы, называемые «первая,) И «вторая» . Обе они

-

фактически таблицы «3аказчикИ», но псевдонимы разрешают им быть
обработанными независимо. Псевдонимы «первый,) И «второй» были
установлены в предложении

FROM

запроса, сразу после имени ко­

пии таблицы. Псевдонимы могут использоваться в предложении

SELECT,

даже если они не определены в предложении

FROM.

Следующая команда будет определять любые ошибки в запол­
нении:

SELECT перв.ПРНОМ, ВТОр.ЗНОМ, перв.ПНОМ,
BTOP'nPHOM,

ВТОр.зном, ВТОр.пном

FROM Заказчики

перв, Заказчики втор

WHERE перв.ЗНОМ = втор.ЗНОМ
AND перв.ПНОМ < > втор.пном;

Если заполнение таблицы проведено верно, то вывод будет
пустым.

При работе с несколькими таблицами запрос может быть со­
ставным, использующим или не использующим операции обновле­
ния. Внутренние запросы называют подзапросами.
Пусть известно имя продавца (Аврорин), но значение его поля
«ПНОМ') неизвестно и надо извлечь все заказы из таблицы «3аказы,).
Тогда:

143

SELECT *
FROM Заказы
WНЕRЕпном=

(SELECT пном
FROM Продавцы
WHERE пимя = 'Москва');
Чтобы оценить внешний (основной) запрос,

SQL

сначала дол­

жен оценить внутренний запрос (подзапрос) предложения
Ответ: «пном,) =
а

помещает его

1004.
в

Однако

SQL,

WHERE.

не просто выдает это значение,

предикат основного запроса

вместо

самого

под­

запроса, так чтобы предикат прочитал

WHERE

пном

= 1004.

для работы с несколькими таблицами может использоваться и

операция объединения

Например, для получения всех

(UNION).

продавцов и заказчиков, размещенных в Москве можно использо­
вать команду:

SELECT пном, пимя
FROM Продавцы
~HEAE город = 'Москва'
UNION

SELECT зном, зимя
FROM Заказчики
WHERE город = 'Москва';
Как можно видеть, столбцы, выбранные двумя командами, вы­
ведены так, как если она была одна . Заголовки столбца исключе­

ны, потому что ни один из столбцов, выведенных объединением,

не был извлечен непосредственно только из одной таблицы. Толь­
ко последний запрос заканчивается точкой с запятой. Отсутствие

точки с запятой дает понять

SQL,

что имеется еще один или более

запросов.

Возможны и запросы с командами обновления, рассмотренны­
ми ранее.

Можно выполнить и так называемый перекрестный запрос, ре­
зультатом которого является таблица, аналогичная таблице в прило­

жении

Excel.

Команда

TRANSFORM

го запроса.

144

служит для выполнения тако­

До сих пор речь шла о статическом языке

ристику динамическому языку

SQL.

SQL.

Дадим характе­

Первую часть предыдущего слож­

ного оператора можно записать

SELECT ПНОМ, ПИМЯ

FROM

Продавцы

WHERE

город

= :город;

Здесь двоеточие перед словом «город» означает, что задан пара­

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

программы. Параметры могут быть заданы во всех командах выбор­
ки и обновления .

• ВСТРОЕННЫЙ ЯЗЫК SQL
До сих пор рассматривался интерактивный
остановимся на встроенном языке

SQL,

SQL.

Теперь кратко

используемом для расши­

рения программ, написанных на других языках. Хотя непроцедур­

ность интерактивного языка

SQL делает его

очень мощным, в то же

время она накладывает на язык большое число ограничений.
Чтобы преодолеть эти ограничения, можно включать

SQL в

про­

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

ANSI.
SQL.
Логические конструкции типа if ... then (если ... то), for ... do (для
выполнить) и while ... repeat (пока ... повторять), используемые
Отметим некоторые ограничения

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

Интерактивный

SQL

не может делать многие операции со зна­

чениями, размещением или распределением их, выводом их на ка­

кое-то устройство. Цель встроенного

SQL состоит в соединении

воз­

можностей декларативного и процедурного языков.

Строго говоря, следует выделить вложенный и встроенный язык

SQL.
В первом случае основным является язык

SQL,

в который вво­

дятся операторы циклов и условных переходов. Здесь нет резкого
разделения на интерфейсный и вложенный языки. Обычно опера­

торы выборки

(SELECT), обновления (DELETE, UPDATE, INSERT),
(TRANSFORM) относят к интерактивному
SQL. В то же время операторы CREATE, ALTER, DROP,

перекрестного запроса
языку
10 - 4840

145

GRANT, REVOKE считаются принамежащими к вложенному языку
SQL. В качестве объектов выступают таблицы, поля, ограничения,
индексы, домены,

виды,

генераторы, триггеры, хранимые процеду­

ры. Присутствие «алгоритмических составляющих» языка лучше все­

го видно в СУБД

InterBase

в триггерах и хранимых процедурах.

Во втором случае операторы языка

SQL

ритмические языки. Часто им является язык
дЫ

«встраиваются»

в алго­

Pascal. Для этого

коман­

помещаются в исходный текст главной программы, которой

SQL

предшествует фраза ЕХЕС

SQL (EXECute SQL).

Далее обсуждаются

некоторые команды, являющиеся специальными для вложенной

формы

SQL.

Когда вставляются команды

SQL

в текст программы, написан­

ной на другом языке, надо выполнить прекомпиляцию прежде, чем

окончательно ее скомпилировать. Программа, называемая преком­

пилятором (или препроцессором), будет просматривать текст про­
граммы и преобразовывать команды

SQL

в форму, удобную для

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

Иными словами, основная программа вызывает процедуры

SQL,

которые выбирают параметры из главной программы и возвращают

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

SQL.

Идея в том, чтобы процедуры могли ра­

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

(lD)

SQL,

связана с

доступа во время ее выполнения. Идентифи­

катор доступа, связанный с программой, должен иметь все привиле­

гии, чтобы выполнять операции

SQL

SQL,

выполняемые в программе.

и части базового языка программ будут связываться друг с

другом с помощью значений переменных. Разные языки распозна­
ют различные типы данных МЯ переменных и
виваленты

SQL

ANSI

определяет эк­

базового языка Паскаль.

Можно использовать переменные из главной программы во вло­
женных операторах

SQL везде,

где будут использоваться выражения

значений.
Главные переменные должны:

•

быть объявленными в

SQL DECLARE SESSION

(раздел объяв­

лений);

•
SQL;

иметь совместимый тип данных с их функциями в команде

146

•

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

команде

SQL, если команда SQL самостоятельно не может сделать

назначение;

•

(:), когда они упоминаются в ко­
SQL.
Пусть в nporpaMMe имеются четыре переменных с именами id_num,
salesperson, loc и соmш. Они содержат значения, которые нужно
предшествовать двоеточию

манде

вставить в таблицу «Продавцы». Можно вложить следующую ко­
манду

SQL

в программу

ЕХЕС

SOL INSERT INTO Продавцы
VALUES (:id_num, :salesperson, :Ioc,

:сотт)

Обратите внимание, что точка с запятой в конце команды от­

сутствует. Это потому, что соответствующее завершение для
встроенной команды

SQL

зависит от языка, для которого делается

вложение.

Команду можно включить в цикл:

while

поt епd-оf-filе (iпрut)

do

Ьеgiп

геаdlп (id_пum, sаlеsрегsоп, lос, сотт);
ЕХЕС

SOL INSERT INTO Salespeople
VALUES (:id_пum, :sаlеsрегsоп, :Ioc,

:сотт);

епd;
Фрагмент программы на языке Паскаль определяет цикл, кото­
рый будет считывать значения из файла, сохранять их в четырех
поименованных

переменных,

ных в таблице «Продавцы»

сохранять

значения

этих

пере мен­

и затем считывать следующие четыре

значения.

Все переменные, на которые имеется ссылка в предложениях

SQL,

должны сначала быть объявлены в

SQL DECLARE

SЕСТЮN

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

ными командами

SQL - BEGIN DECLARE SECТION (начало раз­
END DECLARE SЕСТЮN (конец раздела объяв­
предшествует, как обычно ЕХЕС SQL (выполнить).

дела объявлений) и
лений), которым

Чтобы объявить переменные предыдущего при мера, можно ввести:

ЕХЕС

SOL BEGIN DECLARE SECTION;

Var
10'

147

id-num:

integer;
packed аггау (1 .. 1О) of char;
loc:
packed аггау (1 .. 1О) of char;
сотт:
real;
ЕХЕС SQL END DECLARE SECTION;
Sа/еsрегsоп:

где Уаг

-

заголовок, который предшествует ряду объявляемых пере­

менных и упакованным (или распакованным) массивам.
Переместим строку Строков из таблицы «Продавцы» в перемен­
ные главного языка:

ЕХЕС

SQL SELECT sпum, sпаmе, city, сотт
INTO :id_пum, :salesperson, :Ioc, :сотт
FROM Salespeople
WHERE sпum = 1001;

Возможно использовать запросы, выводящие многочисленные
строки, при меняя курсор. Курсор

-

это вид переменной, которая

связана с запросом. Значением этой переменной может быть каж­
дая строка, которая выводится при запросе.

Заметим, что язык

SQL

может использоваться как для построе­

ния, так и для запросов, в то время как язык

QBE

применяется

только для обновления и, в основном, для запросов.

Другим вариантом встроенного языка программирования

SQL

служит язык, используемый, например, при применении СУБД

InterBase

в среде

Delphi:

так называемый формируемый запрос, в

котором SQL-операторы встраиваются в язык

мощью команды

Queryl.SQL.Add(' ... '),

Object Pascal

с по­

где в скобках указывается

SQ L-оператор.
ЯЗЫКQВЕ

Работа на языке

SQL проста,

но требует знания языка. Для пользо­

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

1) через меню и экранные формы;
2) с помощью языка Query Ву Example - QBE (запрос

по примеру).
Первый способ зависит от варианта разработки СУБД второй

способ, предложенный М.М. Злудом и базирующийся на исчислении

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

148

С помощью этого способа на экран вызывается одна или не­

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

подчеркнугых переменных, написанных большими буквами. Выво­

димые на печать поля указываются символом Р

(print),

точкой и

подчеркнутой пере мен ной (например, Р.А).
При ведем два примера запросов, базирующихся на примере
Пример

5.2. Получить фамилии студентов 4 курса кафедры
4 (рис. 5.3).

4.1.

ИиУС,

имеющих балл не менее
Файл

Номер
студента

Фамилия

Балл

Курс

~.A

>-4

4

студента

СТУД
Рис.

Пример

5.3.

5.3.

Группа

Запрос фамилии по одной таблице

Получить фамилии студентов, руководителем кото­

рых является профессор кафедры ИиУС (рис.
Файл

Номер

Фамилия

студента

студента

Х

СТУД

Файл

ПРЕП

Кафедра

5.4).

Курс

Балл

Группа

Кафедра

Р.А

Номер

Фамилия

преподавателя преподавателя

Должность Кафедра Зарплата !надбавка
проф

у

ИиУС

Номер

Файл

преподавате

у

СТПР
Рис.

5.4.

Запрос фамилии по нескольким таблицам

Могуг быть использованы (в первом столбце запроса) агрегат­

ные функции

(SUM, AVG,

МАХ,

MIN,

СNТ-счетчик). Возможно

создавать виды (View).
QBE поддерживает справочник таблиц

[4],

процедуры обнов­

ления.

Реализация языка программирования
вариантов. Один из них для СУБД

149

QBE может иметь несколько
Access рассмотрен в гл. 5.

Контрольные вопросы

1. Что такое «отношение»?
2. Назовите характеристики отношения.
3. Что такое арность отношения? размерность? ключ?
4. Для чего используются ключи?
5. Что такое составной ключ (суперключ)? родительский
6. В чем цель нормализации?
7. Сформулируйте назначение 1-5 нормалЬНblХ форм.

и внешний ключи?

Глава

6

Сетевые и иерархические

базы данных
При изложении сетевой и иерархической моделей данных целесооб­
разно использовать такой порядок.

Сначала описывается логическая структура модели данных (МД),
затем

-

процессы использования построенной БД с помощью предло­

женного Э.Ф. Коддом языка Альфа

[9]

и, наконец, процедура программ­

ного описания (создания и использования) БД. Поскольку Альфа-опи­
сание указанных моделей данных не отличается от Альфа-описания
реляционной модели данных, оно опущено.

б. 1. ЛОГИЧЕСКАЯ СТРУКТУРА СЕТЕВОЙ БД
При различных способах реализации сетевых моделей
наибольшее распространение получила модель КОДАСИЛ

COnference

оп

DAta SYstems Language -

[1-11]
(CODASYL

Ассоциация по языкам си­

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

(DBTG - DataBase Task Group).

Эта модель считается наи­

более развитой сетевой моделью данных, постоянно развивается,
поддерживается и сопровождается, являясь как бы стандартом.
Ассоциация КОДАСИЛ образовалась в

БД, начиная с

1969

1959

г., а Рабочая группа

г., выпускала спецификации. Основы сетевой

модели были заложены в

1971

г. Комитетом по яод. Вместо Рабочей

rpуппы БД стала работать Рабочая группа языков БД, начавшая с рас­

ширения КаБаЛа. Серьезные результаты были получены в

1973

г. В

отчетах группы была описана сетевая модель данных, фактически
мало изменившаяся с тех пор. Основная цель КОДАСИЛ

-

созда­

ние иерархической модели, позволяющей описывать отношения

М: М, т. е. уменьшить недостатки иерархической модели.

Разрабатывались и соответствующие СУБД:

DMS (корпорации
DBMS (DЕС), IDS (Honeywell). В на­
стоящее время широко известна db _ Vista, работающая на персональ­
ных компьютерах в DOS и Windows.
UNIVAC), IDMS

(СuШпапе),

151

Структурными элементами сетевой модели данных КОДАСИЛ

являются элемент данных, агрегат данных и запись (рис.

6.1,

а),

которым присваиваются имена.

-

Элемент данных (ЭД)

наименьшая поименованная единица

данных (аналог поля в файловых системах), с помощью которой
осуществляется построение всех остальных структур. При меры эле­

ментов данных: «Табельный номер», «Шифр детали», «Год рожде­
ния». Имя элемента данных используется для его идентификации в
схеме структуры данных более высокого уровня. Значение элемента

данных может быть числовым (целым, вещественным), нечисловым
(символьным, логическим). В некоторых приложениях может ис­
пользоваться

«неопределенное»

значение

элемента данных

и

это

значит, что значение соответствующего свойства объекта не опреде­
лено в БД.
Агрегат данных

поименованная совокупность элементов дан­

-

ных внутри записи, которую можно рассматривать как единое целое.

Имя агрегата используется для его идентификации в схеме структуры
данного более высокого уровня. Агрегат данных может быть простым
(рис.
(рис.

6.1, 6),
6.1, в),

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

а)

Элемент данных

Агрегат данных

l

Запись 1--- Набор 1---

Г

База
данных

в)

б)

Дата

I

Число Месяц

Предприятие

I Год

Адрес

НазваниеПочтовый

Город

индекс

Улица
номер дома

г)

Заказ на покупку
Партия товара

Дата
Номер
заказа

заказа

о ~

~

~~~
Рис.

6.1.

U

с!)

0.0:1

О

:S:~

t:::

.е§'

~
I

~
с!)

0.0:1

О

:S:~

t::: ~

.е§'

~
I

0:1

0.0:1

.е§'
:S:~

S~ ~ ::::r S~ ~ l=:i .. S~

Структурные элементы сетевой БД

152

g 0:1

~

:z:
с!)

::::r

Различают агрегаты типа «вектор» И типа «повторяющаяся груп­

па». Агрегат, повторяющаяся компонента которого является про­
стым элементом данных, называется «вектором». Например агрегат

«Заработная плата», в котором экземпляр элемента данных может
повторяться до

12

раз (за каждый месяц года). Агрегат, повторяю­

щаяся компонента которого представлена совокупностью данных,

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

вторяющиеся группы. На рис.

г представлен агрегат «Заказ на

6.1,

покупку», имеющий в своем составе повторяющуюся группу «Партия
товара».

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

Запись

-

поименованная совокупность элементов данных и/или

агрегатов. Иными словами, запись

-

это агрегат, который не входит

в состав никакого другого агрегата и может иметь сложную иерар­
хическую

структуру,

поскольку допускается

многократное

приме­

нение агрегации. Имя записи используется для идентификации типа
записи в схемах типов структур более высокого уровня.
Записи являются фактически простейшими структурными эле­
ментами,

через

которые

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

связи:

элементом

связи

служит набор.
Набор записей

-

поименованная совокупность записей, образу­

ющая двухуровневую

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

структуру

подчинения:

каж­

дый тип набора представляет собой отношение (связь) между двумя
или несколькими типами записей. В силу иерархичности набора для

каждого его типа один тип записи объявляется «владельцем», тогда
остальные типы записей

-

«члены», т. е. имеют место «запись-вла­

делец» и «запись-член (набора»). Каждый экземпляр набора должен
содержать только один экземпляр записи-владельца и любое коли­
чество экземпляров записей-членов.

Структуры БД строятся на основании следующих основных ком­
позиционных правил.

1.

База данных может содержать любое количество типов запи­

сей и типов наборов.

2.

Между двумя типами записи может быть определено любое

количество типов наборов.

3.

Тип записи может быть владельцем и одновременно членом

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

153

При удалении записи-владельца удаляются соответствующие ука­
затели на записи-члены, но сами записи-члены не уничтожаются

(сингулярный набор).

Наборы могут быть нескольких разновидностей.

1.

С одними и теми же типами записей, но разными типами

наборов.

2.
Служащий
Анкетные

I

Система

.,_"_с_луж
__ащ_и_й...,"
данные

Наборы из трех и более запи­

сей, в том числе с обратной связью.

Сингулярный набор (только

3.

один экземпляр). У такого набора нет
естественного владельца и в качестве

его выступает система (рис.
Рис.

6.2.

Сингулярный набор

6.2).

В

дальнейшем такие наборы могут приобрести запись-владельца.

Количество объявляемых сингулярных наборов произвольно .

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

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

бора, а остальные

-

членами набора. На рис.

показан пример

6.3

многочленного набора «Научные труды», владельцем которого явля­

ется запись типа «Научный сотрудниК», а членами

-

записи типа

«Научный отчет», «Доклад на конференциИ», «Статья В журнале»,
Научный_сотрудник

Анкетные -ланные

Регистрационный_номер _отчета,
название,

Докл~на_конференции

ГО)Lвыпуска

Название-локла,ца,соавторы-локл,
название_коНференции, дата

Название_статьи, соавторы_ст,
название_журнала,

Название_м, соавторы_м,

Монография

Рис.

6.3.

номер_и_год

издательство,

Многочленный набор

154

год издания

«Монографию>. Экземпляр некоторого типа многочленного набора

включает в себя один экземпляр записи-владельца и все связанные с
ним экземпляры записей-членов заданных типов. В конкретных СУБД

концепция многочленного набора может быть не реализована.

В сетевой БД возможны следующие способы доступа:

•
•

последовательный просмотр записей основного файла;

просмотр всех записей зависимого файла, связанного с конк­

ретной записью основного файла;

•

прямой поиск записи основного файла по ее ключу (точка до­

ступа).
Отметим, что если запись используется для представления сущ­

ности, то набор

для представления связей меЖдУ рассматривае­

-

мыми сущностями.

Сетевые модели данных могут быть представлены в форме гра­

фов: вершины графа используются для интерпретации типов сущ­
ностей, а дуги

-

для интерпретации типов связей меЖдУ сущнос­

тями.

На графической диаграмме схемы БД тип набора изображается
поименованной дугой междУ соответствующими типами записей: дуга

исходит из типа записи-владельца набора и заходит в тип записи­
члена набора.

В модели КОДАСИЛ основным внутренним ограничением це­
лостности является функциональность связей, т. е. с помощью на­
боров можно реализовать непосредственно связи типа

М

: 1.

1 : 1, 1 : М,

В модели это первое внутреннее ограничение выражается ут­

веРЖдением: в конкретном экземпляре набора экземпляр записи­
члена набора может иметь не более одного экземпляра записи-вла­

дельца набора. Следовательно, число экземпляров набора некото­
рого типа в точности равно числу экземпляров записей-владельцев

этого типа набора в БД. При этом экземпляр набора может быть и
пустым, т. е. состоять из экземпляра записи-владельца (экземпляры
записей-членов могут отсутствовать в некоторые моменты времени

при функционировании системы).
Из функционального характера реализуемых в МД связей следу­
ет второе внутреннее ограничение целостности

-

экземпляр записи

может быть членом только одного экземпляра среди всех экземпля­

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

посредственно представлять в модели тип «многие ко многим». Для
представления связи типа М

:N

вводят вспомогательный тип записи

и две функциональные связи типа

155

1: М

(см. рис.

4.7).

6.2. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СЕТЕВОЙ БД
Представим в виде сетевой модели БД «Учебный процесс».
Возьмем за основу связи, показанные на рис.

прежнему присутствуют связи

M:N.

б (см.). Здесь по­

3.4,

Их замена возможна двумя спо­

собами:

•
•

использованием нормализации (рис.

3.4,

в);

введением, наряду с прямыми, обратных связей.

Второй путь характерен для иерархических МД. Поскольку в се­

тевой МД используются и ключи, ей более присущ первый путь.
Тогда сетевая модель получит вид, показанный на рис.

торые экземпляры логических записей

-

на рис.

6.4,

а неко­

6.5.

Отметим, что в отчетах КОДАСИЛ первоначально предполага­
лось обязательное участие программиста в работе БД. В последую­
щих версиях предусматривалось минимальное участие программис­

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

БД от физической БД. ЭТО хорошо заметно из рис.
на языке СУБД

DBMS,

приведенной ниже.

SCHEMA NAME IS ОВ_2
AREA NAME IS DB2_AREA
RECORDNAME IS PART .
LOCATION МООЕ IS CALC HASH_PS
USING PS in PART
DUPLICATES NOTALLOWED
WITHIN DB2~REA
PS ТУРЕ IS CHAR 5
РО ТУРЕ IS CHAR 25
CL ТУРЕ IS CHAR 2
RECORDNAME IS WH
WITHIN DB2_AREA
WS ТУРЕ IS CHAR 5
WD ТУРЕ IS CHAR 25
SEТ NAME IS INVENTIORY
OWNER IS PART
MEMBERISWH

156

6.5

и программы

Рис.

6.4.

Структура сетевой БД

~иусllS4-12-80 Iсорокин п.в·l-

г-----1А11 1s I4 ,зl
г1А2 12214,0j.----гfАзl18~,2

IЛППI171-12-0sIБорисов Б.вl-I1тппI212-10-81 1Степанов и.в.r- 1-1-

~IА-174~Серов А.п·1197914,зl
~~-1832Iпикин п·ф·11976Iз,91
1- f--~1A-1840ITYКOB

ф·к.1197714,21

1~

3811 Шаталов А.с.lд·х.нlПРОфессор~

13871Сифоров п.д.lд·х.нlПроФессорj.-137з1Евдокимов с.С·lд·х.н·IПроФессо~
г-lКибернетика 1300 1120lДоцентI
Математикаl600 1200 1Доцент 1

n

Ir-

~ Лекцииl120

~t

~IЛекции1200
Рис.

6.5.

Экземпляры логических записей

MANDATORY AUTOMATIC
ASCENDING КЕУ IS WS in WH
DUPLICATES NOT ALLOWED
SEТ

OCCURRENCE SELECTION IS THRU
LOCATION МООЕ of OWNER
Базовыми языками в сетевых СУБД могут быть

В частности, дЛЯ СУБД

DBMS

COBOL, PL/I.
COBOL, а
приведено в табл. 6.1.

базовым языком служит

соответствие его команд командам языка БД

Таблица
Соответствие команд языков БД и

6.1

COBOL

Язык БД

COBOL

AREA

REALM

OPEN

READY

CLOSE

FINISH

FIXED

НЕТ

MANDATORY

PERMANENT

OPTIONAL

TRANSIENT

AUTOMATIC

AUТOMAТlC

MANUAL

MANUAL

INSERT

CONNECТ

REMOVE

DISCONNECТ

MODIFY

MODlFY

STORE

STORE

DELETE

ERASE

в физической модели выделено понятие «схема»

-

совокупность

типов записей и связей между ними.

База данных физически состоит из областей

(AREA),

которые

разделены на блоки, называемые страницами. Размер страницы,
каждая из которых имеет уникальный номер в одной и той же обла­
сти, определяется пользователем. Номер страницы и строки в ней

158

образует физический ключ записи, а логическая структура реализу­

ется с помощью указателей. Поиск в логической структуре может
осуществляться по ключу, что в физической структуре реализуется

указателями. Указатели (абсолютные или относительные) MOryT иметь
цепочечную организацию (от записи к записи) или в виде массива
указателей.

Создание сетевой БД (ЯОД)
Иллюстрацию ЯОД удобно провести с помощью программы,
приведенной ранее.

Программа определяет имена схемы

(SCHEMA),

области

(AREA)

возможно и с объявлением начальной и конечной страниц. В об­
ласть возможно копирование

(CALL) из других схем. Задаются за­
(RECORD) и вводится метод их размещения (LOCATION
MODE IS .. ), определяющий способ хранения. Различают методы
DIRECT, CALC, VIA SET, SYSTEM, INDEX.
Метод DIRECT самый быстрый: управление осуществляет пользо­

писи

ватель путем присваивания адресов. В последних версиях этот ме­
тод исключен.

Метод

CALC

(ключ указывается после слова

USING)

предус­

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

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

Размещение через набор

VIA (SET)

применяется, когда запись­

член направляется на ту же страницу, где находится запись-владе­

лец. Метод

SYSTEM

применяется по умолчанию, а метод

INDEX

используется редко.

Указывается возможность наличия
щихся данных, расположенных в начале
записей-членов, либо их запрет

(DUPLICATES) повторяю­
(FIRST) или конце (LAST)

(NOT).

Необходимо указать и связи набора: запись-владелец

(OWNER),
(MEMBER), размещение записи-члена после экземп­
ляра записи-владельца (FIRST), после последней записи-члена
(LAST), после текущей записи (NEXT), перед текущей записью
(PRIOR), отсортированные записи (SORTED), тип указателей (NET,
PRIOR).
запись-член

Предусматриваются своеобразные процедуры включения (и ис­

ключения) записей (рис.

6.6),

более подробно описываемые в ЯМД.

159

I

l Запись J
Присоединение

Отсоединение

,

(исключение)

МANDATORY
Обяза-

(исключение)

,

I

I

OPTIONAL

AUTOМAТIC

Необяза-

Автомати-

тельное

ческое

тельное

,

,

МANUAL
Ручное

,

,

DELETE

REMOVE

STORE

INSERT

Уничтожить

Исключить

Включить

Вставить

Рис.

6.6.

Процедуры присоединения и отсоединения записей
на языке СУБД DBMS

Устанавливается выбор экземпляра набора, в частности, по спо­
собу размещения владельца

THRU

LOCAТION МООЕ

(SET OCCYRENCE
ofOWNER).

SELECТION

Может устанавливаться и блокировка монопольная

IS

(EXCLUSIVE)

инемонопольная (КЕЕР).

Использование сетевой БД (ЯМД)
Команды ЯМД возможно разделить на несколько групп.

Открытие и закрытие БД производится командами О PEN и

CLOSE.
Доступ осуществляется командами

манда

FIND (FIND RECORD

точка входа»

FIND, GET, OBTAIN.

Ко­

ОВ_КЕУ =

о непересекающихся под­

множеств Т!, Т2 , ••• , Тm , каждое из которых в свою очередь является
деревом.

Деревья Т!, Т2 , ••• , Тm называются поддеревьями корня.

Из определения следует, что любой узел дерева является корнем

некоторого поддерева, содержащегося в полном дереве. Число под­
деревьев узла называют степенью узла. Узел называется концевым,
если он имеет нулевую степень. Иногда концевые узлы называют

листьями, а ребра

-

ветвями. Узел, не являющийся ни корнем, ни

концевым узлом, называется узлом ветвления.

Таким образом, иерархическая древовидная структура, ориенти­
рованная от корня, удовлетворяет следующим условиям:

162

•
•
•

узел состоит из одного или нескольких атрибутов;
иерархия всегда начинается с корневого узла;
на верхнем уровне может находиться только один узел

-

кор­

невой;

•

на нижних уровнях находятся порожденные (зависимые) узлы:

они могут добавляться в вертикальном и горизонтальном направле­

ниях без ограничения;

•

каждый порожденный узел, находящийся на уровне

i,

связан

ТОлько с одним непосредственно исходным узлом (непосредствен­

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

(i -1)

каждый исходный узел может иметь один или несколько не­

•

посредственно порожденных узлов, которые называются подобны­
ми (связи

•

1 : М);

доступ к каждому порожденному узлу выполняется через его

непосредственно исходный узел;

•

существует единственный иерархический путь доступа к любо­

му узлу, начиная от корня дерева (рис.

6.7),

например путь

ABEI.

Поскольку узлы, входящие в иерархический путь, могут встре­

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

рассматриваемого

узла,

является

для

последнего

исходным

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

узлом.

В иерархических моделях данных используется ориентация дре­

вовидной структуры от корня, т. е. дуги, соответствующие функци-

Рис.

11"

6.7.

Иерархический путь доступа

163

ональным связям, направлены от корня к листьям дерева. Графи­

ческая диаграмма схемы базы данных для иерархической базы дан­
ных называется деревом определения.

Вершины дерева определения БД соответствуют введенным ти­
пам групп записей, с помощью которых выполнена интерпретация
типов сущностей. Обычно допускают только простые типы групп, т. е.
группа,

представляющая

вершину дерева определения,

не должна

включать составные и повторяющиеся группы, но их можно пред­

ставить как самостоятельные вершины дерева определения. Корне­
вой вершине дерева определения соответствует тип корневой груп­

пы, остальным вершинам
определения,

-

типы зависимых групп. Дуга дерева

соответствующая групповому отношению,

представ­

ляет некоторый тип связи между рассматриваемыми типами сущно­

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

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

Тип зависимой группы можно идентифицировать соответствующей
последовательностью связей «исходныЙ-порожденныЙ». Иерархи­
ческий путь в дереве определения представляется последовательно­
стью групп, начинающейся типом корневой группы и заканчиваю­
щейся типом заданной группы.

Следствием внутренних ограничений иерархической модели яв­
ляется то, что каждому экземпляру зависимой группы в иерархи­

ческой БД соответствует уникальное множество экземпляров ро­
дительских групп (по одному экземпляру каждого типа родительс­
кой группы).
Иерархия

-

это разновидность сети, являющаяся совокупнос­

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

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

-

тип

виртуальной логической записи (необходим, когда надо поместить
какой-либо тип записи в два или более деревьев иерархии или в
нескольких местах в одном дереве). Такая логическая запись пред­

ставляет собой указатель на логическую запись не которого типа и
устраняет избыточность.

Снова обратимся к рис.

3.4,

в (см.). Теперь придется перемес­

тить некоторые поля в другие таблицы. На рис.
связь ряда таблиц.

164

6.8

показана прямая

Рис.

6.4.

6.8.

Структура иерархической БД

ПРОГРАММНАЯ РЕАЛИЗАЦИЯ

ИЕРАРХИЧЕСКОЙ БД
в иерархической МД имеется сильная зависимость логической
структуры от физической, что хорошо видно из рис.
мы на языке СУБД

IMS,

6.9

и програм­

приведенной ниже.

ОВО NAME=OB3, ACCESS=HISAM
OATASEТ 001 =ОЕРТО01, OEVICE=3380, OWFLW=OEPTOVF
SEGM NAME=PART, BYТES=32
LCHILO NAME=(COMP_ASSEMB, ОВ3), PAIR=ASSEMB_COMP

FIELO NAME=(PS, SEQ), BYТES=5, START=1
FIELO NAME=PO, BYТES=25, STAAT=6
FIELO NAME=CL, BYТES=2, START=31
SEGM NAME=ASSEMB_COMP, BYТES=10
POINTER=(LPART, ТWIN, LТWIN)
PARENT(PART), SOURCE(PART, PHISICAL, ОВ3)
FIELO NAME=(PS, SEQ), BYТES=5, START=1
FIELO NAME=OТY, BYТES=5, START=6
SEGM NAME= СОМР_ASSEMB, BYТES=1 О
POINTER=RAIDEA
FIELO NAME=(PS, SEQ), BYТES=5, START=1
PARENT РААТ, SOURCE(ASSEMB_COMP, ОВ3)
FIELO NAME=(PS, SEQ), BYТES=5, START=1
FIELO NAME=OТV, BYТES=5, START=6
165

Факультет
Шифр_факультета,
название

I

Курс
номер_курса,

I

Шифр_кафедры,
название_кафедры

дата_начала_сессии,
дата

окончания

сессии

I

Группа
ШИфрJрynпы,
фио_старостыгруппыы

Студент
Номер_по_порядку,

Кафедра

I I

I

Дисциплина

Шифр--.дисциплины,

название --.дИСЦИПЛИНЫ

I

номер_зачетной_книжки,

ФИО
Рис.

6.9.

Реализация иерархической БД

На внутреннем уровне древовидные структуры могут быть пред­

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

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

схеме этой базы данных. На рис.

6.9

приведен пример схемы иерар­

хической базы данных и ее возможной реализации на внугреннем
уровне.

Создание иерархической БД (НОД)
Базовыми языками иерархической БД по-прежнему может быть

COBOL, PL/I, Assembler.
Иллюстрацию ЯОД удобно вести на основе программы на языке

СУБД

IMS.

Объявляются имена БД, сегмента и полей. Для одного

из полей, по которому идет упорядочение, указывается метка

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

(U)

SEQ и

или много (М). От­

(PARENT) сегмент. Может присугствовать
(POINTER), метод доступа (HISAM).
166

поле

Введение логических связей обозначается командой

LCHILD,

в

которой указываются имена порожденного логического сегмента и
сегмента БД, а в команде

PARENT -

исходные физический и логи­

ческий сегменты БД.

Использование иерархической БД (ЯМД)
Обновление осуществляется командами REPLACE (заменить) и
DELETE (удалить текущий сегмент и порожденные). Вставка
(lNSERT) может быть по отношению к текущему исходному сег­
менту (INSERT S) или по указанию (INSERT клиенты WHERE
ГОРОД = 'СПб' and ИМЯ АГЕНТА= 'Святослав').

Помещение сегмента в область ввода-вывода осуществляется
командой

G ЕТ:

GET UNIQUE
WHERE ,
GEТNEXT,
GEТ NEXТ

WITHIN PARENT.

Из описания иерархической МД видно, что БД построить доста­
точно сложно. Здесь нет четкого разделения логической и физичес­
кой структур. Набор структур запросов ограничен, а для неиерархи­
ческих связей требуются дополнительные логические связи, пре­
вращающие фактически иерархическую МД в сетевую.

Контрольные вопросы

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.

Каковы структурные элементы сетевой модели данных?
Что такое элемент данных? агрегат? запись?
Назовите виды агрегатов.
Как обеспечивается связь между записями?
Каковы разновидности наборов?

Каковы правила построения сетевой БД?
Почему нельзя реализовать отношение М:

N?

Как оно реализуется?

Каковы структурные элементы иерархической модели данных?

Каковы типы сегментов?

Как обеспечивается двусторонняя связь между сегментами?
Как обеспечивается доступ к сетевой БД?

Глава

7

Объектно-ориентированные
базы данных
Серьезные недостатки реляционной модели данных привели к необхо­
димости поиска других моделей. Такой прогрессивной и перспективной

моделью данных является объектно-ориентированная модель данных.
В ней собственно база данных, интерфейс пользователя и алгоритм
приложения построены с использованием объектно-ориентированного
подхода.

Суть объектно-ориентированных баз данных иллюстрируется на СУБД
САСНЕ, получившей распространение в России. В этой СУБД, чтобы полу­
чать данные из многочисленных реляционных БД, предусмотрен объект­
ный доступ (объектно-ориентированная модель) и SQL-доступ (реляцион­
ная модель с использованием языка SQL2). Хранение данных в САСНЕ осу­
ществляется с помощью многомерной модели данных, позволяющей

уменьшить объем потребной памяти при одновременном увеличении ско­
рости доступа к данным.

7.1.

НЕДОСТАТКИ РЕЛЯЦИОННЫХ БАЗ ДАННЫХ

Автор реляционной модели данных Э.Ф. Кодд первоначально
сформулировал

12

требований к БД, чтобы она могла называться

реляционной. В дальнейшем этот перечень увеличился до

333

тре­

бований. Им, несмотря на широкое распространение реляционных

баз данных, не удовлетворяет ни одна из известных СУБД.
Более того, при значительных объемах данных начинают прояв­
ляться недостатки реляционных баз данных. К этим недостаткам

относятся: сложность структуры, вызванная необходимостью про­
ведения нормализации; низкая производительность из-за поиска по

ключу, что в

3-5

раз увеличивает количество операций доступа;

ограниченный набор типов данных; представление данных только в
виде двумерных таблиц и невозможность реализации таблиц с не­
линейной структурой; не возможность послойного рассмотрения дан­

ных (например, «Работающие»
ки» И «преподаватели»

-

-

в одном слое, «научные сотрудни­

В другом, подчиненном слое); нестыковка

168

с принципами все более широко применяемого объектно-ориенти­
рованного подхода; невозможность задать для определенного типа

данных набор операторов-методов, которые приходится вводить в

конкретном приложении; возникновение коuфузuu

-

утраты при

многочисленных обновлениях третьей (а порой и второй) нормаль­
ной формы; сложность совмещения с другой парадигмой хранилищ
данных.

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

построение объектно-ориентированной базы данных (ООБД). Ее
появление стимулировано и требованиями большой быстродейству­
ющей памяти (свыше

изводства

20
(CADjCAM).
7.2.

Гбайт) для систем конструированияjпро­

СОСТОЯНИЕ РАЗВИТИЯ ООБД

в соответствии с «Манифестом ООБД»

1989

[2],

опубликованном в

г., используется формула

ООСУБД = СУБД
где сокращения

00

+ ООЯП,
и ЯП означают объектно-ориентированный

язык программирования. ООСУБД должна поддерживать объекты
с нелинейной структурой (сложные объекты, в том числе с иерар­

хией типов), что достигается инкапсуляцией и наследованием. Легко
поддерживается расширяемость,

вычислительная

полнота,

языки

запроса.

В 1991 г. была сформирована группа Object Database Management
Group (ODMG), перед которой была поставлена цель построить стан­
дарты дЛЯ ООБД хотя бы на уровне стандартов для реляционных
БД. В

1993

г. эта группа предложила своеобразный стандарт для

ООБД, названный

1)
2)
3)
4)

ODMG-3, который включал:
Object Data Model (ООМ);
язык определения объектов Object Definition Language (ООЦ;
объектный язык запроса Object Query Language (OQL);
объектную модель

интерфейсы языков программирования (С++ и других).

В настоящее время насчитывается свыше

300 объектно-ориентиро­
7.1.

ванных СУБД (ООСУБД), данные некоторых приведены в табл.
Сфера их применения указана в табл.

Из табл.

7.1

7.2.

видно, что ООСУБД создаются с использованием

различных подходов.

Выбор ООСУБД может определяться наличием поддержки ре­

ляционных БД; интерфейса с языками С и расширениями

169

SQL;

Таблица

7.1

Характеристики некоторых ООСУБД
Фирма-

НаЗl\aние ООСУБД

IlроизнодитеJlЬ

Objectivity
Рое!

CpeдcТlla разработки

С. С++,

Objectivity/0 В

Soliware

SQL. Java

С, С++, ОDБС,

Рое!

Object Oesign

Подход к разработке

Java
С. С++,

Object Store

Java
Расширение объ-

Ontos

'пс.

С++.

Java

С++,

Java

С++,

Java

ектно-ориентиро-

ванных библиотек
классов

Versant Objec!
Technology

Ontos

Computer Associate

Jasmine

НПU «Интелтек

ОБ,

Versant

OOB-Jupiter

Плюс»

С++

Всшвка объектно-

02 Technology

с++,

02

ориентированного

Java

языка БД в обычHый базовый язык
Расширение языка

GemStone l пс.

С++,

GemStone

(С++) возможнос-

Java

тями работы с БД

Semantic Information Manager,
Cache ObjectScript

САСНЕ

InterSystems

Новый язык базы
данных или модели данных

средств разработки и администрирования; доступа к данным из дей­

ствующих БД (с помощью ООВС и SQL-запросов); возможности
работы с различными платформами.

Фирма
тельскую,

BKS Software
переносимую,

предлагает ООСУБД
интегрированную

механизмами транзакций в средах

Poet

как пользова­

с двумя

ступенчатыми

Windows NT, Unix

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

нием базового языка С++.

В России
бург)

-

-

при активной работе фирмы СП.АРМ (С.-Петер­

все шире используется СУБД

Cache

фирмы

InterSystems,

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

170

Таблица

7.2

Сфера применения ООСУБД
Vcrsant

GcmStonc

02

ObjcctStory

РОЕТ

МодеЛИРО8ание

+

+

+

+

+

САПР

+

+

+

+

+

Управление произ-

-

+

+

+

+

+

+

-

+

+

CASE

+

+

-

+

+

Планирование

+

-

-

-

-

+

-

+

+

+

-

-

-

+

-

+

-

-

+

8Одством

Обработка изображения

Гипертекстовые
системы

Издательство

Экспертные системы

Нет информauии

Следует заметить, что ООСУБД все чаще применяют как со­
ставную часть другого приложения.

Например, компания

Computervision,

про изводящая программное

САD-обеспечение, интегрировала в свой продукт СУБД
Компания

MKS,

Enterprise Integration Technology

ObjectStory.

предлагает продукт

позволяющий вести разработку технологических процессов и

оборудования; управление предприятием; проектирование производ­
ственных помещений; диагностику, мониторинг (отслеживание);
моделирование и планирование.

Американские фирмы

AototroI Technology, Step Tools, Dec ис­
ObjectStory для работы со слабо структуриро­
в стандарте Standard of Exchange of Product model

пользуют ООСУБД

ванными данными

data (STEP)

обмена данными.

7.3.

СУЩНОСТЬ ООБД

Суть объектно-ориентированной БД определяется объектно-ори­

ентированным подходом (рис.

7.1),

который подразумевает объект­

но-ориентированное проектирование и объектно-ориентированное
программирование.

171

Объектноориентированный
подход

1

I

I

Объектно-

Объектно-

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

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

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

проектирование

Рис.

7.1.

Объектно-ориентированный подход

Объектно-ориентированное nроектирование

методология про­

-

ектирования, соединяющая в себе процесс объектной декомпози­

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

Объектно-ориентированное nрограммирование

-

методология про­

граммирования, основанная на представлении программ в виде свя­

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

Объектно-ориентированное проектирование предполагает не
только деление (декомпозицию) базы знаний или базы данных на
составные части (рис.

7.2),

но и рассмотрение общей этапности ре­

ализации БД, выбор инструмента реализации с учетом оговоренных
в техническом задании вариантов реализации.

I

Компьютер I

База

Алгоритм
работы

данных

_____________________ J

I
I
I
I
I
I
I

Интерфейс
пользователя

•

+

Пользователь

Рис.

7.2.

Объектно-ориентированное проектирование

172

Объектно-ориентированное программирование берет за основу

модель атомарного элемента (рис.

7.1).

Дело в том, что, несмотря на мощные средства отладки про­
грамм, для повышения производительности процедуры программи­

рования целесообразно отлаживать программы последовательно, по
блокам. Программа в целом отлаживается быстрее, если блоки были

отлажены заранее. Эти предпосылки и положены в основу объект­
но-ориентированного программирования.

Любая математическая модель имеет вид, представленный на рис.

7.1,

а сложная

-

на рис.

7.3.

Выделяется несколько специфических понятий. Класс

фактически некоторый блок со структурой (рис.

7.1).

-

это

Однако здесь

используется несколько другая терминология. Данные называют свой­
ствами, а алгоритмы
через свойства

-

-

методами. Доступ к классу осуществляется

в статическом режиме написания и отладки про­

граммы или через методы

-

в процессе выполнения (работы) про­

граммы.

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

название объекта.
В объектно-ориентированном программировании используются

три основных принципа: инкапсуляция, наследование, полиморфизм.
Инкапсуляция

-

выделение класса с доступом к нему через свой­

ства или методы.

Класс А

Базовы й

Свойства Методы

класс

1

~

Класс АБ

Свойства Методы

Свойства Методь

ПризводньIe
классы

С

ОБЬ:Т~~ -1-__________

Программ

~

Класс М

а : IОбъект М 11

-1-___ ~:~ь:~:1-

Jnбъект АЫ

'

l.

Ее необходимо преобразовать в модель М., обладающую отме­
J

ченными ранее характеристиками.

Преобразование назовем nравuльным, если справедливы свой­
ства:

1)

полная определенность, т. е. любое состояние модели М ; пред­

ставимо в модели М.;

2) интерпретируе'мость: любой оператор ЯМД в М ; имеет интер­
Mj ;
3) воспроизводимость: любое изменение БД в М. выполняется
некоторым оператором изменения, воспроизводимого средствами М ..
Рассмотрим эти свойства детальнее.
J
1. Введем операторы а: S. ~ S.;
'
1
1:
В.
~
В
..
Тогда
должна
быть
J
J
коммутативна диаграмма на рис. 11.5, а, б или
претацию в ЯМД

I

I

I

264

Sj
Типы

с)

Оператор

PROG;

О;

Id

1 В;

Мо;

! .~~}
О;
1 В]

PROG;

Процедура
Рис.

V

Коммутативные диаграммы ЯОД и Я МД

11.5.

Ms ..
I

Отметим, что В ; и

Bj

(J

=

\If.

't"

MsJ..

в конечном счете характеризуются множе­

{У ; 1, ... , Уn и

ствами

Vj(S) =

k = m

и говорят о подобных типах данных. Однако он встречается

Vj(Sj) =

редко, о чем свидетельствует
реляционных СУБД (табл.

[14]

{У/'

... , vjm}.

В простейшем случае

пример СУБД

11.1-11.4).

Access

и «подобных»

Здесь лучше говорить не о пер­

вичных типах данных, а о некоторых классах (табл.

11.3, 11.4)

про из­

водных типов данных и построении отображения этих классов.
Таблица

Типы данных СУБД
ТИIII\НННЫХ

Access
Характеристика

255

Текстовый

байт

кбайт

Мето

64

Числовой

1,2,4,

Х байт

Дата/Время

Х байт

Денежный

Х байт

С'IеТ'IИК

4 байта
I

ЛОГИ'lеский
Объект

ДО

OLE

265

байт

I

Гбайт

I/. I

Таблица

Соотношение типов данных СУБД

11.2

Paradox и Access
Access

Paradox

Alphanurneric

Текстовый

Nurnber

Числовой с плавающей запитой,

Short Nurnber

Числовой; целое

Сиггепсу

Денежный

Date

Дата/Времи

8 байт

Таблица
Соотношение типов данных СУБД

BTrieve

BTricvc

и

11.3

Access

Acccss
Текстовый

String. Istring, zstring
Integer
1 byte

Числовой. Байт

2 byte

Числовой; целое

4 byte

Числовой; длинное целое

FIoat, bitloat
4 byte

Числовой с плавающей тоt[кой

8 byte

Числовой с плавающей точкой

Decirnal, nurneric

Числовой с плавающей точкой

Мопеу

Денежный

Logical

Да/Нет

Lvar

Объект

OLE

Иными словами, речь идет о непересекающихся множествах

вида С;(У)

=

{С;,}, С;' Е У;> r = 1, R и Cj(V)

=

{С/}, s = f,S, при этом

С;' ~ С/ без потери информации. Тогда имеет место посредством
оператора \jI отображение
этом отображение

2.

cr

C.(Y.(S.»
I

I

I

~

c.(V.(S.»,
J
J
J

где

S.J

=

cr(S.),
I

при

(преобразование типов) должно быть бuекmuвно.

Обеспечение интерпретируемости предполагает, что реализа­

ция программы

PROG;

(или оператора О;) на ЯМД М; эквивалентна

266

Таблица

Соотношение типов данных языка
SQL

Acccss

Char

Текстовый

Vaгchar

Текстовый

Tinint

Числовой.

Smallint

Числовой; целое

Integer

Числовой; длинное целое

Real

Числовой с плавающей точкой

Float

Числовой с плавающей точкой

ОоиЫе

Числовой с плавающей точкой

Date

ДаТ'djВремя

Time

ДаТ'djВремя

Timestamp

Да/Нет

Image

Объект

реализации программы
аграмма на рис.

11.4

SQL и СУБД Access

11.5,

с.

PROG.J

4

баЙТ'd

OLE

на ЯМД М., т. е. коммутативна диJ

Тогда общая связь ЯОД и ЯМД различных моделей данных мо­

жет быть представлена в виде схемы, показанной на рис.

Pj -

11.5,

д, где

процедура.

3.

Говорят, что функция
-->Ре (JA=A(SB=2(S),PA,C(SB=2(T»»
Рис.

[2. [.

Использование унарного оператора в конце (а)

и в начале

(6)

преобразования

278

S,

затем осуществлять

2

РА

РА

I

I

DF~

I

SB>10 SX=5 SX=5
-1

I

I

S(A,B,
C,D)

Т(А,В,

Узел

Узел

SBIO
J B=B----.J
-:::-l
SX=5

1 в =в

I

---:--l

SX=5
I

С,Х)

1

I

DFi

C

JB=B~JB=Bl

I

РА

2

S(A,B,
C,D)

Т(А,В,

Узел

Узел

С,Х)

1

РА (DF(JB=B(S,SX=5 (Т»

S(A,B,
C,D)
Узел 1

2

Т(А,В,
С,Х)

Узел

2

),JB=B(SB>tO,(S),SX=5 (Т») )-->

-->SB - уменьшение размера шрифта;
- выделение текста;
- нижний индекс;
- верхний индекс;
- переменная.
Списки:

- LI - нумерованный список;
- где type имеет такие значения: 1 - 1, 11,
111, ... ; i - 1, 2, 3, ... ; А - А, В, С, ... ; а - а, Ь, с, ....
Рисунки:


Таблица:



-

таблица;
- заголовок таблицы;

строка таблицы;

заголовок столбца или строки внутри

TR;

ячейка таблицы.

Форма:

атрибута:

post,

представляет интерактивную форму ввода и имеет два

method

и асНоп (действие). Чаще всего используют метод

как способ передачи ISАРI-программе введенных данных. На­

пример,

< form method= POST action=getphone.htm>.
-

поле ввода, задаваемое внутри тега

. Input имеет

много атрибутов, из которых рассмотрим основные: пате (название
поля),

value

(значение поля),

type.
294

Например,

.
В свою очередь, атрибут

type

тоже имеет несколько значений.

Рассмотрим основные из них.

type=text - задает однострочные текстовые
type= password - определяет пароль;
type=radio - задает радиокнопку;
type=checkbox - определяет флажок.

поля;

Например,

Select the credit card to place the order:
Visa
Master Card.

Type=range -

проверка диапазона задания (от минимума до мак­

симума);

Type=hidden -

скрытые поля, которые используются обычно для

формирования правил проверки. Например,





.

в последней строке

submit -

это кнопка, нажатие которой вы­

зывает передачу введенных данных полей в Web-сервер, при этом

value

определяет название кнопки.

Аналогично задается кнопка

reset

для сброса значений полей к

начальному состоянию.

Тег



отображает с помощью тега



некоторый

список:


tea
coffee
water
.
Для создания многострочного окна используют тег

295

.

13.3.

РЕАЛИЗАЦИЯ ПУБЛИКАЦИИ

Теперь возможно рассмотреть пример публикации базы данных,
т. е. процедур Б и 2А примера

ника данных

-

13.1.

Процедура

lA -

создание источ­

реализована в виде базы данных.

По-прежнему пример выполним в рамках приложения
Для выполнения публикации удобно

-

Delphi.

для передачи базы дан­

- использовать специальные компоненты
TQueryTableProducer.
В частности, компонента TQueryTableProducer позволяет обра­
щаться к базам данных на основе СУБД Access и InterBase, в кото­
ных

на www-страницу

TDatasetТableProducer и

рых таблицы размещаются в одном файле, через имя БД (файл) и

SQL-оператор

select

с указанием в нем имени таблицы и публикуе­

мых полей.

Для учебных целей составим простую программу с передачей
полей таблицы в некотором цикле'.
Исходная таблица построена в СУБД

Paradox

(рис.

13.2).

Она публикуется с помощью следующей программы.
ReslfUclure Paradox 4 ТаЫе: lаЫе.DВ
I

.'

.Eie1d rO$ter.

Рис.

I

13.2.

Отображаемая таблица

Работа выполнена С. Кузнецовым под руководством авторов.

296

unit Unit1;
interface
uses
Windows, Messages, SysUti/s, C/asses, Graphics, Contro/s,
Forms, Dialogs,
OleCtrls, SHDocVw, Grids, DBGrids, DЬ, DBTabIes, НТТРАрр,
StdCtrls,
Buttons, DBWeb;
type
TForm 1 = class(TForm)
DataSource 1: TDataSource;
ТаЫе1: ТТаЫе;

DBGrid1: TDBGrid;
BitBtn1: TBitBtn;
BitВtn2: TBitBtn;
ВitВtпЗ: TBitBtn;
WebBrowser: 1WebBrowser;
procedure BitBtn1Click(Sender: TObject);
procedure BitBtn2Click(Sender: TObject);
procedure ВitВtпЗСliсk(Sепdег: TObject);
procedure FindAddress;
private
{ Private declarations }
pubIic
{ PubIic declarations }
end;
var
Form 1: TForm 1;
implementation
{$А

*.DFM}
uses shellapi, filectrl; j jподключение модулей
procedure TForm1.FindAddress;
var
Flags: OLEVariant;
297

begin
Flags:= О; /jycTaHoBKa адреса броузера
WebBrowser. Navigate(WideString('с: \ HTMLTEST. htm'), Flags,
Flags, Flags, Flags);
end;
procedure TForm1.BitBtn1Click(Sendeг: TObject); //закрытие формы
begin
close;
end;
pгoceduгe TFoгm1.BitВtn2Click(Sendeг: TObject); //алгоритм пуб­
ликации

vaг

HTMLStг: TStгingList;

I,k:

Integeг;

Begin / /основные теги HTML
HTMLStг:= TStгingList.Cгeate;
HtmIStг.Cleaг;

HtmlStг.Add

('');

HtmlStГ.Add ('');
HtmlStГ.Add (''

+

'НТМL-страница, содержащая отчет

из БД'+ '') ;
HtmlStГ.Add ('') ;
HtmlStГ.Add ('.
ЗЗ4

Фрагмеuтация и локализация. Обычно предполагаетсн горизон­

тальная и вертикальная фрагментация. Горизонтальная фрагмента­
ция предусматривает деление однотипных данных по узлам. В рас­
сматриваемом случае она означает разделение задач

по клиентам

и

условное деление данных между ними с помощью приложений, раз­
мещаемых на компьютерах-клиентах. Локализация (принязка дан­

ных К узлам) в клиентском режиме также предельно упрощена, по­
скольку данные размещены на сервере.

Реализация распределенной БД
При использовании режима клиент - сервер во з никают такие
задачи для сервера и клиентов.

Для сервера

Построение структуры системы таблиц на сервере, возможно

1.

с системой запросов (видов) для заполнения таблиц , с установлени­
ем связей междутаблицами.

Заполнение таблиц данными.

2.
3.

Обеспечение доступа через виды, запросы и хранимые проце-

дуры .

Для клиентов

Разработать необходимые приложения.

1.
2.

Построить соответствующие интерфейсы польз ователей.

В данной главе рассмотрим локальный вариант режима клиент­

сервер. Особенности формирования удаленного варианта с одно- и
многоуровневой структурой обсудим в гл.

15.

Собственно база данных. Необходимо выполнить следующие ра­
боты.

•
•

Построение таблиц .
Установление связей между таблицами для осуществлеllИЯ ссы­

лочной целостности в РБД.
• Использование хранимых процедур для обеспечения ссылоч­
ной целостности.

•

Создание системы генераторов для обеспечения автоматичес­

кого заполнения полей, требующих автонумерации .

•

Загрузка таблиц данными из существующей БД «Учебный про­

цесс».

Построение структуры таблиц. Все операции по созданию струк­

туры таблиц РБД в

Windows ISQL
(рис. 14.14).

InterBase

осуществляются при помощи утилиты

(WISQЦ, поставляемой в комплекте с сервером РБД

335

QffiI EJ

~ DllnterBase Interactive SQL
.~.

I"SQL StateJ:nent
select • Irom grupp~

.. )

JSQLOutput

(.~

=sc:~eC't

*'

NG

NАЗVANIЕ

А/97

ЛОЗ

ДMe~MQC:

А/98

АО2

~Me~Moe

А/99

AO~

~Me~Moe

ВА/94

Иб

ДMC:~MOC:

БА/95

И5

~Me~Moe

БА/96

И4

~Me~Moe

БМ/94

АОб

~Me~Moe

БМ/95

АО5

~Me~Moe

БМ/96

АО4

~MeSMoc

ВТ/94

ВТб

ДMC:~Moe

БТ/95

БТ5

~Me~Moe

-Erom

БТ/96

БТ4

ДMC~Moe

ВТ/97

ВТЭ

ДMe~Moe

ВТ/98

БТ2

-;r-f .--,;t ~/

~~ I .

;i···.,:{:~>".....

.4.. _"о

grupp=t

ДMe~Moe

-.. jI...~'7·,·Ji.&?:'''':';''О;~

·;\·I""~·"

.') - j' ,: " ~-a

-]'

.~

I .~~,:, ;.>::;1>.':1,: ;,?:~;~}";:.~·:t~~:. .:r;.уЖ:~?~{~~~jJJ~А.,;rZ;·.(~~~j> ~ ,.

!I Local Seтve!

IDatabase: E:\DiQlom\P.ROJECТ\deKanat\Bases.gdb
Рис.

14.14.

Окно

Windows ISQL

Создание таблиц и других объектов РБД выполняется на язы­
ке

SQL.
Язык

QBE

серьезно ограничивает разработчика и позволяет ему

создавать запросы только по готовым шаблонам, которые были за­
ложены создателями языка.

Приведем пример создания таблицы
ТаЫе:

gruppa:

GRUPPA, Owner: SYSDBA * j
TABLE GRUPPA (NG VARCHAR(6) СНАААСТЕА SET
WIN1251 NOT NULL,
NAZVANIE VARCHAR(6) СНАААСТЕА SEТ WIN1251,
ОТО VARCHAR(20) СНАААСТЕА SET WI N 1251 ,
STAROSTAVARCHAR(20) СНАААСТЕА SEТWIN1251,
STAR_POLN VARCHAR(50) СНАААСТЕА SEТWIN1251,
KURATOR VARCHAR(20) СНАААСТЕА SEТ WIN1251,
KURS VARCHAR(50) СНАААСТЕА SEТWIN1251,
j*

САЕАТЕ

336

SH_SPEC INTEGER NOT NULL,

GOD_NABOR INTEGER,
STUDENTOV INTEGER,
DEVUSHEK INTEGER,

UNOSHEY INTEGER,
BESPLATN INTEGER,
CHAST INTEGER,

POLNPLATN INTEGER,
CONSTRAINT GRUPPRIMKEY1 PRIMARY

КЕУ

(NG));

Последняя строка указывает на то, что поле

NG (номер группы)
SH_SPEC INTEGER
создать колонку sh_spec

является первичным ключом. Инструкция типа

NOT NULL указывает на то,

что необходимо

типа Integer с обязательным ненулевым значением.
Всего РБД насчитывает 18 таблиц:

• ArhivStud -

архивная таблица, содержащая информацию об

успеваемости студентов, за прошедшие семестры;

• Gruppa -

• IPP -

список всех групп;

таблица, хранящая информацию о прохождении студен­

тами производственной практики;

• Izuchenie -

таблица с информацией об изучаемых предметах в

группах;

•
•
•
•
•
•

Kafedra - список кафедр;
Laba - список;
Obshegit - список студентов, живущих в общежитиях;
Oplata - информация об оплате студентами своего обучения;
Predmet - список преподаваемых предметов;
Predpr - список предприятий, на которых проходят производ-

ственную практику студенты;

•
•
•
•
•

Prepod - список преподавателей;
Prikaz - приказы;
Specialnost - список специальностей;
Student - список обучающихся студентов и сведения о них;
TempUsp - промежуточная таблица, необходимая для генера­

ции сложных отчетов, которые не могут быть организованы только
с использованием запросов;

• Uspevaem • Vid--prikaz -

информация о сдаче сессии студентами;

виды приказов.

После создания таблиц программист может извлечь из РБД

SQL-

команды, которые он вводил в процессе создания таблиц. Такая

информация, получаемая из РБД, называется метаданными. Тек­
стовый файл, содержаший метаданные, может быть в случае необ22 - 4840

ЗЗ7

ходимости повторно выполнен, что позволит в случае полной поте­

ри РБД, восстановить ее структуру без повторного, утомительного
набивания всех SQL-команд. Для получения подобной информации
необходимо в утилите

Windows ISQL

Metadata for DataBase,

выбрать в меню

Extract/SQL

после чего указать имя файла, в котором

необходимо сохранить метаданные. Листинг SQL-программ разра­

ботанной РБД приведен в Приложении

2.

Установление связей между таблицами. Для создания связей в

WISQL

PRIMARY КЕУ (NG) - со­
здание основного ключа по полю NG; FOREIGN КЕУ (NG)
REFERENCES GRUPPA (NG) - создание внешнего ключа NG с
подключением к основному ключу NG таблицы GRUPPA.
используются инструкции вида

Структура таблиц и связей разработанной РБД представлена на
рис.

14.15.

Связи и таблицы в РБД по возможности сохранены для

осуществления переноса и конвертирования информации из ранее
описанной БД.
Создание хранимых nроцедур. Хранимая процедура в СУБД

InterBase

может применяться как в алгоритме приложения, так и,

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

зультаты клиентскому приложению. Такой подход позволяет также
снизить требования к производительности компьютера пользовате­

ля, работающего с РБД.
Приведем пример хранимой процедуры, осуществляющей уда­

ление ключевых записей из таблицы

Kafedra:

ALTER PROCEDURE КAFEDRA_DEL (DKКAF INTEGER)
AS
declare variabIe dsh_spec iпtеgег;
declare variabIe dпg varchar(6);
declare variabIe dпzk varchar( 1О);
declare variabIe dkprikaz iпtеgег;
declare variabIe dkprep iпtеgег;
BEGIN
for select sh_spec from sресiаlпоst
where kkaf=:dkkaf
iпtо :dsh_spec
do
Ьеgiп

338

....
';:

['рупnа

Кафедра
I\ISЫ:

NAZV КAF
АВиу
ZAVED
иен

SТЕ.Р

UCН-ZVAN

RAВTEL
DOHTEL

г-

~~-~

NAZVAN1E
ОТО

~c

~

эаск овисн

~

ZAМEST

SEKReTAR

Преподаватель
~

t...,~REP
DOtэ_РRБР
FAМIO

5TATU5

UCIi

SТЕР

UСИ-ZVAN

r-

~

.----

Ст~еит
IШ

JWI

-

NOМE.R

STUD

Предмет

--

1\

Изучеиие
Шi

=

STAROSTA

F10

STAR POLN
KURATOR

5TARFAМ

ким

OATAROJ

PREDм

PASPORT
ADRES
GORPRIB

SOКRPUD

VIDZANATIA

LEКCII

CНASI

LAВa

ОТСВЕТ

STIPENDIA

.sн..=
GOD NAВOR

иноsНЕУ

I

.t.A.1ЮRAТОR

~

STUDENTOV
DEVUSHEK

![ЛаборатоРииl
КIIМ.

IШ

JI!'JШJ1
иен

PLAN

ADRPRIa

PRRAB

VID OPLAT

КRRAВ

ОТЕё

BESPLATN

r--

CНAST

МАТ

POLNPLATN

VOEN

CRl\S
ОВ

NКRED

OBRAZ

!ш

5 POL

овса

~~7

Вид nPИ1Саза
КI'!ШI

VIO PRIK

~:::::

lJD

шк

PLATOOK

OS_OТM

ОАТАО

INYAZ
VODIT

SUММA

DOMTEL

OOMTEL

МRAВOТ

Успеваеиостъ

KgRIКJ\2

е:-

ОСН

PLAN
SEмESTR
КРМР

отеНЕТ
ОСЕНКА

POSL БЕЗ
ОТМЕТКА

Vипп
/
Jifil

гхрхив

~

=

PLATDOK

Предnpиятие
KPRP

JiZК

NЛZ.VРRР

SEMESTR

ADRPRP
PROFIL

DOLGN_IPP

TELPRP
RASCHET

DOGOVOR

14.15.

SEМESTR

1--

OOG OBSH
,,-опэ ОВ$Н

PRICHINA

VR_PRAKT

Рис.

~

=

г---. SEМESTR

АКАОЕМ_ОТР

UМQ

Общежитие

ПРИ1Саз

DOLGN

IШ
JiZК

PLAN

эвмЕsта

КURSP

ООО POST
POL-

Оплата

uси

lrn\U

Схема связей таблиц БД "Учебный процесс»

ОАТАО

~

for select ng from gruppa
where gruppa.sh_spec=:dsh_spec
into :dng
do
begin
for select nzk from student
where student.ng=:dng
into :dnzk
do
begin
delete from ipp where ipp.nzk=:dnzk;
delete from uspevaem where uspevaem.nzk=:dnzk;
delete from atestacia where atestacia.nzk=:dnzk;
delete from oplata where oplata.nzk=:dnzk;
delete from obshegit where obshegit.nzk=:dnzk;
for select kprikaz from prikaz
where prikaz.nzk=:dnzk
into :dkprikaz
do delete from vidJ)rikaz where vidJ)rikaz.kprik=:dkprikaz;
delete from prikaz where prikaz.nzk=:dnzk;
end
delete from student where student.ng=:dng;
delete from izuchenie where izuchenie.ng=:dng;
delete from gruppa where gruppa.ng=:dng;
end
delete from specialnost where sh_spec=:dsh_spec;
end
for select kprep from prepod where kkaf=:dkkaf
into :dkprep
do begin
delete from izuchenie where kprep=:dkprep;
delete from uspevaem where kprep=:dkprep;
delete from atestacia where kprep=:dkprep;
end
delete from prepod where kkaf=:dkkaf;
delete from laba where laba.kkaf=:dkkaf;
delete from kafedra where kkaf=:dkkaf;
suspend;

END
340

Данная процедура

KAFEDRA_DEL в качестве параметра полу­
DKKAF, после чего сначала осуществляет уда­

чает номер кафедры

ление записей в подчиненных таблицах и лишь затем ключевой за­

писи В таблице

KAFEDRA.

Многие подчиненные таблицы сами имеют подчиненные табли­
цы. Таким образом, перед удалением данных в них необходимо осу­

ществить удаление данных в подчиненных им таблицах и лишь по­

том

-

в родительских таблицах. Выйти из сложившегося положения

позволяет поддерживаемая в

SQL.

InterBase

вложенность процедур языка

Благодаря этому существует возможность реализовать достаточ­

но сложную процедуру каскадного удаления, содержащую в себе до

16

вложений при размере подобной процедуру не более

48

кбаЙт.

В БД «Учебный процесс» имеется несколько хранимых проце­
дур, которые выполняют следующие работы:

• Gruppa_Del -

каскадное удаление в таблице

Gruppa

и связан­

каскадное удаление в таблице

Kafedra

и связан­

ных с ней таблицах;

• Kafedra_Del ных с ней таблицах;

каскадное удаление в таблице

• Predmet_Del -

Predmet

и свя­

занных с ней таблицах;

каскадное удаление в таблице

• Predpr_Del -

Predpr

и связан­

Prepod

и связан­

ных с ней таблицах.

• Prepod_Del -

каскадное удаление в таблице

ных с ней таблицах;

• Prikaz_Del -

каскадное удаление в таблице

Prikaz

и связанных

с ней таблицах;

• Specialnost_Del -

каскадное удаление в таблице

Specialnost

и

связанных с ней таблицах;

• Student_Del

-каскадное удаление в таблице

Student

и связан­

ных с ней таблицах.

Заполнение (загрузка таблиц данными из существующей БД «Учеб­

ный процесс»), как и в централизованной БД, возможно либо пря­
мо в таблицу, либо в формы. Состав форм описан в интерфейсе
пользователя.

В отличие от централизованной БД в данной БД часть данных
заполняется автоматически через генераторы.

Создание системы ге1lераторов. В явном виде InterBase не под­
держивает полей типа «автонумерация». Вместо этого в InterBase
существует механизм, называемый «генераторами». Генератор

-

некая переменная, значение которой может быть получено и увели­

чено на некоторое значение при помощи встроенной функции

GEN ID.
341

Обычно генераторы используют в триггерах, при этом текст триг­

гера может быть следующим:

САЕАТЕ TRIGGER TI_CLIENTS FOR CLIENTS
ACTIVE BEFORE
INSERT POSITION О

AS
BEGIN IF (new.CLIENT-'О IS NULl) THEN
СLIЕNТJD=GЕNJD«имя генератора>,

1);

END,
где О

-

начальное значение;

шаг приращения в текущем значе­

1-

нии генератора.

Механизм генераторов гарантирует, что даже при конкурентном

(параллельном) вызове функции

GEN_ID

каждому пользователю

будет выдаваться уникальное значение. Последнее значение генера­
тора всегда запоминается в БД, поэтому разработчику не нужно за­

ботиться о восстановлении его максимального значения после под­
соединения к БД. Генераторы являются переменными типа

integer

(Iongint).
Программный комплекс (БД) «Учебный процесс» содержит три
генератора, предназначенных для генерации уникальных кодов:

• Gen_kkaf - кафедр;
• Gen_kpred - предмета;
• Gen_Kprp - предприятия.
Интерфейс пользователя. Речь пойдет об интерфейсе клиента,
поскольку интерфейс сервера обычно очень прост.
Интерфейс РБД должен быть реализован способом, интуитивно
понятным ДЛЯ пользователя-непрофессионала. От пользователя тре­
буются лишь познания в его предметной области.
В качестве средства реализации интерфейса пользователя выб­
ран пакет разработки программного обеспечения
ный на языке высокого уровня

Object Pascal.

Delphi 5,

основан­

Пакет позволяет созда­

вать приложения под графические операционные системы семей­

ства

Windows. Delphi 5 разрабатывался коллективом той же компании
Borland, что и РСУБД InterBase, и потому встроенная ими в Delphi 5
поддержка InterBase является наиболее полной и оптимально функ­
ционирующей.

Для создания программ, осуществляющих взаимодействие пользо­
вателя с РБД, в системе

традиционно используется механизм
(ВОЕ).
В стандартную поставку ВОЕ входит два набора драйверов.

Delphi

Borland Database Engine

342

• Первый набор предназначен для файл-серверных СУБД dBase,
Paradox, FoxPro, Access и данных в текстовом формате. Эти драйве­
ры реально представляют собой весьма сложные программы, вы­
полняющие множество функций СУБД .

• Второй набор ориентирован на клиент-серверные РСУБД
InterBase, 18М DB2, Informix, Oracle, Sybase и Мiсrosоft SQL Server.
Этот набор называется SQL Links. Такие драйверы устроены проще.
Они только передают запросы и команды из BDE в РСУБД и полу­
чают обратно результаты их выполнения. Всю работу по обработке

данных выполняет РСУБД.
Фирмой Мiсrosоft был разработан и стандартный протокол
(Ореп

Database Connectivity Interface,

ODBC

открытый интерфейс взаимо­

действия с БД), напоминающий работу

BDE.

Драйверы

ODBC

вы­

пущены для всех без исключения СУБД, и разработчик может ис­
пользовать в

BDE

как драйверы

SQL Links,

так и драйверы

ODBC.

Разработка интерфейса РБД на любом языке высокого уровня
является сложной и кропотливой задачей, в отличие от реализации

интерфейса в

Access,

где разработчик руководствуется стандартны­

ми шаблонами и методами построения запросов, отчетов и форм.
Интерфейс пользователя БД «Учебный процесс»

насчитывает

свыше сорока форм, из которых порядка двадцати необходимы для
генерации отчетов.

Далее предполагается, что разработчик знаком с работой прило­
жения

Delphi

в рамках автоматизации программирования и потому

процедура создания интерфейса опускается.

При использовании интерфейса возможно обращаться к систе­

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

Общая схема интерфейса пользователя показана на рис.

14.16.

Кратко опишем его элементы Заполнение, Отчеты, Сервис.
Основная экранная форма для элемента ЗаnОЛllение с системой

закладок (кнопок) показана на рис.

14.16.

Как видно, доступ возмо­

жен через систему меню или экранных форм.

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

кнопок, могут быть выполнены также с помощью системы меню.

Порядок заполнения таблиц тот же, что и в централизованной БД.
Рассмотрим одну из экранных форм. При нажатии кнопки Спе­
циальность появляется экранная форма, показанная на рис. 14.17.
Данные могут вводиться пользователем, как в поля ввода, так и

непосредственно в таблицу, расположенную в нижней части фор-

343

..:: '. Дe~aHaT

.'

B~ lE3

~I

i~ец~

.......... Ir;p~;.~
I.1li11il~ ·

~ .-*i
_.~.

IПi>l«-.1 н1cr!ke'frroll 111

•

-,

-

,

K'a~

14.16.

J!
~1
'.-

{ВпМта

."

~{~ ёtiiJ;tY

-~

Рис .

.1Ч~~~н.e!:i

. _ !ita-~

Основная экранная форма элемента Заполнение
QIX

_1~

1 И_нR6"",0!>6~

_

~I M~~lIТ~~ttlopoett4

,_

jи

~A~eнт

....I!Ш\В . В .

M~H. Дрхмв

.-1

I~

П р ед",.".

9 . Теория « методы принятия реше~

9
1

1995
1995 ~

L

~_

I

1995

Проектирое.ниеАСОИУ

9 lUи~еые сет}.. интerраЛЫ10rо ~~ания
------:

9 , Сем~нтические и гилертекстоеые с«стемы
9 rCpeд_CТ8d 06рo6arки илл.остpar. ИНформации
9 Средсте. 06ра6arки Иnl1lOCТpar. ИнформоцИ>1

~~~II.[I:~М~IПi~~·еаll••llllшвЕ€~~111111~·' Комп.юrернЫЙ дизайн изданий
BAI95

-I 8А·О1/95

9 \.Системы06рo6arКиц,,,,,.

1995
1995
BAI95
В.А.·О2195
1995
ТВА.О2/95
i .
1995
ВAl95
IBA02195
1995
ВAI95
ВА02195
. - -'995
:::':::~-- -tвA:02195 __ о - - " 995

ВAl95

t

8A'01~5

Рис.

14.19.

__ .

~ _У_
Н_
ИР_С_ _ _ _ _ - -- - , , - - - --1
9. Т eol"'. и мerao.ы_ П_"'"ИЯ рewе..ю1_
9 Проектироа.""еАСОИУ
9' Uиq>poеые сети ИНТefPdI1bНorо 06сJ1Oj*"",,"ИЯ
9 Се,.",...,ические И гипертекстое",. (;«стемы
9 \Сред;теа 06рa6arки иn~рат. ИНормации

Архив успеваемости студентов

Кнопка Просмотр архива открывает экранную форму изобра­
женную на рис.

14.19,

которая содержит перенесенную ранее в ар­

хив информацию об успеваемости студентов.
Данная информация доступна пользователю только для просмотра. Экранная форма содержит таблицу со следующими полями.

•
•
•
•
•
•
•
•
•

Номер группы.
Номер зачетной книжки.

Учебный план.
Семестр.
Предмет.
Преподаватель.
Отчетность.
Оценка.
Отметка.

Алгоритм nреобразованuя. В его построении участвуют:

•
•
•

хранимые процедуры;

виды серверной части;
формы, связанные с клиентской частью.

Хранимые процедуры позволяют в значительной мере снизить

объемы информации, передаваемые по сети (трафик). К ним в БД
относится

Grup_Sum,

которая осуществляет подсчет числа «плат-

347

ных», «частично платных» и «бесплатных» студентов, обучающихся

в каждой конкретной группе, а также осуществляет подсчет числа
юношей и девушек в группе.

Создание видов

(View)

таблиц служит для повышения быстро­

действия системы запросов. Приведем команды по созданию вида

EKZAMVIEW

из РБД «Учебный процесс»:

j* View: EKZAMVIEW, Owner: SYSDBA * j
CREATE VIEW EKZAMVIEW (NZK, ОТСНЕТ, SEMESTR, SH_SPEC,
POSL_SES, FIO, KURS) AS
SELECT
uspevaem. nzk, otchet, uspevaem. semestr, gruppa.sh_spec,
posl_ses,student.fio,
gruppa.kurs
from uspevaem, gruppa, student
where uspevaem.ng=gruppa.ng and
uspevaem.nzk=student.nzk and semestr 12
group uspevaem.nzk,otchet,uspevaem.semestr,sh_spec,posl_ses,
student.fio,gruppa.kurs Ьу
having оtсhеt='экз';
Как видно из при мера, выборку данных можно осуществлять од­
новременно из неограниченного числа связанных таблиц. Так, дан­

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

semestr, sh_spec, posl_ses, fio, kurs.

nzk, otchet,

Этот вид используется при генера­

ции отчета по успеваемости студентов в текущем семестре. Инфор­
мация, полученная из этого вида, в дальнейшем перерабатывается
интерфейсной частью и используется для генерации отчетов типа:

•
•
•
•

студенты, не сдавшие ,сессию;
студенты, сдавшие сессию на все пятерки;

студенты, сдавшие сессию на пятерки и одну четверку;
студенты, сдавшие сессию на пятерки и две четверки.

В программе имеются следующие виды, которые используются:

•
•
•
•

EkzamView - для генерации отчетов о сдаче студентами сессии;
GruppaView - для ускорения доступа к связанным полям;
StudentView - для ускорения доступа к связанным полям;
ZadolgView - для генерации отчетов о сдаче студентами сессии.

Программа содержит большое количество алгоритмов, необходимых для обработки тех или иных действий пользователя, генера­
ции сложных отчетов, взаимодействия с РБД и переработки инфор­

мации. Многие из этих алгоритмов было практически невозможно

348

реализовать, используя лишь стандартные конструкции

поэтому в них наряду с

Pascal

Object Pascal,

использовался также и язык

SQL.

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

кода, содержащего как

Pascal,

так и

SQL,

при ведем фрагмент про­

цедуры генерирующей «зачетную (экзаменационную) ведомость».

procedure TForm11.Button5Click(Sender: TObject);
var
t1 :string[10];
begin
t1 :=datamodule2.izuchenie.fieldbyname('otchet').asstring;
Загрузка в переменную
лицы

tl

текущего значения колонки

otchet таб­

izuchenie

if t1 ='зач' then form 12.QRLаЬеI1.сарtiоп:='Зачетная

ведомость';

Если tl=зач, то вывести в отчет 'Зачетная ведомость'

if t1 ='аттес' then

fогm12.QRLаЬеI1.сарtiоп:='Аттестационная

ведомость';

if t1 ='экз' then

fогm12.QRLаЬеI1.сарtiоп:='Экзаменационная ве-

домостЬ';

if t1 ='кjпр' then fогm12.QRLаЬеI1.сарtiоп:='КурсовоЙ
if t1 =" then exit;
datamodule2.queryrep 1.sql.clear;

проект';

Сброс текущих SQL-команд, загруженных в запрос Queгyrep 1

datamodule2.queryrep1.sql.add('select * from predmet');
Добавление

SQL команды'sеlесt * [rom predmet'

в запрос Queгyrepl

datamodule2.queryrep1.sql.add('where kpred='+
datamodule2. izuchenie. fieldbyname('kpred') .asstring);
datamodule2.queryrep1.open;
Осуществление запроса

form 12.QRLabeI11.caption:=
datamodule2.q ueryrep 1 .fieldbyname('predm'). value;
349

Выводит в отчет название предмета

datamodule2.queryrep1.close;
Закрытие запроса

queryrep I

datamodule2.queryrep 1.sql.clear;
datamodule2.queryrep1.sql.add('select * from prepod');
datamodule2.queryrep1.sql.add('where kprep='+
datamodule2.izuchenie.fieldbyname('kprep').asstring);
datamodule2.queryrep1.open;
form12.QRLabeI13.caption:=
datamodule2.queryrep1.fieldbyname('fioprep').value;
Выводит в отчет ФИО преподавателя

datamodule2.queryrep1.close;
datamodule2.queryrep1.sql.clear;
datamodule2.queryrep1.sql.add('select ng,sh_spec from gruppa');
datamodule2.queryrep1.sql.add('where ng='+""+
datamodule2. izuchen ie. fieldbyname('ng') .asstring+"");
datamodule2.queryrep1.open;
foгm 12.QRLabeI5.caption:=
datamodule2.queryгep1.fieldbyname('sh_spec').value;
Выводит в отчет шифр специальности.

datamodule2.queryrep1.close;
datamodule2.queryrep1.sql.clear;
datamodule2.queryrep1.sql.add('select * from student');
datamodule2.queryгep 1.sql.add('where student.ng='+""+
datamodule2.izuchenie.fieldbyname('ng').asstring+"");
datamodule2.queryrep1.sql.add('ordeг Ьу nomer_stud');
datamodule2.queryrep1.open;
Выводит в отчет список студентов выбранной группы.
foгm12.QRLabeI7.caption:=

datamodule2.izuchenie.fie/dbyname('semestr').asstring;
Выводит в отчет номер семестра

350

Начало

Вывести в отчет
"Зачетная ведомость"

Вывести в отчет
"Аттестационная
ведомость"

Вывести в отчет
"Экзаменационная
ведомость"
Нет

Вывести в отчет
"Курсовой проект"

Вывести в отчет
данные о студентах

выбранной группы

Конец

Рис.

14.20.

Блок-схема процедуры,

генерирующей «зачетную (экзаменационную) ведомость»

form12.QRLabeI9.caption:=
datamoduJe2. izuсhепiе. fiеJdЬупаmе('пg') .аsstгiпg;
ВЫВОДИТ В отчет номер группы

form12.quickrep1.Preview;
Выводит отчет на предварительный просмотр

datamodule2.queryrep1.close;
епd;
Данную процедуру можно представить в виде блок-схемы, изоб­

раженной на рис.

14.20.

На этом закончим описание распределенной БД «Учебный про­
цесс».

Контрольные вопросы

1.

Какие подходы к проектированию БД вы знаете? В чем их разница? Каковы

последствия различия в подходах?

2.
3.
4.

Какие режимы использования БД вы знаете?
Перечислите и дайте характеристику этапам создания и реализации БД.
В чем отличие многопользовательского режима от однопользовательского при

проектировании БД? При эксплуатации БД?

5. Что такое «приложение»?
6. Перечислите этапы проектирования БД при традиционном подходе.
7. Каковы источники и способы получения данных дЛЯ БД?
8. Почему для примеров выбраны СУБД Acees и IпtегВаsе?
9. Перечислите возможные способы заполнения данных.
10. Назовите составные части БД, постепенно формируемые при ее реализации.
11. Что такое «хранимая процедура», «триггер», «генератор»? Для чего они используются?

1,2. Как создаются таблицы в СУБД InterBase?
13 Как устанавливаются связи в СУБД InterBase?
14. Зачем нужен вид (View)?

Глава

15

Современный подход
к проектированию и реализации

баз данных
Современный подход (рис.

2.6)

рассмотрим на примере

2.2

(см. гл.

2)

процедуры приема на работу. При изложении подхода воспользуемся гра­
дацией гл.

15.

Реализация проводится на СУБД IпtегВаsе в среде

Delphi.

Предполагается, что пользователь знаком с языком программирова­

ния

Object Pascal

(или

Pascal),

имеет некоторые навыки в работе с

Delphi

применительно к автоматизации программирования и знает начала интер­

фейсного и вложенного языков

SQL.

Рассматривается режим работы клиент-сервер с использованием
одноуровневой структуры. Первоначально изучается локальный вариант
(сервер и клиент расположены на одном компьютере) с одним клиентом.

Этот вариант используется чаще всего для отладки удаленного варианта
(сервер и клиент- на разных компьютерах).
Далее рассматривается удаленный вариант и процедура перехода к

нему от локального варианта. Сначала изучается случай с наличием одного
клиента, а затем

-

с несколькими клиентами.

Отдельно рассматривается специфика реализации многоуровневой
структуры режима клиент--.

Описание объекта управления имеет вид

z(t) = z(1 - 1)

+ [t](x[/] - y[tJ).

(15.1 )

Уволенные (описание действия среды) определяются в режиме

диалога в конце каждого цикла

[t].

Описание управляющей части определяется дискретной и не­
прерывной составляющими.

Дискретная составляющая
(табл.

представлена системой

15.1).

Формально система правил:
п'

355

правил

Таблица

15.1

Таблица правил
Номер
IIранила

У1lеllая

Откры-

CTelleHb

тия

(А)

(8)

Средний

Знак

балл

БШIJI

(С)

Знак

Стаж

паж

(D)

Долж>юсть

-

-

-

Отказать

Да

-

-

-

-

Науч_сотр

Да

Нет

>=

3,5

-

-

Инж

4

Да

Нет

<

3,5

>=

2

Инж_экеrur

5

да

Нет

<

3,5

<

2

Отказать

1

Нет

2

Да

3

-

- коне

О, А = нет;
В = нет, С

О, А = да,

iJtJ=

где

< 3,5, D < 2;

(15.2)

1,

А = да,

В = да;

2,
3,

А = да,

В = нет, С ~

А = да,

В = нет, С

3,5;
< 3,5,

О;;::

2,

r Е [1, R], i Е [l,З].
Непрерывная составляющая управляющей части системы состо­

ит из уравнений:

wr;[t] = wг-t.;[/]

+

l(ir[/]), если ir[t]

'* О, wo;[O] =

О;

(15.3)

при решении и:

U.[/]
= w.[t]
I

при

ГI

r= R

(15.4)

и

x[t] =

и[ {],

Е = р

где р

-

u(t)

~

(15.5)

E(t)

- z',

план приема по штатному расписанию,

(15.6)

z'

= Z-

информа­

ция о состоянии объекта управления (количестве работающих).
Объяснения. В процессе работы машины (логического) вывода

на основе правил

(15.2)

компьютер вырабатывает решения-сове­

ты. Если у менеджера возникает сомнение в правильности реше­
ния-совета, он может запросить у компьютера объяснения, кото­
рые выдаются в словесной формулировке использованного прави­
ла (табл.

15.1).
356

Например, претендента Петрова рекомендовано принять науч­

НЫМ СОТРУДНИКОМ на основе правила
ЕСЛИ Ученая степень

-

Да и

2,

которое гласит:

Открытия

-

Да, ТО nРИllять

научным сотрудником.

Процесс работы пользователя показан на рис.

15.2.

На основе анализа алгоритма приложения возможно составить
техническое задание

Техническое задание
Для выполнения проектных работ необходимы специалисты

в

соответствии со штатным расписанием. Если имеются вакантные

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

в помощь руководителю

-

соот­

-

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

-

производственное под­

разделение.

Объем БД не превышает

1 ГбаЙт.

Необходимо использовать широко распространенную СУБД.
Интерфейс БД следует рассчитывать на конечного пользователя (КП)
начального уровня, т. е. от КП не требуется знаний языков про­
граммирования высокого уровня.

БД должна иметь средства восстановления при сбоях и обладать
достаточным быстродействием.

Концептуальная модель. На основе ТЗ можно составить набор
таблиц БД. Таблица «Правила» приведена ранее. В таблицах «Штат­
ное расписание»

(табл.

15.2)

и «Список работающих»

(табл.

15.3)

данные приведены только ДЛЯ первого цикла.

Таблица
Штатное расписание (начальное)
Время

1

1

1

должность

Научный
сотрудник

Инженерконструктор

Инженер по
ЭКСlVlуатации

План

Факт

Вакансии

10

5

5

9

7

2

12

9

3

357

15.2

Рис.

n-

15.2.

Процедура работы с БД:

принимаемыс; В

-

вакансии

Таблица

15.3

Список штатного расписания (начальное)
Врсмя

Фамилия

У'IСIIaЯ

Откры-

Срсдний

стспень

тия

балл

Стаж

Статус

I

ВОДОПЬЯНОВ

Да

Да

4,8

7

Работ.

I

Каримов

Да

Да

3,3

5

Работ .

I

Крамской

Да

Да

4,2

8

Работ.

I

Крикунов

Да

Да

3,5

9

Работ.

I

Трубецков

Да

Да

4,1

15

Работ.

I

Крымов

Да

Нет

4,0

4

Работ.

I

Мамедов

Да

Нет

3,9

6

Работ.

1

Орлов

Да

Нет

3,7

3

Работ.

1

Синцов

Да

Нет

4,5

1

Работ.

1

Петрович

Да

Нет

4,2

7

Работ.

1

Тараканов

Да

Нет

4,1

3

Работ.

1

Травкин

Да

Нет

5,0

9

Работ.

1

Хохлов

Да

Нет

4,0

4

Работ.

1

Черкас

Да

Нет

4,8

2

Работ.

I

Касымов

Да

Нет

3,3

3

Работ.

I

Контуров

Да

Нет

3,0

4

Работ.

359

Долж((ОСТЬ

Науч.
сотр.

Науч.
сотр.

Науч.
сотр.

Науч.
сотр.

Науч.
сотр.

ИНЖ.конс.

ИНЖ.конс.

ИНЖ.конс.

ИНЖ.конс.

ИНЖ.конс.

ИНЖ.конс.

ИНЖ.конс.

ИНЖ.конс.

ИНЖ.конс.

ИНЖ.экс!UI.

ИНЖ.экс!UI.

Продолжение табл.
Врс-

"Я

Фамилия

У'IСllая

Откры-

СРСЛlIИЙ

степеllЬ

ТИ51

бал!!

Стаж

Статус

I

Купцов

Да

Нет

3,3

5

Работ.

I

РеБРОII

Да

Нет

3,4

7

Работ.

I

Ремезов

Да

Нет

3,4

5

Работ.

1

Соколов

Да

Нет

3,3

3

Работ.

1

Тиунов

Да

Нет

3,0

6

Работ.

1

Троекуров

Да

Нет

3,0

4

Работ.

1

lЦавеЛl,

Да

Нет

3,2

9

Работ.

I

Карпов

Да

Да

3,2

1

Прете".

1

Крылов

Да

Да

3,1

2

Претен.

1

СИНLlОВ

Да

Нет

4,5

1

Претен.

1

Симонов

Да

Нет

3,9

2

Претен.

1

Иванов

Да

Нет

3,2

3

Претен.

1

Козлов

Да

Нет

3,4

4

Претен.

1

Петров

Да

Да

4,0

1

Претен.

I

rYPOII

Да

Нет

4,0

3

Претен.

I

Цветков

Да

Нет

3,0

1

Претен.

15.3

ДолжIIOCTb

ИНЖ.ЭКСI1Л.

Инж.экспл.

ИНЖ.ЭКСПJl.

ИНЖ.экспл.

ИНЖ.экспл.

ИНЖ.экспл.

ИНЖ.эксrm.

Фрагментация и локализация. Из технического задания следует,
что необходимо провести горизонтальную фрагментацию таблиц, что

удобнее всего осуществить введением видов. Такой вариант, неза­
висимо от выбранной СУБД, является одновременно одним из спо­

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

360

Выбор СУБД. Остановим выбор, как и ранее, на реляционной
модели данных, как широко применяемой.

Нетрудно видеть, что БД должна быть МIЮГОПОJlьзовательской,
что возможно достичь многопользовательским (файл-серверным)

режимом или режимом клиент-сервер. Предпочтительным, в силу
меньшего трафика, ~lВляется режим клиент-сервер.

В качестве критериев выбора конкретной СУБД в соответствии

с тз могут быть использованы, как в п.

14.4,

механизм блокировки,

особенности хранения данных, производительность, характер ин­

сталляции, обслуживание, конфигурирование и настройка, восста­
новление данных при сбоях, требование к ресурсам (см. табл.

14.1).

Перечисленным критериям в наибольшей степени удовлетворя­

ет СУБД

используемая в среде

InterBase,

Delphi.

Приведем первоначально основные предельные характеристики

InterBase.
Объем БД

до 10000, количество
65 000, длина записи до 64 кбайт, длина поля - до 32 кбайт, вложенность SQL-запроса до 16, размер хранимой процедуры или триггера - до 48 кбаЙт.
InterBase использует следующие типы данных: small (± 32 767, 2
байта); integer (± 2 млрд; 4 байта); Лоа! (± 3,4 Е ± 38; 4 байта);
double precision (± 1,7 Е ± 308; 8 байт); char, varchar (символьный
тип, до 255 символов); date. Вместо типа данных float лучше указы­
вать decimal(a, Ь) или numeric(a, Ь), где а - количество знаков; Ь записей

-

- 10

Гбайт, количество полей

не ограничено, число таблиц

-

-

до

число знаков после запятой.

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

15.2.

РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ

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

первоначально

СУБД

Access.

реализована

и

тестирована

с

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

Интерфейс пользователя БД выполнен с применени­

ем меню (рис.

15.3).

Такой подход позволил не только отработать

основные положения работы пользователя с БД, но и унифициро­
вать алгоритм приложения с помощью системы используемых далее

шаблонов.
Вместе с тем СУБД

Access

сталкивается, как отмечалось ранее, с

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

нейшее изложение касается СУБД

361

InterBase

в среде

Delphi.

Форма "Показать"

Форма "Обработатьn

Штат

Кадры

'p~=a:~

L·~p~1

IРаботающие I

IПретенденты I

D
Количество D

Текущий цикл

Начать

Запуск

циклов

правил

Iколич.

ествеННЬIЙ

результат

l

рринимаемые I
Принятые
Уволенные

I

'~c::e
Принять
всех

п;до~1
Рис.

15.3.

Интерфейс пользователя, реализованный в СУБД

Access

I

I

Delphi

I
Клиент-сервер I

Режим
База

BDE Administratorl IWISQL I ISQL Explorer

данных

Интерфейс
пользователя

Алгоритм
приложений

IIФормы DelPhil
I

I

Меню

Вложенный SQL I

ISQL Manager

I

I I Кнопки I Элементы

I

управленияl

Встроенный SQL
Интерфейсный SQL и

Object Pascal

Рис.

15.4.

Система реализации режима клиент-сервер

Система реализации БД в режиме клиент-сервер показана на
рис.

15.4.

В режиме клиент-сервер выделяются два варианта; локальный
(сервер и клиент расположены на одном компьютере) и удаленный
(сервер и клиент

-

на разных компьютерах).

Рассмотрим последовательно названные варианты, при этом в
локальном варианте процедуру фрагментации опустим.

Локальный вариант режима клиент-сервер

Режим клиент-сервер может быть построен с помощью:

1)
2)

прямых запросов к серверу (через компонент

Query);

запросов через хранимые процедуры, «расположенные»

на

сервере.

Первый способ подробно описан в

[19].

Для него характерна

высокая вычислительная нагрузка клиентов, в силу чего такой спо­

соб удобнее назвать квазирежимом клиент-сервер.
Более грамотным

-

для реализации алгоритма приложения

-

является второй способ с использованием для хранимых процедур

вложенного языка

СУБД

SQL. Рассмотрим его более подробно.
InterBase «работает» с вложенным языком SQL.

время запросы с

мощью интерфейсного

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

В то же

клиентского приложения осуществляются с

по­

SQL через компонент TQuery и языка про­
Object Pascal (возможно через формируемый SQL-

запрос).

363

Нетрудно видеть, что среди типов данных нет счетчика (автоин­

кремент

-

в СУБД

Paradox).

Его заменяет специальная программа,

получившая название генератор. Генератор обычно связывают с
оператором или триггером, реже

Не предусмотрено в

InterBase

-

SQL-

с хранимой процедуроЙ.

и полуавтоматическое задание ус­

ловий на значение, ссылочной целостности, как это имеет место в

СУБД

Paradox.

Условия на значение и ограничения определяются

ограничениями

CONSTRAINTS,

задаваемыми в неявном (без ука­

зания имени) или явном (с указанием имени) видах.

Для реализации остальных процедур используют дополнитель­
ные программы, называемые триггерами. Они «работают» с событи­

ями

Before*

(до),

After*

(после) каких-либо изменений в таблицах.

Генераторы, хранимые процедуры, триггеры пишутся на вложен­
ном языке программирования

SQL.

А. СОБСТВЕННО БД. В построении БД на сервере по-прежне­
му выделяется формирование алиаса и структуры БД, заполнение
таблиц данными.

Алuас. Выберем в качестве имени алиаса

priem_s.

В СУБД

InterBase

все объекты помещаются в один файл. В связи с этим первоначаль­

но следует создать файл БД (с именем

WISQL.

priems)

с помощью утилиты

Ее запуск осуществляется через элемент

Interbase 4.2jWISQL
Windows.
В головном меню WISQL выберем FilejCreate Database и в по­
явившемся окне Create Database установим локальный вариант
InterBase (Local Engine), имя пользователя (путь, например,
D:\student\Chert_cl\priems.gdb) и пароль (по умолчанию - masterkey)
системного администратора для локального сервера InterBase.
Для надежной «руссификации» в окне Database Options следует
указать DEFAULT CHARACTER SET WIN1251.
головного меню

Нажатие кнопки ОК приводит к запоминанию файла БД.

Задание имени БД возможно и программно

-

с помощью

script-

файлов, описанных позднее.
Теперь можно

- для формирования алиаса - обратиться к ути­
BDE Administrator. В ее головном меню через ObjectjNew вы­
берем в окне New Database Alias в качестве имени драйвера INTRBASE
(lNTERBASEl). Заменим его на priem_s. В правом окне в строке
SERVERNAME укажем путь к созданному файлу. В строке
USERNAME зададим имя SYSDBA. Щелкнем правой кнопкой мыши
на имени алиаса в левом окне и выберем элемент меню Apply и
зафиксируем созданный алиас. Нажмем «+» слева от имени алиаса
и в открывшемся окне введем пароль masterkey.
лите

364

Отметим, что имя пользователя и пароль являются средствами

защиты БД и при работе

InterBase

будут часто запрашиваться. На

время отладки БД такой запрос можно заблокировать.

Создание алиаса закончено.

Его можно использовать непосредственно в компоненте

QlIery
Query в

одноименной цепочки доступа к БД. Однако предпочтительнее

для улучшения процесс а управления БД
головной форме

перед объектом

-

Database (обычно один
AliasName установим
качестве свойства DataBaseName - priem_ss. Теперь
компонент QlIery станет priem_ss.
Delphi

вставить компонент

для базы данных). В нем в качестве свойства

priem_s,

а в

алиасом для

Создание структуры таблиц. Структура таблиц создается через
программу, написанную на вложенном языке

SQL.

Ее можно вво­

дить в компьютер двумя способами.

1.

Первоначально написать всю программу (sсгiрt-файл) в лю­

бом из текстовых редакторов. При ее сохранении файлу следует за­
дать расширение

Затем программу можно ввести с помощью

утилиты

оп

sql.
WISQL (Run

ISQL Script).

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

скольку при наличии ощибок в программе первый способ факти­
чески сводится ко второму.

2. Здесь
Exlorer.

может использоваться утилита

WISQL

или утилита

SQL

При вызове

WISQL полезно закрепить «русификацию». Для этого
SessionjAdvanced Setting в окне Character Set Оп надо за­
WIN1251.

В режиме

дать

ДЛЯ создания структуры таблиц и их заполнения используется

язык

SQL.

Установим сетевое соединение БД с

Connect to Database

WISQL

через элемент

Filej

его головного меню. В открывщемся окне зада­

дим путь к БД, имя пользователя и пароль.

В появившейся заставке в верхнем окне

SQL Statement следует
Pravila наберем

набрать SQL-оператор. Так, для создания таблицы

CREATETABLE Pravila(
Nomprav integer Not Null,
FIO varchar( 15) ,
Stepen varchar( 5),
Otkrytie varchar(5),
365

Znak_ball varchar(5),
Sr_ball numeric( 15,2),
Znak_Stag varchar(5),
Stag integer,
Dolgnost varchar( 1О),
Objasnenia varchar( 120)
);
По завершении набора следует нажать кнопку

Набор «переходит» в окно

ISQL Output

Run.

и при отсутствии оши­

бок выполняется. При наличии ошибок выдается сообщение, в ко­
тором указывается строка и знак в наборе, где допущена ошибка.

После ее исправления следует снова нажать кнопку
Описанная процедура утомительна, и потому в
ми

Previous и Next можно

Run.
WISQL

кнопка­

возвратить необходимый оператор из ниж­

него окна в верхнее. После его корректировки он вводится нажати­
ем кнопки

Run.

Подтверждение окончания набора программы осуществляется
выбором в головном меню
ния

File/Commit Work,

а отказ от выполне­

- File/Rollback Work.

После завершения работ с

WISQL отсоединение от БД прово­
File/Disconnect from Database. Выбор кнопки Ехи
означает выход из WISQL.
Следует отметить, что вложенный SQL имеет слабые средства

дится выбором

отладки программ и неудобный интерфейс. Однако высокое быст­

родействие программ при работе в сетевом режиме заставляет ми­
риться с этим недостатком.

Чтобы контролировать работу

WISQL,

возможно использовать

меню.

При нажатии элемента меню
ся заставка

View Information.

View/Metadata Information

выдает­

В ней можно выбрать тип и имя объек­

та, в результате чего в окне JSQL Output будет показана программа
объекта на вложенном языке SQL.
Если имя объекта не задано, выдается список объектов данного
типа.

Выбор элемента меню Extract /SQL Metadata for Table и имени
таблицы приведет к выдаче данных о ней, которые могут быть со­
хранены 8 txt-фаЙле.

Нажатие

Extract /SQL Metadata

[ог

Database

вызовет выдачу ме­

таданных о БД в виде программы на вложенном языке

SQL.

Ееможно

скопировать в буФер и затем сохранить, например, в редакторе
Пример такой SQL-программы приведен в Приложении

366

Word.
3.

Заполнение таблиц. Заполнение можно осуществить в

в

WISQL или

SQL Explorer.
В первом случае производится построчная вставка данных с по­

мощью оператора INSЕRт. Корректировка данных может осуществ­

ляться операторами
зультатов

-

UPDATE

и

DELETE,

контроль полученных ре­

оператором SЕLЕСт. Однако такой способ утомителен.

Более удобно использование утилиты

SQL Explorer,

которая по­

зволяет к тому же создавать структуру таблиц.
После открытия

SQL Explorer на экране

появляется двухоконная

заставка. В левом окне выбирается закладка

Databases

и необходи­

мый алиас. Нажатие «+» слева от него раскрывает перечень типов

объектов БД. Нажатие «+» у выбранного типа объектов раскрывает
перечень имен этого типа объектов. Выбор имени вызывает появле­

- четырех) закладок.
Definition определяет метаданные конкретного объек­
та, закладка Text позволяет получить SQL-оператор создания конк­
ретного объекта. Выбор закладки Data (для таблиц) позволяет про­
ние в правом окне трех (для таблиц

Закладка

вести просмотр, заполнение и корректировку данных в выбранной
таблице.
Для введения новых данных следует нажать «+» в навигаторе и
последовательно вводить записи. При переходе на последующую

запись предыдущая запоминается автоматически. Для запоминания
последней записи необходимо нажать кнопку

Post

или

Refresh

нави­

гатора.

Создание программного кода любого объекта осуществляется при
выборе закладки

Enter SQL.

В верхней части правого окна набира­

ется SQL-оператор и нажимается кнопка с изображением молнии.
Если оператор набран корректно, в нижней части правого окна по­

является результат выполнения оператора (в противном случае вы­
дается сообщение об ошибке). После успешного выполнения опе­

ратора следует обновить в утилите информацию о БД с помощью
элемента меню

View jRefresh.

Контроль за работой БД и сервера в удаленном варианте осуще­

ствляется утилитой

Interbase Server Manager.

Б. ИНТЕРФЕЙС ПОЛЬЗОВАТЕЛЯ. В режиме клиент-сервер
серверная часть интерфейса пользователя развита, как правило, слабо.
В нем выводятся параметры, общие для всех клиентов. Таких пара­

метров обычно немного.
Основной акцент в разработке интерфейса пользователя пере­
носится на интерфейс клиента.

При формировании интерфейса учтем опыт, накопленный при
выполнении работы

[19],

где интерфейс пользователя построен на

367

основе одной формы

Delphi.

В связи с этим усложнился програм­

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

меню к другим элементам меню, постоянного изменения SQL-опе­

ратора в компонентах

Query.

При использовании нескольких форм компоненты

Query

можно

закрепить за конкретными выводимыми на экран вариантами таб­

лиц, переносом SQL-операторов в свойства

SQL

компонент

Query.

При этом потребуется дополнительный программный код для взаи­
модействия форм, но он много проще «устраняемого» программно­
го кода.

В общем случае можно использовать девять форм
клиента и одну

-

Delphi

для

для сервера.

При переходе к хранимым процедурам алгоритм приложения
клиентской части резко упрощается. Для таблиц «Кадры», «Работа­

ющие», «Претенденты», «Принимаемые», «Принятые» SQL-опера­
торы почти совпадают.

В связи с этим лучше использовать четыре формы
клиента и одну

-

Delphi

для

для сервера. Тогда возможно такое «распределе­

ние» таблиц.

Сервер

Form5,

на которой расположены компоненты

Editl

и

Edit2

для

фиксации текущего цикла и общего количества циклов.
Клиент

Forml (основная) - меню и таблица «Штатное расписание».
Form2 - таблица «Кадры» и ее составные части.
Form3 - таблица «Объяснения».
Form4 - таблица «Правила».
Формы Delphi Form2 - Form4 - модальные. При их закрытии
осуществим переключение доступных элементов головного меню.

В головном меню

Form 1 выделим элементы Главная, Показать,

Обработать.

Для элементов головного меню предварительно введем следующее деление.

Главllая

Открыть
Выйти

Ноказать
Штатное расписание

368

Кадры

Претенденты
Работающие

Принимаемые
Принятые

Уволенные
Обработать
Начать
Запуск правил
Количественный результат
Объяснения
Изменение правил
Изменение результата

Принять всех
Продолжить
Замечание. При использовании нескольких форм следует уста­
новить необходимые связи между ними. Для этого н модуле
после заголовка

imp1ementation

unit

пишется строка

uses unit1, ... , uniti, ... unitm;
Без установления связей формы взаимодействов за конкретной

таблицей и вид запроса не меняется в течение всей сессии.

2.

Составление формируемого запроса, размещаемого в програм­

мном коде. Тогда предыдущий при мер получит вид

Query1.Close;
Query1.SQL.Clear;
Query1.SQL.Add('select * from kadry');
Query1.0pen;
Этот способ при меняется при однооконном варианте интерфей­
са или в случае частого изменения вида запроса в объекте

Queryl.

с точки зрения написания SQL-запроса разница невелика, по­
этому дальнейшую процедуру формирования шаблонов иллюстри­

руем с использованием SQL-своЙств.
ВП1.l. Оператор

select используется

в многочисленных вариан­

тах, определяемых следующими основными признаками:

а) использованием параметров (два класса

-

обычный и с пара­

метрами);

б) применением функций агрегирования (обычный, агрегиро­
ванный);

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

RequestLive);

г) использованием одной или нескольких исходных таблиц.

Для проектируемой БЗ представляют интерес следующие варианты.

1.

Простая выборка (будем называть вариант

select1):

select * from kadry

2.

Выборка с параметрами (select2), в которой вьщелим случаи:
с одной таблицей (select21):

•

select dolgnos, count( dolgnos) as fakty from kadry
where (stаtus='работ')
And(vremja between 1 And :vremja)
group Ьу dolgnos
ParamByName('Vremja').Value:=StrTolnt(Edit1.Text);

•

с двумя таблицами

(select22):

select K.vremja, K.Familia,
370

K.Uch_stepen, K.Otkrytie, K.Sr_ball,
K.Stag, K.dolgnos,
P.Objasnenia from kadry К, pravila Р
where vremja=:vremja And
Р .nomprav=K. nomprav
Vremja').Value:=StrTolnt(Edit1.Text)

3.

Выборка с вычислениями и функциями агрегирования

(select3):

select dоlgпоs, соuпt(dоlgпоs) as fakty from kadry
where stаtus='работ'
group Ьу dolgnos

4.

Выборка с параметрами и возможностями изменения вызванных

данных в диалоге:

RequestLive:=True;
select * from kadry
where (stаtus='приним')
апd (vremja=:vremja)
РагаmВуNаmе(Vгеmjа').Vаluе:=StгТоlпt(Еdit1.Техt);
ВОl.2. Оператор

1.

С параметрами

•

update с
updatel,

тремя разновидностями:

включающий два подкласса:

имя изменяемого поля не входит в условия

(update 11):

Update kadry
set поmргаv=:поmргаv,
dоlgпоs=:dоlgпоs

where (uсh_stереп=:uсh_stереп)
Апd (otkrytie=:otkrytie)
Апd (Sr_ball=:Stag)
Апd (stаtus='претен')

Апd

(vremja=:vremja)

РагаmВyNаmе('поmргаv').Vаluе:=Quегу2.RеldВуNamе('поmргаv').Vа'ие;

•

имя изменяемого поля входит в условия

для переменной используется приставка

Update kadry
set status=:status
24'

371

(update12),
old_

при этом

where (status=:old_status)
And (vremja=:vremja)
ParamByName('status') .Value: ='принят';

2. С параметрами,

вычислениями и использованием цикла

(update2):

Update staCrasp
set fakty=:fakty,
vacanc=plany -fakty
where (dolgnos=:dolgnos)
And (vremja=:vremja)
ParamByName('Vremja' ).Value:=StrTolnt(Edit1.Text);

3. С параметрами,
(update3):

циклом и ссылкой

Datasource

на параметры

update stat_rasp
set plany=:plany, fakty=:fakty,
vacanc=:vacanc, prinimaem=:prinimaem,
nedobor=: nedobor
where vremja=:vremja and dolgnos=:dolgnos
Datasource: =DataSource2;
ВП1.3. Оператор

1.

Обычный

insert:
(insertl):

insert into kadry
' )....,
va Iues ( 'П етров,"да,
ВП1.4. Оператор

1.

Обычный

delete:
(deletel):

delete from pravila

2.

С параметрами:

delete from kadry
where vremja=:vremja and dоlgпоs='отказать'
ParamByName('Vremja').Value:=StrTolnt(Edit1.Text);
ВП1.S. Оператор

drop

уничтожения таблицы

drop tabIe pravila
372

(dropl)

ВПl.6. Оператор

create

создания таблицы

(createl),

описанный

ранее.

ВП2. Комплексные составляющие, использующие 1lе ме1lее двух элементарных составляющих.

ВП2.1. Составляющая

insert! (insert\ + se\ectl):

insert into kadry
select * from kadryjsh
ВП2.2. Составляющая

update! (update\ + se\ect3):

update staCrasp
set plany=:plany, fakty=:fakty,
vacanc=:vacanc, prinimaem=:prinimaem,
where (vremja=:vremja) and
dolgnos IN
(select dolgnos, count(dolgnos) as fakty
from kadry
where (stаtus='работ') and
(vremja between 1 and :vremja)
group Ьу dolgnos)
ParamByName('Vremja'). Value: =StrT 01 nt( Edit 1.Т ext);
ВПЗ. На основе этих составляющих формируются шаблоны, по­
казанные в табл.

1.1

и «при вязанные» К действиям пользователя

нажатию элементов меню (см. рис.

-

15.2.).

При построении алгоритма приложения шаблоны связываются
с соответствующими элементами меню и апробируются. Однотип­
ные шаблоны могут просто копироваться.

Отметим одно интересное обстоятельство. Формирование про­
граммных шаблонов (табл.

15.4)

фактически осуществляется во всех

СУБД, но в различных вариантах.
В СУБД

Access

составляющими являются запросы, в которых

хранятся и промежуточные результаты. В СУБД

De\phi)

Paradox (в рамках
Query, которые хра­
InterBase контейнерами для

составляющие связаны с компонентами

нят промежуточные данные. В СУБД

шаблонов служат хранимые процедуры, в которых последовательно

размещаются необходимые составляющие. Промежуточные резуль­
таты хранятся в предложении

INTO

программы хранимой процеду­

ры в виде параметров.

Схема взаимодействия сервера и клиента в части алгоритма при­

ложения показана на рис.15.5.

373

Таблица

Программные шаблоны алгоритма приложения
ШаБЛОII

ДеЙСТIIИЯ ПОЛЬЗОllателя

Начать

А-копирование

Deletel
Insertl
\fJIИ

Б-копирование

Selectl
Update3
\fJIИ

В-копирование

Updatel
\fJIИ

Г-копирование

Огорl

Createl
[nsert[
Штатное расписание

Select3
Update2
Select21

Кадры

Selcct21

Работающие

Select21

Претенденты

Select21

Запуск праВ\fJI

Selectl
Updatell
Updatell

Принимаемые

Select21

Количественный результат

Select3
Update2
Select21

Объяснение

Select22

Принять всех

Delete2
Updatel2

Принятые

Select21

Продолжить

Updatel2
Б-копирование

Selectl
Selectl

374

15.4

Продолже//uе табл.
Действиsr ПОЛЬЗОIJЗтелsr

15.4

ШаБЛОI1

Уволенные

Sclect4
Selectl

Изменение результата

Select4

Изменение правил

Select21
Selcct4
Update12

в рассматриваемой программной реализации генераторы и триг­
геры не используются.

Фрагмент-пример программы алгоритма приложения приведен
в приложении

языке

SQL)

Pascal

с

15

3.

В ней выделена серверная часть (на вложенном

и клиентская часть (интерфейсный язык

SQL

и

Object

формами).

Клиентская часть достаточно проста. Она в значительной мере
представляет собой программу интерфейса пользователя, поскольку
почти все sеlесt-запросы «спрятаны»

в SQL-свойства компонент

Query.
Сервер

иент

3апрс
с
параметрами

«КадрЫ>,

;