Kto to pisze i dlaczego uważa, że może...

Moje zdjęcie
Doświadczony. Hmmm. Może docenisz tę cechę? Nie wiem, czy warto. Doświadczenie to głównie to, czego bym nie radził Tobie powtarzać. Ale i tak zrobisz, co zechcesz...

wtorek, 9 września 2014

Codd'a 12 zasad zarządzania bazą danych dla OLAPu


Jako glossa do nieudanej ale burzliwej "dyskusji" o tym, czym jest OLAP i czy tabela przestawna i OLAP to inne bajki, zamieszczam podstawowy tekst tego Ojca Założyciela dzisiejszej technologii bazodanowej Edgara Franka "Teda" Codd'a.

W tekście wytłuszczam te fragmenty, które bezpośrednio odnoszą się do przedmiotu sporu.
W komentarzach (kursywą) wyjaśniam, jakie wypowiedzi mojego adwersarza i moje mają tu zastosowanie.
Dyskusja ta ma charakter nieco abstrakcyjny, ale dla genezy dzisiejszych "problemów z analizą biznesową", ma fundamentalne znaczenie. Moim skromnym zdaniem.
Tłumaczenie zasad z angielskiego tekstu - własne.

Zaczynam:
W 1985 Edgar F. Codd napisał artykuł, określający zasady dla Systemów Zarządzania Relacyjnymi Bazami Danych (RDBMS systemów zarządzania), które zrewolucjonizowały branżę IT.
Pamiętam, jak czytałem jeszcze wcześniejsze teksty Codda, wówczas pracownika IBM, w materiałach szkoleniowych tej firmy, jeszcze nie zdając sobie sprawy z ich znaczenia, w czytelni Ośrodka Obliczeniowego MPM na Kruczej, w Warszawie, na początku lat osiemdziesiątych. Stała tam najnowocześniejsza w kraju maszyna IBM 370, o gigantycznej pamięci operacyjnej 1 MB. Na ogromnych (fizycznie) dyskach stumegabajtowych można było tę pamięć "wirtualnie" rozszerzyć. Rozwiązywaliśmy na tej  maszynie układy równań o kilkudziesięciu tysiącach niewiadomych. A jednocześnie - można by powiedzieć, że byłem świadkiem narodzin współczesnej informatyki bazodanowej, czytając pierwsze koncepcje Codd'a - języka SQL i relacyjnych baz danych.

W 1993 roku, Codd wraz z kolegami, opracował 12 zasad, które definiują OLAP (Online Analytical Processing), technologię oprogramowania i przetwarzania danych, która pozwala na konsolidację i analizę danych w wielowymiarowej przestrzeni.

Oto 12 postulatów Codda:
(podkreślenia i komentarze - KR)

1.    Wielowymiarowy, poglądowy - Widok

Analitycy muszą mieć możliwość  ujrzenia przedsiębiorstwa jako obiektu z natury wielowymiarowego.
 - na przykład, zyski mogą być prezentowane dla regionu, produktu, okresu czasu, lub scenariusza (takiego jak rzeczywisty, planowany lub prognozowany). Wielowymiarowe modele danych umożliwiają proste, bardziej intuicyjne manipulowanie danymi przez użytkowników, w tym - "krojenie w plastry i kostki".

2.    Przezroczystość

Niezależnie od tego, czy OLAP stanowi część standardowego arkusza kalkulacyjnego, czy pakietu graficznego, powinno to być przezroczyste dla użytkownika. OLAP powinien być częścią struktury systemów otwartych, które mogą być osadzone w każdym miejscu pożądanym przez użytkownika, bez szkodliwego wpływu na funkcjonalność narzędzia - gospodarza. Użytkownik nie powinien być nawet świadom, z jakich źródeł danych korzystały narzędzia OLAP. Np. czy były one jednorodne czy niejednorodne (co do formatu i platformy).
(podkreślenia KR)
 (1) To kluczowe zdania dla przedmiotu naszej dyskusji: 
- "Ojciec Założyciel" uważa za oczywiste, że tabela przestawna - to OLAP. Mało tego, uważa on, że OLAP jest (może być) wręcz częścią customizowanego skoroszytu. Sceptyków odsyłam do oryginalnego tekstu (Punkt 2).
- Mój adwersarz, że to całkiem inna bajka.

I mimo wielkiego wysiłku, nie potrafiłem go przekonać. Może pan Codd go przekona?

3.    Dostępność (Accessibility)

W celu uzyskania dostępu do heterogenicznych źródeł danych, przeprowadzenia wszelkich niezbędnych do konwersji i przedstawienie spójnego widoku dla użytkownika, narzędzia OLAP powinny mieć własną strukturę logiczną. Narzędzie (nie użytkownik) powinno samo troszczyć się, skąd pochodzą dane fizyczne.

Ten postulat systemy raportujące starają się realizować, ale zazdrośnie strzegą dostępu do ujednoliconych danych przez tabelę przestawną znajdującą się w Excelu. Ten link, punkt 3 artykułu

4.    Stabilna wydajność raportowania

Wydajność narzędzia OLAP nie powinna ucierpieć  znacząco, w miarę zwiększania się liczby wymiarów.

5.    Architektura Klient / serwer

Komponent serwera narzędzi OLAP powinien być wystarczająco inteligentny, aby różni klienci mogli być dołączeni przy minimalnym wysiłku. Serwer powinien być zdolny do odwzorowania i konsolidacji danych dla różnych baz danych. 


Czy 5 -ty postulat Codda został zrealizowany? Właśnie cały mój wywód, do którego nawiązuje uwaga (2) (patrz ten artykuł, zwłaszcza rozdział "Praktyka z wczoraj i co się z nią stało") udowadnia, że jest z tym nienajlepiej.

6.    Generyczna (uwzględniająca realizację, realistyczna) struktura wymiarów


Każdy wymiar danych powinien być równoważny  do jego struktury i zdolności operacyjnych.
(Każdy wymiar danych powinien mieć przemyślaną strukturę i możliwości operacyjne jej realizacji.)

7.    Dynamiczna obsługa rzadkich macierzy

Fizyczna struktura serwera OLAP powinna zapewniać optymalną obsługę macierzy rzadkich.

8.    Wsparcie dla wielu użytkowników

Narzędzia OLAP muszą zapewnić jednoczesną aktualizację i dostęp (do odczytu), integralność i bezpieczeństwo.

9.    Operacje cross-wymiarowe

Narzędzia obliczeniowe muszą umożliwić obliczenie i manipulację danych na dowolnej liczbie wymiarów danych i nie mogą ograniczać żadnych relacji między elementami danych.

10.                   Intuicyjna obsługa danych

Manipulacja danymi znajdującymi się na ścieżce konsolidacji, takie jak drill-down lub agregowanie, powinny być realizowane poprzez bezpośrednie działanie na komórki modelu analitycznego, a nie poprzez korzystanie z menu lub poprzez skomplikowaną nawigację po całym interfejsie użytkownika.

11.                   Elastyczne raportowanie

Funkcjonalność raportowania powinna zapewnić informacje w formie wymaganej przez użytkownika

Przez elastyczne raportowanie producenci BI rozumieją swoje raporty, których zmiana, aktualizacja, poprawka  wymaga najczęściej oddzielnego projektu informatycznego. Jeśli to jest elastyczne, to niewiele rzeczy jest nieelastycznych. Omawiałem to w przywołanym wyżej tekście, rozdział "Konsekwencje dziwnego rozwoju analizy". 

12.                   Nieograniczone Wymiary i poziomy agregacji.

Dla wszystkich zadań i celów - Liczba obsługiwanych wymiarów danych powinna być nieograniczona. Każdy wymiar  ogólny powinien umożliwić w zasadzie nieograniczoną liczbę poziomów agregacji zdefiniowanych przez użytkownika w obrębie danej ścieżki konsolidacji.

Na tle tych archaicznych już, zdawałoby się postulatów "ojca założyciela", współczesny analityk może sam sobie sobie odpowiedzieć, czy pracuje w środowisku analiz, które wyobrażał sobie dwadzieścia lat temu mister Codd z kolegami, czy może jednak coś się nie udało?
Stąd właśnie nasza koncepcja innej architektury - SOA.