- Код спеціалізації лікаря
- Назва
- Id- лікаря
2.2.Нормалізація відносин
Під нормалізацією відносини мається на увазі процес приведення відношення до однієї з так званих нормальних форм (НФ). Однак перед розглядом НФ слід сказати кілька слів, навіщо потрібна нормалізація.
Для підтримки БД в стійкому стані використовується ряд механізмів, які отримали узагальнену назву коштів підтримки цілісності. Ці механізми застосовуються як статично (на етапі проектування БД), так і динамічно (в процесі роботи з БД). звернемо
увагу на ті обмеження, яким повинна задовольняти БД в процесі створення, незалежно від її наповнення даними. Приведення структури БД у відповідність цим обмеженням - це і є нормалізація.
Визначивши кожну сутність, можна визначити набір її атрибутів.
Кожен пацієнт має наступний набір відомостей:
Кожен пацієнт зареєстрований за певного місця проживання: Індекс
Якщо пацієнт приходить до лікарні йому призначають прийом, при цьому вказуючи:
- Реєстраційний номер прийому
- Id- пацієнта
- Id- лікаря
- дата прийому
- № страхового поліса пацієнта
Лікар має параметри:
- Id-лікаря
- Серія паспорта
- № паспорта
- спеціалізація
- код спеціалізації
- № ліцензії
- дата народження
- ім'я лікаря
- Прізвище лікаря
- По батькові лікаря
При цьому лікар має спеціалізацію, яка володіє наступним набором відомостей:
- Код спеціалізації лікаря
- Назва
- Id- лікаря
На даному етапі структура відносин знаходиться в першій нормальній формі (1NF), т.к. значення атрибутів атомарні і все не ключові атрибути функціонально залежать від ключа.
Спробуємо привести відносини до другої нормальної форми (2NF).
Для цього виділимо наступні функціональні залежності:
Розглянемо відношення, що моделює процес запису на прийом до лікаря. Структура даного відносини визначається наступним набором атрибутів:
(Реєстраційний номер прийому, Id- пацієнта, Id- лікаря, дата прийому, № страхового поліса пацієнта)
Первинним ключем відношення може бути (Реєстраційний номер прийому, № страхового поліса пацієнта), який однозначно визначає кожен рядок відносини. З іншого боку, атрибути ПІБ залежить тільки від частини первинного ключа - ІПН пацієнта, отже, для приведення даного відносини до другої нормальної форми слід розбити його на проекції.
Таким чином у нас визначаться два наступні відносини:
(№ страхового поліса пацієнта, Прізвище, Ім'я, По батькові)
(Реєстраційний номер прийому, Id- пацієнта, Id- лікаря, Дата прийому)
Цей набір відносин не неповних функціональних залежностей, а отже знаходиться в другій нормальній формі.
Тепер спробуємо привести ставлення до третьої нормальної
Розглянемо відношення, що зв'язує лікаря з пацієнтом:
- (Прізвище пацієнта, Ім'я пацієнта, По батькові пацієнта, (№ страхового поліса пацієнта, дата прийому, Id- пацієнта, Id- лікаря, Прізвище лікаря, Ім'я лікаря, По батькові лікаря, Код спеціалізації, № ліцензії)
Первинним ключем цього відношення є № страхового поліса пацієнта, але варто розглянути і інші функціональні залежності:
№ страхового поліса пацієнта → Прізвище пацієнта, Ім'я пацієнта, По батькові пацієнта
№ страхового поліса пацієнта → Id- пацієнта
№ страхового поліса пацієнта → Id- лікаря
№ ліцензії лікаря → Код спеціалізації лікаря
№ ліцензії лікаря → Прізвище лікаря, Ім'я лікаря, По батькові лікаря
Більшість цих залежностей утворюють транзитивні групи, щоб уникнути цього слід виділити такі набори відносин:
(№ страхового поліса пацієнта, Прізвище пацієнта, Ім'я пацієнта, По батькові пацієнта, дата прийому)
(Id- лікаря, № ліцензії лікаря, Код спеціалізації лікаря, Прізвище лікаря, Ім'я лікаря, По батькові лікаря)
(Реєстраційний номер прийому, № страхового поліса пацієнта, дата прийому)
Первинні ключі відносин виділені.
2.3. Розробка даталогіческой моделі даних «Діяльність лікарні»
Даталогіческая модель була реалізована через All Fusion ERWIN Data Modeler шляхом визначення сутностей, зв'язків і атрибутів (рис.10.).
Рис.10. Даталогіческая модель даних «Діяльність лікарні»
Фізична модель даних, навпаки, залежить від конкретної СУБД, фактично будучи відображенням системного каталогу. У фізичної моделі міститься інформація про всі об'єкти БД. Оскільки стандартів на об'єкти БД не існує, фізична модель залежить від конкретної реалізації СУБД. Отже, однією і тією ж логічної моделі можуть відповідати кілька різних фізичних моделей. Якщо в логічної моделі не має значення, який саме тип даних має атрибут, то у фізичній моделі важливо описати всю інформацію про конкретних фізичних об'єктах - таблицях, колонках, індексах, процедурах і т. Д. Поділ моделі даних на логічні і фізичні дозволяє вирішити кілька важливих завдань.
Лістинг, представлений нижче реалізований за допомогою CA ERwin Data Modeler, підключення здійснювалося через ODBC / Generic (Додаток №1). Генерація коду здійснювалася через головне меню: Tools -> Forward Engineer -> Schema generation. Далі вибираємо у вікні кнопку Preview. І отримуємо підсумкової лістинг.
2.5.Архітектура інформаційної системи
Клієнт - сервер - одна з найбільш динамічно розвиваються технологій побудови багаторівневих ЕІС.
Сервер - це логічний процес, який забезпечує обслуговування запитувачів його процесів і повернення результатів роботи. Існує безліч видів серверів, що розрізняються набором послуг, що надаються (як правило здійснюють доступ до деякого інформаційного або обчислювальному ресурсу) Клієнт - це процес, який посилає серверу запит на обслуговування. На практиці відбувається поділ програмної системи на кілька взаємодіючих компонент, які в свою чергу можуть виступати в ролі клієнта або сервера, а може клієнта і сервера одночасно. Зокрема ми розглянемо триланкову архітектуру, де присутній третій елемент такої як сервер додатків.
Клієнт взаємодіє з сервером по строго певним алгоритмом:
· Встановлення зв'язку з сервером;
· Запит конкретного виду обслуговування;
· Отримання від сервера результатів запиту через сервер додатка;
· Розрив зв'язку з сервером.
Рішення для компаній з розподіленою структурою.
Архітектура системи включає спеціальні засоби, які дають можливість створити єдине легко кероване рішення для підприємств з територіально розподіленою структурою (територіально віддаленими філіями).
Користувачі, наприклад, з Далекого Сходу, можуть працювати з системою, що знаходиться в Санкт-Петербурзі. Таке з'єднання може бути організовано через різні канали зв'язку, в тому числі і через супутникові.
Рис.12. Робота БД в триланкової моделі
Триланкового модель являє собою типовий варіант, при якому кожна з додатків реалізується на окремому комп'ютері. Переваги такої системи гнучкість, Масштабованість, висока безпека, висока надійність, балансування навантаження, збільшення швидкості роботи і універсальність.
2.6.Публікація даних в Інтернет в рамках ІС «Діяльність лікарні»
- Здійснення доступу через WEB- інтерфейс
- Здійснення по FTP протоколу, де буде здійснюватися робота з базою даних безпосередньо
- Публікація бази даних по FTP протоколу.
Програми, які рекомендуються використовувати для роботи з сервером по протоколу FTP: