Câștiguri:
- Abilitatea de a explica modele de date conceptuale, logice și fizice și concepte de normalizare și de a produce schițe de relații entitate cu sprijinul inteligenței artificiale
- Abilitatea de a redacta dicționar de date, reguli de afaceri și relații de tabel cu solicitări structurate și de a le verifica în raport cu sistemul real
- Abilitatea de a evalua critic sugestiile de schemă generate de AI în ceea ce privește integritatea, singularitatea și conformitatea cu regulile de afaceri.
Un sistem informatic este în esență o structură care menține datele organizate. Modelarea datelor este sarcina de a proiecta faptele unei afaceri (client, comandă, produs, factură) și relația lor între ele într-un mod structurat. Un model de date bun stă la baza raportării precise, a interogărilor rapide și a datelor consistente; Un model prost este sursa de ani de inconsecvență și lucrări repetitive de corecție. De cele mai multe ori, profesionistul MIS nu codifică modelul de la zero, ci verifică dacă modelul respectă regulile de business și traduce modelul între unitatea de business și IT.
Modelarea datelor are loc la trei niveluri de abstractizare. Modelul conceptual (conceptual în engleză) este cel mai înalt nivel: ce entități principale există și cum sunt legate? „Clientul plasează o comandă, comanda include produsul.” Nu există detalii tehnice. Modelul logic definește atributele (câmpurile), cheile și tipurile de relații ale fiecărei entități; dar încă nu este legat de un anumit produs de bază de date. Modelul fizic (în engleză fizic) este versiunea concretă a tabelelor, a tipurilor de date și a indicilor dintr-o anumită bază de date (de exemplu, SQL Server, PostgreSQL). Aceste trei niveluri sunt versiuni din ce în ce mai detaliate ale aceleiași idei.
Entitate-Relație și chei
Limbajul de bază al modelului de date este modelul Entitate-Relație (ER). Entitatea poate fi gândită ca un tabel: Client, Comanda. Atributul este coloana tabelului: nume, email, suma. Relația este modul în care entitățile sunt conectate: un client poate avea mai multe comenzi (relație unu-la-mulți).
Există două concepte cheie critice. Cheia primară este câmpul care identifică în mod unic fiecare rând dintr-un tabel; de exemplu CustomerID. O cheie externă este un câmp dintr-un tabel care indică cheia primară a altui tabel; ID-ul clientului din tabelul de comenzi conectează comanda clientului respectiv. Aceste conexiuni asigură integritatea referenţială: nu poate fi plasată o comandă pentru un client care nu există.
Sfat: Când AI generează o schiță ER, este mai ușor să solicitați în mod explicit cheia primară pentru fiecare tabel și cheia externă pentru fiecare relație. Dar verificați fiecare cheie externă sugerată de model în raport cu regula de afaceri reală: uneori relația pe care o considerați „unu-la-mulți” este de fapt „mulți-la-mulți”.
Normalizare: Prevenirea recidivei
Normalizarea este procesul de reducere a redundanței și de păstrare a integrității prin împărțirea datelor în tabele logice. Scopul este de a păstra aceleași informații într-un singur loc. De exemplu, în loc să tastați adresa clientului din nou și din nou în fiecare linie de comandă, păstrați adresa o dată în tabelul Client și o legați cu o cheie străină din comandă. În acest fel, atunci când adresa se schimbă, o actualizați într-un singur loc; În caz contrar, sute de comenzi vor avea adrese diferite. Aceasta se numește anomalie de actualizare.
Opusul normalizării este denormalizarea: permiterea în mod deliberat a unor repetiții de dragul vitezei de raportare. În sistemele de afaceri (baza de date operațională), normalizarea este în general preferată, iar în sistemele de raportare (depozit de date), denormalizarea este adesea preferată. Deci „normalizarea nu este întotdeauna bună”; Decizia se ia in functie de scop.
Dicţionar de date: limbaj comun
Dicționarul de date este un document care definește ce înseamnă fiecare câmp, tipul său, constrângerile și regula de afaceri. Ce înseamnă câmpul „stare”? Ce valori poate lua (În așteptare, Aprobat, Anulat)? Este obligatoriu? Fără acest document, același câmp va fi interpretat diferit de echipe diferite și raportul va fi distorsionat. Dicționarul de date este lingua franca a organizației și unul dintre cele mai valoroase rezultate ale profesioniștilor MIS. AI poate extrage rapid o schiță inițială a dicționarului de date din structura tabelului existent; Dar numai unitatea care utilizează acele date verifică adevărata semnificație comercială a fiecărui domeniu.
Trei mini carcase: după cifre
Cazul 1 – Costul repetiției. Într-o companie de distribuție, adresa clientului a fost păstrată separat atât în tabelul de comenzi, cât și în tabelul de facturare. Când un client se muta, adresa era actualizată într-un singur tabel; 1.400 de facturi au mers la vechea adresă și au fost rambursate. Dacă adresa a fost normalizată într-un singur tabel, o singură actualizare ar fi suficientă. Proiectul de remediere a costat 2 săptămâni.
Cazul 2 — Tip greșit de relație. Un expert MIS dintr-o instituție de învățământ a recunoscut relația (unu-la-mulți) „Studentul aparține unei clase” în modelul generat de AI. Cu toate acestea, studenții se puteau înscrie la mai multe clase opționale; Relația era de fapt multi-la-mulți și era necesar un tabel intermediar (Înregistrare). Greșeala a fost dezvăluită în teren când un elev nu s-a înscris în clasa a II-a. Dacă sugestia AI ar fi fost confirmată, ar fi fost prinsă de la început.
Cazul 3 — Valoarea dicționarului de date. S-a stabilit că câmpul „policy_status” dintr-o companie de asigurări a fost interpretat diferit de 5 echipe diferite, astfel încât același KPI a dat 3 rezultate diferite în rapoarte. Prin elaborarea unui dicționar de date bazat pe inteligență artificială și prin obținerea unui acord uniform cu unitatea de afaceri, inconsecvența raportului a fost eliminată și timpul lunar al întâlnirilor de reconciliere a fost redus cu 60%.
Solicitare slabă / Solicitare puternică
Prompt slab:
Proiectați o bază de date de comerț electronic.
Solicitare puternică:
Rolul dvs.: Sunteți un modelator de date cu experiență. ELABORAȚI un model de date LOGIC conform următoarelor reguli de afaceri. Reguli:- Pentru fiecare entitate: câmpuri, cheie primară, câmpuri obligatorii.- Pentru fiecare relație: tip (unu-la-mulți / mulți-la-mai multe) și cheie externă.- Propuneți tabel intermediar în relații multi-la-mai multe.- Normalizare până la 3rd; Dacă recomandați denormalizarea intenționată, scrieți justificarea.- Etichetați [CONFIRMARE NECESARĂ] orice regulă de afaceri de care nu sunteți sigur. Reguli de afaceri:- Clientul poate plasa mai multe comenzi.- O comandă conține mai multe produse; Un produs apare în mai multe comenzi.- Produsele au categorii.[alte reguli...]
Promptul puternic clarifică nivelul modelului (logic), regulile cheie și relația, ținta de normalizare și punctele care necesită confirmare.
Patru șabloane copiabile
1) Schiță de dicționar de date:
Din definiția tabelului rezultă o schiță a dicționarului de date. Pentru fiecare câmp: nume, tip, este obligatoriu, valori posibile, semnificația afacerii (etichetă[PREDICTION] dacă este o predicție). Tabel: [DDL sau listă de câmpuri]
2) Revizuirea normalizării:
Există vreun risc de duplicare a datelor, anomalii de actualizare și oportunități de normalizare în structura tabelului de mai jos? Pentru fiecare constatare, notează ce formă normală o încalcă și sugestia ta. Structura: [text]
3) proiect ER din regula de afaceri:
Traduceți următoarele reguli de afaceri în entități, atribute și relații. Specificați tipul fiecărei relații (1-1, 1-N, N-N) și, dacă N-N, sugerați un tabel intermediar. Marcați reguli ambigue. Reguli: [text]
4) Întrebări de verificare a tipului de relație:
Pentru fiecare relație din modelul de date de mai jos, generați o întrebare de afaceri „da/nu” care va testa corectitudinea tipului acesteia (de exemplu, „Poate un student să fie înscris la mai multe clase în același timp?”). Model: [text]
Diagramă de comparație: niveluri de model
caracteristică
conceptuală
logic
fizice
Detaliu
cel putin
mediu
majoritatea
cheie/relație
Principalele active
Cheile definite
Inclusiv index/tip
Depinde de baza de date
nu
nu
Da
publicul țintă
unitate de afaceri
analist
Dezvoltator/DBA
Contribuția AI
draft
pescaj puternic
Schiță, confirmare DBA
Greșeli comune
- Gândindu-vă la o relație multi-la-mulți ca unul-la-mulți. Aceasta este cea mai comună eroare de modelare; Dacă tabelul intermediar este uitat, sistemul nu poate păstra starea actuală.
- Pune totul într-o singură masă. Adunarea tuturor câmpurilor într-un singur tabel de dragul „simplităţii” produce anomalii de duplicare şi actualizare.
- Nu scriu un dicționar de date. Același KPI dă rezultate diferite atunci când sensul câmpurilor rămâne în minte.
- Încredere oarbă în recomandarea AI privind tipurile de date și constrângeri. Modelul poate sugera o zonă „suficient de mare”; Regula de afaceri determină limitele reale (de exemplu, TR ID 11 cifre).
- Normalizare absolutizantă. Normalizarea excesivă la nivelul de raportare încetinește interogarea; Scopul variază în funcție de context.
Atenție: inteligența artificială poate produce modele care arată frumos, dar care încalcă regulile de afaceri. Pentru fiecare relație sugerată de model, întrebarea „este chiar așa?” Pune o întrebare de afaceri. Modelul de date este scheletul sistemului; O fractură a scheletului este foarte greu de reparat mai târziu.
Pe scurt
Modelarea datelor este procesul de structurare a faptelor de afaceri cu entități, atribute și relații și se desfășoară la nivel conceptual, logic și fizic. Cheile primare și externe asigură integritatea referențială; Normalizarea reduce repetiția, dar și denormalizarea este legitimă în funcție de scop. Dicționarul de date este limba comună a organizației. AI oferă o viteză semnificativă în producerea schițelor ER, a dicționarelor de date și a recenziilor de normalizare; cu toate acestea, tipurile de relații, tipurile de date și semantica afacerii trebuie să fie confirmate în raport cu regula de afaceri reală. Doar pentru că modelul arată bine nu înseamnă că este corect.
Sarcina de aplicare
Luați în considerare un „sistem de împrumut de bibliotecă”: membri, cărți, registre de împrumut. (1) Aveți o schiță de model logic produsă de promptul puternic. (2) Testați tipul fiecărei relații pe care modelul îl sugerează (în special, „un membru poate avea mai multe copii ale aceleiași cărți?”) cu o întrebare de afaceri. (3) Găsiți cel puțin o relație multi-la-mulți și definiți un tabel intermediar. (4) Scrieți linii de dicționar de date pentru cel puțin 4 câmpuri (nume, tip, obligatoriu, semnificație comercială). (5) Evidențiați o constrângere pe care modelul s-ar putea adapta și explicați cum ați verifica-o.
lista de verificare
- [ ] Cheia primară a fiecărui tabel este definită.
- [ ] Am verificat tipul fiecărei relații cu întrebarea de afaceri.
- [ ] Am definit un tabel intermediar pentru relațiile multi-la-mulți.
- [ ] Am normalizat sau justificat denormalizarea datelor duplicate.
- [ ] Am scris o linie de dicționar de date pentru câmpurile critice.
- [ ] Am confirmat sugestiile de tip de date/constrângeri ale AI împotriva regulii de afaceri.