Desain Database Relasional

Transkripsi

1 DIKLAT TEKNIS UMUM DESAIN PENGELOLAAN DATABASE MODUL Desain Database Relasional Oleh Dr. Khamami Herusantoso Sanyoto Gondodiyoto Widyaiswara Pusdiklat Keuangan Umum KEMENTERIAN KEUANGAN REPUBLIK INDONESIA BADAN PENDIDIKAN DAN PELATIHAN KEUANGAN PUSDIKLAT KEUANGAN UMUM JAKARTA 2011

2 Judul Modul: Desain Database Relasional Penulis: Dr. Khamami Herusantoso Sanyoto Gondodiyoto Cetakan Pertama: 2011 Modul: Desain Database Relasional ii

3 Puji syukur kami panjatkan ke hadirat Tuhan yang Maha Esa, karena hanya atas berkat rahmat-nya kita semua masih diberikan kesempatan untuk melaksanakan tugas-tugas terkait kediklatan hingga saat ini, terutama bagi penulis yang telah diberi kesempatan untuk menyusun dan menyelesaikan modul ini dengan baik. Modul Structure and Query Language untuk Diklat Teknis Umum Pengelolaan Database ini disusun oleh Saudara Khamami Herusantoso dan Saudara Agus Hekso Pramudijono berdasarkan Surat Keputusan Kepala Pusdiklat Nomor KEP-003/PP.7/2011 tanggal 28 Januari 2011 tentang Pembentukan Tim Penyusunan Modul Diklat Teknis Umum (DTU) Desain Pengelolaan Database di Lingkungan Pusdiklat Keuangan Umum Tahun Anggaran Kami menyetujui modul ini digunakan sebagai bahan ajar bagi para peserta Diklat Teknis Umum Pengelolaan Database. Modul ini merupakan salah satu bahan ajar yang diperlukan selain 4 (empat) modul lain yang saling melengkapi yaitu Modul Pengenalan Konsep Database, Modul Desain Database Relasional, Modul Pemrograman SQL, dan Modul Pengelolaan Database, yang kesemuanya menjadi sarana dalam membantu pencapaian tujuan pembelajaran dalam Diklat Teknis Umum Pengelolaan Database. Akhirnya, semoga Modul Diklat ini dapat bermanfaat bagi peserta diklat pada khususnya dan masyarakat luas pada umumnya. Jakarta, Juni 2011 Kepala Pusat Pendidikan dan Pelatihan Keuangan Umum Tony Rooswiyanto NIP Modul: Desain Database Relasional iii

4 HALAMAN JUDUL IDENTITAS MODUL KATA PENGANTAR DAFTAR ISI DAFTAR TABEL DAFTAR GAMBAR PETUNJUK PENGGUNAAN MODUL PETA KONSEP MODUL Halaman i ii iii v vi vii viii A. PENDAHULUAN 1. Deskripsi Singkat 2. Prasyarat Kompetensi 3. Standar Kompetensi dan Kompetensi Dasar 4. Relevansi Modul B. KEGIATAN BELAJAR 1. Kegiatan Belajar 1 : Pengantar Desain Database a. Pengertian Desain Database b. Model Database c. Latihan d. Rangkuman e. Tes Formatif f. Umpan Balik dan Tindak Lanjut 2. Kegiatan Belajar 2 : Entity Relation Model a. Entitas dan Atribut Modul: Desain Database Relasional iv

5 b. Relasi Antar Entitas c. Fitur ER Model d. Latihan e. Rangkuman f. Tes Formatif g. Umpan Balik dan Tindak Lanjut 3. Kegiatan Belajar 3 : Konsep Normalisasi a. Atribut Kunci b. Ketergantungan Fungsional c. Bentuk Normalisasi d. Latihan e. Rangkuman f. Tes Formatif g. Umpan Balik dan Tindak Lanjut PENUTUP TES SUMATIF KUNCI JAWABAN (LATIHAN, TES FORMATIF, &TES SUMATIF) DAFTAR PUSTAKA Modul: Desain Database Relasional v

6 Tabel 3.1 Contoh Update Anomaly Tabel 3.2 Contoh Insert Anomaly Tabel 3.3 Contoh Delete Anomaly Tabel 3.4 Tabel Mata Kuliah Tabel 3.5 Contoh Tabel Tabel 3.6 Tabel Nilai Tabel 3.7 Tabel Mahasiswa Tabel 3.8 Tabel Versi Pertama Tabel 3.9 Tabel Versi Kedua Tabel 3.10 Contoh Tabel T-1 Tabel 3.11 Contoh Tabel T-2 Tabel 3.12 Contoh T-1hasil Tabel 3.13 Contoh Tabel T-1-1 Tabel 3.14 Contoh Tabel T-1-2 Tabel 3.15 Contoh Tabel T-1-3 Tabel 3.16 Contoh Tabel T-1-1 Tabel 3.17 Contoh Tabel T Tabel 3.18 Contoh Tabel T Halaman Modul: Desain Database Relasional vi

7 Halaman Gambar 1.1 Tahapan Perancangan Database Gambar 2.1 Himpunan Entitas Mahasiswa Gambar 2.2 Contoh Himpunan Entitas Gambar 2.3 Gambaran Himpunan Entitas di Tabel Gambar 2.4 Contoh Atribut Komposit Gambar 2.5 Entitas Mahasiswa dengan Atribut Gambar 2.6 Relasi Digambarkan dengan Belah Ketupat Gambar 2.7 Himpunan Entitas Mahasiswa Berelasi dengan Himpunan Entitas Organisasi Gambar 2.8 Contoh Derajat Relasi Unary Gambar 2.9 Contoh Derajat Relasi Binary Gambar 2.10 Contoh Derajat Relasi Ternary Gambar 2.11 Relasi dengan Kardinalitas 1 ke 1 Gambar 2.12 Relasi dengan Kardinalitas 1 ke Banyak Gambar 2.13 Relasi dengan Kardinalitas Banyak ke 1 Gambar 2.14 Relasi dengan Kardinalitas Banyak ke Banyak Gambar 2.15 Contoh Diagram ER Gambar 2.16 Relasi 1 ke 1 Gambar 2.17 Relasi 1 ke Banyak Gambar 2.18 Relasi Banyak ke 1 Gambar 2.19 Relasi banyak ke Banyak Gambar 2.20 Contoh Himpunan Entitas Lemah Gambar 2.21 Contoh Spesialisas Gambar 2.22 Contoh Agregasi Gambar 2.23 Relasi Dipandang Sebagai Himpunan Entitas Gambar 2.24 Ringkasan Notasi pada Diagram ER Gambar 2.25 Atribut Multivalued Dipecah Menjadi Entitas Baru Modul: Desain Database Relasional vii

8 Gambar 2.26 Atribut Himpunan Entitas Kuat Dipresentasikan ke Dalam Tabel Gambar 2.27 Penurunan Himpunan Entitas Lemah ke Tabel Gambar 2.28 Penurunan Kardinalitas Relasi N to N Menjadi Tabel Gambar 2.29 Representasi Spesialisasi ke Tabel Metoda 1 Gambar 2.30 Representasi Spesialisasi ke Tabel Metoda 1 Gambar 2.31 Representasi Agregasi untuk Tabel Mata Kuliah, Dosen, dan Dosen Mengajar Mata Kuliah Gambar 2.32 Representasi Agregasi untuk Tabel Mahasiswa dan Mahasiswa Mengambil Mata KUliah Gambar 3.1 Diagram Normalisasi Modul: Desain Database Relasional viii

9 Modul ini merupakan salah satu bagian dari 5(lima) modul yang diperlukan dan bersifat saling melengkapi, yaitu: 1. Modul Pengenalan Konsep Database; 2. Modul Desain Database Relasional; 3. Modul Structured Query Language; 4. Modul Pemrograman SQL; 5. Modul Pengelolaan Database. yang kesemuanya tersebut menjadi satu paket dan dimaksudkan dalam rangka pencapaian tujuan pembelajaran pada Diklat Teknis Umum Desain Pengelolaan Database. Modul Desain Database Relasional ini terdiri dari tiga kegiatan belajar (KB), yaitupengantar Desain Database, Entity Relationship Model dan Konsep Normalisasi. Modul ini perlu untuk dibaca secara berurutan dari KB 1 hingga KB3 agar konsep Desain Database Relasional menjadi lebih mudah dipahami. Pada akhir setiap kegiatan belajar diberikan rangkuman yang berisi intisari dari materi yang sudah dibahas sebelumnya.selanjutnya untuk mengevaluasi pemahaman pembaca, disetiap akhir kegiatan belajar juga disajikan tes formatif. Meskipun sudah disediakan kunci jawaban atas pertanyaan-pertanyaan dalam Tes Formatif, peserta disarankan untuk tidak melihat dulu kunci jawaban, namun sebaiknya peserta mengejakan terlebih dahulu Tes Formatif sesuai dengan alokasi waktu yang diberikanbaru kemudian melakukan penilaian secara mandiri dan mengecek nilainya dengan kriteria umpan balik, apakah sudah tercapai dengan baik. Jika nilai baik belum tercapai, maka peserta disarankan membaca kembali materi dan mengulangi mengerjakan soal tes sampai memperoleh hasil yang diharapkan. Modul: Desain Database Relasional ix

10 PENGANTAR DESAIN DATABASE Pengertian Desain Database Model Database ENTITY RELATIONSHIP MODEL Entitas dan Atribut Relasi Antar Entitas Fitur ER Model KONSEP NORMALISASI Atribut Kunci Ketergantungan Fungsional Bentuk Normalisasi Modul: Desain Database Relasional x

11 A. PENDAHULUAN 1. Deskripsi Mata pelajaran ini membahas 2. Standar Kompetensi Setelah mengikuti mata pelajaran ini, peserta diharapkan mampu menjelaskan desain database relasional 3. Kompetensi Dasar Setelah selesai mengikuti pembelajaran ini, peserta diklat diharapkan mampu: a. menjelaskan pengertian desain database; b. menjelaskan entity relation model; c. menjelaskan konsep normalisasi 4. Relevansi Modul Setelah mempelajari modul ini diharapkan peserta dapat mengaplikasikannya dalam pekerjaan yang menjadi tugas pokok dan fungsinya.. Modul: Desain Database Relasional 1

12 B. KEGIATAN BELAJAR 1. Kegiatan Belajar 1 PENGANTAR DESAIN DATABASE Indikator Setelah selesai mengikuti pembelajaran ini peserta diklat diharapkan mampu: menjelaskan pengertian desain database; menjelaskan model database a) Pengertian Desain Database Pada bagian ini akan dijelaskan pengertian desain database. Desain database merupakan proses untuk merepresentasikan fakta dunia nyata (real world) yang dikehendaki ke dalam sistem komputer, sehingga mudah dipahami pemakai dengan mempertimbangkan kemudahan implementasi dan pemrosesannya. Istilah dunia nyata (real world) bermakna terhadap keseluruhan data yang belum terstruktur yang secara nyata ada/terkait dalam lingkup sistem yang sedang ditinjau. Dunia nyata disini bisa dikatakan sebagai sebuah domain secara utuh/penuh maupun subdomain, sebagai contoh jika kita menganggap suatu perusahaan sebagai suatu domain maka kita dapat menganggap unit-unit yang ada dalam perusahaan tersebut adalah subdomain atau bisa saja sebuah proses bisnis atau aktivitas yang ada di perusahaan tersebut juga bisa kita anggap sebagai sebuah subdomain bahkan domain. Setiap dunia nyata (real world) yang ada memiliki karakter yang tidak sama/unik. Sebagai contoh dunia nyata bagi sistem perbankan pasti tidak sama dengan dunia nyata bagi sistem Modul: Desain Database Relasional 2

13 rumah sakit. Pertanyaannya adalah apakah dunia nyata di bank yang satu dengan bank yang lain pasti sama? Permasalahan dalam perancangan database adalah bagaimana merancang struktur logikal dan fisikal dari satu atau lebih database untuk memenuhi kebutuhan informasi yang diperlukan oleh pengguna sesuai dengan aplikasi-aplikasi yang ditentukan. (Waliyanto, 2000). Dengan permasalahan tersebut dapat ditentukan beberapa tujuan utama perancangan database,yaitu : a. memenuhi kebutuhan informasi sesuai dengan yang diperlukan oleh pengguna untuk aplikasi tertentu; b. mempermudah pemahaman terhadap struktur informasi yang tersedia dalam database; c. memberikan keterangan tentang persyaratan pemrosesan dan kemampuan sistem, seperti lama tidaknya mengakses data, kapasitas memori yang tersedia dan sebagainya. Tahapan-tahapan proses perancangan untuk memenuhi tujuan tersebut adalah: a. mengumpulkan dan menganalisis persyaratan; b. merancang konsepsual database; c. memilih Database Management Software (DBMS); d. merancang logikal database; e. merancang fisikal database (pemetaan model data); f. iimplementasi sistem database. Secara khusus proses perancangan berisikan 2 aktifitas paralel. Aktifitas yang pertama melibatkan perancangan dari isi data dan struktur database, sedangkan aktifitas kedua mengenai perancangan pemrosesan database dan aplikasi-aplikasi perangkat lunak. Modul: Desain Database Relasional 3

14 Gambar 1.1 Tahapan perancangan database (Kompilasi dari Elmasri R, 1994). Dua aktifitas ini saling menjalin, misalnya : kita dapat mengidentifikasikan data item yang akan disimpan dalam database dengan menganalisa aplikasi-aplikasi database. Dua aktifitas ini juga saling mempengaruhi satu sama lain. Contohnya : fase perancangan database secara fisik, pada saat kita memilih struktur penyimpanan dan jalur-jalur akses dari file-file database yang tergantung pada aplikasi-aplikasi yang akan menggunakan file-file tersebut. Modul: Desain Database Relasional 4

15 Di lain pihak, kita biasanya menentukan perancangan aplikasiaplikasi database dengan mengarah kepada konstruksi skema database yang telah ditentukan selama aktifitas yang pertama. Enam fase di atas tidak harus diproses berurutan. Pada beberapa hal, rancangan tersebut dapat dimodifikasi dari yang pertama dan sementara itu mengerjakan fase yang terakhir (feedback loop antara fase) dan feedback loop dalam fase sering terjadi selama proses perancangan. Fase 1 merupakan kumpulan informasi yang berhubungan dengan penggunaan database. Fase 6 merupakan implementasi databasenya. Fase 1 dan 6 kadang-kadang bukan merupakan bagian dari perancangan database, tetapi merupakan bagian dari siklus kehidupan sistem informasi secara umum. Inti dari proses perancangan database adalah fase 2,4,5. Fase 1: Pengumpulan Data dan Analisa Proses identifikasi dan analisa kebutuhan-kebutuhan data disebut pengumpulan data dan analisa. Untuk menentukan kebutuhankebutuhan suatu sistem database, pertamatama harus mengenal bagian-bagian lain dari sistem informasi yang akan berinteraksi dengan sistem database, termasuk para pemakai yang ada dan para pemakai yang baru serta aplikasi-aplikasinya. Kebutuhan-kebutuhan dari para pemakai dan aplikasi inilah yang kemudian dikumpulkan dan dianalisa. Aktifitas-aktifitas pengumpulan data dan analisa : 1. Menentukan kelompok pemakai dan bidang-bidang aplikasinya Menentukan aplikasi utama dan kelompok user yang akan menggunakan database. Individu utama pada tiap-tiap kelompok pemakai dan bidang aplikasi yang telah dipilih merupakan peserta utama pada langkah-langkah berikutnya dari pengumpulan dan spesifikasi data. Modul: Desain Database Relasional 5

16 2. Peninjauan dokumentasi yang ada Dokumen yang ada yang berhubungan dengan aplikasi-aplikasi dipelajari dan dianalisa. Dokumen-dokumen lainnya (seperti : kebijaksanaan-kebijaksanaan, form, report, dan bagan organisasi) diuji dan ditinjau kembali untuk menguji apakah dokumen-dokumen tersebut berpengaruh terhadap kumpulan data dan proses spesifikasi. 3. Analisa lingkungan operasi dan pemrosesan data Informasi yang sekarang dan yang akan datang dipelajari. Termasuk juga analisa jenis-jenis transaksi dan frekuensi-frekuensi transaksinya dan juga arus informasi dalam sistem. Input-output data untuk transaksi-transaksi tersebut diperinci. 4. Daftar pertanyaan dan wawancara Tuliskan tanggapan-tanggapan dari pertanyaan-pertanyaan yang telah dikumpulkan dari para pemakai database yang berpotensi. Ketua kelompok (individu utama) dapat diwawancarai sehingga input yang banyak dapat diterima dari mereka dengan memperhatikan informasi yang berharga dan mengadakan prioritas. Fase 2: Perancangan database secara konseptual Tujuan dari fase ini adalah menghasilkan conceptual schema untuk database yang tergantung pada sebuah DBMS yang spesifik. Sering menggunakan sebuah high-level data model seperti ER/EER model selama fase ini. Dalam conceptual schema, kita harus memerinci aplikasi-aplikasi database yang diketahui dan transaksi-transaksi yang mungkin. Fase perancangan database secara konseptual mempunyai 2 aktifitas paralel : 1. Perancangan skema konseptual : menguji kebutuhan-kebutuhan data dari suatu database yang merupakan hasil dari fase 1, dan menghasilkan sebuah skema konseptual yang independen terhadap DBMS. Skema ini dapat Modul: Desain Database Relasional 6

17 dihasilkan dengan menggabungkan bermacam-macam kebutuhan user dan secara langsung membuat skema database atau dengan merancang skema-skema yang terpisah dari kebutuhan tiap-tiap user dan kemudian menggabungkan skema-skema tersebut. Model data yang digunakan pada perancangan skema konseptual bersifat independen terhadap DBMS dan langkah selanjutnya adalah memilih sebuah DBMS untuk melaksanakan rancangan tersebut. 2. Perancangan transaksi : menguji aplikasi-aplikasi database dimana kebutuhan-kebutuhannya telah dianalisa pada fase 1, dan menghasilkan perincian transaksitransaksi ini. Kegunaan fase ini yang diproses secara paralel bersama fase perancangan skema konseptual adalah untuk merancang karakteristik dari transaksi-transaksi database yang telah diketahui pada suatu DBMS-independent. Transaksi-transaksi ini akan digunakan untuk memproses dan memanipulasi database suatu saat dimana database tersebut dilaksanakan. Fase 3: Pemilihan DBMS Pemilihan database di tentukan oleh beberapa faktor, diantaranya: faktor teknik,ekonomi, dan politik organisasi. Contoh faktor teknik : Keberadaan DBMS dalam menjalankan tugasnya seperti jenis-jenis DBMS (relational, network, hierarchical, dll), struktur penyimpanan, dan jalur akses yang mendukung DBMS, pemakai, dll. Faktor-faktor ekonomi dan organisasi yang mempengaruhi satu sama lain dalam pemilihan DBMS : 1. Struktur data Jika data yang disimpan dalam database mengikuti struktur hirarki, maka suatu jenis hirarki dari DBMS harus dipikirkan. Modul: Desain Database Relasional 7

18 2. Personal yang telah terbiasa dengan suatu sistem Jika staf programmer dalam suatu organisasi sudah terbiasa dengan suatu DBMS, maka hal ini dapat mengurangi biaya latihan dan waktu belajar. 3. Tersedianya layanan penjual Keberadaan fasilitas pelayanan penjual sangat dibutuhkan untuk membantu memecahkan beberapa masalah sistem. Fase 4: Perancangan database secara logika (pemetaan model data) Fase selanjutnya dari perancangan database adalah membuat sebuah skema konseptual dan skema eksternal pada model data dari DBMS yang terpilih. Fase ini dilakukan oleh pemetaan skema konseptual dan skema eksternal yang dihasilkan pada fase 2. Pada fase ini, skema konseptual ditransformasikan dari model data tingkat tinggi yang digunakan pada fase 2 ke dalam model data dari DBMS yang dipilih pada fase 3. Pemetaannya dapat diproses dalam 2 tingkat : 1. Pemetaan system-independent Pemetaan ke dalam model data DBMS dengan tidak mempertimbangkan karakteristik atau hal-hal yang khusus yang berlaku pada implementasi DBMS dari model data tersebut. 2. Penyesuaian skema ke DBMS yang spesifik Mengatur skema yang dihasilkan pada langkah 1 untuk disesuaikan pada implementasi yang khusus di masa yang akan datang dari suatu model data yang digunakan pada DBMS yang dipilih. Hasil dari fase ini memakai perintah-perintah DDL dalam bahasa DBMS yang dipilih yang menentukan tingkat skema konseptual dan eksternal dari sistem database. Tetapi dalam beberapa hal, perintahperintah DDL memasukkan parameter-parameter rancangan fisik Modul: Desain Database Relasional 8

19 sehingga DDL yang lengkap harus menunggu sampai fase perancangan database secara fisik telah lengkap. Fase ini dapat dimulai setelah pemilihan sebuah implementasi model data sambilmenunggu DBMS yang spesifik yang akan dipilih. Contoh: jika memutuskan untuk menggunakan beberapa relational DBMS tetapi belum memutuskan suatu relasi yang utama. Rancangan dari skema eksternal untuk aplikasi-aplikasi yang spesifik seringkali sudah selesai selama proses ini. Fase 5: Perancangan database secara fisik Perancangan database secara fisik merupakan proses pemilihan struktur-struktur penyimpanan dan jalur-jalur akses pada file-file database untuk mencapai penampilan yang terbaik pada bermacammacam aplikasi. Selama fase ini, dirancang spesifikasi-spesifikasi untuk database yang disimpan yang berhubungan dengan struktur-struktur penyimpanan fisik, penempatan record dan jalur akses. Berhubungan dengan internal schema (pada istilah 3 level arsitektur DBMS). Beberapa petunjuk dalam pemilihan perancangan database secara fisik : 1. Response time : waktu yang diperlukan dari suatu transaksi database yang diajukan hingga memperoleh jawaban atau respons. Pengaruh utama pada response time yang di bawah kendali DBMS yaitu : waktu akses database untuk data item yang ditunjuk oleh suatu transaksi. Response time juga dipengaruhi oleh beberapa faktor yang tidak berada di bawah kendali DBMS yaitu: beban sistem, penjadwalan sistem operasi atau penundaan komunikasi. 2. Space utility : jumlah ruang penyimpanan yang digunakan oleh file-file database dan struktur jalur akses ke database yaitu index dan jalur akses lainnya. Modul: Desain Database Relasional 9

20 3. Transaction through put rata-rata jumlah transaksi yang dapat diproses per menit oleh sistem database, dan merupakan parameter kritis dari sistem transaksi (misal : digunakan pada pemesanan tempat di pesawat, bank, dll). Hasil dari fase ini adalah penentual awal dari struktur penyimpanan dan jalur akses untuk file-file database. Fase 6: Implementasi sistem database Setelah perancangan secara logika dan secara fisik lengkap, kita dapat melaksanakan sistem database. Perintah-perintah dalam DDL dan SDL(storage definition language) dari DBMS yang dipilih, dihimpun dan digunakan untuk membuat skema database dan file-file database (yang kosong). Sekarang database tersebut dimuat (disatukan) dengan datanya. Jika data harus dirubah dari sistem komputer sebelumnya, perubahan-perubahan yang rutin mungkin diperlukan untuk format ulang datanya yang kemudian dimasukkan ke database yang baru. Transaksitransaksi database sekarang harus dilaksanakan oleh para programmmer aplikasi. Spesifikasi secara konseptual diuji dan dihubungkan dengan kode program dengan perintah-perintah dari embedded DML yang telah ditulis dan diuji. Suatu saat transaksi tersebut telah siap dan data telah dimasukkan ke dalam database, maka fase perancangan dan implementasi telah selesai, dan kemudian fase operasional dari sistem database dimulai. Sebuah sistem database merupakan komponen dasar sistem informasi organisasi yang lebih besar. Oleh karena itu siklus hidup aplikasi database berhubungan dengan siklus hidup sistem informasi. Siklus kehidupan sistem informasi merupakan macro lifecycle sementara itu siklus kehidupan database merupakan micro lifecycle. Aktifitas-aktifitas yang berhubungan dengan database sebagai micro life cycle dan termasuk fase-fasenya diantaranya : system definition, design, implementation, loading atau data conversion, Modul: Desain Database Relasional 10

21 application conversion, testing dan validation, operation, monitoring dan maintenance. Proses perancangan database merupakan bagian dari micro lifecycle. Sedangkan kegiatan-kegiatan yang terdapat di dalam proses tersebut diantaranya : pengumpulan data dan analisis, perancangan database secara konseptual, pemilihan DBMS, perancangan database secara logika (data model mapping), perancangan database secara fisik, dan implementasi sistem database. b) Model data Model database adalah suatu konsep yang terintegrasi dalam menggambarkan hubungan (relationships) antar data dan batasanbatasan (constraint) data dalam suatu sistem database. Model database yang paling awal adalah berbasis model flat file (file datar), dimana semua record disimpan dalam bentuk sebuah file biasa. Pada model ini, tidak ada hubungan (relationship) yang bisa didefinisikan atau dibuat diantara record-record tersebut. Dengan tidak adanya hubungan antar record, maka record-record tersebut hanya bisa diakses dengan cara berurutan (sekuensial). Sebagai contoh, jika ingin menemukan suatu record pelanggan ke 50, maka akan dilakukan pencarian dari record pertama sampai ke record 49 secara berurutan. Model ini sesuai dengan kondisi dimana semua record akan diproses secara keseluruhan, tapi tidak sesuai jika hanya ingin mencari record yang sesuai saja dalam suatu database. Model selanjutnya adalah hierarchial model (model hirarki), yang secara luas digunakan dalam lingkungan komputer mainframe. Model ini diturunkan dari Information Management Systems pada tahun 1950an dan diadopsi oleh perusahaan-perusahaan seperti bank, asuransi dan masih digunakan hingga sampai hari ini. Model ini dirancang dengan hubungan yang terstruktur sehingga memungkinkan dan mempermudah akses terhadap suatu data atau record. Dengan menggunakan skema dari suatu pohon yang dibalik, hubungan yang terjadi dalam model hirarki ini adalah parent-child dan one-to-many. Setiap tabel parent bisa Modul: Desain Database Relasional 11

22 mempunyai beberapa child tabel, namun setiap child tabel hanya mempunyai satu parent tabel. Karena struktur datanya permanen, dan secara eksplisit terhubung antara satu sama lainnya, maka proses pengaksesan data akan lebih cepat. Meskipun demikian, model struktur yang bersifat kaku ini menyebabkan beberapa masalah. Penambahan child tabel tidak bisa dilakukan jika tidak terhubung dengan parent tabel. Misalnya, jika parent tabelnya adalah Dokter dan child tabelnya adalah Pasien, maka penambahan pasien akan bergantung dengan dokter. Dengan kata lain, penambahan record seorang pasien harus juga menambahkan record seorang dokter. Begitu juga jika sebuah parent tabel dihapus, maka child-child tabel dibawahnya juga akan terhapus. Berdasarkan model hirarki pohon terbalik juga, pendekatan desain database selanjutnya dibuat yaitu network model. Model ini menerapkan hubungan yang lebih rumit dari model hirarki, sebagai contoh suatu pohon bisa memiliki cabang yang banyak. Pada model ini, tabel-tabel terhubung dalam sebuah himpunan, dimana sebuah record dalam tabel owner akan dihubungkan dengan beberapa record dalam tabel member. Seperti halnya model hirarki, pengaksesan data pada network model juga berlangsung sangat cepat. Namun demikian, model ini juga mempunyai beberapa masalah. Misalnya, seorang user harus paham betul secara menyeluruh struktur database yang ada untuk memperoleh sebuah data atau informasi. Jika strukturnya berubah, maka segala informasi yang berkaitan dengannya akan berubah juga. Pada tahun 1970-an, hubungan antar database (database relational) dikembangkan dengan pesat dan begitu rumit, dimana nantinya akan mendominasi penggunaan konsep ini dalam semua industri. Pada model database relational, data disimpan dalam sebuah relations (relasi), biasanya disebut dengan tabel. Kumpulan dari tabel, record (atau tuples), dan fields (atau attributes) adalah komponenkomponen dasar yang membentuk suatu relasi database. Setiap data individual, disimpan dalam field di suatu tabel dan setiap record terdiri dari beberapa field yang membentuk suatu tabel. Modul: Desain Database Relasional 12

23 Model database relational dikembangkan dari proposal oleh Dr. E.F. Codd yang berjudul A Relational Model of Data for Large Shared Databanks pada tahun Codd adalah seorang peneliti ilmiah di IBM, yang menjelaskan cara yang baik untuk mengelola data yang ada dalam jumlah besar. Model hirarki dan network pada waktu itu cenderung bermasalah dengan redundansi dan integritas data. Dengan menggabungkan disiplin ilmu aljabar, kalkulus dan lojik ke suatu data, Codd membangun suatu model yang lebih komplek. TUGAS DAN LATIHAN 1. Apakah tujuan dari proses desaindatabase? 2. Sebutkan tahapan proses desain database? RANGKUMAN Perancangan database merupakan proses untuk merepresentasikan fakta dunia nyata (real world) yang dikehendaki ke dalam sistem komputer, sehingga mudah dipahami pemakai dengan mempertimbangkan kemudahan implementasi dan pemrosesannya. Modul: Desain Database Relasional 13

24 TES FORMATIF KEGIATAN BELAJAR 1 1. Dalam menganalisis suatu domain, hal-hal yang harus diperhatikan adalah sebagai berikut kecuali A. Pendefinisian masalah D. Identifikasi entitas dan relasi B. Business process oriented E.Identifikasi produktivitas domain C. Aturan/rule yang jelas 2. Berikut ini jenis model database kecuali... A. Relational D. Hirarkial B. Heuristik E. Object oriented C. Network 3. Hal-hal berikut ini yang berhubungan dengan metodologi perancangan database kecuali... A. Cara pembuatan database D. Perancangan lojik B. Perancangan fisik E. Penentuan entitas dan relasi C. Operasi recovery 4. Output berupa ER-D dihasilkan dalam tahapan dalam perancangan basis data yaitu: A. Tahap Mendefinisikan Kebutuhan B. Tahap Rancangan Konsep Basis Data C. Tahap Rancangan Implementasi D. Tahap Rancangan Fisik Basis Data Modul: Desain Database Relasional 14

25 UMPAN BALIK DAN TINDAK LANJUT Periksalah jawaban Saudara dengan kunci jawaban test formatif KB 1. Hitunglah jumlah jawaban Saudara yang sesuai dengan kunci jawaban, kemudian gunakan rumus di bawah ini untuk mengetahui tingkat penguasaan Saudara terhadap materi. Rumus = Jumlah jawaban yang sesuaikunci Jumlah semua soal X 100% Penjelasan tingkat penguasaan % = Amat Baik 81 90,99 % = Baik 71 80,99% = Cukup 61 70,99% = Kurang 0 60,99% = Amat Kurang Kalau Saudara mencapai tingkat penguasaan 80% atau lebih, maka Saudara dapat meneruskan dengan materi pada KB 2. Tetapi apabila nilai Saudara kurang dari 80%, maka kami sarankan Saudara mengulangi materi pada KB 1, terutama materi yang Saudara belum kuasai. Modul: Desain Database Relasional 15

26 2. Kegiatan Belajar 2 ENTITY DAN RELATIONSHIP MODEL Indikator Setelah selesai mengikuti pembelajaran ini peserta diklat diharapkan mampu: menjelaskan entitas dan atribut; menjelaskan relasi antar entitas; menjelaskan fitur ER Model a) Entitas dan Atribut Definisi entitas adalah objek yang dirasa penting di sistem tersebut, yang bisa berupa : Objek Konkrit Contoh : Orang, Buku Objek Abstrak Contoh : Jadwal, Pinjaman, Tabungan Heru adalah salah satu contoh dari entitas. Sedangkan Heru, Dewi, Yati merupakan himpunan entitas orang. Dapat kita katakan bahwahimpunan Entitas (Entity Set):Sekelompok entitas yang sejenis dan berada dalam lingkup yang sama. Kumpulan entitas orang dengan karakteristik mempunyai nim, prodi, dsb bisa kita katakan merupakan himpunan entitas mahasiwa. Entitas menunjuk kepada pada individu suatu objek sedangkan himpunan entitas menunjuk pada rumpun (family) dari individu tersebut. Modul: Desain Database Relasional 16

27 Heru Dewi Entitas orang entitas orang Yati Mahasiswa Himpunan entitas orang yang mempunyai kesamaan karakteristik yaitu nim, prodi, dsb membentuk himpunan entitas mahasiswa Gambar 2.1 Himpunan Entitas Mahasiswa Sebuah entitas / himpunan entitas dapat di gambarkan / di notasikan dengan sebuah gambar persegi panjang. Berikut merupakan contoh entitas mahasiwa, jadwal dan pinjaman. Mahasiswa Jadwal Pinjaman Gambar 2.2 Contoh himpunan entitas Setiap entitas mempunyai atribut yang melekat pada entitas tersebut. Berikut gambaran konseptual database (* entitas dan atribut) yang direfleksikan kedalam bentuk fisik dari database (* tabel dan kolom). Atribut Entitas NIM NAMA PROGRAM STUDI Heru Manajemen Informatika Dewi Teknik Komputer Yati Komputerisasi Akuntansi Entitas 1 Entitas 2 Entitas 3 MAHASISWA Modul: Desain Database Relasional 17

28 Gambar Error! No text of specified style in document..1 Gambaran Himpunan entitas di Tabel Atribut merupakan gambaran karakteristik dari sebuah entitas atau himpunan entitas. Contoh : atribut untuk himpunan entitas mahasiswa adalah nim, nama, alamat, ipk, program studi, hobi, dsb. Setiap atribut mempunyai domain value set yaitu batasan batasan yang dibolehkan bagi suatu atribut. Tipe tipe atribut dapat dibedakan. Simple dan Composite Atribut Simple yaitu suatu atribut yang tidak bisa dibagi menjadi bagian yang lebih kecil lagi. Contoh atribut simple adalah Jenis Kelamin. Atribut Compositeyaitu suatu atribut yang dapat di bagi menjadi beberapa bagian. Contoh atribut composite Nama dapat di bagi menjadi nama depan dan nama belakang. Gambar Error! No text of specified style in document..2 Contoh Atribut Komposit Single value dan multivalued Atribut Single value yaitu suatu atribut yang bisa di isi paling banyak 1 nilai untuk setiap baris data. Contoh atribut single value adalah Jenis Kelamin. Atribut Multivalued yaitu suatu atribut yang bisa lebih dari 1 nilai yang sejenis untuk setiap baris data. Contoh atribut mutlivalued value adalah Alamat, No telp dan hobi. Ketiga atribut tersebut bisa berisi lebih dari 1. Contoh untuk 1 entitas orang bisa mempunyai lebih dari 1 nilai untuk atribut hobi yang isinya musik, olahraga begitu juga Modul: Desain Database Relasional 18

29 untuk telp dan alamat (* karena bisa mempunyai > 1 no telp dan > 1 alamat) Derived attribute Derived Attribute yaitu suatu atribut yang nilainya didapatkan dari hasil pengolahan atribut lain. Contoh atribut derived adalah umur yaitu didapatkan dari perhitungan tanggal lahir dan tanggal sekarang. IPK yang didapatkan dari penjumlahan nilai di bagi dengan jumlah sks yang diambil. Notasi atribut digambarkan dengan gambar elips. Atribut kunci biasa di beri tanda # atau garis bawah. Contoh himpunan entitas mahasiswa mempunyai atribut nim sebagai key, prodi, nama, ipk, dsb nama prodi ipk #nim Mahasis Gambar 2.5 Entitas mahasiswa dengan Atribut b) Relasi antar entitas ER menggambarkan entitas-entitas dengan atributnya yang saling berelasi. Relasi menggambarkan hubungan antara entitas satu dengan entitas yang lain sesuai dengan proses bisnisnya. Notasi relasi didalam diagram ER digambarkan dengan notasi belah ketupat. Perhatikan contoh relasi antara mahasiswa dengan organisasi berikut. Modul: Desain Database Relasional 19

30 Gambar Error! No text of specified style in document..3 Relasi di gambarkan dengan belah ketupat Gambar di atas menunjukkan hubungan antara entitas mahasiswa dan entitas organisasi. Relasi yang terjadi adalah relasi mempunyai, dimana mahasiwa mempunyai organisasi. Entitas mahasiwa memiliki atribut nim, nama, alamat, prodi, ipk, dsb. Sedangkan entitas organisasi memiliki atribut kd_organisasi, nama_organisasi, jenis_organisasi (* olahraga/kesenian/jurusan dsb). 1 Mahasiswa bisa mempunyai 0 atau lebih organisasi pada semester dan tahun ajaran tertentu. 1 Organisasi bisa di punyai 0 atau lebih mahasiswa pada semester dan tahun ajaran tertentu. Kardinalitas relasi adalah n ke n. Dampak dari kardinalitas n ke n ini, relasi menjadi atribut, primary key dari entitas mahasiwa dan primary key dari entitas organisasi masuk ke tabel relasi sebagai atribut. Atribut tambahan berupa semester dan tahun ajaran merupakan atribut tambahan pada tabel relasi mempunyai, atribut ini disebut atribut deskriptif. Atribut deskriptif ini muncul karena adanya kebutuhan dari proses bisnis untuk mencatat historis mahasiwa tersebut per semester dan tahun ajaran tertentu, sehingga bisa di lihat track record organisasi mahasiwa tersebut selama belajar di kampus dari semester ke semester berikutnya. Berikut merupakan contoh gambaran antara entitas mahasiwa dan entitas organisasi Dewi Yati Organisai LINUX Heru Organisai Pecinta Satwa Dewi Mempunyai organisasi Pecinta Satwa Di semester 1 tahun ajaran 2010/2011 Gambar Error! No text of specified style in document..4 Himpunan. Modul: Desain Database Relasional 20

31 Entitas Mahasiwa Berelasi dengan Himpunan Entitas Organisasi Derajat Himpunan Relasi Jika dilihat dari jumlah entitas yang dihubungkan oleh sebuah relasi, maka kita bisa membagi menjadi 3 macam: Unary(Hanya me-relasi-kan 1 entitas) Gambar Error! No text of specified style in document..5 Contoh Derajat Relasi Unary Relasi di atas menggambarkan entitas karyawan yang ber-relasi dengan entitas karyawan. Entitas karyawan bisa merupakan karyawan biasa tetapi bisa juga merupakan manajer. Relasi yang terjadi yaitu relasi karyawan bekerja untuk manajer (* entitas manajer adalah salah satu karyawan juga). Perhatikan kardinalitas relasinya, 1 karyawan hanya bekerja untuk 1 manajer, tetapi 1 manajer bisa mempunyai banyak bawahan. Binary (me-relasi-kan 2 entitas) Gambar Error! No text of specified style in document..6 Contoh Derajat Relasi Binary Relasi di atas menggambarkan entitas pelangan yang ber-relasi dengan entitas pinjaman. 1 pelanggan bisa mempunyai banyak Modul: Desain Database Relasional 21

32 nomor pinjaman, dan 1 nomor pinjaman hanya untuk 1 pelanggan. Ternary (me-relasi-kan 3 entitas) Gambar Error! No text of specified style in document..7 Contoh Derajat Relasi Ternary Relasi di atas menggambarkan entitas karyawan yang ber-relasi dengan entitas cabang dan entitas pekerjaan melalui relasi bekerja_di. 1 karyawan bekerja di sebuah id pekerjaan tertentu dan juga bekerja di sebuah cabang tertentu. Ada 3 entitas yang terlibat dari relasi di atas Kardinalitas Relasi Kardinalias relasi menggambarkan banyaknya jumlah maksimum entitas dapat ber-relasi dengan entitas pada himpunann entitas yang lain. Pada himpunan relasi biner, pemetaan kardinalitas relasi dapat berupa salah satu dari pilihan berikut : Satu ke Satu Modul: Desain Database Relasional 22

33 Gambar Error! No text of specified style in document..8 Relasi dengan Kardinalitas 1 ke 1 Relasi di atas menggambarkan bahwa untuk setiap entitas di himpunan entitas A berpasangan dengan maksimal 1 entitas di himpunan entitas B. Asumsi kita akan membuat sebuah tugas yaitu menjadi pj_cuci_piring. 1 Orang di tugaskan untuk menjadi pj_cuci_piring di maksimal 1 hari. Begitupun juga jika di balik, pada 1 hari, maksimal 1 orang yang menjadi pj_cuci_piring. Dari A ke B kardinalitasnya maksimal 1, dan dari B ke A kardinalitasnya maksimal 1. Oleh karena itu relasi ini berkardinalitas 1 ke 1. Satu ke Banyak Gambar Error! No text of specified style in document..9 Relasi dengan Kardinalitas 1 ke Banyak Relasi di atas menggambarkan bahwa untuk setiap entitas di himpunan entitas A berpasangan dengan banyak entitas di himpunan Modul: Desain Database Relasional 23

34 entitas B. Asumsi yang berbeda di pakai ketika memandang relasi ini, 1 orang bisa memperoleh pj_cuci_piring untuk > 1 hari. Tetapi 1 hari hanya di pj-kan hanya untuk maksimal 1 orang. Dari A ke B kardinalitasnya maksimal adalah banyak, dan dari B ke A kardinalitasnya maksimal 1. Oleh karena itu relasi ini berkardinalitas 1 ke banyak. Banyak ke Satu Gambar Error! No text of specified style in document..10 Relasi dengan Kardinalitas Banyak ke 1 Relasi di atas menggambarkan bahwa untuk setiap entitas di himpunan entitas A berpasangan dengan maksimal 1 entitas di himpunan entitas B. Asumsikan bahwa untuk 1 hari pj_cuci_piring boleh di berikan pada banyak orang, sedangkan 1 orang hanya di berikan tugas untuk menjadi pj_cuci_piring sebanyak maksimal 1 hari. Dari A ke B kardinalitasnya maksimal adalah 1, dan dari B ke A kardinalitasnya maksimal adalah banyak. Oleh karena itu relasi ini berkardinalitas banyak ke 1. Banyak ke Banyak Modul: Desain Database Relasional 24

35 Gambar Error! No text of specified style in document..11 Relasi dengan Kardinalitas Banyak ke Banyak Relasi di atas menggambarkan bahwa untuk setiap entitas di himpunan entitas A berpasangan dengan maksimal banyak entitas di himpunan entitas B. Asumsikan bahwa dalam 1 hari pj_cuci_piring bisa di bebankan pada banyak orang dan 1 orang bisa di bebankan untuk menjadi pj_cuci_piring lebih dari 1 hari. Dari A ke B kardinalitasnya maksimal adalah banyak, dan dari B ke A kardinalitasnya maksimal adalah banyak. Oleh karena itu relasi ini berkardinalitas banyak ke banyak. Key Penggunaan key merupakan cara untuk membedakan suatu entitas didalam himpunan entitas dengan entitas lain. Key dipilih karena unik, untuk setiap entitas sehingga bisa di bedakan dari entitas yang lain. Kita bisa mendefinisikan key sebagai satu atau gabungan dari beberapa atribut yang dapat membedakan semua row dalam relasi secara unik. Macam key ada 3 yaitu : Superkey Superkey yaitu satu atau lebih atribut (kumpulan atribut) yang dapat membedakan satiap baris data dalam sebuah relasi secara unik. Contoh super key yaitu = Nim, nama, alamat, kota Nim, nama, alamat Nim, nama Modul: Desain Database Relasional 25

36 Nim Candidate key Kumpulan atribut minimal yang dapat membedakan setiap baris data dalam sebuah relasi secara unik. Contoh Nim Primary key Primary key merupakan salah satu dari candidate key yang terpilih. Alasan pemilihan primary key : Lebih sering di jadikan acuan Lebih ringkas Jaminan keunikan key lebih baik Contoh dari primary key adalah Nim Diagram ER Merupakan diagram model konseptual untuk menggambarkan struktur logis dari database berbasis grafis. #nim nama kota #kd_org nama alamat Mahasisw m Organisasi ipk umur prodi jenis Gambar Error! No text of specified style in document.-12 Contoh Diagram ER Notasi yang digunakan di Diagram ER adalah : Garis : Link yang menghubungkan atara Entitas dengan atribut, dan entitas dengan relasi atau entitas Elips dobe : Menunjukkan atribut yang multivalued Elips dengan garis terputus : Menunjukkan atribut turunan Constraint Cardinalitas Dalam menggambarkam kardinalitas pada Diagram ER, digunakan garis panah (->) yang menunjukkan Satu atau garis biasa Modul: Desain Database Relasional 26

37 ( ) yang menunjukkan Banyak. #nim nama kota #kd_org nama alamat Mahasisw m Organisasi ipk umur prodi jenis Gambar Error! No text of specified style in document..13 Relasi 1 ke 1 1 Mahasiswa hanya boleh menjabat 1 jabatan dalam 1 periode tertentu. 1 Jabatan hanya boleh di jabat oleh 1 mahasiswa dalam 1 periode tertentu. #nim nama kota #kd_org nama alamat Mahasisw m Organisasi ipk umur prodi jenis Gambar Error! No text of specified style in document..14 Relasi 1 ke banyak 1 Jabatan hanya boleh dijabat oleh 1 mahasiswadalam 1 periode tertentu dan 1 organisasi tertentu. 1 Mahasiswa boleh menjabat 1 jabatan dalam 1 periode tertentu di organisasi yang berbeda. #nim nama kota #kd_org nama alamat Mahasisw m Organisasi ipk umur prodi jenis Gambar Error! No text of specified style in document..15 Relasi Banyak ke 1 Modul: Desain Database Relasional 27

38 1 Jenis Beasiswa boleh diberikan untuk banyak mahasiwa 1 Mahasiwa hanya boleh mendapatkan 1 Jenis beasiwa #nim nama kota #kd_org nama alamat Mahasisw m Organisasi ipk umur prodi jenis Gambar Error! No text of specified style in document..16 Relasi Banyak ke Banyak 1 Mahasiswa boleh mengambil banyak mata kuliah 1 Mata kuliah boleh diambil banyak mahasiwa Himpunan Entitas Lemah Secara umum, Himpunan Entitas Lemah tidak memiliki primary key dan selalu bergantung pada entitas lain. Notasi entitas lemah digambarkan dengan double persegi panjang, sedangkan relasi untuk himpunan entitas lemah digambarkan dengan double diamond. Diskriminator / key parsialadalah atribut atribut yg dpt membedakan entitas entitas yang terdapat di himpunan entitas lemah. Diskriminator tidak sama dengan primary key. Konsep diskriminator hanya di pakai pada himpunan entitas lemah. Primary keypada Himpunan Entitas lemah ada 2 yaitu primary key dari entitas kuat yg berelasi dan diskriminator / key parsialnya. Diskriminator di notasikan dengan garis bawah yang putus putus. #nip Pegawai nama Nama penerima Tunjangan Nomor jabatan Besar tunjangan Gambar 2.20 Contoh Himpunan Entitas Lemah Modul: Desain Database Relasional 28

39 Relasi di atas menggambarkan bahwa seorang pegawai mendapatkan fasilitas tunjangan dari perusahaan tempat dia bekerja. Tunjangan dalam hal ini adalah entitas lemah. Tunjangan sebagai entitas tidak bisa berdiri sendiri, tunjangan harus bergantung pada entitas pegawai (* tidak akan ada tunjangan jika tidak ada pegawai). Kardinalitas relasi yang terjadi pada himpunan entitas lemah biasanya merupakan banyak ke 1 / 1 ke banyak dengan kardinalitas 1 di himpunan entitas yang lebih kuat. Spesialisasi Spesialisasi merupakan proses desain top-down dengan mendesain subgrouping didalam didalam himpunan entitas yang berbeda dari himpunan entitas. Tujuan dari spesialisasi adalah memberikan gambaran konseptual tentang perbedaan karakteristik dari himpunan entitas yang hampir serupa dengan konsep sub grouping / pengelompokan. Subgrouping di atas menjadi himpunan entias yang levelnya lebih rendah dan memiliki atribut tersendiri yang tidak dimiliki pada level di atasnya. Atribut ini khas dan merupakan pembeda dari entitas di subgroup yang lain. IS A dinotasikan dengan gambar segitiga berlabel IS A. Sifat dari spesialisasi adalah inheritan atribut yaitu atribut pada level tinggi secara otomatis akan di turunkan pada level di bawahnya. Modul: Desain Database Relasional 29

40 nama #Id_pegawai Pegawai Besar tunjangan Gaji Per Bulan IS A Upah Per Jam Jumlah Jam Kerja Pegawai Tetap Pegawai Honorer Gambar 2.21 Contoh Spesialisasi Contoh di atas menggambarkan bahwa entitas pegawai mempunyai 2 subgroup yaitu pegawai tetap dan pegawai honorer. Kedua entitas pegawai tetap dan pegawai honorer sama sama mempunyai atribut turunan yaitu nama dan id_pegawai dari entitas pegawai. Perbedaan dari pegawai tetap dan pegawai honorer terdapat di atribut yang melekat pada subgroup-nya. Atribut besar tunjangan dan gaji perbulan hanya terdapat di himpunan entitas pegawai tetap, sedangkan atribut upah per jam dan jumlah jam kerja terdapat di himpunan entitas pegawai honorer. Generalisasi Generalisasi merupakan proses desain bottom-up dengan mengkombinasikan jumlah himpunan entitas yang digunakan secara bersama sama. Spesialisasi dan generalisasi sama sama digambarkan dengan notasi IS A, yang membedakan adalah sudut pandangnya saja. Jika Spesialisasi kita mendefinisikan entitas secara umum kemudian mencari subgroup dari entitas tersebut, tetapi generalisasi memandang sebaliknya, dari adanya subgroupsubgroup yang berbeda kemudian di cari entitas umum yang mewakili 2 himpunan entitas tersebut. Agregasi Agregasi adalah enkapsulasi dari entitas entitas yang berelasi (*nn). Pada umumnya terbentuk dari kardinalitas relasi banyak ke banyak. Didalam konsep agregasi terdapat istilah enkapsulasi relasi dari kedua entitas. Enkapsulasi di perlukan karena kedua himpunan entitas yang ber-relasi tersebut merupakan 1 kesatuan yang tidak bisa di pisah. Modul: Desain Database Relasional 30

41 Notasi agregasi di gambarkan dengan gambar persegi panjang yang membungkus himpunan entitas yang saling ber-relasi. Gambar 2.22 Contoh Agregasi Gambar di atas menunjukkan relasi dosen mengajar sebuah mata kuliah dan mahasiswa mengambil mata kuliah yang diajarkan oleh dosen tertentu. Agregasi di perlukan dikarenakan tidak di mungkinkan mahasiwa untuk mengambil mata kuliah tanpa adanya dosen yang bersedia untuk mengajar mata kuliah tersebut. Dalam kasus di atas menekankan bahwa himpunan entitas dosen harus ber-relasi terlebih dahulu dengan himpunan entitas mata kuliah, kemudian relasinya di pandang sebagai 1 entitas yang ber-relasi dengan himpunan entitas mahasiwa lewat relasi mengambil. Primary key dari kedua himpunan entitas dosen dan mata kuliah akan secara implisit masuk ke relasi mengajar dengan di tambah 2 atribut deskriptif (* semester dan thn_ajaran). Relasi tersebut di anggap sebagai 1 entitas seperti gambar di bawah ini. Gambar 2.23 Relasi di pandang sebagai Himpunan Entitas Modul: Desain Database Relasional 31

42 Ringkasan notasi simbol di ER Gambar 2.24 Ringkasan Notasi pada Diagram ER Modul: Desain Database Relasional 32

43 c) Penurunan Skema ER ke Tabel Penurunan skema dimaksudkan untuk mengubah sebuah konsep hubungan entitas dan relasi kedalam bentuk fisik tabel tabel yang berelasi. Inti dari Entity Relationship adalah menggambarkan hubungan di dunia nyata kedalam bentuk entitas entitas yang saling ber-relasi, dari diagram ini bisa di buat kedalam bentuk tabel yang langsung di implementasikan kedalam database. Secara umum penurunan diagram ER ke tabel memiliki aturan sebagai berikut : Setiap himpunan entitas menjadi Tabel (* baik himpunan entitas kuat atau lemah) Setiap atribut menjadi kolom di tabel Kardinalitas relasi akan menentukan jumlah tabel yang terbentuk (* akan di bahas di bawah lebih detail) 1) Representasi atribut sebagai Kolom Pada atribut bertipe simple, single danderived direpresentasikan sama persis seperti diagram ER. Tetapi untuk atribut komposit dan multivalued mempunyai aturan tersendiri. Atribut komposit akan dipecah dengan membuat atribut terpisah untuk masing masing komponennya. Contoh atribut nama pada tabel mahasiwa, di pecah menjadi 2 kolom yaitu nama depan dan nama belakang. Atribut multivalued mengharuskan untuk di pecah menjadi 2 Tabel. Atribut multivalued M dari entitas E direpesentasikan oleh tabel terpisah EM. Perhatikan gambar di bawah yang menunjukkan bagaimana penurunan sebuah atribut multivalued: Modul: Desain Database Relasional 33

44 Gambar 2.25 Atribut multivalued di pecah menjadi entitas baru 2) Representasi Himpunan Entitas sebagai Tabel Himpunan entitas kuat di representasikan kedalam tabel dengan kolom sama persis dengan atribut yang sudah di definisikan di diagram ER. Perhatikan gambar di bawah ini : Gambar 2.26 Atribut himpunan entitas kuat di representasikan kedalam tabel Himpunan entitas lemah akan menjadi tabel tersendiri yang didalamnya ada kolom primary key yang merupakan identifikasi dari himpunan entitas kuat.contoh di bawah menggambarkan himpunan entitas lemah di turunkan kedalam tabel. Modul: Desain Database Relasional 34

45 Gambar 2.27 Penurunan Himpunan Entitas Lemah ke tabel 3) Representasi Relasi (* pada kardinalitas N to N) Relasi dari Himpunan Banyak ke Banyak direpresentasikan kedalam Tabel tersendiri dengan primary key dari 2 Entitas menjadi atribut di Tabel Relasi. Perhatikan relasi banyak ke banyak berikut dan contoh penurunan ke tabel : Modul: Desain Database Relasional 35

46 Gambar 2.28 Penurunan Kardinalitas relasi N to N menjadi Tabel 4) Hubungan kardinalitas dengan tabel yang terbentuk Kardinalitas relasi dari Himpunan Entitas yang saling ber-relasi akan menentukan banyaknya tabel yang bisa di buat. Adapun aturannya sebagai berikut : 1 ke 1 Pilih primary key di 1 himpunan entitas untuk menjadi foreign key bagi himpunan entitas yang lain. 1 ke banyak / banyak ke 1 Primary key pada Tabel berkardinalitas sedikit menjadi foreign key pada tabel berkardinalitas banyak. Banyak ke banyak Sudah jelas di atas 5) Representasi Spesialisasi (IS A) Ada 2 pendekatan yang dipakai didalam menurunkan spesialisasi kedalam tabel. Pendekatan 1 Bentuklah tabel untuk level entitas yg lebih tinggi Bentuklah tabel untuk level entitas yg lebih rendah (*dengan Modul: Desain Database Relasional 36

47 memasukkan primary key pada level yg lebih tinggi ke tabel dengan level yang lebih rendah) Gambar 2.29 Representasi spesialisasi ke tabel metoda 1 Pendekatan 2 Bentuklah tabel untuk tiap himpunan entitas dengan semua atribut lokal dan turunan. Bisa jadi tabel pada level tinggi tidak perlu di simpan jika spesialisasi adalah total. Jika diperlukan bisa dibuat view yang menggabungkan tabel-tabel spesialisasi. Gambar 2.30 Representasi spesialisasi ke tabel metoda 1 6) Representasi Agregasi Untuk merepresentasikan agregasi, buatlah tabel yang terdiri dari : Foreign key dari himpunan entitas yang berhubungan Setiap atribut deskriptif Atribut baru untuk primary key di tabel relasi Modul: Desain Database Relasional 37

48 Gambar 2.31 Representasi Agregasi untk tabel mata kuliah, dosen dan Dosen mengajar mata kuliah Gambar 2.32 Representasi Agregasi untuk tabel Mahasiwa dan Mahasiwa Mengambil Mtkul Modul: Desain Database Relasional 38

49 TUGAS DAN LATIHAN RANGKUMAN Modul: Desain Database Relasional 39

50 TES FORMATIF KEGIATAN BELAJAR 2 (Waktu: 20 menit) 1. Manakah yang bukan merupakan entitas dari pilihan di bawah A. Dosen D. Penjadwalan B. Mata Kuliah E. Nasabah C. Mempunyai 2. Notas persegi panjang bisa memberikan makna A. Entitas D. Atribut B. Himpunan Entitas E. Relasi C. A dan B benar 3. Berikut ini merupakan domain value set bagi sebuah atribut didalam konse EntityRelationship, kecuali A. Simple D. Multivalued B. Composit E. Surrogate key C. Single value 4. Dibawah ini merupakan alasan yang benar tentang makna Atribut deskriptif A. Muncul hanya jika 2 entitas Atribut yang dipercaya sebagai bertemu di sebuah relasi D. key B. Dibolehkan di konsep ER E. Pernyataan di atas salah semua C. Atribut yang di turunkan dari atribut lain Modul: Desain Database Relasional 40

51 5. Pada gambar di atas, derajat himpunan relasinya adalah A. Unary D. Four-ary B. Binary E. Tidak ada jawaban yang benar C. Ternary 6. Perhatikan relasi berikut Relasi di atas merupakan contoh dari relasi A. Agregasi D. WeakEntity B. Spesialisasi E. Salah semua C. Generalisasi Modul: Desain Database Relasional 41