P. 1
ERD menurut chen

ERD menurut chen

|Views: 3,134|Likes:
Published by lienana
tell about entity relatioship diagram
tell about entity relatioship diagram

More info:

Published by: lienana on Feb 18, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as DOC, PDF, TXT or read online from Scribd
See more
See less

06/30/2013

pdf

text

original

Bab 8

Entity Relationship Diagram (Diagram Hubungan antara Entitas)
8.1 PENGANTAR

B

ab ini membahas bagaimana professional system menggambarkan model data secara grafik dengan menggunakan entity relationship diagram yang kadangkadang dikenal sebagai ERD (istilah ini yang akan selalu digunakan) atau diagram ER. Dengan kata lain, ERD adalah suatu model jaringan yang menggunakan susunan data yang disimpan dalam system secara abstrak. Jadi, jelaslah bahwa ERD ini berbeda dengan DFD yang merupakan suatu model jaringan fungsi yang akan dilaksanakan oleh system, sedangkan ERD merupakan model jaringan data yang menekankan pada strukturstruktur dan relationship data. Biasanya ERD ini digunakan oleh professional system untuk berkomunikasi dengan pemakai eksekutif tingkat tinggi dalam suatu organisasi (seperti wakil presiden direktur dan manajer yang tidak tertarik pada pelaksanaan operasi-operasi system sehari-hari). Pemakai ini lebih tertarik dengan hal-hal sebagai berikut: • Data apa saja yang dibutuhkan untuk bisnis mereka? • Bagaimana data tersebut berelasi dengan data lainnya? • Siapa saja yang diperkenalkan untuk mengakses data tersebut? ERD juga menguntungkan bagi professional system, karena ERD memperlihatkan hubungan antar data store pada DFD (dapat dilihat pada BAB XI: Implementasi Basis Data Dalam Proyek Pengembangan Sistem Informasi). Hubungan ini tidak terlihat pada DFD, karena DFD hanya memusatkan perhatian pada fungsi-fungsi system bukan pada data yang dibutuhkan. Diagram hubungan entitas atau yang lebih dikenal dengan sebutan E-R diagram, adalah notasi grafik dari sebuah model data atau sebuah model jaringan yang menjelaskan tentang data yang tersimpan (storage data) dalam system secara abstrak. Diagram hubungan entitas tidak menyatakan bagaimana memanfaatkan data, membuat data, mengubah data, dan menghapus data.

8.2 ELEMEN-ELEMEN DIAGRAM HUBUNGAN ENTITAS
8.2.1 ENTITY Pada E-R diagram, entity digambarkan dengan sebuah bentuk persegi panjang. Entity adalah sesuatu apa saja yang ada di dalam system, nyata maupun abstrak dimana data tersimpan atau dimana terdapat data. Entitas diberi nama dengan kata benda dan dapat dikelompokkan dalam empat jenis nama, yaitu orang, benda, lokasi, kejadian(terdapat unsur waktu di dalamnya). 8.2.2 RELATIONSHIP Pada E-R diagram, relationship dapat digambarkan dengan sebuah bentuk belah ketupat. Relationship adalah hubungan alamiah yang terjadi antara entitas. Pada umumnya penghubung (relationship) diberi nama dengan kata kerja dasar sehingga memudahkan untuk melakukan pembacaan relasinya (bisa dengan kalimat aktif atau kalimat pasif). Penggambaran hubungan yang terjadi adalah sebuah bentuk belah ketupat dihubungkan dengan dua bentuk empat persegi panjang. Contohnya, Entitas Mahasiswa dengan NIM = “14534” dan Nama_Mhs = “Yudin” yang memepunyai relasi dengan Entitas Kuliah dengan Kode_Kul = “SI-140” dan Nama_MK = “Basis Data”, sehingga struktur data dari Relasi ini bahwa mahasiswa tersebut mengambil mata kuliah pada suatu perguruan tinggi. Sedangkan kita juga mengenal adanya Himpunan Relasi, yaitu kumpulan semua relasi di-antara entitas-entitas yang terdapat dalam himpunan entitas-himpunan entitas, tetapi pada umumnya himpunan relasi sering disebut dengan Relasi saja. Illustrasinya sebagai berikut. Tabel 8.1 Entitas / Tabel kuliah Entitas Kuliah Kode_Kul SI-140 PA-100 MT-140 Nama_MK Basis Data Pancasila Kalkulus SKS 4 2 4 Semester 3 1 4

Tabel 8.2 Tabel / Entitas kuliah Relasi Entitas Mahasiswa NIM 14534 14251 14782 Nama_Mhs Yudin Nurhasan Yanah ..... ..... ..... ..... Kode_Kul SI-140 PA-100 MT-140 Nama_MK Basis Data Pancasila Kalkulus …. …. …. …. Entitas Kuliah

8.2.3 RELATIONSHIP DEGREE
Relation degree atau Derajat Relationship adalah jumlah entitas yang berpartisipasi dalam satu relationship Derajat Relationship yang sering dipakai di dlam ERD sebagai berikut. 8.2.3.1Unary Relationship Contoh:

Pegawa i

Menikah

Gambar 8.1 (a) Diagram Relationship Unary. Pada Ganbar 8.1 (a) relationship Menikah menunjukkan relationship satu-ke-satu antara instance-instance dari entitas PEGAWAI. 8.2.3.2 Binary Relationship Binary Relationship adalah model Relationship antara instance-instance dari suatu tipe entitas (dua entity yang berasal dari entity yang sama). Relationship ini paling umum digunakan dalam pembuatan mode data. Gambar di bawah ini menunjukkan bahwa relationship Bekerja untuk merupakan Relationship banyak-ke-satu. Artinya, seorang

pegawai hanya dapat bekerja untuk satu departemen dan satu departemen memiliki banyak pegawai

Contoh: PEGAWAI M Bekerja untuk N DEPT.

Gambar 8.1 (b) Diagram Relationship Binary 8.2.3.3 TERNARY RELATIONSHIP Ternary Relationship merupakan relationship antara instance-instance dari tiga tipe entitas secara serentak . poada gambar 8.1 (c) relationship mengirimkan mencatat jumlah suatu alat tertentu yang dikirimkan oleh suatu pabrik menuju ke suatu gudang yang telah ditentukan. Masing-masing entitas mungkin berpartisipasi satu atau banyak dalam suatu relationship ternary. Perlu dicatat bahwa relationship ternary tidak sama dengan tiga relationship binary. Alat

Pegawai Bekerja Utk

Pegawai

Jumlah Gambar 8.1 Diagram Relationship Ternary

8.2.4 ATRIBUT
Secara umum atribut adalah sifat atau karakteristik dari tiap entitas maupun tiap Relationship. Maksudnya, atribut adalah sesuatu yang menjelaskan apa sebenarnya yang dimaksud entitas maupun Relationship sehingga sering dikatakan bahwa atribut adalah elemen dari setiap entitas dari Relationship. 8.2.4.1 Atribut Value

Atribut value atau nilai attribute adalah suatu occurrence teretntu dari sebuah attribute di dalam suatu entity atau Relationship. Ada dua jenis atribut antara lain sebagai berikut. a. Identifier (key) digunakan untuk menentukan suatu entity secara unik (primary key). b. Descriptor (nonkey attribute) digunakan untuk menspesifikasikan karakteristik dari suatu entity yang tidak unik. 8.2.5 KARDINALITAS (CARDINALITY) Kardinalitas Relasi menunjukkan jumlah maksimum tupel yang dapat berelasi dengan entitas pada entitas yang lain. Pada contoh sebelumnya, dapat melihat bahwa tupel-tupel pada emas Mahasiswa dapat berelasi dengan satu tupel, banyak tupel, atau bahkan tidak satupun tupel dari entitas Kuliah.Begityu pula sebaliknya, entitas-entitas pada entitas kuliah ada yang berelasi dengan beberapa tupel pada entitas Mahasiswa dan ada pula yang berelasi dengan satu tupel pada entitasa Mahasuswa. 8.2.5.1 One to One Tingkat hubungan ini menunjukkqn hubungan satu ke satu, dinyatakan dengan satu kejadian pada entitas pertama, dan hanya mempunyai satu hubungan dengan satu kejadian pada entitas yang kedua dan sebaliknya. Artinya setiap tupel pada entitas A berhubungan dengan paling banyak satu tupel pada entitas B, dan begitu juga sebaliknya setiap tupel pada entitas B berhubungan dengan paling banyak satu tupel pada entitas A. 8.2.5.2 One to Many atau Many to One Tingkatkan hubungan satu ke banyak adalah sama dengan banyak ke satu, tergantung dari arah mana hubungan tersebut dilihat. Untuk satu kejadian pada entitas yang pertama dapat mempunyai banyak hubungan dengan kejadian pada entitas yang kedua. Sebaliknya, satu kejadian pada entitas yang kedua hanya dapat mempunyai satu hubungan dengan satu kejadian pada entitas yang pertama.

One to Many (satu ke banyak)
Yang berarti satu tupel pada entitas A dapat berhubungan dengan banyak tupel pada entitas B, tetapi pada entitas sebaliknya, dimana setiap tupel pada entitas B, berhubungan dengan paling banyak satu tupel pada entitas A.

Many to One (banyak ke satu)
Yang berarti setiap tupel pada entitas BA dapat berhubungan dengan paling banyak satu tupel pada entitas B, tetapi tidak sebaliknya, di mana setiap tupel pada entitas A berhubungan dengan paling banyak satu tupel pada entitas B. 8.2.5.3 Many to Many Tingkat hubungan banyak ke banyak terjadi jika tiap kejadian pada sebuah entitas akan mempunyai banyak hubungan dengan kejadian pada entitas lainya, dilihat dari sisi entitas yang pertama maupun dilihat dari sisi yang kedua.

Artinya setiap tupel pada entitas A dapat berhubungan dengan banyak tupel pada entitas B, dan sebaliknya, di mana setiap tupel pada entitas B dapat berhubungan dengan banyak tupel pada entitas A.

8.3 NOTASI (DIAGRAM E-R)
Notasi-notasi simbolik di dalam Diagram E-R yang dapat kita gunakan adalah sebagai berikut. • Persegi panjang, menyatakan Himpunan Entitas / entitas. • Lingkaran / Elips, menyatakan Atribut (Atribut yang berfungsi sebagai key digaris bawahi) • Belah Ketupat, menyatakan Himpunan Relasi /relasi. • Garis, sebagai penghubung anatra Himpunan Relasi dengan Himpunan Entitas dan Himpunan Entitas dengan Atributnya. • Kardinalitas Relasi dapat dinyatakan dengan banyaknya garis cabang atau dengan pemakaian angka (1 dan 1 untuk relasi satu-ke-satu, 1 dan N untuk relasi sqatu-kesatu-ke-banyak atau N dan N untuk relasi banyak-ke-banyak). E Himpunan Entitas E

a

Atribut a sebagai key

R

Himpunan Relasi R

Link Berikut adalah contoh aktual penggambaran relasi antar himpunan entitas lengkap dengan kardinalitas relasi dan atribut-atributnya: 8.3.1 CONTOH KASUS PENGGAMBARAN KARDINALITAS RELASI DENGAN ERD VERSI CHEN 8.3.1.1 Relasi satu-ke-satu (one-to-one) Contoh:

Adanya relasi antara entitas Dosen dengan antitas Jurusan. Relasinya kita beri nama’Kepalai’. Pada relasi ini, setiap dosen paling banyak mengepalai satu jurusan (walaupun memang tidak semua dosen yang menjadi ketua jurusan). Setiap jurusan dikepalai oleh paling banyak satu orang dosen. Maka penggambarannya adalah sebagai berikut. NID NID 1  1 Kepala  Jurusan

Dosen

Gambar 8.2 (a) Diagram Kardinalitas One to One Catatan: Pada setiap kejadian hubungan/kardinalitas relast satu ke satu dapat ditangani dengan menyamakan primary key masing-masing entitas. Penyamaan primary key ini dilakukan hanya untuk memudahkan daya ingat kita. Apabila primary key pada salah satu entitas tersebut dengan nama primary key yang sama pada entitas pasangannya. 8.3.1.2 Relasi satu-ke-banyak (one-to-many) Contoh: Adanya relsi antara entitas Dosen dengan entitas Kuliah. Relasinya kita beri nama ‘Ajar’. Pada relasi ini, setiap dosen dapat mengajar lebih dari satu mata kuliah, sedang setiap mata kuliah diajar hanya oleh paling banyak satu orang dosen. Maka penggambarannya adalah sebagai berikut. NID NID Kd_MK 1  M 

Dosen

Ajar

Kuliah

Gambar 8.2 (b) Diagram Kardinalitas One to Many

Catatan: Pada setiap kejadian hubungan/kardinalitas relasi satu ke banyak dapat ditangani dengan cara menaruh primary key yang berada pada sisi relasi/entitas satu ke entitas/relasi yang banyak, maka entitas yang banyak akan selalu memiliki foreign key di man keynya berasal dari entitas/relasi yang satu. Seperti terlihat pada ERD di atas, NID pada entitas dosen berfungsi sebagai primary key. Edangkan NID pada entitas Kuliah berfungsi sebagai foreign key, semetara primary key pada entitas Kuliah adalah Kd_MK. 8.3.1.3 Relasi banyak-ke-banyak (many-to-many) Contoh: Adanya relasi entitas Mahasiswa dengan entitas Kuliah. Relasinya kita beri nama ‘Belajar’. Pada relasi ini, setiap mahasiswa dapat mempelajari lebih dari satu mata kuliah. Demikian juga sebaliknya, setiap mata kuliah dapat dipelajari oleh lebih dari satu orang mahasiswa. Maka penggambarannya adalah sebagai berikut. NIM M Mahasiswa  NIM Kd_MK N  Kd_MK

belajar

Kuliah

Gambar 8.2 (c) Diagram Kardinalitas Many to Many Catatan: Pada setiap kejadian hubungan/kardinalitas relasi banyak ke banyak dapat ditangani dengan cara membuat file konektor (file baru sedemikian sehingga relasi langsung banyak ke banyak berubah menjadi relasi tidak langsung satu lawan banyak melalui file konektor. Isi file konektor adalah minimal berisi dua primary key yaitu satu dari entitas Dosen, dan satu lagi dari entitas Kuliah, maka pada setiap kasus kardinalitas relasi Banyak ke Banyak akan menghasilkan tiga relasi baru. Seperti telihat pada ERD di atas, Entitas Mahasiswa dengan primary key: NIM, entitas Kuliah dengan primary key: Kd_MK, serta entitas Belajar dengan primary key NIM + Kd_MK (entitas belajar merupakan file konektor), sementara atribut NIM pada entitas (file konektor) Belajar berfungsi sebagai foreign key dari entitas Mahasiswa, dan Kd_MK pada entitas (file konektor) Belajar berfungsi sebagai foreign key dari entitas Kuliah. Dengan demikian maka kardinalitas relasi banyak ke banyak di atas telah berubah (seolah-olah) menjadi satu ke banyak. 8.3.2 DIAGRAM ER VERSI JAMES MARTIN

Di samping pemakaian notasi yan gsudah dijelaskan sebelumnya, dalam bebagai literatur akan dapat dijumpai pula penggambaran diagram E-R yang sedikit berbeda dengan yang telah kita gunakan. Penggambaran ini dikenalkan oleh James Martin. Mahasiswa  |Dosen  belajar  | Kuliah || Ajar

Gambar 8.3 Diagram E-R dalam Notasi James Martin Pada diagram E-R tersebut, perbedaannya terletak pada penggambaran derajat relasi yang sekaligus juga telah mengakomodasi adanya Derajat Relasi Minimum. Tabel 8.3 Tabel ERD versi Chen dan versi James Martin DASAR ARTI Notasi 1 Notasi 2 Kardinalis Kardinalitas satu-ke1 1 satu Kardinalitas satu-ke1 M banyak Kardinalitas banyak-keM banyak M 11 1 M 01 0 0M Relationship Class-Subclass / Subtipe-Subtipe ISA ISA Kardinalitas Mandatory One Kardinalitas Banyak (1,2,...M) Kardinalitas Optional 0 atau 1 Kardinalitas Optional 0 atau banyak (0,1,2,...M) Relationship ClassSubclass

Relationship Eksklusip

Terkadang pula, notasi untuk relasi-relasi yang bukan banyak-ke-banyak ditiadakan dari Diagram E-R. Cara penggambaran semacam ini sangat dipengaruhi oleh tahap implemetasi. 8.3.2.1 Contoh kasus kardinalitas relasi film video dengan menggunakan notasi ERD versi James Martin Dari gambar 8.4, jelas bahwa suatu toko video mungkin memiliki lebih dari satu copy untuk film-film tertentu, tetapi toko tersebut mungkin tidak memiliki satu copy pun dari suatu film tertentu dalam persediaan. Dengan demikian dibutuhkan notasi yang lebih rinci untuk menunjukkan range kardinalitas untuk suatu relationship. Film Copy_Film || Disimpan Sbg  0

Gambar 8.4 Diagram Kardinalitas Relasi versi James Martin 8.3.2.2 Kardinalitas minimum dan maksimum.

Kardinalitas minimum suatu relationship adalah jumlah minimum instance dari entitas B yang mungkin berhubungan dengan tiap instance dari entitas A. pada contoh sebelumnya, jumlah minimum copy film yang tersedia untuk suatu film adalah ‘Nol’. Kardinalitas Maksimum adalah jumlah maksimum instance. Untuk contoh di atas, jumlah maksimumnya adalah ‘banyak’ (suatu nilai tak terdefinisi yang lebih dari satu). Dengan menggunakan notasi pada kardinalitas relsi versi James Martin di atas, relationship ini digambarkan sebagai berikut. Film Copy_Film || Disimpan Sbg  0

Gambar 8.5 Diagram Kardinalitas maksimum dan minimum Pada Gambar 8.5 simbol nol pada garis dekat entitas COPY FILM berarti kardinalitas minimum, sementara notasi berkaki tiga berarti kardinalitas maksimum banyak. Sudah tentu suatu relationship adalah dua arah (bidirectional) sehingga ada juga notasi kardinalitas yagn dekat dengan entitas FILM. Perhatikan bahwa minimum dan maksimum entitas ini keduanya sama, yaitu kardinalitas satu. Hal ini disebut kardinalitas mandatory one. Dengan kata lain, tiap copy suatu film yang disimpan harus merupakan satu copy yang tepat dari satu film. Umumnya partisipasi dalam suatu relationship mungkin optimal.parsial atau mandatory/total untuk entitas yang terlibat. Jika kardinalitas minimum adalah nol, maka partisipasi adalah optimal, sedangkan kardinalitas maksimum adalah satu; partisipasi adalah mandatory. Contoh-contoh dari tiga relationship yang menampilkan semua kombinasi kardinalitas minimum dan maksimum yang mungkin dapat dilihat pada Gambar 8.6 di bawah ini.

Pasien Penyakit

||

Miliki

 |

Riwayat

Gambar 8.6. (a) Diagram Kardinalitas Mandatory Ditugask an pada

Pegaw ai

Proyek

Gambar 8.6. (a) Diagram Kardinalitas Satu Optimal, Satu Mandatory

Pegawai

Ditugaskan pada

Gambar 8.6. (c) Diagram Kardinalitas Optimal Dari gambar 8.6 di atas ada tiga deskripsi singkat dari masing-masing kardinalitas, yaitu: • PASIEN Memiliki RIWAYAT PENYAKIT (Gambar 8.6 (a)). Setiap pasien memiliki satu riwayat penyakit atau lebih (diasumsikan bahwa kunjungan awal pasien selalu dicatat sebagai suatu instance dari RIWAYAT PENYAKIT). Tiap instance RIWAYAT PENYAKIT dimiliki oleh tepat satu PASIEN (kardinalitas mandatory one yang lain). • PEGAWAI Ditugaskan pada PROYEK (Gambar 8.6 (b)). Tiap PROYEK memiliki paling sedikit satu PEGAWAI yang dirugaskan pada proyek ini (beberapa proyek memiliki lebih dari satu pegawai). Tiap PEGAWAI mungkin atau tidak (optional) ditugaskan pada PROYEK yang ada, atau mungkin ditugaskan pada beberapa PROYEK. • PEGAWAI Menikah PEGAWAI (Gambar 8.6 (c)). ERD ini adalah kardinalitas nol atau satu dalam dua arah karena seorang pegawai mungkin atau tidak menikah. Mungkin juga kardinalitas maksimum merupakan jumlah yang sudah pasti, bukan nilai banyak yang berubah-ubah. Misalkan, kebijakan perusahaan menyatakan bahwa seorang pegawai mungkin bekerja pada paling banyak lima proyek pada waktu yang sama. Dengan sturan ini, angka lima dapat ditempatkan di atas atau di bawah garis berkaki tiga dekat entitas PROYEK pada Gambar 8.6 (b). 8.2.2.3 Ketergantungan keberadaan (Exitence Dependency) Konsekuensi dari kardinalitas mandatory one adalah bahwa suatu instance dari tipe entitas tidak akan ada, kecuali bila ada suatu instance dari tipe entitas yang direlasikan. Misalkan, suatu instance dari entitas COPY FILM tidak akan ada kecuali entitas FILM yang direlasikan sudah ada. Dengan kata lain, ketergantungan keberadaan berarti bahwa suatu instance dari suatu entitas tidak akan ad tanpa keberadaan instance dari entitas lain yang direlasikan. Istilah lain yang sering digunakan untuk tipe entitas yang memiliki kardinalitas mandatory one adalah entitas lemah (Weak entity). Entitas lemah adalah suatu tipe entitas yang memiliki ketergantungan keberadaan atau suatu entitas yang tidak memiliki atribut kunci utama. Oleh sebab itu, suatu instance dari entitas lemah tidak akan ada secara bebas, tetapi tergantung pada keberadaan instance entitas lainnya. Dengan kata lain,

beberapa instance entitas tidak dapat dibedakan satu sama lain, karena kombinasi dan nilai atribut entitas-entitas tersebut adalah sama. Untuk contoh film video, COPY FILM adalah entitas lemah. 8.3.2.4 Indentiflying Relationship. Seperti telah dijelaskan di atas bahwa entitas lemah sering tidak memiliki idenfier alami (atau kunci kandidat), maka kunci utama dari entitas paBiaya/pemilik (entitas tempat entitas lemah bergantung) sering digunakan sebagai kunci utama dari entitas anak (chilod) yagn bergantung. Gambar 8.6 di atas dapat diperbaiki menjadi seperti gambar 8.7. NoFil m Film Nama Film NoFil m Copy Film Gambar 8.7 Diagram Entitas Lemah Pada Gambar 8.7 tampaklah bahwa kunci utama entitas paBiaya FILM, yaitu NO_FILM, adalah bagian lain dari kunci utamanya). Suatu Identiflying Relationship merupakan relationship tempat kunci utama entitas parent digunakan sebagai bagian kunci utama dari entitas anak. Ada dua keuntungan dari Identiflying relationship, antara lain sebagai berikut. • Integritas data. Keuntungan keberadaan dikuatkan karena kunci utama yang dipakai bersama-sama (oleh sebab itu entitas lemah tidak akan ada kecuali entitas paBiaya ada). • Memudahkan pengaksesan entitas anak. Pada contoh di atas, COPY FILM dapat dicari jika nomor film dan nomor copy diketahui. NoCop y

8.4 TAHAPAN PEMBUATAN DIAGRAM E-R
Diagram E-R selalu dibuat secara bertahap. Paling tidak ada dua kelompok pentahapan yagn bias ditempuh di dalam pembuatan Diagram E-R, yaitu: 1. tahap pembuatan Diagram E-R awal (preliminary design)< 2. tahap optimasi Diagram E-R (final design ). Langkah-langkah teknis yang dapat kita lakukan untuk menghasilkan Diagram E-R adalah sebagai berikut. a. Mengidentifikasi dan menetapkan seluruh entitas yagn akan terlibat. b. Menentukan atribut-atribut key (primary key) dari masing-masing entitas. c. Mengidentifikasi dan menetapkan seluruh relasi di antara entitas-entitas yang ada berserta foreign-key-nya (jika terjadi kardinalitas relasi one to many to many). d. Menentukan derajat/kardinalitas relasi untuk setiap relasi.

e. Melengkapi entitas dan relasi dengan atribut-atribut deskriptif (non-key). Untuk menetapkan langkah-langkah teknis pada tahap pertama tersebut serta mewujudkan perancangan basis data pada lingkup sistem perkuliahan, maka urutan penggambarannya adalah sebagai berikut.

8.4.1 MENGIDENTIFIKASI DAN MENETAPKAN SELURUH
ENTITAS YANG AKAN TERLIBAT Sebagaimana telah disebutkan, entitas mewakili sebuah kumpulan entitas/individu yang jelas eksistensinya dan dapat berdiri sendiri. Akan tetapi, entitas mana saja yang akan kita pilih/libtkan tidak hanya tergantung pada jenis topik/sistem yang kita tinjau, tetapi juga ditentukan oleh seberapa jauh ruang lingkup yan gingin kita akomodasi dalam rancangan basis data kita. Dalam lingkup sistem perkuliahan sesungguhnya ada banyak sekali entitas yagn bisa kita libatkan seperti Mahasiswa, Kuliah, Praktikum, Dosen, Asisten, Ruang, Jurusan, Literatur dan lain-lain. Namun, dalam lingkup sistem perkuliahan yagn sederhana sesuai dengan pembahasan di bab sebelumnya, dapat kita identifikasi adanya tiga buah entitas, yaitu Mahasiswa, Kuliah dan Dosen. Mahasiswa Dosen Gambar 8.8 (a) Identifikasi entitas yang terlibat Kuliah

8.4.2 MENENTUKAN ATRIBUT-ATRIBUT KEY (PRIMARY KEY) DARI MASING-MASING ENTITAS
Atribut-atribut key yagn kita sertakan di masing-msing entitas merupakan atribut terpenting yang dapat mengidentifikasi (membedakan) setiap entitas yang ada di dalamnya. Keberadaan atribut ini juga akan memberi keyakinan tentang kebenaran eksistensi dari setiap entitas. Salah satu ciri dari entitas adalah kemandiriaannya. Kemandirian itu terlihat dari kejelasan atribut yang menjadi key dan perbedaannya dengan key ayng ada di entitas yang lain.

NIM

Kd_MK

NID

Mahasis wa

Kuliah

Dosen

Gambar 8.8 (b) Penentuan primary key

8.4.3 MENGIDENTIFIKASI DAN MENETAPKAN SELURUH RELASI DI ANTARA ENTITAS-ENTITAS YANG ADA FOREIGN-KEYNYA

Langkah ketiga ini merupakan langkah terpenting dalam pembentukan Diagram E-R. Ketepatan kita dalam menentukan relasi-relasi yang terjadi di antara entitas akan sangat menetukan kualitas rancangan basis data yang kita bangun. Relasi-relasi yang kita tetapkan harus dapat mengakomodasi semua fakta yang ada, dan menjamin semua kebutuhan penyajian data, tetapi di sisi lain juga harus dibuat seoptimal mungkin agar tidak memakan ruang penyimpanan data. Untuk itulah, relasi-relasi yang sifatnya tidak langsung harus ditiadakan. NI NI Kd_ Kd_ NI NI Kd_ M M MK MK D D MK Bel ajar Aja r

Mahasis wa

Kulia h

Dos en

Gambar 8.8 (c) Identifikasi seluruh relasi dan foreign-key-nya Relasi Belajar akan dapat mengakomodasi adanya fakta tentang sejumlah mahasiswa yang mengambil mata kuliah tertentu dan sebaliknya sejumlah mata kuliah yang diambil / dipelajari oleh mahasiswa tertentu. Demikian juga dengan relasi Ajar yang dapat mengakomodasikan fakta tentang dosen yang mengajar mata kuliah tertentu. Kendati dalam bahasa alamiah, ada kebutuhan untuk menyajikan informasi tentang mahasiswa mana saja yang diajar oleh seorang dosen. Karena kebutuhan penyajian informasi semacam iti telah dapat dipenuhi dengan melakukan query yang melibatkan entitas kuliah dan kedua relasi yang telah ada.

8.4.4 MENENTUKAN DERAJAT / KARDINALITAS UNTUK SETIAP RELASI

RELASI

Karena memang fakta memperlihatkan bahwa seorang mahasiswa boleh mengambil beberapa mata kuliah sekaligus dan begitu sebaliknya, sebuah mata kuliah dapat diikuti oleh banyak mahasiswa sekaligus, maka derajat relasi antara entitas Mahasiswa dan Kuliah adalah banyak-ke-banyak. NI M NI M Kd_ MK Kd_ MK Kd_ MK NI D NI D

Mahasis wa

Bel ajar

 Kulia  h

Aja r

Dos en

Gambar 8.8(D-3) Penentuan derajat kardinalitas relasi

8.4.5 MELENGKAPI ENTITAS DAN RELASI DENGAN ATRIBUTATRIBUT DESKRIPTIF (NON-KEY)
Berangkat dari fakta yang ada, atribut-atribut deskriptif yang dapat kita sertakan pada masing-masing entitas danrelasi. Keberadaan atribut-atribut deskriptif ini merupakan refleksi pengakomodasian terhadap fakta yang memang ada, dan kebutuhan penyajian data pada saat yang lain. Atribut deskriptif ini juga tidak banyak berperan dalam membentuk pemahaman kita dalam “membaca” sebuah Diagram E-R, bahkan cenderung mengganggu, karena biasanya jumlah atribut demikian cukup banyak. Karena itu, khususnya pada sebuah sistem yang besar dan kompleks, langkah terakhir ini sering kali tidak dilakukan sehingga Diagram E-R sampai pada langkah ke empat saja.

8.5 DIAGRAM E-R DENGAN KAMUS DATA
Tujuan utama pembuatan Diagram E-R adalah untuk menunjukkan objek-objek (entitas) apa saja yang ingin dilibatkan dalam sebuah basis data dan bagaimana hubungan yang terjadi di antara objek tersebut. Dalam hal ini diperbolehkan untuk menggambarkan Diagram E-R dengan tambahan Kamus Data. Mahasis wa 1 Belaj N ar Kuliah N Ajar N Dosen

Gambar 8.9 Diagram ER lengkap dengan kardinalitas relasi Kamus Data: Mahasiswa = { NIM, Nama_Mhs, Alamat, Tpt_lahir, Tgl_lhr } Kuliah = { Kode MK, Nama_MK, SKS, Semester } Dosen = { NID, Nama_Dos, Keahlian, Alamat } Mempelajari = { NIM, Kode MK, Index_Prestasi } Mengajar = { Kode MK, NID, Waktu, Ruang }

8.6 MODEL DATA LANJUT 8.6.1 VARIAN ENTITAS
Idealnya, entitas yang kita libatkan dalam sebuah diagram E-R adalah entitas kuat / bebas (strong entitas). Entitas demikian tidak mempunyai ketergantungan dengan entitas lainnya. Namun demikian, dalam pembuatan diagram E-R kita tidak selalu dapat melibatkan entitas seperti itu. Adakalanya juga melibatkan entitas yang lemah (Weak entity sets) atau bagian dari entitas lainnya.

8.6.2 ENTITAS LEMAH
Entitas ini berisi entitas-entitas yang kemunculannya tergantung pada eksistensinya dalam sebuah relasi terhadap entitas lainnya. Entitas yang demikian memiliki atribut yang Nam a_ Ortu

dapat berfungsi sebagai key, yang benara-benar dapat menjamin keunikan entitas di dalamnya. Ni Ni Nam m Contoh: m a_ Na Ortu ma Orang_T Mem Mh iliki ua s Ni Hob Alm m Mahasis by _ Mh Ho s Tg Men by yel_ Hob nan lhr y
gi

Alm _ Ort u

Gambar 8.10 Diagram Weak Entity yang lebih kompleks

8.6.3 SUB ENTITAS (SUB TIPE ENTITAS)
Sub entitas merupakan entitas yang beranggotakan entitas-entitas yang merupakan bagian dari himpunan entitas yang lebih superior. Sub entitas merupakan hasil dekomposisi himpunan entitas berdasarkan pengelompokan tertentu. Contoh: NID Dosen IS A Pang kat Ni k Tgl_M sk Gambar 8.11 Diagram Sub Tipe Entity Dosen_Tet ap
Dosen tidak_Tetap

NID

Nama_K an

Alm_ Kan

8.6.4 RELASI MULTI ENTITAS
Relasi multi entitas (N-ary relasi) merupakan relasi dari tiga himpunan entitas atau lebih. Contoh:

Pada sistem perkuliahan kita dapat menambahkan himounan entitas baru, yaitu himpunan entitas ruang yang kemudian bersama dengan himpunan etitas dosen dan kuliah membentuk relasi ‘pengajaran’.

Kode_ kul

Kode_ kul

Nama_ dos

Nama_ dos

Kuliah

Pen gajar an Wakt u Ruang

Dosen

Kode_ru ang

Kode_ru ang

Nama_ru ang

Kapasita s

Gambar 8.12 Diagram ER Multi entitas Pada diagram E-R di atas, entitas ruang dibentuk karena data ruang juga memiliki entitas-entitas dengan jumlah atribut khusus (kode_ruang, nama_ruang, dan kapasitas), selanjutnya relasi yang kemudian terbentuk dari ketiga entitas di atas tentu saja karena memiliki key yang berasal dari ketiganya yaitu (kode_kul dari entitas kuliah, nama_dos dari entitas dosen dan kode_ruang dari entitas ruang). Yang menjadi tidak jelas pada relasi demikian adalah derajat relasinya.

8.6.5 RELASI GANDA (REDUNDANT RELASI)
Relasi ganda (Redundant relasi) adalah relasi yang muncul antara dua entitas tidak hanya satu relasi, tapi ada lebih dari satu relasi. Contoh:

NID

Kd_MK

Aj ar

Dosen

Temp at

Wakt u

Kuliah

kua sai

NID

Kd_MK

Gambar 8.13 Diagram Relasi Ganda

8.6.6 SPESIALISASI DAN GENERALISASI
Jika kita memulai dari sebuah entitas lalu kemudian melakukan pengelompokan yang melahirkan entitas baru maka kita sedang melakukan Spesialisasi. Pendekatan bersifat bottom-up, mula-mula terpisah tapi kemudian menjadi satu proses ini disebut Generalisasi. Dengan demikian, Spesialisasi dan Generalisasi merupakam dua proses yang berlawanan. Yang ditekankan pada spesialisasi adalah perbedaan antar kelompok entitas sedang dalam generalisasi yang ditekenkan adalah persamaannya. Spesialisasi dan Generalisasi diwujudkan dalam notasi relasi yang khusus yang disebut Relasi “I S A” sebagai berikut. Dosen

ISA Dosen tetap Dosen tdk tetap Mahasiswa

ISA

Mahasiswa D3

Mahasiswa S1

Gambar 8.14 Diagram Relasi ISA

8.6.7 AGREGASI
Agregasi menggambarkan sebuah relasi yang secara langsung menghubungkan sebuah entitas dengan sebuah relasi dalam diagram E-R. Mahasiswa Belaja r
Kd_ MK

Kuliah

NIM

Ajar
Kode_Pr a

Nilai Kuliah

Kode_Pr a

Nama_P ra

Juml_ja m

Gambar 8.15 Diagram Agregasi

8.7 TRANSDORMASI DIAGRAM E-R KE LRS (LOGIKAL RECORD STRUCTURE)
Aturan-aturan dalam melakukan transformasi E-R Diagram ke logical record structur adalah sebagai berikut. 1. Setiap entity akan diubah kebentuk sebuah kotak dengan nama entity berada di luar kotak dan atribut berada di dalam kotak. 2. Sebuah relasi kadang disatukan dalam sebuah kotak bersama entity, kadang dipisah dalam sebuah kotak tersendiri. Aturan pokok di atas akan sangat dipengaruhi oleh elemen yang menjadi titik perhatian utama pada langkah transformasi, yaitu cardinality/kardinalitas.

8.7.2 1:1 (ONE TO ONE)
Pada kardinalitas one to one, sebaiknya panah diarahkan ke entity dengan jumlah atribut yang lebih sedikit. Misalkan: Terdapat suatu relasi KAWIN yaitu penggabungan antara entity SUAMI dengan entity ISTRI.3 Pda kasus ini symbol ‘@’ yang diletakkan disalah satu atribut melambangkan primary key pada entitas tersebut., sedangkan atribut yang tidak memiliki / diberikan symbol ‘@’, merupakan atribut non-key dari entitas tersebut. − Penggabungan relasi KAWIN ke entity ISTRI SUAMI
NO.KTP-S NAMA-S TPT-L-S TGL-L-S @NO-SURAT NIKAH @NO-SURAT NIKAH NO.KTP-S NAMA-S TPT-L-S

SUAMI

Ka win
@NO-SURAT NIKAH NO.KTP-I NAMA-I TPT-L-I TGL-L-I TGL-KAWIN @NO-SURAT NIKAH NO.KTP-I NAMA-I TPT-L-I TGL-L-I TGL-KAWIN

ISTRI

ISTRI

Gambar 8.16 (a) Diagram ER One to One ke LRS

− Penggabungan relasi KAWIN ke entity SUAMI SUAMI
@NO-SURAT @NO-SURAT NIKAH NIKAH NO.KTP-S NO.KTP-I NAMA-S NAMA-I TPT-L-S TPT-L-I TGL-L-S TGL-L-I TGL-KAWIN

SUAMI

Ka win

@NO-SURAT NIKAH @NO-SURAT NIKAH NO.KTP-I NAMA-I TPT-L-I

ISTRI

NO.KTP-I NAMA-I TPT-L-I TGL-L-I TGL-KAWIN

ISTRI

Gambar 8.16 (b) Transformasi Diagram ER One to One LRS

8.7.3 1: M (one to many)
Pada kardinalitas relasi one to many, maka relasi harus digabungkan dengan entity pada pihak yang many, dan tidak perlu melihat banyak sedikitnya atribut pada entity tersebut. Misalkan terdapat relasi KERJA yang merupakan penggabungan antara entity PEGAWAI DAN PROYEK. Relasi tersebut akan dikonversikan ke LRS dan digabungkan ke entity PEGAWAI, karena entity PEGAWAI memiliki kardinalitas relasi Many. PEGAWAI
@NO_PEG NAMA @NO_PEG @ @KD_PROY NAMA

PEGAWAI

KERJA

PROYEK

@KD_PROY TGL_MULAI BIAYA

@KD_PROY TGL_MULAI BIAYA

PROYEK

Gambar 8.17 Transformasi Diagram ER One to Many ke LRS Pada kasus di atas symbol ‘@’ yang diletakkan disalah satu atribut melambangkan primary key pada entitas tersebut, dan symbol ‘@@ ‘ yang diletakkan disalah satu atribut melambangkan foreign key, sedangkan atribut yabg tidak memiliki / diberikan symbol ‘@’, merupakan atribut non-key dari entitas tersebut. Pada gambar 8.17 di atas terlihat bahwa entitas PEGAWAI memiliki foreign key ‘Kd_Proy’ yang berasal dari entitas PROYEK.

8.7.4 M: N (MANY TO MANY)
Pada kardinalitas Many to Many, maka relationship berubah status menjadi file konektor (yang akan merubah kardinalitas many to many seolah-olah menjadi one to many), sehingga baik entity maupun relasi akan menjadi struktur record tersendiri.

Dengan demikian, maka panah dari entity a dan entity b mengarah ke relationship tersebut. Misalkan terdapat relasi BELI yang merupakan penggabungan antara entity PELANGGAN dengan entity pada BARANG. Relasi tersebut bila dikonversikasikan ke LRS akan menjadi seperti gambar berikut. PELANGGAN PELANGGAN NAMA @ @[ @KD_PEL] BELI BELI
JUMLAH @KD_PEL NAMA

@KD_PEL

@ @[ @KD_BRG

@

@ @[ @KD_BRG]

PROYEK BARANG

@KD_BRG NAMA_BRG NAMA_BRG HARGA_BRG HARGA_BRG

@KD_BRG

Gambar 8.18 Transformasi Diagram ER Many to Many ke LRS Pada kasus di atas symbol ‘@ ‘ yang diletakkan di salah satu atribut melambangkan primary key pada entitas tersebut dan symbol ‘@@’ yang diletakkan di salah satu atribut melambangkan foreign key, sedangkan atribut yang tidak memiliki / diberikan symbol ‘@’, merupakan atribut non-key dari entitas tersebut. Pada gambar 8.18 di atas terlihat bahwa relationship BELI berubah menjadi file konektor dengan tiga atribut, yakni @@[@KD_PEL], yang merupakan foreign key bagi entitas PELANGGAN, dan @@[@KD_BRG] yang merupakan foreign key bagi entitas BARANG sehingga keduanya diberi symbol ‘@@’. Sementara @KD_PEL, dan @KD_BRG merupakan primary key bagi entitas BELI, sehingga kedua atribut tersebut diberi symbol ‘@’ yang menunjukkan fungsi sebagai primary key. Sedangkan atribut JUMLAH pada entitas BELI merupakan atribut deskriptif non key.

8.8 TRANSFORMASI ERD ATAU LRS KE RELASI
Subbab ini akan membahas bagaimana ERD /LRS di transformasikan ke relasi. Transformasi ini sering disebut dengan mapping ERD ke database relational. Transformasi ini dibagi ke dalam dua langkah, yaitu transformasi dengan merepresentasikan relationship menjadi relasi-relasi yang atau tabel-tabel database. Relasi-relasi yang berasal dari transformasi ini dapat dinormalisasikan dengan tekniteknik normalisasi.

8.8.1 MEREPRESENTASIKAN ENTITAS
Tiap tipe entitas dalam ERD ditransformasikan menjadi suatu relasi. Kunci utama /primary key (Identifier) tiap entitas menjadi kunci utama /primary key dari relasi yang bersangkutan. Adapun karakteristik yang perlu diperhatikan dalam memastikan atau memilih satu atau beberapa atribut dari kunci kandidat / candidate key telah dibahas pada bab sebelumnya (BAB I ‘PENGANTAR SISTEM BASIS DATA’. 6. ‘Kunci Elemen Data’. c. ‘Primary Key’) Tiap atribut bukan kunci dari tipe entitas menjadi atribut bukan kunci relasi. Relasirelasi yang dibentuk dari tipe entitas mungkin dimodifikasi sebagai relation yang dipresentasikan, seperti yang telah dibahas pada kasus TRANSFORMASI ERD ke LRS di atas . Gambar 8.19 (a) menunjukkan representasi dari tipe entitas PELANGGAN suatu perusahaan. Relasi PELANGGAN yang berkaitan dengan entitas PELANGGAN dapat dipresentasikan sebagai berikut. PELANGGAN (NO.PELANGGAN → NAMA,ALAMAT, KOTAKKODEPOS,POTONGAN) Relasi di bawah ini jika dipresentasikan sebagai tabel dengan data sample pada Gambar 8.19 (a) akan menjadi Relasi / Tabel Pelanggan seperti terlihat pada gambar 8.19 (b). Kota Alamat

KodePos

Nama Discount NoPelang gan Pelanggan

(a) ERD pelanggan No_Pelan ggan A1273 A6390 Nama Toko ABC PT.Jali Alamat Jl.RST No.3 JL. Kota Solo Kode Pos 20122 14440 Disco unt 5% 3%

XAB Jakart

No.12 ..........

a (b) Relasi

Gambar 8.19 Transformasi Suatu Tipe Entitas menjadi Relasi

8.8.2 MEMPRESENTASIKAN RELATIONSHIP
Prosedur untuk mempresentasikan relationship tergantung kepada derajat relationship (unary, binary, atau ternary), serta karakteristik relationship. 8.8.2.1 Relationship binary satu-ke-banyak (1:N) Relationship binary satu-ke-banyak (1:N) dalam ERD dipresentasikan dengan menambah satu atau lebih atribut primary key entitas yang berbeda di sisi satu (1) sebagai foreign key dlam relasi yang ada pada sisi banyak (M). Gambar 8.20 menunjukkan suatu contoh aturan ini. Gambar 8.20 (a) menunjukkan relationship (1:M) Memberikan yang menghubungkan PELANGGAN dan PESANAN. Dua relasi, PELANGGAN dan PESANAN, dibentuk dari tipe masing-masing entitas. NO.PELANGGAN yang merupakan primary key pada tabel /relasi PELANGGAN (pada sisi satu dari relationship) ditambahkan sebagai foreign key tabel /relasi PESANAN (pada sisi banyak dari relationship).
No_Pelang gan

Nam a

Alam at

TglPesa nan No_Pelang gan TglKiri m Pelanggan

Ko ta
KodePos Pelanggan Beri

Discou nt

(a) ERD dengan Kardinalitas Relasi 1 : M Pelanggan No_Pelan ggan A1273 A6390 .......... Pesanan

Nama Toko ABC PT.Jali

Alamat Jl.RST No.3 JL. XAB No.12

Kota Solo Jakart a

Kode Pos 20122 14440

Disco unt 5% 3%

No_Pesan TglPesa an nan 57192 12/04/95 60723 21/05/95 70112 07/08/95

TglKirim 19/04/95 28/05/95 14/08/95

No Pelanggan A1273 A6390 A1273

(b) Relasi Pelanggan dan Pesanan Gambar 8.20 Mempresentasikan Relastionship 1:M Kasus khusus dari aturan di atas beraplikasi pada relationship satu-ke-satu (1:1) anatra dua entitas A dan B. Pada kasus ini, relationship dapat dipresentasikan dengan salah satu cara di antaranya sebagai berikut.  Menambahkan primary key A sabagai foreign key B.  Menambahkan primary key B sebagai foreign key A.  Kedua aturan di atas digabungkan. 8.8.2.2 Relationship Binary M:N (Banyak ke Banyak) Misalkan ada relationship banyak-ke-banyak (M:N) antara dua tipe entitas. A dan B, untuk relationship seperti ini, perlu dibentuk relasi baru yang terpisah dari kedua entitas di atas. Primary key dari relasi ini adalah kunci komposisi (kunci gabungan) yang terdiri dari primary key pada masing-masing entitas dalam relationship. Atribut-atribut bukan kunci yang bekaitan dengan relationship M:N ditempatkan pada relasi C. Gambar 8.21 menunjukkan suatu contoh aturan ini. Gambar 8.21 (a) menampilkan relationship (M:N). Relationship MINTA yang menghubungkan dua tipe entitas PESANAN dan PRODUK. Gambar 8.21 (b) menunjukkan tipe relasi (PESANAN, PRODUK dan JENIS PESANAN) yang dibentuk dari tipe-tipe entitas dan relationship Minta. Langkah pertama untuk melakukan pembentukan ketiga relasi ini adalah suatu relasi dibentuk untuk tipe-tipe entitas dalam relationship (yaitu PESANAN, dan PRODUK), kemudian pembentukan relasi baru untuk relationship Minta (yang disebut JENIS PESANAN), dilaksanakan. Primary key JENIS PESANAN adalah kata kunci kombinasi antara primary key PESANAN dan PRODUK. Atribut bukan kunci JUMLAH PESANAN juga muncul pada entitas JENIS PESANAN.
NoPesa nan TglPesa nan Pesanan TglPesa nan

0
Min ta NoProdu k

Atubut lainnya

___
Produk

Keteran gan

Ruan g

(a) ERD Pesanan No Pesanan 57192 60723 70112 TglPesana n 12/04/95 21/05/95 07/08/95 TglKirim 19/04/95 28/05/95 14/08/95

Jenis Pesanan (berasal dari relationship Minta) No No Jml Pesanan Produk Pesanan 60723 M120 3 60723 B261 4 Produk No Produk M120 B261 F145 Keteran gan Tas Karpet Lemari Ruang G001 G002 F005 Antribut lainnya ................ ................ ................

(b) Relasi Gambar 8.21 Merepresentasikan Relationship M:N

8.9 APLIKASI ERD 8.9.1 THREE-TIERS CLIENT SERVER
Arsitektur three-tiered merupakan salah satu trend penting pada perkembangan aplikasi corporate. Konsep three tier ini merupakan suatu konsep yang menarik dan menjadi kenyataan pada pasar perangkat lunak di masa kini dan masa mendAgus. Perbedaan Arsitektur three-tiered dan two-tiered Arsitektur two-tiered adalah lingkungan client server traditional. Pada arsitektur ini suatu aplikasi dibagi menjadi dua entitas antara lain. • Client atau front end, yang merupakan bagian user inteface • Server atau back end, yang mengelola database, lazim disebut database server Dalam konfigurasi yang tipikal, pembagian ini juga meliputi pembagian hardware dan software. Client biasanya terletak pada workstation yang digunakan oleh user,

dan dibuat dengan menggunakan program seperti PowerBuilder, SqlWindows, Visual Basic, atau Delphi. Sedangkan server adalah suatu komputer server yang diletakkan di bagian lain pada jaringan yang menjalankan perangkat lunak database software, seperti Sybase, atau Oracle, Arsitektur ini ditampilkan pada Gambar 8.22 Cli ent Front End Database Management Gambar 8.22 arsitektur client server two-tiered Arsitektur three-tier menambahkan komponen ketiga seperti pada Gambar 8.23 Pada middle-tier, adalah bussiness process server, merupakan suatu bagian perangkat lunak terpisah, biasanya dijalankan pada hardware yang terpisah. Bagian ini menjalankan program yang berisi aturan-aturan aplikasi, seperti menerapkan aturan bisnis dan melakukan pemrosesan yang kompleks. Dari sisi pandang client, business process server adalah berfungsi sebagai server. Dari sisi pandang databse server, business process server dianggap sebagai client. Suatu business process server dapat berupa suatu mesin UNIX yang menjalankan program hitungan yang kompleks. Bussine ss Process Server Middle Tier Serv er Back Business Rules Serv er Back End User Interface

Cli ent Front End End

User Interface Database Management Application Logic

Gambar 8.23 Arsitektur client-serve three-tiered Yang harus diperhatikan adalah konsep middle-tier tidak sama dengan middleware. Middleware adalah perangkat lunak yang menghubungkan program yang berjalan pada plaform yang berbeda, middleware ini ditujukan agar program yang berjalan pada plaform yang berbeda tersebut dapat saling mengirimkan message dan data. Middleware memainkan peranan yang penting pada arsitektur three-tier, karena meddlewared inilah yang menghubungkan ketiga tier tersebut. Misalkan suatu sistem client server yang bekerja sebagai suatu sistem penerimaan order. Program client akan memasukkan setiap adanya order penjualan yang baru. Order ini dikirim ke middle-tier, lalu di middle-tier order akan diproses. Misalkan

akan diperiksa apakah barang yang dipesan tersebut tersedia di inventory, menghitung discount yang akan diberikan, mengecek jumlah tunggakan pelanggan tersebut, dan lain-lainnya. Bila order tersebut bisa diterima, maka middle-tier akan mengirimkan pesan menyetujui ke client, dan juga mengirimkan data baru yang berisi order baru ini ke database server, untuk menyimpan order tersebut. Pada system two-tier, aturan bisnis diterapkan pada program front end atau dapat juga database server (merupakan mekanisme penyimpanan-stored procedure). Dengan cara ini pada model two-tired, system akan lambat bila proses yang harus dilakukan adalah besar. Sehingga keuntungan utama dari model three-tired adalah: meringankan beban database server dengan cara memebagi pekerjaan ke business process server. Sebenarnya konsep arsitektur ini tidaklah benar-benar baru, yang hanya baru adalah metode mempartisinya secara formal sehingga tersedia perangkat Bantu yang dapat digunakan untuk menyusun model ini. Di lain pihak model three-tired ini biasanya hanya cocok untuk proyek-proyek yang berukuran besar. Untuk aplikasi kecil atau menengah, mungkin one atau two-tired lebih tepat.

8.9.2 ARSITEKTUR MANY-TIERED
Untuk pengembangan lebih lanjut, kini dikembangkan arsitektur many-tiered. Aplikasi didistribusian ke lebih dari tiga plaform, yang biasanya dilakukan dengan membagi proses bisnis tersebut, dapat juga disebut fourth-tier. Ada juga variasi yang bertujuan sebagai suatu penyederhanaan. Pembagian ketiga tier ini dapat juga tidak dilakukan secara fisik diletakkan di tiga system computer terpisah yang saling dihubungkan. Akan tetapi diletakkan pada satu atau dua computer saja. Yang penting adalah aplikasi-aplikasi tersebut tersegmentasi secara logis dan tidak tergantung, tetapi dapat saling berkomunikasi dan bertukar message dan data. Keuntungan Banyak keuntungan dari model three-tieredni diantaranya yang terpenting adalah peningkatan unjuk kerja atau performance. Dengan kata lain dapat dikatakan model ini mampu menyediakan satu solusi Graphical User Interface (GUI) yang user friendly pada suatu computer desk top client, yang mengemas proses suatu transaksi berukuran amat sangat besar yang biasanya hanya diperoleh dan ditemukan pada computer mainframe. Hal ini memecah kebutuhan untuk menyediakan suatu sistem pemrosesan besar dengan GUI yang memeiliki 40 sampai dengan 50 user. Hal lainnya adalah secalability. Arsitektur ini dapat dengan cepat dan mudah menaikkan jumlah transaksi pengguna tanpa perlu perubahan besar pada investasi hardware dan software. Misalkan pada suatu client server yang two-tiered yang meletakkan prosedur penyimpanan order pada database server. Ketika volume transaksi membesar, database server menjadi pelan. Untuk itu menaikkan unjuk kerja kembali, maka pilihan untuk penambahan database server sulit untuk dilakukan. Pada sistem three-tiered, masalah ini dengan mudah dapat dipecahkan, yaitu dengan cara menambahkan middle-tier server. Setiap server menjalankan program business server yang sama. Tidak menjadi masalah client mana yang dilayani, karena setiap client dapat melakukan dengan koneksi server yang manapun, ketika yang satunya sibuk.

Cli ent
Back End

Cli Database Management ent

Stored Database Procedures Server

Cli ent Gambar 8.24 Stored Procedures pada Database Server

Cli ent

Bussine ss Process Server

Cli ent

Cli ent

Bussine ss Process Server

Databas e Server

Gambar 8.25 Penambahan Middle-tier untuk menaikkan performa Suatu aplikasi three-tier juga mudah untuk pindah ke berbagai back-end server. Pada aplikasi two-tier, misalnya ingin mengubah dari SQL Server ke Oracle, atau DB2, maka seluruh prosedur store harus ditulis ulang, karena sangat bergantung pada dialek

dari tiap produk SQL tersebut. Pada arsitektur three-tiered, penggunaan prosedure store ini diminimalkan karena proses logik dilaukan di middle-tier. Misalkan pada model client server two-tier yang lain proses aturan bisnis diletakkan di program client. Hal ini memiliki potensi untuk menimbulkan problem juga. Permasalahan perawatan adalah problem yang terbesar. Bagaimana untuk melakukan up nilai pada beratus-ratus client, dengan pemrograman aturan bisnis yang baru. Hal lainnya adalah biaya upgrade untuk tiap workstation sehingga proses dapat berlangsung dengan cepat, karena tiap workstation tersebut harus menjalankan program yang melakukan proses aturan bisnis tersebut juga. Arsitektur three-tiered memecahkan masalah ini, karena pengubahan aturan bisnis hanya perlu dilakukan di middle server saja sehingga mudah untuk dilakukan perawatan perangkat lunak.

GUI

SP Databa se Server

Client Management

Back End Database

GUI

SP Client SP Client GUI : Graphical User Interface SP : Stored Precedures

GUI

Gambar 8.26 Arsitektur Two-tiered dengan stored procedures pada client Suatu kemampuan yang berharga dari arsitektur three-tier ini adalah kemampuan untuk mendukung berbagai platform client yang berfungsi sebagai front-end. Fort Software Inc, telah mengembangkan suatu system yang memiliki client dari MacIntosh, Windows, dan Unix Motif, keseluruhannya dikoneksikan ke mesin yang sama.

8.9.3 CLIENT DAN SERVER YANG KHUSUS
Suatu indikasi dari flexibilitas dari arsitektur three-tiered ini adalah kenyataan bahwa client dan database server tidak harus merupakan suatu perangkat computer yang biasa dibayangkan. Client tidaklah harus merupakan suatu workstation. Pengguna dapat menjaloankan aplikasi dari Macintosh, atau dari tombol tekan pesawat telefon, ataupun dari Automated Teller Machine (ATM). Kesemuanya dikoneksikan kepada business prosess server yang sama, dan menjalankan suatu kumpulan aturan bisnis yang sama. Begitu juga dengan database server dapat berupa sesuatu yang bukan produk SQL. Sebab business prosess layer menyajikan pada client dengan suatu pandangan logis terhadap data, menghalangi akses langsung client dari dan ke database server. Back end server dapat berupa IMS, VSM atau suatu sumber data yang real time. Bentuk

penyimpanan data pada back end server ini tidak memberikan pengaruh pada proses bisnis. Pada terapannya, trend yang ada pada saat ini adalah menggunakan three-tier sebagai suatu front-end untuk system non-relasial, misal legacy mainframe system.

8.9.4 PROGRAM PENGEMBANG ARSITEKTUR THREE-TIERS
Ada dua pendekatan utama dalam memilih alat bantu program pengembangan ini seperti berikut. • Pendekatan satu sumber (single vendor), dengan menggunakan suatu produk tunggal, misal Forte atau Dynasty. Produk-produk ini mampu mengembangkan client, middle-tier, dan pemanggilan ke database server, serta mengelola koneksi dan komunikasi antar ketiga tier tersebut. • Pendekatan mix and match, dengan cara mengambil berbagai produk dengan vendor yang berbeda dengan melakukan pilihan yang tepat. Dan mengkonfigurasikan sehingga produk-produk tersebut dapat saling komunikasi. Permasalahan dengan satu sumber adalah satu solusi yang bersifat proprietary dan tidak terlalu “open”. Sehingga dengan menggunakan pendekatan mix and match ketergantungan kepada vendor tunggal menjadi berkurang atau tidak ada sama sekali. Kekurangan dari pendekatan mix and match adalah dibutuhkannya kemampuan dan pengetahuan yang luas bagi developer, misal pemrograman C level rendah. Juga berkurangnya flexibilitas dalam mempartisi aplikasi.

SUMBER TUNGGAL
Produk ini menyediakan lingkungan pengembangan yang konprehensif dan terintegrasi, untuk suatu aplikasi three-tiered. Keseluruhan proses seperti diesain user interface, pemrograman proses bisnis, pengaksesan database, dan komunikasi antar tier. Setiap produk memiliki feature yang hampir sama, antara lain sebagi berikut. • Kemampuan mengembangkan aplikasi pada satu platform dan memindahkan ke mesin lainnya. • Disain screen yang interaktif. • Bahasa pemrograman yang proprietary dengan embedded SQL. • Mendukung berbagai platform untuk client dan middle-tier. • Koneksi pada produk database server terkemuka. Forte dan Dynasty menyediakan perangkat bantu grafis untuk “partitioning”. Partitioning adalah proses membagi aplikasi kedalam objek-objek, dan menempatkan objek tersebut pada berbagai tier dan platform. Dengan menggunakan perangkat Bantu partitioning, dapat dispesifikasikan, apakah suatu objek ditempatkan pada client, atau middle-tier, system operasi apakah yang digunakan, dan untuk objek di middle-tier, target server. Perangkat Bantu partitioning kemudian akan menghasilkan kode C atau C++ untuk mesin target. Kemudian kode ini dipindahkan ke mesin target, dikompile, dan di link. Tetapi produk ini membutuhkan site-license untuk pengembang aplikasi. 8.9.4.1 Forte Software Inc

Dalam pengembangan program ditest dalam modus interpreter, dan setelah itu diterjemahkan ke C++, dikompile dan dilink suatu modul runtime dibutuhkan untuk menjalankan aplikasi. Pemrograman adalah berorientasi objek dan event driven. Termasuk kemampuan untuk mendefinisikan event. Ini menjadikan suatu business prosess server, untuk mengirimkan suatu event mengenai suatu kondisi bisnis yang dideteksi oleh client dan segera meresponsenya. Untuk runtime ada beberapa perangkat bantu monitoring. Misalnya untuk memonitor beban pekerjaan dan keluaran business prosess server, juga untuk membuat Bahasa Alamiine dan offline secara real time. Forte mendukung Windows, Macintosh, Motif untuk client, berbagai UNIX dan DEC untuk middle tier, dan Orase, Sybase, RDB, dan DB2/6000 untuk database server. 8.9.4.2 Dynasty Technologies Inc Dynasty Development Environment menyediakan suatu lay-out yang cepat dengan perangkat Bantu pendisain layar ala RAD (Rapid Application Development). Bahasa pemrograman adalah Objek Oriented. Satu aplikasi akan ditranslasikan ke C dan dikompilasi selama testing, begitu juga ketika akan disebarkan pada server. Client dari Dynasty dapat bekerja di Windows, Macintosh, Motif, OS/2 Presentation Manager, dan OpeBahasa Alamiook. Middle tier dapat bekerja di platform DOS, OS/2, Mac, UNIX, Netware, dan jaringan Windows-compatible lainnya. Database server dapat berupa Oracle, Sybase, Microsoft SQL Server, SQLBase, atau lainnya melalui ODBC (Open Database Connectivity). 8.9.4.3 Seer Technology Inc STI menyediakan perangkat Bantu disain secara grafis, seperti Entity Relationship (ER) diagram, database diagram, dan menghasilkan aplikasi langsung dari diagram tersebut. Pemrograman yang dilakukan berbasiskan objek. Teknologi ini mendukung berbagai platform untuk client: Windows, OS / 2, AIX, Sun UNIX. Middle tier adalah OS / 2, Windows NT, dan berbagai versi UNIX. Mendukung konektivitas ke mainframe legacy system seperti CICS, IMS, dan DB2. Database server lainnya yang didukung adalah: Oracle, Sybase, Informix, dan Microsoft SQL Server. 8.9.4.4 Progress Software corporation PSC merupakan perangkat Bantu termurah, Client yang didukung adalah Windows NT, UNIX, VMS, Motif, juga sebagai middle-tier. Middle-tier lainnya yang juga didukung adalah: AS / 400, OS / 2, atau BAHASAALAMIM. Untuk database server yang didukung: PROGRESS database, Oracle, Sybase, SQLServer, DB2 / 400, RDB, RMS, dan ODBC. 8.9.4.5 Produk-produk mix and match Pada pendekatan ini digunakan produk-produk dari vendor yang digunakan sebagai komponen pembentuk struktur three-tier. Suatu masalah penting dalam mengkombinasiakn produk seperti ini adalah pengguna middleware yang akan menyatukan program-program tersebut bersama. Beberapa protocol standar yang telah

berkembang dan digunakan untuk menggabungkan berbagai produk untuk arsitektur three-tier ini. • Remote Procedures Call (RPC) - suatu teknik yang digunakan untuk suatu program di suatu platform untuk memanggil suatu prosedur yang berada di platform lainnya. Seperti halnya memanggil prosedur yang ada di library lokal. RPC merupakan istilah generik, memiliki berbagai implementasi yang berbeda. • Common Object Request Broker Architecture (CORBA) - Disusun oleh Objek Management Group (OMG). Suatu standard untuk menyebarkan objek pada berbagai platform, dan mendukung pengiriman message anatra objek tersebut. • Distributed Computing Environment (DCE) - Disusun oleh Open system Foundation (OSF). Suatu standar mengirimkan data dan message antara platform. DCE menggunakan kemampuan RPC, dan suatu directory service, dan security dan banyak hal yang lainnya. 8.9.4.6 JYACC Inc Sistem pengembang JAM menyediakan JAM / TPi untuk aplikasi three-tiered. Dapat digunakan untuk mengembangkan client dan modul business-process. JAM / TPi menterjemahkan dan menyebarkan modul proses pada tuxedo atau Encina transaction processing monitor. 8.9.4.7 Open Environment Corporation (DEC) OEC merupakan kumpulan perangkat bantu yang mempermudah pembangunan komponen pada system three tier dengan menggunakan koneksi DCE. Sebagai contoh akan menghasilkan “stub” RPC yang dapat dipanggil dari aplikasi client yang dibangun dengan menggunakan PowerBuilder, VisualBasic atau produk front-end lainnya. 8.9.4.8 Greenbrier & Russel Inc RPC Painter merupakan produk yang menjadikan OEC Entera dapat diakses secara langsung dari PowerBuilder. RPC Painter menghasilkan PowerBuilder Data Windows control yang menggantikan Data Windows standard untuk koneksi two-tier dengan suatu koneksi ke suatu server non database, seperti business process server, dengan menggunakan metoda pemanggilan DCE RPCl. Powersoft Corporation PowerBuilder telah menyediakan connection objek yang memudahkan koneksi dari client PowerBuilder ke middle-tier server atau ke PowrBuilder client lainnya. 8.9.4.9 Magna Software Corporation Magna X adalah suatu produk perangkat bantu development grafis untuk membangun middle tier pada aplikasi three tier, dapat bekerja dengan Tuxedo, Enchina atau Entera dan mendukung koneksi ke system mainframe IBM. 8.9.4.10 Novell’s Tuxedo dan Transarc’s Enchina Tuxedo dari Novell, Enchina dari IBM merupakan perangkat bantu monitor proses transaksi. Kegunaan utamanya untuk mendukung system three-tiered. Kegunaan utama

adalah untuk menyediakan suatu interface antara client dan database server pada lingkungan transaksi yang kompleks, terutama bila berbagai database terlibat. Program ini menyediakan satu pengukuran kendali, sebagai contoh transaksi silang antar server. Juga mungkin untuk menggunakan produk ini sebagai middle-tier. Sebab program aplikasi ini bersifat programmable, dan dapat deprogram untuk menerapkan aturan-aturan bisnis sehingga menjadikan program ini menjadi business process server. Berbagai produk misal, JYACC, JAM /TPI menggunakan pendekatan ini.

-oo0oo-

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->