Próba stworzenia standardu 'danych o danych'.

Zmienność ekonomii światowej i coraz ostrzejsza konkurencja zmuszają firmy handlowe do wykorzystywania posiadanych zasobów w nowy, kreatywny i bardziej efektywny sposób. Jednym z takich zasobów są dane. Jeszcze do niedawna uważane jedynie za siłę napędową codziennej działalności gospodarczej, obecnie stają się samodzielnymi i niesłychanie cennymi aktywami firmy.

Jednakże zwiększająca się szybkość zmian w gospodarce powoduje, że wielkiego znaczenia nabiera wiarygodny i szybki dostęp do danych. Potrzeba uzyskania szybkiego i łatwego w zarządzaniu dostępu do danych stworzyła nowe technologie - hurtownie danych, przetwarzanie rozproszone klient/serwer oraz wielkie zintegrowane aplikacje, tak jak SAP R/3, pakiety Dun & Bradstreet czy Oracle.

W tych nowych warunkach krytycznym elementem zarządzania danymi stają się "metadane", czyli "dane o danych" - ich lokalizacji, sposobach dostępu, właściwościach, strukturze, formatowaniu i in. Dane o danych są gromadzone w repozytoriach (zwanych czasem słownikami danych). Wiele narzędzi do tworzenia aplikacji tworzy i utrzymuje własne repozytoria. Istnieją także specjalistyczne narzędzia do zakładania, obsługi i utrzymywania repozytorium dla potrzeb całej firmy.

Istotny problem związany z metadanymi polega na tym, że każda implementacja słownika czy repozytorium jest unikatowa i związana z narzędziem. Problem ten próbuje rozwiązać firma konsultingowa Meta Group, która zebrała roboczą grupę producentów narzędzi Metadata Council (w jej skład wchodzą m.in. firmy Arbor Software, Cognos Inc., Platinum Technology i Texas Instruments). Celem ma być opracowanie zestawu funkcji aplikacyjnych API dla metadanych, definiowanych i utrzymywanych przez reprezentantów przemysłu. Po powstaniu takiego standardu można będzie założyć w firmie jedno wspólne repozytorium, zdefiniować w nim metadane tylko raz i korzystać z nich za pomocą różnych narzędzi.

Standard wymiany metadanych

Proponowany standard wymiany metadanych składa się z czterech warstw (p. rysunek):

• standardowego metamodelu danych;

• minimalnego zestawu funkcji API dostępu do metadanych;

• warstwy translacji modelu;

• warstwy konfiguracji użytkowej.

W implementacji standardu modelu metadanych zakładano początkowo, że będą one zapamiętywane w dowolnym formacie wybranym przez producenta narzędzia: tabelach bazy relacyjnej, pliku tekstowym, bazie nierelacyjnej i in. Tak więc standard wymiany tych danych musiałby dopuszczać możliwość translacji danych do postaci właściwej dla używanego narzędzia. Jest to jednak trudne do przyjęcia, gdyż tworzy więcej problemów niż ich rozwiązuje.

Problem próbuje się więc rozwiązać na kilka sposobów: przez przyjęcie obszernego zestawu standardowych funkcji API, do których wszystkie narzędzia musiałyby się odwoływać, zapisywanie metadanych w pliku tekstowym, ładowanym w momencie startu narzędzia lub podejście hybrydowe.

W przypadku zdefiniowania standardowych API dostępu do modelu metadanych, każda zmiana ich zestawu spowoduje konieczność zmian narzędzia (podobna sytuacja występuje w X-Windows, gdzie każde uaktualnienie zestawu funkcji API powoduje konieczność przekodowania i przekompilowania aplikacji).