p align="justify">
экранными
формами ввода.
Нарушения логической целостности
базы данных могут быть связаны не только
с вводом в нее недостоверных данных или
с неправомерными действиями процедур
обработки данных, работающие в среде
базы данных и помещающих в базу данных
генерируемые ими данные. Они могут являться
также следствием несвоевременного прерывания
выполнения таких процедур для обработки
запроса, выданного другим пользователем.
Для исключения таких ситуаций
в мультипользовательских СУБД
предусматривается механизм транзакций,
который подробнее обсуждается ниже.
Проблема обеспечения физической целостности
базы данных возникает в связи с возможными
ее разрушениями в результате сбоев и
отказов оборудования вычислительной
системы, повреждений машинных носителей
данных. Развитые СУБД располагают средствами
восстановления разрушенной базы данных,
основанные чаще всего на использовании
ее контрольных копий и журнализации изменений
(14, С.34).
В мультипользовательских СУБД
предусматриваются механизмы разграничения
полномочий доступа (управления доступом)
пользователей к базе данных, поскольку
наряду с данными, доступными любому пользователю,
в ней могут храниться и такие данные,
которые должны быть доступны лишь ограниченному
кругу пользователей. Кроме того, может
быть ограничена группа пользователей,
которой разрешено обновлять те или иные
данные.
Механизмы управления доступом
обычно основываются на принципах
паролей, сопоставлении так называемых
замков управления доступом, ассоциированных
с защищенными объектами, и ключей, специфицируемых
пользователем, либо на явной спецификации
полномочий доступа.
Настройка СУБД на конкретные
условия применения может включать
модификацию параметров организации среды
хранения данных, выбор новых, более эффективных
для данного случая методов доступа из
числа представляемых системой. Обычно
она допускает также изменение структуры
хранимых данных или их размещения в среде
хранения (реорганизацию базы данных)
с целью повышения производительности
системы или возвращения освобожденной
памяти для повторного использования.
Кроме того, предусматривается возможность
логической реструктуризации базы данных
– модификации концептуальной схемы с
последующим приведением базы данных
в соответствие с вновь сформированной
схемой, а также ряд других функций для
поддержки деятельности системного персонала,
ответственного за эксплуатацию базы
данных. Такой персонал называют администратором
базы данных.
Для управления настройкой системы
используются ее языковые средства
– языки определения данных, связанные
с различными архитектурными
уровнями системы, а в некоторых системах
– возможности задания параметров системной
среды. Характер и возможности языковых
средств СУБД определяются главным
образом моделью данных, поддерживаемой
этой системой.
Организация параллельного доступа
пользователей к базе данных
является довольно сложной задачей. Здесь
нужно исключить коллизии, связанные с
одновременным обновлением данных разными
пользователями, с возможностью чтения
одним пользователем объекта базы данных,
который успел лишь частично обновить
другой пользователь. Такие коллизии привели
бы к нарушению логической целостности
базы данных. Для их предотвращения в СУБД
предусматривается техника транзакций
и блокирования ресурсов данных. Транзакцией
называют последовательность операций
пользователя над базой данных, которая
сохраняет ее логическую целостность.
Если, например, из базы данных нужно удалить
сведения о некотором поставщике в связи
с тем, что он прекращает дальнейшие поставки,
то вслед за этим необходимо удалить и
сведения о запланированных этим поставщиком
поставках продукции. Иначе база данных
будет содержать сведения о поставках
неизвестного системе поставщика. Ясно,
что в мультипользовательской среде такую
последовательность операций нельзя прерывать
до полного ее завершения ее завершения
для обработки запросов других пользователей
системы.
На время исполнения транзакции,
модифицирующей значение данных,
необходимо во избежание коллизий
блокировать эти ресурсы, с
тем чтобы не допустить к
ним доступа для других
транзакций. В различных СУБД
используются разные методы блокирования.
В одних системах предусматривается автоматическое
блокирование ресурсов на время их обновления,
в других оно должно явно запрашиваться
в пользовательских транзакциях. Используются
и комбинированные стратегии блокирования.
Блокирование может предусматривать монопольное
использование ресурса данной транзакцией
или допускать его совместное использование
с другими транзакциями.
Разрешая таким образом проблему
параллельного доступа, блокирование
ресурсов вместе с тем порождает
новую проблему – возможность возникновения
тупиковой ситуации. Так называется ситуация,
когда группа из двух или более транзакций
монопольно захватывает ресурсы таким
образом, что каждая из них ожидает освобождения
какого-либо ресурса, монопольно захваченного
(блокированного) другой транзакцией из
этой группы.
Разработан ряд теоретических
подходов, позволяющих предотвращать
возникновение тупиковых ситуаций.
Это может быть сделано, в
частности, путем соблюдения всеми
пользователями некоторых «джентельменских»
норм поведения. В некоторых СУБД реализованы
специальные автоматические механизмы
предотвращения тупиковых ситуаций либо
механизмы, обеспечивающие выход из тупиковой
ситуации за счет отката образующих ее
транзакций.
СУБД всегда реализуется как цельная
программная система. Часто наряду с основной
частью системы, называемой ее ядром, в
состав СУБД включают ряд периферийных
программных компонентов вспомогательного
назначения (утилит), которые могут исполняться
независимо от ядра системы. Совокупность
таких компонентов называют окружением
системы. Окружение СУБД обычно включает
утилиты, поддерживающие деятельность
администратора базы данных, утилиты,
используемые в процессе разработки информационных
систем, утилиты создания контрольной
копии базы данных и восстановления ее
при разрушениях, автономные средства
обмена данными (экспорта-импорта) с другими
системами, средства обучения пользователей
и системного персонала (17, С.20).
- Языковые
средства СУБД.
Функциональные возможности моделей данных
становятся доступными пользователю СУБД
благодаря ее языковым средствам. Заметим,
что здесь речь пойдет не о пользователях
базы данных, а о пользователях СУБД. К
их числу относятся и персонал администрирования
данными, и разработчики прикладных систем
на основе данной СУБД, и конечные пользователи
системы базы данных. Пользователи каждой
из этих категорий могут иметь специально
для них предназначенные интерфейсы на
том или ином уровне архитектуры системы.
Реализация языковых средств интерфейсов
может быть осуществлена различными способами.
Для высококвалифицированных пользователей,
например разработчиков сложных прикладных
систем, языковые средства чаще всего
предоставляются в их явной синтаксической
форме.
В других случаях функции языков
могу быть доступны косвенным образом,
когда они реализуются в форме различного
рода меню, диалоговых сценариев или заполняемых
пользователем таблиц. По таким входным
данным интерфейсные средства формируют
адекватные синтаксические конструкции
языка интерфейса и передают их на исполнение
или включают в генерируемый программный
код приложения. Интерфейсы с неявным
использованием языка широко используются
в СУБД для персональных ЭВМ. В реляционных
СУБД широко распространен основанный
на таком подходе табличный язык Query-By-Example
(QBE), разработанный М.Злуфом.
Языковые средства СУБД используются
для выполнения двух основных
функций – для описания представления
базы данных на управляемых
уровнях системной архитектуры и для инициирования
выполнения операций манипулирования
данными.
Первая из этих функций обеспечивается
языком описания данных (ЯОД). Его
часто называют также языком
определения данных. Описание базы
данных средствами ЯОД называется схемой
базы данных. Оно включает описание структуры
базы данных и налагаемых на нее ограничений
целостности в рамках тех правил, которые
регламентированы моделью данных используемой
СУБД. Помимо указанных функций, ЯОД некоторых
СУБД обеспечивают также возможности
задания ограничений доступа к данным
или полномочий пользователей (12, С.52).
Кроме того, многие системы не
имеют самостоятельных языков
для спецификации междууровневых отображений
данных. В таких случаях определения способов
отображения также описываются средствами
ЯОД одного из смежных архитектурных уровней.
Они включаются при этом в соответствующую
базу данных.
Здесь уместно сделать важное
замечание. Разработчики некоторых
СУБД при проектировании архитектуры
системы не уделяют достаточного
внимания обеспечению естественного разделения
функций архитектурных уровней. В результате
в значительной мере утрачивается возможность
достижения той степени независимости
данных, которую потенциально способна
обеспечить «чисто» реализованная многоуровневая
архитектура. Наиболее часто встречающиеся
дефекты архитектуры заключаются в том,
что спецификации некоторых характеристик
организации хранимых данных, законное
место которых в схеме внутреннего уровня,
попадают в схему концептуального уровня.
Образцом тщательной реализации
идеологии разделения функций архитектурных
уровней системы баз данных, являются
языковые спецификации CODASYL для систем
баз данных сетевой структуры.
ЯОД не всегда синтаксически
оформляется в виде самостоятельного
языка. Он может быть составной частью
единого языка данных, сочетающего возможности
определения данных и манипулирования
данными.
Язык манипулирования данными
(ЯМД) позволяет запрашивать предусмотренные
в системе операции над данными из баз
данных. Аналогично языку определения
данных ЯМД не обязательно выступает в
форме синтаксически самостоятельного
языка СУБД. На практике разделение ЯОД
и ЯМД играет скорее методическую роль
или используется в технологических целях.
Имеются многочисленные примеры
языков СУБД, объединяющих возможности
описания данных и манипулирования данными
в единых синтаксических рамках. Весьма
популярным среди языков такого рода является
реляционный язык SOL, разработанный в
исследовательской лаборатории фирмы
IBM в Сан-Хосе и реализованный в середине
70-х годов в экспериментальной реляционной
СУБД System R.
Некоторые СУБД располагают такими
языками, которые не только
реализуют функции определения данных
и манипулирования данными, но и обладают
управляющими структурами и другими средствами,
свойственными традиционным языкам программирования.
Благодаря этому они могут использоваться
как функционально полное инструментальное
средство для создания прикладных систем
или для формулировки запросов пользователей
к базе данных. Такие языки называют автономными.
Автономные непроцедурные языки высокого
уровня называют языками запросов. Они
предназначены для конечных пользователей
систем баз данных.
Хотя автономные языки современных
СУБД и обладают развитыми
функциональными возможностями, существует
много приложений, для реализации которых
этих возможностей оказывается недостаточно.
Наиболее распространены случаи, когда
поддерживаемая системой модель, оказывается
слишком бедна средствами моделирования
семантики предметной области, недостаточно
развиты структурообразующие и \ или операциональные
средства модели.
В таких ситуациях уже на
стадии создания СУБД предполагается,
что ее язык будет использоваться
в сочетании с обычными языками
программирования, средствами которых
будет восполняться функциональная неполнота
данной системы. Язык программирования
выступает при этом в роли включающего
языка по отношению к языку СУБД, и прикладные
системы реализуются на таком объединенном
языке.
Интерфейсы включающих языков
предусмотрены во многих СУБД.
Реализация интерфейсов включающего языка
основана на использовании области связи
между прикладной программой и СУБД, доступной
обеим взаимодействующим сторонам. Для
этой цели структура области связи должна
быть описана в программе в терминах ее
языка программирования.
Через область связи осуществляется обмен
данными между программой и СУБД при выполнении
операций манипулирования данными с помощью
операторов ЯМД, передаются программе
сигналы обратной связи СУБД – сообщения
об ошибках и коды завершения операций.