Логическая модель базы данных

3.2 Логическая модель базы данных

Проектирование реализации БД(логическое проектирование) представляет собой трансформацию концептуальной модели в набор отношений в нормальной форме Бойса-Кодда(НФБК). Для приведения спроектированного универсального отношения в НФБК воспользуемся декомпозиционным методом проектирования, содержанием которого является описание семантики универсального отношения в терминах функциональных зависимостей(ФЗ) и использование последних для нормализации отношения.

Введем следующие понятия: функциональная зависимость, ключ, первичный ключ, детерминант, НФБК.

Если даны два атрибута A и B, то говорят, что B функционально зависит от A (обозначается A à B), если для каждого A существует ровно одно связанное с ним значение B. A и B могут быть не только единичными атрибутами, но и группами из двух и более атрибутов.

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

Первичный ключ используется для уникальной идентификации кортежа.

Детерминант. Если в ФЗ A à B B не зависит от любого подмножества A(т.е. функциональная зависимость полна), то A является детерминантом B.

НФБК определяется следующим образом: отношение находится в НФБК, если каждый детерминант отношения является ключом. Проверим находится ли универсальное отношение R(ТЕМА№, ТЕМА, ВОПРОС№, ВОПРОС, ОТВЕТ№, ОТВЕТ, ИСТИННОСТЬ) в НФБК.

Выпишем ФЗ для универсального отношения:

ТЕМА№ à ТЕМА,

ТЕМА№, ВОПРОС№ à ВОПРОС,

ВОПРОС№, ОТВЕТ№ à ОТВЕТ,

ВОПРОС№, ОТВЕТ№ à ИСТИННОСТЬ.

Из записанных ФЗ видно, что рассматриваемое отношение имеет только один ключ, а именно набор атрибутов < ТЕМА№, ВОПРОС№, ОТВЕТ№>. То есть это минимальный набор значений атрибутов, которые, если они известны, определяют значения других атрибутов кортежа. Детерминантами отношения являются левые части всех ФЗ, а именно: <ТЕМА№>, <ТЕМА№, ВОПРОС№>, <ВОПРОС№, ОТВЕТ№>.

Легко обнаружить, что ни один детерминант не является ключом. Из чего следует, что рассматриваемое отношение не находится в НФБК и подлежит декомпозиции.

Алгоритм декомпозиционного проектирования выглядит так:

1) разрабатывается универсальное отношение для БД;

2) определяются все ФЗ между атрибутами отношения;

3) определяется, находится ли отношение в НФБК. Если ДА, то проектирование завершено, если НЕТ, отношение должно быть разложено на два;

4) шаги 2 и 3 повторяются для каждого нового отношения, полученного в результате декомпозиции. Проектирование завершается, когда все отношения будут находиться в НФБК.

Детерминант <ВОПРОС№, ОТВЕТ№> не является ключом и имеет два зависимых от него атрибута

ВОПРОС№, ОТВЕТ№ à ОТВЕТ

ВОПРОС№, ОТВЕТ№ à ИСТИННОСТЬ,

что можно рассматривать в качестве единичной ФЗ с составными правой и левой частями ВОПРОС№, ОТВЕТ№ à ОТВЕТ,ИСТИННОСТЬ.

Таким образом, получаются два новых отношения R1 и R2:

R1(ТЕМА№, ТЕМА, ВОПРОС№, ВОПРОС)

ФЗ: ТЕМА№ à ТЕМА,

ТЕМА№, ВОПРОС№ à ВОПРОС.

Возможные ключи: <ТЕМА№, ВОПРОС№>.

Детерминанты:<ТЕМА№>,< ТЕМА№,ВОПРОС№>.

R2(ВОПРОС№, ОТВЕТ№, ОТВЕТ, ИСТИННОСТЬ)

ФЗ: ВОПРОС№, ОТВЕТ№ à ОТВЕТ,ИСТИННОСТЬ.

Возможные ключи: <ВОПРОС№, ОТВЕТ№>.

Детерминанты: <ВОПРОС№, ОТВЕТ№>.

Отношение R2(ВОПРОС№, ОТВЕТ№, ОТВЕТ, ИСТИННОСТЬ) находится в НФБК, т.к. его детерминант является ключом, а потому в дальнейшей декомпозиции не нуждается.

В отношении R1(ТЕМА№, ТЕМА, ВОПРОС№, ВОПРОС) детерминант <ТЕМА№> не является возможным ключом, поэтому R1 не находится в НФБК и подлежит дальнейшему расщеплению. Результатом расщепления отношения R1 являются отношения R3,R4:

R3(ТЕМА№, ВОПРОС№, ВОПРОС)

ФЗ: ТЕМА№, ВОПРОС№ à ВОПРОС.

Возможные ключи: <ТЕМА№, ВОПРОС№ >.

Детерминанты: <ТЕМА№, ВОПРОС№ >.

R4(ТЕМА№, ТЕМА)

ФЗ: ТЕМА№ à ТЕМА.

Возможные ключи: <ТЕМА№>.

Детерминанты: <ТЕМА№>.

Эти два отношения находятся в НФБК, следовательно проектирование завершается и его результатом является логическая модель БД в НФБК:

R2(ВОПРОС№, ОТВЕТ№, ОТВЕТ, ИСТИННОСТЬ),

R3(ТЕМА№, ВОПРОС№, ВОПРОС),

R4(ТЕМА№, ТЕМА).

3.3 Структура файлов базы данных

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

·    Широкий выбор типов полей, включая авто-инкремент, BLOBs и т.п.

·    Соблюдение целостности данных, контроля данных, обновления индексов на уровне ядра BDE.

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

В результате анализа поставленной задачи были разработаны следующие файлы данных:

1)  TEMA - содержит информацию о имеющихся разделах(темах);

2)  QUESTION - предназначен для хранения вопросов к темам из таблицы TEMA;

3)  ANSWER - содержит варианты ответов на вопросы из таблицы QUESTION;

4)  TICKETS - предназначен для хранения информации о билетах;

5)  CONTROL - содержит информацию о результатах тестирования;

6)  RESULT - предназначен для сбора информации об истинности ответов студента.

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

Таблица 3.3

Структура файла данных TEMA.DB

Таблица 3.4

Структура файла данных QUESTION.DB

Таблица 3.5

Структура файла данных TICKETS.DB

Таблица 3.6

Структура файла данных ANSWER.DB

Таблица 3.7

Структура файла данных CONTROL.DB

Таблица 3.8

Структура файла данных RESULT.DB