┌─────────────┬──────────────────────┬─────────────────────────────┬──────────────┬────────────────┐
│ id_pelanggan│ nama                 │ email                       │ no_telp      │ tgl_lahir      │
├─────────────┼──────────────────────┼─────────────────────────────┼──────────────┼────────────────┤
│ 1           │ Budi Santoso         │ budi@gmail.com              │ 081234567890 │ 1995-03-15     │
│ 2           │ SITI RAHAYU          │ sitirahayugmail.com         │ 0812-3456-78 │ 1998-11-20     │ ← masalah?
│ 3           │ Ahmad               │ ahmad@yahoo.com             │ +62812345678 │ 1990-07-08     │ ← masalah?
│ 4           │ Dewi Lestari         │ dewi@gmail.com              │ NULL         │ 2025-06-15     │ ← masalah?
│ 5           │ test                 │ test@test.com               │ 08000000000  │ NULL           │ ← masalah?
│ 6           │ Budi Santoso         │ budi2@gmail.com             │ 081234567890 │ 1995-03-15     │ ← masalah?
│ 7           │ Rizki Pratama        │ rizki@gmail.com             │ 08987654321  │ 1988-04-22     │
│ 8           │ aaa                  │ aaa@aaa.com                 │ 12345        │ NULL           │ ← masalah?
│ 9           │ Indah Permatasari    │ indah@gmail.com             │ 087812345678 │ 2010-09-01     │ ← masalah?
│ 10          │ Joko Widodo          │ jokowi@pemerintah.go.id     │ 081100000001 │ 1961-06-21     │
└─────────────┴──────────────────────┴─────────────────────────────┴──────────────┴────────────────┘

┌───────────────────────────────────────────────────────────────────────────┐
│                    6 DIMENSI KUALITAS DATA                                │
│                  (Data Quality Framework — DAMA/ISO 8000)                 │
├──────────────────┬────────────────────────────┬───────────────────────────┤
│ Dimensi          │ Definisi                    │ Contoh Pelanggaran        │
├──────────────────┼────────────────────────────┼───────────────────────────┤
│ 1. ACCURACY      │ Data benar-benar             │ tgl_lahir = 2025-06-15   │
│ (Akurasi)        │ merepresentasikan realitas  │ (tanggal di masa depan)  │
│                  │ — nilai sesuai kenyataan    │ nama = "Joko Santoso"    │
│                  │                             │ tapi orangnya "Ahmad"    │
├──────────────────┼────────────────────────────┼───────────────────────────┤
│ 2. COMPLETENESS  │ Semua data yang diperlukan  │ no_telp = NULL padahal   │
│ (Kelengkapan)    │ ada dan tidak ada nilai     │ wajib diisi untuk notif  │
│                  │ yang hilang                 │ Nama hanya "Ahmad" tanpa │
│                  │                             │ nama belakang            │
├──────────────────┼────────────────────────────┼───────────────────────────┤
│ 3. CONSISTENCY   │ Data yang sama dinyatakan   │ Format no_telp campur:   │
│ (Konsistensi)    │ dengan cara yang sama di   │ "081234", "+62812", "812" │
│                  │ seluruh sistem              │ Nama ada yang Title Case, │
│                  │                             │ ada yang UPPERCASE       │
├──────────────────┼────────────────────────────┼───────────────────────────┤
│ 4. TIMELINESS    │ Data tersedia tepat waktu   │ Data pelanggan diperbarui │
│ (Ketepatan       │ dan mencerminkan kondisi   │ setahun sekali → alamat  │
│ Waktu)           │ terkini yang dibutuhkan     │ sudah tidak relevan       │
│                  │                             │ Harga produk tidak       │
│                  │                             │ diperbarui saat promo    │
├──────────────────┼────────────────────────────┼───────────────────────────┤
│ 5. VALIDITY      │ Data sesuai format, tipe,   │ Email tanpa "@"          │
│ (Validitas)      │ dan range yang telah        │ No KTP hanya 10 digit    │
│                  │ ditetapkan                  │ Rating = 7 (seharusnya   │
│                  │                             │ 1–5 saja)                │
│                  │                             │ Nama = "test", "aaa"     │
├──────────────────┼────────────────────────────┼───────────────────────────┤
│ 6. UNIQUENESS    │ Tidak ada data yang         │ Pelanggan terdaftar dua  │
│ (Keunikan)       │ terduplikasi secara tidak   │ kali dengan email berbeda │
│                  │ semestinya                  │ Transaksi muncul dua kali │
│                  │                             │ karena double processing  │
└──────────────────┴────────────────────────────┴───────────────────────────┘

MASALAH ACCURACY YANG UMUM:
  → Data diinput dengan salah (typo, salah baca formulir)
  → Data sudah benar saat diinput tapi realitasnya berubah:
    - Alamat pelanggan (pindah rumah)
    - Status pernikahan (berubah)
    - Jabatan karyawan (promosi/mutasi)
  → Data yang masuk akal tapi salah:
    - Gaji = 50.000 (harusnya 5.000.000)
    - Umur = 200 (harusnya 20)

CARA MENDETEKSI:
  ✓ Range check: CHECK (tgl_lahir < CURRENT_DATE)
  ✓ Cross-validation dengan sumber lain (verifikasi KTP, dll.)
  ✓ Statistical outlier detection di level aplikasi atau pipeline ETL
  ✓ Audit berkala terhadap sampel data

CARA MENCEGAH:
  ✓ Validasi input di level aplikasi (bukan hanya DB)
  ✓ Double-entry verification untuk data kritis
  ✓ Audit trail: siapa mengubah apa, kapan
  ✓ Proses update data berkala (data refresh)

PERBEDAAN PENTING: NULL yang "Sah" vs NULL yang "Masalah"

  NULL yang SAH:
    tgl_kembali DATE NULL  ← NULL berarti "belum dikembalikan" (semantik bisnis)
    tgl_menikah DATE NULL  ← NULL berarti "belum menikah"
    no_fax VARCHAR NULL    ← Tidak semua orang/perusahaan punya fax

  NULL yang BERMASALAH:
    nama VARCHAR NOT NULL → tapi data lama ada yang "" (string kosong)
    email VARCHAR NOT NULL → ada yang "N/A" atau "tidak punya"
    → String kosong lolos NOT NULL constraint!

COMPLETENESS BUKAN HANYA SOAL NULL:
  → String kosong ("") ≠ NULL — keduanya berbeda, keduanya bisa bermasalah
  → Kolom ada isinya tapi isinya tidak bermakna:
    nama = "-", "xxx", "tidak diketahui"
  → Kolom wajib dalam konteks bisnis tapi tidak di-constraint di DB:
    Misal: untuk pengiriman, alamat lengkap wajib ada

CARA MENGUKUR COMPLETENESS:
  SELECT
    COUNT(*) AS total_baris,
    SUM(CASE WHEN nama IS NULL OR nama = '' THEN 1 ELSE 0 END) AS nama_kosong,
    SUM(CASE WHEN email IS NULL OR email = '' THEN 1 ELSE 0 END) AS email_kosong,
    ROUND(100.0 * SUM(CASE WHEN email IS NULL THEN 1 ELSE 0 END) / COUNT(*), 2)
        AS pct_email_null
  FROM pelanggan;

DUA JENIS KONSISTENSI:

A. Konsistensi Intra-Tabel (dalam satu tabel):
   → Format yang tidak seragam dalam kolom yang sama
   
   CONTOH: Kolom no_telp dengan berbagai format:
   +─────────────────────────────┐
   │ 081234567890                │
   │ 0812-3456-7890              │  ← berbeda format
   │ +62 812 3456 7890           │  ← berbeda format
   │ 62812345678                 │  ← tidak ada leading 0
   │ (021) 555-1234              │  ← nomor tetap, bukan HP
   └─────────────────────────────┘
   
   Saat mau filter pelanggan dengan prefix "0812":
   WHERE no_telp LIKE '0812%'
   → Hanya menemukan format pertama dan kedua! Baris 3, 4, 5 terlewat.

B. Konsistensi Inter-Tabel (antar tabel atau antar sistem):
   → Data yang sama dinyatakan berbeda di tempat berbeda
   
   CONTOH:
   Tabel KARYAWAN: jabatan = "Manajer Keuangan"
   Tabel PAYROLL : jabatan = "Finance Manager"
   → Apakah ini orang/jabatan yang sama? Tidak bisa dipastikan!
   
   Solusi: Gunakan tabel referensi (master data) untuk jabatan,
           simpan jabatan_id FK ke tabel JABATAN — konsisten!

CARA MENEGAKKAN KONSISTENSI FORMAT:
  ✓ Gunakan ENUM untuk nilai terbatas (status, jenis, kategori)
  ✓ Normalisasi format di level aplikasi sebelum INSERT
    (UPPER(), LOWER(), TRIM(), regex replacement)
  ✓ Gunakan tabel referensi (master data) untuk data terstandar
  ✓ CHECK constraint dengan REGEXP (terbatas)

DATA YANG "BENAR" KEMARIN BISA "SALAH" HARI INI:

Contoh nyata:
  Sistem CRM menyimpan alamat pelanggan saat pertama mendaftar.
  Tiga tahun kemudian, 40% pelanggan sudah pindah alamat.
  Tim marketing mengirim brosur → 40% tidak sampai.

Dimensi timeliness mencakup:
  → CURRENCY: Seberapa baru data terakhir diperbarui?
  → LATENCY : Berapa lama jeda antara kejadian di dunia nyata
               dengan data tersimpan di database?
  → FRESHNESS: Apakah data cukup segar untuk use case saat ini?

SOLUSI UMUM:
  ✓ Audit columns: created_at, updated_at di setiap tabel
  ✓ Proses validasi data berkala (periodic data cleansing)
  ✓ Konfirmasi data saat ada interaksi: "Apakah alamat Anda masih sama?"
  ✓ SLA untuk refresh data: "Data diperbarui setiap 24 jam"
  ✓ Data expiry policy: Tandai data yang sudah terlalu lama tidak diperbarui

VALIDITY: DATA HARUS SESUAI ATURAN YANG DITETAPKAN

Level-level validasi:

Level 1 — FORMAT:
  Email harus mengandung "@" dan "."
  Nomor KTP harus 16 digit
  Kode pos Indonesia harus 5 digit angka

Level 2 — RANGE / DOMAIN:
  Usia harus antara 0 dan 150
  Rating antara 1 dan 5
  Persentase antara 0 dan 100
  Tanggal lahir harus di masa lalu

Level 3 — REFERENTIAL:
  id_kategori di tabel PRODUK harus ada di tabel KATEGORI
  (ini yang dijaga FK constraint)

Level 4 — BUSINESS RULE:
  Tanggal selesai proyek harus setelah tanggal mulai
  Pelanggan di bawah 18 tahun tidak boleh beli produk tertentu
  Stok tidak boleh negatif

CARA MENEGAKKAN VALIDITY:
  ✓ Level DB   : CHECK constraint, FK constraint, ENUM, NOT NULL
  ✓ Level App  : Validasi di form/API sebelum data masuk ke DB
  ✓ Level ETL  : Data profiling dan cleaning saat ingestion
  ✓ Level Audit: Monitoring otomatis dan alerting

MASALAH DUPLIKASI DATA — LEBIH UMUM DARI YANG DIKIRA

Penyebab duplikasi:
  → Double-submit form (user klik tombol dua kali)
  → Retry mekanisme di sistem yang gagal di tengah jalan
  → Multiple entry points: web + mobile + admin panel
  → Migrasi data dari sistem lama
  → Integrasi data dari beberapa sumber

JENIS DUPLIKASI:
  1. Exact duplicate  : Semua kolom identik (paling mudah dideteksi)
  2. Near-duplicate   : Beda tipis: "Budi Santoso" vs "Budi Santoso "
                        (ada spasi di akhir) — sama tapi tidak exact match
  3. Logical duplicate: email berbeda tapi orangnya sama
                        budi@gmail.com vs budi.santoso@gmail.com

CARA MENDETEKSI DUPLIKASI:
  -- Mencari baris dengan kombinasi nilai yang duplikat
  SELECT nama, email, tgl_lahir, COUNT(*) AS jumlah
  FROM pelanggan
  GROUP BY nama, email, tgl_lahir
  HAVING COUNT(*) > 1;

CARA MENCEGAH:
  ✓ UNIQUE constraint pada kolom atau kombinasi kolom yang harus unik
  ✓ Idempotency key di API: setiap request punya ID unik,
    request yang sama tidak diproses dua kali
  ✓ Deduplication check sebelum INSERT
  ✓ Master Data Management (MDM) untuk data shared antar sistem

CONTOH RANTAI MASALAH:

Masalah CONSISTENCY (format no_telp berbeda-beda)
       ↓
Menyebabkan masalah UNIQUENESS (tidak bisa deteksi duplikasi)
       ↓
Menyebabkan masalah ACCURACY (laporan jumlah pelanggan unik salah)
       ↓
Menyebabkan keputusan bisnis yang keliru

CONTOH LAIN:

Masalah TIMELINESS (data alamat tidak diperbarui)
       ↓
Menyebabkan masalah ACCURACY (alamat sudah tidak benar)
       ↓
Menyebabkan masalah COMPLETENESS dari sudut pandang bisnis
  (data "ada" tapi tidak berguna untuk pengiriman)

1. ENTITY INTEGRITY (Integritas Entitas)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Aturan: Setiap baris dalam tabel harus dapat diidentifikasi secara unik.
          Primary Key TIDAK BOLEH NULL dan harus UNIK.

  Mekanisme: PRIMARY KEY constraint (otomatis NOT NULL + UNIQUE)
  
  Contoh pelanggaran:
  → Dua baris dengan id_produk yang sama
  → id_produk = NULL
  
  Penegakan: DBMS secara otomatis menolak INSERT/UPDATE yang melanggar PK.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2. REFERENTIAL INTEGRITY (Integritas Referensial)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Aturan: Nilai FK harus merujuk ke PK yang benar-benar ADA di tabel induk.
          Tidak boleh ada "orphan record" — baris anak yang merujuk
          ke induk yang sudah tidak ada.

  Mekanisme: FOREIGN KEY constraint dengan ON DELETE / ON UPDATE action
  
  Contoh pelanggaran:
  → PESANAN.id_pelanggan = 999, tapi id_pelanggan = 999
    tidak ada di tabel PELANGGAN (orphan record)
  → Hapus PELANGGAN yang masih punya PESANAN aktif
  
  DAMPAK ORPHAN RECORD:
    SELECT pesanan.*, pelanggan.nama
    FROM pesanan
    LEFT JOIN pelanggan ON pesanan.id_pelanggan = pelanggan.id_pelanggan;
    → Baris dengan id_pelanggan = 999 akan menghasilkan NULL
      di semua kolom pelanggan → laporan penjualan kacau!

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

3. DOMAIN INTEGRITY (Integritas Domain)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Aturan: Nilai kolom harus berada dalam domain (rentang/himpunan) yang
          telah ditentukan — tipe data, format, range, dan daftar nilai valid.

  Mekanisme: Data type, CHECK constraint, ENUM, NOT NULL, DEFAULT
  
  Contoh pelanggaran:
  → rating = 7 (padahal harus 1-5) → CHECK gagal
  → email tanpa "@" → lolos NOT NULL tapi tidak valid bisnis
  → harga = -50000 → CHECK (harga >= 0) gagal
  
  LAPISAN DOMAIN INTEGRITY:
  Layer 1 - DBMS     : Tipe data, CHECK, ENUM, NOT NULL
  Layer 2 - Aplikasi : Validasi form, regex, API validation
  Layer 3 - ETL      : Data profiling, cleansing sebelum load

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

4. USER-DEFINED INTEGRITY (Integritas Business Rule)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  Aturan: Aturan bisnis spesifik yang tidak bisa di-encode sepenuhnya
          dengan constraint standar — membutuhkan logika tambahan.

  Mekanisme: Trigger, stored procedure, application logic
  
  Contoh business rule yang rumit:
  → "Seorang karyawan tidak boleh mengajukan cuti lebih dari 12 hari
     dalam satu tahun kalender" → butuh hitung SUM dari tabel CUTI
  → "Stok tidak boleh dipesan melebihi stok yang tersedia"
    → butuh cek stok real-time saat ORDER dibuat
  → "Diskon 15% hanya berlaku untuk member yang bergabung lebih dari 1 tahun"
    → butuh hitung selisih tanggal bergabung
  
  IMPLEMENTASI VIA TRIGGER (contoh cek stok):
  
  DELIMITER $$
  CREATE TRIGGER before_insert_order_item
  BEFORE INSERT ON item_pesanan
  FOR EACH ROW
  BEGIN
    DECLARE stok_tersedia INT;
    SELECT stok INTO stok_tersedia
    FROM produk WHERE id_produk = NEW.id_produk;
    
    IF NEW.qty > stok_tersedia THEN
      SIGNAL SQLSTATE '45000'
      SET MESSAGE_TEXT = 'Stok tidak mencukupi!';
    END IF;
  END$$
  DELIMITER ;

DATABASE LAYER (Lapisan 1 — Paling kuat):
  Penegak: MySQL/PostgreSQL engine
  Tools  : PK, FK, UNIQUE, CHECK, ENUM, NOT NULL, TRIGGER
  Kelebihan:
    ✓ Tidak bisa di-bypass dari jalur manapun (web, mobile, API, direct SQL)
    ✓ Terpusat — satu aturan untuk semua akses
    ✓ Otomatis — tidak bergantung pada developer mengingat aturan
  Kelemahan:
    ✗ Pesan error dari DB seringkali tidak user-friendly
    ✗ Beberapa business rule terlalu kompleks untuk di-constraint di DB
    ✗ Cross-table validation lebih sulit (butuh trigger)

APPLICATION LAYER (Lapisan 2 — Fleksibel):
  Penegak: Backend framework (Laravel, Spring, Django, dll.)
  Tools  : Form validation, API validation, regex, business logic
  Kelebihan:
    ✓ Bisa memberikan pesan error yang user-friendly
    ✓ Bisa implementasi business rule yang sangat kompleks
    ✓ Bisa validasi multi-step (cek ketersediaan, hitung diskon, dll.)
  Kelemahan:
    ✗ Bisa di-bypass jika ada jalur akses langsung ke DB
    ✗ Harus diimplementasikan di setiap aplikasi yang mengakses DB
    ✗ Rentan terhadap bug developer

PROCESS LAYER (Lapisan 3 — Kompensasi):
  Penegak: Manusia, SOP, audit berkala, ETL pipeline
  Tools  : Review proses, periodic data audit, anomaly detection
  Kelebihan:
    ✓ Bisa menangkap masalah yang tidak bisa dideteksi otomatis
    ✓ Bisa menangani kasus edge yang tidak terprediksi
  Kelemahan:
    ✗ Lambat dan mahal
    ✗ Tidak konsisten (bergantung pada manusia)
    ✗ Setelah data masuk DB, memperbaikinya lebih sulit

PRINSIP: Defense in Depth
  Idealnya, semua tiga lapisan aktif.
  Jangan mengandalkan hanya satu lapisan.
  "Constraint di DB adalah jaring pengaman terakhir, bukan satu-satunya."

SKENARIO NYATA: SISTEM MANAJEMEN PROYEK

Tabel: PROYEK (id_proyek, nama, anggaran, id_manajer*)
       KARYAWAN (id_karyawan, nama, ...)
       TUGAS (id_tugas, deskripsi, id_proyek*, id_karyawan*)

SKENARIO 1: Manajer mengundurkan diri
  → Apakah boleh hapus data karyawan yang menjadi manajer proyek aktif?
  → ON DELETE RESTRICT pada PROYEK.id_manajer:
     Tidak bisa hapus sebelum proyek ditutup atau manajer diganti.
  
SKENARIO 2: Proyek dihapus (dibatalkan)
  → Apakah semua tugas dalam proyek harus ikut dihapus?
  → ON DELETE CASCADE pada TUGAS.id_proyek:
     Semua tugas otomatis terhapus saat proyeknya dihapus.
  
SKENARIO 3: Karyawan dipindah departemen tapi tetap di kantor
  → Tugasnya tetap harus ada, tapi id_karyawan berubah?
  → id_karyawan tidak berubah (surrogate key stabil) → tidak masalah
  → Tapi jika natural key (nama) yang berubah → ON UPDATE CASCADE memperbarui
    semua FK yang merujuk ke karyawan tersebut secara otomatis

PEMAHAMAN MENDALAM: RESTRICT vs NO ACTION
  Keduanya menolak DELETE/UPDATE jika masih ada child rows.
  Perbedaan: RESTRICT = cek SEBELUM statement dieksekusi
             NO ACTION = cek SETELAH semua statement dalam transaksi selesai
  Praktis di MySQL: Keduanya berperilaku sama untuk single statement.
  Relevan di PostgreSQL: NO ACTION memungkinkan UPDATE dalam transaksi
  multi-statement yang lebih kompleks.

TIGA JENIS METADATA:

1. TECHNICAL METADATA (Metadata Teknis)
   Mendeskripsikan struktur fisik dan teknis dari data.
   
   Isi:
   → Nama tabel dan kolom
   → Tipe data setiap kolom
   → Constraint (PK, FK, UNIQUE, NOT NULL, CHECK)
   → Index dan storage engine
   → Relasi antar tabel
   
   Contoh: Dokumentasi DDL, schema diagram, INFORMATION_SCHEMA di MySQL
   Siapa yang butuh: DBA, developer, data engineer

2. BUSINESS METADATA (Metadata Bisnis)
   Mendeskripsikan makna bisnis dan konteks dari data.
   
   Isi:
   → Definisi bisnis setiap kolom dalam bahasa non-teknis
   → Pemilik data (data owner) dan penanggung jawab (steward)
   → Aturan bisnis yang berlaku
   → Kriteria kualitas data
   → Frekuensi pembaruan
   
   Contoh: Data dictionary, business glossary, data catalog
   Siapa yang butuh: Business analyst, data scientist, manajer, auditor

3. OPERATIONAL METADATA (Metadata Operasional)
   Mendeskripsikan bagaimana data digunakan dan dikelola.
   
   Isi:
   → Data lineage: Data ini berasal dari mana?
   → Riwayat perubahan (audit trail, change log)
   → Statistik penggunaan: Tabel mana yang paling sering di-query?
   → Hasil profiling: Berapa persen NULL? Distribusi nilai?
   → Jadwal refresh dan ETL history
   
   Contoh: Audit log, INFORMATION_SCHEMA.TABLE_STATISTICS, ETL logs
   Siapa yang butuh: Data engineer, DBA, compliance officer

APA ITU DATA DICTIONARY?

Data Dictionary (DD) adalah dokumen terstruktur yang berfungsi sebagai
"kamus resmi" dari seluruh data yang ada dalam sistem database.

Ia menjadi single source of truth untuk:
  → "Apa arti kolom status di tabel pesanan?"
  → "Siapa yang boleh mengubah data harga produk?"
  → "Nilai apa saja yang valid untuk kolom jenis_anggota?"
  → "Dari mana data ini berasal (lineage)?"
  → "Kapan terakhir tabel ini diperbarui?"

MENGAPA DATA DICTIONARY PENTING?

Tanpa DD:
  → Developer baru butuh berminggu-minggu memahami struktur DB
  → Nama kolom ambigu: apakah "status" di tabel A sama dengan
    "status" di tabel B?
  → Data scientist tidak tahu arti kolom → analisis bisa keliru
  → Saat ada bug: tidak ada referensi untuk memahami aturan bisnis yang benar

Dengan DD:
  → Onboarding anggota tim baru lebih cepat
  → Analisis data lebih akurat (konteks jelas)
  → Komunikasi antar tim lebih efektif (bahasa yang sama)
  → Compliance dan audit lebih mudah (dokumentasi tersedia)
  → Evolusi sistem lebih aman (dampak perubahan bisa dianalisis)

SIAPA YANG MEMBUAT DAN MEMELIHARA DD?
  → Data modeller / database architect: membuat DD awal
  → DBA: memastikan DD sinkron dengan struktur DB
  → Business analyst: mengisi definisi bisnis
  → Data steward: memelihara dan memperbarui DD secara berkelanjutan

╔══════════════════════════════════════════════════════════════════════════╗
║                        DATA DICTIONARY — LEVEL TABEL                    ║
╠════════════════════════╦═════════════════════════════════════════════════╣
║ Atribut               ║ Nilai                                            ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Nama Tabel            ║ peminjaman                                       ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Skema / Database      ║ perpustakaan                                     ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Deskripsi Bisnis      ║ Menyimpan riwayat lengkap setiap transaksi       ║
║                       ║ peminjaman buku oleh anggota perpustakaan,       ║
║                       ║ termasuk tanggal pinjam, rencana kembali,        ║
║                       ║ tanggal aktual kembali, dan denda keterlambatan. ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Pemilik Data          ║ Divisi Perpustakaan — Bagian Sirkulasi           ║
║ (Data Owner)          ║                                                  ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Penanggung Jawab      ║ Kepala Bagian Sirkulasi                          ║
║ (Data Steward)        ║                                                  ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Frekuensi Pembaruan   ║ Real-time (setiap ada transaksi pinjam/kembali)  ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Retensi Data          ║ Disimpan selamanya (riwayat permanen); arsip     ║
║                       ║ ke tabel historis setelah 5 tahun               ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Sumber Data           ║ Sistem Perpustakaan Online, input petugas        ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Estimasi Jumlah Baris ║ ~50.000 baris/tahun (asumsi 200 peminjaman/hari) ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Business Rules        ║ 1. Satu anggota hanya boleh meminjam 3 buku     ║
║                       ║    secara bersamaan                              ║
║                       ║ 2. Masa pinjam standar: 7 hari                  ║
║                       ║ 3. Denda keterlambatan: Rp 500/hari/buku        ║
║                       ║ 4. Anggota tidak aktif tidak boleh meminjam     ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Tabel Terkait         ║ anggota (FK: id_anggota)                        ║
║                       ║ buku (FK: id_buku)                               ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Dibuat Tanggal        ║ 2025-08-01                                       ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Terakhir Diperbarui   ║ 2026-02-20                                       ║
╠════════════════════════╬═════════════════════════════════════════════════╣
║ Versi                 ║ 1.2                                              ║
╚════════════════════════╩═════════════════════════════════════════════════╝

╔═══════════════╦══════════════════╦══════╦══════╦════════╦═══════════════════════════════════════════╗
║ Nama Kolom    ║ Tipe Data        ║ NULL ║ Key  ║Default ║ Deskripsi Bisnis & Aturan                 ║
╠═══════════════╬══════════════════╬══════╬══════╬════════╬═══════════════════════════════════════════╣
║ id_pinjam     ║ INT UNSIGNED     ║ NO   ║ PK   ║ AUTO   ║ Nomor identifikasi unik setiap transaksi  ║
║               ║ AUTO_INCREMENT   ║      ║      ║        ║ peminjaman. Surrogate key yang dibuat     ║
║               ║                  ║      ║      ║        ║ sistem secara otomatis.                   ║
╠═══════════════╬══════════════════╬══════╬══════╬════════╬═══════════════════════════════════════════╣
║ id_anggota    ║ INT UNSIGNED     ║ NO   ║ FK   ║ –      ║ Referensi ke anggota yang meminjam.       ║
║               ║                  ║      ║      ║        ║ Wajib diisi (total participation).        ║
║               ║                  ║      ║      ║        ║ ON DELETE RESTRICT: Anggota tidak bisa    ║
║               ║                  ║      ║      ║        ║ dihapus jika masih punya riwayat pinjam.  ║
╠═══════════════╬══════════════════╬══════╬══════╬════════╬═══════════════════════════════════════════╣
║ id_buku       ║ INT UNSIGNED     ║ NO   ║ FK   ║ –      ║ Referensi ke buku yang dipinjam.          ║
║               ║                  ║      ║      ║        ║ ON DELETE RESTRICT: Buku tidak bisa       ║
║               ║                  ║      ║      ║        ║ dihapus jika masih punya riwayat pinjam.  ║
╠═══════════════╬══════════════════╬══════╬══════╬════════╬═══════════════════════════════════════════╣
║ tgl_pinjam    ║ DATE             ║ NO   ║ –    ║CURRENT ║ Tanggal buku dipinjam. Default ke         ║
║               ║                  ║      ║      ║_DATE   ║ tanggal hari ini jika tidak diisi.        ║
║               ║                  ║      ║      ║        ║ Tidak bisa diubah setelah buku dipinjam.  ║
╠═══════════════╬══════════════════╬══════╬══════╬════════╬═══════════════════════════════════════════╣
║ tgl_rencana   ║ DATE             ║ NO   ║ –    ║ –      ║ Tanggal yang dijadwalkan untuk             ║
║ _kembali      ║                  ║      ║      ║        ║ pengembalian. Dihitung otomatis:           ║
║               ║                  ║      ║      ║        ║ tgl_pinjam + masa_pinjam (dari tabel       ║
║               ║                  ║      ║      ║        ║ JENIS_ANGGOTA). Harus > tgl_pinjam.       ║
╠═══════════════╬══════════════════╬══════╬══════╬════════╬═══════════════════════════════════════════╣
║ tgl_kembali   ║ DATE             ║ YES  ║ –    ║ NULL   ║ Tanggal aktual buku dikembalikan.         ║
║ _aktual       ║                  ║      ║      ║        ║ NULL berarti buku BELUM dikembalikan.     ║
║               ║                  ║      ║      ║        ║ Hanya diisi saat buku dikembalikan.       ║
║               ║                  ║      ║      ║        ║ Nilai valid: >= tgl_pinjam.               ║
╠═══════════════╬══════════════════╬══════╬══════╬════════╬═══════════════════════════════════════════╣
║ denda         ║ DECIMAL(10,2)    ║ NO   ║ –    ║ 0.00   ║ Total denda keterlambatan dalam Rupiah.   ║
║               ║                  ║      ║      ║        ║ Dihitung: (tgl_kembali_aktual –           ║
║               ║                  ║      ║      ║        ║ tgl_rencana_kembali) × Rp500.             ║
║               ║                  ║      ║      ║        ║ Harus >= 0. Default 0 jika tidak          ║
║               ║                  ║      ║      ║        ║ terlambat.                                ║
╠═══════════════╬══════════════════╬══════╬══════╬════════╬═══════════════════════════════════════════╣
║ status        ║ ENUM             ║ NO   ║ –    ║'dipinjam║ Status terkini transaksi peminjaman.     ║
║               ║ ('dipinjam',     ║      ║      ║'       ║ dipinjam    : buku sedang di tangan      ║
║               ║ 'dikembalikan',  ║      ║      ║        ║              anggota                     ║
║               ║ 'terlambat')     ║      ║      ║        ║ dikembalikan: sudah kembali tepat waktu  ║
║               ║                  ║      ║      ║        ║ terlambat   : sudah kembali tapi          ║
║               ║                  ║      ║      ║        ║              melewati tenggat, atau       ║
║               ║                  ║      ║      ║        ║              belum kembali & sudah lewat  ║
╚═══════════════╩══════════════════╩══════╩══════╩════════╩═══════════════════════════════════════════╝

-- Melihat semua tabel dalam database tertentu
SELECT TABLE_NAME, TABLE_ROWS, TABLE_COMMENT, CREATE_TIME, UPDATE_TIME
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'perpustakaan'
ORDER BY TABLE_NAME;
 
-- Melihat detail kolom dari tabel tertentu
SELECT
    COLUMN_NAME,
    COLUMN_TYPE,
    IS_NULLABLE,
    COLUMN_KEY,
    COLUMN_DEFAULT,
    EXTRA,
    COLUMN_COMMENT
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'perpustakaan'
  AND TABLE_NAME   = 'peminjaman'
ORDER BY ORDINAL_POSITION;
 
-- Melihat semua constraint (FK) dalam database
SELECT
    CONSTRAINT_NAME,
    TABLE_NAME,
    COLUMN_NAME,
    REFERENCED_TABLE_NAME,
    REFERENCED_COLUMN_NAME
FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA = 'perpustakaan'
  AND REFERENCED_TABLE_NAME IS NOT NULL
ORDER BY TABLE_NAME;
 
-- Melihat semua index dalam database
SELECT
    TABLE_NAME,
    INDEX_NAME,
    COLUMN_NAME,
    NON_UNIQUE,
    INDEX_TYPE
FROM INFORMATION_SCHEMA.STATISTICS
WHERE TABLE_SCHEMA = 'perpustakaan'
ORDER BY TABLE_NAME, INDEX_NAME;

DATA GOVERNANCE adalah sistem kerangka kerja yang mendefinisikan:
  SIAPA  yang berhak membuat keputusan tentang data
  APA    keputusan yang perlu dibuat
  BAGAIMANA keputusan tersebut dibuat dan dieksekusi

Governance bukan hanya soal teknologi — ini tentang:
  → Orang: Roles, tanggung jawab, akuntabilitas
  → Proses: Kebijakan, prosedur, standar
  → Teknologi: Tools untuk penegakan kebijakan

TANPA DATA GOVERNANCE:
  → Setiap developer mendefinisikan kolom "status" berbeda
  → Tidak ada yang tahu apakah data pelanggan boleh dilihat tim marketing
  → Data breach terjadi tanpa ada yang bertanggung jawab
  → Regulasi dilanggar tanpa disadari

DENGAN DATA GOVERNANCE:
  → Standar yang jelas: format, naming, tipe data
  → Jalur persetujuan jelas saat ada perubahan skema
  → Kontrol akses terstruktur: siapa boleh baca/ubah/hapus
  → Kepatuhan regulasi terjamin secara sistemik

1. DATA OWNER (Pemilik Data)
   → Pejabat senior yang secara bisnis bertanggung jawab
     atas data dalam domain tertentu
   → Membuat keputusan strategis: kebijakan retensi,
     siapa yang boleh akses, kapan data bisa dihapus
   → Contoh: Direktur Keuangan = data owner untuk data keuangan
   
2. DATA STEWARD (Pengelola Data)
   → Bertanggung jawab atas kualitas dan integritas data
     sehari-hari (lebih operasional dari Data Owner)
   → Tugas: memperbarui data dictionary, memantau DQ,
     menyelesaikan masalah kualitas data
   → Contoh: Kepala Divisi IT atau Data Analyst senior

3. DATA CUSTODIAN (Penjaga Data)
   → Bertanggung jawab atas infrastruktur penyimpanan dan keamanan data
   → Tugas: backup, recovery, access control, enkripsi
   → Contoh: Database Administrator (DBA)

4. DATA CONSUMER (Pengguna Data)
   → Menggunakan data untuk kebutuhan bisnis atau analisis
   → Wajib menggunakan data sesuai kebijakan yang ditetapkan
   → Contoh: Data Scientist, Business Analyst, Manajer

HUBUNGAN ANTAR PERAN:
  Data Owner → menetapkan kebijakan
       ↓
  Data Steward → memastikan kebijakan dijalankan, menjaga kualitas
       ↓
  Data Custodian → mengimplementasikan keamanan teknis
       ↓
  Data Consumer → menggunakan data sesuai kebijakan

1. KEBIJAKAN AKSES DATA (Data Access Policy)
   → Siapa boleh baca, siapa boleh ubah, siapa boleh hapus?
   → Prinsip Least Privilege: berikan akses minimum yang diperlukan
   
   Implementasi di MySQL:
   -- Buat user dengan akses terbatas
   CREATE USER 'analyst_team'@'%' IDENTIFIED BY 'password';
   GRANT SELECT ON perpustakaan.* TO 'analyst_team'@'%';
   -- Analyst hanya bisa SELECT, tidak bisa INSERT/UPDATE/DELETE
   
   CREATE USER 'app_backend'@'localhost' IDENTIFIED BY 'password';
   GRANT SELECT, INSERT, UPDATE ON perpustakaan.* TO 'app_backend'@'localhost';
   REVOKE DELETE ON perpustakaan.* FROM 'app_backend'@'localhost';
   -- Aplikasi backend bisa baca/tulis tapi tidak bisa hapus

2. KEBIJAKAN RETENSI DATA (Data Retention Policy)
   → Berapa lama data disimpan? Kapan data bisa/harus dihapus?
   
   Contoh kebijakan umum:
   → Data transaksi    : Disimpan 10 tahun (untuk audit perpajakan)
   → Log aplikasi      : Disimpan 90 hari (kemudian dihapus otomatis)
   → Data pelanggan    : Disimpan selama pelanggan aktif + 2 tahun
   → Data anak di bawah umur: Khusus — lihat UU Perlindungan Anak
   
   Implementasi: Scheduled job/cron yang menghapus atau mengarsip
   data sesuai kebijakan.

3. KEBIJAKAN PERUBAHAN SKEMA (Schema Change Policy)
   → Perubahan struktur tabel (ALTER TABLE) harus melalui:
     a. Review dan persetujuan (code review atau DBA review)
     b. Diuji di environment development/staging
     c. Memperbarui data dictionary setelah perubahan
     d. Komunikasi ke semua stakeholder yang terdampak
   → Jangan pernah langsung ALTER TABLE di production
     tanpa proses review!

4. KEBIJAKAN BACKUP DAN RECOVERY
   → Full backup: berapa kali? Disimpan di mana? Berapa lama?
   → Point-in-time recovery: bisa recovery ke titik waktu tertentu?
   → Recovery Time Objective (RTO): berapa lama boleh downtime?
   → Recovery Point Objective (RPO): berapa lama data boleh hilang?

DATA GOVERNANCE DI INDONESIA — KERANGKA REGULASI

1. UU NO. 27 TAHUN 2022 — PERLINDUNGAN DATA PRIBADI (PDP)
   Berlaku efektif Oktober 2024.
   
   Yang harus diperhatikan:
   → Data pribadi: nama, alamat, email, no. KTP, no. HP, tgl_lahir, dll.
   → Harus ada dasar hukum untuk memproses data pribadi
     (persetujuan, kepentingan sah, kontrak, dll.)
   → Hak subjek data: hak akses, koreksi, hapus, portabilitas
   → Wajib melindungi data dengan langkah teknis dan organisasional
   → Wajib melapor jika terjadi kebocoran data dalam 14 hari
   
   Dampak pada desain database:
   → Enkripsi untuk data sensitif (tgl_lahir, no_KTP, dll.)
   → Kemampuan untuk "melupakan" (delete) data pengguna jika diminta
   → Audit trail: log siapa mengakses data pribadi siapa
   → Anonimisasi untuk keperluan analisis (tidak perlu identitas asli)

2. UU ITE (UU NO. 11/2008 diubah UU NO. 19/2016)
   → Mengatur penggunaan data elektronik
   → Larang akses tanpa izin ke sistem elektronik
   → Relevan untuk desain sistem autentikasi dan otorisasi

3. STANDAR ISO 27001 — INFORMATION SECURITY MANAGEMENT
   Internasional, banyak perusahaan Indonesia mengadopsi:
   → Manajemen risiko keamanan informasi
   → Kontrol akses, enkripsi, audit
   → Relevan untuk organisasi yang menangani data sensitif dalam volume besar

IMPLIKASI PRAKTIS UNTUK DATA MODELLING:
  ✓ Identifikasi kolom yang berisi data pribadi di data dictionary
  ✓ Pertimbangkan enkripsi untuk kolom sensitif (no_KTP, password)
  ✓ Desain mekanisme untuk soft-delete (jangan hapus permanent, tapi
    tandai is_deleted = 1 untuk audit trail)
  ✓ Rencanakan anonimisasi: hapus nama/email tapi simpan data transaksinya
  ✓ Dokumentasikan tujuan pengumpulan setiap data pribadi di data dictionary

"GARBAGE IN, GARBAGE OUT"
  Jika data yang masuk ke model ML atau analisis statistik berkualitas
  buruk, maka output yang dihasilkan pun tidak dapat dipercaya —
  tidak peduli seberapa canggih algoritmanya.

ESTIMASI INDUSTRI:
  → Data scientist menghabiskan 60–80% waktu mereka
    untuk data cleaning dan preparation
  → Bukan karena mereka suka — tapi karena kualitas data
    yang sampai ke tangan mereka seringkali buruk
  → Inilah mengapa data modelling yang baik DAN data governance
    yang kuat sangat berharga: mencegah masalah di hulu
    jauh lebih murah daripada membersihkan di hilir

ACCURACY → Model yang Menyesatkan
  Contoh kasus:
  Sebuah startup fintech menggunakan model ML untuk
  prediksi risiko kredit. Kolom "penghasilan" ternyata
  ada yang diisi dalam satuan juta (5 = Rp5.000.000)
  dan ada yang diisi dalam satuan rupiah (5000000).
  
  Akibat: Model "belajar" dari data yang campur aduk →
  prediksi risiko kredit keliru → bank memberi pinjaman
  ke profil yang salah → kerugian finansial nyata.

COMPLETENESS → Bias dalam Analisis
  Contoh kasus:
  Riset kepuasan pelanggan: 30% data "rating" bernilai NULL
  (responden tidak menjawab). Jika NULL diabaikan (di-drop),
  analisis hanya mencakup 70% yang menjawab.
  
  Masalah: Pelanggan yang tidak puas cenderung tidak mau
  mengisi rating → NULL bukan random, ada polanya (selection bias).
  Analisis "rata-rata rating" yang mengabaikan NULL
  secara sistematis lebih tinggi dari kenyataannya.

CONSISTENCY → Segmentasi yang Salah
  Contoh kasus:
  Analisis segmentasi pelanggan berdasarkan kota.
  Kolom kota_asal berisi: "Jakarta", "jakarta", "JAKARTA",
  "Dki Jakarta", "DKI Jakarta", "Kota Jakarta".
  
  Akibat: Setiap variasi dianggap sebagai kota berbeda →
  segmen "Jakarta" tampak kecil → rekomendasi bisnis keliru
  (misalnya: tidak buka cabang baru di Jakarta karena
  terlihat sedikit pelanggan).

TIMELINESS → Rekomendasi yang Usang
  Contoh kasus:
  Sistem rekomendasi produk menggunakan riwayat pembelian
  pelanggan. Data tidak diperbarui secara real-time.
  
  Akibat: Sistem merekomendasikan produk yang sudah
  dibeli kemarin, atau promosi yang sudah berakhir minggu lalu.
  Pengalaman pengguna buruk.

VALIDITY → False Patterns
  Contoh kasus:
  Dataset transaksi berisi tanggal "2099-12-31" untuk
  transaksi yang gagal diproses sistem (default error date).
  
  Akibat: Analisis tren transaksi per tahun menunjukkan
  "lonjakan transaksi di tahun 2099" → anomali yang membingungkan.
  Jika tidak dideteksi, bisa mengacaukan model forecasting.

UNIQUENESS → Hitung yang Salah
  Contoh kasus:
  Laporan "jumlah pelanggan unik" untuk meeting direksi:
  laporan menunjukkan 50.000 pelanggan. Padahal setelah
  deduplication ditemukan hanya 35.000 pelanggan unik
  (15.000 adalah duplikat dari berbagai sumber).
  
  Akibat: Seluruh strategi ekspansi berbasis data yang salah.
  Target "1 juta pelanggan" sebenarnya baru 70% tercapai,
  bukan 100%.

-- ============================================================
-- TOOLKIT DATA QUALITY ASSESSMENT
-- ============================================================
 
-- 1. CEK COMPLETENESS — Hitung persentase NULL per kolom
SELECT
    'nama'    AS kolom,
    COUNT(*)  AS total,
    SUM(CASE WHEN nama IS NULL OR nama = '' THEN 1 ELSE 0 END) AS nilai_kosong,
    ROUND(100.0 * SUM(CASE WHEN nama IS NULL OR nama = '' THEN 1 ELSE 0 END)
          / COUNT(*), 2) AS persen_kosong
FROM pelanggan
UNION ALL
SELECT 'email', COUNT(*),
    SUM(CASE WHEN email IS NULL OR email = '' THEN 1 ELSE 0 END),
    ROUND(100.0 * SUM(CASE WHEN email IS NULL OR email = '' THEN 1 ELSE 0 END)
          / COUNT(*), 2)
FROM pelanggan
UNION ALL
SELECT 'no_telp', COUNT(*),
    SUM(CASE WHEN no_telp IS NULL THEN 1 ELSE 0 END),
    ROUND(100.0 * SUM(CASE WHEN no_telp IS NULL THEN 1 ELSE 0 END)
          / COUNT(*), 2)
FROM pelanggan;
 
-- 2. CATUR VALIDITY — Cari email yang tidak mengandung '@'
SELECT id_pelanggan, nama, email
FROM pelanggan
WHERE email NOT LIKE '%@%'
   OR email NOT LIKE '%.%';
 
-- 3. CEK VALIDITY — Tanggal di masa depan
SELECT id_pelanggan, nama, tgl_lahir
FROM pelanggan
WHERE tgl_lahir > CURRENT_DATE
   OR tgl_lahir < '1900-01-01';  -- juga cek yang tidak masuk akal
 
-- 4. CEK UNIQUENESS — Temukan baris duplikat
SELECT nama, email, tgl_lahir, COUNT(*) AS jumlah_duplikat
FROM pelanggan
GROUP BY nama, email, tgl_lahir
HAVING COUNT(*) > 1
ORDER BY jumlah_duplikat DESC;
 
-- 5. CEK CONSISTENCY — Deteksi variasi format no_telp
SELECT no_telp, COUNT(*) AS jumlah
FROM pelanggan
WHERE no_telp IS NOT NULL
GROUP BY
    CASE
        WHEN no_telp LIKE '08%'     THEN '08... (format lokal)'
        WHEN no_telp LIKE '+62%'    THEN '+62... (format internasional)'
        WHEN no_telp LIKE '62%'     THEN '62... (tanpa +)'
        WHEN no_telp REGEXP '^[0-9-() ]+$' THEN 'Format campuran angka'
        ELSE 'Format tidak dikenal'
    END
ORDER BY jumlah DESC;
 
-- 6. PROFILING CEPAT — Nilai unik dan distribusi (contoh: status pesanan)
SELECT status, COUNT(*) AS jumlah,
    ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER(), 2) AS persentase
FROM pesanan
GROUP BY status
ORDER BY jumlah DESC;
 
-- 7. CEK DATA YANG "MENCURIGAKAN" (test data masuk production)
SELECT id_pelanggan, nama, email
FROM pelanggan
WHERE LOWER(nama) IN ('test', 'aaa', 'xxx', 'demo', 'admin', 'user')
   OR LOWER(email) LIKE '%test%'
   OR LOWER(email) LIKE '%demo%';
 
-- 8. CEK TIMELINESS — Baris yang belum diperbarui dalam 1 tahun
SELECT id_pelanggan, nama, updated_at,
    DATEDIFF(CURRENT_DATE, updated_at) AS hari_sejak_update
FROM pelanggan
WHERE updated_at < DATE_SUB(CURRENT_DATE, INTERVAL 1 YEAR)
ORDER BY updated_at ASC;

┌───────────┬──────────────────────────┬───────────┬──────┬────────────┬────────────────┐
│ id_produk │ nama_produk              │ harga     │ stok │ id_kategori│ status         │
├───────────┼──────────────────────────┼───────────┼──────┼────────────┼────────────────┤
│ 1         │ Laptop ASUS VivoBook 14  │ 7500000   │ 15   │ 1          │ aktif          │
│ 2         │ laptop asus              │ 7500000   │ 15   │ 1          │ aktif          │ ← ?
│ 3         │ Mouse Wireless Logitech  │ 0         │ 8    │ 2          │ aktif          │ ← ?
│ 4         │ Keyboard Mechanical      │ 350000    │ -3   │ 2          │ aktif          │ ← ?
│ 5         │ Monitor LG 24"           │ NULL      │ 5    │ 2          │ AKTIF          │ ← ?
│ 6         │ SSD Kingston 1TB         │ 850000    │ 20   │ 99         │ aktif          │ ← ?
│ 7         │ Headphone Sony           │ 450000    │ 0    │ 3          │ nonaktif       │
│ 8         │ webcam hd 1080p logitech │ 45.0000   │ 12   │ 3          │ aktif          │ ← ?
│ 9         │ RAM Corsair 16GB DDR4    │ 650000    │ 7    │ 2          │ aktif          │
│ 10        │ test produk              │ 1         │ 0    │ 1          │ aktif          │ ← ?
└───────────┴──────────────────────────┴───────────┴──────┴────────────┴────────────────┘

════════════════════════════════════════════════════════════════════
DATA DICTIONARY — [NAMA SISTEM / DATABASE]
Versi: [X.Y] | Terakhir Diperbarui: [YYYY-MM-DD]
Disusun oleh: [Nama] | Direview oleh: [Nama Data Steward]
════════════════════════════════════════════════════════════════════

────────────────────────────────────────────────────────────────────
TABEL: [nama_tabel]
────────────────────────────────────────────────────────────────────
Nama Tabel        : [nama_tabel]
Skema/Database    : [nama_database]
Deskripsi Bisnis  : [Jelaskan fungsi bisnis tabel ini dalam 2–4
                     kalimat. Hindari jargon teknis. Tulis seolah
                     menjelaskan kepada manajer non-teknis.]
Data Owner        : [Jabatan/divisi yang secara bisnis
                     bertanggung jawab atas data ini]
Data Steward      : [Nama/jabatan pengelola data sehari-hari]
Frekuensi Update  : [Real-time / Harian / Mingguan / Bulanan /
                     Hanya saat event tertentu]
Retensi Data      : [Berapa lama data disimpan? Kapan diarsip/hapus?]
Estimasi Volume   : [Perkiraan jumlah baris dan pertumbuhan per bulan]
Sumber Data       : [Dari mana data ini berasal: form web, API,
                     migrasi, integrasi sistem lain, dll.]
Tabel Berelasi    : [Daftar tabel yang memiliki FK ke/dari tabel ini]

Business Rules    :
  BR-001: [Aturan bisnis pertama — tulis dengan jelas]
  BR-002: [Aturan bisnis kedua]
  BR-003: [Aturan bisnis ketiga]
  [Tambah sesuai kebutuhan]

────────────────────────────────────────────────────────────────────
KOLOM-KOLOM:
────────────────────────────────────────────────────────────────────

Nama Kolom        : [nama_kolom]
Tipe Data         : [INT UNSIGNED / VARCHAR(n) / DECIMAL(p,s) / dll.]
Nullable          : [YES / NO]
Key Type          : [PK / FK / UNIQUE / — (bukan key)]
Nilai Default     : [Nilai default, atau AUTO_INCREMENT, atau —]
Deskripsi Bisnis  : [Penjelasan 2–4 kalimat tentang makna bisnis
                     kolom ini. Apa artinya? Bagaimana digunakan?
                     Siapa yang mengisinya?]
Nilai Valid       : [Untuk ENUM: daftar nilai dan artinya.
                     Untuk numerik: range yang valid.
                     Untuk teks: format yang diharapkan.]
Aturan Bisnis     : [Business rule spesifik untuk kolom ini
                     yang belum tertangkap oleh definisi di atas]
Catatan           : [Informasi tambahan: semantik NULL, riwayat
                     perubahan nama, hubungan dengan kolom lain, dll.]

[Ulangi blok di atas untuk setiap kolom]

────────────────────────────────────────────────────────────────────
RIWAYAT PERUBAHAN:
────────────────────────────────────────────────────────────────────
Tanggal     | Versi | Perubahan                  | Oleh
────────────┼───────┼────────────────────────────┼──────────────
[YYYY-MM-DD]| 1.0   | Versi awal                 | [Nama]
[YYYY-MM-DD]| 1.1   | Tambah kolom [nama]        | [Nama]
[YYYY-MM-DD]| 1.2   | Ubah tipe [kolom] → [tipe] | [Nama]
════════════════════════════════════════════════════════════════════

CHECKLIST PENILAIAN KUALITAS DATA
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[ACCURACY]
□ Tidak ada nilai yang secara logis tidak mungkin (mis. tgl_lahir di masa depan)
□ Tidak ada nilai yang secara statistik merupakan outlier ekstrem
□ Data yang berasal dari input manual telah diverifikasi/validated
□ Ada mekanisme audit trail untuk mendeteksi perubahan yang tidak sah

[COMPLETENESS]
□ Kolom NOT NULL tidak punya nilai kosong ("") yang lolos constraint
□ Persentase NULL pada setiap kolom telah dievaluasi dan dalam batas wajar
□ Tidak ada record yang missing kolom yang secara bisnis wajib diisi
□ Dokumentasi ada untuk setiap kolom nullable: apa arti NULL di sini?

[CONSISTENCY]
□ Format data seragam dalam satu kolom (no_telp, nama, kode, dll.)
□ Nilai yang sama tidak dinyatakan berbeda di tabel berbeda
□ Tidak ada konflik antar kolom dalam satu baris (mis. tgl_mulai > tgl_selesai)
□ Tabel referensi (master data) ada untuk menstandarkan nilai yang berulang

[TIMELINESS]
□ Semua tabel punya audit columns: created_at dan updated_at
□ Frekuensi update data sesuai dengan kebutuhan bisnis
□ Ada proses untuk menandai atau menonaktifkan data yang sudah kadaluarsa
□ SLA refresh data terdokumentasi dan dipatuhi

[VALIDITY]
□ Semua kolom dengan nilai terbatas menggunakan ENUM atau FK ke tabel referensi
□ CHECK constraint ada untuk kolom numerik yang punya range logis
□ Validasi format (email, nomor telepon, kode pos) ada di lapisan aplikasi
□ Data uji coba (test data) tidak ada di environment production

[UNIQUENESS]
□ Kolom bisnis yang harus unik punya UNIQUE constraint
□ Tidak ada duplikasi baris yang terdeteksi (cek dengan GROUP BY + HAVING)
□ Mekanisme idempotency ada untuk mencegah double-insert dari sistem
□ Strategi deduplication ada untuk data yang masuk dari multiple sumber

[GOVERNANCE]
□ Setiap tabel punya Data Owner yang jelas
□ Data dictionary tersedia dan up-to-date
□ Kolom yang berisi data pribadi (PII) telah diidentifikasi
□ Kebijakan akses (siapa boleh baca/tulis/hapus) terdokumentasi
□ Kebijakan retensi data ada dan diimplementasikan
□ Mekanisme audit trail ada untuk data sensitif

-- ============================================================
-- TEMPLATE QUERY DATA QUALITY ASSESSMENT
-- Ganti nama database dan tabel sesuai kebutuhan
-- ============================================================
 
-- 1. RINGKASAN TABEL: Jumlah baris dan tanggal update
SELECT
    TABLE_NAME,
    TABLE_ROWS AS estimasi_baris,
    CREATE_TIME,
    UPDATE_TIME,
    TABLE_COMMENT
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'nama_database'
ORDER BY TABLE_ROWS DESC;
 
-- 2. COMPLETENESS REPORT: % NULL per kolom (sesuaikan nama tabel & kolom)
SELECT
    kolom,
    total_baris,
    jumlah_null,
    ROUND(100.0 * jumlah_null / total_baris, 2) AS persen_null,
    CASE
        WHEN ROUND(100.0 * jumlah_null / total_baris, 2) = 0    THEN '✓ Sempurna'
        WHEN ROUND(100.0 * jumlah_null / total_baris, 2) <= 5   THEN '⚠ Perlu perhatian'
        WHEN ROUND(100.0 * jumlah_null / total_baris, 2) <= 20  THEN '⚠⚠ Bermasalah'
        ELSE '✗ Kritis'
    END AS status
FROM (
    SELECT 'nama' AS kolom, COUNT(*) AS total_baris,
           SUM(CASE WHEN nama IS NULL OR nama = '' THEN 1 ELSE 0 END) AS jumlah_null
    FROM pelanggan
    UNION ALL
    SELECT 'email', COUNT(*),
           SUM(CASE WHEN email IS NULL OR email = '' THEN 1 ELSE 0 END)
    FROM pelanggan
    UNION ALL
    SELECT 'no_telp', COUNT(*),
           SUM(CASE WHEN no_telp IS NULL THEN 1 ELSE 0 END)
    FROM pelanggan
) AS completeness_check
ORDER BY persen_null DESC;
 
-- 3. UNIQUENESS CHECK: Deteksi kemungkinan duplikat pelanggan
SELECT
    SOUNDEX(nama) AS nama_soundex,  -- Soundex: nama mirip meski beda ejaan
    COUNT(DISTINCT email) AS variasi_email,
    COUNT(*) AS jumlah_kemungkinan_duplikat,
    GROUP_CONCAT(email SEPARATOR ' | ') AS daftar_email
FROM pelanggan
GROUP BY SOUNDEX(nama)
HAVING COUNT(*) > 1 AND COUNT(DISTINCT email) > 1
ORDER BY jumlah_kemungkinan_duplikat DESC;
 
-- 4. VALIDITY CHECK: Data yang tidak sesuai rule bisnis
SELECT 'email_invalid' AS jenis_masalah, COUNT(*) AS jumlah
FROM pelanggan WHERE email NOT REGEXP '^[A-Za-z0-9._%+\-]+@[A-Za-z0-9.\-]+\.[A-Za-z]{2,}$'
UNION ALL
SELECT 'tgl_lahir_masa_depan', COUNT(*)
FROM pelanggan WHERE tgl_lahir > CURRENT_DATE
UNION ALL
SELECT 'tgl_lahir_terlalu_tua', COUNT(*)
FROM pelanggan WHERE tgl_lahir < '1900-01-01'
UNION ALL
SELECT 'nama_terlalu_pendek', COUNT(*)
FROM pelanggan WHERE LENGTH(TRIM(nama)) < 2;
 
-- 5. DATA PROFILING: Distribusi nilai untuk kolom kategorik
SELECT
    status,
    COUNT(*) AS jumlah,
    ROUND(100.0 * COUNT(*) / SUM(COUNT(*)) OVER (), 2) AS persen,
    REPEAT('█', ROUND(COUNT(*) * 30 / MAX(COUNT(*)) OVER (), 0)) AS bar_chart
FROM pesanan
GROUP BY status
ORDER BY jumlah DESC;

LEMBAR KERJA — LATIHAN DATA QUALITY ASSESSMENT
Nama  : ___________________________ NIM : _______________
Tanggal: ___________________

DATASET: Tabel produk (lihat Soal D.1)

TABEL IDENTIFIKASI MASALAH:
┌────────┬────────────────────────┬──────────────┬────────────────────────┬────────────────────────────┐
│ id_prod│ Masalah yang Ditemukan │ Dimensi DQ   │ Dampak jika Dibiarkan  │ Saran Perbaikan            │
├────────┼────────────────────────┼──────────────┼────────────────────────┼────────────────────────────┤
│   2    │                        │              │                        │                            │
│   3    │                        │              │                        │                            │
│   4    │                        │              │                        │                            │
│   5    │                        │              │                        │                            │
│   6    │                        │              │                        │                            │
│   8    │                        │              │                        │                            │
│  10    │                        │              │                        │                            │
└────────┴────────────────────────┴──────────────┴────────────────────────┴────────────────────────────┘

PERTANYAAN ANALISIS:

1. Masalah mana yang bisa dicegah dengan constraint DDL?
   [Jawaban:]

2. Constraint DDL apa yang spesifik mencegah masing-masing masalah di atas?
   Masalah: ___________ → Constraint: ___________
   Masalah: ___________ → Constraint: ___________
   Masalah: ___________ → Constraint: ___________

3. Masalah mana yang TIDAK bisa dicegah dengan constraint DDL saja?
   [Jawaban:]

4. Untuk masalah di nomor 3, di lapisan mana seharusnya ditangani?
   □ Application layer (validasi form/API)
   □ ETL/Ingestion pipeline
   □ Proses manual/SOP
   □ Data governance policy
   
   Jelaskan: [Jawaban:]