1. Достоверность. Необходимо следить, чтобы элементы модели четко соответствовали требованиям предметной области.
2. Отсутствие избыточности. Необходимо следить, чтобы элементы модели не повторяли друг друга.
3. Простота. В модель следует включать только те элементы, без которых действительно нельзя обойтись.
4. Выбор подходящих связей. Включение в модель всех возможных связей между сущностями может привести к избыточности модели.
5. Использование элементов адекватных типов. Основной вопрос, который должен быть решен – как отражать факт предметной области при помощи атрибута или сущности. Атрибут легче реализовать и быстрее обрабатывать, однако этот подход может привести к несогласованности данных. Выбор подхода зависит от цели создания информационной системы.
Переход от концептуальной схеме базы данных к внутренней, учитывающей особенности выбранной модели данных и СУБД.
При переходе от концептуальной схемы в нотации «сущность-связь» к внутренней схеме в реляционной модели данных выполняются следующие правила:
1) Каждая сущность преобразуется в отдельное отношение с соответствующими атрибутами;
2) Связь «один-к-одному» реализуется либо слиянием двух отношений, либо связью «один-ко-многим» с определением дополнительной целостности с помощью триггеров (триггер – программа, выполняемая при модификации данных отношения с целью поддержания целостности данных). Триггеры определяются вместе со схемой БД на специальном алгоритмическом языке, предоставляемым конкретной СУБД.
3) Связи «многие-ко-многим» и связи степенью 2 реализуется созданием ассоциативных отношений, первичный ключ которых образуется копированием первичных ключей из связанных отношений.
4) Иерархии категорий преобразуются одним из двух способов:
а) в одно отношение для всей иерархии с последующей разработкой правил целостности, поддерживающих ограничения назначения атрибутов;
б) в отдельное отношение для главной сущности и для каждой из категорий. Это также требует разработки правил целостности, но они касаются нескольких сущностей.
Модель данных (по Дейту) – абстрактное, самодостаточное логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину, с которой взаимодействует пользователь. Объекты позволяют моделировать структуру данных, а операторы – поведение данных.
Модель данных (по Кузнецову, в контексте БД) описывает набор родовых понятий и признаков, которыми должны обладать все конкретные СУБД и управляемые ими БД, если они основываются на этой модели. Наличие общей модели данных позволяет сравнивать конкретные реализации.
Модель данных (по Конноли) – интегрированный набор понятий для описания и обработки данных, связей между ними и ограничений, накладываемых на данные в некоторой предметной области.
По Дейту, реляционная модель данных включает следующие аспекты:
- структурный аспект,
- аспект обработки,
- аспект целостности.
Структурный аспект реляционной модели.
Отношение – таблица, состоящая из строк и столбцов, отношения представляют в БД классы объектов реального мира. Синонимы: таблица, файл, сущность.
Домен – набор допустимых значений для одного или нескольких атрибутов. Аналогичен типу в языках программирования, то есть подразумевает допустимые отношения и набор операций с ними.
Кортеж – строка отношения. Кортеж соответствует объекту реального мира, принадлежащего некоторому классу. Синонимы: запись, строка.
Степень отношения – количество атрибутов в отношении.
Кардинальность отношения – количество его кортежей.
Пример отношения:
Таб. Номер
ФИО
Должность
Непосредственный начальник
Иванов
Директор
Null
Петров
Начальник отдела 1
Сидоров
Начальник отдела 2
Козлов
Инженер
Мартынов
Работник по договору
Null
Плынский
Инженер
Нормализованное отношение – отношение, структура которого определяется при помощи особых методов устранения избыточности и взаимозависимости в данных. Связанные понятия: нормальные формы, нормализация отношений, алгоритмы декомпозиции.
Реляционная БД – набор нормализованных отношений.
Реляционной схемой называется имя отношения, за которым следует множество пар имен атрибутов и доменов. Например, для атрибутов А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-значение всегда одного типа, а интерпретация зависит от пользователя.
