Datamodellering för en bättre analysmiljö. Linus Hjorth

Transkript

1 Datamodellering för en bättre analysmiljö Linus Hjorth

2 Datamodellering för en bättre analysmiljö Affärsvärde Leverans ( IT ) så informationsmodellering också Vad Varför Var - Hur

3 Modeller olika sorters (vad) Informationsmodell beskriver information, hur saker hänger iop Logisk datamodell regler för information i ett system Fysisk datamodell specifikation av system, eller för utveckling

4 Informationsmodeller Kärt barn Subjektsmodell Logisk affärsmodell Konceptuell modell Beskriver hur något är, eller ska bli ut ett affärsperspektiv Inte nödvändigtvis med systemstöd Viktigt för leverans av affärsbehov Men varför/vilken är nyttan

5 Varför informationsmodellera? Ge samsyn Data från olika system Olika användare Olika tillämpningar Riskminimering Färre missförstånd Gör det lättare att prioritera Grund för mappning Rapportkrav Källdata

6 Att tänka på Homonymer Synonymer Klass och instans Ok att modellera, svårare vid verbal kommunikation: Produkt, Modell & enhet Aggregat/beräknade kolumner Total/summa Abstraktion vissa termer med likartad struktur kan bli klassificering ( kod ) Effektivare modell Slutanvändare får svårare att se vad modellen innehåller

7 Notation Kråkfötter (Crow s foot) Personlig favorit Överblick snabbare (jmf siffror/bokstäver) Logisk även affärsanvändare brukar förstå Samma som i datamodellering

8 Logisk datamodell Används för implementering Affärs- eller databasterm (klarspråk förkortningar) Logiska datatyper (text numeriskt belopp antal - datum) Beskriver regler för hur data förhåller sig (till annan data) Överlappar informationsmodellering (dock alltid tabeller och kolumner) Databas-oberoende Krav på IT/utveckling

9 Fysisk datamodell Används vid implementering Databas-specifik Databastermer Fysiska datatyper (INT VARCHAR DATETIME2) Index, partitionering, schema Kan avvika i struktur jmf logisk modell Prestanda Användar-/fråge-krav De-normalisering Vissa regler hanteras vid inmatning/etl

10 Sammanfattning modelltyper Om ditt behov är Kommunikation använd informationsmodell Säkerställa dataintegritet använd logisk datamodell Hantera prestanda använd fysisk datamodell (citat Ronald Damhof) Vad ha var? Info Logisk Fysisk Entitet X X Relation X X Attribut x X Kardinalitet x X X Primärnyckel x X X Främmande nyckel x X X Datatyp x X Tabell X Kolumn X

11 Användningsområden (var) IM LDM FDM FDM IM LDM FDM IM LDM FDM Data Mart Källor Filer Databas Stage Detaljdata ABT Export

12 Komma igång (hur) Intervjuer Dokumentation Affärsdokument (avtal, produktbeskrivningar, reglemente, reklam) Workshopar Specifikt krav (top-down) Allmän sondering innan prioritering (top-down & buttom-up) Processmodeller Jobba aldrig själv

13 Komma igång (hur) Exempel på några metoder SAS Analytics Life Cycle BEAM - Business Event Analysis & Modeling ELM Ensamble Logical Model BIP: Behov Information - Prototyp Likartade, men lite olika resultat

14 SAS Analytics Life Cycle Ask scope, behov Prepare kartlägg behov (informationsmodell) och data Explore analysera data med behov i åtanke Model anpassa data och utveckla statistiska modeller Implement koppla samman modeller med levande data Act gör något åt det som upptäcks Evaluate Följ upp och förfina

15 Business Event Analysis & Modeling - BEAM Fokus dimensionsmodellering Kartläggning av processer och händelser 7W s : Who, What, When, Where, how (many/much), Why, how (did it happen) Fakta: how (many/much) Dimensioner: resten Agile Data Warehouse Design Collaborative Dimensional Modeling, from Whteboard to Star Schema : Lawrence Corr och Jim Stagnitto

16 Ensamble Logical Model - ELM Bygger på BEAM Sprunget ur data vault Genesee Academy Ej public domain Strukturera din information baserat på affärsobjekt, relationer och attribut Affärsobjekt (Core Business Concepts) Plats, person, produkt, sak, händelse Relation naturliga mellan affärsobjekt Attribut: beskriver affärsobjekt

17 BIP Behov Information Prototyp Framtaget av Infotrek presentation SAS Forum SE 2017 Intervjuer och workshop för att dokumentera verksamhet och viktigaste behoven Från detta skapas informationsmodell Viktigaste kraven mappas mot källdata, och prototyp byggs Ska kunna rymmas i en sprint Snabb verifiering av krav, och möjligheterna att uppfylla dem

18 Paradigmer inom (fysisk) datamodellering inom analys/bi Tredje normalformen - 3NF Data Vault & andra ensamble-metoder Dimensionsmodellering Data för analys Big Data

19 POSITION EMPLOYEE PK Position_Id Tredje normalformen -3NF PK Employee_Id Employee_Name Date_Hired FK Employee_Id Position_Start_Date Position_End_Date Job_Code Grunden för modellering i relationsdatabaser sedan urminnes tider Togs in till analys/bi/dw-världen av Bill Inmon Huvudsakligt tillägg är historisering (nya raden när värden förändras) Svårt/går ej att implementera fysisk modell enligt relationsteori Fördel: många känner till teknik Nackdel: inte så flexibel vid förändringar, svårt att få ut data PK PK PK PK EMPLOYEE Employee_Id Emp_Valid_From_Date Emp_Valid_To_Date Employee_Name Date_Hired EMPLOYEE Employee_Id Valid_From_Date Valid_To_Date Employee_No PK PK PK PK FK FK FK POSITION Position_Id Pos_Valid_From_Date Pos_Valid_To_Date Employee_Id Emp_Valid_From_Date Position_Start_Date Position_End_Date Job_Code POSITION Position_Id Valid_From_Date Valid_To_Date Employee_Id Position_No Employee_Name Position_Start_Date Date_Hired Position_End_Date Job_Code

20 dm Bridge Snowflake Model Dimensionsmodellering Dim Syndrom *PK SyndromId: int Syndromnamn: varchar(50) Dim Tid *PK Datum: date Månad: int År: int Kvartal: varchar(6) Dim Klinik *PK KlinikId: int Kliniknamn: varchar(50) Bridge_Diagnos_Syndrom Gjordes populär av Ralph Kimball *pfk DiagnosId: int FK SyndromId: int PrioNr: int Fysiskt implementerad Star Schema Ungefär samma användningsfall som kuber strukturerade ad-hocfrågor Logisk modell Snowflake nivåer i hierarkier normaliseras Dim_Diagnos *PK DiagnosId: int Diagnoskod: varchar(50) Diagnos: varchar(50) FK DiagnosgruppId: int Fakt_Besök Besökstid: time(7) Besökslängd: time(7) Avgift: money FK PatientId: int FK DiagnosId: int FK Datum: date FK MotagningId: int Dim_Mottagning *PK MotagningId: int Mottagningskod: varchar(10) Mottagningsnamn: varchar(50) FK KlinikId: int Relativt enkel att förstå även för användare Brygg-tabeller och andra konstruktioner för att täcka in fler användningsfall lika komplicerat som 3NF Dim_Diagnosgrupp *PK DiagnosgruppId: int Dignosgruppkod: varchar(10) Diagnosgruppnamn: varchar(50) Dim_Patient *PK PatientId: int Namn: varchar(50) Adress: varchar(50) FK PostNr: varchar(0) Dim Postnr *PK PostNr: varchar(5) Postort: varchar(50)

21 dm Data Vault Data Vault & ensembler Employee_Detail *pfk Employee_RK Employee_Nm Position_Cd Manager_Flg *PK Valid_from_Dt * Valid_to_Dt * Processed_DtTm Employee_X_Internal_Org *pfk Employee_RK *FK Internal_Org_RK *PK Valid_from_Dt * Valid_to_Dt * Source_System_Cd * Processed_DtTm Internal_Org_Detail *pfk Internal_Org_RK Internal_Org_Nm *PK Valid_from_Dt * Valid_to_Dt * Processed_DtTm Employee Internal_Org Nästan de-facto standard för data warehouse (detaljdatalager) Uppdelning av information i tre kategorier Affärskoncept (med unik nyckel) Hub Relationer mellan affärskoncept Link Beskrivning av koncept (och ev relation) Satellite Anses flexiblare Separation av nycklar, relation & attribut Relationer alltid M-M Uppdelning av attribut som man behagar Employment *pfk Employee_RK Job_Cd Employee_Nm Position_Cd *PK Valid_from_Dt * Valid_to_Dt * Source_System_Cd * Processed_DtTm *PK Employee_RK Employee_Id * First_Seen_Dt * Last_Seen_Dt * Source_System_Cd * Processed_DtTm Agent *PK Agent_RK FK Employee_RK Agent_Id Agent_Nm *pfk Valid_from_Dt * Valid_to_Dt * Source_System_Cd * Processed_DtTm *PK Internal_Org_RK Internal_Org_Id * First_Seen_Dt * Last_Seen_Dt * Processed_DtTm Internal_Org_Assoc *FK Parent_Internal_Org_RK *pfk Child_Internal_Org_RK *PK Valid_from_Dt * Valid_to_Dt * Source_System_Cd * Processed_DtTm Finns do s och dont s, men fortfarande hantverk

22 Modellera för analys Många olika typer av analyser och statistiska modeller olika krav på design Några vanliga behov: Svårt med kontinuerligas värden. Skapa grupper med intervaller, eller rank Gärna en rad per individ transponering av data (lång till bred) Historik/trend fångas i fler variabler (Amount_Jan, Amount_Feb etc) Flaggor (ny kund 3 mån, är företag, har mer än ett abonnemang) Informationsmodell vid kravställning Fysisk modell för analystabell avancerade användare

23 Big Data/Data Science Rå data Schema on read Blandning av verktyg Strukturerad/semi-struktureradostrukturerad data Fortsatt behov av förstå och koppla samman data Är vad man gör den till GDPR driver på ordning & reda Fokus på dokumentation

24 Nu har du modeller och sen då? Ska alla göra allt? Mognad Fas Komplexitet Hur använder jag mina modeller Bild Skapa upp databas (initialt/nytt forward engineer) Skapa modell från databas (dokumentation - reverse engineer) Skapa/underhålla metadata. I SAS 9.4 via Metadata Bridges Importera Jämföra uppdateringar Vissa begräsningar inte säkert att allt kan importeras

25