Реляційна модель даних має такі властивості:
кожен елемент таблиці - один елемент даних;
всі поля в таблиці є однорідними, тобто мають один тип;
кожне поле має унікальне ім'я;
однакові записи в таблиці відсутні.
Складемо таблиці з відповідними їм атрибутами, використовуючи дані наведені вище. Для кожного атрибуту встановимо логічно відповідний йому тип даних.
Таблиця 2.2.1. «Главы»
| Поле | Тип даних | Розмір |
| № главы | Числовий | Довге ціле |
| Название главы | Текстовий | 50 |
| Краткое содержание | Поле МЕМО | |
| Начальная страница | Числовий | Довге ціле |
| Конечная страница | Числовий | Довге ціле |
Таблиця 2.2.2. «Подглавы»
| Поле | Тип даних | Розмір |
| № главы | Числовий | Довге ціле |
| Код подглавы | Текстовий | 5 |
| Название подглавы | Текстовий | 45 |
| Начальная страница | Числовий | Довге ціле |
| Конечная страница | Числовий | Довге ціле |
Таблиця 2.2.3. «Параграфы»
| Поле | Тип даних | Розмір |
| Код параграфа | Числовий | Довге ціле |
| № главы | Числовий | Довге ціле |
| Код поглавы | Текстовий | 5 |
| Название параграфа | Текстовий | 30 |
| Начальная страница | Числовий | Довге ціле |
| Конечная страница | Числовий | Довге ціле |
| Ключевые слова, которые упоминаются | Текстовий | 15 |
| Процедуры, которые упоминаются | Текстовий | 60 |
| Функции, которые упоминаются | Текстовий | 15 |
| Свойства компонентов, которые упоминаются | Текстовий | 35 |
| Типы переменных, которые рассматриваются | Текстовий | 15 |
| Определения | Поле МЕМО | |
| Фрагменты кода | Логический | |
| Рисунки | Логический | |
| Таблицы | Логический |
Таблиця 2.2.4. «Таблицы»
| Поле | Тип даних | Розмір |
| Код параграфа | Числовий | Довге ціле |
| Название таблицы | Текстовий | 10 |
| Содержание таблицы | Поле об’єкту OLE |
Таблиця 2.2.5. «Типы переменных»
| Поле | Тип даних | Розмір |
| Код параграфа | Числовий | Довге ціле |
| Тип переменной | Текстовий | 10 |
| Описание | Поле МЕМО |
Таблиця 2.2.6. «Фрагменты кода»
| Поле | Тип даних | Розмір |
| Код параграфа | Числовий | Довге ціле |
| Фрагмент кода | Поле МЕМО | |
| Описание | Поле МЕМО |
Таблиця 2.2.7. «Функции»
| Поле | Тип даних | Розмір |
| Код параграфа | Числовий | Довге ціле |
| Функция | Текстовий | 10 |
| Описание | Поле МЕМО |
Таблиця 2.2.8. «Процедуры»
| Поле | Тип даних | Розмір |
| Код параграфа | Числовий | Довге ціле |
| Процедура | Текстовий | 10 |
| Описание | Поле МЕМО |
Таблиця 2.2.9. «Ключевые слова»
| Поле | Тип даних | Розмір |
| Код параграфа | Числовий | Довге ціле |
| Код ключевого слова | Числовий | Довге ціле |
| Ключевое слово | Текстовий | 10 |
| Описание | Поле МЕМО |
Таблиця 2.2.10. «Рисунки»
| Поле | Тип даних | Розмір |
| Код параграфа | Числовий | Довге ціле |
| Название рисунка | Текстовий | 50 |
| Рисунок | Поле об’єкту OLE |
Структура таблиць відноситься до 3 НФ:
1) кожен стовпець таблиці неподільний і в рамках однієї таблиці немає стовпців з однаковими за змістом значеннями.
2) первинні ключі таблиць однозначно визначають запис і не надмірні.
3) значення будь-якого поля не входить у первинний ключ, не залежить від значення іншого поля, що також не входить у первинний ключ.
2.3 Фізичне проектування інформаційних систем
Фізичний етап проектування полягає в реалізації створеного проекту на комп'ютері. Фізична модель бази даних визначає спосіб розміщення даних (файлів) на пристроях зовнішньої пам'яті ЕОМ, а також способи і засоби організації ефективного доступу до них. У цілому файлова структура та система управління є прерогативою операційної системи, тому по відношенню до баз даних, орієнтованих на роботу з елементами даних і високу інтенсивність обміну, ефективність введення / виводу, вона буде не оптимальна. Операційна система з завданнями баз даних справляється погано.
Система управління базами даних (СУБД), її мова, набагато більша, ніж набір файлової системи операційного середовища. Тобто СУБД бере на себе безпосередньо керування зовнішньою пам'яттю, мінімально використовуючи операційну систему.
Стадія фізичного проектування БД включає:
вибір способу організації БД;
розробку специфікації внутрішньої схеми БД засобами моделі даних;
опис відображення концептуальної схеми БД у внутрішній структурі управління файлами.
На відміну від ранніх СУБД багато сучасних системи, у тому числі і Access не надають розробнику будь-якого вибору на стадії фізичного проектування. На цій стадії можна говорити не про варіанти фізичного проектування, а про варіанти реалізації. Тобто, після створення даталогічної моделі фізичне проектування включає:
вибір СУБД;
оновлення структури таблиць;
призначення типів полів для розподілу атрибутів сутностей;
можливе створення таких додаткових об'єктів як індекси, тригери (обробники подій) і процедури, що зберігаються, що полегшують пошук в таблицях і обробку даних контролю цілісності [9].
Дана інформаційна система розроблена в СУБД Access, основною перевагою якої є можливість створення і експлуатації досить потужних баз даних без необхідності щось програмувати. Ще одне додаткова перевага Access – інтегрованість цієї програми з Excel, Word та іншими програмами пакета MS Office.
Система управління базами даних (СУБД) — спеціалізована програма (частіше комплекс програм), що призначена для організації і ведення бази даних. [10]
СУБД Access входить до складу широко розповсюдженого сімейства офісних додатків Microsoft Office. Microsoft Access на сьогоднішній день є одним з найпоширеніших настільних додатків для роботи з базами даних. Це пов’язано з тим, що Access володіє дуже широким діапазоном засобів для введення, аналізу та представлення даних. Ці кошти є не тільки простими і зручними, а й високопродуктивними, що забезпечує високу швидкість розробки додатків. Спочатку Access мала ряд унікальних можливостей, таких як вміння зводити воєдино інформацію з різних джерел (електронних таблиць, текстових файлів, інших баз даних), подання даних в зручному для користувача вигляді за допомогою таблиць, діаграм, звітів, інтеграція з іншими компонентами Microsoft Office. Вдосконалюючись від версії до версії, Access стала інструментом, який може задовольнити потреби самих різних категорій користувачів: від новачка, якому подобається дружній інтерфейс системи, що дозволяє йому впоратися із завданнями, до професійного розробника, який має весь необхідний інструментарій для побудови унікального рішення для конкретного підприємства середнього бізнесу.
Таблиці — це основні й найнеобхідніші об’єкти будь-якої БД. Саме в таблицях зберігаються всі дані. Реляційна БД може містити цілий набір взаємозв'язаних таблиць.
Запити — це спеціалізовані структури, що створюються для здійснення обробки бази даних. За допомогою запитів можна упорядкувати дані, виконати їх фільтрацію, об’єднання, відбір або навіть зміну.
Форми — це об’єкти, що дозволяють вводити в базу нові дані або переглядати вже існуючі у зручній для користувача формі (вигляді, поданні).
Звіти — ці об’єкти говорять самі за себе. Вони видають дані на принтер або інший пристрій виводу (це може бути і монітор), у зручному та наочному вигляді. Наприклад, у вигляді бланку або рахунку.
Макроси — це набір макрокоманд. Коли виникає необхідність частого виконання одних і тих же операцій з БД, є можливість згрупувати набір команд в один макрос. Після чого ініціалізацію його виконання закріплюють за певною комбінацією клавіш клавіатури. Простими словами, натискання цієї комбінації при роботі з базою призводить до виконання всієї послідовності дій, що записані у макрос.
Модулі — це програми, що створені засобами мови Visual Basic. Вони дозволяють доповнити стандартні засоби Access, якщо наявних вже не вистачає для задоволення всіх вимог до роботи СУБД. Програміст може розширити можливості системи, дописавши необхідні модулі та додавши їх у БД [4].