Смекни!
smekni.com

Диплом Программная система Аттестации ИТ-специалистов (стр. 7 из 15)

Именно так в некоторых пост реляционных СУБД реализована работа со сколь угодно сложными типами данных, создаваемых пользователями.

Домены

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

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

· Домен имеет уникальное имя (в пределах базы данных).

· Домен определен на некотором простом типе данных или на другом домене.

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

· Домен несет определенную смысловую нагрузку.

Например, домен , имеющий смысл "возраст сотрудника" можно описать как следующее подмножество множества натуральных чисел:

Если тип данных можно считать множеством всех возможных значений данного типа, то домен напоминает подмножество в этом множестве.

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

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

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

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

Отношения, атрибуты, кортежи отношения

Определения и примеры

Фундаментальным понятием реляционной модели данных является понятие отношения. В определении понятия отношения будем следовать книге К. Дейта

Определение 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.


Таблица 4.8 Описание таблиц

Название таблицы

Назначение

Примечание

QGROUPS Список категорий вопросов Для этой таблицы создан генератор и триггер для получения уникального идентификатора
QESTIONS Список вопросов Для этой таблицы создан генератор и триггер для получения уникального идентификатора
USERS Список специалистов, имя и пароль Для этой таблицы создан генератор и триггер для получения уникального идентификатора
GROUPS Список групп специалистов Для этой таблицы создан генератор и триггер для получения уникального идентификатора
TYPES Список типов пользователей. Для этой таблицы создан генератор и триггер для получения уникального идентификатора
ASESSION Хранит признак открытой сессии специалистом и дату/время начала сессии

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