С самого начала
развития вычислительной техники образовались два основных направления ее
использования.
Первое направление –
применение вычислительной техники для выполнения численных расчетов, которые
слишком долго или вообще невозможно производить вручную. Становление этого
направления способствовало интенсификации методов численного решения сложных
математических задач, развитию класса языков программирования, ориентированных
на удобную запись численных алгоритмов, становлению обратной связи с
разработчиками новых архитектур ЭВМ.
Второе направление –
это использование средств вычислительной техники в автоматических или
автоматизированных информационных системах.
В самом широком смысле
информационная система представляет собой программный комплекс, функции
которого состоят в поддержке надежного хранения информации в памяти компьютера,
выполнении специфических для данного приложения преобразований информации и/или
вычислений, предоставлении пользователям удобного и легко осваиваемого
интерфейса. Обычно объемы информации, с которыми приходится иметь дело таким
системам, достаточно велики, а сама информация имеет достаточно сложную
структуру. Классическими примерами информационных систем являются банковские
системы, системы резервирования авиационных или железнодорожных билетов, мест в
гостиницах и т.д.
На самом деле, второе
направление возникло несколько позже первого. Это связано с тем, что на заре
вычислительной техники компьютеры обладали ограниченными возможностями в части
памяти. Понятно, что можно говорить о надежном и долговременном хранении
информации только при наличии запоминающих устройств, сохраняющих информацию
после выключения электрического питания. Оперативная память этим свойством
обычно не обладает.
Вначале использовались
два вида устройств внешней памяти: магнитные ленты и барабаны. При этом емкость
магнитных лент была достаточно велика, но по своей физической природе они
обеспечивали последовательный доступ к данным. Магнитные же барабаны (они больше
всего похожи на современные магнитные диски с фиксированными головками) давали
возможность произвольного доступа к данным, но были ограниченного размера.
Легко видеть, что
указанные ограничения не очень существенны для чисто численных расчетов. Даже
если программа должна обработать (или произвести) большой объем информации, при
программировании можно продумать расположение этой информации во внешней памяти,
чтобы программа работала как можно быстрее.
С другой стороны, для
информационных систем, в которых потребность в текущих данных определяется
пользователем, наличие только магнитных лент и барабанов неудовлетворительно.
Одним из естественных требований к таким системам является средняя быстрота
выполнения операций.
Именно требования к
вычислительной технике со стороны нечисленных приложений вызвали появление
съемных магнитных дисков с подвижными головками, что явилось революцией в
истории вычислительной техники. Эти устройства внешней памяти обладали
существенно большей емкостью, чем магнитные барабаны, обеспечивали
удовлетворительную скорость доступа к данным в режиме произвольной выборки, а
возможность смены дискового пакета на устройстве позволяла иметь практически
неограниченный архив данных.
С появлением магнитных
дисков началась история систем управления данными во внешней памяти. До этого
каждая прикладная программа, которой требовалось хранить данные во внешней
памяти, сама определяла расположение каждой порции данных на магнитной ленте или
барабане и выполняла обмены между оперативной и внешней памятью с помощью
программно-аппаратных средств низкого уровня (машинных команд или вызовов
соответствующих программ операционной системы). Такой режим работы не позволяет
или очень затрудняет поддержание на одном внешнем носителе нескольких архивов
долговременно хранимой информации. Кроме того, каждой прикладной программе
приходилось решать проблемы именования частей данных и структуризации данных во
внешней памяти.
Историческим шагом
явился переход к использованию централизованных систем управления файлами.
С точки зрения прикладной программы файл – это именованная область внешней
памяти, в которую можно записывать и из которой можно считывать данные. Правила
именования файлов, способ доступа к данным, хранящимся в файле, и структура этих
данных зависят от конкретной системы управления файлами и, возможно, от типа
файла. Система управления файлами берет на себя распределение внешней памяти,
отображение имен файлов в соответствующие адреса во внешней памяти и обеспечение
доступа к данным.
Практически во всех
современных компьютерах основными устройствами внешней памяти являются
жесткие магнитные диски с подвижными головками, и именно они служат для
хранения файлов. Накопитель на жёстких магнитных дисках (англ. HDD – Hard Disk
Drive) – это запоминающее устройство большой ёмкости, в котором носителями
информации являются круглые алюминиевые пластины — платтеры, обе поверхности
которых покрыты слоем магнитного материала.
Рабочие поверхности
платтеров разделены на кольцевые концентрические дорожки, а дорожки — на
секторы. Головки считывания-записи вместе с их несущей конструкцией и дисками
заключены в герметически закрытый корпус, называемый модулем данных.
Поверхность платтера
имеет магнитное покрытие толщиной всего лишь в 1,1 мкм, а также слой смазки для
предохранения головки от повреждения при опускании и подъёме на ходу. При
вращении платтера над ним образуется воздушный слой, который обеспечивает
воздушную подушку для зависания головки на высоте 0,5 мкм над поверхностью
диска.
Жесткие диски имеют
большую ёмкость. Скорость вращения шпинделя (вращающего вала) обычно составляет
7200 об/мин, среднее время поиска данных 9 мс, средняя скорость передачи данных
до 60 Мбайт/с.
Жесткий диск вращается
непрерывно. Все современные накопители снабжаются встроенным кэшем, повышающим
их производительность. Жесткий диск связан с процессором через контроллер
жесткого диска.

Рисунок
1.
Устройство жесткого диска
При разметке жесткого
диска каждая дорожка размечается на одно и то же количество блоков таким
образом, что в каждый блок можно записать по максимуму одно и то же число
байтов. Таким образом, для произведения обмена с жестким диском на уровне
аппаратуры нужно указать номер цилиндра, номер поверхности, номер блока на
соответствующей дорожке и число байтов, которое нужно записать или прочитать от
начала этого блока.
Однако эта возможность
обмениваться с магнитными дисками порциями меньше объема блока в настоящее время
не используется в файловых системах. Во всех файловых системах явно или неявно
выделяется некоторый базовый уровень, обеспечивающий работу с файлами,
представляющими набор прямо адресуемых в адресном пространстве файла блоков.
Размер этих логических блоков файла совпадает или кратен размеру физического
блока диска и обычно выбирается равным размеру страницы виртуальной памяти,
поддерживаемой аппаратурой компьютера совместно с операционной системой.
Все современные
файловые системы поддерживают многоуровневое именование файлов за счет
поддержания во внешней памяти дополнительных файлов со специальной структурой –
каталогов. Каждый каталог содержит имена каталогов и/или файлов,
содержащихся в данном каталоге. Таким образом, полное имя файла состоит из
списка имен каталогов плюс имя файла в каталоге, непосредственно содержащем
данный файл. Разница между способами именования файлов в разных файловых
системах состоит в том, с чего начинается эта цепочка имен.
В этом отношении
имеются два крайних варианта. Во многих системах управления файлами требуется,
чтобы каждый архив файлов (полное дерево справочников) целиком располагался на
одном дисковом пакете (или логическом диске, разделе физического дискового
пакета, представляемом с помощью средств операционной системы как отдельный
диск). В этом случае полное имя файла начинается с имени дискового устройства,
на котором установлен соответствующий диск. Можно назвать эту организацию
поддержанием изолированных файловых систем.
Другой крайний вариант
был реализован в файловой системе операционной системы Multics, где
пользователи представляли всю совокупность каталогов и файлов как единое
дерево. Полное имя файла начиналось с имени корневого каталога, и пользователь
не обязан был заботиться об установке на дисковое устройство каких-либо
конкретных дисков. Сама система, выполняя поиск файла по его имени, запрашивала
установку необходимых дисков. Такую файловую систему можно назвать полностью
централизованной.
Поскольку файловые
системы являются общим хранилищем файлов, принадлежащих разным пользователям,
системы управления файлами должны обеспечивать авторизацию доступа к файлам. В
общем виде подход состоит в том, что по отношению к каждому зарегистрированному
пользователю данной вычислительной системы для каждого существующего файла
указываются действия, которые разрешены или запрещены данному пользователю.
Существовали попытки реализовать этот подход в полном объеме. Но это вызывало
слишком большие накладные расходы как по хранению избыточной информации, так и
по использованию этой информации для контроля правомочности доступа.
В большинстве
современных систем управления файлами применяется подход к защите файлов,
впервые реализованный в ОС UNIX. В этой системе каждому зарегистрированному
пользователю соответствует пара целочисленных идентификаторов: идентификатор
группы, к которой относится этот пользователь, и его собственный идентификатор в
группе. Соответственно, при каждом файле хранится полный идентификатор
пользователя, который создал этот файл, и отмечается, какие действия с файлом
может производить он сам, какие действия с файлом доступны для других
пользователей той же группы, и что могут делать с файлом пользователи других
групп. Эта информация очень компактна, при проверке требуется небольшое
количество действий, и этот способ контроля доступа удовлетворителен в
большинстве случаев.
Если операционная
система поддерживает многопользовательский режим, вполне реальна ситуация, когда
два или более пользователей одновременно пытаются работать с одним и тем же
файлом. Если все эти пользователи собираются только читать файл, ничего
страшного не произойдет. Но если хотя бы один из них будет изменять файл, для
корректной работы этой группы требуется взаимная синхронизация.
Потребности
информационных систем
главным образом ориентированы на хранение, выбор и модификацию постоянно
существующей информации. Структура информации зачастую очень сложна, и хотя
структуры данных различны в разных информационных системах, между ними часто
бывает много общего. На начальном этапе использования вычислительной техники для
управления информацией проблемы структуризации данных решались индивидуально в
каждой информационной системе. Производились необходимые надстройки над
файловыми системами (библиотеки программ), подобно тому, как это делается в
компиляторах, редакторах и т.д.
Но поскольку
информационные системы требуют сложных структур данных, эти дополнительные
индивидуальные средства управления данными являлись существенной частью
информационных систем и практически повторялись от одной системы к другой.
Стремление выделить общую часть информационных систем, ответственную за
управление сложно структурированными данными, явилось первой побудительной
причиной создания системы управления базами данных (СУБД). Очень скоро
стало понятно, что невозможно обойтись общей библиотекой программ, реализующей
над стандартной базовой файловой системой более сложные методы хранения данных.
Как было сказано ранее,
традиционных возможностей файловых систем оказывается недостаточно для
построения даже простых информационных систем. Далее представлен ряд
потребностей, которые не покрываются возможностями систем управления файлами:
- поддержание
логически согласованного набора файлов;
- обеспечение
языка манипулирования данными;
- восстановление
информации после разного рода сбоев;
- реально
параллельная работа нескольких пользователей.
Можно считать, что если
прикладная информационная система опирается на некоторую систему управления
данными, обладающую этими свойствами, то эта система управления данными является
системой управления базами данных (СУБД).
Основные функции СУБД:
1.
Непосредственное управление данными во внешней памяти.
Эта функция включает обеспечение необходимых структур внешней памяти как для
хранения данных, непосредственно входящих в БД, так и для служебных целей,
например, для убыстрения доступа к данным в некоторых случаях (обычно для этого
используются индексы). В некоторых реализациях СУБД активно используются
возможности существующих файловых систем, в других работа производится вплоть до
уровня устройств внешней памяти. Но подчеркнем, что в развитых СУБД пользователи
в любом случае не обязаны знать, использует ли СУБД файловую систему, и если
использует, то как организованы файлы. В частности, СУБД поддерживает
собственную систему именования объектов БД.
2.
Управление
буферами оперативной памяти.
СУБД обычно работают с БД значительного размера; по крайней мере этот размер
обычно существенно больше доступного объема оперативной памяти. Если при
обращении к любому элементу данных будет производиться обмен с внешней памятью,
то вся система будет работать со скоростью устройства внешней памяти.
Практически единственным способом реального увеличения этой скорости является
буферизация данных в оперативной памяти. При этом, даже если операционная
система производит общесистемную буферизацию (как в случае ОС UNIX), этого
недостаточно для целей СУБД, которая располагает гораздо большей информацией о
полезности буферизации той или иной части БД. Поэтому в развитых СУБД
поддерживается собственный набор буферов оперативной памяти с собственной
дисциплиной замены буферов.
3.
Управление
транзакциями.
Транзакция – это последовательность операций над базой данных (БД),
рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и
СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней
памяти, либо ни одно из этих изменений никак не отражается на состоянии БД.
Понятие транзакции необходимо для поддержания логической целостности БД. То
свойство, что каждая транзакция начинается при целостном состоянии БД и
оставляет это состояние целостным после своего завершения, делает очень удобным
использование понятия транзакции как единицы активности пользователя по
отношению к БД. При соответствующем управлении параллельно выполняющимися
транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать
себя единственным пользователем.
4.
Журнализация.
Одним из основных требований к СУБД является надежность хранения данных во
внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в
состоянии восстановить последнее согласованное состояние БД после любого
аппаратного или программного сбоя. Обычно рассматриваются два возможных вида
аппаратных сбоев:
- так называемые
мягкие сбои, которые можно трактовать как внезапную остановку работы
компьютера (например, аварийное выключение питания),
- жесткие сбои,
характеризуемые потерей информации на носителях внешней памяти.
Примерами программных сбоев могут быть:
- аварийное
завершение работы СУБД (по причине ошибки в программе или в результате
некоторого аппаратного сбоя),
- аварийное
завершение пользовательской программы, в результате чего некоторая транзакция
остается незавершенной.
Понятно, что в любом случае для восстановления БД нужно располагать некоторой
дополнительной информацией. Другими словами, поддержание надежности хранения
данных в БД требует избыточности хранения данных, причем та часть данных,
которая используется для восстановления, должна храниться особо надежно.
Наиболее распространенным методом поддержания такой избыточной информации
является ведение журнала изменений БД. Журнал – это особая часть БД,
недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда
поддерживаются две копии журнала, располагаемые на разных физических дисках), в
которую поступают записи обо всех изменениях основной части БД.
Во
всех случаях придерживаются стратегии "упреждающей" записи в журнал (так
называемого протокола Write Ahead Log – WAL). Эта стратегия заключается в том,
что запись об изменении любого объекта БД должна попасть во внешнюю память
журнала раньше, чем измененный объект попадет во внешнюю память основной части
БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью
журнала можно решить все проблемы восстановления БД после любого сбоя.
5.
Поддержка
языков БД. Для
работы с базами данных используются специальные языки, в целом называемые
языками баз данных. В ранних СУБД поддерживалось несколько специализированных по
своим функциям языков. Чаще всего выделялись два языка – язык определения
схемы БД (SDL – Schema Definition Language) и язык манипулирования
данными (DML – Data Manipulation Language). SDL служил главным образом для
определения логической структуры БД, т.е. той структуры БД, какой она
представляется пользователям. DML содержал набор операторов манипулирования
данными, т.е. операторов, позволяющих заносить данные в БД, удалять,
модифицировать или выбирать существующие данные.
В
современных СУБД обычно поддерживается единый интегрированный язык, содержащий
все необходимые средства для работы с БД, начиная от ее создания, и
обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным
языком наиболее распространенных в настоящее время реляционных СУБД является
язык SQL (Structured Query Language).
Прежде всего, язык SQL сочетает средства SDL и DML, т.е. позволяет определять
схему реляционной БД и манипулировать данными. При этом именование объектов БД
(для реляционной БД –именование таблиц и их столбцов) поддерживается на языковом
уровне в том смысле, что компилятор языка SQL производит преобразование имен
объектов в их внутренние идентификаторы на основании специально поддерживаемых
служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с
именами таблиц и их столбцов.
Естественно,
организация типичной СУБД и состав ее компонентов соответствует
рассмотренному нами набору функций. Логически в современной
реляционной СУБД можно выделить:
- ядро СУБД (Data
Base Engine) – наиболее внутренняя часть,
- компилятор
языка БД (обычно SQL),
- подсистема поддержки времени
выполнения,
- набор утилит.
В некоторых системах
эти части выделяются явно, в других – нет, но логически такое разделение можно
провести во всех СУБД.
Ядро СУБД
отвечает за:
- управление
данными во внешней памяти,
- управление
буферами оперативной памяти,
- управление
транзакциями и журнализацию.
Соответственно, можно
выделить следующие ядра (по крайней мере, логически, хотя в некоторых системах
эти компоненты выделяются явно):
- менеджер
данных,
- менеджер
буферов,
- менеджер
транзакций и менеджер журнала.
Функции этих
компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все эти
компоненты должны взаимодействовать по тщательно продуманным и проверенным
протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным
пользователям напрямую и используемым в программах, производимых компилятором
SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро
СУБД является основной резидентной частью СУБД. При использовании архитектуры
"клиент-сервер" ядро является основной составляющей серверной части системы.
Главная задача
компилятора языка БД – компиляция операторов языка БД в некоторую
выполняемую программу. Основной проблемой реляционных СУБД является то, что
языки этих систем (а это, как правило, SQL) являются непроцедурными, т.е. в
операторе такого языка специфицируется некоторое действие над БД, но эта
спецификация не является процедурой, а лишь описывает в некоторой форме условия
совершения желаемого действия. Поэтому компилятор должен решить, каким образом
выполнять оператор языка прежде, чем произвести программу. Применяются
достаточно сложные методы оптимизации операторов.
Результатом компиляции
является выполняемая программа, представляемая в некоторых системах в машинных
кодах, но более часто в выполняемом внутреннем машинно-независимом коде. В
последнем случае реальное выполнение оператора производится с привлечением
подсистемы поддержки времени выполнения, представляющей собой, по сути дела,
интерпретатор этого внутреннего языка.
В отдельные утилиты
БД обычно выделяют такие процедуры, которые слишком накладно выполнять с
использованием языка БД, например:
- загрузка и
выгрузка БД,
- сбор
статистики,
- глобальная
проверка целостности БД и т.д.
Утилиты программируются
с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь
ядра.
|