ERD menurut chen

47
Entity Relationship Diagram (Diagram Hubungan antara Entitas) 8.1 PENGANTAR ab ini membahas bagaimana professional system menggambarkan model data secara grafik dengan menggunakan entity relationship diagram yang kadang-kadang dikenal sebagai ERD (istilah ini yang akan selalu digunakan) atau diagram ER. B 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 struktur-struktur 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? Bab 8

description

tell about entity relatioship diagram

Transcript of ERD menurut chen

Page 1: ERD menurut chen

Entity RelationshipDiagram (Diagram

Hubungan antara Entitas)

8.1 PENGANTARab ini membahas bagaimana professional system menggambarkan model data secara grafik dengan menggunakan entity relationship diagram yang kadang-

kadang dikenal sebagai ERD (istilah ini yang akan selalu digunakan) atau diagram ER.B 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 struktur-struktur 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.

Bab 8

Page 2: ERD menurut chen

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 KuliahKode_Kul Nama_MK SKS SemesterSI-140 Basis Data 4 3PA-100 Pancasila 2 1MT-140 Kalkulus 4 4

Page 3: ERD menurut chen

Tabel 8.2 Tabel / Entitas kuliah

Relasi Entitas Mahasiswa Entitas Kuliah

NIM Nama_Mhs .....14534 Yudin .....14251 Nurhasan .....14782 Yanah .....

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:

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

Kode_Kul Nama_MK ….SI-140 Basis Data ….PA-100 Pancasila ….MT-140 Kalkulus ….

Pegawai

Page 4: ERD menurut chen

DEPT.Bekerja untuk

Bekerja Utk

Jumlah

PEGAWAI

Contoh: M N

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.

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

Alat

Pegawai Pegawai

Page 5: ERD menurut chen

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.

Page 6: ERD menurut chen

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-ke-satu-ke-banyak atau N dan N untuk relasi banyak-ke-banyak).

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.

E

Page 7: ERD menurut chen

NID NID

1 1Dosen Kepala Jurusan

Gambar 8.2 (a) Diagram Kardinalitas One to One

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 MDosen Ajar Kuliah

Gambar 8.2 (b) Diagram Kardinalitas One to Many

8.3.1.3 Relasi banyak-ke-banyak (many-to-many)

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.

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.

Page 8: ERD menurut chen

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 NIM Kd_MK Kd_MK

M NMahasiswa belajar Kuliah

Gambar 8.2 (c) Diagram Kardinalitas Many to Many

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 belajar | Kuliah || Ajar | Dosen

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.

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.

Page 9: ERD menurut chen

Tabel 8.3 Tabel ERD versi Chen dan versi James MartinDASAR ARTI

Notasi 1 Notasi 2Kardinalis

1 1

1 M

M M

11

1M 01

0 0M

RelationshipClass-Subclass / Subtipe-Subtipe

ISA ISA

Kardinalitas satu-ke-satuKardinalitas satu-ke-banyakKardinalitas banyak-ke-banyak

Kardinalitas Mandatory One Kardinalitas Banyak (1,2,...M)Kardinalitas Optional 0 atau 1Kardinalitas Optional 0 atau banyak (0,1,2,...M)

Relationship Class-Subclass

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 || Disimpan Sbg 0 Copy_Film

Gambar 8.4 Diagram Kardinalitas Relasi versi James Martin

8.3.2.2 Kardinalitas minimum dan maksimum.

Page 10: ERD menurut chen

Pegawai Ditugaskanpada

Proyek

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 || Disimpan Sbg 0 Copy_Film

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 || Miliki | Riwayat Penyakit

Gambar 8.6. (a) Diagram Kardinalitas Mandatory

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

Page 11: ERD menurut chen

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.

Page 12: ERD menurut chen

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.

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.

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

NoFilm

Nama Film

Film Copy Film

NoFilm

NoCopy

Page 13: ERD menurut chen

NIM Kd_MK NID

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 Kuliah Dosen

Gambar 8.8 (a) Identifikasi entitas yang terlibat

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.

Gambar 8.8 (b) Penentuan primary key

8.4.3 MENGIDENTIFIKASI DAN MENETAPKAN SELURUH RELASI

DI ANTARA ENTITAS-ENTITAS YANG ADA FOREIGN-KEY- NYA 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

Mahasiswa Kuliah Dosen

Page 14: ERD menurut chen

tidak memakan ruang penyimpanan data. Untuk itulah, relasi-relasi yang sifatnya tidak langsung harus ditiadakan.

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 RELASI

UNTUK SETIAP 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.

Gambar 8.8(D-3) Penentuan derajat kardinalitas relasi

8.4.5 MELENGKAPI ENTITAS DAN RELASI DENGAN ATRIBUT-

ATRIBUT 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

NIM

Kd_MK Kd_M

K

NID NID

Mahasiswa Belajar

Kuliah Ajar Dosen

NIM

Kd_MK

Mahasiswa Belajar

Kuliah Ajar Dosen

NIM

NIM

Kd_MK Kd_M

K

Kd_MK NID NID

Page 15: ERD menurut chen

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.

N N N 1

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 LANJUT8.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 dapat berfungsi sebagai key, yang benara-benar dapat menjamin keunikan entitas di dalamnya.

Contoh:

Mahasiswa Belajar

Kuliah Ajar Dosen

NamaMhs

Alm_Mhs

NimNim

Tgl_lhr

Mahasiswa

Memiliki

Menye-nangi

Nim

Nama_Ortu Orang_Tua

Hobby

HobyHoby

Alm_Ortu

Nama_Ortu

Page 16: ERD menurut chen

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:

Gambar 8.11 Diagram Sub Tipe Entity8.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’.

NID NID

Dosen

ISA

Pangkat

Nik

Tgl_Msk

Dosen_Tetap Dosen tidak_Tetap

Alm_Kan

Nama_Kan

Kode_kul

Kode_kul Nama_do

s

Nama_dos

Kuliah Peng-

ajaran

Dosen

Kode_ruang Waktu

Page 17: ERD menurut chen

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:

Gambar 8.13 Diagram Relasi Ganda

Ruang

Kode_ruangNama_ruan

g

Kapasitas

NID Kd_MK

Ajar

Tempat Waktu Dosen

kuasai

Kuliah

NID Kd_MK

Page 18: ERD menurut chen

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.

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.

Dosen

ISA

Dosen tetap Dosen tdk tetap

Mahasiswa

ISA

Mahasiswa D3 Mahasiswa S1

MahasiswaBelajar

Kuliah

Kd_MK

NIM

Page 19: ERD menurut chen

Gambar 8.15 Diagram Agregasi8.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.3Pda 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

@NO-SURAT NIKAHNO.KTP-SNAMA-S SUAMITPT-L-STGL-L-S

@NO-SURAT NIKAH

NO.KTP-I ISTRI

Ajar

NilaiKode_Pra

Kuliah

Kode_PraNama_Pra

Juml_jam

SUAMI

Kawin

@NO-SURAT NIKAHNO.KTP-SNAMA-STPT-L-STPT-L-S

@NO-SURAT NIKAHNO.KTP-INAMA-ITPT-L-ITGL-L-I

TGL-KAWIN

Page 20: ERD menurut chen

NAMA-ITPT-L-ITGL-L-ITGL-KAWIN

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

Penggabungan relasi KAWIN ke entity SUAMI

@NO-SURAT NIKAHNO.KTP-SNAMA-S SUAMITPT-L-STGL-L-S

@NO-SURAT NIKAH

NO.KTP-I ISTRINAMA-ITPT-L-ITGL-L-ITGL-KAWIN

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.

@NO_PEG PEGAWAINAMA

@KD_PROY PROYEK

ISTRI

SUAMI

Kawin

ISTRI

@NO-SURAT NIKAHNO.KTP-INAMA-ITPT-L-ITGL-L-I

@NO-SURAT NIKAHNO.KTP-INAMA-ITPT-L-ITGL-L-ITGL-KAWIN

PEGAWAI

KERJA

PROYEK

@NO_PEG@ @KD_PROYNAMA

@KD_PROYTGL_MULAIBIAYA

Page 21: ERD menurut chen

TGL_MULAI BIAYA

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.

@KD_PEL PELANGGAN NAMA

@ @[ @KD_PEL] @ @[ @KD_BRG] BELI JUMLAH

@KD_BRG BARANG NAMA_BRG HARGA_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 ‘@@’.

BELI

PROYEK @KD_BRGNAMA_BRGHARGA_BRG

PELANGGAN @KD_PELNAMA

@ @[ @KD_BRG@ @[ @KD_BRG]JUMLAH

Page 22: ERD menurut chen

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 tekni-teknik 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. Relasi-relasi 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).

Alamat

Nama

Kota

KodePos

Discount

NoPelanggan Pelanggan

Page 23: ERD menurut chen

(a) ERDpelanggan No_Pelanggan Nama Alamat Kota Kode Pos DiscountA1273 Toko ABC Jl.RST No.3 Solo 20122 5%A6390 PT.Jali JL. XAB No.12 Jakarta 14440 3%..........

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

(a) ERD dengan Kardinalitas Relasi 1 : M

PelangganNo_Pelanggan Nama Alamat Kota Kode Pos Discount

A1273 Toko ABC Jl.RST No.3 Solo 20122 5%

No_Pelanggan

Kota

Discount

Nama

KodePos

Alamat

Pelanggan Beri

No_Pelanggan

TglPesanan

TglKirim

Pelanggan

Page 24: ERD menurut chen

A6390 PT.Jali JL. XAB No.12 Jakarta 14440 3%..........

Pesanan No_Pesanan TglPesanan TglKirim No Pelanggan

57192 12/04/95 19/04/95 A127360723 21/05/95 28/05/95 A639070112 07/08/95 14/08/95 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.

0

___

TglPesananNoPesanan TglPesana

n

Pesanan

Minta Atubut lainnya

NoProduk Produk

Page 25: ERD menurut chen

(a) ERD

Pesanan No Pesanan TglPesanan TglKirim

57192 12/04/95 19/04/9560723 21/05/95 28/05/9570112 07/08/95 14/08/95

Jenis Pesanan (berasal dari relationship Minta)No Pesanan No Produk Jml Pesanan

60723 M120 360723 B261 4

Produk No Produk Keterangan Ruang Antribut lainnya

M120 Tas G001 ................B261 Karpet G002 ................F145 Lemari F005 ................

(b) Relasi

Gambar 8.21 Merepresentasikan Relationship M:N

8.9 APLIKASI ERD8.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

Ruang Keterangan

Page 26: ERD menurut chen

Front End Back End User Interface 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.

Front End Middle Tier Back End User Interface Business Rules 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:

Client

Server

Client

Server

BussinessProcessServer

Page 27: ERD menurut chen

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.

Client

Page 28: ERD menurut chen

Back End Database Management

Gambar 8.24 Stored Procedures pada Database 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.

Client

Client

Stored DatabaseProcedures Server

Client

Client

Client

BussinessProcessServer

BussinessProcessServer Database

Server

Database Server

Page 29: ERD menurut chen

GUI SP Back End Client Database Management

GUI SP Client

GUI : Graphical User Interface GUI SP SP : Stored Precedures

Client

Gambar 8.26 Arsitektur Two-tiered dengan stored procedures pada client

Suatu kemampuan yang berharga dari arsitektur three-tier ini adalah kemampuan untukmendukung 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.

Page 30: ERD menurut chen

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

Page 31: ERD menurut chen

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

Page 32: ERD menurut chen

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-