57 Место субд в системе информационного обслуживания управленческой деятельности; эволюция развития субд; функциональная структура субд.
Место СУБД в системе информационного обслуживания управленческой деятельности - СППР же!
Эволюция развития СУБД:
1. СУБД первого поколения(иерархическая –> сетевая модель данных). Поголовно коммерческие и использовались для работы на мейнфремах. Недостатки – сложно писать запросы, нет четких стандартов. Пример - IMS (Information Management System), разработанная в 60х.
2.СУБД второго поколения (реляционная модель данных), разработан SQL – стандартный ЯМД для всех реляционных СУБД. Используются и на ПК, и на мейнфремах. Недостатки – ограниченные возможности моделирования. Пример – современные СУБД Access, Oracle и т.д.
3. СУБД третьего поколения(обьектно-ориентированная и обьектно-реляционная модели данных). Разрабатываются для упрощения приложений баз данных.
Не стоит думать, что в наше время не используются СУБД первого поколения – сейчас такие системы известны как NoSQL СУБД.
Функциональная структура СУБД:
Как правило, СУБД содержит следующие компоненты: язык описания данных (ЯОД) и программные модули языка; язык манипулирования данными (ЯМД) и программы, реализующие язык, дополнительные компоненты СУБД. Язык описания данных включает в себя три языка: язык описания концептуальных схем, внешних схем и внутренних схем БД. Язык описания данных схем идентифицирует и описывает, с одной стороны, классы объектов, с которыми имеет дело пользователь, а с другой стороны - связи между этими классами объектов. Используется ЯОД как при создании БД, так и при ее модификации. Некоторые ЯОД схемы позволяют задавать способы хранения данных во внешней памяти и методы доступа к ним. Такие описания соответствуют уровню СУБД между концептуальной и внутренней схемами. Некоторые СУБД требуют определение соответствий между концептуальной и внутренней схемами. Во многих СУБД языки описания схем и подсхем подобны. Кроме того, данные языки могут содержать элементы описания внутренних схем и поэтому используются только два языка: для описания схем и подсхем. Построение концептуальной схемы БД предназначенной для многочисленных пользователей и задач, возлагается на администратора БД. Администратор БД должен: построить концептуальную схему и внешние схемы, необходимые для различных пользователей; определить права доступа для пользователей и физическую организацию данных, исходя го методов доступа, которые применяются пользователями; разработать процедуры, позволяющие системе безопасно функционировать. Внешние схемы, необходимые пользователям и задачам, могут описываться с помощью ЯОД, применяемого для описания концептуальной схемы, и могут отличаться от концептуальной схемы. Например, во внешней схеме указываются лишь некоторые элементы данных, используемые для решения конкретной задачи и описанные в концептуальной схеме. При этом представления данных во внешней и концептуальной схемах могут различаться.
Язык манипулирования данными используется для работы с данными, т.е. загрузки, поиска, изменения данных. Рассматриваемый язык допускает применение специальных инструкций, позволяющих осуществлять поиск, изменение, вставку и манипулирование данными. Обращение к СУБД производится с помощью оператора, который в качестве параметров обращения содержит инструкции ЯМД.
Дополнительные компоненты СУБД - это служебные программы, играющие важную роль в процессе работы с БД и предназначенные для: создания (загрузки) БД; копирования содержимого БД с целью восстановления в случаях аварийных ситуаций; реорганизации БД, чтобы получить более эффективный ее вариант; печати как частей, так и всей БД; сбора и получения статистических данных об использовании записей, файлов, путей доступа и т.п.; восстановления содержимого БД, начиная с некоторой контрольной точки, при возникновении аварийных ситуаций.
58 Схема обработки стандартного запроса в СУБД; особенности обработки распределенного запроса в СУБД.
Обработка запросов – последовательность действий, приводящая к извлечению информации из БД. Последовательность действий в этом случае состоит из трансляции запроса с языка высокого уровня в выражения, выполняемые на физическом уровне, преобразования оптимизации и фактическое выполнение запроса.
Наибольший процент времени при выполнении запроса тратится на обращения к диску /* вспомнить физическое хранение */ и сортировку данных. Поэтому при выполнении запроса сначала выявляются стратегии выполнения запроса, сравниваются и производится выполнение согласно лучшей.
Общая схема обработки запроса
Основные шаги обработки запросов
1 Разбор и трансляция. Язык SQL удобен и понятен пользователю БД, но его невозможно использовать в качестве внутреннего языка БД. В качестве такого языка может выступать расширенная реляционная алгебра. Трансляция при обработке запроса аналогична синтаксическому разбору в трансляторе языка программирования. В процессе трансляции проверяется правильность написания запроса и ассоциация имен, использованных в запросе с именами отношений и атрибутов.
2 Оптимизация. Один и тот же запрос может быть транслирован в различные выражения реляционной алгебры.
Например:
Select Сумма from счет where сумма<2500
Можно транслировать в выражение
sсумма<2500(pсумма(счет)) или pсумма(sсумма<2500(счет)).
Для выполнения каждого оператора реляционной алгебры могут использоваться различные алгоритмы. Например, для вычисления селекции нужно пересмотреть все кортежи отношения. Если же построен индекс, по атрибуту «сумма», то можно использовать индекс для проверки условия, а затем извлекать найденные кортежи, используя адрес в индексе. Таким образом, недостаточно оттранслировать запрос в операторы реляционной алгебры, необходимо еще определить, как будет выполняться каждый из этих операторов. Инструкция для выполнения оператора реляционной алгебры называется вычислительным примитивом. Последовательность примитивов, которая будет использована для выполнения запроса, называется планом выполнения запроса. Пример такого плана
pсумма ------ sсумма<2500; используя индекс 1 ------- отношение счет
/* Рисовать деревом сверху вниз (вычисляться будет снизу вверх ) */
В общем случае работа оптимизатора состоит из двух частей. Первая – выбор выражений, эквивалентных полученным в результате трансляции, но выполняемых быстрее. Второй – выбор стратегии выполнения запроса, а именно выбора последовательности выполнения операторов или применения индексов. Выбор стратегии осуществляется на основе сравнения цены выполнения. Основным параметром в этом случае является число обращений к диску. Для определения этого параметра оптимизатор использует статистику БД. Такая статистика включает информацию о размерах отношений и индексов.
3 На третьем шаге используя выбранный план осуществляется выбор данных.
Обработка распределённых запросов. Суть в том, что для запроса может потребоваться обращение к нескольким узлам. В такой системе может быть много возможных способов пересылки данных, позволяющих выполнить рассматриваемый запрос
59 Обеспечение целостности системы баз данных; триггеры и хранимые процедуры в СУБД.
Целостность базы данных (database integrity)– защита базы данных от санкционированных
пользователей.
Обеспечение целостности данных касается защиты от внесения непреднамеренных ошибок и предотвращения последних. Оно достигается за счёт проверки ограничений целостности – условий, которым должны удовлетворять значения данных.
Рассмотрим различные типы ограничений целостности:
1. Уникальность значения первичного ключа (PRIMARY KEY).
2. Уникальность значения комбинации ключевых полей:
UNIQUE(A),
где A – атрибут или комбинация атрибутов.
(1,2 – структурные ограничения.)
3. Задание диапазона значений атрибута:
BETWEEN min_value AND max_value
4. Задание взаимоотношений между значениями атрибутов:
A @ B,
где @ – оператор отношения (например, знак ">").
5. Задание списка возможных значений:
IN (value1, value2,… valueN)
6. Определение формата атрибута (например, даты или числа).
7. Определение домена атрибута на основе значений другого атрибута: множество значений некоторого атрибута отношения является подмножеством значений другого атрибута этого или другого отношения.
3.-7. – ограничения на значения данных.
8. Ограничения на обновление данных (например, каждое следующее значение атрибута должно быть больше предыдущего).
9. Ограничения на параллельное выполнение операций (механизм транзакций) и проверка ограничений целостности после окончания внесения взаимосвязанных изменений.
Реализация ограничений целостности возлагается на СУБД или выполняется с помощью специальных программных модулей. СУБД проверяет выполнение ограничений целостности при каждой операции модификации БД, если эта операция может нарушить целостность БД. Эта проверка проводится либо сразу после выполнения оператора DML, либо после выполнения всей транзакции. (По стандарту ISO этим можно управлять. По умолчанию проверка проводится после каждой операции DML).
Хранимая процедура (stored procedure) — это именованный набор команд TransactSQL (или любого другого языка процедур, ассоциированного с СУБД), хранящийся непосредственно на сервере и представляющий собой самостоятельный объект базы данных. Без хранимых процедур пользователю пришлось бывводить весь набор команд всякий раз, когда он хочет выполнить какое-либо действие. Перечислим достоинства использования хранимых процедур: Использование хранимых процедур повышает скорость выполнения операций, так как процедура предварительно компилируется на сервере, и при повторном вызове процедура уже загружена в память (кэш), где найти ее можно гораздо быстрее, чем на диске, к томуже не нужна повторная компиляция и оптимизация. Хранимые процедуры могут состоять из десятков и сотен команд, но для их запуска достаточно указать всего лишь имя нужной хранимой процедуры. Это позволяет уменьшить размер запроса, посылаемого по сети от клиента на сервер, так как весь набор команд находится в том месте, где он должен быть выполнен. Таким образом, при использовании хранимых процедур возможно уменьшение нагрузки на сеть. Использование хранимых процедур реализует принцип модульного проектирования, так как процедуры позволяют разбивать большие задачи на самостоятельные, более
мелкие и удобные в управлении части.
Триггер (trigger) SQL Server 2000 — это специальный тип хранимых процедур, запускаемых сервером автоматически при выполнении тех или иных действий с данными таблицы. Каждый триггер привязывается к конкретной таблице. Когда пользователь пытается, например, изменить данные в таблице, сервер автоматически запускает триггер и, только если он завершается успешно, разрешается выполнение изменений. Все производимые триггером модификации данных рассматриваются как одна транзакция. В случае обнаружения ошибки или нарушении целостности данных происходит откат этой транзакции. Тем самым внесение изменений будет запрещено. Будут также отменены все изменения, уже сделанные
триггером. C помощью ограничений целостности, правил и значений по умолчанию не всегда можно добиться нужного уровня функциональности. Часто требуется реализовать сложные алгоритмыпроверки данных, чтобыгарантировать их достоверность и реальность. Кроме того, бывает необходимо отслеживать изменения значений таблицы, чтобы нужным образом изменить связанные данные. Для решения этих и многих других проблем используются триггеры. Область применения триггеров не ограничивается какими-то строго рамками. Вы можете свободно применять триггеры по своему усмотрению, исходя из требований к удобству и производительности выполняемых действий.
Достоинства триггеров:
− автоматическое обеспечение каскадных воздействий в дочерней таблице при выполнении операций над родительскими таблицами, при этом эти каскадные воздействия выполняются на сервере, и пользователю нет нужды заботиться об этом на клиентских программах. (Не все СУБД поддерживают при определении таблиц каскадные воздействия в дочерних таблицах)
− изменения в триггерах не ведут к переписыванию клиентских программ и не требуют распространения новых версий клиентских программ между пользователями.
− При отказе (отмене) транзакций отменяются также все изменения, внесенные в БД с помощью триггеров.Для эффективного применения триггеров необходимо четкое понимание принципов их действия. Не следует применять триггерыдля выполнения простых проверок, которыемогут быть произведеныс помощью правил или ограничений целостности. Кроме того, следует избегать использования триггеров, если теже действиямогут быть реализованы с помощью хранимой процедурыили обычного пакета команд Transact-SQL. Использование триггеров нежелательно еще и по той причине, что они удерживают блокировку до завершения триггера, запрещая обращение к ресурсу других пользователей. Триггерыразличаются по типу команд, на которые они реагируют. Существуют три типа триггеров.
- INSERT TRIGGER. Триггеры этого типа запускаются при попытке вставки данных с помощьюкомандыINSERT;
- UPDATE TRIGGER. Триггерыэтого типа запускаются при попытке изменения данных с помощьюкомандыUPDATE;
- DELETE TRIGGER. Триггерыэтого типа запускаются при попытке удаления данных с помощьюкомандыDELETE.