Полная функциональная зависимость

К ключ, А1, A2,... An – некоторые атрибуты в отношении R. Пусть А1, A2,... An Î К (т.е. имеем составной ключ)

Полной функциональной зависимостью неключевых атрибутов B1, B2,… Bm называется такая зависимость, при которой каждый B1, B2,… Bm функционально зависит от K (т.е. от всей совокупности атрибутов ключа), но не находится в функциональной зависимости ни от какой части составного ключа.

Пример. В отношении Университет можно привести следующие примеры полных функциональных зависимостей:

{ Caf, Disp, Cat } ® FIO

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

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

Многозначная зависимость Атрибут A однозначно определяет атрибут B, если для каждого значения атрибута A существует хорошо определенное множество соответствующих значений атрибута B.

 

Первая нормальная форма (1НФ) - это обычное отношение. Согласно нашему определению отношений, любое отношение автоматически уже находится в 1НФ. Напомним кратко свойства отношений (это и будут свойства 1НФ):

• В отношении нет одинаковых кортежей.
• Кортежи не упорядочены.
• Атрибуты не упорядочены и различаются по наименованию.
• Все значения атрибутов атомарны.

Отношение, представленное в табл. 30 служит примером отношения, находящегося в 1НФ.

 

Отношение R находится во второй нормальной форме (2НФ) тогда и только тогда, когда отношение находится в 1НФ и все ее поля, не входящие а первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Т.е. любое неключевое поле однозначно идентифицируется полым набором ключевых полей.

Замечание. Если потенциальный ключ отношения является простым, то отношение автоматически находится во 2НФ.

Таблица, находящаяся во 2НФ должна удовлетворять следующим требованиям:

1) Таблица должна содержать данные об одном типе объектов;

2) Каждая таблица должна содержать одно поле или несколько полей, образующих уникальный идентификатор или первичный ключ для каждой строки;

3) Все, не входящие в первичный ключ поля, должны однозначно определяться этим ключом;

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

Если таблица не находится во 2НФ, то нужно выполнить ее декомпозицию.

Для нашего примера результатом декомпозиции табл. 30 будет:

CafedraPersons

ID_Caf	Caf	Phone		Tab_N_S	FIO
	ВТ				Ланцов В.Н.
	ИСИМ				Мамаев А.А
	ИЗИ				Буланкин В.Б.
		Алешкин А.А.

Disciplines

ID_Disp	Disp	Cat
	САПР	ЛК
	САПР	ПР
	АрхЭВМ	ЛК
	АрхЭВМ	КП
	ЗИ	ЛК
	ЗИ	ЛБ
	Инф-ка	ПР

 

Отношение R находится в третьей нормальной форме (3 НФ) тогда и только тогда, когда отношение находится во 2НФ и ни одно из ее неключевых полей функционально не зависит от любого другого неключевого поля. Или другими словами, таблица находится в 3НФ, если она находится во 2НФ и каждое ее неключевое поле нетранзитивно зависит от первичного ключа.

 

Очевидно, что для нашего примера все таблицы удовлетворяют условию 3НФ, кроме отношения Disciplines. Т.к. категория занятия, вообще говоря, зависит от вида дисциплины. Поэтому его надо разбить на 2 более мелких отношения:

Disciplines Categories

ID_Disp	Disp	ID_Cat		ID_Cat	Cat
	САПР				ЛК
	САПР				ПР
	АрхЭВМ				ЛБ
	АрхЭВМ				КП
	ЗИ
	ЗИ
	Инф-ка

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

 

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

 

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

5.6 Элементы модели "сущность-связь"

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

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

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

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

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

Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом [37]. В дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства, реализующие одну и ту же нотацию, могут отличаться своими возможностями. По сути, все варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового описания. Все такие диаграммы используют графическое изображение сущностей предметной области, их свойств (атрибутов), и взаимосвязей между сущностями.

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

Основные понятия ER-диаграмм

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

Каждая сущность должна иметь наименование (Name), выраженное существительным в единственном числе.

Примерами сущностей могут быть такие классы объектов как "Сотрудник", "Дисциплина", "Кафедра".

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

Рис. 10

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

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

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

Атрибут сущности (Attribute) это именованная характеристика, являющаяся некоторым свойством сущности.

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

Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия" и т.д.

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

Рис. 11

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

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

Рис. 12

Связь (Relationship) это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою.

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

Например, связи между сущностями могут выражаться следующими фразами - "СОТРУДНИКИ читают ДИСЦИПЛИНЫ ", "каждый СОТРУДНИК принадлежит одной КАФЕДРЕ".

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

Рис. 13

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

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

Ошибка! Ошибка связи.

Рис. 14

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

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

Левая сущность (со стороны "один") называется родительской (Parent-to-Child), правая (со стороны "много") – дочерней (Child-to- Parent). Пример такой связи приведен на рис. 13.

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

Каждая связь может иметь одну из двух модальностей связи (Relationship Type):

Рис. 15

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

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

Связь может иметь разную модальность с разных концов (как на рис. 13).

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

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

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

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

Справа налево: "Каждую дисциплину обязан вести ровно один сотруднику".

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

1) Список сущностей предметной области.

2) Список атрибутов сущностей.

3) Описание взаимосвязей между сущностями.

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

Выводы: Реальным средством моделирования данных является не формальный метод нормализации отношений, а так называемое семантическое моделирование. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship). Диаграммы сущность-связь позволяют использовать наглядные графические обозначения для моделирования сущностей и их взаимосвязей.

Различают логические и физические ER-диаграммы.

Логические не учитывают особенностей конкретных СУБД.

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

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

 

 

Элементы языка SQL

Текущая версия стандарта языка SQL принята в 1992 г. (Официальное название стандарта - Международный стандарт языка баз данных SQL (1992) (International Standart Database Language SQL), неофициальное название - SQL/92, или SQL-92, или SQL2). Документ, описывающий стандарт, содержит более 600 страниц. Мы дадим только некоторые понятия языка.

Операторы SQL

Основу языка SQL составляют операторы, условно разбитые не несколько групп по выполняемым функциям.

Группы операторов (перечислены не все операторы SQL):

1) Операторы DDL (Data Definition Language) - операторы определения объектов базы данных

· CREATE SCHEMA/ DROP SHEMA – создать/удалить схему базы данных

· CREATE TABLE/ALTER TABLE/ DROP TABLE - создать таблицу/изменить таблицу/удалить таблицу

· CREATE DOMAIN/ALTER DOMAIN/DROP DOMAIN - создать домен/изменить домен/удалить домен

· и др.

2) Операторы DML (Data Manipulation Language) - операторы манипулирования данными

· SELECT - отобрать строки из таблиц

· INSERT - добавить строки в таблицу

· UPDATE - изменить строки в таблице

· DELETE - удалить строки в таблице

· COMMIT - зафиксировать внесенные изменения

• ROLLBACK - откатить внесенные изменения

3) Операторы защиты и управления данными

· CREATE ASSERTION - создать ограничение

· DROP ASSERTION - удалить ограничение

· GRANT - предоставить привилегии пользователю или приложению на манипулирование объектами

· REVOKE - отменить привилегии пользователя или приложения

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

Наиболее важными для пользователя являются операторы манипулирования данными (DML).

Типы данных

В языке SQL/89 поддерживаются следующие типы данных: CHARACTER, NUMERIC, DECIMAL, INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION. Эти типы данных классифицируются на типы строк символов, целых чисел и дробных чисел.

 

Спецификатор типа CHARACTER имеет вид

CHARACTER(lenght)

где lenght задает длину строк данного типа. Заметим, что в SQL/89 нет типа строк переменного размера, хотя во многих реализациях они допускаются. Строки символов изображаются в виде 'последовательность символов' (например, 'example').

Представителями второго класса типов являются NUMERIC, DECIMAL (или DEC), INTEGER (или INT) и SMALLINT. Спецификатор типа NUMERIC имеет вид

NUMERIC[(precision[,scale])].

где precision – точность, scale - масштаб. Здесь и далее, если опущен масштаб, то он полагается равным 0, а если опущена точность, то ее значение по умолчанию определяется в реализации.

Спецификатор типа DECIMAL (или DEC) специфицируют точные числа, представленные с масштабом scale и точностью, равной или большей значения precision.

DECIMAL[(precision[,scale])]

 

Значения целых чисел в общем случае представляются в форме

[+|-]<целое-без-знака>

Наконец, в классу типов данных дробных чисел относятся типы FLOAT, REAL и DOUBLE PRECISION. Спецификатор типа FLOAT имеет вид

FLOAT[(precision)]

где precision – точность.

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

<целое-число>E<целое-со-знаком>

Заметим, что хотя с использованием языка SQL можно определить схему БД, содержащую данные любого из перечисленных типов, возможность использования этих данных в прикладных системах зависит от применяемого языка программирования. Хотя правила встраивания SQL в программы на языке Си не определены в SQL/89, в большинстве реализаций, поддерживающих такое встраивание, имеется следующее соответствие между типами данных SQL и типами данных Си:

CHARACTER соответствует строкам Си;

INTEGER соответствует long;

SMALLINT соответствует short;

REAL соответствует float;

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

6.2.1 Операторы работы с таблицами

Синтаксис оператора создания таблицы (синтаксис приведен не полностью)

CREATE TABLE < имя_таблицы>

({ определение_столбца |[ ограничение_таблицы ]}.,..)

<определение столбца>::=

<имя_столбца> {< имя_домена> |< тип_данных> }

[ ограничение_столбца… ]

[ DEFAULT <з начение_по_умолчанию> ]

 

<ограничение_столбца> может быть любым из следующих:

NOT NULL (НЕ НУЛЕВОЙ)

UNIQUE (УНИКАЛЬНЫЙ)

PRIMARY KEY (ПЕРВИЧНЫЙ КЛЮЧ)

DEFAULT=<выражение> (ПО УМОЛЧАНИЮ = выражению)

REFERENCES <имя_таблицы> (ССЫЛКА НА <имя_таблицы>[(<имя_столбца>)])

[(<имя_столбца>.,..)]

 

<ограничение таблицы> может быть любым из следующих:

UNIQUE (УНИКАЛЬНЫЙ)

PRIMARY KEY (ПЕРВИЧНЫЙ КЛЮЧ)

FOREIGN KEY(<column name>) (ВНЕШНИЙ КЛЮЧ)

REFERENCES <имя_таблицы> (ССЫЛКА НА <имя_таблицы>[(<имя_столбца>)])

[(<имя_столбца>.,..)]

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

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

Примеры

CREATE TABLE Cafedra(ID_Caf INTEGER NOT NULL PRIMARY KEY, Caf CHAR(10), Phone INTEGER(6) NOT NULL)

можно и так:

CREATE TABLE "Cafedra" ("ID_Caf" INTEGER NOT NULL, "Caf" CHAR(10), "Phone" INTEGER NOT NULL, PRIMARY KEY("ID_Caf"));

 

CREATE TABLE Disciplines(ID_Disp INTEGER PRIMARY KEY, Disp CHAR, ID_Cat REFERENCES Categories(ID_Cat))

 

Синтаксис оператора изменения таблицы (синтаксис приведен не полностью)

ALTER TABLE < имя таблицы>

{ ADD [ COLUMN ] < определение столбца> }

| { ALTER [ COLUMN ] < имя_столбца> { SET DEFAULT < значение_по_умолчанию> | DROP DEFAULT }}

| { DROP [ COLUMN ] < имя_столбца> RESTRICT | CASCADE }

| { ADD < ограничение таблицы> }

| { DROP CONSTRAINT < имя_ограничения> RESTRICT | CASCADE }

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

DROP TABLE < имя_таблицы > CASCADE | RESTRICT

Удалить имеющуюся таблицу. Вместе с таблицей удаляются и ограничения, определенные для этой таблицы.

RESTRICT – таблица удаляется, только если нет никаких ссылок на эту таблицу в других ограничениях или представлениях.

CASCADE – удаляются также и все объекты, ссылающиеся на эту таблицу.

 

Синтаксис определения домена

CREATE DOMAIN имя_домена [ AS ] тип_данных

[ DEFAULT значение_по_умолчанию ]

[ имя_ограничения ] ограничение check [ атрибуты_ограничения ]

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

Пример Приведенный ниже оператор создает домен MyDomen на основе целочисленного типа данных, причем значения из этого домена не могут принимать неположительные значения (но могут принимать значение NULL!).

CREATE DOMAIN MyDomen AS integer CHECK (VALUE > 0)

 

Изменение имеющегося домена

ALTER DOMAIN имя_домена

{ SET DEFAULT значение_по_умолчанию }

| { DROP DEFAULT }

| { ADD [ имя_ограничения ] ограничение check [ атрибуты_ограничения ]}

| { DROP CONSTRAINT имя_ограничения }

Стандарт запрещает вносить несколько изменений одной командой ALTER DOMAIN. Т.е. если требуется удалить ограничение CHECK и добавить значение по умолчанию, то придется выполнить два оператора ALTER DOMAIN.

Уничтожение домена

DROP DOMAIN имя_домена CASCADE | RESTRICT

RESTRICT – домен не уничтожается, если имеются ссылки на него из столбцов таблиц.

CASCADE, то происходят следующие действия:

· Тип данных домена передается столбцам, основанным на этом домене.

· Если столбец не имеет значения по умолчанию, а для домена значение по умолчанию определено, то оно становится значением по умолчанию для столбца.

· Все ограничения домена становятся ограничениями столбца.