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
Judul Modul:
Desain Database Relasional
Penulis:
Dr. Khamami Herusantoso Sanyoto Gondodiyoto
Cetakan Pertama: 2011
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 2011.
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
Halaman
HALAMAN JUDUL i
IDENTITAS MODUL
KATA PENGANTAR ii
DAFTAR ISI iii
DAFTAR TABEL v
DAFTAR GAMBAR vi
PETUNJUK PENGGUNAAN MODUL vii
PETA KONSEP MODUL 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
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
Halaman 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-1-1-1 Tabel 3.18 Contoh Tabel T-1-1-2
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.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
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.
Pengertian Desain Database
Model Database
Entitas dan Atribut
Relasi Antar Entitas
Fitur ER Model
Atribut Kunci
Ketergantungan Fungsional
Bentuk Normalisasi
PENGANTAR DESAIN DATABASE
KONSEP NORMALISASI ENTITY RELATIONSHIP MODEL
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.
B. KEGIATAN BELAJAR 1. Kegiatan Belajar 1
PENGANTAR DESAIN 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 Indikator
Setelah selesai mengikuti pembelajaran ini peserta diklat diharapkan mampu:
menjelaskan pengertian desain database; menjelaskan model database
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.
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.
Di lain pihak, kita biasanya menentukan perancangan aplikasi-aplikasi 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 kebutuhan-kebutuhan 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.
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
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 transaksi-transaksi 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.
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, perintah-perintah DDL memasukkan parameter-parameter rancangan fisik
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 bermacam-macam 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.
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. Transaksi-transaksi 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,
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 batasan-batasan (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
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 komponen-komponen 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.
Model database relational dikembangkan dari proposal oleh Dr. E.F. Codd yang berjudul “A Relational Model of Data for Large Shared Databanks” pada tahun 1970. 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.
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
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 X 100% Jumlah semua soal
Penjelasan tingkat penguasaan 91 – 100 % = 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.
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.
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.
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).
Mahasiswa Jadwal Pinjaman
Heru Dewi Yati Mahasiswa entitas orang Entitas orang
Himpunan entitas orang yang mempunyai kesamaan karakteristik yaitu nim, prodi, dsb membentuk himpunan entitas ‘mahasiswa’
Atribut Entitas
Entitas 1 Entitas 2 Entitas 3
MAHASISWA
NIM NAMA PROGRAM STUDI
30107001 Heru Manajemen Informatika 30207001 Dewi Teknik Komputer
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
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
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.
Mahasis
#nim prodi ipk
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
. Gambar Error! No text of specified style in document..4 Himpunan
Heru
Dewi Yati Organisai LINUX
Organisai Pecinta Satwa Dewi
Mempunyai organisasi Pecinta Satwa Di semester 1 tahun ajaran 2010/2011
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
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 :
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
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.
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 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.
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
kota #nim nama prodi ipk #kd_org nama jenis umur
(—) yang menunjukkan “Banyak”.
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.
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.
Gambar Error! No text of specified style in document..15 Relasi Banyak ke 1 kota #nim nama prodi ipk #kd_org nama jenis umur
alamat Mahasisw m Organisasi kota #nim nama prodi ipk #kd_org nama jenis umur
alamat Mahasisw m Organisasi
kota #nim nama prodi ipk #kd_org nama jenis umur
1 Jenis Beasiswa boleh diberikan untuk banyak mahasiwa 1 Mahasiwa hanya boleh mendapatkan 1 Jenis beasiwa
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.
Gambar 2.20 Contoh Himpunan Entitas Lemah
Tunjangan Pegawai #nip nama jabatan Nomor Nama penerima Besar tunjangan kota #nim nama prodi ipk #kd_org nama jenis umur
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.
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 (*n-n). 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.
Pegawai
#Id_pegawai nama
IS A
Pegawai Tetap Pegawai Honorer Gaji Per Bulan
Upah Per Jam
Jumlah Jam Kerja
Besar tunjangan
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.
Ringkasan notasi simbol di ER
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:
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
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 :
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
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
Gambar 2.31 Representasi Agregasi untk tabel mata kuliah, dosen dan Dosen mengajar mata kuliah
TUGAS DAN LATIHAN 1.
2.
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 bertemu di sebuah relasi D.
Atribut yang dipercaya sebagai key
B. Dibolehkan di konsep ER E. Pernyataan di atas salah semua C. Atribut yang di turunkan
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
7. Banyak tabel yang bisa di hasilkan dari relasi di soal nomor 4 di atas adalah _________
A. 3 Tabel D. 6 Tabel
B. 4 Tabel E. 7 Tabel
C. 5 Tabel
8 Gambar himpunan entitas berikut menggambarkan _______
A. Himpunan Entitas D. Relasi
B. Himpunan Entitas
Lemah E. Atribut
C. Himpunan Entitas Kuat
9. Banyak tabel yang bisa di hasilkan dari relasi di soal nomor 4 di atas adalah _________
A. 3 Tabel
B. 4 Tabel D. 7 Tabel
C. 5 Tabel E. Network
10 Setiap atribut pasti menjadi 1 kolom. Pernyataan tersebut _______
A Benar D. Salah pada kondisi tertentu
B Salah E. C dan D benar
UMPAN BALIK DAN TINDAK LANJUT
Periksalah jawaban Saudara dengan kunci jawaban test formatif KB 2. 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 sesuai kunci X 100% Jumlah semua soal
Penjelasan tingkat penguasaan 91 – 100 % = 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 3. Tetapi apabila nilai Saudara kurang dari 80%, maka kami sarankan Saudara mengulangi materi pada KB 2, terutama materiyang Saudara belum kuasai.
3. Kegiatan Belajar 3
KONSEP NORMALISASI
Indikator
Setelah selesai mengikuti pembelajaran ini peserta diklat diharapkan mampu:
menjelaskan atribut kunci;
menjelaskan ketergantungan fungsional; menjelaskan bentuk normalisasi.
a) Atribut Kunci
Normalisasi adalah langkah-langkah sistematis untuk menjamin bahwa struktur database memungkinkan untuk general purpose query dan bebas dari insertion, update dan deletion anomalies yang dapat menyebabkan hilangnya integritas data (E.F. Codd, 1970).
Pada dasarnya normalisasi dilakukan untuk memperbaiki desain tabel yang kurang baik sehingga penyimpanan data menjadi lebih efisien dan bebas anomali data. Untuk memperjelas pemahaman tentang proses normalisasi, perhatikan diagram berikut:
Gambar 3.1 Diagram Normalisasi
Intinya, normalisasi dilakukan terhadap desain tabel yang sudah ada dengan tujuan untuk meminimalkan redundansi (pengulangan) data dan menjamin integritas data dengan cara menghidari 3 Anomali Data: Update, Insertion dan Deletion Anomaly.
Update Anomaly
Tabel 3.1 Contoh Update Anomaly
NIM Nama_Mhs Kd_Jur Nama_Jur Kode_MK Nama_MK SKS Nilai 1-01 Heru TE Elektro TE-001 Elektronika 3 A
1-01 Heru TE Elektro DU-001 English 2 A
2-01 Dewi IF Informatika IF-001 Algoritma 3 B 2-01 Dewi IF Informatika DU-001 English 2 C 2-02 Yati IF Informatika IF-002 Database 2 A Tabel di atas adalah contoh tabel yang memiliki desain yang kurang baik. Perhatikan bahwa jika kita ingin meng-update jumlah sks mata kuliah English dari 2 menjadi 3 sks, maka kita harus mengupdate lebih dari 1 record, yaitu baris 2 dan 4.
Jika hanya salah satu baris saja yang di-update, maka data menjadi tidak konsisten (ada mata kuliah English dengan 2 sks dan ada mata kuliah English dengan 3 sks) . Kondisi seperti inilah yang disebut dengan update anomaly.
Insertion Anomaly
Tabel 3.2 Contoh Insert Anomaly
NIM Nama_Mhs Kd_Jur Nama_Jur Kode_MK Nama_MK SKS Nilai
1-01 Heru TE Elektro TE-001 Elektronika 3 A
1-01 Heru TE Elektro DU-001 English 2 A
2-01 Dewi IF Informatika IF-001 Algoritma 3 B
2-01 Dewi IF Informatika DU-001 English 2 C
2-02 Yati IF Informatika IF-002 Database 2 A
Pada tabel yang sama seperti contoh di atas, terjadi pula insertion anomaly. Misalkan terdapat mahasiswa baru dengan nim 1-02 bernama ‘Zubaedah’ dengan kode jurusan ‘TE’ dan nama jurusan ‘Elektro’.
Data mahasiswa tersebut tidak dapat dimasukkan ke dalam tabel sebab dia belum mengambil kuliah apapun (misalnya karena belum
melakukan registrasi). Kondisi inilah yang disebut dengan insertion anomaly.
Deletion Anomaly
Tabel 3.3 Contoh Delete Anomaly
NIM Nama_Mhs Kd_Jur Nama_Jur Kode_MK Nama_MK SKS Nilai
1-01 Heru TE Elektro TE-001 Elektronika 3 A
1-01 Heru TE Elektro DU-001 English 2 A
2-01 Dewi IF Informatika IF-001 Algoritma 3 B
2-01 Dewi IF Informatika DU-001 English 2 C
2-02 Yati IF Informatika IF-002 Database 2 A
Pada contoh tabel di atas terjadi deletion anomaly. Perhatikan bahwa jika kita menghapus data mahasiswa bernama ‘Yati’ maka kita harus menghapus data pada baris ke 5, hal ini akan mengakibatkan kita juga kehilangan data mata kuliah ‘Database’. Kondisi inilah yang disebut dengan deletion anomaly.
Selain 3 anomali di atas, ada beberapa konsep yang mendasari normalisasi. Adapun konsep-konsep penting yang mendasari normalisasi adalah konsep mengenai super key, candidate key, primary key, functional dependencydan tentu saja bentuk-bentuk normal yang menjadi acuan kita dalam melakukan normalisasi terhadap desain sebuah tabel. Pemahaman terhadap konsep-konsep ini sangat penting dan akan dibahas di beberapa sub bab berikutnya.
The Three Keys
Konsep tentang key adalah konsep yang penting untuk memahami keterkaitan antar atribut data dalam tabel dan akan sangat berguna dalam proses normalisasi. Dalam setiap tabel, terdapat 3 macam key:
a) Super key
Super key adalah satu atribut atau gabungan atribut (kolom) pada tabel yang dapat membedakan semua baris secara unik.
b) Candidate key
Candidate key disebut juga dengan minimal super key, yaitu super key yang tidak mengandung super key yang lain. Setiap candidate key pasti merupakan super key, namun tidak semua super key akan menjadi candidate key.
c) Primary key
Primary key adalah salah satu candidate key yang dipilih (dengan berbagai pertimbangan) untuk digunakan dalam DBMS. Tiap tabel hanya memiliki 1 primary key, namun primary key tersebut bisa saja dibentuk dari beberapa atribut (kolom).
Untuk memperjelas pemahaman kita terhadap 3 macam key di atas, perhatikan contohnya pada tabel mata_kuliah di bawah ini:
Tabel 3.4 Tabel Mata Kuliah
Kode_MK Nama_MK Semester SKS
U-001 English 2 2 U-002 Kalkulus 1 3 F-001 Algoritma 1 3 F-002 Database 2 3 F-003 Artificial Intelligence 5 2 E-001 Elektronika 4 3
Beberapa super key dari tabel di atas adalah: 1. (kode_mk)
Dari 6 baris data yang ada pada tabel di atas tak ada satupun yang memiliki kode_mk yang sama.
2. (nama_mk)
Demikian pula dengan nama_mk, masing-masing baris data memiliki nama_mk yang unik. Tidak ada satupun baris data yang memiliki kolom nama_mk dengan nilai yang sama persis.
3. (kode_mk,nama_mk,semester)
Walaupun beberapa baris data memiliki kolom semester dengan nilai yang sama (misalnya baris 1&4, baris 2&3) namun tidak ada satupun
baris data yang memiliki kombinasi kode_mk, nama_mk dan semester yang sama persis.
4. (kode_mk,nama_mk, sks)
Kombinasi kode_mk, nama_mk dan sks juga digolongkan sebagai super key dengan alasan yang kurang lebih sama dengan poin 3. 5. (kode_mk,nama_mk, semester, jml_temu)
Kombinasi kode_mk, nama_mk, semester dan jml_temu juga digolongkan sebagai super key dengan alasan yang kurang lebih sama dengan poin 3 dan 4.
Sedangkan yang bukan super key adalah: 1. (sks)
Perhatikan bahwa kolom sks tidak bisa membedakan baris data secara unik, contohnya baris data 2,3, 4 dan 6 sama-sama memiliki kolom sks bernilai 3.
2. (semester)
Kolom semester juga tidak bersifat unik, contohnya baris data 1 dan 4 sama-sama memiliki kolom semester bernilai 2
3. (semester, sks)
Kombinasi semester dan sks juga tidak membedakan tiap baris data secara unik, contohnya baris data ke 2 dan 3 sama-sama memiliki kolom semester bernilai 1 dan sama-sama memiliki kolom sks bernilai 3
Candidate key dari tabel mata_kuliah dipilih dari super key yang sudah ada. Super key yang akan menjadi candidate key adalah super key yang tidak mengandung super key lain di dalamnya.
Perhatikan 5 super key yang sudah kita peroleh dari analisis sebelumnya:
1. (kode_mk) 2. (nama_mk)
3. (kode_mk,nama_mk,semester) 4. (kode_mk,nama_mk, sks)
Super key yang hanya teridiri dari satu atribut data pasti akan menjadi candidate key sebab tidak mungkin mengandung super key yang lain. Oleh karena itu super key pada poin 1 dan 2 otomatis menjadi candidate key. Super key pada poin 3 tidak menjadi candidate key sebab dalam kombinasi (kode_mk, nama_mk, semester) terdapat super key yang lain yaitu (kode_mk). Dengan demikian, poin 4 dan 5 juga bukan candidate key.
Dari analisis ini, kita memperoleh 2 buah candidate key yaitu (kode_mk) dan (nama_mk). Salah satu dari beberapa candidate key ini akan dipilih untuk digunakan dalam DBMS sebagai primary key. Ada beberapa pertimbangan untuk memilih primary key, di antaranya adalah jaminan keunikan yang lebih kuat, representasi yang lebih baik dan lain-lain.
b) Ketergantungan Fungsional
Functional dependency (FD) atau kebergantungan fungsional adalah constraint atau batasan/ ketentuan antara 2 buah himpunan atribut pada sebuah tabel.
JIka A dan B adalah himpunan atribut dari tabel T, kebergantungan fungsional antara A dan B biasanya dinyatakan dalam notasi notasi A B. Notasi A B berarti:
A menentukan B
B secara fungsional bergantung kepada A. A B jika memenuhi syarat berikut ini :
Pada sebuah tabel T, jika ada dua baris data atau lebih dengan nilai atribut A yang sama maka baris-baris data tersebut pasti akan memiliki nilai atribut B yang sama Namun hal ini tidak berlaku sebaliknya.
Tabel 3.5 Contoh Tabel
NIM Nama_Mhs Kd_Jur Nama_Jur Kode_MK Nama_MK SKS Nilai
1-01 Heru TE Elektro TE-001 Elektronika 3 A
1-01 Heru TE Elektro DU-001 English 2 A
2-01 Dewi IF Informatika IF-001 Algoritma 3 B
2-01 Dewi IF Informatika DU-001 English 2 C
2-02 Yati IF Informatika IF-002 Database 2 A
Contoh kebergantungan fungsional yang terdapat pada tabel di atas: NIM Nama_mhs
Untuk setiap baris data, jika NIM = 1-01 pasti Nama_mhs = ‘Heru’, walaupun belum tentu semua mahasiswa yang bernama Heru memiliki NIM = 1-01
NIM Kd_jur
Untuk setiap baris data, jika NIM = 1-01 pasti Kd_jur = ‘TE’, walaupun tidak semua baris data dengan kd_jur ‘TE’ memiliki kolom NIM bernilai 1-01
NIM Nama_Jur
Untuk setiap baris data dengan kolom NIM bernilai 1-01 pasti memiliki kolom Nama_Jur = ‘Elektro’, walaupun tidak semua orang di jurusan Elektro memiliki NIM = 1-01. Demikian pula tidak semua baris data pada tabel dengan kolom Nama_Jur = ‘Elektro’ memiliki kolom NIM = 1-01 Penulisan kebergantungan fungsional dari 3 poin di atas dapat diringkas menjadi (NIM) (nama_mhs, kd_jur, nama_jur)
Dengan demikian, dari tabel tersebut dapat kita simpulkan beberapa kebergantungan fungsional (FD) sebagai berikut:
• FD1: (nim) (nama_mhs, kd_jur, nama_jur) • FD2: (kd_jur) (nama_jur)
• FD3: (kode_mk) (nama_mk, sks) • FD4: (nim,kode_mk) (nilai)
Ada beberapa jenis kebergantungan fungsional, di antaranya yaitu: a. Partial Functional dependency
c. Multivalued Functional dependency
Ketiganya adalah konsep penting dalam normalisasi, namun dalam sub bab ini kita hanya akan membahas mengenai Partial Functional dependency dan Transitive Functional dependency.
a) Partial Funcional Dependency
Partial Functional dependency atau kebergantungan fungsional parsial terjadi bila:
• B A
• B adalah bagian dari candidate key
Dengan kata lain jika (B,C) adalah candidate key dan B A maka A bergantung secara parsial terhadap (B,C) atau (B,C) menentukan A secara parsial.
Untuk lebih jelasnya perhatikan tabel berikut ini: Tabel 3.6 Tabel Nilai
NIM Nama_Mhs Kode_MK Nilai
1-01 Heru TE-001 A
1-01 Heru DU-001 A
2-01 Dewi IF-001 B
2-01 Dewi DU-001 C
2-02 Yati IF-002 A
Pada tabel di atas perhatikan bahwa:
1. Super key : (nim,kode_mk), (nim,nama_mhs,kode_mk) dan (nim,nama_mhs,kode_mk,nilai)
2. Dari super key yang sudah diperoleh pada poin 1, maka dipilih super key yang akan menjadi candidate key yaitu (nim,kode_mk) 3. FD: (nim) (nama_mhs)
Dari analisis poin 2 dan 3 maka dapat disimpulkan bahwa terjadi kebergantungan fungsional parsial dimana (nama_mhs) bergantung kepada (nim,kode_mk) secara parsial atau dapat juga dikatakan bahwa (nim,kode_mk) menentukan (nama_mhs) secara parsial.
b) Transitive Functional dependency
Transitive Functional dependency atau kebergantungan fungsional transitif terjadi jika:
A B
B C
Jika A B dan B C maka A C. Dengan kata lain A bergantung secara transitif terhadap C melalui B atau A menentukan C secara transitif melalui B.
Untuk lebih jelasnya perhatikan contoh tabel berikut ini: Tabel 3.7 Tabel Mahasiswa
NIM Nama_Mhs Kd_Jur Nama_Jur
1-01 Heru TE Elektro
1-01 Heru TE Elektro
2-01 Dewi IF Informatika
2-01 Dewi IF Informatika
2-02 Yati IF Informatika
FD1: (nim) (nama_mhs, kd_jur, nama_jur) FD2: (kd_jur) (nama_jur)
Dengan demikian dapat disimpulkan bahwa (nama_jur) bergantung secara transitif terhadap (nim) melalui (kd_jur) atau dapat juga dikatakan bahwa (nim) (nama_jur) secara transitif melalui (kd_jur).
c) Bentuk Normalisasi
Bentuk Normal adalah sekumpulan kriteria yang harus dipenuhi oleh sebuah desain tabel untuk mencapai tingkat/level bentuk normal tertentu. Parameter yang biasanya digunakan dalam menentukan kriteria bentuk normal adalah Functional dependency & The Three Keys.
Masing-masing bentuk normal memiliki kriteria dan level tertentu yang tidak mungkin dicapai tanpa memenuhi kriteria bentuk nomal level yang berada di bawahnya. Makin tinggi level bentuk normal yang dicapai maka kualitas desain tabel tersebut dinyatakan makin baik dan semakin kecil peluang terjadinya anomali dan redundansi data.
Normalisasi dilakukan dengan cara menerapkan Bentuk-Bentuk Normal secara bertahap dari level terendah sampai level yang dikehendaki. Walaupun ada beberapa bentuk normal namun jika desain tabel tertentu sudah memenuhi kriteria 3rd NF atau BCNF maka desain tabel itu biasanya dianggap sudah ‘cukup normal’.
Bentuk Normal Pertama (1st Normal Form)
Bentuk normal pertama atau First Normal Form (1st NF) adalah bentuk normal yang memiliki level terendah.
Kriteria 1st NF:
• Tidak ada atribut (kolom) pada tabel yang bersifat multi-value Sebuah atribut disebut bersifat multivalue jika dalam sebuah baris data pada kolom tersbut terdapat lebih dari satu nilai. Misalnya kolom telepon yang berisi ‘0813xx, 022xxx’ dan seterusnya.
• Tidak memiliki lebih dari satu atribut dengn domain yang sama Sebuah tabel dikatakan memiliki lebih dari satu atribut dengan domain yang sama jika pada tabel tersebut terdapat lebih dari satu kolom yang digunakan untuk menyimpan data yang jenisnya sama. Misalnya kolom telepon1, telepon2, telepon3 dan seterusnya.
Untuk lebih jelasnya perhatikan 2 versi contoh tabel T berikut ini: Tabel 3.8 Tabel Versi pertama
NIM Nama_Mhs Telp_1 Telp_2 Kd_ Jur
Nama_Jur Kode_ MK
Nama_MK SKS Nilai 1-01 Heru 0813xx 022xxx TE Elektro TE-001 Elektronika 3 A 2-01 Dewi 0812xx 021xxx IF Informatika IF-001 Algoritma 3 B 2-02 Yati 0852xx 031xxx IF Informatika IF-002 Database 2 A
