SELECT … SELECT…

FROM P, SP FROM P, SP

WHERE P. P#=SP. P# WHERE P. WEIGHT=SP. QTY

(имеет смысл) (не имеет смысла )

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

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

CREATE DOMAIN domain data_types;

*CREATE DOMAIN S# CHAR(5);

CREATE BASE relatin;

*CREATE BASE relatin S;

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

· домены имею уникальные имена в БД

· именованные отношения имеют уникальные имена в БД

· атрибуты имеют уникальные имена, содержащиеся в отношениях

DESTROY DOMAIN domain;

Отношения

Разграничим понятие переменная отношения и значение отношения. Переменная отношения, это обычная переменная такая же как и в языках программирования т. е. именованный объект, значение которого может изменятся со временем, а значение этой переменной в любой момент времени и будет значением отношения. Приведем формальное определение термина отношения: Отношение R определенное на множестве доменов D…Dn (не обязательно различных) содержит две части: заголовок и тело. Если представить отношение в терминах таблиц, то заголовок это строка заголовков столбцов, а тело – множество срок данных. Заголовок содержит фиксированное множество атрибутов или точнее пар <имя_атрибута:имя_домена>; {<A1:D1>,…,<An:Dn>}. Причем каждый атрибут Aj соответствует одному и только одному из лежащих в его основе доменов Dj (где j=1…n) . Все имена A1…An разные. Тело содержит множество картежей, а кортеж – множество пар <имя_атрибута:значение_атрибута>; {<A1,Vi1>…<An, Vin>} (i=1…m, m – количество кортежей). В каждом таком кортеже есть одна такая пара <имя_атрибута:значение_столбца>, т. е. <Aj:Vij> и для каждого атрибута Aj в заголовке. Для любой такой пары Vij является значением из уникального домена Dj который связан с Aj. Значения m и n называются соответственно кардинальным числом и степенью отношения R.

Уточним понятие переменной отношения. Например, перемен. R будет иметь разные значения в разное время однако всевозможные значения переменной R будут иметь одинаковые заголовки. Так заголовок базового отношения S выглядит так S={S#, SNAME, STATUS, CITY}. Лежащие в основе отношения домены не обязательно должны быть различны, не обязательно все различны, это означает, что несколько атрибутов в отношении могут иметь основой один домен.

P#	P#	QTY
P1	2	2
P1	3	4
P2	3	1
P2	4	3

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

Определение данных.

Определим синтаксис оператора CREATE BASE RELATION base_relation

(attribute definition-commalist, (1)

candidate-key-definition list, (2)

foreign-key-definition list) (3)

– список определения атрибутов разделённый запятыми. (2) – список определения потенциальных ключей. (3) – список определения внешних ключей.

Определение атрибута имеет форму: attribute DOMAIN (domain). Если опустить спецификацию DOMAIN (domain), то считается, что атрибут основан на домене с тем же именем.

Свойства отношений.

В любом отношении: 1) нет одинаковых кортежей. 2) кортежи не упорядочены сверху вниз. 3) атрибуты неупорядочены слева направо. 4) все значения атрибутов атамарные.

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

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

Это св-во следует из того факта, что заголовок отношения также определен как множество.

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

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

Виды отношений.

Именованные отношения – это переменное отношение, определённое в СУБД посредством операторов: create Base relation; create view; create snapshot.

Базовым отношением называется именованное отношение которое не является производным ( т. е. базовое отношение является автономным).

НЕ нашли? Не то? Что вы ищете?

Производным отношением называется отношение определённое посредством реляционного выражения через другие именованные отношения и в конечном счете через базовые отношения.

Представлением (view) называется именованное производное отношение. Представления виртуальны – они представлены в системе исключительно через определения в терминах других именованных отношений.

Снимки (snapshot) – это именованные производные отношения, однако в отличии от представлений снимки реальны, а не виртуальны.

Пример: create snapshot SC AS ((S JOIN P) WHERE P# =’P2’)[S, CITY] REFRESH EVERYDAY;

Результатом запроса называется неименованное производное отношение служащие результатом некоторого произвольного запроса, (результат при этом не сохраняется).

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

Пример: ((S JOIN P) WHERE P# =’P2’)[S, CITY]

S JOIN P = TEMP 1 первое промежуточное выражение

TEMP 1 WHERE P# = ‘P2’ =TEMP 2 второе промежуточное выражение

TEMP 2 [S, CITY] = TEMP 3 третье промежуточное выражение (конечный результат).

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

Хранимым отношением называется отношение, которое поддерживается в физической памяти непосредственным образом.

Отношения и предикаты.

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

Например: интерпретация отношений S может быть следующей: поставщик с номером (S#) имеет имя (SNAME) и определённое значение статуса (STATUS), и располагается в определённом городе (CITY), кроме того нет двух поставщиков с одинаковыми номерами.

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

Например: S# = S1 SNAME = ‘SMITH’ STATUS = 20 CITY = ‘LONDON’ (ИСТИНА)

S# = S1 SNAME = ABBEY’ STATUS = 45 CITY = ‘TUSCON’ (ЛОЖЬ)

В любой момент времени отношение содержит в точности те кортежи, при которых предикат является истинным. Т. образом предикат данного отношения составляет критерий возможности обновления для этого отношения т. е. критерий для решения явл-ся ли некоторое обновление допустимым для данного отношения. Для нашего примера СУБД считают кортеж приемлемым если выполнены следующие условия: значение S# принадлежит домену номеров поставщиков. Значение SNAME принадлежит домену имен. Значение STATUS принадлежит домену значения статуса. Значение CITY принадлежит домену названий городов.

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

Реляционные БД.

РБД – это БД воспринимаемая пользователем как набор формализованных отношений разной степени. Выражение “воспринимаемое пользователем” является решающим. Идея реляционной модели применяется к внешнему и концептуальному уровням системы, а не к внутреннему.

Потенциальные ключи.

Пусть r некоторое переменное отношение. Тогда потенциальный ключ k для r, это …

подмножество множества атрибутов r, всегда обладающие следующими свойствами:

свойствами уникальности (нет двух различных кортежей в текущем значении переменной r с одинаковым значением k)

свойством не избыточности (никакое из подмножеств k не обладает свойством уникальности).

Синтаксис определения потенциального ключа:

candidate key-definition

:: = CANDIDATE KEY

(attribute - commalist) |

PRIMARY KEY (attribute - commalist)

Терминология.

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

Замечание:

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

2. Потенциальные ключи определены как множество атрибутов, поэтому при ссылке используются фигурные скобки множества. {S#, P#} – потенциальный ключ SP

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

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

S WHERE S=’S5’

S WHERE CITY=’PARIS’

Первичный и альтернативный ключи.

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

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

Внешний ключ: Пусть R2 – базовое отношение. Тогда, внешний ключ FK в отношении R2 – подмножество множества атрибутов. R2 – такое, что существует базовое отношение R1 (R1 и R2 не обязательно различны) с потенциальным ключом СК. Каждое значение FK в текущем значении R2 всегда совпадает с текущим значением CK некоторого кортежа в текущем значении R1.

Пояснение:

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

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

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

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

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

Пример БД: «отделов и сотрудников» в упрощ. Форме.

Dpt (dept#, dname, budget)

Primary key (dept#)

Emp (emp#, ename, dept#, salary)

Primary key (emp#)

Foreign key(dept#) references dept

В этой БД аттрибут dept# отношение emp# являются внешним ключем соответственно первичному ключу dept# отношение dept

Однако он конечно не явл компонентом перв ключа ЕМР#

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

Отнош, которое содержит ключ наз ссылающимся отношением, а отнош, которое сод-т соотв потенц-й ключ наз - ся ссылочным отношением (целевым).

Cсылочные диаграммы

рассмотрим БД «поставщики и детали»

сущ в БД ссылочные ограничения можно представить ср-ми след ссыл. диаграммы.

SßSPàP

отношение может быть одновременно и ссылочным и ссылающимся, как в случае отнош R2 вслед диагр: R3àR2àR1

обобщая пример введем понятие ссылочный путь: RnàRn-1à. . . àR2àR1

заметим что отношения R1, R2 в определении внешних ключей не обязательно различны., т. е. некоторое отношение может включать внешний ключ, значения которого должны соответств-ть знач-м некоторых потен-х ключей в том же отношении. EMP (EMP#,…, SALARY,..,MGR_EMP#…

PRIMARY KEY (EMP#)

FOREIGN KEY (RENAME MGR_EMP# AS EMP#)

REFERENCES EMP

Такие отнош-я иногда наз-ся само ссылающимися.

рассмотренные отношения представ собой спец случай более общей ситуации, когда могут возникнуть ссылочные циклы RnàRn-1à. . . àR2àR1àRn

соответствие внешнего к потенциальному ключу иногда наз “клеем”, которое удержив БД как целое.

Введем правила ссылочной целостности: БД не должна содержать не согласованных знач-й внеш ключей.

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

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

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

Как избежать некорректных состояний?

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

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

Удалить поставщика, для которого существует хотя бы одна поставка.

Существует 2 возможности по (меньшей мере):

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

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

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

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

Foreign keyreferences base relation

Delete option

Update option

Параметр option может принимать значения

Restricted – ограничить

Cascades – каскадировать

Дать название всем возможным действиям не реально èпараметр option в нашем синтаксисе должен включать возможность вызова определенной при установке процедуры БД (хранимой процедуры)

NULL – значение

NULL – значение в БД предполагаются для решения проблемы отсутствующей информации.

Следовательно необходимо иметь некоторый подход когда сталкиваемся с такими ситуациями в формальных системах БД. Коддом был предложен подход к этой проблеме, в котором для представления отсутствующей информации использ спе-е маркеры NULL – значения. тогда если данный кортеж имеет NULL – значение в данной позиции атрибута следов-но в этом кортеже значение атрибутов по некоторой причине отсутствует. В случае введения NULL – значения синтаксис определения атрибута L оператора create base relation должен быть расширен для включения спецификации вида: NULL S ALLOWED; NULL S NOT ALLOWED

Если данному атрибуту не разрешено содержать NULL – значения система будет отвергать любые попытки NULL – значения в эту позицию.

Q СОЕДИНЕНИЕ:

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

(A TIMES B) WHERE XQY

Другими словами – это отношение с тем же заголовком, что и пр декартовом произведении отношений А и В и с телом содержащим множество кортежей t таких, что t принадлежит этому декартовому произведению и вычисление условия XQY дает значение ИСТИНА для этого кортежа. Атрибуты Х и У должны быть определены на одном и том же домене, а операция должна иметь смысл для этого домена.

Определим больше-соединение отношения S по атрибуту CITY с отношением P по атрибут CITY. Производим предварительное переименование атрибутов :

((S RENAME CITY AS SCITY) TIMES (P RENAME CITY AS PCITY)) WHERE SCITY>PCITY

В результате мы получаем :

S#	SNAME	STATUS	SCITY	P#	PNAME	COLOR	WEIGHT	PCITY
S2	JONES	10	PARIS	P1	Not	RED	12	LONDON
S2	-//-	-//-	-//-	P4	…..	……	……	-//-
S2	-//-	-//-	-//-	P6	…..	……	……	-//-
S3	BLAKE	30	-//-	P1	…..	……	……	-//-
S3	-//-	-//-	-//-	P4	…..	……	……	-//-
S3	-//-	-//-	-//-	P6	…..	……	……	-//-

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

Деление.

Пусть отношение А и В имеют заголовок

{X1,…,Xm, Y1,…,Yn} (A)

{Y1,…,Yn} (B)

соответственно, т.е. атрибуты Y1,Y2,…,Yn общие для двух отношений и отношение А имеет дополнительные атрибуты Х1,Х2,…,Хm. Отношения А и В представляют собой соответственно делимое и делитель. Предположим также, что соответствующие атрибуты определены на одном и том же домене. Пусть теперь выражение {X1,…,Xm} и {Y1,…,Yn} обозначают два составных атрибута Х и У соответственно. Тогда делением отношения А на В (A DEVIDBY B) называется отношение с заголовком {X} и телом, содержащим множество всех кортежей {X:x} таких, что существует кортеж {X:x, Y:y}, который принадлежит отношению А для всех кортежей {Y:y}, принадлежащих отношению В.

Нестрого это можно сформулировать так : результат содержит такие Х-значения из отношения А, для которых соответствующие У-значения из А включают все У-Значения из отношения В.

DOR

DEND

DEND DEVIDBY DOR

Примеры использования реляционной алгебры.

1. Получить имена поставщиков, которые поставляют деталь P2

Из за большого объема этот материал размещен на нескольких страницах:
1 2 3

Введение в БД (стр. 2 )