Розробка гнучкої системи автоматизації відстеження дзвінків з мобільних телефонів

Размещено на http://www.allbest.ru/

Міністерство освіти і науки України

Криворізький інститут

Кременчуцького університету економіки, інформаційних технологій і управління

Кафедра технічної кібернетики

ДИПЛОМНА РОБОТА

зі спеціальності

7.091402 “Гнучкі комп'ютеризовані системи та робототехніка“

ПОЯСНЮВАЛЬНА ЗАПИСКА

«Розробка гнучкої системи автоматизації відстеження дзвінків з мобільних телефонів»

Студента групи ГКС-05-з Вишневського Костянтина Івановича

Керівник роботи ст. викл. Супрунова Юлія Анатоліївна

Кривий Ріг

2010

Анотація

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

Розроблена система реалізована в середовищі Delphi 7. Додатковою вимогою є встановлення пакету MS Excel, який необхідний для формування документів із вхідною інформацією.

Аннотация

Целью дипломной работы является разработка гибкой системы отслеживания звонков с мобильных телефонов. Разработанная система прошла апробацию в экспертно-криминалистическом отделе Криворожского городского управления УМВД Украины в Днепропетровской области.

Разработанная система реализована в среде Delphi 7. Дополнительным требованием является установка пакета MS Excel, который необходим для формирования документов с входящей информацией.

The summary

The purpose of the diploma is development of a flexible system for tracking calls from mobile phones. The developed system has been tested in the expertise and forensic department of Kriviy Rih urban management Ministry of Internal Affairs of Ukraine in the Dnipropetrovsk region

The developed system is realized in the environment of Delphi 7. Setting of package of MS Excel, which is required for the formation of documents with the incoming information.

ЗМІСТ

• ВСТУП
• 1. ПОСТАНОВКА ЗАВДАННЯ
• 1.1 Найменування та галузь використання
• 1.2 Підстава для створення
• 1.3 Характеристика розробленого програмного забезпечення
• 1.4 Мета й призначення
• 1.5 Загальні вимоги до розробки
• 1.6 Джерела розробки
• 2. DELPHI, ЯК ВІЗУАЛЬНЕ СЕРЕДОВИЩЕ РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ
• 2.1 З чого все починалося
• 2.2 Історія Delphi
• 2.3 Візуальне конструювання форм
• 2.4 Інтегроване середовище розробки
• 3. ОСНОВИ ТЕХНОЛОГІЇ ACTIVEX DATA OBJECTS (ADO)
• 3.1 Огляд технології ADO
• 3.2. Огляд технології OLE DB
• 3.3. Архітектура технології ADO
• 4. ТЕХНОЛОГІЯ DATASNAP
• 4.1 Багатокористувацькі інформаційні системи
• 4.1.1 Склад
• 4.1.2 Типові проблеми
• 4.1.3 Способи вирішення проблем
• 4.2 Введення в технологію DataSnap
• 4.3. Багатоланкові додатки
• 4.3.1 Структура багатоланкового додатку в Delphi
• 4.3.2 Триланковий додаток в Delphi
• 4.3.3 Сервер додатків
• 4.3.4 Клієнтський додаток
• 4.4. Механізм віддаленого доступу до даних DataSnap
• 4.4.1 Компонент TDCOMConnection
• 4.4.2 Компонент TSocketConnection
• 4.4.3 Компонент TWebConnection
• 4.4.4 Провайдери даних
• 4.4.5 Допоміжні компоненти - брокери з'єднань
• 5. ОПИС ФУНКЦІОНАЛЬНИХ МОЖЛИВОСТЕЙ ТА ПРОГРАМНОЇ РЕАЛІЗАЦІЇ ПРОЕКТОВАНОЇ СИСТЕМИ
• 5.1 Предметна область і задачі, покладені на гнучку систему автоматизації
• 5.2 Архітектура побудови проектованої системи
• 5.3 Схема інформаційних потоків проектованої системи
• 5.4 База даних PhoneInfo
• 5.5. Сервер додатків
• 5.5.1 Логіко - функціональна схема сервера додатків
• 5.5.2 Інтерфейс та програмна реалізація сервера додатків
• 5.6. Клієнтський додаток
• 5.6.1 Логіко - функціональна схема клієнтського додатку
• 5.6.2 Інтерфейс клієнтського додатку
• 5.6.3 Програмна реалізація проектованої системи
• end;6. ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ
• 6. ЕКОНОМІЧНЕ ОБҐРУНТУВАННЯ ДОЦІЛЬНОСТІ РОЗРОБКИ
• ПРОГРАМНОГО ПРОДУКТУ
• 6.1 Визначення витрат на створення програмного продукту
• 6.2 Витрати, пов'язані з розробкою програми на ПК
• 6.3 Визначення планованої економії від упровадження програмного продукту
• 7. ОХОРОНА ПРАЦІ
• 7.1 Аналіз небезпечних й шкідливих виробничих факторів
• 7.2 Заходи щодо нормалізації небезпечних і шкідливих факторів
• 7.3 Пожежна безпека
• ВИСНОВКИ
• СПИСОК ЛІТЕРАТУРИ

ВСТУП

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

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

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

Реалізація даної задачі проводиться у системі програмування Delphi 7 з використанням технологій ADO та DataSnap.

Delphi являє собою середовище програмування, яка призначена для створення комп'ютерних програм. Для забезпечення більш легкого і швидкого створення діючих програм Delphi включає до складу візуальне середовище програмування IDE (Integrated Development Environment). IDE служить для організації взаємодії з програмістом і містить безліч, створених розробниками, компонентів і, практично готових до використання, заготовок. Також Delphi має розвинені можливості по створенню призначеного для користувача інтерфейсу, широкий набір функцій, методів і властивостей для вирішення прикладних розрахунково-обчислювальних завдань.

Для спрощення доступу та обробки, дані повинні бути систематизовані і впорядковані в таблиці даних. Для управління систематизованими даними необхідна система управління базами даних (СУБД).

У даній дипломній роботі використовується СУБД MS SQL Server2000. Microsoft SQL Server - система управління реляційними базами даних, розроблена корпорацією Microsoft.

Microsoft SQL Server в якості мови запитів використовує версію SQL, що отримала назву Transact-SQL (скорочено T-SQL), яка є реалізацією SQL-92 (стандарт ISO для SQL) з множинними розширеннями. T-SQL дозволяє використовувати додатковий синтаксис для збережених процедур і забезпечує підтримку транзакцій (взаємодія бази даних з керуючим додатком). Microsoft SQL Server також підтримує Open Database Connectivity (ODBC) - інтерфейс взаємодії додатків з СУБД.

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

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

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

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

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

Початок робіт: 01.11.09. Закінчення робіт: 25.05.10.

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

Розроблена система реалізована в середовищі Delphi 7. Система повинна функціонувати під керуванням операційної системи Windows ХР. Додатковою вимогою є встановлення пакету MS Excel, який необхідний для формування вхідних документів системи та наявність встановленого сервера баз даних MS SQL Server 2000, на якому буде розгорнута база даних для зберігання необхідної інформації для роботи даної системи.

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

Головним завданням системи є обробка вхідних даних та генерація наступної вихідної інформації:

- Інформація щодо здійснення дзвінків з певного телефонного номера, з телефону з певним IMEI та за певний проміжок часу;

- Інформація щодо кількості дзвінків між двома абонентами

До складу системи входять:

· Client.exe - виконавчий файл для користувача розробленої системи;

· Server.exe - - виконавчий файл - сервер додатків, який може бути розташований на будь-якому комп'ютері, що підключений до локальної мережі;

· PhoneInfo_Data.MDF - файл, що містить таблиці баз даних, і який може бути розташований на будь-якому комп'ютері, де інстальована СУБД MS SQL Server 2000 і що підключений до локальної мережі;

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

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

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

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

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

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

· Простота й зрозумілість інтерфейсу.

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

· IBM-сумісний комп'ютер, не нижче Pentium IІ, RAM-128Mb, SVGA-800*600*16bit;

· Вільний простір на жорсткому диску не менш 2 Мб.

· Наявність СУБД MS SQL Server 2000 і локальної мережі;

· Додаткове програмне забезпечення: встановлення пакету MS Excel, який необхідний для формування вхідних документів системи.

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

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

· загальний опис технології процесу;

· опис інформаційних потоків в експертно-криміналістичному відділі Криворізького міського управління УМВС України в Дніпропетровській області;

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

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

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

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

2. DELPHI, ЯК ВІЗУАЛЬНЕ СЕРЕДОВИЩЕ РОЗРОБКИ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ

2.1 З чого все починалося

З початку ніяких мов програмування не було - для перших ЕОМ програми писалися на "чистій" машинній мові. Це було дуже важким і копітким заняттям. Потім комусь спало на думку, що простіше створити програму, яка сама буде переводити вихідний код, написаний за певними правилами, в машинну мову. Так з'явився перший компілятор - Асемблер. Компілятор - програма, яка переводить вихідний програмний код в машинну мову, і створює повноцінний виконуваний програмний файл. Такі файли можуть мати розширення *. com і *. exe. Розширення *. com зрідка ще зустрічаються в старих програмах, які створювалися під операційну систему MS-DOS. Всі сучасні програми, створені для Windows, мають розширення *. exe.

Також існують інтерпретатори - програми, які не створюють виконуваний програмний файл. Інтерпретатори представляють собою оболонку, в яку потрібно завантажити файл з вихідним текстом програми, потім інтерпретатори порядково переводять код в машинну мову, і виконують його. Найбільш відомим інтерпретатором є класичний Бейсік (Basic). Незручність використання інтерпретаторів та програмного забезпечення, створеного на них, не дозволяють використовувати їх широко. Для розповсюдження програм, створених на інтерпретаторі, необхідно на комп'ютер користувача встановити не тільки написану програму, але і сам інтерпретатор. А користувачу доведеться навчитися користуватися цим інтерпретатором (завантажувати в нього програму, давати команду на виконання), а також навчитися користуватися самою програмою. Проте в деяких випадках інтерпретатори бувають вельми корисні, наприклад, інтерпретатори PHP і Perl, що використовуються в Web-програмуванні, виконуються на стороні сервера, і не доставляють користувачеві проблем.

Асемблер найбільш наближений до машинного мови, тому його називають мовою низького рівня. Писати програми на Асемблері було простіше, ніж "чистою машинною" мовою, в результаті програми створювалися швидше. Ринок програмного забезпечення має одну важливу властивість - лідирує та програма, яка з'явилася на ринку раніше. Створювати програми на Асемблері стало не тільки простіше, але і вигідніше.

Створення Асемблера сприяло бурхливому розвитку мов програмування. З'явилося безліч мов високого рівня - C, C + +, Pascal і багато інших. Правила створення коду на мовах високого рівня більш наближені до людських мов, тому програми на таких мовах створювалися ще простіше й швидше. Мови програмування стали удосконалюватися не по днях, а по годинах. Перші мови високого рівня були процедурними - в них логіка програми будувалася на використанні функцій і процедур, які можна викликати з будь-якого місця програми.

Потім з'явилися об'єктні мови програмування. У них логіка програми будувалася на об'єктах, кожний з яких мав власні властивості, методи та події, які могли бути успадковані нащадками цього об'єкту. Іншими словами, створення програм багаторазово полегшувалося - замість того, щоб написати десяток сторінок коду, достатньо було просто оголосити такий то об'єкт. Такі мови стали називати об'єктно-орієнтованими (ООП - Об'єктно-орієнтоване програмування).

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

2.2 Історія Delphi

Історія Delphi починається з 60-х років, коли професор Н. Вірт розробив мова високого рівня Pascal. Це була найкращий мова для вивчення програмування, і для створення програм для операційної системи MS-DOS. Потім, в 1983 році, А. Гейлсберг спільно з іншими програмістами, які тільки що організували компанію Borland, розробив компілятор Turbo Pascal, який став наступним кроком в еволюції Delphi. Потім з'явився Object Pascal, який вже використовував об'єктно-орієнтований підхід до програмування. Коли з'явилася перша версія Windows - Windows 3.10, Програмісти Borland створили Delphi 1. Це вже була об'єктно-орієнтоване середовище для візуальної розробки програм, заснована на мові Object Pascal.

З появою Windows 95 з'явилася Delphi 2, потім Delphi 3, 4, 5. Мова програмування Object Pascal, який був стрижнем Delphi, перетерпів такі суттєві зміни, що з появою Delphi 6 компанія Borland, яка вже перетворилася на корпорацію, офіційно оголосила про перейменування Object Pascal в Delphi. Тому мають рацію ті, хто говорить, що Delphi - це візуальне середовище розробки програм. Але також мають рацію і ті, хто стверджує, що Delphi - це один з кращих мов програмування.

Основу Delphi становить не тільки сама мова, але й RAD (Rapid Application Development) - середовище швидкої розробки програм. Завдяки візуальному програмуванню, а також досить великий бібліотеці візуальних компонентів, Delphi дозволяє створювати програми найбільш швидко і ефективно, приймаючи на себе основну роботу, і залишаючи програмісту творчий процес. Зрозуміло, можливість швидкого створення професійних додатків для Windows робить Delphi - програмістів затребуваними в усіх галузях людської діяльності.

2.3 Візуальне конструювання форм

Система Delphi є однією з кращих розробок в сучасній теорії і практики програмування. Як будь-яка подібна система, Delphi призначена для розробки програм і має дві характерні особливості:

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

Це прискорення досягається за рахунок наступних властивостей Delphi:

візуального конструювання форм і широкого використання бібліотеки візуальних компонентів.

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

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

2.4 Інтегроване середовище розробки

Інтегроване середовище розробки (Integrated Development Environment - IDE) - це середовище, в якому є все необхідне для проектування, запуску і тестування додатків і де все націлено на полегшення процесу створення програм. IDE інтегрує в собі редактор кодів, відладчик, інструментальні панелі, редактор зображень, інструментарій баз даних - все, з чим доводиться працювати.

Рис. 2.1 Головні вікна Delphi

1. Головне вікно програми. У головному вікні програми знаходиться основне меню, панелі інструментів і палітра компонентів, які дозволяють здійснювати управління як проектом, так і самою програмою.

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

3. Інспектор об'єктів. Він забезпечує простий і зручний інтерфейс для зміни властивостей об'єктів Delphi та управління подіями, на які реагує об'єкт. Вікно Інспектора Об'єктів має дві сторінки. У верхній частині вікна є випадаючий список всіх компонентів, розміщених на формі. У ньому можна вибрати той компонент, властивості та події якого цікавлять.

Сторінка властивостей (Properties) Інспектори Об'єктів показує властивості того об'єкта, який в даний момент виділено вами.

Сторінка подій (Events) становить другу частину Інспектора Об'єктів. На ній зазначені всі події, на які може реагувати вибраний об'єкт.

4. Форма. Основою майже всіх додатків Delphi є форма. Її можна розуміти як типове вікно Windows. Форма є основою, на якій розміщаються компоненти інтерфейсу користувача та є однією із важливіших складових візуального програмування.

5. Редактор коду. Однією з найбільш важливих частин середовища Delphi є вікно редактора коду. Його вигляд і можливості змінюються від версії до версії. Редактор Коду в Delphi 7 має дві сторінки: Code (код) і Diagram (діаграми). Перша з них містить коди модулів програми та тексти інших файлів, які відкриті в процесі проектування. Друга сторінок дозволяє будувати діаграми, що ілюструють взаємини компонентів у додатку. Ця сторінка є повноцінним програмним редактором. Її можна налаштовувати на різний стиль роботи. У редакторі застосовується виділенням кольором і шрифтом синтаксичних елементів.

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

3. ОСНОВИ ТЕХНОЛОГІЇ ACTIVEX DATA OBJECTS (ADO)

Доступ до даних є найважливішою вимогою при розробці сучасних бізнес-додатків. Технологія ODBC забезпечує доступ до реляційних баз даних і це перший крок на шляху вирішення цієї проблеми. Однак, коли розроблювачі хочуть включити у свої проекти не реляційні джерела даних або працювати в середовищах, подібних Інтернет, вони стикаються з дилемою - або розробляти власні парадигми доступу до даних, або працювати на рівні API, що несумісне з новими середовищами. ActiveX об'єкти доступу до даних (ActiveX Data Object) вирішують цю дилему і забезпечують єдину модель, що працює з усіма джерелами даних у різних середовищах. У такий спосіб ADO забезпечує послідовний, високопродуктивний доступ до даних, із якими можливо створювати клієнтські програми для роботи з БД або бізнес-об'єкти середнього рівня, що використовують додатки, інструментарій, мова або, навіть, Інтернет-переглядач (Internet Explorer). ADO - це єдиний інтерфейс доступу до даних, що необхідний для створення одне- і багаторівневих додатків архітектури клієнт/сервер і Web-орієнтованих інформаційних систем.

3.1 Огляд технології ADO

Технологія ADO була вперше застосована в Microsoft Internet Information Server як інтерфейс доступу до БД. Використання ADO дозволяє мінімізувати мережний трафік у ключових Internet-сценаріях і зменшити кількість проміжних рівнів між клієнтським додатком і джерелом даних. ADO легко використовувати, тому що він (або вони (об'єкти) або вона (технологія)) застосовує звичну систему викликів - інтерфейс Автоматизації OLE, доступний сьогодні в більшості засобів розробки додатків. Через легкість застосування й вивчення популярність ADO буде рости й у підсумку ADO витисне технології RDO і DAO, що у даний час застосовуються дуже широко. Технологія ADO багато в чому подібна до RDO і DAO, наприклад, вона використовує ті ж угоди мови. ADO також підтримує аналогічну семантику і тому може бути легко освоєна розроблювачами ПЗ.

ADO є інтерфейсом програмного рівня до OLE DB, новітній і наймогутнішої парадигмі доступу до даних від MS. OLE DB забезпечує високопродуктивний доступ до багатьох джерел даних. ADO і OLE DB разом являють собою основу стратегію універсального доступу до даних (Universal Data Access). OLE DB дає можливість універсального доступу до багатьох даних і представляє розроблювачам можливість зробити це досить легко. Тому що ADO знаходиться на вершині OLE DB, те застосування ADO має всі привілеї універсального доступу до даних, що забезпечує OLE DB.

3.2 Огляд технології OLE DB

OLE DB - це відкрита специфікація, розроблена на основі успіху специфікації ODBC і забезпечує відкритий стандарт доступу до усіх видів даним у системах масштабу підприємства. OLE DB - це ядро технології підтримуючий універсальний доступ до даних. На відміну від технології ODBC, що була створена для доступу до реляційних БД, технологія OLE DB розроблена для реляційних і не реляційних джерел даних, таких як сховища пошти (mail stores), текстів і графіки для Web, служби каталогів (directory services), IMS і VSAM сховищ даних на мейнфреймах.

Компоненти OLE DB складаються з провайдерів даних (data providers), що представляють свої дані, споживачів даних (data consumers), що використовують дані, і сервісних компонентів (service components), що обробляють і транспортують дані (наприклад, процесор запитів і механізм курсорів). OLE DB містить у собі міст із ODBC, щоб дати можливість розроблювачам використовувати ODBC-драйвера реляційних БД, широко розповсюджені в даний час.

3.2.1 OLE DB провайдери

Існує два типи OLE DB додатків: споживачі й провайдери. Споживачами можуть бути будь-які додатки, що використовують OLE DB інтерфейси. Наприклад, Delphi додаток, що використовує OLE DB інтерфейси для зв'язку із сервером БД - це OLE DB споживач. Об'єктна модель ADO, що використовує OLE DB інтерфейси, - це теж OLE DB споживач. Будь-який додаток, що використовує ADO, побічно використовує OLE DB інтерфейси через об'єкти ADO.

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

Microsoft OLE DB SDK version 1.1 поставляє два OLE DB провайдери: ODBC провайдер і провайдер текстів. Провайдер текстів є прикладом, що демонструє докладну реалізацію OLE DB провайдеру. ODBC провайдер - це OLE DB провайдер для ODBC драйверів. Цей провайдер надає механізм для споживачів, щоб використовувати існуючі ODBC драйвери без необхідності термінової заміни існуючих ODBC драйверів на нові OLE DB провайдери.

3.2.2 ODBC провайдери

ODBC провайдер встановлює відповідність між OLE DB інтерфейсами і ODBC API. З ODBC провайдером OLE DB споживачі можуть зв'язуватися із сервером БД через існуючі ODBC драйвери. Споживач викликає OLE DB інтерфейс через ODBC провайдеру. ODBC провайдер викликає відповідні ODBC API інтерфейси і посилає запити до ODBC драйвера. Метою розробки ODBC провайдеру є здійснення усієї функціональності менеджера ODBC драйвера. Тому тепер немає необхідності в менеджері ODBC драйвера. Однак при використанні ODBC провайдером версії 1.1 менеджер ODBC драйвера усе ще потрібно для підтримки зв'язку з ODBC додатками.

3.3 Архітектура технології ADO

ADO засновано на технології COM (Component Object Model) - компонентній об'єктній моделі. Всі об'єкти й інтерфейси ADO є інтерфейсами й об'єктами COM.

Рис. 3.1 Архітектура ADO

3.3.1 Огляд компонентів ADO в середовищі Delphi

Для роботи з ADO на вкладці компонентів ADO є шість компонентів: TADOConnection, TADOCommand, TADODataSet, TADOTable, TADOQuery, TADOStoredProc.



Рис. 3.2 Палітра компонентів ADO

TADOConnection аналогічний компонентові BDE TDatabase і використовується для вказівки бази даних і роботи з транзакціями.

TADOTable - таблиця доступна через ADO.

TADOQuery - запит до бази даних. Це може бути як запит, у результаті якого повертаються дані і бази (наприклад, SELECT), так і запит не повертає даних (наприклад, INSERT).

TADOStoredProc - виклик збереженої процедури. На відміну від BDE і InterBase збережені процедури в ADO можуть повертати набір даних, по цьому компонент даного типу є нащадком від TDataSet і може виступати джерелом даних у компонентах типу TDataSource.

TADOCommand і TADODataSet є найбільше загальними компонентами для роботи з ADO, але і найбільш складними в роботі. Обидва компоненти дозволяють виконувати команди мовою провайдера даних (так у ADO називається драйвер бази даних).

Різниця між ними в тім, що команда, що виконується через TADODataSet, повинна повертати набір даних і цей компонент дозволяє працювати з ними засобами Delphi (наприклад, прив'язати компонент типу TDataSource). А компонент TADOCommand дозволяє виконувати команди не повертають набір даних, але не має штатних засобів Delphi для наступного використання повернутого набору даних.

Очевидно, що усі компоненти повинні зв'язуватися з базою даних. Робиться це двома способами або через компонент TADOConnection або прямим указівкою бази даних в інших компонентах. До TADOConnection інші компоненти прив'язуються за допомогою властивості Connection, до бази даних прямо через властивість ConnectionString.

База даних може бути зазначена двома способами через файл лінка до даних (файл у форматі Microsoft Data Link, розширення UDL), або прямим завданням параметрів з'єднання.

Значення властивості всіх ConnectionString цих компонентів можуть бути введені прямо в текстовій формі, але куди простіше викликати редактор властивості натиснувши на кнопку «…» наприкінці отримавши введення. Вікно цієї властивості виглядає так:

Рис. 3.3 Вікно властивості ConnectionString

При виборі «Use data link file» і натисканні на кнопку «Browse...» з'являється стандартний діалог вибору файлу. Цей файл можна створити в будь-якому вікні explorer-а (у цьому вікні відкриття файлу, у самому explorer, на desktop і т.д.) викликавши контекстне меню і вибравши пункт «New/Microsoft Data Link». Потім викличте локальне меню для створеного файлу і виберіть у ньому пункт «Open». Після цього з'явиться property sheet описаний трохи нижче. Ці ж вкладки містить і property sheet, викликуваний через пункт «Property» локального меню UDL файлу, але в ньому ще є вкладки стосовні до самого файлу.

Використання файлів Microsoft Data Link спрощує підтримку додатків, тому що можливо використовувати засобу Windows для настроювання додатка.

При виборі в редакторі властивості «Use connection string» і натисканні на кнопку «Build...» з'являється такою же property sheet, як і при виборі «Open» для Microsoft Data Link файлу.

У цьому вікні вибирається тип бази даних, місце розташування бази і параметри з'єднання.

На першій сторінці вибирається тип бази даних або Provider, у термінах ADO.

Рис. 3.4 Вибір типу бази даних (провайдера)

Бази MS Access доступні як через «Microsoft Jet OLE DB Provider», так і через «Microsoft OLE DB Provider for ODBC».

Наступна сторінка залежить від обраного типу бази, однак для всіх типів є кнопка «Test connection» що дозволяє перевірити правильність і повноту параметрів.

Для «Microsoft Jet OLE DB Provider» вона виглядає так:

Рис. 3.5 Вибір джерела бази даних

Checkbox «Blank password» придушує діалог введення ідентифікатора і пароля користувача при встановленні з'єднання, якщо поле пароля порожнє.

Checkbox «Allow saving password» зберігає пароль у рядку параметрів з'єднання. Якщо він не відзначений, то введений пароль буде використовуватися тільки при виконанні тестового з'єднання.

Для «Microsoft OLE DB Provider for ODBC» ця сторінка виглядає так:



Рис. 3.6 Вибір джерела бази даних

Радіокнопка «Use data source name» дозволяє ввести аліас ODBC, а через «Use connection string» уводиться як аліаси так і тип ODBC драйвера і параметри з'єднання.

Параметри ідентифікації користувача аналогічні вище описаним.

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



Рис. 3.7 Встановлення додаткових параметрів

На сторінці «All» можна відредагувати всі параметри з попередніх сторінок і параметри залежні від провайдера, але не ввійшли на сторінку «Connection». Редагування здійснюється у виді параметр - значення, причому в текстовій формі, ніяких діалогів немає. Допомоги те ж ні, ці параметри описані тільки в документації на провайдер. Її можна знайти в MSDN Data Access Services/Microsoft Data Access Components (MDAC) SDK/Microsoft Active Data Objects (ADO)/Microsoft ADO Programmer's Reference/Using Providers with ADO.



Рис. 3.8 Сторінка з усіма доступними параметрами відкриття

У компоненті TADOConnection є властивості Provider, DefaultDatabase і Mode які є альтернативним методом завдання частин рядка параметрів з'єднання - провайдеру, бази даних (наприклад, шляхи до бази MS Access) і режиму спільного використання файлів бази даних. Ці значення цих властивостей автоматично включаються в рядок з'єднання, якщо були задані до активізації компонента й автоматично виставляються після з'єднання.

3.3.2 Інтерфейси архітектури ADO

Інтерфейс Connection

Об'єкти цього типу виконують наступні функції:

· зв'язок із сервером

· керування транзакціями

· одержання інформації про помилки, що відбулися, (властивість Errors)

· одержання інформації про схему даних (таблиці, поля і т.д.)

Рис. 3.9 Схема взаємодії в ADO основних COM інтерфейсів

Інтерфейси Recordset і Field

Інтерфейс Recordset (на нижньому рівні ADO це IRowset) є аналогом TDataSet у Delphi.

Підтримує поточне положення і переміщення курсору, закладки (bookmarks), читання, зміна і видалення записів і так далі. Значення полів і їхніх типів доступні за допомогою властивості Fields.

Інтерфейс Field дозволяє одержувати значення полючи, його тип довжину і так далі.

Інтерфейси Command і Parameter

Ці два типи дозволяють працювати з командами джерела даних. Синтаксис команд для кожного з джерел свій.

Інтерфейс Property

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

Бібліотека досить заплутана, багато функцій дубльовані в різних об'єктах. Наприклад, Recordset можна створювати прямо, методом Open, (причому попередньо створювати Connection не обов'язково), можна одержати як результат виконання методу Command.Execute, або після Connection.Execute задавши команду без параметрів.

Особливості інтерфейсу Command та RecordSet

Інтерфейс Command інкапсульований в усі компоненти за винятком TADOConnection. Це зроблено тому, що в ADO немає можливості одержати дані не виконавши команду.

Інтерфейс Recordset інкапсульований у компоненти похідні від TCustomADODataSet. Це компоненти TADODataSet, TADOTable, TADOQuery, TADOStoredProc. Одержувати дані з них можливо штатними засобами Delphi.

Можливе одержання даних і при виконанні компонента TADOCommand. Метод цього компонента Execute повертає тип _Recordset. Після чого його можна, наприклад, зв'язати з компонентом TADODataSet у такий спосіб

ADODataSet1.RecordSet := ADOCommand1.Execute;

Компоненти TADOTable, TADOQuery і TADOStoredProc є окремими випадками команди, відповідно для таблиці, SQL запиту і збереженої процедури.

Тип Connection інкапсулюється в компонент TADOConnection.

Коли ви виконуєте команду попередньо не відкриваючи з'єднання, воно все рівно створюється. Одержати до нього доступ можливо через властивість Recordset. Прив'язати компонент TADOConnection до уже відкритого з'єднання можливо через властивість ConnectionObject.

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

3.3.3 Використання компонента TADOConnection

У цьому прикладі розглядається робота з компонентом TADOConnection, SQL запитами з параметрами і трансакціями.

Створимо додаток з наступних компонентів

Connect типу TADOConnection

MasterSQL і DetailSQL типу TADODataSet

MasterDS і DetailDS типу TDataSource

MasterGrid і DetailGrid типу TDBGrid

Рис. 3.10 Master-detail форма на етапі дизайну

Зв'язуємо MasterGrid, MasterDS, MasterSQL і DetailGrid, DetailDS, DetailSQL аналогічно попередньому прикладові, за винятком того, що замість типу TADOTable використовується тип TADODataSet.

Прив'язуємо Connect до бази даних. Для цього в редакторі властивості ConnectionString вибираємо ту ж базу даних, що й у попередньому прикладі.

Для введення SQL запитів необхідно відредагувати властивість CommandText компонентах MasterSQL і DetailSQL. Після натискання на кнопку "SQLString" з'явиться редактор компонентів, що виглядає в такий спосіб:

Рис. 3.11 Редактор SQL-запита

Кнопка «Add Table to SQL» додає в текст SQL запиту таблицю, обрану в списку «Tables», а «Add Field to SQL» поле таблиці, обране в списку «Fields».

Запит для MasterSQL

select VendorNo, VendorName, Country, City, State, Preferred

from vendors

Запит у DetailSQL повинний вибирати тільки ті деталі, постачальник яких є поточним у MasterSQL. Для цього установимо властивість DataSource компонента DetailSQL у значення MasterDS.

select PartNo, OnOrder, OnHand, ListPrice, Description, Cost

from parts

where VendorNo = :VendorNo

Запит для DetailSQL наступний:

VendorNo у частині where - параметр запиту. Параметри при встановленому DataSource беруться з нього.

Активізуємо MasterSQL і DetailSQL аналогічно попередньому прикладові.

Додаток можна запускати. Цей приклад можна знайти в директорії MasterDetail.

3.3.4 Використання параметрів запиту

Тепер обмежимо вибірку постачальників за значенням полючи State. Для цього додамо до форми наступні компоненти StateEdit типу TEdit c вкладки Standard, QueryButton типу TButton c вкладки Standard

Змінимо запит у MasterSQL на

:StateID - параметр, замість якого при виконанні підставляється значення.

select VendorNo, VendorName, Country, City, State, Preferred

from vendors

where State = :StateID

Додамо так само обработчик події OnClick у QueryButton наступного змісту

procedure TForm1.QueryButtonClick(Sender: TObject);

begin

MasterSQL.Active := False;

DetailSQL.Active := False;

MasterSQL.Parameters.ParamByName('StateID').Value := StateEdit.Text;

MasterSQL.Active := True;

DetailSQL.Active := True;

end;

Програма готова. Цей приклад можна знайти в директорії Param.

3.4.5 Синхронізація даних клієнта і сервера

У ADO використовуються три методи синхронізації даних на клієнті і сервері.

Перший - c допомогою методу Resync, що повторно зчитує запису набору. Цей метод використовується при виконанні методу Refresh Delphi.

Другий - повторний запит методом Requery, що заново виконує запит на сервері. Виконання цього методу те ж саме, що і виконання підряд закриття і відкриття набору даних.

Третій - повідомлення сервером клієнта у випадку зміни даних.

Ці методи доступні у всіх компонентах даних, що мають набір. Однак ці функції доступні не для всіх баз даних.

3.4.6 Робота з транзакціями

У компонентах ADO робота з транзакціями здійснюється через компонент TADOConnection.

Тип транзакції встановлюється у властивості IsolationLevel однієї з наступних констант:

Таблиця 3.1

Список констант

IlUnspecified	Сервер буде використовувати кращий, на його думку, тип ізоляції.
IlChaos	Транзакції з більш високим рівнем ізоляції не можуть змінювати дані змінені, але не підтверджені в поточної транзакції.
IlReadUncommitted	Читання даних змінених у не підтверджених транзакцій. Тобто зміни видні відразу після того як інша транзакція передала них на сервер.
IlBrowse	Те ж саме що і IlReadUncommitted
IlReadCommitted	Читання даних змінених підтвердженими транзакціями. Тобто зміна даних буде очевидно після виконання Commit в інший транзакції.
IlCursorStability	Те ж саме що і IlCursorStability.
IlRepeatableRead	Зміни, зроблені іншими транзакціями не видимі, але при виконанні перезапиту вони транзакція може одержувати новий набір даних.
IlIsolated	Трансакція не бачить змін даних зроблених іншими транзакціями.
IlSerializable	Те ж саме що і IlIsolated.

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

Властивість Attributes установлює чи відкривати нову транзакцію автоматично

xaCommitRetaining - при підтвердженні транзакції

xaAbortRetaining - при скасуванні транзакції

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

BeginTrans Починає транзакцію

CommitTrans Підтверджує зроблені зміни

RollbackTrans Відкочує транзакцію.

3.4.7 Атрибути доступу до даних

На відміну від BDE, ADO підтримує більше настроювань роботи даних.

У ADO є поняття набору даних (recordset) і тісно зв'язане з ним поняття курсору (cursor). Що таке курсор у документації на ADO не описане. Однак чому те місце розташування набору даних називається положенням курсору. Я думаю, що це термінологічна плутанина в Microsoft і курсор той же саме що набір даних.

В усіх компонентах що мають набір даних (тобто в TADODataSet, TADOTable, TADOQuery, TADOStoredProc) є властивості CursorLocation, CursorType, LockType і MarshalOptions, що встановлюють параметри обміну із сервером. Усі ці властивості повинні бути встановлені до того, як набір даних відкривається. Якщо ви установите їх пізніше, те ефекту не буде.

CursorLocation - визначає, де виконується робота з набором на клієнті (clUseClient) або на сервері (clUseServer). Якщо набір даних розташований на клієнті, то із сервера дані запитуються однократно (або до виконання повторного запиту), надалі уся вибірка даних і позиціювання йде на клієнті. Однак модифікація даних виробляється негайно.

CursorType - установлює тип курсору. Значення одне з:

ctUnspecified - бібліотека ADO сама визначає оптимальний тип блокування.

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

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

ctDynamic - динамічний курсор. Додавання, зміни і видалення іншими користувачами видимі і можливі всі типи пересування по наборі даних. Закладки (bookmarks) можливі тільки, якщо провайдер даних них підтримує.

ctKeyset - курсор набору даних. Аналогічний динамічному курсорові, за винятком того, що ви не побачите записи додані іншими користувачами, а записи вилучені іншими користувачами недоступні з вашого набору даних. Зміни даних іншими користувачами видимі.

Треба помітити, що TDBGrid і інші компоненти, що одночасно працюють з декількома записами, можуть працювати тільки коли закладки підтримуються. Тому для компонентів з якими ви будите зв'язувати такі компоненти повинні використовуватися типи ctKeyset або ctDynamic.

LockType - визначає тип блокування записів у наборі даних. Воно з:

ltUnspecified - бібліотека ADO сама визначає який тип буде використовуватися.

ltReadOnly - тільки читання, зміна даних неможливо.

ltPessimistic - песимістичне блокування. Запис блокується відразу після початку редагування і до збереження записів.

ltOptimistic - оптимістичне блокування. Запис блокується тільки коли зміни зберігаються.

ltBatchOptimistic - теж саме що і ltOptimistic, але використовується відкладене збереження змін записів. Більш докладно вона розглядається в наступному пункті.

MarshalOptions - це властивість визначає чи будуть відправлені на сервер ті полючи, що не були змінені. При значенні moMarshalAll будуть, а при moMarshalModifiedOnly не будуть.

4. ТЕХНОЛОГІЯ DATASNAP

delphi дзвінок відстеження автоматизація

Технологія DataSnap призначена для створення за допомогою Delphi і подальшої експлуатації віддалених серверів автоматизації, що надають своїм контролерам доступ до даних серверних СУБД (в даному випадку вони звичайно називаються серверами доступу до даних).

4.1 Багатокористувацькі інформаційні системи

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

4.1.1 Склад

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

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

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

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

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

У разі серверних СУБД до цього набору додаються засоби взаємодії користувацького програми та сервера баз даних, що використовують ту ж саму підтримку мережевих протоколів операційними системами. Ці засоби зазвичай включають клієнтську частину серверної СУБД, що містить, як правило, низькорівневий інтерфейс для взаємодії з сервером баз даних. Крім цього, засоби забезпечення доступності даних нерідко містять бібліотеки, які реалізують якийсь універсальний механізм доступу до даних. Ці функції спрощують використання клієнтської частини, якщо СУБД серверна, або реалізують стандартні операції з даними, якщо СУБД не є серверною. У разі користувальницьких додатків, створених за допомогою засобів розробки Borland, це бібліотека Borland Database Engine (BDE) з драйверами SQL Links, бібліотеки dbExpress, а також бібліотеки ADO (ActiveX Data Objects), ODBC-драйвери і OLE DB-провайдери.

4.1.2 Типові проблеми

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

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

Рис. 4.1 Класична інформаційна система

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

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

Наступний фактор безпосередньо пов'язаний з тим, що багато засобів розробки використовують одні й ті ж стандартні бібліотеки доступу до даних (у випадку Windows це ADO, ODBC, іноді BDE). На сьогоднішній день є чимала кількість різних програмних продуктів, що містять будь-які дані (особливо енциклопедій й довідників), при встановленні яких встановлюються і ці бібліотеки (подібні дії дозволені при певних умовах виробниками цих бібліотек). У цьому разі, особливо при застосуванні бібліотек BDE, немає стовідсоткової гарантії, що версія будь-який з подібних бібліотек, що входить в комплект поставки такого роду продукту, виявиться новіше, ніж встановлена в корпоративній інформаційній системі, і що програма установки «чужого» продукту не внесе змін в налаштування, що супроводжують цю бібліотеку, таким чином, що працездатність вашої, вже встановленою, інформаційної системи виявиться порушеною. Подібна ситуація, звичайно, суперечить правилам створення дистрибутивів, але такі випадки час від часу трапляються навіть з непоганими комерційними продуктами, при цьому далеко не у всіх організаціях діють жорсткі обмеження на застосування тих чи інших програмних продуктів на робочих місцях користувачів.

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