Физические модели данных (наиболее популярные) - описывают то, как данные хранятся в компьютере: структуру записей, их упорядоченность, существующие пути доступа:

• Обобщающая модель (unifying model)

• Модель памяти кадров (frame memory)

Иерархическая модель данных (имд) //первое поколение субд

Под ИМД понимается модель, объединяющая записи, хранимые в общей древовидной структуре с одним корневым типом записей, который имеет несколько подчиненных типов записей или не имеет совсем. Каждый подчиненный тип записи может иметь несколько подчиненных типов или не иметь их совсем.

Структура работает по указателям (адресам).

В общем случае существуют связи трех типов:

1. 1:1 – один к одному

2. 1:M (N) – один ко многим

3. N:M – многие ко многим (например, студенты и дисциплины)

«-» ИМД:

1. Поддержка связей типа 1:1 и 1:M.

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

3. Дочерние экземпляры не могут существовать без наличия родительских экземпляров.

«+» ИМД: Моделирует, хотя и сложно, систему управления предприятием в целом.

Сетевая модель данных (смд) //первое поколение субд

Под СМД понимается модель, состоящая из записей, элементов данных и связей типа 1:M (1:1, как частный случай), установленных между записями. При этом связи типа N:M и рекурсивные связи поддерживаются с помощью декомпозиции.

Рекурсивная связь – ссылка объекта на самого себя.

Если в ИМД допустить связь между узлами поддеревьев, получится СМД (нет одного корня).

«-» СМД:

1. Практическая невозможность изменения структуры (=> гибель первого поколения СУБД).

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

3. Требуется помощь квалифицированного программиста.

Реляционная модель данных (рмд) //второе поколение субд

РМД опирается на систему понятий реляционной алгебры, поддерживает связи 1:M (1:1, как частный случай), а связи типа N:M и рекурсивные связи реализуются с помощью декомпозиции.

В реляционных базах данных вся информация представляется в виде двумерных таблиц. Таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных. Таблица отражает тип объекта реального мира (сущность), а каждая ее строки (кортеж) – конкретный объект. Например, таблица “Сотрудники отдела” содержит сведения обо всех сотрудниках отдела, каждая ее строка – набор значений атрибутов конкретного сотрудника. Значения конкретного атрибута выбираются из домена (domain) – множества всех возможных значений атрибута объекта. Имя столбца должно быть уникальным в таблице. Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или набор столбцов) называется первичным ключом (может быть простым и составным). В таблице “Сотрудники отдела” первичным ключом служит столбец “Номер пропуска”. В таблице не должно быть строк, имеющих одно и то же значение первичного ключа. Если таблица удовлетворяет этому требованию, она называется отношением.

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

«+»РМД:

1. Наличие развитой теории РМД.

2. Наличие аппарата приведения к реляционной других моделей данных.

3. Поддержка специальных средств ускоренного доступа к информации (первичный ключ – для уникального определения записей; вторичные индексы – для сортировки).

4. Наличие стандартизированного высокоуровневого языка запросов.

Модель данных на основе инвертированных списков

Похожа на РМД. Но отличается от нее тем, что:

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

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

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

4.Приведите сравнительную характеристику структур хранения данных

4 структуры хранения данных:

• последовательные файлы (heap);

• хешированные файлы (hash);

• индексно-последовательные файлы (ISAM);

• двоичные деревья (B⁺-Tree).

Последовательные файлы

Неупорядоченный последовательный файл (sequential file) является простейшим типом структуры файлов. Записи размещаются в файле в том порядке, в котором они в него добавляются. Каждая новая запись помещается на последнюю страницу файла. Это позволяет очень эффективно выполнять операции вставки. Для доступа к его записям потребуется выполнить линейный поиск - последовательно считываются все страницы файла до тех пор, пока не будет найдена нужная запись. Операции извлечения данных выполняются относительно медленно. Для удаления записи сначала потребуется извлечь нужную страницу, потом удалить нужную запись, а после этого снова сохранить эту страницу на диске.

Последовательный файл или куча является наиболее удобной структурой для хранения данных в следующих случаях:

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

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

• при каждом обращении к таблице выборке подлежат все ее кортежи (в любом порядке). Пример – выборка адресов всех сдаваемых в аренду объектов;

• таблица имеет дополнительные структуры поиска, например, индекс по ключу.

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

Хешированные файлы

Для вычисления адреса страницы, в которой должна находиться та или иная запись, используется хеш-функция (hash function), аргументами которой являются значения одного или нескольких полей этой записи. Подобное поле называется полем перемешивания (hash field), а если поле также является ключевым полем файла, то оно называется хеш-ключом (hash key). Записи в хешированном файле произвольным образом распределены по всему доступному для файла пространству. По этой причине хешированные файлы иногда называют файлами с произвольной структурой (random file) или файлами прямого доступа (direct file).

Хеш-функция выбирается таким образом, чтобы записи внутри файла были распределены максимально равномерно. Один из методов построения хеш-функции носит название свертка (folding) и основан на выполнении некоторых арифметических действий над различными частями поля перемешивания.

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

Индексно-последовательные файлы

Отсортированный файл с первичным индексом называется индексированным последовательным файлом или индексно-последовательным файлом. Эта структура является компромиссом между файлами с последовательной и произвольной организацией. В таком файле записи могут обрабатываться как последовательно, так и выборочно с произвольным доступом, осуществляемым на основе поиска по заданному ключевому значению с использованием индекса. Индексированный последовательный файл имеет более сложную структуру, которая обычно включает следующие компоненты: первичная область хранения; отдельный индекс или несколько индексов; область переполнения.

Подобная организация файлов используется в методе индексно-последовательного доступа ISAM (Indexed Sequential Access Method), он представляет собой более гибкую структуру хранения данных. Он поддерживает выборку данных по точному совпадению значения ключа, по шаблону подстановки, по диапазону значений и по части основного ключа. Однако структура индекса ISAM-файла статична и создается в момент создания самого файла. Поэтому производительность доступа к данным ISAM-файла снижается по мере обновления его данных.

Двоичные деревья

Дерево состоит из иерархии узлов (node), в которой каждый узел, за исключением корня (root), имеет родительский (parent) узел, а также один, несколько или ни одного дочернего (child) узла. Корень не имеет родительского узла. Узел, который не имеет дочерних узлов, называется листом (leaf). Глубиной дерева называется максимальное количество уровней между корнем и листом. Глубина дерева может быть различной для разных путей доступа к листам. Если же она одинакова для всех листьев, то в этом случае дерево называется сбалансированным или B-деревом (B-tree). Степенью (degree) или порядком (order) дерева называется максимально допустимое количество дочерних узлов для каждого родительского узла. Бинарным деревом (binary tree) называется дерево порядка 2, в котором каждый узел имеет не больше двух дочерних узлов

По сравнению с хешированными файлами двоичные деревья также представляют собой значительно более гибкие структуры хранения данных. Они позволяют выполнять выборку данных по точному совпадению ключевого значения, по шаблону подстановки, по диапазону значений и по частично заданному ключу. Индекс двоичных деревьев является динамическим, увеличивающимся по мере роста таблицы. Благодаря этому эффективность доступа в двоичных деревьях не снижается по мере обновления данных таблицы. Файлы структуры B⁺-Tree постоянно сохраняют упорядоченность доступа по ключу, даже при обновлении их данных. Поэтому скорость выборки строк в порядке значений ключа здесь выше, чем у ISAM-файлов, и является постоянной. Однако если информация в таблице не подвергается постоянным изменениям, то использование структуры бинарного дерева может оказаться менее эффективным по сравнению с индексно-последовательными файлами.

5. Сравните функции централизованных и распределенных субд (на примере реляционных субд).

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

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

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

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

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

Функции СУБД:

1. Хранение, извлечение и обновление данных

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

3. Поддержка транзакций.

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

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

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

7**. Поддержка обмена данными. СУБД должна обладать способностью к интеграции с коммуникационным программным обеспечением. Большинство пользователей осуществляют доступ к базе данных с помощью терминалов. Иногда эти терминалы подсоединены непосредственно к компьютеру с СУБД. В других случаях терминалы могут находиться на значительном удалении и обмениваться данными с компьютером, на котором располагается СУБД, через сеть. В любом случае СУБД получает запросы в виде сообщений обмена данными (communications messages) и аналогичным образом отвечает на них. Такая передача данных управляется менеджером обмена данными. Хотя этот менеджер не является частью собственно СУБД, тем не менее, чтобы быть коммерчески жизнеспособной, любая СУБД должна обладать способностью интеграции с разнообразными существующими менеджерами обмена данными. Даже СУБД для персональных компьютеров должны поддерживать работу в локальной сети, чтобы вместо нескольких баз данных для каждого пользователя можно было установить одну централизованную базу данных и использовать ее как общий ресурс для всех пользователей. При этом предполагается, что не база данных должна быть распределена в сети, а удаленные пользователи должны иметь возможность доступа к централизованной базе данных. Такая топология называется распределенной обработкой.

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

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

10. Вспомогательные службы

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

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

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

Функции СУРБД:

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

2. расширенные средства ведения каталога, позволяющие сохранять сведения о распределении данных в сети;

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

4. расширенные функции управления параллельностью, позволяющие поддерживать целостность реплицируемых данных;

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

Правило 11 – независимость от распределения данных (одно из 12 правил Э.Кодда из группы «правила независимости от данных», предложенных им для определения реляционных систем):

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

6. Стандарты языка sql

SQL является одним из двух доминирующих языков, используемых в реляционных базах данных, существует в различных формах с середины 70-х годов и приобрел огромную популярность в 80-е годы, когда реляционные базы данных получили широкое распространение как на больших вычислительных машинах, так и на мини-ЭВМ. Истоки SQL следует отнести к периоду возникновения реляционной модели. Историю разработки языка SQL иллюстрирует рис. 3.1. (SEQUEL - ранняя версия SQL, Structured English QUEry Language).

Одной из причин преуспевания SQL послужило формирование ANSI комитета X3H2, учрежденного для разработки стандартов языков баз данных. Документ, озаглавленный "SQL" представлял собой сведения о различных формах SQL, используемых в коммерческих программных продуктах. Примерно в то же время ISO в рамках технического комитета TC97 также вела работу по созданию стандарта языков реляционных баз данных. В середине 80-х годов обе организации одобрили стандарты SQL (ANSI – в 1986 году, а ISO – в начале 1987 года).

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

Однако еще до 1989 года как в ANSI, так и в ISO началась работа по радикальным расширениям SQL. Эта работа, первоначально идентифицированная как SQL2, началась в 1987 году, и ее результаты спустя пять лет были приняты в качестве стандарта SQL-92. При этом работа над SQL2 перекрывалась работой над SQL3, новой версией стандарта SQL, которая до сих пор находится в стадии разработки. Работа над SQL3 началась в 1990 году параллельно с SQL2 главным образом как “запасной вариант” для возможностей, которые предполагалось не включать по тем или иным причинам в SQL2 (объектно-ориентированные расширения языка, дополнительные реляционные возможности). История стандартизации SQL отражена на рис. 3.2.

Рассмотрим кратко стандарт SQL-92, предусматривающий разделение языка на три различных уровня:

1. Базовый SQL. Этот уровень построен таким образом, чтобы он был очень похожим на SQL-89 с некоторыми небольшими различиями, такими как новые интерфейсы языков программирования для Ада, С и MUMPS, переменная состояния SQLSTATE и др.

2. Промежуточный SQL. Построен таким образом, чтобы охватить примерно половину оставшихся различий между SQL-89 и SQL-92, и включает динамический SQL, операторы манипулирования схемой, поддержку доменов, а также некоторые другие элементы языка.

3. Полный SQL. Это полный стандарт SQL-92. К числу различий между ним и промежуточным SQL следует отнести отложенную проверку ограничений целостности, операторы поискового обновления и удаления, в которых условия поиска ссылаются на столбцы таблицы-операнда, позиционирование курсоров, временные таблицы, утверждения и другие возможности.

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

Рассмотрим основные возможности языка SQL-92:

• манипулирование таблицами. В дополнение к созданию таблиц с помощью оператора CREATE TABLE были добавлены также возможности удаления таблиц (DROP TABLE) и модификации их содержимого (ALTER TABLE);

• домены. В SQL-92 добавлена возможность определения доменов. Одно из преимуществ использования доменов состоит в том, что любые изменения в определении домена распространяются на все определения столбцов во всех таблицах, в которых используется определение этого домена;

• новые типы данных. В SQL-92 были добавлены следующие типы данных: DATE; TIME; TIMESTAMP; строки типа BIT; литерные и битовые строки переменной длины; строки типа NATIONAL CHARACTER (ориентированы на национальные наборы символов);

• новый параметр состояния. Имеющийся в предыдущей версии стандарта код состояния SQLCODE был заменен параметром SQLSTATE, который предоставляет гораздо больше диагностической информации. Кроме того, была добавлена диагностическая область. Размер этой области специфицируется пользователем с помощью оператора SET TRANSACTION или является величиной, определяемой реализацией, если пользователь явно не указал этого размера;

• операторы транзакций. Небольшие синтаксические изменения были сделаны в операторах COMMIT и ROLLBACK (оба используются для завершения транзакций). В стандарте SQL-89 вместе с ключевыми словами этих операторов следовало использовать слово WORK (COMMIT WORK и ROLLBACK WORK). В SQL-92 слово WORK было сделано необязательным. В отличие от некоторых коммерческих СУБД транзакции начинаются не выполнением оператора START TRANSACTION, а неявно;

• дополнительные связывания языка. Базовый SQL, в основном, совпадает со стандартом SQL-89 с небольшими расширениями;

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

• информационная схема. Стандарт SQL-92 предоставляет формальные средства для управления метаданными базы данных. Информационная схема обеспечивает в качестве формального метода управления метаданными базовые таблицы в схеме определения (DEFINITION_SCHEMA) и построенные на их основе таблицы-представления (view), управляемые в информационной схеме (INFORMATION_SCHEMA);

• безопасность. В стандарте SQL-89 свойства безопасности были предусмотрены для таблиц, столбцов и представлений. В SQL-92 были добавлены возможности защиты и управления доступом для доменов, наборов символов, сортирующих последовательностей и трансляций. Возможности защиты предоставляются в следующих областях: выборка (SELECT); добавление (INSERT); обновление (UPDATE); удаление (DELETE); возможность ссылки (REFERENCES); использование (USAGE) – для доменов, наборов символов, сортирующих последовательностей и трансляций. Привилегии предоставляются с помощью оператора GRANT. В стандарте SQL-89 привилегии никогда не могут быть отменены, а в SQL-92 эта возможность добавлена и может осуществляться с помощью оператора REVOKE. Кроме того, привилегии могут предоставляться таким образом, что их получателю может быть позволено передавать данную конкретную привилегию. Такая возможность осуществляется путем снабжения оператора GRANT спецификаций WITH GRANT OPTION. Хотя свойства безопасности в SQL-92 были значительно расширены по сравнению с более ранними версиями стандарта SQL, им еще недостает ряда возможностей, необходимых для основных приложений с повышенными требованиями к безопасности;

• временные таблицы. В SQL-92 добавлена поддержка для явного создания временных таблиц в контексте транзакции. Они исключают накладные расходы, связанные с постоянными таблицами, но могут использоваться для хранения результатов промежуточных операций или для других целей.

Кроме того, продолжается работа над стандартом SQL3, который пока ещё не принят.

7. Анализ архитектур многозвенных приложений для работы с базами данных

Большинство прикладных программ можно условно разделить на 3 части:

• Логику представления (интерфейсные алгоритмы)

• Бизнес-логику (расчетные алгоритмы, правила)

• Логику доступа к данным (алгоритмы хранимых процедур)

Известны 3 основных типа архитектуры систем распределенной обработки:

• Централизованная архитектура (телеобработка)

• Архитектура файл-сервер

• Архитектура клиент-сервер

Телеобработка (60 – 70 гг.)

Традиционной архитектурой многопользовательских систем раньше считалась схема, получившая название “телеобработка”, при которой один из компьютеров с единственным процессором был соединен с несколькими терминалами так, как показано на рис.

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

«-» 1. Так как главное ядро системы – центральный компьютер, то надежность системы низка.

2. Ориентация на конкретную аппаратуру (нет взаимозаменяемости).

3. Недостаточная гибкость приложений.

«+» 1.Простая разработка приложений.

2. Легкость в обслуживании и управлении (всё в одном месте).

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

Файловый сервер (80 – 90 гг.)

В среде файлового сервера обработка данных распределена в сети, обычно представляющей собой локальную вычислительную сеть (ЛВС). Файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Однако пользовательские приложения, СУБД и копии базы данных размещены и функционируют на отдельных рабочих станциях, и обращаются к файловому серверу только по мере необходимости получения доступа к нужным им файлам (рис.). Таким образом, файловый сервер функционирует просто как совместно используемый жесткий диск. СУБД на каждой рабочей станции посылает запросы файловому серверу по всем необходимым ей данным, которые хранятся на диске файл-сервера (приходилось передавать не ответ на запрос, а всю копию БД; сложно не нарушать ссылочную целостность; архитектура была популярна при использовании СУБД типов dBase, FoxPro, Access). Такой подход характеризуется значительным сетевым трафиком, что может привести к снижению производительности всей системы в целом.

Таким образом, архитектура с использованием файлового сервера обладает следующими основными недостатками:

• большой объем сетевого трафика;

• на каждой рабочей станции должна находиться полная копия СУБД;

• управление параллельностью, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД.

«+» Надежнее телеобработки.

Технология клиент/сервер (с 90-х гг. По настоящее время)

Технология клиент/сервер разработана с целью устранения недостатков, имеющихся в первых двух подходах. Термин “клиент/сервер” означает такой способ взаимодействия программных компонентов, при котором они образуют единую систему: существует клиентский процесс, требующий определенных ресурсов, а также серверный процесс, который эти ресурсы предоставляет. Как правило, принято размещать сервер на одном узле локальной сети, а клиентов – на других узлах. На рис. показана общая архитектура типа клиент/сервер, хотя возможны и альтернативные варианты топологии: один клиент – один сервер; несколько клиентов – один сервер; несколько клиентов – несколько серверов.

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

Такой тип архитектуры обладает приводимыми ниже преимуществами:

• обеспечивается более широкий доступ к существующим базам данных;

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

• стоимость аппаратного обеспечения снижается. Достаточно мощный компьютер с большим устройством хранения необходим только серверу;

• сокращаются коммуникационные расходы. Приложения выполняют часть операций на клиентских компьютерах и посылают через сеть только запросы к базе данных, что позволяет существенно сократить объем пересылаемых по сети данных;

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

• такая архитектура естественным образом отображается на архитектуру открытых систем.

Дальнейшим расширением двухуровневой архитектуры клиент/сервер является трехуровневая архитектура, при которой функциональная часть прежнего толстого (интеллектуального) клиента разделяется на две части: тонкий (неинтеллектуальный) клиент на рабочей станции управляет только пользовательским интерфейсом, тогда как средний уровень обработки данных управляет всей остальной логикой приложения. Третьим уровнем здесь является сервер базы данных. Эта трехуровневая архитектура оказалась более подходящей для некоторых сред, например, для сетей Internet и Intranet, где в качестве клиента может использоваться обычный Web-броузер (среднее звено – провайдер услуг, а сервер – где угодно в мире).

Технология клиент-сервер объединяет 3 варианта архитектуры:

• Двухзвенная

• Трехзвенная

• Многозвенная

Двухзвенная архитектура клиент-сервер:

1. Конфигурация «тонкий» сервер – «толстый» клиент

2. Конфигурация «толстый» сервер – «тонкий» клиент

«-» 1.Если логика представлений меняется, её надо менять везде.

2. «Узкое» место – сервер, так как обрабатывает несколько баз.

Концептуальная трехзвенная архитектура клиент-сервер:

Возможны 4 варианта среднего звена:

• Мониторы обработки транзакций

• Сервер передачи сообщений

• Сервер приложений (самый популярный вид для реляционных БД)

• Брокеры объектных запросов (ORB) для ООСУБД

«-» 1. Узкое место – среднее звено.

2. Большая сложность и стоимость разработки прикладных программ.

«+» 1. Высокая масштабируемость (max число пользователей теоретически не ограничено).

2. Большая производительность и надежность.

3. Гибкость системы.

Известна 5-тизвенная архитектура клиент-сервер. Служит для связи с унаследованными системами (СУБД старого поколения).

8. Назначение и стадии нормализации реляционных баз данных

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

Нормализация – это метод создания набора отношений с заданными свойствами на основе требований к данным, установленным в некоторой организации.

Процесс нормализации был впервые предложен Э. Ф. Коддом (1972). Нормализация часто выполняется в виде последовательности тестов для некоторого отношения с целью проверки его соответствия (или несоответствия) требованиям заданной нормальной формы. Таким образом, процесс нормализации основывается на концепции нормальных форм. Говорят, что отношение находится в некоторой нормальной форме, если удовлетворяет заданному набору условий.

// Нормализация необходима для оптимизации данных (например, чтобы сведения в базе данных не повторялись).

Сначала Э. Ф. Коддом были предложены три вида нормальных форм: первая (1НФ), вторая (2НФ) и третья (3НФ). Затем Р. Бойсом и Э. Ф. Коддом (1974) было сформулировано более строгое определение третьей нормальной формы, которое получило название нормальной формы Бойса – Кодда (НФБК). Все эти нормальные формы основаны на функциональных зависимостях, существующих между атрибутами отношения. Впоследствии Фейгином (Fagin, 1977, 1979) были определены четвертая (4НФ) и пятая (5НФ) нормальные формы. Однако на практике нормальные формы более высоких порядков используются крайне редко.

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

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

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

Первая нормальная форма – это отношение, в котором все используемые домены содержат только скалярные (атомарные) значения, и не имеют повторяющихся групп.

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

• В первом подходе повторяющиеся группы устраняются путем ввода соответствующих данных в пустые столбцы строк с повторяющимися данными. Иными словами, пустые места при этом заполняются дубликатами неповторяющихся данных. Этот подход часто называют “выравниванием” (flattening) таблицы.

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

Если 1НФ не выполнена, то база не является реляционной, и говорить о других нормальных формах не имеет смысла.

Иногда разработчики нарушают требования 1НФ. Например, СУБД Advanced Revelation, которая основана на модели ассоциативных мотивов (не реляционная модель).

Вторая нормальная форма (2НФ) основана на понятии полной функциональной зависимости.

В некотором отношении атрибут B называется полностью функционально зависимым от атрибута A, если атрибут B функционально зависит от полного значения атрибута A и не зависит ни от какого подмножества полного значения атрибута A.

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

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

// 2НФ нужна для правильного назначения первичных ключей.

Если для атрибутов A, B и C некоторого отношения существуют зависимости вида A ® B и B ® C, то говорят, что атрибут C транзитивно зависит от атрибута A через атрибут B (при условии, что атрибут A функционально не зависит ни от атрибута B, ни от атрибута C).

Транзитивная зависимость является описанием такого типа функциональной зависимости, которая возникает при наличии следующих функциональных зависимостей между атрибутами A, B и С:

A ® B и B ® C

В данном случае транзитивная зависимость A ® C осуществляется через атрибут B. Это утверждение справедливо только в том случае, если атрибут A функционально не зависит от атрибутов B и C.

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

// 3НФ требует отсутствия транзитивных функциональных зависимостей; не должно быть в базе вычисляемых полей.

Иногда применяется денормализация, то есть обоснованное нарушение нормальной формы. Но, принимая решение о денормализации, следует учитывать следующее:

• денормализация существенно усложняет реализацию;

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

• денормализация ускоряет выборку данных, одновременно замедляя их обновление.

Формально термин денормализация означает внесение в реляционную схему таких усовершенствований, при которых уровень нормализованности обработанных отношений по сравнению с уровнем нормализованности хотя бы одного из исходных отношений уменьшается. Иногда этот термин используется в более широком понимании – для определения ситуации, когда объединяются два отношения в одно.

Начальное определение Э. Ф. Кодда для 3НФ не совсем подходит для отношений с перечисленными ниже условиями:

• отношение имеет два (или более) потенциальных ключа;

• два потенциальных ключа являются сложными;

• потенциальные ключи перекрываются (т. е. имеют, по крайней мере, один общий атрибут).

Поэтому оригинальное определение 3НФ было впоследствии заменено более строгим определением Бойса – Кодда (Boyce/Codd), для которого было принято отдельное название – нормальная форма Бойса – Кодда, НФБК. (На самом деле строгое определение “третьей” нормальной формы, эквивалентное определению нормальной формы Бойса – Кодда, было впервые дано Хезом (Heath) в 1971 году, и этой форме следовало бы дать название “нормальная форма Хеза”.)

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

Функциональная зависимость называется неприводимой слева, если ее левая часть не является избыточной. Менее формальное определение имеет другую формулировку: отношение находится в нормальной форме Бойса – Кодда тогда и только тогда, когда детерминанты являются потенциальными ключами.

// НФБК требует, чтобы каждый столбец, от которого зависит другой столбец, сам являлся уникальным ключом.

Пусть A, B и С являются произвольными подмножествами множества атрибутов отношения R. Тогда B многозначно зависит от A, что символически выражается записью:

A –>>B (читается как “A многозначно определяет B” или “A двойная стрелка B”), тогда и только тогда, когда множество значений B, соответствующее заданной паре (значение A, значение C) отношения R, зависит только от A, но не зависит от C.

В работах Фейгина показано, что для данного отношения R{A, B, C} многозначная зависимость A –>> B выполняется тогда и только тогда, когда также выполняется многозначная зависимость A –>> C. Таким образом, многозначные зависимости всегда образуют связанные пары и поэтому их обычно представляют вместе в символическом виде: A –>>B | C.

Отношение R находится в четвертой нормальной форме тогда и только тогда, когда существуют такие подмножества A и B атрибутов отношения R, что не выполняется (нетривиальная) многозначная зависимость A –>> B. Тогда все атрибуты отношения R также функционально зависят от атрибута A.

Нормализация НФБК-отношения с получением 4НФ-отношений заключается в устранении многозначных зависимостей из НФБК-отношений посредством выделения в новое отношение одного или нескольких участвующих в многозначных зависимостях атрибутов вместе с копией одного или нескольких детерминантов (то есть, путем увеличения сущностей). На практике применяется редко.

Пусть R является отношением, а A, B, ... , Z – произвольные подмножества множества атрибутов отношения R. Отношение R удовлетворяет зависимости соединения: * (A, B, ... , Z), тогда и только тогда, когда оно равносильно соединению своих проекций с подмножествами атрибутов A, B, ... , Z (Фейгин).

Отношение R находится в пятой нормальной форме (5НФ) тогда и только тогда, когда каждая зависимость соединения в отношении R подразумевается потенциальными ключами отношения R.

Упрощенное определение говорит о том, что пятая нормальная форма – это отношение без зависимостей соединения. Таким образом 5НФ, которая также называется проективно-соединительной нормальной формой или ПСНФ (project-join normal form – PJNF), означает, что отношение в такой форме не имеет зависимостей соединения. На практике применяется крайне редко.

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

Итоговая схема процедуры нормализации

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

Можно выделить следующие цели процесса нормализации:

• исключение некоторых типов избыточности;

• устранение некоторых аномалий обновления;

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

• упрощение процесса наложения ограничений целостности.

Другие нормальные формы

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

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

Ограничение домена – это ограничение на использование значений для данного атрибута только из некоторого предписанного домена.

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

Нормальная форма типа “выборка – объединение” предполагает возможность декомпозиции на основе выборки по строкам. При этом оператором декомпозиции является непересекающаяся выборка, а соответствующим оператором композиции – непересекающееся объединение. Таким образом, всегда можно создать “выбирающе-объединительную” теорию нормализации, аналогичную, но независимую относительно проекционно-соединительной теории нормализации.

9. Концепции и проблемы er- и err-моделирования

ER-модель

Модель “сущность – связь” (Entity-Relationship model или ER-модель) представляет собой высокоуровневую концептуальную модель данных, которая была разработана Ченом (Chen) в 1976 году с целью упрощения задачи проектирования баз данных. Эта модель данных представляет собой набор концепций, которые описывают структуру базы данных и связанные с ней транзакции обновления и извлечения данных. Основная цель разработки высокоуровневой модели данных заключается в создании модели пользовательского восприятия данных и согласовании большого количества технических аспектов, связанных с проектированием базы данных. Следует особо подчеркнуть, что концептуальная модель данных не зависит от конкретной СУБД или аппаратной платформы, которая используется для реализации базы данных.

Основные концепции модели “сущность – связь” включают типы сущностей, типы связей и атрибуты.

Типы сущностей (entity type) – это объекты или концепции, которые характеризуются на данном предприятии как имеющие независимое существование.

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

Сущность – это экземпляр типа сущности, который может быть идентифицирован уникальным образом.

• Слабый тип сущности – это тип сущности, существование которого зависит от какого-то другого типа сущности (обозначается, как прямоугольник с двойным контуром).

• Сильный тип сущности – это тип сущности, существование которого не зависит от какого-то другого типа сущности (обозначается, как прямоугольник).

Слабые сущности иногда называют дочерними (child), зависимыми (dependent) или подчиненными (subordinate), а сильные – родительскими (parent), сущностями-владельцами (owner) или доминантными (dominant).

Атрибут – это свойство типа сущности или типа связи.

Домен атрибута – это набор значений, которые могут быть присвоены атрибуту.

• Простой атрибут – это атрибут, состоящий из одного компонента с независимым существованием (не могут быть разделены на более мелкие компоненты; иногда называют атомарными).

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

• Однозначный атрибут – это атрибут, который содержит одно значение для одной сущности.

• Многозначный атрибут – это атрибут, который содержит несколько значений для одной сущности.

• Производный атрибут – это атрибут, который представляет значение, производное от значения, связанного с ним атрибута или некоторого множества атрибутов, принадлежащих некоторому (не обязательно данному) типу сущности.

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

Первичный ключ – это потенциальный ключ, который выбран в качестве первичного ключа.

Составной ключ – это потенциальный ключ, который состоит из двух или более атрибутов.

Тип связи – это осмысленная ассоциация между сущностями разных типов.

Связь – это ассоциация между сущностями, включая по одной сущности из каждого участвующего в связи типа сущности.

Степень связи – это количество сущностей, которые охвачены данной связью:

• Связь со степенью два называется бинарной (binary) // две сущности

• Связь со степенью три называется тернарной (ternary) // три сущности

• Связь со степенью четыре называется кватернарной (quaternary) // четыре сущности

• Рекурсивная связь – это такая связь, в которой одни и те же сущности участвуют несколько раз в разных ролях.

Двумя основными типами ограничений, накладываемых на связи, являются кардинальность (cardinality) связи и степень участия (participation):

• Показатель кардинальности описывает количество возможных связей для каждой из сущностей-участниц (1:1 //не целесообразна, 1:M, M:N).

• Степень участия определяет, зависит ли существование некоторой сущности от участия в связи некоторой другой сущности:

  1. Полное (total) участие (обязательное) - для существования некоторой сущности требуется существование другой сущности, связанной с ней определенной связью // выражается двойной линией

  2. Частичное (partial) участие (необязательное) – в противном случае // выражается одной линией

Проблемы er-моделирования

Возможны проблемы, возникающие при разработке концептуальной модели данных (например, могут не выполняться некоторые запросы). Эти проблемы, которые принято называть ловушками соединения (connection trap), обычно возникают вследствие неправильной интерпретации смысла некоторых связей. Рассмотрим два основных типа ловушек соединения: ловушку разветвления (fan trap) и ловушку разрыва (chasm trap):

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

Устраняют путем переназначения связей между сущностями.

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

Устраняют путем определения дополнительной связи между сущностями.

EER-модель (Enhanced ER) //улучшенная

Предназначена для моделирования объектно-ориентированных баз данных.

1. Суперкласс – это тип сущности, включающий разные подклассы, которые необходимо представить в модели данных.

Подкласс – это тип сущности, который исполняет отдельную роль, а также является членом суперкласса.

Например, суперкласс – работники, подкласс – менеджеры, секретари…(то есть должности).

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

Генерализация – это процесс сведения различий между сущностями к минимуму путем выделения их общих характеристик.

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

10. Назначение реляционной алгебры и реляционного исчисления. Начальная реляционная алгебра э. Кодда.

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

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

 Реляционная алгебра – это теоретический язык операций, которые на основе одного или нескольких отношений позволяют создавать другое отношение без изменения самих исходных отношений.

Реляционная алгебра является языком последовательного использования отношений, в котором все кортежи, возможно, даже взятые из разных отношений, обрабатываются одной командой без организации циклов. Э. Ф. Кодд определил так называемую “начальную алгебру” – набор из восьми операторов, символически показанный на рис. 7.1, составляющих две группы по четыре оператора в каждой:

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

• специальные реляционные операции: выборка, проекция, соединение и деление.

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

11. Этапы проектирования баз данных, основанных на различных моделях данных.

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

Основными целями проектирования базы данных являются:

• представление данных и связей между ними, необходимых для всех основных областей применения данного приложения и любых существующих групп его пользователей;

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

• разработка предварительного варианта проекта, структура которого позволяет удовлетворить все основные требования, предъявляемые к производительности системы (например, ко времени реакции системы).

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

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

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

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

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

3 этап. Физическое проектирование данных – это процесс создания описания реализации базы данных на вторичных запоминающих устройствах с указанием структур хранения и методов доступа, используемых для организации эффективной обработки данных.

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

• создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;

• определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность системы с базой данных;

• разработка средств защиты создаваемой системы.

В целом данные этапы являются общими для различных моделей данных. Отличие реляционнх БД и объектно-ориентированных: в реляционных баз данных в 3НФ используются ключи, в объктно-ориентированных – указатели. В объктно-ориентированных баз данных нет понятия нормализации.

12. Методы и средства концептуального проектирования реляционных баз данных

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

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

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

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

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

Концептуальное проектирование базы данных (этапы):

Этап 1. Создание локальной концептуальной модели данных исходя из представлений о предметной области каждого из типов пользователей.

Этап 1.1. Определение типов сущностей.

Этап 1.2. Определение типов связей.

Этап 1.3. Определение атрибутов и связывание их с типами сущностей и связей.

Этап 1.4. Определение доменов атрибутов.

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

Этап 1.6. Специализация или генерализация типов сущностей (необязательный этап).

Этап 1.7. Создание диаграммы “сущность – связь”( ER- диаграммы).

Этап 1.8. Обсуждение локальных концептуальных моделей данных с конечными пользователями.

Задачей первого этапа является разбиение проекта на группу относительно небольших (и более простых) задач исходя из представления о предметной области приложения, свойственных каждому из типов конечных пользователей. Результатом выполнения этого этапа является создание локальных концептуальных моделей данных, представляющих собой полное и точное отражение представлений о предметной области приложения отдельных типов пользователей.

В качестве средств проектирования применяются CASE-пакеты.

CASE-средства (от Computer Aided Software/System Engineering) позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE-средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций. Применимы практически во всех сферах деятельности. Результат применения CASE-средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок.

Линейка AllFusion Modeling Suite:

- AllFusion Process Modeler (ранее: BPwin) - моделирование бизнес-процессов - AllFusion ERwin Data Modeler (ранее: ERwin) - моделирование баз данных и хранилищ данных - AllFusion Data Model Validator (ранее: ERwin Examiner) - проверка структуры СУБД и моделей, созданных в ERwin - AllFusion Model Manager (ранее: ModelMart) - среда для командной работы проектировщиков - AllFusion Component Modeler (ранее: Paradigm Plus) - моделирование приложений и генерация объектного кода

IBM Rational Software:

Rational Software Modeler + Rational Software Architect – моделирование бизнес-процессов и компонентов приложений

Oracle:

 Oracle Designer - моделирование бизнес-процессов и баз данных

А также, Silvernum, Rose Rational и др.

13. Методы и средства логического проектирования реляционных баз данных

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

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

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

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

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

Логическое проектирование базы данных (для реляционной модели). Этапы:

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

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

Этап 2.2. Определение набора отношений исходя из структуры локальной логической модели данных.

Этап 2.3. Проверка модели с помощью правил нормализации.

Этап 2.4. Проверка модели с помощью транзакций пользователей.

Этап 2.5. Создание (уточнение) диаграмм “сущность – связь” (ER- диаграмм).

Этап 2.6. Определение требований поддержки целостности данных.

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

Этап 3. Создание и проверка глобальной логической модели данных.

Этап 3.1. Слияние локальных логических моделей данных в единую глобальную модель данных.

Этап 3.2. Проверка глобальной логической модели данных.

Этап 3.3. Проверка возможностей расширения модели в будущем.

Этап 3.4. Создание окончательного варианта диаграммы “сущность – связь” (ER- диаграммы).

Этап 3.5. Обсуждение глобальной логической модели данных с пользователями.

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

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

В качестве средств проектирования применяются CASE-пакеты.

CASE-средства (от Computer Aided Software/System Engineering) позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE-средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций. Применимы практически во всех сферах деятельности. Результат применения CASE-средств - оптимизация систем, снижение расходов, повышение эффективности, снижение вероятности ошибок.

Линейка AllFusion Modeling Suite:

- AllFusion Process Modeler (ранее: BPwin) - моделирование бизнес-процессов - AllFusion ERwin Data Modeler (ранее: ERwin) - моделирование баз данных и хранилищ данных - AllFusion Data Model Validator (ранее: ERwin Examiner) - проверка структуры СУБД и моделей, созданных в ERwin - AllFusion Model Manager (ранее: ModelMart) - среда для командной работы проектировщиков - AllFusion Component Modeler (ранее: Paradigm Plus) - моделирование приложений и генерация объектного кода

IBM Rational Software:

Rational Software Modeler + Rational Software Architect – моделирование бизнес-процессов и компонентов приложений

Oracle:

 Oracle Designer - моделирование бизнес-процессов и баз данных

А также, Silvernum, Rose Rational и др.

13. Методы и средства физического проектирования реляционных баз данных

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

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

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

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

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

Физическое проектирование базы данных (с использованием реляционной СУБД). Этапы:

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

Этап 4.1. Проектирование основных таблиц в среде целевой СУБД.

Этап 4.2. Реализация бизнес-правил предприятия в среде целевой СУБД.

Этап 5. Проектирование физического представления базы данных.

Этап 5.1. Анализ транзакций.

Этап 5.2. Выбор файловой структуры.

Этап 5.3. Определение вторичных индексов.

Этап 5.4. Анализ необходимости введения контролируемой избыточности данных.

Этап 5.5. Определение требований к дисковой памяти.

Этап 6. Разработка механизмов защиты.

Этап 6.1. Разработка пользовательских представлений (видов).

Этап 6.2. Определение прав доступа.

Этап 7. Организация мониторинга и настройка функционирования системы.

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

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

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

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

В качестве средств проектирования применяются непосредственно СУБД-средства.

15. Сопровождение реляционных баз данных. Технические приемы улучшения показателей работы баз данных.

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

Заключительный этап жизненного цикла включает выполнение таких действий, как:

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

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

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

Технические приемы:

Оптимизация запроса – это процедура выбора наиболее эффективного плана выполнения поступившего запроса.

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

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

Общее правило оптимизации запросов – минимизировать размер всех выполняемых операций реляционной алгебры и выполнять любые унарные операции до выполнения бинарных.

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

Еще одним примером технического приема является настройка утилит для конкретной БД, например, статистика базы данных InterBase/FireBird, полученная через gstat или Services API, предоставляет большое количество статистических данных, которые могут быть использованы для анализа работы сервера и самой базы данных. Приложения, работающие с базой данных, могут корректно работать с транзакциями и самими данными, то есть не создают длительные активные транзакции, не запускают длительные snapshot транзакции. Все это верно для небольшого количества одновременно работающих пользователей, но как только количество пользователей возрастет на порядок и следовательно увеличиться количество операций по вставке, редактированию и удалению данных, могут возникнуть проблемы по сборке, так называемого, мусора. Проведенная и

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

С помощью утилиты gstat с соответствующими ключами или Services API можно получить следующие виды статистики:

* Статистика заголовочной страницы - это информация о глобальных свойствах всей базы данных, хранящаяся на заголовочной страницы каждой базы данных( -header );

* Статистика страниц данных - информация о таблицах содержащихся в базе данных ( -data);

* Статистика индексов - информация об индексах в базе данных (-index);

* Статистика системных таблиц (-system).

Пример использования gstat:

gstat -header -user SYSDBA -password masterkey c:work.gdb

gstat -all -user SYSDBA -password masterkey c:work.gdb

получаем полную статистическую информацию базы данных.

Др.примерами технических приемов являются перепроектирование запросов, реорганизация индексов и другое.

16. Взаимодействие баз данных с корпоративными хранилищами данных.

Хранилище данных – это предметно-ориентированный, интегрированный, привязанный ко времени и неизменяемый набор данных, предназначенный для поддержки принятия решений.

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

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

БД взаимодействует с хранилищами данных в моменты загрузки и очистки данных.

Загрузка в хранилище новых данных – дело не быстрое. Это процесс может занимать часы, и даже дни. Обычно он состоит из следующих операций:

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

- очистка данных. Поступающие данные часто бывают «грязными» в том смысле, что содержат значительные ошибки. В частности, OLTP-системы могут не выполнять строгого контроля целостности, например, ввод записей с неверными идентификаторами клиентов или товаров. Поэтому в процессе наполнения хранилища обычно производится проверка целостности данных;

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

- переформатирование данных. Формат поступающих данных может сильно отличаться от формата, используемого в базе хранилища. Один распространенный источник расхождений – форматы дат и времени. Кроме этих очевидных отличий могут быть и более серьезные: информация из одной таблицы OLTP-источника может разделяться на части, помещаемые в несколько таблиц хранилища, и наоборот, информация из нескольких таблиц может сливаться для помещения в одну таблицу хранилища;

- вставка/обновление данных. После предварительной обработки выполняется помещение данных в хранилище. Обычно это специализированная операция, выполняемая в пакетном режиме без транзакций, но с использованием специальных средств восстановления в случае сбоев. Ее скорость должна быть очень высокой (обычно до сотен мегабайт в час);

- создание/обновление индексов. Специализированные индексы, используемые программным обеспечением хранилища, должны быть модифицированы в соответствии с обновленным содержимым базы данных. Как и в случае вставки/обновления данных, эта операция может потребовать особой обработки. В одних ситуациях быстрее и проще создать весь индекс заново, чем модифицировать его по мере поступления строк, в других ситуациях более приемлемый второй вариант.

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

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

OLTP-системы не предназначены для получения быстрого ответа на произвольные запросы. Они также не используются для хранения устаревших исторических данных, которые требуют для анализа тенденций. OLTP-системы, в основном, поставляют огромное количество «сырых» данных, которые с трудом поддаются анализу. С помощью хранилищ данных можно получить ответы на более сложные вопросы, например, «Какова средняя выручка от продажи товара в каждом отделении компании в сравнении с аналогичными показателями прошлого года?», «Какая связь наблюдается между ежегодной выручкой в каждом отделении компании и общим количеством торговых агентов в каждом из этих отделений».

17. Сравнительная характеристика oltp и olap-систем.

В области информационных технологий существуют два взаимно дополняющих друг друга направления:

• технологии, ориентированные на оперативную (транзакционную) обработку данных. Эти технологии лежат в основе экономических информационных систем, предназначенных для оперативной обработки данных. Называются подобные системы - OLTP ( online transaction processing ) системы;

• технологии, ориентированные на анализ данных и принятие решений. Эти технологии лежат в основе экономических информационных систем, предназначенных для анализа накопленных данных. Называются подобные системы – OLAP.

Необходимо отметить, что различия этих технологий существенны. В таблице 2 приведено сравнение системных характеристик OLTP и OLAP.

18. Специализированные базы данных и их влияние на развитие коммерческих баз данных.

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

2. Активные базы данных. Традиционные базы данных являются пассивными. Технология активных баз данных – это путь к базам знаний, исследуемым в области искусственного интеллекта (ИИ). Свойства активных баз данных заключаются в том, что процедурные элементы общей среды встраиваются в систему базы данных и управляются декларативным образом. Развитие технологии активных баз данных рассматривается в настоящее время как одна из главных тенденций, которая будет революционизировать разработку приложений. Технология хранение операций над данными и процедур вместе с самими данными широко используется в других областях, например в объектно-ориентированных баз данных. Активные системы баз данных предусматривают возможности, позволяющие:

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

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

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

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

• соединение (например, одного шоссе с другим);

• соседство (например, какие районы соединяются данным шоссе);

• порядок (например, линейная последовательность дорожных знаков вдоль шоссе);

• метрические отношения (примерные расстояния, например, “близко”, “далеко” или “однодневный переезд”).

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

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

• анализ изображений и распознавание образов;

• структурирование и понимание изображения;

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

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

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

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

• “обычные” типы данных в базе данных (которые можно встретить в реляционной или сетевой базе данных);

• данные неподвижных изображений (как в фотографиях);

• другие типы графики;

• данные движущихся изображений (видео);

• аудио (голос, музыкальные звуки, звуки, издаваемые животными);

• текстовые данные, например, такие, которые можно найти в документах текстовых процессоров или файлах электронных таблиц.

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

В состав типовой документальной информационно-поисковой системы входят четыре основных подсистемы:

• подсистема ввода и регистрации

• подсистема обработки.

• подсистема хранения.

• подсистема поиска.

На специализированных базах данных опробываются новые решения и наиболее лучшие из них используются при проектировании коммерческих баз данных.

19. Методы обработки запросов в централизованных и распределенных базах данных.

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

1. предполагает использование эвристических правил. Наиболее часто встречаемые правила эвристической обработки запросов:

1. Выполнение операций выборки на самых ранних этапах обработки.

2. Как можно более раннее выполнение операций проекции.

3. Однократное вычисление общих выражений.

4. Объединение в одну операцию соединения операции декартова произведения и следующей за ней операции выборки, предикат которой представляет условие соединения.

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

2. Оценка стоимости операций реляционной алгебры

1. Для каждого базового отношения R

– количество кортежей (записей) в отношении R (т. е. его кардинальность);

– показатель блокирования отношения R (т. е. количество кортежей отношения R, размещаемых в одном дисковом блоке);

– количество блоков вторичной памяти, необходимых для сохранения отношения R. Если кортежи отношения R физически размещены в одном участке, то справедлива следующая формула:

2. Для каждого атрибута A базового отношения R

– количество уникальных значений атрибута A в отношении R;

– минимальное и максимальное количество возможных значений атрибута A в отношении R;

– кардинальность выборки атрибута A в отношении R. Оно представляет собой среднее количество кортежей, которые удовлетворяют условию, заданному для атрибута A.

3. Для каждого многоуровневого индекса I множества значений атрибута A:

– количество уровней индекса I;

– количество листовых блоков индекса I.

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

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

20. Методы оптимизации запросов.

Оптимизация запроса – это процедура выбора наиболее эффективного плана выполнения поступившего запроса. В централизованных СУБД:

1. динамическая оптимизация запросов. Декомпозиция и оптимизация выполняются динамически при каждом вызове запроса.

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

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

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

21. Сравните протоколы управления параллельностью в централизованных субд. Уровни изоляции транзакций.

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

1. Базовым пессимистическим протоколом является метод двухфазной блокировки (2PL, 2-phase loch). (Консервативные (пессимистические) методы. Откладывают выполнение транзакций, способных в будущем в тот или иной момент времени войти в конфликт с другими транзакциями);

Транзакция выполняется по протоколу двухфазной блокировки, если в ней все операции блокировния предшествуют первой операции разблокирования.

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

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

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

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

Преимущество 2PL состоит в том, что его относительно просто реализовать. Протокол 2PL, определяющий моменты усьановки и снятия блокировки для каждой из транзакций, используется для обеспечения упорядоченности. (минус может возникнуть взаимная блокировка. Взаимная блокировка – это тупиковая ситуация, которая может возникнуть, когда две (или более) транзакции находятся во взаимном ожидании освобождения блокировок, удерживаемых каждой из них.)

2. Использование временных отметок. (консервативный метод)

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

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

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

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

• фаза чтения. Она охватывает транзакцию от ее начала и вплоть до момента непосредственного выполнения фиксации результатов. Транзакция считывает значения всех необходимых ей элементов данных и помещает их в локальные переменные. Любые обновления применяются только к локальной копии данных, но не к информации, сохраняемой в самой базе данных;

• фаза проверки. Эта фаза следует за фазой чтения. Выполняются проверки, необходимые для получения гарантий отсутствия нарушения упорядоченности в случае переноса в базу данных изменений, выполненных транзакцией. Для транзакций, включающих только операции чтения, проверка состоит в подтверждении того, что использованные транзакцией значения по-прежнему остаются текущими значениями соответствующих элементов данных. Если нарушений не отмечено, транзакция завершает свое выполнение. Если найдены измененные значения, транзакция отменяется и перезапускается. Если в транзакции выполнялось обновление данных, то проверка включает выполнение контроля того, сохранится ли база данных в согласованном состоянии после внесения в нее результатов данной транзакции, а также не будут ли нарушены условия упорядоченности. В случае обнаружения ошибки транзакция отменяется и перезапускается;

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

Уровни изоляции и проблемы обновления данных в многопользовательской среде.

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

22. Сравните протоколы управления параллельностью в распределенных субд.

Решения по организации управления параллельностью в распределенной среде строятся на двух основных подходах:

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

1. Централизованный протокол двухфазной блокировки. При использовании этого протокола существует единственный сайт, на котором сохраняется вся информация о блокировании элементов данных в системе (Alsberg and Day; Garsia-Molina, 1979). Соответственно во всей распределенной СУБД существует только один планировщик или менеджер блокировки, способный устанавливать и снимать блокировку с элементов данных. (плюсы – его относительно просто реализовать. Обнаружение взаимных блокировок может выполняться теми же методами, что и в центральных СУБД, поскольку вся информация о блокировках элементов находится в распоряжении единственного менеджера блокировок.

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

2. двухфазная блокировка с первичными копиями. В данном случае каждый локальный менеджер отвечает за управление блокировкой некоторого набора элементов данных. Для каждого реплицируемого набора данных одна из копий выбирается в качестве первичной копии (primary copy), а все остальные расцениваются как ведомые копии (slave copy). Выбор первичного сайта может осуществляться по разным правилам, причем сайт, который выбран для управления блокировкой первичной копии данных, необязательно должен содержать саму эту копию.

(плюсы –

минус - усложнение методов обнаружения взаимных блокировок в связи с наличием нескольких менеджеров блокировок, а также сохранение в системе определенной степени централизации, поскольку запросы на блокировку первичной копии элемента могут быть выполнены только на единственном сайте);

3. распределенный протокол двухфазной блокировки. В данном случае каждый менеджер блокировки отвечает за управление элементами данных, размещенных на его сайте. Если данные не подвергаются репликации, этот протокол функционирует аналогично протоколу двухфазной блокировки с первичными копиями. В противном случае распределенный протокол двухфазной блокировки использует особый протокол управления репликацией, получивший название “один раз считать, обновить всех” (Read-One-Write-All – ROWA). В этом случае для операций считывания может использоваться любая копия реплицируемого элемента, однако, прежде чем значение элемента можно будет обновить, должны быть заблокированы для записи все его существующие копии.

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

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

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

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

минус - в повышенной сложности алгоритма, усложнении процедур выявления взаимной блокировки, а также необходимости отправки не менее [(n + 1)/2] сообщений с запросами на установление блокировки и [(n + 1)/2] сообщений с запросами на отмену блокировки);

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

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

23. Сравните протоколы восстановления в централизованных субд.

Восстановление базы данных – это процесс возвращения базы данных в корректное состояние, утраченное в результате сбоя или отказа.

Тип процедуры, которая будет использована для восстановления базы данных, зависит от размера повреждений, которые были нанесены этой базе в результате отказа. Рассмотрим два варианта:

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

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

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

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

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

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

24. Сравните модели обеспечения безопасности в субд.

1. Первая модель основана на подсистеме полномочий (модель GRANT/REVOKE), которая наделяет одних пользователей правом избирательно и динамично задавать различные полномочия другим пользователям, а также отбирать такие полномочия в случае необходимости. При использовании простой модели безопасности баз данных необходимо поддерживать два функциональных принципа: проверку полномочий (санкционирование) и проверку подлинности (аутентификация). Базовая модель проверки полномочий теоретически может быть представлена матрицей безопасности, устанавливающей отношения между всеми пользователями и процессами системы, с одной стороны, и всеми объектами предметной области – с другой. Данная модель основана на избирательном управлении, т.е. пользователь обладает различными правами (привилегиями или полномочиями) при работе с разными объектами. Более того, различные пользователи обычно обладают и разными правами доступа к одному и тому же объекту. Таким образом, избирательные схемы характеризуются значительной гибкостью. Данная модель используется наиболее часто в СУБД;

2. Модель многоуровневой безопасности Белла – ЛаПадула. Модель предназначена для управления субъектами, т. е. активными процессами, запрашивающими доступ к информации, и объектами, т. е. файлами, записями, полями и другими сущностями данной информационной модели. Объекты подвергаются классификации, а каждый субъект причисляется к одному из уровней допуска (clearance) к классам объектов. Классы и уровни допуска совместно называются классами или уровнями доступа. Данная модель основана на обязательном управлении, т.е. каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. Следовательно, при таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска. Таким образом, обязательные схемы являются достаточно жесткими и статичными.

25. Управление безопасностью в базах данных (с приведением конкретных примеров).

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

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

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

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

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

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

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

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

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

Исследования безопасных распределенных баз данных впервые были проведены в проекте “Woods Hole” (США, 1982), в котором были определены две альтернативные архитектуры распределенных СУБД. Общей чертой обеих архитектур было наличие единого пользующегося доверием менеджера баз данных, который подключается к нескольким физически раздельным СУБД (рис. 19.3). Например, первая база данных содержит совершенно секретные данные, вторая – данные с грифом "секретно", третья – данные без грифа секретности. Вызовы всех операций над базами данных (в том числе и запросы) адресуются компоненту внутреннего интерфейса, который маршрутизирует их соответствующим образом. Запросы на доступ к совершенно секретным данным от обладающих соответствующим допуском процессов или пользователей направляются СУБД, управляющей данными этого уровня секретности. Если поступает многоуровневый запрос, то он декомпозируется и маршрутизируется менеджером соответствующим образом (здесь многоуровневый запрос – это запрос, относящий сразу к нескольким уровням безопасности).

В 1988 году впервые была разработана модель безопасной базы данных SeaView (Secure Data Views) с принципом многоуровневой безопасности, таким как многоэкземплярность.

Вопросы информационной безопасности в объектно-ориентированных базах данных.

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

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

• принципы многоуровневой безопасности, разработанные для реляционных баз данных, такие как многоэкземплярность и соответствие модели Белла – ЛаПадула, нашли место и в безопасных системах ООБД.

Так, объектно-ориентированным аналогом СУБД SeaView является система SODA (Secure Object-oriented DAtabase). В SODA применяются стратегии безопасности Белла – ЛаПадула и назначаются метки безопасности для классификации объектов. При этом поддерживаются два различных типа меток:

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

• метки объектов, аналогичны классификации на уровне кортежей (т. е. поддерживается единый общий класс для всего кортежа или объекта).

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

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

• распространение концепции многоуровневой безопасности на другие модели и распределенные базы данных (в частности, на ООСУБД);

• предотвращение нежелательных выводов.

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

• проникновение концепций безопасности в высокопроизводительные системы баз данных.