DWH építés folyamata : alfolyamatok, lépések

1. Üzleti és technikai felmérés

Ezen a ponton meg kell értenünk, hogy milyen üzleti problémákat kell megoldani, milyen forrásrendszerekkel dolgozunk, és hogyan fog kinézni az adattárház modell. Nézzük ezt egy konkrét banki kártyarendszer példáján!

1.1 Üzleti igények azonosítása

Példa:
Egy bank kártyarendszerének adattárházát szeretnénk létrehozni, hogy támogassuk a következő üzleti területeket:

Üzleti terület	Felhasználási eset
Kockázatkezelés	Fraud detection (csalás észlelése) - például ha egy kártyát rövid időn belül több országban használnak.
Marketing	Ügyfélszegmentálás - például prémium ügyfelek azonosítása a kártyahasználat alapján.
Pénzügyi riportok	Tranzakciók összegzése pénznemenként, régiónként.
Szabályozói riporting	Napvégi egyenlegek, tranzakciók, AML (Anti-Money Laundering) ellenőrzés.

Ezek alapján a legfontosabb adatokat azonosítjuk:

Kártyaadatok (kártyaszám, ügyfél, kártya típusa, lejárati dátum)
Tranzakciók (összeg, időpont, devizanem, elfogadóhely, ország)
Ügyféladatok (név, cím, státusz)
Elfogadóhelyek (POS terminál, ATM, e-kereskedelem)

1.2 Forrásrendszerek elemzése

A bank által használt rendszerek az adatokat különböző módon tárolhatják és szolgáltathatják.

Példa:

Rendszer	Adatforrás típusa	Frissítési gyakoriság
Core Banking System	Oracle SQL	Napi
Kártyarendszer (Visa, Mastercard)	XML, API	Óránként
Tranzakciós napló	Flat file (CSV)	Naponta
Ügyfélkezelő rendszer (CRM)	REST API	Valós időben

💡 Probléma: Az adatok különböző formátumokban érkeznek. Például az ügyfél neve a CRM rendszerben lehet „Kovács Péter”, de a kártyarendszerben „PETER KOVACS”.

Megoldás:

Egységes formátumot alakítunk ki az adattárházban (pl. minden ügyfélnév nagybetűs legyen).
Ellenőrizzük a duplikációkat (pl. azonos ügyfél több különböző néven).

1.3 Adattárház architektúra és modellezési elvek kiválasztása

Az adattárház struktúrája a választott modellezési elvtől függ.

📌 Példa – Data Vault modell
A Data Vault modell rugalmasan támogatja a történeti adatokat és könnyen bővíthető.

Entitás	Típus	Leírás
Kártya (Card HUB)	HUB	Kártyaszámot azonosító fő entitás.
Ügyfél (Customer HUB)	HUB	Az ügyfél azonosítója, akihez a kártya tartozik.
Tranzakció (Transaction HUB)	HUB	Minden egyes kártyás tranzakció egy egyedi azonosítóval.
Kártya-ügyfél kapcsolat	LINK	Egy ügyfél több kártyával rendelkezhet.
Tranzakció-kártya kapcsolat	LINK	Egy kártya végrehajt egy adott tranzakciót.
Kártya adatai (Card SAT)	SAT	Lejárati dátum, kártyatípus stb.
Ügyfél adatai (Customer SAT)	SAT	Ügyfél címe, státusza stb.
Tranzakció adatai (Transaction SAT)	SAT	Tranzakció összege, időpontja stb.

2. Adattárház betöltési folyamatának tervezése (ETL)

Cél: Az adatok kivonása, transzformálása és betöltése az adattárházba egy hatékony ETL-folyamat kialakításával.

2.1 ETL komponensek meghatározása

Az ETL három fő szakaszból áll:

Fázis	Leírás	Példa
Extract (Kinyerés)	Az adatok kivonása a forrásrendszerekből.	Kivonjuk a kártya tranzakciókat a banki SQL adatbázisból.
Transform (Átalakítás)	Adattisztítás, normalizálás, az adattárház formátumának kialakítása.	A "HUF" devizanemet szabványosítjuk "HUF" helyett "Ft"-re.
Load (Betöltés)	Az adatok feltöltése az adattárházba.	Az ügyfelek és kártyák HUB, LINK, SAT táblákba töltése.

2.2 Adattárház betöltési szintek

A tipikus adattárház-betöltési folyamat három rétegen keresztül történik:

1️⃣ Stage réteg (Nyers adatok betöltése)

Ide érkeznek az adatok a forrásrendszerekből.
Az adatok változtatás nélkül kerülnek tárolásra (pl. raw tranzakciós adatok).
Példa:

---sql

CREATE TABLE STAGE_TRX (
    trx_id VARCHAR2(20),
    card_number VARCHAR2(16),
    amount NUMBER,
    currency VARCHAR2(3),
    trx_time TIMESTAMP,
    merchant_name VARCHAR2(100),
    country VARCHAR2(3)
);

2️⃣ Data Vault réteg (Adattárház struktúra)

A normalizált Data Vault táblákba kerülnek az adatok.
HUB, LINK és SAT táblák kerülnek feltöltésre.
Példa HUB tábla (Kártya HUB):

---sql

CREATE TABLE HUB_CARD (
    hk_card NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    card_number VARCHAR2(16) UNIQUE NOT NULL,
    load_date TIMESTAMP,
    record_source VARCHAR2(50)
);

Példa LINK tábla (Ügyfél-Kártya kapcsolat):

---sql

CREATE TABLE LINK_CUSTOMER_CARD (
    hk_link NUMBER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
    hk_card NUMBER REFERENCES HUB_CARD(hk_card),
    hk_customer NUMBER REFERENCES HUB_CUSTOMER(hk_customer),
    load_date TIMESTAMP,
    record_source VARCHAR2(50)
);

3️⃣ Adatpiac réteg (Data Mart)

Az üzleti riportokhoz optimalizált, denormalizált adatok kerülnek ide.
Példa egy aggregált riport táblára:

---sql

CREATE TABLE DM_CARD_TRANSACTIONS (
    card_number VARCHAR2(16),
    total_spent NUMBER,
    trx_count NUMBER,
    last_trx_date TIMESTAMP
);

2.3 ETL lépések részletesen

1️⃣ Extract (Adatkivonás)

Forrás: Oracle, flat file, API (REST, SOAP)
Eszközök: SQL script, Python, Talend, Informatica

Példa: Kártya tranzakciók kivonása SQL-ben egy banki rendszerből

---sql

SELECT 
    trx_id, card_number, amount, currency, trx_time, merchant_name, country 
FROM BANK_TRX 
WHERE trx_time >= SYSDATE - 1;

🔹 Kihívás: Időzónák kezelése, devizanemek konverziója.

2️⃣ Transform (Adattisztítás és transzformációk)

Adattisztítás: Duplikációk kezelése, adathiányok pótlása
Normalizáció: Különböző formátumok egységesítése (pl. devizanemek)
Hash kulcsok generálása a Data Vault-hoz

Példa: Hash kulcs generálása egy kártya HUB-hoz Oracle-ben

---sql

SELECT 
    STANDARD_HASH(card_number, 'SHA256') AS hk_card, 
    card_number, SYSDATE AS load_date, 'BANK_TRX' AS record_source
FROM STAGE_TRX;

🔹 Kihívás: Nagy mennyiségű adat esetén a hash kulcs generálás optimalizálása.

3️⃣ Load (Betöltés)

Az adatok HUB, LINK, SAT táblákba kerülnek
Incrementális betöltés: Csak az új vagy módosult adatok betöltése

Példa: Új kártyák HUB betöltése

--- sql

INSERT INTO HUB_CARD (hk_card, card_number, load_date, record_source)
SELECT DISTINCT 
    STANDARD_HASH(card_number, 'SHA256'), 
    card_number, 
    SYSDATE, 
    'BANK_TRX'
FROM STAGE_TRX
WHERE NOT EXISTS (
    SELECT 1 FROM HUB_CARD WHERE HUB_CARD.card_number = STAGE_TRX.card_number
);

🔹 Kihívás: Több millió rekord esetén teljesítmény-optimalizálás (pl. indexek, particionálás).

2.4 Teljesítmény-optimalizálás

Oracle optimalizáció: Execution Plan elemzése, Materialized View-k alkalmazása.
Paralelizáció: PL/SQL Bulk Collect vagy több szálas feldolgozás.
Particionálás: Táblák és indexek idő alapú particionálása.

Példa: Particionált tranzakciós tábla létrehozása

--- sql

CREATE TABLE TRANSACTION_SAT (
    hk_trx NUMBER,
    trx_amount NUMBER,
    currency VARCHAR2(3),
    trx_time TIMESTAMP,
    load_date TIMESTAMP
)
PARTITION BY RANGE (trx_time) (
    PARTITION trx_2024_01 VALUES LESS THAN (TO_DATE('2024-02-01', 'YYYY-MM-DD')),
    PARTITION trx_2024_02 VALUES LESS THAN (TO_DATE('2024-03-01', 'YYYY-MM-DD'))
);

🔹 Előny: A riportok gyorsabban futhatnak, mert a rendszer csak a szükséges partíciót olvassa be.

3. Riportok és adatpiac építése (Data Mart)

Miután az adatok az adattárházban vannak (HUB, LINK, SAT struktúrában), elérkezünk az adatpiacok (Data Mart) kialakításához, amelyeket az üzleti riportok és elemzések alapjául használunk.

3.1 Adatpiac célja és struktúrája

Az adatpiacokat úgy tervezzük meg, hogy az üzleti területek könnyen hozzáférjenek az aggregált és lekérdezésre optimalizált adatokhoz.

📌 Példa: Bankkártya-rendszer adatpiacai

Adatpiac	Célja
Fraud Data Mart	Csalásészlelési modellek támogatása (gyanús tranzakciók azonosítása).
Marketing Data Mart	Ügyfélszegmentáció, kártyahasználati szokások elemzése.
Financial Data Mart	Tranzakciós összegzések, pénznem szerinti riportok.
Regulatory Data Mart	Szabályozói jelentések (pl. AML - pénzmosás elleni riportok).

📌 Adattárolási struktúra:

Csillagséma (Star Schema) vagy
Hópehelyséma (Snowflake Schema)

A csillagséma előnye, hogy egyszerűbb és gyorsabb riportokhoz, míg a hópehelyséma jobb normálizációt biztosít.

3.2 Dimenziók és ténytáblák kialakítása

📌 Példa – Csillagséma tranzakciós adatpiac esetén

Tábla neve	Típus	Tartalom
FACT_TRANSACTIONS	Ténytábla	Kártyás tranzakciók részletei (összeg, dátum, deviza stb.).
DIM_CARD	Dimenzió	Kártyaadatok (kártyaszám, típusa, lejárat, ügyfél azonosító stb.).
DIM_CUSTOMER	Dimenzió	Ügyfél adatok (név, cím, státusz).
DIM_TIME	Dimenzió	Dátum dimenzió (nap, hónap, év, hét stb.).
DIM_MERCHANT	Dimenzió	Elfogadóhely adatok (név, ország, kategória).

3.3 Adatpiacok feltöltése

Az adatpiacok betöltése tipikusan aggregált, gyorsan lekérdezhető adatokat tartalmaz.

1️⃣ Dimenziók betöltése
Példa: Ügyfél dimenzió betöltése

--- sql

INSERT INTO DIM_CUSTOMER (customer_id, customer_name, country, segment, status)
SELECT DISTINCT
    c.hk_customer, 
    csat.customer_name, 
    csat.country, 
    CASE WHEN csat.total_spent > 100000 THEN 'VIP' ELSE 'Standard' END AS segment,
    csat.status
FROM HUB_CUSTOMER c
JOIN SAT_CUSTOMER csat ON c.hk_customer = csat.hk_customer;

2️⃣ Ténytábla betöltése
Példa: Tranzakciós ténytábla betöltése

--- sql

INSERT INTO FACT_TRANSACTIONS (transaction_id, card_id, customer_id, merchant_id, amount, currency, trx_date)
SELECT 
    t.hk_trx, 
    c.hk_card, 
    cu.hk_customer, 
    m.hk_merchant, 
    t.amount, 
    t.currency, 
    t.trx_time
FROM TRANSACTION_SAT t
JOIN LINK_CUSTOMER_CARD lc ON t.hk_card = lc.hk_card
JOIN HUB_CUSTOMER cu ON lc.hk_customer = cu.hk_customer
JOIN HUB_CARD c ON lc.hk_card = c.hk_card
JOIN HUB_MERCHANT m ON t.hk_merchant = m.hk_merchant;

3️⃣ Aggregált riportok generálása
Példa: Napi tranzakciós összegzés devizanem szerint

--- sql

CREATE MATERIALIZED VIEW MV_DAILY_TRX_SUMMARY AS
SELECT 
    trx_date, 
    currency, 
    SUM(amount) AS total_spent, 
    COUNT(*) AS trx_count
FROM FACT_TRANSACTIONS
GROUP BY trx_date, currency;

3.4 Riportok készítése

Miután az adatpiacokat feltöltöttük, különböző eszközök segítségével riportokat és dashboardokat készíthetünk.

📌 Riportolási eszközök

Eszköz	Jellemzők
Power BI	Interaktív dashboardok, könnyen összeköthető SQL adatbázissal.
Tableau	Erős vizualizációs képességek, jól skálázható.
Oracle BI	Nagyvállalati környezethez illeszkedő megoldás.
SAP BO	Komplex vállalati riportokhoz alkalmas.

📌 Példa Power BI riport – Kártyás tranzakciók időszakos elemzése

Szűrők: Dátum, kártyatípus, ügyfél szegmens.
Vizualizációk:
- Tranzakciós volumen időbeli alakulása.
- Ügyfélszegmensek szerinti kártyahasználat.
- Leggyakoribb tranzakciós helyszínek térképen.

3.5 Teljesítmény-optimalizálás adatpiac szinten

🔹 Materialized View-k – előre aggregált riportokat gyorsíthatunk.
🔹 Indexek és particionálás – gyorsabb lekérdezésekért.
🔹 Cache-elés – Power BI vagy Tableau oldalán az adatok gyorsítótárazása.
🔹 ETL optimalizálás – inkrementális frissítések alkalmazása teljes újratöltés helyett.

4. Adattárház karbantartása és monitorozása

Miután az adattárház és az adatpiacok működnek, folyamatos karbantartásra és monitorozásra van szükség, hogy biztosítsuk az adatok pontosságát, frissességét és a rendszer teljesítményét.

4.1 Adatminőség ellenőrzés

🔍 Cél: Az adattárházba betöltött adatok megbízhatóságának biztosítása.
📌 Tipikus adatminőségi problémák:

Hiányzó adatok (pl. ügyfélnév, tranzakció összege).
Duplikációk (ugyanaz a tranzakció kétszer jelenik meg).
Inkonszisztens adatok (pl. eltérő devizanem formátumok).

✅ Adatminőség-ellenőrzési lépések:

Ellenőrzés típusa	Példa SQL lekérdezés
Hiányzó adatok keresése	`SELECT * FROM DIM_CUSTOMER WHERE customer_name IS NULL;`
Duplikációk keresése	`SELECT card_number, COUNT() FROM FACT_TRANSACTIONS GROUP BY card_number HAVING COUNT() > 1;`
Értékkészlet ellenőrzés	`SELECT DISTINCT currency FROM FACT_TRANSACTIONS;`
Időbélyeg problémák	`SELECT * FROM FACT_TRANSACTIONS WHERE trx_date > SYSDATE;`

📌 Megoldás:

Automatizált adatminőség-ellenőrzés (pl. Python vagy SQL alapú validációs szkriptek).
Hiányzó adatok pótlása (pl. alapértelmezett értékek beállítása).
Duplikációk kiszűrése az ETL során.

4.2 ETL folyamatok monitorozása

🔍 Cél: Az adat betöltések stabilitásának és pontosságának fenntartása.

📌 Mit érdemes figyelni?
1️⃣ Betöltési idő – Mennyi ideig tart a teljes ETL folyamat?
2️⃣ Rekordszám-ellenőrzés – Hány rekord érkezett a forrásból és hány került betöltésre?
3️⃣ Hibás adatok – Milyen tranzakciók nem kerültek betöltésre és miért?

✅ Példa: ETL futás monitorozása egy log táblában

--- sql

CREATE TABLE ETL_LOG (
    job_name VARCHAR2(50),
    start_time TIMESTAMP,
    end_time TIMESTAMP,
    row_count NUMBER,
    status VARCHAR2(20),
    error_message VARCHAR2(500)
);

📌 PL/SQL példa egy ETL logolásra

--- sql

DECLARE
    v_start_time TIMESTAMP := SYSTIMESTAMP;
    v_row_count NUMBER := 0;
BEGIN
    -- Adat betöltése
    INSERT INTO FACT_TRANSACTIONS (...) 
    SELECT ... FROM STAGE_TRX;
    
    -- Rekordszám lekérdezése
    SELECT COUNT(*) INTO v_row_count FROM FACT_TRANSACTIONS;
    
    -- Log mentése
    INSERT INTO ETL_LOG (job_name, start_time, end_time, row_count, status) 
    VALUES ('TRANSACTION_ETL', v_start_time, SYSTIMESTAMP, v_row_count, 'SUCCESS');
    
    COMMIT;
EXCEPTION
    WHEN OTHERS THEN
        INSERT INTO ETL_LOG (job_name, start_time, end_time, row_count, status, error_message) 
        VALUES ('TRANSACTION_ETL', v_start_time, SYSTIMESTAMP, v_row_count, 'FAILED', SQLERRM);
        ROLLBACK;
END;

📌 Automatizálás eszközei:

Control-M vagy Airflow – Ütemezett ETL folyamatok futtatása és monitorozása.
Nagios, Prometheus – Adattárház teljesítményfigyelés.

4.3 Teljesítményoptimalizálás

🔍 Cél: Az ETL és riportfolyamatok gyorsítása.

📌 Problémák és megoldások

Probléma	Megoldás
Lassú lekérdezések	Indexek, materializált nézetek használata
Túl sok CPU/memória használat	PL/SQL Bulk Collect, particionált táblák
Hatalmas adatmennyiség mozgatása	Inkrementális betöltés, Delta Load használata
Riportok lassú futása	Cache-elés, OLAP kockák alkalmazása

✅ Példa: Particionált táblák használata
Ha a FACT_TRANSACTIONS tábla havi bontásban van particionálva:

--- sql

CREATE TABLE FACT_TRANSACTIONS (
    transaction_id NUMBER,
    card_id NUMBER,
    customer_id NUMBER,
    amount NUMBER,
    trx_date TIMESTAMP
)
PARTITION BY RANGE (trx_date) (
    PARTITION trx_2024_01 VALUES LESS THAN (TO_DATE('2024-02-01', 'YYYY-MM-DD')),
    PARTITION trx_2024_02 VALUES LESS THAN (TO_DATE('2024-03-01', 'YYYY-MM-DD'))
);

🔹 Előny: A riportok és lekérdezések gyorsabbak lesznek, mert az adatbázis csak az adott partíciót olvassa be.

✅ Példa: Materializált nézetek a gyors riportokhoz

--- sql

CREATE MATERIALIZED VIEW MV_TOP_MERCHANTS AS
SELECT merchant_id, SUM(amount) AS total_spent
FROM FACT_TRANSACTIONS
GROUP BY merchant_id;

🔹 Előny: A riportok nem futtatnak teljes aggregációt, hanem előre számított adatokat használnak.

4.4 Hiba- és incidenskezelés

🔍 Cél: Az adatbetöltési és riportolási hibák gyors felismerése és kezelése.

✅ Hiba típusok és megoldások

Hiba típusa	Megoldás
Nem futott le az ETL	Automatikus újrafuttatás Airflow/Control-M segítségével
Hiányzó adatok az adatpiacon	Ellenőrző lekérdezések és alert-ek beállítása
Lassú riportok	Indexek, materializált nézetek, OLAP optimalizálás
Duplikált tranzakciók	Adattisztítás, ETL szűrők, egyedi kulcsok beállítása

📌 Monitoring alert beállítása (Oracle Alert Script)

---sql

SELECT COUNT(*) FROM ETL_LOG WHERE status = 'FAILED' AND start_time > SYSDATE - 1;

🔹 Megoldás: Ha a hiba előfordul, küldhetünk automatikus emailt vagy figyelmeztetést.

5. Üzleti értéknövelés: Predikciós modellek és fejlett analitika

Miután az adattárház működik és stabil, a következő lépés az adatok üzleti értékének növelése. Ehhez fejlett elemzési és predikciós technikákat alkalmazhatunk, például Machine Learning modelleket a kártyás tranzakciók elemzésére.

5.1 Üzleti problémák, amelyekre ML megoldást adhat

📌 Példa egy bankkártya-rendszerben

Probléma	Megoldás
Csalásészlelés (Fraud Detection)	AI modellek a gyanús tranzakciók azonosítására
Ügyfélszegmentáció és ajánlórendszer	ML-alapú személyre szabott ajánlatok kártyabirtokosoknak
Tranzakciós volumen előrejelzés	Prediktív modellek a jövőbeni pénzforgalom becslésére
Hitelkártya-limitek optimalizálása	ML segítségével ügyfélspecifikus hitelkeretek ajánlása

5.2 Adatelőkészítés ML modellhez

Mielőtt Machine Learning modellt építünk, elő kell készíteni az adatokat.
Példa: Csalásészlelés (Fraud Detection)

✅ Adatok kiválasztása
A csalásokat felismerő modellhez szükségünk lehet:

Tranzakciós adatok: Összeg, időpont, helyszín, kártya típusa stb.
Ügyfél viselkedési minták: Átlagos költési szokások, földrajzi mozgások.
Korábbi csalásjelentések: Mely tranzakciókat jelölték csalásként.

✅ Feature Engineering (Új jellemzők létrehozása)
Az adatokból új változókat hozunk létre, amelyek segítenek a modellnek jobban megkülönböztetni a csalásokat a normál tranzakcióktól.
Példa új változókra csalásészleléshez:

Feature	Leírás
Tranzakció összeg vs. ügyfél átlagos költése	Ha az aktuális tranzakció jelentősen eltér az átlagtól, gyanús lehet.
Távolság az utolsó tranzakcióhoz képest	Egy ügyfél rövid időn belül két különböző országban? Gyanús lehet.
Tranzakciók időbeli mintázata	Éjjel történő tranzakciók nagyobb eséllyel lehetnek csalások.

✅ SQL-lekérdezés az adatok előállítására

---sql

SELECT 
    t.transaction_id, 
    t.amount, 
    c.customer_id, 
    c.segment, 
    t.trx_date, 
    (t.amount / AVG(t.amount) OVER (PARTITION BY c.customer_id)) AS amount_ratio,
    ST_DISTANCE(m.location, LAG(m.location) OVER (PARTITION BY c.customer_id ORDER BY t.trx_date)) AS geo_distance,
    CASE WHEN t.trx_date - LAG(t.trx_date) OVER (PARTITION BY c.customer_id ORDER BY t.trx_date) < INTERVAL '1' HOUR 
         THEN 1 ELSE 0 END AS rapid_succession_flag,
    t.is_fraud
FROM FACT_TRANSACTIONS t
JOIN DIM_CUSTOMER c ON t.customer_id = c.customer_id
JOIN DIM_MERCHANT m ON t.merchant_id = m.merchant_id;

🔹 Előny: A csalásgyanús viselkedés azonosításához extra jellemzőket hozunk létre, amelyeket az ML modellek felhasználhatnak.

5.3 Modellépítés és tanítás

Most, hogy az adatok készen állnak, építhetünk egy gépi tanulási modellt Python és scikit-learn vagy egy felhőalapú AI platform (pl. Azure Machine Learning, Google Vertex AI) segítségével.

✅ Példa: Random Forest modell csalásészleléshez Pythonban

--- python

import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import classification_report

# Adatok beolvasása
df = pd.read_csv('transactions.csv')

# Feature és target változók kiválasztása
features = ['amount_ratio', 'geo_distance', 'rapid_succession_flag']
X = df[features]
y = df['is_fraud']

# Adatok felosztása tanító és tesztelő készletre
X_train, X_test, y_train, y_test = train_test_split(X, y, test_size=0.2, random_state=42)

# Modell létrehozása és betanítása
model = RandomForestClassifier(n_estimators=100, random_state=42)
model.fit(X_train, y_train)

# Predikció és értékelés
y_pred = model.predict(X_test)
print(classification_report(y_test, y_pred))

🔹 Eredmény: Az ML modell azonosíthatja a csalásgyanús tranzakciókat, és akár valós időben figyelmeztethet a potenciálisan veszélyes eseményekre.

✅ AI modellek beépítése az adattárházba
A predikciós eredményeket visszatölthetjük az adattárházba egy "FRAUD_SCORE" oszlopba, amelyet riportokhoz és real-time monitoringhoz használhatunk.

---sql

ALTER TABLE FACT_TRANSACTIONS ADD fraud_score NUMBER;

UPDATE FACT_TRANSACTIONS t
SET fraud_score = (SELECT predicted_fraud FROM FRAUD_PREDICTIONS p WHERE t.transaction_id = p.transaction_id);

5.4 AI és automatizált döntéshozatal

📌 Mi történik, ha egy tranzakció gyanús?

A rendszer automatikusan blokkolja a kártyát.
SMS-t küld az ügyfélnek: „Ez Ön volt? (Igen/Nem)”.
Ha az ügyfél nem válaszol, a rendszer értesíti az ügyfélszolgálatot.

✅ RPA (UiPath, Automation Anywhere) és AI kombinációja

A bot automatizált ellenőrzéseket futtat, és ha kell, felhívja az ügyfelet.
AI elemzi az ügyfél reakcióit és ajánlást ad az ügyintézőnek.

5.5 Riportok és vizualizáció

A predikciós modellek eredményeit riportokban is meg lehet jeleníteni.

📌 Power BI dashboard példa:

Térképes vizualizáció a gyanús tranzakciókról.
Trend elemzés: nő vagy csökken a csalások aránya?
ML predikciós pontosságának mérése (Precision, Recall, F1-score).

6. Valós idejű adatfeldolgozás és streaming analitika

Miután a predikciós modellek és a csalásészlelés működnek, a következő szint az adatok valós idejű feldolgozása és azonnali reakciók biztosítása. Ezt streaming analitikával és eseményvezérelt architektúrával érhetjük el.

6.1 Miért van szükség valós idejű adatfeldolgozásra?

📌 Tipikus üzleti problémák, amelyek valós idejű adatfeldolgozást igényelnek:

Probléma	Valós idejű megoldás
Csalásészlelés	Azonnali gyanús tranzakció-azonosítás és kártya letiltás
Dinamikus hitelkeret-kezelés	Az ügyfél kártya-limitjének automatikus módosítása a költési szokásai alapján
Élő ügyfélszegmentáció	Vásárlás után azonnali kuponajánlat küldése
Tranzakciófigyelés	Banki ügyfélszolgálat azonnal értesítést kap egy problémás tranzakcióról

📌 Milyen technológiák alkalmasak erre?
🔹 Apache Kafka – Nagy teljesítményű valós idejű adatközvetítés.
🔹 Apache Flink / Spark Streaming – Streaming adatok feldolgozása és elemzése.
🔹 Azure Stream Analytics / Google Dataflow – Felhőalapú valós idejű analitika.

6.2 Streaming architektúra egy bankkártya-rendszerben

Egy valós idejű adatfeldolgozó rendszer így épülhet fel:

1️⃣ Tranzakciók beérkezése: Egy POS terminál vagy egy online vásárlás indít egy tranzakciót.
2️⃣ Adatküldés Kafka vagy egyéb message queue-ba: A tranzakciós adat egy üzenetként bekerül egy streaming rendszerbe.
3️⃣ Streaming elemzés (Spark Streaming, Flink, Azure Stream Analytics):

AI alapú csalásészlelés
Anomália-érzékelés
Azonnali riasztások
4️⃣ Döntéshozatal:
Ha csalás gyanúja van → kártya letiltása
Ha nagy összegű tranzakció történt → ügyfélértesítés
Ha vásárlási minta változik → ajánlat generálása
5️⃣ Adattárházba és adatpiacra írás

📌 Példa egy Apache Kafka alapú adatfolyamra:

---bash

# Kafka topic létrehozása
kafka-topics.sh --create --topic transactions --bootstrap-server localhost:9092

# Üzenet küldése a topicba
echo '{"card_id": 1234, "amount": 1500, "location": "London", "trx_time": "2025-03-26T12:00:00Z"}' | \
kafka-console-producer.sh --broker-list localhost:9092 --topic transactions

6.3 Streaming alapú csalásészlelés (Apache Spark Streaming)

A következő Spark Streaming kód folyamatosan figyeli a Kafka topicból érkező tranzakciókat, és kiszűri a csalásgyanúsakat.

✅ Példa: Spark Streaming kód csalás detektálására Pythonban

---python

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, when
from pyspark.sql.types import StructType, StructField, StringType, DoubleType, TimestampType

# Spark session létrehozása
spark = SparkSession.builder \
    .appName("FraudDetectionStreaming") \
    .getOrCreate()

# Tranzakciós adatstruktúra
schema = StructType([
    StructField("card_id", StringType(), True),
    StructField("amount", DoubleType(), True),
    StructField("location", StringType(), True),
    StructField("trx_time", TimestampType(), True)
])

# Adatfolyam beolvasása Kafka topicból
df = spark.readStream \
    .format("kafka") \
    .option("kafka.bootstrap.servers", "localhost:9092") \
    .option("subscribe", "transactions") \
    .load()

# JSON adat kinyerése és értelmezése
trx_data = df.selectExpr("CAST(value AS STRING)").selectExpr("from_json(value, schema) as data").select("data.*")

# Csalásgyanús tranzakciók azonosítása (pl. nagy összeg, ismeretlen helyszín)
fraudulent_trx = trx_data.withColumn("fraud_flag",
    when((col("amount") > 5000) | (col("location") == "Unknown"), 1).otherwise(0)
)

# Eredmények visszaírása egy másik Kafka topicba vagy egy adatbázisba
fraudulent_trx.writeStream \
    .format("console") \
    .outputMode("append") \
    .start() \
    .awaitTermination()

🔹 Előnyök:
✔️ Valós idejű csalásfelderítés, még mielőtt a tranzakció befejeződne.
✔️ Azonnali ügyfélértesítés vagy kártya-blokkolás lehetősége.
✔️ Automatikus adatfeldolgozás és adattárház frissítés.

6.4 Valós idejű riportok és vizualizáció

A streaming analitika egyik nagy előnye, hogy real-time dashboardokat építhetünk.

✅ Példa egy Power BI vagy Kibana dashboardra:

Csalásgyanús tranzakciók térképes megjelenítése.
Tranzakciók volumene óránként.
Ügyfélinterakciók nyomon követése az értesítések alapján.

📌 Adatvizualizáció SQL-ben (pl. egy real-time adatpiacon)

--- sql

SELECT trx_time, COUNT(*) AS transaction_count
FROM FACT_TRANSACTIONS
WHERE trx_time > SYSDATE - INTERVAL '1' HOUR
GROUP BY trx_time
ORDER BY trx_time DESC;

7. Automatizált riportolás és BI megoldások

Most, hogy az adattárház működik és valós idejű adatfolyamokat is kezelünk, a következő lépés az üzleti intelligencia (BI) megoldások kiépítése és automatizált riportok készítése. Ezzel biztosíthatjuk, hogy a szakterületek gyorsan és hatékonyan hozzáférjenek az adatokhoz.

7.1 Üzleti intelligencia célok

📌 Milyen riportokra van szükség egy bankkártya-rendszerben?

Riport típusa	Célja
Tranzakciós riportok	Napi/heti/havi tranzakciók elemzése
Csalásgyanús tranzakciók jelentése	Gyanús aktivitások azonosítása és vizsgálata
Ügyfélszegmentáció és költési szokások	Ügyfélprofilok elemzése, célzott ajánlatok készítése
Kártyahasználati trendek	Kártyás fizetések változásának vizsgálata (országonként, időszakonként)

📌 BI eszközök, amelyeket használhatunk

Power BI – Interaktív dashboardok, valós idejű adatelemzés.
Tableau – Haladó vizualizációk és prediktív elemzés.
Looker / Google Data Studio – Könnyen beépíthető Google Cloud környezetben.

7.2 Adatok előkészítése BI eszközökhöz

A riportok és dashboardok megfelelően strukturált adatokat igényelnek. Ezért készítünk egy adatpiacot (Data Mart), amelyet a BI eszközök könnyen feldolgozhatnak.

📌 SQL lekérdezés egy napi tranzakciós riporthoz

---sql

SELECT 
    trx_date, 
    card_type, 
    SUM(amount) AS total_amount, 
    COUNT(*) AS transaction_count
FROM FACT_TRANSACTIONS
WHERE trx_date >= SYSDATE - INTERVAL '7' DAY
GROUP BY trx_date, card_type
ORDER BY trx_date DESC;

🔹 Eredmény: Ezzel az adatbázis biztosítja a napi tranzakciós riport alapját.

7.3 Power BI dashboard felépítése

Power BI-ban létrehozhatunk egy interaktív dashboardot, amely élőben frissíti az adatokat.

✅ Példa egy Power BI dashboardra:
1️⃣ Tranzakciós trendek grafikonon – Havi tranzakciós volumen.
2️⃣ Hőtérkép a csalásokról – Hol fordulnak elő a legtöbb csalásgyanús tranzakciók?
3️⃣ Ügyfélszegmentáció – Milyen típusú ügyfelek milyen gyakran használják a kártyát?
4️⃣ Költekezési mintázatok – Mely boltokban költik a legtöbb pénzt?

📌 Valós idejű frissítés beállítása Power BI-ban:

DirectQuery mód – Közvetlen kapcsolat az adatbázishoz.
Power BI Gateway – On-premises adatkapcsolat frissítése.
Scheduled Refresh – Időzített adatfrissítés (pl. óránként).

7.4 Automatikus riportküldés (Power BI + SQL Server Reporting Services - SSRS)

A BI megoldások részeként beállíthatunk automatikus riportküldést az ügyfelek vagy a vezetőség számára.

📌 Automatikus riport generálása SQL Server Reporting Services (SSRS) segítségével

--- sql

EXEC sp_send_dbmail  
    @profile_name = 'BankReports',  
    @recipients = 'management@bank.com',  
    @subject = 'Napi tranzakciós riport',  
    @body = 'Csatoltan található a napi tranzakciós riport.',  
    @query = 'SELECT trx_date, card_type, SUM(amount) AS total_amount FROM FACT_TRANSACTIONS GROUP BY trx_date, card_type',  
    @attach_query_result_as_file = 1;

🔹 Eredmény: A riport minden reggel automatikusan e-mailben kiküldésre kerül.

7.5 Dashboard integráció mobil és webes alkalmazásokba

A vezetőség és az ügyfélszolgálat számára egy mobilon és weben is elérhető dashboardot hozhatunk létre.

📌 Power BI embed a bank belső rendszerébe (példa egy iframe kóddal)

---html

<iframe width="800" height="600" 
    src="https://app.powerbi.com/view?r=eyJrIjoiXXXXXXXXXXXX" 
    frameborder="0" allowFullScreen="true"></iframe>

🔹 Eredmény: A BI riportok banki intraneten, ügyfélszolgálati rendszeren vagy mobilalkalmazásban is elérhetők.

8. Teljesítményoptimalizálás és skálázhatóság

Most, hogy az adattárház adatokat fogad, feldolgozza őket és BI riportokkal kiszolgálja a szakterületeket, a következő lépés az optimalizálás és skálázás.

A nagy adatmennyiségek miatt fontos, hogy az adattárház megfelelően legyen indexelve, particionálva és finomhangolva, hogy a lekérdezések gyorsak maradjanak.

8.1 Teljesítményproblémák az adattárházban

📌 Tipikus problémák, amelyeket optimalizálni kell

Probléma	Lehetséges megoldás
Lassú lekérdezések	Indexelés, materializált nézetek
Hatalmas táblaméretek	Particionálás, adattömörítés
Párhuzamos tranzakciós terhelés	OLAP és OLTP szétválasztása
Riportok frissítési ideje túl hosszú	Delta load, inkrementális frissítések
Skálázási problémák nagy adatmennyiségnél	Elosztott adattárolás, felhőalapú adattárház

8.2 Indexelés és materializált nézetek

📌 Miért fontos az indexelés?
Ha az adattárházban egy nagy FACT_TRANSACTIONS tábla van, amelyben milliárdnyi tranzakció található, akkor a lekérdezések lassúak lehetnek.

✅ Megoldás: Indexek használata

---sql

CREATE INDEX idx_trx_date ON FACT_TRANSACTIONS(trx_date);
CREATE INDEX idx_card_id ON FACT_TRANSACTIONS(card_id);

🔹 Eredmény: A tranzakciós riportok gyorsabban futnak, mert az adatbázis az indexeket használja a keresésekhez.

📌 Materializált nézet létrehozása gyors riportokhoz
Ha egy riport mindig ugyanazokat az aggregált adatokat használja, akkor érdemes materializált nézetet létrehozni.

---sql

CREATE MATERIALIZED VIEW mv_trx_summary AS 
SELECT trx_date, card_type, SUM(amount) AS total_amount, COUNT(*) AS transaction_count
FROM FACT_TRANSACTIONS
GROUP BY trx_date, card_type;

🔹 Eredmény: A lekérdezés nem a teljes táblát fogja újra számolni, hanem az előre kiszámított adatokat használja.

8.3 Táblaparticionálás a teljesítmény növelése érdekében

📌 Probléma: Ha egy FACT_TRANSACTIONS tábla több terabájtnyi adatot tartalmaz, a riportok lassúak lesznek.

✅ Megoldás: Particionálás dátum alapján

--- sql

CREATE TABLE FACT_TRANSACTIONS (
    card_id NUMBER,
    trx_date DATE,
    amount NUMBER,
    location VARCHAR2(100)
)
PARTITION BY RANGE (trx_date) (
    PARTITION p202401 VALUES LESS THAN (TO_DATE('2024-02-01', 'YYYY-MM-DD')),
    PARTITION p202402 VALUES LESS THAN (TO_DATE('2024-03-01', 'YYYY-MM-DD')),
    PARTITION p202403 VALUES LESS THAN (TO_DATE('2024-04-01', 'YYYY-MM-DD'))
);

🔹 Eredmény: A rendszer csak az adott hónaphoz tartozó partíciót vizsgálja, nem az egész táblát.

8.4 OLTP és OLAP környezet szétválasztása

📌 Probléma: Az adattárház túlterhelődik, mert az ügyféltranzakciók (OLTP) és az elemzési lekérdezések (OLAP) egyazon rendszerben futnak.

✅ Megoldás: OLTP és OLAP szétválasztása
🔹 OLTP rendszer (Online Transaction Processing): Gyors, kis tranzakciók, például ügyfélkártyás fizetések.
🔹 OLAP rendszer (Online Analytical Processing): Nagy mennyiségű adat elemzése, például trendek vizsgálata.

👉 Megoldás: Az OLTP adatok másolása OLAP adattárházba napi vagy óránkénti ETL folyamatokkal.

---sql

INSERT INTO FACT_TRANSACTIONS (card_id, trx_date, amount, location)
SELECT card_id, trx_date, amount, location 
FROM OLTP_TRANSACTIONS
WHERE trx_date >= SYSDATE - INTERVAL '1' DAY;

🔹 Eredmény: Az ügyféltranzakciók nem lassítják az elemzéseket.

8.5 Skálázási megoldások nagy adattárházakhoz

📌 Ha az adattárház mérete növekszik, szükség lehet skálázásra.

✅ Vertikális skálázás (Scale-up)

Több memória, erősebb CPU az adatbázisszerveren
SSD-alapú adattárolás

✅ Horizontális skálázás (Scale-out)

Adatok elosztása több szerveren
Sharding (adatdarabolás) például ügyfélszegmensek szerint

✅ Felhőalapú adattárházak (Snowflake, BigQuery, Azure Synapse)

Automatikus skálázás
Költséghatékony adattárolás és számítási kapacitás

📌 Példa: Azure Synapse skálázása

---sql

ALTER DATABASE Warehouse 
MODIFY (SERVICE_OBJECTIVE = 'DW100c');

🔹 Eredmény: A rendszer dinamikusan növeli az erőforrásokat az igényeknek megfelelően.

9. Adatminőség és adatkezelési szabályok

Most, hogy az adattárház teljesítménye optimalizált és skálázható, a következő kulcsfontosságú lépés az adatminőség biztosítása és az adatkezelési szabályok bevezetése. Egy bankkártya-rendszer esetében az adatok pontossága, konzisztenciája és megbízhatósága kritikus fontosságú.

9.1 Miért fontos az adatminőség az adattárházban?

📌 Ha az adatok hibásak vagy hiányosak, az üzleti döntések pontatlanok lesznek.
📌 A pénzügyi szabályozások (pl. GDPR, PSD2) miatt az adatoknak pontosnak kell lenniük.
📌 A duplikált vagy hibás adatok felesleges tárhelyhasználatot és teljesítményproblémákat okoznak.

✅ Megoldás: Adatminőségi keretrendszer kialakítása

9.2 Adatminőség-ellenőrzési lépések

Ellenőrzési szint	Cél	Példa egy bankkártya-rendszerben
Formátumellenőrzés	Adatok helyes struktúrájának biztosítása	Kártyaszám 16 jegyű legyen
Hiányzó adatok keresése	Hiányzó rekordok azonosítása	Tranzakciókban mindig legyen dátum és összeg
Duplikációk kiszűrése	Ismétlődő adatok kiszűrése	Ugyanaz az ügyfél ne szerepeljen kétszer
Konzisztenciaellenőrzés	Kapcsolódó adatok egyezősége	Tranzakció összege ne legyen negatív
Üzleti szabályok ellenőrzése	Banki előírásoknak való megfelelés	Kártyás tranzakció max. limitje ne legyen átlépve

9.3 Példa SQL ellenőrzésekre

✅ 1️⃣ Hiányzó adatok keresése

---sql

SELECT * FROM FACT_TRANSACTIONS 
WHERE trx_date IS NULL OR amount IS NULL;

🔹 Eredmény: Azonosítjuk a hiányzó adatokat, és értesítjük az adatgazdát.

✅ 2️⃣ Duplikált tranzakciók kiszűrése

--- sql

SELECT trx_id, card_id, COUNT(*) 
FROM FACT_TRANSACTIONS 
GROUP BY trx_id, card_id 
HAVING COUNT(*) > 1;

🔹 Eredmény: Kiderül, ha egy tranzakció többször van rögzítve.

✅ 3️⃣ Inkonszisztens adatok keresése

---sql

SELECT * FROM FACT_TRANSACTIONS 
WHERE amount < 0;

🔹 Eredmény: Azonosítjuk az érvénytelen tranzakciókat.

✅ 4️⃣ Érvénytelen kártyaszámok keresése

---sql

SELECT * FROM DIM_CARD 
WHERE LENGTH(card_number) <> 16;

🔹 Eredmény: Azonosítjuk a hibásan rögzített kártyaszámokat.

9.4 Adattisztítás és minőségbiztosítás

🔹 Automatikus adatjavítási stratégiák:
✅ Üres értékek pótlása (pl. ha hiányzik egy tranzakció időbélyege, vegyük az aktuális dátumot)
✅ Hibás adatok módosítása (pl. érvénytelen országkódok javítása)
✅ Duplikációk kiszűrése és törlése

📌 Példa: Automatikus adattisztítás SQL-ben

--- sql

UPDATE FACT_TRANSACTIONS 
SET trx_date = SYSDATE 
WHERE trx_date IS NULL;

🔹 Eredmény: A hiányzó dátumokat automatikusan kiegészítjük.

📌 Példa: Duplikált adatok törlése

---sql

DELETE FROM FACT_TRANSACTIONS 
WHERE trx_id IN (
    SELECT trx_id FROM (
        SELECT trx_id, ROW_NUMBER() OVER (PARTITION BY trx_id ORDER BY trx_date DESC) AS rn 
        FROM FACT_TRANSACTIONS
    ) WHERE rn > 1
);

🔹 Eredmény: A duplikált tranzakciókat eltávolítjuk, megtartva a legfrissebb verziót.

9.5 Data Governance és adatvédelmi előírások (GDPR, PSD2)

A banki adattárházban tárolt adatoknak meg kell felelniük az adatvédelmi előírásoknak.

📌 Kulcsfontosságú előírások és azok kezelése

Adatvédelmi előírás	Követelmény	Megoldás az adattárházban
GDPR (EU)	Ügyfelek személyes adatainak védelme	Pseudonymizáció, adathozzáférés korlátozása
PSD2 (EU)	Biztonságos fizetési tranzakciók	Adatnaplózás, kétfaktoros hitelesítés
SOX (USA)	Pénzügyi adatok integritása	Audit logok vezetése, változáskövetés

✅ Adatok titkosítása az adattárházban
🔹 Példa: PII adatok titkosítása Oracle Transparent Data Encryption (TDE) segítségével

---sql

ALTER TABLE DIM_CUSTOMER 
MODIFY (customer_name ENCRYPT);

🔹 Eredmény: Az ügyféladatok titkosítva lesznek a tárolás során.

✅ Adathozzáférési jogosultságok beállítása

---sql

GRANT SELECT ON FACT_TRANSACTIONS TO BI_ANALYST;

🔹 Eredmény: Csak a szükséges felhasználók férhetnek hozzá az érzékeny adatokhoz.

10. Monitoring és karbantartás

Miután az adattárház felépítése és az adatminőség biztosítása megtörtént, a következő kulcsfontosságú lépés a folyamatos monitoring és karbantartás. Ez az adattárház működésének stabilitásáért, a teljesítmény fenntartásáért és a hibák minimalizálásáért felelős folyamat.

10.1 Miért fontos a monitoring és karbantartás?

📌 Teljesítményproblémák elkerülése: Az adattárház folyamatos növekedése és a lekérdezések komplexitása miatt szükséges a teljesítmény figyelése.
📌 Hibák időben történő észlelése: Az adatbetöltési folyamatokban fellépő problémák gyors felismerése segít megelőzni az adatvesztést.
📌 Adatvédelmi és jogi megfelelés biztosítása: A napi karbantartás segít biztosítani, hogy az adattárház mindig megfeleljen a jogszabályi előírásoknak (pl. GDPR).

10.2 Monitoring eszközök és metrikák

A monitoring során fontos, hogy a legfontosabb metrikákat folyamatosan figyeljük. A bankkártya-rendszer adattárházában az alábbi kulcsfontosságú mutatók és eszközök használata javasolt:

10.2.1 Teljesítménymutatók

📌 Lekérdezési idő: A lekérdezések végrehajtásának ideje.
📌 Tárhelyhasználat: Az adattárház által elfoglalt hely mennyisége.
📌 Adatbetöltési idő: Az adatok frissítésének és betöltésének ideje.
📌 Hibák száma: Az adatbetöltési folyamatok során felmerült hibák száma.

10.2.2 Monitorozási eszközök

Eszköz	Leírás
Oracle Enterprise Manager	Részletes teljesítményfigyelés, adatbázis- és rendszerfigyelés
SQL Server Management Studio	Tárhelyhasználat és lekérdezési teljesítmény monitorozása
Nagios	Különféle rendszerek és alkalmazások monitorozása, figyelmeztetések beállítása
Prometheus & Grafana	Részletes időszaki teljesítménymutatók és grafikonok készítése

🔹 Példa: Grafana konfigurálása adatbázis monitorozásához
A Grafana használható, hogy figyelemmel kísérjük az adattárház adatbázisainak teljesítményét. Beállítható, hogy az eszköz figyelje például a CPU kihasználtságot, memóriát, lekérdezési időket.

10.3 Automatizált figyelmeztetések

A hibák és problémák gyors észlelése érdekében automatizált figyelmeztetéseket állíthatunk be. Az alábbiak szerint:

10.3.1 Lekérdezési idő figyelése

📌 Ha egy lekérdezés túl sokáig tart (pl. 5 másodpercnél hosszabb), azonnali figyelmeztetés érkezhet.

---sql

SELECT * FROM sys.dm_exec_requests 
WHERE status = 'running' 
AND start_time < SYSDATETIME() - INTERVAL '5' SECOND;

🔹 Eredmény: Az időben történő figyelmeztetések segítenek a teljesítményproblémák gyors kezelésében.

10.3.2 Adatbetöltési hibák figyelése

📌 Ha az ETL folyamatok nem futnak le megfelelően, vagy hibát jeleznek, azonnal értesíthetjük a rendszergazdát.

---bash

grep "ETL job failed" /var/log/etl_process.log

🔹 Eredmény: A hibák gyors felismerése és javítása.

10.4 Karbantartási feladatok

A rendszer folyamatos működése érdekében szükség van a rendszeres karbantartásra, hogy az adattárház hatékonyan és gyorsan működjön. Néhány fontos karbantartási feladat:

10.4.1 Indexek újjáépítése

Az adatbázis teljesítményének javítása érdekében érdemes időszakosan újraépíteni az indexeket.

---sql

ALTER INDEX idx_trx_date REBUILD;

🔹 Eredmény: Az indexek gyorsítják a lekérdezéseket és csökkentik a válaszidőt.

10.4.2 Törlés és archiválás

A régi vagy már nem szükséges adatokat archiválni kell, hogy a rendszer ne terhelődjön le túl sok nem használt adattal.

---sql

DELETE FROM FACT_TRANSACTIONS WHERE trx_date < TO_DATE('2023-01-01', 'YYYY-MM-DD');

🔹 Eredmény: Csökkentjük az adattárház terhelését és javítjuk a teljesítményt.

10.4.3 Szervizablakok beállítása

Az adattárház karbantartási feladatait érdemes meghatározott időpontokban végezni, például éjszakai vagy hétvégi szervizablakokban, amikor az üzleti folyamatok alacsony terhelés alatt állnak.

10.5 Adattárház naplózás és auditálás

A naplózás segít az adattárház működésének nyomon követésében, valamint biztosítja a biztonsági és jogi megfelelést. A banki környezetben különösen fontos, hogy a pénzügyi tranzakciók és az adatok kezelésének minden lépése naplózásra kerüljön.

10.5.1 Naplózás beállítása Oracle DB-ben

--- sql

ALTER SYSTEM SET AUDIT_TRAIL = DB,EXTENDED;

🔹 Eredmény: A rendszer minden fontos tranzakciót és műveletet naplóz, segítve ezzel a biztonságot és a megfelelést.

10.5 Példa: Indexek újjáépítése és statisztikák frissítése

📌 Indexek újjáépítése

--- sql

ALTER INDEX idx_trx_date REBUILD;

🔹 Eredmény: Az index újjáépítésével csökkenthetjük a fragmentációt, és javíthatjuk a lekérdezési teljesítményt.

📌 Statisztikák frissítése

---sql

EXEC DBMS_STATS.GATHER_SCHEMA_STATS('SALES');

🔹 Eredmény: A frissített statisztikák segítik az adatbázis optimalizálásában a lekérdezéseket.

10.6 Teljesítmény optimalizálási eszközök

📌 Explain Plan
A lekérdezési terv elemzése segít azonosítani a teljesítménybeli problémákat.

---sql

EXPLAIN PLAN FOR 
SELECT card_id, SUM(amount) FROM FACT_TRANSACTIONS GROUP BY card_id;

🔹 Eredmény: A lekérdezés optimalizálása a legjobb teljesítmény eléréséhez.

📌 Database Performance Tuning Advisor (Oracle)
Az Oracle DB Performance Tuning Advisor segít az adatbázis teljesítményének finomhangolásában.

IT, BI, DWH, DM, AI