Файл: Систем управления.pdf

Управляет пользовательским интерфейсом
Принимает и проверяет синтаксис введенного пользователем запроса
Выполняет приложение
Генерирует запрос к базе данных и передает его серверу
Отображает полученные данные пользователю
Принимает и обрабатывает запросы к базе данных со стороны клиентов
Проверяет полномочия пользователей
Гарантирует соблюдение ограничений целостности
Выполняет запросы/обновления и возвращает результаты клиенту
Поддерживает системный каталог
Обеспечивает параллельный доступ к базе данных
Обеспечивает управление восстановлением
Этот тип архитектуры обладает приведенными ниже преимуществами.

Обеспечивается более широкий доступ к существующим базам данных.

Повышается общая производительность системы. Поскольку клиенты и сервер находятся на разных компьютерах, их процессоры способны выполнять приложения параллельно. При этом настройка производительности компьютера с сервером упрощается, если на нем выполняется только работа с базой данных.

Стоимость аппаратного обеспечения снижается. Достаточно мощный компьютер с большим устройством хранения нужен только серверу – для хранения и управления базой данных,

Сокращаются коммуникационные расходы. Приложения выполняют часть операций на клиентских компьютерах и посылают через сеть только запросы к базе данных, что позволяет существенно сократить объем пересылаемых по сети данных.

Повышается уровень непротиворечивости данных. Сервер может самостоятельно управлять проверкой целостности данных, поскольку все ограничения определяются и проверяются только в одном месте. При этом каждому приложению не придется выполнять собственную проверку.

Эта архитектура весьма естественно отображается на архитектуру открытых систем.
Некоторые разработчики баз данных использовали эту архитектуру для организации средств работы с распределенными базами данных, т.е. с набором нескольких баз данных, логически связанных и распределенных в компьютерной сети» Однако, несмотря на то, что архитектура «клиент/сервер» вполне может быть использована для организации распределенной СУБД, сама по себе она не образует распределенную СУБД. Более подробно распределенные СУБД обсуждаются в главе 5.
1.4. Понятие независимости данных
Трехуровневая архитектура позволяет обеспечить независимость хранимых данных от использующих их программ и пользователей [2, 5, 17], АБД может при необходимости переписать хранимые данные на другие носители информации и (или) реорганизовать их физическую структуру, изменив лишь физическую модель (внутреннюю схему) данных. АБД может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель
(концептуальную схему). Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся «прозрачными» для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.
Таким образом, различают два типа независимости данных – логическую и физическую.
Логическая независимость данных – полная защищенность внешних схем (инфологической модели
) от изменений, вносимых в концептуальную схему (даталогическую модель).
Физическая независимость данных – полная защищенность концептуальной схемы
(даталогической модели) от изменений, вносимых во внутреннюю схему (физическую модель).
Структура СУБД определяется используемой моделью данных. В этом смысле для СУБД являются обязательными следующие функции [12]:
а) трансляция схемы, определяющей структуру хранимых данных, в некоторое внутреннее представление, используемое СУБД при дальнейшей работе с данными (схема обычно составляется администратором базы данных на основании требований предполагаемых пользователей и записывается на языке определения данных, принятом в СУБД);
б) загрузка данных в базу данных (создание БД), сопровождаемая максимально возможной
19

проверкой их правильности;
в) реализация запросов пользователей (формулжруемых на специальном языке, принятом в данной
СУБД) на отбор и извлечение некоторой части базы: данных по задаваемым ими критериям отбора; этот процесс может сопровождаться некоторыми процедурами редактирования и обработки отобранной информации;
г) обновление некоторых частей базы данных без изменения структуры данных; критерии определения обновляемой части обычно аналогичны критериям отбора данных и задаются пользователем.
1.5. Категории пользователей базой данных
1.5.1. Общая классификация пользователей БД
Рассмотренные особенности СУБД позволяют создавать базы данных для обеспечения информационных потребностей пользователей. Одним из аспектов этой задачи является разработка системы, ориентированной на эффективное обслуживание запросов пользователей. Исходя из этого, целесообразно проанализировать типы и виды предъявляемых к БД запросов. Результаты та кого анализа представлены на рис. 1.9 [17].
Постоянные пользователи – такие, которые регулярно пользуются услугами БД и для которых можно заранее спрогнозировать типы запросов, определяющие круг их интересов. Постоянные пользователи могут обращаться к БД и с произвольными по содержанию запросами. Предварительное определение тематики запросов существенно помогает организовать эффективную обработку запросов.
Рис. 1.9. Категории пользователей БД
Разовые пользователи – те, которые не имеют постоянных запросов, но могут обращаться к системе с произвольными по содержанию запросами.
При разделении пользователей БД по уровню компетенции речь идет о защите определенной части данных от тех пользователей, которые по различным причинам не должны иметь возможность их получения или изменения. Следовательно, в архитектуре СУБД должны быть предусмотрены специальные средства для обеспечения санкционированного доступа пользователей к данным.
Пользователи-задачи обращаются к базе данных с регламентированными по форме и содержанию запросами. Выдаваемая им информация соответствующим образом обрабатывается и компонуется на основании принятых в системе формальных правил и соглашений.
Пользователи-люди обращаются к БД с произвольными либо с регламентированными по
20

содержанию запросами. Выдаваемая им информация должна иметь удобную для человека форму представления: в виде текста на естественном языке, таблиц с пояснениями, графиков и т.п.
Пользователи – прикладные программисты – особая категория, которая выполняет работы по программированию функциональных задач.
Пользователи-непрограммисты – наиболее многочисленная группа лиц, для удовлетворения информационных потребностей которых создается база данных. Поэтому таких пользователей часто называют конечными пользователями. Это специалисты в своей области деятельности, которые обычно не имеют специальной подготовки по программированию.
Особо следует рассмотреть задачи и функции, выполняемые администратором базы данных.
1.5.2. Администратор базы данных
Администратор базы данных – человек (или группа лиц), имеющий' полное представление об одной или нескольких базах данных и контролирующий их проектирование и использование. Отвечает за состояние базы данных в организации (учреждении) на протяжении ее жизненного цикла.
Функциями АБД являются [12, 17]:

решение вопросов организации данных об объектах предметной области и установлении связей между этими данными с целью объединения информации о различных объектах; согласование представлений пользователей;

координация всех действий по проектированию, реализации и ведению БД; учет перспективных и текущих требований пользователей;

решение вопросов, связанных с расширением БД в связи с изменением границ предметной области;

разработка и реализация мер по обеспечению защиты данных от некомпетентного использования, от сбоев технических средств, по обеспечению секретности определенной части данных и разграничению доступа к данным;

выполнение работ по ведению словаря данных; контроль неизбыточности и непротиворечивости данных, их достоверности;

обеспечение заданной производительности БД, чтобы обработка запросов выполнялась за приемлемое время;

изменение при необходимости методов хранения данных, путей доступа к ним, связей между данными, форматов данных; определение степени влияния изменений на всю БД;

координация вопросов технического обеспечения системы аппаратными средствами исходя из требований, предъявляемых БД к оборудованию;

координация работы системных программистов, разрабатывающих дополнительное программное обеспечение для улучшения эксплуатационных характеристик системы;

координация работы прикладных программистов, разрабатывающих новые пакеты программ и выполнение их проверки и включение в состав программного обеспечения системы.
Таким образом, при реализации достаточно сложных проектов, группа АБД может включать ряд специалистов, представленных на рис. 1.10 [17].
1.5.3. Разделение функций администрирования
В некоторых очень сложных предметных областях функции администрирования автоматизированной информационной системы могут быть распределены между администратором
данных (АД) и администраторам базы данных (АБД),
21

Рис. 1.10, Состав группы АБД
Специфика обязанностей АД к АБД на этапах жизненного цикла автоматизированной информационной системы представлена в табл. 1.2 [7].
Таблица 1.2
Этап
Основная роль
Вспомогательная роль
Планирование разработки базы данных
АД
АБД
Определение требований к системе
АД
АБД
Сбор и анализ требований пользователей
АД
АБД
Концептуальное проектирование базы данных
АД
АБД
Выбор целевой СУБД
АБД
АД
Логическое проектирование базы данных
АБД
АД
Разработка приложений
АБД
АД
Физическое проектирование базы данных
АБД
АД
Создание прототипов
АБД
АД
Реализация
АБД
АД
Конвертирование и первичная загрузка данных
АБД
АД
Тестирование
АБД
АД
Эксплуатация и сопровождение
АБД
АД
При таком делении функций администрирования к задачам администрирования данных относятся следующие.

Разработка стратегии построения информационной системы.

Предварительная оценка осуществимости и планирование процесса создания базы данных.

Разработка корпоративной модели данных.

Определение требований организации к используемым данным.

Определение стандартов сбора данных и выбор формата их представления.

Оценка объемов данных и вероятности их роста.

Определение способов и интенсивности использования данных.

Определение правил доступа к данным и мер безопасности соответствующих правовым нормам и внутренним требованиям организации.

Концептуальное проектирование базы данных.

Взаимодействие с АБД и разработчиками приложений.

Обучение пользователей существующим стандартам обработки данных и юридической ответственности за их некорректное применение.

Постоянная модернизация используемых информационных систем и технологий.

Обеспечение полноты всей требуемой документации.

Поддержка словаря данных.

Взаимодействие с конечными пользователями для определения новых требований и разрешения проблем, связанных с доступом к данным и недостаточной производительностью их обработки.
Деятельность АДБ по сравнению с АД является в большей мере технической. Основные задачи администратора БД при наличии АД следующие [7].
22


Оценка и выбор целевой СУБД.

Логическое и физическое проектирование базы данных.

Реализация физического проекта базы данных в среде целевой СУБД.

Определение требований защиты и поддержки целостности данных.

Взаимодействие с разработчиками приложений баз данных.

Разработка стратегии тестирования.

Обучение пользователей.

Ответственность за сдачу в эксплуатацию готового приложения базы данных.

Контроль текущей производительности системы и соответствующая настройка базы данных.

Регулярное резервное копирование.

Разработка требуемых механизмов и процедур восстановления.

Обеспечение полноты используемой документации, включая материалы, разработанные внутри организации.

Поддержка актуальности используемого программного и аппаратного обеспечения, включая заказ и установку пакетов обновлений в случае необходимости.
Результаты сравнительного анализа задач администрирования данных и администрирования базы данных представлены в табл. 1.3 [7], из которой видно, что работа АД является в большей степени управленческой, а работа АБД – технической.
1.6. Средства администрирования баз данных
Учитывая сложность и важность функций АБД, легко предположить, что для их успешного выполнения, у администратора должны быть специальные средства администрирования.
Таблица 1.3
Администрирование данных
Администрирование базы данных
Участвует в стратегическом планировании информационной системы организации
Оценивает новые СУБД
Определяет долгосрочные цели
Выполняет планы достижения целей
Применяет стандарты, политики и процедуры
Применяет стандарты, политики и процедуры
Определяет требования к данным
Реализует требования к данным
Выполняет концептуальное проектирование базы данных Выполняет логическое и физическое проектирование базы данных
Разрабатывает и сопровождает корпоративную модель данных
Реализует физический проект базы данных
Координирует разработку системы
Выполняет текущий контроль и управление базой данных
Управленческая направленность
Техническая направленность
Работа не зависит от типа целевой СУБД
Работа зависит от типа целевой СУБД
К основным из таких средств администрирования можно отнести:
1) язык определения данных;
2) язык манипулирования данными;
3) словарь данных (системный каталог).
Вкратце остановимся на назначении перечисленных средств.
Для работы с данными в СУБД предусмотрен внутренний язык, состоящий из двух частей: языка
определения данных (Data Definition Language – DDL) и языка манипулирования данными (Data
Manipulation Language – DML).
Эти языки еще называются подъязыками данных, т.к. в них отсутствуют конструкции для выполнения всех вычислительных операций, обычно используемых в языках программирования высокого уровня. Во многих СУБД предусмотрена возможность внедрения операторов подъязыка данных в программы на языках высокого уровня. В этом случае язык высокого уровня принято называть базовым или включающим языком.
Язык определения данных (ЯОД, DDL) - формальный закон, используемый в некоторой модели
23

данных для определения структуры, баз данных [12].
Результат компиляции операторов ЯОД – набор таблиц» хранимых в особых файлах, называемых
словарями данных или системными каталогами.
Посредством ЯОД обычно определяются подразделения данных, типовые структуры и правила их композиции, присваиваются имена данным, определяются типы элементов данных посредством задания присущих им свойств, учреждаются ключи базы данных, а также определяются отношения между данными, упорядоченность данных внутри их совокупностей, правила проверки достоверности данных и замки защиты от неправомочного использования их.
Обычно в ЯОД не определяются техника запоминания или поиска данных на физических носителях и другие особенности их физической организации, что обусловлено одной из основных концепций базы данных – независимостью логической структуры данных от физических особенностей их хранения.
ЯОД обычно полностью независим от языка манипулирования данными. Следовательно, определение данных в базах данных независимо от программ обработки, что является второй важной концепцией использования баз данных.
Язык манипулирования данными (ЯМД, DML) – совокупность языковых средств для организации доступа к данным в некоторой модели данных и в соответствующих ей СУБД [12].
Может выступать в роли языка запросов, прямо обеспечивающего информационное обслуживание пользователей баз данных, или быть расширением некоторого языка программирования, называемого базовым (включающим) языком, с конструкциями и понятиями которого ЯМД должен быть согласован.
Операторы ЯМД позволяют извлекать данные из баз данных, создавать или модифицировать последние.
К основным операциям манипулирования данными относятся:

вставка в БД новых сведений;

модификация сведений, хранимых в БД;

извлечение сведений, содержащихся в БД;

удаление сведений на БД.
ЯМД отличаются базовыми конструкциями манипулирования данными. Отличают два их типа:
а) процедурные ЯМД;
б) непроцедурные (декларативные) ЯМД.
С помощью, процедурного языка пользователь (программист) указывает на то, кол; можно получить необходимые данные из определенного набора данных. Т.е. пользователь должен определить все операции доступа К данным, чтобы получить результат. При этом предполагается знание пользователем деталей внутренней , организации структур данных в БД.
С помощью непроцедурных языков пользователь указывает какие данные ему нужны, без определения способа их получения. Данный подход освобождает пользователя от необходимости знать подробности внутренней организации БД. Работа пользователя обретает некоторую независимость от данных.
В общем случае язык запросов – часть ЯМД, высокоуровневый узкоспециализированный язык, предназначенный для удовлетворения различных требований по выборке данных из БД.
СУБД должна иметь доступный конечным пользователям каталог, в котором хранится описание элементов данных.
Словарь данных (системный каталог) – специальная система в составе БД, содержащая информацию обо всех ресурсах системы (см. рис. 1.11).
В словаре данных (системном каталоге) интегрированы метаданные – данные об объектах базы данных, позволяющие упростить способ доступа к ним и управление ими. Перед доступом к реальным данным СУБД обращается к системному каталогу.
Ключевой особенностью архитектуры ANSI/SPARC является наличие интегрированного системного каталога с данными о схемах, пользователях, приложениях и т.д. Предполагается, что каталог доступен как пользователям, так и функциям СУБД. В зависимости от типа используемой СУБД количество информации и способ ее применения могут варьироваться. Обычно в системном каталоге хранятся следующие сведения:

имена, типы и размеры элементов данных;

имена связей;

накладываемые на данные ограничения поддержки целостности;
24


имена зарегистрированных пользователей, которым предоставлено право доступа к данным;

внешняя, концептуальная и внутренняя схемы и , отображения между ними;

статистические данные, например частота транзакций и счетчики обращений к объектам базы данных.
Рис. 1.11. Примерная структура словаря данных
Системный каталог позволяет достичь определенных преимуществ, перечисленных ниже.

Информация о данных может быть централизованно собрана и сохранена, что позволит контролировать доступ к этим данным, как и к любому другому ресурсу.

Можно определить смысл данных, что поможет другим пользователям понять их предназначение.

Упрощается сообщение, так как сохраняются точные определения смысла данных. В системном каталоге также могут быть указаны один или несколько пользователей, которые являются владельцами данных или обладают правом доступа к ним.

Благодаря централизованному хранению избыточность и противоречивость описания отдельных элементов данных могут быть легко обнаружены.

Внесенные в базу данных изменения могут быть запротоколированы.

Последствия любых изменений могут быть определены еще до их внесения, поскольку в системном каталоге зафиксированы все существующие элементы данных, установленные между ними связи, а также все их пользователи.

Меры обеспечения безопасности могут быть дополнительно усилены.

Появляются новые возможности организации поддержки целостности данных.

Может выполняться аудит сохраняемой информации.
Системный каталог СУБД является одним из фундаментальных компонентов системы. Многие перечисленные в разд. 1.3 [7]программные компоненты строятся на использовании данных, хранящихся в системном каталоге. Например, модуль контроля прав доступа использует системный каталог для проверки наличия у пользователя полномочий, необходимых для выполнения запрошенных им операций. Для проведения подобной проверки системный каталог должен включать следующие компоненты:
 имена пользователей, для которых разрешен доступ к базе данных;
 имена элементов данных в базе данных;
 элементы данных, к которым каждый пользователь имеет право доступа, и разрешенные типы доступа к ним – для вставки, обновления, удаления или чтения.
25

Другим примером могут служить средства проверки целостности данных, которые используют системный каталог для проверки того, удовлетворяет ли запрошенная операция всем установленным ограничениям поддержки целостности данных. Для выполнения этой проверки в системном каталоге должны храниться такие сведения:
 имена элементов данных из базы данных;
 типы и размеры элементов данных;
 ограничения, установленные для каждого из элементов данных.
Термин «словарь данных» часто используется для программного обеспечения более общего типа, чем просто каталог СУБД. Система словаря данных может быть либо пассивной, либо активной.
Активная система всегда согласуется со структурой базы данных, поскольку она автоматически поддерживается этой системой. Пассивная система может противоречить состоянию базы данных из-за инициируемых пользователями изменений. Если словарь данных является частью базы данных, то он называется интегрированным словарем данных. Изолированный словарь данных обладает своей собственной специализированной СУБД. Его предпочтительно использовать на начальных этапах проектирования базы данных для некоторой организации, когда требуется отложить на какое-то время привязку к конкретной СУБД. Однако недостаток этого подхода заключается в том, что после выбора
СУБД и воплощения базы данных изолированный словарь данных значительно труднее поддерживать в согласии с состоянием базы данных.
Эту проблему можно было бы свести к минимуму, если преобразовать использовавшийся при проектировании словарь данных непосредственно в каталог СУБД.