Всё для Учёбы — студенческий файлообменник
1 монета
doc

Студенческий документ № 000166 из ДГТУ (бывш. РИСХМ)

1. Роль и место банков данных в информационных системах

Первый этап развития управления данными - создание и использование файловых систем.

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

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

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

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

За несколько десятилетий последовательно появлялись системы, основанные на 3-х базовых моделях данных, или концептуальных моделях структурирования данных. Перечислим эти 3 модели: иерархическая, сетевая и реляционная.

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

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

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

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

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

В 1970 г. Е.Ф.Кодд опубликовал революционную по содержанию статью, которая всерьёз поколебала устоявшиеся представления о БД. Он выдвинул идею, что данные нужно связывать в соответствии с их внутренними логическими взаимоотношениями, а не физическими указателями. Т.о., пользователи смогут комбинировать данные из разных источников, если логическая информация, необходимая для такого комбинирования, присутствует в исходных данных. Это открывало новые возможности для информационно-управляющих систем, поскольку запросы к БД теперь не были ограничены физическими указателями.

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

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

Публикация работ Кодда в начале 70-х вызвала взрыв активности, как среди ученых, так и среди разработчиков программных систем по созданию реляционной СУБД. Результатом этой деятельности явилось создание во второй половине 70-х реляционных систем, которые поддерживали такие языки, как SQL (язык структурированных запросов), Quel (язык запросов) и QBE (запрос по образцу). С широким распространением персональных компьютеров в 80-е г.г. также появились реляционные БД для микрокомпьютеров. В 1986 г. SQL был принят в качестве стандарта ANSI языков реляционных БД. Этот стандарт несколько раз обновлялся.

Сегодня реляционные СУБД рассматриваются как стандарт для современных коммерческих систем работы с данными.

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

Основные понятия

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

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

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

Пользователи баз данных

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

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

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

2. База данных как информационная модель предметной области

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

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

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

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

Между объектами предметной области могут существовать связи, имеющие различный содержательный смысл. Эти связи могут быть обязательными и факультативными (необязательными). Обязательная связь ЗАМЕЩАЕТ существует, напр., между 2-мя типами объектов СОТРУДНИК и ДОЛЖНОСТЬ в предметной области "Отдел кадров организации". Каждый сотрудник зачисляется на какую-либо должность, и не может быть сотрудника, не замещающего какой- то должности. В то же время связь ЗАМЕЩАЕТСЯ между типами объектов ДОЛЖНОСТЬ и СОТРУДНИК является факультативной, т.к. могут существовать вакантные должности.

Связи между типами объектов могут быть любой размерности (арности). Наиболее часто используются бинарные связи, устанавливающие различные соответствия между объектами 2-х типов - "один к одному" (1:1), "один ко многим" (1: n), многие ко многим" (m: n).

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

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

Кроме того, известно о существовании следующих связей:

ФАКУЛЬТЕТ ??СПЕЦИАЛЬНОСТИ;

ФАКУЛЬТЕТ ?? Id*;

СПЕЦИАЛЬНОСТЬ ?? Id*;

Id* ?? ПРЕДМЕТ;

Id* ? ФАМИЛИЯ АБИТУРИЕНТА, ИМЯ, ОТЧЕСТВО, ГОД РОЖДЕНИЯ, ...;

Id* ? ПРЕДМЕТ, ОЦЕНКА;

ФАКУЛЬТЕТ ? ДЕКАН, НОМЕР ТЕЛЕФОНА;

ШИФР СПЕЦИАЛЬНОСТИ ? НОМЕР, НАЗВАНИЕ СПЕЦИАЛЬНОСТИ.

Здесь ?? - связь типа 1: n; ? - связь типа 1:1.

Теперь рассмотрим информационную модель той части предметной области, которая связана с организацией приема в вуз (рис. 1), предварительно выделив объекты "АБИТУРИЕНТ", "ФАКУЛЬТЕТ", "СПЕЦИАЛЬНОСТЬ" и "ПРЕДМЕТ" и формализовав связи.

Рис.1. Информационная модель согласно объектному анализу

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

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

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

3. Система управления базой данных (СУБД)

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

Основные функции СУБД

* управление данными во внешней памяти (на дисках);

* управление данными в оперативной памяти с использованием дискового кэша;

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

* поддержка языков БД (язык определения данных, язык манипулирования данными).

Обычно современная СУБД содержит следующие компоненты:

* ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию,

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

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

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

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

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

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

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

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

4. Многопользовательские СУБД имеют достаточно развитые средства администрирования БД.

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

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

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

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

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

Классификация СУБД

По модели данных

* Иерархические

* Сетевые

* Реляционные

* Объектно-ориентированные

* Объектно-реляционные

По степени распределённости

* Локальные СУБД (все части локальной СУБД размещаются на одном компьютере)

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

По способу доступа к БД

* Файл-серверные

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

На данный момент файл-серверная технология считается устаревшей, а её использование в крупных информационных системах - недостатком[2].

Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.

* Клиент-серверные

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

Примеры: Oracle, Firebird, Interbase, IBM DB2, Informix, MS SQL Server, Sybase Adaptive Server Enterprise, PostgreSQL, MySQL, Cache, ЛИНТЕР.

* Встраиваемые

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

Примеры: OpenEdge, SQLite, BerkeleyDB, Firebird Embedded, Microsoft SQL Server Compact, ЛИНТЕР.

Языковые средства СУБД

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

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

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

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

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

ЯОД и ЯМД не всегда синтаксически оформляются в виде самостоятельных языков. Они могут быть составными частями единого языка данных, сочетающего возможности определения данных и манипулирования данными. Имеются многочисленные примеры языков СУБД, объединяющих возможности описания данных и манипулирования данными в единых синтаксических рамках. Наиболее распространенным среди языков такого рода является язык SQL. С 1987 г. был принят ряд версий международного стандарта этого языка как языка запросов для реляционных СУБД. Действующая версия этого стандарта SQL:2003 была принята в 2003 г.

4. Администрирование базы данных

Администрирование базы данных - это функция управления базой данных (БД). Лицо ответственное за администрирование БД называется "Администратор базы данных" (АБД).

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

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

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

Основные задачи администратора базы данных

* Проектирование базы данных.

* Оптимизация производительности базы данных.

* Обеспечение и контроль доступа к базе данных.

* Обеспечение безопасности в базе данных.

* Резервирование и восстановление базы данных.

* Обеспечение целостности баз данных.

* Обеспечение перехода на новую версию СУБД.

5. Трехуровневая архитектура СУБД

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рис. 1:

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

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

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

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

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

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

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

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

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

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

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

Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области.

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

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

Модель "сущность-связь"

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

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

Рис. 1. Пример определения сущности в модели ER

Между сущностями могут быть установлены связи - бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности. Например, если у нас есть связь между сущностью "Студент" и сущностью "Преподаватель" и эта связь - руководство дипломными проектами, то каждый студент имеет только одного руководителя, но один и тот же преподаватель может руководить множеством студентов-дипломников. Поэтому это будет связь "один-ко-многим" (1:М), один со стороны "Преподаватель" и многие со стороны "Студент" (см. рис. 2).

Рис. 2. Пример отношения "один-ко-многим" при связывании сущностей "Студент" и "Преподаватель"

В разных нотациях мощность связи изображается по-разному. В нашем примере мы используем нотацию CASE системы POWER DESIGNER, здесь множественность изображается путем разделения линии связи на 3. Связь имеет общее имя "Дипломное проектирование" и имеет имена ролей со стороны обеих сущностей. Со стороны студента эта роль называется "Пишет диплом под руководством", со стороны преподавателя эта связь называется "Руководит". Графическая интерпретация связи позволяет сразу прочитать смысл взаимосвязи между сущностями, она наглядна и легко интерпретируема. Связи делятся на три типа по множественности: один-к-одному (1:1), один-ко-многим (1:M), многие-ко-многим (M:M). Связь один-к-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности. Связь 1: M означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи. Связь "один-к-одному" (1:1) означает, что один экземпляр одной сущности связан только с одним экземпляром другой сущности, а связь "многие-ко-многим" (M:M) означает, что один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот, один экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Например, если мы рассмотрим связь типа "Изучает" между сущностями "Студент" и "Дисциплина", то это связь типа "многие-ко-многим" (M:M), потому что каждый студент может изучать несколько дисциплин, но и каждая дисциплина изучается множеством студентов. Такая связь изображена на рис. 3.

* Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками. Например, между двумя сущностями "Студент" и "Преподаватель" можно установить две смысловые связи, одна - рассмотренная уже ранее "Дипломное проектирование", а вторая может быть условно названа "Лекции", и она определяет, лекции каких преподавателей слушает данный студент и каким студентам данный преподаватель читает лекции. Ясно, что это связь типа многие-ко-многим. Пример этих связей приведен на рис. 3.

Рис. 3. Пример моделирования связи "многие-ко-многим"

* Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной - если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны. Обязательность связи тоже по-разному обозначается в разных нотациях. Мы снова используем нотацию POWER DESIGNER. Здесь необязательность связи обозначается пустым кружочком на конце связи, а обязательность перпендикулярной линией, перечеркивающей связь. И эта нотация имеет простую интерпретацию. Кружочек означает, что ни один экземпляр не может участвовать в этой связи. А перпендикуляр интерпретируется как то, что по крайней мере один экземпляр сущности участвует в этой связи. Рассмотрим для этого ранее приведенный пример связи "Дипломное проектирование". На нашем рисунке эта связь интерпретируется как необязательная с двух сторон. Но ведь на самом деле каждый студент, который пишет диплом, должен иметь своего руководителя дипломного проектирования, но, с другой стороны, не каждый преподаватель должен вести дипломное проектирование. Поэтому в данной смысловой постановке изображение этой связи изменится и будет выглядеть таким, как представлено на рис. 4.

Рис. 4. Пример обязательной и необязательной связи между сущностями

Кроме того, в ER-модели допускается принцип категоризации сущностей. Это значит, что, как и в объектно-ориентированных языках программирования, вводится понятие подтипа сущности, то есть сущность может быть представлена в виде двух или более своих подтипов - сущностей, каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне. Все подтипы одной сущности рассматриваются как взаимоисключающие, и при разделении сущности на подтипы она должна быть представлена в виде полного набора взаимоисключающих подтипов. Если на уровне анализа не удается выявить полный перечень подтипов, то вводится специальный подтип, называемый условно ПРОЧИЕ, который в дальнейшем может быть уточнен. В реальных системах бывает достаточно ввести подтипизацию на двух-трех уровнях.

Сущность, на основе которой строятся подтипы, называется супертипом. Любой экземпляр супертипа должен относиться к конкретному подтипу. Для графического изображения принципа категоризации или типизации сущности вводится специальный графический элемент, называемый узел-дискриминатор, в нотации POWER DESIGNER он изображается в виде полукруга, выпуклой стороной обращенного к суперсущности. Эта сторона соединяется направленной стрелкой с суперсущностью, а к диаметру этого круга стрелками подсоединяются подтипы данной сущности (см. рис. 5).

Рис. 5. Диаграмма подтипов сущности ТЕСТ

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

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

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

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

Между сущностями "Книги" и "Экземпляры" существует связь "один-ко-многим" (1:М), обязательная с двух сторон. Чем определяется данный тип связи? Мы можем предположить, что каждая книга может присутствовать в библиотеке в нескольких экземплярах, поэтому связь "один-ко-многим". При этом если в библиотеке нет ни одного экземпляра данной книги, то мы не будем хранить ее описание, поэтому если книга описана в сущности "Книги", то по крайней мере один экземпляр этой книги присутствует в библиотеке. Это означает, что со стороны книги связь обязательная. Что касается сущности "Экземпляры", то не может существовать в библиотеке ни одного экземпляра, который бы не относился к конкретной книге, поэтому и со стороны "Экземпляры" связь тоже обязательная.

Теперь нам необходимо определить, как в нашей системе будет представлен читатель. Естественно предложить ввести для этого сущность "Читатели", каждый экземпляр которой будет соответствовать конкретному читателю. В библиотеке каждому читателю присваивается уникальный номер читательского билета, который будет однозначно идентифицировать нашего читателя. Номер читательского билета будет ключевым атрибутом сущности "Читатели". Кроме того, в сущности "Читатели" должны присутствовать дополнительные атрибуты, которые требуются для решения поставленных задач, этими атрибутами будут: "Фамилия Имя Отчество", "Адрес читателя", "Телефон домашний" и "Телефон рабочий". Почему мы ввели два отдельных атрибута под телефоны? Потому что надо в разное время звонить по этим телефонам, чтобы застать читателя, поэтому администрации библиотеки будет важно знать, к какому типу относится данный телефон. В описании нашей предметной области существует ограничение на возраст наших читателей, поэтому в сущности "Читатели" надо ввести обязательный атрибут "Дата рождения", который позволит нам контролировать возраст наших читателей.

Из описания предметной области мы знаем, что каждый читатель может держать на руках несколько экземпляров книг. Для отражения этой ситуации нам надо провести связь между сущностями "Читатели" и "Экземпляры". А почему не между сущностями "Читатели" и "Книги"? Потому что читатель берет из библиотеки конкретный экземпляр конкретной книги, а не просто книгу. А как же узнать, какая книга у данного читателя? А это можно будет узнать по дополнительной связи между сущностями "Экземпляры" и "Книги", и эта связь каждому экземпляру ставит в соответствие одну книгу, поэтому мы в любой момент можем однозначно определить, какие книги находятся на руках у читателя, хотя связываем с читателем только инвентарные номера взятых книг. Между сущностями "Читатели" и "Экземпляры" установлена связь "один-ко-многим", и при этом она не обязательная с двух сторон. Читатель в данный момент может не держать ни одной книги на руках, а с другой стороны, данный экземпляр книги может не находиться ни у одного читателя, а просто стоять на полке в библиотеке.

Теперь нам надо отразить последнюю сущность, которая связана с системным каталогом. Системный каталог содержит перечень всех областей знаний, сведения по которым содержатся в библиотечных книгах. Мы можем вспомнить системный каталог в библиотеке, с которого мы обычно начинаем поиск нужных нам книг, если мы не знаем их авторов и названий. Название области знаний может быть длинным и состоять из нескольких слов, поэтому для моделирования системного каталога мы введем сущность "Системный каталог" с двумя атрибутами: "Код области знаний" и "Название области знаний". Атрибут "Код области знаний" будет ключевым атрибутом сущности.

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

Инфологическая модель предметной области "Библиотека" представлена на рис. 6.

Рис. 6. Инфологическая модель "Библиотека"

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

7. Иерархическая и сетевая модели данных

Иерархическая модель данных

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

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

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

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

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

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

Рис. 1. Пример иерархических связей между сегментами

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

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

* в каждой физической БД существует один корневой сегмент, то есть сегмент, у которого нет логически исходного (родительского) типа сегмента;

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

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

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

Рис. 2. Пример структуры иерархического дерева

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

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

На рис. 3 представлены 2 экземпляра иерархического дерева соответствующей структуры.

Рис. 3. Пример двух экземпляров данного дерева

Экземпляры-потомки одного типа, связанные с одним экземпляром сегмента-предка, называют "близнецами". Так, для нашего примера экземпляры b1, b2 и b3 являются "близнецами", но экземпляр b4 подчинен другому экземпляру родительского сегмента, и он не является "близнецом" по отношению к экземплярам b1, b2 и b3. Набор всех экземпляров сегментов, подчиненных одному экземпляру корневого сегмента, называется физической записью. Количество экземпляров-потомков может быть разным для разных экземпляров родительских сегментов, поэтому в общем случае физические записи имеют разную длину. Так, используя принцип линейной записи иерархических графов, пример на рис. 3 можно представить в виде двух записей:

а1 b1 b2 b3 c1 d1 d2 e1 a2 b4 b5 c2 c3 d3 d4 e2 e3 e4 Запись 1 Запись 2 Как видно из нашего примера, физические записи в иерархической модели различаются по длине и структуре.

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

Сетевая модель данных

Базовыми объектами модели являются:

* элемент данных;

* агрегат данных;

* запись;

* набор данных.

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

Агрегат данных соответствует следующему уровню обобщения в модели. В модели определены агрегаты двух типов: агрегат типа вектор и агрегат типа повторяющаяся группа.

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

Адрес Город Улица дом квартира Агрегат типа повторяющаяся группа соответствует совокупности векторов данных. Например, агрегат Зарплата соответствует типу повторяющаяся группа с числом повторений 12.

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

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

Рис. 4.

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

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

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

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

Преподаватель Группа День недели № пары Аудитория Дисциплина Иванов 4306 Понедельник 1 22-13 КИД Иванов 4307 Понедельник 2 22-13 КИД Карпова 4307 Вторник 2 22-14 БЗ и ЭС Карпова 4309 Вторник 4 22-14 БЗ и ЭС Карпова 4305 Вторник 1 22-14 БД Смирнов 4306 Вторник 3 23-07 ГВП Смирнов 4309 Вторник 4 23-07 ГВП

Рис. 5.

Экземпляров набора Ведет занятия будет 3 (по числу преподавателей), экземпляров набора Занимается у будет 4 (по числу групп). На рис. 6 представлены взаимосвязи экземпляров данных наборов.

Рис. 6. Пример взаимосвязи экземпляров двух наборов

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

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

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

Все операции манипулирования данными в сетевой модели делятся на навигационные операции и операции модификации.

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

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

8. Реляционная модель данных

Теоретической основой этой модели стала теория отношений, основу которой заложили два логика - американец Чарльз Содерс Пирс (1839-1914) и немец Эрнст Шредер (1841-1902). В руководствах по теории отношений было показано, что множество отношений замкнуто относительно некоторых специальных операций, то есть образует вместе с этими операциями абстрактную алгебру. Это важнейшее свойство отношений было использовано в реляционной модели для разработки языка манипулирования данными, связанного с исходной алгеброй. Американский математик Э. Ф. Кодд в 1970 году впервые сформулировал основные понятия и ограничения реляционной модели, ограничив набор операций в ней семью основными и одной дополнительной операцией.

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

N-арным отношением R называют подмножество декартова произведения D1? D2? ... ?Dn множеств D1, D2, ..., Dn (n > 1), необязательно различных. Исходные множества D1, D2, ..., Dn называют в модели доменами.

R D1 ? D2 ? ... ? Dn

где D1 ? D2 ? ... ?Dn- полное декартово произведение.

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

Например, имеем три домена: D1 содержит три фамилии, D2 - набор из двух учебных дисциплин и D3 - набор из трех оценок. Допустим, содержимое доменов следующее:

* D1 = {Иванов, Крылов, Степанов};

* D2 = {Теория автоматов, Базы данных};

* D3 = {3, 4, 5}

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

; ;

; ; ; ...

; ; ; Отношение R моделирует реальную ситуацию и оно может содержать, допустим, только 5 строк, которые соответствуют результатам сессии (Крылов экзамен по "Базам данных" еще не сдавал):

; ; ; ; ;

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

R Фамилия Дисциплина Оценка Иванов Теория автоматов 4 Иванов Базы данных 3 Крылов Теория автоматов 5 Степанов Теория автоматов 5 Степанов Базы данных 4 Данная таблица обладает рядом специфических свойств:

1. В таблице нет двух одинаковых строк.

2. Таблица имеет столбцы, соответствующие атрибутам отношения.

3. Каждый атрибут в отношении имеет уникальное имя.

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

Вхождение домена в отношение принято называть атрибутом. Строки отношения называются кортежами.

Количество атрибутов в отношении называется степенью, или рангом, отношения.

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

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

R1 Дисциплина Фамилия Оценка Теория автоматов Крылов 5 Теория автоматов Степанов 5 Теория автоматов Иванов 4 Базы данных Иванов 3 Базы данных Степанов 4 Любое отношение является динамической моделью некоторого реального объекта внешнего мира. Поэтому вводится понятие экземпляра отношения, которое отражает состояние данного объекта в текущий момент времени, и понятие схемы отношения, которая определяет структуру отношения.

Схемой отношения R называется перечень имен атрибутов данного отношения с указанием домена, к которому они относятся:

SR = (A1, A2, A n), Ai Di.

Если атрибуты принимают значения из одного и того же домена, то они называются ?-сравнимыми, где ? - множество допустимых операций сравнения, заданных для данного домена. Например, если домен содержит числовые данные , то для него допустимы все операции сравнения, тогда ? = {=, <>,>=,} Однако и для доменов, содержащих символьные данные, могут быть заданы не только операции сравнения по равенству и неравенству значений. Если для данного домена задано лексикографическое упорядочение, то он имеет также полный спектр операций сравнения.

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

SR1 = (A1, A2, ..., An) - схема отношения R1.

SR2 = (Bi1, Bi2,..., Bin) - схема отношения R2 после упорядочения имен атрибутов.

Тогда

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

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

Рис. 1. Связь между основным и подчиненным отношениями

PRIMARY KEY отношения Сотрудник атрибут Паспорт является FOREIGN KEY для отношения "карьера".

9. Целостность реляционных данных

Ограничения целостности

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

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

Большинство БД подчиняется очень многим специальным правилам целостности, в том смысле, что они применяются к одной конкретной БД. Например, (1) Вес деталей должен быть больше нуля, (2) Значения статуса поставщиков должны быть в диапазоне 1-100, (3) Статус поставщиков из города Красноярск должен быть равен 40.

Однако в реляционной модели есть два особых общих правила целостности, которые применяются к любой БД. То есть во 2-й части реляционной модели определяются два ограничения, которые должны выполняться в любой реляционной БД:

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

(2) ссылочная целостность (связана с внешними ключами).

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

(1) Свойством уникальности - нет двух различных кортежей в R с одинаковым значением K.

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

Любое отношение имеет по крайней мере один потенциальный ключ.

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

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

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

PS: Потенциальные ключи обеспечивают основной механизм адресации на уровне кортежей в реляционной системе. Следовательно, единственный гарантируемый системой способ точно указать на какой-нибудь кортеж - это указать значение некоторого первичного ключа. Например, S# - первичный ключ, тогда с помощью выражения S WHERE S# = 'S3' мы получим не больше одного кортежа. CITY - не первичный ключ и с помощью выражения S WHERE CITY = 'КАНСК' мы получим в общем случае количество кортежей, которое нельзя предсказать. Таким образом, первичные ключи имеют такое же фундаментальное значение для успешной работы реляционной системы, как адресация основной памяти для успешной работы компьютера.

Целостность сущностей

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

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

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

Null-значение - специальный маркер, используемый для представления отсутствующей информации (это не нули или пробелы!). Например, поставка существует, но количество товара не известно.

Null-значение обозначает тот факт, что значение неизвестно.

Внешние ключи

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

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

Это основной вид связи - один-ко-многим. Отношение, входящее в связь со стороны один, называют родительским отношением. Отношение, входящее в связь со стороны много, называется дочерним отношением.

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

Взгляните на атрибут S# (Номер поставщика) отношения SPJ (Поставка). Ясно, что значение этого атрибута допустимо только в том случае, если такое же значение существует в качестве значения первичного ключа S# отношения S (Поставщики). Например, не имеет смысла включать в SPJ поставку для поставщика S8, если в отношении S не существует поставщика S8. Таким образом, атрибут S# отношения SPJ являются примером внешнего ключа.

Определение: Пусть R2 - базовое отношение. Тогда внешний ключ FK в отношении R2 - это подмножество множества атрибутов отношения R2, такое что:

(1) существует базовое отношение R1 с первичным ключом К,

(2) каждое значение внешнего ключа FK в отношении R2 является или null-значением, или совпадает со значением первичного ключа К некоторого кортежа в отношении R1.

R1 - родительское отношение, R2 - дочернее отношение.

PS: 1. Внешний ключ, так же как и потенциальный, может быть простым и составным.

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

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

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

5. Так как внешние ключи фактически служат ссылками на кортежи в другом отношении, то эти ссылки не должны указывать на несуществующие объекты.

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

То есть если В ссылается на А, то А должно существовать.

Правила внешних ключей

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

Для каждого внешнего ключа необходимо решить 2 проблемы:

1. Что делать при попытке удалить объект ссылки внешнего ключа, напр., удалить поставщика, для которого есть поставки.

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

Возможны 2 способа решения указанных проблем:

* "ограничить" - ограничить операцию удаления или обновления до момента, когда не будет существовать соответствующих ссылок (поставок). В противном случае операция запрещается.

* "каскадировать" - каскадировать операцию удаления или обновления, удалая или обновляя также соответствующие ссылки (поставки).

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

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

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

Инфологическая модель (ER-модель) используется на ранних стадиях разработки проекта.

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

Рассмотрим правила преобразования ER-модели в реляционную.

1. Каждой сущности ставится в соответствие отношение (таблица) реляционной модели данных.

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

Рис. 1. Преобразование сущности СОТРУДНИК к отношению EMPLOYEE

3. Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).

4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).

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

6. Для отражения категоризации сущностей при переходе к реляционной модели

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

7. Дополнительно при описании отношения между типом и подтипами необходимо указать тип дискриминатора. Дискриминатор может быть взаимоисключающим (M/E, mutually exclusive ) или нет. Если установлен данный тип дискриминатора, то это значит, что один экземпляр сущности супертипа связан только с одним экземпляром сущности подтипа и для каждого экземпляра сущности супертипа существует потомок. Кроме того, необходимо указать для второго способа, наследуется ли только идентификатор супертипа в подтипы или наследуются все атрибуты супертипа.

8. Если мы зададим наследование только идентификатора, то мы получим следующее преобразование (см. рис. 3 и 4).

Рис. 3. Исходная модель взаимосвязи супертипа и подтипов

Рис. 4. Результирующая модель с наследованием только идентификатора суперсущности.

9. Разрешение связей типа "многие-ко-многим". Так как в реляционной модели данных поддерживаются между отношениями только связи типа "один-ко-многим", а в ER-модели допустимы связи "многие-ко-многим", то необходим специальный механизм преобразования, который позволит отразить множественные связи, неспецифические для реляционной модели, с помощью допустимых для нее категорий. Это делается введением специального дополнительного связующего отношения, которое связано с каждым исходным связью "один-ко-многим", атрибутами этого отношения являются первичные ключи связываемых отношений. Так, например, в схеме "Библиотека" присутствует связь такого типа между сущностью "Книги" и "Системный каталог". Для разрешения этой неспецифической связи при переходе к реляционной модели должно быть введено специальное дополнительное отношение, которое имеет всего два атрибута: ISBN (шифр книги) и KOD (код области знаний). При этом каждый из атрибутов нового отношения является внешним ключом (FOREING KEY), а вместе они образуют первичный ключ (PRIMARY KEY) новой связующей сущности. На рис. 5 представлена реляционная модель, соответствующая представленной ранее инфологической модели "Библиотека".

Рис. 5. Реляционная схема "Библиотека"

11. Реляционная алгебра

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

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

Теоретико-множественные операции реляционной алгебры

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

Пусть заданы два отношения R1 = { r1 } , R2 = { r2}, где r1 и r2 - соответственно кортежи отношений R1 и R2, то объединение

R1 R2 = { r | r R1 r R2}.

Здесь r - кортеж нового отношения, - операция логического сложения "ИЛИ".

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

R1 Шифр детали Название детали 00011073 Гайка M1 00011075 Гайка М2 00011076 Гайка М3 00011003 Болт М1 00011006 Болт М3 00013063 Шайба М1 00013066 Шайба М3 R2 Шифр детали Название детали 00011073 Гайка M1 00011076 Гайка М3 00011077 Гайка М4 00011004 Болт М2

R3 Шифр детали Название детали 00011073 Гайка M1 00011075 Гайка М2 00011076 Гайка М3 00011003 Болт М1 00011006 Болт М3 00013063 Шайба М1 00013066 Шайба М3 00011077 Гайка М4 00011004 Болт М2

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

R3 = R1 R2 ={ r | r R1 r R2 }

здесь - операция логического умножения (логическое "И").

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

R4 Шифр детали Название детали 00011073 Гайка M1 00011076 Гайка М3 00011006 Болт М3

Разностью отношений R1 и R2 называется отношение, содержащее множество кортежей, принадлежащих R1 и не принадлежащих R2:

R5 =R1 \R2 ={r | r R1 r R2}

Отношение R5 содержит перечень деталей, изготавливаемых только на участке 1, отношение R6 содержит перечень деталей, изготавливаемых только на участке 2.

R6 =R2 \ R1 ={r | r R2 r R1 }

R2 00011006 Болт М3 R5 Шифр детали Название детали 00011075 Гайка М2 00011003 Болт М1 00013063 Шайба М1 00013066 Шайба М3

R6 Шифр детали Название детали 00011077 Гайка М4 00011004 Болт М2

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

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

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

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

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

(c, q) =

Здесь n - число элементов в первом кортеже с, m - число элементов во втором кортеже q.

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

Декартовым произведением отношения R1 степени n со схемой

SR1 = (A1, A2, ... , An),

и отношения R2 степени m со схемой

SR2 = (B1, B2, ..., Bm),

называется отношение R3 степени n+m со схемой

SR3 = (A1, A2, ... , An, B1, B2, ..., Bm),

содержащее кортежи, полученные сцеплением каждого кортежа r отношения R1 с каждым кортежем q отношения R2.

То есть если R1 = { r }, R2 = { q }

R1 R2 = {(r, q) | r R1 q R2}

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

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

(R1 R2) \ (R1 \ R2) \ (R2 \ R1)

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

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

Специальные операции реляционной алгебры

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

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

* терм А ос а,

где А - имя некоторого атрибута, принимающего значения из домена D; a - константа, взятая из того же домена D, а D; oc - одна из допустимых для данного домена D операций сравнения;

* терм А ос В,

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

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

= {r | r R с(r) = "Истина"}

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

Например, выбрать из R10 детали с шифром "0011003". R12 =

R12 Шифр детали Название детали Цех 00011003 Болт М1 Цех 1 00011003 Болт М1 Цех 3

Следующей специальной операцией является операция проектирования.

Пусть R - отношение, SR = (A1, ... , An) - схема отношения R.

Обозначим через B подмножество атрибутов отношения R.

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

По определению отношений все дублирующие кортежи удаляются из результирующего отношения.

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

Например, выберем все цеха, которые изготавливают деталь "Болт М1".

Для этого нам необходимо из отношения R10 выбрать детали с заданным названием, а потом полученное отношение спроектировать на столбец "Цех". Результатом выполнения этих операций будет отношение R14:

R13 = R14 =

R13 Шифр детали Название детали Цех 00011003 Болт М1 Цех 1 00011003 Болт М1 Цех 3 R14 Цех Цех 1 Цех 3 Следующей специальной операцией реляционной алгебры является операция соединения.

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

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

Типы операций соединения:

* ? - соединение

* соединение по эквивалентности (частный случай ? - соединения)

* естественное соединение

* внешнее соединение

* полусоединение.

? - соединение определяет отношение, которое содержит кортежи из декартова произведения отношений R и Q, удовлетворяющие предикату ?. Предикат имеет вид:

R.ai ? Q.bj. Вместо ? может быть указан один из операторов сравнения (, >=, <>, =).

R Q =

Если предикат ? содержит только оператор равенства (=), то соединение называется соединением по эквивалентности.

Пример ? - соединение.

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

R15 Шифр детали Название детали Материал 00011073 Гайка M1 сталь-ст1 00011075 Гайка М2 сталь-ст2 00011076 Гайка М3 сталь-ст1 00011003 Болт М1 сталь-ст3 00011006 Болт М3 сталь-ст3 00013063 Шайба М1 сталь-ст1 00013066 Шайба М3 сталь-ст1 00011077 Гайка М4 сталь-ст2 00011004 Болт М2 сталь-ст3 00011005 Болт М5 сталь-ст3 00013062 Шайба М2 сталь-ст1 R17 Название детали Гайка M1 А отношение R16 содержит перечень цехов и шифров изготавливаемых в них деталей.

R16 Шифр детали

Цех 00011073 Цех 1 00011003

00011003 Цех 3

Цех 1

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

R17= R18=

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

Естественное соединение - проекция выборки из декартова произведения.

Пример: R4 Шифр детали Название детали 00011073 Гайка M1 00011076 Гайка М3 00011006 Болт М3 R5

Шифр детали

Цех 00011073 Цех 1 00011076

00011003 Цех 3

Цех 1 R4 R5 Шифр детали Название детали Цех 00011073 Гайка M1 Цех 1 00011076 Гайка М3 Цех 3

Внешнее соединение

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

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

Для обозначения отсутствующих значений во втором отношении используется определитель Null.

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

Полусоединение

Операция полусоединения определяет отношение, которое содержит те кортежи отношения R, которые входят в соединение отношений R и S.

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

Здесь А - набор всех атрибутов в отношении R. Это полутета-соединение. Существуют полусоединения по эквивалентности и естественное полусоединение.

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

Пусть отношение R определено на множестве атрибутов A, а отношение S - на множестве атрибутов В, причем В А. Пусть С=А - В, т.е. С является множеством атрибутов отношения R, которые не являются атрибутами отношения S. Тогда результатом деления R ? S является набор кортежей отношения R, определенных на множестве атрибутов C, которые соответствуют комбинации всех кортежей отношения S.

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

Пример.

Пусть делимое - отношение D1, содержащее номера поставщиков (SN) и номера поставляемых ими деталей (PN). Делители - отношения DOR, представленные ниже:

SN PN S1 P1 S1 P2 S1 P3 S1 P4 S1 P5 S1 P6 S2 P1 S2 P2 S3 P2 S4 P2 S4 P4 S4 P5 D1

DOR DORDOR

PN P1 P4 PN P1

PN P1 P2 P3 P4 P5 P6

Результат деления D1 ? DOR:

SN S1 S4 SN S1 SN S1 S2

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

12. Реляционное исчисление

Введение

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

Алгебра и исчисление эквивалентны в том смысле, что каждому выражению в исчислении соответствует эквивалентное выражение в алгебре и наоборот, т.е. между ними существует взаимно-однозначное соответствие.

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

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

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

Для определения кортежной переменной используется оператор RANGE. Например, для того чтобы определить переменную СЛУЖАЩИЙ, областью определения которой является отношение СЛУЖАЩИЕ, нужно употребить конструкцию

RANGE OF СЛУЖАЩИЙ IS СЛУЖАЩИЕ;

Как уже говорилось, из этого определения следует, что в любой момент времени переменная СЛУЖАЩИЙ представляет некоторый кортеж отношения СЛУЖАЩИЕ. При использовании кортежных переменных в формулах можно ссылаться на значение атрибута переменной. Например, для того, чтобы сослаться на значение атрибута СЛУ_ИМЯ переменной СЛУЖАЩИЙ, нужно употребить конструкцию СЛУЖАЩИЙ.СЛУ_ИМЯ.

Правильно построенные формулы

Правильно построенная формула (ППФ) служит для выражения условий, накладываемых на кортежные переменные.

Простые условия

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

СЛУЖАЩИЙ.СЛУ_НОМ = 2934 и

СЛУЖАЩИЙ.СЛУ_НОМ = ПРОЕКТ.ПРОЕКТ_РУК

являются простыми условиями.

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

Более сложные варианты ППФ строятся с помощью логических связок NOT, AND, OR и IF ... THEN с учетом обычных приоритетов операций (NOT > AND > OR) и возможности расстановки скобок. Так, если form - ППФ, а comp - простое сравнение, то NOT form, comp AND form, comp OR form и IF comp THEN form являются ППФ.

Для примеров воспользуемся отношениями СЛУЖАЩИЕ, ПРОЕКТЫ и НОМЕРА_ПРОЕКТОВ (см. рис. 1).

Рис. 1. Примерные значения отношений СЛУЖАЩИЕ, ПРОЕКТЫ и НОМЕРА_ПРОЕКТОВ

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

IF СЛУЖАЩИЙ.СЛУ_ИМЯ = 'Иванов'

THEN (СЛУЖАЩИЙ.СЛУ_ЗАРП >= 22400.00 AND СЛУЖАЩИЙ.ПРО_НОМ = 1)

Эта формула будет принимать значение true для следующих значений кортежной переменной СЛУЖАЩИЙ:

СЛУ_НОМЕР СЛУ_ИМЯ СЛУ_ЗАРП ПРО_НОМ 2934 Иванов 22400.00 1 2935 Петров 29600.00 1 2936 Сидоров 18000.00 1 2937 Федоров 20000.00 1 2938 Иванова 22000.00 1 2935 Петров 29600.00 2 2939 Сидоренко 18000.00 2 2940 Федоренко 20000.00 2 2941 Иваненко 22000.00 2 Кванторы

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

Пусть здесь и далее в этом разделе СЛУ1 и СЛУ2 представляют собой две кортежные переменные, определенные на отношении СЛУЖАЩИЕ. Тогда ППФ

EXISTS СЛУ2 (СЛУ1.СЛУ_ЗАРП > СЛУ2.СЛУ_ЗАРП)

для текущего кортежа переменной СЛУ1 принимает значение true в том и только в том случае, если во всем отношении СЛУЖАЩИЕ найдется такой кортеж (ассоциированный с переменной СЛУ2), чтобы значение его атрибута СЛУ_ЗАРП удовлетворяло внутреннему условию сравнения. Легко видеть, что эта формула принимает значение true только для тех значений кортежной переменной СЛУ1, которые соответствуют служащим, не получающим минимальную зарплату. Соответствующее множество кортежей показано на рис. 2a (для тела отношения СЛУЖАЩИЕ из рис. 1).

Рис. 2. Примеры правильно построенных формул с кванторами

Правильно построенная формула

FORALL СЛУ2 (СЛУ1.СЛУ_ЗАРП СЛУ2.СЛУ_ЗАРП)

для текущего кортежа переменной СЛУ1 принимает значение true в том и только в том случае, если для всех кортежей отношения СЛУЖАЩИЕ (связанных с переменной СЛУ2) значения атрибута СЛУ_ЗАРП удовлетворяют условию сравнения. Снова легко видеть, что формула принимает значение true только для тех значений кортежной переменной СЛУ1, которые соответствуют служащим, получающим максимальную зарплату. Соответствующее множество кортежей показано на рис. 2b.

Целевые списки и выражения реляционного исчисления

Целевой список определяет набор и имена атрибутов результирующего отношения.

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

* var.attr, где var - имя свободной переменной соответствующей ППФ, а attr - имя атрибута отношения, на котором определена переменная var;

* var, что эквивалентно наличию подсписка var.attr1, var.attr2, ..., var.attrn, где {attr1, attr2, ..., attrn} включает имена всех атрибутов определяющего отношения;

* new_name = var.attr; new_name - новое имя соответствующего атрибута результирующего отношения.

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

В качестве простого примера покажем выражение реляционного исчисления кортежей, результат которого совпадает с результатом операции СЛУЖАЩИЕ ? НОМЕРА_ПРОЕКТОВ:

RANGE OF СЛУ1, СЛУ2 IS СЛУЖАЩИЕ

НОМЕР_ПРОЕКТА range of is НОМЕРА_ПРОЕКТОВ

СЛУ1.СЛУ_НОМЕР, СЛУ1.СЛУ_ИМЯ, СЛУ1.СЛУ_ЗАРП

WHERE FORALL НОМЕР_ПРОЕКТА EXISTS СЛУ2

(СЛУ1.СЛУ_НОМЕР = СЛУ2.СЛУ_НОМЕР AND

СЛУ1.ПРО_НОМ = НОМЕРА_ПРОЕКТОВ.ПРО_НОМ)

Конечно, результатом этого выражения является отношение

СЛУ_НОМЕР СЛУ_ИМЯ СЛУ_ЗАРП 2934 Иванов 22400.00 2935 Петров 29600.00 13. Определение данных в языке SQL

SQL (Structured Query Language) - Структурированный Язык Запросов - стандартный язык запросов по работе с реляционными БД. Язык SQL появился после реляционной алгебры, и его прототип был разработан в конце 70-х годов в компании IBM Research. Он был реализован в первом прототипе реляционной СУБД фирмы IBM System R. В дальнейшем этот язык применялся во многих коммерческих СУБД и в силу своего широкого распространения постепенно стал стандартом "де-факто" для языков манипулирования данными в реляционных СУБД.

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

В конце 1992 г. был принят новый международный стандарт языка SQL, который в дальнейшим будем называть SQL/92 или SQL2. И он не лишен недостатков, но в то же время является существенно более точным и полным, чем SQL/89. В настоящий момент большинство производителей СУБД внесли изменения в свои продукты так, чтобы они в большей степени удовлетворяли стандарту SQL2.

В 1999 году появился новый стандарт, названный SQL3. Если отличия между стандартами SQL1 и SQL2 во многом были количественными, то стандарт SQL3 соответствует качественным серьезным преобразованиям. В SQL3 введены новые типы данных, при этом предполагается возможность задания сложных структурированных типов данных, которые в большей степени соответствуют объектной ориентации. Наконец, добавлен раздел, который вводит стандарты на события и триггеры, которые ранее не затрагивались в стандартах, хотя давно уже широко использовались в коммерческих СУБД. В стандарте определены возможности четкой спецификации триггеров как совокупности события и действия. В качестве действия могут выступать не только последовательность операторов SQL, но и операторы управления ходом выполнения программы. В рамках управления транзакциями произошел возврат к старой модели транзакций, допускающей точки сохранения (savepoints), и возможность указания в операторе отката ROLLBACK точек возврата позволит откатывать транзакцию не в начало, а в промежуточную ранее сохраненную точку. Такое решение повышает гибкость реализации сложных алгоритмов обработки информации.

Структура SQL

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

SQL содержит разделы, представленные в табл. 1:

Таблица 1. Операторы определения данных DDL Оператор Смысл Действие CREATE TABLE Создать таблицу Создает новую таблицу в БД DROP TABLE Удалить таблицу Удаляет таблицу из БД ALTER TABLE Изменить таблицу Изменяет структуру существующей таблицы или ограничения целостности, задаваемые для данной таблицы CREATE VIEW Создать представление Создает виртуальную таблицу, соответствующую некоторому SQL-запросу ALTER VIEW Изменить представление Изменяет ранее созданное представление DROP VIEW Удалить представление Удаляет ранее созданное представление CREATE INDEX Создать индекс Создает индекс для некоторой таблицы для обеспечения быстрого доступа по атрибутам, входящим в индекс DROP INDEX Удалить индекс Удаляет ранее созданный индекс Таблица 2. Операторы манипулирования данными Data Manipulation Lanquaqe (DML) Оператор Смысл Действие DELETE Удалить строки Удаляет одну или несколько строк, соответствующих условиям фильтрации, из базовой таблицы. Применение оператора согласуется с принципами поддержки целостности, поэтому этот оператор не всегда может быть выполнен корректно, даже если синтаксически он записан правильно INSERT Вставить строку Вставляет одну строку в базовую таблицу. Допустимы модификации оператора, при которых сразу несколько строк могут быть перенесены из одной таблицы или запроса в базовую таблицу UPDATE Обновить строку Обновляет значения одного или нескольких столбцов в одной или нескольких строках, соответствующих условиям фильтрации

Таблица 3. Язык запросов Data Query Lanquaqe (DQL) Оператор Смысл Действие SELECT Выбрать строки Оператор, заменяющий все операторы реляционной алгебры и позволяющий сформировать результирующее отношение, соответствующее запросу Таблица 4. Средства управления транзакциями Оператор Смысл Действие COMMIT Завершить транзакцию Завершить комплексную взаимосвязанную обработку информации, объединенную в транзакцию ROLLBACK Откатить транзакцию Отменить изменения, проведенные в ходе выполнения транзакции SAVEPOINT Сохранить промежуточную точку выполнения транзакции Сохранить промежуточное состояние БД, пометить его для того, чтобы можно было в дальнейшем к нему вернуться

Таблица 5. Средства администрирования данных Оператор Смысл Действие ALTER DATABASE Изменить БД Изменить набор основных объектов в базе данных, ограничений, касающихся всей базы данных ALTER DBAREA Изменить область хранения БД Изменить ранее созданную область хранения ALTER PASSWORD Изменить пароль Изменить пароль для всей базы данных CREATE DATABASE Создать БД Создать новую базу данных, определив основные параметры для нее CREATE DBAREA Создать область хранения Создать новую область хранения и сделать ее доступной для размещения данных DROP DATABASE Удалить БД Удалить существующую базу данных (только в том случае, когда вы имеете право выполнить это действие) DROP DBAREA Удалить область хранения БД Удалить существующую область хранения (если в ней на настоящий момент не располагаются активные данные) GRANT Предоставить права Предоставить права доступа на ряд действий над некоторым объектом БД REVOKE Лишить прав Лишить прав доступа к некоторому объекту или некоторым действиям над объектом

Типы данных

В языке SQL92 поддерживаются следующие типы данных:

* CHARACTER(n) или CHAR(n) - символьные строки постоянной длины в n символов. При задании данного типа под каждое значение всегда отводится n символов, и если реальное значение занимает менее, чем n символов, то СУБД автоматически дополняет недостающие символы пробелами.

* NUMERIC[(n,m)] - точные числа, здесь n - общее количество цифр в числе, m - количество цифр слева от десятичной точки.

* DECIMAL[(n,m)] - точные числа, здесь n - общее количество цифр в числе, m - количество цифр слева от десятичной точки.

* DEC[(n,m)] - то же, что и DECIMAL[(n,m)].

* INTEGER или INT - целые числа.

* SMALLINT - целые числа меньшего диапазона.

* FLOAT[(n)] - числа большой точности, хранимые в форме с плавающей точкой. Здесь n - число байтов, резервируемое под хранение одного числа. Диапазон чисел определяется конкретной реализацией.

* REAL - вещественный тип чисел, который соответствует числам с плавающей точкой, меньшей точности, чем FLOAT.

* VARCHAR(n) - строки символов переменной длины.

* BIT(n) - строка битов постоянной длины.

* BIT VARYING(n) - строка битов переменной длины.

* DATE - календарная дата.

* TIMESTAMP(точность) - дата и время.

* INTERVAL - временной интервал.

Операторы определения данных в SQL

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

определение таблицы>::=CREATE TABLE

(описание элемента таблицы> [{,}...])

::= определение ограничений таблицы>

определение столбца>::=

[][...]

::=DEFAULT { | USER | NULL } дополнительные ограничения столбца>::=NOT NULL

[ограничение уникальности столбца>]

ограничение по ссылкам столбца>

CHECK () ограничение уникальности столбца>::= UNIQUE

::=FOREIGN KEY

::= REFERENCES

()

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

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

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

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

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

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

Задание в разделе ограничений целостности столбца выражения NOT NULL приводит к неявному порождению проверочного ограничения целостности для всей таблицы "CHECK (C IS NOT NULL)" (где C - имя данного столбца). Если ограничение NOT NULL не указано и раздел умолчаний отсутствует, то неявно порождается раздел умолчаний DEFAULT NULL. Если указана спецификация уникальности, то порождается соответствующая спецификация уникальности для таблицы.

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

Если в разделе ограничений целостности указано ограничение по ссылкам данного столбца, то порождается соответствующее определение ограничения по ссылкам для таблицы: FOREIGN KEY() , что означает, что значения данного столбца должны быть взяты из соответствующего столбца родительской таблицы. Родительской таблицей в данном случае называется таблица, которая связана с данной таблицей связью "один-ко-многим" (1:М). При этом каждая строка родительской таблицы может быть связана с несколькими строками определяемой таблицы. Трансляция операторов SQL проводится в режиме интерпретации, поэтому важно, чтобы сначала была бы описана родительская таблица, а потом уже все подчиненные (дочерние) таблицы, связанные с ней. Иначе транслятор определит ссылку на неопределенный объект.

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

Попробуем написать простейший оператор создания таблицы BOOKS из базы данных "Библиотека".

При этом будем предполагать наличие следующих ограничений целостности:

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

* Название книги - последовательность символов, не более 120. Обязательно должно быть задано.

* Автор - последовательность символов, не более 30, может быть не задан.

* Соавтор - последовательность символов, не более 30, может быть не задан.

* Год издания - целое число, не менее 1960 и не более текущего года. По умолчанию ставится текущий год.

* Издательство - последовательность символов, не более 20, может отсутствовать.

* Количество страниц - целое число не менее 5 и не более 1000.

CREATE TABLE BOOKS

( ISBN varchar(14) NOT NULL PRIMARY KEY,

TITLE varchar(120) NOT NULL,

AUTOR varchar(30) NULL,

COAUTOR varchar(30) NULL,

YEAR_PUBL smallint DEFAULT Year(GetDate()) CHECK(YEAR_PUBL >= 1960 AND

YEAR_PUBL = 5 AND PAGES ::= ALTER TABLE

{ ADD определение столбца>

ALTER {SET DEFAULT

DROP DEFAULT } |

DROP {CASCADE | RESTRICT} |

ADD { | |

|

} | DROP CONSTRAINT имя условия { CASCADE |

RESTRICT} }

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

Давайте рассмотрим пример. Чаще всего применяется операция добавления столбца. Предложение определения нового столбца в операторе ALTER TABLE имеет точно такой же синтаксис, как и в операторе создания таблицы. Добавим столбец EDUCATION (образование), содержащий символьный тип данных, с заданным перечнем значений ("начальное", "среднее", "неоконченное высшее", "высшее") в таблицу READERS.

ALTER TABLE READERS

ADD EDUCATION varchar (30) DEFAULT NULL

CHECK (EDUCATION IS NULL OR

EDUCATION= "начальное" OR

EDUCATION= "среднее " OR EDUCATION= "неоконченное высшее" OR

EDUCATION= "высшее" )

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

14. Обработка данных в SQL

Оператор выбора SELECT

Язык запросов (Data Query Language) в SQL состоит из единственного оператора SELECT. Этот единственный оператор поиска реализует все операции реляционной алгебры. Как просто, всего один оператор. Однако писать запросы на языке SQL (грамотные запросы) сначала совсем не просто. Надо учиться, так же как надо учиться решать математические задачки или составлять алгоритмы для решения непростых комбинаторных задач. Один и тот же запрос может быть реализован несколькими способами, и, будучи все правильными, они, тем не менее, могут существенно отличаться по времени исполнения, и это особенно важно для больших баз данных.

Синтаксис оператора SELECT имеет следующий вид:

SELECT[ALL|DISTINCT](|*)

FROM

[WHERE ] [GROUP BY ]

[HAVING ] [ORDER BY ]

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

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

В разделе FROM задается перечень исходных отношений (таблиц) запроса.

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

В разделе GROUP BY задается список полей группировки.

В разделе HAVING задаются предикаты-условия, накладываемые на каждую группу.

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

В выражении условий раздела WHERE могут быть использованы следующие предикаты:

* Предикаты сравнения { =, <>, >,=,IS NULL и IS NOT NULL.

Если в данном кортеже (в данной строке) указанный атрибут имеет неопределенное значение, то предикат IS NULL принимает значение "Истина" (TRUE), а предикат IS NOT NULL - "Ложь" (FALSE), в противном случае предикат IS NULL принимает значение "Ложь", а предикат IS NOT NULL принимает значение "Истина".

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

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

Рассмотрим детально первые три строки оператора SELECT:

* SELECT - ключевое слово, которое сообщает СУБД, что эта команда - запрос. Все запросы начинаются этим словом с последующим пробелом. За ним может следовать способ выборки - с удалением дубликатов (DISTINCT) или без удаления (ALL, подразумевается по умолчанию). Затем следует список перечисленных через запятую столбцов, которые выбираются запросом из таблиц, или символ '*' (звездочка) для выбора всей строки.

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

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

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

SELECT * FROM R1, R2

соответствует декартову произведению таблиц R1 и R2. Выражение

SELECT R1.A, R2.B FROM R1, R2

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

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

Рассмотрим базу данных, которая моделирует сдачу сессии в некотором учебном заведении. Пусть она состоит из трех отношений R1, R2, R3. Будем считать, что они представлены таблицами R1, R2 и R3 соответственно.

R1 = (ФИО, Дисциплина, Оценка); R2 = (ФИО, Группа); R3 = (Группы, Дисциплина)

R1 ФИО Дисциплина Оценка Петров Ф. И. Базы данных 5 Сидоров К. А. Базы данных 4 Миронов А. В. Базы данных 2 Степанова К. Е. Базы данных 2 Крылова Т. С. Базы данных 5 Сидоров К. А. Теория информации 4 Степанова К. Е. Теория информации 2 Крылова Т. С. Теория информации 5 Миронов А. В. Теория информации Null Владимиров В. А. Базы данных 5 Трофимов П. А. Сети и телекоммуникации 4 Иванова Е. А. Сети и телекоммуникации 5 Уткина Н. В. Сети и телекоммуникации 5 Владимиров В. А. Английский язык 4 Трофимов П. А. Английский язык 5 Иванова Е. А. Английский язык 3 Петров Ф. И. Английский язык 5 R2 ФИО Группа Петров Ф. И. 4906 Сидоров К. А. 4906 Миронов А. В. 4906 Крылова Т. С. 4906 Владимиров В. А. 4906 Трофимов П. А. 4807 Иванова Е. А. 4807 Уткина Н. В. 4807

R3 Группа Дисциплина 4906 Базы данных 4906 Теория информации 4906 Английский язык 4807 Английский язык 4807 Сети и телекоммуникации Приведем несколько примеров использования оператора SELECT.

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

* SELECT DISTINCT Группы FROM R3

Результат:

Группа 4906 4807 * Вывести список студентов, которые сдали экзамен по дисциплине "Базы данных" на "отлично".

* SELECT ФИО * FROM R1

* WHERE Дисциплина = "Базы данных" AND Оценка = 5

Результат:

ФИО Петров Ф. И. Крылова Т. С. * Вывести список всех студентов, которым надо сдавать экзамены с указанием названий дисциплин, по которым должны проводиться эти экзамены.

* SELECT ФИО,Дисциплина

* FROM R2,R3

* WHERE R2.Группа = R3.Группа;

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

Результат:

ФИО Дисциплина Петров Ф. И. Базы данных Сидоров К. А. Базы данных Миронов А. В. Базы данных Степанова К. Е. Базы данных Крылова Т. С. Базы данных Владимиров В. А. Базы данных Петров Ф. И. Теория информации Сидоров К. А. Теория информации Миронов А. В. Теория информации Степанова К. Е. Теория информации Крылова Т. С. Теория информации Владимиров В. А. Теория информации Петров Ф. И. Английский язык Сидоров К. А. Английский язык Миронов А. В. Английский язык Степанова К. Е. Английский язык Крылова Т. С. Английский язык Владимиров В. А. Английский язык Трофимов П. А. Сети и телекоммуникации Иванова Е. А. Сети и телекоммуникации Уткина Н. В. Сети и телекоммуникации Трофимов П. А. Английский язык Иванова Е. А. Английский язык Уткина Н. В. Английский язык * Вывести список лентяев, имеющих несколько двоек.

* SELECT DISTINCT R1.ФИО

* FROM R1 a, R1 b

* WHERE a.ФИО = b.ФИО AND

* a.Дисциплина <> b.Дисциплина AND

* a.Оценка = 5

Результат:

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

Вложенные запросы

С помощью SQL можно вкладывать запросы внутрь друг друга. Обычно внутренний запрос генерирует значение, которое проверяется в предикате внешнего запроса (в предложении WHERE или HAVING), определяющего, верно оно или нет. Совместно с подзапросом можно использовать предикат EXISTS, который возвращает истину, если вывод подзапроса не пуст.

Примеры.

PNUM PNAME PSTATUS 1 Иванов 4 2 Петров 1 3 Сидоров 2 Отношение P (Поставщики)

DNUM DNAME DSTATUS 1 Болт 3 2 Гайка 2 3 Винт 1 Отношение D (Детали)

Номер поставщика

PNUM Номер детали

DNUM Поставляемое количество

VOLUME 1 1 100 1 2 200 1 3 300 2 1 150 2 2 250 3 1 1000 Отношение PD (Поставки)

1. Получить список поставщиков, статус которых меньше максимального статуса в таблице поставщиков (сравнение с подзапросом):

SELECT *

FROM P WHERE P.STATYS

::= [ имя синонима таблицы_1] [ ...] [,[ ] ]

:: = NATURAL { INNER | FULL [OUTER] LEFT [OUTER] | RIGHT [OUTER]} JOIN

:: = CROSS JOIN

::= UNION JOIN

::= { INNER FULL [OUTER] | LEFT [OUTER] | RIGHT [OUTER]}

JOIN {ON условие | [USING (список столбцов)]}

В этих определениях INNER - означает внутреннее (естественное) соединение, LEFT - левое соединение, то есть в результат входят все строки таблицы 1, а части результирующих кортежей, для которых не было соответствующих значений в таблице 2, дополняются значениями NULL (неопределено). Ключевое слово RIGHT означает правое внешнее соединение, и в отличие от левого соединения в этом случае в результирующее отношение включаются все строки таблицы 2, а недостающие части из таблицы 1 дополняются неопределенными значениями. Ключевое слово FULL определяет полное внешнее соединение: и левое и правое. При полном внешнем соединении выполняются и правое и левое внешние соединения и в результирующее отношение включаются все строки из таблицы 1, дополненные неопределенными значениями, и все строки из таблицы 2, также дополненные неопределенными значениями.

Ключевое слово OUTER означает внешнее, но если заданы ключевые слова FULL, LEFT, RIGHT, то соединение всегда считается внешним.

Рассмотрим примеры выполнения внешних соединений. Снова вернемся к БД "Сессия". Создадим отношение, в котором будут стоять все оценки, полученные всеми студентами по всем экзаменам, которые они должны были сдавать. Если студент не сдавал данного экзамена, то вместо оценки у него будет стоять неопределенное значение. Для этого выполним последовательно естественное внутреннее соединение таблиц R2 и R3 по атрибуту Группа, а полученное отношение соединим левым внешним естественным соединением с таблицей R1, используя столбцы ФИО и Дисциплина. При этом в стандарте разрешено использовать скобочную структуру, так как результат соединения может быть одним из аргументов в части FROM оператора SELECT.

SELECT R1.ФИО, R1.Дисциплина, R1.Оценка

FROM (R2 NATURAL INNER JOIN R3 ) LEFT JOIN R1 USING ( ФИО, Дисциплина)

Результат:

ФИО Дисциплина Оценка Петров Ф. И. Базы данных 5 Сидоров К. А. Базы данных 4 Миронов А. В. Базы данных 2 Степанова К. Е. Базы данных 2 Крылова Т. С Базы данных 5 Владимиров В. А. Базы данных 5 Петров Ф. И. Теория информации Null Сидоров К. А. Теория информации 4 Миронов А. В. Теория информации Null Степанова К. Е. Теория информации 2 Крылова Т. С Теория информации 5 Операторы обновления данных

В операции обновления данных входят три операции: операция удаления записей - ей соответствует оператор DELETE, операция добавления или ввода новых записей - ей соответствует оператор INSERT и операция изменения (обновления записей) - ей соответствует оператор UPDATE. Рассмотрим каждый из операторов подробнее.

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

Оператор ввода данных INSERT имеет следующий синтаксис:

INSERT INTO имя_таблицы [() ]

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

INSERT INTO BOOKS ( ISBN,TITLE,AUTOR,COAUTOR,YEARIZD,PAGES)

VALUES ("5-88782-290-2",

"Аппаратные средства IBM PC. Энциклопедия",

"Гук М. ","",2000,816)

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

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

INSERT INTO BOOKS VALUES ("5-88782-290-2",

"Аппаратные средства IBM PC. Энциклопедия",

"Гук М.","",2000,816)

Результаты работы обоих операторов одинаковые.

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

INSERT INTO BOOKS ( ISBN,TITLE,AUTOR,YEARIZD,PAGES)

VALUES ("5-88782-290-2",

"Аппаратные средства IBM PC. Энциклопедия",

"Гук М.",2000,816)

Столбцу COAUTOR будет присвоено в этом случае значение NULL.

Какие столбцы должны быть заданы при вводе данных? Это определяется тем, как описаны эти столбцы при описании соответствующей таблицы. Если столбец или атрибут имеет признак обязательный (NOT NULL) при описании таблицы, то оператор INSERT должен обязательно содержать данные для ввода в каждую строку данного столбца. Поэтому если в таблице все столбцы обязательные, то каждая вводимая строка должна содержать полный перечень вводимых значений, а указание имен столбцов в этом случае необязательно. В противном случае, если имеется хотя бы один необязательный столбец и вы не вводите в него значений, задание списка имен столбцов - обязательно.

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

INSERT INTO EXEMPLAR (INV,ISBN,YES_NO,NUM_READER,DATE_IN, DATE_OUT)

VALUES (1872, "5-88782-290-2",NO,

344,GetDate(),DateAdd(d,GetDate(),14))

И это означает, что мы выдали экземпляр книги с инвентарным номером 1872 читателю с номером читательского билете 344, отметив, что этот экземпляр не присутствует с этого момента в библиотеке, и определили дату выдачи книги как текущую дату (функция GetDate()), а дату возврата задали двумя неделями позднее, использовав при этом функцию DateAdd (), которая позволяет к одной дате добавить заданное количество интервалов даты и тем самым получить новое значение типа "дата". Мы добавили 14 дней к текущей дате.

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

INSERT INTO READER (NAME_READER, ADRESS, HOOM_PHONE, BIRTH_DAY)

SELECT (NAME_STUDENT, ADRESS, HOOM_PHONE, BIRTH_DAY)

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

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

Синтаксис оператора DELETE следующий:

DELETE FROM имя_таблицы [WHERE условия_отбора]

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

Например, если нам надо удалить результаты прошедшей сессии, то мы можем удалить все строки из отношения R1 командой

DELETE FROM R1

Условия отбора в части WHERE имеют тот же вид, что и условия фильтрации в операторе SELECT. Эти условия определяют, какие строки из исходного отношения будут удалены. Например, если мы исключим студента Миронова А. В., то мы должны написать следующую команду:

DELETE FROM R2 WHERE ФИО = 'Миронов А.В.'

В части WHERE может находиться встроенный запрос. Например, если нам надо исключить неуспевающих студентов, то по закону о высшем образовании неуспевающим считается студент, имеющий две и более задолженности по последней сессии. Тогда нам в условиях отбора надо найти студентов, имеющих либо две или более двоек, либо два и более несданных экзамена из числа тех, которые студент сдавал. Для поиска таких горе-студентов нам надо выбрать из отношения R1 все строки с оценкой 2 или с неопределенным значением, потом надо сгруппировать полученный результат по атрибуту ФИО и, подсчитав количество строк в каждой группе, которое соответствует количеству несданных экзаменов каждым студентом, отобрать те группы, у которых количество строк не менее двух. Теперь попробуем просто записать эту сложную конструкцию на SQL и убедимся, что этот сложный запрос записывается достаточно компактно.

DELETE FROM R2 WHERE R2.ФИО IN (SELECT R1.ФИО FROM R1

WHERE Оценка = 2 OR Оценка IS NULL

GROUP BY R1.ФИО HAVING COUNT(*) >= 2

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

DELETE FROM R2 WHERE R2.ФИО IN (SELECT R1.ФИО

FROM (R2 NATURAL INNER JOIN R3 )

LEFT JOIN R1 USING ( ФИО, Дисциплина)

WHERE Оценка = 2 OR Оценка IS NULL

GROUP BY R1.ФИО

HAVING COUNT(*) >= 2

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

UPDATE имя_таблицы

SET имя_столбца = новое_значение [WHERE условие_отбора]

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

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

UPDATE R1 SET R1.Оценка = 4

WHERE R1.ФИО = "Степанова К.Е." AND R1.Дисциплина = "Базы данных"

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

R4 =

R4 Группа Курс 4906 3 4807 4 В этом случае перевод на следующий курс можно выполнить следующей операцией обновления:

UPDATE R4 SET R4.Kypc = R4.Kypc + 1

И результат будет выглядеть следующим образом:

Группа Курс 4906 4 4807 5 Операция модификации, так же как и операция удаления, может использовать сложные подзапросы. Расширим нашу базу еще одним отношением, которое будет содержать перечень студентов, получающих стипендию с указанием надбавки, которую они получают за отличную учебу. Исходно там могут находиться все студенты с указанием неопределенного размера стипендии. По мере анализа отношения R1мы можем постепенно заменять неопределенные значения на конкретные размеры стипендии. Отношение R5 имеет вид:

R5 ФИО Группа Стипендия Петров Ф. И. 4906 Сидоров К. А. 4906 Миронов А. В. 4906 Крылова Т. С. 4906 Владимиров В. А. 4906 Трофимов П. А. 4807 Иванова Е. А. 4807 Уткина Н. В. 4807 Будем считать наличие трех пятерок по сессии признаком повышенной стипендии, + 50% к основной, наличие двух пятерок из сданных экзаменов и отсутствие двоек и троек на сданных экзаменах - признаком повышения стипендии на 25%, наличие хотя бы одной двойки среди сданных экзаменов - признаком снятия или отсутствия стипендии вообще, то есть -100% надбавки. При отсутствии троек на сданных экзаменах назначим обычную стипендию с надбавкой 0%. Однако все эти изменения мы должны будем сделать отдельными операциями обновления.

Назначение повышенной стипендии:

UPDATE R5 SET R5.Стипендия = 50% WHERE R5.ФИО IN

(SELECT R1.ФИО

FROM R1 WHERE R1.Оценка = 5

GROUP BY R1.ФИО

HAVING COUNT(*) =3 )

Назначение стипендии с надбавкой 25%:

UPDATE R5 SET R5.Стипендия = 25% WHERE R5.ФИО

IN (SELECT R1.ФИО FROM R1

WHERE R1.ФИО NOT

IN (SELECT A.ФИО FROM R1 A

WHERE A.Оценка =2 )

Назначение обычной стипендии:

UPDATE R5 SET R5.Стипендия = 0%

WHERE R5.ФИО IN (SELECT R1.ФИО FROM R1

WHERE R1.Оценка >=4 AND R1.ФИО NOT IN (SELECT A.ФИО FROM R1 A

WHERE A.Оценка <= 3 OR A.Оценка IS NULL) )

Снятие стипендии:

UPDATE R5 SET R5.Стипендия = -100% WHERE R5.ФИО IN

(SELECT R1.ФИО FROM R1

WHERE R1.Оценка <= 2 OR

R1.Оценка IS NULL)

15. Функциональные зависимости. Основные определения.

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

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

* Описание концептуальной схемы БД в терминах выбранной СУБД.

* Описание внешних моделей в терминах выбранной СУБД.

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

* Описание процедур поддержки семантической целостности базы данных.

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

ОПРЕДЕЛЕНИЕ

Корректной назовем схему БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.

Процесс разработки корректной схемы реляционной БД называется логическим проектированием БД.

Проектирование схемы БД может быть выполнено двумя путями:

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

* путем синтеза, то есть путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.

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

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

* первая нормальная форма (1НФ);

* вторая нормальная форма (2НФ);

* третья нормальная форма (3НФ);

* нормальная форма Бойса-Кодда (НФБК);

* четвертая нормальная форма (4НФ);

* пятая нормальная форма, или форма проекции-соединения (5НФ).

Основные свойства нормальных форм:

* каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей;

* при переходе к следующей нормальной форме свойства предыдущих нормальных форм сохраняются.

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

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

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

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

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

Приведем ряд основных определений.

Функциональная зависимость(ФЗ) является связью типа многие - к - одному между множествами атрибутов внутри данного отношения.

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

Левая и правая части ФЗ называются детерминантом и зависимой частью соответственно.

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

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

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

Очевидным способом сокращения множества ФЗ является исключение тривиальных ФЗ.

Функциональная зависимость тривиальна, если ее правая часть является подмножеством левой части. Например, для БД поставщиков и деталей тривиальная ФЗ:

(PNUM, DNUM)?PNUM

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

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

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

16. Замыкание множества зависимостей

Некоторые ФЗ могут подразумевать другие ФЗ. Например, если для отношения R выполняются ФЗ А ? В и В ? С, то также выполняется зависимость А ? С, которая называется транзитивной функциональной зависимостью, т.е. С транзитивно через В зависит от А.

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

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

Пусть А, В, С - произвольные подмножества множества атрибутов отношения R, а запись АВ означает объединение А и В.

1. Рефлексивность: если В является подмножеством А, то А B

2. Дополнение: если АB , то AC BC

3. Транзитивность: если A B и B C , то A C.

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

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

4. Самоопределение: А ? А.

5. Декомпозиция: если А ? ВС, то А ? В и А ? С.

6. Объединение: если А ? В и А ? С, то А ? ВС.

7. Композиция: если А ? В и С ? В, то АС ? ВD.

17. Нормальные формы

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

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

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

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

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

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

* первая нормальная форма (1 НФ);

* вторая нормальная форма (2 НФ);

* третья нормальная форма (3 НФ);

* нормальная форма Бойса-Кодда (НФБК);

* четвертая нормальная форма (4 НФ);

* пятая нормальная форма (5 НФ).

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

ОПРЕДЕЛЕНИЕ

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

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

Преподаватель День недели Номер пары Название дисциплины Тип занятий Группа Петров В. И. Понед. 1 Теор. выч. проц. Лекция 4906 Вторник 1 Комп. графика Лаб. раб.. 4907 Вторник 2 Комп. графика Лаб. раб 4906 Киров В. А. Понед. 2 Теор. информ. Лекция 4906 Вторник 3 Пр-е на С++ Лаб. раб. 4907 Вторник 4 Пр-е на С++ Лаб. раб. 4906 Серов А. А. Понед. 3 Защита инф. Лекция. 4944 Среда 3 Пр-е на VB Лаб. раб 4942 Четверг 4 Пр-е на VB Лаб. раб. 4922 Здесь на пересечении одной строки и одного столбца находится целый набор элементарных значений, соответствующих набору дней, перечню пар, набору дисциплин, по которым проводит занятия один преподаватель.

Для приведения отношения "Расписание" к первой нормальной форме необходимо дополнить каждую строку фамилией преподавателя.

Преподаватель День недели Номер пары Название дисциплины Тип занятий Группа Петров В. И. Понед. 1 Теор. выч. проц. Лекция 4906 Петров В. И. Вторник 1 Комп. графика Лаб. раб.. 4907 Петров В. И. Вторник 2 Комп. графика Лаб. раб 4906 Киров В. А. Понед. 2 Теор. информ. Лекция 4906 Киров В. А. Вторник 3 Пр-е на С++ Лаб. раб. 4907 Киров В. А. Вторник 4 Пр-е на С++ Лаб. раб. 4906 Серов А. А. Понед. 3 Защита инф. Лекция. 4944 Серов А. А. Среда 3 Пр-е на VB Лаб. раб 4942 Серов А. А. Четверг 4 Пр-е на VB Лаб. раб. 4922

ОПРЕДЕЛЕНИЕ

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

Рассмотрим отношение, моделирующее сдачу студентами текущей сессии. Структура этого отношения определяется следующим набором атрибутов:

(ФИО, Номер зач.кн., Группа, Дисциплина, Оценка)

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

(ФИО, Номер.зач.кн., Группа) (Номер зач.кн., Дисциплина, Оценка)

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

А почему надо приводить отношения ко второй нормальной форме? Иначе говоря, какие аномалии или неудобства могут возникнуть, если мы оставим исходное отношение и не будем его разбивать на два? Давайте рассмотрим ситуацию, когда студент переведен из одной группы в другую. Тогда в первом случае (если мы не разбивали исходное отношение на два) мы должны найти все записи с данным студентом и в них изменить значение атрибута Группа на новое. Во втором же случае меняется только один кортеж в первом отношении. И конечно, опасность нарушения корректности (непротиворечивости содержания) БД в первом случае выше. Может получиться так, что часть кортежей поменяет значения атрибута Группа, а часть по причине сбоя в работе аппаратуры останется в старом состоянии. И тогда наша БД будет содержать записи, которые относят одного студента одновременно к разным группам. Чтобы этого не произошло, мы должны принимать дополнительные непростые меры, например организовывать процесс согласованного изменения с использованием сложного механизма транзакций, который мы будем рассматривать в лекциях, посвященных вопросам распределенного доступа к БД. Если же мы перешли ко второй нормальной форме, то мы меняем только один кортеж. Кроме того, если у нас есть студенты, которые еще не сдавали экзамены, то в исходном отношении мы вообще не можем хранить о них информацию, а во второй схеме информация о студентах и их принадлежности к конкретной группе хранится отдельно от информации, которая связана со сдачей экзаменов, и поэтому мы можем в этом случае отдельно работать со студентами и отдельно хранить и обрабатывать информацию об успеваемости и сдаче экзаменов, что в действительности и происходит.

ОПРЕДЕЛЕНИЕ

Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей.

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

(ФИО, Номер зач.кн., Группа, Факультет, Специальность, Выпускающая кафедра)

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

Номер зач.кн. ФИО

Номер зач.кн. Группа

Номер зач.кн. Факультет

Номер зач.кн. Специальность

Номер зач.кн. Выпускающая кафедра

Группа Факультет

Группа Специальность

Группа Выпускающая кафедра

Выпускающая кафедра Факультет

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

(Номер.зач.кн., ФИО, Специальность, Группа)

(Группа, Выпускающая кафедра)

(Выпускащая кафедра, Факультет)

Первичные ключи отношений выделены.

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

Полученный набор отношений находится в третьей нормальной форме.

ОПРЕДЕЛЕНИЕ

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

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

(Номер зач.кн., Идентификатор_студента, Дисциплина, Дата, Оценка)

Возможными ключами отношения являются Номер_зач.кн, Дисциплина, Дата и Идентификатор_студента, Дисциплина, Дата.

Какие функциональные зависимости у нас имеются?

Номер_зач.кн, Дисциплина, Дата Оценка;

Идентификатор_студента, Дисциплина, Дата Оценка;

Номер зач.кн. Идентификатор_студента;

Идентификатор_студента Номер зач.кн.

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

* Это отношение находится в третьей нормальной форме, потому что неполных функциональных зависимостей неключевых атрибутов от атрибутов возможного ключа здесь не присутствует и нет транзитивных зависимостей. А как же третья и четвертая зависимости, разве они не являются неполными? Нет, потому что зависимым не является неключевой атрибут, то есть атрибут, не входящий ни в один возможный ключ. Но вот под четвертую нормальную форму наше отношение не подходит, потому что у нас есть два детерминанта Номер зач.кн. и Идентификатор_студента, которые не являются возможными ключами отношения. Для приведения отношения к нормальной форме Бойса-Кодда надо разделить отношение, например, на два со следующими схемами:

* (Идентификатор_студента, Дисциплина, Дата, Оценка)

* (Номер зач.кн., Идентификатор_студента)

или наоборот:

(Номер зач.кн., Дисциплина, Дата, Оценка)

(Номер зач.кн., Идентификатор_студента)

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

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

18. Схема процесса нормализации

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

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

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

Обычно достаточно приведения набора отношений к 3НФ для получения удовлетворительной структуры данных.

19. Управление транзакциями

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

Транзакция рассматривается как некоторое неделимое действие над базой данных, осмысленное с точки зрения пользователя. В то же время это логическая единица работы системы. Рассмотрим несколько примеров. Что может быть названо транзакцией? Кем определяется, какая последовательность операций над базой данных составляет транзакцию? Конечно, однозначно именно разработчик определяет, какая последовательность операций составляет единое целое, то есть транзакцию. Разработчик приложений или хранимых процедур определяет это исходя из смысла обработки данных, именно семантика совокупности операций над базой данных, которая моделирует с точки зрения разработчика некоторую одну неразрывную работу, и составляет транзакцию. Допустим, выделим работу по вводу данных о поступивших книгах, новых книгах, которых не было раньше в библиотеке. Тогда эту операцию можно разбить на две последовательные: сначала ввод данных о книге - это новая строка в таблице BOOKS, а потом ввод данных обо всех экземплярах новой книги - это ввод набора новых строк в таблицу EXEMPLAR в количестве, равном количеству поступивших экземпляров книги. Если эта последовательность работ будет прервана, то наша база данных не будет соответствовать реальному объекту, поэтому желательно выполнять ее как единую работу над базой данных.

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

* ввод нового заказа со всеми реквизитами заказчика;

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

* подсчет стоимости заказа с формированием платежного документа типа выставляемого счета к оплате;

* включение нового заказа в производство.

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

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

Свойства транзакций. Способы завершения транзакций

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

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

Плоские, или традиционные, транзакции, характеризуются четырьмя классическими свойствами: атомарности, согласованности, изолированности, долговечности (прочности) - ACID (Atomicity, Consistency, Isolation, Durability). Иногда традиционные транзакции называют ACID-транзакциями. Упомянутые выше свойства означают следующее:

* Свойство атомарности (Atomicity) выражается в том, что транзакция должна быть выполнена в целом или не выполнена вовсе.

* Свойство согласованности (Consistency) гарантирует, что по мере выполнения транзакций данные переходят из одного согласованного состояния в другое - транзакция не разрушает взаимной согласованности данных.

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

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

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

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

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

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

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

В стандарте ANSI/ISO SQL определены модель транзакций и функции операторов COMMIT и ROLLBACK. Стандарт определяет, что транзакция начинается с первого SQL-оператора, инициируемого пользователем или содержащегося в программе, изменяющего текущее состояние базы данных. Все последующие SQL-операторы составляют тело транзакции. Транзакция завершается одним из четырех возможных путей (рис. 1):

Рис. 1. Модель транзакций ANSI/ISO

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

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

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

4. ошибочное завершение программы прерывает транзакцию (как будто был использован оператор ROLLBACK).

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

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

* Оператор BEGIN TRANSACTION сообщает о начале транзакции. В отличие от модели в стандарте ANSI/ISO, где начало транзакции неявно задается первым оператором модификации данных, в модели SYBASE начало транзакции задается явно с помощью оператора начала транзакции.

* Оператор COMMIT TRANSACTION сообщает об успешном завершении транзакции. Он эквивалентен оператору COMMIT в модели стандарта ANSI/ISO. Этот оператор, как и оператор COMMIT, фиксирует все изменения, которые производились в БД в процессе выполнения транзакции.

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

* Оператор ROLLBACK имеет две модификации. Если этот оператор используется без дополнительного параметра, то он интерпретируется как оператор отката всей транзакции, то есть в этом случае он эквивалентен оператору отката ROLLBACK в модели ANSI/ISO. Если же оператор отката имеет параметр и записан в виде ROLLBACK B, то он интерпретируется как оператор частичного отката транзакции в точку сохранения B.

Показать полностью… https://vk.com/doc113709407_437609508
Рекомендуемые документы в приложении