Системы управления базами данных

1. Имя отношения выделяется курсивом и подчеркиванием и пишется прописными буквами, например: СОТРУДНИКИ.

2. Имя атрибута отношения выделяется курсивом и подчеркиванием и пишется с большой буквы, например: Оклад.

3. Ключевые атрибуты отношения выделяются полужирным шрифтом, например: Табельный номер.

4. Имя связи между отношениями выделяется курсивом и подчеркиванием и пишется строчными буквами, например: работает.

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

1. Функциональный подход к проектированию БД.

Этот метод является наиболее распространённым. Он реализует принцип "от задач" и применяется в том случае, когда известны функции некоторой группы лиц и/или комплекса задач, для обслуживания информационных потребностей которых создаётся рассматриваемая БД.

2. Предметный подход к проектированию БД.

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

3. Проектирование с использованием метода "сущность-связь".

Метод "сущность-связь" (Entity-Relation, ER-method) был разработан в 1976 г. П.Ченом (Chen P.P.). Он является комбинацией двух предыдущих и обладает достоинствами обоих. Этап инфологического проектирования начинается с моделирования ПО. Проектировщик разбивает ПО на ряд локальных областей, каждая из которых (в идеале) включает в себя информацию, достаточную для обеспечения информационных потребностей одной группы будущих пользователей или решения отдельной задачи. Каждое локальное представление моделируется отдельно, а затем выполняется их объединение. Выбор локального представления зависит от масштабов ПО. Обычно ПО разбивается на локальные области так, чтобы каждая из них соответствовала отдельному внешнему приложению и содержала 6-7 сущностей (т.е. объектов, о которых в системе будет накапливаться информация).

Сущности, существование которых не зависит от существования других сущностей, называются базовыми, остальные сущности - зависимыми. Например, сущность ЛЕКЦИЯ зависит от базовых сущностей ГРУППА, ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА.

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

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

Далее осуществляется спецификация связей: выявляются связи между сущностями внутри локального представления. Каждая связь именуется. Кроме спецификации связей типа "сущность - сущность", выполняется спецификация связей типа "сущность - атрибут" и "атрибут - атрибут" для отношений между атрибутами, которые относятся к одной и той же сущности или к одной и той же связи типа "сущность - сущность".

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

· объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта;

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

· образование классов и подклассов подобных объектов (например, класс "изделие" и подклассы типов изделий, производимых на предприятии).

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

1. Идентичность. Два или более элементов модели идентичны, если они имеют одинаковое семантическое значение.

2. Агрегация. Позволяет рассматривать связь между элементами как новый элемент. Например, связь экзамен между сущностями СТУДЕНТ, ДИСЦИПЛИНА, ПРЕПОДАВАТЕЛЬ может быть представлена агрегированной сущностью ЭКЗАМЕН с атрибутами Название дисциплины, Фамилия преподавателя, Фамилия студента, Оценка.

3. Обобщение. Позволяет образовывать многоуровневую иерархию обоб-щений. Например, в объединяемых представлениях присутствуют следующие сущности:

ДЕТАЛИ СОБСТВЕННОГО ПРОИЗВОДСТВА

ДЕТАЛИ ПОКУПНЫЕ

СБОРОЧНЫЕ ЕДИНИЦЫ ПОКУПНЫЕ

СБОРОЧНЫЕ ЕДИНИЦЫ СОБСТВЕННОГО ПРОИЗВОДСТВА

Их можно объединить так, как показано на рис. 3.1. Это позволит упростить формализацию процессов обработки данных. Например, оформление заказа на покупные элементы изделий в данном примере может быть описано один раз (для второго уровня иерархии).

Рис.3.1. Использование обобщений при объединении

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

По завершении объединения результаты проектирования представляют собой концептуальную инфологическую модель ПО. Модели локальных представлений - это внешние инфологические модели.

На этапе анализа ПО также решаются следующие задачи:

1. Определение правил (ограничений целостности), которым должны удовлетворять сущности ПО, атрибуты сущностей и связи между ними. Часть этих правил реализуется в схеме базы данных (возможности реализации ограничений целостности в схеме БД определяются моделью данных той СУБД, которая будет выбрана для реализации проекта). Остальные правила реализуются с помощью программного обеспечения.

2. Выделение групп пользователей системы. Каждая группа выполняет определённые задачи и обладает разными правами доступа к системе.

3. Создание внешней спецификации тех функций (процессов), которые эта система будет выполнять. Например, для той же библиотечной системы это задачи поиска книг (по определённым критериям), выдачи/приёма книг, определение списка должников и т.д.

2.2 Определение требований к операционной обстановке

На этом этапе производится оценка требований к вычислительным ресурсам, необходимым для функционирования системы, выбор типа и конфигурации ЭВМ, типа и версии операционной системы.

Выбор зависит от таких следующих показателей:

· примерный объём данных в БД;

· динамика роста объёма данных;

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

· интенсивность запросов к данным по типам запросов;

· требования к времени отклика системы по типам запросов.

2.3 Выбор СУБД и инструментальных программных средств

Выбор СУБД является одним из важнейших моментов в разработке проекта БД, так как он принципиальным образом влияет на весь процесс проектирования БД и реализации информационной системы.

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

· тип модели данных, которую поддерживает данная СУБД, адекватность модели данных структуре рассматриваемой ПО;

· характеристики производительности СУБД;

· запас функциональных возможностей для дальнейшего развития информационной системы;

· степень оснащенности СУБД инструментарием для персонала администрирования данными;

· удобство и надежность СУБД в эксплуатации;

· стоимость СУБД и дополнительного программного обеспечения.

2.4 Логическое проектирование БД

На этапе логического проектирования разрабатывается логическая структура БД, соответствующая инфологической модели ПО. Решение этой задачи существенно зависит от модели данных, поддерживаемой выбранной СУБД. Результатом выполнения этого этапа являются схемы БД концептуального и внешнего уровней архитектуры, составленные на языках определения данных (DDL) выбранной СУБД.

2.5 Физическое проектирование БД

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

Более подробно процесс проектирования баз данных освещен в [9].

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

2.6 Автоматизация проектирования БД

Функциональное ядро систем автоматизированного проектирования (САПР) БД строится как совокупность взаимосвязанных модулей инфологического моделирования, проектирования схемы, подсхем и физической организации БД.

Существующие в настоящее время САПР БД строятся как человеко-машинные экспертные системы. В первую очередь это определяется слабо поддающимся формализации процессом синтеза инфологического описания ПО, т.е. преобразования неформальных представлений реального мира в формальные категории. Этот процесс выполняется экспертом - специалистом в той или иной ПО. Поэтому все проблемы, которые характерны для формирования базы знаний экспертной системы, возникают и в случае САПР БД.

Характерной особенностью САПР БД является её ориентация на коллективное творчество и продолжительность самого процесса проектирования, предполагающего множественные итерации. Это находит свое отражение в наличии журнала проектирования и других средств, обеспечивающих ведение и коллективное использование исходных данных, промежуточных и окончательных результатов проектирования. Общая структура САПР БД приведена на рис. 3.2.

Рис. 3.2. Общая структура САПР БД

2.7 Особенности проектирования реляционных БД

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

· Каждое отношение соответствует одной сущности ПО и в него вносятся все атрибуты объекта, связанные с ним отношением 1:1.

· Связь типа 1:n реализуется с помощью внешнего ключа.

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

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

2.7.1 Аномалии модификации данных

В качестве примера возьмём отношение со следующими атрибутами (ключевые атрибуты выделены подчёркиванием):

ПОСТАВКИ (Номер поставки, Название товара, Цена товара, Количество, Дата поставки, Название поставщика, Адрес поставщика)

Различают три вида аномалий: аномалии обновления, удаления и добавления. Аномалия обновления может возникнуть в том случае, когда информация дублируется. Другие аномалии возникают тогда, когда две и более независимые сущности объединены в одно отношение. Например:

1. Аномалия обновления: в отношении ПОСТАВКИ она может возникнуть, если у какого-либо поставщика изменился адрес. Изменения должны быть внесены во все кортежи, соответствующие поставкам этого поставщика; в противном случае данные будут противоречивы.

2. Аномалия удаления: при удалении записей обо всех поставках одного поставщика все данные о поставщике будут утеряны.

3. Аномалия добавления: в нашем примере она возникнет, если с поставщиком заключен договор, но поставок от него еще не было. Информация о таком поставщике не может быть внесена в отношение ПОСТАВКИ, т.к. для него не определён ключ (номер поставки и название товара) и другие обязательные поля.

Для решения проблемы аномалии модификации данных при проектировании РБД проводится нормализация отношений.

2.7.2 Нормализация отношений

В рамках реляционной модели данных Э.Ф. Коддом был разработан аппарат нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме. Нормализация схемы отношения выполняется путём декомпозиции схемы.

Декомпозицией схемы отношения R называется замена её совокупностью схем отношений А_i таких, что

и не требуется, чтобы отношения А_i были непересекающимися. Декомпозиция отношения должна обладать следующими свойствами:

1. Полнота - декомпозиция не должна приводить к потере зависимостей между атрибутами сущностей.

2. Восстановимость - должна существовать операция реляционной алгебры, применение которой позволит восстановить исходной отношение.

Введём понятие простого и сложного атрибута. Простой атрибут - это атрибут, значения которого атомарны (т.е. неделимы). Сложный атрибут может иметь значение, представляющее собой конкатенацию нескольких значений одного или разных доменов. Аналогом сложного атрибута может быть агрегат или повторяющийся агрегат данных.

Покажем нормализацию на примере отношения КНИГИ (табл. 3.1):

Id - идентификатор (первичный ключ),

Code - шифр рубрики,

Theme- название рубрики,

Title - название книги,

Author- автор,

Editor - редактор,

Type - тип издания (учебник, учебное пособие, сборник и.т.п.),

Year - год издания,

Pg - количество страниц.

Таблица 3.1. Исходное отношение КНИГИ

ID	Code	Theme	Author	Title	Editor	Type	Year	Pg
200	681.3	ПО ВТ	Бочков С.	Язык СИ	Садчиков П.	учебник	1990	384
			Субботин Д.
100	681.3	ПО ВТ	Джехани Н.	Язык АДА		учебник	1960	552
300	621.5	МО	Крон Г.	Диакоптика	Баранов А.	учебник	1972	544
876	007	ИИ	Гик Е.Я.	Шахматы и математика	Кикоин И.	учебное пособие	1983	176
					Капица С.
440	32.97	ВТ		ПУ для ПЭВМ	Витенберг А.	справочник	1992	208
385	001.8	Инфор-матика	Фролов Г.	Элементы информатики	Храмов А.	учебное пособие	1989	304
			Кузнецов Э.		Рожков П.

Примечание. В таблице 3.1 используются следующие сокращения:

ВТ - вычислительная техника;

ПО ВТ - программное обеспечение вычислительной техники;

МО - математическое обеспечение;

ИИ - искусственный интеллект.

3.7.2 Первая нормальная форма (1НФ).

Отношение приведено к 1НФ, если все его атрибуты простые.

Отношение КНИГИ содержит сложные атрибуты Author ("Авторы") и Editor ("Редакторы"). Для приведения к 1НФ требуется сделать ключ отношения составным - атрибуты ID, Author и Editor (табл. 3.2).

Таблица 3.2. Отношение КНИГИ, приведённое к 1НФ

ID	Code	Theme	Author	Title	Editor	Type	Year	Pg
200	681.3	ПО ВТ	Бочков С.	Язык СИ	Садчиков П.	учебник	1990	384
200	681.3	ПО ВТ	Субботин Д.	Язык СИ	Садчиков П.	учебник	1990	384
100	681.3	ПО ВТ	Джехани Н.	Язык АДА		учебник	1960	552
300	621.5	МО	Крон Г.	Диакоптика	Баранов А.	учебник	1972	544
876	007	ИИ	Гик Е.Я.	Шахматы и математика	Кикоин И.	учебное пособие	1983	176
876	007	ИИ	Гик Е.Я.	Шахматы и математика	Капица С.	учебное пособие	1983	176
440	32.97	ВТ		ПУ для ПЭВМ	Витенберг А.	справочник	1992	208
385	001.8	Инфор-матика	Фролов Г.	Элементы информатики	Храмов А.	учебное пособие	1989	304
385	001.8	Инфор-матика	Кузнецов Э.	Элементы информатики	Рожков П.	учебное пособие	1989	304

Введём понятие функциональной зависимости. Пусть X и Y - атрибуты (группы атрибутов) некоторого отношения. Говорят, что Y функционально зависит от X, если в любой момент времени каждому значению X=х соответствует единственное значение Y=y (X?Y). (При этом любому значению Y=y может соответствовать несколько значений Х=(х₁, х₂,…)).

Атрибут X в функциональной зависимости X?Y называется детерминантом отношения.

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

2.7.3 Вторая нормальная форма (2НФ)

Отношение находится во 2НФ, если оно приведено к 1НФ и каждый неключевой атрибут функционально полно зависит от составного ключа.

Для того чтобы привести отношение ко 2НФ, нужно:

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

· построить дополнительные проекции на часть составного ключа и атрибуты, функционально зависящие от этой части ключа.

Ключом отношения КНИГИ (табл. 3.2) является комбинация полей (ID, Author, Editor). Все поля, не входящие в состав ключа, зависят только от идентификатора книги. Поэтому отношение должно быть разбито на два: КНИГИ (табл. 3.3) и КНИГИ-АВТОРЫ-РЕДАКТОРЫ (табл. 3.4). Эти отношения связаны по внешнему ключу, которым является поле ID.

Таблица 3.3. Отношение КНИГИ, приведённое к 2НФ

ID	Code	Theme	Title	Type	Year	Pg
200	681.3	ПО ВТ	Язык СИ для ПК	учебник	1990	384
100	681.3	ПО ВТ	Язык АДА	учебник	1960	552
300	621.5	МО	Диакоптика	учебник	1972	544
876	007	ИИ	Шахматы и математика	учебное пособие	1983	176
440	32.97	ВТ	ПУ для ПЭВМ	справочник	1992	208
385	001.8	Информатика	Элементы информатики	учебное пособие	1989	304

Таблица 3.4. Отношение КНИГИ-АВТОРЫ-РЕДАКТОРЫ (2НФ)

ID	Author	Editor
200	Бочков С.	Садчиков П.
200	Субботин Д.	Садчиков П.
100	Джехани Н.
300	Крон Г.	Баранов А.
876	Гик Е.Я.	Кикоин И.
876	Гик Е.Я.	Капица С.
440		Витенберг А.
385	Фролов Г.	Храмов А.
385	Кузнецов Э.	Рожков П.

Рассмотрим понятие транзитивной зависимости. Пусть X, Y, Z - атрибуты некоторого отношения. При этом X? Y и Y? Z, но обратное соответствие отсутствует, т.е. Z не зависит от Y или Y не зависит от X. Тогда говорят, что Z транзитивно зависит от X (X?? Z).

2.7.4 Третья нормальная форма (3НФ).

Отношение находится в 3НФ, если оно находится во 2НФ и в нем отсутствуют нетранзитивные зависимости.

Для отношения КНИГИ (табл. 3.3) атрибут Theme зависит от атрибута Code, а не от ключа (хотя название рубрики, естественно, соответствует её шифру). Поэтому для приведения отношения к 3НФ (табл. 3.5) нужно выделить из него ещё одно отношение РУБРИКАТОР (табл. 3.6).

Таблица 3.5. Отношение КНИГИ, приведённое к 3НФ

ID	Code	Title	Type	Year	Pg
200	681.3	Язык СИ для ПК	учебник	1990	384
100	681.3	Язык АДА	учебник	1960	552
300	621.5	Диакоптика	учебник	1972	544
440	32.97	ПУ для ПЭВМ	справочник	1992	208
876	007	Шахматы и математика	учебное пособие	1983	176
385	001.8	Элементы информатики	учебное пособие	1989	304

Таблица 3.6. Отношение РУБРИКАТОР, приведённое к 3НФ

Code	Theme
681.3	ПО ВТ
621.5	МО
007	ИИ
32.97	ВТ
001.8	Информатика

Введём понятие многозначной зависимости. Многозначная зависимость существует, если заданным значениям атрибута X соответствует множество, состоящее из нуля (или более) значений атрибута Y (X-»Y). Если в отношении присутствуют многозначные зависимости, то схема отношения должна находиться в 4НФ.

Различают тривиальные и нетривиальные многозначные зависимости. Тривиальной называется такая многозначная зависимость X-»Y, для которой Y I X или X U Y = R, где R - рассматриваемое отношение. Тривиальная многозначная зависимость не нарушает 4НФ. Если хотя бы одно из двух этих условий не выполняется (т.е. Y не является подмножеством X или X U Y состоит не из всех атрибутов R), то такая многозначная зависимость называется нетривиальной.

2.7.5 Четвертая нормальная форма (4НФ).

Отношение находится в 4НФ, если оно находится в 3НФ и в нем отсутствуют нетривиальные многозначные зависимости.

Для отношения КНИГИ-АВТОРЫ-РЕДАКТОРЫ (табл. 3.4) атрибуты Author и Editor зависит образуют две многозначные зависимости от первичного ключа, и при этом значения этих атрибутов не зависят друг от друга. Поэтому для приведения отношения к 4НФ нужно разбить его на два отношения КНИГИ-АВТОРЫ и КНИГИ-РЕДАКТОРЫ (табл. 3.7, 3.8).

Таблица 3.7. Отношение КНИГИ-АВТОРЫ (4НФ)

ID	Author
200	Бочков С.
200	Субботин Д.
100	Джехани Н.
300	Крон Г.
876	Гик Е.Я.
385	Фролов Г.
385	Кузнецов Э.

Таблица 3.8. Отношение КНИГИ-РЕДАКТОРЫ (4НФ)

ID	Editor
200	Садчиков П.
300	Баранов А.
876	Кикоин И.
876	Капица С.
440	Витенберг А.
385	Храмов А.
385	Рожков П.

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

3. СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ

Система управления базами данных (СУБД) - это важнейший компонент АИС, основанной на базе данных. СУБД необходима для создания и поддержки базы данных информационной системы в той же степени, как для разработки программы на алгоритмическом языке - транслятор. Программные составляющие СУБД включают в себя ядро и сервисные средства (утилиты).

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

Системой управления базами данных называют программную систему, предназначенную для создания на ЭВМ общей базы данных для множества приложений, поддержания её в актуальном состоянии и обеспечения эффективного доступа пользователей к содержащимся в ней данным в рамках предоставленных им полномочий.

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

Для инициализации базы данных разработчик средствами конкретной СУБД описывает логическую структуру БД, её организацию в среде хранения и представления данных пользователями (соответственно концептуальную схему БД, схему хранения и внешние схемы). Обрабатывая эти схемы, СУБД создаёт пустую БД требуемой структуры и предоставляет средства для наполнения её данными о предметной области и дальнейшей эксплуатации.

3.1 Классификация СУБД

По степени универсальности СУБД делят на два класса: СУБД общего назначения (СУБД ОН) и специализированные СУБД (СпСУБД).

СУБД ОН не ориентированы на какую-либо предметную область или на конкретные информационные потребности пользователей. Каждая система такого рода является универсальной и реализует функционально избыточное множество операция над данными. СУБД ОН имеют в своем составе средства настройки на конкретную предметную область, условия эксплуатации и требования пользователей. Производство этих систем поставлено на широкую коммерческую основу.

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

· за счёт знания особенностей конкретной предметной области,

· путём сокращения функциональной полноты системы.

Создание СпСУБД - дело весьма трудоемкое, поэтому для того, чтобы выбрать этот путь, надо иметь действительно веские основания. В дальнейшем будут рассматриваться только СУБД общего назначения.

По модели данных различают иерархические, сетевые, реляционные и объектно-ориентированные СУБД.

По методам организации хранения и обработки данных СУБД делят на централизованные и распределённые. Первые работают с БД, которая физически хранится в одном месте (на одном компьютере). Это не означает, что пользователь может работать с БД только за этим же компьютером: доступ может быть удалённым (в режиме клиент-сервер). Большинство централизованных СУБД перекладывает задачу организации удаленного доступа к данным на сетевое обеспечение, выполняя только свои стандартные функции, которые, естественно, усложняются за счёт одновременности доступа многих пользователей к данным.

3.2 Основные функции СУБД

В качестве основных функций СУБД можно выделить следующие:

1. Хранение, извлечение и обработка данных.

Это основная функция системы, ради которой она создаётся.

2. Наличие языка обработки данных.

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

3. Наличие доступного пользовательского каталога данных.

Каталог (словарь-справочник) содержит метаданные, т.е. информацию о данных. Он должен быть организован с использованием тех же структур, что и сами данные. Это даёт возможность использовать для доступа к нему тот же язык, который используется для доступа к самим данным.

4. Поддержка многопользовательского режима доступа.

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

5. Обеспечение логической независимости данных.

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

6. Обеспечение физической независимости данных.

Под физической независимостью данных подразумевается способность СУБД предоставлять некоторую свободу модификации способов организации базы данных в среде хранения, не вызывая необходимости внесения изменений в логическое представление данных. Это позволяет оптимизировать среду хранения данных с целью повышения эффективности системы, не затрагивая созданных прикладных программ, работающих с БД.

Свойства (5-6) обеспечиваются с помощью одних и тех же механизмов СУБД.

7. Обеспечение логической целостности БД.

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

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

8. Обеспечение физической целостности данных.

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

Восстановление данных основано на периодическом создании резервных копий БД и ведении журнала регистрации изменений.

9. Управление доступом.

Для многопользовательских систем актуальна проблема защиты данных от несанкционированного доступа. Каждый пользователь этой системы в соответствии со своим уровнем (приоритетом) имеет доступ либо ко всей совокупности данных, либо только к её части. Управление доступом также подразумевает предоставление прав на проведение отдельных операций над отношениями или другими объектами БД.

10. Настройка СУБД.

Настройка СУБД обычно выполняется администратором БД, отвечающим за функционирование системы в целом. В частности, она может включать в себя следующие операции:

· модификация параметров организации среды хранения данных с целью повышения эффективности системы;

· подключение внешних приложений к БД;

· изменение структуры хранимых данных или их размещения в среде хранения (реорганизацию БД) для повышения производительности системы или повторного использования освободившейся памяти;

· модификацию концептуальной схемы данных (реструктуризацию БД) при изменении ПО и/или потребностей пользователей.

3.3 Логическая и физическая целостность БД

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

Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Это означает следующее: либо успешно выполняются все составляющие транзакцию операции и СУБД фиксирует результат их выполнения (команда COMMIT), либо происходит откат всей транзакции (команда ROLLBACK) и все изменения отменяются. При таком подходе каждая операция модификации данных (или группа взаимосвязанных операций) рассматриваются системой как логически неделимая операция.

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

Одно из основных требований к СУБД - надежное хранение данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии автоматически восстановить последнее согласованное состояние БД после аппаратного или программного сбоя, в результате которых может быть нарушена логическая и/или физическая целостность данных. Для восстановления БД необходимо располагать некоторой дополнительной информацией. Наиболее распространённый метод поддержания такой избыточной информации - ведение журнала регистрации изменений.

Журнал регистрации изменений (журнал транзакций) - это часть БД, недоступная пользователям СУБД и поддерживаемая особо тщательно (иногда ведутся две копии журнала, хранимые на разных физических носителях). В журнал поступают все сведения обо всех изменениях основной части БД. Форма записи в журнал изменений зависит от СУБД. Это может быть порция данных, измененная в результате выполнения логической операции над данными, или, например, в результате минимальной внутренней операции модификации страницы (блока) внешней памяти.

Внесение изменений в журнал всегда носит опережающий характер по отношению к записи изменений в основную часть БД (протокол WAL - Write Ahead Log). Эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем изменённый объект попадёт во внешнюю память основной части БД. Если СУБД корректно соблюдает протокол WAL, то с помощью журнала транзакций можно решить все проблемы восстановления БД после сбоя, не препятствующего дальнейшему функционированию системы, например, после сбоя приложения или фонового процесса СУБД.

Примечание. Существуют сбои, после которых база данных не может быть восстановлена автоматически. Например, сбой записи на диск относится к таким фатальным ошибкам. Восстановление БД после фатального сбоя требует использования дополнительных системных средств и участия человека (администратора базы данных).

3.4 Администрирование БД

Основные задачи администрирования БД - обеспечение надежного и эффективного функционирования системы БД, адекватности содержания БД информационным потребностям пользователей, отображения в БД актуального состояния ПО.

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

1. Администрирование предметной области: поддержка представления БД на концептуальном уровне архитектуры СУБД (общем для всех приложений); адекватное отображение в БД изменений, происходящих в ПО. Последнее требование может подразумевать реструктуризацию (изменение схемы) БД и последующее приведение содержимого БД в соответствие с новой схемой.

2. Администрирование БД: поддержка представления БД в среде хранения, эффективная и надежная эксплуатация системы БД. Если на этом уровне проводится реорганизация БД (с целью повышения эффективности работы), то она заключается в следующем:

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

· изменения способов размещения данных в пространстве памяти, например:

o разбиение таблицы на части для распределения её по различным физическим носителям с целью распараллеливания доступа к ней;

o построение кластеров;

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

· изменения используемых методов доступа к данным, например, построение индексов или введение хеширования.

1. Администрирование приложений: поддержка представлений БД для различных групп пользователей механизмами внешнего уровня СУБД. При изменении концептуальной схемы БД или схемы хранения может потребоваться внесение соответствующих изменений в приложения.

2. Администрирование безопасности данных: предоставление пользователям прав на доступ к БД и настройка системных средств защиты от несанкционированного доступа.

В состав СУБД обычно включаются вспомогательные средства (различные утилиты), упрощающие администрирование БД.

4.5. Словари-справочники данных

Словарь-справочник данных (ССД) - это программная система, предназначенная для централизованного хранения и использования описания объектов БД (метаданных). Эта система содержит сведения:

· о составе и структуре базы данных;

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

· об ограничениях целостности;

· о вспомогательных объектах и компонентах ИС.

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

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

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

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

4. ФИЗИЧЕСКАЯ ОРГАНИЗАЦИЯ ДАННЫХ

4.1 Механизмы среды хранения и архитектура СУБД

Механизмы среды хранения БД служат для управления двумя группами ресурсов - ресурсами хранимых данных и ресурсами пространства памяти. В задачу этого механизма входит отображение структуры хранимых данных в пространство памяти, позволяющее эффективно использовать память и определить место размещения данных при запоминании и при поиске данных.

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

Механизмы среды хранения выполняют следующие операции:

1. При запоминании нового объекта:

· определение места размещения нового объекта "физической" БД в пространстве памяти;

· выделение необходимого ресурса памяти;

· запоминание этого объекта;

· формирование связей с другими объектами.

2. При поиске объекта:

· поиск места размещения объекта в пространстве памяти по заданным атрибутам или "адресу";

· выборка объектов для обработки.

3. При удалении объекта:

· удаление объекта с освобождением памяти (физическое удаление) или без освобождения (логическое удаление);

· разрушение связей с другими объектами.

Примечание: в реляционных СУБД формирование связей осуществляется на логическом уровне (т.е. по значениям атрибутов), а в иерархических и сетевых СУБД - на физическом уровне (по адресам записей).

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

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

4.2 Пространство памяти и размещение хранимых данных

Ресурсам пространства памяти соответствуют объекты внешней памяти ЭВМ, управляемые средствами операционной системы или СУБД.

Для обеспечения естественной структуризации хранимых данных, более эффективного управления ресурсами и/или для технологического удобства всё пространство памяти БД обычно разделяется на части (области, разделы и др.). (Во многих системах область соответствует файлу.) Области памяти используются для размещения хранимых записей одного или нескольких типов и разбиваются на пронумерованные страницы фиксированного размера. В большинстве систем обработку данных на уровне страниц ведёт операционная система (ОС), а обработку записей внутри страницы обеспечивает только СУБД.

Страницы представляются в среде ОС блоками внешней памяти, кластерами или секторами, доступ к которым осуществляется за одно обращение. В системах, которые позволяют управлять размером страницы, приходится искать компромисс между производительностью системы и требуемым объёмом оперативной памяти.

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

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

Удаление записей может быть логическим или физическим. В первом случае запись помечается как удаленная, но фактически она остаётся на прежнем месте. Фактическое удаление этой записи будет произведено либо при реорганизации БД, либо специальной сервисной программой, инициируемой администратором БД.

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

При динамической реорганизации страниц записи БД плотно размещаются вслед за заголовком страницы, а после них расположен свободный участок (рис. 5.1,а). Смещение начала свободного участка хранится в заголовке страницы. При удалении записи оставшиеся записи переписываются подряд в начало страницы и изменяется смещение начала свободного участка.



Рис. 5.1. Управление свободным простанством памяти на страницах

Если система ведёт список свободных участков, то возможны разные варианты. Ссылка на первый свободный участок на странице может храниться в заголовке страницы, и каждый свободный участок хранит ссылку на следующий (или признак конца списка) (рис. 5.1,б). Каждый освобождаемый участок включается в список свободных участков на странице.

Другой способ заключается в поддержке списков участков в виде отдельных структур (рис. 5.1,в). Список ведется как стек, очередь или упорядочённый список. В последнем случае упорядочение осуществляется по размеру свободного участка, что позволяет при размещении новой записи выбирать для неё наиболее подходящий по размеру участок.

Для учёта свободных участков в СУБД могут поддерживаться инвентарные страницы. Они создаются для области (или группы страниц) и содержат информацию о свободных участках в этой области. Это существенно ускоряет поиск свободного пространства для размещения новых записей.

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

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

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

Структура и представление хранимых данных, их размещение в пространстве памяти и используемые методы доступа определяются схемой хранения. Схема хранения оперирует в терминах типов объектов.

4.3 Структура хранимых данных

Единицей хранения данных в БД является хранимая запись. Она может представлять как полную запись концептуального уровня, так и некоторую её часть. Если запись разбивается на части, то её фрагменты представляются экземплярами хранимых записей каких-либо типов. Все части записи связываются указателями (ссылками) или размещаются по специальному закону так, чтобы механизмы междууровневого отображения могли опознать все компоненты и осуществить сборку полной записи концептуальной БД по запросу механизмов концептуального уровня.

Хранимые записи одного типа состоят из фиксированной совокупности полей и могут иметь формат фиксированной или переменной длины.

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

Хранимая запись состоит из двух частей:

1. Служебная часть. Используется для идентификации записи, задания её типа, хранения признака логического удаления, для кодирования значений элементов записи, для установления структурных ассоциаций между записями. Никакие пользовательские программы не имеют доступа к служебной части хранимой записи.

2. Информационная часть. Содержит значения элементов данных.

Элементы хранимой записи могут иметь фиксированную или переменную длину. При этом обычно элементы фиксированной длины хранятся в начале записи и размещаются в памяти с заранее определённых позиций, а за ними размещаются элементы переменной длины. Хранение элементов переменной длины осуществляется одним из двух способов: размещение через разделитель или хранение размера элемента данных. Наличие полей переменной длины позволяет не хранить незначащие символы и тем существенно снижает затраты памяти на хранение данных; но при этом увеличивается время на извлечение элементов записи.

Каждой записи БД система присваивает внутренний идентификатор, называемый (по стандарту CODASYL) ключом базы данных (КБД). Значение КБД формируется системой при размещении записи и содержит информацию, позволяющую однозначно определить место размещения записи (её адрес). В качестве КБД может выступать, например, последовательный номер записи в файле или совокупность адреса страницы и смещения от начала страницы.

Конкретные составляющие КБД зависят от операционной системы и от СУБД, точнее, от вида используемой адресации и от структуризации памяти, принятой в данной СУБД.

4.4 Виды адресации хранимых записей

Рассмотрим два вида адресации: прямую и косвенную.

Прямая адресация предусматривает указание непосредственного местоположения записи в пространстве памяти. Простейший вариант адресации используется в том случае, если в памяти хранится один вид записи фиксированной длины. Тогда в качестве адреса записи может использоваться её порядковый номер. (Прямая адресация используется, например, в системах ADABAS и dBaseIII PLUS).

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

Указанные недостатки можно преодолеть, используя косвенную адресацию. Существует множество способов косвенной адресации. Один из них состоит в том, что часть адресного пространства страницы выделяется под индекс страницы (рис. 5.2). Число статей (слотов) в нем одинаково для всех страниц. Ключом БД по-прежнему служит номер этой записи в области. С помощью простых арифметических действий можно получить по номеру записи номер нужной страницы и номер требуемого слота в индексе этой страницы. Найденный слот укажет местоположение записи на этой странице, где N, n - это соответственно номер страницы памяти и номер слота на этой странице, в котором хранится адрес записи (смещение от начала страницы).

Рис.5.2. Косвенная адресация с использованием индексов

При перемещении записи она остаётся на той же странице, и слот по-прежнему указывает на неё (меняется его содержимое, но не сам слот). Если запись не вмещается на страницу, она помещается на специально отведённые в данной области страницы переполнения, и соответствующий слот продолжает указывать место её размещения.

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

Также с адресацией связана другая функция среды хранения - поддержка связей между хранимыми записями.

4.5 Организация связей между хранимыми записями

Для сетевой и иерархической моделей данных эти связи поддерживаются на физическом уровне. Способы представления связей определяются схемой хранения и чаще всего основаны на использовании указателей или на размещении данных в смежных областях памяти.