1.4 Структура вікна файлу бази даних субд Access, довідкова система Access.

Після запуску MS Access (подвійним натиском миші по піктограмі з зображенням ключа на панелі MS Office або обравши команду Програми головного меню Windows, що відкривається кнопкою Пуск, а потім -Microsoft Access) на екрані з'являється вікно запрошення MS Access. Це вікно має дві основні опції, призначені для створення нової і відкриття раніше створеної бази даних. Створення нової бази даних розглянемо нижче. Після відкриття існуючої бази даних на екрані з'явиться головне вікно Access (мал. 2.), що містить п'ять частин: 1.  Заголовок вікна;

2.           Рядок меню;

3.  Панелі інструментів;

4.           Вікно бази даних;

5.  Рядок стану.

Заголовок знаходиться у верхній частині вікна і містить копію піктограми програми, її назву і кнопки керування вікном.

Рядок меню містить меню поточного вікна, що змінюється залежно від режиму роботи.

MS Access має різноманітні панелі інструментів. При першому вході в MS Access на екрані з'являється панель інструментів, яка називається База

Вікно бази даних містить шість вкладок: Таблицы, Запросы, Отчеты, Формы, Макросы і Модули. У правій частині вікна бази даних знаходяться кнопкиОткрыть, Конструктор і Создать. Кнопка Открыть призначена для відкриття обраного об'єкта, яким може бути таблиця, запит або форма. При переході на вкладку Отчеты найменування кнопки Открыть змінюється на Просмотр, а при переході на вкладку Макросы - на Запуск

Кнопка Конструктор призначена для модифікації об'єкта, а кнопка Создать - для його створення.

1.5 Модифікація структури таблиць та зв’язків.

Зведення до першої нормальної форми

 На цьому етапі створюється двовимірна таблиця, що містить всі потрібні атрибути ІМ, і виділяються ключові атрибути. Саме вони однозначно визначають кожен рядок в таблиці, тобто запис. Усі інші атрибути функціонально залежатимуть від ключових. Розрізняють повну функціональну залежність і часткову, коли деякі неключові атрибути залежать лише від частини ключа. В цьому випадку можуть спостерігатися аномалії розміщення даних:

n     аномалії включення, які викликані тим, що ключові елементи не можуть приймати нульових значень;

n     аномалії поновлення. При поновленні даних потрібно заповнити дані у всіх атрибутах, хоча деякі з их в цей момент і не змінюють свого значення

n     аномалії знищення. При знищенні запису із таблиці  втрачаються усі пов”язані із ним дані

 

Коли поле в даному записі містить більше як одне значення для кожного входження первинного ключа, такі групи даних називаються групами, що повторюються. 1НФ не припускає наявності таких багатозначних полів. Розглянемо приклад бази даних  лікувального закладу, що містить таблицю ПАЦІЄНТИ із такими значеннями (атрибут, виділений курсивом, є первинним ключом):

 

Таблиця А

Номер_пацієнта	Прізвище	Ім”я	Група_крові	Rh	Дата_аналізу_крові	К-сть_еритроцитів
1	Коваленко	Іван	1	+	12.04.99	норма
1	Коваленко	Іван	1	+	12.09.99	норма
2	Поліщук	Тарас	2	-	12.09.99	норма
5	Корнієнко	Олег	2	+	13.09.99	норма

 

 

Для зведення цієї таблиці  до 1НФ ми повинні усунути атрибут  (поле) Дата_аналізу_крові з таблиці ПАЦІЄНТИ і створити нову таблицю АНАЛІЗИ_КРОВІ, в якій означити первинний ключ, що є комбінацією номера пацієнта і датою його аналізу крові (Номер_пацієнта + Дата_аналізу_крові - див. Табл. Б). Тепер для кожного аналізу крові різні рядки; тим самим ми усунули групи, що повторюються. 

 

Таблиця Б. АНАЛІЗИ_КРОВІ

 

Номер_пацієнта	Дата_аналізу_крові	К-сть_еритроцитів
1	12.04.99	норма
1	12.09.99	норма
2	12.09.99	норма
5	13.09.99	норма

 

 

Зведення до другої нормальної форми

 

            Наступний важливий крок в процесі нормалізації  полягає у знищенні всіх неключових атрибуті, які залежать лише від частини первинного ключа. Такі атрибути називаютьсячастково залежними. Неключові атрибути містять в собі інформацію про дану сутність предметної області, але не ідентифікують її унікальним чином.

На цьому етапі досягається повна функціональна залежність усіх атрибутів  від ключа за рахунок розбиття даних на кілька таблиць. До основних аномалій відноситься аномалія дублювання даних. Можливе дублювання даних виявляється шляхом встановлення тих атрибутів, які однозначно залежать від інших атрибутів , що не є ключовими (транзитивний зв”язок). Для усунення вказаного недоліку модель приводиться до третьої нормальної форми.

 Наприклад, припустимо, що ми хочемо розподілити пацієнтів за захворювання ми (поставленому діагнозу). Для цього створимо таблицю ЗАХВОРЮВАННЯ із складовим первинним ключом, що включає номер пацієнта та ідентифікатор захворювання (Номер_пацієнта + ІД_захворювання).

 

Таблиця В. ЗАХВОРЮВАННЯ

 

Номер_пацієнта	Ід_захворювання	Прізвище	Назва_захворювання	Опис_захворювання
1	ФРН	Коваленко	Фарингіт	<blob>
2	ТНЗ	Поліщук	Тонзиліт	<blob>
5	ЛРН	Корнієнко	Ларингіт	<blob>

 

У цій таблиці  виникає така проблема. Атрибути Назва_захворювання  та опис_захворювання відносяться до захворювання як до сутності, значить, залежать від атрибуту ІД_захворювання (що є частино. Первинного ключа), але не від атрибуту Номер_пацієнта. Отже, вони є частково залежними від складового первинного ключа. Те ж можна сказати і про атрибут Прізвище, який залежить від атрибуту Номер_пацієнта, але не залежить від атрибуту ІД_захворювання. Для нормалізації  цієї таблиці (зведення її до 2НФ) знищимо з неї атрибути Номер_пацієнта і Прізвище і створимо другу таблицю (назвемо її ПАЦІЄНТ), яка буде містити лише ці два атрибути, і вони ж будуть складати її первинний ключ. 

 

Зведення до третьої нормальної форми

 

Третій етап процесу зведення таблиць до  нормальної форм и полягає у знищенні неключових атрибутів, які залежать від інших неключових атрибутів . Тобто, атрибути, що мають транзитивні зв”язки, виділяються в окремі таблиці. Кожен неключовий атрибут повинен бути логічно пов”язаний з атрибутом (атрибутами), що є первинним ключом. 

Припустимо, наприклад, що ми добавили поля Номер_головного_симптому та Інші_захворювання_із_цим_симптомом в таблицю ЗАХВОРЮВАННЯ, що знаходиться в 2НФ (первинним ключом є поле ІД_захворювання). Атрибут Інші_захворювання_із_цим_симптомом логічно пов”язаний з атрибутом Номер_головного_симптому, неключовим атрибутом, але не з атрибутом ІД_захворювання, що є первинним ключом (табл. Г).

 

Таблиця Г. ЗАХВОРЮВАННЯ

 

Ід_захворювання	Назва_захворювання	Опис_захворювання	Номер_головного_симптому	Інші_захворювання_із_цим_симптомом
ФРН	Фарингіт	<blob>	3	Тонзиліт, грип,
ТНЗ	Тонзиліт	<blob>	3	Фарингіт, грип
ЛРН	Ларингіт	<blob>	4	Пухлина гортані

 

Для нормалізації цієї таблиці (зведення її в 3НФ) знищимо атрибут Інші_захворювання_із_цим_симптомом, змінимо Номер_головного_симптому на Головний_симптом і зробимо атрибут Головний_симптом зовнішнім ключом, що посилається на атрибут Номер_симптому в таблиці СИМПТОМИ. Після цього таблиці  ЗАХВОРЮВАННЯ та СИМПТОМИ будуть виглядати таким чином:

 

Таблиця Д. ЗАХВОРЮВАННЯ

 

Ід_захворювання	Назва_захворювання	Опис_захворювання	Головнийсимптом симпт
ФРН	Фарингіт	<blob>	3
ТНЗ	Тонзиліт	<blob>	3
ЛРН	Ларингіт	<blob>	4

 

Таблиця Е. СИМПТОМИ

 

Номер_симптому	Назва_симптому	Захворювання _із_цим_симптомом
3	Біль горла	Тонзиліт, фарингіт, грип,
4	Захрип голос	Ларингіт, пухлина гортані

 

Тепер, коли ми навчилися проводити нормалізацію таблиць з метою усунення надлишковоті дублювання даних і групування інформації в логічно пов”язаних одиницях, потрібно зробити ряд зауважень з питань проектування баз даних. Потрібно чітко розуміти, що розбиття інформації на дрібніші одиниці з однієї сторони, сприяє підвищенню надійності і несуперечливості бази даних, а з іншої сторони, понижує її продуктивність, оскільки вимагаються додаткові затрати процесорного часу (серверного або машини споживача) на обернене з”єднання талиць при представленні інформації на екрані. Іноді для досягнення потрібної продуктивності потрібно зробити відступ від канонічної нормалізації, при цьому чітко усвідомлюючи, що потрібно гарантувати міри щодо запобігання суперечливості в даних. Тому будь-яке рішення про необхідність тої чи іншої дії щодо нормалізації  можна приймати лише ретельно проаналізувавши предметну область і клас поставленої задачі. Може бути потрібним кілька ітерацій для досягнення стану, який буде бажаним компромісом між чіткістю представлення і реальними можливостями техніки. Тут уже починається мистецтво..

 

7. Сьомий крок є останнім у нашому списку, але не останнім щодо важливості в процесі проектування бази даних. На цьому кроці ми повинні спланувати питання надійності даних і, при потребі, збереження секретності інформації. Для цього потрібно відповісти на такі питання:

n   хто буде мати права (і які) на використання бази даних

n   хто буде мати права на модифікацію, вставку і знищення даних

n   чи потрібно робити відмінність в правах доступу

n   яким чином забезпечити загальний режим захисту інформації і т.ін.