Розробка інформаційно-пошукової системи реєстратури поліклініки «реєстратура»

Дана СУБД була обрана з наступних причин: простота засобів реалізації; легкість освоєння інструментарієм розробника (VBA); наочність візуалізації інформації.

Бази даних створені за допомогою системи управління базами даних «Microsoft Access» повністю реалізую реляційну модель побудови даних. База даних «Microsoft Access» являє собою набір груп об'єктів, таких як таблиці, запити, форми, звіти.

Зв'язки між таблицями можна розбити на чотири базових реляційних типу з відносинами: один-до-одного; один-до-багатьох; багато-до-одного; багато-до-багатьох. Структура організації таблиць дозволяє створення первинних і зовнішніх ключів. Є можливість зміни типу внутрішніх об'єднань для зв'язаних таблиць.

 

2.2. Алгоритм програми

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

1) системний аналіз і словесний опис інформаційних об'єктів предметного області;

2) проектування інфологічної моделі предметного області – частковий формалізований опис об'єктів предметного області в термінах деякої семантичної моделі;

3) даталогічне або логічне проектування БД, тобто опис БД в термінах прийнятої даталогчної моделі даних.

4) фізичне проектування БД, тобто вибір ефективного розміщення БД на зовнішніх носіях для забезпечення найефективнішої роботи додатку.

Інформаційна модель та її опис.

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

Інформаційна модель містить у собі сукупність вхідних  і вихідних документів, файлів вхідної, оперативної постійної та результативної інформації.

Контекстна діаграма системи наведена на рис. 2.1

Рис. 2.1 Контекстна модель системи

Рис. 2.2. Діаграма потоків даних.

При декомпозиції системи отримуємо 4 основні підсистеми:

• Ведення обліку хворих;
• Ведення списку лікарів;
• Ведення обліку записів на прийом;
• Облік викликів додому  терапевта.

На мал. 3 наведена модель підсистеми "АРМ оператора" по методології Гейна /Сарсона. Підсистема працює з наступними сховищами даних:

• БД хворі;
• БД лікарі;
• БД розклад;
• БД запису на прийом;
• БД запису на аналізи;
• БД викликів додому.

Інфологічна модель.

При розробці інформаційних систем проект бази даних є тим фундаментом, на якому будується вся система в цілому. Отже, інфологічна модель повинна включати такий опис наочної області, який буде легко «читатися» не тільки фахівцями по базах даних. Цей опис повинен бути настільки ємким, щоб можна було оцінити глибину і коректність опрацьовування проекту БД, і воно не повинне бути прив'язано до конкретної СУБД. Загальноприйнятим стала скорочена назва ER-модель.

Метод сутність-зв'язок є простим і швидким. Оскільки для полегшення процесу проектування і наочності вироблюваних операцій можливе використовування CASE-засобів.

Для побудови інформаційної моделі використовувався CASE-засіб ERWin, внаслідок чого була одержана модель сутність-зв'язок. В ній визначені всі основні сутності і зв'язки, які існують між ними.

Схема інфологічної моделі комплексу завдань АІС "Реєстратура" поліклініки представлена на рис. 2.3. В даній інфологічній моделі можна виділити такі прості інформаційні об'єкти, як  "Хворий", "Лікар" й "Розклад", "Виклик додому ", "Запис на прийом", "Запис на аналізи", це основні об'єкти, всі інші сутності є довідниками й таблицями для подання зв'язків 1:М.

 

Рис. 2.3. ІЛМ модель системи

 

Характеристика первинних документів з нормативно - довідковою та вхідною оперативною інформацією

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

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

Первинні  документи призначені для відображення процесів у матеріальній сфері та представляють всю постійну та оперативну інформацію, необхідну для рішення економічних завдань і управлінських рішень [24].

До числа основних вимог до первинних документів, можна віднести наступні:

-  не надмірність і повноту інформації для рішення завдань;

- високу вірогідність і своєчасність зібраної інформації.

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

При проектуванні форм первинних документів, в інформаційній системі враховувалися наступні вимоги:

• Відсутність у первинних документах постійної інформації, для якої необхідне створення самостійних файлів;
• Відсутність дублювання показників у документах;
• Ведення реквізитів, що мають одне або кілька значень на документ, тобто виділення однозначних та багатозначних реквізитів;
• Виділення довідкових, по-групованих реквізитів та реквізитів підстав;
• Логічність побудови, тобто старші за обсягом понять ознаки повинні передувати молодшим (наприклад: лікар  - розклад - хворий - запис на прийом);
• Узгодження послідовності реквізитів у документі з макетами розміщення інформації на екрані ЕОМ.

Вхідною інформацією є наступна:

• Відомості про пацієнтів;
• Інформація про лікарів;
• Запис на прийом;
• Запис на аналізи;
• Виклик терапевта додому.

Даталогічна модель

Даталогічна модель бази повинна відображати вимоги конкретної СУБД, в даному випадку MS Access 2003, тому в її склад входять таблиці, що містять відомості про інформаційні об'єкти й зв'язки між ними. Всі таблиці даталогічної моделі можна розбити на таблиці з оперативною інформацією й таблиці з умовно-постійною інформацією.

Склад поля, їхнє найменування, ідентифікатори відображені у відповідних таблицях, представлених нижче.

Таблиця 2.1.

Структура таблиці "Хворий"

№ п/п	Найменування поля	Ідентифікатор поля	Тип поля	Довжина поля	Ознака ключа
1	Kard	Номер карти	Текст	10	Первинний ключ
2	org_strahov	Організація страхування	Текст	50
3	Polisa	Номер поліса	Текст	50
4	kod_ligoty	Пільги	Число
5	SNILS	СНИЛС	Текст	50
6	Fam	Прізвище	Текст	50
7	Nam	Ім'я	Текст	50
8	Otch	По батькові	Текст	50
9	Pol	Стать	Текст	1
10	data_roj	Дата народження	Дата
11	post_obl	Адреса прописки	Текст	50
12	post_paion		Текст	50
13	post_city		Текст	50
14	post_street		Текст	50
15	post_home		Текст	50
16	post_korp		Текст	50
17	post_kv		Текст	50
18	reg_obl	Адреса проживання	Текст	50
19	reg_paion		Текст	50
20	reg_city		Текст	50
21	reg_street		Текст	50
22	reg_home		Текст	50
23	reg_korp		Текст	50
24	reg_kv		Текст	50
25	phone_home		Текст	50
26	phone_slug		Текст	50
27	doc_lgot	Телефон домашній	Текст	50
28	invalid	Телефон службовий	Текст	50
29	mesto_rab	Документ підтверджуючий пільги	Текст	50

 

Таблиця 2.2

Структура таблиці "Лікар"

№ п/п	Найменування поля	Ідентифікатор поля	Тип поля	Довжина поля	Ознака ключа
1	spec	Шифр	Лічильник		ПК
2	Profil	Профіль/спеціалізація	Текст	20
3	fam	Прізвище	Текст	50
4	nam	Ім'я	Текст	50
5	otch	По батькові	Текст	50

 

Таблиця 2.3

Структура таблиці "Розклад"

№ п/п	Найменування поля	Ідентифікатор поля	Тип поля	Довжина поля	Ознака ключа
1	kod	Шифр	Лічильник		ПК
2	Spec	Лікар	Число	Ціле	Код для зв'язку з таблицею лікарів
3	Week	День	Текст	10
4	Time	Час	Текст	50
5	Room	Кабінет	Текст	50

 

Таблиця 2.4

Структура таблиці "Виклик"

№ п/п	Найменування поля	Ідентифікатор поля	Тип поля	Довжина поля	Ознака ключа
1	kod	Шифр	Лічильник		ПК
2	Boln	Хворий	Число	Ціле	Код для зв'язку з таблицею хворих
3	Vrach	Лікар	Число	Ціле	Код для зв'язку з таблицею лікарів
4	date_v	Час виклики	Дата/час
5	Time	Час	Текст	50
6	Adres	Адреса	Текст	50

 

Таблиця 2.5

Структура таблиці "Запис на аналізи"

№ п/п	Найменування поля	Ідентифікатор поля	Тип поля	Довжина поля	Ознака ключа
1	kod	Шифр	Лічильник		ПК
2	Boln	Хворий	Число	Ціле	Код для зв'язку з таблицею хворих
3	Analiz	Аналіз	Текст	50
4	date_z	Дата аналізу	Дата/час

 

Таблиця 6

Структура таблиці "Запис на прийом"

№ п/п	Найменування поля	Ідентифікатор поля	Тип поля	Довжина поля	Ознака ключа
1	Kod	Шифр	Лічильник		ПК
2	Boln	Хворий	Число	Ціле	Код для зв'язку з таблицею хворих
3	Vrach	Лікар	Число	Ціле	Код для зв'язку з таблицею лікарів
4	date_z	Дата запису	Дата/час
5	Time	Час запису	Текст	10

Взаємозв'язок між таблицями наведено на рис. 2.4

Рис. 2.4 Схема даних

 

Цілісність БД

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