Українська  державна будівельна корпорація «УкрБуд»

      ДВНЗ  МАКІЇВСЬКИЙ ПОЛІТЕХНІЧНИЙ КОЛЕДЖ 
 
 
 
 

КУРСОВИЙ  ПРОЕКТ 

Пояснювальна  записка 

КП.5.080405.402/07.41.010.ПЗ 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

      Розробив:

      студент групи ПР – 41

      Левченко В.Н.

      Керівник  проекту:   

      Ніжник  Світлана Федорівна. 
 
 
 
 
 

2011

 

Завдання

на курсовий проект по предмету:

«Проектування автоматизованих інформаційних  систем». 

студенту спеціальності: "Програмування для ЕОТ і АС"

IV курсу  групи ПР – 41 Левченко Володимиру Миколайовичу

Тема завдання: розробити проект автоматизованої системи прийому пацієнтів у поліклініці.

Вхідні  дані: для таблиці Пацієнт: код, ПІБ, адреса, телефон, дата народження, група крові, страхова компанія, номер страховки; для таблиці Прийом: код, дата прийому, дата виписки, номер палати, код пацієнта; для таблиці Лікар: код, ПІБ, адреса, телефон, дата народження, спеціалізація, номер кабінету, робочий телефон, код прийому; для таблиці Курс лікування: код, діагноз, дата, час, ліки, примітки.

Завдання  для курсового  проекту: Спроектувати автоматизовану систему для обліку прийому пацієнтів у поліклініці. БД повинна містити наступні обов’язкові дані:

• Данні про пацієнта (ПІБ, телефон, адреса, група крові);
• Данні про прийом (дата прийому, дата виписки, номер палати);
• Данні про лікаря (ПІБ, адреса, спеціалізація, номер кабінету, телефон);
• Данні про курс лікування (діагноз, дата, час, ліки).

 

Календарний план виконання курсового проекту

 

Оцінка курсового  проекту:________________ 

Дата видачі                                                                

«1»    березня   2011р.

Строк закінчення                                                          

«12»   квітня    2011р. 

                                                                                                                   Викладач

Ніжник  Світлана Федорівна

 

Лист  зауважень 

 

 

Вступ

     

У сучасному  житті майже все тримається на комп’ютерних науках та техніці. У  наш час необхідно нехай не професійно, але як користувач знати  та вміти працювати за комп’ютером. Також необхідно володіти навичками роботи зі стандартними засобами, такими, як  MS Office.

     

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

     

Додаток Mіcrosoft Offіce  Access 2003 являє собою інструмент, що дозволяє реалізувати поставлену мету.

     

Досягнення мети здійснюється за допомогою комплексу завдань:

     

- проектування й створення таблиць для зберігання даних;

     

- уведення даних;

     

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

 

3. Загальна  частина

1.1. Дослідження предметної області

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

     Вихідними даними є звіти які формуються за  запитом оператора.    

1.2. Постановка завдання

Спроектувати  автоматизовану систему для обліку прийому пацієнтів у поліклініці. БД повинна містити наступні обов’язкові дані:

• Данні про пацієнта (ПІБ, телефон, адреса, група крові);
• Данні про прийом (дата прийому, дата виписки, номер палати);
• Данні про лікаря (ПІБ, адреса, спеціалізація, номер кабінету, телефон);
• Данні про курс лікування (діагноз, дата, час, ліки).

1.3. Описання вхідних даних

    Для вирішення задачі необхідно знати  які дані нам треба обробляти. У нашому випадку  вхідні дані мають  вигляд таблиць, яка представлені нижче.

Таблиця 1 – Данні про Пацієнта.

 

 

Таблиця 2 – Данні про Прийом.

Таблиця 3 – Данні про Лікаря.

Таблиця 4 – Данні про Курс лікування.

4. Описання  вихідних даних

Таблиця 5 – Звіт : Пацієнти з однаковими захворюваннями.

 

Таблиця 6 – Звіт : Звітний період.

1.5. Опис основних процедур перетворених даних

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

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

 

4. Основна частина

1. Розробка  інформаційної моделі

     Розробка  концептуальної моделі представлена у  вигляді ER-діаграми: 

Рис.1 ER – діаграма

 

2. Визначення суттєвостей і взаємозв’язків між ними

     Згідно з побудованої інфологічної моделі визначені суттєвості (об`єкти):

• Пацієнт, який включає такі атрибути: ПІБ пацієнта, телефон, адреса, група крові;
• Прийом, який включає такі атрибути:  дата прийому, дата виписки, номер палати;
• Лікар, який включає такі атрибути:  ПІБ лікаря, адреса, спеціалізація, номер кабінету, телефон;
• Курс лікування, який включає такі атрибути:  діагноз, дата, час, ліки, дієти, примітки.

 

     Визначення  взаємозв’язків між суттєвостями:

Рис. 2. Взаємозв’язок між об’єктами Пацієнт та Прийом.

    Поле  id_Паціента є первинним ключем для таблиці Паціент, за допомогою якого встановлюється зв’язок між записами таблиць Паціент та Прийом і зовнішнім ключем для таблиці Прийом. 

Рис. 3. Взаємозв’язок між об’єктами Прийом та Лікар.

    Поле  id_Прийому є первинним ключем для таблиці Прийом, за допомогою якого встановлюється зв’язок між записами таблиць Прийом та Лікар і зовнішнім ключем для таблиці Лікар.

    

Рис. 4. Взаємозв’язок між об’єктами Продаж та Контрагент.

    Поле  id_Лікаря є первинним ключем для таблиці Лікар, за допомогою якого встановлюється зв’язок між записами таблиць Лікар та Курс лікування і зовнішнім ключем для таблиці Курс лікування.

Рис. 5. Загальний взаємозв’язок між об’єктами Пацієнт, Прийом, Лікар та Курс лікування 

    Для встановлення зв`язку між пацієнтом та самим прийомом, розглянемо об’єкти Пацієнт та Прийом. У складі атрибутів об`єкта Пацієнт є поле id_Паціента, яке необхідно для зв`язку з полем id_Паціента об`єкта Прийом. Оскільки кожен пацієнт може приходити декілька разів, то цей зв`язок має тип «один-до-багатьох».

    Для встановлення зв`язку між прийомом та лікарем, який буде проводити прийом, розглянемо об’єкти Прийом та Лікар. У складі атрибутів об`єкта Прийом є поле id_Прийому, яке необхідно для зв`язку з полем id_Прийому об`єкта Лікар. Оскільки однин прийом може проводити один лікар, то цей зв`язок має тип «один-до-одного».

    Для встановлення зв`язку між лікарем та курсом лікування, який він назначив, розглянемо об’єкти Лікар та Курс лікування. У складі атрибутів об`єкта Лікар є поле id_Лікаря, яке необхідно для зв`язку з полем id_Лікаря об`єкта Курс лікування. Оскільки кожен лікар може назначати декілька курсів, то цей зв`язок має тип «один-до-багатьох».

3. Обґрунтування вибору СКБД, проектування БД

     Сучасне життя неможливе без ефективного  керування. Важливою категорією являються  системи обробки інформації, от котрих залежить ефективність роботи будь-якого підприємства або закладу. Така система повинна:

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

     Сучасна СКБД в основному являється додатком Windows, так як дана середа дозволяє більш  повно використати можливості персональної ЕОМ, ніж середа DOS. Зниження вартості високовиробничих ПК обумовив не тільки широкий перехід до середи Windows, де розробник програмного-забезпечення може у меншій ступені піклуватися о розподілі ресурсів, але також зробити програмне-забезпечення ПК у цілому та СКБД в частості меншій критичними до апаратних ресурсів ЕВМ.

     Серед найбільш яскравих представників систем керування базами даних можливо відмітити: Lotus Approach, Microsoft Access, Borland dBase, Borland Paradox, Microsoft Visual FoxPro, Microsoft Visual Basic, а також база даних Microsoft SQL Server та Oracle, використаних у додатках, побудованих по технології «клієнт-сервір». Фактично, у будь-якій сучасній СКБД існує аналог, випускаємой іншою компанією, яка має аналогічну область застосування та можливості, будь-який додаток в змозі працювати з багатьма форматами представлення даних, здійснювати експорт та імпорт даних завдяки наявності більшого числа конвертерів.

     Проглянувши всі ці системи керування базами даних, була обрана система Microsoft Access. Так як – це одна із самих поширених та популярних у сучасний час реляційна СКБД. Так, наприклад, при роботі з об’єктами Access у режимі конструктора доступна багато кратна відміна виповнених дій. Завдяки підтримки в Access по умовчанню форматів файлів, більш пізніх версій, існуючі розробки без проблем переносяться у нову середу. (Файл бази даних Access, маючий розширення .mdb, представляє собою сукупність всіх об’єктів конкретного додатка: таблиць, запитів, форм, звітів, сторінок, макросів та модулів.) Значно зручніше працювати зі зведеними таблицями і діаграмами, котрі, окрім того, можна зберегти  у вигляді сторінок доступу к даним.

     Переваги  БД:

     Взаємопов’язаність  даних:

     Локалізація певної групи даних програми загалом  полегшує доступ до інших груп даних  цього ж застосування. В наслідок орієнтації БД на велику кількість сеансів використання виникає необхідність у підтримці різноманітних зв’язків між даними.

     Мінімальна  надлишковість:

     Вимога  мінімізації надлишковості полягає  в тому, що в базі має зберігатися  мінімальна кількість копій одних  і тих самих даних. Це необхідно у зв’язку з орієнтацією БД на кілька застосувань. Надлишкові копії використовуються для підтримки зв’язків між даними.

     Незалежність  даних від програм:

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

     Цілісність  та захист від неавторизованого доступу:

     Під цілісністю бази даних розуміють  несуперечність (відповідність певним умовам) даних, що в ній зберігаються. Наприклад для кадрових даних  рік народження співробітника не може бути більшим за рік призначення на посаду або поточний рік.

     Для уникнення суперечливих ситуацій при  модифікації бази даних співвідношення між даними контролюються спеціальними засобами підтримки цілісності БД. Умови, що накладаються спеціальною  службою – адміністраторами баз даних (АБД), а СКБД надають необхідні інструментальні засоби.

     Оскільки  БД орієнтовано на широке коло застосувань, то зрозумілим є існування засобів  захисту від неавторизованого доступу(навмисного чи ненавмисного) користувачів до даних. Серед них – система паролів та індентіфікацій користувачів, а також розподіл даних і користувачів на групи з різними правами.

     Крім  наведених, БД мають ще низку переваг  порівняно з файловими системами:

• інтегроване зберігання даних;
• централізоване керування;
• ефективне керування доступом до даних;
• скорочення часу розробки програмних систем;
• спільне використання даних;
• відновлення бази даних;
• дотримання стандартів.

     Наприклад, коли порівнювати Microsoft Access з системою керування Oracle, ми побачимо, що він нам не підходить тому, що Oracle підходить для розробки більш складних БД, які потрібні середнім або великим підприємствам, та і ціна за велика. А Microsoft Access є стандартною і більш доступною системою керування та нескладна у розумінні.

2.4 Розробка даталогічної моделі

2.4.1 Визначення об’єктів

    Згідно  з побудованою інфологічною моделлю  визначені сутності (об`єкти):

• Пацієнт;
• Прийом;
• Лікар;
• Курс лікування.

Таблиця 7 – склад атрибутів об'єкту Пацієнт.

 

Таблиця 8 – склад атрибутів об'єкту Прийом.

 

Таблиця 9 – склад атрибутів об'єкту Лікар.

 

Таблиця 10 – склад атрибутів об'єкту Курс лікування.

 

2.4.2 Визначення взаємозв’язків між об’єктами

Рис. 6. Взаємозв’язок між об’єктами Пацієнт та Прийом.

    Поле  id_Паціента є первинним ключем для таблиці Паціент, за допомогою якого встановлюється зв’язок між записами таблиць Паціент та Прийом і зовнішнім ключем для таблиці Прийом. 

Рис. 7. Взаємозв’язок між об’єктами Прийом та Лікар.

    Поле  id_Прийому є первинним ключем для таблиці Прийом, за допомогою якого встановлюється зв’язок між записами таблиць Прийом та Лікар і зовнішнім ключем для таблиці Лікар.

    

Рис. 8. Взаємозв’язок між об’єктами Продаж та Контрагент.

    Поле  id_Лікаря є первинним ключем для таблиці Лікар, за допомогою якого встановлюється зв’язок між записами таблиць Лікар та Курс лікування і зовнішнім ключем для таблиці Курс лікування.

2.4.3 Завдання атрибутів, первинних та альтернативних ключів

     Ключове поле – упорядковане індексоване  поле. Ключових полів може бути декілька.

     Первинний ключ – одне або декілька ключових полів, що звичайно використовуються для  зв’язку між таблицями. Це поле повинно  містити тільки унікальні ненульові значення. Ключ, що складається з одного поля, називається простим. Ключ, що складається з декілька полів, називається складовим. Ключ може бути тільки один. Первинний ключ однозначно визначає запис. Таблиця автоматично сортує за значенням первинного ключа.

     Зовнішній ключ – один або декілька полів  таблиці, що вказує на запис в іншій  таблиці.

Таблиця 11 – Склад атрибутів об`єкта Пацієнт

 

Таблиця 12 – Склад атрибутів об`єкта Прийом

 

    Поле  id_Паціента є первинним ключем для таблиці Паціент, за допомогою якого встановлюється зв’язок між записами таблиць Паціент та Прийом і зовнішнім ключем для таблиці Прийом.

Таблиця 13 – Склад атрибутів об`єкта Прийом

 

Таблиця 14– Склад атрибутів об`єкта Лікар

 

    Поле  id_Прийому є первинним ключем для таблиці Прийом, за допомогою якого встановлюється зв’язок між записами таблиць Прийом та Лікар і зовнішнім ключем для таблиці Лікар. 
 
 
 
 
 
 

     Таблиця 15 – Склад атрибутів об`єкта Лікар

Таблиця 16– Склад атрибутів об`єкта Курс лікування.

 

    Поле  id_Лікаря є первинним ключем для таблиці Лікар, за допомогою якого встановлюється зв’язок між записами таблиць Лікар та Курс лікування і зовнішнім ключем для таблиці Курс лікування.

2.4.4 Нормалізація моделі

     Нормалізація  даних – це процес, за допомогою  якого будується модель даних  відповідно до певних вимог. Для моделей зв’язків і сутностей такою вимогою є мінімізація дублювання даних з метою забезпечення гнучкості й можливості відображення моделі в різних схемах проектування баз даних.

     Для того аби перевірити, що модель сутностей  і зв’язків, в якій усі сутності унікально ідентифіковані, перебуває в третій нормальній формі, необхідно перевірити її відповідність кільком умовам.

     Попередня умова

     Всі сутності мають бути унікально ідентифіковані комбінацією атрибутів та/ або зв’язків.

     Перша нормальна форма

     Слід  видалити атрибути або групи атрибутів, що повторюються. Якщо атрибут може набувати більше одного значення водночас або є більше одного атрибута з  тим самим ім’ям, то необхідно  означити нову сутність, яка описується цим атрибутом. Унікальний ідентифікатор нової суттєвості складається з атрибутів, що перейшли до нього, і зв’язку типу “ багато – до – одного ” з вихідною сутністю.

     Друга нормальна форма

     Слід  видалити атрибути, залежні тільки від частини унікального ідентифікатора.

     Якщо  сутність має унікальний ідентифікатор, що складається більш ніж з одного атрибута та/або зв’язку і якщо певний атрибут залежить тільки від частини цього складеного ідентифікатора, тоді цей атрибут і та частина ідентифікатора, від якої він залежить, мають стати основною для формування нової сутності. Нова сутність ідентифікуються успадкованою частиною унікального ідентифікатора вихідної сутності та має з нею зв’язок типу “один – до – багатьох ”.

     Третя нормальна форма

     Слід  виділити атрибути, залежні від атрибутів, що не є частиною унікального ідентифікатора.

     Якщо  існує атрибут, який залежить від  іншого атрибута, що не є частиною унікального  ідентифікатора, то залежний атрибут  разом із тим атрибутом, від якого  він безпосередньо залежить, мають  становити основу для формування нової сутності, яка буде сполучена зв’язком типу ”один – до – багатьох ” з вихідної сутністю. Унікальним ідентифікатором нової сутності є той атрибут, від якого залежить інший атрибут.

2.4.5 Фізичний опис моделі

 

     База  даних організована в популярному  форматі локальних баз даних MS Access. Цей формат для організації реляційних баз даних досить розповсюджені, оскільки володіє найбільше розвитою системою збереження типів даних, можливостями індексування полів, що дозволяє одержувати доступ до даних за мінімальний час, а також функціями по забезпеченню посилальної цілісності між реляційними таблицями, що дозволяє розробнику мінімізувати тимчасові витрати на створення бази даних, а кінцевому користувачу витрати на підтримку цілісності збереження даних та отримання з ази даних збереження даних. Оскільки база даних MS Access – реляційна аза даних, то запити к даним здійснюються з допомогою реляційної мови запитань SQL. Завдяки розвинутій системі визначення ключових полів та індексів при створенні таблиць запити будуть виконуватися з мінімальними тимчасовими витратами. Цей фактор для локальних баз даних не є ключовим, однак, при зрості об’єму збереження даних швидкість виконування запитів стає вирішальним фактором при виборі формату баз даних.

     База  даних «Автоматизована система прийому пацієнтів у поліклініці» представлена чотирма таблицями: Пацієнт (таблиця 17), Прийом(таблиця 18), Лікар (таблиця 19), Курс лікування (таблиця 20). Розглянемо структуру кожної докладно.

     В таблиці Пацієнт представлена інформація про усіх пацієнтів які зверталися у поліклініку. Поля, їх типи представлені в таблиці 17

Таблиця 17 – Опис об’єкта Пацієнт

     Первинним ключем таблиці є поле id_Пацієнта, яке однозначно визначає кожне поле таблиці.

     В таблиці Прийом представлена інформація про звернення пацієнта. Поля, їх типи представлені в таблиці 18

Таблиця 18 – Склад атрибутів об’єкта Прийом

 

     Первинним ключем таблиці є поле id_Прийому, яке однозначно визначає кожне поле таблиці.

     В таблиці Лікар представлена інформація о лікарі який працює у цій поліклініці. Поля, їх типи представлені в таблиці 19

Таблиця 19– Склад атрибутів об’єкта Лікар

 

     Первинним ключем таблиці є поле id_Лікаря, яке однозначно визначає кожне поле таблиці.

     В таблиці Курс лікування представлена інформація про лікування хворого. Поля, їх типи представлені в таблиці 20

Таблиця 20– Склад атрибутів об’єкта Курс лікування

 

     Первинним ключем таблиці є поле id_ Курс_лікування, яке однозначно визначає кожне поле таблиці.

 

2.4.6 Реалізація запитів, форм та звітів

     Запит – це інструмент управління даними, який дозволяє витягати із таблиць бази даних відомості, які відповідають визначеному критерію. За допомогою запитів можливо автоматизувати процес відновлення або видалення запитів з одній або декількох таблиць, а також робити обчислення, ґрунтуючись на значеннях, зберігаючись у таблиці. Запити можливо будувати за допомогою конструктора, майстра або у режимі SQL запитів.

     Для реалізації поставленого завдання треба  було реалізувати запит переліку пацієнтів, які за тих або інших обставин були госпіталізовані, він включає в себе ПІБ пацієнта його діагноз, а також дату звернення. (рис.9 та рис.10).

Рис. 9 Запит переліку госпіталізованих пацієнтів у режимі конструктор. 

Рис. 10 Запит переліку госпіталізованих пацієнтів у режимі таблиці.

 

      Для того, щоб робітники мали змогу  визначитися яка на даний момент найбільш прогресуюча хвороба було створено запит, котрий визначає хворобу з якою зверталися найбільшу кількість разів, який включає в себе: ПІБ пацієнта, діагноз, а також прописані ліки. (рис.11 та рис. 12).

     Рис. 11 Запит на найпоширенішу хворобу у режимі конструктор.

     Рис. 12 Запит перелік найпоширенішу хворобу у режимі таблиці 

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

    Після запуску БД з’явиться головна форма(рис.13).

    На  головній формі розташовані 2 кнопки: Таблиці та Звіти.

 

     Рис. 13 Головна форма

     При натисканні на одну з кнопок відкриється одна з проміжних форм. При натисканні на кнопку Таблиці відкриється форма яка зображена на Рис.14, а Звіти – Рис.15

Рис. 14 Проміжна форма Таблиці

Рис. 15 Проміжна форма Звіти

     Розглянемо  групу Таблиця (Рис.16 – Рис.19)

     Після того, як ви натиснули кнопку Пацієнт, на екрані з’явиться форма для заповнення даних про пацієнта (Рис. 16).

Рис. 16 Форма Пацієнт

    При натисканні на кнопку Прийом здійснює перехід до форми для роботи з даними про прийом. (Рис.17).

Рис. 17 Форма Прийом 

    При натисканні на кнопку Лікар здійснює перехід до форми для роботи з даними лікаря. (Рис.18).

Рис. 18 Форма Лікар 

    При натисканні на кнопку Курс Лікування здійснює перехід до форми для роботи з даними продажу. (Рис.19).

Рис. 19 Форма Курс лікування 

     Тепер розглянемо групу Звіти

     При натисканні на кнопку Госпіталізовані з’явиться список усіх хворих яких було госпіталізовано (Рис.20)

     Рис. 20 Звіт Госпіталізовані

     При натисканні на кнопку Часта хвороба з’явиться список  людей які хворіють однією хворобою, яка на даний момент зустрічається найчастіше (Рис.21)

     Рис. 21 Звіт Найчастіша хвороба

     У БД є можливість переглянути всі звернення у поліклініку за деякий період. Для цього необхідно натиснути кнопку «Звітний період» (Рис 22)

     Рис. 22. Вибір терміну  продаж

 

3. Висновок

     Моїм  завданням курсового проекту  було розробити автоматизовану систему для обліку продаж на мебельній фабриці. На мій погляд, я з цим завданням впорався. Завдяки цьому проекту, я навчився робити форми, запити, звіти, діаграми в Microsoft Access. Для того, щоб створити гарний та зручний у використанні інтерфейс я:

1. ознайомився з проблемною сферою та з процесом обліку та звітуванням продажам;
2. визначив тип організації та структурний підрозділ;
3. визначив суттєвості для побудови інфологічної системи;
4. створив таблиці з вказаним розміром, ім’ям та типом;
5. вказав типи взаємозв’язків між об’єктами;
6. розробив зовнішній вигляд вихідних документів;
7. розробив  форми;
8. зробив запити;
9. на основі запитів зробив звіти;
10. створив діаграму;
11. перевірив зв’язки між об’єктами моделі;
12. розробив графічний інтерфейс та реалізував його.

     Всі ці маніпуляції допомогли мені поповнити  знання комп’ютерних наук та закріпили  знання отриманні на предметі ПАІС, а по базам даних. 

 

4. Список літератури

1. Кравченко В.Г., Проектування автоматизованих  інформаційних систем: Навчальний посібник – Київ.: КНЕУ, 2008 – 360 стор.
2. Иванова Г.С., Технология программирования: Учебник для вузов – Москва.: Издательство МГТУ им. Н.Є. Баумана, 2002 – 320стр.
3. Пасічник В.В., Резніченко В.А., Організація баз даних та знань. – Київ.: Видавнича група BHV, 2006. – 384 стор.
4. Ситник Н.В., Краснюк М.Т. Проектування баз і сховищ даних: Навчальний метод посібник для самостійного вивчення дисциплін. – Київ.: КНЕУ, 2005. – 264 стор.
5. Вендров А.М. Проектирование программного обеспечения экономического обеспечения экономических информационных систем: Учебник. – Москва.: Финансы и статистика, 2003. – 352стр.
6. Атре Ш. Структурний підхід до організації баз даннях,  1983. – 320 з.
7. Бойко в.В., Савінков в.М. Проектування баз даних інформаційних систем, 1989. – 351 з.
8. Джексон Г. Проєктірованіє реляційних баз даних для використання з МІКРОЕОМ. -М.: Мир, 1991. – 252 з.
9. Мартін Дж. Планування розвитку автоматизованих систем, 1984. – 196 з.
10. Мейер М. Теорія реляційних баз даних. – М.: Мир, 1987. – 608 з.
11. Тіорі Т., Фрай Дж. Проектування структур баз даних. У 2 кн., – М.: Мир, 1985. Кн. 1. – 287 с.: Кн. 2. – 320 з.
12. Хаббард Дж. Автоматизоване проектування баз даних. – М.: Мир, 1984. – 294 з.
13. Цикрітізіс Д., Лоховські Ф. Моделі даних, 1985. – 344 з.
14. Переклад: М.Р. Когаловській Модель "сущность-связь" – шаг к единому представлению о данных. Петер Пін-шен Чен, 1976 р. Нова редакція: Сергій Кузнецов, 2009 р.

 

5. Список електронних ресурсів

1.   http://books.net-soft.ru/access.htm - посібник Access для вивчення роботи з базами даних MS Access

2.http://www.citforum.ru/database/edu.shtml - навчальні засоби по СКБД.

 

Додаток А

Рис. 23. Таблиця БД «Пацієнт» 

Рис. 24. Таблиця БД «Прийом» 

Рис. 25. Таблиця БД «Лікар»

Рис. 26. Таблиця БД «Курс лікування»

 

Додаток Б

     Лістинг запита «Госпіталізовані хворі»

     SELECT Пациент.Фамилия,  Пациент.Имя, Пациент.Отчество, [Курс  лечения].Диагноз, [Курс лечения].Дата

     FROM (Пациент INNER JOIN Прием ON Пациент.id_Пациента = Прием.id_Пациента) INNER JOIN (Врач INNER JOIN [Курс  лечения] ON Врач.id_Врача = [Курс лечения].id_Врача) ON Прием.id_Приема = Врач.id_Приема

     WHERE (((Прием.Госпитализация)=Yes));

Додаток В

     Лістинг запита «Хвороба, які зустрічається найчастіше»

     SELECT Пациент.Фамилия, Пациент.Имя, Пациент.Отчество, Врач.Фамилия, Врач.Имя, Врач.Отчество, [Курс лечения].Диагноз, [Курс лечения].Дата

     FROM (Пациент INNER JOIN Прием ON Пациент.id_Пациента = Прием.id_Пациента) INNER JOIN (Врач INNER JOIN [Курс  лечения] ON Врач.id_Врача = [Курс лечения].id_Врача) ON Прием.id_Приема = Врач.id_Приема;