Formaty CIM

Model Informacji w Chmurze (Cloud Information Model – CIM) został od początku zaprojektowany jako oparty na standardach, niezależny od aplikacji model pojęć biznesowych — klientów, zamówień, produktów, kont i relacji między nimi. Jednak model koncepcyjny jest użyteczny tylko wtedy, gdy systemy, które go potrzebują, mogą go faktycznie konsumować. Dlatego właśnie CIM jest publikowany nie jako pojedynczy zastrzeżony artefakt, ale jako rodzina serializacji, z których każda jest skierowana do innej klasy narzędzi, środowiska wykonawczego i odbiorców.

Na tej stronie wyjaśniono, czym jest każdy format CIM, do czego służy i jak wybierać spośród nich. Jeśli jesteś architektem danych w przedsiębiorstwie, inżynierem integracji lub ETL, dostawcą aplikacji lub platformy albo współtwórcą open-source, format, po który sięgniesz w pierwszej kolejności, zależy od tego, w którym miejscu potoku danych się znajdujesz.

Kluczowe wnioski

• CIM jest dystrybuowany w dwóch rodzinach: formatach sieci semantycznej (JSON-LD, RDF Schema, SHACL, R2RML) i formatach czytelnych dla człowieka/relacyjnych (słownictwo AML, dialekt AML, typy RAML, JSON Schema, SQL DDL).
• Model koncepcyjny (concepts.*) opisuje byty i relacje; schemat kanoniczny (schema.*) opisuje kształty danych i ograniczenia. Są to odrębne artefakty o odrębnych celach.
• JSON-LD to kanoniczna forma do odczytu maszynowego; AML to czytelna dla człowieka forma tej samej treści; SQL DDL i JSON Schema to formy, z których bezpośrednio korzysta większość zespołów aplikacyjnych i ETL.
• R2RML to pomost: odwzorowuje schemat relacyjny na graf RDF, co pozwala połączyć istniejące bazy danych SQL z warstwą semantyczną.
• Wybór formatu jest kwestią konsumenta, a nie preferencji — wybierz ten, który Twój docelowy zestaw narzędzi natywnie przyjmuje, a pozostałe wykorzystaj do kontroli krzyżowej.

Dlaczego CIM jest dostarczany w wielu formatach

Większość modeli danych jest publikowana w dokładnie jednej formie — zwykle jest to diagram ER, arkusz kalkulacyjny lub plik metadanych specyficzny dla dostawcy. To działa, dopóki nie pojawi się potrzeba udostępnienia modelu pomiędzy organizacjami korzystającymi z różnych stosów technologicznych.

Platforma detaliczna może obsługiwać PostgreSQL i dbt; partner może korzystać z grafowej bazy danych i triple store; dostawca SaaS może udostępniać interfejsy API JSON i weryfikować ładunki za pomocą JSON Schema. Jeśli wspólny model istnieje tylko w jednym z tych dialektów, wszyscy inni muszą go przetłumaczyć – a tłumaczenia ulegają rozbieżnościom.

Wieloformatowa strategia CIM jest świadomą odpowiedzią na ten problem. Model jest tworzony raz, a następnie tłumaczony na formaty, które w przejrzysty sposób odwzorowują uznane standardy, dzięki czemu każdy konsument przyjmuje CIM przy użyciu narzędzi, które już posiada.

Ta sama filozofia stoi za organizacjami normalizacyjnymi, takimi jak World Wide Web Consortium (W3C), które publikuje specyfikacje takie jak RDF, SHACL i R2RML, które CIM wykorzystuje zamiast wymyślać na nowo. Jest to również zgodne z szerszą misją interoperacyjności Linux Foundation, w ramach której działa projekt CIM.

Powiązane: Fivetran — W pełni zarządzany potok ELT, który po prostu działa.

Praktyczna korzyść jest dwojaka: firmy stosujące różne technologie mogą wdrożyć CIM bez konieczności całkowitej wymiany systemów (rip-and-replace), a współtwórcy mogą rozszerzać model w dowolnym formacie odpowiadającym ich wiedzy specjalistycznej, wiedząc, że inne serializacje można zregenerować.

Model koncepcyjny a schemat kanoniczny

Przed porównaniem formatów plików warto rozróżnić dwie warstwy, które CIM utrzymuje oddzielnie, a które nowicjusze często mylą.

• Model koncepcyjny odpowiada na pytanie: co istnieje i jak się relacjonuje. Definiuje byty (Klient, Zamówienie, Produkt), ich atrybuty i relacje między nimi. Jest on celowo zbliżony do słownictwa biznesowego i celowo pozbawiony szczegółów fizycznych.
• Schemat kanoniczny odpowiada na pytanie: jak wygląda poprawna instancja. Dodaje kształty danych i ograniczenia — kardynalność, typy, wymagane pola, zakresy wartości — względem których system może przeprowadzić walidację.

W dystrybucji CIM odpowiadają one dwóm rdzeniom nazw plików: concepts.* dla warstwy koncepcyjnej i schema.* dla warstwy kanonicznej. Utrzymywanie ich oddzielnie oznacza, że analityk biznesowy może odczytać model koncepcyjny bez przedzierania się przez składnię ograniczeń, podczas gdy inżynier może weryfikować ładunki względem schematu bez konieczności analizowania pełnej narracji koncepcyjnej.

Jeśli robisz zakupy: Boomi AtomSphere — Enterprise iPaaS do integracji hybrydowej chmury z lokalną firmą.

Formaty sieci semantycznej

Te formaty wyrażają CIM jako graf oparty na RDF. Są właściwym wyborem, gdy Twoi konsumenci obejmują triple store’y, grafy wiedzy, narzędzia ontologiczne lub dowolny system wnioskujący na danych powiązanych (linked data).

JSON-LD — concepts.json i schema.json

JSON-LD to JSON z kontekstem danych powiązanych, co czyni go pragmatycznym pomostem pomiędzy zwykłymi internetowymi interfejsami API a siecią semantyczną. CIM publikuje dwa artefakty JSON-LD:

• concepts.json — koncepcyjny opis bytów i relacji, wyrażony jako RDF Schema.
• schema.json — kanoniczne kształty danych i dodatkowe ograniczenia, wyrażone w SHACL.

Ponieważ jest to poprawny format JSON, pliki concepts.json i schema.json mogą być ładowane przez zwykłe narzędzia do obsługi JSON, ale ponieważ zawierają @context, mogą zostać również rozwinięte do pełnych trójek RDF. Ta podwójna natura sprawia, że JSON-LD jest często najlepszym domyślnym wyborem dla zespołów, które chcą zachować wierność semantyczną bez konieczności wdrażania wyspecjalizowanego stosu RDF od pierwszego dnia.

RDF Schema — schema.json

RDF Schema (RDFS) zapewnia słownictwo do opisu klas i właściwości — konstrukcje rdfs:Class, rdfs:subClassOf oraz rdfs:domain/rdfs:range, które pozwalają maszynie zrozumieć, że Zamówienie jest dokumentem biznesowym i że jego właściwość klienta wskazuje na Klienta. CIM wykorzystuje RDFS, aby nadać modelowi koncepcyjnemu formalną semantykę, dzięki czemu hierarchie podklas i domeny właściwości są interpretowalne maszynowo, a nie tylko udokumentowane.

SHACL — schema.json

Shapes Constraint Language (SHACL) to standard W3C służący do walidacji grafów RDF pod kątem zestawu warunków zwanych kształtami (shapes). Tam, gdzie RDFS mówi, czym jest klasa, SHACL mówi, co poprawna instancja musi spełniać — wymagane właściwości, dozwolone typy wartości, limity liczności. Kanoniczne kształty danych CIM są wyrażone w SHACL, co oznacza, że każdy procesor SHACL może walidować dane zgodne z CIM bez potrzeby pisania niestandardowego kodu.

R2RML — schema.rdml

R2RML to standard W3C służący do mapowania schematu relacyjnej bazy danych na graf RDF. Jest to format, który ma największe znaczenie dla inżynierów integracji i ETL, ponieważ jest to mechanizm, dzięki któremu istniejąca baza danych SQL — z jej tabelami, kolumnami i kluczami obcymi — jest udostępniana jako połączone dane (linked data) zgodne z CIM.

Powiązane: Matillion — ELT typu push-down zbudowany dla hurtowni danych w chmurze.

Zamiast ręcznie przemodelowywać operacyjną bazę danych, tworzy się (lub generuje) mapowanie R2RML, które deklaruje, w jaki sposób każda tabela i kolumna odpowiada encjom i właściwościom CIM. Wynikiem jest wirtualny graf RDF nad istniejącymi danymi relacyjnymi.

Formaty czytelne dla człowieka i relacyjne

Nie każdy konsument potrzebuje RDF. Twórcy aplikacji, modelarze danych i administratorzy baz danych (DBA) często chcą czegoś, co można przeczytać w edytorze tekstu lub załadować bezpośrednio do bazy danych. CIM zapewnia im serializacje AML, RAML, JSON Schema i SQL DDL.

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

AML, pochodna języka AnyLogic Modeling Language używana tutaj jako dialekt modelowania, jest czytelną dla człowieka formą ekspresji CIM. CIM publikuje trzy artefakty AML:

Nasz wybór: Workato — Oparte na automatyzacji iPaaS, na którym zespoły biznesowe mogą faktycznie bazować.

• concepts.yaml — słownictwo (vocabulary) AML, czytelna dla człowieka wersja modelu koncepcyjnego.
• schema.yaml — dialekt AML, czytelna dla człowieka wersja kanonicznych kształtów danych.
• schema.raml — renderowanie typów danych RAML dla kształtów kanonicznych.

Warto przyswoić rozróżnienie między słownictwem a dialektem: słownictwo definiuje terminy (rzeczowniki i czasowniki modelu), podczas gdy dialekt określa, w jaki sposób te terminy są łączone w poprawne struktury. Jeśli przeglądasz CIM po raz pierwszy, concepts.yaml jest zazwyczaj najbardziej przystępnym punktem wejścia.

JSON Schema — schema.json

JSON Schema to de facto standard walidacji dokumentów JSON, obsługiwany natywnie lub za pomocą bibliotek w praktycznie każdym nowoczesnym języku. Artefakt JSON Schema w CIM wyraża kanoniczne kształty danych jako JSON Schema, co czyni go bezpośrednio użytecznym w bramach API, brokerach komunikatów i potokach CI, które już walidują ładunki JSON. Jeśli Twoim interfejsem integracyjnym jest REST lub JSON sterowany zdarzeniami, często jest to format, którego potrzebujesz.

SQL DDL — schema.sql

SQL DDL to zestaw instrukcji CREATE TABLE, CREATE VIEW oraz ograniczeń (constraints), które materializują kształty kanoniczne w relacyjnej bazie danych. CIM celuje w składnię SQL 2008, co zapewnia przenośność DDL pomiędzy głównymi silnikami relacyjnymi. Jest to format, po który sięgają DBA i inżynierowie ETL, gdy chcą stworzyć fizyczny schemat zgodny z CIM — na przykład bazę danych stagingową lub integracyjną, która odzwierciedla model kanoniczny.

Wybór formatu: praktyczny przewodnik

Nie ma jednego „poprawnego” formatu. Właściwy wybór zależy od tego, kto lub co będzie konsumować model w następnym kroku. Skorzystaj z poniższej tabeli jako pomocy w podjęciu decyzji.

Jeśli Twoim konsumentem jest…	Zacznij od…	Ponieważ…
Analityk biznesowy lub modelarz danych przeglądający model	Słownictwo AML (concepts.yaml)	Czytelne dla człowieka, priorytet dla słownictwa biznesowego
Triple store, graf wiedzy lub narzędzie ontologiczne	JSON-LD (concepts.json, schema.json)	Natywny RDF z dostępem przez JSON
Walidator SHACL lub potok semantycznej jakości danych	SHACL (schema.json)	Standardowa walidacja ograniczeń nad RDF
Istniejąca relacyjna baza danych, którą chcesz udostępnić jako linked data	R2RML (schema.rdml)	Mapuje tabele/kolumny na encje CIM bez przemodelowywania
API JSON REST lub sterowane zdarzeniami	JSON Schema (schema.json)	Bezpośrednio waliduje ładunki JSON
Relacyjna baza danych, którą chcesz dostosować do CIM	SQL DDL (schema.sql)	Przenośny SQL 2008 DDL
API opisane w RAML	Typy RAML (schema.raml)	Natywne dla łańcuchów narzędzi RAML

Kilka praktycznych uwag:

• Nie traktuj formatów jako niezależnych modeli. Są one serializacjami tego samego bazowego modelu CIM. Jeśli znajdziesz rozbieżność między np. schema.json (JSON Schema) a schema.json (SHACL), jest to błąd lub niezgodność wersji, a nie wybór projektowy — zgłoś to.
• Uważaj na kolizje nazw plików. Kilka formatów ma wspólny rdzeń schema z różnymi rozszerzeniami (schema.json, schema.yaml, schema.raml, schema.sql, schema.rdml). Pobierając pełną dystrybucję, trzymaj katalogi formatów osobno, aby nie nadpisać jednej serializacji inną.
• Dopasuj format do etapu walidacji. Używaj formatów koncepcyjnych do przeglądu na etapie projektowania, a formatów kanonicznych do walidacji w czasie rzeczywistym (runtime). Walidacja względem modelu koncepcyjnego nie ma sensu — brakuje w nim ograniczeń.
• Preferuj generowanie nad ręczną edycję. Jeśli rozszerzasz CIM, rozszerz źródło i wygeneruj ponownie pozostałe serializacje, zamiast edytować każdy format ręcznie, w przeciwnym razie wersje rozjadą się i stracą synchronizację.

Pobieranie pełnej dystrybucji CIM

CIM jest rozpowszechniany jako kompletna definicja w każdym dostępnym formacie, dzięki czemu możesz pobrać cały model w potrzebnej serializacji, zamiast składać go element po elemencie. Opublikowane opcje pobierania to:

• AML (vocabulary) — model pojęciowy zrozumiały dla człowieka.
• AML (dialect) — kanoniczne kształty (shapes) zrozumiałe dla człowieka.
• JSON-LD (vocabulary & schema) — model semantyczny czytelny maszynowo.
• R2RML — mapowanie relacyjne do RDF.
• RAML Types — kanoniczne kształty jako typy danych RAML.
• SQL DDL — kanoniczne kształty jako przenośny SQL.

Każdy plik do pobrania zawiera pełną definicję CIM w danym formacie, co oznacza, że możesz wdrażać CIM stopniowo: zacznij od formatu obsługiwanego przez Twój bieżący zestaw narzędzi i dodawaj kolejne w miarę wzrostu potrzeb w zakresie interoperacyjności.

Współtworzenie w różnych formatach

Ponieważ CIM jest projektem otwartym, wkład społeczności jest mile widziany — a wieloformatowa struktura kształtuje sposób, w jaki ta współpraca przebiega. Współtwórcy zazwyczaj dzielą się na dwie grupy:

• Współtwórcy modelu proponują nowe encje, relacje lub ograniczenia. Zmiany te są tworzone raz, a następnie propagowane do pozostałych serializacji.
• Współtwórcy formatu poprawiają wierność lub narzędzia konkretnej serializacji — na przykład udoskonalając mapowania R2RML lub przenośność SQL DDL.

Jeśli wnosisz swój wkład, praktyczną zasadą jest zrozumienie, którą warstwę zmieniasz (koncepcyjną czy kanoniczną) i które formaty muszą w rezultacie zostać zregenerowane. Repozytoria projektu na GitHubie oraz internetowy formularz dla współtwórców są punktami wejścia do zaangażowania się w projekt.

Często zadawane pytania

Jaka jest różnica między concepts.json a schema.json w CIM?

concepts.json to model pojęciowy — encje i relacje w CIM, wyrażone jako JSON-LD z semantyką RDF Schema. schema.json to schemat kanoniczny — kształty danych i dodatkowe ograniczenia, wyrażone jako JSON-LD z semantyką SHACL. Krótko mówiąc, concepts opisuje to, co istnieje; schema opisuje, jak musi wyglądać poprawna instancja.

Dlaczego CIM publikuje ten sam model w tak wielu formatach?

Ponieważ różni odbiorcy korzystają z różnych technologii. Magazyn trójek (triple store) potrzebuje RDF; API JSON wymaga JSON Schema; administrator bazy danych potrzebuje SQL DDL; analityk biznesowy potrzebuje czegoś czytelnego dla człowieka. Publikowanie CIM w wielu standardowych formatach pozwala każdemu z tych odbiorców zaadoptować model przy użyciu narzędzi, które już posiadają, zamiast narzucać wszystkim jeden stos technologiczny.

Do czego służy R2RML w CIM?

R2RML to standard W3C służący do mapowania schematu relacyjnej bazy danych na graf RDF. W CIM jest to pomost, który udostępnia istniejące bazy danych SQL jako powiązane dane (linked data) zgodne z CIM, dzięki czemu można łączyć operacyjne systemy relacyjne z warstwą semantyczną bez konieczności ręcznego ich ponownego modelowania.

Czy AML to to samo, co formaty JSON-LD?

Nie. AML jest czytelną dla człowieka formą CIM — słownictwem (concepts.yaml) i dialektem (schema.yaml, schema.raml). JSON-LD to czytelna maszynowo forma oparta na RDF. Opisują ten sam model, ale są skierowane do różnych odbiorców i zestawów narzędzi.

Od jakiego formatu CIM powinienem zacząć?

To zależy od Twojego zastosowania. Jeśli przeglądasz model, zacznij od słownictwa AML. Jeśli budujesz API JSON, zacznij od JSON Schema. Jeśli łączysz relacyjną bazę danych, zacznij od R2RML lub SQL DDL. Jeśli pracujesz z grafem wiedzy, zacznij od JSON-LD i SHACL.

Czy mogę edytować jeden format CIM bez aktualizowania pozostałych?

Można, ale nie należy tego robić. Formaty są serializacjami jednego modelu bazowego, więc ręczna edycja pojedynczego formatu powoduje rozbieżność w całej rodzinie plików. Zamiast tego rozszerz model źródłowy i zregeneruj pozostałe serializacje.

Dalsze czytanie

• World Wide Web Consortium (W3C) — organ normalizacyjny stojący za RDF, RDF Schema, SHACL i R2RML, czyli specyfikacjami, na których opiera się CIM.
• Shapes Constraint Language (SHACL) — informacje o języku ograniczeń używanym do kanonicznych kształtów danych w CIM.
• Linux Foundation — fundacja, w ramach której działa projekt CIM.