Dobici:
- Sposobnost objašnjavanja konceptualnih, logičkih i fizičkih modela podataka i koncepata normalizacije te izrade nacrta odnosa entiteta uz podršku umjetne inteligencije
- Sposobnost izrade nacrta rječnika podataka, poslovnih pravila i odnosa tablica sa strukturiranim upitima i njihova provjera u odnosu na stvarni sustav
- Sposobnost kritičke procjene prijedloga shema koje je generirala umjetna inteligencija u smislu integriteta, singularnosti i usklađenosti s poslovnim pravilima.
Informacijski sustav je u biti struktura koja organizira podatke. Modeliranje podataka zadatak je dizajniranja činjenica o poslovanju (kupac, narudžba, proizvod, faktura) i njihov međusobni odnos na strukturiran način. Dobar podatkovni model temelj je točnog izvješćivanja, brzih upita i dosljednih podataka; Loš model je izvor godina nedosljednosti i rada na ispravljanju koji se ponavlja. Većinu vremena stručnjak za MIS ne kodira model od nule, već provjerava je li model u skladu s poslovnim pravilima i prevodi model između poslovne jedinice i IT-a.
Modeliranje podataka odvija se na tri razine apstrakcije. Konceptualni model (engleski conceptual) je najviša razina: koji glavni entiteti postoje i kako su povezani? "Kupac naručuje, narudžba uključuje proizvod." Nema tehničkih detalja. Logički model definira atribute (polja), ključeve i tipove odnosa svakog entiteta; ali još uvijek nije vezan za određeni proizvod baze podataka. Fizički model (engleski physical) je konkretna verzija tablica, tipova podataka i indeksa u određenoj bazi podataka (npr. SQL Server, PostgreSQL). Ove tri razine sve su detaljnije verzije iste ideje.
Entitet-odnos i ključevi
Osnovni jezik podatkovnog modela je Entity-Relationship (ER) model. Entitet se može zamisliti kao tablica: Kupac, Narudžba. Atribut je stupac tablice: ime, email, iznos. Odnos je način na koji su entiteti povezani: kupac može imati mnogo narudžbi (odnos jedan prema više).
Dva su kritična ključna koncepta. Primarni ključ je polje koje jedinstveno identificira svaki redak u tablici; na primjer CustomerID. Strani ključ je polje u jednoj tablici koje pokazuje na primarni ključ druge tablice; CustomerID u tablici narudžbi povezuje koja je to narudžba kupca. Ove veze osiguravaju referentni integritet: narudžba se ne može postaviti za kupca koji ne postoji.
Savjet: kada AI generira ER nacrt, olakšava izričito zahtijevanje primarnog ključa za svaku tablicu i stranog ključa za svaki odnos. Ali provjerite svaki strani ključ predložen modelom u odnosu na stvarno poslovno pravilo: ponekad je odnos za koji mislite da je "jedan-prema-više" zapravo "više-prema-više".
Normalizacija: Sprječavanje ponavljanja
Normalizacija je proces smanjenja redundantnosti i očuvanja cjelovitosti dijeljenjem podataka u logičke tablice. Cilj je držati iste informacije na jednom mjestu. Na primjer, umjesto da stalno iznova upisujete adresu kupca u svaki redak narudžbe, zadržite adresu jednom u tablici Kupac i povežete je sa stranim ključem iz narudžbe. Na ovaj način, kada se adresa promijeni, ažurirate je na jednom mjestu; Inače će stotine narudžbi imati različite adrese. To se zove anomalija ažuriranja.
Suprotno od normalizacije je denormalizacija: namjerno dopuštanje nekih ponavljanja radi brzine izvještavanja. U poslovnim sustavima (operativne baze podataka) općenito se preferira normalizacija, au sustavima izvještavanja (skladište podataka) često se preferira denormalizacija. Dakle, "normalizacija nije uvijek dobra"; Odluka se donosi prema namjeni.
Rječnik podataka: zajednički jezik
Rječnik podataka je dokument koji definira što svako polje znači, njegovu vrstu, ograničenja i poslovno pravilo. Što znači polje "status"? Koje vrijednosti može poprimiti (na čekanju, odobreno, otkazano)? Je li to obavezno? Bez ovog dokumenta, različiti će timovi različito tumačiti isto polje i izvješće će biti iskrivljeno. Rječnik podataka je lingua franca organizacije i jedan od najvrjednijih rezultata MIS stručnjaka. AI može brzo izdvojiti početni nacrt rječnika podataka iz postojeće strukture tablice; Ali samo jedinica koja koristi te podatke potvrđuje pravo poslovno značenje svakog polja.
Tri mini kućišta: po brojevima
Slučaj 1 — Trošak ponavljanja. U distribucijskom poduzeću adresa kupca držana je odvojeno u tablicama narudžbi i faktura. Kada se kupac preselio, adresa je ažurirana samo u jednoj tablici; Na staru adresu otišlo je 1.400 faktura i vraćeno im je. Ako je adresa normalizirana u jednoj tablici, jedno ažuriranje bilo bi dovoljno. Projekt sanacije koštao je 2 tjedna.
Slučaj 2 — Pogrešna vrsta veze. Stručnjak za MIS u obrazovnoj ustanovi priznao je odnos (jedan prema više) „Učenik pripada razredu” u modelu generiranom umjetnom inteligencijom. Međutim, učenici su mogli upisati više od jednog izbornog predmeta; Odnos je zapravo bio mnogo-prema-više i bila je potrebna međutablica (Record). Greška je otkrivena na terenu kada se učenik nije upisao u drugi razred. Da je AI-jev prijedlog bio potvrđen, bio bi uhvaćen od samog početka.
Slučaj 3 — Vrijednost rječnika podataka. Utvrđeno je da polje "policy_status" u osiguravajućem društvu različito tumači 5 različitih timova, pa je isti KPI dao 3 različita rezultata u izvješćima. Izradom rječnika podataka koji pokreće umjetna inteligencija i postizanjem jedinstvenog dogovora s poslovnom jedinicom, nedosljednost izvješća je eliminirana, a vrijeme mjesečnog sastanka za usklađivanje smanjeno je za 60%.
Slab upit / Jak upit
Slab upit:
Dizajnirajte bazu podataka e-trgovine.
Snažan upit:
Vaša uloga: Vi ste iskusni modelar podataka. NACRT LOGIČNOG modela podataka u skladu sa sljedećim poslovnim pravilima. Pravila:- Za svaki entitet: polja, primarni ključ, obavezna polja.- Za svaki odnos: tip (jedan-prema-više / više-prema-više) i strani ključ.- Predložite međutablicu u odnosima više-prema-više.- Normalizirajte do 3. normalnog oblika; Ako preporučujete namjernu denormalizaciju, napišite obrazloženje.- Označite [POTREBNA POTVRDA] svako poslovno pravilo za koje niste sigurni. Poslovna pravila:- Kupac može postaviti više narudžbi.- Narudžba sadrži više proizvoda; Jedan proizvod pojavljuje se u više narudžbi.- Proizvodi imaju kategorije.[ostala pravila...]
Snažni prompt pojašnjava razinu modela (logičku), pravila ključa i odnosa, cilj normalizacije i točke koje zahtijevaju potvrdu.
Četiri predloška za kopiranje
1) Nacrt rječnika podataka:
Nacrt rječnika podataka slijedi iz definicije tablice. Za svako polje: naziv, tip, je li obavezno, moguće vrijednosti, poslovno značenje (oznaka[PREDVIĐANJE] ako je predviđanje). Tablica: [DDL ili popis polja]
2) Pregled normalizacije:
Postoji li rizik od dupliciranja podataka, anomalije ažuriranja i mogućnosti normalizacije u strukturi tablice u nastavku? Za svaki nalaz napiši koji normalni oblik narušava i svoj prijedlog. Struktura: [tekst]
3) ER nacrt iz poslovnog pravila:
Prevedite sljedeća poslovna pravila u entitete, atribute i odnose. Navedite vrstu svakog odnosa (1-1, 1-N, N-N) i ako je N-N, predložite međutablicu. Označite dvosmislena pravila. Pravila: [tekst]
4) Pitanja za provjeru vrste odnosa:
Za svaki odnos u podatkovnom modelu u nastavku generirajte poslovno pitanje "da/ne" koje će testirati ispravnost njegove vrste (npr. "Može li učenik biti upisan u više od jednog razreda u isto vrijeme?"). Model: [tekst]
Tablica usporedbe: Razine modela
značajka
pojmovni
logično
fizički
Detalj
najmanje
srednji
većina
ključ/odnos
Glavna imovina
Definirani ključevi
Uključujući indeks/tip
Ovisi o bazi podataka
br
br
da
ciljanu publiku
poslovna jedinica
analitičar
Programer/DBA
Doprinos AI
nacrt
jak propuh
Nacrt, DBA potvrda
Uobičajene greške
- Razmišljanje o odnosu više-prema-više kao jedan-prema-više. Ovo je najčešća pogreška modeliranja; Ako je međutablica zaboravljena, sustav ne može zadržati stvarno stanje.
- Stavljanje svega u jednu tablicu. Skupljanje svih polja u jednu tablicu radi "jednostavnosti" proizvodi dupliciranje i anomalije ažuriranja.
- Ne piše rječnik podataka. Isti KPI daje različite rezultate kada značenje polja ostane u umu.
- Slijepo vjerujući AI-jevim preporukama o vrstama podataka i ograničenjima. Model može predložiti "dovoljno veliko" područje; Poslovno pravilo određuje stvarna ograničenja (npr. TR ID 11 znamenki).
- Apsolutiziranje normalizacije. Pretjerana normalizacija na sloju izvješćivanja usporava upit; Svrha se razlikuje ovisno o kontekstu.
Oprez: Umjetna inteligencija može proizvesti modele koji izgledaju lijepo, ali krše poslovna pravila. Za svaki odnos koji predlaže model, pitanje "je li stvarno ovako?" Postavite poslovno pitanje. Model podataka je kostur sustava; Prijelom kostura kasnije je vrlo teško sanirati.
Ukratko
Modeliranje podataka je proces strukturiranja poslovnih činjenica s entitetima, atributima i odnosima i odvija se na konceptualnoj, logičkoj i fizičkoj razini. Primarni i strani ključevi osiguravaju referentni integritet; Normalizacija smanjuje ponavljanje, ali denormalizacija je također legitimna ovisno o svrsi. Rječnik podataka zajednički je jezik organizacije. AI pruža značajnu brzinu u izradi ER nacrta, rječnika podataka i pregleda normalizacije; međutim, tipovi odnosa, tipovi podataka i poslovna semantika moraju se potvrditi u odnosu na stvarno poslovno pravilo. Samo zato što model izgleda dobro ne znači da je i pravi.
Zadatak aplikacije
Razmotrite "sustav knjižnične posudbe": članovi, knjige, evidencija posudbe. (1) Imajte nacrt logičkog modela koji je proizveo moćni brz. (2) Testirajte vrstu svakog odnosa koji model predlaže (točnije, "može li član imati više od jednog primjerka iste knjige?") s poslovnim pitanjem. (3) Pronađite barem jedan odnos više-prema-više i definirajte međutablicu. (4) Napišite retke rječnika podataka za najmanje 4 polja (naziv, tip, obavezno, poslovno značenje). (5) Istaknite ograničenje koje je model možda uklopio i objasnite kako biste to provjerili.
popis za provjeru
- [ ] Definiran je primarni ključ svake tablice.
- [ ] Provjerio sam vrstu svakog odnosa s poslovnim pitanjem.
- [ ] Definirao sam međutabelu za odnose više-prema-više.
- [ ] Normalizirao sam ili opravdao denormalizaciju dupliciranih podataka.
- [ ] Napisao sam redak rječnika podataka za kritična polja.
- [ ] Potvrdio sam AI-jeve prijedloge vrste podataka/ograničenja u odnosu na poslovno pravilo.