Купувати чи будувати
Лише в рідкісних випадках є сенс створювати інструмент метаданих з нуля. Це пов’язано з тим, що для цього потрібні ресурси, які добре знайомі з операційними, технічними та бізнес-аспектами системи сховища даних, а такі ресурси важко знайти. Навіть коли такі ресурси доступні, часто існують інші завдання, які можуть принести більше користі організації, ніж створення інструменту метаданих з нуля.
Насправді, питання часто полягає в тому, чи потрібен взагалі будь-який тип інструменту метаданих. Хоча метадані відіграють надзвичайно важливу роль в успішному впровадженні сховища даних, це не завжди означає, що потрібен інструмент для зберігання всіх “даних про дані”. Таку інформацію можна, скажімо, зберігати в репозиторії інших використовуваних інструментів, у текстовій документації або навіть у презентації чи електронній таблиці.
Зважаючи на вищесказане, автор вважає, що наявність міцної основи метаданих є одним із ключів до успіху проекту зі створення сховища даних. Тому, навіть якщо інструмент метаданих не обрано на початку проекту, важливо мати стратегію метаданих, тобто те, як будуть зберігатися метадані в системі зберігання даних.
Функціональні можливості інструменту метаданих
Це найскладніший інструмент для вибору, тому що тут немає чіткого стандарту. Насправді, можливо, було б краще назвати це вибором стратегії метаданих. Традиційно люди вносять інформацію для моделювання даних в такі інструменти, як ERWin та Oracle Designer, але витягти інформацію з таких інструментів моделювання даних складно. Наприклад, однією з цілей вибору метаданих є надання інформації кінцевим користувачам. Очевидно, що це складне завдання за допомогою інструменту моделювання даних.
Тому, як правило, додаткові зусилля витрачаються на створення шару метаданих, орієнтованих на кінцевих користувачів. Хоча це дозволяє кінцевим користувачам отримати необхідне розуміння того, що означають дані і звіти, які вони переглядають, це явно неефективно, оскільки вся ця інформація вже знаходиться десь у системі сховища даних, чи то інструмент ETL, інструмент моделювання даних, інструмент OLAP або інструмент звітності.
Постачальники інструментів для сховищ даних намагаються об’єднати їх на основі моделі метаданих. У червні 2000 року OMG випустила стандарт метаданих під назвою CWM (Common Warehouse Metamodel), і деякі постачальники, такі як Oracle, заявили про його впровадження. Цей стандарт включає в себе новітні технології, такі як XML, UML і SOAP, і, якщо він буде широко прийнятий, це дійсно найкраще, що може статися з індустрією зберігання даних. Однак, на даний момент автор не бачив багато інструментів, що використовують цей стандарт, тому очевидно, що він ще не зовсім прижився.
Тож що це означає для ваших зусиль у сфері метаданих? За відсутності всього іншого, я б рекомендував, щоб будь-який інструмент, який ви обираєте для управління метаданими, підтримував XML, і щоб будь-який інший інструмент, який має використовувати метадані, також підтримував XML. Тоді це питання визначення DTD у вашій системі зберігання даних. При цьому не потрібно турбуватися про критерії, які зазвичай є важливими для інших інструментів, такі як продуктивність і підтримка паралелізму, оскільки розмір метаданих, як правило, невеликий порівняно з розміром сховища даних.
ОРИГІНАЛ СТАТТІ:Reporting Tools
🚀Долучайтесь до нашої спільноти Telegram:
🚀Долучайтесь до нашої спільноти FaceBook:
