Tietomalli on luuranko
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 2/7 luvussa Ajattele kuin tietoarkkitehti, Data Architect -kurssin luku 1. Jokainen moduuli on itsenäinen. Edellinen: Ajattele kuin arkkitehti · Seuraava: Peruttavuustesti
Kysymys, johon tämä moduuli vastaa: Miksi tietomalli on tärkeämpi kuin mikään sen päälle rakennettu, ja miten sitä arvioidaan?
Kun opetan tietoarkkitehtuuria, palaan yhä uudelleen yhteen lauseeseen: tietomalli on luuranko.
Tietomalli on järjestelmän luuranko. Kaikki muu rakennetaan sen ympärille, ja se pitää muun kehon koossa. Luita ei näe, kun katsoo ihmistä, mutta ne ratkaisevat, kuinka pitkä hän on, miten hän liikkuu ja mitä hän jaksaa kantaa.
Mieti kaikkea, mitä rakennamme Salesforce-toteutuksessa. Rakennamme automaatiota tietomallin ympärille. Kirjoitamme Apexia sitä vasten ja Flow’ta, jotka lukevat ja päivittävät sitä. Rakennamme integraatioita, jotka lähettävät tietoja sinne ja hakevat tietoja sieltä. Luomme sen päälle raportteja ja analytiikkaa, ja suunnittelemme tietoturvan sen ympärille. Ja yhä useammin rakennamme tekoälyagentteja, joiden täytyy ymmärtää noita tietoja ja toimia niiden perusteella. Kaikki tämä riippuu alla olevasta rakenteesta.
Siksi on niin tärkeää saada tietomalli oikein ajoissa. Luurankoa voi muuttaa myöhemminkin. Mutta se todennäköisesti sattuu.
Aloita liiketoiminnasta
Osio nimeltä “Aloita liiketoiminnasta ”Hyvä tietomalli alkaa yksinkertaisesta kysymyksestä: mitä liiketoiminnan oikeasti täytyy kuvata? Ei ”mitä Salesforce-objekteja meillä on?” Eikä todellakaan ”mitä pystyn rakentamaan nopeasti?”
Yritämme ensin ymmärtää liiketoiminnan. Mitkä ovat tämän liiketoiminnan tärkeät asiat? Miten ne liittyvät toisiinsa? Kuka ne omistaa? Miten ne muuttuvat ajan myötä? Mitä täytyy muistaa, ja mikä on yhteistä eri liiketoimintaprosesseille? Vasta kun ymmärrämme nämä asiat, meidän kannattaa alkaa kääntää niitä objekteiksi, kentiksi ja suhteiksi.
Tämä kuulostaa itsestään selvältä. Käytännössä sen tekee hyvin helposti väärinpäin. Joku tunnistaa jotain, joka näyttää myyntimahdollisuudelta (Opportunity), tapaukselta (Case) tai omaisuuserältä (Asset), ja alkaa heti suunnitella sen ympärille. Joskus se on juuri oikein. Joskus yritämme sovittaa neliskanttista palikkaa pyöreään reikään, ja kun sen päätöksen ympärille on rakennettu tarpeeksi, palikan saaminen pois tulee hyvin kalliiksi.
Tässä kysymys, jonka kuulen jatkuvasti. Asiakkaan liiketoiminnalla voi olla monta toimituspaikkaa. Pitäisikö jokaisen paikan olla tili (Account) vai mukautettu objekti? Ennen kuin vastaat, huomaa, mitä sinun pitäisi tietää ensin: mitä paikka tarkoittaa tälle liiketoiminnalle ja mitä sille tapahtuu. Se on liiketoiminnan mallintamista ennen objekteja. (Annan oman vastaukseni luvussa 3.)
Kanna. Kasva. Suoriudu.
Osio nimeltä “Kanna. Kasva. Suoriudu. ”Kun katson tietomallia, haluan sen läpäisevän kolme testiä: kanna liiketoimintaa, kasva liiketoiminnan mukana ja suoriudu.
Kanna. Mallin täytyy kantaa sitä, mitä liiketoiminta oikeasti yrittää saavuttaa. On suuri ero mallilla, joka teknisesti pystyy tallentamaan tiedot, ja mallilla, joka oikeasti kuvaa liiketoimintaa hyvin. Jos lisään jatkuvasti outoja kenttiä, erikoislippuja, monimutkaista automaatiota ja poikkeuksia, koska malli ei aivan sovi, alan kysyä, onko ongelma todella automaatiossa. Ehkä malli on väärä. Hyvän mallin pitäisi tehdä liiketoiminnasta helpompi ymmärtää, ei vaikeampi.
Kasva. Kun sanon kasva, en tarkoita pelkästään lisää tietueita. Volyymilla on merkitystä: kymmenentuhatta tietuetta ja sata miljoonaa luovat hyvin erilaisia ongelmia. Mutta liiketoiminta kasvaa myös monimutkaisuudeltaan. Se lisää tuotteita, menee uusille markkinoille, ostaa yrityksiä, muuttaa prosesseja, lisää kanavia ja kytkee uusia järjestelmiä. Se huomaa, että jokin, minkä se luuli olevan yksi asia, onkin oikeasti viisi eri asiaa. Malli, joka toimii tänään kauniisti, voi muuttua ansaksi, jos huomiselle ei ole tilaa. Siksi suosin suunnitelmia, jotka kasvavat lisäämällä, enkä suunnitelmia, jotka muuttavat jatkuvasti jo olemassa olevaa. Uuden lisääminen on yleensä helpompaa kuin sellaisen määritteleminen uudelleen, josta kymmenet muut asiat riippuvat.
Suoriudu. Tiedot eivät vain lepää paikallaan. Kirjoitamme niitä, etsimme niitä, teemme niihin kyselyjä, jaamme niitä, raportoimme niistä ja integroimme niitä, ja yhä useammin tekoälyjärjestelmät hakevat niitä kontekstiksi ennen kuin toimivat. Malli voi näyttää kauniilta kaaviossa ja silti olla kamala käyttää. Siksi suunnittelemme sekä sen mukaan, miten tiedot tallennetaan, että sen mukaan, miten tietoja käytetään.
Ja sen täytyy suoriutua jatkossakin. Sen täytyy suoriutua suuressa mittakaavassa: kun käyttäjien määrä kasvaa, kun tietojen määrä kasvaa, todellisissa olosuhteissa ja huippujen aikana, vuoden kiireisimpänä päivänä eikä keskimääräisenä päivänä. Ja sen täytyy suoriutua silloinkin, kun jotain odottamatonta tapahtuu.
Kanna. Kasva. Suoriudu. Palaamme näihin kolmeen testiin koko kurssin ajan.
Liian litteä, liian monimutkainen tai yksinkertaisesti väärä
Osio nimeltä “Liian litteä, liian monimutkainen tai yksinkertaisesti väärä ”Olen nähnyt tietomallien menevän pieleen kolmella tavalla.
Ensimmäinen on väärän asian valitseminen alun perin. Käytämme vakio-objektia, koska se näyttää riittävän läheiseltä, ja käytämme sitten vuosia poikkeusten lisäämiseen, koska se ei koskaan sopinut oikein. Se on se neliskanttinen palikka.
Toinen on mallin tekeminen liian litteäksi. Kaikki menee yhteen objektiin, ja aluksi se tuntuu ihanan yksinkertaiselta. Sitten liiketoiminta kasvaa, ja huomaamme, että joillakin noista asioista on oma elinkaarensa, niitä voi olla useita, ne tarvitsevat oman tietoturvansa tai niillä on omia suhteitaan. Yhtäkkiä kuvaamme yksi-moneen-suhdetta kentillä Kenttä 1, Kenttä 2 ja Kenttä 3 tai yhä monimutkaisemmilla lipuilla ja automaatiolla. Malli ei jättänyt meille kasvuvaraa.
Kolmas on päinvastainen virhe: ylinormalisoimme. Luomme elegantin kaavion, jossa on objekti objektin perään ja jokainen käsite on täydellisesti erotettu. Teknisesti kaunis, käytännössä kurja. Käyttäjien on vaikea ymmärtää sitä, ja sivuasettelut ja Lightning-sivut, joissa on liittyvä luettelo toisensa perään, voivat alkaa tuntua loputtoman syviltä. Kyselyt monimutkaistuvat, automaatio kulkee useamman suhteen yli, raportointi vaikeutuu ja alusta tekee enemmän työtä vastatakseen tavallisiin liiketoiminnan kysymyksiin.
Kumpi siis on oikein, litteä vai normalisoitu? Kaavaa ei ole. Pidät päässäsi kuvaa optimaalisesta mallista ja ymmärrät kompromissit, kun siirryt siitä poispäin. Se on arkkitehtuurin taitoa, ja palaamme siihen moduulissa 4 ja seuraavassa luvussa, jossa opimme mallintamaan. Toistaiseksi tunnista, että rakenne itsessään on arkkitehtuurinen päätös.
Ole varovainen luurankoa muuttaessasi
Osio nimeltä “Ole varovainen luurankoa muuttaessasi ”Kun järjestelmä on käytössä, minusta tulee hyvin varovainen tietomallin perustavien muutosten suhteen.
Oletetaan, että tekstikenttä on ollut olemassa vuosia, ja joku sanoo: ”Emme oikeastaan käytä sitä enää niin. Muutetaan se numeroksi.” Se kuulostaa kenttämuutokselta. Mutta mikä riippuu siitä kentästä? Flow’t, Apex, raportit, integraatiot, tietoputket, ulkoiset sovellukset, tekoälyagentit. Ja mitä historiatiedoille tapahtuu? Alusta itse ei anna muuttaa kentän tyyppiä, kun koodi tai Flow’t vielä viittaavat siihen, mikä kertoo, kuinka laajalle muutos ulottuu.
Joskus oikea vastaus ei ole muuttaa sitä, mikä on jo olemassa. Muutoksen vakavuudesta riippuen luon mieluummin jotain uutta, migroin harkiten ja poistan vanhan rakenteen käytöstä vaiheittain:
Lisää, älä muuta. Poista käytöstä, älä yllätä.
Salesforce antaa jopa tavan sanoa tämä metatiedoissa: kentän Field Usage (kentän käyttö) -arvoksi voi asettaa DeprecateCandidate, ”suunniteltu poistettavaksi käytöstä eikä enää käytössä”. Se merkitsee kentän kaikille, jotka lukevat objektia; se ei piilota kenttää, joten sen poistaminen on edelleen päätös, joka sinun pitää toteuttaa.
Sillä kun arkkitehtuurin muut osat riippuvat jostakin, sen merkityksen muuttaminen voi olla paljon vaarallisempaa kuin sen nimen muuttaminen. Pahin versio on kenttä, jonka nimi pysyy samana, kun sen sisältö muuttuu: kaikki sen jälkeen tuleva luottaa yhä nimeen.
Jopa niin yksinkertainen asia kuin kentän Required (pakollinen) -valintaruudun rastittaminen voi muuttua aikapommiksi. Jos olet jo kerännyt tietoja, joissakin tietueissa kenttä on tyhjä. Sitten päiviä, viikkoja tai kuukausia myöhemmin joku päivittää jonkin noista tietueista, ja tallennus epäonnistuu pakollisen kentän takia, eikä kenelläkään ole sitä arvoa. Yksinkertaisella muutoksella, kuten kentän merkitsemisellä pakolliseksi, voi olla tahattomia ja viivästyneitä seurauksia. Palaamme Required-asetukseen ja siihen, milloin arvo oikeasti tiedetään, luvussa 3.
Kokeen jälkeen: tekoälykin rakentaa luurangon päälle. Pyydä tekoälytyökalua rakentamaan sovellus, niin se luo objektit, kentät, Flow’t, Apexin, komponentit ja testit minuuteissa. Jos alkuperäinen tietomalli oli väärä, emme ole välttäneet huonon päätöksen seurauksia; olemme nopeuttaneet niitä, koska jokainen luotu kerros on yksi asia lisää, joka riippuu siitä rakenteesta. Siksi haluan, että ihmisarkkitehti arvioi tekoälyn luoman tietomallin, ymmärtää sen ja vastaa siitä. Moduuli 7 vie tätä pidemmälle.
Luuranko tulee ensin
Osio nimeltä “Luuranko tulee ensin ”Kurssin edetessä puhumme paljosta teknologiasta: objekteista ja suhteista, suurista tietomääristä, kyselyistä, integraatiosta, migraatiosta, transaktioista, tietoturvasta, Data 360:sta ja tekoälystä. Kaiken sen alla on tietomalli.
Jos malli kantaa liiketoimintaa, pystyy kasvamaan liiketoiminnan mukana ja suoriutuu niissä käyttötavoissa, joilla tietoja aiomme käyttää, olemme rakentaneet vahvan perustan. Jos perusta on väärä, kaikki sen jälkeen vaikeutuu.
Tietomalli on luuranko. Arkkitehtien pitäisi olla hyvin huolellisia, kun he suunnittelevat luurankoa. Olemassa olevien rakenteiden muuttamisella voi olla ketjuuntuvia seurauksia.
Mitä arkkitehti tässä päättää
Osio nimeltä “Mitä arkkitehti tässä päättää ”- Kantaako malli liiketoimintaa, pystyykö se kasvamaan sen mukana ja suoriutuuko se niissä käyttötavoissa, joilla tietoja käytetään.
- Sopiiko käsite vakio-objektiin vai onko se neliskanttinen palikka.
- Kuinka litteä tai kuinka normalisoitu mallista tehdään, ja miksi.
- Pitäisikö luurankoon tehtävän muutoksen olla lisäys, migraatio tai käytöstä poistaminen eikä muutos paikallaan.
Lue lisää
Osio nimeltä “Lue lisää ”- Considerations for Converting the Field Type of a Custom Field (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-10-02; tarkistettu uudelleen 2026-10-12): mitkä tyyppimuutokset voivat hävittää tietoja ja miksi et voi muuttaa sellaisen kentän tyyppiä, johon Apex, Flow’t tai prosessit viittaavat.
- Data Classification Metadata Fields (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-10-02; tarkistettu uudelleen 2026-10-12): Field Usage -arvot (Active, DeprecateCandidate, Hidden) ja muut luokittelukentät.