Зважаючи на все перераховане, порівняння між різними MDD продуктами можна проводити тільки за узагальненими категоріями. У більш дешевому секторі ринку є лише однокористувацькі і призначені для невеликих локальних мереж засоби перегляду багатовимірних даних. Хоча вони мають досить високий рівень функціональних можливостей і зручні у використанні, ці системи обмежені за своїм масштабом. і їм бракує коштів, необхідні реалізації OLAPобработки у сенсі. До цієї категорії потрапляють такі продукти, як PowerPlay корпорації Cognos, PaBlo фірми Andyne та Mercury компанії Business Objects. Дорогий сектор ринку представлений системами Acumate ES фірми Kenan Technologies, Express корпорації Oracle, Gentium компанії Planning Sciences і Holos фірми

Holistic Systems. Вони настільки відрізняються за своїми можливостями, що будь-яку з них можна сміливо виділяти в окрему категорію. І нарешті, MDD-системи у чистому вигляді: Essbase корпорації Arbor Software, LightShip Server фірми Pilot Software та TM/1 компанії Sinper.

Другий клас OLAP-засобів – реляційні OLAP-системи (ROLAP). Тут для зберігання даних використовуються старі реляційні СУБД, а між БД та клієнтським інтерфейсом організується обумовлений адміністратором системи шар метаданих. Через цей проміжний шар клієнтський компонент може взаємодіяти з реляційною БД як багатовимірною. Подібно до засобів першого класу, ROLAP-системи добре пристосовані для роботи з великими інформаційними сховищами, вимагають значних витрат обслуговування спеціалістами інформаційних підрозділів та передбачають роботу в розрахованому на багато користувачів режимі. Серед продуктів цього типу - IQ/Vision корпорації IQ Software, DSS/Server та DSS/Agent фірми MicroStrategy та DecisionSuite компанії Information Advantage.

ROLAP-засоби реалізують функції підтримки прийняття рішень надбудові над реляційним процесором БД.

Такі програмні продукти повинні відповідати низці вимог,

зокрема:

- мати потужний оптимізований для OLAP генератор SQL виразів, що дозволяє застосовувати багатопрохідні SQL-оператори SELECT та/або кореловані підзапити;

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

генерувати SQL-вирази, оптимізовані для цільової реляційної СУБД, включаючи підтримку доступних у ній розширень цієї мови;

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

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

Третій порівняно новий тип OLAP-засобів - інструменти генерації запитів та звітів для настільних ПК, доповнені

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

компанія Brio Technology зі своєю системою Brio Query Enterprise, Business Objects з однойменним продуктом та Cognos з PowerPlay.

В даний час збільшується кількість Web-сумісних продуктів OLAP.

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

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

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

OLTP-системи, будучи високоефективним засобом реалізації оперативної обробки, виявилися мало придатними для завдань аналітичної обробки. Це викликано наступним:

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

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

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

Коло завдань, ефективно вирішуваних кожної із систем, визначимо з урахуванням порівняльних характеристик OLTP- і OLAP-систем (табл. 8).

Таблиця 8

Коло завдань розв'язуваних OLTP- та OLAP-системами

Характеристика
Частота оновлення	Висока частота,	Мала частота, великі "порції"
	невеликі "порції"
Джерела даних	В основному, внутрішні	Стосовно аналітичної
		системі, в основному,
Вік даних	Поточні (кілька	Історично (за роки) та
		прогнозовані
Рівень агрегації	Деталізовані дані	В основному
		агреговані дані
Можливості	Регламентовані	Послідовність
аналітичних		інтерактивних обліків,
операцій		динамічна зміна рівнів
		агрегацій та зрізів даних
Призначення	Фіксація, оперативний	Робота з історичними
	пошук та обробка даних,	даними, аналітична
	регламентована	обробка, прогнозування,
	аналітична обробка	моделювання

				Таблиця 9
	Порівняння OLTP та OLAP
характеристика
Переважаючі		Введення даних, пошук		Аналіз даних
операції
Характер запитів				Складні транзакції
		транзакцій
Збережені дані		Оперативні,		охоплюючі
		деталізовані
				агреговані
Вид діяльності		Оперативна,		Аналітична,
		тактична		стратегічна
Тип даних		Структуровані		Різнотипні

3.7. Підходи щодо вибору економічних інформаційних систем

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

1. Наскільки технології бізнесу у фірмі від традиційних.

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

неефективною - частина модулів системи буде незастосовна або непрацездатна в поставлених умовах.

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

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

3. Які суми готова вкласти компанія в автоматизацію.

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

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

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

Розробка ЕІС своїми засобами та замовлення розробки ЕІС сторонньої організації-розробника найбільш привабливі для рідкісного або нетипового ведення "ділового господарства". При цьому конкретний вибір варто робити на підставі інформації про фінансовий стан фірми, наявність надійної фірми розробника або інтегратора та можливість встановити з нею тривалі партнерські відносини та інші фактори.

Більш докладний аналіз переваг та недоліків методів автоматизації представлений у таблиці.

Таблиця 10

Переваги та недоліки методів автоматизації

Переваги підходу

Недоліки підходу

Орієнтація

російські

Проблема

інвестицій

адаптація

закони, "особливості" бізнесу,

початкові

готової ЕІС

бухгалтерського обліку

абсолютні

величини

російської

опинитися

невеликі,

подальші

виробництва

Доступність

розробників

навчання,

підтримки

обслуговування

розвиток

супроводу, що у варіанті

інформаційної

із зарубіжним продуктом або

бути дуже значними). У

має куди менші масштаби,

умовах

нестабільності

обходиться

економіки

недосконалості

дорожче (можливо в десятки та

законодавства,

сотні разів). Робочий день одного

гарантії

стабільності

кваліфікованого

виробника

програмного

спеціаліста

на будівництві

забезпечення (ПЗ) протягом

адаптації систем такого класу

всього терміну експлуатації ПЗ.

західна фірма цілком може

оцінити дуже дорого.

1.2.Купівля та

Найбільшим

початкові

адаптація

подібного

є

готової ЕІС

величезна

потужність

Дуже значні

витрати на

зарубіжного

потенціал західних продуктів

використання

продукту,

навчання

виробництва

та комплексів автоматизації.

персоналу та пов'язані з цим

Зазвичай вони складаються з ряду

зміни

комплектуються

торкнутися

апаратного

залежності

забезпечення фірми.

споживача (хоча існує і

У зв'язку з багатьма чисто

цілий ряд систем, які по

російськими факторами (велика

причин

динамічність

модульними

є;

обстановки,

системам

властива

людського

велика закритість та велика

інше) величина подібного ризику

труднощі

експлуатації

роду вкладень дуже висока.

впровадженні).

Основний

проблемою

є

необхідність

переорієнтації

технічних

аспектів діяльності фірми під

те, як це уявляли собі

розробники продукту, що в

наших умовах можливо дуже

рідко навіть якщо ці технології

визнані

загальноприйнятими.

Відсутність

деяких

продуктах

типових

російської

користувача

компонент,

недостатня

локалізація

утруднити

значно

ефективність його застосування.

Стратегії

та критерії вибору

західний

інформаційної

достатньо

непрості,

головними із вимог, які

можуть бути пред'явлені системі

подібного

є:

функціональна

відкритість,

модульність,

масштабованість, здатність до

роботі у розподіленому середовищі,

настроюваність

постачання у вихідних текстах),

цінова політика виробника

продукту та його представників у

2.Розробка

Цей підхід у більшості

Велике (причому часом важко

випадків застосуємо лише у двох

прогнозований) час розробки

власним

варіантах: для достатньо

і, у багатьох випадках, велика

великої фірми, здатної

величина витрат.

кваліфікованих

розробників ПЗ і в тому

випадку, якщо комплекс

автоматизації не дуже великий і

може бути розроблений

досить обмеженими

ресурсами.

Зазвичай цей варіант

автоматизації використовується в

тому випадку, коли жоден з

існуючих комерційних

продуктів не задовольняє

керівництво підприємства, або

якщо бізнес настільки

динамічний, що перенастроювання

готового продукту виявиться

дорожче або менше

ефективнішою, ніж свого.

Переваги:

орієнтований

конкретну фірму

комплекс

автоматизації,

покриваючий

необхідний

якість,

ефективність та оперативність

"підтримки" (ніхто не знає

всіх особливостей бізнесу

фірмі краще

її власних

співробітників).

3.Розробка

Цей варіант перегукується з

Однак тут виникають проблеми,

попереднім, але відрізняється від

подібні першим варіантом

спільно з

його наступним: фірмі не

автоматизації, але зазвичай цими

проблемами легше керувати через

розробник

програмістів з однієї

більш тісних контактів

сторони, і вона отримує

споживача інформаційної

орієнтований на неї

системи та фірми-розробника

продукт – з іншого.

(Інтегратора).

У разі наявності у фірми-

розробника технологічного

"конструктора" (ядра

інформаційної системи,

досить легко розвивається

та адаптованого під

мінливі умови) такий

варіант автоматизації може

виявитися дешевше та

ефективніше другого підходу та

динамічніше та технологічніше

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

Впровадження якісної ЕІС одна із найважливіших елементів ринкового успіху підприємства міста і умовою її динамічного розвитку.

3.8. Критерії вибору ЕІС

При виборі ЕІС необхідно враховувати такі критерії:

репутація фірми, репутація системи, стаж перебування фірми над ринком, число продажів.

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

термінологія та якість русифікації західної системи.

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

яка російська команда стоїть за західною системою.Хто її русифікував, хто впроваджує? Чи знають вони виробництво? Яка у них освіта? Який досвід? Яка за ними “історія успіхів”? Який їхній підхід до впровадження?

розумна ціна . Купуючи систему, необхідно пам'ятати, що на весь цикл – купівля, впровадження, супровід, розвиток – доведеться витратити у 3 – 10 разів більше грошей, ніж вартість програмних засобів. Чим складніша і дорожча система, тим більший коефіцієнт. Якщо доведеться залучати західних консультантів, це буде коштувати щонайменше в 1000 $ на день, причому заздалегідь неясно, чи вони навчатимуть працювати з їхньою системою, чи співробітники підприємства за ці гроші їх знайомитимуть із хвилюючими особливостями російської економіки.

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

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

гнучкість. Система впроваджуватиметься півтора-три роки і працюватиме п'ять - десять років. За цей час підприємство зміниться. Зміниться продукція, оргструктура, організація управління, бізнес – процеси, ролі та повноваження управлінців. Система управління має змінюватися разом із виробництвом. Отже система повинна дозволяти легко змінювати АРМи та меню, формувати звіти та довідки, робити довільні вибірки інформації у зручному поданні, змінювати бізнес – процеси та алгоритми шляхом параметричного налаштування тощо. Звичайна проблема із західними системами – не зрозуміло, для якого користувача екрани для введення інформації. Начебто для технолога, але до чого тут нормативи планування? Начебто для комірника, але до чого тут ціни і тривалість циклу? Начебто для бухгалтера, але для якого розділу обліку? У цьому випадку доведеться розбивати екрани, прибирати зайві реквізити, додавати потрібні, змінювати назви полів, змінювати їхнє розташування на екрані, змінювати значущість, додавати поля до бази даних, змінювати HELP. Чи дозволить це робити система і якою ціною? Система повинна також легко інтегруватися з іншими модулями, наприклад, з російськими програмами розрахунку зарплати або управління персоналом (не очевидно, що вдасться використати відповідні західні аналоги) або з існуючими старими розробками, які не можна відключити (через специфіку, унікальність тощо). п.). Системи європейського виробництва зазвичай гнучкіші, ніж американські, - вони спочатку орієнтовані на облік національних особливостей різних країн Європейського співтовариства,

архітектури. Бажана триланкова - сервер бази даних, сервер додатків, клієнт - клієнт-серверна архітектура з можливістю використання "тупих терміналів". Клієнт може бути "товстим" або "тонким",

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

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

Сильно нормалізовані моделі даних добре підходять для OLTP-додатків. On-Line Transaction Processing (OLTP) – додатків оперативної обробки транзакцій. Типовими прикладами OLTP-додатків є системи складського обліку, замовлень квитків, операційні банківські системи та інші. Основна функція таких систем полягає у виконанні великої кількості коротких транзакцій. Самі транзакції є досить простими, але проблеми полягають у тому, що таких транзакцій дуже багато, виконуються вони одночасно і при виникненні помилок транзакція повинна відкотитися і повернути систему до стану, в якому вона була до початку транзакції. Практично всі запити до бази даних в OLTP-додатках складаються з команд вставки, оновлення та видалення. Запити на вибірку, в основному, призначені для надання користувачам вибірки даних з різних довідників. Τᴀᴋᴎᴎᴀᴀᴈᴏᴍ, більшість запитів відома наперед ще на етапі проектування системи. Критичним для OLTP-додатків є швидкість та надійність виконання коротких операцій оновлення даних. Чим вищий рівень нормалізації даних в OLTP-додатках, тим воно швидше та надійніше. Відступи від цього правила можуть відбуватися тоді, коли вже на етапі розробки відомі деякі запити, що часто виникають, що вимагають поєднання відносин і від швидкості виконання яких істотно залежить робота додатків.

Іншим типом програм є OLAP-додатки – On-Line Analitical Processing (OLAP) – програми оперативної аналітичної обробки даних. Це узагальнений термін, що характеризує принципи побудови систем підтримки ухвалення рішень – Decision Support System (DSS), сховищ даних – Data Warehouse, систем інтелектуального аналізу даних – Data Mining. Такі системи призначені для знаходження залежностей між даними, щодо динамічного аналізу за принципом «що якщо…» тощо завдань. OLAP-додатки оперують з великими масивами даних, накопиченими на підприємстві або з інших джерел. Такі системи характеризуються такими ознаками:

Додавання до системи нових даних відбувається відносно рідко великими блоками, наприклад, раз на місяць чи квартал;

Дані, додані в систему, зазвичай, ніколи не видаляються;

перед завантаженням дані проходять різні підготовчі процедури, пов'язані з приведенням їх до певних форматів;

Запити до системи є нерегламентованими та досить складними;

швидкість виконання запитів важлива, але з критична.

Бази даних OLAP-додатків зазвичай представлені у вигляді одного або декількох гіперкубів, вимірювання якого є довідковими даними, а в осередках самого гіперкуба зберігаються значення цих даних. Фізично гіперкуб може бути побудований на основі спеціальної багатовимірної моделі даних Multidimensional OLAP (MOLAP) або представлений засобами реляційної моделі даних Relational OLAP (ROLAP).

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

- Шляхи забезпечення надійності системи водопостачання

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

- I. Концепція безпеки системи захисту

Концепція безпеки системи, що розробляється - «це набір законів, правил і норм поведінки, що визначають, як організація обробляє, захищає і поширює інформацію. Зокрема, правила визначають, у яких випадках користувач має право оперувати з... [читати докладніше]

- після прийняття основних рішень щодо конструкції системи опалення

ПРОЕКТУВАННЯ СИСТЕМИ ВОДЯНОГО ОПАЛЕННЯ БУДІВЛІ Накресліть схеми теплових вузлів при підключенні системи опалення за відкритою та закритою схемами. Запитання для самоперевірки При теплопостачанні кількох будівель. Насоси та інше обладнання встановлюють... [читати докладніше]

- Вимоги щодо забезпечення пожежної безпеки системи запобігання пожежі.

Основи забезпечення пожежної безпеки технологічних процесів Питання 2.Пожежна профілактика об'єкта (25хв.) Пожежна профілактика включає комплекс організаційних і технічних заходів, спрямованих на забезпечення безпеки людей,... [читати докладніше]

- Тканини та системи органів тварин

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

У геномах вищих еукаріот присутні численні послідовності ДНК, що повторюються. У людини, наприклад, такі повтори займають понад 40% всього геному. І цього випливає, що при освіті DSBs ймовірність одночасного утворення кількох розривів по... [читати докладніше]

- Визначення груп крові системи АВО цоліклонами анти-А, анти-В та анти-АВ

ВИЗНАЧЕННЯ ГРУП КРОВІ Відповідно до цього правила всім хворим можна переливати кров О(1) групи, оскільки вона не містить аглютиногенів, а реципієнтам АВ(1У) групи можна переливати кров інших груп, оскільки вона не містить аглютиногенів. Звідси введено...

Чи знаєте ви, у чому хибність поняття "фізичний вакуум"?

Фізичний вакуум - поняття релятивістської квантової фізики, під ним там розуміють нижчий (основний) енергетичний стан квантованого поля, що має нульовий імпульс, момент імпульсу та інші квантові числа. Фізичним вакуумом релятивістські теоретики називають повністю позбавлене речовини простір, заповнений невимірюваним, отже, лише уявним полем. Такий стан на думку релятивістів не є абсолютною порожнечею, але простір, заповнений деякими фантомними (віртуальними) частинками. Релятивістська квантова теорія поля стверджує, що, згідно з принципом невизначеності Гейзенберга, у фізичному вакуумі постійно народжуються і зникають віртуальні, тобто частки, що здаються (кому здаються?): відбуваються так звані нульові коливання полів. Віртуальні частки фізичного вакууму, а отже, він сам, за визначенням не мають системи відліку, тому що в іншому випадку порушувався б принцип відносності Ейнштейна, на якому ґрунтується теорія відносності (тобто стала б можливою абсолютна система вимірювання з відліком від частинок фізичного вакууму, що у свою чергу однозначно спростувало б принцип відносності, на якому побудована СТО). Таким чином, фізичний вакуум і його частинки не є елементами фізичного світу, але лише елементи теорії відносності, які існують не в реальному світі, але лише в релятивістських формулах, порушуючи при цьому принцип причинності (виникають і зникають так), принцип об'єктивності (віртуальні частки можна вважати залежно від бажання теоретика або існуючими, або не існуючими), принцип фактичної вимірності (не спостерігаються, не мають своєї ISO).

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

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

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

Система оперативної обробки даних (ON LINE TRANSACTION PROCESSING) OLTP розрахована на швидке обслуговування щодо простих запитів великої кількості користувачів. Ці системи вимагають захисту від несанкціонованого доступу, порушення цілісності даних, апаратних і програмованих збоїв.

Їх характеризує короткий час очікування виконання запитів.

Сфера застосування √ це сфера платежів, обліку, резервування місць, банки та біржові операції

Транзакція- це деяка закінчена з погляду користувача дію над БД.

Системи аналітичної обробки даних (ON LINE ANALIZIS PROCESSING) OLAP- це системи підтримки прийняття рішень, орієнтовані виконання більш складних запитів, потребують статистичної обробки історичних даних, накопичених за певний проміжок часу. Аналітичні системи включають:

1. засоби обробки інформації на основі методів штучного інтелекту

2. засоби графічного представлення даних.

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

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

Наведені класи систем (OLAP та OLTP), вони засновані на використанні СУБД, але типи запитів дуже відрізняються.

Обробка транзакцій в OLTP системах

Транзакція -неподільна з позиції на БД послідовність операцій маніпулювання даними. Це може бути операція зчитування, видалення, вставки і т.д.

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

Транзакція повинна мати 4 основні властивості:

1. атомарність,транзакція повинна виконуватися як єдина операція доступу до БД, вона має бути виконана повністю або виконана взагалі.

2. узгодженістьгарантує взаємну цілісність даних.

3. ізольованість, транзакції будуть виконуватися ізольовано в системі користувача.

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

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

Фіксація - це дія, що забезпечує запис у БД усіх змін.

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

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

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

При відкаті СУБД за журналом транзакцій відновлює рядки, які були модифіковані.

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

1. SQL оператором commit work

SQL оператором rollback

2. простим завершенням оператора, який викликав транзакцію.

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

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

Проблеми:

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

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

Для усунення цього використовують серіалізацію (спільне відпрацювання):

1. транзакція не може отримати доступу до незафіксованих даних

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

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

Взаємоблокування транзакцій

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

СУБД періодично перевіряє блокування і якщо є взаємоблокування, то одна із транзакцій насильно переривається.

Засоби відновлення після збоїв

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

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

 OLTP та OLAP системи У попередньому підрозділі зазначалося, що для адекватного подання предметної галузі, простоти розробки та підтримки бази даних відносини мають бути приведені до третьої нормальної форми (існують форми нормалізації та більш високих порядків, але на практиці вони використовуються досить рідко), то є сильно нормалізованими. Однак слабко нормалізовані відносини також мають свої переваги, основним з яких є те, що якщо до бази даних звертатися в основному тільки з запитами, а модифікації та додавання даних проводити дуже рідко, їх вибірка проводиться значно швидше. Це тим, що у слабо нормалізованих відносинах вже хіба що вироблено їх з'єднання і цього не витрачається процесорний час. Виділяють два класи систем, котрим більшою мірою підходять сильно і слабко нормалізовані відносини. Сильно нормалізовані моделі даних добре підходять для OLTP-додатків – On-Line Transaction Processing (OLTP) – додатків оперативної обробки транзакцій. Типовими прикладами OLTP-додатків є системи складського обліку, замовлень квитків, операційні банківські системи та інші. Основна функція таких систем полягає у виконанні великої кількості коротких транзакцій. Самі транзакції є досить простими, але проблеми полягають у тому, що таких транзакцій дуже багато, виконуються вони одночасно і при виникненні помилок транзакція повинна відкотитися і повернути систему до стану, в якому вона була до початку транзакції. Практично всі запити до баз даних в OLTP-додатках складаються з команд вставки, оновлення та видалення. Запити на вибірку, в основному, призначені для надання користувачам вибірки даних з різних довідників. Таким чином, більшість запитів відома заздалегідь ще на етапі проектування системи. Критичним для OLTP-додатків є швидкість та надійність виконання коротких операцій оновлення даних. Чим вищий рівень нормалізації даних в OLTP-додатках, тим воно швидше та надійніше. Відступи від цього правила можуть відбуватися тоді, коли вже на етапі розробки відомі деякі запити, що часто виникають, що вимагають з'єднання відносин і від швидкості виконання яких істотно залежить робота додатків. Іншим типом програм є OLAP-додатки - On-Line Analitical Processing (OLAP) - програми оперативної аналітичної обробки даних. Це узагальнений термін, що характеризує принципи побудови систем підтримки прийняття рішень – Decision Support System (DSS), сховищ даних – Data Warehouse, систем інтелектуального аналізу даних – Data Mining. Такі системи призначені для знаходження залежностей між даними, для проведення динамічного аналізу за принципом "що якщо..." тощо. OLAP-додатки оперують з великими масивами даних, накопиченими на підприємстві або з інших джерел. Такі системи характеризуються такими ознаками: * Додавання до системи нових даних відбувається відносно рідко великими блоками, наприклад, один раз на місяць або квартал; * Дані, додані в систему, як правило, ніколи не видаляються; * перед завантаженням дані проходять різні підготовчі процедури, пов'язані з приведенням їх до певних форматів тощо; * запити до системи є нерегламентованими та досить складними; * Швидкість виконання запитів важлива, але не критична. Бази даних OLAP-додатків зазвичай представлені у вигляді одного або декількох гіперкубів, вимірювання якого є довідковими даними, а в осередках самого гіперкуба зберігаються значення цих даних. Фізично гіперкуб може бути побудований на основі спеціальної багатовимірної моделі даних – Multidimensional OLAP (MOLAP) або представлений засобами реляційної моделі даних – Relational OLAP (ROLAP). У системах OLAP, що використовують реляційну модель даних, дані доцільно зберігати у вигляді слабо нормалізованих відносин, що містять заздалегідь обчислені основні підсумкові дані. Надмірність даних та пов'язані з нею проблеми тут не страшні, тому що їх оновлення відбувається досить рідко і разом із оновленням даних здійснюється перерахунок підсумків. Характеристики та коло завдань, що ефективно вирішуються кожною технологією, пояснюється наступною порівняльною таблицею: ХарактеристикаOLTPOLAPПризначення системиРеєстрація, оперативний пошук та обробка транзакцій, регламентований аналізРобота з історичними даними, аналітична обробка, прогнозування, моделюванняЗберігані даніОперативні Поточні (кілька місяців)Історичні (за роки) і прогнозованіЧастота оновлення данихВисока, невеликими "порціями"Мала, великими "порціями"Рівень агрегації данихДеталізовані даніВ основному - агреговані даніПереважні операціїВведення даних, пошук, оновленняАналіз данихСпосіб використаннязапропонованийЗапропонованийНепередбачуванийНе даних Вид діяльностіОперативна, тактичнаАналітична, стратегічнаПріоритетиВисока продуктивність Висока доступністьГнучкість Автономність користувачаКатегорія користувачівВелика кількість працівників виконавчої ланкиВідносно мала кількість працівників керівної ланки Порівняння OLTP і OLAP Характеристика OLTP ні, деталізованіОхоплюючі великий період часу, агрегованіВигляд діяльностіОперативна, тактичнаАналітична, страте -ГичнаТип данихСтруктурованіРізнотипніСистемна характеристикаОблікова система (OLTP)OLAPВзаємодія з користувачем На рівні транзакції На рівні всієї бази даних Дані, що використовуються при зверненні користувача до системиОсобливі записиГрупи записівЧас відгукуСекундиВід декількох секунд до декількох хвилинВикористання апарату й рівень деталізації) В основному похідні (зведені значення)Характер доступу до бази данихПредвизначені або статичні шляхи доступу та відносини даних Невизначені або динамічні шляхи доступу та відносини даних Мінливість данихВисока (дані оновлюються з кожною транзакцією)Низька (під час запиту дані оновлюються рідко)Пріоритети Висока продуктивність Висока доступність