Wprowadzenie do budowy systemów analitycznych

Transkrypt

1 1 Informatyka w Zarządzaniu WYKŁAD III Wprowadzenie do budowy systemów analitycznych MAIL: WWW: KONSULTACJE: andrzej.dudek@ae.jgora.pl piątki sala 80 budynek A

2 Cele i strategie informatyzacji przedsiębiorstw Metodologia CASE 2 FHD (Function Hierarchy Diagram) Diagramu hierarchii funkcji. Służy on do zdefiniowania wszystkich funkcji opisujących system. FHD(DHF) prowadzi do opracowanie szczegółowego modelu potrzeb informacyjnych użytkownika. Celem modelowania funkcji jest również opracowanie takiego modelu, który byłby niezależny od metod realizacji systemu. Korzyścią z jego opracowania jest dokładne poznanie potrzeb informacyjnych użytkownika.

3 Cele i strategie informatyzacji przedsiębiorstw Metodologia CASE 3 PIZZA PRZEZ INTERNET Menu Zamawianie Ewidencja partnerów (pizzeri) Rozliczenia Raporty Ustawienia Edycja listy dań (pizz) Edycja listy składników Edycja listy dodatków Przeglądanie menu online Odnotowanie zamówienia Potwierdzenie zamówienia przez klienta Przekazanie zamowienia do partnera Potwierdzenie zamówienia przez partnera Potwierdzenie realizacji Anulowanie realizacji Dodanie nowega kandydata do współpracy Dopisanie kandydata do bazy Wygenerowanie umowy o współpracy Podpisanie cyfrowe umowy o współpracy Edycja danych partnera Konwersja zamówienia zreal. na rozlicznenie Konwersja rozliczenia anulowanego na rozliczenie Zestawienie rozliczeń dla partnera za okres >> Konwersja rozliczeń na faktury Odnotowanie płatności związanej z rozliczeniami Zamówienia za okres >> Zamówienia wg typów pizzy, składników, dodatków >> Zamówienia wg partnera Efektywność partnera Efektywność portalu i pracowników >> Edycja listy użytkowników (pracowników portalu) Cennik i prowizje Domyślne czasy dostaw Zarządzanie dostępnością zamówień wg odległości od pizzeri Zarządzanie treściami statycznymi na portalu Zarządzanie banerami

4 Cele i strategie informatyzacji przedsiębiorstw Metodologia CASE 4 DFD (Data Flow Diagram) - Diagramu przepływu danych. Służy on do przedstawienia obiektów zewnętrznych, procesów elementarnych, składnic danych oraz powiązań pomiędzy tymi elementami. Obiekty zewnętrzne (terminatory, encje zewn., external entities) - reprezentują zewnętrzne w stosunku do analizowanego systemu źródła powstania i miejsca przeznaczenia informacji (te, które dostarczają i odbierają dane). Składnice danych (magazyny, zbiory, data stores) - reprezentują miejsca przechowywania danych między procesami (dostępne są tylko z procesów). Procesy (funkcje, proceses) - definiują sposób wykonywania jednej lub więcej funkcji (program, procedura, algorytm, operacja ręczna czy zautomatyzowana (całkowicie lub częściowo) - wszystkie czynności wykonywane na danych). przepływy danych (strumienie, data flows) - przedstawiają obieg danych w systemie; powiązania pomiędzy procesami a innymi elementami DFD.

5 Cele i strategie informatyzacji przedsiębiorstw Metodologia CASE Obiekty zewnętrzne (terminatory, encje zewn., external entities) - reprezentują zewnętrzne w stosunku do analizowanego systemu źródła powstania i miejsca przeznaczenia informacji (te, które dostarczają i odbierają dane); KLIENT, DOSTAWCA, BANK i inne. Składnice danych (magazyny, zbiory, data stores) - reprezentują miejsca przechowywania danych między procesami (dostępne są tylko z procesów). Zaistnienie składnicy w DFD ma sens wtedy, kiedy przechowywane tam dane służą realizacji co najmniej dwóch procesów. wszelkiego rodzaju KARTOTEKI. Procesy (funkcje, proceses) - definiują sposób wykonywania jednej lub więcej funkcji (program, procedura, algorytm, operacja ręczna czy zautomatyzowana (całkowicie lub częściowo) - wszystkie czynności wykonywane na danych). Przepływy danych (strumienie, data flows) - przedstawiają obieg danych w systemie; powiązania pomiędzy procesami a innymi elementami DFD. 5

6 Cele i strategie informatyzacji przedsiębiorstw Metodologia CASE 6

7 Cele i strategie informatyzacji przedsiębiorstw Metodologia CASE 7 ERD (Entity Relationship Diagram) - Diagram związków encji. Służy on do przedstawienia dokładnej charakterystyki danych wykorzystywanych przez system i relacji pomiędzy danymi. Obiekty (encje, entities) - osoba, miejsce, zdarzenie, które ma znaczenie dla projektowanego systemu, o tym obiekcie są gromadzone i przechowywane informacje. Encja - składnik rzeczywistości Atrybut cecha opisująca encję, ma za zadanie identyfikować, opisywać, klasyfikować, określać ilość i wyrażać stan encji Związek powiązanie między encjami

8 Cele i strategie informatyzacji przedsiębiorstw Metodologia CASE/ Diagram ERD 8

9 Cele i strategie informatyzacji przedsiębiorstw UML 9 Diagramy ERD, DFD i HFD są narzędziami modelowania relacyjnych baz danych i programów tworzonych w językach strukturalnych. W nowoczesnych systemach tworzonych w Java, C++, C# oraz technologiach ORM (Object Relational Mapping) takich jak Hibernate, do obiektowego projektowaniu systemów służy język UML (Unified Modeling Language) definiujący własne typy diagramów takie jak: diagramy klas modelowanie statycznej struktury systemu; diagramy rozmieszczenia modelowanie przestrzennego rozmieszczenia składników systemu; diagramy komponentów modelowanie fizycznych elementów wchodzących w skład systemu i powiazań między nimi; diagramy interakcji modelowanie zależności w przesyłaniu komunikatów pomiędzy obiektami w systemie; diagramy aktywności modelowanie czynności i zakresu odpowiedzialności elementów i użytkowników systemu; diagramy sekwencji modelowanie sposobu i kolejności współdziałania procesów w systemie; diagram użycia modelowanie funkcjonalności system

10 Bazy danych 10 Baza danych to zbiór danych o określonej strukturze. zapisany na zewnętrznym (trwałym) nośniku pamięci komputera. Zgodnie z tą definicją bazami danych są również systemy plików na dyskach komputera, jednak nowoczesne bazy danych są powiązane z wyspecjalizowanymi programami zarządzającymi określanymi często jako SZBD (system zarządzania bazą danych) takimi jak: ORACLE, MS SQL. POSTGRESQL, MYSQL, FIREBIRD, SAP DB, DB2, MS ACCESS. (i inne)

11 Bazy danych 11 Programy tego typu powinny: - Zapewniać odpowiednią organizację danych na poziomie fizycznym (w pamięci komputera); - Dbać o zachowanie integralności danych oraz umożliwiać definiowanie reguł integralności; - Dbać o poufność danych i umożliwiać dostęp do nich tylko autoryzowanym użytkownikom; - Zapewniać możliwość pracy współbieżnej wielu użytkownikom równocześnie i unikać tzn. zderzeń poprzez zaawansowane mechanizmy takie jak transakcje, blokowanie pesymistyczne czy blokowanie optymistyczne; - Zapewniać niezawodność danych i eliminować w miarę możliwości błędy związane z zapisem / odczytem danych z nośników pamięci poprzez mechanizm tzn. mirroringu oraz możliwość tworzenia kopii zapasowych; - Definiować język dostępu do danych. W przypadku zdecydowanej większości baz danych tym językiem jest strukturalny język zapytań SQL Structural Query Language

12 Bazy danych 12 Można wyróżnić cztery najważniejsze modele baz danych (choć należy nadmienić, iż praktycznie wszystkie programy typu SZBD funkcjonują w modelu relacyjnym): Model hierarchiczny Baza danych w tym modelu reprezentuję strukturę drzewiastą z jednym wydzielonym obiektem głównym i powiązaniami jednokierunkowymi z pozostałymi obiektami. Zgodnie z nazwą w tym modelu zakłada się, iż pomiędzy modelowanymi obiektami opisującymi fragmenty rzeczywistości zawsze zachodzi związek typu obiekt nadrzędny obiekt podrzędny Szybko okazało się, iż to założenie zbyt mocno ogranicza proces modelowania i aktualnie ten model jest tylko modelem historycznym. Model sieciowy Model sieciowy usuwał ograniczenia modelu hierarchicznego umożliwiając definiowanie dowolnych powiązań pomiędzy modelowanymi obiektami. Został zastąpiony przez model relacyjny, gdyż ten ostatni okazał się bardziej efektywny i łatwiejszy do implementacji.

13 Bazy danych 13 Model obiektowy Model, w którym do opisu danych wykorzystywane są pojęcia z zakresu programowania obiektowego takie jak dziedziczenie, enkapsulacja, polimorfizm itp. Model ten powstał mniej więcej na początku lat osiemdziesiątych i nie doczekał się żadnych istotnych realizacji praktycznych. Zamiast tego w ostatnich kilku standardem latach stało się podejście mieszane, mapujące relacyjne bazy danych na obiekty języka Java czy C#, wykorzystujące technologie typu ORM/ORB (Object Relational Mapping/ Object Relational Broker) takie jak Hibernate czy Java Persistence API Model relacyjny Model ten jest rozszerzeniem matematycznego pojęcia relacji (czyli podzbioru iloczynu Kartezjańskiego). Został on opracowany przez E. F. Codda, i mniej więcej od lat osiemdziesiątych poprzedniego stulecia zdecydowana większość SZBD jest oparta właśnie o ten model. Relacja jest pewnym uogólnieniem pojęcia tabeli, przy czym w przeciwieństwie do tabel znanych z MS Excel czy MS Word tabela ta jest zapisywana bezpośrednio w pamięci trwałej komputera a ponadto musi spełniać warunki:

14 Bazy danych relacja w modelu relacyjnym baz danych musi spełniać warunki: 14 Tabela musi mieć określoną jednoznaczną nazwę; Każda kolumna tabeli (pole, atrybut) musi posiadać jednoznaczną nazwę; Każda kolumna tabeli musi zawierać dane określonego typu (np. tekst, liczbę, wartość logiczną, datę, format waluty, itp.); Nie jest istotna kolejność kolumn; Nie jest (nie powinna być) istotna kolejność wierszy (rekordów); Dane w poszczególnych polach (na przecięciu kolumn i wierszy) na są niepodzielne (atomowe); Każda tabela powinna mieć zdefiniowany klucz główny (pole/a niepuste, niepowtarzalne, jednoznacznie identyfikujące rekord). Poprawnie zaprojektowane relacyjne bazy danych powinny spełniać postulaty tzw. III postaci normalnej, co zazwyczaj jest osiągane poprzez proces normalizacji bazy.

15 Normalizacja 15 Model logiczny Encja, krotka, atrybut Model fizyczny Tabela, rekord, pole Bazy danych składają się z dużej ilości tabel połączonych ze sobą i spełniających warunki trzeciej postaci normalnej Pierwsza postać normalna Dane w poszczególnych polach są niepodzielne (np. nie powinno być pola Imię_i_nazwisko tylko dwa osobne pola) oraz nie występuje wielowymiarowość (np. w tabeli faktura pola pozycja1, pozycja2, pozycja3 itp). Jedynym wyjątkiem od reguły w niektórych sytuacjach jest umieszczenie w tabeli dwóch pól opisujących podobne dane (imię, drugie_imię). Unikanie wielowymiarowości jest związane z rozdzieleniem tabel. W przykładzie z fakturą powinno się zaprojektować dwie osobne tabele: faktura i pozycje faktury połączone sprzężone ze sobą. Każda tabela ma w I postaci normalnej zdefiniowany klucz główny (pole/a niepuste, niepowtarzalne, jednoznacznie identyfikujące rekord)

16 Normalizacja 16 Druga postać normalna Żaden podzbiór klucza głównego składającego się z wielu pól nie może sam stanowić klucza (+ pierwsza postać normalna). Najprostszym sposobem spełnienia tego postulatu jest zdefiniowanie wszędzie kluczy składających się z jednego pola. Trzecia postać normalna Brak zależności przechodnich pomiędzy polami tabeli innymi niż klucz (+ druga postać normalna). Zależności przechodnie powodują powtarzanie się danych (redundancję) oraz są zagrożeniem dla integralności bazy, bo to samo pole w jednym rekordzie może mieć inną wartość a w drugim omyłkowo wpisaną inną. Sposobem uniknięcia zależności przechodnich jest rozdzielenie tabel i utworzenie nowej tabeli z polami zależnymi przechodnio.

17 Normalizacja 17 Aby postulaty trzeciej postaci normalnej były spełnione należy w większości przypadków rozdzielić projektowaną tabele na szereg tabel połączonych. Możliwe jest to dzięki mechanizmowi sprzężeń błędnie nazywanych czasami relacjami. Sprzężenie to para pól w dwóch tabelach z których jedno pełni rolę klucza głównego w pierwszej tabeli. Pole w drugiej tabeli nosi nazwę klucza obcego. Przykładowo, jeśli tworzymy bazę danych dotyczącą kolekcji płyt CD, to poprawnie zaprojektowana baza powinna rozdzielać informacje o samej płycie od informacji o utworach. Tabela Płyty mogłaby mieć następujące pola

18 Normalizacja 18 Id_płyty Wykonawca Tytuł Gatunek... 1 U2 Joshua Tree Rock 2 U2 Achtung Baby Rock 3 Kaliber 44 3:44 Hip-Hop 4 Cypress Hill Black Sunday Hip-Hop 5 Vavamuffin Vabang Reggae Natomiast tabela Utwory może zawierać: Id_Utworu Id_Płyty Tytuł Czas_odtw With or without you 2 1 I still haven t found 3 2 One 4 3 Wena 5 3 Konfrontacje 6 3 Masz albo myślisz o nich 7 3 Litery 8 4 I wanna get high 9 4 Insane In The Brain 10 5 Smokin in Jamaica

19 Wprowadzenie do budowy systemów analitycznych Normalizacja 19 Tabele te są sprzężone polem Id_płyty, które w tabeli Płyty jest kluczem głównym a w tabeli Utwory kluczem obcym. Zwróćmy uwagę, że o ile wartości klucza głównego są unikalne, to wartości odpowiadającego mu w tabeli Utwory klucza obcego mogą się powtarzać. Interpretacja sprzężenia tabel w tym wypadku jest dość prosta. Utwór One pochodzi z płyty o id=2 czyli z płyty U2 Achtung Baby, utwór Wena z płyty o id=3 czyli z płyty Kalibra 44 3:44 a utwór Insane in the Brain z płyty Cypress Hill Black Sunday itd.

20 Narzędzia RAD 20 Rapid Application Development narzędzia informatyczne integrujące narzędzia CASE z procesem tworzenia oprogramowania, przyśpieszające tworzenie software u poprzez zastosowanie technik programowania graficznego, zdarzeniowego i komponentowego. Np.: Sun NetBeans, IBM Eclipse, Borland JBuilder KDevelop: biblioteka Qt Microsoft Visual Studio.NET (2003, 2005, 2008): Borland Delphi C++/C#Builder 2006, Turbo Delphi/C++/C#) CodeGear RAD Studio 2007 Oracle Designer Magic

21 Narzędzia RAD 21

22 Narzędzia RAD 22

23 Narzędzia RAD 23 Narzędzia typu RAD coraz częściej wykorzystują podejście obiektowe i UML (Universal Modeling Language) jako język opisu projektu oraz XML (extended Mark-up Language) jako język w którym projekt jest przechowywany* *(diagramy ERD i DFD reprezentują podejście strukturalne)

24 Hurtownia danych 24 Hurtownia danych (ang. data warehouse) rodzaj bazy danych, która jest zorganizowana i zoptymalizowana pod kątem pewnego wycinka rzeczywistości. Hurtownia danych jest wyższym szczeblem abstrakcji niż zwykła relacyjna baza danych (choć do jej tworzenia używane są także podobne technologie). W skład hurtowni wchodzą zbiory danych zorientowanych tematycznie (np. hurtownia danych klientów). Dane te często pochodzą z wielu źródeł, są one zintegrowane i przeznaczone wyłącznie do odczytu. W modelach hurtowni danych mogą występować architektury: Schemat gwiazdy Schemat płatka śniegu Schemat konstelacji Na podstawie:

25 Hurtownia danych 25 Architektura gwiazdy jest najprostszym modelem projektu bazy danych w hurtowni danych. Główną cechą schematu gwiazdy jest centralna tabela, nazywana tabelą faktów, z którą połączone są tabele wymiarów. Model taki umożliwia przeglądanie poszczególnych kategorii, sumaryzację, i filtrowanie danych. W modelu gwiazdy tabela faktów w hurtowni danych jest w trzeciej postaci normalnej, podczas gdy tabele wymiarów reprezentują drugą postać normalną. Tabela faktów zwykle zawiera rekordy gotowe do eksploracji, Rekordy w tabeli faktów mogą być postrzegane jako wydarzenia, co jest spowodowane naturą hurtowni danych. Prawie wszystkie informacje w typowej tabeli faktów są reprezentowane również w jednej lub wielu tabeli wymiarów. Klucz główny każdej z tabeli wymiarów jest związany z tabelą faktów i jest to składowa złożonego klucza głównego tabeli faktów. W schemacie gwiazdy występuje tylko jedna zdenormalizowana tabela dla każdego z wymiarów.

26 Hurtownia danych 26 Architektura płatka śniegu jest bardziej złożoną wersją schematu gwiazdy. Główną różnicą między nimi stanowi fakt, że w schemacie płatka śniegu tabele wymiarów są znormalizowane, czyli są zaprojektowane zgodnie z modelem relacyjnej bazy danych. Schemat płatka śniegu jest używany przede wszystkim wtedy, gdy tabela wymiarów osiąga duże rozmiary i w schemacie gwiazdy jest ciężko przedstawić kompleksowość takiej struktury danych.

27 Wprowadzenie do budowy systemów analitycznych Hurtownia danych 27 Dla każdego schematu gwiazdy lub schematu płatka śniegu można zbudować architekturę konstelacji faktów. Ta architektura jest bardziej złożona od schematu gwiazdy i płatka śniegu, ponieważ może zawierać wiele tabeli faktów. Dzięki temu tabele wymiarów mogą być dzielone i wykorzystywane przez kilka tabeli faktów równocześnie. Rozwiązanie to jest bardzo elastyczne i daje wiele możliwości, jednak odbywa się to kosztem trudności w utrzymaniu. Główną wadą tego rozwiązania jest wysoki stopień skomplikowania, ponieważ podczas analiz należy rozważyć wiele różnych możliwości agregacji.

28 Data Mining 28 Data mining (zgłębianie danych). Data mining jako proces analityczny, przeznaczony jest do eksploracji dużych zbiorów danych (zazwyczaj odnoszących się do zjawisk gospodarczych lub rynkowych), w poszukiwaniu reguł i systematycznych zależności pomiędzy zmiennymi, a następnie do oceny wyników poprzez zastosowanie wykrytych prawidłowości do nowych podzbiorów danych. Ostatecznym celem data mining jest przewidywanie. wizualizacje na wykresach metody statystyczne Analiza dyskryminacyjna Analiza skupień Drzewa klasyfikacyjne (Breiman 1984, Gatnar 2001) sieci neuronowe metody uczenia maszynowego metody ewolucyjne Web mining

29 OLAP Kostka wielowymiarowa (Multidimensional OLAP Cube) 29 Wielowymiarowa kostka OLAP (cube) jest podstawową strukturą danych w każdym systemie OLAP działającym w środowisku Hurtowni Danych. Cube składa się z Miar (Measures), Wymiarów (Dimensions) i Poziomów (Levels) i jest zoptymalizowany pod kątem szybkiego i bezpiecznego dostępu do danych wielowymiarowych. Miary to wskaźniki numeryczne (ile?), natomiast wymiary reprezentują dane opisowe (kto? co? kiedy? gdzie?). Wymiary są pogrupowane za pomocą poziomów, które odzwierciedlają hierarchię funkcjonującą w organizacji i pozwalają użytkownikom końcowym zwiększać lub zmniejszać poziom szczegółowości analizowanego wymiaru.

30 OLAP 30 Z reguły w hurtowni danych jest zdefiniowanych co najmniej kilkanaście wymiarów, a najczęściej spotykanym i wymiarami są: Czas Klient Produkt Lokalizacja Biuro Sprzedaży Hierarchia każdego z wymiarów ustawiona jest za pomocą Poziomów. Przykładowo, hierarchia poziomów może być ułożona w następujący sposób:: wymiar Czas: Rok -> Kwartał -> Miesiąc -> Tydzień -> Dzień Klient: Grupa klientów -> Nazwa klienta Produkt: Linia Produktu -> Grupa Produktu -> Produkt Lokalizacja: Obszar -> Region -> Kraj

31 OLAP 31 Kategorie to elementy danych które opisują poziomy w wymiarach. Przykładowo, dla wymiaru Lokalizacji, w hurtowni danych zostały ustawione poziomy obszaru, regionu i kraju. W tym przykładzie dla Polski kategoriami będą: Obszar - Europa Region - Europa Środkowa Kraj - Polska Typowe, najczęściej występujące Miary w hurtowniach danych to: Przychód netto Przychód brutto Waga Ilość Koszt

32 OLAP 32 Kategorie to elementy danych które opisują poziomy w wymiarach. Przykładowo, dla wymiaru Lokalizacji, w hurtowni danych zostały ustawione poziomy obszaru, regionu i kraju. W tym przykładzie dla Polski kategoriami będą: Obszar - Europa Region - Europa Środkowa Kraj - Polska Typowe, najczęściej występujące Miary w hurtowniach danych to: Przychód netto Przychód brutto Waga Ilość Koszt

33 OLAP 33

34 OLAP 34

35 35 DZIĘKUJĘ ZA UWAGĘ!