Дальше пример из л.Р. 4.

Информационная модель представляется в виде диаграмм “сущность-связь”, отражающих основные объекты предметной области и связи между ними. Дополнительно определяются атрибуты сущностей, характеристики связей, индексы и бизнес-правила, описывающие ограничения и закономерности предметной области. После создания ER-диаграммы пакет автоматически генерирует SQL-код для создания таблиц, индексов и других объектов БД. По заданным бизнес-правилам формируются стандартные триггеры БД для поддержки целостности данных, для сложных бизнес-правил можно создавать собственные триггеры, используя библиотеку шаблонов.

25. Место СУБД в системе информационного обслуживания управленческой деятельности; эволюция развития СУБД; функциональная структура СУБД.

Место субд в системе информационного обслуживания управленческой деятельности - сппр же!

Эволюция развития СУБД:

1. СУБД первого поколения(иерархическая –> сетевая модель данных). Поголовно коммерческие и использовались для работы на мейнфремах. Недостатки – сложно писать запросы, нет четких стандартов. Пример - IMS (Information Management System), разработанная в 60х.

2.СУБД второго поколения (реляционная модель данных), разработан SQL – стандартный ЯМД для всех реляционных СУБД. Используются и на ПК, и на мейнфремах. Недостатки – ограниченные возможности моделирования. Пример – современные СУБД Access, Oracle и т.д.

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

Не стоит думать, что в наше время не используются СУБД первого поколения – сейчас такие системы известны как NoSQL СУБД.

Функциональная структура СУБД:

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

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

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

25. Схема обработки стандартного запроса в СУБД; особенности обработки распределенного запроса в СУБД.

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

Наибольший процент времени при выполнении запроса тратится на обращения к диску /* вспомнить физическое хранение */ и сортировку данных. Поэтому при выполнении запроса сначала выявляются стратегии выполнения запроса, сравниваются и производится выполнение согласно лучшей.

Общая схема обработки запроса

Основные шаги обработки запросов

1 Разбор и трансляция. Язык SQL удобен и понятен пользователю БД, но его невозможно использовать в качестве внутреннего языка БД. В качестве такого языка может выступать расширенная реляционная алгебра. Трансляция при обработке запроса аналогична синтаксическому разбору в трансляторе языка программирования. В процессе трансляции проверяется правильность написания запроса и ассоциация имен, использованных в запросе с именами отношений и атрибутов.

2 Оптимизация. Один и тот же запрос может быть транслирован в различные выражения реляционной алгебры.

Например:

Select Сумма from счет where сумма<2500

Можно транслировать в выражение

s_{сумма<2500}(p_сумма(счет)) или p_сумма(s_{сумма<2500}(счет)).

Для выполнения каждого оператора реляционной алгебры могут использоваться различные алгоритмы. Например, для вычисления селекции нужно пересмотреть все кортежи отношения. Если же построен индекс, по атрибуту «сумма», то можно использовать индекс для проверки условия, а затем извлекать найденные кортежи, используя адрес в индексе. Таким образом, недостаточно оттранслировать запрос в операторы реляционной алгебры, необходимо еще определить, как будет выполняться каждый из этих операторов. Инструкция для выполнения оператора реляционной алгебры называется вычислительным примитивом. Последовательность примитивов, которая будет использована для выполнения запроса, называется планом выполнения запроса. Пример такого плана

p_сумма ------ s_{сумма<2500}; используя индекс 1 ------- отношение счет

/* Рисовать деревом сверху вниз (вычисляться будет снизу вверх ) */

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

3 На третьем шаге используя выбранный план осуществляется выбор данных.

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

25. Обеспечение целостности системы баз данных; триггеры и хранимые процедуры в СУБД.

Целостность базы данных (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.

25. Критерии выбора СУБД.

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

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

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

У современных СУБД необходимо рассматривать:

модель данных;

особенности архитектуры и функциональные возможности;

возможности контроля работы СУБД;

особенности разработки приложений;

производительность;

доступность БД - постоянная возможность получения ответа на запрос;

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

наличие средств защиты данных от несанкционированного доступа;

поддержку стандартных механизмов доступа к данным (ODBC, JDBC, OLE DB);

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

качество и полноту документации;

возможность использования национальных языков;

логическую и физическую организацию хранения данных (распределение таблиц, индексов и других объектов БД по файлам, областям, пакетам, владельцам, схемам);

аутентификацию, распределение прав доступа и система безопасности (пользователи, группы, роли);

структуру БД (типы данных и размеры полей, ограничения на поля, индексы и т.п.);

ссылочную целостность (первичные и внешние ключи, ссылки между таблицами);

возможности программирования триггеров, хранимых процедур и пользовательских функций (встроенные языки программирования сценариев), SQL-запросы, команды и операторы (поддержка уровня ANSI, конструкции запросов, встроенные функции и т.п.);

преобразование данных (обработка пустых полей и значений NULL, конвертирование дат в числа или строк в числа и т.п.);

программный интерфейс клиентской части для прямого доступа к программам, составляющим СУБД, например, Oracle Call Interface (поддержка связанных переменных, обработка массивов записей в пакетном режиме, обработка результатов запросов);

драйверы верхнего уровня (ODBC, JDBC, OLEDB, ADO, др.);

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

поддержку ОС Unix (Sun Solaris, HP-UX, IBM AIX, Linux) и Windows, протоколов взаимодействия клиента с сервером и поддержка транспортного уровня (TCP/IP, IPX/SPX, NetBIOS).

25. Технология хранилищ данных: основные положения и допущения, модели данных для хранилищ данных.

создание хранилищ данных (Data warehouses), то есть процесс сбора, отсеивания и предварительной обработки данных с целью предоставления результирующей информации пользователям для статистического анализа (а нередко и создания аналитических отчетов). Ральф Кимбалл (Ralph Kimball), один из авторов концепции хранилищ данных, описывал хранилище данных как место, где люди могут получить доступ к своим данным (Ralph Kimball, The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses, John Wiley & Sons, 1996 и «The Data Web house Toolkit: Building the Web-Enabled Data Warehouse», John Wiley & Sons, 2000). Он же сформулировал и основные требования к хранилищам данных:

 поддержка высокой скорости получения данных из хранилища;

 поддержка внутренней непротиворечивости данных;

 возможность получения и сравнения так называемых срезов данных (slice and dice);

 наличие удобных утилит просмотра данных в хранилище;

 полнота и достоверность хранимых данных;

 поддержка качественного процесса пополнения данных.

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

25. Тенденции развития современных технологий управления базами данных.

«управление данными (data management) – общее понятие, описывающее функции системы, которые обеспечивают создание и доступ к хранимым данным, соблюдение соглашений о хранении данных, регулирование использования устройств ввода – вывода». Этот термин долгое время использовался только для данных, находящихся в памяти ЭВМ. Основным инструментом управления данными здесь является СУБД.

Таблица 1 - Эволюция управления данными

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

Управление данными в экспедициях и экспериментах, пунктах измерений

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

Управление данными в центрах обработки данных

Одновременно с организацией управления данными на уровне источников данных развивалось управление данными в центрах сбора (мировых и национальных центрах данных). После создания в 1957 г. системы мировых центров данных началась работа по занесению данных на технические носители по различным дисциплинам. По мере увеличения числа дисциплин, по которым собирались данные, накопления данных в различных форматах, перехода обработки данных с одного на другое поколение ЭВМ, существенно усложнилась проблема управления данными в центрах сбора. Необходимо не только отслеживать форматы сбора данных, но и правила конвертирования, чтобы не потерять информацию. Появилась проблема дублирования данных, полученных из разных источников (от разных стран и Мировых центров данных). На первое место выдвинулась проблема качества данных. Одной из важных проблем стало создание упорядоченных БД с эффективным доступом к ним. Для решения этих задач создаются:

• система ведения метаданных;

• инвертированные массивы данных;

• массивы расчетных характеристик.

Так как большого опыта в управлении огромными массивами данных (сотни Гигабайт) не было ни в России, ни в других странах, то каждый центр разрабатывал свои технологии управления данными. Только в девяностых годах, когда основные дисциплинарные массивы с большей или меньшей полнотой были переведены на современные технические носители, а возможности персональных ЭВМ позволили обрабатывать эти данные, наилучшим способом управления данными в центре стало применение мощной коммерческой СУБД. При этом стало возможным создать интегрированную БД (т.е. объединить в рамках одной БД несколько дисциплинарных массивов). Главной проблемой управления данными в центрах обработки данных становится качество, сохранность и восстановление данных после сбоев.

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