Enemmän kuin tietokanta

🌐 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 1/10 luvussa Salesforcen tietoarkkitehtuuri, Data Architect -kurssin luku 3. Jokainen moduuli on itsenäinen. Seuraava: Katso emoalukseen: vakiotietomallit

Kysymys, johon tämä moduuli vastaa: Mikä tekee Salesforcesta erilaisen kuin perinteinen tietokanta?

Jos olet ollut Salesforce-ylläpitäjä jo jonkin aikaa, osaat jo luoda objektin. Setup, Object Manager, New Custom Object. Annat sille nimen, lisäät muutaman kentän, rakennat sivuasettelun, ja kymmenen minuutin päästä käyttäjät voivat työskennellä sen kanssa.

Mutta mitä oikeastaan tapahtui, kun napsautit Save (Tallenna)?

Jos taustasi on tietokannoissa, kuvittelet luultavasti, että Salesforce loi uuden taulun. Ei luonut. Ja sen ymmärtäminen, miksi ei, on yksi niistä kohdista, joissa alat siirtyä ylläpitäjän tai kehittäjän ajattelusta arkkitehdin ajatteluun.

Salesforce tietysti tallentaa tietoja, ja sen alla on tietokantoja. Mutta Salesforce ei ole tietokanta, jonka päälle on laitettu kiva näyttö. Se on metatietovetoinen sovellusalusta, ja tämä ero muovaa lähes jokaista tämän kurssin päätöstä.

Alustalla on muoto

Luvussa 2 rakensimme mallin välittämättä Salesforcesta lainkaan. Se oli tarkoituksellista: kuuntelimme substantiiveja, rakensimme käsitteellisen mallin, lisäsimme attribuutit, avaimet ja suhteet, ja vasta sitten kysyimme, miten Salesforcen pitäisi toteuttaa se. Nyt meidän on ymmärrettävä se, minkä päälle sen toteutamme.

Käytän tästä yksinkertaista sanontaa: alustalla on muoto. Salesforce antaa meille objektit, kentät, suhteet, suojauksen, automaation, API:t, transaktiot, raportoinnin ja haun, ja ne kaikki ovat yhteydessä toisiinsa. Kun luon objektin, en vain luo paikkaa riveille. Luon jotain, joka osallistuu suojausmalliin, johon automaatio voi kohdistua, jonka API:t tuovat saataville, jota raportit voivat käyttää, johon muut objektit voivat liittyä ja josta käyttäjät, integraatiot ja yhä useammin agentit tulevat riippumaan. Se on paljon enemmän kuin taulu.

Metatiedot ovat pohjapiirustus

Ajattele rakennusta. On itse rakennus, ja on pohjapiirustus, joka kuvaa sen: missä seinät ovat, mihin ovet tulevat, miten huoneet liittyvät toisiinsa. Salesforce toimii samalla tavalla. Objektin määrittely on metatietoa. Kentän määrittely on metatietoa. Suhde on metatietoa. Suurin osa siitä, mitä määritämme Setupissa, on metatietoa, ja alusta lukee sen ajon aikana antaakseen orgillemme sen rakenteen ja toiminnan.

Salesforce kuvaa alustan ytimen sekä monivuokralaiseksi (multitenant) että metatietovetoiseksi: kun määrittelemme objektin tai kentän, määrittely tallennetaan metatietona eikä uutena fyysisenä tauluna tai sarakkeena orgiamme varten (Platform Multitenant Architecture (opens in a new tab)).

Kun opetan tätä, avaan konepellin. Salesforce ei luo sinulle uutta tietokantaa joka kerta, kun lisäät objektin. Se lisää tietueen omiin tauluihinsa: objektien tauluun, kenttien tauluun, tietojen tauluun sekä apu- eli pivot-tauluihin indeksejä ja suhteita varten, ja kaikki on avainnettu orgin tunnisteella, joka pitää orgisi tiedot erillään kaikkien muiden tiedoista. Kentän lisääminen on siis vain merkinnän lisäämistä. Siksi voit luoda sellaisen lennossa, lounastauolla, tuotannossa.

Se selittää myös asian, johon moni kompastuu. Kun kirjoitat SELECT Id, Name, Special__c FROM Account, se näyttää yhdeltä taululta. Pinnan alla luet vakio-objektia ja sen mukautettua kenttää eri rakenteista, joten alusta tekee liitoksen (join), jota et koskaan kirjoittanut. Indeksejä on, mutta ne eivät toimi niin kuin perinteisen tietokannan indeksi. Sisäistä toteutusta ei tarvitse tuntea koetta varten. Sen sinun on kuitenkin tiedettävä, että se, mitä näet Object Managerissa, ei ole yksi yhteen -kuva fyysisistä tauluista, ja että tämä abstraktio on sekä alustan voima että syy siihen, miksi se käyttäytyy niin kuin käyttäytyy.

Click to enlarge

Katso emoalukseen

Yksi asioista, joita sanon kurssilaisille, on: katso emoalukseen. Ennen kuin keksit jonkin monimutkaisen tavan tehdä jotain Salesforcessa, katso, miten Salesforce itse sen tekee.

Otetaan esimerkiksi tili (Account). Et luonut sitä; Salesforce loi. Silti voit lisätä siihen kenttiä, rakentaa automaatiota sen ympärille, muuttaa sen asetteluja, tuoda sen saataville API:en kautta ja liittää siihen muita objekteja. Mukautetut objektit pyörivät samalla koneistolla, ja siksi vakio-objektit ja mukautetut objektit tuntuvat niin samanlaisilta, kun rakennamme niiden päälle. Apexissa niillä on jopa yhteinen perusluokka, sObject.

Tämän tavan varaan tämä luku rakentuu, ja seuraavassa moduulissa katsomme kunnolla: vakiotietomalleja, jotka Salesforce on jo rakentanut sinulle.

Emme rakenna Salesforcen viereen. Laajennamme sitä.

API tuli objektin mukana

Luo taulu perinteiseen tietokantaan, niin sinulla on taulu. Jos jonkin toisen sovelluksen pitää käsitellä sitä, jollakulla on lisää työtä edessään. Luo objekti Salesforceen, niin alusta ymmärtää sen jo sovellus- ja integraatiokerroksissaan: se käyttää samoja metatietoja tarjotakseen REST- ja SOAP-API:nsa, joten objektin tietueita voi luoda, lukea, päivittää ja poistaa niiden kautta heti, kun objekti on olemassa (Platform Multitenant Architecture (opens in a new tab)).

En suunnitellut API:a sen takia, että loin objektin. Alusta tuntee objektin, sen kentät, niiden tyypit, sen suhteet ja sen suojauksen. Se on yksi syy siihen, miksi Salesforce-kehitys etenee niin nopeasti. Se on myös syy siihen, miksi objektin luominen on isompi päätös kuin miltä näyttää: kytket rakenteen kokonaiseen sovellusalustaan. Ja sama pätee toisinkin päin. SQL Serverin tai Oraclen parista tulevat kysyvät minulta joskus, miten tiedot ladataan suoraan tietokantaan. Ei mitenkään. Kaikki tulee API:en kautta.

Kerrostalo

Sitten sana, jonka kuulet koko ajan: monivuokralaisuus (multitenancy). Ajattelen sitä kerrostalona.

Sinulla on oma asuntosi. Huonekalusi ovat sinun, eikä avaimesi pitäisi avata minun oveani. Mutta jaamme talon: sähkön, veden, hissit, aulan. Orgisi tuntuu omalta ympäristöltäsi, jossa ovat sinun tietosi, sinun objektisi ja sinun automaatiosi. Pinnan alla Salesforce kuvaa jokaisen orgin vuokralaiseksi ja eristää kunkin vuokralaisen tiedot, metatiedot ja logiikan, kun taas infrastruktuuri ja palvelut ovat yhteisiä (Platform Multitenant Architecture (opens in a new tab)). Näin se pystyy antamaan jokaiselle asiakkaalle näin muokattavan alustan ilman, että jokaiselle pyöritetään omaa erillistä kokonaisuutta.

Talon jakamisella on kuitenkin seurauksensa. Jos yksi asukas ostaa valtavan ilmastointilaitteen ja pitää hiustenkuivainta ja uunia päällä yhtä aikaa, sulake palaa, ja koko kerros pimenee.

Hissiä ei voi ottaa omaksi

Pysytään talossa vielä hetki. Kuvittele, että yksi asukas ilmoittaa: ”Tarvitsen hissiä kahdeksasta kahteentoista. Kukaan muu ei saa käyttää sitä.” Se ei toimi yhteisessä talossa, eikä se toimi Salesforcessakaan. Yhden vuokralaisen ei voi antaa kuluttaa yhteisiä resursseja rajattomasti ja heikentää alustaa kaikilta muilta.

Tästä tulevat governor limits (alustan rajat). Jos olet kehittänyt Salesforcessa, olet luultavasti kohdannut ne listana ulkoa opeteltavia lukuja. En halua, että ajattelet niitä niin. Salesforce soveltaa rajoja transaktio- ja org-tasolla, jotta yhden vuokralaisen työkuorma ei monopolisoi yhteistä laskentatehoa (Architecture Basics (opens in a new tab)). Se on arkkitehtuuria; jokainen yksittäinen raja on vain sen toteutus. Myöhemmin kurssilla välitämme tietyistä rajoista, koska ne muuttavat suunnitelmaa. Muista nyt talo: sinulla on valtava vapaus remontoida asuntoasi. Hissiä et saa ottaa omaksesi.

Salesforcen ID:t ovat osa abstraktiota

Jokaisella Salesforce-tietueella on tunniste, jonka alusta ymmärtää, tietueen ID, ja se toimii kaikkialla alustassa: käyttöliittymässä, API:issa, raporteissa ja automaatiossa.

Luvussa 2 sanoimme, että hyvä avain on yksilöllinen, muuttumaton, merkityksetön eikä koskaan henkilötietoa (PII). Salesforcen ID täyttää sen Salesforcen osalta. Se ei kuitenkaan ole sama asia kuin liiketoiminta-avain. Yritykselläsi voi silti olla ERP:n asiakasnumero, työntekijänumero tai kumppanin tilausnumero, joka merkitsee jotain järjestelmien välillä. Älä sekoita lausetta ”Salesforce tietää, mikä tietue tämä on” lauseeseen ”yritys tietää, mikä liiketoiminnan asia tämä on”. Ne ovat eri tunnistamisen ongelmia, ja jälkimmäinen palaa integraation ja perustietojen yhteydessä.

Objektit ovat enemmän kuin tallennuspaikka

Tässä on ajattelutavan muutos, jonka haluan sinun tekevän ennen tämän luvun loppuosaa. Objekti ei ole vain paikka tietojen tallentamiseen. Kenttä ei ole vain sarake, eikä suhde ole vain viiteavain. Käytän tietokantavertauksia opettaessani, koska ne liittyvät siihen, minkä ihmiset jo tietävät. Mutta jos pysähdymme niihin, arkkitehtuuri jää huomaamatta.

Valitsemamme objekti ratkaisee, mitkä ominaisuudet tulevat sen mukana. Kentän tyyppi vaikuttaa vahvistukseen, integraatioon, hakuun, raportointiin ja siihen, miten muut järjestelmät lukevat tiedot. Suhde ratkaisee elinkaaren, omistajuuden, jakamisen ja poistamisen. Se, mihin tiedot sijoitamme, vaikuttaa tallennustilaan, suorituskykyyn ja skaalautuvuuteen. Ja koska kaikki tämä pyörii jaetulla alustalla, valinta, joka on harmiton sadalla tietueella, voi käyttäytyä aivan eri tavalla sadalla miljoonalla. Käymme nämä päätökset läpi yksi kerrallaan.

Kokeen jälkeen: mitä tekoäly muuttaa. Vuosien ajan hyvät nimet ja kuvaukset auttoivat seuraavaa ylläpitäjää tai kehittäjää ymmärtämään, mitä olimme rakentaneet. Nyt koneetkin lukevat tätä kontekstia. Tekoälyjärjestelmällä, joka käsittelee kenttää nimeltä Flag2__c, on sama ongelma kuin uudella kehittäjällä: mitä tämä tarkoittaa? Metatiedot eivät ole enää koristetta; ne ovat osa sitä, miten koneet ymmärtävät sovelluksen.

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

• Suunnittelenko alustalle, jolla oikeasti olen, vai kohtelenko Salesforcea kuin mitä tahansa tietokantaa?
• Mitkä suunnitelmani osat ovat liiketoiminnan käsitteitä ja mitkä Salesforcen toteutusvalintoja?
• Mitä alustan toimintaa tulee mukana rakenteessa, jonka olen luomassa?
• Mitkä rajat ovat jaetun arkkitehtuurin ilmentymiä, ja mitkä niistä muovaavat tätä suunnitelmaa?
• Jos tätä rakennetta on myöhemmin vaikea muuttaa, kohtelenko sitä arkkitehtuuripäätöksenä?

Luvussa 2 sanoimme: älä suunnittele Setupista käsin. Nyt tiedät siihen toisenkin syyn. New Custom Object -painikkeen napsauttaminen ei vain anna sinulle taulua; se kytkee taas yhden arkkitehtuurisi palan metatietovetoiseen, monivuokralaiseen alustaan. Mutta ennen kuin päätät, minkä objektin luot, on perustavampi kysymys: kuuluvatko nämä tiedot tänne ylipäätään? Siitä seuraavaksi.

Lue lisää

• Salesforce Architects, Platform Multitenant Architecture (opens in a new tab), englanniksi, tarkistettu 2026-10-02, tarkistettu uudelleen 2026-10-12: objektien ja kenttien määrittelyt tallennetaan metatietona eikä uusina tauluina; jaetut taulut (MT_Objects, MT_Fields, MT_Data, MT_Indexes), joiden avaimena on OrgID; samat metatiedot tarjoavat REST- ja SOAP-API:t.
• Salesforce Architects, Architecture Basics (opens in a new tab), englanniksi, tarkistettu 2026-10-02, tarkistettu uudelleen 2026-10-12: governor limits ja suoritusrajat, jotta koodi ja transaktiot eivät monopolisoi yhteisiä laskentaresursseja (”don’t monopolize shared compute resources”).