close

Вход

Забыли?

вход по аккаунту

?

542.Корелина Т.В.Введение в базы данных

код для вставкиСкачать
Министерство образования и науки РФ
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
“ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ АРХИТЕКТУРНОСТОРОИТЕЛЬНЫЙ УНИВЕРСИТЕТ”
Т. В. Корелина
ВВЕДЕНИЕ В БАЗЫ ДАННЫХ
Учебное пособие
Рекомендовано научно-методическим советом Воронежского
государственного архитектурно-строительного университета в качестве
учебного пособия для студентов специальности 080801 – «Прикладная
информатика (в экономике)» и бакалавров направления 230201 –
«Информационные системы и технологии»
Воронеж 2012
УДК 681.32 (075.8)
ББК 32.81
К663
Рецензенты:
кафедра математических методов исследования операций
Воронежского государственного университета;
А. Н. Зеленина, кан. техн. наук, доцент,
Воронежский институт высоких технологий
К663
Корелина, Т. В. Введение в базы данных: учеб. пособие /
Т.В. Корелина; Воронежский ГАСУ. – Воронеж, 2012– 162 c.
В настоящем учебном пособии рассматриваются теоретические и
практические основы построения баз и банков данных: основные компоненты
банка данных, этапы проектирования баз данных, модели данных, принципы
организации реляционной модели данных и нормализации реляционных
отношений, базисные средства манипулирования реляционными отношениями
(реляционная алгебра и реляционное исчисление), внутренняя организация
СУБД, организация распределенных баз данных и технология клиент/сервер,
основы разработки баз данных с использованием средств СУБД Microsoft
Access.
Пособие предназначено для студентов вузов, в том числе заочного и
дистанционного обучения.
Ил. 47. Табл. 1. Библиогр.: 32 назв.
УДК 681.32 (075.8)
ББК 32.81
ISBN 978-5-89040-376-6
© Корелина Т.В., 2012
© Воронежский ГАСУ, 2012
2
ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ …………………………………………………………….
1. ПОНЯТИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ ……………..
1.1. Процессы в информационной системе ……………………
1.2. Этапы развития информационных систем ………………
1.3. Структура информационной системы
Типы обеспечивающих подсистем …………………….…
1.4. Классификация информационных систем
по признаку структурированности задач …………………
1.4.1. Понятие структурированности задач ………………..
1.4.2. Типы информационных систем, используемые
для решения частично структурированных задач …
1.4.3. Классификация ИС по характеру
использования информации …………………………..
1.4.4. Классификация ИС по сфере применения…………...
1.4.5. Классификация ИС по степени автоматизации…….
Контрольные вопросы……………………………………………
2. ВВЕДЕНИЕ В СУБД ……………………………………………….
2.1. Понятие базы и банка данных ……………………………...
2.2. Средства реализации баз данных …………………………
2.2.1. Программные средства банка данных ………………
2.2.2. Языковые средства …………………………………....
2.2.3. Технические и организационнометодические средства ………………………………………
2.2.4. Требования к банкам данных ………………………
2.3. Функции и требования к СУБД ……………………………
2.4. Классификация банков данных
2.4.1. Классификация баз данных …………………………...
2.4.2. Классификация СУБД ………………………………....
2.4.3. Классификация БнД по экономикоорганизационным признакам ………………………………..
2.5. Концепция централизованного управления данными ……
2.6. Трехуровневая архитектура систем баз данных …………
2.7. Пользователи банков данных ………………………………
2.8. Архитектура «клиент/сервер» ……………………………...
Контрольные вопросы……………………………………………
3. МОДЕЛИ И ТИПЫ ДАННЫХ ……………………………….…..
3.1. Иерархическая модель ……………………………………...
3.2. Сетевая модель ……………………………………………...
3.3. Реляционная модель ………………………………………...
3.4. Постреляционная модель …………………………..………
3.5. Многомерная модель ………………………………………..
3.6. Типы данных ………………………………………………...
3
6
7
8
9
9
12
12
13
14
14
15
16
17
17
19
19
20
21
21
22
23
23
24
24
25
28
32
33
37
38
38
40
42
42
45
48
Контрольные вопросы……………………………………………
4. ПРИМЕНЕНИЕ БАЗ ДАННЫХ В КОРПОРАТИВНЫХ
ИНФОРМАЦИОННЫХ СИСТЕМАХ ……………………………..
4.1. Корпоративная информационная система ………………...
4.2. Контур административного управления …………………..
4.2.1. Наполнение баз данных на примере модуля
«Управление персоналом» ……………………………
4.3. Контур оперативного управления …………………………
4.3.1. Пример организации модуля «Управление
продажами (сбыт)» ……………………………………
4.3.2. Базы данных модуля «Автотранспорт» ……………...
4.4. Контур бухгалтерского учета ……………………………..
Контрольные вопросы……………………………………………
5. СПРАВОЧНО-ПРАВОВЫЕ БАЗЫ ДАННЫХ ………………....
5.1. Общая характеристика справочно-правовых баз …………
5.2. Наиболее популярные юридические базы данных ………
5.2.1. База ЮСИС …………………………………………….
5.2.2. Информационно-поисковая система "Кодекс" ……....
5.2.3. Справочно-правовая система "Гарант" ………………
5.2.4. Справочно-правовая система «Консультант Плюс» ..
5.2.5. Программный комплекс "Эталон" …………………....
Контрольные вопросы……………………………………………………..
6. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ. . . . . . . . . . . . . . . . . . . . . .
6.1. Этапы проектирования баз данных. . . . . . . . . . . . . . . . . . . .
6.2. Инфологическое моделирование . . . . . . . . . . . . . . . . . . . . .
6.2.1. Компоненты инфологической модели. . . . . . . . . . . . . .
6.2.2. Классификация бинарных связей. . . . . . . . . . . . . . . . . .
6.2.3. Моделирование локальных представлений. . . . . . . . . .
6.2.4. Объединение моделей локальных представлений
6.3. Даталогическое проектирование . . . . . . . . . . . . . . . . . . . . . .
6.4. Проектирование реляционных баз данных . . . . . . . . . . . . .
6.5. Нормализация отношений . . . . . . . . . . . . . . . . . . . . . . . . . . .
Контрольные вопросы……………………………………………
7. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ. . . . . . . . . . . . . . . . . . . . .
7.1. Общие понятия. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2. Реляционные объекты данных . . . . . . . . . . . . . . . . . . . . . . .
7.2.1. Основные понятия. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.2. Фундаментальные свойства отношений. . . . . . . . . . . .
7.2.3. Виды отношений. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3. Целостность реляционных данных . . . . . . . . . . . . . . . . . . . .
7.4. Реляционные операторы . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1. Реляционная алгебра……………………………………
7.4.2. Реляционное исчисление……………………………….
Контрольные вопросы……………………………………………
4
49
50
50
51
51
54
54
57
58
59
61
61
63
63
64
65
66
67
67
68
68
70
70
71
72
76
79
81
84
91
93
93
94
94
97
97
98
100
100
108
112
8. ЯЗЫК РЕЛЯЦИОННЫХ БАЗ ДАННЫХ SQL.. . . . . . . . . . . . . .
8.1. Функции и основные возможности . . . . . . . . . . . . . . . . . . .
8.2. Средства определения схемы. . . . . . . . . . . . . . . . . . . . . . . .
8.2.1. Определение таблицы. . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.2. Определение ограничений целостности таблицы. . . . .
8.2.3. Определение представлений. . . . . . . . . . . . . . . . . . . . . .
8.3. Структура запросов. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1. Спецификация курсора. . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.2. Оператор выборки. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.3. Подзапрос. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.4. Табличное выражение. . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4. Агрегатные функции и результаты запросов . . . . . . . . . . .
8.5. Операторы обновления . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Контрольные вопросы……………………………………………
9. ВНУТРЕННЯЯ ОРГАНИЗАЦИЯ РЕЛЯЦИОННЫХ СУБД. .
9.1. Хранение отношений. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2. Индексы . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3. Журнальная информация . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.4. Служебная информация . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Контрольные вопросы……………………………………………
10. НАСТОЛЬНЫЕ СУБД …………………………………………
10.1. Общие сведения о настольных СУБД . . . . . . . . . . . . . . . .
10.2. Наиболее популярные настольные СУБД. . . . . . . . . . . . . .
10.2.1. dBase и Visual dBase . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.2. Paradox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10.2.3. Microsoft FoxPro и Visual FoxPro . . . . . . . . . . . . . . . . .
10.2.4. Microsoft Data Engine . . . . . . . . . . . . . . . . . . . . . . . . . .
Контрольные вопросы……………………………………………
11. СЕРВЕРНЫЕ СУБД……………………………………………….
11.1. Характерные черты современных серверных СУБД . . . .
11.2. Наиболее популярные серверные СУБД . . . . . . . . . . . . . .
11.2.1.Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.2. Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.3.Sybase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.4.Informix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11.2.5. DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Контрольные вопросы …………………………………………
ЗАКЛЮЧЕНИЕ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
БИБЛИОГРАФИЧЕСКИЙ СПИСОК . . . . . . . . . . . . . . . . . . . . . . . .
5
113
113
114
114
115
117
118
119
120
120
120
124
126
127
128
128
132
135
136
137
138
138
139
139
142
143
145
146
147
147
150
150
153
154
155
156
158
159
160
ВВЕДЕНИЕ
Использование баз данных и информационных систем становится
неотъемлемой составляющей деловой деятельности современного человека и
функционирования преуспевающих организаций. В связи с этим большую
актуальность приобретает освоение принципов построения и эффективного
применения соответствующих технологий и программных продуктов – систем
управления базами данных. Цель учебного пособия заключается в
систематическом изложении теоретических основ построения баз данных,
возможностей современных систем управления базами данных, технологии
применения их для разработки и использования информационных систем.
Учебное пособие имеет следующую структуру.
В первой главе дается определение понятия информационная система,
рассмотрены этапы развития информационных систем, их структура и
классификация по признаку структурированности задач.
Во второй главе дано определение банка данных и охарактеризованы
основные его компоненты, приведена классификация банков данных и
сформулированы требования, предъявляемые к ним, представлена концепция
централизованного
управления
данными,
рассмотрены
функции
администратора базы данных и архитектура «клиент/сервер».
В третьей главе дается общая характеристика моделей и типов данных.
Рассматриваются как классические (иерархическая, сетевая, реляционная), так
и постреляционная, многомерная и объектно-ориентированная модели.
В четвертой главе рассматривается
применение баз данных в
корпоративных информационных системах, контур административного
управления, контур оперативного управления, контур бухгалтерского учета.
Подробно рассматриваются способы наполнения баз данных на примере
модуля «Управление персоналом».
Пятая глава посвящена справочно-правовым базам данных. Дается их
общая характеристика и рассматриваются наиболее популярные юридические
базы данных (база ЮСИС, информационно-поисковая система «Кодекс»,
справочно-правовые системы «Гарант», «Консультант Плюс» и программный
комплекс «Эталон»).
Курс «Базы данных» тесно связан с другими дисциплинами, изучающими
основы вычислительной техники, программирование, проектирование
информационных систем. Особо тесная связь наблюдается с дисциплинами
«Вычислительные системы, сети и телекоммуникации», «Информационные
технологии в экономике», «Алгоритмические языки и программирование».
Данное учебное пособие написано в предположении, что студенты
владеют соответствующим понятийным аппаратом. Учебное пособие может
быть использовано для студентов вузов, в том числе заочной и дистанцио нной
форм обучения, а также для обучения работе с базами данных в качестве
конечного пользователя.
6
1. ПОНЯТИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
С самого начала развития вычислительной техники образовались два
основных направления ее использования. Первое направление - применение
вычислительной техники для выполнения численных расчетов, которые
слишком долго или вообще невозможно производить вручную. Становление
этого направления способствовало интенсификации методов численного
решения сложных математических задач, развитию класса языков
программирования, ориентированных на удобную запись численных
алгоритмов, становлению обратной связи с разработчиками новых архитектур
ЭВМ.
Второе направление - использование средств вычислительной техники в
автоматизированных информационных системах. В самом широком смысле
информационная система представляет собой программный комплекс,
функции которого состоят в поддержке надежного хранения информации в
памяти компьютера, выполнении специфических для данного приложения
преобразований информации и/или вычислений, предоставлении пользователям
удобного и легко осваиваемого интерфейса. Обычно объемы информации, с
которыми приходится иметь дело таким системам, достаточно велики, а сама
информация имеет достаточно сложную структуру. Классическими примерами
информационных систем являются банковские системы, системы
резервирования авиационных или железнодорожных билетов, мест в
гостиницах и т.д.
Под информацией понимают любые сведения о каком-либо событии,
сущности, процессе и тому подобном, являющиеся объектом некоторых
операций: восприятия, передачи, преобразования, хранения или использования.
Под системой понимают любой объект, который одновременно
рассматривается и как единое целое, и как объединенная в интересах
достижения поставленных целей совокупность разнородных элементов.
Системы отличаются между собой как по составу, так и по главным целям.
Пример. Приведем несколько систем, состоящих из разных элементов и
направленных на реализацию разных целей.
Система
Фирма
Компьютер
Элементы системы
Главная цель системы
Люди, оборудование,
Производство товаров
материалы, здания и др.
Электронные
и Обработка данных
электромеханические элементы,
линии связи
В информатике понятие «система» имеет множество смысловых
значений. Системой может называться аппаратная часть компьютера. Системой
7
может также считаться множество программ для решения конкретных
прикладных задач.
Добавление к понятию «система» слова «информационная» отражает
цель её создания и функционирования. Информационные системы
обеспечивают сбор, хранение, обработку, поиск, выдачу информации,
необходимой в процессе принятия решений задач.
Информационная система - взаимосвязанная совокупность средств,
методов и персонала, используемых для хранения, обработки и выдачи
информации в интересах достижения поставленной цели.
1.1. Процессы в информационной системе
Процессы, обеспечивающие работу информационной системы любого
назначения, условно можно представить в виде схемы (рис. 1.1), состоящей из
блоков:
• ввод информации из внешних или внутренних источников;
• обработка входной информации и представление её в удобном виде;
• вывод информации для представления потребителям или передачи в
другую систему;
• обратная связь - это информация, переработанная людьми данной
организации для коррекции входной информации.
Аппаратная и программная части
информационной системы
Ввод
информации
Обработка
информации
Вывод
информации
Вывод
информаци
и
Персонал
организации или
другая
информационная
система
Обратная связь
Рис.1.1. Процессы в ИС
Информационная система определяется следующими свойствами:
любая информационная система может быть подвергнута анализу,
построена и управляема на основе общих принципов построения систем:
8
информационная система является динамичной и развивающейся:
при построении информационной системы необходимо использовать
системный подход:
выходной
продукцией информационной системы является
информация, на основе которой принимаются решения;
информационную систему следует воспринимать как человекокомпьютерную систему обработки информации.
1.2.
Этапы развития информационных систем
1. Первые информационные системы появились в 50-х гг. В эти годы они
были предназначены для обработки счетов и расчета зарплаты, а
реализовывались на электромеханических бухгалтерских счетных машинах.
Это приводило к некоторому сокращению затрат и времени на подготовку
бумажных документов.
2. 60-е гг. знаменуются изменением отношения к информационным
системам. Информация, полученная из них, стала применяться для
периодической отчетности по многим параметрам. Для этого организациям
требовалось компьютерное оборудование широкого назначения, способное
обслуживать множество функций, а не только обрабатывать счета и считать
зарплату, как было ранее.
3. В 70-х - начале 80-х гг. информационные системы начинают широко
использоваться
в
качестве
средства
управленческого
контроля,
поддерживающего и ускоряющего процесс принятия решений.
4. К концу 80-х гг. концепция использования информационных систем
вновь изменяется. Они становятся стратегическим источником информации и
используются на всех уровнях организации любого профиля. Информационные
системы этого периода, предоставляя вовремя нужную информацию, помогают
организации достичь успеха в своей деятельности, создавать новые товары и
услуги, находить новые рынки сбыта, обеспечивать себе достойных партнёров,
организовывать выпуск продукции по низкой цене и многое другое.
1.3. Структура информационной системы.
Типы обеспечивающих подсистем
Структуру информационной системы составляет совокупность отдельных
её частей, называемых подсистемами.
Подсистема — это часть системы, выделенная по какому-либо признаку.
Общую структуру информационной системы можно рассматривать как
совокупность подсистем независимо от сферы применения. В этом случае
говорят о структурном признаке классификации, а подсистемы называют
обеспечивающими. Таким образом, структура любой информационной
9
системы может быть представлена совокупностью обеспечивающих подсистем
(рис. 1.2).
Среди обеспечивающих подсистем обычно выделяют информационное,
техническое, математическое, программное, организационное и правовое
обеспечение.
Техническое
обеспечение
Математиче
ское
обеспечение
Информаци
онное
обеспечение
Информаци
онная
система
Организаци
онное
обеспечение
Правовое
обеспечение
Программно
е
обеспечение
Рис.1.2. Структура ИС как совокупность обеспечивающих подсистем
Информационное обеспечение
Назначение подсистемы информационного обеспечения состоит в
своевременном формировании и выдаче достоверной информации для
принятия управленческих решений.
Информационное обеспечение - совокупность единой системы
классификации и кодирования информации, унифицированных систем
документации, схем информационных потоков, циркулирующих в организации,
а также методология построения баз данных.
Для создания информационного обеспечения необходимо:
ясное понимание целей, задач, функций всей системы управления
организацией;
выявление движения информации от момента возникновения и до её
использования на различных уровнях управления, представленной для анализа
в виде схем информационных потоков;
совершенствование системы документооборота;
наличие и использование системы классификации и кодирования;
владение методологией создания концептуальных информационнологических моделей, отражающих взаимосвязь информации. К каждому
исполнителю должна поступать только та информация, которая используется;
создание массивов информации на машинных носителях, что требует
наличия современного технического обеспечения.
10
Техническое обеспечение
Техническое обеспечение — комплекс технических средств,
предназначенных для работы информационной системы, а также
соответствующая документация на эти средства и технологические процессы.
Комплекс технических средств составляют:
компьютеры любых моделей;
устройства сбора, накопления, обработки, передачи и вывода
информации;
устройства передачи данных и линии связи;
оргтехника.
Документацией оформляются предварительный выбор технических
средств, организация их эксплуатации, технологический процесс обработки
данных, технологическое оснащение.
Документацию можно разделить на три группы:
общесистемную (включающую государственные и отраслевые
стандарты по техническому обеспечению);
специализированную (содержащую комплекс методик по всем этапам
разработки технического обеспечения);
нормативно-справочную (используемую при выполнении расчетов по
техническому обеспечению).
Математическое и программное обеспечение
Математическое и программное обеспечение – совокупность
математических методов, моделей, алгоритмов и программ для реализации
целей и задач информационной системы, а также нормального
функционирования комплекса технических средств.
К средствам математического обеспечения относят:
средства моделирования процессов управления;
типовые задачи управления;
методы математического программирования, математической
статистики.
В состав программного обеспечения входят:
1) общесистемные программные продукты;
2) специальные программные продукты;
3) техническая документация.
К общесистемному программному обеспечению относят комплексы
программ, ориентированных на пользователей и предназначенных для решения
типовых задач обработки информации.
Специальное
программное
обеспечение
представляет
собой
совокупность программ, разработанных при создании конкретной
11
информационной системы. В его состав входят пакеты прикладных программ
(ППП).
Техническая документация на разработку программных средств должна
содержать описание задач, задание на алгоритмизацию, экономикоматематическую модель задачи, контрольные примеры.
Организационное обеспечение
Организационное обеспечение — совокупность методов и средств,
регламентирующих взаимодействие работников с техническими средствами и
между собой в процессе разработки и эксплуатации информационной системы.
Организационное обеспечение создаётся по результатам предпроектного
обследования на 1-м этапе.
Правовое обеспечение
Правовое обеспечение — совокупность правовых норм, определяющих
создание, юридический статус и функционирование информационных систем,
регламентирующих порядок получения, преобразования и использования
информации.
Правовое обеспечение этапов функционирования информационной
системы включает:
статус информационной системы;
права, обязанности и ответственность персонала;
правовые положения отдельных видов процесса управления;
порядок создания и использования информации и др.
1.4. Классификация информационных систем по признаку
структурированности задач
1.4.1.
Понятие структурированности задач
При создании или классификации информационных систем возникают
проблемы, связанные с формальным - математическим и алгоритмическим описанием решаемых задач. От степени формализации зависят:
1) эффективность работы всей системы;
2) уровень автоматизации.
Чем точнее математическое описание задачи, тем выше возможности
компьютерной обработки данных и тем меньше степень участия человека в
процессе её решения.
Различают три типа задач, для которых создаются информационные
системы:
1) структурированные (формализуемые);
2) неструктурированные (не формализуемые);
3) частично структурированные.
12
Структурированная (формализуемая) задача — задача, где известны все
её элементы и взаимосвязи между ними.
Неструктурированная (неформализуемая) задача - задача, в которой
невозможно выделить элементы и установить между ними связи.
В структурированной задаче удается выразить её содержание в форме
математической модели, имеющей точный алгоритм решения. Подобные
задачи обычно приходится решать многократно, и они носят рутинный
характер. Целью использования информационной системы для решения
структурированных задач является полная автоматизация их решения, т.е.
сведение роли человека к нулю.
Пример 1. В информационной системе необходимо реализовать задачу
заработной платы. Это структурированная задача, где полностью известен
алгоритм решения. Рутинный характер этой задачи определяется тем, что
расчеты всех начислений и отчислений весьма просты, но объем их очень
велик, так как они должны многократно повторяться ежемесячно для всех
категорий работающих. Решение неструктурированных задач из-за
невозможности создания математического описания и разработки алгоритма
связано с большими трудностями. Решение в таких случаях принимается
человеком из эвристических соображений на основе своего опыта и, возможно,
косвенной информации из разных источников.
Пример 2. Необходимо формализовать взаимоотношения в студенческой
группе. Для данной задачи существен психологический и социальный факторы,
которые очень сложно описать алгоритмически.
В практике работы любой организации существует сравнительно немного
полностью структурированных или совершенно неструктурированных задач. О
большинстве задач можно сказать, что известна лишь часть их элементов и
связей между ними. Такие задачи называются частично структурированными. В
этих условиях можно создать информационную систему. Получаемая в ней
информация анализируется человеком, который будет играть определяющую
роль. Такие информационные системы являются автоматизированными, так как
в их функционировании принимает участие человек.
1.4.2. Типы информационных систем, используемые
для решения частично структурированных задач
Информационные системы, используемые для решения частично
структурированных задач, подразделяются на два вида (рис.1.3):
1) создающие управленческие отчеты и ориентированные главным
образом на обработку данных (поиск, сортировку, агрегирование, фильтрацию).
Используя сведения, содержащиеся в этих отчетах, управляющий принимает
решение;
2) разрабатывающие возможные альтернативы решения. Принятие
решения при этом сводится к выбору одной из предложенных альтернатив.
13
Информационные системы
Для частично структурированных или
неструктурированных задач
Для структурированных задач
(автоматизация решения)
Разрабатывающие альтернативы
решений
Создающие управленческие
отчеты
модельные
экспертные
Рис.1.3. Классификация ИС по признаку структурированности решаемых задач
1.4.3. Классификация ИС по характеру использования информации
Информационно—поисковые
системы
производят
ввод,
систематизацию, хранение, выдачу информации по запросу пользователя без
сложных преобразований данных. Например, информационно-поисковая
система в библиотеке, в железнодорожных и авиа кассах продажи билетов.
Информационно—решающие системы осуществляют все операции
переработки информации по определенному алгоритму. Среди них можно
выделить два класса: управляющие и советующие.
Управляющие ИС вырабатывают информацию, на основании которой
человек принимает решение. Для этих систем характерны тип задач расчетного
характера и обработка больших объемов данных. Примером могут служить
система оперативного планирования выпуска продукции, система
бухгалтерского учета.
Советующие ИС вырабатывают информацию, которая принимается
человеком к сведению.
1.4.4. Классификация ИС по сфере применения
Информационные системы организационного управления предназначены
для автоматизации функций управленческого персонала.
14
Основными функциями являются: оперативный контроль и
регулирование, оперативный учет и анализ, управление сбытом и снабжением.
ИС управления технологическими процессами (ТП) служат для
автоматизации функций производственного персонала. Они широко
используются при организации поточных линий, изготовлении микросхем, на
сборке.
ИС автоматизированного проектирования (САПР) предназначены для
автоматизации функций инженеров-проектировщиков, конструкторов,
архитекторов. Основными функциями являются : инженерные расчеты,
создание графической документации.
Интегрированные
(корпоративные)
ИС
используются
для
автоматизации всех функций фирмы и охватывают весь цикл работ от
проектирования до сбыта продукции.
1.4.5. Классификация ИС по степени автомат изации
В зависимости от степени автоматизации информационных процессов в
системе управления информационные системы определяются как ручные,
автоматические, автоматизированные (рис.1.4).
Информационные системы
По степени автоматизации
Ручные
Автоматические
Автоматизированные
По сфере применения
По характеру информации
Интегрированные
Информационно-поисковые
Организационного
управления
Информационно-решающие
Управление ТП
(тех. процессом)
Управляющие
Советующие
САПР автоматизиров. проектир.
Рис.1.4. Классификация ИС по разным признакам
15
Ручные ИС характеризуются отсутствием современных технических
средств переработки информации и выполнением всех операций человеком.
Например, о деятельности менеджера в фирме, где отсутствуют компьютеры,
можно говорить, что он работает с ручной ИС.
Автоматические ИС выполняют все операции по переработке
информации без участия человека.
Автоматизированные ИС предполагают участие в процессе обработки
информации и человека, и технических средств, причем главная роль
отводится компьютеру.
Перед тем, как определить понятие «данного», представим следующую
абстрактную ситуацию: имеются некоторая система, информация о состоянии
которой представляет интерес, и наблюдатель, способный воспринимать
состояния системы и в определенной форме фиксировать их в своей памяти
(никаких других действий наблюдатель не выполняет). В этом случае говорят,
что в памяти наблюдателя находятся «данные», описывающие состо яние
системы. В качестве такого «наблюдателя» в общем случае и выступают
информационные системы. Таким образом, данные можно определить как
информацию, фиксированную в определенной форме, пригодной для
последующей обработки, хранения и передачи.
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Дайте определение понятий «информационная система», информация
и данные.
2. Какие процессы обеспечивают работу информационной системы?
3. Какими свойствами характеризуется информационная система?
4. Назовите основные этапы развития информационных систем.
5. Структура ИС как совокупность обеспечивающих подсистем.
6. Что представляет собой информационное, техническое и
математическое обеспечения?
7. Что представляет собой программное, организационное и правовое
обеспечения?
8. Какие Вы знаете типы задач, для которых создаются информационные
системы?
9. Как можно классифицировать информационные системы по характеру
использования информации?
10. В чем отличие информационно-поисковых систем от информационнорешающих?
11. Как можно классифицировать информационные системы по степени
автоматизации?
16
2. ВВЕДЕНИЕ В СУБД
2.1. Понятие базы и банка данных
Банк данных (система баз данных – database system) – это система
специальным образом организованных данных (баз данных), программных,
технических,
языковых,
организационно-методических
средств,
предназначенных для обеспечения централизованного накопления и
коллективного многоцелевого использования данных. Соответственно двум
понятиям – «информация» и «данные» – в банках данных различают два
аспекта рассмотрения вопросов: инфологический и даталогический [29].
Инфологический аспект употребляется при рассмотрении вопросо в,
связанных со смысловым содержанием данных независимо от способов их
представления в памяти системы.
На этапе инфологического проектирования информационной системы
должны быть решены вопросы:
1) о каких объектах или явлениях реального мира требуется накапливать
и обрабатывать информацию в системе;
2) какие их основные характеристики и взаимосвязи между собой будут
учитываться;
3) уточнения вводимых в информационную систему понятий об объектах
и явлениях, их характеристиках и взаимосвязях.
Таким образом, на этапе инфологического проектирования выделяется
часть реального мира, определяющая информационные потребности системы,
т.е. ее предметную область.
Даталогический аспект употребляется при рассмотрении вопросов
представления данных в памяти информационной системы. При
даталогическом проектировании системы исходя из возможностей имеющихся
средств восприятия, хранения и обработки информации разрабатываются
соответствующие формы представления информации в системе посредством
данных, а также приводятся модели и методы представления и преобразования
данных, формулируются правила смысловой интерпретации данных.
Основное средство представления семантики данных – естественный
язык. Но можно использовать формализованные языки, которые позволяют
более эффективно организовать обработку данных на вычислительной технике
и представить необходимую семантику данных, удовлетворяющую
практическим потребностям целого ряда прикладных задач. К этому классу
информационных систем относятся и банки данных. Банк данных является
сложной человеко-машинной системой, включающей в свой состав различные
взаимосвязанные и взаимозависимые компоненты (рис 2.1) [12].
Ядром БнД является база данных. База данных – это поименованная
совокупность взаимосвязанных данных, находящихся под управлением СУБД.
В общем случае данные в базе данных являются интегрированными и общими
[9]. Под понятием интегрированные данные подразумевается возможность
17
представить базу данных как объединение нескольких отдельных файлов
данных, полностью или частично не перекрывающихся. Под понятием общие
данные подразумевается возможность использования отдельных областей
данных в базе данных несколькими различными пользователями, т.е. каждый из
этих пользователей может иметь доступ к одной и той же области данных
(причем различные пользователи могут использовать эти данные для разных
целей). Одним из следствий интегрированной базы данных является то, что
любой конкретный пользователь обычно имеет отношение к какой-то
небольшой части всей базы данных, т.е. такая база данных может
восприниматься различными пользователями по-разному.
Банк данных
Информационная
компонента
Языковые
средства
Программные
средства
СУБД
Технические
средства
Организационнометодические
средства
Администратор
БнД
Рис. 2.1. Компоненты банка данных
В традиционной терминологии объекты реального мира, сведения о
которых хранятся в базе данных, называются сущностями (entities), а их
актуальные признаки – свойствами или атрибутами (attributes). Каждый
признак конкретного объекта есть значение атрибута. В базе данных могут
отражаться не только физические объекты. Она способна вобрать в себя
сведения об абстракциях, процессах, явлениях – то есть обо всем, с чем
сталкивается человек в своей деятельности. Помимо объектов существуют также
отношения, которые связывают их вместе. Отношения также являются частью
данных.
В состав базы данных входит также метаинформация (т.е. информация
об информации), включающая описание базы данных (схема БД), информацию
о предметной области, необходимую для проектирования системы, о
18
пользователях БнД, о проектных решениях и др. Централизованное хранилище
метаинформации называется словарем данных (словарь-справочник,
энциклопедия, репозиторий).
2.2. Средства реализации баз данных
2.2.1. Программные средства банка данных
Программные средства БнД представляют собой сложный комплекс,
обеспечивающий взаимодействие всех частей информационной системы при ее
функционировании (рис. 2.2) [12].
Программные средства БнД
Программная
компонента
Ядро СУБД
Прикладные программы
обслуживания БнД
ОС
Трансляторы
Утилиты
Рис. 2.2. Программные средства БнД
Основу программных средств БнД представляет СУБД. Система
управления базой данных (СУБД, database mamagement system (DBMS)) или
диспетчер базы данных (database manager) – совокупность языковых и
программных средств, облегчающих выполнение всех операций, связанных с
организацией хранения данных, их корректировки и доступа к ним. Основная
функция, выполняемая СУБД, – предоставление пользователю базы данных
возможности работать с ней, не вникая в детали на уровне аппаратного
обеспечения.
В СУБД можно выделить ядро СУБД (Data Base Engine),
обеспечивающее организацию ввода, обработки и хранения данных, а также
средства
тестирования
и
утилиты,
обеспечивающие
выполнение
вспомогательных функций. Важной компонентой СУБД являются
трансляторы или компиляторы для используемых ею языковых средств.
Подавляющее большинство СУБД работает в среде универсальных
операционных систем и взаимодействует с ОС при обработке обращений к
БнД. Поэтому можно считать, что ОС также входит в состав БнД. Для
обработки запросов к БД пишутся соответствующие программы, которые
представляют прикладное программное обеспечение БнД.
19
2.2.2. Языковые средства
Языковые средства обеспечивают интерфейс пользователей разных
категорий с банком данных. Языковые средства большинства СУБД относятся
к языкам четвертого поколения.
При проектировании языков четвертого поколения используются
следующие принципы [12]:
принцип минимума работы (язык должен обеспечить минимум
усилий, чтобы «заставить» машину работать);
принцип минимума мастерства (работа должна быть так проста, как
только это возможно; она не должна быть уделом избранных и быть понятной
лишь посвященным);
принцип естественности языка, упразднения «инородного»
синтаксиса и мнемоники;
принцип минимума времени (язык должен позволять без
существенной задержки реализовывать возникающие потребности в доступе к
информации и ее обработке);
принцип минимума ошибок;
принцип минимума поддержки (возможность внесения изменений в
имеющиеся приложения);
принцип максимума результата (пользователю предоставляется
мощный инструмент для решения разнообразных задач).
Выделяют две концепции развития языковых средств: концепцию
разделения и концепцию интеграции. При использовании концепции
разделения различают языки описания данных (ЯОД), языки манипулирования
данными (ЯМД), языки запросов и другие языковые средства.
В составе языков описания данных в зависимости от особенностей СУБД
поддерживаются все или некоторые из следующих языков: язык описания схем,
язык описания подсхем, язык описания хранимых данных, язык описания
внешних данных (входных, выходных).
ЯМД разделяются на две большие группы: процедурные и непроцедурные.
При использовании процедурным языкам надо указать, какие действия и над
каким объектом необходимо выполнить, чтобы получить результат. В
непроцедурных языках указывается, что надо получить в ответе, а не как это
сделать. Примерами непроцедурных языков являются языки, основанные на
реляционном исчислении, представителем которых является язык запросов SQL.
По функциональным возможностям выделяют следующие категории
языков [12]:
1. Языки, обеспечивающие только возможности запросов (обеспечивают
вывод требуемых данных на экран или печать в нужном формате).
2. Комплексные языки запросов-обновлений (позволяют формулировать
сложные запросы, относящиеся к нескольким взаимосвязанным записям,
обновлять данные так же легко, как и формулировать запросы; благодаря их
использованию, пользователи могут создавать собственные файлы).
20
3. Генераторы отчетов позволяют выбирать нужные данные из файлов
или баз данных и форматировать их в виде требуемых форм документов).
4. Графические языки (позволяют выводить данные в виде различных
графиков и диаграмм, а также использовать другие изобразительные
возможности).
5. Инструментальные средства поддержки решений (предназначены для
систем принятия решений).
6. Генераторы приложений (предназначены для генерации приложений,
обеспечивают возможность описания непроцедурным путем требуемой
обработки информации и дальнейшей автоматической генерации программ).
7.
Машиноориентированные
языки
спецификаций
(являются
генераторами приложений, но более универсальны и позволяют
специфицировать приложения разных типов).
8. Параметризированные пакеты прикладных программ (допускают
легкую модификацию самого пакета, позволяют пользователям генерировать
собственные отчеты, запросы к БД и т.д.).
9. Языки приложений (спроектированы для специфических приложений:
управление финансами, управление работой станков с программным
управлением).
По форме представления различают аналитические, табличные и
графические языковые средства. Большинство современных СУБД включает в
свой состав несколько языковых средств разного уровня.
2.2.3. Технические и организационно-методические средства
Чаще всего используются универсальные ЭВМ, периферийные
устройства для вывода информации в базу данных и отображения выводимой
информации. Последнее время наметился переход от больших ЭВМ к
открытым распределенным системам на компьютерах RISC-архитектуры.
Представляют собой различные инструкции, методические и
регламентирующие материалы, предназначенные для пользователей разных
категорий, взаимодействующих с банком данных.
2.2.4. Требования к банкам данных
Особенности
«банковской»
организации
данных
позволяют
сформулировать основные требования, предъявляемые к БнД [9]:
1) адекватность отображения предметной области (полнота, целос тность
и непротиворечивость данных, актуальность информации, т.е. ее соответствие
состоянию объекта на данный момент);
2) возможность взаимодействия пользователей разных категорий и в
разных режимах, обеспечение высокой эффективности доступа для разных
приложений;
3) дружелюбность интерфейсов и малое время на освоение системы,
особенно для конечных пользователей;
21
4) обеспечение секретности и конфиденциальности для некоторой части
данных; определение групп пользователей и их полномочий;
5) обеспечение взаимной независимости программ и данных;
6) обеспечение надежности функционирования БнД; защита данных от
случайного и преднамеренного разрушения; возможность быстрого и полного
восстановления данных в случае их разрушения; технологичность обработки
данных, приемлемые характеристики функционирования БнД (стоимость
обработки, время реакции системы на запросы, требуемые машинные ресурсы
и др.).
Преимущества банка данных по сравнению с традиционным бумажным
методом содержания записей:
1. компактность,
2. скорость работы,
3. низкие трудозатраты при работе,
4. применимость (нужная информация доступна в любой момент времени),
5. в многопользовательской среде – централизованное управление
данными.
2.3. Функции СУБД
1. Определения данных. СУБД должна допускать определения данных
(внешние схемы, концептуальную схему, внутреннюю схему, а также все
связанные отображения) в исходной форме и преобразовывать эти определения
в форму соответствующих объектов, т.е. СУБД должна включать в себя
компонент языкового процессора для различных языков определения данных.
2. Обработка данных. СУБД должна уметь обрабатывать запросы
пользователя на выборку, изменение или удаление соответствующих данных в
базе данных или на добавление новых данных в базу данных, т.е. СУБД должна
включать в себя компонент процессора языка обработки данных.
Запросы ЯОД бывают «планируемые» и «непланируемые».
Планируемый запрос – это запрос, необходимость которого
предусмотрена заранее. АД должен настроить физический проект БД таким
образом, чтобы гарантировать достаточное быстродействие для таких запросов.
Непланируемый запрос – специальный запрос, необходимость которого
не была предусмотрена заранее.
Планируемые запросы характерны для «операционных» приложений, а
непланируемые – для приложений «поддержки решений».
3. Безопасность и целостность данных. СУБД должна контролировать
пользовательские запросы и пресекать попытки нарушения правил
безопасности и целостности, определенные АБД.
4. Восстановление данных и дублирование. Осуществляется СУБД или
администратором транзакций.
5. Ведение словаря данных.
22
6. Производительность. СУБД должна выполнять все указанные
функции с максимально возможной эффективностью.
В целом назначением СУБД является предоставление пользовательского
интерфейса с базой данных.
2.4. Классификация банков данных
Банки данных являются сложными системами, и их классификация может
быть произведена по разным признакам.
2.4.1. Классификация баз данных
Центральной компонентой банка данных является база данных, и
большинство классификационных признаков относится именно к ней.
По форме представления информации различают видео- и
аудиосистемы, а также системы мультимедиа. Эта классификация в
основном показывает, в каком виде информация из баз данных выдается
пользователям: в виде изображения (символьный текст, рисунки, чертежи,
фотографии и т.д.), звука или дается возможность использования разных
форм отображения информации.
Пока наибольшее практическое использование находят базы данных,
содержащие обычные символьные данные. Эти базы данных, в свою очередь,
могут быть разделены на неструктурированные, частично структурированные
и структурированные. К неструктурированным БД могут быть отнесены базы,
организованные в виде семантических сетей. Частично структурированными
можно считать базы данных в виде обычного текста или гипертекстовой
системы.
Структурированные БД, в свою очередь, по типу используемой модели
делятся на иерархические, сетевые, реляционные, смешанные и
мультимодельные. Наибольшее коммерческое использование в настоящее
время имеют реляционные системы. Классификация по типу модели
распространяется не только на базы данных, но и на СУБД и даже на банк
данных в целом.
По типу хранимой информации БД делятся на документальные,
фактографические и лексикографические. Среди документальных баз
различают библиографические, реферативные и полнотекстовые. К
лексикографическим базам данных относятся различные словари.
По характеру организации хранения данных и обращения к ним
различают локальные (персональные), общие (интегрированные) и
распределенные базы данных. Базы данных могут классифицироваться по
охвату предметной области. Причем эта классификация, в свою очередь, может
производиться по разным признакам: по территориальному (всемирный,
страна, город или какой-либо иной регион), временному (год, месяц, с начала
века и т.п.), ведомственному, проблемному.
23
2.4.2. Классификация СУБД
По языкам общения СУБД делятся на открытые (используются
универсальные языки программирования), замкнутые (собственные языки
общения с пользователями) и смешанные.
По числу уровней в архитектуре различают одноуровневые,
двухуровневые, трехуровневые системы. Под архитектурным уровнем СУБД
понимают функциональный компонент, механизмы которого служат для
поддержки некоторого уровня абстракции данных.
По выполняемым функциям СУБД делятся на информационные и
операционные. Информационные СУБД позволяют организовать хранение
информации и доступ к ней. Для выполнения более сложной обработки
необходимо писать специальные программы. Операционные СУБД выполняют
достаточно сложную обработку, например, автоматически позволяют получать
агрегированные показатели, не хранящиеся непосредственно в базе данных,
могут изменять алгоритм обработки и т.д.
По сфере возможного применения различают универсальные и
специализированные, обычно проблемно-ориентированные СУБД.
Системы управления базами данных поддерживают разные типы данных.
Набор типов данных, допустимых в разных СУБД, различен. В настоящее
время наблюдается тенденция к расширению числа используемых типов
данных. Кроме того, ряд СУБД позволяет разработчику (прикладному
программисту или администратору БД) добавлять новые типы данных и новые
операции над этими данными. Такие системы называются расширяемыми
системами баз данных (РСБД).
Дальнейшим развитием концепции РСБД являются объектноориентированные системы баз данных, обладающие достаточно мощными
выразительными возможностями, чтобы непосредственно моделировать
сложные объекты. Новым направлением в развитии программного обеспечения
банков данных являются генераторы системы базы данных. Они позволяют
разработчику строить собственную СУБД нового типа без полного
переписывания программного кода из заготовок.
2.4.3. Классификация БнД по экономико-организационным признакам
Следующая группа признаков классификации связана с банком данных в
целом. По условиям предоставления услуг различают бесплатные и платные
банки данных. Платные БД, в свою очередь, делятся на бесприбыльные и
коммерческие. Бесприбыльные банки данных функционируют на принципе
самоокупаемости и не ставят своей целью получение прибыли. Это обычно БнД
социально значимой информации, имеющей широкий круг пользователей, или
научной, библиотечной информации. Основной целью создания коммерческих
банков данных является получение прибыли от информационной деятельности.
По форме собственности банки данных делятся на государственные и
негосударственные.
24
По степени доступности различают общедоступные и с ограниченным
кругом пользователей.
В литературе встречаются и другие аспекты классификации банков
данных, но названные являются наиболее значимыми.
2.5. Концепция централизованного управления
При централизованном управлении должен быть человек –
администратор данных (АД), несущий ответственность за данные,
безопасность данных и разбирающийся в них на уровне управления высшего
руководства предприятия [9]. За техническую реализацию решений АД
отвечает администратор базы данных (АБД) – профессиональный специалист
в области информационных технологий. У АБД должен быть штат из
системных программистов и технических ассистентов.
Преимущества централизованного управления данными
1. Возможность сокращения избыточности (дублирования информации).
2. Возможность устранения (до некоторой степени) противоречивости за
счет множественного обновления данных.
3. Возможность общего доступа к данным.
4. Возможность соблюдения стандартов.
5. Возможность введения ограничений для обеспечения безопасности.
6. Возможность обеспечения целостности (правильности и точности)
данных.
7. Возможность сбалансировать противоречивые требования.
8. Обеспечение независимости данных.
 Независимость данных
В системах, зависимых от данных, сведения об организации данных и
способе доступа встроены в логику и код приложения. В них невозможно
изменить структуру хранения (т.е. способ физического хранения данных) или
метод доступа (т.е. способ осуществления доступа к данным), не изменив
самого приложения (возможно, радикально).
Это является серьезным ограничением, так как:
1) для разных приложений требуются разные представления одних и тех
же данных;
2) администратор базы данных должен иметь возможность при
изменившихся требованиях изменять структуру хранения или метод доступа к
данным без изменения существующих приложений.
Таким образом, обеспечение независимости данных – основная цель
систем баз данных. Независимость данных можно определить как иммунитет
приложений к изменениям в структуре хранения данных и в методах доступа к
данным. Далее будет рассмотрена архитектура систем баз данных,
25
обеспечивающая основу для достижения этой цели. Предварительно
необходимо рассмотреть три новых термина: хранимое поле, хранимая запись,
хранимый файл (рис. 2.3) [9].
Хранимая база данных
Другие хранимые файлы
Хранимый файл PFILE с деталями
Номер Название
детали детали
P1
Два экземпляра
хранимого типа
Nut
Цвет
Вес
детали детали
Red
12
Хранимые экземпляры полей
записи деталь
P2
Bolt
Номер Название
детали детали
Green
17
Цвет
Вес
детали детали
Рис. 2.3. Хранимые поля, записи и файлы
Хранимое поле – наименьшая единица хранимых данных. База данных
содержит много экземпляров каждого из нескольких типов хранимых полей.
Хранимая запись – это набор связанных хранимых полей. Экземпляр
хранимой записи состоит из группы связанных экземпляров хранимых полей.
Хранимый файл – набор всех экземпляров хранимых записей одного типа.
В системах, отличных от баз данных, обычно логическая запись совпадает
с соответствующей хранимой записью. В базах данных это вовсе не
26
обязательно, так как АБД может понадобиться внести изменения в структуру
хранения данных, в то время как логическая структура останется неизменной.
Перечислим аспекты структуры хранения баз данных, которые могут
подвергнуться изменениям [9].
 Представление числовых данных
Числовое поле может храниться во внутренней арифметической форме
(например, в упакованном десятичном формате) или в виде символьной строки.
В каждом случае АБД должен определить подходящее основание системы
счисления (например, он может выбрать двоичную или десятичную систему
счисления), масштаб (число с фиксированной или плавающей запятой), тип
(действительное число или комплексное) и точность (количество цифр).
Каждый из этих параметров может быть изменен для повышения
производительности, при введении нового стандарта или по другим прич инам.
 Представление символьных данных
Поле в форме символьной строки может сохраняться с помощью
нескольких разных наборов кодирования символов.
 Единицы для числовых данных
Единицы числовых полей могут быть изменены, например, с дюймов на
сантиметры, если приложение связано с процессами измерения.
 Кодирование данных
В некоторых ситуациях может понадобиться представлять данные
кодированными значениями. Например, поле "цвет детали", которое
представлено в приложении как символьная строка ("Красный", "Голубой",
"Зеленый"), может храниться в виде десятичной цифры в соответствии с
таблицей перекодировки: 1 = "Красный", 2 = "Голубой" и т.д.
 Материализация данных
Обычно логическое поле, используемое приложением, соответствует
некоторому определенному хранимому полю. В этом случае процесс
материализации, т.е. построение экземпляра логического поля из
соответствующего экземпляра хранимого поля и передача его приложению,
можно назвать прямым. Однако иногда логическое поле может не иметь
соответствующего эквивалентного хранимого поля, а его значение
"материализуется" с помощью некоторых вычислений, выполняемых над
набором из нескольких экземпляров хранимых полей. Например, значения
логического поля "общее количество" можно определить путем суммирования
нескольких хранимых значений поля "количество". "Общее количество" – это
пример виртуального поля, процесс определения его значения называют
непрямым.
27
 Структура хранимых записей
Два существующих типа хранимых записей можно объединить в один.
Такие изменения могут выполняться, когда в систему баз данных вводятся
ранее существующие приложения. При этом предполагается, что логическая
запись приложения может состоять из подмножества соответствующей
хранимой записи, т.е. некоторые поля хранимой записи будут "невидимы" для
рассматриваемого приложения. И наоборот, один тип хранимых записей можно
разделить на два. Такое разделение позволяет редко используемые части
исходной записи поместить, например, на более медленное устройство. При
этом неявно предполагается, что логическая запись приложения может
содержать поля из нескольких отдельных хранимых записей, т.е. логическая
запись является расширением любой из этих хранимых записей.
 Структура хранимых файлов
Хранимый файл может физически храниться в памяти разными
способами. Например, его можно разместить на одном томе памяти (например,
на одном диске) или распределить на нескольких томах разных типов
устройств; он может быть физически упорядочен в соответствии со значениями
некоторого хранимого поля; он может быть упорядочен какими-либо другими
способами, например с помощью одного или нескольких индексов или
встроенных цепочек указателей; к нему может быть обеспечен доступ методом
хеш-адресации; хранимые записи могут быть физически объединены в блоки
(несколько в одной физической записи). Но ни один из этих факторов не
должен влиять каким-либо образом на приложение.
Этим ограничиваются аспекты структуры хранения, которые можно
подвергнуть изменениям. Здесь среди прочего предполагается, что база данных
может развиваться, не оказывая влияния на приложения. В действительности
возможность развития базы данных без логического ущерба для существующих
приложений является единственным наиболее важным мотивом обеспечения
независимости данных.
2.6. Трехуровневая архитектура системы баз данных
Архитектура ANSU/SPARC (Study Group on Data Management System)
включает три уровня: внутренний, концептуальный и внешний (рис. 2.4) [9].
Внешний уровень связан со способами представления данных для
отдельных пользователей.
Концептуальный уровень является «промежуточным» между внутренним
и внешним уровнями.
Внутренний уровень – это уровень, наиболее близкий к физическому
хранению, т.е. связанный со способами сохранения информации на физических
устройствах хранения.
Внешний уровень – это индивидуальный уровень пользователя. У каждого
пользователя есть свой язык общения: для прикладного программиста – один из
28
распространенных языков программирования или специальный язык
рассматриваемой системы, для конечного пользователя – специальный язык
запросов или язык специального назначения, возможно, основанный на фо рмах
и меню, созданный специально с учетом требований пользователя и
поддерживаемый некоторым оперативным приложением. Все эти языки
включают подъязык данных – подмножество операторов всего языка (базового
языка), связанное только с объектами и операциями баз данных. Любой
подъязык данных является комбинацией, по крайней мере, двух подчиненных
языков – языка определения данных (data definition language – DLL), который
поддерживает определения или объявления объектов базы данных, и языка
обработки данных (data manipulation language – DML), который поддерживает
операции с такими объектами или их обработку.
Внешний уровень
(индивидуальные представления
пользователей)
Концептуальный уровень
(обобщенное представление
пользователей)
Внутренний уровень
(представление в памяти)
Рис. 2.4. Три уровня архитектуры
Внешнее представление – это содержимое базы данных, каким видит его
определенный пользователь. Внешнее представление состоит из множества
экземпляров каждого типа внешней записи, которые не обязательно должны
совпадать с хранимыми записями. Находящийся в распоряжении пользователя
подъязык данных определен в терминах внешних записей.
Каждое внешнее представление определяется средствами внешней схемы,
которая в основном состоит из определений каждого типа записей во внешнем
представлении. Внешняя схема написана с помощью языка определения
данных из пользовательского подъязыка данных.
Концептуальное представление – это представление всего содержимого
базы данных в несколько более абстрактной форме по сравнению с физическим
способом хранения данных, т.е. представление данных такими, какие «они есть
на самом деле», а не такими, какими вынужден их видеть пользователь в
рамках, например, определенного языка или используемого аппаратного
обеспечения. Концептуальное представление состоит из множества
29
экземпляров каждого типа концептуальной записи. Концептуальная запись не
обязательно должна совпадать с внешней и хранимой записью. Концептуальное
представление определяется с помощью концептуальной схемы, которая
включает определения каждого типа концептуальных записей. Для обеспечения
независимости данных нельзя включать в определения концептуального языка
любое рассмотрение структуры хранения или метода доступа.
Определения в концептуальной схеме могут включать определения
многих дополнительных средств, таких как средства безопасности или правила
для обеспечения целостности.
Отображение концептуальный – внутренний определяет как
концептуальные записи и поля представлены на внутреннем уровне. При
изменении структуры хранимой записи изменяется и отображение таким
образом, чтобы концептуальная схема осталась неизменной.
Отображение внешний – концептуальный определяет соответствие
между некоторыми внешними представлениями и концептуальным
представлением.
Внутреннее представление (хранимая база данных) – это представление
нижнего уровня всей базы данных; оно состоит из множества экземпляров
каждого типа внутренней записи (хранимая запись).
Внутреннее представление не связано с физическим уровнем, так как в
нем не рассматриваются физические записи (блоки и страницы) и физич еские
области хранения, такие как цилиндры и дорожки. Внутреннее представление
предполагает бесконечное линейное адресное пространство; подробности того,
как адресное пространство отображено на физическое устройство, зависят от
системы и не включены в общую архитектуру.
Внутреннее представление описывается с помощью внутренней схемы
(определения структуры хранения), которая определяет различные типы
хранимых записей, существующие индексы, способы представления хранимых
полей, физическую последовательность хранимых записей и т.д. Внутренняя
схема пишется с использованием внутреннего языка определения данных.
Если внешний уровень связан с индивидуальным представлением
пользователей, то концептуальный уровень связан с обобщенным
представлением пользователей. Иначе говоря, может быть несколько внешних
представлений, каждое из которых состоит из более или менее абстрактного
представления определенной части базы данных, и может быть только одно
концептуальное представление, состоящее из абстрактного представления базы
данных в целом.
Также есть единственное внутреннее представление, отражающее всю
базу данных как физически хранимую. Основные компоненты архитектуры и их
взаимосвязь показаны на рис. 2.5. Многие системы позволяют выражать
определение одного внешнего представления через другое (с помощью
отображения внешний-внешний), не требуя обязательно явно определять
отображение на концептуальный уровень.
30
31
2.7. Пользователи банков данных
Пользователей можно разделить на три большие группы [12].
Прикладные программисты отвечают за написание прикладных
программ, использующих базу данных. Эти программы могут быть простыми
программами пакетной обработки или оперативными приложениями, функция
которых – поддержка работы конечного пользователя.
Конечные пользователи работают с системами баз данных
непосредственно через рабочую станцию или терминал. Конечный
пользователь может получить доступ к базе данных, используя одно из
оперативных приложений, или воспользоваться интегрированным интерфейсом
программного интерфейса самой системы баз данных. Такой интерфейс
поддерживается
встроенным в систему баз данных оперативным приложением – процессором
языка запросов.
Администраторы базы данных – группа специалистов, обеспечивающих
создание, функционирование и развитие БнД. В составе админис трации БнД
должны быть системные аналитики, проектировщики структур данных и
внешнего по отношению к банку данных информационного обеспечения,
проектировщики технологических процессов обработки данных, системные и
прикладные программисты, операторы, специалисты по техническому
обслуживанию.
К функциям администратора банка данных можно отнести следующие:
1. Анализ предметной области: описание предметной области, выявление
ограничений целостности, определение статуса информации, определение
потребностей пользователей, определение статуса пользователей, опр еделение
соответствия «данные – пользователь», определение объемно-временных
характеристик обработки данных.
2. Проектирование структуры базы данных: определение состава и
структуры файлов базы данных, связей между ними, выбор методов
упорядочения данных и методов доступа к информации, описание структуры
БД на языке описания данных (ЯОД).
3. Задание ограничений целостности при описании структуры базы
данных и процедур обработки БД: задание ограничений целостности, прис ущих
предметной области, определение ограничений целостности, вызванных
структурой базы данных, разработка процедур обеспечения целостности БД
при вводе и корректировке данных, обеспечение ограничений целостности при
параллельной работе пользователей в многопользовательском режиме.
4. Первоначальная загрузка и ведение базы данных: разработка
технологии первоначальной загрузки и ведения (изменения, добавления,
удаления записей) БД, проектирование форм ввода, создание программных
модулей, подготовка исходных данных, ввод и контроль ввода.
5. Защита данных.
32
5.1. Обеспечение парольного входа в систему: регистрация
пользователей, назначение и изменение паролей.
5.2. Обеспечение защиты конкретных данных: определение прав доступа
групп пользователей и отдельных пользователей, определение допустимых
операций над данными для отдельных пользователей, выбор/создание
программно-технологических средств защиты данных.
5.3. Тестирование средств защиты данных.
5.4. Фиксация попыток несанкционированного доступа к информации.
5.5. Исследование возникающих случаев нарушения защиты данных и
проведение мероприятий по их предотвращению.
6. Обеспечение восстановления БД: разработка программнотехнологических средств восстановления БД, организация ведения системных
журналов.
7. Анализ обращений пользователей к БД: сбор статистики обращений
пользователей к БД, ее хранение и анализ (кто из пользователей, к какой
информации, как часто обращался, какие выполнял операции, время
выполнения запросов, анализ причин безуспешных (в том числе и аварийных)
обращений к БД).
8. Анализ эффективности функционирования БнД и развитие системы:
анализ показателей функционирования системы (время обработки, объем памяти,
стоимостные показатели), реорганизация и реструктуризация баз данных,
изменение состава баз данных, развитие программных и технических средств.
9. Работа с пользователями: сбор информации об изменениях в
предметной области, об оценке пользователями работы БнД, определение
регламента работы пользователей с БнД, обучение пользователей,
консультирование пользователей.
10. Подготовка и поддержание системных программных средств: сбор и
анализ информации о СУБД и ППП, приобретение программных средств, их
установка, проверка работоспособности, поддержание системных библиотек,
развитие программных средств.
11. Организационно-методическая работа: выбор или создание методики
проектирования БД, определение целей и направлений развития системы,
планирование этапов развития БнД, разработка и выпуск организационнометодических материалов.
2.8. Архитектура клиент/сервер
На высоком уровне систему баз данных можно рассматривать как
систему, состоящую из двух частей – сервера (или машины базы данных) и
набора клиентов (или внешнего интерфейса) (рис. 2.6) [9].
Сервер – это собственно СУБД.
33
Клиенты – это различные приложения, которые выполняются «над»
СУБД. Они делятся на приложения, написанные пользователями, и
приложения, предоставляемые поставщиками (инструментальные системы).
Конечные
пользователи
Приложения
Приложения
Клиенты
Компьютер
клиента
Удаленный
доступ
СУБД
Сервер
СУБД
Компьютер
сервера
База данных
Рис 2.6. Архитектура клиент/сервер.
Рис. 2.7. Клиент и сервер
запускаются на разных машинах.
Инструментальные системы делятся на несколько классов:
процессоры языков запросов;
генераторы отчетов;
графические бизнес-подсистемы;
электронные таблицы;
процессоры обычных языков;
средства управления копированием;
генераторы приложений;
другие средства разработки приложений, включая CASE-продукты
(CASE или Computer-Aided Software-Engineering – автоматизация разработки
программного обеспечения).
34
Поскольку система в целом может быть четко разделена на две части
(сервер и клиенты), появляется возможность работы этих двух частей на разных
машинах, т.е. существует возможность распределенной обработки (рис. 2.7).
Разные машины соединяются в коммуникационную сеть так, что одна
задача обработки данных распределяется на несколько машин в сети, связь
осуществляется с помощью специального программного обеспечения для
управления сетью.
Преимущества распределенной обработки:
возможность параллельной обработки данных: для всей задачи
применяется несколько процессоров и обработка сервера и клиента
осуществляется параллельно, поэтому время ответа и производительное время
должны уменьшиться;
Компьютеры
клиентов
Коммуникационная
сеть
Компьютер
сервера
Рис. 2.8. Один сервер, много клиентов
машина сервера может быть изготовлена по специальному заказу,
приспособлена для работы с СУБД и может обеспечить лучшую
производительность СУБД;
машина клиента может быть персональной станцией, приспособленной к
потребностям конечного пользователя;
возможность совместного использования базы данных (рис. 2.8);
выполнение сервера и клиента на отдельных машинах соответствует
практической работе многих предприятий.
35
Машины клиентов могут иметь свои собственные сохраняемые данные, а
машина сервера может иметь свои собственные приложения, т.е. каждая
машина будет выступать в роли сервера для одних пользователей и в роли
клиента для других, иными словами, каждая машина будет поддерживать
полную систему баз данных (рис. 2.9).
Клиенты
Сервер
Клиенты
Клиенты
Сервер
Сервер
Коммуникационная
сеть
Клиенты
Клиенты
Сервер
Сервер
Рис. 2.9. Каждая машина одновременно является клиентом и сервером
Отдельная машина клиента может иметь доступ к нескольким разным
машинам серверов. Такой доступ предоставляется двумя способами:
1. Клиент получает доступ к любому количеству серверов, но лишь к
одному в одно и то же время.
2. Клиент может получать доступ к любому количеству серверов
одновременно (т.е. за один запрос можно получить комбинированные данные
двух или более серверов). В этом случае серверы рассматриваются клиентом
36
как один (с логической точки зрения), и пользователь может не знать, на какой
именно машине какая часть данных содержится.
Второй пример системы обычно называют распределенной системой баз
данных. Полная поддержка для распределенных баз данных означает, что
отдельное приложение может «прозрачно» обрабатывать данные,
распределенные на множестве различных баз данных, управление которыми
осуществляют разные СУБД, работающие на многочисленных машинах с
различными
операционными
системами,
соединенными
вместе
коммуникационными сетями. Понятие «прозрачно» означает, что приложение
выполняет обработку данных с логической точки зрения, как будто управление
данными полностью осуществляется одной СУБД, работающей на отдельной
машине. Такая возможность может показаться невероятно трудной задачей, но
весьма желанной с практической точки зрения.
КОНТРОЛЬНЫЕ ВОПРОСЫ
1.Что представляет собой банк данных, какие компоненты входят в его
состав?
2.Дайте определение базы данных.
3.Перечислите программные средства банка данных.
4.Каково назначение СУБД?
5.Охарактеризуйте языковые средства банка данных.
6.Приведите классификацию баз данных.
7.По каким признакам можно классифицировать СУБД?
8.Приведите классификацию банков данных по экономикоорганизационным признакам.
9.Какие требования предъявляются к банкам данных?
10.Охарактеризуйте преимущества банка данных по сравнению с
традиционным методом содержания записей.
11.Что представляет собой централизованное хранение данных?
12.В чем заключается независимость данных?
13.Опишите основные уровни трехуровневой архитектуры системы баз
данных.
14.Выделите основные группы пользователей банка данных, дайте их
характеристики.
15.Перечислите функции администратора банка данных.
16.Перечислите основные функции СУБД.
17.Что представляет собой архитектура «клиент-сервер»?
18.Перечислите преимущества распределенной обработки данных.
19.Дайте определение полной и распределенной системы баз данных.
37
3. МОДЕЛИ И ТИПЫ ДАННЫХ
Хранимые в базе данные имеют определенную логическую структуру –
иными словами, описываются некоторой моделью представления данных
(моделью данных), поддерживаемой СУБД [28]. К числу классических
относятся следующие модели данных:
• иерархическая;
• сетевая;
• реляционная.
Кроме того, в последние годы появились и стали более активно
внедряться на практике следующие модели данных:
• постреляционная;
• многомерная;
• объектно-ориентированная.
Разрабатываются также всевозможные системы, основанные на других
моделях данных, расширяющих известные модели. В их числе можно назвать
объектно-реляционные, дедуктивно-объектно-ориентированные, семантические,
концептуальные и ориентированные модели. Некоторые из этих моделей служат
для интеграции баз данных, баз знаний и языков программирования. В
некоторых СУБД поддерживается одновременно несколько моделей данных.
3.1. Иерархическая модель
В иерархической модели связи между данными можно описать с
помощью упорядоченного графа (или дерева). Упрощенно представление
связей между данными в иерархической модели показано на рис. 3.1.
Рис. 3.1. Представление связей в иерархической модели
Для описания структуры иерархической БД на некотором языке
программирования используется тип данных «дерево». Тип «дерево» схож с
типами данных «структура» языка программирования Си и «запись» языка
Паскаль. В них допускается вложенность типов, каждый из которых находится
38
на некотором уровне. Тип «дерево» является составным. Он включает в себя
подтипы («поддеревья»), каждый из которых, в свою очередь, является типом
«дерево». Каждый из типов «дерево» состоит из одного «корневого» типа и
упорядоченного набора (возможно, пустого) подчиненных типов. Каждый из
элементарных типов, включенных в тип «дерево», является простым или
составным типом «запись». Простая «запись» состоит из одного типа,
например, числового, а составная «запись» объединяет некоторую с овокупность типов, например, целое, строку символов и указатель (ссылку).
Пример типа «дерево» как совокупности типов показан на рис. 3.2.
Отдел
Отд_номер
Отд_размер
Начальник
Нач_номер
Отд_зарплата
Сотрудник
Нач_имя
Нач_телефон
Сотр_номер
Сотр_имя
Сотр_зарплата
Рис. 3.2. Пример типа «дерево»
Корневым называется тип, который имеет подчиненные типы и сам не
является подтипом. Подчиненный тип (подтип) является потомком по
отношению к типу, который выступает для него в роли предка (родителя).
Потомки одного и того же типа являются близнецами по отношению друг к
другу.
В целом тип «дерево» представляет собой иерархически организованный
набор типов «запись».
Иерархическая БД представляет собой упорядоченную совокупность
экземпляров данных типа «дерево» (деревьев), содержащих экземпляры типа
«запись» (записи). Часто отношения родства между типами переносят на
отношения между самими записями. Поля записей хранят собственно числовые или
символьные значения, составляющие основное содержание БД. Обход всех
элементов иерархической БД обычно производится сверху вниз и слева направо.
Для организации физического размещения иерархических данных в
памяти ЭВМ могут использоваться следующие группы методов:
• представление линейным списком с последовательным распределением
памяти (адресная арифметика, левосписковые структуры);
• представление связными линейными списками (методы, использующие
указатели и справочники).
К
основным
операциям
манипулирования
иерархически
организованными данными относятся следующие:
39
• поиск указанного экземпляра БД (например, дерева со значением 10 в
поле Отд_номер);
• переход от одного дерева к другому;
• переход от одной записи к другой внутри дерева (например, к
следующей записи типа Сотрудники);
• вставка новой записи в указанную позицию;
• удаление текущей записи и т. д.
В соответствии с определением типа «дерево» можно заключить, что
между предками и потомками автоматически поддерживается контроль
целостности связей. Основное правило контроля целостности формулируется
следующим образом: потомок не может существовать без родителя, а у
некоторых родителей может не быть потомков. Механизмы поддержания
целостности связей между записями различных деревьев отсутствуют.
К достоинствам иерархической модели данных относятся эффективное
использование памяти ЭВМ и неплохие показатели времени выполнения
основных операций над данными. Иерархическая модель данных удобна для
работы с иерархически упорядоченной информацией.
Недостатком иерархической модели является ее громоздкость для
обработки информации с достаточно сложными логическими связями, а также
сложность понимания для обычного пользователя. На иерархической модели
данных основано сравнительно ограниченное количество СУБД, в числе
которых можно назвать зарубежные системы IMS, PC/Focus, Team-Up и Data
Edge, а также отечественные системы Ока, ИНЭС и МИРИС.
3.2. Сетевая модель
Сетевая модель данных позволяет отображать разнообразные
взаимосвязи элементов данных в виде произвольного графа, обобщая тем
самым иерархическую модель данных (рис. 3.3). Наиболее полно концепция
сетевых БД впервые была изложена в «Предложениях группы КОДАСИЛ»
(KODASYL – Conference on Data System Languages).
Рис. 3.3. Представление связей в сетевой модели
Для описания схемы сетевой БД используются две группы типов:
«запись» и «связь». Тип «связь» определяется для двух типов «запись»: предка
и потомка. Переменные типа «связь» являются экземплярами связей.
40
Сетевая БД состоит из набора записей и набора соответствующих связей.
На формирование связи особых ограничений не накладывается. Если в
иерархических структурах запись-потомок могла иметь только одну записьпредка, то в сетевой модели данных запись-потомок может иметь произвольное
число записей-предков (сводных родителей).
Пример схемы простейшей сетевой БД показан на рис. 3.4. Типы связей
здесь обозначены надписями на соединяющих типы записей линиях.
Работают в отделе
Отдел
Сотрудники
Начальник
Состоит из сотрудников
Имеет начальника
Рис. 3.4. Пример схемы сетевой БД
Физическое размещение данных в базах сетевого типа может быть
организовано практически теми же методами, что и в иерархических базах
данных. К числу важнейших операций манипулирования данными баз сетевого
типа можно отнести следующие:
• поиск записи в БД;
• переход от предка к первому потомку;
• переход от потомка к предку;
• создание новой записи;
• удаление текущей записи;
• обновление текущей записи;
• включение записи в связь;
• исключение записи из связи;
• изменение связей и т. д.
Достоинством сетевой модели данных является возможность
эффективной реализации по показателям затрат памяти и оперативности. В
сравнении с иерархической моделью сетевая модель предоставляет большие
возможности в смысле допустимости образования произвольных связей.
Недостатком сетевой модели данных является высокая сложность и
жесткость схемы БД, построенной на ее основе, а также сложность для
понимания и выполнения обработки информации в БД обычным
пользователем. Кроме того, в сетевой модели данных ослаблен контроль
целостности связей вследствие допустимости установления произвольных
41
связей между записями. Системы на основе сетевой модели не получили
широкого распространения на практике. Наиболее известными сетевыми СУБД
являются следующие: IDMS, db_VistaIII, СЕТЬ, СЕТОР и КОМПАС.
3.3. Реляционная модель
Реляционная модель данных предложена сотрудником фирмы IBM
Эдгаром Коддом и основывается на понятии «отношение» (relation).
Отношение представляет собой множество элементов, называемых кортежами.
Подробно теоретическая основа реляционной модели данных рассматривается
в следующем разделе. Наглядной формой представления отношения является
привычная для человеческого восприятия двумерная таблица. Таблица имеет
строки (записи) и столбцы (колонки). Каждая строка таблицы имеет
одинаковую структуру и состоит из полей. Строкам таблицы соответствуют
кортежи, а столбцам – атрибуты отношения.
С помощью одной таблицы удобно описывать простейший вид связей
между данными, а именно: деление одного объекта (явления, сущности,
системы и проч.), информация о котором хранится в таблице, на множество
под- объектов, каждому из которых соответствует строка или запись таблицы.
При этом каждый из подобъектов имеет одинаковую структуру или сво йства,
описываемые соответствующими значениями полей записей. Например,
таблица может содержать сведения о группе обучаемых, о каждом из которых
известны следующие характеристики: фамилия, имя и отчество, пол, возраст и
образование. Поскольку в рамках одной таблицы не удается описать более
сложные логические структуры данных из предметной области, применяют
связывание таблиц. Физическое размещение данных в реляционных базах на
внешних носителях легко осуществляется с помощью обычных файлов.
Достоинство реляционной модели данных заключается в простоте,
понятности и удобстве физической реализации на ЭВМ. Именно простота и
понятность для пользователя явились основной причиной их широкого
применения. Проблемы же эффективности обработки данных этого типа
оказались технически вполне разрешимыми. Основными недостатками
реляционной модели являются следующие: отсутствие стандартных средств
идентификации отдельных записей и сложность описания иерархических и
сетевых связей. Примерами зарубежных реляционных СУБД для ПЭВМ
являются следующие: dBaseIII Plus и dBase IY, DB2, Paradox и dBASE for
Windows, Visual FoxPro и Access, Clarion, Ingres и Oracle.
3.4. Постреляционная модель
Классическая реляционная модель предполагает неделимость данных,
хранящихся в полях записей таблиц. Это означает, что информация в таблице
представляется в первой нормальной форме. Существует ряд случаев, когда это
ограничение мешает эффективной реализации приложений. Постреляционная
42
модель данных представляет собой расширенную реляционную модель,
снимающую ограничение неделимости данных, хранящихся в записях таблиц.
Постреляционная модель данных допускает многозначные поля – поля, значения
которых состоят из подзначений. Набор значений многозначных полей считается
самостоятельной таблицей, встроенной в основную таблицу.
На рис. 3.5 на примере информации о накладных и товарах для сравнения
приведено представление одних и тех же данных с помощью реляционной (а) и
постреляционной (б) моделей [28]. Таблица INVOICES (накладные) содержит
данные о номерах накладных (INVNO) и номерах покупателей (CUSTNO). В
таблице INVOICE.ITEMS (накладные-товары) содержатся данные о каждой из
накладных: номер накладной (INVNO), название товара (GOODS) и количество
товара (QTY). Таблица INVOICES связана с таблицей INVOICE.ITEMS по
полю INVNO.
а) INVOICES
INVNO
CUSTNO
0373
8723
8374
8232
7364
8723
INVOICE.ITEMS
INVNO
GOODS
0373
Сыр
0373
Рыба
8374
Лимонад
8374
Сок
8374
Печенье
7364
Йогурт
QTY
3
2
1
6
2
1
б) INVOICES
INVNO
0373
CUSTNO
8723
8374
8232
7364
8723
COODS
Сыр
Рыба
Лимонад
Сок
Печенье
Йогурт
QTY
3
2
1
6
2
1
Рис. 3.5. Структуры данных реляционной и постреляционной модели
Как видно из рис.3.5, по сравнению с реляционной моделью в
постреляционной модели данные хранятся более эффективно, а при обработке
не требуется выполнять операцию соединения данных из двух таблиц. Для
доказательства на рис. 3.6 приводятся примеры операторов SELECT выбора
43
данных из всех полей базы на языке SQL для реляционной (а) и
постреляционной (б) моделей.
Помимо обеспечения вложенности полей постреляционная модель
поддерживает ассоциированные многозначные поля (множественные группы).
Совокупность ассоциированных полей называется ассоциацией. При этом в
строке первое значение одного столбца ассоциации соответствует первым
значениям всех других столбцов ассоциации. Аналогичным образом связаны
все вторые значения столбцов и т. д.
На длину полей и количество полей в записях таблицы не накладывается
требование постоянства. Это означает, что структура данных и таблиц имеют
большую гибкость.
Поскольку постреляционная модель допускает хранение в таблицах
ненормализованных данных, возникает проблема обеспечения целостности и
непротиворечивости данных. Эта проблема решается включением в СУБД
механизмов, подобных хранимым процедурам в клиент-серверных системах.
а)
SELECT
INVOICES.INVNO, CUSTNO, GOODS, QTY
FROM
INVOICES, INVOICE.ITEMS
WHERE,
INVOICES.INVNO=INVOICE.ITEMS.INVNO;
6)
SELECT
INVNO, CUSTNO, GOODS, QTY
FROM
INVOICES;
Рис. 3.6. Операторы SQL для реляционной и постреляционной моделей
Для описания функций контроля значений в полях имеется возможность
создавать процедуры (коды конверсии и коды корреляции), автоматически
вызываемые до или после обращения к данным. Коды корреляции
выполняются сразу после чтения данных, перед их обработкой. Коды
конверсии, наоборот, выполняются после обработки данных.
Достоинством постреляционной модели является возможность
представления совокупности связанных реляционных таблиц одной
постреляционной таблицей. Это обеспечивает высокую наглядность
представления информации и повышение эффективности ее обработки.
Недостатком постреляционной модели является сложность решения проблемы
обеспечения целостности и непротиворечивости хранимых данных.
44
3.5. Многомерная модель
Многомерные СУБД являются узкоспециализированными СУБД,
предназначенными для интерактивной аналитической обработки информации.
Раскроем основные понятия, используемые в этих СУБД: агрегируемость,
историчность и прогнозируемость данных [28].
Агрегируемость данных означает рассмотрение информации на
различных уровнях ее обобщения. В информационных системах степень
детальности представления информации для пользователя зависит от его
уровня: аналитик, пользователь-оператор, управляющий, руководитель.
Историчность данных предполагает обеспечение высокого уровня
статичности (неизменности) собственно данных и их взаимосвязей, а также
обязательность привязки данных ко времени.
Статичность данных позволяет использовать при их обработке
специализированные методы загрузки, хранения, индексации и выборки.
Временная привязка данных необходима для частого выполнения
запросов, имеющих значения времени и даты в составе выборки.
Необходимость упорядочения данных по времени в процессе обработки и
представления данных пользователю накладывает требования на механизмы
хранения и доступа к информации. Так, для уменьшения времени обработки
запросов желательно, чтобы данные всегда были отсортированы в том порядке,
в котором они наиболее часто запрашиваются.
Прогнозируемость
данных
подразумевает
задание
функций
прогнозирования и применение их к различным временным интервалам.
Многомерность модели данных означает не многомерность визуализации
цифровых данных, а многомерное логическое представление структуры
информации при описании и в операциях манипулирования данными.
По сравнению с реляционной моделью многомерная организация данных
обладает более высокой наглядностью и информативностью. Для иллюстрации
на рис. 3.7 приведены реляционное (а) и многомерное (б) представления одних
и тех же данных об объемах продаж автомобилей.
Если речь идет о многомерной модели с мерностью больше двух, то не
обязательно визуально информация представляется в виде многомерных
объектов (трех-, четырех- и более мерных гиперкубов). Пользователю и в этих
случаях более удобно иметь дело с двухмерными таблицами или графиками.
Данные при этом представляют собой «вырезки» (точнее, «срезы») из
многомерного хранилища данных, выполненные с разной степенью
детализации.
Рассмотрим основные понятия многомерных моделей данных, к числу
которых относятся измерение и ячейка.
Измерение (Dimension) – это множество однотипных данных,
образующих одну из граней гиперкуба. Примерами наиболее часто
используемых временных измерений являются Дни, Месяцы, Кварталы и Годы.
45
В качестве географических измерений широко употребляются Города, Районы,
Регионы и Страны. В многомерной модели данных измерения играют роль
индексов, служащих для идентификации конкретных значений в ячейках
гиперкуба.
а)
Модель
«Жигули»
«Жигули»
«Жигули»
«Москвич»
«Москвич»
«Волга»
Месяц
июнь
июль
август
июнь
июль
июль
Объем
12
24
5
2
18
19
б)
Модель
«Жигули»
«Москвич»
«Волга»
Июнь
12
2
No
Июль
24
18
19
Август
5
No
No
Рис. 3.7. Реляционное и многомерное представление данных
2000
Измерения:
Время (год) – 1998, 1999, 2000.
Менеджер – Петров, Смирнов, Яковлев
Модель – «Волга», «Жигули», «Москвич»
Показатель: Объем продаж
1999
1998
Петров
9
4
9
Смирнов
4
9
7
Яковлев
7
7
4
Объем продаж
«Москвич»
«Жигули»
«Волга»
Рис. 3.8. Пример трехмерной модели
46
Ячейка (Cell) или показатель – это поле, значение которого однозначно
определяется фиксированным набором измерений. Тип поля чаще всего
определен как цифровой. В зависимости от того, как формируются значения
некоторой ячейки, обычно она может быть переменной (значения изменяются и
могут быть загружены из внешнего источника данных или сформированы
программно) либо формулой (значения, подобно формульным ячейкам
электронных таблиц, вычисляются по заранее заданным формулам).
В примере на рис. 3.7(б) каждое значение ячейки Объем продаж
однозначно определяется комбинацией временного измерения (Месяц пр одаж)
и модели автомобиля. На практике зачастую требуется большее количество
измерений. Пример трехмерной модели данных приведен на рис. 3.8.
В существующих МСУБД используются два основных варианта (схемы)
организации данных: гиперкубическая и поликубическая.
В поликубической схеме предполагается, что в БД может быть
определено несколько гиперкубов с различной размерностью и с различными
измерениями в качестве граней. Примером системы, поддерживающей
поликубический вариант БД, является сервер Oracle Express Server.
В случае гиперкубической схемы предполагается, что все показатели
определяются одним и тем же набором измерений. Это означает, что при
наличии нескольких гиперкубов БД все они имеют одинаковую размерность и
совпадающие измерения. Очевидно, в некоторых случаях информация в БД
может быть избыточной (если требовать обязательное заполнение ячеек).
В случае многомерной модели данных применяется ряд специальных
операций, к которым относятся: формирование «среза», «вращение», агрегация
и детализация.
«Срез» (Slice) представляет собой подмножество гиперкуба, полученное в
результате фиксации одного или нескольких измерений. Формирование
«срезов» выполняется для ограничения используемых пользователем знач ений,
так как все значения гиперкуба практически никогда одновременно не
используются. Например, если ограничить значения измерения Модель
автомобиля в гиперкубе (см. рис. 3.8) маркой «Жигули», то получится
двухмерная таблица продаж этой марки автомобиля различными менеджерами
по годам.
Операция «вращение» (Rotate) применяется при двухмерном
представлении данных. Суть ее заключается в изменении порядка измерений
при визуальном представлении данных. Так, «вращение» двумерной таблицы,
показанной на рис. 3.7(б), приведет к изменению ее вида таким образом, что по
оси Х будет марка автомобиля, а по оси Y – время.
Операцию «вращение» можно обобщить и на многомерный случай, если
под ней понимать процедуру изменения порядка следования измерений. В
простейшем случае, например, это может быть взаимная перестановка двух
произвольных измерений.
47
Операции «агрегация» (Drill Up) и «детализация» (Drill Down) означают
соответственно переход к более общему и к более детальному представлению
информации пользователю из гиперкуба.
Основным достоинством многомерной модели данных является удобство
и эффективность аналитической обработки больших объемов данных,
связанных со временем. При организации обработки аналогичных данных на
основе реляционной модели происходит нелинейный рост трудоемкости
операций в зависимости от размерности БД и существенное увеличение з атрат
оперативной памяти на индексацию. Недостатком многомерной модели данных
является ее громоздкость для простейших задач обычной оперативной
обработки информации.
3.6. Типы данных
Первоначально СУБД применялись преимущественно для решения
финансово-экономических задач. При этом, независимо от модели
представления, в базах данных использовались следующие основные типы
данных:
• числовые. Примеры значений данных: 0.43, 328, 2Е+5;
• символьные (алфавитно-цифровые). Примеры значений данных:
"пятница", "строка", "программист";
• даты, задаваемые с помощью специального типа "Дата" или как
обычные символьные данные. Примеры значений данных: 1.12.97, 23/2/1999.
В разных СУБД эти типы могли несущественно отличаться друг от друга
по названию, диапазону значений и виду представления. Впоследствии в новых
областях применения стали появляться специализированные системы
обработки
данных,
например,
геоинформационные,
обработки
видеоизображений и т. д. В связи с этим разработчики стали вводить в
традиционные СУБД новые типы данных. К числу сравнительно новых типов
данных можно отнести следующие:
• временные и дата-временные, предназначенные для хранения
информации о времени и/или дате. Примеры значений данных: 31.01.85 (дата),
9:10:03 (время), 6.03.1960 12:00 (дата и время);
• символьные переменной длины, предназначенные для хранения
текстовой информации большой длины, например, документа;
• двоичные, предназначенные для хранения графических объектов, аудиои видеоинформации, пространственной, хронологической и другой
специальной информации. Например, в MS Access таким типом является тип
данных "Поле объекта OLE", который позволяет хранить в БД графические
данные в формате BMP (Bitmap) и автоматически их отображать при работе с БД;
48
• гиперссылки (hyperlinks), предназначенные для хранения ссылок на
различные ресурсы (узлы, файлы, документы и т. д.), находящиеся вне базы
данных, например, в сети Internet, корпоративной сети intranet или на жестком
диске компьютера. Примеры значений данных:
http:\\www.chat.ru, ftp:\\chance4u.teens.com.
В современных СУБД с различными моделями данных могут
использоваться все перечисленные типы данных.
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Перечислите классические и современные модели представления
данных.
2. Укажите достоинства и недостатки иерархической модели данных.
3. Как организуется физическое размещение данных в БД иерархического
типа?
4. Охарактеризуйте сетевую модель данных.
5. Охарактеризуйте реляционную модель данных.
6. В чем отличие между постреляционной и реляционной моделями
данных?
7. Укажите достоинства и недостатки постреляционной модели.
8. Охарактеризуйте многомерную модель.
9. Назовите и поясните смысл операций, выполняемых над данными в
случае многомерной модели.
49
4. ПРИМЕНЕНИЕ БАЗ ДАННЫХ В КОРПОРАТИВНЫХ
ИНФОРМАЦИОННЫХ СИСТЕМАХ
4.1. Корпоративная информационная система
Наиболее преуспевающими в деловом мире являются те фирмы и
корпорации, которые в состоянии быстрее всех собрать информацию,
обработать, проанализировать ее и на основе этого принять решение, то есть
использующие современные информационные технологии. Поэтому
максимально эффективной автоматизированной системой является та,
которая охватывает все взаимосвязанные многогранные бизнес -процессы, все
аспекты внутри - и внешнехозяйственной деятельности, то есть комплексные
автоматизированные системы.
Корпорации имеют высокий уровень организации и специализации
производственной и административной деятельности, значительную
рассредоточенность подразделений, большие отчеты данных, а также сильно
развитую информационно-технологическую инфраструктуру.
Корпоративные информационные системы характеризуются комплексностью охвата функций управления, повышенной упорядоченностью
деловых процессов, массовостью операций. Им свойственны эффективность
использования компьютерного и телекоммуникационного оборудования,
программного обеспечения. Они обладают возможностью локальной установки
и внедрения отдельных частей системы, высокой степенью адаптивно сти
функциональной структуры к особенностям управляемого объекта.
Примером такой системы является система "Галактика" - программный
продукт корпорации "Галактика", авторитетно представляющей себя на рынке
автоматизированных систем управления крупным предприятием.
Решение всего комплекса задач, на который ориентирована корпоративная информационная система управления предприятием, обеспечивается
четырьмя функциональными контурами:
Контуром административного управления
Контуром оперативного управления
Контуром управления производством
Контуром бухгалтерского учета
Модульный принцип построения системы допускает как изолированное
использование отдельных программных модулей, так и их произвольные
комбинации, в зависимости от производственно-экономической необходимости.
В результате работы всех пользователей системы происходит наполнение
базы данных предприятия (организации) оперативной информацией о ходе
выполнения конкретных хозяйственных операций, относящихся к различным
направлениям деятельности. Обработка оперативной информации позволяет с
одной стороны, проанализировать взаимоотношения с контрагентом на основе
сведений о движении матценностей, услуг, работ и финансовых средств, а с
50
другой стороны, оценить эффективность работы предприятия по различным
направлениям хозяйственной деятельности. При этом обеспечивается:
принцип однократного ввода в БД информации и, как следствие,
отсутствие
дублирования
функций
пользователей,
упорядочение
документооборота;
легкость контроля на корректность и целостность данных,
персонификация действий пользователя;
контроль за регламентом выполнения хозяйственных операций;
быстрая перестройка системы, изменение эксплуатационной схемы
системы при изменении бизнес-процесса (технологии управления).
4.2. Контур административного управления
4.2.1. Наполнение баз данных на примере модуля
«Управление персоналом»
Программный модуль "Управление персоналом" предназначен для:
автоматизации процесса ведения личных дел сотрудников;
планирования и управления штатным расписанием и резервом на
замещение должностей;
планирования и учета рабочего времени сотрудников;
получения отчетов по кадровой информации о сотрудниках
предприятия.
На рис. 4.1 представлена схема функционирования модуля, в которой
показана взаимосвязь задач, решаемых системой, с хранящейся в базе данных
информацией. Показано взаимодействие и с другими модулями системы.
Управление штатами обеспечивает составление штатного расписания
предприятия с указанием основных характеристик рабочих мест. При
необходимости можно завести дополнительные характеристики, состав
которых определяется пользователем (требования к квалификации,
образованию, возрасту, должностные инструкции, оснащение рабочего места и
т.д.).
1 – Личное дело сотрудника состоит из 10 разделов, содержащих в сумме
около 150 показателей. Раздел "Анкетные данные" позволяет сформировать
анкету с необходимым набором вопросов. Кроме того, к личному делу можно
"подшить" произвольное количество приложений, содержащих текстовую
(автобиография, характеристики и т.п.), графическую (фото...) и другую
необходимую информацию.
Все назначения и перемещения выполняются в увязке со штатным
расписанием. Один сотрудник может занимать несколько ставок, в том числе
неполных. По каждому рабочему месту можно составить список сотрудников,
входящих в резерв на замещение данной должности.
51
Рис. 4.1. Взаимосвязь задач, решаемых системой "Управление персоналом"
Средства подготовки отчетов предлагают возможность гибкой
настройки выходных документов на потребности конкретного предприятия.
52
Создание отчета включает в себя определение правил отбора
сотрудников в отчет, порядок их сортировки и выбор формы
выходного
документа.
Пользователь
может
создать
свой
собственный отчет в дополнение к уже имеющимся и включить его в
список стандартных отчетов для дальнейшего использования.
Модуль учета и управления кадрами дает гибкие средства для
адаптации к самым различным требованиям:
• состав и структура каталогов по лностью определяются
потребностями
предприятия,
пользователь
может
создавать
собственные каталоги для з аполнения анкет и дополнительных
характеристик рабочих мест;
• анкета позволяет вводить произвольные, не предусмотренные
программой данные о сотруднике и использовать их при отборе и
сортировке выводимых в отчет записей;
•
приложения
позволяют
хранить
произвольную
дополнительную информацию о сотруднике – как текстовую, так и
графическую;
• состав имеющихся отчетов легко расширяется заданием
правил отбора сотрудников в отчет и порядка 'их сортировки. Формы
выходных документов проектируются с помощью текстового
редактора.
Модуль учета и управления кадрами может быть установлен
вами как в локальном варианте, когда вся работа выполняется на
одном компьютере, так и в сетевом варианте, когда работа над
одними и теми же данными может выполняться на н ескольких
компьютерах одновременно, что позволяет гибко распределять
обязанности между работниками отдела кадров и другими по требителями кадровой информации:
• ведение стадий обработки документов и контроль исполнения
документов;
• поиск документов по формальным полям, присвоенным
данному документу;
• продвижение документов по маршруту обработки;
• массовая рассылка документов в подразделения;
• регистрация (постановка на учет) отчетов системы как
документов;
• вывод на экран списка всех учтенных документов, связанных
с документами-основаниями системы (например, счетами за
проданные
товары
или
услуги)
и
направлениями
работ
хозяйственного плана; просмотр любого из указан ных документов.
Связь с документами-основаниями устанавливается пользователем.
Схема документооборота на предприятии (в организации)
представлена на следующем рис. 4.2.
53
Рис. 4.2. Сх ема документообор ота предприятия
4.3. Контур оперативного управления
К контуру оперативного управления отнесены задачи, непосредственно
связанные с реализацией производственных планов предприятия. Среди этих
задач можно выделить как актуальные для всех типов организаций (снабжение,
складской учет), так и характерные только для торговых организаций
(операции с консигнационным товаром розничная торговля).
Настраиваемость и модульная структура системы позволяют Вам выбрать
для приобретения только необходимые компоненты.
Схема информационных потоков контура оперативного управления
приведена на рис. 4.3.
4.3.1. Пример организации модуля «Управление продажами (сбыт)»
Пользовательский интерфейс программного модуля "Управление продажами
"реализован аналогично интерфейсу модуля "Управление закупками".
54
Новым элементом модуля "Управление продажами" является функция
формирования отпускных цен. Система позволит вам создать и поддерживать
произвольное число различных прайс-листов. Так, можно иметь отдельные
прайс-листы для крупнооптовой и мелкооптовой торговли, для розничных
продаж, для выделенных групп товаров и услуг и т.п. Прайс -лист можно
формировать вручную либо автоматически, рассчитывая предполагаемую цену
реализации путем добавления к учетной цене ТМЦ описанной пользователем
гибкой системы торговых наценок (скидок) и налогов.
Технология решения задачи управления продажами проиллюстрирована
схемой на рис. 4.3.
Из особенностей реализации этого модуля следует отметить следующие
возможности:
• произвольное число позиций в документе на продажу;
• учет типа налогообложения при оформлении документа;
• гибкая возможность изменения цен путем оперативной корректиро вки
прайс-листов;
• использование в документах на продажу как товарных, так и нематериальных позиций (услуг);
• автоматическое формирование номеров документов на продажу с
возможностью их корректировки пользователем;
возможность корректировки курса валюты непосредственно в процессе
формирования документа;
• возможность ведения продаж наборами (комплектами) товаров;
• динамический контроль наличия товаров на складе при выписке счета;
• возможность оформлять счета для отсутствующих в наличии товаров
(вариант предоплаты);
• автоматическое либо ручное резервирование ТМЦ в разрезе складов и
предприятий при выписке документа и гибкое управление резервом;
• возможность управлять выбором склада, с которого должна произойти
отгрузка;
• возможность автоматически оформлять накладную по выписанному
документу-основанию;
• контроль повторных попыток оформить накладную на отпуск по уже
исполненному документу-основанию;
• возможность автоматически производить списание товара на складе при
оформлении накладной на его отпуск;
• учет возвратов ТМЦ;
• автоматическое формирование расходных складских ордеров по группе
накладных;
• формирование платежных требований на оплату по документамоснованиям;
• получение сведений о документах-основаниях по выбранным
контрагентам с помощью "карточки покупателя";
55
Рис. 4.3. Схема реализации модуля "Управление продажами"
56
• прогнозирование объемов закупок и формирование заявок на дефициты;
• полная интеграция с модулем "Поставщики, получатели";
• отражение в бухгалтерском контуре всех операций по реализации
материальных ценностей и услуг с помощью механизма типовых
хозяйственных операций.
Стандартные отчеты:
• печать накладных;
• отчеты о состоянии документов-оснований на продажу (в исполнении,
просрочены, оплачены и др.);
• отчеты о реализованных товарах и услугах в разрезе номенклатуры,
групп, партий, внешней классификации, получателей;
• отчет о несоответствиях в документах на продажу;
• реестры документов-оснований и накладных;
• анализ реализации по периодам в разрезе контрагентов (либо групп
контрагентов по регионам, формам собственности и т.д.) и товаров (групп
товаров).
4.3.2. Базы данных модуля «Автотранспорт»
Модуль «Автотранспорт» предназначен для учета и анализа работы
автотранспорта как на предприятиях, обеспечивающих перевозку грузов
собственным средствами, так и на автотранспортных предприятиях,
оказывающих услуги по перевозке грузов и пассажиров.
С помощью данного модуля можно выполнить следующие задачи:
• вести картотеки подвижного состава и водителей. Составлять табели
транспортных средств и водителей;
• формировать картотеки заказов на внешние и внутрихозяйственные
работы как на основании накладных (актов на услуги), так и независимо от них;
• выписывать и обрабатывать путевые листы;
• рассчитывать расход ГСМ, выручку и стоимость услуг;
•получать оперативную информацию о состоянии транспортных средств
и данных о водителях и на основании этой информации направлять
транспортные средства на ТО и капитальный ремонт;
• просматривать текущие данные о распределении работ среди водителей;
• учитывать пробег шин и работу аккумуляторов на основе данных из
путевых листов;
• выдавать отчеты по технико-эксплуатационным показателям работы
автотранспорта, техническому обслуживанию, расходу ГСМ, оплате труда
водителей, сведениям о заказчиках, пробегам шин и работе аккумуляторов.
Передавать данные об оплате труда водителей в модуль «Зарплата». В
информационной системе управления предприятием должны быть реализованы
связи модуля «Автотранспорт» с модулями:
• «Заработная плата», в который передаются данные из путевых листов;
57
• Основные средства, данные из которого передаются в карточку
транспортных средств;
• информация из модулей «Управление закупками», «Управление продажами», «Консигнация», «Складской учет». «Производство» используется при
формировании картотеки заказов на основании сопроводительных документов.
Информационная база модуля Автотранспорт очень обширна. Ее общая
структура представлена на рис. 4.4.
Картотека основного
состава
Рис. 4.4. Информационная база модуля "Автотранспорт"
4.4. Контур бухгалтерского учета
Базы данных модуля «Расчет зарплаты»
Модуль «Зарплата» полностью автоматизирует ведение табелей и расчет
начислений, удержаний и налогов на фонд оплаты труда (ФОТ) при
повременной и сдельной форме оплаты. При ее разработке реализованы два
основных принципа:
• универсальность – возможность использования в любых организациях,
начиная от крупных, со штатом в несколько тысяч человек, до предприятий
малого бизнеса, с любым режимом работы;
58
• адаптируемость
– обеспечение возможности бухгалтеру
самостоятельно проводить настройку с учетом специфики конкретного
предприятия и изменений действующего законодательства.
Для начисления заработка можно использовать до 160 видов оплат. Для
каждого вида оплаты можно определять алгоритм расчета, включение в расчет
различных видов удержаний, средних заработков и налогов на ФОТ. В
стандартном варианте поставки настроено до 30-ти видов оплат. При
необходимости помимо стандартного набора алгоритмов расчета можно
использовать собственные алгоритмы. Их формирование обеспечивается
набором функций, обеспечивающих доступ к базе данных, и не требует
специальной подготовки пользователя.
Обеспечивается ведение лицевых счетов работников и хранение данных
обо всех начислениях и удержаниях за прошлый и текущий год. Эти данные
могут использоваться для получения разнообразных справок.
Модуль «Зарплата» позволяет получать разнообразную документацию,
начиная от расчетных листков и платежных ведомостей и кончая различными
сводами и контрольным журналом по оплате труда. Основной документ по
оплате труда – расчетно-платежная ведомость – допускает настройку формы в
зависимости от специфики предприятия.
При переходе к новому расчетному периоду автоматически формируются
бухгалтерские справки о начислениях, удержаниях и налогах на ФОТ.
Одновременно формируются платежные поручения на перечисление налогов, а
также удержаний в пользу других юридических и физических лиц. Дальнейшая
работа с этими документами производится в модуле «Финансы».
Модуль «Зарплата» имеет тесную взаимосвязь с модулем «Управление
персоналом». Учетные данные работников, введенные в одном из этих модулей,
становятся доступными для другого. Таким образом исключается
необходимость повторного ввода идентичных данных о работниках
предприятия. Функциональная схема модуля «Зарплата» приведена на рис. 4.5.
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Перечислите основные характеристики корпоративных систем.
2. Перечислите основные составляющие системы «Галактика».
3. Приведите пример организации баз данных модуля «Управление
персоналом»
4. Поясните общую схему документооборота предприятия.
5. Опишите компоновку баз данных в модуле «Управление продажами».
6. Перечислите составные части модуля «Автотранспорт».
7. Пояснить взаимодействие баз данных модулей «Зарплата» и
«Управление персоналом».
59
Рис. 4.5. Функциональная схема модуля «Зарплата»
60
5. СПРАВОЧНО-ПРАВОВЫЕ БАЗЫ ДАННЫХ
5.1. Общая характеристика справочно-правовых баз
Пожалуй, самым существенным отличием справочных правовых систем
от других баз данных, да и от другого программного обеспечения воо бще,
является постоянная передача информации в пользовательские СПС. Причем
оперативность поступления новых документов рассматривается и
разработчиками СПС, и пользователями как одно из основных потребительских
качеств информационных систем по законодательству.
Технологически обновление информации в системах разных
разработчиков построено по-разному. В некоторых правовых базах данных
(например, "Гарант") при обновлении информации должна быть произведена
полная замена информационного банка. То есть "старая" база полностью
"затирается" и на ее место записывается новая. Такой способ обновления
предполагает обязательный визит курьера с переносным винчестером для
замены базы.
В системах другого типа, таких как "Консультант Плюс", обновление
информации основано на принципе "кусочного" пополнения. То есть в с истему
на компьютер пользователя добавляются лишь файлы пополнения: с новыми
документами, редакциями, изменениями и дополнениями. Это дает
пользователю реальную возможность ежедневно принимать новую
информацию по модему. Хотя, как показывает практика, многие пользователи,
если их устраивает не столь частое обновление, пользуются услугами
курьерской доставки (на дискете). Говоря о передаче информации в
пользовательские СПС, нельзя не отметить, что абсолютное большинство их
российских пользователей работают в режиме off-line, когда база данных
физически целиком находится на компьютере пользователя.
Видимо, пока в нашей стране работа в "оффлайновом" режиме
предпочтительна (по сравнению с работой в on-line) по целому ряду причин.
Во-первых, несмотря на внушительные объемы (от 10 до 150 Мб), большинство
существующих систем легко работают на любом современном компьютере.
Дело в том, что обычно разработчики снабжают свои правовые базы
программными средствами, обеспечивающими достаточную степень сжатия
информации и оперативное использование ресурсов памяти. Во-вторых,
технологические возможности отечественных СПС и в режиме off-line
позволяют поддерживать достаточный для пользователей уровень
оперативности получения новой информации. В-третьих, далеко не все
телефонные линии и не во всех регионах России способны поддерживать
длительную связь с хостом, необходимую для работы в режиме диалогового
доступа. И наконец, on-line может потребовать от пользователя
дополнительных нежелательных затрат, а именно: регулярного и длительного
выделения отдельной телефонной линии, оплаты телекоммуникационных услуг
61
и т.д. Кроме того, вряд ли юристу или бухгалтеру (etc.) захочется тратить свое
время и нередко часами "дозваниваться" до центрального сервера.
Однако надо заметить, что разработчики некоторых СПС уделяют
внимание и работе своих систем в "онлайновом" режиме. Правда, пока в
основном из имиджевых соображений. Ведь "мировая паутина" охватила уже и
Россию, и on-line считается модным, технологичным и современным
направлением. Первым, кто предоставил возможность on-line-доступа, была
система "ЮСИС". Вслед за этим "Гарант-Сервис" и "Центр компьютерных
разработок", по крайней мере, уже в своих рекламных материалах заявляют о
предоставлении пользователям возможности работы в режиме on-line. A
известие о появлении в августе 1996 года у АО "Консультант плюс"
собственного Internet-узла также может свидетельствовать о серьезных
намерениях в области on-line-доступа и у этой фирмы. Что пока можно сказать
совершенно определенно, так это, что практически все наиболее известные СПС
представлены в глобальных сетях своими демонстрационными версиями (демоверсии содержат лишь примеры текстов документов и показывают возможности
работы с системой). Их можно найти с помощью обычных поисковых систем.
Все без исключения разработчики убеждены, что они не "торгуют"
нормативными документами, а предоставляют пользователю удобный
инструмент для получения и хранения нормативной информации, а также
работы с ней. Действительно, справочные правовые системы – это не просто
набор текстов нормативных документов. Каждая СПС имеет информацио ннопоисковый аппарат, позволяющий очень быстро (1-10 секунд, в зависимости от
быстродействия системы и компьютера) находить нужный материал в массиве
из десятков тысяч документов.
Во всех справочных системах поиск происходит по стандартному набору
исходных реквизитов документа. Обычно это законодательная тематика,
принявший орган, дата (или временной период «с... по...») принятия,
официальный номер документа. Также во многих системах возможен поиск по
названию, по полному тексту (по любому слову из текста), по набору слов, по
ключевым словам. То есть алгоритм поиска совершенно такой же, как и в
обычной "бумажной" картотеке.
Чтобы найти требуемый документ, пользователь сначала должен открыть
"карточку реквизитов" ("карточку запроса"). Приведенные нами реквизиты
являются полями этой карточки. Заполнив одно или несколько полей, можно
получить все искомые нормативные акты, которые отвечают заданным
реквизитам.
На российском рынке представлен целый ряд справочно-правовых
систем, начиная от простейших, стоимостью от $20 и заканчивая мощными
программами, стоимость которых зачастую превышает $1000. В последнем
случае фирма-разработчик, как правило, имеет развитую региональную сеть как
по сбору информации, так и по ее распространению.
62
Ежегодно проводится конкурс баз данных правовой информации,
который с очевидностью позволяет сравнить достоинства и недос татки
представленных программ, определить направления дальнейшего развития
информатизации в правовой сфере.
Несмотря на заметные различия в организации пользовательского
интерфейса, в возможностях и скорости поиска, в объеме и качестве
накопленной информации, все системы имеют сходную функциональную
структуру. Типичная система правовой информации включает в себя:
средства поиска документов по контексту и рубрикатору;
средства поиска документа по реквизитам;
механизм навигации в базе данных по гипертекстовым
ссылкам;
модули работы со списками и текстами документов;
подсистему обновления базы данных.
5.2. Наиболее популярные юридические базы данных
5.2.1. База ЮСИС
ЮСИС ориентирована, в первую очередь, на профессиональных юристов,
законодателей, адвокатов, нотариусов, судей, юрисконсультов, которые в своей
деятельности постоянно нуждаются в юридической информации. Для них
ЮСИС играет роль персонального референта, предназначенного не только для
поиска документов по интересующей правовой тематике и ознакомления с
ними, но и для формирования из них подборок, разработки со бственных
документов.
ЮСИС позволяет формализовать процесс организации труда
профессионала на основе следующей схемы. С помощью ЮСИС изучается
правовой аспект интересующей области, создается подборка нормативных
актов. Из библиотеки ЮСИС выбирается типовая форма договора, письма,
приказа и т.п. и на ее основе подготавливается собственный документ.
Программный комплекс ЮСИС (в дальнейшем мы будем пользоваться
сокращением ПК ЮСИС, или просто ЮСИС) представляет собой обширный
архив (базу данных) юридических и справочных документов с хорошо
организованной картотекой. База данных и картотека периодически
пополняются вновь опубликованными материалами. ЮСИС является также
мощным инструментом для работы с архивом и картотекой. С помощью ПК
ЮСИС в архиве можно проводить поиск документов по тем критериям, которые
вы зададите, делать подборку материалов и правовые обоснования по
интересующим вас вопросам, прослеживать связи между отдельными
документами, делать из документов необходимые выписки. Вы можете снабдить
имеющиеся в архиве документы собственными аннотациями, добавить в архив
новые материалы и даже создать собственные архив и картотеку. При
необходимости последующая обработка материалов может производиться с
63
помощью стандартных текстовых редакторов, например, с помощью редактора
MS Word.
Таким образом, ПК ЮСИС является автоматизированным рабочим
местом
профессионального
юриста,
обеспечивая
необходимый
инструментарий для полного цикла работ с правовыми документами. С полной
уверенностью можно сказать, что в настоящее время ЮСИС является
стандартом работы с правовой информацией.
ЮСИС может эффективно использоваться не только юристами, но и
руководителями различного уровня, специалистами, предпринимателями,
студентами и аспирантами.
Для использования ПК ЮСИС не требуется каких-либо знаний в области
программирования, основная работа происходит путем выбора пунктов меню
или позиций в списках, появляющихся на экране.
ИСТОЧНИКИ ИНФОРМАЦИИ «ЮСИС» – эталонные банки данных
правовой информации:
Научно-технический центр «Система» (ФАПСИ при Президенте РФ);
Научный центр правовой информации Министерства юстиции РФ;
Нормативные акты министерств и ведомств РФ, Москвы и Московской
области;
Правовые акты Верховного Суда РФ и Высшего Арбитражного Суда РФ;
Дополнительные базы данных формируются совместно с ведущими
информационными агентствами, книжными издательствами и редакциями
средств массовой информации (ИА «Экономическая сеть», РИА «Ореанда», ИД
«ИНФРА-М», «Финансовая газета» и другие).
Функционально ПК ЮСИС состоит из следующих компонентов:
архива документов – базы данных, в которой содержатся тексты всех
материалов и документов вместе с необходимой служебной информацией;
картотеки – набора отдельных информационных карточек, каждая из
которых содержит сведения о данном документе (наименование, исходящие
данные, связи с другими документами, ключевые слова и т.п.);
инструментария – набора программ, позволяющих с помощью
компьютера производить поиск и анализ карточек и связанных с ними
документов, делать списки найденных документов, выписки из них, а также
добавлять собственные аннотации к документам.
5.2.2. Информационно-поисковая система "Кодекс"
Центр компьютерных разработок (ЦРК) при мэрии Санкт-Петербурга
занимается разработкой и ведением баз данных информационно-поисковой
системы "Кодекс" с 1991 года. Первое время эта система распространялась
практически только в Санкт-Петербурге и Ленинградской области, но,
начиная с 1994 года, фирма-разработчик стала предпринимать усилия по
продвижению системы на российский рынок. В настоящее время ЦРК имеет
64
свои представительства (региональные центры) в нескольких городах Ро ссии,
однако наиболее активно "Кодекс" рекламируется в Москве и по-прежнему в
Санкт-Петербурге.
Разработчики ИПС "Кодекс" предлагают своим пользователям набор
тематических баз по законодательству России, электронные подшивки газет,
а также некоторые справочные базы. Каждая из тематических баз "Кодекса"
содержит неплохую подборку документов по основной тематике, но
документы по смежным тематикам практически отсутствуют. Вследствие
этого пользователь должен приобретать несколько разных баз из
предлагаемого набора.
Фирма-разработчик ИПС "Кодекс" получает новые документы для своих
баз через региональные представительства федеральных органов власти в
Санкт-Петербурге. Следует отметить, что система имеет определенные
недостатки в наполнении информационного банка. Не лучшим образом она
реализована и с точки зрения программирования.
5.2.3. Справочно-правовая система "Гарант"
Разработкой СПС "Гарант" занимается компания "Гарант-Сервис",
которой в декабре 1997 года исполнилось семь лет. Разработки программы
начались в августе 1990 года. Первая версия СПС "Гарант" была представлена в
1991 году, и сегодня она выполнена на хорошем профессиональном уровне,
отличается высоким качеством информационного банка и программной
оболочки.
Разработчики СПС "Гарант" предлагают пользователю набор
тематических баз данных по законодательству. Это "Законодательство России",
"Таможенное законодательство", "Банковское законодательство", "Земельное
законодательство", "Жилищное законодательство", "Международное право",
"Уголовное и административное право", а также ряд баз по региональному
законодательству, в том числе по законодательству Москвы и СанктПетербурга. Также предлагается ряд вспомогательных баз ("Формы правовых
документов", "Налогообложение и бухгалтерский учет: Вопросы-Ответы").
Кроме того, в настоящее время в СПС Гарант включаются проекты законов,
находящихся на стадии рассмотрения и утверждения.
До последнего времени программная оболочка СПС "Гарант" не
позволяла производить кусочного пополнения информационного банка, то есть
приходилось при обновлении производить полную его замену. В настоящее
время эта проблема решена.
СПС "Гарант" обладает мощными возможностями как по поиску
нормативных актов, так и по аналитической работе с ними. Данная система
предлагает пользователю большое количество комментариев к документу:
информационные (предупреждают об изменении или прекращении действия
документов), разъясняющие (разъясняют, как применять документ),
выявляющие противоречия (указывают, как правильно трактовать
65
противоречивые формулировки), полезные советы (подсказывают, как
использовать льготы и послабления со стороны государства), исправляющие
ошибки (исправляют технические недоразумения и опечатки в оригинальных
текстах документов).
Система поиска по ключевым словам в СПС "Гарант", включающая в себя
от 2000 до 13000 ключевых слов в зависимости от базы, вызывает двойственные
чувства. С одной стороны, такое положение говорит о развитой возможности
данного вида поиска. Но, с другой стороны, может сложиться ситуация, когда
пользователь перегружен информацией. Поиск документа в этом случае
затягивается во многом из-за поиска необходимого ключевого слова.
Практический опыт работы со справочно-правовыми системами
показывает, что такое большое количество ключевых слов скорее следует
отнести к недостаткам, чем к достоинствам системы.
5.2.4. Справочно-правовая система «Консультант Плюс»
Справочно-правовая система «Консультант Плюс» на сегодняшний день,
обладая целым рядом уникальных особенностей, является наиболее мощной
системой на российском рынке. К числу таких особенностей можно отнести
следующие:
крупнейший информационный банк (более 240 тысяч документов);
пополнение информационного банка до 8 тысяч документов
ежемесячно;
возможность выбора системы любого уровня детализации - от
базовой системы, включающей основы законодательства и правовые акты
общего значения, до крупнейшего банка действующих правовых актов
Российской Федерации;
выполнение Госзаказа по разработке системы классификации
нормативных актов РФ в рамках Соглашения между Правительством РФ и
Международным банком реконструкции и развития;
быстродействие операций с базой данных (добавление и изменение
документов, построение индексов, в том числе по тексту), в 2-3 раза
превосходящее мировые аналоги;
единственная в России правовая система, сертифицированная
компанией Microsoft и получившая логотип "Designed for Microsoft Windows
NT and Windows 95";
программа льготного обслуживания научных и учебных заведений.
Включение «Консультант Плюс» в программу обучения в вузах в соответствии
с рекомендацией Госкомвуза.
Структура информационного банка СПС «Консультант Плюс» в отличие
от многих других систем построена не по тематическим разделам, а по степени
информационного наполнения (по так называемому "принципу матрешки").
Таким образом, информационной банк системы меньшего размера обязательно
входит в информационный банк большего размера.
66
Кроме основных баз по законодательству в СПС «Консультант Плюс»
входит целый ряд вспомогательных баз по бухгалтерской, банковской,
инвестиционной деятельности. Особого внимания заслуживает база
«Консультант Арбитраж», посвященная судебной и арбитражной практике.
СПС «Консультант Плюс» обладает наиболее мощными поисковыми
возможностями, в особенности в отношении полнотекстового поиска.
5.2.5. Программный комплекс "Эталон"
Программный комплекс "Эталон" является одной из немногих систем,
разработанных государственным предприятием – Научным центром правовой
информации при Министерстве юстиции (НЦПИ).
Впервые "Эталон" появился на рынке в 1989 году, но, несмотря на это,
система не имела заметного коммерческого успеха, поскольку первоначально
фирма-разработчик не предпринимала значительных усилий для продвижения
системы на рынке. В настоящее время ситуация несколько изменилась.
Пользователям предлагается программный комплекс "Эталон" с выбором
информационного наполнения: либо общая база "Законодательство РФ
(включая ведомственные нормативные акты), СНГ и бывшего СССР", либо
одна или несколько специализированных подбаз.
В целом программная оболочка "Эталона" существенно уступает
описанным выше справочно-правовым системам как по функциональным
возможностям, так и по техническим требованиям, предъявляемым к
программе.
Однако к числу несомненных заслуг НЦПИ следует отнести глубокие
наработки в теории информационного обеспечения правоприменительной
деятельности, создание, пожалуй, самого большого информационного банка
нормативных документов, а также достаточно успешное обеспечение этими
документами государственных органов.
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Какие вы знаете справочно-правовые базы?
2. Какие вы знаете наиболее популярные юридические базы данных и
каково их назначение?
3. Как база ЮСИС позволяет формализовать процесс организации труда
профессионала?
4. Что представляет собой программный комплекс ЮСИС?
5. Что представляет собой информационно-поисковая система "Кодекс"?
6. Какие бывают справочно-правовые системы и каково их основное
назначение?
7. Что представляет собой Программный комплекс "Эталон"?
67
6. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ
6.1. Этапы проектирования
В базе данных отражается информация об определенной предметной
области. Предметной областью (ПО) называется часть реального мира,
представляющая интерес. В автоматизированных информационных системах
отражение предметной области представлено моделями данных нескольких
уровней [12].
Даталогическая модель базы данных (ДЛМ)
ДЛМ является моделью логического уровня и представляет собой
отображение логических связей между элементами данных безотносительно к
их содержанию и среде хранения. Эта модель строится в терминах
информационных единиц, допустимых в той конкретной СУБД, в среде
которой проектируется база данных. Этап создания ДЛМ называется
даталогическим проектированием. Описание логической структуры базы
данных на языке СУБД называется схемой.
Физическая модель БД
Используется для привязки даталогической модели к среде хранения. Эта
модель определяет используемые запоминающие устройства, способы
физической организации данных в среде хранения. Модель физического уровня
также строится с учетом возможностей, предоставляемых СУБД. Описание
физической структуры базы данных называется схемой хранения.
Соответствующий этап проектирования БД называется физическим
проектированием.
К числу работ, выполняемых на этапе физического проектирования,
относятся: выбор типа носителя, способа организации данных, методов
доступа, определение размера физического блока, управление размещением
данных на внешнем носителе, управление свободной памятью, определение
целесообразности сжатия данных и используемых методов сжатия, оценка
физической модели данных.
В настоящее время наблюдается тенденция к сокращению работ на
стадии физического проектирования. Иногда эти работы вообще бывают
скрыты от проектировщика.
Внешняя модель
Используется для описания логической структуры БД с точки зрения
конкретного пользователя. Описание внешней модели называется подсхемой.
В подсхемах задаются также допустимые режимы обработки, что служит
дополнительным механизмом защиты информации от разрушения.
Использование аппарата подсхем облегчает работу пользователя, так как
он должен знать структуру не всей базы данных, а только той ее части, которая
имеет непосредственное отношение к нему.
68
Предметная
область
Инфологическое
моделирование
Предварительная
логическая модель
Даталогическое
моделирование
Анализ
Физическое
проектирование
Анализ
Описание БД (схемы,
схемы хранения)
Проектирование
и описание подсхем
Рис. 6.1. Взаимосвязь этапов проектирования БД
Инфологическая модель предметной области
ИЛМ - это описание предметной области, выполненное без ориентации
на используемые в дальнейшем программные и технические средства.
Взаимосвязь этапов проектирования БД
Инфологическая модель предметной области строится первой.
Предварительная инфологическая модель строится еще на предпроектной
стадии и затем уточняется на более поздних стадиях проектирования. Затем на ее
основе строится даталогическая модель. Физическая и внешняя модели после
этого могут строиться в любой последовательности, в том числе и параллельно
(рис. 6.1).
При проектировании БД возможны два вида возвратов на предыдущие
уровни: первый обусловлен необходимостью пересмотра результата
проектирования, второй вызван необходимостью уточнения предыдущей
69
модели (обычно инфологической) с целью получения дополнительной
информации для проектирования или при выявлении противоречий в модели.
6.2. Инфологическое моделирование
Проектирование БД начинается с предварительной структуризации
предметной области: объекты реального мира подвергаются классификации,
фиксируется совокупность подлежащих отображению в БД типов объектов.
Для каждого типа объектов фиксируется совокупность свойств, посредством
которых будут описываться конкретные объекты этого типа в БД, виды
отношений (взаимосвязей) между этими объектами. Затем решаются вопросы о
том, какая информация об этих объектах должна быть представлена в БД и как
ее представить с помощью данных.
Сущность инфологического подхода к проектированию информационных
систем заключается в установлении соответствия между состоянием
предметной области, его восприятием и представлением в базе данных.
Основные требования к ИЛМ:
- адекватное отображение предметной области;
- непротиворечивость;
- отсутствие неоднозначности трактовки;
- возможность легкой расширяемости, обеспечивающая ввод данных без
изменения ранее определенных;
- обеспечение возможности композиции и декомпозиции модели.
ИЛМ содержит необходимую и достаточную информацию для
дальнейшего проектирования автоматизированной системы обработки
информации.
6.2.1. Компоненты инфологической модели
Модель «сущность — связь»
Модель типа «сущность-связь» - это неформальная модель предметной
области, которая используется на этапе инфологического проектирования базы
данных и позволяет моделировать объекты предметной области, а также
взаимоотношения объектов. Основное ее назначение - семантическое описание
предметной области и представление информации для обоснования выбора
видов моделей и структур данных, которые в дальнейшем будут использованы
в системе.
При построении модели типа «сущность-связь» используется три
основных конструктивных элемента: сущность, атрибут и связь. Информация о
проекте объединяется с помощью графических диаграмм.
Сущность - это собирательное понятие, некоторая абстракция реально
существующего объекта, процесса или явления, о котором необходимо хранить
информацию в системе.
В модели используются также понятия «тип сущности» и «экземпляр
сущности». Тип сущности определяет набор однородных объектов, а
70
экземпляр сущности - конкретный объект в наборе. Каждый рассматриваемый
в модели тип сущности должен быть поименован.
Атрибут - это поименованная характеристика сущности, которая
принимает значения из некоторого множества значений. Основное назначение
атрибута - описание свойства сущности, а также идентификация экземпляров
сущностей.
Связи выступают в модели в качестве средства, с помощью которого
представляются отношения между сущностями, имеющими место в предметной
области. Тип связи рассматривается между типами сущностей, а конкретный
экземпляр связи рассматриваемого типа существует между конкретными
экземплярами рассматриваемых типов сущностей.
Наиболее часто встречаются бинарные связи.
6.2.2. Классификация бинарных связей
1. Связь «один к одному» (1:1) - такой тип связи между типами сущностей
А и В, когда каждому экземпляру сущности А соответствует один и только
один экземпляр сущности В и наоборот. Идентификация экземпляров
сущностей уникальна в обоих направлениях для отображений.
Пример: квартира
ответственный квартиросъемщик.
2. Связь «один ко многим» (1:М) - одному экземпляру сущности А может
соответствовать 0, 1 или несколько экземпляров сущности В, однако каждому
экземпляру сущности В соответствует только один экземпляр сущности А.
Идентификация экземпляров при отображении 1: М уникальна только в
направлении от В к А.
Пример: район
город.
3. Связь «многие к Одному» (М:1) является обратной связи 1: М.
Пример: район
город.
4. Связь «многие ко многим» (М:М) - каждому экземпляру сущности А
может соответствовать 0, 1 или несколько экземпляров сущности В и наоборот.
Идентификация экземпляров сущностей неуникальна в обоих направлениях.
Пример: студент
дисциплина.
В некоторых случаях целесообразно рассматривать однонаправленную связь от
сущности А к сущности В. В зависимости от количественных характеристик
отображения различают простую и многозначную связь.
При простой однонаправленной связи от сущности А к сущности В
одному и тому же экземпляру сущности А соответствует один и тот же
экземпляр сущности В. При этом обратная связь не определена.
Идентификация экземпляров сущности В экземплярами сущности А уникальна.
Пример: отдел
служащий.
При многозначной однонаправленной связи от сущности А к сущности В
одному и тому же экземпляру сущности А соответствует 0, 1 или несколько
экземпляров сущности В. При этом обратная связь не определена.
71
Идентификация экземпляров сущности В экземплярами сущности А не
уникальна.
Пример: пациент
заболевание.
Информацию о проекте оформляют составлением спецификаций по
сущностям, атрибутам и отношениям с использованием графических диаграмм, для
этого обозначают:
типы сущностей - прямоугольниками;
атрибуты - овалами, соединяя их с соответствующими типами сущностей
ненаправленными ребрами; идентифицирующие атрибуты подчеркиваются;
связи (отношения) - ромбами, соединяя их с соответствующими типами
сущностей ненаправленными ребрами, за исключением бинарных связей,
которые представляются направленными ребрами.
При моделировании используются следующие общие правила:
- используются только три типа конструктивных элементов - сущность,
атрибут, связь;
- в отдельном проектном представлении каждый компонент информации
моделируется только одним конструктивным элементом, т. е. необходимо
избегать избыточности в использовании конструктивных элементов.
При моделировании предметной области проектировщик разбивает ее на
ряд локальных областей, моделирует каждое локальное представление, а затем
их объединяет.
6.2.3. Моделирование локальных представлений
Моделирование локальных проектных представлений завершается
построением модели локального представления. Для удобства проектирования
в отдельном локальном представлении желательно использовать шесть-семь
типов сущностей. Чаще всего локальное представление соответствует
отдельному внешнему приложению, например отдельной функциональной
задаче либо отдельному пользователю.
Для каждого локального представления необходимо сформулировать
сущности, требуемые для его описания, т. е. указать типы объектов предметной
области, о которых в системе должна накапливаться информация.
В отдельных случаях это сделать сложно, так как некоторая порция
информации может быть представлена любым из типов конструктивных
элементов: сущность, атрибут или связь. В этих случаях рекомендуется
проработать несколько вариантов моделей локального представления и
отобрать более гибкий с точки зрения представления инфо рмации, т. е.
позволяющий представлять не только всю порцию некоторой информации, но и
ее отдельные фрагменты.
Пример. Пусть в некотором локальном представлении выполняется
описание поставок товаров на склад. Предполагается, что в одной поставке
может участвовать только один поставщик, поставляя только один вид товара.
При этом поставщик может участвовать в нескольких поставках [29].
72
Для описания воспользуемся только двумя основными конструкциями сущность и атрибут. Графическая диаграмма локального предс тавления
показана на рис. 6.2.
ИНДЕКС
ПОСТАВКИ
ИНДЕКС
ПОСТАВЩИКА
АДРЕС
ПОСТАВЩИКА
ИНДЕКС
ТОВАРА
НАЗВАНИЕ
ТОВАРА
КОЛИЧЕСТВО
ПОСТАВЛЕННОГО
ТОВАРА
ЦЕНА ЕДИНИЦЫ
ТОВАРА
ПОСТАВКА
ШИФР СКЛАДА
ДАТА ПОСТАВКИ
Рис. 6.2. Исходная графическая диаграмма локального представления
Такая модель обладает определенными недостатками. С ее помощью
нельзя представить порцию информации об отдельном поставщике, который не
выполняет поставок в настоящее время. Для этого необходимо ввести в модель
сущность ПОСТАВЩИК, назначить ей соответствующие атрибуты, связать с
сущностью ПОСТАВКА, если это необходимо, и удалить избыточные
элементы (рис. 6.3).
При таком представлении всегда можно определить, какой конкретно
поставщик выполнил поставку, используя для этих целей связь ПОСТАВЛЯЕТ
между сущностями ПОСТАВЩИК и ПОСТАВКА, т.е. в информационном
плане данная модель сохраняет все возможности предыдущей. При этом она
более богата с точки зрения информационного представления, так как дает
информацию и об отдельных поставщиках независимо от того, выполняли они
поставку товаров или нет.
Однако полученный вариант не представляет информацию об отдельных
товарах, если они отсутствуют в поставках. Чтобы такие порции информации
можно было представлять, необходимо ввести в модель сущность ТОВАР и
выполнить аналогичные процедуры построения, как и для сущности
ПОСТАВЩИК (рис. 6.4).
73
ИНДЕКС
ПОСТАВЩИКА
АДРЕС
ПОСТАВЩИКА
ПОСТАВЩИК
ДАТА
ПОСТАВКИ
ПОСТАВЛЯЕТ
ШИФР
СКЛАДА
ПОСТАВКА
ИНДЕКС
ПОСТАВКИ
ИНДЕКС
ТОВАРА
ЦЕНА
ЕДИНИЦЫ
ТОВАРА
НАЗВАНИЕ
ТОВАРА
КОЛИЧЕСТВО
ПОСТАВЛЕННО
ГО ТОВАРА
Рис. 6.3. Графическая диаграмма с введением в модель сущности ПОСТАВЩИК
ИНДЕКС
ПОСТАВЩИКА
АДРЕС
ПОСТАВЩИКА
ИНДЕКС
ТОВАРА
НАЗВАНИЕ
ТОВАРА
ПОСТАВЩИК
ТОВАР
ПОСТАВЛЯЕТ
ПОСТАВКА
ИНДЕКС
ПОСТАВКИ
КОЛИЧЕСТВО
ПОСТАВЛЕННО
ГО ТОВАРА
ЦЕНА
ЕДИНИЦ
Ы
ТОВАРА
ПОСТАВЛЕН
ШИФР
СКЛАДА
ДАТА
ПОСТАВКИ
Рис. 6.4. Графическая диаграмма с введением в модель сущности ТОВАР
74
Полученный вариант не позволяет представить информацию «какие
товары может поставлять отдельный поставщик» и «какие поставщики могут
поставлять данный товар». Для реализации в модели подобной информации
необходимо организовать соответствующие связи между сущностями
ПОСТАВЩИК и ТОВАР (рис. 6.5).
ИНДЕКС
ПОСТАВЩИКА
АДРЕС
ПОСТАВЩИКА
ИНДЕКС
ТОВАРА
НАЗВАНИ
ТОВАРА
ПОСТАВЩИК
ЦЕНА
ЕДИНИЦЫ
ТОВАРА
МОЖЕТ
ПОСТАВЛЯТЬ
ТОВАР
ПОСТАВЛЯЕТ
МОЖЕТБЫТЬ
ПОСТАВЛЕН
ПОСТАВКА
ИНДЕКС
ПОСТАВКИ
КОЛИЧЕСТВО
ПОСТАВЛЕННОГ
О ТОВАРА
ПОСТАВЛЕН
ШИФР
СКЛАДА
ДАТА
ПОСТАВКИ
Рис. 6.5. Графическая диаграмма с введением в модель связей
МОЖЕТ ПОСТАВЛЯТЬ и МОЖЕТ БЫТЬ ПОСТАВЛЕН
Для локального представления, рассмотренного в примере, выбираем
заключительный вариант модели, поскольку он более гибкий для
представления информации: позволяет представлять информацию о поставках
и ее отдельных фрагментах, поставщиках, товарах, возможностях поставщиков,
распределении поставщиков по видам товаров. Следовательно, база данных,
реализующая это представление, окажется более гибкой в обработке данных и
будет обладать большими возможностями по обработке произвольных
запросов. Следовательно, для данного локального представления целесообразно
сформулировать такие сущности, как ПОСТАВКА, ПОСТАВЩИК, TOBАР.
Каждой выбранной сущности должно быть присвоено четкое
наименование, отражающее смысловое содержание вводимого понятия. Общее
количество сформулированных сущностей в отдельном локальном
представлении должно быть ограниченным.
75
Для каждой сущности необходимо указать идентификатор, служащий для
однозначного
распознавания
экземпляров
сущности. В качестве
идентификатора служит один атрибут или совокупность из нескольких
атрибутов, в этом случае идентифицирующий атрибут является составным
атрибутом, набор значений которого уникален, т. е. значения
идентифицирующего атрибута находятся во взаимно однозначном соответствии
с экземплярами сущности.
Одним из этапов моделирования локальных представлений является
спецификация связей. Выявляются все зависимости между сущностями и
атрибутами и определяется, какие связи необходимые, а какие избыточные. В
зависимостях «атрибут-атрибут» целесообразно стремиться к случаю, когда
наблюдаются
только
зависимости
описательных
атрибутов
от
идентифицирующего, других зависимостей нет.
Моделирование локального представления заканчивается графическим
оформлением всех выявленных сущностей, связей между ними и атрибутов и
составлением всех перечисленных выше спецификаций.
6.2.4. Объединение моделей локальных представлений
При объединении моделей локальных представлений проектировщик
может формировать конструкции, являющиеся производными по отношению к
использованным в локальных представлениях. Вводимые производные
конструкции должны обеспечивать непротиворечивое представление данных.
При объединении представлений используются три основополагающие
концепции: идентичность, агрегация и обобщение.
Два или более элементов модели идентичны, если имеют одинаковое
семантическое (смысловое) значение.
Агрегация позволяет рассматривать связь между элементами модели как
новый элемент.
При объединении представлений агрегация встречается в следующих
трех формах:
1. В одном представлении агрегатный объект определен как единое целое,
а во втором - рассматриваются его составные части.
2. Агрегатный объект как единое целое не определен ни в одном из
представлений, но в обоих представлениях рассматриваются его различные
составные части.
3. Один и тот же агрегатный объект рассматривается в обоих
представлениях, но составляющие различаются.
Пример. Объединению подлежат два представления (рис. 6.6, а, б). С
использованием агрегации можно объединить эти представления (рис. 6.6, в).
Обобщением называется абстракция данных, позволяющая трактовать
класс различных подобных типов объектов как один поименованный
обобщенный тип объекта. В обобщении подчеркивается общая природа объектов.
76
В случае многоуровневой иерархии обобщений структура обобщения
образует родовую иерархию, что приводит к появлению понятий родовой и
видовой сущности. При построении обобщений вводятся смысловые категории
(обычно категории типа или роли), относительно которых формируются
родовые иерархии. Пример обобщения приведен на рис. 6.7.
В процессе объединения выявляются противоречия между отдельными
локальными представлениями, вызванные некорректностью требований,
неполнотой спецификаций, наличием возможных ошибок, различием
требований в отдельных приложениях.
а)
Индекс
Цена
Гарнитур
Имеет
в составе
стулья
Имеет
в составе
столы
Имеет
в составе
шкафы
Стол
Шкаф
Стул
Индекс - СТ
Цена - СТ
Индекс - Ш
Индекс - С
б)
Название
Цена - Ш
Цена - С
Дата
Гарантийный
изготовления
срок
Гарнитур
Индекс-СТ
Имеет
в составе
стулья
Имеет
в составе
столы
1
Имеет
в составе
полки
Стул
Стол
Полка
Количество-СТ
Индекс-П
Индекс-С
Количество-П
Количество-С
Рис. 6.6. Пример объединения локальных множеств с использованием агрегации
Процесс объединения носит итеративный характер и продолжается до тех
пор, пока не будут интегрированы все представления, согласованы и ус транены
все противоречия. После завершения объединения результаты проектирования,
77
представляющие собой концептуальную инфологическую модель ПО,
оформленную в виде графических диаграмм и соответствующих спецификаций,
поступают на этап даталогического проектирования БД. Сформированные
спецификации вводятся в словарь данных системы.
в)
Индекс
Название
Цена
Гарнитур
Дата
Гарантийный
изготовления
срок
Индекс-СТ
Имеет в составе
стулья
Стул
Цена-СТ
Количество-СТ
Индекс-С
Имеет в составе
столы
Стол
Цена-С
Количество-С
Индекс-Ш
Имеет в составе
шкафы
Шкаф
Цена-Ш
Количество-Ш
Индекс-П
Имеет в составе
полки
Полка
Цена-П
Количество-П
Рис. 6.6 (окончание). Пример объединения локальных множеств с использованием агрегации
Индекс
Название
Дата изготовления
Цена
Гарантийный срок
Гарнитур
Имеет
в составе
Индекс - К
Наименование
Компонент
Цена - К
Количество
Рис. 6.7. Пример использования обобщения
78
6.3. Даталогическое проектирование
Любая СУБД оперирует с допустимыми для нее логическими единицами
данных, а также допускает использование определенных правил композ иции
логических структур более высокого уровня из составляющих
информационных единиц более низкого уровня. Кроме того, многие СУБД
накладывают количественные и иные ограничения на структуру базы данных.
Поэтому прежде, чем приступить к построению даталогической модели,
необходимо детально изучить особенности СУБД, определить факторы, влияющие на выбор проектного решения, ознакомиться с существующими
методиками проектирования, а также провести анализ имеющихся средств
автоматизации проектирования, возможности и целесообразности их
использования.
Хотя даталогическое проектирование является проектированием
логической структуры базы данных, на него оказывают влияние возможности
физической организации данных, предоставляемые конкретной СУБД. Поэтому
знание особенностей физической организации данных является полезным при
проектировании логической структуры.
Логическая структура базы данных, а также сама заполненная данными
база данных являются отображением реальной предметной области. Поэтому
на выбор проектных решений самое непосредственное влияние оказывает
специфика отображаемой предметной области, отраженная в инфологической
модели.
Конечным результатом даталогического проектирования является
описание логической структуры базы данных на ЯОД. Спроектировать
логическую структуру базы данных означает определить все информационные
единицы и связи между ними, задать их имена; если для информационных
единиц возможно использование разных типов, то необходимо определить их
тип. Следует также задать некоторые количественные характеристики,
например длину поля.
Каждый тип модели данных и каждая разновидность модели,
поддерживаемая конкретной СУБД, имеют свои специфические особенности.
Вместе с тем имеется много общего во всех структурированных моделях
данных и принципах проектирования БД в их среде. Все это дает возможность
использовать единый методологический подход к проектированию структуры
базы данных (что отражается в ИЛМ).
Процесс проектирования БД предусматривает предварительную
классификацию объектов предметной области, систематизированное
представление информации об объектах и связях между ними. На начальных
этапах проектирования должен быть определен состав БД.
При проектировании логической структуры БД осуществляется
преобразование исходной инфологической модели в модель данных,
поддерживаемую конкретной СУБД, и проверка адекватности полученной
даталогической модели отображаемой предметной области. Для любой
79
предметной области существует множество вариантов проектных решений ее
отображения в даталогической модели. Методика проектирования должна
обеспечивать выбор наиболее подходящего проектного решения. Минимальная
логическая единица данных семантически для всех СУБД одинакова и
соответствует либо идентификатору объекта, либо свойству объекта или
процесса.
Связи между сущностями предметной области, отраженные в
инфологической модели, могут отображаться в даталогической модели, либо
посредством
совместного
расположения
соответствующих
им
информационных элементов, либо путем объявления связи между ними. Связь
может передаваться как на внутризаписном, так и на межзаписном уровне.
Не все виды связей, существующие в предметной области, могут быть
непосредственно отображены в конкретной даталогической модели. Так,
многие СУБД не поддерживают непосредственно отношение М:М между
элементами. В этом случае в даталогическую модель вводится дополнительный
вспомогательный элемент, отображающий эту связь.
При проектировании логической структуры БД основное значение имеет
специфика отображаемой предметной области. Однако и характер обработки
информации оказывает влияние на принимаемое проектное решение.
Например, рекомендуется хранить вместе информацию, часто обрабатываемую
совместно и, наоборот, разделять по разным файлам информацию, не
использующуюся одновременно. Информацию, используемую часто, и
информацию, частота обращения к которой мала, также следует хранить в
разных файлах, причем последнюю может оказаться выгодным вынести в
архивные файлы, а не поддерживать в составе БД.
При переходе от инфологической модели к даталогической следует иметь
в виду, что инфологическая модель включает в себя всю информацию о
предметной области, необходимую и достаточную для проектирования БД. Это
не означает, что все сущности, зафиксированные в ИЛМ, должны в явном виде
отражаться в даталогической модели. Прежде чем строить даталогическую
модель, необходимо решить, какая информация будет храниться в базе данных.
Например, в инфологической модели должны быть отражены вычисляемые
показатели, но вовсе не обязательно, что они должны храниться в базе данных.
Существуют разные подходы к определению состава показателей,
которые должны храниться в базе данных. Согласно одному из них в БД
должны храниться только исходные показатели, все производные показатели
должны быть получены расчетным путем в момент реализации запроса (этот
подход иногда называют принципом синтезирования, имея в виду возможность
«синтезировать» требуемые показатели из хранимых в информационной базе
данных).
Такой подход имеет очевидные достоинства: 1) простота и однозначность
в принятии решения «что хранить»; 2) отсутствие неявного дублирования
информации со всеми вытекающими из этого последствиями (меньше объем
80
памяти, чем при хранении как исходных, так и производных показателей,
проще проблемы контроля целостности данных); 3) потенциальная
возможность получить любой расчетный показатель, а не только те, которые
хранятся в БД.
При отображении объекта в файл базы данных идентификатор объекта
будет являться полем этого файла, причем в большинстве случаев ключевым
полем. Однако в некоторых случаях появляется необходимость введения
искусственных идентификаторов, или, как их еще называют, кодов. Такими
случаями являются следующие.
1. В предметной области может наблюдаться синонимия, т.е. может
случиться, что естественный идентификатор объекта не обладает свойством
уникальности. Например, среди сотрудников предприятия могут быть
однофамильцы. В этом случае для обеспечения однозначной идентификации
объектов ПО в информационной системе необходимо использовать
искусственные коды.
2. Если объект участвует во многих связях, то для их отображения
создается несколько файлов, в каждом из которых повторяется идентификатор
объекта. Для того чтобы не использовать во всех файлах длинный естественный
идентификатор объекта, можно ввести и использовать более короткий код. Это
не только сэкономит память, но и сократит трудоемкость ввода информации.
3. Если естественный идентификатор может изменяться со временем
(например, фамилия), то это может вызвать много проблем, если наряду с
таким «динамическим» идентификатором не использовать «статический»
искусственный идентификатор.
Когда присваиваются идентификаторы каким-либо объектам, то
желательно, чтобы эти идентификаторы были постоянными.
Все шаги проектирования даталогической модели выполняются
итеративно. Причем вероятны итерации не только внутри стадии
даталогического проектирования, но и с «захватом» других стадий
проектирования БД.
6.4. Проектирование реляционных баз данных
Для реляционной базы данных проектирование логической структуры
заключается в том, чтобы разбить всю информацию по файлам (отношениям), а
также определить состав полей (атрибутов) для каждого из этих файлов.
Существуют разные способы проектирования логической структуры
реляционных баз данных. Среди них есть и строгие математические методы
(нормализация
отношений).
Первоначально
рассмотрим
способ
проектирования, основанный на анализе инфологической модели и переходе от
нее к реляционным отношениям. Этот метод является достаточно простым и
наглядным и в то же время дает хорошие результаты [12].
Для перехода от инфологической модели к реляционной можно
воспользоваться следующими рекомендациями.
81
1. Для каждого простого объекта и его единичных свойств строится
отношение, атрибутами которого являются идентификаторы объекта и
реквизиты, соответствующие каждому из единичных свойств.
2. Если у объекта имеются множественные свойства, то каждому из них
ставится в соответствие отдельное отношение. Ключом этого отношения будет
идентификатор соответствующего объекта, а неключевым атрибутом –
реквизит, отражающий данное свойство.
3. Если между объектом и его свойством имеется условная связь, то при
отображении в реляционную модель возможны следующие варианты:
а) если многие из объектов обладают рассматриваемым свойством, то его
можно хранить в базе данных так же, как и обычное свойство;
б) если только незначительное число объектов обладает указанным
свойством, то для многих записей в файле базы данных значение
соответствующего поля будет пустым при использовании предыдущего
решения. Для устранения этого недостатка можно выделить отдельное
отношение, которое будет включать идентификатор объекта и атрибут,
соответствующий рассматриваемому свойству. Это отношение будет содержать
столько строк, сколько объектов имеет рассматриваемое свойство. Однако это
решение тоже имеет недостатки и применяется сравнительно редко.
4. Наличие между объектами связи типа 1:1 является довольно редкой
ситуацией в реальной жизни. Если связь между объектами 1:1 и класс
принадлежности обоих сущностей являются обязательными, то для
отображения обоих объектов и связи между ними можно использовать один
файл. Такое решение потребует меньше всего памяти для своей реализации.
Однако таким решением не следует злоупотреблять. Если случится, что для
каждого из этих объектов в дальнейшем потребуется отразить какие-то свои
связи или в запросах часто будет требоваться информация отдельно по
каждому из объектов, то это может усложнить работу.
Если для каждого из этих объектов сохраняются отдельные отношения,
то информацию о связях между ними можно отразить, включив в одно из
отношений идентификатор связанного объекта из другого отношения. Причем
если класс принадлежности обоих сущностей является обязательным, то это
можно сделать в любом из отношений. Если класс членства одного из объектов
является необязательным, то идентификатор сущности, для которой класс
принадлежности является необязательным, добавляется в отношение,
соответствующее тому объекту, для которого класс принадлежности
обязателен.
Если степень связи между объектами 1:1 и класс принадлежности каждой из
них являются необязательными, то следует использовать три отношения: по
одному для каждой сущности и одно для отображения связи между ними.
Если связь 1:1 реализована на одном и том же множестве объектов, то
можно использовать одно отношение.
82
5. Если между объектами предметной области имеется связь 1:М и класс
принадлежности n-связной сущности является обязательным, то можно
использовать два отношения, по одному для каждой сущности. В отношение,
соответствующее 1-связной сущности, при этом надо дополнительно добавить
идентификатор связанного с ней объекта.
Если
класс
принадлежности
n-связной
сущности
является
необязательным, то для отображения связи надо создать третье отношение,
которое будет содержать ключи каждой из связанных сущностей.
6. Если между объектами предметной области имеется связь М:N, то для
хранения такой информации потребуются три отношения: по одному для
каждой сущности и одно для отображения связи между ними. Последнее
отношение будет содержать идентификаторы связанных объектов.
7. Каждому агрегированному объекту, имеющему место в предметной
области, в даталогической реляционной модели будет соответствовать
отдельный файл базы данных (отношение). Атрибутами этого отношения будут
идентификаторы всех объектов, «задействованных» в данном агрегированном
объекте, а также реквизиты, соответствующие свойствам этого агрегированного
объекта. Объединить информацию о нескольких агрегированных объектах в
одно реляционное отношение можно только в том случае, если те объекты, с
которыми связан каждый из них, полностью совпадают.
8. При отображении обобщенных объектов могут быть приняты разные
решения. Во-первых, всему обобщенному объекту может быть поставлен в
соответствие один файл базы данных. Другой крайней ситуацией является
решение, при котором каждой из категорий объектов нижнего уровня ставится
в соответствие отдельное отношение. В первом случае атрибутами отношения
будут все единичные свойства, присущие объектам хотя бы одной категории,
плюс идентификатор объекта. Во втором случае каждое отношение будет
включать в себя идентификатор объекта, те свойства, которые присущи
объектам данной категории, а также свойства, которыми обладают родовые
объекты, стоящие выше его по иерархии. Другими словами, для «видовых»
объектов наблюдается наследование свойств «родовых» объектов.
Кроме этих двух «крайних» решений возможны и комбинированные
варианты. Выбор конкретного решения будет зависеть от многих факторов, в
том числе от того, насколько часто информация о разных категориях объектов
обрабатывается совместно, как велико различие в «видовых» свойствах и
некоторых других факторах.
9. Наличие связи «целое-часть» также может быть отображено в
даталогической модели по-разному. Само это отношение может качественно
различаться для разных ситуаций. Так, если речь идет о составе изделий, то
между «ИЗДЕЛИЕМ» и «ДЕТАЛЬЮ» имеется связь типа М:М, так как одна и
та же деталь может входить в разные изделия и, наоборот, в изделие входят разные детали. Состав изделия обычно является сложным, и отражать его в явном
виде в структуре базы данных нежелательно, а иногда и невозможно. Кроме
83
того, рассматриваемая связь реализована на однородном множестве объектов. В
этом случае для отображения связи «целое-часть» можно воспользоваться
двумя файлами базы данных. Первый из них будет хранить информацию о
самих объектах, а второй – информацию о связи между ними, а также
дополнительную информацию, характеризующую эту связь. Для состава
изделия это могут быть поля «что входит», «куда входит» и «количес тво».
Отношение «целое-часть» может отражать, например, структуру какой-то
организации. В этом случае ему скорее всего будет соответствовать связь типа
1:М, и для его отображения в даталогической модели можно использ овать
рекомендации, данные в п. 5 для соответствующего случая.
В рассматриваемой ситуации также можно воспользоваться неявным
выделением уровней, но такой прием используется здесь редко.
Некоторые реляционные СУБД требуют, чтобы при описании базы
данных были указаны ключи отношения. Причем если отношение имеет
несколько вероятных ключей, то один из них должен быть задан в качестве
первичного ключа, а остальные описаны как уникальные поля. Вероятными
ключами отношений, соответствующих простым или обобщенным объектам,
будут
идентификаторы
соответствующих
объектов.
Если
таких
идентификаторов несколько, то в качестве первичного ключа обычно
выбирается короткий код объекта. Для отношений, соответствующих
агрегированным объектам, ключ будет составной. В большинстве случаев им
будет являться конкатенация (соединение) идентификаторов объектов,
«участвующих» в этом агрегированном объекте. Для отношений, отражающих
связь М:М между объектами, ключ будет также составным и будет включать
идентификаторы связанных объектов. Для отношений, отображающих
множественные свойства объекта, составной ключ будет содержать
идентификатор объекта и поле, соответствующее множественному полю.
Реляционная база данных, полученная в результате использования
предложенной методики проектирования, будет нормализованной и
автоматически находится в четвертой нормальной форме.
Как известно, вся предметная область может быть представлена в виде
одного универсального отношения. Недостатки такого способа хранения
известны, и нормализация отношений служит устранению этих недостатков.
6.5. Нормализация отношений
Задача группировки атрибутов в отношения при условии, что набор
возможных отношений заранее не фиксирован, допускает большое количес тво
разных вариантов и приводит к проблеме выбора рационального варианта из
множества альтернативных вариантов схемы отношения.
Рациональные варианты группировки атрибутов в отношении должны
отвечать следующим требованиям:
1) выбранные для отношений первичные ключи должны быть
минимальными;
84
2) выбранный состав отношений базы должен быть минимальным
(отличаться минимальной избыточностью атрибутов);
3) при выполнении операций включения, удаления и модификации
данных в базе не должно быть трудностей (аномалий);
4) перестройка набора отношений при введении новых типов данных
должна быть минимальной;
5) разброс времени ответа на различные запросы к БД должен быть
небольшим.
Для решения перечисленных вопросов выполняется нормализация
исходных схем отношений проекта БД.
В теории реляционных баз данных обычно выделяется следующая
последовательность нормальных форм [16]:
• первая нормальная форма (1NF);
• вторая нормальная форма (2NF);
• третья нормальная форма (3NF);
• нормальная форма Бойса-Кодда (BCNF);
• четвертая нормальная форма (4NF);
• пятая нормальная форма или нормальная форма проекции-соединения
(5NF или PJ/NF).
Основные свойства нормальных форм:
• каждая следующая нормальная форма в некотором смысле лучше
предыдущей;
• при переходе к следующей нормальной форме свойства предыдущих
нормальных свойств сохраняются.
Нормализация отношений заключается в декомпозиции отношения,
находящегося в предыдущей нормальной форме, в два или более отношения,
удовлетворяющих требованиям следующей нормальной формы.
Методы нормализации базируются на использовании понятий
функциональной и многозначной зависимости.
Определение 1. Функциональная зависимость
В отношении R атрибут Y функционально зависит от атрибута X (X и Y
могут быть составными) в том и только в том случае, если каждому значению X
соответствует в точности одно значение Y: R.X R.Y.
Определение 2. Полная функциональная зависимость
Функциональная зависимость R.X R.Y называется полной, если атрибут
Y не зависит функционально от любого точного подмножества X.
Определение 3. Транзитивная функциональная зависимость
Функциональная зависимость R.X R.Y называется транзитивной, если
существует такой атрибут Z, что имеются функциональные зависимости
R.X R.Z и R.Z R.Y и отсутствует функциональная зависимость R.Z R.X.
85
Определение 4. Неключевой атрибут
Неключевым атрибутом называется любой атрибут отношения, не
входящий в состав первичного ключа.
Определение 5. Взаимно независимые атрибуты
Два или более атрибута взаимно независимы, если ни один из этих
атрибутов не является функционально зависимым от других.
Определение 6. Детерминант
Детерминант – любой атрибут, от которого полностью функционально
зависит некоторый другой атрибут.
Определение 7. Многозначные зависимости
В отношении R(A,B,C) существует многозначная зависимость R.A R.B в том
и только в том случае, если множество значений B, соответствующее паре значений A
и C, зависит только от A и не зависит от С.
Легко показать, что в общем случае в отношении R(A,B,C) существует
многозначная зависимость R.A R.B в том и только в том случае, когда
существует многозначная зависимость R.A R.C.
Определение 8. Зависимость соединения
Отношение R(X,Y,...,Z) удовлетворяет зависимости соединения
*(X,Y,...,Z) в том и только в том случае, когда R восстанавливается без потерь
путем соединения своих проекций на X, Y, ..., Z.
Первая нормальная форма (1NF)
Схема отношения R находится в первой нормальной форме тогда и
только тогда, когда все входящие в нее атрибуты являются атомарными.
Для работы языков запросов достаточно, чтобы отношение находилось в
1NF.
Вторая нормальная форма (2NF)
Рассмотрим следующий пример схемы отношения:
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ
(СОТР_НОМЕР,
СОТР_ЗАРП,
ОТД_НОМЕР,
СОТР_ЗАДАН)
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР
СОТР_ЗАРП
СОТР_НОМЕР
ОТД_НОМЕР
ОТД_НОМЕР
СОТР_ЗАРП
СОТР_НОМЕР, ПРО_НОМЕР
СОТР_ЗАДАН
86
ПРО_НОМЕР,
Как видно, хотя первичным ключом является составной атрибут
СОТР_НОМЕР, ПРО_НОМЕР, атрибуты СОТР_ЗАРП и ОТД_НОМЕР
функционально зависят от части первичного ключа, атрибута СОТР_НОМЕР. В
результате мы не сможем вставить в отношение СОТРУДНИКИ-ОТДЕЛЫПРОЕКТЫ кортеж, описывающий сотрудника, который еще не выполняет
никакого проекта (первичный ключ не может содержать неопределенное
значение). При удалении кортежа мы не только разрушаем связь данного
сотрудника с данным проектом, но утрачиваем информацию о том, что о н
работает в некотором отделе. При переводе сотрудника в другой отдел мы
будем вынуждены модифицировать все кортежи, описывающие этого
сотрудника, или получим несогласованный результат. Такие неприятные
явления называются аномалиями схемы отношения. Они устраняются путем
нормализации.
Отношение R находится во второй нормальной форме (2NF) в том и
только в том случае, когда находится в 1NF и каждый неключевой атрибут
полностью зависит от первичного ключа.
Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИПРОЕКТЫ:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР
СОТР_ЗАРП
СОТР_НОМЕР
ОТД_НОМЕР
ОТД_НОМЕР
СОТР_ЗАРП
СОТРУДНИКИ-ПРОЕКТЫ
(СОТР_НОМЕР,
ПРО_НОМЕР,
СОТР_ЗАДАН)
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР
CОТР_ЗАДАН
Каждое из этих двух отношений находится в 2NF, и в них устранены
отмеченные выше аномалии (легко проверить, что все указанные операции
выполняются без проблем).
Третья нормальная форма (3NF)
Рассмотрим еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ, находящееся в
2NF. Заметим, что функциональная зависимость СОТР_НОМЕР
СОТР_ЗАРП является транзитивной; она является следствием функциональных
зависимостей СОТР_НОМЕР
ОТД_НОМЕР и ОТД_НОМЕР
СОТР_ЗАРП. Другими словами, заработная плата сотрудника на самом деле
87
является характеристикой не сотрудника, а отдела, в котором он работает (это
не очень естественное предположение, но достаточное для примера).
В результате мы не сможем занести в базу данных информацию,
характеризующую заработную плату отдела, до тех пор, пока в этом отделе не
появится хотя бы один сотрудник (первичный ключ не может содержать
неопределенное значение). При удалении кортежа, описывающего последнего
сотрудника данного отдела, мы лишимся информации о заработной плате
отдела. Чтобы согласованным образом изменить заработную плату отдела, мы
будем вынуждены предварительно найти все кортежи, описывающие
сотрудников этого отдела. То есть в отношении СОТРУДНИКИ-ОТДЕЛЫ попрежнему существуют аномалии. Их можно устранить путем дальнейшей
нормализации.
Отношение R находится в третьей нормальной форме (3NF) в том и
только в том случае, если находится в 2NF и каждый неключевой атрибут
нетранзитивно зависит от первичного ключа.
Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ в два
отношения СОТРУДНИКИ и ОТДЕЛЫ:
СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР
ОТД_НОМЕР
ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП)
Первичный ключ:
ОТД_НОМЕР
Функциональные зависимости:
ОТД_НОМЕР
СОТР_ЗАРП
Каждое из этих двух отношений находится в 3NF и свободно от
отмеченных аномалий.
На практике третья нормальная форма схем отношений достаточна в
большинстве случаев, и приведением к третьей нормальной форме процесс
проектирования реляционной базы данных обычно заканчивается. Однако
иногда полезно продолжить процесс нормализации.
Нормальная форма Бойса-Кодда (BKNF)
Рассмотрим следующий пример схемы отношения:
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ИМЯ, ПРО_НОМЕР,
СОТР_ЗАДАН)
Возможные ключи:
СОТР_НОМЕР, ПРО_НОМЕР
СОТР_ИМЯ, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР
CОТР_ИМЯ
88
СОТР_НОМЕР
ПРО_НОМЕР
СОТР_ИМЯ
CОТР_НОМЕР
СОТР_ИМЯ
ПРО_НОМЕР
СОТР_НОМЕР, ПРО_НОМЕР
CОТР_ЗАДАН
СОТР_ИМЯ, ПРО_НОМЕР
CОТР_ЗАДАН
В этом примере мы предполагаем, что личность сотрудника полностью
определяется как его номером, так и именем (это снова не очень жизненное
предположение, но достаточное для примера).
В соответствии с определением 7 отношение СОТРУДНИКИ-ПРОЕКТЫ
находится в 3NF. Однако тот факт, что имеются функциональные зависимости
атрибутов отношения от атрибута, являющегося частью первичного ключа,
приводит к аномалиям. Например, для того чтобы изменить имя сотрудника с
данным номером согласованным образом, нам потребуется модифицировать
все кортежи, включающие его номер.
Отношение R находится в нормальной форме Бойса-Кодда (BCNF) в том
и только в том случае, если каждый детерминант является возможным ключом.
Очевидно, что это требование не выполнено для отношения
СОТРУДНИКИ-ПРОЕКТЫ. Можно произвести его декомпозицию к
отношениям СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ)
Возможные ключи:
СОТР_НОМЕР
СОТР_ИМЯ
Функциональные зависимости:
СОТР_НОМЕР
CОТР_ИМЯ
СОТР_ИМЯ
СОТР_НОМЕР
СОТРУДНИКИ-ПРОЕКТЫ
(СОТР_НОМЕР,
ПРО_НОМЕР,
СОТР_ЗАДАН)
Возможный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР
CОТР_ЗАДАН
Возможна альтернативная декомпозиция, если выбрать за основу
СОТР_ИМЯ. В обоих случаях получаемые отношения СОТРУДНИКИ и
СОТРУДНИКИ-ПРОЕКТЫ находятся в BCNF, и им не свойственны
отмеченные аномалии.
Четвертая нормальная форма (4NF)
Рассмотрим пример следующей схемы отношения:
ПРОЕКТЫ (ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН)
Отношение ПРОЕКТЫ содержит номера проектов, для каждого проекта
список сотрудников, которые могут выполнять проект, и список заданий,
89
предусматриваемых проектом. Сотрудники могут участвовать в нескольких
проектах, и разные проекты могут включать одинаковые задания.
Каждый кортеж отношения связывает некоторый проект с сотрудником,
участвующим в этом проекте, и заданием, которое сотрудник выполняет в
рамках данного проекта (предполагаем, что любой сотрудник, участвующий в
проекте, выполняет все задания, предусмотренные этим проектом). По причине
сформулированных выше условий единственным возможным ключом
отношения является составной атрибут ПРО_НОМЕР, ПРО_СОТР,
ПРО_ЗАДАН и нет никаких других детерминантов. Следовательно, отношение
ПРОЕКТЫ находится в BCNF. Но при этом оно обладает недостатками: если,
например, некоторый сотрудник присоединяется к данному проекту,
необходимо вставить в отношение ПРОЕКТЫ столько кортежей, сколько
заданий в нем предусмотрено.
В отношении ПРОЕКТЫ существуют следующие две многозначные
зависимости:
ПРО_НОМЕР
ПРО_СОТР
ПРО_НОМЕР
ПРО_ЗАДАН
Дальнейшая нормализация отношений, подобных отношению ПРОЕКТЫ,
основывается на следующей теореме.
Теорема Фейджина
Отношение R(A,B,C) можно спроецировать без потерь в отношения
R1(A,B) и R2(A,C) в том и только в том случае, когда существует многозначная
зависимость A B | C.
Под проецированием без потерь понимается такой способ декомпоз иции
отношения, при котором исходное отношение полностью и без избыточности
восстанавливается путем естественного соединения полученных отношений.
Отношение R находится в четвертой нормальной форме (4NF) в том и
только в том случае, если в случае существования многозначной зависимости A
B все остальные атрибуты R функционально зависят от A.
В нашем примере можно произвести декомпозицию отношения
ПРОЕКТЫ в два отношения ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫЗАДАНИЯ:
ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР)
ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН)
Оба эти отношения находятся в 4NF и свободны от отмеченных
аномалий.
Пятая нормальная форма (5NF)
Во всех рассмотренных до этого момента нормализациях производилась
декомпозиция одного отношения в два. Иногда это сделать не удается, но
возможна декомпозиция в большее число отношений, каждое из которых
обладает лучшими свойствами.
90
Рассмотрим, например, отношение
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ
(СОТР_НОМЕР,
ОТД_НОМЕР,
ПРО_НОМЕР)
Предположим, что один и тот же сотрудник может работать в нескольких
отделах и работать в каждом отделе над несколькими проектами. Первичным
ключом этого отношения является полная совокупность его атрибутов,
отсутствуют функциональные и многозначные зависимости.
Поэтому отношение находится в 4NF. Однако в нем могут существовать
аномалии, которые можно устранить путем декомпозиции в три отношения.
Отношение R находится в пятой нормальной форме (нормальной форме
проекции-соединения – PJ/NF) в том и только в том случае, когда любая зависимость
соединения в R следует из существования некоторого возможного ключа в R.
Введем следующие имена составных атрибутов:
СО = {СОТР_НОМЕР, ОТД_НОМЕР}
СП = {СОТР_НОМЕР, ПРО_НОМЕР}
ОП = {ОТД_НОМЕР, ПРО_НОМЕР}
Предположим, что в отношении СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ
существует зависимость соединения:
* (СО, СП, ОП)
На примерах легко показать, что при вставке и удалении кортежей могут
возникнуть проблемы. Их можно устранить путем декомпозиции исхо дного
отношения в три новых отношения:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, ОТД_НОМЕР)
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР)
ОТДЕЛЫ-ПРОЕКТЫ (ОТД_НОМЕР, ПРО_НОМЕР)
Пятая нормальная форма – это последняя нормальная форма, которую
можно получить путем декомпозиции. Ее условия достаточно нетривиальны, и
на практике 5NF не используется. Заметим, что зависимость с оединения
является обобщением как многозначной зависимости, так и функциональной
зависимости.
КОНТРОЛЬНЫЕ ВОПРОСЫ
1.
Перечислите этапы проектирования баз данных.
2.
Дайте определение инфологической, датологической и физической
моделей данных.
3.
Как взаимосвязаны между собой этапы проектирования баз
данных?
4.
В чем заключается инфологическое моделирование базы данных?
91
5.
Какие требования предъявляются к инфологической модели?
6.
Перечислите компоненты инфологической модели.
7.
Что такое идентификатор объекта, какими свойствами он должен
обладать?
8.
Что представляет собой модель «сущность-связь»?
9.
Какие различают типы связей между объектами, как они
отображаются в инфологической модели?
10. Приведите примеры из любых предметных областей связей типа
1:1, 1:М; М:М между объектами.
11. В чем заключается моделирование локальных представлений?
Приведите пример.
12. По каким правилам осуществляется объединение локальных
представлений?
13. Какой объект называется агрегированным? Приведите примеры
агрегированных объектов.
14. Какой объект называется обобщенным? Приведите примеры
обобщенных объектов.
15. В чем заключается даталогическое проектирование базы данных?
16. Каким образом реализуется связь М:М между объектами?
17. Какие подходы существуют при выборе показателей, которые
должны храниться в базе данных?
18. В каких случаях обоснованным является введение искусственных
идентификаторов?
19. Дайте рекомендации по проектированию реляционной базы
данных.
20. В чем заключается нормализация отношений?
21. Дайте определение функциональной, полной функциональной,
транзитивной и многозначной зависимостей.
22. Какие существуют нормальные формы? Дайте их краткую
характеристику.
92
7. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ
7.1. Общие понятия
Реляционная база данных представлена пользователю как множество
отношений или таблиц. Все значения в отношении атомарные или скалярные
(нет групп повторения). Реляционная система поддерживает реляционные базы
данных и операции над ними, в частности включающие в себя операцию
выборки строк RESTRICT (SELECT), операцию выборки столбцов PROJECT
(также называемую проекцией) и операцию соединения таблиц JOIN. Эти и
подобные операции выполняются на уровне множества. Свойство
замкнутости реляционных систем означает, что результат операции имеет тот
же тип, что и объекты, над которыми проводилась операция (все они являются
отношениями); это позволяет использовать вложенные реляционные
выражения.
Формальная теория, которая лежит в основе реляционных систем,
называется реляционной моделью. Реляционная модель изучает материал
только на логическом уровне и не затрагивает физический уровень. В модели
рассматриваются три аспекта данных – структура (объекты данных),
целостность и обработка данных (операторы). Объектами в основном
являются таблицы, целостность обеспечивается внешними и первичными
ключами, а операторы – это RESTRICT, PROJECT, JOIN и т.д.
Оптимизатор – это компонент системы, определяющий, как будут
реализованы запросы пользователя (которые указывают, что делать, а не как
делать). Таким образом, в реляционных системах предусмотрена
ответственность за «навигацию» по хранимой базе данных для нахождения
необходимых данных; такие системы иногда называют системами
автоматической навигации. Оптимизация и автоматическая навигация
являются предпосылками независимости данных в реляционной системе.
Каталог – это множество системных таблиц, которые содержат
дескрипторы различных важных для системы элементов (базовых таблиц,
представлений, индексов и т.д.). Пользователи могут опрашивать каталог так
же, как собственные данные.
Производная таблица — это таблица, полученная из других таблиц
посредством реляционного выражения. Базовая таблица — это таблица, не
являющаяся производной. Представление — это именованная производная
таблица, определение которой через другие таблицы содержится в каталоге.
Пользователь может оперировать представлениями практически так же, как и
базовыми таблицами. Система выполняет операции над представлениями,
заменяя ссылки на название представления выражением, определяющим его,
т.е. преобразуя операцию над представлением в соответствующую операцию
над базовыми таблицами. Этот метод реализации операций называется методом
подстановки.
93
Стандартным языком для работы с реляционными базами данных
является язык SQL. Для создания новой базовой таблицы используется
оператор SQL CREATE TABLE. Оператор выборки SELECT (или SELECTFROM-WHERE) языка SQL предоставляет функциональные возможности
реляционных операторов RESTRICT, PROJECT и JOIN и даже больше.
Операторы обновления SQL – это операторы INSERT, UPDATE и DELETE.
Связь реляционной модели с компонентами архитектуры
ANSI/SPARC
1. Базовые таблицы соответствуют концептуальному уровню
архитектуры ANSI/ SPARC.
2. Представления соответствуют внешнему уровню архитектуры
ANSI/SPARC.
3. В реляционной модели не рассматривается внутренний уровень систем
данных, в частности внутренний уровень архитектуры ANSI/SPARC.
4. Язык SQL — это типичный (фактически стандартный) подъязык
данных. В этом смысле он включает в себя язык определения данных и язык
обработки данных. Язык обработки данных SQL может использоваться как на
внешнем, так и на концептуальном уровне.
5. Прикладные программы в SQL-системе могут получить доступ к базе
данных из базового языка, такого как COBOL, посредством встроенных SQLоператоров.
7.2. Реляционные объекты данных
7.2.1. Основные понятия
Основными понятиями объектов реляционных баз данных являются
отношение, кортеж, кардинальное число, атрибут, степень, домен и первичный ключ.
Пример отношения СОТРУДНИКИ, содержащего информацию о сотрудниках
некоторой организации, приведен на рис. 3.1.
Домен - допустимое потенциальное множество значений данного типа,
которые может принимать объект.
Домен представляет набор скалярных значений, из которых разные
атрибуты различных отношений берут свои реальные значения. Домены
ограничивают сравнения, т.е. в общем случае требуется, чтобы сравниваемые
значения принадлежали одному домену. Как следствие, домены ограничивают
различные реляционные операции.
Отношение делится на две части: заголовок и тело. Заголовок – это
набор атрибутов (точнее, пар «имя атрибута: имя домена»), а тело – это набор
кортежей. Количество атрибутов называется степенью (или арностью), а
количество кортежей – кардинальным числом.
Первичный ключ – это уникальный идентификатор для таблицы, т.е.
столбец или такая комбинация столбцов, что в любой момент времени не
существует двух строк, содержащих одинаковое значение в этом столбце или
комбинации столбцов.
94
Кардинальное
число
Степень
Рис. 7.1. Пример отношения СОТРУДНИКИ
Для реляционных
эквивалентными:
баз
Формальный реляционный термин
Отношение
Кортеж
Кардинальное число
Атрибут
Степень
Первичный ключ
Домен
данных
следующие
термины
являются
Неформальный эквивалент
Таблица
Строка или запись
Количество строк
Столбец или поле
Количество столбцов
Уникальный идентификатор
Общая совокупность допустимых значений
В дальнейшем в качестве примера будет использоваться база данных
поставщиков и деталей (рис. 7.2).
95
S
S#
S1
S2
S3
S4
S5
P
P#
STATU
CITY
S
Smith
20
London
Jones
10
Paris
Black
30
Paris
Clark
20
London
Adams
30
Athens
SNAME
SP
WEIGH
CITY
T
Londo
Red
12
n
Green
17
Paris
Blue
17
Rome
Londo
Red
14
n
Blue
12
Paris
Londo
Red
19
n
PNAME COLOR
P1
Nut
P2
P3
Bolt
Screw
P4
Screw
P5
Cam
P6
Cog
S#
P#
QTY
S1
S1
S1
S1
S1
S1
P1
P2
P3
P4
P5
P6
300
200
400
200
100
100
S2
P1
300
S2
P2
400
S3
S4
P2
P2
200
200
S4
P4
300
S4
P5
400
Рис. 7.2. База данных поставщиков и деталей
В базе данных предполагается следующая семантика:
• Таблица S представляет поставщиков. Каждый поставщик имеет
уникальный номер (S#); имя (SNАМЕ); значение рейтинга или статуса
(SТАТUS); место расположения (СIТY). Предполагается, что каждый
поставщик расположен точно в одном городе.
• Таблица Р представляет детали (точнее, виды деталей). У каждого вида
детали есть номер детали (Р#), который является уникальным; название детали
(РNАМЕ); цвет (СОLOR); вес (WEIGHT); место расположения, где хранится
этот вид деталей (CITY). Предполагается, что вес детали приведен в фунтах.
Также предполагается, что каждый отдельный вид детали только о дного цвета
и хранится на складе точно в одном городе.
• Таблица SР представляет поставки. Каждая поставка характеризуется
номером поставщика (S#), номером детали (Р#) и количеством (QTY).
Предполагается, что в одно и то же время может быть не более одной поставки
для одного поставщика и одной детали, поэтому для данной поставки
комбинация значений S# и Р# уникальна с точки зрения набора текущих
поставок, находящихся в таблице SР.
Поставщиков и детали можно рассматривать как объекты, а поставку –
как отношение между определенным поставщиком и определенной деталью.
96
7.2.2. Фундаментальные свойства отношений
1. Отсутствие кортежей-дубликатов
Исходя из этого свойства, у каждого отношения должен быть первичный
ключ. По крайней мере, полный набор атрибутов отношения обладает этим
свойством. При формальном определении первичного ключа требуется
обеспечение его «минимальности», т.е. в набор атрибутов первичного ключа не
должны входить такие атрибуты, которые можно отбросить без ущерба для
однозначности определения кортежа.
2. Отсутствие упорядоченности кортежей
Дает дополнительную гибкость СУБД при хранении баз данных во
внешней памяти и при выполнении запросов к базе данных.
3. Отсутствие упорядоченности атрибутов
Для ссылки на значение атрибута в кортеже «отношения» всегда
используется имя атрибута.
4. Атомарность значений атрибутов
Это следует из определения домена как потенциального множества
значений простого типа данных, т.е. среди значений домена не могут
содержаться множества значений (отношения). Принято говорить, что в
реляционных базах данных допускаются только нормализованные отношения
или отношения, представленные в первой нормальной форме.
7.2.3. Виды отношений
1. Именованное отношение – это переменная отношения, определенная в
СУБД посредством операторов создания отношения, представления или
снимка.
2. Базовое отношение – отношение, не являющееся производным.
3. Производное отношение – отношение, определенное (посредством
реляционного выражения) через другие отношения и, в конечном счете, ч ерез
базовые отношения.
4. Выраженное отношение – отношение, которое можно получить из набора
именованных отношений посредством некоторого реляционного выражения. Базовые
отношения, представления, снимки, промежуточные и окончательные результаты
отчетов являются выражаемыми отношениями.
5. Представление – именованное производное отношение. Представления
виртуальны – они представлены в системе исключительно через определение в
терминах других именованных отношений.
6. Снимки (snapshot) – это именованные производные отношения, однако
в отличие от представлений снимки реальны, а не виртуальны, т.е.
представлены не только с помощью определения в терминах других
именованных отношений, но также и своими отдельными данными. Создание
снимка похоже на выполнение запроса, за исключением того, что результат
такого запроса сохраняется в базе данных под определенным именем как
отношение, доступное только для чтения, и периодически снимок
97
«обновляется», т.е. его текущее значение сбрасывается, запрос выполняется
снова и его результат становится новым значением снимка.
7. Результатом запроса называется неименованное производное
отношение, служащее результатом некоторого определенного запроса. База
данных не обеспечивает постоянного существования для результатов запросов.
8.
Промежуточным
результатом называется неименованное
производное отношение, являющееся результатом некоторого реляционного
выражения, вложенного в другое, большее выражение.
9.
Хранимым
отношением
называется отношение, которое
поддерживается в физической памяти «непосредственным» образом.
Для каждого отношения есть связанная с ним интерпретация, или
предикат, составляющий критерий возможности обновления для этого
отношения.
Пример: Поставщик с определенным номером (S#) имеет определенное
имя (SNAME) и определенное значение статуса (STATUS) и располагается в
определенном городе (CITY); кроме того, нет двух поставщиков с одинаковыми
номерами.
В любой момент времени отношение содержит в точности те кортежи,
при которых предикат является истиной.
Реляционная база данных – это база данных, воспринимаемая
пользователем как набор нормализованных отношений разной степени.
7.3.
Целостность реляционных данных
Важнейшим вопросом при проектировании систем обработки данных
(СОД) является обеспечение целостности данных. Проблема целостности
состоит в обеспечении правильности данных в базе данных в любой момент
времени. Целостность данных обеспечивается набором специальных
предложений, называемых ограничениями целостности. Ограничения
целостности представляют собой утверждения о допустимых значениях
отдельных информационных единиц и связях между ними. Ограничения
целостности определяются в большинстве случаев особенностями предметной
области, хотя могут отражать и чисто информационные характеристики.
Ограничения целостности могут относиться к разным информационным
объектам: атрибутам (полям), кортежам (строкам, записям), отношениям
(таблицам, файлам), связям между файлами и т. п.
Для полей чаще всего используются следующие виды ограничений:
1). тип и формат поля;
2). задание диапазона значений;
3). признак непустого поля;
4). задание домена.
98
Потенциальным ключом (К) отношения R называется подмножество
множества атрибутов R, обладающее свойствами уникальности и
неизбыточности.
Потенциальный ключ, состоящий из более чем одного атрибута,
называется составным, состоящий из одного атрибута – простым.
Потенциальные ключи обеспечивают основной механизм адресации на
уровне кортежей в реляционной системе.
Базовое отношение может иметь больше одного потенциального ключа. В
таком случае в реляционной модели один из потенциальных ключей должен
быть выбран в качестве первичного ключа (PRIMARY KEY), а остальные будут
называться альтернативными ключами (CANDIDATE KEY).
Внешним ключом называется атрибут или группа атрибутов одного
отношения, которым назначена ссылка на первичный ключ другого отношения,
для однозначного его определения.
В целостной части реляционной модели данных помимо ограничений для
атрибутов фиксируются два базовых требования целостности, которые должны
поддерживаться в любой реляционной СУБД:
1) требование целостности сущностей, означающее, что любой кортеж
любого отношения отличим от любого другого кортежа этого отношения, т.е.
любое отношение должно обладать первичным ключом;
2) требование целостности по ссылкам (требование внешнего ключа).
Требование состоит в том, что для каждого значения внешнего ключа
появляющегося в ссылающемся отношении (в отношении, на которое ведет
ссылка), должен найтись кортеж с таким же значением первичного ключа, либо
значение внешнего ключа должно быть неопределенным (т.е. ни на что не
указывать – null-значение).
Для поддержания целостности по ссылкам существуют три подхода:
1) ОГРАНИЧИТЬ (RESTRICTED). Запрещается производить удаление
кортежа, на который существуют ссылки (т.е. сначала нужно либо удалить
ссылающиеся кортежи, либо соответствующим образом изменить значения их
внешнего ключа);
2) при удалении кортежа, на который имеются ссылки, во всех
ссылающихся кортежах значение внешнего ключа автоматически становится
неопределенным.;
3) КАСКАДИРОВАТЬ (CASCADES). Каскадное удаление – при
удалении кортежа из отношения, на которое ведет ссылка, из ссылающегося
отношения автоматически удаляются все ссылающиеся кортежи.
Помимо этого возможно использование процедур баз данных (хранимых
процедур, триггеров), которые вызываются при выполнении операций
удаления модификации и вставки и выполняют заданные действия.
99
7.4.
Реляционные операторы
7.4.1. Реляционная алгебра
Набор основных алгебраических операций состоит из восьми опер аций,
которые делятся на два класса: теоретико-множественные операции и
специальные реляционные операции.
Теоретико-множественные операции
Это объединение, пересечение, вычитание и произведение (расширенное
декартово произведение). Первые три операции требуют от операндов
совместимости по типу.
Два отношения совместимы по типу, если каждое из них имеет одно и то
же множество атрибутов и соответствующие атрибуты определены на одном и
том же домене.
1.
Объединения отношений - при объединении двух отношений
производится отношение, включающее все кортежи, входящие хотя бы в одно
из отношений-операндов.
R1
R2
а
д
б
е
в
а
и
к
л
и
г
к
д
л
е
R=R1 U R2
R = R1 UNION R2
а
д
б
е
в
а
и
г
к
д
л
е
2. Пересечение отношений – операция пересечения двух отношений
(R = R1 INTERSECT R2) производит отношение, включающее все кортежи,
входящие в оба отношения-операнды.
R=R1 R2
и
к
л
3. Разность отношений - отношение, являющееся разностью двух
отношений (R = R1 MINUS R2), включает все кортежи, входящие в отношение
– первый операнд; такие, что ни один из них не входит в отношение,
являющееся вторым операндом.
R=R1–R2
а
д
б
е
100
в
а
4. Декартово произведение отношений - при выполнении прямого
произведения двух отношений производится отношение, кортежи которого
являются конкатенацией (сцеплением) кортежей первого и второго операндов.
R=R1 R2
R = R1 TIMES R2
а
д
б
е
в
а
и
и
к
к
л
л
и
а
д
и
к
б
е
к
л
в
а
л
и
г
г
г
к
д
д
д
л
е
е
е
Операции объединения, пересечения и декартова произведения
ассоциативны и коммутативны. На рис. 7.3 приведены примеры теоретикомножественных операций применительно к базе данных «поставщики-детали».
A
S# SNAME
S1 Smith
S4 Clark
a)
STATUS CITY
20
London
20
London
Объединение
(A UNION B)
B
S# SNAME
S1 Smith
S2 Jones
STATUS CITY
20
London
10
Paris
S#
S1
S4
S2
STATUS
20
20
10
SNAME
Smith
Clark
Jones
б)
Пересечение
(A INTERSECT B)
S# SNAME
S1 Smith
в)
Вычитание
(A MINUS B)
S# SNAME STATUS CITY
S4 Clark
20
London
г)
CITY
London
London
Paris
STATUS CITY
20
London
Вычитание
(B MINUS A)
S# SNAME STATUS CITY
S2 Jones
10
Paris
Рис. 7.3 Примеры теоретико-множественных операций
101
Специальные реляционные операции
1 Ограничение отношения (выборка) – результатом ограничения
отношения по некоторому условию является отношение, включающее кортежи
отношения-операнда, удовлетворяющее этому условию:
A WHERE comp,
где A - ограничиваемое отношение,
comp - простое условие сравнения.
Можно использовать операции ограничения, в которых условием
ограничения является произвольное булевское выражение, составленное из
простых условий с использованием логических связок AND, OR и AND и скобок
(рис. 7.4).
2 Проекция отношения - при выполнении проекции отношения на
заданный набор его атрибутов производится отношение, кортежи которого
производятся путем взятия соответствующих значений из заданных столбцов
кортежей отношения-операнда, с исключением дублирующих кортежей
(рис. 7.5).
3 Соединение отношений - при соединении двух отношений по
некоторому условию образуется результирующее отношение, кортежи которого
являются конкатенацией кортежей первого и второго отношений и
удовлетворяют этому условию.
S WHERE CITY =’London’
P WHERE WEIGHT < 14
S#
S1
S4
P# PNAME
P1 Nut
P5 Cam
SP WHERE S# = ‘S1’ AND P# = ‘P1’
SNAME
Smith
Clark
COLOR
Red
Blue
S#
S1
STATUS CITY
20
London
20
London
WEIGHT
12
12
P#
P1
CITY
London
Paris
QTY
300
Рис. 7.4. Примеры операций выборки
Имеются важные частные случаи соединения – естественное соединение
и -соединение. Операция естественного соединения применяется к паре
отношения A и B, обладающих (возможно, составным) общим атрибутом c (т.е.
атрибутом с одним и тем же именем и определенным на одном и том же
домене). Пусть ab обозначает объединение заголовков отношений A и B. Тогда
102
естественное соединение A и B – это спроецированный на ab результат
эквисоединения A и B по A.c и B.c (рис. 7.6).
S [CITY]
CITY
London
Paris
Athens
P [COLOR, CITY]
COLOR
Red
Green
Blue
Blue
(S where city = ‘Paris’) [S#]
CITY
London
Paris
Rome
Paris
S#
S2
S3
Рис. 7.5. Примеры операций проекции
Основной смысл операции естественного соединения - возможность
восстановления сложной сущности, декомпозированной по причине требования
первой нормальной формы.
д
е
а
г
д
е
R=R1 R2
a1(R1)=a2(R2)
#
S1
S1
S1
S2
S2
S3
S3
S4
S4
S4
S
SNAME
Smith
Smith
Smith
Jones
Jones
Bla
ke
Blake
Clark
Clark
Clark
STATUS
CITY
P#
PNAME
COLOR
WEIGHT
20
20
20
10
10
London
London
London
Paris
Paris
P1
P4
P6
P2
P5
Nut
Screw
Cog
Bolt
Cam
Red
Red
Red
Green
Blue
12
14
19
17
12
30
Paris
P2
Bolt
Green
17
30
20
20
20
Paris
London
London
London
P5
P1
P4
P6
Cam
Nut
Screw
Cog
Blue
Red
Red
Red
12
12
14
19
Рис. 7.6. Естественное соединение S JOIN P
103
-соединение предназначается для тех случаев, когда требуется
соединить вместе два отношения на основе некоторых условий, отличных от
эквивалентности. -соединением отношения А по атрибуту Х с отношением В
по атрибуту Y называется результат вычисления выражения (A TIMES B)
WHERE X Y, т.е. -соединение – это отношение с тем же заголовком, что и
при декартовом произведении отношений А и В, и с телом, содержащим
множество кортежей t, таких, что t принадлежит этому декартову
произведению и вычисление условия “X Y” дает значение «истина» для этого
кортежа. Атрибуты X и Y должны быть определены на одном и том же домене,
а операция должна иметь смысл для этого домена. Пример
-соединения
приведен на рис.7.7.
S# SNAME STATUS CITY P# PNAME
S2
S2
S2
S3
S3
Jones
Jones
Jones
Blake
Blake
10
10
10
30
30
Paris
Paris
Paris
Paris
Paris
P1
P4
P6
P1
P4
Nut
Screw
Cog
Bolt
Cam
S3
Blake
30
Paris
P6
Bolt
C
WEIGHT
OLOR
Red
12
Red
14
Red
19
Red
12
Red
14
Red
19
PCITY
London
London
London
London
London
Lon
don
Рис. 7.7. Больше-соединение отношений поставщиков и деталей
по атрибуту города
4 Деление отношений - операция реляционного деления имеет два
операнда: бинарное и унарное отношения. Результирующее отношение состоит
из одноатрибутных кортежей, включающих значения первого атрибута
кортежей первого операнда, таких, что множество значений второго атрибута
(при фиксированном значении первого атрибута) совпадает с множеством
значений второго операнда (рис. 7.8).
Дополнительно в состав реляционной алгебры включается операция
переименования, производящая отношение, тело которого совпадает с телом
операнда, но имена атрибутов изменены и операция присваивания,
позволяющая сохранить результат вычисления реляционного выражения в
существующем отношении БД.
R RENAME NAME1 AS NAME2
Поскольку результатом любой реляционной операции (кроме операции
присваивания) является некоторое отношение, можно образовывать
реляционные выражения, в которых вместо отношения-операнда некоторой
реляционной операции находится вложенное реляционное выражение.
104
DEND
DOR
S#
S1
S1
S1
S1
S1
S1
..
P#
P1
P2
P3
P4
P5
P6
..
P#
..
S2
S2
S3
S4
S4
S4
..
P1
P2
P2
P2
P4
P5
D P#
DOR
P3
OR
P1
P2
P4
P1
P2
P3
P4
P5
P6
DEND DIVIDEBY DOR
S#
S1
S2
S#
S1
S4
S#
S1
Рис. 7.8. Примеры деления
Примеры использования реляционной алгебры
для выражения словесных запросов в виде формулы
1. Получить имена поставщиков, которые поставляют деталь P2:
((SP JOIN S) WHERE P# = ’P2’) [SNAME].
2. Получить имена поставщиков, которые поставляют по крайней мере
одну красную деталь:
(((P WHERE COLOR = ‘Red’) JOIN SP) [S#] JOIN S) [SNAME]
или
(((P WHERE COLOR = ‘Red’) [P#] JOIN SP) JOIN S) [SNAME].
3. Получить имена поставщиков, которые поставляют все детали:
((SP [S#, P#] DIVIDEBY P [P#] JOIN S) [SNAME].
4. Получить номера поставщиков, поставляющих по крайней мере все те
детали, которые поставляет поставщик S2:
105
SP [S#, P#] DIVIDEBY (SP WHERE S# = ‘S2’) [P#].
5. Получить имена поставщиков, которые не поставляют деталь P2:
((S [S#] MINUS (SP WHERE P# = ‘P2’) [S#]) JOIN S) [SNAME].
Назначение реляционной алгебры
Основная цель реляционной алгебры – обеспечить запись выражений.
Возможно следующее применение таких выражений:
- определение области выборки, т.е. определение данных для их выбора;
- определение области обновления, т.е. определение данных для их
вставки, изменения или удаления как результата операции обновления;
- определение (именованных) виртуальных отношений, т.е.
определение данных для их визуализации через представления;
- определение снимка, т.е. определение данных для сохранения в виде
«мгновенного» снимка отношения;
- определение правил безопасности, т.е. определение данных, для
которых осуществляется контроль доступа;
- определение требований устойчивости, т.е. определение данных,
которые входят в область для некоторой операции управления
одновременным доступом;
- определение правил целостности, т.е. некоторых особых правил,
которым должна удовлетворять база данных, наряду с общими
правилами, представляющими часть реляционной модели и
применяемыми к каждой базе данных.
В общем, выражения служат для символического высокоуровневого
представления намерений пользователя и ими можно манипулировать в
соответствии с многочисленными правилами преобразования. Таким образом,
реляционная алгебра служит хорошим базисом для оптимизации.
Операции расширения и подведения итогов
Многие авторы предлагали дополнительные операторы помимо восьми
основных. Наиболее часто встречаются операторы расширения и подведения
итогов.
Операция расширения (EXTEND) позволяет из определенного
отношения создать новое отношение, содержащее дополнительный атрибут,
значения которого получены посредством некоторых скалярных вычислений.
Синтаксис:
EXTEND A ADD exp AS Z.
Результатом этого выражения будет отношение с заголовком,
эквивалентным заголовку отношения А, расширенному новым атрибутом Z,
который подсчитывается вычислением скалярного выражения exp для кортежа
отношения А. При этом отношение А не должно иметь атрибута Z и выражение
exp не должно ссылаться на атрибут Z.
106
Пример:
EXTEND P ADD (WEIGHT*454) AS GMWT;
EXTEND (P JOIN SP) ADD (WEIGHT*QTY) AS SHIPWT;
EXTEND S ADD COUNT ((SP RENAME S# AS X) WHERE X=S#) AS NP.
Атрибут NP в результирующем отношении представляет количество
деталей,
поставляемых
поставщиком,
который
идентифицируется
соответствующим значением S#.
Функция COUNT – пример итоговой функции, т.е. функции, берущей в
качестве аргумента множество значений и возвращающей одно значение.
Также используются следующие итоговые функции: SUM (сумма), AVG
(среднее значение), MAX (максимальное значение), MIN (минимальное
значение).
Таким образом, операция расширения обеспечивает возможность
«горизонтального» или «построчного» вычисления в алгебре. Операция
подведения итогов (SUMMARIZE) выполняет аналогичную функцию для
«вертикальных» вычислений.
Синтаксис:
SUMMARIZE A BY (A1, A2, …, An) ADD exp AS Z,
где A1, A2, …, An – отдельные атрибуты отношения А.
Результатом этого выражения будет отношение с заголовком {A1, A2, …,
An, Z} и с телом, содержащим все такие кортежи t, которые являются
кортежами проекции отношения А по атрибутам A1, A2, …, An, расширенного
значением для нового атрибута Z; такое новое значение Z подсчитывается
вычислением итогового выражения exp по всем кортежам отношения А,
которое имеет те же самые значения для атрибутов A1, A2, …, An, что и кортеж t.
Пример:
SUMMARIZE SP BY (P#) ADD SUM (QTW) AS TOTQTY – вычисляется
отношение с заголовком {P#, TOTQTY}, в котором существует один кортеж
для каждого значения P# в отношении SP; в этом кортеже содержится значение
P# и соответствующее общее количество деталей.
SUMMARIZE (P JOIN SP) BY (CITY) ADD COUNT AS NSP – результат
будет следующим:
CITY
NSP
London
5
Paris
6
Rome
1
Операторы обновления
Реляционная модель кроме реляционной алгебры может включать также
операции реляционного присвоения, имеющие следующий синтаксис:
target := source.
Вычисленное значение source присваивается отношению target, заменяя
его старое значение. Операция присвоения дает возможность обновлять базу
107
данных, однако она позволяет только полностью заменять значение отношения,
поэтому используются более точные операции обновления, такие как INSERT,
DELETE и UPDATE.
Оператор вставки INSERT
Синтаксис: INSERT source INTO target.
Пример: INSERT (S where CITY = ‘London’) INTO TEMP.
Оператор обновления UPDATE
Синтаксис: UPDATE target assignment-commalist,
где каждое присвоение assignment имеет вид attribute:=scalar-expression;
target – реляционное выражение, а каждый атрибут attribute принадлежит
отношению, которое является результатом вычисления указанного выражения.
Все кортежи в результирующем отношении обновляются в соответствии с
указанным оператором присвоения.
Пример: UPDATE P WHERE COLOR = ‘Red’ CITY := ‘Paris’.
Оператор удаления DELETE
Синтаксис: DELETE target.
Пример: DELETE S WHERE STATUS < 20.
7.4.2. Реляционное исчисление
Помимо реляционной алгебры для описания реляционных операций
может быть использовано реляционное исчисление. Допустим, необходимо
создать запрос: «Получить номера и города поставщиков, поставляющих деталь
Р2». Алгебраическая версия этого запроса выглядит следующим образом:
- преобразовать естественное соединение отношений S и P по атрибуту S#;
- выбрать из результата этого соединения кортежи детали P2;
- спроецировать результат этой выборки по атрибутам S# и CITY.
Формулировка этого запроса в терминах реляционного исчисления
выглядит приблизительно так: «Получить атрибуты S# и CITY для таких
поставщиков, для которых существует поставка в отношении SP с тем же
значением атрибута S# и со значением P2 атрибута P#».
Во второй формулировке мы указываем лишь характеристики
результирующего отношения, но ничего не говорим о способе его
формирования. В этом случае система должна сама решить, какие операции и в
каком порядке нужно выполнить над отношениями. Обычно говорят, что
алгебраическая формулировка является процедурной, т.е. задающей правила
выполнения запроса, а логическая – описательной (или декларативной),
поскольку она всего лишь описывает свойства желаемого результата. На самом
деле эти два механизма эквивалентны, и существуют не очень сложные правила
преобразования одного формализма в другой.
Реляционное исчисление основано на исчислении предикатов.
Базисными понятиями исчисления являются понятие переменной с
определенной для нее областью допустимых значений и понятие правильно
построенной формулы, опирающейся на переменные, предикаты и кванторы. В
108
зависимости от того, что является областью определения переменной,
различаются исчисление кортежей и исчисление доменов. В исчислении
кортежей областями определения переменных являются отношения базы
данных, т.е. допустимым значением каждой переменной является кортеж
некоторого отношения. В исчислении доменов областями определения
переменных являются домены, на которых определены атрибуты отношений
базы данных, т.е. допустимым значением каждой переменной является
значение некоторого домена.
При использовании кортежных переменных в формулах можно ссылаться
на значение атрибута переменной. Например, для того, чтобы сослаться на
значение атрибута SNAME переменной SX, нужно употребить конструкцию
SX.SNAME.
Синтаксис реляционного исчисления определяется с помощью
грамматики в форме Бэкуса-Наура (БНФ) и имеет следующий вид:
range-variable-definition
::=
RANGE OF variable IS range-item-commalist;
range-item
::=
relation | expression
expression
::=
(target-item-commalist) [WHERE wff]
target-item
::=
variable | variable . attribute [AS attribute]
wff
::=
condition
| NOT wff
| condition AND wff
| condition OR wff
| IF condition THEN wff
| EXISTS variable (wff)
| FORALL variable (wff)
| (wff)
где
commalist – список элементов, разделенных запятыми;
relation - имя отношения, variable - имя переменной, attribute - имя атрибута;
condition (условие) – формула WFF, заключенная в скобки, или простое
скалярное сравнение;
wff (well-formulated formula) – правильно построенная формула.
Правильно построенные формулы (WFF) служат для выражения условий,
накладываемых на кортежные переменные. Основой WFF являются простые
сравнения, представляющие собой операции сравнения скалярных значений
(значений атрибутов переменных или литерально заданных констант). Более
109
сложные варианты WFF строятся с помощью логических связок NOT, AND, OR
и IF ... THEN. Допускается также построение WFF с помощью кванторов
(EXIST) и (FORALL).
Переменная кортежа определяется следующим образом:
RANGE OF T IS X1, X2, …, Xn,
где T – определяемая переменная кортежа, а Xi – либо имя отношения, либо
выражение исчисления кортежей.
Пример: RANGE OF SX IS S.
Переменные, входящие в WFF, могут быть свободными или связанными.
Все переменные, входящие в WFF, при построении которой не использовались
кванторы, являются свободными. Если имя переменной использовано сразу
после квантора при построении WFF, то это связанная переменная. Т акая
переменная не видна за пределами минимальной WFF, связавшей эту
переменную. При вычислении значения такой WFF используется не одно
значение связанной переменной, а вся ее область определения. Формула WFF, в
которой все переменные связаны, называется закрытой формулой WFF.
Открытая формула WFF – это такая формула, которая содержит по крайней
мере одну свободную переменную.
WFF обеспечивают средства формулировки условия выборки из
отношений БД. Чтобы можно было использовать исчисление для реальной
работы с БД, требуется компонент, который определяет набор и имена
столбцов результирующего отношения. Этот компонент называется целевым
списком (target_item_commalist). Целевой список строится из целевых
элементов, каждый из которых может иметь следующий вид:
•var.attr, где var - имя свободной переменной соответствующей WFF, а attr
- имя атрибута отношения, на котором определена переменная var;
•var, что эквивалентно наличию подсписка var.attr1, var.attr2, ..., var.attrn,
где attr1, attr2, ..., attrn, включает имена всех атрибутов определяющего
отношения;
•new_name AS var.attr; new_name - новое имя соответствующего атрибута
результирующего отношения.
Последний вариант требуется в тех случаях, когда в WFF используются
несколько свободных переменных с одинаковой областью определения.
Выражением реляционного исчисления кортежей называется конструкция вида
target_item_commalist WHERE wff. Значением выражения является отношение,
тело которого определяется WFF, а набор атрибутов и их имена – целевым
списком.
Примеры:
1. Получить номера поставщиков из Парижа со статусом больше 20:
SX.S# WHERE SX.CITY = ‘Paris’ AND SX.STATUS > 20
2. Получить имена поставщиков, которые поставляют деталь P2:
SX. NAME WHERE EXISTS SPX ( SPX.S# = SX.S# AND SPX.P# = ‘P2’)
110
3. Получить имена поставщиков, которые поставляют по крайней мере
одну деталь, поставляемую поставщиком S2:
SX.SNAME WHERE EXISTS SPX (EXISTS SPY (SX.S# = SPX.S# AND
SPX.P# = SPX.P# AND
SPY.S# = ‘S2’))
4. Получить имена поставщиков, которые поставляют все детали:
SX.SNAME WHERE FORALL PX (EXISTS SPX (SPX.S# = SX.S# AND
SPX.P# = PX.P))
5. Получить имена поставщиков, которые не поставляют деталь P2:
SX.SNAME WHERE NOT EXISTS SPX
(SPX.S# = SX.S# AND SPX.P# = ‘P2’)
6. Получить общее количество поставляемых деталей:
SUM (SPX, QTY) AS GRANDTOTAL)
Основным формальным отличием исчисления доменов от исчисления
кортежей является наличие дополнительного набора предикатов, позволяющих
выражать так называемые условия принадлежности. Если R - это n-арное
отношение с атрибутами a1, a2, ..., an, то условие членства имеет вид R (ai1:vi1,
ai2:vi2, ..., aim:vim) (m <= n), где vij - это либо литерально задаваемая константа,
либо имя доменной переменной. Условие членства принимает значение true в
том и только в том случае, если в отношении R существует кортеж,
содержащий указанные значения указанных атрибутов. Если v ij – константа, то
на атрибут aij задается жесткое условие, не зависящее от текущих значений
доменных переменных; если же vij – имя доменной переменной, то условие
членства может принимать разные значения при разных значениях этой
переменной.
Во всех остальных отношениях формулы и выражения исчисления
доменов выглядят похожими на формулы и выражения исчисления кортежей.
Пример:
1. Получить номера поставщиков из Парижа со статусом больше 20:
SX WHERE EXISTS STATUSX
(STATUSX>20 AND S (S#:SX, STATUS:STATUSX, CITY:‘Paris’))
2. Получить имена поставщиков, которые поставляют, по крайней мере,
одну деталь, поставляемую поставщиком S2:
NAMEX WHERE EXISTS SX EXISTS PX
(S (S#:SX, SNAME:NAMEX
AND SP (S#:SX, P#:PX)
AND SP (S#:’S2’, P#:PX)
3. Получить имена поставщиков, которые поставляют все детали:
NAMEX WHERE EXISTS SX (S (S#:SX, SNAME:NAMEX)
AND FORALL PX (IF P (P#:PX)
THEN SP (S#:SX, P#:PX)))
111
4. Получить имена поставщиков, которые не поставляют деталь P2:
NAMEX WHERE EXISTS SX (S (S#:SX, SNAME:NAMEX)
AND NOT SP (S#:SX, P:’P2’))
5. Получить номера деталей, которые или весят более 16 фунтов, или
поставляются поставщиком S2, или и то и другое:
PX WHERE EXISTS WEIGHTX
(P (P#:PX, WEIGHT:WEIGHTX)
AND WEIGHTX>16)
OR SP (S#:’S2’, P#:PX)
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Что представляет собой реляционная база данных?
2. Какова связь реляционной модели с компонентами архитектуры
ANSI/SPARC?
3. Перечислите реляционные объекты данных.
4. Перечислите фундаментальные свойства отношений.
5. Какие существуют виды отношений?
6. В чем заключается целостность реляционных данных?
7. Дайте определения первичного, потенциального и внешнего ключа.
8. Какие подходы существуют для обеспечения целостности по ссылкам?
9. Для чего предназначена реляционная алгебра и реляционное
исчисление?
10. Перечислите теоретико-множественные операции реляционной
алгебры.
11. Перечислите специальные реляционные операции.
13. Каково назначение реляционной алгебры?
14. Опишите операции расширения и подведения итогов.
15. Перечислите операторы обновления.
16. Что представляет собой реляционное исчисление?
17. Опишите синтаксис выражения, построенного на основе
реляционного исчисления.
18. Что представляет собой правильно построенная формула?
19. Чем отличается исчисление кортежей от исчисления предикатов?
112
8. ЯЗЫК РЕЛЯЦИОННЫХ БАЗ ДАННЫХ SQL
8.1. Функции и основные возможности
Язык для взаимодействия с БД SQL (Structured Query Language)
появился в середине 70-х и был разработан в рамках проекта
экспериментальной реляционной СУБД System R. Первоначально язык был
ориентирован главным образом на удобную и понятную пользователям
формулировку запросов к реляционной БД в настоящее время язык SQL
является полным языком БД, содержащим помимо операторов формулирования
запросов и манипулирования БД средства определения и манипулирования
схемой БД, определения ограничений целостности и триггеров, представлений
БД, возможности определения структур физического уровня, поддерживающих
эффективное выполнение запросов, авторизации доступа к отношениям и их
полям; точек сохранения транзакции и откатов.
SQL представляет собой комбинацию реляционного исчисления
кортежей и реляционной алгебры. В современных СУБД с интерактивным
интерфейсом можно создавать запросы, используя другие средства, например
QBE (Query By Example – язык запросов по образцу). Однако применение SQL
зачастую позволяет повысить эффективность обработки данных в базе.
Существует несколько стандартов языка SQL: SQL1 (SQL/89), SQL2
(SQL/92), SQL3.
Операторы языка SQL можно условно разделить на два подъязыка: язык
определения данных (Data Definition Language – DDL) и язык манипулирования
данными (Data Manipulation Language – DML). Основные операторы языка SQL
представлены в табл. 8.1 [28].
Таблица 8.1
Операторы языка SQL
Вид
DDL
DML
Название
CREATE TABLE
DROP TABLE
ALTER TABLE
CREATE INDEX
DROP INDEX
CREATE VIEW
DROP VIEW
GRAND
REVOKE
SELECT
UPDATE
INSERT
DELETE
Назначение
Создание таблицы
Удаление таблицы
Изменение структуры таблицы
Создание индекса
Удаление индекса
Создание представления
Удаление представления
Назначение привилегий
Удаление привилегий
Выборка записей
Изменение записей
Вставка новых записей
Удаление записей
113
8.2. Средства определения схемы
8.2.1. Определение таблицы
Оператор определения таблицы имеет следующий синтаксис:
<определение таблицы> ::=
CREATE TABLE <имя таблицы> (<элемент таблицы>
[{,<элемент таблицы>}...])
<элемент таблицы> ::=
<определение столбца>
| <определение ограничений целостности таблицы>
Кроме имени таблицы в операторе специфицируется список элементов
таблицы, каждый из которых служит либо для определения столбца, либо для
определения ограничения целостности определяемой таблицы. Требуется
наличие хотя бы одного определения столбца.
Для определения столбцов таблицы и ограничений целостности
используются специальные операторы, которые должны быть вложены в
оператор определения таблицы.
Оператор
определения
столбца
описывается
следующими
синтаксическими правилами:
<определение столбца> ::=
<имя столбца> <тип данных>
[<значение по умолчанию>] [<ограничения целостности столбца>...]
<значение по умолчанию> ::=
DEFAULT { <литерал> | NULL }
<ограничения целостности столбца> ::=
NOT NULL [<спецификация уникальности>]
| <спецификация ссылки>
| CHECK (<условие поиска>)
Коме обязательной части, в которой определяется имя столбца и его тип
данных, определение столбца может содержать два необязательных раздела:
раздел значения столбца по умолчанию и раздел ограничений целос тности
столбца.
В разделе значения по умолчанию указывается значение, которое должно
быть помещено в строку, заносимую в данную таблицу, если значение данного
столбца явно не указано. Значение по умолчанию может быть указано в виде
литеральной константы с типом, соответствующим типу столбца, или путем
задания ключевого слова NULL, означающего, что значением по умолчанию
является неопределенное значение. Если значение столбца по умолчанию не
установлено, и в разделе ограничений целостности столбца указано NOT
NULL, то попытка занести в таблицу строку с неспецифицированным
значением данного столбца приведет к ошибке.
114
Указание в разделе ограничений целостности NOT NULL приводит к
неявному порождению проверочного ограничения целостности для всей
таблицы "CHECK (C IS NOT NULL)" (где C - имя данного столбца). Если
указана спецификация уникальности, то порождается соответствующая
спецификация уникальности для таблицы.
Если в разделе ограничений целостности указано ограничение по
ссылкам данного столбца (<спецификация
ссылки>), то порождается
соответствующее определение ограничения по ссылкам для таблицы:
FOREIGN KEY(C) <спецификация ссылки>.
Если указано проверочное ограничение столбца, то условие поиска этого
ограничения должно ссылаться только на данный столбец, и неявно
порождается соответствующее проверочное ограничение для всей таблицы.
Оператор изменения структуры таблицы имеет формат вида:
ALTER TABLE <имя таблицы>
({ADD, MODIFY, DROP} <имя столбца> [<тип данных>] [NOT NULL]
[,{ADD, MODIFY, DROP} <имя столбца> [<тип данных>] [NOT NULL]]...)
Изменение структуры таблицы может состоять в добавлении (ADD),
изменении (MODIFY) или удалении (DROP) одного или нескольких столбцов
таблицы. Правила записи оператора ALTER TABLE такие же, как и оператора
CREATE TABLE. При удалении столбца указывать <тип данных> не нужно.
Оператор удаления таблицы имеет формат вида:
DROP TABLE <имя таблицы>
8.2.2. Определение ограничений целостности таблицы
Ограничения целостности таблицы обладают следующим синтаксисом:
<определение ограничений целостности таблицы> ::=
<определение ограничения уникальности>
| <определение ограничения по ссылкам>
| <определение проверочного ограничения>
<определение ограничения уникальности> ::=
<спецификация уникальности> (<список уникальности столбцов>)
<спецификация уникальности> ::= UNIQUE | PRIMARY KEY
<список уникальности столбцов> ::= <имя столбца> [{,<имя
столбца>}...]
<определение ограничения по ссылкам > ::=
FOREIGN KEY (<ссылающиеся столбцы>) <спецификация ссылки>
<спецификация ссылки> ::=
REFERENCES <упомянутая таблица и колонки>
<ссылающиеся столбцы> ::= <список столбцов ссылки>
<упомянутая таблица и колонки> ::=
<имя таблицы> [(<список столбцов ссылки>)]
<список столбцов ссылки> ::= <имя столбца> [{,<имя столбца>}...]
<определение проверочного ограничения> ::= CHECK (<условие поиска>)
115
Для одной таблицы может быть задано несколько ограничений
целостности, в том числе те, которые неявно порождаются ограничениями
целостности столбцов. Ограничения таблицы фактически проверяются пр и
выполнении каждого оператора SQL.
Далее T обозначает таблицу, для которой определяются ограничения
целостности.
Ограничение уникальности
Каждое имя столбца в списке уникальности должно именовать столбец T
и не должно входить в этот список более одного раза. При определении
столбца, входящего в список уникальности, должно быть указано огранич ение
столбца NO NULL. Среди ограничений уникальности T не должно быть более
одного определения первичного ключа (ограничения уникальности с ключевым
словом RIMARY KEY).
Действие ограничения уникальности состоит в том, что в таблице T не
допускается появление двух или более строк, значения столбцов уникальности
которых совпадают.
Ограничение по ссылкам
Ограничение по ссылкам от заданного набора столбцов CT таблицы T на
заданный набор столбцов CT1 некоторой определенной к этому моменту
таблицы T1 определяет условие на содержимое обеих этих таблиц, при котором
ссылки можно считать корректными.
Если список столбцов CT1 явно специфицирован в определении
ограничения по ссылкам, то требуется, чтобы этот список явно входил в какоелибо определение уникальности таблицы T1. Если же список CT1 не
специфицирован явно в определении ограничения по ссылкам таблицы T, то
требуется, чтобы в определении таблицы T1 присутствовало определение
первичного ключа, и список CT1 неявно полагается совпадающим со списком
имен столбцов из определения первичного ключа таблицы T1. Имена столбцов
списков CT и CT1 должны именовать столбцы таблиц T и T1 соответс твенно и
не должны появляться в списках более одного раза. Списки столбцов CT и CT1
должны содержать одинаковое число элементов, и столбец таблицы T,
идентифицируемый i-м элементом списка CT, должен иметь тот же тип, что и
столбец таблицы T1, идентифицируемый i-м элементом списка CT1.
Ограничение по ссылкам удовлетворяется, если для каждой корректной
ссылки существует объект, на который она ссылается.
Проверочное ограничение
Проверочное ограничение специфицирует условие, которому должна
удовлетворять в отдельности каждая строка таблицы T. Это условие не должно
содержать подзапросов, спецификаций агрегатных функций, а также ссылок на
внешние переменные или параметров. В него могут входить только имена
столбцов данной таблицы и литеральные константы.
116
Таблица удовлетворяет проверочному ограничению целостности в том и
только в том случае, когда вычисление условия для каждой строки таблицы
дает true.
8.2.3. Определение представлений
Механизм представлений (view) является мощным средством языка SQL,
позволяющим скрыть реальную структуру БД от некоторых пользователей за
счет определения представления БД, которое реально является некоторым
хранимым в БД запросом с именованными столбцами, а для пользователя
ничем не отличается от базовой таблицы БД (с учетом технических
ограничений). Любая реализация должна гарантировать, что состояние
представляемой таблицы точно соответствует состоянию базовых таблиц, на
которых определено представление. Обычно вычисление представляемой
таблицы (материализация соответствующего запроса) производится каждый раз
при использовании представления.
Оператор определения представления имеет следующий синтаксис:
<определение представления> ::=
CREATE VIEW <имя таблицы> [(<список столбцов представления>)]
AS <спецификация запроса> [WITH CHECK OPTION]
<список столбцов представления> ::= <имя столбца>[{,<имя столбца>}...]
Определяемая представляемая таблица V является изменяемой (т.е. по
отношению к V можно использовать операторы DELETE и UPDATE) в том и
только в том случае, если выполняются следующие условия для спецификации
запроса:
•в списке выборки не указано ключевое слово DISTINCT;
•каждое арифметическое выражение в списке выборки представляет
собой одну спецификацию столбца, и спецификация одного столбца не
появляется более одного раза;
•в разделе FROM указана только одна таблица, являющаяся либо базовой
таблицей, либо изменяемой представляемой таблицей;
•в условии выборки раздела WHERE не используются подзапросы;
•в табличном выражении отсутствуют разделы GROUP BY и HAVING.
Если в списке выборки спецификации запроса имеется хотя бы одно
арифметическое выражение, состоящее не из одной спецификации столбца, или
если одно имя столбца участвует в списке выборки более одного раза,
определение представления должно содержать список имен столбцов
представляемой таблицы. Проще говоря, нужно явно именовать столбцы
представляемой таблицы, если эти имена не наследуются от столбцов таблиц
раздела FROM спецификации запроса.
Требование WITH CHECK OPTION в определении представления имеет
смысл только в случае определения изменяемой представляемой таблицы,
которая определяется спецификацией запроса, содержащей раздел WHERE.
При наличии этого требования не допускаются изменения представляемой
117
таблицы, которые приводят к появлению в базовых таблицах строк, не видимых
в представляемой таблице (т.е. таких строк, которые не удовлетворяют условию
поиска раздела WHERE спецификации запроса). Если WITH CHECK OPTION в
определении представления отсутствует, такой контроль не производится.
Оператор удаления представления имеет формат вида:
DROP VIEW <имя представления>.
Оператор позволяет удалить созданное ранее представление. При удалении
представления таблицы участвующие в запросе удалению не подлежат.
8.3. Структура запросов
Сводка синтаксических правил:
<спецификация курсора> ::=
<выражение запросов> [<order by раздел>]
<выражение запросов> ::=
< терм запроса>
| <выражение запросов> UNION [ALL] <терм запроса>
<терм запроса> ::=
<спецификация запроса>
| (<выражение запросов>)
< спецификация запроса> ::=
(SELECT [ALL | DISTINCT] <список выборки> <табличное выражение>)
<оператор выборки> ::=
SELECT [ALL | DISTINCT] <список выборки>
INTO <список переменных ПП> <табличное выражение>
<подзапрос> ::=
(SELECT [ALL | DISTINCT] <выражение, вычисляющее значение>
<табличное выражение>
<табличное выражение> ::=
<from раздел>
[<where раздел>]
[<group by раздел>]
[<having раздел>]
Язык допускает три типа синтаксических конструкций, начинающихся с
ключевого слова SELECT: спецификация, оператор выборки и подзапрос. Их
основой является синтаксическая конструкция «табличное выражение».
Семантика табличного выражения состоит в том, что на основе
последовательного применения разделов from, where, group by и having из
заданных в разделе from таблиц строится некоторая новая результирующая
таблица, порядок следования строк которой не определен и среди строк
которой могут находиться дубликаты (т.е. в общем случае таблица-результат
табличного выражения является мультимножеством строк).
118
8.3.1. Спецификация курсора
Курсор – это понятие языка SQL, позволяющее с помощью набора
специальных операторов получить построчный доступ к результату запроса к
БД. К табличным выражениям, участвующим в спецификации курсора, не
предъявляются какие-либо ограничения. При определении спецификации
курсора используются три дополнительных конструкции: спецификация
запроса, выражение запросов и раздел ORDER BY.
Спецификация запроса
В спецификации запроса задается список выборки (список
арифметических выражений над значениями столбцов результата табличного
выражения и констант). В результате применения списка выборки к результату
табличного выражения производится построение новой таблицы, содержащей
то же число строк, но другое число столбцов, содержащих результаты
вычисления соответствующих арифметических выражений из списка выборки.
В спецификации запроса могут содержаться ключевые слова ALL или
DISTINCT. При наличии ключевого слова DISTINCT из таблицы, полученной
применением списка выборки к результату табличного выражения, удаляются
строки-дубликаты; при указании ALL (или просто при отсутствии DISTINCT)
удаление строк-дубликатов не производится.
Выражение запросов
Выражение запросов - это выражение, строящееся по указанным
синтаксическим правилам на основе спецификаций запросов. В выражениях
запросов может использоваться операция UNION (объединение таблиц) с
возможной разновидностью UNION ALL. Таблицы-операнды выражения
запросов должны содержать одно и то же число столбцов, и соответствующие
столбцы всех операндов должны быть одного и того же типа. Выражение
запросов вычисляется слева направо с учетом скобок. При выполнении
операции UNION производится обычное теоретико-множественное
объединение операндов, т.е. из результирующей таблицы удаляются
дубликаты. При выполнении операции UNION ALL образуется
результирующая таблица, в которой могут содержаться строки-дубликаты.
Раздел ORDER BY
Раздел ORDER BY позволяет установить желаемый порядок просмотра
результата выражения запросов. Синтаксис ORDER BY следующий:
<order by раздел> ::=
ORDER BY <спецификация сортировки>
[{,<спецификация сортировки>}...]
<спецификация сортировки> ::=
{<порядковый номер столбца> | <спецификация столбца>}
[ASC | DESC]
Задается список столбцов результата выражения запросов, и для каждого
столбца указывается порядок просмотра строк результата в зависимости от
значений этого столбца (ASC – по возрастанию (умолчание), DESC – по
119
убыванию). Столбцы можно задавать их именами в том и только в том случае,
когда (1) выражение запросов не содержит операций UNION или UNION ALL и
(2) в списке выборки спецификации запроса этому столбцу соответствует
арифметическое выражение, состоящее только из имени столбца. Во всех
остальных случаях в разделе ORDER BY должен указываться порядковый
номер столбца в таблице-результате выражения запросов.
8.3.2. Оператор выборки
Оператор выборки позволяет получить результат запроса в прикладной
программе без привлечения курсора. Раздел INTO содержит список
переменных прикладной программы, в которые будет помещен результат.
Ограничением является то, что результирующая таблица должна содержать не
более одной строки. Соответственно, результат базового табличного выражения
должен содержать не более одной строки, если оператор выборки не содержит
спецификации DISTINCT, и не должен содержать более одной несовпадающей
строки, если спецификация DISTINCT задана.
8.3.3. Подзапрос
Подзапрос – это запрос, который может входить в предикат условия
выборки оператора SQL. К подзапросам применяется то ограничение, что
результирующая таблица должна содержать в точности один столбец.
Поскольку подзапрос всегда вложен в некоторый другой оператор SQL, то в
качестве констант в арифметическом выражении выборки и логических
выражениях разделов WHERE и HAVING можно использовать значения
столбцов текущих строк таблиц, участвующих в (под) запросах более внешнего
уровня.
8.3.4 Табличное выражение
Вычисление
табличного
выражения
рассматривается
как
последовательное применение разделов FROM, WHERE, GROUP BY и
HAVING к таблицам, заданным в списке FROM.
Раздел FROM
Раздел FROM имеет следующий синтаксис:
<from раздел> ::=
FROM <ссылка таблицы>
({,<ссылка таблицы>}...]
<ссылка таблицы> ::=
<имя таблицы> [<связанное имя>]
Результатом выполнения раздела FROM является расширенное декартово
произведение таблиц, заданных списком таблиц раздела FROM.
Связанное имя – это некоторый синоним имени таблицы, который можно
использовать в других разделах табличного выражения для ссылки на строки
именно этого вхождения таблицы.
Раздел WHERE
Синтаксис раздела WHERE следующий:
<where раздел> ::= WHERE <условие поиска>
120
Условие поиска содержит предикаты, связанные булевскими операциями
AND, OR, NOT. Вычисление раздела WHERE производится по следующим
правилам: пусть R – результат вычисления раздела FROM. Тогда условие
поиска применяется ко всем строкам R и результатом раздела WHERE является
таблица, состоящая из тех строк R, для которых результатом вычисления
условия поиска является true. Если условие выборки включает подзапросы, то
каждый подзапрос вычисляется для каждого кортежа таблицы R.
Поскольку SQL допускает наличие в базе данных неопределенных
значений, то вычисление условия поиска производится не в булевой, а в
трехзначной логике со значениями true, false и unknown (неизвестно). Булевские
операции AND, OR и NOT работают в трехзначной логике следующим образом:
true AND unknown = unknown
unknown AND true = unknown
unknown AND unknown = unknown
true OR unknown = true
unknown OR true = true
unknown OR unknown = unknown
NOT unknown = unknown
Среди предикатов условия поиска могут находиться следующие
предикаты: предикат сравнения, предикат between, предикат in, предикат like,
предикат null, предикат с квантором и предикат exists.
Предикат сравнения
Синтаксис предиката сравнения определяется следующими правилами:
<предикат сравнения> ::=
<значение выражения> <операция>
{<значение выражения> | <подзапрос>}
<операция> ::=
= | <> | < | > | <= | >=
Арифметические выражения левой и правой частей предиката сравнения
строятся по общим правилам построения арифметических выражений и могут
включать в общем случае имена столбцов таблиц из раздела FROM и константы.
Типы данных арифметических выражений должны быть сравнимыми.
Если правый операнд операции сравнения задается подзапросом, то
мощность результата подзапроса должна быть не более единицы. Если хотя бы
один из операндов операции сравнения имеет неопределенное значение или
если правый операнд является подзапросом с пустым результатом, то значение
предиката сравнения равно unknown.
Предикат between
Предикат between имеет следующий синтаксис:
<between предикат> ::=
<значение выражения>
[NOT] BETWEEN <значение выражения> AND <значение выражения>
121
Результат "x BETWEEN y AND z" тот же самый, что результат "x >= y
AND x <= z". Результат "x NOT BETWEEN y AND z" тот же самый, что
результат "NOT (x BETWEEN y AND z)".
Предикат in
Предикат in определяется следующими синтаксическими правилами:
<in предикат> ::=
<значение выражения> [NOT] IN
{<подзапрос> | (<список значений>)}
<список значений> ::=
<спецификация значения>
{,<спецификация значения>}...
Типы левого операнда и значений из списка правого операнда должны
быть сравнимыми.
Значение предиката равно true в том и только в том случае, когда значение
левого операнда совпадает хотя бы с одним значением списка правого операнда.
Значение предиката "x NOT IN S" равно значению предиката "NOT (x IN S)".
Предикат like
Предикат like имеет следующий синтаксис:
<like предикат> ::=
<спецификация столбца> [NOT] LIKE <образец>
[ESCAPE <escape символ>]
<образец> ::= <спецификация значения>
<escape символ> ::= < спецификация значения>
Типы данных столбца левого операнда и образца должны быть типами
символьных строк. В разделе ESCAPE должен специфицироваться одино чный
символ.
Значение предиката равно true, если шаблон является подстрокой
заданного столбца. При этом если раздел ESCAPE отсутствует, то при
сопоставлении шаблона со строкой производится специальная интерпретация
двух символов шаблона: символ подчеркивания ("_") обозначает любой
одиночный символ; символ процента ("%") обозначает последовательность
произвольных символов произвольной длины (может быть нулевой).
Если же раздел ESCAPE присутствует и специфицирует некоторый
одиночный символ x, то пары символов "x_" и "x%" представляют одино чные
символы "_" и "%" соответственно.
Значение предиката like есть unknown, если значение столбца либо
шаблона не определено.
Значение предиката "x NOT LIKE y ESCAPE z" совпадает со значением
"NOT x LIKE y ESCAPE z".
Предикат null
Предикат null описывается синтаксическим правилом:
<null предикат> ::=
<спецификация столбца> IS [NOT] NULL
122
Этот предикат всегда принимает значения true или false. При этом значение
"x IS NULL" равно true тогда и только тогда, когда значение x не определено.
Значение предиката "x NOT IS NULL" равно значению "NOT x IS NULL".
Предикат с квантором
Предикат с квантором имеет следующий синтаксис:
<предикат с квантором> ::=
<значение выражения> <операция> <квантор> <подзапрос>
<квантор> ::=
<все> | <какой-нибудь>
<все> ::= ALL
<какой-нибудь> ::= SOME | ANY
Обозначим через x результат вычисления арифметического выражения
левой части предиката, а через S результат вычисления подзапроса.
Предикат "x <операция> ALL S" имеет значение true, если S пусто или
значение предиката "x <операция> s" равно true для каждого s, входящего в S.
Предикат "x <операция> ALL S" имеет значение false, если значение предиката
"x <операция> s" равно false хотя бы для одного s, входящего в S. В остальных
случаях значение предиката "x <операция> ALL S" равно unknown.
Предикат "x <операция> SOME S" имеет значение false, если S пусто или
значение предиката "x <операция> s" равно false для каждого s, входящего в S.
Предикат "x <операция> SOME S" имеет значение true, если значение
предиката "x <операция> s" равно true хотя бы для одного s, входящего в S. В
остальных случаях значение предиката "x <операция> SOME S" равно unknown.
Предикат exists
Предикат exists имеет следующий синтаксис:
<exists предикат> ::=
EXISTS <подзапрос>
Значение предиката равно true тогда и только тогда, когда результат
вычисления подзапроса не пуст, в противном случае - false.
Раздел GROUP BY
Синтаксис раздела GROUP BY следующий:
<group by раздел> ::=
GROUP BY <спецификация столбца>
[{,<спецификация столбца>}...]
Если обозначить через R таблицу, являющуюся результатом
предыдущего раздела (FROM или WHERE), то результатом раздела GROUP BY
является разбиение R на множество групп строк, состоящее из минимального
числа групп, таких что для каждого столбца из списка столбцов раздела
GROUP BY во всех строках каждой группы, включающей более одной строки,
значения этого столбца равны.
Раздел HAVING
Последним при вычислении табличного выражения используется раздел
HAVING (если он присутствует). Синтаксис этого раздела следующий:
123
<having раздел> ::=
HAVING <условие поиска>
Раздел HAVING может быть осмыслен в табличном выражении только в
том случае, когда в нем присутствует раздел GROUP BY. Условие поиска этого
раздела задает условие на группу строк сгруппированной таблицы.
Поэтому в арифметических выражениях предикатов, входящих в условие
выборки раздела HAVING, прямо можно использовать только спецификации
столбцов, указанных в качестве столбцов группирования в разделе GROUP BY.
Остальные столбцы можно специфицировать только внутри спецификаций
агрегатных функций COUNT, SUM, AVG, MIN и MAX, вычисляющих в
данном случае некоторое агрегатное значение для всей группы строк.
Аналогично обстоит дело с подзапросами, входящими в предикаты условия
выборки раздела HAVING: если в подзапросе используется характеристика
текущей группы, то она может задаваться только путем ссылки на столбцы
группирования.
Результатом выполнения раздела HAVING является сгруппированная
таблица, содержащая только те группы строк, для которых результат
вычисления условия поиска есть true.
8.4. Агрегатные функции и результаты запросов
Агрегатные функции определяются следующими синтаксическими
правилами:
<спецификация агрегатной функции> ::=
COUNT | <distinct агрегатная функция>
| <all агрегатная функция>
<distinct агрегатная функция> ::=
{ AVG | MAX | MIN | SUM | COUNT }
(DISTNICT <спецификация столбца>)
<all агрегатная функция> ::=
{ AVG | MAX | MIN | SUM } ([ALL] <значение выражения>)
В SQL определены пять стандартных агрегатных функций: COUNT число строк или значений, MAX - максимальное значение, MIN - минимальное
значение, SUM - суммарное значение и AVG - среднее значение.
Агрегатные функции предназначены для того, чтобы вычислять
некоторое значение для заданного множества строк. Таким множеством строк
может быть группа строк, если агрегатная функция применяется к
сгруппированной таблице, или вся таблица. Для всех агрегатных функций,
кроме COUNT, фактический (т.е. требуемый семантикой) порядок вычислений
следующий: на основании параметров агрегатной функции из заданного
множества строк производится список значений. Затем по этому с писку
значений производится вычисление функции. Если список оказался пустым, то
124
значение функции COUNT для него есть 0, а значение всех остальных функций null.
Пусть T обозначает тип значений из этого списка. Тогда результат
вычисления функции COUNT - точное число с масштабом и точностью,
определяемыми в реализации. Тип результата значений функций MAX и MIN
совпадает с T. При вычислении функций SUM и AVG тип T не должен быть
типом символьных строк, а тип результата функции - это тип точных чисел с
определяемыми в реализации масштабом и точностью, если T - тип точных
чисел, и тип приблизительных чисел с определяемой в реализации точностью,
если T - тип приблизительных чисел.
Вычисление функции COUNT производится путем подсчета числа строк
в заданном множестве. Все строки считаются различными, даже если они
состоят из одного столбца со значением null во всех строках.
Если агрегатная функция специфицирована с ключевым словом
DISTINCT, то список значений строится из значений указанного столбца. (В
этом случае не допускается вычисление арифметических выражений!) Далее из
этого списка удаляются неопределенные значения и устраняются значениядубликаты. Затем вычисляется указанная функция.
Если агрегатная функция специфицирована без ключевого слова
DISTINCT (или с ключевым словом ALL), то список значений формируется из
значений арифметического выражения, вычисляемого для каждой строки
заданного множества. Далее из списка удаляются неопределенные значения и
производится вычисление агрегатной функции. В этом случае не допускается
применение функции COUNT!
Агрегатные функции можно разумно использовать в спецификации
курсора, операторе выборки и подзапросе после ключевого слова SELECT и в
условии выборки раздела HAVING. Стандарт допускает более экзотическое
использование агрегатных функций в подзапросах (агрегатная функция на
группе кортежей внешнего запроса), но на практике они встречаются очень
редко.
Возможны различные случаи применения агрегатных функций в списке
выборки в зависимости от вида табличного выражения.
Если результат табличного выражения R не является сгруппированной
таблицей, то появление хотя бы одной агрегатной функции от множества строк
R в списке выборки приводит к тому, что R неявно рассматривается как
сгруппированная таблица, состоящая из одной (или нуля) группы с
отсутствующими столбцами группирования. Поэтому в этом случае в списке
выборки не допускается прямое использование спецификаций строк R: все они
должны находиться внутри спецификаций агрегатных функций. Результатом
запроса является таблица, состоящая не более чем из одной строки, полученной
путем применения агрегатных функций к R.
Аналогично обстоит дело в том случае, когда R представляет собой
сгруппированную таблицу, но табличное выражение не содержит раздела
125
GROUP BY (и следовательно, содержит раздел HAVING). Если в случае
предыдущего абзаца было два варианта формирования списка выборки (только
с прямым указанием столбцов R или только с указанием их внутри
спецификаций агрегатных функций), то в данном случае возможен только
второй вариант. Результат табличного выражения явно объявлен
сгруппированной таблицей, состоящей из одной группы, и результат запроса
можно формировать только путем применения агрегатных функций к этой
группе строк. Опять результатом запроса является таблица, состоящая не более
чем из одной строки, полученной путем применения агрегатных функций к R.
В случае, когда R представляет собой "настоящую" сгруппированную
таблицу, т.е. табличное выражение содержит раздел GROUP BY и,
следовательно, определен, по крайней мере, один столбец группирования,
правила формирования списка выборки полностью соответствуют правилам
формирования условия выборки раздела HAVING. Допускается прямое
использование спецификации столбцов группирования, а спецификации
остальных столбцов R могут появляться только внутри спецификаций
агрегатных функций. Результатом запроса является таблица, число строк в
которой равно числу групп в R, и каждая строка формируется на основе
значений столбцов группирования и агрегатных функций для данной группы.
8.5. Операторы обновления
К операторам обновления относятся операторы изменения, вставки и
удаления записей.
Оператор изменения записей
UPDATE <имя таблицы>
SET <имя столбца> = {<выражение> , NULL}
[, SET <имя столбца> = {<выражение> , NULL}... ]
[WHERE <условие>]
Выполнение оператора UPDATE состоит в изменении значений в
определенных операндом SET столбцах таблицы для тех записей, которые
удовлетворяют условию, заданному операндом WHERE.
Новые значения полей в записях могут быть пустыми (NULL) либо
вычисляться в соответствии с арифметическим выражением. Правила записи
арифметических и логических выражений аналогичны соответствующим
правилам оператора SELECT.
Оператор вставки новых записей имеет форматы двух видов:
INSERT INTO <имя таблицы>
[(<список столбцов>)]
VALUES (<список значений>)
и
INSERT INTO <имя таблицы>
| [(<список столбцов>)]
126
<предложение SELECT>
В первом формате оператор INSERT предназначен для ввода новых
записей с заданными значениями в столбцах. Порядок перечисления имен
столбцов должен соответствовать порядку значений, перечисленных в списке
операнда VALUES. Если <список столбцов> опущен, то в <списке значений>
должны быть перечислены все значения в порядке столбцов структуры
таблицы. Во втором формате оператор INSERT предназначен для ввода в
заданную таблицу новых строк, отобранных из другой таблицы с помощью
предложения SELECT.
Оператор удаления записей
DELETE FROM <имя таблицы> [WHERE <условие>]
Результатом выполнения оператора DELETE является удаление из
указанной таблицы строк, которые удовлетворяют условию, определенному
операндом WHERE. Если необязательный операнд WHERE опущен, т. е.
условие отбора удаляемых записей отсутствует, удалению подлежат все записи
таблицы.
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Опишите функции и основные возможности языка реляционных баз
данных SQL.
2. Перечислите основные операторы языка SQL.
3. Какие операторы SQL можно отнести к средствам определения схемы
БД?
4. Какой синтаксис имеет оператор определения таблицы, из каких
разделов он состоит?
5. Опишите операторы изменения структуры и удаления таблицы.
6. Каким образом задаются ограничения целостности для таблицы?
7. Что представляют собой ограничение уникальности, ограничение по
ссылкам, проверочное ограничение?
8. Каким образом в SQL определяются и удаляются внешние
представления?
9. Опишите структуру запроса SQL.
10. Чем отличается спецификация запроса, оператор выборки и
подзапрос?
11. Что представляет собой спецификация курсора?
12. Что такое табличное выражение, из каких разделов оно состоит?
13. Перечислите предикаты, используемые в табличном выражении,
опишите их синтаксис.
14. Для чего предназначены агрегатные функции?
15. Опишите синтаксис операторов обновления.
127
9. ВНУТРЕННЯЯ ОРГАНИЗАЦИЯ РЕЛЯЦИОННЫХ СУБД
Существуют следующие разновидности объектов во внешней памяти
базы данных:
1) строки отношений - основная часть базы данных, большей частью
непосредственно видимая пользователем;
2) управляющие структуры - индексы, создаваемые для повышения
эффективности выполнения запросов;
3) журнальная информация, поддерживаемая для удовлетворения
потребности в надежном хранении данных;
4) служебная информация, поддерживаемая для удовлетворения
внутренних потребностей системы (например, информация о свободной
памяти).
9.1. Хранение отношений
Существуют два принципиальных подхода к физическому хранению
отношений: покортежное и хранение отношения по столбцам.
При покортежном хранении отношений кортеж является единицей
физического хранения. Это обеспечивает быстрый доступ к целому кортежу, но
при этом во внешней памяти дублируются общие значения разных кортежей
одного отношения и могут потребоваться лишние обмены с внешней памятью,
если нужна часть кортежа.
При хранении отношения по столбцам единицей хранения является
столбец отношения с исключенными дубликатами. При такой организации
суммарно в среднем тратится меньше внешней памяти, поскольку дубликаты
значений не хранятся; за один обмен с внешней памятью в общем случае
считывается больше полезной информации. Дополнительным преимущес твом
является возможность использования значений столбца отношения для
оптимизации выполнения операций соединения. Но при этом требуются
существенные дополнительные действия для сборки целого кортежа (или его
части). Наиболее распространено покортежное хранение отношений.
Наиболее простой формой хранения кортежей в памяти ЭВМ является
одномерный линейный список. Линейный список X рассматривают как
последовательность X[1], X[2], ..., X[i], ..., X[n], компоненты которой
идентифицированы порядковым номером, указывающим их относительное
расположение в X.
Отображение логической структуры данных на физическую структуру
хранения называют адресной функцией. При реализации адресной функции
используют два основных метода: последовательное и связанное распределение
памяти.
128
При последовательном распределении памяти вектор данных логически
отделен от описания структуры хранимых данных. Описание структуры
хранится в отдельной записи и содержит:
N - размер вектора данных, т.е. число кортежей;
m - размер элемента списка, т.е. размер кортежа;
- адрес базы, указывающий на начало вектора данных в памяти.
В этом случае адрес каждого кортежа можно вычислить с помощью
адресной функции (рис. 9.1).
(i)= +(i-1)m
А
Содержимое
дрес
(1) =
y1
(2) = +m
y2
.
.
.
(i) = +(i-1)m
yi
.
.
(n) = +(n-1)m
yn
Рис. 9.1. Пример последовательного распределения памяти
для представления линейного списка
При связанном распределении памяти для построения структуры
необходимо задать отношения следования и предшествования элементов с
помощью указателей. Указателями служат адреса, хранимые в записях данных
(рис. 9.2).
Для достижения большей гибкости при работе с линейными списками в
каждый узел X[i] вводится два указателя. Один реализует связь
рассматриваемого узла с узлом X[i+1], а другой - с узлом X[i-1] (рис. 9.3).
Такой метод распределения памяти позволяет расширить либо сократить
структуру без перемещения самих данных в памяти ЭВМ, однако при этом
требуется больше памяти для хранения структуры по сравнению с
последовательным распределением. Значение адресной функции можно
получить только путем просмотра хранящихся указателей, а это ведет к
увеличению времени поиска.
129
а)
б)
y1
y2
y1
y2
y3
y4
y3
y4
y2А
y5
Рис. 9.2. Примеры связанных линейных списков:
а – однонаправленный список;
б – тот же список после удаления узла 4 и включения узлов 2а и 5
y1
y3
y2
y4
y7
y8
y5
y6
Рис. 9.3. Пример двунаправленного линейного списка
Этот недостаток можно устранить различными способами. Одним из
способов является организация связанного списка с пропусками (рис. 9.4, а).
Для этого линейный список делится на группы узлов, связанные между собой
обратными указателями. Вначале осуществляется доступ по обратным
указателям к группе, в которой находится требуемый узел, а затем по прямым
указателям перебираются узлы группы, пока не будет найден требуемый узел.
Вход в список при таком способе организации начинается с конца.
Другой способ заключается в построении специального дополнительного
линейного списка – индекса, например, с последовательным распределением
памяти. Элементы индекса – значения первых узлов каждой группы и указатели
на них (рис. 9.4, б).
130
а)
y1
y2
y3
y4
y5
y6
y7
y8
y9
Индекс
б)
y1
y4
y7
y1
y2
y3
y4
y5
y6
y7
y8
y9
Рис. 9.4. Примеры реализации способов ускорения доступа
к узлам линейного списка:
а – организация линейного списка с пропусками;
б – организация линейного списка с использованием индекса
Важной разновидностью представления в памяти линейного списка
является циклический список. Циклически связанный список обладает той
особенностью, что связь от последнего узла идет к первому узлу списка.
Циклический список позволяет получить доступ к любому узлу списка,
отправляясь от любого заданного узла.
Таким образом, основой построения связанных списковых структур
являются указатели. При практической реализации на ЭВМ используются три
типа указателей:
1. Действительный адрес – используется тогда, когда необходимо
получить наибольшую скорость обработки данных, организованных в
связанные списковые структуры. Недостаток – жесткая привязка записей к
конкретному месту расположения в памяти.
2. Относительный адрес – позволяет размещать записи в любом месте
памяти и на различных внешних устройствах без изменения значений
указателей, при этом относительное расположение в памяти узлов списка
между собой должно быть постоянным. При перемещении списка указатели в
записях не изменяются, а изменяется базовый адрес при вычислении
действительных машинных адресов. Относительные адреса в качестве
указателей применяются при страничной организации памяти. Скорость
доступа к узлам несколько замедляется по сравнению со случаем машинных
адресов, однако появляется возможность размещать список в любом свободном
месте памяти подходящего размера.
131
3. Символический адрес (идентификатор) - позволяет перемещать
отдельные записи относительно друг друга, включать или удалять записи в
список без изменения указателей во всех остальных записях списка. Однако
скорость доступа меньше, чем в первых двух случаях.
При реализации процедур поиска данных необходимо определить адрес
записи по значению ключа. Для вычисления адреса чаще всего использ уется
метод хеширования. Основная идея хеш-адресации заключается в том, что
каждый экземпляр хранимой записи размещается в памяти по адресу,
вычисляемому с помощью некоторой адресной функции – хеш-функции – по
значению первичного ключа.
Хеш-функция h имеет не более M различных значений и удовлетворяет
условию: 0 h(k)<M для всех k K, т.е. для всего множества ключа, и
однозначно определяет M по значению k.
В случае необходимости не обязательно организовывать записи в
соответствии со значениями первичного ключа. Формально можно выполнять
организацию записей по значениям любого из полей, входящих в состав записи.
Недостатки хеш-адресации: хранимая структура является неупорядоченной по
значению первичного ключа; возможность коллизий (ситуаций, когда для двух
различных записей вычисляется один и тот же адрес памяти для хранения).
9.2. Индексы
Основное назначение индексов состоит в обеспечении эффективного
прямого доступа к кортежу отношения по ключу и последовательный просмотр
в порядке возрастания или убывания значений ключа. Обычно индекс
определяется для одного отношения и ключом является значение атрибута
(возможно, составного). Если ключом индекса является возможный ключ
отношения, то индекс должен обладать свойством уникальности, т.е. не
содержать дубликатов ключа.
Общей идеей любой организации индекса является хранение
упорядоченного списка значений ключа с привязкой к каждому значению
ключа списка идентификаторов кортежей. Различные способы организации
индекса отличаются друг от друга, главным образом, способом поиска ключа с
заданным значением.
Наиболее популярным подходом к организации индексов в базах данных
является использование техники бинарных деревьев (B-деревьев).
В-деревья можно построить на основе неплотных или плотных индексов.
Пусть основной файл F упорядочен по полю ключа K. Построим
дополнительный файл FD (рис. 9.5) по правилу: 1) записи файла FD имеют
формат FD(K,P), где K - поле, принимаемое значение ключа первой записи
блока основного файла F; P - указатель на этот блок; 2) записи файла FD
упорядочены по полю K.
132
Файл FD
Основная область
K
Блок 1
Основная область
P
K
5
5
45
Блок 3 19
Файл FD
Область переполнения
A1 … An
K
A1 … An
Блок 7 27
40
61
73
45
Блок 4 50
Блок 2
98
100
81
215
Блок 8
100
Блок 5 110
211
215
Блок 6
Рис. 9.5. Пример неплотного индекса
Полученный файл FD называется неплотным индексом. Количество
записей файла FD равно количеству блоков основного файла F.
133
В- дерево
3-й уровень
2-й уровень
1-й уровень
K
P
Файл F
Основная
область
K A1 … An
5
овень
5
Блок 8
27
K
19
P
5
45
Блок 4
Блок 9
27
40
45
Блок 2
K
45
61
Блок 10
P
50
5
81
Блок 5
61
Блок 11
73
81
Блок 1
100
81
Блок 12
98
81
211
Блок 6
100
Блок 13
110
211
Блок 3
227
Блок 14
211
215
Блок 7
227
Блок 15
Рис. 9.6. Пример структуры типа B-дерево
134
Поиск вначале выполняется в индексе для нахождения адреса блока
основного файла, а затем этот блок считывается в оперативную память и в нем,
например, с помощью последовательного поиска определяется требуемая
запись.
Так как неплотный индекс упорядочен по ключевому полю, то над ним
можно построить еще один неплотный индекс и т.д., пока на самом последнем,
верхнем уровне не останется всего один блок (рис. 9.6). Полученная структура
называется B-деревом порядка m, где m - количество записей в блоке индекса.
Такое дерево должно иметь в каждом узле не менее m/2 зависимых узлов, и все
листья должны располагаться на одном уровне.
Поиск в В-дереве осуществляется так же, как и в неплотном индексе. При
поиске по интервалу a K b вначале выполняется поиск по K=a в B-дереве, а
затем – последовательный поиск по условию K b в блоках первого уровня Bдерева.
Плотный индекс строится почти так же, как и неплотный индекс.
Различие заключается в том, что для каждого значения ключа К в файле FD
имеется отдельная запись, а в неплотном индексе – только для значения ключа
первой записи блока. Над плотным индексом также можно построить B-дерево.
9.3. Журнальная информация
Одним из основных требований к развитым СУБД является надежность
хранения баз данных. Это требование предполагает, в частности, возмо жность
восстановления согласованного состояния базы данных после любого рода
аппаратных и программных сбоев. Для выполнения восстановления
необходима некоторая дополнительная информация, которая в большинстве
современных реляционных СУБД поддерживается в виде журнала изменений
базы данных.
Целью журнализации изменений баз данных является обеспечение
возможности восстановления согласованного состояния базы данных после
любого сбоя. Поскольку основой поддержания целостного состояния базы
данных является механизм транзакций, журнализация и восстановление тесно
связаны с понятием транзакции. Общими принципами восстановления
являются следующие:
• результаты зафиксированных транзакций должны быть сохранены в
восстановленном состоянии базы данных;
• результаты незафиксированных транзакций должны отсутствовать в
восстановленном состоянии базы данных.
Это означает, что восстанавливается последнее по времени согласованное
состояние базы данных.
Возможны следующие ситуации, при которых требуется производить
восстановление состояния базы данных:
• индивидуальный откат транзакции;
135
• восстановление после внезапной потери содержимого оперативной
памяти (мягкий сбой);
• восстановление после поломки основного внешнего носителя базы
данных (жесткий сбой).
Во всех трех случаях основой восстановления является избыточное
хранение данных. Эти избыточные данные хранятся в журнале, содержащем
последовательность записей об изменении базы данных.
Возможны два основных варианта ведения журнальной информации. В
первом варианте для каждой транзакции поддерживается отдельный локальный
журнал изменений базы данных этой транзакцией. Эти локальные журналы
используются для индивидуальных откатов транзакций и могут
поддерживаться в оперативной памяти. Кроме того, поддерживается общий
журнал изменений базы данных, используемый для восстановления состо яния
базы данных после мягких и жестких сбоев.
Этот подход позволяет быстро выполнять индивидуальные откаты
транзакций, но приводит к дублированию информации в локальных и общем
журналах. Поэтому чаще используется второй вариант - поддержание только
общего журнала изменений базы данных, который используется и при
выполнении индивидуальных откатов.
9.4. Служебная информация
Для корректной работы подсистемы управления данными во внешней
памяти необходимо поддерживать информацию, которая используется только
этой подсистемой и не видна подсистеме языкового уровня. Набор структур
служебной информации зависит от общей организации системы, но обычно
требуется поддержание следующих служебных данных:
• внутренних каталогов, описывающих физические свойства объектов
базы данных, например, число атрибутов отношения, их размер и, возможно,
типы данных; описание индексов, определенных для данного отношения и т.д;
• описателое свободной и занятой памяти в страницах отношения. Такая
информация требуется для нахождения свободного места при занесении
кортежа;
• связывания страниц одного отношения. Если в одном файле внешней
памяти могут располагаться страницы нескольких отношений (обычно к этому
стремятся), то нужно каким-то образом связать страницы одного отношения.
Тривиальный способ использования прямых ссылок между страницами часто
приводит к затруднениям при синхронизации транзакций (например, особенно
трудно освобождать и заводить новые страницы отношения). Поэтому
стараются использовать косвенное связывание страниц с использованием
служебных индексов. В частности, известен общий механизм для описания
свободной памяти и связывания страниц на основе B-деревьев.
136
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Какие разновидности объектов существуют во внешней памяти базы
данных?
2. Чем отличается покортежное хранение отношений от хранения
отношения по столбцам?
3. Дайте определение одномерного линейного списка и адресной функции.
4. Какие методы существуют при реализации адресной функции?
5. В чем заключается последовательное распределение памяти?
6. Какие существуют варианты реализации связанного распределения
памяти?
7. Приведите примеры связанных линейных списков и двунаправленных
линейных списков.
8. Какие типы указателей используются при практической реализации
списковых структур?
9. Дайте определение хеш-функции. В чем заключается метод хеширования?
10. Для чего предназначены индексы?
11. Приведите пример организации индексов на основе B-деревьев.
12. Каким образом осуществляется построение неплотного индекса?
Приведите пример.
13. Чем отличаются плотный и неплотный индексы?
14. Каким образом осуществляется поиск в B-дереве?
15. Что представляет собой системный журнал БД, каково его назначение?
16. Какая служебная информация должна храниться в БД?
137
10. НАСТОЛЬНЫЕ СУБД
10.1. Общие сведения о настольных СУБД
Настольные СУБД как таковые не содержат специальных приложений и
сервисов, управляющих данными, — взаимодействие с ними осуществляется с
помощью файловых сервисов операционной системы. Нередко подобные СУБД
имеют в своем составе и средства разработки, ориентированные на работу с
данными формата, характерного для этой СУБД, и позволяющие создать более
или менее комфортный пользовательский интерфейс. Что же касается
обработки данных — она целиком и полностью осуществляется в
пользовательском (клиентском) приложении.
Следующим шагом в развитии настольных СУБД было появление их
сетевых многопользовательских версий, позволяющих обрабатывать данные,
находящиеся в общедоступном хранилище (например, на сетевом диске)
нескольким пользователям одновременно. От чисто настольных СУБД их
многопользовательские версии отличаются наличием механизма блокировок
частей файлов данных (содержащих одну или несколько записей таблицы), что
позволяет обращаться к одному и тому же файлу нескольким пользователям
одновременно.
Недостатки подобных СУБД не очевидны и становятся заметны, как
правило, при росте хранимых объемов данных и увеличении числа
пользователей. Обычно они проявляются в снижении производительности и в
возникновении сбоев при обработке данных после некоторого времени
использования клиентских приложений. Причина подобных проблем кроется в
основном принципе работы таких СУБД и основанных на них
информационных систем, заключающемся в обработке данных внутри
пользовательского приложения. Например, если с помощью такой системы
требуется выполнить запрос согласно какому-либо критерию (например,
выбрать заказы, обработанные за последние два часа, из таблицы заказов), то, в
лучшем случае (если эта таблица проиндексирована по времени поступления
заказа), приложение должно прочесть с сетевого диска весь индекс, найти в нем
сведения о местоположении записей в файлах, содержащих таблицу, и затем
прочесть эти части файлов. В общем же случае, когда таблица не
проиндексирована по данному полю, ее необходимо загрузить с сетевого диска
и проанализировать.
Еще одна проблема настольных СУБД заключается в возможности
нарушения ссылочной целостности данных, так как единственным механизмом,
контролирующим ее, является пользовательское приложение. Поэтому все
пользовательские приложения должны содержать соответствующий код и
доступ к файлам базы данных из любых других приложений должен быть
запрещен. В наиболее популярных настольных СУБД (например, Microsoft
Access, Corel Paradox) код, контролирующий стандартную ссылочную
целостность, содержится в библиотеках, используемых всеми приложениями,
138
работающими с этой базой данных, а сама база данных при этом может
содержать описание правил ссылочной целостности.
Следующим этапом развития СУБД для персональных компьютеров
были так называемые серверные СУБД. Они будут рассмотрены в следующей
главе.
Архитектура «клиент/сервер», для которой предназначены серверные
СУБД, является в определенной степени возвратом к прежней
«мэйнфреймовой» модели, основанной на централизации хранения и обработки
данных на одном выделенном компьютере, где функционирует специальное
приложение или сервис, называемый сервером баз данных. Сервер баз данных
отвечает за работу с файлами базы данных, поддержку ссылочной целостности,
резервное копирование, обеспечение авторизованного доступа к данным,
протоколирование операций и, конечно, за выполнение пользо вательских
запросов на выбор и модификацию данных и метаданных. Клиентские
приложения, являющиеся источниками этих запросов, функционируют на
персональных компьютерах в сети.
Не останавливаясь подробно на достоинствах и недостатках подобной
архитектуры, отметим лишь, что при использовании серверных СУБД
выполнение запросов производится самим сервером, поэтому клиентские
приложения получают от сервера только результаты самого запроса и не
требуют передачи всего индекса или всей таблицы, что существенно снижает
сетевой трафик при обработке запросов. Отметим также, что многие объекты,
предназначенные для реализации бизнес-правил, такие как хранимые
процедуры и триггеры, доступны лишь в серверных СУБД.
Рассмотрев, какими бывают базы данных, вернемся к настольным СУБД
и поговорим о наиболее популярных из них.
10.2. Наиболее популярные настольные СУБД
На сегодняшний день известно более двух десятков форматов данных
настольных СУБД, однако наиболее популярными, исходя из числа проданных
копий, следует признать dBase, Paradox, FoxPro и Access. Из появившихся
недавно СУБД следует также отметить Microsoft Data Engine — по существу
серверную СУБД, представляющую собой «облегченную» версию Microsoft
SQL Server, но предназначенную, тем не менее, для использования главным
образом в настольных системах и небольших рабочих группах.
10.2.1. dBase и Visual dBase
Первая промышленная версия СУБД dBase — dBase II (принадлежащая
тогда компании Ashton-Tate, приобретенной позже компанией Borland)
появилась в начале 80-х годов. Благодаря простоте в использовании,
нетребовательности к ресурсам компьютера и, что не менее важно, грамотной
маркетинговой политике компании-производителя этот продукт приобрел
139
немалую популярность, а с выходом следующих его версий — dBase III и dBase
III Plus (1986 г.), оснащенных весьма комфортной по тем временам средой
разработки и средствами манипуляции данными, быстро занял лидирующие
позиции среди настольных СУБД и средств создания использующих их
приложений.
Хранение данных в dBase основано на принципе «одна таблица — один
файл» (эти файлы обычно имеют расширение *.dbf). MEMO-поля и BLOB-поля
(доступные в поздних версиях dBase) хранятся в отдельных файлах (обычно с
расширением *.dbt). Индексы для таблиц также хранятся в отдельных файлах.
При этом в ранних версиях этой СУБД требовалась специальная операция
реиндексирования для приведения индексов в соответствие с текущим
состоянием таблицы.
Формат данных dBase является открытым, что позволило ряду других
производителей заимствовать его для создания dBase-подобных СУБД,
частично совместимых с dBase по форматам данных. Например, весьма
популярная некогда СУБД FoxBase (разработанная Fox Software, Inc. и ныне
принадлежащая Microsoft) использовала формат данных dBase для таблиц,
однако форматы для хранения MEMO-полей и индексов были своими
собственными, несовместимыми с dBase. Очень популярное в начале 90-х годов
(и кое-где применяемое до сих пор) средство разработки Clipper компании
Nantucket Corp (приобретенной впоследствии компанией Computer Associates)
манипулировало как с данными формата dBase III (включая индексные файлы и
файлы для MEMO-полей), так и с индексными файлами собственного формата.
Помимо популярного формата данных dBase является родоначальником и
некогда популярного семейства языков программирования, получившего
называние xBase. Все языки этого семейства, использующиеся и в FoxBase, и в
Clipper, и в некоторых более поздних средствах разработки, таких как
канувший в Лету CA Visual Objects фирмы Computer Associates, содержат
сходный набор команд для манипуляции данными и являются по существу
интерпретируемыми языками. В роли интерпретатора команд xBase выступает
обычно либо среда разработки приложения на этом языке, либо среда времени
выполнения, которую можно поставлять вместе с приложением. Отметим, что
для скрытия исходного текста xBase-приложения подобные СУБД обычно
содержат утилиты для псевдокомпиляции кода, который затем поставляется
вместе со средой времени выполнения. В случае Clipper среда времени
выполнения содержится в самом исполняемом файле (и сам Clipper формально
считается компилятором), но, тем не менее, этот язык по существу также
является интерпретируемым.
Обладавшие немалым сходством в синтаксисе и поддерживаемом наборе
команд во времена широкого применения DOS, языки семейства xBase, тем не
менее, имеют немало различий, особенно в поздних версиях «наследников»,
использовавших их СУБД. Как правило, все они имеют собственные объектные
140
расширения, и поэтому в настоящее время говорить об их совместимости
между собой практически не приходится.
Отметим, однако, что для работы с данными формата dBase (или иных
dBase-подобных СУБД) совершенно необязательно пользоваться диалектами
xBase. Доступ к этим данным возможен с помощью ODBC API (и
соответствующих драйверов) и некоторых других механизмов доступа к
данным (например, Borland Database Engine, некоторых библиотек других
производителей типа СodeBase фирмы Sequenter), и это позволяет создавать
приложения, использующие формат данных dBase, практически с помощью
любого средства разработки, поддерживающего один из этих механизмов
доступа к данным.
После покупки dBase компанией Borland этот продукт, получивший
впоследствии название Visual dBase, приобрел набор дополнительных
возможностей, характерных для средств разработки этой компании и для
имевшейся у нее другой настольной СУБД — Paradox. Среди этих
возможностей были специальные типы полей для графических данных,
поддерживаемые индексы, хранение правил ссылочной целостности внутри
самой базы данных, а также возможность манипулировать данными других
форматов, в частности серверных СУБД, за счет использования BDE API и SQL
Links.
В настоящее время Visual dBase принадлежит компании dBase, Inc. Его
последняя версия — Visual dBase 7.5 имеет следующие возможности:
Средства манипуляции данными dBase и FoxPro всех версий.
Средства создания форм, отчетов и приложений.
Средства публикации данных в Internet и создания Web-клиентов.
Ядро доступа к данным Advantage Database Server фирмы Extended
Systems и ODBC-драйвер для доступа к данным этой СУБД.
Средства публикации отчетов в Web.
Средства визуального построения запросов.
Средства генерации исполняемых файлов и дистрибутивов.
В настоящее время к Visual dBase в качестве дополнения может быть
приобретен компонент dConnections, позволяющий осуществить доступ к
данным Oracle, Sybase, Informix, MS SQL Server, DB2, InterBase из Visual dBase
7.5 и приложений, созданных с его помощью.
Компания dBase, Inc объявила также о проекте dBASE Open Source,
целью которого является разработка сообществом пользователей dBase новых
компонентов и классов с целью включения их в последующую версию dBase
(получившую название dBase 2000). Иными словами, имеется тенденция
превращения dBase (или его частей) в некоммерческий продукт с доступными
исходными текстами.
141
10.2.2. Paradox
Paradox был разработан компанией Ansa Software, и первая его версия
увидела свет в 1985 году. Этот продукт был впоследствии приобретен
компанией Borland. С июля 1996 года он принадлежит компании Corel и
является составной частью Corel Office Professional.
В конце 80-х — начале 90-х годов Paradox, принадлежавший тогда
компании Borland International, был весьма популярной СУБД, в том числе и в
нашей стране, где он одно время занимал устойчивые позиции на рынке
средств разработки настольных приложений с базами данных.
Принцип хранения данных в Paradox сходен с принципами хранения
данных в dBase — каждая таблица хранится в своем файле (расширение *.db),
MEMO- и BLOB-поля хранятся в отдельном файле (расширение *.md), как и
индексы (расширение *.px).
Однако, в отличие от dBase, формат данных Paradox не является
открытым, поэтому для доступа к данным этого формата требуются
специальные библиотеки. Например, в приложениях, написанных на C или
Pascal, использовалась некогда популярная библиотека Paradox Engine, ставшая
основой Borland Database Engine. Эта библиотека используется ныне в
приложениях, созданных с помощью средств разработки Borland (Delphi,
C++Builder), в некоторых генераторах отчетов (например, Crystal Reports) и в
самом Paradox. Существуют и ODBC-драйверы к базам данных, созданным
различными версиями этой СУБД.
Отметим, однако, что отсутствие «открытости» формата данных имеет и
свои достоинства. Так как в этой ситуации доступ к данным осуществляется
только с помощью «знающих» этот формат библиотек, простое редактирование
подобных данных по сравнению с данными открытых форматов типа dBase
существенно затруднено. В этом случае возможны такие недоступные при
использовании «открытых» форматов данных сервисы, как защита таблиц и
отдельных полей паролем, хранение некоторых правил ссылочной целостности
в самих таблицах — все эти сервисы предоставляются Paradox, начиная с
первых версий этой СУБД.
По сравнению с аналогичными версиями dBase ранние версии Paradox
обычно предоставляли разработчикам баз данных существенно более
расширенные возможности, такие как использование деловой графики в DOS приложениях, обновление данных в приложениях при многопользовательской
работе, визуальные средства построения запросов на основе интерфейса QBE
— Query by Example (запрос по образцу), средства статистического анализа
данных, а также средства визуального построения интерфейсов
пользовательских приложений с автоматической генерацией кода на языке
программирования PAL (Paradox Application Language).
Windows-версии СУБД Paradox, помимо перечисленных выше сервисов,
позволяли также манипулировать данными других форматов, в частности dBase
и данными, хранящимися в серверных СУБД. Такую возможность пользователи
142
Paradox получили благодаря использованию библиотеки Borland Database
Engine и драйверов SQL Links. Это позволило использовать Paradox в качестве
универсального средства управления различными базами данных (существенно
облегченная версия Paradox 7 под названием Database Desktop по -прежнему
входит в состав Borland Delphi и Borland C++Builder именно с этой целью). Что
же касается базового формата данных, используемого в этом продукте, то он
обладает теми же недостатками, что и все форматы данных настольных СУБД,
и поэтому при возможности его стараются заменить на серверную СУБД, даже
сохранив сам Paradox как средство разработки приложений и манипуляции
данными.
Текущая версия данной СУБД — Paradox 9 поставляется в двух
вариантах: Paradox 9 Standalone Edition и Paradox 9 Developer’s Edition. Первый
из них предназначен для использования в качестве настольной СУБД и входит
в Corel Office Professional, второй — в качестве как настольной СУБД, так и
средства разработки приложений и манипуляции данными в серверных СУБД.
Обе версии содержат:
средства манипуляции данными Paradox и dBase;
средства создания форм, отчетов и приложений;
средства визуального построения запросов;
средства публикации данных и отчетов в Internet и создания Webклиентов;
Corel Web-сервер;
ODBC-драйвер для доступа к данным формата Paradox из Windowsприложений;
средства для доступа к данным формата Paradox из Java-приложений.
Помимо этого Paradox 9 Developer’s Edition содержит:
Run-time-версию Paradox для поставки вместе с приложениями;
средства создания дистрибутивов;
драйверы SQL Links для доступа к данным серверных СУБД;
Отметим, однако, что популярность этого продукта как средства
разработки в последнее время несколько снизилась, хотя в мире
эксплуатируется еще немало информационных систем, созданных с его
помощью.
10.2.3. Microsoft FoxPro и Visual FoxPro
FoxPro ведет свое происхождение от настольной СУБД FoxBase фирмы
Fox Software. Разрабатывая FoxBase в конце 80-х годов, эта компания
преследовала цель создать СУБД, функционально совместимую с dBase с точки
зрения организации файлов и языка программирования, но с ущественно
превышающую ее по производительности. Одним из способов повышения
производительности являлась более эффективная организация индексных
143
файлов, нежели в dBase, — по формату индексных файлов эти две СУБД
несовместимы между собой.
По сравнению с аналогичными версиями dBase, FoxBase и более поздняя
версия этого продукта, получившая название FoxPro, предоставляли своим
пользователям несколько более широкие возможности, такие как
использование деловой графики, генерация кода приложений, автоматическая
генерация документации к приложениям и т.д.
Впоследствии этот продукт был приобретен компанией Microsoft. Его
последние версии (начиная с версии 3.0, выпущенной в 1995 году) получили
название Visual FoxPro. С каждой новой версией этот продукт оказывался все
более и более интегрирован с другими продуктами Microsoft, в частности с
Microsoft SQL Server, — в состав Visual FoxPro в течение нескольких последних
лет входят средства переноса данных FoxPro в SQL Server и средства доступа к
данным этого сервера из Visual FoxPro и созданных с его помощью
приложений. Хотя формат данных FoxPro также модифицировался с каждой
новой версией, приобретая такие возможности, как хранение правил ссылочной
целостности и некоторых бизнес-правил в самой базе данных, миграции
приложений Visual FoxPro на серверные платформы уделялось значительно
большее внимание.
Последняя версия этого продукта — Visual FoxPro 6.0, доступна и
отдельно, и как составная часть Microsoft Visual Studio 6.0. Отличительной
особенностью этой настольной СУБД от двух рассмотренных выше является
интеграция этого продукта с технологиями Microsoft, в частности поддержка
COM (Component Object Model — компонентная объектная модель,
являющаяся основой функционирования 32-разрядных версий Windows и
организации распределенных вычислений в этой операционной системе),
интеграция с Microsoft SQL Server, возможности создания распределенных
приложений, основанных на концепции Windows DNA (Distributed interNet
Applications).
Visual Fox Pro 6.0 предоставляет следующие возможности:
средства публикации данных в Internet и создания Web-клиентов;
средства создания ASP-компонентов и Web-приложений;
средства создания COM-объектов и объектов для Microsoft Transaction
Server, позволяющих создавать масштабируемые многозвенные
приложения для обработки данных;
средства доступа к данным серверных СУБД, базирующиеся на
использовании OLE DB (набор COM-интерфейсов, позволяющий
осуществить унифицированный доступ к данным из разнообразных
источников, в том числе из нереляционных баз данных и иных
источников, например Microsoft Exchange);
средства доступа к данным Microsoft SQL Server и Oracle, включая
возможность создания и редактирования таблиц, триггеров, хранимых
процедур;
144
средства отладки хранимых процедур Microsoft SQL Server;
средства визуального моделирования компонентов и объектов,
являющиеся составными частями приложения — Visual Modeller;
средство для управления компонентами приложений, позволяющее
осуществлять их повторное использование.
Итак, тенденции развития этого продукта очевидны: из настольной СУБД
Visual FoxPro постепенно превращается в средство разработки приложений в
архитектуре «клиент/сервер» и распределенных приложений в архитектуре
Windows DNA. Впрочем, эти тенденции в определенной степени характерны
для всех наиболее популярных настольных СУБД — мы уже убедились, что и
dBase, и Paradox также позволяют осуществлять доступ к наиболее популярным
серверным СУБД.
10.2.4. Microsoft Data Engine
MSDE представляет собой СУБД, базирующуюся на технологиях
Microsoft SQL Server, но предназначенную для использования в настольных
системах или в сетевых приложениях с объемом данных до 2 Гбайт и
небольшим количеством пользователей. По существу MSDE является
облегченной версией Microsoft SQL Server, не содержащей средств
администрирования, и к настольным СУБД может быть отнесена весьма
условно.
В Microsoft Access пользователь может выбрать, какой механизм доступа
к данным следует применять: Microsoft Jet — стандартный набор библиотек
доступа к данным или MSDE (в этом случае управление базой данных
осуществляется с помощью отдельного процесса). Возможно преобразование
имеющихся баз данных Access в базу данных MSDE из среды разработки
Access.
Базы данных MSDE полностью совместимы с базами данных Microsoft
SQL Server и могут при необходимости управляться этим сервером. Как
большинство серверных СУБД, эти базы данных поддерживают транзакции,
позволяют создавать триггеры и хранимые процедуры (недоступные в базах
данных Access), использовать механизмы защиты данных, предоставляемые
операционной системой. Помимо этого при большом числе пользователей и
большом объеме данных приложения, использующие MSDE, отличаются более
высокой производительностью, так как обработка запросов происходит внутри
процесса, управляющего базой данных, а не внутри клиентского приложения,
что позволяет снизить сетевой трафик, связанный с передачей данных от
сервера к клиенту.
MSDE входит в состав Microsoft Office 2000 Premium или Developer, а
также доступна на Web-сайте Microsoft для зарегистрированных пользователей
Visual Studio 6.0 Professional, Enterprise Edition либо любого из средств
разработки, являющегося частью Visual Studio 6.0 Professional или Enterprise
Edition. MSDE может свободно распространяться в составе приложений,
145
созданных с помощью любого из средств разработки, входящего в состав Visual
Studio 6.0 или Office 2000 Developer.
В данной главе рассмотрены наиболее популярные на сегодняшний день
настольные СУБД. Развитие тех из настольных СУБД, что сумели сохранить
свою популярность на протяжении многих лет, подчинялось вполне
определенным закономерностям. Все эти СУБД:
приобрели визуальные средства проектирования форм, отчетов и
приложений в момент появления ранних Windows-версий;
стали предоставлять доступ к данным серверных СУБД к моменту
появления первых 32-разрядных версий;
приобрели средства публикации данных в Internet и в той или иной
степени поддерживают создание приложений для редактирования
данных с помощью Web-браузеров;
начали предоставлять возможность хранить описания правил
ссылочной целостности внутри базы данных.
Помимо этого все современные СУБД, за исключением Corel Paradox, в
качестве альтернативы собственному формату данных позволяют использовать
для создания настольных приложений облегченные серверы баз данных,
предназначенные для использования на одном компьютере или в рамках
небольшой рабочей группы. Иными словами, история развития настольных
СУБД отражает современные тенденции развития информационных систем,
такие как создание распределенных систем с использованием Internet или
Intranet, применение средств быстрой разработки приложений и массовый
перенос приложений, использующих базы данных, включая настольные
приложения, в архитектуру «клиент/сервер».
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Дайте характеристику наиболее популярных настольных СУБД.
2. Укажите основные тенденции развития настольных СУБД
146
11. СЕРВЕРНЫЕ СУБД
11.1. Характерные черты современных серверных СУБД
Применительно к системам баз данных архитектура "клиент-сервер"
интересна и актуальна главным образом потому, что обеспечивает простое и
относительно дешевое решение проблемы коллективного доступа к базам
данных в локальной сети.
Термин "сервер баз данных" обычно используют для обозначения всей
СУБД, основанной на архитектуре "клиент-сервер", включая и серверную, и
клиентскую части. Такие системы предназначены для хранения и обеспечения
доступа к базам данных.
Хотя обычно одна база данных целиком хранится в одном узле сети и
поддерживается одним сервером, серверы баз данных представляют собой
простое и дешевое приближение к распределенным базам данных, поскольку
общая база данных доступна для всех пользователей локальной сети.
Доступ к базе данных от прикладной программы или пользователя
производится путем обращения к клиентской части системы. В качестве
основного интерфейса между клиентской и серверной частями выступает язык
баз данных SQL.
Современные серверные СУБД обычно предоставляют дополнительный
набор сервисов, связанных с обслуживанием хранения и обработки данных,
созданием клиентских приложений, сменой СУБД или ее версии,
обслуживанием нескольких баз данных, публикацией данных в Internet.
Наиболее характерные для сегодняшнего дня сервисы, предоставляемые
серверными СУБД следующие:
А. Реализация для нескольких платформ
Почти все современные серверы баз данных существуют в нескольких
версиях для различных платформ (как правило, различные коммерческие
версии UNIX — Solaris, HP/UX и др., а также Windows NT Server и, с недавнего
времени, Windows 2000). Многие производители серверных СУБД также
выпускают версии своих серверов для Windows NT Workstationи Windows 95/98
(а иногда даже для Windows CE). В последнем случае такие серверы нередко
бывают персональными (однопользовательскими), либо в их реализации
отсутствуют возможности, характерные для полнофункциональных версий этих
серверов. Подобные персональные серверы, как правило, используются в
«переносных» системах, например на ноутбуках, применяемых для работы с
базой данных отдельно от центрального офиса компании с последующей
репликацией данных. Иногда такие серверы используются при создании
приложений для изоляции разработчика от сервера баз данных, находящегося в
процессе эксплуатации.
В последнее время многие производители серверных СУБД выпускают
также версии для Linux — с этой точки зрения Linux в последние два года была
весьма «модной» платформой.
147
Исключением из этого правила является Microsoft SQL Server. Однако
для данной СУБД это вполне оправданно — компания Microsoft сама
производит серверные операционные системы и в отличие от большинства
других производителей серверных СУБД может себе позволить создавать
серверы баз данных, тесно интегрированные с сервисами операционной
системы собственного производства и поддерживающие исключительно их.
Б. Административные утилиты
Наличие удобных утилит администрирования часто оказывается одним из
решающих факторов при выборе СУБД. Именно поэтому подавляющее
большинство современных СУБД обычно поставляется с подобными
утилитами, и их интерфейс в последнее время напоминает интерфейс Windows
Explorer.
В. Резервное копирование данных
Резервное копирование данных и журналов транзакций поддерживается
всеми без исключения коммерческими серверными СУБД. Различия между
СУБД в поддержке резервного копирования заключаются в том, возможно ли
производить резервное копирование в процессе работы пользователей, и если
да, то какие пользовательские операции в это время нельзя выполнять. Помимо
этого в комплекте поставки некоторых СУБД могут содержаться утилиты для
использования различных внешних устройств (например, накопителей на
магнитных лентах) в качестве средств хранения резервных копий.
Г. Обслуживание репликаций
Репликация по существу представляет собой гарантированное
копирование информации из одной базы в несколько других. Репликации
используются для разделения нагрузки между серверами в сети, для
перемещения поднаборов данных на вспомогательные серверы, для
синхронизации данных на нескольких серверах и многих других целей.
В том или ином виде репликации поддерживаются всеми современными
серверными СУБД. Различия могут быть лишь в поддержке тех или иных
конкретных сценариев репликаций (например, внесение изменений
одновременно на нескольких серверах, возможность шифрования
реплицируемых данных и др.).
Д. Параллельная обработка данных в многопроцессорных системах
О возможностях повышения производительности с помощью
параллельной обработки запросов в многопроцессорных системах начали
говорить несколько лет назад, после появления первого продукта такого класса
— Oracle Parallel Server. Серверы, поддерживающие параллельную обработку,
разрешают нескольким процессорам обращаться к одной базе данных, что
позволяет обеспечить высокую скорость обработки транзакций.
В настоящее время подавляющее большинство производителей
современных серверных СУБД поставляют на рынок версии, поддерживающие
параллельную обработку данных. Обычно это версии для Windows NT и
коммерческих версий UNIX.
148
Е. Поддержка OLAP и создания хранилищ данных
OLAP (On-Line Analytical Processing) представляет собой технологию
построения многомерных хранилищ данных (Data Warehouses), как правило,
агрегатных, то есть являющихся результатом обработки набора данных,
нередко состоящего из нескольких таблиц. Такие хранилища данных в
последнее время широко используются в системах поддержки принятия
решений.
Многомерные хранилища данных могут быть реализованы как в виде
набора обычных реляционных таблиц, так и в виде нереляционной
многомерной базы данных. В последнем случае такое хранилище обычно
управляется отдельным сервером. Многие производители серверных СУБД
поставляют такие серверы отдельно (Oracle, Informix), некоторые включают их
в состав сервера реляционных баз данных (Microsoft SQL Server 7.0). Нередко с
целью повышения конкурентоспособности подобные OLAP-системы строят
многомерные хранилища на основе данных из других СУБД, как это сделано,
например, в Microsoft SQL Server OLAP Extensions и в Sybase Adaptive Server
IQ.
Ж. Распределенные запросы и транзакции
Возможности выполнения распределенного запроса или распределенной
транзакции поддерживаются сейчас почти всеми серверными СУБД, по
крайней мере в том случае, когда все вовлеченные в транзакцию серверы — от
одного и того же производителя. С этой целью используется механизм
двухфазного завершения транзакций (two-phase commit), когда на первом этапе
серверы, вовлеченные в транзакцию, сигнализируют о готовности ее завершить,
а на втором этапе происходит реальная фиксация изменений в базах данных.
Что касается распределенных транзакций с участием «чужих» серверов,
то они, как правило, реализуются с помощью мониторов транзакций или иных
подобных сервисов, например Microsoft Distributed Transaction Coordinator.
К. Средства проектирования данных
Многие производители серверных СУБД производят также средства
анализа бизнес-процессов и проектирования данных, иногда универсальные
(как в случае Sybase DataArchitect), а порой ориентированные главным образом
на конкретную СУБД (как в случае Oracle Designer/2000). Многие
производители СУБД не имеют в своем арсенале собственных средств
проектирования данных, ориентируясь на универсальные CASE-средства типа
Platinum
ERwin.
Нередко
производители
СУБД
встраивают
в
административные утилиты несложные средства проектирования данных,
позволяющие визуально редактировать схемы данных, как это сделано,
например, в Microsoft SQL Server 7.0.
Л. Поддержка собственных и «чужих» средств разработки и
генераторов отчетов
Многие производители серверных СУБД выпускают также средства
разработки и генераторы отчетов. Иногда данные средства разработки
149
используют тот же язык программирования, что применяется при написании
триггеров и хранимых процедур (в этом случае, как правило, клиентское
приложение должно включать интерпретатор этого языка), что позволяет
отлаживать хранимые процедуры, помещая их в клиентское приложение.
Типичный пример подобного подхода реализован в Oracle Developer/2000.
Практически все производители серверных СУБД делают все возможное
для того, чтобы клиентские приложения для их СУБД можно было создавать с
помощью других средств разработки. С этой целью они предоставляют
разработчикам описания API клиентской части, ODBC-драйверы, OLE DBпровайдеры, а нередко и объектные модели, позволяя использовать COMобъекты клиентской части в приложениях (как, например, это сделано в
клиентских частях Oracle, Microsoft SQL Server, Informix).
Производители серверных СУБД, ориентирующиеся только на
собственные средства разработки, как правило, оказываются вытесненными с
рынка или теряют его часть
М. Поддержка доступа к данным с помощью Internet
Без поддержки публикации данных в Internet или получения данных от
удаленных Internet-клиентов сегодня не обходится практически ни одна
коммерческая СУБД, в том числе настольные базы данных. Тем или иным
способом производители серверных СУБД поддерживают Web-технологии.
Чаще всего эта поддержка осуществляется с помощью Web-серверов
собственного производства, либо посредством создания расширений для
существующих Web-серверов, либо просто путем включения в комплект
поставки утилит, генерирующих Web-страницы согласно определенному
расписанию.
11.2. Наиболее популярные серверные СУБД
На сегодняшний день известно более двух десятков серверных СУБД,
однако наиболее популярными, исходя из числа продаж и инсталляций, следует
признать Oracle, Microsoft SQL Server, Informix, Sybase, DB2.
11.2.1.Oracle
Oracle была первой коммерческой реляционной СУБД, поддерживающей
ставший ныне индустриальным стандартом язык SQL; ее первая версия
появилась в 1979 году. Фактически все это время Oracle является бессменным
лидером на рынке производителей коммерческих СУБД и второй (после
Microsoft) по величине компанией, производящей программное обеспечение.
Ранние версии этой СУБД были предназначены для мэйнфреймов, а в
качестве рабочих мест использовались «неинтеллектуальные» терминалы.
Однако со временем появились версии Oracle, предназначенные для
использования в архитектуре «клиент-сервер» (первой такой версией была
Oracle 5, выпущенная в 1985 году). Первоначально эти версии были
150
предназначены для различных серверных платформ — различных версий
UNIX, VMS и др. Позже были выпущены версии сервера Oracle для Novell
NetWare. Первые версии этого сервера для персональных компьютеров
появились в середине 90-х (Personal Oracle 7 for Windows 3.1, Personal Oracle 7
for Windows 95, Personal Oracle Lite, Oracle Workgroup Server 7 for Windows
NT). До появления этих версий персональные компьютеры могли
использоваться исключительно в качестве клиентских рабочих станций — в
состав Oracle для серверных платформ обычно входила клиентская часть для
DOS.
Отметим, что Oracle была первой компанией, создавшей СУБД,
использовавшую предоставляемые некоторыми серверными платформами
средства параллельных вычислений — Oracle Parallel Server (до его появления
параллельные вычисления использовались только для решения научных задач).
При использовании параллельных вычислений Oracle Parallel Server дает
возможность нескольким процессорам обращаться к одной базе данных, что
позволяет обеспечить высокую скорость обработки транзакций, а более
поздние его версии дают возможность осуществить декомпозицию операций с
большими объемами данных с целью параллельного выполнения их на
нескольких процессорах.
На сегодняшний день последней версией Oracle является версия Oracle 8i,
отличительными свойствами которой являются:
наличие объектных расширений и соответствующих типов данных,
таких как вложенные таблицы, массивы, объекты и др. Иными словами, Oracle
8 и Oracle 8i являются объектно-ориентированными СУБД;
наличие функций аналитической обработки данных (например,
вычисления процентных соотношений, ранжирования, сравнения временных
периодов);
возможность создания таблиц, содержащих агрегатные данные
(materialized views) и возможность частичного их обновления при изменении
данных, на основании которых они вычислены;
поддержка Java, в частности JDK 1.2 и JDBC 2.0;
поддержка XML, в частности в Oracle 8i включены XML Parser for
Java, C/C++, PL/SQL, превращающие XML-данные в вид, пригодный для
использования в Oracle 8;
поддержка HTML- и XML-страниц с включенным в них кодом PL/SQL
(для их выполнения требуются дополнительные продукты, например WebDB
PL/SQL Gateway или Oracle Application Server PL/SQL Cartridge);
поддержка хранения мультимедиа-данных с возможностью
индексации, построения контекстных запросов, поддержки разных языков для
хранимых документов;
набор процедур и функций для обработки пространственной
информации (Oracle Spatial);
151
дополнительные возможности обеспечения безопасности, например
шифрование данных, поддержка SSL, использование ролей уровня базы данных
и уровня предприятия;
возможность создания систем, устойчивых к сбоям, с использованием
нескольких параллельных процессов;
поддержка Microsoft Cluster Server;
наличие OLE DB-провайдера для доступа к данным.
Oracle 8i существует в трех редакциях: Oracle 8i, Oracle 8i Enterprise
Edition, Oracle 8i Personal Edition.
Для создания многомерных хранилищ данных существует и отдельный
продукт — Oracle Express OLAP.
Помимо различных версий сервера баз данных среди продуктов Oracle
имеется также Designer/2000 — ориентированное на эту СУБД CASE-средство
для анализа бизнес-процессов и проектирования данных, а также средства
разработки клиентских приложений. Одно из них — Developer/2000
(называвшееся ранее Oracle*Forms) — весьма популярно среди пользователей
Oracle; были и другие средства разработки (например, Oracle Power Objects).
Отметим, что приложения, созданные с помощью Developer/2000, могут
выполняться на различных платформах. Язык PL/SQL, используемый в этом
средстве разработки, является интерпретируемым и представляет собой тот же
самый язык, что используется в Oracle для написания серверного кода. Это
позволяет отлаживать с помощью Developer/2000 серверный код.
Производя собственные средства разработки, Oracle предоставляет своим
пользователям возможность создавать клиентские приложения с помощью
других средств. В частности, помимо стандартного в таких случаях
клиентского API (Oracle Call Interface) клиентская часть Oracle содержит также
объектную модель (Oracle Objects for OLE), позволяющую использовать
клиентскую часть Oracle как набор COM-объектов для доступа к данным.
Кроме того, обычно клиентская часть Oracle содержит также ODBC-драйвер
для доступа к данным этой СУБД.
Отметим, что и многие другие компании производят ODBC-драйверы и
OLE DB-провайдеры для доступа к Oracle (в частности, Microsoft). Компании,
производящие средства разработки, использующие собственные библиотеки
доступа к данным (такие как Inprise или Gupta/Centura), также включают
библиотеки доступа к Oracle в состав наиболее дорогих версий своих
продуктов.
Из готовых информационных систем на базе Oracle следует особо
отметить несколько крупных систем управления предприятием, в частности
SAP/R3. На Западе также нередко используются готовые решения от самой
Oracle Corporation, объединенные под общим названием Oracle Applications,
такие как Oracle Financials, Oracle Human Resources, Oracle Market Management,
Oracle Project Systems и др.
152
11.2.2. Microsoft SQL Server
Первая версия Microsoft SQL Server, совместно разработанная в 1988 году
компаниями Microsoft и Sybase, предназначалась для платформы OS/2.
Последующие версии этого сервера баз данных предназначались для
платформы Windows NT и со временем были тесно интегрированы с этой
операционной системой. Для других платформ версии этого сервера не
выпускались и не выпускаются.
Удобный пользовательский интерфейс утилит администрирования в
сочетании с достаточно высокой производительностью и относительно
невысокой стоимостью эксплуатации сделал эту серверную СУБД второй по
популярности — после Oracle. Наибольший рост популярности этой СУБД
пришелся на конец 90-х годов, когда были выпущены Microsoft SQL Server 6.0
(1995 год), обладавший централизованными функциями администрирования и
встроенными возможностями репликации данных, Microsoft SQL Server 6.5
(1996 год) и Microsoft SQL Server 6.5 Enterprise Edition, поддерживающий
параллельные вычисления в многопроцессорных системах.
На сегодняшний день наиболее широко используемой является
выпущенная в 1998 году версия Microsoft SQL Server 7.0. Эта версия отличается
от предыдущих тем, что была полностью переписана фирмой Microsoft
исключительно под платформу Windows NT. В состав Microsoft SQL Server 7.0
входят еще более простые утилиты администрирования (Enterprise Manager),
сервисы преобразования данных (Data Transformation Services), облегчающие
перенос данных в SQL Server из других типов СУБД, поддержка
распределенных запросов и транзакций, OLAP-сервер и утилиты для создания
хранилищ данных (в том числе данных из других серверных СУБД),
расширенная поддержкой функций для создания Web-приложений.
Помимо собственно Microsoft SQL Server 7.0 в качестве встроенной
СУБД для настольных приложений и приложений для небольших рабочих
групп можно также использовать Microsoft Data Engine (MSDE) — настольный
сервер баз данных, совместимый с Microsoft SQL Server и предназначенный для
использования в настольных системах или в сетевых приложениях с
небольшим (до 2 Гбайт) объемом данных и небольшим количеством
пользователей. Базы данных MSDE полностью совместимы с базами данных
Microsoft SQL Server и могут при необходимости управляться этим сервером.
Клиентские приложения для Microsoft SQL Server и MSDE можно
создавать как с помощью средств разработки Microsoft — Visual Basic, Visual
C++, Access и Visual FoxPro, так и с помощью средств разработки других
производителей. Для этой цели имеются ODBC-драйвер и OLE DB-провайдер,
а также содержащий их набор библиотек Microsoft Data Access Components
(MDAC), позволяющий использовать в средствах разработки объекты ActiveX
Data Objects (ADO) — COM-объекты для доступа к данным. MDAC является
составной частью Windows 2000, а для пользователей других Windows платформ доступен отдельно на Web-сайте Microsoft.
153
В отличие от Oracle, Microsoft не производит средств разработки,
использующих тот же самый язык программирования, что и язык для создания
кода триггеров и хранимых процедур, однако производит средства отладки
серверного кода (например, SQL Server Debugger входит в состав Visual Basic и
Visual C++).
11.2.3.Sybase
Серверные продукты компании Sybase происходят от двух «предков».
Первым из них является одна из ранних версий Microsoft SQL Server, созданная
совместно Microsoft и Sybase. Начиная с 1994 года Microsoft и Sybase
разрабатывают свои серверные продукты независимо друг от друга, и
результатом деятельности компании Sybase в этом направлении является
продукт под названием Adaptive Server Enterprise (в настоящее время
используются его версии 11 и 12). Этот продукт существует для Windows NT и
некоторых версий UNIX (включая Linux) и предназначен для обслуживания
крупных предприятий. В настоящее время этот сервер поддерживает:
упреждающее асинхронное чтение, что повышает скорость
выполнения сложных запросов;
использование кластерных систем;
распределенную обработку запросов, в том числе к базам данных
других производителей;
расширенные хранимые процедуры, позволяющие осуществить легкий
доступ к не-SQL функциям (Java, 3GL-системы, функции операционной
системы и т.д.);
параллельную обработку запросов в многопроцессорных системах;
параллельную работу утилит администрирования;
интеграцию с популярными системами безопасности, такими как
Kerberos.
Еще одна линия серверных продуктов Sybase ведет свое начало от
сервера баз данных Watcom SQL Anywhere, отличавшегося компактностью и
простотой администрирования. Последняя версия этого продукта называется
Adaptive Server Anywhere 6.0.3. Этот сервер предназначен для обслуживания
небольших рабочих групп, для применения в портативных компьютерах в
качестве персонального сервера с периодической репликацией, а также в
мобильных устройствах — существуют версии этого сервера для Windows CE
2.1 и версия UltraLite для разнообразных мобильных устройств.
Для управления распределенными транзакциями Sybase выпускает
монитор транзакций — Jaguar CTS.
Для создания многомерных хранилищ данных у Sybase существует еще
один серверный продукт — Adaptive Server IQ, позволяющий создавать
хранилища на основе данных не только из СУБД производства Sybase, но и из
СУБД других производителей. Отметим также, что существует ряд продуктов
под общим названием Sybase Industry Warehouse Studio, ориентированных на
154
обслуживание конкретных предметных областей: торговли (Retail Warehouse
Studio), здравоохранения (Healthcare Warehouse Studio), страхования (Life
Insurance Warehouse Studio) и др.
Помимо серверных продуктов Sybase производит средства разработки,
ориентированные на создание клиентских приложений для них (PowerBuilder,
PowerJ, PowerSite; последнее предназначено для создания Web-приложений), и
средства проектирования данных и генерации кода приложений. Последние
можно отнести к универсальным средствам — CASE-средство DataArchitect
поддерживает широкий спектр СУБД различных производителей, а генератор
приложений AppModeler способен генерировать код не только для PowerBuilder
и Optima++, но и для Delphi, Visual Basic, Web-приложений с использованием
ASP.
11.2.4. Informix
Ведущий продукт фирмы Informix — Informix Dynamic Server, последняя
версия которого называется Informix Dynamic Server.2000 (выпущена в
сентябре 1999 года). Данный продукт поддерживает платформы UNIX и
Microsoft Windows NT и обеспечивает эффективную работу как на одно-, так и
на многопроцессорных системах, а также в кластерах. Сервер построен по
архитектуре Dynamic Scalable Architecture (DSA), обеспечивающей мощные
средства для параллельной обработки данных. В числе основных характеристик
Informix Dynamic Server следует отметить:
использование для управления дисковым пространством как средств
операционной системы (UNIX или Microsoft Windows NT), так и собственных
функций, позволяющих обойти ограничения операционной системы и добиться
более высокой производительности, — такое управление дисковым
пространством называется Raw Disk Management;
управление разделением памяти — поддержку одновременного
доступа к данным, находящимся в памяти, несколькими приложениями;
динамическое управление потоками;
поддержку фрагментации таблиц и индексов на нескольких дисках;
распараллеливание запросов (parallel database query, PDQ);
зеркалирование данных.
Сервер поддерживает двухфазное завершение транзакций, гетерогенные
транзакции (в этом случае в транзакциях может принимать участие и неInformix сервер, доступный через Informix Enterprise Gateway).
Расширение функциональности сервера реализуются на базе DataBlade —
коллекций объектов баз данных и подпрограмм на языке С, подключаемых к
базе данных. Для разработки DataBlades необходимо использовать DataBlade
Developer’s Kit. Фирма Informix и целый ряд независимых производителей
выпускают модули DataBlade, такие, например, как Excalibur Text DataBlade
Module, Informix Geodetic DataBlade Module, Informix TimeSeries DataBlade
155
Module, Excalibur Image DataBlade Module, Informix Web DataBlade Module и
ряд других.
Входящие в состав Informix Dynamic Server клиентские утилиты
предназначены для подключения к серверу и обработки информации (DBAccess) и для выполнения функций администрирования (DB/Cockpit).
Клиентские приложения могут создаваться с использованием языков
Informix ESQL (средство для разработки на языке С, позволяющее включать в
приложения запросы к данным на языке SQL), а также С, С++, Java, Visual
Basic и Delphi. Помимо этого существует собственное средство разработки —
Informix-4GL и Informix Client Software Developer’s Kit.
Фирма Informix выпускает Informix ODBC Driver, OLE DB Provider для
Informix Dynamic Server и Informix JDBC Driver.
В состав продукта входят собственно сервер, а также Informix Connect
2.30, DataBlade Developer’s Kit 4.0 и Informix Server Administrator 1.0.
Для генерации отчетов предлагается Informix-ViewPoint — визуальное
средство, рассчитанное на пользователей. Версия Pro также содержит средства
администрирования.
Говоря о сервере фирмы Informix, следует упомянуть и поддержку OLAP:
продукт под названием Informix MetaCube поставляется как часть Informix
Decision Frontier — комплексного решения для создания хранилищ данных.
Среди других продуктов фирмы Informix следует отметить:
Informix Internet Foundation.2000 — специально разработанный для
Internet вариант Informix Dynamic Server;
i.Reach — корпоративный репозитарий для хранения данных
различного типа, интеллектуального управления информацией и извлечения
данных. Основное назначение данного продукта — поддержка включения в
содержимое корпоративных сайтов электронных документов и их последующее
обслуживание;
i.Sell — комплексное решение для электронной коммерции на базе
Informix Dynamic Server.
11.2.5. DB2
Семейство серверных СУБД фирмы IBM, известное под названием DB2
Universal Database, представляет собой стратегию IBM по объединению
продуктов DB2 для различных платформ в единую линию. Впервые
появившееся в 1996 году семейство DB2 Universal Database объединяло в себе
функциональные возможности таких продуктов фирмы, как DB2 Common
Server, DB2 Parallel Edition (DB2 PE), Net.Data, Data Propagator и технологии
DataHub, и предназначалось для платформ UNIX, OS/2 и Microsoft Windows
NT.
Отметим, что при переносе DB2 на не-IBM-платформы фирма старается
максимально использовать уникальные функциональные возможности
конкретной платформы. Например, в DB2 for Windows 2000 для обеспечения
156
безопасности используется Windows NT LAN Manager, полностью
поддерживается Windows Performance Monitor, Systems Management Server,
интеграция с Active Directory для каталогизации баз данных, а также такие
интерфейсы доступа к данным, как ODBC, ADO и OLE DB. Помимо этого DB2
for Windows 2000 поддерживает Microsoft Transaction Services (MTS) в качестве
координатора при создании приложений, использующих распределенные
транзакции.
Для разработчиков, использующих Microsoft Visual Studio, становятся
доступными дополнительные модули, например Stored ProcedureBuilder,
включаемый непосредственно в среду Visual Studio. IBM также предлагает
собственные средства разработки, например IBM VisualAge for Java,
позволяющие создавать приложения, работающие с данными в DB2. Продукт
также поддерживает создание хранимых процедур на языке Java (Java Stored
Procedure Builder).
Помимо этого IBM предлагает бесплатное средство для миграции данных
из Microsoft Access в DB2, а также средства для миграции данных из Oracle,
Microsoft, Sybase и Informix.
К основным характеристикам СУБД можно отнести поддержку
реляционных и комплексных данных через объектные расширения,
возможность работы на мультипроцессорных платформах, поддержку
кластеров, 64-битную архитектуру памяти и распараллеливание запросов,
возможность создания Web-приложений (поддерживаются такие технологии,
как Java, JDBC, SQLJ, XML) и наличие средства для гетерогенного
администрирования и обработки данных.
Семейство DB2 функционионирует на системах AS/400 и RISC
System/6000, мэйнфреймах IBM, машинах от Hewlett-Packard и Sun
Microsystems и на таких операционных системах, как Windows NT и Windows
95/98, OS/2, AIX, HP-UX, SCO UnixWare, Linux, NUMA-Q и Sun Solaris, и
сейчас поддерживает портативные устройства под управлением Windows CE и
Palm OS.
DB2 Universal Database выпускается в редакциях DB2 Universal Database
Enterprise — Extended Edition (платформы AIX, Solaris и Windows NT), DB2
Universal Database Enterprise Edition (платформы AIX, HP-UX, Linux, OS/2,
Solaris и Windows NT), DB2 Universal Database Workgroup Edition (платформы
Linux, OS/2 и Windows NT) и DB2 Universal Database Personal Edition
(платформы OS/2, Linux, Windows 9x и Windows NT).
К дополнительным продуктам можно отнести:
DB2 OLAP Server — средство для онлайновой аналитической
обработки данных и реализации хранилищ данных, интегрирующее ядро
Hyperion Essbase с семейством DB2 Universal Database. Работает с Hyperion
Integration Server (Hyperion), Hyperion Wired for OLAP (Hyperion), Brio.Insight
(Brio Technology), BUSINESSOBJECTS (Business Objects), PowerPlay (Cognos),
157
Lotus 1-2-3 (Lotus), Excel, Internet Explorer, Visual Basic (Microsoft) и Crystal Info
(Seagate);
DB2 Connect — средство для управления соединениями различных
клиентов с DB2 на AS/400;
DB2 Universal Developer’s Edition — рассчитанное на разработчиков
средство для создания и тестирования приложений в архитектуре «клиентсервер», работающих с данными DB2;
DB2 DataJoiner — средство для доступа к реляционным и
нереляционным данным, расположенным на различных платформах, как к
единому «образу» данных;
DB2 Data Links Manager — средство для управления дополнительными
файлами, подключаемыми к СУБД;
DB2 Query Patroller — набор средств для создания запросов и
управления ресурсами для систем принятия решений. DB2 Query Patroller
получает ODBC-запросы от клиента, анализирует их и динамически
распределяет запросы по различным узлам DB2 UDB Enterprise — Extended
Edition;
DB2 Net.Data — приложение, позволяющее Web-разработчикам
создавать динамические Internet-приложения, используя Web Macros;
DB2 Universal Database Satellite Edition — средство для внедрения
масштабируемых мобильных решений, для управления удаленными
пользователями. Поддерживает функции репликации, централизованное
администрирование и средства управления через Web — DB2 Web Control
Center;
DB2 Everywhere — СУБД для Palm OS и Windows CE,
обеспечивающее SQL-функции и синхронизацию данных с другими
реляционными базами данных, с данными Lotus Notes/Domino и PIMs.
Таким образом, по сравнению с информационными системами,
основанными на настольных СУБД, системы, использующие серверные СУБД,
обладают более высокой производительностью, меньшим сетевым трафиком,
более совершенными средствами обеспечения безопасности, а также
возможностями перенести на сервер баз данных часть кода, связанную с
реализацией бизнес-правил и обработкой данных. Так же существующие на
сегодняшний день возможности наиболее популярных серверных СУБД
отражают современные тенденции развития информационных систем.
КОНТРОЛЬНЫЕ ВОПРОСЫ
1. Дайте характеристику наиболее популярных серверных СУБД.
2. Укажите основные тенденции развития серверных СУБД.
3. Расскажите о преимуществах серверных СУБД.
158
ЗАКЛЮЧЕНИЕ
В учебном пособии рассмотрены этапы развития информационных
систем и их классификация по признаку структурированности задач, вопросы
построения, проектирования и использования банков и баз данных, а именно
архитектура систем баз данных, функции СУБД, модели и типы данных,
теоретические основы проектирования баз данных, рассматривается
применение баз данных в корпоративных информационных системах и способы
наполнения баз данных на примере модуля «Управление персоналом», а также
рассмотрены наиболее популярные справочно-правовые базы данных.
Учебное пособие позволяет не только освоить основные разделы курсов
«Базы данных», «Управление данными», но и по окончании этих курсов
повысить качество и надежность разработок в области создания
информационных систем.
УСЛОВНЫЕ ОБОЗНАЧЕНИЯ
АД
АБД
Бд
БнД
ИС
ОС
ППП
РСБД
СУБД
ЯОД
ЯМД
– администратор данных
– администратор базы данных
– база данных
– банк данных
– информационная система
– операционная система
– пакет прикладных программ
– расширяемые системы баз данных
– система управления базами данных
– язык описания данных
– язык манипулирования данными
159
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Астахова, И.Ф. SQL в примерах и задачах: учебное пособие/ И.Ф.
Астахова, А.П. Толстобров, В.М. Мельников.- Минск: Новое знание, 2002.176с.
2. Атре, Ш. Структурный подход к организации баз данных / Ш. Атре. –
М.: Финансы и статистика, 1983. – 320 с.
3. Бойко, В. В. Проектирование баз данных информационных систем /
В.В Бойко., В.М Савинков. – М.: Финансы и статистика, 1989. – 351 с.
4. Бородаев, В. А. Базы и банки данных: учеб. пособие / В. А. Бородаев ,
В. Н. Кустов. - Л.: ВИКИ, 1989. – 224 c.
5. Васильев, В. Объектно-ориентированная база данных: взгляд изнутри //
Компьютеры + Программы. 1997. № 3 (36). – С.45–49.
6. Вейскас, Д. Эффективная работа с Microsoft Access 97 / Д. Вейскас. –
СПб: Питер Ком, 1999. – 973с.
7. Горев А. Visual FoxPro 5.0. Книга для программистов / А. Горев. – М.:
Журнал “Fox Talk” ТОО «Эдэль», 1997 – 552 с.
8. Горев, А. Эффективная работа с СУБД / А. Горев, Р. Ахаян, С.
Макашарипов – СПб.: Питер, 1997. - 704 с.
9. Грубер, М. Понимание SQL.: Пер. с англ. / М. Грубер.– М., 1993. –
430с.
10. Дейт, К. Дж. Введение в системы баз данных / К. Дж. Дейт: Пер с
англ. – 6-е изд. – Киев: Диалектика, 1998. – 1328 с.
11. Джексон, Г. Проектирование реляционных баз данных для
использования с микроЭВМ / Г. Джексон. - М.: Мир, 1991. – 252 с.
12. Дженнингс, Р. Microsoft Access 97 в подлиннике. Том II: Пер. с англ.
/P. Дженнингс. - СПб: BHV – Санкт-Петербург, 1997.
13. Диго, С.М. Проектирование и использование баз данных: учебник /
С.М. Диго. – М.: Финансы и статистика, 1995. – 208 с.
14. Каратыгин, С. А. Visual FoxPro 6 / С.А. Каратыгин, А.Ф. Тихонов,
Л.Н. Тихонова . - М.: ЗАО «Издательство БИНОМ», 1999. - 784 с.
15. Кириллов, В.В. Структуризованный язык запросов (SQL) / В.В.
Кириллов. – СПб.: ИТМО, 1994. – 80 с.
16. Кириллов, В.В. Основы проектирования реляционных баз данных /
В.В. Кириллов. – СПб.: ИТМО, 1996. – 90 с.
17. Краморенко, Н.В. Базы данных: учеб. пособие / Н.В. Краморенко. Владивосток: ТИДОТ ДВГУ, 2004. - 85 с.
18. Кузнецов, С.Д. Введение в системы управления базами данных / С.Д.
Кузнецов. СУБД: 1995. №№ 1,2,3,4; 1996. №№ 1,2,3.
19. Кузнецов, С. Д. Основы современных баз данных / С.Д. Кузнецов. 2-е
изд. - М.: ЗАО «Издательство БИНОМ», 2007. - 484 с.
20. Ладыженский, Г. М. Системы управления базами данных – коротко о
главном / Г. М. Ладыженский. СУБД: 1995 г. №№ 1–4.
160
21. Мартин, Дж. Организация баз данных в вычислительных системах /
Дж. Мартин. Пер. с англ. - М.: Мир, 1980. – 662 с.
22. Мейер, М. Теория реляционных баз данных / М. Мейер. – М.: Мир, 1987.
– 608 с.
23. Наумов, А.Н. Системы управления базами данных и знаний: справ.
изд. / А.Н. Наумов, А.М. Вендров, В.К. Иванов и др.; Под ред. Наумова А.Н. М.: Финансы и статистика, 1991. – 352 с.
24. Тиори, Т. Проектирование структур баз данных. В 2 кн. / Т. Тиори,
Дж. Фрай. - М.: Мир, 1985. Кн. 1. 287 с.: Кн. 2. 320 с.
25. Ульман, Дж. Основы систем баз данных: Пер. с англ. / Г. Хансен, Д.
Хансен. - М.: ЗАО «Издательство БИНОМ», 1999. – 292 с.
26. Хаббард, Дж. Автоматизированное проектирование баз данных / Дж.
Хаббард. – М.: Мир, 1984. – 294 с.
27. Харитонова, И. Microsoft Access 2000 в подлиннике / И. Харитонова,
М. Михеев. СПб.: БХВ – Санкт-Петербург, 1999. – 1088с.
28. Хомоненко, А. Д. Базы данных: учебник для высших учебных
заведений / А.Д. Хомоненко, В.М. Цыганков, М.Г. Мальцев / Под ред. проф.
А.Д. Хомоненко. - СПб: КОРОНА, 2000. – 416 с.
29. Цикритизис, Д. Модели данных / Д. Цикритизис, Ф. Лоховски.- М.:
Финансы и статистика, 1985. - 344 с.
30. Четвериков, В.Н. Базы и банки данных: учеб. для вузов по спец
«АСУ» / В.Н. Четвериков, Г.И. Ревунков, Э.Н. Самохвалов; Под. ред.
В.Н. Четверикова. – М.: Высш. шк., 1987. – 248 с.
31. Stonebraker, M. Introduction to “Integration of Knowledge and Data
Management” // M. Stonebraker (ed.). Readings in Database System. – San Mateo,
Calif.: Morgan Kaufmann, 1988. – 783 p.
32. Ceri, S. Logic Programming and Databases / S. Ceri, G. Gottlob, L. Tanca
New York, N.Y. Springer-Verlag, 1990. – 284 р
161
Учебное издание
Корелина Татьяна Валерьевна
ВВЕДЕНИЕ В БАЗЫ ДАННЫХ
Учебное пособие
Редактор Акритова Е.В.
Подписано в печать 25.01.2012. Формат 60х84 1/16. Уч.-изд.л.10,0.
Усл.-печ.л. 10,1. Бумага писчая. Тираж 100 экз. Заказ №
Отпечатано: отдел оперативной полиграфии издательства учебной
литературы и учебно-методических пособий Воронежского ГАСУ
394006 Воронеж, ул. 20-летия Октября, 84
162
Документ
Категория
Без категории
Просмотров
54
Размер файла
2 961 Кб
Теги
данных, базы, 542, введение, корелина
1/--страниц
Пожаловаться на содержимое документа