Sanasto, alkuperä ja luokittelu

🌐 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 3/6 luvussa Tietojen laatu ja hallinta, Data Architect -kurssin luku 5. Jokainen moduuli on itsenäinen. Edellinen: Huonojen tietojen pitäminen ulkona · Seuraava: Tietosuojalait muovaavat suunnittelua

Kysymys, johon tämä moduuli vastaa: Miten kirjaat, mitä tiedot tarkoittavat, mistä ne tulivat ja kuinka arkaluonteisia ne ovat?

Olet perinyt orgin. Tilillä (Account) on 900 kenttää, joiden joukossa Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c ja Account_Status__c. Mikä niistä kertoo, onko joku oikeasti asiakas? Avaat kuvaukset. Kolme on tyhjiä. Yhdessä lukee ”Customer Type”. Kiitos vain. Yhden mukaan se tuli ERP:stä; toisen loi kuusi vuotta sitten joku, joka on lähtenyt aikoja sitten. Kuvittele nyt, ettet ole arkkitehti vaan integraatio, raportointitiimi tai agentti. Organisaatiolla on paljon tietoja. Se ei tarkoita, että se tietää, mitä tiedot tarkoittavat.

Tässä kohdassa metatiedoista tulee arkkitehtuuria kolmen kysymyksen kautta, jotka liittyvät toisiinsa mutta eivät ole samoja:

• Sanasto: mitä nämä tiedot tarkoittavat?
• Alkuperä (lineage): mistä ne tulivat?
• Luokittelu: miten niitä on käsiteltävä?

Kahdenlaisia metatietoja

Metatietoja on kahdenlaisia, ja tarvitset molempia. Liiketoiminnan metatiedot kertovat, mitä tiedot merkitsevät liiketoiminnalle: määritelmä, omistaja, käyttösäännöt, arkaluonteisuus. Tekniset metatiedot kertovat, miten tiedot on rakennettu ja miten ne liikkuvat: objekti ja kenttä, tyyppi ja pituus, API-nimi, skeema, mappaus järjestelmästä toiseen, alkuperä lähteestä kohteeseen. Kentän API-nimi ja tyyppi kertovat kehittäjälle, miten sitä käytetään; sen määritelmä ja omistaja kertovat kaikille muille, pitäisikö sitä käyttää. Kun ne ovat ristiriidassa, tai toinen puuttuu, siinä integraatiot ja raportit menevät pieleen.

Koetieto. Erota liiketoiminnan metatiedot (merkitys, määritelmät, omistaja, säännöt, arkaluonteisuus: liiketoiminnan sanasto ja luokittelu) teknisistä metatiedoista (objektit, kentät, tyypit, API-nimet, skeemat, mappaukset ja alkuperä).

Aloita merkityksestä

Luku 3 asetti säännön: jokainen kenttä saa kuvauksen. Ei ”Customer Status” kentälle nimeltä Customer Status, vaan jotain tällaista: ”Kumppanin nykyinen kaupallinen suhde Steve Truckingiin. Asetetaan ERP:stä aktivoinnin jälkeen. Älä käytä prospektien kvalifiointiin.” Nyt tiedän, mitä se tarkoittaa, mistä se tulee ja mihin sitä ei pidä käyttää. Siitä alkaa liiketoiminnan tietosanakirja (data dictionary): yhteiset määritelmät tiedoille, joilla on väliä. Mikä on asiakas? Aktiivinen asiakas? Mitä Delivered tarkoittaa? Mikä lasketaan ajallaan olevaksi? Nämä kuulostavat itsestään selviltä, kunnes laitat viisi osastoa samaan huoneeseen: taloushallinnolla on yksi määritelmä, myynnillä toinen, operatiivisella toiminnalla kolmas, tietovarastolla neljäs, ja joku rakensi koontinäytön viidennen varaan. Ongelma ei ole se, ettei kukaan puhu samaa kieltä. Ongelma on, ettei yritys ole sopinut merkityksestä.

Tietosanakirja voi olla taulukossa tai dokumentaatiotyökalussa, mutta sen tärkeiden määritelmien on oltava lähellä sitä, missä ihmiset käyttävät tietoja. Alustalla se tarkoittaa kenttien kuvauksia, ohjetekstejä ja luokittelun metatietoja. Analytiikassa se on vielä tärkeämpää: ”liikevaihto” ei voi tarkoittaa yhtä asiaa johdon koontinäytöllä ja toista analyytikon kyselyssä. Sitä varten on semanttinen kerros, ja Data 360:n semanttiset mallit pitävät hallittuja määritelmiä, kuten mittareita, dimensioita ja suhteita, fyysisten tietojen yläpuolella (Create a Semantic Model in Data 360 (opens in a new tab)). Tekniikka muuttuu; vaatimus ei: tärkeillä tiedoilla on oltava sovittu merkitys.

Ja aloita merkityksestä, älä tekniikasta. Tietosanakirja, joka alkaa objektista, kentästä, tyypistä ja API-nimestä, dokumentoi toteutuksen. Tietosanakirja, joka alkaa liiketoiminnan termeistä, dokumentoi yrityksen:

Liiketoiminnan termi	Merkitys	Missä se esitetään
Vähittäiskauppakumppani (Retail Partner)	Jälleenmyyjä, jolle Steve Trucking toimittaa sopimuksen perusteella	Salesforcen tili (Account); talouden ERP:n asiakas
Toimitus (Delivery)	Yksi toimitus yhdelle vastaanottajalle, yhteen osoitteeseen, yhtenä päivänä	Tänään RouteDesk; työtilaus, kun toimitukset siirtyvät Salesforceen
Vastaanottaja (Recipient)	Henkilö, joka vastaanottaa toimituksen	Vastaanottajan tiedot toimituksessa
Delivered (toimitettu)	Valmis sovitun operatiivisen määritelmän mukaisesti	Toimituksen tila
Ajallaan toimitettu	Valmis sovitun toimitusikkunan sisällä	Johdettu mittari

Click to enlarge

Yksi merkitys, monta teknistä esitystä.

Kysy sitten, mistä se tuli

Kun tiedän, mitä arvo tarkoittaa, haluan tietää, mistä se tuli. Se on alkuperää (lineage). Kumppanin virallinen nimi Salesforcessa: kirjoittiko myyjä sen, lähettikö ERP sen, muunsiko integraatio sen, yhtenäistikö Data 360 sen, laskettiinko se, tuottiko tekoäly sen? Ne vaikuttavat siihen, kuinka paljon luotan siihen ja mitä saan sillä tehdä. Muista moduulin 2 väliaikaiset tietueet: kahdessa tilissä voi kummassakin lukea ”Keystone”, toisen loi myyjä eilen, toinen tuli ERP:stä auktoritatiivisen tunnisteen kanssa. Sama teksti, eri alkuperä, eri käsittely.

Alkuperä ei ole vain data engineerin kaavio tuhannesta taulusta. Tärkeistä tiedoista haluan vastata käytännön kysymyksiin: mistä se alkoi, mikä järjestelmä on auktoritatiivinen, mikä muunsi sitä, mitkä järjestelmät saivat kopiot, mikä muutti sitä viimeksi, ja voinko jäljittää johdetun arvon takaisin sen lähteisiin? Luvun 4 järjestelmäkartta kertoo, että järjestelmät on yhdistetty. Alkuperä kertoo, mitä tiedoille tapahtui matkalla.

Osa alkuperästä tulee ilmaiseksi: ERP-tunnus tilillä, Created By ja Last Modified By, integraatiolokit, mappausasiakirjat. Data 360 lisää tieto-objekteihinsa alkuperäkentät, jotka kirjaavat kunkin tietueen tietolähteen ja lähdeobjektin (Data Lineage Fields (opens in a new tab)). Mutta älä oleta, että alkuperä ilmestyy siksi, että järjestelmät on integroitu. Joskus hyödyllisin alkuperä on yksi kenttä: Source System = Keystone. Ja jos lähteellä on merkitystä hallinnalle, tee siitä mekaanisesti luotettava, integraation asettama, ei ihmisen kirjoittama.

Johdetut tiedot tarvitsevat alkuperää kaikkein eniten. Sanotaan, että Steve Trucking laskee myöhästymisriskin kuorma-auton sijainnista, toimitusikkunasta ja reittihistoriasta, ja ajojärjestely käyttää sitä priorisointiin. Mistä ”korkea” tuli? Lisää agentti, joka kertoo vastaanottajalle ”toimituksesi on myöhässä”, ja sinun on tiedettävä, mihin se perustui ja kuinka tuoretta se oli. Mitä kauemmas siirryt tallennetuista arvoista laskettuihin, yhtenäistettyihin, ennustettuihin ja tuotettuihin, sitä tärkeämpää alkuperä on.

Luokittelu vastaa eri kysymykseen

Nyt: miten sitä pitäisi käsitellä? Vastaanottajan nimi, toimitusosoite, puhelinnumero, toimitusmuistiinpanot, toimituksen tila, kuorma-auton numero, jakelukeskus, vähittäiskauppakumppani, valokuva: ne eivät ole yhtä arkaluonteisia. ”Jakelussa” ei ole puhelinnumero, eikä jakelukeskuksen koodi ole valokuva jonkun kodin sisältä. Salesforcessa voit kirjata tämän jokaiseen kenttään, vakio- tai mukautettuun: Data Owner, Field Usage, Data Sensitivity Level ja Compliance Categorization (Data Classification Metadata Fields (opens in a new tab)). Luku 3 kutsui niitä taksonomiakentiksi ja kertoi, miksi niillä on väliä: merkitse kenttä PII:ksi tai GDPR:ksi, niin prosessit löytävät sen peitetyökaluista Salesforcen tekoälyn luottamuskerrokseen, joka voi estää merkittyjä arvoja päätymästä suurelle kielimallille. Yksi varoitus luvusta 3: Salesforce poistaa nykyään tämän kielimallin peittämisen käytöstä agenteilta, koska se voi riisua kontekstin, jota agentti tarvitsee (Luokittele se, millä on väliä: taksonomiakentät). Luokittelun on siis yhä ohjattava muita kontrolleja.

Kantani tässä on harkittu: luokittele arkaluonteiset kentät, älä jokaista kenttää. En halua, että kolme kuukautta käytetään tuhansien kenttien luokitteluun, jotta joku voi raportoida ”100 % luokiteltu”, eikä kukaan käytä sitä. Vastaanottajan puhelinnumero: kyllä. Kotiosoite: kyllä. Toimitusmuistiinpanot, joissa voi olla porttikoodeja ja ”koira pihalla”: kyllä. Valokuvat, joissa voi näkyä ihmisiä tai koti: ehdottomasti. Sisäinen näyttöotsikko? Siihen hallinnan energiaa ei kannata käyttää. Se ei tee dokumentoimattomista kentistä hyväksyttäviä. Kaksi eri tehtävää: dokumentointi on laajaa; luokittelu on harkittua. Se pitää luokittelun merkityksellisenä.

Taksonomia, jota ihmiset osaavat käyttää

Luokittelu tarvitsee sanaston, taksonomian. Salesforcen oletukset ovat Public, Internal, Confidential, Restricted ja MissionCritical; organisaatiosi voi haluta omat nimiönsä. En määrää niitä. Pidä ne ymmärrettävinä: jos luokkia on 47, eikä kukaan tietosuojatiimin ulkopuolella osaa erottaa luokkaa 31 luokasta 32, siitä ei ole apua. Hyvä taksonomia yhdistää nimiön käyttäytymiseen. Jos kenttä on arkaluonteinen henkilötieto, kuka saa nähdä sen, saako se mennä sandboxiin, poistua alueelta, näkyä analytiikassa, kuinka kauan sitä säilytetään, saako agentti käyttää sitä? Nyt luokittelu tekee työtä.

Luokittelu ilman täytäntöönpanoa on koristetta

Merkitse vastaanottajan puhelinnumero arkaluonteiseksi äläkä muuta mitään muuta, niin olet kirjoittanut dokumentaatiota. Hyödyllistä, mutta hallinta menee pidemmälle: luokittelun pitäisi ohjata käyttöoikeuksia, peittämistä, salausta, säilytystä, suostumusta, tietojen liikkumista, sandboxien käyttöä, auditointia ja tekoälyn pääsyä. Osa siitä on arkkitehdin suunnittelupäätöksiä; jotkin alustat soveltavat nykyään tunnisteita ja luokitteluja suoraan käytännöissä, kuten Data 360:n hallinta tekee (Data Governance in Data 360 (opens in a new tab)). Eikä kentän merkitseminen Restricted-tasolle estä ketään lukemasta sitä. Luokittelu kertoo, miten kenttää pitäisi käsitellä; tietoturva tekee siitä totta. Järjestys on: tunnista tiedot, ymmärrä ne, luokittele se, millä on väliä, ja sovella sitten kontrollit, joita luokittelu edellyttää.

Click to enlarge

Kolme kysymystä tiedoistasi, ja kolmannen on ohjattava jotain.

Myös viitetiedot tarvitsevat metatietoja

Maakoodit, toimitusten tilat, jakelukeskusten koodit, kumppanien tunnisteet, peruutusten syyt: ne näyttävät yksinkertaisilta, kunnes kaksi järjestelmää on eri mieltä. Yksi sanoo CANCELLED, toinen CANCELED, kolmas CNCL, neljäs 9. Viitetiedot tarvitsevat määritelmät, omistajan, lähteen, elinkaaren arvojen muuttuessa ja mappaukset, kun järjestelmät esittävät ne eri tavoin. Pienet arvot voivat ohjata hyvin suuria prosesseja. Luku 6 menee pidemmälle.

Kaikki kolme yhdessä

Otetaan vastaanottajan puhelinnumero. Sanasto: numero, jolla tavoitetaan tietyn toimituksen vastaanottava henkilö. Alkuperä: vähittäiskauppakumppanin kuormaluettelosta. Luokittelu: henkilötieto. Nyt arkkitehtuurikysymykset ovat mahdollisia: saako tiimi nähdä sen ja kuinka kauan (taustakuvauksen mukaan vain omilla pysähdyksillään ja vain sinä päivänä); saako se mennä sandboxiin; tarvitseeko Snowflake sitä; saako agentti käyttää sitä; mitä tapahtuu, kun toimitus on tehty?

Otetaan nyt toimituksen tila. Sanasto: toimituksen nykyinen operatiivinen tila. Alkuperä: Steve Truckingin toimitusprosessin asettama ja lähetetty takaisin kullekin kumppanille sen oman integraation kautta. Luokittelu: operatiivinen, ei arkaluonteinen. Eri tiedot, eri käsittely. Siitä tässä on kyse.

En pidä metatietoja dokumentaationa, joka tuotetaan sen jälkeen, kun varsinainen arkkitehtuuri on tehty. Jos en osaa sanoa, mitä kenttä tarkoittaa, en ymmärrä tietomallia. Jos en tiedä, mistä arvo tuli, en ymmärrä integraatioita. Jos en tiedä, onko se arkaluonteinen, en ymmärrä tietoturvaa. Metatiedot kuvaavat arkkitehtuuria, ja joskus ohjaavat sitä.

Kokeen jälkeen: mitä tekoäly muuttaa. Luokittelusta on tulossa kytkin sille, mitä agentti saa hakea tai toistaa, ja alkuperän on ulotuttava aina agentin vastaukseen tai toimintaan asti. Jos agentti kertoo vastaanottajalle, että toimitus on myöhässä, arkkitehtuurin pitäisi pystyä kertomaan, mihin se perustui, mistä se tuli ja oliko agentilla lupa käyttää sitä. ”Jossain Salesforcessa” ei ole alkuperä, eikä ”asiakastiedot” ole luokittelu.

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

• Mitkä liiketoiminnan termit tarvitsevat hallitut määritelmät, jotta järjestelmät ja tiimit eivät anna yhdelle sanalle eri merkityksiä.
• Miten tärkeät arvot säilyttävät riittävästi alkuperää näyttääkseen lähteensä, auktoriteettinsa ja muunnoksensa.
• Millä kentillä on arkaluonteisuus- tai compliance-merkitys, niin että ne saavat eksplisiittisen luokittelun.
• Mitä taksonomiaa organisaatio käyttää, ja osaavatko ihmiset soveltaa sitä johdonmukaisesti.
• Miten luokittelu ohjaa todellisia kontrolleja sen sijaan, että se jää käyttämättä.

Ennen kuin hallitset tietoja, tiedä, mitä sinulla on: mitä ne tarkoittavat, mistä ne tulivat, miten niitä on käsiteltävä. Dokumentoi laajasti, luokittele harkiten, säilytä alkuperä siellä, missä sillä on väliä. Muuten et hallitse tietoja. Sinulla vain on niitä.

Lue lisää

• Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).
• Salesforce Help, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) ja Create a Semantic Model in Data 360 (opens in a new tab) (englanniksi, tarkistettu 2026-10-14).