Pengertian Database Design merupakan suatu proses dari pembuatan sebuah rancangan yang mendukung visi dan misi perusahaan yang dibutuhkan untuk sebuah sistem basis data. Perancangan basis data dibagi menjadi 3(tiga) tahapan utama yaitu Conceptual Database Design, Logical Database Design, dan Physical Database Design.

1. RESUME MANAJEMEN BASIS DATA
CONCEPTUAL, LOGICAL, AND PHYSICAL DATABASE DESIGN
Disusun oleh :
RINA MULDANY HARAHAP
J3D114104
TEK A / P 1
PROGRAM KEAHLIAN TEKNIK KOMPUTER
PROGRAM DIPLOMA
INSTITUT PERTANIAN BOGOR
BOGOR
2015

2. Database System
Pengertian Database Design merupakan suatu proses dari pembuatan sebuah rancangan
yang mendukung visi dan misi perusahaan yang dibutuhkan untuk sebuah sistem basis data.
Perancangan basis data dibagi menjadi 3(tiga) tahapan utama yaitu Conceptual Database
Design, Logical Database Design, dan Physical Database Design.
Conceptual Database Design (Perancangan Basis Data Konseptual)
Yang merupakan Proses membangun model data yang dipakai dalam suatu perusahaan,
independen dari semua pertimbangan fisik. The conceptual database design fase dimulai dengan
penciptaan data konseptual Model dari perusahaan, yang sepenuhnya independen dari rincian
implementasi seperti DBMS sasaran, program aplikasi, bahasa pemrograman, platform perangkat
keras, masalah kinerja, atau pertimbangan fisik lainnya. Langkah-langkah dalam pembuatan
model basis data konseptual adalah :
Langkah 1: Membangun model data konseptual adalah untuk membangun model data
konseptual terhadap kebutuhan data suatu perusahaan. Dengan cara :
Langkah 1.1 Mengidentifikasi Tipe Entitas
Yaitu dengan mendefinisikan suatu objek utama atau entitas dimana user memang
membutuhkannya. Misal dengan mengidentifikasi kata benda atau frase kata benda yang
telah disebutkan oleh user. Setelah tipe entitas diidentifikasi, dilakukan pemberian nama
yang berarti dan jelas kepada user. Mencatat nama dan deskripsi entitas dalam kamus
data. Apabila dimungkinkan, mendokumentasikan jumlah occurences yang diharapkan
dari tiap entitas. Jika entitas dikenal dengan nama yang berbeda, nama tersebut menunjuk
kepada sinonim atau alias yang dicatat dalam kamus data.
Langkah 1.2 Mengidentifikasi Tipe Hubungan/Relasi
Yaitu dengan relasi diidentifikasi dengan menggunakan kata kerja atau frase kata
kerja. Relasi yang paling umum adalah relasi binary. Yang artinya relasi antar entitas
yang persis antara dua entitas saja. Bagaimanapun, relasi kompleks yang melibatkan lebih

3. dari dua entitas dan relasi rekursif yang hanya melibatkan satu entitas harus diperhatikan.
Adapun langkah-langkah dalam mengidentifikasi tipe relasi sebagai berikut :
 Menggunakan Entity-Relationship (ER) Diagram
ERD digunakan untuk merepresentasikan entitas dan bagaimana relasi antar entitas
dan untuk membantu dalam pembuatan gambaran umum dari perancangan basis data
yang sedang dikembangkan.
 Menentukan multiplicity constraint dari tipe relasi
Setelah relasi antar entitas, maka langkah berikutnya adalah menentukan multiplicity
setiap relasi. Multiplicity constraints digunakan untuk mengecek dan memelihara
kualitas data. Constraints ini menyatakan entity ocurrences yang dapat dimasukkan
ketika database di-update untuk menentukan apakah pengupdate-an tersebut
melanggar aturan enterprise atau tidak.
 Mengecek Fan Traps dan Chasm Traps
Langkah berikutnya adalah mencek fan traps dan chasm traps. Yaitu dengan
merepresentasikan suatu relasi antar entitas. Tetapi alur relasinya memperlihatkan
ambiguitas. Chasm traps adalah suatu model dimana terdapat hubungan antar entitas
yang satu dengan yang lain, tetapi tidak ada relasi antar kedua entitas yang utama.
 Mengecek setiap entitas mempunyai minimal sebuah relasi
Pada pembuatan ERD, pastikan setiap entitas mempunyai minimal satu relasi dengan
entitas yang lain. Jika memang setiap entitas sudah memiliki minimal satu relasi
dengan entitas yang lain, maka langkah berikutnya adalah memperhatikan kamus
data.
 Mendokumentasikan tipe relasi
Setelah tipe relasi diidentifikasi, langkah selanjutnya adalah memberi nama yang
mempunyai makna dan jelas kepada user. Selain itu, juga merecord deskripsi relasi
dan multiplicity constraints pada kamus data.
Langkah 1.3 : Mengidentifikasi atribut pada tiap entitas
Untuk mengidentifikasi dan mengasosiasikan atribut yang sesuai dengan tipe
entitas atau tipe relasi. Atribut dapat dibagi menjadi 3 yaitu :

4. 1. Simple atau Composite Atribut
Salah satu hal yang penting adalah perlunya memperhatikan apakah suatu atribut
tertentu adalah simple atau composite. Composite atribut adalah atribut yang dibangun
dari simple atribut. Sebagai contoh, atribut alamat bisa saja dibuat simple dan
menyimpan beberapa detail dari alamat sebagai suatu nilai.
2. Single atau Multi-valued Atribut Suatu atribut
Selain dapat menjadi single atau composite, dapat pula mempunyai satu atau lebih
nilai, sebagai contohnya yaitu atribut nomor telepon. Seseorang bisa saja mempunyai
nomor telepon lebih dari satu, keadaan seperti itu dapat disebut multi-valued atribut.
Tetapi apabila atribut tertentu hanya mempunyai satu nilai maka disebut single atribut.
3. Derived Atribut
Derived atribut adalah atribut yang nilainya tergantung dengan nilai atribut yang lain.
Contoh, umur seorang staff, banyaknya properti yang dikelola oleh seorang staff, dan
pinjaman deposit yang dihitung dua kali pada pinjaman bulanannya.
Langkah 1.4 : Menentukan domain atribut
Untuk menentukan domain dari atribut yang ada di dalam model data konseptual
lokal. Contoh : Domain atribut dari nomor staff (staffNo) terdiri dari lima karakter string
dimana dua karakter awal berupa huruf, sedangkan tiga karakter berikutnya berupa angka
yang berkisar dari 1-999 dan Nilai yang mungkin untuk atribut sex adalah ‘M’ atau ‘F’.
Domain dari atribut ini adalah karakter string tunggal yang berisi nilai ‘M’ atau ‘F’.
Langkah 1.5 : Mengidentifikasi candidate key dan primary key tiap atribut
Untuk mengidentifikasi candidate key dari setiap tipe entitas, dan jika memang
terdapat lebih dari satu candidate key, pilihlah salah satunya untuk menjadi primary key,
dan yang lainnya sebagai alternate key. Pada saat memilih primary key diantara candidate
key, gunakanlah petunjuk berikut untuk membantu pemilihan : Candidate key dengan
jumlah set atribut paling sedikit, Candidate key yang nilainya jarang sekali berubah,
Candidate key dengan jumlah karakter paling sedikit, Candidate key dengan nilai
maksimalnya yang terkecil, dan Candidate key yang paling mudah digunakan dari sudut
pandang user.

5. Langkah 1.6: Mempertimbangkan penggunaan konsep pemodelan enhanced
(langkah optional)
Agar dapat mempertimbangkan penggunaan konsep enhanced modeling, seperti
specialization, generalization, aggregation dan composition.
Langkah 1.7 : Mengecek redundansi
Untuk mengecek apakah ada redundansi dalam model basis data. Adapun langkah
untuk menghilangkannya yaitu Menguji kembali relasi one-to-one (1:1), Menghilangkan
relasi redundansi, dan Mempertimbangkan dimensi waktu.
Langkah 1.8 : Memvalidasi konseptual lokal terhadap transaksi pengguna
Untuk memastikan bahwa model konseptual lokal mendukung transaksi yang
diperlukan oleh user. Pengujian dilakukan dengan dua pendekatan yang mungkin untuk
memastikan model data konseptual mendukung transaksi yang diperlukan yaitu
mendeskripsikan transaksi, menggunakan jalur transaksi.
Langkah 1.9 : Me-review data konseptual terhadap kebutuhan pengguna
Untuk me-review model data konseptual lokal bersama user guna memastikan bahwa
yang ada sudah merupakan representasi yang ‘benar’ dari kebutuhan data enterprise.
Logical Database Design (Perancangan Basis Data Logikal)
Perancangan basis data logikal merupakan suatu proses membangun sebuah data
spesifik, tetapi terlepas dari DBMS tertentu dan pertimbangan fisikal lainnya. Langkah-
langkah dalam perancangan basis data logikal adalah sebagai berikut :
Langkah 2 : Membangun dan Memvalidasi Data Logikal untuk Setiap View
Untuk menerjemahkan model data konseptual kedalam data logikal dan kemudian
memvalidasi tersebut untuk mengecek apakah secara struktur benar dan mendukung
transaksi yang dibutuhkan.
Langkah 2.1 : Menentukan relasi untuk data logikal
Agar membuat suatu relasi untuk data logikal yang merepresentasikan suatu entitas,
relasi dan juga atribut yang telah diidentifikasi. Adapun pendeskripsian bagaimana relasi

6. dapat diturunkan dari struktur di bawah ini yang terjadi dalam model data konseptual
antara lain:
1. Tipe entitas kuat (Strong Entity Type)
2. Tipe entitas lemah (Weak Entity Type )
3. Tipe relasi binary one-to-many (1:*)
4. Tipe relasi binary one-to-one (1:1)
5. Tipe relasi rekursif one-to-one (1:1)
6. Tipe relasi superclass atau subclass
7. Tipe relasi binary many-to-many
8. Tipe relasi kompleks
9. Atribut multi-valued
Langkah 2.2 : Memvalidasi relasi dengan menggunakan normalisasi
Untuk memvalidasi relasi model data logikal dengan menggunakan teknik
normalisasi. Tujuan dari normalisasi yaitu Meminimalkan jumlah atribut yang perlu
untuk mendukung kebutuhan data dari suatu perusahaan, Atribut dengan relasi logikal
yang dekat (digambarkan sebagai functional dependency) yang ditemukan dalam relasi
yang sama, dan Meminimalkan redundansi dengan tiap atribut direpresentasikan hanya
sekali dengan pengecualian atribut yang membentuk semua atau sebagian foreign key
yang penting untuk berpartisipasi dalam relasi yang terhubung.
Langkah 2.3 : Memvalidasi relasi terhadap transaksi user
Untuk suatu pengecekan bahwa relasi yang dibuat pada langkah sebelumnya juga
mendukung transaksi ini, dan karena itu dipastikan juga bahwa tidak ada error dalam
relasi yang telah dibuat.
Langkah 2.4 : Mengecek batasan integritas
Untuk mengecek batasan integritas agar diharapkan dapat menjaga basis data supaya
tidak menjadi tidak lengkap (incomplete), tidak akurat (inaccurate), atau tidak konsisten
(inconsistent). Ini enam tipe batasan integritas, antara lain yaitu data yang dibutuhkan,
batasan domain atribut, multiplicity, integritas entitas, integritas referensial, dan batasan
umum.
Langkah 2.5 : Me-review data logikal terhadap kebutuhan pengguna
Untuk me-review model data logikal dengan user untuk memastikan bahwa model
tersebut sesuai dengan representasi yang benar dari kebutuhan data perusahaan. Apabila

7. user merasa tidak puas dengan model tersebut maka dilakukan pengulangan kembali
langkah-langkah sebelumnya jika diperlukan.
Langkah 2.6 : Menggabungkan data logikal kedalam global (langkah optional)
Untuk rancangan basis data dengan multiple user yang dikelola menggunakan
pendekatan sudut pandang integrasi. Untuk memfasilitasi gambaran proses
penggabungan, digunakan model data logikal lokal dan model data logikal global. Model
data logikal lokal merepresentasikan satu atau lebih tetapi tidak semua sudut pandang
user terhadap basis data. Sedangkan model data logikal global merepresentasikan semua
sudut pandang user terhadap basis data. Dalam langkah ini, dilakukan penggabungan dua
atau lebih model data logikal lokal kedalam satu model data logikal global. Aktivitas
penggabungan tersebut meliputi :
Langkah 2.6.1 : Penggabungan data logikal lokal kedalam global
Untuk menggabungkan model data logikal lokal kedalam satu data logikal global.
Beberapa tugas dari pendekatan ini adalah sebagai berikut :
1. Review nama dan isi dari suatu entitas atau relasi dan candidate key-nya.
2. Me-review nama dan isi dari suatu relasi atau foreign key.
3. Menggabungkan entitas atau relasi dari model data lokal.
4. Memasukkan (tanpa penggabungan) entitas atau relasi yang unik untuk setiap model
data lokal.
5. Menggabungkan relasi atau foreign key dari model data lokal.
6. Memasukkan (tanpa penggabungan) relasi atau foreign key yang unik untuk setiap
model data lokal.
7. Mengecek entitas atau relasi dan relasi atau foreign key yang hilang.
8. Mengecek foreign key.
9. Mengecek batasan integritas.
10. Menggambar ER global atau diagram relasi.
11. Meng-update dokumentasi.
Langkah 2.6.2 : Memvalidasi data logikal global
Dapat memvalidasi relasi yang dibuat dari model data logikal global dengan
menggunakan teknik normalisasi dan juga memastikan bahwa relasi yang dibuat
mendukung transaksi yang dibutuhkan, jika perlu.

8. Langkah 2.6.3 : Me-review data logikal global dengan user
Me-review model data logikal global dengan user untuk memastikan bahwa model
yang dibuat tersebut merupakan representasi yang benar terhadap kebutuhan data
perusahaan.
Langkah 2.7 : Mengecek kemungkinan pengembangan di masa depan
Menentukan bagian mana yang kelihatannya akan berubah ke masa depannya dan
juga memperhatikan supaya model data logikal dapat mengakomodasi perubahan
tersebut. Hasil akhir dari perancangan basis data logikal adalah merancang suatu model
informasi berdasarkan spesifik model yang ada (seperti model relasional), tetapi tidak
tergantung terhadap suatu DBMS dan perangkat keras lainnya. Basis data logikal
merancang suatu map untuk setiap lokal konseptual data. Jika terdapat lebih dari satu
pandangan user, maka model data logikal lokal akan dikombinasikan menjadi suatu
model data logikal global yang merepresentasikan semua pandangan user dari suatu
perusahaan.
Physical Database Design (Perancangan Basis Data Fisikal)
Perancangan basis data fisikal adalah suatu proses untuk mendeskripsikan
pengimplementasian dari suatu basis data pada media penyimpanan secondary, dengan
mendeskripsikan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai
keefisienan dalam mengakses data, dan batasan integritas, serta pengukuran keamanan
apapun yang berhubungan.
Langkah 3 : Menerjemahkan Data Logikal sesuai DBMS yang Dituju
Untuk membuat suatu skema basis data relasional dari model data logikal yang dapat
diimplementasikan ke DBMS yang dituju.
Langkah 3.1 : Merancang relasi dasar
Yaitu dengan memutuskan bagaimana merepresentasikan relasi dasar yang
diidentifikasi dalam data logikal pada DBMS yang dituju. Untuk memulai proses
perancangan basis data fisikal, pertama-tama dapat dilakukan dengan menyatukan dan
mengasimilasikan informasi mengenai relasi yang dirancang selama perancangan basis
data logikal. Informasi yang diperlukan dapat berasal dari kamus data dan definisi relasi

9. yang didefinisikan menggunakan Database Design Language (DDL). Untuk setiap relasi
yang diidentifikasi pada model data logikal, dapat didefinisikan berisi :
a. Nama relasi;
b. Daftar simple atribut dalam tanda kurung;
c. Primary key (PK), alternate key (AK), dan foreign key (FK);
d. Batasan integritas referensial untuk setiap foreign key yang diidentifikasi;
e. Dari kamus data, dari setiap atributnya dapat diketahui;
f. Domain atribut tersebut yang terdiri dari tipe data, panjang, dan berbagai constraint
pada domain tersebut;
g. Suatu optional nilai default untuk atribut;
h. Apakah atribut dapat diisi dengan nilai null;
i. Apakah atribut dapat diturunkan dan jika demikian bagaimanA perhitungannya.
Langkah 3.2 : Merancang representasi data turunan (derived data)
Agar memutuskan bagaimana merepresentasikan suatu data turunan yang terdapat
pada model data logikal pada DBMS yang dituju. Atribut yang nilainya didapatkan
dengan mengevaluasi atribut lain dikenal sebagai atribut turunan atau atrribut kalkulasi.
Sebagai contoh : Jumlah staf yang bekerja pada suatu cabang (branch), Total gaji bulanan
untuk semua staf dan Jumlah properti yang di-handle oleh anggota staf.
Langkah 3.3 : Merancang general constraint
Untuk merancang kendala umum untuk DBMS yang dituju. Meng-update suatu
relasi yang mungkin dibatasi oleh batasan integritas yang mengatur transaksi ‘real world’
yang direpresentasikan oleh peng-update-an tersebut. Perancangan batasan tersebut sekali
lagi tergantung pada DBMS yang dipilih. Beberapa sistem menyediakan fasilitas-fasilitas
dibandingkan yang lainnya untuk mendefinisikan kendala umum. Seperti langkah
sebelumnya, jika sistem tersebut mempunyai aturan sesuai aturan standar SQL, beberapa
batasan dapat diterapkan.
Langkah 4 : Merancang Organisasi File dan Indeks
Menentukan organisasi file yang optimal untuk menyimpan relasi dasar dan indeks
yang dibutuhkan untuk mencapai kinerja yang diharapkan. Karena itu, cara dimana relasi
dan tuples yang ada akan disimpan pada penyimpanan secondary.
Langkah 4.1 : Menganalisis transaksi

10. Untuk memahami fungsionalitas dari suatu transaksi dimana akan dijalankan pada
basis data untuk menganalisis transaksi yang penting.
Langkah 4.2 : Memilih organisasi file
Untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. Beberapa
organisasi file efisien untuk bulk loading data kedalam basis data tetapi setelah itu tidak
efisien. Dengan kata lain, kita ingin menggunakan struktur penyimpanan yang efisien
untuk mengeset basis data dan kemudian mengubahnya untuk penggunaan operasional
normal. Karena itu, tujuan dari langkah ini adalah untuk memilih organisasi file yang
optimal untuk tiap relasi, jika DBMS yang dituju memperbolehkannya. Dalam banyak
kasus yang ada, suatu relasional DBMS akan memberikan sedikit bahkan tanpa pilihan
dalam memilih organisasi file, walaupun beberapa akan mempunyai indeks yang spesifik.
Beberapa macam organisasi file yang ada adalah sebagai berikut yaitu Heap, Hash,
Indexed Sequential Office Access Method (ISAM), B*-three, dan Clusters. Jika DBMS
yang dituju tidak memperbolehkan adanya pemilihan organisasi file, maka langkah ini
dapat dihilangkan.
Langkah 4.3 : Memilih indeks
Untuk mengurutkan tuple dalam relasi dengan menspesifikasi primary atau clustering
indeks. Dalam kasus ini, biasanya pemilihan suatu atribut untuk pengurutan atau
clustering pada tuple adalah sebagai berikut :
a. Suatu atribut yang digunakan paling sering untuk operasi penggabungan (join), yang
akan membuat operasi penggabungan itu lebih efisien.
b. Suatu atribut yang digunakan paling sering untuk mengakses suatu tuple didalam relasi
yang ada. Apabila pengurutan atribut yang dipilih adalah kunci dari relasi, indeks tersebut
akan menjadi primary index. Sedangkan jika pengurutan atribut yang dipilih bukan
merupakan kunci dari relasi, indeks tersebut akan menjadi clustering index. Setiap relasi
hanya dapat mempunyai primary index atau clustering index.
Langkah 4.4 : Mengestimasi kapasitas penyimpanan
Untuk mengestimasi jumlah kapasitas disk yang akan dibutuhkan oleh basis data
dalam mendukung implementasi basis data pada penyimpanan secondary. Seperti pada
langkah sebelumnya, mengestimasi penggunaan disk sangat bergantung pada DBMS
yang dituju dan perangkat lunak yang digunakan untuk mendukung basis data. Secara

11. umum estimasi tersebut dilakukan berdasarkan ukuran tiap tuple dan jumlah tuple dalam
relasi.
Langkah 5 : Merancang Tampilan untuk User
Untuk merancang tampilan user yang diidentifikasi selama tahap pengumpulan dan
analisis kebutuhan pada Siklus Hidup Pengembangan Sistem Basis Data.
Langkah 6 : Merancang Mekanisme Keamanan
Sasaran dari tahap ini adalah untuk memutuskan bagaimana kebutuhan keamanan ini
akan direalisasikan. Perancang basis data harus hati-hati terhadap fasilitas yang
ditawarkan oleh DBMS yang dituju. Relasional DBMS biasanya menyediakan dua
macam keamanan basis data antara lain : Keamanan sistem dan Keamanan data
Keamanan sistem menutupi pengaksesan dan penggunaan basis data pada tingkat
sistem, seperti username dan password. Sedangkan keamanan data penutupan
pengaksesan dan penggunaan objek basis data (seperti relasi dan views) dan tindakan
dimana user dapat memperoleh objek tersebut. Beberapa issue keamanan yang perlu
diperhatikan yaitu Pencurian data (Theft and Fraud), Kehilangan kerahasiaan data (Loss
of Confidentially), Kehilangan hak pribadi (Loss of Privacy), Kehilangan integritas (Loss
of integrity) dan Kehilangan ketersediaan data (Loss of availability)
Faktor keberhasilan di Desain Basis Data
Agar menadapatkan keberhasilan dalam Desain Basis Database dengan : Bekerja secara
interaktif dengan pengguna sebanyak mungkin, ikuti metodologi terstruktur sepanjang proses
pemodelan data, empekerjakan pendekatan data-driven, Memasukkan pertimbangan struktural
dan integritas ke dalam model data, Campurkan konseptualisasi, normalisasi, dan teknik validasi
transaksi ke dalam metodologi pemodelan data, Gunakan diagram untuk mewakili sebanyak satu
model data yang mungkin, Gunakan Database Design Language (DBDL) untuk mewakili
semantik data tambahan yang tidak dapat dengan mudah direpresentasikan dalam sebuah
diagram, Membangun kamus data untuk melengkapi diagram model data dan DBDL tersebut
dan bersedia untuk mengulangi langkah-langkah.