P. 1
normalisasi

normalisasi

|Views: 582|Likes:

More info:

Published by: 'Satria' Abdi Rezpector on May 30, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

11/21/2013

pdf

text

original

PERANCANGAN & IMPLEMENTASI BASIS DATA RELASIONAL DENGAN TEKNIK NORMALISASI

DISUSUN OLEH : ANDRI ADITYA R 09080301007 MANAJEMEN INFORMATIKA

FAKULTAS ILMU KOMPUTER

UNIVERSITAS SRIWIJAYA
2009-2010

1

DAFTAR ISI DAFTAR ISI................................................................................................. 2 Pendahuluan ................................................................................ 3 Pengertian Basis data ………………………………………….. 4 Perancangan Basisdata ………………………………………… 6 Implementasi Basis Data …………………………………….... 8 Teknik Normalisasi ….…………………... …………………… 9 Penerapan Logical Data Model Dalam Contoh Kasus ………... 13 Daftar Pustaka ………………………………………………… 21

2

Database merupakan jantung dari system informasi. masih ada beberapa orang yang memiliki tidak mempertimbangkan efektifitas dalam mendesain database. • maintain data secara akurat dan konsisten. termasuk desain data. Efektifitas dari database harus dapat memenuhi kebutuhan : • memastikan data agar dapat diakses oleh banyak user pada banyak aplikasi. Untuk menjelaskan lebih lanjut pentingnya efektifitas database. landasan yang utama adalah database dan implementasi prgoram. Database yang tidak efektif dan implementasi program yang tidak terstruktur dapat mempengaruhi performansi sistem informasi tersebut.Pendahuluan Dalam suatu sistem informasi. data yang tidak konsisten. dibuatlah beberapa contoh kasus yang dapat menunjukkan betapa pentingnya desain sebelum pembuatan database yaitu pembuatan logical data model. dibuatlah beberapa contoh kasus dalam desain logical data model. Selain dari requirement tersebut. tujuan dari desain database adalah efisiensi penyimpanan data dan efisiensi pembacaan maupun update data. dapat dilihat bahwa desain mempengaruhi database yang akan dibentuk. Pembuatan desain yang tidak dibangun dengan cermat dapat menyebabkan hilangnya data yang dibutuhkan. Salah satu langkah dalam membangun suatu sistem informasi adalah melakukan perancangan database. Dari pengamatan yang dilakukan penulis. data juga harus akurat dan konsisten. 3 . Pengaruh desain terhadap database sangatlah besar. Dari contoh kasus yang diberikan. • database dapat memenuhi kebutuhan sesuai dengan pertumbuhan user dan • database dapat memenuhi kebutuhan pembacaan data tanpa memperdulikan bagaimana data secara fisik tersimpan. Data harus tersedia ketika user ingin menggunakan. Database merupakan suatu koleksi data. • memastikan data yang dibutuhkan baik sekarang maupun yang akan datang dapat tersedia. proses update yang lambat dan banyak hal lain. Untuk menghindari hal tersebut. tipe data maupun relasinya. redundansi data.

File terdiri dari record dan field. Berbeda dengan sistem file yang menyimpan data secara terpisah. tabel terdiri dari baris dan kolom. definisi basis data adalah kumpulan data yang dihubungkan secara bersama-sama.Pengertian Basis data Basis data dapat didefinisikan dalam sejumlah sudut pandang. Sedangkan menurut Fathansyah (1999. tabel atau objek. data pada tiap kolom terdiri dari ukuran dan tipe yang sejenis (char/ numeric). Dalam sebuah tabel. Data dalam basis data disimpan dalam tiga struktur. seperti menurut Connolly (2002. yaitu file. Kumpulan data yang saling berhubungan yang disimpan secara bersama sedemikian rupa dan tanpa pengulangan (redudansi) yang tidak perlu. definisi dari basis data adalah kumpulan terintegrasi dari file yang merupakan representasi data dari suatu model enterprise.p2).p5). Objek terdiri dari data dan instruksi program yang memfungsikan data. File didalam basis data dapat terhubung kepada beberapa tabel. Kumpulan file/ tabel/ arsip yang saling berhubungan yang disimpan dalam media penyimpanan elektronis. basis data adalah :    Himpunan kelompok data (arsip) yang saling berhubungan yang diorganisasi sedemikian rupa agar kelak dapat dimanfaatkan kembali dengan cepat dan mudah. Basis data bukan menjadi milik dari suatu departemen tetapi sebagai sumber daya perusahaan yang dapat digunakan bersama. untuk memenuhi berbagai kebutuhan. Tabel terdiri dari kolom-kolom yang saling terkait.p14). seperti file yang terdiri dari record yang saling terkait. dan gambaran dari data yang dirancang untuk memenuhi kebutuhan informasi dari suatu organisasi. 4 . pada basis data data tersimpan secara terintegrasi. Menurut Date (1990.

kerusakan software dan hardware dapat terjadi Proses pemeliharaan dapat memakan waktu karena ukurannya yang besar Proses back up data memakan waktu 5 .Keuntungan dari basis data: • • • • • • • • Mengurangi duplikasi data Meningkatkan integritas data Memelihara independensi data Meningkatkan keamanan data Memelihara konsistensi data Manipulasi data lebih canggih Mudah untuk digunakan Mudah untuk di akses Kekurangan: • • • • • • Sistem lebih rumit. jadi memerlukan tenaga ahli dalam disain. kerusakan dapat terjadi Karena semua data di tempat terpusat. program dan implementasi Lebih mahal Bila ada akses yang tidak benar.

disertai IPS (indeks prestasi semester) Apabila ketiga informasi ini diteliti maka diperoleh domain data (entity) sebagai berikut: 1. 6. 2. Pisahkan/kelompokkan hasil temuan informasi menjadi beberapa entity. Tentukan field-data yang mungkin menjadi indeks (primary key) setiap entity 5. 3. Data Dosen Data Mahasiswa didukung oleh field-field data sebagai berikut: • • • Nomer Mahasiswa Nama Mahasiswa Alamat 6 . Contoh: Sistem Akademik pada umumnya membutuhkan informasi dasar sebagai berikut: • • • Daftar Peserta Mata Kuliah (DPMK) : daftar per-mata kuliah yang memuat semua nama mahasiswa yang mengambil mata kuliah tersebut pada rencana studi-nya di awal semester. Pikirkan kemungkinan relasi antar entity o bila one-to-one : berarti sebenarnya kedua entity ini bisa digabung o bila one-to-many atau many-to-one : tambahkan primary-key dari entity sisi-one sebagai field-data baru pada entity sisi many. Pilih DBMS untuk melakukan implementasi. o bila many-to-many : ciptakan sebuah file-relasi dengan field data utama adalah primary-key masing-masing entity yang berelasi. Data Matakuliah 3. Pikirkan field-data yang mendukung setiap entity 4. dimana setiap entity diciptakan sebagai sebagai sebuah table pada model relasional. Teliti informasi apa yang dibutuhkan oleh organisasi ini.Perancangan Basis Data Suatu data base dibangun berdasarkan kebutuhan informasi dalam suatu organisasi. tambahkan field data yang baru apabila field data ini bergantung pada kedua primary key. Daftar Nilai Akhir (DNA) : daftar per-mata kuliah yang memuat nama semua mahasiswa yang mengambil matakuliah tersebut disertai kode nilai yang akan dilingkari oleh dosen pengasuh di-akhir semester. oleh sebab itu pada umumnya perancangan data base dimulai dari pengamatan kebutuhan informasi. Kartu Hasil Studi (KHS) atau Rapor: print-out untuk setiap mahasiswa dimana termuat hasil studi mahasiswa tersebut untuk setiap matakuliah yang di-ikutinya. Berikut ini adalah langkah-langkah yang sering dilakukan dalam perancangan basisdata: 1. Data Mahasiswa 2. misalnya dengan mewawancarai pengguna informasi dalam organisasi tersebut.

dengan kata lain relasi-nya many-tomany (M-to-N). yaitu file semester. Karena itu primary key dari dosen (kode-dosen) ditambahkan ke entity matakuliah. dimana satu mahasiswa dapat mem-program banyak matakuliah. Karena itu diperlukan file-relasi. dan Kode-Dosen untuk entity Dosen.• • • • Jenis Kelamin Agama Tgl Lahir dsb Data Matakuliah didukung oleh field-field data sebagai berikut: • • • • Kode Matakuliah Nama Matakuliah SKS dsb Data Dosen didukung oleh field-field data sebagai berikut: • • • • • Kode Dosen Nama Dosen Alamat Keahlian dsb Ketiga entity tersebut diatas memiliki primary-key masing-masing. tetapi field dari file matakuliah akan bertambah. misalnya di program S1. dan satu matakuliah hanya diajar oleh seorang dosen. Kode-Matakuliah untuk entity Matakuliah. yaitu: NomerMahasiswa untuk entity Mahasiswa. menjadi: • • • • Kode Matakuliah Nama Matakuliah SKS Kode-Dosen 7 . dan sebaliknya satu matakuliah dapat diprogramkan oleh banyak mahasiswa. pada umumnya seorang dosen boleh mengajar lebih dari satu matakuliah. dengan fieldfield data sbb: • • • • Kode matakuliah Nomer mahasiswa Nilai kode semester Dosen <–> Matakuliah : relasi ini ditandai dengan penugasan dosen. dengan demikian relasi-nya one-to-many (1-to-M). Langkah berikutnya adalah menentukan relasi antar entity tersebut: Mahasiswa <–> MataKuliah : relasi ditandai dengan rencana studi. File data dosen nanti tidak ada perubahan.

8 . Karena itu primary key dari dosen ditambahkan ke entity mahasiswa. dimana seorang dosen boleh menjadi PA lebih dari satu mahasiswa sementara setiap mahasiswa memerlukan satu PA. Implementasi Basis Data Setelah rancangan logika dan fisik selesai. Dosen <–> Mahasiswa : relasi ini ditandai dengan fungsi dosen sebagai penasehat akademik (PA). Pernyataan dalam DDL (data definition language) termasuk SDL (storage definition language) dari DBMS terpilih dikompilasi dan digunakan untuk membuat skema basis data dan file basis data (kosong).• Dsb Kode-dosen pada file matakuliah disebut kunci-tamu atau foreign-key. tahap rancangan dan implementasi selesai dan tahap operasi dari sistem basis data dimulai. Hal ini merupakan tanggung jawab DBA bersama desainer basis data. sehingga relasi yang cocok adalah one-to-many (1-to-M). Jika data diubah dari sistem komputerisasi sebelumnya. Basis data dapat kemudian dipopulasikan dengan data. Tabel Matakuliah. sehingga susunan field-data mahasiswa menjadi sebagai berikut: • • • • • • • • Nomer Mahasiswa Nama Mahasiswa Alamat Jenis Kelamin Agama Tgl Lahir Kode-Dosen dsb Pada akhirnya basisdata akademik ini paling tidak harus terdiri atas empat tabel/file yaitu: Tabel Mahasiswa. dan Tabel Semester. Tabel Dosen. Transaksi basis data harus diimplementasikan dengan aplikasi yang dibuat programming berdasarkan spesifikasi konseptual dari transaksi dan kemudian menulis dan melakukan uji coba kode porgram dengan perintah DML. kita dapat mengimplementasikan sistem basis data. rutin konversi diperlukan untuk format kembali data untuk menyimpan ke basis data baru. Jika transaksi siap dan data disimpan ke basis data.

Depedensi merupakan konsep yang menda-sari normalisasi. X→Y 2. Ada 3 macam anomali pada suatu database: 1. Anomali penyisipan data (insert) 2. Jenis depedensi antara lain: 1. Anomali adalah proses pada basis data yang memberikan efek samping yang tidak diharap.TEKNIK NORMALISASI 1. Anomali pengubahan data (update) 3.Tujuan dari Normalisasi  Untuk menghilangkan kerangkapan data  Untuk mengurangi kompleksitas  Untuk mempermudah pemodifikasian data 3.kan (misalnya ketidakkonsistenan data karena adanya redudansi). Depedensi Transitif Atribut Z mempunyai depedensi transitif terhadap X bila: • • Y memiliki depedensi fungsional terhadap X Z memiliki depedensi fungsional terhadap Y 2. Depedensi (Ketergantungan). Anomali penghapusan data (delete) Bila ada anomali maka relasi mungkin perlu dipecah menjadi beberapa tabel lagi agar diperoleh database yang optimal. Depedensi Fungsional Suatu atribut Y mempunyai depe-densi fungsional terhadap atribut X jika dan hanya jika setiap nilai nilai X berhubungan dengan sebuah nilai Y.Pengertian Normalisasi Normalisasi merupakan proses pengelompokan data elemen menjadi tabletabel yang menunjukkan entitas dan relasinya.Bentuk tidak normal (unnormalized Form) 9 . Depedensi menjelaskan nilai suatu atribut yang menentukan nilai atribut lainnya.

alamat_klien. no_pegawai P27 nama_pegawai Amir Udinsah no_klien K01 K02 K04 P28 P29 P30 Kartika Amelia Barkah Mahendra K03 K07 K05 K06 K08 4. nomor_klien. bisa tidak lengkap atau terduplikasi. contoh : Seorang pegawai memiliki : nomor_pegawai. keperluan_klien Satu orang pegawai mungkin akan melayani lebih dari 1 orang klien. nama_pegawai. Data dikumpulkan apa adanya sesuai dengan kedatangannya. nama_klien.Bentuk ini merupakan kumpulan data yang direkam. tidak ada keharusan mengikuti suatu format tertentu. Bentuk normal pertama (1NF) • • • Setiap data disajikan dalam bentuk flat file (tabular/tabel) Seluruh atribut kunci terdefinisikan Tidak ada pengulangan group pada tabel•Semua atribut bergantung pada kunci primer (PK) Contoh : no_pegawai P27 P27 P27 P28 P28 nama_pegawai Amir Udinsah Amir Udinsah Amir Udinsah Kartika Amelia Kartika Amelia no_klien K01 K02 K04 K03 K07 nama_klien Rini Suwandi Edi Damhudi Fatwa Sari Robert Irwandi Veronica Suci nama_klien Rini Suwandi Edi Damhudi Fatwa Sari Robert Irwandi Veronica Suci Gabriela Febrianti Siti Amiarti Sandi Sunardi 10 .Bentuk – bentuk normalisasi antara lain : 1.

Bentuk normal kedua (2NF) Sebuah tabel/relasi berada dalam bentuk normal kedua jika: • • Sudah berada dalam bentuk pertama dan Semua atribut bukan kunci memiliki depedensi sepenuhnya terhadap kunci primer (PK) (Namun masih memungkinkan tabel dalam 2NF menunjukkan adanya depedensi transitif. Bentuk normal ketiga (3NF) Sebuah tabel/relasi berada dalam bentuk normal ketiga jika: • Sudah berada dalam bentuk kedua dan 11 .P29 P30 P30 Barkah Mahendra Mahendra K05 K06 K08 Gabriela Febrianti Siti Amiarti Sandi Sunardi 2. artinya ada satu atau beberapa atribut yang masih bergantung pada atribut bukan kunci) Contoh : no_pegawai P27 P28 P29 P30 no_klien K01 K02 K03 K04 K05 K06 K07 K08 nama_pegawai Amir Udinsah Kartika Amelia Barkah Mahendra nama_klien Rini Suwandi Edi Damhudi Robert Irwandi Fatwa Sari Gabriela Febrianti Siti Amiarti Veronica Suci Sandi Sunardi 3.

Sebuah tabel/relasi berada dalam bentuk BCNF jika: • • Setiap penentu (determinan) pada tabel adalah sebuah kunci kandidat (candidate key) Jika tabel hanya mengandung satu kunci kandidat maka bentuk 3NF sama dengan BCNF. Bentuk BCNF (Boyce-Codd Normal Form) BCNF adalah kasus khusus 3NF. 12 .• Contoh : no_pegawai P27 P27 P27 P28 P28 P29 P30 P30 Tidak mengandung depedensi transitif no_klien K01 K02 K04 K03 K07 K05 K06 K08 4.

Gambar 2. Relasi entiti Pegawai dan entitiDepartemen Namun ternyata ketika terjadi pergantian kepala departemen. Gambar 1. ada lebih dari satu pegawai yang mengepalai suatu departemen dan begitu pula sebaliknya. Sebagai seorang pegawai pasti mempunyai sebuah jabatan. relasi antara entiti Pegawai dengan entiti Departemen dapat dihilangkan. Penambahan entiti History Kepala Departemen Apabila ruang lingkup ditambah dengan pencatatan setiap jabatan yang dipegang selama seorang pegawai. desain gambar 1 ditambahkan suatu entiti yang mencatat tanggal seorang pegawai menjabat suatu departemen. sehingga dari entiti history jabatan dapat diketahui departemen yang saat itu menaunginya. maka gambar 2 harus diubah lagi dengan memasukkan informasi pilihan jabatan yang mungkin dijabat seorang pegawai selain kepala departemen. 13 . Oleh karena itu. data kepala departemen yang lama sudah tidak dapat lagi diketahui.PENERAPAN LOGICAL DATA MODEL DALAM CONTOH KASUS Contoh kasus 1 Gambar 1 menunjukkan relasi kepala departemen antara entiti Pegawai dengan Departemen adalah 1 : 1 yang berarti satu orang pegawai hanya dapat mengepalai satu departemen dan satu departemen hanya boleh dikepalai oleh satu orang pegawai. Oleh karena itu. Dilihat dari kenyataan yang terjadi. relasi tersebut adalah benar karena tidak mungkin pada satu waktu. Dengan kata lain. database tidak menyediakan penyimpanan data masa lampau. sehingga dapat ditelusuri siapa saja yang pernah menjabat menjadi kepala departemen suatu departemen (gambar 2).

perlu diperhatikan data mana saja yang boleh diakses seorang pegawai. Gambar 4. data mana yang tidak boleh diakses oleh seorang pegawai. setiap pegawai berhak melihat history jabatannya masingmasing maupun milik pegawai lain. Contoh kasus 2 Pada suatu database yang diakses oleh banyak user. Contoh kasus 1 memperlihatkan bahwa dalam melakukan desain perlu memastikan data apa saja yang dibutuhkan baik sekarang maupun yang akan datang dapat tersedia. namun setiap pegawai (kecuali bagian penggajian) hanya boleh melihat data gaji miliknya sendiri. oleh karena itu dibuat sebuah entiti tersendiri. Perubahan entiti History Jabatan Moss poin (d) dan Elmasri poin (a) menyatakan bahwa pembuatan model harus disesuaikan dengan fakta. Kemudian yang kedua adalah apakah database dapat memenuhi kebutuhan sesuai dengan pertumbuhan user sebagaimana yang digambarkan pada gambar 3 yaitu bahwa jenis jabatan dapat semakin beragam. 14 . Pada gambar 1 terdapat permasalahan yaitu tidak menyediakan penyimpanan data masa lampau.Gambar 3. Seperti yang dilihat pada gambar 4. Apabila ternyata database yang digunakan tidak mendukung management user. Pengaksesan history jabatan Untuk memastikan data agar dapat diakses oleh banyak user pada banyak aplikasi maka perlu diperhatikan pemilihan database yang digunakan. maka perlu disediakan entiti Hak Akses dan entiti Menu (gambar 5).

Entiti Prestasi berleasi dengan entity Jabatan Ternyata prestasi tidak sepenuhnya melekat pada prestasi.Gambar 5. Contoh kasus 3 memperlihatkan bahwa ketika mengadopsi aturan bisnis dengan obyek 15 . sehingga pada gambar 6 digambarkan bahwa entity Prestasi direlasikan dengan entiti History Jabatan. namun sebenarnya lebih tepat apabila entiti Prestasi direlasikan dengan entiti Pegawai. Penambahan hak akses menu Contoh kasus 2 memperlihatkan bahwa pemilihan database juga mempengaruhi desain database. Contoh kasus 3 Seorang pegawai berprestasi akan dikaitkan dengan jabatan apa yang dimiliki pada saat itu. Untuk mengetahui prestasi seorang pegawai didapat pada saat pegawai tersebut menjabat menjadi apa. dimana tiap database menyediakan tipe data yang berbeda. dapat dilakukan proses query. Gambar 6. antara lain adalah management user atau pemilihan tipe data.

16 .pada dunia nyata harus dilakukan dengan cermat. Nama Prestasi dan Tanggal Prestasi tiap ada nilai dari seorang penilai. sehingga relasi yang dibuat menjadi tepat (Moss poin (d) dan Elmasri poin (a) dan memastikan bahwa tiap definisi/semantik menempel pada data yang sesuai (Moss (a) dan Elmasri (d)). Entiti Prestasi berelasi dengan entity Pegawai Contoh kasus 4 Normalisasi penting dilakukan untuk memastikan bahwa sebuah atribut hanya dimiliki oleh satu entiti saja sehingga maintain data dapat dilakukan secara akurat dan konsisten. Data yang tidak ternormalisasi juga menyebabkan lambatnya proses update. Jumlah penilai tergantung pada jabatan yang dimiliki oleh pegawai yang berprestasi tersebut. ternyata terjadi redundansi data. Setiap prestasi seorang pegawai dinilai oleh beberapa penilai. dimana terjadi perulangan data atribut No Urut. Dilihat dari gambar 8. Gambar 7.

Pemisahan redundansi data pada entiti Penilaian Prestasi Contoh kasus 4 memperlihatkan bahwa dalam melakukan desain perlu memperhatikan aturan normalisasi (Moss poin (c) dan Elmasri poin (b)). sehingga konsistensi data dapat terjamin. Berbeda dengan data yang tersimpan dengan desain pada gambar 9.Gambar 8. Sedangkan gambar 10 menghasilkan tabel prestasi dengan primary key Kode Prestasi. Contoh kasus 5 Hal lain yang perlu diperhatikan adalah pemilihan atribut sebagai primary key (Moss poin (b)). proses update hanya perlu dilakukan pada satu record saja. Contoh data pada tabel Prestasi dari gambar 8 dapat dilihat pada tabel 1. Gambar 9. maka update harus dilakukan pada tiga record) dalam table Prestasi. Proses update data akan menjadi lebih sulit apabila dilakukan pada desain database seperti gambar 8. Pemilihan desain tergantung daripada desainer database. Apabila dicermati. Redundansi data pada entiti Prestasi Gambar 8 dapat diubah menjadi gambar 9 untuk menghilangkan redundansi data. Kode Prestasi pada tabel prestasi dapat dihilangkan karena dengan NIP Pegawai dan No Urut tidak menyebabkan kesulitan proses update data pada tabel Prestasi. Tabel 1. Contoh data tabel Prestasi Apabila terjadi kesalahan dalam pemasukan data atribut Nama Prestasi dari ’Technology Award 2003’ menjadi ’Technology Award 2004’. Antara gambar 9 dengan gambar 10 terdapat perbedaan primary key untuk entiti Prestasi. Gambar 9 menghasilkan tabel Prestasi dengan primary key NIP pegawai dan No Urut. 17 .

padahal dari relasi dinilai (antara entiti Prestasi dengan entiti Penilaian Prestasi) dapat dicari pula NIP Pegawai yang dinilai prestasinya dengan 18 .Gambar 10. Pada gambar 11 terdapat entiti Range Nilai yang menyimpan informasi ’arti’ tiap nilai akhir pada tiap prestasi. Gambar 11. Entiti Range Nilai tidak harus berelasi dengan entiti lain Hasil dari penilaian prestasi dari tiap penilai akan dikalkulasi sehingga menghasilkan nilai akhir (disimpan pada atribut Nilai Akhir pada entity Prestasi). Contoh kasus 7 Pembuatan relasi yang berlebihan juga menyebabkan redundasi data (Elmasri poin (b)). Gambar 12 memperlihatkan bahwa ada redundasi relasi dimana pada tabel Penilaian Prestasi disimpan atribut NIP Pegawai. bukan menyimpan tiap nilai dan arti nilai. Sehingga entiti Range Nilai cukup berdiri sendiri. Ada beberapa table yang memang harus berdiri sendiri karena table tersebut hanya sebagai tabel bantu. Primay Key Tabel Prestasi adalah Kode Prestasi Contoh kasus 6 Pendapat yang mengatakan bahwa semua table dalam suatu sistem informasi harus memiliki relasi adalah tidak sepenuhnya benar. Entiti Range Nilai tidak perlu direlasikan dengan entiti Prestasi karena yang disimpan pada entiti Range Nilai merupakan informasi range nilai dan arti nilai.

Character(n) berarti menyimpan data sejumlah n karakter. Salah satu contohnya adalah tipe data antara character dengan variable character. Pada gambar 13 terlihat bahwa Pegawai dibedakan menjadi dua jenis yaitu pegawai tidak tetap dan pegawai tetap. Redundasi relasi pada relasi pegawai berprestasi Contoh kasus 9 Pemilihan tipe data juga merupakan hal yang penting dalam melakukan desain. pegawai tidak tetap tidak akan memiliki history jabatan seperti pegawai tetap. seperti atribut NIP Pegawai. Gambar 12. Sehingga relasi pegawai berprestasi harus dihilangkan untuk menghilangkan redundansi data. Redundasi relasi pada relasi pegawai berprestasi Contoh kasus 8 Pemilihan bentuk desain dapat juga mempengaruhi penyimpanan nilai null pada data (Elmasri poin (c)). Oleh karena itu. untuk jumlah karakter data yang sama. Oleh karena itu. Sedangkan untuk atribut Nama Pegawai digunakan tipe data variable character. relasi menjabat seharusnya tidak direlasikan antara entiti Pegawai dengan entiti History Jabatan melainkan direlasikan antara entiti Pegawai Tetap dengan entiti History Jabatan. Variable character(n) berarti menyimpan data sejumlah karakter yang dimasukkan. digunakan tipe data character. 19 .menggunakan proses query. Gambar 13.

Tipe data atribut tersebut harus diubah dari Variable Character(50) menjadi Character(50). proses bisnis pada sistem dan mempersiapkan desain yang dapat digunakan pada perkembangan sistem di masa yang akan datang.Gambar 14. 20 . c. pemilihan primary key untuk suatu tabel dan f. pembuatan relasi yang redundansi. Dalam mendesain logical data model harus memperhatikan database yang akan digunakan. pemilihan tipe data. d. tidak mempersiapkan desain yang dapat digunakan pada perkembangan system di masa yang akan datang. 2. maka dapat diambil kesimpulan yaitu : 1. adanya redundansi data. e. Kesalahan yang sering terjadi dalam melakukan desain adalah a. KESIMPULAN Berdasarkan dari pembahasan sebelumnya. pembuatan relasi yang salah. b. Pemilihan tipe data Penggunaan tipe data pada gambar 14 untuk atribut Nama Prestasi pada entiti Prestasi menyebabkan penggunaan space yang tidak perlu setiap kali terjadi penambahan data dari tabel Prestasi.

com/perancangan-basis-data/ http://expresiaku.wordpress.com/category/ilmu-komputer/analisadan-perancangan-basis-data/ 21 .DAFTAR PUSTAKA http://teguhnet.com/2008/09/20/studi-kasus-dan-modeldatabase/ http://teknik-informatika.wordpress.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->