Гринберг А.С., Иванюкович В.А., Новыш Б.В., Шешолко В.К. Ситуационный анализ и моделирование на основе информационных технологий баз данных

Подождите немного. Документ загружается.

номер и уникальное атомное число. Т.е., в таком отношении есть четыре

потенциальных ключа и из них может быть выбран первичный ключ.

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

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

целостности объектов: Ни один элемент первичного ключа базового

отношения не может быть Null-значением. Понятие Null-значения было

предложено Е. Коддом для представления отсутствующей информации: если

данный кортеж имеет Null-значение данного атрибута, то это означает, что в

таком кортеже значение атрибута по некоторой причине отсутствует. Null-

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

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

базовых отношений и только для первичных ключей.

Причина важности потенциальных ключей в реляционной системе

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

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

помощью выражения

Сотрудники WHERE Табель=’В3'

мы гарантированно получим отношение, содержащее не более одного

кортежа. Но с помощью выражения

Сотрудники WHERE Код_отдела=’А1'

мы можем получить любое количество кортежей. Таким образом,

потенциальные ключи имеют такое же фундаментальное значение для

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

успешной работы компьютера, на котором эта система установлена.

Итак, потенциальный ключ – это минимальный набор атрибутов, по

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

Минимальность означает, что исключение из набора любого атрибута не

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

отношение обладает хотя бы одним потенциальным ключом. Один из них

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

отдавать предпочтение несоставным ключам или ключам, составленным из

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

длинными текстовыми значениями (предпочтительнее использовать

целочисленные атрибуты). Так, для идентификации студента можно

использовать либо уникальный номер зачетной книжки, либо набор из

фамилии, имени, отчества, номера группы и, может быть, дополнительных

атрибутов, так как не исключено появление в группе двух студентов с

одинаковыми фамилиями, именами и отчествами. Не допускается, чтобы

первичный ключ отношения (любой атрибут, участвующий в первичном

ключе) принимал неопределенное значение (Null-значение). Иначе возникнет

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

кортеж отношения (экземпляр сущности). По тем же причинам необходимо

обеспечить уникальность первичного ключа.

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

ключей:

1. Если сущность С связывает сущности А и В, то она должна включать

внешние ключи, соответствующие первичным ключам сущностей А и В.

2. Если сущность В обозначает сущность А, то она должна включать внешний

ключ, соответствующий первичному ключу сущности А.

С понятием внешнего ключа реляционная модель связывает правило

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

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

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

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

корректном состоянии. Чтобы такое состояние сохранилось, надо либо

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

разрешить такие операции, но выполнить некоторые компенсирующие

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

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

(например, отдел, в котором числятся сотрудники)?

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

который ссылается внешний ключ (например, изменить номер отдела)?

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

 ограничение – «ограничить» операции до момента появления первой

ссылки;

 каскадирование – «каскадировать» операции, удаляя или обновляя все

соответствующие атрибуты.

Разработчик при проектировании внешних ключей базы данных должен

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

внешний ключ, но и ответить на эти вопросы, т.е. указать специальные правила

внешних ключей для данного внешнего ключа.

Реляционная модель допускает появление Null-значений среди атрибутов

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

отдельные сотрудники не числились ни в одном отделе. В таком случае в

соответствующем кортеже отношения «Сотрудники» будет отсутствовать код

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

значение внешнего ключа должно либо быть равным значению первичного

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

строгое определение внешнего ключа может быть таким: Внешний ключ FK в

отношении R2 – это подмножество множества атрибутов R2 такое, что

существует базовое отношение R1 с потенциальным ключом CK, для

которого каждое значение FK в текущем значении R2 или является Null-

значением, или совпадает со значением CK некоторого кортежа в текущем

значении R1.

В дополнении к целостности отношений и целостности по ссылкам

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

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

относятся к ней одной и определяются разработчиком. Чаще всего

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

(экзаменационная оценка от 2 до 5), принадлежность набору значений (пол "М"

или "Ж"). В этом случае средством обеспечения целостности являются домены.

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

атрибута берется из соответствующего домена. Это более фундаментальное

правило, чем первые два.

3.5. Некоторые правила построения инфологической модели

На основании сказанного в этой главе можно сформулировать некоторые

правила построения реляционной модели.

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

содержащих всю информацию, которая должна храниться в БД.

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

таблиц.

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

которые в реляционной модели называются записями (records).

3. Столбцы таблицы называются полями (fields), им присваиваются имена и в

каждом из них размещаются однородные значения данных (даты, фамилии,

целые числа или денежные суммы и т.п.).

4. Записи имеют фиксированное число полей (столбцов) и значений.

Множественные поля и повторяющиеся группы недопустимы. Иначе

говоря, в каждой позиции таблицы на пересечении строки и столбца всегда

должно быть только одно значение или ничего.

5. Записи таблицы обязательно отличаются друг от друга хотя бы

единственным значением, что позволяет однозначно идентифицировать

любую строку такой таблицы.

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

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

единственным. В частности, не существует каких-либо формул или

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

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

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

принадлежащих одному и тому же домену (рис.2.7.3). На рис.2.7.6 приведен

результат действия таких связей – соединение двух таблиц.

7. При выполнении операций с таблицей ее строки и столбцы можно

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

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

возможность выделения любой строки или любого набора строк с

указанными признаками.

Покажем пример моделирования простой базы данных. Необходимо

хранить и обрабатывать информацию о выполняемых фирмой проектах,

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

и поставщики составляют основные объекты (или сущности), о которых фирме

необходимо хранить информацию. Под термином объект (сущность) понимают

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

базовые отношения базы данных. Кроме основных объектов существуют и

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

отношение ДП между поставщиками и деталями: каждый поставщик

поставляет определенные детали и, наоборот, каждая деталь поставляется

определенным поставщиком; также существует отношение между проектами и

деталями (отношение ПрД). Эти отношения двусторонние – их можно

рассматривать в обоих направлениях. Следует помнить, что такие отношения,

подобно основным объектам, являются частью данных и в некотором смысле

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

объектов. Схема, представленная на рис. 3.5.1, называется диаграммой объект/

отношение или сущность/связь.

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

Таблица Проекты представляет уникальный номер проекта Пр№, его

наименование Имя_Пр и размещение – Гор_Пр.

Проекты

Детали

Поставщики

ПрД ДП

Рис. 3.5.1. Диаграмма Объект/отношение

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

детали Имя_Д, цвет Цв, вес Вес (в граммах), город Гор_Д, где производится

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

одном городе.

Таблица Поставщики представляет уникальный номер поставщика П№,

имя Имя_П (не обязательно уникальное), значение рейтинга Статус, место

расположения Гор_П.

Таблица ДП представляет поставки. Одно из ее назначений – соединение

таблиц Детали и Поставщики. Она может состоять из полей П№ и Д№ .

Таблица ПрД представляет потребность проектов в деталях и соединяет

таблицы Проекты и Детали. Она может состоять из полей Пр№, Д№ и,

возможно, Кол.

Таким образом, можно считать, что инфологическая модель базы данных

построена. Однако очевидно, что информацию, содержащуюся в таблицах ДП и

ПрД, можно представить более рационально, соединив ее в одну таблицу с

именем, например, Поставки, включающую поля Д№, П№, Пр№ и Кол. Эта

таблица будет выполнять функцию отношений (связей) между объектами

(сущностями) Проекты, Детали и Поставщики конструируемой базы данных.

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

представлены таблицами.

С учетом изложенного, схема базы данных может иметь вид,

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

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

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

Проекты

Пр№

Имя_Пр

Гор_Пр

Детали

Д№

Имя_Д

Цв

Вес

Гор_Д

Поставки

Д№

П№

Пр№

Кол

Постав-

щики

П№

Имя_П

Статус

Гор_П

Рис. 3.5.2. Схема базы данных

1 М

М 1

1 М

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

CREATE DOMAIN Пр№ CHAR(5)

CREATE DOMAIN Имя CHAR(30)

CREATE DOMAIN Д№ CHAR(5)

CREATE DOMAIN Цв CHAR(10)

CREATE DOMAIN Вес NUMERIC(5)

CREATE DOMAIN Гор CHAR(15)

CREATE DOMAIN Кол NUMERIC(5)

CREATE DOMAIN П№ CHAR(5)

CREATE DOMAIN СтатусNUMERIC(3)

CREATE BASE RELATION Проекты

( Пр№ DOMAIN ( Пр№ ),

Имя_Пр DOMAIN ( Имя ),

Гор_Пр DOMAIN ( Гор ),

PRIMARY KEY ( Пр№ );

CREATE BASE RELATION Детали

( Д№ DOMAIN ( Д№ ),

Имя_Д DOMAIN ( Имя ),

Цв DOMAIN ( Цв ),

Вес DOMAIN ( Вес ),

Гор_Д DOMAIN ( Гор ),

PRIMARY KEY ( Д№ );

Поставки Детали

П№ Д№ Пр№ Кол Д№ Имя_Д Цв Вес Гор

П1 Д1 Пр1 200 Д1 Тестер Черный 250 Минск

П1 Д1 Пр4 700 Д2 Дозиметр Серый 700 Борисов

П2 Д3 Пр1 400 Д3 Радиометр Черный 1400 Гродно

П2 Д3 Пр2 200 Д4 Часы Желтый 140 Минск

П2 Д3 ПР3 200 Д5 Рулетка Красный 200 Брест

П2 Д3 ПР4 500 Д6 Лом Черный 5000 Варшава

П2 Д3 ПР5 600

П2 Д3 ПР6 400 Поставщики

П2 Д3 ПР7 800 П№ Имя_П Статус Гор

П2 Д5 ПР2 100 П1 Волк 20 Брест

П3 Д3 ПР1 200 П2 Заяц 10 Минск

П3 Д4 ПР2 500 П3 Лев 30 Гродно

П4 Д6 ПР3 300 П4 Лиса 20 Минск

П4 Д6 ПР7 300 П5 Бык 30 Брест

П5 Д2 ПР2 200

П5 Д2 ПР4 100 Проекты

П5 Д5 ПР5 500 Пр№ Имя_П Гор

П5 Д5 ПР7 100 Пр1 Спутник Минск

П5 Д6 ПР2 200 Пр2 Корунд Минск

П5 Д1 ПР4 100 Пр3 Лес Брест

П5 Д3 ПР4 200 Пр4 Шина Бобруйск

П5 Д4 ПР4 800 Пр5 Азот Гродно

П5 Д5 ПР4 400 Пр6 Электро Молодечно

П5 Д6 ПР4 500 Пр7 Кристалл Пинск

Рис.3.5.3. База данных проектов, деталей и поставщиков

CREATE BASE RELATION Поставщики

( П№ DOMAIN ( П№ ),

Имя_П DOMAIN ( Имя ),

СтатусDOMAIN ( Статус ),

Гор_П DOMAIN ( Гор ),

PRIMARY KEY ( П№ );

CREATE BASE RELATION Поставки

( П№ DOMAIN ( П№ ),

Д№ DOMAIN ( Д№ ),

( Пр№ DOMAIN ( Пр№ ),

Кол DOMAIN ( Кол ),

PRIMARY KEY ( П№, Д№, Пр№);

FOREIGN KEY ( П№ ) REFERENCES Поставщики

FOREIGN KEY ( Пр№ ) REFERENCES Проекты

FOREIGN KEY ( Д№ ) REFERENCES Детали;

Представленная на рис. 3.5.2 – 3.5.3 модель базы данных будет

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

операций.

3.6. Организация доступа к данным

Производительность работы с данными в значительной степени

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

Целью упорядочения расположения данных на диске (или структуры хранения)

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

3.6.1. Страницы и файлы

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

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

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

определяет страницу, на которой находится искомая запись, а затем для

извлечения этой страницы запрашивает диспетчер дисков. Диспетчер дисков

определяет физическое положение искомой страницы на диске и посылает

соответствующий запрос на ввод-вывод данных (рис.3.6.1).

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

системы, с помощью которого выполняются все дисковые операции ввода-

вывода (BIOS). Для выполнения этих операций необходимо знать значения

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

физические адреса. Вместо этого

диспетчеру файлов достаточно

рассматривать диск как набор

страниц фиксированного размера с

уникальным идентификационным

номером. Соответствие физических

адресов на диске и номеров страниц

обеспечивает диспетчер дисков.

1. При работе с диском как

набором хранимых файлов

(в теории систем баз

данных под файлом

подразумевается хранимый

набор однотипных записей,

т.е. в случае реляционной

базы данных – таблица)

диспетчер файлов

использует средства диспетчера дисков согласно определенному в

СУБД способу. Каждый хранимый файл имеет идентификационный

номер (имя), а каждая хранимая запись имеет идентификационный

номер записи (RID). Диспетчер файлов организует выполнение всех

операций с файлами, необходимых при работе с базой данных и для

формирования структуры хранения.

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

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

на диске как можно более близко. Для этого используется технология

кластеризации данных. Различают внутрифайловую кластеризацию, когда

кластеризация осуществляется в рамках одного хранимого файла (например,

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

порядковому номеру, то все записи о поставщиках следует физически

размещать таким образом, чтобы запись о поставщике П1 была возле записи

П2, запись П2 – возле записи П3 и т.д.) и межфайловую кластеризацию, когда

СУБД

Диспетчер

файлов

Диспетчер

дисков

База данных

на внешних

носителях

Запрос хранимой

записи

Возвращение

хранимой записи

Возвращение

храним. страницы

Запрос хранимой

страницы

Операция

ввода/вывода

Чтение данных с

диска

Рис.3.6.1. Схема взаимодействия СУБД,

диспетчера файлов и диспетчера дисков

охвачено сразу несколько файлов (например, если часто требуется

осуществлять доступ к данным о поставщике и обо всех его поставках деталей

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

рядом). В каждый момент времени кластеризацию файла или набора файлов

можно осуществлять только одним из этих способов.

Внутрифайловую и межфайловую кластеризацию СУБД может

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

это возможно) или на смежных страницах. Поэтому СУБД важно иметь

сведения не только о сохраненных файлах, но и о страницах. Диспетчер дисков

должен обеспечить, чтобы логически близкие страницы были физически близко

расположены на диске.

Очевидно, что после выполнения нескольких обычных действий (например,

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

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

«фрагментирован»). Поэтому логическую последовательность страниц в

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

физически близкого размещения на диске. Для этого каждая страница содержит

заголовок страницы с информацией о физическом дисковом адресе страницы,

которая логически следует за данной страницей. Тогда достаточно знать

расположение только первой страницы из набора, поскольку положение второй

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

страниц.

В реальных базах данных на одной странице может размещаться не одна, а

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

страницы может соответствовать физической последовательности, заданной

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

отдельные записи вверх или вниз на странице, размещая все записи в верхней

части страницы и оставляя свободное пространство в нижней части страницы.

В стандартных СУБД хранимый файл представляет собой набор хранимых

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

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

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