Для усвоения материала книги требуется понимание основ объектно-ориентированного программирования и принципов построения программ, управляемых событиями. Какую-то часть кода сгенерирует за вас Delphi, но для серьезной работы потребуется и серьезное знание языка Паскаль. Некоторые неосновные свойства компонентов, описанных в книге, ссылаются напрямую на программный интерфейс Windows. Его знание, конечно, не будет лишним, но и не является обязательным. Та часть книги, которая посвящена работе Delphi с базами данных, требует наличия у читателя основ знаний в этой области.
3. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ
3.1 Концептуальная модель базы данных
Первый шаг процесса проектирования состоит в определении всех атрибутов, включаемых в базу, и в определении связей между ними.
Наш набор атрибутов - следующий:
ТЕМА№ - порядковый номер темы с вопросами;
ТЕМА - название раздела(темы);
ВОПРОС№ - уникальный номер вопроса;
ВОПРОС - текст вопроса;
ОТВЕТ№ - уникальный номер варианта ответа на вопрос;
ОТВЕТ - текст варианта ответа на вопрос;
ИСТИННОСТЬ - истинность варианта ответа на вопрос(правда или ложь).
Сведем все атрибуты и принимаемые ими на некоторый момент времени значения в следующую таблицу:
Таблица 3.1
Сводная таблица атрибутов ПРО и их значений
| ТЕМА№ | ТЕМА | ВОПРОС№ | ВОПРОС | ОТВЕТ№ | ОТВЕТ | ИСТИННОСТЬ |
| 1 | тема1 | 1 | вопрос1 | 1 | ответ1 | True |
| 2 | ответ2 | False | ||||
| 3 | ответ3 | False | ||||
| 2 | вопрос2 | 4 | ответ4 | False | ||
| 5 | ответ5 | True | ||||
| 2 | тема2 | 3 | вопрос3 | 6 | ответ6 | True |
| 7 | ответ7 | False | ||||
| 4 | вопрос4 | 8 | ответ8 | False | ||
| 9 | ответ9 | True | ||||
| 10 | ответ10 | False | ||||
| 3 | тема3 | 5 | вопрос5 | 11 | ответ11 | True |
| 12 | ответ12 | False |
Эта таблица не является отношением, так как значения первых четырех полей в ней - атомарные, а значения оставшихся трех - множественные. Чтобы таблица стала отношением, ее нужно реконструировать таким образом, чтобы каждый элемент кортежа имел атомарное значение. Это делается с помощью простого процесса вставки (табл.3.2.).
Хотя вставка добавила большой объем избыточных данных, новая таблица получает статус отношения, которое называют универсальным отношением проектируемой БД. Такое отношение включает все представляющие интерес атрибуты и все данные, которые предполагается размещать в БД. Таким образом, получена концептуальная модель проектируемой БД.
Таблица 3.2
Концептуальная модель БД
| ТЕМА№ | ТЕМА | ВОПРОС№ | ВОПРОС | ОТВЕТ№ | ОТВЕТ | ИСТИННОСТЬ |
| 1 | тема1 | 1 | вопрос1 | 1 | ответ1 | True |
| 1 | тема1 | 1 | вопрос1 | 2 | ответ2 | False |
| 1 | тема1 | 1 | вопрос1 | 3 | ответ3 | False |
| 1 | тема1 | 2 | вопрос2 | 4 | ответ4 | False |
| 1 | тема1 | 2 | вопрос2 | 5 | ответ5 | True |
| 2 | тема2 | 3 | вопрос3 | 6 | ответ6 | True |
| 2 | тема2 | 3 | вопрос3 | 7 | ответ7 | False |
| 2 | тема2 | 4 | вопрос4 | 8 | ответ8 | False |
| 2 | тема2 | 4 | вопрос4 | 9 | ответ9 | True |
| 2 | тема2 | 4 | вопрос4 | 10 | ответ10 | False |
| 3 | тема3 | 5 | вопрос5 | 11 | ответ11 | True |
| 3 | тема3 | 5 | вопрос5 | 12 | ответ12 | False |
3.2 Логическая модель базы данных
Проектирование реализации БД(логическое проектирование) представляет собой трансформацию концептуальной модели в набор отношений в нормальной форме Бойса-Кодда(НФБК). Для приведения спроектированного универсального отношения в НФБК воспользуемся декомпозиционным методом проектирования, содержанием которого является описание семантики универсального отношения в терминах функциональных зависимостей(ФЗ) и использование последних для нормализации отношения.
Введем следующие понятия: функциональная зависимость, ключ, первичный ключ, детерминант, НФБК.
Если даны два атрибута A и B, то говорят, что B функционально зависит от A (обозначается A-B), если для каждого A существует ровно одно связанное с ним значение B. A и B могут быть не только единичными атрибутами, но и группами из двух и более атрибутов.
Ключом называется атрибут или совокупность атрибутов, которые используются для идентификации записи и обнаружения ее на ЗУ. Ключей может быть несколько.
Первичный ключ используется для уникальной идентификации кортежа.
Детерминант. Если в ФЗ A-BB не зависит от любого подмножества 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
| Название поля | Тип | Назначение |
| Tema_id | autoincrement | уникальный идентификатор раздела(темы) |
| Tema_name | alpha(100) | название раздела(темы) |
Таблица 3.4
Структура файла данных QUESTION.DB
| Название поля | Тип | Назначение |
| Quest_id | autoincrement | уникальный идентификатор вопроса |
| Tema_id | long integer | номер темы, которой принадлежит вопрос |
| Quest_name | memo | текст вопроса |
Таблица 3.5
Структура файла данных TICKETS.DB
| Название поля | Тип | Назначение |
| Ticket_id | autoincrement | уникальный идентификатор записи |
| Ticket_num | long integer | номер билета |
| Quest_id | long integer | идентификатор вопроса |
Таблица 3.6