У цій статті йтиметься про архітектуру сховищ даних. Чим керуватися за її побудові, які підходи працюють – і чому.

"Казка брехня - та в ній натяк ..."

Посадив дід… сховище. І виросло сховище велике-превелике. Ось тільки до пуття не знав, як воно влаштоване. І затіяв дід ревом. Покликав дід бабусю, онучку, кота та мишку на сімейну раду. І говорить таку тему: «Виросло у нас сховище. Дані з усіх систем стікаються, таблиць мабуть-невидимо. Користувачі звіти свої готують. Начебто все добре – жити та жити. Та тільки один сум – ніхто не знає, як воно влаштоване. Дисків вимагає мабуть-невидимо - не напасешся! А тут ще користувачі до мене ходити повадилися з різними скаргами: то звіт зависає, то дані застарілі. А то й зовсім біда – приходимо ми зі звітами до царя-батюшки, а цифри між собою не сходяться. Не рівна година – розгнівається цар – не зносити тоді голови – ні мені, ні вам. Ось вирішив я вас зібрати і порадитися: що робитимемо?».

Окинув він своїм поглядом збори і питає:
- Ось ти, бабко знаєш, як воно влаштоване наше сховище?
- Ні, діду, не знаю. Та й звідки мені знати? Он там які браві хлопці його охороняють! Одні всищі які! Не підступишся. Я зайшла якось їх провідати, пиріжків напекла. А вони пиріжки з'їли, вуса витерли і кажуть: «Та чого ти прийшла, бабко? Яке тобі сховище? Ти скажи – який тобі звіт потрібен – ми тобі зробимо! Ти головне пиріжки частіше приноси! Аж надто вони в тебе смачні.»
- А ти, онучко кохана, чи знаєш, як влаштовано наше сховище?
- Ні, діду, не знаю. Дали мені якось доступ до нього. Підключилася я, дивлюся - а там таблиць - мабуть-невидимо. І у схеми різні сховані. Очі розбігаються…. Я спершу розгубилася. А потім придивилася - якісь із них порожні, інші заповнені, та лише наполовину. А ще дані, схоже, повторюються. Не дивно, що дисків не напасешся, з такою надмірністю!
- Ну а ти, кіт, що скажеш про сховище наше? Чи є в ньому щось хороше?
- Та як не сказати, дідусь - скажу. Я на внучкине прохання намагався в окремій схемі пілотик змастити – вітринку маленьку. Щоб зрозуміти, яка торгівля для нашої держави вигідна – які продукти добре купці йдуть, ті данину платять – скарбницю поповнюють. А які – геть погано. І став я зі сховища цього дані собі підбирати. Фактів назбирав. І став намагатися порівняти їх проти товарів. І що ж, діду, я побачив – продукти вони начебто й однакові, а дивишся в таблички – різні! Взявся я їх тоді гребінцем внучкиним зачісувати. Чесав-чухав - і привів до деякого одноманітності, очей ласкавого. Але рано я зрадів - другого дня запустив я свої скриптики чудові дані у вітринці оновити - а в мене все і роз'їхалося! "Як так?" - думаю, - внучка-то, напевно, засмутиться - сьогодні треба було б наш пілотік міністру показувати. Як же ми підемо з такими даними?
- Так, сумні казки, кіт, розповідаєш. Ну а ти, мишка-норушка, невже не намагалася дізнатися про сховище? Ти в нас дівчина жвава, в'язка, товариська! Що ти нам розповіси?
- Та як, дідусю, не намагатися - звичайно, я мишка тиха, та спритна. Попросила якось онука кота модель даних нашого державного сховища роздобути. А кіт, звичайно, до мене прийшов – на тебе, каже, мишка, вся надія! Ну що добра справа добрим людям (і котам) не зробити? Пішла я до замку, де начальник сховища модель даних у сейфі ховає. І причаїлася. Дочекалася, коли він ту модель із сейфа витягне. Тільки він за кавою вийшов – я стрибнув на стіл. Дивлюся на модель нічого зрозуміти не можу! Як так? Не впізнаю наше сховище! У нас таблиць тисячі незліченні, даних – невгамовні потоки! А тут - все струнко та красиво ... Подивився він на цю модель - і назад у сейф прибрав.
- Так, зовсім дивні речі, ти нам, мишка, повідала.
Дуже задумався дід.
- Що робитимемо, друже мої? Адже з таким сховищем довго не проживеш… Користувачі геть скоро – зовсім терпіння втратять.

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

Розбір польотів

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

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

У принципі, у нас непогане сховище: якщо не чіпати – все працює. Щоправда, щойно потрібно внести зміну – починаються «локальні обвали».
Дані завантажуються щодня, за регламентом, у межах одного великого процесу, протягом 8ч. І це нас влаштовує. Але якщо раптом виникає збій – це потребує ручного втручання. І далі може працювати непередбачено довго, т.к. будуть потрібні участь людини в процесі.
Накотили реліз – чекай на проблеми.
Якесь одне джерело не змогло вчасно віддати дані – чекають на всі процеси.
Цілісність даних контролює база даних – тому наші процеси падають помилково, коли вона порушується.
У нас дуже велике сховище – 2000 таблиць в одній загальної схеми. І ще 3000 у багатьох інших схем. Ми вже слабо уявляємо, як вони влаштовані та з якого приводу з'явилися. Тому нам буває складно щось перевикористати. І доводиться багато завдань вирішувати наново. Оскільки так простіше і швидше (ніж розбиратися «в чужому коді»). У результаті маємо розбіжності і функціонал, що дублюється.
Ми очікуємо, що джерело даватиме якісні дані. Але виявляється, що це негаразд. У результаті багато часу витрачаємо на вивірку своїх фінальних звітів. І дуже в цьому досягли успіху. У нас навіть є налагоджений процес. Щоправда, це триває час. Але користувачі звикли.
Користувач не завжди довіряє нашим звітам та вимагає обґрунтування тієї чи іншої цифри. У якихось випадках він правий, а в якихось ні. Але дуже складно їх доводити, т.к. у нас не передбачено засобів "наскрізного аналізу" (або data lineage).
Ми могли б залучити додаткових розробників. Але у нас проблема – як нам включити їх у роботу? Як найефективніше розпаралелити роботи?
Як розвивати систему поступово, не вдаючись у розробку «ядра системи» на цілий рік?
Сховище даних асоціюється із корпоративною моделлю. Але ми точно знаємо (бачили у банку XYZ), що будувати модель можна нескінченно довго (у банку XYZ шість місяців ходили та обговорювали бізнес-сутності, без будь-якого руху). А навіщо вона взагалі? Чи, може, краще без неї, якщо з нею стільки проблем? Може її взагалі якось згенерувати?
Ми вирішили вести модель. Але як системно розвивати модель даних сховища? Чи потрібні нам правила гри і які вони можуть бути? Що це нам дасть? А якщо ми помилимося з моделлю?
Чи маємо ми зберігати дані, чи історію їхніх змін, якщо «бізнесу вони не потрібні»? Не хотілося б «зберігати сміття» та ускладнювати використання цих даних для реальних завдань. Чи сховище збереже історію? Яка вона буває? Як сховище працює з часом?
Чи потрібно намагатися уніфікувати дані на сховищі, якщо ми маємо систему управління НСІ? Якщо є МДМ, чи це означає, що тепер вся проблема з майстер-даними вирішена?
У нас незабаром очікується заміна ключових облікових систем. Чи сховище даних повинно бути готовим до зміни джерела? Як цього досягти?
Чи потрібні нам метадані? Що під цим розумітимемо? Де вони можуть бути використані? Як можна продати? Чи потрібно їх зберігати «в одному місці»?
Наші Замовники украй не стабільні у своїх вимогах та бажаннях – постійно щось змінюється. У нас взагалі бізнес дуже динамічний. Поки що ми щось робимо – це вже стає непотрібним. Як нам зробити так, щоб видавати результат максимально швидко – як гарячі пиріжки?
Користувачі потребують оперативності. Але ми можемо наші основні процеси завантаження запускати часто, т.к. це навантажує системи-джерела (погано позначається на продуктивності) – тому ми вішаємо додаткові потоки даних – які будуть забирати точково – те, що нам потрібно. Щоправда, виходить багато потоків. І частину даних ми потім викинемо. До того ж, буде проблема збіжності. Але інакше ніяк…

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

Антикрихкість

Дивлячись на наш список, можна зробити один висновок. Не складно створити якусь «базу даних для звітності», накидати туди даних чи навіть побудувати певні регламентні процеси оновлення даних. Система починає якось жити, з'являються користувачі, а з ними зобов'язання та SLA, виникають нові вимоги, підключаються додаткові джерела, зміна методологій – все це треба враховувати в процесі розвитку.

Через деякий час картина наступна:
«Ось сховище. І воно працює, якщо його не чіпати. Проблеми виникають тоді, коли ми маємо щось змінювати».

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

Така властивість об'єкту – руйнуватися під впливом хаосу, випадкових подій та потрясінь - Нассим Ніколас Талеб називає крихкістю . А також вводить протилежне поняття: антикрихкість – коли предмет не руйнується від стресу та випадковостей, а отримує від нього пряму вигоду. («Антихрупність. Як отримати вигоду з хаосу»)
Інакше це можна назвати адаптивність або стійкість до змін .

Що це означає у цьому контексті? Які є джерела хаосу для ІТ-систем? І що означає «здобути вигоду з хаосу» з погляду ІТ архітектури?
Перша думка, яка спадає на думку – зміни, які приходять ззовні. Що є зовнішнім світом системи? Для сховища зокрема. Звичайно, насамперед – зміни з боку джерел даних для сховища:

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

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

Не менш критичні зміни ініціюються з боку споживачів сховища (зміна вимог):

раніше для побудови звіту даних вистачало – тепер потрібно підключити додаткові поля чи нове джерело даних;
раніше реалізовані методики обробки даних застаріли – потрібно переробити алгоритми та все, на що це впливає;
раніше всіх влаштовувало поточне значення атрибуту довідника на інформаційній панелі – тепер потрібне значення, актуальне на момент виникнення аналізованого факту/події;
виникла вимога до глибини історії зберігання даних, якої раніше не було – зберігати дані не за 2 роки, а за 10 років;
раніше було достатньо даних за станом «на кінець дня/періоду» - тепер потрібний стан даних «всередині дня», або на момент певної події (наприклад, ухвалення рішення щодо кредитної заявки – для Basel II);
раніше нас влаштовувала звітність за даними на вчора (T-1) або пізніше, зараз нам потрібен T0;
і т.д.

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

Але це ще не все.
Говорячи про мінливість, ми передусім згадуємо зовнішні чинники. Адже всередині ми можемо все контролювати, нам так здається, чи не так? І так і ні. Так, більшість факторів, які поза зоною впливу – зовнішні. Але є й “внутрішня ентропія”. І саме через її наявність нам іноді потрібно повернутися "у точку 0". Почати гру спочатку.
У житті ми часто схильні розпочинати з нуля. Чому нам це властиво? І чи так це погано?
Що стосується ІТ. Для самої системи – це може бути дуже добре – можливість переглянути окремі рішення. Особливо коли ми можемо зробити це локально. Рефакторинг - процес розплутування тієї павутини, яка періодично виникає в процесі розвитку системи. Повернення «до початку» може бути корисним. Але має ціну.
При грамотному управлінні архітектурою ця ціна знижується - і процес розвитку системи стає більш контрольованим і прозорим. Простий приклад: якщо дотримується принципу модульності – можна переписати окремий модуль, не торкнувшись зовнішні інтерфейси. І цього не можна зробити за монолітної конструкції.

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

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

Приклад системи з «казки про сховище» - це якраз вельми хитка система, побудована на крихких підходах до проектування. І якщо так відбувається – руйнація настає досить швидко, саме для цього система класу.
Чому я можу так стверджувати? Тема сховищ не нова. Підходи та інженерні практики, які були за цей час вироблені, були спрямовані саме на це збереження життєздатності системи.
Найпростіший приклад: одна з найчастіших причин провалу проектів сховищ «на зльоті» - це спроба побудувати сховище над системами-джерелами, які перебувають у стадії розробки, без узгодження інтеграційних інтерфейсів – спроба забрати дані безпосередньо з таблиць. Через війну пішли у розробку – цей час база даних джерела змінилася – і потоки завантаження у сховище стали непрацездатні. Переробляти щось пізно. А якщо ще й не підстрахувалися, зробивши кілька шарів таблиць усередині сховища – все можна викинути і починати заново. Це лише один із прикладів, причому один із простих.

Критерій тендітного та антитендітного по Талебу простий. Головний суддя – час. Якщо система витримує перевірку часом, і показує свою «живучість» і «невбивність» - вона має властивість антикрихкості.
Якщо при проектуванні системи ми враховуватимемо антикрихкість як вимогу – це спонукає нас використовувати такі підходи до побудови її архітектури, які зроблять систему більш адаптивною і до «хаосу ззовні», і до «хаосу зсередини». І, зрештою, система матиме більш тривалий термін життя.
Нікому з нас не хочеться робити «часи». І не треба обманювати себе, що по-іншому нині не можна. Дивитись на кілька кроків уперед – це нормально для людини у будь-який час, тим більше у кризовий.

Що таке сховище даних та навіщо ми його будуємо

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

Як взагалі люди дійшли того, що необхідні сховища даних? І чим вони відрізняються від просто «дуже великої бази даних»?
Давним-давно, коли у світі жили просто «системи обробки бізнес-даних», був поділу ІТ-систем такі класи як фронтальні oltp-системи, бэк-офисные dss, системи обробки текстових даних, сховища даних, і т.д.
Це був той час, коли Майклом Стоунбрейкером було створено першу реляційну СУБД Ingres.
І це був час, коли ера персональних комп'ютерів вихором увірвалася в комп'ютерну індустрію і назавжди перевернула усі уявлення ІТ співтовариства того часу.

Тоді можна було легко зустріти корпоративні програми, написані на базі СУБД класу desktop – таких як Clipper, dBase та FoxPro. А ринок клієнт-серверних додатків та СУБД лише набирав обертів. Одна за іншою з'являлися сервери баз даних, які надовго займуть свою нішу в ІТ-просторі - Oracle, DB2 і т.д.
І було поширено термін «додаток баз даних». Що включало в себе таку програму? Спрощено - деякі форми введення, якими користувачі могли одночасно вводити інформацію, деякі розрахунки, які запускалися «по кнопці» чи «за розкладом», і навіть якісь звіти, які можна було побачити на екрані чи зберегти як файлів і надіслати на печатка.
"Нічого особливого - звичайний додаток, тільки є база даних, - так зауважив один з моїх наставників на ранньому етапі трудового шляху. Чи так нічого особливого? - Подумала тоді я.

Якщо придивитися - то особливості все-таки є. У міру зростання користувачів, обсягу інформації, що надходить, у міру зростання навантаження на систему – її розробники-проектувальники, щоб зберегти швидкодію на прийнятному рівні йдуть на якісь «хитрощі». Найперше – це поділ монолітної «системи обробки бізнес-даних» на додаток обліку, який підтримує роботу користувачів у режимі on-line, та окремо виділяють додаток для batch-обробки даних та звітності. Кожна з цих програм має свою базу даних і навіть розміщується на окремому екземплярі сервера БД, з різними налаштуваннями під різний характер навантаження – OLTP та DSS. І між ними вишиковуються потоки даних.

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

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

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

Ключові особливості сховищ даних

Давайте подивимося докладніше. Які ключові особливостіє у цих систем? Що відрізняє сховища даних від інших ІТ-систем підприємства?

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

По-друге, це історичні дані – "Corporate memory" - Так називають сховища даних. Щодо роботи з часом у сховищах все дуже цікаво. В облікових системах дані є актуальними в моменті. Потім користувач робить якусь операцію – і дані оновлюються. При цьому історія змін може і не зберегтися – це залежить від практики обліку. Візьмемо, наприклад, залишок на банківському рахунку. Нас може цікавити актуальний залишок на «зараз», на кінець дня або на момент події (наприклад, в момент розрахунку скорингового балу). Якщо перші два вирішуються досить просто, то для останнього, швидше за все, будуть потрібні спеціальні зусилля. Користувач, працюючи зі сховищем, може звертатися до минулих періодів, здійснювати їх порівняння з поточним тощо. Саме подібні можливості, пов'язані з часом, істотно відрізняють сховища даних від систем обліку – отримання стану даних у різних точках осі часу – на певну глибину у минулому.

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

По-четверте, це робота з якістю даних . У процесі завантаження даних у сховищі виконуються їх очищення, загальні перетворення та трансформації. Загальні перетворення необхідно робити в одному місці – і далі використовуватиме побудови різних звітів. Це дозволить уникнути розбіжностей, які викликають стільки роздратування у бізнес-користувачів – особливо керівництво, якому приносять «на стіл» цифри з різних відділів, які не сходяться між собою. Низька якість даних породжує помилки та розбіжності у звітах, наслідок яких – це зниження рівня довіри користувача до всієї системи, до всього аналітичного сервісу загалом.

Архітектурна концепція

Кожен, хто стикався зі сховищем, швидше за все спостерігав якусь «шарувату структуру» - т.к. саме ця архітектурна парадигма прижилася для систем класу. І невипадково. Шари сховища можна як окремі компоненти системи – зі своїми завданнями, зоною відповідальності, «правилами гри».
Рівнева архітектура – це засіб боротьби зі складністю системи – кожен наступний рівень абстрагований від складнощів внутрішньої реалізації попереднього. Такий підхід дозволяє виділяти однотипні завдання та вирішувати їх одноманітним чином, не винаходячи щоразу «велосипед» з нуля.
Схематично концептуальна архітектурна схема представлена малюнку. Це спрощена схема, яка відображає лише ключову ідею – концепцію, але без «анатомічних подробиць», які виникатимуть за більш глибокого опрацювання деталей.

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

Primary Data Layer – шар первинних даних (або стейджинг , або операційний шар ) – призначений для завантаження із систем-джерел та збереження первинної інформації, без трансформацій – у вихідній якостіта підтримкою повної історії змін.
Завдання цього шару- абстрагувати наступні шари сховища від фізичного пристрою джерел даних, способів забору даних та методів виділення дельти змін.

Core Data Layer – ядро сховища - центральний компонент системи, який відрізняє сховище від просто "платформи batch-інтеграції", або "великого звалища даних", оскільки його основна роль - це консолідація данихз різних джерел, приведення до єдиних структур, ключів. Саме при завантаженні в ядро здійснюється основна робота з якістю даних та загальні трансформації, які можуть бути складними.
Завдання цього шару– абстрагувати своїх споживачів від особливостей логічного устрою джерел даних та необхідності зіставляти дані з різних систем, забезпечити цілісність та якість даних.

Data Mart Layer - аналітичні вітрини – компонент, основна функція якого – перетворення даних до структур, зручним для аналізу (якщо з вітринами працює BI – це, зазвичай, dimensional model), чи відповідно до вимог системи-споживача.
Зазвичай, вітрини беруть дані з ядра – як надійного і вивіреного джерела – тобто. користуються сервісом цього компонента щодо приведення даних до єдиного виду. Будемо називати такі вітрини регулярними . В окремих випадках вітрини можуть брати дані безпосередньо зі стейджингу - оперуючи первинними даними (у ключах джерела). Такий підхід зазвичай використовується для локальних завдань, де не потрібна консолідація даних з різних систем і де потрібна оперативність більш ніж якість даних. Такі вітрини називають операційними . Деякі аналітичні показники можуть мати складні методики розрахунків. Тому для таких нетривіальних розрахунків та трансформацій створюють так звані вторинні вітрини .
Завдання шару вітрин– підготовка даних відповідно до вимог конкретного споживача – BI-платформи, групи користувачів або зовнішньої системи.

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

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

Таке чітке розподілення системи на окремі компоненти істотно підвищує керованість розвитку системи:

знижується складність завдання, що ставиться розробнику функціоналу того чи іншого компонента (він не повинен одночасно вирішувати і питання інтеграції із зовнішніми системами, і продумувати процедури очищення даних, і думати про оптимальне подання даних для споживачів) – завдання простіше декомпозувати, оцінити та виконати невеликий delivery;
можна підключати на роботу різних виконавців (і навіть команд, чи підрядників) – т.к. такий підхід дозволяє ефективно розпаралелювати завдання, знижуючи їх взаємний вплив один на одного;
наявність персистентного стейджинга дозволяє швидко підключити джерела даних, не проектуючи повністю ядро, чи вітрини для всієї предметної області, а далі поступово добудовувати інші верстви відповідно до пріоритетів (причому дані будуть у сховище – доступні системним аналітикам, що значно полегшить завдання подальшого розвитку сховища);
наявність ядра дозволяє всю роботу з якістю даних (а також, можливі промахи та помилки) приховати від вітрин і від кінцевого користувача, а головне – використовуючи цей компонент як єдине джерело даних для вітрин, можна уникнути проблем зі збіжністю даних внаслідок реалізації загальних алгоритмів одному місці;
виділення вітрин дозволяє врахувати відмінності та специфіку розуміння даних, які можуть бути у користувачів різних підрозділів, а їхнє проектування під вимоги BI дозволяє не тільки видавати агреговані цифри, а забезпечити перевірку достовірності даних шляхом надання можливостей drill down до первинних показників;
наявність сервісного шару дозволяє виконувати наскрізний аналіз даних (data lineage), використовувати уніфіковані засоби аудиту даних, загальні підходи до виділення дельти змін, роботи з якістю даних, управління завантаженням, засоби моніторингу та діагностики помилок, прискорює вирішення проблем.

Такий підхід до декомпозиції також робить систему більш стійкою до змін (у порівнянні з «монолітною конструкцією») - забезпечує її антикрихкість:

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

Далі ми пройдемося по кожному з наведених вище компонентів і подивимося на них трохи докладніше.

Ядро системи

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

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

Модель ядра сховища та корпоративна модель даних

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

Міф 1 Корпоративна модель даних – це величезна модель, що з тисяч сутностей (таблиць).
Насправді. У будь-якій предметній області, у будь-якому бізнес-домені, у даних будь-якої компанії, навіть найскладнішої, основних сутностей небагато – 20-30.

Міф 2 Не потрібно розробляти жодну «свою модель» - купуємо галузеву референсну модель – і робимо все за нею. Витрачаємо гроші – зате отримуємо гарантований результат.
Насправді. Референсні моделі можуть бути дуже корисні, т.к. містять галузевий досвід моделювання цієї галузі. З них можна знайти ідеї, підходи, практики іменування. Перевірити «глибину охоплення» області, щоб не упустити з уваги щось важливе. Але ми навряд чи зможемо використовувати таку модель з коробки - як є. Це такий самий міф, як наприклад – покупка ERP-системи (або CRM) та її впровадження без будь-якого «докручування під себе». Цінність таких моделей народжується в їхній адаптації до реалій саме цього бізнесу, саме цієї компанії.

Міф 3 Розробка моделі ядра сховища може зайняти багато місяців, і на цей час проект буде фактично заморожений. Крім того, це вимагає шалена кількість зустрічей та участі безлічі людей.
Насправді. Модель сховища може розроблятися разом із сховищем ітеративно, частинами. Для неохоплених областей ставляться «точки розширення» чи «заглушки» - тобто. застосовуються деякі "універсальні конструкції". При цьому потрібно знати міру, щоб не вийшло суперуніверсальна штука з 4х таблиць, в яку складно як «покласти дані», так і (ще складніше) дістати. І яка украй не оптимально працює з погляду продуктивності.

Час на розробку моделі справді буде потрібно. Але це час, витрачене на «малювання сутностей» - це час, необхідне аналізу предметної області, вникнення у те, як влаштовані дані. Саме тому в цьому процесі дуже беруть участь аналітики, а також залучаються різні бізнес-експерти. І робиться це точково, вибірково. А не шляхом організації зустрічей за участю шаленої кількості людей, розсилок величезних анкет тощо.
Якісний бізнес та системний аналіз - ось, що є ключовим при побудові моделі ядра сховища. Потрібно багато чого зрозуміти: де (у яких системах) породжуються дані, як вони влаштовані, у яких бізнес-процесах вони циркулюють тощо. Якісний аналіз ще жодній системі не шкодив. Швидше, навпаки – проблеми виникають із «білих плям» у нашому розумінні.

Розробка моделі даних – це процес винаходу і придумування чогось нового. Фактично модель даних у компанії вже існує. І процес її проектування швидше схожий на розкопки. Модель акуратно і ретельно витягується на світ із «ґрунту» корпоративних даних і вбирається в структуровану форму.

Міф 4 У нас в компанії бізнес настільки динамічний, і все так швидко змінюється, що даремно нам робити модель - вона застаріє раніше, ніж ми введемо цю частину системи в експлуатацію.
Насправді. Згадаймо, що ключовий фактор ядра – стабільність. І насамперед, топології моделі. Чому? Тому що саме цей компонент є центральним і впливає на решту. Стабільність – це вимога і до моделі ядра. Якщо модель дуже швидко застаріває – значить вона неправильно спроектована. Для її розробки обрані не ті підходи та «правила гри». І це питання якісного аналізу. Ключові сутності корпоративної моделі змінюються дуже рідко.
Але якщо нам спаде на думку зробити для компанії, які торгують скажімо, кондитерськими виробами, замість довідника «Продукти» зробити «Цукерки», «Торти» та «Пироги». То коли з'явиться піца в переліку товарів - так, потрібно буде вводити безліч нових таблиць. І це якраз питання підходу.

Міф 5 Створення корпоративної моделі – це дуже серйозна, складна та відповідальна справа. І страшно зробити помилку.
Насправді. Модель ядра хоч і має бути стабільною, але все ж таки не «відлита в металі». Як і будь-які інші проектні рішення, її структуру можна переглядати та видозмінювати. Просто не потрібно забувати про цю її якість. Але це зовсім не означає, що на неї "не можна дихати". І це не означає, що неприпустимі тимчасові рішення та «заглушки», які мають бути заплановані до переробки.

Міф 6 Якщо у нас джерело даних – це, наприклад, система НСІ (або система управління майстер-даними – МДМ), то вона вже по-хорошому має відповідати корпоративній моделі (особливо, якщо вона нещодавно спроектована, і не встигла обрости «побочкою», «традиціями»). » та часниками). Виходить, що для цього випадку нам модель ядра не потрібна?
Насправді. Так, у цьому випадку побудова моделі ядра сховища сильно полегшується - т.к. ми слідуємо готової концептуальної моделі верхнього рівня. Але не виключається зовсім. Чому? Тому що при побудові моделі певної системи діють деякі свої правила - які типи таблиць використовувати (для кожної сутності), як версіонувати дані, з якою гранулярністю вести історію, які метаатрибути (технічні поля використовувати) і т.п.

Крім того, яка б чудова та всеохоплююча система НСІ та МДМ у нас не була – як правило, виникнуть нюанси, пов'язані з існуванням локальних довідників «про те саме» в інших облікових системах. І цю проблему, чи хочемо ми цього, чи ні – доведеться вирішувати на сховищі – адже звітність та аналітику збирати тут.

Шар первинних даних (або історизований staging або операційний шар)

Він позначений як Primary Data Layer. Роль цього компонента: інтеграція із системами-джерелами, завантаження та зберігання первинних даних, а також попереднє очищення даних - перевірка на відповідність правилам форматно-логічного контролю, зафіксованих у «угоді про інтерфейс взаємодії» з джерелом.
Крім того, даний компонент вирішує дуже важливе для сховища завдання - виділення "справжньої дельти змін" - незалежно від того, чи дозволяє джерело відстежувати зміни в даних чи ні і яким чином (за яким критерієм їх можна "зловити"). Як тільки дані потрапили в стейджинг – для решти верств питання виділення дельти вже зрозуміле – завдяки маркуванню мета-атрибутами.

Дані в цьому шарі зберігаються в структурах, максимально близьких до системи-джерела – щоб зберегти первинні дані якомога ближче до їхнього первозданного вигляду. Ще одна назва цього компонента – «операційний шар».
Чому б просто не використовувати усталений термін "staging"? Справа в тому, що раніше, до «епохи великих даних та VLDB», дисковий простір був дуже дорогим – і часто первинні дані якщо і зберігалися, то обмежений інтервал часу. І часто ім'ям “staging” називають очищуєтьсябуфер.
Тепер же технології зробили крок вперед - і ми можемо дозволити собі не тільки зберігати всі первинні дані, але історизувати їх з тим ступенем гранулярності, який тільки можливий. Не означає, що ми повинні контролювати зростання даних і скасовує необхідність управляти життєвим циклом інформації, оптимізуючи вартість зберігання даних, залежно від «температури» використання – тобто. відводячи «холодні дані», які менш затребувані, на дешевші носії та платформи зберігання.

Що нам дає наявність «історизованого стейджингу»:

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

Які можуть виникнути складності при побудові стейджингу, що «історизується»:

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

Що ще цікавого можна сказати про цей прошарок.
По-перше, якщо ми відходимо від парадигми "наскрізних процесів завантаження" - то для нас більше не працює правило "караван йде зі швидкістю останнього верблюда", точніше ми відмовляємося від принципу "каравану" і переходимо на принцип "конвеєра": взяв дані з джерела – поклав у свій шар – готовий брати таку порцію. Це означає, що
1) ми не чекаємо, поки відбудеться обробка на інших шарах;
2) ми не залежимо від графіка надання даних іншими системами.
Простіше кажучи, ми ставимо на розклад процес завантаження, який бере дані з одного джерела через певний спосіб підключення до нього, перевіряє, чи виділяє дельту – і поміщає дані в цільові таблиці стейджингу. І все.

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

Шар аналітичних вітрин

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

Якщо споживачем є зовнішня система, то, як правило, вона диктує ті структури даних, які їй необхідні та регламенти забору інформації. Хорошим підходом вважається такий, за якого за коректний забір даних відповідає сам споживач. Сховище дані підготувало, сформувало вітрину, забезпечило можливість інкрементального забору даних (маркування мета-атрибутами для подальшого виділення дельти змін), а система-споживач далі сама керує та відповідає за те, як вона цією вітриною користується. Але бувають особливості: коли система немає активного компонента для забору даних – необхідний або зовнішній компонент, який виконає інтегруючу функцію, чи сховище виступить у ролі «платформи інтеграції» - і забезпечить коректне інкрементальне відвантаження даних далі – межі сховища. Тут спливає багато нюансів, і правила інтерфейсної взаємодії мають бути продумані та зрозумілі обом сторонам (втім, як завжди – коли йдеться про інтеграцію). До таких вітрин, як правило, застосовується регламентне очищення/архівування даних (рідко потрібно, щоб ці «транзитні дані» зберігалися тривалий час).

Найбільше значення з погляду аналітичних завдань є вітрини «для людей» - точніше для інструментів BI, з якими вони працюють.
Втім, є категорія «особливо розвинених користувачів» – аналітики, дослідники даних – яким не потрібні ні BI-інструменти, ні регламентні процеси наповнення зовнішніх спеціалізованих систем. Їм потрібні деякі «загальні вітрини» і «своя пісочниця», де вони можуть створювати таблиці та трансформації на власний розсуд. У цьому випадку відповідальність сховища полягає у забезпеченні наповнення даними цих загальних вітрин у відповідність до регламенту.
Окремо можна назвати таких споживачів як кошти Data Mining – глибокого аналізу даних. Такі інструменти мають свої вимоги до перепідготовки даних, і з ними працюють експерти з дослідження даних. Для сховища завдання зводиться – знову ж таки до підтримки сервісу із завантаження деяких вітрин узгодженого формату.

Проте, повернемося до аналітичних вітрин. Саме вони становлять інтерес з погляду розробників-проектувальників сховища у цьому шарі даних.
На мою думку, найкращий підхід до проектування вітрин даних, перевірений часом, на який зараз «заточені» практично всі платформи BI – це підхід Ральфа Кімбалла. Він відомий під назвою dimensional modeling - Багатомірне моделювання. Існує безліч публікацій на цю тему. Наприклад, з основними правилами можна ознайомитись у публікації Марги Росс. І, звичайно ж, можна рекомендувати від гуру багатовимірного моделювання. Інший корисний ресурс – «Поради Кімбалла»
Багатомірний підхід до створення вітрин описаний і опрацьований настільки добре – як з боку «євангелістів методу», так і з боку провідних вендорів ПЗ, що немає сенсу тут якось докладно на ньому зупинятися – першоджерело завжди краще.

Хотілося б зробити лише один акцент. «Звітність та аналітика» буває різною. Є «важкий reporting» - попередньо замовлені звіти, які формуються у вигляді файлів і доставляються користувачам за передбаченими каналами доставки. А є інформаційні панелі – BI dashboards. За своєю суттю це web-додатки. І на час відгуку цих додатків пред'являються такі самі вимоги, як й у будь-якого іншого web-приложения. Це означає, що нормальний час оновлення панелі BI – це секунди, а не хвилини. Важливо пам'ятати при розробці рішення. Як цього досягти? Стандартний метод оптимізації: дивимося, із чого складається час відгуку і що ми можемо впливати. На що найбільше витрачається час? На фізичні (дискові) читання БД, передачі даних по мережі. Як зменшити обсяг даних, що зчитуються і передаються за один запит? Відповідь очевидна і проста: потрібно дані або агрегувати, або накласти фільтр на великі таблиці фактові таблиці, що беруть участь у запиті, і виключити з'єднання великих таблиць (звернення до фактових таблиць повинні йти тільки через вимірювання).

Навіщо потрібен BI? Чим він зручний? Чому ефективна багатовимірна модель?
BI дозволяє користувачеві виконувати так звані «нерегламентовані запити». Що це означає? Це означає, що ми запиту заздалегідь точно не знаємо, але ми знаємо які показники в яких розрізах користувач може запросити. Користувач формує такий запит шляхом вибору відповідних фільтрів BI. І завдання розробника BI та проектувальника вітрин – забезпечити таку логіку роботи програми, щоб дані або фільтрувалися, або агрегувалися, не допускаючи ситуації, коли даних вимагається занадто багато – і додаток «зависав». Зазвичай починають з агрегованих цифр, далі заглиблюючись до детальніших даних, але принагідно встановлюючи потрібні фільтри.

Не завжди достатньо просто побудувати «правильну зірку» – і отримати зручну структуру для BI. Іноді потрібно десь застосувати денормалізацію (оглядаючись при цьому, як це вплине на завантаження), а десь зробити вторинні вітрини та агрегати. Десь додати індекси чи проекції (залежно від СУБД).

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

Сервісний шар

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

До цього шару відносять дві області зберігання даних:

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

Можна по-різному побудувати процес керування завантаженням. Один із можливих підходів такий: розбиваємо усі безліч таблиць сховища на модулі. У модуль можуть бути включені таблиці лише одного шару. Таблиці, що входять до складу кожного модуля, завантажуємо в рамках окремого процесу. Назвемо його керуючий процес . Запуск процесу керування ставиться на свій розклад. Керуючий процес оркеструє виклики атомарних процесів, кожен із яких завантажує одну цільову таблицю, і навіть містить деякі спільні кроки.
Очевидно, що досить просто розділити таблиці staging на модулі – за системами-джерелами, точніше їх точками підключення. Але для ядра це вже складніше – т.к. там необхідно забезпечити цілісність даних, отже треба враховувати залежності. Тобто. виникатимуть колізії, які потрібно вирішувати. І є різні методи їхнього вирішення.

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

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

Не ставлю завдання тут повністю висвітлити цю тему – організації завантаження – лише розставляю акценти, куди варто звернути увагу.
Наведений підхід – це лише один із варіантів. Він досить адаптивний. І його "концептуальним прототипом" послужив конвеєр Toyota і система "точно під час" (just-in-time). Тобто. ми тут відходимо від поширеної парадигми виключно «нічного завантаження даних», а завантажуємо невеликими порціями протягом дня – у міру готовності даних у різних джерелах: що прийшло – те й завантажили. При цьому у нас працює безліч паралельних процесів. А «гарячий хвіст» нових даних буде «моргати» - і через якийсь час вирівнюватися. Ми маємо врахувати таку особливість. І у разі потреби формувати користувальницькі вітринами «зрізами», де все вже цілісне. Тобто. не можна одночасно досягти і оперативності, і консистентності (цілісності). Потрібен баланс – десь важливе одне, десь інше.

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

Проектування та ведення моделей даних сховища

Чому при розробці будь-якої системи, де задіяна база даних (а в сховищі – особливо), важливо приділяти увагу проектування моделей даних? Чому б просто не накидати набір таблиць де завгодно – хоч у текстовому редакторі? Навіщо нам ці картинки?
Як не дивно, такі питання ставлять навіть досвідчені розробники.
Взагалі, ніщо не заважає накидати таблиці - і почати їх використовувати. Якщо… якщо при цьому в голові (!) розробник має струнку загальну картину тієї структури, яку він сприймає. А якщо розробників кілька? А що, якщо ці таблиці використовуватиме хтось ще? А якщо пройде час – людина залишить цю область, а потім до неї знову повернеться?

Чи можна розібратися без моделі? В принципі можна. І розібратися, і «прикинути картинки на папірці», і «пошерстити – поселити» дані. Але набагато простіше, зрозуміліше та швидше скористатися готовим артефактом – моделлю даних. А також розуміти «логіку її устрою» - тобто. добре б мати загальні правила гри.

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

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

Проектування моделей даних – це окрема, дуже велика тема. При проектуванні сховищ використовуються два основні підходи.
Для ядра добре підходить підхід «сутність-зв'язок» - коли будується нормалізована (3NF) модель з урахуванням саме дослідження предметної області, точніше виділеної її області. Тут грає та сама «корпоративна модель», про яку йшлося вище.

При проектуванні аналітичних вітрин підходить багатовимірна модель . Цей підхід добре лягає розуміння бізнес-користувачів – т.к. це модель, проста і зручна для людського сприйняття – люди оперують зрозумілими та звичними поняттями метрик (показників) та розрізів, за якими вони аналізуються. І це дозволяє просто і чітко побудувати процес збору вимог – ми малюємо набір «матриць розрізів та показників», спілкуючись із представниками різних підрозділів. А потім зводимо в одну структуру - "модель аналізу": формуємо "шину вимірювань" і визначаємо факти, які на них визначені. Принагідно опрацьовуємо ієрархії та правила агрегації.

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

Отже, під час моделювання даних сховища ми фактично вирішуємо кілька завдань:

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

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

Резюмуємо.

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

Особливості проектів сховищ даних

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

Сховище даних – це замовлення ПЗ

Сховище даних - це завжди "замовна розробка", а не коробкове рішення. Так, існують галузеві BI-додатки, що включають референсну модель даних, передналаштовані ETL-процеси з поширених джерел (наприклад, ERP систем), набір типових панелей BI і звітів. Але на практиці сховище вкрай рідко впроваджується як «коробка». Я працюю зі сховищами близько 10 років, і жодного разу не бачила такої історії. Завжди виринають свої нюанси, пов'язані з унікальними особливостями компанії – як бізнесу, так і ІТ-ландшафту. Тому сподіватися, що архітектуру надасть «вендор», який постачає рішення дещо необачно. Архітектура таких систем часто «визріває» всередині самої організації. Або її формують фахівці компанії-підрядника, що є основним виконавцем у проекті.

Сховище даних – це інтеграційний проект

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

Сховище даних – це колективний проект

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

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

Крім того, коли в процес розвитку системи залучено безліч людей і команд, часто розрізнених – то неминуче постають питання: як побудувати комунікації та інформаційну взаємодію між ними. Чим більш стандартні та зрозумілі підходи та практики використовуються – тим простіше, зручніше та ефективніше можна налагодити таку роботу. І в тому числі варто подумати про склад «робочих артефактів», серед яких для сховищ №1 – це моделі даних (див. попередній розділ).

Сховище даних має більший термін життя в порівнянні з іншими системами

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

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

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

Поступовий ітеративний розвиток

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

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

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

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

Сховища даних – «мульти-проектна історія»

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

Баланс інновацій та перевірених рішень

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

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

Подивимося на СУБД – як найбільш критичну та важливу для сховищ технологічну платформу.
Останнім часом явно намітився дрейф реляційних баз даних, створених спочатку як «універсальних» у бік спеціалізації. Вже давно провідні вендори випускають різні опції - для додатків різного класу (OLTP, DSS & DWH). Крім того, з'являються додаткові можливості для роботи з текстом, гео-даними тощо.

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

Мабуть, централізація та спеціалізація – це два взаємодоповнюючі тренди, які періодично змінюють один одного, забезпечуючи розвиток та баланс. Також як і еволюційний (поступовий) поступовий розвиток та кардинальні зміни. Так, у 90-х роках Майкл Стоунбрейкер був одним із авторів Маніфесту баз даних III покоління, в якому чітко звучала думка, що світові не потрібна ще одна революція у світі баз даних. Однак через 10 років він публікує роботи, в яких анонсує передумови початку нової ери у світі СУБД - саме виходячи з їхньої спеціалізації.
Він наголошує на тому, що поширені універсальні СУБД побудовані на «безрозмірній» (one-size-fits-all) архітектурі, яка не враховує ні змін апаратних платформ, ні поділу додатків на класи, для яких можна придумати більш оптимальне рішення, ніж реалізуючи Універсальні вимоги.
І починає розвивати низку проектів у відповідність до цієї ідеї. Один із яких – C-Store – колонкова СУБД, спроектована в архітектурі shared nothing (SN), спочатку створена спеціально для систем класу сховищ даних. Далі цей продукт отримав комерційний розвиток як HP Vertica.

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

Епілог

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

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

"Унікальність антикрихкості полягає в тому, що вона дозволяє нам працювати з невідомістю, робити щось в умовах, коли ми не розуміємо, що саме робимо, - і досягати успіху"/Насім Н.Талеб/

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

Галузеві моделі даних

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

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

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

Як правило, виділяються моделі вищого рівня (і більш загальні за змістом) та нижчого (відповідно, більш детальні). Верхній рівень моделювання – це так звані концептуальні моделі даних(conceptual data models), які дають загальну картину функціонування підприємства чи організації. Концептуальна модель включає основні концепції чи предметні галузі, критичні для функціонування організації; зазвичай їх кількість вбирається у 12-15. Така модель описує класи сутностей, важливих для організації (бізнес-об'єкти), їх характеристики (атрибути) та асоціації між парами цих класів (тобто зв'язки). Оскільки в бізнес-моделюванні термінологія ще остаточно не встояла, у різних англомовних джерелах концептуальні моделі даних можуть також називатися subject area model (що можна перекласти як моделі предметних областей) або subject enterprise data model (предметні корпоративні моделі даних).

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

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

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

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

Компанія може мати два шляхи створення корпоративної логічної моделі даних: будувати її самостійно або скористатися готовою. галузевою моделлю(Industry logical data model). У разі відмінності у термінах відбивають лише різні підходи до побудови однієї й тієї ж логічної моделі. У тому випадку, якщо компанія самостійно розробляє та впроваджує власну логічну модель даних, то така модель, як правило, має назву просто корпоративної логічної моделі. Якщо ж організація вирішує користуватися готовим продуктом професійного постачальника, тоді можна говорити про галузевій логічної моделі даних. Остання є готовою логічною моделлю даних, з високим ступенем точності відбиває функціонування певної галузі. Галузева логічна модель – це предметно-орієнтований та інтегрований вид усієї інформації, яка має знаходитись у корпоративному Сховищі даних для отримання відповідей як на стратегічні, так і на тактичні бізнес-питання. Як і будь-яка інша логічна модель даних, галузева модель залежить від прикладних рішень. Вона також не включає похідні дані або інші обчислення для швидкого отримання даних. Як правило, більшість логічних структур такої моделі знаходять гарне втілення у її ефективній фізичній реалізації. Такі моделі розробляються багатьма постачальниками для різних галузей діяльності: фінансової сфери, виробництва, туризму, охорони здоров'я, страхування і т.д.

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

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

Спеціаліст у галузі бізнес-аналітики (Business Intelligence) Стів Хобермен (Steve Hoberman) виділяє п'ять факторів, які необхідно брати до уваги при вирішенні питання про придбання галузевої моделі даних. Перший – це час та засоби, необхідні для побудови моделі. Якщо організації необхідно швидко досягти результатів, то галузева модель надасть перевагу. Використання галузевої моделі не може негайно забезпечити картину всієї організації, але здатне заощадити значну кількість часу. Замість власне моделювання час буде витрачено на зв'язування існуючих структур з галузевою моделлю, а також на обговорення того, як краще налаштувати її під потреби організації (наприклад, які визначення мають бути змінені, а які елементи даних – додані).

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

Третій фактор – досвід в оцінці ризиків та моделюванні. Створення корпоративної моделі даних потребує кваліфікованих ресурсів як із боку бізнесу, і IT-персоналу. Як правило, менеджери добре знають роботу організації в цілому, або діяльність конкретного відділу. Лише деякі з них мають як широкі (у масштабах усієї компанії), так і глибокі (у рамках підрозділів) знання про свій бізнес. Більшість менеджерів зазвичай добре знають лише одну область. Тому для того, щоб отримати загальнокорпоративну картину, потрібні суттєві бізнес-ресурси. Це збільшує вимоги до IT-персоналу. Чим більше бізнес-ресурсів потрібно для створення та тестування моделі, тим досвідченішими мають бути аналітики. Вони повинні не тільки знати, як отримати інформацію від бізнес-персоналу, але також вміти знаходити загальну точку зору в спірних галузях та бути здатними подавати всю цю інформацію в інтегрованому вигляді. Той, хто займається створенням моделі (у багатьох випадках це той самий аналітик), повинен мати гарні навички моделювання. Створення корпоративних логічних моделей вимагає моделювання «для майбутнього» та здатності конвертувати складний бізнес у буквальному значенні «в квадрати та лінії».

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

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

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

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

Галузеві моделі даних забезпечують компаніям єдине інтегроване подання їхньої бізнес-інформації. Багатьом компаніям буває непросто здійснити інтеграцію своїх даних, хоча це є необхідною умовою більшості загальнокорпоративних проектів. За даними дослідження Інституту Сховищ даних (The Data Warehousing Institute, TDWI), понад 69% опитаних організацій виявили, що інтеграція є суттєвим бар'єром для впровадження нових додатків. Навпаки, здійснення інтеграції даних приносить компанії суттєвий дохід.

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

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

Публікації

Стів Хобермен (Steve Hoberman). Використання галузевої логічної моделі даних як корпоративної моделі.
Клодіа Імхоф (Claudia Imhoff). Оперативне створення Сховищ даних та виконання проектів Business Intelligence за допомогою моделювання даних (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

Епілог

"Унікальність антикрихкості полягає в тому, що вона дозволяє нам працювати з невідомістю, робити щось в умовах, коли ми не розуміємо, що саме робимо, - і досягати успіху"/Насім Н.Талеб/

Теги: Додати теги

5.1. Організація даних у корпоративних інформаційних системах.

Розглядаючи КІС на спрощеному рівні можна сказати, що вона містить у собі корпоративну комп'ютерну (обчислювальну) мережу та спеціалізований пакет прикладних програм (ППП) для вирішення завдань предметної області. У свою чергу як ППП, так і комп'ютерна мережа припускають у своїй основі використання інформаційних даних про стан та розвиток, контрольованих та керованих ними систем. Історично склалося так, що КІС складається з окремих розгалужених підсистем окремих підприємств, взаємопов'язаних між собою і часто являють собою ієрархічну систему. Природно припустити, що такі підсистеми мають як власні джерела, і власні місця зберігання супутніх даних. Об'єднуючись у єдину систему, виникають питання спільного коректного використання даних, що територіально перебувають у різних місцях їх зберігання. Отже, для успішного управління виробничим об'єднанням, оснащеним КІС, йому потрібна надійна система збору, зберігання та обробки даних. Іншими словами, необхідна єдина інформаційна інфраструктура, що задовольняє стратегічним проектам BI (Business Intelligence) або інтегрована база для зберігання та використання даних. Головною метою інтеграції даних є отримання єдиної та цільної картини стану корпоративних бізнес-даних. Сама по собі інтеграція є складним процесом, в основі якого доцільно виділити:

Технології,

Продукти,

Програми.

Методи- Це підходи до інтеграції даних.

Технології- Це процеси, що реалізують ті чи інші методи інтеграції даних.

Продукти- це комерційні рішення, що підтримують ту чи іншу технологію інтеграції даних.

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

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

5.2. Корпоративні бази даних та вимоги до них

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

· Просте і зрозуміле користувачеві введення даних у базу,

· Зберігання даних у вигляді, який не призведе до надмірного розростання даних,

· Доступність до загальної інформаціїспівробітників усіх підрозділів корпорації за обов'язкової умови розмежування прав доступу,

· Швидке знаходження та вибірка необхідної інформації,

· Сортування та фільтрацію необхідних даних,

· Угруповання однойменних даних,

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

· Перетворення та наочність виведених даних,

· Масштабованість,

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

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

Створення інтегрованої корпоративної бази даних можливе різними методами, основними з яких є:

· Консолідація,

· Федералізація,

· Поширення.

5.3. Характеристика інтеграційних рішень корпоративних баз даних

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

Стосовно корпорації під час використання цього методу дані копіюються і збираються з первинних баз (БД – Slave) шляхом інтеграції на єдине місце зберігання (БД –Master). Зазвичай, таким місцем зберігання вибирається сервер центрального (головного) офісу (рис.5.1).

Рис.5.1. Метод консолідації даних

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

Найбільш поширеними технологіями підтримки таких рішень при консолідації є:

· Вилучення, перетворення та завантаження - ETL (Extract Transform Load);

· Управління змістом корпорації – ECM (Enterprise Content Management).

Достоїнствами методу консолідації є:

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

2. Можливість управління неструктурованими даними, такими як документи, звіти та сторінки завдяки технологічним рішенням ECM.

Для роботи з консолідованою базою даних КІС створюються спеціальні бізнес-додатки,які дозволяють створювати запити до даних бази, звіти та, на їх основі, здійснювати аналіз даних.

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

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

Таке відставання може становити від кількох секунд до кількох годин чи навіть днів.

федералізація.Під федералізацієюзазвичай розуміється об'єднання. Такий термін часто використовують у політиці при облаштуванні кордонів держави (наприклад, ФРН, РФ, США).

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

Рис.2. Метод федералізації даних

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

Підтримку федеративного підходу до інтеграції даних забезпечує технологія Enterprise information integration (E I I), що означає – Інтеграція корпоративної інформації.

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

Основними перевагами федеративного підходу є:

· можливість доступу до поточних даних без створення додаткової нової бази даних,

· Доцільність застосування після придбання або злиття компаній,

· Незамінність у тих випадках, коли з міркувань безпеки існують ліцензійні обмеження на копіювання даних первинних систем,

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

· Високий ступінь корисності для великих транснаціональних корпорацій.

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

· Зниження продуктивності через додаткові витрати на доступ до численних джерел даних,

· федералізація найбільш прийнятна для отримання невеликих масивів даних,

· Високі вимоги до якості первинних даних.

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

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

· Інтеграція корпоративних додатків EAI – Enterprise Application Integration,

· Тиражування корпоративних даних EDR – Enterprise Data Replication.

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

Рис.5.3. Метод розповсюдження даних

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

Поєднання в методі технологій інтеграції (EAI) та тиражування (EDR) дає множинні переваги у вигляді наступних переваг:

· Висока продуктивність,

· Можливість реструктуризації та очищення даних,

· Врівноваження навантаження за рахунок створення резервних копій та відновлення даних.

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

· Інтеграція даних про клієнтів у системах CDI - Customer Data Integration,

· Інтеграція даних про клієнтів у модулях CRM – Customer Relations Management.

Зокрема, підхід до реалізації CDI може бути виконаний різними шляхами.

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

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

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

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

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

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

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

5.4. Поняття та структурні рішення сховищ даних

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

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

В основі концепції сховищ даних покладено дві основні ідеї:

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

2. Поділ наборів даних та додатків, що використовуються для обробки та аналізу.

Сховище даних організується у випадках, коли необхідно отримати:

· Інтеграцію поточних та історичних значень даних,

· Об'єднання даних з розрізнених джерел,

· Створення надійної платформи даних для аналітичних цілей,

· Забезпечення однорідності даних в організації,

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

· Забезпечення широкої історичної картини та можливостей для аналізу тенденцій розвитку.

Історично сховища даних будувалися за одно-двома і трирівневою схемою.

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

Перевагами таких схем є:

· Швидка передача даних з оперативних систем у спеціалізовану систему без проміжних ланок,

· Мінімум витрат за рахунок використання єдиної платформи.

Недоліки:

· Вузьке коло вирішуваних питань через єдине джерело даних,

· Низька якість даних через відсутність етапу очищення.

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

Переваги:

· Витрини, що використовуються, проектуються для відповідей на конкретний ряд питань,

· Є можливість оптимізувати дані у вітринах, що сприяє підвищенню продуктивності.

Недоліки:

· Складність забезпечення несуперечності даних через багаторазове їх повторення у вітринах,

· Потенційна складність наповнення вітрин при великій кількості джерел даних,

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

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

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

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

· Склад є джерелом аналітичної інформації, що використовується для оперативного управління,

· В оперативному складі готуються дані для подальшого завантаження до центрального сховища. Під підготовкою даних мається на увазі проведення перевірок та перетворення даних у зв'язку з різним регламентом надходження даних від першого рівня.

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

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

Рис.5.4. Архітектура сховища даних

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

· Вилученняданих – це процес перенесення даних з неоднорідних джерел до оперативного складу,

· Перетворенняданих – це модифікація даних на основі спеціальних правил з подальшою передачею їх у центральне сховище,

· Очищенняданих – це виключення дублювання даних, які від різних джерел,

· Оновленняданих – це поширення оновлення даних на вихідні дані базових таблиць та похідні дані, розміщені у сховищі.

Переваги:

· Наповнення вітрин спрощено через використання єдиного джерела очищених даних,

· Вітрини даних синхронізовані з корпоративною бізнес – картиною, що дозволяє легко розширити центральне сховище та додати вітрини даних,

· Гарантована продуктивність.

Недоліки:

· Наявність надмірності даних, що веде до зростання вимог до технології зберігання даних,

5. 5.Системи управління базами даних та технології доступу до даних у КІС

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

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

Особливістю СУБД працюючих у КІС є те, що їм доводиться управляти базами даних, розміщеними на носіях, розподілених у просторі.

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

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

Характерною особливістю створених за допомогою СУБД програм для роботи з віддаленими та розподіленими корпоративними базами даних є використання відкритого інтерфейсу доступу до даних – ODBC (Open Data Base Connectivity). Всі функції передачі даних покладаються на інтерфейс ODBC, який є сполучним мостом між СУБД інтегрованої бази і СУБД клієнтських додатків. У цьому СУБД клієнта можуть взаємодіяти як зі своїми локальними базами, а й із даними, які у інтегрованої базі. Клієнт має можливість надсилати запити на СКБД інтегрованої бази, отримувати дані і пересилати власні оновлені дані.

Галузеві моделі даних

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

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

Публікації

Стів Хобермен (Steve Hoberman). Використання галузевої логічної моделі даних як корпоративної моделі.
Клодіа Імхоф (Claudia Imhoff). Оперативне створення Сховищ даних та виконання проектів Business Intelligence за допомогою моделювання даних (Fast-Tracking Data Warehousing & Business Intelligence Projects via Intelligent Data Modeling)

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

Поділіться роботою у соціальних мережах

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

ТЕМА V. КОРПОРАТИВНІ БАЗИ ДАНИХ

V .1. Організація даних у корпоративних системах. Корпоративні бази даних

V .2. СУБД та структурні рішення у корпоративних системах.

V.3. Технології Internet/Intranet та корпоративні рішення щодо доступу до баз даних.

V .1. ОРГАНІЗАЦІЯ ДАНИХ У КОРПОРАТИВНИХ СИСТЕМАХ. КОРПОРАТИВНІ БАЗИ ДАНИХ

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

Існують різні визначення баз даних.

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

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

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

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

Основні вимоги до баз даних:

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

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

База знань (БЗ)  сукупність баз даних та використовуваних правил, отриманих від осіб, які приймають рішення. База знань є елементом експертних систем.

Слід розрізняти різні способи представлення даних.

Фізичні дані | це дані, що зберігаються у пам'яті ЕОМ.

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

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

Рис. 1.1. Структура взаємодії підрозділів із інформаційними ресурсами корпорації.

Корпоративні бази даних бувають зосереджені (централізовані) та розподілені.

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

Рис.1.2. Схема гетерогенної централізованої бази даних

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

Великий потік обміну даними;
Високий трафік у мережі;
Низька надійність;
Низька загальна продуктивність.

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

Вищий рівень одночасності обробки внаслідок розподілу навантаження;
Поліпшення використання даних на місцях під час виконання віддалених (дистанційних) запитів;
Найменші витрати;
Простота керування локальними базами.

Витрати створення мережі, у вузлах якої перебувають робочі станції (малі ЕОМ), набагато нижчі, ніж видатки створення аналогічної системи з допомогою великий ЕОМ. На Рис.1.3 наведена логічна схема розподіленої бази даних.

Рис.1.3. Розподілена база даних корпорації.

Дамо наступне визначення розподіленої бази даних.

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

Найважливішими вимогами до характеристик розподіленої бази даних є:

Масштабованість;
Сумісність;
Підтримка різних моделей даних;
Перенесення;
Прозорість розташування;
Автономність вузлів розподіленої бази даних (Site Autonomy);
Обробка розподілених запитів;
Виконання розподілених транзакцій.
Підтримка однорідної системи безпеки.

Прозорість розташування дозволяє користувачам працювати з базами даних, не знаючи нічого про їхнє розташування. Автономність вузлів розподіленої бази даних означає, що ведення кожної бази може відбуватися незалежно від інших. Розподілений запит - це запит (SQL-пропозиція), під час виконання якого відбувається доступом до об'єктів (таблицям чи уявленням) різних баз даних. За виконання розподілених транзакцій здійснюється узгоджене управління (concurrency control) всіма залученими базами даних. Oracle7 використовує технологію двофазної передачі для виконання розподілених транзакцій.

Бази даних, що становлять розподілену базу даних, не обов'язково повинні бути однорідними (тобто вестися однією СУБД) або оброблятися в середовищі однієї і тієї ж операційної системи та/або на комп'ютерах того самого типу. Наприклад, одна база даних може бути базою Oracle на комп'ютері SUN з операційною системою SUN OS(UNIX), друга база даних може вестися СУБД DB2 на мейнфреймі IBM 3090 з операційною системою MVS, а для ведення третьої бази може використовуватися СУБД SQL/DS мейнфрейме IBM, але з операційною системою VM. Обов'язково тільки одна умова - всі машини з базами даних повинні бути доступні через мережу, в яку вони входять.

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

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

При створенні розподіленої бази даних концептуальному рівні доводиться вирішувати такі задачи:

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

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

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

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

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

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

Основна мета DW - створення єдиного логічного уявлення даних, які у різнотипних БД, чи, іншими словами, єдиної моделі корпоративних даних.

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

У структурі корпорації може бути присутнім банк даних.

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

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

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

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

V .2. СУБД І СТРУКТУРНІ РІШЕННЯ У КОРПОРАТИВНИХ СИСТЕМАХ

Системи управління базами даних та знань

Важливою складовою сучасних інформаційних систем системи управління базами даних (СУБД).

СУБД комплекс програмних та мовних засобів, призначених для створення, ведення та використання баз даних.

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

Основна особливість сучасних СУБД - те, що сучасні СУБД підтримують такі технології як:

Технологію клієнт/сервер.
Підтримка мов БД. Цемова визначення схемиБД (SDL - Schema Definition Language),мова маніпулювання даними (DML - Data Manipulation Language), інтегровані мови SQL (Structured Queue Language), QDB (Query - By - Example) і QMF (Query Management Facility ) Розвинений периферійний засіб специфікації запитів та генерації звітів для DB 2 і т. д.;
Безпосереднє керування даними у зовнішній пам'яті.
Управління буферами оперативної пам'яті.
Управління транзакціями. OLTP технологія (On-Line Transaction Processing), OLAPтехнологія (On-Line Analysis Processing)для DW.
Забезпечити захист та цілісність даних. Використання системи дозволяється лише користувачам, які мають право доступу до даних. При виконанні користувачами операцій над даними підтримується узгодженість даних, що зберігаються (цілісність). Це важливо в корпоративних розрахованих на багато користувачів інформаційних системах.
Журналізація.

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

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

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

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

По відношенню до корпоративних (розподілених) баз даних умовно можна виділити такі типи СУБД:

СУБД "Робочого столу". Ці продукти, в першу чергу, орієнтовані на роботу з персональними даними (дані "робочого столу"). Вони мають набори команд спільного використання загальних БД, але невеликого розміру (типу малого офісу). Насамперед, це СУБД типу Ассеss, dВАSЕ, Рагаdох, ЕохРго. Чому Ассеss, dВАSЕ, Рагаdох, ЕохРго мають незадовільний доступ до корпоративних даних. Справа в тому, що не існує простого способу подолати бар'єр між персональними та корпоративними даними. І суть навіть не в тому, що механізм СУБД персональних даних (або малого офісу) орієнтований на доступ до даних через багато шлюзів, міжмережевих продуктів і т.д. Проблема полягає в тому, що ці механізми пов'язані з повною передачею файлів і відсутністю розгалуженої підтримки індексів, в результаті чого черги до сервера практично зупиняють роботу у великих системах.
Спеціалізовані високопродуктивні розраховані на багато користувачів СУБД. Такі СУБД характеризуються наявністю розрахованого на багато користувачів ядра системи, мови маніпулювання даними та наступними функціями, характерними для розвинених розрахованих на багато користувачів СУБД:
організацією буферного пулу;
наявністю системи обробки черг транзакцій;
наявністю механізмів розрахованого на багато користувачів блокування даних;
веденням журналу транзакцій;
наявністю механізмів розмежування доступу.

Це СУБД типу Oracle, DВ2, SQL/Server, Informix, Sybase, ADABAS, Titanium та інші надають широкий сервіс обробки корпоративних БД.

Працюючи з базами даних використовується механізм транзакцій.

Транзакція Це логічна одиниця роботи.

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

Транзакція має чотири важливі властивості, відомі як властивості АСІД:

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

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

Подано команду COMMIT WORK (зафіксувати транзакцію).
Подано команду ROLLBACK WORK (відкотити транзакцію).
Сталося від'єднання користувача від СУБД.
Стався збій системи.

Для користувача вона носить, як правило, атомарний характер. Насправді це складний механізм взаємодії користувач (додаток) база даних. Програмне забезпечення корпоративних систем використовують механізм обробки транзакцій у реальному часі (Online Transaction Processing Systems, OLTP), зокрема програми бухгалтерського обліку, програмне забезпечення прийому та обробки клієнтських заявок, фінансові програми, виробляють масу інформації. Ці системи розраховані (і відповідним чином оптимізовані) на обробку великих обсягів даних, виконання складних транзакцій та інтенсивних операцій читання/запису.

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

Доставкою інформації кінцевому користувачеві - займаються системи аналітичної обробки даних у реальному часі (On-line Analytical Processing, OLAP), Які забезпечують виключно простий доступ до даних за рахунок зручних засобів генерації запитів та аналізу результатів. В OLAP-системах цінність інформаційного товару збільшується завдяки застосуванню різноманітних методів аналізу та статистичної обробки. Крім того, ці системи оптимізовані з точки зору швидкості вилучення даних, збору узагальненої інформації та орієнтовані на пересічних користувачів (мають інтуїтивно зрозумілий інтерфейс). Якщо OLTP-система видає відповіді на прості питання типу "який був рівень продажу товару N у регіоні M у січні 199х р.?", то OLAP-системи готові до більш складних запитів користувачів, наприклад: "Дати аналіз продажу товару N по всіх регіонах за планом на другий квартал у порівнянні з двома попередніми роками".

Архітектура клієнт/сервер

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

		База даних
Комп'ютер-сервер
Мережа
IBM-сумісний ПК	IBM-сумісний ПК	IBM-сумісний ПК
		Програми

Рис. 2.1. Система архітектури клієнт-сервер

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

Сервер (Server) ¦ це об'єкт (ЕОМ), що надає послуги іншим об'єктам за їх запитами.

Як випливає з самого терміну, головна функція комп'ютера-сервера полягає в обслуговуванні потреб клієнта. Термін "Сервер" використовується для позначення двох різних груп функцій: файл-сервер і сервер баз даних (далі ці терміни означають залежно від контексту програмне забезпечення, що реалізує зазначені групи функцій, або комп'ютери з цим програмним забезпеченням). Файл-сервери призначені до виконання операцій із базами даних, їх основна функція - поділ файлів між кількома користувачами, тобто. забезпечення одночасного доступу багатьох користувачів до файлів на комп'ютері – файл-сервері. Приклад файл-сервера є операційна система NetWare компанії Novell. Сервер баз даних можна встановити та привести в дію на комп'ютері - файл-сервері. СУБД Oracle у вигляді NLM (Network Loadable Module) виконується серед NetWare на файл-сервері.

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

Одна з важливих вимог до сервера - це те, що операційна система, в середовищі якої розміщений сервер баз даних, має бути багатозадачною (і, бажано, але не обов'язково, розрахованою на багато користувачів). Наприклад, СУБД Oracle, встановлена на персональному комп'ютері з операційною системою MS-DOS (або PC-DOS), що не задовольняє вимогу багатозадачності, не може використовуватися як сервер баз даних. І та ж СУБД Oracle, встановлена на комп'ютері з багатозадачною (хоча і не багатокористувацькою) операційною системою OS/2, може бути сервером баз даних. Багато різновидів систем UNIX, MVS, VM і деякі інші операційні системи є і багатозадачними, і розрахованими на багато користувачів.

Розподілені обчислення

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

розподілена база даних;
Розподілена обробка даних.

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

Існує багато типів серверів:

сервер баз даних;
Сервер друку;
Сервер віддаленого доступу;
Факс-сервер;
Web-сервер і т.д.

В основі базової технології Клієнт/сервер лежать такі базові технології, як:

Технології операційних систем; концепція взаємодії відкритих систем; створення об'єктно-орієнтованих середовищ функціонування програм;
Телекомунікаційні технології;
Мережеві технології;
Технології графічного інтерфейсу користувача ( GUI);
І т.д.

Переваги технології клієнт-сервер:

Технологія клієнт/сервер дозволяє проводити обчислення на неоднорідних обчислювальних середовищах. Незалежність від платформ: доступ до різноманітних мережних середовищ, до складу яких входять комп'ютери різних типів із різними операційними системами.
Незалежність джерел даних: доступом до інформації різнорідних баз даних. Приклади таких систем - DB2, SQL / DS, Oracle, Sybase.
Баланс завантаження клієнта та сервера.
Виконання обчислень там, де це відбувається найефективніше;
Надають можливість ефективного масштабування;
Міжплатформні обчислення. Міжплатформні обчислення визначаються просто як реалізація технологій у неоднорідних обчислювальних середовищах. Тут мають бути забезпечені такі можливості:
Додаток має виконуватися на кількох платформах;
На всіх платформах воно повинно мати той самий інтерфейс і логіку роботи;
Додаток має інтегруватися з рідним операційним середовищем;
Воно має однаково поводитись на всіх платформах;
Для нього має передбачатися проста та узгоджена підтримка.

 Розподілені обчислення. Розподілені обчислення передбачають розподіл робіт між кількома обчислювальними машинами (щоправда, розподілені обчислення ширше поняття).

 Розукрупнення. Розукрупнення ¦ перенесення додатків для великих ЕОМ на малі комп'ютерні платформи.

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

 Скорочення загального часу виконання програми;

 Зменшення використання клієнтом пам'яті;

 Скорочення мережного трафіку.

Можливість роботи з мультимедіа: на цей час створено чимало програм роботи з мультимедіа для ПК. Подібних програм зміни термінал-хост або ні, або дуже дорогі.
Можливість залучення великих обчислювальних ресурсів для операцій з базами даних: оскільки програми виконуються на комп'ютерах-клієнтах, на комп'ютері-сервері для операцій з базами даних вивільняються додаткові (порівняно з конфігурацією термінал-хост) ресурси, такі як обчислювальні ресурси центрального процесора та оперативна пам'ять.
Вища продуктивність роботи програмістів: продуктивність праці програмістів зростає завдяки використанню таких засобів, як SQL*Forms і CASE: вони дозволяють розробляти програми швидше, ніж такі мови програмування, як C, PL1 чи COBOL.
Підвищення продуктивності роботи кінцевих користувачів: в даний час багато кінцевих користувачів освоїли такі системи, як Lotus, Paradox, Word Perfect, Harvard Graphics і т.д.

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

Рис. 2.2. Ілюстрація доступу клієнтів до загального ресурсу сервера.

Як впровадити технологію клієнт-сервер

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

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

Мова SQL . Мова запитів високого рівня - SQL (Structured Query Language ) служить для реалізації запитів до баз даних, таких як ЯМД, ЯОД та ПЯД і прийнятий як стандарт. Мова SQL спочатку було прийнято як мову даних програмних виробів фірми IBM та ЯМД реляційної СУБД SYSTEM R фірми IBM . Важливою особливістю мови SQL полягає в тому, що та сама мова представляється через два різні інтерфейси, а саме: через інтерактивний інтерфейс і через інтерфейс прикладного програмування (динамічний SQL). Динамічний SQL складається з безлічі можливостей вбудованої мови SQL , передбачених спеціально для конструювання інтерактивних додатків, де під інтерактивним додатком розуміється програма, написана для підтримки звернення до бази даних кінцевого користувача, що працює на інтерактивному терміналі. Мова SQL забезпечує виконання функцій визначення, маніпулювання та управління даними баз даних і є прозорим для користувача з погляду СУБД, що реалізується.

Рис. 2.3. Схема виконання запитів користувача до розподілених баз даних.

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

Модель даних складається з трьох компонентів:

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

Одною з найважливіших характеристикроботи СУБД є можливість пов'язувати об'єкти.

Існують такі види зв'язків між об'єктами:

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

Існують такі основні моделі даних:

Реляційна модель даних.
Ієрархічна модель даних.
Неповна мережна модель даних.
Модель даних CODASYL.
Розширена мережева модель даних.

V.3. ТЕХНОЛОГІЇ INTERNET/INTRANET І КОРПОРАТИВНІ РІШЕННЯ ЗА ДОСТУПОМ ДО БАЗІВ ДАНИХ

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

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

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

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

Інші схожі роботи, які можуть вас зацікавити.
6914.		Поняття бази даних	11.56 KB
	Базою даних є представлена в об'єктивній формі сукупність самостійних матеріалів статей розрахунків нормативних актів судових рішень та інших подібних матеріалів систематизованих таким чином, щоб ці матеріали могли бути знайдені та оброблені за допомогою електронної обчислювальної машини Цивільного кодексу РФ ст. База даних організована відповідно до певних правил і підтримувана в пам'яті комп'ютера сукупність даних, що характеризує актуальний стан деякої...
8064.		Розподілені бази даних	43.66 KB
	Розподілені бази даних Під розподіленою базою даних РБД розуміється набір логічно пов'язаних між собою даних, що розділяються, які фізично розподілені по різних вузлах комп'ютерної мережі. Доступ до даних не повинен залежати від наявності або відсутності реплік даних. Система повинна автоматично визначати методи виконання з'єднання об'єднання даних мережевий канал здатний впоратися з обсягом інформації, що передається, і вузол має достатню обчислювальну потужність для з'єднання таблиць. СУРБД має бути здатною...
20319.		БАЗИ ДАНИХ ТА ЇХ ЗАХИСТ	102.86 KB
	Оперативні бази даних з'явилися в середині 1960-х. Операції над оперативними базами даних оброблялися інтерактивному режимі з допомогою терміналів. Прості індексно-послідовні організації записів швидко розвинулися більш потужної моделі записів, орієнтованої на набори. За керівництво роботою Data Base Task Group (DBTG), яка розробила стандартну мову опису даних та маніпулювання даними, Чарльз Бахман отримав Т'юрінгівську премію.
5031.		Розробка бази даних Бібліотека	11.72 MB
	Технологія проектування бази даних. Визначення взаємозв'язків між сутностями та створення моделі даних. Основні ідеї сучасної інформаційної технології базуються на концепції згідно з якою дані повинні бути організовані в бази даних з метою адекватного відображення реального світу, що змінюється, і задоволення інформаційних потреб користувачів. Ці бази даних створюються та функціонують під управлінням спеціальних програмних комплексівзваних системами управління базами даних СУБД.
13815.		Ієрархічна модель бази даних	81.62 KB
	Основні ідеї сучасної інформаційної технології базуються на концепції баз даних згідно з якою основою інформаційної технології є дані організовані в базах даних, що адекватно відображають стан тієї чи іншої предметної області та забезпечують користувача актуальною інформацією в цій предметній галузі. Необхідно визнати той факт, що дані є...
14095.		Розробка бази даних бібліотеки	11.72 MB
	Збільшення обсягу та структурної складності даних, що зберігаються, розширення кола користувачів інформаційних систем призвели до широкого поширення найбільш зручних і порівняно простих для розуміння реляційних (табличних) СУБД.
5061.		Створення бази даних поліклініки	2.4 MB
	Розвиток засобів обчислювальної техніки та інформаційних технологій забезпечив можливості для створення та широкого застосування автоматизованих інформаційних систем (АІС) різноманітного призначення. Розробляються та впроваджуються інформаційні системи управління господарськими та технічними об'єктами
13542.		Бази даних геологічної інформації	20.73 KB
	Останнім часом широкими темпами відбувається впровадження комп'ютерних технологійі, зокрема, баз даних, у наукову сферу. Цей процес не оминає і геологію, оскільки саме в природничих науках є необхідність для зберігання та обробки великих обсягів інформації.
9100.		Бази даних. Основні поняття	26.28 KB
	База даних - це сукупність відомостей про конкретні об'єкти реального світу в будь-якій предметній галузі. Кожен об'єкт характеризується яким-небудь набором даних властивостей, які в БД називаються атрибутами.
5240.		Створення бази даних «Деканат ВНЗ»	1.57 MB
	База даних (БД) - це сукупність взаємозалежних, що зберігаються разом на зовнішніх носіях пам'яті комп'ютера даних, за наявності такої організації та мінімальної надмірності, яка допускає їх використання оптимальним чином для одного або кількох додатків

Ціль лекції

Вивчивши матеріал цієї лекції, ви знатимете:

що таке корпоративна модель даних ;
як перетворити корпоративну модель данихмодель сховища даних;
основні елементи корпоративної моделі даних ;
рівні представлення корпоративної моделі даних ;
алгоритм перетворення корпоративної моделі даних на багатовимірну модель сховища даних ;

і навчіться:

розробляти моделі сховища даних на основі корпоративної моделі данихорганізації;
розробляти схему "зірка" за допомогою CASE-засобів;
секціонувати таблиці багатовимірної моделі за допомогою CASE-коштів.

Корпоративна модель даних

Вступ

Ядром будь-якого ХД є його модель даних. Без моделі даних буде дуже складно організувати дані у ХД. Тому розробники ХД повинні витратити час та сили на розробку такої моделі. Розробка моделі ХД лягає на плечі проектувальника ХД.

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

Відправною точкою в проектуванні ХД може бути так звана корпоративна модель даних(corporate data model або enterprise data model, EDM), що створюється у процесі проектування OLTP-систем організації. При проектуванні корпоративної моделі данихзазвичай робиться спроба створити з урахуванням бізнес-операцій таку структуру даних, яка зібрала і синтезувала у собі всі інформаційні потреби організації.

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

Корпоративна модель даних

Як вирішити завдання перетворення корпоративної моделі данихмодель ХД? Щоб розв'язати це завдання, необхідно мати цю модель, тобто. корпоративна модель данихмає бути побудована та документована. І треба зрозуміти, щоз цієї моделі та якмає трансформуватися у модель ХД.

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

Основними елементами корпоративної моделі данихє:

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

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

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

p align="justify"> Корпоративна модель даних підрозділяється відповідно до предметних областей, які представляють групи сутностей, що відносяться до підтримки конкретних потреб бізнесу. Деякі предметні області можуть покривати такі специфічні бізнес-функції, як управління контрактами, інші об'єднувати сутності, що описують продукти чи послуги.

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

Корпоративна модель даних зазвичай має кілька рівнів уявлення. На самому високому рівні(high level) корпоративної моделі данихрозташовується опис основних предметних областей організації та його взаємозв'язків лише на рівні сутностей. На рис. 16.2 наведено фрагмент корпоративної моделі данихверхнього рівня.

Рис. 16.2.

На схемі, наведеній на малюнку, представлено чотири предметні області: "Покупець" ( Customer), "Рахунок" ( account), "Замовлення" ( Order) та "Товар" ( Product). Як правило, на верхньому рівні представлення моделі вказуються лише прямі зв'язкиміж предметними областями, які, наприклад, фіксують такий факт: покупець оплачує рахунок замовлення товарів. Детальна інформація та непрямі взаємозв'язки на цьому рівні корпоративної моделіне наводяться.

Наступного, середньому рівні(Mid level) корпоративної моделі данихпоказується докладна інформація про об'єкти предметних областей, тобто ключі та атрибути сутностей, їх взаємозв'язки, підтипи та супертипи і т.д. Для кожної предметної області моделі верхнього рівня є одна модель середнього рівня. На рис. 16.3 зображено середній рівень уявлення корпоративної моделідля фрагмента предметної сфери "Замовлення".

З рис. 16.3 видно, що предметна область "Замовлення" ( Order) включає кілька сутностей, визначених через їх атрибути, і взаємозв'язків між ними. Представлена модель дозволяє відповісти на такі питання, як дата замовлення, хто зробив замовлення, хто відправив замовлення, хто отримує замовлення та низку інших. З наведеної схеми видно, що у цій організації виділяють два типи замовлень – замовлення з рекламної акції ( Commersial) та замовлення з роздрібної торгівлі ( Retail).

Зауважимо, що корпоративна модель данихможе представляти різні аспекти діяльності організації та з різним ступенем деталізації та завершеності. Якщо корпоративна модельпредставляє всі аспекти діяльності організації, вона ще називається моделлю даних організації(Enterprise data model).

З точки зору проектування ХД важливим фактором у прийнятті рішення створення моделі ХД корпоративної моделі данихє стан завершеності корпоративної моделі даних.

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

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

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

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

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

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

Приклад моделі "ГІС для органів влади та місцевого самоврядування".

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

Допомогти у полегшенні та оптимізації цього процесу, у перекладі ІТ-підходу на сучасний рівень якраз і покликані галузеві моделі даних.

Галузеві моделі даних від компаніїEsri

Моделі даних під платформу Esri ArcGIS є робочими шаблонами для застосування в ГІС-проектах і створення структур даних для різних прикладних областей. Формування моделі даних включає створення концептуального дизайну, логічної та фізичної структури, які потім можна використовувати для побудови персональної чи корпоративної бази геоданих. ArcGIS надає інструменти для створення та управління схемою бази даних, а шаблони моделі даних використовуються для швидкого запуску ГІС-проекту з різних сфер застосування та галузей. Спеціалісти Esri разом із спільнотою користувачів витратили значну кількість часу на розробку ряду шаблонів, які можуть забезпечити можливість швидкого початку проектування бази геоданих підприємства. Ці проекти описані та документовані на веб-сайті support.esri.com/datamodels . Нижче, в порядку їх згадування на цьому сайті, представлений змістовий переклад назв галузевих моделей Esri:

Адресний реєстр
Сільське господарство
Метеорологія
Базові просторові дані
Біорізноманіття
Внутрішній простір будівель
Облік парникових газів
Ведення адміністративних кордонів
Збройні сили. Розвідка
Енергетика (включаючи новий протокол ArcGIS MultiSpeak)
Екологічні споруди
МНС. Пожежна охорона
Лісовий кадастр
Лісне господарство
Геологія
ГІС національного рівня (e-gov)
Підземні та стічні води
Охорона здоров'я
Археологія та охорона пам'ятних місць
Національна безпека
Гідрологія
Міжнародна гідрографічна організація (IHO). Формат S-57 для ENC
Іригація
Земельний кадастр
Муніципальний уряд
Морська навігація
Державний кадастр
Нафтогазові структури
Трубопроводи
Растрові сховища
Батиметрія, рельєф морського дна
Телекомунікації
Транспорт
Водопровід, каналізація, ЖКГ

Ці моделі містять усі необхідні ознаки галузевого стандарту, а саме:

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

Фахівці Esri входять до експертної групи незалежних органів, які рекомендують до використання різні галузеві моделі, наприклад PODS (Pipeline Open Data Standards - відкритий стандарт для нафтогазової галузі; в даний час є реалізація PODS як база геоданих Esri PODS Esri Spatial 5.1.1) або база геоданих (БГД) з ArcGIS for Aviation, яка враховує рекомендації ICAO та FAA, а також стандарт обміну навігаційними даними AIXM 5.0. Крім того, існують рекомендовані моделі, які суворо відповідають існуючим галузевим стандартам, наприклад S-57 та ArcGIS for Maritime (морські та прибережні об'єкти), а також моделі, створені за результатами виконаних робіт Esri Professional Services і є «де-факто» стандартами у відповідній області. Наприклад, GIS for the Nation і Local Government ("ГІС для органів державної влади та місцевого самоврядування") вплинули на стандарти NSDI та INSPIRE, а Hydro та Groundwater (гідрологія та ґрунтові води) активно використовуються у вільно доступному професійному пакеті ArcHydro та комерційних продуктах третіх фірм. Слід зазначити, що Esri підтримує і стандарти "de-facto", наприклад NHDI. Всі запропоновані моделі даних документовані та готові до використання в ІТ-процесах підприємства. Супровідні матеріали до моделей включають:

UML-діаграми зв'язків сутностей;
структури даних, домени, довідники;
готові шаблони баз геоданих у форматі ArcGIS GDB;
приклади даних та приклади додатків;
приклади скриптів завантаження даних, приклади утиліт аналізу;
довідники за пропонованою структурою даних.

Компанія Esri узагальнює свій досвід побудови галузевих моделей у вигляді книг і локалізує матеріали, що публікуються. Компанією Esri CIS локалізовано та видано наступні книги:

Геопросторова сервіс-орієнтована архітектура (СОА);
Проектування баз геоданих для транспорту;
Корпоративні геоінформаційні системи;
ГІС: нова енергія електричних та газових підприємств;
Нафта та газ на цифровій карті;
Моделювання нашого світу. Керівництво Esri з проектування бази геоданих;
Думаючи про ГІС. Планування ГІС: посібник для менеджерів;
Географічні інформаційні системи. Основи;
ДВС для адміністративно-господарського управління;
Веб-ГІС. Принципи та застосування;
Стратегії проектування систем, 26 видання;
68 випусків журналу ArcReview з публікаціями компаній та користувачів ГІС-систем;
... і безліч інших тематичних нотаток та публікацій.

Наприклад, книга " Моделювання нашого світу…(переклад) - це всебічний посібник і довідник з моделювання даних у ГІС взагалі, і за моделлю даних бази геоданих зокрема. даних та збору даних до просторового аналізу та візуального представлення: Докладно описується, як спроектувати географічну БД, відповідну проекту, налаштувати функціональність бази даних без програмування, керувати потоком робіт у складних проектах, моделювати різноманітні мережеві структури, такі як річкові, транспортні чи електричні мережі, впроваджувати дані космозйомки у процес географічного аналізу та відображення, а також створювати 3D-моделі даних ГІС. Проектування баз геоданих для транспортумістить методологічні підходи, випробувані на великій кількості проектів і повністю відповідають законодавчим вимогам Європи та США, а також міжнародним стандартам. А в книзі ГІС: нова енергія електричних та газових підприємствз використанням реальних прикладів показані переваги, які корпоративна ГІС може дати компанії-постачальнику енергії, включаючи такі аспекти як обслуговування клієнтів, експлуатація мереж та інші бізнес-процеси.

Деякі з книг, перекладних та оригінальних, виданих російською мовою компаніями Esri CIS та DATA+. Вони зачіпаються як концептуальні питання, пов'язані з технологією ГІС, і багато прикладні аспекти моделювання і розгортання ГІС різного масштабу і призначення.

Застосування галузевих моделей розглянемо з прикладу моделі даних BISDM (Building Interior Space Data Model, інформаційна модель внутрішнього простору будівлі) версії 3.0. BISDM є розвитком більш загальної моделі BIM (Building Information Model, інформаційна модель будівлі) і призначена для використання в задачах проектування, будівництва, експлуатації та виведення з експлуатації будівель та споруд. Використовується в ПЗ ГІС, дозволяє ефективно обмінюватися геоданими з іншими платформами та взаємодіяти з ними. Належить до загальної групи завдань FM (управління інфраструктурою організації). Перерахуємо основні переваги моделі BISDM, застосування якої дозволяє:

організувати обмін інформацією в гетерогенному середовищі єдиним правилам;
отримати «фізичне» втілення концепції BIM та рекомендованих правил керування проектом будівництва;
підтримувати засобами ДВС єдине сховище на всьому життєвому циклі будівлі (від проекту до виведення з експлуатації);
координувати роботу різних спеціалістів у проекті;
візуалізувати закладений календарний план та етапи будівництва для всіх учасників;
давати попередню оцінку вартості та термінів зведення (4D- та 5D-дані);
контролювати хід реалізації проекту;
забезпечити якісну експлуатацію будівлі, включаючи обслуговування та ремонти;
стати частиною системи управління активами, включаючи функції аналізу ефективності використання площ (здавання в оренду, складські приміщення, менеджмент працівників);
проводити розрахунок та здійснювати управління завданнями енергоефективності будівлі;
моделювати рух людських потоків.

BISDM визначає правила роботи з просторовими даними на рівні внутрішніх приміщень у будівлі, у тому числі призначення та види використання, прокладені комунікації, встановлене обладнання, Облік ремонтів та обслуговування, протоколювання інцидентів, взаємозв'язки з іншими активами компанії. Модель допомагає створювати єдине сховище географічних та негеографічних даних. Було використано досвід провідних світових компаній виділення сутностей і моделювання лише на рівні БГД (бази геоданих) просторових і логічних взаємозв'язків всіх фізичних елементів, формують як саму будівлю, і його внутрішні приміщення. Дотримання принципів BISDM дозволяє суттєво спростити завдання інтеграції коїться з іншими системами. На першому етапі це зазвичай інтеграція з CAD. Потім, при експлуатації будівлі, використовується обмін даними з ERP та EAM-системами (SAP, TRIRIGA, Maximo та ін.).

Візуалізація структурних елементів BISDM засобами ArcGIS.

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

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

Ще раз відзначимо, що при спільному використанні BISDM і ArcGIS з'являється можливість автоматичної побудови 3D-моделей за накопиченими даними, оскільки БГД містить повний опис об'єкта, включаючи z-координати, приналежність до поверху, види з'єднань елементів, способи встановлення обладнання, матеріал, доступні шляхи переміщення персоналу, функціональне призначення кожного елемента тощо. і т.п. Потрібно врахувати, що після виконання первинного імпорту всіх проектних матеріалів у BISDM БГД виникає потреба додаткового інформаційного наповнення для:

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

За рахунок застосування ArcGIS спрощується імпорт додаткових 3D-об'єктів та довідників з зовнішніх джерел, т.к. модуль ArcGIS Data Interoperability дозволяє створювати процедури імпорту подібних даних і коректному їх розміщення всередині моделі. Підтримуються всі формати, що використовуються в даній галузі, у тому числі IFC, AutoCAD Revit, Bentlye Microstation.

Галузеві моделі даних від компанії IBM

IBM надає набір інструментів та моделей керування зберіганням даних для різних областей діяльності:

IBM Banking and Financial Markets Data Warehouse (фінанси)
IBM Banking Data Warehouse
IBM Banking Process and Service Models
IBM Health Plan Data Model (охорона здоров'я)
IBM Insurance Information Warehouse (страхування)
IBM Insurance Process and Service Models
IBM Retail Data Warehouse (роздрібна торгівля)
IBM Telecommunications Data Warehouse (телекомунікації)
InfoSphere Warehouse Pack:
- for Customer Insight (для розуміння клієнтів)
- for Market and Campaign Insight (для розуміння компанії та ринку)
- for Supply Chain Insight (для розуміння постачальників).

Наприклад, модель IBMBankingandFinancialMarketsDataWarehouseпризначена для вирішення специфічних проблем банківської галузі з точки зору даних, а IBMBankingProcessandServiceModels- з погляду процесів та СОА (сервіс-орієнтованої архітектури). Для телекомунікаційної галузі представлені моделі IBMInformationFrameWork (IFW)і IBMTelecommunicationsDataWarehouse (TDW). Вони допомагають суттєво прискорити процес створення аналітичних систем, а також знизити ризики, пов'язані з розробкою додатків бізнес-аналізу, управління корпоративними даними та організацією сховищ даних з урахуванням специфіки телекомунікаційної галузі. Можливості IBM TDW охоплюють весь спектр ринку телекомунікаційних послуг - від інтернет-провайдерів та операторів кабельних мереж, що пропонують послуги дротової та бездротової телефонії, передачі даних та мультимедійного контенту, до транснаціональних компаній, що надають послуги телефонного, супутникового, міжміського та міжнародного зв'язку, а також організації глобальних мереж. На сьогоднішній день TDW використовується великими та дрібними постачальниками послуг провідного та бездротового зв'язку по всьому світу.

Інструмент під назвою InfoSphere Warehouse Pack для Customer Insightє структурованим і легко впроваджуваним бізнес-вмістом для все більшої кількості бізнес-проектів і галузей, серед яких банківська справа, страхування, фінанси, програми медичного страхування, телекомунікації, роздрібна торгівля та дистрибуція. Для бізнес-користувачів InfoSphere Warehouse Pack for Market and Campaign Insightдопомагає максимально підвищити ефективність заходів щодо аналізу ринку та маркетингових кампаній завдяки покроковому процесу розробки та обліку специфіки бізнесу. За допомогою InfoSphere Warehouse Pack for Supply Chain Insightорганізації мають можливість отримувати поточну інформацію щодо операцій ланцюжків поставок.

Позиція Esri всередині архітектури рішень IBM.

На особливу увагу заслуговує підхід IBM для електроенергетичних компаній і підприємств ЖКГ. Для того, щоб задовольнити зростаючі запити споживачів, енергопостачальним підприємствам необхідна більш гнучка архітектура порівняно з сьогоднішньою, а також стандартна галузева об'єктна модель, що спростить вільний обмін інформацією. Це підвищить комунікативні можливості енергетичних компаній, забезпечуючи взаємодію у більш економічному режимі, та надасть новим системам кращої видимості всіх необхідних ресурсів незалежно від того, де вони знаходяться в межах організації. Базою для такого підходу є СОА (сервіс-орієнтована архітектура), компонентна модель, що встановлює відповідність між функціями підрозділів та сервісами різних додатків, які можна багаторазово використовувати. «Служби» таких компонентів обмінюються даними за допомогою інтерфейсів без жорсткої прив'язки, приховуючи від користувача всю складність систем, що стоять за ними. У такому режимі підприємства можуть легко додавати нові програми незалежно від постачальника програмного забезпечення, операційної системи, мови програмування або інших внутрішніх характеристик програмного забезпечення. На основі СОА реалізується концепція SAFE ( Solution Architecture for Energy), вона дозволяє компанії електроенергетичної галузі отримати засноване на стандартах цілісне уявлення своєї інфраструктури.

Esri ArcGIS® - визнана у всьому світі програмна платформа для геоінформаційних систем (ГІС), що забезпечує створення та керування цифровими активами електроенергетичних, газотранспортних, розподільчих, а також телекомунікаційних мереж. ArcGIS дозволяє провести найповнішу інвентаризацію компонентів електричної розподільної мережі з урахуванням їхнього просторового розташування. ArcGIS істотно розширює архітектуру IBM SAFE, надаючи інструменти, програми, робочі процеси, аналітику та інформаційно-інтеграційні можливості, необхідні для управління інтелектуальним енергопідприємством. ArcGIS в рамках IBM SAFE дозволяє отримувати з різних джерел інформацію про об'єкти інфраструктури, активи, клієнтів та співробітників з точними даними про їх місцезнаходження, а також створювати, зберігати та обробляти геоприв'язану інформацію про активи підприємства (опори, трубопроводи, проводи, трансформатори, кабельна каналізація) і т.д.). ArcGIS всередині інфраструктури SAFE дозволяє динамічно об'єднати основні бізнес-додатки, комбінуючи дані з ГІС, SCADA та систем обслуговування клієнтів із зовнішньою інформацією, наприклад про інтенсивність трафіку, погодні умови або супутникові знімки. Енергопідприємства використовують таку комбіновану інформацію для різних цілей від С.О.Р. (загальної картини оперативної обстановки) до інспектування об'єктів, технічне обслуговування, аналізу та планування мереж.

Інформаційні компоненти енергопостачального підприємства можна змоделювати за допомогою кількох рівнів, які ранжуються від найнижчого – фізичного – до верхнього, найбільш складного рівня логіки бізнес-процесів. Ці рівні можна інтегрувати, щоб забезпечити відповідність типовим галузевим вимогам, наприклад, під час автоматизованої реєстрації вимірювань та керування системою диспетчерського контролю та збору даних (SCADA). Вибудовуючи архітектуру SAFE, енергопостачальні компанії роблять значні кроки у просуванні загальногалузевої відкритої об'єктної моделі під назвою «Загальна інформаційна модель для енергетичних компаній» (Common Information Model (CIM) for Energy and Utilities). Ця модель забезпечує необхідну базу для просування багатьох підприємств до сервіс-орієнтованої архітектури, оскільки вона заохочує використання відкритих стандартів для структуризації даних та об'єктів. За рахунок того, що всі системи використовують ті самі об'єкти, плутанина і нееластичність, пов'язані з різними реалізаціями однакових об'єктів, будуть скорочені до мінімуму. Таким чином, визначення об'єкта «клієнт» та інших важливих бізнес-об'єктів буде уніфіковано у всіх системах енергопостачального підприємства. Тепер за допомогою CIM постачальники та споживачі послуг можуть використовувати загальну структуру даних, полегшуючи виведення дорогих компонентів бізнесу на аутсорсинг, оскільки CIM встановлює загальну базу, де можна побудувати обмін інформацією.

Висновок

Комплексні галузеві моделі даних забезпечують компаніям єдине інтегроване представлення їхньої бізнес-інформації. Багатьом компаніям буває непросто здійснити інтеграцію своїх даних, хоча це є необхідною умовою більшості загальнокорпоративних проектів. За даними дослідження Інституту Сховищ даних (The Data Warehousing Institute, TDWI), понад 69% опитаних організацій виявили, що інтеграція є суттєвим бар'єром для впровадження нових додатків. Навпаки, здійснення інтеграції даних приносить компанії відчутний прибуток і зростання ефективності.

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