Visits (Візити

VisitlD (N візиту)	PatientlD (Код пацієнта)	Doctor (Лікар)
1	3	Smith
2	1	Morgan

Рис. 3. Кожен Візит в таблиці Visits відповідає пацієнту з таблиці Patients

Наприклад, якщо подивитись на Візити з VisitID, рівним 2, видно, що його зробив пацієнт з PatientlD, рівним 1. Потім, звернувшись до таблиці Patients, можна з'ясувати, що PatientlD = 1 присвоєно пацієнту Julie Smith.

У відповідність з термінологією реляційних баз даних такий взаємозв'язок називається зовнішнім ключем (foreign key).

PatientlD - первинний ключ у таблиці Patients, проте коли він з'являється в іншій таблиці, наприклад. Visits, його називають зовнішнім ключем.

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

2.3 Види логічного зв'язку.

Зв'язок встановлюється між двома загальними полями (стовпцями) двох таблиць.

Існують зв'язки з відношенням «один-до-багато», «один-до-одного» і «багато-до-багатьох».

Зв'язки, які можуть існувати між записами двох таблиць:

• один – до – одного, кожному запису з однієї таблиці відповідає один запис в іншій таблиці ( зв’язок “один-до-одного” допускає зв’язок між двома об’єктами, представленими у вигляді таблиць, наприклад, “ПАЦІЄНТ” і “СТАН ОРГАНІЗМУ ПАЦІЄНТА” (кожному пацієнту відповідає конкретний стан організму);

• один – до – багатьох, кожному запису з однієї таблиці відповідає декілька записів  іншої таблиці (зв’язок “один-до-багатьох” допускає зв’язок з одним об’єктом кількох інших, наприклад, “ПАЦІЄНТ” і “ЛІКАР” (кожному лікарю відповідає кілька пацієнтів);

• багато – до – одного, безлічі записів з одній таблиці відповідає один запис в іншій таблиці (зв’язок “багато-до-одного” допускає зв’язок кількох об’єктів з одним об’єктом, наприклад, “ЛІКАР” і “ПАЦІЄНТ” і (пацієнти можуть обслуговуватись в одного лікаря);

• багато – до – багатьох, безлічі записів з однієї таблиці відповідає декілька записів в іншій таблиці (зв’язок “багато-до-багатьох” допускає зв’язок кількох об’єктів з кількома іншими, наприклад, “ПАЦІЄНТ” і “ЛІКУВАЛЬНИЙ ЗАКЛАД” (пацієнти можуть обслуговуватися в різних лікувальних закладах) ).

2.4 Створення бд. Етапи проектування

Створення БД починається з проектування, а саме:

• Дослідження предметної області;

• Аналіз даних;

• Визначення відношень і задання первинних і вторинних (зовнішніх) ключів.

У процесі проектування визначається структура реляційної БД (склад таблиць, їх структура і логічні зв'язки). Структура таблиці визначається складом стовпців, типом даних і розмірами стовпців, ключами таблиці.

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

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

Етапи проектування бази даних

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

2. Розробка структури таблиць, які повинна містити база даних. При проектуванні таблиць рекомендується керуватися наступними основними принципами:

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

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

3. Визначення необхідних в таблиці полів. Кожна таблиця містить інформацію на окрему тему, а кожне поле в таблиці містить окремі відомості за темою таблиці. При розробці полів для кожної таблиці необхідно пам'ятати:

- кожне поле повинне бути пов'язане з темою таблиці;

- не рекомендується включати в таблицю дані, які є результатом виразу;

- у таблиці повинна міститися вся необхідна інформація.

4. Задання ключових полів. Для того, щоб можна було зв'язати дані з різних таблиць, кожна таблиця повинна містити поле або набір полів, які будуть однозначно ідентифікувати кожен запис в таблиці.

5. Визначення зв'язків між таблицями. Після розподілу даних по таблицях і визначення ключових полів необхідно вибрати схему зв'язків даних у різних таблицях. Для цього потрібно задати зв'язки між таблицями.

6. Перегляд структури бази даних і виявлення можливих недоліків. Бажано це зробити на етапі, поки таблиці не заповнені даними.

7. Додавання даних і створення інших об'єктів бази даних. Якщо структури таблиць відповідають поставленим вимогам, то можна вводити всі дані. Потім можна створювати будь-які запити, форми, звіти, макроси й модулі.

8. Використання засобів аналізу, в яких існують інструменти для вдосконалення структури баз даних. Майстер аналізу таблиць досліджує таблицю, якщо буде потреба пропонує нову її структуру й зв'язки, а також переробляє її. Аналізатор швидкодії досліджує всю базу даних, дає рекомендації з її поліпшення, а також здійснює їх.

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

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

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

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