Важливою характеристикою зв'язку є тип зв'язку. Розглянемо типи зв'язків 1-3.
Так як лікар здійснює кілька прийомів, а так же кожен прийом здійснюється одним лікарем, то в цьому випадку зв'язок 1 має тип "один до багатьох"
Так як пацієнт може приходити на прийом до лікаря кілька разів, а на прийом по талону приходить тільки 1 пацієнт, то в цьому випадку зв'язок 2 має тип "один до багатьох"
Так як один і той же діагноз виставляється на прийомі декільком пацієнтам, а на одному прийомі виставляється тільки 1 діагноз, то зв'язок 3 має тип "один до багатьох"
Розглянемо поняття клас приналежності сутності.
В нашій предметної області можна виділити наступні класи приналежності сутності:
Кожен лікар обов'язково приймає пацієнтів по талону;
Кожен прийом обов'язково здійснюється лікарем;
Кожен пацієнт обов'язково приходить на прийом по талону;
На кожен прийом обов'язково приходить пацієнт;
Можливий діагноз не обов'язково виставляється на прийомі;
На прийомі обов'язково виставляється діагноз.
3. СозданіеER-моделі предметної області. Для подання сутностей і зв'язків між ними використовуються ER-діаграми. На їх основі створюється єдиний наочний образ моделюється предметної області - ER-модель предметної області.
ER-модель для поліклініки зображена на малюнку:
Визначення атрибутів, їх значень, первинних ключів.
Виявляються всі атрибути, що описують сутність створеної ER-моделі. Кожному атрибуту присвоюється осмислене ім'я, зрозуміле користувачам. Про кожному атрибуті в словник даних поміщаються такі відомості:
Ім'я атрибута і його опис;
Тип і розмірність значень;
Значення, прийняте для атрибута за замовчуванням (якщо є);
Чи може атрибут мати Null - значення;
Чи є атрибут складовим, і якщо так, то з яких простих атрибутів він складається;
Чи є атрибут розрахунковим, і якщо це так, то як обчислюються його значення.
Можна виділити наступні набори атрибутів сутностей для предметної області АУДИТ:
III. Логічна модель бази даних
Мета етапу логічного проектування перетворення концептуальної моделі на основі обраної моделі даних в логічну модель, яка не залежатиме від особливостей використовуваної в подальшому СУБД для фізичної реалізації бази даних. Для її досягнення виконуються наступні процедури.
Вибір моделі даних.
У нашому випадку вибирається реляційна модель даних в зв'язку з наочністю табличного представлення даних і зручності роботи з ними.
Визначення набору таблиць виходячи ізER-моделі і їх документування. Для кожної сутності створюється таблиця. Здійснюється формування структури таблиць на підставі певних правил. Встановлюються зв'язки між таблицями за допомогою механізму первинних і зовнішніх ключів. Структури таблиць і встановлені зв'язки між ними документуються.
Для зв'язків, виявлених на концептуальному етапі, застосовуються такі правила:
Згідно з правилом 4. так як зв'язок ЛІКАР - ЗДІЙСНЮЄ - ПРИЙОМ
має тип "один до багатьох" і клас суті на боці М є обов'язковим. то необхідно побудувати таблицю для кожної сутності. Первинний ключ сутності повинен бути первинним ключем відповідної таблиці. Первинний ключ сутності на стороні 1 додається як атрибут в таблицю для сутності на стороні М.
Згідно з правилом 4. так як зв'язок ПАЦІЄНТ - ПРИХОДИТЬ - ПРИЙОМ
має тип "один до багатьох" і клас суті на боці М є обов'язковим. то необхідно побудувати таблицю для кожної сутності. Первинний ключ сутності повинен бути первинним ключем відповідної таблиці. Первинний ключ сутності на стороні 1 додається як атрибут в таблицю для сутності на стороні М.
Згідно з правилом 4. так як зв'язок ДІАГНОЗ - ВИСТАВЛЯЄТЬСЯ - ПАЦІЄНТІВ має тип "один до багатьох" і клас суті на боці М є обов'язковим. то необхідно побудувати таблицю для кожної сутності. Первинний ключ сутності повинен бути первинним ключем відповідної таблиці. Первинний ключ сутності на стороні 1 додається як атрибут в таблицю для сутності на стороні М.
