Gevinster:
- Evne til å forklare konseptuelle, logiske og fysiske datamodeller og normaliseringskonsepter og produsere utkast til entitetsforhold med støtte fra kunstig intelligens
- Evne til å utarbeide dataordbok, forretningsregler og tabellforhold med strukturerte spørsmål og verifisere dem mot det virkelige systemet
- Evne til kritisk å vurdere AI-genererte skjemaforslag når det gjelder integritet, singularitet og overholdelse av forretningsregler.
Et informasjonssystem er i hovedsak en struktur som holder data organisert. Datamodellering er oppgaven med å designe fakta til en virksomhet (kunde, ordre, produkt, faktura) og deres forhold til hverandre på en strukturert måte. En god datamodell er grunnlaget for nøyaktig rapportering, raske spørringer og konsistente data; En dårlig modell er kilden til år med inkonsekvens og repeterende korrigeringsarbeid. Mesteparten av tiden koder ikke MIS-profesjonelle modellen fra bunnen av, men verifiserer at modellen overholder forretningsreglene og oversetter modellen mellom forretningsenheten og IT.
Datamodellering fortsetter på tre abstraksjonsnivåer. Den konseptuelle modellen (engelsk konseptuell) er det høyeste nivået: hvilke hovedenheter eksisterer og hvordan er de relatert? "Kunden legger inn en bestilling, bestillingen inkluderer produktet." Det er ingen tekniske detaljer. Den logiske modellen definerer attributtene (feltene), nøklene og relasjonstypene til hver enhet; men det er fortsatt ikke knyttet til et spesifikt databaseprodukt. Den fysiske modellen (engelsk fysisk) er den konkrete versjonen av tabellene, datatypene og indeksene i en spesifikk database (f.eks. SQL Server, PostgreSQL). Disse tre nivåene er stadig mer detaljerte versjoner av den samme ideen.
Entitet-forhold og nøkler
Grunnspråket i datamodellen er Entity-Relationship (ER) modellen. Entitet kan betraktes som en tabell: Kunde, Ordre. Attributtet er kolonnen i tabellen: navn, e-post, beløp. Relasjon er hvordan enheter henger sammen: en kunde kan ha mange bestillinger (en-til-mange-forhold).
Det er to kritiske nøkkelbegreper. Primærnøkkel er feltet som unikt identifiserer hver rad i en tabell; for eksempel kunde-ID. En fremmednøkkel er et felt i en tabell som peker til primærnøkkelen til en annen tabell; Kunde-IDen i ordretabellen kobler sammen hvilken kundes ordre det er. Disse forbindelsene sikrer referanseintegritet: en ordre kan ikke legges inn for en kunde som ikke eksisterer.
Tips: Når AI-en skal generere et ER-utkast, gjør det det lettere å eksplisitt be om primærnøkkelen for hver tabell og fremmednøkkelen for hvert forhold. Men kontroller hver fremmednøkkel foreslått av modellen mot den faktiske forretningsregelen: noen ganger er forholdet du tror er "en-til-mange" faktisk "mange-til-mange".
Normalisering: Forebygging av tilbakefall
Normalisering er prosessen med å redusere redundans og bevare integritet ved å dele inn data i logiske tabeller. Målet er å holde den samme informasjonen på ett sted. For eksempel, i stedet for å skrive inn kundeadressen om og om igjen i hver ordrelinje, beholder du adressen én gang i Kundetabellen og kobler den til en fremmednøkkel fra ordren. På denne måten, når adressen endres, oppdaterer du den på ett sted; Ellers vil hundrevis av bestillinger ha forskjellige adresser. Dette kalles oppdateringsavvik.
Det motsatte av normalisering er denormalisering: bevisst tillate noen repetisjoner for å rapportere hastighet. I forretningssystemer (operativ database) foretrekkes generelt normalisering, og i rapporteringssystemer (datavarehus) foretrekkes ofte denormalisering. Så "normalisering er ikke alltid bra"; Avgjørelsen tas i henhold til formålet.
Data Dictionary: Common Language
Dataordbok er et dokument som definerer hva hvert felt betyr, dets type, begrensninger og forretningsregel. Hva betyr "status"-feltet? Hvilke verdier kan det ta (Venter, Godkjent, Kansellert)? Er det obligatorisk? Uten dette dokumentet vil det samme feltet bli tolket forskjellig av ulike team og rapporten vil bli forvrengt. Dataordboken er organisasjonens lingua franca og en av MIS-ekspertens mest verdifulle leveranser. AI kan raskt trekke ut et første dataordbokutkast fra den eksisterende tabellstrukturen; Men bare enheten som bruker disse dataene bekrefter den sanne forretningsbetydningen av hvert felt.
Tre minivesker: etter tallene
Sak 1 — Kostnaden ved gjentakelse. I et distribusjonsselskap ble kundeadressen holdt separat i både ordre- og fakturatabellen. Når en kunde flyttet, ble adressen oppdatert i kun én tabell; 1400 fakturaer gikk til den gamle adressen og ble refundert. Hvis adressen ble normalisert i en enkelt tabell, ville en enkelt oppdatering være tilstrekkelig. Utbedringsprosjektet kostet 2 uker.
Tilfelle 2 – Feil type forhold. En MIS-ekspert ved en utdanningsinstitusjon erkjente (en-til-mange) forholdet "Student tilhører en klasse" i den AI-genererte modellen. Imidlertid kan studenter melde seg på mer enn én valgfri klasse; Forholdet var faktisk mange-til-mange og en mellomtabell (Rekord) var nødvendig. Feilen ble avslørt i feltet da en elev ikke klarte å melde seg inn i andre klasse. Hvis AI-ens forslag hadde blitt bekreftet, ville det blitt fanget opp fra starten.
Tilfelle 3 — Verdi av dataordbok. Det ble fastslått at "policy_status"-feltet i et forsikringsselskap ble tolket ulikt av 5 forskjellige team, så samme KPI ga 3 forskjellige resultater i rapportene. Ved å utarbeide en AI-drevet dataordbok og oppnå enhetlig avtale med forretningsenheten, ble rapportinkonsekvens eliminert og månedlig avstemmingsmøtetid redusert med 60 %.
Svak forespørsel / sterk forespørsel
Svak melding:
Design en e-handelsdatabase.
Kraftig ledetekst:
Din rolle: Du er en erfaren datamodeller. UTSETT en LOGISK datamodell i henhold til følgende forretningsregler.Regler:- For hver enhet: felt, primærnøkkel, obligatoriske felt.- For hver relasjon: type (en-til-mange / mange-til-mange) og fremmednøkkel.- Foreslå mellomtabell i mange-til-mange-relasjoner.- 3. Normaliser form opp til; Hvis du anbefaler tilsiktet denormalisering, skriv begrunnelsen.- Merk [BEKRÆVELSE KREVES] enhver forretningsregel du er usikker på. Forretningsregler:- Kunden kan legge inn flere bestillinger.- En bestilling inneholder flere produkter; Ett produkt forekommer i mange bestillinger.- Produkter har kategorier.[andre regler...]
Den kraftige ledeteksten klargjør modellnivået (logisk), nøkkel- og forholdsregler, normaliseringsmål og punkter som krever bekreftelse.
Fire kopierbare maler
1) Utkast til dataordbok:
En dataordbokskisse følger av tabelldefinisjonen. For hvert felt: navn, type, er det obligatorisk, mulige verdier, forretningsmessig betydning (etikett[PREDICTION] hvis det er en prediksjon). Tabell: [DDL eller feltliste]
2) Normaliseringsgjennomgang:
Er det noen risiko for duplikatdata, oppdateringsavvik og mulighet for normalisering i tabellstrukturen nedenfor? For hvert funn, skriv ned hvilken normal form det bryter med og ditt forslag. Struktur: [tekst]
3) ER-utkast fra forretningsregel:
Oversett følgende forretningsregler til enheter, attributter og relasjoner. Spesifiser typen av hvert forhold (1-1, 1-N, N-N), og hvis N-N, foreslå en mellomtabell. Merk tvetydige regler. Regler: [tekst]
4) Spørsmål om relasjonstypebekreftelse:
For hvert forhold i datamodellen nedenfor, generer et "ja/nei"-forretningsspørsmål som vil teste riktigheten av typen (f.eks. "Kan en student være påmeldt i mer enn én klasse samtidig?"). Modell: [tekst]
Sammenligningsskjema: Modellnivåer
funksjon
konseptuelle
logisk
fysisk
Detalj
i det minste
medium
de fleste
nøkkel/relasjon
Hoved eiendeler
Nøkler definert
Inkludert indeks/type
Avhenger av database
nei
nei
Ja
målgruppe
forretningsenhet
analytiker
Utvikler/DBA
Bidrag av AI
utkast
sterkt utkast
Utkast, DBA-bekreftelse
Vanlige feil
- Tenker på et mange-til-mange-forhold som en-til-mange. Dette er den vanligste modelleringsfeilen; Hvis mellomtabellen glemmes, kan ikke systemet beholde den faktiske tilstanden.
- Setter alt i en tabell. Å samle alle feltene i én tabell for "enkelhetens skyld" produserer duplisering og oppdateringsavvik.
- Ikke å skrive en dataordbok. Den samme KPI gir forskjellige resultater når meningen med feltene forblir i tankene.
- Stoler blindt på AIs anbefaling av datatyper og begrensninger. Modellen kan foreslå et "stort nok" område; Forretningsregelen bestemmer de faktiske grensene (f.eks. TR ID 11 sifre).
- Absoluttiserende normalisering. Overdreven normalisering ved rapporteringslaget bremser søket; Formålet varierer avhengig av konteksten.
Forsiktig: Kunstig intelligens kan produsere modeller som ser fine ut, men som bryter forretningsreglene. For hvert forhold foreslått av modellen, spørsmålet "er det virkelig slik?" Still et forretningsspørsmål. Datamodellen er skjelettet til systemet; Et brudd i skjelettet er svært vanskelig å reparere senere.
Oppsummert
Datamodellering er prosessen med å strukturere forretningsfakta med enheter, attributter og relasjoner og fortsetter på konseptuelle, logiske og fysiske nivåer. Primære og fremmede nøkler sikrer referanseintegritet; Normalisering reduserer repetisjon, men denormalisering er også legitim avhengig av formålet. Dataordboken er organisasjonens fellesspråk. AI gir betydelig hastighet i å produsere ER-utkast, dataordbøker og normaliseringsgjennomganger; relasjonstyper, datatyper og forretningssemantikk må imidlertid bekreftes mot den faktiske forretningsregelen. Bare fordi modellen ser bra ut, betyr det ikke at den er riktig.
Søknadsoppgave
Tenk på et "bibliotekslånssystem": medlemmer, bøker, lånejournaler. (1) Få et logisk modellutkast produsert av den kraftige ledeteksten. (2) Test typen av hvert forhold modellen foreslår (spesifikt "kan et medlem ha mer enn ett eksemplar av samme bok?") med et forretningsspørsmål. (3) Finn minst én mange-til-mange-relasjon og definer en mellomtabell. (4) Skriv dataordboklinjer for minst 4 felt (navn, type, obligatorisk, forretningsmessig betydning). (5) Fremhev en begrensning som modellen kan ha passet og forklar hvordan du vil verifisere den.
sjekkliste
- [ ] Primærnøkkelen til hver tabell er definert.
- [ ] Jeg bekreftet typen av hvert forhold med forretningsspørsmålet.
- [ ] Jeg definerte en mellomtabell for mange-til-mange-relasjoner.
- [ ] Jeg normaliserte eller rettferdiggjorde denormaliseringen av dupliserte data.
- [ ] Jeg skrev en dataordboklinje for kritiske felt.
- [ ] Jeg bekreftet AIs forslag til datatype/begrensninger mot forretningsregelen.