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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У заданому відношенні R атрибут Y функціонально залежить від атрибуту X. У символьному вигляді R.X -> R.Y (читається як "R.X функціонально визначає R.Y") - в тому і тільки в тому випадку, якщо кожне значення 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Корпоративна модель даних (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. New Jersey: Prentice Hall, 1983.). Інформаційний інжиніринг використовує керувати інформацією підхід, спрямований бізнесом, і застосовує іншу нотацію для представлення бізнес-правил. IE служить розширенням та розвитком нотації та базових концепцій методології ER, запропонованої Пітером Ченом.

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

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

Висновок

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

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

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

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

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

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

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

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

Епілог

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

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

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

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

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

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

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

Технології,

Продукти,

Програми.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

· Поширення.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недоліки:

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

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

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

Переваги:

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

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

Недоліки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Переваги:

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

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

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

Недоліки:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Публікації

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ціль лекції

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

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

і навчіться:

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

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

Вступ

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

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

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

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

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

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

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

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

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

Таким чином, корпоративна модель данихінші моделі. корпоративної моделі даних.

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

16.1 зображено основні елементи

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

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

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

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

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

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

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

моделлю даних організації корпоративної моделі даних(Enterprise data model). З точки зору проектування ХД важливим фактором у прийнятті рішення створення моделі ХД корпоративної моделі даних.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Висновок

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

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

Ціль лекції

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

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

і навчіться:

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

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

Вступ

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

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

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

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

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

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

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

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

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

Таким чином, корпоративна модель данихпідтипів та супертипів; корпоративної моделі даних.

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

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

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

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

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

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

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

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

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

моделлю даних організації корпоративної моделі даних(Enterprise data model). З точки зору проектування ХД важливим фактором у прийнятті рішення створення моделі ХД корпоративної моделі даних.

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

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

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

16.3 видно, що предметна область "Замовлення" (

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

) та замовлення з роздрібної торгівлі ( (Enterprise data model).

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

1. Реляційна модель даних

1.1. Реляційна модель даних. Основні визначення

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

Основні поняття:

* Відношення є двовимірною таблицею, що містить деякі дані.

* Сутність - об'єкт будь-якої природи, дані про який зберігаються у БД. Атрибути – властивості, що характеризують сутність (стовпці).

* Ступінь відношення - кількість стовпців.

* Схема відношення - список імен атрибутів, наприклад, СПІВРОБІТНИК (№, ПІБ, Рік народження, Посада, Кафедра).

* Домен - сукупність значень атрибутів відношення (тип даних).

* Кортеж - рядок таблиці.

* Кардинальність (потужність) – кількість рядків у таблиці.

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

* Зовнішній ключ - це атрибут (атрибути) однієї таблиці, який може бути первинним ключем іншої таблиці. Є посиланням на первинний ключ іншої таблиці.

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

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

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

1.2 Операції над відносинами

Щоб привести таблицю до першої нормальної форми (1НФ), потрібно дотриматися двох правил:

1. Атомарність чи неподільність. Кожна колонка повинна мати одне неподільне значення.

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

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

Починати нормалізацію слід з перевірки структури БД на сумісність із 1НФ. Усі стовпці, які є атомарними, мають бути розбиті на складові їх стовпці. Якщо в таблиці є стовпці, що повторюються, то їм потрібно виділити окрему таблицю.

Щоб привести таблицю до першої нормальної форми, слід:

* Знайти всі поля, які містять багатоскладові частини інформації.

* Ті дані, які можна розбити на складові, потрібно виносити в окремі поля.

* Винести повторювані дані в окрему таблицю.

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

Для приведення таблиць до другої нормальної форми (2НФ), таблиці повинні бути вже в 1НФ. Нормалізація має відбуватися по порядку.

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

Щоб привести базу до другої нормальної форми, треба:

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

* Створити необхідні поля в таблицях users і forums, виділити з існуючих полів або створити нові первинні ключі.

* Для кожної таблиці потрібен свій первинний ключ

* Створити зовнішні ключі та позначаємо їх відносини між таблицями. Кінцевим кроком нормалізації до 2НФ буде виділення зовнішніх ключів зв'язку з асоційованими таблицями. Первинний ключ однієї таблиці має бути зовнішнім ключем до іншої.

Підказки:

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

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

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

Щоб привести базу до третьої нормальної форми, треба:

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

* Створити відповідні таблиці. Якщо є проблемний стовпець у кроці 1, створити окремі таблиці для нього.

* Створити чи виділити первинні ключі. Кожна таблиця повинна мати первинний ключ.

* Створити необхідні зовнішні ключі, які утворюють будь-яке із відносин.

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

2. Корпоративні інформаційні системи

реляційна модель дана система

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

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

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

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

4. Архітектура системи - сукупність властивостей системи, суттєвих для користувача.

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

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

У Федеральному законі «Про інформацію, інформатизації та захист інформації» дається таке визначення:

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

Класифікація за масштабом

За масштабом інформаційні системи поділяються на такі групи:

* Поодинокі;

* групові;

* Корпоративні.

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

Корпоративною інформаційною системою може вважатися система, що автоматизує понад 80% підрозділів підприємства.

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

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

Корпоративні інформаційні системи є розвитком систем для робочих груп, вони орієнтовані великі компанії і можуть підтримувати територіально рознесені вузли чи мережі. В основному вони мають ієрархічну структуру з кількох рівнів. Для таких систем характерна архітектура клієнт-сервер зі спеціалізацією серверів або багаторівнева архітектура. Під час створення таких систем можуть використовуватися самі сервери баз даних, як і розробки групових інформаційних систем. Однак у великих інформаційних системах найбільшого поширення набули сервери Oracle, DB2 і Microsoft SQL Server.

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

Класифікація у сфері застосування

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

* Системи обробки транзакцій;

* Системи прийняття рішень;

* інформаційно-довідкові системи;

* офісні інформаційні системи.

Список використаної літератури

1. Агальцов, В.П. Бази даних. У 2-х т. т. 2. Розподілені та віддалені бази даних: Підручник / В.П. Агальці. - М: ІД ФОРУМ, НІЦ ІНФРА-М, 2013.

2. Голіцина, О.Л. Бази даних: Навчальний посібник/О.Л. Голіцина, Н.В. Максимов, І.І. Попов. – К.: Форум, 2012.

3. Карпова, І.П. Бази даних: Навчальний посібник/І.П. Корпова. – СПб.: Пітер, 2013.

4. Кирилів, В.В. Введення в реляційні бази даних. Введення в реляційні бази даних/В.В. Кирилов, Г.Ю. Громів. – СПб.: БХВ-Петербург, 2012.

5. Пирогов, В.Ю. Інформаційні системи та бази даних: організація та проектування: Навчальний посібник / В.Ю. Пирогів. – СПб.: БХВ-Петербург, 2009.

6. Г.М. Федорова. Інформаційні системи. – К.: Академія, 2013.

7. А.Є. Сатуніна, Л.А. Сисоєва. Управління проектом корпоративної інформаційної системи підприємства - М.: Фінанси та статистика, Інфра-М, 2009.

Розміщено на Allbest.ru

...

Подібні документи

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

курсова робота , доданий 29.01.2011


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

курсова робота , доданий 19.01.2011


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

реферат, доданий 20.12.2010


Концепція системи бази даних. Реляційна модель та її характеристики. Цілісність у реляційній моделі. Реляційна алгебра. Запитання проектування БД. Нормальні форми відносин. Проектування БД шляхом сутність-зв'язок. ER-діаграми. Мова SQL.

курс лекцій, доданий 03.10.2008


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

презентація , доданий 14.10.2013


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

реферат, доданий 19.12.2011


Види та функції системи управління базами даних Microsoft Access. Ієрархічна, мережева, реляційна модель опису баз даних. Основні поняття таблиці баз даних. Особливості створення об'єктів бази даних; основні форми. Доступ до Internet у Access.

контрольна робота , доданий 08.01.2011


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

наукова робота , доданий 08.06.2010


Моделі даних управління базами даних. Концептуальні моделі даних. Роль баз даних у інформаційних системах. Реляційна модель даних. Визначення предметної галузі. Побудова моделі баз даних для інформаційної системи "Домашні тварини".

курсова робота , доданий 19.04.2011


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