Applied Database II

1
Basis Data Praktis

• Applied Database II

2
Overview

• Pengertian dan studi mengenai key
• Tabel dan relasinya
• Normalisasi basisdata
• Personal yang terlibat dalam pemanfaatan sistem
  basisdata dan tugasnya

3
KEY

• Menunjukkan identitas sebuah data dalam tabel,
  sebuah "row" unik
• Jenis key dalam suatu rekaman
• Primary key
• Secondary key
• Foreign key
• Key dapat dibentuk oleh sebuah data element
  tunggal, atau merupakan komposisi dari beberapa
  data element (composite key)

4
Primary Key

• Kunci, identifikasi unik sebuah rekaman yang
  berciri sama (misalnya sebuah row dalam tabel
  basis data relasional). Biasanya primary key
  mewakili sebuah entitas. sebuah entitas yang
  dalam dunia nyata sama, sebaiknya mempunyai
  identifikasi yang sama. Contoh NIM (mahasiswa),
  NIP (pegawai).
• Diperlukan untuk proses add, update, delete sebab
  menunjukkan ciri unik yang diubah
• Bagaimana dengan tabel yang tidak mempunyai
  primary key? Maka Semua kolom menjadi key atau
  akan duplikasi data.
• Perancangan primary key sangat penting
• Primary key (ciri unik dalam tabel) mungkin
  terdiri dari beberapa field

5
Secondary and Foreign Key

• Secondary key
• Ciri lain untuk mengidentifikasi rekaman, tidak
  harus unik. Misalnya untuk mengidentifikasi
  sekelompok orang dalam department yang sama.
• Foreign key adalah sebuah data element pada
  sebuah rekaman, yang merupakan primary key di
  tempat lain. Gunanya untuk integritas/koherensi
  data.

6
Pengkodean Key (1/2)

• Key biasanya dikode, untuk menjaga konsistensi
  dan keunikannya
• Kode harus menjamin kelanggengan
• Informasi yang sering berubah sebaiknya bukan
  dikode, melainkan disimpan sebagai atribut
• Contoh
• Kode Pegawai (NIP atau id_pegawai) sebaiknya
  hanya mengandung hal yang tetap. Jika mengandung
  kode Department tempat kerja, dan pegawai
  dimungkinkan untuk pindah department, maka akan
  menyulitkan. Sebaiknya department dijadikan
  atribut tabel kode, dan bukan bagian dari
  id_pegawai

7
Pengkodean Key (2/2)

• Kode yang merepresentasi identitas mahasiswa
  (id_mahasiswa) dan dipakai sebagai primary key
  dengan sistem pengkodean sebagai berikut, dan
  semua elemen numerik XXYYSNNN
• XX Kode Jurusan studi (01 s/d 27)
• YY dua digit terakhir tahun masuk (00, 01, dst)
• S Strata (1/2/3)
• NNN nomor urut (satu jurusan studi maksimal
  mempunyai 999 mahasiswa)
• Kode tersebut akan menyulitkan jika seorang
  mahasiswa
• boleh pindah jurusan, maka harus diberi
  id_mahasiswa baru.
• melanjutkan ke S2, maka harus mempunyai
  id_mahasiswa baru (padahal orangnya sama)

8
Relasi antar Tabel

• Key dipakai untuk menentukan relasi antar tabel
  basis data

Master_2
Relasi
Master_1
Master_x
Referensi
Master
Detail
History
Transaksi periodik
Transaksi per kejadian
Detail dari Detail
9
Jenis Table

• Referensi
• Biasanya berisi kode-kode dan deskripsinya. Jika
  referensi "kecil-kecil", biasanya disatukan
  menjadi sebuah tabel referensi.
• Dari segi isinya, tabel referensi "mirip" master,
  khusus untuk kode-kode
• Primary Key ? id_ref

10
Jenis Table (2)

• Master
• Berisi data induk dari entitas penting
• Primary Key ? id_master
• Relasi
• Relasi antar master
• PK ? Id semua master yang berelasi ?
• id_master id_master1 id_master_2

11
Jenis Table (3)

• Detail
• Jika sebuah master mempunyai banyak "rows" yang
  berelasi dengan master tsb, biasanya disimpan
  dalam tabel detail. Con
• Seorang pegawai mempunyai 1-N anak
• Seorang pegawai mengikuti 1-N kursus
• Sebuah barang mempunyai 1-N supplier
• Sebuah negara mempunyai banyak propinsi
• PK ? id_masterid_detail

12
Jenis Table (4)

• Detail dari detail
• Jika detail mempunyai lebih dari satu informasi
  dengan key tertentu, misalnya
• detail kursus pegawai sebuah kursus yang
  diikuti masih mempunyai beberapa modul
• sebuah propinsi masih mempunuai beberapa
  kabupaten
• PK ? id_masterid_detailidDetaildetail

13
Jenis Table (5)

• Transaksi periodik
• data yang secara periodik berelasi dengan master.
  Contoh
• Tabel absensi yang merupakan kehadiran pegawai
  per hari (untuk setiap tanggal, ada status
  kehadiran)
• Tabel log book pencatatan produksi setiap shift
  (tgl, shift_ke) dicatat banyaknya barang yang
  diproduksi
• PK ? id_masterid_waktu

14
Jenis Table (6)

• Transaksi per kejadian
• Data yang berelasi dengan master, tetapi tidak
  secara periodik (artinya hanya per kejadian),
  misalnya
• data kecurian barang
• data kerusakan
• PK ? id_masterid_kejadian

15
Jenis Table (7)

• History
• Data yang sudah tidak dikehendaki disimpan dalam
  database yang aktif.
• Ada dua type tabel history
• Strukturnya sama dengan data asli (dapat berupa
  master, detail, atau yang lain). Jika "strict"
  key yang muncul di tabel aktif tidak boleh muncul
  di tabel history.
• Tabel history yang menyimpan semua sejarah
  perubahan ingin disimpan, maka disebut history,
  misalnya history golongan pegawai. Dalam hal ini,
  sebenarnya dikategorikan sebagai "transaksi".
• PK ?
• Type 1 sama dengan tabel asal
• Type 2 id_asalid_history

16
Notes

• Definisi di atas adalah definisi yang diberikan
  dalam kuliah ini.
• Panah (garis berarah) dalam skema artinya "Refer
  to"
• Sebuah master mungkin akan berelasi dengan master
  lain, yaitu 1-N sehingga sebuah master menjadi
  detail dari master yang lain, atau terjadi tabel
  relasi antar master
• Sebenarnya, detail dengan transaksi dari sudut
  pandang key sama saja, mewakili relasi 1-N. Tapi
  dibedakan karena biasanya transaksi mengandung
  info mengenai waktu (keynya tanggal)

17
Normalisasi data

• Salah satu hal yang penting untuk diperhatikan
  dalam perancangan basisdata dalah basisdata yang
  normal
• Bagaimanakah bentuk basis data yg normal?
• 1NF
• 2NF
• 3NF
• BCNF

18
Pertimbangan Praktis dalam Perancangan Tabel (1)

• Untuk mendapatkan basisdata yang benar-benar
  normal, harus dilakukan translasi secara
  sistematis dari E-R diagram setiap entity
  menjadi sebuah tabel, dan setiap relasi juga
  menjadi sebuah tabel dengan key yang sudah
  dirancang.

19
Pertimbangan Praktis dalam Perancangan Tabel (2)

• Seringkali basisdata yang 100 normal justru
  tidak dikehendaki karena beberapa alasan
• Jika semua tabel ditranslasi otomatis dari E-R
  dengan aturan di atas, maka jumlah tabel akan
  "meledak". Maka, beberapa relasi/tabel mungkin
  saja "dilebur" menjadi sebuah tabel. Biasanya,
  relasi yang atributnya hanya key, akan
  dilebur/ditipkan ke salah satu tabel. Contoh
• kode_agama yang dititpkan sebagai field dalam
  tabel pegawai, karena relasi Pegawai dengan Agama
  tidak membutuhkan atribut lain
• tanggal yang sebenarnya merupakan entity,
  dijadikan atribut langsung. Sebenarnya, tanggal
  lahir seseorang merupakan relasi antara kalender
  dengan orang
• Seringkali basisdata sangat normal mempenalti
  performansi

20
Pertimbangan Praktis dalam Perancangan Tabel (3)

• Tabel yang normal, karena beberapa alasan,
  dipecah menjadi lebih dari satu tabel, misalnya
  karena DBMS yang menangani tidak optimal untuk
  tabel yang kolomnya terlalu banyak
• Nama entitas yang disimpan sebaiknya mengikuti
  pedoman yang ditentukan. Misalnya nama tabel
  diawali t_ nama View diawali dengan v_ .
• Nama field sebaiknya dirancang dengan
  konvensi/peraturan yang baku, dan tidak
  diubah-ubah. Field yang merujuk ke entitas yang
  sama, sebaiknya nama field-nya sama. Biasakan
  memakai prefiks untuk mengenali type field, atau
  mengenali semantik (artinya), mengenalinya
  sebagai key. Jika perusahaan mempunyai standard,
  semua perancang harus mengikuti standard tersebut

21
Pertimbangan Praktis dalam Perancangan Tabel (4)

• Primary key untuk entitas penting sebaiknya tidak
  pernah dipakai ulang untuk entitas lain.
• Contoh NIP pegawai atau NIM mahasiswa, karena
  mewakili seorang pegawai atau seorang mahasiswa,
  maka sebaiknya NIM yang sama di dunia nyatanya
  adalah mahasiswa/orang yang sama. Banyak
  persoalan timbul karena sistem tidak dirancang
  dengan identitas unik ini, misalnya sistem KTP di
  Indonesia. Lihat bahasan mengenai kode
• Untuk primary key yang menyatakan identitas
  seperti pada butir di atas), operasi delete
  secara fisik dan online secara langsung harus
  dihindari. Harus dirancang sebuah atribut status
  record, dan penghapusan dari basis data jika
  memang diperlukan karena alasan space digantikan
  dengan pemindahan, dilakukan secara "batch" oleh
  petugas khusus

22
Pertimbangan Praktis dalam Perancangan Tabel (5)

• Jika dimungkinkan pendefinisian domain (nama
  type), sebaiknya dipakai sebab menghindari
  inkonsistensi.
• Contoh jika sudah sepakat bahwa semua field yang
  isinya uang batasannya tertentu, maka sebaiknya
  didefinisikan domain bernama "Uang" untuk menjaga
  konsistensi lebar field dan banyaknya digit.
  Fasilitas ini tersedia di beberapa DBMS besar
  seperti Oracle Designer.
• Struktur tabel biasanya dirancang dan sebaiknya
  tidak diubah. Jika diinginkan tambahan informasi,
  lebih sering dilakukan penambahan tabel baru dan
  direlasikan ke tabel yang ada karena dengan cara
  ini, kita tidak perlu mengubah struktur dan
  relasi yang sudah ada (dan seringkali program
  aplikasi yang sudah ada). Solusi ini seringkali
  lebih dilakukan daripada mengubah struktur tabel

23
Pertimbangan Praktis dalam Perancangan Tabel (6)

• Selain adanya key, seringkali identitas asal
  record penting untuk didefinisikan dan dicatat,
  terutama untuk data yang penting. Setiap row
  tabel mengandung id_user (yang melakukan
  penambahan/perubahan) dan d_update (tanggal
  update)
• Pengisian tabel Beberapa tabel isinya tidak
  perlu dientry, melainkan bisa dibangkitkan. Dalam
  hal ini, sebaiknya user tidak "disiksa" untuk
  mengetik, misalnya tabel absensi karena
  bersifat harian, dapat dirancang sehingga petugas
  hanya cukup mengetik status kehadiran dan
  keterangan yang perlu. Field identitas pegawai,
  tanggal kerja dapat dibangkitkan

24
Pemeliharaan Data (1)

• Selama aplikasi dioperasikan, mungkin saja
  terjadi kesalahan aplikasi, atau kerusakan sistem
  sehingga data yang disimpan rusak. Memperbaiki
  data yang rusak merupakan bagian pekerjaan yang
  harus dilakukan oleh pengelola data.
• Bagaimana memperbaiki data yang rusak?

25
Pemeliharaan Data (2)

• Dengan membuat program kecil di luar program
  aplikasi.
• Untuk data yang sedikit, dan diagnosa
  kerusakannya jelas, maka data dikoreksi (melalu
  program) satu persatu.
• Jika kerusakan banyak, maka perbaikan lebih mudah
  dilakukan dengan menimpa kembali dengan data
  yang pernah diback-up. Dalam pengelolaan
  basisdata, dikenal istilah backup dan recovery
• Backup data biasanya disediakan program yang
  secara periodik akan membuat salinan data, untuk
  mengembalikan data ke sebuah status jika terjadi
  kerusakan

26
Pemeliharaan Basisdata (3)

• Journal file untuk memelihara catatan dari
  semua transaksi yang terjadi, yang digunakan
  untuk melakukan roll back jika sebuah transaksi
  ingin dibatalkan
• transaction log berisi catatan data yang
  penting pada setiap transaksi kode dan waktu
  transaksi, user id, nilai data pada saat
  transaksi, record yang diakses dan dimodifikasi

27
Pemeliharaan Basisdata (4)

• database change log berisi keadaan data sebelum
  dan sesudah perubahan (before image, after image)
• Checkpoint titik dimana DBMS melakukan
  sinkronisasi semua keadaan dan file
• Recovery modul DBMS yang mengembalikan data ke
  kondisi benar dan memulai proses
• forward
• rollback

28
Recovery

• Recovery sangat praktis untuk data yang bukan
  merupakan sejarah perubahan. Recovery menjadi
  rumit dan seperti membangun dengan menelusuri
  kembali untuk data transaksi.
• Jika pengelola data lalai melakukan backup, dan
  bon kertas tidak terarsip dengan rapi atau bahkan
  tidak ada, maka akan terjadi suatu disaster.
• Contoh data transaksi pengambilan dan
  penambahan barang pada suatu sistem inventory
  yang mengalami kegagalan sistem dan crash. Maka
  transaksi harian yang banyak harus direstore dari
  back up, atau jika lalai melakukan back up maka
  harus dientry ulang. Bayangkan jika tidak ada bon
  kertasnya (misalnya data dientry melalui
  internet).