Fitimet:
- Aftësia për të shpjeguar modelet konceptuale, logjike dhe fizike të të dhënave dhe konceptet e normalizimit dhe për të prodhuar drafte të marrëdhënieve entitet me mbështetjen e inteligjencës artificiale
- Aftësia për të hartuar lidhjet e fjalorit të të dhënave, rregullave të biznesit dhe tabelave me kërkesa të strukturuara dhe verifikimin e tyre ndaj sistemit real
- Aftësia për të vlerësuar në mënyrë kritike sugjerimet e skemave të krijuara nga AI për sa i përket integritetit, singularitetit dhe pajtueshmërisë me rregullat e biznesit.
Një sistem informacioni është në thelb një strukturë që mban të organizuara të dhënat. Modelimi i të dhënave është detyra e dizajnimit të fakteve të një biznesi (klienti, porosia, produkti, fatura) dhe marrëdhëniet e tyre me njëri-tjetrin në mënyrë të strukturuar. Një model i mirë i të dhënave është baza e raportimit të saktë, pyetjeve të shpejta dhe të dhënave të qëndrueshme; Një model i keq është burimi i viteve të mospërputhjes dhe punës së përsëritur korrigjuese. Në shumicën e rasteve, profesionisti i MIS nuk e kodon modelin nga e para, por verifikon që modeli përputhet me rregullat e biznesit dhe e përkthen modelin midis njësisë së biznesit dhe IT.
Modelimi i të dhënave vazhdon në tre nivele të abstraksionit. Modeli konceptual (konceptual anglisht) është niveli më i lartë: cilat entitete kryesore ekzistojnë dhe si lidhen ato? "Klienti bën një porosi, porosia përfshin produktin." Nuk ka detaje teknike. Modeli logjik përcakton atributet (fushat), çelësat dhe llojet e marrëdhënieve të çdo entiteti; por ende nuk është i lidhur me një produkt specifik të bazës së të dhënave. Modeli fizik (anglisht fizik) është versioni konkret i tabelave, llojeve të të dhënave dhe indekseve në një bazë të dhënash specifike (p.sh. SQL Server, PostgreSQL). Këto tre nivele janë versione gjithnjë e më të detajuara të së njëjtës ide.
Entiteti-Marrëdhënia dhe çelësat
Gjuha bazë e modelit të të dhënave është modeli Entity-Relationship (ER). Entiteti mund të mendohet si një tabelë: Klienti, Porosi. Atributi është kolona e tabelës: emri, emaili, shuma. Marrëdhënia është mënyra se si lidhen entitetet: një klient mund të ketë shumë porosi (marrëdhënie një-me-shumë).
Ekzistojnë dy koncepte kyçe kritike. Çelësi primar është fusha që identifikon në mënyrë unike çdo rresht në një tabelë; për shembull ID-ja e klientit. Një çelës i huaj është një fushë në një tabelë që tregon çelësin kryesor të një tabele tjetër; ID-ja e klientit në tabelën e porosive lidh porosinë e klientit. Këto lidhje sigurojnë integritet referues: një porosi nuk mund të bëhet për një klient që nuk ekziston.
Këshillë: Kur AI të gjenerojë një draft ER, e bën më të lehtë të kërkosh në mënyrë eksplicite çelësin kryesor për secilën tabelë dhe çelësin e huaj për secilën marrëdhënie. Por verifikoni çdo çelës të huaj të sugjeruar nga modeli kundër rregullit aktual të biznesit: ndonjëherë marrëdhënia që mendoni se është "një-me-shumë" është në të vërtetë "shumë-me-shumë".
Normalizimi: Parandalimi i përsëritjes
Normalizimi është procesi i reduktimit të tepricës dhe ruajtjes së integritetit duke i ndarë të dhënat në tabela logjike. Qëllimi është të mbash të njëjtin informacion në një vend. Për shembull, në vend që të shkruani adresën e klientit vazhdimisht në çdo rresht porosie, ju e mbani adresën një herë në tabelën e Klientit dhe e lidhni atë me një çelës të huaj nga porosia. Në këtë mënyrë, kur adresa ndryshon, ju e përditësoni atë në një vend; Përndryshe, qindra porosi do të kenë adresa të ndryshme. Kjo quhet anomali e përditësimit.
E kundërta e normalizimit është denormalizimi: lejimi i qëllimshëm i disa përsëritjeve për hir të shpejtësisë së raportimit. Në sistemet e biznesit (baza e të dhënave operacionale), përgjithësisht preferohet normalizimi, dhe në sistemet e raportimit (depoja e të dhënave), shpesh preferohet denormalizimi. Pra, “normalizimi nuk është gjithmonë i mirë”; Vendimi merret sipas qëllimit.
Fjalori i të dhënave: Gjuha e përbashkët
Fjalori i të dhënave është një dokument që përcakton se çfarë do të thotë secila fushë, llojin e saj, kufizimet dhe rregullin e biznesit. Çfarë do të thotë fusha "status"? Çfarë vlerash mund të marrë (në pritje, miratuar, anuluar)? A është e detyrueshme? Pa këtë dokument, e njëjta fushë do të interpretohet ndryshe nga ekipe të ndryshme dhe raporti do të shtrembërohet. Fjalori i të dhënave është lingua franca e organizatës dhe një nga produktet më të vlefshme të profesionistit të MIS. AI mund të nxjerrë shpejt një draft të fjalorit fillestar të të dhënave nga struktura ekzistuese e tabelës; Por vetëm njësia që përdor ato të dhëna verifikon kuptimin e vërtetë të biznesit të secilës fushë.
Tre Mini Rastet: Nga Numrat
Rasti 1 - Kostoja e përsëritjes. Në një kompani shpërndarjeje, adresa e klientit mbahej veçmas në tabelat e porosive dhe faturave. Kur një klient lëvizte, adresa përditësohej vetëm në një tabelë; 1400 fatura kanë shkuar në adresën e vjetër dhe janë kthyer. Nëse adresa do të normalizohej në një tabelë të vetme, do të mjaftonte një përditësim i vetëm. Projekti i rehabilitimit kushtoi 2 javë.
Rasti 2 — Lloji i gabuar i marrëdhënies. Një ekspert MIS në një institucion arsimor pranoi marrëdhënien (një me shumë) "Studenti i përket një klase" në modelin e krijuar nga AI. Megjithatë, studentët mund të regjistroheshin në më shumë se një klasë me zgjedhje; Marrëdhënia ishte në fakt shumë-me-shumë dhe kërkohej një tabelë e ndërmjetme (Record). Gabimi u zbulua në terren kur një nxënës nuk arriti të regjistrohej në klasën e dytë. Nëse sugjerimi i AI do të ishte konfirmuar, do të ishte kapur që në fillim.
Rasti 3 — Vlera e fjalorit të të dhënave. U përcaktua se fusha "policy_status" në një kompani sigurimesh interpretohej ndryshe nga 5 ekipe të ndryshme, kështu që i njëjti KPI dha 3 rezultate të ndryshme në raporte. Me hartimin e një fjalori të të dhënave të fuqizuar nga AI dhe arritjen e marrëveshjes uniforme me njësinë e biznesit, mospërputhja e raportit u eliminua dhe koha e takimit mujor të barazimit u reduktua me 60%.
Prompt i dobët / Prompt i fortë
Njoftim i dobët:
Dizenjoni një bazë të dhënash të tregtisë elektronike.
Njoftim i fuqishëm:
Roli juaj: Ju jeni një modelues me përvojë të dhënash. DRAFToni një model LOGJIK të të dhënave sipas rregullave të mëposhtme të biznesit. Rregullat:- Për çdo entitet: fushat, çelësi kryesor, fushat e kërkuara.- Për çdo marrëdhënie: lloji (një-me-shumë / shumë-për-shumë) dhe çelësi i huaj.- Propozoni një tabelë ndërmjetëse në marrëdhëniet shumë-në-shumë.- Normalizoni deri në formën 3 normalizoj; Nëse rekomandoni denormalizim të qëllimshëm, shkruani arsyetimin.- Etiketoni [KËRKOHET KONFIRMIMI] çdo rregull biznesi për të cilin nuk jeni të sigurt. Rregullat e biznesit:- Klienti mund të bëjë porosi të shumta.- Një porosi përmban shumë produkte; Një produkt shfaqet në shumë porosi.- Produktet kanë kategori.[rregulla të tjera...]
Prompti i fuqishëm sqaron nivelin e modelit (logjik), rregullat kryesore dhe të marrëdhënieve, objektivin e normalizimit dhe pikat që kërkojnë konfirmim.
Katër modele të kopjueshme
1) Drafti i fjalorit të të dhënave:
Një përmbledhje e fjalorit të të dhënave rrjedh nga përkufizimi i tabelës. Për secilën fushë: emri, lloji, a është i detyrueshëm, vlerat e mundshme, kuptimi i biznesit (etiketa[PARASHIKIM] nëse është një parashikim). Tabela: [DDL ose lista e fushave]
2) Rishikimi i normalizimit:
A ka ndonjë rrezik të të dhënave të dyfishta, anomali të përditësimit dhe mundësi për normalizim në strukturën e tabelës më poshtë? Për çdo gjetje, shkruani se cilën formë normale shkel dhe sugjerimin tuaj. Struktura: [tekst]
3) Drafti i ER nga rregulli i biznesit:
Përkthejini rregullat e mëposhtme të biznesit në entitete, atribute dhe marrëdhënie. Specifikoni llojin e secilës marrëdhënie (1-1, 1-N, N-N) dhe nëse N-N, sugjeroni një tabelë të ndërmjetme. Shënoni rregulla të paqarta. Rregullat: [tekst]
4) Pyetje për verifikimin e llojit të marrëdhënies:
Për çdo marrëdhënie në modelin e të dhënave më poshtë, krijoni një pyetje biznesi "po/jo" që do të testojë korrektësinë e llojit të saj (p.sh., "A mund të regjistrohet një student në më shumë se një klasë në të njëjtën kohë?"). Modeli: [tekst]
Grafiku i krahasimit: Nivelet e modelit
veçori
konceptuale
logjike
fizike
Detaj
të paktën
e mesme
shumica
kyç/lidhje
Asetet kryesore
Çelësat e përcaktuara
Përfshirë indeksin/llojin
Varet nga databaza
nr
nr
po
audienca e synuar
njësi biznesi
analist
Zhvilluesi/DBA
Kontributi i AI
draft
draft i fortë
Drafti, konfirmimi i DBA
Gabimet e zakonshme
- Duke menduar për një marrëdhënie shumë-me-shumë si një-me-shumë. Ky është gabimi më i zakonshëm i modelimit; Nëse tabela e ndërmjetme harrohet, sistemi nuk mund të mbajë gjendjen aktuale.
- Duke vendosur gjithçka në një tryezë. Mbledhja e të gjitha fushave në një tabelë për hir të "thjeshtësisë" prodhon dyfishim dhe anomali të përditësimit.
- Mos shkrimi i një fjalori të dhënash. I njëjti KPI jep rezultate të ndryshme kur kuptimi i fushave mbetet në mendje.
- Duke besuar verbërisht rekomandimin e AI për llojet dhe kufizimet e të dhënave. Modeli mund të sugjerojë një zonë "mjaft të madhe"; Rregulli i biznesit përcakton kufijtë aktualë (p.sh. TR ID 11 shifra).
- Normalizimi absolutues. Normalizimi i tepërt në shtresën e raportimit ngadalëson pyetjen; Qëllimi ndryshon në varësi të kontekstit.
Kujdes: Inteligjenca artificiale mund të prodhojë modele që duken bukur, por që shkelin rregullat e biznesit. Për çdo marrëdhënie të sugjeruar nga modelja, pyetja "a është vërtet kështu?" Bëni një pyetje biznesi. Modeli i të dhënave është skeleti i sistemit; Një thyerje në skelet është shumë e vështirë të riparohet më vonë.
Në përmbledhje
Modelimi i të dhënave është procesi i strukturimit të fakteve të biznesit me entitete, atribute dhe marrëdhënie dhe vazhdon në nivele konceptuale, logjike dhe fizike. Çelësat kryesorë dhe të huaj sigurojnë integritet referencial; Normalizimi redukton përsëritjen, por denormalizimi është gjithashtu legjitim në varësi të qëllimit. Fjalori i të dhënave është gjuha e përbashkët e organizatës. AI ofron shpejtësi të konsiderueshme në prodhimin e drafteve të ER, fjalorëve të të dhënave dhe rishikimeve të normalizimit; megjithatë, llojet e marrëdhënieve, llojet e të dhënave dhe semantika e biznesit duhet të konfirmohen kundër rregullit aktual të biznesit. Vetëm për shkak se modeli duket i mirë nuk do të thotë se është i duhuri.
Detyra e aplikimit
Konsideroni një “sistem huazimi të bibliotekave”: anëtarët, librat, të dhënat e huazimit. (1) Keni një draft model logjik të prodhuar nga prompti i fuqishëm. (2) Testoni llojin e secilës marrëdhënie që sugjeron modeli (në mënyrë specifike, “a mund të ketë një anëtar më shumë se një kopje të të njëjtit libër?”) me një pyetje biznesi. (3) Gjeni të paktën një lidhje shumë-me-shumë dhe përcaktoni një tabelë të ndërmjetme. (4) Shkruani rreshtat e fjalorit të të dhënave për të paktën 4 fusha (emri, lloji, i detyrueshëm, kuptimi i biznesit). (5) Theksoni një kufizim që modeli mund të ketë përshtatur dhe shpjegoni se si do ta verifikonit atë.
listë kontrolli
- [ ] Përcaktohet çelësi kryesor i secilës tabelë.
- [ ] Kam verifikuar llojin e secilës marrëdhënie me pyetjen e biznesit.
- [ ] Përcaktova një tabelë të ndërmjetme për marrëdhëniet shumë-me-shumë.
- [ ] Kam normalizuar ose justifikuar denormalizimin e të dhënave të dyfishta.
- [ ] Kam shkruar një linjë fjalori të dhënash për fushat kritike.
- [ ] Konfirmova sugjerimet e llojit të të dhënave/kufizimit të AI kundër rregullave të biznesit.