Fanyirmawati's Weblog

normalisasi

fanyirmawati — Sat, 10 Jan 2009 06:19:26 +0000

PERINTAH KERJA BENGKEL No2031

Nama : Ahmad R No. Polisi : D5377WG Diterima Selesai

Alamat : Bakung 3 No. 22 No. Mesin : Tgl :11/09/2008 ……….

Telp : No. Rangka : Jam : 08:17:21 ……….

Tipe : C 100 M7 5X125 Tahun/Warna: 2006/Black KM : 12586

PERINTAH KERJA : : PERBAIKAN YANG LALU

*# Tune Up/QS # 25000 : No. PKB Tgl. PKB KM Mekanik Operasi

*#Oli Mesin Federal# 25000 :

*#Baud Setelan Klep 7500 :

*Baud Cover 3000 :

Jumlah 60500 :

Lama Pengerjaan :………………………….. Mekanik : Juli

Semua Pekerjaan & pengggantian suku cadang yang tertulis pada perintah kerja ini telah disetujui oleh pemilik/pemakai kendaraan termasuk test kendaraan ditempat maupun berjalan.

Kami tidak bertanggung jawab atas kehilangan/kerusakan yang disebabkan oleh bencana alam dan huru-hara beserta akibat-akibatnya dan hal-hal lain yang bersifat foroe majeure.

Apabila dalam waktu 1 (satu) bulan setelah kendaraan selesai diperbaiki tidak/belum diambil :

a. Kami tidak bertanggung jawab atas resiko kehilangan/kerusakan perlengkapan kendaraan, dll.

b. Kami kenakan biaya tambahan sebesar Rp. 2500,- (dua ribu lima ratus rupiah) perhari.

Mengetahui Menyetujui

( ) ( Ahmad R )

WorkShop Supervisor Pemilik

a. Dekomposisi

No. Faktur

Nama

Alamat

Telp

Tipe

No. Polisi

No.Mesin

No. Rangka

Tahun/warna

Tanggal

Jam

Perintah Kerja

No. PKB

Tgl. PKB

Mekanik

Operasi

b. Un Normal

No. Faktur

Nama

Alamat

Telp

Tipe

No. Polisi

No. Mesin

No. Rangka

Tahun/

warna

Tgl

Jam

Perintah Kerja1

Perintah kerja2

Perintah kerja3

Perintah kerja4

2031

Ahmad R

Bakung No.22

C 100 M7

2006 / Black

11/09/08

08:17:21

12586

Tune Up/QS

Oli Mesin Federal

Baud Setelan Klep

Baud Cover

Transaksi

No. Transaksi

Tgl

No. Perintah Kerja

No.Faktur

c. 1-NF

Faktur

No. Faktur

Nama

No.Pemilik

Alamat

Telp

Tipe

No. Polisi

No.Rangka

Tahun/warna

Kode Petugas

Perintah Kerja

No. Perintah Kerja

Nama Perintah Kerja

Harga

Petugas

Kode Petugas

Nama Petugas

d. 2-NF

Perintah Kerja

No. Perintah Kerja

Nama Perintah Kerja

Harga

Transaksi

No. Transaksi

Tgl

No. Perintah Kerja

No.Faktur

Faktur

No. Faktur

Nama

No.Pemilik

Alamat

Telp

Tipe

No. Polisi

No.Rangka

Tahun/warna

Kode Petugas

Petugas

Kode Petugas

Nama Petugas

Pemilik

No Pemilik

Nama Pemilik

Alamat

QUERY

· Untuk Menampilkan semua data perintah kerja

SELECT * FROM Perintah Kerja

· Untuk menampilkan semua data pemilik kendaraan

SELECT * FROM Pemilik Kendaraan

Model dan Studi Kasus Database

fanyirmawati — Thu, 09 Oct 2008 09:14:49 +0000

PENGARUH DESAIN TERHADAP PENERAPAN EFEKTIFITAS

DATABASE MELALUI BEBERAPA CONTOH KASUS

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

Salah satu langkah dalam membangun suatu sistem informasi adalah melakukan perancangan

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

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

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

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

· maintain data secara akurat dan konsisten,

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

· database dapat memenuhi kebutuhan sesuai dengan pertumbuhan user dan

· database dapat memenuhi kebutuhan pembacaan data tanpa memperdulikan bagaimana data secara fisik tersimpan.

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

LOGICAL DATA MODEL

Logical data model merupakan pemodelan dari proses bisnis yang berfokus pada analisis data. Logical data model dibangun oleh tiga notasi yaitu entiti, atribut dan relasi. Entiti adalah tempat, obyek, kejadian maupun konsep pada lingkungan user dimana diperlukan maintain data pada organisasi tersebut. Atribut adalah karakteristik yang dimiliki tiap entiti. Relasi adalah hubungan asosiasi data antar entiti.

Beberapa hal yang perlu diperhatikan dalam pembuatan logical data model menurut Moss Larissa :

Memeriksa definisi, semantik dan tipe data pada tiap entiti untuk mencari duplikasi obyek bisniskarena dapat tidak terlihat apabila nama yang digunakan berbeda.
Memastikan tiap data pada entiti bahwa hanya memiliki satu pengenal yang unik (primary key), dimana termasuk apabila ada data lama yang dihapus dari database.
Menggunakan aturan normalisasi untuk memastikan bahwa sebuah atribut hanya dimiliki oleh satu entiti saja.
Mengadopsi aturan bisnis dengan obyek pada dunia nyata. Aturan bisnis ini memperlihatkan relasi data antar entiti.

Beberapa hal yang perlu diperhatikan dalam pembuatan logical data model menurut Elmasri Ramez :

Semantic atribut

Bagaimana menggambarkan relasi yang dapat menggambarkan fakta yang ada.

Memperkecil terjadinya data redundansi

Tujuan dalam pembuatan database adalah mengoptimalkan penyimpanan data.

Memperkecil terjadinya nilai null pada data

Null value dapat menyebabkan penyimpanan data yang besar dan dapat terjadi kesalahpahaman dalam mengartikan suatu atribut. Null value dapat diinterpretasikan sebagai :

(1) atribut ini tidak dimiliki oleh data tersebut,

(2) nilai atribut tidak diketahui dan

(3) nilai atribut diketahui tetapi belum dicatat.

Tiap entiti memiliki definisi/semantik yang jelas.

PENERAPAN LOGICAL DATA MODEL DALAM CONTOH KASUS

Contoh kasus 1

Gambar 1 menunjukkan relasi kepala departemen antara entiti Pegawai dengan Departemen adalah 1 : 1 yang berarti satu orang pegawai hanya dapat mengepalai satu departemen dan satu departemen hanya boleh dikepalai oleh satu orang pegawai. Dilihat dari kenyataan yang terjadi, relasi tersebut adalah benar karena tidak mungkin pada satu waktu, ada lebih dari satu pegawai yang mengepalai suatu departemen dan begitu pula sebaliknya.

Gambar 1. Relasi entiti Pegawai dan entitiDepartemen

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

Gambar 2. Penambahan entiti History Kepala Departemen

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

Gambar 3. Perubahan entiti History Jabatan

Moss poin (d) dan Elmasri poin (a) menyatakan bahwa pembuatan model harus disesuaikan dengan fakta. Contoh kasus 1 memperlihatkan bahwa dalam melakukan desain perlu memastikan data apa saja yang dibutuhkan baik sekarang maupun yang akan datang dapat tersedia. Pada gambar 1 terdapat permasalahan yaitu tidak menyediakan penyimpanan data masa lampau. Kemudian yang kedua adalah apakah database dapat memenuhi kebutuhan sesuai dengan pertumbuhan user sebagaimana yang digambarkan pada gambar 3 yaitu bahwa jenis jabatan dapat semakin beragam, oleh karena itu dibuat sebuah entiti tersendiri.

Contoh kasus 2

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

Gambar 4. Pengaksesan history jabatan

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

Gambar 5. Penambahan hak akses menu

Contoh kasus 2 memperlihatkan bahwa pemilihan database juga mempengaruhi desain database, antara lain adalah management user atau pemilihan tipe data, dimana tiap database menyediakan tipe data yang berbeda.

Contoh kasus 3

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

Gambar 6. Entiti Prestasi berleasi dengan entity Jabatan

Ternyata prestasi tidak sepenuhnya melekat pada prestasi, namun sebenarnya lebih tepat apabila entiti Prestasi direlasikan dengan entiti Pegawai. Untuk mengetahui prestasi seorang pegawai didapat pada saat pegawai tersebut menjabat menjadi apa, dapat dilakukan proses query. Contoh kasus 3 memperlihatkan bahwa ketika mengadopsi aturan bisnis dengan obyek pada dunia nyata harus dilakukan dengan cermat, sehingga relasi yang dibuat menjadi tepat (Moss poin (d) dan Elmasri poin (a) dan memastikan bahwa tiap definisi/semantik menempel pada data yang sesuai (Moss (a) dan Elmasri (d)).

Gambar 7. Entiti Prestasi berelasi dengan entity Pegawai

Contoh kasus 4

Normalisasi penting dilakukan untuk memastikan bahwa sebuah atribut hanya dimiliki oleh satu entiti saja sehingga maintain data dapat dilakukan secara akurat dan konsisten. Data yang tidak ternormalisasi juga menyebabkan lambatnya proses update. Setiap prestasi seorang pegawai dinilai oleh beberapa penilai. Jumlah penilai tergantung pada jabatan yang dimiliki oleh pegawai yang berprestasi tersebut. Dilihat dari gambar 8, ternyata terjadi redundansi data, dimana terjadi perulangan data atribut No Urut, Nama Prestasi dan Tanggal Prestasi tiap ada nilai dari seorang penilai.

Gambar 8. Redundansi data pada entiti Prestasi

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

Gambar 9. Pemisahan redundansi data pada entiti Penilaian Prestasi

Contoh kasus 4 memperlihatkan bahwa dalam melakukan desain perlu memperhatikan aturan normalisasi (Moss poin (c) dan Elmasri poin (b)), sehingga konsistensi data dapat terjamin. Proses update data akan menjadi lebih sulit apabila dilakukan pada desain database seperti gambar 8. Contoh data pada tabel Prestasi dari gambar 8 dapat dilihat pada tabel 1.

Tabel 1. Contoh data tabel Prestasi

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

Contoh kasus 5

Hal lain yang perlu diperhatikan adalah pemilihan atribut sebagai primary key (Moss poin (b)). Antara gambar 9 dengan gambar 10 terdapat perbedaan primary key untuk entiti Prestasi. Gambar 9 menghasilkan tabel Prestasi dengan primary key NIP pegawai dan No Urut. Sedangkan gambar 10 menghasilkan tabel prestasi dengan primary key Kode Prestasi. Pemilihan desain tergantung daripada desainer database. Apabila dicermati, Kode Prestasi pada tabel prestasi dapat dihilangkan karena dengan NIP Pegawai dan No Urut tidak menyebabkan kesulitan proses update data pada tabel Prestasi.

Gambar 10. Primay Key Tabel Prestasi adalah Kode Prestasi

Contoh kasus 6

Pendapat yang mengatakan bahwa semua table dalam suatu sistem informasi harus memiliki relasi adalah tidak sepenuhnya benar. Ada beberapa table yang memang harus berdiri sendiri karena table tersebut hanya sebagai tabel bantu.

Gambar 11. Entiti Range Nilai tidak harus berelasi dengan entiti lain

Hasil dari penilaian prestasi dari tiap penilai akan dikalkulasi sehingga menghasilkan nilai akhir (disimpan pada atribut Nilai Akhir pada entity Prestasi). Pada gambar 11 terdapat entiti Range Nilai yang menyimpan informasi ’arti’ tiap nilai akhir pada tiap prestasi. Entiti Range Nilai tidak perlu direlasikan dengan entiti Prestasi karena yang disimpan pada entiti Range Nilai merupakan informasi range nilai dan arti nilai, bukan menyimpan tiap nilai dan arti nilai. Sehingga entiti Range Nilai cukup berdiri sendiri.

Contoh kasus 7

Pembuatan relasi yang berlebihan juga menyebabkan redundasi data (Elmasri poin (b)). Gambar 12 memperlihatkan bahwa ada redundasi relasi dimana pada tabel Penilaian Prestasi disimpan atribut NIP Pegawai, padahal dari relasi dinilai (antara entiti Prestasi dengan entiti Penilaian Prestasi) dapat dicari pula NIP Pegawai yang dinilai prestasinya dengan menggunakan proses query. Sehingga relasi pegawai berprestasi harus dihilangkan untuk menghilangkan redundansi data.

Gambar 12. Redundasi relasi pada relasi pegawai berprestasi

Contoh kasus 8

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

Gambar 13. Redundasi relasi pada relasi pegawai berprestasi

Contoh kasus 9

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

Gambar 14. Pemilihan tipe data

Penggunaan tipe data pada gambar 14 untuk atribut Nama Prestasi pada entiti Prestasi menyebabkan penggunaan space yang tidak perlu setiap kali terjadi penambahan data dari tabel Prestasi. Tipe data atribut tersebut harus diubah dari Variable Character(50) menjadi Character(50).

KESIMPULAN

Berdasarkan dari pembahasan sebelumnya, maka dapat diambil kesimpulan yaitu :

1. Kesalahan yang sering terjadi dalam melakukan desain adalah

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

b. pembuatan relasi yang salah,

c. pembuatan relasi yang redundansi,

d. adanya redundansi data,

e. pemilihan primary key untuk suatu tabel dan

f. pemilihan tipe data.

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

Sumber : http://www.petra.ac.id/~puslit/journals/pdf.php?PublishedID=INF05060101.

studi kasus perancangan database

fanyirmawati — Wed, 17 Sep 2008 08:50:50 +0000

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

Gambar 1: Tahap perancangan database untuk database yang berukuran besar

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)

**************

database

fanyirmawati — Tue, 09 Sep 2008 06:32:00 +0000

Database

fanyirmawati — Tue, 09 Sep 2008 06:27:42 +0000

perancangan database

fanyirmawati — Fri, 05 Sep 2008 09:13:19 +0000

Perancangan Database

Ditulis pada September 24, 2007 oleh Achun

Pokok pemikiran dalam merancang database adalah bagaimana merancang database sehingga dapat memenuhi kebutuhan saat ini dan kemudahannya untuk dikembangkan dimasa yang akan datang. Perancangan model konseptual perlu dilakukan disamping perancangan secara phisik.

Pada perancangan konseptual, digunakan beberapa konsep pendekatan relasional namun tidak berarti konsep ini harus diimplementasikan ke model relasional saja tetapi juga apat dengan model Hirarchi dan model Network.

Tugas merancang database adalah bagian dari tugas database administrator . Model konseptual mengkombinasikan beberapa cara untuk memproses data dan untuk beberapa aplikasi. Model konseptual tidak tergantung aplikasi tertentu dan tidak tergantung DBMS, Hadware yang digunakan.

Pada perancangan model konseptual tinjauan dilakukan pada struktur data dan relasi antar file menggunakan model dan relasional.

Terdapat dua teknik dalam merancang database yaitu :

· Teknik Normalisasi

· Teknik Entity Relationship

Hello world!

fanyirmawati — Fri, 05 Sep 2008 08:46:08 +0000

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!