zisky:
- Schopnost vysvětlit koncepční, logické a fyzické datové modely a koncepty normalizace a vytvářet návrhy vztahů mezi entitami s podporou umělé inteligence
- Schopnost navrhnout datový slovník, obchodní pravidla a vztahy mezi tabulkami se strukturovanými výzvami a ověřit je se skutečným systémem
- Schopnost kriticky vyhodnotit návrhy schémat generované AI z hlediska integrity, singularity a souladu s obchodními pravidly.
Informační systém je v podstatě struktura, která udržuje data organizovaná. Úkolem datového modelování je strukturovaně navrhnout fakta o podnikání (zákazník, objednávka, produkt, faktura) a jejich vzájemný vztah. Dobrý datový model je základem přesných sestav, rychlých dotazů a konzistentních dat; Špatný model je zdrojem let nekonzistentnosti a opakujících se oprav. Profesionál MIS většinou nekóduje model od začátku, ale ověřuje, zda model odpovídá obchodním pravidlům a převádí model mezi obchodní jednotku a IT.
Datové modelování probíhá na třech úrovních abstrakce. Konceptuální model (anglicky conceptual) je nejvyšší úrovní: jaké hlavní entity existují a jak spolu souvisí? "Zákazník zadá objednávku, objednávka obsahuje produkt." Neexistují žádné technické podrobnosti. Logický model definuje atributy (pole), klíče a typy vztahů každé entity; ale stále není vázán na konkrétní databázový produkt. Fyzický model (anglicky Physical) je konkrétní verze tabulek, datových typů a indexů v konkrétní databázi (např. SQL Server, PostgreSQL). Tyto tři úrovně jsou stále podrobnější verze stejné myšlenky.
Vztah entit a klíče
Základním jazykem datového modelu je model Entity-Relationship (ER). Entitu si lze představit jako tabulku: Zákazník, Objednávka. Atribut je sloupec tabulky: jméno, email, částka. Vztah je způsob, jakým jsou entity propojeny: zákazník může mít mnoho objednávek (vztah one-to-many).
Existují dva zásadní klíčové pojmy. Primární klíč je pole, které jednoznačně identifikuje každý řádek v tabulce; například CustomerID. Cizí klíč je pole v jedné tabulce, které ukazuje na primární klíč jiné tabulky; Číslo zákazníka v tabulce objednávek spojuje, o kterou objednávku zákazníka se jedná. Tato připojení zajišťují referenční integritu: nelze zadat objednávku pro neexistujícího zákazníka.
Tip: Když AI vygeneruje návrh ER, usnadní to explicitní vyžádání primárního klíče pro každou tabulku a cizího klíče pro každý vztah. Ověřte však každý cizí klíč navržený modelem proti skutečnému obchodnímu pravidlu: někdy vztah, o kterém si myslíte, že je „jeden k mnoha“, je ve skutečnosti „mnoho k mnoha“.
Normalizace: Prevence recidivy
Normalizace je proces snížení redundance a zachování integrity rozdělením dat do logických tabulek. Cílem je udržet stejné informace na jednom místě. Například místo toho, abyste do každého řádku objednávky znovu a znovu zadávali adresu zákazníka, ponecháte adresu jednou v tabulce Zákazník a propojíte ji s cizím klíčem z objednávky. Tímto způsobem, když se adresa změní, aktualizujete ji na jednom místě; Jinak budou mít stovky objednávek různé adresy. Tomu se říká anomálie aktualizace.
Opakem normalizace je denormalizace: záměrné umožnění určitého opakování kvůli rychlosti vykazování. V obchodních systémech (provozní databáze) je obecně preferována normalizace a v systémech reportingu (datový sklad) je často preferována denormalizace. Takže „normalizace není vždy dobrá“; Rozhoduje se podle účelu.
Datový slovník: Common Language
Datový slovník je dokument, který definuje, co každé pole znamená, jeho typ, omezení a obchodní pravidlo. Co znamená pole „stav“? Jaké hodnoty může nabývat (Nevyřízeno, Schváleno, Zrušeno)? Je to povinné? Bez tohoto dokumentu bude stejné pole různými týmy interpretováno odlišně a zpráva bude zkreslená. Datový slovník je lingua franca organizace a jedním z nejcennějších výstupů profesionálů MIS. Umělá inteligence může rychle extrahovat počáteční návrh datového slovníku ze stávající struktury tabulky; Ale pouze jednotka používající tato data ověřuje skutečný obchodní význam každého pole.
Tři mini případy: Podle čísel
Případ 1 – Náklady na opakování. V distribuční společnosti byla adresa zákazníka vedena odděleně v tabulkách objednávek a faktur. Když se zákazník přestěhoval, adresa byla aktualizována pouze v jedné tabulce; 1 400 faktur odešlo na starou adresu a byly vráceny. Pokud by byla adresa normalizována v jedné tabulce, stačila by jediná aktualizace. Projekt sanace stál 2 týdny.
Případ 2 – Špatný typ vztahu. Expert MIS ve vzdělávací instituci uznal vztah (jeden k mnoha) „Student patří do třídy“ v modelu generovaném AI. Studenti si však mohli zapsat více než jednu volitelnou třídu; Vztah byl ve skutečnosti many-to-many a byla vyžadována mezitabulka (Record). Chyba byla odhalena v oboru, když žák neuspěl při zápisu do druhé třídy. Pokud by byl návrh AI potvrzen, byl by chycen od začátku.
Případ 3 – Hodnota datového slovníku. Bylo zjištěno, že pole „policy_status“ v pojišťovně bylo různě interpretováno 5 různými týmy, takže stejný KPI poskytl 3 různé výsledky ve zprávách. Vytvořením datového slovníku založeného na AI a dosažením jednotné dohody s obchodní jednotkou byla odstraněna nekonzistence sestav a doba měsíčních schůzek pro odsouhlasení byla zkrácena o 60 %.
Slabá výzva / Silná výzva
Slabá výzva:
Navrhněte databázi elektronického obchodu.
Výkonná výzva:
Vaše role: Jste zkušený datový modelář.NAVRHNĚTE LOGICKÝ datový model podle následujících obchodních pravidel.Pravidla:- Pro každou entitu: pole, primární klíč, povinná pole.- Pro každý vztah: typ (one-to-many / many-to-many) a cizí klíč.- Navrhněte přechodnou tabulku ve vztazích many-to-many.- Normalizujte až 3. normální formu; Pokud doporučujete záměrnou denormalizaci, napište zdůvodnění.- Označte [POTVRZENÍ VYŽADOVÁNO] jakékoli obchodní pravidlo, kterým si nejste jisti.Obchodní pravidla:- Zákazník může zadat více objednávek.- Objednávka obsahuje více produktů; Jeden produkt se vyskytuje v mnoha objednávkách.- Produkty mají kategorie.[jiná pravidla...]
Výkonná výzva objasňuje úroveň modelu (logická), pravidla klíčů a vztahů, cíl normalizace a body vyžadující potvrzení.
Čtyři kopírovatelné šablony
1) Návrh datového slovníku:
Z definice tabulky vyplývá osnova datového slovníku. Pro každé pole: název, typ, je to povinné, možné hodnoty, obchodní význam (label[PREDICTION], pokud se jedná o předpověď). Tabulka: [DDL nebo seznam polí]
2) Kontrola normalizace:
Existuje nějaké riziko duplicitních dat, anomálie aktualizace a příležitosti k normalizaci ve struktuře tabulky níže? U každého nálezu napište, jakou normální formu porušuje a svůj návrh. Struktura: [text]
3) Návrh ER z obchodního pravidla:
Převeďte následující obchodní pravidla na entity, atributy a vztahy. Zadejte typ každého vztahu (1-1, 1-N, N-N) a pokud N-N, navrhněte přechodnou tabulku. Označte nejednoznačná pravidla. Pravidla: [text]
4) Otázky k ověření typu vztahu:
Pro každý vztah v datovém modelu níže vygenerujte obchodní otázku „ano/ne“, která otestuje správnost jejího typu (např. „Může být student zapsán do více než jedné třídy současně?“). Model: [text]
Srovnávací tabulka: Úrovně modelu
funkce
koncepční
logické
fyzické
Detail
alespoň
střední
většina
klíč/vztah
Hlavní aktiva
Definovány klíče
Včetně indexu/typu
Závisí na databázi
ne
ne
Ano
cílové publikum
obchodní jednotka
analytik
Vývojář/DBA
Příspěvek AI
návrh
silný průvan
Koncept, potvrzení DBA
Časté chyby
- Přemýšlet o vztahu mnoho k mnoha jako jeden k mnoha. Toto je nejčastější chyba modelování; Pokud je mezitabulka zapomenuta, systém nemůže zachovat aktuální stav.
- Dát vše do jedné tabulky. Shromažďování všech polí v jedné tabulce z důvodu „jednoduchosti“ vytváří duplicitní a aktualizační anomálie.
- Nepsání datového slovníku. Stejný KPI dává různé výsledky, když význam polí zůstává v mysli.
- Slepě důvěřovat doporučením AI ohledně datových typů a omezení. Model může navrhnout „dostatečně velkou“ oblast; Obchodní pravidlo určuje skutečné limity (např. TR ID 11 číslic).
- Absolutizující normalizace. Přílišná normalizace na vrstvě hlášení zpomaluje dotaz; Účel se liší v závislosti na kontextu.
Upozornění: Umělá inteligence může vytvářet modely, které vypadají hezky, ale porušují obchodní pravidla. U každého vztahu navrženého modelkou je otázka "je to opravdu takhle?" Zeptejte se na obchodní otázku. Datový model je kostrou systému; Zlomenina v kostře se později velmi obtížně opravuje.
V souhrnu
Datové modelování je proces strukturování obchodních skutečností pomocí entit, atributů a vztahů a probíhá na koncepční, logické a fyzické úrovni. Primární a cizí klíče zajišťují referenční integritu; Normalizace snižuje opakování, ale denormalizace je také legitimní v závislosti na účelu. Datový slovník je společným jazykem organizace. AI poskytuje značnou rychlost při vytváření návrhů ER, datových slovníků a normalizačních recenzí; typy vztahů, datové typy a obchodní sémantika však musí být potvrzeny podle skutečného obchodního pravidla. To, že model vypadá dobře, ještě neznamená, že je správný.
Aplikační úkol
Zvažte „systém výpůjček knihoven“: členové, knihy, záznamy o výpůjčkách. (1) Nechte si vytvořit návrh logického modelu pomocí výkonné výzvy. (2) Otestujte typ každého vztahu, který model navrhuje (konkrétně „může mít člen více než jednu kopii stejné knihy?“) s obchodní otázkou. (3) Najděte alespoň jeden vztah mnoho k mnoha a definujte mezitabulku. (4) Napište řádky datového slovníku pro minimálně 4 pole (název, typ, povinné, obchodní význam). (5) Zvýrazněte omezení, které model mohl splňovat, a vysvětlete, jak byste jej ověřili.
kontrolní seznam
- [ ] Je definován primární klíč každé tabulky.
- [ ] Ověřil jsem typ každého vztahu s obchodní otázkou.
- [ ] Definoval jsem přechodnou tabulku pro vztahy many-to-many.
- [ ] Normalizoval jsem nebo odůvodnil denormalizaci duplicitních dat.
- [ ] Napsal jsem řádek datového slovníku pro kritická pole.
- [ ] Potvrdil jsem návrhy datového typu/omezení AI proti obchodnímu pravidlu.