Business Intelligence

01.09.2021

Ewolucja

Analiza biznesowa to coś więcej niż zestaw współpracujących ze sobą aplikacji, to sposób na życie firmy, a narzędzia, które wprowadzisz, aby w ten sposób służyć, z czasem nieuchronnie się zmienią. W niektórych dziedzinach nazywa się to planowanym starzeniem się, ale ja wolę nazywać to planowaną ewolucją. Prawdopodobnie będziesz mieć kilka zintegrowanych narzędzi współpracujących ze sobą, aby dostarczać wglądy biznesowe użytkownikom BI. Tak jak części samochodu ulegają zużyciu lub muszą z czasem zostać wymienione, będziesz musiał zaplanować wymianę lub modernizację poszczególnych komponentów BI. Musisz rozważyć zalety i wady mniejszych zakłóceń związanych z wymianą części na części w porównaniu z przeprowadzaniem przeglądu od góry do dołu całego systemu naraz. Może istnieć wiele powodów, dla których nadszedł czas na zmianę jednego z komponentów systemu:

•  Zmiana potrzeb użytkownika. To jest oczywiste. Twój system nie może zrobić tego, czego potrzebujesz. Być może na rynku pojawił się nowy produkt, który wzbudził Twoje zainteresowanie, a może zmieniły się wymagania dotyczące wydajności. Tak czy inaczej, czas na aktualizację.
•  Zmieniają się standardy oprogramowania. W tym przypadku nie chodzi o to, że to, czego używasz, nie działa, po prostu jest to niezgodne z przyszłym stanem systemu.
•  Zewnętrzna zgodność wymaga zmiany. Może jest jakiś zewnętrzny sprzedawca?
•  Dostępna jest aktualizacja.
•  Funkcjonalność można łączyć. Zawsze istnieje szansa, że dzięki ujednoliceniu aplikacji można uzyskać większą wydajność. Pamiętaj, że każde oprogramowanie, które obsługuje informacje, jest potencjalnym słabym ogniwem w łańcuchu - i to samo dotyczy uścisków dłoni między komponentami. Umieszczenie dwóch lub więcej funkcji pod jednym dachem może ułatwić administrację i poprawić wydajność.

Jedno pytanie

To, czy jakiś program lub dana funkcja pasuje do twoich długoterminowych planów, czy nie, jest z pewnością kwestią do rozważenia. Ale w istocie musisz zadać sobie jedno podstawowe pytanie:

Czy dostarcza wartości dzisiaj?

Niektóre elementy Twojej architektury mogą być ślepymi zaułkami, może pojawić się planowana przestarzałość lub długoterminowa użyteczność komponentu może zostać przesłonięta przez dziwną, mglistą przyszłość. W porządku - o ile ten kawałek zapewnia teraz wartość.

Jazda terenowa

Zbuduj swój system zgodnie z długoterminowym planem. Oznacza to, że ulepszenia i ulepszenia powinny następować zgodnie z harmonogramem, zgodnie z planem i tak, jak pojawiają się na mapie drogowej. Ale czasami jest jasne, że zdarzenia zewnętrzne doprowadzą do zmiany warunków biznesowych - a to prowadzi do zmiany potrzeb systemu BI. W przypadku dużych wydarzeń korporacyjnych - takich jak reorganizacje, wykupy lub zmiany na szczycie firmy - musisz wiedzieć, kiedy nadszedł czas, aby zjechać z chodnika i zostawić swoją mapę drogową za sobą.
Powrót

02.09.2021

Bazy danych docelowych BI: hurtownie danych, sklepy i sklepy

Dane - informacje, które określają ilościowo i opisują działania Twojej organizacji - są źródłem wszelkich spostrzeżeń biznesowych pochodzących z Twojego środowiska BI. Jednym z najważniejszych kroków w całym procesie jest opracowanie rozsądnej strategii poszukiwania go, czyszczenia, porządkowania, zatrzymywania i przyjmowania użytecznej postawy. Aby użytkownicy - za pomocą używanego oprogramowania - mieli łatwy dostęp do Twoich danych, musisz umieścić je w docelowym środowisku danych. Po ustawieniu tego ustawienia (które może przybierać różne formy) dane są dostępne dla aplikacji użytkowników BI, które mogą je gromadzić i wykorzystywać do tworzenia kluczowych strategicznych i operacyjnych wglądów, które sprawiają, że cały wysiłek BI jest opłacalny. Docelowa baza danych BI, bez względu na jej formę, musi być zoptymalizowana pod kątem procedur "wyprowadzania danych" - zapytań, które zasilają narzędzia do raportowania i analizy. Docelowa baza danych musi być zbudowana tak, aby wytrzymać obciążenia charakterystyczne dla użycia BI. Zwykle docelowa baza danych BI jest nastawiona na przechowywanie ogromnych ilości danych historycznych na wszystkich poziomach podsumowania i agregacji. Ponadto docelowa baza danych BI może być zaprojektowana tak, aby zasilać różnorodną gamę dużych, złożonych zapytań i raportów - oprócz zasilania zaawansowanych narzędzi analitycznych. W tym rozdziale omówiono najpopularniejsze docelowe środowiska danych BI: hurtownie danych, hurtownie danych, operacyjne magazyny danych i modele hybrydowe. Idąc dalej, zastanawiamy się nad tymi ważnymi pytaniami:

•  Gdzie znajdują się aktualnie potrzebne nam dane?
•  Jak na świecie mamy to wszystko zebrać?
•  Jakie wysiłki należy włożyć w jego utrzymanie i oczyszczenie?
•  Jak możemy upewnić się, że dane są ustandaryzowane, więc mamy do czynienia z porównaniami jabłek do jabłek?
•  Jak powinniśmy uporządkować dane, aby jak najlepiej obsługiwać konkretną gamę wdrożonych aplikacji skierowanych do użytkowników?
•  Gdzie i jak będziemy przechowywać dane? Musimy podejmować decyzje dotyczące architektury pamięci masowej, protokołów i standardów.

Istnieją strategie wdrożeniowe, które pasują do każdego rodzaju środowiska. Jeśli jesteś zaangażowany w implementację BI, to, czego szukasz, jest dość znajome: aktualne, dokładne, wartościowe i dające się wykorzystać spostrzeżenia. Odpowiedzi na te pytania pomogą określić, która architektura danych jest najlepszym sposobem na osiągnięcie tego celu.
Powrót

03.09.2021

Hurtownie danych i BI

BI opiera się na założeniu, że ważne dane operacyjne - rzeczy, na które naprawdę trzeba patrzeć - są przechowywane na różnych platformach i lokalizacjach w firmie. Zebranie tych informacji pod jednym parasolem jest zwykle nazywane hurtownią danych. Konkretne definicje mogą się różnić w zależności od dostawców i ekspertów, ale ogólnie hurtownia danych to system przechowywania danych zaprojektowany i zbudowany w celu wspólnego gromadzenia historycznych danych operacyjnych - w celu tworzenia na ich podstawie raportów i analiz. Wykonywanie tych zadań na operacyjnych bazach danych byłoby skomplikowane i kosztowne, nie mówiąc już o tym, że może spowolnić działalność firmy do indeksowania. Hurtownia danych to sposób na oddzielenie operacji od raportowania i analizy. Hurtownia danych niekoniecznie oznacza jedną bazę danych pełną danych gotowych do raportowania i analizy. Czasami bardziej sensowne jest zebranie danych w kilku powiązanych systemach niż w jednym dużym systemie. Hurtownie danych są często projektowane w celu wypełnienia luki w wielu obszarach funkcjonalnych organizacji, łącząc w użyteczny sposób powiązane dane historyczne. Działy finansowo-księgowe (np.) mogą korzystać z jednego systemu przechowywania danych, natomiast działy HR i sprzedaży korzystają z własnych mechanizmów gromadzenia danych. Wiele obiektów i bryłek informacji zawartych w tych różnych systemach będzie takich samych. Hurtownia danych zapewnia logiczne - iw większości przypadków fizyczne - łącze, które łączy te obiekty razem przez linie departamentalne (lub nawet stanowe). Jednym z powodów utworzenia hurtowni danych jest to, że tworzy ona elastyczne środowisko, z którego można przeprowadzać analizę przedsiębiorstwa w całej firmie. Deweloperzy, analitycy baz danych i menedżerowie mogą tworzyć bardziej złożone zapytania, raporty i przeprowadzać analizy o wyższej wartości, gdy wszystkie informacje firmy znajdują się pod jednym dachem, niż byliby w stanie, gdyby pozostały odizolowane w obrębie każdej jednostki biznesowej lub zespołu. Gdy ktoś zadaje nowe pytanie dotyczące firmy, informacje potrzebne do udzielenia odpowiedzi są już dostępne w magazynie; nie ma potrzeby ponownego wyszukiwania i integrowania danych. Gdy wszystkie dane znajdują się w jednym miejscu, programiści mogą wykonywać bardziej wartościową pracę, zamiast tworzyć tabele jednorazowego użytku dla każdego zapytania biznesowego. Uwaga dotycząca terminologii jest prawdopodobnie uzasadniona tutaj. Niektóre władze nadają terminowi "repozytorium danych" bardziej szczegółowe znaczenie niż w tej książce; tutaj jest używany jako ogólny termin dla każdego miejsca, które przechowuje dane. W niektórych kręgach repozytorium danych jest uważane za aktywny system operacyjny, ale hurtownia danych to magazyn historycznych informacji biznesowych (to bardziej stabilna i powszechna definicja). Tak więc zwykłe rozróżnienie wygląda tak:

•  Hurtownia danych reprezentuje wszystkie zdarzenia transakcyjne, które składają się na przeszłość, na których firma macierzysta wykonuje czynności tylko do odczytu, takie jak sporządzanie raportów i analiz statystycznych.
•  Repozytorium danych to migawka teraźniejszości (i być może niedawnej przeszłości); systemy transakcyjne firmy regularnie aktualizują dane w repozytorium dla określonych zadań taktycznych wspierających podejmowanie decyzji.
Powrót

04.09.2021

Rozszerzony przykład

Czasami pełny przykład może pomóc w poprawie sytuacji biznesowej.

Wheels Automotive, Inc.

Wyobraź sobie, że Wheels Automotive to salon samochodowy, który sprzedaje publicznie nowe i używane samochody. Jesteś dyrektorem generalnym Wheels; potrzebujesz lepszego zrozumienia zachowań klientów, mając nadzieję, że uda Ci się zidentyfikować najbardziej dochodowych klientów i opracować nowe strategie sprzedaży i marketingu. Pytasz swój dział IT o listę klientów - a kiedy odpowiadają, pytając "która lista?" Przy kilku równoległych systemach w Wheels zawierających dane o klientach i sprzedaży trudno jest odpowiedzieć na pozornie proste pytania. Wyobraźmy sobie, że fikcyjny dealer, podobnie jak większość firm w prawdziwym świecie, ewoluował w swojej 20-letniej historii - najpierw oferował tylko sprzedaż nowych samochodów, ale ostatecznie rozszerzył się na samochody używane, części, serwis i finansowanie motoryzacyjne. Wraz z dodawaniem każdej nowej linii biznesowej firma dodawała nowe systemy informatyczne, które ją wspierają. Oprócz tego sprzedawcy korzystają ze wspólnej bazy danych Microsoft Access, aby śledzić perspektywy sprzedaży, gdy wchodzą do salonu lub dzwonią, aby wyrazić zainteresowanie zakupem samochodu. Działają niezależnie od siebie, na różnych platformach. Wiele takich samych informacji pojawia się w więcej niż jednym systemie; na przykład prawie każda baza danych zawiera informacje o klientach z tej branży. Ale żadna pojedyncza baza danych nie ma pełnego obrazu klienta. Jeśli chciałbyś zobaczyć listę całej historii transakcji klienta za pomocą Wheels, musiałbyś uruchomić kilka różnych raportów (jeden lub więcej w każdym systemie), a następnie ręcznie połączyć wyniki. Wdrożenie hurtowni danych w Wheels wymagałoby przechowywania informacji operacyjnych przechowywanych w sześciu systemach operacyjnych dealera w jednym miejscu, w ujednoliconym formacie, tworząc jeden historyczny zapis historii biznesowej firmy. To dałoby pracownikom Wheels jeden widok działań w całej firmie, z których mogą pracować, aby wykonywać zadania raportowania i analizy. Rysunek 16-2 przedstawia pożądaną konfigurację hurtowni danych Wheels Automotive: Każda oddzielna baza danych wprowadza odpowiednie informacje o klientach i sprzedaży do centralnej hurtowni danych. Przenosząc dane z różnych domów do jednego repozytorium, osiągnęliśmy jeden widok bazy klientów. Teraz, zamiast zmuszać nas do przeglądania sześciu różnych systemów, hurtownia danych pokazuje każdą interakcję z konkretnym klientem, wykonując jedno zapytanie lub kompilując jeden raport. Teraz, jeśli wyszukasz danego klienta Wheels Automotive, aplikacja uzyska dostęp do hurtowni danych, aby wyświetlić informacje o profilu klienta wraz z listą wszystkich transakcji sprzedaży z udziałem tego klienta niezależnie od działu. To, co widzisz na rysunku 16-3, jest uproszczoną wersją rzeczywistych danych, które pojawiają się i są przechowywane w hurtowni danych. Aby utrzymać złożoność na dystans podczas wyjaśniania pojęć, musiałem wydestylować informacje o kliencie i sprzedaży do podstawowego formatu. Prawdziwy salon samochodowy śledziłby szczegółowe informacje o kliencie (jak każda firma) - na przykład adres e-mail, telefon, dane ze spisu ludności, preferencje i inne szczegóły, oprócz adresu pocztowego. Transakcje sprzedaży zawierałyby również znacznie wyższy poziom szczegółowości. Ale nawet bez wszystkich szczegółów użyteczność skonsolidowanego widoku klienta powinna być jasna:

•  Pozwala handlowcom na podejmowanie lepszych decyzji operacyjnych, gdy klient wchodzi do drzwi.
•  Przechowując go w hurtowni danych dostosowanej do celów raportowania, menedżerowie mogą tworzyć znaczące raporty dotyczące klientów i sprzedaży w ułamku czasu, który zajęłoby, gdyby ktoś próbował połączyć sześć systemów operacyjnych w tym samym celu.
Powrót

05.09.2021

Wyzwanie ujednolicenia danych

Hurtownia danych brzmi dobrze w teorii, ale w praktyce jest trochę trudniej. Dla każdej żywej osoby, która kiedykolwiek zawierała transakcje z Wheels Automotive, chcesz wyeliminować powielanie i przechowywać jeden rekord klienta. Tak więc część budowania hurtowni danych obejmuje identyfikację sytuacji, w których ta jedna osoba jest przechowywana w więcej niż jednym systemie operacyjnym. Aby osiągnąć unifikację w hurtowni danych Wheels, musisz porównać rekordy klientów w każdej bazie danych, łącząc te, w przypadku których masz pewność, że zduplikowane dane dotyczą jednej osoby. Na początek musisz posortować rekordy na kategorie:

•  Co najmniej dwa identyczne rekordy, w których każde z pól danych jest dokładnie takie samo i prawdopodobnie odnosi się do jednego klienta.
•  Zapisy, w których można zgadywać (lub zastosować określone zasady, aby dojść do wniosku), że dotyczą tego samego klienta.
•  Rekordy, które mają kilka cech i mogą być takie same, ale nie możesz być pewien bez dalszego zbadania.

Identyczne rekordy można traktować jako jedną osobę, ale zasady biznesowe muszą być przemyślane, a następnie zaimplementowane w celu obsługi rekordów, które nie są idealnie dopasowane. To ćwiczenie jest przykładem tego, co musi zrobić zespół projektowy hurtowni danych, gdy implementuje pojedyncze repozytorium danych klientów. Jeśli istnieje 100 000 zduplikowanych nazw, Twój zespół IT będzie musiał zaprogramować system zgodnie z zasadami ich łączenia, ponieważ ręczne łączenie rekordów byłoby zbyt czasochłonne. Zauważ, że w tej samej bazie danych znajdują się dwa rekordy, które wydają się odnosić do tego samego klienta: Geralda Z. Juareza. Nazwisko osoby jest na tyle unikatowe, że można wyciągnąć taki wniosek, ale jak zaprogramować komputer, aby dokonywał takiego osądu? Różne adresy mogą po prostu oznaczać, że klient przeniósł się między wizytami w Wheels Automotive, że pan Juarez ma dwa ważne adresy lub że rzeczywiście jest dwóch klientów, z których każdy nazywa się Gerald Z. Juarez. W jaki sposób dane są tak mylone w jednym małym salonie samochodowym? Może się to zdarzyć na wiele sposobów. Wheels Automotive mógł zakupić firmę zajmującą się używanymi samochodami na ulicy i odziedziczyć jej system sprzedaży. Ponieważ potrzeby biznesowe ewoluowały w czasie, a nowe systemy były instalowane lub aktualizowane, prawdopodobnie programiści po prostu przedefiniowali dane dla każdego kolejnego systemu. Na przykład, kiedy Wheels rozgałęził się w branży motoryzacyjno-finansowej, miał dostawcę i zbudował system wsparcia od podstaw, ignorując istniejącą bazę danych. Wkrótce systemy są całkowicie rozdrobnione i niemożliwe do połączenia. Gdy zastanowisz się, jak duże przedsiębiorstwo staje przed podobnymi wyborami przy jeszcze większych ilościach danych, zaczynasz dostrzegać wartość koncepcji hurtowni danych - i wyzwania związane z jej wdrożeniem. A jeśli nadal nie jesteś przekonany, to, co do tej pory sprawdziliśmy, jest najprostszym rodzajem problemu standaryzacji danych. Pomyśl o tym, jak skomplikowane może się to stać w przypadku wymiernych informacji (np. dane dotyczące sprzedaży i finansów), gdy dwa różne systemy mierzą to samo w różny sposób - lub gdy łączą się dwie całe firmy, z których każda ma zupełnie inne standardy danych, definicje i schematy klasyfikacji produktów i dane sprzedażowe. Ogromna złożoność sporów dotyczących danych korporacyjnych powoduje, że dziedzina analizy danych tak gwałtownie się rozrosła. Jeśli wyciskanie spostrzeżeń z danych historycznych jest ważne, potrzebujesz kogoś z zespołu, który dokładnie wie, jak najlepiej wykorzystać rozbieżne dane operacyjne. A ponieważ BI jest środowiskiem wyrzucania śmieci, prawidłowe łączenie danych jest niezbędnym krokiem przychodzącym, aby zapewnić, że wyniki wychodzące są (wszystkich) dokładne, terminowe, wartościowe i wykonalne.
Powrót

06.09.2021

Działania w zakresie analizy danych

Przekopywanie się przez dane z każdego indywidualnego systemu źródłowego w celu zrozumienia, jakie informacje zawierają oraz w jaki sposób są przechowywane i prezentowane, jest głównym zadaniem projektowym związanym z budowaniem hurtowni danych. To nie jest rodzaj analizy, którą wykonasz na końcu łańcucha BI, gdzie cenne spostrzeżenia zaczynają wypływać z oprogramowania front-endowego. Ta analiza to krok poprzedzający integrację danych - standaryzacja i integracja danych pochodzących od różnych systemów źródłowych. W każdym schemacie, który obejmuje centralny punkt gromadzenia danych, zawsze istnieje ryzyko, że właściciele danych źródłowych odczują dotkliwą utratę kontroli i mogą stawiać opór przed badaniem, jeśli nie wręcz wrogość na myśl o zmianach w ich systemie . W tym przypadku warto mieć silne zarządzanie danymi w organizacji - centralny organ, który działa (przynajmniej teoretycznie) jako centralny zarządca danych. Przy wdrożonym zarządzaniu danymi wszyscy w firmie muszą podporządkować się życzeniom organu centralnego, grupy (lub osoby lub zestawu standardów) dbającej o najlepszy interes firmy jako całości, a nie jednego zespołu lub jednostki biznesowej . Aby przeprowadzić integrację danych, analitycy i architekci muszą uzgadniać dane z różnych silosów operacyjnych firmy, podejmować decyzje biznesowe, jak najlepiej scalić te dane, a następnie skodyfikować te decyzje w twarde i szybkie reguły, które można zastosować do hurtowni danych aby zapewnić ujednolicony widok ważnych obiektów biznesowych, takich jak transakcje sprzedaży, klienci, dostawcy i prawie wszystko, co znajduje się pod słońcem. Integracja danych podstawowych firmy często obejmuje technologie centralne, które mogą uzyskiwać dostęp do danych podstawowych, czyścić, standaryzować, dopasowywać, integrować i propagować. Znajomość zarządzania danymi podstawowymi, opcji dostawców i obsługujących je architektur jest niezbędna do umożliwienia integracji danych klientów (CDI). Celem jest tutaj opracowanie strategii zarządzania danymi, dzięki której odpowiednia wiedza trafi w ręce właściwych osób. Trzeba to zrobić w sposób bezpieczny i terminowy. Aha, a ludzie, którzy otrzymują te dane, muszą wiedzieć, co z nimi zrobić, kiedy dostaną je w swoje ręce. Teoretycznie ich decyzje będą lepsze z pełniejszą wizją "prawdy" (cokolwiek by to nie było).
Powrót

07.09.2021

Profilowanie danych

Przed zaprojektowaniem planu konsolidacji zbierz profil danych każdego systemu źródłowego. Zwykle obejmuje to opis odpowiednich struktur tabel, definicji każdego pola i niektórych właściwości statystycznych danych (takich jak liczba rekordów, zakres wartości znalezionych w każdym polu i inne metryki używane przez projektantów hurtowni danych do opracowanie procesu normalizacji). Wspólne informacje o profilu danych obejmują następujące cechy jako punkt wyjścia do katalogowania danych:

•  Nazwa i opis: Każdy element w każdej tabeli powinien mieć unikalną nazwę w profilu danych, która odnosi się do określonej nazwy pola używanej w kodzie systemu. Profil danych będzie również zawierał definicję funkcji i roli danych - w języku nietechnicznym, jeśli jest to możliwe i stosowne.
•  Typ danych i zasady walidacji: Każda wartość pola musi być zgodna z określonymi wzorcami i należeć do ogólnej domeny informacji. Na przykład pole NAZWA_F, które zawiera imię osoby, będzie polem tekstowym z określonym limitem znaków.
•  Własność i pochodzenie: Wszystkie pola danych należą do pewnej hierarchii, która prowadzi w górę przez strukturę tabeli, bazę danych i aplikację pochodzenia. Kluczową informacją jest tutaj zrozumienie, kto ustala politykę dotyczącą sposobu obsługi danych na poziomie operacyjnym - czy to pojedynczy kierownik, czy komitet zarządzający.
•  Relacje i reguły biznesowe: Ta ważna informacja zawiera informacje o tym, jak pola danych i tabele są ze sobą powiązane w kontekście biznesowym oraz jakie zasady wpływają na ich wartości.

Istnieje więcej informacji, które można przechwycić, takie jak fizyczna lokalizacja danych, zasady bezpieczeństwa dotyczące informacji, szczegóły użytkowania i inne, które można wyświetlić na temat danych źródłowych. Ale nie ma gwarancji, że wszystko lub cokolwiek z nich będzie dostępne, więc analityk danych ma obowiązek zrobić wszystko, co w jego mocy. W przypadku dużego systemu z kilkoma operacyjnymi źródłami danych profilowanie i analizowanie danych może być ogromnym zadaniem. Ale jest to ważne dla udanego wysiłku hurtowni danych. Ta wiedza na temat istniejących danych operacyjnych będzie stanowić wskazówkę dla projektantów procesów transformacji i ładowania, które nastąpią później. Analitycy danych muszą wypełnić lukę między światem technicznym i biznesowym, gdy przechodzą przez proces integracji. Będą łączyć te dwie domeny razem z każdą podjętą decyzją. Na przykład, gdy integrowane są dwa rekordy klientów, analityk danych musi zbadać i zrozumieć, w jaki sposób pracownicy firmy wprowadzali dane klientów w przeszłości. Jaki proces przeszli? Czy istniały reguły biznesowe, które wpłynęły na rejestrowane przez nich informacje? Po pełnym zrozumieniu procesów w świecie rzeczywistym mogą określić specyfikę techniczną integracji zapisów. Te pytania nie są tak proste, jak mogą się początkowo wydawać. Czym właściwie jest klient? Jeśli ograniczysz go do odwiedzających Twój sklep lub witrynę, którzy dokonali co najmniej jednego zakupu w ciągu swojego życia, co stanie się z osobami wymienionymi jako potencjalni klienci, ale którzy nigdy nie dokonali zakupu? Co się stanie, jeśli dwa identyczne rekordy mają różne numery telefonów? W takim przypadku analityk danych musi ustalić, który z nich "przetrwa" (w takim przypadku analityk prawdopodobnie ustawiłby regułę, aby pobrać numer telefonu ostatnio edytowanego rekordu, zakładając, że informacje istnieją w systemie .) To są ważne pytania i mogą mieć daleko idące konsekwencje dla biznesu.
Powrót

08.09.2021

Strukturyzacja danych w celu umożliwienia BI

Jeśli analitycy danych wykonają dla Ciebie dobrą robotę, profil danych zapewni pełny obraz stanu danych pochodzenia systemu. Teraz nadszedł czas, aby uzyskać te dane w formacie, który będzie można wykorzystać w aplikacjach użytkowników BI. Nie możesz zrzucić wszystkich danych, które właśnie profilowałeś, do hurtowni danych, chcąc nie chcąc. Gdy już wiesz, z czym masz do czynienia w zakresie danych źródłowych, nadszedł czas, aby przejść przez etapy ich czyszczenia i uporządkowania, a następnie ustalić, jak i gdzie je przechowywać oraz w jakiej formie. Systemy skierowane do użytkownika, które opierają się na docelowym systemie danych, prawdopodobnie będą korzystać z kombinacji aplikacji do wysyłania zapytań i raportowania o dużym wpływie, pakietów statystycznych i ewentualnie oprogramowania do analizy i wizualizacji. Zamierzone zastosowania danych w rzeczywistości przejdą długą drogę do określenia, w jaki sposób należy uporządkować dane. Wiesz, skąd pochodzą dane i dobrze wiesz, jakie aplikacje będą miały do nich dostęp w interfejsie użytkownika. Wszystkie te aplikacje będą miały nieco inne potrzeby związane z zużyciem danych, ale należy pamiętać o kilku standardowych parametrach, jak opisano w nadchodzących sekcjach
Powrót

09.09.2021

Dane docelowe BI

Docelowa baza danych BI będzie musiała zostać zbudowana pod kątem jednokierunkowej wydajności, a nie wydajności pamięci masowej. Podczas gdy operacyjne bazy danych działają w celu normalizacji rekordów dla szybkich operacji odczytu/zapisu, hurtownia danych służy do przesyłania zapytań z narzędzi front-end. Poza sytuacjami, w których wprowadzane są do niego dane operacyjne, hurtownia danych jest dostawcą danych, a nie konsumentem danych. Użytkownicy BI będą prosić o informacje w formatach, które mają dla nich sens, logicznie wzorując się na samej firmie. Dlatego zamiast przechowywać dane w sposób, który wymaga skomplikowanych zapytań o dostęp, hurtownia danych przechowuje informacje o firmie w taki sam sposób, w jaki pracownicy wiedzy faktycznie myślą o firmie. Aby przeprowadzić zaawansowane analizy, użytkownicy będą myśleć w kategoriach znanych wydarzeń biznesowych i obiektów, z którymi czują się komfortowo: sprzedaży, produktów, klientów i sklepów. Użytkownicy nie będą myśleć o mylącej terminologii bazodanowej, takiej jak klucze podstawowe, odsyłacze lub skomplikowane instrukcje JOIN wymagane w zapytaniach SQL. Dane muszą być udostępniane osobom, które nie są ekspertami od baz danych.
Powrót

10.09.2021

Projektowanie hierarchii informacji

Kiedy myślisz o najważniejszych pomiarach do oceny za pomocą systemów front-end, prawdopodobnie skupisz się na serii prostych faktów i pomiarów. Dobrymi przykładami mogą być wskaźniki finansowe - takie jak sprzedaż lub marża brutto - lub wskaźniki wykorzystania zasobów, czas oczekiwania na centrum obsługi klienta lub inne wymierne wskaźniki, które Twoja firma próbuje zoptymalizować. Przechowywanie danych w kategoriach wymiarów ułatwia ich pobieranie do szybkich zapytań i analiz dla celów BI; pozwala użytkownikom wyszukiwać fakty według ich wymiarów. Na przykład można zapytać system o wszystkie transakcje sprzedaży (fakty), które zawierały określony typ produktu (wymiar) w określonym kodzie pocztowym (wymiarze). Przechowywanie danych według wymiarów jest w rzeczywistości bliższym przybliżeniem sposobu, w jaki ludzie zwykle myślą o danych firmy. Każdy wymiar jest aspektem pojedynczego wydarzenia biznesowego, który w jakiś sposób je opisuje lub kategoryzuje. Wymiary nadają zdarzeniom kontekst i znaczenie. Połączenie faktów z wymiarami mówi, co wydarzyło się w firmie w dokładnie określonych przez Ciebie warunkach. Jako przykład rozważmy hipotetyczną kolej: firmy przewożące pasażerów zazwyczaj mierzą swoją wydajność za pomocą wskaźnika unikalnego dla ich branży, znanego jako pasażer-mile (P/M). Jeden P/M to jeden płacący pasażer podróżujący jedną milę pociągiem obsługiwanym przez firmę. Tak więc pociąg ze 100 osobami na pokładzie, który przejechał 50 mil, zostaje wprowadzony do systemu jako 5000 P/M. Normalnie kolej używałaby wtedy tej liczby jako mianownika do innych pomiarów, takich jak przychód z podróży, koszt obsługi pociągu lub ilość zużytego paliwa. Każde obliczenie daje pewien wgląd w wydajność operacyjną kolei. Na najbardziej szczegółowym poziomie kolej przyjrzy się konkretnej podróży pociągiem między dwoma miastami, weźmie liczbę płacących pasażerów i pomnoży ją przez liczbę mil, aby uzyskać P/M dla tej podróży. Kolej może wtedy chcieć zmierzyć P/M kilkoma różnymi aspektami swoich operacji, zaczynając od tego samego poziomu szczegółowości - na przykład:

•  Według czasu: Całkowity koszt/miesiąc na dzień, który sumuje się do rachunku zysków i strat za tydzień, aż do miesiąca i roku.
•  Według położenia geograficznego: P/M między dowolnymi dwoma miastami w regionie, których wszystkie kombinacje sumują się do regionalnej wartości P/M. Wszystkie regionalne wartości P/M sumują się do krajowego pomiaru P/M.
•  Według typu lokomotywy: P/M dla konkretnej lokomotywy, PM dla lokomotyw tego samego typu, PM dla lokomotyw z tej samej rodziny: elektrycznych lub spalinowych lub być może parowych (dla zabawy).

Lista pomiarów "Według" jest ograniczona tylko liczbą przechowywanych wymiarów. I każdy wymiar może mieć jakość hierarchiczną - jak trzy wymiary pokazane tutaj, gdzie poszczególne pomiary można pogrupować w kolejne bardziej ogólne. Hierarchiczne uporządkowanie danych w środowisku przechowywania danych znacznie przyspiesza i ułatwia pozyskiwanie bardziej znaczących porcji informacji dla użytkowników. W środowisku operacyjnym hierarchie te muszą być obliczane ręcznie i poddawane skomplikowanym, kosztownym (pod względem szybkości przetwarzania) komendom bazy danych. Agregacja to ogólny termin opisujący sposób podsumowywania danych na różnych poziomach szczegółowości hierarchii. Hurtownia danych powinna obsługiwać "zsumowane" obliczenia dla hierarchii wartości dla każdego wymiaru. W poprzednim przykładzie ta funkcja umożliwiłaby użytkownikowi wysyłanie zapytań do hurtowni danych o szerokie obszary danych, takie jak P/M w regionie wschodnim, za cały czerwiec. Nawet jeśli można by zobaczyć pomiary P/M bardziej szczegółowo, jeśli chcesz, możliwości agregacji i podsumowania zapewniają szybki czas odpowiedzi w przypadku bardziej ogólnych zapytań.

Słowo o Master Data Management

Wokół koncepcji praktyk zarządzania danymi w całym przedsiębiorstwie krąży wiele modnych słów. Jednym z bardziej powszechnych, które zobaczysz, jest Master Data Management (MDM). MDM to koncepcja obejmująca całościowe podejście przedsiębiorstwa do zapewnienia spójności znaczenia i jakości wszystkich danych firmy. Chociaż idea ta jest zgodna z hurtowniami danych i docelowymi bazami danych BI, wykracza poza zwykłą integrację kilku dziedzin danych do raportowania i analizy. Wysiłki MDM mają na celu stworzenie jednej wersji "prawdy" we wszystkich systemach - nie tylko w hurtowni danych, ale także w środowiskach operacyjnych, modułach planowania zasobów przedsiębiorstwa (ERP) i wszędzie tam, gdzie informacje są obsługiwane. MDM ma dotyczyć systemów i środowisk, które nie mają nic wspólnego z Twoim projektem BI lub hurtownią danych, którą tworzysz w celu jego obsługi. W wielu przypadkach zespół BI przyjmuje zasadę MDM, ponieważ projekty BI wymagają pewnego poziomu standaryzacji danych w całym przedsiębiorstwie. Gdy zespół przejdzie przez różne przeszkody i stworzy jeden obraz informacji o firmie dla hurtowni danych, inne podmioty w firmie zaczynają pytać o przejście przez ten sam proces standaryzacji w swoich obszarach. Zakłada się, że odpowiedzialność za MDM spoczywa na zespole BI lub hurtowni danych. Teoretycznie jednak MDM powinien być na pierwszym miejscu jako szeroki cel firmy, którego osiągnięcie znacznie ułatwiłoby hurtownie danych i BI. Wyprowadzanie danych to kolejna cecha hurtowni danych. Z pewnością nie jest to wyjątkowa koncepcja dla systemów docelowych BI, ale nadal jest ważna. Fakt pochodny to niepodzielna (niepodzielna, wysoce specyficzna) część danych, która nie istnieje w danych źródłowych. Hurtownia danych tworzy ją z ustaloną formułą opartą na kombinacji oryginalnych elementów danych. Na przykład, duży producent sprzętu komputerowego może nie śledzić rażących argin w każdej transakcji składowej w żadnym ze swoich indywidualnych systemów źródłowych. Ale programista może być w stanie wyprowadzić ten ważny pomiar z istniejących danych. Deweloper może stworzyć formułę na podstawie danych pochodzących z dwóch różnych systemów:

• cena sprzedaży z systemu CRM
•  dane dotyczące kosztów sprzedaży towarów z bazy danych łańcucha dostaw

Odjęcie jednego od drugiego daje wymagany pomiar marży po składniku. Hurtownia danych byłaby zaprogramowana do wykonywania obliczeń w celu uzyskania tej wartości marży i przechowywania jej we wstępnie ułożonej tabeli, gdzie następnie byłaby dostępna dla analityków w raportach i analizach. Gdyby docelową bazą danych BI była grupa rockowa, grałaby tylko covery. Na liście nie znalazłyby się żadne oryginalne utwory. Docelowa baza danych BI jest repozytorium informacji, które istnieją w innych systemach. Oczywiście, mogą istnieć dane pochodne, a niektóre pola mogą zostać przekształcone, aby podstawowe informacje były łatwiejsze do zrozumienia lub bardziej dostępne. Ale na najbardziej podstawowym poziomie w docelowym systemie BI nie powinny być rejestrowane żadne nowe fakty ani zdarzenia, które nie znajdują się już w operacyjnej bazie danych gdzie indziej.
Powrót

11.09.2021

Jakość danych

Niska jakość danych podważa wartość informacji i powoduje, że użytkownicy i interesariusze nie ufają aplikacjom, które na nich polegają. Częścią przygotowania danych do wykorzystania przez aplikację BI jest przejście kontroli w celu zapewnienia jakości danych. Logiczne jest wymaganie rygorystycznych standardów wprowadzania danych jako ochrony przed niską jakością danych. Na przykład, jeśli klienci są wprowadzani do systemu bez kodów pocztowych, można wdrożyć aktualizację aplikacji, która uniemożliwi wpis, chyba że zostanie wprowadzony pełny pięciocyfrowy kod pocztowy. Choć w teorii brzmi to dobrze, w rzeczywistości może to spowodować niezamierzone konsekwencje. Nękani urzędnicy wprowadzający dane (na przykład) mogą ominąć zasady, wprowadzając 00000 jako kod pocztowy lub wprowadzając jakiś inny nonsensowny 5-cyfrowy numer, aby sobie to ułatwić. Standardy wprowadzania danych powinny z pewnością odgrywać pewną rolę, ale powinny być starannie zaprojektowane - i nie zastąpią back-endowego procesu jakości danych
Powrót

12.09.2021

Modele danych

Po przeanalizowaniu, skategoryzowaniu i sprofilowaniu danych źródłowych nadszedł czas, aby przejść do projektowania docelowej bazy danych BI. Pierwszym krokiem w budowie dowolnej bazy danych jest wybór modelu danych: zestawu reguł i ograniczeń dotyczących sposobu organizacji i przechowywania informacji w bazie danych. Mówimy tutaj o magazynie logicznym, a nie fizycznym - system zarządzania bazą danych obsługuje większość z nich bez konieczności martwienia się o to. Model pomaga nam zrozumieć rzeczywisty świat, przedstawiając jego wersję bez tłuszczu. Model reprezentuje dane - które z kolei reprezentują jednostki biznesowe i relacje, które zapełniają świat rzeczywisty. Ale ponieważ świat rzeczywisty jest skomplikowanym miejscem, dane mogą być czasami wyjątkowo skomplikowane. Aby być skutecznym, Twój model musi dzielić wystarczająco dużo cech z rzeczywistością, aby działał jako dokładna reprezentacja, a jednocześnie skoncentrować się na jego podstawowych cechach, aby para nie wydobywała się z twoich uszu, gdy o tym myślisz. Model danych pokieruje sposobem przechowywania i porządkowania informacji w docelowej bazie danych. Oznacza to, że dobrym pomysłem jest przetestowanie modelu podczas projektowania, aby mógł obsłużyć wszystkie potrzeby informacyjne, które mogą się pojawić. Projektując swój model danych - a zatem same dane - nieustannie dokonujesz kompromisu między rzeczywistością a użytecznością. Jeśli uczynisz model danych zbyt prostym, możesz ukrywać ważne zawiłości rzeczywistych operacji biznesowych. Ale jeśli sprawisz, że model danych będzie zbyt skomplikowany, Twoi użytkownicy go nie zrozumieją, a w rezultacie nie będą mogli w pełni korzystać z aplikacji front-endowych - a wtedy możesz pożegnać się z nimi wspaniałe spostrzeżenia biznesowe, o których marzyłeś.
Powrót

13.09.2021

Wymiarowy model danych

Wymiarowy model danych reprezentuje procesy i zdarzenia biznesowe, takie jak sprzedaż, wysyłki lub dane wyjściowe fabryki.

Tabele faktów i wymiary

Większość hurtowni danych korzysta z modelu wymiarowego z poprzedniego przykładu kolejowego, w którym informacje krążą wokół mierzalnych faktów, takich jak liczby sprzedaży. Te ważne fakty zajmują centralną pozycję w bazie danych, zajmując tabelę, z której promieniuje reszta informacji. Baza danych przechowuje te centralne fakty w tabeli znanej (co dość ciekawe) jako tabela faktów. Każdy wiersz w tabeli faktów jest podstawową, niepodzielną jednostką w bazie danych. Projektanci baz danych są odpowiedzialni nie tylko za decydowanie o tym, jakie są kluczowe fakty, ale także za decydowanie o tym, jak szczegółowo chcą utworzyć tabelę faktów. Na przykład, jeśli mierzysz wyniki finansowe, spraw, aby jakaś miara sprzedaży była Twoim faktem. Projektanci następnie zdecydują, czy każdy wiersz w tabeli reprezentuje pojedynczą pozycję z transakcji, pojedynczą transakcję, dzienną sumę transakcji dla każdej lokalizacji sklepu, czy inną agregację informacji o sprzedaży.

Drugim kluczowym filarem modelu wymiarowego jest sposób wybierania, kategoryzacji i przechowywania wymiarów (szczególnych aspektów faktu). Wymiary to różne sposoby filtrowania faktów, takie jak sprzedaż według sprzedawcy, sprzedaż według typu produktu lub sprzedaż według okresu. Jeśli sprzedaż jest podstawowymi miarami w tabeli faktów, wymiar powie coś o tej kwocie w dolarach. Na przykład możesz uruchomić następujące zapytanie:

Pokaż całkowitą sprzedaż według stanu

Tutaj geografia jest wymiarem, ponieważ odpytałeś system, aby rozbić sprzedaż według stanu. Jeśli zapytasz system, aby pokazać całkowitą sprzedaż według kodu pocztowego, nadal będziesz wysyłać zapytania według wymiaru geograficznego, ale podzielisz te same dane sprzedaży na nieco inne linie. Podstawowe fakty byłyby takie same, ale model wymiarowy pozwala ci rozbić go na kawałki w dowolny sposób, który ci się przyda.
Powrót

14.09.2021

Korzyści z modelu wymiarowego

Wspaniałą rzeczą w modelu wymiarowym jest to, że dane są przechowywane w sposób, w jaki ludzie myślą. Tabele faktów są kluczową miarą wyników firmy, które staramy się mierzyć - niezależnie od tego, czy chodzi o sprzedaż, liczbę przejechanych mil, czy też minuty oczekiwania. A wymiary to wszystkie możliwe wpływy na te miary. Z drugiej strony dane znormalizowane nie są uporządkowane w sposób, który odzwierciedla to, jak ludzie zwykle myślą. To właśnie sprawia, że dane wymiarowe są tak przydatne; nie musi być przechowywany w jakimś tajemnym, tajnym kodzie przeznaczonym tylko dla programistów. Zwykłe osoby mogą przeszukiwać bazę danych i czuć się komfortowo, że wyniki będą dokładnie tym, o co prosili. To nie jest trywialna korzyść; zwiększa satysfakcję użytkowników z narzędzi front-end i przybliża pracowników do tych wszystkich ważnych spostrzeżeń BI. Są też inne korzyści:

•  Dane są nie tylko bardziej intuicyjne dla użytkowników, którzy będą tworzyć zapytania i raporty, ale także ułatwiają zrozumienie hurtowni danych dla programistów. To jest dobre na czas budowy i pomaga również w konserwacji.
•  Intuicyjne dane wymiarowe są również ważne dla architekta BI, ponieważ narzędzia do raportowania oraz zaawansowane pakiety analityczne i statystyczne są przygotowane do pracy w tego rodzaju środowisku, co ułatwia integrację nowych narzędzi.
•  Ujednolicenie danych ze źródeł danych operacyjnych w jeden model nadaje się do modelu wymiarowego, jeśli każdy system koncentruje się wokół tej samej funkcji.
•  Szybkość zapytań może zostać poprawiona. Zamiast wymagać bardzo złożonych złączeń tabel, model wymiarowy umożliwia prostsze, bardziej bezpośrednie operacje na odfiltrowanie tylko wierszy wymaganych przez żądającego.
•  Model wymiarowy ma elastyczny schemat - choć niekoniecznie jest to łatwe, możesz dodać więcej faktów i wymiarów bez konieczności przebudowy bazy danych
Powrót

15.09.2021

Wadą modelu wymiarowego

Normalizacja danych zmniejsza nadmiarowość w bazach danych jako sposób na poprawę wydajności pamięci masowej i zmniejszenie możliwości wystąpienia niespójności i błędów danych. Te negatywy mogą potencjalnie wejść w grę z modelem wymiarowym. Wiele reguł wymuszania integralności danych związanych z relacyjnym modelem danych jest wyrzucanych przez okno w modelu wymiarowym. Wynik: wiele danych jest przechowywanych.
Powrót

16.09.2021

Wielowymiarowe gwiezdne wojny

Istnieją dwa podstawowe modele przechowywania danych wymiarowych: schematy gwiaździste i schematy płatków śniegu. Każdy ma swoje dobre i złe strony. Specjaliści od danych nieuchronnie mają silne zdanie na temat tego, która hurtownia danych jest najlepsza dla administrowanej przez nich hurtowni danych.

Schemat gwiazdy

Schemat gwiazdy jest podstawową manifestacją wymiarowego modelu danych. Ma dwa poziomy danych i tylko dwa poziomy - fakty i wymiary. Nazywa się to schematem gwiaździstym, ponieważ centralna tabela faktów ma dowolną liczbę promieniujących z niej wymiarów, które oferują aspekty informacji opisanych w tabeli faktów. Rysunek 16-5 to prosta reprezentacja tabel w schemacie gwiazdy. Centralnym mierzonym zdarzeniem są informacje o sprzedaży przechowywane w tabeli FAKT SPRZEDAŻY. Informacje w czterech dołączonych tabelach wymiarów służą do opisania najbardziej szczegółowych transakcji sprzedaży. Schemat gwiazdy pozwala analitykom mierzyć fakty z różnych perspektyw ograniczonych jedynie do liczby przechowywanych wraz z nimi wymiarów. Jest to popularny sposób przechowywania danych w hurtowni danych, ponieważ naśladuje sposób, w jaki użytkownicy często myślą o informacjach biznesowych. Na przykład, jeśli analitycy szukają informacji na temat wyników różnych sklepów detalicznych w danym regionie, zasadniczo pytają o wszystkie indywidualne transakcje sprzedaży, które spełniają kryteria ich zapytania - obliczane razem. Tabele faktów w schemacie gwiaździstym reprezentują właśnie to - długą listę pojedynczych transakcji (niezależnie od tego, jakie mogą być), które można filtrować i łączyć zgodnie z informacjami, które je opisują. Ten model danych jest najbardziej popularny w hurtowniach danych, które zasilają aplikacje BI. Programiści i użytkownicy końcowi mogą to łatwo zrozumieć, co sprawia, że bazy danych zbudowane na schemacie gwiaździstym są łatwe w tworzeniu, utrzymaniu i użytkowaniu. Jednym z wymiarów, który prawie zawsze znajdujesz w schemacie gwiazdy, jest czas; Hurtownie danych są budowane w celu zapewnienia wglądu w historyczne wyniki wydarzeń firmowych. Nieuchronnie jednym ze standardowych sposobów, w jaki analitycy patrzą na dane, jest patrzenie na nie w określonych przedziałach czasu. To ważne, ponieważ pokazuje trendy historyczne i pozwala wnioskować o przeszłości i jej wpływie na przyszłość.
Powrót

17.09.2021

Schemat płatka śniegu

Schemat płatka śniegu jest ściśle powiązany ze schematem gwiaździstym, ponieważ model danych jest wyśrodkowany na centralnej tabeli faktów. Ale trochę inaczej radzi sobie z wymiarami; niektóre wymiary są znormalizowane w celu zaoszczędzenia miejsca i zmniejszenia nadmiarowości. Schemat płatka śniegu stał się popularny, ponieważ mówi się, że wykorzystuje to, co najlepsze z obu światów. Podstawowe informacje są wielowymiarowe, dzięki czemu model danych jest łatwiejszy do zrozumienia i dostępu; ale zamiast przechowywać pewne szczegółowe informacje w kółko, wykorzystuje znormalizowane tabele w niektórych częściach bazy danych. To, co schemat płatka śniegu zyskuje dzięki nadmiarowości i elastyczności danych, traci pod względem złożoności. Oznacza to, że analitykom danych i administratorom trudniej jest utrzymać i dostroić strukturę niż struktura płatka śniegu. Podobnie jak schemat gwiaździsty, jest zorganizowany wokół centralnej tabeli faktów, która zawiera istotne informacje o firmie. I jest również otoczony wymiarami. Różnica polega na tym, że wymiary schematu gwiaździstego są podzielone na znormalizowane hierarchie, aby zaoszczędzić miejsce i zmniejszyć nadmiarowość.
Powrót

18.09.2021

Inne rodzaje modeli danych

W hurtowniach danych nazwą gry są modele wymiarowe. Ale istnieją inne podejścia niż schemat gwiazdy i płatka śniegu.

Znormalizowany schemat

Relacyjne bazy danych wykorzystują znormalizowany schemat, w którym dokłada się wszelkich starań, aby przechowywać informacje tylko raz. Ma to sens, gdy próbujesz zachować ścisłą integralność danych i wykorzystujesz minimalną przestrzeń dyskową. Jest to również właściwy sposób, aby przejść do systemów transakcyjnych, w których programy potrzebują szybkich czasów odpowiedzi podczas uzyskiwania dostępu, modyfikowania i zapisywania rekordów.

Modele hybrydowe

Chociaż systemy przechowywania danych zwykle działają w jedną lub drugą stronę, czasami warto zastosować podejście mieszane - znormalizowany schemat dla jednej domeny danych i model wymiarowy dla innej domeny. To, czy to podejście działa, zależy od charakteru zapytań, które planujesz uruchomić w hurtowni danych. Aby schemat działał prawidłowo, kombinacja konstrukcji znormalizowanych i wymiarowych musi być w pełni zgodna z rodzajami zapytań, które planujesz uruchomić. Większość ekspertów zgadza się, że to rzadkie zjawisko. Musisz zadawać pytania w określony sposób, a dane muszą być powiązane w prawdziwym świecie. Pozwól, aby architekci danych poprowadzili Cię w tej decyzji; po prostu upewnij się, że dostarczasz im wystarczająco dużo informacji, aby to przemyśleć. Oprócz określenia struktury danych i zapytań, które planujesz uruchomić, zadaj następujące pytania:

•  Co ważniejsze - wydajność systemu lub łatwość obsługi i konserwacja?
•  Jak elastyczny musi być system?
•  Czy oprogramowanie, które ma być podłączone do hurtowni danych, obsługuje hybrydowy model danych?
•  Czy w przyszłości zmieni się coś, co może zmusić nas do uruchamiania zapytań innych niż przewidywaliśmy?
Modele danych nie dają jednoznacznej odpowiedzi. Nie ściskaj danych do modelu wymiarowego, jeśli jest to kwadratowy kołek w okrągłym otworze. Jeśli modelowane dane są zbyt złożone (z systemu źródłowego, procesów lub ich kombinacji), zastosowanie modelu wymiarowego do obiektów i miar biznesowych może być niemożliwe. Zacznij od tego, co masz i ustal, który model działa najlepiej. Nie zaczynaj od modelu i pracuj wstecz.
Powrót

19.09.2021

Targi danych

Wyobraź sobie, że Twoja firma wdrożyła hurtownię danych, która zbiera informacje o klientach i transakcjach sprzedaży ze wszystkich oddziałów i oddziałów firmy. To powinno być bardzo przydatne; w całym przedsiębiorstwie hurtownia danych oferuje ujednolicony, zintegrowany widok informacji. Ale powiedzmy, że dział badań rynku chce uzyskać dostęp do tych danych i uruchomić określony rodzaj aplikacji do analizy predykcyjnej w odniesieniu do informacji przechowywanych w hurtowni danych. Firma może ustanowić dla zespołu marketingowego bazę danych. W środowisku BI istnieje kilka definicji zbiorczych danych, ale najpowszechniej akceptowaną jest jednodomenowa agregacja danych używana do raportowania, analizy lub wspomagania decyzji. Marty danych różnią się architekturą; mogą otrzymywać dane z hurtowni danych lub bezpośrednio z systemów transakcyjnych. Mogą dokonywać przekształceń i obliczeń na danych podobnych do hurtowni danych. Ale marty danych zawsze mają ograniczony zakres i cel biznesowy. Na przykład możesz mieć hurtownię danych, która obsługuje system punktów sprzedaży w Twojej firmie. Tabele faktów w Twojej hurtowni danych, z których chcesz wysyłać zapytania i raporty, będą zawierały informacje o transakcjach sprzedaży, takie jak kwota każdej sprzedaży, pozycje (takie jak numer SKU) i czy rabat został stosowany do sprzedaży. Te podstawowe fakty można powiązać z wieloma wymiarami przechowywanymi wraz z danymi transakcyjnymi. Wymiary danych transakcji mogą obejmować informacje o czasie, informacje o sklepie i kasjer, który zakończył sprzedaż. Marty danych mogą być świetne dla bardziej okazjonalnych użytkowników, którzy nie mają takiego poziomu wiedzy, jak zwykły lub zaawansowany użytkownik zaawansowanych narzędzi. Scal informacje wysokiego poziomu dotyczące jednego tematu funkcjonalnego w środowisku zbiorczej bazy danych i pomiń szczegóły, które możesz zaoferować bardziej doświadczonym użytkownikom. Na przykład dyrektor generalny może potrzebować widoków wysokiego poziomu informacji o sprzedaży bez konieczności obsługi skomplikowanego narzędzia do raportowania lub pisania złożonych zapytań. Jednym z niebezpieczeństw związanych z modelowaniem każdego procesu/zdarzenia biznesowego jest to, że możesz skończyć z wieloma odmiennymi, niepowiązanymi datami mart. Każdy data mart będzie działał efektywnie i odpowiadał na konkretne pytania biznesowe w swojej dziedzinie. Wartość każdej mart danych dla organizacji będzie jednak ograniczona; na pytania nie można odpowiedzieć w różnych funkcjach firmy.
Powrót

20.09.2021

Operacyjne magazyny danych

To może Cię zaskoczyć, ale operacyjny magazyn danych (ODS) został zaprojektowany z myślą o integracji i przechowywaniu … czekaj na to … dane operacyjne do celów raportowania i analizy. Twoja organizacja może potrzebować migawek bieżących danych operacyjnych, które można udostępnić i zbadać w celu wsparcia funkcji taktycznych, takich jak procesy wspomagania decyzji lub pewnego rodzaju raportowanie. Ponieważ hurtownie danych są zaprojektowane jako opiekunowie danych historycznych, mogą nie być w stanie zareagować wystarczająco szybko, aby zaspokoić potrzeby taktyczne. W takim przypadku SZWO może być dla Ciebie. Analiza biznesowa polega między innymi na dostarczaniu informacji na czas. ODS może pomóc w zapewnieniu, że spostrzeżenia są dostarczane na czas, aby można było na nich działać, dostarczając najnowsze widoki danych operacyjnych. ODS działa jak hurtownia danych: różne systemy w firmie dostarczają informacje operacyjne, które przetwarza w jednorodną formę, dzięki czemu analitycy i autorzy raportów mogą uzyskać jeden widok informacji. Jednak w przeciwieństwie do hurtowni danych, ODS nie ma na celu utrzymywania rozległego historycznego zapisu informacji. Informacje zawarte w ODS mają stanowić aktualny (lub przynajmniej bardzo aktualny) obraz działalności firmy. Daje to firmom szansę na natychmiastową analizę, aby zareagować na daną sytuację. Wiele firm wykorzystuje ODS jako obszar pomostowy dla hurtowni danych. Logika integracji i procesy znajdują się w operacyjnej składnicy danych. W ten sposób przychodzące dane są odpowiednio przekształcane w celu płynnej integracji. Następnie na bieżąco hurtownia danych pobiera aktualną partię danych z ODS i dodaje ją do istniejących już w systemie danych historycznych.
Powrót

21.09.2021

Produkty BI i dostawcy

Dla kierowników projektów i sponsorów projektów BI planujących nową inicjatywę business intelligence, wybór oprogramowania do zasilania środowiska jest jednym z największych wyborów w trakcie wdrożenia. Dobrą wiadomością jest to, że branża dojrzała; Na osoby oceniające aplikacje czeka wiele potężnych i wydajnych opcji. Istnieją aplikacje ogólnego przeznaczenia, aplikacje specjalistyczne, pakiety typu "wszystko w jednym" i plany w stylu kafeterii. Branża oprogramowania wzrosła do zapotrzebowania na dobre narzędzia BI, które mogą wykopać te spostrzeżenia biznesowe, które są (znasz mantrę) dokładne, aktualne, wartościowe i wykonalne. Wszystkie te wybory mogą być nieco przytłaczające, dlatego w tym rozdziale przyjrzymy się aktualnemu stanowi branży oprogramowania w odniesieniu do analizy biznesowej. Ten stan ciągle się zmienia i nie zawsze jest łatwy do zdefiniowania. Ta księga jest dokładna w momencie ukończenia rękopisu. Ale jeśli przeszłość jest jakąkolwiek wskazówką, kilka dużych przejęć nastąpi w momencie, gdy książka trafi do druku, a cały krajobraz branży zmieni się z dnia na dzień. Rynek oprogramowania BI jest notorycznie dynamiczny. Są gracze niszowi, którzy pojawiają się i wyrabiają sobie markę w jednej specjalności. Sprzedawcy w czystej postaci specjalizują się w tworzeniu produktów dla jednego celu biznesowego - w tym przypadku BI. Są też wielcy dostawcy oprogramowania, którzy zaznaczyli swoją obecność poza BI. Próbując wejść na lukratywny rynek oprogramowania Business Intelligence, często wykupują mniejszych graczy, aby uzupełnić swoje portfolio produktów BI. Wszystko to komplikuje zmieniający się krajobraz funkcji produktów i potrzeb korporacyjnych. Ważna funkcja, która obecnie znajduje się w większym pakiecie aplikacji, może zostać jutro wydzielona jako samodzielny produkt. To, co mówię, to ostrzeżenie lektora - strzeż się czytelniku!
Powrót

22.09.2021

Przegląd oprogramowania BI

Każdy nieco inaczej definiuje granice rynku. Na potrzeby tej książki definiujemy rynek BI jako aspekt wszystkiego w stosie technologicznym - od danych operacyjnych po narzędzia skierowane do użytkowników, które wyrzucają te cenne spostrzeżenia:

•  Systemy zarządzania bazami danych (DBMS)
•  Narzędzia do integracji danych
•  Narzędzia ETL (wyodrębnianie, przekształcanie, ładowanie)
•  Narzędzia hurtowni danych
•  Zapytania, narzędzia do raportowania i analizy
•  Zapytania doraźne
•  Zarządzanie raportami przedsiębiorstwa
•  Usługi powiadamiania i komunikatora
•  OLAP i inne analizy
•  Inne narzędzia front-end
•  Eksploracja i analiza danych
•  Narzędzia wizualizacji (tablice wskaźników, karty wyników, grafika)
•  Narzędzia dostępu (portale, dostęp mobilny)

W oprogramowaniu BI nie ma czegoś takiego jak uniwersalne rozwiązanie. Niektóre firmy starają się dotknąć każdej przestrzeni, ale nie ma jednej firmy, której produkt robi wszystko dobrze. Nie zakochaj się w tych etykietach. Zapytaj różnych ekspertów BI, a otrzymasz inne drzewo genealogiczne oprogramowania związanego z analizą biznesową. Ale od czegoś trzeba zacząć, prawda?
Powrót

23.09.2021

Model wymiarowy

Spośród każdej głównej grupy BI oprogramowanie BI można rozpatrywać w pięciu głównych wymiarach jakościowych (lub półjakościowych). Nie uwzględniłem ceny, ponieważ jest oczywiste, że musisz ocenić każdy zasób dla swojego projektu według tego, jak dolary i centy mieszczą się w budżecie projektu.

•  Zestaw funkcji: czy ta aplikacja może robić dokładnie to, czego od niej potrzebuję, gdy jest zainstalowana w moim środowisku? Różni dostawcy oprogramowania koncentrują się na różnych funkcjach, więc to, że patrzysz na dwa różne narzędzia OLAP, nie oznacza, że otrzymujesz dokładnie to samo.
•  Kompatybilność: czy ta aplikacja będzie działać z innymi? Narzędzia BI w górę iw dół stosu technologii ze swej natury muszą dobrze współdziałać z innymi dziećmi, które już mieszkają w bloku. Ale to nie znaczy, że wszyscy są najlepszymi przyjaciółmi. Jest to niezwykle ważne, ponieważ większość firm ma już pewnego rodzaju środowisko danych, z którym muszą być zgodne ich narzędzia BI.
•  Opakowanie: co dostawca oprogramowania umieszcza w jednym wydaniu swojego oprogramowania BI? Możesz uzyskać wszystko, czego potrzebujesz, korzystając z jednego zestawu licencji; z drugiej strony możesz kupować z menu á la carte.
•  Wydajność: jak szybko poradzi sobie z dużą ilością danych, które na nią wyrzucę? A jeśli w przyszłości liczba ta dramatycznie wzrośnie, czy oprogramowanie będzie w stanie się z tym rozwijać?
•  Łatwość użycia: ściśle związana z ilością szkoleń i wsparcia, które otrzymasz od dostawcy oprogramowania. Niektóre firmy chcą zarabiać na licencjach na oprogramowanie, inne na ich wsparciu. Upewnij się, że bierzesz pod uwagę oba, wybierając oprogramowanie.

To, co sprawia, że wybór oprogramowania jest nieco łatwiejszy dla większości osób zaangażowanych w projekty BI, to fakt, że często nie mają zbyt wielu możliwości wyboru. Nie chodzi o to, że na rynku nie ma szerokiej gamy produktów; wręcz przeciwnie. Problem, a raczej rzeczywistość większości projektów i firm polega na tym, że z samej swojej natury dyktują one pewien zestaw cech.
Powrót

24.09.2021

Pracować razem

Wymiar zgodności to pierwsza rzecz, o której myślą specjaliści BI, rozważając nową instalację lub aktualizację; instalowane oprogramowanie musi działać z danymi aktualnie znajdującymi się w systemie i musi komunikować się z systemem. Ostatnie dziesięć lat przyniosło duży postęp w zakresie standardów, co otworzyło rynek. Prawie wszystkie produkty mogą posługiwać się jakąś formą standardu znanego jako Open Database Connectivity (ODBC), który tłumaczy żądania i odpowiedzi do systemu bazodanowego na rodzaj dostępnej dla wszystkich lingua franca. Dostawcy publikują interfejsy programowania aplikacji (API), które umożliwiają programistom dostęp do funkcji produktu w kodzie. Ważny był standard Extensible Markup Language (XML), a ciągłe rozprzestrzenianie się samej sieci WWW (wraz z pojawieniem się przeglądarki jako narzędzia zwiększającego produktywność) przyspieszyło ten proces. Mimo że te standardy są ustalone, nic nie jest uniwersalnie kompatybilne. A koncepcja kompatybilności jest daleka od osiągnięcia prostoty podobnej do listy kontrolnej, której wszyscy sobie życzymy. W praktyce (na przykład) aplikacje przechowujące dane w formacie XML mogą nie współpracować z innym systemem opartym na XML. Dobrym planem jest łączenie dostawców w celu uzyskania odpowiedniego zestawu funkcji - lub stworzenia ogólnego rozwiązania w odpowiednim przedziale cenowym dla Twojego budżetu. Ale lepiej mieć ekspertów pod ręką, aby wszystkie te rzekomo kompatybilne komponenty współpracowały ze sobą. Nawet jeśli znajdziesz odpowiedni produkt lub dostawcę, który znajduje się na idealnym skrzyżowaniu ceny i wymaganych wymiarów jakościowych, być może będziesz musiał jeszcze bardziej zawęzić pole. Firmy często narzucają określone standardy lub mogą mieć wcześniej istniejące relacje z niektórymi dostawcami; jeśli tak, to istnieje inny zestaw ograniczeń, których Twój zespół projektowy musi przestrzegać.
Powrót

25.09.2021

Rynek oprogramowania BI

Rynek oprogramowania BI jest zaludniony przez firmy wszystkich kształtów i rozmiarów. Wśród liderów rynku znajdują się znane nazwiska, takie jak Microsoft i Oracle, ale także mniejsze firmy BI, takie jak Business Objects. Dodatkowo są gracze niszowi, którzy bardzo dobrze wykonują jedną funkcję, oraz specjaliści wertykalni: firmy, które koncentrują się na BI dla konkretnej branży.

Trochę historii

Początki dzisiejszego, wartego wiele miliardów dolarów rynku oprogramowania Business Intelligence są skromne i rozproszone. Dyscypliny, które pojawiały się, odchodziły, metamorfozowały, zmieniały nazwy i powracały, prawie zawsze zaczynały się od nisz innowatorów w firmach, które chciały wycisnąć część wiedzy z tych wszystkich danych. Nic dziwnego, że firmy, które utworzyły wczesny rynek BI, były, podobnie jak ich zwolennicy i mistrzowie, graczami niszowymi. Początki BI - w różnych jego formach - ewoluowały wraz z mniejszymi firmami tworzącymi wyspy technologii; ich głównym problemem było wygrywanie w konkurencyjnej niszy. Oznaczało to oferowanie produktów o wysokiej wydajności i bogatych w funkcje (zgodnie z definicją ich rynku), zamiast elastyczności. Zamiast oferować uniwersalną kompatybilność, mali dostawcy BI budowaliby swoje pakiety tak, aby dobrze współpracowały z jednym podstawowym systemem bazodanowym. Wszystko zmieniło się wraz ze wzrostem popularności sieci klient-serwer, które ostatecznie ustąpiły miejsca Internetowi i sieci World Wide Web. Oprogramowanie stało się bardziej modułowe. Gdy firmy zaczęły mieszać i dopasowywać swoje komponenty BI, interaktywność i kompatybilność stały się ważniejsze.
Powrót

26.09.2021

Fuzje i przejęcia

Rynek oprogramowania BI jest jak zbiornik z rekinami, w którym małe ryby pływają na całe życie i ostatecznie robią jedną rzecz wystarczająco dobrze (jak na ironię), aby zostać zjedzonym przez większą rybę. Ta większa ryba jest następnie zjadana przez jeszcze większą rybę i tak dalej, aż na rynku będzie mniej konkurentów.

Duża ryba, mała ryba

W ostatnich latach kształt rynku został wyznaczony przez przejęciowy charakter dostawców oprogramowania dla dużych firm: Microsoft, Oracle, IBM i SAP. W tym samym czasie dostawcy rozwiązań BI typu pure-play nie spoczęli na laurach; nadal wykupują konkurentów i uzupełniających się graczy, aby poprawić swoją pozycję na rynku. Przejęcia rosną kaskadowo. Na arenie BI liderami rynku w górę iw dół stosu technologii BI są często firmy średniej wielkości (takie jak Hyperion, Cognos i Business Objects). Z wyjątkiem obszaru baz danych, największe firmy zajmujące się oprogramowaniem odgrywały tylko niewielką, ale rosnącą rolę na rynku. Firmy średniej wielkości zajęły się innymi średnimi i małymi graczami na rynku, kupując ich, aby uzupełnić swoje portfele BI. W ostatnich latach giganci oprogramowania weszli do gry, wchodząc na rynek BI za jednym zamachem dzięki przejęciu odtwarzacza średniej wielkości.

Buduj kontra kup

Ogólna decyzja dla każdej firmy, w dowolnej domenie, to kompilacja kontra kupno. Jeśli firma rozpozna cechę lub funkcję, której potrzebuje dla jednego ze swoich produktów lub do użytku wewnętrznego, ma wybór: albo poświęcić czas na napisanie kodu, albo kupić istniejący produkt od innej firmy. Każdy ma swoje plusy i minusy:

•  Kompilacja: jeśli dostawca tworzy własne rozwiązanie, możesz spać spokojnie, wiedząc, że nowa funkcja będzie zwykle doskonale zgodna z istniejącym portfolio produktów i rozwiązań. Minusem jest oczywiście to, że rozwiązanie, które otrzymasz, nie będzie tak rozwinięte, jak dojrzały produkt BI. Dzieje się tak, ponieważ zdobycie wiedzy i doświadczenia wymaganego do wytworzenia świetnego produktu wymaga czasu. Potrzeba lat ciężkiej pracy, innowacji, wielu wydań i (czasem) kosztownych błędów, aby oprogramowanie ewoluowało i ulepszało się, zanim zostanie zaakceptowane przez rynek.
•  Kupuj: jeśli sprzedawca dostrzeże lukę w swoim portfolio lub jeśli jego ludzie uważają, że jego własny produkt jest w niekorzystnej sytuacji na rynku, może po prostu kupić istniejącego gracza, aby szybko nadrobić zaległości. Doskonałym przykładem był rok 2003, kiedy firma Business Objects kupiła Crystal Decisions, wówczas wiodącego dostawcę aplikacji do raportowania (coś, czego B.O. wtedy nie robił). Minusem tego podejścia jest to, że nie można automatycznie zakładać, że produkty Twojej firmy będą dobrze współpracować z produktami przejmowanej firmy. Oracle (na przykład) przeszło przez żarłoczne fazy rozwoju BI - ale całe to pochłanianie czasami pozostawiało firmę z mylącym zestawem produktów o nakładającej się funkcjonalności.
•  Zabij: Ups, zawsze jest ta trzecia opcja dostępna dla dostawców oprogramowania: Kup swojego konkurenta, a następnie zamknij firmę, pozostawiając swój własny produkt, aby zdominował rynek. Często produkt konkurencji ma kilka zbawiennych cech, które warto kanibalizować. Firma Oracle wielokrotnie stosowała to podejście w dziedzinie planowania zasobów przedsiębiorstwa (ERP) - kupując konkurentów, wchłaniając funkcje ich produktów, a następnie powoli przenosząc swoją bazę klientów na produkty Oracle. Z perspektywy nabywcy oprogramowania BI musisz mieć świadomość, że zawsze jest to możliwe dla kupowanego produktu.

Jako rozwiązanie tymczasowe, wielu dostawców będzie współpracować z dostawcą uzupełniającym, aby zadowolić swoją bazę klientów. Microsoft, nie mając własnego pakietu analitycznego, robił to przez lata z firmą Comshare i kilkoma innymi dostawcami potężnych pakietów raportowania analitycznego. Partnerstwo może oznaczać prostą relację marketingową, w której obie firmy współpracują przy pozyskiwaniu klientów lub budowanie relacji technicznej, aby zapewnić, że kod z każdej aplikacji jest dobrze zintegrowany, lub jakąś formę współpracy między tymi dwoma skrajnościami. Nie powinieneś tego robić, ale jest to rzeczywistość rynku BI: Kiedy decydujesz się na wybór konkretnego dostawcy BI, dobrym pomysłem jest przeprowadzenie zarówno analizy produktu, jak i analizy rynku. Upewnij się, że żadne czerwone flagi nie powiewają na wietrze z przodu. Czy firma próbuje sprzedać Ci produkty, które niedawno nabyła? (Jeśli tak, to jak dobrze zna swoje nowe produkty?) Czy firma jest kandydatem do przejęcia? (Jeśli tak, czy są w stanie zagwarantować stałe wsparcie dla swojego produktu?) Oczywiście, powinieneś to robić przy wszystkich większych zakupach … heck, zanim kupisz ten odkurzacz, równie dobrze możesz sprawdzić historię firmy. Ale rynek BI jest szczególnie donkiszotowski, więc miej oczy szeroko otwarte na znaki ostrzegawcze. Oto przedsmak ostatnich przejęć w świecie BI i wokół niego w ciągu ostatnich kilku lat:

•  Hyperion kupił Brio
•  Oracle kupiło Hyperiona
•  Oracle kupiło IRI
•  Business Objects kupiło Crystal Decisions
•  Business Objects kupił Cartesis
•  Microsoft kupił ProClarity
•  Actuate kupione EII
•  Ascential kupił Mercator
•  IBM kupił Alphablox
•  SAP kupił pilota
•  SAP kupił Outlooksoft
Powrót

27.09.2021

Główne firmy programistyczne w BI

Ponieważ Business Intelligence i powiązane z nią dyscypliny stały się bardziej zakorzenione w procesach korporacji, duże firmy programistyczne, które już dostarczają narzędzia produktywności i danych, zareagowały, oferując własne narzędzia BI. W rezultacie dostawcy platform, tacy jak Microsoft i SAP, stali się głównymi graczami na scenie BI. W niektórych przypadkach ich aplikacje zostały wyhodowane organicznie - zaplanowane i wyprodukowane przez własny zespół programistów. W innych przypadkach duża firma wypełnia swój zestaw narzędzi, kupując firmę, która stworzyła produkt, którego potrzebuje.

Wiązki radości

Duże firmy zajmujące się oprogramowaniem działają nieco inaczej w dostarczaniu BI na rynek niż dostawcy czystej gry. Firma taka jak Microsoft czy Oracle ma gigantyczną bazę instalacyjną klientów korzystających z innych części swojego oprogramowania biznesowego. Obie firmy, wraz z kilkoma innymi, dominują na rynku baz danych dla przedsiębiorstw. To daje im przewagę, jeśli chodzi o rynki, na których nie są tradycyjnie silni. Tak było w przypadku BI zaledwie kilka lat temu. Dostawcy BI strategicznie łączą komponenty swojego oprogramowania w zależności od tego, jak widzą potrzeby rynku. To dobra wiadomość dla wielu właścicieli projektów, ponieważ oznacza to, że często mają już własne licencje na oprogramowanie. Na przykład, jeśli Twój dział IT posiada licencje Microsoft SQL Server, niektóre z najważniejszych narzędzi BI są dołączone do tego produktu. Nie musisz kupować niczego dodatkowego; już to masz. Jedynym minusem jest to, że takie podejście może utrudnić ocenę produktów obok siebie. A jeśli wiatry budżetowe tak właśnie wiają, może to oznaczać, że będziesz musiał użyć produktu tylko dlatego, że jest już na miejscu, zamiast kupować inny produkt, który ma faktycznie potrzebne funkcje.
Powrót

28.09.2021

Oracle

Oracle, który już teraz jest poważnym graczem w zakresie podstawowej bazy danych i planowania zasobów przedsiębiorstwa (ERP), ma znaczącą pozycję na rynku BI. Oracle oferuje zintegrowane BI ze swoimi aplikacjami transakcyjnymi i ERP - na przykład zrównoważone karty wyników i narzędzia analityczne wbudowane w pakiet Supply Chain. Oracle, podobnie jak Microsoft, jest obecny na całym stosie technologii BI. Dyrektor generalny Oracle, Larry Ellison, kieruje się tą samą filozofią dotyczącą BI, co w przypadku innych nisz oprogramowania: przekonać klientów, że integracja to ból głowy i że uzyskanie ujednoliconej platformy od jednego dostawcy (i być może poświęcenie trochę w niektórych obszarach) jest lepsze niż podejmowanie najlepszych rasowe podejście, które może wymagać szerokiej integracji. Dedykowane rozwiązania Oracle dla hurtowni danych obejmują Warehouse Builder i Oracle BI Enterprise Edition (zasadniczo stara platforma analityczna Siebel, połknięta podczas przejęcia), a także platformy do tworzenia i integrowania rozwiązań BI dla klientów. Następnie zintegrowano aplikację do zarządzania wydajnością PeopleSoft i rozwiązania Essbase OLAP firmy Hyperion. Jeśli to brzmi jak wiele ruchomych części, to tak jest. Jednym z głównych zarzutów dotyczących podejścia Oracle do BI jest to, że przez lata byli tak przejęci - i mają tak wiele równoległych i specjalistycznych ofert - że trudno jest poruszać się po całym ich menu ofert bez zgubienia drogi. Każde nowe przejęcie oznacza, że gigant oprogramowania musi podjąć wysiłek integracyjny, który może zająć lata. Oracle planuje połączyć wszystkie te ruchome części w 2008 r. w pakiet produktów o nazwie Oracle Fusion, który połączy aplikacje korporacyjne, technologię baz danych, funkcje BI i inne zalety pod parasolem ujednoliconego oprogramowania pośredniczącego. Pakiet Business Intelligence Suite będzie zawierał następujące produkty podrzędne w różnych stanach pakietowania:

•  Panel
•  Odpowiedzi (zapytanie, raportowanie, analiza)
•  Dostarcza (wiadomości i alerty)
•  Wydawca (dystrybucja i routing raportów)
•  Essbase Analytics (uniwersalny OLAP)
•  Odłączona analityka
•  Warehouse Builder (ETL, jakość danych, zarządzanie metadanymi)

Produkty Oracle są drogie, a ich produkty BI nie są wyjątkiem. Pakiet BI Suite Enterprise Edition kosztuje 1500 USD za nazwanego użytkownika lub 225 000 USD za procesor serwera. Dobrą wiadomością jest to, że współpracuje z innymi źródłami danych; jeśli nie masz wystarczająco dużo zarysowania, aby zbudować swoje rozwiązanie na bazie danych Oracle, możesz użyć czegoś tańszego i nadal oczekiwać, że zadziała. Następna generacja produktów Oracle będzie nosiła nazwę 11g, będzie miała architekturę w większym stopniu opartą na zdarzeniach i ukaże się pod koniec 2008 roku. ścieżki technologii pojedynków (na przykład istnieją dwie platformy OLAP i dwa podejścia oparte na hurtowniach danych). Ponadto Oracle dokona poważnej aktualizacji swojej aplikacji do obsługi kart wyników. Oczywiście wszystko to może ulec zmianie.
Powrót

29.09.2021

Microsoft

Mały oddział Billa Gatesa z Waszyngtonu ma zwyczaj zakłócania porządku, gdy wchodzi na nowy rynek. Na początku Microsoft dobrze bawi się z konkurencją, budując jej poziom komfortu; potem wyciąga się na kanapie i zaczyna czuć się jak w domu. Wizja Gatesa obejmuje lepsze zarządzanie informacjami (niezależnie od tego, czy zaczyna się od za dużo, czy za mało) - i to właśnie robi jego firma. Po powolnym początku Microsoft jest obecnie jednym z największych graczy na rynku BI, dzięki popularnemu produktowi bazy danych dla przedsiębiorstw, SQL Server.

Microsoft Office

Office znajduje się na większości biznesowych komputerów osobistych na świecie, zapewniając naturalne środowisko dla front-endowego BI. W szczególności Microsoft wbudował Excela w potężne narzędzie BI; w szczególności te funkcje są bardzo przyjazne dla BI:
•  Excel działa jako mechanizm zapytań i analiz dzięki zaawansowanym funkcjom tabel przestawnych.
•  Excel oferuje atrakcyjny mechanizm raportowania i wizualizacji dla niemal każdego rodzaju środowiska danych.
•  Funkcjonalność arkusza roboczego można teraz osadzać w innych miejscach poza programem Excel, za pośrednictwem coraz ważniejszego pakietu oprogramowania pośredniczącego SharePoint.

Tabele przestawne od lat pomagają pracownikom wiedzy w wykonywaniu funkcji BI i są lepsze niż kiedykolwiek w pakiecie Office 2007. Nawet nowe opcje formatowania warunkowego firmy Microsoft mogą wnieść znaczną wartość do działań BI: gdy łatwiej zrozumieć tabele przestawne, prawdopodobnie przyniesie spostrzeżenia biznesowe.

Serwer SQL

Microsoft ma zademonstrować swój produkt bazodanowy nowej generacji, SQL Server 2008, gdzieś w połowie (no cóż, tak) 2008 roku. Flagowy system DBMS firmy Microsoft jest intensywnie rozwijany w celu poprawy możliwości analizy biznesowej w niektórych kluczowych obszarach:

•  Zarządzanie danymi nieustrukturyzowanymi: jest to jedna z wielu "następnych granic" integracji i eksploatacji informacji. Łatwo jest dodać dane dotyczące sprzedaży i jak najlepiej je wykorzystać, ale w jaki sposób firmy mogą uzyskać kluczowe informacje na podstawie danych nieliczbowych?
•  Wizualizacja: Firma Microsoft zwiększyła możliwości wizualizacji w swoim pakiecie raportowania, licencjonując kod od firmy specjalizującej się w raportowaniu i wizualizacji (Dundas Data Visualization), która wnosi możliwości tworzenia map i wykresów do następnej generacji. Te funkcje są dodatkiem do standardowej taryfy SQL Server BI:
•  Usługi integracyjne: znane od lat jako usługi transformacji danych (DTS), jest to narzędzie ETL firmy Microsoft.
•  Usługi analityczne: Oferowanie usług OLAP i eksploracji danych z wykorzystaniem tak zwanego zunifikowanego modelu danych firmy Microsoft.
•  Usługi raportowania: niezawodne narzędzie do tworzenia raportów i komunikacji oferowane po raz pierwszy z SQL Server 2005
•  Narzędzia prezentacji: wykorzystanie przez firmę Microsoft pulpitu nawigacyjnego i oprogramowania do wizualizacji ProClarity po raz pierwszy daje firmie Bill Gates & Co.

Powrót

30.09.2021

SAP

SAP jest wiodącym na świecie dostawcą Enterprise Resource Platform (ERP), dlatego też przyjmuje nieco inne spojrzenie na BI. SAP oferuje swój magazyn biznesowy i inne narzędzia związane z BI jako część większych pakietów technologicznych, a nie jako samodzielne produkty. Jedynymi firmami korzystającymi z narzędzi SAP BI są te, które już korzystają z oprogramowania ERP.

IBM

W przeciwieństwie do Oracle i Microsoft, Big Blue jest bardziej zaangażowany w grę partnerską niż cokolwiek innego, koncentrując się na swojej podstawowej platformie zarządzania bazą danych DB2 i serwerze aplikacji Websphere jako platformie, z której można układać oferty BI. Zamiast stawiać czoła konkurentom, jak to czasami robią inni wielcy dostawcy, IBM pielęgnuje relacje z firmami programistycznymi, które mają lepszą pozycję do natychmiastowej pomocy swoim klientom. DB2 to podstawowy system DBMS IBM. Można go kupić w konfiguracji hurtowni danych o nazwie DB2 Warehouse Edition (wersja 9.1 to najnowsza wersja). Oferuje to programistom narzędzia do tworzenia zintegrowanych przepływów danych, eksploracji danych i analiz - wszystko za pośrednictwem pakietów Alphablox i Cubeviews (oba produkty poprzednich przejęć). IBM od dawna współpracuje z Hyperionem i jego produktem Essbase OLAP, co daje mu solidnego partnera w wielowymiarowej przestrzeni rynkowej analitycznej. Ale to partnerstwo wygasło w 2005 roku, przez co IBM wydawał się trochę pozbawiony steru. Od tego czasu podjęli bardziej agresywne ruchy w środku stosu BI, w tym zakup dostawcy integracji danych DataMirror Technology w połowie 2007 roku.
Powrót