Piirrä suhteet
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 2/6 luvussa Tietojen mallintaminen merkityksen kautta, Data Architect -kurssin luku 2. Jokainen moduuli on itsenäinen. Edellinen: Kuuntele substantiiveja · Seuraava: Rakenna looginen malli
Kysymys, johon tämä moduuli vastaa: Miten muutan ehdokasentiteetit käsitteelliseksi tietomalliksi?
Meillä on substantiivit taululla. Nyt haluan tietää laatikoiden välisistä viivoista, koska kokoelma entiteettejä ei vielä oikeastaan ole tietomalli. Suuri osa merkityksestä asuu suhteissa. Vähittäiskauppakumppani ylläpitää jakelukeskuksia. Kuormaluettelossa luetellaan toimitukset. Toimitus menee vastaanottajalle. Tiimi ajaa kuorma-autoa. Jokainen näistä lauseista kertoo minulle jotain liiketoiminnasta, ja jokainen antaa minulle uuden kysymyksen kysyttäväksi.
Aloita liiketoiminnan kielestä
Osio nimeltä “Aloita liiketoiminnan kielestä ”En vieläkään halua puhua Salesforcesta. En kysy, pitäisikö tämän olla lookup- vai master-detail-suhde, en mieti Salesforcen liitosobjekteja (Salesforce Junction Object) enkä päätä, mitä tapahtuu, kun päätietue poistetaan. Yritän ymmärtää liiketoiminnan suhdetta.
Otetaan lause ”vähittäiskauppakumppani ylläpitää jakelukeskuksia”. Se kuulostaa yksinkertaiselta. Mutta onko vähittäiskauppakumppanilla yksi jakelukeskus vai monta? Steve Truckingilla jokainen vähittäiskauppakumppani ylläpitää alueellista jakelukeskusta jokaisella alueella, jota Steve Trucking palvelee, joten monta. Voiko jakelukeskus kuulua useammalle kuin yhdelle vähittäiskauppakumppanille? Onko jakelukeskuksella merkitystä sellaisenaan, omine henkilökuntineen ja historioineen, vai onko se pelkkä osoite? Jos vähittäiskauppakumppani lähtee, välitämmekö yhä sen jakelukeskuksista?
Nuo eivät ole Salesforce-kysymyksiä. Ne ovat liiketoimintakysymyksiä, ja vastaukset voivat muuttaa mallin täysin.
Lue viivat
Osio nimeltä “Lue viivat ”Ennen kuin menemme syvemmälle, haluan antaa sinulle kielen, jota käytämme tästä eteenpäin jokaisessa kaaviossa. Se on pieni. Kahden laatikon välinen viiva kertoo, että asiat liittyvät toisiinsa, ja sen päiden merkinnät kertovat, kuinka monta.
Aloita pelkästä viivasta, ilman merkintöjä. Siitä minä aloitan valkotaululla: tiedän, että nämä kaksi substantiivia liittyvät toisiinsa, en vain ole vielä kysynyt, miten. Sitten päät saavat merkinnät. Yksi poikkiviiva viivan yli tarkoittaa yhtä. Variksenjalka (crow’s foot), pää joka haarautuu kolmeen kuin linnun jalka, tarkoittaa montaa. Myöhemmin tässä moduulissa näet ensimmäisen merkinnän viereen ilmestyvän toisen, poikkiviivan tai ympyrän, ja se vastaa eri kysymykseen: voiko niitä olla nolla?
Yksi sääntö muistettavaksi: luet jokaisen merkinnän sen laatikon kohdalta, jota se koskettaa. Laatikkoa lähinnä oleva merkintä on suurin mahdollinen määrä; seuraava merkintä ulompana on pienin.
Istu, paikka, mallinna
Osio nimeltä “Istu, paikka, mallinna ”Ennen Steve Truckingia palataan moduulin 1 koiriin. Meillä oli viisi laatikkoa: omistaja, kasvattaja, koira, rotu ja temppu. Nyt kysyn niiden välisistä viivoista.
Yksi vai monta? Omistajalla voi olla useampi kuin yksi koira; Analla on kaksi. Koiralla on yksi omistaja, ainakin meidän mallissamme. Se on yhden suhde moneen: poikkiviiva omistajan päässä, variksenjalka koiran päässä. Kasvattaja on samanmuotoinen: yksi kasvattaja kasvattaa monta koiraa.
Voiko niitä olla nolla? Max tuli löytöeläinkodista, joten sillä ei ole kasvattajaa lainkaan. Kasvattajan pää saa ympyrän: koiralla on nolla tai yksi kasvattaja. Jokaisella koiralla on kuitenkin omistaja, joten se pää saa toisen poikkiviivan: tasan yksi.
Monta moneen? Koira osaa monta temppua, ja tempun, vaikkapa Istu, osaa moni koira. Se on monen suhde moneen, ja juuri sieltä lähden etsimään piilossa olevaa käsitettä. Onko jotain, mikä koskee sitä, että tämä koira osaa tämän tempun? Kuinka hyvin se tekee sen ja milloin se oppi sen. Suhteella on omia tietojaan, joten siitä tulee oma asiansa: koiran temppu (Dog Trick), koira nimessä ensin, koska koira on se, joka sitä ohjaa.
Mitä kukin viiva tarkoittaa? Omistaja omistaa koiran. Kasvattaja kasvattaa sen. Koira osaa temppunsa. Nimeä viivat, niin kuka tahansa osaa lukea mallin takaisin sinulle.
Nyt vai ajan mittaan? Välittääkö kukaan siitä, kuinka hyvä Bella on Istu-tempussa tänään, vai siitä, miten se pääsi siihen? Jos kouluttaja tarkistaa sen muutaman kuukauden välein, jokainen tarkistus on oma tietueensa: tempun arviointi (Trick Assessment), jossa on päivämäärä, taitotaso ja tarkistaja, sen koiran tempun alla, johon se kuuluu. Jopa suhteella, josta tuli oma asiansa, voi olla oma historiansa.
Rodun jätän toistaiseksi yhdistämättä. Se on yhä moduulin 1 kysymys, oma laatikkonsa vai koiraan kirjoitettu sana, ja moduuli 4 ratkaisee sen.
Jokainen näistä kysymyksistä toimii samalla tavalla oikeassa liiketoiminnassa. Kysytään ne nyt Steve Truckingilta.
Kysy: ”Yksi vai monta?”
Osio nimeltä “Kysy: ”Yksi vai monta?” ”Yksi ensimmäisistä asioista, jotka haluan ymmärtää suhteesta, on sen kardinaliteetti. Se on tietokantatermi; itse kysymys on paljon yksinkertaisempi: kuinka moni näistä voi liittyä kuinka moneen noista? Käsitteellisellä tasolla on kolme perusmallia.
Tämä on prosessin tärkeä vaihe: ota kaksi eri substantiivia ja ymmärrä niiden suhde. Useimmiten se on yhden suhde moneen tai monen suhde yhteen. Vain harvoin törmäät yhden suhteeseen yhteen.
Yhden suhde moneen on kaikkialla. Yhdellä vähittäiskauppakumppanilla on monta jakelukeskusta. Yhdessä kuormaluettelossa luetellaan monta toimitusta. Yhdellä reitillä on noin kymmenen pysähdystä. Kun kuulen tuollaista kieltä, alan piirtää viivaa.
Ja nyt viiva saa merkintänsä. Kumpikin pää kertoo, kuinka monta on sitä laatikkoa, jota se koskettaa: poikkiviiva tarkoittaa yhtä, variksenjalka montaa. Lue se kummankin laatikon kohdalta: yhdellä vähittäiskauppakumppanilla on monta jakelukeskusta.
Yhden suhteita yhteen on olemassa, mutta ne ovat harvinaisia, ja kun löydän sellaisen, kysyn muutaman kysymyksen. Ovatko nämä todella kaksi eri substantiivia vai sama? Jos ne ovat eri, mikä niiden välinen yhden suhde yhteen on? Ja onko se aina yhden suhde yhteen, vai vain juuri nyt? Nämä ovat tietomallin suunnittelun avainkysymyksiä. Tiimi ja kuorma-auto näyttävät minä tahansa aamuna yhden suhteelta yhteen: kaksi ihmistä, yksi kuorma-auto, yksi reitti. Kuukauden aikana eivät, ja juuri siellä piilee tämän mallin kiinnostavin suhde.
Monen suhteet moneen ovat erityisen kiinnostavia, koska ne kertovat usein, että liiketoiminnassa on vielä yksi käsite. Voiko tiimi ajaa useampaa kuin yhtä kuorma-autoa ajan mittaan? Kyllä. Voiko kuorma-autoa ajaa useampi kuin yksi tiimi? Sen elinkaaren aikana varmasti. Tiimeillä ja kuorma-autoilla on siis monen suhde moneen. Mutta nyt haluan tietää enemmän. Välittääkö liiketoiminta siitä, milloin tiimillä oli kuorma-auto? Mille reitille, minä päivänä? Kuka teki osoituksen? Jos suhde itse kantaa tietoa, josta välitämme, olemme löytäneet uuden liiketoimintakäsitteen: tiimin osoituksen (Crew Assignment).
Se on tärkeä mallinnustapa. Joskus kiinnostavin asia ei ole yksikään alussa kuulemistamme substantiiveista. Se piileskelee kahden substantiivin välisessä suhteessa.
Suhteista voi tulla asioita
Osio nimeltä “Suhteista voi tulla asioita ”Tämä on yksi kohdista, joissa haluan ylläpitäjien alkavan ajatella toisin. Salesforcessa olemme tottuneet puhumaan objekteista ja kentistä, joten on helppo pitää laatikoita tärkeänä osana ja viivoja pelkkänä putkistona. Mutta suhteella itsellään voi olla liiketoiminnallinen merkitys.
Ajatellaan toimitusta ja sen tuotteita. Toimituksessa voi olla useita tuotteita, vaikkapa pesukone ja kuivausrumpu. Tuote, sama jääkaappimalli, esiintyy tuhansissa toimituksissa. Tähän asti helppoa. Mutta entä jos minun pitää tietää, kuinka monta kappaletta tuotetta tässä toimituksessa on, asennetaanko se tai viedäänkö vanha pois? En ole enää kiinnostunut pelkästä toimituksen ja tuotteen välisestä suhteesta. Olen kiinnostunut toimitusrivistä (Delivery Item), ja se käsite ansaitsee oman entiteettinsä.
Jos tulet Salesforcen parista, saatat jo ajatella: ”Tuohan on liitosobjekti.” Et ole väärässä. Mutta en halua aloittaa siitä. Toimitusrivi on liiketoimintakäsite ennen kuin se on Salesforcen liitosobjekti (Salesforce Junction Object). Liiketoiminta ensin, toteutus sitten.
Muutama tapani näille suhde-entiteeteille, missä ne sitten lopulta rakennetaankin.
Nimeä se. Jos liiketoiminnalla on sille jo sana, käytä heidän sanaansa. Jos ei ole, ota kahden päätietueen nimet ja yhdistä ne. Ajattele tilausta ja tuotetta. Niiden välissä oleva asia on tilausrivi (Order Item): tilaus ja tilauksessa oleva tuote. Se on kummankin päätietueen alitietue, ja Salesforcessa siitä voi tulla Salesforcen liitosobjekti. Mutta kumpi nimi tulee ensin: Item Order vai Order Item? Katso, minkälaisia tietoja kumpikin päätietue on. Tuote on viitetietoa; tilaus on tapahtumatietoa, ja tilaus on se, joka sitä ohjaa. Siksi Order Item tai Order Product, samaan tapaan kuin Salesforcessa on Opportunity Product. Steve Truckingilla se on toimitusrivi (Delivery Item). Ohjaava nimi tulee ensin, ja tietue lajittuu omistajansa viereen jokaisessa luettelossa, jota koskaan katsot.
Anna sille oma avain. On houkuttelevaa sanoa, että toimitusrivi tunnistetaan toimituksen ja tuotteen yhdistelmällä, ja jättää asia siihen. Se on yhdistelmäavain, ja yhdistelmäavaimia on paljon vaikeampi käsitellä: jokaisen tietueeseen viittaavan järjestelmän on kannettava molempia puolikkaita. Anna suhde-entiteetille oma tunnisteensa ja pidä toimitus plus tuote yksilöllisyyttä koskevana sääntönä, ei tunnisteena.
Huomaa, mitä siinä ei ole: sarjanumeroa. Määrä ja sarjanumero eivät kuulu samaan tietueeseen. Määrä laskee useita kappaleita jotain; sarjanumero tunnistaa yhden tietyn kappaleen. Jos liiketoiminta tarvitsee sarjanumeroita, jokaisesta yksiköstä tulee oma tietueensa, ja viisi jääkaappia on viisi tietuetta. En keksi tilannetta, jossa toimitusrivin alla olisi toimitusrivin erittely. Se on joko tai: kooste, jossa on määrä, tai yksi tietue yksikköä kohden. Tässä se on määrä.
Seuraa attribuutteja, jotka kaipaavat historiaa. Jotkin suhde-entiteetit ovat valmiita heti, kun ne luodaan: tämän toimituksen pesukone pysyy tämän toimituksen pesukoneena. Toiset muuttuvat jatkuvasti. Tiimillä on tällä viikolla kuorma-auto 117, ja ensi viikolla kuorma-auto siirtyy toiselle tiimille. Kun suhde muuttuu ja liiketoiminta välittää siitä, mitä se oli ennen, suhde-entiteetti tarvitsee päivämäärät, ja tiimin osoitus on se, jota kannattaa seurata. Kysy ajoissa, välittääkö liiketoiminta nykyhetkestä vai ajan mittaan tapahtuvasta; palaamme tähän hetken päästä.
Suhteilla on merkitystä kardinaliteetin lisäksi
Osio nimeltä “Suhteilla on merkitystä kardinaliteetin lisäksi ””Yhden suhde moneen” ei riitä suhteen ymmärtämiseen. Haluan tietää myös, mitä suhde tarkoittaa.
Toimituksella on sijainti. Mikä sijainti? Jakelukeskus, josta se lähtee? Vastaanottajan koti, johon se menee? Ne eivät ole keskenään vaihdettavissa. Kahdessa mallissa voi olla täsmälleen samat laatikot ja sama kardinaliteetti, ja viivat voivat silti tarkoittaa aivan eri asioita. Siksi hyvä malli ei ole pelkkiä viivoilla yhdistettyjä laatikoita. Viivat tarvitsevat nimet. Jos annan kaavioni toiselle arkkitehdille, hänen ei pitäisi joutua arvaamaan, mitä suhde tarkoittaa, ja jos näytän sen liiketoiminnalle, siinä pitäisi käyttää kieltä, jonka he tunnistavat.
Myös valinnaisuudella on väliä
Osio nimeltä “Myös valinnaisuudella on väliä ”Kysymyksen ”kuinka monta?” sisällä piilee toinen kysymys: onko suhde pakollinen? Voiko toimitus olla olemassa ennen kuin se on lisätty reitille? Sen täytyy voida: kuormaluettelo saapuu päivää tai kahta ennen toimitusta, ja reitit lyödään lukkoon edellisenä iltana. Voiko toimitus olla olemassa ilman vähittäiskauppakumppania? Ei; jokainen toimitus tulee jonkin kumppanin kuormaluettelosta. Se on valinnaisuutta.
Älä taaskaan hyppää suoraan Salesforcen Required (pakollinen) -valintaruutuun. On eri asia sanoa ”jokaisella toimituksella on oltava vähittäiskauppakumppani” kuin sanoa ”Salesforcen pitäisi vaatia vähittäiskauppakumppanikenttä, kun tietue luodaan”. Ne voivat päätyä samaksi toteutukseksi, mutta ne eivät ole sama väite. Ensimmäinen on liiketoimintasääntö; toinen on yksi tapa valvoa sitä. Arkkitehteina haluamme ymmärtää ensimmäisen ennen kuin päätämme toisesta.
Kaaviossa valinnaisuus on kunkin pään toinen merkintä. Laatikkoa lähinnä oleva merkintä on suurin mahdollinen määrä: poikkiviiva yhdelle, variksenjalka monelle. Seuraava merkintä ulompana on pienin: toinen poikkiviiva tarkoittaa vähintään yhtä, ympyrä tarkoittaa, että niitä voi olla nolla. Jokainen toimitus on siis tasan yhdessä kuormaluettelossa, ja kuormaluettelossa luetellaan yksi tai monta toimitusta. Toimitus on nollassa tai yhdessä pysähdyksessä, ei missään ennen kuin se on reititetty, ja pysähdyksessä jätetään nolla tai monta toimitusta.
Aika muuttaa suhteita
Osio nimeltä “Aika muuttaa suhteita ”Tässä on kysymys, jota kysyn paljon: tarkoitatko nyt vai ajan mittaan?
Tiimi ajaa kuorma-autoa. Juuri nyt? Tämän päivän reitillä? Niin kauan kuin nuo kaksi ihmistä työskentelevät yhdessä? Niistä syntyy eri malleja. Jos liiketoimintaa kiinnostaa vain se, mikä kuorma-auto tiimillä on tänään, malli voi pysyä yksinkertaisena. Jos sen täytyy tietää jokainen kuorma-auto, jota tiimi on ajanut, milloin ja millä reitillä, tarvitsemme historiaa, ja löytämästämme tiimin osoituksesta tulee yhtäkkiä hyvin tärkeä.
Tämä on yleinen mallinnusvirheiden lähde. Mallinnamme nykytilan, koska sen näemme näytöllä. Sitten viikkoja myöhemmin vähittäiskauppakumppani tekee vahinkoilmoituksen, ja joku kysyy: ”Millä tiimillä oli kuorma-auto 117 maaliskuun 17. päivänä?” Ja huomaamme, että olemme kirjoittaneet vastauksen päälle aina, kun osoitus on muuttunut.
Yksi tapa säilyttää tuo historia on tehdä osoituksesta oma tietueensa. Kun tiimi osoitetaan, luomme tiimin osoituksen, jolla on alkupäivä. Kun osoitus muuttuu, merkitsemme vanhaan tietueeseen loppupäivän ja luomme uuden, jolla on oma alkupäivänsä. Nyt kysymykseen ”kenellä oli tuo osoitus kuusi kuukautta sitten?” on helppo vastata, eikä tarvitse kaivaa kenttähistoriaa tai tietomuutosten lokia. Ja kun tiimillä on ollut monta osoitusta, joku kysyy, mikä niistä on nykyinen, joten lisäisin myös Active-lipun (aktiivinen).
Kun joku siis kertoo minulle suhteesta, en kysy vain, miten asiat liittyvät toisiinsa. Kysyn: muuttuuko suhde, ja välitämmekö sen historiasta?
Piirrä ennen kuin konfiguroit
Osio nimeltä “Piirrä ennen kuin konfiguroit ”Steve Truckingin mallistamme on tulossa hyödyllinen. Tiedämme, mitkä suhteet ovat yhden suhteita moneen, missä monen suhde moneen kätkee toisen käsitteen, mitkä suhteet ovat valinnaisia ja mitkä muuttuvat ajan mittaan. Emmekä ole vieläkään luoneet yhtään Salesforce-objektia. Se on tarkoituksellista.
Tämän kaavion pitäisi olla jotain, minkä voin laittaa liiketoiminnan eteen, eikä heidän pitäisi tarvita Salesforce-osaamista kertoakseen, onko se oikein. Jos he eivät pysty vahvistamaan sitä, koska se on täynnä Salesforce-terminologiaa, olen siirtynyt liian nopeasti fyysiseen suunnitteluun.
Mitä arkkitehti tässä päättää
Osio nimeltä “Mitä arkkitehti tässä päättää ”Kun käyn läpi käsitteellisen mallin suhteita, päätän:
- Miten tärkeimmät liiketoimintaentiteetit liittyvät toisiinsa.
- Onko kukin suhde yhden suhde yhteen, yhden suhde moneen vai monen suhde moneen, nyt ja ajan mittaan.
- Onko kukin suhde pakollinen vai valinnainen.
- Kätkeekö monen suhde moneen merkityksellisen liiketoimintakäsitteen.
- Muuttuuko suhde ajan mittaan, ja tarvitsemmeko sen historian.
Lookup vai master-detail, liitosobjektin konfigurointi, ketjupoistot ja jakaminen ovat fyysisiä päätöksiä; pääsemme niihin. Juuri nyt vastaamme yhä tärkeämpään kysymykseen: miten tämä liiketoiminta oikeasti toimii? Kun ymmärrämme entiteetit ja niiden väliset suhteet, voimme alkaa lisätä niitä kuvaavia yksityiskohtia. Silloin käsitteellisestä mallistamme alkaa tulla looginen tietomalli.