Dobici:
- Sposobnost objašnjavanja konceptualnih, logičkih i fizičkih modela podataka i koncepata normalizacije i izrade nacrta odnosa entiteta uz podršku umjetne inteligencije
- Sposobnost izrade nacrta rječnika podataka, poslovnih pravila i odnosa tabela sa strukturiranim upitima i provjere ih u odnosu na stvarni sistem
- Sposobnost kritičke procene predloga šema generisanih veštačkom inteligencijom u smislu integriteta, singularnosti i usklađenosti sa poslovnim pravilima.
Informacioni sistem je u suštini struktura koja održava podatke organizovanim. Modeliranje podataka je zadatak dizajniranja činjenica o poslovanju (kupac, narudžba, proizvod, faktura) i njihovog međusobnog odnosa na strukturiran način. Dobar model podataka je temelj tačnog izvještavanja, brzih upita i konzistentnih podataka; Loš model je izvor godina nekonzistentnosti i ponavljajućeg rada na ispravljanju. Većinu vremena, MIS profesionalac ne kodira model od nule, već provjerava da li je model u skladu s poslovnim pravilima i prevodi model između poslovne jedinice i IT-a.
Modeliranje podataka se odvija na tri nivoa apstrakcije. Konceptualni model (engleski konceptual) je najviši nivo: 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 fizički) je konkretna verzija tabela, tipova podataka i indeksa u određenoj bazi podataka (npr. SQL Server, PostgreSQL). Ova tri nivoa su sve detaljnije verzije iste ideje.
Entitet-odnos i ključevi
Osnovni jezik modela podataka je model entitet-odnos (ER). Entitet se može zamisliti kao tabela: Kupac, Narudžbina. Atribut je kolona tabele: ime, email, iznos. Odnos je način na koji su entiteti povezani: kupac može imati mnogo narudžbi (odnos jedan-prema-više).
Postoje dva ključna ključna koncepta. Primarni ključ je polje koje jedinstveno identifikuje svaki red u tabeli; na primjer CustomerID. Strani ključ je polje u jednoj tabeli koje ukazuje na primarni ključ druge tabele; CustomerID u tabeli narudžbi povezuje o kojoj je narudžbi kupca riječ. 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 eksplicitno traženje primarnog ključa za svaku tablicu i stranog ključa za svaku relaciju. 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: Sprečavanje ponavljanja
Normalizacija je proces smanjenja redundancije i očuvanja integriteta podjelom podataka u logičke tablice. Cilj je zadržati iste informacije na jednom mjestu. Na primjer, umjesto da stalno iznova kucate adresu kupca u svakoj liniji narudžbe, čuvate adresu jednom u tabeli Kupci i povezujete je sa stranim ključem iz narudžbe. Na ovaj način, kada se adresa promijeni, ažurirate je na jednom mjestu; U suprotnom, stotine narudžbi će imati različite adrese. Ovo se zove anomalija ažuriranja.
Suprotnost normalizaciji je denormalizacija: namjerno dopuštanje nekog ponavljanja radi brzine izvještavanja. U poslovnim sistemima (operativna baza podataka), normalizacija je generalno poželjna, au sistemima za izvještavanje (skladište podataka), denormalizacija se često preferira. Dakle, "normalizacija nije uvijek dobra"; Odluka se donosi prema namjeni.
Rječnik podataka: zajednički jezik
Rječnik podataka je dokument koji definira šta svako polje znači, njegov tip, ograničenja i poslovno pravilo. Šta znači polje "status"? Koje vrijednosti može poprimiti (Na čekanju, Odobreno, Otkazano)? Da li je to obavezno? Bez ovog dokumenta, isto polje će različito tumačiti različiti timovi i izvještaj će biti iskrivljen. Rječnik podataka je lingua franca organizacije i jedan od najvrednijih proizvoda MIS profesionalaca. AI može brzo izdvojiti početni nacrt rječnika podataka iz postojeće strukture tabele; Ali samo jedinica koja koristi te podatke potvrđuje pravo poslovno značenje svakog polja.
Tri mini slučaja: prema brojevima
Slučaj 1 — Trošak ponavljanja. U distributivnom preduzeću, adresa kupca se čuvala odvojeno iu tabeli narudžbi i faktura. Kada se klijent preselio, adresa je ažurirana u samo jednoj tabeli; 1.400 faktura je otišlo na staru adresu i vraćeno je. Ako je adresa normalizovana u jednoj tabeli, jedno ažuriranje bi bilo dovoljno. Projekat sanacije koštao je 2 sedmice.
Slučaj 2 — Pogrešan tip odnosa. Stručnjak MIS-a u obrazovnoj instituciji priznao je odnos (jedan prema više) „Učenik pripada klasi“ u modelu generisanom umjetnom inteligencijom. Međutim, učenici su mogli da se upišu u više od jednog izbornog časa; Relacija je zapravo bila više-prema-više i bila je potrebna međutabela (zapis). Greška je otkrivena na terenu kada se učenik nije upisao u drugi razred. Da je sugestija AI bila potvrđena, bila bi uhvaćena od 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štajima. Izradom rečnika podataka sa veštačkom inteligencijom i postizanjem jedinstvenog dogovora sa poslovnom jedinicom, nedoslednost izveštaja je eliminisana i vreme za sastanke mesečnog usaglašavanja smanjeno je za 60%.
Slaba prompt / jaka prompt
Slab upit:
Dizajnirajte bazu podataka e-trgovine.
Snažan upit:
Vaša uloga: Vi ste iskusan modelar podataka. NAPRAVITE LOGIČKI model 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đutabelu u odnosima mnogo-prema-više.- Normalizirajte formu do ; Ako preporučujete namjernu denormalizaciju, napišite obrazloženje.- Označite [POTREBNA POTVRDA] svako poslovno pravilo u koje niste sigurni. Poslovna pravila:- Kupac može poslati više narudžbi.- Narudžba sadrži više proizvoda; Jedan proizvod se javlja u više narudžbi.- Proizvodi imaju kategorije.[druga pravila...]
Moćni prompt pojašnjava nivo modela (logički), ključ i pravila odnosa, cilj normalizacije i tačke koje zahtevaju potvrdu.
Četiri predloška koji se mogu kopirati
1) Nacrt rječnika podataka:
Nacrt rječnika podataka slijedi iz definicije tablice. Za svako polje: naziv, tip, da li je obavezno, moguće vrijednosti, poslovno značenje (oznaka[PREDIKCIJA] ako je predviđanje). Tabela: [DDL ili lista polja]
2) Pregled normalizacije:
Postoji li rizik od dupliranja podataka, anomalije ažuriranja i mogućnosti za normalizaciju u strukturi tabele ispod? Za svaki nalaz napišite koji normalni oblik krši i vaš prijedlog. Struktura: [tekst]
3) ER nacrt iz poslovnog pravila:
Prevedite sljedeća poslovna pravila u entitete, atribute i odnose. Navedite tip svake veze (1-1, 1-N, N-N) i ako N-N, predložite međutabelu. Označite dvosmislena pravila. Pravila: [tekst]
4) Pitanja za verifikaciju vrste veze:
Za svaki odnos u donjem modelu podataka generirajte poslovno pitanje "da/ne" koje će testirati ispravnost njegovog tipa (npr. "Može li učenik biti upisan u više od jednog razreda u isto vrijeme?"). Model: [tekst]
Uporedni grafikon: Nivoi modela
karakteristika
konceptualni
logicno
fizički
Detalj
barem
srednje
većina
ključ/relacija
Glavna imovina
Definirani ključevi
Uključujući indeks/tip
Zavisi od baze podataka
br
br
Da
ciljnu publiku
poslovna jedinica
analitičar
Developer/DBA
Doprinos AI
nacrt
jak nacrt
Nacrt, DBA potvrda
Uobičajene greške
- Razmišljanje o odnosu mnogo-prema-više kao jedan-prema-više. Ovo je najčešća greška u modeliranju; Ako je međutabela zaboravljena, sistem ne može zadržati stvarno stanje.
- Stavljanje svega na jednu tabelu. Okupljanje svih polja u jednu tabelu radi "jednostavnosti" proizvodi dupliranje i anomalije ažuriranja.
- Ne pišem rječnik podataka. Isti KPI daje različite rezultate kada značenje polja ostaje u umu.
- Slijepo vjerovati preporuci AI o tipovima podataka i ograničenjima. Model može predložiti "dovoljno veliko" područje; Poslovno pravilo određuje stvarna ograničenja (npr. TR ID 11 cifara).
- Apsolutizirajuća normalizacija. Pretjerana normalizacija na sloju za izvještavanje usporava upit; Svrha varira ovisno o kontekstu.
Oprez: Umjetna inteligencija može proizvesti modele koji lijepo izgledaju, ali krše poslovna pravila. Za svaku vezu koju predloži model postavlja se pitanje "da li je stvarno ovako?" Postavite poslovno pitanje. Model podataka je skelet sistema; Prijelom skeleta je vrlo teško popraviti kasnije.
Ukratko
Modeliranje podataka je proces strukturiranja poslovnih činjenica sa entitetima, atributima i odnosima i odvija se na konceptualnom, logičkom i fizičkom nivou. Primarni i strani ključevi osiguravaju referentni integritet; Normalizacija smanjuje ponavljanje, ali je i denormalizacija legitimna u zavisnosti od svrhe. Rječnik podataka je zajednički jezik organizacije. AI pruža značajnu brzinu u izradi nacrta ER, rječnika podataka i pregleda normalizacije; međutim, tipovi odnosa, tipovi podataka i poslovna semantika moraju biti potvrđeni u odnosu na stvarno poslovno pravilo. Samo zato što model izgleda dobro ne znači da je ispravan.
Zadatak aplikacije
Razmotrimo „sistem bibliotečke pozajmice“: članovi, knjige, zapisi o posudbi. (1) Imajte nacrt logičkog modela proizveden od strane moćnog prompta. (2) Testirajte tip svakog odnosa koji model predlaže (konkretno, „može li član imati više od jednog primjerka iste knjige?“) poslovnim pitanjem. (3) Pronađite barem jednu vezu više prema mnogo i definirajte međutabelu. (4) Napišite rečnik 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 ga provjerili.
kontrolna lista
- [ ] Primarni ključ svake tablice je definiran.
- [ ] Provjerio sam tip svakog odnosa sa poslovnim pitanjem.
- [ ] Definirao sam međutabelu za relacije mnogo-prema-više.
- [ ] Normalizovao sam ili opravdao denormalizaciju duplih podataka.
- [ ] Napisao sam liniju rječnika podataka za kritična polja.
- [ ] Potvrdio sam sugestije tipa podataka/ograničenja AI protiv poslovnog pravila.