TUGAS 2 DAN TUGAS INDIVIDU

BASIS DATA

DI

OLEH :

DEDI PRAMANA
NIM.11950310418

UNIVERSITAS SAINS DAN TEKNOLOGI

FAKULTAS SAINS DAN TEKNOLOGI
2020
Bagian 1
 Bagian 2
Tabel Petugas – Didalam tabel ini nantinya akan kita simpan data petugas, petugas
dapat melakukan operasi-operasi tertentu sesuai dari definisi yang kita buat, jika ingin
dikembangkan nantinya setiap petugas perpustakaan mempunyai hak akses yang
berbeda-beda.

Tabel Anggota – Pada tabel anggota berisi data-data anggota perpustakaan yang
mempunyai hak untuk membaca buku yang tersedia diperpustakaan atau meminjam
dalam jangka waktu tertentu.

Tabel Buku – Pada tabel buku berisi deskripsi buku baik itu judul, pengarang penerbit
dan lainnya. Selain itu kita juga dapat mengetahui jumlah stok buku yang tersedia yang
dapat dipinjam.

Tabel Rak – Tabel rak nantinya berfungsi untuk memberikan informasi lokasi buku pada
setiap rak didalam perpustakaan tersebut.
Tabel Peminjaman – pada tabel ini nantinya akan disimpan data-data terkait
peminjaman buku.

Tabel Pengembalian – Memberikan informasi terkait pengembalian buku dan juga

besaran denda yang harus dibayar, jika melebihi dari batas waktu buku yang harus
dikembalikan.

Deskripsi Atribut Tabel

Deskripsi tabel menjelaskan bagaimana atribut yang tersusun didalam setiap tabel. masing-
masing tabel mempunyai atribut yang membentuk karakteristik/sifat yang melekat pada
sebuah tabel. Contohnya untuk tabel buku karakteristik yang melekat pada buku adalah
judul, nama pengarang dan penerbit. Berikut ini adalah keterangan setiap atribut atau field
pada masing-masing tabel:

Tabel Petugas

No Kolom Tipe Keterangan

1 id_petugas int(11) Primary Key, Auto Increment

2 nama_petugas varchar(50) Not Null

3 jabatan_petugas varchar(50) Not Null

4 no_telp_petugas char(13) –

5 alamat_petugas varchar(100) –
Tabel Anggota

No Kolom Tipe Keterangan

1 id_anggota int(11) Primary Key, Auto Increment

2 kode_anggota char(9) Unik, Not Null

3 nama_anggota varchar(100) Not Null

4 jk_anggota char(1) Not Null

5 jurusan_anggota char(2) Not Null

6 no_telp_anggota char(13) –

7 alamat_anggota varchar(100) –

Tabel Buku

No Kolom Tipe Keterangan

1 id_buku int(11) Primary Key, Auto Increment

2 kode_buku char(5) Unik, Not Null

3 judul_buku varchar(50) Not Null

4 penulis_buku varchar(50) Not Null

5 penerbit_buku varchar(50) –

6 tahun_penerbit char(4) –

7 stok int(11) –
Tabel Rak

No Kolom Tipe Keterangan

1 id_rak int(11) Primary Key, Auto Increment

2 nama_rak varchar(50) Not Null

3 lokasi_rak varchar(50) Not Null

4 id_buku int(11) Foreign Key

Tabel Peminjaman

No Kolom Tipe Keterangan

1 id_peminjaman int(11) Primary Key, Auto Increment

2 tanggal_pinjam date Not Null

3 tanggal_kembali date Not Null

4 id_buku int(11) Not Null

5 id_anggota int(11) Not Null

6 id_petugas int(11) Not Null

Tabel Pengembalian

No Kolom Tipe Keterangan

1 id_pengembalian int(11) Primary Key, Auto Increment

2 tanggal_pengembalian date Not Null

3 denda int(11) –

4 id_buku int(11) Not Null

5 id_anggota int(11) Not Null

6 id_petugas int(11) Not Null

Relasi Tabel

Relasi tabel adalah sesuatu yang menggambarkan hubungan antara tabel satu dengan
yang lain pada database. Relasi dibuat pada setiap atribut/field yang menjadi kunci utama
(primary key) pada sebuah tabel kemudian dihubungkan ke field kunci tamu (foreign key)
pada tabel lainnya. Syarat utamanya adalah field yang dijadikan kunci utama (primary key)
harus unik artinya tidak boleh ada data yang sama atau lebih dari satu (duplicate).

Berikut ini adalah contoh relasi tabel pada database perpustakaan:

 Relasi One to One, One to Many, Many to One, Many to Many

Entity Relationship 
A.    One To One Relation
Mempunyai pengertian setiap baris data pada tabel pertama dihubungkan hanya ke satu
baris data pada tabel ke dua. Hubungan antara file pertama dan file kedua adalah satu
berbanding satu. 
Contoh : 

 Pada pengajaran private satu guru satu siswa. 

 Seorang guru mengajar seorang siswa, Seorang siswa diajar oleh seroang guru.

Gambar :

B.     One To Many Relation

Mempunyai pengertian setiap baris data dari tabel pertama dapat dihubungkan ke satu baris
atau lebih data pada tabel ke dua. Hubungan antara file pertama dan file kedua adalah satu
berbanding banyak atau banyak berbanding satu. 
Contoh :

 Dalam satu perusahaan memperkerjakan banyak pegawai. 

 Satu bagian memperkerjakan banyak pegawai, Satu pegawai kerja dalam satu bagian.

                 Gambar :
 C.     Many To One Relation

Kebalikan dari relation One To Many dimana setiap baris data dari tabel pertama
dihubungkan lebih dari satu baris ke tabel kedua. Hubungan antara file pertama dan file
kedua adalah banyak berbanding satu. 
Contoh :

 Beberapa orang mengendarai satu mobil.

  Beberapa warga melakukan gotong royong di fasum.

                 Gambar :

D.    Many To Many Relation

Mempunyai pengertian Satu baris atau lebih data pada tabel pertama bisa dihubugkan ke
satu atau lebih baris data pada tabel ke dua. Artinya ada banyak baris di tabel satu dan
tabel dua yang saling berhubungan satu sama lain. Hubunga tabel pertama dan tabel kedua
adalah banyak berbanding banyak. 
Contoh :

 Dalam universitas seorang mahasiswa dapat mengambil banyak mata kuliah 

Satu mahasiswa banyak mengambil banyak mata kuliah dan satu mata kuliah diambil
banyak mahasiswa.

                 Gambar :
 Apa itu Entity Relationship Diagram (ERD)?

Basis data mutlak merupakan bagian integral dari sistem perangkat lunak. Untuk
sepenuhnya memanfaatkan Diagram ER dalam rekayasa basis data menjamin Anda untuk
menghasilkan desain basis data berkualitas tinggi untuk digunakan dalam pembuatan,
pengelolaan, dan pemeliharaan basis data. Model ER juga menyediakan sarana untuk
komunikasi.

Apa itu diagram ER (ERD)?

Pertama-tama, apa itu Diagram Hubungan Entitas?

Entity Relationship Diagram, juga dikenal sebagai ERD, ER Diagram atau model ER, adalah jenis

diagram struktural untuk digunakan dalam desain database. ERD berisi simbol dan konektor berbeda

yang memvisualisasikan dua informasi penting: Entitas utama dalam ruang lingkup sistem ,

dan hubungan antar entitas-entitas ini .

Dan itulah mengapa ini disebut diagram "Entity" "Relationship" (ERD)!

Ketika kita berbicara tentang entitas dalam ERD, sangat sering kita merujuk pada objek bisnis

seperti orang / peran (misalnya Siswa), objek bisnis berwujud (misalnya Produk), objek bisnis tidak

berwujud (misalnya Log), dll. "Hubungan" adalah tentang bagaimana entitas-entitas ini berhubungan

satu sama lain dalam sistem.

 Dalam desain ER yang khas, Anda dapat menemukan simbol seperti persegi panjang
bulat dan konektor (dengan gaya berbeda pada ujungnya) yang menggambarkan entitas,
atributnya, dan antar-hubungan.
Kapan menggambar Diagram ER?
Jadi, kapan kita menggambar ERD? Sementara model ER sebagian besar
dikembangkan untuk merancang database relasional dalam hal visualisasi konsep dan dalam
hal desain database fisik, masih ada situasi lain ketika diagram ER dapat membantu. Berikut
adalah beberapa kasus penggunaan umum.
 Desain basis data - Bergantung pada skala perubahan, berisiko mengubah struktur basis data
secara langsung dalam DBMS. Untuk menghindari penghancuran data dalam basis data produksi,
penting untuk merencanakan perubahan dengan hati-hati. ERD adalah alat yang membantu. Dengan
menggambar diagram ER untuk memvisualisasikan ide-ide desain database, Anda memiliki
kesempatan untuk mengidentifikasi kesalahan dan kelemahan desain, dan untuk membuat koreksi
sebelum mengeksekusi perubahan dalam database.
 Basis data debug - Untuk men-debug masalah-masalah basis data dapat menjadi tantangan,
terutama ketika database berisi banyak tabel, yang membutuhkan penulisan SQL kompleks dalam
mendapatkan informasi yang Anda butuhkan. Dengan memvisualisasikan skema database dengan
ERD, Anda memiliki gambaran lengkap dari seluruh skema database. Anda dapat dengan mudah
menemukan entitas, melihat atributnya dan mengidentifikasi hubungan yang mereka miliki dengan
orang lain. Semua ini memungkinkan Anda untuk menganalisis basis data yang ada dan untuk
mengungkapkan masalah basis data dengan lebih mudah.
 Pembuatan dan penambalan basis data - Paradigma Visual, alat ERD, mendukung alat
pembuatan basis data yang dapat mengotomatiskan proses pembuatan dan penambalan basis data
melalui diagram ER. Jadi, dengan alat Diagram ER ini, desain ER Anda tidak lagi hanya diagram
statis tetapi cermin yang benar-benar mencerminkan struktur basis data fisik.
 Bantuan dalam pengumpulan persyaratan - Tentukan persyaratan sistem informasi dengan
menggambar ERD konseptual yang menggambarkan objek bisnis tingkat tinggi dari sistem. Model
awal seperti itu juga dapat dikembangkan menjadi model basis data fisik yang membantu pembuatan
basis data relasional, atau bantuan dalam pembuatan peta proses dan mode aliran data.
Panduan notasi ERD
Diagram ER berisi entitas, atribut, dan hubungan. Di bagian ini, kita akan membahas
simbol ERD secara terperinci.
 Kesatuan
Entitas ERD adalah hal atau konsep yang dapat didefinisikan dalam suatu sistem ,
seperti orang / peran (misalnya Siswa), objek (misalnya Faktur), konsep (misalnya Profil)
atau peristiwa (misalnya Transaksi) (catatan: Dalam ERD, istilah " entitas "sering digunakan
sebagai ganti" tabel ", tetapi keduanya sama). Saat menentukan entitas, anggaplah mereka
sebagai kata benda. Dalam model ER, suatu entitas ditampilkan sebagai persegi panjang
bulat, dengan namanya di atas dan atributnya terdaftar di tubuh bentuk entitas. Contoh ERD
di bawah ini menunjukkan contoh entitas ER.

Atribut Entitas
Juga dikenal sebagai kolom, atribut adalah properti atau karakteristik entitas yang

menyimpannya .

Atribut memiliki nama yang menggambarkan properti dan tipe yang menggambarkan jenis

atributnya, seperti varchar untuk sebuah string, dan int untuk integer. Ketika ERD dibuat untuk

pengembangan basis data fisik, penting untuk memastikan penggunaan tipe yang didukung oleh

RDBMS target.

Contoh diagram ER di bawah ini menunjukkan entitas dengan beberapa atribut di dalamnya.

Kunci utama

Juga dikenal sebagai PK, kunci utama adalah jenis khusus dari atribut entitas yang secara unik

mendefinisikan catatan dalam tabel database . Dengan kata lain, tidak boleh ada dua (atau lebih) catatan

yang memiliki nilai yang sama untuk atribut primary key. Contoh ERD di bawah ini menunjukkan
entitas 'Produk' dengan atribut kunci primer 'ID', dan pratinjau catatan tabel dalam database. Catatan

ketiga tidak valid karena nilai ID 'PDT-0002' sudah digunakan oleh catatan lain.

Kunci asing

Juga dikenal sebagai FK, kunci asing adalah referensi ke kunci utama dalam sebuah tabel . Ini

digunakan untuk mengidentifikasi hubungan antar entitas. Perhatikan bahwa kunci asing tidak harus

unik. Beberapa catatan dapat berbagi nilai yang sama. Contoh Diagram ER di bawah ini menunjukkan

entitas dengan beberapa kolom, di antaranya kunci asing digunakan dalam referensi entitas lain.

Hubungan
Hubungan antara dua entitas menandakan bahwa kedua entitas tersebut saling terkait satu sama

lain . Misalnya, seorang siswa dapat mendaftar dalam suatu kursus. Entitas Siswa karena itu terkait

dengan Kursus, dan hubungan disajikan sebagai penghubung yang menghubungkan antara mereka.
Kardinalitas

Kardinalitas mendefinisikan kemungkinan jumlah kejadian dalam satu entitas yang dikaitkan

dengan jumlah kejadian di entitas lain . Misalnya, SATU tim memiliki pemain BANYAK. Saat hadir

dalam ERD, entitas Tim dan Pemain saling terhubung dengan hubungan satu-ke-banyak.

Dalam diagram ER, kardinalitas direpresentasikan sebagai kaki gagak di ujung konektor. Tiga

hubungan kardinal yang umum adalah satu-ke-satu, satu-ke-banyak, dan banyak-ke-banyak.

 Contoh kardinalitas satu-ke-satu

Hubungan satu-ke-satu sebagian besar digunakan untuk membagi entitas menjadi dua untuk

memberikan informasi secara ringkas dan membuatnya lebih dimengerti. Gambar di bawah ini

menunjukkan contoh hubungan satu-ke-satu.

Contoh kardinalitas Satu-ke-Banyak

Hubungan satu-ke-banyak mengacu pada hubungan antara dua entitas X dan Y di mana sebuah

instance X dapat dihubungkan ke banyak instance Y, tetapi sebuah instance Y terkait hanya dengan satu

instance X. Gambar di bawah ini menunjukkan contoh hubungan satu-ke-banyak.

Contoh kardinalitas Banyak ke Banyak

Hubungan banyak-ke-banyak mengacu pada hubungan antara dua entitas X dan Y di mana X

dapat dikaitkan dengan banyak contoh Y dan sebaliknya. Gambar di bawah ini menunjukkan contoh

hubungan banyak-ke-banyak. Perhatikan bahwa hubungan banyak ke banyak dibagi menjadi sepasang

hubungan satu ke banyak dalam ERD fisik. Anda akan tahu apa ERD fisik di bagian selanjutnya.
 Model data konseptual, Logis, dan Fisik
Model ER biasanya digambar hingga tiga tingkat abstraksi:
 ERD Konseptual / model data Konseptual
 ERD logis / Model data logis
 ERD Fisik / Model data fisik

Sementara ketiga level model ER berisi entitas dengan atribut dan hubungan, mereka berbeda

dalam tujuan mereka diciptakan dan audiensi yang mereka targetkan.

Fitur ERD Konseptual Logis Fisik

Nama kesatuan) Iya Iya Iya

Hubungan Iya Iya Iya

Kolom Iya Iya

Jenis Kolom Pilihan Iya

Kunci utama Iya

Kunci asing Iya

Pemahaman umum terhadap tiga model data adalah bahwa analis bisnis menggunakan model

konseptual dan logis untuk memodelkan objek bisnis yang ada dalam sistem, sementara perancang basis

data atau insinyur basis data menguraikan model ER konseptual dan logis untuk menghasilkan model

fisik yang menyajikan fisik. struktur basis data siap untuk pembuatan basis data. Tabel di bawah ini

menunjukkan perbedaan antara ketiga model data.

Model konseptual vs Model logis vs Model data:

Model data konseptual

ERD konseptual memodelkan objek bisnis yang harus ada dalam suatu sistem dan hubungan di

antara mereka . Model konseptual dikembangkan untuk menyajikan gambaran keseluruhan sistem

dengan mengenali objek bisnis yang terlibat. Ini mendefinisikan entitas apa yang ada, BUKAN tabel

mana. Sebagai contoh, tabel 'banyak ke banyak' mungkin ada dalam model data logis atau fisik tetapi

mereka hanya ditampilkan sebagai hubungan tanpa kardinalitas di bawah model data konseptual.
 Contoh model data konseptual

CATATAN: ERD Konseptual mendukung penggunaan generalisasi dalam pemodelan hubungan

'semacam' antara dua entitas, misalnya, Segitiga, adalah semacam Bentuk. Penggunaannya seperti

generalisasi di UML. Perhatikan bahwa hanya ERD konseptual yang mendukung generalisasi.

Model data logis

ERD logis adalah versi detail dari ERD Konseptual . Model ER logis dikembangkan untuk

memperkaya model konseptual dengan mendefinisikan secara eksplisit kolom di setiap entitas dan

memperkenalkan entitas operasional dan transaksional. Meskipun model data logis masih independen

dari sistem database aktual di mana database akan dibuat, Anda masih bisa mempertimbangkannya jika

itu mempengaruhi desain.

Model data fisik

Fisik ERD merupakan cetak biru desain aktual dari database relasional . Model data fisik

menguraikan model data logis dengan menetapkan setiap kolom dengan jenis, panjang, nullable, dll.

Karena ERD fisik menunjukkan bagaimana data harus disusun dan terkait dalam DBMS tertentu,

penting untuk mempertimbangkan konvensi dan pembatasan sistem basis data aktual di mana basis data
akan dibuat. Pastikan jenis kolom didukung oleh DBMS dan kata-kata yang dipesan tidak digunakan

dalam penamaan entitas dan kolom.

Cara menggambar diagram ER?

Jika Anda merasa sulit untuk memulai dengan menggambar diagram ER, jangan khawatir. Di

bagian ini, kami akan memberikan Anda beberapa tips ERD. Coba ikuti langkah-langkah di bawah ini

untuk memahami cara menggambar diagram ER secara efektif.

1. Pastikan Anda jelas tentang tujuan menggambar ERD. Apakah Anda mencoba
menyajikan arsitektur sistem secara keseluruhan yang melibatkan definisi objek bisnis? Atau apakah
Anda mengembangkan model ER yang siap untuk pembuatan basis data? Anda harus jelas tentang
tujuan untuk mengembangkan diagram ER pada tingkat rincian yang tepat (Baca bagian Model Data
Konseptual, Logikan dan Fisik untuk lebih jelasnya)
2. Pastikan Anda jelas tentang cakupan model. Mengetahui ruang lingkup pemodelan
mencegah Anda memasukkan entitas yang berlebihan dan hubungan dalam desain Anda.
3. Gambar entitas utama yang terlibat dalam ruang lingkup.
4. Tentukan properti entitas dengan menambahkan kolom.
5. Tinjau ERD dengan hati-hati dan periksa apakah entitas dan kolom cukup untuk
menyimpan data sistem. Jika tidak, pertimbangkan untuk menambahkan entitas dan kolom
tambahan. Biasanya, Anda dapat mengidentifikasi beberapa entitas transaksional, operasional, dan
peristiwa dalam langkah ini.
6. Pertimbangkan hubungan antara semua entitas dan hubungkan mereka dengan
kardinalitas yang tepat (mis. Satu-ke-banyak antara entitas Pelanggan dan Pesanan). Jangan khawatir
jika ada entitas yatim. Meskipun tidak umum, itu sah.
7. Menerapkan teknik normalisasi basis data untuk menyusun kembali entitas dengan cara
yang dapat mengurangi redundansi data dan meningkatkan integritas data. Misalnya, rincian pabrikan
mungkin disimpan di bawah entitas Produk pada awalnya. Selama proses normalisasi, Anda mungkin
menemukan bahwa detail terus mengulang catatan dari catatan, lalu Anda dapat membaginya sebagai
Produsen entitas terpisah, dan dengan kunci asing yang menghubungkan antara Produk dan Produsen.
Contoh model data
Contoh ERD - Sistem Penyewaan Film
 Contoh ERD - Toko Online

Menggunakan ERD dengan Data Flow Diagram (DFD)

Dalam analisis dan desain sistem, Data Flow Diagram (DFD)  dapat ditarik
untuk memvisualisasikan aliran informasi dalam proses sistem. Di Data Flow
Diagram, ada simbol yang disebut Data Store, yang mewakili tabel database
yang menyediakan informasi yang dibutuhkan oleh sistem.
 Karena Diagram ER fisik menyediakan cetak biru dari database aktual,
entitas dalam ERD tersebut disejajarkan dengan datastore dalam DFD. Anda
dapat menggambar ERD sebagai pelengkap DFD dengan mewakili struktur
informasi yang mengalir dalam suatu sistem, atau, sebaliknya, untuk
menggambar DFD dalam melengkapi ERD dengan menunjukkan bagaimana data
akan digunakan oleh sistem dalam runtime.

Menggunakan ERD dengan BPMN Business Process

Diagram (BPD)
Dalam pemetaan proses bisnis, BPMN Business Process Diagram
(BPD) dapat ditarik untuk memvisualisasikan alur kerja bisnis. Dalam Diagram
Proses Bisnis, ada simbol yang disebut Data Object, yang mewakili input data ke
/ output dari kegiatan proses.
 Karena model data konseptual dan logis memberikan pandangan tingkat
tinggi dari objek bisnis dalam suatu sistem, entitas dalam ERD tersebut selaras
dengan objek data dalam BPD. Anda dapat menggambar ERD sebagai pelengkap
BPD dengan mewakili struktur objek data yang dibutuhkan oleh alur kerja
bisnis, atau, sebaliknya, untuk menarik BPD dalam melengkapi ERD dengan
menunjukkan bagaimana data akan digunakan selama proses bisnis.

Memilih alat ERD

Dibutuhkan waktu dan upaya untuk mengembangkan model data dengan
ERD. Alat desain database yang bermanfaat harus dapat mengurangi waktu dan
upaya Anda. Paradigma Visual memberi Anda tidak hanya alat ERD tetapi juga
serangkaian fitur pemodelan visual yang membantu Anda menggambar lebih
cepat dan lebih mudah. Ini mendukung sebagian besar sistem manajemen basis
data relasional populer di pasar saat ini baik dalam hal desain basis data,
pembuatan basis data, dan pembalikan ERD.

Perancang ERD tersedia dalam Visual Paradigm Modeler  , yang

harganya hanya US $ 6 per bulan  . Kami sarankan Anda mengunduh dan
mencoba . Ditawarkan 30 hari evaluasi GRATIS. Tidak diperlukan kartu kredit.

Desain Skema Database

Menentukan Primary Key

 Misalnya kita akan menyimpan data pegawai dalam tabel  m_pegawai .
Informasi pegawai memiliki beberapa data sebagai berikut:

 nip (nomor induk pegawai), dijamin unik karena tiap pegawai pasti
beda.
 nama, tidak unik. Agus, Budi, Cahyo biasanya banyak yang pakai.
 email, juga unik. Tidak mungkin satu email dipake rame-rame.

Dari ketiga data di atas, hanya dua yang bisa jadi primary key
yaitu  nip  dan  email , karena secara proses bisnis, nilainya harus unik di tiap
record pegawai. Kedua data ini, bila kita pilih salah satunya menjadi primary
key, maka disebut dengan istilah natural key, artinya primary key yang
diambil dari data yang memang sudah ada.

Selain natural key, kita juga bisa membuat data lain yang tidak berkaitan
dengan proses bisnis. Misalnya menambahkan primary key berupa
kolom  id  di tabel pegawai yang nilainya kita konfigurasi supaya bertambah
satu (increment) tiap ada record baru yang dimasukkan ke tabel.
Kolom  id  ini disebut dengan istilah surrogate key.

Natural vs Surrogate

Keuntungan kita menggunakan natural key adalah, datanya sudah ada.

Dengan demikian kita tidak perlu menambah kapasitas penyimpanan untuk
satu kolom khusus primary key.

Kerugian dari natural key adalah nilainya bisa berubah. Sebagai contoh, bila
perusahaan merger, maka nilai  nip  bisa dipastikan akan menyesuaikan
dengan perusahaan lain yang dimerger. Bisa formatnya ikut perusahaan lain
tersebut, dan bisa juga membuat format baru sesuai kesepakatan bersama.

Kalau gitu, email saja yang jadi primary key.

Email justru lebih sering berubah. Gak perlu merger, cukup ada layanan yang
menawarkan kapasitas lebih besar, orang langsung bikin akun email baru.

Lalu memangnya kenapa kalau berubah?

Yang namanya primary key, akan digunakan di tabel lain sebagai foreign key.
Apalagi untuk tabel master, pasti dia akan direlasikan di berbagai tabel
lainnya. Jika primary key berubah, maka semua tabel lain harus ikut diupdate
isi foreign key-nya. Ini akan membutuhkan locking yang luas karena harus
 meliputi banyak tabel sekaligus. Semakin luas locking, semakin lemot
performance, karena proses lain harus antri mendapatkan lock.

Masalah kedua, penggunaan natural key cenderung akan mengarah pada

penggunaan compound/composite key, yaitu primary key yang terdiri dari
dua atau lebih kolom. Ini akan lebih merepotkan lagi, karena foreign key dari
composite key juga akan terdiri dari dua/lebih kolom.

Kekurangan dari surrogate key adalah ada tambahan space harddisk untuk
menyimpan data kolom tambahan. Juga tambahan space untuk membuat
index dari natural key (yang seharusnya otomatis terindex bila dia menjadi
primary key).

Lalu, sebaiknya pakai natural key atau surrogate key?

Saya selalu pakai surrogate key. Sebabnya karena space harddisk semakin
lama semakin murah, sedangkan locking problem dan composite key akan
memakan mandays programmer yang semakin lama semakin mahal.

Strategi Key Generator

Karena nilai dari surrogate key tidak berhubungan dengan data yang
diwakilinya, maka kita bisa melakukan optimasi dalam pemilihan algoritma
untuk menghasilkan nilai baru. Ada beberapa strategi yang biasa digunakan:

 Auto increment / sequence. Cara ini disebut dengan berbagai istilah,

misalnya AUTO_INCREMENT (MySQL), SEQUENCE (Oracle), SERIAL
(PostgreSQL), IDENTITY (MS SQL Server), AutoNumber (MS Access), dan
lainnnya. Intinya adalah penggunaan tipe data integer yang nilainya
bertambah terus.
 UUID / GUID. Tipe datanya 32 karakter alfanumerik, bisa diwakili di
database dengan CHAR atau VARCHAR.

Pilih yang mana?

Saya biasa pakai UUID, karena dia dijamin unik siapapun yang menjalankan
generator. Ini akan sangat berguna dalam skenario database terdistribusi
seperti ini.

Misalnya database kita split menjadi database kantor pusat dan kantor
cabang. Masing-masing cabang insert data transaksi ke database yang ada di
kantor cabang. Pada sore hari, database cabang diupload ke kantor pusat
dan digabungkan ke database pusat, bersama-sama dengan data transaksi
dari cabang lain.

Bila kita menggunakan sequence, akan terjadi duplikasi primary key, karena
masing-masing cabang memulai sequence dari angka 1. Cabang A akan
punya data 1 - 100, demikian juga cabang-cabang lain.

Lain halnya bila kita menggunakan UUID. Nilai yang dihasilkan oleh cabang
A dijamin berbeda dengan nilai yang dihasilkan cabang B. Dengan demikian,
kita tinggal insert data cabang A dan cabang B ke database pusat tanpa ada
primary key yang bentrokan.

Tabel Transaksi
Sekarang kita beranjak ke tabel untuk menyimpan data transaksi.

Pola yang umum dipakai adalah relasi  master-detail-header  seperti ini

Pola ini bisa kita gunakan untuk aplikasi perpustakaan seperti ini
 Ataupun untuk aplikasi bengkel, dimana detailnya ada dua (part dan jasa)

Pola yang sama bisa digunakan dalam pencatatan transaksi lain, misalnya:

 jurnal akuntansi : jurnal_header berisi tanggal dan keterangan,

jurnal_detail berisi id_akun, debet/kredit, dan nilai nominal
 transaksi di minimarket : transaksi_header berisi tanggal dan nama
kasir, transaksi_detail berisi id_produk, qty, harga_satuan
 keluar/masuk barang di gudang : transaksi_header berisi tanggal,
transaksi_detail berisi id_barang, qty
 dan sebagainya

Identifying Relationship

Pembaca yang teliti akan melihat bahwa garis penghubung relasi

antara  header  dan  detail  berbeda dengan  detail  dan  master .  Header-
detail  garisnya menyambung sedangkan  detail-master  putus-putus. Garis
tersambung disebut dengan istilah identifying relationship, yaitu hubungan
parent-child. Artinya, kalau induknya (record di tabel header) dihapus, maka
anaknya (record di tabel detail) juga harus dihapus karena sudah tidak
relevan lagi.

Berbeda dengan master-detail. Kalau masternya dihapus, belum tentu data

transaksinya juga ikut dihapus. Bisa jadi relasinya cuma diset
menjadi  NULL  saja, tapi datanya tetap ada dan tetap bisa dihitung.

Tabel Akumulasi
Terakhir, kita bahas tentang tabel akumulasi. Tabel ini sebetulnya tidak
wajib dibuat. Kita membuat tabel ini terutama untuk alasan performance.

Misalnya kita ingin menampilkan data jumlah stok buku di satu hari tertentu.
Atau kita ingin mencari berapa jumlah barang yang tersisa untuk satu jenis
barang tertentu.

Tanpa tabel akumulasi, kita harus mencari dulu saldo awalnya, kemudian kita
melakukan penjumlahan berapa penambahan dan pengurangan selama
periode bisnis berjalan. Kalau bisnisnya baru jalan 3 hari tidak masalah, tapi
bagaimana kalau sudah jalan 3 tahun? Tentu ada jutaan record yang harus
dijumlahkan oleh database dalam sekali request. Bagaimana kalau usernya
banyak?

Untuk mengatasinya, kita buat tabel untuk akumulasi. Berikut skemanya

 Penjelasan kolomnya sebagai berikut:

 id : surrogate key
 id_xx : relasi ke tabel master barang/akun/produk/dsb
 tanggal : supaya memudahkan, kita buat satu record per hari
 saldo_awal : nilai di awal hari
 debet : penambahan nilai dalam hari itu
 kredit : pengurangan nilai dalam hari itu

Kok gak ada saldo akhir?

Ya kan tinggal dihitung saja. Saldo akhir = saldo awal + debet - kredit.
Gampang kan?
 Ada dua pilihan metode dalam mengisi tabel akumulasi ini:

1. Diupdate setiap insert transaksi. Jika menggunakan metode ini, jangan

lupa menggunakan database transaction untuk menjaga konsistensi data.
2. Diupdate secara batch di akhir hari. Jika menggunakan metode ini,
jangan lupa memasang lock supaya tidak ada orang yang insert record baru
pada saat kita sedang menghitung akumulasi. Biasanya kalau trafiknya tinggi
dan harus selalu online (seperti ATM bank), perlu menggunakan teknik
shadow balance supaya transaksi bisa terus jalan walaupun batch update
sedang berjalan.

Kesimpulan
Poin penting yang bisa diambil dari artikel ini:

 natural key vs surrogate key

 pola master-detail-header
 pola master-akumulasi
Database seperti apa yang bisa di normalisasi?

Tentunya tidak semua database, hanya tipe “relational database” bisa di normalisasi.

banyak vendor DBMS (database management system) diantaranya Oracle, MySql,

SqlServer, PostgreeSQL dan masih banyak lagi.

Bagaimana cara melakukan normalisasi database?

Untuk melakukan normalisasi database kita harus mengidentifikasi seperti apa

bentuk data yang yang saat ini di simpan. Sebagai contoh, saya punya data pembelian

tiket nonton bioskop.

Contoh data di atas merupakan data yang belum dinormalisasi, untuk selanjutnya

tahap normalisasi 1NF

1NF

Suatu tabel dikatakan 1NF jika dan hanya jika setiap setiap atribut dari

data tersebut hanya memiliki nilai tunggal dalam satu baris.

Jadi tabel yang belum normal tadi perlu diubah, sehingga bentuk 1NF menjadi seperti

ini:
Intinya pada tahap 1NF ini tidak diperbolehkan ada grouping data ataupun duplikasi

data. Tahap selanjutnya 2NF

2NF

Syarat 2NF adalah tidak diperkenankan adanya partial “functional

dependency” kepada primary key dalam sebuah tabel.

Apa itu “functional dependency”?

Itu adalah batasan keterkaitan antara 2 attribut dalam suatu tabel (pasti banyak yang

bingung).

Intinya adalah pada 2NF ini tabel tersebut harus dipecah berdasarkan primary key.

Sehingga bentuk 2NF dari tabel tersebut ialah sebagai berikut.

Setelah dinormalisasi 2NF, tabelnya terpecah menjadi 4. Tahap selanjutnya ialah

3NF.
3NF

Pada 3NF tidak diperkenankan adanya partial “transitive

dependency” dalam sebuah tabel.

Apa itu “transitive dependency”?

Transitive dependency merupakan functional dependency yang berdasarkan sifat

transitifitas. (pasti bingung juga).

Intinya adalah pada 3NF ini, jika terdapat suatu atribut yang tidak bergantung pada

primary key tapi bergantung pada field yang lain maka atribut-atribut tersebut perlu

dipisah ke tabel baru.

Contohnya ada pada atribut “keterangan_member”, field tersebut bergantung pada

yang bukan merupakan primary key field “tipe_member”. Jadi setelah di normalisasi

3NF ialah sebagai berikut: