Muuta malli Salesforceksi

🌐 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)

Kuva on luotu tekoälyllä

Tekoälyn kääntämä. Yhteisö ei ole vielä tarkistanut käännöstä. Lue englanniksi

Moduuli 6/6 luvussa Tietojen mallintaminen merkityksen kautta, Data Architect -kurssin luku 2. Jokainen moduuli on itsenäinen. Edellinen: Suunnittele kolmanteen normaalimuotoon ja peräänny sitten · Seuraava: luvun opiskeluopas, sitten seuraava luku: Salesforcen tietoarkkitehtuuri

Kysymys, johon tämä moduuli vastaa: Miten loogisesta tietomallista tulee fyysinen Salesforce-tietomalli?

Vihdoin puhumme Salesforcesta. Jos olet vastustanut halua muuttaa jokainen laatikko objektiksi, nyt saat tehdä sen. Mutta huomaa, missä järjestyksessä tulimme: ymmärsimme liiketoiminnan, kuvasimme tiedot, sijoitimme kunkin tiedon sinne, minne se kuuluu, ja päätimme, missä joustamme siitä tarkoituksella. Vasta nyt kysyn, miten Salesforcen pitäisi toteuttaa se. Sen etenemisen haluan sinun muistavan: käsitteellinen → looginen → fyysinen. Käsitteellinen malli kuvaa liiketoimintaa. Looginen malli kuvaa tietoja. Fyysinen malli kuvaa, miten oikeasti rakennamme sen.

Istu, paikka, mallinna

Fyysisen vaiheen näkee helpoimmin jostain pienestä, joten lemmikit menevät ensin.

Keitä ovat yritykset ja ihmiset? Kasvattaja on yritys, joten siitä tulee tili (Account), jonka tietuetyyppi on Kasvattaja. Omistaja on myös tili, tai henkilötili, jonka tietuetyyppi on Omistaja. Kaksi saman vakio-objektin lajia rinnakkain kaavion yläosassa, juuri siellä, missä ne ovat olleet moduulista 1 asti.

Millä ei ole vakiokotia? Lemmikistä, rodusta, tempusta, lemmikin tempusta ja tempun arvioinnista tulee mukautettuja objekteja. Ja muistatko lajin, jonka kopioimme lemmikille moduulissa 5? Tässä se saa tehtävänsä: siitä tulee lemmikin tietuetyyppi, koira tai kissa. Yksi objekti kahdella tietuetyypillä, kummallakin oma sivuasettelunsa ja valintaluettelon arvonsa, koiraobjektin ja kissaobjektin sijaan.

Mitkä suhteet ovat master-detail-suhteita? Käytän master-detailia vain silloin, kun alitietuetta ei koskaan siirretä toiselle päätietueelle. Lemmikin temppu kuuluu lemmikilleen koko elämän, ja jokainen tempun arviointi kuuluu lemmikin tempulleen, joten molemmat ovat master-detail-suhteita. Se kannattaa heti: master-detail on se, mikä antaa lemmikin pitää koontikentän (roll-up summary) lemmikin tempuistaan, joten moduulin 5 osatut temput -laskuri pysyy tahdissa itsestään. Lemmikit kuitenkin vaihtavat kotia, joten omistaja on lookup.

Mitkä ovat lookupeja? Salesforce ei suosittele yli 10 000 alitietuetta yhdelle päätietueelle. Suosittu temppu kuten Istu, yleinen rotu tai iso kasvattaja voisi ylittää sen helposti, joten lemmikin temppu osoittaa temppuunsa lookupilla, ja lemmikki osoittaa rotuunsa ja kasvattajaansa samalla tavalla. Ja vältä polymorfisia suhteita aina kun voit, sellaisia, joissa yksi kenttä voi osoittaa useaan objektityyppiin. Ne ovat käteviä ensimmäisenä päivänä ja hankalampia kaikelle, minkä täytyy lukea niitä myöhemmin: raporteille, integraatioille ja nyt agenteille.

Mikä jää alustan ulkopuolelle? Jos lemmikillä on GPS-panta, joka ilmoittaa sen sijainnin, sitä sijaintia ei tarvitse kopioida sisään lainkaan. Se voi olla ulkoinen objekti, joka luetaan suoraan pannan seurantajärjestelmästä.

Click to enlarge

Jokainen kaavion päätös palautuu johonkin, mitä päätimme aiemmin, ja juuri se on tarkoitus. Nyt sama vaihe Steve Truckingille.

Aloita loogisesta mallista

Steve Truckingin loogisessa mallissa on nyt vähittäiskauppakumppani, jakelukeskus, kuormaluettelo, toimitus, toimitusrivi, vastaanottaja, reitti, pysähdys, tiimi, kuorma-auto ja tiimin osoitus. Ne ovat liiketoimintakäsitteitä, ja nyt voin alkaa kohdistaa niitä Salesforceen.

Vähittäiskauppakumppani voisi olla tili. Toimitus voisi vastata jotain, mitä Salesforcessa jo on aikataulutettua kenttätyötä varten, tai siitä voisi tulla mukautettu objekti. Kuormaluettelolle ei ole sopivaa vakio-objektia, joten siitä tulee todennäköisesti mukautettu. Ja vastaanottaja on aidosti vaikea kysymys: henkilötili, yhteyshenkilö vai pelkkiä tietoja toimituksessa? Vastaamme siihen kunnolla seuraavassa luvussa.

Tärkeä sana on yhä voisi. Älä oleta toteutusta vain siksi, että liiketoimintakäsite kuulostaa Salesforce-objektilta. Siksi rakensimme ensin loogisen mallin: se antaa meille jotain, mitä vasten Salesforce-suunnitelmaa voi testata.

Liiketoimintaentiteetti ei automaattisesti tarkoita mukautettua objektia

Tässä on ansa, jota haluan ylläpitäjien välttävän: ”Tunnistimme yksitoista entiteettiä, joten tarvitsemme yksitoista mukautettua objektia.” Ei. Looginen entiteetti kertoo meille, että liiketoimintakäsitteellä on merkitystä. Se ei sanele, miten Salesforcen täytyy tallentaa se. Käsitteestä voi tulla vakio-objekti, mukautettu objekti, objektien välinen suhde, kenttä tai muutama kenttä, konfiguraatiossa hallittu arvo tai tietoa, joka asuu kokonaan Salesforcen ulkopuolella (Steve Truckingin toimituskuvat ovat hyvä ehdokas siihen). Fyysinen malli on se paikka, jossa nuo valinnat tehdään, ja juuri siksi emme tehneet niitä ensimmäisessä puhelussa.

Attribuuteista tulee fyysisiä kenttiä

Sama siirtymä tapahtuu attribuuteille. Loogisella kuorma-autollamme on yksikkönumero, VIN-tunnus, merkki, malli, vuosimalli, rekisterikilpi ja tila. Nyt päätämme, miten ne ovat fyysisesti olemassa: mikä objekti omistaa ne, mitä kenttätyyppejä ne käyttävät, mitkä ovat pakollisia, minkä täytyy olla yksilöllisiä, mitkä ovat ulkoisia tunnisteita, mitkä tarvitsevat vahvistuksen, mitkä johdetaan tallentamisen sijaan ja mitkä ovat arkaluonteisia. Loogisella tasolla kysyimme, mitä kuorma-auto tarkoittaa. Fyysisellä tasolla kysymme, miten Salesforce esittää kuorma-auton. Eri kysymykset.

Click to enlarge

Suhteista tulee alustapäätöksiä

Kaikki suhteisiin käyttämämme aika kannattaa tässä. Tiedämme jo, onko kukin niistä yhden suhde yhteen, yhden suhde moneen vai monen suhde moneen, pakollinen vai valinnainen, ja onko sen historialla merkitystä. Nyt päätämme, miten Salesforce sen toteuttaa: lookup, master-detail tai Salesforcen liitosobjekti (Salesforce Junction Object), ja ehkä liitos, jolla on omia attribuutteja, koska kuten huomasimme, suhteella itsellään voi olla liiketoiminnallinen merkitys.

Muistele tiimin osoitusta. Olisimme voineet aloittaa tämän luvun sanomalla: ”Luodaan Salesforcen liitosobjekti tiimin ja kuorma-auton väliin.” Katso, minkä olisimme ohittaneet: miksi suhde on olemassa, tarvitseeko se päivämäärän ja reitin, onko sillä tila ja tarvitseeko viikkoja myöhemmin tehty vahinkoilmoitus sen historiaa. Nuo liiketoimintakysymykset kertovat meille, mikä tiimin osoitus on. Vasta sitten meidän pitäisi päättää, miten Salesforce sen rakentaa, ja onko Salesforcessa jo jotain, mikä hoitaa tehtävän.

Piirrä nyt fyysinen malli

Kaavio muuttuu taas. Käsitteellinen malli näytti liiketoimintakäsitteet ja yksinkertaiset viivat. Looginen malli lisäsi attribuutit, avaimet, kardinaliteetin ja suhteisiin piiloutuneet entiteetit. Nyt fyysinen malli alkaa näyttää Salesforcelta: vakio-objektit, mukautetut objektit, kentät, suhdetyypit ja se, mikä asuu alustan ulkopuolella.

Click to enlarge

Haluan, että pystyt laittamaan nuo kolme kaaviota rinnakkain ja näkemään etenemisen: et kolmea toisiinsa liittymätöntä kaaviota, vaan saman liiketoiminnan kolmella tasolla.

Sananen siitä, miten piirrän nämä, koska asettelu on osa viestiä. Laitan pääobjektin keskelle, hieman alas. Jos sillä on päätietueobjekteja, laitan ne hieman yläpuolelle, jotta mallia luetaan ylhäältä alas ja vasemmalta oikealle, samalla tavalla kuin liiketoiminta sitä ajattelee. Viitetiedot menevät sivuun. Väreilläkin on merkitys: teen Salesforcesta aina sinisen, ja valitsen värin yrityksen omille järjestelmille, yleensä vihreän, koska vihreä on mukava ja ystävällinen väri. En käytä punaista, ja keltaiset ovat vähän räikeitä. Kun malli on aseteltu noin, se laulaa minulle. Monet kaaviot, joita löydät, ovat oikeastaan tilanhallintaa: miten saan kaikki autoni pysäköityä ahtaaseen autotalliini? Maalaan mieluummin loogisen kuvan, jonka mieli pystyy hahmottamaan.

Fyysisen mallin täytyy kunnioittaa alustaa

Salesforce ei ole geneerinen relaatiotietokanta. Sillä on mielipiteitä suhteista, omistajuudesta, suojauksesta ja raportoinnista. Sillä on rajoja, kyselykäyttäytymistä ja automaatiota sekä arkkitehtuuri, joka vaikuttaa siihen, miten malli käyttäytyy suuressa mittakaavassa. Valkotaululla täydelliseltä näyttävän loogisen mallin voi siis joutua muuttamaan, kun siitä tulee fyysinen. Se ei ole Salesforcen hankaluutta. Se tarkoittaa, että alustalla on muoto, ja hyvät arkkitehdit ymmärtävät sen muodon. Seuraava luku käsittelee juuri sitä.

Joskus fyysinen malli myös poikkeaa tarkoituksella puhtaasta loogisesta mallista moduulissa 5 tekemiemme denormalisointipäätösten vuoksi. Se on ihan hyvä, kunhan osaamme selittää miksi.

Älä suunnittele Setupista käsin

On tapa, jonka haluan sinun lopettavan, jos sinulla on se: tietoarkkitehtuurin aloittaminen kohdasta Setup → Object Manager → New Custom Object ja mallin keksiminen siinä samalla. Salesforce tekee asioiden luomisesta uskomattoman helppoa; se on yksi sen vahvuuksista ja yksi syistä, miksi heikot tietomallit syntyvät niin nopeasti. Muutama klikkaus, ja sinulla on objekti, muutama lisää, ja sinulla on kentät ja suhde. Sitten tietoa saapuu, flow’ita rakennetaan, raportteja luodaan, integraatiot riippuvat siitä, ja viidessä minuutissa luomasi objektin muuttaminen on hyvin kallista. Se on luvun 1 peruttavuustesti. Joten ennen kuin klikkaat New Custom Object, piirrä malli.

Fyysinen ei tarkoita pysyvää

On toinenkin syy, miksi pidän kolme mallia erillään: teknologia muuttuu. Tänään osa Steve Truckingin tiedoista asuu Salesforce-coressa. Huomenna osa niistä voi asua Data 360:ssa, tietovarastossa tai järjestelmässä, jota emme ole vielä valinneet, ja tekoälyavustaja tarvitsee oman esityksensä. Fyysinen arkkitehtuuri voi muuttua, kun taas liiketoimintakäsitteet pysyvät huomattavan vakaina: vähittäiskauppakumppanit, toimitukset ja vastaanottajat ovat yhä olemassa. Se tekee loogisesta mallista arvokkaan. Se on kestävä kuvaus liiketoiminnasta, joka ei ole sidottu tämänpäiväiseen toteutukseen.

Mitä arkkitehti tässä päättää

Kun muutan loogisen mallin fyysiseksi Salesforce-malliksi, päätän:

• Mitkä liiketoimintaentiteetit vastaavat Salesforcen vakio-ominaisuuksia ja mitkä tarvitsevat mukautettuja objekteja tai muun esitystavan.
• Miten loogisista attribuuteista tulee fyysisiä kenttiä ja miten suhteet toteutetaan alustalla.
• Mihin tarkoituksellinen denormalisointi kuuluu fyysisessä suunnitelmassa.
• Mitkä tiedot kuuluvat Salesforceen ja mitkä jonnekin muualle.
• Mitkä alustan ominaisuudet vaativat fyysistä mallia poikkeamaan loogisesta.

Tärkeintä on, että haluan pystyä jäljittämään jokaisen päätöksen taaksepäin. Jos osoitat jotain fyysisessä mallissani ja kysyt ”Miksi tuo on tuossa?”, minun pitäisi pystyä viemään sinut loogisen ja käsitteellisen mallin kautta takaisin johonkin, mitä liiketoiminta oikeasti tarvitsee: liiketoiminta → käsitteellinen → looginen → fyysinen.

Kokeen jälkeen: mitä tekoäly muuttaa. Tekoäly voi nyt viedä vaatimusdokumentin yhdellä hypyllä aina Salesforce-objekteihin ja -kenttiin asti. Se tekee järjestyksestä tärkeämmän, ei vähemmän tärkeää: jos se hyppää vaatimuksista suoraan konfiguraatioon, pyydä sitä näyttämään, mitä välissä tapahtui: minkä se päätti olevan entiteetti, mitkä avaimet se valitsi, mitä suhteita se oletti ja missä se denormalisoi. Ne ovat arkkitehtuuripäätöksiä, ja arkkitehdin täytyy yhä nähdä ne.

Aloitimme tämän luvun ensimmäisestä puhelusta substantiiveja kuunnellen, ja päätämme sen fyysiseen malliin, jonka voimme jäljittää takaisin liiketoimintaan. Nyt kun olemme päättäneet rakentaa Salesforcen päälle, seuraava kysymys menee syvemmälle: millaisen tietoalustan päälle oikeastaan rakennamme?

Lue lisää

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (opens in a new tab), Salesforce Developers, Winter ‘27 (englanniksi, tarkistettu 2026-10-02): ”configure parent-child relationships with no more than 10,000 children to one parent record” eli enintään 10 000 alitietuetta yhdelle päätietueelle. Ohje data skew’sta, ei ehdoton raja; luku 7 menee syvemmälle.
• Roll-Up Summary Field (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-10-12): koontikenttä (roll-up summary) laskee detail-tietueiden määrän tai summan master-detail-suhteen kautta.