Perustiedot ja identiteetti
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 6 opiskeluopas Data Architect -kurssilla. Lue ensin kuusi moduulia, myös tarkistuspisteen 1 läpikäynti; tämä sivu auttaa sinua tarkistamaan, mitä jäi mieleen.
Tästä opiskeluoppaasta. Se on koottu vain tämän kurssin omasta sisällöstä ja Salesforcen julkaiseman kokeen oppaan 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 ulkoa opettelu on joka tapauksessa väärä tapa tulla arkkitehdiksi.
Tämä luku kattaa kokeen Master Data Management -osion (5 %) sekä yhden näkymän asiakkaaseen Salesforce Data Management -osiosta. Painoltaan osio on pieni, mutta sen ajatukset (auktoriteetti, täsmäytys, säilymissäännöt) näkyvät monen muun skenaarion sisällä. Alustan luvut muuttuvat, joten tarkista ajantasaiset luvut ennen kuin luotat niihin.
Koetta varten
Osio nimeltä “Koetta varten ”Rastita kohdat sitä mukaa kuin etenet. Jokainen linkittää kohtaan, jossa asia opetetaan.
MDM-2: golden record ja totuuden järjestelmä
- Tiedän, että auktoriteetti määrätään attribuuttia kohden, ei tietuetta kohden: yhdellä tilillä voi olla ERP:ssä hallittuja ja Salesforcessa hallittuja kenttiä. (Totuus kuuluu attribuutille)
- Kysyn, missä kukin attribuutti luodaan, missä sitä muokataan ja missä siihen viitataan, sekä sen muutoksen viiveen. (Luotu, muokattu, viitattu ja kuinka nopeasti?)
- Osaan rakentaa auktoriteettikartan, ja tiedän, etteivät liiketoiminnan omistaja ja auktoritatiivinen järjestelmä ole sama asia. (Rakenna auktoriteettikartta)
- Tiedän, että auktoriteetti voi muuttua elinkaaren aikana (Salesforcen prospektista tulee ERP:n hallitsema asiakas), ja että kopio ei ole auktoriteetti. (Auktoriteetti muuttuu elinkaaren aikana, Kopio ei ole auktoriteetti)
MDM-1: MDM-tekniikat
- Koetieto: Tunnen neljä MDM:n toteutustyyliä, rekisterin, konsolidoinnin, rinnakkaiselon ja keskitetyn: mitä kukin keskittää ja työntääkö se arvoja takaisin. (Neljä mallia rinnakkain)
- Osaan erottaa neljä MDM-tyyliä toisistaan: rekisteri, konsolidointi, rinnakkaiselo ja keskitetty, ja valita keveimmän, joka ratkaisee ongelman. (Neljä mallia rinnakkain)
- Tiedän, että kanoninen tietomalli harmonisoi rakenteen mutta ei ratkaise auktoriteettia. (Yhteinen malli ei ole yhteinen totuus)
- Tiedän järjestyksen: harmonisoi, sitten täsmäytä, sitten konsolidoi. (Harmonisoi, sitten täsmäytä, sitten konsolidoi)
- Tiedän, että kynnysarvot kuvastavat virheiden sietokykyä ja että rikastaminen tarvitsee alkuperätiedot. (Kynnysarvot, tarkistus ja rikastaminen)
- Koetieto: Tunnen hierarkioiden hallinnan: Parent Account rakentaa hierarkian (Lightning-näkymä näyttää enintään 2 000 tiliä, ilman henkilötilejä), hierarkioilla on usein jaettu hallinta, ja yrityksellä voi olla useita päteviä hierarkioita. (Hierarkiatkin ovat perustietoja, Yksi hierarkia, useita mastereita)
MDM-3: voittavien attribuuttien valinta
- Pidän täsmäytyksen, yhdistämisen ja säilymissäännöt erillään. (Täsmäytys, yhdistäminen ja säilymissäännöt)
- Tunnen säilymissäännöt: uusin, yleisin, lähteen prioriteetti, ja tiedän, että jokainen sääntö tarvitsee omistajan. (Säilymissäännöt: mikä arvo voittaa?)
- Tiedän, että täsmäys ei vaadi yhdistämistä, ja yhdistän vain, kun voittaja on selvä, ja päätän ensin, mitä lapsitietueille tapahtuu. (Täsmäys ei vaadi yhdistämistä, Yhdistämissääntöni: selvä voittaja)
- Koetieto: Tiedän, mitä Salesforcen tilien yhdistäminen tekee: enintään kolme tietuetta, yksi pääasiallinen tietue, vanhimman tietueen Created By ja Created Date säilytetään, muut roskakoriin, eikä henkilötilien yhteyspisteobjekteja yhdistetä. (Mitä Salesforcen yhdistäminen todella tekee)
SDM-3: yksi näkymä asiakkaaseen
- Tiedän, että Data 360:n identiteetin selvitys linkittää lähdeprofiilit yhtenäiseksi profiiliksi ja säilyttää linkit takaisin: lähimpänä rekisteriä. (Identiteetin selvitys vastaa kysymykseen ”kuka?”)
- Koetieto: Tunnen Data 360:n täsmäytyssäännöt: säännön kaikkien ehtojen on täsmättävä, mikä tahansa sääntö voi täsmätä; enemmän ehtoja tarkkuuden vuoksi, vähemmän konsolidoinnin vuoksi. (Täsmäytyssäännöt)
- Tunnen täsmäytysmenetelmät (Exact, Exact Normalized, Fuzzy kolmella tarkkuudella): epätarkempi menetelmä nostaa konsolidointia ja väärien täsmäysten riskiä. (Täsmäytyssäännöt)
- Koetieto: Tiedän, että sovitussäännöt (Last Updated, Most Frequent, Source Priority) päättävät, mitä yhtenäinen profiili näyttää, mutta eivät muuta lähteitä; yhteyspisteitä ei soviteta. (Sovituskaan ei ole hallitsemista)
- Osaan valita tehtävään kaksoiskappaleiden hallinnan, identiteetin selvityksen tai erillisen MDM-alustan. (Kolme työkalua kolmeen tehtävään)
MDM-4 ja kaksisuuntaiset tiedot
- Tiedän, etteivät kaksisuuntaiset tiedot tarkoita kahta masteria: Salesforcessa tehty muokkaus ERP:n omistamaan kenttään on pyyntö, joten suunnittelen pyyntö → vahvistus → hyväksyntä → julkaisu, odottavan tilan kanssa. (Kaksisuuntaiset tiedot eivät tarkoita kahta masteria, Kun master sanoo ei)
- Osaan välttää silmukat ja törmäykset: erotan alkuperäisen muutoksen sen kaiusta ja päätän, mitkä kentät kulkevat yhdessä yhtenä transaktiona. (Silmukat ja törmäykset)
- Kun yksi asiakas on kahdessa ERP:ssä, osaan valita hierarkian, vertaistilit tai yhden tilin, jolla on lapsi kutakin ERP:tä kohden, sen mukaan, kuinka hyvin asiakas pitää ERP-järjestelmänsä synkronissa. (Yksi asiakas, kaksi ERP:tä, Kysy, miten ERP:t pidetään synkronissa)
Tarkistuspiste 1: osan 1 kokoaminen yhteen
- Koetieto: Tiedän, mitkä ulkoiset lisenssit sisältävät vakiojakamisen: Customer Community Plus ja Partner Community, jotka tarvitsevat ulkoisille käyttäjille rooleja; Customer Community käyttää jakamisjoukkoja (sharing sets). (Kuka näkee mitä ja kuka tarvitsee lisenssin)
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.
- ”Yksi totuuden lähde”: mikä totuus? Se on totuuden arkkitehtuuri, ei yksi tietue.
- Tee auktoriteetti näkyväksi skeemassa: etuliite kentille, jotka toinen järjestelmä omistaa.
- Luottamus tarvitsee muutakin kuin arvon: lähde, viimeisin vahvistus, kuka sitä muutti.
- Aloita ongelmasta, älä MDM-tuotteesta. MDM on liiketoimintapäätös auktoriteetista.
- Linkittäminen ei ole hallitsemista.
- Kun väärät täsmäykset tulevat kalliiksi, täsmäytä tarkoituksella liian vähän.
- Säilytä ulkoisista latauksista tulleet kaksoiskappaleet, kun saatat joutua jäljittämään taaksepäin.
- Yhtenäinen profiili on kartta. Golden record on päätös.
- Esitystapa ei ole auktoriteetti.
- Identiteetin yhtenäistäminen ei pyyhi pois tietoturvarajoja.
- Vaikeimpia ovat kaksisuuntaiset. Jaettu auktoriteetti ei ole ongelma; epäselvä auktoriteetti on.
- Älä koskaan anna hylätyn pyynnön muuttua kilpailevaksi totuudeksi.
- Kenttä, joka kertoo, että tämä on perustietoa, ohjaa muokattavuutta, ei tietuetyyppi.
- Emme hallitse ERP-järjestelmiä. Hallitsemme sitä, miten esitämme ne Salesforcessa.
Tärkeät termit
Osio nimeltä “Tärkeät termit ”| Termi | Yhdellä rivillä |
|---|---|
| Perustietojen hallinta (master data management, MDM) | Avaintietojen auktoritatiivisen identiteetin ja arvojen määrittäminen ja hallinnointi järjestelmien yli |
| Auktoriteettikartta | Kullekin attribuutille: kuka sen luo, kuka omistaa päätöksen, mikä järjestelmä on auktoritatiivinen, kuka saa muuttaa sitä |
| Golden record | Hallittu päätös siitä, mitkä arvot ovat auktoritatiivisia |
| Hybridi golden record | Tietue, jonka osaa attribuuteista hallitaan muualla ja kopioidaan sisään ja osa omistetaan paikallisesti |
| Rekisteri (registry) | MDM, joka linkittää tietueet samaksi entiteetiksi muuttamatta lähteitä |
| Konsolidointi | MDM, joka yhdistää tiedot keskitetysti, yleensä analytiikkaa varten, työntämättä niitä takaisin |
| Rinnakkaiselo (coexistence) | MDM, joka päättää hallitun arvon ja julkaisee sen takaisin lähteisiin |
| Keskitetty MDM | MDM, jossa hallitut tiedot luodaan masterissa ja jaellaan |
| Kanoninen tietomalli | Yrityksen sovittu muoto käsitteelle, jonka avulla järjestelmät kuvataan toisiinsa |
| Harmonisointi | Arvojen tekeminen vertailukelpoisiksi: vakiomuodot, koodit ja lyhenteet |
| Täsmäytys | Sen päättäminen, edustavatko tietueet samaa asiaa |
| Säilymissäännöt (survivorship) | Säännöt siitä, mikä arvo voittaa, kun lähteet ovat eri mieltä |
| Pääasiallinen tietue (principal) | Salesforcen yhdistämisessä tietue, joka säilyy ja pitää piilotetut ja vain luku -kenttänsä |
| Täsmäytysmenetelmä (match method) | Miten Data 360:n täsmäytysehto vertaa arvoja: exact, exact normalized tai fuzzy |
| Identiteetin selvitys (identity resolution) | Data 360:n tapa täsmäyttää lähdeprofiilit yhtenäisiksi profiileiksi |
| Yhtenäinen profiili | Joukko avaimia, jotka linkittävät yhtä henkilöä tai yritystä edustavat lähdetietueet |
| Sovitussäännöt (reconciliation rules) | Data 360:n säännöt siitä, minkä arvon yhtenäinen profiili näyttää |
| Jaetusti hallittu hierarkia | Hierarkia, jonka haarat ovat eri järjestelmien omistamia |
Testaa itsesi
Osio nimeltä “Testaa itsesi ”Lyhyitä skenaarioita kurssin tyyliin. Päätä vastauksesi ennen kuin avaat sen.
1. ”Salesforce on asiakkaan yksi totuuden lähde.” Mitä kysyt?
Mikä totuus? Auktoriteetti on attribuuttikohtainen: ERP voi omistaa virallisen nimen, laskutusosoitteen ja luottorajan, kun taas Salesforce omistaa myyntivastaavan ja asiakasmenestyksen tason. Rakenna auktoriteettikartta. Lue uudelleen Totuus kuuluu attribuutille.
2. Palveluagenttien pitää nähdä, että Salesforcen yhteyshenkilö on sama henkilö, joka osti verkosta. Kukaan ei tarvitse järjestelmiin muutoksia. Mikä MDM-tyyli?
Rekisteri: linkitä tietueet yhdeksi identiteetiksi muuttamatta lähteitä, mikä on juuri sitä, mitä Data 360:n identiteetin selvitys tekee. Valitse kevein malli, joka ratkaisee ongelman. Lue uudelleen Rekisteri: kerro, kuka on kuka.
3. Säilymissäännöksi on asetettu ”uusin voittaa” jokaiselle kentälle. Joku muuttaa ERP:n omistaman virallisen nimen Salesforce-kopiota. Mitä tapahtuu, ja mikä on vialla?
Uusin arvo voittaa, ja kopio ohittaa auktoriteetin. ”Uusin” on väite luottamuksesta, joka sopii joillekin attribuuteille (matkapuhelinnumero) ja toisille ei. Kun auktoriteettikartta sanoo ERP:n omistavan kentän, ERP voittaa. Lue uudelleen Säilymissäännöt: mikä arvo voittaa?.
4. Vanhan järjestelmän asiakastietueet tuodaan, ja ne täsmäävät olemassa oleviin tileihin. Yhdistetäänkö ne?
Ole varovainen. Täsmäys ei vaadi yhdistämistä, ja yhdistäminen tuhoaa vanhat ID:t ja vanhemmat arvot, joita saatat tarvita jäljittämiseen. Linkitä ne, ellei voittaja ole selvä eikä kaksoiskappale tuo mitään, mitä tarvitset. Lue uudelleen Yhdistämissääntöni: selvä voittaja.
5. Data 360:n yhtenäinen profiili näyttää Dallas. Tiimi sanoo, että Dallas on nyt jokaisen järjestelmän kultainen arvo. Onko?
Ei. Sovitus päättää, mitä yhtenäinen profiili näyttää; se ei muuta lähteitä eikä tee hallintapäätöstä. Jos jokaisen järjestelmän on käytettävä yhtä hallittua arvoa, kyse on rinnakkaiselosta tai keskitetystä MDM:stä, jolla on omistaja. Lue uudelleen Sovituskaan ei ole hallitsemista.
6. Terveystietojen täsmäytys verrattuna markkinointitietojen täsmäytykseen: samat säännöt?
Ei. Väärä täsmäys markkinoinnissa lähettää väärän tarjouksen; terveystiedoissa se yhdistää kahden ihmisen sairaushistoriat. Aseta tiukkuus väärässä olemisen hinnan mukaan, ja täsmäytä liian vähän, kun sekoittuminen tulee kalliiksi. Lue uudelleen Väärässä olemisen hinta.
7. Myyjät haluavat päivittää ERP:n omistaman laskutusosoitteen Salesforcesta. Miten suunnittelet sen?
Pyyntönä, ei muokkauksena: Salesforce lähettää ehdotetun arvon, ERP vahvistaa ja hyväksyy sen ja julkaisee auktoritatiivisen arvon takaisin. Pidä siihen asti odottava tila, ja käsittele hylkäykset, törmäykset ja kaiut. Lue uudelleen Kaksisuuntaiset tiedot eivät tarkoita kahta masteria.
8. Steve Truckingilla sama John Smith esiintyy kahden vähittäiskauppakumppanin kuormaluetteloissa. Yhtenäistetäänkö hänet?
Ei, tarkoituksella. Kumppani ei saa koskaan nähdä toisen kumppanin vastaanottajia, ja yhtenäinen identiteetti on silta, josta tiedot vuotavat. Täsmäytä liian vähän, kun sekoittuminen tulee kalliiksi; jos kumppani haluaa tunnistaa toistuvat vastaanottajat, rajaa se vain siihen kumppaniin. Lue uudelleen Yhtenäistäisinkö vastaanottajat kumppanien yli?.
9. Myyjä lähettää uuden katuosoitteen ERP:n omistamaan osoitteeseen, kun samalla minuutilla joku ERP:ssä muuttaa kaupungin. Mitä päätät?
Kulkeeko osoite yhtenä transaktiona. Jos kulkee, kentät menevät kaikki yhdessä tai ei mikään niistä, ja pyyntö hylätään, koska osoite muuttui sillä välin. Päätä se ennen ensimmäistä törmäystä, ja muista, että pyyntö pyytää muuttamaan ERP:n arvoa, ei muuta sitä. Lue uudelleen Silmukat ja törmäykset.
10. Asiakkaalla on yksi asiakas kahdessa ERP:ssä, eikä kukaan pidä kahta tietuetta synkronissa. Myynti haluaa yhden tilin. Mitä suosittelet?
En yhtä tiliä. Jos he eivät pysty pitämään tietueita synkronissa omissa ERP-järjestelmissään, Salesforce ei voi tehdä sitä heidän puolestaan: esitä ne vertaistileinä tai hierarkiana, ja näytä rakenne, jonka myynti jo tuntee. Yksi tili, jolla on lapsi kutakin ERP:tä kohden, edellyttää asiakasta, joka pitää yhteiset arvot synkronissa. Lue uudelleen Kysy, miten ERP:t pidetään synkronissa.
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 tavoiteluettelo painotuksineen. Tarkista aina nykyinen versio ennen kuin varaat kokeen.
- Kunkin moduulin oma Lue lisää -osio luettelee Salesforcen dokumentaation, johon sen tosiasiat perustuvat, sekä tarkistuspäivän.