Znasz ten moment: finanse mają jedną liczbę przychodów w systemie CRM, pulpit nawigacyjny magazynu pokazuje inną, a lider pyta przy wszystkich, która z nich jest prawidłowa. Niewygodna odpowiedź brzmi: oba systemy mogą mówić prawdę na swój własny sposób, ale nie służą do tej samej pracy. To jest sedno różnicy między system of record a source of truth, a błędne zrozumienie tego rozróżnienia sprawia, że zespoły wdrażają uszkodzone pulpity nawigacyjne, niejasne audyty i powoli reagują na incydenty.

Spis treści

• Dlaczego to rozróżnienie ma znaczenie w nowoczesnej architekturze danych

  • Warstwa operacyjna i warstwa analityczna

• Różnice mechaniczne między System of Record a Source of Truth

  • Zakres, własność i zachowanie podczas odświeżania

• Jak każdy z tych konceptów zawodzi w środowisku produkcyjnym

  • Jak wygląda awaria w warstwie operacyjnej

  • Jak wygląda awaria w warstwie agregacji

• Kryteria decyzyjne przy wyborze lub uzgadnianiu SOR i SOT

  • Używaj właściwej warstwy do właściwego pytania

• Jak Data Observability wspiera niezawodne SOR i SOT

  • Co powinno monitorować observability

• Lista kontrolna wdrożenia i zalecane architektury

  • Praktyczna lista kontrolna

  • Wzorce architektury, które się sprawdzają

• Zastosowania w rzeczywistych warunkach w branżach regulowanych

  • Co zmienia się w zależności od branży

Dlaczego to rozróżnienie ma znaczenie w nowoczesnej architekturze danych

Zespół ds. finansów może spędzić godzinę na debacie nad rozbieżnością w przychodach, która w rzeczywistości jest problemem systemowym. Jeden raport korzysta z CRM, który służy jako system of record dla operacyjnych danych klientów, podczas gdy inny korzysta z hurtowni danych, która została ukształtowana w source of truth do raportowania międzyfunkcyjnego. IBM opisuje system of record jako autorytatywne źródło dla domeny lub procesu biznesowego, podczas gdy source of truth harmonizuje wiele systemów of record w kompletny widok między domenami. Ta różnica ma znaczenie, ponieważ systemy te są zbudowane do różnych zadań, a nie dlatego, że jeden jest bardziej „prawdziwy” od drugiego. Wyjaśnienie IBM dotyczące system of record a source of truth wyraźnie pokazuje ten podział architektoniczny.

Warstwa operacyjna i warstwa analityczna

Najprościej myśleć o tym w kategoriach: operacyjny versus analityczny. System of Record to operacyjny magazyn, który przechwytuje, weryfikuje, aktualizuje i przechowuje autorytatywne rekordy dla jednej jednostki biznesowej i nie jest używany bezpośrednio do raportowania ani analityki. Dlatego platforma kadrowa, ERP lub CRM może być systemem of record dla własnych danych, podczas gdy hurtownia lub zarządzana warstwa semantyczna staje się source of truth dla raportowania korporacyjnego. Podział systemów operacyjnych i analitycznych autorstwa Petera Ritchie'ego jest użyteczny, ponieważ pokazuje, że to rozróżnienie nie jest szumem semantycznym, ale granicą architektoniczną.

Praktyczną korzyścią jest zaufanie. Jeśli pulpit nawigacyjny ma odpowiadać na pytanie, co wydarzyło się w całej firmie, nie powinien pobierać danych bezpośrednio z odizolowanych magazynów operacyjnych i oczekiwać, że same się dopasują. Jeśli system transakcyjny ma zachować autorytatywny adres klienta, nie powinien zawierać logiki agregacji na poziomie przedsiębiorstwa.

Zasada praktyczna: używaj system of record do przechwytywania i kontroli, a source of truth do wspólnej interpretacji.

Ten podział stał się kluczowy, gdy przedsiębiorstwa przeszły od pojedynczych operacyjnych baz danych do wielosystemowych architektur danych. Nowoczesne wytyczne traktują SOR i SOT jako pojęcia uzupełniające się, a nie synonimy stosowane zamiennie, ponieważ każde z nich rozwiązuje inny tryb awarii. Kiedy ludzie je ze sobą łączą, rezultat jest zwykle taki sam: sprzeczne liczby, opóźnione decyzje i długie spotkanie, na które nikt nie miał ochoty.

Różnice mechaniczne między System of Record a Source of Truth

Konkretna różnica ujawnia się w zachowaniu produkcyjnym. System of record jest zoptymalizowany pod kątem jednej domeny, często zapisywany i zbudowany w celu zachowania spójności transakcyjnej w momencie zapisu. Source of truth ma szerszy zakres, jest nastawiony na odczyt i zbudowany tak, aby uzgadniać autorytatywne dane wejściowe w zarządzany widok, z którego mogą korzystać decydenci. Porównanie SOR i SOT przygotowane przez Nutrient wyraźnie rysuje tę granicę, zwłaszcza różnicę między operacyjnym magazynem działającym w czasie zbliżonym do rzeczywistego a okresowo odświeżanym widokiem analitycznym. Porównanie SOR i SOT firmy Nutrient zwraca również uwagę na praktyczną kwestię: SOR służy jednej domenie, podczas gdy SOT daje organizacji wspólny widok.

Zakres, własność i zachowanie podczas odświeżania

SOR to miejsce, w którym dane są tworzone i zarządzane. Ujęcie Rework pomaga, ponieważ oddziela zbiór reguł od warstwy przechowywania: source of truth definiuje, jak dane powinny być interpretowane, a system of record to miejsce, w którym te dane są przechowywane. Dlatego zespół ds. sprzedaży wprowadza nowego klienta, finanse rejestrują fakturę, a kadry aktualizują akta pracownika w SOR, podczas gdy kierownictwo opiera się na SOT w celu uzyskania spójnego widoku tych rekordów. Wyjaśnienie source of truth i system of record przez Rework pokazuje również, dlaczego hurtownia danych może służyć jako SOT, mimo że nie jest źródłem faktów.

Mechanika zaufania jest inna. Systemy SOR doskonale sprawdzają się w przechwytywaniu danych w danym momencie, ale same nie rozwiązują problemu duplikatów ani nie uzupełniają brakujących pól bez dodatkowych kontroli. SOT zależą od wzbogacania, weryfikacji i uzgadniania, więc ich niezawodność zależy od jakości danych wejściowych i ciągłej walidacji. Dlatego Observability ma znaczenie, zanim dane trafią do pulpitów nawigacyjnych. Narzędzia takie jak kontrole pojedynczego źródła AutoProv są przydatne w praktyce, ponieważ ujawniają luki, niedopasowania i brak pokrycia źródeł, zanim uszkodzony rekord zostanie uznany za autorytatywny.

SOR może być poprawny dla jednego podmiotu, a mimo to stanowić słabą podstawę do raportowania korporacyjnego. SOT może być autorytatywny dla pytania biznesowego, a jednocześnie zależeć od kilku leżących pod nim systemów of record.

Ta różnica wyjaśnia, dlaczego zachowanie podczas odświeżania ma znaczenie. Magazyn transakcyjny może zawierać najświeższy fakt dla pojedynczego rekordu, podczas gdy zarządzana warstwa analityczna może zawierać najbardziej użyteczną odpowiedź wielodomenową do celów planowania i raportowania. Jeśli te zadania zostaną połączone, każdy odbiorca musi zgadywać, której warstwie zaufać, co zazwyczaj skutkuje niespójnymi liczbami i powolnymi korektami.

Jak każdy z tych konceptów zawodzi w środowisku produkcyjnym

Tryby awarii są różne, więc scenariusz postępowania w przypadku incydentu również powinien być inny. System of record zawodzi, gdy sam rekord jest niekompletny, duplikaty pozostają nierozwiązane lub zmiana schematu psuje procesy odbiorców, którzy od niego zależą. Source of truth zawodzi, gdy jakość danych wejściowych jest niska, ETL dostarcza nieaktualne dane lub logika uzgadniania pomija konflikt między dwoma systemami, z których każdy uważa się za poprawny. Ta różnica ma znaczenie na produkcji, ponieważ punkt awarii zmienia miejsce, w którym najpierw szukasz problemu i gdzie umieszczasz kontrole. Observability musi wychwycić problem, zanim dotrze on do pulpitów nawigacyjnych, dlatego narzędzia takie jak kontrole pojedynczego źródła AutoProv są przydatne w praktyce, gdy zespoły muszą wcześnie wykryć luki, niedopasowania i brak pokrycia źródeł.

Jak wygląda awaria w warstwie operacyjnej

Awarie operacyjne zazwyczaj pojawiają się najpierw jako problemy z wprowadzaniem danych lub integracją. Zduplikowany rekord klienta może utworzyć dwie tożsamości w systemach niższego szczebla. Zmiana schematu może zepsuć integrację, która oczekiwała istnienia danego pola lub stabilności typu. Jeśli kontrole przechwytywania są słabe, system źródłowy może wiernie przechowywać złe dane, co jest gorsze niż ich utrata, ponieważ złe dane wyglądają wtedy na autorytatywne.

Warstwa operacyjna zawodzi w punkcie zapisu. To jest ten kompromis. Jest ona zbudowana do przechwytywania, walidacji, aktualizacji i przechowywania rekordów, więc słabość w którymkolwiek z tych kroków zamienia system of record w niezawodne miejsce do przechowywania niewiarygodnych faktów. Ujęcie System of Record i Single Source of Truth przez Petera Ritchie'ego jest tutaj przydatne, ponieważ pozwala skupić się na wierności operacyjnej, a nie na zachowaniu raportowania.

Jak wygląda awaria w warstwie agregacji

Awarie SOT są często cichsze, co utrudnia ich zauważenie. Hurtownia danych może nadal ładować dane zgodnie z harmonogramem, będąc jednocześnie w błędzie, ponieważ jedno źródło upstream jest nieaktualne, jedna reguła scalania jest przestarzała lub jedno założenie dotyczące deduplikacji przestało obowiązywać w zeszłym tygodniu. Warstwa ta nadal wygląda na zdrową z zewnątrz, ale prezentowana przez nią odpowiedź może odbiegać od rzeczywistości biznesowej, którą ma podsumowywać. Dlatego zespoły potrzebują wglądu we wzorce napływu danych, zmiany strukturalne i kontrole reguł biznesowych, zanim problem dotrze do pulpitu nawigacyjnego.

Dla zespołów, które potrzebują konkretnego punktu odniesienia dla tego rodzaju kontroli, uzgadnianie danych leży w samym centrum problemu. Jest to dyscyplina, która ujawnia, kiedy rekordy się nie zgadzają, kiedy brakuje jednego ze źródeł i kiedy „zaufany” agregat niesie ze sobą nieaktualny lub częściowy widok. Source of truth zależy od tych kontroli, ponieważ autorytet bez weryfikacji to tylko etykieta.

Pytanie o przyczynę źródłową jest proste, ale zespoły zbyt często je pomijają. Czy błędny rekord powstał w magazynie operacyjnym, czy stał się mylący po agregacji i uzgodnieniu? Jeśli nie odpowiesz na to jednoznacznie, marnujesz czas na obwinianie niewłaściwej warstwy i niewłaściwego zespołu.

Kryteria decyzyjne przy wyborze lub uzgadnianiu SOR i SOT

Zacznij od własności. Jeśli zespół tworzy i utrzymuje dane w ramach żywego procesu biznesowego, system ten jest zazwyczaj system of record dla tej domeny. Jeśli celem jest przedstawienie zharmonizowanego widoku w różnych domenach na potrzeby raportowania, planowania lub nadzoru, warstwa ta jest zazwyczaj source of truth. Błędem jest próba zmuszenia jednego systemu do dobrego wykonywania obu tych zadań, ponieważ ścieżka zapisu wymaga ścisłego zachowania transakcyjnego, podczas gdy ścieżka odczytu wymaga szerokiej integracji i historii.

Używaj właściwej warstwy do właściwego pytania

Zarządzana hurtownia danych lub warstwa semantyczna jest często właściwym SOT, gdy finanse, sprzedaż i operacje potrzebują jednego widoku biznesu. Systemy operacyjne pozostają autorytatywne dla własnych rekordów, podczas gdy hurtownia staje się uzgodnioną warstwą raportowania, ponieważ łączy wiele autorytatywnych danych wejściowych. Ten wzorzec działa, ponieważ szanuje rzeczywistość architektoniczną, w której warstwa raportowania znajduje się nad systemami operacyjnymi, a nie je zastępuje.

Jeśli wiele systemów rości sobie prawo do autorytetu nad tym samym polem, dokonaj uzgodnienia, pytając, który system jest właścicielem tworzenia, który odpowiada za walidację, a który za interpretację na dalszych etapach. Odpowiedź rzadko brzmi „wszystkie w równym stopniu”. Częściej jeden system powinien być właścicielem ścieżki zapisu, a inny wspólnej ścieżki odczytu, z przepływem pracy uzgadniania, który flaguje konflikty, zanim się rozprzestrzenią.

Zasada operacyjna: jeśli pole napędza transakcję, uprzywilejuj SOR. Jeśli pole napędza decyzję międzyfunkcyjną, uprzywilejuj SOT.

W tym miejscu spotykają się również governance i architektura. Pytanie nie brzmi, czy hurtownia danych jest „mniej prawdziwa”, ale czy jest to właściwe miejsce do tworzenia kontrolowanej, audytowalnej interpretacji kilku rzeczywistych systemów. Wcześniejsza sekcja dotycząca różnic mechanicznych ma tutaj znaczenie, ponieważ ten sam element danych może zgodnie z prawem mieć swoje miejsce operacyjne i decyzyjne.

Gdy zespoły potrzebują konkretnego modelu uzgadniania, ten przewodnik po znaczeniu uzgadniania danych jest pomocnym odnośnikiem wewnętrznym. Kluczem jest jasne przypisanie uprawnień, aby konflikt nie stawał się argumentem politycznym przy każdej zmianie liczby.

Jak Data Observability wspiera niezawodne SOR i SOT

Data observability zmniejsza dystans między „rekord istnieje” a „rekord jest wystarczająco wiarygodny, by go skonsumować”. W warstwie operacyjnej oznacza to wychwytywanie dryfu schematu, brakujących rekordów i wadliwej walidacji, zanim systemy downstream przejmą te uszkodzenia. W zaufanej warstwie analitycznej oznacza to wykrywanie opóźnień w dostarczaniu, anomalii i naruszeń reguł, zanim użytkownicy biznesowi zobaczą błędną wersję rzeczywistości. digna to jedna z opcji w tym obszarze, a jej moduły idealnie odpowiadają omówionym wcześniej trybom awarii: Data Anomalies do opartego na sztucznej inteligencji uczenia linii bazowej, Timeliness do monitorowania dostarczania i wykrywania opóźnień, Data Validation do wymuszania reguł biznesowych oraz Schema Tracker do wykrywania zmian strukturalnych.

Co powinno monitorować observability

Kontrole powinny pasować do warstwy. Dla SOR znaczenie mają walidacja na poziomie rekordów i śledzenie schematów, ponieważ punkt przechwytywania musi pozostać czysty. Dla SOT kluczowe są terminowość i wykrywanie anomalii, ponieważ świeżość i jakość uzgadniania decydują o tym, czy wspólny widok jest nadal wiarygodny. Projekt digna ma również znaczenie z perspektywy governance, ponieważ działa w całości w infrastrukturze klienta, z wykonaniem w bazie danych, więc wrażliwe rekordy nie muszą opuszczać środowiska w celu sprawdzenia.

Szersza lekcja brzmi: observability nie jest dodatkiem do pulpitu nawigacyjnego. To płaszczyzna kontrolna między systemami of record a sources of truth. Gdy potok zaczyna dostarczać dane z opóźnieniem, schemat ewoluuje lub reguła biznesowa przestaje obowiązywać, problem powinien pojawić się jako incydent na długo przed tym, jak kadra kierownicza zobaczy nieaktualny wskaźnik KPI.

Aby uzyskać głębszy przegląd produktu, ten przegląd data observability w digna jest przydatnym punktem wyjścia.

Zespoły szukające praktycznego scenariusza zachowania integralności mogą również wyciągnąć wnioski z przewodnika dla liderów Church Extension Fund, zwłaszcza jeśli muszą przełożyć język governance na kontrole operacyjne. Observability działa najlepiej, gdy jest dostosowane do rzeczywistego cyklu życia danych, a nie dodawane na siłę po zepsuciu raportu.

Lista kontrolna wdrożenia i zalecane architektury

Czyste wdrożenie zaczyna się od własności, a nie od narzędzi. Najpierw zidentyfikuj każdy system, który tworzy lub aktualizuje krytyczną jednostkę, a następnie oznacz ten, który jest właścicielem autorytatywnej ścieżki zapisu, jako SOR. Następnie wyznacz warstwę raportowania, która łączy te dane wejściowe, jako SOT i udokumentuj, na które pytania ta warstwa może odpowiadać. Jeśli oczekuje się, że obie warstwy odpowiedzą na to samo pytanie, jest to błąd projektowy, a nie zaleta.

Praktyczna lista kontrolna

• Odwzoruj właścicieli jednostek: przypisz system, który tworzy i aktualizuje rekord, jako SOR dla tej domeny.

• Zdefiniuj warstwę raportowania: wybierz hurtownię danych lub warstwę semantyczną, która będzie działać jako SOT dla decyzji międzydomenowych.

• Najpierw napisz reguły walidacji: zdefiniuj reguły biznesowe dla wymaganych pól, dozwolonych wartości i obsługi konfliktów przed automatyzacją ładowania danych.

• Monitoruj terminowość w jasny sposób: określ oczekiwania co do czasu napływu danych źródłowych, a następnie generuj alerty, gdy tak się nie dzieje.

• Śledź zmiany schematu w sposób ciągły: traktuj zmiany strukturalne jako ryzyko wydania, a nie zmianę kosmetyczną.

• Przechowuj dowody audytowe razem: zachowaj historię pochodzenia danych (lineage) i ścieżkę uzgadniania, aby zespoły ds. governance mogły wykazać, jak zbudowano zaufany widok.

Aby uzyskać szerszy widok platformy, ten przegląd platformy danych przedsiębiorstwa dostarcza przydatnego kontekstu dla zespołów projektujących rozwiązania w oparciu o wiele źródeł i zarządzanych odbiorców.

Wzorce architektury, które się sprawdzają

W przypadku wieloźródłowych danych klientów niech CRM, system bilingowy i wsparcie pozostaną SOR dla swoich własnych domen, a następnie skonsoliduj je w zarządzanej warstwie semantycznej, która służy jako SOT dla zespołów ds. klientów i kadry kierowniczej. W przypadku raportowania finansowego zachowaj ERP lub księgę główną jako autorytatywne źródło dla transakcji, a następnie publikuj uzgodnione widoki raportowe z hurtowni danych. W przypadku analityki operacyjnej użyj przechwytywania zmian danych (CDC) lub zaplanowanego pobierania do warstwy analitycznej, aby operacje przebiegały szybko, a analityka pozostała spójna.

Najsilniejszym wzorcem nie jest jeden system udający, że jest wszystkim. To jasne źródło operacyjne, zarządzany widok analityczny i warstwa monitorowania, która udowadnia, że oba te elementy nadal się zgadzają.

Ta struktura sprawdza się w środowiskach chmurowych, lokalnych i hybrydowych, ponieważ logika jest taka sama, nawet gdy zmienia się technologia. Systemy mogą się różnić, ale model uprawnień nie powinien.

Zastosowania w rzeczywistych warunkach w branżach regulowanych

Usługi finansowe kładą nacisk przede wszystkim na integralność u źródła, a w drugiej kolejności na harmonizację w raportowaniu, ponieważ dane dotyczące ryzyka i regulacji nie mogą dryfować bez wykrycia. Sektor zdrowia stawia na niezawodność dokumentacji medycznej, a następnie nakłada na nią widoki operacyjne i raportowe, tak aby zespoły medyczne i ds. zgodności nie pracowały na niekompatybilnych danych. Telekomunikacja ma inny profil obciążeń: duże wolumeny danych klientów i operacyjnych mogą ulec uszkodzeniu bez ostrzeżenia pod dużym obciążeniem, dlatego śledzenie schematów i terminowość stają się kluczowe dla utrzymania aktualności zaufanego widoku.

Programy sektora publicznego zazwyczaj mają do czynienia z mieszanką długowiecznych rekordów, oczekiwań audytowych i wielu odbiorców raportów, co sprawia, że separacja między SOR a SOT jest szczególnie cenna. W praktyce oznacza to, że system operacyjny zachowuje autorytatywny rekord, podczas gdy warstwa raportowania jest zaprojektowana pod kątem identyfikowalności, spójności i dowodowości. Modułowe podejście digna dobrze się tu sprawdza, ponieważ platforma może monitorować dane o ryzyku finansowym, dokumentację medyczną, bogate w dane operacyjne kanały klientów i rządowe potoki raportowania bez wymuszania tego samego wzorca kontroli wszędzie.

Co zmienia się w zależności od branży

Wspólnym mianownikiem jest to, że środowiska regulowane nie mogą polegać na stwierdzeniu „pulpit nawigacyjny wyglądał dobrze”. Potrzebują dowodu na to, że rekord upstream był prawidłowy, że warstwa agregacji otrzymała dane na czas i że zmiany schematu nie zmieniły znaczenia bez powiadomienia. W tym miejscu linia między system of record a source of truth staje się kontrolą operacyjną, a nie tylko definicją.

Jeśli Twoja organizacja przygotowuje się do audytu lub zaostrza kontrole wokół raportowania dla kierownictwa, zasób Regina SOC 2 pomoc w audycie dla dyrektorów finansowych jest użytecznym przykładem tego, jak praca nad Compliance zależy od wiarygodnych dowodów, a nie tylko spójnych opowieści. Ta sama zasada obowiązuje w tych branżach: zaufany widok musi dać się wykazać, a nie tylko zakładać.

Jeśli porządkujesz kwestię tego, gdzie kończą się Twoje systemy of record, a zaczyna source of truth, digna daje zespołom możliwość obserwowania punktów styku, zamiast odkrywania ich wad w uszkodzonym pulpicie nawigacyjnym. Monitoruje zachowanie danych, weryfikuje reguły biznesowe, śledzi terminowość i wykrywa zmiany schematu wewnątrz Twojego własnego środowiska, czyli dokładnie to, czego potrzebują te architektury. Odwiedź digna, aby zobaczyć, jak to pasuje do Twojego własnego stosu operacyjnego i raportowego.

Po stronie source of truth, gdzie hurtownia może ładować dane zgodnie z harmonogramem, a jednocześnie po cichu oddalać się od rzeczywistości biznesowej, digna Data Anomalies uczy się normalnego poziomu bazowego każdej tabeli i sygnalizuje nieoczekiwane odchylenia, zanim trafią na dashboard.

Najczęściej zadawane pytania

Czym różni się system of record od source of truth?

System of record to nadrzędny magazyn operacyjny dla jednej domeny biznesowej, np. CRM, ERP lub system kadrowy, w którym dane są tworzone i zarządzane. Source of truth łączy kilka systemów of record w zarządzany, międzydomenowy widok, zwykle w hurtowni danych lub warstwie semantycznej służącej do raportowania.

Czy hurtownia danych może być systemem of record?

Zazwyczaj nie; artykuł umieszcza hurtownię w roli source of truth. Nie wytwarza ona faktów, lecz łączy wiele autorytatywnych źródeł w uzgodnioną warstwę raportową. Systemy operacyjne, takie jak CRM, platforma rozliczeniowa czy księga główna ERP, pozostają nadrzędne dla własnych rekordów i transakcji.

Czym różnią się awarie systemu of record i source of truth?

System of record zawodzi w momencie zapisu: niekompletne rekordy, nierozwiązane duplikaty klientów lub zmiana schematu psująca integracje. Source of truth zawodzi ciszej, gdy źródło nadrzędne staje się nieaktualne, reguła scalania jest przestarzała lub założenie deduplikacji przestaje obowiązywać, a ładowania nadal przebiegają zgodnie z harmonogramem.

Który system ma pierwszeństwo, gdy dwa systemy różnią się w tym samym polu?

Zapytaj, który system odpowiada za tworzenie, który za walidację, a który za dalszą interpretację. Zasada operacyjna z artykułu jest prosta: jeśli pole napędza transakcję, pierwszeństwo ma system of record; jeśli napędza decyzję międzydziałową, pierwszeństwo ma source of truth, wsparte procesem uzgadniania, który wcześnie sygnalizuje konflikty.

Jak obserwowalność danych wspiera systemy of record i source of truth?

Kontrole powinny pasować do warstwy. W systemie of record walidacja na poziomie rekordów i śledzenie schematu utrzymują punkt wprowadzania danych w czystości. W source of truth terminowość i wykrywanie anomalii potwierdzają, że wspólny widok jest aktualny i uzgodniony. Artykuł przypisuje to modułom digna Data Validation, Schema Tracker, Timeliness i Data Anomalies.