Suunnittele kolmanteen normaalimuotoon ja peräänny sitten
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 5/6 luvussa Tietojen mallintaminen merkityksen kautta, Data Architect -kurssin luku 2. Jokainen moduuli on itsenäinen. Edellinen: Sijoita tiedot oikeaan paikkaan · Seuraava: Muuta malli Salesforceksi
Kysymys, johon tämä moduuli vastaa: Milloin minun pitäisi tarkoituksella poiketa puhtaasta normalisoidusta mallista?
Edellisessä moduulissa kehotin sinua suunnittelemaan kolmanteen normaalimuotoon.
Nyt kehotan sinua rikkomaan sen.
Joskus.
Se on tärkeä ero. On suuri ero sillä, rakentaako vahingossa sotkuisen tietomallin vai denormalisoiko tarkoituksella puhtaan mallin. Jos et ylipäätään ymmärrä, mihin tiedot kuuluvat, niiden kopioiminen jonnekin muualle ei ole arkkitehtuuria. Se on pelkkää monistamista.
Mutta kun ymmärrän puhtaan loogisen mallin, voin tehdä tietoisen päätöksen muotoilla tiedot toisin niitä käyttäville ihmisille ja järjestelmille.
Suunnittele kolmanteen normaalimuotoon, kun se on mahdollista. Peräänny sitten, kun on pakko.
Huomaa, mitä tuo lause ei sano. Se ei sano, että kolmas normaalimuoto olisi helpompi ymmärtää. Joskus se on vaikeampi: täysin normalisoitu malli voi hajottaa yhden liiketoiminnan idean viiteen objektiin, ja sitä käyttävien ihmisten täytyy koota se uudelleen päässään. Normalisointi kertoo minulle, mihin kukin tieto kuuluu. Se ei lupaa, että se olisi helpoin muoto lukea, käyttää tai raportoida. Juuri siksi perääntyminen on suunnittelutaito eikä epäonnistuminen.
Aloita mallintamalla totuus. Päätä sitten, miten se totuus pitää toimittaa.
Istu, paikka, mallinna
Osio nimeltä “Istu, paikka, mallinna ”Takaisin koirien pariin, ja tällä kertaa teemme muutaman tarkoituksellisen valinnan.
Rotu: valintaluettelo vai oma taulu? Aja se niiden kysymysten läpi, jotka annan sinulle myöhemmin tässä moduulissa. Onko tietoa useamman kuin yhden sarakkeen verran? Kyllä: ainakin koko. Kuinka monta arvoa? Kennelliitot tunnustavat muutamia satoja rotuja (pelkästään American Kennel Club luettelee 205), mikä ylittää reilusti nyrkkisääntöni, noin 20. Rotu ansaitsee siis oman taulunsa, ja jokainen koira osoittaa rotuunsa. Se ratkaisee kysymyksen, jota olemme kantaneet moduulista 1 asti: rotu on oma laatikkonsa.
Taitotaso: valintaluettelo. Opettelee, Hyvä, Mestari. Kolme nimiötä, niistä ei ole muuta sanottavaa, eivätkä ne muutu. Juuri siihen valintaluettelo on tarkoitettu.
Montako temppua kukin koira osaa? Vastaus on jo mallissa: laske koiran koiran temppu -tietueet. Mutta kouluttaja haluaa sen luvun jokaiseen raporttiin, lajitella ja suodattaa sen mukaan, rakentamatta raporttia kahden taulun yli. Joten peräännyn ja pidän Osatut temput -laskurin suoraan koiralla. Se on kopio. Totuus asuu yhä koiran tempussa; laskuri on sen esitys, ja sen on pysyttävä tahdissa. Salesforce antaa meille siistin tavan tehdä juuri se, ja näemme sen moduulissa 6.
Nyt juonenkäänne: koirakoulu alkaa ottaa vastaan kissoja. Mitä teemme? Yksi vaihtoehto: lisätään kissataulu koirataulun viereen ja kissan temppu koiran tempun viereen. Kaikki tuplaantuu: kaksi kappaletta jokaista näyttöä, kaksi jokaista raporttia, ja sinä päivänä, kun he ottavat kaneja, kolme. Toinen vaihtoehto: astu askel taaksepäin ja huomaa, että kissalla on omistaja, ehkä kasvattaja, rotu, syntymäpäivä ja kärsivällisyydellä temppu tai kaksi. Samat tiedot ja samat suhteet kuin koiralla. Joten yleistämme: lemmikki (Pet), jolla on laji (Species), koira tai kissa. Jokainen rotu kuuluu myös johonkin lajiin, ja siellä laji todella asuu: labradorinnoutaja on koira. Lemmikki kantaa kopiota tarkoituksella, jotta jokainen näyttö ja raportti voi alkaa kysymyksellä ”koira vai kissa?” katsomatta rotua. Taas yksi tarkoituksellinen kopio, ja moduulissa 6 se saa oman tehtävänsä.
Se on suunnittelua muutosta varten, ja se on kompromissi. Yleistä liian aikaisin, niin kaikesta tulee epämääräinen ”asia”, jolla on tyyppikenttä, jota kukaan ei ymmärrä. Yleistän, kun liiketoiminta oikeasti tuo minulle toisen lajin ja kaksi jakavat lähes kaiken, kuten koirat ja kissat tässä. Jos kissat tarvitsisivat hyvin erilaisia tietoja, miettisin kahdesti.
Nyt samanlaisia valintoja Steve Truckingilla, jossa panokset ovat suuremmat.
Puhtain malli ei aina ole paras järjestelmä
Osio nimeltä “Puhtain malli ei aina ole paras järjestelmä ”Kuvittele tiimi pysähdyksellä. Toimituksella on tuotteensa. Asennuksella on tarkistuslista. Jokainen vaihe tarvitsee valokuvat. Vastaanottaja allekirjoittaa.
Normalisoitu malli on kaunis: toimitus → toimitusrivi → asennuksen tarkistuslista → valokuva, kukin paikassaan.
Sitten istun alas niiden ihmisten kanssa, jotka sitä oikeasti käyttävät. Tiimi kuittaa noin kymmenen pysähdystä päivässä, pihateillä, usein ilman kenttää. Jos kaunis mallini lähettää heidät näyttöjen ja liittyvien luetteloiden sokkeloon yhden pysähdyksen kuittaamiseksi, minulla on arkkitehtuuriongelma.
Tietomalli ei ole ainoa asia, jota suunnittelemme.
Suunnittelemme järjestelmää.
Joskus käyttökokemus voittaa
Osio nimeltä “Joskus käyttökokemus voittaa ”Tämä on yksi syistä, joiden vuoksi peräännyn joskus täydellisesti normalisoidusta mallista: käyttökokemus.
Ehkä käsite voisi teknisesti olla oma entiteettinsä, mutta sen erottaminen lisää monimutkaisuutta, joka tuo hyvin vähän arvoa. Ehkä päätietue, jolla on useita tasoja alitietueita, on akateemisesti puhdas mutta kurja syöttää ja ylläpitää. Ehkä käsite on pieni, vakaa ja sitä käytetään lähinnä valintana.
Tässä kohtaa lakkaan kysymästä vain ”Mihin tämä tieto teoriassa kuuluu?” ja alan kysyä ”Miten tätä järjestelmää oikeasti tullaan käyttämään?”
Se ei tarkoita, että jokainen valitus ylimääräisestä klikkauksesta litistää mallin. Se tarkoittaa, että käytettävyys on legitiimi arkkitehtuurin syöte.
Joskus raportointi voittaa
Osio nimeltä “Joskus raportointi voittaa ”Raportointi on toinen yleinen syy.
Jokainen vähittäiskauppakumppani haluaa tuloskortin: ajallaan tehdyt toimitukset alueittain ja kuukausittain. Puhtaassa mallissa toimitus tietää jakelukeskuksensa, ja jakelukeskus tietää alueensa. Teknisesti pystymme navigoimaan sen.
Mutta pystyykö raportointityökalu? Pystyvätkö ihmiset, jotka rakentavat omat raporttinsa? Pystyvätkö he vastaamaan kysymykseen ilman raportointiarkkitehtuuria, joka on monimutkaisempi kuin itse kysymys?
Silloin saatan kopioida tai johtaa alueen toimitukseen, lähemmäs sitä paikkaa, jossa sitä käytetään.
Nyt olen tuonut mukaan monistamista. Tarvitsen siis toisen kysymyksen: kuka omistaa totuuden?
Jos lähdearvo muuttuu, mitä kopiolleni tapahtuu? Pitäisikö sen muuttua? Vai pitäisikö sen säilyttää se, mikä oli totta toimituksen hetkellä? Ne ovat eri vaatimuksia.
Denormalisointi ei poista monimutkaisuutta.
Se siirtää sitä.
Lookup vai valintaluettelo?
Osio nimeltä “Lookup vai valintaluettelo? ”Tässä on pienempi esimerkki, johon Salesforce-ylläpitäjät törmäävät jatkuvasti. Käyttäjän täytyy valita arvojen joukosta. Luonko uuden entiteetin ja liitän siihen, vai käytänkö valintaluetteloa?
Otetaan toimituksen tila: aikataulutettu, lastattu, jakelussa, saapumassa, toimitettu, asennettu, poikkeama, palautettu. Lyhyt, vakaa nimiöiden luettelo. Valintaluettelo on juuri sitä, mitä haluan.
Otetaan sitten pysähdyksen laji: pelkkä toimitus, toimitus ja asennus, toimitus ja poisvienti. Siinä on omaa tietoa: kuinka kauan pysähdys kestää, mitä taitoja tiimi tarvitsee, mikä asennuksen tarkistuslista on voimassa. Se muuttuu itsenäisesti, ja liiketoiminta hallitsee sitä. Se on entiteetti, ei nimiö.
Jos luon objektin jokaiselle käsitteelle, joka teoriassa voitaisiin normalisoida, voin rakentaa teknisesti kauniin järjestelmän, jonka käytöstä kukaan ei nauti. Jos teen jokaisesta käsitteestä valintaluettelon, koska se on helppoa, voin maalata itseni nurkkaan hyvin nopeasti.
Kysyn siis: onko sillä omaa tietoa? Suhteita? Muuttuuko se itsenäisesti? Täytyykö sitä hallita tietona? Voisiko liiketoiminta lopulta tarvita siltä enemmän kuin nimiön?
Tässä ovat kysymykset, joita oikeasti kysyn suunnittelupalaverissa.
Onko tietoa useamman kuin yhden sarakkeen verran? Jos arvo tarvitsee kuvauksen, keston, taitoluettelon tai omistajan, se ei ole enää nimiö.
Kuinka monta arvoa? Nyrkkisääntöni on noin 20. Yli 20 arvon jälkeen valintaluettelo alkaa hajota, ja on aika miettiä objektia. Osavaltiot, viisikymmentä kappaletta, ovat poikkeus, jonka kanssa elämme, ja maat ovat vielä pahempia; rehellisesti, rakastaako kukaan maavalintaluetteloita? Minusta ne ovat ärsyttäviä.
Luodaanko arvoja ajan mittaan, ja kuka ne luo? Valintaluettelon arvon lisääminen on konfiguraatiomuutos, mikä tarkoittaa ylläpitäjää. Jos liiketoiminta lisää arvoja joka viikko eivätkä lisääjät ole ylläpitäjiä, valintaluettelo laittaa tiketin jokaisen uuden arvon eteen.
Täytyykö ihmisten suodattaa ja raportoida sen mukaan? Valintaluettelot ovat siihen erinomaisia. Lookupit eivät ole yhtä siistejä. Jokainen lookup lisää hypyn: raporttityyppi seuraa vain lyhyttä ketjua liittyviä objekteja (mukautettu raporttityyppi sallii enintään neljä objektisuhdetta), näytöstä tulee liittyviä luetteloita liittyvien luetteloiden sisällä, ja koodista tulee monimutkaisempaa.
Arvoluettelo aloittaa usein elämänsä valintaluettelona ja ansaitsee ajan mittaan oman objektinsa. Anna sen ansaita se.
Joskus mittakaava muuttaa vastauksen
Osio nimeltä “Joskus mittakaava muuttaa vastauksen ”Suunnitelma, joka toimii kauniisti muutamalla tuhannella tietueella, voi käyttäytyä hyvin eri tavalla miljoonilla.
Älä siis katso pelkkää kaaviota. Tunne luvut.
Steve Trucking tekee noin miljoona toimitusta vuodessa, ja määrä kasvaa 30 % vuodessa. Jokainen toimitus kerää noin kahdeksan tilapäivitystä. Se tekee tänä vuonna kahdeksan miljoonaa tilatietuetta ja kolmantena vuonna noin 13,5 miljoonaa vuodessa. Lisää siihen neljä tai viisi miljoonaa valokuvaa vuodessa.
Sama malli. Hyvin erilainen arkkitehtuuri.
Menemme paljon syvemmälle osassa Arkkitehtuuri suuressa mittakaavassa. Muista toistaiseksi: volyymi voi muuttaa tietomallinnuksen päätöksen. Loogisesti oikea suhde ei ole automaattisesti paras fyysinen suunnitelma joka mittakaavassa.
Eri käyttäjät haluavat eri muotoja
Osio nimeltä “Eri käyttäjät haluavat eri muotoja ”Tähän asti olemme ajatelleet operatiivista järjestelmää. Koordinaattorit reitittävät toimituksia. Tiimit kuittaavat pysähdyksiä. Järjestelmä muuttuu liiketoiminnan pyöriessä.
Mutta liiketoiminta haluaa myös analysoida vuosien historiaa. Mitkä kumppanit ja alueet myöhästelevät? Miten toimitusaika on muuttunut? Kuinka usein asennukset tarvitsevat toisen käynnin?
Analyyttinen järjestelmä voi haluta samat tiedot eri tavalla järjestettyinä. Kuulet termejä kuten tietovarasto, fakta, dimensio ja tähtimalli. Emme avaa niitä tässä; Steve Truckingilla se on Snowflake-tietovarasto, ja palaamme siihen myöhemmin kurssilla.
Toistaiseksi: eri käyttäjät voivat tarvita saman totuuden eri muotoja.
Tekoäly tuo uuden käyttäjän
Osio nimeltä “Tekoäly tuo uuden käyttäjän ”Ja nyt on vielä yksi käyttäjä: tekoäly.
Vastaanottaja lähettää tekstiviestin: ”Missä toimitukseni on?” Tekoälyavustaja voisi hakea tämän:
Toimitus 10427, reitti 3312, pysähdys 7, kuorma-auto 117, aikaikkuna 13.00–15.00.
Perinteinen sovellus seuraa noita suhteita mielellään. Mutta vastatakseen vastaanottajalle avustaja tarvitsee kontekstia, joka on koottu useasta paikasta:
Redrock-astianpesukoneesi on tämän päivän reitin seitsemäs pysähdys Phoenixin jakelukeskuksesta. Kuorma-auto on kolmen pysähdyksen päässä, ja olet yhä klo 13–15 aikaikkunassasi.
Olemme ottaneet tietoja useasta toisiinsa liittyvästä entiteetistä ja koonneet litteämmän, kontekstirikkaan esityksen yhdelle tietylle käyttäjälle.
Se ei tarkoita, että tuhoaisin normalisoidun mallini. Eikä se todellakaan tarkoita: ”tekoäly pitää litteästä datasta, joten laita kaikki yhteen jättimäiseen objektiin.” Älä tee niin.
Totuuden lähde pysyy puhtaana. Tekoäly saa esityksen, joka on rakennettu sen tekemää työtä varten. Se on sama idea, jonka juuri näimme analytiikan kohdalla:
Yksi totuuden lähde voi tukea useita käyttömuotoja.
Menemme paljon syvemmälle groundingiin ja hakuun myöhemmin kurssilla.
Älä luo useita totuuksia
Osio nimeltä “Älä luo useita totuuksia ”Tässä on vaara.
Jos kopioin alueen toimitukseen raportointia varten, lähetän litistetyn version Snowflakeen ja rakennan kontekstirikkaan version tekoälyavustajalle, mikä niistä on oikea?
Se kysymys tarvitsee vastauksen. Haluan tietää, missä auktoritatiivinen arvo asuu. Kaikki muu on sen totuuden esitys jotain tarkoitusta varten.
Se paikka on system of record (lähdejärjestelmä). Denormalisoidut kopiot voivat olla hyviä: pysähdysnäyttö, tuloskortti, Snowflake ja tekoälyn konteksti tekevät kukin työnsä paremmin niille rakennetussa muodossa, ja niihin viittaaminen on ihan hyvä. Mutta kun jokin muuttuu, muutos alkaa lähdejärjestelmästä, tyypillisesti relaatiomallista, ja virtaa ulospäin jokaiseen kopioon. Kukaan ei korjaa aluetta Snowflakessa tai muokkaa tekoälyn kontekstia käsin. Korjaa se lähteessä ja anna muutoksen virrata.
Ja sillä on eniten väliä, kun tiedot muuttuvat. Jos jakelukeskus siirtyy tänään toiselle alueelle, pitäisikö viime kuun toimitusten näyttää uusi alue? Ehkä. Ehkä ei. Historiaa varten saatan tarvita alueen, joka oli voimassa toimituksen hetkellä. Se ei ole enää synkronointiongelma. Se on liiketoimintapäätös.
Siksi denormalisoinnin ei pitäisi koskaan tapahtua vahingossa. Jokainen monistettu tieto herättää kysymyksiä omistajuudesta, synkronoinnista, historiasta ja luottamuksesta. Se on luvun 1 kompromissiajattelua: tiedä, mitä ostat (helpomman näytön, yksinkertaisemman raportin, paremman kontekstin tekoälylle) ja mitä maksat (monistetut tiedot, synkronointi, monimutkaisempi totuuden omistajuus). Ja koska aloitimme puhtaasta loogisesta mallista, voimme osoittaa jokaista kopiota ja sanoa: ”Tiedän, että tämä kuuluu tuonne. Laitan sen esityksen tänne tämän vaatimuksen takia.” Se on päätös, jonka voimme arvioida, kyseenalaistaa ja kirjata ylös, jotta seuraava arkkitehti tietää miksi.
Mitä arkkitehti tässä päättää
Osio nimeltä “Mitä arkkitehti tässä päättää ”Kun harkitsen denormalisointia, päätän:
- Missä kunkin liiketoimintatiedon auktoritatiivinen lähde asuu.
- Aiheuttaako puhdas malli todellisia ongelmia käyttäjille, raportoinnille, mittakaavalle tai suorituskyvylle.
- Onko yksinkertaisempi esitys monistamisen arvoinen ja miten kopio pysyy luotettavana.
- Pitäisikö historiallisten arvojen muuttua, kun nykyinen lähde muuttuu.
- Tarvitseeko analytiikka tai tekoäly tiedoista eri muodon kuin operatiivinen järjestelmä.
Lähtökohta ei koskaan muutu: tiedä, mihin totuus kuuluu. Sitten, kun vaatimukset sen oikeuttavat, muotoile se toimitusta varten.
Seuraavaksi Salesforce palaa kuvaan. Muutamme suunnittelemamme fyysiseksi tietomalliksi.
Lue lisää
Osio nimeltä “Lue lisää ”- Build Powerful Reports with Custom Report Types (opens in a new tab), Salesforce Admins, 24.6.2019 (englanniksi, tarkistettu 2026-10-12): mukautettu raporttityyppi ”can span up to 4 object relationships” eli voi kattaa enintään neljä objektisuhdetta.
- Unleash the hounds, terriers and lapdogs: American Kennel Club recognizes 3 more breeds (opens in a new tab), PBS NewsHour, 2.1.2026 (englanniksi, tarkistettu 2026-10-12): AKC tunnustaa 205 rotua, mukaan lukien kolme uutta tulokasta.
- Huvin vuoksi: FCI Breeds Nomenclature (opens in a new tab), Fédération Cynologique Internationale (englanniksi, tarkistettu 2026-10-12): kansainvälisen kattojärjestön rotuluettelo kymmenessä ryhmässä. Selaa sitä, niin näet, miksi rotu ansaitsi oman taulunsa.