Tietojen mallintaminen merkityksen kautta
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 2 opiskeluopas Data Architect -kurssilla. Lue ensin kuusi 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ämä luku on perusta kokeen osiolle Data Modeling and Database Design (tietomallinnus ja tietokantasuunnittelu), joka on neljännes kokeesta. Se käsittelee ajattelua; seuraava luku, Salesforcen tietoarkkitehtuuri, käsittelee sitä, miten alusta sen rakentaa. Suurin osa siitä, mitä objekteista, kentistä ja suhteista testataan, vaatii siis molemmat luvut.
Koetta varten
Osio nimeltä “Koetta varten ”Tämän luvun kohdat, joilla on todennäköisimmin merkitystä kokeessa. Jokainen on sidottu kokeen tavoitteeseensa ja linkittää paikkaan, jossa asia opetetaan. Rastita ne sitä mukaa kuin etenet.
DM-1: tekniikoiden vertailu Salesforce-tietomallin suunnittelussa
- Osaan selittää eron käsitteellisen, loogisen ja fyysisen tietomallin välillä ja sen, mihin kutakin käytetään. (Muuta malli Salesforceksi)
- Löydän vaatimuksesta ehdokasentiteetit ja erotan työtä tekevän henkilön tiedosta. (Substantiivit antavat sinulle ehdokasentiteetit)
- Osaan lukea ja piirtää variksenjalkanotaatiota (crow’s foot): yksi, monta ja toinen merkintä valinnaiselle tai pakolliselle. (Lue viivat, Myös valinnaisuudella on väliä)
- Osaan nimetä suhteen kardinaliteetin: yhden suhde yhteen, yhden suhde moneen, monen suhde moneen. (Kysy: ”Yksi vai monta?”)
- Tiedän, että monen suhteesta moneen tulee oma entiteettinsä, ja Salesforcessa yleensä liitosobjekti (junction object), jolla on kaksi päätietuetta. (Suhteista voi tulla asioita)
- Tiedän, milloin suhde tarvitsee historiaa (tietueen, jolla on alku- ja loppupäivä) eikä kenttää, joka kirjoitetaan yli. (Aika muuttaa suhteita)
- Osaan valita hyvän yksilöllisen ID:n, ja tiedän, miksi luonnollinen avain tai mikä tahansa henkilötietoa sisältävä on riskialtis. (Sitten meidän on puhuttava yksilöllisistä ID:istä)
- Tiedän eron luonnollisen avaimen ja sijaisavaimen välillä ja sen, että yhdellä tietueella voi olla useita ulkoisia tunnisteita. (Luonnolliset avaimet ja sijaisavaimet)
- Tiedän, että Auto Number -kenttä on luettava numero eikä tietueen Salesforce-ID. (Suhteet riippuvat yksilöllisistä ID:istä)
- Osaan soveltaa ensimmäistä, toista ja kolmatta normaalimuotoa ja huomaan kentän, jossa on useita arvoja tai joka toistaa tietoa jostain muusta. (Yksinkertainen tapa ajatella 1NF:ää, 2NF:ää ja 3NF:ää)
- Osaan selittää, milloin denormalisoida tarkoituksella (käyttäjät, raportointi, mittakaava) ja mitä se maksaa. (Suunnittele kolmanteen normaalimuotoon ja peräänny sitten)
- Osaan valita arvoluettelolle valintaluettelon tai lookupin objektiin. (Lookup vai valintaluettelo?)
- Tiedän, että mukautettu raporttityyppi sallii enintään neljä objektisuhdetta, ja miksi sillä on merkitystä syville malleille. (Lookup vai valintaluettelo?)
- Tiedän, milloin master-detail sopii (alitietuetta ei koskaan siirretä toiselle päätietueelle) ja milloin lookup on turvallisempi, mukaan lukien Salesforcen ohje enintään 10 000 alitietueesta yhdellä päätietueella. (Suhteista tulee alustapäätöksiä)
- Tiedän, miksi polymorfisia suhteita kannattaa välttää aina kun voin. (Suhteista tulee alustapäätöksiä)
- Tiedän, että liiketoimintaentiteetti ei automaattisesti tarkoita mukautettua objektia: se voi olla vakio-objekti, kenttä, konfiguraatiota tai tietoa, joka asuu Salesforcen ulkopuolella. (Liiketoimintaentiteetti ei automaattisesti tarkoita mukautettua objektia)
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.
- Unohda Salesforce hetkeksi. Mallinna liiketoiminta ennen kuin kohdistat sen tiliin ja yhteyshenkilöön.
- Kuuntele sanaa, joka kätkee kaksi asiaa. Steve Truckingilla ”asiakas” oli sekä vähittäiskauppakumppani että vastaanottaja.
- Malli on osa keskustelua. Ensimmäisen mallisi ei ole tarkoitus olla oikea; sen tarkoitus on näyttää, missä olet väärässä.
- Nimeä viivat. Kaksi mallia, joissa on samat laatikot, voivat tarkoittaa eri asioita.
- Kysy ”nyt vai ajan mittaan?” jokaisesta suhteesta.
- Yksilöllinen, muuttumaton, merkityksetön, ei koskaan henkilötietoa.
- Sijoita tieto sinne, minne se kuuluu, peräänny sitten tarkoituksella ja kirjaa ylös miksi.
- Denormalisointi ei poista monimutkaisuutta; se siirtää sitä. Tiedä, kuka omistaa totuuden.
- Yksi totuuden lähde, monta muotoa: näytöt, raportit, tietovarasto ja tekoäly.
- Älä suunnittele Setupista käsin. Piirrä malli ennen kuin klikkaat New Custom Object.
- Jäljitä jokainen fyysinen päätös takaisin johonkin, mitä liiketoiminta tarvitsee.
Tärkeät termit
Osio nimeltä “Tärkeät termit ”| Termi | Yhdellä rivillä |
|---|---|
| Entiteetti | Asia, josta liiketoiminta välittää ja josta se säilyttää tietoja |
| Ehdokasentiteetti | Substantiivi, josta voi tulla entiteetti, kun olet kysynyt siitä |
| Attribuutti | Tieto, joka kuvaa entiteettiä |
| Suhde | Miten kaksi entiteettiä liittyvät toisiinsa, liiketoiminnan kielellä nimettynä |
| Kardinaliteetti | Kuinka moni yhtä liittyy kuinka moneen toista |
| Valinnaisuus | Onko suhde pakollinen vai voiko niitä olla nolla |
| Variksenjalka (crow’s foot) | ”Monen” merkintä viivan päässä |
| Liitosobjekti (junction object) | Salesforcen tapa rakentaa monen suhde moneen: kummankin päätietueen alitietue |
| Käsitteellinen malli | Mitä liiketoiminnassa on olemassa ja miten se liittyy toisiinsa; ei Salesforcea |
| Looginen malli | Tiedot: attribuutit, yksilölliset ID:t ja suhteet, yhä sitomatta alustaan |
| Fyysinen malli | Miten alusta sen rakentaa: objektit, kentät ja suhdetyypit |
| Luonnollinen avain | Tunniste, joka on jo olemassa liiketoiminnassa, kuten kuorma-auton VIN-tunnus |
| Sijaisavain | Tunniste, joka on luotu vain tietueen tunnistamista varten |
| Ulkoinen tunniste | Toisen järjestelmän ID samalle tietueelle, säilytettynä ja kohdistettuna |
| Normalisointi (1NF, 2NF, 3NF) | Jokaisen tiedon sijoittaminen sinne, minne se kuuluu: yksi arvo kenttää kohden, tiedot koko avaimesta, ei tietoja muista tiedoista |
| Denormalisointi | Tietojen kopioiminen tai litistäminen tarkoituksella, syystä jonka osaat nimetä |
| Päivitysanomalia | Sama tieto tallennettuna moneen paikkaan, joten yksi muutos jättää osan kopioista vääriksi |
Testaa itsesi
Osio nimeltä “Testaa itsesi ”Lyhyitä skenaarioita kurssin tyyliin. Päätä vastauksesi ennen kuin avaat sen.
1. Liiketoiminta kertoo, että tiimi ajaa kuorma-autoa. Kuusi viikkoa myöhemmin joku kysyy, millä tiimillä oli kuorma-auto 117 tiettynä päivänä. Mitä mallissa olisi pitänyt olla?
Tiimin osoitus: tiimin ja kuorma-auton välinen suhde omana tietueenaan, jossa on alkupäivä, loppupäivä ja reitti. Tiimit ja kuorma-autot ovat ajan mittaan monen suhteessa moneen, ja liiketoiminta välittää historiasta. Kuorma-auton kenttä olisi kirjoitettu yli. Lue uudelleen Aika muuttaa suhteita.
2. Tiimi ehdottaa kunkin vastaanottajan puhelinnumeron käyttämistä yksilöllisenä ID:nä, ”koska se on yksilöllinen”. Mitä sanot?
Se ei läpäise testejä: puhelinnumerot vaihtuvat ja niitä jaetaan, joten se ei ole muuttumaton eikä luotettavasti yksilöllinen, ja se on henkilötietoa, joka kopioituisi jokaiseen tietueeseen linkittyvään järjestelmään. Käytä merkityksetöntä generoitua ID:tä ja pidä puhelinnumero attribuuttina. Lue uudelleen Sitten meidän on puhuttava yksilöllisistä ID:istä.
3. Toimituksella on kentät Tuote 1, Tuote 2 ja Tuote 3. Saapuu toimitus, jossa on neljä tuotetta. Mikä on todellinen ongelma, ja miten se korjataan?
Malli piilotti toistuvan rakenteen kenttien sisään (ensimmäisen normaalimuodon ongelma). Korjaus ei ole Tuote 4 -kenttä; se on toimitusrivi-entiteetti, toimituksen alitietue, jolloin jokainen tuote on tietue. Lue uudelleen Ensimmäinen normaalimuoto.
4. Jokaiseen toimitukseen tallennetaan jakelukeskuksen esihenkilön nimi. Esihenkilö vaihtuu. Mikä meni vikaan?
Jostain muusta (jakelukeskuksesta) kertova tieto tallennettiin toimitukseen: kolmannen normaalimuodon ongelma, ja nyt päivitysanomalia sadoissa tietueissa. Esihenkilö kuuluu jakelukeskukselle; toimitus osoittaa jakelukeskukseen. Lue uudelleen Kolmas normaalimuoto.
5. Pysähdyksen laji (pelkkä toimitus, asennuksen kanssa, poisviennin kanssa) tarvitsee keston, tiimin taidot ja tarkistuslistan. Valintaluettelo vai objekti?
Objekti. Siinä on tietoa useamman kuin yhden sarakkeen verran, liiketoiminta hallitsee sitä ja se muuttuu omassa tahdissaan. Toimituksen tila, lyhyt ja vakaa nimiöiden luettelo, pysyy valintaluettelona. Lue uudelleen Lookup vai valintaluettelo?.
6. Kumppanit haluavat täsmällisyyden tuloskortin alueittain, ja alue asuu jakelukeskuksessa. Kopioit alueen jokaiseen toimitukseen. Mitä sinun täytyy päättää?
Kuka omistaa totuuden, miten kopio pysyy synkronissa ja pitäisikö vanhojen toimitusten säilyttää alue, joka oli voimassa niiden tapahtuessa, vai seurata jakelukeskusta, jos se siirtyy. Denormalisointi siirsi monimutkaisuutta; se ei poistanut sitä. Lue uudelleen Joskus raportointi voittaa.
7. Istu-tempun kaltainen temppu voisi liittyä satoihin tuhansiin lemmikkeihin. Master-detail vai lookup lemmikin tempusta temppuun?
Lookup. Salesforcen ohje on enintään 10 000 alitietuetta yhdellä päätietueella, ja suosittu temppu ylittäisi sen. Master-detail sopii lemmikin tempusta lemmikkiin, koska lemmikin temppua ei koskaan siirretä toiselle päätietueelle ja yksi lemmikki osaa vain muutaman tempun; se on myös se, minkä avulla lemmikki voi koota osatut temput -laskurinsa. Lue uudelleen Istu, paikka, mallinna.
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.