Характеристика первинних документів з нормативно – довідковою та вхідною оперативною інформацією
Під документом розуміється певна сукупність відомостей, використовувана при рішенні економічних завдань, розташована на матеріальному носії у відповідності до встановленої форми. Документ розглядається як спеціальний знак економічної мови, що має єдність форми, змісту й матеріального носія та володіючий наступними властивостями:
- Напівфункціональність, оскільки документ може призначатися для виконання функцій реєстрації інформації про стан елементів і процесів, що відбуваються в економічній системі, для обробки, зберігання цієї інформації та для передачі її на відстань;
- Наявності юридичної чинності, що забезпечується наявністю підписів посадових осіб, завдяки яким підтверджується вірогідність інформації, що втримується в документі.
Первинні документи призначені для відображення процесів у матеріальній сфері та представляють всю постійну та оперативну інформацію, необхідну для рішення економічних завдань і управлінських рішень [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 Схема даних
Цілісність БД
Одним з понять в технології баз даних являється цілісності. В загальному випадку це поняття перш за все зв'язано з тим, що база даних відображає в інформаційному вигляді деякий об'єкт або сукупність взаємозв'язаних об'єктів. В реляційній моделі об'єкти представлені у вигляді сукупності взаємозв'язаних відносин. Під цілісністю розумітимемо відповідність інформаційної моделі предметної області, збереженої в базі даних. Будь-яку зміну в наочній області, значущу для побудови моделі, повинно відбиватися в базі даних, і при цьому повинна зберегтися однозначна інтерпретація інформаційної моделі в термінах предметної області.
Відзначили, що тільки істотні або значущі зміни предметної області повинні відстежуватися в інформаційній моделі. Дійсно, модель завжди є деяким спрощенням реального об'єкту, в моделі ми відображаємо тільки те, що нам важливо для вирішення конкретного набору задач.
Крім того, розроблені методи автоматичного перетворення проекту БД з ER-моделі в реляційну, при цьому перетворення виконується в даталогічну модель, відповідної конкретної СУБД.
Результативна інформація.
Програма створює наступні звіти та документи:
- Звіти про виклики додому;
- Звіти про записи на прийом;
- Звіти про записи на здачу аналізів.
Дата добавления: 2018-09-22; просмотров: 174; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!