Perancangan DataBase 2
Diarsipkan di bawah: Uncategorized | Tag: Perancangan Database2
Tinggalkan sebuah Komentar
Di dalam suatu organisasi yang besar, sistem database merupakan bagian penting pada sistem informasi, karena di perlukan untuk mengelola sumber informasi pada organisasi tersebut. Untuk mengelola sumber informasi tersebut yang pertama kali di lakukan adalah merancang suatu sistem database agar informasi yang ada pada organisasi tersebut dapat digunakan secara maksimal.
Tujuan Perancangan Database
· Untuk memenuhi kebutuhan akan informasi dari pengguna dan aplikasi
· Menyediakan struktur informasi yang natural dan mudah di mengerti oleh pengguna
· Mendukung kebutuhan pemrosesan dan beberapa obyek kinerja dari suatu sistem database
Berikut ini siklus kehidupan sistem informasi di mana terdapat siklus kehidupan sistem database.
Siklus Kehidupan Sistem Informasi (Macro Life Cycle )
Tahapan–tahapan yang ada pada siklus kehidupan sistem informasi yaitu :
1. Analisa Kelayakan
Tahapan ini memfokuskan pada penganalisaan areal aplikasi yang unggul , mengidentifikasi pengumpulan informasi dan penyebarannya, mempelajari keuntungan dan kerugian , penentuan kompleksitas data dan proses, dan menentukan prioritas aplikasi yang akan digunakan.
2. Analisa dan Pengumpulan Kebutuhan Pengguna
Kebutuhan–kebutuhan yang detail dikumpulkan dengan berinteraksi pada sekelompok pemakai atau pemakai individu. Mengidentifikasikan masalah yang ada dan kebutuhan-butuhan, ketergantungan antar aplikasi, komunikasi dan prosedur laporan.
3. Perancangan
Perancangan terbagi menjadi dua yaitu : perancangan sistem database dan sistem aplikasi
4. Implementasi
Mengimplementasikan sistem informasi dengan database yang ada
5. Pengujian dan Validasi
Pengujian dan validasi sistem database dengan kriteria kinerja yang diinginkan oleh pengguna.
6. Pengoperasian dan Perawatan
Pengoperasian sistem setelah di validasi disertai dengan pengawasan dan perawatan sistem
Siklus Keh idupan Aplikasi Database ( Micro Life Cycle )
Tahapan yang ada pada siklus kehidupan aplikasi database yaitu :
1. Pendefinisian Sistem
Pendefinisian ruang lingkup dari sistem database, pengguna dan aplikasinya.
2. Perancangan Database
Perancangan database secara logika dan fisik pada suatu sistem database sesuai dengan sistem manajemen database yang diinginkan.
3. Implementasi Database
Pendefinisian database secara konseptual, eksternal dan internal, pembuatan file–file database yang kosong serta implementasi aplikasi software.
4. Pengambilan dan Konversi Data
Database ditempatkan dengan baik, sehingga jika ingin memanggil data secara langsung ataupun merubah file–file yang ada dapat di tempatkan kembali sesuai dengan format sistem databasenya.
5. Konversi Aplikasi
Software-software aplikasi dari sistem database sebelumnya di konversikan ke dalam sistem database yang baru
6. Pengujian dan Validasi
Sistem yang baru telah di test dan di uji kinerja nya
7. Pengoperasian
Pengoperasian database sistem dan aplikasinya
8. Pengawasan dan Pemeliharaan
Pengawasan dan pemeliharaan sistem database dan aplikasi software
Proses Perancangan Database
Ada 6 tahap untuk proses perancangan suatu database :
1. Pengumpulan data dan analisis
2. Perancangan database secara konseptual
3. Pemilihan sistem manajemen database
4. Perancangan database secara logika
5. Perancangan database secara fisik
6. Implementasi sistem database
Struktur dan Aplikasi
Isi Data Database
Tahap 1 |
Analisis dan Pengumpulan kebutuhan pengguna |
Pengumpulan data |
Pengumpulan Pemrosesan |
Tahap 2 |
Perancangan Konseptual |
Perancangan Konseptual skema |
Perancangan Transaksi dan Aplikasi
|
Tahap 3 |
Pemilihan Sistem Manajemen Database |
Tahap 4 |
Perancangan Logik |
Perancangan Konseptual dan Eksternal skema |
Seberapa Batasan Kinerjanya |
Tahap 5 |
Perancangan Fisik |
Skema internal |
Tahap 6 |
Implementasi |
Perintah DDL Perintah SDL |
Implementasi transaksinya |
|
Keterangan :
Secara khusus proses perancangan berisikan 2 aktifitas paralel. Aktifitas yang pertama melibatkan perancangan dari isi data dan struktur database, sedangkan aktifitas kedua mengenai perancangan pemrosesan database dan aplikasi–aplikasi perangkat lunak.
Dua aktifitas ini saling berkaitan , misalnya mengidentifikasi data item yang akan disimpan dalam database dengan cara menganalisa aplikasi–aplikasi database. Dua aktifitas ini juga saling mempengaruhi satu sama lain. Contohnya tahap perancangan database secara fisik, pada saat memilih struktur penyimpanan dan jalur akses dari file suatu database dimana bergantung dengan aplikasi–aplikasi yang akan menggunakan file tersebut.
Penentuan perancangan aplikasi–aplikasi database yang mengarah ke konstruksi skema database telah ditentukan selama aktifitas pertama.
Ke-enam tahap yang telah disebutkan sebelumnya dapat di proses secara tidak berurutan . Dalam beberapa hal, dapat dilakukan modifikasi perancangan kembali ke tahap yang pertama (feedback loop) setelah melakukan tahap selanjutnya.
Tahap 1 : Pengumpulan data dan analisis
Sebelum merancang suatu database, yang harus dilakukan adalah mengetahui dan menganalisis apa yang diinginkan dari pengguna aplikasi, sehingga proses ini disebut pengumpulan data dan analisis. Untuk menspesifikasikan kebutuhan yang pertama kali dilakukan adalah mengidentifikasi bagian lain di dalam sistem informasi yang berinteraksi dengan sistem database. Termasuk pengguna yang baru atau yang sudah lama juga aplikasinya, kebutuhan–kebutuhan tersebut dikumpulkan dan di analisa.
Kegiatan pengumpulan data dan analisis :
· Menentukan kelompok pemakai dan areal bidang aplikasinya.
Pengguna yang menguasai aplikasi yang lama dari setiap bagian dipilih untuk menyampaikan kebutuhan-kebutuhan dan menspesifikasikannya.
· Peninjauan dokumentasi yang ada.
Dokumen yang berhubungan dengan aplikasi yang akan dibuat dipelajari dan dianalisa, sedangkan dokumen lainnya seprti kebijakan manual, form, laporan–laporan dan bagan-bagan organisasi diuji dan ditinjau kembali untuk mengetahui apakah dokumen tersebut berpengaruh terhadap pengumpulan data dan proses spesifikasi
· Analisa lingkungan operasi dan kebutuhan pemrosesan.
Lingkungan operasional yang sekarang dan informasi yang direncanakan akan di gunakan dipelajari, termasuk menganalisa jenis–jenis dari transaksi dan frekuensi transaksinya seperti halnya alur informasi dengan sistem. Input dan output data untuk transaksi tersebut harus diperinci.
· Pengumpulan respon terhadap daftar pertanyaan dan angket yang telah dibuat sebelumnya.
Pengumpulan respon dari angket dan daftar pertanyaan berisikan prioritas para pengguna dan penempatan mereka di dalam berbagai aplikasi. Ketua kelompok mungkin akan ditanya untuk membantu para pengguna dalam memberikan informasi yang penting dan menentukan prioritas.
Teknik yang digunakan dalam penspesifikasian kebutuhan secara formal :
· OOA ( Object Oriented Analysis )
· DFD ( Data Flow Diagram )
· HIPO ( Hierarchical Input Process Output )
· SADT ( Structured Analysis & Design )
Tahap 2 : Perancangan database secara konseptual
Tujuan dari tahap ini adalah untuk menghasilkan skema konseptual untuk databse yang tidak tergantung pada sistem manajemen database yang spesifik. Penggunaan model data tingkat tinggi seperti ER/EER sering digunakan didalam tahap ini. Di dalam skema konseptual dilakukan perincian aplikasi–aplikasi database dan transaksi–transaksi yang diketahui .
Ada dua kegiatan di dalam perancangan database secara konseptual :
· Perancangan skema konseptual :
Pada tahap ini kegiatan yang dilakukan mengecek tentang kebutuhan– kebutuhan pemakai terhadap data yang dihasilkan dari tahap 1, dimana
tujuan dari proses perancangan skema konseptual adalah menyatukan pemahaman dalam struktur database, pengertian semantik, keterhubungan dan batasan-batasannya, dengan membuat sebuah skema database konseptual dengan menggunakan model data ER/EER tanpa tergantung dengan sistem manajemen database
Ada dua pendekatan perancangan skema konseptual :
· Terpusat
Kebutuhan–kebutuhan dari aplikasi atau kelompok–kelompok pemakai yang berbeda digabungkan menjadi satu set kebutuhan pemakai kemudian dirancang menjadi satu skema konseptual.
· Integrasi view–view yang ada
Untuk masing–masing aplikasi atau kelompok–kelompok pemakai yang berbeda dirancang sebuah skema eksternal ( view ) kemudian view – view tersebut disatukan ke dalam sebuah skema konseptual.
Ada 4 strategi dalam perancangan skema konseptual :
¨ Top down
¨ Bottom Up
¨ Inside Out
¨ Mixed
· Transaksi
Merancangan karakteristik dari transaksi–transaksi yang akan di implementasikan tanpa tergantung dengan DBMS yang telah dipilih. Transaksi–transaksi ini digunakan untuk memanipulasi database sewaktu diimplementasikan . Pada tahap ini diidentifikasikan input, output dan fungsional . Transaksi ini antara lain : retrieval, update dan delete, select dll.
Tahap 3 : Pemilihan Sistem Manajemen Database
Pemilihan sistem manajemen database ditentukan oleh beberapa faktor a.l : Teknik, Ekonomi, dan Politik Organisasi
Faktor Teknik :
· Tipe model data ( hirarki, jaringan atau relasional )
· Struktur penyimpanan dan jalur pengaksesan yang didukung sistem manajemen database
· Tipe interface dan programmer
· Tipe bahasa queri
Faktor Ekonomi :
· Biaya penyiadaan hardware dan software
· Biaya konversi pembuatan database
· Biaya personalia
· Biaya pelatihan
· Biaya pengoperasian
· Biaya pemeliharaan
Faktor Organisasi :
· Struktur data
Jika data yang disimpan dalam database mengikuti struktur hirarki, maka suatu jenis hirarki dari sistem manajemen database harus dipikirkan.
· Personal yang terbiasa dengan sistem yang terdahulu
Jika staff programmer dalam suatu organisasi sudah terbiasa dengan sautu sistem manajemen database maka hal ini dapat mengurangi biaya latihan dan waktu belajar.
· Ketersediaan dari service vendor
Keberadaan fasilitas pelayanan penjual sangat dibutuhkan untuk membantu memecahkan masalah sistem.
Tahap 4 : Perancangan database secara logika ( Transformasi model data )
Transformasi dari skema konseptual dan eksternal ( Tahap 2 ) ke model data sistem manajemen database yang terpilih, ada dua proses yaitu :
· Transformasi yang tidak tergantung pada sistem, pada tahap ini transformasi tidak mempertimbangkan karakteristik yang spesifik atau hal– hal khusus yang akan diaplikasikan pada sistem manajemen database
· Penyesuaian skema ke sistem manajemen database yang spesifik, di lakukan suatu penyesuaian skema yang dihasilkan dari tahap 1 untuk dikonfirmasikan pada bentuk implementasi yang spesifik dari suatu model data seperti yang digunakan oleh sistem manajemen database yang terpilih
Hasil dari tahap ini dituliskan dengan perintah DDL ke dalam bahasa sistem manajemen database terpilih. Tapi jika perintah DDL tersebut termasuk dalam parameter–parameter perancangan fisik , maka perintah DDL yang lengkap harus menunggu sampai tahap perancangan database secara fisik telah lengkap.
Tahap 5 : Perancangan Database Secara Fisik
Proses pemilihan struktur penyimpanan yang spesifik dan pengaksesan file– file database untuk mencapai kinerja yang terbaik di bermacam–macam aplikasi
Kriteria pemilihan perancangan fisik :
· Waktu respon
Waktu transaksi database selama eksekusi untuk menerima respon
· Penggunaan ruang penyimpanan
Jumlah ruang penyimpanan yang digunakan oleh database file dan struktur jalur pengaksesannya
· Terobosan yang dilakukan file transaksi
(Transaction troughput )
Merupakan nilai rata–rata transaksi yang dapat di proses permenit oleh sistem database dan merupakan parameter kritis dari sistem transaksi
Apabila waktu respon dari database tidak mencapai optimalisasi, maka pada tahap perancangan fisik ini dapat dilakukan denormalisasi.
Denormalisasi
Denormalisasi merupakan proses yang dilakukan pada database yang sudah dinormalisasi, dengan cara memodifikasi struktur tabel dan mengabaikan kerangkapan data (yang terkontrol) untuk meningkatkan kinerja database.
Proses denormalisasi termasuk :
§ Mengkombinasikan tabel-tabel yang terpisah dengan join
§ Mereplikasi/menduplikat data pada tabel
Tahap 6 : Implementasi
Implementasi skema database logik dan fisik ke dalam penyataan DDL dan SDL dari sistem manajemen database yang telah dipilih, untuk digunakan dalam pembuatan file–file database yang masih kosong
Studi Kasus :
Di bawah ini deskripsi mengenai suatu perusahaan yang akan di representasikan dalam database dan buat sesuai dengan proses perancangan database dari tahap 1 s/d tahap 4.
1. Suatu perusahaan terdiri atas bagian–bagian, masing–masing bagian mempunyai nama, nomor bagian dan lokasi . Setiap bagian mempunyai seorang pegawai yang mempunyai seorang pimpinan yang memimpin bagian tersebut.
2. Setiap bagian mengontrol sejumlah proyek dimana masing–masing proyek mempunyai nama, nomor proyek dan lokasi .
3. Setiap pegawai menjadi anggota pada salah satu bagian tapi dapat bekerja di beberapa proyek . Untuk setiap pegawai yang bekerja di proyek mempunyai jam kerja per-minggu . Seorang pegawai mempunyai nama, nomor pegawai, alamat, jenis kelamin, tanggal lahir dan usia serta supervisor / penyelia langsung. Pegawai juga mempunyai tanggungan yang terdiri atas nama, jenis kelamin dan hubungannya dengan si pegawai.
Catatan = Kasus diambil dari contoh Diagram ER pada materi Model Entity Relationship (Sistem Basis Data 1/Pengantar Sistem Basis Data)
**************
|
||||
|
||||
Contoh kasus Normalisasi
Diarsipkan di bawah: Uncategorized | Tag: Contoh Kasus Normalisasi
Tinggalkan sebuah Komentar
Bentuk normal pertama (BNI)
Tabel Contoh atribut jamak yaitu alamat
|
kode_plg |
Nama_plg |
Alamat1 |
Alamat2 |
alamat … |
|
P-101 |
Kirana |
Deresan II no 23 |
Perumahan no |
|
|
P-102 |
Karisma |
Karang Nangka II no 199 |
|
|
|
… |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Gambar Diagram E-R dengan entity alamat
Gambar Diagram E-R dengan entity penyalur
Gambar Diagram Skema BNI
Gambar Diagram E-R yang telah memenuhi BNII
Gambar Diagram Skema BNII
Gambar Skema Diagram BNII dengan tambahan atribut pada entity barang
Gambar Diagram E-R yang telah memenuhi BNIII
Gambar Skema Diagram BNIII
Tabel pelanggan
|
Kode_plg |
nama_plg |
Alamat |
|
P-101 |
Kirana |
Deresan II no 23 |
|
P-102 |
Karisma |
Karang Nangka II no 199 |
|
P-103 |
|
|
|
P-104 |
Lutfi |
Gendeng no 642 |
|
P-105 |
Qornain |
Gendeng no 642 |
|
P-106 |
|
Ambarukmo …. |
Tabel barang
|
kode_brg |
nama_brg |
tipe_brg |
|
B-101 |
pena |
alat tulis |
|
B-102 |
pensil 2B |
alat tulis |
|
B-103 |
penghapus |
alat tulis |
|
B-104 |
penggaris |
alat tulis |
|
B-201 |
batere nasional |
batu batere |
|
B-202 |
batere alkalin |
batu batere |
|
B-301 |
MILO 300 g |
Susu |
|
B-302 |
MILO 600 g |
Susu |
Tabel penyalur
|
Kode_pyl |
nama_pyl |
Alamat |
|
S-11 |
Indo Grosir |
Jl.Magelang no … |
|
S-12 |
Indo Maret |
Jl. Magelang no … |
|
S-13 |
Pamela |
Jl. Kusuma Negara no … |
|
S-14 |
WS |
Jl. Wonosari no … |
Tabel info
|
No_info |
Kode_brg |
kadaluarsa |
Harga dasar |
Persen_laba |
discount |
persediaan |
|
1 |
B-101 |
null |
3000 |
1.2 |
0.1 |
50 |
|
2 |
B-102 |
null |
1000 |
1.2 |
0.1 |
75 |
|
3 |
B-103 |
null |
1000 |
1.2 |
0.1 |
30 |
|
4 |
B-104 |
null |
2500 |
1.2 |
0.1 |
10 |
|
5 |
B-201 |
null |
1000 |
1.2 |
0.1 |
25 |
|
6 |
B-202 |
null |
2000 |
1.2 |
0.1 |
15 |
|
7 |
B-301 |
2007 |
13000 |
1.1 |
0.03 |
5 |
|
8 |
B-301 |
2009 |
13000 |
1.1 |
0.03 |
10 |
|
9 |
B-302 |
2007 |
25000 |
1.1 |
0.05 |
10 |
|
10 |
B-302 |
2009 |
25000 |
1.1 |
0.05 |
20 |
Studi Kasus Merancang Database
Tinggalkan sebuah KomentarOne Step at A Time
Kasus dalam tulisan ini adalah: Merancang database relasional untuk menyimpan data
“stok barang” – ini adalah ruang-lingkupnya (scope)
Dari spesifikasi yang sudah diperoleh dari pemakai (business user), kita ketahui bahwa
yang dimaksud dengan stok barang adalah jumlah tersedia (quantity on hand) untuk
setiap barang. Maka kita membutuhkan tabel stok_barang terdiri dari 2 kolom.
Beberapa baris datanya sebagai berikut.
nama_barang
…
Barang A
Barang B
Barang C
Barang D
…
jumlah_tersedia
…
100
150
175
250
…
1
Perhatikan bahwa setiap barang hanya memiliki satu jumlah_tesedia. Dengan kata
lain, nama barang unik didalam tabel stok_barang.
Spesifikasi juga meminta rancangan database kita untuk menangani transaksi
pembelian dan penjualan barang, dan dampaknya pada stok barang. Tepatnya, bila ada
barang masuk (pembelian) dan/atau keluar (penjualan), jumlah_tersedia perlu
dimutakhirkan (update).
Ada dua pilihan cara melaksanakannya:
1. Jumlah barang masuk/keluar langsung ditambah/kurang-kan pada kolom
jumlah_tersedia (update in place). Cara ini umumnya disebut sistem online. Data
transaksi keluar/masuk barang disimpan, misalnya untuk keperluan audit atau
rekonstruksi tabel stok_barang.
2. Data transaksi barang masuk dikumpulkan, setelah waktu tertentu, misalnya
akhir hari, barulah diperhitungkan ke jumlah_tersedia. Cara ini disebut sistem
batch.
Maka, untuk cara yang manapun dari kedua diatas, dibutuhkan satu tabel lagi untuk
menyimpan data transaksi, misalnya sebagai berikut.
nama_barang
…
Barang A
Barang A
Barang B
…
jumlah
…
1
10
5
…
masuk/keluar
…
m
k
k
…
tanggal
…
2-Jan-04
5-Jan-04
10-Jan-04
…
Agar nama barang dikedua tabel sinkron, maksudnya semua nama barang ditabel
transaksi_stok harus ada ditabel stok_barang, maka kedua tabel kita hubungkan:
nama_barang ditabel stok_barang kita migrasikan ketabel transaksi_stok. Dengan
kata lain, nama_barang ditabel transaksi_stok adalah foreign key dengan referensi
nama_barang ditabel stok_barang. Diagram ER (Entity Relationship) model data
sebagai berikut.
2
Perhatikan bahwa pada transaksi_stok, nama_barang dan tanggal adalah (composite)
primary key. Ini berarti dalam satu hari (tanggal) untuk suatu barang hanya boleh ada
satu transaksi.
Lebih lanjut, spesifikasi menyatakan bahwa, ada beberapa gudang, dan suatu barang
mungkin stoknya disimpan dibeberapa gudang (dan suatu gudang bisa menyimpan
lebih dari satu barang) Maka perlu ditambahkan data gudang. Struktur tabel kita
menjadi sebagai berikut.
nama_barang
…
Barang A
Barang A
Barang B
Barang C
Barang C
Barang D
…
gudang
…
Gudang 1
Gudang 2
Gudang 1
Gudang 2
Gudang 3
Gudang 3
jumlah_tersedia
…
100
10
150
175
20
250
…
Perhatikan bahwa setiap barang disuatu gudang hanya memiliki satu jumlah_tesedia.
Dengan kata lain, nama_barang bersama gudang-nya unik didalam tabel stok_barang.
Kini primary key tabel ini adalah nama_barang dan gudang. Dan, model data menjadi:
Karena oleh pemakai setiap barang sudah terbiasa diberi kode, maka dalam database
kode barang juga diinginkan, selain namanya. Pemakai juga memastikan didalam
spesifikasi, bahwa kode barang tidak pernah berubah, sedang nama barang kadang
perlu diubah, maka kita gunakan kode_barang sebagai primary key. Berkembanglah
model data kita menjadi:
3
Contoh isi tabel stok_barang sekarang adalah:
kode_barang
…
A01
A01
B01
C01
C01
D01
nama_barang
…
Barang A
Barang A
Barang B
Barang C
Barang C
Barang D
…
gudang
…
Gudang 1
Gudang 2
Gudang 1
Gudang 2
Gudang 3
Gudang 3
jumlah_tersedia
…
100
10
150
175
20
250
…
Dapat dilihat, nama barang ikut diulang bersama kode barangnya. Akibatnya, bila ada
perubahan nama, semua baris data barang bersangkutan harus seragam ikut dirubah
dan barang ditabel ini sudah diwakili oleh kode_barang. Ini berbahayakan integritas
data; maka sebaiknya dipisahkan, sebagai berikut.
4
Ringkasan
Laksanakan langkah-langkah demi langkah, jangan sekaligus menganalisa dan
merancang semua data dalam spesifikasi.
1. Mulai dengan minimal, satu tabel, berdasar makna fungsi yang dibutuhkan. Dalam
contoh kita, makna stok barang adalah quantity on hand untuk setiap barang.
2. Kembangkan struktur dari tabel ini, dengan makin menyertakan detil spesifikasi.
Dalam contoh kita, quantity on hand disetiap gudang – maka perlu ditambahkan
field “gudang”. Demikian juga dengan penambahan kode_barang.
3. Bila ada duplikat data (data sama di lebih dari satu baris) dan sudah ada wakilnya
pisahkanlah ditabel lain yang dihubungkan dengan tabel asalnya.
4. Fungsi berbeda biasanya memerlukan tabel terpisah; dalam contoh kita, fungsi
“transaksi stok”. Kita perlu tabel untuk menyimpan transaksi. Hubungkan dengan
tabel utama (umumnya disebut master dalam system batch) agar data terkait
dikedua tabel sinkron (integritas terjaga)
Makin besar dan rumit database yang harus kita rancang, teknik praktis ini makin
lebih terbukti efektivitasnya, dibandingkan dengan menggunakan teknik normalisasi
secara formal.
Model Database dan Studi kasus
Model database adalah suatu konsep yang terintegrasi dalam menggambarkan hubungan (relationships) antar data dan batasan-batasan (constraint) data dalam suatu sistem database. Model data yang paling umum, berdasarkan pada bagaimana hubungan antar record dalam database (Record Based Data Models), terdapat tiga jenis,
yaitu :
a. Model Database Hirarki (Hierarchical Database Model)
Model hirarkis biasa disebut model pohon, karena menyerupai pohon yang dibalik. Model ini menggunakan pola hubungan orangtua-anak
<!–[if mso & !supportInlineShapes & supportFields]> SHAPE <![endif]–>
|
Dosen Siti Nurbaya |
|
Dosen Ashadi |
|
Pengantar Basis Data |
|
Pemrograman C |
|
Matematika I |
|
Rudi |
|
Asti |
|
Dina |
|
Dina |
|
Edi |
|
Ita |
|
Edi |
<!–[if mso & !supportInlineShapes & supportFields]><![endif]–>
b. Model Database Jaringan (Network Database Model)
<!–[if mso & !supportInlineShapes & supportFields]> SHAPE <![endif]–>
|
Dosen Siti Nurbaya |
|
Dosen Ashadi |
|
Pengantar Basis Data |
|
Pemrograman C |
|
Matematika I |
|
Rudi |
|
Asti |
|
Dina |
|
Edi |
|
Ita |
<!–[if mso & !supportInlineShapes & supportFields]><![endif]–>
c. Model Database Relasi (Relational Database Model)
Model Relasional merupakan model yang paling sederhana sehingga mudah digunakan dan dipahami oleh pengguna. Model ini menggunakan sekumpulan tabel berdimensi dua ( yang disebut relasi atau tabel ), dengan masing-masing relasi tersusun atas tupel atau baris dan atribut. DBMS yang bermodelkan relasional biasa disebut RDBMS (Relational Data Base Management System). Model database ini dikemukakan pertamakali oleh EF codd, seorang pakar basisdata. Model ini sering disebut juga dengan database relasi.
Model database hirarki dan jaringan merupakan model database yang tidak banyak lagi dipakai saat ini, karena adanya berbagai kelemahan dan hanya cocok untuk struktur hirarki dan jaringan saja. Artinya tidak mengakomodir untuk berbagai macam jenis persoalan dalam suatu sistem database.
Model database relasi merupakan model database yang paling banyak digunakan saat ini, karena paling sederhana dan mudah digunakan serta yang paling penting adalah kemampuannya dalam mengakomodasi berbagai kebutuhan pengelolaan database. Sebuah database dalam model ini disusun dalam bentuk tabel dua dimensi yang terdiri dari baris (record) dan kolom (field), pertemuan antara baris dengan kolom disebut item data (data value), table-tabel yang ada di hubungkan (relationship) sedemikian rupa menggunakan field-field kunci (Key field) sehingga dapat meminimalkan duplikasi data.
Tingkatan Data Dalam Database Relasi
Dalam suatu sistem database relasi, data yang tersimpan dalam DBMS mempunyai tingkatan-tingkatan, sebagai berikut :
• Karakter (Characters)
Merupakan bagian terkecil dalam database, dapat berupa karakter numerik (angka 0 s.d 9), huruf ( A – Z, a – z) ataupun karakter-karakter khusus, seperti *, &. %, # dan lain-lain.
• Field atau Attribute
Merupakan bagian dari record yang menunjukkan suatu item data yang sejenis, Misalnya : field nama, file NIM dan lain sebagainya. Setiap field harus mempunyai nama dan tipe data tertentu. Isi dari field di sebut Data Value. Dalam table database, field ini disebut juga kolom.
Record atau Tupple
Tuple/Record adalah kumpulan data value dari attributee yang berkaitan sehingga dapat menjelaskan sebuah entity secara lengkap. Misal : Record entity mahasiswa adalah kumpulan data value dari field nobp, nama, jurusan dan alamat per-barisnya. Dalam tabel database, Record disebut juga baris.
• Table/Entity
Entity merupakan sesuatu yang dapat diidentifikasi dari suatu sistem database, bisa berupa objek, orang, tempat, kejadian atau konsep yang informasinya akan disimpan di database. Misal. Pada sistem database akademik, yang menjadi entity adalah, mahasiswa, dosen, matakuliah dan lain-lain. Dalam aplikasi nantinya, penggunaan istilah Entity sering di samakan dengan istilah Tabel. (Entity = table). Disebut tabel, karena dalam merepresentasikan datanya di atur dalam bentuk baris dan kolom. Baris mewakili 1 record dan kolom mewakili 1 field. Dalam sistem database tradisional, entity/table ini disebut juga dengan file.
• Database
Kumpulan dari tabel-tabel yang saling berelasi, disusun secara logis, sehingga menghasilkan informasi yang bernilai guna dalam proses pengambilan keputusan.
Ada beberapa sifat yang melekat pada suatu tabel :
• Tidak boleh ada record yang sama (kembar)
• Urutan record tidak terlalu penting, karena data dalam record dapat diurut sesuai dengan kebutuhan.
• Setiap field harus mepunyai nama yang unik (tidak boleh ada yang sama).
• Setiap field mesti mempunyai tipe data dan karakteristik tertentu
Contoh produk DBMS terkenal yang menggunakan model relasional antara lain adalah :
1. DB2 (IBM)
2. Rdb/VMS (Digital Equipment Corporation)
3. Oracle (Oracle Corporation)
4. Informix (Informix Corporation)
5. Ingres (ASK Group Inc)
6. Sybase (Sybase Inc)
Di lingkungan PC, produk-produk berbasis relasional yang cukup terkenal antara lain adalah :
1. Keluarga R:Base (Microrim Corp) antara lain berupa R:Base 5000
2. Keluarga dBase (Ashton-Tate, sekarang bagian dari Borland International), antara lain dbase III Plus, dBase IV, serta Visual dBase
3. Microsoft SQL ( Microsoft Corporation)
4. Visual FoxPro (Microsoft Corporation)
MACAM-MACAM PERINTAH DATA BASE
1. Bahasa Definisi Data (Data Definition Language/ DDL)
DDL adalah perintah-perintah yang biasa digunakan oleh administrator basis data (DBA) utnuk mendefinisikan skema ke DBMS. Skema adalah deskripsi lengkap tentang struktur medan, rekaman, dan hubungan data pada basis data
Index merupakan suatu mekanisme yang lazim digunakan pada basis data, yang memungkinkan pengambilan data dapat dilakukan dengan cepat.
DDL Digunakan untuk mespesifikasikan struktur/skema basis data yang menggambarkan/mewakili desain basis data secara keseluruhan.
Hasil kompilasi perintah DDL adalah kamus data (File yang berisi metadata (data yang mendeskripsikan data sesungguhnya).
Struktur penyimpan dan metode akses yang digunakan oleh sistem basis data disebut dengan data storage and definition language.
2. Bahasa Manipulasi Data (Data Manipulation laguage/ DML)
DML adalah perintah-perintah yang digunakan untuk mengubah, manipulasi dan mengambil data pada basis data. Tindakan seperti menghapus, mengubah, dan mengambil data menjadi bagian dari DML.
DML pada dasarnya dibagi menjadi dua :
- Prosedural, yang menuntut pengguna menentukan data apa saja yang diperlukan dan bagaimana cara mendapatkannya.
- Nonprosedural, yang menuntut pengguna menentukan data apa saja yang diperlukan, tetapi tidak perlu menyebutkan cara mendapatkannya.
3. DQL ( Data Query Language)
Query sesungguhnya berarti pertanyaan atau permintaan. Istilah ini tetap dipertahankan dalam bentuk asli, karena telah populer di kalangan pengguna DBMS di Indonesia
B. Model Entity-Relationship (ER)
Model Entity-Relationship adalah model data konseptual tingkat tinggi untuk perancangan basis data. Model data konseptual adalah himpunan konsep yang mendeskripsikan struktur basis data, transaksi pengambilan dan pembaruan basis data.
Model ER adalah data konseptual tak tergantung DBMS dan platform perangkat keras tertentu. Model ER dikemukakan oleh Chen [1976]. Sejak itu, telah memperoleh banyak perhatian dan perluasan.
Model ER adalah persepsi terhadap dunia nyata sebagai terdiri objek-objek dasar yang disebut entitas dan keterhubungan (relationship) antar entitas-entitas itu.
Konsep paling dasar di model ER adalah entitas, relationship dan atribut.
Komponen-komponen utama model ER adalah:
a. Entitas (entity), Entitas memodelkan objek-objek yang berada diperusahaan/lingkungan.
b. Relationship. Relationship memodelkan koneksi/hubungan di antara entitas-entitas.
c. Atribut-atribut (properi-properti), memodelkan properti-properti dari entitas dan relationship.
d. Konstrain-konstrain (batasan-batasan) integritas, konstrain-konstrain ketentuan validitas.
Entitas (Entity) dan Himpunan Entitas (Entitas Sets)
Entitas merupakan individu yang mewakili sesuatu yang nyata (eksistensinya) dan dapat dibedakan dari sesuatu yang lain. Sebuah kursi yang kita duduki, seseorang yang menjadi pegawai di sebuah perusahaan dan sebuah mobil yang melintas di depan kita adalah entitas.
Sekelompok entitas yang sejenis dan berada dalam lingkup yang sama membentuk sebuah himpunan entitas (entity sets). Sederhananya, entitas menunjuk pada individu suatu objek, sedang himpunan entitas menunjuk pada rumpun (family) dari individu tersebut.
Seorang pasien, misalnya akan dimasukkan dalam himpunan entitas pasien. Sedang seorang dokter akan ditempatkan dalam himpunan entitas dokter.
Dalam berbagai pembahasan/literature, penyebutan himpunan entitas (yang kurang praktis) ini seringkali digantikan dengan sebutan entitas saja.
Karena itu sering ditemui, penggunaan istilah entitas (entity) di sebuah literature sebenarnya menunjuk pada himpunan entitas.
Kunci Entitas
Sebagaimana model relasional, adalah penting dan berguna untuk memasukkan kunci yang diasosiasikan dengan himpunan entitas. Kunci pada himpunan entitas S, adalah himpunan atribut A. Sehingga tidak ada dua entitas di S yang mempunyai nilai sama untuk tiap atribut di A dan tidak ada subset di A yang dapat menjadi kunci di S, dengan demikian kunci mempunyai property minimal.
Atribut (Atributes/Properties)
Setiap entitas pasti memiliki atribut yang mendeskripsikan karakteristik (property) dari entitas tersebut.
Penentuan / pemilihan atribut-atribut yang relevan bagi sebuah entitas merupakan hal penting lainnya dalam pembentukan model ER. Contoh : nim, nama, alamat, kode.
Relasi (Relationship) dan Himpunan Relasi (Relationship Sets)
Relasi menunjukkan adanya hubungan di antara sejumlah entitas yang berasal dari himpunan entitas yang berbeda.
Misalnya, entitas seorang mahasiwa dengan
nim = ‘980001’ dan
nama_mhs = ‘Ali Akbar’ (yang ada di himpunan entitas Mahasiswa)
mempunyai relasi dengan entitas sebuah mata kuliah dengan
kode_kul=’IF-110’ dan
nama_kul=’Struktur Data’.
Relasi diantara kedua entitas tadi mengandung arti bahwa mahasiswa tersebut sedang mengambil/mempelajari mata kuliah tersebut di sebuah perguruan tinggi yang ditinjau.
Kumpulan semua relasi diantara entitas-entitas yang terdapat pada himpunan entitas-himpuan entitas tersebut membentuk himpunan relasi (relationship sets).
Sebagaimana istilah himpunan entitas yang banyak sekali disingkat menjadi entitas, istilah himpunan relasi jarang sekali digunakan dan lebih sering disingkat dengan istilah relasi saja.
Kardinalitas/derajat Relasi
Kardinalitas Relasi menunjukkan jumlah maksimum entitas yang dapat berelasi dengan entitas pada himpunan entitas yang lain. Kardinalitas relasi merujuk kepada hubungan maksimum yang terjadi dari himpunan entitas yang satu ke himpunan entitas yang lain dan begitu juga sebaliknya.
Kardinalitas di antara dua himpunan entitas (misalnya A dan B) dapat berupa :
a. Satu ke satu (One to One),
setiap entitas pada himpunan entitas A berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas begitu juga sebaliknya setiap entitas pada himpunan entitas B berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas A.
b. Satu ke Banyak (one to many),
setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B,
tetapi tidak sebaliknya, dimana setiap entitas pada himpunan entitas B berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas A.
c. Banyak ke Satu (Many to One),
setiap entitas pada himpunan entitas A berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas B, tetapi tidak sebaliknya, dimana setiap entitas pada himpunan entitas A berhubungan dengan paling banyak satu entitas pada himpunan entitas B.
d. Banyak ke Banyak (Many to Many)
setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B,
demikian juga sebaliknya, di mana setiap entitas pada himpunan entitas B dapat berhubungan dengan banyak entitas pada himpunan entitas A.
Diagram Entity-Relationship (ER)
Penggambaran Model ER secara sistematis dilakukan melalui diagram ER. Notasi-notasi simbolik di dalam Diagram ER yang dapat digunakan adalah:
1. Persegi panjang, menyatakan Himpunan Entitas.
2. Lingkaran/Elips, menyatakan atribut (Atribut yang berfungsi sebagai key digaris bawahi).
3. Belah ketupat, menyatakan Himpunan Relasi.
4. Garis, sebagai penghubung antara Himpunan Relasi dengan Himpunan Entitas dan Himpunan Entitas dengan atributnya.
5. Kardinalitas Relasi dapat dinyatakan dengan banyaknya garis cabang atau dengan pemakaian angka (1 dan 1 untuk relasi one to one, 1 dan N untuk relasi one to many atau N dan N untuk relasi many to many).
Contoh diagram ER :
Tahap Pembuatan Diagram ER
Diagram ER selalu dibuat secara bertahap. Paling tidak ada dua kelompok penahapan yang biasa ditempuh di dalam pembuatan diagram ER, yaitu :
a. Tahap pembuatan Diagram ER awal (preliminary design). Yaitu :
- Mengidentifikasi dan menetapkan seluruh entity yang terlibat dalam sistem database tersebut.
- Menentukan attribute-attribute atau field dari masing-masing entity beserta kunci (key)-nya.
Menentukan attribute dari suatu entitas sangat menentukan baik atau tidaknya sistem database yang dirancang, karena attribute ini sangat menentukan nantinya dalam proses relasi. Attribute merupakan ciri khas yang melekat pada suatu entity, misalnya attribute pada mahasiswa dapat berupa nobp, nama, tempat lahir, tanggal lahir, alamat, nama orang tua, pekerjaan orang tua dan lain-lain. Dari sekian banyak kemungkinan attribute yang ada pada entity mahasiswa, kita dapat menggunakan hanya yang perlu saja. Setelah menentukan attributenya selanjutnya adalah menentukan field kunci. Field kunci adalah penanda attribute tersebut sehingga bisa digunakan untuk relasi nantinya dan field kunci ini harus bersifat unik. Misalnya pada entity mahasiswa, attribute nobp bisa dijadikan field kunci, karena bersifat unik dan tidak ada mahasiswa yang mempunyai nobp sama.
- Mengidentifkasi dan menetapkan seluruh himpunan relasi diantara himpunan-himpunan entity yang ada beserta kunci tamu (foreign key)- nya.
Setelah menentukan entity dan attribute beserta field kuncinya, maka selanjutnya adalah menentukan entity yang terbentuk akibat adanya relasi antar entity. Misalnya antara entity mahasiswa dengan entity dosen, terjadi suatu hubungan proses mengajar, maka proses mengajar ini merupakan entity baru. Entity mengajar ini harus kita tentukan juga attribute yang melekat padanya beserta kunci tamu (foreign key). Kunci tamu adalah field kunci utama pada tabel lain, dan field tersebut digunakan juga pada tabel yang satu lagi. Misalnya nobp adalah
field kunci dari entity mahasiswa, pada entity mengajar terdapat juga attribute NoBP, maka keberadaan attribute nobp pada entity mengajar disebut sebagai kunci tamu. Proses menentukan hubungan antar entity juga sangat menentukan kualitas system database yang dirancang.
- Menentukan derajat relasi untuk setiap himpunan relasi.
Setelah semua entity dan attribute yang dibutuhkan terbentuk, maka selanjutnya adalah menentukan derajat relasi antar entity tersebut, apakah satu kesatu, satu ke banyak atau sebaliknya, atau banyak ke banyak. Berhati-hatilah dalam menentukan derajat relasi ini, karena nantinya akan berhubungan dengan proses query terhadap data
- Melengkapi himpunan entitas dan himpunan relasi dengan atribut-atribut deskriptif (non key).
Jenis-Jenis Kunci (Key)
• Candidat Key
Sebuah attribute atau lebih yang secara unit mengidentifikasi sebuat record, disebut candidate key. Attribute ini mempunyai nilai yang unik pada hampir setiap recordnya. Fungsi dari candidate key ini adalah sebagai calon primary key.
Contoh candidate-key :
|
Candidate Key |
 |
|||
 |
|||
|
ID_Cus |
Name |
NoOfPay |
Amount |
|
112233 |
Tim |
890 |
9000 |
|
112231 |
Kate |
891 |
8000 |
|
112241 |
Tyson |
895 |
10000 |
• Primary Key
Salah satu atrribut dari candidat key dapat dipilih menjadi primary key dengan 3 kriteria sbb :
§ Key tersebut lebih natural untuk dijadikan acuan
§ Key tersebut lebih sederhana
§ Key tersebut cukup uniqe
• Foreign Key
Jika sebuah primary key terhubungan ke table/entity lain, maka keberadaan primary key pada entity tersebut di sebut sebagai foreign key. Misal : Primary Key KodeDosen dari entity Dosen digunakan juga pada field entity KRS, maka keberadaan field KodeDosen pada entity KRS disebut sebagai foreign key.
• Alternate Key
Setiap atribut dari candidate key yang tidak terpilih sebagai primary key akan dinamakan alternate key. Pada contoh sebelumnya bila untuk primary key dipilih ID_Cus maka alternate key nya adalah No.of Pay
.
|
Primary Key |
|
Foreign Key |
 |
 |
||
|
KODE |
MK |
SKS |
KD-Dosen |
|
TEL 100 |
Fisika |
3 |
D-101 |
|
TEL 200 |
Isyarat |
2 |
D-109 |
|
TEL 210 |
T.Kendali |
2 |
D-101 |
|
KD-Dosen |
Nama_Dosen |
|
D-100 |
Badu,S.T |
|
D-101 |
Ir.Thomas |
|
D-109 |
Harry,S.T,M.T |
|
b. Tahap optimasi Diagram ER (final design).
C. Normalisasi
Proses normalisasi adalah proses untuk memperoleh properti-properti skema relasi yang bagus menjadi bentuk normal lebih tinggi sehingga syarat-syarat dibawah ini terpenuhi:
a. Mengoptimalisasi redudansi (pengulangan data yang tidak perlu). Redudansi tidak bisa dihilangkan sama sekali karena berguna untuk integritas referensial, tetapi redudansi bisa dioptimalisasi. Untuk jumlah data yang tidak terlalu banyak mungkin tidak terlalu berpengaruh dalam hal penggunaan harddisk. Tapi bayangkan jika ada ribuan, bahkan jutaan redudansi, mungkin akan sangat berpengaruh pada penggunaan ruang.
b. Menghilangkan anomali. Anomali pada dasarnya adalah ketidak-konsistenan (inkonsistensi). Misalkan ada pergantian nama dari Bank Perkasa menjadi Bank Perkasa Utama sebanyak 4 record. Jika pergantian nama hanya dilakukan pada salah satu record saja, maka terjadi ketidak-konsistenan yaitu satu nomor bank berrelasi dengan 2 nama bank yang berbeda.
Dekomposisi tabel dapat mengurangi redudansi yang ada dan menghilangkan anomali.
Perancangan melalui proses normalisasi mempunyai keuntungan-keuntungan sebagai berikut :
a. Meminimalkan ukuran penyimpanan yang diperlukan untuk penyimpanan data.
b. Meminimalkan resiko inkonsistensi data pada basis data.
c. Meminimalkan kemungkinan anomaly pembaruan.
d. Memaksimalkan stabilitas struktur data.
Bentuk Normal
Tujuan proses normalisasi adalah mengkonversi relasi menjadi bentuk normal lebih tinggi. Terdapat beragam tingkat bentuk normal, yaitu :
a. Bentuk normal pertama (1NF)
b. Bentuk normal kedua (2NF)
c. Bentuk normal ketiga (3NF)
d. Bentuk normal Boyce-Codd (BCNF)
e. Bentuk normal keempat (4NF)
f. Bentuk normal kelima (5NF)
Codd mendefinisikan bentuk normal pertama, kedua dan ketiga di makalah (Codd, 1970). Bentuk normal ketiga kemudian diperbaiki sehingga mempunyai bentuk normal yang lebih kuat yaitu BCNF (Codd, 1974). Fagin memperkenalkan bentuk normal keempat (Fagin, 1977), kemudian Fagin juga memperkenalkan bentuk normal kelima (Fagin, 1979).
Bentuk normal pertama untuk menghilangkan atribut bernilai jamak. Bentuk normal kedua untuk menghilangkan kebergantungan parsial. Bentuk normal ketiga untuk menghilangkan kebergantungan transitif. Bentuk normal Boyce-Codd untuk menghilangkan anomaly tersisa disebabkan kebergantungan fungsional. Bentuk normal keempat untuk menghilangkan kebergantungan nilai jamak. Bentuk normal kelima untuk menghilangkan anomaly tersisa.
Tiga bentuk normal pertama berkaitan dengan kebergantungan fungsional. Sementara itu bentuk keempat dan kelima berkaitan dengan redudansi yang disebabkan kebergantungan banyak nilai (multi-valued dependencies).
Bentuk Normal Pertama
Bentuk normal pertama adalah ekivalen dengan definisi model relasional. Relasi adalah bentuk normal pertama (1NF) jika semua nilai atributnya adalah sederhana (bukan komposit).
Syarat :
o Tidak ada set atribut yang berulang atau bernilai ganda.
o Telah ditentukannya primary key untuk tabel atau relasi.
o Tiap atribut hanya memiliki satu pengertian.
o Tiap atribut yang dapat memiiki banyak nilai sebenarnya menggambarkan entitas atau relasi yang terpisah.
Bentuk Normal Kedua
Syarat :
o Bentuk data telah memenuhi kriteria bentuk normal ke satu.
o Atribut bukan kunci(non-key attribute) haruslah memiliki ketergantungan fungsional sepenuhnya pada primary key
Relasi pada bentuk normal kedua harus tidak menyimpan fakta-fakta mengenai bagian kunci relasi. Bentuk normal kedua menghilangkan kebergantungan parsial dan masih memiliki anomali-anomali yang secara praktis tidak dapat diterima.
Bentuk Normal Ketiga
Syarat :
o Bentuk data telah memenuhi kriteria bentuk normal ke dua.
o Atribut bukan kunci(non-key attribute) tidak boleh memiliki ketergantungan fungsional terhadap atribut bukan kunci lainnya. Seluruh atribut bukan kunci pada suatu relasi hanya memiliki ketergantungan fungsional terhadap primary key di relasi itu saja.
Bentuk normal ketiga menghilangkan kebergantungan transitif, awalnya bentuk normal ketiga dipikir sebagai bentuk normal puncak/paling akhir. Namun kemudian dapat ditemukan bentuk normal lebih kuat yaitu bentuk normal Boyce-Codd.
Bentuk Normal Boyce-Codd (BCNF)
BCNF memiliki ketentuan yaitu masing-masing atribut utama bergantung fungsional penuh pada masing-masing kunci dimana kunci tersebut bukan bagiannya. Relasi adalah BCNF (optimal) jika setiap determinan atribut-atribut relasi adalah kunci relasi. Relasi adalah BCNF (optimal) jika kapanpun fakta-fakta disimpan mengenai beberapa atribut, maka atribut-atribut ini merupakan satu kunci relasi. BCNF dapat memiliki lebih dari satu kunci. Properti penting BCNF adalah relasi tidak memiliki informasi yang redundan.
Bentuk Normal Keempat
Relasi dalam bentuk normal keempat (4NF) jika relasi dalam BCNF dan tidak berisi kebergantungan banyak nilai. Untuk menghilangkan kebergantungan banyak nilai dari satu relasi, kita membagi relasi menjadi dua relasi baru. Masing – masing relasi berisi dua atribut yang mempunyai hubungan banyak nilai.
Bentuk Normal Kelima
Bentuk normal kelima (5NF) berurusan dengan properti yang disebut join tanpa adanya kehilangan informasi (lossless join). Bentuk normal kelima (5NF) juga disebut PJNF (projection-join normal form). Kasus-kasus ini sangat jarang muncul dan sulit untuk dideteksi secara praktis.
Contoh Normalisasi pada beberapa tingkatan.
Diberikan tabel Mahasiswa di bawah ini, akan dilakukan normalisasi sampai bentuk normal ke tiga
Perhatikan bahwa tabel di atas sudah dalam bentuk normal ke Satu(1NF).
|
Bentuk Normal 2 ( NF2 )
|
|
||||
 |
||||
Bentuk Normal 3 NF3
Perancangan DataBase
Perancangan Database
Di dalam suatu organisasi yang besar, sistem database merupakan bagian penting pada sistem informasi, karena di perlukan untuk mengelola sumber informasi pada organisasi tersebut. Untuk mengelola sumber informasi tersebut yang pertama kali di lakukan adalah merancang suatu sistem database agar informasi yang ada pada organisasi tersebut dapat digunakan secara maksimal.
Tujuan Perancangan Database
· Untuk memenuhi kebutuhan akan informasi dari pengguna dan aplikasi
· Menyediakan struktur informasi yang natural dan mudah di mengerti oleh pengguna
· Mendukung kebutuhan pemrosesan dan beberapa obyek kinerja dari suatu sistem database
Berikut ini siklus kehidupan sistem informasi di mana terdapat siklus kehidupan sistem database.
Siklus Kehidupan Sistem Informasi (Macro Life Cycle )
Tahapan–tahapan yang ada pada siklus kehidupan sistem informasi yaitu :
1. Analisa Kelayakan
Tahapan ini memfokuskan pada penganalisaan areal aplikasi yang unggul , mengidentifikasi pengumpulan informasi dan penyebarannya, mempelajari keuntungan dan kerugian , penentuan kompleksitas data dan proses, dan menentukan prioritas aplikasi yang akan digunakan.
2. Analisa dan Pengumpulan Kebutuhan Pengguna
Kebutuhan–kebutuhan yang detail dikumpulkan dengan berinteraksi pada sekelompok pemakai atau pemakai individu. Mengidentifikasikan masalah yang ada dan kebutuhan-butuhan, ketergantungan antar aplikasi, komunikasi dan prosedur laporan.
3. Perancangan
Perancangan terbagi menjadi dua yaitu : perancangan sistem database dan sistem aplikasi
4. Implementasi
Mengimplementasikan sistem informasi dengan database yang ada
5. Pengujian dan Validasi
Pengujian dan validasi sistem database dengan kriteria kinerja yang diinginkan oleh pengguna.
6. Pengoperasian dan Perawatan
Pengoperasian sistem setelah di validasi disertai dengan pengawasan dan perawatan sistem
Siklus Keh idupan Aplikasi Database ( Micro Life Cycle )
Tahapan yang ada pada siklus kehidupan aplikasi database yaitu :
1. Pendefinisian Sistem
Pendefinisian ruang lingkup dari sistem database, pengguna dan aplikasinya.
2. Perancangan Database
Perancangan database secara logika dan fisik pada suatu sistem database sesuai dengan sistem manajemen database yang diinginkan.
3. Implementasi Database
Pendefinisian database secara konseptual, eksternal dan internal, pembuatan file–file database yang kosong serta implementasi aplikasi software.
4. Pengambilan dan Konversi Data
Database ditempatkan dengan baik, sehingga jika ingin memanggil data secara langsung ataupun merubah file–file yang ada dapat di tempatkan kembali sesuai dengan format sistem databasenya.
5. Konversi Aplikasi
Software-software aplikasi dari sistem database sebelumnya di konversikan ke dalam sistem database yang baru
6. Pengujian dan Validasi
Sistem yang baru telah di test dan di uji kinerja nya
7. Pengoperasian
Pengoperasian database sistem dan aplikasinya
8. Pengawasan dan Pemeliharaan
Pengawasan dan pemeliharaan sistem database dan aplikasi software
Proses Perancangan Database
Ada 6 tahap untuk proses perancangan suatu database :
1. Pengumpulan data dan analisis
2. Perancangan database secara konseptual
3. Pemilihan sistem manajemen database
4. Perancangan database secara logika
5. Perancangan database secara fisik
6. Implementasi sistem database
Struktur dan Aplikasi
Isi Data Database
Tahap 1 |
Analisis dan Pengumpulan kebutuhan pengguna |
Pengumpulan data |
Pengumpulan Pemrosesan |
Tahap 2 |
Perancangan Konseptual |
Perancangan Konseptual skema |
Perancangan Transaksi dan Aplikasi
|
Tahap 3 |
Pemilihan Sistem Manajemen Database |
Tahap 4 |
Perancangan Logik |
Perancangan Konseptual dan Eksternal skema |
Seberapa Batasan Kinerjanya |
Tahap 5 |
Perancangan Fisik |
Skema internal |
Tahap 6 |
Implementasi |
Perintah DDL Perintah SDL |
Implementasi transaksinya |
|
Keterangan :
Secara khusus proses perancangan berisikan 2 aktifitas paralel. Aktifitas yang pertama melibatkan perancangan dari isi data dan struktur database, sedangkan aktifitas kedua mengenai perancangan pemrosesan database dan aplikasi–aplikasi perangkat lunak.
Dua aktifitas ini saling berkaitan , misalnya mengidentifikasi data item yang akan disimpan dalam database dengan cara menganalisa aplikasi–aplikasi database. Dua aktifitas ini juga saling mempengaruhi satu sama lain. Contohnya tahap perancangan database secara fisik, pada saat memilih struktur penyimpanan dan jalur akses dari file suatu database dimana bergantung dengan aplikasi–aplikasi yang akan menggunakan file tersebut.
Penentuan perancangan aplikasi–aplikasi database yang mengarah ke konstruksi skema database telah ditentukan selama aktifitas pertama.
Ke-enam tahap yang telah disebutkan sebelumnya dapat di proses secara tidak berurutan . Dalam beberapa hal, dapat dilakukan modifikasi perancangan kembali ke tahap yang pertama (feedback loop) setelah melakukan tahap selanjutnya.
Tahap 1 : Pengumpulan data dan analisis
Sebelum merancang suatu database, yang harus dilakukan adalah mengetahui dan menganalisis apa yang diinginkan dari pengguna aplikasi, sehingga proses ini disebut pengumpulan data dan analisis. Untuk menspesifikasikan kebutuhan yang pertama kali dilakukan adalah mengidentifikasi bagian lain di dalam sistem informasi yang berinteraksi dengan sistem database. Termasuk pengguna yang baru atau yang sudah lama juga aplikasinya, kebutuhan–kebutuhan tersebut dikumpulkan dan di analisa.
Kegiatan pengumpulan data dan analisis :
· Menentukan kelompok pemakai dan areal bidang aplikasinya.
Pengguna yang menguasai aplikasi yang lama dari setiap bagian dipilih untuk menyampaikan kebutuhan-kebutuhan dan menspesifikasikannya.
· Peninjauan dokumentasi yang ada.
Dokumen yang berhubungan dengan aplikasi yang akan dibuat dipelajari dan dianalisa, sedangkan dokumen lainnya seprti kebijakan manual, form, laporan–laporan dan bagan-bagan organisasi diuji dan ditinjau kembali untuk mengetahui apakah dokumen tersebut berpengaruh terhadap pengumpulan data dan proses spesifikasi
· Analisa lingkungan operasi dan kebutuhan pemrosesan.
Lingkungan operasional yang sekarang dan informasi yang direncanakan akan di gunakan dipelajari, termasuk menganalisa jenis–jenis dari transaksi dan frekuensi transaksinya seperti halnya alur informasi dengan sistem. Input dan output data untuk transaksi tersebut harus diperinci.
· Pengumpulan respon terhadap daftar pertanyaan dan angket yang telah dibuat sebelumnya.
Pengumpulan respon dari angket dan daftar pertanyaan berisikan prioritas para pengguna dan penempatan mereka di dalam berbagai aplikasi. Ketua kelompok mungkin akan ditanya untuk membantu para pengguna dalam memberikan informasi yang penting dan menentukan prioritas.
Teknik yang digunakan dalam penspesifikasian kebutuhan secara formal :
· OOA ( Object Oriented Analysis )
· DFD ( Data Flow Diagram )
· HIPO ( Hierarchical Input Process Output )
· SADT ( Structured Analysis & Design )
Tahap 2 : Perancangan database secara konseptual
Tujuan dari tahap ini adalah untuk menghasilkan skema konseptual untuk databse yang tidak tergantung pada sistem manajemen database yang spesifik. Penggunaan model data tingkat tinggi seperti ER/EER sering digunakan didalam tahap ini. Di dalam skema konseptual dilakukan perincian aplikasi–aplikasi database dan transaksi–transaksi yang diketahui .
Ada dua kegiatan di dalam perancangan database secara konseptual :
· Perancangan skema konseptual :
Pada tahap ini kegiatan yang dilakukan mengecek tentang kebutuhan– kebutuhan pemakai terhadap data yang dihasilkan dari tahap 1, dimana
tujuan dari proses perancangan skema konseptual adalah menyatukan pemahaman dalam struktur database, pengertian semantik, keterhubungan dan batasan-batasannya, dengan membuat sebuah skema database konseptual dengan menggunakan model data ER/EER tanpa tergantung dengan sistem manajemen database
Ada dua pendekatan perancangan skema konseptual :
· Terpusat
Kebutuhan–kebutuhan dari aplikasi atau kelompok–kelompok pemakai yang berbeda digabungkan menjadi satu set kebutuhan pemakai kemudian dirancang menjadi satu skema konseptual.
· Integrasi view–view yang ada
Untuk masing–masing aplikasi atau kelompok–kelompok pemakai yang berbeda dirancang sebuah skema eksternal ( view ) kemudian view – view tersebut disatukan ke dalam sebuah skema konseptual.
Ada 4 strategi dalam perancangan skema konseptual :
¨ Top down
¨ Bottom Up
¨ Inside Out
¨ Mixed
· Transaksi
Merancangan karakteristik dari transaksi–transaksi yang akan di implementasikan tanpa tergantung dengan DBMS yang telah dipilih. Transaksi–transaksi ini digunakan untuk memanipulasi database sewaktu diimplementasikan . Pada tahap ini diidentifikasikan input, output dan fungsional . Transaksi ini antara lain : retrieval, update dan delete, select dll.
Tahap 3 : Pemilihan Sistem Manajemen Database
Pemilihan sistem manajemen database ditentukan oleh beberapa faktor a.l : Teknik, Ekonomi, dan Politik Organisasi
Faktor Teknik :
· Tipe model data ( hirarki, jaringan atau relasional )
· Struktur penyimpanan dan jalur pengaksesan yang didukung sistem manajemen database
· Tipe interface dan programmer
· Tipe bahasa queri
Faktor Ekonomi :
· Biaya penyiadaan hardware dan software
· Biaya konversi pembuatan database
· Biaya personalia
· Biaya pelatihan
· Biaya pengoperasian
· Biaya pemeliharaan
Faktor Organisasi :
· Struktur data
Jika data yang disimpan dalam database mengikuti struktur hirarki, maka suatu jenis hirarki dari sistem manajemen database harus dipikirkan.
· Personal yang terbiasa dengan sistem yang terdahulu
Jika staff programmer dalam suatu organisasi sudah terbiasa dengan sautu sistem manajemen database maka hal ini dapat mengurangi biaya latihan dan waktu belajar.
· Ketersediaan dari service vendor
Keberadaan fasilitas pelayanan penjual sangat dibutuhkan untuk membantu memecahkan masalah sistem.
Tahap 4 : Perancangan database secara logika ( Transformasi model data )
Transformasi dari skema konseptual dan eksternal ( Tahap 2 ) ke model data sistem manajemen database yang terpilih, ada dua proses yaitu :
· Transformasi yang tidak tergantung pada sistem, pada tahap ini transformasi tidak mempertimbangkan karakteristik yang spesifik atau hal– hal khusus yang akan diaplikasikan pada sistem manajemen database
· Penyesuaian skema ke sistem manajemen database yang spesifik, di lakukan suatu penyesuaian skema yang dihasilkan dari tahap 1 untuk dikonfirmasikan pada bentuk implementasi yang spesifik dari suatu model data seperti yang digunakan oleh sistem manajemen database yang terpilih
Hasil dari tahap ini dituliskan dengan perintah DDL ke dalam bahasa sistem manajemen database terpilih. Tapi jika perintah DDL tersebut termasuk dalam parameter–parameter perancangan fisik , maka perintah DDL yang lengkap harus menunggu sampai tahap perancangan database secara fisik telah lengkap.
Tahap 5 : Perancangan Database Secara Fisik
Proses pemilihan struktur penyimpanan yang spesifik dan pengaksesan file– file database untuk mencapai kinerja yang terbaik di bermacam–macam aplikasi
Kriteria pemilihan perancangan fisik :
· Waktu respon
Waktu transaksi database selama eksekusi untuk menerima respon
· Penggunaan ruang penyimpanan
Jumlah ruang penyimpanan yang digunakan oleh database file dan struktur jalur pengaksesannya
· Terobosan yang dilakukan file transaksi
(Transaction troughput )
Merupakan nilai rata–rata transaksi yang dapat di proses permenit oleh sistem database dan merupakan parameter kritis dari sistem transaksi
Apabila waktu respon dari database tidak mencapai optimalisasi, maka pada tahap perancangan fisik ini dapat dilakukan denormalisasi.
Denormalisasi
Denormalisasi merupakan proses yang dilakukan pada database yang sudah dinormalisasi, dengan cara memodifikasi struktur tabel dan mengabaikan kerangkapan data (yang terkontrol) untuk meningkatkan kinerja database.
Proses denormalisasi termasuk :
§ Mengkombinasikan tabel-tabel yang terpisah dengan join
§ Mereplikasi/menduplikat data pada tabel
Tahap 6 : Implementasi
Implementasi skema database logik dan fisik ke dalam penyataan DDL dan SDL dari sistem manajemen database yang telah dipilih, untuk digunakan dalam pembuatan file–file database yang masih kosong
Studi Kasus :
Di bawah ini deskripsi mengenai suatu perusahaan yang akan di representasikan dalam database dan buat sesuai dengan proses perancangan database dari tahap 1 s/d tahap 4.
1. Suatu perusahaan terdiri atas bagian–bagian, masing–masing bagian mempunyai nama, nomor bagian dan lokasi . Setiap bagian mempunyai seorang pegawai yang mempunyai seorang pimpinan yang memimpin bagian tersebut.
2. Setiap bagian mengontrol sejumlah proyek dimana masing–masing proyek mempunyai nama, nomor proyek dan lokasi .
3. Setiap pegawai menjadi anggota pada salah satu bagian tapi dapat bekerja di beberapa proyek . Untuk setiap pegawai yang bekerja di proyek mempunyai jam kerja per-minggu . Seorang pegawai mempunyai nama, nomor pegawai, alamat, jenis kelamin, tanggal lahir dan usia serta supervisor / penyelia langsung. Pegawai juga mempunyai tanggungan yang terdiri atas nama, jenis kelamin dan hubungannya dengan si pegawai.
Catatan = Kasus diambil dari contoh Diagram ER pada materi Model Entity Relationship (Sistem Basis Data 1/Pengantar Sistem Basis Data)
**************
|
||||
|
||||
Hello world!
Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!
