Понятия 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 Унарная связь. Отношение ссылается на себя

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

· Если нашим поставщикам присваиваются уникальные номера и не может быть двух различных поставщиков с одинаковыми именами, то в любом кортеже отношения 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).
В качестве первичного может быть выделен любой возможный ключ. Это решение проектировщика. Однако важно подчеркнуть, что при анализе данных в процессе проектирования БД необходимо выявить и указать все потенциальные ключи каждого отношения. Только так можно обеспечить отражение в модели соответствующих бизнес-правил. С другой стороны, объявляя все возможные ключи, аналитик указывает проектировщику ФБД все обусловленные семантикой пути быстрого доступа к данным.

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

. Здесь приведены формулы РИ кортежей, эквивалентные выражениям РА из примеров п. 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 основывается на смеси алгебраических и логических конструкций. Человек формулирует запрос в виде предиката, а система строит соответствующую процедуру вычисления требуемого результата.

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

Сформулируем средствами РА несколько запросов к БД «Поставщик–Деталь–Изделие» (см. рис. 2.3). В формулировках запросов ненужные круглые скобки будем опускать.

1) Получить полные сведения обо всех производимых изделиях.

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 совпадает со схемой отношения, произведенного выражением в правой части.

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

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

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

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

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

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

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

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

Проекция

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

Пусть 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

принимает значение .Т.

Ä R2

= sF(R1 ´ R2)[21].

Пример:

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 ( ).

называется внешним ключом

(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НФ.

это термин, обозначающий специальным образом

Словосочетание «база данных» – это термин, обозначающий специальным образом организованное компьютерное хранилище данных. Базы данных (БД) создаются для информационного обеспечения управления предприятием (бизнесом)[1].
Управление предприятием невозможно без достоверной информации о процессах, происходящих в области его деятельности. Так, производителю товаров нужно иметь сведения о наличии на его складах сырья и готовой продукции, о состоянии производственных подразделений, о контрагентах, поставщиках и заказчиках, о расчетах с ними, о спросе на свою продукцию, об эффективности рекламы и т.п. Коллекционеру марок нужна информация о выпущенных марках, их ценности, о других коллекционерах и их коллекциях... Все это – сведения о вполне определенной части реального мира, входящей в сферу интересов предприятия. Они и накапливаются в БД. При этом обязательно сохраняются все обусловленные логикой деятельности взаимосвязи фактов.
Сведения, хранящиеся в БД, находятся под контролем специальной системы управления базами данных (СУБД). Основные задачи СУБД – поддержание порядка в хранилище и обеспечение доступа к хранимой информации для просмотра, анализа и изменения. Однако, в отличие от файловых систем, также обеспечивающих накопление и хранение данных и доступ к ним, системы баз данных существенно опираются на смысл данных, используя его для организации структур хранения, поддержания целостности информации и выборки нужных пользователю сведений.
Технологии баз данных развиваются с начала 60-х годов и к настоящему времени оформились в инженерную дисциплину в рамках информатики. Она определяет:
·
архитектурные концепции систем баз данных;
· языковые средства определения и манипулирования данными – модели данных;
· методологии проектирования баз данных и их приложений;
· подходы к организации одновременного доступа к данным многих пользователей;
· методы защиты данных от разрушения и несанкционированного доступа.
Этот раздел информатики интенсивно развивается.
Ежегодно в мире публикуется около 100 000 страниц текстов, относящихся к технологиям баз данных [1]. В настоящем пособии (очень кратко) излагаются фундаментальные концепции и решения. Более подробные сведения можно найти в рекомендуемой литературе.
Изучая предлагаемый материал, следует иметь в виду, что всякая теория есть, прежде всего, система терминов. Автор считал своей основной задачей точное определение терминологии. Основная задача читателя – усвоить ее. Только владея терминами, вы сможете легко читать специальные тексты. Несмотря на то, что теории баз данных уже не менее тридцати лет, терминология в этой области еще не устоялась. Поэтому мы приводим все известные нам синонимы терминов и сознательно используем их на равных правах, полагая, что это поможет читателю при изучении литературы.

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

Взятие разности отношений. Пусть отношения R1 и R2 совместимы по объединению. Отношение R называется разностью отношений R1

и R2, если его схема эквивалентна схемам операндов, а тело составлено только из кортежей R1, не принадлежащих R2.

R = R1

– R2 = {SR : R( ) = R1( ) = R2( ), SR Î R1 Ù SR

R2}.

Пример:

R1 =

R2 =

, R1 – R2 =

область-определения ::= 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;