Step step normalisasi :

1NF ( First normal Form )
1.Menghilangkan semua pengulangan field
2 Definisikan primary keys.
3 PK nya harus Uniq
4 Setiap field  selain PK harus tergantung pada PK
5 Setiap field harus terisi 1 nilai
6 Buat tabel baru untuk memindahkan pengulangan field dari table sebelumnya

Tabel:Supplier.dbf

———————————————————
Supid    Nama_supplier     no_telp1     no_telp2          no_telp3
——————————————————-
1              Joko                    088814141    081352525     98885411
2             Wawan                 088814142    081352526             
3             Ahmad                088814143   
——————————————————- 

Akan ada masalah Update/Insert  apabila no_telpon nya lebih dari 3
Ketika di normalkan akan menjadi :

Tabel Supplier.dbf                   Tabel Supplier_telp.dbf           
———————-        ————————–
Supid     Nama_supplier           id     supid       No_telp
———————-       —————————
1           Joko                            1       1           088814141
2           Wawan                        2       1           081352525
3          Ahmad                         3       1           98885411
                                                4       2           088814142   
                                               5       2           081352526             

2NF ( Second Normal Form )
Definisi: Semua field harus tergantung pada primary key

Detail_invoice.dbf
———————————————-
 id  Invoice_id    Goods_id    Qty      Harga   Cust_id
———————————————-
 1    S.01              1                10      5000     C.01
 2    S.01               5                8      25000     C.01

Disini terlihat field cust_id tidak tergantung pada primary key id  dan Invoice_id
maka cust_id bisa kita pindah dari tabel detail_invoice.dbf ke file invoice.dbf

3rd NF  ( third Normal form )
Menghilangkan field yg sama sekali tidak berhubungan dengan PK tapi bergantung pada field lainnya

Invoice.dbf
———————————————————-
Invoice_id    Tgl              Cust_id      Nama_customer
———————————————————-
S.01         10-10-06          C.01          Dunia ,PT
S.02         10-10-06          C.02          Septia ,PT

disini field Nama_customer dapat dihilangkan karena tidak berhubungan langsung dengan PK nya ( Invoice_id) tapi bergantung pada Cust_id.

Umumnya kita akan berhenti pada Normal ke Tiga , walaupun masih ada beberapa normal berikutnya

Dari semua step diatas maka dapat terlihat normalisasi dapat memudahkan kita membuat proses Insert/update/Delete ,
namun normalisasi menimbulkan masalah pada Query performance dibandingkan yg DeNormalized
bayangkan jumlah JOIN bila ada >5 tabel yg terlibat dalam  sebuah Query dengan jumlah data yg banyak

Quote

Normalisasi akan meningkatkan data integrity tetapi akan juga meningkatkan Query complexity.
sebaliknya Denormalisasi akan mengurangi data integrity dan juga mengurangi Query Compexity

Bagi yang pernah coba Crystal Report/Reporting Tool lainya  tentu merasakan dampak negatif dari Normalisasi , mengapa ? karena performance untuk reporting yg melibatkan banyak tabel menjadi lebih lambat dibanding Denormalized form

PENGARUH DESAIN TERHADAP PENERAPAN EFEKTIFITAS

DATABASE MELALUI BEBERAPA CONTOH KASUS

ABSTRAK: 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.

Kata kunci: database, logical data model.

ABSTRACT: The main foundation of information system is database and programming. Inefficient

database and unstructured programming can influence information system performance. Database design

is very important, including the data design, data domain and relationship. Unstable design can cause data

lost, inconsistent data, redundancy data, slow data updating and many more. A some presented in this

paper study cases here show how important the step of design before the step of making database, which is

called the design of logical data model. From these study cases here, we can see that design will influence

the database.

Keywords: database, logical data model.

PENDAHULUAN

Salah satu langkah dalam membangun suatu

sistem informasi adalah melakukan perancangan

database. Database merupakan jantung dari sistem

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

(1) memastikan data agar dapat diakses

oleh banyak user pada banyak aplikasi,

(2) maintain data secara akurat dan konsisten, (3) memastikan data yang dibutuhkan baik sekarang maupun yang akan

datang dapat tersedia,

(4) database dapat memenuhi

kebutuhan sesuai dengan pertumbuhan user dan (5)database dapat memenuhi kebutuhan pembacaan data tanpa memperdulikan bagaimana data secarafisik tersimpan [4].

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

[2]:

a. Memeriksa definisi, semantik dan tipe data pada tiap entiti untuk mencari duplikasi obyek bisnis karena dapat tidak terlihat apabila nama yang digunakan berbeda.

b. Memastikan tiap data pada entiti bahwa hanya

memiliki satu pengenal yang unik (primary key),

dimana termasuk apabila ada data lama yang

dihapus dari database.

c. Menggunakan aturan normalisasi untuk memastikan bahwa sebuah atribut hanya dimiliki oleh satu entiti saja.

d. 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 [1]:

a. Semantic atribut

Bagaimana menggambarkan relasi yang dapat

menggambarkan fakta yang ada.

b. Memperkecil terjadinya data redundansi

Tujuan dalam pembuatan database adalah mengoptimalkan penyimpanan data.

c. 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.

d. Tiap entiti memiliki definisi/semantik yang jelas.

PENERAPAN LOGICAL DATA MODEL

DALAM CONTOH KASUS

Contoh kasus digambar menggunakan notasi

chicken feet dengan tools Power Designer 6.1.

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.

bekerja pada

kepala departemen

Pegawai

NIP Pegawai

Nama Pegawai

Departemen

Kode Departemen

Nama Departemen

Gambar 1. Relasi entiti Pegawai dan entiti

Departemen

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).

kepala departemen departemen

bekerja pada

Pegawai

NIP Pegawai

Nama Pegawai

Departemen

Kode Departemen

Nama Departemen

History Kepala Departemen

Tanggal Menjabat

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.

jabatan

menjabat departemen

Pegawai

NIP Pegawai

Nama Pegawai

Departemen

Kode Departemen

Nama Departemen

History Jabatan

Tanggal Menjabat

Jenis Jabatan

Kode Jabatan

Jabatan

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.

Entity relationship adalah suatu cara memodelkan suatu data ditingkat konseptual dalam perancangan basis data.  Model Entity-Relationship merupakan alat modeling data yang populer dan banyak digunakan oleh para perancang database.  Data model merupakan representasi abstrak dari data tentang entitas, kejadian, aktifitas dan asosiasinya dalam suatu organisasi.  Tujuan dari pemodelan data adalah untuk menyajikan data dan menjadikan data mudah dimengerti, sehingga mempermudah perancangan dan pengaksesan database.

Berdasarkan tipe konsepnya, data model dibagi menjadi dua kategori yaitu Conceptual (High Level) Data Model dan Physical (Low Level) Data Model.  Conceptual Data Model merupakan konsep yang berkaitan dengan pandangan pemakai terhadap data, sedangkan Physical Data Model merupakan konsep yang menerangkan detail dari bagaimana data di simpan di dalam komputer.  Dalam pandangan ini model Entity-Relationship digunakan untuk menggambarkan Conceptual Data Model (E-R).

Model Entity-Relationship

Model E-R diperkenalkan pertama kali oleh P.P. Chen pada tahun 1976, walau model ini sudah ketinggalan jaman akan tetapi dalam penerapannya ER masih merupakan model yang efektif dalam upaya menggambarkan persepsi dari pemakai karena berisi objek-objek dasar yang disebut sebagai entitas dan hubungan antar entitas-entitas yang disebut relationship.  Adapun model E-R dinotasikan sebagai berikut :

Simbol	Arti	Uraian
	Entitas	Entitas/Entity adalah sesuatu yang dibedakan dalam dunia nyata, diman informasi yang berkaitan dengannya dikumpulkan.  Entity set (Himpunan entitas) adalah kumpulan dari entity yang sejenis, berupa proyek, kendaraan, pegawai, konsumen, pemasok, penjualan dan lain sebagainya.
	Relationship	Hubungan yang terjadi antara satu atau lebih entity.  Relationship tidak mempunyai keberadaan fisik kecuali yang diwarisi dari hubungan antara entity tersebut.
	Atribut	Karakteristik dari entity atau relationship yang menyediakan penjelasan detail tentang entity atau relationship tersebut.  Nilai atribut (Attribute value) adalah suatu data aktual atau informasi tertentu yang disimpan pada tiap atribut di dalam suatu entitas atau relationship (Nonkey attribute).  Identifier (key) digunakan untuk menentukan suatu entity secara unik.  Descriptor (nonkey attribute) digunakan untuk menspesifikasikan  karakteristik dari suatu entity yang tidak unik.
	Key Atribut (Atribut Kunci)	Atribut yang digunakan untuk menentukan suatu entity secara unik.
	Weak Entity	Lihat penjelasan tentang weak entity
	Identifying Relationship	Lihat penjelasan tentang weak entity
	Multivalued Atribut	Lihat penjelasan tentang weak entity
	Discriminating atribut pada weak entity	Lihat penjelasan tentang weak entity

Derajat Relationship

Terdapat 3 macam derajat dari relationship, yaitu :

• Unary Degree (derajat satu),

             Bila satu entity mempunyai relasi terhadap dirinya sendiri.  Digambarkan sebagai berikut :

• Binary degree (derajat dua) dan

 

Bila satu relasi menghubugkan dua entity, digambarkan sebagai berikut :

 

• Ternary degree (derajat tiga)

Bila satu entity menghubungkan lebih dari dua entity. Digambarkan sebagai berikut :

Cardinality Ratio Constraint

Berfungsi untuk menjelaskan jumlah hubungan/relationship dari entity-entity yang berpastisipasi.  Terdapat 3 macam CRC yaitu :

• Hubungan 1 : 1 (One to One Relationship)

Yaitu suatu entity yang berada di himpunan A berhubungan dengan paling banyak dengan satu entity pada himpunan B, dan entity pada himpunan B berhubungan dengan paling banyak satu entity di himpunan A, digambarkan sebagai :

• Hubungan 1 : M (One to Many/Many to One Relationship)

Yaitu suatu entity pada himpunan A dapat berhubungan dengan sejumlah entity pada himpunan B, tetapi entity yang berada pada himpunan B hanya dapat berhubungan dengan hanya satu entity dari himpunan A atau sebaliknya.  Digambarkan sebagai :

     

• Hubungan M : N (Many to Many Relationship)

             Yaitu suatu entity yang berada di himpunan A dapat berhubungan dengan banyak entity di himpunan B, dan sebaliknya. Digambarkan sebagai :

 Notasi Bentuk Lain

Bentuk lain dari Cardinality Ratio Constraint dapat ditunjukan dalam beberapa bentuk hubungan antar entitas ke entitas, entitas ke relationship, maupun sebaliknya yang digambarkan sebagai berikut :

Simbol	Uraian	Simbol	Uraian
	Hubungan satu ke satu		Hubungan satu (optional)
	Hubungan satu atau lebih		Hubungan many (optional)
	Hubungan many

 Participation Constraint

Berfungsi untuk menjelaskan keberadaan suatu entity yang tergantung dengan entitas lainnya.  Terdapat dua macam Participation Constraint yaitu

• Total Participation

               Yaitu keberadaan suatu entity tergantung pada entity lain, yang digambarkan dengan dua garis penghubung antara entity dengan relationshipnya.

• Partial Participation

                Dimana keberadaan suatu entity tidak tergantung pada entity lain, digambarkan cukup dengan satu garis penghubung.

Weak Entity

Suatu entity yang mungkin memiliki suatu atribut yang bukan miliknya, dimana keberadaannya tergantung dari entity lain.  Entity lain tersebut dikatakan sebagai Identifying Owner dan relationshipnya dinamakan Identifying Relationship.  Weak entity selalu memiliki Total Participation Constraint dengan Identifying Owner.

Entity Relationship (E-R) Diagram

 Entity-Relationship Diagram melengkapi penggambaran grafik dari struktur logika, dengan kata lain E-R diagram menggambarkan arti dari aspek data seperti bagaimana entity-entity, atribute-atribute dan relationship-relationship disajikan.  Langkah-langkah pembuatan E-R Diagram :

1. Tentukan entity-entity yang diperlukan disesuaikan dengan permintaan pemakai;
2. Tentukan relationship antar entity-entity;
3. Tentukan Cardinality ratio dan Participation Constraints
4. Tentukan atribut-atribut yang diperlukan dari setiap entity
5. Tentukan primary key diantara atribut-atribut
6. Buatlah penamaan entity, atribut dan relationship yang unik, dan hindari penamaan yang sama untuk objek yang berbeda

 Penggunaan Model E-R dalam Perancangan Database

Model E-R sangat berperan penting dalam perancangan database, Model ini digunakan pada tahap Conceptual Design, yaitu tahap kedua dari perancangan database.  Tahapan pertama adalah pengumpulan dan analisa permintaan dari pemakai, tahap kedua dilakukan penerapan conceptual design dimana model E-R ini digunakan, pada tahap ini data disajikan dalam bentuk diagram. 

Dengan penggunaan diagram ini, dapat terlihat jelas hubungan entity dengan entity dan atribut yang diperlukan di dalam suatu entity.  Tahapan berikutnya adalah logical design, dalam tahap ini diagram E-R ditransformasikan ke dalam bentuk database, dengan sebelumnya ditentukan dahulu model database apa yang dipilih.  Tahap akhir dari perancangan database adalah tahap physical design, yaitu tahap untuk menentukan organisasi file dari database dan mendefinisikan penyimpanan data secara fisik.  Tahapan-tahapan ini digambarkan sebagai berikut :

Perancangan Entity Relationship dengan bantuan program Microsoft Visio 2007

     Merancang model E-R dalam praogram aplikasi seperti Microsoft Visio 2007 dapat menggunakan 2 cara yaitu :

1. Dengan bantuan shape Basic Flowchart
2. Dengan bantuan shape Database Model Diagram

 Basic Flowchart

 Pada visio penggunaan shape basic flowchart dapat membantu untuk merancang suatu E-R diagram dengan cepat yang tata cara penggunaannya sebagai berikut :

1. Pada menu File pilihlah New – Getting Started .. untuk memilih template categories yang dikehendaki
2. Setelah menu Template Categories muncul pilihlah Flowchart template klik icon Basic Flowchart, klik Create
3. Pilihan simbol yang sesuai dengan icon shape adalah sebagai berikut :

Simbol E-R	Nama	Icon Pada Basic Flowchart
	Entitas	Process
	relationship	Decision
	Atribut	Terminator
	Key Atribut	Terminator dengan menggunakan underlin

Adapun contoh dari E-R diagram yang menggambarkan database suatu perusahaan dapat digambarkan dengan bantuan basic flowchart adalah sebagai berikut :

Model dari E-R diagram tersebut di atas dapat juga di buat dalam bentuk notasi lain seperti yang diterangkan sebelumnya, yaitu dengan menggambarkan suatu relationship antar entity ke entity lain, yang menggambarkan suatu E-R dari sistem e-commerce yang digambarkan sebagai berikut :

Pembuatan model E-R dengan menggunakan database diagram akan di bahas pada tulisan selanjutnya….

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

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)

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

Sumber: murni_rk.staff.gunadarma.ac.id

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

Teknik Normalisasi

Teknik normalisasi banyak digunakan terutama pemula karena mudah dipahami dan diaplikasikan.

Dasar-dasar normalisasi

·      Normal form (bentuk normal) adalah suatu klas dari skema database relasi yang didefinisikan untuk memenuhi tujuan dari tingginya integritas dan maintainability

·      Kreasi dari suatu bentuk normal disebut normalisasi

·      Normalisasi dicapai dengan penganalisaan ketergantungan diantara setiap individu attribut yang diassosiasikan dengan relasinya

First normal form

·      Suatu relasi ada dalam kondisi First Normal Form (1NF) jika dan hanya jika semua domain yang tercakup terdiri hanya atomic value, misalnya tidak ada pengulangan group (domain-domain) dalam suatu tuple

·      Keuntungan dari 1NF dibanding Unnormalized relation (UNRs) adalah pada bentuk penyederhanaan representasi dan kemudahan dalam pengembangan menggunakan suatu query language

·      Kekuranannnya adalah kebutuhan terhadap duplikasi data

·      Sebagian besar sistem relasi (tidak semua) membutuhkan suatu relasi dalam bentuk 1NF

Second Normal Form

·      Suatu superkey adalah suatu himpunan dari satu atau lebih attribute, yang mana, dimana diambil secara khusus yang memmungkinkan kita untuk mengidentifikasikan secara unik satu entitas atau relasi

·      Suatu Candidate key adalah suatu subset dari attribut-attribut pada superkey yang juga merupakan superkey dan tidak reducible ke superkey yang lain

·      Suatu primary key dipilih dari himpunan candidate key untuk digunakan pada suatu index untuk relasi yang bersangkutan

·      Kepemilikan dari satu atau beberapa attribute yang dapat didefinisikan secara unik dari nilai satu atau beberapa attribute disebut functional dependency

·      Diberikan suatu relasi (R), suatu himpunan (B) adalah functionally dependent pada himpunan attribut yang lain(A) jika, pada satu waktu tertentu, setiap nilai A diassosiasikan dengan satu nilai B, bentuk ini adalah suatu FD yang dinotasikan dengan A → B

• contohR : {paper-id, inst-name, isnt-addr, editor-id, publ-id, auth-id, auth-name,auth-addr}Fds : paper-id, auth-id → auth-namepaper-id,auth-id → auth-addrpaper-id, auth-id → inst-namepaper-id, auth-id → inst-addrauth-id → auth-nameauth-id → auth-addrinst-name → inst-addrpaper-id → editor-idpaper-id → publ-idbentuk sederhanapaper-id, auth-id → auth-name, auth-addr, inst-name, inst-addrauth-id → auth-name, auth-addrinst-name → inst-addr

paper-id → pub-id, editor-id

·      Suatu relasi adalah dalam posisi second normal form (2NF) jika dan hanya jika relasi tersebut juga dalam 1NF dan setiap nonkey attribute tergantung penuh pada primary key-nya

·      2NF membutuhkan bahwa FD apapun didalam relasi harus berisi semua komponen dari primary key sebagai determinant, baik secara langsung atau transitif

·      contoh, primary key adalah paper_id, auth_id. Bagaimanapun, terdapat Fds yang lain (auth_Id → auth-name, auth-addr, and paper-id → pub-id, editor-id) yang berisi satu komponen dari primary key, tetapi tidak keduaduanya.

·      Mengapa harus 2NF, pertimbangkan keuntungan dari 1NF pada R. paper, pub-id dan editor-id dibuat duplikat. Untuk setiap author dari paper. Jika editor dari publikasi untuk suatu paper berubah, beberapa tuple harus pula di-update. Akhirnya, jika satu paper di ambil, semua tupple yang diassosiasikan harus dihapus. Bentuk ini akan memberikan efek samping pada penghapusan informasi yang mengassosiasikan suatu auth-id dengan auth-name dan auth-addr.

·      Suatu cara yang dapat dilakukan untuk hal tersebut adalah dengan mentransformasikan relasi kedalam dua atau beberapa relasi 2NF

contohR1 : paper-id, auth-id → inst-name, inst-addrR2 : auth-id → auth-name, auth-addrR3 : paper-id → pub-id, editor-id

Third Normal Form

·      Pada R1, inst_addr pasti diduplikat untuk setiap kombinasi paper_author yang mejelaskan satu inst_name. Juga, jika kita menghapus satu paper dari database, kita harus memberikan efek samping penghapusan assosiasi antara inst_name dan inst_addr.

·      Suatu relasi dalam Third Normal Form (3NF) jika dan hanya jika relasi tersebut dalam 2NF dan setiap non key attribute adalah nontransitive dependent pada primary key

Contoh :R11 : paper-id, auth-id → inst-nameR12 : inst_name → inst_addrR2 : auth-id → auth-name, auth-addrR3 : paper-id → pub-id, editor-id

Boyce-Codd Normal Form

·      Suatu Trivial FD adalah suatu bentuk YZ → Z

·      Suatu relasi R dalam kondisi Boyce-Codd Normal Form (BCNF) jika untuk semua nontrivial FD X → A, X adalah superkey

·      BCNF adalah suatu bentuk yang lebih kuat dari normalisasi ke tiga. 3NF equivalent dengan perkataan bahwauntuk setiap nontrivial FD X → A, dimana X dan A merupakan simple atau composite attribut, satu dari duakondisi harus dipenuhi.X adalah superkey, atauA adalah prime attribute

·      BCNF mengelimisasi kondisi kedua dari 3NF

Penerapan Bentuk Normalisasi

Proses perancangan database menggunakan metode normalisasi dapat dimulai dari dokumen dasar yang pakai dalam sistem.

·      Menuliskan semua data yang akan direkam, bagian yang double tidak perlu dituliskan. Terlihat record record yang tidak lengkap, sulit untuk membayangkan bagaimana bentuk record yang harus dibentuk untuk merekam data tersebut.

·      Bentuklah menjadi bentuk normal kesatu dengan memisah misahkan data pada field field yang tepat dan benilai atomic, juga seluruh record harus lengkap adanya. Bentuk file adalah flat file.
Dengan bentuk normal kesatu ini telah dapat dibuat satu file dengan 11 field yaitu nomor factur, kode supplier, nama supplier, kode barang, nama barang, tanggal, jatuh tempo, quantitas, harga, jumlah, total satu factur.

Teknik Entity Relationship (ER)

Konsep Entity Relationship (Cardinality)

a. One to One Relationship

Hubungan antara file pertama dan file kedua adalah satu berbanding satu.

Contoh :

• pada pengajaran private satu guru satu siswa

• “seorang guru mengajar seorang siswa, seorang siswa diajar oleh seorang guru”

Gambar :

b. One to Many atau Many to One Relationship

Hubungan antara file pertama dan file kedua adalah satu berbanding banyak atau banyak berbanding satu.

Contoh :

• Dalam suatu perusahan satu bagian mempekerjakan banyak pegawai.

• “Satu bagian mempekerjakan banyak pegawai, satu pegawai kerja dalam satu bagian”

c. Many to Many Relationship

Hubungan file pertama dan file kedua adalah banyak berbanding banyak.

Contoh :

• Dalam universitas seorang mahasiswa dapat mengambil banyak matakuliah

• “Satu mahasiswa mengambil banyak matakulih dan satu matakuliah diambil banyak mahasiswa.”

LANGKAH-LANGKAH PERANCANGAN TEKNIK ER

Sumber awal data teknik perencanaan database dengan ER adalah data dictionary (kumpulan data).

Langkah-langkah perancangan ER:

1.   Memilih kelompok atribut yang sama untuk dijadikan sebuah entitas dan menentukan primary key dengan syarat unik dan mewakili entitas

2.   Menggambarkan Cardinality dari ER diagram berdasarkan analisa relasi yang didapat. Relasi yang terjadi dapat One to One, One to Many dan Many to Many relationship

3.   Membentuk SKEMA DATABASE atau LRS (Logical Record Structure) berdasarkan ER diagram

·      Bila relasi One to One maka foreign key diletakkan pada salah satu dari 2 entitas yang ada atau menyatukan ke dua entitas tersebut.

·      Bila relasi One to Many maka foreign key diletakkan di entitas yang Many

·      Bila relasi many to many maka dibuat “file konektor” yang berisi 2 foreign key yang berasal dari kedua entitas

Membentuk tabel-tabel berdasarkan primary key yang terpilih dengan syarat sudah mencapai aturan normalisasi sekurang-kurangnya 3NF dari Skema DB/LRS yang ada :

PENERAPAN TEKNIK E – R

Buatlah perancangan database dengan teknik ER untuk data dictionary berikut ini :

·      No. Anggota

·      Nama Anggota

·      Tgl. Lahir

·      Alamat

·      Tgl. Masuk

·      Kode Buku

·      Judul

·      Pengarang

·      Penerbit

·      Tahun Terbit

·      Tgl.Pinjam

·      Tgl. Kembali

LANGKAH 1

·      Memilih kelompok atribut yang sama untuk dijadikan beberapa entitas dan menentukan primary key dengan syarat unik dan mewakili entitas

·      Dari data dictionary diatas dapat ditentukan 2 entitas yaitu :

Ø Entitas Anggota (Primary key: No. Anggota)

Ø Entitas Buku (Primary Key: Kode Buku)

Anggota

·      No. Anggota

·      Nama Anggota

·      Tgl. Lahir

·      Alamat

·      Tgl. Masuk

Buku

·      Kode Buku

·      Judul

·      Pengarang

·      Penerbit

·      Tahun Terbit

• Atribut Tgl. Pinjam dan Tgl. Kembali tidak dimasukkan dulu kedalam salah satu entitas.

LANGKAH 2

·      Menggambarkan Cardinality dari ER diagram berdasarkan analisa relasi yang didapat. Relasi yang terjadi dapat One to One, One to Many dan Many to Many relationship

·      Misalnya relasi yang terjadi :

“Seorang anggota dapat meminjam banyak buku dan satu buku dapat dipinjamkan oleh banyak anggota”

Gambar ER Diagram:

LANGKAH 3

·      Membentuk Skema DB atau LRS berdasarkan ER diagram

·      Bila relasi One to One maka foreign key diletakkan pada salah satu dari 2 entitas yang ada atau menyatukan ke dua entitas tersebut.

·      Bila relasi One to Many maka foreign key diletakkan di entitas yang Many

·      Bila relasi many to many maka dibuat “file konektor” yang berisi 2 foreign key yang berasal dari kedua entitas

• LRS yang berbentuk :

LANGKAH 4

·      Membentuk tabel-tabel berdasarkan primary key yang terpilih dengan syarat sudah mencapai aturan normalisasi sekurang-kurangnya 3NF dari Skema DB/LRS yang ada :

·      Karena relasi yang terjadi many to many maka dibuat file konektor.

Referensi:

http://zulidamel.wordpress.com/2007/09/24/perancangan-database/

af-kuliahku.blogspot.com/2008/02/perancangan-database-firmansyah0606022.html – 67k