Именно так в некоторых пост реляционных СУБД реализована работа со сколь угодно сложными типами данных, создаваемых пользователями.
В реляционной модели данных с понятием тип данных тесно связано понятие домена, которое можно считать уточнением типа данных.
Домен - это семантическое понятие. Домен можно рассматривать как подмножество значений некоторого типа данных имеющих определенный смысл. Домен характеризуется следующими свойствами:
· Домен имеет уникальное имя (в пределах базы данных).
· Домен определен на некотором простом типе данных или на другом домене.
· Домен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена.
· Домен несет определенную смысловую нагрузку.
Например, домен , имеющий смысл "возраст сотрудника" можно описать как следующее подмножество множества натуральных чисел:
Если тип данных можно считать множеством всех возможных значений данного типа, то домен напоминает подмножество в этом множестве.
Отличие домена от понятия подмножества состоит именно в том, что домен отражает семантику, определенную предметной областью. Может быть несколько доменов, совпадающих как подмножества, но несущие различный смысл. Например, домены "Вес детали" и "Имеющееся количество" можно одинаково описать как множество неотрицательных целых чисел, но смысл этих доменов будет различным, и это будут различные домены.
Основное значение доменов состоит в том, что домены ограничивают сравнения. Некорректно, с логической точки зрения, сравнивать значения из различных доменов, даже если они имеют одинаковый тип. В этом проявляется смысловое ограничение доменов. Синтаксически правильный запрос "выдать список всех деталей, у которых вес детали больше имеющегося количества" не соответствует смыслу понятий "количество" и "вес".
Замечание. Понятие домена помогает правильно моделировать предметную область. При работе с реальной системой в принципе возможна ситуация когда требуется ответить на запрос, приведенный выше. Система даст ответ, но, вероятно, он будет бессмысленным.
Замечание. Не все домены обладают логическим условием, ограничивающим возможные значения домена. В таком случае множество возможных значений домена совпадает с множеством возможных значений типа данных.
Фундаментальным понятием реляционной модели данных является понятие отношения. В определении понятия отношения будем следовать книге К. Дейта
Определение 1. Атрибут отношения есть пара вида <Имя_атрибута : Имя_домена>.
Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами соответствующих доменов.
Определение 2. Отношение , определенное на множестве доменов (не обязательно различных), содержит две части: заголовок и тело.
Заголовок отношения содержит фиксированное количество атрибутов отношения:
Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида <Имя_атрибута : Значение_атрибута>:
таких что значение атрибута принадлежит домену
Отношение обычно записывается в виде:
,
или короче
,
или просто
.
Число атрибутов в отношении называют степенью отношения.
Мощность множества кортежей отношения называют мощностью отношения.
Возвращаясь к математическому понятию отношения, введенному в предыдущей главе, можно сделать следующие выводы:
Вывод 1. Заголовок отношения описывает декартово произведение доменов, на котором задано отношение. Заголовок статичен, он не меняется во время работы с базой данных. Если в отношении изменены, добавлены или удалены атрибуты, то в результате получим уже другое отношение (пусть даже с прежним именем).
Вывод 2. Тело отношения представляет собой набор кортежей, т.е. подмножество декартового произведения доменов. Таким образом, тело отношения собственно и является отношением в математическом смысле слова. Тело отношения может изменяться во время работы с базой данных - кортежи могут изменяться, добавляться и удаляться.
i. Предварительная структура базы данных, нормализация
Прежде чем начать проектирование базы данных, необходимо определиться какие данных нам необходимо хранить и их взаимосвязь.
Таблица 4.1 Поля таблицы QUESTIONS
| QUESTIONS – список вопросов | ||
| ID | Integer | Идентификатор вопроса |
| Q_TEXT | BLOB | Текст вопроса |
| QPICTURE | BLOB | Граф. часть к вопросу |
| CID | INTEGER | Категория вопроса |
| Q1 | SMALLINT | Балл за вариант ответа |
| Q2 | SMALLINT | Балл за вариант ответа |
| Q3 | SMALLINT | Балл за вариант ответа |
| Q4 | SMALLINT | Балл за вариант ответа |
| Q5 | SMALLINT | Балл за вариант ответа |
| Q6 | SMALLINT | Балл за вариант ответа |
| Q7 | SMALLINT | Балл за вариант ответа |
| Q8 | SMALLINT | Балл за вариант ответа |
| Q9 | SMALLINT | Балл за вариант ответа |
Таблица 4.2 Поля таблицы USERS
| USERS – список специалистов | ||
| ID | INTEGER | Идентификатор специалиста |
| GID | INTEGER | Принадлежность пользователя к группе |
| TID | INTEGER | Принадлежность пользователя к типу |
| LOGIN | VARCHAR | Ф.И.О специалиста |
| PWD | VARCHAR | Пароль специалиста |
Таблица 4.3 Поля таблицы STORE
| STORE – данные специалиста | ||
| ID | INTEGER | Идентификатор специалиста |
| UID | INTEGER | Отвечавший пользователь |
| CID | INTEGER | Категория вопросов |
| DATED | VARCHAR | Дата аттестации |
| PERCS | SMALLINT | Результат в % |
Таблица 4.4 Поля таблицы TYPES
| TYPES – Типы пользователя | ||
| ID | INTEGER | Идентификатор пользователя |
| FLAGS | INTEGER | Признак ответа |
| NAME | VARCHAR | Название типа |
Таблица 4.5 Поля таблицы QGROUPS
| QGROUPS – Категории вопросов | ||
| ID | INTEGER | Идентификатор пользователя |
| NAME | VARCHAR | Категория вопроса |
Таблица 4.6 Поля таблицы GROUPS
| QGROUPS – Группы пользователей | ||
| ID | INTEGER | Идентификатор пользователя |
| NAME | VARCHAR | Категория группы |
Таблица 4.7 Поля таблицы ASESSIONS
| ASESSIONS – Активные сессии | ||
| ID | INTEGER | Идентификатор пользователя |
| UID | INTEGER | Отвечавший пользователь |
| NAME | VARCHAR | Ф.И.О пользователя |
| CHOOSENGROUPS | BLOB | Номера выбранной категории |
| GROUPSRP | BLOB | Формат отвеченных вопросов |
Отношение находится в Первой Нормальной Форме (1НФ), если оно содержит только скалярные (атомарные) значения [ ].
Отношение находится во второй нормальной форме (2НФ) тогда и только тогда, когда отношение находится в 1НФ и нет не ключевых атрибутов, зависящих от части сложного ключа. (Неключевой атрибут - это атрибут, не входящий в состав никакого потенциального ключа).
Замечание. Если потенциальный ключ отношения является простым, то отношение автоматически находится в 2 НФ.
ii. Окончательная структура базы данных
Структура базы данных разработана с использованием Case-средства фирмы Platinum – ErWin 3.5.2. и представлена на рисунке 4.1. Описания таблиц базы данных даны в таблице 4.8.