Error és history tábla szerepe az adattárházban

Error tábla szerepe az adattárházban

Az error tábla az adattárház betöltési folyamataiban olyan rekordok tárolására szolgál, amelyek hibásak vagy nem felelnek meg az üzleti szabályoknak, ezért nem tölthetők be közvetlenül az integrációs vagy célrendszerekbe.

---

1. Miért van szükség error táblára?

🔹 Hibás adatok elkülönítése – Az adattárházba érkező adatok nem vesznek el, hanem egy külön táblában tároljuk őket, hogy később elemezhessük és javíthassuk őket.
🔹 Betöltési folyamatok stabilitása – Ha egy betöltés során néhány rekord hibás, a többi rekord sikeresen feldolgozható, mert az error táblába kerülnek a problémás adatok.
🔹 Hibaelemzés és minőségellenőrzés – Segít az adatminőség problémák feltárásában (pl. hiányzó értékek, adattípus-eltérések, duplikációk).
🔹 Javítás és újrafeldolgozás – A hibás rekordokat később javítani lehet, és újra lehet próbálni a betöltést.

---

2. Mikor használunk error táblát?

✅ ETL (Extract-Transform-Load) folyamatokban, amikor az adatok betöltése előtt különböző validációkat végzünk.
✅ Stage területről történő integráció során, ha az adatok nem felelnek meg az üzleti szabályoknak.
✅ Ha a forrásrendszerekből érkező adatok hibásak, és javításra van szükség.
✅ Amikor szükség van auditálásra, hogy milyen hibák és milyen gyakorisággal fordulnak elő.

---

3. Error tábla felépítése

Az error táblák általában a következő mezőket tartalmazzák:

Mező neve	Szerepe
id	Egyedi azonosító
table_name	Melyik forrásból érkezett az adat
error_type	Hibatípus (pl. "Hiányzó adat", "Érvénytelen formátum")
error_description	Hiba részletes leírása
record_data	Az eredeti rekord (pl. JSON vagy VARCHAR formátumban)
created_at	A hiba bejegyzésének időpontja
processed_flag	Jelzi, hogy a hiba javítva lett-e már

📌 Példa egy Oracle error tábla létrehozására:

CREATE TABLE error_log (
    id NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    table_name VARCHAR2(100),
    error_type VARCHAR2(50),
    error_description VARCHAR2(4000),
    record_data CLOB,
    created_at TIMESTAMP DEFAULT SYSTIMESTAMP,
    processed_flag CHAR(1) DEFAULT 'N'
);

Error táblába írás az ETL folyamatban

📌 Példa egy hiba naplózására, ha egy ügyfél neve üres:

INSERT INTO error_log (table_name, error_type, error_description, record_data)
VALUES (
    'customer_stage',
    'Hiányzó adat',
    'Az ügyfél neve üres',
    '{ "customer_id": 123, "name": null, "email": "test@example.com" }'
);

 ETL folyamat PL/SQL példával:

BEGIN
    FOR rec IN (SELECT * FROM customer_stage) LOOP
        IF rec.name IS NULL THEN
            INSERT INTO error_log (table_name, error_type, error_description, record_data)
            VALUES ('customer_stage', 'Hiányzó adat', 'Az ügyfél neve hiányzik', rec.customer_id || ', ' || rec.email);
        ELSE
            INSERT INTO customer (customer_id, name, email)
            VALUES (rec.customer_id, rec.name, rec.email);
        END IF;
    END LOOP;
END;
/

Error tábla kezelése és újratöltése

1️⃣ Hibaellenőrzés és elemzés

• Milyen típusú hibák fordulnak elő gyakran?
• Forrásrendszerből jön a hiba, vagy az ETL folyamatban történik?

2️⃣ Hibás rekordok javítása

• Manuálisan (ha kevés hiba van)
• Automatikusan (ha ismert szabályok szerint javítható)

3️⃣ Újratöltés a megfelelő célterületre
📌 Példa a javított rekordok visszatöltésére:

INSERT INTO customer (customer_id, name, email)
SELECT customer_id, name, email FROM error_log
WHERE processed_flag = 'Y';

4️⃣ Error tábla tisztítása

• Történeti adatok megtartása? → Archíválás egy külön "error_history" táblába
• Vagy időszakos törlés? → Például 90 napnál régebbi rekordok törlése:

DELETE FROM error_log WHERE created_at < SYSDATE - 90;

History táblák az adattárházban

A history (történeti) táblák az adattárház egyik alapvető komponensei, amelyek biztosítják az adatrekordok időbeli változásának nyomon követését. Ezek a táblák megőrzik az egyes rekordok korábbi állapotait, így lehetővé teszik az időbeli visszakövetést, változáselemzést és auditálást.

---

Miért van szükség history táblákra?

✅ Adatok időbeli változásának megőrzése → Az adatok frissítése nem felülírja a régi értékeket, hanem új rekordot hoz létre.
✅ Üzleti elemzések és trendek vizsgálata → Pl. hogyan változtak az ügyféladatok az idő során?
✅ Auditálás és megfelelőség biztosítása → Bizonyos iparágakban (pl. pénzügy, egészségügy) kötelező az adatváltozások naplózása.
✅ Delta betöltések támogatása → Könnyebb az új és módosult rekordok azonosítása és betöltése.

---

 History táblák típusai

A history táblák kialakítása az adatváltozás kezelésének módszerétől függ. Az adattárházakban általában az SCD (Slowly Changing Dimensions – Lassan változó dimenziók) koncepcióját használják.

History modell	Jellemzők	Felhasználási terület
SCD Type 1 (Nincs történet)	A régi adat felülíródik, nincs nyomon követés.	Ha csak az aktuális állapot számít, pl. hibás adatok javítása.
SCD Type 2 (Teljes történet megőrzése)	Minden rekordváltozás új sorban kerül tárolásra, időbélyeggel.	Ha minden változás megőrzése kritikus (pl. ügyfélcím-változások).
SCD Type 3 (Limitált történet)	Egy adott számú változás tárolása külön oszlopban (pl. "előző cím").	Ha csak egy korábbi állapotot kell megőrizni.
SCD Type 4 (History és aktuális külön táblában)	Egy aktuális és egy történeti tábla van.	Ha nagy mennyiségű változást kell kezelni.

---

3. SCD Type 2 – Leggyakoribb history modell

A SCD Type 2 esetében minden változás új rekordként kerül be az adatbázisba. Az alábbi mezők biztosítják a változások nyomon követését:

Mező neve	Szerepe
id	Egyedi azonosító
natural_key	Az üzleti azonosító (pl. ügyfélkód)
attribute_1, attribute_2, ...	Az üzleti adatok
valid_from	Mikortól érvényes az adott sor?
valid_to	Meddig érvényes?
is_active	Jelenleg aktív rekord? (I/N vagy 1/0)

📌 Példa history tábla létrehozására Oracle-ben:

CREATE TABLE customer_history (
    id NUMBER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
    customer_id NUMBER,
    name VARCHAR2(100),
    address VARCHAR2(200),
    valid_from DATE,
    valid_to DATE,
    is_active CHAR(1)
);

📌 Példa adatok:

id	customer_id	name	address	valid_from	valid_to	is_active
1	101	Kovács Béla	Budapest, Fő utca 1.	2023-01-01	2024-01-01	N
2	101	Kovács Béla	Budapest, Kossuth tér 5.	2024-01-01	NULL	Y

🛠️ Frissítés logikája (SCD Type 2)

• Ha változik egy adat, a régi sor valid_to dátumot kap és is_active = N állapotot.
• Az új adat új sorba kerül valid_from = SYSDATE és is_active = Y értékkel.

📌 Példa egy frissítésre:

UPDATE customer_history
SET valid_to = SYSDATE, is_active = 'N'
WHERE customer_id = 101 AND is_active = 'Y';

INSERT INTO customer_history (customer_id, name, address, valid_from, is_active)
VALUES (101, 'Kovács Béla', 'Budapest, Kossuth tér 5.', SYSDATE, 'Y');


History tábla kezelése az ETL folyamatban
Az ETL folyamatokban a history tábla frissítésére az incrementális betöltés során van szükség.
🔹 Delta azonosítása (mely adatok változtak?)
SELECT * FROM source_data s
LEFT JOIN customer_history h ON s.customer_id = h.customer_id
WHERE s.address <> h.address OR h.is_active = 'N';



🔹 Frissítés az aktuális adatok inaktiválásával

UPDATE customer_history
SET valid_to = SYSDATE, is_active = 'N'
WHERE customer_id IN (SELECT customer_id FROM source_data);

🔹 Új adatok beszúrása

INSERT INTO customer_history (customer_id, name, address, valid_from, is_active)
SELECT customer_id, name, address, SYSDATE, 'Y'
FROM source_data;

Mikor használjunk history táblákat?

✅ Amikor üzleti döntésekhez szükség van az adatok időbeli változásának vizsgálatára.
✅ Ha az adatok frissítése nem felülírást jelent, hanem változáskövetést.
✅ Amikor megfelelőségi vagy audit követelmények írják elő az adatmegőrzést.
✅ Ha trendeket és előrejelzéseket szeretnénk készíteni.

❌ Nem szükséges history tábla, ha mindig csak az aktuális állapot számít (pl. tranzakciós rendszerek egyes eseteiben).