Dewirachmaamik’s Weblog

 

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

 

 

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.

A. Pendahuluan

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