CRITICAL BOOK REPORT

PERANCANGAN BASIS DATA

Dosen Pengampu : Arnah Ritonga S.Si., M.Si.

DISUSUN OLEH :

KELOMPOK 10 (SEPULUH)

RATNA ARDITA SARI (4193530005)

SRI UTAMI DEWI (4193530006)

AININDIA HERMIATI (4193530007)

YOHANA MANGUNSONG (4193530008)

MATEMATIKA NONDIK 19B

MATEMATIKA

FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM

UNIVERSITAS NEGERI MEDAN

2020
 DAFTAR ISI

Daftar Isi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

BAB I : PENDAHULUAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

1.1 Latar Belakang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Rumusan Masalah . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
1.3 Tujuan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2

BAB II : BAHASAN MATERI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1 Identitas Buku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3

2.2 Ringkasan Buku . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Hasil Critical Book Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

BAB III : SIMPULAN DAN SARAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1 Kesimpulan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34

3.2 Saran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

DAFTAR PUSTAKA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35

Lampiran . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36

(i)
 BAB I

PENDAHULUAN

1.1 Latar Belakang

Sistem basis data merupakan sebuah sistem penyimpanan kumpulan
file-file yang saling berkaitan dengan file yang lainnya serta pengelolaan
data dengan menggunakan komputer membentuk suatu bangunan data
untuk memberikan informasi, sehingga informasi yang disediakan cepat
dan akurat. Menggunakan sistem basis data di dalam suatu perusahaan,
akan membantu perusahaan dalam pengambilan keputusan yang lebih baik,
tepat dan optimal. Sistem basis data sangat dibutuhkan oleh semua
perusahaan agar dapat bersaing dan mengungguli perusahaan lainnya di zaman
yang kompetitif ini. Tuntutan agar dapat bekerja lebih baik, maka
perusahaan membutuhkan sebuah sistem basis data.

1.2 Rumusan Masalah

1. Bagaimana kesamaan dan perbedaan penulisan konsep/defenisi dari kedua
buku?
2. Bagaimana penjelasan konsep/defenisi yang dibahas kedua buku?
3. Bagaimana pendahuluan/ilustrasi awal sebagai pengantar teorema/sifat
kedua buku?
4. Bagaimana kesamaan prinsip/teorema/dalil/sifat yang dibahas kedua
buku?
5. Bagaimana penjelasan teorema/sifat yang dibahas kedua buku?
6. Bagaimana kelengkapan/variasi soal latihan kedua buku?

(1)
1.3 Tujuan
1. Mengetahui kesamaan dan perbedaan penulisan konsep/ defenisi dari
kedua buku
2. Mengetahui penjelasan konsep/defenisi yang dibahas kedua buku
3. Mengetahui pendahuluan/ ilustrasi awal sebagai pengantar teorema/sifat
kedua buku
4. Mengetahui kesamaan dan prinsi- prinsip/teorema/dalil/sifat yang dibahas
kedua buku
5. Mengetahui penjelasan teorema/sifat yang dibahas kedua buku
6. Mengetahui kelengkapan/variasi soal latihan kedua buku
7. Mengetahui kekurangan/kelebihan kedua buku

(2)
 BAB II
PEMBAHASAN

2.1 Identitas Buku

a. Buku 1
Nama Buku : SISTEM BASIS DATA
Nama Penulis : Waljiyanto
Nama Penerbit : GRAHA ILMU
Tahun Penerbit : 2003
Jumlah Halaman : 130
Jumlah Bab :8
ISBN : 978-3289-35-X
b. Buku 2
Nama Buku : KONSEP & TUNTUNAN PRAKTIS SISTEM
BASIS DATA
Nama Penulis : Abdul Kadir
Nama Penerbit : ANDI
Tahun Penerbit : 2002
Jumlah Halaman : 215
Jumlah Bab : 11
ISBN :-
c. Buku 3
Nama Buku : SISTEM BASIS DATA
Nama Penulis : Agus Wahyu Widodo, Diva Kurnianingtyas
Nama Penerbit :UB Press
Tahun Penerbit : 2017
Jumlah Halaman : 143
Jumlah Bab :7
ISBN : 978-602-432-389-9

(3)
2.2 Ringkasan Buku
a. Buku 1
PERANCANGAN BASIS DATA
Pokok persoalan dalam perancangan adalah bagaimana merancang
struktur logikal dan fisikal dari satu atau lebih basis data untuk memenuhi
kebutuhan informasi yang diperlukan oleh pemakai sesuai dengan
aplikasi-aplikasi yang telah ditentukan.
Dari problem di atas dapat dikatakan bahwa tujuan perancangan basis
data adalah:
a. memenuhi kebutuhan informasi sesuai dengan yang diperlukan oleh
pemakai untuk aplikasi tertentu;
b. mempermudah pemahaman terhadap struktur informasi yang tersedia
dalam basis data;
c. memberikan keterangan tentang persyaratan pemrosesan dan kemampuan
sistem, seperti lama pengaksesan data, kapasitas memori yang harus ada,
dan sebagainya.
Diperlukan tahapan proses perancangan basis data yang dapat
diharapkan memperoleh hasil yang sesuai dengan tujuan, yaitu :
a. Koleksi dan analisis persyaratan
b. Perancangan konsepsual basis data
c. Pemilihan SMBD
d. Perancangan logikal basis data
e. Perancangan fisikal basis data (pemetaan model data)
f. Implementasi sistem basis data
Dalam pelaksanaan perancangan basis data terdapat dua kegiatan yang
secara paralel harus dilakukan, yaitu :
1. Perancangan struktur dan isi data, atau disebut juga analisis data.

2. Perancangan pemrosesan data dan program aplikasi (transaksi data), atau

disebut juga analisis fungsional.

Inti dari perancangan basis data adalah tahapan 2,4, dan 5:

a. Rancangan Konsepsual Basis Data (tahap 2)

Pada tahapan ini akan dihasilkan skema konsepsual dari basis data
yang bebas dari SMBD tertentu. Dalam hal ini digunakan pemodelan
bahasa tingkat tinggi seperti model E-R ("Entity Relationship") atau EER
("Enhanced Entity Relationship"). Pada tahap ini juga ditentukan transaksi
data yang dapat dilakukan terhadap sistem basis data.

(4)
b. Rancangan Logikal (tahap 4)
Rancangan logikal disebut juga pemetaan model data, yaitu
mentransformasikan model data yang telah dibuat pada tahap 2 ke dalam
model data yang sesuai dengan SMBD yang dipilih. Misalnya saja dalam
penyusunan basis data akan digunakan SMBD relasional, maka model data
konsepsual dibuat sesuai dengan konsep pemodelan data relasional. Pada
tahap ini juga dilakukan perancangan skema eksternal (jendela pemakai)
untuk aplikasi yang ditentukan.
c. Rancangan fisikal basis data (tahap 5)
Pada tahap ini dilakukan pendefinisian basis data yang akan disimpan
sesuai dengan SMBD yang digunakan, yang meliputi struktur
penyimpanan data, format data, dan jalur akses. Tahap ini disebut skema
internal pada istilah arsitektur SMBD.

 Koleksi dan analisis persyaratan

Pada tahapan ini dapat ditempuh dengan melakukan kegiatan sebagai

berikut:

a. Melakukan identifikasi bidang aplikasi dan kelompok pemakai. Kemudian

dipilih anggota kelompok pemakai yang dapat dipakai sebagai kunci
pemakai utama yang dapat mewakili kelompoknya. Selanjutnya adalah
melakukan pengumpulan persyaratan dan membuat spesifikasi data dan
proses dari tiap kelompok pemakai.
b. Mempelajari dan menganalisis dokumen yang adapada aplikasi tertentu.
Dokumen dapat berupa daftar isian, laporan, bagan organisasi, pedoman
kenja, peraturan-peraturan yang ada, dan sebagainya. Hasil dari analisis
akan dapat berupa spesifikasi proses dan data yang harus disimpan.
c. Mempelajari sistem yang sedang berjalan, baik masih menggunakan
sistem manual ataupun sudah menggunakan sistem komputer. Dalam hal
ini dilakukan analisis jenis transaksi yang ada, jumlah transaksi, dan alur
informasi dalam sistem. Kemudian dibuat spesifikasi data masukan dan
data keluaran.
d. Membuat semacam pertanyaan/angket pada calon pemakai yang
dipandang potensial untuk memperoleh spesifikasi informasi dan proses
yang diperlukan. Dalam hal ini dapat juga dilakukan dengan wawancara
secara langsung dengan personal kunci calon pemakai.

(5)
 Dalam melakukan analisis data dan persyaratan di atas biasanya
dilakukan dengan membuat diagram yang dapat berupa diagram hirarkhi
data masukan-keluaran, ataupun diagram alir data ("data flow diagram").
Teknik analisis spesifikasi persyaratan juga dapat dilakukan secara
otomatis dengan bantuan perangkat lunak yang khusus dirancang untuk
maksud tersebut, missal DESINGNER 2000 pada perangkat lunak
ORACLE.

 Perancangan konsepsual basis data

a. Rancangan skema konsepsual
Hasil rancangan konsepsual menupakan pemodelan data dari
penahaman dunia nyata yang dituliskan dalam bahasa tingkat tinggi dan
tidak terikat dengan SMBD yang akan digunakan. Pembuatan skema
konsepsual ini pada umumnya digunakan diagram CR. Dalam penyusunan
rancangan konsepsual ini dimulai dengan identifikasi komponen utama
dari skema, yaitu jenis entiti, jenis hubungan, dan atribut tiap entiti. Setiap
entiti juga ditentukan identitasnya, derajat dan partisipasi hubungan, dan
konstrin. Pada proses ini tidak jarang terjadi perbedaan pandangan antar
pemakai, sebagai contoh:
1. Perbedaan pemberian nama. Misal pemakai yang satu memberikan nama
jenis entiti PERSIL sebagai representasi petak tanah, sedang pemakai lain
menyebut BIDANG.
2. Perbedaan klasifikasi. Misal pemakai satu mengklasifikasikan
FAKULTAS sebagai jenis entiti, tetapi pemakai lain memandang sebagai
atribut.
3. Perbedaan nilai data. Hal ini sering terjadi pada pendefinisian tipe data.
Misalnya saja pada skema yang satu memberi nilai atribut sebagai integer,
tetapi pada skema pemakai lain sebagai karakter.

4. Perbedaan konstrin. Misal terjadi perbedaan dalam hal penentuan identitas

tiap entiti, atau perbedaan dalam penentuan derajat dan partisipasi
hubungan.

(6)
 Oleh karena itu, sebagai acuan dalam perancangan konsepsual dipakai
karakteristik sebagai berikut :

1. Model data harus cukup memberikan tampilan yang menggambarkan

perbedaan jenis data, hubungan dan konstrin (ekspresif).
2. Model harus dibuat sederhana dan mudah dipahami serta digunakan oleh
pemakai yang awam sekalipun (sederhana).
3. Penyajian model data dibuat dalam diagram yang mudah diinterpretasi
(penyajian diagramatik).
4. Penyajian model data dalam skema harus teliti dan tidak menimbulkan
interpretasi yang bias (akurat).

b. Rancangan transaksi.
Secara umum model transaksi dapat di kelompokkan menjadi tiga

fungsi, yaitu :

1. Transaksi pemanggilan ("retrieval transac-tion"), yaitu pemanggilan data

untuk ditampilkan di layar monitor atau dicetak sebagai laporan. Misal
pemanggilan nama dosen yang mengajar mata kuliah tertentu.
2. Traksaksi pembaharuan ("update transaction"), yaitu digunakan untuk
pemasukan data baru atau perubahan data yang ada dalam basis data.
Misal pemasukan nama dosen baru untuk mengajar mata kuliah tertentu.
3. Transaksi gabungan ("mixed transaction"), yaitu digunakan untuk
kombinasi pemanggilan data dan pembaharuan data. Misalnya saja dalam
kasus revisi perubahan pengisian KRS mahasiswa. Pekerjaan pertama
adalah melakukan pemanggilan semua mahasiswa yang ikut suatu mata
kuliah, kemudian dilakukan penghapusan yang membatalkan kuliah dan
pembaharuan data mahasiswa yang mengambilmata kuliah.

 Pemilihan SMBD

Dalam hal ini juga diperhatikan tentang jenis model SMBD (hirarkhi,
jaringan, relasional, orientasi obyek atau yang lain), struktur penyimpanan
data dan alur akses data, jendela perantara untuk pemakai dan pemrogram,
jenis Bahasa tingkat tinggi untuk menyusun pertanyaan, dan sebagainya.

(7)
 Faktor faktor ekonomi dan organisasi dalam penentuan SMBD yang
harus digunakan sebagai berikut:

a. Struktur data

b. Keahlian personil terhadap sistem

c. Pelayanan purna jual

 Pemodelan logikal basis data

Tujuan dari tahap ini adalah menyusun rancangan konsepsual dan

skema eksternal yang sesuai dengan SMBD yang dipilih. Dalam pekerjaan
ini dilakukan tranformasi model konsepsual dan skema eksternal yang
dihasilkan pada tahap sebelumnya ke dalam model data yang sesuai
dengan SMBD yang digunakan. Secara umum dilakukan dengan dua
langkah, yaitu :

a. Pemetaan (transformasi data) yang tidak terikat sistem.

b. Penyusunan skema sesuai dengan SMBD.

 Perancangan fisikal basis data

Perancangan fisikal basis data bertujuan untuk membuat spesifikasi

struktur penyimpanan dan jalur akses data sehingga diperoleh kemampuan
sistem yang baik untuk berbagai aplikasi. Tiap SMBD akan menawarkan
berbagai pilihan untuk melakukan organisasi berkas dan jalur akses data
yang meliputi variasi cara membuat indeks, pengelompokan rekaman
dalam blok cakram penyimpan, mengkaitkan data yang berhubungan
dengan "pointer", dan sebagainya. Apabila suatu jenis SMBD sudah
dipilih, maka penyusunan basis data harus mengikuti fasilitas dan
ketentuan yang ada pada sistem yang telah dipilih. Beberapa hal yang
menjadi pertimbangan dalam perancangan fisikal adalah :

a. Waktu tanggap (response time

b. Penggunaan memori komputer

c. Transaksi data

(Waljiyanto;2000)

(8)
b. Buku 2
1. Proses Perancangan Basis Data
Proses perancangan basis data, terlepas dari masalah yang ditangani,
dibagi menjadi 2 tahapan:
1. perancangan basis data secara konseptual,
2. perancangan basis data secara logis, dan
3. perancangan basis data secara fisis.
Perancangan basis data secara konseptual merupakan upaya untuk
membuat model yang masih bersifat konsep. Perancangan basis data
secara logis merupakan tahapan untuk memetakan model konseptual ke
model basis data yang akan dipakai (model relasional, hirarkis, atau
jaringan). Namun sebagaimana halnya perancangan basis data secara
konseptual, perancangan ini tidak tergantung pada DBMS yang akan
dipakai. Itulah sebabnya perancangan basis data secara logis terkadang
disebut pemetaan model data [17]. Perancangan basis data secara fisis
merupakan tahapan untuk menuangkan perancangan basis data yang
bersifat logis menjadi basis data fisis yang tersimpan pada media
penyimpan eksternal (yang spesifik terhadap DBMS yang dipakai).Untuk
memahami kedua tahapan perancangan basis data tersebut, perlu kiranya
mengenal daur hidup pengembangan sistem (biasa disebut SDLC/System
Development Life Cycle) secara utuh. Hal ini disebabkan perancangan
basis data hanya merupakan bagian dari tahapan perancangan sistem, dan
tahapan perancangan sistem itu sendiri merupakan salah satu dari sejumlah
tahapan pada daur hidup pengembangan sistem.

1. Pengembangan Sistem
Pengembangan sistem terdiri atas sederetan kegiatan yang dapat
dikelompokkan menjadi beberapa tahapan. Ada berbagai pembagian
tahapan dalam pengembangan sistem, yaitu: Metodologi yang disebut
waterfall atau air terjun [20, 22] yang membagi daur hidup pengembangan
sistem menjadi 6 tahapan: konsepsi, pendahuluan, analisis, perancangan,
implementasi,dan pengujian. McLeod[18] mengemukakan 4 tahapan:
perencanaan, analisis, perancangan dan implementasi. Fabbri dan
Schwab[1] membaginya menjadi 5 tahapan: studi kelayakan, rencana
pendahuluan, analisis sistem, perancangan sistem dan implementasi
sistem.

(9)
1. Tahapan Studi Kelayakan
Pada tahapan studi kelayakan, identifikasi terhadap kebutuhan sistem
baru mulai dilakukan. Identifikasi tidak hanya didasarkan oleh kebutuhan-
kebutuhan baru yang dikehendaki olch manajemen (yang sclama ini belum
terpenuhi), tetapi juga harus memperhatikan kebutuhan pada sistem yang
sudah ada, baik sistem manual maupun sistem otomasi. Hasil tahapan ini
berupa daftar kebutuhan, perkiraan biaya untuk membuat sistem baru, dan
juga solusi yang dikchendaki. Perkiraan biaya antara lain didasarkan oleh
DBMS yang digunakan (Oracle, Visual FoxPro, dan sebagainya) dan juga
komputer yang dipakai (mainframe, minikomputer, atau mikrokom puter).
2. Tahapan Rencana Pendahuluan
Tahapan rencana pendahuluan menentukan lingkup proyek atau sistem
yang akan ditangani. Hal ini digunakan untuk menentukan jadwal proyek.
Adapun lingkup sistem yang ditangani dijabarkan dalam bentuk DFD
konteks (atau sering disebut juga diagram konteks). DFD (Data Flow
Diagram) sering diterjemahkan menjadi diagram aliran data. DAD
merupakan alat yang biasa dipakai untuk mendokumentasikan proses
dalam sistem. DAD menekankan pada fungsi-fungsi di dalam sistem, cara
menggunakan informasi yang tersimpan dan pemindahan informasi
antarfungsi di dalam sistem. DAD konteks adalah DAD yang
memperlihatkan sistem sebagai sebuah proses. Tujuannya adalah
memberikan pandangan umum sistem. DAD konteks memperlihatkan
sebuah proses yang berinteraksi dengan lingkungannya. Ada pihak luar
atau lingkungan yang memberi masukan dan ada pihak yang menerima
keluaran sistem. Dalam hal ini pihak luar (sering disebut terminator) dapat
berupa sistem lain. suatu perangkat keras, orang, atau organisasi.
Gambar 3.1 memperlihatkan contoh DAD konteks, yang menggambarkan
secara umum sistem yang dipakai untuk menangani pembayaran royalti
buku.
Gambar 3.1 DAD konteks sistem penanganan royalti buku.
Diagram konteks di atas memberikan gambaran bahwa sistem
berinteraksi dengan empat terminator: Bagian Penjualan, Manajer
Keuangan, Bank, dan Pengarang. Tanda panah menyatakan masukan dan
keluaran sistem. Sebagai contoh, sistem menerima masukan berupa
laporan penjualan dari Bagian Penjualan. Pada tahapan selanjutnya,
tahapan analisis sistem. DAD konteks akan dijabarkan ke pandangan yang
lebih detail. Dalam beberapa literatur, DAD yang lebih detail daripada
DAD konteks disebut DAD analisis dan DAD model, sedangkan pada
sejumlah literatur yang lain disebut sebagai DAD saja.

(10)
3. Tahapan Analisis Sistem
Pada tahapan analisis sistem, analis sistem (orang yang
bertanggungjawab terhadap pengembangan sistem secara menyeluruh)
sering berdialog dengan pengguna untuk memperoleh informasi detail
kebutuhan pengguna. Pengumpulan kebutuhan pengguna biasa dilakukan
melalui wawancara, observasi, dan kuesioner. Hasil yang didapatkan
dipakai sebagai bahan untuk menyusun DAD untuk sistem baru. Gambar
3.2 memperlihatkan sebuah contoh DAD yang merupakan penjabaran dari
DAD konteks di depan.

No. DAD :1

Nama DAD : Penanganan Royalti Buku

Laporan
Penjualan

Mencatat Buku
Terjual
Data buku
terjual

Jadwal
pembayaran

Catatan
Waktu
Royalti
pembayaran
Royalti
2 terbayar
Membuat
laporan royalti
jatuuh tempo royalti
Belum
terbayar

Ringkasan
royalti royalti
belum
terbayar
Daftar
Rencana transfer
pembayaran
3

Memproses
persetujuan
pembayaran bukti transfer

alamat
Surat
pemberitahuan
Nomor
rekening Data
Pengarang pembayaran

Rekening bank

Pembayaran

(11)
Proses yang terdapat pada DAD Gambar 3.2 biasa dijabarkan lebih rinci
ke dalam DAD yang lain. Sebagai contoh, Gambar 3.3 memperlihatkan
DAD untuk proses dengan nomor identifikasi 3 (Memproses pembayaran).

No. DAD : 1.3

Nama DAD : Pemrosesan pembayaran

Catatan
Royalti

Ringkasan royalti
3.1 Royalti
royalti Belum
terbayar
terbayar
Membuat
rincian royalti

Per pengarang
Daftar
pembayaran Daftar
Rincian Rencana
royalti pembayaran

persetujuan
Salinan
bukti 3.2
transfer transfer
3.3 Mentransfer
uang
Membuktikan
surat
bukti transfer
pemberitahuan Nomor
rekening
Surat
pemberitahuan
alamat
Data
pembayaran
Pengarang
Rekening bank

Pembayaran

Perlu diketahui bahwa simbol – simbol yang digunakan pada DAD

mempunyai nama sebagaimana diperlihatkan pada Gambar 3.4.

Terminator

Proses Data

(12)
 Aliran Data

Penyimpan Data

Ada berbagai bentuk lain yang digunakan untuk menggambarkan DAD.

Model yang digunakan pada buku ini didasarkan atas Yourdon Systems

Method [26].

ENTRI KAMUS ALIRAN DATA

Kegunaan : untuk menjelaskan setiap aliran data pada diagaram aliran data

NAMA ALIRAN DATA Trander

KETERANGAN Dokumen ini merupakan bukti

pentrasferan royalti kepada pengarang

DARI Bank

KE 1 Mencatat buku terjual

STRUKTUR DATA Tanggal transfer

Bank pentransfer

Pengirim

Alamat pengirim = jalan + kota

Penerima = Nama Penerima + Bank + Alamat

Bank, Nomor Rekening , Nilai Transfer

KOMENTAR

Untuk memperinci DAD, item-item yang terdapat pada aliran data

(digambarkan dengan garis dan panah) dan juga yang terdapat pada
penyimpan data dijabarkan dalam bentuk kamus data. Kamus data adalah
deskripsi formal mengenai seluruh elemen yang tercakup dalam DAD.
Pada tahapan perancangan, elemen-elemen pada kamus data akan menjadi
bahan untuk menyusun basis data. Gambar 3.4 memperlihatkan contoh
entri kamus data untuk aliran data bukti transfer yang tercantum pada
Gambar 3.2.

(13)
 McLeod menyebut kamus data yang digunakan untuk menyatakan clemen-
elemen data pada aliran data DAD dengan istilah kamus aliran data dan kamus
data untuk penyimpan data sebagai kamus penyimpan data. Deskripsi setiap
elemen đinyatakan dengan kamus elemen data.
4. Tahapan Perancangan Sistem
Tahapan perancangan sistem dibagi menjadi dua bagian:
1. Perancangan basis data, dan
2. Perancangan proses.
Perancangan basis data merupakan langkah untuk menentukan basis
data yang diharapkan dapat mewakili seluruh kebutuhan pengguna.
Penyusunan basis data ini berlandaskan kamus aliran data yang telah
dibuat pada tahapan sebelumnya.

Perancangan basis data, sebagaimana telah dibahas pada Subbab 3.1,

terdiri atas perancangan basis data secara konseptual, perancangan basis
data secara logis, dan perancangan basis data secara fisis.

Perancangan basis data secara konseptual terdiri atas tiga langkah berikut:

1. penentuan entitas pada basis data,

2. pendefinisian hubungan antarentitas, dan

3. penerjemahan hubungan ke dalam entitas.

 Model Data Logis

Aribut Hubungan

Enitas Kekangan

Kunci Kunci Integritas Do

Kandidat Asing Referensial

Penambahan Peremajaan Penghapusan

Kunci
Alternatif
Kunci
Primer
Nama Tipe Format Panjang Nilai

Gambar 3.6 Berbagai komponen pada perancangan basis data secara

konseptual

(14)

Langkah-langkah di atas melibatkan komponen-komponen

sebagaimana diperlihatkan pada Gambar 3.6. Konsep dan Tuntunan
Praktis Basis Data.

Penjelasan mengenai beberapa komponen di atas adalah sebagai berikut:

1. Entitas
Entitas terkadang disebut tipe entitas atau kelas entitas. Entitas
menyatakan objek atau kejadian. PELANGGAN, PENGAWAL,
DEPARTEMEN, PENGARANG,BUKU, MATAKULIAH merupakan
contoh entitas. Pada model relasional, entitas akan menjadi tabel.
2. Atribut
 Atribut adalah item data yang menjadi bagian dari suatu entitas. Istilah
lain atribut adalah properti. Nama Pegawai ataupun NIP adalah contoh
atribut yang terdapat pada entitas PEGAWAI. Jumlah SKS. Kode
Matakuliah merupakan contoh atribut pada entitas MATAKULIAH.
3. Hubungan
Hubungan adalah asosiasi atau kaitan antara dua entitas. Misalnya,
antara DOSEN WALI dan MAHASISWA terdapat hubungan berupa
bimbingan Pada model relasional. hubungan akan menjadi kunci tamu
(Definisi kunci tamu dibahas di belakang).
4. Kekangan
Kekangan digunakan untuk melindungi integritas data (misalnya,
melindungi kesalahan sewaktu pengisian data).
5. Domain
Domain adalah himpunan nilai yang berlaku bagi suatu atribut. Kekangan
domain mendefinisikan nama, tipe, format, panjang, dan nilai masing-
masing item data. Anda akan sering menemui tipe seperti CHAR, dan
NUMERIC pada berbagai perangkat lunak basis data. CHAR menyatakan
tipe alfanumerik atau karakter (dapat berupa gabungan huruf simbol dan
angka). NUMERIC menyatakan tipe bilangan.
Sebagai contoh:
a. Kode suku cadang dinyatakan dengan KD SUKU_CD. bertipe
alfanumerik,
panjang 5 karakter, dengan format AA99 (A-huruf. 9-Ddigit).
b. Agama dinyatakan dengan nama AGAMA, panjang 1 karakter. dengan
kemungkinan nilai berupa 1. K. P. H. dan B (masing-masing untuk
menyatakan Islam, Katolik. Kristen. Hindu. dan Budha).

(15)
6. Integritas referensial
Integritas referensial adalah aturan-aturan yang mengatur hubungan
antara kunci primer dengan kunci tamu milik tabel-tabel yang berada
dalam suatu basis data relasional untuk menjaga konsistensi data. Tujuan
integritas referensial adalah untuk menjamin agar elemen dalam suatu
tabel yang menunjuk ke suatu pengenal unik pada suatu baris pada tabel
lain benar-benar menunjuk ke suatu nilai yang memang ada. Sebagai
contoh. dapatlah didefinisikan suatu aturan yang tidak memperkenankan
data pelanggan pada tabel PELANGGAN dihapus kalau data pelanggan
tersebut dipakai pada tabel lain (disebut integritas referensial
penghapusan) Contoh lain, seorang mahasiswa tidak diizinkan mendaftar
 matakuliah yang tidak ditawarkan pada semester ini (integritas referensial
penyisipan).
Macam integritas referensial ada tiga, yaitu :
a. penambahan (insert).
b. penghapusan (Delete). Dan
c. peremajaan (Update).
Pembagian ini didasarkan oleh operasi yang akan dilakukan. Integritas
referensial pada peremajaan memungkinkan pengubahan suatu kunci pada
suatu tabel menyebabkan semua niiai pada tabel lain yang tergantung pada
tabel tersebut juga akan diubah (dikenai dengan istilah cascade upadate).

Kunci kandidat, kunci utama, kunci altermatif, dan kunci tamu akan
dijelaskan di belakang.
Perancangan basis data secara konseptual bersifat tidak tergantung oleh
DBMS. Contoh pendefinisian entitas bernama MAHASISWA :

PEGAWAI

NOMOR_PEG KARAKTER(6)

NAMA_PEG KARAKTER(25)

GAJI ANGKA (6)

Contoh di atas menyatakan bahwa entitas PEGAWAI memiliki atribut:

• NOMOR_PEG dengan panjang 6 karakter

• NAMA PEG dengan panjang 25 karakter. dan

• GAJI dengan panjang 6 digit.

(16)

Pendefinisian basis data secara konseptual tidak mempunyai

standar. Pendefinisian basis data secara konseptual bisa juga mengarah
pada perangkat lunak tertentu yang akan dipakai untuk
mengimplementasikan basis data. Pendefinisian entitas dengan bentuk
seperti berikut lazim digunakan oleh mereka yang menggunakan bahasa
pemrograman keluarga dBASE.

Entitas : PEGAWAI

Atribut Tipe Le Jangka Keteran

bar uan gan
NOMOR_ Chara 6 Nomor
PEG cter pegawa
 i
NAMA_P Chara 25 Nama
EG cter pegawa
i
GAJI Nume 6 Gaji
ric
AGAMA Chara 1 I.K.P. Agama
cter B.H I =
Islam
K=
Katolik
P =
Protest
an
B=
Budha
H=
Hindu

TGL_LA Date Tangga

HIR l Lahir
Gambar 3.7 Contoh pendefinisian basis data secara konseptual

(17)

Contoh di atas menjelaskan bagaimana mendefinisikan item-item yang

ada pada suatu entitas. Namun sekarang yang mungkin menjadi
pertanyaan adalah bagaimana asal-muasal pendefinisian suatu entitas.
Penentuan entitas dilakukan dengan mengamati DAD yang telah dibuat.
Bila kamus data telah dibuat, penentuan entitas dapat dilakukan dengan
mudah. Sesungguhnya entitas dapat muncul dari aliran data maupun
penyimpan data. Perlu diketahui sebelumnya bahwa penyimpan data
belum tentu akan menjadi sebuah entitas, karena penyimpan data hanyalah
menyatakan wadah berbagai elemen secara logis dan bukan secara fisis.
Elemen-elemen yang ada pada suatu penyimpan data bisa saja kelak
tersimpan pada beberapa tabel dalam basis data.

Berikut merupakan contoh sejumlah entitas pada keadaan awal yang

terdapat pada sistem penanganan royalti buku di depan. Untuk
 menyederhanakan pembahasan, tipe masing-masing elemen tidak
dicantumkan.

CATATAN ROYALTI REKENING_BANK

PERIODE
NAMA_PENGARANG
IDENTITAS_BUKU NAMA-
_BANK
JUDUL_BUKU
ALAMAT_BANK
NAMA_PENGARANG
NO_REKENING
TOTAL_BUKU_TERJUAL
BESAR_ROYALTI PEMBAYARAN
PENGARANG
NAMA_PENGARANG
NAMA_PENGARANG
TANGGAL_TRANSFER
ALAMAT
NAMA_BANK_KIRIM
TELPON
NO_TRANSFER
JADWAL_PEMBAYARAN NILAI_TRANSFER
NAMA_PENGARANG
BULAN_PEMBAYARAN_1

BULAN_PEMBAYARAN_2

(18)

Gambar 3.8 Daftar entitas sistem penanganan royalti buku pada keadaan
awal

Ada tiga hal yang perlu diperhatikan tentang entitas:

1. Sebuah atribut bisa jadi merupakan suatu pengulangan (berisi sejumlah
nilai, bukan sebuah nilai),
2. Sebuah atribut muncul pada beberapa entitas (lebih dari satu, sebagaimana
diuraikan diatas), dan
3. Sebuah atribut barangkali merupakan karakteristik dari entitas lain atau
mungkin merupakan karakteristik atribut lain.
Berikut adalah pedoman pemecahan terhadap masalah-masalah diatas:
 Suatu atribut adalah katrakteristik dari entitas lain.
Solusi:
 Buanglah atribut tersebut dari entitas.
Sebagai contoh, NAMA_PENGARANG sebenernya bukan merupakan
karakteristik dari JADWAL_PEMBAYARAN (Gambar 3.7), melainkan
merupakan karakteristik dari entitas PENGARANG. Dengan demikian
NAMA_PENGARANG perlu dibuang dari entitas
JADWAL_PEMBAYARAN. Hal yang sama juga berlaku untuk beberapa
entitas yang lain.
 Suatu atribut adalah karakteristik dari atribut lain.
Solusi :
1. Buatlah entitas baru,
2. Tempatkan dua atribut tersebut pada entitas baru,
3. Buanglah kedua atribut dari entitas lama.

JUDUL_BUKU pada entitas CATATAN_ROYALTI (Gambar 3.8)

merupakan karakteristik dari atribut IDENTITAS_BUKU. Oleh karena itu
kedua item ini perlu dikeluarkan dari entitas CATATAN_ROYALTI dan
kemudian diletakkan pada entitas baru yang diberi nama BUKU. Jadi
entitas baru yang bernama BUKU berisi sebagai berikut:

BUKU
IDENTITAS_BUKU
JUDUL_BUKU

Jika diperlukan, entitas BUKU bisa dilengkapi dengan atribut-atribut lain

seperti EDISI dan ISBN.

(19)

 Atribut adalah grup pengulangan

Solusi:
Atribut yang mungkin mempunyai nilai lebih dari satu harus dipisahhkan
dengan atribut yang nilainya hanya satu, dan diletakkan pada entitas baru.
Perhatikan contoh berikut:

DOSEN
NAMA_DOSEN
GAJI_DOSEN
TELPON_DOSEN
KANTOR_DOSEN
BEBAN_AJAR
Pada contoh diatas, BEBAN_AJAR menyatakan matakuliah yang diampu
oleh seorang dosen. Oleh karena seorang dosen kemungkinan besar
mengajar lebih dari sebuah matakuliah, maka atribut ini menyatakan suatu
pengulangan.
Solusi persoalan ini adalah sebagai berikut:
DOSEN
NAMA_DOSEN
GAJI_DOSEN
TELPON_DOSEN
KANTOR_DOSEN

AJAR
MATA KULIAH
Pada contoh ini, item yang semula bernama BEBAN_AJAR sekarang
diwakili oleh MATA KULIAH, dan entitasnya diberi nama AJAR.
Berdasarkan pedoman diatas, entitas-entitas yang ada pada Gambar 3.8
akan menjadi sejumlah entitas sebagaimana diperlihatkan pada Gambar
3.9.
BUKU
JADWAL_PEMBAYARAN
IDENTITAS_BUKU
BULAN_PEMBAYARAN_1
NAMA_BUKU
BULAN_PEMBAYARAN_2

(20)
CATATAN_ROYALTI REKENING_BANK
PERIODE
NAMA_BANK
TOTAL_BUKU_TERJUAL
ALAMAT_BANK
BESAR_ROYALTI
NO_REKENING

PENGARANG PEMBAYARAN
NAMA_PENGARANG
TANGGAL_TRANSFER
 ALAMAT
NO_TRANSFER

TELPON
NILAI_TRANSFER

BANK_PENTRANSFER

NAMA_BANK_KIRIM
ALAMAT_BANK_KIRIM
Gambar 3.9 Daftar entitas hasil revisi
Entitas yang ada pada suatu sistem umumnya banyak. Antarentitas
memiliki hubungan. Hubungan antarentitas biasa dinyatakan dengan
diagram E-R (Entity-relationship) atau diagram entitas hubungan. Contoh
diagram E-R ditunjukan pada Gambar 3.10

Pelanggan

Menyewa

Mobil

(21)
Gambar 3.10 Hubungan antara entitas PELANGGAN dan MOBIL
dinyatakan dengan diagram E-R.
Pada gambar didepan, belah ketupat dengan tulisan “Menyewa”
menyatakan hubungan antara dua entitas (PELANGGAN dan MOBIL).
Tulisan 1 dan M pada hubungan diatas biasa dinyatakan dengan notasi
1:M. Notasi ini menyatakan hubungan antara PELANGGAN dan MOBL
bersifat “ satu ke banyak”. Artinya, seseorang pelanggan dapat menyewa
lebih dari satu mobil.
Model diagram E-R sangat bervariasi. Terkadang bentuk seperti di atas
dinyatakan sebagaimana terlihat dibawah ini.

Pelanggan
 Selain diagram E-R, diagram lain yang sering dipakai adalah diagram
struktur data (disebut juga diagramBachman [8]). Diagram ini menyerupai
diagram E-R. Hubungan antar entitas didalam diagram struktur data
dinyatakan dengan garis dan panah. Dua panah identik dengan 1 pada
diagram E-R. Gambar 3.11 memperlihatkan contoh diagram struktur data
yang menyatakan hubungan antara entitas PELANGGAN dan MOBIL.

Pelanggan

Mobil

Gambar 3.11 Hubungan antara entitas PELANGGAN dan MOBIL

dinyatakan dengan diagram struktur data

(22)
 Kunci Primer
Kunci primer adalah kunci kandidat yang dipilih sebagai kunci utama
untuk mengidentifikasi baris dalam tabel.
 Kunci Alternatif
Kunci alternatif adalah semua kunci kandidat yang tidak bertindak sebagai
kunci primer.
 Kunci Tamu
Kunci tamu (kadang disebut kunci asing) adalah sembarang atribut yang
menunjuk ke kunci primer pada tabel lain.

Sebagai contoh, perhatikan Gambar 3.14. pada gambar ini terdapat 2

tabel. KODE_PELANGGAN adalah kunci primer milik tabel
PELANGGAN dan KODE_KOTAmenyatakan kunci tamu yang
menunjukkan ke tabel KOTA. Terlihat bahwa atribut yang berkedudukan
sebagai kunci tamu bisa saja memiliki nilai yang kembar, tetapi yang
bertindak sebagai kunci primer tidak mungkin kembar.

PELANGGAN

KODE_PELANG NAMA_PELAN KODE_K

GAN GGAN OTA
160002 AMIRUDIN 1201
160003 SITA DEVI 1201
160004 IVAN 1201
LESMANA

KOTA
KODE_KOTA NAMA_KOTA
1101 SEMARANG
1201 YOGYA
1202 SLEMAN
1203 BANTUL

Gambar 3.14 Gambaran kunci primer dan kunci tamu

Apabila suatu tabel tidak memiliki atribut (atau gabungan atribut) yang
dapat dijadikan sebagai kunci kandidat, perlulah dibuatkan atribut baru
yang kemudian dijadikan sebagai kunci kandidat. Misalnya, pada
PENGARANG, NAMA_PENGARANG tidak dapat dijadikan sebagai
kunci mengingat ada kemungkinan dua orang atau lebih yang memiliki
nama yang sama. Oleh karena itu atribut dengan nama
KODE_PENGARANG bisa diciptakan.

(23)

Secara keseluruhan, kunci primer pada sistem penanganan royalti buku

adalah sebagaimana diperlihatkan pada Gambar 3.15 (dinyatakan dengan
garis bawah).
BUKU REKENING BANK
IDENTITAS BUKU KODE
REKENING

NAMA_BUKU
NAMA_BANK
CATATAN ROYALTI
ALAMAT_BANK
 KODE ROYALTI
NO_REKENING
PERIODE
TOTAL_BUKU_TERJUAL
NILAI_ROYALTI PEMBAYARAN
KODE
PEMBAYARAN
PENGARANG
TANGGAL_TRANSFER
KODE PENGARANG
NO_TRANSFER
NAMA_PENGARANG
NILAI_TRANSFER
ALAMAT
TELPON BANK_PENTRANSFER
JADWAL PEMBAYARAN KODE BANK
KODE_JADWAL
NAMA_BANK_KIRIM
BULAN_PEMBAYARAN_1
ALAMAT_BANK_KIRIM
BULAN_PEMBAYARAN _2
Gambar 3.15 Tabel-tabel pada sistem penanganan royalti buku
dilengkapi dengan kunci (dinyatakan dengan garis bawah)

Hasil pada Gambar 3.15 merupakan contoh model konseptual. Model ini
dapat dituangkan ke model basis data yang akan digunakan (tahapan
perancangan basis data secara logis).

(24)
Pada perancangan basis data secara logis, hanya pemetaan ke
model relasional yang dibahas, mengingat model ini paling banyak dipakai
pada PC. Pemetaan ke model hirarkis dan jaringan dibahas oleh Atre[21].
Pada model relasional, setelah tabel dilengkapi dengan kunci yang
bersifat unik, langkah selanjutnya adalah menerjemahkan hubungan
antartabel ke dalam kunci tamu. Cara melakukan penerjemahan ditentukan
oleh jenis hubungan antartabel. Dalam hal ini ada tiga macam hubungan:
1. Hubungan satu ke satu (1:1),
2. Hubungan satu ke banyak (1:M), dan
3. Hubungan banyak ke banyak (M:N).
 Hubungan satu ke satu ditangani dengan cara menyamakan kunci
primer masing-masing tabel. Penyamaan kunci ini dilakukan hanya untuk
memudahkan mengingat-ingat. Apabila nama kunci berbeda, gantilah
nama kunci pada salah satu tabel dengan nama kunci tabel lainnya.
Sebagai contoh, PENGARANG dan REKENING_BANK memiliki
hubungan satu ke satu. Setiap pengarang hanya mengajukan sebuah nomor
rekening. Pada keadaan seperti ini kunci pada PENGARANG, yaitu
KODE_PENGARANG, diberikan ke REKENING_BANK untuk
menggantikan KODE_REKENING. Dengan demikian tabel
REKENING_BANK berubah menjadi:
REKENING_BANK
KODE_PENGARANG
NAMA_BANK
ALAMAT_BANK
NO_REKENING
Contoh hubungan satu ke satu yang lain adalah PENGARANG dan
JADWAL_PEMBAYARAN. Hasilnya, KODE_PENGARANG
menggantikan KODE_JADWALpada JADWAL_PEMBAYARAN.
Hubungan satu ke banyak ditangani dengan cara menaruh kunci
tabel yang berada pada sisi “satu”ke tabel yang bersisi “banyak”, sebagai
contoh adalah hubungan antara tabel PENGARANG dan BUKU. Perlu
diketahui bahwa sebenarnya hubungan BUKU dan PENGARANG adalah
banyak ke banyak, tetapi ada penerbit yang membuat ketentuan bahwa bila
sebuah buku ditulis oleh beberapa orang, maka hanya satu orang yang
mewakili menerima royalti. Itulah sebabnya hubungan antara
PENGARANG dan BUKU pada sistem ini bersifat satu ke banyak.
Dengan demikian tabel BUKU akan berubah menjadi:

(25)

BUKU
IDENTITAS BUKU
NAMA_BUKU
KODE_PENGARANG
KODE_PENGARANG pada tabel BUKU bertindak sebagai kunci
tamu.

BUKU
IDENTITAS_B NAMA_BU KODE_PENGAR
UKU KU ANG
 970001 Turbo A00001
970002 Pascal B00022
970003 C++ A00001
970004 Turbo A00001
Prolog
Visual C++

PENGARANG
KODE_PENGARAN NAMA_PENGARANG
G
A00001 Abdul Kadir
A00002 Ardiansyah
A00003 Avian Suwandi

Gambar 3.16 Contoh hubungan satu ke banyak

Contoh hubungan satu ke banyak yang lain:

 BUKU dan CATATAN_ROYALTI
CATATAN_ROYALTI mendapatkan tambahan berupa
IDENTITAS_BUKU.
 CATATAN_ROYALTI dan PEMBAYARAN
CATATAN_ROYALTI mendapatkan tambahan berupa
KODE_PEMBAYARAN.
 BANK_PENTRANSFER dan PEMBAYARAN
PEMBAYARAN mendapatkan berupa KODE_BANK.

(26)

Hubungan banyak ke banyak ditangani dengan menciptakan tabel

baru. Tabel baru ini disebut tabel asosiasi, digunakan untuk
mengungkapkan hubungan antara kedua tabel. Tabel asosiasi berisi kunci
kedua tabel. Seandainya sistem penanganan royalti buku perlu mencatat
data pengarang untuk sebuah buku yang ditulis oleh lebih dari satu
pengarang, maka PENGARANG dan BUKU tidak berubah, tetapi akan
terbentuk tabel yang namanya dapat berupa PENGARANG_BUKU.
Isinya sebagai berikut :
PENGARANG_BUKU
KODE_PENGARANG
 IDENTITAS_BUKU
Berikut adalah hasil akhir tabel-tabel yang digunakan pada sistem
penanganan royalti buku.
BUKU
IDENTITAS BUKU REKENING_BANK
NAMA_BUKU KODE
PENGARANG
KODE_PENGARANG NAMA_BANK
CATATAN ROYALTI ALAMAT_BANK
KODE ROYALTI NO_REKENING
PERIODE PEMBAYARAN
TOTAL_BUKU_TERJUAL KODE
PEMBAYARAN
NILAI _ROYALTI TANGGAL
TRANSFER
IDENTITAS_BUKU NO_TRANSFER
PENGARANG NILAI_TRANSFER
KODE_PENGARANG KODE_BANK
NAMA_PENGARANG KODE_ROYALTI
ALAMAT BANK PENTRANSFER
TELPON KODE BANK
JADWAL PEMBAYARAN
NAMA_BANK_KIRIM
KODE_PENGARANG
ALAMAT_BANK_KIRIM
BULAN_PEMBAYARAN_1
BULAN_PEMBAYARAN_2

(27)
Setelah semua hubungan diterjemahkan menjadi kunci tamu, perlu
dilakukan normalisasi terhadap tabel-tabel yang sudah terbentuk.
Normalisasi biasanya hanya dipakai untuk verifikasi, untuk meyakinkan
bahwa tidak perlu lagi ada perubahan-perubahan pada tabel.
Setelah semua tabel dinormalisasi (memenuhi kriteria normalisasi),
maka proses perancangan basis data secara fisik mulai dilakukan. Tahapan
ini bergantung kepada DBMS yang digunakan. Kegiatan-kegiatan yang
dilakukan antara lain:
 Mendefinisikan seluruh kolom untuk semua tabel,
 Mendefinisikan kebutuhan integritas referensial,
 Mendefinisikan view atau pandangan,
 Mendefinisikan indeks.
Kegiatan-kegiatan ini dilakukan dengan menggunakan perintah-perintah
yang tersedia pada DBMS.
Perancangan proses biasanya menghasilkan dokumentasi
perancangan dalam bentuk Spesifikasi Program dan Bagan Struktur
Sistem. Spesifikasi Program dipakai sebagai petunjuk bagi pemrogram
agar dengan mudah dapat menuangkan proses ke dalam program. Bagan
Struktur Sistem memperlihatkan seluruh program dalam sistem baru dan
hirarki kontrol terhadap program-program tersebut.
Gambar 3.18 memperlihatkan contoh Bagan Struktur Sistem
Menampilkan
menu
sistem royalti

Memproses
Menu Menampilkan
pembayaran
sistem royalti menu laporan
royalti

Membuat laporan
Pemasukan data buku
royalti jatuh tempo

Pemasukan data Membuat rincian

pengarang royaltti per pengarang

Pemasukan data
royalti

Pemasukan data bank

transfer

(28)

Gambar 3.18 Contoh Bagan Struktur Sistem

Rancangan yang lain berupa rancangan laporan. Suatu aplikasi umumnya
melibatkan banyak laporan, dan tentu saja macam laporan sangat
ditentukan oleh kebutuhan pengguna.

5. Tahapan Implementasi Sistem

Tahapan implementasi sistem mencakup pengkodean program, pengujian

program, pemasangan program, dan juga pelatihan kepada pengguna.
 Setelah tahap ini berakhir maka akan sampai pada penggunaan. Dalam hal
ini aplikasi mulai dioprasikan oleh pengguna untuk melakukan berbagai
transaksi.

3. Daftar Kata Kunci

Aliran data Kekangan

Atribut Kunci alternatif
Bagan struktur sistem Kunci tamu (foreign key)
DAD Kunci kandidat
DAD Konteks Kunci kombinasi
DFD Kunci komposit
DIAGRAM Bachman Kunci primer
Diagram E-R Kunci sederhana
Domain Penyimpanan data
Entitas Perancangan basis data
Hubungan Perancangan proses
Hubungan satu ke banyak Proses data
Hubungan satu ke satu SDLC
Integritas referensial Tabel asosiasi
Kamus data Terminator

(Abdul Kadir;2002)

(29)

c. Buku 3
1. Langkah Awal Perancangan Basis Data
a. Mengidentifikasi tujuan sistem secara tepat
Programer di sini menentukan tujuan dari pembuatan aplikasi basis
data, penetuan format dari basis data dan sasaran pengguna data base
untuk siapa.
b. Berdiskusi dengan user untuk mengidentifikasi bentuk forms dan reports
 Dalam merancang sebuah basis data programer harus menentukan
bentuk forms dan reports yang mudah dipakai dan dimengerti oleh user.
Dengan adanya ini memungkinkan aplikasi basis data sedikit mengalami
kerumian ketika akan dipakai oleh user.
c. Merancang classes (table) dan relationship
Sebelum membuat aplikasi program basis data, programmer harus
membuat gambaran mengani kemungkinan tabel-tabel yang akan
digunakan dan relationship diantara tabel-tabel tersebut, sehingga ketika
melakukan pembuatan aplikasi si programer sudah mempunyai gambaran
tentang sistem basis datanya.
d. Mengidentifikasi semua business constraint
Programer basis data harus mengetahui batasan-batasan dari semua
business constrain yan digunakan dalam aplikasi basis datanya, sehingga
tidak ada kesalahan dalam aplikasi basis data.
e. Memeriksa ulang kecocokan design dengan business rules yang ada
Setelah aplikasi basis data selesai programer harus memeriksa kembali
kecocokan design basis data dengan aturan bisnis, aplikasi yan dibuatt
sudah tepat, hal ini bertujuan meminimalisir kesalahan dikemudian hari.
2. Syarat Perlunya Normalisasi
a. Fleksibilitas
Terdapat struktur yang mendukung berbagai cara untuk menampilkan
data, sehingga ketika user menjalankan aplikasi dengan maksud yang di
inginkan aplikasi basis data berjalan memenuhi permintaan user.
Programer harus merancang semua kemungkinan yang akan terjadi dalam
aplikasi basis data ketika user menggunakan aplikasinya.
b. Integritas data
Semua data dalam basis data yang saling berkaitan harus terhubung
dalam suatu relationships, adanya modification anomalies yang
disebabkan oleh penghapusan, pengisian, pembaruan data harus dapat
dicegah, agar tidak membuat isi data berantakan. Masalah ini harus dapat
dicegah supaya ketika suatu data berubah maka semua data yang berkaitan
dengan data tersebut dapat berubah secara otomatis.

(30)

c. Efficiency
Dalam basis data kita harus meminimalisir terjadinya pengulangan
data dalam suatu tabel, hal ini akan memperbesar ukuran dari basis data
membengkak sehingga memerlukan ruang penyimpanan yang besar pula,
maka perlu dilakukan efisiensi untuk menghemat media penyimpanan.
d. Menghindari modification anomaly
 Desain basis data yang baik meyakinkan bahwa user bisa mengubah isi
data tanpa efek yang tidak diharapkan. Modification anomaly adalah efek
yang tidak diharapkan saat kita melakukan modifikasi terhadap basis data.
1. Insertion anomaly : penambahan suatu fakta dalam suatu entity tidak dapat
dilakukan sampai dengan suatu fakta mengenai entity lain ditambahkan
pula.
2. Update anomaly : untuk mengubah suatu single row, kita harus mengubah
beberapa row yang lain.
3. Delection anomaly : penghapusan suatu row bisa menyebabkan data yang
lain ikut terhapus.

3. Definisi Normalisasi

Arti normalisasi dalam relational basis data design, adalah proses

pengorganisasian data untuk meminimalisasi duplikasi.

Normalisasi umumnya melibatkan pembagian basis data ke dalam dua

atau lebih tabel dan penetuan relationships antar table-table tersebut.

Untuk mengisolasi data sehingga penambahan, penghapusan, dan

modifikasi dari suatu field dapat dilakukan hanya pada satu table dan
terpropagasi pada sisa basis data melalui bentuk relationships yang telah
dilakukan (Webopedia).

Normalisasi mengacu pada proses pembuatan struktur relational yang

efficient, reliable, flexible, dan tepat unuk menyimpan informasi. Data
yang telah ternormalisasi harus dalam struktur relational (Reid Software
Development, http://www.accessbasisdata.com/normalize. html).

(31)

4. Functional Dependency

Functional Dependency adalah alat yang penting ketika kita

menganalisis sebuah table unuk redundancy yang berlebihan. Functional
dependency adalah sebuah constraint tentang basis data content. Constraint
bisa dikarakteristikkan sebagai “value_based constraint” dengan
 “value_neutral constraint”. Value_based constraint melibatkan
perbandingan sebuah kolom dengan konstanta menggunakan operator
perbandingan <, >, =. Contohnya : usia > 20. Value_neutral constraint
melibatkan perbandingan beberapa kolom. Contohnya : usia pensiun harus
lebih besar dari pada usia sekaran yang ada dalam basis data.

Primary key (PK), foreign key (FK), Functional Dependency (FD)

adalah macam dari value_neutral constrain yang penting. Sebuah primary
key bisa mengambil sembarang nilai selama nilai tersebut tidak sama
dengan nilai primary key yang telah ada. Foreign key constrain memiliki
syarat bahwa nilai dari sebuah kolom pada suatu tale ada pada sebuah
kolom yang berada pada table lain. FD adalah contrain tentang 2 atau lebih
kolom dalam suatu table.

Functional Dependency membolehkan kita untuk mengekspresikan

constraint yang tidak bisa kita ekspresikan dengan superkey. Perhatikan
skema dibawah ini :

Loan-info-schema+(loan-number, branch-name, customer-name,

amount)

Himpunan functional Dependency yang diharapkan terjadi pada schema di

atas adalah :

Loan-number  amount

Loan-number  branch-name

Kita tidak menginginkan functional dependency seperti dibawah ini :

Loan-number  customer-name

(32)

Karena pada umumnya, loan diberikan kepada lebih dari satu customer.

Kita akan mengubah functional dependency dalam 2 cara :

1. Untuk mengetes relasi apakah mereka legal di awah functional

dependency yang diberikan. Jika sebuah relasi r adalah legal di bawah
 kumpulan functional dependency, kita bisa katakan bahwa r memenuhi
FD.
2. Untuk menentukan constraint pada kumpulan relasi yang legal. Kita akan
memfokuskan bahwa hanya relasi-relasi itu yang memenuhi kumpulan
functional dependency yang diberikan.
5. Proses dan Tahapan Normalisasi

Pada dasarnya terdapat dua proses di dalam normalisasi sebuah abel

yaitu :

a. Data diuraikan dalam bentuk tabel, selanjutnya dianalisis berdasarkan

persyaratan tertentu dalam beberapa tingkat.
b. Apabila tabel yang diuji belum memenuhi persyaratan tertentu, maka tael
tersebut perlu dipecah menjadi beberapa tabel yang lebih sederhana
sampai memenuhi bentuk tabel yang optimal

Tahapan dalam normalisasi dimulai dari tahap paling ringan (1NF)

hingga paling ketat (5NF).

(Widodo.A.W, Kurnianingtyas.D;2017)

(33)

BAB III
PENUTUP
3.1 Kesimpulan
 Sistem basis data merupakan sebuah sistem penyimpanan kumpulan
file-file yang saling berkaitan dengan file yang lainnya serta pengelolaan
data dengan menggunakan komputer membentuk suatu bangunan data
untuk memberikan informasi, sehingga informasi yang disediakan cepat
dan akurat.
Form digunakan untuk merepresentasikan ke user atau menerima inputan
dari user data-data dalam tabel/query dalam bentuk interface grid, tombol dan
lain-lain. Form dalam Accessdapat dimasukkan ke dalam form lain sebagai
control sub form, biasanya jika kita bekerja dalam transaksi master detail.
Report merupakan fasilitas dalam Microsoft Access yang berfungsi untuk
mencetak data dalam bentuk laporan, dapat berasal dari tabel maupun query.
Cara yang mudah untuk membuat report adalah dengan Create report by using
wizard

3.2 Saran

1. Buku 1 dan buku 3 seharusnya cakupan point materinya lebih luas seperti
pada buku 2
2. Buku 2 lebih cocok digunakan sebagai referensi dibandingkan buku 1 dan
buku 3

(34)

DAFTAR PUSTAKA

1. Kadir.Abdul.2002.Konsep&Tuntunan Praktis Sistem Basis Data.ANDI.

2. Waljiyanto.2003.Sistem Basis Data.Graha Ilmu.
3. Widodo.A.W&Kurnianingtyas.2017.UB Press.Malang

(35)

LAMPIRAN
(36)