Автоматизація ведення бази даних індивідуальних програм реабілітації інвалідів
Проектування бази даних та інтерфейсу програми. Розробка бази даних за допомогою Firebird 2.5. Контроль коректності вхідних та вихідних даних. Додавання та редагування інформації. Вплив електронно-обчислювальних машин на стан здоров'я користувачів.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | украинский |
Дата добавления | 12.10.2015 |
Размер файла | 4,7 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
РЕФЕРАТ
Темою дипломного проекту є «Автоматизація ведення бази даних індивідуальних програм реабілітації інвалідів».
Об'єкт дослідження: система ведення індивідуальних програм реабілітацій інвалідів.
Мета роботи - дослідити сферу роботи МСЕК та розробити автоматизовану систему ведення індивідуальних програм реабілітацій інвалідів.
Загальна частина 13 сторінок. Вимоги до технічних засобів, опис інструментальних засобів, що використовувались при розробці програми.
Спеціальна частина 48 сторінок. Докладна інформація про розроблення та експлуатацію програми.
Економічна частина 4 сторінки. Економічний розрахунок вартості програмного продукту.
Охорона праці 20 сторінок. Аналіз та розрахунок захисту від шкідливих та небезпечних факторів.
В даному дипломному проекті засобами середовища Delphi 7 розроблено програму, що призначена для для автоматизації ведення бази даних індивідуальних програм реабілітації інвалідів.
Ключові слова: ІНВАЛІДИ, АВТОМАТИЗАЦІЯ, ІНДИВІДУАЛЬНА ПРОГРАМА РЕАБІЛІТАЦІЇ, БАЗА ДАНИХ, ДОУМЕНТ, ДОВІДКА, DEPHI 7, FIREBIRD 2.5.
ВСТУП
При оформленні індивідуальної програми реабілітації інвалідів треба виконати багато паперової роботи: подати ряд документів, оформити огляд і отримати підтвердження. При цьому для отримання документа на індивідуальну програми реабілітації (далі ІПР) потрібно буде заповнити багато бланків. Ведення цих даних включає різноманітну інформацію, що повторюються із одного документу до іншого, що підвищує ймовірність виникнення помилок та вимагає часу на заповнення документів. До того ж у великій кількості довідок важко орієнтуватися. Таким чином для обліку даних потрібно вести базу даних, що повинна включати таку інформацію, як особисті дані пацієнта та інформацію про його захворювання, ступінь обмеження життєдіяльності та реабілітаційні заходи, інформація про призначення спеціальних засобів.
До задач автоматизації можна віднести:
- запобігання несанкціонованого доступу до даних;
- зменшення кількості помилок;
- контроль за ІПР різних років;
- зменшення кількості часу на складання документу та пошук.
В результаті аналізу стану галузі постає задача про надання персоналу можливостей:
- ведення списків інвалідів та призначених їм ІПР;
- оформлення ІПР та пошук серед них;
- формування документу про ІПР.
У зв'язку з цим була б актуальна програма, що автоматизує процес ведення бази даних особистої інформації про інвалідів, обмежень життєдіяльності інвалідів та індивідуальних програм реабілітації інвалідів. Вона не повинна вимагати спеціальних знань від користувача та могла б використовуватися у медичних закладах для ведення бази даних по індивідуальним програмам реабілітації інвалідів.
На основі попереднього аналізу є цілком обґрунтованою розробка програмного забезпечення, призначеного для автоматизації ведення даних по даним інвалідів та ІПР для використання Медико-соціальною експертною комісією (далі МСЕК).
Темою даного дипломного проекту є «Автоматизація ведення бази даних індивідуальних програм реабілітації інвалідів».
Виходячи з вище написаного, можна зробити висновок про те, що тема дипломного проекту є актуальною, а поставлене завдання - своєчасним.
1. ПОСТАНОВКА ЗАВДАННЯ
Тема даного дипломного проекту -- «Автоматизація ведення бази даних індивідуальних програм реабілітації інвалідів». Система повинна складатися з підсистем адміністрування, ведення даних про інваліда, дані про ІПР, пошук, формування документів.
В рамках даного дипломного проекту потрібно організувати базу даних та розробити програмний додаток, який дозволяє працювати з розробленою базою даних, яка повинна містити довідники, що можуть доповнятися в процесі роботи програми та стандартні довідники, що поставляються з шаблоном бази даних вже заповненими. База даних повинна містити інформацію у таблицях про осіб, що мають інвалідність в таблиці «Особиста картка», основні дані про індивідуальну програму реабілітації у таблиці «ІПР», дані про обмеження життєдіяльності в таблиці «Обмеження», а також дані про заходи по реабілітації у таблиці «Реабілітація».
Програма повинна формувати документ вказаного типу у вигляді Excel.
Крім того, програма повинна перевіряти усі введені дані на коректність та видавати повідомлення у випадку помилкового вводу.
Програма повинна дозволяти такі дії з інформацією пов'язаної з ІПР над таблицями бази даних, як перегляд, додавання, редагування, видалення інформації про особисті дані пацієнта, а також пов'язаної з особистою карткою ІПР, обмежень та реабілітаційних заходів, а також сортування, фільтрування та пошук даних про пацієнта. Стосовно ІПР програма повинна надавати можливість роботи з такою інформацією, як номер програми реабілітації, дата запису, тип програми реабілітації, тривалість перебування на інвалідності, діагноз, супутні захворювання, реабілітаційний потенціал, дата контролю за виконанням ІПР, працівник, що заповнив документ.
При введенні інформації користувачем програма повинна максимально забезпечувати контроль даних, що вводяться.
Програмне забезпечення повинно мати сучасний, зручний та зрозумілий для користувача інтерфейс.
Вхідні дані наведено у додатку А.
Лістинг програми міститься у додатку Б.
2. ЗАГАЛЬНА ЧАСТИНА
- 2.1 Вимоги до технічних заходів, що застосовуються
Технічні вимоги до ПК повинні відповідати мінімальним системним вимогам для розробки і експлуатації програмного продукту.
Вимоги до складу і параметрів технічних засобів: система повинна працювати на ІBM-сумісних персональних комп'ютерах.
Мінімальні вимоги до конфігурації персонального комп'ютеру:
- тип процесора Intel Pentium 166 MHz або краще;
- обсяг оперативного запам'ятовуючого пристрою 64 Мб і більше;
- обсяг вільного місця на жорсткому диску 124 Мб;
- операційна систем Microsoft Windows XP.
Рекомендовані вимоги до конфігурації персонального комп'ютеру:
- тип процесора Intel Pentium 500 MHz або краще;
- обсяг оперативного запам'ятовуючого пристрою 256 Мб і більше;
- обсяг вільного місця на жорсткому диску750 Мб і більше;
- операційна систем Microsoft Windows XP, Vista, 7.
- 2.2 Опис інструментальних засобів, що застосовуються
Завдяки своїй зручності поширена об'єктно-орієнтована технологія візуального програмування, яка дозволяє швидко розробляти програми. Для розробки даного проекту обрано інтегроване середовище Borland Delphi 7 та система СУБД FireBird 2.5.
Середовище Borland Delphi 7 було обрано завдяки своїй зручності у використанні та широкому виборі компонентів візуального програмування.
Щодо архітектури і принципів роботи Borland Delphi можна сказати, що Delphi -- це об'єктно-орієнтоване середовище візуального програмування (RAD -- Rapid Application Development) [1-3]. Delphi призначено для прискореної розробки високопродуктивних програм, які можуть працювати в середовищі Windows або Linux. При цьому Delphi дозволяє звести до мінімуму об'єм програмного коду, який вводиться вручну. В склад Delphi входять засоби, необхідні для розробки, тестування та встановлення програм, включаючи велику за обсягом бібліотеку компонентів (VCL -- Visual Components Library), засоби візуального проектування, шаблони програм і форм. Середовище проектування Delphi є відкритою системою і дозволяє використовувати як компоненти VCL, так і компоненти від сторонніх розробників, або власні компоненти. Також, сильною стороною Delphi є можливість використання функцій WinAPI.
В системі Delphi використовується спеціалізована версія мови програмування Pascal, що постійно вдосконалюється; вона називається Delphi (в шостій і більш ранішніх варіантах системи Delphi вона називалась Object Pascal - "Об'єктний Паскаль"). Ця версія включає набір розширень, орієнтованих тільки на застосування в рамках середовища Delphi і призначених для прискореного створювання програм.
Середовище Delphi 7 являє собою інтегровану оболонку розробника, в яку входить набір спеціалізованих програм, які відповідають за різні етапи створення готової програми. Основні вікна системи Delphi 7 наступні: інспектор об'єктів, провідник, проектувальник форм, вікно редактора. Вихідний текст програми формується в середовищі Delphi 7 за допомогою вбудованого редактора вихідних текстів. Цей редактор спеціалізований. Він відрізняється гнучкими можливостями кольорового виділення різних елементів тексту програми (ключових слів, назв, операцій, чисел і рядків) і надає можливість швидкого вводу конструкцій, які часто зустрічаються.
Елементами мови є набори компонентів, які дозволяють створювати додатки за найрізноманітнішими тематиками. Компоненти володіють наборами властивостей, що характеризують їх особливості. Крім властивостей, компоненти містять методи -- програмний код, який обробляє значення властивостей та події -- повідомлення, які компонент приймає від програми. Всі програми в Delphi 7 будуються за наступним принципом: в головній частині з розширенням .DPR зберігається тільки виклик декількох команд, які відкривають головне вікно, а також виконують завершальні дії. Решта всього програмного коду міститься в файлах, що зберігають опис додаткових модулів, які підключаються. Кожен модуль має чітко задану структуру, яка зазвичай автоматично генерується системою Delphi 7 при його створенні. Модуль складається з чотирьох частин: інтерфейсної частини, частини реалізації (обов'язкова), частини ініціалізації і частини завершення (необов'язкова). Спочатку вказують заголовок модуля - ключове слово Unit, за ним довільну назву модуля (вона повинна співпадати з іменем файлу, в якому модуль зберігається) і ставлять крапку з комою: Unit Testunit. Інтерфейсна частина описує інформацію, яка доступна з інших частин програми, з інших модулів і головної частини. Частина реалізації описує інформацію, яка недоступна з інших модулів. Подібне розділення модуля на частини дозволяє створювати і розповсюджувати модулі у відкомпільованому вигляді (розширення DCU), додаючи до них тільки опис інтерфейсної частини. При цьому внести зміни в такий модуль неможливо, вихідний код, який реалізує описані в інтерфейсній частині можливості, недоступний. Такий підхід дозволяє повторно використовувати раніше написані модулі для інших програм і вже відкориговані модулі та розмежовує доступ до модуля декількох програмістів, а також дозволяє розбивати програму на набір логічно незалежних модулів. Інтерфейсна частина завжди йде першою і починається з ключового слова interface, а частина реалізації з - implementation. Частини ініціалізації і завершення необов'язкові. Вказані в них дії виконуються, відповідно, на самому початку та в самому кінці роботи програми і тільки один раз. Частина ініціалізації починається з ключового слова initialization, частина завершення -- з ключового слова finalization. В кінці модуля завжди ставиться слово end і крапка.
Базовими елементами мови являються: коментарі, змінні, константи, оператори, типи даних тощо.
Це середовище дозволяє створювати візуальний інтерфейс, має простий синтаксис. Також воно добре документовано, що дозволить швидше виконати поставлену задачу.
Delphi -- це нащадок Турбо Паскаля, який був випущений для операційної системи Cp/m в 1983 році. У лютому 1994 року Турбо Паскаль був перенесений на операційну систему MS-DOS. На ранньому етапі розвитку комп'ютерів IBM РС, Турбо Паскаль був однією з найбільш популярних мов розробки програмного забезпечення -- головним чином тому, що це був цілком серйозний компілятор, який, включаючи компілятор, редактор і відладчик. Середовище мало змогу працювати на машині з 64 Kb оперативної пам'яті.
Під Windows Турбо Паскаль був перенесений фірмою Borland в 1990 році. А остання версія Borland Pascal 7.0 (має тепер таку назву), не рахуючи Delphi, вийшла в світ в 1992 році. Розробка Delphi почалася в 1993 році. Після проведення beta-тестування Delphi показали на "Software Development '95". Спочатку на Delphi можна було програмувати під MS Windows 3.1. Починаючи з версії 2.0 на Delphi можна створювати програми під будь-яку з 32-бітних версій MS Windows.
В 2000 році була спроба створити варіант Delphi під операційну систему на базі ядра Linux, така модифікація Delphi мала назву Kylix. Було випущено 3 версії Kylix, проте експеримент виявився невдалим і 2003 року проект був заморожений.
2003 року була створена модифікація мови під платформу Microsoft.NET, що отримала назву Delphi.NET. Цей варіант мови послідовно розвивається в версіях Delphi 8, 2005, 2006, 2007.
Частково Delphi підтримується також у відкритому проекті FreePascal, що потенційно дозволяє створювати програми під велику кількість платформ.
СУБД Firebird є однією з найпопулярніших у світі безкоштовних, кросплатформових систем управління базами даних з відкритим вихідним кодом. FireBird є поширеною СУБД, основними перевагами якої є можливість створення великих та складних баз даних, проте розмір бази не вплине на швидкодію роботи з нею. Також вона має повну відповідність вимогам ACID: СУБД Firebird зроблений спеціально, щоб задовольняти вимогам атомарності, цілісності, ізоляції та надійності.
Вона була розроблена на основі вихідного коду СУБД Interbase і розвивається сьогодні незалежним міжнародним співтовариством. За надійністю, продуктивністю та функціональними можливостями ця система мало чим поступається визнаним лідерам свого класу -- Oracle і Microsoft SQL Server.
Основні можливості СУБД Firebird полягають в тому, що вона повністю підтримує стандартні ANSI в синтаксисі мови SQL і може працювати під управлінням багатьох операційних систем -- Windows, Linux, MacOS, Solaris і різних Unix-платформах. Серед переваг цієї системи використання дуже розвиненої мови для збережених процедур і тригерів. Попередник Firebird, СУБД Interbase, використовувалася в інформаційних системах починаючи з 1981 року.
Firebird це вільний проект, підтримуваний багатьма програмістами та спеціалістами з інших областей по всьому світу. Його початок було покладено 25 липня 2000 року, коли корпорація Inprise Corp (нині відома як Borland Software Corp) відкрила вихідні коди своєї СУБД Interbase, яка використовувалася в різних інформаційних системах, починаючи з 1981 року.
Firebird повністю безкоштовна, вона не вимагає ні реєстрації, ні оплати за підтримку. Вихідний код цієї системи відкритий і будь-який бажаючий може розробляти на його базі власні некомерційні проекти, за умови дотримання вимог ліцензії IDPL, по якій поширюється Firebird.
Firebird заснована на вихідному коді InterBase 6.0, який був випущений як Open Source компанією Borland в серпні 2000 року. Історія Interbase починається в 1984 році, таким чином, продукт є спадкоємцем більш ніж 20-річного досвіду роботи з реляційними базами даних.
В якості переваг Firebird можна відзначити багатоверсійну архітектуру, що забезпечує паралельну обробку оперативних і аналітичних запитів (це можливо тому, що читаючі користувачі не блокують тих, що пишуть), компактність (дистрибутив 5Mb), високу ефективність і потужну мовну підтримку для збережених процедур і тригерів.
Firebird використовується в різних промислових системах (складські та господарські, фінансовий і державний сектори) з 2001 р. Це комерційно незалежний проект C і C++ програмістів, технічних радників і розробників мультиплатформових систем управління базами даних, заснований на вихідному коді, випущеному компанією Borland 25 липня 2000 року у вигляді вільної версії Interbase 6.0.
Firebird є сервером баз даних. Один сервер Firebird може обробляти кілька сотень незалежних баз даних, кожну з безліччю користувальницьких сполук. Він є повністю вільним від ліцензійних відрахувань навіть для комерційного використання.
Серед недоліків можна відмітити відсутність кешу результатів запитів, повнотекстових індексів.
Основні характеристики СУБД Firebird наведено нижче. Серед них відповідність вимогам ACID: Firebird зроблений спеціально, щоб задовольняти вимогам атомарності, цілісності, ізоляції та надійності транзакцій ("Atomicity, Consistency, Isolation and Durability"). [4]
Також перевагою є версійна архітектура: Основна особливість Firebird версійна архітектура, що дозволяє серверу обробляти різні версії одних і тих же записів в будь-який час таким чином, що кожна транзакція бачить свою версію даних, не заважаючи сусіднім ("читаючі транзакції не блокують пишучі, а пишучі не блокують читаючі"). Це дозволяє використовувати одночасно OLTP і OLAP запити.
Іншою важливою перевагою є збережені процедури, використовуючи мову PSQL (процедурний SQL) Firebird, можливо створювати складні процедури для обробки даних на стороні сервера. Для генерації звітів особливо зручні збережені процедури з можливістю вибірки, що повертають дані у вигляді набору записів. Такі процедури можна використовувати в запитах так само, як і звичайні таблиці.
СУБД може містити збережені процедури і тригери, які можуть генерувати події, на які може підписатися клієнт. Після успішного завершення транзакції (COMMIT) він буде сповіщений про минулі події та їх кількість.
Ідея генераторів (послідовностей) робить можливою просту реалізацію автоінкрементних полів, і не тільки їх. Генератори є 64-бітними збереженими в базі даних лічильниками, які працюють незалежно від транзакцій. Вони можуть бути використані для різних цілей, таких як генерація первинних ключів, управління тривалими запитами в сусідніх транзакціях, і тому подібне.
Бази даних тільки для читання дозволяють поширювати бази даних, наприклад, на CD-ROM. Особливо спрощує розповсюдження даних їх використання в комбінації з вбудованої версією сервера Firebird (Firebird Embedded).
Наступною перевагою цієї СУБД є повний контроль за транзакціями: Один клієнтський додаток може виконувати безліч одночасних транзакцій. У різних транзакціях можуть бути використані різні рівні ізоляції. Протокол двофазного підтвердження транзакцій забезпечує гарантовану стійкість при роботі з декількома базами даних. Так само доступні оптимістичне блокування даних та точки збереження транзакцій.
Іншим плюсом є резервне копіювання на льоту. Для резервного копіювання немає потреби зупиняти сервер. Процес резервного копіювання зберігає стан бази даних на момент свого старту, не заважаючи при цьому роботі з базою. Крім того, існує можливість створювати інкрементні резервні копії БД.
Також важливим моментом є тригери. Для кожної таблиці можливе призначення кількох тригерів, що спрацьовують до або після вставки, оновлення та видалення записів. Для тригерів використовується мова PSQL, дозволяючи вносити початкові значення, перевіряти цілісність даних, викликати виключення, і так далі. В Firebird 1.5 з'явилися універсальні тригери, які дозволяють в одному тригері обробляти вставки, оновлення та видалення записів таблиці.
Зовнішні функції бібліотеки з UDF (User Defined Function) можуть бути написані будь-якою мовою і легко підключені до сервера у вигляді DLL/SO, дозволяючи розширювати можливості сервера "зсередини".
Декларативний опис посилальної цілісності забезпечує несуперечність і цілісність багаторівневих відносин "master-detail" між таблицями.
Firebird підтримує безліч міжнародних наборів символів (включаючи Unicode) з безліччю варіантів сортування.
Також у цьому розділі треба згадати і про такий інструмент як SQL. SQL (Structured query language) -- декларативна мова програмування для взаємодії користувача з базами даних, що застосовується для формування запитів, оновлення і керування реляційними БД, створення схеми бази даних і її модифікації, системи контролю за доступом до бази даних. Сам по собі SQL не є ні системою керування базами даних, ні окремим програмним продуктом. Не бувши мовою програмування в тому розумінні, як C або Pascal, SQL може формувати інтерактивні запити або, бувши вбудованою в прикладні програми, виступати в якості інструкцій для керування даними. Стандарт SQL, крім того, вміщує функції для визначення зміни, перевірки і захисту даних.
SQL -- це діалогова мова програмування для здійснення запиту і внесення змін до бази даних, а також управління базами даних. Багато баз даних підтримує SQL з розширеннями до стандартної мови. Ядро SQL формує командна мова, яка дозволяє здійснювати пошук, вставку, оновлення, і вилучення даних, використовуючи систему управління і адміністративні функції. SQL також включає CLI (Call Level Interface) для доступу і управління базами даних дистанційно.
Перша версія SQL була розроблена на початку 1970-х років у IBM. Ця версія мала назву SEQUEL і була призначена для обробки й пошуку даних, що містилися в реляційній базі даних IBM, System R . Мова SQL пізніше була стандартизована Американськими Держстандартами (ANSI) в 1986. Спочатку SQL розроблялась як мова запитів і управління даними, пізніші модифікації SQL створено продавцями систем управління базами даних, які додали процедурні конструкції, control-of-flowкоманд і розширення мов.
SQL призначений для виконання запитів. Крім того, в SQL входить синтаксис для оновлення, вставки і знищення даних. Цей синтаксис разом з командами поновлення формує мова управління даними (DML):
- SELECT -- отримує дані з таблиці БД;
- UPDATE -- оновлює дані в таблиці БД;
- DELETE -- знищує дані в таблиці БД;
- INSERT INTO -- вставляє нові дані в таблицю БД.
DDL є частиною SQL, яка управляє створенням і видаленням таблиць в БД, крім того, за допомогою DDL ми можемо призначати індекси (ключові слова), налагоджувати взаємозв'язки між таблицями і накладати обмеження на таблиці БД [5].
Найважливішими командами DDL є наступні команди:
- CREATE TABLE -- створення нової таблиці;
- ALTER TABLE -- зміна існуючої таблиці;
- DROP TABLE -- видалення таблиці;
- CREATE INDEX -- створення індексу (ключового слова для полегшення пошуку);
- DROP INDEX -- видалення індексу.
- 2.3 Розробка баз даних за допомогою Firebird 2.5
інтерфейс редагування інформація база
Процес розробки бази даних складається з таких кроків:
- визначення мети створення бази даних;
- пошук і впорядкування потрібних відомостей;
- розділення даних на таблиці;
- перетворення елементів даних на стовпці;
- визначення первинних ключів;
- створення зв'язків між таблицями;
- удосконалення структури;
- застосування правил нормалізації .
Угрупування одних і тих же даних в таблиці може проводитися різними способами. Атрибути і відносини повинні групуватися за реляційними принципами, тобто має повністю мінімізуватися дублювання даних, а також спрощуватися процедура їх обробки з подальшим оновленням. Одним з першорядних завдань при проектуванні баз даних виступає усунення надмірності, а воно досягається за допомогою нормалізації.
Нормалізація баз даних являє собою формальний апарат обмежень на створення таблиць, що дозволяє усунути дублювання, з обов'язковим забезпеченням несуперечності інформації, що зберігається, зменшуючи трудовитрати, пов'язані з веденням та обслуговуванням бази даних. Операція нормалізації полягає в розкладанні вихідних таблиць бази даних на більш прості.
На кожному ступені даного процесу таблиці обов'язково приводяться до нормальних форм. Кожна ступінь нормалізації характеризується певним набором обмежень, яким і повинні відповідати всі таблиці. Таким чином, здійснюється видалення з таблиць неключової інформації, яка є надлишковою.
Нормалізація баз даних ґрунтується на понятті функціональної залежності між атрибутами. Прийнято вважати, що один атрибут залежить від іншого, якщо в кожен момент часу певному значенню другого атрибута відповідає трохи більше, ніж одне значення першого.
Нормалізація баз даних - це загальне поняття, однак, його прийнято поділяти на кілька нормальних форм, про які й буде сказано далі.
Будь-який інформаційний об'єкт вважається відповідним першій нормальній формі, коли значення кожного його атрибута є єдиним. Якщо у якогось атрибуту є повторюване значення, то не можна вважати, що об'єкт належить першій нормальній формі. Виходить, що можна створити ще одну сутність, тобто інформаційний об'єкт.
Прийнято вважати, що інформаційний об'єкт належить до другої нормальної формі, коли він вже перебуває в першій нормальній формі і кожен з його атрибутів, який не перебуває в потенційному ключі, повністю залежить, у функціональному плані, від кожного з потенційних ключів.
Прийнято вважати, що інформаційний об'єкт належить до третьої нормальної форми, якщо він вже перебуває в другій нормальній формі і в ньому не присутня жодна з транзитивних залежностей неключових об'єктів від ключів. Під транзитивною залежністю прийнято розуміти очевидну залежність між полями.
Нормалізація бази даних ставить перед розробником основну мету, яка полягає в приведенні всіх відносин до третьої нормальної форми. Тільки так у подальшому можна буде створити ефективну інформаційну систему.
Варто сформулювати набір правил, яких слід притримуватися в роботі з нормалізації. У першу чергу варто виключати повторювані групи. Необхідно формувати окрему таблицю, що зберігає кожен набір пов'язаних атрибутів, в якій і створити окремий ключ. Далі обов'язково виключити надлишкові дані. У випадках, коли залежність атрибуту спостерігається тільки від частини ключа, то його необхідно виставити в окрему таблицю. Третє правило полягає в обов'язковому виключенні стовпців, що не залежать від ключа. Атрибути слід помістити в ізольовану таблицю, якщо вони не роблять належного впливу на ключ. Обов'язково слід ізолювати незалежні множинні відносини. У даному випадку мова йде про те, що між кількома відносинами не проглядається конкретний зв'язок. І нарешті, варто ізолювати множинні відносини, пов'язані семантично. На цьому нормалізація БД завершується, після чого настає процес розробки.
- 2.4 Компоненти роботи з базами даних
Для роботи з базою даних доцільно обрати такі компоненти призначені для роботи з базами даних, як TIBdatabase, TIBTransaction, TDataSource, TIBTable та TIBQuery. При проектуванні програми для підключення бази даних доцільно встановити такі параметри для компонентів.
Для TIBdatabase1 властивість DatabaseName у вказати шлях до бази даних, властивість Connected встановити у True. Для TIBTransaction1 властивість Active у True. Для TDataSource3 властивість Dataset у IBQuery3. Для TIBQuery3 властивість Database у TIBdatabase1, Властивість SQL [6] залежно від потреб заповнити запитом мовою SQL, а властивість Active встановити у True.
Таким чином може бути спроектована та підключена база даних для початку проектування програми.
3 СПЕЦІАЛЬНА ЧАСТИНА
- 3.1 Програмна частина
- 3.1.1 Проектування бази даних та інтерфейсу програми
Для реалізації бази даних була обрана СУБД Firebird 2.5, в якій створено 24 таблиці.
Доцільно було поділити інформацію на різні таблиці, з яких 4 основні і 20 довідників. Схема взаємозв'язку таблиць представлена в додатку В.
Дані, що використовуються у таблиці багато разів, було доречно занести у так звані довідкові таблиці, що мають характерний префікс SPR_ у своїй назві, вони приведені на рисунках 3.1 3.20. Довідники, що поставляються заповненими:
- «Стать»;
- «Освіта»;
- «Групи інвалідності»;
- «Тип програми реабілітації»;
- «Види обмежень»;
- «Ступені обмежень»;
- «Заходи реабілітації»;
- «Реабілітаційний потенціал»;
- «Мета реабілітації».
Довідники, що можуть поповнюватися в ході виконання програми:
- «Діагнози»;
- «Супутні захворювання»;
- «Професії»;
- «Терміни проведення реабілітаційних заходів»;
- «Обсяг проведення реабілітаційних заходів»;
- «Місце проведення реабілітаційних заходів»;
- «Працівники закладу»;
- «Райони»;
- «Області»;
- «Населені пункти»;
- «Райони населеного пункту».
На рисунках позначка «ПК» позначає, що поле є первинним ключем, позначка «ВК», що поле є зовнішнім ключем.
Рисунок 3.1 - Структура таблиці статі SPR_SEX
Рисунок 3.2 - Структура таблиці ступенів освіти SPR_OSVITA
Рисунок 3.3 - Структура таблиці груп інвалідності SPR_GR_INV
Рисунок 3.4 - Структура таблиці типів ІПР SPR_PROG_SKL
Рисунок 3.5 - Структура таблиці видів обмежень SPR_VID_OBMEJ
Рисунок 3.6 - Структура таблиці супутніх захворювань SPR_STUP
Рисунок 3.7 - Структура таблиці реабілітаційних заходів SPR_ZAH
Рисунок 3.8 - Структура таблиці реабілітаційних потенціалів SPR_R_POTENCIAL
Рисунок 3.9 - Структура таблиці цілей реабілітації SPR_META
Рисунок 3.10 - Структура таблиці діагнозів SPR_DIAGNOZ
Рисунок 3.11 - Структура таблиці супутніх захворювань SPR_MKH
Рисунок 3.12 - Структура таблиці професій SPR_PROF
Рисунок 3.13 - Структура таблиці термінів реабілітації SPR_TERMIN
Рисунок 3.14 - Структура таблиці обсягів реабілітацій SPR_OBSYAG
Рисунок 3.15 - Структура таблиці місць реабілітації SPR_MISC
Рисунок 3.16 - Структура таблиці працівників МСЕК SPR_SOTRUDNIKI
Рисунок 3.17 - Структура таблиці районів області SPR_RAJON_OBL
Рисунок 3.18 - Структура таблиці областей SPR_OBL
Рисунок 3.19 - Структура таблиці населених пунктів SPR_NAS_PUNKT
Рисунок 3.20 - Структура таблиці районів населеного пункту SPR_RAJON
Таблиця «Особиста картка пацієнта» містить такі поля
- ID_CHEL --- унікальний ідентифікатор;
- FIO -- ПІБ;
- DR -- дата народження;
- SEX -- стать;
- OBL -- область;
- R_OBL -- район області;
- PUNKT -- населений пункт;
- R_PUNKT -- район населеного пункту;
- INDEX1 -- поштовий індекс;
- STREET -- вулиця;
- TEL -- номер телефону;
- OSVITA -- освіта;
- GR_INV -- група інвалідності;
- ID_PROF -- професія;
- WORK -- ким працює.
Таблиця «Обмеження» містить такі поля
- ID_IPR -- ідентифікатор ІПР, до якої відноситься обмеження;
- ID_VID_OBMEJ -- ідентифікатор виду обмеження, до якого відноситься запис;
- ID_STUP -- ідентифікатор ступеню, до якого відноситься дане обмеження.
Таблиця «ІПР» містить такі поля:
- ID_IPR -- унікальний ідентифікатор ІПР;
- ID_CHEL -- ідентифікатор пацієнта, для якого складена дана програма;
- N_PROG -- номер програми реабілітації;
- DAT_ZAP -- дата заповнення ІПР;
- MSEK_N -- назва та номер МСЕК;
- ID_PROG_SKL -- програма складена;
- TRIV_INV -- тривалість перебування на інвалідності;
- ID_DIAGNOZ -- діагноз;
- SUPUT_ZAHV -- супутні захворювання;
- ID_R_POTENCIAL -- реабілітаційний потенціал;
- META -- мета реабілітації;
- DAT_SPIVB -- Дата проведення співбесіди;
- DAT_KONTR -- Дата контролю за виконанням ІПР;
- SOTRUDNIK -- Працівник, що уклав ІПР.
Таблиця «Реабілітація» містить такі поля
- ID_IPR -- ідентифікатор ІПР, до якої відносяться реабілітаційні заходи;
- ID_ZAH -- реабілітаційний захід;
- ID_TERMIN -- термін виконання реабілітації;
- ID_OBSYAG -- обсяг виконання реабілітації;
- ID_MISCE -- місце виконання реабілітації.
Схема зв`язку таблиць приведена у додатку В.
Таким чином ми маємо таблицю, що містить перелік персональних даних про осіб-інвалідів OS_KARTA, що зображено на рисунку 3.21, дані про обмеження життєдіяльності містяться у таблиці OBMEJ, що зображено на рисунку 3.22, дані про індивідуальну програму реабілітації зображено у таблиці IPR, що відображено на рисунку 3.23 та дані про реабілітаційні заходи містяться у таблиці REABIL, що відображено на рисунку 3.24.
Рисунок 3.21- Структура таблиці OS_KARTA
Рисунок 3.22 - Структура таблиці OBMEJ
Рисунок 3.23 - Структура таблиці IPR
Рисунок 3.24 - Структура таблиці REABIL
Поля таблиць, які є індивідуальними ідентифікаторами, не відображаються в ході виконання програми, так як служать для зв'язування таблиць за ключовими полями та не несуть змістовного значення для користувача.
Для підключення бази даних до програми використано SQL-запити, приклад якого приведено в лістингу 3.1
Лістинг 3.1 - Властивість SQL компоненту TIBQuery
SELECT os.id_chel, os.fio, os.dr, sex.sex as sex1, obl.obl as obl1, osv.osvita as osvita1, os.work, os.street, os.index1, os.tel, ro.rajon_obl as r_obl1, np.nas_punkt as punkt1, r.rajon as r_punkt1, gr.gr_inv as gr_inv1, prof.prof as id_prof1 From Os_karta os
INNER JOIN Spr_sex sex ON os.sex = sex.id_sex
INNER JOIN Spr_GR_INV gr ON os.gr_inv = gr.id_gr_inv
INNER JOIN Spr_osvita osv ON os.osvita = osv.id_osvita
INNER JOIN Spr_obl obl ON os.obl = obl.id_obl
INNER JOIN Spr_rajon_obl ro ON os.r_obl = ro.id_rajon_obl
INNER JOIN Spr_rajon r ON os.r_punkt = r.id_rajon
INNER JOIN Spr_nas_punkt np ON os.punkt = np.id_nas_punkt
INNER JOIN Spr_prof prof ON os.id_prof = prof.id_prof
Зручно не використовувати один шлях доступу до таблиць бази даних, а мати для цього файл налаштувань, який дозволяє вказати з програми шлях доступу до бази даних. Такий підхід дає можливість розташовувати дані в будь-якому місці, не перекомпільовуючи при цьому програму. Приклад вхідних даних міститься у додатку А.
Згідно з постановкою задачі доцільно розробити інтерфейс програми, який би складався з форм, описаних нижче.
До складу інтерфейсу повинно входити 15 форм, список та призначення яких приведено у таблиці 3.1.
Таблиця 3.1 - Призначення форм
Назва форми |
Призначення форми |
|
AboutForm |
Відображення інформації про програму |
|
DataModule1 |
Розташування не візуальних компонентів |
|
FormAddDov, FormAddDovMKH |
Додавання та редагування даних у довідниках |
|
FormAddIPR |
Додавання та редагування інформації про індивідуальну програму реабілітації |
|
FormAddPacient |
Додавання даних про пацієнта |
|
Назва форми |
Призначення форми |
|
FormAvtoriz |
Авторизація |
|
FormDovidnik |
Перегляд довідників |
|
FormIPRView |
Перегляд ІПР |
|
FormNastr |
Вибір шляху до БД |
|
FormReabil |
Форма реабілітаційних заходів ІПР |
|
FormRedPac |
Редагування інформації про пацієнта |
|
MainForm |
Основна форма |
|
FormRedPas |
Форма зміни пароля |
|
FormPath |
Налаштування для збереження довідок |
Основна форма Main зображена на рисунку 3.1. Вона містить такі компоненти [7] як:
- TMainMenu -- для забезпечення відображення головного меню уверху форми для переходів на інші форми;
- TStatusBar -- для відображення поточної інформації системи у нижній частині вікна;
- TToolBar -- для відображення кнопок під головним меню для швидкого доступу до деяких функцій;
- TDBNavigator -- для переходу по таблиці;
- TEdit -- для вводу інформації;
- TImageList -- для збереження зображень у форматі *.bmp для іконок;
- TDateTimePicker -- для вибору коректної дати;
- TBitBtn -- кнопка із іконкою для виконання дій;
- TGroupBox -- для візуально відділення інформації;
- TPopupMenu -- для спливаючого меню, що викликається правою кнопкою миші;
- TDBGrid -- для відображення таблиці із бази даних;
- TImage -- для розміщення зображень, зокрема фону форми;
- TXPManifest -- для придання формі стилю Windows XP;
- TLabel -- для розміщення пояснювального тексту;
- TComboBox -- для вибору значення зі списку;
- TPanel -- для розміщення та вирівнювання компонентів один відносно одного.
Рисунок 3.25 - Основна форма Main
Для вирівнювання вікна при появі його властивість Position була встановлена у poScreenCenter, для того, щоб користувач не міг змінити розмір вікна, його властивість BorderStyle була встановлена у Single для відповідних форм. Також при розміщенні компонентів на формі властивість Align в залежності від потреб була встановлена у alBottom, alClient, alLeft , alRight чи alTop для компонентів.
Головне меню містить такі пункти меню:
- «Авторизація» -- має підпункти для виходу із програми та для реєстрації нового користувача;
- «Заповнити» -- має підпункти для виклику вікна заповнення даних про пацієнта та заповнення ІПР пацієнта;
- «Пошук» -- показує чи скриває панель пошуку;
- «Довідники» -- через підпункти викликає вікно перегляду для конкретного довідника;
- «Про програму» -- викликає вікно «Про програму»;
- «Конфігурація» -- викликає вікно конфігурації;
- «Вихід» -- закриває програму.
Компонент TPopupMenu призначений для виконання дій над записами та містить такі пункти:
- «Додати пацієнта»;
- «Додати ІПР»;
- «Редагувати»;
- «Видалити».
Для зручності невізуальні компоненти [8] було розміщено на спеціальній формі DataModule, яку зображено на рисунку 3.26.
Рисунок 3.26 - Форма з невізуальними компонентами DataModule
Форма додавання інформації [9] про пацієнта містить такі компоненти, як TImage, TGroupBox, TMainMenu, TLabel, TDateTimePicker, TEdit, TComboBoх.
Форма додавання інформації про ІПР містить такі компоненти як TLabel, TEdit, TDateTimePicker, TUpDown -- для завдання числового значення кліком по стрілкам, TGroupBox, TImage, TMainMenu, TDBListBox -- для відображення інформації із таблиці обмежень, TMemo -- для вводу ступеня обмеження, TSpeedButton -- кнопка-зображення для відкриття довідників, TComboBox, TDBNavigator.
Вибір реабілітаційних засобів, їх термінів, обсягу та місця проведення виконується на формі додавання інформації про реабілітаційні заходи, їх обсяги, терміни та місця проведення «Реабілітація», яка зображена на рисунку 3.29. Дана форма містить такі компоненти, як TTreeView -- призначений для відображення довідника реабілітації у вигляді дерева, TImage, TMainMenu, TComboBox, TLabel, TBitBtn, TSpeedButton.
Перегляд довідників виконується на формі FormDovidnik, в якій відкривається тільки той, що буде обрано у підменю «Довідники». Ця форма мітить такі компоненти як TPageControl -- для вибору вкладок, TDBGrid, TBitBtn.
Форма містить такі компоненти, як TMainMenu, TImage, TGroupBox, TLabel, TEdit.
Форма додавання до інших довідників, а саме: «Професії», «Терміни реабілітації», «Обсяги реабілітації», «Місця реабілітація», «Працівники», «Область», «Район області», «Населений пункт» та «Район населеного пункту». Вона містить такі ж самі компоненти, що й попередня і відрізняється лише тим, що містить тільки одне поле для заповнення.
Форма редагування інформації [10] про пацієнтів відображає дані про конкретного пацієнта, що занесені в таблицю, та дозволяє змінити їх. На формі містяться такі компоненти, як TMainMenu, TGroupBox, TLabel, TDateTimePicker, TImage, TComboBox, TEdit.
Форма перегляду інформації про ІПР містить такі компоненти, як TMainMenu, TPanel, TMemo, TDBGrid.
Форма авторизації дозволяє виконати вхід до програми. Вона містить такі компоненти, як TLabel, TEdit, TImage, TMainMenu.
Форма зміни пароля має такі компоненти, як TImage, TLabel, TGroupBox, TEdit, TMainMenu.
Форма інформації про програму містить інформацію про програму. На формі містяться такі компоненти, як TLabel, TImage.
Форма конфігурації містить інформацію про шлях до БД. Вона містить такі компоненти, як TLabel, TButton, TImage,TEdit та TOpenDialog -- для відкриття діалогу вибору шляху.
Форма конфігурації містить інформацію про шлях для збереження довідок ІПР. Вона містить такі компоненти, як TLabel, TButton, TBitBtn, TEdit та TOpenDialog -- для відкриття діалогу вибору шляху, TCheckBox -- для відмічання прапорцем настройки.
3.1.2 Опис вхідних та вихідних даних
Вхідними даними у даній програмі є інформація для чотирьох основних таблиць: «Особиста картка пацієнта», «Обмеження», «ІПР» та «Реабілітація», яку користувач вводить з клавіатури, а також дані, якими заповнюються довідники.
Приклад вхідних даних приведено у додатку А.
Вихідними даними є документ сформований в Excel-документі, фрагмент шаблону документу ІПР зображено на рисунку 3.40.
Рисунок 3.40 - Фрагмент шаблону документу
3.1.3 Контроль коректності вхідних та вихідних даних
Контролю коректності даних, необхідно приділяти чималу увагу, оскільки необроблені помилки, приводять до критичних ситуацій при роботі в роботі програмі.
Тестування програмного забезпечення -- це процес, що використовується для виміру якості розроблюваного програмного забезпечення. Зазвичай воно проводиться протягом всієї розробки та супроводу на різних рівнях. Рівень тестування визначає "над чим" виробляються тести: над окремим модулем, групою модулів або системою, в цілому. При цьому жоден з рівнів тестування не може вважатися пріоритетним. Важливі всі рівні тестування, незалежно від використовуваних моделей і методологій.
Модульне тестування (Unit testing) дозволяє перевірити функціонування окремо взятого елемента системи. Що вважати елементом модулем системи визначається контекстом. Найбільш повно даний вид тестів описаний в стандарті IEEE 1008-87 "Standard for Software Unit Testing", задаючому інтегровану концепцію систематичного і документованого підходу до модульного тестування.
Інтеграційне тестування (Integration testing) є процесом перевірки взаємодії між програмними компонентами / модулями. Класичні стратегії інтеграційного тестування - "зверху-вниз" і "знизу-вгору" - використовуються для традиційних, ієрархічно структурованих систем і їх складно застосовувати, наприклад, до тестування слабозв'язаних систем. Інтеграційне тестування - постійно проводиться діяльність, що передбачає роботу на досить високому рівні абстракції. Найбільш успішна практика інтеграційного тестування базується на інкрементальних підході, що дозволяє уникнути проблем проведення разових тестів, пов'язаних з тестуванням результатів чергового тривалого етапу робіт, коли кількість виявлених дефектів призводить до серйозної переробки коду (традиційно, негативний досвід випуску та тестування тільки великих релізів називають "big bang").
Системне тестування (System testing) охоплює цілком всю систему. Більшість функціональних збоїв повинна бути ідентифікована ще на рівні модульних та інтеграційних тестів. У свою чергу, системне тестування, зазвичай фокусується на нефункціональних вимогах - безпеки, продуктивності, точності, надійності т.п.
Існує кілька методів тестування:
- тестування методом «чорної скриньки» (Black box testing);
- тестування методом «білого ящика» (White box);
- тестування методом «сірого ящика» (Grey box).
У термінології професіоналів тестування (програмного і деякого апаратного забезпечення) фрази "тестування білого ящика" і "тестування чорного ящика" ставляться до того, чи має розробник тестів і тестувальник доступ до вихідного коду тестованого ПО, або ж тестування виконується через інтерфейс користувача або прикладної програмний інтерфейс, наданий тестуємим модулем.
При тестуванні білого ящика (англ. white-box testing, також кажуть - прозорого ящика), розробник тесту має доступ до вихідного коду і може писати код, який пов'язаний з бібліотеками тестованого ПЗ. Це типово для юніт-тестування, при якому тестуються тільки окремі частини системи. Воно забезпечує те, що компоненти конструкції - працездатні і стійкі, до певної міри.
При тестуванні чорного ящика (англ. black-box testing), тестувальник має доступ до ПЗ тільки через ті ж інтерфейси, що і замовник або користувач, або через зовнішні інтерфейси, що дозволяють іншого комп'ютера або іншому процесу підключитися до системи для тестування. Наприклад, тестуючий модуль може віртуально натискати клавіші або кнопки миші в програмі, що тестується за допомогою механізму взаємодії процесів, з упевненістю в тому, чи все йде правильно, що ці події викликають той же відгук, що й реальні натискання клавіш і кнопок миші. Як правило, тестування чорного ящика ведеться з використанням специфікацій або інших документів, що описують вимоги до системи.
Що стосується самих помилок, то вони можуть бути синтаксичними та логічними. Перші легко визначаються, так як компілятор вказує на них, та легко усуваються, якщо проаналізувати текст помилки. Другі ж потребують значної уваги. Як правило вони виражаються не появою повідомлень, а роботою програми, яка на практиці не відповідає очікуванням. В такому разі може допомогти покроковий запуск програми, трасування, відстеження значень змінних і тому подібне.
Для забезпечення надійності програми потрібно передбачити дії у разі невдалої спроби підключитися до бази даних, невірно введених або не введених даних. Прикладом логічної помилки служить, наприклад, випадок, коли програма не може підключитися до бази даних через те, що база даних відсутня у місці, де прописана програма. Цю помилку можна вирішити передбачивши, щоб програма спочатку перевіряла наявність в базі даних файлу, а потім з'являлося вікно, в якому можна обрати новий шлях до бази даних.
- 3.1.4 Опис структури та складових системи
Система ділиться на підсистему адміністрування та підсистему користувача.
Спочатку користувач повинен ввести пароль на формі авторизації, після чого йому буде відображена основна форма. З основної форми через пункти головного меню викликаються всі інші форми для забезпечення виконання таких функцій, як:
- додавання даних у систему;
- редагування;
- видалення;
- пошук, сортування, фільтрація;
- формування документу.
Для користувача, що авторизувався як адміністратор, доступні всі функції, для звичайного, що не вводить паролю, доступні лише деякі функції. Схема взаємодії складових частин програми приведена на рисунку 3.41, 3.42.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Рисунок 3.42 - Продовження схеми взаємодії складових частин програми
- 3.2 Опис модулів програми
Програма містить 15 модулів, перелік обробників подій приведено у таблиці 3.2. Основними подіями є обробка події натискання на кнопку, зміни вмісту поля та активація форми.
Таблиця 3.2 - Вміст модулів програми
Назва |
Перелік обробників подій |
|
Main |
m_exitClick, m_aboutClick, tb_view_iprClick, m_add_iprClick, m_zmin_korClick, m_poiskClick, FormCreate, m_add_pacClick, pop_delClick, tb_excelClick, m_zmin_korClick, DBGrid_InfTitleClick, BitBtn_filtrClick, pop_add_iprClick, pop_add_pacClick, m_konfClick, tb_add_pacClick, m_diagnozClick, m_mkhClick, m_profClick, m_terminClick, m_obClick, m_miscClick, m_pracClick, pop_redClick, BitBtn_cancelClick, c_sexChange, m_r_oblClick, m_oblClick, m_nas_punktClick, m_r_punktClick, c_grChange, c_osvChange, c_oblChange, fio |
|
About |
-- |
|
AddDov |
m_cancelClick, m_ addClick, FormActivate |
|
AddDovMKH |
m_cancelClick, m_addClick, FormActivate |
|
Назва |
Перелік обробників подій |
|
AddPacient |
m_exitClick, FormShow, m_add_pacClick, FormCreate, c_sexChange, c_osvChange, c_grChange, c_profChange, c_oblChange, c_r_oblChange, c_nas_punktChange, c_r_nas_punktChange, m_dd_iprClick, SpeedButton_profClick, SpeedButton_oblClick, SpeedButton_r_oblClick, SpeedButton_punktClick, SpeedButton_r_punktClick |
|
Avtoriz |
m_exitClick, m_enterClick, RGClick, FormCreate |
|
DataModule |
DataModuleCreate |
|
Dob_IPR |
m_exitClick, m_reabilClick, FormCreate, DBNavigator1Click, Memo3KeyPress..Memo16KeyPress, m_addClick, s_zahChange pr_sklChange, r_potencialChange, diagnozChange, c_pracChange, metaChange, sp_diagnozClick, sp_mkhClick, sp_pracClick |
|
Dovidnik |
FormClose, BitBtn_add_mClick, BitBtn_del_mClick, BitBtn_addClick, BitBtn_delClick, BitBtn_red_mClick, BitBtn_redClick |
|
IPRView |
m_exitClick, m_redClick, FormActivate, m_obmejClick, m_reabilClick, m_excelClick |
|
Nastr |
B_obzorClick |
|
PathEx |
FormShow, zberejClick, obzorClick |
|
Reabil |
m_exitClick, FormCreate, TreeViewChange, m_addClick, BitBtnAddClick, c_obmChange, c_terminChange, miscChange, B_obClick, B_tClick, B_mClick, c_obmDropDown, TreeViewClick |
|
RedPac |
m_exitClick, FormActivate, m_red_pacClick, SpeedButton_profClick, SpeedButton_oblClick, SpeedButton_r_oblClick, SpeedButton_punktClick, SpeedButton_r_punktClick |
|
AddPas |
m_exitClick, m_enterClick |
Форма Main призначена для відображення таблиці пацієнтів, а також доступу до модифікації таблиці [11] та додавання ІПР. Більш детально призначення обробників подій модулів головної форми Main описано в таблиці 3.3.
Таблиця 3.3 - Призначення обробників подій модулів форми Main
Назва |
Призначення |
|
m_exitClick |
Вихід із програми |
|
m_aboutClick |
Виклик форми «Про програму» |
|
tb_view_iprClick |
Виклик форми перегляду ІПР |
|
m_add_iprClick, pop_add_iprClick |
Виклик форми додавання ІПР |
|
m_zmin_korClick |
Виклик форми зміни пароля |
|
m_poiskClick |
Показ чи приховування панелі пошуку |
|
FormCreate |
Підготовка компонентів до відображення |
|
m_add_pacClick, pop_add_pacClick, tb_add_pacClick |
Виклик форми додавання пацієнта |
|
DBGrid_InfTitleClick |
Сортування даних за стовпцем |
|
BitBtn_filtrClick |
Фільтрування за датою |
|
m_konfClick |
Виклик форми конфігурації |
|
m_diagnozClick, m_mkhClick, m_profClick, m_terminClick, m_obClick, m_miscClick, m_r_oblClick, m_oblClick, m_nas_punktClick, m_r_punktClick, m_pracClick |
Виклик форми довідників |
|
BitBtn_cancelClick, |
Зброс фільтрування |
|
fioChange |
Пошук в таблиці за фамілією |
|
c_grChange, c_osvChange, c_oblChange, sexChange |
Фільтрація за полями з інформацією про групу інвалідності, область, стать та освіту |
|
pop_delClick, |
Видалення інформації про пацієнта |
|
pop_redClick, |
Редагування інформації про пацієнта |
Більш детально призначення обробників подій модулів форми AddDov описано в таблиці 3.4.
Таблиця 3.4 - Призначення обробників подій модулів форми AddDov
Назва |
Призначення |
|
m_addClic |
Виконання додавання даних |
|
m_cancelClick |
Вихід із програми |
|
FormActivate |
Активація форми |
Більш детально призначення обробників подій модулів форми AddDovMKH описано в таблиці 3.5.
Таблиця 3.5 - Призначення обробників подій модулів форми AddDovMKH
Назва |
Призначення |
|
m_addClick |
Виконання додавання даних |
|
m_cancelClick |
Вихід із програми |
|
FormActivate |
Активація форми |
Більш детально призначення обробників подій модулів форми AddPacient описано в таблиці 3.6.
Таблиця 3.6 - Призначення обробників подій модулів форми AddPacient
Назва |
Призначення |
|
m_exitClick |
Закрити програму |
|
FormShow |
Підготовка форми до відображення |
|
m_add_pacClick, |
Вставка інформації про пацієнта |
|
FormCreate |
Підготовка форми до відображення |
|
SpeedButton_profClick, SpeedButton_oblClick, SpeedButton_r_oblClick, SpeedButton_punktClick, SpeedButton_r_punktClick |
Відкриття довідника |
|
c_sexChange, c_osvChange, c_grChange, c_profChange, c_oblChange, c_r_oblChange, c_nas_punktChange, c_r_nas_punktChange |
Збереження ключу з довідника |
|
m_dd_iprClick |
Виклик форми додавання ІПР |
Більш детально призначення обробників подій модулів форми Avtoriz описано в таблиці 3.7.
Таблиця 3.7 - Призначення обробників подій модулів форми Avtoriz
Назва |
Призначення |
|
m_exitClick |
Закрити програму |
|
m_enterClick |
Війти в систему |
|
FormCreate |
Підготовка форми |
|
RGClick |
Відображення чи приховування поля паролю |
Більш детально призначення обробників подій модулів форми Addpas описано в таблиці 3.8.
Таблиця 3.8 - Призначення обробників подій модулю Redpas
Назва |
Призначення |
|
m_exitClick |
Закрити програму |
|
m_enterClick |
Війти в систему |
Більш детально призначення обробників подій модулів форми DataModule описано в таблиці 3.9.
Таблиця 3.9 - Призначення обробників подій форми DataModule
Назва |
Призначення |
|
DataModuleCreate |
Підключення компонентів |
Більш детально призначення обробників подій модулів форми Path описано в таблиці 3.10.
Таблиця 3.10 - Призначення обробників подій модулю PathEx
Назва |
Призначення |
|
FormShow |
Підготовка форми до відображення |
|
zberejClick |
Прийняття налаштування |
|
obzorClick |
Закрити вікно |
Більш детально призначення обробників подій модулів форми Dob_IPR [12] описано в таблиці 3.11.
Таблиця 3.11 - Призначення обробників подій форми Dob_IPR
Назва |
Призначення |
|
DataModuleCreate |
Підключення компонентів |
|
m_exitClick |
Закрити програму |
|
N2Click |
Виклик форми реабілітації |
|
FormCreate |
Підготовка форми |
Подобные документы
Теоретичні відомості про пакет ІЗВП Borland Delphi та СУБД MS Access, оцінка їх функціональних особливостей. Опис структури бази даних. Проектування інтерфейсу програми, опис її логічної структури та функцій. Контроль коректності вхідних, вихідних даних.
курсовая работа [4,5 M], добавлен 03.01.2014Розробка структури бази даних. ER-моделі предметної області. Проектування нормалізованих відношень. Розробка форм, запитів, звітів бази даних "Автосалон". Тестування роботи бази даних. Демонстрація коректної роботи форми "Додавання даних про покупців".
курсовая работа [4,0 M], добавлен 02.12.2014Опис вхідних та вихідних повідомлень, процедури перетворення даних. Розробка інфологічної моделі, інформаційні об’єкти та їх характеристика. Автоматизація даталогічного проектування. Опис структур таблиць бази даних на фізичному рівні, реалізація запитів.
курсовая работа [2,5 M], добавлен 02.01.2014Розробка бази даних "Автовокзал". Функціональні залежності між атрибутами. Ідентифікація атрибутів, які в реляційної моделі даних використовуються в якості первинних ключів реляційних відносин. Організація вибірки інформації з бази за допомогою запиту.
курсовая работа [35,6 K], добавлен 19.08.2012Проектування і реалізація реляційної бази даних для централізованого зберігання інформації з метою полегшення і систематизації даних замовлень клієнтів готельного комплексу. Розробка сценаріїв для створення бази даних і базових таблиць проекту.
курсовая работа [147,2 K], добавлен 02.06.2019Проектування бази даних предметної області "Магазин будівельних матеріалів". Аналіз сукупності вхідних і вихідних даних, шляхи удосконалення інформаційної системи обліку товару. Організація інформаційної бази, розробка логічної і фізичної моделі.
курсовая работа [559,2 K], добавлен 09.05.2016Розробка бази даних для обробки інформації про діяльність туристичного агентства. Визначення предметної області, вхідних та вихідних даних, їх організації. Генерація схеми бази даних. Реалізація функціональних вимог. Інструкція з експлуатації системи.
курсовая работа [5,3 M], добавлен 12.05.2015Специфікація вимог для кожного з двох користувачів. Концептуальне проектування бази даних. Визначення типів сутностей та зв’язків, доменів. Перетворення концептуальної моделі даних у логічну, визначення набору відношень, підтримки цілісності даних.
курсовая работа [55,1 K], добавлен 15.03.2015Розробка бази даних в середовищі Microsoft SQL Server 2008 для обліку послуг фітнес-клубу. Таблиці для баз даних, їх властивості. Аналіз сукупності вхідних і вихідних параметрів, опис інформаційної бази, розробка логічної і фізичної моделі даних в ІС.
курсовая работа [449,9 K], добавлен 09.05.2016Проектування бази даних, що реалізує звіти про графік робіт на об’єктах впродовж місяця. Графічне зображення нагромаджувачів даних. Побудова діаграм потоків даних і переходів станів, таблиць у вигляді двовимірного масиву, запитів. Створення бази даних.
курсовая работа [1,2 M], добавлен 29.02.2012