Best Practice Dalam Menyusun Data Model

Asti Dwiyana
ecomindo-dev
Published in
8 min readOct 21, 2022

Data model merupakan diagram yang menggambarkan hubungan dari setiap elemen data yang terlibat pada sebuah proses bisnis. Penyusunan data model penting karena manfaat utama dari aplikasi MIS pada dasarnya adalah meningkatkan efisiensi dan efektifitas pengolahan data. Pada prakteknya, banyak orang yang tidak mengetahui langkah-langkah yang tepat dalam menyusun data model, akibatnya:

  1. Melewatkan informasi penting, sehingga informasi tidak tersedia saat hendak mengambil keputusan.
  2. Tidak disimpan secara efisien, sehingga biaya penyimpanan jadi lebih mahal.
  3. Tidak disusun dengan tepat, sehingga mengakibatkan query atau pemrosesan data menjadi lambat.
  4. Tidak didokumentasikan dengan tepat, sehingga keterkaitan antar elemen dan hubungannya dengan proses bisnis jadi sulit untuk dipahami.

Artikel ini akan membahas mengenai best practice dalam menyusun data model. Artikel ini ditujukan bagi pembaca yang sudah memahami dasar-dasar pembuatan Entity Relationship Diagram (ERD).

Ada beberapa best practice dalam menyusun data model yaitu: menyusun data model dengan urutan langkah yang tepat, melengkapi informasi karakteristik data, serta mempertimbangkan performance.

A. Menyusun Data Model Dengan Urutan Langkah Yang Tepat

Dalam menyusun data model, ada beberapa langkah yang harus dilakukan, yaitu:

  1. Menentukan subject area
  2. Menentukan tabel transaksi untuk setiap subjek area
  3. Menentukan field-field apa saja yang diperlukan untuk setiap table
  4. Menentukan tabel referensi.

Untuk mempermudah memahami urutan dalam menyusun data model akan disertai dengan contoh kasus.

Contoh kasus :
SP adalah perusahaan penyedia jasa keamanan. Pelanggan SP dapat memasang berbagai sensor di sekitar rumah atau toko. Jika ada kegiatan mencurigakan atau ada pembobolan, sensor akan mengirimkan sinyal ke kantor polisi (polsek) terdekat dan juga ke HP pemilik rumah/toko. Pemilik dapat mengatur untuk menggunakan fitur silent alarm, dimana alarm tidak herbunyi dan hanya member sinyal ke petugas. Atau bisa juga mengggunakan fitur alarm yang akan berbunyi kencang untuk memperingatkan sekitar. Pengguna juga dapat mengatur untuk mengirimkan sinyal pada orang orang tertentu, misalnya tetangga sehingga mereka bisa saling mengawasi keamanan wilayah dengan lebih baik. Ini hanya bisa dilakukan bila tetangga juga menginstall aplikasi mobile SP. SP juga bekerjasama dengan startup VM, yang membuat monitoring device untuk dipasang ke kendaraan. Device milik VM dapat dipasang pada mobil pribadi para pemilik produk SP. Jika terjadi pembobolan, sensor akan mengirimkan sinyal ke mobil dan membunyiken klakson mobil untuk memperingatkan semua orang di wilayah tersebut.

Untuk mempercepat respon, setiap petugas patroli juga menginstall aplikasi SP di HP-nya. Aplikasi SP memantau lokasi patroli dan mengirimkan sinyal bahaya pada patroli -patroli terdekat via HP petugas. Karena petugas patroli berganti-ganti, diperlukan aplikasi web yang digunakan oleh polsek untuk mengelola data patroli setiap hari. Aplikasi ini mengelola rute patroli serta petugasnya, termasuk nomor HP para petugas. Device milik VM juga dipasang dimobil patroli. Device tersebut dapat mengirimkan lokasi GPS kendaraan, lengkap dengan pola permakaian dan kondisi kesehatan mobil. SP merekam seluruh rute perjalan patroli dan membuat peta coverage patroli yang dapat dilihat oleh perwira polisi sesuai dengan tingkat kewenangannya. Polsek dapat melihat coverage patroli-patroli miliknya. sedangkan Polres dan Polda (tingkatan di atas polsek) dapat melihat coverage seluruh patroli di wilayahnya masing-masing.

Langkah 1: Menentukan Subjek Area.

Untuk menentukan subject area, kita perlu terlebih dahulu menyusun model dari proses bisnis, karena subject area baru bisa didapatkan dari proses bisnis yang sudah tersusun.

Berikut merupakan model proses bisnis PT. SP sesuai dengan contoh kasus di atas :

Gambar 1. Model Proses Bisnis Untuk Proses Konfigurasi dan Entry Data Patroli
Gambar 2. Model Proses Bisnis Untuk Proses Deteksi dan Alert
Gambar 3. Model Proses Bisnis Untuk Proses Analysis

Pada gambar 1–3 dapat dilihat ada notasi storage yang ditandai dengan bulatan merah. Notasi storage bisa berarti kumpulan tabel atau hanya berisikan satu tabel saja tetapi bukan merupakan sebuah tabel. Dalam hal ini, notasi storage bisa disebut sebagai subject area. Masing-masing subject area nantinya akan terdiri dari tabel-tabel yang relevan dengan bisnis proses pada subject area tersebut.

Langkah 2: Menentukan Tabel Transaksi.

Setelah mengetahui subject area apa saja yang ada pada model proses bisnis, langkah selanjutnya adalah menentukan tabel transaksi untuk setiap subject area tersebut dan menetapkan field / atribut apa saja yang dimiliki oleh tabel tersebut.

Data yang disimpan pada tabel bisa bersifat sebagai data transaksi atau data referensi.

  • Tabel transaksi berisi data yang dihasilkan dari proses bisnis (data transaksi).
  • Tabel referensi berisi data yang digunakan untuk membentuk proses bisnis (data referensi).

Pada contoh kasus PT.SP, terdapat subject area patroli. Dari subject area Patroli, dapat disimpulkan bahwa dibutuhkan satu tabel transaksi Patroli yang nantinya akan menyimpan data-data yang berhubungan dengan proses Patroli. Perlu diketahui bahwa sebuah tabel dapat berada dibeberapa subject area karena tidak tertutup kemungkinan suatu tabel dapat dipakai di beberapa bagian dalam proses bisnis.

Dari contoh kasus PT.SP, kita dapat menentukan tabel transaksi, yaitu tabel Patroli, tabel Deteksi, dan tabel Alert.

Tabel Patroli berisikan data-data yang berhubungan dengan kegiatan patroli, seperti:

  • ID Mobil,
  • Rute yang dijalankan,
  • Petugas yang mengendarai,
  • Waktu Patroli, yaitu tanggal dan jam mulai & selesai patroli.

Tabel Deteksi berisikan data-data yang berhubungan dengan proses deteksi, seperti:

  • ID Customer,
  • Nama customer,
  • ID Device,
  • ID Sensor,
  • ID Mobil customer,
  • ID Patroli,
  • Lokasi kejadian,
  • Waktu dan Jenis kejadian,
  • Status deteksi.

Tabel Alert berisikan data-data yang berhubungan dengan proses alerting, seperti:

  • ID Sensor,
  • ID Device,
  • ID Konfigurasi,
  • ID Rute.

Langkah 3: Menentukan Tabel Referensi

Dari contoh kasus PT.Seorang Pria, kita menentukan tabel-tabel referensi yang dibutuhkan, yaitu:

  • Tabel Rute Patroli yang berisi rute dan status aktif atau tidaknya rute tersebut.
  • Tabel Petugas yang berisi NIP, Nama, No HP, dan lokasi tugas.
  • Tabel Mobil Patroli yang berisi plat mobil, pola pemakaian, dan kondisi kesehatan mobil.
  • Tabel TitikRute yang berisi titik-titik rute yang harus dikunjungi suatu rute.

Berikut contoh data model subject area patroli :

Gambar 4. Data Model Subject Area Patroli

B. Melengkapi Informasi Status dan Riwayat Data

Poin kedua yang akan dibahas adalah mengenai primary key, alternate key, foreign key, composite key, cascade update & delete, discontinue flag / active flag, tabel history, dan effective date.

Primary Key

Primary key merupakan kolom pada tabel yang secara unique mengidentifikasi setiap baris data pada tabel. Primary key tidak boleh bernilai NULL.

Primary key seharusnya berisi informasi yang unique berdasarkan konten dari data tersebut. Contohnya adalah pada tabel MobilPatroli, primary key nya adalah no_mobilpatroli yang merupakan informasi yang unique dari tabel tersebut.

Suatu tabel bisa bersifat sebagai strong-entity atau weak-entity. Weak entity adalah tabel yang primary key nya mengacu pada tabel lain. Sedangkan strong entity adalah tabel yang primary key nya tidak bergantung ke tabel lain.

Salah satu jenis primary key adalah Composite key. Composite Key merupakan kombinasi beberapa kolom, dan kolom tersebut digunakan untuk mengidentifikasi semua baris yang terlibat secara unique. Composite key juga bisa didefinisikan sebagai primary key yang dibuat dari beberapa kolom.

Foreign Key

Foreign key merupakan sebuah kolom pada tabel yang menghubungkan tabel tersebut dengan primary key pada tabel parent nya. Contohnya adalah kolom ID_Rute pada tabel Patroli yang menjadi penghubung antara tabel Patroli dan RutePatroli.

Alternate Key

Alternate key merupakan kolom yang dijadikan alternatif pengganti primary key. Kolom ini memiliki value unique dan umumnya berbentuk sequence number atau GUID.

Fungsi dari alternate key adalah:

  1. Jika terjadi perubahan pada primary key maka tidak dibutuhkan cascading update ke table-table child nya.
  2. Menghindari pemakaian composite key, agar referensi menjadi lebih sederhana. Pada gambar 5, dapat dilihat bahwa tabel TitikRute merupakan weak entity karena primary key nya bergantung pada tabel Rute. Jadi ketika ada tabel lain yang merujuk ke table TitikRute maka foreign key nya ada dua yaitu No_TitikRute dan ID_RutePatroli. Untuk menghindari hal tersebut, maka tabel TitikRute diberi alternate key yaitu ID_TitikRute agar ketika ada tabel lain yang merujuk ke tabel TitikRute hanya memiliki satu foreign key yaitu alternate key dari tabel TitikRute.
Gambar 5. Data Model Subjek Area Patroli yang sudah dilengkapi dengan alternate key

Discontinue Flag / Active Flag

Dicontinue flag atau active flag merupakan sebuah atribut pada tabel yang digunakan untuk menandakan sebuah data masih aktif atau tidak. Contohnya adalah atribut IsActive pada tabel rute. Atribut ini berfungsi untuk menandakan rute mana saja yang masih aktif. Active flag diperlukan karena data tidak lagi dibutuhkan, tetapi data tersebut tidak dapat dihapus. Ini karena data tersebut masih direfer oleh tabel lain sebagai Foreign-Key atau kita masih membutuhkannya untuk keperluan lain, misalnya reporting.

Tabel History

Tabel history bisa digunakan untuk menyimpan data-data yang memiliki transaction date dan data-data yang harus disimpan secara berulang.

Effective Date

Kolom effective_start_date dan effective_end_date digunakan untuk menyimpan historical data, sehingga kita dapat melihat perubahan data dari waktu ke waktu.

Kolom effective date ini juga penting agar administrator tidak perlu mengubah data tepat di jam tertentu. Contohnya adalah voucher diskon pada e-commerce. Voucher tersebut pastinya memiliki masa tenggang. Kolom effective date dapat digunakan pada voucher agar di jam tertentu administrator tidak harus mengaktifkannya secara manual.

C. Mempertimbangkan Performance

Ada beberapa hal yang sangat mempengaruhi performance, diantaranya adalah normalisasi, indexing, partisi, dan denormalisasi.

Normalisasi

Normalisasi bertujuan untuk mencegah redudansi sehingga menghemat media penyimpanan, serta memastikan inkonsistensi data. Normalisasi biasanya digunakan pada database aplikasi transaksional (OLTP). Dengan menggunakan metode normalisasi, jumlah tabel yang dihasilkan untuk suatu proses akan lebih banyak.

Indexing

Index adalah sebuah objek dalam database yang dapat mempercepat proses pencarian data (query). Index digunakan untuk menemukan data dengan cepat tanpa harus mencari setiap baris dalam tabel setiap kali tabel diakses. Seringkali performa query baru diketahui setelah aplikasi masuk ke fase production, sehingga index baru ditambahkan belakangan. Ini adalah bagian dari performance-tunning. Gunakan modul profiler untuk mengetahui beban query dan efektfitas pengunaan index sebelum memutuskan tabel mana yang perlu di-tunning.

Penetapan index juga perlu mempertimbangkan behavior penggunaan tabel. Semakin banyak index digunakan di suatu tabel, maka proses insert ke tabel tersebut akan menjadi semakin lambat.

Partisi

Partisi adalah cara yang dilakukan untuk membagi objek database (tabel, index, views) menjadi bagian-bagian yang terpisah. Tujuan dari partisi adalah :

  1. Jika data berukuran besar, data dapat diakses secara paralel karena disimpan ditempat yang berbeda.
  2. Pengolahan data dapat dilakukan pada scope yang lebih kecil.
  3. Atomic transaction dapat dilakukan di level partisi ketimbang di level tabel atau row saja.

Denormalisasi

Denormalisasi bertujuan untuk mempercepat pencarian data pada database dengan menggunakan redudansi data pada tabel yang ada. Metode ini banyak digunakan pada database aplikasi analisa (OLAP). Data-data yang dibutuhkan nantinya akan disimpan dalam satu tabel agar memudahkan proses pencarian data.

C. Penutup

Sebagai IT developer, penting untuk memiliki pemahaman akan penyusunan data model. Mulai dari proses penentuan subject area, penentuan tabel transaksi dan field didalamnya, hingga penentuan tabel referensi. Penyusunan data model yang tepat akan meningkatkan efektifitas dan efisiensi pengolahan data. Dengan data model yang akurat, maka data yang tersimpan merupakan data yang tepat dan terjaga integritasnya, sehingga pada akhirnya akan menghemat banyak biaya.

Semoga artikel ini bermanfaat. Terima kasih.

Editor: AF

--

--