Przewodnik po ekonomicznej eksploracji danych

W przeciwieństwie do tradycyjnego programowania aplikacji, w którym funkcje API zmieniają się każdego dnia, programowanie baz danych zasadniczo pozostaje takie samo. Pierwsza wersja Microsoft Visual Studio .NET została wydana w lutym 2002 roku, a nowa wersja była wydawana mniej więcej co dwa lata, nie licząc wydań Service Pack. To szybkie tempo zmian zmusza personel IT do oceny aplikacji firmowych co kilka lat, pozostawiając funkcjonalność aplikacji nienaruszoną, ale z zupełnie innym kodem źródłowym, aby być na bieżąco z najnowszymi technikami i technologią.

Tego samego nie można powiedzieć o kodzie źródłowym bazy danych. Standardowe zapytanie SELECT / FROM / WHERE / GROUP BY , napisane w początkach SQL, działa do dziś. Oczywiście nie oznacza to, że nie było żadnych postępów w programowaniu relacyjnych baz danych; były i były bardziej logiczne niż techniczne .

Począwszy od czasów, kiedy Bill Inmon i Ralph Kimball opublikowali swoje teorie dotyczące projektowania hurtowni danych, postępy w programowaniu baz danych koncentrowały się na zapobieganiu utracie cennych informacji i wydobywaniu z nich wszystkich cennych informacji. Gdy Inmon i Kimball wprowadzili świat baz danych do hurtowni danych, wprowadzono poważne zmiany w narzędziach ETL (Extract/Transform/Load), które zapewniły twórcom baz danych łatwy dostęp do metadanych oraz danych z nierelacyjnych źródeł baz danych, z którymi trudno było pracować w przeszłości. Zwiększyło to ilość dostępnych danych, z których można wydobyć cenne informacje, a ten wzrost dostępnych danych doprowadził do postępu w przetwarzaniu danych za pomocą kostek OLAP i algorytmów eksploracji danych.

Dodanie hurtowni danych, kostek OLAP i algorytmów eksploracji danych do architektury bazy danych może radykalnie usprawnić procesy biznesowe i uwydatnić wzorce w danych, o których istnieniu nigdy by się nie dowiedziało. Automatyzacja może również mieć ogromny wpływ na możliwości analizy biznesowej.

Zanim jednak zaczniesz dodawać nowe narzędzia i technologie, powinieneś upewnić się, że baza danych transakcji jest poprawnie zbudowana.

Baza danych transakcji

Baza danych transakcji to podstawa, a jeśli Twoja baza danych transakcji nie jest wiarygodna i dokładna, dodanie czegokolwiek na wierzchu jest receptą na katastrofę.

Ważną kwestią, o której należy pamiętać podczas dodawania kolejnych warstw do bazy danych, jest to, że wszystkie projekty muszą wykazywać zwrot z inwestycji , dlatego najlepiej jest maksymalnie wykorzystać obecną architekturę przed dodaniem kolejnych warstw. Wszystkie te warstwy wykorzystują dane pochodzące z bazy danych transakcji. W wielu sytuacjach te same wyniki można uzyskać, wysyłając zapytanie do bazy danych transakcji. Oczywiście idealną metodą jest odczytywanie wszystkich raportów z hurtowni danych lub modułu OLAP, ale gdy organizacja nie jest gotowa na taki poziom złożoności, ważniejsze jest, aby w pierwszej kolejności zaspokoić jej potrzeby w zakresie raportowania. Po zaspokojeniu podstawowych potrzeb raportowania znacznie łatwiej jest rozpocząć dyskusję na temat tego, w jaki sposób odpowiednia hurtownia danych i ewentualnie kostka OLAP mogą przynieść korzyści firmie.

Niemal każdy programista zna trzy zasady normalizacji bazy danych. Ścieżką do optymalizacji są procedury składowane odczytujące z bazy danych transakcji. Problemy, których należy szukać, to czytelność, wielokrotne wywołania tej samej tabeli bazy danych i niepotrzebne użycie zmiennych.

Wszyscy elitarni programiści baz danych są wybredni, jeśli chodzi o czytelność swoich procedur składowanych. Istnieje kilka cech wspólnych w sposobie formatowania zapytań przez specjalistów ds. baz danych, który różni się od sposobu, w jaki deweloperzy aplikacji. Zazwyczaj słowa kluczowe i funkcje agregujące są pisane wielkimi literami, podczas gdy nazwy tabel i pól używają albo wielkich liter, albo podkreśleń. Aliasy tabel mają pewną korelację z rzeczywistą nazwą tabeli. Wyrównanie sekcji procedury składowanej ma pewien typ wzorca blokowego.

Poniżej znajduje się przykład zapytania wykorzystującego czytelny format.

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

Następną rzeczą, na którą należy zwrócić uwagę, jest to, że zapytanie trafia do tabeli więcej niż raz. W większości zapytań dostęp do tabeli jest potrzebny tylko raz, z wyjątkiem rzadkich przypadków, gdy trzeba agregować inną funkcję agregującą. To kolejny błąd, który popełniają niektórzy programiści aplikacji, być może dlatego, że programista aplikacji myśli w kategoriach projektowania zorientowanego obiektowo.

Projekt zorientowany obiektowo tworzy oddzielne obiekty dla każdego unikalnego elementu danych, ale programista baz danych musi myśleć w kategoriach logiki zestawów. Tylko dlatego, że zapytanie uzyskuje dostęp do tabeli więcej razy, niż jest to potrzebne, nie oznacza, że ​​zapytanie generuje niedokładne dane, jednak ma to wpływ na wydajność zapytania.

Innym problemem jest odrzucanie lub duplikowanie rekordów za każdym razem, gdy masz sprzężenie, co obniża dokładność zapytania. Niepotrzebne użycie zmiennych to kolejny znak, że zapytanie zostało opracowane przez programistę aplikacji. Deweloperzy aplikacji używają zmiennych w całym swoim kodzie, podczas gdy zapytanie bardzo rzadko wymaga użycia zmiennych, z wyjątkiem sytuacji, gdy są zadeklarowane jako parametr procedury składowanej. Po raz kolejny jest to znak, że deweloper nie myślał w kategoriach ustalonej logiki.

ETL (wyodrębnianie obciążenia transformacji) i raportowanie

Gdy baza danych transakcyjnych klienta zawiera poprawnie działające zapytania, kolejnym krokiem jest usprawnienie procesów biznesowych.

Najłatwiejszym sposobem zidentyfikowania zapotrzebowania firmy na procesy ETL lub automatyczne raportowanie jest sprawdzenie, kto odczytuje dane z bazy danych transakcji, a następnie manipuluje nimi za pomocą arkusza kalkulacyjnego. Arkusz kalkulacyjny ma taką samą strukturę jak tabela bazy danych. Oba zawierają wiersze i kolumny. Jeśli masz użytkowników końcowych, którzy samodzielnie manipulują danymi, powinieneś zadać sobie pytanie: „Dlaczego tego procesu nie można zautomatyzować?”

Automatyzacja procesów biznesowych zapewnia natychmiastowy zwrot z inwestycji i należy ją zawsze rozważyć przed przejściem do droższych projektów, takich jak hurtownie danych. Identyfikacja użytkowników końcowych manipulujących danymi za pomocą arkusza kalkulacyjnego może wydawać się prosta, ale istnieje pewne zastrzeżenie tego procesu.

Deweloperzy lubią automatyzować procesy; to właśnie robią. Użytkownicy końcowi niekoniecznie lubią zautomatyzowane procesy, zwłaszcza jeśli zagrażają ich pracy. Nie bądź więc naiwny i nie myśl, że użytkownicy końcowi podbiegną do Ciebie i zidentyfikują codzienne zadania, które można zautomatyzować. Naprawdę musisz przejąć inicjatywę w identyfikowaniu możliwości usprawnienia.

Dobrze zbudowany system ETL powinien również zapewniać możliwość cofnięcia wszystkich danych załadowanych do bazy danych transakcji z powrotem do oryginalnego pliku źródłowego. Jest to kluczowy element architektury bazy danych. Jeśli nie znasz dokładnej daty/godziny dodania każdego rekordu, wraz z nazwą źródła (nazwą użytkownika lub nazwą pliku), które dodało rekordy, to nie jesteś przygotowany do obsługi złych danych załadowanych do bazy danych transakcji. Powinieneś zadać sobie pytanie: „A co, jeśli ktoś wyśle ​​nam zły plik?” Jak długo zajęłoby ci zidentyfikowanie rekordów, które z niego pochodziły?

Hurtownia danych

Istnieją dwie teorie projektowania hurtowni danych. Różnicę między teoriami Inmona i Kimballa można podsumować w następujący sposób:

Teoria Inmona zakłada najpierw opracowanie hurtowni danych, a następnie zbudowanie wielowymiarowych baz danych do raportowania z hurtowni danych. Teoria Kimballa polega na tym, aby najpierw opracować wielowymiarowe bazy danych do raportowania, a następnie połączyć je w celu stworzenia hurtowni danych.

Zawsze chcesz zapewnić klientom najszybszy zwrot z inwestycji. Tworzenie baz danych to prosty proces. Zaczynasz od przejęcia zapytań znajdujących się w raportach i zmiany ich z zwracania zestawów wyników na przechowywanie zestawów wyników w stałych tabelach. Wystarczy dodać TRUNCATE TABLE ; INSERT INTO nazwa tabeli przed oryginalnym słowem kluczowym SELECT . Gdy masz kilka funkcjonalnych tabel zbiorczych danych, identyfikacja możliwości scalenia zbiorczych zbiorczych danych powinna znaleźć się we właściwym miejscu; wyszukaj zapytania raportu, które używają tej samej listy tabel, a następnie scal listę pól. Wymaga to bardziej skomplikowanego zapytania, zwłaszcza gdy lista tabel rośnie. Jednak dopóki dokładnie testujesz zapytanie, każda przyrostowa zmiana może zostać wprowadzona bez zakłócania normalnych procesów biznesowych.

Za każdym razem, gdy wprowadzasz ulepszenie w projekcie hurtowni danych Kimball, masz możliwość pokazania klientowi zwrotu z inwestycji. Dzieje się tak, ponieważ hurtownia danych jest budowana jako pierwsza, a zbiorcze bazy danych raportowania są budowane na podstawie statycznej hurtowni danych. Dlatego większość kosztów ponosisz na początku projektu hurtowni danych.

Kostka OLAP

Kostka OLAP może przynieść korzyści organizacji, zapewniając zagregowane dane z szybkim czasem odpowiedzi, możliwościami doraźnego drążenia dla użytkowników końcowych i eksploracji danych. Kiedy masz odpowiednią kostkę OLAP, możesz wydobyć z danych każdy bit wartości. Kostka OLAP jest zbudowana na bazie hurtowni danych, ale używa innego języka, MDX, niż standardowa baza danych SQL. Wymaga również bardziej zaangażowanych prac konfiguracyjnych niż serwer bazy danych. Ta złożoność sprawia, że ​​projekt OLAP jest kosztowny, a ponadto trudno jest znaleźć doświadczonych programistów MDX.

Architekci danych czasami widzą istniejące kostki OLAP z prostym pulpitem nawigacyjnym wykorzystującym kostkę, bez pojedynczego procesu, którego nie można zastąpić zapytaniem SQL, hurtownią danych lub raportem standardowym. Kostka OLAP może zapewnić szybszy czas odpowiedzi niż gotowy raport, ale w większości sytuacji różnica jest znikoma. Można również skorzystać z funkcji drążenia, jednak przed udostępnieniem użytkownikom funkcji drążenia warto skorzystać z raportów w formie gotowej, które zapewniają podobny interfejs ad hoc.

Umożliwia to rejestrowanie zapytań ad hoc uruchamianych przez użytkowników końcowych, a następnie identyfikowanie nowych raportów w formie gotowej, o których użytkownicy końcowi nie zdawali sobie sprawy. Ponieważ zarówno czas odpowiedzi, jak i ulepszenia w zakresie drążenia są zwykle minimalne podczas opracowywania kostki OLAP, nie ma potrzeby sugerować tego klientowi, dopóki nie potrzebuje architektury bazy danych, która może obsłużyć zaangażowaną eksplorację danych. To wtedy możesz naprawdę zaimponować klientom i pokazać im coś o ich działalności, czego mogliby nigdy nie wiedzieć bez solidnej architektury bazy danych.

Jak wspomniano wcześniej, zbudowanie kostki OLAP może być wyzwaniem. Dobrą zasadą jest rozważenie hybrydowej kostki OLAP. PowerPivot programu Microsoft Excel zapewnia łatwe w użyciu narzędzia do eksploracji danych bez złożoności pełnej kostki OLAP. Główną wadą hybrydy jest to, że nie ma ona takiego samego czasu odpowiedzi. Dużą zaletą jest jednak to, że łatwiej jest tworzyć raporty eksploracji danych za pomocą programu Excel w porównaniu z MDX. Podczas eksploracji danych przydatne są trzy raporty. Możemy spojrzeć na kilka przykładów ze świata rzeczywistego i jak je zinterpretować.

Wszystkie te raporty pochodzą z automatycznej aplikacji do handlu dziennego stworzonej przez autora.

Raporty wizualne

Raport wykresu punktowego

Raport z wykresami punktowymi to raport na poziomie szczegółowości, który porównuje dwie zmienne. Dodanie koloru i rozmiaru do rzeczywistych kropek pomaga zwizualizować rzeczywiste wyniki w odniesieniu do tych zmiennych.

Raport Pudełka i Wąsów

Ten raport podsumowuje wartości x i y z raportu wykresu punktowego. Wartości osi x są dyskretyzowane w zestawie kubełków.

Końce każdego wąsu (linia) reprezentują wartości odstające. Żółte i jasnoniebieskie słupki reprezentują górny i dolny zakres odchylenia standardowego.

Model regresji liniowej

Ten raport pokazuje korelację między wartościami osi x i y wraz z wygładzeniem linii, którą można przedstawić za pomocą wzoru matematycznego. Uwzględniono wartość R-kwadrat, aby pokazać, jak wiarygodna jest korelacja.

Wniosek

Wraz z rozwojem Twojej firmy, zwykle rośnie również Twoja baza danych.

Większość organizacji początkowo nie potrzebuje specjalisty ds. baz danych ani wyspecjalizowanej firmy zajmującej się badaniem danych, która odpowiadałaby na ich potrzeby. Zamiast tego pracownicy IT zajmują się wieloma obowiązkami lub, jak to się mówi, „noszą wiele kapeluszy”. To działa do pewnego momentu, ale w końcu trzeba sprowadzić specjalistów.

Pozycje wymienione w tym dokumencie to szybki i łatwy sposób na zidentyfikowanie problemów z bazą danych, o których być może nie wiedziałeś. Mamy nadzieję, że omówiono również, w jaki sposób można zbudować najwyższej klasy narzędzia do eksploracji danych bez wydawania dużych pieniędzy na drogie licencje na oprogramowanie. W ten sposób uzyskasz lepsze wyobrażenie o tym, jakie korzyści może przynieść Twojej organizacji dodanie specjalisty ds. baz danych do personelu IT.