EDW #2: Słowniczek

Ten wpis należy do serii wpisów poświęconych architekturze hurtowni danych.

Zanim przejdziemy do konkretów, najpierw przedstawię kilka podstawowych definicji, żebyśmy mówili wspólnym językiem.

Uwaga #1: Definicje są pisane moim własnym widzimisię (nie będę ściągał z Wiki), jeżeli widzisz jakieś braki lub niedociągnięcia, komentuj śmiało, poprawię.

Uwaga #2: poniższa lista jest stworzona ad-hoc – będę ją (być może) rozbudowywał w miarę potrzeb. Być może nawet kiedyś ułożę ją alfabetycznie… Poniższe definicje to nie jakieś kompendium wiedzy, pochodzą z różnych podwórek, dotyczą różnych zagadnień

encja (ang. entity): klasa obiektów biznesowych mających wspólny zestaw cech. Encją może być na przykład [Klient], [Adres], [Faktura] albo [Rodzaj konta]. To najważniejsze pojęcie w DW – wszystko tak naprawdę kręci się wokół encji. Jeżeli programujesz obiektowo, możesz myśleć o encji jako o klasie. W bazie danych encja odpowiada, w przybliżeniu, tabeli.

obiekt (ang. object): pojedynczy, jednoznacznie identyfikowalny element należący do danej encji. Na przykład obiektem encji [Klient] może być Jan Kowalski, urodzony 24 sierpnia w Kluczborku. Z obiektowego punktu widzenia obiekt to instancja klasy. W bazie danych obiekt to – w przybliżeniu – jeden rekord w tabeli.

atrybut (ang. attribute): cecha encji. Atrybutami encji [Klient] mogą być na przykład [Imię], [Nazwisko] czy [Data urodzenia], a atrybutami encji [Faktura] mogą być [Data wystawienia], [Kwota brutto] albo [Numer faktury]. W bazie danych odpowiednikiem atrybutu jest na ogół kolumna.

identyfikator lub klucz (ang. identifier, key): atrybut (lub zbiór atrybutów) encji umożliwiający jednoznaczne rozpoznanie każdego z obiektów należących do encji. Przykładowo atrybutem obiektu [Jan Kowalski] należącego do encji [Klient] może być [Numer klienta], [PESEL] albo automatycznie generowany klucz liczbowy (IDENTITY), lub cokolwiek innego, unikalnego dla danego klienta.

Klucze dzielimy na dwa rodzaje: biznesowe i techniczne. Klucz biznesowy to taki, którego atrybuty są „rozumiane” przez użytkowników końcowych. Na przykład [Numer klienta] albo [Data]. Klucz techniczny to taki, który jest generowany wewnętrznie przez system (na przykład jako IDENTITY) i zazwyczaj nie jest znany użytkownikowi końcowemu. Każda encja powinna mieć co najmniej jeden z tych dwóch identyfikatorów. Często ma obydwa (biznesowy dla użytkowników oraz techniczny dla programistów i dla poprawienia wydajności).

relacja (ang. relationship): „połączenie” dwóch (lub więcej) encji za pomocą atrybutów. Teoria modelowania danych rozróżnia wiele rodzajów relacji. Najczęściej używane to jeden-do-jednego (ang. one-to-one), jeden-do-wielu (one-to-many) oraz wiele-do-wielu (many-to-many). Aby relacja mogła powstać, niezbędne są klucze unikalne. Przykładowo jeżeli w encji (tabeli) [Geografia] mamy obiekt (rekord) [Kluczbork] oraz przypisany mu identyfikator techniczny ID=2389754, wówczas w pojedynczym rekordzie encji [Klient], odpowiadającemu klientowi [Jan Kowalski], zamiast przechowywać w kolumnie [Miejsce urodzenia] wartość tekstową „Kluczbork”, użyjemy tam identyfikatora unikalnego 2389754. To przykład relacji jeden-do-wielu, bo Jan Kowalski urodził się w jednym mieście (w Kluczborku), ale w Kluczborku urodziło się wiele osób. Relację jeden-do-wielu określa się również mianem rodzic-dziecko (ang. parent-child) – w tym przypadku obiekt [Kluczbork] jest „rodzicem” obiektu [Jan Kowalski]. Stąd też mamy nowe pojęcie, czyli:

klucz obcy (ang. foreign key): identyfikator obiektu przechowywany w innym obiekcie w ramach relacji. W przykładzie powyżej klucz techniczny 2389754 rekordu [Kluczbork] w tabeli [Geografia] jest jednocześnie kluczem obcym w rekordzie [Jan Kowalski] w tabeli [Klient].

fakt (ang. fact): obiekt należący do encji reprezentującej pojedyncze „wydarzenie” biznesowe. Faktem może być na przykład wystawienie faktury albo wypożyczenie książki, albo dodanie wpisu do blogu. Encje definiujące fakty są (na ogół) „wysokie” oraz „chude”, czyli – mówiąc językiem baz danych – są to tabele z relatywnie dużą ilością wierszy oraz niewielką ilością kolumn, najchętniej numerycznych.

miara (ang. measurement): ilościowy atrybut faktu, na przykład kwota na fakturze lub ilość słów we wpisie na blogu, lub ilość uczniów w klasie. Miary mogą być addytywne: jeżeli dodamy wartości miar z kilku różnych faktów tej samej encji, uzyskany wynik będzie „miał sens” biznesowy (na przykład jeżeli klasa 1a ma aktualnie 17 uczniów, a klasa 1b 23, łączna ilość uczniów w klasach 1a i 1b wynosi 40). Przykładem miary nieaddytywnej jest udział procentowy: jeżeli w klasie 1a jest 30% dziewczynek, a w 1b 40%, nie oznacza to bynajmniej, że w obydwu klasach jest łącznie 70% dziewczynek. Każdy fakt powinien mieć przynajmniej jedną miarę (jeżeli nie ma jej w sposób naturalny, często tworzy się „sztuczną” miarę równą jeden dla każdego rekordu, umożliwiającą przynajmniej zliczanie rekordów-faktów).

wymiar (ang. dimension): encja reprezentująca „obiekty biznesowe”. Wymiarem może być np. [Klient], [Data] czy [Województwo]. Wymiary z założenia są „niskie” i „grube”, a więc mają mniej rekordów, niż fakty, za to więcej atrybutów umożliwiających potem bogatsze analizy.

Uwaga: dość uniwersalnym sposobem na rozpoznanie, czy dana encja jest faktem, czy wymiarem, jest próba postawienia jakiegoś zadania analitycznego. Na przykład: „Jak wygląda kwota sprzedaży netto według krajów, miesięcy i rodzajów produktów?” Encje występujące po słowie „według” prawie na pewno będą związane z wymiarami. W tym przypadku: [Kraj], [Miesiąc], [Rodzaj produktu] to atrybuty wymiarów [Geografia], [Kalendarz], [Klasyfikacja produktu]. Natomiast encje występujące przed słowem „według” prawie na pewno będą faktami (lub miarami należącymi do faktów). W tym przypadku mamy „Kwota sprzedaży netto”, która może być miarą faktu [Faktura] albo [Sprzedaż]. I tak dalej.

wymiar zdegenerowany (ang. degenerated dimension): wymiar charakteryzujący się tylko jednym atrybutem. Klasyczny przykład wymiaru zdegenerowanego to [Numer faktury]. Wymiary zdegenerowane na ogół nie istnieją w postaci osobnej tabeli – są zamiast tego „wchłonięte” przez skojarzone z nimi fakty.

hierarchia (ang. hierarchy): wymiar, którego atrybuty zorganizowane są od ogółu („rodzica”) do szczegółu („dziecka”), przy czym szczegóły są unikalne w ramach tego samego rodzica. Przykładowa hierarchia to wymiar [Kalendarz], który na najwyższym (najbardziej ogólnym) poziomie może mieć [Rok], w ramach każdego roku mamy unikalny dla każdego roku [Kwartał] (Q1, Q2, Q3, Q4), potem [Miesiąc] i [Data]. Innym przykładem hierarchii kalendarzowej może być [Rok]=>[Tydzień]=>[Data] albo [Region] => [Kraj] => [Województwo] i tak dalej. Atrybut najbardziej szczegółowy (w naszym przykładzie: data) jest zazwyczaj kluczem biznesowym hierarchii. Hierarchia może być przechowywana w postaci zdenormalizowanej w pojedynczej tabeli lub w postaci (mniej lub bardziej) znormalizowanej w kilku tabelach połączonych kaskadowo relacją jeden-do-wielu.

agregacja (ang. aggregation): operacja polegająca na zgrupowaniu wartości tego samego atrybutu z wielu obiektów tej samej klasy (po naszemu: wartości z tej samej kolumny z wielu rekordów tej samej tabeli), a następnie przeprowadzeniu na tak powstałej grupie operacji scalającej ją do pojedynczej wartości. Agregacji dokonuje się na ogół na atrybutach numerycznych (i addytywnych). Najpopularniejsze agregacje to: ilość wystąpień, suma, średnia, mediana, minimum, maksimum, odchylenie standardowe. W przypadku agregowania atrybutów tekstowych można na przykład policzyć ilość unikalnych wystąpień danego tekstu, albo wykonać zamianę wielu wartości w listę, lub ich de-duplikację i tak dalej.

normalizacja (ang. normalization): szerokie pojęcie z zakresu organizacji danych, oznaczające takie zorganizowanie danych w encje, atrybuty, identyfikatory i relacje, które zminimalizuje redundantność danych przy jednoczesnym zachowaniu pożądanej funkcjonalności. Prostym przykładem normalizacji może być operacja opisana w definicji relacji (patrz wyżej), gdzie zamiast przechowywania nazwy „Kluczbork” we wszystkich rekordach klientów urodzonych w Kluczborku, przechowujemy tylko numeryczny identyfikator Kluczborka, a samą nazwę przenosimy do osobnej tabeli [Geografia]. Normalizacja niesie ze sobą wiele zalet: poprawia spójność danych, redukuje redundancję, poprawia wydajność wykonywania zapytań. Nadmierna normalizacja może jednak prowadzić do zbyt dużej komplikacji w wykonywaniu zapytań, należy więc zachować „zdrowy” umiar przy jej aplikowaniu. Złota zasada normalizacji mówi, że jeżeli jakaś grupa tekstów pojawia się w różnych miejscach bazy danych w tym samym kontekście, prawdopodobnie należy ją wydzielić do osobnej tabeli i zaopatrzyć w unikalne identyfikatory numeryczne.

denormalizacja (ang. denormalization): operacja odwrotna do normalizacji. W niektórych, szczególnych przypadkach denormalizacja może poprawić wydajność wykonywania zapytań, a także upraszcza „konsumowanie” danych przez użytkowników końcowych. Podobnie jak z normalizacją, denormalizację należy wykonywać „z głową” aby uniknąć ryzyka uszkodzenia spójności danych w bazie.

W kolejnym odcinku (za tydzień) omówimy sobie bardziej szczegółowo kwestie związane z planowaniem i definiowaniem wymiarów w hurtowni danych. Będzie to zarazem ostatni wpis „opisowy” – później zanurzymy się już w konkretnych przykładach i scenariuszach.

Autor: xpil

Po czterdziestce. Żonaty. Dzieciaty. Komputerowiec. Krwiodawca. Emigrant. Rusofil. Lemofil. Sarkastyczny. Uparty. Mól książkowy. Ateista. Apolityczny. Nie oglądam TV. Uwielbiam matematykę. Walę prosto z mostu. Gram na paru instrumentach. Lubię planszówki. Słucham bluesa, poezji śpiewanej i kapel a’capella. || Kliknij tutaj po więcej szczegółów ||

Dodaj komentarz

1 Komentarz do "EDW #2: Słowniczek"

Powiadom o
avatar
Sortuj wg:   najnowszy | najstarszy | oceniany
kwas007
Gość

bardzo się podoba;) czekam na kolejne wpisy

wpDiscuz