Дипломна робота
Розробка бази даних з архітектурою “клієнт-сервер”. Розробка серверної
та клієнтської частини.
ЗМІСТ
TOC \o “1-3” \h \z \u HYPERLINK \l “_Toc167785044” ВСТУП PAGEREF
_Toc167785044 \h 4
HYPERLINK \l “_Toc167785045” 1. ОГЛЯД І АНАЛІЗ РОЗГЛЯДУВАНОЇ ПРОБЛЕМИ
І ІСНУЮЧИХ МЕТОДІВ І ЗАСОБІВ ЇЇ ВИРІШЕННЯ PAGEREF _Toc167785045 \h 8
HYPERLINK \l “_Toc167785046” 1.1 Огляд архітектури “КЛІЄНТ-СЕРВЕР”
PAGEREF _Toc167785046 \h 8
HYPERLINK \l “_Toc167785047” 1.1.2 Клієнти та сервери локальних
мереж. PAGEREF _Toc167785047 \h 9
HYPERLINK \l “_Toc167785048” 1.1.3 Системна архітектура
“клієнт-сервер” PAGEREF _Toc167785048 \h 11
HYPERLINK \l “_Toc167785049” 1.1.4 Сервери баз даних PAGEREF
_Toc167785049 \h 14
HYPERLINK \l “_Toc167785050” 1.1.5 Принципи взаємодії між
клієнтськими й серверними частинами PAGEREF _Toc167785050 \h 14
HYPERLINK \l “_Toc167785051” 1.1.6 Переваги протоколів віддаленого
виклику процедур PAGEREF _Toc167785051 \h 15
HYPERLINK \l “_Toc167785052” 1.1.7 Типовий поділ функцій між
клієнтами й серверами PAGEREF _Toc167785052 \h 16
HYPERLINK \l “_Toc167785053” 1.1.8 Архітектури процесора бази даних.
PAGEREF _Toc167785053 \h 16
HYPERLINK \l “_Toc167785054” 1.2 Трирівнева архітектура
“КЛІЄНТ-СЕРВЕР” PAGEREF _Toc167785054 \h 17
HYPERLINK \l “_Toc167785055” 1.2.1 Персональні СУБД. PAGEREF
_Toc167785055 \h 21
HYPERLINK \l “_Toc167785056” 1.3 INTRANET і архітектура
“КЛІЄНТ-СЕРВЕР” PAGEREF _Toc167785056 \h 23
HYPERLINK \l “_Toc167785057” 1.3.1 Дворівнева архітектура
“клієнт-сервер” PAGEREF _Toc167785057 \h 23
HYPERLINK \l “_Toc167785058” 1.3.2 Трирівнева архітектура
“клієнт-сервер” PAGEREF _Toc167785058 \h 24
HYPERLINK \l “_Toc167785059” 1.3.3. Програми розширення серверної
частини PAGEREF _Toc167785059 \h 25
HYPERLINK \l “_Toc167785060” 1.4 Технологія JAVA. PAGEREF
_Toc167785060 \h 25
HYPERLINK \l “_Toc167785061” 1.4.1 Технологічний цикл обробки
JAVA-програм. PAGEREF _Toc167785061 \h 25
HYPERLINK \l “_Toc167785062” 1.4.2 JAVA-машина PAGEREF
_Toc167785062 \h 28
HYPERLINK \l “_Toc167785063” 1.4.3 Типи даних які підтримує
JAVA-машина PAGEREF _Toc167785063 \h 29
HYPERLINK \l “_Toc167785064” 1.4.4 Регістри PAGEREF _Toc167785064
\h 30
HYPERLINK \l “_Toc167785065” 1.4.5 Вказівники PAGEREF _Toc167785065
\h 31
HYPERLINK \l “_Toc167785066” 1.4.6 “Збір сміття” PAGEREF
_Toc167785066 \h 32
HYPERLINK \l “_Toc167785067” 1.4.7 Система команд JAVA-машини
PAGEREF _Toc167785067 \h 33
HYPERLINK \l “_Toc167785068” 1.5 Взаємодія з серверами баз даних –
JDBC PAGEREF _Toc167785068 \h 34
HYPERLINK \l “_Toc167785069” 1.5.1 Використання JDBC PAGEREF
_Toc167785069 \h 35
HYPERLINK \l “_Toc167785070” 1.5.2 Принципи використання JDBC
PAGEREF _Toc167785070 \h 36
HYPERLINK \l “_Toc167785071” 3.4 Нетривіальні можливості JDBC
PAGEREF _Toc167785071 \h 39
HYPERLINK \l “_Toc167785072” 3.5 Використання JDBC 363 PAGEREF
_Toc167785072 \h 41
HYPERLINK \l “_Toc167785073” 1.4 Робота з запитами в MS Access
PAGEREF _Toc167785073 \h 44
HYPERLINK \l “_Toc167785074” 1.5.1 Створення запитів на вибірку
PAGEREF _Toc167785074 \h 45
HYPERLINK \l “_Toc167785075” 1.5.2 Вибір даних з однієї таблиці
PAGEREF _Toc167785075 \h 46
HYPERLINK \l “_Toc167785076” 1.5.3 Встановлення властивостей полів
PAGEREF _Toc167785076 \h 48
HYPERLINK \l “_Toc167785077” 1.5.4. Введення умов відбору PAGEREF
_Toc167785077 \h 49
HYPERLINK \l “_Toc167785078” 1.5.5 Умови відбору для дат і часу
PAGEREF _Toc167785078 \h 50
HYPERLINK \l “_Toc167785079” 1.5.6 Багатотабличні запити PAGEREF
_Toc167785079 \h 51
HYPERLINK \l “_Toc167785080” 1.5.7 Створення запиту на основі іншого
запиту PAGEREF _Toc167785080 \h 53
HYPERLINK \l “_Toc167785081” 2.1 Основні поняття формальної моделі
PAGEREF _Toc167785081 \h 57
HYPERLINK \l “_Toc167785082” 2.2 Модель системи PAGEREF
_Toc167785082 \h 58
HYPERLINK \l “_Toc167785083” 3.ІМПЛЕМЕНТАЦІЯ ПРОГРАМИ З АРХІТЕКТУРОЮ
“КЛІЄНТ-СЕРВЕР” ЗАСОБАМИ МОВИ JAVA2 EE PAGEREF _Toc167785083 \h 64
HYPERLINK \l “_Toc167785084” 3.1 Постановка задачі PAGEREF
_Toc167785084 \h 64
HYPERLINK \l “_Toc167785085” 3.2 Реалізація клієнтської частини
PAGEREF _Toc167785085 \h 64
HYPERLINK \l “_Toc167785086” 3.3 Реалізація серверної частини
PAGEREF _Toc167785086 \h 69
HYPERLINK \l “_Toc167785087” 4. ВИЗНАЧЕННЯ ЕКОНОМІЧНОЇ ЕФЕКТИВНОСТІ
РОБОТИ СИСТЕМИ PAGEREF _Toc167785087 \h 75
HYPERLINK \l “_Toc167785088” 4.1 Економічна доцільність розробки
програмного забезпечення та його впровадження PAGEREF _Toc167785088 \h
75
HYPERLINK \l “_Toc167785089” 4.2 Побудова мережевого графа PAGEREF
_Toc167785089 \h 75
HYPERLINK \l “_Toc167785090” 4.3 Економічне обґрунтування розробки та
впровадження програми PAGEREF _Toc167785090 \h 82
HYPERLINK \l “_Toc167785091” 4.4 Розрахунок витрат на розробку
програмного забезпечення PAGEREF _Toc167785091 \h 83
HYPERLINK \l “_Toc167785092” 4.5 Розрахунок капітальних вкладень
PAGEREF _Toc167785092 \h 84
HYPERLINK \l “_Toc167785093” 4.6 Розрахунок експлуатаційних витрат
PAGEREF _Toc167785093 \h 85
HYPERLINK \l “_Toc167785094” 4.7 Розрахунок зведених економічних
показників PAGEREF _Toc167785094 \h 86
HYPERLINK \l “_Toc167785095” 5.1 Аналіз небезпечних та шкідливих
виробничих факторів PAGEREF _Toc167785095 \h 88
HYPERLINK \l “_Toc167785096” 5.2 Заходи для забезпечення нормальних
умов праці та розрахунок природної освітленості PAGEREF _Toc167785096
\h 90
HYPERLINK \l “_Toc167785097” 5.3 Забезпечення безпеки експлуатації
ЕОМ PAGEREF _Toc167785097 \h 98
HYPERLINK \l “_Toc167785098” ВИСНОВКИ PAGEREF _Toc167785098 \h 103
ВСТУП
Архітектура клієнт-сервер сьогодні являє собою домінуючу концепцію у
створенні розподілених мережних застосувань і передбачає взаємодію та
обмін даними між ними. Вона передбачає такі основні компоненти: набір
серверів, які надають інформацію або інші послуги програмам, які
звертаються до них; набір клієнтів, які використовують сервіси, що
надаються серверами; мережа, яка забезпечує взаємодію між клієнтами та
серверами. Сервери є незалежними один від одного. Клієнти також
функціонують паралельно і незалежно один від одного. Немає жорсткої
прив’язки клієнтів до серверів. Більш ніж типовою є ситуація, коли один
сервер одночасно обробляє запити від різних клієнтів; з іншого боку,
клієнт може звертатися то до одного сервера, то до іншого. Клієнти мають
знати про доступні сервери, але можуть не мати жодного уявлення про
існування інших клієнтів.
Дуже важливо ясно уявляти, хто або що розглядається як “клієнт”. Можна
говорити про клієнтський комп’ютер, з якого відбувається звернення до
інших комп’ютерів. Можна говорити про клієнтське та серверне програмне
забезпечення. Нарешті, можна говорити про людей, які бажають за
допомогою відповідного програмного та апаратного забезпечення отримати
доступ до тієї чи іншої інформації.
Загальноприйнятим є положення, що клієнти та сервери – це перш за все
програмні модулі. Найчастіше вони знаходяться на різних комп’ютерах, але
бувають ситуації, коли обидві програми – і клієнтська, і серверна,
фізично розміщуються на одній машині; в такій ситуації сервер часто
називається локальним.
Типовим прикладом клієнт-серверної взаємодії є WWW. Існує величезна
кількість веб-серверів, на яких розміщується та чи інша інформація. У
найпростішому випадку ця інформація являє собою набір веб-сторінок, які
можуть зберігатися на сервері у вигляді файлів, розмічених за допомогою
мови розмітки HTML. Але ситуація, як правило, є більш складною; значна
частина веб-ресурсів на сучасному етапі є динамічними, тобто вони не
існують в заздалегідь підготовленому вигляді, а створюються
безпосередньо в процесі обробки запиту від користувача.
Для того, щоб людина, яка працює в Інтернет, могла переглянути ту чи
іншу сторінку, на її комп’ютері повинно бути встановлено відповідне
програмне забезпечення. Програми для перегляду веб-сторінок називаються
броузерами; найпоширенішим броузером є Internet Explorer.
Але, крім броузерів, до серверів можуть звертатися і інші клієнти, а
саме – автономні програми. Вони можуть передбачати взаємодію з людиною,
а можуть працювати в цілком автоматичному режимі. Типовим класом таких
програм є роботи, призначені для автоматичного перегляду веб-ресурсів.
Зокрема, роботи є важливим елементом пошукових систем і використовуються
ними для перегляду сторінок і збору інформації про них.
Для запиту до веб-сервера клієнтська програма повинна задати
місцезнаходження комп’ютера, на якому розміщується серверна програма;
назву потрібного документа і, можливо, інші дані, які специфікують
запит. Мережа забезпечує знаходження сервера і передачу йому
клієнтського запиту. Серверні програми обробляють цей запит; відповідь
пересилається по мережі клієнтові.
Модель клієнт-серверної взаємодії визначається перш за все розподілом
обов’язків між клієнтом та сервером. Логічно можна виокремити три рівні
операцій: рівень представлення даних, який по суті являє собою інтерфейс
користувача і відповідає за представлення даних користувачеві і введення
від нього керуючих команд; прикладний рівень, який реалізує основну
логіку застосування і на якому здійснюється необхідна обробка
інформації; рівень управління даними, який забезпечує зберігання даних
та доступ до них. Дворівнева клієнт-серверна архітектура передбачає
взаємодію двох програмних модулів – клієнтського та серверного. В
залежності від того, як між ними розподіляються наведені вище функції,
розрізняють : модель тонкого клієнта, в рамках якої вся логіка
застосування та управління даними зосереджена на сервері. Клієнтська
програма забезпечує тільки функції рівня представлення; модель товстого
клієнта, в якій сервер тільки керує даними, а обробка інформації та
інтерфейс користувача зосереджені на стороні клієнта. Тонкими клієнтами
часто також називають пристрої з обмеженою потужністю: кишенькові
комп’ютери, мобільні телефони та ін.
Трирівнева клієнт-серверна архітектура, яка почала розвиватися з
середини 90-х років, передбачає відділення прикладного рівня від
управління даними. Виокремлюється окремий програмний рівень, на якому
зосереджується прикладна логіка застосування. Програми проміжного рівня
можуть функціонувати під управлінням спеціальних серверів застосувань,
але запуск таких програм може здійснюватися і під управлінням звичайного
веб-сервера. Нарешті, управління даними здійснюється сервером даних.
Для роботи з системою користувач використовує стандартне програмне
забезпечення – звичайний броузер. Це позбавляє його необхідності
завантажувати та інсталювати спеціальні програми (хоча інколи така
необхідність все-таки виникає). Але користувачеві слід надати в
розпорядженні інтерфейс, який дозволяв би йому взаємодіяти з системою і
формувати запити до неї; форми, що визначають цей інтерфейс,
розміщуються на веб-сторінках та завантажуються разом з ними.
Броузер формує запит та пересилає його до сервера, який здійснює
обробку. При необхідності сервер викликає серверні програмні модулі, які
забезпечують обробку запиту і в разі потреби звертаються до сервера
даних. Сервер даних здійснює операції з даними, що зберігаються в
системі та складають її інформаційну основу. Зокрема, він може здійснити
вибірку з інформаційної бази відповідно до запиту та передати її модулю
проміжного рівня для подальшої обробки. Дані, з якими працює сервер
даних, найчастіше організовані як реляційна база даних.
Найчастіше веб-сервер і серверні модулі проміжного рівня розміщуються на
одному комп’ютері, хоч і являють собою окремі і логічно незалежні
програмні модулі.
На сучасному етапі для програмування модулів проміжного рівня
використовується мова серверних сценаріїв РНР, а для управління даними –
СУБД MySQL. Таким чином, зв’язку PHP-MySQL слід розглядати як
стандартний інструмент для створення порівняно простих інтерактивних
веб-сайтів та систем електронної комерції; близько 90% комерційних
систем сьогодні створюється саме на цій основі. Водночас як засоби
управління даними, так і middleware-засоби можуть бути
найрізноманітнішими. Так, для створення серверних застосувань, крім РНР,
широко застосовуються Java, Perl, Python. Взагалі, технології створення
розподілених, зокрема веб-застосувань, стрімко розвиваються. Слід
згадати про технології EJB (Enterprise Java Beans), CORBA, а також про
.NET – порівняно нову ініціативу компанії Microsoft. Для зберігання
даних та їх передачі часто використовується так звана розширена мова
розмітки XML (Extensible Markup Language).
1. ОГЛЯД І АНАЛІЗ РОЗГЛЯДУВАНОЇ ПРОБЛЕМИ І ІСНУЮЧИХ МЕТОДІВ І ЗАСОБІВ
ЇЇ ВИРІШЕННЯ
1.1 Огляд архітектури “КЛІЄНТ-СЕРВЕР”
Подібно до систем баз даних архітектура “клієнт-сервер” цікава й
актуальна головним чином тому, що забезпечує просте й відносно дешеве
рішення проблеми колективного доступу до баз даних у локальній мережі.
Використання архітектури “клієнт-сервер” може зацікавити у випадку, коли
Ви відповідаєте за розробку програми, яка постійно звертається до даних
у локальній мережі або до файлового сервера. До цього програмного
забезпечення можуть звертатись декілька користувачів, а з часом й інші
програми які будуть обробляти ці дані деяким чином.
Реальне поширення архітектури “клієнт-сервер” стало можливим завдяки
розвитку й широкому впровадженню в практику концепції відкритих систем.
Тому ми почнемо з короткого введення про них.
Основним змістом підходу відкритих систем є спрощення комплексування
обчислювальних систем за рахунок міжнародної й національної
стандартизації апаратних і програмних інтерфейсів. Головною причиною
розвитку концепції відкритих систем – це перехід до використання
локальних комп’ютерних мереж і ті проблеми комплексування
апаратно-програмних засобів, які викликав цей перехід. У зв’язку з
бурхливим розвитком технологій глобальних комунікацій відкриті системи
здобувають ще більше значення й масштабність.
Ключовою фразою відкритих систем, спрямованої убік користувачів, є
незалежність від конкретного постачальника. Орієнтуючись на продукцію
компаній, що дотримуються стандартів відкритих систем, споживач, що
здобуває будь-який продукт такої компанії, не попадає до неї в рабство.
Він може продовжити нарощування потужності своєї системи шляхом
придбання продуктів будь-якої іншої компанії, що дотримує стандарти.
Причому це стосується як апаратних, так і програмних засобів.
Практичною опорою системних і прикладних програмних засобів відкритих
систем є стандартизована операційна система. У цей час такою системою є
UNIX. Фірмам-постачальникам різних варіантів ОС UNIX у результаті
тривалої роботи вдалося прийти до угоди про основні стандарти цієї
операційної системи. Зараз всі розповсюджені версії UNIX в основному
сумісні по частині інтерфейсів, наданих прикладним (а в більшості
випадків і системним) програмістам. Як здається, незважаючи на появу
системи, що претендує на стандарт, Windows NT, саме UNIX залишиться
основою відкритих систем у найближчі роки.
Технології й стандарти відкритих систем забезпечують реальну й
перевірену практикою можливість виробництва системних і прикладних
програмних засобів із властивостями мобільності (portability) та
інтероперабельності (interoperability). Властивість мобільності означає
порівняльну простоту переносу програмної системи в широкому спектрі
апаратно-програмних засобів, що відповідають стандартам.
Інтероперабельність означає спрощення комплексування нових програмних
систем на основі використання готових компонентів із стандартними
інтерфейсами.
Перевагою для користувачів є те, що вони можуть поступово заміняти
компоненти системи на їх нові версії, не втрачаючи працездатності
системи. Зокрема, у цьому криється рішення проблеми поступового
нарощування обчислювальних, інформаційних й інших потужностей
комп’ютерної системи.
1.1.2 Клієнти та сервери локальних мереж.
В основі широкого поширення локальних мереж лежить відома ідея поділу
ресурсів. Висока пропускна здатність локальних мереж забезпечує
ефективний доступ з одного вузла локальної мережі до ресурсів, що
перебуває в інших вузлах.
Розвиток цієї ідеї приводить до функціонального виділення компонентів
мережі: розумно мати не тільки доступ до ресурсів вибраного комп’ютера,
але також одержувати від цього комп’ютера деякий сервіс. Так ми
приходимо до розрізнення робочих станцій і серверів локальної мережі.
Робоча станція призначена для безпосередньої роботи користувача або
категорії користувачів і має ресурси, що відповідають локальним потребам
даного користувача.
Сервер локальної мережі повинен мати ресурси, що відповідають його
функціональному призначенню й потребам мережі. Помітимо, що у зв’язку з
орієнтацією на підхід відкритих систем, вірніше говорити про логічні
сервери (маючи на увазі набір ресурсів і програмних засобів, що
забезпечують послуги над цими ресурсами), які розташовуються не
обов’язково на різних комп’ютерах. Особливістю логічного сервера у
відкритій системі є те, що якщо з міркуваннях ефективності сервер
доцільно перемістити на окремий комп’ютер, те це можна проробити без
потреби в якій-небудь переробці як його самого, так і його прикладних
програм.
Прикладами серверів можуть служити:
• сервер телекомунікацій, що забезпечує послуги зі зв’язку даної
локальної мережі із зовнішнім світом;
• обчислювальний сервер, що дає можливість робити обчислення, які
неможливо виконати на робочих станціях;
• дисковий сервер, що володіє розширеними ресурсами зовнішньої пам’яті й
їх у використання користувачам й, можливо, іншим серверам;
• файловий сервер, що підтримує загальне сховище файлів для всіх робочих
станцій;
• сервер баз даних, фактично звичайна СУБД, що приймає запити по
локальній мережі й повертає результати.
Сервер локальної мережі надає ресурси (послуги) робочим станціям й/або
іншим серверам.
Прийнято називати клієнтом локальної мережі, що запитує послуги в
деякого сервера й сервером – компонентів локальної мережі, що роблять
послуги деяким клієнтам.
1.1.3 Системна архітектура “клієнт-сервер”
Зрозуміло, що в загальному, щоб прикладна програма, що виконується на
робочій станції, могла запросити послугу в деякого сервера, як мінімум
потрібно деякий інтерфейсний програмний рівень, що підтримує такого роду
взаємодію (було б щонайменше неприродно вимагати, щоб прикладна програма
прямо користувалася примітивами транспортного рівня локальної мережі).
Із цього і випливають основні принципи системної архітектури
“клієнт-сервер”.
Система розбивається на дві частини, які можуть виконуватися в різних
вузлах мережі, – клієнтську й серверну частини. Прикладна програма або
кінцевий користувач взаємодіють із клієнтською частиною системи, що у
найпростішому випадку забезпечує просто надмережний інтерфейс.
Клієнтська частина системи при потребі звертається по мережі до
серверної частини. Помітимо, що в розвинених системах мережне звертання
до серверної частини може й не знадобитися, якщо система може вгадувати
потреби користувача, і в клієнтській частині втримуються дані, здатні
задовольнити його наступний запит.
Інтерфейс серверної частини визначений і фіксований. Тому можливо
створення нових клієнтських частин існуючої системи (приклад
інтероперабельності на системному рівні).
Основною проблемою систем, заснованих на архітектурі “клієнт-сервер”, є
те, що відповідно до концепції відкритих систем від них потрібна
мобільність у якомога більшому широкому класі апаратно-програмних рішень
відкритих систем. Навіть якщо обмежитися UNIX-орієнтованими локальними
мережами, у різних мережах застосовується різна апаратура й протоколи
зв’язку. Спроби створення систем, що підтримують всі можливі протоколи,
приводить до їхнього перевантаження та шкоду функціональності.
Ще більш складний аспект цієї проблеми пов’язаний з можливістю
використання різних подань даних у різних вузлах неоднорідної локальної
мережі. У різних комп’ютерах може існувати різна адресація, подання
чисел, кодування символів і т.д. Це особливо істотно для серверів
високого рівня: телекомунікаційних, обчислювальних, баз даних.
Загальним рішенням проблеми мобільності систем, заснованих на
архітектурі “клієнт-сервер” є опора на програмні пакети, що реалізують
протоколи вилученого виклику процедур (RPC – Remote Procedure Call). При
використанні таких засобів звертання до сервісу у вилученому вузлі
виглядає як звичайний виклик процедури. Засоби RPC, у яких, природно,
утримується вся інформація про специфіку апаратур локальної мережі й
мережних протоколів, переводить виклик у послідовність мережних
взаємодій. Тим самим, специфіка мережного середовища й протоколів
схована від прикладного програміста.
При виклику вилученої процедури програми RPC роблять перетворення
форматів даних клієнта в проміжні машинно-незалежні формати й потім
перетворення у формати даних сервера. При передачі відповідних
параметрів виробляються аналогічні перетворення.
Якщо система реалізована на основі стандартного пакета RPC, вона може
бути легко перенесена в будь-яке відкрите середовище.
Технологія “клієнт-сервер” стосовно до СУБД зводиться до поділу системи
на дві частини – додаток-клієнт (front-end) і сервер бази даних
(back-end). Ця архітектура сполучає кращі риси обробки даних на
мэйнфреймах і технології “файл-сервер”. Від мэйнфреймов технологія
“клієнт-сервер” запозичила такі риси, як централізоване адміністрування,
безпека, надійність. Від технології “файл-сервер” успадковані низька
вартість і можливість розподіленої обробки даних, використовуючи ресурси
комп’ютерів-клієнтів. Зараз графічний інтерфейс користувача став
стандартом для систем “клієнт-сервер”. Крім того, архітектура
“клієнт-сервер” значно спрощує й прискорює розробку додатків за рахунок
того, що правила перевірки цілісності даних перебувають на сервері.
Неправильно працюючий клієнтський додаток не може привести до втрати або
перекручування даних. Всі ці можливості, раніше властиві тільки складній
і дорогій системам, зараз доступні навіть невеликим організаціям.
Вартість устаткування, програмного забезпечення й обслуговування для
персональних комп’ютерів у десятки разів нижче, ніж для мейнфреймів.
Особливості обробки даних у різних архитектурах показані на Рисунку 1.
Рисунок 1. Обробка даних у різних архітектурах
Локальний комп’ютер
Локальний додаток
СУБД
Дані
Архітектура “файл-сервер”
Клієнт
Файл-сервер
Мережевий додаток
Дані
СУБД
Клієнт
Мережевий додаток
Пересилання даних
СУБД
Архітектура “клієнт-сервер”
Сервер БД
Клієнтський додаток
Дані
Клієнтський додаток
пересилання запитів
і результатів
1.1.4 Сервери баз даних
Термін “сервер баз даних” звичайно використовують для позначення всієї
СУБД, заснованої на архітектурі “клієнт-сервер”, включаючи й серверну, і
клієнтську частини. Такі системи призначені для зберігання й
забезпечення доступу до баз даних.
Хоча звичайно одна база даних цілком зберігається в одному вузлі мережі
й підтримується одним сервером, сервери баз даних являють собою просте й
дешеве наближення до розподілених баз даних, оскільки загальна база
даних доступна для всіх користувачів локальної мережі.
1.1.5 Принципи взаємодії між клієнтськими й серверними частинами
Доступ до бази даних від прикладної програми або користувача створюється
шляхом звертання до клієнтської частини системи. Як основний інтерфейс
між клієнтською й серверною частинами виступає мова баз даних SQL.
Це мова по суті справи являє собою поточний стандарт інтерфейсу СУБД у
відкритих системах. Назва SQL-сервер ставиться до всіх серверів баз
даних, заснованих на SQL.
Сервери баз даних, інтерфейс яких заснований винятково мовою SQL, мають
свої переваги й свої недоліки. Очевидна перевага – стандартність
інтерфейсу. У ідеалі, хоча це і не зовсім так, клієнтські частини
будь-якої SQL-орієнтованої СУБД могли б працювати з будь-яким
SQL-сервером незалежно від виробника останнього.
Недолік теж досить очевидний. При такому високому рівні інтерфейсу між
клієнтською й серверною частинами системи на стороні клієнта працює
занадто мало програм СУБД. Це нормально, якщо на стороні клієнта
використається малопотужна робоча станція. Але якщо клієнтський
комп’ютер має достатню потужність, то часто виникає бажання покласти на
нього більше функцій керування базами даних, розвантаживши сервер, що є
вузьким місцем всієї системи.
Одним з перспективних напрямків СУБД є гнучке конфігурування системи,
при якому розподіл функцій між клієнтською й користувацькою частинами
СУБД визначається при установці системи.
1.1.6 Переваги протоколів віддаленого виклику процедур
Згадані вище протоколи віддаленого виклику процедур особливо важливі в
системах керування базами даних, заснованих на архітектурі
“клієнт-сервер”.
По-перше, використання механізму віддаленних процедур дозволяє
перерозподіляти функції між клієнтською й серверною частинами системи,
оскільки в тексті програми віддаленний виклик процедури нічим не
відрізняється від самого виклику, і отже, теоретично будь-який компонент
системи може розташовуватися як на стороні сервера, так і на стороні
клієнта.
По-друге, механізм віддаленого виклику приховує розходження між
взаємодіючими комп’ютерами. Фізично неоднорідна локальна мережа
комп’ютерів приводиться до логічно однорідної мережі взаємодіючих
програмних компонентів. У результаті користувачі не зобов’язані серйозно
піклуватися про разову закупівлю сумісних серверів і робочих станцій.
1.1.7 Типовий поділ функцій між клієнтами й серверами
У типовому на сьогоднішній день випадку, на стороні клієнта СУБД працює
тільки таке програмне забезпечення, що не має безпосереднього доступу до
баз даних, а звертається для цього до сервера з використанням мови SQL.
У деяких випадках хотілося б включити до складу клієнтської частини
системи деякі функції для роботи з “локальним кэшем” бази даних, тобто з
тією її частиною, що інтенсивно використається клієнтською прикладною
програмою. У сучасній технології це можна зробити тільки шляхом
формального створення на стороні клієнта локальної копії сервера бази
даних і розгляду всієї системи як набору взаємодіючих серверів.
З іншого боку, іноді хотілося б перенести більшу частину прикладної
системи на сторону сервера, якщо різниця в потужності клієнтських
робочих станцій і сервера надто велика. Взагалі ж при використанні RPC
це зробити неважко. Але потрібно, щоб базове програмне забезпечення
сервера дійсно дозволяло це. Зокрема, при використанні ОС UNIX проблеми
практично не виникають.
1.1.8 Архітектури процесора бази даних.
Основна частина будь-якої системи “клієнт-сервер” – це сервер БД. Із
часу виникнення архітектури “клієнт-сервер” з’явилося багато варіантів
архітектури процесора БД, оскільки він багато в чому визначає успіх
всієї системи. Основна вимога до сервера БД – забезпечення мінімального
часу виконання запитів при максимально можливому числі користувачів.
Існують дві основні архітектури для побудови процесора БД: архітектура з
декількома процесами й багатоптокова архітектура.
1. Архітектура з декількома процесами
Характеризується тим, що кілька екземплярів виконавчого файлу, що
працюють одночасно. Ці системи відрізняються непоганою масштабованістю,
але вимагають значних витрат пам’яті, тому що пам’ять кожному екземпляру
додатка виділяється окремо. Ця архітектура має на увазі наявність
ефективного механізму взаємодії процесів і покладається на операційну
систему при поділі процесорного часу між окремими екземплярами додатка.
Найвідоміший приклад сервера, побудованого по цій архітектурі, – Oracle
Server. Коли користувач підключається до БД Oracle, він у дійсності
запускає окремий екземпляр виконавчого файлу бази даних.
2. Багатопотокова архітектура
Ця архітектура використовує тільки один виконавчий файл з декількома
потоками виконання. Головна перевага – більш скромні вимоги до
впровадження ніж для архітектури з декількома процесами. Тут сервер бере
на себе поділ часу між окремими потоками, іноді даючи перевагу деяким
завданням над іншими. Крім того, відпадає необхідність у складному
механізмі взаємодії процесів. По цій архітектурі побудовані MS SQL
Server й Sybase SQL Server.
1.2 Трирівнева архітектура “КЛІЄНТ-СЕРВЕР”
На верхньому рівні абстрагування взаємодії клієнта й сервера досить
чітко можна виділити наступні компоненти:
• презентаційна логіка (Presentation Layer – PL), призначена для роботи
з даними користувача;
• бізнес-логіка (Business Layer – BL), призначена для перевірки
правильності даних, підтримки, тощо;
• логіка доступу до ресурсів (Access Layer – AL), призначена для
зберігання даних;
Рисунок 2. “Товстий” клієнт. (fat client)
Сервер БД Користувацький інтерфейс
Дані Бізнес-логіка
Користувацький інтерфейс
Бізнес-логіка
Найбільше що часто зустрічається варіант реалізації архітектури
клієнт-сервер у вже впроваджених системах. Така модель має на увазі
об’єднання в клієнтському додатку як PL, так й BL, у такий спосіб
забезпечується повна децентралізація керування бізнесом-логікою. Однак
якщо буде потреба виконання яких-небудь змін у клієнтському додатку
потрібно міняти вихідний код. Серверна частина, при описаному підході,
являє собою сервер баз даних, реалізуючий AL. До описаної моделі часто
застосовують абревіатуру RDA – Remote Data Access.
Рисунок 3. “Тонкий” клієнт. (thin client)
Логіка Користувацький інтерфейс
Дані
Користувацький інтерфейс
Модель, що починає активно використатися в корпоративному середовищі у
зв’язку з поширенням Internet-технологій й, у першу чергу,
Web-браузерів. У цьому випадку клієнтський додаток забезпечує реалізацію
PL, тому клієнт може задовольнятися досить скромною апаратною
платформою, а сервер поєднує BL й AL. Максимальне завантаження сервера
передбачає виконання бізнесу-логіки тільки за допомогою збережених
процедур сервера (Збережені процедури – відкомпільовані SQL-інструкції,
що зберігаються на сервері). Це дозволяє максимально централізувати
контроль над даними й легко змінювати правила роботи відразу для цілого
підприємства. З іншого боку, незначне коректування правил, що стосуються
тільки частини користувачів, вимагає тривалої процедури узгодження. У
цьому випадку неможливо реалізувати якісь виключення із загальних правил
для деяких користувачів або додатків. У принципі, це добре і є запорукою
безпеки й цілісності даних.
Рисунок 4. Сервер бізнесу-логіки. (Трирівнева архітектура)
Проміжний сервер
Користувацький інтерфейс
Бізнес-логіка
другого рівня
Сервер БД
Користувацький інтерфейс
Бізнес-логіка
Дані
З модель із фізично виділеним в окремий додаток блоком BL одержуємо
трирівневу архітектуру “клієнт-сервер”. На сервері БД може функціонувати
“універсальна” частина бізнес-логіки (правила на рівні підприємства або
групи зв’язаних додатків). Така схема дозволяє підтримувати клієнтів на
користувальницьких комп’ютерах й у той же час розвантажити сервер БД від
надмірного завантаження при збереженні гнучкої системи роботи з
бізнеса-правилами. Як проміжний сервер може використатися інший
SQL-сервер, але частіше та раціональніше задіяти персональну СУБД, що
менш вимоглива до апаратних ресурсів і може забезпечити зручні засоби
побудови й підтримки бізнес-логіки.
1.2.1 Персональні СУБД.
Для розробки клієнтських додатків у більшості випадків замість
універсальних засобів розробки зручніше використати персональні СУБД.
Використання персональних СУБД дозволяє не тільки ефективно
організовувати роботу з бізнес-правилами, але й підтримати незалежну
роботу клієнтського додатка за рахунок наявності власних форматів
зберігання даних. Коротка характеристика деяких персональних СУБД
наведена в таблиці.
Таблиця 1.2.1 – Коротка характеристика деяких персональних СУБД
Найменування Коротка характеристика
Lotus Approach 97 Дозволяє виконувати всі види обробки даних. Має дуже
простий інтерфейс. СУБД тісно інтегрована з базами даних Notes й
електронними таблицями Lotus 1-2-3. Підтримує технологію електронного
обміну повідомленнями MAPI.
MS Access 97 Повноцінна СУБД, що володіє багатим набором візуальних
засобів, численними майстрами й потужною мовою програмування Visual
Basic for Applications. Має гнучку систему підготовки звітів.
Підтримуються технології ODBC і OLE 2.0. СУБД тісно інтегрована з усіма
додатками MS Office.
MS Visual FoxPro 5 Одна з найбільш швидких персональних СУБД, що
сполучає технологію xBase й об’єктно-орієнтировану мову програмування.
Має багатий набір візуальних засобів розробки й майстрів для швидкої
побудови додатків і звітів. Підтримуються технології Active, ODBC й OLE
2.0. Дозволяє створювати OLE-сервера й має засоби для розробки й
підтримки додатків “клієнт-сервер”.
Paradox 7 Підтримує всі види роботи з даними. Для візуального виконання
стандартних завдань є спеціальний засіб Experts. Наділений власною
досить складною мовою ObjectPAL. Підтримує технології OLE 2.0, Active,
MAPI й ODBC.
1.3 INTRANET і архітектура “КЛІЄНТ-СЕРВЕР”
1.3.1 Дворівнева архітектура “клієнт-сервер”
Рисунок 5. Дворівнева архітектура “клієнт-сервер”
Web-броузер Джерело даних
Web-сервер
NOS (Network Operation System)
Розмежування функцій між Web-броузером й Web-сервером є дуже чітким.
Web-сервер надає HTML-сторінки, а броузер відображає ці сторінки шляхом
інтерпретації тегів HTML.
1.3.2 Трирівнева архітектура “клієнт-сервер”
Рисунок 6. Трирівнева архітектура “клієнт-сервер”
Web-броузер Джерело даних
Третій рівень
Програма розширення
сервера
HTML
Web-сервер
NOS
Клієнтський рівень займає броузер, на рівні сервера перебуває сервер БД,
а на проміжному рівні розташовуються Web-сервер і програма розширення
сервера. Таке архітектурне рішення дозволяє зменшити мережевий трафік,
робить компоненти взаємозамінними й підвищує рівень безпеки. Однак така
архітектура також утрудняє обробку транзакцій БД через природу протоколу
HTTP, який не запам’ятовує стан (цей протокол використовується для
передачі даних між броузером і сервером БД).
Броузер посилає Web-серверу запити на доставку Web-сторінок або даних.
Web-сервер обслуговує заявки на Web-сторінки, а запити відправляє
програмі-розширенню серверної частини. Остання приймає передані їй
запити, перетворить їх у форму, зрозумілу серверу БД, і передає їхньому
серверу БД.
Потім сервер БД виконує роботу з обслуговування запиту й повертає
результат програмі-розширенню серверної частини. Нарешті та перетворить
результати у формат, прийнятний для броузера, і передає їхньому
Web-серверу, а той у свою чергу – броузеру.
1.3.3. Програми розширення серверної частини
Однієї з головних причин використання програм-розширень серверної
частини на проміжному рівні є можливість використати стандарти, що
існують для двох крайніх рівнів, шляхом здійснення трансляції між ними.
Інші застосування розширень серверної частини складаються в підтримці
з’єднань між БД із метою зменшити трафік у мережі й у підтримці резерву
з’єднань між БД для зменшення витрат ресурсів на відкриття/закриття БД.
Розширення серверної частини також підтримують взаємозамінність у своїх
стандартних інтерфейсах. Тому Web-сервери й сервери БД можна порівняно
легко заміняти або нарощувати.
Існує три категорії розширень серверної частини: із звичайним CGI, з
гібридним CGI і з API.
1.4 Технологія JAVA.
1.4.1 Технологічний цикл обробки JAVA-програм.
Технологічний цикл підготовки, трансляції, редагування зовнішніх
зв’язків, тестування, налагодження й виконання Java-програм таки самий,
що й для інших мов програмування, що інтерпретуються, але з однією
істотною відмінністю – при редагуванні зовнішніх зв’язків необхідні
компоненти можуть доставлятися по мережі.
Важливо відзначити, однак, що Java-програми можуть з’являтися як би у
двох іпостасях – як самостійний додаток й як аплет, тобто сукупність
об’єктів, що виконуються в середовищі броузера.
З погляду програміста, аплет і додаток відрізняються в першу чергу
місцями входу й життєвим циклом.
Додаток як місце входу має метод
public static void main (String args[]);
Цей метод повинен бути визначений у тім public-класі, що знаходиться у
файлі, який виконується віртуальною Java-машиною. У параметр args
передається масив рядків – параметрів командного рядка.
Приклад: програма, що друкує свої аргументи
public class myTop {
public static void main (String args[]) {
int argc = args.length;
for (int i = 0; i < argc; i++)
System.out.println (argc[i]);
}
}
Аплет виконується в контексті броузера і його життєвий цикл визначається
наступними методами класу Applet:
public void init () – викликається броузером при завантаженні аплета;
public void start () – викликається броузером при показі сторінки;
public void stop () – викликається броузером, коли той іде з
Web-сторінки;
public void destroy () – цей метод призначений для звільнення ресурсів;
аналог деструктора, але не викликається автоматично; завжди викликає
stop() і викликається при виході з броузера та при перезавантаженні
аплета.
Приклад: аплета
1. import java.awt.Graphics;
2. import java.applet.Applet;
3. class SimpleApplet extends Applet {
4. public void paint (Graphics g) {
5. g.drawString (10, 10, “Hello world!”);
6. }
7. }
Найпростіший аплет виглядає так.
Метод paint (рядки 4-6) визначає, як аплет перемальовує себе в той
момент, коли віконний менеджер посилає броузеру запит на
перемальовування.
Включення аплета в WWW-сторінку виробляється в такий спосіб. У мові HTML
2.0 передбачені спеціальні конструкції
Якщо ви бачите цей текст,
те ваш навігатор не підтримує Java
Даний фрагмент містить простий приклад включення аплета в WWW-сторінку.
Оскільки броузери ігнорують невідомі конструкції, у навігаторі, що не
підтримує Java, буде видний текст “Якщо ви бачите цей текст, то ваш
навігатор не підтримує Java“
Отримати значення, передані за допомогою конструкції, можна в
такий спосіб.
public void init () {
String fontname = getParameter (“name”);
String fontSizestring = getParameter (“size”);
int theSize = Int.parseInt (fontSizeString);
. . .
}
1.4.2 JAVA-машина
Java-компілятор транслює вихідні тексти Java-програм у коди Java-машини.
Загалом кажучи, Java-машина є віртуальною в тому розумінні, що вона не
існує у вигляді реальних мікросхем й інших пристроїв, а являє собою
програмний емулятор, що виконується на якій-небудь традиційній апаратній
платформі. Імовірно, уже найближчим часом варто очікувати появи й усе
більше широкого поширення й прямих апаратних реалізацій Java-машини.
Ідея мовних процесорів не нова. Відомі спроби впровадити так званий
P-код як стандарт на результат роботи Паскаль-компиляторов; у свій час
багато писали про мову й машину Форт; була виконана апаратна реалізація
рефал-машины, і список цей можна продовжувати й продовжувати.
У контексті проекту Java специфікація віртуальної машини є частиною
комплексу мір, спрямованих на стандартизацію Java-середовища на
забезпечення її незалежності від апаратно-програмної платформи. Крім
того, варто враховувати те специфічне середовище, у якій повинні
готуватися й працювати Java-програми. Якщо Web-сторінка містить
Java-аплеты, ці аплеты будуть передаватися по мережі. Виходить, досить
бажано, щоб Java-код був як можна більше компактним; у противному
випадку час завантаження сторінки ризикує стати занадто великим.
Відповідно, архітектура й система команд Java-машини проектувалися таким
чином, щоб усіляко сприяти компактності коду. З іншого боку, формат
команд Java-машини досить простий (звичайно команди не мають операндов і
займають один байт), тому можливо її (машини) ефективну емуляцію. Із
цієї причини програми, підготовлені для виконання на Java-машині, часто
називають байтами-кодами.
1.4.3 Типи даних які підтримує JAVA-машина
Java-машина підтримує наступні стандартні типи даних:
byte – однобайтові цілі числа;
short – двобайтові цілі числа;
int – чотирьохбайтові цілі числа;
long – восьмибайтові цілі числа;
float – чотирьохбайтові дійсні числа у форматі IEEE-754;
double – восьмибайтові дійсні числа;
char – двобайтові беззнакові символи в кодуванні Unicode.
Оскільки Java-компілятор у стані перевірити типи даних під час
трансляції, при виконанні немає потреби асоціювати додаткову інформацію
зі значеннями стандартних типів. Замість цього генеруються команди,
розраховані на обробку даних певних типів. Наприклад, для додавання
цілих чисел буде згенерована команда iadd, а для додавання дійсних чисел
подвійної точності – команда dadd.
Значення типу boolean представляються однобайтовими цілими числами й
обробляються за допомогою відповідних команд.
Є ще два стандартних типи даних:
object – чотирьохбайтове посилання на об’єкт (масиви трактуються як
об’єкти);
returnAddress – чотирьохбайтовий адрес повернення з методу.
Специфікації Java-машини не описують внутрішньої структури об’єктів. У
реалізації Sun Microsystems значення типу object вказує на вказівник, що
зберігає два посилання – на таблицю методів і на дані об’єкта. Можливі й
інші подання.
Java-машина є 32-бітною. Більш довгі значення (long, double)
представляються як пари чотирьохбайтових величин. Не обмовляється, у
якому порядку розташовуються елементи пари; більше того, верифікатор
байт-кодів зобов’язаний виявляти й відкидати програми, що намагаються
“вручну” встановити довгі значення.
1.4.4 Регістри
В Java-машині повинні підтримуватися наступні регістри:
pc – лічильник команд; вказує на код операції для команди, що буде
виконуватися наступною.
vars – базовий регістр для доступу до локальних змінних поточного
методу.
optop – вказівник на вершину стека операндів. Java-машина є стековою,
тому основна частина команд бере операнди зі стека й туди ж поміщає
результат.
frame – вказівник на структуру, що містить оточення часу виконання.
У свою чергу, оточення часу виконання використовується для реалізації
трьох цілей: динамічного завантаження, повернення з методів й обробки
виняткових ситуацій.
Для забезпечення динамічного завантаження, оточення часу виконання
містить посилання на таблицю символів поточного методу й поточного
класу. Перед початком виконання методу виробляється редагування його
зовнішніх зв’язків (настроювання посилань на зовнішні методи й зовнішні
дані). Подібне настроювання посилань робить згенерований код стійким
стосовно змін у зовнішніх класах.
Для забезпечення нормального повернення з методів виконується
відновлення регістрового оточення методу.
Для обробки виняткових ситуацій Java-машина виконує прохід по стеку
викликів методів і відшукує саму внутрішню конструкцію catch, що
обробляє вийняткову подію.
У принципі оточення виконання може містити додаткову інформацію,
необхідну, наприклад, для налагодження, але в специфікаціях Java-машини
це залишено на розсуд авторів реалізації.
1.4.5 Вказівники
Найбільша новина для тих, хто раніше програмував на С, а тепер зайнявся
вивченням Java, це те, що в мові Java немає вказівників. Традиційно
вважалося, що працювати з вказівниками важко, а їхнє використання
приводить до появи помилок, що виявляють важко. Тому розроблювачі Java
вирішили відмовитися від використання вказівників зовсім.
Якщо потрібно передати посилання на змінну базового типу, такого,
наприклад, як int або long, то нічого не вийде – змінні базових типів
передаються за значенням, а не по посиланню. Тому не можна прямо
створити мовою Java еквівалент наступної програми, складеної мовою С:
// Деяка змінна
int nSomeValue;
// Функція, що змінює значення змінної,
// заданою своєю адресою
void StoreValue(int *pVar, int nNewValue)
{
pVar->nNewValue;
}
. . .
StoreValue(&nSomeValue, 10);
Вихід, однак, є.
Мова Java дозволяє використати замість вказівників посилання на об’єкти.
Користуючись цими посиланнями, ви можете адресувати об’єкти по їхньому
імені, викликаючи методи й змінюючи значення даних об’єктів.
Що ж стосується даних базових типів, якщо вам потрібно передавати на них
посилання, та варто замінити базові типи на відповідні класи, що
заміщаються. Наприклад, замість типу int використайте клас Integer,
замість типу long – клас Long і так далі.
Ініціалізація таких об’єктів повинна виконуватися за допомогою
конструктора, як це показано нижче:
Integer nSomeValue;
nSomeValue = new Integer(10);
Перший рядок створює неініціалізоване посилання з ім’ям nSomeValue і
типом Integer. При спробі використання такого посилання виникне
виключення.
Другий рядок створює об’єкт класу Integer, викликаючи конструктор. Цей
конструктор визначає початкове значення. Після виконання оператора
присвоювання посилання nSomeValue буде посилатися на реальний об’єкт
класу Integer й її можна буде використати.
Ім’я об’єкта nSomeValue типу Integer ви можете передавати функціям як
параметр, причому це буде посиланням на об’єкт.
Створюючи програми мовою С, часто використалися вказівники для адресації
елементів масивів, створених статично або динамічно в оперативній
пам’яті. Знаючи початкову адресу такого масиву й тип елементів, що
зберігаються в ньому, ви могли адресуватися до окремих елементів масиву.
У мові Java реалізований механізм масивів, що виключають необхідність
використання покажчиків.
1.4.6 “Збір сміття”
Одна з найцікавіших особливостей мови програмування Java і середовища
виконання додатків Java полягає в наявності спеціального процесу збору
сміття, призначеного для видалення непотрібних об’єктів з пам’яті. Ця
система рятує програміста від необхідності уважно стежити за
використанням пам’яті, звільняючи непотрібні більше області.
Створюючи об’єкти в Java, ви можете керуватися принципом “створи й
забудь”, тому що система збору сміття подбає про видалення ваших
об’єктів. Об’єкт буде вилучений з пам’яті, як тільки на нього не
залишиться ні одного посилання з інших об’єктів.
Пріоритет процесу зборки сміття дуже низький, тому “збирання” середовища
виконання додатків Java не віднімає ресурси в самих додатків. Для
створення об’єктів під час виконання виділяється область динамічної
пам’яті. Мова Java розрахована на те, що цю область обслуговує збирач
сміття, оскільки в мові немає засобів для звільнення пам’яті. Як саме
працює збирач сміття, визначається реалізацією Java-машини.
1.4.7 Система команд JAVA-машини
Команда Java-машини складається з однобайтового коду операції, за яким
ідуть операнди (якщо такі є). Можна виділити наступні групи команд:
команди завантаження констант і змінних у стек операндів. Для кожного
типу даних є свої команди завантаження. Наприклад, команда з кодом
операції dload й операндом, що задає зсув, завантажує в стек з локальної
змінної речовинне число подвійної точності, а команда aload робить те ж
для посилання на об’єкт.
команди запам’ятовування даних зі стека в локальні змінні.
команди керування масивами. Наприклад, команда newarray з операндом, що
задає тип елементів, витягає зі стека необхідний розмір масиву, створює
його й поміщає в стек посилання на масив. Відзначимо, що для створення
масивів з елементами-об’єктами служить інша команда, anewarray. За
рахунок подібної спеціалізації досягається ефективність інтерпретації
Java-програм.
команди роботи зі стеком. До цієї групи ставляться команди, які
видаляють, дублюють, міняють місцями верхні елементи стека операндов, а
також виконують інші, більше складні маніпуляції зі стеком.
арифметичні команди. Операнди витягаються зі стека; туди ж поміщають
результат.
логічні команди (зміщення, і, або, що виключає або).
команди перетворення до іншого типу.
команди передачі керування. Наприклад, у команді jsr (перехід на
підпрограму) операндом служить відносна адреса переходу; адреса команди,
що випливає за jsr, міститься на вершину стека операндов. Є команди для
реалізації перемикачів.
команди повернення з функції. Для повернення результатів різних типів
використаються команди з різними кодами операції. Крім того, є команда
breakpoint, що зупиняє нормальний хід виконання й передає керування
оброблювачеві цієї події.
команди маніпулювання з полями об’єктів (установити/ прочитати
звичайне/статичне поле).
команди виклику методів. Їх чотири. Команда invokevirtual викликає
(віртуальний) метод на основі аналізу інформації часу виконання. Команда
invokenonvirtual здійснює виклик на основі інформації часу компіляції –
наприклад, виклик методу батьківського класу. Команда invokestatic
викликає статичний метод класу. Нарешті, команда invokeinterface
викликає метод, представлений інтерфейсом. Виконання всіх перерахованих
команд зв’язано не тільки з передачею керування, але й з аналізом
різного роду таблиць.
команда порушення виняткової ситуації – athrow.
інші об’єктні операції (створити об’єкт, перевірити тип об’єкта).
команди синхронізації (увійти в критичний інтервал, вийти з нього).
Звідси видно, що не існує семантичного розриву між мовою Java й
Java-машиною. Це важливо для компактності скомпільованих Java-програм і
для забезпечення високої швидкості трансляції.
1.5 Взаємодія з серверами баз даних – JDBC
JDBC (Java DataBase Connectivity) – набір класів і методів, які
використовуються у мові програмування Java для роботи з базами даних.
JDBC забезпечує прості, універсальні й добре адатуємі засоби взаємодії з
різними СУБД.
Інтерфейси JDBC, розроблені корпорацією Sun, забезпечують виконання всіх
стандартних операцій з базами даних SQL, а розробники PostgreSQL надають
конкретну реалізацію цих інтерфейсів. Реалізація робить всю взаємодію з
базою даних: підключення, реєстрацію, виклик збережених процедур і т.д.
Інтерфейси спроектовані таким чином, що програма, що використовує JDBC,
може підключитися до будь-якої JDBC-сумісної бази даних без модифікації
коду. Втім, при цьому все-таки необхідно враховувати деякі обставини.
По-перше, JDBC не виконує лексичного аналізу або перевірки синтаксису
SQL на стороні клієнта. Команди просто передаються базі даних незалежно
від їхньої правильності. Таким чином, якщо код SQL працює в одній СУБД,
але не підходить для іншої, реалізація не буде знати про це до моменту
фактичного втановлення з’єднання й пересилання коду SQL. У цей час Sim
намагається вирішити цю проблему. Можливо, що відповідні зміни будуть
внесені в наступні версії JDBC або з переходом на інший стандарт.
По-друге, у реалізацію включаються додаткові класи, специфічні для
конкретного продукту. Наприклад, в PostgreSQL є розширення для
геометричних типів даних. Вони існують тільки в PostgreSQL і не
підтримуються іншими фірмами. Якщо ви використаєте ці спеціалізовані
класи, програма не буде працювати в інших JDBC-сумісних базах даних.
Одне з переваг драйвера JDBC для PostgreSQL полягає в тім, що він є
драйвером «четвертого типу». Це означає, що він написаний на «чистій»
мові Java, що дозволяє перенести його куди завгодно й використати на
будь-якій платформі з підтримкою TCP/IP, оскільки драйвер підключається
тільки через TCP/IP.
1.5.1 Використання JDBC
Класи JDBC представляють основні компоненти взаємодії програми з SQL. У
всіх основних класів JDBC – Connection, Statement, ResultSet, Blob й
Clob – є прямі аналоги в SQL. Крім того, в JDBC включені допоміжні класи
– наприклад, класи ResultsSetMetaData й DatabaseMetaData призначені для
роботи з метаданними. Зокрема, вони використаються для одержання
інформації про можливості бази даних, для перевірки типу результату
запитів, у процесі налагодження й просто в ситуаціях, коли ви не маєте
інформації про дані, з якими працюєте.
Інтерфейс JDBC в PostgreSQL також містить класи для роботи з
нестандартними розширеннями PostgreSQL. До їхнього числа ставляться
Fastpath, геометричні типи, більші об’єкти й класи, що спрощують
сериалізацію об’єктів Java у базі даних.
1.5.2 Принципи використання JDBC
Для створення фізичного підключення до бази даних використовується
об’єкт Connection, що представляє фізичне підключення до бази даних.
Об’єкт Connection потрібно для створення об’єктів Statement, за
допомогою яких в JDBC базі даних передаються команди SQL.
Існує три різновиди об’єктів Statement: базовий клас Statement, класи
PreparedStatement і CallableStatement.
Statement s = c.createStatement():
Тут створюється об’єкт класу Statement з ім’ям s для об’єкта Connection
з ім’ям с. Далі створений об’єкт Statement може використатися для
виконання запитів до бази даних.
У класі Statement особливо важливі два методи. Перший, executeQuery,
одержує один аргумент (код виконуваної команди SQL) і повертає об’єкт
класу ResultSet, про яке мова йтиме нижче. Метод executeQuery
призначений для виконання команд, що повертають набори даних, наприклад
запитів SELECT. Об’єкт, що повертає, ResultSet представляє дані,
отримані в ході запиту.
Приклад вибірки даних з бази даних
Statement s = nul 1: try {
s = c.createStatement;
} catch (SQLException se) {
System.out.printlnC’We got an exception while creating a statement:” +
“that probably means we’re no longer connected.”):
se.printStackTrace();
System, exit(l);
}
ResultSet rs = null:
Try {
rs = s.executeQuery(“SELECT * FROM books”);
} catch (SQLException se) {
System.out.printlnC’We got an exception while executing our query:” +
“that probably means our SQL is invalid”):
se.pnntStackTrace():
System.exit(l):
}
int index = 0:
try {
while (rs.next) {
System.out.printlnC’Here’s the result of row ” + index++ + “:”):
System.out.pri ntln(rs.getStri ng(1)):
}
} catch (SQLException se) {
System.out.pnntlnC’We got an exception while getting a result:this ” +
“shouldn’t happen: we’ve done something really bad.”);
se.pnntStackTrace();
System.exit(l):
}
Спочатку ми створюємо об’єкт Statement, а потім використовуємо метод
executeQuery цього об’єкта для виконання запиту SELECT * FROM books.
Повернутий запитом об’єкт ResultSet використовується для виводу
отриманої інформації.
Об’єкт ResultSet надає основний інтерфейс вибірки з бази даних. Він
володіє двома основними можливостями: можливістю послідовного перебору
отриманих записів і можливістю повернення значення заданого поля
поточного запису. Принцип перебору такий же, як у стандартних
перерахуваннях Java: ви починаєте перебір у позиції перед першим
елементом і послідовно переходите до наступного елемента методом next.
Метод next повертає true у тому випадку, якщо об’єкт ResultSet успішно
перейшов до наступного запису (тобто в підсумковому наборі ще залишилися
неопрацьовані записи). Цикл while виводить значення першого поля кожної
із записів, що повертають. Якщо підсумковий набір не містить ні одного
запису, перші ж виклики next поверне fal se і програма нічого не виведе.
Клас ResultSet може повертати значення різних типів. У прикладі, перше
поле інтерпретується як рядок (Stri ng). На щастя, всі стандартні типи
даних SQL можуть бути представлені в строковому виді, тому незалежно від
типу даних ви завжди зможете одержати значення першого поля й вивести
його. Клас ResultSet містить безліч інших методів, включаючи методи
вибірки для всіх типів даних SQL і перетворення їх до типів Java. За
додатковою інформацією звертайтеся до опису ResultSet у документації
API.
Інший важливий метод, executeUpdate, теж викликається з одним аргументом
– виконуваною командою SQL. executeQuery та executeUpdate відрізняються
тим, що метод executeUpdate призначений для виконання команд, що
змінюють стан даних у базі. Наприклад, при виклику executeUpdate для
команди CREATE, INSERT або UPDATE повертається число типу int, що
визначає кількість модифікованих записів.
Statement s – null: try {
s = c.createStatement():
} catch (SQLException se) {
System.out.printlnC’We got an exception while creating a statement:” +
“that probably means we’re no longer connected.”):
se.printStackTrace();
System.exlt(1):
}
int m = 0;
try {
m = s.executeUpdate1 INSERT INTO books VALUES ” +
“(41472. ‘Practical PostgreSGl’. 1212. 4)”): >
} catch (SQLException se) {
System.out.println(“We got an exception while executing our query:” +
“that probably means our SQL is invalid”): >
se.printStackTrace():
System.exit(l):
}
System.out.println(“Successfully modified ” + m + ” rows.\n”):
3.4 Нетривіальні можливості JDBC
Як згадувалося вище, крім базового об’єкта Statement в JDBC існує два
інших типи об’єктів для подання команд: PreparedStatement й Cal
lableStatement. Вони будуть описані нижче.
У даному підрозділі також буде розказано про об’єкти ResultsSetMetaData
й DatabaseMetaData. З їхньою допомогою можна запросити в JDBC опис
результатів запиту або бази даних. Можливість одержання такої інформації
на стадії виконання програми дозволяє динамічно виконувати команди SQL –
навіть такі, параметри яких були невідомі на момент написання програми.
Об’єкт CallableStatement.
Об’єкт CallableStatement дозволяє виконувати збережені процедури в
JDBC-co-містких базах даних. Кращим джерелом інформації із цього питання
є сайт Sun Javasoft (http://java.sun.com/products/jdbc/), оскільки
стандарт викликуваних команд (callable statements) змінюється й
розвиваються і його практичні застосування залежать від версії Java й
JDBC.
Об’єкт PreparedStatement
Об’єкт PreparedStatement представляє підготовлені (prepared) команди
SQL, багаторазово виконувані з різними вихідними даними – наприклад,
якщо вам треба було вставити в таблицю кілька записів, одну за іншою.
Головна перевага PreparedStatement полягає в тім, що команда проходить
попередню компіляцію, що рятує від витрат на повторну обробку команд SQL
при кожнім виконанні.
PreparedStatement ps = null;
try {
ps = c.prepareStatementC’INSERT INTO authors VALUES (?. ?. ?)”);
ps.setlntd. 495);
ps.setString(2. “Light-Williams”);
ps.setString. “Corwin”);
} catch (SQLException se) {
System.out.println”We got an exception while preparing a statement:” +
“Probably bad SQL.”);
se.printStackTrace();
System.exit(l);
}
try {
ps.executeUpdate();
} catch (SQLException se) {
System.out.printlnC’We got an exception while executing an update:” +
“possibly bad SQL. or check the connection.”);
se.pnntStackTrace();
System.exit(l);
}
Як видно з лістингу, підготовлена команда виглядає цілком звично, хіба
що всі змінні величини заміняються в ній знаками питання (?).
Присвоювання виконується методами класу PreparedStatement (setlnt,
setString і т.д.). Вибір методу для кожного поля залежить від типу даних
цього поля.
Об’єкти PreparedStatement зручні тим, що вони забезпечують автоматичне
перетворення типів даних Java у типи SQL. Наприклад, при переході до
типу text вам не потрібно турбуватися про екранування символів або
лапках.
Зверніть увагу: перший аргумент методу set ідентифікує номер позиції
змінної (знаку питання), що привласнюється значення. Одиниця означає
перший знак питання, двійка – другої й т.д.
Інша сильна сторона PreparedStatement пов’язана з тим, що об’єкт можна
знову й знову використати з новими даними, не створюючи нового об’єкта
Statement для кожного набору параметрів. Звичайно, такий підхід більше
ефективний, оскільки він обмежується створенням одного об’єкта, а нові
значення змінних задаються методами set.
ResultSetMetaData
В JDBC можна запросити докладну інформацію про підсумковий набір запиту.
Клас ResultsSetMetaData повертає опис об’єкта ResultSet, отриманого при
виклику executeQuery. У ньому міститься інформація про кількість полів,
типі даних, іменах полів і т.д.
Із всіх методів класу ResultSetMetaData найчастіше використаються методи
getColumnName й getColumnTypeName. Вони повертають відповідно ім’я поля
й ім’я його типу даних у вигляді значення типу String.
3.5 Використання JDBC 363
Навіть якщо відволіктися від міркувань ефективності, механізм
PreparedStatement набагато надійніше підготовки декількох команд в
об’єктах Statement.
ResultSetMetaData rsmd = null;
try {
rsmd = rs.getMetaData();
} catch (SQLException se) {
System.out.printlnC’We got an exception while getting the metadata:” +
“check the connection.”);
se.printStackTrace();
System.exit(l);
}
String columnName = nul;.
columnType = null;
try {
columnName = rsmd.getColumnName(1);
columnType – rsmd.getColumnTypeName(l);
} catch (SQLException se) {
System.out.printlnC’We got an exception while getting the column name:”
+ “check the connection.”);
se.printStackTrace();
System.exit(l);
}
System.out.print(“‘The name of the first column is: ‘”);
System.out.print(columnName);
System.out.prin(“The data type of the first column is: “);
System.out.println(columnType);
Клас ResultSetMetaData містить багато інших корисних методів. Описи
наведені в документації JDK API.
DatabaseMetaData
Нарешті, клас DatabaseMetaData призначений для одержання інформації про
базу даних, з якої ви працюєте. Зокрема, він дозволяє одержати відповідь
па перераховані нижче питання.
Які каталоги присутні в базі даних?
З яким типом бази я працюю?
Під яким ім’ям користувача я працюю з базою даних?
DatabaseMetaData dbmd = null;
try {
dbmd = c.getMetaData();
} catch (SQLException se) {
System.out.printlnC’We got an exception while getting the metadata:” +
” check the connection.”);
se.printStackTrace();
System.exit(l);
}
String username = null;
Try {
username = dbmd.getUserName();
} catch (SQLException se) {
System.out.printlnC’We got an exception while getting the username:” +
“check the connection.”); se.printStackTrace;
System.exit(l);
}
String url = null;
Try {
url = dbmd.getURL();
} catch (SQLException se) {
System.out.printlnC’We got an exception while getting the URL:” + “check
the connection.”);
se.printStackTrace();
System.exit(l);
}
System.out.printlnC(‘”You are connected to ‘” + url +
‘” with user name ‘” + username + …..);
Як було сказано вище, кращим джерелом інформації про інші методи
DatabaseMetaData є документація JDK API.
1.4 Робота з запитами в MS Access
Програмне забезпечення для роботи з базами даних використовується на
персональних комп’ютерах досить давно. Взагалі, база даних – це набір
записів і файлів, які організовані спеціальним чином. В комп’ютері,
наприклад, можна зберігати прізвища і адреси друзів або клієнтів.
Можливо, зберігати всі свої листи, і вони згруповані по адресатам, або
набір файлів з даними по фінансовим справам: отримані або виставлені
рахунки, витрати по чековій книжці або балансам. Один з типів баз даних
– це документи, які набрані за допомогою текстових редакторів і
згруповані за темами. Другий тип – файли електронних таблиць, які
об’єднані в групи по характеру їх використання. Щоб керувати даними, які
розкидані по сотням таблиць і файлів використовуються системи керування
базами даних (СКБД). Microsoft Access 97 саме є такою системою. Майже
всі сучасні системи побудовані на реляційній моделі керування базами
даних. Назва “реляційна” пов’язана з тим, що кожний запис в такій базі
даних має інформацію, яка відноситься тільки до одного конкретного
об’єкту. В реляційній СКБД всі дані представлені в вигляді таблиць.
Інформація про об’єкти визначеного виду представляється в табличному
вигляді – в стовпчиках таблиці містяться різні характеристики об’єктів –
атрибути (наприклад, адреси клієнтів), а рядки призначені для опису
величин всіх атрибутів окремого об’єкта (наприклад, дані про конкретного
клієнта). В випадку, коли використовуються функції СКБД для вибору
інформації з однієї або декількох таблиць (виконується запит, що є темою
даної дипломної роботи), результат представляється у вигляді таблиці.
Більше того, можна виконати запит із використанням результатів іншого
запиту. Можна об’єднати інформацію з декількох таблиць або запитів.
Система керування базами даних дає можливість контролювати структуру і
опис даних, роботу з ними і організацію колективного користування
інформацією. СКБД також суттєво збільшує можливості і полегшує
каталогізацію і ведення великих об’ємів інформації, яка зберігається в
численних таблицях. СКБД включає в себе три основних типа функцій:
визначення даних, їх обробка й керування даними. Усі ці функціональні
можливості в повній мірі реалізовані в Microsoft Access.
В базі даних Access основними об’єктами є таблиці, запити, форми, звіти,
макроси і модулі. Таблиця – об’єкт, який використовується для збереження
даних. Таблиця складається з полів (стовпчиків), в яких зберігаються
різні дані, і записів (рядків). В записи зібрана вся інформація про
деякий об’єкт. Запит – об’єкт, який дозволяє користувачу отримати
потрібні дані з одної або декількох таблиць. Для створення запиту можна
використовувати бланк QBE(запит по зразку) або інструкцію SQL. Можна
створювати запити на вибірку, поновлення, видалення або додавання даних.
За допомогою запитів також можна створювати нові таблиці, використовуючи
дані з одної або декількох існуючих таблиць. Форма – об’єкт, призначений
в основному для вводу даних, відображення їх на екрані або керування
роботою додатку. Звіт – об’єкт, призначений для створення документа,
який в подальшому може бути роздрукований або включений в документ
іншого додатку.
1.5.1 Створення запитів на вибірку
Запити дають широкі можливості для вибору, сортування і обчислення з
використанням даних однієї таблиці. Дуже важливо вміти використовувати
дані з пов`язаних таблиць, допомагає будувати багатотабличні запити
майстер запитів.
Запит на вибірку можна використовувати не тільки для відбору даних, але
і для їх поновлення. Запит на вибірку має ряд властивостей, які можна
використовувати для зміни роботи запиту.
В режимі таблиці доступні самі різні операції з даними – огляд,
сортування, фільтрація, поновлення і друк. Але достатньо часто
приходиться проводити обчислення і огляд даних з декількох таблиць.
Відобразити потрібні дані можна за допомогою запитів.
Після виконання запита на вибірку (який відбирає інформацію з таблиць і
інших запитів бази даних, в той час як при виконанні запиту на зміну
дані вставляються, поновлюються або видаляються) Microsoft Access
створює набір записів, які містять відібрані дані. В більшості випадків
з набором записів можна працювати так само, як з таблицею: можна
проглянути і відібрати інформацію, роздрукувати і поновити дані. Але на
відміну від реальної таблиці, цей набір записів фізично не існує в базі
даних. Access створює набір записів з даних таблиць тільки під час
виконання запиту. Якщо змінити дані в наборі записів, Access внесе
відповідні зміни в таблицю, на базі яких побудований запит.
При вивченні форм і звітів виявляється, що запити є найкращим способом
виділення даних, необхідних для вирішення визначеного завдання. Запити
можуть слугувати джерелами даних таких елементів керування, як список і
поле зі списком, що спрощує введення даних.
Щоб відкрити вікно нового запиту в режимі конструктора, і вікні бази
даних потрібно перейти на вкладку Запросі натиснути кнопку Создать, яка
міститься з правого боку від списку запитів. Access відкриє вікно
діалогу Новый запрос. В нас є вибір: створити запит самостійно в режимі
конструктора або скористатися допомогою майстра для створення одного з
декількох типів запитів. Щоб відкрити існуючий запит в режимі
конструктора, треба виділити його ім`я на вкладці Запросі натиснути
кнопку Конструктор. Запит відкривається в режимі Конструктор. В верхній
частині вікна запиту знаходяться списки полів (назви стовпчиків
таблиці), в нижній частині – бланк запиту.
1.5.2 Вибір даних з однієї таблиці
Одна з переваг запитів є те, що вони дозволяють достатньо швидко
відібрати необхідні дані з декількох пов’язаних таблиць. Але запити
корисні і при роботі з одною таблицею. Всі методи, які використовуються
для роботи з єдиною таблицею, підходять і для складних багатотабличних
запитів.
Найкраще за все створити запит на основі одної таблиці так: відкрити
вікно бази даних, вибрати потрібну таблицю, розкрити список кнопки
Новыйобъектна панелі інструментів і вибрати пункт Новый запрос і
натиснути кнопку ОК (якщо рядок Имя таблицыне виводиться в бланку
запиту, слід вибрати команду Вид/Имена таблиц). Відкривається вікно
конструктора, воно розділене на дві частини (мал. 1). В верхній частині
знаходяться списки полів таблиць або запитів, на підставі яких
створюється новий запит. В нижній розміщений бланк QBE (Query By Example
– запит по зразку), в якому виконується вся робота по створенню нового
запиту. Кожний стовпчик бланку представляє одне поле, яке
використовується в запиті. Поле може просто належати одній з таблиць,
бути обчислюваним (його значення розраховується на основі одного або
декількох полів таблиці), або підсумковим, яке використовує одну із
вбудованих функцій Microsoft Access.
Рисунок 7. Вікно бланка запиту
Полям запиту можна надавати імена, які будуть відображатися і заголовках
стовпчиків при виведенні набору записів запиту, а для генерації
обчислюваних полів можна використовувати вирази любого ступеню
складності.
В зв’язку з тим, що була виконана команда Вид/Имена таблиц, в даному
рядку бланка запиту Access виведе ім’я таблиці, з якої вибране поле. В
третьому рядку бланка можна задати, чи потрібно виконувати сортування по
вибраному або обчислюваному полю.
Прапорці в бланку Вывод на екран відповідають за вивід на екран полів в
наборі записів. По замовчуванню Access виводить на екран всі поля, які
містить бланк запиту. Але деякі поля включаються в запит тільки для
відбору потрібних записів, а виводити їх на екран зовсім не обов`язково.
Щоб виключити таке поле з набору записів, треба зняти його прапорець в
рядку Вывод на екран.
Для введення умов відбору записів використовується рядок Условиеотбора і
рядок или.
Першим кроком при створенні запиту є вибір полів, які включаються в
набір записів. Це можна зробити, просто перетягнувши поле в потрібний
стовпчик бланка зі списку полів в верхній частині вікна. При
перетягуванні поля вказівник мишки перетворюється в маленький
прямокутник.
Якщо потрібно включити в запит всі поля таблиці, то достатньо
перетягнути значок “*” зі списку полів в бланк QBE.
Інший спосіб ввести в запит всі поля таблиці – це двічі клацнути на
заголовку списку полів в верхній частині вікна: таким чином виділяються
всі поля таблиці. Потім перетягнути виділені поля в рядок Поле бланка
запиту. Вказівник миші перетвориться в значок з зображенням декількох
прямокутників, який показує, що перетягуються декілька полів. Коли
відпускається кнопка миші, Access помістить в бланк запиту всі поля
таблиці.
1.5.3 Встановлення властивостей полів
В загальному випадку поля, які виводяться в наборі записів запиту,
наслідують властивості для відповідних полів таблиці. Можна задати інші
значення наступних властивостей: Описание(інформація, яка виводиться в
рядку стану вікна запита в режимі таблиці, коли поле стає поточним),
Формат поля (представлення даних на екрані), Число десятичных знаков
(для числових даних), Маска ввода і Подпись (заголовок стовпчика).
Щоб задати властивості деякого поля, потрібно клацнути на любій чарунці
відповідного стовпчика в бланку запита і натиснути кнопку Свойства на
панелі інструментів або вибрати команду Вид/Свойства.
1.5.4. Введення умов відбору
Якщо потрібно відібрати записи з конкретним значенням поля, треба ввести
його чарунку Условие отбора цього поля. Текстове значення, яке
використовується в якості умови відбору, повинне бути вміщене в лапки.
В випадку, якщо нас цікавить декілька значень, вводяться в рядок Условие
отбора і розділяються логічним оператором OR.
Коли вводяться умови відбору для декількох полів, то всі вирази в
рядку Условие отбора або в рядку илиповинні приймати значення Істина
для любого запису, який включається в набір записів запиту. Це означає,
що Access виконує логічну операцію AND над умовами відбору, які
знаходяться в одному рядку. Щоб результат операції AND мав значення
Істина, умови повинні бути істинними; тільки в цьому випадку запис
відбирається запитом. Наприклад, ми вибираємо записи з таблиці, в якій
знаходяться дані про робітників. Умовою відбору обрано поле Загальний
стаж і його значіння:
>10 AND <20
Це означає, що будуть відібрані тільки ті записи (з даними про
робітників) значення яких відповідає обом умовам в рядку Условие
отбора (стаж більше 10 років, але не перевищує 20). Всі інші записи в
таблицю запиту не попадуть.
Коли задаються для деякого поля декілька умов відбору, які з’єднані
логічним оператором OR, то для того, щоб запис був відібраний запитом,
істинним повинна бути хоча б одна з них. Є два способи задати декілька
пов’язаних оператором OR умов для одного поля. Можна ввести всі умови в
одну чарунку рядка Условие отбора і з’єднати їх оператором OR.
Наприклад, з таблиці про поставників продукції запис в чарунці Условие
отбора:
“Київ” OR “Вінниця”, означає, що будуть відібрані всі записи про
поставників, що знаходяться в містах Київ і Вінниця.
Інший варіант: введення кожної умови в окрему чарунку рядка или. При
використанні декількох рядків илидля відбору запису достатньо виконання
всіх умов в одному з рядків или.
¬
„`
2
$
h
j
l
????H?H???l
c
¤
¦
?
?
¬
®
°
e
e
i
i
–
R
T
V
Z
\
^
`
b
d
?
?
c
?
O
O
j;
j/
j
2
·d·f·?·–·AE·E·a·ae·e·:? IN(“Київ”,“Вінниця”) означає те саме, що і вираз “Київ” OR “Вінниця”.
LIKE. Оператор, корисний для пошуку зразків в текстових полях. В зразок
пошуку можна включити символи шаблона, “?” заміняє любий символ в даній
позиції, а “*” означає любу кількість символів в даній позиції. Символ
“#” вказує, що в даній позиції повинна бути цифра.
1.5.5 Умови відбору для дат і часу
Microsoft Access зберігає значіння дат і часу як числа з плаваючою
комою і з подвійною точністю. Значіння з лівого боку від десяткової коми
відповідає даті, а дробова частина числа представляє час доби.
Щоб повідомити Access про те, що вводиться дата і час, значення
вміщується в символи числа (#). Наприклад, #10 Квітень 2003# і
#10/04/03# визначають одну і ту саму дату.
Access дає декілька функцій, які можна використовувати при завданні
умов відбору для дат і часу:
Day(дата). Повертає значення дня місяця в діапазоні від 1 до 31.
Month(дата). Повертає значення місяця року в діапазоні від 1 до 12.
Year(дата). Повертає значення року в діапазоні від 100 до 9999.
Weekday(дата). Повертає значення чисел від 1 (Неділя) до 7 (Субота),
які відповідають дням тижня.
Hour(дата). Повертає ціле число від 0 до 23, які представляють значення
часу.
DatePart(інтервал, дата). Повертає номер кварталу або номер тижня в
залежності від того, який код інтервалу задається (“q” – для визначення
кварталу, “ww” – для визначення порядкового номера тижня в році).
Date(). Повертає поточну системну дату.
Використання параметрів запиту
До сих пір ми вводили умови відбору безпосередньо в бланк запиту в
режимі конструктора. Але на етапі створення запиту на завжди можна
визначити, які значіння повинен відшукувати Access. Потрібно включити в
запит параметр, і при кожному виконанні запиту Access буде вимагати
конкретні умови відбору.
Щоб визначити параметр, потрібно ввести в рядок Условие отборазамість
конкретного значення ім’я або фразу, яка вміщена в квадратні дужки. Те,
що вміщене всередині квадратних дужок, Access розглядає як ім’я
параметра. Воно виводиться в вікні діалогу при виконанні запиту, тому в
якості імені параметра розумно використовувати змістовну фразу. В одному
запиті можна задати декілька параметрів, при цьому ім’я кожного
параметру повинно бути унікальним і інформативним.
Для кожного параметра запиту можна вказати тип даних. Access
використовує цю інформацію для перевірки введеного значення. Наприклад,
якщо визначено параметр як числовий, Access відкине літерні символи в
значенні параметра. З мовчазної згоди Access надає параметрам запиту
текстовий тип даних. Якщо потрібно змінити тип даних, треба вибрати
команду Запрос/Параметры, і Access виведе на екран вікно діалогу
Параметры запроса. В цьому вікні діалогу вводиться ім’я кожного
параметра, тип якого ми хочемо визначити, в стовпчик Параметрв такому
вигляді, в якому воно було вказане в бланку запиту, але без квадратних
дужок. В стовпчику Тип данныхтреба встановити потрібний тип даних, який
вибирається зі списку, що розкривається. Після визначення всіх
параметрів натискаємо кнопку ОК.
При виконанні запиту Access попросить ввести почергово значення для
кожного з параметрів, використовуючи вікно діалогу.
1.5.6 Багатотабличні запити
Розглянувши можливості запитів, які основані на одній таблиці, на базі
отриманих знань легко організувати перегляд об’єднаних даних з декількох
пов’язаних таблиць. Здатність запитів відбирати дані з декількох таблиць
особливо корисна при створенні форм і звітів.
Розглянемо приклад, в якому об’єднується інформація з двох таблиць. В
вікні бази даних треба перейти на вкладку Запросыі натиснути кнопку
Создать. В вікні діалогу Новый запросвибрати Конструкторі натиснути
кнопку ОК. Access відкриє вікно нового запиту в режимі конструктора і
виведе на екран вікно діалогу Добавление таблицы. Вікно діалогу дозволяє
вибрати таблиці і запити, які будуть базовими для нового запиту.
Вибираються дві таблиці і закривається вікно.
Якщо зв’язок між базовими таблицями був раніше визначений, то верхня
частина вікна запиту в режимі конструктора буде виглядати так, як
показано
Рисунок 8. Конструктор запиту
на мал. 2. Access пов’язує використовувані в запиті таблиці на основі
інформації про зв’язок, яка задана при їх створенні. Access зв’язок в
вигляді лінії, яка з’єднує первинний ключ одної таблиці з відповідним
полем іншої. Якщо зв’язок між таблицями не визначений, Access сам
прийме рішення, встановивши зв’язок між полями з однаковими іменами і
співпадаючими типами даних.
Користувач включає в бланк запиту необхідні поля з двох таблиць.
Побачити результат запиту можна, переключившись у режим таблиці.
Як уже згадувалося, вікні режиму таблиці можна виконувати з набором
записів запиту майже всі дії, які доступні для звичайних таблиць.
Одним з найцікавіших аспектів багатотабличних запитів є можливість зміни
даних вихідних таблиць прямо в наборі записів.
1.5.7 Створення запиту на основі іншого запиту
При створенні запита в режимі конструктора вікно діалогу Добавление
таблицы дозволяє вибрати в якості джерела даних для нового запиту не
тільки таблиці, але і запити. Дійсно, побудова одного запиту на основі
іншого – це ще один спосіб роботи з даними з декількох таблиць: спочатку
створюється один запит, за допомогою якого вирішується визначене коло
задач і відбирається сукупність даних з декількох таблиць, а потім на
його основі будується інший для отримання кінцевого набору записів.
Використання майстра запитів
1.
Рисунок 9. Діалогове вікно Новый запрос
В вікні бази даних перейти на вкладку Запросыі натиснути кнопку Создать.
2. В діалоговому вікні Новыйзапросвибрати майстра Простой запрос
(Рисунок 9). Натиснути ОК.
В діалоговому вікні (Рисунок 10), що з’явилося, вказати ім’я таблиці або
запита, на якому буде збудований новий запит. Потім вибрати поля, з яких
повинні бути відновлені дані.
Рисунок 10. Створення простого запиту
Якщо необхідно, вказати додаткові таблиці або запит, а потім вибрати з
них поля, які повинні бути використані.
4. Закінчивши роботу в цьому діалоговому вікні, натиснути ОК.
Потрібно слідувати інструкціям, які виникають в наступних діалогових
вікнах майстра. В останньому діалоговому вікні користувачу пропонується
вибір виконати запит або продивитися його структуру в режимі
конструктора. Якщо отриманий запит не відповідає вимогам, можна знову
звернутися до майстра або внести зміну в запит в режимі конструктора.
Відкриття, копіювання, збереження, перейменування і видалення запитів
Користувач може відкрити в режимі конструктора різні запити: запит на
вибірку, перехресний запит і запит на зміну. Запит на вибірку і
перехресний запит також можна відкрити в режимі таблиці для огляду
результатів.
Можна створити ярлик для відкриття об’єкта бази даних, яка знаходиться
або на комп’ютері користувача, або на файловому сервері мережі або в
директорії для спільного доступу. В Microsoft Windows можна створити
ярлик, перемістивши за допомогою миші об’єкт з вікна бази даних в
робочий стіл або папку. Інший спосіб – клацнути правою кнопкою миші
потрібний об’єкт (запит, наприклад) і вибрати команду Создать ярлык.Щоб
створити ярлик не на робочому столі, треба ввести новий шлях в поле
Размещение.
Для копіювання вибирається об’єкт і натискається кнопка Копироватьна
панелі інструментів. Під час копіювання об’єкта в іншу базу даних,
закривається поточна база і відкривається та, в яку потрібно вставити
об’єкт. При відкритому вікні бази даних натиснути кнопку Вставитьна
панелі інструментів.
Збереження запиту відбувається шляхом натискання кнопки Сохранитьна
панелі інструментів.
Для збереження копії об’єкта бази даних з новим ім’ям або в іншому
файлі, при умові що об’єкт відкритий або виділений, потрібно вибрати
команду Сохранить как/Экспортв меню Файл. Щоб зберегти об’єкт в поточній
базі даних, треба вибрати параметр В текущей базе данныхв діалоговому
вікні Сохранение объекта, ввести ім’я об’єкта і натиснути ОК.
Для перейменування запита потрібно впевнитися, що об’єкт бази даних
закритий. Далі в вікні бази даних вибрати вкладку Запросы, яка містить
потрібний об’єкт. Натиснути кнопку миші на імені об’єкта, а потім знову
натиснути кнопку миші, щоб змінити ім’я, ввести нове ім’я.
Для видалення об’єкта виділити його і натиснути кнопку Delete.
Оптимізація запитів
Існує ряд способів прискорення виконання запитів:
– Стискати бази даних
– Індексувати поля
– Вибирати типи даних мінімального розміру
– При створенні запиту не додавати лишні поля в запит. Зняти
прапорець Вывод на экран для полів, зміст яких не виводиться в запиті
– Використовувати для умов відбору вирази, які дозволяють
оптимізувати запит
2. МАТЕМАТИЧНО-ІНФОРМАЦІЙНА СИСТЕМА НА ОСНОВІ АРХІТЕКТУРИ
“КЛІЄНТ-СЕРВЕР” TOC \o “1-3” \h \z \u
2.1 Основні поняття формальної моделі
Оглянувши основні проблеми, що постають перед моделюванням розподілених
інформаційних систем (далі ІС) типу клієнт-сервер, перейдемо до
формального опису таких ІС (використовуючи описані вище підходи).
Виходячи з основних принципів опису системи, виділимо основні компоненти
системи – її входи та виходи. Входом системи є множина запитів клієнтів
системи, виходами – множина відповідей системи на запити. У загальному
випадку реакція визначається не лише поточним запитом, а й усіма
попередніми. Для усунення необхідності кожен раз обробляти усі попередні
запити клієнта, вводиться поняття стану інформаційної системи. Стан
інформаційної системи є агрегованою історією запитів до системи. У
системі виділяються окремі страти, тобто вона є багаторівневою і на
кожному рівні міститься не менше однієї автономної підсистеми (яка
фактично є окремою
системою).
На кожному з рівнів (крім верхнього та нижнього) традиційно
розглядається три вхідних потоки – потік зовнішніх збурень, потік
розпоряджень з вищого рівня, потік реакцій нижчого рівня. Перші два
потоки в моделі розподілених інформаційних систем ототожнюються,
оскільки вища система є клієнтом системи нижчого рівня. Отже, запити з
системи вищого рівня, з одного боку, можуть розглядатися як вхідні
збурення, а з іншого – запити страти вищого рівня.
Формальна модель повинна забезпечувати можливість ієрархічного з’єднання
систем. Таке з’єднання базується на спрямуванні вихідного потоку нижчої
системи у вищу систему, що разом з вхідним збудженням складає вхідний
сигнал для вищої системи. У формуванні відповіді сервісу на запит
користувача виділимо такі етапи:
1. отримання запиту від користувача або вищого сервісу;
2. формування запитів до нижчих сервісів;
3. отримання відповідей від нижчих сервісів;
4. формування відповіді на запит.
Аналізуючи ці етапи, відзначимо два моменти:
• якщо розглядати тільки верхній зріз системи, то при його описі
потрібно виділяти як потік запиту користувача так і потік реакцій
підкомпонент;
• в системі в цілому (зі всіма рівнями включно) слід визначати лише один
вхідний потік – запити користувачів (адже відповіді нижчих систем
визначаються запитами вищого сервісу, а отже, вхідними запитами
користувачів).
Деталізація системи проводиться до певного найнижчого рівня. Для функцій
цього рівня розглядаються лише вхідні запити користувача (вищої
системи). Такий підхід узгоджується з тведженням про неістотність опису
вхідних потоків від нижчих систем для системи взагалі. Уся система з
усіма її рівнями розглядається як система найнижчого рівня (адже в ній
завжди можна виділити компоненти найнижчого рівня).
При аналізі поведінки системи модель спрощується завдяки усуненню
параметрів з запитів користувача та реакцій систем. Досліджуючи певні
особливості функціонування системи, можна взагалі усувати або запит
користувача, або вхідний потік від нижчих систем. Досліджуючи систему в
цілому, а не тільки її певний зріз, розглядається лише вхідні запити
користувачів.
При розгляді правил композиції систем та утворення систем внаслідок
застосування до їх компонент певних операцій, враховуємо, що запити до
компонент формуються результуючою системою, а відповіді компонент
направляються до неї для формування остаточної реакції.
2.2 Модель системи
Автоматна модель розподіленої ІС описується традиційним впорядкованим
набором
де Q – вхідні запити ІС, R – відповіді нижчих систем, A – вихідний
алфавіт ІС, St-множина станів системи, ?, ? – функції переходів та
виходів.
Розглянемо детальніше кожен з об’єктів. Множину символів, що складають
вхідний алфавіт системи, опишемо у такий спосіб:
де множина IdQ – множина унікальних ідентифікаторів запитів.
Множину символів, що складають вихідний алфавіт системи, опишемо у такий
спосіб:
де IdA – множина унікальних ідентифікаторів відповідей.
Множину символів, що складають відповіді нижчих систем, опишемо
наступним чином:
де IdR – множина унікальних ідентифікаторів відповідей нижчих систем.
Кожен запит до ІС та її відповідь містить дві частини: ідентифікаційну
та параметричну. Ідентифікаційна – однозначно визначає тип запиту
(наприклад: запит на отримання даних, оновлення, розміщення замовлення
тощо). Параметри є фактично додатковою інформацією, що супроводжує
запити та відповіді на них ІС (наприклад: текст Web-сторінки, вибірка з
бази даних, прайс-лист системи Internet-маркетингу -параметри відповіді,
критерії на вибірку даних, нове замовлення – параметри запиту). Опис
стану системи також базується на аналогічному підході: Загальну схему
конкретного стану St інформаційної системи можна описати так:
Де St1… StNst – стани компонент інформаційної системи.
Таким чином, формальний опис стану ІС має рекурсивний характер (до
певного найнижчого рівня деталізації, на якому стани мають атомарний
характер).
Кожен стан St(i) містить ідентифікатор стану IdSt та стани усіх
підсистем, що належать до ІС. Кількість станів обмежується кількістю
можливих станів підсистем.
Проте реально їх кількість істотно менше внаслідок обмежень та
взаємозв’язків, що можуть існувати між станами системи. Серед таких
обмежень виділимо два основні типи:
• внутрішні стосовно одне одного (типу обмежень на унікальність або
простих обмежень типу Check);
• зовнішні (типу зовнішніх ключів).
Ієрархія станів ІС повинна узгоджуватися та породжуватися відповідною
FHD. Найнижчий рівень деталізації кожної з компонент відповідає
атомарним функціям. Результуючу множину станів ІС можна подати як ERD
цієї ІС. Стосовно ERD станів системи ставиться задачу нормалізації. У
такому випадку систему з нормалізованими станами вважатимемо
нормалізованою. Так параметри станів ІС формують базу даних ІС. Аналіз
формальної моделі клієнт-сервер системи приводить нас до висновку про
принципову схожість класичних інформаційних систем, що будуються на
технологіях баз даних, та систем з архітектурою клієнт-сервер. Фактично,
ми говоримо про узагальнення понять баз даних в моделях
найрізноманітніших інформаційних систем (таких, як Web-системи). База
даних системи у такому разі розглядається у ширшому розумінні, ніж
просто набір спеціальних об’єктів (наприклад таблиць), що обробляються
та підтримуються певною СУБД. Навіть набір статичних Web-сторінок, що
зберігаються, як окремі файли у файловій системі сервера, розглядається
як база даних. Модель даних у будь-якому випадку повинна належним чином
документуватись та проектуватись (як правило, з використанням такого
інструментарію як ERD). Проте не викликає сумнівів те, що для побудови
серйозних інформаційних систем з великими об’ємами даних як засоби
підтримки даних повинні використовуватися промислові СУБД реляційного
або об’єктно-реляційного типу. Встановлення відповідності між базою
даних системи та станом її автоматної моделі не є випадковим, а
грунтується на фундаментальних засадах теорії формальних систем.
Актуальний стан системи є фактично історією системи, тобто результатом
усіх попередніх запитів клієнтів. З точки зору інформаційних систем
найкращим способом агрегації усіх попередніх запитів є ведення їх бази
даних. Так, аналізуючи вміст реляційної бази даних, відзначимо, що він
фактично є історією SQL-запитів, що формулювались до бази даних (тобто
станом системи в розумінні теорії формальних систем).
Визначення точної реакції системи на запит клієнта залежить не лише від
ідентифікаторів запиту та стану ІС. Реакція системи залежить також від
параметрів Pj запиту та бази даних ІС. У відповіді системи також
міститиметься, окрім ідентифікатора, й параметрична компонента. Проте в
межах автоматної моделі неможливо повністю описати реакцію системи на
запит клієнта (враховуючи, що множина можливих запитів з параметрами та
станів з БД може мати велику розмірність, зокрема бути скінченні або
мати потужність континуум). Відповідь системи на запит клієнта
формується як автоматна реакція мережі автоматів (відповідно з
ієрархічною структурою ІС) із корекцією та доповненням відповідно до
параметрів запиту та БД ІС. Параметричну компонента системи є
другорядною при описі функціональності системи. Параметрична компонента
усувається з розгляду шляхом використання стохастичних та
недетермінованих автоматних моделей. Тоді параметри запитів, відповідей
та БД ІС в моделі не розглядаються, а реакція системи перестає бути
повністю визначеною. У стохастичній моделі замість алгоритмічної
корекції відповіді сервера вводяться імовірнісні характеристики можливих
переходів та виходів. У недетермінованій моделі залишаться лише можливі
переходи та відповіді на стан.
Реакція системи може бути неповністю визначеною і у випадку
параметричного опису. Тобто реакція системи на кожен запит описується
множиною можливих переходів, виходів та їх імовірностей.
Функція переходу:
Функція виходу:
Ми отримаємо імовірнісно-автоматну модель ІС. Розглянемо проблему
формування імовірностей для опису реакції системи на запит. Можливі два
підходи до її розв’язання:
1. визначення імовірності конкретної реакції системи на запит
користувача зі врахуванням значення конкретного параметра;
2. визначення загальної імовірності конкретної реакції системи на запит
користувача без врахування значення конкретного параметра;
Перший підхід забезпечує максимально можливу визначеність реакції
інформаційної системи на запит користувача. Проте недоліком такого
підходу є велика складність визначення імовірності переходу. Крім того,
при використанні операції усунення параметра потрібно буде
перераховувати імовірності переходів. Для проведення фізичної
оптимізації також доцільно використовувати загальні значення
імовірностей реакції системи. Тому доцільніше використовувати другий
підхід. У такому разі імовірність реакції визначається для кожної пари
(St,Q) без врахування значень параметрів запиту до системи та її бази
даних. Визначеність поведінки системи буде меншою ніж у першому випадку,
проте для усунення параметрів з розгляду та фізичної оптимізації системи
непотрібно буде додаткових перетворень. Якщо в системі існуть запити з
такими параметрами, що суттєво впливають на реакцію системи та є
важливими для її оптимізації, тоді пару (параметр, запит) можна
перетворити в окремий запит.
3.ІМПЛЕМЕНТАЦІЯ ПРОГРАМИ З АРХІТЕКТУРОЮ “КЛІЄНТ-СЕРВЕР” ЗАСОБАМИ МОВИ
JAVA2 EE
3.1 Постановка задачі
Для демонстрації архітектури “клієнт-сервер”, засобами мови JAVA2 EE, я
вирішив створити програму для запису слухачів на семінари.
Програма повинна вміти робити наступне:
Вести облік семінарів;
Переглядати, додавати, редагувати та знищувати записи про людей, які
вирішили прослухати обраний семінар;
3.2 Реалізація клієнтської частини
Перед створенням клієнтсьої я вирішив ознайомитись з засобами мови JAVA2
EE для роботи з мережами та вже існуючими інструментами налагодження
підключення до мережевих програм, а саме із програмою telnet.exe, що
входить до складу операційної системи UNIX та операційних систем
сімейства Windows (у трохи спрощеному варіанті). Необхідно врахувати, що
вона не є обов’язковим компонентом операційної системи, необхідно
перевірити чи встановлена комп’ютері. Якщо її неможливо запустити з
командного рядка, тоді потрібно ще раз завантажити програму втановлення
операційної системи й вибрати її в списку пропонованих для встановлення
компонентів.
Програма telnet може використовуватись не тільки для з’єднання з деяким
комп’ютером, та роботи з електронною поштою, але й для роботи з іншими
мережевими сервисамі. Нижче приводиться один із прикладів використання
цієї програми.
telnet time-A.timefreq.bldrdoc.gov 13
50692 97-09-01 2 1:4 3:1 5 50 0 0 5 0.0 UTC(NIST) *
File Edit Settings. Help
~$ telnet time-A.timefreq.bldrdoc,gov 13
Trying 132.163.4.102…
Connected to t1me-A.timefreq.bldrdoc.gov.
Escape character 1s ‘ * ] ‘ .
52088 01-06-28 14:35:13 50 0 0 644.8 UTCCNIST)
Connection closed by foreign host.
~$ D
Програма telnet підключилася до сервісу “визначення часу”, що працює на
більшості комп’ютерів під управлінням операційної системи UNIX.
Зазначений у цьому прикладі сервер перебуває в Національному Інституті
Стандартів і Технологій (National Institute of Standards) в Боулдері,
штат Колорадо, США. Його системний час синхронізований із цезієвмми
атомними годинниками. (Звичайно, отримане значення поточного часу буде
не зовсім точним, через затримки, пов’язаних з передачею даних у
мережі.) По домовленості, сервіс “визначення часу” завжди пов’язаний з
портом 13.
При описі мережних технологій портом називається не якийсь фізичний
прилад, а абстрактне поняття, що означає організацію з’єднання між
сервером і клієнтом. Програмне забезпечення сервера постійно працює на
віддаленому комп’ютері і очікує надходження мережевого трафіка на порт
13. При одержанні операційною системою на віддаленому комп’ютері
мережного пакета із запитом на підключення до порту 13 активізується
процес-слухач сервера й встановлюється з’єднання.
Таке з’єднання може бути перервано одним з його учасників.
Після запуску програми telnet з параметром time-A. timef req.bldrdoc.
gov
і портом 13 незалежне мережне програмне забезпечення перетворить рядок
time-A. timef req. bldrdoc .gov в IP-адресу 132.163. 135. 130. Потім
надсилає запит на з’єднання із заданим комп’ютером по порту 13.
Після встановлення з’єднання програма на віддаленому комп’ютері посилає
назад рядок з даними, а потім закриває з’єднання. У загальному випадку
клієнти й сервери до закриття з’єднання можуть брати участь у більше
складних діалогах.
Ще один більше цікавий експеримент, який варто виконати з відключенням
еха-відповіді уведених символів. В операційній системі Windows це можна
зробити, указуючи в режимі командного рядка команду
set LOCAL_ECHO off.
Далі
1. Підключитись до сервера java.sun.com до порта 80.
2. Увести рядок GET / HTTP / 1.0 точно в показаному форматі.
3. Тепер двічі натисніть клавішу .
Відповідь сервера має вже знайомий нам вид сторінки тексту у форматі
HTML, а саме основний Web-сторінки компанії Sun, присвяченої технологіям
Java. Саме так звичайний броузер одержує всі Web-сторінки.
import java.io.*;
import java.net.*;
public class SocketTest {
public static void main(String[] args) {
try {
Socket s = new Socket(“time-A.timefreq.bldrdoc.gov” 13);
BufferedReader in = new BufferedReader
(new InputStreamReader (s.getlnputStreamf) ) );
boolean more = true;
while (more) {
String line = in.readLine();
if (line == null)
more = false;
else
System.out.println(line);
} catch (IOException e) {
e.printStackTrace();
}
}
Це дуже проста програма, але ще до аналізу двох її ключових рядків
необхідно звернути увагу на те, що в ній імпортується пакет java.net і
обробляються виключні ситуації при виконанні операцій уведення/виводу в
блоці try/catch . (При роботі з мережами можуть виникати збої, тому в
багатьох мережних методах передбачені повідомлення про помилки
уведення/виводу. Для успішної компіляції коду ці повідомлення необхідно
перехоплювати й обробляти відповідним чином.).
Цей приклад містить наступні два ключові рядки.
Socket s = new Socket(“time-A.timefreq.bldrdoc.gov”, 13);
BufferedReader in = new BufferedReader
(new InputStreamReader (s.getlnputStreamf) ) ) ,
Перший рядок дозволяє відкрити сокет. Сокет – це абстрактне поняття, яке
позначає програмне забезпечення, що дозволяє організувати операції
обміну даними між програмами. Конструкторові сокета передається адреса
вилученого сервера й номер порту. При невдалому з’єднанні виникає
виняткова ситуація UnknownHostException, а при наявності якихось інших
проблем— виключна ситуація IOException. Клас UnknownHostException є
класом наслідником від IOException, тому в цьому простому прикладі
обробляється тільки виняткова ситуація базового класу.
Після відкриття сокета метод getlnputStream класу java.net. Socket
віз-обертає об’єкт потоку InputStream, який можна використати як
звичайний файл. Після одержання потоку програма приступає до виконання
наступних дій.
1. Зчитує всі відправлені сервером символи за допомогою методу readLine.
2. Виводить кожен рядок на стандартному пристрої виводу.
Дійсний процес триває доти, поки не закінчиться потік або не
відключеться від сервера. У такому випадку метод readLine поверне null.
Клас Socket дуже зручний у роботі, тому що приховує всі складні
подробиці встановлення мережного з’єднання й передачі даних у мережі. А
пакет java.net надає такий же програмний інтерфейс, що використовується
для роботи з файлами.
Отже, після дослідження питаннь підключення до серверів та інших
мережевих сервісів а програмі “клієна” було розроблені наступні основні
методи:
Метод підключення до сервера
Метод для отримання списку слухачів;
Метод для отримування інформації про слухача;
Метод для додавання інформації про слухачів до бази даних;
Метод для редагування інформації про слухачів;
Метод для знищення слухачів з бази даних;
Та ряд допоміжних: метод, який викликається, коли втрачається зв’язок із
сервером, в цьому випадку всі назви семінарів видаляються і створюються,
умови для повторного підключення до сервера (активується відповідна
кнопка та пункт меню), метод, який центрує вікно програми при її
запуску, методи реалізації технології Drag’n’Drop, що дозволяє змінювати
семінар слухача простим перетягуваням мишки з таблиці до спику семінарів
у вікні програми.
Рисунок 6. Вигляд готової програми клієнта
3.3 Реалізація серверної частини
Тепер після створення клієнта, що може одержувати дані з мережі,
спробуємо створити сервер, що може посилати дані.
Спочатку, досділимо питання написання серверів засобами мови JAVA2 EE.
Після запуску програми сервера вона переходить у режим очікування
приєднання клієнтів до своого порту. Необхідно вибрати номер порту, що
не використається ніякими стандартними пристроями. Наведена нижче
команда дозволяє створити сервер з портом 8189.
ServerSocket s = new ServerSocket(8189);
Потім показана нижче команда повідомляє програмі, що вона повинна
очікувати підключення клієнтів до заданого порту.
Socket incoming = s. Accept();
Відразу після підключення клієнта до порту за допомогою переданого по
мережі корректного запиту цей метод посилає об’єкт Socket, що
представляє встановлене з’єднання. Даний об’єкт можна використати для
читання вхідних й запису вихідних даних так, як показано нижче.
BufferedReader in = new BufferedReader
(new InputStreamReader(incoming.getlnputstream()));
PrintWriter out = new PrintWriter
(incoming.getOutputStreamf), true) ;
Всі дані вихідного потоку сервера стають даними вхідного потоку клієнта
й навпаки, всі дані вихідного потоку клієнта стають даними вхідного
потоку сервера.
Потоки будуть виконувати роль читачів і тих, що записують дані за
допомогою методу readLine (він визначений у класі Buf feredReader, але
не в класі InputStream) і методу print (він визначений у класі
PrintWriter, але не в класі OutputStream) відповідно. Для передачі
бінарних даних необхідно перетворити ці потоки в потоки DatalnputStream
і DataOutputStream. А для передачі об’єктів сериалізаціиї варто
використати потоки ObjectlnputStream й ObjectOutputStream.
Допустимо, що програма-клієнт відправила вітання:
out.println(“Hello! Enter BYE to exit.”);
При використанні утиліти telnet для підключення до програми-сервера на
порті 8189 показане вище вітання буде відображено у вікні термінала.
У цієї простої програми-сервера построчно зчитуються вхідні дані,
відправлені програмою-клієнтом, і відображаються на екрані в режимі
ехо-відповіді. Такім чином даний приклад демонструє одержання вхідних
даних від програми-клієнта. Програма-сервер повинна обробити отримані
дані й дати адекватну відповідь.
String line = in.readLine();
if (line != null) {
out.println(“Ехо-відповідь: ” + line);
if (line.trim().equals(“BYE”))
done = true;
}
else
done = true;
Нарешті, варто закрити використовуваний сокет.
incoming.close();
От і всі! Кожна програма-сервер, наприклад, Web-сервер, виконує такий же
цикл основних дій.
1. Одержання команди від програми-клієнта (“дайте мені потрібну
інформацію”) із вхідного потоку даних.
2. Пошук заданої інформації.3. Посилка клієнтові знайденої інформації у
вихідний потік даних.
Далі показаний повний текст описаної вище програми-сервера.
import java.io.*;
import java.net.*;
public class EchoServer {
public static void main(String[] args ) {
try {
// Створити сокет
ServerSocket s = new ServerSocket(8189);
// Перейти в режим очікування
// запитів з боку клієнтів
Socket incoming = s.accept();
BufferedReader in = new BufferedReader
(new InputStreamReader(
incoming.getlnputStreamf)));
PrintWriter out = new PrintWriter
(incoming.getOutputStreaml),
true /* autoFlush * / ) ;
out.println( “Hello! Enter BYE to exit.” );
// Ех-відповідь запиту клієнта
boolean done = false;
while (!done) {
String line = in.readLine();
if (line == null)
done = true;
else {
out.println(“Echo: ” + line);
if (line.trim().equals{“BYE”))
done = true;
incoming.close();
}
} catch (Exception e) {
e.printStackTrace();
}
}
}
Для перевірки працездатності програми її потрібно відкомпілювати й
запустити. Потім необхідно підключитися за допомогою утиліти telnet до
сервера 127.0.0.1 і порту 8189.
IP-адреса 127.0.0.1 називається локальною адресою зворотного зв’язку
(local loopback address), яка позначає локальний комп’ютер. Оскільки
ехо-відповідь буде відображатися на екрані локального комп’ютера, те
саме до нього й треба підключитися в даному прикладі.
При використанні підключення, що комутирує, для виконання цього приклада
буде потрібно його встановити. Справа в тому, що навіть при взаємодії з
локальним комп’ютером у нашому випадку потрібно завантажити необхідне
мережне програмне забезпечення. Тепер будь-який користувач мережі може
одержати доступ до програми-сервера при
умові, що йому відома IP-адреса вашого комп’ютера й номер порту.
При підключенні до цього порта буде отримане повідомлення
Hello! Enter BYE to exit.
Введем будь-яку фразу й одержимо на неї ехо-відповідь. Для відключення
від програми-сервера слыд ввести BYE (всі символи у верхньому регістрі).
~$ telnet local host 8189
Trying 12?.0.0.1 …
Connected to local host.local domain.
(“Escape character Is ‘ Л ] ‘ .
Hello! Enter BYE to exit.
Hello there! How are you today?
Echo: Hello there I How are you today?
I am fine., thanks. And you?
|Echo: I am fine, thanks, And you?
BYE
Echo: BYE
Connection closed by foreign host.
• $ 0
У попередньому простому прикладі програми-сервера не передбачена
можливість одночасного підключення відразу декількох програм-клієнтів.
Звичайно, програма-сервер працює на комп’ютері-сервері, а
програми-клієнти можуть одночасно підключатися до неї за допомогою
мережі Internet з будь-якої частини світу. Якщо на сервері не
передбачена обробка одночасного підключення декількох клієнтів, те це
приведе до того, що один клієнт може монополізувати доступ до даної
програмі-серверу протягом тривалого часу. Щоб уникнути таких ситуацій
варто вдатися до допомоги потоків.
Для кожного нового з’єднання із сокетом, тобто при успішній обробці
запиту на з’єднання, буде запущений новий потік, що подбає про
організаціївзаємодії між програмою-сервером і даною програмою-клієнтом.
Для цього в програмі-сервері варто організувати показаний нижче цикл.
while (true) {
Socket incoming = s.accept;
Thread t = new ThreadedEchoHandler(incoming);
t.start();
}
Клас ThreadedEchoHandler є похідним від класу Thread і містить
представлений нижче цикл обробки взаємодії із програмою-клієнтом в
своєму методі run.
class ThreadedEchoHandler extends Thread {
public void run() {
try {
BufferedReader in = new BufferedReader
(new InputStreamReader(incoming.getlnputStreamf)));
PrintWriter out = new PrintWriter
(incoming.getOutputStream(), true /* autoFlush * / ) ;
String line;
while ((line = in.readLine()) != null) {
incoming.close();
}
catch (Exception e) {
Тепер декілька програм-клієнтів можуть одночасно підключатися до
сервера, тому що для кожного з’єднання створюється новий потік. Це можна
легко провірити скомпілювавши й запустивши програму-сервер, код якої
наведений у вище та відкрийте кілька вікон утиліти telnet. Тепер кожне
окреме вікно утиліти telnet може незалежно взаємодіяти із
програмою-сервером. Для закриття даного з’єднання й вікна утиліти telnet
слід натиснути комбінацію клавіш <Ctrl+C>.
Рисунок 7. Вигляд завершеного сервера
4. ВИЗНАЧЕННЯ ЕКОНОМІЧНОЇ ЕФЕКТИВНОСТІ РОБОТИ СИСТЕМИ
4.1 Економічна доцільність розробки програмного забезпечення та його
впровадження
Всі програмні продукти, які розробляються на даний час, необхідно
обґрунтувати з точки зору економічної доцільності. Дане обґрунтування
необхідне для того, щоб вчасно припинити (при втраті актуальності або
надмірних витратах) розробку або здійснити необхідні інвестування в
проект для забезпечення необхідними програмними або апаратними засобами
розробників з метою одержання очікуваних результатів. Економічний ефект
розробленого продукту визначається на основі економічних показників, які
дають можливість прогнозувати результат від впровадження даної програми.
Існує багато методів визначення економічних показників доцільності
впровадження та використання математичного та програмного забезпечення.
Враховуючи інтенсивний розвиток комп’ютерної техніки, на сьогодні такий
аналіз є невід’ємною частиною попереднього аналізу аналогічних робіт,
оскільки саме результат автоматизації виробничих процесів дає суттєве
покращення в технології виробництва чи діагностування об’єктів, а кошти,
що затрачаються на дану роботу, повинні бути еквівалентними тому ефекту,
який принесе конкретне нововведення.
В даній роботі проводиться розрахунок економічних показників та аналіз
всієї роботи по розробці алгоритмічного і програмного забезпечення.
4.2 Побудова мережевого графа
Мережевий граф є основним плановим документом в системі мережевого
планування і керування, що являє собою інформаційно-динамічну модель, в
якій зображаються взаємозв’язки і результати всіх робіт, необхідних для
досягнення кінцевої мети розробки, тобто мережевий граф – це наочне
відображення плану робіт.
В мережевому графі детально чи укрупнено показано, що, в якій
послідовності, коли, за який час, для чого необхідно виконати, щоб
забезпечити закінчення всіх робіт не пізніше заданого, директивного
терміну.
Порядок побудови мережевих графів визначається прийнятою технологією і
організацією робіт. Мережеві графи тільки відображають існуючу або
проектовану черговість і взаємозв’язок виконання робіт.
По кожній роботі необхідно враховувати:
які роботи повинні бути завершені раніше, ніж почнеться дана робота;
які роботи можуть початись після завершення даної роботи;
які інші роботи повинні виконуватись одночасно з виконуванням даної
роботи.
Аналізуючи мережевий граф можна виділити його головні елементи: події і
роботи. Розглянемо детальніше значення термінів:
подія – це стан, момент досягнення проміжної або кінцевої цілі розробки.
робота – це розтягнений в часі процес, необхідний для здійснення події.
Кожна робота має попередню подію і закінчується визначеною подією.
характеристик, а також для аналізу мережі чи для аналізу складеного
плану розробки.
Резерв часу події – це такий проміжок часу, на який може бути відкладене
здійснення цієї події без порушення термінів завершення розробки в
цілому. Резерви часу існують в мережевому графі в усіх випадках, коли
існує більш ніж один шлях різної тривалості.
Резерв часу події К визначається як різниця між пізнім Тп і раннім Тр
термінами завершення події за формулою
К = ТП-ТР. (4.1)
Найбільш пізній з допустимих термінів ТП – це такий термін здійснення
події, перевищення якого викличе аналогічну затримку завершальної події.
Іншими словами, якщо подія наступила в момент ТП, вона потрапила в
критичну зону і наступні за нею роботи повинні знаходитись під таким же
контролем як і роботи критичного шляху.
Найбільш ранній з можливих термінів здійснення події ТР – це термін
необхідний для виконання всіх робіт, що передують цій події. Цей час
знаходиться шляхом вибору максимального значення із тривалості всіх
шляхів, що приводять до даної події.
Вихідні дані мережевого графа представлені в таблицях 4.1 та 4.2.
Таблиця 4.1 – Події мережевого графа
№ події Подія
0 Отримання технічного завдання на дипломне проектування
1 Аналіз проблеми дипломного проектування
2 Ознайомлення з технічною літературою на задану тему
3 Пошук інформації в мережі INTERNET
4 Підбір необхідних джерел інформації
5 Аналіз підібраного матеріалу
6 Визначення задач, які виникають при розробці
7 Розгляд існуючих способів моделювання даних систем
8 Аналіз існуючих способів моделювання
9 Постановка задачі для математичного моделювання
10 Аналіз показників, які впливають на систему
11 Визначення параметрів моделі
12 Розробка структури алгоритму
13 Розробка алгоритму програмного забезпечення
Продовження таблиці 4.1
14 Вибір середовища програмування для реалізації завдання
15 Розробка структури даних
16 Визначення основних програмних модулів
17 Розробка алгоритму роботи системи
18 Розробка процедури обробки даних
19 Остаточне налагодження програми
20 Аналіз одержаних результатів
21 Визначення економічної доцільності використання системи
22 Завершення роботи
Таблиця 4.2 – Роботи мережевого графа
Номери робіт Роботи Тривалість, дні
0-1 Аналіз завдання дипломного проекту 3
1-2 Огляд технічної літератури 5
1-3 Огляд інформації в INTERNET 3
3-4 Робота з підібраним матеріалом з INTERNET 4
2-4 Робота з підібраним матеріалом 5
4-5 Аналіз показників, які впливають на систему 4
5-6 Виділення конкретних задач, що виникають при моделюванні 5
6-7 Формулювання вимог до моделей 4
7-8 Пошук адекватної математичної моделі 15
8-9 Формулювання конкретної задачі для вибраного способу моделювання 5
8-10 Аналіз решти можливих показників, які впливають на систему 6
9-11 Пошук і аналіз значень коефіцієнтів моделі 5
Продовження таблиці 4.2
10-11 Визначення залежностей параметрів моделі 7
11-12 Розробка структури алгоритму програми 10
12-13 Розробка структури програми 6
13-14 Розробка чисельного алгоритму реалізації моделі 18
14-16 Аналіз можливостей вибраного програмного пакету 2
13-15 Уточнення виду вхідних даних для програми 3
15-17 Розробка алгоритму опрацювання даних 10
16-18 Написання алгоритму модуля 3
17-18 Опрацювання вхідної інформації 6
18-19 Реалізація процедури обробки даних 10
19-20 Налагодження програми 10
20-21 Аналіз адекватності моделі 5
21-22 Аналіз економічних показників Завершення роботи 20
На рисунку 4.1 зображений мережевий граф, який отримано із вихідних
даних таблиць. Знаходимо критичний шлях і розраховуємо ранній, пізній
час і резерв часу.
Критичний шлях – це найбільш тривала по часу послідовність робіт, які
ведуть від вихідної до завершальної події. Величина критичного шляху
визначає термін виконання всього комплексу по плануванню робіт.
Зміна тривалості будь-якої роботи, що лежить на критичному шляху,
відповідним чином змінює термін настання завершальної події, тобто дату
досягнення кінцевої мети, яка ставиться при плануванні розробки.
При плануванні комплексу операцій критичний шлях дозволяє знайти термін
настання завершальної події. В процесі керування ходом розробки увага
керівництва зосереджується на роботах критичного шляху. Це дозволяє
найбільш доцільно і оперативно контролювати обмежене число робіт, що
впливають на термін розробки, а також краще використати існуючі ресурси.
Оскільки в даному випадку мережевий граф досить простий, очевидно що
критичний шлях рівний 138.
Дані розрахунків часу подій приведені в таблиці 4.3
Таблиця 4.3 – Параметри подій мережевого графіка
№ події Ранній час Пізній час Резерв часу
0 0 0 0
1 3 3 0
2 8 8 0
3 6 10 4
4 13 13 0
5 17 17 0
6 22 22 0
7 26 26 0
8 41 41 0
Продовження таблиці 4.3
9 46 49 3
10 47 47 0
11 54 54 0
12 64 64 0
13 70 70 0
14 88 88 0
15 73 74 1
16 90 90 0
17 84 87 3
18 93 93 0
19 103 103 0
20 113 113 0
21 118 118 0
22 138 138 0
4.3 Економічне обґрунтування розробки та впровадження програми
Економічне обґрунтування розробки та впровадження програми будемо
здійснювати на аналізі таких економічних показників:
Sp.n – сумарні витрати на розробку програмного забезпечення;
?Kд2/1 – додаткові капітальні вкладення;
KEOM – капітальні вкладення в ЕОМ;
?Ee2/1 – додаткові капітальні вкладення.
Розрахунок відповідних коефіцієнтів проводиться з врахуванням того, що
варіаційні задачі діагностування раніше виконувались вручну.
4.4 Розрахунок витрат на розробку програмного забезпечення
Сумарні витрати на розробку програмного забезпечення Sрп. визначаються
за формулою:
, (4.2)
де р0 – норматив рентабельності, що враховує прибуток установи, яка
розробляє дану програму, долі одиниці;
– час, що витрачається на розробку даної програми працівником і-ої
кваліфікації, люд.-міс;
– основна заробітна плата розробника і-ої кваліфікації, грн/міс;
– коефіцієнт, що враховує додаткову заробітну плату розробникам
програми, в долях від основної заробітної плати;
– коефіцієнт, що враховує нарахування органам соціального захисту на
заробітну плату, в долях від основної та додаткової заробітної плати;
– коефіцієнт, що враховує накладні витрати установи, в якій
розробляється ця програма, в долях до основної заробітної плати
розробника;
– машинний час ЕОМ, необхідний для налагоджування даної програми,
машино-год;
ег – експлуатаційні витрати, що припадають на 1 год машинного часу.
= 300 грн(неповний робочий день). Експлуатаційні витрати, що
припадають на 1 год машинного часу, можуть бути визначені за витратою
електроенергії
(4.3)
де Рсп = 350 – споживана потужність ЕОМ, Вт;
Сеод = 0.32 – вартість 1 кВт/год електроенергії для підприємств.
Отже, за (4.3)
ег =0.35 ? 0.32 = 0,112 грн/год.
становить 100 машино-год. Сумарні витрати на розробку програмного
забезпечення складуть
= 2199.302 (грн)
4.5 Розрахунок капітальних вкладень
, пов’язані з впровадженням розробленої системи, визначаються за
формулою:
, (4.4)
– капітальні вкладення в ЕОМ та інші складові системи;
– машинний час ЕОМ необхідний користувачу для тих задач, які він
розв’язує за допомогою розробленої програми машино-год/рік;
– корисний річний фонд роботи цієї ЕОМ (без врахування простоїв в
ремонті);
– ціна нової програми, грн.:
грн.,
– кількість користувачів.
Капітальні вкладення в ЕОМ та інші складові системи визначаються за
формулою:
(4.5)
– вартість ЕОМ (серверів), грн;
– вартість комунікацій, грн.
Cсер.i для комп’ютера Athlon64 3000, ASUS A8NE, DDR 256 Mb, HDD 120 Gb,
GeForce6600, SyncMaster 17”
Буде становити Cсер.i = 3402 грн
Ском.і для комп’ютерного класу з 30 комп’ютерів буде становити Ском.і =
980 грн. (сюди входять мережевий комутатор, кабель, короб для кабелю,
конектори, мережеві розетки, та мережеві карти)
КЕОМ = 3402 + 980 = 4382 грн.
Корисний річний фонд роботи ЕОМ :
(4.6)
де Др – дійсний річний фонд часу, дні;
kn – коефіцієнт, що враховує профілактичні роботи та плановий ремонт (kn
= 0,1);
= 8). Корисний фонд часу ЕОМ становить:
год/рік.
Машинний час ЕОМ, необхідний користувачу для вирішення задачі з
допомогою ЕОМ, обчислюється як:
, (4.7)
де tз – час, який витрачає користувач на вирішення задачі з ЕОМ, год.
Машинний час ЕОМ становить
год/рік.
Додаткові капітальні вкладення становлять:
грн.
4.6 Розрахунок експлуатаційних витрат
визначається за формулою:
(4.8)
– основна заробітна плата 1-ого робітника, який розв’язував цю задачу
вручну, грн/рік;
Тс – строк служби програми до її морального зносу, роки.
=3600 грн/рік. (неповний робочий день), кількість робітників – 1.
Економія експлуатаційних витрат становить:
= (1+ 0.2) ? 3600 – (696.6 ? 0.112 + 2199.302/3)= 3560 грн.
4.7 Розрахунок зведених економічних показників
Термін окупності додаткових капітальних вкладень визначається за
формулою
(4.9)
Отже, за (4.9)
=3843.08/3560 = 1.07 роки.
Грошовий річний ефект, який отримує користувач при застосуванні системи
визначається за формулою
(4.10)
, і становитиме
=3560 –3843.08/3 = 2278,42 грн.
В таблиці 4.4 наведені зведені економічні показники системи. З вище
наведених розрахунків видно, що розробка та впровадження даної системи є
економічно доцільною. Використана при розрахунках методологія не є
досконалою і не враховує всі переваги застосування інформаційних
комп’ютерних систем. До таких переваг можна віднести якісні параметри:
«безпідкупність» системи при винесенні оцінки за тест
можливість повторного використання уже існуючих тестів
швидкість перевірки завдань
Таблиця 4.4 – Зведені економічні показники розробки системи
Показник Розмірність Значення
Витрати на розробку програмного забезпечення грн 2199.30
Капітальні вкладення грн 3843.08
Економія експлуатаційних витрат грн/рік 3560,45
Термін окупності Рік 1.07
Грошовий річний ефект грн/рік 2278,42
Таким чином, із економічних розрахунків та згаданих переваг випливає, що
впровадження спроектованої системи є економічно доцільним і дозволить
підвищити продуктивність праці працівника, який раніше вирішував дані
задачі вручну.
5. ОХОРОНА ПРАЦІ
5.1 Аналіз небезпечних та шкідливих виробничих факторів
В процесі роботи людина взаємодіє із предметами пращ, знаряддями праці
та іншими людьми. На неї діють різні фактори виробничого середовища, в
якому протікає процес праці (температура, вологість повітря, шум,
вібрація, шкідливі речовини, різні випромінювання та інші). Від умов
праці в великій мірі залежить здоров’я, працездатність людини,
відношення до праці і її результати. При несприятливих умовах різко
знижується продуктивність праці і виникають передумови для виникнення
травм і професійних захворювань.
У зайнятих переважно розумовою працею, робота яких супроводжується
нервово-психічним напруженням (оператори, диспетчери і т.д.), частіше
реєструється патологія, у якої є істотною роль порушень
нервово-ендокринної регуляції: це захворювання нервової системи, органів
травлення, органів чуття.
Недоліки при проектуванні і створенні обчислювальних центрів неминуче
відбивається на якісних і кількісних показниках діяльності робітників, у
тому числі призводить до уповільнення або помилок у процесі роботи.
Особливості характеру і режиму праці, значна розумова напруга й інші
навантаження призводять до зміни в робітників обчислювальних центрів
функціонального стану центральної нервової системи, нервово-м’язового
апарату рук (при роботі з клавіатурою введення інформації).
Нераціональні конструкція і розташування елементів робочого місця
викликають необхідність підтримки змушеної робочої пози. Тривалий
дискомфорт в умовах гіпокінезії викликає погашену пізнотонічну напругу
м’язів і обумовлює розвиток загального стомлення і зниження
працездатності.
При тривалій роботі за екраном дисплея в операторів відзначається
виражена напруга зорового апарату з появою скарг на незадоволеність
роботою, головну біль, дратівливість, порушення сну, втома і хворобливі
відчуття в очах, в області шиї, руках і ін.
Вони також піддаються впливу шкідливих і небезпечних чинників
виробничого середовища: електромагнітних полів (радіочастот), статичній
електриці, шуму, недостатньо задовільних метеорологічних умов,
недостатньої освітленості і психоемоційної напруги. Праця робітників з
електронно-обчислювальною технікою повинна відносити до І-ІІ класу по
гігієнічних умовах праці; його тяжкість не повинна перевищувати
оптимальних.
Потенційно небезпечні виробничі фактори, їхні фактичні і нормативні
значення зведені в таблицю 5.1.
Таблиця 5.1 – Аналіз потенційно небезпечних виробничих факторів
Небезпечний фактор (технологічна операція) Діапазон Фактичне значення
Нормативне значення (безпечна величина) Характер дії на людину
Рентгенівське Понад 1.2 КеВ 9-12 мкр/г 75.0 мкр/г Загальна втома,
головний біль
Ультрафіолетове випромінювання 220-280 нм 0.1 Вт/м2 0.01 Вт/м2
ІЧ-випромінювання 700 нм-1мм 0,05-4 Вт/м2 100 Вт/м2
Видимий діапазон 320-700 нм 0.1-2.0 Вт/м2 10 Вт/м2
Електростатичне поле – 15 кВ/м 20-60 кВ/м
Яскравість – 75-80 Кд/м2 35 Вт/м2 Різь в очах
5.2 Заходи для забезпечення нормальних умов праці та розрахунок
природної освітленості
Виробничі приміщення даної категорії проектуються відповідно до вимог
СНІП 2.09.04-87 “Адміністративні і побутові будинки приміщення
виробничих підприємств”. Розміщення приміщень здійснюються за принципом
однорідності видів виконуваних робіт. З метою оптимізації умов праці
робітників, необхідно встановлювати відеотермінали в приміщення, суміжні
й ізольовані від приміщень із технологічним обладнанням.
Для екрану монітора використовується спеціальний фільтр який захищає очі
оператора від ультрафіолетових і рентгенівських променів, а також
підвищує контрастність зображення.
Переважно застосовуються захисні екрани трьох типів – сіткові, плівкові
і скляні. Результат досліджень властивостей фільтрів наведено в таблиці
5.2.
Сіткові екрани, зменшують блищання, але значно знижують контрастність і
видимість об’єктів розрізнення, що неприпустимо. Плівкові – поліпшуючи
видимість і контрастність зображення, швидко вигоряють і утруднюють
видимість.
Таблиця 5.2 – Характеристики захисних екранів
Тип фільтру Конструкція Позитивні якості Негативні якості
Сітковий без
провідного шару Чорна капронова сітка з ниток різної товщини та різного
плетіння Зменшує блищання
скляної поверхні Захисних функцій не виконує; знижує
видимість на 50%;
зменшує чіткість і
контрастність
зображення
Продовження таблиці 5.2
Сітка з
провідними
нитками, або
провідним
покриттям і
заземленням Чорна металева або
капронова сітка з
металевим покриттям Захищає від ЕСП при високій провідності від
ЕМП (СЧ і НЧ
спектрів) Зменшує чіткість,
контрастність і
видимість зображення
Плівковий
тонований Тонка плівка фірми
“Polaroid” СР-50;
“Polaroid” СР-60 Знижує блищання і
мерехтіння екрану,
дещо підвищує
контрастність і чіткість Не призначений для
захисту від
випромінювання, мала прозорість (25%); швидко вигоряє при користуванні
Скляний тонкий:
тонований з
поглинаючим
шаром Тонке неполіроване
скло Знижує блищання від екрана ЕПТ Як правило, не має
сертифіката якості
Скляний товстий Товсте скло, леговане іонами важких металів Забезпечує
захист від випромінювань ЕМП (ВЧ, НЧ, СЧ), УФ. Дуже яскравий блиск
від фільтра
Комбінований:
скляний з
плівковим
покриттям Тонке скло і плівка Прозорість, послаблює
всі види
випромінювання Високе блищання
По можливості екран дисплею необхідно розмістити трохи вище рівня очей.
Це створить розвантаження тих груп м’язів, які напружені при нормальному
погляді – вниз або вперед.
У операторних, а також інших приміщеннях, де особливості експлуатації
устаткування обумовлюють підвищену рухливість повітря, значні рівні
звуку й інші несприятливі чинники виробничого середовища, постійні
робочі місця операторів ЕОМ необхідно розміщувати в ізольованих кабінах,
площа яких із розрахунку на одну людину повинна бути не менше 6 м2, а
об’єм не менше 20 м3.
Кабіна оператора повинна розміщатися з протилежної сторони від гучних
агрегатів обчислювальних машин, вона повинна мати природне освітлення
при коефіцієнті природної освітленості не менше 1,0% з організованим
повітрообміном.
На постійних робочих місцях і в кабіні оператора повинні бути
забезпечені мікрокліматичні параметри, рівні освітленості, шуму і стан
повітряного середовища, визначені чинними санітарними правилами і
нормами.
Таблиця 5.3 – Нормативні характеристики метеорологічних умов у
виробничих приміщеннях
Виробниче приміщення Категорія важкості фізичних робіт Період року
Температура, °С Відносна вологість, % Швидкість руху повітря,
м/с
Відділ розробки програмного забезпечення І а – легка Теплий Холодний
22-25
20-23 40-60
40-60 0,1
0,1
У виробничих приміщеннях повинні дотримуватися такі об’єми зовнішнього
повітря:
– при об’ємі приміщення більше – 10 м3 на одного працюючого, присутності
вікон і відсутності виділення шкідливих речовин припускається природна
вентиляція приміщення, якщо не потрібно дотримання технологічних
параметрів чистоти повітря; – у виробничих приміщеннях без вікон і
ліхтарів подача повітря на одного працюючого повинна бути не менше 60 м3
/год, при дотриманні норм мікроклімату, шкідливих речовин і пилюки.
В усіх операторних на постійних робочих місцях параметри мікроклімату
повинні відповідати вимогам СН 4088-86 “Мікроклімат виробничих
приміщень”.
Кондиціонування повітря повинно забезпечувати автоматичну підтримку
параметрів мікроклімату у необхідних межах в перебіг усіх сезонів року,
очищення повітря від пилюки шкідливих речовин, створення невеличкого
надлишкового тиску у чистих приміщеннях для виключення надходження
неочищеного повітря. Необхідно також передбачити можливість
індивідуального регулювання роздачі повітря у окремих приміщеннях.
Температура повітря, яке подається, повинна бути не нижче 19°С.
Характеристика системи вентиляції наводиться в таблиці 5.4.
Таблиця 5.4 – Характеристика системи вентиляції
Виробниче приміщення Вид вентиляції Вентиляційне обладнання Кратність
повітряного обміну, 1/год
Відділ розробки програмного забезпечення штучна кондиціонер PHILIPS
4X12SG 1.2
Освітлення в приміщеннях операторних повинно бути змішаним, природним і
штучним.
Природне освітлення повинно здійснюватися у виді бічного освітлення.
Значення коефіцієнту природного освітлення повинно відповідати
нормативним рівням по СНІП 11-4-79 “Природне і штучне освітлення. Норми
проектування”. При виконанні роботи категорії високої зорової точності
цей показник повинен бути не нижче 1,5%, при роботі середньої точності –
не нижче 1,0%. Орієнтація світлоотворів для приміщень з ЕОМ повинна бути
північною.
Штучне освітлення в приміщеннях операторів варто здійснювати у виді
комбінованої системи освітлення з використанням люмінесцентних джерел
світла у світильниках загального освітлення. Для запобігання
підсвічування екранів дисплеїв прямими світловими потоками
застосовуються світильники загального освітлення, розташовані між рядами
робочих місць або зон із достатнім бічним освітленням. При цьому лінії
світильників розташовуються паралельно світлоотворам.
Освітлювальні установки повинні забезпечувати рівномірну освітленість за
допомогою переважно відбитого або розсіяного світлорозподілу. Вони не
повинні створювати світних відблисків на клавіатурі й інших частинах
пульта, а також на екрані. Для уникнення відблисків на екранах від
світильників загального освітлення необхідно застосовувати антиблікові
сітки, спеціальні фільтри для екранів, захисні козирки або розташовувати
джерела світла паралельно напрямку погляду на екран.
Місцеве освітлення забезпечується світильниками, встановленими
безпосередньо на столі або на його вертикальній панелі, а також
вмонтованими в козирок пульта. Якщо виникає необхідність використання
індивідуального світлового джерела, то він повинен мати можливість
орієнтації в різних напрямках І бути оснащений пристроєм для регулювання
яскравості і захисної сітки, що охороняє від осліплення і відбитого
блиску.
Джерела світла стосовно робочого місця розташовують таким чином,
виключити влучення в очі прямого світла. Захисний кут арматури в цих
джерел повинний бути не менше 30°.
Пульсація освітленості використовуваних люмінесцентних ламп не повинна
перевищувати 10%. При природному освітленні варто застосовувати засоби
сонцезахисту, що знижують перепади яскравостей між природним світлом і
світінням екрану. У якості таких засобів можна використовувати плівки з
металевим покриттям або регульовані жалюзі з вертикальними ламелями.
Крім того, рекомендується розміщення вікон з однієї сторони робочих
приміщень.
У полі зору оператора повинен бути забезпечений відповідний розподіл
яскравості. Відношення яскравості екрана до яскравості навколишніх його
поверхонь не повинно перевищувати в робочій зоні 3:1.
М’яке рентгенівське випромінювання, що виникає при напрузі на аноді
20-22 кВ, а також висока напруга на струмоведучих ділянках схеми
викликають іонізацію повітря, з утворенням позитивних іонів, що
вважаються несприятливими. Оптимальним рівнем аероіонізації в зоні
подиху працюючого рахується вміст легких аероіонів обох знаків від
1,5-102 до 5-103 у 1 см3 повітря.
Організацію робочого місця оператора необхідно здійснювати на основі
сучасних ергономічних вимог. Конструкція робочих меблів (столи, крісла
або стільці) повинна забезпечувати можливість індивідуального
регулювання
відповідно росту працюючого і створювати зручну позу. Часто
використовувані предмети праці й органи керування повинні знаходитися в
оптимальній робочій зоні.
Робочий стіл повинний регулюватися по висоті в межах 680-760 мм. При
відсутності такої можливості його висота повинна складати 720 мм.
Оптимальні розміри робочої поверхні стільниці 1600×900 мм. Під
стільницею робочого столу повинно бути вільний простір для ніг із
розмірами по висоті не менше 600 мм, по ширині 500 мм, по глибині 650мм.
На поверхні робочого столу для документів необхідно передбачати
розміщення спеціальної підставки, відстань якої від очей повинно бути
аналогічним відстані від очей до клавіатури що дозволяє знизити зорове
стомлення.
Розрахунок природної освітленості
1) Розглянемо схему приміщення, де встановлено персональний комп’ютер
(рисунок 5.1).
Рисунок 5.1 – Схема приміщення
На рисунку 5.1 показано:
– Lд- довжина приміщення: -5 м;
– Lш – ширина приміщення: – 3 м;
– l – глибина приміщення:- Зм;
– h – висота від рівня робочої поверхні до верхньої грані вікна: 1,8 м;
– Із – відстань від розрахункової точки до зовнішньої поверхні стіни 3,4
м;
– Lбуд – відстань між розрахунковим будинком і будинком навпроти: 15м;
– Нк – висота розміщення карнизу будинку навпроти над підвіконником
розрахункового вікна: 8,4 м.
2) По ширині приміщення яка не перевищує 12 м вибираємо бокове
одностороннє освітлення.
3) Визначаємо розряд роботи по зоровій напруженості і характеру зорової
роботи і по них визначаємо коефіцієнт освітлення: е =1.0%
4) По поясу світлового клімату визначаємо коефіцієнт світлового клімату:
т = 0.9.
5) По поясу світлового клімату і орієнтації вікон по сторонах горизонту
(на захід) визначаємо коефіцієнт сонячності: С = 0.85.
6) По коефіцієнтах е, м, С визначаємо нормоване значення коефіцієнта
природного освітлення ен:
ен = е?m?С = 1?0,9?0,85=0,765 (%)
(5.1)
7) Визначаємо відношення довжини приміщення до глибини приміщення:
Ld/l=5/3=1,7
(5.2)
8) Визначаємо відношення глибини приміщення до висоти від рівня робочої
поверхні до верху вікна:
1/h=3/1.8=1,7
(5.3)
бокових світлових прорізів (вікна) по відношеннях (5.1), (5.2) та
(5.3):
10) Визначаємо відношення відстані Lб між нашим приміщенням до висоти Нк
розміщення карнизу будинку навпроти над підвіконником вікна:
Lб/Нк= 15/8,4= 1.79
(5.4)
11) Визначаємо значення коефіцієнта Кб який враховує затіненість вії
будинком навпроти: Кб = 1
12) Визначаємо загальний коефіцієнт світло пропуску матеріалу:
(5.5)
13) Площа підлога:
Sпідлоги=15м2
14) Площа стелі:
Sстелі=15м2
15) Площа стін:
Sстін=48м2
16) Коефіцієнт відбиття від стін, підлоги і стелі:
Рстелі=70%, Рстін=70%, Рпідлоги=56%
17) Середньоваговий коефіцієнт відбиття:
рс = (70?48+70?15+56?15)/(48+15+1115)=67,3%
(5.6)
18) Площа підлоги освітлена вікнами:
ст) = 5 ? (3 – 0,3) = 13,5 (м2)
(5.7)
19) Площа світло прорізів вікон:
(5.8)
20) Необхідне число вікон:
(5.9)
На основі проведеного розрахунку можна зробити висновок, що в
приміщенні, що має вказані розміри, достатньо одного вікна площею 3.6
м2. Отже воно відповідає нормам природного освітлення.
5.3 Забезпечення безпеки експлуатації ЕОМ
Вимоги електричної і механічної безпеки для ЕОМ і систем обробки даних
встановлені ГОСТ 25861-83. Додаткові або особливі заходи безпеки, яких
необхідно дотримуватися при експлуатації і технічному обслуговуванні ЕОМ
і їх пристроїв, вказуються в їх ЕД
Особи, що допускаються до експлуатації і технічного обслуговування ЕОМ,
повинні пройти цільове навчання по вивченню правил роботи і вимог
безпеки при роботі з ЕОМ, а також ЕД на конкретні види ЕОМ, до роботи з
якими вони одержують допуск. До експлуатації ЕОМ допускаються особи, що
мають групу по електробезпеці не нижче її, до технічного обслуговування
– групу ІІІ.
Для безпечної експлуатації ЕОМ в приміщенні, де вона встановлена,
повинні забезпечуватися кліматичні умови, встановлені ЕД
Всі пристрої ЕОМ підлягають захисному заземленню, за винятком пересувних
і переносних, в конструкції яких заземлення не передбачено.
Не допускається використовувати як захисне інформаційне заземлення, якщо
це не дозволено ЕД.
Електричний опір і міцність ізоляції в пристроях ЕОМ перевіряється
відповідно до ЕД з врахуванням наявності подвійної, підсиленої і
додаткової ізоляції.
Періодичній перевірці не рідше 1 разу на рік підлягає струм витоку
пристроїв ЕОМ, який не повинен перевищувати, мА:
0,25 – для пристроїв класу її;
0,75 – для ручних пристроїв класу І;
3,5 – для переносних пристроїв класу, і, стаціонарних – класу І з вилкою
і розеткою, стаціонарних – класу І, призначених для постійного
приєднання до мережі.
Для стаціонарних пристроїв класу І допускається струм витоку понад 3,5
мА до 5% споживаного струму за наступних умов:
– мережеві і заземлюючий проводи мають постійне з’єднання з пристроєм і
мережею будівлі,
– біля входу пристрою повинен бути попереджувальний напис «Великий струм
витоку! Перед підключенням приєднати заземлюючий провід»;
– перетин внутрішнього заземлюючого дроту пристрою не менше 1,2 мм2;
– як додатковий захист рекомендується індикація обриву захисного
заземлення.
Перевірка проводиться згідно ГОСТ 25861 – 83 для вторинних ланцюгів, що
не мають з’єднань із заземленням, за допомогою міліамперметра, яким
вимірюється струм між заземлюючим елементом пристрою і проводами
вторинного ланцюга по черзі
Враховуючи велику щільність монтажу в пристроях ЕОМ, при їх технічному
обслуговуванні повинні забезпечуватися шляхи витоку, повітряні зазори і
відстані по ізоляції в ланцюгах, пошкодження ізоляції яких може привести
до ураження електричним струмом. При кожному регламентованому технічному
обслуговуванні шляху витоку в ланцюгах напругою вище 42 В повинні
очищатися від пилу шляхом протирання спиртом або іншим нейтральним
розчинником, а пошкоджені місця ізоляції повинні покриватися Ізоляційним
лаком. При заміні елементів в цих ланцюгах повинні витримуватися
повітряні зазори між струмоведучими частинами і не допускатися гострі
виступи припою і виводів елементів.
При технічному обслуговуванні пристроїв ЕОМ підлягає обов’язковій
перевірці справність зовнішнього підключення ЕОМ до мережі і
підключаючих пристроїв. Проводи і кабелі не повинні мати пошкоджень
ізоляції і захисної оболонки, обривів жил у місцях приєднання. В місцях
введення у вхідні пристрої
проводи і кабелі повинні бути закріплені, щоб не створювати натягу
струмопровідних жил. З’єднувальні пристрої, зокрема вбудовані в ЕОМ,
повинні мати справні контакти, в з’єднувальних пристроях релейно
контактного типу контактний зазор у відключеному стані повинен бути не
меншим 3 мм
Стан внутрішньої проводки в пристроях ЕОМ підлягає перевірці при
регламентованому технічному обслуговуванні. Внутрішня проводка повити
мати трасування, опорне кріплення для запобігання натягу проводів і їх
з’єднань, додаткову ізоляцію або екранування для відділення проводів, що
знаходяться під основною напругою, від ланцюгів малої напруги. Внутрішня
проводка повинна мати ефективний захист від дотику з рухомими частинами
Жорсткі ізольовані провідники повинні розташовуватися так, щоб
забезпечувати повітряні зазори і шляхи витоку не нижче допустимих.
При регламентованому технічному обслуговуванні, обов’язковій перевірці з
періодичністю не рідше 1 разу на рік, підлягають захист пристроїв ЕОМ
від перевантажень по струму і виконаний на базі реле максимального
струму, захист від коротких замикань При заміні елементів захисту не
допускається застосовувати реле з самоповерненням.
Вентилятори, що встановлені на пристроях ЕОМ для їх охолодження в
робочому режимі, повинні проходити перевірку на безпеку експлуатації з
періодичністю і в об’ємах, вказаних в їх ЕД.
Всі блокування, що є на пристроях ЕОМ, повинні бути в справному стані і
підлягають перевірці при регламентованому технічному обслуговуванні.
Блокування, що відключається для проведення технічного обслуговування,
підлягає підключенню і перевірці після його закінчення Захисні
блокування від надзвичайно небезпечних дій (висока напруга, небезпечні
випромінювання і тд.) не повинні відключатися
Захисні огорожі (кожухи, сітки, бар’єри), що перегороджують доступ до
рухомих частин, ланцюгів високої напруги, газорозрядних трубок високого
тиску і т. д., повинні бути в справному стані, а дверці, що є на них,
повинні надійно утримуватися замками в закритому стані При необхідності,
якщо це передбачено конструкцією пристрою, захисна огорожа повинна бути
заземлена.
Пристрої ультрафіолетового випромінювання, при роботі яких утворюється
озон, або використовуються горючі рідини і гази, повинні експлуатуватися
із застосуванням засобів, що захищають персонал від випромінювання, а
також з дотриманням «Правил пожежної безпеки в газовій промисловості».
У пристроях введення і виведення інформації ЕОМ, а також в пристроях
відображення інформації з високовольтними телевізійними трубками при їх
роботі можуть створюватися і накопичуватися заряди статичної електрики,
тому вони повинні експлуатуватися із застосуванням засобів захисту від
статичної електрики, вказаних в ЕД. Ці засоби підлягають перевірці при
регламентованому технічному обслуговуванні пристроїв.
У пристроях ЕОМ, що працюють з порошками або виробляють пил при
нормальній роботі (паперовий пил), повинні бути в справності
пристосування, що перешкоджають розповсюдженню і забезпечують
накопичення відходів у визначених місцях.
Перевірка цих пристосувань і очищення пристроїв від накопичень пилу
повинні проводитися при технічному обслуговуванні з періодичністю,
встановленою в ЕД.
Попереджувальні написи про призначення і положення органів управління та
індикації підлягають перевірці при кожному технічному обслуговуванні
Написи, що стали непридатними, підлягають заміні або відновленню
Категорично забороняється на пристроях ЕОМ, що знаходяться під напругою.
– зняття і установка вентиляторів, блоків і вузлів,
– від’єднання і приєднання зовнішніх і внутрішніх роз’ємів,
– електромонтажні роботи по заміні електрорадіоелементів;
– заміна мережевих запобіжників.
ВИСНОВКИ
У процесі виконання дипломної роботи зроблена наступна робота:
досліджено архітектуру “клієнт-серверних”;
проаналізовано основні підходи до розробки програм даної архітектури;
розроблено дизайн;
розроблено базу даних;
розроблено клієнтську на серверну частини програми.
В роботі проведено значний аналітичний огляд літературних джерел,
досліджені основні підходи, що існують на сьогодні в областях розробки
програмного забезпечення з архітектурою “клієнт-сервер”. На основі
аналізу спроектовано і розроблено базу даних, серверну та клієнтську
частини.
ПЕРЕЛІК ПОСИЛАНЬ НА ДЖЕРЕЛА
1. А.Горєв, С.Макашарипов, Ю.Владімиров. “SQL Server 6.5 для
профессионалов”, – “Питер” Санкт-Петербург 1998
2. К.Ланг, Д.Чоу. “Публикация баз данных в Интернете”, – “Символ-Плюс”
Санкт-Петербург 1998
3. Д.Боуман, C.Эмерсон, М.Дарновски, “Практическое руководство по
SQL”, – “Диалектика” Киев 1997
4. Microsoft Press, “Секреты создания интрасетей”, – “Питер”
Санкт-Петербург 1998
5. http://www.citforum.ru
6. JDK API
7. Вейскас Джон. Эффективная работа с Access 7.0, – Санкт-Петербург:
1998
8. Дейт К. Введение в системы баз данных, – Москва: 2000
9. Руденко В.Д., Макарчук О.М., Патланжоглу М.О. Практичний курс
інформатики, – К: 1997
10. Послед Борис Access 2000. Базы данных и приложения. Лекции и
упражнения. – К: ДиаСофт. – 2000
11. Збірник нормативних документів з безпеки життєдіяльності.\Витяг з
державних санітарних правил і норм.- Під редак. проф.Сачкова Л.С.,-
Київ: 2000,- с.738-739.
12. Романов Г.М. Человек и дисплей. – Ленинград: 1989.
13. Сибаров Ю.Г.Охрана труда в вычислительных центрах. – Москва :
1990.
Змн.
Арк.
№ докум.
Підпис
Дата
Арк.
PAGE 2
Нашли опечатку? Выделите и нажмите CTRL+Enter
