Банки данных, лекции

Содержание курса

Тема 1. Определение и типология банков данных

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

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

1. Условия предоставления услуг. В соответствии с этим критерием различают бесплатные и платные БнД. Последние, в свою очередь, делятся на бесприбыльные (самоокупаемые) и коммерческие.

2. Обрабатываемая информация. Так называемые OLIP-системы (On-Line Transaction Processing) предназначены для реализации сравнительно простых запросов к хранимым данным. Напротив, в OLAP-системах (On-Line Analytical Processing) предусмотрены возможности проведения сложных аналитических вычислений.

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

4. Охват. Под охватом понимается классификация БнД по территориальному, временному, ведомственному и тематическому признакам.

5. Характер взаимодействия с пользователем. В пассивных БнД сам пользователь определяет характер своего взаимодействия с БнД. Активные БнД могут при необходимости сами менять свое “поведение”.

6. Форма собственности. БнД могут быть государственными, частными и личными.

К БнД всегда предъявляются следующие общие требования, которые заключаются в следующем:

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

- многократное использование данных – различные пользователи могут использовать одни и те же данные по-разному;

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

- быстрая обработка запросов к данным;

- обеспечение контроля целостности данных;

- возможность восстановления данных после сбоев.

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

В настоящее время существует стандарт ANSI (American National Standards Institute), в соответствии с которым имеется три уровня представления данных – физический (внутренний) уровень, концептуальный уровень и уровень внешних моделей.

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

Концептуальный уровень является наиболее общим. На этом уровне отражается обобщенная модель предметной области.

Уровень внешних моделей является отражает особенности видения данных отдельными приложениями. При этом каждое приложение имеет доступ только к тем данным, которые ему необходимы.

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

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

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

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

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

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

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

2. По характеру организации данных БД могут быть неструктурированными, частично-структурированными и структурированными.

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

3. По типу хранимой информации БД делятся на документальные, фактографические и лексикографические.

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

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

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

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

Персональные БД предназначены для одного конкретного пользователя. Распределенные БД предполагают возможность одновременного обращения к данным со стороны множества пользователей.

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

СУБД так же как и БД делятся на ряд категорий.

1. По языкам общения СУБД делятся на открытые и замкнутые.

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

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

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

3. В зависимости от физического расположения различают локальные и сетевые СУБД.

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

Сетевые СУБД делятся на файл-серверные, клиент-серверные и распределенные.

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

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

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

4. По выполняемым функциям СУБД делятся на информационные и операционные.

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

5. В зависимости от сферы использования различают универсальные и специализированные СУБД.

6. По мощности СУБД делятся на настольные и корпоративные.

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

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

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

1. Языки описания данных (ЯОД). В эту группу языков входят языки описания схем и подсхем данных, языки описания хранимых данных, языки описания внешних данных.

2. Языки манипулирования данными (ЯМД). Эти языки в свою очередь делятся на процедурные и непроцедурные. При использовании процедурных данных пользователь сам программно разрабатывает способ, которые обеспечивает нужный для него результат. Непроцедурные языки являются декларативными.

3. Языки запросов (ЯЗ). К языкам запросов относятся языки, непосредственно имеющие только лишь соответствующие возможности, а также комплексные языки запросов, которые имеют еще и возможности обновления данных.

Часто бывает, что для одной и той же цели можно использовать языки различных типов. Такими языками являются, в частности, табличный язык запросов QBE и язык SQL.

Тема 2. Уровни и типы моделей БД

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

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

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

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

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

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

Рассмотрим теперь основные типы моделей данных.

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

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

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

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

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

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

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

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

Необходимо отметить, что в ряде нотаций может использоваться иная терминология. Так, в нотации Американской Ассоциации по базам данных DBTG (Data Base Task Group) термину “запись” соответствует термин “сегмент”, а записью называется все множество записей, которые относятся к одному экземпляру типа “дерево”.

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

Сетевая модель БД является в некотором смысле обобщением иерархической модели. Основное отличие сетевой модели от иерархической заключается в том, что в сетевой модели подчиненный тип может иметь произвольное количество родительских типов. Основными понятиями сетевой модели являются набор, агрегат, запись и элемент данных. Под элементом данных в данном случае следует подразумевать то же самое, что и в иерархической модели - минимальную единицу данных. Агрегаты данных бывают двух типов: агрегат типа вектор и агрегат типа повторяющаяся группа. Агрегат типа вектор соответствует набору элементов данных. Агрегат типа повторяющаяся группа соответствует совокупности векторов данных. Записью называется совокупность агрегатов данных. Каждая запись имеет определенный тип и состоит из совокупности экземпляров записи. Набором называется граф, связывающий два типа записи. Таким образом, набор отражает иерархическую связь между двумя типами записей. Родительский тип записи в данном наборе называется владельцем набора, а дочерний тип записи — членом того же набора. Для каких-либо любых двух типов записей может быть задано любое количество связывающих их наборов. При этом между двумя типами записей может быть определено различное количество наборов. Однако один и тот же тип записи не может быть одновременно владельцем и членом набора.

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

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

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

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

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

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

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

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

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

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

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

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

Инкапсуляция означает возможность разграничения доступа различных программ, приложений, методов и функций (в более широком смысле и доступа различных категорий пользователей) к различным свойствам объектов данных. В контексте термина “инкапсуляция” часто используется понятие видимости – степень доступности отдельных свойств объекта. В современных объектно-ориентированных системах программирования (таких как Delphi или С++ Builder) имеются следующие уровни инкапсуляции (видимости), которые принято называть разделами:

1. Разделы Public, Published и Automated – с незначительными отличительными особенностями свойства объекта, описанные как принадлежащие к данным разделам, полностью доступны.

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

3. Раздел Protected – в отличие от раздела Private свойства объекта становятся доступными наследникам владельца объекта.

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

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

Основным достоинством объектно-ориентированых моделей является возможность моделировать разнообразные сложные взаимосвязи между объектами.

Тема 3. Реляционная алгебра, реляционное исчисление

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

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

Рассмотрим сначала основные операции реляционной алгебры.

Объединением двух отношений, имеющих одинаковые схемы, называется отношение, множеством кортежей которого являются все кортежи исходных отношений.

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

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

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

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

Расширенным декартовым произведением двух отношений со степенями m и n называется отношение степени m+n, кортежи которого получаются сцеплением кортежей первого отношения с кортежами второго. Для того, чтобы получить произведение двух кортежей, необходимо, чтобы в них не было одинаковых имен атрибутов. Что же касается схем исходных отношений, то в отличие от рассмотренных ранее операций, они могут быть произвольными.

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

Теперь дадим определения специальных операций.

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

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

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

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

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

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

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

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

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

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

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

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

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

Операция реляционного сравнения используется для сравнения значений атрибутов в двух отношениях.

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

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

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

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

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

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

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

Тема 4. Построение реляционной схемы БД

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

Для математического определения отношения рассмотрим n множеств D1, D2, …, Dn, которые в реляционной модели называются доменами. Полным декартовым произведением будет называться набор всевозможных сочетаний из n элементов каждое, причем каждый из элементов берется из своего домена. Отношением будет называться подмножество полного декартова произведения – множество упорядоченных кортежей {d1D1, d2D2, …, dnDn}, где элемент di называется атрибутом отношения.

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

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

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

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

4. Все строки в таблице должны иметь одинаковую структуру.

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

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

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

Связь “один-к-одному” (1:1). При данном типе связи одному кортежу главного отношения соответствует один кортеж подчиненного отношения. В этом случае фактически оба отношения являются равноправными.

Связь “один-ко-многим” (1:M). Одному кортежу основного отношения соответствует множество кортежей подчиненного отношения.

Связь “многие-к-одному” (M:1). Нескольким кортежам основного отношения соответствует единственный кортеж подчиненного.

Связь “многие-ко-многим” (M:M). Нескольким кортежам главного отношения соответствует множество кортежей подчиненного.

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

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

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

1. Каждому кортежу главного отношения должно соответствовать ноль или более кортежей подчиненного отношения.

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

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

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

Метод нормальных форм является классическим методом при проектировании БД и основывается на фундаментальном понятии зависимости между атрибутами отношений.

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

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

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

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

Перечисленные определения позволяют дать определения нормальным формам отношений.

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

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

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

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

Для определения четвертой нормальной формы необходимо предварительно сформулировать теорему Фейджина.

Теорема Фейджина. Отношение R с атрибутами А, B и С может быть без потерь спроецировано в отношения R1 с атрибутами А и В и R2 с атрибутами А и С только в том случае, когда в исходном отношении существуют две многозначные зависимости атрибутов В и С от атрибута А.

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

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

Для определения пятой нормальной формы необходимо ввести понятие зависимости проекции-соединения (project-join зависимости). Отношение R с атрибутами X, Y, ..., Z удовлетворяет зависимости соединения X, Y, ..., Z тогда, когда оно может быть восстановлено без потерь путем соединения своих проекций на X, Y, ..., Z.

Отношение R находится в пятой нормальной форме (нормальной форме проекции-соединения PJ/NF) тогда и только тогда, когда любая зависимость соединения в этом отношении следует из существования в нем некоторого возможного ключа.

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

На практике отношения обычно нормализуются до 3НФ или НФБК. Сам процесс нормализации обычно заключается в последовательном выполнении следующих действий:

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

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

3. Удаляются зависимости атрибутов составных ключей от неключевых атрибутов.

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

Тема 5. Инфологическое моделирование

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

Основными свойствами, которым должна удовлетворять инфологическая модель БД, являются прежде всего следующие:

1. Предметная область должна быть описана адекватно и непротиворечиво.

2. Все возможные пользователи должны трактовать эту модель однозначно и легко ее воспринимать.

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

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

Первым шагом при разработке инфологической модели БД является описание объектов предметной области и связей между ними. Инфологическое моделирование направлено на отображение семантики (то есть смысла) предметной области на модель БД. На ранних этапах развития теории БД было предложено несколько семантических моделей. Все эти модели имели свои преимущества и недостатки и к настоящему моменту времени в подавляющем большинстве случаев используется так называемая модель “сущность-связь”. Эта модель называется также методом ER-диаграмм или ER-моделей (Essence – сущность, Relation - связь). Рассмотрим этот метод более подробно.

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

Зависимость между атрибутами сущностей определяет связь между ними. Связи делятся на три типа по степени связи сущностей: один-к-одному (1:1), один-ко-многим (или многие-к-одному) (1:М, М:1), многие-ко-многим (М:М). В общем случае между двумя сущностями может быть задано произвольное количество связей с различными смысловыми нагрузками. Класс принадлежности сущности может быть обязательным (О), когда в связи должен участвовать каждый экземпляр сущности, и необязательным (Н), когда не все экземпляры сущности должны участвовать в связи. Связь может быть обязательной со стороны одной сущности и необязательной со стороны другой. На практике степень связи и класс ее принадлежности всегда определяются исходя из анализа предметной области.

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

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

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

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

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

Объекты могут быть реальными или абстрактными. Объекты объединяются в классы объектов – совокупность объектов, имеющих одинаковый набор свойств. При этом ER-модель строится не для отдельных экземпляров объектов, а именно для классов объектов. В ER-модели каждому классу присваивается уникальное имя – существительное в единственном числе, дополненное при необходимости прилагательным или предлогом (ПРЕДМЕТ, ПРЕДМЕТ_ИЗУЧАЕМЫЙ). Уникальное имя объекта называется его идентификатором.

Каждый объект обладает набором свойств. В совокупности эти свойства описывают все возможные состояния объекта. Экземпляры объекта различаются как раз тем, что конкретные значения их свойств отличаются (объект СТУДЕНТ, свойства ФИО, Группа).

Если каждый объект может обладать только одним значением данного свойства в каждый момент времени (свойство Дата_Рождения), то такие свойства называются единичными. Если же одновременно у объекта имеется несколько значений свойства (свойство Изучаемый_Предмет у объекта СТУДЕНТ), то такие свойства называются множественными.

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

Есть такие свойства, которые могут одновременно присутствовать не у всех объектов данного класса (например, свойство Ученая_Степень у объекта ПРЕПОДАВАТЕЛЬ). Такие свойства называются условными.

Иногда вводится понятие составного свойства. Например, свойство Адрес может состоять из составных частей Город, Улица, Дом и т. д.

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

Составной объект используется для отображения “целое-часть” (ГРУППА-СТУДЕНТ).

Обобщенный объект используется для отображения связи “род-вид” между разными объектами предметной области. Например, для некоторого предприятия обобщенный объект СОТРУДНИК (родовой объект) составляют объекты ДИРЕКТОР, БУХГАЛТЕР. МЕНЕДЖЕР и т. д., (видовые объекты) которые называются категориями обобщенного объекта). Здесь впервые встречается понятие наследования свойств, поскольку все видовые объекты должны обладать всеми свойствами родового объекта (наследуют его свойства), а также индивидуальными, присущими только данному видовому объекту свойствами.

Агрегированными называются такие объекты, которым соответствует некий процесс. Примером такого объекта может быть объект СЕССИЯ, который объединяет в себе такие объекты, как ДАТА_ЭКЗАМЕНА, ОЦЕНКА, ПРЕДМЕТ, СТУДЕНТ.

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

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

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

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

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

4 случай. Связь 1:М (М:1), класс принадлежности М-связной сущности обязательный. Достаточно сформировать два отношения для каждой из сущностей так же как и в случае 2. После этого ключ 1-связной сущности добавляется в качестве атрибута в отношение, соответствующее М-связной сущности, в качестве внешнего ключа.

5 случай. Связь 1:М (М:1), класс принадлежности М-связной сущности необязательный. Здесь по тому же принципу, как и в случае 3, необходимо сформировать три отношения.

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

6 случай. Связь М:М. Вне зависимости от классов принадлежности каждой из сущностей формируется три отношения таким же образом как и в случаях 3 и 5.

В настоящее время существует целый ряд автоматизированных средств проектирования ER-моделей, называемых CASE-средствами. Среди них следует отметить Design/IDEF, Power Designer (S-Designor), Oracle, ERWin. Использование этих средств дает ряд преимуществ, к которым относятся: снижаются требования к знанию языков описания данных и конкретных СУБД; автоматически контролируются целостность и согласованность схемы описания БД; сокращается в целом время проектирования; появляется возможность автоматического тестирования проекта на разных стадиях его проектирования.

Подводя итоги, сформулируем основные этапы проектирования БД в рамках инфологического моделирования.

1. Определение сущностей и выявление связей между ними.

2. Построение ER-диаграммы с учетом всех сущностей и связей между ними.

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

4. Добавление неключевых атрибутов в отношения.

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

Тема 6. Даталогическое проектирование

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

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

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

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

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

Иногда бывают ситуации, когда для задания первичного ключа отношения приходится использовать так называемые искусственные идентификаторы объекта-сущности. Делается это в следующих случаях:

1. Наличие синонимов в предметной области. Это означает, что естественное свойство объекта, наиболее подходящее для использования его в качестве первичного ключа, не обладает свойством уникальности. Например, в списке сотрудников может быть по каким-то причинам не предусмотрено наличие таких свойств, как табельный номер или номер паспорта (эти поля, очевидно, были бы уникальными и могли бы использоваться в качестве ключей). Естественный идентификатор сотрудника – ФИО – при наличии полных однофамильцев в этом случае теряет свойство уникальности и не может быть использован в качестве ключа. Единственным выходом из ситуации становится искусственное добавление дополнительного ключевого (например, автоинкрементного) поля.

2. Второй случай рассмотрен выше – значения естественного идентификатора объекта могут меняться со временем.

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

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

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

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

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

Отдельного анализа требует задача создания отношений в случае наличия в ER-модели сложных объектов.

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

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

Другим вариантом является создание для каждой категории объекта собственного отношения с атрибутами, соответствующими наследуемым и уникальным свойствам данной категории.

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

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

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

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

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

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

1. Соответствие разработанной БД исходной предметной области. Этот критерий называется адекватностью схемы БД. Данное требование является исходным, поскольку без его выполнения говорить о чем-либо другом просто бессмысленно. Любое искажение предметной области означает, что БД является некорректной и не может использоваться.

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

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

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

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

Еще одним аспектом является возможность адаптации системы к изменениям в программном обеспечении. Это означает, что программное обеспечение должно быть стандартизированным и широко распространенным.

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

6. Объем необходимой памяти.

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

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

Тема 7. Физические модели БД

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

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

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

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

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

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

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

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

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

1. Выбор хэш-функции. Признаком “хорошей” хэш-функции является возвращение ею не более 10 синонимов.

2. Выбор стратегии разрешений коллизий.

Далеко не всегда удается найти подходящую хэш-функцию. Поэтому в таких случаях предпочтительным является использование индексных файлов. Такие файлы состоят из двух частей – индексной и основной. Физически, как правило, эти части реализуются в отдельных файлах. Индексная часть строится для основной части, в которой размещены непосредственно сами записи. Различаются файлы с плотным индексом (индексно-прямые файлы), файлы с неплотным индексом (индексно-последовательные файлы) и В-деревья. Все типы перечисленных индексных файлов предназначены для поиска записей по значению первичного ключа.

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

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

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

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

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

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

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

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

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

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

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

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

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

Каждая страница имеет вполне определенную структуру, которая включает в себя следующие элементы:

1. Заголовок страницы содержит в себе номер данной страницы, номера предыдущей и следующей страниц, а также информацию о наличии свободного пространства.

2. Содержание страницы представляет собой непосредственно сами записи данных в виде строк, каждая из которых имеет свой номер.

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

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

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

Тема 8. CASE-технологии

В последнее время широкое распространение получила технология автоматизированного проектирования информационных систем (ИС) и программных продуктов, называемая CASE-технологией (Computer Aided System Engirneering). Понятие CASE включает в себя совокупность регламентно-методических материалов, автоматизированных методов и инструментальных средств разработки, поддерживающих все этапы Жизненного Цикла Системы (ЖЦС, Bysiness System Life Cycle) начиная от первоначального формирования технических требований и спецификаций до получения и сопровождения готового программного продукта. Таким образом, понятие CASE охватывает всевозможные методические и программно-инструментальные средства, объединенные общей целью эффективной поддержки любых процессов создания прикладного программного обеспечения. Использование CASE - технологии при проектировании сложных ИС обеспечивает существенное увеличение производительности труда на всех этапах разработки и значительно сокращает затраты на сопровождение и модификацию по сравнению с проектированием ИС вручную.

Любая CASE-система включает в себя следующие компоненты: метод, нотация и средство. Под методом подразумевается методология проектирования. Нотацией называется выбранное для описания системы средство, которым является программный продукт либо компьютерный инструмент, предназначенный для поддержки и усиления методов проектирования (то есть та среда, в которой работает пользователь).

Основными функциональными компонентами CASE-систем являются следующие:

- централизованное хранилище информации о проекте (БД проекта);

- средства ввода данных в БД;

- средства анализа и редактирования информации в БД;

- средства вывода (средства документирования и верификации).

CASE-средства обеспечивают необходимый для проектирования ИС набор средств. Эти средства включают технологии и стандарты построения диаграмм БД, методы автоматического определения ошибок, а также комплекс технологий для конструирования программных систем.

CASE-средства позволяют решать ряд задач в рамках ЖЦС, к которым относятся задачи стратегического планирования проекта, моделирования ПО, изучения возможных вариантов решения проблем, определения требований к ИС, системного проектирования, программирования, тестирования, отладки программного обеспечения и измерения качества, поддержки документирования, управления процессом проектирования, сопровождения.

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

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

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

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

Методологии классифицируют также по их принадлежности различным этапам ЖЦС. В соответствии с этим они делятся на верхние, средние и нижние.

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

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

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

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

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

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

Для того, чтобы максимально согласовать ЖЦС с реальным процессом проектирования ИС, используется модель с промежуточным контролем, в которой допускается возврат к более ранним этапам. Однако в этом случае недостатком становится увеличение длительности процесса проектирования.

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

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

Цель этапа анализа - показать, как реально работает организация и как достигаются ее цели. В большинстве систем на этом этапе применяется метод структурного анализа. Структурный анализ является развитием системного анализа применительно к системам обработки информации.

Данный метод строится на наглядной диаграммной технике - для описания модели проектируемой системы используются диаграммы, схемы и структурограммы.

Чаще всего в структурном анализе применяются следующие диаграммы:

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

- ER-диаграммы - выявление основных объектов ПО, отношений между ними и их свойств;

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

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

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

На стадии реализации создается и тестируется реальная система.

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

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

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

В результате CASE-средства позволили автоматизировать разработку полного ЖЦС. Такие средства получили название Интегрированный CASE (Integrated CASE). Термин “интегрированный” означает, что различные CASE-средства, поддерживающие ЖЦС, работают согласованно, как если бы они были компонентами одной и той же среды.

Современные CASE-средства реализуют следующие группы функций:

- ведение всех видов проектных описаний для различных этапов разработки в режиме их “ручного” определения (через графические диаграммы и/или экранные формы);

- верификация проектных спецификаций;

- документирование;

- автоматическая генерация некоторых видов проектных описаний;

- спецификация интерфейса с будущими пользователями ИС в виде создания экранных форматов планируемого представления информации;

- возможность параллельной работы проектировщиков над общим проектом;

- разграничение доступа проектировщиков;

- простой и удобный интерфейс.

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

В заключение данного раздела перечислим основные используемые в настоящее время CASE-технологии.

1. Системы Design/IDEF и BPwin используются как средства анализа и предназначены для исследования всевозможных моделей предметной области.

2. Основными средствами проектирования баз данных являются такие технологии, как ERwin, S-Designоr, DataBase Designor.

3. Технологии PRO-IV, Vantage Team Builder применяются для решения задач создания различных проектных спецификаций в качестве средств анализа и проектирования.

4. Технологии Oracle, JAM, Delphi, C++ Duilder, Uniface, Power Builder, SQL являются основными средствами для разработки приложений. Эти средства могут быть предназначены как для решения задач на одном или нескольких этапах ЖЦС (такие как Erwin, S-Designor), так и являться интегрированными, поддерживающими весь ЖЦС (Vantage Team Builder, Oracle).

Среди перечисленных CASE-технологий можно выделить структурные CASE-системы (такие как Vantage Team Builder), основанные на используемых в них методах структурного анализа и программирования, объектно-ориентированные (Object Team) и комбинированные CASE-системы (Oracle).

Тема 9. Целостность БД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тип значения определяет допустимые для данного атрибута символы (числа, буквы, логические переменные и т. д.), а формат устанавливает более жесткие ограничения на возможные значения (например, формат “дата”).

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

Признак определенного значения (обязательность заполнения) не допускает пустого значения атрибута.

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

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

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

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

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

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

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

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

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

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

6. Запрет на обновления. Этот запрет может относиться к любому объекту – атрибуту, строке или таблице. Так, во многих СУБД этот запрет распространяется на значения первичных ключей.

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

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

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

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

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

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

Ряд ограничений целостности следует непосредственно из описания предметной области в рамках ER-модели.

1. Ограничение на уникальность. Ключи таблиц являются уникальными идентификаторами.

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

3. При наличии связи между сущностями могут присутствовать ограничения по связи. Тип связи и класс ее принадлежности определяет ограничение целостности на связь между сущностями.

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

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

Тема 10. Структура SQL

Широкое развитие информационных систем и связанная с этим унифицированность информационного пространства привело к необходимости создания стандартного языка, который мог бы использоваться в большом количестве различных видов компьютерных сред. Этот язык должен позволять пользователям, владеющим навыками использования одного и того же набора команд, использовать их для создания, нахождения, изменения и передачи информации, причем независимо от того, работают ли они на персональном компьютере, сетевой рабочей станции, или на универсальной ЭВМ. Таким стандартным языком стал язык структурированных запросов SQL (сокращенно от Structured Query Language). Язык SQL предназначен для манипулирования данными в реляционных БД, определения структуры БД и для управления правами доступа к данным в многопользовательской среде. В настоящее время SQL реализован практически во всех коммерческих реляционных СУБД, все фирмы провозглашают соответствие своей реализации стандарту SQL, и на самом деле реализованные диалекты SQL очень близки (хотя и не полностью совпадают).

В стандарт SQL в качестве составных частей входят язык определения данных (Data Definition Language, DDL), язык манипулирования данными (Data Manipulation Language, DML) и язык управления данными (Data Control Language, DCL).

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

Существуют статический и динамический встроенный SQL.

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

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

Язык определения данных используется для создания и изменения структуры БД и ее составных частей - таблиц, индексов, представлений (виртуальных таблиц), а также триггеров и сохраненных процедур. Основными его операторами являются операторы CREATE <DATABASE, TABLE, VIEW, INDEX, TRIGGER, PROCEDURE> (создать БД, таблицу БД, вид, индекс, триггер, процедуру), ALTER <> (изменить БД и т. д.), DROP <> (удалить БД и т. д.).

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

CREATE TABLE <имя таблицы>

(<имя столбца> <тип данных> [NOT NULL, PRIMARY KEY]

[,<имя столбца> <тип данных> [NOT NULL], [UNIQUE]]…)

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

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

ALTER TABLE <имя таблицы>

({ADD, MODIFY, DROP} <имя столбца> [<тип данных>]

[NOT NULL]

[,{ADD, MODIFY, DROP} <имя столбца> [<тип данных>]

[NOT NULL]]…)

Операнды ADD, MODIFY, DROP используются для добавления, изменения и удаления одного или нескольких столбцов.

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

DROP TABLE <имя таблицы>

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

CREATE [UNIQUE] INDEX <имя индекса>

ON <имя таблицы>

(<имя столбца> [ASC/DESC]

[,<имя столбца> [ASC/DESC]…)

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

Язык манипулирования данными используется, как это следует из его названия, для манипулирования данными в таблицах БД. Он состоит из 4 основных операторов: SELECT (выбрать), INSERT (вставить), UPDATE (обновить), DELETE (удалить).

Оператор выборки записей:

SELECT [ALL/DISTINCT]

<список данных>

FROM <список таблиц>

[WHERE <условие выборки>]

[GROUP BY <имя столбца> [, <имя столбца>…]

[HAVING <условие поиска>]

[ORDER BY <спецификация> [, <спецификация>]…]

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

В результате выполнения операции SELECT происходит выборка данных из одной или из нескольких таблиц, которые перечисляются в списке после операнда FROM. Эти данные представляются в виде таблицы, которая может иметь (ALL) или не иметь (DISTINCT) повторяющиеся строки.

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

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

Операнд HAVING используется для дополнительной селекции записей при определении списков групп. Правила его использования такие же, что и для операнда WHERE.

Для упорядочения записей применяется операнд ORDER BY.

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

Оператор изменения записей:

UPDATE <имя таблицы>

SET <имя столбца> = {<выражение>. NULL}

[, SET <имя столбца> = {<выражение>, NULL}…]

[WHERE <условие>]

Операнд SET определяет список столбцов таблицы, в которые вносятся изменения, определенные логическими или арифметическими выражениями в условии операнда WHERE. Новые значения в столбцах могут быть и пустыми (NULL).

Оператор добавления новых записей:

INSERT INTO <название таблицы>

[(<список столбцов>)]

VALUES (<список значений>)

или

INSERT INTO <название таблицы>

[(<список столбцов>)]

<предложение SELECT>

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

Оператор удаления записей:

DELETE FROM <название таблицы>

[WHERE <условие>]

Из таблицы удаляются записи, удовлетворяющие условию, определенному операндом WHERE. В случае отсутствие операнда WHERE из таблицы удаляются все записи.

Язык управления данными используется для управления правами доступа к данным и выполнением процедур в многопользовательской среде. Более точно его можно назвать “язык управления доступом”. Он состоит из двух основных операторов GRANT (дать права) и REVOKE (забрать права).

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

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

При ограничении уникальности устанавливается требование, согласно которому две строки в таблице не могут быть иметь одинаковых значений в данном столбце или совокупности столбцов. Данный тип ограничения может быть использован для определения возможных ключей таблицы, один из которых выбирается в качестве первичного (PRIMARY KEY), а остальные определяются с помощью использования оператора UNIQUE. Если первичный ключ является простым, то есть состоящим из одного атрибута, то ограничение PRIMARY KEY может быть задано или непосредственно при описании этого атрибута или в самом конце описания всей таблицы. Если же первичный ключ является составным, то возможен только второй способ. Ограничение UNIQUE устанавливается почти так же как и ограничение PRIMARY KEY с тем отличием, что оно может допускает возможность неопределенных NULL значений.

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

При задании проверочного ограничения выполняется проверка (CHECK) некоторого условия для значения данных в каждой строке таблицы – указывается предикат, который использует значения атрибутов для вычисления некоторого значения. Предикат может принимать значения TRUE, FALSE и UNKNOWN. Ограничение CHECK будет нарушено, если предикат принимает значение FALSE.

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

Для задания ограничений используется оператор CONSTRAINT. Конструкция этого оператора имеет следующий вид:

CONSTRAINT [идентификатор ограничения] <имя ограничения> <выражение>

Существуют следующие идентификаторы ограничений:

PK – ограничение на первичный ключ;

FK – ограничение на внешний ключ;

U – ограничение на уникальность значения;

DF – ограничение на значение по умолчанию;

CK – ограничение на проверочное условие CHECK.

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

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

1. Числовые типы данных. Типы данных INT и SMALLINT задают целые числа. Эти типы удобно задавать, например, для идентификаторов, количества, возраста и т. д. Типы данных NUMERIC и DECIMAL определяют десятичные числа с фиксированным количеством знаков после запятой. Их можно использовать для хранения результатов арифметических операций. Для определения данных с переменным количеством знаков после запятой используются типы REAL и FLOAT. Диапазон допустимых значений данных, определяемых этими типами, существенно больше по сравнению с десятичными числами.

2. Символьные типы данных. Типы CHAR и VARCHAR определяют строки постоянной и переменной длины соответственно. Тип данных TEXT (длинный текст) используется для хранения больших документов.

3. Денежные типы данных MONEY и SMALLMONEY позволяют хранить денежные величины с заданием при необходимости признака валюты.

4. Данные типа время/дата DATETIME и SMALLDATETIME. Такой тип данных удобно задавать при необходимости обработки временных интервалов, например, для сравнения текущей даты с какой-либо фиксированной датой.

5. Логические типы данных. Тип данных BIT определяет так называемые булевы величины, которые могут принимать два значения – Истина и Ложь.

6. Неструктурированные типы данных BINARY, VARBINARY, IMAGE применяются для определения таких данных, как графические объекты, видеоизображения и других неструктурированных байтовых потоков.

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

Тема 11. Запросы на выборку

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

Основным оператором для отбора информации из БД является оператор SELECT.

Формат этого оператора имеет следующий вид:

SELECT [DISTINCT]

{<функция агрегирования>/<выражение для вычисления значения>

[AS <имя столбца>]}

FROM {{<имя таблицы> [AS] [<имя корреляции>].[<имя столбца>.,..]}

{подзапрос [AS] [<имя корреляции>].[<имя столбца>.,..]}

<соединенная таблица>}.,..

[WHERE <условие>]

[GROUP BY {{[<имя таблицы>/<имя корреляции>]}].[<имя столбца>}.,..}]

[HAVING <условие>]

[UNION/INTERSECT/EXCEPT][ALL]

[CORRESPONDING [BY (<имя столбца>.,..)]]

<оператор SELECT>/ TABLE <имя таблицы>/<конструктор значений таблицы>

[ORDER BY {{<столбец-результат> [ASC/DESC]}.,..}

Операнды SELECT, FROM, WHERE, GROUP BY, HAVING и ORDER BY должны записываться в той последовательности, в которой они перечислены.

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

Самый простой вариант запроса соответствует случаю декартова произведения таблиц Т1 и Т2:

SELECT *

FROM T1,T2

Реализация запроса в виде:

SELECT T1.A, T2.B

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

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

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

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

Запросы могут содержать следующие функции агрегирования:

1. COUNT – функция подсчета. Имеется два варианта использования этой функции. В первом случае функция подсчитывает количество строк в таблице или в группе, если используется в операнде GROUP BY. Смысл такого использования заключается в том, что результат подсчета не зависит от того, имеются ли в столбцах значения NULL и указан ли параметр DISTINCT. Во втором случае результат зависит от значений этих параметров.

2. SUM – суммирование значений в столбце.

3. MAX, MIN, AVERAGE – вычисление максимального, минимального и среднего значений.

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

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

Если указан тип соединения LEFT JOIN (левое внешнее соединение), то в соединенную таблицу попадают все строки из первой таблицы и только те строки из второй таблицы, для которых в первой таблице имеются поля связи.

RIGHT JOIN (правое внешнее соединение) является обратным по сравнению с левым внешним соединением – в соединенной таблице имеются все строки из второй таблицы и только те строки из первой таблицы, для которых во второй таблице имеются поля связи.

Кроме перечисленные типов соединения, которые поддерживаются большинством СУБД, в ряде систем присутствуют типы соединений FULL JOIN и UNION JOIN, которые фактически являются объединением и пересечением типов LEFT JOIN и RIGHT JOIN соответственно.

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

1. Интервальный предикат используется для задания диапазона значений:

WHERE [NOT] <выражение> BERWEEN <нижнее значение выражения> AND <верхнее значение выражения>.

2. Предикат IN:

WHERE [NOT] <выражение> [NOT] IN (<список значений>/<подзапрос>)

3. Предикат проверки на неопределенное значение:

WHERE <значение> IS [NOT] NULL

4. Предикат подобия:

WHERE <выражение 1> [NOT] LIKE <выражение 2>

Кроме того, при выполнении подзапросов в условии WHERE может быть использован операнд EXIST, который проверяет возврат подзапросом каких-либо данных:

WHERE [NOT] EXIST <подзапрос>.

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

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

Операнд HAVING часто используется вместе с операндом GROUP BY, причем условие, записанное в этом операнде, имеет то же самое значение для групп, что и условие, записанное в операнде WHERE для строк. Выражение оператора HAVING должно принимать единственное значение для всей группы.

Для упорядочения данных, получаемые в результате запроса, применяется операнд ORDER BY. В списке этого операнда указываются столбцы и строки сортируются в соответствии со значениями этих столбцов. В этом списке могут быть как названия столбцов, так и номера столбцов (целые числа). При этом столбцы всегда нумеруются целым числом в случае, если столбцы являются вычисляемыми, либо получаются в результате использования операнда UNION. Если в списке операнда UNION указывается список столбцов, то в этом случае происходит упорядочение по составному ключу.

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

1. В условии WHERE могут быть заданы в явном виде правила соединения таблиц.

2. Могут быть использованы вложенные запросы.

3. Можно использовать различные конструкции с использованием операнда JOIN.

Рассмотренные выше конструкции относились к поисковым запросам. В корректирующих запросах основными операторами являются операторы INSERT, UPDATE и DELETE.

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

INSERT INTO <название таблицы>

[<название столбца>.,..]<условие запроса>/<конструктор значений>

{DEFAULT VALUES}

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

Оператор UPDATE используется для корректировки содержания таблицы:

UPDATE <название таблицы> SET <название столбца> = <новое значение> [,<название столбца > = < новое значение >…]

[WHERE <условие>]

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

Оператор DELETE используется для удаления строк из таблицы:

DELETE

FROM <название таблицы>

[WHERE <условие>]

Если условие WHERE отсутствует, то удаляются все строки таблицы.

Тема 12. Создание представлений

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

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

Оператор определения представления имеет следующий формат:

CREATE VIEW <имя представления>

[(<имя столбца> [, <имя столбца>]…)]

AS <оператор SELECT>

[WITH[CASCADED/LOCAL]CHECK OPTIONS]

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

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

Для уничтожения представления используется стандартный оператор DROP:

DROP VIEW <имя представления>

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

1. Скрытие от пользователя не предназначающейся для него информации.

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

3. Упрощение сложных запросов.

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

Последняя строка в операторе создания представления (WUTH CHECH OPTION) означает, что при создании представления должно проверяться некоторое заданное условие.

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

Горизонтальное представление используется, главным образом, для уменьшения объема реальных таблиц и имеет вид:

CREATE VIEW <имя представления>

AS

SELECT *

FROM <имя таблицы>

WHERE <имя столбца> = <значение>

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

Аналогом операции проектирования является вертикальное представление, отображающее все строки реальной таблицы и только те столбцы, которые задаются оператором SELECT:

CREATE VIEW <имя представления>

[(<имя столбца> [, <имя столбца>]…)]

AS

SELECT [(<имя столбца> [, <имя столбца>]…)]

FROM <имя таблицы>

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

CREATE VIEW <имя представления>

[(<имя столбца> [, <имя столбца>]…)]

AS

SELECT [([<функция>]<имя столбца> [, <имя столбца>]…)]

FROM <имя таблицы>

GROUP BY [(<имя столбца> [, <имя столбца>]…)]

Объединенные представления используются для представления в одной виртуальной таблице данных из нескольких таблиц БД:

CREATE VIEW <имя представления>

[(<имя столбца> [, <имя столбца>]…)]

AS

SELECT [(<имя столбца> [, <имя столбца>]…)]

FROM [(<имя таблицы> [, <имя таблицы>]…)]

[WHERE <условие>]

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

В соответствии с существующим стандартом SQL данные, содержащиеся в представлении, можно модифицировать только при выполнении следующих условий:

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

2. В корректирующем запросе не должны присутствовать данные, полученные с помощью операторов GROUP BY и HAVING.

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

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

5. В представлении не должно содержаться вложенных запросов.

6. В представлении нельзя использовать соединение таблицы “сама с собой”.

7. Ни на один столбец в выражении оператора SELECT нельзя ссылаться более одного раза.

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

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

DECLARE <имя курсора> CURSOR

FOR <подзапрос>

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

Курсор может находиться в открытом и закрытом состояниях. Открытие курсора осуществляется командой

OPEN CURSOR <имя курсора>.

При закрытии курсора используется команда

CLOSE CURSOR <имя курсора>.

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

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

Тема 13. Распределенная обработка данных

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

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

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

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

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

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

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

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

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

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

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

В дальнейшем обе эти системы будем называть распределенными системами.

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

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

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

В зависимости от количества узлов сети выделяют двухзвенную и трехзвенную архитектуру модели клиент-сервер.

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

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

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

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

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

5. Модель распределенной БД. В этой модели на мощном клиенте располагаются не только прикладные программы, но и часть самих данных.

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

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

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

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

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

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

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

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

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

Тема 14. Модели транзакций

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

В настоящее время существует ряд моделей транзакций, к основным из которых относятся плоские или классические транзакции, цепочечные (многозвенные) и вложенные транзакции. Однако ко всем моделям транзакций предъявляется общий набор требований, получивший название ACID (Atomicity – атомарность, Consistency – согласованность, Isolation – изолированность, Durability - долговечность).

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

Согласованность – при выполнении транзакции БД переходит из одного согласованного состояния в другое согласованное состояние.

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

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

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

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

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

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

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

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

- индивидуальный откат транзакции;

- потеря содержимого оперативной памяти (мягкий сбой);

- выход из строя носителя внешней пвмяти (жесткий сбой).

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

Для реализации возможности восстановления данных существует специальная структура, которая называется журналом транзакций. Основным принципом журнала транзакции является обеспечение протокола, называемого Write Ahead Log (WAL) – “пиши сначала в журнал”. Это означает, что любая запись об изменении объекта данных должна сначала попадать во внешнюю память журнала транзакций, и только потом во внешнюю память базы данных. Таким образом, если во внешней памяти базы данных содержится информация о некотором объекте, над которым уже выполнена операция модификации, то в журнале транзакций заведомо имеется соответствующая запись.

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

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

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

1. В ходе выполнения транзакции пользователь должен видеть только согласованные данные.

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

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

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

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

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

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

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

IS (Intented for Shared Lock) – по отношению к некоторому составному объекту данный тип блокировки означает намерение захватить часть этого объекта в совместном режиме. Если, например, необходимо прочитать часть кортежей из данного отношения, то это отношение вначале захватывается в режиме IS.

IX (Intented for eXclusive Lock) - по отношению к некоторому составному объекту данный тип блокировки означает намерение захватить часть этого объекта в монопольном режиме. При необходимости удаления части кортежей из данного отношения это отношение вначале захватывается в режиме IX.

SIX (Shared, Intented for eXclusive Lock) - по отношению к некоторому составному объекту данный тип блокировки означает совместный захват этого объекта с намерением впоследствии захватывать части этого объекта в монопольном режиме. Этот тип блокировки используется, если, например, выполняется просмотр записей отношения и при необходимости некоторые записи нужно удалить.

Для реализации протокола гранулированных захватов необходимо выполнение следующего условия: прежде чем устанавливается S-блокировка (или X-блокировка) на часть некоторого объекта (например, на кортеж отношения), должна быть установлена IS-блокировка (или IX-блокировка) на весь объект (например, на все отношение). Здесь вместо IS- и IX-блокировок могут быть более сильные блокировки.

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

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

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

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

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

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

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

Тема 15. Защита информации в БД

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

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

При избирательном подходе пользователи обладают различными правами (привилегиями или полномочиями) при работе с данными. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту данных. Избирательные права характеризуются значительной гибкостью.

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

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

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

Привилегии или полномочия пользователей или групп пользователей - это набор действий (операций), которые они могут выполнять над объектами БД.

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

В самом общем случае концепция обеспечения безопасности БД заключается в поддержании двух принципов – проверки полномочий и проверки подлинности.

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

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

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

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

Основными видами угроз являются следующие:

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

- случайный доступ к системным областям памяти;

- некорректная модификация данных;

- ошибочные действия пользователей;

- ошибки в прикладных программах;

- перехват данных в линиях связи;

- хищение информации (дисков или иных носителей данных).

В результате нарушения безопасности возможны следующие последствия:

- получение секретных сведений;

- сбой системы – замедление ее работы или полная остановка;

- потеря содержимого внешней памяти (жесткий сбой);

- материальный ущерб.

Исходя из этого, имеются три основные задачи защиты: защита от хищения, от потери и от сбоев и отказов системы.

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

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

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

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

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

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

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

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

Для обеспечения программно-аппаратной защиты имеются следующие способы:

1. Защита от несанкционированного доступа к данным со стороны пользователей и прикладных программ. Вопросы реализации этого способа рассмотрены выше.

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

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

4. Структурная, функциональная и информационная избыточность.

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

5. Обеспечение высокого качества используемых программно-аппаратных средств.

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

Тема 16. Настройка и администрирование СУБД

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

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

- системные аналитики;

- проектировщики структур данных;

- проектировщики процессов обработки данных;

- системные, прикладные специалисты и операторы;

- специалисты по техническому обслуживанию.

Администраторов БД можно разделить на две категории.

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

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

Основные функции администраторов ИС заключаются в следующем:

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

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

3. Задание ограничений целостности при описании структуры БД и процедур обработки БД – задание декларативных ограничений целостности, определение динамических ограничений целостности в процессе изменения информации, определение ограничений целостности, вызванных структурой БД, разработка процедур ограничения целостности при вводе и корректировке данных.

4. Выбор способа размещения файлов на диске. В большинстве случаев имеется два способа размещения файлов БД на дисках – на так называемых “чистых” дисках или в файловой структуре операционной системы. В первом случае управление данными производится средствами самих СУБД.

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

Основными достоинствами файловой системы являются следующие:

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

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

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

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

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

8. Ведение БД – определение стратегии изменения, добавления и удаления данных, разработка технологии проверки соответствия вводимых данных реальному состоянию предметной области.

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

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

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

Резервное копирование может осуществляться непосредственно во время работы с БД (on-line) или в другое время. Копирование может начаться по команде оператора или автоматически в заданное время.

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

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

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

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

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

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

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

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

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

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

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

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

Банки данных, лекции