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

«Казка брехня - так у ній натяк ...»

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

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

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

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

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

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

1. В принципі, у нас непогане сховище: якщо не чіпати - то все працює. Правда, як тільки потрібно внести зміну - починаються «локальні обвали».
2. Дані завантажуються щодня, за регламентом, в рамках одного великого процесу, протягом 8год. І нас це влаштовує. Але якщо раптом виникає збій - це вимагає ручного втручання. І далі все може працювати непередбачувано довго, тому що будуть потрібні участь людини в процесі.
3. Накотили реліз - чекай проблем.
4. Якийсь один джерело не змогло вчасно віддати дані - чекають всі процеси.
5. Цілісність даних контролює база даних - тому наші процеси падають з помилкою, коли вона порушується.
6. У нас дуже велике сховище - 2000 таблиць в одній загальній схемі. І ще 3000 в безлічі інших схем. Ми вже слабо уявляємо, як вони влаштовані і з якого приводу з'явилися. Тому, нам буває складно щось перевикористати. І доводиться багато завдань вирішувати заново. Оскільки, так простіше і швидше (ніж розбиратися «в чужому коді»). У підсумку маємо розбіжності і дублюється функціонал.
7. Ми очікуємо, що джерело буде давати якісні дані. Але виявляється, що це не так. У підсумку ми багато часу витрачаємо на вивірку своїх фінальних звітів. І дуже в цьому досягли успіху. У нас навіть є налагоджений процес. Правда, це займає час. Але користувачі звикли ...
8. Користувач не завжди довіряє нашим звітам і вимагає обґрунтування тієї чи іншої цифри. У якихось випадках він має рацію, а в якихось немає. Але нам дуже складно їх обґрунтовувати, тому що у нас не передбачено коштів «наскрізного аналізу» (або data lineage).
9. Ми могли б залучити додаткових розробників. Але у нас проблема - як нам включити їх в роботу? Як найефективніше распараллелить роботи?
10. Як розвивати систему поступово, не йдучи в розробку «ядра системи» на цілий рік?
11. Сховище даних асоціюється з корпоративної моделлю. Але ми точно знаємо (бачили в банку XYZ), що будувати модель можна нескінченно довго (в банку XYZ шість місяців ходили і обговорювали бізнес-суті, без будь-якого руху). А навіщо вона взагалі? Або може, краще без неї, якщо з нею стільки проблем? Може, її взагалі якось згенерувати?
12. Ми вирішили вести модель. Але як системно розвивати модель даних сховища? Чи потрібні нам «правила гри» і які вони можуть бути? Що нам це дасть? А що, якщо ми помилимося з моделлю?
13. Чи повинні ми зберігати дані, або історію їх змін, якщо «бізнесу вони не потрібні»? Не хотілося б «зберігати сміття» і ускладнювати використання цих даних для реальних завдань. Чи повинно сховище збережуть історію? Яка вона буває? Як сховище працює з часом?
14. Чи потрібно намагатися уніфікувати дані на сховищі, якщо у нас є система управління НДІ? Якщо є МДМ, чи означає це, що тепер вся проблема з майстер-даними вирішена?
15. У нас скоро очікується заміна ключових облікових систем. Чи повинно сховище даних бути готовим до зміни джерела? Як цього досягти?
16. Чи потрібні нам метадані? Що під цим будемо розуміти? Де саме вони можуть бути використані? Як можна реалізувати? Чи потрібно їх зберігати «в одному місці»?
17. Наші Замовники вкрай нестабільні у своїх вимогах і бажаннях - постійно щось змінюється. У нас взагалі бізнес- дуже динамічний. Поки ми щось робимо - це вже стає непотрібним. Як нам зробити так, щоб видавати результат максимально швидко - як гарячі пиріжки?
18. Користувачі вимагають оперативності. Але ми не можемо наші основні процеси завантаження запускати часто, тому що це навантажує системи-джерела (погано позначається на продуктивності) - тому, ми вішаємо додаткові потоки даних - які забиратимуть точково - то, що нам потрібно. Правда, виходить багато потоків. І частина даних ми потім викинемо. До того ж буде проблема збіжності. Але по-іншому ніяк ...

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

Антіхрупкость

Дивлячись на наш список, можна зробити один висновок. Чи не складно створити якусь «базу даних для звітності», накидати туди даних або навіть побудувати якісь регламентні процеси відновлення даних. Система починає якось жити, з'являються користувачі, а з ними зобов'язання і 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" - так називають сховища даних. По частині роботи з часом в сховищах все дуже цікаво. В облікових системах дані актуальні в моменті. Потім користувач робить якусь операцію - і дані оновлюються. При цьому історія змін може і не зберегтися - це залежить від практики обліку. Візьмемо, наприклад, залишок на банківському рахунку. Нас може цікавити актуальний залишок на «зараз», на кінець дня або на момент нікого події (наприклад, в момент розрахунку скорингового бала). Якщо перші два вирішуються досить просто, то для останнього, швидше за все, буде потрібно спеціальні зусилля. Користувач, працюючи зі сховищем, може звертатися до минулих періодів, здійснювати їх порівняння з поточним і т.д. Саме подібні можливості, пов'язані з часом, істотно відрізняють сховища даних від систем обліку - отримання стану даних в різних точках осі часу - на певну глибину в минулому.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ядро системи

Почнемо «з середини» - ядро \u200b\u200bсистеми або середній шар. На позначений як 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.

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

Епілог

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

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

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

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

Зайцев С.Л., к.ф.-м.н.

повторювані групи

Повторюваними групами є атрибути, для яких єдиний екземпляр сутності може мати більше одного значення. Наприклад, персона може мати більше одного навику. Якщо, з точки зору вимог бізнесу, нам потрібно знати рівень володіння навичкою для кожного, і кожна персона може мати тільки два навички, ми можемо створити сутність, показану на рис. 1.6. Тут представлена \u200b\u200bсутність ПЕРСОНАз двома атрибутами для зберігання навичок і рівня володіння навичками для кожного.

Мал. 1.6. В даному прикладі використовуються повторювані групи.

Проблема повторюваних груп полягає в тому, що ми не можемо точно знати, скільки навичок може мати персона. У реальному житті у деяких людей є один навик, у деяких - кілька, а у деяких - поки жодного. На малюнку 1.7 представлена \u200b\u200bмодель, наведена до першої нормальної формі. Зверніть увагу на доданий ідентифікатор навички , Який унікально визначає кожен НАВИЧКА.

Мал. 1.7. Модель, приведена до першої нормальної формі.

Один факт в одному місці

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

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

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

На малюнку 1.8 представлена \u200b\u200bмодель в другій нормальній формі. Зауважте, що додана сутність НАВИЧКА, І атрибут НАЗВАнавички перенесений в цю сутність. Рівень навички залишився, відповідно, на перетині ПЕРСОНИ і ДОСВІДУ.

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

Кожен атрибут залежить від ключа

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

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

Відносини багато-до-багатьох

відносини багато-до-багатьохвідображають реальність навколишнього світу. Зверніть увагу, що на малюнку 1.9 існує відношення багато-до-багатьох між ПЕРСОНОЮі ШКОЛОЮ. Ставлення точно відображає той факт, що ПЕРСОНАможе вчитися в багатьох ШКОЛАХі в ШКОЛІможе вчитися багато ПЕРСОН.Для досягнення четвертої нормальної форми створюється асоціативна сутність, яка усуває ставлення моногом-ко-многим за рахунок формування окремого запису для кожної унікальної комбінації школи і персони. На малюнку 1.10 представлена \u200b\u200bмодель в четвертій нормальній формі.

Мал. 1.10. У четвертій нормальній формі відношення моногом-ко-многим між ПЕРСОНОЮ і ШКОЛОЮдозволяється за рахунок введення асоціативної суті, в якій відводиться окрема запис для кожної унікальної комбінації ШКОЛИ і ПЕРСОНИ.

Формальні визначення нормальних форм

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

У заданому відношенні R атрибут Y функціонально залежить від атрибуту X. В символьному вигляді RX -\u003e RY (читається як "RX функціонально визначає RY") - в тому і тільки в тому випадку якщо кожне значення X в R асоціюється строго з одним значенням Y в R (в кожен конкретний момент часу). Атрибути X і Y можуть бути складовими (Дейт К. Дж. Введення в системи баз даних. 6-е видання. Изд. Вільямс: 1999, 848 с.).

Відношення R відповідає першій нормальній формі (1NF) тоді і тільки тоді, коли всі належні йому домени містять тільки атомарні значення (Дейт, там же).

Відношення R відповідає другій нормальній формі (2NF) тоді і тільки тоді, коли воно відповідає 1NF, і кожен неключових атрибут повністю залежить від первинного ключа (Дейт, там же).

Відношення R відповідає третій нормальній формі (3NF) тоді і тільки тоді, коли воно відповідає 2NF, і кожен неключових атрибут не транзитивній залежить від первинного ключа (Дейт, там же).

Відношення R відповідає нормальній формі Бойса-Кодда (BCNF) тоді і тільки тоді, коли кожен детермінант є кандидатом на використання в якості ключа.

ПРИМІТКА Нижче наводиться короткий пояснення деяких абревіатур, використовуваних в визначеннях Дейта.

MVD (multi-valued dependency) - багатозначна залежність. Використовується тільки для сутностей з трьома і більше атрибутами. При багатозначною залежності значення атрибута залежить тільки від частини первинного ключа.

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

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

Ставлення відповідає четвертій нормальній формі (4NF) тоді і тільки тоді, коли в R існує MVD, наприклад A®®B. При цьому всі атрибути R функціонально залежать від A. Іншими словами, в R присутні тільки залежно (FD або MVD) форми K®X (тобто функціональна залежність атрибута X від кандидата на використання в якості ключа K). Відповідно R відповідає вимогам 4NF, якщо воно відповідає BCNF і все MVD фактично є FD (Дейт, там же).

Для п'ятої нормальної форми відношення R задовольняє залежності по об'єднанню (JD) * (X, Y, ..., Z) тоді і тільки тоді, коли R еквівалентно його проекція на X, Y, ..., Z, де X, Y ,. .., Z підмножини безлічі атрибутів R.

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

Бізнес-нормальні форми

У своїй книзі Клайв Фінклештейн (Finklestein Cl. An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) застосував інший підхід до нормалізації. Він визначає бізнес-нормальні форми в термінах приведення до цих форм. Багато розробники моделей, вважають цей підхід інтуїтивно більш ясним і прагматичним.

Перша бізнес-нормальна форма (1BNF) виносить повторювані групи в іншу сутність. Ця сутність отримує власне ім'я і первинні (складові) ключові атрибути з вихідної сутності та її повторюваної групи.

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

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

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

П'ята бізнес-нормальна форма (5BNF) проявляється як структурна сутність, якщо є рекурсивна або інша залежність між екземплярами вторинної суті, або якщо рекурсивна залежність існує між екземплярами її первинної сутності.

Завершена логічна модель даних

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

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

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

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

ПРИМІТКА множинність зв'язку описує максимальне число примірників вторинної суті, які можуть бути пов'язані з екземпляром вихідної сутності.необхідність існування абоможливість відсутності зв'язку служить для визначення мінімального числа примірників вторинної суті, які можуть бути пов'язані з екземпляром вихідної сутності.

Фізична модель даних

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

У ERwin фізична модель є графічним представленням реально реалізованої бази даних. Фізична база даних буде складатися з таблиць, стовпців і зв'язків. Фізична модель залежить від платформи, обраної для реалізації, і вимог до використання даних. Фізична модель для IMS буде серйозно відрізнятися від такої ж моделі для Sybase. Фізична модель для OLAP-звітів буде виглядати інакше, ніж модель для OLTP (оперативної обробки транзакцій).

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

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

Збір вимог до використання даних

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

Вимоги до доступу і продуктивності

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

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

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

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

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

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

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

Компоненти фізичної моделі даних

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

зворотне проектування

Коли логічна модель недоступна, виникає необхідність відтворення моделі з існуючої бази даних. У ERwin цей процес називається зворотним проектуванням. Зворотне проектування може здійснюватися кількома способами. Розробник моделі може досліджувати структури даних в базі даних і відтворити таблиці у візуальному середовищі моделювання. Ви можете імпортувати мову опису даних (DDL - data definitions language) в інструмент, який підтримує проведення зворотного проектування (наприклад, Erwin). Розвинені засоби, такі як ERwin, включають функції, що забезпечують зв'язок через ODBC з існуючою базою даних, для створення моделі шляхом прямого читання структур даних. Зворотне проектування з використанням ERwin буде детально обговорюватися в одній з наступних публікацій.

Використання корпоративних функціональних кордонів

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

ПРИМІТКА Деякі з моїх колег називають ці корпоративні функціональні межі моделюванням реального світу. Моделювання реального світу спонукає розробника моделі розглядати інформацію в термінах реально властивих їй відносин і взаємозв'язків.

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

Що таке корпоративна модель даних?

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

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

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

Побудова корпоративної моделі даних шляхом нарощування

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

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

Поняття методології моделювання

Існує кілька методологій візуального моделювання даних. ERwin підтримує дві:

IDEF1X (Integration Definition for Information Modeling - інтегроване опис інформаційних моделей).

IE (Information Engineering - інформаційна інженерія).

IDEF1X - хороша методологія і використання її нотації широко поширене

Інтегроване опис інформаційних моделей

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

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

інформаційний інжиніринг

Клайва Фінклештейна часто називають батьком інформаційного інжинірингу, хоча подібні ж концепції викладав разом з ним і Джеймс Мартін (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Інформаційний інжиніринг використовує для управління інформацією підхід, що направляється бізнесом, і застосовує іншу нотацію для представлення бізнес-правил. IE служить розширенням і розвитком нотації і базових концепцій методології ER, запропонованої Пітером Ченом.

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

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

висновок

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

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

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

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

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

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

ПРИМІТКА множинність зв'язку описує максимальне число примірників вторинної суті, які можуть бути пов'язані з екземпляром вихідної сутності.Необхідність існування або можливість відсутності зв'язку служить для визначення мінімального числа примірників вторинної суті, які можуть бути пов'язані з екземпляром вихідної

Все частіше 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. Усі пропоновані моделі даних документовані і готові до використання в IT-процесах підприємства. Супровідні матеріали до моделей включають:

• 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 for 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 не тільки володіють великим досвідом моделювання, але і добре розбираються в побудові моделей для певної галузі.

архітектура БД

Схема КМД - це опис структури моделі даних з точки зору адміністратора.

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

Схема КМД описує структуру даних, записів і полів.

Всі СУБД підтримують три основних види моделей даних:

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

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

2. Мережева модель. Дозволяє правильно відобразити всі складнощі взаємозв'язків.

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

3. Реляційна модель. В основі лежить математичний термін Relation - відношення, а просто - таблиця. Наприклад, прямокутна двомірна.

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

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

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

ставлення - це двовимірна таблиця особливого виду, що складається з заголовка і тіла.

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

Кожен з атрибутів визначено на своєму домені. Домен є тип даних «цілий», а логічне умова - n\u003e 0. Тема є незмінним в часі, на відміну від тіла відносини. тіло відносини - це сукупність кортежів, Кожен з яких представляє собою пару «атрибут - значення».

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

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

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

відношення - таблиця;

атрибут - колонка або поле;

кортеж - запис або рядок.

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

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

Ключ повинен відповідати таким вимогам:

· Повинен бути унікальним;

· Повинен бути мінімальним, тобто видалення будь-якого атрибута з ключа веде до порушення унікальності.

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

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

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

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

· Структурної;

· Маніпуляційної;

· Цілісною.

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

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

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

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

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

1. Стандартні операції: - перетин, - об'єднання, \\ - різниця, X - декартовій твір.

2. Специфічні: проекція, обмеження, з'єднання, розподіл.

a. Об'єднання.

ШД ШМ ОІ НР

R 1 (шифр деталі, шифр матеріалу, одиниці виміру, норма витрати)

R 2 (ШД, ШМ, ОІ, НР)

необхідно знайти

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

b. Перетин.

Виділення співпадаючих рядків.

c. Різниця.

Виняток з R 1 кортежів, які збігаються з R 2.

d. Декартово твір.

Тут проводиться конкатенація кортежів.

Кожен рядок одного безлічі конкатенуються з кожним рядком іншого.

Дано дві множини:

Декартово твір має наступний вигляд:

У цьому випадку S-ступінь дорівнює, а, тобто вийде 12 рядків і 5 стовпців.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.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 (відкотити транзакцію).
• Сталося від'єднання користувача від СУБД.
• Стався збій системи.

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

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

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

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

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

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

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

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

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

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

• Технологія клієнт / сервер дозволяє робити обчислення на неоднорідних обчислювальних середовищах. Незалежність від платформ: доступ до різнорідним мережевим середах, до складу яких входять комп'ютери різних типів з різними операційними системами.
• Незалежність від джерел даних: доступ до інформації різнорідних баз даних. Приклади таких систем - DB2, SQL / DS, Oracle, Sybase.
• Баланс завантаження клієнта і сервера.
• {!LANG-ab8586026aa0da6bdb7d886ea732a4af!}
• {!LANG-f03752b8b224a2c47965554c76a95fb3!}
• {!LANG-b0dc6224c64b63987a8998aff0241150!}{!LANG-939354d7dc2f23054e09100e63f8faf1!}
• {!LANG-d696387a04f4cfd16b282c9395b38b5a!}
• {!LANG-af96fd2f4c0415bff97f8bb474e671db!}
• {!LANG-480f2a66d373006962b801f1959838af!}
• {!LANG-93cc6a6ed4450b14ac4387653bab3fee!}
• {!LANG-4635c5f137eb67f11e0e02da8dec2bd0!}

 {!LANG-88a02794448510d3b69e1c3c9a5694ed!}

 {!LANG-06919794a6b4d6c3d184a765c261cc41!}

• {!LANG-6e52285b7ad6a4c194c340e136c6f77f!}

 {!LANG-d87eba68978d066be983a28bb98b1c56!}

 {!LANG-744c86dd773e7dc9bf302e3ef26bf4d1!}

 {!LANG-294f8c580e4b9efad9658c81db289b95!}

• {!LANG-1c8377ea4592463ad37fdc196d098e21!}
• {!LANG-b27c6f4844bb676516f700b00fca87ba!}
• {!LANG-aa0996fa3fb43a9a7b9e726c525bfc89!}
• {!LANG-02f1cf378c35abdeda05917561d24017!}

{!LANG-d7c911920c4f970f53a8940ea11e23cc!}

{!LANG-db7e80c3db68f647c12d46b6ca840431!}

{!LANG-2f4ac88f1c20b6566544a4f2a52efdba!}

{!LANG-d6bc25c9e3d6e12906997095afe461dd!}

• {!LANG-5fa77e1d43b74d8bf9fa956ae8be8806!}
• {!LANG-a3d054ff80b21c383f0afa2f18abf394!}
• {!LANG-c578f360f708b37695b95f32729e7597!}
• {!LANG-4a3e2e38a0c38629672a8e6338fb3ff9!}
• {!LANG-17351d797da379a91d3febd62875b291!}

{!LANG-94704186d7b3cf12a35a41d57ff3f891!} {!LANG-69fd9d38b737ce46456c01eb748a309c!}{!LANG-6ee5f75b61c11acebbc1007af5dd0a94!} {!LANG-35cb20c214861c3b8d82c0b61cad4038!}{!LANG-5efa902df4499e745ad9aa30d606fbaf!} {!LANG-89f77ef99b83e54353ddd45bb0777cba!}IBM {!LANG-5a780caeeddfa079fb1ac762c3d17a27!}{!LANG-23f4adfa98d3ac183320b8018f27a137!} {!LANG-5dbbb94afdcfe82b65050eb41f6d6871!}{!LANG-5efa902df4499e745ad9aa30d606fbaf!} {!LANG-be03f2a46cc28ae2d9306e55be919257!}{!LANG-b98800d0078b52500dc6d2138ff93b18!} {!LANG-a7d5450c6b380232cf68f95a2029f009!}{!LANG-5efa902df4499e745ad9aa30d606fbaf!} {!LANG-b8b521bc4d0ba02428936ca2ea7afd3b!}{!LANG-5efa902df4499e745ad9aa30d606fbaf!} {!LANG-8c0e99dff1edaffb09b4fcfe7c3449dd!}

{!LANG-afa02d78c7dc6b955d29442046b1169f!}

{!LANG-229860f83b2a2e998474f0f344705a1b!}

{!LANG-c2d32f223a741de90e61f7f2395d03dd!}

• {!LANG-dbc7f8d4b9534984fc5eae1c22c39130!}
• {!LANG-baf9fe16dc2c1237d969ff83ac342664!}
• {!LANG-1010603a3f729b270526b8515adc3fcb!}
• {!LANG-daa5fb259cf93cf7d428c1a9f64090fe!}
• {!LANG-ec0d281ec52d710f3928969ea8668f46!}

{!LANG-bc15032c98b0015d9f7ada582bd46073!}

{!LANG-c13f2576144432dffe618d760429dce3!}

• {!LANG-f8d1d11d66c4e8688e80135175049f3b!}{!LANG-1fa58f3cede28d8229af13a1ee8e7366!}
• {!LANG-ec4023295b6dffbcc59d6043b9fc64f9!}{!LANG-508fe17283d1d7de05b3f3331c03e320!}
• {!LANG-a3bc6f9f0fe8990487dc70d3af5b4f75!}{!LANG-7aed2d8d8eaa8af666f922c01dbb022c!}
• {!LANG-8687b350f3364f8c5f4509ce6d4ce3da!} {!LANG-48509ce7b0f2e547eaea3227e0d389b1!}
• {!LANG-23874c19fba1acff1f6619f0e3829a99!} {!LANG-ad85e0cc6ebf5de30f3a303ab574a562!}

{!LANG-ff1bdf6fe2920ff7acb8cf30995d3044!}

• {!LANG-c0102fb0e1216d18cedbcd85c311d2ee!}
• {!LANG-000158e3e5a29d56f74af20421fe42fb!}
• {!LANG-f5e3b260e44980d7ba6df7df276e5335!}
• {!LANG-fb668aa6620a236549a5f6f443d364f0!}
• {!LANG-9adcabc9f0fa62a906c5615cd42d2f25!}

{!LANG-158b861146233a3b0ae05bcf458dd79d!} {!LANG-f597b9ccbebe1badc4aa8b6bbc62af31!}

{!LANG-5dbd45586db21e0e5f5618b5f3ac254b!}

{!LANG-0feacbd4e40a364677e9733dab001747!}

{!LANG-eddf4961bfb69bc503ba762edfb8f359!}

{!LANG-85f3070ce95211386beeeb47329cdbdd!}

{!LANG-e9ed4c58c30deecefa944ea8da503a5e!}
6914.		{!LANG-d077e7d010bb204111f7555bfe5afe7d!}	{!LANG-0851be393b0003d186cb164cf8fef734!}
	{!LANG-9bfa49e84cc550bac85a7ed871f8294f!}
8064.		{!LANG-fddf9b9565416acbbe0ac728517de976!}	{!LANG-f2a8badee2b307dc3409730f4d16dca1!}
	{!LANG-d4ea30b0fe75138334534eee9c748e7d!}
20319.		{!LANG-0ce12bb253a3a18610a16901853e622f!}	{!LANG-2cfc18a8c044c8a419821e3a7154d48f!}
	{!LANG-d64d1b98fb65c8f88cb7562e53aa51a7!}
5031.		{!LANG-b4c0a1c15394543ea9ead84aeb8957f8!}	{!LANG-602ef51ead414c3052262826618d8ca2!}
	{!LANG-9476eb574942a299b3c54404d3c19f63!}
13815.		{!LANG-1a3866b7b0fac7c7131a33a9177c5ec0!}	{!LANG-9a6eab91af3ccc7b24278f77f4f22bf1!}
	{!LANG-a2cfe887ec1b5013420bdf3e07ba0a87!}
14095.		{!LANG-2257814a7200c21c6a6adff0d553c97f!}	{!LANG-602ef51ead414c3052262826618d8ca2!}
	{!LANG-771fcb065dd21f8319bfa996da83150a!}
5061.		{!LANG-6ca9b484d2ede5519b65674b4152a1b9!}	{!LANG-530f3f5f798a83dc6c0ca52eee96e4c9!}
	{!LANG-57aa69d0357abce1c2f5a6445a7dacd4!}
13542.		{!LANG-f78b1e5e1d6e0e7f6ef8a71c01ab319d!}	{!LANG-02b5452e6d3a4ca3282db1b0d416893c!}
	{!LANG-24b4a6884248f33fc3bf3ea917e187ce!}
9100.		{!LANG-da400482e509fb4aa23fe097930b962b!}	{!LANG-33a8872611742be056edb5103f973f40!}
	{!LANG-9e6dc2bd9b065ece7daa41b7f69d8c55!}
5240.		{!LANG-bce39512d4f003f97046c7eb13647789!}	{!LANG-61fed3aaafd24343fb987df6119f9635!}
	{!LANG-c226e864bc61cda6f7a6d1be21d4735d!}

{!LANG-340a5fccadaf7318378c500176fd2cb7!}

{!LANG-b206c9b9823a397f9df19f1571726fc3!}

{!LANG-a7802024bac45056205f9a945a82a1ed!}

{!LANG-8eeb97c2187d8bccbc7e8118b86f0782!}

{!LANG-2552730e84a5ede14449c2d1269cf37d!} {!LANG-ce4301a7066682ec76895d0a0d59a900!}{!LANG-23098db53b5ad63ce8994419aa1be419!}

{!LANG-1c18e0c3c5e43b49d6033d0ba08363da!} {!LANG-9e159444221b8a8503bb523b8cfdc04a!}{!LANG-2fff1c50378e99adb30f6c1946f21396!}

{!LANG-f7025a39c08d4196f6eed4dfc68fc2c3!}

{!LANG-1910c6baf135649ec9b994922959f445!}

{!LANG-fe1058ba2fcd469ef516789072da6572!}

{!LANG-5b154e55ea85c8e5f7b1da0a5cb6fdd4!} {!LANG-073f09e46893633cad514ca0b2c35793!}{!LANG-3d247cda5ffc82d8f8e8745b98dc0be0!}

{!LANG-7e1587a85193d33725ddc86b30d990b9!}

{!LANG-238a7a7f3c1f3238a0d1056768ba8b6d!}

{!LANG-63c9713626ecdb5c97d0474d01841a74!}

{!LANG-3aff4736fc757e4bc68fe98bd2e043a9!}

{!LANG-32a28f14e4d76567f2e03b9be4472714!}

{!LANG-54cd22abe2866dd143609ab6faa9d63a!}

{!LANG-0b3e9f410671487124253e5533e668cd!}

{!LANG-0c5001853634b3ae7a65dc962f9ba920!}

{!LANG-29814fe474314520f8250929cb67a816!}

{!LANG-6b969f9ef23e2d285408eadf45fce8f5!}

{!LANG-a7a3b64beb2f118a2cfcc35c3f3c16df!}

{!LANG-882760825b721c29ca67007a2453448a!}

{!LANG-d7cdbc19021fb9eec893a7e147fed6bf!}

1. {!LANG-5e9596be651a70c2dfeb03bdd1712207!}
2. {!LANG-2f9f14a4878fefaf5efc75055a6a341c!}

Зайцев С.Л., к.ф.-м.н.

повторювані групи

Повторюваними групами є атрибути, для яких єдиний екземпляр сутності може мати більше одного значення. Наприклад, персона може мати більше одного навику. Якщо, з точки зору вимог бізнесу, нам потрібно знати рівень володіння навичкою для кожного, і кожна персона може мати тільки два навички, ми можемо створити сутність, показану на рис. 1.6. Тут представлена \u200b\u200bсутність ПЕРСОНАз двома атрибутами для зберігання навичок і рівня володіння навичками для кожного.

Мал. 1.6. В даному прикладі використовуються повторювані групи.

Проблема повторюваних груп полягає в тому, що ми не можемо точно знати, скільки навичок може мати персона. У реальному житті у деяких людей є один навик, у деяких - кілька, а у деяких - поки жодного. На малюнку 1.7 представлена \u200b\u200bмодель, наведена до першої нормальної формі. Зверніть увагу на доданий ідентифікатор навички , Який унікально визначає кожен НАВИЧКА.

Мал. 1.7. Модель, приведена до першої нормальної формі.

Один факт в одному місці

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

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

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

На малюнку 1.8 представлена \u200b\u200bмодель в другій нормальній формі. Зауважте, що додана сутність НАВИЧКА, І атрибут НАЗВАнавички перенесений в цю сутність. Рівень навички залишився, відповідно, на перетині ПЕРСОНИ і ДОСВІДУ.

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

Кожен атрибут залежить від ключа

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

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

Відносини багато-до-багатьох

відносини багато-до-багатьохвідображають реальність навколишнього світу. Зверніть увагу, що на малюнку 1.9 існує відношення багато-до-багатьох між ПЕРСОНОЮі ШКОЛОЮ. Ставлення точно відображає той факт, що ПЕРСОНАможе вчитися в багатьох ШКОЛАХі в ШКОЛІможе вчитися багато ПЕРСОН.Для досягнення четвертої нормальної форми створюється асоціативна сутність, яка усуває ставлення моногом-ко-многим за рахунок формування окремого запису для кожної унікальної комбінації школи і персони. На малюнку 1.10 представлена \u200b\u200bмодель в четвертій нормальній формі.

Мал. 1.10. У четвертій нормальній формі відношення моногом-ко-многим між ПЕРСОНОЮ і ШКОЛОЮдозволяється за рахунок введення асоціативної суті, в якій відводиться окрема запис для кожної унікальної комбінації ШКОЛИ і ПЕРСОНИ.

Формальні визначення нормальних форм

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

У заданому відношенні R атрибут Y функціонально залежить від атрибуту X. В символьному вигляді RX -\u003e RY (читається як "RX функціонально визначає RY") - в тому і тільки в тому випадку якщо кожне значення X в R асоціюється строго з одним значенням Y в R (в кожен конкретний момент часу). Атрибути X і Y можуть бути складовими (Дейт К. Дж. Введення в системи баз даних. 6-е видання. Изд. Вільямс: 1999, 848 с.).

Відношення R відповідає першій нормальній формі (1NF) тоді і тільки тоді, коли всі належні йому домени містять тільки атомарні значення (Дейт, там же).

Відношення R відповідає другій нормальній формі (2NF) тоді і тільки тоді, коли воно відповідає 1NF, і кожен неключових атрибут повністю залежить від первинного ключа (Дейт, там же).

Відношення R відповідає третій нормальній формі (3NF) тоді і тільки тоді, коли воно відповідає 2NF, і кожен неключових атрибут не транзитивній залежить від первинного ключа (Дейт, там же).

Відношення R відповідає нормальній формі Бойса-Кодда (BCNF) тоді і тільки тоді, коли кожен детермінант є кандидатом на використання в якості ключа.

ПРИМІТКА Нижче наводиться короткий пояснення деяких абревіатур, використовуваних в визначеннях Дейта.

MVD (multi-valued dependency) - багатозначна залежність. Використовується тільки для сутностей з трьома і більше атрибутами. При багатозначною залежності значення атрибута залежить тільки від частини первинного ключа.

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

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

Ставлення відповідає четвертій нормальній формі (4NF) тоді і тільки тоді, коли в R існує MVD, наприклад A®®B. При цьому всі атрибути R функціонально залежать від A. Іншими словами, в R присутні тільки залежно (FD або MVD) форми K®X (тобто функціональна залежність атрибута X від кандидата на використання в якості ключа K). Відповідно R відповідає вимогам 4NF, якщо воно відповідає BCNF і все MVD фактично є FD (Дейт, там же).

Для п'ятої нормальної форми відношення R задовольняє залежності по об'єднанню (JD) * (X, Y, ..., Z) тоді і тільки тоді, коли R еквівалентно його проекція на X, Y, ..., Z, де X, Y ,. .., Z підмножини безлічі атрибутів R.

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

Бізнес-нормальні форми

У своїй книзі Клайв Фінклештейн (Finklestein Cl. An Introduction to Information Engineering: From Strategic Planning to Information Systems. Reading, Massachusetts: Addison-Wesley, 1989) застосував інший підхід до нормалізації. Він визначає бізнес-нормальні форми в термінах приведення до цих форм. Багато розробники моделей, вважають цей підхід інтуїтивно більш ясним і прагматичним.

Перша бізнес-нормальна форма (1BNF) виносить повторювані групи в іншу сутність. Ця сутність отримує власне ім'я і первинні (складові) ключові атрибути з вихідної сутності та її повторюваної групи.

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

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

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

П'ята бізнес-нормальна форма (5BNF) проявляється як структурна сутність, якщо є рекурсивна або інша залежність між екземплярами вторинної суті, або якщо рекурсивна залежність існує між екземплярами її первинної сутності.

Завершена логічна модель даних

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

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

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

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

ПРИМІТКА множинність зв'язку описує максимальне число примірників вторинної суті, які можуть бути пов'язані з екземпляром вихідної сутності.необхідність існування абоможливість відсутності зв'язку служить для визначення мінімального числа примірників вторинної суті, які можуть бути пов'язані з екземпляром вихідної сутності.

Фізична модель даних

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

У ERwin фізична модель є графічним представленням реально реалізованої бази даних. Фізична база даних буде складатися з таблиць, стовпців і зв'язків. Фізична модель залежить від платформи, обраної для реалізації, і вимог до використання даних. Фізична модель для IMS буде серйозно відрізнятися від такої ж моделі для Sybase. Фізична модель для OLAP-звітів буде виглядати інакше, ніж модель для OLTP (оперативної обробки транзакцій).

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

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

Збір вимог до використання даних

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

Вимоги до доступу і продуктивності

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

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

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

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

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

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

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

Компоненти фізичної моделі даних

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

зворотне проектування

Коли логічна модель недоступна, виникає необхідність відтворення моделі з існуючої бази даних. У ERwin цей процес називається зворотним проектуванням. Зворотне проектування може здійснюватися кількома способами. Розробник моделі може досліджувати структури даних в базі даних і відтворити таблиці у візуальному середовищі моделювання. Ви можете імпортувати мову опису даних (DDL - data definitions language) в інструмент, який підтримує проведення зворотного проектування (наприклад, Erwin). Розвинені засоби, такі як ERwin, включають функції, що забезпечують зв'язок через ODBC з існуючою базою даних, для створення моделі шляхом прямого читання структур даних. Зворотне проектування з використанням ERwin буде детально обговорюватися в одній з наступних публікацій.

Використання корпоративних функціональних кордонів

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

ПРИМІТКА Деякі з моїх колег називають ці корпоративні функціональні межі моделюванням реального світу. Моделювання реального світу спонукає розробника моделі розглядати інформацію в термінах реально властивих їй відносин і взаємозв'язків.

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

Що таке корпоративна модель даних?

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

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

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

Побудова корпоративної моделі даних шляхом нарощування

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

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

Поняття методології моделювання

Існує кілька методологій візуального моделювання даних. ERwin підтримує дві:

IDEF1X (Integration Definition for Information Modeling - інтегроване опис інформаційних моделей).

IE (Information Engineering - інформаційна інженерія).

IDEF1X - хороша методологія і використання її нотації широко поширене

Інтегроване опис інформаційних моделей

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

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

інформаційний інжиніринг

Клайва Фінклештейна часто називають батьком інформаційного інжинірингу, хоча подібні ж концепції викладав разом з ним і Джеймс Мартін (Martin, James. Managing the Database Environment. Upper Saddle River, New Jersey: Prentice Hall, 1983.). Інформаційний інжиніринг використовує для управління інформацією підхід, що направляється бізнесом, і застосовує іншу нотацію для представлення бізнес-правил. IE служить розширенням і розвитком нотації і базових концепцій методології ER, запропонованої Пітером Ченом.

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

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

висновок

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

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

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

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

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

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

ПРИМІТКА множинність зв'язку описує максимальне число примірників вторинної суті, які можуть бути пов'язані з екземпляром вихідної сутності.Необхідність існування або можливість відсутності зв'язку служить для визначення мінімального числа примірників вторинної суті, які можуть бути пов'язані з екземпляром вихідної

{!LANG-3333e6b1e9331384b91ff9c440fa1f35!}

{!LANG-c39a297b6426c8a2ab9ebaee59a436dd!}

{!LANG-0681667aacee13ec64d5d0a616b48fe8!} {!LANG-f517578066bfc388290aa7857be71d10!}

• {!LANG-b0e28c9a5cd9b83ad6d4f760a83a5a36!}
• {!LANG-d991cfcb4f29359daae0616fdf51af53!}
• {!LANG-a378ecb07351536d6054069baef8be5d!}
• 2. {!LANG-872e7882066b3cab641486a441682f8f!}
• {!LANG-1ad5aa5905501c7c974d5ec6eb23bf1c!}

{!LANG-aa4b12fd6885ec083bc6c5f2479113bc!}

{!LANG-83466002822c888bc501186d14bf6da0!}

{!LANG-8ba1b8160aec9ecd34d81286649201c8!}

{!LANG-a4d6e6b0a4dfc5830f46bb5d9e6551ce!}

{!LANG-a3ebadea3aad7a911909db545ebaa6d9!}

{!LANG-da175a532f5fe0d3fddb4240338bf627!}

{!LANG-d9cd2a55fc54d80977fd11fe9fe55c6d!}

{!LANG-5e7d00d840a0215c92c4cf3bc9dd32b2!}

{!LANG-b6633fe362b34cca4a2e17fe58fdc66b!}

{!LANG-69b92cc7e081f61ada2251ceed96840b!}

{!LANG-49d04d5f4a5c833b053a3bb2ac470a13!}

{!LANG-6a90820b31ccd07d853db16c797a9f51!}

{!LANG-d22a1fe6bbbbfe05c4a1a96fe40b2dc3!}

{!LANG-972866f8c875bc35cbc67b6e7c1e8aa6!}

{!LANG-df17c9e0f2bcf0d9e71a28b1698f94ed!}

{!LANG-34604a3a93603ac848106782409d6667!}

{!LANG-fb3707efd09446e86377fdfb42c6a4cb!}

{!LANG-2f6c4470ad0c19aa32e4aa8d43163364!}

{!LANG-d40cdd8e39b1a70663da8ab33f207ea6!}

{!LANG-7ea928982eeff54ed19b7ad73c3810ff!}

{!LANG-8b23719b20ad87f64675c8d2a65e28a7!}

{!LANG-352fb6ec398aa7b78eeb25b57ee7e7a8!}

{!LANG-ef6844071ef234a2bfe51d0e7e6caa90!}

{!LANG-5d57281d042a86341e7e13e1f8b06f39!}

{!LANG-3bc00d570a947cbd23805f10b2947811!}

{!LANG-0fa2694bbc71f3175d4594a5e0088cb4!}

{!LANG-80bb1c0b2f89c02707b8610caeb3ff53!}

{!LANG-7403b3d6a00e19f2bf2e46200fb7ab86!}

{!LANG-374269e1292b0c9914a0a618c3111a30!}

{!LANG-f642331168861e5b250cc670018c8fa4!}

{!LANG-8beba4e5b513ab3eb61414e25afb07a2!}

{!LANG-8531b1c53ca98624a49a16bca3a097a6!}

{!LANG-c020ba5e0d8c56df6ab6ea77eb978582!}

{!LANG-05633c745865f6ea2003e982686225aa!}

{!LANG-eb5ea1d03e15dcce3760bca78446e11f!}

{!LANG-e328adc7a12f86825689745bc3f318f8!}

{!LANG-c5ac75001e3a7170a85e5ba6431a21c6!}

{!LANG-ed1f3d0ca6e14ed472b7ea9408a0a5d2!}

{!LANG-b90666afca938faaeb07a4a253c68bab!}

{!LANG-5e36c343df6a80063220a5aed11554d0!}

{!LANG-1f624bbdb7c2be529c5b8b4648fc7aae!}

{!LANG-344d938e71a755c385a2d79bc844391c!}

{!LANG-6e61d656c0d3b346214e6c06bf09ddaa!}

{!LANG-0532b993290df2d91ccfe1bfaabdd031!}

{!LANG-1e252e2adec40791114d00c71b18561c!}

{!LANG-9ca18aec32af3361ad96104a211a7c3e!}

{!LANG-d99b2cac0aa06a5959438682b791773f!}

{!LANG-340fcfc98ae8c4901df12a901adb97e7!}

{!LANG-5dc416bae208e6a2e9082f8f643a31f1!}

{!LANG-d2dd740712a8eeb58cbed342a39f37c9!}

{!LANG-68a1bcc0d7b3f3a9bd2b5cafee053673!}

{!LANG-fd5d3d6edf8afa8d9e5fc368eb6140b3!}

{!LANG-2c8c63736aaebe7bfe706b6537990dba!}

{!LANG-082245e0b16e3379c1fd79db3b509b92!}

{!LANG-d01ef7a71cecc6d4b4ca625bb183360e!}

{!LANG-74a92b8b994caa3e43d699a78f71ac6c!}

{!LANG-c1cba907837c27035f04853157663849!}

{!LANG-9e042c85ce082e810640a65c1e17b4f2!}

{!LANG-de86eaee0ab4364a28952b65a9386a12!}

{!LANG-508cc39de5e9b4443fd36b4193e0f647!}

{!LANG-9dc6a88870a04b836308fda6a2e678aa!}

{!LANG-febbdfebd5878d4afe1a84088e5d7f04!}

{!LANG-99d589b7085ba2e4a7b32645b82cedcf!}

{!LANG-79082e9d76c4e0d58c1f03c1e9b8ce90!}

{!LANG-f8b9dbd1c17199fb962cc7e055451cb8!}

{!LANG-811bcf5e132d028b869435eb4ef9fb90!}

{!LANG-79afb6a4ba30184eb7e1d9bee572092f!}

{!LANG-7f8420f3cb25a55f39830439997b8d39!}

{!LANG-eb0c6ecd0efd00209124d0f6cadae755!}

{!LANG-693709c12c34b5defa6f34a53209d6dc!}

{!LANG-c0a5a5fec26eb949ad0f7f22801ba3c1!}

{!LANG-e12a0cd276268f8b0addf9a94acb57b3!}

{!LANG-b9751d0c8b39851642df48339e030187!}

{!LANG-3078450320dd615101afc40f0a82ccd4!}

{!LANG-bafc2d30dce595b9f46f9d6485e2f8a1!}

{!LANG-ae4abe9c1498a53feb05413230f16626!}

{!LANG-a8b80e630a220093702e736bf16aba20!}

{!LANG-32f861f1b35e7b556492148235f3cffa!}

{!LANG-7e2e799205c172d320338f7fdfebee97!}

{!LANG-41b166837d8381c710b52f1ff7bbab8f!}

{!LANG-e4589413a8a7be043b56925a5fed83b1!}

...

{!LANG-2315defc5e8fbf7be03badaab0f522f9!}

{!LANG-e84afb0b8365829a33003ab3023b6aba!}

{!LANG-2bde2f4b07cb26c0c0783e3af2337a9b!}


{!LANG-b3bcfbdbdba6ecc21f55da6b0d3501e0!}

{!LANG-eb7a98640658aef9110e17ed40f430fd!}


{!LANG-41ca2bf1f6fb6a835e1d0b293755e3a3!}

{!LANG-481f3c2f16b860f12fdfa44f70142cb3!}


{!LANG-5ce989c9b48ed31fe04bc3994fc9d917!}

{!LANG-85905362a0165ae373a19f01ef88bcc9!}


{!LANG-9c5c59e48f5ff266a0d5d99b71e43414!}

{!LANG-9842baed3d31dd7b1bdb90356bf14a12!}


{!LANG-ae54a333df78f8040a68420c92fe78e4!}

{!LANG-199faeb261997ea9f2aa3187d3457647!}


{!LANG-af6ff049a5ecf49af92dc6138b89c004!}

{!LANG-b9666305e264ad9c0f6cec0c4344f2ad!}


{!LANG-63f83efbb26b63f310040474f016417d!}

{!LANG-06390cda217927a1a71195ae736c98d8!}


{!LANG-e34592f3258248039d8d15f4484f7610!}

{!LANG-591a1ee818b97a14e4ab2879975443c0!}


{!LANG-8c40e64b1ec72067abf6def4d8265ab8!}

Все частіше 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. Усі пропоновані моделі даних документовані і готові до використання в IT-процесах підприємства. Супровідні матеріали до моделей включають:

• 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 for 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 не тільки володіють великим досвідом моделювання, але і добре розбираються в побудові моделей для певної галузі.