Desain Database. Dr. Khamami Herusantoso 1/107

Transkripsi

1 Desain Database 1/107

2 Kompetensi Dasar 1. menjelaskan konsep dan pengertian desain database pada Microsoft Access dengan baik Menjelaskan konsep dan pengertian desain database dengan metode top down Menjelaskan konsep dan pengertian desain database dengan metode bottom up menjelaskan proses desain database dengan baik 2. mendesain database dengan baik Mendesain database pada tahap pengumpulan requirement dan analisis Mendesain database pada tahap pembuatan conceptual database design Mendesain database pada tahap pemilihan DBMS Mendesain database pada tahap data model mapping/pembuatan logical database design Mendesain database pada tahap pembuatan physical database design Mendesain database pada tahap implementasi system database melakukan tahapan model entity-relationship dalam mendesain database dengan baik 2/107

3 Kompetensi Dasar 3. menerapkan normalisasi database dalam mendesain database dengan baik Menjelaskan teori normalisasi Database Menjelaskan tujuan normalisasi database Menerapkan teknik normalisasi database Menjelaskan anomali pada proses normalisasi database menerapkan key database dalam mendesain database dengan baik Menjelaskan pengertian key Menerapkan macam-macam key 4. menggunakan komponen database dalam mendesain database dengan baik Menggunakan Table Menggunakan Query Menggunakan Form Menggunakan Report Menggunakan Macro Menggunakan Module 3/107

4 Agenda Database planning System definition Requirement collection & analysis Database design 4/107

5 DBMS selection (opt) Database planning System definition Requirement collection & analysis Db Design Conceptual db design Logical db design Physical db design DB System Development Lifecycle Application design Prototyping (opt) Implementation Data conversion & loading Testing Operational maintenance

6 Step 1: Database Planning Mengatur aktivitas-aktivitas yang memungkinkan tahapan database system development lifecycle dilaksanakan seefisien dan seefektif mungkin Dua langkah penting dalam perencanaan: 1. Mendefinisikan mission statement untuk database system 2. Mengideintifikasi mission objectives 6/107

7 (i) Mission Statement Paparan misi menolong dalam menjelaskan tujuan dari proyek database dan memberikan arah yang lebih jelas kepada pembuatan database system yang efisien dan efektif 7/107

8 Perusahaan Broker (Property) Contoh: tujuan dari DreamHome database system adalah untuk mengelola data yang digunakan dan dibuat guna mendukung bisnis sewa properti oleh client dan pemilik properti, dan juga untuk membantu kerjasama dan information sharing diantara cabang 8/107

9 (ii) Mission Objectives Setiap sasaran misi hendaknya dapat mengidentifikasi tugas tertentu yg harus didukung oleh database 9/107

10 Example: Mission Objectives for DreamHome Database System 10/107

11 DBMS selection (opt) Database planning System definition Requirement collection & analysis Db Design Conceptual db design Logical db design Physical db design Application design Prototyping (opt) Implementation Data conversion & loading Testing Operational maintenance

12 Step 2: System Definition Menjelaskan: 1. scope dan batasan dari database system 2. view-view utama dari pemakai User view mendefinisikan apa-apa yang diminta pada database system dari sudut pandang: Jabatan pekerjaan (misal, manager atau supervisor) atau Enterprise application area (misal, marketing, personnel, or stock control). 12/107

13 Example: System Boundary for DreamHome Database System 13/107

14 Contoh: User View 14/107

15 Database planning System definition DBMS selection (opt) Requirement collection & analysis Db Design Conceptual db design Logical db design Application design Physical db design Prototyping (opt) Implementation Data conversion & loading Testing Operational maintenance

16 Step 3: Requirements Collection and Analysis Proses pengumpulan dan penganalisaan informasi tentang bagian organisasi yang akan disupport oleh sistem database yang akan dibuat Hasil diatas digunakan untuk mengidentifikasi permintaan pemakai terhadap sistem yang baru Hasil dari step ini adalah users requirements specification document 16/107

17 Aktivitas yang Dilakukan 1. Identifikasi aplikasi utama dan kelompok pemakai yang akan menggunakan database yang akan dirancang. 2. Studi dan analisa dokumentasi yang ada yang berhubungan dengan aplikasi yang akan dibuat. 3. Studi lingkungan operasi dan rencana penggunaan informasi. Analisa jenis transaksi dan frekuensi pelaksanaannya 17/107

18 Requirement & Specification Doc 18/107

19 Requirement & Specification Doc 19/107

21 Database Design Proses untuk membuat sebuah rancangan database yang akan mendukung mission statement dan mission objective perusahaan Approach: Bottom-up Top-down 21/107

22 Bottom-Up and Top-Down Approach Sumber data (laporan, form dll) ubah ke format tabel Unnormalized Form (UNF) Dunia Nyata buat diagram ER hilangkan group berulang Diagram ER petakan ke tabel Bentuk normal tahap ketiga (3NF) hilangkan ketergantungan transitif Bentuk normal tahap kedua (2NF) hilangkan ketergantungan parsial Bentuk normal pertama (1NF) 22/107

23 Database Design Approaches Bottom-up: represented by normalization process Dimulai dari level atribut-atribut dasar (yaitu entitas, properti dan relationship), dimana dengan analisa dari asosiasi diantara atribut-atribut tsb, atribut dikelompokkan menjadi tabel-tabel yang merepresentasikan tipe entitas dan hubungan diantara entitas Tepat untuk perancangan Database yang sederhana dengan jumlah atribut yang relatif sedikit 23/107

24 Contoh: Perancangan Database Bottom-up Kumpulan atribut: NIP, Nama, NoUnit, NamaUnit, NIPAtasan, Nama Atasan NIP Nama NoUnit NamaUnit NIPAtasan NamaAtasan 001 Budi 01 Setjen 006 Yudi 002 Yudo 01 Setjen 006 Yudi 003 Tuti 02 BPPK 004 Yono 004 Yono 02 BPPK 008 Yani 005 Yeni 03 DJP 009 Yuni 006 Yudi 01 Setjen 010 Yana 24/107

25 Contoh: Perancangan Database Bottom-up (lanjutan) Dikelompokkan kedalam tiga jenis entitas (dengan proses normalisasi) Pegawai (atribut ke-1 dan ke- 2), Unit (atribut ke-3 dan ke-4), dan Atasan (atribut ke-5 dan ke-6) Entitas-entitas tersebut menjadi tabel 25/107

26 Database Design Approaches Top-Down: illustrated by the ER model concepts Dimulai dari pengembangan data model yang berisikan beberapa high-level entitas dan relationship, dan kemudian mengaplikasikan top-down refinement secara berturut-turut untuk mengidentifikasi entitas dengan level yang lebih rendah, relationship dan atribut-atribut yang terasosiasi Tepat untuk perancangan Database yang kompleks 26/107

27 Contoh: Perancangan Database Top- Down NIP Nama NamaUnit NoUnit Pegawai dipecah NIP Nama NamaUnit NoUnit Pegawai Bekerja Unit 27/107

29 Conceptual Database Design Proses pembuatan sebuah model dari data yang digunakan pada sebuah perusahaan, tidak bergantung pada pertimbangan fisik. Model data dibuat dengan menggunakan informasi yang tertulis dalam users requirements specification Model data konseptual adalah sumber dari informasi untuk fase perancangan logikal 29/107

30 Logical Database Design Proses pembuatan sebuah model berdasarkan pada sebuah model data yang spesifik (misalnya relasional), tetapi tidak bergantung pada DBMS tertentu dan pertimbangan fisik lainnya. Model data konseptual diproses dan dipetakan ke model data logikal hasilnya adalah tabel-tabel relational yang telah dinormalisasi 30/107

31 Physical Database Design Proses pembuatan deskripsi dari implementasi Database pada media penyimpanan sekunder. Mendeskripsikan tabel dasar (base relation), organisasi file dan indeks yang digunakan untuk mendapatkan akses yang efisien. Disesuaikan terhadap sistem DBMS tertentu 31/107

32 Bottom-Up and Top-Down Approach Sumber data (laporan, form dll) ubah ke format tabel Unnormalized Form (UNF) Dunia Nyata buat diagram ER hilangkan group berulang Diagram ER conceptual DB design Bentuk normal tahap ketiga (3NF) Physical DB Design hilangkan ketergantungan transitif Bentuk normal tahap kedua (2NF) Logical DB design hilangkan ketergantungan parsial Bentuk normal pertama (1NF) petakan ke tabel 32/107

33 Normalisasi Database 33/107

34 Pengantar Penyempurnaan Skema: Persoalan yang Ditimbulkan oleh Redundansi Redundansi ruang penyimpanan: beberapa data disimpan secara berulang Update anomaly: Jika satu copy data terulang tsb diubah, inkonsistensi data dpt terjadi kecuali kalau semua copy dari data tsb diubah dengan cara yang sama Insertion anomaly: Mungkin dpt terjadi kesulitan utk menyisipkan data tertentu kecuali kalau beberapa data tidak terkait lainnya juga ikut disisipkan Deletion anomaly: Mungkin dpt terjadi kesulitan utk menghapus data tertentu tanpa harus kehilangan beberapa data tidak terkait lainnya 34/107

35 Persoalan yang Ditimbulkan oleh Redundansi: Contoh NIP Nama Jabatan Grading 1001 Yana Kepala Pusat Yani Kepala Pusat Yono Kepala Bidang Yuni Pelaksana Yuno Pelaksana 15 Redundansi ruang penyimpanan: Pelaksana yang berkorespondensi dg grading 15 diulang dua kali Update anomaly: Nilai Jabatan (yg terkait dengan nilai grading) dlm baris pertama dpt diubah tanpa membuat perubahan yg sama pada baris kedua Insertion anomaly: Kesulitan utk menyisipkan pegawai baru kecuali nilai grading untuk jabatan dari pegawai tsb sudah diketahui Deletion anomaly: Jika semua baris yang terkait dg nilai jabatan tertentu dihapus (misalnya baris utk pegawai Yono dihapus), maka kita akan kehilangan informasi ketergantungan antara nilai jabatan dan nilai grading yang diasosiasikan dengan nilai rating tsb (yaitu jabatan = Kepala Bidang dan grading = 20) 35/107

36 Penyebab Anomali Mengapa anomali - anomali ini terjadi? Karena menggabungkan dua tema (konsep entitas) dalam satu relasi. Ini mengakibatkan duplikasi duplikasi sebagai akibat dari ketergantungan antar atribut yang tidak pada tempatnya. Solusi : Normalisasi 36/107

37 Normalisasi Normalisasi adalah proses pembentukan struktur database sehingga sebagian besar ambiguity bisa dihilangkan. Tahap Normalisasi dimulai dari tahap paling ringan (1NF) hingga paling ketat (5NF) Biasanya hanya sampai pada tingkat 3NF atau BCNF karena sudah cukup memadai untuk menghasilkan tabel-tabel yang berkualitas baik. 37/107

38 Normalisasi Sebuah tabel dikatakan baik (efisien) atau normal jika memenuhi 3 kriteria sbb: 1. Jika ada dekomposisi (penguraian) tabel, maka dekomposisinya harus dijamin aman (Lossless-Join Decomposition). Artinya, setelah tabel tersebut diuraikan / didekomposisi menjadi tabel-tabel baru, tabel-tabel baru tersebut bisa menghasilkan tabel semula dengan sama persis. 2. Terpeliharanya ketergantungan fungsional pada saat perubahan data (Dependency Preservation). 3. Tidak melanggar Boyce-Code Normal Form (BCNF) (-akan dijelaskan kemudian-) 38/107

39 Normalisasi Jika kriteria ketiga (BCNF) tidak dapat terpenuhi, maka paling tidak tabel tersebut tidak melanggar Bentuk Normal tahap ketiga (3rd Normal Form / 3NF). 39/107

40 Langkah Langkah Normalisasi 40/107

41 Tabel Universal Tabel Universal (Universal / Star Table) sebuah tabel yang merangkum semua kelompok data yang saling berhubungan, bukan merupakan tabel yang baik. Misalnya: 41/107

42 Tabel Universal NIP Nama No_klien Nama_klien 037 Nina K05 Martini K08 Anton K02 Sarmini 038 Tono K04 Eka K10 Andin 039 Hadi K06 Mitha K24 Buyung K90 Indah 42/107

43 Functional Dependency Notasi: A B A dan B adalah atribut dari sebuah tabel. Berarti secara fungsional A menentukan B atau B tergantung pada A, jika dan hanya jika ada 2 baris data dengan nilai A yang sama, maka nilai B juga sama Notasi: A B atau A x B Adalah kebalikan dari notasi sebelumnya. 43/107

44 Functional Dependency Contoh tabel pemasok Kode Nama_Brg Harga Kd_Pemasok Nm_Pemaso k T-001 TV SN P22 PT Sumber Jakarta T-002 TV SN P22 PT Sumber Jakarta T-003 TV SS P11 PT Tunas Jaya Kota Surabaya T-004 TV M P33 PT Mekar Semarang T-005 TV S P44 PT Holic Semarang 44/107

45 Dependensi Fungsional Berdasarkan tabel tersebut, diperoleh: Kode Nama_Brg Kode Harga Kode Kd_Pemasok Kode Nm_Pemasok Kd_Pemasok Nm_Pemasok Setiap Kode pasti berhubungan dengan satu Nama_Brg begitu juga antara Kode dan Harga. Begitu seterusnya. Misalnya: T-001 hanya cocok dengan 1 barang, yaitu TV SN 14 Catatan: Bagaimana kalau dibalik? Harga tidak menentukan barangnya, (karena banyak barang mempunyai harga yang sama); tapi satu jenis barang punya satu harga. Nama_Brg Kode Nm_Pemasok Kode_Pemasok 45/107

46 Dependensi Fungsional Perhatikan bagian ini: Kode Nama_Brg Kode Harga Kode Kd_Pemasok Kode Nm_pemasok Kd_Pemasok Nm_Pemasok Ternyata, Kode menentukan lebih dari satu atribut. Notasinya dapat diganti sebagai berikut: Kode {Nama_Brg, Harga, Kd_Pemasok} Kode Nm_Pemasok (yang ini bagaimana?) 46/107

47 Bentuk-bentuk Normal 1. Bentuk Normal Tahap Pertama (1st Normal Form / 1NF) 2. Bentuk Normal Tahap Kedua (2nd Normal Form / 2NF) 3. Bentuk Normal Tahap (3rd Normal Form / 3NF) 4. Boyce-Code Normal Form (BCNF) 5. Bentuk Normal Tahap (4th Normal Form / 4NF) 6. Bentuk Normal Tahap (5th Normal Form / 5NF) 47/107

48 Bentuk Normal Tahap Pertama (1st Normal Form / 1NF) Bentuk normal 1NF terpenuhi jika sebuah tabel tidak memiliki atribut bernilai banyak (multivalued attribute), atribut composite atau kombinasinya dalam domain data yang sama. Setiap atribut dalam tabel tersebut harus bernilai atomic (tidak dapat dibagi-bagi lagi) 48/107

49 Data Tidak Ternormalisasi NIP Nama No_klien Nama_klien 037 Nina K05 Martini K08 Anton K02 Sarmini 038 Tono K04 Eka K10 Andin 039 Hadi K06 Mitha K24 Buyung K90 Indah 49/107

50 Data 1NF NIP Nama No_klien Nama_klien 037 Nina K05 Martini 037 Nina K08 Anton 037 Nina K02 Sarmini 038 Tono K04 Eka 038 Tono K10 Andin 039 Hadi K06 Mitha 039 Hadi K24 Buyung 039 Hadi K90 Indah 50/107

51 Contoh 2 (composite) JadwalKuliah Kodekul NamaKul Dosen Kelas Jadwal Dimana nilai pada atribut jadwal berisi gabungan antara Hari dan Jam. Jika asumsi hari dan jam memegang peranan penting dalam sistem database, maka atribut Jadwal perlu dipisah sehingga menjadi JadwalHari dan JadwalJam sbb: JadwalKuliah Kodekul NamaKul Dosen Kelas JadwalHari JadwalJam 51/107

52 Bentuk Normal Tahap Kedua (2nd Normal Form) Bentuk normal 2NF terpenuhi dalam sebuah tabel jika telah memenuhi bentuk 1NF, dan semua atribut selain primary key, secara utuh memiliki Functional Dependency pada primary key Sebuah tabel tidak memenuhi 2NF, jika ada atribut yang ketergantungannya (Functional Dependency) hanya bersifat parsial saja (hanya tergantung pada sebagian dari primary key) Jika terdapat atribut yang tidak memiliki ketergantungan terhadap primary key, maka atribut tersebut harus dipindah atau dihilangkan 52/107

53 Contoh Tabel berikut memenuhi 1NF tapi tidak termasuk 2NF: NIM Nama Alamat Mk_kode mk_nama mk_sks nihuruf Tidak memenuhi 2NF, karena {NIM, mk_kode} yang dianggap sebagai primary key sedangkan: {NIM, mk_kode} mhs_nama {NIM, mk_kode} {NIM, mk_kode} mhs_alamat mk_nama {NIM, mk_kode} mk_sks {NIM, mk_kode} nihuruf Tabel di atas perlu didekomposisi menjadi beberapa tabel yang memenuhi syarat 2NF 53/107

54 Contoh Functional dependencynya sbb: {NIM, mk_kode} nihuruf (fd1) NIM {mhs_nama, mhs_alamat} (fd2) Mk_kode {mk_nama, mk_sks} (fd3) fd1 (NIM, mk_kode, nihuruf) Tabel Nilai fd2 (NIM, mhs_nama, mhs_alamat) Tabel Mahasiswa fd3 (mk_kode, mk_nama, mk_sks) Tabel MataKuliah 54/107

55 Bentuk Normal Tahap Ketiga (3rd Normal Form /3NF) Bentuk normal 3NF terpenuhi jika telah memenuhi bentuk 2NF, dan jika tidak ada atribut non primary key yang memiliki ketergantungan terhadap atribut non primary key yang lainnya. 55/107

56 Contoh Tabel berikut memenuhi 2NF, tapi tidak memenuhi 3NF: Pegawai NIP Nama Alm_Jalan Alm_Kota Alm_Provinsi Alm_Kodepos karena masih terdapat atribut non primary key (yakni alm_kota dan alm_provinsi) yang memiliki ketergantungan terhadap atribut non primary key yang lain (yakni alm_kodepos): alm_kodepos {alm_provinsi, alm_kota} Sehingga tabel tersebut perlu didekomposisi menjadi: Pegawai (NIP, nama, alm_jalan, alm_kodepos) Kodepos (alm_kodepos, alm_provinsi, alm_kota) 56/107