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 :

1. Memeriksa definisi, semantik dan tipe data pada tiap entiti untuk mencari duplikasi obyek bisniskarena dapat tidak terlihat apabila nama yang digunakan berbeda.
2. Memastikan tiap data pada entiti bahwa hanya memiliki satu pengenal yang unik (primary key), dimana termasuk apabila ada data lama yang dihapus dari database.
3. Menggunakan aturan normalisasi untuk memastikan bahwa sebuah atribut hanya dimiliki oleh satu entiti saja.
4. 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. Semantic atribut

Bagaimana menggambarkan relasi yang dapat menggambarkan fakta yang ada.

1. Memperkecil terjadinya data redundansi

Tujuan dalam pembuatan database adalah mengoptimalkan penyimpanan data.

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

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

DEKONSTRUKSI SISTEM SEBAGAI

BAHAN REKOMENDASI PENGEMBANGAN SISTEM

( STUDI KASUS www.bookpool.com )

Perencanaan sistem informasi ditujukan untuk menyelaraskan teknologi informasi dengan strategi bisnis dalam organisasi. Harapannya adalah untuk memperoleh manfaat maksimum terhadap investasi. Pada tahap perencanaan terdiri dari 3 langlah, yaitu:

1. Indentifikasi faktor perencanaan strategi
   1. Tujuan
   2. CSF
   3. Area Permasalahan
2. Identifikasi objek perencanaan perusahaan
   1. Lokasi
   2. Fungsi bisnis
   3. Tipe-tipe entitas
3. Pengembangan model perusahaan
   1. Dekomposisi fungsional
   2. Diagram E-R
   3. Matriks perencanaan

Proses pengembangan database merupakan bagian dari pengembangan sistem. Tiga tahap penting dalam perancangan database yaitu:

1. Perancangan secara konseptual
   1. Diagram konteks
   2. DFD
   3. Model ER
2. Perancangan secara logis

- Translasi model ER ke dalam model relational

1. Perancangan secara fisik

- Penciptaan database, relasi ( tabel ), dan hal-hal lain terkait ke dalam bentuk fisik.

Dalam pembuatan atau pembangunan database ada beberapa tahap yang perlu diperhatikan, antara lain:

• Tahap 1: Tentukan entities (object-object dasar) yang perlu ada di database
• Tahap 2: Tentukan attributes (sifat-sifat) masing-masing entity sesuai kebutuhan database
• Tahap 3: Tentukan relationships (hubungan-hubungan) di antara entities tersebut
• Tahap 4: Pembuatan ERD
• Tahap 5: Proses normalisasi database
• Tahap 6: Implementasi Database

Dari tahap atau metode tersebut dipakai untuk mendeskonstruksi situs www.bookpool.com. Tahap pertama adalah menentukan entitas.

1. Entitas adalah object dalam sistem yang memberikan suatu informasi. Entitas mempunyai sifat-sifat diantaranya adalah:

<!–[if !supportLists]–>· <!–[endif]–>Signifikan: memang perlu disimpan di database

<!–[if !supportLists]–>· <!–[endif]–>Umum: tidak menunjuk pada sesuatu yang khusus

<!–[if !supportLists]–>· <!–[endif]–>Fundamental: dapat berdiri sendiri sebagai entity yang dasar dan independent

<!–[if !supportLists]–>· <!–[endif]–>Unitary: merupakan satu kesatuan yang tidak dapat dipecah lagi

<!–[if gte vml 1]> <![endif]–><!–[if !vml]–><!–[endif]–>

Dari capturan halaman Home diatas dapat ditemukan suatu entitas yang terdiri dari:

• Entitas Buku

• Entitas Subyek
  
• Entitas Subsubyek
• Entitas Penerbit

<!–[if gte vml 1]> <![endif]–><!–[if !vml]–><!–[endif]–>

• Entitas Pengarang

<!–[if gte vml 1]> <![endif]–><!–[if !vml]–><!–[endif]–>

• Entitas Penjualan
• Entitas Detai_penjualan

<!–[if gte vml 1]> <![endif]–><!–[if !vml]–><!–[endif]–>

• Entitas Customer

<!–[if gte vml 1]> <![endif]–><!–[if !vml]–><!–[endif]–>

• Entitas Review

<!–[if gte vml 1]> <![endif]–><!–[if !vml]–><!–[endif]–>

• Entitas Testimonial

2. Tahap kedua, adalah menentukan atribute dari tiap entitas.

• Tentukan sifat-sifat (fields atau kolom) yang dimiliki tiap entity, serta tipe datanya.
• Attribute yang sesuai harus:

<!–[if !supportLists]–>· <!–[endif]–>Signifikan: memang penting dan perlu dicatat di dalam database

<!–[if !supportLists]–>· <!–[endif]–>Bersifat langsung (direct), bukan derived. Contoh attribute direct: tanggal_lahir
Contoh attribute derived: umur

<!–[if !supportLists]–>· <!–[endif]–>Tentukan attribute yang menjadi Primary Key untuk entity yang bersangkutan.

<!–[if !supportLists]–>· <!–[endif]–>Jika satu attribute tidak cukup, gabungan beberapa attribute bisa menjadi Composite Primary Key.

<!–[if !supportLists]–>· <!–[endif]–>Jika Composite Primary Key banyak (lebih dari 3 attribute), sebaiknya menambahkan attribute buatan yang menjadi Primary Key yang tunggal.

3. Tahap ketiga, menentukan Relationshipnya.

• Tentukan jenis hubungan di antara entity yang satu dengan entities yang lain.
• Macam hubungan ada 3:

<!–[if !supportLists]–>· <!–[endif]–>One-to-one (1:1)

<!–[if !supportLists]–>· <!–[endif]–>One-to-many (1:n)

<!–[if !supportLists]–>· <!–[endif]–>Many-to-many (m:n)

<!–[if !supportLists]–>· <!–[endif]–>Dalam membentuk hubungan di antara 2 entities, tentukan attribute mana yang digunakan untuk menghubungkan kedua entities tersebut.

<!–[if !supportLists]–>· <!–[endif]–>Tentukan entity mana yang menjadi tabel utama, dan entity mana yang menjadi tabel kedua.

<!–[if !supportLists]–>· <!–[endif]–>Attribute (dari tabel utama) yang menghubungkannya dengan tabel kedua menjadi Foreign Key di tabel kedua.

4. Tahap ke empat pembuatan ERD dan implentasi ERD dalam table.

<!–[if gte vml 1]> <![endif]–><!–[if !vml]–><!–[endif]–>

5. Tahap ke lima proses normalisasi.

Dari Relationshipnya dicek apakah masih ada table-tabel yang belum normal, jika belum dilakukan normaslisasinya. Untuk contoh diatas setelah dicek, table-tabelnya sudah normal..

Kesimpulan

Situs www.bookpool.com sudah bisa didekonstruksi menggunakan teknik atau metode pembuatan atau membangun database dan hasilnya bisa dilihat dari relationshipnya.

Sumber : http://dosen.amikom.ac.id/downloads/artikel/DEKONSTRUKSI%20SITUS%20www.doc.

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/

Sumber :

http://af-kuliahku.blogspot.com/2008/02/perancangan-database-firmansyah0606022.html