загальнокорпоративне централізоване сховище даних;

тематичні вітрини даних на рівні підрозділів;

робочі місця кінцевих користувачів.

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

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

статичні, що включають визначений набір сценаріїв обробки даних і складання звітів (інформаційні системи керівника - ІСК);

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

СППР, створювані в розрахунку на безпосереднє використання особами, що приймають рішення, являються надзвичайно простими в застосуванні, але жорстко обмеженими у функціональності. Такі статичні СППР [44], або Інформаційні системи керівника (ІСК) [67] - містять у собі певні множини запитів і, будучи задовільними для повсякденної роботи, нездатні відповісти на всі питання до існуючих даних, виникаючих при прийнятті рішень. Результатом роботи такої системи, як правило, є багатосторінкові звіти. Таким чином, зовнішня простота статичних СППР, за яку активно бореться більшість замовників інформаційно-аналітичних систем, обертається втратою гнучкості.

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

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

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

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

1.4. Аналіз методів організації і пошуку інформації в обчислювальних системах

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

Можливим рішенням є впровадження декількох локальних ІС з незалежними БД. У цьому випадку реалізація запиту потребує рішення ряду задач :

визначення ЕОМ, у якій утримуються запитувані дані;

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

збір і об'єднання результатів роботи декількох користувачів;

виділення з об'єднаних результатів відповіді на вхідній запит.

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

Можливі різноманітні форми реалізації РБД. Одна з них - багатокористувацькі системи і локальні мережі з виділеним файловим сервером. Їх перевагою є висока швидкість та інтенсивність переданих даних [35, 50]. Проте централізоване збереження інформації подає серйозні вимоги до часу реакції системи на запит окремого користувача та читання або запис у базу даних, до потреби БД при збоях, часу їх відновлення. Крім того, у випадку територіально розосередженого об'єкта рознесення вузлів мережі потребує великих додаткових витрат на прокладання кабелю і придбання додаткових технічних засобів забезпечення віддаленого доступу. Сучасне математичне забезпечення локальних мереж висуває достатньо високі вимоги до обчислювальної техніки. У багатьох випадках це призведе до необхідності технічного переозброєння і великих капітальних вкладень. Висока вартість одного робочого місця локальної мережі зі значним рознесенням вузлів потребує серйозного економічного обґрунтування доцільності її впровадження.

У моделі мережі територіально розосередженої системи [50] виконуються такі умови :

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

повідомлення не упорядковані - усі повідомлення доставляються в порядку їх відправлення;

випадкові повідомлення неможливі - мережа передає тільки дійсні повідомлення, що посилаються вузлами, і не може спонтанно генерувати і відправляти власні;

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

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