Slide INF106 SBD Pertemuan 4 dan 5
Perancangan Basis
Data
Pertemuan 4 dan 5
Definisi Perancangan Basisdata
Perancangan
Database
adalah
proses
untuk
menentukan isi dan pengaturan data yang dibutuhkan
untuk mendukung berbagai rancangan sistem.
Tujuan Perancangan Database :
untuk memenuhi informasi yang berisikan kebutuhankebutuhan user secara khusus dan aplikasi-aplikasinya.
memudahkan pengertian struktur informasi.
mendukung kebutuhan-kebutuhan pemrosesan dan
beberapa obyek penampilan (response time, processing
time, dan storage space)
Proses Perancangan Database
6 Fase proses perancangan database :
1. Pengumpulan data dan analisis
2. Perancangan database secara konseptual
3. Pemilihan DBMS
4. Perancangan database secara logika (data model
5. Perancangan database secara fisik
6. Implementasi Sistem database.
mapping)
6 fase di atas tidak harus diproses berurutan. Pada beberapa hal, rancangan tsb
dapat dimodifikasi dari yang pertama dan sementara itu mengerjakan fase yang
terakhir (feedback loop antara fase) dan feedback loop dalam fase sering terjadi
selama proses perancangan.
Fase 1 : Pengumpulan data dan
analisa
Proses identifikasi dan analisa kebutuhan-kebutuhan data disebut
pengumpulan data dan analisa.
Untuk
menentukan
kebutuhan-kebutuhan
suatu
sistem
database,
pertama-tama harus mengenal bagian-bagian lain dari sistem informasi
yang akan berinteraksi dengan sistem database, termasuk para
pemakai yang ada dan para pemakai yang baru serta aplikasiaplikasinya.
Kebutuhan-kebutuhan dari para pemakai dan aplikasi-aplikasi inilah
yang kemudian dikumpulkan dan dianalisa.
Aktifitas-aktifitas pengumpulan
data dan analisa
1. Menentukan kelompok pemakai dan bidang-bidang
aplikasinya.
2. Peninjauan dokumentasi yang ada.
3. Analisa lingkungan operasi dan pemrosesan data.
4. Daftar pertanyaan dan wawancara.
Fase 2 : Perancangan database
konseptual
Tujuan dari fase ini adalah menghasilkan conceptual
schema untuk database yang tergantung pada sebuah
DBMS yang spesifik.
Sering menggunakan sebuah high-level data model
seperti ER/EER model selama fase ini.
Dalam conceptual schema, kita harus merinci aplikasiaplikasi database yang diketahui dan transaksi-transaksi
yang mungkin.
Aktifitas paralel perancangan database
secara konseptual
Perancangan skema konseptual :
menguji kebutuhan-kebutuhan data dari suatu database yang
merupakan hasil dari fase 1, dan menghasilkan sebuah
conceptual database schema pada DBMS independent model
data tingkat tinggi seperti EER (enhanced entity relationship)
model.
Perancangan transaksi :
menguji aplikasi-aplikasi database dimana kebutuhankebutuhannya telah dianalisa pada fase 1, dan menghasilkan
perincian transaksi-transaksi ini.
Fase 3 : Pemilihan DBMS
Pemilihan database ditentukan oleh beberapa faktor, diantaranya:
Struktur data
Jika data yang disimpan dalam database mengikuti struktur hirarki, maka
suatu jenis hirarki dari DBMS harus dipikirkan.
Personal yang telah terbiasa dengan suatu sistem
Jika staf programmer dalam suatu organisasi sudah terbiasa dengan suatu
DBMS, maka hal ini dapat mengurangi biaya latihan dan waktu belajar.
Tersedianya layanan penjual
Keberadaan fasilitas pelayanan penjual sangat dibutuhkan untuk membantu
memecahkan beberapa masalah sistem.
Teknik
Keberadaan DBMS dalam menjalankan tugasnya seperti jenis-jenis DBMS
(relational, network, hierarchical, dll), struktur penyimpanan, dan jalur akses
yang mendukung DBMS, pemakai, dll.
Fase 4 : Perancangan database secara
logika (pemetaan model data)
Fase selanjutnya dari perancangan database adalah membuat
sebuah skema konseptual dan skema eksternal pada model data
dari DBMS yang terpilih.
Fase ini dilakukan oleh pemetaan skema konseptual dan skema
eksternal yang dihasilkan pada fase 2.
Pada fase ini, skema konseptual ditransformasikan dari model data
tingkat tinggi yang digunakan pada fase 2 ke dalam model data dari
DBMS yang dipilih pada fase 3.
Pemetaan diproses dalam 2 tingkat
Pemetaan system-independent
Pemetaan ke dalam model data DBMS dengan tidak
mempertimbangkan karakteristik atau hal-hal yang khusus yang
berlaku pada implementasi DBMS dari
model data tsb.
Penyesuaian skema ke DBMS yang spesifik
mengatur skema yang dihasilkan pada langkah 1 untuk
disesuaikan pada implementasi yang khusus di masa yang akan
datang dari suatu model data yang
digunakan pada DBMS yang dipilih.
Fase 5 : Perancangan database fisik
Perancangan database secara fisik merupakan proses pemilihan
struktur-struktur penyimpanan dan jalur-jalur akses pada file-file
database untuk mencapai penampilan yang terbaik pada
bermacam-macam aplikasi.
Selama fase ini, dirancang spesifikasi-spesifikasi untuk
database yang disimpan yang berhubungan dengan strukturstruktur penyimpanan fisik, penempatan record dan jalur akses.
Petunjuk pemilihan perancangan
database secara fisik
Response time
Waktu yang telah berlalu dari suatu transaksi database yang diajukan Untuk
menjalankan suatu tanggapan. Pengaruh utama pada response time adalah di
bawah pengawasan DBMS yaitu : waktu akses database untuk data item yang
ditunjuk oleh suatu transaksi.
Response time juga dipengaruhi oleh beberapa faktor yang tidak berada di
bawah pengawasan DBMS, seperti penjadwalan sistem operasi atau
penundaan komunikasi.
Space Utility
Jumlah ruang penyimpanan yang digunakan oleh file-file database dan strukturStruktur jalur akses.
Transaction throughput
Rata-rata jumlah transaksi yang dapat diproses per menit oleh sistem
database, dan merupakan parameter kritis dari sistem transaksi (misal,
digunakan pada pemesanan tempat di pesawat, bank, dll).
Hasil dari fase ini adalah penentuan awal dari struktur penyimpanan dan jalur
akses untuk file-file database.
Fase 6 : Implementasi sistem
database
Setelah perancangan secara logika dan secara fisik lengkap,
kita dapat melaksanakan sistem database.
Perintah-perintah dalam DDL dan SDL(storage definition
language) dari DBMS yang dipilih, dihimpun dan digunakan
untuk membuat skema database dan file-file database (yang
kosong) kemudian database tsb dimuat (disatukan) dengan
datanya.
Jika data harus dirubah dari sistem komputer sebelumnya,
perubahan-perubahan yang rutin mungkin diperlukan untuk
format ulang datanya yang kemudian dimasukkan ke
database yang baru.
Transaksi-transaksi database sekarang harus dilaksanakan
oleh para programmmer aplikasi.
ALASAN PERANCANGAN
BASIS DATA
• Sistem basis data telah menjadi bagian dalam sistem
informasi suatu organisasi
• Kebutuhan menyimpan data dl jumlah besar semakin
mendesak
• Fungsi-fungsi dalam organisasi semakin
dikomputerisasikan
• Semakin kompleks data & aplikasi yg digunakan, maka
relationship antar data harus dimodelisasikan
• Dibutuhkannya kemandirian data
KONVERSI & LOADING DATA
• Tahap ini dilakukan apabila sistem basis data
yg ada digantikan sistem basis data baru
• Semua data yg ada ditransfer ke basis data
baru & konversi aplikasi yg ada utk basis data
baru
PENGOPERASIAN & PERAWATAN
• Pengoperasian basis data setelah divalidasi
• Memonitor kinerja sistem, jika tidak sesuai
perlu reorganisasi basis data
• Perawatan & upgrade sistem aplikasi basis
data jika diperlukan.
Model Konseptual Basis Data
Model konseptual merupakan kombinasi beberapa cara
untuk memproses data untuk beberapa aplikasi.
Pada perancangan model konseptual basis data ini
penekanan dilakukan pada struktur data dan relasi antara
field.
Pada perancangan model konseptual ini dapat dilakukan
dengan menggunakan model data relasional.
Teknik Normalisasi
Proses normalisasi adalah proses pengelompokan data elemen
menjadi tabel-tabel yang menunjukkan entity dan relasinya.
Pada proses normalisasi dilakukan pengujian pada beberapa
kondisi apakah ada kesulitan pada saat
menambah/menyisipkan, menghapus, mengubah dan
mengakses pada suatu Basis data.
Bila terdapat kesulitan pada pengujian tersebut maka perlu
dipecahkan relasi pada beberapa tabel lagi atau dengan kata
lain perancangan basis data belum optimal.
Entity
Entity atau entitas, dalam basis data entity
sama halnya dengan sebuah tabel.
Atribut
Atribut, dalam basis data sama halnya
dengan field.
Jenis Atribut
• Atribut Sederhana
• Atribut Komposit
• Atribut Bernilai Tunggal
• Atribut Bernilai Jamak
• Atribut Harus Bernilai
• Atribut Bernilai Null
• Atribut Turunan
Atribut Sederhana
Atribut Sederhana : atribut sederhana merupakan atribut
atomik
yang tidak dapat lagi dipecah menjadi atribut lain.
Contoh:
Entitas mahasiswa mempunyai atribut sederhana berupa NIM,
NamaMahasiswa .
Atribut Komposit
Atribut Komposit : atribut komposit merupakan atribut yang
masih
dapat dipecah menjadi sub-sub atribut yang masing-masing
memiliki arti
tesendiri.
Contoh:
Entitas mahasiswa mempunyai atribut alamat. Maka alamat disini
dapat
dipecah menjadi sub atribut seperti kota, kab, kode_pos.
Entitas dosen mempunyai atribut nama_dosen. Maka nama disini
dapat
Atribut Bernilai Tunggal
Atribut Bernilai Tunggal : atribut yang hanya
memiliki satu nilai untuk setiap barisnya.
Contoh:
entitas mahasiswa mempunyai atribut NIM, nama,
alamat isi data
dari atribut ini hanya boleh diisi dengan 1 data.
Setiap mahasiswa hanya memiliki 1 NIM, 1 Nama, 1
Alamat.
Atribut Bernilai Jamak
Atribut Bernilai Jamak : yaitu atribut yang boleh memiliki
lebih dari
satu nilai untuk setiap barisnya.
Contoh:
entitas mahasiswa mempunyai atribut Hobby isi data dari
atribut ini
boleh lebih dari 1 data. Mahasiswa Roshita memiliki NIM
04102002
beralamat di Jalan Garuda 32 Yogyakarta memiliki Hobby
(Olah Raga,
Atribut Harus Bernilai (not null)
Atribut Harus Bernilai : yaitu atribut yang harus memiliki nilai data
untuk setiap barisnya. Biasanya atribut seperti ini sudah ditetapkan
dalam perancangan tabelnya sehingga jika dalam pengisian di
kosongi
akan terjadi kesalahan.
Contoh:
entitas mahasiswa mempunyai atribut NIM dan nama_mahasiswa
yang harus diisi datanya, sebab jika tidak diisi akan terjadi kesalahan
(error) dalam basis data
Atribut Bernilai Null (is null)
Atribut Bernilai Null : yaitu atribut yang boleh tidak memiliki
nilai data
untuk setiap barisnya.
Contoh:
entitas mahasiswa mempunyai atribut hobby, nama_pacar yang
boleh tidak terisi.
Atribut Turunan
Atribut Turunan : yaitu atribut yang nilai-nilainya diperoleh
dari
pengolahan atau dapat diturunkan dari atribut lain yang
berkaitan.
Contoh:
entitas mahasiswa mempunyai atribut IPK yang diperoleh
dari
pengolahan atribut Nilai pada tabel (entitas Nilai) dengan
kode NIM
mahasiswa yang sama dan diproses sehingga menghasilkan
Field (Atribut) Kunci
setiap field selalu terdapat kunci berupa field atau satu set field
yang dapat mewakili record.
Misalnya Nomor Induk Mahasiswa (NIM) merupakan
kunci dari tabel mahasiswa suatu Perguruan Tinggi, setiap pencarian
cukup dengan menyebut NIM mahasiswa tersebut maka dapat diketahui
identitas mahasiswa lainnya seperti nama, alamat dan atribut lainnya.
Contoh lain:
Nomor Pegawai (NIDN) bagi data dosen, NIK untuk data karyawan,
Kode_Kuliah untuk data Mata kuliah, dan lain sebagainya.
Kunci Kandidat (Candidate Key)
Kunci kandidat adalah satu atribut atau satu set atribut
yang
mengidentifikasikan secara unik suatu kejadian spesifik
dari entity.
Satu set atribut menyatakan secara tidak langsung
dimana anda tidak
dapat membuang beberapa atribut dalam set tanpa
merusak
kepemilikan yang unik.
Kunci Kandidat (Candidate Key)
Contoh:
Tabel pegawai berisi field:
• nik
• no_ktp
• nama_pegawai
• tmp_lahir
• tgl_lahir
• alamat
• kota
Kunci kandidat dalam tabel pegawai di disamping
dapat dipilih sbb :
nik
no_ktp
nama_pegawai (tidak dapat dipakai karena
sering seseorang punya nama yang
sama dengan orang lain)
tmp + tgl Lahir (mungkin bisa dipakai
sebagai kunci karena kemungkinan orang
dengan nama yang sama dan tanggal lahir
yang
sama cukup kecil)
nama + tmp + tgl_lahir (dapat dipakai
sebagai kunci)
alamat dan kota (bukan kunci)
Kunci Kandidat (Candidate Key)
Contoh Kasus:
Tentukan Kunci Kandidat dari tabel tersebut
Tabel mt_kuliah berisi field:
•
id_matkul
•
kode_matkul
•
nama_matkul
•
kurikulum
•
semester
•
sks
•
nilai_minimum
Kunci kandidat dalam tabel mt_kuliah di disamping
dapat dipilih sbb :
id_matkul
kode_matkul
nama_matkul (mungkin bisa dipakai sebagai
kunci karena kemungkinan nama matkul
dengan yang lain ada perbedaan)
kurikulum + semester + sks +
nilai_minimum (tidak dapat dipakai karena
sering matkul punya data yang
sama dengan matkul lain)
Kunci Primer (Primary Key)
Primary key adalah satu atribut atau satu set minimal atribut yang tidak
hanya mengidentifikasi secara unik suatu kejadian spesifik, tetapi juga dapat
mewakili setiap kejadian dari suatu entity.
Catatan:
Setiap kunci kandidat dapat menjadi kunci primer tetapi sebaliknya
sebaiknya
dipilih satu saja yang dapat mewakili secara menyeluruh terhadap entity
yang
ada.
Kunci Primer (Primary Key)
Contoh :
1.nik (karena sifatnya yang unik maka tidak mungkin pegawai
mempunyai Nomor Induk Karyawan yang sama).
2.no_ktp (bisa dipakai misalnya untuk pegawai yang baru
belum mendapatkan nomor pegawai maka bisa digunakan
nomor KTP untuk sementara sebagai kunci primer.
3.kode_mtkuliah (bisa dipakai untuk data mata kuliah karena
kode mata kuliah bersifat unik untuk tiap mata kuliah)
Kunci Primer (Primary Key)
Contoh Kasus:
Tentukan Kunci Primer dari tabel tersebut
Tabel mt_kuliah berisi field:
1. id_matkul
2. kode_matkul
3. nama_matkul
4. kurikulum
5. semester
6. sks
7. nilai_minimum
Kunci Alternatif (Alternate Key)
Kunci alternatif adalah kunci kandidat yang tidak dipakai
sebagai kunci primer. Kunci alternatif ini sering digunakan
untuk kunci pengurutan misalnya dalam membuat laporan.
Kunci Alternatif (Alternate Key)
Contoh Kasus:
Tentukan Kunci Alternatif dari tabel tersebut
Tabel krs berisi field:
1.no_krs
2.id_matkul
3.nim
4.nilai_angka
5.nilai_huruf
6.lulus
BACK
NEXT
Kunci Tamu (Foreign Key)
Kunci tamu adalah satu atribut atau satu set minimal atribut yang
melengkapi satu hubungan yang menunjukkan ke induknya.
kunci tamu ditempatkan pada entity anak dan sama dengan kunci primer
induk yang direlasikan.
Hubungan antara entity induk dengan anak adalah hubungan satu lawan
banyak (one to many relationship)
Kunci Tamu (Foreign Key)
Contoh Kasus:
Tentukan Kunci Tamu dari tabel tersebut
Kamus Data
Contoh Kamus Data :
Nama Database : akademik
Nama Tabel
: mahasiswa
Fungsi
: menyimpan data mahasiswa
Bahasa Basisdata
Contoh Kamus Data :
Nama Database
Nama Tabel
Fungsi
Nama Field
: akademik
: dosen
: menyimpan data profil dosen
Tipe
Panjang
Karakter
id
Integer
3
nidn
Varchar
15
glr_dpn
Varchar
15
nama
Varchar
20
glr_blk
Varchar
15
jab_akademik
Varchar
50
telp
Varchar
30
email
Varchar
30
Keterangan
Primary Key
Unique
Bahasa Basisdata
Contoh Kamus Data :
Nama Database : akademik
Nama Tabel
Fungsi
: mt_kuliah
: menyimpan data mata kuliah
Nama Field
Tipe
Panjang
Karakter
id
Integer
3
mtk_kode
Varchar
10
mtk_nama
Varchar
30
sks
Char
1
semester
Char
1
kurikulum
Char
9
nilai_min
Char
1
Keterangan
Primary Key
Bahasa Basisdata
Contoh Kamus Data :
Nama Database : akademik
Nama Tabel
Fungsi
: mtk_open
: menyimpan data mata kuliah yang dibuka
Nama Field
Tipe
Panjang
Karakter
id
Integer
10
mtk_id
Integer
3
dosen_id
Integer
3
thn_ajaran
Char
9
aktif
Char
1
Keterangan
Primary Key
ERD (Entity Relationship Diagram)
Keterangan :
Banyak pegawai bekerja pada satu
departemen.
ERD
(Entity Relationship
Diagram)
Contoh Kasus :
1. Sebuah perusahaan retail memiliki banyak pelanggan yang
telah memesan sejumlah barang produksi.
Gambarkan diagram ER dari proses transaksi pembelian
tersebut dan buatkan tabel-tabelnya!
SOLUSI
ER Diagram :
PELANGGAN
1
Order
N
BARANG
N
Proses
1
PENJUALAN
Keterangan:
Satu pelanggan dapat memesan banyak barang.
Banyak barang dapat diproses pada satu kali penjualan.
SOLUSI
Tabel :
Data
Pertemuan 4 dan 5
Definisi Perancangan Basisdata
Perancangan
Database
adalah
proses
untuk
menentukan isi dan pengaturan data yang dibutuhkan
untuk mendukung berbagai rancangan sistem.
Tujuan Perancangan Database :
untuk memenuhi informasi yang berisikan kebutuhankebutuhan user secara khusus dan aplikasi-aplikasinya.
memudahkan pengertian struktur informasi.
mendukung kebutuhan-kebutuhan pemrosesan dan
beberapa obyek penampilan (response time, processing
time, dan storage space)
Proses Perancangan Database
6 Fase proses perancangan database :
1. Pengumpulan data dan analisis
2. Perancangan database secara konseptual
3. Pemilihan DBMS
4. Perancangan database secara logika (data model
5. Perancangan database secara fisik
6. Implementasi Sistem database.
mapping)
6 fase di atas tidak harus diproses berurutan. Pada beberapa hal, rancangan tsb
dapat dimodifikasi dari yang pertama dan sementara itu mengerjakan fase yang
terakhir (feedback loop antara fase) dan feedback loop dalam fase sering terjadi
selama proses perancangan.
Fase 1 : Pengumpulan data dan
analisa
Proses identifikasi dan analisa kebutuhan-kebutuhan data disebut
pengumpulan data dan analisa.
Untuk
menentukan
kebutuhan-kebutuhan
suatu
sistem
database,
pertama-tama harus mengenal bagian-bagian lain dari sistem informasi
yang akan berinteraksi dengan sistem database, termasuk para
pemakai yang ada dan para pemakai yang baru serta aplikasiaplikasinya.
Kebutuhan-kebutuhan dari para pemakai dan aplikasi-aplikasi inilah
yang kemudian dikumpulkan dan dianalisa.
Aktifitas-aktifitas pengumpulan
data dan analisa
1. Menentukan kelompok pemakai dan bidang-bidang
aplikasinya.
2. Peninjauan dokumentasi yang ada.
3. Analisa lingkungan operasi dan pemrosesan data.
4. Daftar pertanyaan dan wawancara.
Fase 2 : Perancangan database
konseptual
Tujuan dari fase ini adalah menghasilkan conceptual
schema untuk database yang tergantung pada sebuah
DBMS yang spesifik.
Sering menggunakan sebuah high-level data model
seperti ER/EER model selama fase ini.
Dalam conceptual schema, kita harus merinci aplikasiaplikasi database yang diketahui dan transaksi-transaksi
yang mungkin.
Aktifitas paralel perancangan database
secara konseptual
Perancangan skema konseptual :
menguji kebutuhan-kebutuhan data dari suatu database yang
merupakan hasil dari fase 1, dan menghasilkan sebuah
conceptual database schema pada DBMS independent model
data tingkat tinggi seperti EER (enhanced entity relationship)
model.
Perancangan transaksi :
menguji aplikasi-aplikasi database dimana kebutuhankebutuhannya telah dianalisa pada fase 1, dan menghasilkan
perincian transaksi-transaksi ini.
Fase 3 : Pemilihan DBMS
Pemilihan database ditentukan oleh beberapa faktor, diantaranya:
Struktur data
Jika data yang disimpan dalam database mengikuti struktur hirarki, maka
suatu jenis hirarki dari DBMS harus dipikirkan.
Personal yang telah terbiasa dengan suatu sistem
Jika staf programmer dalam suatu organisasi sudah terbiasa dengan suatu
DBMS, maka hal ini dapat mengurangi biaya latihan dan waktu belajar.
Tersedianya layanan penjual
Keberadaan fasilitas pelayanan penjual sangat dibutuhkan untuk membantu
memecahkan beberapa masalah sistem.
Teknik
Keberadaan DBMS dalam menjalankan tugasnya seperti jenis-jenis DBMS
(relational, network, hierarchical, dll), struktur penyimpanan, dan jalur akses
yang mendukung DBMS, pemakai, dll.
Fase 4 : Perancangan database secara
logika (pemetaan model data)
Fase selanjutnya dari perancangan database adalah membuat
sebuah skema konseptual dan skema eksternal pada model data
dari DBMS yang terpilih.
Fase ini dilakukan oleh pemetaan skema konseptual dan skema
eksternal yang dihasilkan pada fase 2.
Pada fase ini, skema konseptual ditransformasikan dari model data
tingkat tinggi yang digunakan pada fase 2 ke dalam model data dari
DBMS yang dipilih pada fase 3.
Pemetaan diproses dalam 2 tingkat
Pemetaan system-independent
Pemetaan ke dalam model data DBMS dengan tidak
mempertimbangkan karakteristik atau hal-hal yang khusus yang
berlaku pada implementasi DBMS dari
model data tsb.
Penyesuaian skema ke DBMS yang spesifik
mengatur skema yang dihasilkan pada langkah 1 untuk
disesuaikan pada implementasi yang khusus di masa yang akan
datang dari suatu model data yang
digunakan pada DBMS yang dipilih.
Fase 5 : Perancangan database fisik
Perancangan database secara fisik merupakan proses pemilihan
struktur-struktur penyimpanan dan jalur-jalur akses pada file-file
database untuk mencapai penampilan yang terbaik pada
bermacam-macam aplikasi.
Selama fase ini, dirancang spesifikasi-spesifikasi untuk
database yang disimpan yang berhubungan dengan strukturstruktur penyimpanan fisik, penempatan record dan jalur akses.
Petunjuk pemilihan perancangan
database secara fisik
Response time
Waktu yang telah berlalu dari suatu transaksi database yang diajukan Untuk
menjalankan suatu tanggapan. Pengaruh utama pada response time adalah di
bawah pengawasan DBMS yaitu : waktu akses database untuk data item yang
ditunjuk oleh suatu transaksi.
Response time juga dipengaruhi oleh beberapa faktor yang tidak berada di
bawah pengawasan DBMS, seperti penjadwalan sistem operasi atau
penundaan komunikasi.
Space Utility
Jumlah ruang penyimpanan yang digunakan oleh file-file database dan strukturStruktur jalur akses.
Transaction throughput
Rata-rata jumlah transaksi yang dapat diproses per menit oleh sistem
database, dan merupakan parameter kritis dari sistem transaksi (misal,
digunakan pada pemesanan tempat di pesawat, bank, dll).
Hasil dari fase ini adalah penentuan awal dari struktur penyimpanan dan jalur
akses untuk file-file database.
Fase 6 : Implementasi sistem
database
Setelah perancangan secara logika dan secara fisik lengkap,
kita dapat melaksanakan sistem database.
Perintah-perintah dalam DDL dan SDL(storage definition
language) dari DBMS yang dipilih, dihimpun dan digunakan
untuk membuat skema database dan file-file database (yang
kosong) kemudian database tsb dimuat (disatukan) dengan
datanya.
Jika data harus dirubah dari sistem komputer sebelumnya,
perubahan-perubahan yang rutin mungkin diperlukan untuk
format ulang datanya yang kemudian dimasukkan ke
database yang baru.
Transaksi-transaksi database sekarang harus dilaksanakan
oleh para programmmer aplikasi.
ALASAN PERANCANGAN
BASIS DATA
• Sistem basis data telah menjadi bagian dalam sistem
informasi suatu organisasi
• Kebutuhan menyimpan data dl jumlah besar semakin
mendesak
• Fungsi-fungsi dalam organisasi semakin
dikomputerisasikan
• Semakin kompleks data & aplikasi yg digunakan, maka
relationship antar data harus dimodelisasikan
• Dibutuhkannya kemandirian data
KONVERSI & LOADING DATA
• Tahap ini dilakukan apabila sistem basis data
yg ada digantikan sistem basis data baru
• Semua data yg ada ditransfer ke basis data
baru & konversi aplikasi yg ada utk basis data
baru
PENGOPERASIAN & PERAWATAN
• Pengoperasian basis data setelah divalidasi
• Memonitor kinerja sistem, jika tidak sesuai
perlu reorganisasi basis data
• Perawatan & upgrade sistem aplikasi basis
data jika diperlukan.
Model Konseptual Basis Data
Model konseptual merupakan kombinasi beberapa cara
untuk memproses data untuk beberapa aplikasi.
Pada perancangan model konseptual basis data ini
penekanan dilakukan pada struktur data dan relasi antara
field.
Pada perancangan model konseptual ini dapat dilakukan
dengan menggunakan model data relasional.
Teknik Normalisasi
Proses normalisasi adalah proses pengelompokan data elemen
menjadi tabel-tabel yang menunjukkan entity dan relasinya.
Pada proses normalisasi dilakukan pengujian pada beberapa
kondisi apakah ada kesulitan pada saat
menambah/menyisipkan, menghapus, mengubah dan
mengakses pada suatu Basis data.
Bila terdapat kesulitan pada pengujian tersebut maka perlu
dipecahkan relasi pada beberapa tabel lagi atau dengan kata
lain perancangan basis data belum optimal.
Entity
Entity atau entitas, dalam basis data entity
sama halnya dengan sebuah tabel.
Atribut
Atribut, dalam basis data sama halnya
dengan field.
Jenis Atribut
• Atribut Sederhana
• Atribut Komposit
• Atribut Bernilai Tunggal
• Atribut Bernilai Jamak
• Atribut Harus Bernilai
• Atribut Bernilai Null
• Atribut Turunan
Atribut Sederhana
Atribut Sederhana : atribut sederhana merupakan atribut
atomik
yang tidak dapat lagi dipecah menjadi atribut lain.
Contoh:
Entitas mahasiswa mempunyai atribut sederhana berupa NIM,
NamaMahasiswa .
Atribut Komposit
Atribut Komposit : atribut komposit merupakan atribut yang
masih
dapat dipecah menjadi sub-sub atribut yang masing-masing
memiliki arti
tesendiri.
Contoh:
Entitas mahasiswa mempunyai atribut alamat. Maka alamat disini
dapat
dipecah menjadi sub atribut seperti kota, kab, kode_pos.
Entitas dosen mempunyai atribut nama_dosen. Maka nama disini
dapat
Atribut Bernilai Tunggal
Atribut Bernilai Tunggal : atribut yang hanya
memiliki satu nilai untuk setiap barisnya.
Contoh:
entitas mahasiswa mempunyai atribut NIM, nama,
alamat isi data
dari atribut ini hanya boleh diisi dengan 1 data.
Setiap mahasiswa hanya memiliki 1 NIM, 1 Nama, 1
Alamat.
Atribut Bernilai Jamak
Atribut Bernilai Jamak : yaitu atribut yang boleh memiliki
lebih dari
satu nilai untuk setiap barisnya.
Contoh:
entitas mahasiswa mempunyai atribut Hobby isi data dari
atribut ini
boleh lebih dari 1 data. Mahasiswa Roshita memiliki NIM
04102002
beralamat di Jalan Garuda 32 Yogyakarta memiliki Hobby
(Olah Raga,
Atribut Harus Bernilai (not null)
Atribut Harus Bernilai : yaitu atribut yang harus memiliki nilai data
untuk setiap barisnya. Biasanya atribut seperti ini sudah ditetapkan
dalam perancangan tabelnya sehingga jika dalam pengisian di
kosongi
akan terjadi kesalahan.
Contoh:
entitas mahasiswa mempunyai atribut NIM dan nama_mahasiswa
yang harus diisi datanya, sebab jika tidak diisi akan terjadi kesalahan
(error) dalam basis data
Atribut Bernilai Null (is null)
Atribut Bernilai Null : yaitu atribut yang boleh tidak memiliki
nilai data
untuk setiap barisnya.
Contoh:
entitas mahasiswa mempunyai atribut hobby, nama_pacar yang
boleh tidak terisi.
Atribut Turunan
Atribut Turunan : yaitu atribut yang nilai-nilainya diperoleh
dari
pengolahan atau dapat diturunkan dari atribut lain yang
berkaitan.
Contoh:
entitas mahasiswa mempunyai atribut IPK yang diperoleh
dari
pengolahan atribut Nilai pada tabel (entitas Nilai) dengan
kode NIM
mahasiswa yang sama dan diproses sehingga menghasilkan
Field (Atribut) Kunci
setiap field selalu terdapat kunci berupa field atau satu set field
yang dapat mewakili record.
Misalnya Nomor Induk Mahasiswa (NIM) merupakan
kunci dari tabel mahasiswa suatu Perguruan Tinggi, setiap pencarian
cukup dengan menyebut NIM mahasiswa tersebut maka dapat diketahui
identitas mahasiswa lainnya seperti nama, alamat dan atribut lainnya.
Contoh lain:
Nomor Pegawai (NIDN) bagi data dosen, NIK untuk data karyawan,
Kode_Kuliah untuk data Mata kuliah, dan lain sebagainya.
Kunci Kandidat (Candidate Key)
Kunci kandidat adalah satu atribut atau satu set atribut
yang
mengidentifikasikan secara unik suatu kejadian spesifik
dari entity.
Satu set atribut menyatakan secara tidak langsung
dimana anda tidak
dapat membuang beberapa atribut dalam set tanpa
merusak
kepemilikan yang unik.
Kunci Kandidat (Candidate Key)
Contoh:
Tabel pegawai berisi field:
• nik
• no_ktp
• nama_pegawai
• tmp_lahir
• tgl_lahir
• alamat
• kota
Kunci kandidat dalam tabel pegawai di disamping
dapat dipilih sbb :
nik
no_ktp
nama_pegawai (tidak dapat dipakai karena
sering seseorang punya nama yang
sama dengan orang lain)
tmp + tgl Lahir (mungkin bisa dipakai
sebagai kunci karena kemungkinan orang
dengan nama yang sama dan tanggal lahir
yang
sama cukup kecil)
nama + tmp + tgl_lahir (dapat dipakai
sebagai kunci)
alamat dan kota (bukan kunci)
Kunci Kandidat (Candidate Key)
Contoh Kasus:
Tentukan Kunci Kandidat dari tabel tersebut
Tabel mt_kuliah berisi field:
•
id_matkul
•
kode_matkul
•
nama_matkul
•
kurikulum
•
semester
•
sks
•
nilai_minimum
Kunci kandidat dalam tabel mt_kuliah di disamping
dapat dipilih sbb :
id_matkul
kode_matkul
nama_matkul (mungkin bisa dipakai sebagai
kunci karena kemungkinan nama matkul
dengan yang lain ada perbedaan)
kurikulum + semester + sks +
nilai_minimum (tidak dapat dipakai karena
sering matkul punya data yang
sama dengan matkul lain)
Kunci Primer (Primary Key)
Primary key adalah satu atribut atau satu set minimal atribut yang tidak
hanya mengidentifikasi secara unik suatu kejadian spesifik, tetapi juga dapat
mewakili setiap kejadian dari suatu entity.
Catatan:
Setiap kunci kandidat dapat menjadi kunci primer tetapi sebaliknya
sebaiknya
dipilih satu saja yang dapat mewakili secara menyeluruh terhadap entity
yang
ada.
Kunci Primer (Primary Key)
Contoh :
1.nik (karena sifatnya yang unik maka tidak mungkin pegawai
mempunyai Nomor Induk Karyawan yang sama).
2.no_ktp (bisa dipakai misalnya untuk pegawai yang baru
belum mendapatkan nomor pegawai maka bisa digunakan
nomor KTP untuk sementara sebagai kunci primer.
3.kode_mtkuliah (bisa dipakai untuk data mata kuliah karena
kode mata kuliah bersifat unik untuk tiap mata kuliah)
Kunci Primer (Primary Key)
Contoh Kasus:
Tentukan Kunci Primer dari tabel tersebut
Tabel mt_kuliah berisi field:
1. id_matkul
2. kode_matkul
3. nama_matkul
4. kurikulum
5. semester
6. sks
7. nilai_minimum
Kunci Alternatif (Alternate Key)
Kunci alternatif adalah kunci kandidat yang tidak dipakai
sebagai kunci primer. Kunci alternatif ini sering digunakan
untuk kunci pengurutan misalnya dalam membuat laporan.
Kunci Alternatif (Alternate Key)
Contoh Kasus:
Tentukan Kunci Alternatif dari tabel tersebut
Tabel krs berisi field:
1.no_krs
2.id_matkul
3.nim
4.nilai_angka
5.nilai_huruf
6.lulus
BACK
NEXT
Kunci Tamu (Foreign Key)
Kunci tamu adalah satu atribut atau satu set minimal atribut yang
melengkapi satu hubungan yang menunjukkan ke induknya.
kunci tamu ditempatkan pada entity anak dan sama dengan kunci primer
induk yang direlasikan.
Hubungan antara entity induk dengan anak adalah hubungan satu lawan
banyak (one to many relationship)
Kunci Tamu (Foreign Key)
Contoh Kasus:
Tentukan Kunci Tamu dari tabel tersebut
Kamus Data
Contoh Kamus Data :
Nama Database : akademik
Nama Tabel
: mahasiswa
Fungsi
: menyimpan data mahasiswa
Bahasa Basisdata
Contoh Kamus Data :
Nama Database
Nama Tabel
Fungsi
Nama Field
: akademik
: dosen
: menyimpan data profil dosen
Tipe
Panjang
Karakter
id
Integer
3
nidn
Varchar
15
glr_dpn
Varchar
15
nama
Varchar
20
glr_blk
Varchar
15
jab_akademik
Varchar
50
telp
Varchar
30
Varchar
30
Keterangan
Primary Key
Unique
Bahasa Basisdata
Contoh Kamus Data :
Nama Database : akademik
Nama Tabel
Fungsi
: mt_kuliah
: menyimpan data mata kuliah
Nama Field
Tipe
Panjang
Karakter
id
Integer
3
mtk_kode
Varchar
10
mtk_nama
Varchar
30
sks
Char
1
semester
Char
1
kurikulum
Char
9
nilai_min
Char
1
Keterangan
Primary Key
Bahasa Basisdata
Contoh Kamus Data :
Nama Database : akademik
Nama Tabel
Fungsi
: mtk_open
: menyimpan data mata kuliah yang dibuka
Nama Field
Tipe
Panjang
Karakter
id
Integer
10
mtk_id
Integer
3
dosen_id
Integer
3
thn_ajaran
Char
9
aktif
Char
1
Keterangan
Primary Key
ERD (Entity Relationship Diagram)
Keterangan :
Banyak pegawai bekerja pada satu
departemen.
ERD
(Entity Relationship
Diagram)
Contoh Kasus :
1. Sebuah perusahaan retail memiliki banyak pelanggan yang
telah memesan sejumlah barang produksi.
Gambarkan diagram ER dari proses transaksi pembelian
tersebut dan buatkan tabel-tabelnya!
SOLUSI
ER Diagram :
PELANGGAN
1
Order
N
BARANG
N
Proses
1
PENJUALAN
Keterangan:
Satu pelanggan dapat memesan banyak barang.
Banyak barang dapat diproses pada satu kali penjualan.
SOLUSI
Tabel :