CIM-muodot

(CIM) suunniteltiin alusta alkaen standardeihin perustuvaksi, sovellusagnostiseksi liiketoimintakonseptien malliksi – asiakkaista, tilauksista, tuotteista, tileistä ja niiden välisistä suhteista. Käsitteellinen malli on kuitenkin hyödyllinen vain, jos sitä tarvitsevat järjestelmät voivat todella hyödyntää sitä. Tästä syystä CIM ei ole julkaistu yhtenä yksittäisenä proprietary-artefaktina, vaan serialisointien perheenä, joista jokainen on kohdistettu eri työkaluille, suoritusaikoihin ja kohderyhmille.

Tällä sivulla selitetään, mitä kukin CIM-muoto on, mihin se on tarkoitettu ja miten valita niiden väliltä. Olitpa yritystietoarkkitehti, integraatio- tai ETL-insinööri, sovellus- tai alustatoimittaja tai avoimen lähdekoodin kehittäjä, valitsemasi muoto riippuu siitä, missä kohtaa tietoputkea toimit.

Keskeiset huomiot

• CIM jaetaan kahteen perheeseen: semanttisen verkon muotoihin (JSON-LD, RDF Schema, SHACL, R2RML) ja ihmisen luettaviin/relaatiomuotoihin (AML-sanasto, AML-murre, RAML-tyypit, JSON Schema, SQL DDL).
• Käsitteellinen malli (concepts.*) kuvaa entiteettejä ja suhteita; kanoninen skeema (schema.*) kuvaa tietomuotoja ja rajoituksia. Ne ovat erillisiä artefakteja, joilla on eri käyttötarkoitukset.
• JSON-LD on kanoninen koneellisesti luettava muoto; AML on saman sisällön ihmisen luettava muoto; SQL DDL ja JSON Schema ovat muotoja, joita useimmat sovellus- ja ETL-tiimit käyttävät suoraan.
• R2RML on silta: se kartoittaa relaatioskeeman RDF-graafiin, ja näin yhdistät olemassa olevat SQL-tietokannat semanttiseen kerrokseen.
• Muodon valinta on kuluttajan, ei mieltymyksen kysymys – valitse se, jonka kohdetyökalukettisi tukee natiivisti, ja käytä muita ristiintarkistuksina.

Miksi CIM toimitetaan useissa muodoissa

Useimmat tietomallit julkaistaan vain yhdessä muodossa – yleensä ER-kaaviona, laskentataulukona tai toimittajakohtaisena metatietotiedostona. Tämä toimii, kunnes malli on jaettava organisaatioiden välillä, jotka käyttävät eri teknologiapinoja.

Vähittäismyyntialusta saattaa käyttää PostgreSQLiä ja dbt:tä; kumppani voi käyttää graafitietokantaa ja triple storea; SaaS-toimittaja voi tarjota JSON-rajapintoja ja validoida datapaketit JSON Schemalla. Jos jaettu malli on olemassa vain yhdessä näistä murteista, kaikkien muiden on käännettävä se – ja käännökset alkavat erkaantua.

CIM:n monimuotostrategia on tietoinen vastaus tähän ongelmaan. Malli kirjoitetaan kerran ja käännetään sitten muotoihin, jotka vastaavat selkeästi tunnustettuja standardeja, jotta jokainen kuluttaja voi ottaa CIM:n käyttöön jo olemassa olevilla työkaluillaan.

Tämä on sama filosofia, jota noudattavat standardielimet, kuten World Wide Web Consortium (W3C), joka julkaisee spesifikaatioita, kuten RDF, SHACL ja R2RML, joita CIM hyödyntää uudelleen sen sijaan, että keksisi ne uudelleen. Se on myös linjassa Linux Foundationin laajemman yhteentoimivuustehtävän kanssa, jonka alaisuudessa CIM-projekti toimii.

Aiheeseen liittyvä: Fivetran — Täysin hallittu ELT-putkisto, joka vain jatkaa käynnissä.

Käytännön hyöty on kaksinkertainen: yritykset, joilla on erilaisia teknologioita, voivat ottaa CIM:n käyttöön ilman kokonaan uutta järjestelmäinvestointia (rip-and-replace), ja kehittäjät voivat laajentaa mallia siinä muodossa, joka vastaa heidän osaamistaan, tietäen että muut serialisoinnit voidaan luoda uudelleen.

Käsitteellinen malli vs. kanoninen skeema

Ennen tiedostomuotojen vertailua on hyödyllistä erottaa kaksi tasoa, jotka CIM pitää erillään – ja jotka tulokkaat usein sekoittavat.

• Käsitteellinen malli vastaa kysymykseen mitä on olemassa ja miten asiat liittyvät toisiinsa. Se määrittelee entiteetit (Customer, Order, Product), niiden attribuutit ja niiden väliset suhteet. Se on tarkoituksella lähellä liiketoimintasanoastoa ja välttää fyysisiä yksityiskohtia.
• Kanoninen skeema vastaa kysymykseen miltä kelvollinen esiintymä näyttää. Se lisää tietomuodot ja rajoitukset – kardinaalisuuden, tyypit, pakolliset kentät, arvoalueet – joita vasten järjestelmä voi validoida tiedon.

CIM-jakelussa nämä vastaavat kahta tiedostonimen alkua: concepts.* käsitteelliselle tasolle ja schema.* kanoniselle tasolle. Niiden pitäminen erillään tarkoittaa, että liiketoiminta-analyytikko voi lukea käsitteellisen mallin kahlaamatta rajoitussyntaksin läpi, kun taas insinööri voi validoida datapaketit skeemaa vasten tarvitsematta koko käsitteellistä kerrontaa.

Jos olet ostoksilla: Boomi AtomSphere — Enterprise iPaaS hybridi pilvestä on-prem -integraatioon.

Semanttisen verkon muodot

Nämä muodot ilmaisevat CIM:n RDF-pohjaisena graafina. Ne ovat oikea valinta, kun kuluttajiin kuuluu triple storeja, tietograafeja (knowledge graphs), ontologiatyökaluja tai mitä tahansa järjestelmää, joka päättelee linkitettyjen tietojen perusteella.

JSON-LD — concepts.json ja schema.json

JSON-LD on JSON, jossa on linkitetyn datan konteksti, mikä tekee siitä pragmaattisen sillan tavallisten web-rajapintojen ja semanttisen verkon välille. CIM julkaisee kaksi JSON-LD-artefaktia:

• concepts.json — entiteettien ja suhteiden käsitteellinen kuvaus, ilmaistuna RDF Schemana.
• schema.json — kanoniset tietomuodot ja lisärajoitukset, ilmaistuna SHACL:llä.

Koska kyseessä on validi JSON, concepts.json ja schema.json voidaan ladata tavallisilla JSON-työkaluilla, mutta koska niissä on @context, ne voidaan myös laajentaa täysiksi RDF-tripleiksi. Tämän kaksoisluonteen vuoksi JSON-LD on usein paras oletusvalinta tiimeille, jotka haluavat semanttista tarkkuutta ilman, että heidän täytyy ottaa käyttöön erikoistunutta RDF-pinoa heti ensimmäisestä päivästä lähtien.

RDF Schema — schema.json

RDF Schema (RDFS) tarjoaa sanaston luokkien ja ominaisuuksien kuvaamiseen – rdfs:Class, rdfs:subClassOf sekä rdfs:domain/rdfs:range -konstruktit, joiden avulla kone ymmärtää, että Order on liiketoimintadokumentti ja että sen customer-ominaisuus viittaa Customer-entiteettiin. CIM käyttää RDFS:ää antaakseen käsitteelliselle mallille muodollisen semantiikan, jotta aliluokkahierarkiat ja ominaisuusalueet ovat konetulkittavia eivätkä pelkästään dokumentoituja.

SHACL — schema.json

Shapes Constraint Language (SHACL) on W3C-standardi RDF-graafien validoimiseksi muodoiksi kutsuttujen ehtojen perusteella. Siinä missä RDFS kertoo, mikä luokka on, SHACL kertoo, mitä kelvollisen instanssin täytyy täyttää – vaaditut ominaisuudet, sallitut arvotyypit ja kardinaalisuusrajat. CIM:n kanoniset datamuodot on ilmaistu SHACL-muodossa, mikä tarkoittaa, että mikä tahansa SHACL-prosessori voi validoida CIM-yhteensopivia tietoja ilman mukautettua koodia.

R2RML — schema.rdml

R2RML on W3C-standardi relaatiotietokantakaavion mäppäämiseksi RDF-graafiin. Tämä on integraatio- ja ETL-insinööreille tärkein muoto, koska se on mekanismi, jolla olemassa oleva SQL-tietokanta – taulukoineen, sarakkeineen ja vierasavaineen – paljastetaan CIM-yhteensopivana linkitettynä datana.

Aiheeseen liittyvä: Airbyte — Avoimen lähdekoodin ELT hallitulla pilvivaihtoehdolla.

Sen sijaan, että mallintaisit toiminnallisen tietokantasi uudelleen käsin, kirjoitat (tai luot) R2RML-mäppäyksen, joka määrittelee, kuinka kukin taulukko ja sarake vastaa CIM-entiteettejä ja -ominaisuuksia. Tuloksena on virtuaalinen RDF-graafi olemassa olevien relaatiotietojesi päällä.

Ihmisen luettavat ja relaatiomuodot

Kaikki kuluttajat eivät halua RDF-muotoa. Sovelluskehittäjät, tietomallintajat ja tietokantahallinnoijat (DBA) haluavat usein jotain, jota he voivat lukea tekstieditorissa tai ladata suoraan tietokantaan. CIM palvelee heitä AML-, RAML-, JSON Schema- ja SQL DDL -serialisaatioilla.

AML — concepts.yaml, schema.yaml, schema.raml

AML (AnyLogic Modeling Language), jota käytetään tässä mallinnusmurteena, on CIM:n ihmisen luettavassa muodossa oleva ilmaus. CIM julkaisee kolme AML-artefaktia:

Mistä aloittaisimme: Matillion — Push-down ELT rakennettu pilvitietovarastoihin.

• concepts.yaml — AML-sanasto, käsitteellisen mallin ihmisen luettava versio.
• schema.yaml — AML-murre, kanonisten datamuotojen ihmisen luettava versio.
• schema.raml — kanonisten muotojen RAML-tietotyyppien renderöinti.

Sanaston ja murteen välinen ero on tärkeä sisäistää: sanasto määrittelee termit (mallin substantiivit ja verbit), kun taas murre määrittelee, kuinka nämä termit yhdistetään kelvollisiksi rakenteiksi. Jos tarkastelet CIM:ää ensimmäistä kertaa, concepts.yaml on yleensä helpoin aloituskohta.

JSON Schema — schema.json

JSON Schema on tosiasiallinen standardi JSON-dokumenttien validoinnissa, ja sitä tuetaan natiivisti tai kirjastojen kautta käytännössä kaikilla nykyaikaisilla kielillä. CIM:n JSON Schema -artefakti ilmaisee kanoniset datamuodot JSON Schemana, mikä tekee siitä suoraan käytettävän API-yhdyskäytävissä, viestivälittäjissä ja CI-putkissa, jotka jo validoivat JSON-hyötykuormia. Jos integrointipintasi on REST tai tapahtumapohjainen JSON, tämä on usein haluamasi muoto.

SQL DDL — schema.sql

SQL DDL on joukko CREATE TABLE- ja CREATE VIEW -lauseita sekä rajoitteita, jotka materialisoivat kanoniset muodot relaatiotietokantaan. CIM noudattaa SQL 2008 -syntaksia, mikä pitää DDL:n kannettavana suurimpien relaatiomoottoreiden välillä. Tämä on muoto, johon DBA:t ja ETL-insinöörit tukeutuvat, kun he haluavat pystyttää CIM:n mukaisen fyysisen skeeman – esimerkiksi kanonista mallia heijastavan staging- tai integraatiotietokannan.

Muodon valitseminen: Käytännön opas

Ei ole olemassa yhtä “oikeaa” muotoa. Oikea valinta määräytyy sen mukaan, kuka tai mikä kuluttaa mallia seuraavaksi. Käytä alla olevaa taulukkoa päätöksenteon apuna.

Jos kuluttajasi on…	Aloita…	Koska…
Yritysanalyytikko tai tietomallintaja, joka tarkastelee mallia	AML-sanasto (concepts.yaml)	Ihmisen luettava, liikesanasto etusijalla
Triple store, tietograafi tai ontologiatyökalu	JSON-LD (concepts.json, schema.json)	Natiivi RDF JSON-sisäänkäynnillä
SHACL-validaattori tai semanttinen tietolaatuputki	SHACL (schema.json)	Standardien mukainen rajoitevalidointi RDF:n päällä
Olemassa oleva relaatiotietokanta, jonka haluat paljastaa linkitettynä datana	R2RML (schema.rdml)	Mäppää taulukot/sarakkeet CIM-entiteetteihin ilman uudelleenmallintamista
REST- tai tapahtumapohjainen JSON-rajapinta	JSON Schema (schema.json)	Validoi suoraan JSON-hyötykuormat
Relaatiotietokanta, jonka haluat mukauttaa CIM:iin	SQL DDL (schema.sql)	Kannettava SQL 2008 DDL
RAML-kuvattu rajapinta	RAML-tyypit (schema.raml)	Natiivi RAML-työkaluketjuille

Muutama käytännön huomio:

• Älä käsittele muotoja itsenäisinä malleina. Ne ovat saman taustalla olevan CIM:n serialisaatioita. Jos huomaat ristiriidan esimerkiksi schema.json (JSON Schema) ja schema.json (SHACL) välillä, se on bugi tai versioero, ei suunnitteluvalinta – ilmoita siitä.
• Huomioi tiedostonimien törmäykset. Useat muodot jakavat saman schema-rungon eri päätteillä (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml). Kun lataat täyden jakelun, pidä muotohakemistot erillään, jotta et korvaa yhtä serialisaatiota toisella.
• Valitse muoto validointivaiheen mukaan. Käytä käsitteellisiä muotoja suunnitteluvaiheen tarkasteluun ja kanonisia muotoja ajonaikaisen validoinnin yhteydessä. Validointi käsitteellistä mallia vastaan ei ole mielekästä, sillä siitä puuttuvat rajoitteet.
• Suosi generoituja käsin muokattujen sijaan. Jos laajennat CIM:ää, laajenna lähdettä ja generoi muut serialisaatiot uudelleen sen sijaan, että muokkaisit jokaista muotoa käsin, jotta kokonaisuus ei ajaudu epäsynkroniseen tilaan.

Täyden CIM-jakelun lataaminen

CIM on jaettu täydellisenä määritelmänä jokaisessa käytettävissä olevassa muodossa, joten voit ladata koko mallin tarvitsemassasi serialisaatiossa sen sijaan, että kokoaisit sen pala kerrallaan. Julkaistut latausvaihtoehdot ovat:

• AML (vocabulary) — ihmisen luettavissa oleva käsitteellinen malli.
• AML (dialect) — ihmisen luettavissa olevat kanoniset muodot.
• JSON-LD (vocabulary & schema) — koneellisesti luettava semanttinen malli.
• R2RML — relaatio-RDF-kartoitus.
• RAML Types — kanoniset muodot RAML-tietotyypeinä.
• SQL DDL — kanoniset muodot kannettavana SQL:nä.

Jokainen lataus sisältää täydellisen CIM-määritelmän kyseisessä muodossa, mikä tarkoittaa, että voit ottaa CIM:n käyttöön asteittain: aloita muodosta, jota nykyinen työkaluketjusi tukee, ja lisää muita, kun yhteentoimivuustarpeesi kasvavat.

Osallistuminen eri muodoissa

Koska CIM on avoin projekti, panokset ovat tervetulleita – ja monimuotoinen rakenne määrittää, miten osallistuminen toimii. Osallistujat jaetaan yleensä kahteen ryhmään:

• Mallin kehittäjät ehdottavat uusia entiteettejä, suhteita tai rajoituksia. Nämä muutokset luodaan kerran ja siirretään sitten muihin serialisointeihin.
• Formaattien kehittäjät parantavat tietyn serialisoinnin tarkkuutta tai työkaluja – esimerkiksi tarkentavat R2RML-kartoituksia tai SQL DDL:n siirrettävyyttä.

Jos osallistut, käytännön sääntönä on ymmärtää, mitä kerrosta muutat (käsitteellinen vs. kanoninen) ja mitkä muodot on luotava uudelleen seurauksena. Projektin GitHub-arkistot ja osallistujien verkkolomake ovat lähtöpisteitä mukaan lähtemiselle.

Usein kysyttyjä kysymyksiä

Mitä eroa on concepts.json ja schema.json välillä CIM:ssä?

concepts.json on käsitteellinen malli – CIM:n entiteetit ja suhteet ilmaistuna JSON-LD:nä RDF Schema -semantiikalla. schema.json on kanoninen skeema – datamuodot ja lisärajoitukset ilmaistuna JSON-LD:nä SHACL-semantiikalla. Lyhyesti sanottuna concepts kuvaa sitä, mitä on olemassa; schema kuvaa, miltä kelvollisen instanssin tulee näyttää.

Miksi CIM julkaisee saman mallin niin monessa muodossa?

Koska eri käyttäjät käyttävät eri tekniikoita. Triple store tarvitsee RDF:n; JSON-rajapinta tarvitsee JSON-skeeman; tietokanta-asiantuntija (DBA) tarvitsee SQL DDL:n; liiketoiminta-analyytikko tarvitsee jotain ihmisen luettavaa. CIM:n julkaiseminen useissa standardimuodoissa antaa kunkin kohderyhmän ottaa mallin käyttöön jo olemassa olevilla työkaluilla sen sijaan, että kaikille pakotettaisiin yksi teknologiapino.

Mihin R2RML:ää käytetään CIM:ssä?

R2RML on W3C-standardi relaatiotietokantakaavion kartoittamiseksi RDF-graafiin. CIM:ssä se on silta, joka tuo olemassa olevat SQL-tietokannat CIM-yhteensopivina linkitettyinä datoina, joten voit yhdistää toiminnalliset relaatiojärjestelmät semanttiseen kerrokseen ilman, että niitä tarvitsee mallintaa uudelleen käsin.

Onko AML sama asia kuin JSON-LD-muodot?

Ei. AML on CIM:n ihmisen luettavissa oleva ilmaisu – sanasto (concepts.yaml) ja murre (schema.yaml, schema.raml). JSON-LD on koneellisesti luettava, RDF-pohjainen ilmaisu. Ne kuvaavat samaa mallia, mutta on suunnattu eri yleisöille ja työkaluketjuille.

Millä CIM-muodolla minun pitäisi aloittaa?

Se riippuu käyttötapauksestasi. Jos tarkastelet mallia, aloita AML-sanastosta. Jos rakennat JSON-rajapintaa, aloita JSON-skeemalla. Jos yhdistät relaatiotietokannan, aloita R2RML:llä tai SQL DDL:llä. Jos työskentelet tietograafin (knowledge graph) kanssa, aloita JSON-LD:stä ja SHACL:stä.

Voinko muokata yhtä CIM-muotoa päivittämättä muita?

Voit, mutta sinun ei pitäisi. Muodot ovat yhden taustalla olevan mallin serialisointeja, joten yhden muodon muokkaaminen käsin aiheuttaa sen, että eri versiot ajautuvat epäsynkronisiksi. Laajenna sen sijaan lähdemallia ja luo muut serialisoinnit uudelleen.

Lisälukemista

• World Wide Web Consortium (W3C) — RDF:n, RDF Scheman, SHACL:n ja R2RML:n takana oleva standardointielin, joiden spesifikaatioihin CIM rakentuu.
• Shapes Constraint Language (SHACL) — taustatietoa CIM:n kanonisissa datamuodoissa käytetystä rajoituskielestä.
• Linux Foundation — säätiö, jonka alaisuudessa CIM-projekti toimii.