Tietojen laatu ja hallinta
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 5 opiskeluopas Data Architect -kurssilla. Lue ensin kuusi moduulia; 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 Data Governance -osion (10 %) sekä osia Data Modeling -osiosta (metatiedot) ja Salesforce Data Management -osiosta (johdonmukaisuus). Täällä myös tietosuojalainsäädäntö kohtaa tietomallin. Tämä on arkkitehtuuria, ei oikeudellista neuvontaa: lakiasiat päättävät, mitä sovelletaan, ja arkkitehti tekee siitä täytäntöönpantavaa. 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.
GOV-2: hallintaohjelman suunnittelu
- Tiedän, että tietueen omistaja (alustan mekanismi pääsylle) ei ole tietojen omistaja (vastuussa tiedoista liiketoiminnan omaisuutena), ja että jokaiseen kenttään voi kirjata Data Owner -tiedon. (Tietueen omistaja ei ole tietojen omistaja)
- Osaan erottaa tietojen omistajan (päättää käytännön), tietojen vastuuhenkilön (pitää sen toiminnassa) ja ylläpitäjän (pyörittää järjestelmää) toisistaan. (Omistaja, vastuuhenkilö, ylläpitäjä)
- Koetieto: Tunnen kolme tapaa pyörittää hallintaohjelmaa, keskitetty, federoitu (hajautettu) ja hybridi, ja tiedän, mitä kukin tarkoittaa sille, kuka päättää käytännöt ja missä yhteiset määritelmät ovat. (Miten ohjelmaa pyöritetään)
- Osaan käyttää RACI:a vastaamaan siihen, missä tiedot luodaan, missä niitä muokataan ja missä niihin viitataan. (Anna RACI:n ansaita paikkansa)
- Osaan nimetä hallintakäytännölle täytäntöönpanokohdan (käyttöoikeudet, vahvistus, vain integraation kirjoittamat kentät, kenttähistoria), en pelkkää koulutusta. (Hallinnan on muututtava mekaaniseksi)
- Tiedän, että mittaamisen arvoisia laatusignaaleja ovat ne, joiden perusteella joku toimii. (Mittaa sitä, minkä perusteella joku toimii)
SDM-2 ja MDM-4: huonojen tietojen pitäminen ulkona
- Osaan päättää, pitäisikö tilien luonnin olla avoin vai lukittu, ja tunnen väliaikaisen tietuetyypin polun ERP:ssä hallittaville tileille. (Avoin vai lukittu?, Keskitie)
- Osaan suojata hallitut attribuutit (ERP-tunnus, virallinen nimi) ja jättää Salesforcen omat kentät muokattaviksi: hybridi golden record. Ja tiedän, että vain luku -kenttä Dynamic Forms -sivulla ei ole täytäntöönpanoa; kenttätason suojaus tai vahvistussääntö on. (Suojaa hallittu tietue, Oma tietuetyyppi kullekin virralle)
- Tiedän, että kaksisuuntaiset virrat ovat vaikeimpia: jos ERP hallitsee kenttää, Salesforce pyytää sen muuttamista, ja törmäys tarvitsee säännön (ERP voittaa, hylkää jos muuttunut, tai ihminen ratkaisee). (Suojaa hallittu tietue)
- Tiedän, että pakolliset kentät voivat luoda valetietoja (
N/A,999999), ja tunnen vaihtoehdot. (Älä anna pakollisten kenttien luoda valetietoja) - Osaan päättää, mitä tapahtuu saapuville tiedoille, jotka eivät läpäise tarkistuksia: hyväksy, hylkää tai eristä, ja kuka omistaa poikkeuksen. (Jokainen tietojen raja tarvitsee laatupäätöksen)
- Tiedän, että viitetiedotkin tarvitsevat metatietoja: määritelmät, omistajan, lähteen ja mappaukset järjestelmien välillä. (Myös viitetiedot tarvitsevat metatietoja)
DM-3: liiketoiminnan ja tekniset metatiedot
- Koetieto: Osaan erottaa liiketoiminnan metatiedot (merkitys, määritelmät, omistaja, säännöt, arkaluonteisuus) teknisistä metatiedoista (objektit, kentät, tyypit, API-nimet, skeemat, mappaukset, alkuperä). (Kahdenlaisia metatietoja)
- Tiedän eron liiketoiminnan tietosanakirjan (mitä se tarkoittaa), alkuperän (mistä se tuli) ja luokittelun (miten sitä on käsiteltävä) välillä. (Tunne tietosi)
- Tunnen Salesforcen luokittelukentät: Data Owner, Field Usage, Data Sensitivity Level, Compliance Categorization, vakio- ja mukautetuissa kentissä. (Luokittelu vastaa eri kysymykseen)
- Tiedän, että luokitellaan arkaluonteiset kentät, ei jokaista kenttää, ja että luokittelu ilman täytäntöönpanoa on koristetta. (Luokittelu ilman täytäntöönpanoa on koristetta)
GOV-1: henkilötiedot ja arkaluonteiset tiedot
- Tunnistan tärkeimmät lait (EU:n yleinen tietosuoja-asetus eli GDPR, CCPA/CPRA, PIPEDA, LGPD, Australian Privacy Act, HIPAA, PCI DSS, SOX, COPPA), tiedän, että GDPR voi ulottua EU:n ulkopuolisiin organisaatioihin, ja tiedän, mitä laeilla on yhteistä: oikeudet, siirrot, tietoturvaloukkauksista ilmoittaminen ja osoitusvelvollisuus. (Säädökset, jotka sinun pitäisi tunnistaa, Lait eivät pysähdy rajalle)
- Tiedän eron salauksen, peittämisen, pseudonymisoinnin ja anonymisoinnin välillä, ja että pseudonymisoidut tiedot ovat yhä henkilötietoja. (Anonymisoitu, pseudonymisoitu, salattu, peitetty)
- Tiedän, että vähemmän kerääminen on tietosuojakontrolli ja että säilytys suunnitellaan heti alussa. (Vähemmän keräämisen päätös on arkkitehtuuripäätös, Säilytys on osa mallia)
- Tunnen suostumustietomallin: yleinen suostumus Individual-objektissa, viestintäkanavan suostumus, yhteyspisteen suostumus ja tietojen käyttötarkoitus. (Käytä mallia, jonka Salesforce on jo rakentanut)
- Tiedän, että pyynnöillä on määräajat (GDPR: kuukausi, jota voi jatkaa kahdella lisäkuukaudella), joten kopioiden kartan on oltava olemassa ensin. (Aika kuluu)
- Tiedän, että oikeus tulla unohdetuksi tarkoittaa jokaisen kopion löytämistä (historia, arkistot, analytiikka, lokit, tiedostot, vapaa teksti), ja että Privacy Centerin käytännöt ajetaan objektikohtaisesti asiakastietuetta vastaan. (Nyt henkilö sanoo: unohda minut, Privacy Center on työkalu)
- Tunnen Shield Platform Encryptionin kompromissit: probabilistisesti salattuja kenttiä ei voi suodattaa, ryhmitellä eikä lajitella SOQL:ssä; deterministinen salaus sallii suodattamisen; salatut kentät eivät voi ohjata ehtoihin perustuvaa jakamista. (Salaus on kontrolli, ei vaatimustenmukaisuus)
- Tiedän, ettei tuotannon arkaluonteisia tietoja kopioida sandboxeihin, ja että Data Mask korvataan Data Mask & Seedillä. (Älä kopioi tuotannon riskiä sandboxiin)
- Tunnen kenttähistorian seurannan (enintään 20 kenttää objektia kohden; 18 kuukautta, 24 vain API:n kautta; pitkästä tekstistä kirjataan vain muokkaus) verrattuna Field Audit Trailiin (enintään 200 kenttää, säilytetään kunnes poistat sen). (Historiakin on tietoa)
- Tunnen Event Monitoringin lokien säilytyksen (ilman lisäosaa 1 päivä joillekin tapahtumille, lisäosan kanssa oletuksena 30 päivää, pidennettynä enintään 365) ja tiedän, että tapahtumat viedään SIEM:iin ennen kuin niitä tarvitaan: maksullisia lokeja ei voi hakea sopimuksen alkua edeltävältä ajalta. (Auditointi ja valvonta eivät ole sama asia)
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.
- Käytäntö ilman täytäntöönpanokohtaa on enimmäkseen toive.
- Omistajat päättävät käytännöt, arkkitehdit panevat ne täytäntöön. Älä keksi käytäntöä, äläkä leiki juristia.
- Hallinta ei ole koskaan valmis. Se kulkee aaltoina; suunnittele palaute.
- Älä luota hyvään käytökseen. Rakenna kontrolli: ihmiset, integraatiot ja agentit tekevät kaikki virheitä.
- Hallitse riittävästi, älä kaikkea.
- Estä ensin kalliit virheet. Kaksoiskappale, jolla on kahden vuoden historia, on iso ongelma.
- Erota se, mitä ihmiset lukevat, siitä, minkä perusteella koneet päättävät.
- Dokumentoi laajasti, luokittele harkiten.
- Halvimmat hallittavat arkaluonteiset tiedot ovat ne, joita et koskaan kopioinut.
- Suostumus on tietoa, ja lupa käyttää tietoja on voitava esittää tietona.
- Hallitse ensin, minne henkilötiedot menevät, koska poistaminen on harvinaista ja vaikeaa.
- Vaatimustenmukaisuus ei ole tuote.
- Keruu → Luokittelu → Suojaus → Käyttö → Säilytys → Poisto → Auditointi.
- Tallenna näyttö ennen kuin kukaan pyytää sitä.
Tärkeät termit
Osio nimeltä “Tärkeät termit ”| Termi | Yhdellä rivillä |
|---|---|
| Tietojen hallinta (data governance) | Tietoja koskevat käytännöt ja arkkitehtuuri, joka tekee niistä totta |
| Tietojen omistaja | Henkilö tai toiminto, joka vastaa tietystä tietolajista |
| Tietojen vastuuhenkilö (data steward) | Henkilö, joka pitää tiedot terveinä päivittäin |
| Tietojen ylläpitäjä (custodian) | Tiimi, joka käyttää tietoja sisältäviä järjestelmiä |
| RACI | Responsible (toteuttaja), Accountable (vastuussa), Consulted (kuultava), Informed (tiedotettava) |
| Väliaikainen tietue | Tietue, joka on luotu ennen kuin auktoritatiivinen järjestelmä on hyväksynyt sen |
| Liiketoiminnan tietosanakirja | Sovitut määritelmät liiketoiminnan tärkeille termeille |
| Alkuperä (lineage) | Mistä arvo tuli ja mitä sille tapahtui matkalla |
| Tietojen luokittelu | Tietojen merkitseminen arkaluonteisuuden ja compliance-luokan mukaan, jotta ne saavat oikeat kontrollit |
| Taksonomia | Nimiöiden joukko, jolla organisaatio luokittelee tietoja |
| Henkilötiedot | Tiedot, jotka yksilöivät henkilön tai voidaan yhdistää takaisin henkilöön |
| Pseudonymisointi | Tunnisteiden korvaaminen niin, että tie takaisin on yhä olemassa; yhä henkilötietoja |
| Anonymisointi | Kohtuullisen mahdollisuuden tunnistaa henkilö poistaminen |
| Suostumustietomalli | Salesforcen objektit suostumukselle henkilön, kanavan, yhteyspisteen ja käyttötarkoituksen mukaan |
| Oikeus tulla unohdetuksi | Henkilön oikeus, jos laki sen antaa, saada henkilötietonsa poistetuiksi |
| Hybridi golden record | Yksi tietue, jossa on perustietojärjestelmän kentät ja Salesforcen omat kentät, kullakin yksi lähde |
| Liiketoiminnan / tekniset metatiedot | Mitä tiedot tarkoittavat ja kuka ne omistaa / miten ne on rakennettu ja miten ne liikkuvat |
| Field Audit Trail | Pidempi kenttähistoria: enintään 200 kenttää objektia kohden, säilytetään kunnes poistetaan |
| Event Monitoring | Lokit kirjautumisista, vienneistä, API-kutsuista ja katseluista, säilytetään rajoitetun ajan |
| SIEM | Tietoturvan säilö, jossa tapahtumalokeja säilytetään ja analysoidaan |
Testaa itsesi
Osio nimeltä “Testaa itsesi ”Lyhyitä skenaarioita kurssin tyyliin. Päätä vastauksesi ennen kuin avaat sen.
1. Käytännön mukaan vain taloushallinto saa muuttaa asiakkaan virallista nimeä. Tiimi aikoo hoitaa asian koulutuksella. Mitä puuttuu?
Täytäntöönpanokohta. Koulutus ei ole kontrolli: käytä kenttätason pääsyä, kenttää, johon vain integraatio kirjoittaa, vahvistussääntöä tai hallittua prosessia. Omistajat päättävät käytännön; arkkitehti tekee siitä mekaanisesti totta. Lue uudelleen Hallinnan on muututtava mekaaniseksi.
2. Asiakkaiden perustiedot hallitaan ERP:ssä. Myyjien on päästävä myymään uusille prospekteille heti. Miten annat heidän tehdä sen ilman, että kaksi järjestelmää luo perustietueen?
Anna myyjien luoda tili väliaikaisella tietuetyypillä ja muunna se sitten hallitulla prosessilla: taloushallinto hyväksyy, tai integraatio lähettää sen ERP:hen, joka täsmää tai luo asiakkaan ja lähettää takaisin auktoritatiivisen tunnuksen. Lue uudelleen Keskitie.
3. Uusi pakollinen kenttä täyttyy arvoilla ”N/A” ja ”999999”. Mitä tapahtui, ja mitä tekisit sen sijaan?
Käyttäjät pakotettiin vastaamaan ennen kuin he tiesivät. Vaadi sitä myöhemmin prosessissa, anna toisen järjestelmän toimittaa se, käytä väliaikaista tilaa tai salli eksplisiittinen Tuntematon, kun se on todellinen vastaus. Lue uudelleen Älä anna pakollisten kenttien luoda valetietoja.
4. Tiimi korvasi nimet tokeneilla ja sanoo, että tiedot on anonymisoitu, joten poistopyyntö on hoidettu. Onko se?
Ei, jos tokenit voidaan yhdistää takaisin henkilöön: se on pseudonymisointia, ja tiedot ovat yhä henkilötietoja. Kerro tarkasti, mitä järjestelmä tekee ja missä mappaus on, ja anna lakiasioiden päättää, täyttääkö se vaatimuksen. Lue uudelleen Anonymisoitu, pseudonymisoitu, salattu, peitetty.
5. Vastaanottaja suostuu toimitusta koskeviin tekstiviesteihin mutta ei markkinointiin. Miten mallin pitäisi säilyttää se?
Suostumustietomallilla, ei yhdellä valintaruudulla: henkilö, kanava (tekstiviesti), tietty numero ja tietojen käyttötarkoitus (toimitusilmoitukset, ei markkinointi). Ja päätä, mikä järjestelmä on suostumuksen osalta auktoritatiivinen, jotta peruutus tavoittaa jokaisen järjestelmän, joka toimii sen perusteella. Lue uudelleen Käytä mallia, jonka Salesforce on jo rakentanut.
6. Compliancen pitää suodattaa raportteja salatulla sosiaaliturvatunnuskentällä (Social Security). Kenttä käyttää oletussalausmenetelmää. Mikä on ongelma?
Probabilistinen salaus ei salli suodattamista SOQL:n WHERE-lausekkeissa eikä tiedonhallinnan suodattimissa. Deterministinen salaus sallii suodattamisen hieman vahvuuden kustannuksella. Salaus on suunnittelupäätös, jolla on kompromisseja, ei valintaruutu lopussa. Lue uudelleen Salaus on kontrolli, ei vaatimustenmukaisuus.
7. Kuusi kuukautta välikohtauksen jälkeen joku kysyy, kuka vei joukon tietueita ulos. Kukaan ei ottanut Event Monitoringin tallennusta käyttöön. Mitä voit kertoa?
Todennäköisesti et mitään: tapahtumalokeja säilytetään rajoitetun ajan (enintään vuoden, pidennettynäkin), joten kaikki vanhempi on poissa, ellei sitä viety ulos. Ota Event Monitoring käyttöön ja lähetä tapahtumat SIEM:iin ennen kuin tarvitset niitä. Lue uudelleen Auditointi ja valvonta eivät ole sama asia.
8. Myyjä pyytää Salesforcea muuttamaan asiakkaan virallisen nimen, jota ERP hallitsee. Samoina minuutteina joku muuttaa sen ERP:ssä. Mitä suunnitelman pitäisi sanoa?
Että Salesforce pyysi muutosta, ei muuttanut: ERP hallitsee kenttää. Päätä törmäyssääntö etukäteen (ERP voittaa, hylkää jos arvo muuttui, tai ihminen ratkaisee) ja se, kulkevatko toisiinsa liittyvät kentät yhdessä. Lue uudelleen Suojaa hallittu tietue.
9. Henkilön poistopyyntö saapuu. Tiimi aikoo alkaa kartoittaa, missä hänen tietonsa ovat. Mikä on ongelma?
Aika kuluu jo: GDPR:n mukaan kuukausi, jota voi monimutkaisissa pyynnöissä jatkaa kahdella lisäkuukaudella. Kopioiden kartan on oltava olemassa ennen kuin pyyntö saapuu. Lue uudelleen Aika kuluu.
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 ja lait, joihin sen tosiasiat perustuvat, sekä tarkistuspäivän.