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.
