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

Схема модулей СУБД

Компоненты СУБД выполняют важнейшие функции

Процессор запросов. 

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

Среда
СУБД состоит из следующих программных
компонентов:

1. Процессор
запросов.
Основной компонент СУБД, который
преобразует запросы в последовательность
низкоуровневых инструкций для контроллера
базы данных.

2. Контроллер
базы данных.
Этот компонент взаимодействует с
пользовательскими прикладными программами
и запросами. Для выполнения поступившего
запроса контроллер базы данных вызывает
контроллер файлов.

3. Контроллер
файлов.
Этот компонент предназначен для хранения
файлов и отвечает за распределение
дискового пространства. Он создает и
поддерживает список структур и индексы,
определенные во внутренней схеме СУБД.

4.
Процессор
языка DML.
Этот программный компонент преобразует
операторы DML,
вставленные в прикладные программы.
Для генераций соответствующего кода
препроцессор DML
взаимодействует с процессором запросов.

5. Компилятор
языка DDL.
Компилятор языка DDL
преобразует DDL-команды
в набор таблиц, содержащих «данные о
данных». Эти таблицы сохраняются в
системном каталоге, а управляющая
информация сохраняется в заголовках
файлов с данными.

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

Основные
компоненты среды СУБД представлены на
рис.1.1.

Рис.1.1.
Основные компоненты СУБД

1.4. Архитектура среды базы данных

Главная
особенность систем с базами данных
заключается в том, чтобы предложить
пользователям систем абстрактное
представление о данных,
скрыв особенности хранения и управления
ими. Поскольку база данных является
общим ресурсом информационной системы,
то каждому пользователю может потребоваться
свое, отличное от других представление
о данных, хранимых в системе. Для
удовлетворения этих потребностей
комитет стандартов ANSI/ SPARC признал
необходимость использования системы
трехуровневого подхода при описании
элементов данных. Трехуровневая
архитектура
состоит из: внешнего, концептуального
и внутреннего уровней абстракций.
Трехуровневая архитектура ANSI/SPARC
представлена на рис.1.2.

Основная
задача этой системы –

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

Рис.1.2.
Архитектура ANSI/SPARC

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

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

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

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

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

В
соответствии с терминологией ANSI/SPARC
, представление отдельного пользователя
называется внешним представлением.

Внешнее
представление
–

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

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

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

Концептуальное
представление
–

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

Концептуальное
представление –

это представление всего содержимого
базы данных.

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

Концептуальную
схему, как правило, определяет администратор
данных. Она определяет объекты, в которых
заинтересовано предприятие, а также
информацию, которую необходимо записывать
в этих объектах.

Соседние файлы в папке bd

• #
• #
• #
• #

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

Альтернативное определение:

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

Основные программные компоненты среды СУБД

Аппаратное обеспечение

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

Программное обеспечение

Включает в себя ПО:

• самой СУБД
• прикладных программ
• ОС
• сетевое

Приложения в основном создаются на языках 3-го (C, Fortran, Pascal и т.д.) и 4-го уровней (SQL и т.д.), операторы которых внедряются в программы на языках 3-го уровня. Языки 4-го уровня могут увеличить производительность системы и удобство для обслуживания программ. СУБД состоит из нескольких программных компонентов (модулей), выполняющих специфические операции. ОС предоставляет базовые службы, а СУБД представляет собой надстройку над ними.

Основные программные компоненты среды СУБД :

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

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

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

    Пример простейшей базы данных в виде таблицы

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

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

    Среди множества СУБД наиболее часто используются пакеты программ dBASE разных версий, FoxBase +, FoxPro, Fox Soft Ware, Clipper, совместимые с dBASE по системе команд и файлам.

    Например, БД, созданная в одной СУБД, может использоваться в другой совместимой с ней СУБД, имеющей формат файлов dBASE (*.dbf). Однако есть иные СУБД, например PARADOX и RBase, несовместимые с dBASE. Кроме СУБД для DOS, существуют СУБД, работающие в среде Windows, например Access, MS Works и др.

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

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

Типы данных

В СУБД можно обрабатывать следующие типы данных:

• Символьный (Character).
• Числовой (Numeric).
• Дата календарная (Date).
• Логический (Logical).
• имя поля
• тип поля
• длина поля
• количество десятичных знаков
• СУБД поддерживает пять типов полей:

    Данные символьного типа — это любая последовательность символов длиной не более 254.

     Числовые данные делятся на 2 вида: целые и вещественные. Длина числового поля должна быть достаточной, чтобы поместились знак числа, целая часть, точка (десятичная) и дробная часть.

    Значения календарной даты по умолчанию отображаются в Американском формате ММ/ЧЧ/ГГ (ММ-месяц, ЧЧ-число, ГГ-год). Длина этого поля установлена автоматически и равна 8.

    Данные логического типа имеют значения ДА (YES) и НЕТ (NO).

    В математической логике они называются Истина (True) и Ложь (False). В логических полях БД используются только первые буквы латинских слов Y,T,N,F. Длина логического поля равна 1.

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

Структура базы данных

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

Каждое поле БД характеризуется рядом параметров.

СИМВОЛЬНЫЙ — поля этого типа предназначены для хранения в них информации, которая рассматривается как строка символов и может состоять из букв, цифр, знаков препинания и т.п.

ЧИСЛОВОЙ — поля этого типа предназначены только для хранения чисел.

ДАТА — поля этого типа предназначены для хранения каких-либо дат в фиксированном формате: число, месяц, год.

ЛОГИЧЕСКИЙ — поля этого типа предназначены для хранения альтернативных значений вида «ДА» — «НЕТ» или «ПРАВДА» — «ЛОЖЬ». При этом значению «ДА» соответствует нахождение в поле символа «Т», а значение «НЕТ» — символа «F».

ПРИМЕЧАНИЕ (Memo) — поля этого типа используются для хранения фрагментов текста (примечаний).

    Длина поля — это ширина вертикального столбца таблицы в символах.

    Длина полей СИМВОЛЬНОГО типа представляют собой количество символов, которое Вы хотите уместить в поле.

    Длина поля ЧИСЛОВОГО типа равна количеству десятичных разрядов числа, умещающегося в поле, включая знак числа, десятичную точку, целую и дробную часть. Например, если Вы описываете значение «-546.78», то длина равна 7.

    Длина ЛОГИЧЕСКОГО поля всегда равна 1, так как его значение «T» или «F».

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

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

Голенищев Э.П., Клименко И.В. Информационное обеспечение систем управления — файл book_1.doc

приобрести
Голенищев Э.П., Клименко И.В. Информационное обеспечение систем управления
скачать (368.6 kb.)
Доступные файлы (5):

book_0.doc	27kb.	19.10.2005 11:16	скачать
book_1.doc	1230kb.	10.12.2003 18:02	скачать
book_2.doc	649kb.	10.12.2003 18:00	скачать
book_3.doc	667kb.	10.12.2003 17:59	скачать
n5.jpg	21kb.	19.10.2005 11:21	скачать

book_1.doc

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

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

Можно четко сформулировать требования к БД со стороны внешних пользователей [17]. База данных должна:

1. удовлетворять актуальным информационным потребностям пользователей, обеспечивать возможность хранения и модификации больших объемов многоаспектной информации;
2. обеспечивать заданный уровень достоверности хранимой информации и ее непротиворечивость;
3. обеспечивать доступ к данным только пользователей с соответствующими полномочиями;
4. обеспечить возможность поиска информации по произвольной группе признаков;
5. удовлетворять заданным требованиям производительности при обработке запросов;
6. иметь возможность реорганизации и расширения при изменении границ предметной области;
7. обеспечивать выдачу информации пользователям в различной форме;
8. обеспечивать простоту и удобство обращения внешних пользователей за информацией;
9. обеспечивать возможность одновременного обслуживания большого числа внешних пользователей.

Соответственно двум понятиям – «информация» и «данные» – в базах данных различают два аспекта рассмотрения вопросов: инфологический и даталогический [5, 17].

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

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

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

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

1.3. Понятие системы управления базами данных

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

Система управления базами данных – совокупность языковых и программных средств, предназначенных для создания, ведения и конкурентного использования базы данных многими пользователями [12].

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

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

Концепция централизованного управления данными имеет ряд неоспоримых преимуществ по сравнению с файловыми системами (см. прил.1).

1. Минимальная избыточность хранимых данных.
2. Непротиворечивость хранимых данных.
3. Многоаспектное использование данных.
4. Комплексная оптимизация.
5. Возможность стандартизации представления и обмена данными.
6. Возможность обеспечения санкционированного доступа к данным.

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

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

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

б) первоначальную загрузку данных в БД – так называемое создание БД;

в) обновление данных;

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

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

1.3.1. Обобщенная архитектура СУБД

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

Обобщенная структура связей программ и данных при использовании СУБД представлена на рис. 1.1 [5].

Рис. 1.1. Связь программ и данных при использовании СУБД

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

• физическом размещении в памяти данных и их описаний;
• механизмах поиска запрашиваемых данных;
• проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);
• способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;
• поддержании баз данных в актуальном состоянии и множестве других функций СУБД [5, 8, 17].

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

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

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

Рис. 1.2. Трехуровневая архитектура ANSI/SPARC

Представленный подход к описанию данных предложен комитетом ANSI/SPARC (Комитет Планирования Стандартов и Норм Национального Института Стандартизации США) и имеет целью отделение пользовательского представления о базе данных от ее физической организации. Такое отделение обеспечивает независимость хранимых данных и желательно по следующим причинам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Соответствующие трехуровневой архитектуре ANSI/ SPARC три уровня моделей данных для описания предметной области и реализации базы данных представлены на рис.1.3 [5].

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

Основные программные компоненты СУБД представлены на рис. 1.4 [7].

Рис. 1.3. Уровни моделей данных

Рис. 1.4. Основные компоненты типичной СУБД

• Процессор запросов. Это основной компонент СУБД, который преобразует запросы в последовательность низкоуровневых инструкций для контроллера базы данных.
• Контроллер базы данных. Этот компонент взаимодействует с запущенными пользователями прикладными программами и запросами. Контроллер базы данных принимает запросы и проверяет внешние и концептуальные схемы для определения тех концептуальных записей, которые необходимы для удовлетворения требований запроса. Затем контроллер базы данных вызывает контроллер файлов для выполнения поступившего запроса. Компоненты контроллера базы данных показаны на рис. 1.5 [7].
• Контроллер файлов манипулирует предназначенными для хранения данных файлами и отвечает за распределение доступного дискового пространства. Он создает и поддерживает список структур и индексов, определенных во внутренней схеме. Если используются хешированные файлы, то в его обязанности входит и вызов функций хеширования для генерации адресов записей. Однако контроллер файлов не управляет физическим вводом и выводом данных непосредственно, а лишь передает запросы соответствующим методам доступа, которые считывают данные в системные буферы или записывают их оттуда на диск.
• Препроцессор языка DML. Этот модуль преобразует внедренные в прикладные программы DML-операторы в вызовы стандартных функции базового языка. Для генерации соответствующего кода препроцессор языка DML должен взаимодействовать с процессором запросов.
• Компилятор языка DDL. Компилятор языка DDL преобразует DDL-команды в набор таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге, а управляющая информация — в заголовках файлов с данными.
• Контроллер словаря. Контроллер словаря управляет доступом к системному каталогу и обеспечивает работу с ним. Системный каталог доступен большинству компонентов СУБД.

Рис. 1.5. Компоненты контроллера БД

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

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

Для воплощения базы данных на физическом уровне помимо перечисленных выше модулей нужны некоторые другие структуры данных. К ним относятся файлы данных и индексов, а также системный каталог (см. гл. З).

1.3.2. Достоинства и недостатки СУБД

СУБД призваны решить недостатки файловых систем (см. прил.1), но при этом имеют и ряд специфических недостатков [7].

Достоинства СУБД

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

Контроль за избыточностью данных

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

Непротиворечивость данных

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

Больше полезной информации при том же объеме хранимых данных

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

Совместное использование данных

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

Поддержка целостности данных

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

Повышенная безопасность

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

Применение стандартов

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

Повышение эффективности с ростом масштабов системы

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

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

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

Повышение доступности данных

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

Улучшение показателей производительности

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

Упрощение сопровождения системы за счет независимости данных

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

Улучшенное управление параллельностью

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

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

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

Недостатки СУБД

• Сложность.
• Размер.
• Стоимость.
• Дополнительные затраты на аппаратное обеспечение.
• Затраты на преобразование.
• Производительность.
• Серьезные последствия при выходе системы из строя.

Сложность

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

Размер

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

Стоимость

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

Дополнительные затраты на аппаратное обеспечение

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

Затраты на преобразование

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

Производительность

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

Серьезные последствия при выходе системы из строя

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

1.3.3. Архитектура многопользовательских СУБД

В этом разделе приводятся различные типовые архитектурные решения, используемые при реализации многопользовательских СУБД, а именно схемы обычной телеобработки, файловый сервер и технология «клиент/сервер» [7].

Телеобработка

Традиционной архитектурой многопользовательских систем раньше считалась схема, получившая название «телеобработки», при которой один компьютер с единственным процессором был соединен с несколькими терминалами так. как показано на рис. 1.6 [7]. При этом вся обработка выполнялась в рамках единственного компьютера, а присоединенные к нему пользовательские терминалы были типичными «неинтеллектуальными» устройствами, не способными функционировать самостоятельно. С центральным процессором терминалы были связаны с помощью кабелей, по которым они посылали сообщения пользовательским приложениям (через подсистему управления обменом данными операционной системы). В свою очередь, пользовательские приложения обращались к необходимым службам СУБД. Таким же образом сообщения возвращались назад на пользовательский терминал. Недостатком является то, что при такой архитектуре основная и чрезвычайно большая нагрузка возлагалась на центральный компьютер, который должен был выполнять не только действия прикладных программ и СУБД, но и значительную работу по обслуживанию терминалов (например, форматирование данных, выводимых на экраны терминалов).

Рис. 1.6. Топология телеобработки

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

Файловый сервер

В среде файлового сервера обработка данных распределена в сети, обычно представляющей собой локальную вычислительную сеть (ЛВС). Файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Однако пользовательские приложения и сама СУБД размещены и функционируют на отдельных рабочих станциях, и обращаются к файловому серверу только по мере необходимости получения доступа к нужным им файлам – как показано на рис. 1.7[7].

Рис. 1.7. Архитектура с использованием файлового сервера

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

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

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

Технология «клиент/сервер»

Технология «клиент/сервер» была разработана с целью устранения недостатков, имеющихся в первых двух подходах. «Клиент/сервер» означает такой способ взаимодействия программных компонентов, при котором они образуют единую систему. Как видно из самого названия, существует некий клиентский процесс, требующий определенных ресурсов, а также серверный процесс, который эти ресурсы предоставляет. При этом совсем необязательно, чтобы они находились на одном и том же компьютере. На практике принято размещать сервер на одном узле локальной сети, а клиенты – на других узлах. На рис. 1.8 показана архитектура типа «клиент/сервер» [7].

Рис. 1.8. Общая схема построения систем с архитектурой «клиент/сервер»

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

полнение запроса и обновление данных. Помимо этого поддерживается управление параллельностью и восстановлением. Выполняемые клиентом и сервером операции приведены в табл. 1.1 [7].
Таблица 1.1

Клиент	Сервер
Управляет пользовательским интерфейсом	Принимает и обрабатывает запросы к базе данных со стороны клиентов
Принимает и проверяет синтаксис введенного пользователем запроса	Проверяет полномочия пользователей
Выполняет приложение	Гарантирует соблюдение ограничений целостности
Генерирует запрос к базе данных и передает его серверу	Выполняет запросы/обновления и возвращает результаты клиенту
Отображает полученные данные пользователю	Поддерживает системный каталог
	Обеспечивает параллельный доступ к базе данных
	Обеспечивает управление восстановлением

Этот тип архитектуры обладает приведенными ниже преимуществами.

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

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

---

1.2. Понятие базы данных