Merancang ERD Sederhana untuk Aplikasi

Sebelum menulis satu baris kode pun, aplikasi yang baik dimulai dari perancangan data. ERD (Entity Relationship Diagram) adalah peta yang menggambarkan data apa yang disimpan aplikasi dan bagaimana data-data itu saling terhubung. Artikel ini mengajarkan cara merancang ERD sederhana dari nol, memahami jenis relasi, menerapkan normalisasi dasar, lalu menerjemahkannya menjadi migration Laravel memakai contoh nyata: toko online sederhana.

Mengapa harus repot menggambar ERD dulu? Karena kesalahan struktur database jauh lebih mahal diperbaiki daripada kesalahan kode. Mengubah nama variabel cukup lima menit, tetapi mengubah struktur tabel setelah aplikasi berjalan dengan ribuan baris data bisa berarti migrasi rumit, downtime, dan risiko kehilangan data. ERD memaksa Anda memikirkan bentuk data secara matang sebelum menuangkannya ke kode, sehingga keputusan penting diambil saat biaya perubahan masih murah. Anda bisa menggambar ERD dengan alat seperti dbdiagram.io, draw.io, atau bahkan di atas kertas — yang penting adalah proses berpikirnya.

1. Mengenal Komponen ERD

• Entitas: objek utama yang datanya disimpan, misalnya User, Product, Order. Di database, satu entitas biasanya menjadi satu tabel.
• Atribut: properti dari entitas, misalnya Product punya atribut name, price, stock. Atribut menjadi kolom.
• Primary Key (PK): kolom unik yang mengidentifikasi setiap baris, umumnya id.
• Foreign Key (FK): kolom yang menunjuk ke primary key tabel lain, membentuk relasi antar tabel.

2. Jenis Relasi

Memahami kardinalitas adalah inti perancangan ERD:

• One-to-One (1:1): satu baris di tabel A berpasangan dengan tepat satu baris di tabel B. Contoh: satu User punya satu Profile. FK diletakkan di salah satu tabel dan diberi constraint unik.
• One-to-Many (1:N): satu baris di A bisa punya banyak baris di B. Contoh: satu User membuat banyak Order. FK diletakkan di sisi "many" (di tabel orders ada user_id).
• Many-to-Many (N:M): banyak baris A berhubungan dengan banyak baris B. Contoh: satu Order berisi banyak Product, dan satu Product bisa ada di banyak Order. Relasi ini butuh tabel pivot di tengah, misalnya order_items.

3. Contoh Kasus: Toko Online Sederhana

Kita rancang empat entitas: users, products, orders, dan order_items. Relasinya:

• Satu User membuat banyak Order (1:N).
• Satu Order berisi banyak Product melalui order_items (N:M).

Secara ringkas, ERD-nya bisa digambarkan seperti ini:

users (1) ----< (N) orders (1) ----< (N) order_items (N) >---- (1) products

Perhatikan bahwa order_items tidak sekadar tabel pivot kosong; ia menyimpan atribut tambahan seperti quantity dan price (harga saat pembelian). Inilah alasan kita membuatnya sebagai entitas sendiri, bukan pivot polos.

4. Normalisasi Dasar

Normalisasi mencegah data ganda dan tidak konsisten. Tiga aturan pertama yang perlu diingat:

• 1NF (First Normal Form): setiap kolom berisi satu nilai atomik, tidak ada daftar dalam satu kolom. Jangan simpan "produk A, produk B" dalam satu kolom.
• 2NF: setiap atribut non-kunci bergantung pada seluruh primary key. Inilah alasan detail item pesanan dipisah ke order_items.
• 3NF: tidak ada atribut yang bergantung pada atribut non-kunci lain. Contoh: jangan simpan product_name di orders karena itu milik products; cukup simpan product_id.

Namun perhatikan pengecualian penting: di order_items kita sengaja menyimpan price, karena harga produk bisa berubah dan kita ingin merekam harga saat transaksi terjadi. Ini denormalisasi yang disengaja demi akurasi histori.

5. Menerjemahkan ERD ke Migration Laravel

Setelah ERD jelas, ubah menjadi migration. Mulai dari tabel tanpa dependensi (parent) menuju tabel yang bergantung padanya (child).

Schema::create('products', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->integer('price');
    $table->integer('stock')->default(0);
    $table->timestamps();
});

Tabel orders memiliki foreign key ke users — inilah relasi 1:N:

Schema::create('orders', function (Blueprint $table) {
    $table->id();
    $table->foreignId('user_id')->constrained()->cascadeOnDelete();
    $table->integer('total')->default(0);
    $table->string('status')->default('pending');
    $table->timestamps();
});

Tabel penghubung order_items mewujudkan relasi N:M antara orders dan products:

Schema::create('order_items', function (Blueprint $table) {
    $table->id();
    $table->foreignId('order_id')->constrained()->cascadeOnDelete();
    $table->foreignId('product_id')->constrained();
    $table->integer('quantity');
    $table->integer('price'); // harga saat transaksi
    $table->timestamps();
});

6. Mencerminkan Relasi di Model Eloquent

ERD juga menentukan method relasi di model. Relasi 1:N dari User ke Order:

class User extends Authenticatable
{
    public function orders()
    {
        return $this->hasMany(Order::class);
    }
}

Relasi N:M dari Order ke Product lewat tabel pivot, dengan mengambil kolom tambahan:

class Order extends Model
{
    public function products()
    {
        return $this->belongsToMany(Product::class, 'order_items')
            ->withPivot(['quantity', 'price'])
            ->withTimestamps();
    }
}

7. Kesalahan Umum saat Merancang ERD

• Menaruh FK di sisi yang salah: pada 1:N, foreign key selalu di sisi "many".
• Melupakan tabel pivot untuk N:M: relasi banyak-ke-banyak tidak bisa langsung; ia butuh tabel penghubung.
• Menduplikasi data: menyimpan nama produk di banyak tabel membuat pembaruan rawan tidak konsisten.
• Mengabaikan histori: untuk transaksi, salin nilai penting seperti harga agar tidak berubah saat data induk diperbarui.
• Urutan migration salah: membuat tabel anak sebelum tabel induk membuat foreign key gagal. Selalu buat tabel yang dirujuk lebih dulu.

8. Dari ERD ke Fitur Nyata

Setelah struktur database jadi, ERD Anda menjadi panduan membangun fitur. Setiap entitas biasanya berpasangan dengan satu controller CRUD, setiap relasi menentukan eager loading yang Anda pakai agar query efisien, dan setiap foreign key mengingatkan Anda memvalidasi bahwa data referensi memang ada. Misalnya, saat menyimpan order, Anda akan melakukan loop pada item keranjang untuk mengisi order_items, sekaligus menyalin harga produk saat itu. Karena ERD sudah menjelaskan hubungan antar tabel, alur kode ini menjadi jelas dan mudah diprediksi.

ERD juga membantu tim berkomunikasi. Seorang developer baru yang melihat ERD Anda langsung memahami bagaimana aplikasi bekerja tanpa harus membaca ribuan baris kode. Karena itu, simpan diagram ERD di repositori atau dokumentasi proyek dan perbarui setiap kali struktur berubah. Diagram yang terjaga adalah investasi kecil yang menghemat banyak waktu onboarding dan mencegah kesalahpahaman.

Dengan memetakan entitas, memilih jenis relasi yang tepat, menormalisasi seperlunya, lalu menerjemahkannya ke migration dan model, Anda punya fondasi database yang bersih dan mudah dikembangkan. Merancang ERD lebih dulu menghemat banyak waktu debugging di kemudian hari, dan menjadi kebiasaan yang membedakan aplikasi asal jadi dari aplikasi yang benar-benar siap tumbuh.