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.
Entitas: Pelanggan, pembayaran, Penggunaan Relationships: Tagihan dikirim ke pelanggan, pelanggan membuat pembayaran, dan pelanggan menggunakan pulsa telepon Tagihan Proses pembayaran Pelayanan Registrasi Pembacaan Jumlah Pulsa
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
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.
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).
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.
2.2.2.1Struktur 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
(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.
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.
2.2.2.2Relasi 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
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.3Relasi 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
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.
Bentuk di atas biasa disebut dengan instansi relasi. Tabel Branch adalah cara paling baik untuk menuliskan seluruh bentuk relasi four- tuples.
2.2.2.4Properti 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
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
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.5Kunci-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).
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.
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.2Integritas 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
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.3Integritas 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
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.4Batasan 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
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.1Terminology
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.
2.2.4.2Tujuan 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’.
- Beberapa member dari Staff dapat melihat tuple-tuple Staff tanpa atribut salary.
- Penamaan dari 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.3Pembaharuan 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 .
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).
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
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,
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. 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
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
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).
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.
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. 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)
• 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
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. 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
(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. 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).
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
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.
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
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
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 anggotanya, dimana perbedaan antara anggota-anggota dari entitas ini diidentifikasi seperti anggota-anggota-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
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).
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
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. 27 : Gambar spesialisasi/generalisasi pada entitas staff (Connolly, p365)
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-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
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”.
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)
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
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
- 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
- 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
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
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
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).
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
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
