Winst:
- Vermogen om conceptuele, logische en fysieke datamodellen en normalisatieconcepten uit te leggen en concepten voor entiteitsrelaties te produceren met behulp van kunstmatige intelligentie
- Mogelijkheid om data dictionary, bedrijfsregels en tabelrelaties op te stellen met gestructureerde aanwijzingen en deze te verifiëren met het echte systeem
- Mogelijkheid om door AI gegenereerde schemasuggesties kritisch te evalueren in termen van integriteit, singulariteit en naleving van bedrijfsregels.
Een informatiesysteem is in wezen een structuur die gegevens georganiseerd houdt. Datamodellering is de taak om de feiten van een bedrijf (klant, bestelling, product, factuur) en hun relatie tot elkaar op een gestructureerde manier te ontwerpen. Een goed datamodel vormt de basis voor nauwkeurige rapportage, snelle queries en consistente data; Een slecht model is de bron van jaren van inconsistentie en repetitief correctiewerk. Meestal codeert de MIS-professional het model niet helemaal opnieuw, maar controleert hij of het model voldoet aan de bedrijfsregels en vertaalt hij het model tussen de businessunit en IT.
Gegevensmodellering vindt plaats op drie abstractieniveaus. Het conceptuele model (Engels conceptueel) is het hoogste niveau: welke hoofdentiteiten bestaan er en hoe zijn ze gerelateerd? "De klant plaatst een bestelling, de bestelling bevat het product." Er zijn geen technische details. Het logische model definieert de attributen (velden), sleutels en relatietypen van elke entiteit; maar het is nog steeds niet gebonden aan een specifiek databaseproduct. Het fysieke model (Engels fysiek) is de concrete versie van de tabellen, datatypen en indexen in een specifieke database (bijvoorbeeld SQL Server, PostgreSQL). Deze drie niveaus zijn steeds gedetailleerdere versies van hetzelfde idee.
Entiteitsrelatie en sleutels
De basistaal van het datamodel is het Entity-Relationship (ER)-model. Entiteit kan worden gezien als een tabel: Klant, Bestelling. Het attribuut is de kolom van de tabel: naam, e-mailadres, bedrag. Relatie is hoe entiteiten met elkaar verbonden zijn: een klant kan veel bestellingen hebben (een-op-veel-relatie).
Er zijn twee cruciale sleutelconcepten. De primaire sleutel is het veld dat elke rij in een tabel op unieke wijze identificeert; bijvoorbeeld KlantID. Een refererende sleutel is een veld in de ene tabel dat verwijst naar de primaire sleutel van een andere tabel; Het KlantID in de besteltabel geeft aan om welke klant het gaat. Deze verbindingen zorgen voor referentiële integriteit: er kan geen bestelling worden geplaatst voor een klant die niet bestaat.
Tip: Wanneer u de AI een ER-concept laat genereren, wordt het eenvoudiger om voor elke tabel expliciet de primaire sleutel en voor elke relatie de refererende sleutel op te vragen. Maar verifieer elke externe sleutel die door het model wordt voorgesteld aan de hand van de daadwerkelijke bedrijfsregel: soms is de relatie waarvan u denkt dat deze 'één-op-veel' is, in werkelijkheid 'veel-op-veel'.
Normalisatie: herhaling voorkomen
Normalisatie is het proces waarbij redundantie wordt verminderd en de integriteit behouden door gegevens in logische tabellen te verdelen. Het doel is om dezelfde informatie op één plek te bewaren. In plaats van het klantadres bijvoorbeeld steeds opnieuw in elke orderregel te typen, bewaart u het adres één keer in de Klanttabel en koppelt u het aan een externe sleutel uit de order. Op deze manier werkt u het adres op één plek bij als het adres verandert; Anders hebben honderden bestellingen verschillende adressen. Dit wordt update-anomalie genoemd.
Het tegenovergestelde van normalisatie is denormalisatie: het opzettelijk toestaan van enige herhaling omwille van de rapportagesnelheid. In bedrijfssystemen (operationele database) wordt over het algemeen de voorkeur gegeven aan normalisatie, en in rapportagesystemen (datawarehouse) wordt vaak de voorkeur gegeven aan denormalisatie. Dus "normalisatie is niet altijd goed"; De beslissing wordt genomen op basis van het doel.
Gegevenswoordenboek: gemeenschappelijke taal
Data dictionary is een document dat definieert wat elk veld betekent, het type, de beperkingen en de bedrijfsregel. Wat betekent het veld ‘status’? Welke waarden kan het aannemen (In behandeling, Goedgekeurd, Geannuleerd)? Is het verplicht? Zonder dit document zal hetzelfde veld door verschillende teams verschillend worden geïnterpreteerd en zal het rapport vervormd zijn. Het datawoordenboek is de lingua franca van de organisatie en een van de meest waardevolle producten van de MIS-professional. AI kan snel een eerste datadictionary-concept uit de bestaande tabelstructuur extraheren; Maar alleen de eenheid die die gegevens gebruikt, verifieert de werkelijke zakelijke betekenis van elk veld.
Drie mini-hoesjes: volgens de cijfers
Geval 1 — De kosten van herhaling. In een distributiebedrijf werd het klantadres afzonderlijk bijgehouden in zowel de order- als de factuurtabellen. Wanneer een klant verhuisde, werd het adres in slechts één tabel bijgewerkt; 1.400 facturen gingen naar het oude adres en werden terugbetaald. Als het adres in één tabel zou worden genormaliseerd, zou een enkele update voldoende zijn. Het saneringsproject duurde 2 weken.
Geval 2 – Verkeerd type relatie. Een MIS-expert in een onderwijsinstelling erkende de (één-op-veel) relatie ‘Student behoort tot een klas’ in het door AI gegenereerde model. Studenten konden zich echter voor meer dan één keuzevak inschrijven; De relatie was eigenlijk veel-op-veel en er was een tussenliggende tabel (Record) vereist. De fout werd in het veld aan het licht gebracht toen een leerling zich niet inschreef voor het tweede leerjaar. Als de suggestie van de AI was bevestigd, zou deze vanaf het begin zijn opgepakt.
Geval 3 — Waarde van datadictionary. Er werd vastgesteld dat het veld 'polisstatus' bij een verzekeringsmaatschappij door vijf verschillende teams verschillend werd geïnterpreteerd, waardoor dezelfde KPI drie verschillende resultaten in de rapporten opleverde. Door het opstellen van een door AI aangedreven datawoordenboek en het bereiken van uniforme overeenstemming met de business unit, werd inconsistentie in de rapporten geëlimineerd en werd de tijd voor maandelijkse afstemmingsvergaderingen met 60% verkort.
Zwakke prompt/sterke prompt
Zwakke prompt:
Ontwerp een e-commercedatabase.
Krachtige prompt:
Jouw rol: Je bent een ervaren datamodelleur. ONTWERP een LOGISCH datamodel volgens de volgende bedrijfsregels. Regels: - Voor elke entiteit: velden, primaire sleutel, verplichte velden. - Voor elke relatie: type (één-op-veel / veel-op-veel) en externe sleutel. - Stel een tussentabel voor in veel-op-veel-relaties. - Normaliseer tot en met de 3e normaalvorm; Als u opzettelijke denormalisatie aanbeveelt, noteer dan de reden. - Label [BEVESTIGING VEREIST] op elke bedrijfsregel waarvan u niet zeker bent. Bedrijfsregels: - De klant kan meerdere bestellingen plaatsen. - Een bestelling bevat meerdere producten; Eén product komt in veel bestellingen voor. - Producten hebben categorieën. [andere regels...]
De krachtige prompt verduidelijkt het modelniveau (logisch), de sleutel- en relatieregels, het normalisatiedoel en de punten die bevestiging vereisen.
Vier kopieerbare sjablonen
1) Concept gegevenswoordenboek:
Uit de tabeldefinitie volgt een overzicht van de datadictionary. Voor elk veld: naam, type, is het verplicht, mogelijke waarden, zakelijke betekenis (label[PREDICTION] als het een voorspelling is). Tabel: [DDL- of veldlijst]
2) Normalisatiebeoordeling:
Bestaat er een risico op dubbele gegevens, afwijkende updates en mogelijkheden voor normalisatie in de onderstaande tabelstructuur? Schrijf bij elke bevinding op welke normaalvorm deze schendt en uw suggestie. Structuur: [tekst]
3) ER-concept van bedrijfsregel:
Vertaal de volgende bedrijfsregels naar entiteiten, attributen en relaties. Specificeer het type van elke relatie (1-1, 1-N, N-N) en indien N-N, stel een tussenliggende tabel voor. Markeer dubbelzinnige regels. Regels: [tekst]
4) Verificatievragen over het relatietype:
Genereer voor elke relatie in het onderstaande gegevensmodel een zakelijke 'ja/nee'-vraag waarmee de juistheid van het type wordt getest (bijvoorbeeld: 'Kan een leerling tegelijkertijd voor meer dan één klas zijn ingeschreven?'). Model: [tekst]
Vergelijkingstabel: modelniveaus
functie
conceptueel
logisch
fysiek
Details
tenminste
middelmatig
de meeste
sleutel/relatie
Belangrijkste troeven
Sleutels gedefinieerd
Inclusief index/type
Afhankelijk van de database
nee
nee
Ja
doelgroep
bedrijfseenheid
analist
Ontwikkelaar/DBA
Bijdrage van AI
ontwerp
sterke trek
Concept, DBA-bevestiging
Veel voorkomende fouten
- Een veel-op-veel-relatie beschouwen als één-op-veel. Dit is de meest voorkomende modelfout; Als de tussentabel wordt vergeten, kan het systeem de werkelijke status niet behouden.
- Alles in één tabel zetten. Het verzamelen van alle velden in één tabel omwille van de "eenvoud" levert duplicatie en update-afwijkingen op.
- Geen datawoordenboek schrijven. Dezelfde KPI geeft verschillende resultaten als de betekenis van de velden in het achterhoofd blijft.
- Blindelings vertrouwend op de aanbevelingen van AI over datatypen en beperkingen. Het model suggereert mogelijk een gebied dat “groot genoeg” is; De bedrijfsregel bepaalt de daadwerkelijke limieten (bijvoorbeeld TR ID 11 cijfers).
- De normalisatie verabsoluteren. Overmatige normalisatie op de rapportagelaag vertraagt de query; Het doel varieert afhankelijk van de context.
Let op: Kunstmatige intelligentie kan modellen voortbrengen die er mooi uitzien, maar in strijd zijn met de bedrijfsregels. Voor elke relatie die door het model wordt voorgesteld, wordt de vraag "is het echt zo?" Stel een zakelijke vraag. Het datamodel is het skelet van het systeem; Een breuk in het skelet is later zeer moeilijk te herstellen.
Samengevat
Datamodellering is het proces van het structureren van zakelijke feiten met entiteiten, attributen en relaties en verloopt op conceptueel, logisch en fysiek niveau. Primaire en externe sleutels zorgen voor referentiële integriteit; Normalisatie vermindert herhaling, maar denormalisatie is ook legitiem, afhankelijk van het doel. De data dictionary is de gemeenschappelijke taal van de organisatie. AI zorgt voor aanzienlijke snelheid bij het produceren van ER-concepten, datawoordenboeken en normalisatiebeoordelingen; relatietypen, gegevenstypen en zakelijke semantiek moeten echter worden bevestigd aan de hand van de daadwerkelijke bedrijfsregel. Het feit dat het model er goed uitziet, betekent niet dat het goed is.
Applicatie taak
Denk eens aan een ‘bibliotheekuitleensysteem’: leden, boeken, uitleengegevens. (1) Laat een logisch modelontwerp maken door de krachtige prompt. (2) Test het type relatie dat het model suggereert (in het bijzonder: “kan een lid meer dan één exemplaar van hetzelfde boek hebben?”) met een zakelijke vraag. (3) Zoek ten minste één veel-op-veel-relatie en definieer een tussentabel. (4) Schrijf datadictionary-regels voor minimaal 4 velden (naam, type, verplicht, zakelijke betekenis). (5) Benadruk een beperking waar het model mogelijk aan voldoet en leg uit hoe u dit zou verifiëren.
controlelijst
- [ ] De primaire sleutel van elke tabel is gedefinieerd.
- [ ] Ik heb het type van elke relatie geverifieerd met de zakelijke vraag.
- [ ] Ik heb een tussentabel gedefinieerd voor veel-op-veel-relaties.
- [ ] Ik heb de denormalisatie van dubbele gegevens genormaliseerd of gerechtvaardigd.
- [ ] Ik heb een datadictionary-regel geschreven voor kritische velden.
- [ ] Ik bevestigde dat de suggesties voor gegevenstype/beperkingen van de AI in strijd waren met de bedrijfsregel.