Stiekema StudioEnglish

Casesheet

Cataloom

Een read-only tool voor SQL Server, Azure SQL en Power BI die laat zien waar een tabel of view vandaan komt, welke procedures, modellen en rapporten ervan afhangen en wat een wijziging raakt. De verbanden komen uit de echte view- en procedurecode, niet uit een taalmodel; de output is een map losse HTML-bestanden.

XBAS Business Intelligence B.V. · KVK 89736478 · Almere NL · Case cataloom

De documentatie van Cataloom op de publieke WideWorldImporters-voorbeelddatabase: links de objectlijst met een zoekveld, rechts onder de kop "AI-gegenereerde documentatie uit de echte view- en procedure-logica" een procedure met een beschrijving die uit de procedurecode is afgeleid en een inklapbare SQL-definitie, en daaronder een tabel met zijn beschrijving en de kolommen met type, sleutel en nullability.
Plaat · Cataloom

Samenvatting

Cataloom is een zelfgebouwd product voor de Microsoft-datastack. Het leest read-only de catalogus en de code van views en procedures in SQL Server of Azure SQL, en via de Scanner API de semantic models en rapporten in Power BI. Daaruit bouwt het één keten: de brontabel, de procedures en views die hem lezen of vullen, het model dat erop leunt en de rapporten daarboven, overal waar die koppeling aantoonbaar is. Zo is per object te zien waar het vandaan komt en wat er van een wijziging afhangt. Lineage en relaties worden deterministisch uit de code gemined; het taalmodel schrijft alleen de businessbeschrijvingen erbij en verzint geen verbanden. Daarnaast draait een audit op de SQL-kant en de Power BI-koppeling, van verweesde referenties tot modellen die een verdwenen object lezen, en vanaf de tweede run toont een wijzigingsrapport wat er sinds de vorige meting is veranderd en welke Power BI-modellen dat raakt.

De vraag

Wie een tabel of veld in een warehouse wil wijzigen, wil vooraf weten welke ETL-logica, modellen en rapporten eraan hangen; wie een rapport bouwt, wil weten waar een getal vandaan komt en welke logica erop zit. Dat antwoord staat verspreid over procedurecode, views en Power BI, en Microsoft Purview bedient die vraag alleen als zwaar enterpriseplatform. Cataloom haalt de samenhang uit de code zelf, zodat de AI er alleen woorden aan geeft en geen bewijs verzint.

Wat ik heb gebouwd

  • Een read-only verzamellaag voor SQL Server en Azure SQL: live via een login met db_datareader en VIEW DEFINITION, of zonder verbinding via een leesbaar PowerShell-script dat alleen SELECT's op de systeemcatalogus doet en een zip schrijft
  • Deterministische lineage uit de T-SQL met sqlglot: welke views en procedures een tabel lezen en welke procedures ernaar schrijven, aangevuld met declared foreign keys en join-mining uit dezelfde code
  • Een Power BI-laag via de Scanner API: per semantic model welke tabel of view het leest, met een expliciete matchsterkte tussen server- en databasenaam, en de keten object, model, rapport in dezelfde lineage-viewer
  • Een auditregistry met deterministische checks op de SQL-kant en vier op de Power BI-koppeling, zoals een model dat een verdwenen object of rechtstreeks de staginglaag leest
  • Een wijzigingsrapport per run op basis van content-hashes (nieuw, gewijzigd, hernoemd, verdwenen) met de Power BI-modellen die een verdwenen bron raakt, en een cache per AI-uitkomst zodat een herhaalde run vrijwel geen modelcalls kost
  • Een optionele AI-laag met een bring-your-own Azure OpenAI-sleutel, die per object een businessbeschrijving schrijft en een compact contextbestand voor LLM-sessies maakt; zonder AI werken lineage, audit en wijzigingsrapport volledig

In detail

  • Herkomst en impact in één keten: van brontabel via views en procedures naar Power BI-model en rapport, voor zover de koppeling aantoonbaar is; een koppeling die alleen op databaseniveau vaststaat, wordt niet als tabelrelatie getoond
  • Verbanden uit code, niet uit een taalmodel: lineage en relaties zijn deterministisch gemined, en het taalmodel schrijft alleen de beschrijvingen
  • Doorlopend in plaats van een momentopname: elke run vergelijkt met de vorige, en op een echte database kostte de tweede run 1 verse modelcall in plaats van 109
  • Read-only, met de datastromen per route benoemd: het taalmodel krijgt schema en code, en bij een live verbinding enkele geaggregeerde signalen (tellingen, datumbereiken, statuswaarden), nooit volledige rijen. In je eigen omgeving gaan de AI-stappen naar je eigen Azure OpenAI-resource; bij de gratis audit komt de metadata bij mij, via de zip van het script of via een read-only login

Resultaat

Live sinds augustus 2026 op cataloom.io: een NL-eerst productsite met een doorklikbare demo van het echte rapport op de publieke WideWorldImporters-voorbeelddatabase, en een gratis audit op één database als instap. Bij één organisatie liet de Power BI-laag zien dat 107 semantic models en 156 rapporten aan één database hingen en dat dertien modellen een object lazen dat niet meer bestond. De code is gedekt door een pytest-suite van ruim 1.800 tests. Lineage werkt vandaag op objectniveau: herkomst per veld en een taakgerichte impactweergave zijn de volgende stap, naast de marktvalidatie, want een betalende klant is er nog niet.