Компоненты СБД

Апаратне забезпечення (АЗ)

Для роботи СУБД необхідне апаратне забезпечення (АЗ). Воно залежить від потреб даної організації. Одні СУБД призначені для роботи лише з конкретними типами ОС або обладнання, інші - з широким кругом АЗ і різними ОС. Для роботи СУБД потрібно мін оперативної і дискової пам'яті.

Програмне забезпечення (ПЗ)

Цей компонент захватує ПЗ самої СУБД.

Данні

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

Процедури

До процедур відносяться інструкції і правила, які повинні додержуватися при використанні БД.

Користувачі

g. адміністратори даних і БД;

h. розробники БД;

i. прикладні програмісти;

j. кінцеві користувачі.

Компоненты СБД

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

СУБД состоит из нескольких программных компонентов (модулей), представленных на рис. 5.1, каждый из которых предназначен для выполнения определенной операции. На этой схеме также показано, как СУБД взаимодействует с другими программными компонентами, например с такими, как пользовательские запросы и методы доступа (т.е. методы управления файлами, используемые при сохранении и извлечении записей с данными). /Файловая организация и методы доступа подробно описываются в работах Тиори и Фрая (Teorey and Fry, 1982), Видерхольда (Weiderhold, 1983), Смита и Барнса (Smith and Bames, 1987), а также Ульмана (Ullman, 1988)./ На рис. 5.1 показаны следующие программные компоненты среды СУБД.

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

Рис. 5.1 Основные компоненты типичной системы управления базами данных

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

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

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

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

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

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

Контроль прав доступа. Этот модуль проверяет наличие у данного пользователя полномочий для выполнения затребованной операции.

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

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

Оптимизатор запросов. Этот модуль определяет оптимальную стратегию выполнения запросаz.

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

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

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

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

Для воплощения базы данных на физическом уровне помимо перечисленных выше модулей нужны некоторые другие структуры данных. К ним относятся файлы данных и индексов, а также системный каталог. Группой DAFTG (Data-base Architecture Framework Task Group) была предпринята попытка стандартизации СУБД, и в 1986 году ею была предложена некоторая эталонная модель. Назначение эталонной модели заключается в определении концептуальных рамок для разделения предпринимаемых попыток стандартизации на более управляемые части и указания взаимосвязей между ними на очень широком уровне.

Функції СУБД

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

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

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

· имена, типы и размеры элементов данных;

· имена связей;

· накладываемые на данные ограничения поддержки целостности;

· имена санкционированных пользователей, которым предоставлено право доступа к данным;

· внешняя, концептуальная и внутренняя схемы и отображения между ними;

· статистические данные, например частота транзакций и счетчики обращений к объектам базы данных.

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

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

· Можно определить смысл данных, что поможет другим пользователям понять их предназначение.

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

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

· Внесенные в базу данных изменения могут быть запротоколированы.

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

· Меры обеспечения безопасности могут быть дополнительно усилены.

· Появляются новые возможности организации поддержки целостности данных.

· Может выполняться аудит сохраняемой информации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Программы статистического анализа, позволяющие оценить производительность или степень использования базы данных.

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

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

1. Зберігання, вилучення і обновлення даних

Фундаментальна функція СУБД. Спосіб реалізації цієї ф-ції в СУБД повинен дозволяти скрывать від кінцевого користувача внутрішні деталі фізичної реалізації системи.

2. Каталог, який доступний кінцевим користувачам

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

- імена, типи і розміри елементів даних;

- імена зв'язків;

- обмеження, які накладаються на дані, для підтримки цілісності;

- імена санкцеонированных користувачів, яким предоставлено право доступу до даних;

- зовнішня, концептуальна і внутрішня схеми і відображення між ними;

- статичні дані.

3. Управління транзакціями

Транзакція - це послідовність операцій над БД, даних СУБД як єдине ціле. Або транзакція успішно виконується, і СУБД фіксує (COMMIT) зміни БД, проведені цією транзакцією, в зовнішній пам'яті, або жодна з цих змін ніяк не відображається на стані БД. Поняття транзакції необхідне для підтримки логічної цілісності БД. Якщо пригадати наш приклад інформаційної системи з файлами СПІВРОБІТНИКИ і ВІДДІЛИ, то єдиним способом не порушити цілісність БД при виконанні операції прийому на роботу нового співробітника є об'єднання елементарних операцій над файлами СПІВРОБІТНИКИ і ВІДДІЛИ в одну транзакцію. Таким чином, підтримка механізму транзакцій є обов'язковою умовою навіть розрахованих на одного користувача СУБД (якщо, звичайно, така система заслуговує назви СУБД). Але поняття транзакції набагато більш важливе в розрахованих на багато користувачів СУБД.

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

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

Існує декілька базових алгоритмів сериализации транзакцій. В централізованих СУБД найбільш поширені алгоритми, засновані на захопленнях синхронізацій об'єктів БД. При використовуванні будь-якого алгоритму сериализации можливі ситуації конфліктів між двома або більш транзакціями по доступу до об'єктів БД. В цьому випадку для підтримки сериализации необхідно виконати відкіт (ліквідовувати всі зміни, вироблені в БД) однієї або більш транзакцій. Це один з випадків, коли користувач розрахованої на багато користувачів СУБД може реально (і достатньо неприємно) відчути присутність в системі транзакцій інших користувачів.

4. Сервисы керування паралельністю

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

5. Сервіси востановленния

СУБД повинна надавати засоби востановленния БД на випадок якого небудь її повреждения або разрушения.

6. Сервисы контролю доступу до даних

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

7. Підтримка обміну даними

СУБД повинна володіти способностью до інтеграції з комунікаційним ПЗ.

8. Службы підтримки цілісності даних

СУБД повинна володіти інструментами контролю за тим, щоб дані і їхні зміни відповідали заданими правилами.

9. Службы підтримки незалежності від даних

СУБД повинна володіти інструментами підтримки незалежності програм від фактичної структури БД.

10. Допоміжні Службы

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

Приклади допоміжних утиліт:

k. у-ти імпортування, для завантаження БД із плоских файлів. У-ти експортування – завантаження БД в плоскі диски.

l. Засоби моніторингу, для спостерігання характеристики функціонування і використання БД.

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

n. Інструменти реорганизации індексів, презначені для перебудови індексів і обробки випадків їх переповнення.

o. Інструменти сборки мусора і перерозподіл пам'яті для фізичного устранения удаленных записів з запоминаючих пристроїв.

6_ Поняття БД. Об’єкти і зв’язки. Властивості.

4. Розподіл обов’язків в СБД. АД і АБД.

Розподіл обов’язків в СБД:

a. адміністратори даних і БД;

b. розробники БД;

c. прикладні програмісти;

d. кінцеві користувачі.

Адміністратори даних і БД.

АД відповідають за керування даними, враховуючи планування БД, розробку і сопровождение стандартів, бізнес-правил і ділових процедур, а також за концептуальное і логічне проектування БД. АД консультує і дає свої рекомендації керівництву вищого звена, контролює відповідність загального напрямку розвитку БД встановленими корпоративними цілями.

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

Розробники БД:

e. Розробники логічної БД

f. Розробники фізичної БД

Розробники ЛБДзаймаються ідентифікацією даних, зв’язки між даними і встановлює обмеження на збереженні дані. Вони повинні володіти всестороніми і повним розумінням СД (структури даних) організації і її бізнес-правил. Бізнес-правилаописують характеристики даних з точки зору організації. Приклад б-п:

Для ефективної роботи РЛБД повині як модна раніше вовлеч всіх користувачів БД в процес створення моделі даних.

Розробники ЛБДотримують готову логічну модель даних, займаються її фізичною реалізацією, в тому числі:

-преобразованием ЛМД в набір

7_ Архітектура СБД ANSI/SPARC. Три рівні. Відображення.