Perancangan Basis Data (Kasus: Retail)

Dalam artikel basis data kali ini, saya akan mencoba membahas tentang bagaimana merancang sebuah basis data dengan model relasional pada sebuah kasus tertentu. Scope pembahasan dimulai dari problem statement, identifikasi data, identifikasi entitas, identifikasi atribut setiap entitas, menyusun kembali entitas secara lengkap, melakukan analisis hubungan antar entitas, membuat ERD (entity relationship diagram), dan terakhir mentransformasi ERD ke dalam struktur tabel.

Di sini hanya akan dibahas tentang perancangan basis data menggunakan model data relasional, disebabkan model data inilah yang paling banyak digunakan saat ini, dibandingkan model data lainnya seperti hirarki, maupun network.

Studi kasus yang akan dibahas pada artikel ini tentang perancangan basis data di sebuah transaksi pembelian retail.

Problem Statement

Studi kasus yang akan diberikan pada pembahasan ini adalah tentang transaksi retail di sebuah minimarket. Misalkan diberikan tampilan sebuah struk pembelian seorang member di sebuah minimarket seperti pada Gambar 1.

Berdasarkan tampilan struk tersebut, kita akan membuat rancangan struktur databasenya dengan model data relasional.

Identifikasi Data

Pada Gambar 1 tampak sebuah sebuah struk yang di dalamnya terdapat beberapa data. Berikut ini daftar data yang ada di dalam struk, tersusun secara urut berdasarkan letaknya dalam struk (dari atas ke bawah):

• Nama cabang minimarket
• No. telp cabang minimarket
• Alamat cabang minimarket
• Email kantor pusat
• No. telp kantor pusat
• No. transaksi (No. Bon)
• Nama kasir
• Nama barang
• Kuantitas setiap barang yang dibeli
• Harga satuan barang
• Subtotal harga setiap barang yang dibeli
• Diskon harga setiap barang yang dibeli
• Total harga transaksi pembelian
• Total diskon transaksi pembelian
• Nilai voucher transaksi pembelian
• Jumlah nominal tunai uang pada transaksi pembelian
• Besarnya nominal uang kembalian pada transaksi pembelian
• PPN transaksi pembelian
• Tanggal dan waktu transaksi
• Nama member
• Jumlah poin pada transaksi
• Total poin member
• Nama kantor pusat
• No NPWP kantor pusat
• Alamat kantor pusat

Identifikasi Entitas

Langkah pertama dalam perancangan basis data adalah identifikasi entitas apa saja yang terdapat dalam kasus tersebut. Sebuah entitas bisa berwujud misalnya orang, benda, tempat, atau juga bisa tidak berwujud misalnya transaksi, atau kegiatan. Entitas ini sifatnya harus independen, artinya keberadaannya tidak bergantung entitas lain. Berdasarkan keterangan data yang didapat sebelumnya (terdapat di dalam struk), dapat kita identifikasi beberapa entitas sbb:

• Transaksi Pembelian
• Cabang Minimarket
• Barang
• Kasir
• Member
• Kantor Pusat

Identifikasi Atribut Entitas

Setelah entitas berhasil kita identifikasi, selanjutnya akan kita identifikasi pula atribut setiap entitas tersebut. Atribut adalah properti atau karakteristik yang menjadi milik sebuah entitas tertentu. Pada langkah ini, kita masukkan setiap hasil identifikasi data ke dalam entitasnya masing-masing. Berikut ini adalah entitas beserta atribut-atributnya:

• Transaksi Pembelian:
  • No. transaksi (No. Bon)
  • Total harga transaksi pembelian
  • Total diskon transaksi pembelian
  • Nilai voucher transaksi pembelian
  • Jumlah nominal tunai uang pada transaksi pembelian
  • Besarnya nominal uang kembalian pada transaksi pembelian
  • PPN transaksi pembelian
  • Tanggal dan waktu transaksi
  • Jumlah poin pada transaksi
• Cabang Minimarket
  • Nama cabang minimarket
  • No. telp cabang minimarket
  • Alamat cabang minimarket
• Barang
  • Nama barang
  • Harga satuan barang
• Kasir
  • Nama kasir
• Member
  • Nama member
  • Total poin member
• Kantor Pusat
  • Nama kantor pusat
  • No NPWP kantor pusat
  • Alamat kantor pusat
  • Email kantor pusat
  • No. telp kantor pusat

Perhatikan! Untuk data berikut ini sementara tidak dimasukkan ke dalam atribut entitas tertentu:

• Kuantitas setiap barang yang dibeli
• Subtotal harga setiap barang yang dibeli
• Diskon harga setiap barang yang dibeli

Hal ini disebabkan karena data tersebut bukan milik sebuah entitas tertentu, melainkan milik beberapa entitas, Sebagai contoh misalnya ‘kuantitas setiap barang yang dibeli’ dalam sebuah struk. Data ini melibatkan beberapa entitas, yaitu barang dan juga transaksi. Data ini menunjukkan kuantitas barang yang dibeli pada sebuah transaksi, dengan kata lain data kuantitas ini muncul ketika terjadi transaksi pembelian. Oleh karena itu data ini sifatnya tidak murni milik sebuah entitas tertentu. Demikian pula untuk data subtotal harga dan diskonnya.

Lantas ketiga data di atas akan dikemanakan? Nanti akan tetap kita tambahkan di akhir proses. OK??

Menyusun Entitas Secara Lengkap

Setelah atribut dari setiap entitas berhasil kita identifikasi, langkah selanjutnya adalah menyusun kembali entitas secara lengkap beserta atribut-atributnya, termasuk atribut pengenalnya. Atribut pengenal adalah sebuah atribut yang menjadi pembeda antar data pada entitas. Sebagai contoh misalnya pada entitas transaksi. Di situ ada atribut No. Transaksi (No. Bon) yang sifatnya unik atau tunggal atau tidak boleh ada yang sama antar setiap transaksi. Atribut inilah yang menjadi pembeda tiap data transaksi.

Apabila dalam sebuah entitas belum tampak adanya atribut pengenal, maka bisa kita buat sendiri.

• TransaksiPembelian (NoTransaksi, TotalHarga, TotalDiskon, Voucher, NominalTunai, Kembalian, PPN, TanggalWaktu, Poin)
• Cabang (NoCabang, NamaCabang, NoTelpCabang, AlamatCabang)
• Barang (NoBarang, NamaBarang, HargaSatuan)
• Kasir (NoKasir, NamaKasir)
• Member (NoMember, NamaMember, TotalPoin)
• KantorPusat (NoPusat, NamaPusat, NPWP, AlamatPusat, EmailPusat, NoTelpPusat)

Keterangan: atribut pengenal ditandai dengan garis bawah (underlined)

Khusus pada entitas Cabang, Barang, Kasir, Member, dan KantorPusat, telah dibuat atribut pengenal secara manual. Hal ini disebabkan karena di setiap entitas tersebut belum ada atribut pembeda untuk setiap datanya. Sebagai contoh misalnya entitas Kasir. Di dalam ini hanya ada nama kasir. Sebagaimana kita tahu bahwa nama seseorang bisa saja sama. Oleh karena itu diberikan atribut pengenal NoKasir sebagai pembeda antar kasir.

Analisis Hubungan Antar Entitas

Entitas beserta atribut-atributnya sudah berhasil kita susun, beserta atribut pengenalnya. Langkah selanjutnya dalam perancangan basis data adalah menganalisis hubungan antar entitas. Tampilan struk yang ada pada Gambar 1 menunjukkan hubungan antar entitas. Sebagai contoh misalnya adanya hubungan antar entitas TransaksiPembelian dengan Member. Dalam hal ini seorang member dapat melakukan beberapa transaksi pembelian dengan beberapa NoTransaksi. Sebaliknya, sebuah nomor transaksi pembelian hanya berlaku untuk satu orang member saja.

Di dalam tahap ini, akan kita identifikasi dan analisis semua hubungan antar entitas yang ada. Pada langkah ini, apabila terdapat hal-hal yang belum jelas dalam hal keterkaitan antar entitas bisa dikonfirmasikan kepada klien.

Berikut ini beberapa entitas yang saling berhubungan dengan entitas lain, serta analisisnya:

• TransaksiPembelian – Cabang
  • Sebuah NoTransaksi dilakukan di satu NoCabang saja
  • Sebuah NoCabang bisa melakukan beberapa NoTransaksi
• TransaksiPembelian – Barang
  • Sebuah NoTransaksi bisa terdiri dari beberapa NoBarang
  • Sebuah NoBarang bisa terdapat di beberapa NoTransaksi
• TransaksiPembelian – Kasir
  • Sebuah NoTransaksi hanya dilayani oleh seorang kasir saja (satu NoKasir)
  • Seorang kasir (satu NoKasir) bisa melayani beberapa NoTransaksi
• TransaksiPembelian – Member
  • Sebuah NoTransaksi hanya dilakukan untuk satu NoMember
  • Satu NoMember dapat melakukan beberapa NoTransaksi
• Cabang – KantorPusat
  • Satu NoCabang hanya memiliki satu NoPusat
  • Satu NoPusat bisa memiliki beberapa NoCabang

Hasil analisis hubungan antar entitas di atas nantinya akan menentukan jenis kardinalitas hubungan antar entitas di dalam diagram ERD, apakah termasuk jenis one-to-many, one-to-one, atau many-to-many.

Membuat ERD

Berdasarkan hasil analisis hubungan antar entitas, selanjutnya kita bisa menggambar entity relationship diagram (ERD) nya. ERD yang dibuat ini nanti akan membantu kita dalam menyusun struktur tabel di database sekaligus relasi antar tabelnya.

Untuk membuat ERD bisa menggunakan free online tool, misalnya draw.io

Gambar 2 adalah ERD yang dibuat berdasarkan hasil analisis hubungan antar entitas sebelumnya.

Keterangan: atribut yang diberi garis bawah (underlined) adalah atribut pengenal dari masing-masing entitas.

Transformasi ERD ke Relasi Tabel

Selanjutnya, dari ERD yang telah diperoleh dapat dibuat transformasinya ke dalam relasi tabel.

Dalam melakukan transformasi ERD ke dalam bentuk relasi tabel yang nantinya akan diimplementasikan di dalam DBMS, ada beberapa kaidah yang perlu diperhatikan, yaitu:

• Sebuah entitas nantinya akan menjadi sebuah tabel
• Atribut yang ada di dalam entitas akan menjadi field dari tabel tersebut
• Atribut pengenal dari sebuah entitas akan menjadi Primary Key (PK) dari tabel
• Apabila ada dua entitas yang memiliki hubungan one-to-many, maka akan muncul field baru dalam tabel yang berasal dari entitas dengan kardinalitas many sebagai Foreign Key (FK). Field baru ini diambil dari Primary Key tabel yang berasal dari entitas berkadinalitas one.
• Apabila ada dua entitas yang memiliki hubungan many-to-many, maka akan muncul tabel baru yang Primary Key nya adalah gabungan Primary Key-Primary Key tabel yang berasal dari kedua entitas. Kedua Primary Key ini sekaligus sebagai Foreign Key.
• Apabila ada dua entitas yang memiliki hubungan one-to-one, maka akan muncul field baru di salah satu tabel yang berasal dari kedua entitas tersebut sebagai Foreign Key. Field baru ini diambil dari salah satu Primary Key tabel.

Berdasarkan ERD yang telah dibuat dan dengan menggunakan kaidah di atas, diperoleh diagram relasi antar tabel seperti pada Gambar 3.

Keterangan:

• Pada tabel Cabang, muncul field baru NoPusat sebagai Foreign Key yang mengacu pada field NoPusat yang ada di tabel KantorPusat. Hal ini disebabkan karena entitas Cabang dan KantorPusat memiliki hubungan one-to-many, dan kebetulan entitas Cabang adalah entitas yang berkadinalitas many (perhatikan Gambar 2).
• Pada tabel TransaksiPembelian, muncul beberapa field baru: NoCabang, NoMember, NoKasir. Hal ini disebabkan karena entitas TransaksiPembelian juga memiliki hubungan one-to-many dengan entitas Cabang, Member, dan Kasir. Kebetulan entitas TransaksiPembelian adalah entitas berkadinalitas many pada setiap hubungannya (perhatikan Gambar 2).
• Tabel BarangTransaksi muncul disebabkan dari hasil hubungan many-to-many dari entitas Barang dan TransaksiPembelian (lihat Gambar 2). Dalam hal ini gabungan field NoBarang dan NoTransaksi sebagai Primary Key nya sekaligus sebagai Foreign Key.
• Di dalam tabel BarangTransaksi muncul juga beberapa field: Quantity, SubTotalHarga, dan Diskon. Field ini muncul untuk mengakomodasi data ketiganya yang belum masuk ke dalam entitas tertentu sebelumnya, disebabkan karena ketiganya adalah atribut yang muncul dengan melibatkan beberapa entitas yaitu Barang dan Transaksi Pembelian.

OK.. setelah kita dapatkan struktur relasi antar tabel barulah kita bisa mengimplementasikannya di sebuah DBMS, khususnya RDMS (Relational Database Management System). Adapun untuk membuat Foreign Key di sebuah tabel, dapat menerapkan referential integrity.

Catatan Penting!!

Sebuah desain database dibuat berdasarkan asumsi-asumsi dan kebutuhan riil di lapangan. Sehingga akibatnya, untuk sebuah kasus tertentu bisa jadi akan dihasilkan desain yang berbeda-beda oleh beberapa database desainer. Sebagai contoh misalnya, desain database yang sudah saya paparkan di atas dibuat berdasarkan asumsi saya bahwa setiap kasir pernah melayani transaksi pembelian. Saya tidak tahu persis kebutuhan riilnya di lapangan, karena saya memang belum konfirmasi ke pihak retail tersebut. Sehingga semua desain ini murni berdasarkan asumsi saya 😀 . Sehingga berdasarkan asumsi saya tersebut, bisa ditelusur beberapa data misalnya:

• Siapa nama kasir yang melayani transaksi pembelian tertentu?
• Berasal dari cabang manakah si kasir melayani transaksi pembeliannya?

Akan tetapi, desain database di atas tidak bisa menjawab pertanyaan: siapa saja nama kasir yang belum pernah melayani transaksi pembelian dan berasal dari cabang mana saja?

Hal tersebut tidak bisa terjawab disebabkan data kasir yang belum pernah melayani transaksi pembelian tidak akan tercatat di tabel TransaksiPembelian. Sehingga tidak bisa dilacak dari cabang manakah dia. Untuk mengatasi hal itu, bisa kita tambahkan relasi langsung antara entitas Cabang dan Kasir yang menunjukkan dari cabang mana posisi si kasir ini ditempatkan.

Demikian penjelasan cara merancang basis data berdasarkan studi kasus retail menggunakan model data relasional. Apabila ada yang ingin ditanyakan bisa mengisi komentar di bawah ini. Semoga bermanfaat 🙂

Penjelasan secara oral dari artikel perancangan basis data untuk studi kasus ini bisa disimak di video berikut ini.

---