1. Perubahan Pola Pikir: Bukan Sekadar Membuat Sistem yang Berjalan

Pada pertemuan-pertemuan sebelumnya, mahasiswa telah melalui proses analisis masalah, identifikasi kebutuhan, penyusunan User Story, pembuatan diagram UML, hingga pemetaan spesifikasi fungsional dan non-fungsional. Memasuki Pertemuan 5, mahasiswa harus menaikkan standar intelektual dan teknis pengembangannya[cite: 1].

Tujuan utama dari sebuah proyek perangkat lunak tingkat lanjut bukanlah sekadar melahirkan sistem informasi yang dapat dibuka melalui browser atau menampilkan antarmuka yang menarik. Di era kecerdasan buatan saat ini, tools seperti ChatGPT, Claude, atau Gemini dapat dengan mudah menghasilkan kode pemrograman, basis data, hingga draf arsitektur aplikasi dalam hitungan detik.

2. Dari ERD Menjadi Database: Jembatan Konseptual ke Fisik

Entity Relationship Diagram (ERD) yang dirancang pada tahap awal bukan sekadar gambar dokumentasi pelengkap laporan. ERD adalah cetak biru (*blueprint*) konseptual yang diterjemahkan secara presisi menjadi tabel-tabel fisik di dalam basis data relasional[cite: 1].

Gambar 5.1: Integrasi Komprehensif Struktur ERD Relasional dan Optimasi Algoritma Penanganan Beban Sistem.

Ambil contoh studi kasus Sistem Informasi Penjualan UMKM[cite: 1]. Entitas-entitas yang telah diidentifikasi seperti users, pelanggan, kategori, produk, transaksi, dan detail_transaksi[cite: 1] harus saling terikat melalui aturan relasi yang ketat. Kegagalan dalam merancang hubungan antar tabel di tahap ERD akan berakibat fatal pada integritas data.

3. Konsep Kunci: Primary Key, Foreign Key, dan Kardinalitas Relasi

Dalam membangun basis data relasional, mahasiswa wajib menguasai dua komponen pengikat data yang fundamental:

• Primary Key (PK): Kolom atau atribut unik yang mendefinisikan secara pasti setiap baris data di dalam sebuah tabel (contoh: id_produk pada tabel produk). Tidak boleh ada nilai yang sama atau kosong (*null*).
• Foreign Key (FK): Kolom pada suatu tabel yang merujuk pada Primary Key di tabel lain (contoh: kategori_id di tabel produk). Kolom ini berfungsi sebagai paku pengikat relasi antar entitas.

Selain itu, pemahaman mengenai jenis relasi kardinalitas mutlak dikuasai:

1. One-to-One (1:1): Satu baris data berhubungan tepat dengan satu baris data di tabel lain (contoh: entitas User dengan Profile).
2. One-to-Many (1:N): Satu data dapat berelasi dengan banyak data lainnya (contoh: satu Kategori dapat menaungi banyak Produk)[cite: 1].
3. Many-to-Many (N:M): Banyak data berelasi dengan banyak data (contoh: Mahasiswa dan Mata Kuliah), yang dalam implementasinya wajib menggunakan tabel perantara (*junction table* seperti tabel KRS).

4. Mengapa Harus Ada Tabel Detail Transaksi? (Normalisasi Database)

Kesalahan klasik yang sering dilakukan pemula adalah mencatat seluruh produk yang dibeli langsung ke dalam satu tabel transaksi utama (misal: kolom produk_1, produk_2, dst.). Hal ini melanggar kaidah normalisasi database karena membuat struktur tabel menjadi kaku dan tidak terbatas.

Solusi standarnya adalah menerapkan normalisasi dengan memisahkan struktur menjadi dua tabel:

• Tabel transaksi: Menyimpan informasi umum yang bersifat tunggal per nota (ID transaksi, tanggal, ID pelanggan, total harga, dan kasir)[cite: 1].
• Tabel detail_transaksi: Menyimpan rincian item barang yang dibeli (ID transaksi, ID produk, kuantitas, harga satuan, dan subtotal)[cite: 1].

5. Analisis Pemilihan DBMS (MySQL, PostgreSQL, SQLite, dan SQL Server)

Setelah ERD dirancang, langkah krusial berikutnya adalah memilih Sistem Manajemen Basis Data (*DBMS*) yang paling tepat sesuai dengan karakteristik dan skala proyek perangkat lunak Anda. Berikut adalah analisis perbandingannya:

A. MySQL / MariaDB

Karakteristik: DBMS relasional open-source yang paling populer di dunia web, terintegrasi sangat kuat dengan ekosistem PHP dan Laravel.

• Kelebihan: Performa tinggi untuk operasi baca (*read-heavy*), dokumentasi sangat luas, mudah dipelajari, dan didukung oleh hampir semua layanan *hosting*.
• Kapan Dipilih: Sangat cocok untuk proyek standar seperti e-commerce UMKM, sistem informasi akademik, dan aplikasi web umum.

B. PostgreSQL (Postgres)

Karakteristik: DBMS relasional tingkat lanjut (*object-relational*) yang sangat menekankan pada standar kepatuhan SQL, integritas data, dan kompleksitas query.

• Kelebihan: Sangat kuat menangani transaksi kompleks, mendukung tipe data modern seperti JSON secara native, serta memiliki sistem *locking* yang sangat canggih untuk *concurrency*.
• Kapan Dipilih: Cocok untuk aplikasi skala besar, sistem finansial/perbankan, analitik data, atau aplikasi yang membutuhkan pemrosesan data tingkat tinggi.

C. SQLite

Karakteristik: Basis data relasional mandiri yang bersifat *serverless* (berbasis file tunggal).

• Kelebihan: Tidak memerlukan instalasi server database terpisah, sangat ringan, cepat, dan menjadi bawaan default di berbagai sistem operasi serta framework modern untuk tahap pengujian lokal.
• Kapan Dipilih: Ideal untuk aplikasi mobile, pengujian unit (*testing*), aplikasi skala kecil, atau arsitektur *Offline-First* di sisi *client*.

D. Microsoft SQL Server (MSSQL)

Karakteristik: DBMS komersial tingkat enterprise yang dikembangkan oleh Microsoft.

• Kelebihan: Integrasi yang mulus dengan ekosistem Windows Server dan bahasa pemrograman C# (.NET), serta fitur manajemen enterprise yang lengkap.
• Kapan Dipilih: Digunakan pada lingkungan korporat besar yang memang berbasis lisensi infrastruktur Microsoft.

6. Cara Mengenerate Database secara Utuh Setelah ERD Jadi

Setelah jenis DBMS dipilih, penerjemahan ERD ke mesin database dapat dilakukan melalui:

• Forward Engineering pada CASE Tools: Menggunakan tools seperti *MySQL Workbench* atau *DBeaver* untuk otomatis men-generate skrip DDL (*Data Definition Language*) SQL dari diagram ERD.
• Laravel Migration: Menuliskan struktur tabel secara terprogram menggunakan PHP agar dapat direplikasi secara konsisten di berbagai lingkungan server (lokal, staging, production).

7. Algoritma Tidak Hanya Searching dan Sorting

Mahasiswa ilmu komputer sering kali terjebak dalam pemikiran bahwa algoritma terbatas pada teknik pencarian (*searching*), pengurutan (*sorting*), percabangan (*conditional*), dan perulangan (*loops*). Padahal, dalam arsitektur aplikasi modern berskala web dan cloud, persoalan komputasional jauh lebih luas dan kompleks:

• Manajemen Beban & Skalabilitas: Queue (antrean), Rate Limiting, Throttling, Caching, Batch Processing, dan Concurrency Control[cite: 1].
• Ketahanan Sistem (Resilience): Offline-First, sinkronisasi data lokal, Retry Mechanism, Exponential Backoff, Conflict Resolution, dan Idempotency[cite: 1].
• Kecerdasan Buatan: Klasifikasi, prediksi, sistem rekomendasi, Vector Search, Retrieval-Augmented Generation (RAG), dan Agentic Workflow.

8. Studi Kasus Komputasional: Mengatasi Lonjakan Request (Concurrency & Queue)

Bayangkan skenario nyata: Sebuah sistem absensi atau penjualan diserbu oleh 20 hingga 100 pengguna secara bersamaan (*concurrent requests*)[cite: 1]. Jika seluruh permintaan langsung dieksekusi oleh server web dan menghantam database tanpa kendali, konsumsi CPU dan RAM akan melonjak drastis, berujung pada *latency* tinggi, *database deadlock*, atau *server timeout*.

Untuk menyelesaikan persoalan ini, pengembang menerapkan pendekatan Queue (Antrean) dan Rate Limiting[cite: 1]:

• Queue: Alih-alih memproses transaksi berat seketika, permintaan pengguna dimasukkan ke dalam antrean (*message broker* seperti Redis/Database Queue) dan dieksekusi secara teratur oleh *background worker*[cite: 1].
• Rate Limiting: Algoritme pembatas frekuensi yang menolak atau menahan laju request berlebih dari IP/User tertentu dalam rentang waktu tertentu guna melindungi infrastruktur server[cite: 1].
• Concurrency Control: Penggunaan *Database Transactions* dan *Pessimistic/Optimistic Locking* untuk menjamin konsistensi stok barang agar tidak terjadi penjualan ganda[cite: 1].

9. Arsitektur Offline-First dan Sinkronisasi Data

Bagaimana jika aplikasi digunakan di lapangan (seperti sistem absensi perkebunan atau kurir logistik) di mana koneksi internet sering terputus-putus? Mengandalkan koneksi online penuh akan membuat aplikasi tidak dapat digunakan (*fail*).

Solusinya adalah merancang aplikasi bergeser ke Offline-First Architecture[cite: 1]:

1. Aplikasi tetap berjalan secara lokal dengan memanfaatkan *Local Storage* atau *IndexedDB/SQLite* pada perangkat client[cite: 1].
2. Ketika data dimasukkan saat offline, sistem menandainya dengan status PENDING.
3. Saat koneksi internet kembali pulih (*online*), *Sync Engine* secara otomatis menjalankan algoritma sinkronisasi untuk mengirimkan antrean data lokal ke server pusat[cite: 1].
4. Agar tidak terjadi pengiriman berulang akibat jaringan yang masih fluktuatif, diterapkan Retry Mechanism dengan Exponential Backoff serta Idempotency Key agar server dapat mengenali jika suatu data transaksi sudah pernah tersimpan sebelumnya[cite: 1].

10. Dari ERD Menuju Laravel Migration dan Eloquent Model

Setelah database berhasil di-generate dari ERD, tahap berikutnya adalah implementasi teknis ke dalam framework Laravel menggunakan Migration dan Eloquent ORM.

Migration berfungsi sebagai version control untuk database, memungkinkan pengembang membuat tabel secara terprogram menggunakan PHP:

Schema::create('produk', function (Blueprint $table) {
    $table->id();
    $table->foreignId('kategori_id')->constrained('kategori')->onDelete('cascade');
    $table->string('nama_produk');
    $table->decimal('harga', 15, 2);
    $table->integer('stok');
    $table->timestamps();
});

Selanjutnya, relasi database ini direpresentasikan kedalam Eloquent Model menggunakan method relasi seperti hasMany dan belongsTo, menyatukan konsep desain relasional dengan pemrograman berorientasi objek.

11. AI sebagai System Architect Assistant (Prompt Engineering)

AI adalah alat bantu yang sangat powerful, namun efektivitasnya bergantung pada kualitas instruksi (*prompt*) yang diberikan. Mahasiswa dilarang menggunakan prompt yang terlalu umum seperti: "Buatkan aplikasi penjualan."

Sebagai gantinya, mahasiswa harus menempatkan AI pada peran profesional tertentu (*role assignment*) agar menghasilkan output yang tervalidasi secara arsitektural.

12. Standar Judul Proyek yang "Berisi" (Kontribusi Ilmiah)

Dalam menyusun proposal atau laporan proyek, mahasiswa di lingkungan ITB Yadika Pasuruan diarahkan untuk menghindari judul yang bersifat generik dan administratif semata (seperti: "Sistem Informasi Penjualan Berbasis Web").

Formula Judul Berkualitas:
Masalah + Pendekatan/Algoritma + Tujuan + Objek

• Contoh 1: Implementasi Offline-First dan Sinkronisasi Data untuk Meningkatkan Keandalan Sistem Absensi pada Jaringan Tidak Stabil.
• Contoh 2: Implementasi Queue dan Rate Limiting untuk Meningkatkan Stabilitas Sistem Akademik pada Kondisi Concurrent Request.

13. Tugas Wajib Mahasiswa (Output Pertemuan 5)

Berdasarkan materi yang telah dipelajari, setiap mahasiswa wajib mengumpulkan dokumen pengerjaan dengan format komponen berikut:

1. Rancangan ERD Komprehensif: Skema minimal 5 tabel utama yang saling berelasi, lengkap dengan identifikasi Primary Key dan Foreign Key[cite: 1].
2. Analisis Pemilihan DBMS: Uraian argumentasi pemilihan DBMS secara spesifik (MySQL/PostgreSQL/SQLite/SQL Server) untuk proyek yang dikembangkan.
3. Analisis Masalah & Pendekatan Algoritma: Uraian mengenai persoalan komputasional yang diselesaikan (apakah concurrency, queue, caching, offline-first, sync, dll) beserta alasan pemilihannya[cite: 1].
4. Lampiran Bukti Prompt AI Lengkap: Riwayat transkrip prompt AI secara keseluruhan—mulai dari tahap perancangan ERD, pembuatan migration, hingga analisis pemilihan algoritma program—disertai catatan hasil validasi mandiri oleh mahasiswa.