База данных

Инфологические Даталогические Физические

Основные особенности систем, основанных на инвертированных списках

К числу наиболее известных и типичных представителей таких систем относятся Datacom/DB компании Applied Data Research, Inc. (ADR), ориентированная на компьютеры фирмы IBM, и Adabas компании Software AG.

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

Структуры данных

Манипулирование данными

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

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

Иерархические модели

Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г.

Иерархические структуры данных

Манипулирование данными

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

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

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

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

Сетевые модели

Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования (Conference on Data Systems Languages - CODASYL). Отчет DBTG был опубликован в 1971 г., а в 70-х годах появилось несколько систем, среди которых IDMS.

Сетевые структуры данных

Манипулирование данными

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

Физические модели организации баз данных

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

Модели страничной организации данных в современных БД

Этапы доступа к БД

Вопросы и упражнения для самоконтроля к главе 2

Базовые понятия реляционных баз данных

Тип данных

Домен

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

Например, домен «Имена» в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут представлять имя (в частности, такие строки не могут начинаться с мягкого знака).

Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов «Номера пропусков» и «Номера отделов» относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается.

Схема отношения, схема базы данных

Схема отношения - это именованное множество пар {имя атрибута – имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута).

Схема БД (в структурном смысле) - это набор именованных схем отношений

Кортеж, отношение, ключи

Связи в реляционных базах данных

Фундаментальные свойства отношений

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

Отсутствие кортежей-дубликатов

Отсутствие упорядоченности кортежей

Отсутствие упорядоченности атрибутов

Атомарность значений атрибутов

Характеристика реляционной модели данных

Трехзначная логика (3VL)

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

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

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

Вопросы и упражнения для самоконтроля к главе 3

История языка SQL

Структура языка SQL

Создание запроса с помощью оператора SELECT

Создание простых запросов

Агрегирование данных в запросах

Формирование запросов на основе соединения таблиц

Формирование структур вложенных запросов

Простые подзапросы

Объединение нескольких запросов в один

Синтаксис оператора SELECT

FROM .] } ] ...;

Элементы, используемые в команде SELECT:

< список выбора > - выражения, включающее имена столбцов, функции, знаки операций

<предикат>::=< выражение1 > < оператор> < выражение2> | [NOT] EXISTS< выражение2 >

< оператор> ::= > | < | >= | <= | <> | = | IN | LIKE | BETWEEN …AND | OR | AND | NOT

< выражение2 >::= < выражение1> | [ANY | SOME | ALL ] <подзапрос>

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

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

Оператор удаления данных DELETE

Оператор DELETE имеет формат:

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

Пример 4.42 Удалить все содержимое таблицы Продавцы:

DELETE FROM Продавцы;

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

Пример 4.43 Удалить продавца Аксельрода из таблицы Продавцы:

DELETE FROM Продавцы WHERE snum = 1003;

Замечание. Рекомендуется сначала выполнить оператор SELECT, имеющий такое же предложение WHERE, чтобы убедиться те ли строки будем удалять.

Оператор вставки данных INSERT

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

или

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

Пример 4.45 Добавить нового продавца:

INSERT INTO Продавцы VALUES (1009, 'Вильсон', 'Лондон', 0.12);

Замечание. Команды DML не производят никакого вывода, но СУБД должна дать некоторое подтверждение того, что данные были использованы. Имя таблицы (в нашем случае - Продавцы) должно быть предварительно определено в команде CREATE TABLE (см. п.4.5 ), а каждое значение, заданное в предложении значений VALUES, должно совпадать с типом данных столбца, в который оно вставляется.

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

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

Пример 4.46 INSERT INTO Лондон_1 SELECT * FROM Продавцы WHERE city = 'Лондон';

Здесь выбираются все значения, произведенные запросом - все строки из таблицы Продавцы со значениями city = ‘Лондон’ - и помещаются в таблицу, называемую Лондон_1. Эта таблица должна отвечать следующим условиям:

· она должна уже быть создана командой CREATE TABLE.;

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

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

Оператор UPDATE имеет формат:

где <значение>::=<столбец> |< выражение> | <константа> | <переменная>

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

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

Пример 4.47 Предположим, что продавец Мотика ушел на пенсию, и необходимо переназначить его номер новому продавцу:

UPDATE Продавцы SET sname = 'Гибсон', city = 'Бостон', comm = .10 WHERE snum = 1004;

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

Операторы определения объектов базы данных

Операторы определения таблицы

Базовые таблицы описываются в SQL с помощью предложения CREATE TABLE (создать таблицу). Рассмотрим синтаксис этого предложения:

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

Ограничение – это свойство, назначенное столбцу или таблице, которое запрещает ввод в указанный столбец (или столбцы) недопустимых значений. Основные виды ограничений: NULL, NOT NULL, DEFAULT, PRIMARY KEY, FOREIGN KEY, REFERENCES, CHECK, UNIQUE. Ограничения могут быть без имени или с именем, тогда перед ограничением вставляется слово CONSTRAINT <имя_ограничения>. Наличие имени ограничения позволяет ссылаться на него в операторе изменения таблицы, например:

ALTER TABLE Tab1 ADD CONSTRAINT col1 CHECK (col1 BETWEEN 0 AND 1);

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

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

Если в разделе ограничений целостности указано ограничение по ссылкам данного столбца (REFERENCES <спецификация>), то порождается соответствующее определение ограничения по ссылкам для таблицы:

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

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

В SQL существует также предложение ALTER TABLE (изменить таблицу), которое позволяет добавить справа к таблице новый столбец, изменить или удалить столбец, т.е. модифицировать описание таблицы.

Для построения индекса в SQL существует предложение CREATE INDEX (создать индекс), имеющее формат:CREATE [UNIQUE] INDEX <имя_индекса> ON < имя_таблицы >

(<столбец >[[ASC] | DESC] [, <столбец> [[ASC] | DESC]] ...);

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

Для удаления индекса используется предложение:

DROP INDEX <имя_индекса>;

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

Оператор определения представлений CREATE VIEW

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

где подзапрос, следующий за AS и являющийся определением данного представления, не исполняется, а просто сохраняется в каталоге;

необязательная фраза «WITH CHECK OPTION» (с опцией проверки) указывает, что для операций INSERT и UPDATE над этим представлением должна осуществляться проверка, обеспечивающая удовлетворение WHERE фразы подзапроса;

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

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

б) два или более столбцов подзапроса имеют одно и то же имя;

если же список отсутствует, то представление наследует имена столбцов из подзапроса.

Пример 4.52 Например, создадим представление Лондон_продавцы, которое может рассматриваться пользователем как новая таблица в базе данных:

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

• в списке выборки не указано ключевое слово DISTINCT;
• каждое арифметическое выражение в списке выборки представляет собой одну спецификацию столбца, и спецификация одного столбца не появляется более одного раза (не должно быть агрегатных функций и выражений);
• в разделе FROM указана только одна таблица, являющаяся либо базовой таблицей, либо модифицируемым представлением;
• в условии выборки раздела WHERE не используются подзапросы;
• отсутствуют разделы GROUP BY и HAVING.

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

Замечание. Требование WITH CHECK OPTION в определении представления имеет смысл только в случае определения модифицируемой представляемой таблицы.

Для удаления представления используется оператор:

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

Операторы контроля данных, защиты и управления данными

Операторы управления привилегиями

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

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

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

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

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

GRANT <привилегии> ON < объект> TO < субъект >

[{,<субъект >}...] [WITH GRANT OPTION];

<привилегии>::= ALL [PRIVILEGES] | <действие> [{,<действие> }...]

<действие>::= SELECT | INSERT | DELETE | UPDATE [(<список столбцов>)]

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

[(<список столбцов>)]::= <имя_столбца> [{,<имя_столбца> }...]

<субъект> ::= PUBLIC | <идентификатор_доступа_пользователя>

<привилегии> - список, состоящий из одной или нескольких привилегий, разделенных запятыми, либо фраза ALL PRIVILEGES (все привилегии); <объект> - имя и, если надо, тип объекта (база данных, таблица, представление, индекс и т.п.); <субъекты> - список, включающий один или более идентификаторов доступа, разделенных запятыми, либо специальное ключевое слово PUBLIC (общедоступный).

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

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

Пример 4. 57 GRANT SELECT, INSERT ON Порядки TO Адриан, Диана;

Если пользователь USER_1 предоставил какие-либо привилегии другому пользователю USER_2, то он может впоследствии отменить все или некоторые из этих привилегий. Отмена осуществляется с помощью предложения REVOKE (отменить), общий формат которого очень похож на формат предложения GRANT:

REVOKE <привилегии> ON < объект> FROM < субъект > [{,<субъект >}...];

Пример 4. 61 REVOKE INSERT, DELETE ON Заказчики FROM Адриан, Стефан.

Операторы управления транзакциями

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

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

Транзакция обладает четырьмя важными свойствами, известными как свойства АСИД:

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

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

• подана команда COMMIT (зафиксировать транзакцию);
• подана команда ROLLBACK (откатить транзакцию);
• произошло отсоединение пользователя от СУБД;
• произошел сбой системы.

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

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

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

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

Примерами ограничений целостности могут служить следующие утверждения:

Пример 4.62. У каждого заказчика только один продавец.

Пример 4.63. Каждый сотрудник имеет уникальный табельный номер.

Пример 4.64 Сотрудник обязан числиться в только одном отделе.

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

Как видно из этих примеров, некоторые из ограничений целостности являются ограничениями реляционной модели данных (см. гл. 3). Пример 4.63 представляет ограничение, реализующее целостность сущности. Примеры 4.62, 4.64 представляют ограничения, реализующие ссылочную целостность. Другие ограничения являются достаточно произвольными утверждениями, утверждениями связанными с правилами в конкретной предметной области (пример 4.65). Любое ограничение целостности является семантическим понятием, т.е. появляется как следствие определенных свойств объектов предметной области и/или их взаимосвязей.

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

1. Отказ выполнить "незаконную" операцию.
2. Выполнение компенсирующих действий.

Работа системы по проверке ограничений изображена на рисунке 4.1.

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

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

По способам реализации различают:

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

Рисунок 4.1 Работа системы по проверке ограничений

По времени проверки ограничения делятся на:

• немедленно проверяемые ограничения;
• ограничения с отложенной проверкой.

По области действия ограничения делятся на:

• ограничения домена;
• ограничения атрибута;
• ограничения кортежа;
• ограничения отношения;
• ограничения базы данных.

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

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

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

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

Проблемы параллельной работы транзакций

Вопросы и упражнения для самоконтроля к главе 4

Проектирование реляционных БД с использованием принципов нормализации

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

Применение семантических моделей при проектировании

Основные понятия модели Entity-Relationship

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

Определение 1. Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.

Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Примерами сущностей могут быть такие классы объектов как «Поставщик», «Сотрудник», «Накладная».

Каждая сущность в модели изображается в виде прямоугольника с наименованием (рис.5.1).

Рисунок 5.1 Пример сущности

Определение 2. Экземпляр сущности - это конкретный представитель данной сущности.

Например, представителем сущности «Сотрудник» может быть «Сотрудник Иванов».

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

Определение 3. Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.

Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными). Примерами атрибутов сущности «Сотрудник» могут быть такие атрибуты как «Табельный номер», «Фамилия», «Имя», «Отчество», «Должность», «Зарплата» и т.п.

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

Рисунок 5.2 Пример сущности с указанием атрибутов

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

Сущность может иметь несколько различных ключей.

Ключевые атрибуты изображаются на диаграмме подчеркиванием (рис.5.3).

Рисунок 5.3 Пример сущности с указанием ключа

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

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

Например, связи между сущностями могут выражаться следующими фразами – «СОТРУДНИК может иметь несколько ДЕТЕЙ», «каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ».

Графически связь изображается линией, соединяющей две сущности (рис.5.4).

Рисунок 5.4 Пример связи двух сущностей

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

Каждая связь может иметь один из следующих типов связи (рис.5.5.:

Рисунок 5.5 Графическое изображение типов связей

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

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

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

Каждая связь может иметь одну из двух модальностей связи (рис.5.6).

Рисунок 5.6 Графическое изображение модальностей связи

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

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

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

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на рис. 5.4 читается так:

Слева направо: «каждый сотрудник может иметь несколько детей».

Справа налево: «Каждый ребенок обязан принадлежать ровно одному сотруднику».

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

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

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

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

Пример разработки простой ER-модели

При разработке ER-моделей мы должны получить следующую информацию о предметной области:

1. Список сущностей предметной области.
2. Список атрибутов сущностей.
3. Описание взаимосвязей между сущностями.

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

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

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

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

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

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

Сразу возникает очевидная связь между сущностями – «покупатели могут покупать много товаров» и «товары могут продаваться многим покупателям». Первый вариант диаграммы выглядит так (рис.5.7).

Рисунок 5.7 Первый вариант диаграммы

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

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

· Каждый покупатель может получить несколько накладных.

· Каждая накладная обязана выписываться на одного покупателя.

· Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных).

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

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

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

Рисунок 5.8 Второй вариант диаграммы

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

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

· Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.

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

· Каждый склад имеет свое наименование.

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

· юридическое лицо - термин ненужный, т.к.фирма не работает с физическими лицами. Не обращаем внимания;

· наименование покупателя - явная характеристика покупателя;

· адрес - явная характеристика покупателя;

· банковские реквизиты - явная характеристика покупателя;

· наименование товара - явная характеристика товара;

· (?)цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?

· единица измерения - явная характеристика товара;

· номер накладной - явная уникальная характеристика накладной;

· дата накладной - явная характеристика накладной;

· (?)список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность;

· (?)количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто «товара», а «товара в накладной»;

· (?)цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?

· сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную;

· наименование склада - явная характеристика склада.

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

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

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

· каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную;

· каждый товар может включаться в несколько записей из списка товаров в накладной;

· каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром.

Атрибуты «Количество товара в накладной» и «Цена товара в накладной» являются атрибутами сущности «Список товаров в накладной».

Точно также поступим со связью, соединяющей сущности «Склад» и «Товар». Введем дополнительную сущность «Товар на складе». Атрибутом этой сущности будет «Количество товара на складе». Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

Теперь можно внести все это в диаграмму «Оптовая фирма» (рис. 5.9).

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

Рисунок 5.9 Диаграмма «Оптовая фирма»

Практические рекомендации по проектированию БД

Вопросы и упражнения для самоконтроля к главе 5

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

К основным функция СУБД принято относить следующие:

Непосредственное управление данными во внешней памяти

Управление буферами оперативной памяти

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

Журнализация

Поддержка языков БД

Системы обработки транзакций

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

OLTP-системы

OLAP -системы

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

Сервер 1 Сервер 2

Ответ запрос ответ

Ответ запрос

Архитектура СУБД

Пользователи БД

Вопросы и упражнения для самоконтроля по главе 6

Клиент Сервер

Данные

Клиент Сервер

Процедур

Данные

Клиент Сервер

Запуск

Процедур

Данные SQL

Клиент Сервер приложений Сервер БД

Рисунок 7.4 Модель сервера приложений

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

Аспекты сетевого взаимодействия

Технология распределенной БД (технология STAR)

Технология тиражирования данных

Концепция активного сервера в модели DBS

Вопросы и упражнения для самоконтроля к главе 7