Dobički:
- Sposobnost razlage konceptualnih, logičnih in fizičnih podatkovnih modelov in konceptov normalizacije ter izdelave osnutkov entitetnih odnosov s podporo umetne inteligence
- Sposobnost priprave osnutka podatkovnega slovarja, poslovnih pravil in razmerij med tabelami s strukturiranimi pozivi in njihovo preverjanje glede na resnični sistem
- Sposobnost kritičnega ocenjevanja predlogov shem, ustvarjenih z umetno inteligenco, v smislu celovitosti, singularnosti in skladnosti s poslovnimi pravili.
Informacijski sistem je v bistvu struktura, ki ohranja podatke organizirane. Modeliranje podatkov je naloga oblikovanja dejstev o podjetju (stranka, naročilo, izdelek, račun) in njihovega medsebojnega odnosa na strukturiran način. Dober podatkovni model je temelj natančnega poročanja, hitrih poizvedb in doslednih podatkov; Slab model je vir let nedoslednosti in ponavljajočih se popravkov. Večino časa strokovnjak za MIS ne kodira modela iz nič, ampak preveri, ali je model skladen s poslovnimi pravili, in prevaja model med poslovno enoto in IT.
Modeliranje podatkov poteka na treh ravneh abstrakcije. Konceptualni model (angleško conceptual) je najvišja raven: katere glavne entitete obstajajo in kako so povezane? "Kupec odda naročilo, naročilo vključuje izdelek." Tehničnih podrobnosti ni. Logični model definira atribute (polja), ključe in tipe odnosov vsake entitete; vendar še vedno ni vezan na določen izdelek zbirke podatkov. Fizični model (angleško physical) je konkretna različica tabel, tipov podatkov in indeksov v določeni bazi podatkov (npr. SQL Server, PostgreSQL). Te tri ravni so vedno bolj podrobne različice iste ideje.
Entiteta-razmerje in ključi
Osnovni jezik podatkovnega modela je model Entity-Relationship (ER). Entiteto si lahko predstavljamo kot tabelo: stranka, naročilo. Atribut je stolpec tabele: ime, e-pošta, znesek. Razmerje je, kako so entitete povezane: stranka ima lahko veliko naročil (razmerje ena proti mnogo).
Obstajata dva kritična ključna pojma. Primarni ključ je polje, ki enolično identificira vsako vrstico v tabeli; na primer ID stranke. Tuji ključ je polje v eni tabeli, ki kaže na primarni ključ druge tabele; CustomerID v tabeli naročil povezuje naročilo stranke. Te povezave zagotavljajo referenčno celovitost: naročila ni mogoče oddati za stranko, ki ne obstaja.
Namig: Ko AI ustvari osnutek ER, je lažje izrecno zahtevati primarni ključ za vsako tabelo in tuji ključ za vsako razmerje. Vendar preverite vsak tuji ključ, ki ga predlaga model, glede na dejansko poslovno pravilo: včasih je razmerje, za katerega mislite, da je "ena proti mnogo", dejansko "mnogo proti mnogo".
Normalizacija: Preprečevanje ponovitve
Normalizacija je postopek zmanjševanja redundance in ohranjanja celovitosti z delitvijo podatkov v logične tabele. Cilj je ohraniti iste informacije na enem mestu. Na primer, namesto da bi naslov stranke znova in znova vnašali v vsako vrstico naročila, naslov obdržite enkrat v tabeli Stranka in ga povežete s tujim ključem iz naročila. Tako ga ob spremembi naslova posodobite na enem mestu; V nasprotnem primeru bo na stotine naročil imelo različne naslove. To se imenuje anomalija posodobitve.
Nasprotje normalizacije je denormalizacija: namerno dopuščanje nekaj ponavljanja zaradi hitrosti poročanja. V poslovnih sistemih (operativne baze podatkov) je praviloma prednost normalizacija, v sistemih poročanja (skladišče podatkov) pa denormalizacija. Torej »normalizacija ni vedno dobra«; Odločitev je sprejeta glede na namen.
Podatkovni slovar: skupni jezik
Podatkovni slovar je dokument, ki definira, kaj posamezno polje pomeni, njegov tip, omejitve in poslovno pravilo. Kaj pomeni polje "stanje"? Katere vrednosti lahko sprejme (v teku, odobreno, preklicano)? Ali je obvezno? Brez tega dokumenta si bodo različne ekipe različno razlagale isto polje in poročilo bo popačeno. Podatkovni slovar je lingua franca organizacije in eden najdragocenejših rezultatov strokovnjakov MIS. AI lahko hitro izvleče osnutek začetnega podatkovnega slovarja iz obstoječe strukture tabele; Toda samo enota, ki uporablja te podatke, preveri pravi poslovni pomen vsakega polja.
Trije mini kovčki: po številkah
Primer 1 – Stroški ponovitve. V distribucijskem podjetju so naslov stranke hranili ločeno tako v tabeli naročil kot v tabeli računov. Ko se je stranka preselila, je bil naslov posodobljen samo v eni tabeli; 1.400 računov je šlo na stari naslov in so bili povrnjeni. Če bi bil naslov normaliziran v eni tabeli, bi zadostovala ena posodobitev. Projekt sanacije je stal 2 tedna.
2. primer – Napačen tip razmerja. Strokovnjak za MIS v izobraževalni ustanovi je priznal razmerje (ena proti mnogo) »Študent pripada razredu« v modelu, ustvarjenem z umetno inteligenco. Dijaki pa so se lahko vpisali v več kot en izbirni predmet; Razmerje je bilo dejansko veliko proti mnogo in potrebna je bila vmesna tabela (zapis). Napaka se je pokazala na terenu, ko se dijak ni uspel vpisati v drugi razred. Če bi bil predlog AI potrjen, bi ga ujeli že na začetku.
Primer 3 – Vrednost podatkovnega slovarja. Ugotovljeno je bilo, da je polje "policy_status" v zavarovalnici različno interpretiralo 5 različnih ekip, zato je isti KPI v poročilih dal 3 različne rezultate. S pripravo podatkovnega slovarja, ki ga poganja umetna inteligenca, in doseganjem enotnega dogovora s poslovno enoto je bila odpravljena nedoslednost v poročilu, čas mesečnih usklajevalnih sestankov pa se je zmanjšal za 60 %.
Šibek poziv / močan poziv
Šibek poziv:
Oblikujte bazo podatkov o e-trgovini.
Močan poziv:
Vaša vloga: Ste izkušen modeler podatkov. PRIPRAVITE LOGIČNI podatkovni model v skladu z naslednjimi poslovnimi pravili. Pravila: - Za vsako entiteto: polja, primarni ključ, obvezna polja. - Za vsako razmerje: tip (ena proti mnogo / veliko proti mnogo) in tuji ključ. - Predlagajte vmesno tabelo v odnosih veliko proti mnogo. - Normalizirajte do 3. običajne oblike; Če priporočate namerno denormalizacijo, napišite utemeljitev.- Označite [ZAHTEVA SE POTRDITEV] vsako poslovno pravilo, za katerega niste prepričani. Poslovna pravila:- Stranka lahko odda več naročil.- Naročilo vsebuje več izdelkov; En izdelek se pojavlja v več naročilih.- Izdelki imajo kategorije.[druga pravila...]
Zmogljiv poziv razjasni raven modela (logično), pravila ključev in odnosov, cilj normalizacije in točke, ki zahtevajo potrditev.
Štiri kopirane predloge
1) Osnutek slovarja podatkov:
Oris podatkovnega slovarja sledi iz definicije tabele. Za vsako polje: ime, tip, ali je obvezno, možne vrednosti, poslovni pomen (oznaka [NAPOVED], če je napoved). Tabela: [DDL ali seznam polj]
2) Pregled normalizacije:
Ali obstaja tveganje za podvojene podatke, anomalijo pri posodabljanju in možnost normalizacije v spodnji strukturi tabele? Za vsako ugotovitev zapiši, katero normalno obliko krši, in svoj predlog. Zgradba: [besedilo]
3) Osnutek ER iz poslovnega pravila:
Prevedite naslednja poslovna pravila v entitete, atribute in odnose. Določite vrsto vsakega razmerja (1-1, 1-N, N-N) in če je N-N, predlagajte vmesno tabelo. Označite dvoumna pravila. Pravila: [besedilo]
4) Vprašanja za preverjanje vrste razmerja:
Za vsako razmerje v spodnjem podatkovnem modelu ustvarite poslovno vprašanje »da/ne«, ki bo preizkusilo pravilnost njegovega tipa (npr. »Ali je študent lahko vpisan v več kot en razred hkrati?«). Model: [besedilo]
Primerjalna tabela: ravni modela
funkcija
konceptualno
logično
fizično
Podrobnost
vsaj
srednje
večina
ključ/odnos
Glavna sredstva
Ključi določeni
Vključno z indeksom/vrsto
Odvisno od baze podatkov
št
št
ja
ciljno občinstvo
poslovna enota
analitik
Razvijalec/DBA
Prispevek AI
osnutek
močan osnutek
Osnutek, potrditev DBA
Pogoste napake
- Razmišljanje o razmerju veliko proti mnogo kot o razmerju eden proti mnogo. To je najpogostejša napaka pri modeliranju; Če je vmesna tabela pozabljena, sistem ne more ohraniti dejanskega stanja.
- Zložiti vse v eno mizo. Zbiranje vseh polj v eno tabelo zaradi "preprostosti" povzroči podvajanje in anomalije pri posodabljanju.
- Brez pisanja podatkovnega slovarja. Isti KPI daje različne rezultate, če ostane pomen polj v mislih.
- Slepo zaupanje priporočilom AI glede tipov podatkov in omejitev. Model lahko predlaga "dovolj veliko" območje; Poslovno pravilo določa dejanske omejitve (npr. TR ID 11 števk).
- Absolutiziranje normalizacije. Prekomerna normalizacija na ravni poročanja upočasni poizvedbo; Namen se razlikuje glede na kontekst.
Pozor: umetna inteligenca lahko ustvari modele, ki so videti lepi, vendar kršijo poslovna pravila. Za vsako razmerje, ki ga predlaga model, je vprašanje "ali je res tako?" Postavite poslovno vprašanje. Podatkovni model je okostje sistema; Zlom v skeletu je kasneje zelo težko popraviti.
Če povzamem
Modeliranje podatkov je proces strukturiranja poslovnih dejstev z entitetami, atributi in odnosi ter poteka na konceptualni, logični in fizični ravni. Primarni in tuji ključi zagotavljajo referenčno celovitost; Normalizacija zmanjša ponavljanje, vendar je glede na namen legitimna tudi denormalizacija. Podatkovni slovar je skupni jezik organizacije. AI zagotavlja veliko hitrost pri izdelavi osnutkov ER, podatkovnih slovarjev in pregledov normalizacije; vendar je treba tipe odnosov, tipe podatkov in poslovno semantiko potrditi glede na dejansko poslovno pravilo. Samo zato, ker model izgleda dobro, še ne pomeni, da je pravi.
Aplikacijska naloga
Razmislite o "sistemu knjižnične izposoje": člani, knjige, evidenca izposoje. (1) Imejte osnutek logičnega modela, ki ga ustvari močan poziv. (2) Preizkusite vrsto vsakega odnosa, ki ga predlaga model (natančneje, »ima lahko član več kot en izvod iste knjige?«) s poslovnim vprašanjem. (3) Poiščite vsaj eno razmerje veliko proti mnogo in definirajte vmesno tabelo. (4) Zapišite vrstice podatkovnega slovarja za vsaj 4 polja (ime, vrsta, obvezno, poslovni pomen). (5) Označite omejitev, ki ji je model morda ustrezal, in razložite, kako bi jo preverili.
kontrolni seznam
- [ ] Definiran je primarni ključ vsake tabele.
- [ ] Preveril sem vrsto vsakega odnosa s poslovnim vprašanjem.
- [ ] Definiral sem vmesno tabelo za razmerja veliko proti mnogo.
- [ ] Normaliziral sem ali utemeljil denormalizacijo podvojenih podatkov.
- [ ] Napisal sem vrstico podatkovnega slovarja za kritična polja.
- [ ] Potrdil sem predloge vrste podatkov/omejitev AI glede na poslovno pravilo.