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

Алгебра и исчисление

.
Реляционное исчисление (РИ), как и реляционная алгебра, есть абстрактный язык манипулирования реляционными данными.
РА и РИ эквивалентны в том смысле, что для любого допустимого выражения РА можно построить формулу РИ, производящую такой же результат, и наоборот. В связи с этим возникает вопрос: зачем включать в РМД и алгебру, и исчисление? Ответ кроется в разном уровне процедурности
этих механизмов.
РА представляет в явном виде набор операций, которые можно использовать для вычисления необходимого результата. Выражения реляционной алгебры имеют процедурную интерпретацию. Они сообщают системе, как из базовых отношений построить требуемое производное отношение. Оно может быть вычислено в соответствии с определениями элементарных алгебраических операций, с учетом их старшинства и возможных скобок.
В отличие от РА, РИ есть просто система обозначений для определения производного отношения в терминах других отношений. Для формул РИ процедурной интерпретации нет. Они декларативны. Формула просто определяет условия, которым должны удовлетворять кортежи результирующего отношения, – требуемые данные[25].
Например, запрос: «Получить имена поставщиков, поставляющих деталь Р2» в терминах алгебры имеет вид:
(( SPJ JOIN S) WHERE P# = ‘P2’)[Sn];
и описывает следующую процедуру:
· построить естественное соединение SPJ
и J по атрибуту S#;
· выбрать из результата кортежи, в которых P# = ‘P2’;
· выполнить проекцию результата на атрибут Sn.
Однако можно и не указывать, какие соединения, проекции и селекции строить. Можно сформулировать на некотором формальном языке фразу следующего содержания:
«Получить значения атрибута Sn для таких поставщиков, для которых в SPJ
существуют кортежи с тем же значением атрибута S# и со значением атрибута P# = ‘P2’.»
Подобной фразой можно точно указать системе характеристики интересующего нас отношения. Пусть она сама решает, какие вычисления нужно проделать для того, чтобы получить его.
Формальный язык для точной записи подобных высказываний называется реляционным исчислением. Его основой является исчисление предикатов первого порядка.
Современная РМД располагает двумя вариантами реляционных исчислений. В одном из них областями возможных значений переменных являются отношения (РИ с переменными-кортежами), а в другом – домены (РИ с переменными на доменах). Оба РИ, как и РА, обладают свойством замкнутости относительно множества отношений. То есть формулы РИ определяются над отношениями и интерпретируются как отношения. Это дает возможность строить вложенные формулы, выражая ими очень сложные запросы к реляционной БД.

Аномалия обновления значений

. Если обновляются значения атрибутов, функционально зависящих от части ПК или от неключевых атрибутов, то система не может проверить эти ФЗ, так как их невозможно объявить. Поэтому она не заметит, что поставщик из Яи «приобрел» запрещенный статус. Будут пропущены также ошибки при обновлении значений поля Jn
или Sn и т.п.
3.2.3

Аномалия вставки типа а)
. Если А ® В, то всякий раз, как встретится конкретное значение А, должно встретиться соответствующее ему значение В. Если при этом А не является возможным ключом отношения, то нет никаких ограничений на число кортежей с конкретным значением А и соответствующим ему значением В. Этим и обусловлено избыточное дублирование.
Для того чтобы система могла блокировать ввод ошибочных значений B, она должна знать о наличии ФЗ А ® В. Но если A не является возможным ключом, мы не можем объявить ФЗ А ®
В. Поэтому система не может запретить ввод значения B, не соответствующего этой ФЗ.
В нашем примере универсального отношения атрибут S# не является возможным ключом. Связанная с этим аномалия вставки типа а) обусловлена тем, что нет никакой возможности объявить ФЗ S# ® Sn, S# ® St, S# ® Sci, Sci ® St.

Аномалия вставки типа б)

. Она обусловлена тем, что вставляемые значения функционально зависят от части первичного ключа (ПК).
Для того чтобы добавить в БД сведения о новом поставщике, достаточно указать значение S#
и проверить ФЗ S# ® Sn, S# ® St, S# ® Sci, Sci ® St. Но S# – только часть ПК универсального отношения и эти ФЗ мы не можем объявить. Вставляя кортеж в универсальное отношение, нужно указать определенные значения всех атрибутов первичного ключа и проверить все объявленные таким образом ФЗ. Однако среди них нет интересующих нас зависимостей S# ® Sn, S# ® St, S# ® Sci, Sci ® St. Поэтому, даже если мы присвоим атрибутам P#, J#, Dt
какие-то значения «по умолчанию» и формально обеспечим возможность вставки кортежа, целостность данных не гарантирована.
Таким образом, аномалии обновления типа б) обусловлены тем, что в схеме отношения имеются атрибуты, функционально зависящие от части первичного ключа.

База данных «Поставщик-Деталь-Изделие»

. Наша БД хранит сведения о ПОСТАВЩИКах, поставляемых ими ДЕТАЛях, ИЗДЕЛИях, для которых поставляются ДЕТАЛи и ПОСТАВКАх, выполненных ПОСТАВЩИКами. Данные размещены в четырех отношениях. Концептуальная схема БД приведена на рис. 2.3.
Прямоугольники представляют схемы отношений, дуги – связи отношений, имена над прямоугольниками – названия объектов ПО или фактов. В прямоугольники вписаны имена атрибутов – характеристик объектов. Символы в квадратных скобках – псевдонимы атрибутов, введенные для удобства ссылок.[14]
Диаграмма отражает логические взаимосвязи данных, обусловленные требованиями ПО. Однако, если ограничиться только определениями отношений, то в нашу БД можно будет уложить что угодно. Значения атрибутов должны удовлетворять некоторым ограничениям. Эти ограничения задаются действующими в ПО правилами (бизнес-правилами).

Рис. 2.3 База данных «Поставщик – Деталь – Изделие» (S-P-J)

База данных

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

Бизнес-правила и ограничения целостности

. Пусть в нашей ПО действуют следующие правила:
· номер поставщика уникален;
· номер изделия уникален;
· номер вида детали уникален;
· номер поставщика должен иметь вид ‘Sх’, где х любая последовательность цифр;
· номер вида изделия должен иметь вид ‘Jх’, где х любая последовательность цифр;
· номер вида детали должен иметь вид ‘Pх’, где х любая последовательность цифр;
· значение статуса поставщика может быть только целым, кратным 5 в диапазоне 5 ¸100;
· цвет детали должен выбираться из определенного списка;
· названия городов должны выбираться из определенного списка;
· красные детали хранятся только в Яе;
· если город поставщика Яя, то его статус 50;
· конкретный поставщик может в течение одного дня поставить конкретную деталь для конкретного изделия только однажды;
· количество деталей в одной поставке не может быть меньше 100 или больше 1000;
· месячный объем поставки любой детали не может превосходить 10000.
Если в нашей БД есть, например, кортеж {(номер поставщика, ‘S1’), (название поставщика, ‘Рога и копыта’), (статус, 100), (город размещения, ‘Черноморск’)}[15], то он имеет вполне осмысленную интерпретацию в терминах ПО, если значение S# = ‘S1’ встречается только в этом кортеже и Черноморск включен в список городов. Если такого названия нет в списке, то и кортеж осмысленной интерпретации не имеет.
Если мы просуммируем значения поля Qt во всех строках таблицы SPJ, в которых значение P# = ‘P1’, а значения дат лежат в интервале от 01.03.98 до 31.03.98, и увидим, что эта сумма больше 10000, то либо наши данные ошибочны (этого не должно быть по правилам), либо кто-то из служащих нарушил правила.
Подобных правил в любой ПО очень много. Они подчас бывают очень сложными и действуют независимо от способа хранения данных – на бумаге, на диске, … Если они соблюдаются, то гарантирована интерпретируемость данных. Как все правила, они формальны. Их можно сформулировать в виде предикатов и реализовать алгоритмы вычисления значений этих предикатов на текущих значениях хранимых данных.
Иными словами, существует принципиальная возможность

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

Проверить истинность данных автомат не может. Интерпретируемый кортеж {‘S1’, ‘Рога и копыта’, 100, ‘Черноморск’}

может вводить в заблуждение, если не существует в Черноморске фирмы с таким названием.

Целостность

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

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

ограничениями целостности (ОЦ) данных.

Внешние ОЦ

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

Замечание 4.

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

Все БД, основанные на РМД, кроме специфических правил (внешних ОЦ), подчиняются еще общим

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

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

. Правило целостности сущности часто формулируют как требование уникальности значений первичного ключа. Однако, на самом деле это не так. Требование целостности сущности состоит в том, что каждый кортеж любого отношения должен быть идентифицируем. Иначе говоря, в БД не должна храниться информация о чем-то таком, что мы не можем идентифицировать.
Это требование связано с проблемой представления незнания в БД. В реальной жизни в базу данных нередко приходится включать кортежи, содержащие неизвестные значения некоторых атрибутов.
Например:
· поставщик зарегистрирован, а статус его еще не определен;
· руководство фирмы еще не решило, в каком городе разместить производство изделия;
· известна дата смерти исторического деятеля, а дата рождения затерялась в глубине веков и т.п.
В подобных случаях соответствующим атрибутам присваиваются так называемые Null-значения.
Null
– это специальный маркер, показывающий, что значение данного атрибута в настоящий момент неизвестно и, возможно, будет введено впоследствии. Null не «ноль», не «пробел», и вообще, Null не имеет типа. Этим маркером может быть помечен любой атрибут любого кортежа.
Null
обладает следующими свойствами:
· всякое сравнение с участием Null
дает результат Null;
· все Null-значения различны;
· отрицание Null – тоже Null.
Если какой-либо из атрибутов, входящих в состав первичного ключа отношения, принял значение Null, то представленный этим кортежем экземпляр объекта ПО невозможно идентифицировать. Очевидно, нет смысла хранить в БД такую комбинацию значений.
В самом деле, что означает утверждение: «номер поставщика неизвестен»? Мы еще не присвоили ему номер? Мы не знаем, присвоен ему номер или нет? Нам неизвестно, идет ли речь об уже зарегистрированном в БД поставщике или о каком-то другом? И т.д.
Во всех случаях, прежде чем заносить
информацию в БД, необходимо идентифицировать эту информацию, т.е. задать определенное значение первичного ключа. Если допустить возможность неопределенных значений первичного ключа, то будет разрушен механизм адресации РМД.
Правило целостности сущности: ни один компонент первичного ключа отношения не может принимать неопределенное значение.
Это, как и требование целостности домена, метаправило. Оно означает, что в схеме конкретной РБД должны быть определены первичные ключи всех отношений. Тогда РСУБД не допустит появления кортежей с Null-значениями соответствующих атрибутов.

Декомпозиция универсального отношения

. Очевидный выход, избавляющий от избыточного дублирования данных, состоит в расщеплении (декомпозиции) отношения USPJ на четыре взаимосвязанных отношения – S, P, J, SPJ. Каждое из этих отношений является проекцией USPJ
на соответствующие группы атрибутов[27]:
S = (USPJ[S#, Sn, St, Sci]) RENAME SCi AS Ci;
P = (USPJ[P#, Pn, Co, We, PCi]) RENAME Pci AS Ci;
J = (USPJ[J#, Jn, Jci]) RENAME Jci AS Ci;
SPJ = USPJ[S#, P#, J#, Dt, Qt];
Ниже приведены значения этих отношений для рассматриваемого примера.

Иван

Яя

шайба

Ош

Петр

100

Ош

гайка

Яя ,

Джон

Яя

болт

Яя

Боб

Томск

винт

Ош

SPJ

...

1000

...

1000

...

500

...

1000

... ,

2000

...

1000

...

500

…

Нетрудно убедиться в том, что в этих отношениях сохранены все отмеченные ФЗ. Естественное соединение этих проекций
USPJ = (((((SPJ JOIN S) RENAME Ci AS Sci)
JOIN P) RENAME Ci AS Pci)
JOIN J) RENAME Ci AS Jci;
восстановит универсальное отношение без всяких потерь информации. Кроме того, в этой структуре объявлены все ФЗ, за исключением S.Ci ® St.
Здесь нет аномалий удаления. Из отношения SPJ
можно удалять кортежи без проблем. При удалении кортежей других отношений достаточно соблюдать правила ссылочной целостности, которые объявлены определениями отношений (см. п. 2.4.2). Нет также аномалий вставки типа б).
Сведения о непоставлявших поставщиках, непоставлявшихся деталях и о не получавших поставок изделиях можно заносить в соответствующие отношения.

Аномалии вставки типа а) и обновления значений сохраняются для отношения S. Это обусловлено наличием необъявленной ФЗ между неключевыми атрибутами S.Ci ® St.

Можно попытаться избавиться от цепочки транзитивных зависимостей S# ® Ci ® St, заменив S его проекциями. При этом не должны быть потеряны ФЗ, и естественное соединение проекций должно восстанавливать исходное отношение. Для иллюстрации проблем, которые здесь могут возникнуть, рассмотрим возможные варианты декомпозиции.

Вариант 1.

SST= S[S#, Sn, St]; CS=S[S#, Ci];

Эти проекции для реализации USPJ, приведенной в п. 3.1.2, имеют вид:

SST		CS
S#	Sn	St		S#	Ci
S1	Иван	50	;	S1	Яя
S2	Петр	100		S2	Ош
S3	Джон	50		S3	Яя
S8	Боб	50		S8	Томск

Их естественное соединение по атрибуту S#:

SST JOIN CS
S#	Sn	St	Ci
S1	Иван	50	Яя
S2	Петр	100	Ош
S3	Джон	50	Яя
S8	Боб	50	Томск

совпадает с отношением S.

Здесь сохранены ФЗ S# ® Сi, S# ® St, S# ® Sn. Однако зависимость Ci ® St утрачена. Значения атрибутов Ci и St в проекциях можно менять независимо.

Вариант 2.

SST = S[S#, Sn, St]; STC = S[St, Ci];

Это плохой вариант. Здесь утеряна зависимость S# ® Ci. Поэтому возможна потеря информации при восстановлении исходного отношения. В самом деле, эти проекции имеют вид:

SST		STC
S#	Sn	St	St	Ci
S1	Иван	50	50	Яя
S2	Петр	100	100	Ош
S3	Джон	50	50	Томск
S8	Боб	50

Естественное соединение этих отношений будет содержать лишние кортежи:

SST JOIN STC
S#	Sn	St	Ci
S1	Иван	50	Яя
S2	Петр	100	Ош
S3	Джон	50	Яя
S1	Иван	50	Томск
S3	Джон	50	Томск

<

Это совсем не похоже на исходное отношение. Мало того, что в нем появились ложные кортежи. Атрибут S#

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

Вариант 3.

SC = S[S#, Sn, Ci]; CS=S[Ci, St];

Эти проекции имеют вид:

SC		CS
S#	Sn	Ci	St	Ci
S1	Иван	Яя	50	Яя
S2	Петр	Ош	100	Ош
S3	Джон	Яя	50	Томск
S8	Боб	Томск

Здесь не потеряна ни одна из ФЗ, существующих в исходном отношении. В самом деле, S# ® Sn и S# ® Сi, так как S# – первичный ключ отношения SC. Зависимость S# ® St также неявно существует. Каждому конкретному значению S# соответствует единственное значение Ci, которому в свою очередь соответствует единственное значение St. Следовательно, конкретному значению S# соответствует единственное значение St.

Естественное соединение SC и CS будет происходить без потерь информации, то есть в результате соединения не появятся кортежи, которых не было в исходном отношении. Это следствие того, что Ci – общий атрибут SC и CS, является потенциальным ключом CS. Каждому значению Ci соответствует единственный кортеж CS, который будет при соединении сливаться с соответствующими кортежами SC и образовывать, таким образом, только те кортежи, которые его породили при выполнении проекции S[Ci, St].

Дополнения к модели

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

Дополнительные реляционные операции

.
Определенные к настоящему моменту операции обеспечивают манипуляции кортежами, но не дают никаких средств для работы со скалярами, а это часто бывает необходимо.
Например, могут понадобиться сведения о весах поставок. Их можно получить из отношения (SPJ JOIN P)[SPJ#, We, Qt], вычислив для каждого кортежа значение We*Qt. Однако имеющимися средствами невозможно получить производное отношение со схемой {SPJ#, Tot_We}, где Tot_We
принимает значения выражения We*Qt.
Это пример «горизонтальных вычислений», т.е. комбинирования значений атрибутов из текущего кортежа отношения-операнда. В процессе анализа данных часто нужно комбинировать значения атрибута в различных кортежах – проводить «вертикальные» вычисления.
Например, для создания отчета о поставках может понадобиться отношение, содержащее номера поставщиков, номера поставляемых ими деталей и общие объемы поставок этих деталей, выполненных этими поставщиками. Чтобы получить такое отношение, нужно:
·
сгруппировать кортежи отношения SPJ по значениям подмножества атрибута {S#, P#};
· сформировать отношение со схемой {S#, P#, Tot_Qt}, где Tot_Qt принимает для каждого значения {S#, P#} единственное значение, равное сумме значений атрибута Qt во всех кортежах группы.
Определенные ниже операции производят отношения, содержащие результаты «горизонтальных» и «вертикальных» вычислений.

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

. Реализация изложенной архитектурной концепции вовсе необязательно явно
включает все три уровня. Однако в любой реализации ПП получают доступ к хранимым данным только через посредство СУБД. Для примера рассмотрим схему алгоритма выполнения операции чтения данных прикладной программой [9] (рис. 1.7).

Рис. 1.7 Доступ к данным в СБД
Шаг 1. ПП обращается к СУБД с запросом на чтение записи внешней модели.
Шаг 2. СУБД, используя схемы ВМД и КМД и описание отображения внешний « концептуальный, определяет, какие записи КМД необходимы для формирования требуемой записи ВМД.
Шаг 3.
СУБД, используя схемы КМД и ВНМД и описание отображения концептуальный «
внутренний, определяет, какие записи внутренней модели необходимы для формирования затребованных записей КМД и совокупность физических записей, которые должны быть для этого считаны с физического носителя.
Шаг 4.
СУБД выдает ОС запрос на считывание в свои буферы необходимых записей физической базы данных (ФБД).
Шаг 5.
ОС считывает затребованные записи и помещает их в системные буферы СУБД.
Шаг 6. На основании имеющихся схем моделей и описаний отображений СУБД формирует в своем буфере затребованную внешнюю запись.
Шаг 7. СУБД пересылает сформированную внешнюю запись в рабочую область (РО) ПП.
Шаг 8. СУБД передает в ПП сообщение о результатах выполнения запроса.
Процедура записи данных из ПП в ФБД выполняется аналогично.

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

. Существует несколько разновидностей операции соединения отношений. Наиболее важный для практики вид – естественное соединение или просто соединение.
Эта операция применяется к отношениям, схемы которых имеют одноименные
атрибуты, определенные на общем
домене, т.е. к отношениям с пересекающимися
схемами.
Результатом является отношение, схема которого есть теоретико-множественное объединение схем операндов, а тело составлено из теоретико-множественных объединений таких кортежей операндов, в которых значения одноименных атрибутов совпадают.
Пусть X, Y, Z
– подмножества атрибутов, а R1
и R2 – отношения со схемами R1(X, Y) и R2(Y, Z), соответственно. Естественным соединением этих отношений называется отношение R = R1 Ä R2, имеющее схему R(X, Y, Z) и тело, образованное всеми кортежами {X:x, Y:y, Z:z}
такими, что в R1
существует кортеж {X:x, Y:y} и в R2 – кортеж {Y:y, Z:z}.
Пример 1.

R1 =

, R2 =

, R = R1 Ä R2 =

Пример 2.

R1 =

, R2 =

, R = R1 Ä R2 =

Формализованное описание задачи

.
Цель: документирование результатов начального анализа требований ПО. Формирование общих представлений об информационных потребностях ПО.
Задача:
оформление результатов обследования ПО в виде текстового документа, содержащего:
·
наименование задачи;
· формулировку цели деятельности;
· перечень выполняемых функций с указанием субъектов;
· перечень правил бизнеса;
· перечень хранимых данных;
· перечень предполагаемых пользователей системы.
Этап 2. Определение сущностей и связей.
Цель: документирование сведений об основных сущностях ПО и характере взаимосвязей между ними.
Задачи: построение ER-диаграммы и глоссария к ней.
Перечень выходной документации:
· диаграмма ER-уровня модели;
· глоссарий (таблица).
Последовательность действий:
· выделить основные сущности и присвоить им уникальные имена;
· занести в глоссарий модели формальные определения имен сущностей;
· определить и поименовать связи между сущностями;
· построить ER-диаграмму;
· согласовать диаграмму и глоссарий с экспертами.
Этап 3. Определение семантики связей.
Цель:
документирование сведений об идентификаторах экземпляров сущностей и уяснение логики взаимосвязей сущностей на уровне идентификаторов.
Задачи:
построение диаграммы уровня ключей (KB-диаграммы) и глоссария к ней.
Перечень выходной документации:
· диаграмма KB-уровня модели;
· глоссарий (таблицы).
Последовательность действий:
· преобразовать все неспецифические связи в специфические;
· поименовать ассоциативные сущности и внести формальные определения имен в глоссарий;
· определить возможные ключи независимых сущностей и выделить первичные ключи;
· внести формальные определения имен ключевых атрибутов в глоссарий;
· показать первичные и все возможные ключи на диаграмме;
· определить типы связей и показать на диаграмме переданные ими внешние ключи;
· определить первичные и все возможные ключи зависимых сущностей и показать их на диаграмме;

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

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

· указать дискриминаторы кластеров категорий;

· согласовать диаграмму и глоссарий с экспертами;

· уточнить список хранимых атрибутов.

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

Цель:

документирование сведений о хранимых атрибутах.

Задачи:

построение полноатрибутной диаграммы (FA-диаграммы) и глоссария к ней.

Перечень выходной документации:

· диаграмма FA-уровня модели;

· глоссарий (таблицы).

Последовательность действий:

· дать формальные определения имен неключевых атрибутов;

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

· проверить условия 3НФ для каждого сущностного отношения и при необходимости выполнить нормализацию структуры;

· окончательно согласовать модель с экспертами.

Формальный подход

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

Функциональная зависимость атрибутов

Функциональная зависимость атрибутов
3.2.1 Основные определения.
Определение 1.
Пусть R некоторое отношение, А, В
– подмножества его атрибутов. Говорят, что А
функционально определяет В (или В
функционально зависит от А), если и только если для любого допустимого значения R каждому значению А соответствует точно одно значение В. Функциональную зависимость (ФЗ) принято обозначать А ® В.
Иными словами, если А ® В, то для любого допустимого значения R
два кортежа, совпадающие по значению А, совпадают также и по значению В. Обратное, вообще говоря, неверно. Подмножество А называют детерминантом
зависимости, подмножество В – зависимой частью.
Функциональные зависимости есть связи типа 1:М между подмножествами атрибутов. Они определяются смыслом данных и правилами бизнеса. Наличие ФЗ невозможно установить по результатам анализа значения отношения.
Так, в приведенном выше примере (см. п. 3.1.2) дважды встречающемуся значению
P# = ‘P1’ соответствует одно и то же значение Qt = 1000. Аналогичное соответствие наблюдается и для P# = ‘P3’и P# = ‘P8’. Однако из этих фактов нельзя сделать вывод о существовании ФЗ {P#} ® {Qt}[26]. Возможно, это случайность. Однако, если ПО действительно накладывает ограничения на разовые объемы поставок конкретных видов деталей, то есть и отмеченная ФЗ.
Зависимости S# ® St, S# ® Sci, Sci ® St действительно существуют. По правилам ПО конкретный поставщик расположен в единственном городе, имеет единственный статус, и всем поставщикам, расположенным в одном городе, присваивается один и тот же статус.
Определение 2.
Атрибуты А1, А2, ... , Аn
называются взаимно независимыми, если ни один из них не зависит функционально от какого-либо подмножества остальных.
Например, атрибуты We, Qt, S#, Jn взаимно независимы. Правила бизнеса не обусловливают каких-либо зависимостей между ними или их комбинациями.
Пусть R – некоторое отношение, А, В, С – подмножества его атрибутов. Если А ®
В, В ®
С, то А ® С. В таком случае говорят, что существует транзитивная
функциональная зависимость (С транзитивно зависит от А, А ® В ®
С).
В универсальном отношении USPJ существует транзитивная ФЗ S# ® SСi ® St, следующая из S# ® SCi, SСi ® St.
Определение 3. Пусть A и B – подмножества атрибутов и A – детерминант B. Говорят, что ФЗ A ® B
неприводима, если не существует такого подмножества C Ì
A, что C ® B.
Например, существующая в USPJ ФЗ {S#, P#, J#, Dt} ® Qt неприводима, а зависимость {S#, P#, J#, Dt} ® Jn следует из J# ® Jn, т.е. неприводимой не является.

ФЗ в декомпозированной структуре

. В структуре БД, состоящей из отношений SC, P, J, SPJ, CS объявлены[28] следующие ФЗ:

S# ® Sn;	P# ® Pn;	J# ® Jn;	A ® Qt;	S.Ci ® St.
S# ® St;	P# ® We;	J# ® J.Ci;
S# ® S.Сi;	P# ® Co;
	P# ® P.Ci;

Из них выводятся все остальные ФЗ, указанные в п.11.3.1. Например, поскольку атрибут S#
принадлежит множеству A
и является детерминантом ФЗ S# ® S.Сi, то A ® S.Ci.
Во всех отношениях этой структуры имеются только объявленные ФЗ. Именно, каждый неключевой атрибут любого отношения функционально зависит только от полного возможного ключа. Аномалии обновления данных в этой структуре невозможны.

Характеристика процесса проектирования

. Процесс проектирования БД включает три основных этапа:
·
проектирование концептуальной модели (логического макета БД);
· проектирование внутренней модели (физического макета);
· проектирование внешних моделей (локальных представлений данных для различных конечных пользователей).
Проектированию предшествует этап анализа ПО. Цель анализа – установить, какие данные должны храниться в БД, как эти данные взаимосвязаны и какие ограничения на них накладываются правилами бизнеса.
На первом этапе выбирается подходящая логическая структура для некоторого набора данных, которые должны храниться в БД. Здесь принимаются решения о том, какие базовые отношения и с какими атрибутами (схемами) следует создать и поддерживать. При этом учитываются только требования ПО. Никакие соображения реализации и аспекты использования данных не принимаются во внимание.
На втором этапе проектируются хранимые файлы, в которых будут размещаться базовые отношения, процедуры поддержания целостности, принимаются решения о том, какие нужно создать индексы, на каких носителях какие файлы следует разместить и т.п. Другими словами, на этом этапе выполняется отображение концептуальной модели на структуры хранимых данных.
Все принимаемые здесь решения зависят от конкретной СУБД, которая будет контролировать базу. Абсолютно точная реализация логического макета БД средствами этой СУБД может оказаться невозможной. Поэтому обычно для достижения компромисса между требованиями ПО и возможностями реализации приходится выполнить несколько итераций проектирования логического и физического макетов.
На третьем этапе определяются подмножества данных, необходимых конкретным КП, и проектируются отображения концептуального макета БД на макеты КП. Кроме того, проектируются интерфейсы КП.
Требования конечных пользователей меняются со временем. Может возникнуть потребность в данных, хранение которых не предусмотрено. Может исчезнуть необходимость хранения каких-то данных. Могут измениться способы использования хранимых данных или правила бизнеса.
Все это приводит к необходимости изменения логического макета. Таким образом, процесс проектирования БД, условно изображенный на рис. 3.1, продолжается в течение всего периода жизни системы.

Рис. 3.1Этапы проектирования БД

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

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

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

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

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

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

Иерархии сущностей

.
При описании ПО нередко обнаруживается, что несколько различных объектов имеют сходные свойства и вступают в одинаковые связи с другими объектами. Либо наоборот, оказывается, что экземпляры объекта образуют подмножества, обладающие различными свойствами и вступающие в различные связи.
Например, множество преподавателей ВУЗа является подмножеством множества работников ВУЗа, которое включает в себя, кроме преподавателей, учебно-вспомогательный персонал, работников обеспечивающих служб, администрации и другие категории работников. В базе данных ВУЗа должна быть представлена информация обо всех этих категориях. Часть характеристик категорий совпадает (например: табельный номер, ФИО, дата рождения). Другая часть свойственна только конкретной категории (например, преподаватель, как правило, имеет ученую степень, а лаборант – нет). Кроме того, различные категории работников ВУЗа могут вступать в различные отношения с другими объектами ПО. Например, преподаватель обязательно преподает, по крайней мере, одну учебную дисциплину, а электрик АХЧ никогда не вступает в такую связь.
Можно предложить два варианта описания этой ситуации.
· Ввести единственную сущность СЛУЖАЩИЙ
как объединение множеств атрибутов всех категорий служащих. Эта сущность вступает в связи со всеми другими сущностями, с которыми связаны преподаватель или лаборант и т.д.
· Ввести сущности ПРЕПОДАВАТЕЛЬ, ЛАБОРАНТ и т.д., представляющие выделенные категории работников, и определить все связи этих сущностей.
Однако, и первый и второй варианты неудовлетворительны. Оба неадекватно отображают предметную область. Действительно, первый вариант скрывает реально существующую внутреннюю структуру сущности СЛУЖАЩИЙ и затрудняет понимание ее связей. Можно предположить, что любой экземпляр СЛУЖАЩЕго может заниматься преподаванием, хотя на самом деле это не так. Второй вариант описания этим недостатком не обременен, зато он скрывает факт наличия общих характеристик сущностей.
Для отображения подобных ситуаций в модели ПО вводятся понятия родовой (обобщенной) сущности и категории.

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

(подклассов).

Категорией

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

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

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

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

сущностей любой сложности.

Имя роли

Имя роли
Именование ролей – это механизм разрешения конфликтов имен. Они возникают, например, в унарных связях (см. п. 2.3.4,, замечание 9). Нередки также ситуации, когда один и тот же атрибут передается сущности через посредство нескольких различных связей.
Пример. БД должна хранить сведения о некоторых ИЗДЕЛИях и об УЗЛах, входящих в их состав. При этом сами УЗЛы могут состоять из других узлов, т.е. быть составными ИЗДЕЛИями. Нужно показать, в состав каких ИЗДЕЛИй какие УЗЛы входят. Один и тот же УЗЕЛ может входить в состав различных ИЗДЕЛИй. На ER- уровне это может выглядеть так:

Однако на KB-уровне придется преобразовать это неспецифическое соединение к виду

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

Информация, данные

.
Словом «информация» мы будем обозначать любые сведения о чем-либо, которые могут быть восприняты, преобразованы, сохранены и найдены при помощи ЭВМ.
Данные
– это форма, которую может принять информация. Приведем два определения этого понятия.
1) Представление фактов, понятий или команд в формализованном виде, удобном для пересылки, интерпретации и обработки человеком или автоматически.
2) Любое представление, которому приписано или может быть приписано какое-то значение.
Эти определения раскрывают два различных аспекта понятия. Первое утверждает, что данные – это одна из возможных форм представления информации. В соответствии со вторым данные – это абстракция, символ, принимающий различные значения.

Например, фамилия, возраст, пол – это символы, поставленные в соответствие абстрактным понятиям. ‘Иванов’, ‘Петрова’, ‘Сидоров’ – значения символа фамилия.
Отметим, что оба определения не накладывают никаких ограничений на внутреннюю структуру представления. Например, данными является символ ЧЕЛОВЕК, обозначающий множество символов {фамилия, возраст, пол, …}. Значениями символа ЧЕЛОВЕК являются наборы значений символов-компонентов: {‘Иванов’, ‘25’, ‘муж.’, …}, {‘Петрова’, ‘18’, ‘жен.’, …}.

Изменяемость отношений

. Реляционная модель данных рассматривает отношение как структурный тип. Тип определяется схемой отношения. Все кортежи – знаки типа – удовлетворяют одной и той же схеме. Тело отношения может изменяться во времени. Отдельные кортежи могут добавляться или удаляться. Могут изменяться значения атрибутов в существующих кортежах[11]. Поэтому можно говорить об экземпляре (текущем значении) отношения с заданной схемой.
Экземпляр (значение) отношения – это набор кортежей с заданной схемой, существующий в некоторый фиксированный момент времени.
Замечание 2.
Определенное здесь понятие отношения не совпадает
с одноименным понятием теории множеств.[12]
Читателю предлагается самостоятельно обнаружить различия.

Элементарные понятия

. Выделяется шесть базовых понятий РМД: тип данных, домен, атрибут, схема отношения, кортеж, отношение. Первые три относятся к элементам данных, остальные – к структурам, объединяющим элементы.
Тип данных (в классической РМД) есть множество значений, не имеющих внутренней структуры. Это совпадает с понятием простого типа в ЯВУ. Реляционные СУБД обычно поддерживают числовые, символьные, битовые и логические типы, а также специальные числовые типы, такие как деньги, даты, время и т.п.
Домен есть подмножество элементов типа. Формально домен определяется как пара <тип, предикат>. Предикат задает условия принадлежности элемента типа домену. На одном и том же типе можно определить произвольное число доменов.
Атрибут
есть имя, поставленное в соответствие домену и представляющее семантически значимое свойство объекта ПО. Если домену поставлено в соответствие имя, то говорят, что на домене определен атрибут.
Атрибут принимает значения на домене.
На одном и том же домене можно определить произвольное число атрибутов. Атрибуты, определенные на общем домене, наследуют его свойства.

Категории пользователей

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

Компоненты языка IDEFX

Компоненты языка IDEF1X
4.2.1 Модель данных. Стандарт IDEF1X дает следующее определение модели данных:
Модель данных – графическое и текстуальное представление, идентифицирующее потребности организации в данных для достижения ее целей, выполнения функций и определения стратегий управления. Модель данных идентифицирует сущности, домены, атрибуты и связи между данными и поддерживает единый концептуальный взгляд на данные и их взаимосвязи.
В соответствии с этим определением IDEF1Х как язык описания данных содержит два важнейших компонента:
· графический – средства создания диаграмм, показывающих структуру и взаимосвязи данных;
· текстовый – правила создания и ведения текстовых документов, уточняющих и поясняющих графическую модель, – глоссариев, спецификаций, отчетов, заметок и т.п.
Мы здесь сосредоточимся, главным образом, на графическом компоненте.

Компоненты СБД

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

Рис. 1.2 Состав СБД

СБД	- система базы данных,	ПП	- прикладные программы,
ИК	-информационный компонент,	ЯС	- языковые средства,
БД	- база данных,	ЯОД	- языки определения данных,
ССД	- словарь-справочник данных,	ЯМД	- языки манипулирования данными,
СУБД	- система управления БД,	ЯП	- языки программирования,
ПС	- программные средства,	ОС	- операционная система,
ШС	- штатные средства,	ТС	- технические средства,
Ядро	- ядро СУБД,	ОМС	-организационно-методич. средства,
Т/И	- трансляторы/интерпретаторы,	АБД	- администратор базы данных.
Ут	- утилиты,

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

СУБД

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

Штатные средства СУБД обеспечивают следующие функции:

· ядро – организацию ввода, обработки и хранения данных;

· трансляторы/интерпретаторы – компиляцию и/или интерпретацию прикладных программ, написанных на входных языках СУБД;

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

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

Языковые средства

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

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

· Языки манипулирования данными обеспечивают навигацию в БД или формулирование запросов к данным.

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

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

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

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

К организационно-методическим средствам

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

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

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

· анализ предметной области;

· проектирование структуры БД;

· обеспечение целостности данных;

· первоначальная загрузка и ведение БД;

· защита данных;

· обеспечение восстановления БД;

· анализ обращений пользователей к БД;

· анализ эффективности функционирования СБД и развитие системы;

· работа с пользователями;

· подготовка и поддержание системных программных средств;

· организационно-методическая работа.

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

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

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

· проектировщики структур БД;

· проектировщики технологических процессов обработки данных;

· системные программисты;

· прикладные программисты;

· операторы;

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

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

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

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

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

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

Концептуальная модель ПО

.
Концептуальной (информационной) моделью ПО называется формальное описание объектов реального мира, их свойств и отношений между ними, выполненное с точки зрения определенного вида деятельности и без учета каких-либо аспектов реализации БД.
Концептуальная модель должна:
· быть точной и однозначной;
· адекватно отражать природу данных;
· не зависеть от локальных интерпретаций данных (внешних моделей), обусловленных различными аспектами их использования.
Модель, удовлетворяющая этим требованиям, обеспечивает порождение любых локальных интерпретаций данных посредством формального преобразования концептуального представления. Создание концептуальной модели ПО – важнейший этап проектирования базы данных.
Понятийные основы концептуального моделирования заложены американским исследователем П. Ченом, предложившим в 1976 году так называемую модель «сущность–связь» (Entity–Relationship, ER-модель). Определенные Ченом понятия и диаграммная техника представления структур данных широко используются в практике проектирования концептуальных моделей ПО для различных приложений. Достаточно подробный обзор ER-модели Чена можно найти в [1, гл. 12]. В настоящей главе изложены основные понятия ER-модели в современной терминологии. Мы не описываем диаграммную технику Чена, хотя она и не вышла из употребления. В главе 4 настоящего пособия определены современные нотации, поддерживаемые многими CASE–средствами автоматизации проектирования БД.

Концептуальная модель предметной области

. Понятие концептуальной модели является, пожалуй, наиболее важным достижением теории баз данных. Здесь мы кратко обсудим его на интуитивном уровне. Детали и определения приведены в последующих главах.
Для того чтобы представить ПО в БД, нужно указать, какая именно информация о каких именно объектах и фактах ПО будет храниться. Другими словами, нужно выполнить описание ПО с точки зрения того вида деятельности, для которого предназначается БД. Это описание называется концептуальной (информационной) моделью ПО.
Модель включает описания трех основных компонентов ПО – объектов, их свойств и связей между ними.
Объекты – это вовлеченные в деятельность люди, предметы, места, происходящие события и т.п., информация о которых должна храниться в БД. Можно сказать, что объект есть то, что в словесном описании ПО обозначается именем существительным, возможно, с определениями. Это абстракция множества сходных в определенном смысле экземпляров.
Например, СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, УЧЕБНАЯ ДИСЦИПЛИНА, АУДИТОРИЯ
– объекты ПО «Учебный процесс». ПАЦИЕНТ, ПАЛАТА, ВРАЧ – объекты ПО «Больница».
Объекты обладают некоторыми свойствами (характеристиками), представляющими интерес для бизнеса. Так, СТУДЕНТ характеризуется номером студбилета, фамилией, номером группы, адресом и т.д. Свойствами ПРЕПОДАВАТЕЛЯ
являются фамилия, номер диплома, специальность, ученая степень и т.п. Каждый экземпляр объекта характеризуется определенным набором значений свойств.
Экземпляры объектов вступают в некоторые отношения друг с другом. Информация об этих отношениях также представляется в модели в обобщенном виде, как указание определенной связи между объектами как множествами экземпляров. Так, фраза: «Студент Иванов изучает учебную дисциплину ‘Базы данных’» выражает связь экземпляров объектов СТУДЕНТ и УЧЕБНАЯ ДИСЦИПЛИНА. Очевидно, не только этот студент изучает эту дисциплину, и этот студент изучает не только эту дисциплину. Поэтому можно говорить о связи (отношении) объектов СТУДЕНТ и УЧЕБНАЯ ДИСЦИПЛИНА, выражаемой глаголом ‘изучать’.
Концептуальная модель ПО есть формальное описание объектов, их свойств и отношений.

Контроль целостности домена

. Правило целостности домена должно проверяться при любой попытке ввода/обновления значения любого атрибута, определенного на этом домене. Для того чтобы РСУБД могла это делать, правило должно быть сформулировано в виде предиката и связано с доменом специальным предложением ЯОД – предложением объявления домена (см. п. 2.4.1). Обрабатывая это предложение, система вносит в свой каталог имя домена и реализует процедуру вычисления значений предиката. Процедура связывается с именем домена и сохраняется для дальнейшего исполнения.
Атрибут связывается со своим доменом строкой предложения определения базового отношения (см. п. 2.4.2.). Это определение также сохраняется в системном каталоге. При попытке присваивания атрибуту значения в новом или существующем кортеже система находит по каталогу имя соответствующего домена и вычисляет значение связанного с ним предиката на новом значении атрибута. Если предикат принял значение .F., обновление отвергается.

Контроль целостности сущности

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

Контроль ссылочной целостности

. Требование ссылочной целостности накладывает ограничения на все три операции обновления БД (см. табл. 2.1). Рассмотрим эти ограничения.
Операция
INSERT. Эта операция затрагивает только одно отношение. Если вставляется кортеж в отношение, не являющееся потомком ни в какой связи, то ссылочная целостность не может быть нарушена. Просто в БД появится новый кортеж, на который нет ссылок.
Если добавляется кортеж в отношение-потомок, то ссылочная целостность может быть нарушена. Кортеж можно включить в БД, если содержащееся в нем значение внешнего ключа принадлежит существующему в настоящий момент множеству значений родительского ключа. В РСУБД должна быть системная процедура проверки, подобная процедуре контроля целостности сущности. Она должна вызываться автоматически при любой попытке вставить кортеж в отношение-потомок. Входными данными для нее являются имя ссылочного отношения и значение набора атрибутов внешнего ключа. Процедура возвращает значение .F., если вводимое значение набора атрибутов внешнего ключа потомка не существует в текущем множестве значений первичного ключа родителя.
Процедура связывается с конкретным отношением в процессе обработки строки определения внешнего ключа в предложении определения отношения (см. п. 2.2.4.2). В соответствующий раздел системного каталога заносятся имя ссылочного отношения и перечень атрибутов, входящих в состав внешнего ключа потомка. Попытка выполнения операции INSERT всегда инициирует эту процедуру. Обновление отвергается, если процедура возвратила значение .F.
Операции DELETE и UPDATE. Удаление кортежа отношения, не являющегося ссылочным ни для какого другого, не может привести к нарушению ссылочной целостности. Так, в нашей БД «Поставщик-Деталь-Изделие» мы можем удалить без всяких последствий любой кортеж отношения SPJ.
Однако, если мы попытаемся удалить из отношения S какой-то кортеж, на который есть ссылка в SPJ, то это приведет к проблеме.
Пусть есть в S кортеж
‘S1’, ‘Иван’, 150, ‘Яя’,
а в
SPJ
– кортеж

‘S1’, ‘P3’, ‘J12’ 1000.

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

останется кортеж, содержащий значение ‘S1’, которого нет во множестве значений S.S#.

Аналогичная ситуация возникает при попытке обновить значение ссылочного ключа. Если понадобится изменить в S значение ‘S1’ на ‘S11’, то что делать с соответствующим значением SPJ. S#

?

Существует, по крайней мере, две возможности.

· Отложить удаление/обновление ссылочного ключа до тех пор, пока в БД не останется ни одного ссылающегося на него значения внешнего ключа. Кортеж из S, содержащий значение S.S# = ‘S1’, может быть удален только после того, как в SPJ

не останется ни одного кортежа, содержащего значение SPJ.S# = ‘S1’.

· Каскадировать удаление/обновление, т.е. удалить или обновить значение внешнего ключа во всех кортежах, ссылающихся на удаляемый/обновляемый родительский ключ. Например, удалить кортеж со значением S.S# = ‘S1’ и все кортежи SPJ со значением SPJ.S# = ‘S1’.

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

отношения – ссылочное и ссылающееся.

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

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

Мы говорили о двух видах триггеров ссылочной целостности – ОТЛОЖИТЬ и КАСКАДИРОВАТЬ. Они наиболее часто используются на практике, поэтому РСУБД обычно имеют системные триггеры отложенного и каскадного удаления/обновления. Но возможные варианты действий не ограничиваются этими правилами.

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

Например, система может:

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

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

· удалить ссылающиеся кортежи из отношения-потомка и занести их в некое архивное отношение и т.п.

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

Например, пусть R1, R2, R3

– связанные отношения: R3 ® R2 ® R1. Для R2 определено каскадное удаление. Сделана попытка удаления кортежа R1, на который есть ссылки в R2. Следует удалить все кортежи R2, ссылающиеся на удаляемый кортеж R1. Однако на эти кортежи есть ссылки в R3. Если для R3 также установлено правило каскадного

удаления, то операция будет выполнена «лавиной». Если же для R3 определено отложенное удаление, то операция удаления из R2 не может быть выполнена, и, следовательно, не может быть выполнена операция удаления из R1.

Операции удаления/обновления всегда атомарны.

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

Лексические соглашения

Лексические соглашения
Для того чтобы обеспечить наглядность и читаемость диаграмм, стандарт IDEF1X рекомендует придерживаться ряда соглашений относительно построения имен и фраз на диаграммах.
4.9.1 Имена. В именах сущностей и атрибутов используются только буквы, цифры, а также знаки–разделители: «дефис», «подчерк» и «пробел». Имя должно начинаться с буквы. Части составного имени отделяются дефисом, подчерком или пробелом. Эти разделители не различаются.
Рекомендуется имена сущностей на диаграммах и в текстах глоссариев и замечаний всегда писать ПРОПИСНЫМИ буквами.
Например, глоссарий может содержать такое определение имени ПОСТАВЩИК: «Юридическое лицо, заключившее с фирмой договор на поставку одного или нескольких видов ДЕТАЛей для одного или нескольких видов ИЗДЕЛИй «.
Это определение содержит сведения не только о смысле, но и о связях определяемой сущности с другими сущностями ПО. Выделение имен этих сущностей регистром облегчает зрительное восприятие фактов связи.
Помимо вышеперечисленных разделителей в именах используются еще «×« и «/». Точка отделяет имя роли от основного имени атрибута. Имя роли предшествует точке, основное имя следует за точкой. Ни перед, ни после точки не допускаются другие разделители. Слэш разделяет разнонаправленные имена связи. Кроме того, он разделяет имя сущности или связи и его идентификатор.
4.9.2 Идентификаторы. Стандарт рекомендует назначать именам сущностей и связей уникальные идентификаторы. За идентификатор обычно принимают порядковый номер сущности или связи в порядке появления объекта на диаграмме. Обычно присваиваются идентификаторы вида «Е<число>« сущностям и «R<число>« - связям.
4.9.3 Метки атрибутов. Метки атрибутов размещаются вслед за именем атрибута в круглых скобках. Допускаются следующие метки:
(О) – атрибут может принимать NULL-значения;
(FK) – внешний ключ;
(AK) – атрибут N-го альтернативного ключа;
(<число>) – ссылка на примечание.
Метки (О) и (АК) не могут использоваться вместе, т.е. комбинация вида «дата (АК1) (О)» недопустима. Других ограничений на комбинации значений меток нет.

Методологии семантического подхода

. В настоящее время существует несколько методологий анализа и проектирования логического макета БД, реализующих семантический подход. Основным компонентом любой из них является графический язык определения данных – система графических нотаций для основных понятий ER-модели. Этими средствами проектировщик может точно, ясно и наглядно сформулировать свои текущие представления о ПО в виде диаграмм. Второй компонент – глоссарий, содержащий однозначные определения имен сущностей и атрибутов. Он раскрывает те аспекты модели, которые невозможно отразить графическими средствами. Методологии различаются, в основном, нотациями графических языков определения данных и обладают рядом общих достоинств.
Во-первых, все они поддерживают параллельное развитие анализа ПО и проектирования структуры БД и правил целостности данных. Нет никакой необходимости выявлять весь перечень хранимых данных и правил бизнеса еще до начала проектирования. Для выделения базовых отношений не нужно использовать громоздкие и сложные процедуры нормализации универсального отношения.
Во-вторых, простота нотаций графических языков, строго определенные правила именования сущностей, атрибутов и связей, а также содержащиеся в глоссарии определения имен обеспечивают точную передачу представлений автора модели и однозначную (и одинаковую!) понимаемость модели всеми участниками разработки – аналитиками, экспертами и проектировщиками структур хранения данных.
В-третьих, строго определенная иерархия уровней модели открывает возможность согласования представлений аналитика с представлениями конечных пользователей системы на всех этапах разработки.
В-четвертых, в настоящее время существует несколько десятков товарных CASE-систем (Computer Aided System Engineering), поддерживающих семантические методологии на всех этапах жизненного цикла системы от формулировки замысла до выпуска проектной документации. Многие из них обеспечивают отображение окончательных диаграмм модели на физические структуры данных распространенных СУБД, а также создание триггеров ссылочной целостности, как стандартных, так и оригинальных.
В силу указанных причин использование семантического подхода значительно снижает трудозатраты на ранних этапах проектирования системы, упрощает и облегчает верификацию моделей и обеспечивает создание высококачественных спецификаций систем баз данных.
Далее в настоящей главе изложены основы методологии информационного моделирования IDEF1X (Integrated DEFinitions 1 eXpanded), имеющей в настоящее время статус федерального стандарта США. Предполагается, что читатель усвоил материал пп. 1.4, 2.1 – 2.3.

На концептуальном уровн

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

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

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

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

Вариант 1		Вариант 2

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

Рис. 1.4 Данные вокруг ПП
В первом варианте неизбежна неконтролируемая избыточность. Данным нельзя доверять и ими невозможно управлять как общим ресурсом предприятия.
Во втором варианте избыточности нет, но возникает ряд проблем проектирования и развития системы. Главная из них состоит в том, что если прикладной программист изменит структуры файлов своей ПП, скажем, с целью повышения эффективности программы, то придется переписать все ПП, использующие эти файлы. Прикладные программы оказываются взаимно зависимыми в этом смысле.
Вариант «ПП вокруг данных» (рис. 1.3) лишен этих недостатков. Здесь нет ни неконтролируемой избыточности, ни взаимной зависимости ПП. Однако, если ПП получают доступ к данным непосредственно от ОС, то возникает проблема зависимости ПП от данных. Подробное обсуждение этой проблемы можно найти в [1]. Здесь излагается только ее суть. Начнем с определения терминов.
Данные, хранящиеся во внешней памяти, будем называть хранимыми. Наименьшая (логическая) единица хранимых данных называется хранимым полем. Обычно во внешней памяти размещается много экземпляров
хранимых полей, т.е. значений поля.
Поле имеет имя и тип. Хранимые поля объединяются в хранимые записи. Хранимая запись – это набор связанных хранимых полей.
Например

номер детали	наименование	вес	– тип хранимой записи
‘P12’	‘шайба’	0,1	– экземпляр записи

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

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

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

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

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

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

· Для удовлетворения новым стандартам или требованиям защиты, или с целью экономии внешней памяти и т.д. может понадобиться: изменить представление числовых данных – форму, основание системы счисления, масштаб, тип, точность и т.д.; изменить кодировку символов (ASCII – EBCDIC); ввести кодирование данных.

Требование независимости ПП и данных состоит в том, что все эти изменения не должны быть видны

прикладным программам.

Нормальная форма Бойса – Кодда

(НФБК). Предположим, что в нашей ПО не может быть двух поставщиков с одинаковыми именами, и представим себе, что «учебную» БД проектировал малоопытный проектировщик, создавший отношение со схемой SSPJ(S#, Sn, P#, J#, Dt, Qt). Оно имеет два потенциальных ключа: {S#, P#, J#, Dt} и {Sn, P#, J#, Dt} и находится в 3НФ, так как единственный неключевой атрибут неприводимо зависит от каждого из них. Тем не менее, возможно избыточное дублирование данных.

S#	Sn	P#	J#	Dt	Qt
S1	Иван	P1	J1	...	1000
S1	Иван	P2	J1	...	1000
S1	Иван	P3	J1	...	2000
S2	Петр	P8	J4	...	1000

Для того чтобы изменить имя поставщика S1
нужно перебрать все кортежи со значением S# = S1. Если мы удалим кортеж S2, то потеряем информацию об имени поставщика. Это следствие наличия ФЗ S# ® Sn между атрибутами, входящими в состав различных потенциальных ключей. Отношение имеет детерминанты, не являющиеся потенциальными ключами. Для устранения аномалий следует декомпозировать отношение SSPJ. Возможны два варианта декомпозиции без потерь информации:
1) SS(S#, Sn)       SPJ(S#, P#, J#, Dt, Qt);
2) SS(S#, Sn)       SNPJ(Sn, P#, J#, Dt, Qt).
Отметим, что отношение SS в обоих вариантах имеет два возможных ключа, но при его обновлении не могут возникать аномалии.
Говорят, что отношение находится в нормальной форме Бойса – Кодда, если и только если каждый его детерминант является потенциальным ключом[30].
Если отношение не находится в НФБК, то его всегда можно представить в виде набора проекций, находящихся в НФБК. Но эта декомпозиция не всегда может быть выполнена без потерь информации. Проекции могут оказаться зависимыми в том смысле, что при обновлении одной из них придется обновить и другую.
Пример.
Пусть в отношении СДП(студент, дисциплина, профессор) существуют следующие ФЗ:
профессор ® дисциплина,
{студент, дисциплина} ® профессор,
{студент, профессор} ® дисциплина.
Отношение находится в 3НФ, но не в НФБК, так как имеет три детерминанта: {студент, дисциплина}, {студент, профессор}, {профессор}, а потенциальными ключами являются только два первых.

Возможны три варианта декомпозиции отношения СДП.

Вариант 1.

СП(студент, профессор);           ПД(профессор, дисциплина).

Первичными ключами проекций являются подмножества {студент, профессор} и {профессор}. Существует ФЗ профессор ® дисциплина и выводимая из нее ФЗ {студент, профессор} ® дисциплина. Тело естественного соединения проекций СП

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

СДП
студент	дисциплина	профессор
Иванов	математика	Комов
Иванов	физика	Липов
Петров	математика	Комов
Петров	физика	Дубов

Его проекции таковы:

СП		ПД
студент	профессор	профессор	дисциплина
Иванов	Комов	Комов	математика
Иванов	Липов	Липов	физика
Петров	Комов	Дубов	физика
Петров	Дубов

Если мы попытаемся добавить в СП кортеж {Петров, Липов}, то будет нарушено требование целостности сущности для отношения СПД. Петров уже изучает физику у Комова. Таким образом, при обновлении СП мы должны выяснить, что преподает новый (для Петрова) профессор Липов, а что преподают Дубов и Комов, встречающиеся в СП

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

Вариант 2.

СД(студент, дисциплина); ПД(профессор, дисциплина).

Вариант 3.

СП(студент, профессор); СД(студент, дисциплина).

В каждой декомпозиции утеряна одна из ФЗ, существующих в исходном отношении. Кроме того, восстановить исходное отношение посредством естественного соединения проекций невозможно.Убедитесь в этом сами.

Нормальные формы отношений

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

Объединение отношений

Объединение отношений. Пусть отношения R1 и R2 совместимы по объединению. Отношение R называется объединением отношений R1
и R2, если его схема эквивалентна схемам операндов, а тело составлено из всех кортежей, принадлежащих хотя бы одному из операндов.
R = R1
È R2 = {SR : R ( ) = R1
( ) = R2 ( ), SR Î R1
Ú
SR Î R2}.

Пример:

R1 =

R2 =

, R1 È R2 =

Объявление домена

. Домен на самом деле есть то, что в современных языках программирования называется «тип данных, определенный пользователем». К сожалению, большинство современных СУБД не поддерживает домены как объекты БД.
Определение домена может выглядеть так:
CREATE DOMAIN имя-домена тип [(длина)]
{FOR ALL имя-домена (предикат)}|
{VALUES (список)};
Здесь имя-домена
– уникальное имя, под которым домен будет известен системе и на которое можно ссылаться в определениях отношений;
тип – один из поддерживаемых системой встроенных типов данных;
длина
– длина поля данных в байтах;
предикат
– логическое выражение, использующее имя-домена в качестве переменной;
список
– список значений, разделенных запятыми.
Эта декларация объявляет системе, что она должна внести в свой каталог имя нового объекта – домена, и указывает ограничения на значения, принадлежащие домену. Определение сохраняется в системном каталоге. При любой попытке обновления значения какого-либо атрибута, определенного на этом домене, будет вычислено значение предиката. Если оно окажется равным .F., обновление будет отвергнуто.
Пример 1.
CREATE DOMAIN день CHAR (2)
FOR ALL день (
день = ‘пн’ OR
день = ‘вт’ OR
день = ‘ср’ OR
день = ‘чт’ OR
день = ‘пт’ );
Это же можно записать короче:
CREATE DOMAIN день CHAR (2)
VALUES(‘пн’, ‘вт’, ‘ср’, ‘чт’, ‘пт’);
Если, скажем, в ИС банка на этом домене определен атрибут рабочий день, то система сможет заблокировать выполнение банковских операций по субботам и воскресеньям.
Пример 2.
CREATE DOMAIN вес INTEGER
FOR ALL вес (вес ³ 10 AND вес £ 150 AND mod(вес, 5) = 0);
Каждый атрибут, определенный на этом домене, может принимать целочисленные значения в интервале [10, 150], причем только такие, которые делятся на 5 без остатка.
Если есть возможность создать домен, должна быть и возможность удалить его. Следующая команда
DESTROY DOMAIN имя-домена;
удалит из системного каталога определение домена. Она будет исполнена, если в схеме БД нет ни одного атрибута, определенного на удаляемом домене.
Если система поддерживает домены, то в ней есть возможность выполнения запросов, основанных на доменах. Например, запрос
Какие отношения в БД содержат какую-либо информацию о весе?
в терминах доменов имеет вид:
Какие отношения в БД включают атрибуты, определенные на домене Вес?
Это запрос к системному каталогу. В системе, не поддерживающей домены, такие сведения практически невозможно получить.

Объявление отношения

. Можно говорить о переменной-отношении, заданной схемой отношения, и о значении отношения, существующем в БД в конкретный момент времени (см. п. 2.2.4). Определять следует только схему, т.е. переменную. Значения отношения формируются системой в процессе выполнения запросов пользователей.
В реляционной БД всегда существует несколько основных видов отношений.
· Именованное отношение – это отношение, имя и определение схемы которого сохранены в системном каталоге. Именованное отношение может быть базовым или производным.
· Производное отношение есть отношение, определенное посредством реляционного выражения (см. пп. 2.5, 2.6) через именованные отношения. Производное отношение может быть именованным или неименованным.
· Базовое отношение – именованное отношение, не являющееся производным.
Любое производное отношение, в конце концов, выражается через базовые. Поэтому средства явного определения схемы нужны только для базовых отношений.

Объявление реляционных объектов

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

Область определения

. Переменная-кортеж t определяется фразой:
RANGE OF t IS X1, X2, …, Xn;
где t– имя переменной-кортежа;
Xi – имя отношения или выражение исчисления кортежей.
Все Xi должны быть совместимы по объединению. Переменная t принимает значение на объединении X1 È X2
È… È
Xn.
Обычно список элементов области определения – это одно отношение. Например, предложение
RANGE OF SX IS S;
указывает область определения переменной SX
– отношение S.
Вот более сложный случай.
RANGE OF SPJX IS SPJ;
RANGE OF SY IS (SX) WHERE SX.Ci = ‘Яя’,
(SX) WHERE
EXISTS SPJX (SPJX.S# = SX.S#
AND SPJX.P# = ‘P1’);
Переменная SY принимает значения на множестве кортежей отношения S, относящихся к поставщикам, расположенным в Яе или поставляющим деталь Р1.

Обозначения

.1 Обозначения. Под сущностью в IDEF1Х понимается отношение. Сущности изображаются на диаграммах именованными прямоугольниками, в которые вписываются имена атрибутов. Используемые обозначения определены на рис. 4.1.

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

Общая характеристика модели

Общая характеристика модели
Реляционная модель данных (РМД) состоит из трех частей – структурной, целостностной и манипуляционной[8].
· Структурная часть ставит в соответствие концептуальным понятиям, введенным в п. 1.4, строго определенные математические объекты – реляционные структуры данных. Она является абстрактным языком описания данных.
· Целостностная часть определяет правила, которым должны подчиняться хранящиеся в реляционных структурах непротиворечивые правдоподобные данные.
· Манипуляционная часть определяет абстрактные языки манипулирования данными в реляционных структурах на уровне множеств.
РМД поддерживает только концептуальный уровень представления данных (см. п. 1.3.3).
Все понятия структурной и целостностной частей РМД используются в современных графических ЯОД
(см. гл.4) – входных языках компьютерных систем автоматизированного проектирования баз данных. Многие понятия РМД положены в основу SQL – входного языка современных коммерческих СУБД, обеспечивающего управление данными в БД на концептуальном уровне.
Модель предложена американским математиком Е. Коддом в 1970 году. За три десятилетия она претерпела некоторые изменения. Здесь, в основном в соответствии с [1], изложены современные представления. Определения реляционных ЯОД и ЯМД ориентированы на гипотетическую СУБД, поддерживающую все реляционные возможности. Следует иметь в виду, что ни одна коммерческая СУБД, называемая «реляционной», не поддерживает РМД в полном объеме. Однако тенденции развития этих систем таковы, что можно надеяться на появление «настоящих» реляционных СУБД (РСУБД) в недалеком будущем.

Общая характеристика

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

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

[20] В любой реляционной БД имеется три типа операций обновления базовых отношений:
· INSERT – вставить кортеж в отношение;
· DELETE – удалить кортеж из отношения;
· UPDATE – обновить значение атрибута(ов) в кортеже.
Таблица 2.1 показывает, какие типы ограничений целостности могут ими нарушаться.
Таблица 2.1-
Возможные нарушения ограничений целостности

	Целостность домена	Целостность сущности	Ссылочная целостность
INSERT	ДА	ДА	ДА
DELETE	НЕТ	НЕТ	ДА
UPDATE	ДА	ДА	ДА

Таким образом, выполнение операций INSERT и UPDATE должно сопровождаться (в общем случае) проверками всех трех типов правил целостности. При выполнении операции DELETE
необходимо проверять только ссылочную целостность. Будем считать, что наша гипотетическая РСУБД имеет модуль контроля обновлений, инициируемый любой из команд – INSERT, UPDATE или DELETE, и запускающий нужные процедуры контроля целостности.

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

.
Поскольку отношения – это множества, то операции РА основаны на теоретико-множественных операциях. Однако отношения – множества с особыми свойствами, поэтому в РА входят также специфические операции, которые могут быть определены только на множествах отношений. Выделяют две группы операций РА.
Теоретико-множественные операции:
· объединение;
· разность;
· пересечение;
· расширенное прямое произведение.
Специальные реляционные операции:
· переименование;
· селекция (ограничение, выборка);
· проекция;
· соединение по условию;
· естественное соединение;
· взятие реляционного частного (реляционное деление).
Этот набор операций избыточен, так как некоторые из них выражаются через другие. Тем не менее, все они включаются в состав алгебры как элементарные, исходя из интуитивных потребностей пользователей БД. В этом подразделе приведены формальные определения операций, а в следующем – синтаксис абстрактного языка РА.
Специфика отношений накладывает ограничения на операции. Так, операндами операций объединения, взятия разности
и пересечения могут быть только отношения с эквивалентными схемами.
Определение 1.
Говорят, что отношения R1
и R2 совместимы по объединению, если R1( ) = R2( ).
Операндами операции расширенного прямого произведения могут быть только отношения с непересекающимися схемами.
Определение 2.
Говорят, что отношения R1
и R2 совместимы по взятию расширенного прямого произведения, если
R1( ) Ç
R2( ) = Æ.

Операция подведения итогов

. Это также унарная операция. Ее синтаксис определим так:

подведение-итогов ::= SUMMARIZE терм BY (список) ADD
агрегатное-выражение AS атрибут1;

Здесь список – список атрибутов, по которым производится группирование;
агрегатное-выражение
– скалярное выражение, возвращающее единственное значение для группы кортежей;
атрибут – атрибут схемы производного отношения, определенный на значениях агрегатного-выражения.
Операция SUMMARIZE значительно сложнее операции EXTEND. Поясним ее действие. Пусть R – отношение со схемой, содержащей атрибуты A1, A2, ..., An, по которым нужно подвести итог. Выражение
SUMMARIZE R BY (A1, A2, ..., An) ADD exp AS Z;
произведет безымянное отношение со схемой {A1, A2, ..., An, Z}. Тело этого отношения будет содержать все кортежи проекции отношения R на атрибуты A1, A2, ..., An, дополненные значениями атрибута Z. Значение атрибута Z в кортеже t производного отношения является значением выражения exp. Оно вычисляется на подмножестве всех таких кортежей отношения R, в которых значения атрибутов A1, A2, ..., An совпадают со значениями соответствующих атрибутов в t. Концептуально эту процедуру можно представить как формирование групп кортежей R с одинаковыми значениями атрибутов A1, A2, ..., An
и вычисление значения exp для каждой группы.
Выражение exp содержит ссылки на агрегатные функции, возвращающие скалярные значения, вычисленные для группы кортежей операнда. Имеет смысл ввести такие агрегатные функции, которые выполняют вычисления, часто встречающиеся при подведении итогов:

COUNT		число значений атрибута;
SUM		сумма значений атрибута;
AVG		среднее арифметическое значений атрибута;
MAX		максимальное значение атрибута;
MIN		минимальное значение атрибута.

Пример:
SUMMARIZE SPJ BY (S#, P#) SUM(Qt) AS Tot_Qt;
Это выражение производит отношение со схемой {S#, P#, Tot_Qt}. Тело отношения для каждой пары значений {S#, P#}, встретившейся в SPJ хотя бы один раз, будет содержать ровно один кортеж с соответствующими значениями номера поставщика, номера детали и суммарного объема поставок этой детали этим поставщиком независимо от того, для каких изделий и когда он поставлял этот вид детали.

Операция расширения схемы

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

расширение
::= EXTEND терм ADD выражение AS атрибут[24];

Здесь выражение – любое скалярное выражение, ссылающееся на атрибуты терма.
Очевидны следующие ограничения:
1) схема терма не может содержать атрибута с именем, указанным после AS;
2) выражение не может ссылаться на атрибут.
Пример:
EXTEND (( P JOIN SPJ) ADD We*Qt AS Tot_We)
[SPJ#, Tot_We];
Это выражение произведет безымянное отношение со схемой {SPJ#, Tot_We}. Его кортежи будут содержать сведения о весах зарегистрированных поставок.

Оператор обновления значений атрибутов

. Синтаксис для этого оператора следующий:

UPDATE приемник список-присваиваний;
список-присваиваний ::= атрибут := скалярное-выражение \|
список-присваиваний, атрибут := скалярное-выражение

Здесь приемник
– любое реляционное выражение. Каждый атрибут из списка присваиваний принадлежит приемнику.
Все кортежи приемника обновляются в соответствии с указанным списком присваиваний.
Пример:
UPDATE (S WHERE Ci = ‘Яя’) St := St*10;
Будут обновлены значения атрибута St во всех кортежах отношения S, удовлетворяющих условию Ci = ‘Яя’.

Оператор удаления кортежей

. Оператор удаления кортежей имеет вид:

DELETE приемник;

Здесь приемник
– любое реляционное выражение.
Удаляются все кортежи целевого отношения, произведенного приемником.
Пример:
DELETE (S WHERE Ci = ‘Яя’);
Будут удалены все кортежи отношения S, содержащие сведения о поставщиках, размещенных в Яе.
Реляционные выражения, встречающиеся в операторах INSERT, UPDATE, DELETE, определяют область действия этих операторов. Как правило, эти выражения оказываются либо именами базовых отношений, либо подмножествами кортежей этих отношений. Однако, в принципе, они могут определять какую угодно часть БД.
Подчеркнем, что операции обновления действуют на уровне множеств кортежей. Даже когда обновляется один кортеж, на самом деле обновляется множество, состоящее из одного элемента. Иногда обновление одноэлементного множества невозможно.
Например, в нашей БД может существовать ограничение целостности: «Все поставщики из Яи имеют одинаковые статусы».
Тогда операция
UPDATE (S WHERE S# = ’S1’) St := 50;
не может быть выполнена на уровне одного кортежа, если поставщик S1 размещается в Яе и есть еще поставщики из Яи. Такая операция должна быть либо преобразована системой в операцию
UPDATE (S WHERE Ci = ‘Яя’) St := 50;
обновляющую все кортежи, соответствующие поставщикам из Яи, либо отвергнута в соответствии с определенным правилом целостности.

Оператор вставки кортежей

. Синтаксис для оператора вставки кортежей определим так:

INSERT источник INTO приемник;

Здесь приемник
и источник
– любые реляционные выражения, производящие отношения, совместимые по объединению.
Все кортежи источника вставляются в приемник.
Пример:
Пусть в схеме нашей БД определено отношение TEMP
со схемой {P#, TOTAL}. Оператор
INSERT ((SUMMARIZE SPJ BY (P#) SUM (Qt) AS TOTAL)
WHERE TOTAL > 10000) INTO TEMP;
вставит в отношение TEMP
все кортежи отношения, произведенного операцией SUMMARIZE.

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

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

Переименование атрибутов

. Эта операция вводится в состав операций РА для разрешения конфликтов имен в бинарных операциях. В реальных манипуляциях реляционными данными нередко возникает необходимость вычислить соединение по условию отношений с пересекающимися схемами или построить объединение отношений с «почти совпадающими» схемами, отличающимися только именами атрибутов и т.п.
Эта операция сохраняет тело отношения, изменяя лишь имена указанных атрибутов:
rА ®С (R (A, B)) = R (C, B).

Пересечение отношений

Пересечение отношений. Пусть отношения R1 и R2 совместимы по объединению. Отношение R называется пересечением отношений R1
и R2, если его схема эквивалентна схемам операндов, а тело составлено только из кортежей R1, принадлежащих R2.
R = R1
Ç R2 = {SR : R( ) = R1( ) = R2( ), SR Î R1
Ù
SR Î R2}.
Пример:

R1 =

R2 =

, R1 Ç R2 =

Это неэлементарная операция. Она представляется через операции объединения и разности:
R1 Ç R2 = R1 È R2 – (R1 – R2) È
(R2 – R1 ).

Первая нормальная форма

3.3.1 Первая нормальная форма (1НФ).
Говорят, что отношение находится в первой нормальной форме, если и только если все домены его атрибутов содержат скалярные значения.
Любое отношение РМД находится в 1НФ по определению (см. пп. 2.2.1, 2.2.3).
Рассмотренное выше отношение USPJ находится в 1НФ. Как мы видели, в таком отношении возможно избыточное дублирование данных и аномалии обновления. Некоторые его атрибуты могут функционально зависеть от части возможного ключа. Могут существовать ФЗ между атрибутами, не входящими в состав возможного ключа.

Поддержание целостности в РБД

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

Подходы к концептуальному моделированию

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

Понятие целостности данных

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

Понятия ER– модели и объекты РМД

. В п. 1.4 мы ввели понятия, используемые в концептуальном моделировании, на интуитивном уровне. В пп. 2.2.1, 2.2.3 приведены точные определения математических объектов, которые можно[13] поставить в соответствие этим понятиям. Рисунок 2.2 иллюстрирует это соответствие.

Рис. 2.2 Соответствие интуитивных понятий объектам РМД
Замечание 3. Отношение может соответствовать сущности или связи, но также и произвольному набору атрибутов.

Правила для атрибутов

.3 Правила для атрибутов.
Согласно стандарту, атрибут есть свойство или характеристика, общая для некоторых или всех экземпляров сущности. Атрибут является конкретизацией домена в контексте сущности.
· На диаграммах KB- и FA-уровней каждая сущность имеет не менее одного атрибута. Каждый атрибут может быть собственным атрибутом сущности или присоединенным (мигрировавшим), полученным от другой сущности через связь.
· Каждый атрибут является собственным атрибутом точно одной сущности.
· Присоединенный атрибут должен быть частью первичного ключа передавшей его сущности (родительской или родовой). Присоединенный атрибут помечается символом «(FK)», следующим за именем атрибута.
В совокупности эти требования означают, что никакие две сущности не могут иметь одноименных атрибутов, если они не связаны каким-либо отношением. В последнем случае одноименными могут быть атрибуты, которые являются частью первичного ключа родителя и частью внешнего ключа потомка.
· Каждый экземпляр сущности должен иметь определенное значение каждого атрибута, являющегося частью первичного ключа (см. п. 2.3.5.2).
· Не может быть экземпляра сущности, имеющего более чем одно значение какого-либо из атрибутов (см. п.3.3).
· Атрибуты, не являющиеся частью первичного ключа, могут иметь неопределенные значения. Для ясности такие атрибуты помечаются символом «(О)», следующим за именем атрибута (Optional – необязательный).
· Если атрибут является собственным атрибутом одной сущности и присоединенным атрибутом другой, то либо он имеет одинаковые имена в обеих сущностях, либо помечается именем роли (см. п. 4.6), как присоединенный.
· Определение атрибута должно содержать ссылку на имя домена (см. п. 2.3.5.1).
На KB-диаграммах показываются только атрибуты, входящие в состав первичных, альтернативных и внешних ключей. Атрибуты альтернативных ключей обязательно помечаются символом «(AKn)», где n - номер альтернативного ключа. Все атрибуты, входящие в состав одного и того же альтернативного ключа, помечаются одним и тем же значением n. На FA-диаграмме показываются все атрибуты каждой сущности.

Правила для категоризационных связей

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

Правила для первичных и альтернативных ключей

.
· На диаграммах КВ- и FA- уровней каждая сущность должна иметь первичный ключ.
· Сущность может иметь несколько альтернативных ключей.
· Как первичный, так и альтернативный ключ может быть либо одиночным атрибутом, либо группой атрибутов.
· Отдельный атрибут может быть частью более чем одного ключа, первичного или альтернативного.
· Атрибуты, входящие в первичный и альтернативный ключи, могут быть как собственными атрибутами сущности, так и присоединенными через связь с другой сущностью.
· Первичный и альтернативные ключи должны содержать только те атрибуты, которые необходимы для уникальной идентификации экземпляров сущности.
· Каждый неключевой атрибут должен неприводимо зависеть от первичного ключа, если он составной (см. п. 3.3.2).
· Каждый атрибут, не являющийся частью первичного ключа или какого-либо из альтернативных, должен функционально зависеть только от первичного ключа и каждого из альтернативных (см. п. 3.3.4).
Правила для внешних ключей.
· Каждая сущность, являющаяся потомком в специфической связи или категорией в категоризационной связи, должна содержать множество атрибутов – внешних ключей, переданных связью. Конкретный атрибут может быть элементом нескольких таких множеств. Число атрибутов в каждом множестве внешних ключей должно совпадать с числом атрибутов первичного ключа родительской или родовой сущности.
· Первичный ключ родовой сущности должен передаваться как первичный ключ каждой категории.
· Потомок не может содержать двух полных внешних ключей, которые соотносят с каждым его экземпляром один и тот же экземпляр одного и того же предка, если эти внешние ключи не переданы через различные пути связей, включающие по крайней мере одну промежуточную сущность между этим предком и потомком.
· Каждый присоединенный атрибут потомка или категории должен быть атрибутом первичного ключа связанной с ним родительской или родовой сущности. Обратно, каждый атрибут первичного ключа родительской или родовой сущности должен быть присоединенным атрибутом связанного с нею потомка или категории.
· Каждое имя роли, назначенное присоединенному атрибуту, должно быть уникальным, и в одно и то же имя всегда должен вкладываться один и тот же смысл. Один и тот же смысл не может вкладываться в разные имена, если они не являются псевдонимами.
· Присоединенный атрибут может быть частью более чем одного множества внешних ключей при условии, что он имеет одно и то же значение в этих множествах в некотором фиксированном экземпляре сущности. Такому присоединенному атрибуту может быть назначено имя роли.
· Каждый внешний ключ должен ссылаться на один и только один атрибут первичного ключа родителя.
4.7.3 FA - уровень. Диаграмма FA-уровня должна содержать все, что содержит диаграмма КВ-уровня и, кроме того, все неключевые атрибуты. На КВ- и FA-уровнях в полной мере действуют все правила синтаксиса, изложенные выше.
Все сущности на FA-диаграмме должны находиться по крайней мере в 3НФ.

Правила именования и определения

.2 Правила именования и определения.
Здесь перечислены только основные правила стандарта IDEF1X. Полностью они приведены в [11].
· Сущности, атрибуты и домены обязательно именуются. Именем может быть только имя существительное, возможно с определениями. В качестве имен допускаются аббревиатуры и акронимы.
· Имя должно быть уникальным и осмысленным. Формальное определение имени обязательно включается в глоссарий модели.
Создавая модель, проектировщик стремится сформировать ясное представление о ПО, в частности, о том, какие сведения будут храниться в БД. Этого можно добиться, только сформулировав точные и однозначные определения смысла каждого имени, введенного в модель.
Например, что такое ДЕТАЛЬ? Это неделимая часть изделия, или она сама может собираться из других деталей? Может ли ИЗДЕЛИЕ быть ДЕТАЛЬю? Наша фирма только закупает ДЕТАЛи или может их производить?
Или что такое ФИЛЬМ? Это лента, лежащая в нашей фильмотеке, или это произведение киноискусства? Нас интересуют любые фильмы или только фильмы определенного жанра?
От ответов на эти вопросы зависит организация данных и их взаимосвязи. Поэтому, прежде чем строить диаграммы, необходимо получить точные ответы на все подобные вопросы и зафиксировать документально определения смысла имен. Без этого модель будет неоднозначной и противоречивой.
· Имя сущности, атрибута или домена должно иметь единственный смысл и этот смысл всегда должен выражаться этим именем. Тот же смысл не может вкладываться в другое имя, если оно не является псевдонимом или синонимом основного.
Например, атрибут дата не может иметь смысл даты начала ИЛИ
окончания отчетного периода. Совершенно непонятно, как интерпретировать значения этого атрибута в различных кортежах отношения.
· Сущности и атрибуты всегда именуются в единственном числе. Имя должно относиться к одному экземпляру сущности или значению атрибута.
Соблюдение этих правил обеспечивает интерпретацию диаграмм фразами естественного языка и точную передачу смысла, вложенного в имена автором модели.

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

. Как видно из определения, ППФ – это предикат первого порядка.
Примеры простых предикатов:
SX.S# = SPJX.S#;
SX.S# = ‘S1’;
SX.S# = SPJX.S# AND SPJX.P# = ‘P1’;
NOT (SX.Ci = ‘Яя’);
IF SX.Ci = ‘Яя’ THEN SPJX.S# = ‘S1’;
Последний предикат – пример намеренно бессмысленного, но синтаксически правильного высказывания.
Правильно построенная формула может содержать кванторы EXISTS (существует) и FORALL (для всякого).
Выражение EXISTS SX (SX.Ci = ‘Яя’) может быть прочитано так: «Существует в области определения переменной SX кортеж со значением атрибута Ci равным ‘Яя’». Предикат принимает значение .T., если в текущем значении отношения S есть хотя бы один кортеж со значением Ci = ‘Яя’.
Вообще говоря, если R
– некоторое отношение, t – переменная, определенная на R, t1, t2, …, tn
– значения t (кортежи R), a f(t)
– ППФ, то формула EXISTS t (f(t)) равносильна бескванторной формуле .F. OR f(t1) OR f(t2) OR … OR f(tn).
Выражение FORALL SX (SX. Ci = ‘Яя’) может быть прочитано так: «В каждом кортеже отношения S значение атрибута Ci равно ‘Яя’».
В предыдущих обозначениях формула FORALL t (f(t)) равносильна бескванторной формуле .Т. AND f(t1) AND f(t2) AND … AND f(tn). Очевидно, FORALL t (f(t)) равносильно NOT EXISTS t (NOT (f(t)).
Переменная t, входящая в ППФ, называется связанной
или свободной в зависимости от того, действует ли на формулу квантор по t.
Примеры:
f(t) – переменная t свободная;
f(t, q) – переменные t и q свободные;
EXISTS t (f(t, q)) – переменная t связанная, q – свободная;
FORALL
t (f(t)) AND g(t) - первое вхождение t – связанное, второе – свободное.
В последней формуле одним и тем же символом t обозначены разные переменные, возможно, определенные на одной и той же области. В первой подформуле можно изменить имя переменной, не меняя смысла высказывания и значения предиката. Переменная служит здесь лишь для связи внутренних параметров предиката f( ) с внешним квантором. Второе вхождение переменной t
имеет совершенно иной смысл. Здесь g(t)
принимает то или иное значение в зависимости от значения переменной t. Заменить t на x, например, здесь нельзя, поскольку х и t могут принимать различные значения.
Связанная переменная подобна локальной переменной в языках программирования.
Формула, в которой все переменные связаны, называется закрытой. Например, FORALL x (EXISTS y (f(x, y)))
– закрытая формула. Формула, содержащая по крайней мере одну свободную переменную, называется открытой.

Предикаты отношений и целостность данных

. Целостность данных может быть нарушена только при обновлении базовых
отношений (см. п. 2.4.2). Следовательно, с каждым базовым отношением должны быть связаны конкретные правила целостности. Система должна обеспечивать их соблюдение при каждой попытке обновления текущего значения любого базового отношения.
Всякое отношение имеет некоторую интерпретацию, передающую смысл представленных в нем данных. Эта интерпретация может быть сформулирована в виде предиката. Например, предикат отношения S в неформальной записи выглядит так:
«ПОСТАВЩИК с определенным номером S# имеет имя Sn и значение статуса St и располагается в городе Ci и нет двух ПОСТАВЩИКов с одинаковыми значениями S#».
Этот предикат принимает значение .Т. на тех кортежах, которые образуют тело отношения S в настоящий момент времени. Новый кортеж будет вставлен в тело только в том случае, если на нем предикат отношения принимает значение .Т. Таким образом, предикат есть критерий возможности (допустимости) обновления. В нашем примере кортеж будет вставлен, если
значение S# принадлежит домену S#           И
значение Sn принадлежит домену Sn           И
значение St принадлежит домену St         И
значение Ci принадлежит домену Ci          И
значение S# не встречается среди существующих в отношении S в настоящий момент.
Эти условия называются правилами целостности для отношения S. Именно их должна проверять система, добавляя кортеж в это отношение.
Рассмотрим теперь отношение SPJ. Его предикат (в неформальной записи) таков:
«ПОСТАВЩИК с номером S# поставил для ИЗДЕЛИя с номером J# ДЕТАЛЬ с номером P# в количестве Qt
И в отношении S существует кортеж со значением S.S# = S#
И в отношении P существует кортеж со значением P.P# = P#
И в отношении J существует кортеж со значением J.J# = J#
И нет двух ПОСТАВок с одинаковыми значениями {S#, P#, J#}».
В этой формуле есть ссылки на отношения S, P и J. Следовательно, ее значение должно вычисляться не только при добавлении кортежей в тело SPJ, но и при обновлении хотя бы одного из ссылочных отношений, затрагивающем множество значений родительского ключа.
Таким образом, правила целостности для ссылающихся отношений должны проверяться при обновлении ссылочных отношений. Только при этом условии может быть обеспечена целостность состояния БД. Правила реализуются в виде так называемых хранимых процедур (процедур базы данных). Эти процедуры связываются с соответствующими отношениями и хранятся в базе данных вместе с ними. Посмотрим, какие типы хранимых процедур необходимы для поддержания внутренних ОЦ.

Предложение объявления базового отношения

имеет вид:
CREATE BASE RELATION имя-отношения
(список-определений-атрибутов)
список-определений-возможных-ключей
список-определений-внешних-ключей;
Здесь список-определений ... – список разделенных запятыми строк определений соответствующих элементов схемы отношения.
Строка определения атрибута связывает имя атрибута с его доменом:
имя-атрибута
DOMAIN (имя-домена).
Указанный атрибут принимает значения на указанном домене.
Например, строка определения атрибута We
в предложении определения отношения P (см. рис. 2.3) может иметь вид:
We DOMAIN (вес),
где домен вес
определен в п. 2.4.1, пример 2.
Имена атрибутов должны быть уникальны, по крайней мере, в пределах отношения. Удобно, если имя атрибута совпадает с именем домена, на котором он определен.
Строка определения возможного ключа имеет две модификации:
PRIMARY KEY (список-атрибутов) |
CANDIDATE KEY (список-атрибутов)
Здесь PRIMARY KEY и CANDIDATE KEY объявляют, соответственно, первичный и альтернативный ключи отношения;
список-атрибутов
– список разделенных запятыми имен атрибутов, образующих ключ.
Например, первичный ключ отношения SPJ (см. рис. 2.3) будет объявлен строкой
PRIMARY KEY (S#, P#, J#, Dt),
а альтернативный ключ того же отношения – строкой
CANDIDATE KEY (SPJ#)
Строка определения внешнего ключа имеет вид:
FOREIGN KEY (список-атрибутов)
REFERENCES отношение
DELETE правило-удаления
UPDATE правило-обновления
Здесь список-атрибутов
– список разделенных запятыми имен атрибутов (составного) внешнего ключа, эквивалентный списку атрибутов родительского ключа;
отношение
– имя родительского отношения;
правило ...
следует понимать как ссылку на процедуру БД, реализующую определенное проектировщиком правило внешнего ключа для операции DELETE или UPDATE соответственно. Это может быть либо процедура пользователя, либо одна из стандартных процедур СУБД – Cascade (каскадировать) или Restrict (отложить).
Примеры.
Будем считать, что все необходимые домены определены, и приведем предложения определения схем отношений ПОСТАВЩИК и ПОСТАВКА.

Отношение ПОСТАВЩИК не содержит ни альтернативных, ни внешних ключей и определяется предложением

CREATE BASE RELATION S
( S#	DOMAIN	(S#),
Sn	DOMAIN	(Sn),
St	DOMAIN	(St),
Ci	DOMAIN	(Ci)
)
PRIMARY KEY (S#);

Определение отношения ПОСТАВКА имеет вид

CREATE BASE RELATION SPJ
( S#	DOMAIN	(S#),
P#	DOMAIN	(P#),
J#	DOMAIN	(J#),
Dt	DOMAIN	(Dt),
SPJ#	DOMAIN	(SPJ#),
Qt	DOMAIN	(Qt)
)
PRIMARY KEY (S#, P#, J#, Dt)
CANDIDATE KEY (SPJ#)
FOREIGN KEY (S#) REFERENCES S DELETE Restrict UPDATE Cascade
FOREIGN KEY (P#) REFERENCES P DELETE Restrict UPDATE Cascade
FOREIGN KEY (J#) REFERENCES J DELETE Restrict UPDATE Cascade;

Здесь кроме составного первичного ключа {S#, P#, J#, Dt} указан простой альтернативный ключ {SPJ#}, а также внешние ключи {S#}, {P#}, {J#}. Для внешних ключей определены правила отложенного удаления и каскадного обновления. Это означает, что удаление кортежа родителя не может быть выполнено, если в SPJ существует хотя бы один кортеж, ссылающийся на удаляемое значение родительского ключа. Удаление родительского кортежа произойдет автоматически после удаления последней ссылки на него. Если же пользователь изменит значение какого-либо родительского ключа, то во всех кортежах SPJ, ссылающихся на старое значение, произойдут соответствующие изменения.

Базовое отношение может быть уничтожено командой

DESTROY BASE RELATION имя-отношения;

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

Предметная область

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

Причины аномалий обновления данных

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

Пример простого внешнего ключа

. Это пример простого внешнего ключа, соответствующего простому же родительскому ключу.
Если родительский ключ составной, то ссылающийся на него внешний также составной. Например, пусть наша БД должна хранить сведения о том, какой служащий какие манипуляции с записями о поставках проделывал. Тогда схема БД может содержать фрагмент[19], показанный на рис. 2.4.

Рис. 2.4 Составной внешний ключ {S#, P#, J#}
Здесь отношение A_SPJ содержит составной внешний ключ {S#, P#, J#}, ссылающийся на первичный ключ {S#, P#, J#} отношения SPJ, и простой внешний ключ {Emp#}, ссылающийся на первичный ключ {Emp#} отношения Emp.
Замечание 7. Внешний ключ может полностью входить в состав возможного ключа отношения В, как в предыдущем примере, но может и не входить в него вообще или входить частично.
Например, пусть в нашей БД хранятся сведения о городах размещения поставщиков, деталей и изделий. Соответствующий фрагмент схемы БД показан на рис. 2.5. Здесь атрибуты отношений S, P, J, помеченные символом (FK), – внешние ключи, ссылающиеся на отношение Ct. Включать их в состав возможных (первичных) ключей отношений-потомков нет необходимости.

Рис. 2.5 Внешний ключ *.название не входит в состав первичного
ключа потомка
Замечание 8. Отношение может быть одновременно ссылочным и ссылающимся.
Так, на рис. 2.5 отношения S, P и J являются ссылочными для отношения SPJ и ссылающимися на отношение Сt.
Замечание 9. Отношение может ссылаться на себя, т.е. внешний ключ может быть потомком первичного ключа собственного отношения.
Например, в БД бюро ЗАГС может существовать отношение, показанное на рис. 2.6. Здесь атрибут номер паспорта - ссылочный ключ, а атрибут супруг.номер паспорта – ссылающийся на него внешний ключ.

Рис. 2.6 Унарная связь. Отношение ссылается на себя

Примеры запросов на языке РА

.
Сформулируем средствами РА несколько запросов к БД «Поставщик–Деталь–Изделие» (см. рис. 2.3). В формулировках запросов ненужные круглые скобки будем опускать.
1) Получить полные сведения обо всех производимых изделиях.
J;
2) Получить номера и названия изделий, производимых в Томске.
(J WHERE Ci = ‘Томск’) [J#, Jn];
3) Получить значения номеров поставщиков, выполняющих поставки для изделия J1.
(SPJ WHERE J# = ‘J1’)[S#];
4) Получить значения номеров поставщиков, поставляющих деталь Р1
для изделия J1.
(SPJ WHERE J# = ‘J1’ AND P# = ‘P1’)[S#];
5) Получить значения наименований изделий, для которых выполняет поставки поставщик S1.
(J JOIN (SPJ WHERE S# = ‘S1’))[Jn];
Другой возможный вариант формулировки:
(J[J#, Jn] JOIN (SPJ WHERE S# = ‘S1’)[J#])[Jn];
6) Получить значения цветов деталей поставляемых поставщиком S1.
(P JOIN (SPJ WHERE S# = ‘S1’))[Co];
7) Получить номера поставщиков, поставляющих детали для изделий J1 и J2.
(SPJ WHERE J# = ‘J1’)[S#] INTERSECT
(SPJ WHERE J# = ‘J2’)[S#];
8) Получить значения номеров поставщиков, поставляющих для изделия J1 красную деталь.
((SPJ WHERE J# = ‘J1’) JOIN (P WHERE Co = ‘красный’))[S#];
9) Получить значения номеров деталей, поставляемых для каждого изделия, производимого в Томске.
SPJ[P#, J#] DIVIDEBY (J WHERE Ci = ‘Томск’)[J#];
10) Получить значения номеров поставщиков, поставляющих красные детали для изделий, производимых в Томске или Яе.
((P WHERE Co = ‘красный’) JOIN SPJ
JOIN (J WHERE Ci = ‘Томск’ OR Ci = ‘Яя’))[S#];
11) Получить значения номеров изделий, снабжаемых по крайней мере одним поставщиком, расположенным не в том же самом городе.
(((J RENAME Ci AS JCi) JOIN SPJ JOIN (S RENAME Ci AS Sci))
WHERE NOT (JCi = SCi))[J#];
12) Получить значения номеров изделий, для которых не поставляется ни одной красной детали из Томска.
J[J#] MINUS ((P WHERE Co = ‘красный’ AND Ci = ‘Томск’)[P#])
JOIN SPJ)[J#];
13) Получить имена поставщиков, поставляющих деталь Р2.
(( SPJ JOIN S) WHERE P# = ‘P2’) [Sn];
14) Получить имена поставщиков, поставляющих все детали.
(( SPJ[S#, P#] DIVIDEBY P[P#]) JOIN S) [Sn];
15) Получить имена поставщиков, поставляющих все поставляемые детали.
(( SPJ[S#, P#] DIVIDEBY SPJ[P#]) JOIN S) [Sn];
Замечание. Нередко запросы бывают очень сложными, так что написать одно реляционное выражение очень трудно. В таких случаях удобно использовать оператор реляционного присваивания (:=
). С его помощью предыдущий запрос можно записать так:
T1 : = SPJ [S#, P#] ;
T2 : = SPJ [P#];
T3 : = T1 DIVIDEBY T2;
T4 : = T3 JOIN S;
T5 : = T4[Sn];
Здесь Ti понимаются как идентификаторы временных отношений, создаваемых системой. Схема каждого Ti совпадает со схемой отношения, произведенного выражением в правой части.

Примеры запросов

. Здесь приведены формулы РИ кортежей, эквивалентные выражениям РА из примеров п. 2.5.4. Номера формул соответствуют номерам запросов.
1)            RANGE OF JX IS J;
               JX;
Далее для упрощения записи будем считать, что переменные SX, PX, JX, SPJX определены на отношениях S, P, J, SPJ, соответственно. Если понадобится определить на отношении более одной переменной, будем расширять имя отношения другими буквами, например, SY, SZ… Ненужные скобки будем опускать.
2)            (JX.J#, JX.Jn) WHERE Ci = ‘Томск’;
3)            SPJX.S# WHERE J# = ‘J1’;
4)            SPJX.S# WHERE J# = ‘J1’ AND P# = ‘P1’;
5)            JX.Jn WHERE EXISTS SPJX
(SPJX.S# = ‘S1’ AND SPJX.J# = JX.J#);
6)            PX.Co WHERE EXISTS SPJX
(SPJX.S# = ‘S1’ AND SPJX.P# = PX.P#);
7)            SPJX.S# WHERE J# = ‘J1’ AND EXISTS SPJY
(SPJY.S# = SPJX.S# AND J# = ‘J2’);
8)            SPJX.S# WHERE SPJX.J# = ‘J1’ AND EXISTS PX
(PX.P# = SPJX.P# AND PX.Co = ‘красный’);
9)            SPJX.P# WHERE FORALL JX
(IF JX.Ci = ‘Томск’ THEN EXISTS SPJY
(SPJY.J# = JX.J# AND SPJY.P# = SPJX.P#));
Другая формулировка этого запроса, не использующая квантора всеобщности:
SPJX.P# WHERE NOT EXISTS JX
(JX.Ci = ‘Томск’ AND NOT EXISTS SPJY
(SPJY.J# = JX.J# AND SPJY.P# = SPJX.P#));
10)          SPJX.S# WHERE EXISTS PX
(PX.Co = ‘красный’ AND PX.P# = SPJX.P#) AND
EXISTS JX (JX.J# = SPJX.J# AND
(JX.Ci = ‘Томск’ OR JX.Ci = ‘Яя’));
11)          JX.J# WHERE EXISTS SPJX EXISTS SX
(JX.J# = SPJX.J# AND SX.S# =SPJX.S# AND
NOT (JX.Ci = SX.Ci) );
12)          JX.J# WHERE NOT EXISTS SPJX EXISTS PX
(SPJX.P# = PX.P# AND PX.Ci = ‘Томск’ AND
PX.Co = ‘красный’ AND SPJX.J# = JX.J#);
13)          SX.Sn WHERE EXISTS SPJX
(SPJX.P# = ‘P2’ AND SPJX.S# = SX.S#);
14)          SX.Sn WHERE FORALL PX (EXISTS SPJX
(PX.P# = SPJX.P# AND SPJX.S# = SX.S#));

. Здесь приведены формулы РИ доменов, эквивалентные выражениям РА из некоторых примеров п. 2.5.4. Номера формул соответствуют номерам запросов.
1)            RANGE OF JX IS J#;
RANGE OF JnX IS Jn;
RANGE OF CiX IS Ci;
(JX, JnX, CiX) WHERE J(J# : JX, Jn : JnX, Ci : CiX);
Далее будем опускать определения переменных.
2)            (JX, JnX) WHERE
J(J# : JX, Jn : JnX, Ci : ‘Томск’);
3)            SX WHERE SPJ(J# : ‘J1’);
4)            SX WHERE SPJ(J# : ‘J1’, P# = ‘P1’);
5)            JnX WHERE EXISTS JX (SPJ (S# : ‘S1’, J# : JX)
AND J(J# : JX, Jn : JnX));
6)            CoX WHERE EXISTS PX
(SPJ(S# : ‘S1’, P# : PX) AND
P(P# : PX, Co : CoX));
7)            SX WHERE SPJ(S# : SX, J# : ‘J1’) AND
SPJ(S# : SX, J# : ‘J2’);
Заметьте, что (в отличие от формулы исчисления кортежей) здесь не нужен квантор существования.
8)            SX WHERE EXISTS PX
(SPJ(S# : SX, P# : PX, J# : ‘J1’) AND
P(P# : PX, Co : ‘красный’));
9)            PX WHERE FORALL JX (IF J(J# : JX, Ci : ‘Томск’)                                 THEN SPJ(P# : PX, J# : JX));
Другая формулировка этого запроса, не использующая квантора всеобщности:
PX WHERE NOT EXISTS JX (J(J# : JX, Ci : ‘Томск’) AND                                     NOT SPJ(P# : PX, J# : JX));
Сравните эти формулировки с приведенными в пп. 2.5.4, 2.6.2. Большое количество задач такого типа приведено в [1], [7].
2.6.4 Резюме. Все три механизма манипулирования данными составляют основу реализаций реляционных ЯМД. Это непроцедурные языки. Они не предназначены для записи алгоритмов. Они предназначены для точного формулирования запросов к данным.
Самый распространенный язык запросов SQL основывается на смеси алгебраических и логических конструкций. Человек формулирует запрос в виде предиката, а система строит соответствующую процедуру вычисления требуемого результата.

Если нашим поставщикам присваиваются уникальные

· Если нашим поставщикам присваиваются уникальные номера и не может быть двух различных поставщиков с одинаковыми именами, то в любом кортеже отношения S значения атрибутов S# и Sn уникальны. Оба подмножества {S#} и {Sn} – неизбыточны. Следовательно, оба – потенциальные ключи.
· Если фиксируется только общее количество конкретного вида деталей, поставленное конкретным поставщиком для конкретного изделия, то потенциальным ключом отношения SPJ
является подмножество {S#, P#, J#}.
· Если нас интересуют сведения о поставках по датам поставок, то в схему отношения SPJ необходимо включить атрибут дата поставки
(Dt). В этом случае подмножество {S#, P#, J#} уже не будет обладать свойством уникальности. Потенциальным ключом будет четверка {S#, P#, J#, Dt}.
· Если поставкам присваиваются уникальные номера, то в схему отношения SPJ должен быть включен атрибут номер поставки
(SPJ#), вследствие чего оно приобретет еще один возможный ключ {SPJ#}.
Если потенциальный ключ содержит единственный атрибут, то он называется простым. В противном случае – составным.
Неизбыточность потенциального ключа не эквивалентна минимальности состава атрибутов. И {SPJ#}, и {S#, P#, J#, Dt} – потенциальные ключи несмотря на то, что в первом единственный атрибут, а во втором – четыре.
Если отношение имеет несколько возможных ключей, то один из них выделяется и помечается как первичный. Тогда все остальные возможные ключи называются альтернативными. Первичные ключи обеспечивают механизмы связи отношений (см. п. 2.3.3).
В качестве первичного может быть выделен любой возможный ключ. Это решение проектировщика. Однако важно подчеркнуть, что при анализе данных в процессе проектирования БД необходимо выявить и указать все потенциальные ключи каждого отношения. Только так можно обеспечить отражение в модели соответствующих бизнес-правил. С другой стороны, объявляя все возможные ключи, аналитик указывает проектировщику ФБД все обусловленные семантикой пути быстрого доступа к данным.

Принцип интегрированного хранения

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

Проекция

. Это также унарная операция. Она преобразует не только тело, но и схему отношения. Ее можно представить себе как вычеркивание столбцов таблицы.
Пусть R
– отношение со схемой R(A, B), А и B – подмножества атрибутов схемы. Проекцией отношения R на атрибуты А называется отношение Rp
= pA
(R), имеющее схему Rp(A), кортежами которого являются соответствующие схеме подкортежи отношения R.
Пример:

R =

, pA,C,F (R) =

Расширенное прямое произведение

Расширенное прямое произведение. Пусть отношения R1 и R2 совместимы по взятию расширенного прямого произведения. Отношение R называется расширенным прямым произведением
отношений R1 и R2, если его схема эквивалентна (теоретико-множественному) объединению схем операндов, а тело составлено из всех попарных (теоретико-множественных) объединений кортежей R1 и R2.
R = R1
´ R2 = {SR : SR = SR1 È
SR2, R() = R1() È R2(), SR1 Î R1, SR2 Î R2}.
Пример:

R1 =

R2 =

, R1 ´ R2 =

Реляционное деление

Реляционное деление. Пусть X и Y – подмножества атрибутов, R1
и R2 - отношения со схемами R1(X, Y), R2
(Y). Реляционным частным называется отношение R со схемой R(X), тело которого составляют все такие кортежи {X:x}, что {X:x, Y:y} Î R1 для каждого {Y:y} Î R2
.
R = R1
¸ R2 = {SR : SR Î
R(X), SR È SR2 Î
R1, "SR2 Î R2}.
Пример:

R1 =

, R2 =

, R1 ¸ R2 =

Здесь символом ‘+’ помечены кортежи R1, подкортежи которых войдут в реляционное частное.
Это неэлементарная операция. Она выражается через операции проекции, прямого произведения и разности.

Реляционное исчисление с переменными на доменах

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

Неразумно создавать БД, состоящую из

Резюме
Неразумно создавать БД, состоящую из единственного универсального отношения. В такой БД неизбежно избыточное дублирование данных и аномалии обновления. В ней невозможно поддерживать целостность данных.
Проблема аномалий обновления универсального отношения порождается тем, что в нем представлены все ФЗ, обусловленные требованиями ПО, но средствами РМД можно объявить только те из них, в которых детерминантом является возможный ключ отношения.
Для того чтобы в БД не было аномалий обновления данных, следует хранить данные не в одном отношении, а в нескольких взаимосвязанных. Эти отношения должны быть проекциями универсального отношения, находящимися, по крайней мере, в 3НФ. Естественное соединение всех проекций должно восстанавливать универсальное отношение без потерь информации.
Проецирование универсального отношения должно выполняться с сохранением ФЗ. Из существующих (и объявленных!) в проекциях ФЗ должны выводиться все ФЗ, существующие в универсальном отношении.
Любое отношение 1НФ может быть приведено к системе независимо обновляемых отношений 3НФ без потерь информации.
Отношение, не находящееся в НФБК, может быть декомпозировано без потерь информации на два отношения в НФБК, но эти отношения необязательно будут независимо обновляемыми.
Процесс преобразования универсального отношения к системе отношений, не обладающей аномалиями обновления данных, называется нормализацией. В качестве методики проектирования логического макета БД нормализация мало пригодна, однако концепция нормализации и связанные с ней понятия ФЗ и нормальных форм определяют цели проектирования и критерии их достижения.
Цель
проектирования – создание структуры данных, представляющей собой систему отношений, находящихся в НФБК.
Критерий
– каждое отношение в системе должно быть таким, чтобы любой его детерминант был потенциальным ключом.
В заключение отметим, что в некоторых случаях нормализация до НФБК может оказаться недостаточной для устранения аномалий обновления. Тогда следует продолжить процесс до получения 4НФ или 5НФ [1]. Однако при разумном использовании интуитивного (семантического) подхода к проектированию, изложенного в следующем разделе, такие ситуации возникают исключительно редко.

РИ с переменными-кортежами

. Основным понятием этого варианта РИ является понятие переменной-кортежа.
Пусть R
– некоторое отношение. Величина t, значениями которой являются кортежи отношения R, называется переменной-кортежем, определенной на R.
На интуитивном уровне переменная-кортеж это перемещающееся по строкам таблицы окно, в котором всегда видна одна строка – текущее значение переменной.

Система базы данных

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

Селекция или ограничение по условию

. Это унарная операция. Она строит отношение, схема которого эквивалентна схеме операнда, а тело составлено из кортежей операнда, удовлетворяющих заданному условию. Это можно представить себе как вычеркивание ненужных строк таблицы.
Пусть R
– отношение и F – предикат, определенный на его атрибутах. Селекция
отношения R по условию F есть множество кортежей, на которых предикат F принимает значение .Т. («истина»).
RF = sF
(R) = {SR : RF ( ) = R( ), SR Î
R, F (SR) = .T.}.
Примеры:

, sA=d Ú C=c(R) =

R =

, sB = b (R) =

Семантический подход

, в отличие от формального, предполагает параллельное
выполнение анализа ПО и проектирование логического макета БД. В основе подхода лежат понятия ER-модели данных (см. п. 1.4). Процесс проектирования включает три этапа (см. п. 1.4.7).
· На первом этапе проектировщик формирует общие представления о компонентах бизнеса и их отношениях и идентифицирует основные сущности и связи. При этом он не стремится получить детальную информацию о свойствах объектов ПО и их взаимосвязях.
· На втором этапе представления проектировщика детализируются до уровня идентификаторов экземпляров сущностей и типов связей. Здесь окончательно определяется состав сущностей модели, и специфицируются ограничения целостности сущности и ссылочной целостности – первичные и альтернативные ключи, внешние ключи, типы сущностей и связей. Результат этапа – логический макет БД с точностью до ключей.
· На третьем этапе формируются окончательные представления о составе атрибутов сущностей и полностью определяются схемы всех отношений, соответствующих сущностям. Как правило, все отношения схемы находятся в (усиленной) 3НФ.
Выделяя сущности и определяя связи между ними, проектировщик опирается на свои текущие представления о ПО и здравый смысл. На каждом этапе он может согласовать свои представления с представлениями конечных пользователей. Поэтому грубые ошибки моделирования при разумном использовании семантического подхода – редкость.
Этот подход к проектированию представляется вполне естественным и понятным. Кроме того, он очень эффективен, если проектировщик придерживается определенной дисциплины проектирования и использует подходящие средства для документирования работ.

Семантика данных и способы ее отображения

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

лицо		табельный номер		возраст		отдел
‘Иванов’		‘345’		45		‘12’

товар		склад №		количество		цена
‘Мука’		‘12’		1500		123

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

Семантика доменов и атрибутов

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

Рис. 2.1 Соотношения элементарных понятий РМД
доменах числового типа[9]. Атрибуты, определенные на общем домене сравнимы. Например, длина и ширина должны быть определены на общем домене, т.к. их сравнения осмысленны. А атрибуты табельный номер и номер телефона должны быть определены на разных доменах. Кроме того, эти домены не могут быть числовыми. Никто не складывает и не умножает табельные и телефонные номера.

Схема отношения, кортеж, отношение

. Пусть D1, D2, …Dn – домены (необязательно различные) и А1, А2, …, Аn – атрибуты, определенные на соответствующих доменах.
Определение 1.
Множество R = {(D1, A1), (D2, A2), ..., (Dn, An)}
пар <домен, атрибут>
называется схемой отношения[10].
Интуитивно схему отношения можно понимать как заголовок таблицы или как определение типа простой записи.
Пусть R – схема отношения, Ai – атрибут схемы, ai – значение атрибута.
Определение 2.
Множество пар SR = {Si
: Si = (Ai, ai), (Di, Ai) Î R, ai Î Di, i = 1, …, n} называется кортежем, соответствующим схеме R.
Интуитивно кортеж представляется как строка таблицы с заданным заголовком или набор именованных значений типов, или экземпляр записи.
Например, пусть номера – домен трехсимвольных строк, составленных из цифр ‘0’, ‘1’,...’9’, имена
– домен строк символов русского алфавита, пробелов и точек, а схема отношения СЛУЖАЩИЙ имеет вид:
{( номера, номер служащего), (имена, имя служащего)}.
Кортежи этого отношения могут быть такими:
{(номер служащего, ‘345’), (имя служащего, ‘Иванов И.И.’)},
{(номер служащего, ‘938’), (имя служащего, ‘Петров П.П.’)}.
Отношение интуитивно можно понимать как таблицу, заголовком которой является строка атрибутов, а значимыми строками – строки их значений, или как плоский файл, однако это неточные представления.
Определение 3.
Множество кортежей SR, соответствующих одной и той же схеме R, называется отношением.
Отношение характеризуется:
· арностью (степенью) – числом пар <домен, атрибут> в схеме;
· мощностью – числом кортежей, составляющих тело отношения.
Так, приведенные выше кортежи образуют бинарное отношение мощности 2.
Отношение является единственной
структурной единицей РМД.
Замечание 1. Обычно отношение и его схема обозначаются одним и тем же символом R. Если нам понадобится явно различить схему и отношение, мы сохраним это обозначение за отношением, а схему будем обозначать символом R( ).

Синтаксис исчисления

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

область-определения ::= RANGE OF переменная IS список-элементов-области;
выражение ::= (список-целевых-элементов) [WHERE ппф] ;
целевой-элемент ::= переменная \| переменная.атрибут [AS атрибут];
ппф ::= условие \| NOT ппф \| условие AND ппф \| условие OR ппф \|IF условие THEN ппф \| EXISTS переменная (ппф) \| FOR ALL переменная (ппф) \| (ппф);
условие ::= (ппф) \| сравнение;
сравнение ::= символ q символ;
символ ::= переменная.атрибут \| константа;
q :: = < \| > \| =;

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

Синтаксис категорий

.1 Синтаксис категорий.
Обозначения для связей категоризации показаны на рис. 4.4, рис. 4.5.
Каждая пара линий – от родовой сущности до окружности и от окружности до категории – представляет одну
связь в кластере. Спецификации кардинальности не указываются, поскольку она всегда «ноль или один» со стороны родовой сущности и «точно один» со стороны категории[32]. Категоризационные связи не имеют явных имен. От родовой сущности любую из них можно прочитать «может быть», а обратно – «является».

Рис 4.4 Полный кластер категорий

Рис 4.5 Неполный кластер категорий

Синтаксис реляционных выражений

.
Определим теперь синтаксис для операций РА, который будем использовать в дальнейшем[22]. Основной синтаксической единицей является выражение
РА, производящее отношение. Любое выражение является безымянным производным отношением.

выражение ::= унарное-выражение \| бинарное-выражение;
унарное-выражение ::= переименование \| выборка \| проекция;
переименование ::= терм RENAME атрибут AS атрибут;
терм ::= отношение \| (выражение);
выборка ::= терм WHERE предикат;
предикат ::= сравнение \| предикат AND предикат \| предикат OR предикат \| NOT предикат[23];
сравнение ::= символ q символ;
символ ::= атрибут \| константа;
q ::= < \| > \| =;
проекция ::= терм \| терм [список];
бинарное-выражение ::= проекция бинарная-операция выражение;
бинарная-операция ::= UNION \| INTERSECT \| MINUS \| TIMES \| JOIN \| DIVIDEBY;

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

S RENAME S# AS Snum;		переименование S# в Snum
S;		проекция S на все атрибуты схемы.
S[S#, Ci];		проекция S на атрибуты {S#, Ci}.
S WHERE Ci = ‘Томск’		выборка по условию Ci = ‘Томск’

Бинарные выражения.

(S[Ci]) UNION (P[Ci]);		объединение проекций;
(S[Ci]) INTERSECT (P[Ci]);		пересечение проекций;
(S[Ci]) MINUS (P[Ci]);		разность проекций;
(S RENAME Ci AS SCi) TIMES (P RENAME Ci AS Pci);		расширенное прямое произведение;
(SPJ[S#, P#]) DIVIDEBY (P[P#]);		реляционное деление;
(S JOIN SPJ)[Sn, Qt];		проекция объединения;

Синтаксис соединений

.1 Синтаксис соединений.
Нотации, используемые для обозначения соединений, определены на рис. 4.2.
В диаграммах IDEF1Х представляются только бинарные и унарные связи (соединения), а также иерархии (связи категоризации). Отсутствие обозначений для представления связей высшей арности не является ограничением модели (см. п. 1.4.5.1). Неспецифические соединения могут быть показаны только на диаграммах ER-уровня.
Значение кардинальности связи от родителя указывается около точки на конце дуги. Возможные спецификации кардинальности приведены в таблице 4.1.

Рис. 4.2 Обозначения соединений
а) идентифицирующее соединение;
б) обязательное неидентифицирующее соединение;
в) необязательное неидентифицирующее соединение;
г) неспецифическое соединение.
Таблица 4.1 - Спецификации кардинальности

Обозначение		Число возможных экземпляров связи
		0, 1 или более,
		1 или более,
		0 или 1,
		точно указанное число N,
		от N1 до N2.

Кардинальность со стороны потомка необходимо указывать только для необязательного неидентифицирующего соединения[31]. Ромбик на конце дуги, примыкающем к родительской сущности (см. рис. 4.2, б)), означает, что с каждым экземпляром потомка в связь вступает 0 или 1 экземпляр родителя.
4.4.2 Правила именования соединений. Ниже перечислены только основные правила стандарта.
· Соединению присваивается имя, выражаемое глагольным оборотом. Имя зрительно привязывается к дуге, изображающей соединение. Имена соединений могут быть неуникальными в пределах диаграммы.
· Имя каждого соединения одной и той же пары сущностей должно быть уникальным во множестве имен связей этих сущностей.
· Имена специфических соединений выбираются так, чтобы можно было построить осмысленную фразу, составленную из имени родительской сущности, имени связи, выражения кардинальности и имени потомка (рис. 4.3).

Рис. 4.3 Именование связей
· Связь может быть поименована «от родителя» и от «потомка» (см. рис. 4.2 а) – в)). Имя «от родителя» обязательно.
· Если связь не именуется со стороны потомка, то имя «от родителя» должно выбираться так, чтобы связь легко читалась и со стороны потомка.
· Неспецифические соединения обязательно именуются с обеих сторон.

Система базы данных

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

Соединение по условию

Соединение по условию. Эта операция применяется к отношениям, совместимым по взятию расширенного прямого произведения. Она не является элементарной, однако, включается в базовый набор операций, поскольку очень часто встречается в практических процедурах манипулирования данными.
Пусть R1
и R2 – отношения, совместимые по взятию расширенного прямого произведения, F – предикат, определенный на их атрибутах. Соединением отношений R1 и R2 по условию F называется подмножество кортежей отношения R1 ´
R2, на которых предикат F
принимает значение .Т.
R1
Ä R2
= sF(R1 ´ R2)[21].
F
Пример:

R1 =

R2 =

, R1 Ä R2 =

A= a2ÚD=B

Важным частным случаем является операция соединения по условию равенства
значений атрибутов операндов – эквисоединение.
В этом случае предикат F имеет вид A1 = A2, где A1 и A2 – атрибуты схем R1( ) и R2( ), соответственно. Операция имеет смысл только для сравнимых, т.е. определенных на общем домене, атрибутов.

Соединения

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

Список целевых элементов

. Каждый целевой элемент – это или имя переменной-кортежа, или выражение вида
t.A [ AS X ],
где t – имя переменной-кортежа;
А – имя атрибута сопоставляемого отношения;
Х – новое имя атрибута А, используемое в ссылках на атрибут переменной-кортежа t.
Сопоставляемое отношение
– это область определения переменной t, то есть, отношение являющееся объединением элементов-области.
В вышеприведенном примере сопоставляемое отношение есть объединение отношений
(SX) WHERE SX. Ci = ‘Яя’;
и
(SX) WHERE EXISTS SPJX
(SPJX. S# = SX. S# AND SPJX. P# = ‘P1’);
Примеры целевых списков:
SX.S#, SX.Sn;
SX.Ci AS SCity;
SX.S#, SX.Ci AS SCity, PX.P#, PX.Ci AS Pcity;
Список целевых элементов не имеет смысла вне выражения исчисления.
Целевой список определяет схему целевого отношения. Имена атрибутов (и, соответственно, домены) наследуются от схемы сопоставляемого отношения либо указываются явно необязательной конструкцией «AS атрибут».

СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ

1. Дейт К. Введение в системы баз данных. – Киев-Москва: Диалектика, 1998. – 784 с.
2. Ульман Дж. Основы систем баз данных. – М.: Финансы и статистика, 1983. – 452 с.
3. Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983. – 320 с.
4. Диго С. Проектирование и использование баз данных. – М.: Финансы и статистика, 1995. – 158 с.
5. Джексон Г. Проектирование баз данных для персональных ЭВМ. – М.: Финансы и статистика, 1988, 160 с.
6. Кузнецов С. Н. Введение в СУБД // Системы управления базами данных. – 1995. – №1 – №4.
7. Дейт К. Руководство по реляционной СУБД ДВ2. – М.: Финансы и статистика, 1983. – 204 с.
8. Грабер М. Введение в SQL. – М.: Бином, 1996. – 248 с.
9. Ревунков Г. Н., Самохвалов Э. Н., Чистов В. В. Базы и банки данных и знаний. – М.: Высшая школа, 1992. – 488 с.
10. Хансен Г., Хансен Дж. Базы данных. Разработка и управление – М.: Бином, 1999. – 700 с.
11. Integration Definition for Information Modeling (IDEF1X). Federal Information Processing Standards Publication 184. 1993, December 21.
[1]
Здесь и далее словами «предприятие» или «бизнес» будем обозначать любой вид целенаправленной деятельности – производство продукции, оказание услуг, коллекционирование марок, ведение домашнего хозяйства и т.п.
[2]
Однако – это логическое представление. Физическая организация БД может сильно отличаться от этой структуры.
[3]
Далее в настоящей главе термин ‘данные’ используется в смысле второго определения. Имеются в виду символы, а не их значения.
[4]
Здесь и далее в тексте имена атрибутов выделяются шрифтом и записываются строчными буквами.
[5]
Имена сущностей выделяются шрифтом и записываются прописными буквами. Если в предложении должна быть изменена грамматическая форма имени, то прописными буквами записывается неизмененная часть.

[6]

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

[7]

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

[8]

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

[9]

Эти домены различны, даже если содержат одни и те же значения.

[10]

Сравните это с понятием сущности (см. п. 1.4.2).

[11]

Так в модели отражается динамика реального мира.

[12]

Автор модели Кодд определил этот объект именно как теоретико-множественное отношение.

[13] Но не обязательно именно их!

[14]

Использованные на рисунке нотации определены в главе 4.

[15]

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

[16]

Далее в этом разделе рассматривается схема SPJ(S#, P#, J#, Qt).

[17]

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

[18]

Вообще говоря, требование одноименности

атрибутов излишне.

[19] Здесь и далее несущественные для понимания текста детали схем опускаются.

[20]

Этот материал выходит за рамки РМД, но необходим для понимания смысла предложений определения объектов РБД.

[21]

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

[22]

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

[23]

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

[24]

Считается, что домен атрибута каким-то образом определен. Например, это может быть домен «по умолчанию».

[25]

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

[26]

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

[27]

Легко заметить, что эти отношения соответствуют интуитивно выделяемым объектам ПО.

[28]

Через посредство первичных ключей соответствующих отношений.

[29]

Здесь имеются в виду значения

отношений.

[30]

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

[31]

Для прочих типов соединений она всегда точно 1 (см. п. 1.4.5.5).

[32]

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

Ссылочная целостность

. Нет никакого смысла хранить в БД кортежи отношения-потомка, ссылающиеся на кортежи, не существующие в родительском отношении. Так, если не существует в текущем значении отношения S кортежа со значением S# = ‘S3’, то кортеж {‘S3’, ‘P1’, ‘J8’, 500} не имеет права на существование в текущем значении отношения SPJ. Включающее его состояние БД не может быть интерпретировано.
Требование ссылочной целостности: ни в какой момент времени в базе данных не может быть значений ссылающегося ключа, которых нет среди существующих значений родительского ключа.
Эта формулировка, как, впрочем, и определение внешнего ключа, неточна. Если строго ей следовать, то окажутся недопустимыми Null-значения внешних ключей. Это логически неоправданный запрет. Ситуации, в которых значения атрибутов внешнего ключа неизвестны или вообще не могут быть определены, возникают очень часто.
Так, в примере, показанном на рис. 2.6, не во всех кортежах отношения ЛИЦО
внешний ключ супруг.номер паспорта будет иметь определенные значения. Бывают ведь и холостяки, и разведенные.
Разумно не разрешать Null-значения внешнего ключа, входящего в состав первичного ключа потомка. Этого и не допускает требование целостности сущности. Но если атрибут внешнего ключа не входит в состав первичного ключа потомка, то он может принимать Null-значения.
Имея это в виду, следует сформулировать пункт Б) определения внешнего ключа (см. п. 2.3.4) так:
Б) каждое значение FK в текущем значении В
всегда или совпадает со значением РК
некоторого кортежа в текущем значении А, или является Null-значением.
Более точная формулировка требования ссылочной целостности такова:
ни в какой момент времени в БД не может быть определенных (не Null-) значений ссылающегося ключа, которых нет среди существующих значений родительского ключа.
Это, как и предыдущие два требования, метаправило. Оно означает, что в каждой конкретной РБД должны быть определены специальные правила (правила внешних ключей), поддерживающие требование ссылочной целостности.

Сущность и атрибут

. В концептуальной модели объекту ПО (см. п. 1.1.4) соответствует сущность, а свойству объекта – атрибут. Удовлетворительных формальных определений этих понятий не существует. Ниже следующий текст нужно рассматривать, как попытку помочь читателю сформировать достаточно ясные представления собственными силами.
Атрибут
есть имя, принимающее значения на некотором множестве возможных значений.
Имя передает смысл соответствующего свойства объекта ПО. Например[4]: фамилия студента, номер зачетной книжки – атрибуты, соответствующие одноименным характеристикам объекта ПО СТУДЕНТ.
Множество возможных значений атрибута определяется смыслом характеристики и требованиями ПО. Так, атрибут пол (человека) может принимать значения на двухэлементных множествах {‘мужской’, ‘женский’} или {‘М’, ‘Ж’}, или {0, 1}
и т.п. в зависимости от принятых в ПО стандартов.
Атрибут можно понимать как символ, обозначающий некоторое множество возможных значений данных.
Сущность
есть имя, поставленное в соответствие набору атрибутов.
Имя сущности передает смысл соответствующего объекта ПО. Набор атрибутов сущности соответствует набору характеристик этого объекта, представляющих интерес с точки зрения бизнеса. То есть, атрибуты связаны общим смыслом, а их перечень определяется требованиями ПО.
Например[5], в концептуальной модели ВУЗа могут быть определены сущности:
СТУДЕНТ = {фамилия, имя, номер зачетной книжки, номер группы}
УЧЕБНАЯ ДИСЦИПЛИНА = {код, наименование, кафедра}.
Набор значений атрибутов сущности называется экземпляром сущности.
Например: {‘123’, ‘Базы данных’, ‘АСУ’} – экземпляр сущности УЧЕБНАЯ ДИСЦИПЛИНА.
Сущность можно понимать как множество всех интерпретируемых наборов значений ее атрибутов.
Подчеркнем, что не любой набор возможных значений атрибутов может быть экземпляром сущности. Так, набор {‘Иванова’, ‘Петр’, ‘123456’, ‘432’} не имеет смысла, хотя и составлен из допустимых значений атрибутов сущности СТУДЕНТ.
Замечание 1.
С точки зрения математика сущность есть отношение, определенное на декартовом произведении множеств возможных значений атрибутов.
Замечание 2.
С точки зрения программиста сущность есть подмножество структурного типа данных.
Замечание 3.
Вообще говоря, атрибуты также могут принимать значения структурных типов. Например, атрибутом сущности СТУДЕНТ
может быть зачетная ведомость, в свою очередь обозначающая набор атрибутов {дисциплина, преподаватель, оценка, дата}. Однако распространенные в настоящее время ЯОД не допускают подобных конструкций.[6]

Связь

. Говорят, что объекты ПО состоят в связи, если хотя бы одному экземпляру одного из них можно поставить в соответствие (по определенному правилу) один или более экземпляров другого. Связь сущностей в концептуальной модели отображает множество связей между экземплярами соответствующих объектов ПО (см. п. 1.1.4).
Говоря формально, связь
есть отношение[7], определенное на декартовом произведении сущностей.
На естественном языке связь выражается глагольным оборотом, связывающим имена сущностей.
На рис. 1.8, а показаны четыре экземпляра связи между экземплярами объектов ПО. Здесь Пi – конкретный поставщик, а Тj
– поставленный им товар. Это множество фактов поставок отображается в модели (рис. 1.8, б) четырехэлементным множеством пар (отношением), в которых Пi и Тj – соответствующие наборы значений атрибутов сущностей ПОСТАВЩИК
и ТОВАР.

ПОСТАВЩИК поставил ТОВАР
		{(П1,Т1), (П1,Т5), (П2,Т2), (П4,Т1)}
а)		б)

Рис. 1.8 Связь:
а) связь объектов ПО; б) связь сущностей
Поскольку экземпляры сущностей полностью идентифицируются значениями возможных ключей (см. п. 1.4.3), связь можно понимать как отношение, определенное на декартовом произведении множеств допустимых значений возможных ключей связанных сущностей.
Однако связь может иметь и собственные атрибуты, которые нельзя отнести ни к одной из сущностей. Так, в нашем примере о факте поставки следует знать не только кто и что поставил, но также и сколько, и по какой цене. Соответствующие атрибуты количество и цена нельзя отнести к сущностям ПОСТАВЩИК
или ТОВАР. Это характеристики поставки, т.е. связи. Теперь можем дать окончательное определение понятия связи.
Связь
есть отношение, определенное на декартовом произведении множеств допустимых значений возможных ключей связанных сущностей и собственных атрибутов.
Замечание 4.
С формальной точки зрения сущность и связь как структуры данных неразличимы (см. замечание 1). Этот факт отражен в реляционной модели данных (см. гл. 2).

Связи категоризации

Связи категоризации
Связью категоризации (categorization relationship) называется связь между родовой сущностью и категорией.

Свойства отношений РМД

. Отношения РМД обладают рядом свойств, отличающих их как от обычных теоретико-множественных отношений, так и от таблиц.
Уникальность кортежей. Так как отношение есть множество кортежей, в нем не может быть дубликатов кортежей, то есть каждый кортеж встречается в отношении только один раз. Из этого свойства следует, что каждое отношение имеет некоторый набор атрибутов, значения которых уникально идентифицирует кортежи. Этот набор атрибутов называют возможным ключом
отношения. Формальное определение этого понятия приведено в п. 2.3.3.
Неупорядоченность кортежей. Это также следствие того, что отношение – множество кортежей. Множества неупорядоченны, если их упорядоченность специально не оговорена. Заметим, что в реальных структурах хранения данные так или иначе упорядочены. Однако учет этой упорядоченности в процедурах манипулирования данными сделал бы прикладные программы зависящими от физических структур хранения. Поэтому введение каких-либо гипотез об упорядоченности в концептуальную модель данных было бы ошибкой.
Неупорядоченность атрибутов. Это свойство следует из определения схемы отношения как множества пар <домен, атрибут>. Неупорядоченность атрибутов делает возможной модификацию схем отношений путем удаления атрибутов, вставки новых и переименования атрибутов и позволяет относительно просто определить ряд полезных операций над отношениями.
Уникальность атрибутов. Одноименные атрибуты недопустимы, поскольку это может привести к появлению в схеме отношения дубликатов пар (домен, атрибут), что противоречит определению. Кроме того, только уникальность атрибутов может обеспечить возможность отнесения значения из кортежа к определенному домену.
Атомарность значений атрибутов. Свойство следует из определения атрибута. Атрибут принимает значения на домене, а домен – подмножество простого типа. Таким образом, в реляционной теории не рассматриваются так называемые ненормализованные
отношения.

Свойства связей и сущностей

1.4.5.1 Арность. До сих пор в наших примерах фигурировали только связи между двумя сущностями – бинарные. Однако в реальном мире могут встречаться связи между тремя и более сущностями. Например, если нужно фиксировать факты поставок деталей, выполненных поставщиками для различных изделий, то в модели должны быть определены сущности ПОСТАВЩИК, ДЕТАЛЬ и ИЗДЕЛИЕ и тернарная связь, т.е. отношение, включающее возможные ключи этих трех сущностей. Возможны также унарные связи, т.е. связи между экземплярами одной и той же сущности.
Итак, связь характеризуется арностью (степенью) – числом вступающих в нее сущностей.
Замечание 5.
Существующая в реальном мире n-арная связь объектов ПО может быть представлена в концептуальной модели в виде n бинарных связей n + 1 сущностей. Для этого достаточно определить как сущность соответствующее связи отношение.
Эта сущность будет представлять в модели не объект ПО, а множество фактов связи. Например, вместо тернарной связи ПОСТАВЩИК–ДЕТАЛЬ–ИЗДЕЛИЕ можно рассматривать три бинарных связи ПОСТАВЩИК–ПОСТАВКА, ДЕТАЛЬ–ПОСТАВКА и ИЗДЕЛИЕ–ПОСТАВКА, где ПОСТАВКА – сущность-ассоциация, в состав атрибутов которой входят возможные ключи сущностей ПОСТАВЩИК, ДЕТАЛЬ и ИЗДЕЛИЕ. Именно такой подход используется в языке определения данных IDEF1X (см. гл. 4).
Имея в виду это замечание, далее обсудим характеристики унарных и бинарных связей.
1.4.5.2 Мощность. Пусть E1 и E2 – сущности, состоящие в бинарной связи. Если один экземпляр сущности E1
может вступить в 0, 1 или более экземпляров связи, но один экземпляр сущности E2 – не более чем в один, то говорят, что между E1 и E2 существует связь типа «один ко многим» или 1:M. Если же один экземпляр каждой сущности может образовать 0, 1 или более экземпляров связи, то говорят, что имеет место связь типа «многие ко многим» или M:M.
Число М
экземпляров связи, которые могут быть образованы одним экземпляром сущности, называется мощностью (кардинальностью) связи со стороны этой сущности.

Мощность связи определяется правилами, действующими в ПО (бизнес-правилами). Например, если наша фирма никогда не работает с двумя различными поставщиками одного и того же вида товара, но один поставщик может поставлять более чем один товар, то связь ПОСТАВЩИК–ТОВАР имеет тип 1:М (рис. 1.9, а). Если же ограничений на число поставщиков одного и того же вида товара нет, то имеет место связь типа М:М (рис. 1.9, б).

Рис. 1.9 Мощность связи:
а) связь 1:М; б) связь М:М
Значение мощности может быть неопределенным (0, 1,...), заданным числом (точно 5) или интервалом (от 3 до 8). Это также определяется бизнес-правилами. Например, мощность связи ПОСТАВЩИК–ТОВАР со стороны сущности ТОВАР на рис. 1.9, а равна 1, т.к. один вид товара всегда поставляется точно одним поставщиком. Мощность этой связи со стороны сущности ПОСТАВЩИК не определена, если количество видов товара, поставляемых одним и тем же поставщиком, не ограничено.

Типы сущностей и обязательность связей

. Сущность может участвовать как потомок в нескольких специфических связях. Если ни одна из них не является идентифицирующей, то говорят, что сущность [идентификационно] независима. Потомок в избирательной связи называется [идентификационно] зависимой сущностью.
Обычно независимыми бывают сущности, представляющие реально существующие объекты ПО (ПОСТАВЩИК, ТОВАР). Сущности-ассоциации, представляющие в модели факты связей (ПОСТАВКА), всегда идентификационно зависимы.
Идентификационная зависимость всегда зависимость существования. Экземпляр идентификационно зависимой сущности не может существовать вне связи с родительским экземпляром. Поэтому идентифицирующие связи всегда обязательные. Это означает, что каждому экземпляру потомка всегда соответствует (точно один) экземпляр родителя. Иначе говоря, кардинальность идентифицирующей связи со стороны потомка всегда единица.
Неидентифицирующие связи могут быть необязательными. В такой связи возможно существование экземпляра потомка без соответствующего экземпляра родителя.
Пример. Рассмотрим фрагмент фирмы, занимающейся прокатом видеофильмов. Фирма имеет центральную фильмотеку и сеть прокатных пунктов. Прокатные копии фильмов поступают от поставщиков в фильмотеку, а из фильмотеки попадают в фонды прокатных пунктов. База данных фирмы должна хранить (в частности) сведения:
· о ФИЛЬМах как о произведениях киноискусства (название, режиссер, студия, год выпуска, исполнители главных ролей и т.д.);
· об имеющихся в прокате КОПИЯх (тип носителя, год выпуска, количество прокатов, оценка состояния, признак наличия в хранилище и т.п.);
· о ПРОКАТНЫх ПУНКТах (номер, адрес, телефон, время работы и т.д.).
По правилам фирмы каждому фильму присваивается уникальный номер. Копии получают уникальные номера в пределах фильма. Фирма заинтересована в контроле проката каждой копии. В частности, необходимо знать, находится ли в настоящий момент данная копия в фильмотеке или в определенном прокатном пункте.
Для того чтобы отразить этот фрагмент в концептуальной модели, мы должны определить сущности ФИЛЬМ, КОПИЯ и ПРОКАТНЫЙ ПУНКТ.
Между ними существуют связи, определяемые фразами:

«ФИЛЬМ имеется в одной или более КОПИЯх»;

«КОПИЯ передана в фонд ПРОКАТНого ПУНКТа».

В состав атрибутов сущностей ФИЛЬМ и ПРОКАТНЫЙ ПУНКТ войдут, соответственно, номер фильма

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

В состав атрибутов сущности КОПИЯ войдет атрибут номер копии, но он не может быть ключом, т.к. копии нумеруются в пределах фильма. Возможно существование нескольких экземпляров КОПИй (различных ФИЛЬМов) с одинаковыми значениями этого атрибута. Однако, КОПИЯ – потомок ФИЛЬМа в связи типа 1:М (существует много копий одного фильма, но одна копия не может быть копией нескольких фильмов). Это означает, что атрибут номер фильма входит в состав атрибутов КОПИи в качестве внешнего ключа. Подмножество атрибутов {номер копии, номер фильма} обладает свойством возможного ключа сущности КОПИЯ. Таким образом, обсуждаемая связь идентифицирующая,

а сущность КОПИЯ

– идентификационно зависимая.

Связь сущностей КОПИЯ и ПРОКАТНЫЙ ПУНКТ также специфическая. Родителем в ней выступает ПРОКАТНЫЙ ПУНКТ. Следовательно, атрибут номер прокатного пункта войдет в состав атрибутов КОПИи в качестве внешнего ключа. Экземпляры КОПИи идентифицируются вне этой связи (для того, чтобы указать на конкретную копию, не нужно знать, в каком прокатном пункте она находится). Обсуждаемая связь неидентифицирующая. Кроме того, она необязательная. В самом деле, конкретная копия может в настоящий момент не находиться ни в каком прокатном пункте, т.е. экземпляр КОПИи (потомка в этой связи) существует вне связи с каким-либо экземпляром ПРОКАТНого ПУНКТа (родителя).

Требования к диаграммам

Требования к диаграммам
4.7.1 ER-уровень.
Диаграмма должна содержать сущности и связи, может показывать атрибуты и не должна показывать первичные, альтернативные или внешние ключи. На ER-уровне сущности не различаются как зависимые или независимые, а соединения – как идентифицирующие и неидентифицирующие. Сущности не содержат горизонтальных линий, отделяющих область ключей от области данных. Имена сущностей вписываются в обозначающие их прямоугольники.
Диаграмма ER-уровня может показывать категории, но указывать дискриминаторы кластеров необязательно.
На ER-уровне допустимы неспецифические соединения. Для изображения соединений можно использовать как сплошные, так и штриховые линии. Это не специфицирует соединения.
4.7.2 КВ-уровень. Диаграммы этого уровня изображают сущности, связи, первичные, альтернативные и внешние ключи.
·
Различаются зависимые и независимые сущности, а также идентифицирующие/неидентифицирующие и обязательные/необязательные соединения.
· Неспецифические соединения запрещены.
· Каждая сущность должна иметь первичный ключ и альтернативные ключи, если они существуют.
· Каждая сущность должна содержать внешний ключ для каждого соединения или категоризационной связи, в которой она участвует как потомок или категория.
· Каждый кластер категорий должен иметь дискриминатор.
Диаграмма КВ-уровня может также содержать неключевые атрибуты.
Диаграммы KB-уровня должны удовлетворять ряду правил для ключей. Они являются переформулировками требований целостности сущности и ссылочной целостности РМД, однако не смотря на это приведем их.

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

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

Рис. 1.5 Трехуровневая архитектура БД (общий вид)
Пример. Пусть в нашей ПО имеется объект СЛУЖАЩИЙ, характеризующийся свойствами

табельный номер

номер отдела

зарплата

. . . ,

и есть два конечных пользователя БД – КП1 и КП2. Для КП1 представляют интерес только табельный номер и номер отдела, для КП2 – табельный номер
и зарплата. Объект имеет три уровня представления или описания.
На внешнем уровне показаны два представления объекта СЛУЖАЩИЙ для различных конечных пользователей. Каждому из них обслуживающая его ПП предоставляет ту информацию о СЛУЖАЩем, в которой он заинтересован, скрывая другие характеристики.
Внешний уровень 1 (COBOL)                      Внешний уровень 2
(PL/1)
01 EMP#                                                             DCL 1 EMP
02 ЕМPNO         PIC X (6)                                         2 EMP CHAR (6)
02 DEPNO         PIC X (4)                                         3 SAL FIXED BIN (31);
Первые строчки этих текстов объявляют имена объекта. Вторые и третьи строчки указывают имена и типы характеристик объекта. Для КП1 – это табельный номер и номер отдела, а для КП2 – табельный номер
и зарплата. Отметим, что в разных представлениях имена объекта и его характеристик могут быть различными.
С точки зрения обобщенного пользователя БД содержит следующую информацию о служащих.
Концептуальный уровень
СЛУЖАЩИЙ
Номер служащего   CHAR (6)
Номер отдела CHAR (4)
Зарплата NUMERIC (5)

Из приведенного описания совершенно не видно, как эта информация организована в памяти ЭВМ. Пользователю не нужно это знать. На внутреннем уровне

объект СЛУЖАЩИЙ представлен типом внутренней записи STORED_EMP.

Внутренний уровень

STORED_EMP	LENGTH= 20
PREFIX	TYPE = BYTE (6),	OFFSET= 0
EMP#	TYPE = BYTE (6),	OFFSET= 6,	INDEX = EmPX
DEPT#	TYPE = BYTE (4),	OFFSET=12,
PAY	TYPE =FULLWORD,	OFFSET=16

Указана длина записи – 20 байт. Запись состоит из четырех хранимых полей – PREFIX, EMP#, DEPT# и PAY. Поле PREFIX содержит необходимую служебную информацию. Три поля данных соответствуют свойствам СЛУЖАЩего. Поле EMP# связано с индексом ЕМРХ, обеспечивающим быстрый поиск по значениям ЕМР#. Этот индекс определен на внутреннем уровне, но не виден уже на концептуальном.

Рассмотрим детали трехуровневой архитектуры, представленные на рис. 1.6.

Рис. 1.6 Трехуровневая архитектура БД (детальная схема)

Базовый язык

(PL/1, COBOL, C,…) обеспечивает процедурные возможности, т.е. локальные переменные, арифметические и логические операции, циклы и т.п.

Подъязык данных

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

(внешней моделью).

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

Единицей доступа к данным для пользователя является внешняя запись.

Каждое внешнее представление задается внешней схемой – набором определений типов внешних записей. Схема описывается средствами пользовательского ЯОД. Система сохраняет это описание в словаре данных и может обратиться к нему. Изменения внешней схемы конкретного КП не видны прикладным программам других пользователей.

Третья нормальная форма

(3НФ).
Однако оказывается, что в такой системе отношений еще возможны аномалии обновления. Так, в отношении S
возможно избыточное дублирование данных и связанные с этим аномалии вставки кортежей и обновления значений атрибутов. Это следствие наличия транзитивной ФЗ S# ® SСi ® St.
Говорят, что отношение находится в третьей нормальной форме, если и только если оно находится в 2НФ и нет транзитивных зависимостей.
Можно дать альтернативное определение 3НФ, используя понятия неприводимой ФЗ и взаимной независимости атрибутов.
Отношение находится в третьей нормальной форме, если и только если каждый его неключевой атрибут неприводимо зависит только от первичного ключа и все неключевые атрибуты взаимно независимы.
Второй шаг процедуры нормализации направлен на устранение транзитивных зависимостей. Он, как и первый шаг, всегда может быть выполнен без потерь информации.
В нашем примере на втором шаге мы привели отношение S, содержащее цепочку транзитивных зависимостей, к паре отношений SC и CS, находящихся в 3НФ.
Определения 1НФ и 2НФ предполагают, что отношение имеет единственный потенциальный ключ. Посмотрим теперь, какие ситуации могут возникать, если отношение имеет несколько потенциальных ключей. Оказывается, что в этом случае нормализация до 3НФ может оказаться недостаточной для устранения аномалий обновления.

Универсальное отношени

е и аномалии обновления. Создать логический макет БД, – значит определить набор базовых отношений и правил целостности данных.
Зачем нужен какой-то набор отношений? Почему бы не хранить все данные в одном отношении?
Для того чтобы ответить на эти вопросы, вернемся к нашей «учебной» БД ПОСТАВЩИК–ДЕТАЛЬ– ИЗДЕЛИЕ (см. п. 2.3.2). Она состоит из четырех базовых отношений. Чтобы поддерживать в ней порядок, необходимо следить за соблюдением требования внешнего ключа. Вставляя кортеж в SPJ, мы должны проверить:
· есть ли добавляемое значение S#
среди значений этого атрибута в текущем значении отношения S;
· есть ли добавляемое значение P#
среди значений этого атрибута в текущем значении отношения P;
· есть ли добавляемое значение J#
среди значений этого атрибута в текущем значении отношения J;
· уникален ли новый набор значений {S#, P#, J#, Dt} в отношении SPJ.
При удалении кортежа из какого-либо родительского отношения возникнет вопрос: что делать с потомками удаляемого кортежа в отношении SPJ?
Если же мы создадим единственное (универсальное) отношение USPJ со схемой {S#, Sn, St, Sci, P#, PN, Co, We, Pci, J#, Jn, Jci, Qt}, то никаких проблем ссылочной целостности нет, потому что нет ссылок. Все связи между данными хранятся в одном месте, выражаются как связи между атрибутами одного отношения, а не как связи между отношениями. При добавлении кортежа достаточно проверить уникальность значения подмножества атрибутов {S#, P#, J#, Dt}. При удалении кортежа проблемы «отцов и детей» не возникает. Да и места на диске, кажется, потребуется меньше. В универсальном отношении нужно хранить значения всего тринадцати атрибутов, а в структуре, содержащей четыре отношения, – значения шестнадцати.
На первый взгляд – хорошо. На самом деле – очень плохо. Рассмотрим проблемы, возникающие при хранении данных в универсальном отношении.
Избыточность. Будем считать, что в нашей ПО действует, в дополнение к перечисленным в п. 2.3.2, следующее правило:
· статус поставщика однозначно определяется городом его размещения.

Для иллюстрации выпишем фрагмент возможного значения нашего универсального отношения:

S#	Sn	St	Sci	P#	Pn	Co	We	Pci	J#	Qt	...
S1	Иван	50	Яя	P3	шайба	Ж	20	Ош	J1	1000	...
S1	Иван	50	Яя	P1	гайка	К	10	Яя	J1	1000	...
S1	Иван	50	Яя	P8	болт	Ч	30	Яя	J1	500	...
S2	Петр	100	Ош	P3	шайба	Ж	20	Яя	J2	1000	...
S3	Джон	50	Яя	P2	винт	С	40	Ош	J2	2000	...
S3	Джон	50	Яя	P1	гайка	К	10	Ош	J2	1000	...
S8	Боб	50	Томск	P8	болт	Ч	30	Яя	J2	500	...

Очевидно, группы вида {S1, Иван, 50, Яя} встретятся столько раз, сколько поставок этот поставщик выполнил. Встреченная в первый раз такая группа сообщает нам сведения о конкретном поставщике. Встреченная вторично, она не содержит новой информации.

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

Аномалия вставки типа а).

Универсальное отношение не только нерационально использует пространство внешней памяти. Эта структура еще заставляет нас фиксировать один и тот же факт многократно. Поэтому вполне возможно появление кортежей {‘S1’, ‘Иван’, 100, ‘Яя’, ...}, {‘S1’, ‘Петр’, 50, ‘Ош’, ...}. Каковы имя, статус и город размещения поставщика S1? Эта информация утеряна. Контроль подобных ошибок невозможно возложить на систему.

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

Аномалия вставки типа б).

В универсальное отношение невозможно вставить данные, например, о некотором поставщике, который пока еще не выполнил ни одной поставки. В самом деле, единственным возможным ключом этого отношения является подмножество атрибутов {S#, P#, J#, Dt}. Если новый поставщик еще не выполнил ни одной поставки, то значение подмножества {P#, J#, Dt} в соответствующем кортеже не определено.

Кортеж не имеет идентификатора. Либо мы не можем его вставить, либо должны нарушить требование целостности сущности.

В универсальное отношение невозможно добавить кортеж, содержащий сведения о части объектов ПО.

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

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

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

Аномалия обновления значений. Пусть мы решили поднять статус поставщиков из Яи до 100. При этом нам придется отыскать все кортежи со значением Sci = ‘Яя’

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

При обновлении значений атрибутов универсального отношения существует возможность утери информации.

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

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

Уровни концептуальной модели

. В процессе создания концептуальной модели аналитик формирует собственные представления о предметной области и документирует их средствами какого-либо языка определения данных. Можно выделить три этапа этого процесса. Каждый завершается созданием определенного уровня детализации модели.
На первом этапе
формируются общие представления о ПО, выделяются основные сущности и связи. У аналитика еще нет ясных представлений о свойствах связей и типах сущностей, о необходимых ассоциациях и категориях, о полном перечне атрибутов и т.п. Результатом этапа является модель верхнего уровня абстракции (уровень «сущность–связь»).
На втором этапе
детализируются представления о свойствах сущностей и связей. Вводятся необходимые ассоциативные сущности, строятся иерархии сущностей, определяются возможные и внешние ключи, кардинальности и типы связей. Результатом этапа являются подробные спецификации связей и идентификаторов экземпляров сущностей (уровень ключей).
Третий этап состоит в детализации представлений о характеристиках объектов ПО и определении окончательного состава атрибутов сущностей. Результат этапа – детальные спецификации концептуальной модели, пригодные для определения требований к структурам хранения данных (уровень атрибутов).

Уровни представления диаграмм

.2 Уровни представления диаграмм.
В IDEF1Х различают три уровня графического представления информации, или три уровня диаграмм.
Уровень «сущность-связь» (ER level). Это уровень наименее детального представления информации. Он используется на начальной стадии моделирования, когда еще не выяснены или не поняты до конца свойства сущностей и связей. На диаграммах ER-уровня сущности и связи представлены только их именами.
Уровень ключей (Key-Based Level, KB). На этом уровне в диаграммах отражаются имена первичных и внешних ключей сущностей и спецификации связей. Диаграмма KB-уровня объявляет уникальные идентификаторы экземпляров сущностей и ограничения ссылочной целостности.
Уровень атрибутов (Fully Attributed Level, FA). Диаграмма FA-уровня показывает имена всех атрибутов сущностей и связей и полностью определяет структуру и взаимосвязи данных.
Цель моделирования – создание FA-диаграммы. Она является графическим представлением структуры реляционной базы данных с полностью определенными схемами отношений.
Синтаксис графического языка IDEF1Х обеспечивает однозначное представление ограничений ссылочной целостности в диаграммах KB- и FA-уровня. Правила именования и определения сущностей, доменов и атрибутов дают возможность задать ограничения на значения в текстовых документах, сопровождающих диаграмму. В силу этого трансляция FA-диаграммы в тексты описания таблиц и триггеров БД на языке конкретной СУБД оказывается чисто формальной процедурой и может выполняться автоматически.
Рассмотрим теперь нотации и правила языка IDEF1Х.

Условие принадлежности

. Основное отличие синтаксиса РИ доменов от определенного в п. 2.6.2 состоит в том, что здесь используется специальная синтаксическая конструкция – условие принадлежности:

отношение (пара, пара, …),
пара ::= атрибут : символ,
символ ::= переменная \| литерал.

Здесь отношение
и
переменная – идентификаторы.
Условие принадлежности принимает значение «истина», если и только если в отношении существует кортеж, в котором указанные атрибуты принимают указанные значения.
Примеры.
Условие S(S# : ‘S1’) примет значение .T., если и только если в текущем значении отношения S существует кортеж со значением атрибута S#, равным S1.
Условие SPJ(S# : SX, P# : PX)
принимает значение .T., если и только если в SPJ
есть кортеж, в котором значения S#
и P# совпадают с текущими значениями переменных SX
и PX, определенных на доменах S#
и P#.

Устранение аномалий (пример)

Вернемся к нашему универсальному отношению USPJ(S#, Sn, St, SCi, P#, Pn, We, Co, PCi, J#, Jn, JCi, Dt, Qt). Посмотрим, какие ФЗ между его атрибутами существуют. Для этого обратимся к правилам, сформулированным в пп. 2.3, 3.1.2. Из них следуют такие ФЗ:

S# ® Sn;	P# ® Pn;	J# ® Jn;	A ® SСi;	A ® Co;	A ®Qt.
S# ® St;	P# ® We;	J# ® JCi;	A ® St;	A ® PCi;	A® Sn,
S# ® SСi;	P# ® Co;		A ® Pn;	A ® Jn;	A ® St;
SCi ® St;	P# ® PCi;		A ® We;	A ® JCi;

Здесь обозначено A = {S#, P#, J#, Dt} и исключены тривиальные зависимости типа A ® S#.
Единственным потенциальным ключом этого отношения является подмножество А. От потенциального ключа неприводимо зависит единственный атрибут – Qt. Все прочие атрибуты зависят еще и от различных подмножеств потенциального ключа. Кроме того, есть ФЗ между неключевыми атрибутами (SCi ® St). Зависимости от подмножеств потенциального ключа обусловливают отмеченные в реализации группы повторения вида (P1, гайка, К, 10, Ош). Группы повторения вида (50, Яя) обусловлены наличием ФЗ SCi ® St.

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

. Рассмотрим отношение SPJ[16]
(ПОСТАВКА). Оно содержит атрибуты S#, P#, J#, значения которых указывают, какой ПОСТАВЩИК, для какого ИЗДЕЛИя поставил данный вид ДЕТАЛи. Это отношение могло бы иметь кортеж {‘S3’, ‘P1’, ‘J8’, 500} – «поставщик ‘S3’ выполнил для изделия ‘J8’ поставку детали ‘P1’ в количестве 500 штук». Здесь значение ‘S3’ – ссылка на кортеж отношения S с таким же значением первичного ключа. Аналогичны роли значений ‘P1’, ‘J8’. Атрибуты S#, P#, J# в схеме отношения SPJ поддерживают связи отношений S, P и J. Любой кортеж SPJ можно трактовать как экземпляр связи этих отношений. Он представляет в БД реально существующий факт выполнения поставки конкретного вида детали конкретным поставщиком для конкретного изделия. Отношение SPJ – это пример механизма представления связей объектов в РМД.
Если объекты связаны, то первичные ключи соответствующих им отношений обязательно совмещаются в схеме какого-либо отношения[17]. В этой схеме они называются внешними ключами.
Определение 2.
Пусть В – базовое отношение и FK – некоторое подмножество атрибутов его схемы FK Ì B ( ).
FK
называется внешним ключом
(Foreign Key) отношения В, если
А) существует базовое отношение А с первичным ключом РК (Primary Key);
Б) каждое значение FK в текущем значении В
всегда совпадает со значением РК некоторого кортежа в текущем значении А.
Отношения А и В называются связанными. Отношение А называется родительским или ссылочным, В – потомком или ссылающимся. РК называют родительским (ссылочным) ключом. FK – ключом-потомком (ссылающимся).
Замечание 5. Определение не утверждает, что каждому значению РК из кортежа в текущем значении А должно соответствовать такое же значение FK в текущем значении отношения В.
Так, вполне допустимо такое состояние БД, в котором есть кортеж отношения S со значением S# = ‘S12’, но в отношении SPJ нет ни одного кортежа с таким значением S#. Это просто означает, что к настоящему моменту не зарегистрировано ни одной поставки, выполненной этим поставщиком.
Замечание 6. Состав атрибутов внешнего ключа должен совпадать с составом атрибутов родительского ключа. Точнее: множества PK и FK
пар (домен, атрибут) должны быть эквивалентны.
Так, атрибут SPJ.S# является внешним ключом отношения SPJ, ссылающимся на родительский ключ S.S#. Оба атрибута определены на одном и том же домене и имеют одинаковые имена

Внешний ключ и избирательность связи

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

Внутренние ограничения целостности РМД

. Выделяют три разновидности внутренних ОЦ: целостность домена, целостность сущности, ссылочная целостность.
2.3.5.1 Целостность домена. Домены являются одной из важнейших составляющих РМД. Механизм доменов обеспечивает:
· принципиальную возможность ограничения сравнений (см. п.2.2.2) и блокирования бессмысленных операций в БД;
· принципиальную возможность формального контроля ввода данных. Если предикат, определяющий домен, принял на вводимом значении атрибута значение .F., система не должна принимать это значение атрибута.
Таким образом, если система поддерживает домены, то она способна предотвратить грубые ошибки пользователя. Поэтому при проектировании концептуальной модели очень важно правильно определить домены всех хранимых атрибутов.
Правило целостности домена: всякий атрибут может принимать значения только из своего домена.
Это означает, что в любой РБД для каждого атрибута должно существовать правило, определяющее допустимость значений. Правило целостности домена – это метаправило, правило о правилах.

Возможные ключи

.
Свойство уникальности кортежей отношения РМД (см. п. 2.2.4) означает, в общем случае, что в схеме любого отношения R имеется подмножество атрибутов такое, что никакое значение этого отношения не содержит двух различных кортежей с одинаковым значением этого подмножества. Очевидно, таким подмножеством является все множество атрибутов. Однако, как правило, этим свойством обладают и меньшие подмножества.
Например, кортежи отношения S (см. рис. 2.3) уникальны, т.е. один и тот же набор значений всех атрибутов схемы не может встретиться дважды. По правилам нашей фирмы в списке наших поставщиков нет различных с одинаковыми номерами. Этим свойством обладает любое подмножество схемы S( ), содержащее атрибут S#, в том числе и одноэлементное {S#}.
Подобные подмножества атрибутов – возможные ключи отношения – обладают замечательным свойством. Указав значение возможного ключа, мы указываем на единственный кортеж отношения, содержащий это значение.
Определение 1. Пусть R( ) – схема отношения и K Ì R( ) – подмножество атрибутов схемы. Подмножество К называется возможным (потенциальным) ключом
отношения, если
А) в любой момент времени в текущем значении R нет двух кортежей с одинаковым значением К;
Б) никакое подмножество L Ì К не обладает свойством А).
Свойство А) называется свойством уникальности, а свойство Б) – свойством неизбыточности.
Возможный ключ отношения – это уникальное неизбыточное подмножество его атрибутов.
Возможные ключи обеспечивают основной механизм адресации на уровне кортежей в реляционной системе. Единственный гарантируемый РСУБД способ точно указать на какой-то кортеж – это задать значение какого-либо (любого) потенциального ключа.
Важно заметить, что понятие возможного ключа – логическое. Его не следует путать с физическим
понятием уникального индекса. Вовсе не обязательно должен существовать в ФБД индекс по потенциальному ключу. Какой-то специальный путь доступа в ФБД, конечно, есть, но этот путь – забота проектировщика физических структур, СУБД и ОС. Конечному пользователю о нем ничего знать не нужно.

Возможный ключ сущности

.
Сущность как множество не может иметь двух идентичных экземпляров по определению.
Подмножество атрибутов сущности, один и тот же набор значений которых не может встретиться в двух различных экземплярах, называется возможным ключом
сущности.
Например, подмножество атрибутов {номер зачетной книжки}
является возможным ключом сущности СТУДЕНТ. Не может быть двух различных студентов, номера зачетных книжек которых одинаковы. Сущность УЧЕБНАЯ ДИСЦИПЛИНА имеет два возможных ключа – {код} и {наименование}.
Возможные ключи являются механизмом идентификации экземпляров сущности. Указав значение ключа, мы, тем самым, указываем на конкретный экземпляр.

Вторая нормальная форма

(2НФ).
Приводя отношение USPJ
к системе отношений S, P, J, SPJ, мы выделили в отдельные отношения группы атрибутов, зависящих от части возможного ключа USPJ. Все неключевые атрибуты этих отношений функционально зависят от полных возможных ключей. При этом оказалось, что отношение SPJ содержит ссылки на отношения S, P и J
– внешние ключи.
Первый шаг процедуры нормализации состоит в выделении в отдельные отношения групп атрибутов, зависящих от части возможного ключа отношения 1НФ.
Этот шаг всегда может быть выполнен без потерь информации. Естественное соединение полученных в результате отношений будет эквивалентно исходному отношению[29].
Говорят, что отношение находится во второй нормальной форме, если и только если каждый его неключевой атрибут неприводимо зависит от первичного ключа.
Первый шаг процедуры нормализации приводит нормализуемое отношение к системе отношений, находящихся в 2НФ. Действительно, отношения S, P, J, SPJ, полученные нами после первого шага, удовлетворяют требованиям 2НФ.

Взятие разности отношений

Взятие разности отношений. Пусть отношения R1 и R2 совместимы по объединению. Отношение R называется разностью отношений R1
и R2, если его схема эквивалентна схемам операндов, а тело составлено только из кортежей R1, не принадлежащих R2.
R = R1
– R2 = {SR : R( ) = R1( ) = R2( ), SR Î R1 Ù SR
Ï
R2}.
Пример:

R1 =

R2 =

, R1 – R2 =

Базы данных: Разработка - Управление - Excel

область-определения ::= RANGE OF переменная IS список-элементов-области;
выражение ::= (список-целевых-элементов) [WHERE ппф] ;
целевой-элемент ::= переменная \| переменная.атрибут [AS атрибут];
ппф ::= условие \| NOT ппф \| условие AND ппф \| условие OR ппф \|IF условие THEN ппф \| EXISTS переменная (ппф) \| FOR ALL переменная (ппф) \| (ппф);
условие ::= (ппф) \| сравнение;
сравнение ::= символ q символ;
символ ::= переменная.атрибут \| константа;
q :: = < \| > \| =;

выражение ::= унарное-выражение \| бинарное-выражение;
унарное-выражение ::= переименование \| выборка \| проекция;
переименование ::= терм RENAME атрибут AS атрибут;
терм ::= отношение \| (выражение);
выборка ::= терм WHERE предикат;
предикат ::= сравнение \| предикат AND предикат \| предикат OR предикат \| NOT предикат[23];
сравнение ::= символ q символ;
символ ::= атрибут \| константа;
q ::= < \| > \| =;
проекция ::= терм \| терм [список];
бинарное-выражение ::= проекция бинарная-операция выражение;
бинарная-операция ::= UNION \| INTERSECT \| MINUS \| TIMES \| JOIN \| DIVIDEBY;