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
Pendahuluan

Dalam suatu sistem informasi, landasan yang utama adalah database dan
implementasi prgoram. Database yang tidak efektif dan implementasi program yang
tidak terstruktur dapat mempengaruhi performansi sistem informasi tersebut.
Pengaruh desain terhadap database sangatlah besar, termasuk desain data, tipe data
maupun relasinya. Pembuatan desain yang tidak dibangun dengan cermat dapat
menyebabkan hilangnya data yang dibutuhkan, data yang tidak konsisten, redundansi
data, proses update yang lambat dan banyak hal lain. Untuk menghindari hal tersebut,
dibuatlah beberapa contoh kasus yang dapat menunjukkan betapa pentingnya desain
sebelum pembuatan database yaitu pembuatan logical data model. Dari contoh kasus
yang diberikan, dapat dilihat bahwa desain mempengaruhi database yang akan
dibentuk.

Salah satu langkah dalam membangun suatu sistem informasi adalah melakukan
perancangan

database. Database merupakan jantung dari system informasi. Data harus tersedia
ketika user ingin

menggunakan, data juga harus akurat dan konsisten. Selain dari requirement tersebut,
tujuan dari desain database adalah efisiensi penyimpanan data dan efisiensi
pembacaan maupun update data.

Database merupakan suatu koleksi data. Efektifitas dari database harus dapat
memenuhi kebutuhan :

• memastikan data agar dapat diakses oleh banyak user pada banyak aplikasi,

• maintain data secara akurat dan konsisten,

• memastikan data yang dibutuhkan baik sekarang maupun yang akan datang dapat
tersedia,

• database dapat memenuhi kebutuhan sesuai dengan pertumbuhan user dan

• database dapat memenuhi kebutuhan pembacaan data tanpa memperdulikan

bagaimana data secara fisik tersimpan.

Dari pengamatan yang dilakukan penulis, masih ada beberapa orang yang
memiliki tidak mempertimbangkan efektifitas dalam mendesain database. Untuk
menjelaskan lebih lanjut pentingnya efektifitas database, dibuatlah beberapa contoh
kasus dalam desain logical data model.

3
Pengertian Basis data
Basis data dapat didefinisikan dalam sejumlah sudut pandang, seperti menurut
Connolly (2002,p14), definisi basis data adalah kumpulan data yang dihubungkan
secara bersama-sama, dan gambaran dari data yang dirancang untuk memenuhi
kebutuhan informasi dari suatu organisasi. Berbeda dengan sistem file yang
menyimpan data secara terpisah, pada basis data data tersimpan secara terintegrasi.
Basis data bukan menjadi milik dari suatu departemen tetapi sebagai sumber daya
perusahaan yang dapat digunakan bersama.

Menurut Date (1990,p5), definisi dari basis data adalah kumpulan terintegrasi dari file
yang merupakan representasi data dari suatu model enterprise.

Sedangkan menurut Fathansyah (1999,p2), basis data adalah :

 Himpunan kelompok data (arsip) yang saling berhubungan yang diorganisasi

sedemikian rupa agar kelak dapat dimanfaatkan kembali dengan cepat dan
mudah.
 Kumpulan data yang saling berhubungan yang disimpan secara bersama
sedemikian rupa dan tanpa pengulangan (redudansi) yang tidak perlu, untuk
memenuhi berbagai kebutuhan.
 Kumpulan file/ tabel/ arsip yang saling berhubungan yang disimpan dalam
media penyimpanan elektronis.

Data dalam basis data disimpan dalam tiga struktur, yaitu file, tabel atau objek.
File terdiri dari record dan field, tabel terdiri dari baris dan kolom. Objek terdiri dari
data dan instruksi program yang memfungsikan data. Tabel terdiri dari kolom-kolom
yang saling terkait, seperti file yang terdiri dari record yang saling terkait. File
didalam basis data dapat terhubung kepada beberapa tabel. Dalam sebuah tabel, data
pada tiap kolom terdiri dari ukuran dan tipe yang sejenis (char/ numeric).

4
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, program dan
implementasi
• Lebih mahal
• Bila ada akses yang tidak benar, kerusakan dapat terjadi
• Karena semua data di tempat terpusat, kerusakan software dan hardware dapat
terjadi
• Proses pemeliharaan dapat memakan waktu karena ukurannya yang besar
• Proses back up data memakan waktu

5
Perancangan Basis Data
Suatu data base dibangun berdasarkan kebutuhan informasi dalam suatu organisasi,
oleh sebab itu pada umumnya perancangan data base dimulai dari pengamatan
kebutuhan informasi. Berikut ini adalah langkah-langkah yang sering dilakukan dalam
perancangan basisdata:

1. Teliti informasi apa yang dibutuhkan oleh organisasi ini, misalnya dengan me-
wawancarai pengguna informasi dalam organisasi tersebut.
2. Pisahkan/kelompokkan hasil temuan informasi menjadi beberapa entity.
3. Pikirkan field-data yang mendukung setiap entity
4. Tentukan field-data yang mungkin menjadi indeks (primary key) setiap entity
5. 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.
o bila many-to-many : ciptakan sebuah file-relasi dengan field data utama
adalah primary-key masing-masing entity yang berelasi, tambahkan
field data yang baru apabila field data ini bergantung pada kedua
primary key.
6. Pilih DBMS untuk melakukan implementasi, dimana setiap entity diciptakan
sebagai sebagai sebuah table pada model relasional.

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.
• 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.
• Kartu Hasil Studi (KHS) atau Rapor: print-out untuk setiap mahasiswa dimana
termuat hasil studi mahasiswa tersebut untuk setiap matakuliah yang di-ikuti-
nya, disertai IPS (indeks prestasi semester)

Apabila ketiga informasi ini diteliti maka diperoleh domain data (entity) sebagai
berikut:

1. Data Mahasiswa
2. Data Matakuliah
3. Data Dosen

Data Mahasiswa didukung oleh field-field data sebagai berikut:

• Nomer Mahasiswa
• Nama Mahasiswa
• Alamat

6
 • 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, yaitu: Nomer-

Mahasiswa untuk entity Mahasiswa, Kode-Matakuliah untuk entity Matakuliah, dan
Kode-Dosen untuk entity Dosen.

Langkah berikutnya adalah menentukan relasi antar entity tersebut:

Mahasiswa <–> MataKuliah : relasi ditandai dengan rencana studi, dimana satu
mahasiswa dapat mem-program banyak matakuliah, dan sebaliknya satu matakuliah
dapat diprogramkan oleh banyak mahasiswa, dengan kata lain relasi-nya many-to-
many (M-to-N). Karena itu diperlukan file-relasi, yaitu file semester, dengan field-
field data sbb:

• Kode matakuliah
• Nomer mahasiswa
• Nilai
• kode semester

Dosen <–> Matakuliah : relasi ini ditandai dengan penugasan dosen, misalnya di
program S1, pada umumnya seorang dosen boleh mengajar lebih dari satu matakuliah,
dan satu matakuliah hanya diajar oleh seorang dosen, dengan demikian relasi-nya
one-to-many (1-to-M). Karena itu primary key dari dosen (kode-dosen) ditambahkan
ke entity matakuliah. File data dosen nanti tidak ada perubahan, tetapi field dari file
matakuliah akan bertambah, menjadi:

• Kode Matakuliah
• Nama Matakuliah
• SKS
• Kode-Dosen

7
 • Dsb

Kode-dosen pada file matakuliah disebut kunci-tamu atau foreign-key.

Dosen <–> Mahasiswa : relasi ini ditandai dengan fungsi dosen sebagai penasehat
akademik (PA), dimana seorang dosen boleh menjadi PA lebih dari satu mahasiswa
sementara setiap mahasiswa memerlukan satu PA, sehingga relasi yang cocok adalah
one-to-many (1-to-M). Karena itu primary key dari dosen ditambahkan ke entity
mahasiswa, 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, Tabel Matakuliah, Tabel Dosen, dan Tabel Semester.

Implementasi Basis Data

Setelah rancangan logika dan fisik selesai, kita dapat mengimplementasikan

sistem basis data. Hal ini merupakan tanggung jawab DBA bersama desainer basis
data. 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). Basis data dapat kemudian
dipopulasikan dengan data. Jika data diubah dari sistem komputerisasi sebelumnya,
rutin konversi diperlukan untuk format kembali data untuk menyimpan ke basis data
baru.
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. Jika transaksi siap dan
data disimpan ke basis data, tahap rancangan dan implementasi selesai dan tahap
operasi
dari sistem basis data dimulai.

8
TEKNIK NORMALISASI

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

9
 Bentuk ini merupakan kumpulan data yang direkam, tidak ada keharusan
mengikuti suatu format tertentu, bisa tidak lengkap atau terduplikasi. Data
dikumpulkan apa adanya sesuai dengan kedatangannya.
contoh :
Seorang pegawai memiliki : nomor_pegawai, nama_pegawai, nomor_klien,
nama_klien, alamat_klien, keperluan_klien
Satu orang pegawai mungkin akan melayani lebih dari 1 orang klien.

no_pegawai nama_pegawai no_klien nama_klien

P27 Amir Udinsah K01 Rini Suwandi
K02 Edi Damhudi
K04 Fatwa Sari
P28 Kartika Amelia K03 Robert Irwandi
K07 Veronica Suci
P29 Barkah K05 Gabriela Febrianti
P30 Mahendra K06 Siti Amiarti
K08 Sandi Sunardi

4.Bentuk – bentuk normalisasi antara lain :

1. 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 nama_pegawai no_klien nama_klien
P27 Amir Udinsah K01 Rini Suwandi
P27 Amir Udinsah K02 Edi Damhudi
P27 Amir Udinsah K04 Fatwa Sari
P28 Kartika Amelia K03 Robert Irwandi
P28 Kartika Amelia K07 Veronica Suci

10
P29 Barkah K05 Gabriela Febrianti
P30 Mahendra K06 Siti Amiarti
P30 Mahendra K08 Sandi Sunardi

2. 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; artinya ada satu atau beberapa atribut yang masih bergantung pada atribut
bukan kunci)
Contoh :
no_pegawai nama_pegawai
P27 Amir Udinsah
P28 Kartika Amelia
P29 Barkah
P30 Mahendra

no_klien nama_klien
K01 Rini Suwandi
K02 Edi Damhudi
K03 Robert Irwandi
K04 Fatwa Sari
K05 Gabriela Febrianti
K06 Siti Amiarti
K07 Veronica Suci
K08 Sandi Sunardi

3. Bentuk normal ketiga (3NF)

Sebuah tabel/relasi berada dalam bentuk normal ketiga jika:
• Sudah berada dalam bentuk kedua dan

11
 • Tidak mengandung depedensi transitif
Contoh :
no_pegawai no_klien
P27 K01
P27 K02
P27 K04
P28 K03
P28 K07
P29 K05
P30 K06
P30 K08

4. Bentuk BCNF (Boyce-Codd Normal Form)

BCNF adalah kasus khusus 3NF. 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.

12
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.
Dilihat dari kenyataan yang terjadi, relasi tersebut adalah benar karena tidak mungkin
pada satu waktu, ada lebih dari satu pegawai yang mengepalai suatu departemen dan
begitu pula sebaliknya.

Gambar 1. Relasi entiti Pegawai dan entitiDepartemen

Namun ternyata ketika terjadi pergantian kepala departemen, data kepala

departemen yang lama sudah tidak dapat lagi diketahui. Dengan kata lain, database
tidak menyediakan penyimpanan data masa lampau. Oleh karena itu, desain gambar 1
ditambahkan suatu entiti yang mencatat tanggal seorang pegawai menjabat suatu
departemen, sehingga dapat ditelusuri siapa saja yang pernah menjabat menjadi
kepala departemen suatu departemen (gambar 2).

Gambar 2. Penambahan entiti History Kepala Departemen

Apabila ruang lingkup ditambah dengan pencatatan setiap jabatan yang dipegang
selama seorang pegawai, maka gambar 2 harus diubah lagi dengan memasukkan informasi
pilihan jabatan yang mungkin dijabat seorang pegawai selain kepala departemen. Sebagai
seorang pegawai pasti mempunyai sebuah jabatan, sehingga dari entiti history jabatan dapat
diketahui departemen yang saat itu menaunginya. Oleh karena itu, relasi antara entiti Pegawai
dengan entiti Departemen dapat dihilangkan.

13
 Gambar 3. Perubahan entiti History Jabatan

Moss poin (d) dan Elmasri poin (a) menyatakan bahwa pembuatan model harus
disesuaikan dengan fakta. Contoh kasus 1 memperlihatkan bahwa dalam melakukan desain
perlu memastikan data apa saja yang dibutuhkan baik sekarang maupun yang akan datang
dapat tersedia. Pada gambar 1 terdapat permasalahan yaitu tidak menyediakan penyimpanan
data masa lampau. 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, oleh karena itu dibuat sebuah entiti tersendiri.

Contoh kasus 2

Pada suatu database yang diakses oleh banyak user, perlu diperhatikan data mana saja yang
boleh diakses seorang pegawai, data mana yang tidak boleh diakses oleh seorang pegawai.
Seperti yang dilihat pada gambar 4, setiap pegawai berhak melihat history jabatannya masing-
masing maupun milik pegawai lain, namun setiap pegawai (kecuali bagian penggajian) hanya
boleh melihat data gaji miliknya sendiri.

Gambar 4. Pengaksesan history jabatan

Untuk memastikan data agar dapat diakses oleh banyak user pada banyak aplikasi maka
perlu diperhatikan pemilihan database yang digunakan. Apabila ternyata database yang
digunakan tidak mendukung management user, maka perlu disediakan entiti Hak Akses dan
entiti Menu (gambar 5).

14
 Gambar 5. Penambahan hak akses menu

Contoh kasus 2 memperlihatkan bahwa pemilihan database juga mempengaruhi desain

database, antara lain adalah management user atau pemilihan tipe data, dimana tiap database
menyediakan tipe data yang berbeda.

Contoh kasus 3

Seorang pegawai berprestasi akan dikaitkan dengan jabatan apa yang dimiliki pada saat itu,
sehingga pada gambar 6 digambarkan bahwa entity Prestasi direlasikan dengan entiti History
Jabatan.

Gambar 6. Entiti Prestasi berleasi dengan entity Jabatan

Ternyata prestasi tidak sepenuhnya melekat pada prestasi, namun sebenarnya lebih tepat
apabila entiti Prestasi direlasikan dengan entiti Pegawai. Untuk mengetahui prestasi seorang
pegawai didapat pada saat pegawai tersebut menjabat menjadi apa, dapat dilakukan proses
query. Contoh kasus 3 memperlihatkan bahwa ketika mengadopsi aturan bisnis dengan obyek

15
pada dunia nyata harus dilakukan dengan cermat, 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)).

Gambar 7. 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. Setiap prestasi seorang
pegawai dinilai oleh beberapa penilai. Jumlah penilai tergantung pada jabatan yang dimiliki
oleh pegawai yang berprestasi tersebut. Dilihat dari gambar 8, ternyata terjadi redundansi
data, dimana terjadi perulangan data atribut No Urut, Nama Prestasi dan Tanggal Prestasi tiap
ada nilai dari seorang penilai.

16
 Gambar 8. Redundansi data pada entiti Prestasi

Gambar 8 dapat diubah menjadi gambar 9 untuk menghilangkan redundansi data.

Gambar 9. 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.
Proses update data akan menjadi lebih sulit apabila dilakukan pada desain database seperti
gambar 8. Contoh data pada tabel Prestasi dari gambar 8 dapat dilihat pada tabel 1.

Tabel 1. Contoh data tabel Prestasi

Apabila terjadi kesalahan dalam pemasukan data atribut Nama Prestasi dari
’Technology Award 2003’ menjadi ’Technology Award 2004’, maka update harus dilakukan
pada tiga record) dalam table Prestasi. Berbeda dengan data yang tersimpan dengan desain
pada gambar 9, proses update hanya perlu dilakukan pada satu record saja.

Contoh kasus 5

Hal lain yang perlu diperhatikan adalah pemilihan atribut sebagai primary key (Moss poin
(b)). 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.
Sedangkan gambar 10 menghasilkan tabel prestasi dengan primary key Kode Prestasi.
Pemilihan desain tergantung daripada desainer database. Apabila dicermati, Kode Prestasi
pada tabel prestasi dapat dihilangkan karena dengan NIP Pegawai dan No Urut tidak
menyebabkan kesulitan proses update data pada tabel Prestasi.

17
 Gambar 10. 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. Ada beberapa table yang memang harus berdiri sendiri
karena table tersebut hanya sebagai tabel bantu.

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). Pada gambar 11 terdapat
entiti Range Nilai yang menyimpan informasi ’arti’ tiap nilai akhir pada tiap prestasi. Entiti
Range Nilai tidak perlu direlasikan dengan entiti Prestasi karena yang disimpan pada entiti
Range Nilai merupakan informasi range nilai dan arti nilai, bukan menyimpan tiap nilai dan
arti nilai. Sehingga entiti Range Nilai cukup berdiri sendiri.

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, padahal dari relasi dinilai (antara entiti Prestasi dengan entiti
Penilaian Prestasi) dapat dicari pula NIP Pegawai yang dinilai prestasinya dengan

18
menggunakan proses query. Sehingga relasi pegawai berprestasi harus dihilangkan untuk
menghilangkan redundansi data.

Gambar 12. Redundasi relasi pada relasi pegawai berprestasi

Contoh kasus 8

Pemilihan bentuk desain dapat juga mempengaruhi penyimpanan nilai null pada data (Elmasri
poin (c)). Pada gambar 13 terlihat bahwa Pegawai dibedakan menjadi dua jenis yaitu pegawai
tidak tetap dan pegawai tetap. pegawai tidak tetap tidak akan memiliki history jabatan seperti
pegawai tetap. Oleh karena itu, relasi menjabat seharusnya tidak direlasikan antara entiti
Pegawai dengan entiti History Jabatan melainkan direlasikan antara entiti Pegawai Tetap
dengan entiti History Jabatan.

Gambar 13. Redundasi relasi pada relasi pegawai berprestasi

Contoh kasus 9

Pemilihan tipe data juga merupakan hal yang penting dalam melakukan desain. Salah satu
contohnya adalah tipe data antara character dengan variable character. Character(n) berarti
menyimpan data sejumlah n karakter. Variable character(n) berarti menyimpan data sejumlah
karakter yang dimasukkan. Oleh karena itu, untuk jumlah karakter data yang sama, digunakan
tipe data character, seperti atribut NIP Pegawai. Sedangkan untuk atribut Nama Pegawai
digunakan tipe data variable character.

19
 Gambar 14. 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. Tipe data atribut tersebut harus diubah dari Variable Character(50) menjadi
Character(50).

KESIMPULAN

Berdasarkan dari pembahasan sebelumnya, maka dapat diambil kesimpulan yaitu :

1. Kesalahan yang sering terjadi dalam melakukan desain adalah

a. tidak mempersiapkan desain yang dapat digunakan pada perkembangan system di masa
yang akan datang,

b. pembuatan relasi yang salah,

c. pembuatan relasi yang redundansi,

d. adanya redundansi data,

e. pemilihan primary key untuk suatu tabel dan

f. pemilihan tipe data.

2. Dalam mendesain logical data model harus memperhatikan database yang akan digunakan,
proses bisnis pada sistem dan mempersiapkan desain yang dapat digunakan pada
perkembangan sistem di masa yang akan datang.

20
DAFTAR PUSTAKA
http://teguhnet.wordpress.com/2008/09/20/studi-kasus-dan-model-
database/

http://teknik-informatika.com/perancangan-basis-data/

http://expresiaku.wordpress.com/category/ilmu-komputer/analisa-
dan-perancangan-basis-data/

21