Rakenna looginen malli
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)
Moduuli 3/6 luvussa Tietojen mallintaminen merkityksen kautta, Data Architect -kurssin luku 2. Jokainen moduuli on itsenäinen. Edellinen: Piirrä suhteet · Seuraava: Sijoita tiedot oikeaan paikkaan
Kysymys, johon tämä moduuli vastaa: Miten muutan käsitteellisen mallin loogiseksi tietomalliksi?
Käsitteellinen malli kertoi meille, mitä Steve Truckingilla on olemassa ja miten se liittyy toisiinsa: vähittäiskauppakumppanit ja niiden jakelukeskukset, kuormaluettelot ja toimitukset, vastaanottajat, reitit ja pysähdykset, tiimit, kuorma-autot ja tiimien osoitukset. Se riittää erittäin tuottavaan keskusteluun liiketoiminnan kanssa. Mutta jossain vaiheessa tarvitsen lisää yksityiskohtia. Mitä meidän täytyy tietää toimituksesta? Mikä tekee yhdestä jakelukeskuksesta erilaisen kuin toisesta? Miten tunnistamme vastaanottajan? Mikä kuuluu tiimin osoitukselle eikä tiimille tai kuorma-autolle? Nämä kysymykset vievät meitä käsitteellisestä mallista kohti loogista tietomallia, emmekä vieläkään rakenna Salesforcea.
Istu, paikka, mallinna
Osio nimeltä “Istu, paikka, mallinna ”Ensin takaisin koirien pariin. Meillä on laatikot ja viivat. Nyt kaksi uutta kysymystä: mitä tiedämme kustakin asiasta, ja miten erotamme ne toisistaan?
Mikä sitä kuvaa? Koiralla on nimi ja syntymäpäivä. Omistajalla on nimi, puhelinnumero ja osoite. Tempulla on nimi ja vaikeustaso. Jokainen tieto menee siihen laatikkoon, jota se kuvaa.
Sitten liitos. Kuinka hyvin Bella tekee Istu-tempun ja milloin se oppi sen: kuvaako se Bellaa? Ei aivan; se on joissain tempuissa parempi kuin toisissa. Kuvaako se Istu-temppua? Ei; jokainen koira tekee Istu-tempun eri tavalla. Se kuvaa Bellaa ja Istu-temppua yhdessä, joten se kuuluu koiran temppuun: taitotaso ja oppimispäivä. Siksi liitos on olemassa: jotkin tiedot kuuluvat vain parille.
Mikä koira on mikä? Kokeile ensin nimeä. Max-nimisiä koiria on paljon, joten nimi ei ole yksilöllinen. Omistajan puhelinnumero? Marcuksella on kaksi koiraa samalla numerolla, ihmiset vaihtavat numeroitaan, ja se on jonkun henkilötieto, joka kopioituisi jokaiseen järjestelmään, joka koskaan viittaa koiraan. Mikrosirun numero näyttää paremmalta: se on yksilöllinen, eikä se muutu. Mutta uutta pentua ei ehkä ole vielä sirutettu, eikä avain voi olla tyhjä. Mikrosiru siis jää, jonakin, jolla koira tunnetaan myös, ja koira saa oman koiran ID:nsä (Dog ID): numeron, joka tekee yhden tylsän työn eli erottaa koirat toisistaan.
Samat kysymykset kysymme nyt Steve Truckingilta, ja syistä, joiden vuoksi nimi, puhelinnumero ja mikrosiru kukin jäävät vajaiksi, tulee sääntö, jota olen noudattanut vuosia.
Käsitteellinen kertoo, mitä on olemassa; looginen kertoo, mitä se tarkoittaa tietona
Osio nimeltä “Käsitteellinen kertoo, mitä on olemassa; looginen kertoo, mitä se tarkoittaa tietona ”Otetaan kuorma-auto. Mitä minun täytyy tietää kuorma-autosta? Ehkä sen yksikkönumero, VIN-tunnus, merkki, malli, vuosimalli, rekisterikilpi, nykyinen kilometrimäärä ja tila. Ne ovat kuorma-auton attribuutteja.
Otetaan sitten toimitus. Ehkä vähittäiskauppakumppanin tilausnumero, toimituspäivä, luvattu aikaikkuna, todellinen saapumisaika, tila ja se, sisältyykö toimitukseen asennus tai vanhan laitteen poisvienti. Taas attribuutteja.
Käsitteellinen malli kertoi meille, että toimitus on olemassa. Looginen malli alkaa kertoa, mitä toimitus tarkoittaa tietona. Yksinkertainen laatikko, kuten kuorma-auto tai toimitus, voi edustaa kokonaista joukkoa kenttiä.
Silti useimmissa kaavioissamme laatikot pysyvät yksinkertaisina, kolmesta syystä. Kenttien määrä kasvaa. Kentät vanhenevat nopeasti. Ja jokaisella kentällä on yksityiskohtia, joita on vaikea näyttää objektimallissa: sen API-nimi, nimiö, tietotyyppi ja pituus. Nuo yksityiskohdat kirjataan ehdottomasti, mutta eivät ensimmäiseen tietomalliin. Kun muutaman avainkentän näyttäminen todella auttaa kertomaan tarinan, piirrän yksityiskohtaisen tietomallin: rajatun leikkeen, jossa on vain asian kannalta olennaiset kentät.
Attribuuttien pitää kuvata entiteettiä
Osio nimeltä “Attribuuttien pitää kuvata entiteettiä ”Tässä on yksinkertainen kysymys, jota käytän katsoessani attribuuttia: mitä tämä kuvaa? Kuorma-auton merkki kuvaa selvästi kuorma-autoa. Mutta entä tiimin jäsenten nimet toimituksessa? Kuvaavatko ne toimitusta? Vai kuvaavatko ne tiimiä, jolla oli tiimin osoitus, joka kattoi reitin, johon tämä pysähdys kuului?
Tässä kohtaa tietomalli alkaa paljastaa asioita, jotka näyttävät näytöllä täysin järkeviltä. Koordinaattori sanoo: ”Haluan nähdä tiimin nimet toimituksessa.” Se on pätevä käyttökokemusvaatimus. Se ei välttämättä ole vaatimus tallentaa tiimin nimet toimitukseen. Ne ovat kaksi eri asiaa, ja palaamme tähän normalisoinnin yhteydessä. Opettele toistaiseksi kysymään, mitä asiaa tämä tieto oikeasti kuvaa. Se kysymys säästää sinut monelta harmilta.
Sitten meidän on puhuttava yksilöllisistä ID:istä
Osio nimeltä “Sitten meidän on puhuttava yksilöllisistä ID:istä ”Attribuutit kuvaavat asioita. Mutta on vielä yksi ongelma ratkaistavana: mistä tiedän, mikä asia on mikä?
Kahden vastaanottajan nimi on John Smith. Ovatko he sama henkilö? Ehkä, ehkä ei. Nimi ei riitä. Osoite? Ihmiset muuttavat. Puhelinnumerot vaihtuvat. Sähköpostiosoitteet vaihtuvat. Jopa vähittäiskauppakumppanin nimi voi muuttua.
Tämä tuo meidät avaimiin: siihen, minkä avulla voimme tunnistaa jonkin asian mallissamme yksiselitteisesti. Tästä aiheesta minulle on vuosien varrella muodostunut melko vahva mielipide. Tunnisteelta haluan neljä asiaa:
Yksilöllinen. Muuttumaton. Merkityksetön. Ei koskaan henkilötietoa.
Yksilöllinen. Tunnisteen täytyy tunnistaa tasan yksi asia. Jos kahdella toimituksella voi olla sama arvo, se ei ole luotettava toimituksen tunniste. Nimet eivät yleensä ole yksilöllisiä, osoitteet eivät välttämättä ole yksilöllisiä, ja puhelinnumeroita jaetaan. Jopa arvot, jotka näyttävät tänään yksilöllisiltä, eivät ehkä ole sitä, kun tietoa on tarpeeksi. Kysy siis: voiko kahdella näistä koskaan olla sama arvo? Jos vastaus on kyllä, ole hyvin varovainen sen käyttämisessä tietueen yksilöllisenä ID:nä.
Muuttumaton. Tämä jää usein huomaamatta. Jos tunnistamme vähittäiskauppakumppanin sen nimellä ja kumppani vaihtaa nimeään, saimmeko uuden kumppanin? Emme. Liiketoimintaentiteetti pysyi samana; yksi sen attribuuteista muuttui. Tietueen yksilöllisen ID:n pitää säilyä, vaikka sen tunnistama asia muuttuu, ja se sulkee pois nimet, sähköpostiosoitteet, puhelinnumerot, osoitteet ja käyttäjätunnukset, olivatpa ne kuinka käteviä tahansa, kun järjestelmää ensimmäistä kertaa rakennetaan.
Merkityksetön. Tämä kuulostaa oudolta, kun sen kuulee ensimmäisen kerran. Miksi haluaisin tunnisteen olevan merkityksetön? Koska merkitys muuttuu. Kuvittele, että joku rakentaa toimituksen ID:n, johon on koodattu jakelukeskus, vähittäiskauppakumppani, toimituspäivä ja juokseva numero: PHX-KEY-20261002-0042. Se näyttää fiksulta. Sitten vastaanottaja siirtää toimituksen perjantaille. Muutammeko tunnistetta? Jos emme muuta, se valehtelee meille. Jos muutamme, olemme muuttaneet toimituksen yksilöllistä ID:tä, koska yksi sen attribuuteista muuttui, ja jokainen järjestelmä, joka tallensi vanhan ID:n, on juuri kadottanut sen. Tunniste yritti tehdä kahta työtä: tunnistaa toimituksen ja kuvata sitä. Annan mieluummin attribuuttien kuvata sitä ja tunnisteen tehdä yhden tylsän työn: tunnistaa se. Tylsät tunnisteet ovat hyviä tunnisteita.
Ei koskaan henkilötietoa. Tämä on niin tärkeä, että pidän sen erillään. Älä käytä henkilötietoa (PII) tunnisteena vain siksi, että se näyttää yksilölliseltä. Steve Truckingilla on houkuttelevaa tunnistaa vastaanottaja puhelinnumerosta. Mutta avain kopioituu kaikkialle, missä järjestelmien täytyy yhdistää tietueita: integraatioihin, vienteihin, lokeihin, vähittäiskauppakumppaneille palautettaviin tilatiedostoihin, tietovarastoon, testidataan. Tee puhelinnumerosta avain, ja olet levittänyt vastaanottajan henkilötiedot koko arkkitehtuuriin.
Avaimen täytyy myös olla olemassa jokaisessa tietueessa: ei koskaan null tai tyhjä. Jos jotkut ihmiset eivät anna arvoa, tai heidän ei pitäisi joutua antamaan sitä, se arvo ei voi olla avain. Siksi järjestelmät luovat omat sisäiset tunnisteensa, ja henkilötiedosta, jos sitä ylipäätään tarvitaan, tulee suojattu attribuutti.
Sääntöni on siis: yksilöllinen, muuttumaton, merkityksetön, ei koskaan henkilötietoa.
Luonnolliset avaimet ja sijaisavaimet
Osio nimeltä “Luonnolliset avaimet ja sijaisavaimet ”Tietokantaihmisillä on osalle tästä nimet. Luonnollinen avain on jo olemassa liiketoiminnan tiedoissa: kuorma-auton VIN-tunnus on hyvä esimerkki. Sovelluksemme ei keksinyt sitä, ja sillä on jo merkitys. Sijaisavain luodaan nimenomaan tietueen tunnistamista varten; se ei kuvaa mitään, se vain tunnistaa.
Useimmissa arkkitehtuureissa suosin sijaisavainta sisäisenä tietueen ID:nä ja pidän tärkeät luonnolliset tunnisteet attribuutteina. Se ei tee luonnollisista tunnisteista huonoja; ne ovat usein äärimmäisen tärkeitä. En vain automaattisesti tee niistä tietueen yksilöllistä ID:tä. Kysy, mitä tapahtuu, jos arvo korjataan, muotoillaan uudelleen, korvataan, käytetään uudelleen, puuttuu tai saapuu useammasta kuin yhdestä lähdejärjestelmästä. Siinä kohtaa yksinkertaiselta näyttävästä päätöksestä tulee arkkitehtuuripäätös.
Yhdellä asialla voi olla useita hyödyllisiä tunnisteita
Osio nimeltä “Yhdellä asialla voi olla useita hyödyllisiä tunnisteita ”Sisäinen tietueen ID ei välttämättä ole se tunniste, jota kaikki muut järjestelmät käyttävät. Steve Trucking voi tunnistaa toimituksen sisäisesti generoidulla ID:llä. Jokainen vähittäiskauppakumppani tuntee saman toimituksen omalla tilausnumerollaan: Keystone CSV-kuormaluettelossaan, Redrock API:ssaan, Brightwave EDI-sanomissaan. Ja vanhan ajojärjestelytyökalun RouteDeskin kahdeksan vuoden historia käyttää RouteDeskin omia toimitus-ID:itä.
Nuo tunnisteet ovat tärkeitä. Meidän täytyy säilyttää ne ja kohdistaa ne oikein, koska tilapäivitys on palautettava jokaiselle kumppanille sen numerolla. Mutta kaikista niistä ei tarvitse tulla toimituksen yksilöllistä ID:tä. Kysymykseen ”mikä sen ID on?” voi olla useampi kuin yksi vastaus, ja arkkitehdin täytyy tietää, mikä ID on auktoritatiivinen missäkin yhteydessä. Palaamme tähän perustietojen ja integraation yhteydessä.
Suhteet riippuvat yksilöllisistä ID:istä
Osio nimeltä “Suhteet riippuvat yksilöllisistä ID:istä ”Palataan nyt piirtämiimme viivoihin. Kuormaluettelossa luetellaan toimitukset. Vastaanottaja vastaanottaa toimituksia. Tiimillä on tiimin osoituksia. Nuo suhteet toimivat vain, koska pystymme tunnistamaan luotettavasti asiat molemmissa päissä.
Tässä kohtaa se puree Steve Truckingilla. Vähittäiskauppakumppani muuttaa kuormaluetteloaan toimituspäivänä: tilaus peruttu, tuote vaihdettu, uusi osoite. Jos emme pysty kohdistamaan muutettua riviä jo olemassa olevaan toimitukseen kumppanin tilausnumeron perusteella, luomme toisen toimituksen samalle jääkaapille, ja tiimi saattaa tulla paikalle kahdesti. Laatikot, attribuutit, avaimet ja suhteet eivät ole erillisiä ideoita. Ne ovat kaikki saman mallin osia.
Tässä vaiheessa saatat ajatella: ”Salesforce antaa jokaiselle tietueelle ID:n.” Aivan oikein, ja pääsemme siihen. Jos tiedot asuvat Salesforcessa, jokainen tietue saa Salesforcen generoiman ID:n. Se on kryptinen ja vaikealukuinen, joten tavallisesti tarjoamme myös ID-kentän, jota ihmiset voivat käyttää, kuten toimitusnumeron D-000184227, joka on Auto Number -kenttä. Ihmiset luulevat usein, että se numero on tietueen ID, mutta ei se ole: Salesforcen ID on yhä olemassa sen alla. Ulkoisella järjestelmällä tai tietokannalla, Oraclella tai SQL Serverillä, on myös omat yksilölliset ID:nsä. Mutta arkkitehtuuriin voi lopulta kuulua Salesforce, talouden ERP, Snowflake, Data 360, kumppanien järjestelmät ja järjestelmiä, joita ei vielä ole olemassa. Looginen malli kuvaa liiketoiminnan tiedot tekemättä jokaista päätöstä riippuvaiseksi yhdestä teknologiasta. Se, miten Salesforce sen fyysisesti toteuttaa, on myöhempi vaihe.
Mitä arkkitehti tässä päättää
Osio nimeltä “Mitä arkkitehti tässä päättää ”Kun muutan käsitteellisen mallin loogiseksi malliksi, päätän:
- Mitkä attribuutit oikeasti kuvaavat kutakin entiteettiä.
- Miten kukin entiteetti tunnistetaan yksiselitteisesti ja onko se tunniste tarpeeksi vakaa ollakseen sen yksilöllinen ID.
- Mitkä liiketoiminnan tunnisteet (kumppanien tilausnumerot, vanhojen järjestelmien ID:t) täytyy säilyttää ja kohdistaa.
- Käytetäänkö arkaluonteista tietoa avaimena.
- Yhdistävätkö suhteet entiteetit luotettavien yksilöllisten ID:iden kautta.
Meillä on nyt entiteetit, suhteet, attribuutit ja yksilölliset ID:t: oikean loogisen tietomallin alku. Mutta yksi ongelma on vielä jäljellä. On hyvin helppoa laittaa täysin pätevää tietoa väärään paikkaan. Siinä kohtaa normalisointi tulee mukaan.
Lue lisää
Osio nimeltä “Lue lisää ”- Custom Field Types (opens in a new tab), Salesforce Help (englanniksi, tarkistettu 2026-10-09): Auto Number antaa jokaiselle tietueelle yksilöllisen numeron näyttömuodolla, kuten etuliitteellä ja etunollilla; se ei ole tietueen Salesforce-ID. Katso myös Auto-Number Fields Are Not Always Sequential (opens in a new tab) (englanniksi, tarkistettu 2026-10-09).