Applied Database II Basis Data Praktis. Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 2 Overview Pengertian dan studi mengenai key.

Presentasi berjudul: "Applied Database II Basis Data Praktis. Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 2 Overview Pengertian dan studi mengenai key."— Transcript presentasi:

1 Applied Database II Basis Data Praktis

2 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 2 Overview Pengertian dan studi mengenai key Tabel dan relasinya Normalisasi basisdata Personal yang terlibat dalam pemanfaatan sistem basisdata dan tugasnya

3 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 8 Relasi antar Tabel Key dipakai untuk menentukan relasi antar tabel basis data Detail Referensi Detail dari Detail Transaksi periodik Transaksi per kejadian History Master RelasiMaster_1 Master_2 Master_x

9 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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_master+id_detail

12 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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_master+id_detail+idDetaildetail

13 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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_master+id_waktu

14 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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_master+id_kejadian

15 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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_asal+id_history

16 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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 Anastasia L. R. Data Processing. 2004 Politeknik Informatika Del 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).