Voitot:
- Kyky selittää käsitteellisiä, loogisia ja fyysisiä tietomalleja ja normalisointikonsepteja sekä tuottaa kokonaisuus-suhdeluonnoksia tekoälyn tuella
- Kyky laatia tietosanakirjaa, liikesääntö- ja taulukkosuhteita strukturoiduilla kehotteilla ja verrata niitä todelliseen järjestelmään
- Kyky arvioida kriittisesti tekoälyn luomia skeemaehdotuksia eheyden, singulaarisuuden ja liiketoimintasääntöjen noudattamisen suhteen.
Tietojärjestelmä on pohjimmiltaan rakenne, joka pitää tiedot järjestyksessä. Tietomallinnuksella suunnitellaan jäsennellysti yrityksen tosiasiat (asiakas, tilaus, tuote, lasku) ja niiden suhde toisiinsa. Hyvä tietomalli on tarkan raportoinnin, nopeiden kyselyjen ja johdonmukaisten tietojen perusta. Huono malli on vuosien epäjohdonmukaisuuden ja toistuvan korjaustyön lähde. Useimmiten MIS-ammattilainen ei koodaa mallia tyhjästä, vaan varmistaa, että malli on liiketoimintasääntöjen mukainen ja kääntää mallin liiketoimintayksikön ja IT:n välillä.
Datamallinnus etenee kolmella abstraktiotasolla. Käsitteellinen malli (englanniksi conceptual) on korkein taso: mitä pääkokonaisuuksia on olemassa ja miten ne liittyvät toisiinsa? "Asiakas tekee tilauksen, tilaus sisältää tuotteen." Teknisiä yksityiskohtia ei ole. Looginen malli määrittelee kunkin entiteetin attribuutit (kentät), avaimet ja suhdetyypit; mutta se ei silti ole sidottu tiettyyn tietokantatuotteeseen. Fyysinen malli (englanniksi fyysinen) on tietyn tietokannan (esim. SQL Server, PostgreSQL) taulukoiden, tietotyyppien ja indeksien konkreettinen versio. Nämä kolme tasoa ovat yhä yksityiskohtaisempia versioita samasta ideasta.
Entiteetti-suhde ja avaimet
Tietomallin peruskieli on Entity-Relationship (ER) -malli. Kokonaisuus voidaan ajatella taulukona: Asiakas, Tilaus. Attribuutti on taulukon sarake: nimi, sähköpostiosoite, summa. Suhde on tapa, jolla kokonaisuudet yhdistetään: asiakkaalla voi olla useita tilauksia (yksi moneen suhde).
On olemassa kaksi kriittistä avainkäsitettä. Ensisijainen avain on kenttä, joka yksilöi taulukon jokaisen rivin. esimerkiksi asiakastunnus. Vieras avain on yhden taulukon kenttä, joka osoittaa toisen taulukon perusavaimeen; Tilaustaulukon asiakastunnus yhdistää, minkä asiakkaan tilauksesta on kyse. Nämä yhteydet varmistavat viittauksen eheyden: tilausta ei voida tehdä asiakkaalle, jota ei ole olemassa.
Vinkki: Kun tekoäly luo ER-luonnoksen, on helpompi pyytää erikseen pääavainta jokaiselle taulukolle ja vierasavain jokaiselle suhteelle. Mutta tarkista jokainen mallin ehdottama vierasavain todellista liiketoimintasääntöä vastaan: joskus suhde, jonka luulet olevan "yksi moneen" on itse asiassa "monet moneen".
Normalisointi: Estää uusiutumisen
Normalisointi on prosessi redundanssin vähentämiseksi ja eheyden säilyttämiseksi jakamalla tiedot loogisiin taulukoihin. Tavoitteena on säilyttää samat tiedot yhdessä paikassa. Esimerkiksi sen sijaan, että kirjoittaisit asiakkaan osoitteen yhä uudelleen jokaiselle tilausriville, säilytät osoitteen kerran Asiakastaulukossa ja linkität sen tilauksen vieraalla avaimella. Näin osoitteen muuttuessa päivität sen yhdessä paikassa; Muuten sadoilla tilauksilla on eri osoitteet. Tätä kutsutaan päivityshäiriöksi.
Normalisoinnin vastakohta on denormalisointi: tietoinen toiston salliminen raportoinnin nopeuden vuoksi. Yritysjärjestelmissä (operatiivisessa tietokanta) normalisointi on yleensä edullinen, ja raportointijärjestelmissä (tietovarasto) denormalisointi on usein parempi. Joten "normalisointi ei ole aina hyvä"; Päätös tehdään tarkoituksen mukaan.
Datasanakirja: Common Language
Tietosanakirja on asiakirja, joka määrittelee kunkin kentän merkityksen, tyypin, rajoitukset ja liiketoimintasäännöt. Mitä "tila"-kenttä tarkoittaa? Mitä arvoja se voi ottaa (odottaa, hyväksytty, peruutettu)? Onko se pakollinen? Ilman tätä asiakirjaa eri tiimit tulkitsevat samaa kenttää eri tavalla ja raportti vääristyy. Tietosanakirja on organisaation lingua franca ja yksi MIS-ammattilaisen arvokkaimmista suorituksista. AI voi nopeasti poimia alkuperäisen tietosanakirjan luonnoksen olemassa olevasta taulukkorakenteesta; Mutta vain näitä tietoja käyttävä yksikkö varmistaa kunkin kentän todellisen liiketoiminnallisen merkityksen.
Kolme minikoteloa: Numeroiden mukaan
Tapaus 1 – Toistamisen kustannukset. Jakeluyhtiössä asiakkaan osoite pidettiin erikseen sekä tilaus- että laskutaulukossa. Kun asiakas muutti, osoite päivitettiin vain yhteen taulukkoon; 1 400 laskua meni vanhaan osoitteeseen ja ne palautettiin. Jos osoite normalisoidaan yhdessä taulukossa, yksi päivitys riittäisi. Kunnostusprojekti maksoi 2 viikkoa.
Tapaus 2 – Väärä suhde. Oppilaitoksen MIS-asiantuntija myönsi tekoälyn luomassa mallissa (yksi moneen) suhteen "Oppilas kuuluu luokkaan". Opiskelijat voivat kuitenkin ilmoittautua useammalle kuin yhdelle valinnaiselle luokalle; Suhde oli itse asiassa useista moneen ja välitaulukko (tietue) vaadittiin. Virhe paljastui kentällä, kun opiskelija ei ilmoittautunut toiselle luokalle. Jos tekoälyn ehdotus olisi vahvistettu, se olisi saatu kiinni alusta alkaen.
Tapaus 3 — Tietosanakirjan arvo. Todettiin, että "policy_status"-kenttä vakuutusyhtiössä tulkitsi eri tavalla 5 eri tiimissä, joten sama KPI antoi raporteissa 3 erilaista tulosta. Tekoälypohjaisen datasanakirjan laatiminen ja yhtenäinen sopimus liiketoimintayksikön kanssa eliminoivat raporttien epäjohdonmukaisuudet ja kuukausittaisten täsmäytyskokousten aikaa lyhennettiin 60 %.
Heikko kehote / Vahva kehote
Heikko kehote:
Suunnittele sähköisen kaupankäynnin tietokanta.
Tehokas kehotus:
Roolisi: Olet kokenut tietomallintaja. LUONNOS LOOGINEN tietomalli seuraavien liiketoimintasääntöjen mukaisesti. Säännöt:- Jokaiselle entiteetille: kentät, ensisijainen avain, pakolliset kentät.- Jokaiselle suhteelle: tyyppi (yksi moneen / monta moneen) ja viiteavain.- Ehdota välitaulukkoa useista moneen -suhteissa.- Normalisoi normaalimuotoon asti; Jos suosittelet tahallista denormalisointia, kirjoita perustelut.- Merkitse [VAHVISTUS VAADITTAA] mikä tahansa liiketoimintasääntö, josta et ole varma.Liiketoimintasäännöt:- Asiakas voi tehdä useita tilauksia.- Tilaus sisältää useita tuotteita; Yksi tuote esiintyy useissa tilauksissa.- Tuotteilla on luokkia.[muut säännöt...]
Tehokas kehote selventää mallin tason (looginen), avain- ja suhdesäännöt, normalisointitavoitteen ja vahvistusta vaativat kohdat.
Neljä kopioitavaa mallia
1) Tietosanakirjan luonnos:
Taulukon määritelmästä seuraa datasanakirjan ääriviiva. Jokaisessa kentässä: nimi, tyyppi, onko se pakollinen, mahdolliset arvot, liiketoiminnallinen merkitys (tunniste[PREDICTION], jos se on ennuste). Taulukko: [DDL tai kenttäluettelo]
2) Normalisointitarkistus:
Onko olemassa riski päällekkäisistä tiedoista, päivitysvirheistä ja mahdollisuudesta normalisoitua alla olevassa taulukkorakenteessa? Kirjoita jokaisen löydön kohdalla ylös, mitä normaalia muotoa se rikkoo ja ehdotuksesi. Rakenne: [teksti]
3) ER luonnos liiketoimintasäännöstä:
Käännä seuraavat liiketoimintasäännöt entiteeteiksi, määritteiksi ja suhteiksi. Määritä kunkin suhteen tyyppi (1-1, 1-N, N-N) ja jos N-N, ehdota välitaulukkoa. Merkitse epäselvät säännöt. Säännöt: [teksti]
4) Suhdetyypin varmistuskysymykset:
Luo jokaiselle alla olevan tietomallin suhteelle "kyllä/ei"-liiketoimintakysymys, joka testaa sen tyypin oikeellisuutta (esim. "Voiko opiskelija ilmoittautua useammalle kuin yhdelle luokalle samanaikaisesti?"). Malli: [teksti]
Vertailukaavio: mallitasot
ominaisuus
käsitteellinen
loogista
fyysistä
Yksityiskohta
ainakin
keskikokoinen
useimmat
avain/suhde
Pääomavarat
Avaimet määritelty
Sisältää indeksin/tyypin
Riippuu tietokannasta
ei
ei
Kyllä
kohdeyleisö
liiketoimintayksikkö
analyytikko
Kehittäjä/DBA
Tekoälyn panos
luonnos
vahva veto
Luonnos, DBA-vahvistus
Yleisiä virheitä
- Ajattele monta moneen -suhdetta yksi moneen. Tämä on yleisin mallinnusvirhe; Jos välitaulukko unohtuu, järjestelmä ei voi säilyttää todellista tilaa.
- Laita kaikki yhteen taulukkoon. Kaikkien kenttien kerääminen yhteen taulukkoon "yksinkertaisuuden" vuoksi tuottaa päällekkäisyyksiä ja päivitysvirheitä.
- Ei kirjoita datasanakirjaa. Sama KPI antaa erilaisia tuloksia, kun kenttien merkitys jää mieleen.
- Luotamme sokeasti tekoälyn suosituksiin tietotyypeistä ja rajoituksista. Malli saattaa ehdottaa "riittävän suurta" aluetta; Liiketoimintasääntö määrittää todelliset rajat (esim. TR ID 11 numeroa).
- Absoluutsoiva normalisointi. Liiallinen normalisointi raportointikerroksessa hidastaa kyselyä; Tarkoitus vaihtelee kontekstin mukaan.
Varoitus: tekoäly voi tuottaa malleja, jotka näyttävät hyviltä mutta rikkovat liiketoimintasääntöjä. Jokaisen mallin ehdottaman suhteen kohdalla kysymys "onko se todella tällaista?" Esitä yrityskysymys. Tietomalli on järjestelmän runko; Luurangan murtuma on erittäin vaikea korjata myöhemmin.
Yhteenvetona
Tietomallinnus on prosessi, jossa liiketoiminnallisia tosiasioita jäsennetään entiteeteillä, attribuutteilla ja suhteilla ja etenee käsitteellisellä, loogisella ja fyysisellä tasolla. Ensisijaiset ja vierasavaimet varmistavat viittauksen eheyden; Normalisointi vähentää toistoa, mutta denormalisointi on myös oikeutettua tarkoituksesta riippuen. Tietosanakirja on organisaation yleinen kieli. Tekoäly tarjoaa huomattavan nopeuden ER-luonnosten, tietosanakirjojen ja normalisointikatsausten tuottamisessa; Suhdetyypit, tietotyypit ja liiketoimintasemantiikka on kuitenkin vahvistettava todellista liiketoimintasääntöä vastaan. Se, että malli näyttää hyvältä, ei tarkoita, että se olisi oikea.
Sovellustehtävä
Harkitse "kirjaston lainausjärjestelmää": jäsenet, kirjat, lainaustiedot. (1) Luo looginen malliluonnos tehokkaan kehotteen avulla. (2) Testaa kunkin mallin ehdottaman suhteen tyyppiä (erityisesti "voiko jäsenellä olla useampi kuin yksi kopio samasta kirjasta?") liikekysymyksellä. (3) Etsi vähintään yksi monista moneen -suhde ja määritä välitaulukko. (4) Kirjoita tietosanakirjarivit vähintään neljälle kentälle (nimi, tyyppi, pakollinen, liiketoiminnallinen merkitys). (5) Korosta rajoitus, jonka malli on voinut sovittaa, ja selitä, kuinka varmistaisit sen.
tarkistuslista
- [ ] Jokaisen taulukon ensisijainen avain on määritelty.
- [ ] Vahvistin kunkin liikesuhteen tyypin.
- [ ] Määritin välitaulukon useista moneen -suhteille.
- [ ] Normalisoin tai perustelin kaksoistietojen denormalisoinnin.
- [ ] Kirjoitin tietosanakirjarivin kriittisiä kenttiä varten.
- [ ] Vahvistin tekoälyn tietotyyppi-/rajoitusehdotukset liiketoimintasääntöä vastaan.