Model CIM

(CIM) to otwarty, niezależny od aplikacji model danych, którego zadaniem jest zapewnienie przedsiębiorstwom wspólnego słownictwa dla encji pojawiających się w systemach CRM, ERP, marketingowych, serwisowych i analitycznych. Zamiast wymyślać przez każdego dostawcę własne nazwy obiektów i relacje, CIM definiuje wspólny zestaw obszarów tematycznych, encji i atrybutów, do których może być mapowany każdy system. Model jest zarządzany jako projekt open source w ramach The Linux Foundation, która hostuje szerokie portfolio wspólnych projektów dotyczących danych i infrastruktury.

W tym artykule wyjaśniono, jak zbudowany jest CIM, jak jego komponenty są ze sobą powiązane, jak działają supertypy i podtypy oraz jak zorganizowane są obszary tematyczne. Omówiono także praktyczne decyzje, przed którymi stoi architekt podczas wdrażania CIM — mapowanie, ład danych (governance), wersjonowanie i rozszerzanie — oraz to, gdzie model sytuuje się względem innych standardów branżowych.

Kluczowe wnioski

• CIM organizuje koncepcje biznesowe w Obszary tematyczne, z których każdy zawiera Grupy encji, Encje i Atrybuty — hierarchię, która w przejrzysty sposób odwzorowuje schematy, tabele i kolumny.
• Supertypy i podtypy pozwalają modelowi wyrażać wspólne cechy (np. Strona, która jest osobą lub organizacją), jednocześnie umożliwiając specjalizację.
• Model jest celowo niezależny od aplikacji: opisuje koncepcje biznesowe, a nie implementację konkretnego dostawcy.
• CIM jest publikowany w wielu formatach z przykładowymi diagramami, dzięki czemu może być wykorzystywany zarówno przez narzędzia do modelowania, generatory kodu, jak i w dokumentacji.
• Liczba i zakres obszarów tematycznych rośnie wraz z wkładem konsorcjum i społeczności, dlatego wdrożenie powinno uwzględniać wersjonowanie i zarządzanie zmianami.
• CIM jest jedną z kilku opcji; właściwy wybór zależy od tego, czy potrzebujesz szerokiego modelu międzydomenowego, czy wąskiego, głębokiego standardu dla jednej branży.

Jak zbudowany jest CIM

CIM jest podzielony na komponenty, dzięki czemu można łatwiej nawigować po treściach i z nich korzystać. Każdy poziom hierarchii odpowiada na inne pytanie, a zrozumienie tej hierarchii jest pierwszym krokiem do efektywnego wykorzystania modelu.

• Obszar tematyczny (Subject Area) — Główna koncepcja biznesowa zidentyfikowana przez konsorcjum CIM, taka jak Strona (Party). Każdy obszar tematyczny zawiera jedną lub więcej grup encji. Pomyśl o obszarze tematycznym jako o ograniczonym kontekście (bounded context): grupuje on wszystko, co firma musi wiedzieć na temat jednego szerokiego tematu.
• Grupa encji (Entity Group) — Logiczne grupowanie powiązanych encji w ramach obszaru tematycznego, takie jak Konto (Account). Grupy encji sprawiają, że duże obszary tematyczne pozostają przejrzyste i dają zespołom naturalną jednostkę do przypisywania odpowiedzialności.
• Encja (Entity) — Unikalny obiekt, o którym organizacja zbiera informacje, np. Kontakt do konta (Account Contact). Encja jest analogiczna do standardowej tabeli bazy danych.
• Atrybut (Attribute) — Unikalna cecha encji, taka jak Id konta lub E-mail kontaktu. Atrybut jest analogiczny do standardowego pola bazy danych w tabeli.

Ta czteropoziomowa hierarchia jest celowo znajoma. Architekci danych, którzy pracowali z modelowaniem relacyjnym, modelowaniem wymiarowym lub diagramami encja-relacja, natychmiast rozpoznają ten wzorzec. Wartością, jaką dodaje CIM, nie jest nowa technika modelowania, ale wspólny, wcześniej wynegocjowany zestaw nazw i relacji, na który może zgodzić się wiele organizacji i dostawców.

Przydatny model mentalny: obszar tematyczny to w przybliżeniu schemat lub domena; grupa encji to w przybliżeniu przestrzeń nazw lub moduł; encja to tabela; atrybut to kolumna. To mapowanie jest przybliżone — CIM to model koncepcyjny i logiczny, a nie fizyczny — ale pomaga, gdy przekładasz CIM na fizyczną implementację.

Supertypy i podtypy

Poza czterema podstawowymi komponentami, projekt CIM dostosowuje i rozszerza encje na dalsze grupy przy użyciu supertypów i podtypów. To tutaj model zyskuje znaczną część swojej mocy wyrazu.

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

• Supertyp (Supertype) — Encja, która jest rozszerzana przez encje podtypów i definiuje wspólne atrybuty dla podobnych pojęć.
• Podtyp (Subtype) — Encja, która rozszerza inną encję i dziedziczy atrybuty z encji supertypu.

Klasycznym przykładem jest Strona (Party). Stroną jest każda osoba lub podmiot, z którym firma wchodzi w interakcje. Osoba i organizacja są stronami i dzielą wspólne atrybuty — nazwę, identyfikatory, punkty kontaktowe — ale każda z nich posiada atrybuty, których nie ma druga.

Modelowanie Strony jako supertypu z Osobą i Organizacją jako podtypami pozwala uniknąć powielania wspólnych atrybutów i utrzymuje relacje (na przykład „ta szansa sprzedaży należy do tej strony”) spójnie, niezależnie od tego, który podtyp jest zaangażowany.

Dziedziczenie tego typu jest dobrze ugruntowaną koncepcją w modelowaniu danych i pojawia się w standardach takich jak UML (Object Management Group) oraz w konwencjach encja-relacja stosowanych w całej branży. Podczas fizycznej implementacji CIM musisz zdecydować, jak reprezentować dziedziczenie:

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

• Pojedyncza tabela (Single table) — przechowywanie wszystkich podtypów w jednej tabeli z kolumną dyskryminatora. Proste w zapytaniach, ale może generować wiele kolumn dopuszczających wartość null.
• Dziedziczenie tabel klas (Class table inheritance) — jedna tabela dla supertypu i jedna dla każdego podtypu, połączone wspólnym kluczem. Znormalizowane i przejrzyste, ale wymaga złączeń (joins).
• Dziedziczenie tabel konkretnych (Concrete table inheritance) — oddzielna, samodzielna tabela dla każdego podtypu. Szybkie w przypadku zapytań specyficznych dla podtypu, ale duplikuje wspólne atrybuty.

Nie ma jednej, uniwersalnie poprawnej odpowiedzi. Właściwy wybór zależy od wzorców zapytań, liczby podtypów i tego, jak często wspólne atrybuty są odczytywane razem. Udokumentuj tę decyzję, ponieważ będzie ona miała wpływ na każdą dalszą integrację.

Obszary tematyczne CIM

Obszary tematyczne reprezentują główne koncepcje biznesowe opracowane dotychczas przez konsorcjum. Każdy z nich jest publikowany z własnymi diagramami i formatami, a kilka posiada wyraźne oznaczenia wersji (na przykład v1.0 lub v0.1.1), co odzwierciedla fakt, że niektóre obszary są bardziej dojrzałe niż inne.

Setup — definiuje, z kim współpracujesz, na przykład z klientem, dostawcą i sprzedawcą. Obejmuje także koncepcje oprogramowania i infrastruktury, którymi operuje organizacja: Software Host, Software Tenant, Software User, Software App, Software Test, Software Service, Software Batch Job oraz IoT Device.

Data Model — same podstawowe koncepcje modelowania.

Hire — działania związane z konfiguracją firmy, na przykład wewnętrzna jednostka biznesowa i pracownik. Grupy encji obejmują Job Application, Employee, Compensation, Training, Location, Work Territory oraz Work Report.

Biz Process — koncepcje procesów biznesowych i ciągłości działania.

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

Produce — obsługa materiałów, które będziesz kupować, przenosić i sprzedawać, na przykład produkt i produkt magazynowy. Grupy encji obejmują Supplier Product, Inventory Received, Inventory Product, Inventory Transfer, Electronic Media, Purchase Order oraz Sales Agreement.

Market — działania wykorzystywane do promocji produktu, na przykład kampania marketingowa i sklep internetowy. Grupy encji obejmują Party Resolution, Privacy Consent, Market Audience, Campaign, Promotion, Trade Event, Ad Buy oraz Web Site.

Sell — działania wykorzystywane do sprzedaży produktu, na przykład tworzenie ofert i szans sprzedaży. Grupy encji obejmują Price Book, Shopping Cart, Quote, Contract, Opportunity, Opportunity Forecast, Sales Order, Loyalty Program oraz Competitor.

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

Service — działania mające na celu zapewnienie wsparcia dla sprzedanego lub serwisowanego produktu, na przykład sprawa lub ankieta. Grupy encji obejmują AI Assistant, Asset, Asset Subscription, Web Content, Case, Task oraz Event.

Fulfill — czynności, które wykonujesz w celu realizacji zamówienia klienta, na przykład wysyłka i zamówienie zwrotne. Grupy encji obejmują Fulfillment Order, Shipment, Return Order, Work Order, Work Resource oraz Work Forecast.

Interact — działania służące do śledzenia interakcji z użytkownikami końcowymi lub innymi systemami. Grupy encji obejmują Engagement, Conversation, Appointment, Software Event, Data Connector, Data Movement, Loyalty Journey oraz Loyalty.

Finance — działania mające na celu śledzenie informacji finansowych w firmie, na przykład płatność, faktura i raport wydatków. Grupy encji obejmują Budget, Invoice, Payment Method, Payment, Credit Memo, Financial Ledger Account, Forecast, Calendar oraz Tax Policy.

Analyze — czynności związane z analizą danych, na przykład analizowanie wzorców, wykorzystania produktów, przemieszczania danych, zmian danych i zadowolenia klienta. Grupy encji obejmują AI Model, AI Application, IoT Device Use, Data Lineage, Blockchain, Survey, Loyalty oraz Journal.

Zwróć uwagę, że obszary tematyczne obejmują zarówno kwestie operacyjne (Sell, Fulfill, Service), jak i analityczne (Analyze, Finance). Ta szerokość jest kluczowa: wspólny model jest najcenniejszy, gdy może spójnie opisywać tego samego klienta, produkt lub zamówienie, niezależnie od tego, czy dane znajdują się w systemie transakcyjnym, czy w magazynie danych.

Wybór pomiędzy CIM a innymi standardami

CIM nie jest jedynym wspólnym modelem w przedsiębiorstwie. Kilka uznanych standardów pokrywa się z częściami jego zakresu, a dojrzała architektura często wykorzystuje więcej niż jeden. Decyzja nie polega na wyborze zwycięzcy, a raczej na dopasowaniu szerokości modelu i ładu (governance) do Twojego problemu.

Standard	Główny cel	Typowa zaleta	Czym CIM się różni
CIM	Międzydomenowe koncepcje biznesowe	Szeroki, niezależny od aplikacji zasięg CRM/ERP/marketingu/serwisu	Zaprojektowany jako wspólny parasol nad domenami
OMG Common Core Ontologies / modele oparte na UML	Notacja modelowania koncepcyjnego i ontologie górne	Rygorystyczna semantyka formalna	CIM jest bardziej bezpośrednio zorientowany na biznes
Modele specyficzne dla branży (np. handel detaliczny, opieka zdrowotna, finanse)	Głębokie pokrycie jednego sektora	Precyzja w obrębie pionu	CIM przedkłada szerokość nad głębokość
Modele danych dostawców (platformy CRM/ERP)	Obiekty jednego produktu	Ścisła integracja z tym produktem	CIM jest z założenia neutralny dla dostawców

Praktyczna zasada:

• Jeśli potrzebujesz wspólnego słownictwa dla wielu systemów i dostawców, szeroki model taki jak CIM będzie odpowiednim wyborem.
• Jeśli potrzebujesz głębokiej, regulowanej, specyficznej dla branży semantyki, standard pionowy będzie zazwyczaj bardziej precyzyjny, a Ty możesz go zmapować do CIM na granicach systemów.
• Jeśli integrujesz dane w ramach ekosystemu jednego dostawcy, własny model tego dostawcy może być wystarczający — ale nie pomoże Ci to połączyć się z kolejnym dostawcą.

Najpopularniejszym wzorcem w świecie rzeczywistym jest podejście hub-and-spoke (centrum i szprychy): CIM (lub inny model kanoniczny) znajduje się w centrum, a każdy system źródłowy jest do niego mapowany. Jest to ta sama zasada, która stoi za kanonicznymi modelami danych w zarządzaniu danymi podstawowymi (MDM) oraz za ideą „wymiaru zgodnego” (conformed dimension) spopularyzowaną w modelowaniu wymiarowym przez Ralpha Kimballa.

Praktyczne wskazówki dotyczące wdrażania CIM

Przyjęcie wspólnego modelu jest w równym stopniu ćwiczeniem organizacyjnym, co technicznym. O tym, czy wysiłek się opłaci, decyduje kilka decyzji.

Zacznij od ograniczonego zakresu. Nie próbuj mapować każdego systemu do każdego obszaru tematycznego naraz. Wybierz jedną domenę o wysokiej wartości — Party i Sell są częstymi punktami wyjścia, ponieważ dane o klientach i szansach sprzedaży są powszechnie duplikowane — i udowodnij mapowanie od początku do końca.

Wcześnie określ politykę rozszerzeń. CIM został zaprojektowany tak, aby rozwijać się wraz z konsorcjum i wkładami, ale Twoja organizacja nieuchronnie będzie potrzebować atrybutów, których model jeszcze nie definiuje. Ustal konwencję rozszerzeń lokalnych (na przykład przedrostek przestrzeni nazw), aby atrybuty niestandardowe były wyraźnie odróżnialne od standardowych i mogły zostać później uzgodnione.

Traktuj wersjonowanie jako kwestię pierwszorzędną. Obszary tematyczne posiadają znaczniki wersji, takie jak v1.0 i v0.1.1, co sygnalizuje, że model ewoluuje. Przypnij wersję, na podstawie której budujesz, śledź zmiany i planuj migrację. Jest to ta sama dyscyplina, którą zastosowałbyś do każdej zależności.

Mapuj, nie kopiuj. CIM jest modelem koncepcyjnym i logicznym. Oprzyj się pokusie generowania schematów fizycznych bezpośrednio z niego bez uwzględnienia wydajności, indeksowania i wzorców dostępu systemów, które będą konsumować dane. Użyj modelu, aby uzgodnić znaczenie, a następnie zaprojektuj fizyczną pamięć masową dla swojego obciążenia pracą.

Zarządzaj mapowaniem. Mapowanie pomiędzy systemem źródłowym a CIM samo w sobie jest zasobem. Wersjonuj je, przeglądaj i przypisz do niego właściciela. Narzędzia z zakresu integracji danych — platformy ETL i ELT, katalogi danych i narzędzia do analizy pochodzenia (lineage) — mogą pomóc śledzić, skąd pochodzi każdy atrybut i jak przepływa, co jest dokładnie tym rodzajem metadanych, jakiego oczekuje obszar tematyczny Analyze z encjami takimi jak Data Lineage.

Zaangażuj społeczność. Ponieważ CIM jest projektem open source zarządzanym przez konsorcjum, luki, które znajdziesz, są często lukami, które odkryli także inni. Przekazanie proponowanej encji lub atrybutu z powrotem do projektu jest zarówno przejawem dobrej obywatelskości, jak i sposobem na zmniejszenie długoterminowego obciążenia związanego z utrzymaniem.

Formaty, diagramy i konsumpcja

Projekty CIM są dostępne w wielu formatach dla każdej domeny, w tym w formie przykładowych diagramów. Ma to znaczenie, ponieważ różni odbiorcy w różny sposób konsumują model danych:

• Architekci potrzebują diagramów i widoków relacji, aby analizować strukturę.
• Inżynierowie potrzebują definicji czytelnych maszynowo, które mogą wprowadzić do narzędzi generowania kodu, walidacji schematów lub mapowania.
• Analitycy i stewardzi potrzebują dokumentacji wyjaśniającej, co każda encja i atrybut oznaczają w terminach biznesowych.

Publikowanie w wielu formatach to świadomy wybór projektowy, który obniża barierę adopcji. Oceniając dowolny współdzielony model, sprawdź, czy jest on dostarczany w formatach, które Twój łańcuch narzędzi może faktycznie zaimportować — model, który istnieje tylko jako PDF, jest znacznie mniej użyteczny niż taki z ustrukturyzowanymi definicjami.

Często zadawane pytania

Czym jest Cloud Information Model (CIM)?

Cloud Information Model to otwarty, niezależny od aplikacji model danych, który definiuje wspólne koncepcje biznesowe — takie jak Party, Account i Sales Order — aby różne systemy chmurowe i lokalne mogły wymieniać dane przy użyciu wspólnego słownictwa. Jest on zorganizowany w obszary tematyczne, grupy encji, encje i atrybuty oraz jest zarządzany jako projekt open source w ramach The Linux Foundation.

Jaka jest różnica między nadtypem a podtypem w CIM?

Nadtyp to encja, która jest rozszerzana przez encje podtypów i definiuje atrybuty wspólne dla podobnych pojęć. Podtyp rozszerza inną encję i dziedziczy atrybuty swojego nadtypu. Na przykład Party może pełnić rolę nadtypu, a Person i Organization rolę podtypów, dzięki czemu wspólne atrybuty są definiowane raz, a atrybuty wyspecjalizowane znajdują się w podtypie.

Jak CIM odnosi się do schematu bazy danych?

CIM jest modelem koncepcyjnym i logicznym, a nie schematem fizycznym. Jego encje są analogiczne do tabel bazy danych, a atrybuty do pól, co sprawia, że translacja jest intuicyjna, ale nadal powinieneś projektować fizyczną pamięć masową — indeksowanie, partycjonowanie, denormalizację — w oparciu o własne wzorce zapytań, zamiast kopiować model dosłownie.

Czy CIM jest zamiennikiem dla branżowych standardów danych?

Nie. CIM jest szeroki i międzydomenowy, podczas gdy standardy wertykalne są głębokie i specyficzne dla danego sektora. Wiele organizacji stosuje podejście hub-and-spoke, w którym CIM służy jako model kanoniczny w centrum, a standardy branżowe lub modele dostawców są do niego mapowane na obrzeżach.

Dlaczego obszary tematyczne CIM mają numery wersji?

Znaczniki wersji, takie jak v1.0 i v0.1.1, wskazują, że model ewoluuje i że niektóre obszary tematyczne są bardziej dojrzałe od innych. Przypinanie wersji, śledzenie zmian i planowanie migracji to ta sama dyscyplina zarządzania zależnościami, którą zastosowałbyś do dowolnej współdzielonej biblioteki lub schematu.

Jak obsługiwać atrybuty, których CIM nie definiuje?

Ustal udokumentowaną konwencję rozszerzeń, np. przedrostek przestrzeni nazw, aby atrybuty niestandardowe były wyraźnie odróżnialne od standardowych. Następnie rozważ zgłoszenie tej luki z powrotem do projektu, ponieważ model został zaprojektowany tak, aby rozwijać się dzięki wkładom konsorcjum i społeczności.