Модуль збору та обробки статистичної інформації в медичному закладі

Міністерство освіти і науки, молоді та спорту України Криворізький інститут Кременчуцького університету економіки, інформаційних технологій та управління Кафедра технічної кібернетики Спеціальність 7.5 020 102 «Комп'ютеризовані та робототехнічні системи»

ДИПЛОМНА РОБОТА Тема:

Модуль збору та обробки статистичної інформації в медичному закладі

Студентки групи КРС-07-з Зозулі Марини Олександрівни Керівник роботи ст. викл.

Супрунова Юлія Анатоліївна Кривий Ріг 2012

ЗАВДАННЯ

на дипломну роботу студентки Зозулі Марини Олександрівни

1. Тема роботи: Модуль збору та обробки статистичної інформації в медичному закладі

2. Термін здачі студентом закінченої роботи 03.05.12

3. Вхідні дані до роботи: Вимоги до кінцевого програмного продукту, вихідні масиви даних, програмна документація; матеріали наукових досліджень.

4. Зміст розрахунково-пояснювальної записки (перелік питань, що підлягають розробці): Постановка завдання; Інформаційні системи як сукупність засобів для збереження та обробки інформації; Командна оболонка та мова сценаріїв PowerShell; Дослідження технології COM та створення контролерів автоматизації MS Office; Опис функціональних можливостей та програмної реалізації проектованої системи; Економічне обґрунтування доцільності розробки програмного продукту; Охорона праці.

5. Перелік графічного матеріалу (з точними вказівками обов’язкових креслень)

1. Логіко-функціональна схема роботи системи;

2. Схема інформаційних потоків;

3. Приклади робочих вікон системи;

4. Схема роботи покажчика СОМ-інтерфейсу;

5. Схема взаємодії клієнта с внутрішнім сервером;

6. Схема взаємодії клієнта з сервером в різних процесах на одному комп’ютері;

7. Схема взаємодії клієнта з сервером на різних комп’ютерах;

8. Об'єктна модель MS Excel;

6. Консультанти з роботи, з вказівками розділів роботи, що належать до них

7. Дата видачі завдання 03.11.11 р.

Календарний план

АНОТАЦІЯ

Метою виконання дипломної роботи є автоматизація збору статистичних інформації в умовах неврологічного відділення Криворізького інституту професійних захворювань. Призначення системи — отримання лікарем-дослідником статистичного ряду згідно обраних показників.

Оболонка системи була реалізована засобами середовища програмування Delphi, модуль пошуку даних представлений у вигляді скрипту системи пакетної обробки PowerShell.

Розділів 7, схем та рисунків 22, таблиць 8, бібліографічних посилань 30, загальний обсяг — 103.

АННОТАЦИЯ

Целью выполнения дипломной работы является автоматизация сбора статистических информации в условиях неврологического отделения Криворожского института профессиональных заболеваний. Назначение системы — получение врачом-исследователем статистического ряда согласно выбранным показателям.

Оболочка системы была реализована средствами среды программирования Delphi, модуль поиска данных представлен в виде скрипта системы пакетной обработки PowerShell.

Разделов 7, схем и рисунков 22, таблиц 8, библиографических ссылок 30, общий объем — 103.

THE SUMMARY

The purpose of the diploma work is automation of information statistical collection in the conditions of neurological separation of the Kriviy Rih institute of professional diseases. Setting of the system is receipt by the doctor-researcher of statistical row in obedience to the chosen indexes.

The shell of the system was realized in Delphi program environment, the module of data retrieval is presented as the script of the PowerShell batch processing system.

Sections 7, circuits and figures 22, tables 8, bibliographic references 30, total amount — 103.

ЗМІСТ

• ВСТУП
• 1. ПОСТАНОВКА ЗАВДАННЯ
• 1.1 Найменування та галузь використання
• 1.2 Підстава для створення
• 1.3 Характеристика розробленого програмного забезпечення
• 1.4 Мета й призначення
• 1.5 Загальні вимоги до розробки
• 1.6 Джерела розробки
• 2. ІНФОРМАЦІЙНІ СИСТЕМИ ЯК СУКУПНІСТЬ ЗАСОБІВ ДЛЯ ЗБЕРЕЖЕННЯ ТА ОБРОБКИ ІНФОРМАЦІЇ
• 2.1 Класифікація інформаційних систем
• 2.2 Бази даних як складова частина інформаційної системи
• 3. КОМАНДНА ОБОЛОНКА ТА МОВА СЦЕНАРІЇВ POWERSHELL
• 3.1 Історія розвитку
• 3.2 Загальні відомості
• 3.3 Командлети
• 3.4 Конвейєр
• 3.5 Сценарії
• 4. ДОСЛІДЖЕННЯ ТЕХНОЛОГІЇ COM ТА СТВОРЕННЯ КОНТРОЛЕРІВ АВТОМАТИЗАЦІЇ MS OFFICE
• 4.1 Загальні принципи СОМ-технології
• 4.2 Розвиток СОМ-технологій
• 4.3 Склад СОМ-додатку
• 4.3.1 СОМ — інтерфейс
• 4.3.2 СОМ-сервери
• 4.3.3 СОМ-клієнти
• 4.4 Об'єктна модель MS Excel
• 4.5 Загальні принципи створення контролерів автоматизації MS Office
• 4.6. Принципи створення контролерів автоматизації MS Excel
• 4.6.1 Створення об'єкту Excel. Application, запуск і візуалізація вікна системи
• 4.6.2 Робота з аркушами робочої книги
• 4.6.3 Робота з комірками
• 4.6.4 Пошук і заміна тексту
• 4.6.5 Формули
• 5. ОПИС ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ ТА ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ПРОЕКТОВАНОЇ СИСТЕМИ
• 5.1 Функціональне призначення та технологічні особливості розробки
• 5.2 Розробка схеми інформаційних потоків та логіко-функціональної схеми роботи системи
• 5.3 Опис інтерфейсу користувача
• 5.4 Програмна реалізація системи
• 5.4.1 Реалізація інтерфейсної оболонки засобами Delphi
• 5.4.2 Здійснення пошуку та збору інформації засобами системи пакетної обробки PowerShell
• 6 ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ ПРОГРАМНОГО ПРОДУКТУ
• 7. ОХОРОНА ПРАЦІ
• 7.1 Аналіз небезпечних й шкідливих виробничих факторів
• 7.2 Заходи щодо нормалізації небезпечних і шкідливих факторів
• 7.3 Пожежна безпека
• ВИСНОВКИ

СПИСОК ЛІТЕРАТУРИ

ВСТУП

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

Розглянемо ті методи збереження та роботи з інформацією, які використовуються у сучасному медичному середовищі:

· системи корпоративного управління змістом (ECM system — enterprise content management system);

· прості бази даних;

· окремі файли;

· паперові носії.

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

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

Із схожою проблемою обробки даних можуть зіткнутися ті лікарі, що протягом останніх років самостійно, чи з тиску різних обставин, розпочали зберігання окремих видів медичної документації в електронному вигляді (найчастіше у форматі MS Word). Також важливим чинником може слугувати і той факт, що з такими документами простіше працювати і в якійсь мірі те, що це обов’язковий наказ міністерства охорони здоров’я.

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

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

Інтерфейс системи був створений за допомогою інструментального засобу прискореної розробки програмного забезпечення Delphi. Збір даних був реалізований за допомогою системи пакетної обробки PowerShell, що базується на основі технології .NET Framework. При цьому скрипт сценарію генерується та виконується автоматично на основі умов, заданих користувачем системи та під управлінням оболонки системи.

Windows PowerShell — розширюваний засіб автоматизації від Microsoft, що складається з оболонки з інтерфейсом командного рядка і супутньої мови сценаріїв. Windows PowerShell побудований на базі Microsoft .NET Framework і інтегрований з ним. Додатково PowerShell надає зручний доступ до COM, WMI і ADSI, рівно як і дозволяє виконувати звичайні команди командного рядка, щоб створити єдине оточення, в якому адміністратори змогли б виконувати різні завдання на локальних і видалених системах. Windows PowerShell також надає механізм вбудовування, завдяки якому виконувані компоненти PowerShell можуть бути вбудовані в інші додатки. Ці додатки потім можуть використовувати функціональність PowerShell для реалізації різних операцій, включаючи ті, що надаються через графічний інтерфейс.

1. ПОСТАНОВКА ЗАВДАННЯ

1.1 Найменування та галузь використання

Найменування розробки: модуль збору та обробки інформації в медичному закладі. Розроблена система створена згідно замовленню та пройшла практичну апробацію в умовах неврологічного відділення Криворізького інституту професійних захворювань.

1.2 Підстава для створення

Підставою для розробки є наказ № 55С-01 від 1 листопада 2011 р. по Криворізькому інституту КУЕІТУ.

Початок робіт: 03.11.11. Закінчення робіт: 03.05.12.

1.3 Характеристика розробленого програмного забезпечення

Інтерфейс системи був створений за допомогою інструментального засобу прискореної розробки програмного забезпечення Delphi з використанням пакетів альтернативних компонентів Development Express та AlphaControls 2010. У зв’язку з великим об'ємом вхідних даних та тривалим часом їх обробки пошук та збір даних був реалізований за допомогою системи пакетної обробки PowerShell, що базується на основі технології .NET Framework. При цьому скрипт сценарію генерується та виконується автоматично на основі умов, заданих користувачем системи та під управлінням оболонки системи.

Склад розробленої системи:

· medical_stat.exe — виконавчий файл оболонки системи;

· script. ps1 — файл скрипту PowerShell;

· DocConverterX. exe — зовнішній конвертор файлів формату *.doc в формат *.txt;

· baza. mdb — файл бази даних формату Microsoft Access, що зберігає допоміжну та проміжну інформацію;

· my. ini — файл налаштувань інтерфейсу системи.

Вхідна інформація системи — виписки з історії хвороби у вигляді файлів формату *.doc повинні зберігатися в каталозі doc, в тій же директорії, де знаходиться виконавчий файл.

1.4 Мета й призначення

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

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

Призначення системи — отримання лікарем-дослідником статистичного ряду згідно обраним показникам, які в подальшому можуть бути передані до обробки в пакети MS Excel та STATISTICA.

1.5 Загальні вимоги до розробки

Вимоги до програмного забезпечення:

· робота в середовищі операційних систем Windows XP/Vista/7;

· відсутність додаткових вимог до розміщення здійсненних файлів, простота та зрозумілість інтерфейсу користувача;

· додаткове програмне забезпечення: установка пакету MS Office, для операційних системи версій нижче Windows7 необхідна установка Windows Management Framework.

Мінімальні вимоги до апаратного забезпечення:

· IBM-Сумісний комп’ютер, не нижче Pentium III, RAM-512Mb, SVGA-800*600*16bit, вільний простір на жорсткому диску не менш 250 мБ.

1.6 Джерела розробки

Джерелами розробки дипломної роботи є:

· технічне завдання на реалізацію проекту;

· довідкова література;

· наукова література;

· технічна література;

· програмна документація.

2. ІНФОРМАЦІЙНІ СИСТЕМИ ЯК СУКУПНІСТЬ ЗАСОБІВ ДЛЯ ЗБЕРЕЖЕННЯ ТА ОБРОБКИ ІНФОРМАЦІЇ

Інформаційні системи (ІС) здавна знаходять (в тому чи іншому вигляді) досить широке застосування в життєдіяльності людства. Це пов’язано з тим, що для існування цивілізації необхідним є обмін інформацією — передача знань, як між окремими членами і колективами суспільства, так і між різними поколіннями.

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

Ще один приклад. На великому сучасному підприємстві в тому чи іншому вигляді повинна існувати інформаційна система. Для забезпечення якісного управління потрібно знати (можливо з різним ступенем оперативності) об'єм запасів тієї чи іншої сировини, скільки і якої вироблено продукції, скільки споживається електроенергії, який цех що виробляє і що потребує, та багато іншої інформації, яка стосується виробничих питань. Крім цього, профспілкам необхідні відомості про потреби співробітників у соціально-побутовій, медично-оздоровчій сферах, тощо. Для обробки всіх таких даних потрібні певні організаційні і технічні засоби, тобто ІС.

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

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

2.1 Класифікація інформаційних систем

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

· за призначенням (фактографічні, документальні та змішані);

· за мовами (замкнуті системи, системи з базовою мовою та змішані);

· за локалізацією (локальні та розподілені);

· за схемою додаткової обробки (постобробка та попередня обробка);

· за структурами даних (ієрархічні, мережаного типу, реляційні).

Критерії за якими діляться АІС:

1) за призначенням.

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

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

Змішані системи включають в себе в тих чи інших пропорціях риси обох вищеназваних варіантів. Переважну більшість сучасних систем для ПЕОМ слід віднести до категорії змішаних.

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

Дескрипторні або документальні АІС (ДАІС) історично були першими. Спочатку їх мовою була нічим не обмежена природна мова. Перші ДАІС були призначені для пошуку книг та документів у бібліотеках і великих сховищах, тому їх і почали називати документографічними.

Основним елементом інформаційного простору ДАІС була анотація або реферат книги, документа, явища чи об'єкта. Реферат повинен відображувати ті риси, які цікавлять користувача (як правило — людини). В ньому виділяються слова чи словосполучення, які в сукупності майже однозначно (в ідеалі точно) відповідають повному опису об'єкта, крім того, таких слів повинно бути відносно небагато. Їх називають ключовими словами або дескрипторами. Запит для ДАІС можна сформулювати у вигляді переліку дескрипторів, який на думку користувача характеризує потрібний реферат, а значить, і відповідний об'єкт. Алгоритм формування відповіді послідовно порівнює запит з кожним рефератом і вибирає такі, що пройшли порівняння. В таких системах запит називають пошуковим розпорядженням, а реферат — пошуковим образом.

2) За мовами (замкнуті системи, системи з базовою мовою та змішані);

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

Замкнуті системи самостійно забезпечують користувача всіма необхідними засобами як для локалізації даних, так і для їх постпошукової чи передпошукової обробки. Недоліком таких систем є те, що в них відсутні (або малоефективні) засоби для розробки надбудов — проблемно-орієнтованих комплексів.

Змішані системи передбачають наявність обох можливостей двох попередніх підходів і є найбільш поширеними на сьогодні.

3) за локалізацією (локальні та розподілені);

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

4) за схемою додаткової обробки (постобробка та попередня обробка);

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

5) за структурами даних (ієрархічні, мережного типу, реляційні).

Структури даних, що підтримуються в системі бази даних, — це важливий фактор, що впливає, як на виразову потужність, так і на ефективність функціонування. Для систем з ієрархічною структурою базовою структурою даних є дерево; як правило, вони мають найвищу ефективність функціонування, але виразові можливості їх відносно низькі. Системи з структурами даних типу мережа мають значно кращі виразові можливості, але дещо програють у ефективності функціонування, точніше, від користувача вимагається значно вищий рівень кваліфікації для ефективної експлуатації таких систем. В останні десятиріччя найбільшого розповсюдження (особливо для персональних ЕОМ) зазнали СУБД реляційного типу, для яких характерно щонайпростіша структура даних (плоский файл), але одночасно суттєво підвищений рівень мов маніпулювання даними, що максимально употужнює виразові можливості та знижує ефективність функціонування, тому для таких систем потрібні потужні комп’ютери, і вони значно чутливіші (порівняно з попередниками) до росту об'ємів даних.

2.2 Бази даних як складова частина інформаційної системи

Широке використання ЕОМ призвело до автоматизації обробки і використання величезної кількості інформації у різних галузях діяльності людини. Ще в початковий період розвитку автоматизованих інформаційних систем на основі ЕОМ першого і другого поколінь (кінець 50-х — початок 60-х років) різні організації почали накопичувати і зберігати дані про цікаві для них предметні області. Дані або були «зашиті» безпосередньо в програми, або програми мали змогу вибирати ці дані тільки з жорстко фіксованих (визначених усередині програми) пристроїв (носіїв інформації).

Другий етап розвитку АІС (60-ті - початок 70-х років) фахівці пов’язують із винаходом так званих файлових систем, що забезпечують незалежність розміщення наборів даних, у яких міститься інформація, від конкретних фізичних носіїв (так звана фізична незалежність даних і програм). Однак, кожна така програма була розрахована на роботу тільки з файлами визначеного формату, тобто зберігалася залежність програм від структури даних у файлах (логічна взаємозалежність програм і даних).

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

Користувачі АІС поступово усвідомлювали необхідність централізації управління даними і програмними додатками. Розуміння цієї необхідності приходило різними шляхами.

По-перше, користувачі АІС швидко виявили, що необхідну для ухвалення та прийняття рішення інформацію не дуже легко отримати. Щоб виконати запит на інформацію, необхідно було написати програму, здатну обробити кілька файлів інших програм, здійснюючи перетворення форматів, сортування та вибірку інформації. Відразу виникала проблема інтеграції різномовних програм, тому що файли програм, написаних однією мовою програмування (наприклад, РL/1 або FORTRAN), не могли безпосередньо використовуватися програмами, що були написані іншими мовами програмування. У таких умовах швидко отримати відповідь на заздалегідь непередбачений запит було практично неможливо. Дуже часто користувачі навіть були змушені відмовитися від запиту тому, що за час, протягом якого могла бути отримана відповідь, вона ставала непотрібною або тому, що цінність інформації не відповідала витратам на її отримання По-друге, використання АІС стримувалося отриманням найчастіше суперечливих відповідей на запити. Суперечливість виникала через надмірність даних, що призводила до того, що різні версії одного елемента даних у різних файлах могли знаходитися на різних стадіях оновлення. Складно було підтримувати несуперечливість, узгодженість і цілісність даних. Обчислювальні ресурси, такі, як пам’ять і машинний час, витрачалися нераціонально.

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

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

Усвідомлення значимості, даних, необхідності централізованого управління ними і прагнення розв’язати наведені вище проблеми розвитку АІС призвели до виникнення нової концепції спільного використання даних — концепції баз даних.

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

Насамперед проголосимо основні ідеї, що лежать в основі концепції бази даних:

1. Ізолювати будь-яку прикладну програму від впливу змін в інших програмах через спільні дані шляхом розмежування логічних записів, що використовуються прикладними програмами, від записів, що реально (фізично) запам’ятовуються на магнітних носіях.

2. Усунути надмірне дублювання даних.

3. Централізувати управління даними.

Отже, суть концепції баз даних полягає в інтегрованому збереженні й диференційованому використанні прикладними програмами всієї інформації про об'єкти предметної області, що представляють певний інтерес для організації. За таких умов, з одного боку, формати представлення даних описуються на логічному (зрозумілому) для кожної програми рівні, але, з іншого боку, усі інші дані, що зберігаються у базі даних і не мають ніякого відношення до певної прикладної програми, є для неї «прозорими». Це означає, що їхню присутність програма не відчуває.

Тобто всі дані розміщуються в єдиному сховищі. Користувачі АІС мають можливість звертатися до будь-яких даних, що їх цікавлять.

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

На жаль, у більшості означень поняття бази даних, що наводяться в літературі, не вказуються всі її суттєві ознаки. Також базу даних часто просто ототожнюють із будь-якою сукупністю файлів, що містять деякий набір відомостей про предметну область, яка має певний інтерес для організації. Зі сказаного зрозуміло, що сукупність файлів не обов’язково автоматично утворює базу даних. Щоб це відбувалося, файли повинні бути:

1. Взаємопов'язаними (так, що має бути забезпечена повна й узгоджена інформація про предметну область).

2. Інтегрованими (за умови мінімальної надмірності, необхідної для забезпечення взаємопов'язаності файлів).

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

4. Мати єдину централізовану програму управління, що забезпечує логічну незалежність програм від даних, що знаходяться у файлах.

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

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

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

Системою управління базами даних (СУБД) — називається сукупність мовних і програмних засобів, призначених для створення, управління і сумісного використання БД багатьма користувачами (програмами).

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

Бази даних є новим кроком у розвитку засобів обробки даних, що сприяв подальшому розширенню галузей застосування ЕОМ і сприяв кращому використанню даних у сфері управління й прийняття рішень.

Основними вимогами до баз даних та систем управління ними є:

1. Можливість представлення адекватних реальній предметній області структур даних (побудова адекватної інформаційної моделі предметної області).

2. Простота та малі витрати ресурсів на розвиток системи (швидка і дешева модифікація старих та розробка нових програмних додатків у рамках автоматизованої інформаційної системи).

3. Простота та оперативність доступу до даних, можливість пошуку інформації різними методами.

4. Можливість одночасного ефективного обслуговування великої кількості користувачів.

5. Можливість використання у розподілених обчислювальних мережах ЕОМ.

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

7. Забезпечення представлення даних користувачам (людям або програмам) у вигляді, зручному для їхнього подальшого застосування.

8. Забезпечення необхідної продуктивності розв’язування задач при обмежених витратах ресурсів ЕОМ.

9. Забезпечення захисту інформації у БД від збоїв і відмов у роботі технічних засобів та помилок користувачів.

Основними перевагами застосування БД та СУБД під час реалізації на їхній основі АІС є:

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

2. Усувається суперечливість даних. Вона може виникати, якщо ті самі дані, що використовуються різними програмами подаються декілька разів, і якщо у разі необхідності їхньої зміни не всі копії відновлені. Зрозуміло, що за відсутності над­мірності суперечливість неможлива принципово.

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

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

5. Спрощується підтримка цілісності (адекватності та узгодженості) даних.

6. Забезпечується можливість швидкого на дання даних на нестандартні (заздалегідь непередбачені) запити користувачів без додаткової розробки прикладних програм.

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

8. У разі централізованого управління базою даних спрощується стандартизація та уніфікація представлення даних у АІС.

Основними недоліками, з якими можуть зустрітися користувачі та розробники програмного забезпечення під час застосування БД та СУБД, є:

1. Додаткові витрати ресурсів (оперативної та зовнішньої пам’яті, загальної продуктивності ЕОМ) під час розміщення і роботи СУБД.

2. Додаткові витрати на встановлення і підтримку СУБД у робочому стані.

3. Необхідність кваліфікованого персоналу для централізованого управління базою даних (адміністрації бази даних).

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

Таким чином, використання БД та СУБД щодо створення великих потужних АІС, що включають велику кількість взаємопов'язаних програмних додатків, безперечно дає суттєві переваги порівняно з варіантами створення таких самих АІС на основі файлових систем.

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

3. КОМАНДНА ОБОЛОНКА ТА МОВА СЦЕНАРІЇВ POWERSHELL

Windows PowerShell — розширюваний засіб автоматизації від Microsoft, що складається з оболонки з інтерфейсом командного рядка і супутньої мови сценаріїв.

Windows PowerShell побудований на базі Microsoft .NET Framework і інтегрований з ним. Додатково PowerShell надає зручний доступ до COM, WMI і ADSI, рівно як і дозволяє виконувати звичайні команди командного рядка, щоб створити єдине оточення, в якому адміністратори змогли б виконувати різні завдання на локальних і видалених системах.

Ці адміністративні завдання звичайно виконуються за допомогою командлетів (у оригіналі cmdlets), які є спеціалізованими класами .NET. Користувач може комбінувати їх в скриптах (сценаріях), використовуючи різні конструкції, утиліти командного рядка і звернення до звичайних класів .NET, об'єктам WMI або COM. Крім того, можна використовувати різні сховища даних, такі як файлова система або реєстр Windows, які надаються PowerShell за допомогою постачальників.

Windows PowerShell також надає механізм вбудовування, завдяки якому виконувані компоненти PowerShell можуть бути вбудовані в інші додатки. Ці додатки потім можуть використовувати функціональність PowerShell для реалізації різних операцій, включаючи ті, що надаються через графічний інтерфейс. Цей підхід застосований в Microsoft Exchange Server 2007 для реалізації функціональності у вигляді командлетів PowerShell і графічних утиліт управління у вигляді оболонок PowerShell, які викликають необхідні командлети. Таким чином, графічний інтерфейс управління знаходиться поверх проміжного шару — PowerShell. Інші додатки Microsoft, включаючи Microsoft SQL Server 2008, System Center Operations Manager і System Center Data Protection Manager також надають доступ до своїх інтерфейсів управління через командлети PowerShell.

3.1 Історія розвитку

Кожна випущена версія MS-DOS і Microsoft Windows для персональних комп’ютерів містила утиліту, що надає інтерфейс командного рядка. Це були COMMAND.COM (у системах, заснованих на MS-DOS, включаючи Windows 9x) і cmd. exe (у системах сімейства Windows NT). Це були звичайні інтерпретатори командного рядка, що мали лише декілька базових команд. Для інших завдань були потрібні окремі консольні додатки, які викликалися з цих оболонок. Вони також мали мову сценаріїв (пакетні файли), за допомогою якої можна було автоматизувати різні завдання. Проте ці інтерпретатори не були призначені для повноцінної автоматизації — частково тому, що в них були відсутні еквіваленти багатьох операцій графічного інтерфейсу, а також із-за слабкої функціональності мови сценаріїв, що не дозволяла описувати достатньо складні алгоритми. У Windows Server 2003 ситуація була покращена, проте підтримка сценаріїв все ще вважалася недостатньою.

Microsoft намагалася вирішити деякі з цих недоліків за допомогою Windows Script Host, що вийшов в 1998 році у складі Windows 98, і утиліт для роботи з ним з командного рядка cscript.exe. Він інтегрується з Active Script і дозволяє писати сценарії на сумісних мовах, таких як JScript і VBScript, використовуючи API, що надається програмами через Component Object Model (COM). Проте у цього рішення свої недоліки. Windows Script Host не інтегрований з оболонкою, відсутня вбудована документація, і він швидко одержав репутацію вектора уразливості після декількох комп’ютерних вірусів, що широко розповсюдилися та використали уразливості в його моделі безпеки. Різні версії Windows також надають командні інтерпретатори спеціального призначення (такі як netsh. exe і WMIC) з своїми власними наборами команд. Вони не інтегровані з командною оболонкою і не дають можливостей для взаємодії.

У 2003 Microsoft почала розробку нової оболонки, званої Monad (також відомої як Microsoft Shell або MSH). Monad повинен був стати новою розширюваною оболонкою командного рядка, зі свіжим дизайном, який дозволяв би автоматизувати весь спектр адміністративних завдань. Microsoft опублікувала першу публічну версію бети Monad 17 червня 2005 року. Друга і третя версії були випущені 11 вересня 2005 і 10 січня 2006 відповідно. 25 квітня 2006 року було оголошено, що Monad перейменований в Windows PowerShell для позиціонування його як значної частини їх технологій управління. В цей же час була випущена версія Release Candidate 1 («кандидат на випуск»). Release Candidate 2 послідував 26 вересня 2006 року. Фінальна версія (Release to Web, RTW) була випущена 14 листопада 2006 року для Windows XP SP2 і Windows 2003. Фінальна версія для Windows Vista стала доступна тільки 30 січня 2007 року.

Останній CTP випуск Windows PowerShell версії 2.0 був випущений в грудні 2008 року. Фінальна версія другої версії PowerShell була випущена у складі систем Windows 7 і Windows Server 2008 R2 одночасно з їх випуском. Для решти систем (Windows XP, Windows Server 2003, Windows Vista, Windows 2008), друга версія PowerShell стала доступна у складі комплекту Windows Management Framework 27 жовтня 2009 року. Окрім Windows PowerShell другої версії, в цей комплект також входять WinRM версії 2.0 і BITS 4.0 (останній доступний тільки для Windows Vista і Windows 2008; у Windows 7 і Windows Server 2008 R2 він вбудований).

3.2 Загальні відомості

Команди, що виконуються в Windows PowerShell, можуть бути у формі командлетів, які є спеціалізованими класами .NET, створеними з метою надання функціональності в PowerShell у вигляді сценаріїв PowerShell (.PS1) або є звичайними виконуваними файлами. Якщо команда є виконуваним файлом, то PowerShell запускає її в окремому процесі; якщо це командлет, то він виконується усередині процесу PowerShell. PowerShell надає інтерфейс командного рядка, в якому можна вводити команди і відображати дані, що виводяться ними, в текстовому вигляді. Цей призначений для користувача інтерфейс, що базується на стандартному механізмі консолі Windows, надає механізм автозавершення команд, що настроюється, але не володіє можливістю підсвічування синтаксису, хоча при бажанні її можна забезпечити. У PowerShell також можна створювати псевдоніми (англ. alias) для командлетів, які при виклику перетворяться в оригінальні команди. Крім того, підтримуються позиційні та іменовані параметри для командлетів. При виконанні командлета робота по прив’язці значень аргументів до параметрів виконується самим PowerShell, але при виклику зовнішніх виконуваних файлів аргументи передаються їм для самостійного розбору.

Інше поняття, використовуване в PowerShell, — це конвейєр (англ. pipeline). Подібно до конвейєрів в UNIX, вони призначені для об'єднання декількох команд шляхом передачі вихідних даних однієї команди у вхідні дані другої команди, використовуючи оператор |. Але на відміну від аналога в UNIX, конвейєр PowerShell є повністю об'єктним, тобто дані між командлетами передаються у вигляді повноцінних об'єктів відповідних типів, а не як потік байтів. Коли дані передаються як об'єкти, елементи, що містяться в них, зберігають свою структуру і типи між командлетами, без необхідності використання якої або посимвольного розбору даних. Об'єкт також може містити деякі функції, призначені для роботи з даними. Вони також стають доступними для одержуючого їх командлета. Виведення останнього командлета в конвейєрі PowerShell автоматично передає на командлет Write-Host, який створює текстове представлення об'єктів і даних, що містяться в них, і виводить його на екран.

Оскільки всі об'єкти PowerShell є об'єктами .NET, вони містять метод. ToString (), що повертає текстове представлення даних об'єкту. PowerShell використовує цей метод для перетворення об'єкту в текст. Крім того, він дозволяє вказати правила форматування, так що текстове представлення об'єктів може бути настроєно. Проте, з метою підтримки сумісності, якщо в конвейєрі використовується зовнішній виконуваний файл, то він одержує текстовий потік, що представляє об'єкт, і не інтегрується з системою типів PowerShell.

Розширена система типів (англ. Extended Type System, ETS) PowerShell базується на системі типів .NET, але реалізує деякі доповнення. Наприклад, вона дозволяє створювати різні представлення об'єктів, відображаючи лише деякі з їх властивостей і методів, а також застосовувати спеціальне форматування і механізми сортування. Ці уявлення прив’язуються до оригінальних об'єктів за допомогою конфігураційних файлів у форматі XML.

3.3 Командлети

Командлети (англ. cmdlets) — це спеціалізовані команди PowerShell, які реалізують різну функціональність. Це вбудовані в PowerShell команди. Командлети іменуються за правилом Дієслово-Іменник, наприклад Get-ChildItem, завдяки чому їх призначення зрозуміло з назви. Командлети виводять результати у вигляді об'єктів або їх колекцій. Додатково, командлети можуть одержувати вхідні дані в такій же формі і, відповідно, використовуватися як одержувачі в конвейєрі. Хоча PowerShell дозволяє передавати по конвейєру масиви і інші колекції, командлети завжди обробляють об'єкти по черзі. Для колекції об'єктів обробник командлета викликається для кожного об'єкту в колекції по черзі.

Екземпляри об'єктів створюються в PowerShell і запускаються їм при виклику. Командлети успадковуються від Cmdlet або від PSCmdlet, причому останній використовується тоді, коли командлету необхідно взаємодіяти з виконуваною частиною PowerShell (англ. PowerShell runtime). У цих базових класах обумовлені деякі методи — BeginProcessing (), ProcessRecord () і EndProcessing (), як мінімум один з яких реалізація командлета повинна перезаписати для надання своєї функціональності. Кожного разу при запуску командлета ці методи викликаються PowerShell по черзі. Спочатку викликається BeginProcessing (), потім, якщо командлету передаються дані по конвейєру, ProcessRecord () для кожного елементу, і у самому кінці — EndProcessing (). Клас, що реалізовує Cmdlet, повинен мати один атрибут .NET — CmdletAttribute, в якому указуються дієслово і іменник, що становить ім'я командлета. Популярні дієслова (рекомендується використовувати тільки їх) представлені у вигляді переліку.

Реалізації командлетів можуть викликати будь-які доступні .NET API і можуть бути написані на будь-якій мові .NET. PowerShell також надає деякі додаткові API, такі як WriteObject (), які необхідні для доступу до специфічної для PowerShell функціональності, наприклад для виведення результуючих об'єктів в конвейєр. Командлети можуть використовувати API для доступу до даних безпосередньо або скористатися інфраструктурою постачальників PowerShell, які дозволяють звертатися до сховищ даних через унікальні шляхи. Сховища даних представляються через букви дисків і ієрархічну структуру усередині них (директорії). Windows PowerShell поставляється з постачальниками для файлової системи, реєстру Windows, сховища сертифікатів, а також для псевдонімів команд, змінних і функцій. Інші додатки можуть додавати свої командлети і постачальників для доступу до своїх сховищ даних.

У PowerShell 2.0 була додана можливість створення командлетів на самому PowerShell, без використання .NET мов.

3.4 Конвейєр

У PowerShell, як і в оболонках UNIX/Linux, присутній конвейєр. Цей конвейєр служить для передачі вихідних даних одного командлета у вхідні дані іншого командлета. Зокрема, користувач може вивести результати командлета Get-Process в командлет Sort-Object (наприклад, для сортування процесів по дескрипторах), потім в Where-Object, щоб відфільтрувати процеси, які, наприклад, займають менше 1 МБ сторінкової пам’яті, і врешті-решт передати результати в командлет Select-Object, щоб вибрати тільки перші 10 процесів (по кількості дескрипторів). Концепція конвейєра спочатку використовується в UNIX-подібних системах, концепція PowerShell відрізняється від даного.

У UNIX-подібних системах виведення однієї команди передається на наступний етап конвейєра в бінарній формі, тобто являє собою фактично потік даних. Приклад: dd if=/dev/zero bs=1M count=1M | bzip2 -z9 -c > ex. bz2, де потік «нулів» блоками по 1 МБ в кількості 1-го мільйона разів (з пристрою /dev/zero) командою dd (копіювання спеціальних файлів) передається на введення команди Bzip2, яка їх стискає максимально можливо (з погляду алгоритму стиснення bzip2, опціяz9) і результуючий потік передає на stdout (опціяс), який в свою чергу перенаправляється у файл ex. bz2. Результатом виконання таким щодо короткої команди стане створення архіву, усередині якого буде 1 Т потік нульових байтів. Сам процес створення такого архіву застосовує в даному випадку 2 послідовних конвейєра.

Реалізувати подібну функціональність і гнучкість в Windows засобами самої Windows довгий час було практично неможливим. Закласти даний пролом в середовищах Windows і був фактично покликаний PowerShell, що є якоюсь подібністю UNIX shell.

3.5 Сценарії

PowerShell включає мову сценаріїв з динамічними типами, на якому можна реалізовувати складні операції з використанням командлетів. Мова сценаріїв підтримує змінні, функції, конструкції розгалуження (if-then-else) цикли (while, do, for і foreach), структуровану обробку помилок і безліч інших можливостей, включаючи інтеграцію з .NET.

Змінні в PowerShell позначаються префіксом $ перед ім'ям; їм може бути привласнене будь-яке значення, включаючи виведення командлетів. Хоча сама мова не строго типізується, всередині змінні зберігаються з їх типами, які можуть бути базовими типами (англ. primitive types) або об'єктами. Рядки можуть бути поміщені в одиночні лапки або в подвійні лапки: при використанні подвійних лапок змінні, що містяться в рядку, будуть замінені їх значеннями. Відповідно до синтаксису змінних, якщо шлях до файлу поміщений у фігурні дужки з попереднім знаком долара (тобто $C:foo.txt), то це буде посиланням на вміст файлу. Все, що буде призначено такою змінною, буде записано у файл, і навпаки — при зверненні до її вмісту буде виданий вміст файлу.

До властивостей і методів об'єкту можна звертатися, використовуючи крапку (.), як в синтаксисі C#. PowerShell надає спеціальні змінні, такі як $args, що містить масив всіх неіменованих аргументів командного рядка, переданих функції, або $_, що посилається на поточний об'єкт в конвейєрі і інших конструкціях. У PowerShell також присутні масиви і асоціативні масиви. Крім того, PowerShell автоматично обчислює арифметичні вирази, введені в командному рядку, і розуміє популярні скорочення, такі як GB (ГБ), MB (МБ) і KB (КБ).

У PowerShell можна створювати власні функції, що приймають параметри за допомогою ключового слова function. Популярна проблема для багатьох початківців — те, що функції приймають аргументи, розділені не комами, а пропусками (як утиліти командного рядка або командлети):

: Викликає функцію з двома аргументами.

Ці аргументи можуть бути прив’язані до параметрів, вказаних в оголошенні функції. Також до них можна звернутися через масив $args.

(,): Викликає функцію з одним аргументом, який є масивом з двох елементів.

PowerShell дозволяє викликати будь-які методи .NET, уклавши їх простір імен в квадратні дужки ([]), і потім використовуючи пару двокрапок (:) для вказівки статичного методу. Наприклад [System.Console]: :WriteLine («PowerShell»). Об'єкти створюються за допомогою командлету New-Object, додавати до них нові властивості можна використовуючи командлет Add-Member.

Для обробки помилок PowerShell надає механізм, заснований .NET. У разі помилки видаються об'єкти, що містять інформацію про помилку (об'єкт Exception), які перехоплюються ключовим словом trap. Проте поведінка при виникненні помилок настроюється. Так, можна налаштувати PowerShell, щоб у разі помилки він мовчки продовжував виконання без перехоплення помилки. У другій версії PowerShell також була додана конструкція Try Catch Finally.

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

4. ДОСЛІДЖЕННЯ ТЕХНОЛОГІЇ COM ТА СТВОРЕННЯ КОНТРОЛЕРІВ АВТОМАТИЗАЦІЇ MS OFFICE

4.1 Загальні принципи СОМ-технології

COM (Component Object Model) — це об'єктна модель компонентів. Дана технологія є базовою для технологій ActiveX і OLE. Технології OLE і ActiveX — всього лише надбудови над даною технологією. В якості прикладу можна навести об'єкт TObject, як базовий об'єкт VCL Delphi. Так само технологія СОМ є базовою по відношенню до OLE і ActiveX.

Технологія СОМ застосовується при описі API і двійкового стандарту для зв’язку об'єктів різних мов і середовищ програмування. СОМ надає модель взаємодії між компонентами і додатками. Технологія СОМ працює з так званими СОМ-об'єктами. СОМ-об'єкти схожі на звичайні об'єкти візуальної бібліотеки компонентів Delphi. На відміну від об'єктів VCL Delphi, СОМ-об'єкти містять властивості, методи і інтерфейси. Звичайний СОМ-об'єкт включає один або декілька інтерфейсів. Кожний з цих інтерфейсів має власний покажчик.

Технологія СОМ має два явні плюси:

— створення СОМ-об'єктів не залежить від мови програмування. Таким чином, СОМ-об'єкти можуть бути написані на різних мовах;

— СОМ-об'єкти можуть бути використані в будь-якому середовищі програмування під Windows. До числа цих середовищ входять Delphi, Visual C++, C++Builder, Visual Basic, і багато інших.

Всі СОМ-об'єкти зазвичай містяться у файлах з розширенням DLL або OCX. Один такий файл може містити як одиночний СОМ-об'єкт, так і декілька СОМ-об'єктів. Ключовим аспектом технології СОМ є можливість надання зв’язку і взаємодії між компонентами і додатками, а також реалізація клієнт-серверних взаємодій за допомогою інтерфейсів. Технологія СОМ реалізується за допомогою СОМ-бібліотек (до числа яких входять такі файли операційної системи, як OLE32. DLL і