Inwestycje w pozyskiwanie i analizę danych mają na dłuższą metę sens tylko wtedy, jeśli równolegle firma ma pomysł na kompleksowe zarządzanie metadanymi. Niestety, na razie nie jest to łatwe.

Zasób informacji elektronicznych w firmach wzrasta. Ktoś powiedział, że liniowo, ktoś inny, że wykładniczo. Mniejsza o to - ważniejsza jest inna obserwacja, a mianowicie że od gromadzenia informacji firmy, generalnie rzecz biorąc, nie stają się mądrzejsze. Proces podejmowania decyzji był i nadal jest długi i obarczony błędami. Pracy na poziomie operacyjnym też nie ubyło, bo poprawa produktywności związana z automatyzacją tych czy innych zadań została zmarnowana przez konieczność wprowadzania większej ilości danych - często tych samych na różnych stanowiskach.

Można wskazać wiele przyczyn cząstkowych, które nakładają się na takie "dryfowania", jedna wszakże wydaje się nie do pominięcia: niedostateczne co do zakresu i jakościowo marne metadane, czyli dane służące do opisu znaczenia danych. Źródłem lepszych bądź gorszych metadanych są oczywiście aplikacje, których polityka w tym względzie nadal często odbiega nie tylko od dobrej praktyki, ale i od zdrowego rozsądku i dobrego smaku.

Bywa, że od dostawcy trudno uzyskać nawet prosty opis znaczenia poszczególnych pól w bazie danych, a co dopiero bardziej skomplikowane opisy relacji pomiędzy informacjami. Nawet jeśli firmie uda się zgromadzić metadane dotyczące wszystkich głównych systemów, jest to informacja cząstkowa, obejmująca główny system transakcyjny, hurtownię danych i warstwę OLAP. Informacji o związkach pomiędzy takimi wyspami metadanych - które pozwoliłyby sprawnie zrządzać procesami - jest jak na lekarstwo.

Standardy niewiele zmieniają

Problem nie wynika stąd, że nie wiadomo jak taką strukturę zbudować. Standardy stworzone dokładnie w tym celu, m.in. Object Management Group (OMG), Meta-Object Facility (MOF) Common Warehouse Metamodel (CWM) istnieją od bardzo dawna.

Meta-Object Facility to pewnego rodzaju definicja frameworku aplikacyjnego w obszarze pracy z metadanymi. Zawiera mechanizmy do przechowywania i udostępniania pewnego repozytorium, jak również API, które (w uproszczeniu) pozwala na użycie obiektu bez uprzedniej znajomości jego struktury czy związków z innymi encjami. Dzięki obsłudze refleksji można w ten sposób odczytać listę atrybutów czy wyszukać element o danym identyfikatorze.

Unified Modelling Language autorstwa OMG jest narzędziem do definiowania struktury aplikacji (i przepływu metadanych). Dodając do tego koncepcje PIM, a następnie PSM, można definiować pełne aplikacje. Common Warehouse Metamodel (CWM) to z kolei standard określający sposób opisu schematu i metadanych w hurtowni danych (a także szerzej w rozwiązaniach analitycznych).

Oprócz tego dostępny jest mechanizm wymiany informacji o metamodelu działający w oparciu o XML - XMI (XML Metadata Interchange). Wykorzystuje standard SMIF (Stream-based Model Interchange Format) i pozwala na wymianę repozytoriów, zarówno między systemami/aplikacjami i serwerami metadanych, jak i w środowiskach programistycznych czy IDE - do projektowania metadanych (w tym zastosowaniu najbardziej się upowszechnił).

Nawet jednak na poziomie programisty metadane mogą być źródłem problemów. Większość narzędzi do modelowania (stosunkowo dobrze rozwiązane jest to w PowerDesigner) ma opcję tzw. analizy wpływu, która pozwala sprawdzić, w których miejscach aplikacji trzeba będzie wprowadzić zmiany, gdy zmieni się struktura definicji obiektu (czyli pewna metainformacja). Nawet jeżeli mamy repozytorium metadanych, aplikacje trzeba pisać w specyficzny sposób, by móc z niego skorzystać.

Niestety, znakomita większość mechanizmów przyspieszających tworzenie rozwiązań (generatory kodu itp.) nie uwzględnia istnienia serwerów metadanych. Może z czasem ulegnie to zmianie, ale na razie jeżeli programista ma wykorzystać informacje pochodzące z takiego repozytorium, to kod obsługujący taką interakcję musi napisać ręcznie.

Kilka ważnych szczegółów

Wybierając rozwiązanie do zarządzania metadanymi warto zwrócić uwagę na kilka zagadnień, które niestety są często pomijane. Pierwszy to wersjonowanie. Metadane z natury rzeczy ulegają zmianom w czasie. Przykładowo, rozszerzana jest definicja klienta (np. przez dodanie kilku nowych pól), znikają pewne wpisy z listy słownikowej itp. Większość aplikacji wciąż zakłada jednak, że metadane są statyczne i stąd bierze się wiele problemów. Co prawda API izoluje kod od metamodelu, ale w przypadku gdy np. atrybut znika, "bo jest niepotrzebny", mamy do czynienia z modyfikacją eliminującą "zgodność w dół".

Innym problemem jest możliwość opisania jednej informacji w kilku językach. Metadane to nie tylko abstrakcyjne modele, ale także np. słownik miar w systemie produkcyjnym. W przypadku raportu dla USA warto np. zmienić rozmiary produkowanych elementów z ISO na miary anglosaskie. W przypadku nazw krajów także trzeba wiedzieć, że Finlandia to po fińsku Suomi itd.

Warto dodać, że standardy OMG są dosyć abstrakcyjne i tak naprawdę definiują strukturę do definiowania metamodelu, a nie konkretny metamodel. Implementacja poszczególnych standardów i późniejsza "używalność" API to tak naprawdę dwie różne rzeczy. Z tego właśnie powodu na rynku jest miejsce na różne standardy branżowe, opracowane przez konkretnych dostawców.

Nie można też unikać faktu, że w wielu rozwiązaniach tak wysoki poziom abstrakcji nie jest po prostu potrzebny. Wystarczy np. MDX/XML For Analysis czy inny standard pracy z danymi i wymiany informacji z hurtownią/kostką OLAP. Z punktu widzenia firmy metadane to nie pojęcie abstrakcyjne, a raczej konkretne elementy opisowe - słowniki, związki między systemami i obiektami biznesowymi itp. Używając takiego języka, problem ujednolicenia informacji można rozwiązać na wiele sposobów.

Rozwiązania niby są

Tak naprawdę rozwiązanie do zarządzania metadanymi ma już chyba każdy dostawca middleware. SAP oferuje moduł Master Data Management, który jest centralnym repozytorium danych słownikowych, co samo przez się eliminuje sporo problemów związanych z metadanymi. BEA ma produkt AquaLogic Data Services (dawniej Liquid Data), pozwalający na definiowanie metadanych oraz kojarzenie ich z ich systemem macierzystym.

Podobne rozwiązanie ma także SAS Institute. Również Hyperion MDM pozwala określić tzw. master data i zdefiniować (używając motoru przepływu czy reguł) zasady synchronizacji. Dodatkowo Hyperion zawiera moduły pozwalające "zwykłym" użytkownikom zarządzać metadanymi, np. samodzielnie określić wartości atrybutów. Microsoft w SQL 2005 wprowadził UDM - Unified Data Model, w którym w ramach jednego pojemnika definiuje się pola relacyjne, elementy OLAP, określa translację pojęć, a następnie taki UDM może być wykorzystany do definiowania struktur analitycznych.

Innym ciekawym produktem jest InfoLibrarian - rozwiązanie sprzętowo-programowe, które z jednej strony gromadzi informacje z różnych plików (indeksując je), ale równocześnie zawiera repozytorium metadanych. Firma reklamuje się twierdząc, że "wystarczy wstawić taki serwer do sieci i problem metadanych zostaje wyeliminowany". To oczywiście przesada, ale na pewno można w ten sposób otrzymać "prawie gotowe" rozwiązanie, które zapewni infrastrukturę do gromadzenia i zarządzania metadanymi, oferując przy okazji API dla nowo tworzonych aplikacji.

Ciekawe rozwiązanie oferuje Informatica (dawniej produkt SuperGlue, a obecnie PowerCenter). PowerCenter zawiera centralne repozytorium metadanych oraz mechanizmy do zarządzania, walidacji oraz synchronizacji informacji między repozytoriami metadanych. Informatica definiuje nawet pojęcie Metadata-Driven Architecture, które odnosi się do tego, że przy konstruowaniu aplikacji uwzględnia się "zewnętrzną" warstwę metadanych.

Centralnie lub w rozproszeniu

Rozważania nad kompleksową organizacją metadanych w firmie spędzają sen z powiek niewielu firmom. Dla wielu z nich wygodniej jest "zadowolić się" warstwą integracyjną. Wtedy w kilku rozwiązaniach mamy co prawda wiele "wersji" tych samych danych, ale narzędzie integracyjne (Tibco, BizTalk, w pewnym sensie

Altova MapForce czy Oracle BI) określa, które elementy są tożsame i w jaki sposób ma następować wymiana treści. Takie rozwiązanie ma także tę zaletę, że jest nieinwazyjne, czyli działa na zewnątrz krytycznych aplikacji.

Jest szansa, że gdy aplikacje będą szeroko wykorzystywały usługi Web (czy to budowane zgodnie z SOA, czy po prostu usługi będą jednym z wielu sposobów komunikacji), wtedy taka integracja będzie prosta. Jednak w takim podejściu okaże się, że jeżeli np. pobieramy listę klientów z usługi Web, to możemy przekonfigurować wszystkie systemy, tak by te dane pobierały z jednego miejsca.

Nie powstanie wtedy "centralny serwer metadanych", ale będzie jedno źródło informacji określonego typu. Do tego natura usług Web (a zwłaszcza język XML) pozwala w wielu przypadkach w dosyć prosty sposób przekształcać i dostosowywać format do wymagań różnych systemów. Jednak to nadal będzie rozwiązanie tylko pewnego "wycinka" problemów związanych z metadanymi.

Metadane a ILM

Nacisk na zarządzanie metadanymi pojawia się coraz częściej także ze strony rozwiązań do archiwizacji danych i zarządzania dokumentami. Wszystkie współczesne rozwiązania oznaczone trzyliterowym skrótem ILM (Information Lifecycle Management) wpadają do tej przegródki. Koncepcja ILM zakłada (w dużym uproszczeniu), że dobieramy sposób składowania informacji do ich wagi. To co jest świeże, często używane itp., znajduje się na "szybkiej" pamięci, a w miarę tracenia istotności jest przenoszone na taśmy czy nośniki optyczne.

Choć same dane stają się nieco mniej dostępne, należy zachować szybki dostęp do opisujących je metadanych, by móc w miarę sprawnie ustalić lokalizację poszukiwanych informacji. W przypadku plików sytuacja jest dosyć oczywista - każdy dokument może być opisany metadanymi (tytuł, autor, streszczenie itp.). Poza tym plik zawsze ma datę utworzenia i ostatniego dostępu. Tak więc zachowanie tych informacji i przeniesienie danych np. na taśmę nie stanowi problemu.

W przypadku hurtowni danych zwykle dzieje się tak, że zostaje agregat (np. sumaryczna wysokość sprzedaży w danym okresie), z informacją gdzie szczegółowe dane zostały przeniesione. Zawsze jednak pojawia się problem: skąd wiadomo, które dane są już niepotrzebne. Zwykle decyduje "zdrowy rozsądek" i regulacje prawne. Klasyfikacja danych to jeden z fundamentalnych problemów szybko rozrastającej się dziedziny wiedzy, jaka powstaje wokół ILM.

W kontekście systemów typu ILM pojawia się jeszcze jedno zagadnienie. Z uwagi na naturę takich systemów przechowywania metadane muszą być tak za-pisane, by ich format/postać była czytelna nawet po 10 czy 30 latach. Warto też, aby został opracowany w miarę spójny model informacyjny - tak by nie trzeba było w przyszłości dodawać lub usuwać pewnych atrybutów.