Sijoita tiedot oikeaan paikkaan
Saatavilla myös 28 kielellä
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Español (México) · Français (Canada) · Deutsch (Schweiz)
Moduuli 4/6 luvussa Tietojen mallintaminen merkityksen kautta, Data Architect -kurssin luku 2. Jokainen moduuli on itsenäinen. Edellinen: Rakenna looginen malli · Seuraava: Suunnittele kolmanteen normaalimuotoon ja peräänny sitten
Kysymys, johon tämä moduuli vastaa: Miten normalisointi auttaa minua selvittämään, mihin tiedot oikeasti kuuluvat?
Meillä on looginen malli: entiteetit, suhteet, attribuutit ja avaimet. Nyt haluan kysyä yhden tietomallinnuksen tärkeimmistä kysymyksistä: kuuluvatko nämä tiedot oikeasti tänne?
Se kuulostaa yksinkertaiselta. Ei se ole. Olen nähnyt paljon järjestelmiä, joissa jokainen kenttä oli järkevä silloin, kun joku sen loi. Ongelma ei ollut se, että kentät olisivat olleet naurettavia; ongelma oli, että tiedot oli tallennettu väärään paikkaan. Toimituksessa on tietoa, joka oikeasti kuvaa jakelukeskusta. Sama osoite esiintyy sadoissa tietueissa. Yhdessä kentässä on kolme pilkuilla erotettua arvoa. Yhden liiketoimintatiedon muutos tarkoittaa 10 000 tietueen päivittämistä. Juuri tähän ongelmaan normalisointi auttaa, ja ennen kuin hukumme tietokantaterminologiaan, tässä on koko idea: sijoita tieto sinne, minne se kuuluu. Kaikki muu tässä moduulissa auttaa meitä tekemään sen järjestelmällisemmin.
Mitä normalisointi on?
Osio nimeltä “Mitä normalisointi on? ”Normalisointi on tietojen järjestämistä niin, että jokainen tieto tallennetaan kerran, siihen paikkaan, johon se kuuluu. Kun yksi taulu tekee liian monta työtä, jaamme sen tauluihin, joista kukin kuvaa yhtä asiaa, ja yhdistämme ne avaimilla.
Miksi vaivautua? Koska kerran tallennettu tieto on tieto, jonka muutamme kerran. Normalisointi estää toisteisuuden eli saman tiedon kopioitumisen moniin tietueisiin, ja sen mukana epäjohdonmukaisuudet, jotka hiipivät mukaan, kun yksi kopio päivitetään ja muut eivät. Siksi se sopii tapahtumajärjestelmiin, kuten Salesforceen, jossa tietueita luodaan ja päivitetään koko päivän.
Normalisoimme vaiheittain, joita kutsutaan normaalimuodoiksi, ja jokainen niistä esittää yhden kysymyksen:
- Ensimmäinen normaalimuoto (1NF): yksi arvo kenttää kohden ja jotain, mikä tunnistaa jokaisen rivin yksiselitteisesti.
- Toinen normaalimuoto (2NF): jokainen tieto kuvaa koko sitä, mikä rivin tunnistaa, ei vain osaa siitä.
- Kolmas normaalimuoto (3NF): jokainen tieto kuvaa tätä asiaa, ei jotain muuta, mihin se liittyy.
Kolmannen jälkeen on vielä muitakin muotoja. Sanon niistä sanasen myöhemmin, samoin siitä, miksi yleensä pysähdymme kolmanteen. Katsotaan ensin, miten kolme vaihetta tapahtuvat.
Miksi normalisoimme?
Osio nimeltä “Miksi normalisoimme? ”Kun opetan tätä livenä, en aloita toimituksista. Aloitan koirista. Kaikki ymmärtävät koiria, joten kenenkään huomio ei karkaa liiketoimintaan, ja voimme katsoa, miten tiedot yrittävät löytää kotinsa. Sitten viemme samat siirrot Steve Truckingiin.
Istu, paikka, mallinna
Osio nimeltä “Istu, paikka, mallinna ”Alku: raaka taulukko. Laitan pari koiraa näytölle, ja sitten sali lisää omansa. Muutamassa minuutissa meillä on yksi iso luettelo: koira, sen syntymävuosi, kuka sen omistaa, missä omistaja asuu, rotu, kuka sen kasvatti ja temput, jotka se osaa.
| Koira | Syntynyt | Omistaja | Postinumero | Kaupunki | Rotu | Kasvattaja | Temput |
|---|---|---|---|---|---|---|---|
| Bella | 2017 | Marcus | 80202 | Denver | Labradorinnoutaja | Maple Ridge | Istu, Paikka, Anna tassu |
| Milo | 2019 | Marcus | 80202 | Denver | Villakoira | Golden Meadow | Istu, Kieri |
| Max | 2022 | Ana | 64105 | Kansas City | Sekarotuinen | Istu, Kuollut koira | |
| Luna | 2020 | Kenji | 98101 | Seattle | Husky | Cascade | Istu, Paikka, Pyöri |
| Rocky | 2024 | Priya | 30301 | Atlanta | Beagle | Maple Ridge | Istu |
| Coco | 2014 | Ana | 64105 | Kansas City | Chihuahua | Little Paws | Anna tassu, Pyöri |
Se toimii. Jokainen taulukko toimii ensimmäisenä päivänä. Mutta katso, mikä on jo pielessä. Miten löydän jokaisen koiran, joka osaa Anna tassu -tempun? Anan postinumero on kahdella rivillä, samoin Marcuksen: mitä tapahtuu, jos joku päivittää toisen mutta ei toista? Maple Ridge esiintyy kahdesti, samoin Kansas City. Ja Max tuli löytöeläinkodista, joten kasvattajaa ei ole lainkaan.
Vaihe 1: ensimmäinen normaalimuoto. Kaksi sääntöä. Jokaisessa kentässä on yksi arvo, joten pilkuilla erotettu temppuluettelo saa lähteä. Ja jokainen rivi tarvitsee jotain, mikä tunnistaa sen yksiselitteisesti. Ei koiran nimeä; Max-nimisiä koiria on paljon. ID: automaattisesti luotu ID tai GUID. Temput siirtyvät omille riveilleen, yksi rivi kutakin koiraa ja temppua kohden. Ja kun tempulla on oma rivinsä, on tilaa sille, mitä pilkkuluettelossa ei voinut koskaan sanoa: kuinka vaikea temppu on, kuinka hyvin tämä koira sen tekee ja milloin se oppi sen.
Koira (tunnisteena koiran ID)
| Koiran ID | Nimi | Syntynyt | Omistaja | Postinumero | Kaupunki | Rotu | Kasvattaja |
|---|---|---|---|---|---|---|---|
| D-001 | Bella | 2017 | Marcus | 80202 | Denver | Labradorinnoutaja | Maple Ridge |
| D-002 | Milo | 2019 | Marcus | 80202 | Denver | Villakoira | Golden Meadow |
| D-003 | Max | 2022 | Ana | 64105 | Kansas City | Sekarotuinen | |
| D-004 | Luna | 2020 | Kenji | 98101 | Seattle | Husky | Cascade |
| D-005 | Rocky | 2024 | Priya | 30301 | Atlanta | Beagle | Maple Ridge |
| D-006 | Coco | 2014 | Ana | 64105 | Kansas City | Chihuahua | Little Paws |
Koiran temppu (tunnisteena koiran ID + temppu)
| Koiran ID | Temppu | Vaikeus | Taitotaso | Opittu |
|---|---|---|---|---|
| D-001 | Istu | Helppo | Mestari | 2017-11 |
| D-001 | Paikka | Helppo | Mestari | 2018-01 |
| D-001 | Anna tassu | Keskitaso | Hyvä | 2018-06 |
| D-002 | Istu | Helppo | Mestari | 2020-02 |
| D-002 | Kieri | Vaikea | Opettelee | 2023-05 |
| D-003 | Istu | Helppo | Hyvä | 2022-06 |
| D-003 | Kuollut koira | Vaikea | Opettelee | 2024-03 |
| D-004 | Istu | Helppo | Mestari | 2020-11 |
| D-004 | Paikka | Helppo | Hyvä | 2021-01 |
| D-004 | Pyöri | Keskitaso | Mestari | 2021-06 |
| D-005 | Istu | Helppo | Opettelee | 2025-02 |
| D-006 | Anna tassu | Keskitaso | Mestari | 2015-06 |
| D-006 | Pyöri | Keskitaso | Opettelee | 2025-04 |
Nyt ”jokainen koira, joka osaa Anna tassu -tempun” on helppo kysymys. Mutta huomaa, millä koiran temppu tunnistetaan: ei yhdellä asialla vaan kahdella asialla yhdessä, koiralla ja tempulla. Pidä se mielessä.
Vaihe 2: toinen normaalimuoto. Toisella normaalimuodolla on merkitystä vain, kun rivi tunnistetaan yhdistelmällä, ja koiran temppu tunnistetaan. Kysyn siis jokaisesta sarakkeesta: kuvaako se koko yhdistelmää vai vain osaa siitä? Taitotaso kuvaa sitä, miten tämä koira tekee tämän tempun: Bella on Istu-tempun mestari, Rocky opettelee sitä vielä. Oppimispäivä samoin. Mutta vaikeus? Istu on helppo, teki sen mikä koira tahansa. Se kuvaa temppua, vain osaa avaimesta, ja siksi ”Helppo” toistuu jokaisella Istu-rivillä. Temppu saa siis oman taulunsa, ja jäljelle jää pari.
Temppu
| Tempun ID | Temppu | Vaikeus |
|---|---|---|
| T-01 | Istu | Helppo |
| T-02 | Paikka | Helppo |
| T-03 | Anna tassu | Keskitaso |
| T-04 | Kieri | Vaikea |
| T-05 | Kuollut koira | Vaikea |
| T-06 | Pyöri | Keskitaso |
Koiran temppu (koiran ID + tempun ID)
| Koiran ID | Tempun ID | Taitotaso | Opittu |
|---|---|---|---|
| D-001 | T-01 | Mestari | 2017-11 |
| D-001 | T-02 | Mestari | 2018-01 |
| D-001 | T-03 | Hyvä | 2018-06 |
| D-002 | T-01 | Mestari | 2020-02 |
| D-002 | T-04 | Opettelee | 2023-05 |
| D-003 | T-01 | Hyvä | 2022-06 |
| D-003 | T-05 | Opettelee | 2024-03 |
| D-004 | T-01 | Mestari | 2020-11 |
| D-004 | T-02 | Hyvä | 2021-01 |
| D-004 | T-06 | Mestari | 2021-06 |
| D-005 | T-01 | Opettelee | 2025-02 |
| D-006 | T-03 | Mestari | 2015-06 |
| D-006 | T-06 | Opettelee | 2025-04 |
Tuo koiran temppu -taulu on se, jonka löysimme moduulissa 2, ja tietomallinnuksessa sillä on nimi: liitos, tai kuten minä sitä kutsun, looginen liitosobjekti. Koira osaa monta temppua; tempun osaa moni koira. Liitos on niiden välissä, eikä se ole tyhjää putkistoa: siinä ovat tiedot, jotka kuuluvat itse suhteelle, taitotaso ja päivämäärä. Kohtaamme sen uudelleen moduulissa 6, ja luvussa 3 näemme, että Salesforce käyttää sanaa ”junction object” suppeammin: Salesforcen liitosobjekti (Salesforce Junction Object) on mukautettu objekti, jolla on kaksi master-detail-suhdetta (luku 3, moduuli 7).
Vaihe 3: kolmas normaalimuoto. Palataan nyt koiratauluun. Kaikki siinä tunnistetaan koiran ID:llä, joten toisella normaalimuodolla ei ole sanottavaa. Kolmas normaalimuoto kysyy eri kysymyksen: kuvaako tämä tieto koiraa vai jotain muuta, mihin koira liittyy? Rotu on oma asiansa: labradorinnoutaja on labradorinnoutaja, oli koira mikä tahansa, ja sitä koskevat tiedot, kuten koko, kuuluvat rodulle eivätkä Bellalle. Postinumero ja kaupunki kuvaavat omistajaa, eivät koiraa: siellä Ana asuu, katsoimmepa kumpaa hänen koiristaan tahansa. Kasvattajan tiedot kuvaavat kasvattajaa. Jokainen niistä on tieto toisesta tiedosta, joten jokainen siirtyy omaan tauluunsa, ja koira osoittaa siihen viiteavaimella:
- Koira: koiran ID, nimi, syntynyt, omistajan ID, rodun ID, kasvattajan ID
- Omistaja: omistajan ID, nimi, postinumero, kaupunki
- Rotu: rodun ID, rotu, koko
- Kasvattaja: kasvattajan ID, nimi, kaupunki
- Temppu ja koiran temppu vaiheesta 2
Ana on nyt tallennettu kerran, ja hänen molemmat koiransa osoittavat häneen. Maple Ridge on tallennettu kerran, ja rotutaulu antaa kodin kutakin rotua koskeville tiedoille, kuten koolle, joille taulukossa ei ollut paikkaa. Viiteavain voi olla tyhjä: Maxilla ei ole kasvattajan ID:tä, ja se on rehellinen vastaus, ei aukko. Sitten heitän salille kompakysymyksen: kun omistaja sai koiran, mihin se päivämäärä menee? Koiraan. Tässä mallissa koiralla on yksi omistaja kerrallaan, joten se päivämäärä kuvaa koiran suhdetta omistajaansa.
Voisit mennä vielä askeleen pidemmälle ja erottaa kaupungin postinumerosta; oppikirjat tekevät niin. Käytännössä osoite pysyy koossa, ja Kansas City sijaitsee joka tapauksessa kahdessa osavaltiossa, mukava muistutus siitä, ettei todellinen maailma lue oppikirjojamme.
Siinä on eteneminen: taulukko, sitten kolme kysymystä, ja jokainen tieto päätyy yhteen paikkaan. Astu askel taaksepäin ja katso, mitä rakensimme. Yhdestä sotkuisesta luettelosta tuli kuusi taulua, joista kukin kuvaa yhtä asiaa, avaimilla yhdistettyinä:
Kukaan ei tarvinnut yhtään Salesforce-sanaa pysyäkseen mukana. Siinä on vain koirat, niiden ympärillä olevat ihmiset ja se, mitä koirat osaavat.
Sovelletaan sitä nyt Steve Truckingiin
Osio nimeltä “Sovelletaan sitä nyt Steve Truckingiin ”Koirien avulla siirrot on helppo nähdä. Oikeassa liiketoiminnassa niillä on väliä, koska samat virheet maksavat suuressa mittakaavassa oikeaa rahaa. Viedään siis samat kolme kysymystä Steve Truckingiin. Kuvittele, että se pitää toimituksiaan näin:
| Toimitus | Vähittäiskauppakumppani | Jakelukeskus | Jakelukeskuksen kaupunki | Tiimi | Kuorma-auto |
|---|---|---|---|---|---|
| 1001 | Keystone | Keystone Phoenix DC | Phoenix | Tiimi 12 | 117 |
| 1002 | Keystone | Keystone Phoenix DC | Phoenix | Tiimi 8 | 122 |
| 1003 | Keystone | Keystone Phoenix DC | Phoenix | Tiimi 12 | 117 |
Ensisilmäyksellä tässä ei ole mitään monimutkaista. Mutta katso jakelukeskusta. Toistamme ”Keystone Phoenix DC, Phoenix” jokaisessa sieltä lähtevässä toimituksessa: Steve Trucking tekee noin 3 300 toimitusta päivässä yhdeksästä jakelukeskuksesta, joten kustakin muutama sata päivässä. Mitä tapahtuu, jos jakelukeskus muuttaa? Kuinka monta tietuetta muutamme, ja mitä tapahtuu, jos yksi jää huomaamatta? Nyt tiedot sanovat, että jakelukeskus on kahdessa kaupungissa yhtä aikaa. Se on päivitysanomalia. Entä jos haluamme perustaa uuden jakelukeskuksen ennen sen ensimmäistä toimitusta? Entä jos poistamme jakelukeskuksen viimeisen toimituksen: poistimmeko juuri ainoan paikan, johon olimme tallentaneet siitä mitään?
Nämä ovat saman ongelman eri oireita: sekoitimme eri asioita koskevat tiedot keskenään. Jakelukeskuksen tiedot kuuluvat jakelukeskukselle. Toimituksen tiedot kuuluvat toimitukselle. Tiimin tiedot kuuluvat tiimille. Se on normalisointia käytännössä.
Ensimmäinen normaalimuoto: älä piilota toistuvaa rakennetta
Osio nimeltä “Ensimmäinen normaalimuoto: älä piilota toistuvaa rakennetta ”Aloitetaan ensimmäisestä normaalimuodosta eli 1NF:stä, jossa ihmiset joskus tekevät normalisoinnista vaikeampaa kuin sen tarvitsisi olla.
Oletetaan, että toimituksella on kenttä nimeltä Tuotteet: ”Jääkaappi, jääpalakonesarja, vanhan poisvienti.” Olemme laittaneet kolme tietoa yhteen kenttään. Se tuntuu kätevältä, kunnes joku kysyy: ”Montako poisvientiä teimme viime kuussa?” Tai kuvittele kentät nimeltä Tuote 1, Tuote 2 ja Tuote 3. Se toimii, kunnes tulee toimitus, jossa on neljä tuotetta. Ongelma ei ole se, että valitsimme väärän määrän tuotekenttiä. Ongelma on, ettemme tunnistaneet toistuvaa rakennetta. Toimituksessa voi olla useita tuotteita. Se on tietoa, joka meidän pitäisi mallintaa: moduulissa 2 löytämämme toimitusrivi.
1NF:n käytännön opetus: älä piilota toistuvaa rakennetta kenttien sisään. Jos liiketoiminta kertoo, että jokin voi tapahtua monta kertaa, kuuntele. Siellä voi olla toinen entiteetti, joka yrittää päästä ulos.
Näet tätä oikeissa orgeissa jatkuvasti. Joku tarvitsee kuvauksen usealla kielellä, joten hän luo kentän nimeltä Description_English, sitten Description_French, sitten Description_German. Tai hyväksyntään tarvitaan muutama ihminen, joten saamme kentät Hyväksyjä 1, Hyväksyjä 2, Hyväksyjä 3. Kun löydän tuollaista arvioinnissa, siitä tulee näpeille: korjaa tietomallisi. Yksi tai kaksi, ehkä, jos liiketoiminnalla todella on aina vain yksi tai kaksi. Kaiken sen yli pitäisi olla alaobjekti: käännös, jolla on kieli, tai hyväksyntävaihe, jolla on hyväksyjä. Seuraavasta kielestä tai neljännestä hyväksyjästä tulee uusi tietue, ei uusi kenttä ja käyttöönotto.
Toinen normaalimuoto: kuvaa koko asiaa
Osio nimeltä “Toinen normaalimuoto: kuvaa koko asiaa ”Toisella normaalimuodolla eli 2NF:llä on merkitystä, kun tietue tunnistetaan asioiden yhdistelmällä. Otetaan toimitusrivi. Sillä on oma tietueen ID, mutta jokainen niistä on yksilöllinen yhdistelmällä toimitus + tuote. Oletetaan, että tallennamme toimituksen, tuotteen, määrän ja tuotteen kuvauksen.
Määrä on tässä järkevä: se kuvaa tätä tuotetta tässä toimituksessa. Mutta tuotteen kuvaus ei kuvaa yhdistelmää; se kuvaa tuotetta. Laita se jokaiseen toimitusriviin, niin toistamme sen aina, kun tuo jääkaappimalli lähtee uudella kuorma-autolla. Se on vihje siitä, että tieto kuuluu jonnekin muualle.
2NF:n kysymys on siis: kuvaako tämä attribuutti koko asiaa, jota tunnistan, vai vain osaa siitä? Jos se kuvaa vain tuotetta, se menee tuotteelle. Jos se kuvaa tuotteen paikkaa juuri tässä toimituksessa (määrä, asennetaanko se), se kuuluu toimitusriville. Moni ylläpitäjä ei koskaan tietoisesti sano: ”Nyt sovellan toista normaalimuotoa.” Se on ihan hyvä. Minulle on paljon tärkeämpää, että opit kysymään: mitä tämä tieto oikeasti kuvaa?
Kolmas normaalimuoto: älä tallenna tietoja muista tiedoista
Osio nimeltä “Kolmas normaalimuoto: älä tallenna tietoja muista tiedoista ”Nyt se, josta välitän eniten jokapäiväisessä mallinnuksessa: kolmas normaalimuoto eli 3NF.
Jokaisella jakelukeskuksella on esihenkilö vähittäiskauppakumppanin puolella, joku, joka käyttää kumppaniportaalia. Oletetaan, että laitamme jakelukeskuksen esihenkilön nimen suoraan jokaiseen toimitukseen. Mitä tapahtuu, kun jakelukeskus saa uuden esihenkilön? Päivitämme jokaisen toimituksen siitä jakelukeskuksesta. Siinä on taas sama haju: toistamme tietoa, joka kuuluu jonnekin muualle. Toimitus lähtee jakelukeskuksesta; jakelukeskuksella on esihenkilö. Ne ovat kaksi suhdetta, ja esihenkilön nimi kuuluu jakelukeskukselle.
Klassinen oppikirjaversio on osoite: postinumero, kaupunki ja osavaltio tallennettuina yhdessä jokaiseen tietueeseen, vaikka kaupunki ja osavaltio yleensä seuraavat postinumerosta. Sama muoto, sama kysymys.
3NF:n käytännön kysymys on: kuvaako tämä tieto tätä asiaa vai jotain muuta, mihin tämä asia liittyy? Haluan, että kysyt sitä jatkuvasti.
Astu nyt askel taaksepäin, samoin kuin koirien kanssa. Toimitustaulusta, josta aloitimme, on tullut viisi asiaa, joista kullakin on omat tietonsa: toimitusrivi erottui ensimmäisessä normaalimuodossa, tuote toisessa, ja jakelukeskuksen kaupunki ja esihenkilö siirtyivät jakelukeskukselle kolmannessa.
Samat kolme kysymystä, sama tulos: jokainen tieto yhdessä paikassa.
Yksinkertainen tapa ajatella 1NF:ää, 2NF:ää ja 3NF:ää
Osio nimeltä “Yksinkertainen tapa ajatella 1NF:ää, 2NF:ää ja 3NF:ää ”Normalisointiin voi käyttää kokonaisen tietokantakurssin. Me emme käytä. Tällä kurssilla haluan, että sinulla on käytännön arkkitehdin ymmärrys:
- 1NF: piilotanko useita arvoja tai toistuvia rakenteita kentän tai tietueen sisään?
- 2NF: kuvaako tämä tieto koko asiaa, jota tunnistan?
- 3NF: kuvaako tämä tieto todella tätä entiteettiä vai jotain siihen liittyvää?
Ne eivät ole tietokantaoppikirjan määritelmiä. Ne ovat kysymyksiä, joita voin oikeasti käyttää suunnitellessani.
Kyllä, normalisointi menee pidemmälle: Boyce–Coddin normaalimuoto (BCNF) tiukentaa 3NF:n sääntöjä malleissa, joissa on monimutkaisempia avaimia, ja on olemassa neljäs, viides ja jopa kuudes normaalimuoto. Ne käsittelevät harvinaisempia toistuvuuden lajeja, sellaisia, jotka syntyvät epätavallisista avainrakenteista eivätkä niinkään jokapäiväisistä liiketoimintatietueista. Paljon teoriaa, ja kokemukseni mukaan ei päänvaivan arvoista sellaisissa järjestelmissä, joita rakennamme Salesforceen. Liiketoimintajärjestelmissä paine kulkee yleensä toiseen suuntaan: peräännymme kolmannesta normaalimuodosta paljon todennäköisemmin, käyttäjien, raportoinnin ja suorituskyvyn vuoksi, kuin menemme sen yli. Siitä kertoo seuraava moduuli. Tiedä, että pidemmät muodot ovat olemassa, mutta useimpaan siihen, mitä teemme, 1NF–3NF antavat meille tarvitsemamme ajattelun työkalut.
Suunnittele kolmanteen normaalimuotoon
Osio nimeltä “Suunnittele kolmanteen normaalimuotoon ”Tässä on kantani. Kun yritän ymmärtää liiketoimintaa ja suunnitella sen loogista mallia, haluan aloittaa puhtaalta pöydältä: toimituksen tiedot toimitukselle, jakelukeskuksen tiedot jakelukeskukselle, kuorma-auton tiedot kuorma-autolle, toistuvat käsitteet käsitteinä mallinnettuina. En halua liiketoimintatietoa kopioituna ympäri mallia vain siksi, että se voisi helpottaa jotain näyttöä tai raporttia. En vielä.
Mutta normalisointi ei ole uskonto. Tavoite ei ole akateemisesti puhtain mahdollinen malli. Olen nähnyt arkkitehtien keskittyvän puhtauteen niin paljon, että mallista tulee tuskallinen kaikille, joiden täytyy käyttää sitä. Emme yritä voittaa normalisointikilpailua; rakennamme järjestelmää, ja sillä järjestelmällä on käyttäjiä, raportteja, integraatioita, suorituskykytarpeita, mittakaava ja yhä useammin tekoäly, joka lukee tietoja. Ne saattavat haluta tiedot erimuotoisina.
Lähtökohtani on siis suunnittele kolmanteen normaalimuotoon, kun se on mahdollista, ja peräänny sitten, kun on pakko: ymmärrä ensin, mihin kukin tieto kuuluu. Sitten, jos aiomme poiketa siitä, haluan tietää miksi. Jos vastaus on ”koska en tiennyt, mihin muualle laittaisin kentän”, se ei riitä. Jos vastaus on ”kopioimme tämän arvon tarkoituksella, koska se tekee kumppanien tuloskortista yksinkertaisen, ja meillä on luotettava tapa pitää se synkronissa”, nyt käymme arkkitehtuurikeskustelua.
Mitä arkkitehti tässä päättää
Osio nimeltä “Mitä arkkitehti tässä päättää ”Kun normalisoin loogista mallia, etsin:
- Toistuvia arvoja tai rakenteita, jotka pitäisi mallintaa erikseen.
- Attribuutteja, jotka kuvaavat eri entiteettiä kuin sitä, johon ne on tallennettu.
- Tietoja, jotka on turhaan monistettu moniin tietueisiin, ja riippuvuuksia, jotka tekevät niistä epäjohdonmukaisia.
- Kenttien sisään piilotettuja liiketoimintakäsitteitä.
- Puhdasta mallia, joka kuvaa totuuden ennen toteutuksen kompromisseja.
Ei siksi, että jokaisen fyysisen järjestelmän pitäisi pysyä täydellisesti normalisoituna. Päinvastoin. Seuraavassa moduulissa poikkeamme puhtaasta mallista tarkoituksella, käyttäjien, raportoinnin, mittakaavan, analytiikan ja tekoälyn vuoksi, ja teemme sen tietäen tarkalleen, mistä luovumme.