dB

1. Dasar-Dasar DesainDatabase yang Baik.
Mendesain database bukan hal sulit, akan tetapi harus mengikuti beberapa aturan/standar agar
model data menjadi fleksibel dan membuat kita lebih mudah bekerja dengannya. Desain yang
baik juga akan mempermudah kita dalam menjaga integritas data dan membuat laporan.
Desain database yang baik dimulai dari mendaftar data apa saja yang ingin dimasukan ke dalam
database dan apa yang ingin anda lakukan terhadap data tersebut. Jangan terlalu menganggap
ringan karena jika ada yang terlewat dimasukan, terkadang harus mulai lagi dari awal.
Mengidentifikasi Entities
Jenis informasi yang akan disimpan di dalam database disebut entities. Entities terdiri dari 4
jenis: orang, barang, event, dan lokasi. Semua entitas yang ingin dimasukan ke dalam database
harus masuk dalam kategori ini. Jika ia tidak masuk dalam kategori itu, mungkin merupakan
properti dari entities, atau sering juga disebut atribut.
Sebagai contoh, sebuah database toko akan mempunyai entitas berikut:
 Toko adalah lokasi
 Penjualan adalah event
 Produk adalah barang
 Pelanggan adalah orang.
Mengidentifikasi Relationship
Langkah berikutnya adalah membuat Relationship. Relationship menunjukan bagaimana
hubungan antar entiti ini. Seperti hubungan: Pelanggan membeli Produk, Produk dengan Toko,
Toko dengan Pelanggan, dan seterusnya.
Hubungan relationship dapat dikelompokan dalam beberapa jenis:
 one-to-one, 1:1 (satu ke satu)
 one-to-many: 1:N (satu ke banyak)
 many-to-one: M:1 (banyak ke satu)
 many-to-many: M:N (banyak ke banyak)
Untuk kasus Toko, kita bisa membuat relationship seperti berikut:
 Pelanggan => Penjualan; => 1:N, 1 Pelanggan melakukan banyak transaksi Penjualan (1
transaksi hanya bisa dilakukan oleh 1 Pelanggan);
 Pelanggan => Produk; => M:N, Banyak pelanggan dapat membeli 1 Produk, dan Banyak
Produk dapat dibeli 1 Pelanggan
 Pelanggan => Toko; => M:N, Banyak Pelanggan bisa membeli di 1 toko, dan Banyak
Toko bisa menjual ke 1 Pelanggan

2.  Penjualan => Produk; => M:N, Banyak Penjualan menjual 1 Produk, dan Banyak Produk
bisa dijual dalam 1 transaksi Penjualan.
 Toko => Penjualan; => 1:N, 1 Toko bisa melakukan banyak Penjualan. (1 transaksi
Penjualan hanya bisa dilakukan di 1 toko)
 Toko => Produk; => M:N, Banyak Toko bisa menyimpan 1 Produk, Banyak Produk bisa
disimpan di satu Toko.
Relasi antar tabelnya bisa kita gambar sebagai berikut :
Gambar 1. Hubungan relationship antar entity yang belum dioptimasi.
Relationship Redundant
Dari gambar diatas, kita melihat bahwa hubungan antara Pelanggan dan Produk dapat diwakili
oleh Penjualan. Relationship ini disebut Redundant. Relasi seperti ini bisa dihapus.
Hubungan Produk dan Penjualan yang berupa M:N (banyak ke banyak) pada prakteknya tidak
bisa dilakukan langsung. Tetapi harus dilakukan melalui tabel antara. Begitu juga antara Produk
dengan Toko. Untuk hubungan antara Produk dan Penjualan dapat dibuat tabel antara Penjualan
Detil. Sedangkan hubungan antara Produk dan Toko, dapat dibuat tabel antara Stok. Berikut
adalah model database yang telah diperbaiki:

3. Gambar 2.
Hubungan relationship antar entity yang sudah dioptimasi dengan menghapus relationship
redundant, dan tambahan 2 table: penjualan detail dan stok.
Mengidentifikasi Atribut
Elemen data yang ingin kita simpan dalam sebuah entitas disebut atribut. Contoh atribut pada
entitas Produk adalah nama produk, harga, tipe, pabrik. Pada Pelanggan, misanya nama dan
alamat. Pada Penjualan misalnya produk, tanggal, jumlah, dan seterusnya.
Data Turunan
Data turunan adalah data yang diturunkan dari data atribut lain yang sudah disimpan. Contoh
klasik dari data turunan misalnya ‘total penjualan’. Nilainya adalah total penjumlahan dari harga
barang dikali jumlah pembelian, dalam kurun waktu tertentu. Karena nilainya bisa terus berubah
seiring waktu, maka data turunan ini tidak perlu disimpan.
Memasang Primary Key
Primary Keys
Primary key (PK), atau kunci-utama, adalah satu atau lebih atribut yang mengidentifikasi entity
secara unik. Jika PK terdiri dari dua atau lebih atribut, maka ia disebut composite-key. Semua
atribut yang menjadi bagian dari PK harus memiliki nilai pada setiap record dan sifatnya harus
unik (tidak boleh ada yang sama). Contoh PK misalnya nomor pelanggan, kode barang, dan
seterusnya.
Dalam membangun relationship antar entitas, PK dipakai sebagai referensi. Contohnya, relasi
antara entitas Penjualan dan Penjualan-detil akan menggunakan PK Penjualan. Data atribut PK

4. Penjualan akan disimpan sebagai kolom pada pada entitas Penjualan-detil.
Keberadaan PK Penjualan dalam PK Penjualan-detil disebut Foreign Key.
Menentukan Tipe Data untuk Atribut
Setelah semua entitas dan relationship dibuat, proses berikutnya adalah menentukan tipe data.
Setiap database biasanya mempunyai tipe data sendiri-sendiri. Akan tetapi ada beberapa yang
sesuai standar. Misanya: CHAR, VARCHAR, TEXT, INT, FLOAT, dab DOUBLE.
The standard data types that every database knows, and are most-used, are: CHAR, VARCHAR,
TEXT, FLOAT, DOUBLE, and INT. Untuk database MySQL, akan dibahas pada bagian
berikutnya.
Cara Normalisasi Database
Normalilsasi adalah proses untuk akan menjaga agar data tetap mempunyai integritas yang baik
dengan menghilangkan kelompok data yang duplikat dan redundant. Normalisasi akan membuat
model data menjadi fleksible dan reliable.
Umumnya proses normalisasi dilakukan 3 tahap.
1. Normalisasi Pertama (1NF)
Aturan normalisasi pertama, kolom dari table harus bersifat atomik-value, artinya satu cell tidak
boleh menyimpan banyak nilai. Pada contoh dibawah, kolom Color menyimpan 2 nilai: red,
green dan yellow, blue. Untuk memenuhi normalisasi pertama, kolom Color harus
dikembangkan seperti Contoh 2.

5. Contoh 1. Tabel yang belum di normalisasi.
Contoh 2. Table yang memenuhi kriteria Normalisasi Pertama.
2. Normalisasi Kedua (2NF)
Aturan Normalisasi kedua adalah adalah:
a. Memenuhi semua syarat dari Normalisasi pertama.
b. Menghilangkan subset data yang terdapat pada banyak baris kemudian meletakkanya pada
table terpisah.
c. Membuat relasi antara tabel yang dipisah ini, dengan menggunakan Foreign Key.
Pada Contoh 3, kolom Purchase Location memiliki kolom dengan subset data yang berulang
yaitu Long Angeles (diulang 2x) dan San Fransisko (diulang 2x). Karena itu tabel harus dipecah
di buat relasi antara keduanya.

6. Contoh 3. Tabel belum memenuhi normalisasi kedua.
Contoh 4. Table yang telah memenuhi rule normalisasi kedua.
3. Normalisasi Ketiga (3NF)
Kriteria normalisasi ketiga:
a. Memenuhi kriteria normalisasi kedua.
b. Menghilangkan kolom yang tidak bergantung pada primary-key tabel tersebut.
Pada contoh di bawah ini, kolom GenreType tidak bergantung pada primary-key buku. Hanya
price yang bergantung pada buku. Karena itu GenreType harus dihilangkan dan dalam contoh
ini, dibuat menjadi table sendiri.

7. Contoh 5. Tabel yang belum sesuai normalisasi ketiga.
Contoh 6. Kolom GenreType dihilangkan karena tidak bergantung pada primary-key
buku. Pada contoh ini, dibuat tabel baru Table_Genre.