Begrippenlijst

Deze begrippenlijst verklaart de kernbegrippen van Yres. Technische identifiers (schema-, tabel-, procedure- en kolomnamen) staan exact zoals ze in de code voorkomen — die bevatten vaak nog IRIS, omdat het product vroeger IRIS heette. In lopende tekst gebruiken we de productnaam Yres.

Verdieping

De load engine, SCD2-historie en de zeven load types worden uitgebreid behandeld in Yres uitgelegd en Load types.

Product en organisatie

Term	Betekenis
Yres	Het Azure-data-platform (datawarehouse-automatisering). Voorheen IRIS.
IRIS	Oude productnaam van Yres. Komt nog voor in resource-namen (IRIS_DWH, kv-iris-…), interne URL's en code-identifiers.
Plainwater	Het bedrijf achter Yres; ontwikkelt en host de control plane.
Organisatie	Afgeschermde ruimte waarin een klant Yres gebruikt; bevat één of meer environments. De eerste environment is altijd dev.
Environment (omgeving)	Geïsoleerde versie van een organisatie. Elke environment heeft een eigen ADF-factory en een eigen IRIS_DWH-database. Eerste environment is altijd dev; afhankelijk van de licentie ook test, acceptance, prod.
DTAP	Development, Test, Acceptance, Production — het patroon van gescheiden omgevingen waarlangs changes worden gepromoot. De Change-schema's in IRIS_DWH ondersteunen dit changemanagement.
Project	Categoriseert werk binnen een omgeving; bevat changes en heeft een due date. Alleen beschikbaar bij organisaties met meerdere environments.
Change	Set bewerkingen aan het datawarehouse, te releasen en te installeren naar andere omgevingen (DTAP).
Scripted object	Custom SQL-object (tabel, stored procedure, function) dat niet door Yres is gegenereerd, beheerd onder een change.

De twee planes

Term	Betekenis
Control plane	De multi-tenant SaaS-webapp van Plainwater (één deployment voor alle klanten). Beheert organisaties, gebruikers, environments en facturatie in een PostgreSQL-database. Bevat nooit klantdata — het provisioneert en bestuurt elke data plane via de Azure Management-, ADF-, Key Vault- en Azure DevOps-API's en een directe SQL-verbinding.
Data plane	Eén ADF-factory + één IRIS_DWH Azure SQL-database per organisatie × environment, draaiend binnen de eigen Azure-tenant van de klant. Hier verplaatst de data daadwerkelijk. Dit is waar de load engine leeft.

Bronnen en metadata

Term	Betekenis
Data source	Gekoppelde bron waaruit data geladen wordt (database, applicatie, OData/REST, file server). Wordt aangemaakt via de wizard "Create source".
SourceType	Het brontype dat het laadgedrag bepaalt (bv. MSSQL_ADF, DB2, POSTGRESQL, MYSQL, ODATA, SALESFORCE, SAP_BDC). fxExtractor genereert per sourceType het juiste extract-commando en de delta-WHERE-clause.
ADF	Azure Data Factory — de orkestratielaag. Yres genereert hier de pipelines naartoe; ADF kopieert bytes van bron naar STAGE en roept daarna SQL aan. ADF bevat geen laadlogica.
Integration Runtime (IR)	Compute van ADF die de bron bereikt. Standaard AutoResolveIntegrationRuntime (cloud) voor cloud-bereikbare bronnen; een self-hosted IR (pwccIntegrationRuntimeLinked) voor on-prem/firewalled databases en file servers.
Dictionary	Opgeslagen bron-metadata (tabellen, kolommen, datatypes, keys, relaties) in LoadManagement.Dictionary. Wordt gevuld door "Refresh metadata" en is vereist vóór het toevoegen van tabellen. File- en REST-bronnen slaan deze stap over.
vwExtractor	De contract-view [LoadManagement].[vwExtractor] die ADF leest om te bepalen wát geladen moet worden. Het is een dunne wrapper: SELECT * FROM [LoadManagement].[fxExtractor](NULL, NULL).
fxExtractor	De table-valued function [LoadManagement].[fxExtractor](@LoadFilter, @LoadType) waarin alle extractor-logica zit. Elke teruggegeven rij = één te laden tabel, met alle parameters die ADF stroomafwaarts doorgeeft (load type, DeltaScript, doelschema's, file-/parsing-opties, paginering).

Lagen in het datawarehouse

Term	Betekenis
STAGE	Stagingschema waar ADF de ruwe bron-extract in landt (schemanaam via setting SchemaStage, standaard STAGE). Hier worden de framework-kolommen ETL_Date, KeyHash en RowHash berekend.
HIS	History-laag met de volledige SCD2-historie (schemanaam via setting SchemaHIS). De HIS-schemanaam staat niet hard gecodeerd; op verifieerbare omgevingen resolvet SchemaHIS naar ODS.
ODS	Operational Data Store. Tevens de standaardwaarde van SchemaHIS — de HIS-laag landt in de praktijk in het ODS-schema.
Expose	De reporting-/exposelaag (Exposed, Expose, gebruikersschema's). Bevat de rapportagegerichte views/tabellen plus RBAC, opgebouwd door spMaterializeViews.
Data Lake	Optionele Parquet-landing in Azure Data Lake Gen2. Yres schrijft per run een change feed met alleen de mutaties (YresAction = I/U/D, plus KeyHash/RowHash/YresDateStart), gepartitioneerd op Source/Schema/Target/Year/Month.
Lake feed	De append-only mutatiestroom in de Data Lake: per laadrun één Parquet-bestand met de inserts, updates en deletes van die run. Zie Lake feed.

STAGE → HIS → Expose

De vaste dataspine is: bron → ADF Copy → STAGE → spLoadDWH → spHIS_InsertAndUpdate → HIS (SCD2) → spMaterializeViews → Expose. ADF verplaatst alleen bytes; alle laadlogica zit in SQL.

SCD2-historie en hashing

Term	Betekenis
SCD2	Slowly Changing Dimension type 2 — het historisatiemodel van de HIS-laag. Bij een wijziging blijft de oude versie als gesloten rij bewaard en wordt een nieuwe huidige versie ingevoegd.
KeyHash	varbinary(66)-hash (HASHBYTES('SHA2_512', …)) over de key-kolommen, als persisted computed column op STAGE. De match-join is STAGE.Keyhash = HIS.Keyhash AND HIS.isCurrent = 1.
RowHash	varbinary(66)-hash (HASHBYTES('SHA2_512', …)) over de rowhash-gemarkeerde kolommen. Wijzigingsdetectie is STAGE.Rowhash <> HIS.Rowhash. Een kolom met Rowhash = 0 is uitgesloten van wijzigingsdetectie.
ETL_Date	Laadtimestamp van de rij; één ETL_Date per run, gezet bij de start van de bron-pipeline.
ETL_EndDate	Einddatum van een rij-versie. Voor de huidige (open) versie is dit de sentinel 2999-01-01 00:00:00. Bij sluiten van een rij wordt ETL_EndDate op de ETL_Date van de nieuwe versie gezet.
isCurrent	bit-vlag: 1 = huidige versie, 0 = gesloten/historisch. Altijd 1 of 0, nooit NULL. Er is precies één huidige rij per key.
Delta	nvarchar(1)-vlag op de HIS-rij: 'N' = nieuw, 'D' = gewijzigd.
<stripped>_RowID	IDENTITY-surrogaatkolom per HIS-tabel. De naam is de doeltabelnaam met niet-alfanumerieke tekens verwijderd (de casing blijft behouden), plus _RowID (bv. AX_dbo_Cust → AXdboCust_RowID).
Surrogate key	Optionele door Yres gegenereerde integer-sleutel voor de natural key, opgeslagen in [LoadManagement].[SurrogateKeys]. Gestuurd door fxGetSurrogate(@Target) en de setting DefaultSurrogate.
Delta (watermark)	De wijzigingskolom-waarde die DELTA/DELTAIMAGE/ADDITIONAL als watermerk bijhouden. Na de load wordt UsedTables.LatestRecord = MAX(<DeltaColumn>) bijgewerkt, zodat de volgende run alleen nieuwere records ophaalt.

Load engine

Term	Betekenis
Load type	Bepaalt wat er met de bestaande HIS-data gebeurt. Er zijn zeven types: FULL, DELTA, DELTAIMAGE, IMAGE, OVERWRITE, RELOAD, ADDITIONAL. Ingesteld per tabel in LoadManagement.UsedTables.LoadType, per run overschrijfbaar. Zie Load types.
spLoadDWH	Het instappunt dat ADF aanroept nadat STAGE is gevuld. Bevat eerst een arbitragegate die de load bewust laat falen zolang er voor het target een RUNNING archiveringsrun loopt (LoadType ARCHIVING), en roept daarna spHIS_InsertAndUpdate aan (de oude spUpdateETL_EndDate-aanroep is uitgecommentarieerd; end-dating gebeurt nu binnen spHIS_InsertAndUpdate).
spHIS_InsertAndUpdate	De SCD2-merge-engine die STAGE → HIS verwerkt. Behandelt zes load types expliciet (DELTA, DELTAIMAGE, IMAGE, OVERWRITE, RELOAD, ADDITIONAL); FULL is het impliciete standaardpad.
spMaterializeViews	Bouwt na de load de gematerialiseerde/persisted views in de Expose-laag bij.
Persisted view	Opgeslagen resultaat van een view-query; herladen op volgorde van level.
Master pipeline	Vanuit de frontend geconfigureerde ADF-pipeline met conditionele flow (on success / failure / completion). Beschikbaar vanaf v1.53.
Dynamic Workflow YRES	De generieke load-pipeline die op metadata draait (parameters: Source, Schema, Table, LoadType). Op oudere versies heet deze nog Dynamic Workflow IRIS.

Monitoring en logging

Term	Betekenis
spWriteLoadStatus	De centrale load-status-logger ([Monitoring].[spWriteLoadStatus]). Schrijft LS_Pipeline (bij start van workflow/load), altijd LS_Trans, en zet LoadLog-status op RUNNING/SUCCEEDED/FAILED.
PLANNED / SKIPPED	De twee statussen die spPrepareWorkload (niet spWriteLoadStatus) al vóór de start in LoadLog zet: PLANNED = deze tabel-load wordt echt meegenomen in de ForEach-lus; SKIPPED = er lag al een niet-afgeronde (PLANNED/RUNNING) load voor dezelfde tabel, dus deze aanvraag wordt gelogd maar niet uitgevoerd. Zie Monitoring & logging.
LoadLog	[LoadManagement].[LoadLog] — één duurzame rij per tabel-load met de status (LoadStatus: PLANNED → RUNNING → SUCCEEDED/FAILED, of PLANNED → SKIPPED), start-/eindtijd, foutmelding en een JSON-snapshot van de config. Vormt de join-ruggengraat van vwMonitor.
LS_Pipeline / LS_Trans	[Monitoring].[LS_Pipeline] = één rij per pipeline-/workflow-run; [Monitoring].[LS_Trans] = één rij per stap (de fijnmazige timeline).
vwLoads	De canonieke per-pipeline load-timeline [Monitoring].[vwLoads] (start + runtime per stap, rijtellingen, status).
vwMonitor	Bredere monitor-view [Monitoring].[vwMonitor] die ook materialized views en Power BI-refreshes meeneemt.

Geen vwLoadMonitor

De view vwLoadMonitor bestaat niet in de live database. Gebruik vwLoads (pipeline-timeline) of vwMonitor (breder). Zie de SQL-referentie.

Instellingen, beveiliging en infrastructuur

Term	Betekenis
Setting	Configuratiewaarde in [Config].[Settings], gelezen via [Config].[fxGetSetting](@SettingName). Bepaalt schema-namen, opslagtype, paginering, scaling, enzovoort.
SchemaHIS / SchemaStage	Settings die de HIS- en STAGE-schemanamen bepalen (standaard ODS resp. STAGE), resolved per tabel door Config.fxGetSchemaName.
DefaultStore	Setting voor row- (lezen/schrijven) of column-oriented (queries) opslag van STAGE. Standaard ROW.
Service tier	De Azure SQL-database-tier (settings DefaultServiceTier/HighServiceTier). Yres kan automatisch op- en afschalen rond een load.
Surrogate key	Zie SCD2-historie en hashing.
SSO	Single Sign-On via Azure; per gebruiker afdwingbaar.
RBAC	Role-based access control; rollen volgens CRUD per permissietype. De database-rol Yres_dbreader wordt door spGenerateDbreader opgebouwd.
Key Vault	Azure Key Vault waar alle credentials liggen. De frontend bewaart nooit secrets; bron-credentials gaan naar de Key Vault van de klant (adf-{sourceName}-…) en de linked service verwijst ernaar.