Professional Documents
Culture Documents
БД2
БД2
Теоретичні відомості
У Microsoft Access перед тим, як створювати таблиці, форми та інші об'єкти необхідно розробити
проект бази даних. Правильна структура бази даних є основою для створення ефективної бази даних
адекватної вимогам конкретних задач. Відсутність продуманої структури бази даних призводить до
необхідності постійної переробки і налаштування об'єктів бази даних, таких, як форми і таблиці.
Проектування передбачає етапи створення проекту бази даних від концепції до реального втілення.
Проектування бази даних проходить три основних етапи:
1. Побудова концептуальної моделі БД. Зрозуміло, що неможливо створити базу даних, яка
враховує абсолютно усі аспекти реальності, до якої відноситься задача. На першому етапі
проектування бази даних необхідно визначити призначення бази даних, режими її використання та
основні алгоритми, які реалізують реальні бізнес-процеси – тобто вивчити предметну область
використання бази даних з метою створення моделі. Щоб зрозуміти, що саме і до якого рівня
деталізації необхідно описувати на етапі аналізу, потрібно вибрати певну точку зору на задачу. При
цьому аналіз поставленого завдання повинен враховувати вимоги замовника до системи, яка
розробляється, а також досвід розробника.
2. Побудова інфологічної (інформаційно-логічної) моделі БД. Далі слід розробити ескіз
об'єктів (таблиць), які потрібні для отримання необхідних результатів і визначити зв'язки між цими
об'єктами. При розробці ескізу слід врахувати відповіді на такі запитання:
Які дані ми маємо?
Які дані будуть містити таблиці?
Який тип і які властивості повинні мати дані в кожному полі таблиці? Як таблиці будуть пов'язані
одна з одною?
Організація полів даних в таблицях повинна відбуватись за певним правилами:
кожна таблиця описує певну сутність;
у таблиці не повинно бути даних, що не стосуються до описуваної сутності;
потрібно позбавитися від полів, які повторюються, або містять інформацію, що дублюється;
потрібно уникати полів, що містять похідні чи обчислювальні дані;
кожне поле таблиці має містити найменшу змістовну інформацію (логічну одиницю), яка
стосується описуваної сутності; потрібно розділити складні конструкції даних на окремі елементи
даних;
кожна таблиця повинна мати первинний ключ, який може складатися з одного або декількох
полів;
Закінчення цього етапу передбачає докладний опис всіх таблиць (імена полів, типи даних та їх
властивості), а також зв'язків між ними.
3. Побудова даталогічної моделі бази даних. На цьому етапі проходить практична реалізація
інфологічної моделі на платформі конкретної СУБД (в даному випадку Microsoft Access 2010). На
основі інфологічної моделі:
· створюються потрібні таблиці бази даних з відповідними полями;
· полям задаються необхідні типи та розмірності;
· встановлюються ключові та індексовані поля в таблицях;
· при потребі полям задаються списки вводу даних, маски, формати відображення,
контроль вводу даних, початкові значення та інші властивості;
· створюються зв’язки між таблицями (з врахуванням правил цілісності).
Після створення таблиць, полів та зв’язків необхідно ще раз перевірити структуру бази даних, щоб
виявити можливі недоліки. Бажано зробити це перед заповненням таблиць даними
Результатом цього етапу має бути множина таблиць, які задовольняють правилам нормалізації, із
встановленими (з врахуванням правил цілісності) зв’язками між таблицями.
Предметна область: Поліклініка.
Концептуальна модель
Мета: створити базу даних для приватної поліклініки, яка містить інформацію про візити, лікарів, які
там працюють і пацієнтів, які там лікуються; а також діагноз і методи його обстеження.
Перелік вихідних даних:
Пацієнти
Код_пацієнта
ПІБ_пацієнта
Тел_пацієнта
Адреса_пацієнта
Дата_нар_пацієнта
Діагноз
Прийом
Код_прийому
Код_відділення
Тривалість
Дата_прийому
Пацієнт
Оцінка якості прийому
Лікар
Відділення
Код_Відділення
Вид_Відділення
Ціна
послуги_Відділення
Опис_ Відділення
Діагноз
Код_діагнозу
Діагноз
Діагностика
Лікарі
Код_лікаря
Прізвище_лікаря
Ім'я_лікаря
Спеціальність_лікаря
Медична освіта
Лікаря і Прийом – зв’язок один-до-багатьох (один лікар може мати безліч прийомів).
Відділення і Прийом – зв’язок один-до-багатьох ( одне відділення має багато прийомів).
Прийом і Пацієнти – зв’язок один-до-багатьох ( один пацієнт може мати безліч прийомів).
Діагноз і Пацієнт – зв’язок один-до-багатьох (один пацієнт може мати безліч діагнозів).
Даталогічна модель
Таблиця Відділення
Таблиця Лікарі
Таблиця Діагноз
Таблиця Прийом