Ugyanaz az ügyfél az egyik rendszerben customer_id, a másikban partner_number, a harmadikban account_id. A különbség azonban nem feltétlenül csak az elnevezésben van. Az egyik rendszer szerződő felet, a másik számlafizetőt, a harmadik pedig egy regisztrált felhasználót ért alatta.

Amíg ezeket a fogalmakat egyetlen alkalmazáson belül használjuk, a helyi jelentésük többnyire elegendő. Amikor azonban adatokat integrálunk, riportokat készítünk vagy AI-megoldásokat építünk rájuk, már közös választ kell adnunk egy egyszerűnek tűnő kérdésre:

Mit jelent nálunk az, hogy ügyfél?

A Canonical Data Model erre nem egy újabb technológiai formátummal válaszol. Közös nyelvet teremt az üzleti fogalmak, az adatmodellek, a fizikai platformok és az információ felhasználása között.

A közös modell nem közös adatbázis

A canonical modell célja nem az, hogy minden rendszer ugyanazokat a táblákat, mezőneveket vagy technológiákat használja. Az egyes alkalmazásoknak továbbra is megvan a saját feladatuk, életciklusuk és optimális belső szerkezetük.

A közös modell egy stabil, technológiától lehetőleg független szerződés:

  • meghatározza a fontos üzleti fogalmakat;
  • leírja a közöttük lévő kapcsolatokat;
  • rögzíti az értelmezésükhöz szükséges szabályokat;
  • és ellenőrizhetővé teszi, hogyan kapcsolódnak hozzájuk a különböző forrás- és célrendszerek.

Integrációs környezetben ez gyakran egy semleges szerkezetet jelent, amelyre a források és célok külön-külön képezhetők le. Vállalati adatarchitektúrában ennél tágabb szerepet is kaphat: összekötheti az üzleti szótárat, a logikai modelleket, a platformok fizikai struktúráit, az adatáramlásokat és az analitikai jelentést.

Ebben az írásban a Canonical Data Model kifejezés ezt a tágabb, közös szemantikai gerincet jelenti. Nem egy konkrét gyártó kész adatmodelljét, és nem is egyetlen, mindent átfogó vállalati sémát.

Egy jelentés, öt nézőpontból

A közös jelentés nem egy lépésben születik meg. Ugyanazt a fogalmat több nézőpontból kell leírnunk, majd a nézőpontok közötti kapcsolatokat is meg kell őriznünk.

  1. 01BusinessMit jelent?
  2. 02LogicalHogyan kapcsolódik?
  3. 03PhysicalHol és hogyan él?
  4. 04MappingHogyan feleltethető meg?
  5. 05AnalyticsHogyan válik információvá?

1. Business — a jelentés kiindulópontja

Az első modell még nem táblákról szól. Azt tisztázza, milyen dolgokról, eseményekről és szabályokról beszél a szervezet.

Az „ügyfél” mellett például meg kell jelennie annak is, hogy:

  • természetes vagy jogi személyről beszélünk-e;
  • milyen szerepben kapcsolódik a szervezethez;
  • mitől válik aktívvá;
  • egy ügyfélhez hány szerződés vagy fiók tartozhat;
  • és mely események változtatják meg az állapotát.

Ezen a szinten az üzleti definíció, a felelősség és a döntési szabály fontosabb, mint a technikai reprezentáció. A jó kiindulópont olyan mondatokból áll, amelyeket az üzleti és technológiai szereplők ugyanúgy értenek.

2. Logical — a jelentés szerkezete

A logikai modell az üzleti fogalmakból entitásokat, attribútumokat, azonosítókat, kapcsolatokat és szabályokat formál. Továbbra sem egy konkrét adatbázishoz készül: azt mutatja meg, milyen adatszerkezet képes következetesen hordozni a közös jelentést.

Itt válik láthatóvá például, hogy az ügyfél önálló entitás-e, vagy egy személy vagy szervezet adott szerepe; hogyan kapcsolódik a szerződéshez; milyen azonosítók tartoznak hozzá; és mely kapcsolatokat kell időben is követni.

A logikai modell egyik legfontosabb tulajdonsága, hogy vitathatóvá és ellenőrizhetővé teszi a jelentést. Egy kapcsolat, kardinalitás vagy kötelező attribútum már nem marad kimondatlan feltételezés.

3. Physical — a jelentés megvalósítása

Ugyanaz a logikai modell több fizikai formában is megvalósulhat.

Egy operatív alkalmazás normalizált relációs táblákat használhat. Egy eseményvezérelt integráció üzeneteket továbbíthat. Egy lakehouse oszloporientált fájlokban tárolhatja az adatot. Egy adattárház Data Vault szerkezetet, az analitikai réteg pedig csillagsémát alkalmazhat.

Ezek nem egymással versengő igazságok. Különböző feladatokra optimalizált fizikai nézőpontok. A kapcsolatot az teremti meg közöttük, hogy visszavezethetők ugyanahhoz a logikai jelentéshez.

A fizikai modell ezért technológiaspecifikus döntéseket is tartalmaz: adattípusokat, kulcsokat, partíciókat, tárolási és teljesítménybeli megoldásokat. Ezek változhatnak anélkül, hogy az „ügyfél” üzleti jelentését újra kellene alkotni.

4. Mapping — ahol a modellek találkoznak

A mapping nem a tervezés utáni adminisztráció. Ez teszi bizonyíthatóvá, hogy a közös jelentés valóban végighalad az adat útján.

Egy használható leképezés megmutatja:

  • mely forrásmező mely canonical attribútumhoz kapcsolódik;
  • milyen átalakítás történik;
  • hogyan fordítjuk le a kódértékeket;
  • hogyan kezeljük a hiányzó vagy többértelmű adatot;
  • melyik szabály és verzió volt érvényes az adott időpontban;
  • és hogyan jut tovább az adat a célmodellbe.

Ha például a CRM ACTIVE, az ERP A értékkel jelöli ugyanazt az állapotot, a közös modell önmagában még nem oldotta meg a kérdést. A leképezés rögzíti, hogy ezek valóban ugyanazt jelentik-e, milyen feltételek mellett feleltethetők meg egymásnak, és mi legyen a canonical értékük.

A mapping így egyszerre integrációs specifikáció, adatleszármazási kapcsolat és tesztelhető szakmai szabály.

5. Analytics — amikor az adat információvá válik

Az analitikai modellnek más a feladata, mint az integrációs vagy tranzakciós modellnek. Döntési kérdésekre kell jól és következetesen válaszolnia.

Ezért a canonical modell nem helyettesíti a szemantikai réteget, a dimenziókat, a tényeket vagy a KPI-definíciókat. Stabil jelentésbeli alapot ad hozzájuk.

Az „aktív ügyfelek száma” mutató például csak akkor összehasonlítható, ha tisztázott:

  • mit számítunk ügyfélnek;
  • mely szerepeket vesszük figyelembe;
  • milyen időpontra vonatkozik az aktivitás;
  • hogyan kezeljük az összevont vagy duplikált azonosítókat;
  • és mely események változtatják meg a státuszt.

Az analitika ezen a ponton nem új jelentést talál ki, hanem a közösen meghatározott jelentést rendezi a döntéshozatal számára használható nézőpontba.

Egy rövid példa: három rendszer, egy ügyfélfogalom

Tegyük fel, hogy három rendszerből érkezik adat:

  • a CRM az értékesítési kapcsolatot kezeli;
  • a számlázási rendszer a fizető felet tartja nyilván;
  • a webes felület a regisztrált felhasználót azonosítja.

A canonical modell nem mondja azt, hogy mindhárom rekord automatikusan ugyanaz az ügyfél. Ehelyett közös fogalmakat és kapcsolatokat ad: Party, Customer Role, Account, Contract és az ezekhez tartozó azonosítók.

Ezután a mapping réteg írja le, hogy az egyes rendszerek rekordjai melyik fogalomhoz és milyen szabály alapján kapcsolódnak. Az analitikai modell pedig már erre az ellenőrizhető kapcsolatrendszerre építheti az ügyfélhez, szerződéshez vagy aktivitáshoz tartozó mutatókat.

A közös nyelv értéke itt válik kézzelfoghatóvá: a különböző rendszereknek nem kell azonosnak lenniük ahhoz, hogy az adataik következetesen együtt használhatók legyenek.

Mitől marad használható a modell?

Egy jól körülhatárolt területtel kezdődik

A közös modell fokozatosan építhető. Egy üzleti terület, egy fontos adatáramlás vagy egy döntési kérdés elég erős kezdőpont. A használat közben szerzett tapasztalatok alapján a modell új fogalmakkal és kapcsolatokkal bővíthető.

Van gazdája és életciklusa

A fogalmak, szabályok és leképezések változnak. A verziózás, a felelősségek és a változások hatásának követése ezért a modell része. A canonical modell nem egyszer elkészített rajz, hanem kezelt szakmai termék.

A kapcsolatok ugyanolyan fontosak, mint a modellek

Az üzleti, logikai, fizikai és analitikai nézőpont önmagában is lehet precíz. A teljes rendszer attól válik következetessé, hogy a köztük lévő leképezések is láthatók, ellenőrizhetők és karbantarthatók.

Teret hagy a célspecifikus modelleknek

Egy integrációs üzenet, egy Data Vault réteg és egy csillagséma más feladatot lát el. A közös modell nem eltünteti ezeket a különbségeket, hanem biztosítja, hogy mindegyik ugyanahhoz a jelentéshez kapcsolódjon.

A lényeg

A Canonical Data Model nem attól közös, hogy minden adatot egyetlen sémába gyűjt. Attól válik valóban közös modellé, hogy a szervezet fontos fogalmaihoz közös jelentést, világos kapcsolatokat és ellenőrizhető leképezéseket ad.

Az út ezért nem egyszerűen technikai átalakítások sorozata:

Business → Logical → Physical → Mapping → Analytics

Ez annak a története, hogyan őrizzük meg a jelentést az üzleti kérdéstől a használható információig.

Források és további olvasmányok