Банки и базы данных

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

• Банки и базы данных
• Оглавление
• Лекция 1. Назначение и основные компоненты системы баз данных
• 1.1 Данные и ЭВМ
• 1.2 Концепция баз данных
• 1.3 Основные функции СУБД
• 1.3.1 Непосредственное управление данными во внешней памяти
• 1.3.2 Управление буферами оперативной памяти
• 1.3.3 Управление транзакциями
• 1.3.4 Журнализация
• 1.3.5 Поддержка языков БД
• 1.4 Типовая организация современной СУБД
• 1.5 Классификация пользователей СУБД
• Лекция 2. Инфологическая модель данных «Сущность-связь»
• 2.1 Основные понятия
• 2.2 Характеристика связей и язык моделирования
• 2.3 Классификация сущностей*
• 2.4 О первичных и внешних ключах
• 2.5 Ограничения целостности
• Лекция 3. Ранние подходы к организации БД. Иерархические и сетевые СУБД
• 3.1 Иерархические системы
• 3.1.1 Иерархические структуры данных
• 3.1.2 Манипулирование данными
• 3.1.3 Ограничения целостности
• 3.2 Сетевые системы
• 3.2.1 Сетевые структуры данных
• 3.2.2 Манипулирование данными
• 3.2.3 Ограничения целостности
• 3.3 Достоинства и недостатки
• Лекция 4. Реляционная структура данных. Общие понятия реляционного подхода к организации БД. Основные концепции и термины
• 4.1 Базовые понятия реляционных баз данных
• 4.1.1 Тип данных
• 4.1.2 Домен
• 4.1.3 Схема отношения, схема базы данных
• 4.1.4 Кортеж, отношение
• 4.2 Фундаментальные свойства отношений
• 4.2.1 Отсутствие кортежей-дубликатов
• 4.2.2 Отсутствие упорядоченности кортежей
• 4.2.3 Отсутствие упорядоченности атрибутов
• 4.2.4 Атомарность значений атрибутов
• 4.3 Общая характеристика реляционной модели данных
• Лекция 5. Базисные средства манипулирования реляционными данными
• 5.1 Реляционная алгебра
• 5.1.1 Общая интерпретация реляционных операций
• 5.1.2 Замкнутость реляционной алгебры и операция переименования
• Лекция 6. Базисные средства манипулирования реляционными данными
• 6.1 Особенности теоретико-множественных операций реляционной алгебры
• 6.2 Специальные реляционные операции
• 6.3 Реляционное исчисление
• Лекция 7. Нормализация данных. 1-я, 2-я, 3-я нормальные формы
• 7.1 Функциональная зависимость
• 7.2 Вторая нормальная форма
• 7.3 Третья нормальная форма
• Лекция 8. Нормализация данных. Нормальные формы более высоких порядков
• 8.1 Нормальная форма Бойса-Кодда
• 8.2 Многозначные зависимости. Четвертая нормальная форма
• 8.3 Зависимость соединения. Пятая нормальная форма
• Лекция 9. Структуры внешней памяти
• 9.1 Хранение отношений
• 9.2 Индексы
• 9.3 Журнальная информация
• 9.4 Служебная информация
• Лекция 10. Методы организации индексов
• 10.1 Методы поиска по дереву
• 10.2 Автоматическое поддержание свойства сбалансированности B-деревьев при выполнении операций занесения и удаления записей
• 10.3 Хэширование
• Лекция 11. Защита БД
• 11.1 Обеспечение защиты данных в базе
• 11.1.1 Идентификация пользователя
• 11.1.2 Управление доступом
• 11.1.3 Защита данных при статистической обработке
• 11.1.4 Физическая защита
• Лекция 12. Целостность БД
• 12.1 Целостность сущности и ссылок
• 12.2 Обеспечение целостности данных
• 12.3 Транзакции и целостность баз данных
• 12.4 Изолированность пользователей
• 12.5 Сериализация транзакций
• Лекция 13. Степень соответствия СУБД реляционной модели
• 13.1 Степень соответствия СУБД реляционной модели
• Список литературы по теме курса
• Лекция 1. Назначение и основные компоненты системы баз данных
• Предметом курса являются системы управления базами данных (СУБД). Это очень важная тема, без основательного знакомства с которой в наше время невозможно быть не только квалифицированным программистом, но даже и грамотным пользователем компьютеров.
• 1.1 Данные и ЭВМ
• Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.
• Традиционно фиксация данных осуществляется с помощью конкретного средства общения (например, с помощью естественного языка или изображений) на конкретном носителе (например, камне или бумаге). Обычно данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика) фиксируются совместно, так как естественный язык достаточно гибок для представления того и другого. Примером может служить утверждение "Стоимость авиабилета 128". Здесь "128" - данное, а "Стоимость авиабилета" - его семантика.
• Нередко данные и интерпретация разделены. Например, "Расписание движения самолетов" может быть представлено в виде таблицы, в верхней части которой (отдельно от данных) приводится их интерпретация. Такое разделение затрудняет работу с данными (попробуйте быстро получить сведения из нижней части таблицы).
• Ведение (сопровождение, поддержка) данных - термин объединяющий действия по добавлению, удалению или изменению хранимых данных.
• Применение ЭВМ для ведения и обработки данных обычно приводит к еще большему разделению данных и интерпретации. ЭВМ имеет дело главным образом с данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в явной форме (ЭВМ не "знает", является ли "21.50" стоимостью авиабилета или временем вылета). Почему же это произошло?
• Существует по крайней мере две исторические причины, по которым применение ЭВМ привело к отделению данных от интерпретации. Во-первых, ЭВМ не обладали достаточными возможностями для обработки текстов на естественном языке - основном языке интерпретации данных. Во-вторых, стоимость памяти ЭВМ была первоначально весьма велика. Память использовалась для хранения самих данных, а интерпретация традиционно возлагалась на пользователя. Пользователь закладывал интерпретацию данных в свою программу, которая "знала", например, что шестое вводимое значение связано с временем прибытия самолета, а четвертое - с временем его вылета. Это существенно повышало роль программы, так как вне интерпретации данные представляют собой не более чем совокупность битов на запоминающем устройстве.
• Жесткая зависимость между данными и использующими их программами создает серьезные проблемы в ведении данных и делает использования их менее гибкими.
• Нередки случаи, когда пользователи одной и той же ЭВМ создают и используют в своих программах разные наборы данных, содержащие сходную информацию. Иногда это связано с тем, что пользователь не знает (либо не захотел узнать), что в соседней комнате или за соседним столом сидит сотрудник, который уже давно ввел в ЭВМ нужные данные. Чаще потому, что при совместном использовании одних и тех же данных возникает масса проблем.
• Разработчики прикладных программ (написанных, например, на Бейсике, Паскале или Си) размещают нужные им данные в файлах, организуя их наиболее удобным для себя образом. При этом одни и те же данные могут иметь в разных приложениях совершенно разную организацию (разную последовательность размещения в записи, разные форматы одних и тех же полей и т.п.). Обобществить такие данные чрезвычайно трудно: например, любое изменение структуры записи файла, производимое одним из разработчиков, приводит к необходимости изменения другими разработчиками тех программ, которые используют записи этого файла.
• Для иллюстрации обратимся к примеру, приведенному в книге: У. Девис, Операционные системы, М., Мир, 1980:
• "Несколько лет назад почтовое ведомство (из лучших побуждений) пришло к решению, что все адреса должны обязательно включать почтовый индекс. Во многих вычислительных центрах это, казалось бы, незначительное изменение привело к ужасным последствиям. Добавление к адресу нового поля, содержащего шесть символов, означало необходимость внесения изменений в каждую программу, использующую данные этой задачи в соответствии с изменившейся суммарной длиной полей. Тот факт, что какой-то программе для выполнения ее функций не требуется знания почтового индекса, во внимание не принимался: если в некоторой программе содержалось обращение к новой, более длинной записи, то в такую программу вносились изменения, обеспечивающие дополнительное место в памяти.
• В условиях автоматизированного управления централизованной базой данных все такие изменения связаны с функциями управляющей программы базы данных. Программы, не использующие значения почтового индекса, не нуждаются в модификации - в них, как и прежде, в соответствии с запросами посылаются те же элементы данных. В таких случаях внесенное изменение неощутимо. Модифицировать необходимо только те программы, которые пользуются новым элементом данных.".
• 1.2 Концепция баз данных
• Активная деятельность по отысканию приемлемых способов обобществления непрерывно растущего объема информации привела к созданию в начале 60-х годов специальных программных комплексов, называемых "Системы управления базами данных" (СУБД).
• Основная особенность СУБД - это наличие процедур для ввода и хранения не только самих данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под управлением СУБД, называются "Базы данных" (БД).
• 1.3 Основные функции СУБД
• Традиционных возможностей файловых систем оказывается недостаточно для построения даже простых информационных систем. Существует несколько потребностей, которые не покрываются возможностями систем управления файлами: поддержание логически согласованного набора файлов; обеспечение языка манипулирования данными; восстановление информации после разного рода сбоев; реально параллельная работа нескольких пользователей. Можно считать, что если прикладная информационная система опирается на некоторую систему управления данными, обладающую этими свойствами, то эта система управления данными является системой управления базами данных (СУБД).
• Более точно, к числу функций СУБД принято относить следующие:
• управление данными во внешней памяти;
• управление буферами оперативной памяти;
• управление транзакциями;
• журнализация и восстановление БД после сбоев;
• поддержание языков БД.
• Рассмотрим подробнее:
• 1.3.1 Непосредственное управление данными во внешней памяти
• Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. В развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, и если использует, то как организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД.
• 1.3.2 Управление буферами оперативной памяти
• СУБД обычно работают с БД значительного размера; по крайней мере этот размер обычно существенно больше доступного объема оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.
• Заметим, что существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований.
• 1.3.3 Управление транзакциями
• Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции необходимо для поддержания логической целостности БД.
• 1.3.4 Журнализация
• Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
• Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
• Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.
• Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
• Самая простая ситуация восстановления - индивидуальный откат транзакции. Строго говоря, для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
• При мягком сбое во внешней памяти основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно мы рассмотрим это в соответствующей лекции.
• Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Грубо говоря, архивная копия - это полная копия БД к моменту начала заполнения журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
• 1.3.5 Поддержка языков БД
• Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (DDL - Data Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). DDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. Мы рассмотрим более подробно языки ранних СУБД в следующей лекции.
• В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language), сочетающий средства DDL и DML. В нескольких лекциях этого курса язык SQL будет рассматриваться достаточно подробно.
• 1.4 Типовая организация современной СУБД
• Естественно, организация типичной СУБД и состав ее компонентов соответствует рассмотренному нами набору функций.
• Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.
• Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно, можно выделить такие компоненты ядра (по крайней мере, логически, хотя в некоторых системах эти компоненты выделяются явно), как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Как можно было понять из первой части этой лекции, функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры "клиент-сервер" ядро является основной составляющей серверной части системы.
• Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем (а это, как правило, SQL) являются непроцедурными, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия (вспомните примеры из первой лекции). Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу. Применяются достаточно сложные методы оптимизации операторов, которые мы подробно рассмотрим в следующих лекциях. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполняемом внутреннем машинно-независимом коде. В последнем случае реальное выполнение оператора производится с привлечением подсистемы поддержки времени выполнения, представляющей собой, по сути дела, интерпретатор этого внутреннего языка.
• Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра.
• Рис. 1.1.Связь программ и данных при использовании СУБД
• 1.5 Классификация пользователей СУБД
• Пользователей СУБД можно разделить на 3 большие группы.
• Пользователи
• Пользователей можно разделить на три большие группы.
• * Первая -- прикладные программисты, которые отвечают за написание прикладных программ, использующих базу данных. Прикладные программы выполняют над данными все стандартные операции: выборку существующей информации, вставку новой информации, удаление или обновление существующей информации. Все эти функции выполняются через соответствующий запрос к СУБД. Эти программы могут быть простыми программами пакетной обработки или оперативными приложениями, функция которых -- поддержка работы конечного пользователя, имеющего непосредственный оперативный доступ к базе данных через рабочую станцию или терминал. Большинство современных приложений относится к оперативным.
• * Вторая -- конечные пользователи, которые работают с системами баз данных непосредственно через рабочую станцию или терминал. Конечный пользователь может получить доступ к базе данных, используя одно из оперативных приложений, упомянутых выше, или же воспользоваться интегрированным интерфейсом программного обеспечения самой системы баз данных. Такой интерфейс также поддерживается оперативным приложением, но это приложение не создается пользователем, оно является встроенным в систему баз данных. В большинстве систем есть, по крайней мере, одно такое встроенное приложение, а именно: процессор языка запросов, который позволяет пользователю указывать команды или выражения высокого уровня (такие как select или insert) для данной СУБД. Язык SQL, упомянутый выше, -- типичный пример языка запросов для базы данных.
• Замечание. Общепринятый термин "язык запросов" не совсем точно отражает рассматриваемое понятие, поскольку слово "запрос" подразумевает лишь выборку, в то время как с помощью этого языка выполняются также операции обновления, вставки и удаления (а возможно, и многие другие).
• Кроме языка запросов, в большинстве систем также предоставляются дополнительные встроенные интерфейсы, в которых пользователь в явном виде не использует команд, таких как select. Для работы с базой данной пользователь, например, выбирает необходимые команды меню или заполняет поля в формах. Такие интерфейсы, основанные на меню и формах, облегчают работу с базами данных тем, кто не имеет опыта работы с информационными технологиями (ИТ; часто употребляется также сокращение ИС -- информационные системы, эти понятия практически эквивалентны). Командный интерфейс, т.е. язык запросов, напротив, требует некоторого опыта работы с ИТ (возможно, не очень большого). Однако командный интерфейс обычно более гибок, чем основанный на меню и формах; кроме того, в языках запросов обычно есть определенные функции, которые не поддерживаются интерфейсами, основанными на меню и формах.
• * Третья группа -- администраторы базы данных, или АБД.
• Рассмотрим более подробно концепцию централизованного управления. Предполагается, что при централизованном управлении на предприятии, использующем систему баз данных, есть человек, который несет основную ответственность за данные предприятия. Это администратор данных, или АД, упомянутый ранее в этой главе. В связи с тем, что данные (как отмечено выше) -- одна из главных ценностей предприятия, администратор должен разбираться в данных и понимать нужды предприятия по отношению к данным на уровне управления высшего руководства предприятием. Таким образом, в обязанности администратора данных входит: принимать решение, какие данные необходимо вносить в базу данных в первую очередь, а также обеспечивать поддержание порядка при обслуживании данных и использовании их после занесения в базу данных. Например, он должен указывать, кто, при каких условиях, над какими данными и какие операции может выполнять. Другими словами, он должен обеспечивать безопасность данных.
• Очень важно, чтобы администратор данных работал как управляющий, а не как специалист по техническим вопросам (хотя он, конечно, должен иметь хорошее представление о возможностях баз данных на техническом уровне). Технический специалист, ответственный за реализацию решений администратора данных, -- это администратор базы данных, или АБД. Итак, администратор базы данных, в отличие от администратора данных, должен быть профессиональным специалистом в области информационных технологий. Работа АБД заключается в создании самих баз данных и техническом контроле, необходимом для осуществления решений администратора данных. АБД также несет ответственность за обеспечение необходимого быстродействия системы и ее технического обслуживания. Обычно у АБД есть штат из системных программистов и технических ассистентов (т.е. на практике функции АБД выполняются командой из нескольких человек, а не одним служащим). Однако для простоты удобно считать, что администратор базы данных -- один человек.
• Распределение обязанностей в системах с базами данных.
• Одним из компонентов среды СУБД являются пользователи.
• Среди пользователей СУБД можно выделить 4 различные группы: администраторы данных и баз данных, разработчики баз данных, прикладные программисты и конечные пользователи.
• Администраторы данных и администраторы баз данных.
• База данных и СУБД являются корпоративными ресурсами, которыми следует управлять так же, как и любыми другими ресурсами. Обычно управление данными и базой данных предусматривает управление и контроль за СУБД и помещенными в нее данными.
• Администратор данных, или АД (Data Administrator - DA), отвечает за управление данными, включая планирование базы данных, разработку и сопровождение стандартов, бизнес-правил и деловых процедур, а также за концептуальное и логическое проектирование базы данных. АД консультирует и дает свои рекомендации руководству высшего звена, контролируя соответствие общего направления развития базы данных установленным корпоративным целям.
• Администратор базы данных, или АБД (Database Administrator - DBA), отвечает за физическую реализацию базы данных, включая физическое проектирование и воплощение проекта, за обеспечение безопасности и целостности данных, за сопровождение операционной системы, а также за обеспечение максимальной производительности приложений и пользователей. По сравнению с АД, обязанности АБД носят более технический характер, и для него необходимо знание конкретной СУБД и системного окружения. В одних организациях между этими ролями не делается различий, а в других важность корпоративных ресурсов отражена именно в выделении отдельных групп персонала с указанным кругом обязанностей.
• Администрирование данных и администрирование баз данных.
• Администратор данных (АД) и администратор базы данных (АБД) отвечают за управление действиями, связанными с корпоративными данными и корпоративной базой данных соответственно. Рассмотрим цели и задачи, входящие в круг обязанностей АД и АБД в некоторой организации. В следующей таблице представлены этапы жизненного цикла приложений баз данных и указан вклад АД и АБД на каждом из них (или исполняемые ими роли (основные или вспомогательные)).
• Таблица 1. Этапы жизненного цикла базы данных с указанием роли АД и АБД

Этап	Основная роль	Вспомогательная роль
Планирование разработки базы данных	АД	АБД
Определение требований к системе	АД	АБД
Сбор и анализ требований пользователей	АД	АБД
Концептуальное проектирование базы данных	АД	АБД
Выбор целевой СУБД	АБД	АД
Логическое проектирование базы данных	АД	АБД
Разработка приложений	АБД	АД
Физическое проектирование базы данных	АБД	АД
Создание прототипов	АБД	АД
Реализация	АБД	АД
Конвертирование и загрузка данных	АБД	АД
Квотирование	АБД	АД
Эксплуатация и сопровождение	АБД	АД

• Администратор Данных принимает более активное участие в работе на ранних стадиях жизненного цикла -- от планирования базы данных до этапа ее логического проектирования, тогда как Администратор Базы Данных выполняет более активную роль на поздних стадиях -- от проектирования приложений и физического проектирования базы данных до этапа эксплуатации и сопровождения готовой системы.
• Администрирование данных - управление информационными ресурсами, включая планирование базы данных, разработку и внедрение стандартов, определение ограничений и процедур, а также концептуальное и логическое проектирование баз данных.
• Администратор Данных отвечает за корпоративные информационные ресурсы, включая и некомпьютеризированные данные. На практике это часто связано с управлением данными, которые являются совместно используемым ресурсом для различных пользователей и прикладных программ данной организации. В разных организациях количество сотрудников, выполняющих функции АД, может отличаться и обычно определяется размерами самой организации. Основная обязанность АД состоит в обмене консультациями и советами со старшими менеджерами, а также в слежении за тем, чтобы применение технологий баз данных продолжало соответствовать корпоративным целям. Должность АД обычно принадлежит отделу информационных систем организации. В одних случаях администрирование данных может представлять собой отдельную функциональную задачу, а в других -- совмещаться с администрированием базы данных.
• В настоящее время при обдумывании стратегии планирования информационной системы все больший акцент делается на важности АД. Организации все в большей и большей степени склонны уделять внимание значению данных, используемых или собранных в их информационной системе, как средству достижения более высокой конкурентоспособности. В результате возникает обязательное требование слияния стратегии построения информационных систем с бизнес-стратегиями организации. Это позволяет создать организацию с более гибкой структурой, способную адаптироваться к резким изменениям, имеющую более творческую и инновационную внутреннюю среду, обеспечивающую эффективную перестройку бизнес-процессов в случае необходимости. Упомянутый перенос акцентов означает, что АД во все большей мере должен понимать идеологию развития не только информационных систем, но и бизнес-процессов, и играть ключевую роль в разработке стратегии развития информационной системы, поддерживая ее соответствие деловым стратегиям организации. Это изменение мышления отражает происшедшее в недавнем прошлом драматическое изменение в назначении компьютерных систем: от исходного использования компьютеров для более эффективного управления некоторыми аспектами бизнес-процессов, через последующее повышение эффективности бизнес-процессов, до поддержки и обеспечения изменчивости и инновационности организаций.
• Задачи администрирования данных.
• Ниже перечислены основные задачи администрирования данных:
• ¦ Выбор подходящих инструментов разработки.
• ¦ Помощь в разработке корпоративных стратегий построения информационной системы, развития информационных технологий и бизнес-стратегий.
• ¦ Предварительная оценка осуществимости и планирование процесса создания базы данных.
• ¦ Разработка корпоративной модели данных.
• ¦ Определение требований организации к используемым данным.
• ¦ Определение стандартов сбора данных и выбор формата их представления.
• ¦ Оценка объемов данных и вероятности их роста,
• ¦ Определение способов и интенсивности использования данных.
• ¦ Определение правил доступа к данным и мер безопасности, соответствующих правовым нормам и внутренним требованиям организации.
• ¦ Концептуальное и логическое проектирование базы данных.
• ¦ Взаимодействие с АБД и разработчиками приложений с целью обеспечения соответствия создаваемых приложений всем существующим требованиям.
• ¦ Обучение пользователей -- изучение существующих стандартов обработки данных и юридической ответственности за их некорректное применение.
• ¦ Постоянная модернизация используемых информационных систем и технологий по мере развития бизнес-процессов.
• ¦ Обеспечение полноты всей требуемой документации, включая корпоративную модель, стандарты, ограничения, процедуры, использование словаря данных, а также элементы управления работой конечных пользователей.
• ¦ Поддержка словаря данных организации.
• ¦ Взаимодействие с конечными пользователями для определения новых требований и разрешения проблем, связанных с доступом к данным и недостаточной производительностью их обработки.
• Администрирование Базы Данных - Управление физической реализацией приложений баз данных физическое проектирование базы данных и ее реализация, организация поддержки целостности и защиты данных, наблюдение за текущим уровнем производительности системы, а также реорганизация базы данных по мере необходимости.
• Деятельность Администратора Базы Данных является в большей мере технической, чем деятельность Администратора Данных, и предусматривает знание особенностей конкретных СУБД и операционных систем. Хотя основные обязанности АБД сконцентрированы на разработке и сопровождении систем с максимально полным использованием возможностей целевой СУБД, АБД также в некоторой степени оказывает помощь АД (см. таблицу 1). Количество персонала, выполняющего администрирование баз данных, может варьироваться и в значительной мере зависит от размера самой организации.
• Задачи администрирования базы данных.
• Ниже перечислены основные задачи администрирования базы данных.
• ¦ Оценка и выбор целевой СУБД.
• ¦ Физическое проектирование базы данных.
• ¦ Реализация физического проекта базы данных в среде целевой СУБД.
• ¦ Определение требований защиты и поддержки целостности данных.
• ¦ Взаимодействие с разработчиками приложений баз данных.
• ¦ Разработка стратегии тестирования.
• ¦ Обучение пользователей.
• ¦ Ответственность за сдачу в эксплуатацию готового приложения базы данных.
• ¦ Контроль текущей производительности системы и соответствующая настройка базы данных.
• ¦ Регулярное резервное копирование.
• ¦ Разработка требуемых механизмов и процедур восстановления.
• ¦ Обеспечение полноты используемой документации, включая материалы, разработанные внутри организации.
• ¦ Поддержка актуальности используемого программного и аппаратного обеспечения, включая заказ и установку пакетов обновлений в случае необходимости.
• Сравнение задач администрирования данных и базы данных
• Приведем краткий сравнительный анализ задач администрирования данных и базы данных. В таблице 2 подытожены основные задачи АД и АБД. Наиболее очевидное отличие заключается в самой природе выполняемой ими работы. Работа АД является в большой степени управленческой, а работа АБД -- технической.
• Таблица 2. Основные отличия в задачах, выполняемых АД и АБД

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

• Работа АД не зависит от типа целевой СУБД Работа АБД зависит от типа целевой СУБД
• Система баз данных -- это, по сути, не что иное, как компьютеризированная система хранения записей. Саму же базу данных можно рассматривать как подобие электронной картотеки, т.е. хранилище или контейнер для некоторого набора занесенных в компьютер файлов данных. Пользователям этой системы предоставляется возможность выполнять множество различных операций над такими файлами, например:
• добавлять новые пустые файлы в базу данных;
• вставлять новые данные в существующие файлы;
• получать данные из существующих файлов;
• изменять данные в существующих файлах;
• удалять данные из существующих файлов;
• удалять существующие файлы из базы данных.
• Преимущества системы с базой данных по сравнению с традиционным "бумажным" методом ведения учета очевидны. Отметим некоторые из них: Компактность. Нет необходимости в создании и ведении многотомных бумажных картотек.
• Скорость. Компьютер может выбирать и обновлять данные гораздо быстрее человека. В частности, с его помощью можно быстро получать ответы на произвольные вопросы, возникающие в процессе работы, не затрачивая времени на визуальный поиск или поиск вручную.
• Низкие трудозатраты. Нет необходимости в утомительной работе над картотекой вручную. Механическую работу машины всегда выполняют лучше.
• Актуальность. В случае необходимости под рукой в любой момент имеется точная свежая информация.
• Эти преимущества приобретают еще большее значение в многопользовательской среде, где база данных, вероятно, больше и сложнее однопользовательской. Кроме того, многопользовательская среда имеет дополнительное преимущество: система баз данных предоставляет предприятию средства централизованного управления его данными (именно возможность такого управления является наиболее ценным свойством базы данных). Представьте себе противоположную ситуацию: предприятие не использует систему баз данных, в которой для каждого отдельного приложения создаются свои файлы, чаще всего размещаемые на отдельных магнитных лентах или дисках, в результате чего данные оказываются разрозненными. Систематически управлять такими данными очень сложно.
• Администрирование данных и администрирование базы данных
• Рассмотрим более подробно концепцию централизованного управления. Предполагается, что при централизованном управлении на предприятии, использующем базу данных, есть человек, который несет основную ответственность за данные предприятия. Это администратор данных, или АД. В связи с тем, что данные -- это одна из главных ценностей предприятия, администратор должен разбираться в них и понимать нужды предприятия по отношению к данным на уровне высшего управляющего звена в руководстве предприятием. Сам АД также должен относиться к этому звену. В обязанности администратора данных входит принятие решений о том, какие данные необходимо вносить в базу данных в первую очередь, а так же выработка требований по сопровождению и обработке данных после их занесения в базу данных. Примером подобных требований может служить распоряжение о том, кто и при каких обстоятельствах имеет право выполнять конкретные операции над теми или иными данными. Другими словами, АД должен обеспечивать защиту данных.
• Очень важно помнить, что администратор данных относится к управляющему звену, а не к техническим специалистам (хотя он, конечно, должен иметь хорошее представление о возможностях баз данных на техническом уровне). Технический специалист, ответственный за реализацию решений администратора данных, -- это администратор базы данных, или АБД. Администратор базы данных, в отличие от администратора данных. должен быть профессиональным специалистом в области информационных технологий. Работа АБД заключается в создании самих баз данных и организации технического контроля, необходимого для осуществления решений, принятых администратором данных. АБД также несет ответственность за обеспечение необходимого быстродействия системы и ее техническое обслуживание. Обычно у АБД есть штат из системных программистов и технических ассистентов (т.е. на практике функции АБД выполняются командой из нескольких человек, а не одним служащим). Однако для простоты удобнее считать. что администратор базы данных -- один человек.
• Преимущества централизованного подхода к управлению данными
• Преимущества использования баз данных, связанные с наличием централизованного управления.
• ¦ Возможность совместного доступа к данным
• Совместный доступ к данным означает не только возможность доступа к ним нескольких существующих приложений базы данных, но и возможность разработки новых приложений для работы с этими же данными Другими словами, требования новых приложений по доступу к данным могут быть удовлетворены без необходимости добавления новых данных в базу.
• ¦ Сокращение избыточности данных
• В системах, не использующих базы данных, каждое приложение имеет свои файлы. Это часто приводит к избыточности хранимых данных и, следовательно, к расточительству пространства вторичной памяти. Например, как приложение, связанное с учетом персонала, так и приложение, связанное с учетом обучения служащих, могут иметь собственные файлы с ведомственной информацией о служащих. Эти два файла можно объединить с устранением избыточности (одинаковой информации) при условии, что администратор данных знает о том, какие данные нужны для каждого приложения, т.е. что на предприятии осуществляется необходимое общее управление.
• В данном случае мы не имеем в виду, что избыточность данных может или должна быть устранена полностью. Иногда веские практические или технические причины требуют наличия нескольких копий хранимых данных. Однако такая избыточность должна строго контролироваться, т.е. учитываться в СУБД. Кроме того, в подобном случае должна быть предусмотрена возможность "распространения обновлений"
• ¦ Устранение противоречивости данных (до некоторой степени)
• В действительности это следствие предыдущего пункта. Возьмем пример из жизни. Пусть служащий с номером `Е3', работающий в отделе с номером `D8' представлен двумя различными записями в базе данных. Предположим, что в СУБД не учтено это раздвоение (т.е. избыточность данных не контролируется). Тогда рано или поздно обязательно возникнет ситуация, при которой эти две записи перестанут быть согласованными, когда одна из них будет изменена, а другая -- нет. В этом случае база данных станет противоречивой. Ясно, что противоречивая база данных способна предоставлять пользователю неправильную, противоречивую информацию.
• Также очевидно, что если какой-либо факт представлен одной записью (т.е. при отсутствии избыточности), то противоречий возникнуть не может. Противоречий можно также избежать, если не удалять избыточность, а контролировать ее (соответствующим образом известив об этом СУБД). Тогда СУБД сможет гарантировать, что, с точки зрения пользователя, база данных никогда не будет противоречивой. Данная гарантия обеспечивается тем, что если обновление вносится в одну запись, то оно автоматически будет распространено на все остальные. Этот процесс называется распространением обновлений (propagating updates).
• ¦ Возможность поддержки транзакций
• Транзакция (transaction) -- это логическая единица работы, обычно включающая несколько операций базы данных (в частности, несколько операций изменения). Стандартный пример -- передача суммы денег со счета А на счет В. Очевидно, что в данном случае необходимы два изменения: изъятие денег со счета А и их внесение на счет В. Если пользователь укажет, что оба изменения входят в одну и ту же транзакцию, то система сможет реально гарантировать, что либо оба эти изменения будут выполнены, либо не будет выполнено ни одно из них, даже если до завершения процесса изменений в системе произойдет сбой (скажем, из-за перерыва в подаче электроэнергии).
• Замечание. Упомянутое выше свойство атомарности (неделимости) транзакций -- это не единственное преимущество от поддержки транзакций. Однако в отличие от прочих оно вполне применимо даже в однопользовательской среде(Часто в однопользовательских системах поддержка транзакций совсем не предоставляется, а подобные проблемы часто перекладываются на плечи пользователя).
• ¦ Обеспечение целостности данных
• Задача обеспечения целостности заключается в гарантированной поддержке корректности данных в базе. Противоречивость между двумя записями, представляющими один "факт", является примером утраты целостности данных. Конечно, эта конкретная проблема может возникнуть лишь при наличии избыточности в хранимых данных. Но даже если избыточность отсутствует, база данных может содержать некорректную информацию. Например, в базе данных может быть указано, что сотрудник отработал 400 рабочих часов в неделю вместо 40, или зафиксирована его принадлежность к отделу, которого не существует. Централизованное управление базой данных позволяет избежать подобных проблем (насколько их вообще возможно избежать). Для этого администратор данных определяет (а АБД реализует) ограничения целостности (integrity constraints), иначе называемые бизнес-правилами, которые будут применяться при любой попытке внести какие-либо изменения в соответствующие данные.
• Целостность данных для многопользовательских систем баз данных даже более важна, чем для среды с "частными файлами", причем именно по той причине, что такая база данных поддерживает совместный доступ. При отсутствии должного контроля один пользователь вполне может некорректно обновить данные, от чего пострадают многие другие ни в чем не повинные пользователи. Следует также сказать, что в большинстве существующих коммерческих СУБД поддержка ограничений целостности развита слабо, хотя в настоящее время в этом направлении наблюдаются некоторые улучшения. Приходится констатировать тот печальный факт, что ограничения целостности имеют значительно более фундаментальное и критически важное значение, чем это обычно признается на текущий момент.
• ¦ Организация защиты данных
• Благодаря полному контролю над базой данных АБД (безусловно, в соответствии с указаниями администратора данных) может обеспечить доступ к ней только через определенные каналы. Для этой цели могут устанавливаться ограничения защиты (security constraints) или правила, которые будут проверяться при любой попытке доступа к уязвимым данным. Можно установить различные правила для разных типов доступа (выборка, вставка, удаление и т.д.) к каждому из элементов информации в базе данных. Однако следует заметить, что при отсутствии таких правил безопасность данных подвергается большему риску, чем в обычной (разобщенной) файловой системе. Следовательно, централизованная природа системы баз данных в определенном смысле требует наличия надежной системы защиты.
• ¦ Возможность балансировки противоречивых требований
• Зная общие требования всего предприятия (а не требования каждого отдельного пользователя), АБД (опять же, в соответствии с указаниями администратора данных) может структурировать базу данных таким образом, чтобы обслуживание было наилучшим для всего предприятия. Например, он может выбрать такое физическое представление данных во вторичной памяти, которое обеспечит быстрый доступ к информации для наиболее важных приложений (возможно, с потерей производительности для некоторых других приложений).
• ¦ Возможность введения стандартизация
• Благодаря централизованному управлению базой данных АБД (по указаниям администратора данных) может обеспечить соблюдение всех подходящих стандартов, регламентирующих представление данных в системе. Стандарты могут быть частными, корпоративными, ведомственными, промышленными, национальными и интернациональными. Стандартизация представления данных наиболее важна с точки зрения обмена и пересылки данных между системами. Кроме того, стандарты именования и документирования данных важны как в отношении их совместного использования, так и в отношении их углубленного понимания.
• Большинство перечисленных преимуществ достаточно очевидно. Однако есть дно преимущество, которое необходимо добавить к этому списку и которое не очевидно (хотя косвенно и охватывает несколько преимуществ). Речь идет об обеспечении независимости данных. (Строго говоря, это, скорее, цель создания систем баз данных, а не обязательное их преимущество
• Независимость данных
• Независимость данных может быть реализована на двух уровнях: физическом и логическом. Однако сейчас нас интересует только физическая независимость. Поэтому неуточненный термин "независимость данных" мы пока будем понимать лишь как физическую независимость данных.
• Замечание. Необходимо отметить, что термин "независимость данных" не совсем подходящий (он не отражает достаточно точно сущность происходящего). Но поскольку именно этот термин традиционно используется, мы последуем общему правилу.
• Проще всего разобраться в понятии независимости данных на примере его противоположности. Приложения, реализованные в старых системах ("дореляционные" или созданные даже до появления систем баз данных), в той или иной мере зависимы от данных. Это означает, что способ организации данных во вторичной памяти и способ доступа к ним диктуются требованиями приложения. Более того, сведения об организации данных и способе доступа к ним встроены в саму логику и программный код приложения.
• Пример. Предположим, у нас есть приложение, обрабатывающее файл EMPLOYEE. Исходя из соображений эффективности примем, что этот файл проиндексирован по полю имени работника (NAME). В старых системах в этом приложении учитывалось бы, что такой индекс существует и что последовательность записей в файле определена данным индексом. На основе этих сведений была бы построена вся внутренняя структура приложения. В частности, избранный способ реализации процедур доступа и обработки исключительных ситуаций в значительной степени зависел бы от особенностей интерфейса, предоставляемого программами управления данными.
• Приложения, подобные описанному в этом примере, мы называем зависимыми от данных, так как невозможно изменить физическое представление (т.е. способ физического размещения данных во вторичной памяти) или метод доступа (т.е. конкретный способ доступа к данным), не изменив самого приложения (возможно, радикально). Например, невозможно заменить индексированный файл в нашем примере хешированным файлом, не внеся в приложение значительных изменений. Более того, изменению в подобных случаях подлежат те части приложения, которые взаимодействуют с программами управления данными. Трудности, возникающие при этом, не имеют никакого отношения к проблеме, для решения которой было написано данное приложение; это трудности, внесенные используемой структурой интерфейса управления данными.