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

Базы данных. Классификация баз данных. Основные понятия баз данных.

 

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

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

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

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

Основой баз данных является информация (данные) о конкретной группе предметов (объектов).

Объект — это нечто существующее и различимое, обладаю­щее набором свойств. Отличие одного объекта от другого опреде­ляется конкретными значениями свойств. Объекты бывают материальные и идеальные. К материальным объектам относят­ся предметы материального мира: автомобиль, здания, предметы мебели и т. д. К идеальным (абстрактным) объектам можно отне­сти спектакль, содержание книги и т. д.

Сущность — отображение объекта в памяти человека или ком­пьютера.

Параметр — конкретное значение любого из свойств объекта.

Атрибут — конкретное значение любого из свойств сущно­сти.

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

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

Поле — это один элемент записи, в котором хранится конк­ретное значение атрибута.

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

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

Хранимая процедура — это приложение (программа), объеди­няющая запросы пользователя и процедурную логику и храня­щаяся в базе данных.

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

Ограничение — это логическое условие, накладывающее огра­ничение (интервал допустимых значений) на значение атрибута.

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

- правила или ограничения;

- событие, которое требует проверки правил и ограничений;

- предусмотренные действия, которые выполняются с по­мощью

процедуры или последовательности процедур.

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

- отсутствие проверки;

- проверка допустимости;

- запрет операции;

- каскадное выполнение операций обновления или удаления данных

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

- установка пустого значения по умолчанию.

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

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

Классификация баз данных:

По характеру хранимой информации:
— Фактографические (картотеки),
— Документальные (архивы)

По способу хранения данных:
— Централизованные (хранятся на одном компьютере),
— Распределенные (используются в локальных и глобальных компьютерных сетях).

По структуре организации данных:
— Табличные (реляционные),
— Иерархические.

Задание первичных и альтернативных ключей

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

 

 

Физическое описание модели

На этом этапе каждая таблица, созданная на четвертом этапе:

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

- каждый атрибут (концептуальное требование) таблицы получает свое

имя, тип и размер;

- для каждого ключа, как первичного, так и внешнего, опре­деляются

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

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

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

 

 

Иерархическая модель.

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

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

 

 

Рисунок 2 - Логическая иерархическая модель

В терминологии иерархической моде­ли используются более конкретные понятия: «элемент» (узел); «уро­вень» и «связь». Узел чаще всего представляет собой атрибут (при­знак), описывающий некоторый объект.

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

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

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

 

Рисунок 3 – Пример иерархической модели данных

Сетевая модель.

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

Сетевая модель данных - это представление данных сетевыми структурами типов записей и связанных отношениями мощности один-к-одному или один-ко-многим.

Сетевая модель более демократична. В сетевой модели отсутству­ет понятие главного и подчиненного объекта (рисунок 4,5). Один и тот же объект может выступать как главный и как подчиненный, то есть иметь любое количество взаимосвязей. Здесь допустимы связи на одном уровне. Эта модель использует ту же термино­логию, что и иерархическая модель: «узел», «уровень» и «связь».

 

Рисунок 4 - Логическая сетевая модель

Как известно из теории графов, сетевой граф мо­жет быть преобразован в граф-дерево.

 

Рисунок 5 – Пример сетевой модели данных

 

Реляционная модель.

В 1970-1971 годах Е.Ф.Кодд опубликовал две статьи, в которых ввел реляционную модель данных и реляционные языки обработки данных - реляционную алгебру и реляционное исчисление.

Реляционная алгебра Процедурный язык обработки реляционных таблиц.

Реляционное исчисление Непроцедурный язык создания запросов.

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

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

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

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

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

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

Таблица 1 – Структура реляционной таблицы

 

Имя файла
Поле	Признак ключа	Формат поля
Имя (обозначение)	Полное наименование	Тип	Длина	Точность (для чисел)	N/NN
имя1
…
имя n

Рассмотрим пример реляционной модели данных (таблица 2).

 

Таблица 2 - Детали приборов

Код	Расположение поверхностей	Дополнительная характеристика
	Тела вращения	Валы
	Тела вращения	Втулки
	Не тела вращения	Плоские
	Не тела вращения	Объемные

 

 

На рисунке 6 показано разделение таблицы 2 на две связанные таблицы.

 

Код	Дополнительная характеристика
1.1	Валы
1.2	Втулки
2.1	Плоские
2.2	Объёмные

 

Код	Расположение поверхностей
	Тела вращения
	Не тела вращения

 

 

 

Реляционные модели данных, или реляционные базы данных, являются в настоящее время основным способом в проектировании и организации информационных систем в производстве и бизнесе.

 

Свойства отношений

Отношение обладает следующими характеристиками:

отношение имеет имя, которое отличается от имен всех других отношений;

каждая ячейка отношения содержит только атомарное (неделимое) значение;

каждый атрибут имеет уникальное имя;

значения атрибута берутся из одного и того же домена;

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

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

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

Отношение не может содержать кортежей-дубликатов, т.е. каждая строка должна быть обязательно уникальной.

Основные этапы, на которые разбивается процесс проектирования базы данных информационной системы:

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

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

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

моделирование и интеграция всех представлений

По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь".

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

3) Физическое проектирование - определение особенностей хранения данных, методов доступа и т.д.

Различие уровней представления данных на каждом этапе проектирования представлено в следующей таблице:

 

КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ - сущности - атрибуты - связи	Представление аналитика
ЛОГИЧЕСКИЙ УРОВЕНЬ - записи - элементы данных - связи между записями	Представление программиста
ФИЗИЧЕСКИЙ УРОВЕНЬ - группирование данных - индексы - методы доступа	Представление администратора

 

Атомарность

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

Согласованность

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

Примеры ограничений целостности:

1. Возраст сотрудника не может быть < 18 и > 65 лет.

2. Каждый сотрудник имеет уникальный табельный номер.

3. Сотрудник обязан числиться в одном отделе

Изолированность

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

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

Принципы совместной обработки (сериализации) транзакций:

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

¡ Результат совместного выполнения транзакций должен быть эквивалентен результат)' их последовательного выполнения. Т.е., если две транзакции выполняются параллельно, то полагается, что результат будет такой же, как если бы сначала выполнялась первая, а затем вторая транзакция, или сначала вторая, а потом первая.

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

При выполнении транзакции современные СУБД могут блокировать всю БД, отношение, группу строк или отдельную строку.

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

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

Транзакции могут попасть в ситуацию взаимоблокировки

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

Долговечность

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

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

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

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

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

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

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

Локальные и глобальные транзакции

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

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

 

 

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

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

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

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

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

В сетевой модели допускаются отношения "многие ко многим", а записи не зависят друг от друга. При удалении записи удаляются и все ее связи, но не сами связанные записи.

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

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

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

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

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

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

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

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

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

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

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

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

По архитектуре СУБД и организации хранения данных делятся:

локальные СУБД (все части локальной СУБД размещаются на одном компьютере);

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

По способу доступа СУБД к базе данных:

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

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

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

Функциональность СУБД

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

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

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

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

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

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

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

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

Языки доступа к данным и интерфейсы прикладного программирования. СУБД обеспечивает доступ к данным с помощью языка запросов. Язык запросов это непроцедурный язык, т. е. он предоставляет пользователю возможность определять, что необходимо выполнить, без необходимости указывать, как это нужно выполнять. В состав языка запросов СУБД входят два основных компонента: язык определения данных (data definition language, DDL) и язык манипулирования данными (data manipulation language, DML). DDL определяет структуры, в которых разме­щаются данные, a DML позволяет конечным пользователям извлекать данные из БД. СУБД также предоставляет программистам доступ к данным из процедурных языков третьего поколения (3GL), таких как COBOL, С, PASCAL, Visual Bask и др. В составе СУБД имеются административные утилиты, предназначенные для администраторов базы данных (DBA) и проектировщиков БД, для внедрения, текущего контроля и обслуживания базы данных.

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

- конечный пользователь может получать ответ на запросы, заполняя экранные формы с помощю выбранного им браузера;

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