Реляционная модель данных.

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

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

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

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

- структурный аспект,

- аспект обработки,

- аспект целостности.

Структурный аспект реляционной модели.

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

Атрибут – поименованный столбец отношения, атрибут соответствует характеристике класса. Синоним: поле.

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

Кортеж – строка отношения. Кортеж соответствует объекту реального мира, принадлежащего некоторому классу. Синонимы: запись, строка.

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

Кардинальность отношения – количество его кортежей.

Пример отношения:

Таб. Номер	ФИО	Должность	Непосредственный начальник
1	Иванов	Директор	Null
2	Петров	Начальник отдела 1	1
3	Сидоров	Начальник отдела 2	1
4	Козлов	Инженер	2
5	Мартынов	Работник по договору	Null
6	Плынский	Инженер	3

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

Реляционная БД – набор нормализованных отношений.

Реляционной схемой называется имя отношения, за которым следует множество пар имен атрибутов и доменов. Например, для атрибутов А1, А2, …, Аn, определенных на доменах D1, D2,…, Dn можно определить отношение: R(A1:D1,A2:D2,…, An:Dn).

Сотрудник (Табельный номер: целое,

Имя: строка из 100 символов,

Дата рождения: дата).

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

1. Отношение имеет уникальное в рамках БД имя.

2. Каждый атрибут имеет атомарное значение. В ряде СУБД разрешено нарушение этого свойства.

3. Каждый атрибут имеет уникальное в рамках отношения имя.

4. Значения атрибута берутся из одного и того же домена для всех кортежей отношения.

5. Порядок следования атрибутов отношения не имеет значения.

Проект (код, название, стоимость, дата начала, дата завершения, табельный номер).

Проект (код, стоимость, дата начала, дата завершения, название, табельный номер).

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

7. Порядок следования кортежей отношения не имеет значения – верно только с теоретической точки зрения.

Ключи отношений.

Рассмотрим пример:

Сотрудник (Табельный номер: целое,

Имя: строка из 100 символов,

Дата рождения: дата).

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

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

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

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

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

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

Неопределенные значения.

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

1) использование значений по умолчанию.

2) неопределенные значения (null-значения) и трехзначная логика.

При этом говорят, например, деталь имеет вес, но этот вес неизвестен.

Скалярное сравнение. Если в качестве одного из операндов сравнения выступает null-значение, то в результате получится значение неизвестно (unknown). При этом действуют следующие правила: A>B и если значение операнда А неизвестно, то результат сравнения всегда unknown, независимо от значения В.

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

Логические операции.

В СУБД значения unknown в зависимости от контекста могут заменяться на значения null или false. Некоторые СУБД позволяют явную замену null-значения на значение по умолчанию, свои для каждого типа данных, то есть отказ от трехзначной логики.

Следствия трехзначной логики:

1)х=х, необязательно истинно,

2) p or not p необязательно истинно,

При двузначной логике объединение двух запросов «выдать всех людей, живущих в Орле» и «всех людей, не живущих в Орле» должно описывать всех людей.

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

Интерпретация: БД содержит не реальный мир, а наши знания о реальном мире. Знания о проживании каких-то людей в БД нет, следовательно, они и не попали в результат запросов.

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

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

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