av Doble Engineering Company i Enterprise Asset Management / Juni 25, 2020
dela detta…
Facebook
Pinterest
Twitter
Linkedin
världen av data och analys utvecklas ständigt. Under sina enklare dagar bestod typisk dataorganisation av vissa filer, applikations-eller transaktionsdatabaser, datalager och rapporteringsdatamarter. Eftersom datakällor, volymer, generationshastigheter och insamlingsprocessen har vuxit genom åren måste dagens datormiljö hantera extremt stora datamängder – vanligtvis kallade big data – som avslöjar mönster, trender och mer, på vilka organisationer kan basera beslut.
de flesta organisationer har idag många, om inte alla, av de komponenter som lyfts fram i referensarkitekturen som förmedlas i Figur 1-applikationer, system och källor, dataöverföring, företagsdatalager, datatjänster, analys och rapportering och avancerad databehandling.
Figur 1-komplex referensarkitektur
med datalager och marts representerade som en av 28 möjliga komponenter är det svårt att förstå hur de passar in i bilden vid första anblicken. Men de flesta organisationer är för närvarande intresserade av mer än ett datalager – de måste sammanhängande hantera en komplex miljö som den som visas i Figur 1.
Kimball-och Inmon-arkitekturer erbjuder båda ramar för att hjälpa till med utvecklingen av komplex referensarkitektur.
Snabbuppdatering på de två tillvägagångssätten
innan du använder Kimball-eller Inmon-mönstren är det värt att granska skillnaderna mellan de två metoderna. Kolla in de visuella representationerna för var och en i Figur 21 och figur 32 .
arbetet med Kimball och Inmon – grundarna av respektive modeller – utmanade varandra. Medan båda tillvägagångssätten huvudsakligen drivs av utvecklingscykeln för en datamodell, är modellerna baserade på ett målmedvetet fokus på antingen en bottom up eller en top down-strategi. Dessa spänningar spelade ut i utvecklingen av de övergripande datalagrings-och analysmiljöerna.
Figur 2-visuell Kimball
Visa Figur 3-Visual Inmon View
Kimball-metoden indikerar att datalager och datamarter drivs av affärsprocesser och affärsfrågor. Den uppenbara faran för detta är användbara data kan inte nödvändigtvis kategoriseras eller fångas eftersom det inte skulle passa in i affärsprocessen som definieras.
Inmon-metoden indikerar skapandet av ett företagsdatalager med logiska modeller utformade för varje enhet runt ett ämne, till exempel mätare, faktura och tillgång. Utmaningen är medan de viktigaste ämnena kan representera differentiering, de enheter som stöder dem kan representera gemensamma saker som kan gå förlorade.
till exempel kan platsen för en mätare som representeras av en tjänstplats, faktureringsadressen som representeras i fakturan och lagerplatsen eller distributionsplatsen för en tillgång alla dela gemensamma attribut. Även under Inmon finns det en risk att servicelokalisering, faktureringsadress, tillgång, lagerplats och tillgångsdistributionsplats kan representeras som fem olika objekt, eftersom de anses stödja olika vertikaler i organisationen med olika datamarter.
både inmon-och Kimball-tillvägagångssätten drivs av cykeln för att utveckla den konceptuella datamodellen och sedan implementera datamodellerna i en fysikaliserad form. Denna cykel kan stödja mer smidiga utvecklingsmetoder, men den kommer närmast att anpassas till en vattenfallstyp av utvecklingsmetod på grund av forskningens linjäritet (baserat på process-eller företagsämnet), utvecklingen av den konceptuella modellen (baserat på data i processen eller företagsämnet) och utvecklingen av den fysiska modellen.
ta nästa steg
en smidig process kan göra det svårt att injicera cykler i denna typ av utvecklingsaktivitet. Utmaningen för varje organisation kommer att vara att ta lärdomarna från inmon-och Kimball-tillvägagångssätten och tillämpa dem i ett nytt sammanhang.
mer information om hur man applicerar mönstren i en komplex miljö för att komma i del två av denna bloggserie-håll dig uppdaterad!
under tiden, kolla in vårt senaste inlägg om framgångsrikt genomförande av enterprise information management (EIM).
