7 BAB 2 LANDASAN TEORI 2.1 Database Database adalah

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
data–data 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.
Tagihan
Pembacaan
Jumlah Pulsa
Entitas:
Pelanggan,
pembayaran,
Penggunaan
Relationships:
Tagihan dikirim ke
pelanggan, pelanggan
membuat pembayaran,
dan pelanggan
menggunakan pulsa
telepon
Proses
pembayaran
Pelayanan
Registrasi
Gambar 2. 1 : Contoh Database dari Perusahaan Telekomunikasi
7
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
Jose’s
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
8
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
9
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).
10
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
M001
M002
M003
M004
kd_mtk
T001
T002
T003
T001
Nama
Agus
Budi
Ratna
Isak
Alamat
Jl. Bunga No. 1
Jl. Pemuda No. 3
Jl. Jeruk No. 23
Jl. Manggis No 156
Tabel 2. 2 : Tabel Kuliah
kd_mtk
T001
T002
T003
Fakultas
Teknik Informatika
Akuntansi
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.
11
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 ANSI–SPARC. 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
12
(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.
13
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.
14
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
15
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
16
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.
17
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
18
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
menyederhanakan
kelompok
suatu
model
perulangan
data
relasional
untuk
tidak
diperbolehkan.
-
Dalam sebuah relasi, nilai yang mungkin pada posisi yang
diberikan akan dijelaskan oleh set atau domain, dimana posisi
19
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 elemenelemennya 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).
20
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.
21
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 spasispasi, 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
22
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
CR56
CR76
CR56
CR62
CR56
PropertyNo
PA14
PG4
PG4
PA14
PG36
viewDate
24-May-01
20-Apr-01
26-May-01
14-May-01
28-Apr-01
comment
Too small
Too remote
No dining room
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
23
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
24
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.
25
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 langkahlangkah 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’.
26
-
Beberapa member dari Staff dapat melihat tuple-tuple Staff tanpa atribut
salary.
-
Penamaan dari atribut-atribut dapat diulang atau pemesanan dari atributatribut 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 .
27
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 bagian–bagian 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).
28
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
29
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
melibatkan
4
buah
30
entitas
yaitu
Arranges. Relasi ini
Buyer,
Solicitor,
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)
31
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
32
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 nilai–nilainya
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
33
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
mungkin
kumpulan
untuk
memjadi
atribut-atribut
primary
yang
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).
34
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.
35
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)
36
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)
37
•
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
38
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 oneto-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)
39
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
40
(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)
41
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).
42
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
43
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
44
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
45
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
46
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 anggotaanggota 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
47
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).
48
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
49
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)
50
Gambar 2. 27 : Gambar spesialisasi/generalisasi pada entitas staff (Connolly, p365)
Gambar 2. 28 : Gambar Spesialisasi/generalisasi pada entitas staff (Connolly,p365)
51
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
Sedangkan
relasi
menuju ke superkelas Gambar 2.27.
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 anggotaanggota 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
52
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”.
53
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)
54
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, teknik–teknik, alat–alat maupun dokumentasi tambahan untuk
mendukung dan memberi fasilitas dari desain tersebut.
Perancangan database terdiri dari 3 fase utama, yaitu:
a. Conceptual database design
55
Conceptual database design merupakan suatu proses pembuatan
model dari informasi–informasi 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 tipe–tipe entitas
-
Identifikasikan tipe-tipe hubungan
-
Identifikasi dan hubungkan atribut-atribut dengan tipe
entitas atau tipe hubungan
56
-
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)
3.
-
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
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
57
-
Tinjau kembali model data logikal global dengan
pengguna
4.
5.
Terjemahkan model data logikal global target DBMS.
-
Desain hubungan dasar
-
Desain representasi dari data yang dihasikan
-
Desain batasan-batasan perusahaan
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 diidentifikasikan 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
58
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
Mandatory
Nondisjoint { And }
Optional
Nondisjoint { And }
Mandatory
Disjoint { Or }
Optional
Disjoint { Or }
Relations required
Relasi tunggal (dengan satu atau
lebih
diskriminator
untuk
membedakan tipe dari masingmasing baris)
Dua relasi: satu relasi untuk
superkelas dan satu relasi untuk
seluruh subkelas (dengan satu atau
lebih
diskriminator
untuk
membedakan tipe dari masingmasing baris).
Banyak relasi: satu relasi untuk
setiap superkelas atau subkelas
yang dikombinasikan.
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,
59
bName,
bType,
contactName,
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
60
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).
61
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
62
Berikut tabel tentang inventaris dalam sintaks pembuatan trigger
Tabel 2. 6 : Keterangan inventaris dalam suatu sintaks pembuatan trigger
Nama
Trigger Event
Trigger time
On
Deskripsi
Insert, update, delete
Before, after, atau instead
of
Pengacuan tabel
Batasan trigger
For each row | statement
Trigger body
Begin
{body}
End;
63
Fungsi
Manipulasi data
Menentukan kapan suatu
trigger di ‘fire’
Menentukan tabel mana
yang akan dipengaruhi
oleh trigger
Menentukan batasan
pengaruh trigger
Tempat melakukan
validasi atau pemanggilan
data