Ajattele kuin tietoarkkitehti
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)
Luvun 1 opiskeluopas Data Architect -kurssilla. Lue ensin seitsemän moduulia; tämä sivu auttaa sinua tarkistamaan, mikä jäi mieleen.
Tästä opiskeluoppaasta. Se on koottu pelkästään tämän kurssin omasta sisällöstä ja Salesforcen julkaiseman koeoppaan tavoiteluettelosta. Se ei koskaan perustu oikeisiin koekysymyksiin, eikä se väitä tietävänsä, mitä kokeessa on. Jos olet suorittanut kokeen, älä lähetä minulle sen kysymyksiä: sertifiointisopimus kieltää niiden jakamisen, ja vastausten opetteleminen ulkoa on joka tapauksessa väärä tapa tulla arkkitehdiksi.
Tässä luvussa on vähemmän koetietoa, ja se on tarkoituksellista. Luku kertoo siitä, miten arkkitehti ajattelee, eikä mikään kokeen tavoite kuulu pelkästään sille. Mutta koe rakentuu skenaarioista: liiketoiminta, joitakin lukuja, rajoite ja useita vastauksia, jotka voisivat toimia. Tämän luvun tavoilla luet nuo skenaariot. Siksi alla oleva tarkistuslista kertoo, mitä tavoitetta kukin kohta tukee, eikä väitä, että sitä testataan suoraan.
Koetta varten
Osio nimeltä “Koetta varten ”Rastita ne sitä mukaa kuin etenet. Jokainen kohta linkittää paikkaan, jossa asia opetetaan.
Skenaarion lukeminen kuin arkkitehti (tukee jokaista tavoitetta)
- Erotan todellisen vaatimuksen suunnitelmasta, jossa se saapui (”tarvitsemme kentät Hyväksyjä 2 ja Hyväksyjä 3” vastaan ”meidän täytyy seurata jokaista hyväksyntää”). (Älä vain ota vaatimusta vastaan)
- Etsin epäsuorat vaatimukset, joita kukaan ei sanonut: omistajuus, tuoreus, virheet, säilytys, pääsy. (Etsi epäsuorat vaatimukset)
- Laitan siihen luvut: volyymi päivässä, vuodessa, kasvun kanssa, ja huomaan, kun yksi nolla lisää muuttaa vastauksen. (Tunne lukusi)
- Useiden toimivien vastausten joukosta vertaan, mitä kukin antaa ja mistä se luopuu, suhteessa annettuihin vaatimuksiin ja rajoitteisiin. (Tiedä, mistä luovut, Rajoitteet muuttavat vastauksen)
- Pidän kustannuksia, lisensointia ja rajoja osana sitä, sopiiko työkalu, en jälkiajatuksena. (Yhdeksän kysymystä)
Tietomalli (tukee tavoitetta DM-1)
- Osaan arvioida mallia sen perusteella, kantaako se liiketoimintaa, pystyykö se kasvamaan sen mukana ja suoriutuuko se. (Kanna. Kasva. Suoriudu.)
- Tunnistan mallin, joka on liian litteä (Kenttä 1, Kenttä 2, Kenttä 3), ylinormalisoitu tai rakennettu väärän vakio-objektin varaan. (Liian litteä, liian monimutkainen tai yksinkertaisesti väärä)
- Tiedän, miksi valintaluettelo sopii lyhyelle, vakaalle listalle ja lookup listalle, joka kasvaa jatkuvasti tai saapuu integraatiosta. (Monta tapaa ratkaista ongelma)
- Tiedän, että avain, jolla on merkitys (esimerkiksi osa nimestä), hajoaa, kun se merkitys muuttuu. (Joitakin päätöksiä on halpa muuttaa)
Olemassa olevan muuttaminen (tukee tavoitteita DM-1 ja SDM-2)
- Tiedän, miksi kentän tyypin muuttaminen tai olemassa olevan kentän tekeminen Required-kentäksi (pakollinen) voi rikkoa asioita myöhemmin, ja miksi alusta estää tyyppimuutoksen, kun koodi tai Flow’t viittaavat kenttään. (Ole varovainen luurankoa muuttaessasi)
- Tunnen periaatteen lisää, älä muuta; poista käytöstä, älä yllätä, ja tiedän, että Field Usage voi merkitä kentän käytöstä poistettavaksi ehdokkaaksi. (Ole varovainen luurankoa muuttaessasi)
- Tunnen peruttavuustestin taustalla olevat master-detail-tosiasiat: detail-tietueen pääsy ja omistajuus seuraavat master-tietuetta, master-tietueen poistaminen poistaa sen detail-tietueet, koontikentät vaativat master-detail-suhteen, ja lookup-suhde muuttuu master-detail-suhteeksi vain, kun jokaisessa tietueessa on arvo. (Peruttavuustesti, Lue lisää)
Lisenssit ja jakaminen (tukee tavoitetta SDM-1)
- Tiedän, että suuren volyymin yhteisökäyttäjillä (muun muassa Customer Community) ei ole rooleja eivätkä he käytä jakamismallia, joten pääsy tulee jakamisjoukoista ja jakamisryhmistä, eikä Apex-jakaminen ulotu heihin. (Esimerkki käytännössä: Apex-jakaminen)
Virheet (tukee tavoitetta MIG-1 ja integraatiolukuja)
- Tiedän, että ”työ valmis” ei ole sama asia kuin tiedot ovat oikein, ja miten täsmäytys löytää tietueet, jotka eivät menneet perille. (Osittainen onnistuminen on silti virhe, joka sinun on ymmärrettävä)
Kokeen jälkeen
Osio nimeltä “Kokeen jälkeen ”Koe on lattia, ei katto. Nämä ovat tämän luvun tapoja, joita arkkitehti tarvitsee, kysyttiinpä niistä koskaan tai ei.
- Jonkun täytyy pitää piirustuksia kädessään. Arkkitehtuuri on hyvien päätösten tekemistä puutteellisin tiedoin ja niiden seurausten tuntemista.
- Tietomalli on luuranko. Kaikki muu rakennetaan sen varaan.
- Peruttavuustesti: kuinka vaikeaa tämä on perua, ja kuinka paljon siitä tulee riippumaan?
- Arkkitehtuuri luo painovoimaa. Riippuvuudet tekevät muutoksesta kallista, ei muutos itse.
- Mieti vaikutusaluetta Salesforcen sisällä ja koko yrityksessä. Arkkitehtuuri on kaksisuuntaista liikennettä.
- Kirjoita perustelut ylös: konteksti, vaihtoehdot, päätös, seuraukset, omistaja, tarkastelu. Korvaa uudella; älä pyyhi.
- Paras missä? Epäoptimaalinen päätös voi olla osa optimaalista arkkitehtuuria, jos tiedät tekeväsi sen.
- Kanna mukanasi kuvaa optimaalisesta, jotta tiedät, mihin suuntaan siirryt siitä poispäin ja miksi.
- Think Correct. Think Fast. Nopeus tulee ajattelusta, joka on tehty ennen h-hetkeä.
- Rakenna tätä päivää varten. Suunnittele huomista varten. Suunnittele virheitä varten. Ja käytä 30 %:n kasvua, kun kukaan ei anna sinulle lukua.
- Opettele yhdeksän kysymystä, ei vain vastauksia.
- Tekoäly on rakettibuusteri. Generointi ei ole harkintaa, peruuttamaton on yhä peruuttamaton, eikä ihmisen tekemä arviointi ole seremonia. Luota, mutta tarkista.
Tärkeät termit
Osio nimeltä “Tärkeät termit ”| Termi | Yhdellä rivillä |
|---|---|
| Arkkitehtuurinen päätös | Päätös, joka on vaikea perua ja josta riippuu paljon |
| Peruttavuustesti | Kuinka vaikeaa tämä on perua, ja kuinka paljon siitä tulee riippumaan? |
| Painovoima | Riippuvuudet, jotka kertyvät päätöksen ympärille ajan myötä |
| Vaikutusalue (blast radius) | Kaikki muu, mikä liikkuu, kun päätös muuttuu |
| Päätöskirjaus | Konteksti, vaihtoehdot, päätös, seuraukset, omistaja ja tarkastelukohta, pidettynä pienenä |
| Kompromissi | Mitä vaihtoehto antaa ja mistä se luopuu saadakseen sen |
| Epäsuora vaatimus | Jotain, mitä liiketoiminta odottaa pyytämättä, kuten palautumista, kun lataus epäonnistuu |
| Steven ”nollien määrä” | Yksi nolla lisää volyymissa voi muuttaa koko arkkitehtuurin |
| Täsmäytys | Sen vertaaminen tietue tietueelta, minkä olisi pitänyt tapahtua ja mitä tapahtui |
| Käytöstä poistaminen | Jonkin merkitseminen poistuvaksi ja sen hallittu poistaminen sen sijaan, että sitä muutettaisiin paikallaan |
| Suuren volyymin käyttäjä | Yhteisökäyttäjä (lisensseistä muun muassa Customer Community) ilman roolia, jakamismallin ulkopuolella |
| Skeeman rönsyily | Objektit ja kentät, joita kertyy, koska niiden luominen oli halpaa, kunnes kukaan ei enää suunnitellut mallia |
Testaa itsesi
Osio nimeltä “Testaa itsesi ”Lyhyitä skenaarioita kurssin tyyliin. Päätä vastauksesi ennen kuin avaat sen.
1. Myyntitiimi pyytää myyntimahdollisuudelle (Opportunity) kenttiä Hyväksyjä 2 ja Hyväksyjä 3, kummallekin oma päivämäärä. Mitä kysyt, ja mitä saattaisit rakentaa?
Kysy miksi ja kuinka monta hyväksyntää voi olla. Jos niitä voi olla enemmän kuin kaksi tai kolme, vaatimus on seurata jokaista hyväksyntää, ei lisätä kenttiä: lapsiobjekti, yksi tietue hyväksyntää kohden. Lue uudelleen Älä vain ota vaatimusta vastaan.
2. Joku haluaa muuttaa kentän otsikon, ja joku toinen haluaa muuttaa sen asiakastunnisteen muotoa, jonka viisi järjestelmää jo tallentaa. Kumpi ansaitsee enemmän huomiotasi, ja miksi?
Tunniste. Otsikkoa on halpa muuttaa. Tunniste ei läpäise peruttavuustestiä: vaikea perua, ja siitä riippuu jo paljon. Käytä huomiota suhteessa erehtymisen hintaan. Lue uudelleen Joitakin päätöksiä on halpa muuttaa.
3. Tekstikenttä on ollut käytössä vuosia. Liiketoiminta haluaa sen nyt sisältävän numeron. Miten toimit?
Älä muuta sitä paikallaan. Selvitä, mikä siitä riippuu (Flow’t, Apex, raportit, integraatiot, agentit) ja mitä vanhoille tiedoille tapahtuu. Yleensä: lisää uusi kenttä, migroi harkiten ja poista vanha käytöstä vaiheittain. Lue uudelleen Ole varovainen luurankoa muuttaessasi.
4. 1 200 toimipaikkaa, 100 ajanvarausta toimipaikkaa kohden päivässä, noin 305 päivää vuodessa, kaksi tietuetta ajanvarausta kohden, viiden vuoden säilytys, 30 %:n kasvu. Suunnilleen montako tietuetta, ja miksi sillä on merkitystä?
Noin 73 miljoonaa tietuetta ensimmäisenä vuonna (36,6 miljoonaa ajanvarausta, kaksi tietuetta kustakin) ja yli 650 miljoonaa viidessä vuodessa kasvun kanssa. Sama ominaisuus, pari nollaa lisää, aivan erilainen arkkitehtuuri. Lue uudelleen Tunne lukusi.
5. Yöllinen lataus ilmoittaa miljoonan tietueen kohdalla ”valmis”. Mistä tiedät, että se toimi?
Täsmäytät. Vastaanottava osapuoli kuittaa jokaisen tallentamansa tietueen; lähettäjä vertaa lähettämäänsä siihen, mitä kuitattiin. Puuttuvat kuittaukset tarkoittavat, ettei se toiminut, sanoi työn tila mitä tahansa, ja kertovat, mitkä tietueet yrittää uudelleen, ohjata ihmiselle tai mistä nostaa hälytys. Lue uudelleen Osittainen onnistuminen on silti virhe, joka sinun on ymmärrettävä.
6. 15 miljoonan Customer Community -käyttäjän yhteisö tarvitsee monimutkaista pääsyä tietueisiin. Joku ehdottaa Apex-jakamista. Mikä on ongelma?
He ovat suuren volyymin käyttäjiä: ei rooleja, jakamismallin ulkopuolella, joten Apexilla ei ole kirjoitettavaa jakamistietuetta. Pääsy tulee jakamisjoukoista ja jakamisryhmistä. Lisenssi ratkaisi, mitkä jakamistyökalut ovat olemassa. Lue uudelleen Esimerkki käytännössä: Apex-jakaminen.
7. Tekoälytyökalu luo uudelle sovellukselle kaksikymmentä objektia minuuteissa. Mikä on nyt arkkitehdin tehtävä?
Päättää, pitäisikö meillä olla viisi. Ymmärtää malli niin hyvin, että pystyy puolustamaan sitä: miksi nämä objektit ja suhteet, missä avaimet ja perustiedot ovat, mitä tapahtuu suuressa mittakaavassa. Tarkistaa tosiasiat, joihin se nojasi. Generointi ei ole harkintaa. Lue uudelleen Halpa toteutus siirtää arvon.
Lue lisää
Osio nimeltä “Lue lisää ”- Salesforce Certified Platform Data Architect Exam Guide (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-09-25): virallinen luettelo tavoitteista ja niiden painoarvoista. Tarkista aina ajantasainen versio ennen kuin varaat kokeen.