Fem viktige trinn for kvalitetsdatamodellering

Mange forretningsfolk anser datamodellering for å være en svart kunst praktisert av enterprise IT -avdelingen som ikke gir noen håndgripelige forretningsmessige fordeler og utelukkende er designet for å få dødelige mennesker til å føle seg forvirret og underlegen.

Dessverre er det mange IT -avdelinger som faktisk fremmer denne oppfatningen, og for de som gjør det, leverer datamodelleringen de utfører ingen reelle fordeler – til tross for mumbo -jumboen de synger om det. Det trenger ikke å være slik.

Når det gjøres på riktig måte, kan datamodellering gi enorme forretningsmessige fordeler for ethvert foretak, som inkluderer:

• Informasjon av høyere kvalitet for alle forretningsaktiviteter
• Enklere tilgang til denne informasjonen
• Robuste informasjonssystemer
• Bedre identifisering av produkter, fortjeneste og kostnadssentre.
• Eliminering av overflødig og unødvendig informasjon
• Reduserte kostnader og økte inntekter

Hvordan gjør du dataanalyse og modellering “riktig”? Hvor begynner du?

De følgende to enkle (skjønt fundamental) regler vil veilede deg på veien.

Regel 1: Bruk nøyaktig de samme kildene som du hentet din Forretningsfunksjoner fra for å trekke ut all informasjon for datamodellering.

Regel 2: Kun modelldata som er nødvendig for å direkte støtte bedriftens forretningsfunksjoner.

Starter med Regel 1 vil sikre at du samsvarer med Regel 2.

Den integrerte modelleringsmetoden gir en idiotsikker teknikk for å trekke ut kandidatentiteter, attributter og relasjoner fra kildene som forretningsfunksjonene ble hentet fra. Denne teknikken kan brukes av nybegynnere og erfarne analytikere.

Disse kildene inkluderer:

• Transkripsjoner av tapede analyseintervjuer med ledende bedriftsledere.
• Skrev notater med tilleggsinformasjon fra disse intervjuene.
• Funksjonstitler og beskrivelser utviklet under funksjonsmodellering.
• Informasjonsflytdiagrammer produsert i analyseverksteder.

Teknikk

Den grunnleggende teknikken:

Trinn 1 -Gjennomgå datakildene dine (best å ha disse i elektronisk format) på jakt etter og understreke alle “substantivstrukturer”, siden dette er “kandidat” -enheter.

Steg 2 – Trekk ut alle disse kandidatene, og assosiasjonene mellom dem, i et eget dokument.

Trinn 3 – Konverter disse kandidatene og assosiasjonene til faktiske enheter, attributter og relasjoner.

Trinn 4 – Lag et enhetsrelasjonsdiagram (ERD).

Trinn 5 – Design eventuelle nødvendige relasjonsdatabaser fra ERD.

Eksempel

De første trinnene i teknikken demonstreres best ved hjelp av et eksempel.

Følgende er en del av en transkripsjon av et intervju med en forretningsleder, med alle substantivene understreket.

“Vi mottar ordrene for vår Produkter fra vår kunder de dag før de krever det leveranse. Vi kryss av de mengde av råvarer Forpliktet til bake de Produkter og om nødvendig vi rekkefølge mer fra vår leverandører. Vi bake våre Produkter fersk hver morgen. Vi gjøre leveranser til vår kunder flere ganger Hver dag. På slutt av hver uke vi faktura Hver kunde for leveranser laget til dem under uke. Vi aksepterer innbetaling eller innbetaling fra kunder av penger og kryss av kun”.

Alle substantivstrukturer har blitt understreket.

Den første setningen er:

“Vi mottar ordrene for vår Produkter fra vår kunder de dag* før de krever det leveranse.

Ved å arbeide gjennom setningen ett understreket substantiv om gangen får vi følgende liste over kandidat enheter og foreninger:

rekkefølge [means of ordering] produkt

produkt [ordered by means of] rekkefølge

rekkefølge [received from] kunde

kunde [the source of] rekkefølge

produkt [delivered by means of] leveranse

leveranse [means of delivering] produkt

kunde [recipient of] leveranse

leveranse [made to] kunde

Merk: dag* er et attributt for ordre, sannsynligvis “dato”.

Fordi hver forening er toveis, oppretter vi umiddelbart den motsatte når vi dokumenterer en assosiasjon.

Å jobbe gjennom hele transkripsjonen ovenfor gir oss den flytende komplette listen (sortert alfabetisk):

baking [to produce] produkt

kunde [billed by means of] faktura

kunde [recipient of] leveranse

kunde [source of] innbetaling

kunde [the source of] rekkefølge

leveranse [made to] kunde

leveranse [means of delivering] produkt

leveranse [of products billed on] faktura tbv

faktura [a billing for] produkt

faktura [a means of billing] kunde

faktura [billing for goods delivered by] levering tbv

faktureringsperiode

rekkefølge [means of ordering] produkt

rekkefølge [means of replenishing] råmateriale

rekkefølge [placed with] leverandør

rekkefølge [received from] kunde

innbetaling [accepted from] kunde

innbetaling [made by] betalingsmetode

betalingsmetode [valid means of making] innbetaling

produkt [billed for on] faktura

produkt [delivered by means of] leveranse

produkt [ordered by means of] rekkefølge

produkt [produced by] baking

produkt [requirement for] råmateriale

råmateriale [quantified by means of] aksjesjekk

råmateriale [replenished by means of] rekkefølge

råmateriale [required to bake] produkt

råmateriale [sourced from] leverandør

aksjesjekk [to establish quantity of] råmateriale

leverandør [recipient of] rekkefølge

leverandør [the source of] råmateriale

Dette korte utdraget har gitt oss elleve unike kandidatentiteter og tretti (15 x 2) kandidatforeninger.

Rasjonalisering av enheter

Listen over kandidatentiteter trenger litt mer arbeid for å fjerne falske eller falske enheter. Et typisk eksempel på en kandidatvare som ikke er en riktig enhet er “faktura”. En faktura er sannsynligvis den vanligste forretningsartikkelen som er feilaktig modellert som en enhet. Fakturaen i seg selv er et stykke papir som representerer en forretningsenhet eller en samling enheter, for eksempel et salg (av ett eller flere produkter) eller en fakturering (for ett eller flere salg). Dette er de faktiske dataenhetene som skal modelleres – ikke papirbitene som representerer dem.

Konvertering av foreninger til relasjoner

Foreningene som vi identifiserte må nå også rasjonaliseres og konverteres til “Relasjoner”. Foreninger forteller oss ganske enkelt at to enheter er tilknyttet og gir oss et foreslått navn på denne foreningen. Et forhold forteller oss all den viktige informasjonen vi trenger å vite om foreningen. Dette inkluderer

• det nøyaktige navnet på forholdet
• om det er obligatorisk eller valgfritt
• dens “grad”, det vil si hvis forholdet er en-til-en, en-til-mange eller mange-til-mange

Eksempel

Forhold må kunne leses på følgende måte:

Hver Rekkefølge må være mottat fra en og bare en Kunde

Hver Kunde kan være kilden til en eller fler Ordrene

Forhold er alltid toveis, så det må alltid være to oppføringer for å spesifisere hva de er i begge retninger.

Varene i Modig ovenfor er enhetsnavn.

De understrekede elementene viser alternativet. Obligatoriske forhold er skrevet som må være, valgfrie som kan være.

Elementene i kursiv er forholdsnavn. Disse må navngis slik at de kan gå foran “Må være” eller “Kan være”.

Begrepene “en og bare en” og “en eller flere” definerer graden av forholdet.

Entity Relationship Diagram

All den foregående informasjonen er viktig å vite, men er nesten umulig å visualisere og av begrenset bruk uten å konstruere en Entity Relationship Diagram (ERD). Dette er den mest kraftfulle modellen for bruk i forståelsen av datastrukturen til ethvert foretak og er et vesentlig element i utformingen av kvalitetsdatabaser.

Effektiv oppsett

På en ERD i den integrerte modelleringsmetoden er de “mange” endene av et forhold indikert med et symbol som ligner og kalles en “kråkefot”. Hvis dette symbolet blir snudd på hodet, får vi en “død kråke”. Dette gir opphav til en av de mest kraftfulle, men enkle, reglene for å oppnå et virkelig effektivt oppsett for ethvert ERD, som er “Dead Crows Fly East”.

Nettoresultatet av denne oppsettet er at alle høyvolum og flyktige enheter vil vises øverst og til venstre for ERD, og ​​alle lave volumer og mer konstante enheter vil vises til bunn og til høyre.