Normalisasi Database

Panduan Lengkap Normalisasi Database: Studi Kasus Industri Perbankan

Database yang dirancang dengan baik adalah fondasi dari aplikasi yang andal dan scalable. Salah satu pilar utama dari desain database yang baik adalah normalisasi. Proses ini sering dianggap rumit, tetapi pada intinya, ini adalah cara logis untuk menata data demi efisiensi dan integritas. Secara sederhana, normalisasi adalah proses mengorganisir kolom (atribut) dan tabel (relasi) dalam sebuah database untuk meminimalkan redundansi data (pengulangan data) dan meningkatkan integritas data. Tujuannya adalah untuk memastikan bahwa data disimpan secara logis dan efisien.

Dasar-Dasar Sebelum Memulai

Sebelum masuk ke tahap normalisasi, mari kita pahami beberapa istilah kunci yang akan sering kita gunakan.

  • Cell: Ini adalah istilah untuk perpotongan antara satu baris (row) dan satu kolom (column). Setiap cell idealnya hanya menyimpan satu nilai data.

  • Keys in a Database:

    • Primary Key (PK): Sebuah kolom (atau beberapa kolom) yang secara unik mengidentifikasi setiap baris dalam sebuah tabel. Nilainya tidak boleh NULL dan harus unik.

    • Composite Primary Key: Sebuah Primary Key yang terdiri dari dua atau lebih kolom yang digabungkan untuk menciptakan sebuah nilai unik.

    • Foreign Key (FK): Sebuah kolom dalam satu tabel yang merujuk ke Primary Key di tabel lain, menciptakan hubungan antar tabel.

  • Functional Dependency (Ketergantungan Fungsional): Sebuah atribut B memiliki ketergantungan fungsional pada atribut A (ditulis A → B) jika setiap nilai A secara unik menentukan nilai B. Contoh: CustomerID → CustomerName. Jika kita tahu CustomerID, kita pasti tahu CustomerName-nya.

  • Partial Dependency (Ketergantungan Parsial): Masalah ini hanya muncul pada tabel dengan Composite Primary Key. Terjadi ketika sebuah atribut non-kunci hanya bergantung pada sebagian dari Composite Primary Key, bukan keseluruhannya.

  • Transitive Dependency (Ketergantungan Transitif): Terjadi ketika sebuah atribut non-kunci bergantung pada atribut non-kunci lainnya, bukan pada Primary Key secara langsung. Rantainya seperti ini: Primary Key → Atribut Non-Kunci 1 → Atribut Non-Kunci 2.

Tanpa menata dependensi ini, kita akan menghadapi anomali data:

  • Insertion Anomaly: Sulit memasukkan data baru jika bagian lain dari data belum lengkap.

  • Update Anomaly: Harus mengubah data yang sama di banyak baris, berisiko terjadi inkonsistensi.

  • Deletion Anomaly: Kehilangan data penting secara tidak sengaja saat menghapus baris lain.

Studi Kasus: Database Nasabah & Rekening Bank

Bayangkan sebuah bank pada awalnya mencatat semua data nasabah, rekening, dan cabang dalam satu spreadsheet atau tabel besar.

Tabel Awal (Unnormalized Form / UNF)

+------------+-----------------+---------------------+-------------+---------------+-------------+-------------+---------------+---------------+----------+---------------+--------------+
| CustomerID | CustomerName    | CustomerAddress     | AccountNo1  | AccountType1  | Balance1    | AccountNo2  | AccountType2  | Balance2      | BranchID | BranchName    | BranchCity   |
+------------+-----------------+---------------------+-------------+---------------+-------------+-------------+---------------+---------------+----------+---------------+--------------+
| C001       | David Beckham   | 123 Manchester Rd   | ACC101      | Savings       | 5000.00     | ACC102      | Checking      | 1200.00     | B01      | Main St. Bank | London       |
| C002       | Zinedine Zidane | 456 Madrid Ave      | ACC201      | Savings       | 15000.00    | NULL        | NULL          | NULL        | B02      | City Center   | Manchester   |
| C003       | Paolo Maldini   | 789 Milan Square    | ACC301      | Checking      | 7500.00     | NULL        | NULL          | NULL        | B01      | Main St. Bank | London       |
+------------+-----------------+---------------------+-------------+---------------+-------------+-------------+---------------+-------------+----------+---------------+--------------+

Tabel ini jelas bermasalah. Ada kolom NULL, dan jika David Beckham membuka rekening ketiga, kita harus mengubah struktur tabel. Mari kita perbaiki.

Tahap 1: First Normal Form (1NF)

Aturan 1NF: Setiap cell harus berisi nilai tunggal (atomic), dan tidak boleh ada repeating groups (grup kolom yang berulang).

Problem: Grup kolom (AccountNo, AccountType, Balance) berulang.

Solusi: Buat baris baru untuk setiap rekening yang dimiliki nasabah.

Hasil Tabel Setelah 1NF:

+------------+-----------------+---------------------+-----------+---------------+----------+----------+---------------+--------------+
| CustomerID | CustomerName    | CustomerAddress     | AccountNo | AccountType   | Balance  | BranchID | BranchName    | BranchCity   |
+------------+-----------------+---------------------+-----------+---------------+----------+----------+---------------+--------------+
| C001       | David Beckham   | 123 Manchester Rd   | ACC101    | Savings       | 5000.00  | B01      | Main St. Bank | London       |
| C001       | David Beckham   | 123 Manchester Rd   | ACC102    | Checking      | 1200.00  | B01      | Main St. Bank | London       |
| C002       | Zinedine Zidane | 456 Madrid Ave      | ACC201    | Savings       | 15000.00 | B02      | City Center   | Manchester   |
| C003       | Paolo Maldini   | 789 Milan Square    | ACC301    | Checking      | 7500.00  | B01      | Main St. Bank | London       |
+------------+-----------------+---------------------+-----------+---------------+----------+----------+---------------+--------------+

Perbaikan: Tabel sekarang lebih fleksibel.

Masalah Tersisa: Redundansi data merajalela. Informasi nasabah dan cabang diulang-ulang. Jika David Beckham pindah alamat, kita harus mengubahnya di dua baris. Inilah saatnya 2NF.

Untuk melanjutkan, kita tentukan Primary Key. AccountNo unik untuk setiap rekening, jadi kita bisa menggunakannya sebagai Primary Key.

Tahap 2: Second Normal Form (2NF)

Aturan 2NF: Tabel harus sudah dalam 1NF, dan semua atribut non-kunci harus bergantung penuh pada keseluruhan Primary Key.

Aturan 2NF hanya relevan jika kita memiliki Composite Primary Key. Dalam kasus 1NF kita di atas, AccountNo adalah single primary key. Semua atribut lain (CustomerName, BranchName, dll.) bergantung padanya. Jadi, tabel tersebut secara teknis sudah 2NF.

Namun, untuk tujuan pembelajaran, mari kita ubah skenarionya sedikit. Anggap saja Primary Key-nya adalah {CustomerID, AccountNo}. Ini adalah Composite Primary Key. Sekarang, mari kita periksa dependensinya:

  • CustomerName, CustomerAddress → Hanya bergantung pada CustomerID. Ini Partial Dependency.

  • AccountType, Balance, BranchID, BranchName, BranchCity → Hanya bergantung pada AccountNo. Ini juga Partial Dependency.

Solusi: Pecah tabel untuk menghilangkan partial dependencies.

Hasil Tabel Setelah 2NF:

  1. Tabel Customers

    • PK: CustomerID

    +------------+-----------------+---------------------+
| CustomerID | CustomerName    | CustomerAddress     |
+------------+-----------------+---------------------+
| C001       | David Beckham   | 123 Manchester Rd   |
| C002       | Zinedine Zidane | 456 Madrid Ave      |
| C003       | Paolo Maldini   | 789 Milan Square    |
+------------+-----------------+---------------------+

  2. Tabel Accounts

    • PK: AccountNo

    +-----------+---------------+----------+----------+---------------+--------------+
| AccountNo | AccountType   | Balance  | BranchID | BranchName    | BranchCity   |
+-----------+---------------+----------+----------+---------------+--------------+
| ACC101    | Savings       | 5000.00  | B01      | Main St. Bank | London       |
| ACC102    | Checking      | 1200.00  | B01      | Main St. Bank | London       |
| ACC201    | Savings       | 15000.00 | B02      | City Center   | Manchester   |
| ACC301    | Checking      | 7500.00  | B01      | Main St. Bank | London       |
+-----------+---------------+----------+----------+---------------+--------------+

  3. Tabel Customer_Accounts (Tabel Penghubung)

    • PK: {CustomerID, AccountNo}

    +------------+-----------+
| CustomerID | AccountNo |
+------------+-----------+
| C001       | ACC101    |
| C001       | ACC102    |
| C002       | ACC201    |
| C003       | ACC301    |
+------------+-----------+

Perbaikan: Redundansi data nasabah sudah hilang.

Masalah Tersisa: Lihat Tabel Accounts. BranchName dan BranchCity diulang. Kenapa? Karena BranchName bergantung pada BranchID, yang bukan Primary Key. Ini adalah Transitive Dependency.

Tahap 3: Third Normal Form (3NF)

Aturan 3NF: Tabel harus sudah dalam 2NF, dan tidak boleh ada Transitive Dependency.

Problem: Di Tabel Accounts, kita memiliki dependensi AccountNo → BranchID → BranchName. BranchName bergantung pada BranchID (atribut non-kunci).

Solusi: Pindahkan atribut yang bergantung secara transitif ke tabel baru.

Hasil Struktur Final (3NF):

  1. Tabel Customers (Tetap)

  2. Tabel Customer_Accounts (Tetap)

  3. Tabel Branches (Baru)

    • PK: BranchID

    +----------+---------------+--------------+
| BranchID | BranchName    | BranchCity   |
+----------+---------------+--------------+
| B01      | Main St. Bank | London       |
| B02      | City Center   | Manchester   |
+----------+---------------+--------------+

  4. Tabel Accounts (Dimodifikasi)

    • PK: AccountNo

    • FK: BranchID

    +-----------+---------------+----------+----------+
| AccountNo | AccountType   | Balance  | BranchID |
+-----------+---------------+----------+----------+
| ACC101    | Savings       | 5000.00  | B01      |
| ACC102    | Checking      | 1200.00  | B01      |
| ACC201    | Savings       | 15000.00 | B02      |
| ACC301    | Checking      | 7500.00  | B01      |
+-----------+---------------+----------+----------+

Pada titik ini, database kita sudah sangat baik. Redundansi minimal, integritas data terjaga, dan anomali teratasi. Bagi 95% aplikasi, 3NF adalah tujuan akhir.

Bentuk Normal Tingkat Lanjut (Advanced Normal Forms)

Bentuk-bentuk ini mengatasi anomali yang lebih langka dan kompleks.

Boyce-Codd Normal Form (BCNF atau 3.5NF)

Aturan BCNF: Untuk setiap functional dependency A → B yang non-trivial, A harus menjadi Superkey (sebuah set atribut yang mengandung sebuah Candidate Key).

BCNF adalah versi 3NF yang lebih ketat. BCNF mengatasi anomali yang bisa terjadi jika sebuah tabel memiliki beberapa candidate keys yang tumpang tindih.

Studi Kasus: Bayangkan tabel Banker_Client_Product dimana seorang banker hanya menangani satu jenis produk (misalnya, hanya KPR), dan seorang klien untuk produk tertentu hanya dilayani oleh satu banker.

  • {BankerID, ClientID, ProductType}

  • Candidate Keys: {BankerID, ClientID} dan {ClientID, ProductType}.

  • Tabel ini sudah 3NF. Tapi, ada dependensi BankerID → ProductType. BankerID sendiri bukanlah Superkey. Ini melanggar BCNF.

  • Solusi: Dekomposisi menjadi (BankerID, ProductType) dan (BankerID, ClientID).

Fourth Normal Form (4NF)

Aturan 4NF: Tabel harus dalam BCNF dan tidak memiliki Multi-valued Dependency.

Multi-valued dependency terjadi ketika keberadaan satu baris dengan nilai A dan B menyiratkan keberadaan baris lain dengan A dan C, dimana B dan C tidak saling berhubungan.

Studi Kasus: Tabel Branch_Services_Segments. Sebuah cabang bank menawarkan beberapa layanan (Loans, Investments) dan menargetkan beberapa segmen nasabah (Retail, Corporate). Layanan dan Segmen tidak saling bergantung.

  • {BranchID, Service, Segment}

  • B01, Loans, Retail

  • B01, Loans, Corporate ← Redundansi

  • B01, Investments, Retail ← Redundansi

  • B01, Investments, Corporate

  • Ini adalah multi-valued dependency: BranchID →→ Service dan BranchID →→ Segment.

  • Solusi: Dekomposisi menjadi (BranchID, Service) dan (BranchID, Segment).

Fifth Normal Form (5NF)

Aturan 5NF: Tabel harus dalam 4NF dan tidak memiliki Join Dependency.

Ini adalah level tertinggi dan paling abstrak. Tujuannya adalah untuk menghilangkan redundansi dengan memecah tabel sedemikian rupa sehingga ketika digabungkan kembali (join), tidak ada data palsu yang tercipta.

Studi Kasus: Tabel Banker_Skill_Product dengan aturan: Jika seorang banker memiliki skill tertentu, dan skill itu dibutuhkan untuk menjual sebuah produk, maka banker tersebut bisa menjual produk itu.

  • {BankerID, Skill, Product}

  • Jika kita memiliki data: {BankerA, Negotiation, Loans} dan {BankerB, Analysis, Loans}, kita tidak bisa memecahnya begitu saja.

  • 5NF memastikan bahwa jika tabel dipecah menjadi beberapa bagian (misal: (Banker, Skill), (Skill, Product), (Banker, Product)), penggabungan ketiganya akan menghasilkan tabel asli tanpa kehilangan atau menambah informasi.

Kesimpulan: Seberapa Jauh Normalisasi Diperlukan?

Meskipun ada banyak tingkatan, dalam praktik dunia nyata:

  • 3NF adalah Standar Emas: Untuk sebagian besar aplikasi transaksional (OLTP) seperti e-commerce, perbankan, dan sistem pemesanan, mencapai 3NF adalah tujuan yang paling umum dan praktis.

  • BCNF diinginkan: Jika memungkinkan, mencapai BCNF lebih baik, tetapi kasus yang melanggar BCNF namun memenuhi 3NF cukup jarang.

  • 4NF & 5NF bersifat akademis: Bentuk ini sangat penting secara teoretis tetapi jarang menjadi masalah dalam desain database praktis sehari-hari.

Terkadang, untuk aplikasi yang sangat berfokus pada kecepatan baca data (seperti data warehouse untuk analisis), proses denormalisasi (menggabungkan tabel yang sudah ternormalisasi) justru sengaja dilakukan untuk mengurangi jumlah join dan mempercepat query.

Pada akhirnya, normalisasi adalah alat, bukan dogma. Memahaminya secara mendalam memungkinkan Anda merancang database yang tidak hanya benar secara teknis, tetapi juga efisien dan mudah dipelihara.

PreviousDeploy and ReleaseNextOWASP Top Ten

Last updated