7

BAB 2

LANDASAN TEORI

2.1 Database

Database adalah kumpulan relasi logikal dari data/deskripsi data yang

dapat digunakan bersama dan dibuat untuk memperoleh informasi yang

dibutuhkan oleh perusahaan (Connolly, 2002, p14). Selain itu, database dapat

diartikan sebagai kumpulan data tetap yang dapat digunakan bersama dan saling

berhubungan (Mannino, 2001, p4).

Sehingga dapat disimpulkan bahwa database merupakan suatu kumpulan

datadata yang berhubungan satu sama lainnya dan dapat digunakan bersama

untuk suatu kepentingan.

Gambaran database dapat dilihat pada Gambar 2.1, dimana perusahaan

telekomunikasi diambil sebagai contoh dengan memiliki entity, relationships dan

proses yang meliputinya dalam satu kesatuan database.

Entitas:

Pelanggan, pembayaran, Penggunaan

Relationships: Tagihan dikirim ke

pelanggan, pelanggan membuat pembayaran, dan pelanggan menggunakan pulsa telepon

Tagihan Proses pembayaran

Pelayanan Registrasi

PembacaanJumlah Pulsa

Gambar 2. 1 : Contoh Database dari Perusahaan Telekomunikasi

8

2.2 Model Relational

2.2.1 Sejarah Model Data Relational

Model relasional pertama kali diajukan oleh E. F. Codd dalam

penelitiannya yang berjudul A relational model of data for shared data banks

(Codd, 1970). Saat ini penelitian itu diterima sebagai dasar dari suatu sistem

database, walaupun model set-oriented telah diajukan terlebih dahulu

sebelumnya (Childs, 1968). Inti dari model relasional adalah sebagai berikut:

- Memungkinkan adanya independensi data tingkat tinggi. Dalam arti aplikasi

tool/alat bantu tidak akan memberi dampak pada representasi data internal.

- Untuk menyediakan dasar substansial untuk mengatasi data semantik,

konsistensi dan redudansi, yang pada laporan penelitian E. F. Codd disebut

dengan konsep relasi normalisasi yang artinya dalam relasi tersebut tidak

boleh ada suatu kelompok perulangan.

- Memungkinkan ekspansi dari set-oriented DML (Data Manipulation

Languages)

Walaupun awal ketertarikan pada model relasional berasal dari berbagai

arah, akan tetapi penelitian paling signifikan yang dilakukan terdapat pada tiga

proyek dengan perspektif yang berbeda. Proyek pertama yaitu pada IBM San

Joses Research Laboratory di California, dimana prototipe dari relasional

DBMS System R dikembangkan seiring akhir 1970an. Proyek ini didesain untuk

membuktikan kepraktisan model relasional dengan menyediakan implementasi

dari struktur data dan operasi. Selain itu juga membuktikan bahwa model

relasional adalah suatu sumber dari informasi yang sangat baik tentang

9

implementasi seperti manajemen transaksi, concurency control, teknik recovery,

query optimization, keamanan data dan integritas, faktor manusia dan pengguna

interface dan proyek ini mengawali publikasi penelitian-penelitian pada

pengembangan prototipe yang lain. Proyek System R memiliki dua inti

pengembangan, yang pertama adalah pengembangan dari struktur bahasa query

yang dinamakan SQL (dibaca S-Q-L, atau See-Quel), yang secara formal

menjadi ISO (International Organization for Standarization) dan de facto menjadi

bahasa standar untuk relasional DBMS (Data Base Management System).

Sedangkan yang kedua adalah produksi dari berbagai produk relasional DBMS

(Data Base Management System) diproduksi seiring akhir 1970an dan 1980an,

sebagai contoh DB2 dan SQL/DS yang dikeluarkan oleh IBM dan Oracle yang

dikeluarkan oleh Oracle Corporation.

Pada proyek kedua terjadi suatu perkembangan yang signifikan pada

model relasional yaitu INGRES (Interactive Graphics Retrieval System) di

University of California di Berkeley, yang saat itu aktif pada waktu yang

bersamaan dengan proyek System R. Proyek INGRES terlibat pada

pengembangan prototipe RDBMS (Relational Data Base Management System),

yang berkonsentrasi pada tujuan yang sama dengan System R. Penelitian ini

mengawali suatu versi akademik dari INGRES, dimana yang dikontribusikan

untuk apresiasi umum dari konsep relasional dan menghasilkan produk komersial

INGRES yang dikeluarkan Relational Technology Inc. (sekarang INGRES 2 dari

Computer Associates) dan Inteligent Database Machine dari Brittonlee Inc.

Proyek ketiga adalah Peterlee Relational Test Vehicle di IBM UK

Scientific Centre in Peterlee (Todd, 1976). Proyek ini lebih berorientasi pada

10

teoritikal dibandingkan proyek System R dan INGRES. Pada prinsipnya,

penelitian ini ditujukan kepada proses query, optimisasi, dan ekstensi fungsional.

Sistem komersial yang didasarkan pada model relasional mulai muncul

pada akhir 1970 dan pada awal 1980. Terdapat ratusan macam RDBMS

(Relational Data Base System) untuk lingkungan mainframe dan PC, walaupun

banyak diantaranya yang tidak mengikuti definisi dari model relasional tersebut.

Contoh dari RDBMS (Relational Data Base Management System) berbasis PC

yaitu Accses dan FoxPro yang dikeluarkan oleh Microsoft, Paradox oleh Corel

Corporation, InterBase dan BDM oleh Borland dan yang terakhir R:Base oleh

R:BASE Technology. Seiring dengan kepopularitasan dari model relasional,

banyak sistem non-relasional yang kini dilengkapi dengan relasional pengguna

interface terlepas dari model yang ada. Computer Associates DBMS yang

merupakan jaringan prinsip dari DBMS (Data Base Management System) telah

menjadi CA-IDMS SQL, yang mendukung view data relasional. Pada mainframe

DBMS (Data Base Management System) lain, yang mendukung beberapa fitur

relasional adalah Model 204 milik Computer Corporation of America dan

ADABAS milik Software AG. Beberapa ekstensi dari model data relasional telah

diajukan, sebagai contoh ekstensi pada:

- Pengambilan arti data lebih dekat lagi (contohnya, Codd, 1979)

- Mendukung konsep yang berorientasi objek (contohnya, Stonebraker dan

Rowe, 1986)

- Mendukung kemampuan deduktif (contohnya, Gardarin dan Valduriez,

1989).

11

2.2.2 Pengertian Model Relasional

Model data relasional didasari oleh suatu konsep hubungan matematika,

dimana di dalam model data relasional, data dan hubungan yang ada diantaranya

direpresentasikan dengan menggunakan tabel-tabel, yang memiliki sejumlah

kolom dengan nama yang unik (Connolly, 2002, pp45-46, p71 ). Tabel 2.1 dan

Tabel 2.2 adalah contoh dari model data relasional.

Tabel 2. 1 : Tabel Mahasiswa

NIM kd_mtk Nama Alamat M001 T001 Agus Jl. Bunga No. 1 M002 T002 Budi Jl. Pemuda No. 3 M003 T003 Ratna Jl. Jeruk No. 23 M004 T001 Isak Jl. Manggis No 156

Tabel 2. 2 : Tabel Kuliah

kd_mtk Fakultas

T001 Teknik Informatika T002 Akuntansi T003 Hukum

Sebagai contoh pada Tabel 2.1 mahasiswa dengan NIM M001 adalah

Agus dengan kd_mtk T001, dimana pada Tabel 2.2 diketahui T001

merupakan Fakultas Teknik Informatika. Jadi kedua tabel di atas dapat dikatakan

saling berhubungan atau antara mahasiswa dan kuliah memiliki suatu relasi.

Karena kedua tabel tersebut tidak memiliki explicit link yang lain, maka kd_mtk

yang berada pada Tabel 2.1 dan kd_mtk yang berada pada Tabel 2.2 adalah

sama.

12

2.2.2.1 Struktur Data Relasional

Data relasional tersusun atas beberapa bagian sehingga membentuk

kesatuan data relasional. Struktur yang menyusunnya adalah sebagai berikut:

a. Relasi

Relasi merupakan sebuah tabel yang tersusun atas columns

(kolom-kolom) dan rows (baris-baris) (Connolly, 2002, p72). Sebuah

RDBMS (Relational Data Base Management System) dibutuhkan hanya

karena agar pengguna dapat melihat data dalam bentuk tabel. Namun

persepsi ini hanya dapat dilihat pada struktur database logikal, yaitu

eksternal dan level konseptual dari arsitektur ANSISPARC. Namun

tidak dapat dilakukan pada struktur database fisikal, dimana pada tahap

ini dapat diimplementasikan dengan struktur penyimpanan yang

bervariasi.

b. Atribut

Atribut merupakan columns (kolom-kolom) dari suatu relasi

(tabel) (Connolly, 2002, p72). Dalam model relasional, relasi merupakan

informasi tentang objek yang butuh direpresentasikan ke dalam database.

Sebuah relasi direpresentasikan sebagai tabel 2 dimensi, dimana baris

dari tabel berkorespondensi pada records individual dan kolom dari tabel

berkorespondensi dengan atribut.

c. Domain

Domain merupakan himpunan nilai dari satu atau lebih atribut

(Connolly, 2002, p172). Domain terdiri dari 2 bagian yaitu nama domain

13

(Domain Name) dan definisi dari domain (Domain Definition). Nama

domain digunakan untuk menjelaskan lebih lanjut arti nama dari atribut

atau informasi apa yang ada di dalam atribut itu, contohnya atribut DOB

maka nama domain-nya adalah Date of Birth menjelaskan bahwa DOB

berisi informasi data kelahiran. Sedangkan definisi dari domain (Domain

Definition) berisi nilai apa yang diperbolehkan untuk mengisi atribut

tersebut, contohnya Alamat dengan nama domain alamat tempat tinggal,

dan definisi domain-nya adalah character, 50, yang artinya field alamat

diisi alamat tempat tinggal dan hanya boleh diisi tipe data karakter dan

sebanyak 50 kata.

d. Tuple

Tuple merupakan baris dari suatu relasi atau tabel (Connolly,

2002, p73). Seperti contoh pada tabel Mahasiswa dimana setiap tuple dari

datanya memiliki 2 nilai. Dalam struktur sebuah relasi spesifikasi domain

dan batasan lain yang mungkin dalam suatu nilai disebut intension,

sedangkan yang dapat berubah sewaktu-waktu disebut extension.

e. Degree

Degree merupakan banyaknya atribut atau kolom pada suatu tabel

(Connolly, 2002, p174). Derajat ini dibagi menjadi beberapa macam yaitu

unary artinya derajatnya satu, artinya setiap tuple memiliki satu nilai

(one-tuple), binary untuk derajat dua, tenary untuk derajat tiga dan n-ary

untuk derajat yang lebih dari tiga. Derajat (degree) merupakan properti

dari intension.

14

f. Cardinality

Cardinality merupakan banyaknya tuple atau baris pada suatu

tabel (Connolly, 2002, p74). Kardinalitas merupakan properti dari

extension karena dapat berubah-ubah. Kardinalitas berubah ketika

jumlah baris (tuple) berubah, misal ditambah atau dihapus.

Gambar 2. 2: Instansi dari relasi Branch dan Staff (Connolly,p73).

g. Relasional Database

Koleksi dari relasi-relasi yang telah dinormalisasi dengan nama

relasi yang berbeda (Connolly, 2002, p74). Database relasional berisi

relasi yang terstruktur dengan tepat. Terstruktur yang dimaksud ini adalah

normalisasi.

15

2.2.2.2 Relasi Matematika

Agar dapat lebih mengerti apa yang dimaksud dengan relasi maka

diperlukan pengkajian ulang dari beberapa konsep matematika. Sebagai contoh,

dimisalkan ada dua buah set, D1 dan D2, dimana D1 ={2,4} dan D2 = {1,3,5}.

Produk kartesian dari dua buah set tersebut dapat ditulis D1 X D2 dimana set dari

seluruh pasangan yang dihasilkan memiliki urutan elemen pertama adalah

member dari D1 dan elemen ke dua adalah member dari D2. Ada cara alternatif

untuk mengkombinasikan elemen- elemen ini :

D1 X D2 = {(2.1),(2.3),(2.5),(4.1),(4.3),(4.5)}.

Subset dari produk kartesian ini adalah sebuah relasi. Sebagai contohnya

dapat diproduksi sebuah relasi R dimana :

R = {(2,1),(4,1)}.

Jika urutan pasangan yang ada di dalam suatu relasi ingin dispesifikasi

maka dapat diberikan beberapa kondisi sebagai seleksi. Contohnya jika

diinginkan sebuah relasi R yang berisi pasangan dimana elemen kedua adalah

satu maka R dapat ditulis dengan cara:

R ={(x,y) | x D1 ,y D2,dan y=1}.

Dengan menggunakan set yang sama dapat juga dibuat relasi yang lain, S,

dimana elemen pertama adalah dua kali elemen keduanya. Maka S dapat ditulis

dengan cara:

S ={(x,y) | x D1 , y D2, dan x = 2y}.

Notasi dari relasi tersebut dapat dikembangkan dengan menggunakan tiga

set. Misalkan terdapat tiga buah set D1 , D2, dan D3 maka kartesian produknya

16

dapat ditulis D1 X D2 X D3 dengan urutan set-nya elemen pertama berasal dari

D1 , elemen kedua berasal dari D2 dan elemen ketiga berasal dari D3. Sebagai

contoh:

D1 = {1,3}, D2 = {2,4}, D3 = {5,6}.

D1 X D2 X D3 = {(1.2.5), (1.2.6), (1.4.5), (1.4.6), (3.2.5), (3.2.6),

(3.4.5), (3.4.6)}.

Subset dari hasil produk kartesian ketiga set tersebut adalah sebuah relasi.

Dari ketiga set tersebut, notasi dapat dikembangkan dan didefinisikan untuk

relasi umum, misalnya jika terdapat n domain. Sebagai contoh terdapat n buah

set, D1 , D2,... , Dn, maka dapat dibuat produk kartesiannya dengan cara:

D1 X D2 X .... X Dn = {(d1 ,d2,...dn) | d1 D1 , d2 D2, dn Dn } atau

dapat ditulis dengan

Setiap subset dari n baris yang berasal dari produk kartesian di atas

adalah sebuah relasi dari n sets.

2.2.2.3 Relasi Database

Berdasarkan konsep database di atas, dapat didefinisikan bahwa relasi

skema adalah sebuah nama relasi yang didefinisikan oleh sebuah set pasangan

dari atribut dan nama domain (Connolly, 2002, p76). Misalkan A1, A2, ..., An

merupakan atribut dengan domain D1, D2, ..., Dn. Maka set yang dihasilkan yaitu

{A1 : D1, A2 : D2, .... , An : Dn} adalah sebuah skema relasi. Sebuah relasi R

17

didefinisikan oleh sebuah skema relasi S yang merupakan set pemetaan dari

nama atribut dengan domain korespondensinya. Jadi, relasi R merupakan set dari

n-tuples (baris) : (A1 : d1, A2 : d2, ...., An : dn) dimana d1 D1, d2 D2, .... , dn

Dn.

Setiap elemen di n-tuples terdiri dari sebuah atribut dan nilai dari atribut

tersebut. Biasanya, ketika relasi ditulis dalam bentuk tabel, maka nama atribut

akan ditulis sebagai judul kolom dan menuliskan tuple sebagai baris yang

memiliki bentuk format (d1, d2,....., dn), dimana setiap nilai diambil dari domain

yang cocok.

Dengan demikian dapat dikatakan bahwa suatu relasi dalam model

relasional adalah suatu subset dari produk kartesian dari domain suatu atribut.

Sebuah tabel merupakan suatu representasi fisik yang sederhana dari sebuah

relasi.

Sebagai contoh relasi Branch pada Gambar 2.2. dimana Branch di atas

memiliki 4 atribut yaitu branchNo, street, city, postcode, dengan domain-nya

masing-masing. Artinya relasi Branch adalah suatu hasil dari produk kartesian

domain-nya, atau set dari four-tuple lain, dimana elemen pertama adalah domain

BranchNumber, elemen kedua adalah domain dari StreetName, dan seterusnya.

Satu dari four-tuples adalah

{B005, 22 Deer Rd, London, SW14EH}

atau tepatnya

BranchNo: B05, StreetName: 22 Deer Rd, city: London, postcode:

SW14EH.

18

Bentuk di atas biasa disebut dengan instansi relasi. Tabel Branch adalah

cara paling baik untuk menuliskan seluruh bentuk relasi four- tuples.

2.2.2.4 Properti dari relasi

Sebuah relasi memiliki properti seperti di bawah ini:

- Relasi memiliki nama yang berbeda dari seluruh relasi

yang ada dalam sebuah skema relasional.

- Setiap sel dari sebuah relasi berisi tepat satu nilai tunggal

(atomik).

Contohnya ketika sebuah sel diwajibkan untuk memiliki

hanya satu nilai, maka akan tidak sah jika diisikan lebih dari

pada satu atau dua nilai ke dalam sel tersebut. Contohnya,

pada Branch isi dari postcode hanya diizinkan berisi satu nilai

dan tidak lebih. Relasi ini dikatakan ternormalisasi atau dalam

format normal 1 (first normal form).

- Setiap atribut memiliki nama-nama yang berbeda

- Nilai dari suatu atribut adalah berasal dari domain-nya.

Contohnya pada tabel Branch, branchNo dengan domain

branchNumber harus berisi nomor branch dan tidak diijinkan

berisi postcode.

- Setiap baris selalu berbeda, tidak ada baris yang

terduplikasi

- Urutan dari atribut tidak boleh signifikan

19

Pada umumnya urutan dari penempatan kolom tidak

berpengaruh. Misalnya pada Branch kolom city diletakan

sebelum kolom street tidak akan terlalu berpengaruh, hanya

saja akan lebih baik jika kolom-kolom tersebut ditulis dalam

format alamat yang standar.

- Urutan dari baris tidak boleh signifikan (pada prakteknya

urutan akan mempengaruhi efisiensi dalam mengakses baris).

Urutan baris juga tidak berpengaruh pada arti data, sebagai

contoh dari tabel Branch, tuple B005 ditempatkan di atas

baris B004 akan tidak membawa pengaruh apa-apa (tidak

mengubah makna)

Sebagian besar dari properti yang dispesifikasi untuk hasil relasi berasal

dari properti matematika :

- Ketika produk kartesian diderivasikan dari suatu set dengan

sederhana, elemen nilai tunggal (single value) seperti integer,

setiap elemen dalam setiap baris adalah nilai tunggal.

Singkatnya setiap sel dalam relasi hanya memiliki tepat satu

nilai. Akan tetapi dalam relasi matematika tidak dibutuhkan

normalisasi. Dan kelompok perulangan untuk

menyederhanakan suatu model data relasional tidak

diperbolehkan.

- Dalam sebuah relasi, nilai yang mungkin pada posisi yang

diberikan akan dijelaskan oleh set atau domain, dimana posisi

20

yang telah didefinisikan. Dalam sebuah tabel nilai dari setiap

kolom harus berasal dari domain attribute yang sama.

- Dalam sebuah set tidak ada elemen yang diulang. Demikian

pula dalam sebuah relasi tidak ada baris yang duplikat atau

berulang.

- Sebuah relasi adalah sebuah set, dimana urutan dari elemen-

elemennya tidak bersifat signifikan. Oleh karena itu dalam

sebuah relasi, urutan dari baris adalah tidak penting.

Walau bagaimanapun dalam sebuah relasi matematika, urutan elemen

dalam suatu baris sangat penting. Sebagai contoh dalam relasi matematika (1.2)

tidak sama artinya dengan (2.1).

2.2.2.5 Kunci-kunci relasional (Relational Keys)

Sebagaimana telah disebutkan di atas, bahwa tidak ada baris (tuple) yang

berulang dalam sebuah relasi. Oleh karena itu, dibutuhkan untuk mampu

mengidentifikasikan satu atau lebih atribut yang secara unik mengidentifikasikan

setiap baris dalam suatu relasi.

a. Superkey

Sebuah atribut atau set dari atribut-atribut, yang secara unik

mengidentifikasikan sebuah baris (tuple) dalam sebuah relasi

(Connolly, 2002, p78).

b. Candidate key

Adalah sebuah superkey yang tidak secara tepat sebuah subset

sebuah superkey dalam suatu relasi (Connolly, 2002, p78).

21

Dalam arti kata lain, candidate key adalah key yang mungkin

untuk menjadi suatu primary key. Sebuah candidate key, K,

untuk sebuah relasi R memiliki dua properti :

- Bersifat unik (uniqueness = dalam setiap baris dari setiap

R, nilai dari K secara unik mengidentifikasikan baris

tersebut.)

- Ireducibility, tidak secara tepat subset dari K yang

memiliki property unik.

Ketika sebuah key terdiri dari lebih dari satu atribut maka key

tersebut disebut composite key.

c. Primary key

Candidate key yang dipilih untuk mengidentifikasikan baris

secara unik dalam sebuah relasi (Connolly, 2002, p79).

Candidate key yang tidak terpilih sebagai primary key disebut

alternate key.

d. Foreign key

Sebuah atribut atau set dari atribut-atribut, dimana suatu relasi

yang cocok dengan candidate key dari beberapa relasi

(Connolly, 2002, p79).

2.2.3 Integritas Relasional

Data model memiliki dua bagian, yaitu bagian manipulasi yang

mendefinisikan tipe-tipe operasi yang diijinkan pada data dan sebuah set aturan

integritas, dimana data diyakinkan adalah akurat.

22

Sejak setiap atribut memiliki domain yang berasosiasi, ada batasan

(batasan domain) aturan bentuk pada set dari nilai-nilai yang diijinkan untuk

atribut dari suatu relasi. Ada dua aturan integritas, dimana ada batasan atau

aturan untuk menampilkan semua instansi dari database. Dua aturan utama

untuk model relasional dikenal sebagai integritas entitas (entity integrity) dan

integritas referensial (referential integrity). Sebelumnya perlu dipahami dahulu

konsep daripada nulls, untuk mengerti integritas relasional.

2.2.3.1 Nulls

Menunjukan sebuah value atau nilai untuk sebuah atribut yang isinya

tidak diketahui atau tidak dapat dipakai untuk baris ini. Bagaimanapun null tidak

dapat disamakan dengan nilai nol (zero numeric) atau kata yang berisi spasi-

spasi, nilai nol dan spasi adalah nilai, tapi null menunjukan ketidakadanya

sebuah nilai. Oleh karena itu, nulls harus dibedakan dari nilai yang lain. Kadang

menggunakan istilah null Value, bagaimanapun null bukan sebuah nilai tapi

merepresentasikan ketidakadanya sebuah nilai, istilah nilai null adalah tidak

baik.

2.2.3.2 Integritas Entitas

Aturan integritas pertama adalah ditujukan untuk primary key. Integritas

entitas adalah tidak adanya atribut dari primary key yang bernilai null di dalam

relasi dasar (Connolly, 2002, p82).

Primary key merupakan cara minimal yang digunakan untuk

mengidentifikasikan baris secara unik. Ini berarti tidak ada subset dari primary

23

key yang mampu untuk memberikan identifikasi unik dari baris. Jika diijinkan

adanya null di bagian mana saja dari primary key, maka dengan secara tidak

langsung menyatakan bahwa tidak semua atribut dibutuhkan untuk membedakan

baris yang satu dengan baris yang lain, dimana hal ini merupakan hal yang

bertolak belakang dengan definisi dari primary key. Sebagai contoh, jika dalam

relasi Branch yang memiliki primary key berupa branchNo, tidak dibolehkan

untuk memasukan baris ke dalam relasi Branch dengan nilai null ke atribut

branchNo. Contoh lainnya seperti pada Tabel 2.3, dengan melihat composite

primary key di dalam relasi Viewing, yang terdiri dari clientNumber (clientNo)

dan propertyNumber (propertyNo), tidak diijinkan untuk memasukkan baris ke

dalam relasi Viewing dengan nilai Null baik untuk atribut clientNo ataupun

atribut propertyNo, bahkan untuk kedua atribut tersebut.

Tabel 2. 3 : Relasi viewing (Connolly,p80)

clientNo PropertyNo viewDate comment CR56 PA14 24-May-01 Too small CR76 PG4 20-Apr-01 Too remote CR56 PG4 26-May-01 CR62 PA14 14-May-01 No dining room CR56 PG36 28-Apr-01

2.2.3.3 Integritas Referensial

Aturan integritas kedua ditujukan untuk foreign keys. Integritas

referensial adalah dimana jika sebuah foreign key yang ada dalam sebuah relasi,

maka salah satu dari nilai foreign key tersebut harus cocok pada sebuah nilai

candidate key dari beberapa baris dalam home relasi atau nilai foreign key harus

24

semuanya null (Connolly, 2002, p83). Sebagai contohnya, branchNo dalam relasi

Staff dimana sebuah foreign key ditargetkan ke atribut branchNo dalam home

relasi, Branch. Dimana tidak mungkin untuk membuat sebuah Staff record

dengan noBranch B025, jika sebuah record untuk branchNo B025 dalam

relasi Branch belum ada. Jadi harus dapat dibuat sebuah record Staff dengan

branchNo yang bernilai null, untuk memenuhi situasi dimana sebuah member

baru dari staff diikutkan oleh perusahaan tetapi belum diberikan keterangan

kepada kantor cabang.

2.2.3.4 Batasan Kegiatan (Enterprise Constraint)

Aturan tambahan yang dispesifikasikan oleh pengguna atau database

administrator dari sebuah database (Connolly, 2002, p82). Ini juga

memungkinkan pengguna menambahkan ketentuan batasan yang harus dipenuhi

pada data. Sebagai contoh jika ada sebuah kelebihan limit dari 20 (an upper limit

of 20) yang diletakkan pada nomor dari Staff yang bekerja pada kantor cabang,

kemudian pengguna harus dapat menspesifikasikan dan mengharapkan DBMS

dapat menjalankannya. Dalam kasus ini, tidak mungkin ditambahkan sebuah

member baru dari staff pada cabang yang diberikan pada relasi Staff jika nomor

pada Staff saat ini diberikan kepada cabang adalah 20.

2.2.4 Views

Di dalam arsitektur 3 level ANSI-SPARC, eksternal view digambarkan

sebagai struktur dari database yang berhubungan dengan pengguna. Akan tetapi

di dalam model relasional, view merupakan virtual atau relasi turunan. Sebuah

25

relasi yang tidak perlu ada dengan cara sendiri tetapi mungkin diturunkan secara

dinamik dari satu atau lebih relasi dasar. Jadi model eksternal dan mengandung

baik berupa relasi konseptual level maupun view yang diturunkan dari relasi

dasar.

2.2.4.1 Terminology

Relasi dasar (base relation) merupakan suatu nama bagi relasi yang

berkorespondensi dengan entitas di skema konseptual, dimana tuple-tuple

disimpan secara fisik ke dalam database. Dalam hubungan dengan relasi dasar,

view dapat didefinisikan sebagai hasil dinamik dari satu atau lebih operasi

relasional di dalam relasi dasar untuk menghasilkan relasi lainnya. Atau view

merupakan relasi virtual yang tidak perlu ada di dalam database tetapi dapat

dihasilkan pada saat adanya permintaan dari pengguna yang berbeda.

View merupakan relasi yang keberadaanya dirasakan oleh pengguna,

dapat dimanipulasi jika berada di dalam relasi dasar, tetapi tidak perlu ada di

tempat penyimpanan (meskipun di definisi, hal ini disimpan di dalam katalog

sistem). Isi daripada view didefinisikan sebagai query di dalam satu atau lebih

relasi dasar. Secara otomatis, operasi pada view diterjemahkan ke dalam operasi

relasi dimana relasi itu diturunkan. View sangat dinamik, sehingga jika ada

perubahan di dalam relasi dasar, dengan segera hal ini akan berpengaruh juga

terhadap view. Jika pengguna diperbolehkan untuk melakukan perubahan pada

view, maka perubahan tersebut akan terjadi pada relasi juga.

26

2.2.4.2 Tujuan dari views

Pandangan mekanis yang diinginkan untuk beberapa alasan adalah

sebagai berikut :

- Membuat sebuah mekanis yang kuat dan keamanan

fleksibel dengan menyembunyikan bagian-bagian dari database dari

beberapa pengguna, dimana pengguna tidak tahu akan adanya

beberapa atribut atau tuple-tuple yang hilang dari pandangan.

- Pengguna diizinkan untuk mengakses data dalam sebuah

arah yang disesuaikan dengan keperluannya, sehingga data yang

sama dapat dilihat oleh pengguna yang berbeda dalam langkah-

langkah yang berbeda pada waktu yang sama.

- Dapat menyederhanakan operasi yang kompleks pada

relasi dasar. Contoh, jika sebuah pandangan didefinisikan sebagai

kombinasi (join) dari dua relasi, pengguna-pengguna dapat

melakukan operasi yang lebih sederhana pada view, dimana akan

diterjemahkan oleh DBMS (Data Base Management System) ke

dalam operasi yang sana pada operasi join.

Sebuah view harus dirancang untuk mendukung model eksternal,

sehingga pengguna akan terbiasa, sebagai contoh :

- Pengguna membutuhkan tuple Branch yang mengandung nama dari

manager-manager sama seperti atribut lainnya yang sudah ada di Branch.

View ini dibuat dengan mengkombinasikan relasi Branch dengan dibatasi

dari relasi Staff dimana posisi staff adalah Manager.

27

- Beberapa member dari Staff dapat melihat tuple-tuple Staff tanpa atribut

salary.

- Penamaan dari atribut-atribut dapat diulang atau pemesanan dari atribut-

atribut tersebut diubah. Contohnya, pengguna dibiasakan untuk memanggil

atribut branchNo dari cabang-cabang dengan nama lengkap Branch Number

dapat melihat kolom diatas.

- Beberapa member-member dari Staff dapat melihat record-record untuk

properti-properti yang telah diatur.

2.2.4.3 Pembaharuan View (updating view)

Seluruh pembaharuan pada relasi dasar dengan segera akan mengubah

view yang berhubungan dengan relasi dasar. Sama halnya jika view yang

diperbaharui, maka relasi dasar yang berhubungan akan segera berubah juga.

Bagaimanapun, ada tipe batasan untuk memodifikasi yang dibuat melalui view.

Kondisi-kondisi yang diijinkan untuk memperbaharui dengan menggunakan view

adalah sebagai berikut :

- Update diijinkan melalui view yang didefinisikan menggunakan

query sederhana yang melibatkan relasi dasar tunggal dan

mengandung baik primary key atau candidate key di dalam relasi

dasar.

- Update tidak diijinkan melalui view dengan melibatkan multiple

relasi dasar.

- Update tidak diijinkan melalui view dengan melibatkan aggregasi

atau operasi kelompok .

28

View dapat dibagi menjadi beberapa kelas, yaitu : theoretically not

updateable, theoretically updateable, dan partially updateable.

2.3 Model Entity Relationship (ER Model)

Pemodelan Entity Relationship mengacu berdasarkan top-down analisis

database desain yang dimulai dengan mengidentifikasi data-data penting yang

disebut entitas (entity) dan relasi antara data-data yang harus direpresentasikan di

dalam model.

Relasi entitas terdiri dari bagianbagian yang menyusunnya, yaitu:

2.3.1 Entity types (Tipe Entitas)

Tipe entitas adalah kumpulan objek yang mempunyai karakteristik yang

sama dimana telah diidentifikasi oleh perusahaan (Connolly,2002,p331). Selain

itu tipe entitas dapat juga dikatakan sebagai kumpulan dari entitas yang memiliki

tipe dan karakteristik yang sama (Silberschatz,2002,p27).

Dengan demikian dapat disimpulkan bahwa tipe entitas adalah kumpulan

objek-objek yang memiliki karakteristik atau properti yang sama, serta objek

yang sangat berpengaruh atau yang sangat berperan dalam setiap bisnis

perusahaan, yang kemudian digunakan untuk menyusun diagram hubungan

entitas (entity relationships). Sebuah entitas memiliki eksitensinya sendiri yang

dapat merupakan objek dengan eksistensi fisik (nyata) atau objek dengan

eksistensi konseptual (abstrak).

29

Gambar 2. 3 : Bentuk entitas (Connolly,p333).

2.3.2 Relationship types (Tipe hubungan)

Tipe hubungan adalah hubungan antar entitas (entity) yang saling

berhubungan dan mempunyai arti (Connolly,2002,p334).

Gambar 2. 4 : Tentang tipe Has relasi (Connolly,p334).

Gambar 2.4 memberikan gambaran lebih lanjut mengenai arti relasi,

dimana ada relasi antara Branch dan Staff yang dinamakan Has, jadi artinya

adalah setiap Branch (cabang) mempunyai Staff (staf atau karyawan).

Derajat dari tipe relasi

Relasi antar entitas memiliki derajat/tingkat hubungan yang disebut

dengan derajat relasi (degree of relationship), yang artinya jumlah entitas yang

30

terlibat dalam sebuah relasi. Derajat relationship terdiri dari beberapa jenis,

yaitu:

a. Binary Relationship

Relasi Binary merupakan hubungan antara dua tipe entitas atau

antara dua objek. Contoh hubungan binary adalah PrivateOwner dengan

PropertyForRent yang disebut POwns (Gambar 2.5).

Gambar 2. 5 : Relasi binary yang disebut Powns (Connolly,p336)

b. Ternary Relationship

Hubungan Ternary merupakan hubungan antara tiga tipe

entitas. Contoh hubungan Ternary yang dinamakan Registers.

Relasi ini melibatkan tiga tipe entitas yaitu Staff, Branch dan

Client. Hubungan ini menggambarkan staff mendaftarkan client

pada branch (Gambar 2.6).

Gambar 2. 6 : Gambar relasi ternary disebut Registers (Connolly,p336)

c. Quaternary Relationship

Merupakan hubungan antar empat tipe entitas. Contoh

hubungan Quaternary yang dinamakan Arranges. Relasi ini

melibatkan 4 buah entitas yaitu Buyer, Solicitor,

31

FinancialIntstuttion dan Bid. Relasi ini menggambarkan Buyer,

diberi masukan oleh Solicitor, dan didukung oleh

FinancialInstitution, melakukan penawaran (Gambar 2.7).

Gambar 2. 7 : Gambar relasi quarternary disebut Arranges (Connolly,p337)

d. Recursive Relationship

Hubungan Unary merupakan hubungan antar satu tipe entitas,

dimana tipe entitas tersebut berpartisipasi lebih dari satu kali dengan

peran yang berbeda. Unary juga bisa disebut sebagai hubungan recursive.

Contoh hubungan unary adalah entitas Staff yang berperan menjadi

supervisor dan staff yang di-supervisor-i (Gambar 2.8).

Gambar 2. 8 : Relasi rekursif disebut Supervises (Connolly,p337)

32

Gambar 2. 9 : Contoh dari entitas yang diasosiasikan pada dua

perbedaan relasi (Connolly,p338)

2.3.3 Atribut dan atribut domains

Atribut adalah karakteristik dari suatu entitas atau relasi

(Connolly,2002,p338). Setiap atribut diperbolehkan untuk memiliki nilai yang

disebut dengan domain.

Atribut domain adalah kumpulan dari nilai-nilai yang diperbolehkan

untuk satu atau lebih atribut

Ada beberapa jenis dalam atribut:

a. Simple attribute dan composite attribute

Simple attribute adalah atribut yang terdiri dari komponen

tunggal dimana atribut tersebut tidak dapat dipisahkan lagi.

Sedangkan composite attribute adalah atribut yang masih dapat

dipisahkan lagi menjadi beberapa menjadi beberapa bagian

(Silberschatz,2002,p29). Selain itu simple attribute juga dapat

dikatakan adalah sebuah atribut yang terkomposisi dari komponen

33

tunggal dan memiliki eksitensi sendiri, sedangkan composite

attribute adalah sebuah atribut yang terkomposisi dari komponen

jamak yang masing-masingnya memiliki eksitensi sendiri

(Connolly,2002,p339).

Contoh dari simple attribute adalah tanggalLahir dan

sedangkan untuk composite attribute adalah alamatMahasiswa

yang terdapat pada entitas mahasiswa karena dalam

alamatMahasiswa bisa dibagi menjadi beberapa bagian seperti

atribut street, city dan postcode.

b. Single-valued attribute dan Multi-valued attribute

Single-valued attribute adalah atribut yang memiliki satu

nilai atau mengandung satu nilai pada setiap entitas. Sedangkan

multi-valued attribute adalah atribut yang mempunyai beberapa

nilai pada setiap entitas (Connolly,2002,p339-340). Contoh dari

single-valued attribute adalah NIM, namaMhs, tanggalLahir dan

lain-lain. Sedangkan untuk multi-valued attribute, contohnya

adalah JamPelajaran, Hobi dan lain lain.

c. Derived attribute

Derived attribute merupakan atribut yang nilainilainya

diperoleh dari pengolahan atau dapat diturunkan dari atribut lain

yang berhubungan (Silberschatz,2002,p30). Namun derived

attribute juga dapat diartikan sebuah atribut yang

merepresentasikan suatu nilai yang mampu diderivasikan dari

nilai suatu atribut yang berelasi atau serangkaian atribut, yang

34

tidak berasal dari entitas yang sama (Connolly,2002,p340).

Contohnya adalah atribut umur pada entitas mahasiswa dimana

atribut tersebut diturunkan dari atribut tanggalLahir.

d. Keys

Keys terdiri dari beberapa jenis, yaitu :

- Candidate Key, yaitu jumlah minimal dari serangkaian

atribut-atribut yang dapat mengidentifikasikan setiap

kejadian/record secara unik dari suatu entitas, atau

dapat dikatakan kumpulan atribut-atribut yang

mungkin untuk memjadi primary key

(Connolly,2002,p340).

- Primary Key, yaitu Candidate key yang dipilih untuk

mengidentifikasikan setiap kejadian/record dari suatu

entitas secara unik (Connolly,2002,p341).

- Composite Key, yaitu candidate key yang terdiri dua

atau lebih atribut.

2.3.4 Entitas Kuat dan Entitas Lemah (Strong dan Weak Entity)

Entitas (entity) dapat dibedakan menjadi dua yaitu:

Strong Entity : entitas yang keberadaannya tidak tergantung kepada entitas lain (Connolly,2002,p342).

Weak Entity : entitas yang keberadaannya tergantung dari entitas lain (Connolly,2002,p343).

35

Contohnya adalah entitas dari mahasiswa dan orang tua. Dimana

mahasiswa merupakan entitas kuat, sedangkan orang tua merupakan entitas

lemah dimana keberadaan entitas orang tua tergantung dari entitas mahasiswa.

Namun entitas dapat dikatakan kuat (strong) atau lemah (weak) tergantung pada

konteks penggunaannya.

2.3.5 Atribut dalam Relasi-Relasi

Atribut juga dapat ditambahkan dalam suatu relasi. Sebagai contoh

dimisalkan suatu relasi Advertises, yang berasosiasi dengan PropertyForRent

yang ditunjukan pada Gambar 2. 10. Untuk mendata informasi tentang properti

yang diiklankan serta biayanya, maka informasi ini dapat diasosiasikan pada

entitas Advertises sebagai atribut dateAdvert (tanggal iklan) dan cost (biaya

iklan), dibandingkan dimasukan dalam entitas NewsPaper atau PropertyForRent.

Gambar 2. 10 : Gambar sebuah relasi disebut Advertises dengan atribut-atribut

date Advert dan cost (Connolly,p344)

Representasi diagramatik dari atribut dalam relasi dapat ditulis dengan

simbol layaknya suatu entitas.

36

2.3.6 Batasan struktural

Salah satu tipe utama dari batasan dalam suatu relasi adalah multiplicity.

Multiplicity adalah jumlah (range) yang mungkin dari suatu kejadian sebuah

entitas berelasi dengan kejadian tunggal dari suatu tipe entitas yang berasosiasi

melalui suatu hubungan (Connolly,2002,p344). Multiplicity adalah cara dimana

suatu entitas berhubungan, selain itu juga merupakan representasi dari kebijakan

(aturan bisnis) yang dikeluarkan pengguna atau perusahaan. Memastikan bahwa

segala halnya cocok dengan batasan perusahaan (enterprise constraints) yang

diidentifikasikan dan direpresentasikan sangatlah penting dalam bagian

pembuatan model dari suatu perusahaan.

Derajat yang umum dalam sebuah relasi merupakan derajat dua atau

binary. Tipe tipe hubungan binary adalah :

one-to-one (1:1)

Gambar 2. 11 : Gambar tentang tipe relasi Staff Manages Branch (Connolly,p345)

37

Gambar 2. 12 : Gambar tentang relasi keserbaragaman dari Staff Manages Branch

one-to-one (1:1) (Connolly,p346)

one-to-many (1 : *)

Gambar 2. 13 : Gambar tipe relasi pada Staff Oversees PropertyForRent

(Connolly,p346)

Gambar 2. 14 : Gambar tipe relasi keserbaragaman dari Staff Oversees

PeopertyForRent one-to-many (1:*) (Connolly,p347)

38

many-to-many (* : *)

Gambar 2. 15 : Gambar tipe relasi Newspaper Advertises PropertyForRent

(Connolly,p348)

Gambar 2. 16 : Gambar relasi keserbaragaman pada Newspaper Advertises

PropertyForRent many-to-many (*:*) (Connolly,p348)

Multiplicity untuk relasi yang kompleks Multiplicity untuk relasi yang kompleks yang dimaksudkan

adalah relasi yang derajatnya lebih tinggi dari binary. Multiplicity

untuk relasi yang kompleks adalah jumlah (range) kemungkinan

kejadian tipe entitas dalam sebuah relasi n-ary, dimana nilai yang

lain (n-1) tetap (Connolly,2002,p349).

Cardinality dan Participant Constraints Multiplicity terdiri dari dua batasan yang terpisah yaitu

kardinalitas (cardinality) dan partisipasi (participation). Kardinalitas

mendeskripsikan angka maksimum yang mungkin dalam suatu

39

relasi untuk sebuah entitas yang berpartisipasi dalam tipe relasi

yang dibutuhkan dan partisipasi juga mendeterminasikan apakah

satu atau hanya sebagian dari entitas yang berpartisipasi dalam

sebuah relasi (Connolly,2002,p351).

2.3.7 Masalah dalam ER model

Masalah dalam model relasi entitas (Entity Relationship) adalah yang

biasa dimaksud dengan connection traps. Jenis utama dari connection traps ini

terdiri dari dua jenis yaitu fan traps dan chasm traps.

Fan traps adalah dimana model mereprentasikan hubungan antara tipe

entitas, tetapi jalan diantara entitas tertentu sangat ambigous

(Connolly,2002,p352). Fan traps muncul dimana dua atau lebih hubungan one-

to-many (1:*) fan out dari satu entitas yang sama (Gambar 2.17).

Sebagai contoh seperti model yang direpresentasikan oleh suatu entitas

Division, dimana satu divisi mengoperasikan satu atau lebih Branch, dan satu

division memiliki satu atau lebih Saff. Namun sebuah masalah timbul ketika

ingin diketahui seorang staff bekerja di branch yang mana. Oleh karena itu, ER

model perlu direstruktur kembali, yang digunakan untuk membetulkan asosiasi

yang ada diantara entitas-entitas (Gambar 2.19).

Gambar 2. 17 : Gambar contoh fan trap (Connolly,p352)

40

Gambar 2. 18 : Gambar hubungan semantik pada ER model (Connolly,p352)

Gambar 2. 19 : Gambar model ER direstruktur untuk menghilangkan fan trap

(Connolly,p353)

Gambar 2. 20 : Gambar rangkaian semantik dari ER model (Connolly,p353)

Chasm traps adalah dimana sebuah model yang membutuhkan eksistensi

suatu hubungan antara tipe entitas, namun jalan diantara entitas tertentu tidak ada

41

(Connolly,2002,p353). Chasm traps muncul dimana satu atau lebih relasi dengan

multiplicity minimum adalah nol (0) yang merupakan optional participation

membentuk suatu bagian jalan hubungan antar entitas. Contoh yang potensial

terdapat pada relasi entitas Branch, Staff, dan PropertyForRent (Gambar

2.21). Dimana masalah ini merepresentasikan kenyataan bahwa Branch

memiliki satu atau lebih staff yang bekerja, dan staff yang telah melihat nol (0)

atau lebih properti. Masalahnya akan muncul ketika dicari tahu properti mana

yang tersedia dari setiap cabangnya. Sehingga untuk menyelesaikan masalah ini

maka perlu ditambahkan suatu entitas baru yang menghubungkan antara Branch

dan PropertyforRent. (Gambar 2.23)

Gambar 2. 21 : Gambar contoh chasm trap (Connolly,p353)

Gambar 2. 22 : Rangkaian semantik dari ER model (Connolly,p354)

42

Gambar 2. 23 : Model ER di restruktur untuk menghilangkan chasm trap

(Connolly,p354)

Gambar 2. 24 : Gambar rangkaian semantik dari model ER (Connolly,p355)

2.4 Model Enhanced Entity Relationship

2.4.1 Generalisasi/Spesialisasi (Generalization/ Specialization)

Konsep dari generalisasi/spesialisasi berhubungan dengan tipe khusus

dari entitas yang dikenal dengan nama superkelas dan subkelas, dan proses dari

turunan atribut (attribute inheritance).

43

2.4.1.1 Superkelas dan subkelas

Superkelas merupakan tipe entitas yang mengandung satu atau

lebih sub kelompok yang jelas dari suatu kejadian, dimana perlu untuk

dijelaskan di model data. Sedangkan subkelas merupakan sub kelompok

yang jelas dari suatu kejadian di dalam tipe entitas, dimana perlu

dijelaskan di model data.

Tipe entitas yang memiliki subkelas yang jelas disebut dengan

superkelas. Sebagai contoh, entitas Staff bisa diklasifikasi menjadi

Manager, SalesPersonnel, dan Secretary. Dengan kata lain, entitas

Staff ditunjuk sebagai superkelas dari subkelas Manager,

SalesPersonnel, dan Secretary.

2.4.1.2 Relasi superkelas/subkelas

Setiap member dari subkelas juga merupakan member dari

superkelas, dengan kata lain entitas di subkelas sama dengan entitas di

superkelas, hanya saja memiliki peranan yang jelas. Hubungan antara

superkelas dan suatu subkelas adalah (1:1) dan disebut sebagai relasi

superkelas/subkelas. Sebagai contoh, Staff/Manager memiliki relasi

superkelas/subkelas. Beberapa superkelas mungkin saja mengandung

subkelas yang saling melengkapi, sebagai diilustrasikan dengan anggota

dari Staff yang berupa baik Manager dan anggota dari SalesPersonal.

Contohnya, Manager dan SalesPersonnel merupakan subkelas yang

saling melengkapi dari superkelas Staff. Akan tetapi tidak semua

anggota superkelas perlu menjadi anggota dari subkelas, sebagai contoh

44

adalah anggota Staff tanpa peranan yang jelas seperti anggota Manager

atau anggota dari SalesPersonal.

Superkelas dan subkelas dapat digunakan untuk menghindari

penggambaran tipe berbeda dari Staff dengan kemungkinan atribut

berbeda dalam entitas tunggal. Contohnya, SalesPersonal bisa memiliki

atribut-atribut khusus seperti SalesArea dan CarAllowance. Jika semua

atribut Staff dan peranan khusus yang spesifik digambarkan dengan

entitas tunggal Staff, hal ini akan mengakibatkan banyak nulls untuk

peranan atribut yang spesifik. Jelasnya, SalesPersonal memiliki atribut

biasa dengan staff lainnya seperti staffNo, name, position, dan salary.

Bagaimanapun, ini merupakan atribut yang tidak berbagi yang dapat

menyebabkan masalah ketika semua anggota dari Staff akan

direpresentasikan ke dalam entitas tunggal. Hubungan juga dapat

ditunjukan dimana hanya berasosiasi dengan tipe khusus dari Staff

(subkelas) dan tidak dengan Staff secara umumnya. Sebagai contoh,

SalesPersonal bisa saja memiliki hubungan yang berbeda dimana tidak

cocok untuk semua Staff seperti SalesPersonnelUsesCar.

Untuk menjelaskan hal diatas, pada Gambar 2. 25 menunjukan

relasi AllStaff, yang mengandung rinci dari semua anggota Staff, tidak

peduli dengan posisi apa yang dipegang. Akibat dari menempatkan

semua rinci karyawan di dalam satu relasi adalah pada saat atribut yang

tepat untuk semua Staff diisi (staffNo,name,position, dan salary),

sementara yang dapat dipakai untuk peranan khusus diisi sebagian.

Contohnya, atribut berasosiasi dengan subkelas Manager (mgrStartDate

45

dan bonus), subkelas SalesPersonnel (salesArea dan carAllowance) dan

subkelas Secretary (typingSpeed) memiliki nilai untuk member di

subkelas tersebut. Dengan kata lain, atribut berasosiasi dengan subkelas

Manager, SalesPersonnel, dan Secretary adalah kosong untuk member

dari Staff yang bukan subkelas tersebut.

Dua alasan kenapa perlu dikenalkannya konsep superk

elas dan

subkelas pada ER model, yaitu : 1) dapat menghindari penggambaran

konsep yang hampir sama lebih dari sekali, sehingga perancang dapat

memakai waktu dengan baik dan membuat diagram ER dapat lebih

dibaca, 2) dapat menambah informasi semantik ke dalam bentuk desain

yang dikenal oleh banyak orang.

Gambar 2. 25 : Gambar relasi AllStaff memegang detail-detail dari semua staff

(Connolly,p361)

2.4.1.3 Attribute Inheritance

Entitas dari subkelas mewakili objek dunia nyata (real world)

yang sama seperti di superkelas dan bisa saja memiliki atribut subkelas

46

yang spesifik yang sama halnya berasosiasi dengan superkelas.

Contohnya, anggota dari subkelas SalesPersonnel inherits pada semua

atribut superkelas Staff seperti, staffNo,name, position, dan salary secara

bersama-sama dimana khususnya berasosiasi dengan subkelas

SalesPersonnel seperti salesArea dan carAllowance.

Superkelas adalah sebuah entitas yang berdiri sendiri, dan

memiliki satu atau lebih subkelas-subkelas. Entitas dan subkelas serta

superkelas dan selanjutnya disebut dengan tipe hirarki. Tipe hirarki

dikenal dengan bervariasi nama, termasuk: hirarki spesialisasi (contoh,

Manager merupakan spesialisasi dari Staff), hirarki generalisasi

(contoh, Staff merupakan generalisasi dari Manager) dan IS-A hirarki

(contoh, Manager IS-A (anggota dari) Staff).

Subkelas dengan lebih dari satu superkelas disebut sebagai

subkelas terbagi (shared subclass). Dengan kata lain, anggota dari shared

subclass harus merupakan anggota dari superkelas yang berhubungan.

Sebagai akibatnya, atribut dari superkelas diturunkan oleh shared

subclass, dimana bisa memiliki atribut tambahan sendiri. Proses ini

mengacu sebagai multiple inheritance.

2.4.1.4 Proses Spesialisasi (Specialization Process)

Spesialisasi merupakan proses memaksimalkan perbedaan antara

anggota-anggota dari suatu entitas dengan mengidentifikasi

karakterisitiknya yang berbeda. Spesialisasi menggunakan pendekatan

top-down untuk mendefinisikan suatu set dari superkelas dan subkelas

47

yang berhubungan. Ketika suatu set subkelas dari suatu entitas

diidentifikasi, atribut spesifik akan dimasukan ke setiap subkelas (jika

diperlukan), dan juga mengidentifikasi hubungan antara setiap subkelas

dengan tipe entitas lainnya atau subkelas (jika diperlukan). Contohnya

dimana akan dilakukan proses spesialisasi pada suatu entitas Staff yang

terdiri dari anggota-anggotanya, dimana perbedaan antara anggota-

anggota dari entitas ini diidentifikasi seperti anggota-anggota dengan

atribut tersendiri yaitu hubungan and/or. Staff dengan peranan tugas

sebagai Manager, SalesPersonnel, dan Secretary memiliki atribut

tersendiri dan subkelas Manager, SalesPersonnel, dan Secretary

diidentifikasikan sebagai spesialisasi dari superkelas Staff.

2.4.1.5 Proses Generalisasi (Generalization Process)

Generalisasi merupakan proses meminimalisasikan perbedaan

yang ada antara entitas dengan mengidentifikasi karakteristik yang biasa

ada. Generalisasi menggunakan pendekatan bottom-up, dimana hasil

identifikasi dari generalisasi superkelas berasal dari tipe entitas yang asli.

Sebagai contoh, ada suatu model dimana Manager, SalesPersonnel, dan

Secretary direpresentasikan sebagai tipe entitas yang berbeda. Untuk

melakukan proses generalisasi untuk entitas ini, sebelumnya harus

mengidentifikasi persamaan yang ada antara entitas-entitas tersebut

seperti atribut yang umum dan hubungan (relationship). Ternyata entitas

ini membagi atribut yang umum ke semua Staff dan kemudian

48

Manager, SalesPersonnel dan Secretary akan diidentifikasi sebagai

subkelas yang digeneralisasikan ke superkelas Staff.

Proses generalisasi juga dapat dilihat sebagai kebalikan dari

proses spesialiasasi, dan hal ini mengacu sebagai konsep

generalisasi/spesialisasi.

2.4.1.6 Diagram representasi dari generalisasi/spesialisasi

UML mempunyai sebuah notasi spesial untuk merepresentasikan

generalisasi/spesialisasi. Sebagai contoh, dengan mempertimbangkan

generalisasi/spesialisasi dari entitas Staff ke dalam subkelas-subkelas yang

merepresentasi job role. Superkelas Staff dan subkelas Manager,

SalesPersonnel, dan Secretary dapat direpresentasikan ke dalam diagram EER

(Enhanced Entity Relationship) seperti yang berada pada Gambar 2. 26 yang

menunjukan Staff superkelas dan subkelas, menjadi entitas, direpresentasikan

sebagai bujur sangkar. Subkelas dilampirkan oleh garis-garis pada sebuah

segitiga yang menunjuk ke atas superkelas.

Atribut-atribut spesifik yang diberikan pada subkelas didaftar pada

bagian bawah dari bujur sangkar merepresentasi subkelas. Sebagai contoh,

salesArea dan carAllowance atribut-atribut hanya diasosiasikan dengan subkelas

SalesPersonnel, dan tidak dapat dipakai pada subkelas Manager atau

Secretary. Dan hal ini dapat ditunjukan dengan atribut-atribut yang dispesifikasi

pada subkelas Manager (mgrStartDate and bonus) dan subkelas Secretary

(typingSpeed).

49

Atribut-atribut pada semua subkelas-subkelas secara umum pada daftar

dalam bagian lebih rendah dari bujur sangkar yang merepresentasi superkelas.

Sebagai contoh, atribut staffNo, name, position, dan salary merupakan hal

umum terhadap member dari Staff dan diasosiasikan dengan superkelas Staff.

Pada contoh Gambar 2.26 subkelas Manager direlasikan pada entitas Branch

melalui relasi Manages. Sedangkan superkelas Staff dihubungkan dengan

entitas Branch melalui hubungan Has.

Beberapa spesialisasi dapat dimiliki dari entitas yang sama berdasarkan

pada karakteristik khusus perbedaan. Sebagai contoh, spesialisasi lainnya dari

entitas Staff bisa menghasilkan subkelas FullTimePermanent dan subkelas

PartTimeTemporary, dimana membedakan antara tipe kontrak pekerjaan

(employeement contract) untuk anggota atau staff. Spesialisasi dari tipe entitas

staff menjadi peranan kerja (subclass job role) ditunjukan pada Gambar 2.27.

Sehingga dapat dilihat atribut yang spesifik pada subkelas FullTimePermanent

(salaryScale) dan (holiday Allowance) dan PartTimeTemporary (hourlyRate).

Tipe hirarki dapat dilihat pada Gambar 2.28 dimana peranan kerja

generalisasi/spesialisasi ditunjukan pada Gambar 2.26, diperluas untuk

menunjukan subkelas yang dibagi yang disebut SalesManager dan subkelas

yang disebut Secretary. Dengan memiliki subkelas sendiri disebut

AssistantSecretary. Dengan kata lain anggota dari subkelas yang dibagi,

SalesManager, harus merupakan anggota dari subkelas SalesPersonnel dan

subkelas Manager seperti halnya superkelas Staff. Sebagai akibatnya atribut

dari superkelas Staff dan atribut dari subkelas SalesPersonnel dan Manager

50

diturunkan oleh subkelas SalesManage. Dimana juga memiliki atribut tambahan

sendiri yang disebut salesTarget.

AssistantSecretary merupakan subkelas dari Secretary yang juga

merupakan subkelas dari Staff. Ini berarti bahwa anggota dari subkelas

AssistantSecretary harus menjadi anggota dari subkelas Secretary dan

superkelas Staff. Sebagai akibatnya, atribut dari superkelas Staff dan atribut dari

subkelas Secretary diturunkan dengan subkelas AssistantSecretary, yang juga

memiliki atribut tambahannya startDate.

Gambar 2. 26 : Gambar spesialisasi/generalisasi dari entitas staff (Connolly,p364)

51

Gambar 2. 27 : Gambar spesialisasi/generalisasi pada entitas staff (Connolly, p365)

Gambar 2. 28 : Gambar Spesialisasi/generalisasi pada entitas staff (Connolly,p365)

52

2.4.1.7 Batasan dalam Generalisasi/Spesialisasi (Constraints on

Generalization/Specialization)

Ada dua batasan yang bekerja pada generalisasi/spesialisasi yang

disebut dengan batasan partipasi (participation constraint) dan batasan

disjoint (disjoint constraint).

Batasan partisipasi menentukan apakah setiap anggota di

superkelas harus mengambil bagian sebagai anggota di subkelas. Batasan

partisipasi bisa berupa mandatory atau optional. Relasi

superkelas/subkelas dengan partisipasi mandatory menentukan bahwa

setiap anggota di superkelas harus juga merupakan anggota di subkelas.

Untuk merepresentasikan partisipasi mandatory, Mandatory diletakan

di kurung kurawal dimana menuju ke superkelas Gambar 2.27.

Sedangkan relasi superkelas/subkelas pada partisipasi optional

menujukan bahwa anggota tidak perlu menjadi anggota dari subkelas.

Untuk merepresentasikan partisipasi optional, Optional diletakan di

kurung kurawal dibawah segitiga dimana menuju ke arah superkelas

Gambar 2.27.

Batasan disjoint menggambarkan hubungan antara anggota-

anggota dari subkelas dan menyatakan apakah mungkin untuk anggota

dari superkelas untuk menjadi anggota dari satu atau lebih dari satu

subkelas. Batasan disjoint hanya berlaku ketika superkelas memiliki

lebih dari satu subkelas. Jika subkelas merupakan disjoint, maka entitas

hanya dapat menjadi anggota hanya dari satu subkelas. Untuk

53

merepresentasikan sebuah disjoint pada relasi superkelas/subkelas, Or

diletakan setelah batasan partisipasi di dalam kurung kurawal. Jika

subkelas bukan merupakan disjoint (nondisjoint), maka entitas dapat

menjadi anggota lebih dari satu subkelas. Untuk merepresentasikan

nondisjoint dari relasi superkelas/subkelas, And diletakkan setelah

batasan partisipasi di dalam kurung kurawal.

Batasan disjoint dan partisipasi di dalam generalisasi dan

spesialisasi adalah berbeda, dan dapat dibagi menjadi empat kategori,

yaitu: mandatory dan disjoint, optional dan disjoint, mandatory dan

nondisjoint, optional dan nondisjoint.

2.4.2 Aggregation (Agregasi)

Agregasi merepresentasikan sebuah hubungan has-a atau is-part-of

diantara para entitas dimana satu merepresentasikan whole dan yang lainnya

merepresentasikan part. Agregasi digunakan untuk menunjukan suatu

hubungan kepemilikan antara entitas-entitas, dimana salah satu entitas

menunjukan seluruh-nya dan yang satu adalah bagian dari.

54

Gambar 2. 29 : Contoh Agregation : Branch Has Staff dan Branch Offers

PropertyForRent (Connolly,p372).

2.4.3 Composition (Komposisi)

Komposisi adalah bentuk spesifik dari agregasi yang merepresentasikan

suatu asosiasi di antara entitas-entitas, dimana terdapat suatu kepemilikan yang

kuat (strong-ownership) dan coincidental lifetime antara bagian whole dan

bagian part.

Gambar 2. 30 : Contoh dari komposisi NewsPaper Displays Advert

(Connolly,p373)

55

2.4.4 Generalisasi dan spesialisasi

Konsep pada generalisasi dan spesialisasi diasosiasikan pada beberapa

tipe entitas yang khusus yang dikenal dengan superkelas dan subkelas, serta

proses dari pewarisan sifat atribut (attribute inheritance). Selain itu juga terdapat

dua tipe batasan (constraint) pada sifat relasi superkelas/subkelas yang

participation dan disjoint constraint.

Generalisasi adalah proses meminimalisasikan perbedaaan yang ada

antara entitas yang ada, suatu bentuk absraksi yang mana merupakan suatu set

objek yang mirip sebagai suatu objek tingkat tinggi (higher-level object), dengan

detail pada tingkat rendah (lower-level). Ada dua macam generalisasi yaitu :

1. Menggeneralisasi dari objek yang spesifik pada satuan seluruh

objek dengan tipe itu.

2. Menggeneralisasi dari objek yang berbeda dari suatu objek itu

sendiri atau objek tingkat tinggi.

2.5 Perancangan Database

Perancangan database atau yang biasa disebut dengan metodologi desain

database merupakan pendekatan terstruktur yang mengunakan prosedur

prosedur, teknikteknik, alatalat maupun dokumentasi tambahan untuk

mendukung dan memberi fasilitas dari desain tersebut.

Perancangan database terdiri dari 3 fase utama, yaitu:

a. Conceptual database design

56

Conceptual database design merupakan suatu proses pembuatan

model dari informasiinformasi yang digunakan pada suatu perusahaan

dan independen terhadap semua pertimbangan fisikal.

b. Logical database design

Logical database design merupakan proses dari pembuatan

sebuah model dari informasi yang digunakan pada perusahaan

berdasarkan pada model data yang spesifik (contoh: relasional), tetapi

independen terhadap pertimbangan DBMS tertentu dan fisikal lainnya.

c. Physical database design

Merupakan proses untuk menghasilkan suatu deskripsi dari

implementasi database pada penyimpanan sekunder (secondary storage),

juga mendeskripsikan relasi dasar, organisasi file, dan desain indeks yang

digunakan untuk mencapai akses yang efisien terhadap data dan batasan

integritas lainnya yang masih berhubungan serta ukuran-ukuran

keamanan.

Langkah langkah yang digunakan untuk membangun ketiga fase

tersebut akan dirinci lebih lanjut sebagai berikut:

1. Buatlah data model lokal yang konseptual untuk setiap pengguna

view.

- Identifikasikan tipetipe entitas

- Identifikasikan tipe-tipe hubungan

- Identifikasi dan hubungkan atribut-atribut dengan tipe

entitas atau tipe hubungan

57

- Tentukan domain atribut

- Tentukan atribut candidate dan primary key

- Pertimbangkan penggunaan konsep pemodelan yang

tinggi/enhanced modelling (step optional)

- Periksa model untuk redundansi

- Validasikan model lokal konseptual terhadap transaksi

pengguna

- Tinjau kembali data model lokal yang konseptual dengan

pengguna

2. Buat dan validasikan data model lokal yang logikal untuk setiap

view.

- Pindahkan fitur-fitur yang tidak kompatibel dengan model

relasional (step optional)

- Ambil hubungan untuk data model lokal yang logikal

- Validasikan hubungan menggunakan normalisasi

- Validasikan hubungan terhadap transaksi pengguna

- Tentukan batasan integritas

- Tinjau kembali model data logikal lokal dengan pengguna

3. Buat dan validasikan model data logikal yang global.

- Gabungkan model data logikal lokal menjadi model global

- Validasikan model data logikal global

- Periksa untuk pengembangan mendatang

58

- Tinjau kembali model data logikal global dengan

pengguna

4. Terjemahkan model data logikal global target DBMS.

- Desain hubungan dasar

- Desain representasi dari data yang dihasikan

- Desain batasan-batasan perusahaan

5. Desain reprensentasi fisikal

- Analisa transaksi transaksi

- Pilih organisasi file

- Pilih indeks indeks

- Perkirakan kebutuhan tempat penyimpanan data

6. Desain user view.

7. Desain mekanisme keamanan.

8. Pertimbangkan pengenalan dari redudansi terkontrol

9. Pengaturan dan pengawasan sistem operasional.

Untuk setiap superkelas atau subkelas dalam data konseptual, dapat di-

identifikasikan entitas superkelas sebagai entitas orang tua (parent) dan entitas

subkelas sebagai entitas anak (child). Ada beberapa pilihan yang dapat

digunakan untuk merepresentasikan suatu relasi semacam itu sebagai satu atau

lebih relasi. Pemilihan cara yang paling cocok untuk merepresentaikan relasi

tersebut sangat bergantung pada beberapa faktor, seperti: batasan disjoint dan

participation pada relasi subkelas atau superkelas, dengan melihat apakah

subkelas yang terlibat itu berada didalam hubungan distinct dan dengan melihat

59

jumlah dari participant yang ada di dalam relasi superkelas dan subkelas.

Panduan untuk merepresentasikan relasi superkelas atau subkelas berdasarkan

pada batasan participant dan disjoint seperti yang ditunjukan pada tabel berikut

berikut:

Tabel 2.4 : Panduan untuk relasi superkelas/subkelas berdasarkan

participation dan disjoint constraint (Connolly,p451)

Participation constraint Disjoint constraint Relations required

Mandatory Nondisjoint { And } Relasi tunggal (dengan satu atau lebih diskriminator untuk membedakan tipe dari masing-masing baris)

Optional Nondisjoint { And } Dua relasi: satu relasi untuk superkelas dan satu relasi untuk seluruh subkelas (dengan satu atau lebih diskriminator untuk membedakan tipe dari masing-masing baris).

Mandatory Disjoint { Or } Banyak relasi: satu relasi untuk setiap superkelas atau subkelas yang dikombinasikan.

Optional Disjoint { Or } Banyak relasi: satu relasi untuk superkelas dan satu untuk setiap subkelas.

Option 1 Mandatory, nondisjoint AllOwner (ownerNo, address, telNo, fName, lName, bName, bType, contactName, pOwnerFlag, bOwnerFlag) Primary Key ownerNo Option 2 Optional, nondisjoint Owner (ownerNo, address, telNo) Primary Key ownerNo OwnerDetails (ownerNo, fName, lName, bName, bType, contactName,

60

pOwnerFlag, bOwnerFlag) Primary Key ownerNo Foreign Key ownerNo references Owner (ownerNo) Option 3 Mandatory, disjoint PrivateOwner (ownerNo, fName, lName, address, telNo) Primary Key ownerNo BusinessOwner (ownerNo, bName, bType, contactName, address, telNo) Primary Key ownerNo Option 4 Optional, disjoint Owner (ownerNo, address, telNo) Primary Key ownerNo PrivateOwner (ownerNo, fName, lName) Primary Key ownerNo Foreign Key ownerNo references Owner (ownerNo) BusinessOwner (ownerNo, bName, bType, contactName) Primary Key ownerNo Foreign Key ownerNo references Owner (ownerNo)

Gambar 2. 31 : Beragam representasi dari Owner superkelas/subkelas

berdasarkan participant dan disjoint constraints (Connolly,p451)

Sebagai contoh, entitas Owner dalam relasi superkelas atau subkelas

yang ditunjukan pada Gambar 2.35. Dari gambar Tabel 2.4 ada beberapa cara

untuk merepresentasikan relasi tersebut seperti yang ditunjukan pada Gambar

2.36. Range pemilihan dari penempatan seluruh atribut ke dalam satu relasi

dengan dua diskriminator pOwnerFlag dan bOwnerFlag, mengindikasikan

apakah sebuah baris dari tabel merupakan kepunyaan dari suatu subkelas (option

1), dan untuk membagi atribut ke dalam tiga relasi (option 4).

Dalam kasus ini, representasi yang paling cocok untuk relasi superkelas

atau subkelas dijelaskan dengan constraint relasi tersebut. Dari Gambar 2.35

61

relasi superkelas Owner memiliki hubungan dengan subkelas-nya yang bersifat

mandatory dan disjoint, dimana setiap member dari superkelas Owner harus

menjadi member dari satu subkelas-nya (PrivateOwner atau BusinessOwner)

tetapi tidak dapat menjadi member dari keduanya. Oleh karena itu, dipilih option

3 sebagai representasi terbaik dari relasi ini dan membangun suatu relasi yang

terpisah untuk merepresentasikan setiap subkelas dan memasukkan sebuah

salinan (copy) atribut primary key dari setiap superkelas pada masing-masingnya.

Perlu ditekankan bahwa pada Gambar 3.36 hanya merupakan panduan

saja dan masih banyak faktor lainnya yang mempengaruhi pilihan akhir. Sebagai

contoh, dengan option 1 (mandatory, disjoint) dipilih untuk menggunakan dua

diskriminator untuk membedakan apakah sebuah baris (tuple) adalah anggota

dari suatu subkelas. Secara bersamaan, suatu cara untuk merepresentasikan ini

adalah untuk memiliki satu diskriminator yang membedakan apakah suatu baris

(tuple) merupakan sebuah member dari PrivateOwner, BusinessOwner, atau

kedua-duanya. Secara singkat dapat dibedakan dengan menggabungkan

diskriminator menjadi satu dan diuji secara sederhana apakah satu dari atribut

bersifat unik pada sebuah subkelas yang tidak dapat bernilai null (non null),

untuk menjelaskan apakah suatu baris (tuple) merupakan bagian dari suatu

subkelas. Dalam kasus ini, harus dapat dipastikan bahwa atribut yang diuji

adalah atribut yang diperlukan (maka tidak boleh null).

62

Gambar 2. 32: Relasi superkelas/subkelas supervisor dan staff (Connolly,p433)

2.6 Trigger

Trigger adalah sejenis prosedur atau fungsi yang data dipanggil sesuai

kebutuhan. Trigger digunakan sebagai alat validasi sebelum atau sesudah suatu

manipulasi data. Berikut ini statement standar pembuatan trigger daaalam SQL Server.

Tabel 2. 5 : Syntax Trigger dalam SQL Server, Oracle, dan MySQL

Create Trigger dalam SQL Server CREATE TRIGGER trigger_name ON table_name {{ FOR | AFTER | INSTEAD OF } INSERT, UPDATE, DELETE } AS Kondisi yang terjadi (sql_statement) BEGIN Raiserror (message kesalahan,16,1) Rollback Transaction END Create Trigger dalam Oracle CREATE OR REPLACE TRIGGER [trigger name] BEFORE | AFTER INSERT | UPDATE | DELETE ON [table name] FOR EACH ROW | STATEMENT DECLARE [template] BEGIN {body or validation} END ; Create Trigger dalam MySQL CREATE TRIGGER trigger_name Trigger_time Trigger_event ON table_name FOR EACH ROW trigger_statement

63

Berikut tabel tentang inventaris dalam sintaks pembuatan trigger

Tabel 2. 6 : Keterangan inventaris dalam suatu sintaks pembuatan trigger

Nama Deskripsi Fungsi Trigger Event Insert, update, delete Manipulasi data Trigger time Before, after, atau instead

of Menentukan kapan suatu trigger di fire

On Pengacuan tabel Menentukan tabel mana yang akan dipengaruhi oleh trigger

Batasan trigger For each row | statement Menentukan batasan pengaruh trigger

Trigger body Begin

{body}

End;

Tempat melakukan validasi atau pemanggilan data