Sistem Basis Data

Edison P. Siahaan - Diktat Basis Data 1

2020

Sistem Basis Data

Edison Siahaan

U N I V E R S I T A S M P U T A N T U L A R


Edison Siahaan

Sistem Basis Data


Daftar Isi

INTRODUKSI ............................................................................................................................................ 5

1.1. Definisi dan Tujuan Basis data ............................................................................................... 5

1.2. Abstraksi Data ........................................................................................................................ 6

1.3. Model Data ............................................................................................................................. 6

1.4. Database Language ................................................................................................................ 8

1.5. Pengguna dan Administrator Basis Data ............................................................................... 8

Model Relasional ................................................................................................................................... 10

2.1. Struktur Basis Data Relasional ............................................................................................. 10

2.2. Schema Basis Data ................................................................................................................ 11

2.3. Keys ....................................................................................................................................... 11

2.4. Query Language .................................................................................................................... 12

Aljabar Relasional .................................................................................................................................. 13

3.1. Operator Select .................................................................................................................... 13

3.2. Operator Projection ............................................................................................................. 14

3.3. Union Operator .................................................................................................................... 15

3.4. Operator Set Difference ....................................................................................................... 16

3.5. Operator Cartesian Product ................................................................................................. 17

3.6. Operator Rename ................................................................................................................. 18

3.7. Komposisi dari Operator Dasar dan Ekspresi Aljabar Relasional ....................................... 18

3.8. Operator Tambahan dari Aljabar Relasional ....................................................................... 19

3.9. Operator Set Intersection .................................................................................................... 19

3.10. Operator Natural Join ...................................................................................................... 19

3.11. Operator Division ............................................................................................................. 20

3.12. Extended Operator pada Aljabar Relasional ................................................................... 20

3.13. Insert, Delete dan Update dengan Aljabar Relasional .................................................... 22

Structure Query Language .................................................................................................................... 24

4.1. Sejarah .................................................................................................................................. 24

4.2. Bagian-Bagian dari Bahasa SQL............................................................................................ 24

4.3. Data Definition Language (DDL) Pada Structure Query Language (SQL) ............................ 25

4.4. Data Query Language (DQL) ................................................................................................. 28

4.5. Data Manipulation Language (DML) .................................................................................... 60

4.6. VIEW...................................................................................................................................... 64

SQLite .................................................................................................................................................... 66


5.1. Tentang SQLite ..................................................................................................................... 66

5.2. Definisi, Ciri-Ciri, Fitur dan Kegunaan RDBMS SQLite ......................................................... 67

5.3. Arsitektur SQLite Library ...................................................................................................... 70

5.4. Tipe data pada SQLite Versi 3 .............................................................................................. 71

5.5. Tipe Afinitas (Typed Affinity) ............................................................................................... 73

5.6. SQL Lanjutan Pada SQLite .................................................................................................... 77

5.7. Command Line Shell Untuk SQLite ...................................................................................... 81

Entity Relationship Model ..................................................................................................................... 92

6.1. Tinjauan Terhadap Hubungan ER- Model dengan Tahapan Perancangan Basis Data. ...... 92

6.2. Entitas (Entity) dan Himpunan Entitas (Entity Set) ............................................................. 93

6.3. Relationship (Hubungan antar Entitas)1) dan Relationship set (Himpunan Hubungan antar

Entitas)2) ............................................................................................................................................ 95

6.4. Atribut (Attributes / Properties) ......................................................................................... 97

6.5. Constraint (Batasan) ............................................................................................................ 98

6.6. Entity Relationship Diagram (ERD) .................................................................................... 100

6.7. Diagram Drawing Tools dan Data Modeler Tools ............................................................. 136

6.8. Enhanced / Extended Entity Relationship Model ............................................................. 141

Normalisasi Basis Data ........................................................................................................................ 145

7.1. Ketergantungan Fungsional (Functional Dependency) ..................................................... 146

7.2. Bentuk Normal (Normal Form) .......................................................................................... 148

7.3. Aturan Inferensi (Inference Rule) Pada Ketergantungan Fungsional (Armstrong’s Axioms)

152

7.4. Tutupan / Klosur dari Himpunan Ketergantungan Fungsional (Closure Of Set Of

Functional Dependencies) .............................................................................................................. 153

7.5. Tutupan / Klosur dari Himpunan Atribut (Closure Of Attribute Sets) .............................. 153

7.5. Canonical Cover Himpunan Ketergantungan Fungsional .................................................. 156

7.6. Dekomposisi Relation (Tabel) Berdasarkan Ketergantungan Fungsional ........................ 160

7.7. Lossles – Join Decomposition ............................................................................................. 164

7.8. Dependency Preservation .................................................................................................. 165

Reduksi dan Pemetaan (Mapping) .................................................................................................... 167

8.1. Reduksi ERD Notasi Silberschatz – Korth –Sudarshan ke Model Relasional .................... 168

8.2. Pemetaan (Mapping) ERD Notasi Barker ke Model Relasional ........................................ 176


1

INTRODUKSI

1.1. Definisi dan Tujuan Basis data

Basis data dapat diartikan dari sejumlah sudut pandang, seperti :

a. Himpunan kelompok data (arsip) yang saling berhubungan yang diorganisasikan sedemikian rupa agar kelak dapat dimanfaatkan kembali dengan cepat dan mudah

b. Kumpulan data yang saling berhubungan yang disimpan secara bersama sedemikian rupa dan tanpa pengulangan (redundansi) yang tidak perlu untuk memenuhi berbagai kebutuhan

c. Kumpulan file/tabel/arsip yang saling berhubungan yang disimpan dalam media penyimpanan elektronis.

Pemanfaatan basis data dilakukan untuk memenuhi sejumlah tujuan seperti berikut ini :

a. Kecepatan dan kemudahan b. Efisiensi ruang penyimpanan c. Keakuratan d. Ketersediaan e. Kelengkapan f. Keamanan g. Kebersaman Pemakaian

Sebelum adanya Sistem Basis Data, maka aplikasi basis data dibuat dengan menggunakan/membuat file data secara langsung. Kekurangan bila basis data langsung diaplikasikan menggunakan file data secara langsung adalah :

a. Terjadi Data Redundancy dan inkonsistensi Adanya format file data yang berbeda-beda, memungkinkan terjadinya duplikasi informasi pada sejumlah file yang digunakan.

b. Terjadi kesulitan dalam pengaksesan data dan adanya Isolasi Data

Perbedaaan format dari sejumlah file data menyebabkan adanya kesulitan dalam proses pengumpulan data dari sejumlah file data tersebut.

Adanya kebutuhan untuk menulis suatu program baru untuk setiap task baru yang dibutuhkan

c. Terjadi kesulitan dalam pengaksesan data dan adanya Isolasi Data Karena constraint dibuat dalam program aplikasi, maka penambahan constraint baru atau merubah constraint yang sudah ada, harus dilakukan dengan mengubah program

d. Timbulnya masalah Atomicity dari proses update Jika terjadi failure dan terjadi perubahan sebagian dari data, maka akan terjadi inkonsistensi dalam data.

e. Dapat menyebabkan terjadinya anomali dan inkonsistensi data, jika akses dilakukan secara konkuren (bersamaan) oleh beberapa pengguna

f. Dapat menimbulkan masalah keamanan Karena pembatasan akses berada dalam aplikasi, maka untuk setiap jenis pengguna dengan hak akses yang berbeda, harus dibuat aplikasi yang berbeda.


1.2. Abstraksi Data

Salah satu tujuan dari DBMS adalah untuk menyediakan fasilitas antar muka dalam melihat data kepada pemakai. Untuk itu, sistem tersebut akan menyembunyikan detail tentang bagaimana data disimpan dan dipelihara. Karena itu, seringkali data yang terlihat oleh pemakai sebelumnya berbeda dengan yang tersimpan secara fisik. Abstraksi data merupakan tingkatan dalam bagaimana melihat data dalam sebuah sistem basis data.

Tingkatan-tingkatan abstraksi data yang ada dalam suatu sistem basis data adalah :

a. Physical Level menggambarkan bagaimana (how) suatu record (misalnya data pelanggan) disimpan secara fisik dan akan menjelaskan detil-detil struktur data yang akan digunakan

b. Logical Level Mendeskripsikan data apa (what data)yang disimpan dan hubungan (relationship) diantara

data-data yang disimpan.

type customer = record

customer_id :string;

customer_name :string;

customer_street :string;

customer_city : integer;

end;

c. View Level Tingkatan tertinggi dari abstraksi data, dimana pada level ini hanya akan ditampilkan sebagian dari informasi yang terdapat pada basis data. Informasi yang ditampilkan akan disesuaikan dengan kebutuhan dari pengguna

Berikut adalah gambaran dan representasi tingkatan abstraksi dalam suatu Sistem Basis Data

Gambar 1.1. Tingkatan Abstraksi Data pada Sistem Basis Data

1.3. Model Data

Model Data adalah suatu koleksi kakas (tools) yang digunakan untuk mendeskripsikan :

Data

Relasi antar data (Data relationships)

Data semantics

Data constraints


Model data memungkinkan pendeskripsian rancangan basis data pada level fisik, level logis dan level view. Jenis-jenis Model Data antara lain :

Model Relasional (Relational model)

Entity-Relationship data model

Object-based data models (Object-oriented dan Object-relational)

Semistructured data model (XML)

Model Relasional Model relasional adalah pemodelan data yang akan menghasilkan basis data relasional. Basis

Data Relasional adalah basis data yang memiliki karakteristik sebagai berikut :

Basis data yang akan berisi 1 atau lebih tabel (relations)

Setiap Tabel akan terdiri dari baris (Entitas) dan Kolom(Atribut)

Tabel pada basis data relasional digunakan untuk merepresentasikan data dan hubungan antar data di dalam basis data tersebut.

Untuk mengelola Basis data Relasional, digunakan bahasa yang disebut Database Manipulation Language(DML) dan Database Definition Language (DDL). Saat ini, DML dan DDL yang digunakan basis data relasional adalah bahasa yang dikenal sebagai Structure Query Language(SQL).

Setiap tabel pada basis data relasional umumnya memiliki banyak kolom dan setiap kolomnya

memiliki nama yang unik. Contoh-contoh tabel pada suatu basis data relasional dapat dilihat pada

gambar 1.2. dibawah ini.

Tabel customer

Tabel account

Tabel depositor

Gambar 1.2. Contoh Tabel pada suatu Basis Data Relasional


Entity Relationship Model Pada Entity Relationship Model, maka suatu enterprise adalah suatu koleksi yang terdiri dari

sejumlah himpunan entitas dan himpunan relationship. Entitas pada pemodelan ini adalah obyek

dalam enterprise yang dapat dibedakan dari obyek lainnya, sedangkan Relationship adalah asosiasi

diantara sejumlah entitas. Untuk menggambarkan suatu ERM, maka digunakan diagram yang

disebut Entity Relationship Diagram (ERD). Gambar 1.3. dibawah ini adalah contoh dari suatu ERD

dalam notasi Silberschatz-Korth-Sudarshan.

Gambar 1.3. Contoh ERD dengan notasi Silberschatz – Korth - Sudarshan

1.4. Database Language

Bahasa yang digunakan pada suatu basis data terdiri dari 2 jenis yaitu :

a. Data Definition language (DDL)

DDL adalah suatu bahasa yang dapat digunakan untuk menspesifikasikan dan

mendefinisikan database schema. Contoh perintah DDL menggunakan SQL adalah :

CREATE TABLE account (

account-number char(10),

balance integer)

b. Data Manipulation language (DML).

DML adalah suatu bahasa yang digunakan untuk mengakses dan memanipulasi data yang

diorganisasikan sesuai dengan suatu model data tertentu. Contoh perintah DML yang

menggunakan SQL adalah :

SELECT customer.customer_name

FROM customer

WHERE customer.customer_id=‘192-83-7465’

1.5. Pengguna dan Administrator Basis Data

Pihak yang berhubungan dengan suatu sistem basis data umumnya dapat dikategorikan menjadi

2 yaitu :

a. Pengguna Basis Data (Database User)

b. Administrator Basis Data (Database Administrator)


Pengguna basis data (Database User) dapat dikategorikan menjadi :

Naive user

Pengguna yang tidak mahir dalam berhubungan dengan sistem basis data dan umumnya

akan berinteraksi dengan basis data dengan menggunakan salah satu program aplikasi yang

menggunakan basis data

Application Programmer

Pengguna yang membuat program aplikasi yang berhubungan dengan suatu basis data.

Sophisticated user

Pengguna mahir, yang berinteraksi dengan sistem basis data tanpa membuat program,

melainkan menggunakan query dengan menggunakan database language.

Specialized user

Pengguna mahir yang membuat program aplikasi basis data khusus yang tidak dapat

dimasukkan pada framework pemrosesan data yang umum, misalnya knowledge base dan

expert system serta sistem yang menyimpan data dengan tipe yang kompleks.

Administrator Basis Data, sangat dibutuhkan dalam suatu sistem basis data, administrator umumnya

memiliki tugas sebagai berikut :

Mendefinisikan Schema

Mendefinisikan struktur penyimpanan dan metode pengaksesan

Memodifikasi schema dan physical- organization

Mengelola Pemberian autorisasi akses data

Melakukan Perawatan yang bersifat rutin seperti :

Melakukan back-up data secara periodik

Menjaga dan memperhatikan ketersediaan ruang penyimpanan pada disk

Memperhatikan job-job yang sedang dieksekusi dan memastikan performa DBMS tidak

mengalami penurunan yang signifikan.


2

Model Relasional

2.1. Struktur Basis Data Relasional

Suatu basis data relasional umumnya akan tersusun dari sejumlah tabel yang setiap tabelnya

memiliki identitas/nama yang unik. Secara informal suatu tabel dapat dinyatakan sebagai sebuah

himpunan entitas, sedangkan setiap barisnya dapat dianggap sebagai suatu entitas.

Konsep tabel yang digunakan dalam basis data relasional memiliki keserupaan dengan konsep

matematis yang disebut relation. Gambar 2.1. dibawah ini merupakan contoh dari suatu relation

atau tabel :

Gambar 2.1. Contoh suatu relation

Tabel pada gambar 2.1. adalah contoh dari tabel atau relation. Tabel account pada gambar 2.1.

tersebut memiliki 3 header yaitu account_number, branch_name dan balance. Pada model

relasional header dari setiap kolom tabel dikenal sebagai atribut dari relation. Setiap atribut akan

memiliki sehimpunan nilai yang dapat menjadi nilai dari atribut tersebut. Sehimpunan nilai yang

mungkin menjadi nilai dari suatu atribut pada model relasional dikenal sebagai domain dari atribut

tersebut.

Secara matematis, suatu tabel atau relation dengan n atribut haruslah menjadi suatu himpunan

bagian dari D1 x D2 x … x Dn, sehingga suatu relation adalah himpunan n tuple (a1, a2, …, an) dimana

setiap ai Di . Contoh : jika diberikan :

customer_name = {Jones, Smith, Curry, Lindsay}

customer_street = {Main, North, Park}

customer_city = {Harrison, Rye, Pittsfield}

maka r = { (Jones, Main, Harrison),

(Smith, North, Rye),

(Curry, North, Rye),

(Lindsay, Park, Pittsfield) }

adalah suatu relation dari customer_name x customer_street x customer_city.

Isi dari suatu tabel pada suatu saat disebut juga sebagai relation instance. Tuple pada suatu relation

direpresentasikan dengan baris pada suatu tabel. Urutan penyimpanan tuple (baris) dan urutan

atribut (kolom) pada suatu tabel dalam basis data relasional tidak akan mempengaruhi integritas

dari suatu basis data.


2.2. Schema Basis Data

Database schema adalah desain logis dari suatu basis data relasional, sedangkan Relation

schema adalah desain logis dari suatu relation. Secara umum relation schema harus memuat

seluruh atribut-atribut relation tersebut beserta dengan domain dari atribut tersebut. Contoh

berikut menunjukkan penyederhanaan penulisan relation schema dimana domain dari atribut untuk

sementara tidak dinyatakan secara eksplisit :

Customer_schema = (customer_name, customer_street, customer_city)

Jika relation customer(R) adalah suatu relasi dengan schema Customer_schema diatas, maka dapat

dinyatakan :

customer (Customer_schema)

Schema suatu basis data selain dapat dinyatakan dengan cara diatas, juga umum untuk dinyatakan

dengan gambar yang disebut sebagai schema diagram. Gambar 2.2. dibawah ini menunjukkan satu

contoh schema diagram dari suatu basis data.

Gambar 2.2. Contoh Schema Diagram suatu Basis Data

2.3. Keys

Pada suatu relation dibutuhkan cara untuk dapat mengidentifikasi/membedakan baris-baris

yang ada di dalam relation tersebut. Jenis-jenis key pada suatu relation antara lain adalah :

Super Key

Candidate Key

Alternate Key

Primary Key

Foreign Key

Jika K adalah key dan R adalah suatu relation schema maka K R. K adalah superkey dari

relation r(R) jika K adalah himpunan atribut dari relation schema R yang dapat digunakan untuk

membedakan setiap tuple (baris) pada relation r(R).


K adalah candidate key dari r(R) jika K adalah superkey dengan jumlah atribut yang paling

minimal (Tidak ada himpunan bagian dari K yang dapat menjadi superkey). K adalah Primary Key

dari r(R) jika K adalah candidate key yang dipilih dan digunakan sebagai kunci primer. K adalah

Alternate Key dari r(R) jika K adalah candidate key yang tidak digunakan sebagai kunci primer.

Jika terdapat relation r1 dan r2, maka K adalah Kunci Tamu (Foreign Key) dari r1, jika K adalah

primary key atau candidate key dari r2. Pada hubungan ini maka relation r1 adalah referencing

relation dari foreign key dan r2 adalah referenced relation dari foreign key.

Jika digunakan schema diagram seperti gambar 2.2. diatas maka :

Superkey dari account adalah : (account_number,branch_name) dan (account_number)

Candidate key dan Primary Key dari relation account : account_number

Foreign key dari relation account : branch_name dimana account adalah referencing

relation dan branch adalah referenced relation

2.4. Query Language

Query Language adalah bahasa yang digunakan untuk memperoleh informasi dari suatu basis

data. Query Language (menurut Abraham Silberschatz) dapat dikategorikan menjadi :

Procedural

Pengguna secara spesifik memberi instruksi kepada sistem untuk melakukan sejumlah

urutan kegiatan untuk mendapatkan hasil yang diinginkan.

Non-procedural atau declarative

Pengguna hanya menyatakan hasil yang ingin diperoleh tanpa secara spesifik memberikan

prosedur untuk mendapat hasil tersebut.

Terdapat beberapa “Pure” language yang menjadi dasar dari beberapa bahasa query yang

benar-benar digunakan oleh basis data relasional modern, bahasa-bahasa tersebut antara lain :

Relational algebra

Tuple relational calculus

Domain relational calculus


3

Aljabar Relasional

Relational Algebra atau aljabar relasional adalah salah satu contoh query language yang bersifat

prosedural. Terdapat 6 Operator dasar pada aljabar relasional seperti dapat dilihat pada Tabel. 3.1.

Setiap operator aljabar relasional pada tabel tersebut akan menggunakan 1 atau 2 relation sebagai

masukan untuk menghasilkan hasil (result) berupa suatu relation baru.

Tabel 3.1. Operator Dasar Aljabar Relasional

Nama Operator Simbol

Select

Project

Union

Set Difference –

Cartesian Product x

Rename

3.1. Operator Select

Operator Select dinotasikan : . Select Operation dapat didefinisikan sebagai berikut :

p(r) = {t | t r and p(t)}

dimana :

– p adalah selection predicate berupa pernyataan dalam propositional calculus (logika

proposisi) yang terdiri dari beberapa term yang dihubungkan dengan operator

(and), (or), (not)

• Setiap term dapat berupa <attribute> op <attribute> atau <constant>

dimana op adalah salah satu dari =, , >, . <.

– t adalah tuple

Contoh query dengan operator select adalah sebagai berikut :

branch_name=“Perryridge”(account)

Hasil dari query diatas adalah : seluruh tuple dari relation account yang memiliki atribut

branch_name = Perryridge

Edison P. Siahaan - Diktat Basis Data

3.2. Operator Projection

Operator Project dinotasikan :

dimana : A1, A2 ..., Ak

r

Hasil dari project operation

menghapus atribut-atribut dari relation

aljabar relasional, jika terdapat tuple atau baris yang bersi

maka tuple atau baris-baris tersebut akan dihilangkan dan hanya 1 tuple saja yang akan diambil

Contoh : Untuk mendapatkan seluruh tuple

branch_name , dapat digunakan

account_number, balance (account)

Contoh Soal 3.1. Jika diberikan suatu relasi atau

Jika query yang diberikan adalah

Jawab :

Hasil query A=B ^ D > 5 (r) adalah

Diktat Basis Data

Operator Project dinotasikan : , project operation dapat didefinisikan sebagai berikut :

)( ,,, 21r

kAAA

: list atribut : relation.

dari project operation adalah suatu relation yang memiliki k atribut yang diperoleh dengan

atribut dari relation r yang tidak terdapat pada list A1,A2, ..., A

aljabar relasional, jika terdapat tuple atau baris yang bersifat duplikasi dari tuple yang sudah ada

baris tersebut akan dihilangkan dan hanya 1 tuple saja yang akan diambil

Contoh : Untuk mendapatkan seluruh tuple dari relation account tanpa menyertakan atribut

, dapat digunakan query dengan operator project sebagai berikut :

(account)

atau tabel r sebagai berikut :

Jika query yang diberikan adalah A=B ^ D > 5 (r) , tentukanlah relation hasil dari query terseb

adalah :

14

dapat didefinisikan sebagai berikut :

atribut yang diperoleh dengan

, ..., Ak dari query. Pada

fat duplikasi dari tuple yang sudah ada

baris tersebut akan dihilangkan dan hanya 1 tuple saja yang akan diambil

dari relation account tanpa menyertakan atribut

query dengan operator project sebagai berikut :

tentukanlah relation hasil dari query tersebut.


3.3. Union Operator

Operator Union dinotasikan :

r s = {t | t r

Union operation r s dapat dinyatakan

a. Relation r, s harus memiliki jumlah atribut atau

b. Domain atribut dari relation

Contoh : Query berikut dapat digunakan untu

tabungan atau pinjaman

customer_name (depositor)


Dan query yang diberikan adalah

Jawab :

Hasil query X,Z (r)adalah :

Diktat Basis Data

dinotasikan : , Union operation dapat didefinisikan sebagai berikut :

r or t s}

dapat dinyatakan valid jika memenuhi syarat sebagai berikut :

harus memiliki jumlah atribut atau arity yang sama

Domain atribut dari relation r dan s harus kompatibel

uery berikut dapat digunakan untuk mendapatkan seluruh nama customer yang memiliki

) customer_name (borrower)

atau tabel r sebagai berikut :

query yang diberikan adalah X,Z (r), tentukanlah relation hasil dari query tersebut.

15

dapat didefinisikan sebagai berikut :

jika memenuhi syarat sebagai berikut :

k mendapatkan seluruh nama customer yang memiliki



3.4. Operator Set Difference

Operator Set Difference dinotasikan :

berikut :

r – s = {t | t r and t

Set Difference operation r – s dapat dinyatakan

a. Relasi r, s harus memiliki jumlah atribut atau

b. Domain atribut dari relasi





Jawab :

Hasil query r s adalah :

Diktat Basis Data

dinotasikan : – , Set Difference operation dapat didefinisikan sebagai

s}



elasi r dan s harus kompatibel

atau tabel r dan s sebagai berikut :

query yang diberikan adalah r - s tentukanlah relation hasil dari query tersebut.


query yang diberikan adalah r s tentukanlah relation hasil dari query tersebut.

16

dapat didefinisikan sebagai

jika memenuhi syarat sebagai berikut :




3.5. Operator Cartesian Product

Operator Cartesian Product

sebagai berikut :

r x s = {t q | t r and q s}

Jika terdapat atribut dari r(R) dan



Jawab :

Hasil query r Xs adalah :

Jawab :

Hasil query r - s adalah :

Diktat Basis Data

Operator Cartesian Product

Operator Cartesian Product dinotasikan : X, Cartesian Product operation

dan s(S) yang sama, maka harus digunakan operasi


query yang diberikan adalah r X s tentukanlah relation hasil dari query tersebut.

17

Cartesian Product operation diatas didefinisikan

yang sama, maka harus digunakan operasi rename



3.6. Operator Rename

Rename Operation memungkinkan pemberian nama terhadap hasil dari ekspresi aljabar

relasional. Contoh : x (E) akan mengembalikan Ekspresi E dengan nama X

Rename Operation memungkinkan penunjukkan suatu

nama. Jika suatu ekspresi relational

)(),...,,( 21E

nAAAx

akan mengembalikan hasil ekpresi E dengan nama X dan merubah nama atribut dari hasil ekspresi

menjadi A1 , A2 , …., An .

3.7. Komposisi dari Operator Dasar

Pada aljabar relasional, dimungkinkan suatu ekspresi merup

gabungan dari dari beberapa operator aljabar relasional.

Maka A=C(r x s) menghasilkan :

Jika E1 dan E2 adalah suatu ekspresi aljabar relasional yang dapat berisi relasi dalam basis

ataupun berisi constant relation

aljabar relasional:

E1 E2

E1 – E2

E1 x E2

p (E1), dimana P adalah predikat pada atribut

s(E1), dimana S adalah suatu list atau daftar yang

x (E1), dimana x adalah nama baru dari hasil ekspresi

Diktat Basis Data

memungkinkan pemberian nama terhadap hasil dari ekspresi aljabar

kan mengembalikan Ekspresi E dengan nama X

memungkinkan penunjukkan suatu relation dengan menggunakan beberapa

nama. Jika suatu ekspresi relational-algebra E memiliki arity n, maka :


Komposisi dari Operator Dasar dan Ekspresi Aljabar Relasional

Pada aljabar relasional, dimungkinkan suatu ekspresi merupakan ekspresi yang menggunakan

gabungan dari dari beberapa operator aljabar relasional. Contoh : Jika r x s menghasilkan

menghasilkan :

adalah suatu ekspresi aljabar relasional yang dapat berisi relasi dalam basis

constant relation, maka ekspresi-ekspresi sebagai berikut juga merupakan ekspresi

adalah predikat pada atribut E1

adalah suatu list atau daftar yang terdiri dari beberapa atribut pada

adalah nama baru dari hasil ekspresi E1

18

memungkinkan pemberian nama terhadap hasil dari ekspresi aljabar

dengan menggunakan beberapa


akan ekspresi yang menggunakan

menghasilkan :

adalah suatu ekspresi aljabar relasional yang dapat berisi relasi dalam basis data

ekspresi sebagai berikut juga merupakan ekspresi

terdiri dari beberapa atribut pada E1


3.8. Operator Tambahan dari Aljabar Relasional

Karakteristik dari operator-operator tambahan

a. Operator tambahan dapat diganti de

b. Operator tambahan digunakan untuk menyederhanakan penulisan query

Operator yang merupakan operator tambahan pada relational algebra adalah :

Set Intersection ()

Natural Join ( )

Division ()

Assignment ()

3.9. Operator Set Intersection

Set Intersection Operation dinotasikan :

r s = { t | t r and t s }

Set Intersection operation r s

a. Relation r, s harus memiliki juml

b. Domain atribut dari relation r dan s harus kompatibel

r s merupakan penyederhanaan dari

3.10. Operator Natural Join



Jawab :


X Y

2

Diktat Basis Data

dari Aljabar Relasional

operator tambahan dari aljabar relasional adalah

Operator tambahan dapat diganti dengan komposisi beberapa operator dasar.

Operator tambahan digunakan untuk menyederhanakan penulisan query

Operator yang merupakan operator tambahan pada relational algebra adalah :

)

Set Intersection Operation dinotasikan : r s, didefinisikan :

s dapat dinyatakan valid jika memenuhi syarat sebagai berikut :


Domain atribut dari relation r dan s harus kompatibel

merupakan penyederhanaan dari r s = r – (r – s)



19

dari aljabar relasional adalah :

ngan komposisi beberapa operator dasar.

Operator tambahan digunakan untuk menyederhanakan penulisan query




Natural Join dinotasikan :

s dengan schema S = (E, B, D), maka untuk query

relasi hasil query diatas adalah sebuah relasi dengan schema

Query r s merupakan penyederhanaan dari

r.A, r.B, r.C, r.D, s.E

3.11. Operator Division

Jika diberikan q = r s, maka

operasi divisiona, jika diberikan 2 relasi r(R) dan s(S) dan sch

bentuk sederhana dari query :

r s = R-S (r ) – R-S ( ( R-S

3.12. Extended Operator pada Aljabar Relasional

Operator-operator yang merupakan operator Extended Relational

Generalized Projection

Aggregate Functions

Outer Join

Generalized Projection



Jawab :


Diktat Basis Data

., Jika diberikan relasi r dengan schema R = (

, maka untuk query r s berlaku :

relasi hasil query diatas adalah sebuah relasi dengan schema = (A, B, C, D, E

merupakan penyederhanaan dari operasi :

r.D, s.E (r.B = s.B r.D = s.D (r x s))

maka q adalah relasi yang harus memenuhi persyaratan :

ika diberikan 2 relasi r(R) dan s(S) dan schema S R maka

(r ) x s ) – R-S,S(r ))

Extended Operator pada Aljabar Relasional

operator yang merupakan operator Extended Relational – Algebra :



20

= (A, B, C, D) dan relasi

A, B, C, D, E)

adalah relasi yang harus memenuhi persyaratan : q x s r . Pada

R maka query r s adalah



Generalized Projection merupakan operator yang memperluas fungsi projection dengan

memungkinkan penggunaan hasil fungsi-fungsi aritmatika sebagai nilai atribut dari suatu query yang

menggunakan projection :

)( ,...,,21

EnFFF

dimana : E : ekspresi aljabar relasional

F1,F2, ... Fn : ekspresi aritmatika

Contoh :

Jika terdapat relasi credit_info yang memiliki schema

Credit_info(customer_name,limit,credit_balance), maka query yang akan menghasilkan jumlah

kredit yang dapat digunakan, adalah :

customer_name, limit – credit_balance (credit_info)

Aggregate Functions Fungsi-fungsi agregasi yang umum digunakan antara lain :

avg: average value

min: minimum value

max: maximum value

sum: sum of values

count: number of values

Operator yang digunakan untuk menghitung fungsi-fungsi agregasi dalam aljabar relasional adalah :

)()(,,(),(,,, 221121E

nnn AFAFAFGGG G

dimana :

G1,G2,...,Gn adalah daftar atribut yang menjadi dasar pengelompokkan

Fi adalah fungsi-fungsi agregasi

Ai adalah nama-nama atribut

Outer Join Outer Join dinotasikan sebagai berikut :

Operator outer join merupakan perluasan operasi join dan digunakan untuk menghindari adanya

informasi yang hilang. Pada Outer join dimungkinkan untuk menghasilkan suatu relasi yang

memiliki nilai null di beberapa atribut.


3.13. Insert, Delete dan Update dengan Aljabar Relasional

Pada aljabar relasional, isi dari suatu basis data dapat dimodifikasi menggunakan operasi-operasi

sebagai berikut:

Deletion (Penghapusan)

Insertion (Penyisipan)

Updating (Pengubahan nilai Atribut dari sejumlah tuple)

Pada aljabar relasional, proses penghapusan, penyisipan dan update, umumnya akan diekspresikan

dengan menggunakan assignment operator.

Delete Untuk menghapus sejumlah tuple pada suatu relasi, maka dapat digunakan perintah sebagai

berikut : r r – E

dimana :

r : suatu relasi yang akan dihapus sebagian atau seluruh tuple-nya

E : Ekspresi dalam aljabar relasional

Penghapusan hanya dapat dilakukan pada tuple dan tidak dapat digunakan untuk menghapus nilai

suatu atribut pada tuple.

Contoh :

Untuk menghapus seluruh record pada relasi account yang memiliki nilai atribut

branch_name=“Perryridge”, maka dapat digunakan perintah sebagai berikut :

account account – branch_name = “Perryridge” (account )

Untuk menghapus seluruh record pada relasi loan yang memiliki nilai atribut amount pada

range nilai 0 – 50, dapat digunakan perintah sebagai berikut :

loan loan – amount 0 and amount 50 (loan)

Insert Untuk menyisipkan sejumlah tuple pada suatu relasi, maka dapat digunakan perintah sebagai

berikut :

r r E dimana : r : suatu relasi yang akan disisipkan sejumlah tuple baru E : Ekspresi dalam aljabar relasional Contoh : Perintah untuk menyisipkan nasabah baru bernama smith dengan account number A-973

pada cabang Perryridge serta memiliki jumlah tabungan sebesar $1200 adalah :

account account {(“Perryridge”, A-973, 1200)}

depositor depositor {(“Smith”, A-973)} Update


Untuk merubah nilai dari sejumlah atribut pada suatu relasi dapat digunakan perintah sebagai

berikut :

)(,,,, 21rr

lFFF

dimana Fi adalah :

atribut atau atribut beserta ekspresi yang digunakan untuk merubah nilai dari atribut

tersebut.

Contoh : Untuk merubah nilai atribut balance pada relasi account dengan menambahkan 5 % dari

nilai balance awal, dapat digunakan perintah sebagai berikut :

account account_number, branch_name, balance * 1.05 (account)


4

Structure Query Language

4.1. Sejarah

Pada awal dekade 1970 khususnya tahun 1974, SQL pertama kali dirilis oleh peneliti-peneliti di IBM yaitu Donald D. Chamberlain dan Raymond F. Boyce. SQL Language, pada awalnya disebut sebagai SEQUEL (Structure EnglIsh Query Language) yang merupakan bagian dari System R Project. SEQUEL kemudian berkembang dan disebut sebagai bahasa SQL (Structure Query Language). Saat ini sebagian besar basis data relasional mendukung bahasa SQL. Standarisasi SQL pada awalnya dilakukan oleh ANSI, tetapi saat ini standar bahasa SQL dibuat oleh ISO (International Organization for Standardization) dan IEC (International Electrotechnical Commision).

Standarisasi SQL yang telah dibuat mulai dari awal dikembangkan sampai saat ini, antara lain adalah :

SQL 86

SQL 89

SQL 92

SQL 1999

SQL 2008

SQL 2011

SQL 2016

Walaupun SQL telah distandarisasi, tetapi berbagai RDBMS baik yang bersifat komersial atau non komersial seringkali tidak dapat sepenuhnya mengimplementasikan seluruh standar yang telah dibuat. Hal ini sering kali menyebabkan adanya perbedaan antara SQL yang digunakan oleh vendor-vendor RDBMS tersebut.

4.2. Bagian-Bagian dari Bahasa SQL

Secara informal Bahasa SQL dapat dibagi menjadi beberapa sub bahasa (sublanguage). Sub bahasa tersebut antara lain adalah :

1. Data Definition Language (DDL) 2. Data Manipulation Language (DML) 3. Data Query Language (DQL) 4. Data Control Language (DCL)

Terdapat beberapa pernyataan (statement) yang bersifat dasar pada DDL. Pernyataan-pernyataan dasar ini umumnya digunakan untuk mendefinisikan dan menspesifikasikan struktur serta schema basis data yang dibuat. Pernyataan-pernyataan dasar pada DDL antara lain adalah CREATE, ALTER dan DROP.

Pada sub bahasa Data Manipulation Language (DML) SQL, terdapat juga pernyataan-pernyataan dasar seperti INSERT, UPDATE dan DELETE. Pernyataan-pernyataan dasar pada DML, umumnya digunakan untuk melakukan penyisipan, penghapusan dan perubahan data pada basis data yang telah dibuat.

Seperti pada DDL dan DML, maka pada sub bahasa Data Query Language (DQL) SQL terdapat pula pernyataan dasar. Pernyataan dasar pada Data Query Language SQL digunakan untuk mendapatkan atau memperoleh kembali data-data yang telah disimpan pada basis data. Pernyataan dasar pada DQL adalah pernyataan SELECT.


Sub bahasa Data Control Language (DCL) SQL digunakan untuk melakukan pengelolaan akses dari basis data. Pernyataan-pernyataan dasar pada Data Control Language (DCL) SQL adalah pernyataan-pernyataan seperti GRANT dan REVOKE

4.3. Data Definition Language (DDL) Pada Structure Query Language (SQL)

Seperti yang sudah disebutkan pada bagian 4.2. , pernyataan-pernyataan di sub bahasa DDL umumnya digunakan untuk mendefinisikan dan menspesifikasikan struktur serta schema dari basis data yang akan dibuat. Spesifikasi himpunan relasi pada RDBMS yang dibuat dan dikelola dengan pernyataan-pernyataan DDL antara lain adalah schema dari setiap relasi, domain nilai dari setiap atribut, Integrity Constraints dan himpunan indeks pada setiap relasi.

Pernyataan-pernyataan DDL yang akan dibahas pada diktat ini khususnya adalah pernyataan-pernyataan DDL yang digunakan pada basis data SQLite

4.3.1. Pernyataan CREATE TABLE

Pernyataan CREATE TABLE digunakan untuk mendefinisikan dan membuat suatu tabel/relasi pada RDBMS. Aturan sintaksis dari pernyataan CREATE TABLE adalah sebagai berikut :

Gambar 4.1. Aturan Sintaksis Pada Pernyataan CREATE TABLE

Contoh Pernyataan CREATE TABLE yang digunakan untuk membuat tabel branch yang memiliki 3 kolom atau 3 atribut yaitu branch_name, branch_city dan assets, dapat dilihat dibawah ini :

Gambar 4.2. Contoh Pernyataan CREATE TABLE

Pada saat suatu tabel atau relasi diciptakan, maka dapat ditambahkan integrity constraint pada tabel tersebut. Integrity constraint yang dapat ditambahkan antara lain adalah :

NOT NULL Jika suatu atribut memiliki integrity constraint NOT NULL, maka nilai dari atribut tersebut tidak boleh bernilai NULL

PRIMARY KEY (A1,A2, ..., An) Integrity Constraint PRIMARY KEY digunakan untuk menyatakan bahwa atribut-atribut A1 .. An digunakan sebagai kunci primer dari tabel yang dibuat.

Pada gambar 4.3. dibawah ini dicontohkan pernyataan CREATE TABLE yang digunakan untuk membuat tabel branch yang memiliki 3 atribut (branch_name,branch_city, assets) dan atribut branch_name adalah kunci primer dari tabel tersebut.

CREATE TABLE branch (branch_name char(15), branch_city char(30), assets integer)

CREATE TABLE r (A1 D1, A2 D2, ..., An Dn, (integrity-constraint1), ..., (integrity-constraintk)) Dimana : r : nama relasi yang akan dibuat Ai : nama nama atribut pada relasi r Di : Tipe Data dari dari setiap atribut pada relasi r


Gambar 4.3. Contoh Pernyataan CREATE TABLE dengan Integrity Constraint

4.3.2. Pernyataan DROP TABLE

Pernyataan drop table digunakan untuk menghapus suatu tabel dari basis data. Aturan sintaksis yang digunakan pada pernyataan DROP TABLE adalah :

Gambar 4.4. Aturan Sintaksis Pada pernyataan DROP TABLE

Contoh pernyataan DROP TABLE yang digunakan untuk menghapus tabel branch, dapat dilihat pada gambar 4.5. dibawah ini.

Gambar 4.5. Contoh pernyataan DROP TABLE

DROP TABLE branch

DROP TABLE r Dimana : r : nama relasi yang akan dihapus

Contoh Soal 4.1. Buatlah pernyataan CREATE TABLE yang dapat digunakan untuk membuat sebuah tabelatau relasi

pada yang dinamakan customer pada DBMS SQLite dan memiliki schema diagram sebagai

berikut:

Jawab : Dari schema diagram diketahui bahwa tabel customer yang akan dibuat terdiri dari 3 atribut yaitu

customer_name, customer_street dan customer_city, sedangkan kunci primer dari tabel

customer adalah customer_name. Pernyataan CREATE TABLE yang digunakan untuk membuat

tabel customer adalah sebagai berikut :

CREATE TABLE customer (customer_name char(20), customer_street char(30), customer_city char(30), primary key( customer_name)) ;

CREATE TABLE branch (branch_name char(15), branch_city char(30), assets integer,

primary key (branch_name))


4.3.3. Pernyataan ALTER TABLE

Pernyataan ALTER TABLE digunakan untuk merubah schema dari suatu relasi atau tabel yang sudah dibuat. Aturan sintaksis yang digunakan pada pernyataan ALTER TABLE di SQLite untuk merubah nama dari suatu tabel dapat dilihat pada gambar 4.6.a, sedangkan gambar 4.6.b menunjukkan aturan sintaksis yang digunakan untuk melakukan penambahan atribut atau kolom pada suatu tabel.

(a)

(b)

Gambar 4.6. Pernyataan ALTER TABLE

Contoh Soal 4.2. Buatlah pernyataan ALTER TABLE pada DBMS SQLite yang dapat digunakan untuk merubah nama tabel atau relasi yang dinamakan customer dan memiliki schema diagram seperti gambar berikut menjadi sebuah relasi yang memiliki nama nasabah dan rubahlah tabel atau relasi nasabah tersebut dengan menambahkan 1 atribut baru yaitu atribut zipcode yang memiliki tipe data char(5):

Jawab : Untuk merubah nama tabel customer tabel nasabah dapat digunakan pernyataan : ALTER TABLE customer RENAME TO nasabah; Untuk menambahkan atribut baru yaitu zipcode dengan tipe data char(5) dapat digunakan pernyataan : ALTER TABLE nasabah

ADD COLUMN zipcode char(5); Hasil akhir dari 2 pernyataan ALTER TABLE diatas adalah tabel customer akan dirubah menjadi tabel nasabah yang memiliki 4 atribut seperti tampak pada schema diagram sebagai berikut :

ALTER TABLE x ADD COLUMN A1 D, ..., An D; Dimana : x : nama relasi atau tabel yang akan ditambah atributnya A1 ... A1 : atribut-atribut baru yang akan ditambahkan D1 ... Dn : tipe data dan constraint dari atribut atribut baru.

ALTER TABLE x RENAME TO y

Dimana : x : nama relasi atau tabel yang akan dirubah namanya y : nama relasi atau tabel yang baru


4.4. Data Query Language (DQL)

Pernyataan-pernyataan Data Query Language SQL digunakan untuk mendapatkan atau memperoleh kembali data-data yang telah disimpan pada basis data. Pernyataan dasar pada DQL adalah pernyataan SELECT – FROM - WHERE. Aturan Sintaksis dasar yang digunakan dalam Query adalah :

Gambar 4.7. Aturan Sintaksis Query SQL

Bentuk Query SQL diatas memiliki kesamaan dengan perintah query dalam aljabar relasional sebagai berikut.

))(( 21,,, 21 mPAAA rrrn

Seperti pada aljabar relasional, maka hasil dari pernyataan Query SQL adalah selalu berupa relasi atau tabel.

4.4.1. KLAUSA SELECT

Klausa SELECT pada Query SQL digunakan untuk menentukan daftar atribut yang diikut sertakan pada relasi (tabel) hasil dari query yang dilakukan. Kegunaan dari klausa SELECT memiliki kesamaan dengan kegunaan dan fungsi dari operator Projection (Π) pada query aljabar relasional.

loan_number branch_name amount

L-11 Round Hill 900

L-14 Downtown 1500

L-15 Perryridge 1500


L-17 Downtown 1000

L-23 Redwood 2000

L-93 Mianus 500

(a) Loan_schema (b) Isi Tabel/relasi loan

Gambar 4.8. Schema dan Isi Tabel loan

Jika diberikan suatu relasi atau tabel yang disebut relasi loan seperti pada gambar 4.8. diatas, dan diberikan query : SELECT branch_name FROM loan

Maka hasil dari query tersebut adalah sebuah relasi atau tabel seperti pada gambar 4.9. Dari gambar 4.9 jelas terlihat bahwa relasi atau tabel yang diperoleh dari query hanya akan menyertakan

SELECT A1, A2, ..., An FROM r1, r2, ..., rm WHERE P Dimana : Ai : atribut Ri : relasi / tabel P : predikat yang digunakan untuk menyaring tuple


1 atribut atau 1 kolom saja, yaitu kolom branch_name. Pada gambar 4.9 juga terlihat bahwa query SQL dapat menghasilkan tuple atau baris-baris yang memiliki nilai sama atau bersifat redundan.

branch_name

Round Hill

Downtown

Perryridge

Perryridge

Downtown

Redwood

Mianus

Gambar 4.9. Hasil Query SELECT branch_name FROM loan

SELECT DISTINCT

Klausa SELECT DISTINCT digunakan untuk menghilangkan tuple atau baris-baris yang bernilai sama atau redundan di tabel hasil yang diperoleh. Jika digunakan tabel loan seperti gambar 4.8 dan diberikan query :

SELECT DISTINCT branch_name FROM loan

Maka akan diperoleh tabel hasil atau relasi hasil seperti pada gambar 4.10. Dari gambar 4.10 dapat dilihat bahwa seluruh tuple atau baris dari tabel hasil akan bernilai unik atau tidak memiliki sifat redundan.

branch_name

Round Hill

Downtown

Perryridge

Redwood

Mianus

Gambar 4.10. Hasil Query SELECT DISTINCT branch_name FROM loan

SELECT ALL

Klausa SELECT ALL digunakan untuk mendapatkan seluruh tuple dari relasi hasil tanpa menghilangkan tuple atau baris yang bersifat redundan. Hasil pernyataan query SQL dengan Klausa SELECT ALL akan menghasilkan relasi atau tabel hasil yang sama dengan pernyataan query SQL dengan klausa SELECT, hal ini disebabkan oleh karena pernyataan query SELECT secara implisit akan menggunakan keyword ALL. Gambar 4.11 dibawah ini menunjukkan hasil dari query yang menggunakan klausa SELECT ALL.

branch_name

Round Hill

Downtown

Perryridge

Perryridge

Downtown

Redwood

Mianus

Gambar 4.11. Hasil Query SELECT ALL branch_name FROM loan


Perluasan Atribut pada Klausa SELECT

Pernyataan SELECT selain digunakan untuk memilih atribut yang terdapat dalam tabel, juga dapat digunakan untuk memperoleh nilai dari atribut-atribut yang bersifat perluasan. Contoh Atribut-atribut yang merupakan perluasan dari atribut yang terdapat dan diperoleh dari tabel-tabel di basis data antara lain meliputi fungsi matematis dan fungsi-fungsi lain yang didukung dan disediakan oleh DBMS yang sedang digunakan.

Pada gambar 4.12 ditunjukkan beberapa query SELECT dengan perluasan atribut berupa operasi matematis dan operasi yang menggunakan fungsi-fungsi yang didukung oleh DBMS SQLite.

4*2

8

date("now")

2020-04-26

(a) Hasil Query : SELECT 4*2 (b) Hasil Query : SELECT date(“now”)

random()

8618168456973194156

lower("TEST")

test

(c) Hasil Query : SELECT random() (d) Hasil Query : SELECT lower(“TEST”)

Gambar 4.12. Perluasan Atribut berupa operasi matematis, fungsi date(), random() dan lower() pada Query SELECT

Gambar 4.13 menunjukkan hasil query SQL SELECT yang menggunakan atribut berupa operasi

matematis terhadap nilai dari atribut amount di tabel loan .


L-11 Round Hill 900

L-14 Downtown 1500



L-17 Downtown 1000

L-23 Redwood 2000

L-93 Mianus 500

loan_number (amount*0.03)

L-11 27.0

L-14 45.0

L-15 45.0

L-16 39.0

L-17 30.0

L-23 60.0

L-93 15.0

(a) Tabel loan (c) Hasil Query :

SELECT loan_number, (amount*0.03) FROM loan

Gambar 4.13. Perluasan Atribut pada query SELECT


4.4.2. KLAUSA WHERE

Klausa WHERE digunakan untuk menambahkan pernyataan kondisional yang berisi kondisi atau syarat yang harus dipenuhi oleh tuple atau baris-baris dari tabel yang datanya akan dioperasikan. Pada aljabar relasional, operator yang memiliki kesamaan dengan klausa WHERE adalah operator select (σ).

Jika diberikan tabel loan seperti pada gambar 4.14.a , dan pengguna hendak mendapatkan baris-baris atau tuple yang memiliki nilai atribut amount > 1300 dan berasal dari cabang Perryridge, maka query yang digunakan adalah :

SELECT * FROM loan

WHERE amount > 1300 AND branch_name = “Perryridge”

Pada query diatas digunakan simbol (*) atau simbol asterisk yang berguna untuk menyatakan “all attribute” atau kolom yang dipilih adalah seluruh kolom yang ada pada relasi atau tabel yang digunakan pada query. Hasil dari query diatas adalah tabel atau relasi seperti yang tampak pada gambar 4.14.b.

Contoh Soal 4.3. Buatlah query SELECT untuk mendapatkan jumlah kredit yang masih dapat digunakan (credit_available) oleh setiap nasabah atau customer , jika diberikan tabel atau relasi credit_info sebagai berikut . Tabel credit_info

customer_name limit credit_balance

Curry 2000 1750

Hayes 1500 1500

Jones 6000 700

Smith 2000 400

Jawab : Untuk mendapatkan jumlah kredit yang masih dapat digunakan oleh setiap nasabah atau customer, maka dapat digunakan rumusan sebagai berikut :

Jumlah kredit yang masih dapat digunakan atau credit available = limit - credit_balance Berdasarkan rumusan diatas, maka untuk mendapatkan nilai credit_available (jumlah kredit yang

masih dapat digunakan oleh setiap nasabah) digunakan query sebagai berikut:

SELECT customer_name, (limit – credit_balance) FROM credit_info

Hasil dari query diatas adalah relasi atau tabel sebagai berikut :

customer_name limit-credit_balance

Curry 250

Hayes 0

Jones 5300

Smith 1600



L-11 Round Hill 900

L-14 Downtown 1500



L-17 Downtown 1000

L-23 Redwood 2000

L-93 Mianus 500



(a) Tabel loan

(b) Hasil Query : SELECT * FROM loan WHERE amount > 1300 AND branch_name = “Perryridge”

Gambar 4.14. Contoh Penggunaan Klausa WHERE pada query SELECT

Dari contoh diatas dapat disimpulkan bahwa penyataan kondisional atau predikat pada klausa WHERE dapat menyertakan operator-operator logika (AND, OR dan NOT), operator perbandingan, dan ekspresi aritmatika. Selain daripada operator-operator yang sudah disebutkan tersebut, masih terdapat beberapa operator yang dapat disertakan pada klausa WHERE, operator-operator ini antara lain adalah :

Operator BETWEEN Operator Between digunakan untuk menyatakan rentang nilai yang akan digunakan dalam proses pencocokan nilai suatu atribut dalam proses penyaringan tuple.

Operator LIKE Operator Like pada klausa WHERE umumnya digunakan untuk melakukan penyaringan tuple atau baris-baris berdasarkan pencocokan pola atau pattern matching yang dinyatakan dengan operator LIKE.

Operator IN Operator IN pada klausa WHERE digunakan untuk menyaring tuple atau baris-baris berdasarkan sejumlah nilai atribut yang diletakkan dalam himpunan di operator IN tersebut.

Gambar 4.15 dibawah ini menunjukkan contoh-contoh penggunaan operator BETWEEN, LIKE dan operator IN pada klausa WHERE di query SELECT.


L-11 Round Hill 900

L-14 Downtown 1500



L-17 Downtown 1000

L-23 Redwood 2000

L-93 Mianus 500



(a) Tabel loan (b) Hasil Query :

SELECT * FROM loan WHERE amount BETWEEN 1350 AND 1600



L-11 Round Hill 900


L-11 Round Hill 900

L-14 Downtown 1500

L-17 Downtown 1000

(c) Hasil Query : SELECT * FROM loan WHERE branch_name LIKE “Ro%”

(d) Hasil Query : SELECT * FROM loan WHERE branch_name IN (Round_Hill, Downtown)

Gambar 4.15. Contoh Penggunaan Operator BETWEEN, LIKE dan IN

Dari gambar diatas, khususnya pada gambar 4.15.c yaitu query SELECT yang menyertakan operator LIKE, dapat dilihat salah satu contoh penggunaan simbol wildcard %. Terdapat beberapa simbol karakter wildcard yang umum digunakan untuk membentuk pola atau pattern pada operator LIKE. Simbol-simbol karakter wildcard di SQL antara lain dapat dilihat pada tabel 4.1. sebagai berikut:

Tabel 4.1. Karakter Wildcard pada SQL

Karakter Wildcard

Kegunaan Didukung Oleh SQLite

% Menggantikan 0 atau lebih karakter Ya

_ Menggantikan 1 karakter Ya

[list karakter] Menunjukkan daftar atau list himpunan karakter yang akan dicocokkan

Tidak

[^list karakter] Atau [! list karakter]

Menunjukkan daftar atau list himpunan karakter yang tidak boleh ada di bagian yang akan dicocokkan

Tidak

Contoh Soal 4.4. Buatlah query SELECT untuk mendapatkan seluruh nama customer yang diawali oleh huruf g dan j dari tabel customer dibawah ini. Tabel customer

customer_name customer_street customer_city

Adams Spring Pittsfield Brooks Senator Brooklyn Curry North Rye Glenn Sand Hill Woodside Green Walnut Stamford Hayes Main Harrison

Johnson Alma Palo Alto Jones Main Harrison

Lindsay Park Pittsfield Smith North Rye Turner Putnam Stamford

Williams Nassau Princeton


4.4.3. KLAUSA FROM

Klausa FROM dalam query SQL berguna untuk menyebutkan daftar relasi/tabel yang akan digunakan dalam query tersebut. Klausa FROM memiliki keterkaitan dan kesamaan dengan operator Cartesian Product (X) pada aljabar relasional.

Jika diberikan 2 tabel atau 2 relasi yaitu relasi borrower dan relasi loan seperti pada gambar 4.16.a dan 4.16.b, dan terdapat query :

SELECT * FROM borrower,loan

Maka query SQL diatas akan ekivalen dengan query pada aljabar relasional sebagai berikut :

borrower X loan

Hasil query SQL dan aljabar relasional diatas adalah tabel hasil join antara baris-baris atau tuple pada tabel borrower dengan setiap baris (tuple) dari tabel loan, seperti tampak pada pada gambar 4.16.c.

customer_name loan_number

Hayes L-15 Jackson L-14 Smith L-11


L-11 Round Hill 900

L-14 Downtown 1500


(a) Tabel borrower (b) Tabel loan

Jawab : Query SELECT yang dapat digunakan untuk mendapatkan seluruh nama customer atau nasabah

yang diawali dengan karakter g dan j, tanpa mengizinkan adanya duplikasi pada tabel hasil adalah:

SELECT DISTINCT customer_name FROM customer WHERE customer_name LIKE “[gj]%”

Jika DBMS tidak mendukung karakter wildcard [ ], maka dapat digunakan query SQL sebagai berikut :

SELECT DISTINCT customer_name FROM customer WHERE (customer_name LIKE “g%”) OR (customer_name LIKE “j%”)

Hasil Query :

customer_name

Glenn Green

Johnson Jones


customer_name borrower.loan_number loan.loan_number branch_name amount

Hayes L-15 L-11 Round Hill 900

Hayes L-15 L-14 Downtown 1500

Hayes L-15 L-15 Perryridge 1500

Jackson L-14 L-11 Round Hill 900

Jackson L-14 L-14 Downtown 1500

Jackson L-14 L-15 Perryridge 1500

Smith L-11 L-11 Round Hill 900

Smith L-11 L-14 Downtown 1500

Smith L-11 L-15 Perryridge 1500

(c) Hasil Query : SELECT * FROM borrower, loan

Gambar 4.16. Penggunaan Klausa FROM

Untuk mendapatkan tabel hasil berupa Equi Join atau Inner Join berdasarkan kesamaan nilai

atribut loan_number di tabel borrower dan atribut loan number di tabel loan pada gambar 4.16.a dan gambar 4.16b maka dapat digunakan query Equi Join sebagai berikut :

SELECT * FROM borrower, loan WHERE borrower.loan_number = loan.loan_number

Tabel hasil query Equi Join diatas dapat dilihat pada gambar 4.17 sebagai berikut :











SELECT * FROM borrower,loan





SELECT * FROM borrower, loan WHERE borrower.loan_number = loan.loan_number

Gambar 4.17. Hasil Equi Join tabel borrower dan tabel loan berdasarkan atribut loan_number


4.4.4. Klausa AS

Klausa AS digunakan untuk melakukan operasi rename. Aturan Sintaksis yang digunakan pada klausa AS adalah :

nama_lama AS nama_baru

Contoh penggunakan klausa AS dapat dilihat pada query sebagai berikut :

SELECT customer_name, borrower.loan_number AS loan_id, amount FROM borrower, loan WHERE borrower.loan_number = loan.loan_number

Query diatas akan menghasilkan suatu relasi/tabel yang memiliki 3 atribut yaitu customer_name, amount dan loan_id, dimana loan_id adalah nama atribut yang digunakan untuk mengganti nama atribut loan_number pada tabel hasil query. Hasil Query dapat dilihat pada gambar 4.18 sebagai berikut.




L-11 Round Hill 900

L-14 Downtown 1500



customer_name loan_id branch_name amount

Hayes L-15 Perryridge 1500

Jackson L-14 Downtown 1500

Smith L-11 Round Hill 900

(c) Hasil Query : SELECT customer_name,

borrower.loan_number AS loan_id, amount FROM borrower, loan WHERE borrower.loan_number = loan.loan_number

Gambar 4.18. Penggunaan Klausa AS

Variable Tuple

Klausa AS juga dapat digunakan untuk membuat variabel yang disebut sebagai variabel tuple. Ciri

dari variabel tuple pada SQL antara lain adalah variabel tuple dibuat dengan menggunakan klausa

AS pada bagian klausa FROM

Contoh penggunaan klausa AS untuk menghasilkan suatu variabel tuple dapat dilihat pada query

sebagai berikut.


SELECT customer_name, T.loan_number, S.amount

FROM borrower as T, loan as S

WHERE T.loan_number = S.loan_number ;

Pada query diatas maka variabel tuple yang dibuat adalah variabel tuple T yang akan berisi seluruh

tuple dari tabel borrower dan variabel tuple S yang berisi seluruh tuple dari tabel relasi loan.

Salah satu kegunaan dari variabel tuple adalah memudahkan pembuatan query yang akan

membandingkan baris-baris atau tuple yang diperoleh dari relasi atau tabel yang sama. Pada query

berikut diberikan contoh query yang digunakan untuk mendapatkan seluruh nama cabang yang

memiliki aset lebih besar dari minimal salah satu cabang yang berlokasi di Brooklyn.

SELECT DISTINCT T.branch_name

FROM branch AS T, branch AS S

WHERE T.assets > S.assets AND S.branch_city = ‘ Brooklyn’

Pada query diatas, maka baik variabel tuple T dan variabel tuple S akan menunjuk sejumlah

tuple atau baris pada tabel yang sama yaitu tabel branch. Hasil dari query diatas dapat dilihat pada

gambar 4.19 sebagai berikut.

branch_name branch_city assets

Brighton Brooklyn 7100000 Downtown Brooklyn 9000000

Mianus Horseneck 400000 North Town Rye 3700000 Perryridge Horseneck 1700000

Pownal Bennington 300000 Redwood Palo Alto 2100000 Round Hill Horseneck 8000000

(a) Tabel branch

branch_name

Downtown Round Hill

(b) Hasil Query : SELECT DISTINCT T.branch_name FROM branch AS T, branch AS S WHERE T.assets > S.assets AND S.branch_city = ‘ Brooklyn’

Gambar 4.19. Penggunaan Variabel Tuple


4.4.5. Klausa ORDER BY

Klausa ORDER BY pada query SQL, digunakan untuk untuk mengurutkan tuple atau baris-baris tabel hasil dari query berdasarkan nilai-nilai yang ada pada 1 atau lebih kolom di tabel hasil query tersebut. Metode pengurutan yang dilakukan dapat berupa pengurutan menaik (ascending) maupun pengurutan menurun (descending). Jika pada klausa ORDER BY, metode pengurutan tidak dinyatakan secara eksplisit, maka metode pengurutan yang digunakan secara default adalah metode pengurutan menaik (ascending).

Aturan sintaksis yang digunakan untuk menyatakan klausa ORDER BY pada SQL Query adalah sebagai berikut :

SELECT A1, A2, ... , An FROM table_name ORDER BY A1 ASC|DESC, A2 ASC|DESC ,..., An ASC|DESC;

Contoh penggunaan klausa ORDER BY dapat dilihat pada query sebagai berikut :

SELECT DISTINCT customer_name

FROM borrower, loan

WHERE borrower loan_number = loan.loan_number AND branch_name = ‘Perryridge’

ORDER BY customer_name

Query diatas akan menghasilkan tabel yang terdiri dari 1 kolom yaitu customer_name yang akan

berisi urutan menaik dari nama-nama nasabah yang memiliki pinjaman di cabang Perryridge. Hasil

query dapat dilihat pada gambar 4.20 sebagai berikut.

customer_name account_number

Adams L-16

Curry L-93

Hayes L-15

Jackson L-14

Jones L-17

Smith L-11

Smith L-23


L-11 Round Hill 900

L-14 Downtown 1500



L-17 Downtown 1000

L-23 Redwood 2000

L-93 Mianus 500

(b) Tabel borrower (b) Tabel loan

customer_name

Adams

Hayes

(c) Hasil Query : SELECT customer_name

FROM borrower, loan WHERE borrower.loan_number = loan.loan_number AND branch_name = “Perryridge” ORDER BY customer_name

Gambar 4.20. Penggunaan Klausa ORDER BY


4.4.6. Operasi Himpunan Pada Query SELECT

Untuk melakukan operasi himpunan terhadap tabel-tabel pada basis data atau tabel-tabel hasil Query SELECT, maka pada Data Query Language SQL dikenal beberapa operator himpunan SQL. Operator-operator himpunan ini antara lain adalah : UNION, UNION ALL, INTERSECT,dan EXCEPT.

Operasi himpunan yaitu : UNION, INTERSECT, dan EXCEPT pada SQL merupakan operasi-operasi yang menyerupai operasi dari operator aljabar relasional U (union) , ∩ (Intersec�on) dan – (Set Difference). Seperti pada aljabar relasional, maka tabel-tabel yang dapat dioperasikan dengan operator UNION, INTERSECT dan EXCEPT harus bersifat kompatibel yaitu memiliki jumlah kolom atau atribut yang sama dan operator UNION, INTERSECT dan EXCEPT akan secara otomatis mengeliminasi tuple atau baris-baris yang bersifat redundan.

Contoh Soal 4.5. Jika diberikan tabel borrower dan tabel loan sebagai berikut :


Adams L-16

Curry L-93

Hayes L-15

Jackson L-14

Jones L-17

Smith L-11

Smith L-23


L-11 Round Hill 900

L-14 Downtown 1500



L-17 Downtown 1000

L-23 Redwood 2000

L-93 Mianus 500

Tabel borrower Tabel loan Tentukanlah query SELECT yang dapat digunakan untuk menampilkan tabel yang berisi seluruh nama peminjam, nama cabang dan besar pinjaman yang terurut menaik berdasarkan nama cabang dan terurut menurun berdasarkan nama customer Jawab : Untuk mendapatkan nama peminjam, nama cabang dan besar pinjaman yang terurut menaik

berdasarkan nama cabang dan nama customer dapat digunakan query sebagai berikut :

SELECT branch_name, customer_name,amount FROM borrower, loan WHERE borrower.loan_number = loan.loan_number ORDER BY branch_name, customer_name

Tabel hasil query :

branch_name customer_name amount

Downtown Jackson 1500

Downtown Jones 1000

Mianus Curry 500

Perryridge Adams 1300

Perryridge Hayes 1500

Redwood Smith 2000

Round Hill Smith 900


Contoh penggunaan operator UNION dapat dilihat pada query sebagai berikut : SELECT customer_name FROM depositor UNION SELECT customer_name FROM borrower

Query diatas digunakan untuk mendapatkan seluruh nama nasabah, baik yang memiliki tabungan atau pinjaman (loan) atau memiliki keduanya. Gambar 4.21 berikut menunjukkan hasil eksekusi dari query diatas.


Adams L-16 Curry L-93 Hayes L-15

Jackson L-14 Jones L-17 Smith L-11 Smith L-23

Williams L-17


Hayes A-102 Johnson A-101 Johnson A-201

Jones A-217 Lindsay A-222 Smith A-215 Turner A-305

Johnson A-099

(a) Tabel borrower (b) Tabel depositor

customer_name

Adams Curry Hayes

Jackson Johnson

Jones Lindsay Smith Turner

Williams

(c) Hasil Query : SELECT customer_name FROM depositor UNION

SELECT customer_name FROM borrower

Gambar 4.21. Penggunaan Operator UNION Contoh penggunaan operator INTERSECT dapat dilihat pada query sebagai berikut :

SELECT customer_name FROM depositor INTERSECT SELECT customer_name FROM borrower

Query diatas digunakan untuk mendapatkan seluruh nama nasabah, yang memiliki tabungan (account) dan pinjaman (loan). Gambar 4.22 berikut menunjukkan hasil eksekusi dari query yang menyertakan operator INTERSECT tersebut.





Williams L-17




Johnson A-099


customer_name

Hayes Jones Smith

(c) Hasil Query : SELECT customer_name FROM depositor INTERSECT


Gambar 4.22. Penggunaan Operator INTERSECT

Contoh penggunaan operator EXCEPT dapat dilihat pada query sebagai berikut :

SELECT customer_name FROM depositor EXCEPT SELECT customer_name FROM borrower

Query diatas digunakan untuk mendapatkan seluruh nama nasabah, yang hanya memiliki tabungan (account) dan tidak memiliki pinjaman (loan). Gambar 4.23 berikut menunjukkan hasil eksekusi dari query yang menyertakan operator EXCEPT tersebut.




Williams L-17




Johnson A-099


customer_name

Johnson Lindsay Turner

(c) Hasil Query : SELECT customer_name FROM depositor EXCEPT


Gambar 4.23. Penggunaan Operator EXCEPT


Dari Contoh-contoh yang telah dipaparkan, maka terlihat hasil operator UNION, INTERSECT dan EXCEPT secara otomatis akan mengeliminasi baris-baris yang bersifat redundan di tabel hasil query. Untuk mempertahankan baris-baris yang bersifat redundan khususnya pada operator UNION, maka pada SQL dapat digunakan keyword ALL setelah pernyataan operator UNION. Contoh penggunaan UNION ALL dapat dilihat pada gambar 4.24. berikut.




Williams L-17




Johnson A-099


customer_name

Hayes Johnson Johnson

Jones Lindsay Smith Turner

Johnson Adams Curry Hayes

Jackson Jones Smith Smith

Williams

(c) Hasil Query : SELECT customer_name FROM depositor UNION ALL


Gambar 4.24. Penggunaan Operator UNION ALL Dari gambar 4.24. c dapat dilihat bahwa pada hasil operasi dengan operator UNION ALL, maka baris-baris yang bersifat redundan tidak akan dieliminasi.

4.4.7. Fungsi Agregasi

Fungsi agregasi adalah fungsi yang menggunakan satu atau lebih himpunan nilai sebagai masukan dan akan mengembalikan 1 nilai saja sebagai keluarannya. Fungsi-fungsi agregasi yang dapat digunakan pada query SQL antara lain adalah :


AVG()

MIN()

MAX()

SUM()

COUNT()

Fungsi Agregasi COUNT()

Fungsi agregasi COUNT() akan mengembalikan jumlah tuple atau baris dari tabel hasil query.

Penggunaan fungsi agregasi COUNT() antara lain dapat dilihat dari contoh-contoh berikut :

SELECT COUNT (*) FROM depositor Query diatas digunakan untuk mendapatkan jumlah baris atau tuple yang terdapat pada tabel

depositor.

SELECT COUNT (customer_name) FROM depositor Query diatas digunakan untuk mendapatkan jumlah nama-nama nasabah yang terdapat pada tabel

depositor

SELECT COUNT (DISTINCT customer_name) FROM depositor Query diatas digunakan untuk mendapatkan jumlah nama-nama nasabah yang berbeda dari tabel

depositor

Hasil dari contoh-contoh diatas dapat dilihat pada Gambar 4.25. dibawah ini :




Johnson A-099

(a) Tabel depositor

count (*)

8

count (customer_name)

8

count (distinct customer_name)

6

(b) Hasil Query : SELECT COUNT (*) FROM depositor

(c) Hasil Query : SELECT COUNT (customer_name) FROM depositor

(d) Hasil Query : SELECT COUNT (DISTINCT customer_name) FROM depositor

Gambar 4.25. Penggunaan Fungsi Agregasi COUNT()

Fungsi Agregasi MIN() dan Fungsi Agregasi MAX()

Fungsi agregasi MIN() digunakan untuk mendapatkan nilai terkecil dari kolom yang dipilih, sedangkan fungsi agregasi MAX() digunakan untuk mendapatkan nilai terbesar dari kolom yang dipilih. Contoh-contoh dibawah ini menunjukkan penggunaan fungsi agregasi MIN() dan dan fungsi agregasi MAX().


SELECT customer_name, MIN (amount) FROM borrower,loan WHERE borrower.loan_number=loan.loan_number

Query diatas digunakan untuk mendapatkan nama peminjam dengan besar pinjaman terkecil yang ada pada tabel hasil join antara tabel borrower dengan tabel loan.

SELECT customer_name, MAX (amount) FROM borrower,loan WHERE borrower.loan_number=loan.loan_number

Query diatas digunakan untuk mendapatkan nama peminjam dengan besar pinjaman terbesar yang ada pada tabel hasil join antara tabel borrower dengan tabel loan.

Gambar 4.26 dibawah ini menunjukkan hasil dari kedua query diatas.




Williams L-17


L-11 Round Hill 900 L-14 Downtown 1500 L-15 Perryridge 1500 L-16 Perryridge 1300 L-17 Downtown 1000 L-23 Redwood 2000 L-93 Mianus 500


customer_name MIN(amount)

Curry 500

customer_name MAX(amount)

Smith 2000

(c) Hasil Query : SELECT customer_name, MIN(amount) FROM borrower, loan WHERE borrower.loan_number = loan.loan_number

(d) Hasil Query : SELECT customer_name, MAX(amount) FROM borrower, loan WHERE borrower.loan_number = loan.loan_number

Gambar 4.26. Penggunaan Fungsi Agregasi MIN() dan MAX()

Fungsi Agregasi SUM() dan AVG()

Fungsi agregasi SUM() digunakan untuk mendapatkan jumlah total nilai dari kolom yang dipilih, sedangkan fungsi agregasi AVG() digunakan untuk mendapatkan nilai rata-rata dari kolom yang dipilih. Contoh-contoh dibawah ini menunjukkan penggunaan fungsi agregasi SUM() dan dan fungsi agregasi AVG().

SELECT AVG (amount) FROM loan

Query diatas digunakan untuk mendapatkan nilai rata-rata dari seluruh nilai pinjaman di tabel loan.

SELECT SUM (amount) FROM loan

Query diatas digunakan untuk mendapatkan total jumlah nilai pinjaman yang ada pada tabel loan.

Gambar 4.27 berikut ini menunjukkan hasil dari kedua query diatas.




(a) Tabel loan

AVG(amount)

1242. 85714285714

SUM(amount)

8700

(b) Hasil Query : SELECT AVG(amount) FROM loan

(c) Hasil Query : SELECT SUM(amount) FROM loan

Gambar 4.27. Penggunaan Fungsi Agregasi AVG() dan SUM()

4.4.8. Klausa GROUP BY

Klausa GROUP BY digunakan untuk melakukan pengelompokkan. Pengelompokkan seringkali digunakan bersama dengan fungsi-fungsi agregasi. Hal ini terjadi, karena dengan mengelompokkan tuple atau baris, maka fungsi-fungsi agregasi akan dapat dioperasikan pada hasil pengelompokkan tersebut. Contoh penggunaan klausa GROUP BY dapat dilihat pada query sebagai berikut :

SELECT branch_name, COUNT (DISTINCT customer_name) FROM depositor, account WHERE depositor.account_number =account.account_number GROUP BY branch_name

Query diatas digunakan untuk mendapatkan jumlah nasabah yang berbeda pada setiap cabang. Hasil dari query tersebut dapat dilihat pada gambar 4.28 sebagai berikut.




Johnson A-099

account_number branch_name balance

A-102 Perryridge 400 A-201 Brighton 900 A-215 Mianus 700 A-217 Brighton 750 A-222 Redwood 700 A-305 Round Hill 350 A-101 Downtown 500 A-100 Perryridge 500

(a) Tabel depositor (b) Tabel account


branch_name COUNT (DISTINCT customer_name)

Brighton 2 Downtown 1

Mianus 1 Perryridge 1 Redwood 1 Round Hill 1

(c) Hasil Query : SELECT branch_name, COUNT (DISTINCT customer_name) FROM depositor, account WHERE depositor.account_number =account.account_number GROUP BY branch_name

Gambar 4.28. Penggunaan Klausa GROUP BY Dari gambar diatas dapat dilihat, bahwa hasil query berupa jumlah nasabah akan dikelompokkan berdasarkan nama cabang yang ada. 4.4.9. Klausa HAVING

Klausa HAVING pada query SQL digunakan bersama GROUP BY untuk menambahkan predikat pada pengelompokkan. Contoh dibawah ini menunjukkan penggunaan klausa HAVING pada query SQL.

SELECT branch_name, AVG (amount) FROM loan GROUP BY branch_name HAVING AVG(amount) > 500 Klausa HAVING pada query diatas digunakan untuk menambahkan predikat yang akan

mensyaratkan, bahwa tuple atau baris-baris dari tabel hasil haruslah berisi baris yang memiliki nilai atribut nama cabang yang rata-rata peminjamnya memiliki pinjaman > 500. Gambar 4.29.c menunjukkan hasil query SQL tersebut.



(a) Tabel loan

branch_name AVG (amount)

Downtown 1250.0 Mianus 500.0

Perryridge 1400.0 Redwood 2000.0 Round Hill 900.0

branch_name AVG (amount)

Downtown 1250.0 Perryridge 1400.0 Redwood 2000.0 Round Hill 900.0

(b) Hasil Query : SELECT branch_name, AVG(amount) FROM loan GROUP BY branch_name

(c) Hasil Query : SELECT branch_name, AVG(amount) FROM loan GROUP BY branch_name HAVING AVG(amount) > 500

Gambar 4.29. Penggunaan Klausa HAVING


Klausa HAVING memiliki kesamaan dengan klausa WHERE pada query SQL yaitu keduanya digunakan untuk menambahkan predikat atau pernyataan kondisional pada query SQL, walaupun demikian kedua klausa ini memiliki perbedaan yang penting yaitu :

predikat pada klausa WHERE diaplikasikan sebelum pengelompokkan dilakukan.

Predikat pada klausa HAVING diaplikasikan setelah pengelompokkan dilakukan.

4.4.10. SubQuery atau Nested Query

SQL menyediakan mekanisme untuk menggunakan subquery yaitu query dengan bentuk query SELECT yang bersarang pada pernyataan query SELECT, pernyataan INSERT, UPDATE DELETE atau bersarang pada subquery lainnya.

Subquery juga sering disebut sebagai inner query (query di sisi dalam), sedangkan pernyataan query yang didalamnya berisi subquery akan dinamakan sebagai outer query (query di sisi luar). Jika subquery akan ditempatkan pada query SELECT, maka subquery tersebut dapat ditempatkan pada klausa SELECT, klausa FROM dan pada klausa WHERE.

Jika terdapat query yang memiliki subquery dan meletakkan subquery tersebut pada klausa WHERE, maka query tersebut umumnya digunakan untuk :

mendapatkan kenggotaan dari suatu relasi atau himpunan,

melakukan perbandingan antar himpunan

mendapatkan kardinalitas dari himpunan.

Contoh dari penggunaan subquery pada klausa WHERE untuk mendapatkan dan menguji keanggotaan dari suatu relasi atau himpunan dapat dilihat pada query sebagai berikut :

SELECT DISTINCT customer_name FROM borrower WHERE customer_name IN (SELECT customer_name FROM depositor )

Query diatas adalah query yang digunakan untuk mendapatkan seluruh nama customer atau nasabah yang memiliki tabungan sekaligus juga memiliki pinjaman. Kegunaan subquery di argumen fungsi IN() pada klausa WHERE di contoh query diatas adalah untuk mendapatkan seluruh nama nasabah yang memiliki tabungan. Hasil dari subquery ini akan digunakan oleh outer query untuk mendapatkan seluruh nama nasabah yang memiliki tabungan sekaligus juga memiliki pinjaman. Gambar 4.30 dibawah ini menunjukkan hasil dari query diatas.




Williams L-17




Johnson A-099



customer_name

Hayes Jones Smith

(c) Hasil Query : SELECT DISTINCT customer_name FROM borrower WHERE customer_name IN (SELECT customer_name FROM depositor )

Gambar 4.30. Penggunaan Subquery Fungsi EXISTS()

Fungsi EXISTS() sering digunakan bersama dengan subquery untuk menguji apakah suatu relasi merupakan sebuah relasi yang memiliki sejumlah tuple atau merupakan suatu relasi berupa himpunan kosong. Fungsi EXISTS() akan menghasilkan nilai TRUE jika argumennya yaitu suatu subquery bukan merupakan himpunan kosong, sedangkan fungsi NOT EXISTS() akan menghasilkan nilai TRUE jika argumennya yaitu suatu subquery menghasilkan sebuah himpunan kosong.

Contoh Query yang menggunakan subquery sebagai argumen fungsi NOT EXISTS() pada klausa WHERE, dapat dilihat pada query sebagai berikut :

SELECT DISTINCT S.customer_name FROM depositor as S WHERE NOT EXISTS ( SELECT branch_name FROM branch WHERE branch_city = 'Brooklyn' EXCEPT SELECT R.branch_name FROM depositor as T, account as R WHERE T.account_number =R.account_number

AND S.customer_name = T.customer_name)

Query diatas adalah query yang digunakan untuk mendapatkan customer yang memiliki account di setiap cabang (branch) yang berlokasi di Brooklyn. Hal ini dapat terjadi karena pada subquery :

SELECT branch_name FROM branch WHERE branch_city = ‘Brooklyn’

akan dihasilkan seluruh nama cabang di Brooklyn sedangkan subquery :

SELECT R.branch_name FROM depositor as T, account as R WHERE T.account_number =R.account_number AND S.customer_name = T.customer_name

akan menghasilkan nama-nama cabang tempat customer menyimpan tabungannya, sehingga pernyataan query :

SELECT branch_name FROM branch WHERE branch_city = 'Brooklyn' EXCEPT SELECT R.branch_name FROM depositor as T, account as R WHERE T.account_number =R.account_number AND S.customer_name = T.customer_name


hanya akan menghasilkan himpunan kosong, bilamana kedua subquery pada query tersebut merupakan tabel yang memiliki tuple atau baris yang sama. Gambar 4.31 menunjukkan hasil query dari contoh query dengan fungsi NOT EXISTS() seperti yang telah dibahas diatas.






Johnson A-099

(a) Tabel account (b) Tabel depositor

branch_name branch_city assets

Brighton Brooklyn 7100000 Downtown Brooklyn 9000000

Mianus Horseneck 400000 North Town Rye 3700000 Perryridge Horseneck 1700000

Pownal Bennington 300000 Redwood Palo Alto 2100000 Round Hill Horseneck 8000000

customer_name

Johnson

(d) Hasil Query :

SELECT DISTINCT S.customer_name FROM depositor as S WHERE NOT EXISTS ( SELECT branch_name FROM branch

WHERE branch_city = 'Brooklyn' EXCEPT

SELECT R.branch_name FROM depositor as T, account as R

WHERE T.account_number = R.account_number AND S.customer_name = T.customer_name)

(c) Tabel branch

Gambar 4.31. Penggunaan Subquery dan Fungsi NOT EXISTS()

Subquery Pada Klausa FROM

Pada query SQL, subquery juga dapat diletakkan pada klausa FROM. Jika subquery diletakkan

pada klausa FROM, maka akan terbentuk relasi yang disebut sebagai relasi turunan atau derived

relation.

Contoh query SQL ynag menggunakan subquery yang diletakkan pada klausa FROM dapat

dilihat pada query sebagai berikut :

SELECT branch_name, avg_balance FROM (SELECT branch_name, AVG (balance) AS avg_balance FROM account AS branch_avg GROUP BY branch_name) WHERE avg_balance > 500

Query diatas menggunakan sebuah subquery yang akan menghasilkan suatu relasi turunan dengan nama relasi branch_avg yang memiliki 2 atribut yaitu branch_name dan avg_balance. Pada outer


query, relasi branch_avg akan digunakan untuk mendapatkan nama-nama cabang dengan rata-rata nilai tabungan nasabahnya lebih besar dari 500. Gambar 4.32. dibawah ini menunjukkan hasil penggunaan subquery pada klausa FROM, seperti yang telah dijabarkan diatas.



branch_name avg_balance

Brighton 825.0 Downtown 500.0

Mianus 700.0 Perryridge 450.0 Redwood 700.0 Round Hill 350.0

(a) Tabel account (b) Relasi turunan branch_avg hasil subquery :

SELECT branch_name, avg (amount) AS avg_balance FROM account as branch_avg GROUP BY branch_name

branch_name avg_balance

Brighton 825.0 Mianus 700.0

Redwood 700.0

(c) Hasil Query : SELECT branch_name, avg_balance FROM (SELECT branch_name, avg (amount) AS avg_balance FROM account as branch_avg GROUP BY branch_name) WHERE avg_balance > 500

Gambar 4.32. Penggunaan Subquery pada klausa FROM

4.4.11. Klausa WITH

Klausa WITH pada SQL dapat digunakan untuk menampilkan query yang bersifat kompleks

dengan lebih terstruktur, karena dengan klausa WITH dapat dibuat sebuah tabel atau relasi yang

bersifat sementara dan dapat digunakan oleh query dimana tabel atau relasi sementara tersebut

dinyatakan. Contoh penggunaan klausa WITH pada SQL dapat dilihat pada query sebagai berikut :

WITH max_amount (amount_value) AS (SELECT max (amount) FROM loan) SELECT loan_number, amount_value FROM loan, max_amount WHERE loan.amount = max_amount.amount_value

Query diatas adalah query yang digunakan untuk mendapatakan loan_number yang memiliki nilai

pinjaman yang terbesar. Pernyataan WITH diatas akan menyebabkan terbentuknya suatu tabel

sementara bernama max_amount dengan 1 atribut yaitu amount_value yang nilainya adalah besar


pinjaman terbesar yang ada pada tabel loan. Tabel max_amount ini dapat digunakan pada query

dengan klausa WITH untuk menampilkan loan number yang memiliki nilai pinjaman terbesar, beserta

nilai pinjaman terbesar tersebut.



max (amount)

2000

(a) Tabel loan (b) Hasil Query SELECT max (amount) FROM loan

loan_number amount_value

L-23 2000

(c) Hasil Query : WITH max_amount (amount_value) AS (SELECT max (amount) FROM loan) SELECT loan_number, amount_value FROM loan, max_amount WHERE loan.amount = max_amount.amount_value

Gambar 4.32. Penggunaan Klausa WITH

4.4.12. JOIN

Pernyataan JOIN pada dasarnya adalah pernyataan SQL yang digunakan untuk

menyederhanakan pernyataan operasi cartesian product diantara 2 relasi atau tabel yang ada dalam

suatu basis data relasional. Contoh penggunaan pernyataan JOIN pada SQL antara lain adalah

sebagai berikut :

SELECT * FROM borrower JOIN loan

Pernyataan query SQL diatas adalah ekivalen dengan query SQL sebagai berikut :

SELECT * FROM borrower, loan

Pada aljabar relasional kedua query tersebut akan ekivalen dengan ekspresi sebagai berikut :

borrower X loan

Hasil query SQL dan aljabar relasional diatas adalah sebuah tabel yang berisi join antara tuple (baris-baris pada tabel) atau record pada tabel borrower dengan setiap tuple atau record dari tabel loan, seperti tampak pada pada gambar 4.33.c.





L-11 Round Hill 900

L-14 Downtown 1500


(b) Tabel borrower (b) Tabel loan











(c) Hasil Query : SELECT * FROM borrower JOIN loan

Gambar 4.33. Penggunaan JOIN

Dari Contoh diatas, dapat disimpulkan bahwa operasi join pada SQL akan menggunakan 2 relasi

atau tabel sebagai masukan dan akan mengembalikan sebuah relasi baru sebagai hasil dari operasi

join yang telah dilakukan.

Pada SQL, operasi join dapat diperluas sehingga tidak hanya dapat digunakan untuk

menyatakan operasi cartesian product tanpa kriteria, tetapi juga dapat menyertakan operasi join

dengan kriteria atau syarat tertentu.

Pernyataan join di SQL umumnya dibagi menjadi 2 bagian yaitu:

Bagian Tipe Join (Join Type)

Bagian Kriteria Join (Join Condition)

Tipe-tipe join yang ada pada SQL , antara lain adalah :

JOIN

INNER JOIN

CROSS JOIN

UNION JOIN (tidak didukung oleh DBMS SQLite)

LEFT OUTER JOIN

RIGHT OUTER JOIN (tidak didukung oleh DBMS SQLite)

FULL OUTER JOIN (tidak didukung oleh DBMS SQLite)


Kriteria join (Join Condition) adalah bagian pernyataan join yang digunakan untuk menentukan

kriteria dalam memasangkan tuple (baris) atau record di kedua relasi yang di-join-kan. Jenis-jenis

join condition pada SQL, antara lain adalah:

NATURAL

ON <predicate>

USING <A1,A2,...,An)

Keyword NATURAL umumnya diposisikan di awal pernyataan join sedangkan keyword ON dan

USING akan diposisikan di bagian akhir dari pernyataan join.

INNER JOIN INNER JOIN digunakan untuk melakukan cartesian product antara 2 tabel atau relasi. INNER

JOIN dapat menambahkan syarat atau kriteria dalam melakukan join antara 2 tabel dengan

menyertakan join condition NATURAL, join condition ON serta join condition USING. Contoh

penggunaan INNER JOIN dengan join condition ON dapat dilihat pada query SQL sebagai berikut :

SELECT * FROM borrower INNER JOIN loan ON borrower.loan_number = loan.loan_number ORDER BY borrower.loan_number

Hasil query diatas dapat dilihat pada gambar 4.34 sebagai berikut :




Williams L-17




customer_name borrower.loan_

number loan.loan_

number branch_name Amount

Smith L-11 L-11 Round Hill 900 Jackson L-14 L-14 Downtown 1500 Hayes L-15 L-15 Perryridge 1500 Adams L-16 L-16 Perryridge 1300 Jones L-17 L-17 Downtown 1000

Williams L-17 L-17 Downtown 1000 Smith L-23 L-23 Redwood 2000 Curry L-93 L-93 Mianus 500

(c) Hasil Query : SELECT * FROM borrower INNER JOIN loan ON borrower.loan_number=loan.loan_number ORDER BY borrower.loan_number

Gambar 4.34. Penggunaan INNER JOIN dengan join condition ON


Contoh pernyataan INNER JOIN yang menggunakan join condition USING dapat dilihat pada query dibawah ini :

SELECT * FROM borrower INNER JOIN loan USING (loan_number) ORDER BY borrower.loan_number

Hasil query diatas dapat dilihat pada gambar 4.35 sebagai berikut :




Williams L-17




customer_name loan_number branch_name amount

Smith L-11 Round Hill 900 Jackson L-14 Downtown 1500 Hayes L-15 Perryridge 1500 Adams L-16 Perryridge 1300 Jones L-17 Downtown 1000

Williams L-17 Downtown 1000 Smith L-23 Redwood 2000 Curry L-93 Mianus 500

(c) Hasil Query : SELECT * FROM borrower INNER JOIN loan USING (loan_number) ORDER BY borrower.loan_number

Gambar 4.35. Penggunaan INNER JOIN dengan join condition USING

Pada SQLite, keyword INNER pada pernyataan INNER JOIN adalah bersifat opsional yaitu

apabila keyword INNER tidak dinyatakan, maka akan diperoleh hasil query yang sama. Contoh query

yang tidak menggunakan keyword INNER dapat dilihat pada query sebagai berikut :

SELECT * FROM borrower JOIN loan ON borrower.loan_number = loan.loan_number ORDER BY borrower.loan_number

Query SQL diatas adalah ekivalen dengan pernyataan query dengan keyword INNER sebagai berikut : SELECT * FROM borrower INNER JOIN loan ON borrower.loan_number = loan.loan_number ORDER BY borrower.loan_number


CROSS JOIN

CROSS JOIN memiliki kegunaan dan fungsi yang sama dengan INNER JOIN yaitu digunakan untuk

melakukan cartesian product antara 2 tabel. Jika join yang diinginkan adalah equivalen join, maka

seperti pada tipe INNER JOIN, pada CROSS JOIN juga dapat disertakan join condition ON dan join

condition USING. Contoh penggunaan CROSS JOIN dengan join condition ON dapat dilihat pada

query SQL sebagai berikut :

SELECT * FROM borrower CROSS JOIN loan ON borrower.loan_number = loan.loan_number ORDER BY borrower.loan_number

Hasil query diatas adalah serupa dengan hasil query dengan INNER JOIN yang telah kita lihat hasilnya

di gambar 4.34.

Contoh pernyataan CROSS JOIN yang menggunakan join condition USING dapat dilihat pada query dibawah ini :

SELECT * FROM borrower CROSS JOIN loan USING (loan_number) ORDER BY borrower.loan_number

Hasil query diatas adalah serupa dengan hasil query dengan INNER JOIN yang telah kita lihat hasilnya di gambar 4.35. LEFT OUTER JOIN

Hasil pernyataan LEFT JOIN atau LEFT OUTER JOIN adalah seluruh tuple(baris) pada relasi atau

tabel yang berada di sebelah kiri pernyataan LEFT JOIN dan tuple(baris) atau record yang

merupakan pasangannya yang diperoleh dari relasi di sebelah kanan pernyataan LEFT JOIN. Jika

terdapat tuple(baris) atau record di relasi sebelah kiri tidak memiliki pasangan di relasi di sebelah

kanan, maka tuple(baris) tersebut akan dipasangkan dengan tuple(baris) yang memiliki nilai atribut

NULL. Contoh penggunaan LEFT OUTER JOIN dengan join condition ON dapat dilihat pada query

sebagai berikut :

SELECT * FROM depositor LEFT OUTER JOIN account

ON depositor.account_number = account.account_number ORDER BY depositor.account_number Atau SELECT * FROM depositor LEFT JOIN account

ON depositor.account_number = account.account_number ORDER BY depositor.account_number

Hasil kedua query diatas dapat dilihat pada gambar 4.36. sebagai berikut.





Johnson A-099



(a) Tabel depositor (b) Tabel account

customer_name depositor.

account_number account.


Johnson A-099 NULL NULL NULL Johnson A-101 A-101 Downtown 500 Hayes A-102 A-102 Perryridge 400

Johnson A-201 A-201 Brighton 900 Smith A-215 A-215 Mianus 700 Jones A-217 A-217 Brighton 750

Lindsay A-222 A-222 Redwood 700 Turner A-305 A-305 Round Hill 350

(c) Hasil Query : SELECT * FROM depositor LEFT JOIN account ON depositor.account_number = account.account_number ORDER BY depositor.account_number

Gambar 4.36. Penggunaan LEFT JOIN dengan join condition ON

Contoh penggunaan LEFT JOIN atau LEFT OUTER JOIN dengan join condition USING dapat dilihat pada query sebagai berikut :

SELECT * FROM depositor LEFT JOIN account

USING (account_number) ORDER BY depositor.account_number Atau SELECT * FROM depositor LEFT OUTER JOIN account

USING (account_number) ORDER BY depositor.account_number

Hasil kedua query diatas dapat dilihat pada gambar 4.37. sebagai berikut.





Johnson A-099



(b) Tabel depositor (b) Tabel account

customer_name account_number branch_name balance

Johnson A-099 NULL NULL Johnson A-101 Downtown 500 Hayes A-102 Perryridge 400

Johnson A-201 Brighton 900 Smith A-215 Mianus 700 Jones A-217 Brighton 750

Lindsay A-222 Redwood 700 Turner A-305 Round Hill 350

(c) Hasil Query : SELECT * FROM depositor LEFT JOIN account USING (account_number) ORDER BY depositor.account_number

Gambar 4.37. Penggunaan LEFT JOIN dengan join condition USING

RIGHT OUTER JOIN

Hasil query dengan RIGHT OUTER JOIN adalah seluruh tuple(baris) pada relasi atau tabel yang berada di sebelah kanan pernyataan RIGHT OUTER JOIN dan tuple(baris) yang merupakan pasangannya yang diperoleh dari relasi di sebelah kiri pernyataan RIGHT OUTER JOIN. Jika terdapat baris di relasi sebelah kanan tidak memiliki pasangan di relasi di sebelah kiri, maka tuple(baris) tersebut akan dipasangkan dengan baris yang memiliki nilai atribut NULL.

Pada basis data SQLite pernyataan RIGHT OUTER JOIN tidak didukung, tetapi karena pernyataan RIGHT OUTER JOIN bersifat simetris dengan LEFT OUTER JOIN, maka hasil dari RIGHT OUTER JOIN dapat diperoleh dengan cara mempertukarkan relasi di sisi kiri dan kanan pernyataan LEFT OUTER JOIN. FULL OUTER JOIN

Hasil query dengan FULL OUTER JOIN adalah seluruh tuple(baris) pada relasi atau tabel yang berada di sebelah kanan dan kiri pernyataan FULL OUTER JOIN dan seluruh tuple(baris) yang merupakan pasangannya yang diperoleh dari relasi di sebelah kiri dan kanan pernyataan FULL OUTER JOIN. Jika terdapat baris di relasi sebelah kanan tidak memiliki pasangan di relasi di sebelah kiri, maka baris tersebut akan dipasangkan dengan baris yang memiliki nilai atribut NULL. Sebaliknya jika terdapat baris di relasi sebelah kiri tidak memiliki pasanagan di relasi sebelah kanan, maka baris tersebut akan dipasangkan dengan baris yang memiliki nilai atribut NULL.


Pada basis data SQLite pernyataan FULL OUTER JOIN tidak didukung, tetapi hasil pernyataan FULL OUTER JOIN dapat diperoleh dengan menggabungkan (union) hasil query RIGHT OUTER JOIN dan LEFT OUTER JOIN. Hasil RIGHT OUTER JOIN dapat diperoleh dengan cara mempertukarkan relasi di sisi kiri dan kanan pernyataan LEFT OUTER JOIN.

Contoh Soal 4.6. Jika diberikan tabel depositor dan tabel account sebagai berikut :




Johnson A-099



Tabel depositor Tabel account

Tentukanlah query SELECT yang dapat digunakan pada dbms SQLite untuk menampilkan tabel hasil RIGHT OUTER JOIN dari relasi depositor dan account pada atribut account_number dan terurut menaik berdasarkan nama nasabah atau customer ! Jawab : Karena dbms SQLite tidak mendukung pernyataan RIGHT OUTER JOIN, maka untuk mendapatkan

hasil RIGHT OUTER JOIN tabel depositor dan account dapat digunakan pernyataan LEFT OUTER

JOIN dan mempertukarkan posisi depositor dengan posisi tabel account, yaitu :

SELECT customer_name,depositor.account_number,account.account_number, branch_name,balance

FROM account LEFT OUTER JOIN depositor ON account.account_number = depositor.account_number ORDER BY customer_name Tabel hasil query :

customer_name depositor.

account_number account.


NULL NULL A-100 Perryridge 500 Hayes A-102 A-102 Perryridge 400

Johnson A-201 A-201 Brighton 900 Johnson A-101 A-101 Downtown 500

Jones A-217 A-217 Brighton 750 Lindsay A-222 A-222 Redwood 700 Smith A-215 A-215 Mianus 700 Turner A-305 A-305 Round Hill 350


Contoh Soal 4.7. Jika diberikan tabel depositor dan tabel account sebagai berikut :




Johnson A-099



Tabel depositor Tabel account Tentukanlah query SELECT yang dapat digunakan pada dbms SQLite untuk menampilkan tabel hasil FULL OUTER JOIN dari relasi depositor dan account pada atribut account_number dan terurut menurun berdasarkan nama nasabah atau customer ! Jawab : Karena dbms SQLite tidak mendukung pernyataan FULL OUTER JOIN, maka untuk mendapatkan

hasil FULL OUTER JOIN tabel depositor dan account dapat digunakan penggabungan (union) 2

pernyataan LEFT OUTER JOIN dan mempertukarkan posisi depositor dengan posisi tabel account

di kedua pernyataan LEFT OUTER JOIN tersebut. Query SQL pada SQLite yang akan menghasilkan

tabel atau relasi yang ekivalen dengan tabel hasil FULL OUTER JOIN adalah:


FROM depositor LEFT OUTER JOIN account ON account.account_number = depositor.account_number UNION


FROM account LEFT OUTER JOIN depositor ON account.account_number = depositor.account_number ORDER BY customer_name DESC Tabel hasil query :

customer_name account_number account_number branch_name balance

Turner A-305 A-305 Round Hill 350 Smith A-215 A-215 Mianus 700

Lindsay A-222 A-222 Redwood 700 Jones A-217 A-217 Brighton 750

Johnson A-099 NULL NULL NULL Johnson A-101 A-101 Downtown 500 Johnson A-201 A-201 Brighton 900 Hayes A-102 A-102 Perryridge 400 NULL NULL A-100 Perryridge 500


NATURAL

Kriteria join NATURAL pada pernyataan join di SQL digunakan untuk melakukan join antara 2 relasi berdasarkan kesamaan nilai atribut dengan nama yang sama di kedua relasi tersebut. Pada join condition NATURAL, maka atribut-atribut yang menjadi dasar join tidak perlu disebutkan, karena kriteria join pada NATURAL mensyaratkan bahwa atribut yang digunakan untuk melakukan join adalah atribut-atribut dengan nama yang sama di kedua relasi yang di-join-kan. Contoh penggunaan join condition NATURAL dapat dilihat pada query SQL sebagai berikut.

SELECT * FROM borrower NATURAL JOIN loan

Pernyataan query SQL diatas adalah ekivalen dengan query –query SQL sebagai berikut :

SELECT * FROM borrower INNER JOIN loan USING (loan_number)

SELECT * FROM borrower JOIN loan USING (loan_number)

SELECT * FROM borrower CROSS JOIN loan USING (loan_number)

Hasil dari query-query diatas akan sama dengan hasil query pada gambar 4.35. yang telah dijelaskan sebelumnya. 4.5. Data Manipulation Language (DML)

Structure Query Language atau SQL juga dilengkapi dengan sejumlah perintah atau pernyataan yang dapat digunakan untuk melakukan manipulasi atau perubahan data pada basis data relasional. Manipulasi data pada basis data relasional antara lain dilakukan dengan melakukan penambahan atau penyisipan tuple (INSERT), penghapusan tuple (DELETE) dan pengubahan nilai atribut (UPDATE).

4.5.1. Penyisipan dan Penambahan Tuple atau Record (INSERT)

Cara yang dapat digunakan untuk melakukan penyisipan tuple atau record baru pada suatu tabel dalam basis data relasional, antara lain adalah dengan :

a. Menentukan dan menyatakan baris/tuple atau record yang akan disisipkan. Pernyataan SQL yang dapat digunakan dalam proses ini adalah pernyataan INSERT INTO dengan aturan sintaksis sebagai berikut :

INSERT INTO r [(A1, A2, ... , An) VALUES (V1,V2,...,Vn)]

Dimana : r : tabel atau relasi

A1,A2,...,An : nama atribut dari relasi / tabel V1,V2,...,Vn : nilai untuk setiap atribut

b. Mendapatkan baris/tuple atau record yang akan disisipkan dengan melakukan query SQL yaitu query SELECT, kemudian menyisipkan hasil query SQL tersebut ke dalam tabel. Pernyataan SQL yang dapat digunakan dalam proses ini adalah pernyataan INSERT INTO yang diikuti dengan query SELECT seperti ditunjukkan pada aturan sintaksis sebagai berikut : INSERT INTO r

(Query SELECT)


Query SQL dibawah ini adalah contoh-contoh pernyataan SQL yang dapat digunakan untuk menambahkan tuple(baris) atau record baru pada tabel depositor dan tabel account.

INSERT INTO depositor (customer_name,account_number) VALUES ('Jones', 'A-103'); INSERT INTO account (account_number,branch_name,balance) VALUES ('A-103', 'Downtown',750);

Hasil dari proses penyisipan diatas dapat dilihat pada gambar 4.38.c dan 4.38.d




Johnson A-099



(a) Tabel depositor sebelum penyisipan (b) Tabel account sebelum penyisipan




Johnson A-099 Jones A-103


A-102 Perryridge 400 A-201 Brighton 900 A-215 Mianus 700 A-217 Brighton 750 A-222 Redwood 700 A-305 Round Hill 350 A-101 Downtown 500 A-100 Perryridge 500 A-103 Downtown 750

(c) Tabel depositor sesudah penyisipan (d) Tabel account sesudah penyisipan

Pernyataan SQL untuk Penyisipan : INSERT INTO depositor (customer_name,account_number)

VALUES ('Jones', 'A-103'); INSERT INTO account (account_number,branch_name,balance)

VALUES ('A-103', 'Downtown',750);

Gambar 4.38. Penggunaan INSERT INTO – VALUES

Query SQL dibawah ini adalah contoh pernyataan SQL yang digunakan untuk memilih tuple(baris) atau record dengan query SELECT dan menyisipkannya sebagai record yang baru pada pada tabel depositor.

INSERT INTO depositor SELECT customer_name,loan_number FROM borrower WHERE loan_number = 'L-11'

Hasil dari query diatas adalah tuple atau record yang diperoleh dari tabel borrower yaitu record

dengan loan_number='L-11' akan disisipkan ke tabel depositor. Gambar 4.39 dibawah ini

menunjukkan hasil dari query tersebut.





Johnson A-099 Jones A-103




Williams L-17

(a) Tabel depositor sebelum penyisipan (b) Tabel borrower




Johnson A-099 Jones A-103 Smith L-11

(c) Tabel depositor sesudah penyisipan

Pernyataan SQL untuk Penyisipan : INSERT INTO depositor SELECT customer_name,loan_number

FROM borrower WHERE loan_number = 'L-11'

Gambar 4.39. Penggunaan INSERT INTO – SELECT

4.5.2. Pengubahan nilai atribut (UPDATE)

Pernyataan SQL yang dapat digunakan untuk mengubah nilai atribut adalah pernyataan yang menggunakan klausa UPDATE. Aturan sintaksis klausa UPDATE adalah :

UPDATE r SET assignment [WHERE P]

Dimana : r : tabel atau relasi yang nilai atributnya akan dirubah assignment : ekspresi pemberian nilai baru untuk suatu atribut yang nilainya akan dirubah P : predikat atau syarat atau kriteria pemilihan tuple / record yang nilai atributnya akan dirubah

Contoh pernyataan SQL untuk melakukan pengubahan suatu nilai atribut dapat dilihat pada perintah SQL sebagai berikut :

UPDATE account SET balance = 800 WHERE account_number = 'A-103'


Perintah SQL diatas akan menyebabkan pengubahan nilai atribut balance dari baris/tuple atau

record pada tabel account yang memiliki account_number = ‘L-11’. Gambar 4.40 dibawah ini

menunjukkan hasil dari perintah SQL tersebut.





(a) Tabel account sebelum update (b) Tabel account sesudah update

Pernyataan SQL untuk UPDATE : UPDATE account SET balance = 800 WHERE account_number = 'L-11'

Gambar 4.40. Penggunaan Perintah UPDATE

4.5.3. Penghapusan baris/tuple atau record (DELETE)

Pernyataan SQL yang dapat digunakan untuk menghapus tuple(baris) atau record dari suatu tabel(relasi) adalah perintah dengan menggunakan klausa DELETE. Aturan sintaksis klausa DELETE adalah :

DELETE FROM r [WHERE P]

Dimana : r : tabel atau relasi yang baris/tuple atau record-nya akan dihapus P : predikat berupa syarat atau kriteria pemilihan tuple / record yang akan dihapus

Contoh pernyataan SQL untuk melakukan penghapusan baris/tuple atau record dapat dilihat pada perintah SQL sebagai berikut :

DELETE FROM account WHERE account_number = 'A-103'

Perintah SQL diatas akan menyebabkan penghapusan baris di tabel account yang memiliki memiliki

account_number = ‘A-103’. Gambar 4.41 dibawah ini menunjukkan hasil dari perintah SQL tersebut.






(a) Tabel account sebelum DELETE (b) Tabel account sesudah DELETE

Pernyataan SQL untuk DELETE : DELETE FROM account WHERE account_number = 'A-103'

Gambar 4.41. Penggunaan Perintah DELETE

4.6. VIEW

SQL View adalah tabel atau relasi virtual (bukan tabel sebenarnya) yang dibuat dari tabel atau view lainnya. SQL view tidak memiliki data-data sendiri, tetapi data-datanya berasal dari tabel atau view lainnya. Fungsi dan kegunaan dari view antara lain adalah :

Dapat digunakan untuk menyembunyikan atribut (kolom) atau tuple dari suatu tabel yang tidak ingin ditunjukkan

Dapat digunakan untuk menampilkan hasil perhitungan dari sejumlah data yang bersumber dari tabel-tabel di basis data dimana view tersebut dibuat

Dapat digunakan untuk menyembunyikan perintah atau query SQL yang rumit

Dapat digunakan untuk membatasi akses data ke tabel sebenarnya

Dapat digunakan untuk menampilkan view yang berbeda-beda walaupun data-datanya diambil dari tabel-tabel atau relasi yang sama.

Pernyataan atau perintah SQL yang dapat digunakan untuk membuat suatu view pada sebuah basis data relasional adalah dengan menggunakan perintah CREATE VIEW. Aturan sintaksis CREATE VIEW adalah :

CREATE VIEW v AS <query expression>

Dimana :

v : nama view yang dibuat

<query expression> : ekspresi query SQL yang digunakan untuk membuat view yang diinginkan

Contoh pernyataan create view dapat dilihat pada perintah SQL dibawah ini : CREATE VIEW all_customer AS SELECT branch_name,customer_name FROM depositor NATURAL JOIN account UNION SELECT branch_name, customer_name FROM borrower NATURAL JOIN loan


Untuk contoh diatas, maka hasil yang diperoleh adalah :

Dibuat suatu view atau tabel virtual yang diberi nama all_customer

Tabel virtual all_customer akan terdiri dari 2 atribut yaitu branch_name dan customer_name

tabel virtual all_customer akan berisi seluruh nama customer atau nasabah baik peminjam atau penabung beserta cabang tempat nasabah tersebut meminjam atau menabung.

Gambar 4.42 dibawah ini menunjukkan hasil dari perintah SQL untuk membuat view seperti dicontohkan diatas.




Johnson A-099




Williams L-17

(a) Tabel depositor (b) Tabel borrower

branch_name customer_name

Brighton Johnson Brighton Jones

Downtown Jackson Downtown Johnson Downtown Jones Downtown Williams

Mianus Curry Mianus Smith

Perryridge Adams Perryridge Hayes Redwood Lindsay Redwood Smith Round Hill Smith Round Hill Turner

(c) Tabel virtual (view) all_customer

Pernyataan SQL untuk membuat view all_customer : CREATE VIEW all_customer AS

SELECT branch_name,customer_name FROM depositor NATURAL JOIN account

UNION SELECT branch_name, customer_name FROM borrower NATURAL JOIN loan

Gambar 4.42. Pernyataan SQL CREATE VIEW


5

SQLite 5.1. Tentang SQLite

SQLite Project dimulai pada tahun 2000 oleh Richard Dwayne Hipp. Para pengembang SQLite berharap agar SQLite dapat terus dikembangkan sampai tahun 2050, dimana para pengembang bersama SQLite Consortium (asosiasi yang didirikan untuk memberikan kontribusi berupa pendanaan untuk pengembangan SQLite) senantiasa berupaya untuk melanjutkan vitalitas dan independensi SQLite sehingga tetap menjadi perangkat lunak basis data yang berkualitas tinggi tetapi tetap berada dalam domain perangkat lunak yang bersifat public domain software. Para pengembang utama SQLite dan anggota dari SQLite Consortium pada tahun 2020, dapat dilihat pada gambar 5.1. sebagai berikut :

(a) Anggota-anggota pengembang SQLite

(b) Anggota – Anggota SQLite Consortium

Gambar 5.1. SQLite Developer dan SQLite Consortium


5.2. Definisi, Ciri-Ciri, Fitur dan Kegunaan RDBMS SQLite Definisi SQLite antara lain adalah :

SQLite is an in-process library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. (SQLite Documentation)

SQLite is an embedded SQL database engine. (SQLite Documentation)

SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine (SQLite Tutorial, https://www.tutorialspoint.com/sqlite/)

SQLite is a public-domain software package that provides a relational database management system, or RDBMS (Using SQLite - Jay A. Kreibich, O’Reilly Books)

SQLite is a relational database management system contained in a C programming library. In contrast to many other database management systems, SQLite is not a client–server database engine. Rather, it is embedded into the end program. (https://en.wikipedia.org/wiki/SQLite)

SQLite merupakan sebuah sistem manajemen basis data relasional yang bersifat ACID-compliant dan memiliki ukuran pustaka kode yang relatif kecil, ditulis dalam bahasa C. SQLite merupakan proyek yang bersifat public domain software yang dikerjakan oleh D. Richard Hipp. (https://id.wikipedia.org/wiki/SQLite)

Dari definisi diatas maka dapat diperoleh sejumlah fitur dan ciri yang dimiliki oleh SQLite yaitu antara lain : 1. Self-contained

SQLite memiliki ciri "stand-alone“ atau "self-contained" dalam pengertian bahwa SQLite memiliki sedikit ketergantungan. SQLite dapat dijalankan pada bermacam-macam sistem operasi dan tidak harus menggunakan external library selain daripada beberapa prosedur dan fungsi yang terdapat pada C-standard Library

2. Serverless SQLite tidak membutuhkan proses pada server di sistem yang terpisah dan SQLite library mengakses file simpanan secara langsung. SQLite termasuk DBMS yang disebut sebagai classic serverless, dimana pada classic serverless DBMS maka database engine dan program aplikasi akan berjalan di proses, thread dan ruang alamat yang sama. Menurut Jay A. Kreibeich(“Using SQLite” , O’Reilly Books,2010) perbedaan antara SQLite yang bersifat serverless dengan RDBMS yang memiliki arsitektur client-server dapat dilihat pada gambar 5.2. sebagai berikut.

(a) DBMS dengan Arsitektur Client - Server (b) SQLite

Gambar 5.2. Perbedaan antara DBMS berasitektur Client Server dengan


SQLite - Serverless

Classic Serverless yang dimiliki oleh SQLite berbeda dengan pengertian Neo-Serverless yang digunakan oleh DBMS seperti Microsoft Azure Cosmo DB dan Amazon S3. Pada Neo-Serverless maka database sesungguhnya dikelola dan diimplementasikan oleh proses-proses server yang berjalan di cloud dan pemrogram aplikasi (Application Programmer) tinggal menggunakan layanan yang telah disediakan tanpa harus melakukan konfigurasi langsung terhadap server. Neo-serverless bukan berarti bahwa DBMS tersebut tidak menggunakan server melainkan server disembunyikan dan tidak perlu dikelola secara langsung oleh pengguna dan pengembang aplikasi basis data.

3. Zero-configuration SQLite tidak perlu di-instalasi secara khusus, atau tidak ada prosedur "setup“. SQLite juga tidak membutuhkan proses server yang harus di start, stop atau dikonfigurasi.

4. Transactional Basis data SQLite mengimplementasikan transaksi yang bersifat serializable transactions yang berarti keluaran dari transaksi-transaksi yang berjalan secara konkuren di suatu basis data SQLite akan sama dengan keluaran dari transaksi-transaksi tersebut jika dijalankan secara berurutan. SQLite juga merupakan basis data yang bersifat transaksional, sehingga seluruh transaksi yang terjadi pada basis data SQLite harus bersifat Atomic, Consistent, Isolated, dan Durable (ACID). Properti dan prinsip-prinsip ACID dicetuskan oleh Andreas Reuter dan Theo Harder (https://en.wikipedia.org/wiki/ACID) dan digunakan untuk memberi jaminan adanya validitas perubahan data jika suatu transaksi terjadi di RDBMS. Prinsip-prinsip ACID tersebut terdiri dari : Atomicity

Jika suatu transaksi tersusun dari sejumlah statement (pernyataan) SQL maka prinsip atomicity menjamin bahwa transaksi tetap dianggap sebagai satu unit kesatuan yang tidak terpisah, sehingga jika terdapat statement yang tidak/belum dieksekusi, maka transaksi sebagai 1 unit kesatuan harus dianggap batal/gagal dan basis data tidak akan mengalami perubahan.

Consistency Prinsip consistency menjamin bahwa setiap transaksi yang menyebabkan perubahan pada basis data harus bersifat konsisten serta tidak melanggar aturan dan batasan-batasan (constraint) yang telah dinyatakan untuk basis data tersebut.

Isolation Jika transaksi dijalankan secara konkuren maka prinsip isolation menjamin bahwa transaksi-transaksi akan memenuhi syarat serializable yaitu keluaran yang diperoleh dari beberapa transaksi yang berjalan secara konkuren harus sama dengan keluaran yang diperoleh jika transaksi-transaksi tersebut berjalan secara berurutan.

Durability Prinsip Durability menjamin bahwa jika suatu transaksi selesai dieksekusi dan berhasil, maka hasil dari transaksi harus bersifat menetap dan perubahan yang terjadi harus tersimpan dalam basis data tersebut.

5. Embedded database SQLite memiliki ciri embedded yaitu SQLite library akan menyatu dan tertanam dalam aplikasi yang akan menggunakan DBMS SQLite.

Kegunaan dari RDBMS SQLite antara lain adalah : 1. Sebagai RDBMS yang digunakan pada perangkat yang berjenis embedded device.

o Large RDBMS Platform (Oracle, SQLServer, MySQL, dsb) merupakan kakas yang sangat

baik digunakan untuk menyimpan, mengorganisasi dan mengelola data yang

bervolume besar, tetapi RDBMS tersebut juga membutuhkan resource yang besar,

sehingga tidak cocok jika digunakan pada sistem yang memiliki resource yang terbatas.


SQLite merupakan alternatif RDBMS yang bersifat complement dari Large RDBMS jika

dilihat dari resource yang diperlukan.

o SQLite tidak dimaksudkan sebagai pengganti (replacement) dari Large RDBMS, tetapi

merupakan RDBMS yang tepat digunakan jika penggunaan Large RDBMS bersifat tidak

“praktis” akibat sumber daya yang tersedia tidak dapat dipenuhi oleh sistem, atau

aplikasi yang membutuhkan basis data tidak memerlukan suatu RDBMS yang memiliki

kapasitas besar dan perlu diadministrasi secara khusus oleh seorang administrator.

Contoh dari perangkat-perangkat yang tidak memiliki sumber daya besar dan tidak perlu

diadministrasi secara khusus adalah perangkat-perangkat embedded device seperti

telefon genggam, set top box, games console dan sebagainya.

2. Sebagai bagian dari File yang digunakan oleh sebuah Aplikasi.

o Sebagian besar aplikasi membutuhkan file-file yang menyimpan preferensi, metadata,

cache dan state data dari aplikasi. Data-data tersebut sebenarnya dapat disimpan dalam

suatu basis data dan SQLite File database dapat digunakan untuk menggantikan file-file

tersebut.

3. Sebagai Application Cache

o SQLite dapat membuat basis data yang bersifat temporer di memori primer sehingga

cocok digunakan untuk aplikasi-aplikasi yang tidak membutuhkan basis data tersimpan

dalam media penyimpanan yang bersifat permanen.

4. Sebagai kakas untuk menyimpan data yang memiliki struktur bersifat kompleks sehingga

mudah untuk di distribusikan.

5. Dapat digunakan sebagai file archive dan data container seperti pada ZIP archive atau

Tarballs.

6. Sebagai Kakas ajar (Teaching Tools) khususnya mengenai penggunaan perintah dan query

SQL

Walaupun SQLite banyak memiliki kegunaan, bukan berarti SQLite tidak memiliki kelemahan.

Kelemahan-kelemahan SQLite antara lain adalah :

1. Tidak tepat digunakan pada kondisi High Transaction Rate, karena SQLite tidak dapat

dibandingkan dengan Large RDBMS yang memang dirancang untuk menangani proses

transaksi yang jumlahnya tinggi.

2. Tidak tepat digunakan untuk data yang memiliki volume sangat besar.

3. Tidak memiliki mekanisme autorisasi dan pengaksesan tersendiri, melainkan bergantung

sepenuhnya pada filesystem permission yang dikelola oleh operating system.

4. SQLite dirancang tanpa menggunakan komponen jaringan (network), sehingga lebih baik

digunakan sebagai basis data yang bersifat local resource.

5. SQLite tidak dirancang untuk memiliki mekanisme yang bersifat safe dalam melakukan

replication, dimana simple replication dapat dilakukan dengan menyalin file basis data,

tetapi hal ini harus dilakukan dengan terlebih dahulu memastikan tidak ada proses yang

memodifikasi data pada saat proses replikasi dilakukan.


5.3. Arsitektur SQLite Library

Dalam melakukan pengelolaan file basis data, perangkat lunak DBMS SQLite bekerja dengan cara mengkompilasi perintah-perintah SQL (SQL Statement) menjadi bytecode, lalu mengeksekusi bytecode dengan virtual machine. Komponen-komponen dari perangkat lunak DBMS SQLite Library dan hubungan (interoperate) antar komponen komponen yang ada pada SQLite tersebut, dapat dilihat pada gambar 5.2.

Gambar 5.2. Komponen-Komponen SQLite Library

Interface Sebagian besar kode sumber antar muka berbahasa pemrograman C pada SQLite Library dapat

ditemukan pada kode sumber main.c , legacy.c, dan vdbeapi.c dari kode sumber SQLite Library, sedangkan antar muka TCL diimplementasikan dalam tclsqlite.c.

Tokenizer Jika terdapat SQL Statement yang akan dievaluasi dan dieksekusi maka SQL Statement dalam

bentuk string akan dipecah menjadi token-token. Kode sumber pada SQLite Library yang digunakan untuk melakukan tokenisasi adalah tokenize.c.

Parser Parser akan melakukan parsing berdasarkan token-token yang dihasilkan oleh tokenizer dan

hasil parsing adalah terbentuknya parse tree (pohon urai) dari SQL Statement yang diberikan. Parser yang digunakan oleh SQLite adalah Lemon parser generator dan berkas grammar yang digunakan untuk mengendalikan Lemon Parser dan mendefinisikan SQL Language yang dipahami oleh SQLite dapat ditemukan pada berkas parser.y.


Code Generator Komponen code generator akan membangkitkan bytecode dari parse tree yang dihasilkan oleh

lemon parser. Berkas kode sumber program yang digunakan oleh sqlite untuk membangkitkan bytecode dari sql statement yang diberikan, antara lain attach.c, auth.c, build.c, delete.c, expr.c, insert.c, pragma.c, select.c, trigger.c, update.c, vacuum.c, where.c, wherecode.c, and whereexpr.c.

Bytecode Engine atau Virtual Machine Komponen ini akan digunakan untuk mengeksekusi bytecode dari SQL Statement yang

diberikan. Kode sumber program yang digunakan untuk membuat VM di SQLite antara lain adalah berkas vdbe.c., vdbe.h, vdbeaux.c, vdbeapi.c dan vdbemem.c.

B-Tree File basis data SQLite akan diorganisasikan pada media penyimpanan dengan menggunakan

struktur data B-tree. Implementasi B-Tree yang digunakan oleh SQLite dapat dilihat pada berkas kode sumber program btree.c dan btree.h.

Pager (Page cache) SQLite dalam mengakses data file akan menggunakan model pembacaan, penulisan dan caching

dengan fixed-size pages. Ukuran default page adalah 4096 byte, tetapi ukuran page juga dapat memiliki besar antara 512 - 65536 byte. Implementasi page cache ini dapat dilihat pada berkas kode sumber pager.c file. , wal.c, pcache.c ,pcache1.c dan pager.h.

OS Interface Agar SQLite dapat dijalankan di berbagai sistem operasi, maka SQLite menggunakan obyek

abstrak yang disebut sebagai VFS. Saat ini SQLite mampu menggunakan VFS untuk unix (kode sumber program adalah os_unix.c) agar SQLite dapat berjalan pada sistem operasi yang menyerupai UNIX dan VFS berbasis Windows (kode sumber program adalah os_win.c)

Utilities Komponen ini terdiri dari berkas util.c yang berisi fungsi atau rutin-rutin yang digunakan untuk

mengalokasikan memori, melakukan string comparison dan melakukan konversi text ke bilangan. Selain berkas util.c terdapat juga kode sumber hash.c., printf.c, random.c pada komponen utiliti ini.

Test Code Komponen Test Code akan berisi subrutin yang digunakan untuk melakukan pengujian

terhadapat perangkat lunak SQLite secara keseluruhan, berkas kode sumber untuk melakukan pengujian ini dapat ditemukan di folder "src/" dari kode sumber SQLite Library.

5.4. Tipe data pada SQLite Versi 3

SQLite khususnya SQLite Versi 3 menggunakan sistem dengan pemberian tipe data yang lebih bersifat umum dan dinamis. Pada SQLite, tipe data suatu nilai di sebuah atribut (kolom) akan diasosiasikan dengan nilai itu sendiri. Untuk mengimplementasikan penggunaan tipe yang lebih dinamis tersebut, maka SQLite menerapkan penggunaan tipe kelas penyimpanan (storage class). Untuk setiap nilai yang ada pada basis data SQLite, maka nilai tersebut harus bertipe kelas penyimpanan salah satu dari lima kelas penyimpanan yang tersedia pada SQLite, yaitu:

1. NULL Suatu nilai pada basis data SQLite memiliki tipe kelas penyimpanan (storage class) NULL jika nilai tersebut adalah nilai NULL.

2. INTEGER Suatu nilai pada basis data SQLite memiliki tipe kelas penyimpanan INTEGER jika nilai tersebut adalah bilangan bulat bertanda. Untuk menyimpan nilai bertipe kelas penyimpanan INTEGER, maka besar memori yang dibutuhkan untuk menyimpan nilai


tersebut akan disesuaikan dengan jumlah memori yang dibutuhkan oleh bilangan integer itu sendiri (dapat memiliki panjang 1, 2, 3, 4,,6 atau 8 byte)

3. REAL Suatu nilai memiliki tipe kelas penyimpanan REAL jika nilai tersebut adalah nilai floating point. Jumlah memori yang dibutuhkan untuk menyimpan nilai bertipe kelas penyimpanan (storage class) REAL adalah 8 byte.

4. TEXT Suatu nilai pada basis data SQLite memiliki tipe kelas penyimpanan TEXT, jika nilai tersebut adalah suatu text string. Nilai dengan kelas penyimpanan TEXT dapat disimpan dalam bentuk pengkodean UTF-8, UTF-16BE dan UTF-16LE

5. BLOB Jika suatu nilai pada basis data SQLite dinyatakan sebagai BLOB, maka nilai tersebut akan disimpan seperti yang dinyatakan oleh nilai atau data tersebut.

Untuk mendapatkan tipe kelas penyimpanan (Storage Class) pada basis data SQLite dapat digunakan fungsi typeof().

Contoh Soal 5.1. Jika diberikan schema dari tabel account sebagai berikut :

a. Tentukanlah Pernyataan SQL DDL Create Table yang dapat digunakan untuk membuat tabel diatas !

b. Tentukan Pernyataan SQL DML INSERT INTO untuk menyisipkan 1 record atau tuple baru sebagai berikut pada tabel account tersebut :

account_number : A-151 branch_name : Perryridge balance : 1000

c. Tentukan Query SQL yang dapat digunakan untuk menampilkan tipe kelas penyimpanan dari nilai 1000 pada atribut balance di tabel account tersebut dan tampilkan hasil dari query yang telah dilakukan !

Jawab : a. Pernyataan SQL DDL CREATE TABLE yang dapat digunakan untuk membuat tabel account

dengan schema diatas adalah : CREATE TABLE account (account_number CHAR(10), branch_name CHAR(15), balance NUMERIC(12,2), PRIMARY KEY(account_number) );

b. Pernyataan INSERT INTO untuk menyisipkan record atau tuple seperti soal b adalah : INSERT INTO account (account_number,branch_name,balance) VALUES ('L-151', 'Perryridge',1000);


Tipe Data Boolean

SQLite tidak menyediakan kelas penyimpanan khusus untuk nilai boolean. Nilai boolean akan disimpan sebagai bilangan 0 untuk false dan 1 untuk nilai true.

Tipe Data hari dan waktu (Date/time)

SQLite tidak menyediakan tipe kelas penyimpanan yang khusus untuk menyimpan nilai hari atau waktu. Fungsi date/time yang disediakan oleh SQLite mampu menampilkan dan menyimpan nilai hari dan waktu dalam bentuk nilai bertipe kelas penyimpanan TEXT, INTEGER atau REAL, dimana:

a. Untuk nilai waktu yang disimpan dalam bentuk kelas penyimpanan TEXT, maka nilai waktu tersebut akan memiliki format yang sesuai dengan standar ISO8601 strings ("YYYY-MM-DD HH:MM:SS.SSS").

b. Untuk nilai waktu yang disimpan dalam bentuk kelas penyimpanan INTEGER, maka nilai waktu tersebut adalah nilai waktu yang berdasarkan nilai UNIX Time (Jumlah detik terhitung mulai dari 1970-01-01 00:00:00 UTC.)

c. Untuk nilai waktu yang disimpan dalam bentuk tipe REAL, maka nilai waktu tersebut adalah nilai waktu yang didasarkan pada Julian Day Number (Jumlah hari dihitung dari siang hari tanggal 24 November 4714 B.C. sesuai yang dimaksudkan oleh sistem penanggalan proleptic Gregorian calendar)

5.5. Tipe Afinitas (Typed Affinity)

Untuk menjaga kompatibilitas SQLite terhadap DBMS lain yang menggunakan model tipe data

statis dan lebih strict (tipe data nilai akan diasosiasikan dengan tipe data yang dinyatakan pada

atribut), maka pada SQLite diimplementasikan tipe kedekatan atau tipe afinitas (type affinity) pada

atribut (kolom).

Terdapat 5 tipe afinitas yang dapat digunakan oleh setiap atribut (kolom) pada SQLite. Kelima

tipe afinitas yang dapat digunakan oleh setiap atribut yang ada pada basis data SQLite adalah:

Lanjutan Contoh Soal 5.1. Jawab : c. Pernyataan Query SQL untuk menampilkan tipe kelas penyimpanan dari nilai 1000 di kolom

balance untuk tuple yang baru saja disisipkan adalah : SELECT balance, typeof(balance) FROM account WHERE account_number = 'L-151 '

Hasil dari query SQL diatas adalah :

balance typeof(balance)

1000 integer


1. TEXT

Suatu atribut (kolom) yang memiliki tipe afinitas TEXT akan menyimpan data-data yang

berada pada kolom tersebut dengan menggunakan tipe kelas penyimpanan NULL, TEXT atau

BLOB. Jika nilai data yang dimasukkan adalah nilai numeris atau bilangan, maka bilangan

tersebut akan dirubah ke tipe kelas penyimpanan TEXT sebelum disimpan dalam basis data.

2. NUMERIC

Suatu atribut (kolom) yang memiliki tipe afinitas NUMERIC dapat memiliki dan menyimpan

data-data atau nilai dari kelima kelas penyimpanan (NULL,INTEGER, REAL, TEXT dan BLOB).

Jika terdapat nilai yang memiliki tipe kelas penyimpanan TEXT dimasukkan ke dalam atribut

bertipe afinitas NUMERIC, maka SQLite akan berusaha mengubah nilai text tersebut ke tipe

kelas penyimpanan INTEGER dan REAL, jika text bukan merupakan text bilangan atau text

bilangan tetapi dengan dengan format tidak standar maka nilai atau data tersebut akan

disimpan dengan tipe kelas penyimpanan TEXT.

Jika terdapat nilai yang memiliki tipe kelas penyimpanan NULL dan BLOB dimasukkan ke

dalam atribut bertipe afinitas NUMERIC, maka SQLite tidak akan mengubah tipe kelas

penyimpanan nilai atau data tersebut dan data tersebut akan tetap disimpan dalam bentuk

tipe kelas penyimpanan NULL dan BLOB.

3. INTEGER

Suatu atribut (kolom) yang memiliki tipe afinitas INTEGER akan menerapkan model

penyimpanan nilai yang sama dengan atribut bertipe afinitas NUMERIC, perbedaan antara

tipe afinitas NUMERIC dan tipe afinitas INTEGER hanya terlihat pada saat menggunakan

ekspresi CAST yaitu ekspresi yang digunakan untuk mengubah tipe kelas penyimpanan.

4. REAL

Suatu atribut (kolom) yang memiliki tipe afinitas REAL akan menerapkan model

penyimpanan nilai yang sama dengan atribut bertipe afinitas NUMERIC, kecuali untuk setiap

nilai bilangan bulat akan dikonversikan menjadi bentuk bilangan real (floating point).

5. BLOB

Suatu atribut (kolom) yang memiliki tipe afinitas BLOB tidak akan merubah tipe kelas

penyimpanan dari data yang dimasukkan pada atribut(kolom) tersebut.

Menentukan Tipe Afinitas

Tipe afinitas dari suatu atribut (kolom) pada basis data SQLite, akan ditentukan saat tipe atribut

tersebut dideklarasikan. Aturan-aturan dibawah ini adalah aturan-aturan yang digunakan oleh SQLite

untuk menentukan tipe afinitas dari suatu atribut :

1. Jika tipe atribut yang dideklarasikan berisi string "INT" , maka atribut tersebut akan memiliki

tipe afinitas INTEGER.

2. Jika tipe atribut yang dideklarasikan berisi string "CHAR", "CLOB", atau "TEXT", maka atribut

tersebut akan memiliki tipe afinitas TEXT.

3. Jika tipe atribut yang dideklarasikan berisi string “BLOB" atau jika atribut tersebut tidak

ditentukan memiliki tipe tertentu, maka atribut tersebut akan memiliki tipe afinitas BLOB

4. Jika tipe atribut yang dideklarasikan berisi string "REAL", "FLOA", atau "DOUB", maka atribut

tersebut akan memiliki tipe afinitas REAL

5. Jika tipe atribut yang dideklarasikan tidak memenuhi salah satu dari 4 aturan diatas, maka

tipe afinitas dari atribut tersebut adalah NUMERIC.


Contoh Soal 5.3. Jika diberikan schema diagram dari tabel temporer sebagai berikut :

Dan diketahui isi dari tabel temporer tersebut adalah seperti tabel berikut :

id atribut1 atribut2

1 100 100.0 2 200 test 3 F9 1.4

Tentukanlah jenis tipe kelas penyimpanan dari data-data di kolom atribut1 dan kolom atribut2 !

Contoh Soal 5.2. Jika diberikan schema diagram dari tabel customer sebagai berikut :

Tentukanlah tipe afinitas dan aturan yang akan digunakan oleh SQLite untuk setiap atribut yang dinyatakan pada schema diagram tabel account diatas ! Jawab : Tabel dibawah ini menunjukkan tipe afinitas dari masing-masing atribut yang dinyatakan pada schema diagram tabel account diatas.

Nama Atribut Tipe Data yang dideklarasikan

Tipe Afinitas yang akan digunakan

oleh SQLite

Nomor Aturan yang digunakan untuk menentukan Tipe

Afinitas

account_number char(10) TEXT Aturan ke - 2 branch_name char(15) TEXT Aturan ke - 2

balance numeric (12,2) NUMERIC Aturan ke - 5

Dari tabel diatas dapat dilihat bahwa aturan-aturan yang digunakan adalah aturan :

Aturan ke -2 Jika tipe atribut yang dideklarasikan berisi string "CHAR", "CLOB", atau "TEXT", maka atribut tersebut akan memiliki tipe afinitas TEXT.

Aturan ke -5 Jika tipe atribut yang dideklarasikan tidak memenuhi aturan 1 – 4, maka, maka atribut tersebut akan memiliki tipe afinitas NUMERIC.


Lanjutan Contoh Soal 5.3. Jawab :

Tipe afinitas dari kolom atribut1 sesuai dengan aturan ke 2 adalah TEXT karena didefinisikan dengan tipe char(10), oleh karena itu nilai yang disimpan pada kolom ini dapat memiliki tipe kelas penyimpanan TEXT, NULL dan BLOB dan untuk data-data yang ada pada kolom atribut1 akan diperoleh tipe kelas penyimpanan sebagai berikut :

atribut1 Tipe Kelas Penyimpanan

100 TEXT 200 TEXT F9 TEXT

Tipe afinitas dari kolom atribut2 sesuai dengan aturan ke 4 adalah REAL karena kolom atribut2 didefinisikan dengan tipe double, oleh karena itu nilai yang disimpan pada kolom ini dapat memiliki tipe kelas penyimpanan NULL, INTEGER, REAL, TEXT dan BLOB dan untuk data-data yang ada pada kolom atribut2 maka akan diperoleh tipe kelas penyimpanan sebagai berikut :

Atribut2 Tipe Kelas Penyimpanan

100.0 REAL test TEXT 1.4 REAL


5.6. SQL Lanjutan Pada SQLite

Pada bagian ini akan dibahas beberapa pernyataan SQL Lanjutan yang dapat digunakan untuk melengkapi pernyataan-pernyataan SQL yang telah dibahas pada bab 4 dari diktat ini. Pernyataan-pernyataan SQL lanjutan yang akan dibahas pada bab 5 ini, antara lain adalah pernyataan dan klausa SQL yang berhubungan dengan Integrity Constraint dan pernyataan SQL untuk mendefinisikan Trigger.

5.6.1. Integrity Constraint

Batasan integritas (Integrity Constraint) adalah batasan-batasan yang dibuat agar dapat memastikan perubahan yang akan dilakukan oleh pengguna tidak menyebabkan pelanggaran terhadap integritas data di dalam basis data. Batasan Integritas juga digunakan untuk menjaga konsistensi data pada basis data yang telah dibuat.

Pada bab 4 sudah dibahas pernyataan CREATE TABLE yang menyertakan batasan integritas berupa penciptaan kunci primer (primary key) pada suatu tabel. Pada bagian sub bab ini akan dibahas beberapa batasan integritas selain dari batasan kunci primer yang sudah dipaparkan pada bab 4. Batasan-batasan Integritas yang akan dibahas pada bagian ini adalah :

Batasan NOT NULL

Batasan UNIQUE

Klausa CHECK

Integritas Referensial

Batasan NOT NULL

Jika suatu atribut tidak diizinkan untuk memiliki nilai NULL, maka batasan NOT NULL dapat ditambahkan pada pernyataan DDL yang digunakan untuk menciptakan tabel yang berisi atribut dengan batasan NOT NULL tersebut. Contoh tabel yang memiliki atribut-atribut dengan batasan NOT NULL dapat dilihat pada schema diagram tabel account sebagai berikut.

Pernyataan DDL CREATE TABLE yang dapat digunakan untuk membuat tabel diatas pada SQLite adalah :

CREATE TABLE account ( account_number CHAR(10), branch_name CHAR(15) NOT NULL, balance NUMERIC (12,2) NOT NULL, PRIMARY KEY(account_number));

Batasan UNIQUE

Jika pada suatu tabel terdapat batasan yang mengharuskan bahwa setiap record (tuple) tidak dapat memiliki kombinasi nilai yang sama pada 1 atau lebih pasangan atribut yang dinyatakan sebagai atribut dan pasangan atribut yang bersifat unik, maka dapat digunakan batasan UNIQUE.


Contoh:

Jika diberikan schema diagram dari tabel pelanggan sebagai berikut :

Dan diberikan batasan (constraint) UNIQUE dan batasan NOT NULL pada atribut ktp_pelanggan, batasan NOT NULL pada atribut kode_pos dan nama_pelanggan serta atribut kd_pelanggan adalah kunci primer dari tabel tersebut, maka pernyataan DDL CREATE TABLE yang dapat digunakan untuk membuat tabel pelanggan dengan schema diatas adalah :

CREATE TABLE pelanggan ( kd_pelanggan TEXT, nama_pelanggan TEXT NOT NULL, ktp_pelanggan TEXT NOT NULL, kode_pos TEXT NOT NULL, PRIMARY KEY(kd_pelanggan),

UNIQUE(ktp_pelanggan));

Klausa CHECK

Klausa CHECK dapat diaplikasikan pada saat penciptaan tabel (pendeklarasian relasi), dimana klausa CHECK digunakan untuk menambahkan kriteria nilai pada suatu atribut yang harus dipenuhi oleh setiap record (tuple) pada tabel tersebut.

Contoh : Jika diberikan schema diagram dari suatu tabel account sebagai berikut :

Dan diberikan batasan integritas berupa kriteria yang harus dipenuhi oleh setiap record untuk nilai pada atribut balance yaitu nilai balance ≥ 500, maka pernyataan SQL DDL CREATE TABLE yang dapat digunakan untuk membuat tabel account beserta seluruh batasan integritas yang ada pada tabel tersebut adalah :

CREATE TABLE account ( account_number CHAR(10), branch_name CHAR(15) NOT NULL, balance NUMERIC (12,2) NOT NULL, PRIMARY KEY(account_number),

CHECK (balance >=500) );


Integritas Referensial

Seringkali dalam suatu basis data, nilai suatu atribut yang terdapat pada sebuah tabel memiliki keterkaitan dan berhubungan dengan nilai atribut dari tabel yang lain. Hubungan antar nilai dari suatu atribut yang berada pada tabel berbeda menunjukkan terbentuknya hubungan yang bersifat referensial dan data-data atau nilai dari atribut ini harus terjaga konsistensi-nya.

Untuk mempertahankan konsistensi dan integritas referensial, maka digunakan kunci tamu (foreign key). Umumnya nilai atribut-atribut yang menjadi kunci primer di suatu tabel, akan menjadi kunci tamu di tabel lain jika atribut-atribut tersebut ada di tabel lain. Selain mempertahankan konsistensi, keberadaan kunci tamu juga akan menunjukkan keterkaitan (relationship) antar tabel yang ada di dalam suatu basis data.

Contoh :

Jika diberikan schema diagram sebagai berikut :

Dari diagram dapat dilihat bahwa atribut branch_name yang menjadi kunci primer di tabel branch akan menjadi kunci tamu di tabel account, maka pernyataan SQL CREATE TABLE yang dapat digunakan untuk membuat tabel account beserta seluruh batasan integritas yang dinyatakan untuk tabel tersebut adalah :

CREATE TABLE account ( account_number CHAR(10), branch_name CHAR(15) NOT NULL, balance NUMERIC (12,2) NOT NULL, PRIMARY KEY(account_number), FOREIGN KEY (branch_name) REFERENCES branch(branch_name));

Catatan : Untuk dapat menggunakan batasan foreign key di SQLite, maka PRAGMA FOREIGN_KEYS pada SQLite Library yang digunakan harus dikondisikan pada kondisi ON.

5.6.2. Trigger

SQL Trigger pada suatu basis data adalah suatu fungsi atau prosedur yang dibuat atau diciptakan agar dapat berjalan secara otomatis jika terjadi kejadian-kejadian (event) seperti proses penghapusan (DELETE), penyisipan (INSERT) dan pembaruan (UPDATE) data dari tabel pada basis data tersebut.

Aturan sintaksis sederhana dari statement SQL yang dapat digunakan untuk menciptakan Trigger pada suatu basis data SQLite adalah sebagai berikut :


Dimana :

Jenis_event : Jenis-jenis kejadian yang digunakan sebagai pemicu trigger. Pilihan jenis event yang disediakan pada SQLite adalah :

INSERT

DELETE

UPDATE OF nama_kolom Fungsi atau prosedur Trigger pada basis data SQLite, memiliki batasan-batasan sebagai berikut :

Jenis-jenis kejadian atau event yang dapat digunakan sebagai pemicu tereksekusinya suatu fungsi atau prosedur TRIGGER adalah kejadian (event) DELETE, INSERT atau UPDATE.

Pernyataan-pernyataan SQL yang berada dalam Fungsi TRIGGER dapat menggunakan keyword NEW.nama_atribut dan keyword OLD.nama_atribut sebagai referensi untuk menunjuk nilai baru dan nilai lama dari suatu nilai atribut.

Keyword BEFORE dan AFTER di pernyataan CREATE TRIGGER digunakan untuk menentukan kapan fungsi TRIGGER dieksekusi.

TRIGGER akan terhapus jika tabel yang berhubungan dengan TRIGGER juga dihapus.

Contoh Soal 5.4. Jika diberikan schema diagram dari tabel customer, tabel depositor dan tabel borrower sebagai berikut :

Tentukanlah statement SQL CREATE TRIGGER yang dapat digunakan untuk menciptakan fungsi trigger yang diberi nama updateCustomerName dimana :

Fungsi trigger akan dieksekusi setelah (AFTER) terjadi pembaruan data (UPDATE) berupa pengubahan nilai atribut customer_name (nama nasabah) di tabel customer

Fungsi trigger berisi pernyataan atau statement yang akan mengubah customer_name (nama nasabah) di tabel borrower dan tabel depositor.

Perubahan customer_name di tabel borrower dan tabel depositor akan mengikuti perubahan nilai customer_name di tabel customer.

CREATE TRIGGER nama_trigger [BEFORE|AFTER] jenis_event ON nama_tabel

BEGIN ........ //Pernyataan atau statement yang akan dieksekusi END;


Pada SQLite, jika suatu fungsi SQL Trigger akan dihapus dari basis data tanpa terlebih dahulu menghapus tabel dimana fungsi Trigger tersebut dinyatakan, maka pernyataan yang dapat digunakan adalah pernyataan DROP TRIGGER. Aturan sintaksis penggunaan pernyataan DROP TRIGGER adalah :

5.7. Command Line Shell Untuk SQLite

Salah satu kakas yang disediakan oleh SQLite project adalah kakas berupa command-line shell program yang disebut sebagai sqlite3*) (atau sqlite3.exe pada sistem yang menggunakan sistem operasi windows). Program sqlite3 ini memungkinkan pengguna untuk secara langsung memasukkan perintah-perintah SQL terhadap suatu basis data SQLite dan berkas ZIP Archive.

Salah satu cara yang dapat digunakan untuk menjalankan program sqlite3 adalah dengan memanggil program tersebut melalui command prompt. Kakas sqlite3 dapat dijalankan dengan menyertakan argumen berupa namafile basis data (atau ZIP archive). Jika tidak ditemukan file atau berkas dengan nama yang disertakan pada argumen yang diberikan, maka berkas atau file baru akan dibuat dengan menggunakan nama yang dinyatakan pada argumen pemanggilan sqlite3.

Jika progam sqlite3 dipanggil tanpa menyertakan argumen, maka program sqlite3 secara otomatis akan membuat basis data yang bersifat temporer di memori perangkat. Hal yang sama juga terjadi, jika program sqlite3 dijalankan dengan cara melakukan double click icon program tersebut melalui antar muka yang bersifat GUI. Gambar 5.3 dibawah ini menunjukkan hasil window dari program command line shell sqlite3 yang dijalankan melalui command prompt dan yang dijalankan dengan melakukan double click pada icon program sqlite3.

Catatan *): sqlite3 versi terbaru dapat diunduh dari https://www.sqlite.org

DROP TRIGGER nama_trigger

Lanjutan Contoh Soal 5.4. Jawab : Pernyataan SQL CREATE TRIGGER yang dapat digunakan untuk soal diatas adalah : CREATE TRIGGER updateCustomerName AFTER UPDATE OF customer_name ON customer BEGIN UPDATE borrower SET customer_name=new.customer_name WHERE customer_name = old.customer_name; UPDATE depositor SET customer_name = new.customer_name WHERE customer_name = old.customer_name; END;


(a) Command Line shell sqlite3 yang dipanggil melalui command Prompt

(b) Command Line shell sqlite3 yang dipanggil melalui double click

Gambar 5.3. Command Line Shell sqlite3 yang dipanggil tanpa menyertakan argumen nama file

5.7.1. Perintah khusus (Special commands) atau Dot-Commands untuk sqlite3

Umumnya sqlite3 digunakan untuk menerima dan menjalankan statement atau pernyataan dalam bahasa SQL. Selain dari pernyataan dalam bahasa SQL, sqlite3 juga menerima perintah khusus (special command) yang disebut sebagai Dot-commands. Perintah khusus ini dinamakan Dot-command karena setiap perintah harus diawali dengan karakter titik (“dot”).

Untuk menampilkan daftar dari perintah dot-commands yang ada pada sqlite3 dapat digunakan perintah .help pada sqlite3 command line. Gambar 5.4. berikut menunjukkan daftar dari dot-commands pada sqlite3 yang menggunakan SQLite Library versi 3.31.1.

D:\prakteksqlite>sqlite3 SQLite version 3.31.1 2020-01-27 19:55:54 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> .help .archive ... Manage SQL archives .auth ON|OFF Show authorizer callbacks .backup ?DB? FILE Backup DB (default "main") to FILE .bail on|off Stop after hitting an error. Default OFF .binary on|off Turn binary output on or off. Default OFF .cd DIRECTORY Change the working directory to DIRECTORY .changes on|off Show number of rows changed by SQL .check GLOB Fail if output since .testcase does not match .clone NEWDB Clone data into NEWDB from the existing database .databases List names and files of attached databases .dbconfig ?op? ?val? List or change sqlite3_db_config() options .dbinfo ?DB? Show status information about the database .dump ?TABLE? ... Render all database content as SQL .echo on|off Turn command echo on or off .eqp on|off|full|... Enable or disable automatic EXPLAIN QUERY PLAN .excel Display the output of next command in spreadsheet .exit ?CODE? Exit this program with return-code CODE .expert EXPERIMENTAL. Suggest indexes for queries


.explain ?on|off|auto? Change the EXPLAIN formatting mode. Default: auto

.filectrl CMD ... Run various sqlite3_file_control() operations

.fullschema ?--indent? Show schema and the content of sqlite_stat tables

.headers on|off Turn display of headers on or off

.help ?-all? ?PATTERN? Show help text for PATTERN

.import FILE TABLE Import data from FILE into TABLE

.imposter INDEX TABLE Create imposter table TABLE on index INDEX

.indexes ?TABLE? Show names of indexes

.limit ?LIMIT? ?VAL? Display or change the value of an SQLITE_LIMIT

.lint OPTIONS Report potential schema issues.

.load FILE ?ENTRY? Load an extension library

.log FILE|off Turn logging on or off. FILE can be stderr/stdout

.mode MODE ?TABLE? Set output mode

.nullvalue STRING Use STRING in place of NULL values

.once (-e|-x|FILE) Output for the next SQL command only to FILE

.open ?OPTIONS? ?FILE? Close existing database and reopen FILE

.output ?FILE? Send output to FILE or stdout if FILE is omitted

.parameter CMD ... Manage SQL parameter bindings

.print STRING... Print literal STRING

.progress N Invoke progress handler after every N opcodes

.prompt MAIN CONTINUE Replace the standard prompts

.quit Exit this program

.read FILE Read input from FILE

.recover Recover as much data as possible from corrupt db.

.restore ?DB? FILE Restore content of DB (default "main") from FILE

.save FILE Write in-memory database into FILE

.scanstats on|off Turn sqlite3_stmt_scanstatus() metrics on or off

.schema ?PATTERN? Show the CREATE statements matching PATTERN

.selftest ?OPTIONS? Run tests defined in the SELFTEST table

.separator COL ?ROW? Change the column and row separators

.sha3sum ... Compute a SHA3 hash of database content

.shell CMD ARGS... Run CMD ARGS... in a system shell

.show Show the current values for various settings

.stats ?on|off? Show stats or turn stats on or off

.system CMD ARGS... Run CMD ARGS... in a system shell

.tables ?TABLE? List names of tables matching LIKE pattern TABLE

.testcase NAME Begin redirecting output to 'testcase-out.txt'

.testctrl CMD ... Run various sqlite3_test_control() operations

.timeout MS Try opening locked tables for MS milliseconds

.timer on|off Turn SQL timer on or off

.trace ?OPTIONS? Output each SQL statement as it is run

.vfsinfo ?AUX? Information about the top-level VFS

.vfslist List all available VFSes

.vfsname ?AUX? Print the name of the VFS stack

.width NUM1 NUM2 ... Set column widths for "column" mode sqlite>

Gambar 5.4. Daftar Dot-Commands pada sqlite3 command line shell


Aturan-aturan yang diterapkan pada penggunaan dot-commands di sqlite3 adalah : 1. Setiap perintah dot-command harus diawali dengan simbol titik (.). 2. Setiap 1 perintah dot-command harus berada dalam 1 baris yang sama. 3. Perintah dot-command tidak dapat diletakkan di tengah-tengah pernyataan SQL. 4. Dot-command tidak dapat diberi komentar (comments).

Dibawah ini akan dipaparkan sebagian perintah dot-command yang sering digunakan dan bagaimana menggunakan perintah dot-command tersebut pada program sqlite3.

.open Dot-command open digunakan untuk membuka file sekaligus menutup file yang sedang dibuka

oleh sqlite3. Aturan sintaksis yang digunakan pada perintah open adalah :

Contoh penggunaan perintah .open untuk membuka file basis data SQLite yang memiliki nama bankSilberschatz.db dapat dilihat pada gambar 5.5. dibawah ini.

sqlite> .open bankSilberschatz.db sqlite>

Gambar 5.5. Contoh Penggunaan .open

.show

Dot command show digunakan untuk menampilkan informasi, mengenai beberapa pengaturan dasar dari sqlite3 yang sedang aktif digunakan. Gambar 5.6 dibawah ini menunjukkan penggunaan perintah .show dan hasil yang diperoleh.

sqlite> .show echo: off eqp: off explain: auto headers: off mode: list nullvalue: "" output: stdout colseparator: "|" rowseparator: "\n" stats: off width: filename: :memory:

sqlite>

Gambar 5.6. Contoh Penggunaan .show

.open OPTIONS FILE dimana :

Option : Pilihan yang dapat digunakan antara lain adalah :

--append

--new

--readonly

--nofollow

--zip FILE : nama file yang akan dibuka.


.header Dot command header digunakan untuk menampilkan atau tidak menampilkan nama atribut

(nama kolom) dari tabel hasil query yang dilakukan pada basis data SQLite. Aturan sintaksis yang digunakan pada perintah .header adalah :

.mode

Dot command mode digunakan untuk mengatur tampilan dan keluaran dari hasil eksekusi query SQL yang dilakukan oleh sqlite3. Aturan sintaksis yang digunakan pada perintah .mode adalah

Gambar 5.7 dibawah ini menunjukkan penggunaan perintah .header dan .mode untuk mengatur hasil keluaran yang diperoleh dari sqlite3.

sqlite> .open bankSilberschatz.db -- membuka file basis data sqlite sqlite> SELECT * FROM branch; -- Hasil tampilan query dapat dilihat pada bagian (b) sqlite> .header on sqlite> .mode column sqlite> SELECT * FROM branch; -- Hasil tampilan query setelah merubah header dan mode

dapat dilihat pada bagian (c) sqlite>

(a) Pernyataan/statement yang diberikan pada sqlite3

.mode MODE [TABLE] dimana :

MODE : Pilihan jenis tampilan keluaran yang dapat digunakan yaitu :

ascii

column

csv

html

insert

line

list

quote

tabs

tcl

.header OPTION dimana :

OPTION : Pilihan yang harus dinyatakan, yaitu :

on

off


Brighton|Brooklyn|7100000 Downtown|Brooklyn|9000000 Mianus|Horseneck|400000 North Town|Rye|3700000 Perryridge|Horseneck|1700000 Pownal|Bennington|300000 Redwood|Palo Alto|2100000 Round Hill|Horseneck|8000000

branch_name branch_city assets ----------- ----------- ---------- Brighton Brooklyn 7100000 Downtown Brooklyn 9000000 Mianus Horseneck 400000 North Town Rye 3700000 Perryridge Horseneck 1700000 Pownal Bennington 300000 Redwood Palo Alto 2100000 Round Hill Horseneck 8000000

(b) Hasil tampilan keluaran dari pengeksekusian query sebelum

mengatur header dan mode

(c) Hasil tampilan keluaran dari pengeksekusian query sesudah merubah

header dan mode

Gambar 5.7. Contoh Penggunaan .mode dan .header

.databases

Dot command databases digunakan untuk menampilkan seluruh file basis data sqlite yang sedang aktif dikelola oleh program sqlite3. Gambar 5.8. menampilkan contoh penggunaan dari .databases.

.schema Dot command schema digunakan untuk menampilkan schema dari relasi-relasi yang ada pada

basis data sqlite yang sedang aktif digunakan di sqlite3. Gambar 5.8 menampilkan contoh penggunaan dan hasil yang diperoleh dari perintah .schema terhadap relasi atau tabel customer di contoh basis data sqlite yaitu bankSilberschatz.db.

.tables Dot command tables digunakan untuk menampilkan daftar atau list dari tabel atau relasi yang

ada pada basis data sqlite yang sedang aktif digunakan di sqlite.

sqlite> .open bankSilberschatz.db sqlite> .databases

main: D:\prakteksqlite\bankSilberschatz.db -- Contoh Hasil perintah .databases sqlite> .schema customer

CREATE TABLE customer ( -- Contoh Hasil perintah .schema customer_name char(20), customer_street char(30), customer_city char(30), PRIMARY KEY(customer_name) );

sqlite>sqlite>

Gambar 5.8. Contoh Penggunaan .databases dan .schema


.dump Dot command dump umumnya digunakan untuk menampilkan struktur tabel beserta isi dari

tabel-tabel basis data SQLite yang sedang aktif digunakan oleh sqlite3 dalam bentuk transaksi SQL. Gambar 5.9 menunjukkan contoh hasil dari perintah .dump terhadap tabel customer yang terdapat pada contoh basisdata SQLite bankSilberschatz.db.

sqlite> .open bankSilberschatz.db sqlite> .databases

main: D:\prakteksqlite\bankSilberschatz.db sqlite> .dump customer PRAGMA foreign_keys=OFF; BEGIN TRANSACTION; CREATE TABLE customer ( customer_name char(20), customer_street char(30), customer_city char(30), PRIMARY KEY(customer_name) ); INSERT INTO customer VALUES('Adams','Spring','Pittsfield'); INSERT INTO customer VALUES('Brooks','Senator','Brooklyn'); INSERT INTO customer VALUES('Curry','North','Rye'); INSERT INTO customer VALUES('Glenn','Sand Hill','Woodside'); INSERT INTO customer VALUES('Green','Walnut','Stamford'); INSERT INTO customer VALUES('Hayes','Main','Harrison'); INSERT INTO customer VALUES('Johnson','Alma','Palo Alto'); INSERT INTO customer VALUES('Jones','Main','Harrison'); INSERT INTO customer VALUES('Lindsay','Park','Pittsfield'); INSERT INTO customer VALUES('Smith','North','Rye'); INSERT INTO customer VALUES('Turner','Putnam','Stamford'); INSERT INTO customer VALUES('Williams','Nassau','Princeton'); COMMIT;

Gambar 5.9. Contoh Penggunaan dan hasil dari perintah .dump

.quit

Dot command quit digunakan untuk mengakhiri penggunaan program sqlite3.

5.8. Transaksi SQL

Transaksi SQL dapat diartikan sebagai suatu koleksi operasi yang membentuk 1 unit kesatuan tetapi tersusun atas sekelompok SQL statement dan query yang akan dieksekusi secara berurutan. SQLite seperti juga RDBMS lain yang bersifat transaksional harus memenuhi 4 kriteria standar yang dapat disingkat sebagai ACID (Atomicity, Consistency, Isolation dan Durability).

Pada SQLite dan RDBMS lain yang bersifat transaksional, maka terdapat 3 pernyataan atau statement dasar yang digunakan untuk mengendalikan transaksi. Pernyataan-pernyataan SQL ini adalah :

1. BEGIN TRANSACTION : pernyataan yang digunakan untuk memulai suatu transaksi. 2. COMMIT : pernyataan yang digunakan untuk menyimpan perubahan 3. ROLLBACK TRANSACTION : digunakan untuk melakukan rollback perubahan yang sudah terjadi

pada basis data.


Setiap transaksi pada SQLite harus diawali oleh pernyataan BEGIN TRANSACTION atau BEGIN, gambar 5.10 dibawah ini menunjukkan penggunaan perintah BEGIN TRANSACTION pada suatu transaksi yang akan memindahkan saldo customer (nasabah) Jhonson sebesar 100 dari akun A-101 ke akun Jhonson yang lain yaitu A-201. Contoh proses transaksi di gambar 5.10 dilakukan dengan menggunakan program command-line shell sqlite3 pada basis data bankSilberschatz.db.

SQLite version 3.31.1 2020-01-27 19:55:54 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> .open bankSilberschatz.db sqlite> .header on sqlite> .mode column sqlite> SELECT * FROM depositor NATURAL JOIN account;

customer_name account_number branch_name balance ---------------------- ----------------------- ------------------- ---------- Hayes A-102 Perryridge 400 Johnson A-101 Downtown 500 Johnson A-201 Brighton 900 Jones A-217 Brighton 750 Lindsay A-222 Redwood 700 Smith A-215 Mianus 700 Turner A-305 Round Hill 350

sqlite> BEGIN TRANSACTION; -- Transaksi Dimulai sqlite> UPDATE account -- balance dari account = A-101 berkurang 100 ...> SET balance = balance - 100 ...> WHERE account_number = 'A-101'; sqlite> UPDATE account -- balance dari account = A-201 bertambah 100 ...> SET balance = balance + 100 ...> WHERE account_number = 'A-201'; sqlite> SELECT *FROM depositor NATURAL JOIN account;


sqlite>

Gambar 5.10. Contoh Penggunaan BEGIN TRANSACTION

Setiap proses transaksi masih dapat dibatalkan selama transaksi belum diakhiri dengan

pengeksekusian perintah COMMIT. Untuk membatalkan suatu transaksi yang belum diakhiri dengan COMMIT, dapat digunakan perintah ROLLBACK TRANSACTION atau ROLLBACK. Contoh penggunaan ROLLBACK untuk membatalkan transaksi pada gambar 5.10 dapat dilihat pada gambar 5.11.

Nilai balance

sebelum

transaksi

Nilai balance

sesudah

transaksi






sqlite> ROLLBACK TRANSACTION; sqlite> SELECT * FROM depositor NATURAL JOIN account;


Gambar 5.11. Contoh Penggunaan ROLLBACK TRANSACTION

Nilai balance

sebelum

transaksi

Nilai balance

sesudah

transaksi

Nilai balance

kembali seperti

sebelum

transaksi


Jika suatu transaksi akan diakhiri dan tidak akan dirubah lagi, maka setiap transaksi harus diakhiri dengan pernyataan COMMIT. Setelah pernyataan COMMIT dieksekusi maka isi dari basis data akan mengalami perubahan yang bersifat permanen dan tidak dapat dikembalikan melalui statement ROLLBACK. Gambar 5.12 menunjukkan perubahan yang bersifat permanen karena transaksi sudah diakhiri dengan pernyataan COMMIT.





sqlite> COMMIT; -- Akhir dari Transaksi sqlite> ROLLBACK TRANSACTION; -- ROLLBACK setelah COMMIT Error: cannot rollback - no transaction is active -- Pesan kesalahan (transaksi sudah berakhir) -- karena tidak ada lagi transaksi yang -- berjalan

Nilai balance

sebelum

transaksi

Nilai balance

sesudah

transaksi


sqlite> SELECT * FROM depositor NATURAL JOIN account; customer_name account_number branch_name balance ---------------------- ----------------------- ------------------- ---------- Hayes A-102 Perryridge 400 Johnson A-101 Downtown 400 Johnson A-201 Brighton 1000 Jones A-217 Brighton 750 Lindsay A-222 Redwood 700 Smith A-215 Mianus 700 Turner A-305 Round Hill 350

sqlite>

Gambar 5.11. Contoh Penggunaan COMMIT untuk mengakhiri suatu transaksi

Nilai balance

tetap seperti

sesudah

transaksi


6

Entity Relationship Model

Model Data dapat didefinisikan sebagai kumpulan perangkat konseptual untuk menggambarkan data, hubungan data, semantik (makna) data dan batasan data. Entity–Relationship (E-R) Model adalah salah satu model data tingkat tinggi (high level) atau model konseptual yang didasarkan pada tinjauan terhadap fakta “dunia nyata” (real world) yang didalamnya akan berisi sekumpulan obyek-obyek dasar yang disebut sebagai entitas (entity) dan “hubungan” (relationship) antar obyek-obyek tersebut. Para perancang basis data seringkali menggunakan pemodelan Entity Relationship untuk memodelkan data dari “dunia nyata”, kemudian akan menerjemahkan (mentranslasikan) hasil pemodelan Entity Relationship tersebut ke bentuk pemodelan lain seperti model data relasional.

Istilah “dunia nyata” (real world) pada paragraf diatas tidak boleh diartikan sebagai dunia sebenarnya dan segala isinya tetapi lebih bermakna sempit yang merujuk pada semesta (keseluruhan) data yang belum terstruktur yang secara nyata ada/terkait dalam sebuah lingkup topik yang sedang ditinjau. Oleh karena itu, fakta “dunia nyata” suatu sistem akan berbeda dengan fakta “dunia nyata” dari sistem yang lain.

Untuk aplikasi dengan fakta “dunia nyata” yang sederhana dan kecil, sangat dimungkinkan bagi perancang basis data yang sudah memahami kebutuhan dari aplikasi tersebut untuk menentukan secara langsung entitas, hubungan antar entitas, atribut dan batasan (constraint) data yang dibutuhkan oleh aplikasi tersebut. Hal ini akan berbeda, jika aplikasi yang akan dibangun memiliki kebutuhan basis data dengan tingkat kompleksitas yang tinggi. Untuk aplikasi yang membutuhkan basis data yang data atau faktanya diperoleh dari “dunia nyata” dengan memiliki kompleksitas tinggi, maka perancang basis data harus berinteraksi dengan pengguna dan ahli dibidang sistem tersebut untuk dapat lebih memahami kebutuhan data dari pengguna. Setelah perancang basis data memperoleh spesifikasi kebutuhan pengguna, maka perancang basis data harus dapat merepresentasikan dan memberikan kerangka konseptual tentang kebutuhan data pada level konseptual, sehingga dapat dipahami baik oleh pengguna atau perancang basis data itu sendiri.

Entity Relationship model adalah salah satu pemodelan yang dapat dijadikan sebagai model konseptual dimana pada model ini maka kebutuhan data dari basis data serta struktur basis data yang dapat memenuhi kebutuhan tersebut dapat ditunjukkan secara sistematis. Pada Entity Relationship model maka rancangan konseptual dari suatu basis data akan digambarkan dengan menggunakan 3 komponen dasar yaitu himpunan entitas (entity set), himpunan hubungan antar entitas (Relationship set) serta atribut.

6.1. Tinjauan Terhadap Hubungan ER- Model dengan Tahapan Perancangan Basis Data.

Menurut (Ramakhrisnan, R. Dan Gehrke, J, “Database Management System 2nd edition”, McGraw Hill, 2000 ), maka tahapan proses perancangan basis data yang bersifat kompleks dapat dipecah menjadi 6 tahapan, yaitu :

1. Analisis kebutuhan (Requirement Analysis) Pada tahapan ini perancang basis data harus dapat menangkap dan mengungkap fakta “dunia nyata” (real world) apa saja yang dibutuhkan oleh pengguna untuk dapat disimpan dalam basis data. Oleh karena itu pada tahapan ini perancang basis data harus berkomunikasi dan berdiskusi dengan pengguna dan ahli-ahli yang memahami tentang sistem yang akan dibuatkan basis datanya. Perancang basis data juga harus memahami bagaimana proses-proses sistem yang sudah ada dapat berlangsung dan perubahan-perubahan yang diharapkan oleh pengguna. Perancang basis data juga harus mempelajari dan menganalisis seluruh dokumen-dokumen


yang digunakan dalam sistem yang sedang berjalan, serta bagaimana dokumen-dokumen tersebut dapat dihasilkan. Hasil dari proses analisis kebutuhan berupa spesifikasi kebutuhan basis data akan menjadi masukan dan dasar dari tahapan-tahapan berikutnya.

2. Perancangan Basis Data Konseptual (Conceptual Database Design) Pada tahapan ini hasil dari analisis kebutuhan akan digunakan untuk mendapatkan rancangan konseptual dari basis data dimana rancangan konseptual ini harus berisi deskripsi tentang data yang akan disimpan dalam basis data yang akan dibuat. Selain deskripsi tentang data, maka rancangan konseptual juga harus memuat batasan (constraint) dari data-data yang akan disimpan. Salah satu jenis rancangan konseptual yang dapat dibuat oleh perancang basis data adalah Entity Relationship Model.

3. Perancangan Basis Data Secara Logis (Logical Database Design) Pada tahapan ini, maka perancang basis data harus menentukan jenis DBMS yang digunakan. Jika DBMS yang digunakan adalah RDBMS (Relational Database Management System) dan rancangan konseptual yang digunakan pada tahapan perancangan konseptual adalah Entity Relationship Model, maka pada tahapan ini perancang harus melakukan transformasi hasil pemodelan Entity Relationship ke bentuk model relasional yaitu dalam bentuk schema basis data relasional.

4. Penyempurnaan Schema (Schema Refinement) Pada tahapan ini, schema basis data yang sudah didapat pada tahapan sebelumnya akan disempurnakan. Jika DBMS yang digunakan adalah RDBMS, maka salah satu proses penyempurnaan yang perlu dilakukan adalah melakukan normalisasi terhadap relasi atau tabel-tabel yang sudah diperoleh pada tahapan perancangan logis.

5. Perancangan Basis Data secara Fisik (Physical Database Design) Pada tahapan ini, perancang basis data harus mempertimbangkan beban yang harus ditanggung dan didukung oleh basis data sehingga basis data yang dibuat dapat memenuhi kriteria unjuk kerja seperti yang diharapkan. Penyempurnaan basis data yang dapat dilakukan pada tahapan ini dapat berupa pemilihan organisasi file, dan penentuan index yang tepat pada tabel-tabel yang sudah ada. Pada tahapan ini juga masih dapat dilakukan peninjauan ulang pada schema basis data yang digunakan, sehingga bila diperlukan dapat dilakukan proses denormalisasi, penciptaan view baru dan sebagainya. Secara keseluruhan hasil dari perancangan basis data secara fisik haruslah ditujukan agar basis data yang dibuat dapat memenuhi beban yang mungkin terjadi pada saat basis data tersebut digunakan.

6. Perancangan Keamanan Basis Data (Security Design) Pada tahapan ini, salah satu aspek yang penting dan perlu ditentukan oleh perancang basis data adalah menentukan tabel, view dan data apa saja yang dapat diakses dan tidak dapat diakses oleh setiap jenis role di sisi pengguna.

Dari tahapan-tahapan diatas dapat disimpulkan bahwa penciptaan Entity Relationship Model terjadi pada tahapan ke-2 yaitu pada tahap perancangan basis data secara konseptual. Walaupun penciptaan Entity relationship model terjadi pada tahapan ke-2, tetapi secara umum Entity Relationship Model juga memiliki hubungan yang erat dengan tahapan awal yaitu analisis kebutuhan dan tahapan ke-3 yaitu perancangan basis data secara logis.

6.2. Entitas (Entity) dan Himpunan Entitas (Entity Set)

Entitas adalah obyek “dunia nyata” yang dapat dibedakan dari obyek lain. Contoh dari entitas adalah seorang nasabah, seorang pembeli, sebuah pesawat, sebuah kata, sebuah buku dan sebagainya. Salah satu ciri dari entitas adalah setiap entitas haruslah bersifat unik.

Himpunan entitas adalah sekelompok entitas sejenis yang berada dalam lingkup serta memiliki karakteristik yang sama. Contoh dari himpunan entitas adalah nasabah atau customer bank, pesawat, kata, buku dan sebagainya.


Gambar 6.1.a. dibawah ini menunjukkan contoh dari himpunan entitas yang ada pada contoh “dunia nyata” bank (Silberschatz, et al, “Database Management System 5th edition”, 2005) yaitu himpunan entitas customer dan himpunan entitas loan.

(a)

Adams Spring Pittsfield

Curry North Rye

Jackson Dupont Woodside

Hayes Main Harrison

Jones Main Harrison

Smith North Rye

Williams Nassau Princeton

customer

L-11 900

L-14 1500

L-15 1500

L-16 1300

L-17 1000

L-23 2000

L-19 500

loan

(b)

Gambar 6.1. Himpunan Entitas customer dan Himpunan Entitas loan

Dari contoh pada gambar 6.1.a. dan 6.1.b dapat dilihat bahwa setiap entitas akan direpresentasikan dengan sejumlah atribut. Atribut adalah karakteristik yang dimiliki oleh setiap anggota dari himpunan entitas. Setiap anggota himpunan entitas akan memiliki jumlah dan jenis atribut yang sama tetapi memiliki nilai atributnya sendiri-sendiri. Pada contoh di gambar 6.1.a maka atribut dari himpunan entitas customer adalah customer_id, customer_name, customer_street dan customer city, sedangkan untuk himpunan entitas loan digunakan atribut-atribut loan_number dan amount. Pada gambar 6.1.b maka atribut dari himpunan entitas customer adalah customer_name, customer_street dan customer_city, sedangkan untuk himpunan entitas loan digunakan atribut-atribut loan_number dan amount.

Penentuan dari himpunan entitas, dan atribut – atribut dari himpunan entitas akan bergantung pada hasil analisis kebutuhan yang digunakan oleh perancang basis data. Analisis kebutuhan akan bergantung pada fakta “dunia nyata” yang diperoleh atau ditinjau oleh perancang basis data. Oleh karena itu dapat dilihat bahwa pada contoh 6.1.a fakta “dunia nyata” yang digunakan oleh perancang basis data memungkinkan adanya customer dengan nama yang sama sehingga dibutuhkan atribut customer_id, sedangkan pada contoh 6.1.b fakta “dunia nyata” yang digunakan oleh perancang basis data tidak memungkinkan adanya customer yang memiliki nama yang sama.


Alasan yang sama juga menyebabkan baik pada contoh 6.1. a dan 6.1.b tidak terdapat atribut kode pos, tanggal dan tempat lahir dan atribut-atribut lain dari customer yang mungkin pada “dunia nyata” bank dengan kompleksitas yang tinggi, haruslah juga dimasukkan sebagai fakta atau data yang tersimpan dalam basis data.

Himpunan entitas dapat dibagi menjadi 2 jenis yaitu :

1. Himpunan Entitas Kuat (Strong Entity) Himpunan entitas yang keberadaannya berdiri sendiri dan tidak bergantung pada himpunan entitas lain. Contoh dari himpunan entitas kuat adalah customer, loan, branch dan sebagainya.

2. Himpunan Entitas Lemah (Weak Entity) Himpunan entitas yang keberadaanya tidak berdiri sendiri dan bergantung pada keberadaan entitas kuat. Contoh dari himpunan entitas lemah adalah himpunan entitas payment (pembayaran) yang akan bergantung pada entitas kuat loan.

6.3. Relationship (Hubungan antar Entitas)1) dan Relationship set (Himpunan Hubungan antar

Entitas)2)

Relationship (hubungan antar entitas) 1) menunjukkan adanya hubungan atau asosiasi antar

entitas yang berbeda. Contoh dari relationship adalah suatu relationship (hubungan antar entitas)

yang menghubungkan antara entitas nasabah peminjam bernama Hayes dengan loan atau pinjaman

yang memiliki loan number L-15. Hubungan yang dibentuk dari relationship ini adalah Hayes adalah

seorang customer yang memiliki loan dengan Loan Number L-15.

Relationship Set (himpunan hubungan antar entitas) 2) adalah himpunan atau sekelompok

relationship yang terbentuk dari sejumlah relationship sejenis. Contoh dari himpunan relationship

dapat dilihat pada gambar 6.2. dibawah ini. Pada gambar 6.2 didefinisikan suatu himpunan

relationship borrower yang merupakan himpunan relationship di antara entitas-entitas dari

himpunan entitas customer dan entitas-entitas dari himpunan entitas loan.

Gambar 6.2. Himpunan hubungan antar entitas (Relationship Set) borrower

Catatan :

1) : Untuk menyingkat penulisan, maka pada diktat ini istilah yang digunakan tetap relationship

2)

:Untuk menyingkat penulisan, maka pada diktat ini istilah yang digunakan adalah himpunan relationship


Peran dan fungsi dari suatu entitas yang berpartisipasi dalam sebuah relationship disebut

sebagai entity’s role (peran dari entitas). Jika himpunan entitas yang berpartisipasi pada sebuah

relationship set merupakan himpunan-himpunan entitas yang berbeda, maka role tidak perlu

dinyatakan secara eksplisit. Peran dari entitas atau role harus dinyatakan secara eksplisit jika

himpunan relationship yang terjadi adalah berupa himpunan relationship yang bersifat rekursif

(recursive relationship set). Recursive relationship set adalah himpunan relationship yang akan

menghubungkan entitas-entitas yang berada pada himpunan entitas yang sama. Contoh dari

recursive relationship set adalah himpunan relationship works_for (bekerja untuk) yang ada

diantara entitas – entitas di himpunan entitas employee (pekerja) di dalam suatu bank. Pada

himpunan relationship works_for, maka anggota-anggota dari himpunan entitas employee dapat

memiliki peran (role) yang berbeda yaitu manager dan worker, dimana entitas pekerja yang

berperan berperan sebagai atasan (manajer) akan membawahi beberapa pekerja lain yang menjadi

bawahannya. Gambar 6.3 dibawah ini menunjukkan Entity Relationship diagram, yang memuat

recursive relationship set seperti yang sudah dicontohkan diatas.

Gambar 6.3. Contoh Recursive Relationship Set 3)

Seperti pada Himpunan Entitas, maka suatu himpunan relationship dimungkinkan untuk

memiliki atribut yang disebut sebagai Descriptive Attribute. Gambar 6.4. berikut menunjukkan suatu

contoh descriptive attribute yang disebut acces_date pada himpunan relationship depositor yang

menghubungkan antara himpunan entitas customer dengan himpunan entitas account.

Gambar 6.4. Contoh Recursive Relationship Set

(Catatan : 3)

Notasi ERD yang digunakan adalah notasi Silberschatz – Korth pada Database Management System 5 th Edition, 2005)


6.4. Atribut (Attributes / Properties)

Setiap entitas akan memiliki atribut yang mendeskripsikan karakteristik dari entitas tersebut.

Untuk setiap atribut maka tersedia sejumlah nilai yang diizinkan untuk digunakan sebagai nilai dari

atribut tersebut. Sejumlah nilai yang dapat digunakan sebagai nilai dari atribut disebut sebagai

domain nilai dari atribut tersebut. Salah satu contoh domain nilai adalah domain nilai untuk atribut

loan_number yaitu string dalam bentuk “L-n” dimana n adalah bilangan bulat positif.

Secara formal, maka suatu atribut dari sebuah entitas adalah sebuah fungsi yang akan

memetakan himpunan entitas tersebut ke suatu domain nilai tertentu. Karena suatu entitas mungkin

memiliki sejumlah atribut, maka entitas tersebut dapat dideskripsikan dengan sejumlah pasangan

(atribut,nilai atribut) untuk setiap atribut yang ada pada himpunan entitas.

Contoh Soal 6.1. Jika diberikan himpunan entitas customer sebagai berikut :

Nyatakanlah himpunan entitas customer tersebut dengan notasi himpunan yang menyertakan pasangan (atribut, nilai atribut) dari setiap entitas yang ada pada himpunan entitas. Jawab : Jika Himpunan entitas diatas akan dinyatakan dengan notasi himpunan yang menyertakan pasangan (atribut, nilai atribut), maka hasil yang diperoleh adalah sebagai berikut : { {(customer_id,321-12-3123),(customer_name,Jones),(customer_street, Main),(customer_city,Harrison)}, {(customer_id,019-28-3746),(customer_name,Smith),(customer_street, North),(customer_city,Rye)}, {(customer_id,677-89-9011),(customer_name,Hayes),(customer_street, Main),(customer_city,Harrison)}, {(customer_id,555-55-5555),(customer_name,Jackson),(customer_street, Dupont),(customer_city,Woodside)}, {(customer_id,244-66-8800),(customer_name,Curry),(customer_street, North),(customer_city,Rye)}, {(customer_id,963-96-3963),(customer_name,Williams),(customer_street, Nassau),(customer_city,Princeton)}, {(customer_id,335-57-7991),(customer_name,Adams),(customer_street, Spring),(customer_city,Pittsfield)} }

customer_ id

customer_ name

customer_ street

customer_ city


Jenis-jenis atribut yang dapat digunakan pada Entity Relationship Model antara lain adalah :

Atribut Sederhana (Simple Attribute)

Atribut yang memiliki komponen tunggal. Contohnya : customer_id

Atribut komposit (Composite Attribute)

Atribut yang tersusun dari beberapa atribut lainnya. Atribut penyusun atribut komposit

dapat berupa atribut sederhana dan atau atribut komposit yang lain. Contohnya : atribut

nama dan atribut alamat seperti pada gambar 6.5 berikut.

Gambar 6.5. Contoh Atribut Komposit

Atribut bernilai tunggal (Single Value Attribute)

Atribut yang hanya menyimpan 1 nilai untuk setiap obyek entitas.

Contohnya atribut customer_id

Atribut bernilai jamak (Multi value Attribute)

Atribut yang dapat memiliki lebih dari 1 nilai untuk setiap obyek entitas. Contohnya atribut

nomor telefon

Atribut turunan (Derived Attribute)

Atribut yang nilainya dapat diperoleh dari atribut atau komponen lainnya. Contohnya atribut

Umur

6.5. Constraint (Batasan)

Suatu model konseptual basis data yang dibuat dengan Entity Relationship Model juga dapat

dilengkapi dengan batasan-batasan (constraints) yang harus dipenuhi oleh basis data yang

dimodelkan tersebut. Batasan-batasan yang dapat ditambahkan pada suatu model yang dibuat

dengan Entity Relationship Model antara lain adalah :

Batasan Kardinalitas (Cardinality Mapping)

Key Constraint (kunci yang digunakan pada himpunan entitas dan himpunan relationship)

Batasan Partisipasi (Participation Constraint)


6.5.1. Batasan Kardinalitas

Batasan kardinalitas (rasio kardinalitas atau mapping cardinality) digunakan untuk menunjukkan

jumlah maksimum entitas lain yang dapat berasosiasi dengan suatu obyek entitas tertentu.

Untuk suatu himpunan relationship yang berjenis Binary Relationship Set (Himpunan

relationship yang menghubungkan 2 himpunan entitas yang berbeda), maka rasio kardinalitas yang

dimungkinkan adalah :

1. Satu Ke Satu (One to One atau 1:1)

2. Satu Ke Banyak (One to Many atau 1 : N)

3. Banyak ke Satu (Many to One atau N : 1)

4. Banyak ke Banyak (Many to Many atau M:N)

Gambar 6.6. dibawah ini menunjukkan ke 4 jenis batasan kardinalitas dalam himpunan relationship

antara 2 himpunan entitas yaitu himpunan entitas A dan himpunan entitas B.

(a) Satu Ke Satu (1:1)

(b) Satu Ke Banyak (1 : N)

(c) Banyak Ke Satu (N:1)

(d) Banyak Ke Banyak (M:N)

(b)

Gambar 6.6. Jenis-jenis batasan kardinalitas pada Binary Relationship Set


6.5.2. Key Constraint

Kunci Pada Himpunan Entitas Untuk dapat membedakan setiap obyek baik pada entity set (himpunan entitas) maupun

relationship set (himpunan keterhubungan) maka dibutuhkan atribut-atribut yang dapat membedakan obyek-obyek tersebut.

Suatu super key dari suatu himpunan entitas adalah 1 atau lebih atribut yang nilainya dapat digunakan untuk membedakan obyek-obyek entitas pada suatu himpunan entitas. Suatu candidate key dari sebuah himpunan entitas adalah 1 atau lebih atribut yang jumlahnya paling minimal dan dapat digunakan untuk membedakan obyek-obyek entitas dari suatu himpunan entitas. Suatu primary key dari sebuah himpunan entitas adalah sebuah candidate key yang dipilih dari beberapa candidate key yang tersedia.

Kunci Pada Himpunan Relationship Sebagaimana himpunan entitas yang berisi sejumlah entitas, maka pada himpunan relationship

juga akan beranggotakan sejumlah relationship. Setiap relationship juga harus dapat dibedakan 1

dengan yang lain. Pada umumnya, jika jenis himpunan relationship yang sedang ditinjau adalah

binary relationship set yang bertipe Banyak Ke Banyak, maka gabungan kunci tamu yang berasal dari

kunci primer dari masing-masing himpunan entitas yang berpartisipasi (ikut serta) dalam himpunan

relationship tersebut akan membentuk super key dari himpunan relationship tersebut.

6.5.3. Batasan Partisipasi

Batasan partisipasi dalam Entity Relationship model adalah batasan yang menentukan apakah

semua atau sebagian dari obyek-obyek entitas dapat berpartisipasi pada suatu himpunan

relationship. Batasan partisipasi dapat dibedakan menjadi 2 yaitu :

1. Mandatory (Full / Total) : Seluruh obyek himpunan entitas harus berpartisipasi pada

himpunan relationship

2. Optional (Partial) : Tidak seluruh obyek himpunan entitas berpartisipasi pada himpunan

relationship

6.6. Entity Relationship Diagram (ERD)

Model konseptual basis data yang dihasilkan dari pemodelan Entity Relationship biasanya akan

ditunjukkan menggunakan diagram yang disebut sebagai Entity Relationship Diagram atau ERD. Saat

ini terdapat banyak notasi yang dapat digunakan untuk membuat Entity Relationship Diagram.

Notasi-notasi Entity Relationship diagram tersebut antara lain adalah Notasi Silberschatz-Korth,

Notasi Chen, Notasi Information Engineering atau Crow’s Foot notation, Notasi Barker, Notasi IDEF1X

(Integration DEFinition For Information Modelling) dan sebagainya. Masing-masing notasi memiliki

aturan dan simbol-simbol yang berbeda dalam membuat diagram Entity Relationship.

Mengingat jumlah notasi ERD yang banyak, maka pada diktat ini hanya akan dijelaskan sebagian

kecil dari dasar-dasar notasi-notasi Entity Relationship Diagram yang ada dan dapat digunakan saat

ini.


6.6.1. Notasi Silberschatz – Korth – Sudarshan

1. Notasi Silberschatz – Korth – Sudarshan (“Database System Concepts 5th Edition”,2005) Tabel 6.1. dibawah ini menunjukkan Simbol – simbol komponen ERD pada Notasi Silberschatz –

Korth - Sudarshan yang digunakan pada buku “Database System Concepts 5th Edition”,2005. Notasi

Silberschatz – Korth – Sudarshan adalah salah satu notasi yang merupakan varian dari notasi Chen

karena pada notasi Silbershatz – Korth – Sudarshan, sebagian besar simbol-simbol ERD yang

digunakan adalah simbol-simbol dasar yang diperoleh dari notasi Chen.

Tabel 6.1. Simbol-simbol Notasi ERD Silbershatz – Korth - Sudarshan Pada “Database System Concepts 5th Edition”,2005

Nama Komponen Bentuk Simbol Penjelasan

Himpunan Entitas Kuat (Strong Entity Set)

Himpunan Entitas lemah

(Weak Entity Set)

Atribut (Attribute)

Nama atribut diberi garis bawah jika atribut adalah bagian dari kunci primer suatu himpunan entitas kuat.

Nama atribut tidak diberi garis bawah jika atribut bukan bagian dari kunci primer

Nama atribut diberi garis bawah putus-putus jika atribut adalah bagian dari atribut pembeda dari suatu himpunan entitas lemah

Atribut Bernilai Jamak (Multivalued Attribute)

Atribut Turunan (Derived Attribute)

Himpunan Relationship

Himpunan Identifying Relationship

Simbol himpunan relationship yang akan menghubungkan antara himpunan entitas lemah dengan himpunan entitas kuat

Himpunan Entitas


Lanjutan Tabel 6.1. Simbol-simbol Notasi ERD Silbershatz – Korth-Sudarshan Pada “Database System Concepts 5th Edition”,2005


Penghubung antara himpunan entitas dengan atribut dan himpunan relationship dengan descriptive attribute

Kardinalitas (Jumlah maksimum Entitas lain yang dapat dihubungkan dengan satu anggota himpunan Entitas yang sedang ditinjau pada sebuah himpunan relationship)

Menunjukkan bahwa hanya 1 entitas lain yang dapat dihubungkan dengan satu anggota himpunan entitas yang sedang ditinjau. (Sisi 1 atau one) Catatan : Simbol diletakkan diseberang dari himpunan entitas yang sedang ditinjau (look accross)

Menunjukkan bahwa jumlah entitas lain yang dapat dihubungkan adalah banyak ( N atau many) Catatan: Simbol diletakkan diseberang dari himpunan entitas yang sedang ditinjau (look across)

Batasan Partisipasi / Participation Constraint (Jumlah minimum keikutsertaan Entitas dari himpunan entitas yang sedang ditinjau dalam suatu himpunan relationship (Batasan Partisipasi/Participation Constraint)

Menunjukkan bahwa keikut sertaan dari anggota himpunan entitas yang ditinjau dalam suatu himpunan relationship adalah bersifat partial Catatan: Simbol diletakkan disisi yang sama dengan himpunan entitas yang sedang ditinjau. (look here)

Menunjukkan bahwa keikut sertaan dari anggota himpunan entitas yang ditinjau dalam suatu himpunan relationship adalah bersifat wajib atau total (full / mandatory) Catatan: Simbol diletakkan disisi yang sama dengan himpunan entitas yang sedang ditinjau. (look here)

Spesialisasi atau generalisasi (Himpunan relationship antara Superclass dan Subclass)

IS A


Contoh Soal 6.2. Tentukan gambar diagram ERD dengan notasi Silberschatz-Korth-Sudarshan (“Database System Concepts 5th Edition”,2005) jika diketahui pada ERD tersebut :

Terdapat 2 himpunan entitas :

Himpunan entitas customer Memiliki atribut : customer_id, customer_name, customer_street,dan customer_city kunci_primer : customer_id

Himpunan entitas loan Memiliki atribut : loan_number, amount kunci primer : loan_number

Terdapat 1 himpunan relationship borrower yang menghubungkan himpunan entitas loan dan himpunan entitas customer dengan batasan :

Rasio Kardinalitas adalah many to many

Batasan Partisipasi dari himpunan entitas customer adalah partial Batasan Partisipasi dari himpunan entitas loan adalah total/wajib (full/mandatory)

Jawab : Urutan penggambaran Diagram ERD dengan notasi Silberschatz – Korth – Sudarshan yang diperoleh dengan batasan-batasan sistem diatas adalah :

1. Gambarkan seluruh himpunan entitas beserta seluruh atribut dari masing-masing himpunan entitas yang ada pada sistem

2. Gambarkan himpunan relationship

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number amount

borrower

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number

amount


3. Gambarkan Kardinalitas

Karena rasio kardinalitas himpunan relationship borrower adalah Banyak ke Banyak maka :

Jumlah maksimum entitas loan yang dapat dihubungkan ke 1 entitas customer jika ditinjau dari entitas customer adalah banyak

Jumlah maksimum entitas customer yang dapat dihubungkan ke 1 entitas loan jika ditinjau dari entitas loan adalah banyak

4. Gambarkan batasan partisipasi dari himpunan entitas customer yaitu bersifat partial dan

himpunan entitas loan yaitu bersifat wajib (total /full).

5. Karena terdapat garis-garis yang saling berhimpit khususnya hasil penggambaran

kardinalitas dan batasan partisipasi maka : Hasil akhir dari diagram ERD

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number amount

borrower

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number amount

borrower

Batasan partisipasi diletakkan di sisi yang sama

dengan himpunan entitasnya (look here)

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number amount

borrower

Kardinalitas diletakkan di seberang (look across)


Contoh Soal 6.3. Jika diberikan uraian hasil analisis kebutuhan sebagai berikut :

Suatu bank memiliki banyak cabang , setiap cabang dapat memberikan 0..N pinjaman (loan).

Setiap pinjaman (loan) hanya tercatat pada 1 cabang .

cabang(branch) dan pinjaman (loan) adalah himpunan entitas

Himpunan relationship yang menghubungkan antara himpunan entitas branch dengan himpunan entitas loan disebut sebagai himpunan relationship loan_branch

Setiap pinjaman akan dibedakan dengan loan_number.

Amount (besar) dari setiap pinjaman harus tercatat dalam basis data

Setiap cabang akan dibedakan berdasarkan branch_name, serta setiap cabang juga akan memiliki karakteristik seperti branch_city dan assets

Gambarkanlah Diagram ERD dengan notasi Silberschatz-Korth-Sudarshan (Database Management System 5th edition) dari Entity Relatioship Model yang sesuai dengan uraian fakta “dunia nyata” diatas Jawab : Dari uraian fakta “Dunia Nyata” yang diberikan, maka dapat disimpulkan :

1. Terdapat 2 himpunan entitas yaitu himpunan entitas branch dan himpunan entitas loan 2. Himpunan entitas branch memiliki atribut : branch_name, branch_city dan assets. Kunci

primer dari himpunan entitas branch adalah branch_name 3. Himpunan entitas loan memiliki atribut : loan_number dan amount. Kunci primer dari

himpunan entitas loan adalah loan_number 4. Himpunan relationship yang menghubungkan himpunan entitas branch dengan

himpunan entitas loan disebut himpunan relationship loan_branch 5. Jumlah minimum dan maksimum entitas loan yang dapat dihubungkan dengan 1 entitas

branch adalah 0 dan banyak (0..N). 6. Jumlah minimum dan maksimum entitas branch yang dapat dihubungkan dengan 1

entitas loan adalah 1 dan 1 atau (1..1) 7. Kardinalitas himpunan relationship loan_branch adalah satu ke banyak (one to many)

dari arah branch ke loan atau banyak ke satu (many to one) dari arah loan ke branch. 8. Batasan partisipasi dari himpunan entitas loan adalah wajib atau total (full) sedangkan

batasan partisipasi dari himpunan entitas branch adalah partial. Berdasarkan kesimpulan diatas dan bila digunakan langkah-langkah seperti yang telah ditunjukkan pada contoh soal 6.2, maka hasil akhir diagram ERD yang menunjukkan sistem diatas adalah :

Hasil akhir dari diagram ERD


Gambar 6.7. dibawah ini adalah contoh ERD dari basis data bank dengan fakta dunia “nyata” yang

sederhana. ERD tersebut digambar dengan menggunakan Notasi Silbershatz – Korth – Sudarshan

(“Database System Concepts 5th Edition”,2005).

Gambar 6.7. E-R Diagram untuk suatu Bank Enterprise (Silberschatz et al, “Database System Concepts 5th Edition”,2005)

2. Notasi Silberschatz – Korth – Sudarshan (“Database System Concepts 6th Edition”,2011)

Tabel 6.2. dibawah ini menunjukkan Simbol – simbol komponen ERD pada Notasi Silberschatz –

Korth - Sudarshan yang digunakan pada buku “Database System Concepts 6th Edition”,2011.

Perbedaan antara notasi Silberschatz – Korth – Sudarshan di buku edisi ke 6 dan edisi ke 5 terletak

khususnya pada simbol himpunan entitas dan atribut-atribut dari himpunan entitas serta atribut-

atribut dari himpunan relationship. Selain itu terdapat juga perbedaan dalam menggambarkan

adanya spesialisasi dan generalisasi di dalam suatu ERD yang dibuat.


Tabel 6.2. Simbol-simbol Dasar Notasi ERD Silbershatz – Korth Pada “Database System Concepts 6th Edition”,2011


Himpunan Entitas

Himpunan Entitas

Himpunan Entitas Kuat dan Himpunan Entitas lemah dilambangkan dengan persegi yang dibagi menjadi 2 bagian, nama Himpunan Entitas diletakkan di bagian persegi panjang yang diatas

Atribut dari Himpunan Entitas

Text nama atribut dari himpunan entitas diletakkan di bagian persegi panjang bawah simbol himpunan entitas, dan :

Atribut yang menjadi bagian kunci primer diberi garis bawah

Atribut yang menjadi bagian dari atribut pembeda pada weak entity diberi garis bawah putus-putus

Atribut yang berjenis atribut bernilai jamak diberi tanda kurung kurawal

Atribut yang berjenis atribut turunan diakhiri dengan simbol ()

Atribut-atribut pembentuk atribut komposit harus diberi indentasi dari atribut kompositnya

Contoh :

customer

customer_id name

first_name middle_name last_name

address street

street_name street_number apartment_number

city state zip_code

date_of_birth {phone_number} age()

Atribut pada Himpunan Relationship

(Descriptive Attribute)

Menggunakan simbol persegi panjang yang tidak terbagi, seluruh anggota descriptive attribute ditulis dalam persegi panjang tersebut dan simbol simbol persegi panjang tersebut akan dihubungkan dengan simbol himpunan relationship menggunakan garis putus-putus.


Daftar Descriptive Attribute


Lanjutan Tabel 6.2. Simbol-simbol Dasar Notasi ERD Silbershatz – Korth Pada “Database System Concepts 6th Edition”, 2011




Rasio Kardinalitas (Jumlah maksimum Entitas lain yang dapat dihubungkan dengan satu anggota himpunan Entitas yang sedang ditinjau)


Menunjukkan bahwa jumlah entitas lain yang dapat dihubungkan adalah banyak ( N atau many) Catatan: Simbol diletakkan diseberang dari himpunan entitas yang sedang ditinjau (look across)

Batasan Partisipasi / Participation Constraint (Jumlah minimum keikutsertaan Entitas dari himpunan entitas yang sedang ditinjau dalam suatu relationship (Batasan Partisipasi/Participation Constraint)

Menunjukkan bahwa keikut sertaan dari anggota himpunan entitas yang ditinjau dalam suatu relationship adalah bersifat partial Catatan: Simbol diletakkan disisi yang sama dengan himpunan entitas yang sedang ditinjau. (look here)

Menunjukkan bahwa keikut sertaan dari anggota himpunan entitas yang ditinjau dalam suatu relationship adalah bersifat wajib atau total (full / mandatory) Catatan: Simbol diletakkan disisi yang sama dengan himpunan entitas yang sedang ditinjau. (look here)

Spesialisasi atau generalisasi (Himpunan relationship antara Superclass dan Subclass)

Panah dengan Ujung Terbuka mengarah dari subclass Entity ke Superclass Entity.


Contoh Soal 6.4. Tentukan gambar diagram ERD dengan notasi Silberschatz-Korth-Sudarshan (“Database System Concepts 6th Edition”,2011) jika diketahui pada ERD tersebut :


Himpunan entitas customer Memiliki atribut : customer_id, customer_name, dan customer addres yang terdiri dari customer_street,dan customer_city kunci_primer : customer_id





Jawab : Urutan penggambaran Diagram ERD dengan notasi Silberschatz-Korth-Sudarshan (“Database System Concepts- 6th Edition”,2011) yang diperoleh dengan batasan-batasan sistem diatas adalah :



customer

customer_id customer_name customer_address

customer_street customer_city

loan

loan_number amount

borrower

customer



loan

loan_number amount


Lanjutan Soal 6.4.

3. Gambarkan Kardinalitas Karena rasio kardinalitas himpunan relationship borrower adalah Banyak ke Banyak maka :

Jumlah maksimum entitas loan yang dapat dihubungkan ke 1 entitas customer jika ditinjau dari entitas customer adalah banyak

Jumlah maksimum entitas customer yang dapat dihubungkan ke 1 entitas loan jika ditinjau dari entitas loan adalah banyak


himpunan entitas loan yaitu bersifat total (full).

5. Karena terdapat garis-garis yang saling berhimpit khususnya hasil penggambaran kardinalitas dan batasan partisipasi maka : Hasil akhir dari diagram ERD

borrower loan

loan_number amount

customer



borrower



loan

loan_number amount

customer



borrower


customer



loan

loan_number amount


Gambar 6.8. berikut ini adalah contoh ERD dari suatu bank enterprise dengan fakta “dunia nyata”

sederhana dan diperoleh dengan cara mengkonversi ERD bank enterprise pada gambar 6.7. dimana

ERD pada gambar 6.8 sudah menggunakan notasi Silberschatz – Korth – Sudarshan (“Database

System Concepts 6 th Edition”, 2011).

Gambar 6.8. Contoh ERD Dengan Notasi Silberschatz – Korth – Sudarshan (“Database System

Concepts 6 th Edition” ,2011) 6.6.2. Notasi Chen

Entity Relationship Model pertama kali dikembangkan oleh Dr. Peter Pin Shan Chen seorang

ahli komputer – Information Engineering Amerika keturunan Taiwan. Dr. Peter Chen pertama kali

mempublikasi Entity Relationship Model pada tahun 1976 pada tulisan jurnal ilmiah yang berjudul

“The Entity Relationship Model – Toward a Unified View of Data”. Notasi yang diberikan oleh Dr.

Peter Chen untuk menggambarkan suatu Entity Relationship Model disebut sebagai Notasi Chen.

Notasi Chen merupakan dasar dari sebagian besar notasi ERD yang ada saat ini. Gambar 6.9.a.

adalah foto yang dipublikasikan oleh Dr. Peter Chen di halaman website Dr. Peter Chen di Lousiana

State University (LSU) sedangkan gambar 6.9.b adalah contoh ERD awal yang diberikan oleh Dr.

Peter Chen di tulisan ilmiah “The Entity Relationship Model – Toward a Unified View Of Data”,

1976.


(a) Dr. Peter Pin Shan Chen

(b) Contoh ERD pada Tulisan Ilmiah Dr. Peter Chen “The Entity Relationship Model – Toward a Unified View of Data”, 1976 (Catatan : Pada model awal belum dikenal simbol Associative Entity atau Gerund)

Gambar 6.9. Penemu Entity Relationship Model dan Contoh ERD awal

Selain dari tulisan ilmiah “The Entity Relationship Model – Toward a Unified View of Data”,

masih banyak tulisan-tulisan ilmiah Dr. Peter Chen yang membahas tentang penggunaan dari Entity

Relationship Model , tulisan-tulisan ilmiah tersebut antara lain adalah :

Peter Pin Shan Chen, “English Sentence Structure and Entity–Relationship Diagram”,

Elsevier Science Publishing Co. Inc, 1983

Peter Pin Shan Chen, “English, Chinese and ER – Diagrams”, Data & Knowledge

Engineering, 1997

Peter Pin Shan Chen, “A Preliminary Framework For Entity – Relationship Models”, Entity

Relationship Approach to Information Modelling and Analysis, North-Holland, 1983

Mengingat bahwa notasi Chen memiliki banyak varian karena sudah dikembangkan oleh banyak

peneliti dan tersedia di banyak aplikasi diagram drawing tools dan aplikasi data modeller, maka

untuk simbol notasi Chen yang ada pada diktat ini, hanya akan didasarkan pada acuan simbol-simbol

notasi Chen yang digunakan oleh Dr. Peter Chen di tulisan-tulisan ilmiahnya diatas dan juga akan

menggunakan acuan simbol-simbol ERD yang tersedia pada salah satu aplikasi diagram drawing

tools yang disebut sebagai aplikasi DIA.

Aplikasi diagram drawing tools DIA adalah salah satu aplikasi yang digunakan untuk

menggambar berbagai jenis diagram, salah satunya adalah diagram ERD tanpa disertai proses

otomasi untuk merubah ERD yang telah dibuat ke bentuk schema basis data atau ke bentuk

pernyataan DDL SQL.


Tabel 6.3. Simbol-simbol Notasi ERD Chen pada aplikasi diagram tools DIA


Himpunan Entitas Kuat (Strong Entity Set)

Himpunan Entitas lemah

(Weak Entity Set)

Atribut (Attribute)

Nama atribut diberi garis bawah jika atribut adalah bagian dari kunci primer suatu himpunan entitas kuat.

Nama atribut tidak diberi garis bawah jika atribut bukan bagian dari kunci primer

Nama atribut diberi garis bawah putus-putus jika atribut adalah bagian dari atribut pembeda dari suatu himpunan entitas lemah

Atribut Bernilai Jamak (Multivalued Attribute)

Atribut Turunan (Derived Attribute)




Himpunan Associative Entity

Simbol yang menunjukkan suatu himpunan Relationship dengan rasio kardinalitas Many – To – Many yang jika dikonversikan ke bentuk schema basis data relasional disebut sebagai tabel asosiatif.


Lanjutan Tabel 6.3. Simbol-simbol Dasar Notasi ERD Chen


Penghubung antara himpunan entitas dengan atribut dan himpunan relationship dengan descriptive attribute

Rasio Kardinalitas (Jumlah maksimum Entitas lain yang dapat dihubungkan dengan satu anggota himpunan Entitas yang sedang ditinjau pada sebuah himpunan relationship)

1


N dan atau M

Menunjukkan bahwa jumlah entitas lain yang dapat dihubungkan adalah banyak ( many) Catatan: Simbol diletakkan diseberang dari himpunan entitas yang sedang ditinjau (look across)

Batasan Partisipasi / Participation Constraint (Jumlah minimum keikutsertaan Entitas dari himpunan entitas yang sedang ditinjau dalam suatu himpunan relationship )

Menunjukkan bahwa keikut sertaan dari anggota himpunan entitas yang ditinjau dalam suatu himpunan relationship adalah bersifat partial Catatan: Simbol diletakkan disisi yang sama dengan himpunan entitas yang sedang ditinjau. (look here)

Menunjukkan bahwa keikut sertaan dari anggota himpunan entitas yang ditinjau dalam suatu himpunan relationship adalah bersifat wajib atau total (full / mandatory) Catatan: Simbol diletakkan disisi yang sama dengan himpunan entitas yang sedang ditinjau. (look here)

Spesialisasi dan generalisasi (Himpunan relationship antara Superclass dan Subclass)

IS A


Gambar 6.10. berikut menunjukkan contoh dari ERD dengan notasi Chen yang diberikan oleh

Dr. Peter Chen yang menggambarkan penggunaan spesialisasi dan generalisasi dalam sebuah ERD.

Gambar 6.10. Contoh ERD dengan generalisasi dan spesialisasi (subtype) pada Tulisan Ilmiah Dr. Peter Chen “English, Chinese and ER Diagrams”, 1997

Gambar 6.11.a dan 6.11.b berikut ditunjukkan 2 contoh pendekatan yang digunakan oleh Dr.

Peter Chen untuk menggambarkan agregasi dalam sebuah ERD. Pada pendekatan yang pertama Dr.

Peter Chen menggunakan simbol associative entity (Gerund) sedangkan pada pendekatan yang

kedua digunakan pendekatan dengan aggregation (high level entity type) assignment

(a). Pendekatan Pertama


(b) Pendekatan Kedua

Gambar 6.11. Contoh ERD dengan 2 pendekatan High Level Entity Types (“Relationship types defined on Relationships) pada Tulisan Ilmiah Dr. Peter Chen “English, Chinese and ER Diagrams”,

1997

Contoh Soal 6.5. Tentukan gambar diagram ERD dengan notasi Chen, jika diketahui pada ERD tersebut :








Lanjutan Contoh Soal 6.5. Jawab : Urutan penggambaran Diagram ERD dengan notasi Chen yang diperoleh dengan batasan-batasan sistem diatas adalah :



3. Gambarkan Kardinalitas Karena rasio kardinalitas himpunan relationship borrower adalah Banyak ke Banyak maka :

Jumlah maksimum entitas loan yang dapat dihubungkan ke 1 entitas customer jika ditinjau dari entitas customer adalah banyak (N)

Jumlah maksimum entitas customer yang dapat dihubungkan ke 1 entitas loan jika ditinjau dari entitas loan adalah banyak (M)

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number amount

borrower


N

M

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number amount

borrower

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number

amount



himpunan entitas loan yaitu bersifat total (full).

5. Hasil : Hasil akhir dari diagram ERD

Jika diagram ERD dengan Notasi Chen yang diinginkan mewajibkan seluruh himpunan relationship yang memiliki derajat kardinalitas Banyak ke Banyak (Many to Many) harus dalam bentuk associative entity maka :

Hasil Akhir diagram ERD

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number amount

M N borrower

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number amount

borrower

M N

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number amount

borrower



M N


Contoh Soal 6.6. Jika diberikan uraian hasil analisis kebutuhan sebagai berikut :

Suatu bank memiliki banyak cabang , setiap cabang dapat menerima 0..N tabungan (account).

Setiap tabungan (account) hanya tercatat pada 1 cabang .

cabang(branch) dan tabungan (account) adalah himpunan entitas

Himpunan relationship yang menghubungkan antara himpunan entitas branch dengan himpunan entitas loan disebut sebagai himpunan relationship account_branch

Setiap tabungan (account) akan dibedakan dengan account_number.

Balance (saldo) dari setiap tabungan harus tercatat dalam basis data

Setiap cabang akan dibedakan berdasarkan branch_name, serta setiap cabang juga akan memiliki karakteristik seperti branch_city dan assets

Gambarkanlah Diagram ERD dengan notasi Chen Jawab : Dari uraian fakta “Dunia Nyata” yang diberikan, maka dapat disimpulkan :

1. Terdapat 2 himpunan entitas yaitu himpunan entitas branch dan himpunan entitas account

2. Himpunan entitas branch memiliki atribut : branch_name, branch_city dan assets. Kunci primer dari himpunan entitas branch adalah branch_name

3. Himpunan entitas loan memiliki atribut : account_number dan balance. Kunci primer dari himpunan entitas loan adalah account_number

4. Himpunan Relationship yang menghubungkan himpunan entitas branch dengan himpunan entitas loan disebut himpunan relationship account_branch

5. Jumlah minimum dan maksimum entitas account yang dapat dihubungkan dengan 1 entitas branch adalah 0 dan banyak (0..N).

6. Jumlah minimum dan maksimum entitas branch yang dapat dihubungkan dengan 1 entitas loan adalah 1 dan 1 atau (1..1)

7. Kardinalitas himpunan relationship loan_branch adalah satu ke banyak (one to many) dari arah branch ke account atau banyak ke satu (many to one) dari arah account ke branch.

8. Batasan partisipasi dari himpunan entitas loan adalah wajib atau total (full) sedangkan batasan partisipasi dari himpunan entitas branch adalah partial.

Berdasarkan kesimpulan diatas dan bila digunakan langkah-langkah seperti yang telah ditunjukkan pada contoh soal 6.5, maka hasil akhir diagram ERD yang menunjukkan sistem diatas adalah :


6.6.3. Notasi Information Engineering (IE) atau Notasi Crow’s Foot

Notasi Information Engineering Entity Relationship adalah notasi Entity Relationship Diagram

yang digunakan oleh pencipta dan penemu salah satu Metodologi Perekayasaan Sistem Teknologi

Informasi yang disebut sebagai Metodologi Information Engineering (IE Methodology) yaitu Dr.

James Martin (Inggris) dan Dr. Clive Finklestein (Australia). Notasi IE ini merupakan pengembangan

dari ide notasi Crow’s Foot yang dibuat oleh Dr. Gordon Everest (Amerika Serikat) dalam tulisan

ilmiahnya yang berjudul “Basic Data Structure Models Explained with Common Example”, pada

tahun 1976. Pada ERD dengan notasi IE maka setiap himpunan relationship maksimal hanya

menghubungkan 2 himpunan entitas (himpunan relationship yang diizinkan hanya unary dan binary

relation set). Tabel 6.4. berikut adalah sebagian dari simbol-simbol yang digunakan pada notasi

Information Engeneering beserta varian-variannya.

Tabel 6.4. Simbol-simbol Dasar dari ERD dengan Notasi Information Engineering


Himpunan Entitas

Himpunan Entitas

Contoh – contoh varian Simbol Himpunan Entitas beserta atribut pada himpunan entitas di berbagai varian penggambaran ERD dengan notasi Information Engineering :

Himpunan Entitas

Atau :

Himpunan Entitas

atribut_kunci_primer atribut_sederhana {atribut_multi_nilai } atribut_turunan ()

Atau :

Himpunan Entitas

PK atribut_primer

FK

Atribut_sederhana Atribut_sederhana

Himpunan Entitas Komposit

(Associative Entity)

PK,FK1 PK,FK2

atribut_primer atribut_primer

Atribut_sederhana


Text daftar nama atribut dari himpunan entitas diletakkan di bagian persegi panjang bawah di simbol himpunan entitas

Ketelitian dari penulisan atribut dan jenis-jenis tipe data dari atribut akan bergantung pada kebutuhan dari pengguna dan perangkat lunak yang dipakai untuk menggambar ERD. Secara umum adalah :

jika ERD masih merupakan model konseptual maka atribut tidak perlu dijelaskan secara rinci (less detail)

jika ERD sudah condong ke model logis (Logical Model) maka perlu ditambahkan batasan-batasan seperti Primary Key, Foreign Key dan sebagainya

Lanjutan Tabel 6.4. Simbol-simbol Dasar Notasi ERD dengan Notasi Information Engineering



Himpunan Relationship ( Non Identifying

Relationship )

Menghubungkan antara Entitas-entitas kuat

Identifying Relationship

Menghubungkan antara Entitas Kuat dengan entitas lemah

Menghubungkan antara entitas kuat dengan associative entity atau composite entity (entitas komposit)

Associative Entity (Composite Entity)

Menggunakan simbol himpunan entitas.

Jika ERD yang dibutuhkan masih berupa model konseptual yang tidak terlalu rinci maka associative entity tidak perlu digambarkan

Jika ERD yang dibutuhkan sudah merupakan ERD yang bersifat rinci, maka seluruh Himpunan Relationship many to many harus ditransformasi ke bentuk 2 himpunan relationship one to many dan menambahkan associative entity (tabel asosiatif)

Himpunan Entitas Komposit

(Associative Entity)

PK,FK1 PK,FK2

atribut_primer atribut_primer

Atribut_sederhana

Batasan Partisipasi dan

Rasio Kardinalitasi

Pada notasi Information Engineering, baik batasan partisipasi maupun rasio kardinalitas akan diletakkan diseberang dari entitas yang sedang ditinjau (look accross)

Simbol fork (garpu) atau cakar menunjukkan kardinalitas Banyak

Simbol | menunjukkan 1

Simbol 0 menunjukkan 0

Format yang digunakan adalah : (Partisipasi .. Kardinalitas) atau (Min .. Max)

Urutan yang digunakan adalah kardinalitas menempel pada entitas, sedangkan partisipasi berada dibelakang kardinalitas (tidak menempel pada entitas)

(1..1)

(1..N)

(0..N)

(0..1)


Contoh Soal 6.7. Tentukan gambar diagram ERD dengan notasi Crow’s Foot atau IE, jika diketahui pada ERD tersebut:







Jawab : Urutan penggambaran Diagram ERD dengan notasi IE yang diperoleh dengan batasan-batasan sistem diatas adalah :


2. Gambarkan himpunan relationship (Karena kedua himpunan entitas adalah himpunan entitas kuat, maka himpunan relationship diantara kedua himpunan tersebut adalah Non Identifying Relationship (garis putus-putus)

3. Gambarkan Kardinalitas dan Batasan Partisipasi

Batasan Partisipasi dan Kardinalitas dari Himpunan entitas customer adalah (0..N) karena

Jumlah maksimum entitas loan yang dapat dihubungkan ke 1 entitas customer jika ditinjau dari entitas customer adalah banyak (N)

Batasan Partisipasi : partial = 0

customer

customer_id customer_name customer_street customer_city

loan

loan_number amount

customer


loan

loan_number amount

loan

loan_number amount


Batasan Partisipasi dan Kardinalitas dari himpunan entitas loan adalah (1..N) karena

Jumlah maksimum entitas customer yang dapat dihubungkan ke 1 entitas loan jika ditinjau dari entitas loan adalah banyak (N)

Batasan Partisipasi : total = 1

4. Hasil akhir dari diagram ERD

jika ERD yang diinginkan mewajibkan penggunaan simbol associative entity untuk himpunan relationship many to many maka :

Hasil akhir dari diagram ERD adalah :

Jika ERD yang diinginkan adalah diagram ERD yang lebih condong ke model logis (more detail) , maka:

Hasil akhir dari diagram ERD adalah :

borrower

PK,FK1 customer_id PK,FK2 loan_number

customer

PK customer_id customer_name customer_street customer_city

PK loan_number amount

loan

customer


loan

loan_number amount

borrower

loan_number customer_id

customer


loan

loan_number amount

customer


loan

loan_number amount

(0..N)

(1..N)

Look accross

Look accross


6.6.4. Notasi Barker’s

Notasi ERD Barker’s dibuat oleh Richard Barker, Ian Palmer dan Harry Ellis pada saat ketiganya

bekerja sebagai konsultan dan praktisi analis sistem di CACI (Consolidated Analysis Center

Incorporated) pada tahun 1981. Notasi ERD Barker’s menjadi sangat terkenal dan digunakan secara

luas setelah Mr. Richard Barker menggunakan notasinya ini saat bergabung dengan ORACLE. Pada

saat bekerja di ORACLE, Mr. Richard Barker adalah anggota Main Board Director Oracle Corporation

UK Limited sekaligus sebagai Vice President dari ORACLE di wilayah Eropa. Mr. Richard Barker

bertanggung jawab terhadap Metode Pengembangan Sistem berbasis ORACLE, CASE(Computer

Aided Systems Engineering)* METHOD dan Paket Aplikasi Perangkat Lunak (Application Package

Software) yang menggunakan RDBMS ORACLE. Sampai saat ini ORACLE masih menggunakan Notasi

Barker’s sebagai notasi utama ERD pada perangkat lunak SQL Developer dan Data Modeller dari

ORACLE, dimana pada perangkat lunak tersebut, selain notasi utama yaitu notasi Barker’s, ORACLE

juga menyediakan penggunaan notasi ERD lain sebagai pendamping yaitu Notasi ERD Bachman dan

Notasi ERD Information Engineering.

Tabel 6.5. berikut adalah sebagian dari simbol-simbol yang digunakan notasi Barker’s seperti

yang ada dalam buku Richard Barker yaitu “CASE* METHODTM Entity Relationship Modelling”,

Addison Wesley Publishing, Oracle Corporation-UK Limited, 1990. Selain menggunakan acuan buku

dari Mr. Richard Barker tersebut, simbol-simbol yang digunakan juga akan didasarkan pada simbol-

simbol ERD yang digunakan di perangkat lunak Oracle SQL Developer – Data Modeller versi

19.4.0.350, tahun 2019.

Tabel 6.5. Simbol-simbol Dasar dari ERD dengan Notasi Barker’s Information Engineering


Himpunan Entitas

Pada Notasi Barker’s nama himpunan entitas harus ditulis dengan huruf kapital dan berbentuk singular (tunggal)

Contoh - contoh :

ENTITY NAME




Atribut diletakkan dan ditulis dalam simbol himpunan entitas

Jika model masih berupa konsep, atribut dapat disembunyikan (tidak ditampilkan)

Jika model sudah condong ke model logis (more detail) maka dapat ditambahkan informasi seperti : atribut kunci didahului

oleh simbol # Simbol * didepan atribut

menyatakan atribut bersifat mandatory (tidak boleh bernilai NULL)

Simbol ⁰ didepan atribut menyatakan atribut dapat bernilai NULL.

atau

(style : default dari SQL DEVELOPER –

DATA MODELLER)

Business Relationship (Himpunan

Relationship) dengan Batasan Partisipasi

Optional (Optional Relationship

Set)

Menunjukkan bahwa keikut sertaan dari anggota himpunan entitas yang ditinjau dalam suatu himpunan relationship adalah bersifat partial Catatan: Simbol diletakkan disisi yang sama dengan himpunan entitas yang sedang ditinjau. (look here) , dimana panjang garis hanya setengah dari jarak antar entitas

Business Relationship (Himpunan

Relationship) dengan Batasan Partisipasi

Wajib (Mandatory /Full /

Total)

Menunjukkan bahwa keikut sertaan dari anggota himpunan entitas yang ditinjau dalam suatu himpunan relationship adalah bersifat wajib (Total/Full) Catatan: Simbol diletakkan disisi yang sama dengan himpunan entitas yang sedang ditinjau. (look here) , dimana panjang garis hanya setengah dari jarak antar entitas

ACCOUNT


Nama Komponen

Kardinalitas

Business Relationship (Himpunan Relationship)

Pada Notasi ERD Barker’s terdapat istilah

Barker’s tidak lain adalah Himpunan Relationship,

“CASE* METHOD Entity Relationship Model

seperti tampak pada gambar 6.12.a. berikut ini :

Gambar 6.12. Definisi Business Relationship dan contohnya menurut Rich METHOD Entity Relationship Modelling”, 1990) Dari definisi diatas dapat disimpulkan bahwa Business Relationship adalah istilah Himpunan

Relationship yang diberikan oleh Mr. Richard Barker, dimana pa

relationship yang diizinkan adalah

Relationship Set), seperti dicontohkan pada gambar 6.13 sebagai berikut :

Diktat Basis Data

Bentuk Simbol Penjelasan

(Banyak / Many / N)

(Satu / One / 1 )

Pada notasi Barker’s : Simbol fork menunjukkan

kardinalitas Banyak Garis tunggal (Single line)

menunjukkan

Simbol diletakkan di seberang himpunan entitas yang sedang ditinjau (look across

(Himpunan Relationship)

Pada Notasi ERD Barker’s terdapat istilah Business Relationship. Business Relationship

Himpunan Relationship, dimana berdasarkan buku Mr. Richard Barker,

CASE* METHOD Entity Relationship Modelling”,1990, maka definisi business r

seperti tampak pada gambar 6.12.a. berikut ini :

(a) Definisi Business Relationship

(b) Contoh Business Relationship

Definisi Business Relationship dan contohnya menurut Richard Barker (“CASE* METHOD Entity Relationship Modelling”, 1990)

Dari definisi diatas dapat disimpulkan bahwa Business Relationship adalah istilah Himpunan

Relationship yang diberikan oleh Mr. Richard Barker, dimana pada notasi Barker’s, maka Himpunan

relationship yang diizinkan adalah Binary Relationship set dan Recursive relatio

Relationship Set), seperti dicontohkan pada gambar 6.13 sebagai berikut :

126

Penjelasan

Barker’s : Simbol fork menunjukkan kardinalitas Banyak Garis tunggal (Single line) menunjukkan kardinalitas 1

Simbol diletakkan di seberang himpunan entitas yang sedang

look across)

Business Relationship pada notasi

buku Mr. Richard Barker,

business relationship adalah

ard Barker (“CASE*

Dari definisi diatas dapat disimpulkan bahwa Business Relationship adalah istilah Himpunan

da notasi Barker’s, maka Himpunan

Recursive relationship set (Unary


(b) Contoh Recursive

Gambar 6.13. Contoh – contoh Business Relationship yang valid dan paling umum digunakan pada ERD dengan notasi Barker’s (“

Gambar 6.14. berikut adalah aturan sintaksis yang diberikan oleh Mr. Richard Barker untuk

membaca himpunan relationship atau

himpunan entitas A dan B

Gambar 6.14. Aturan Sintaksis untuk membaca d dianjurkan oleh Mr. Richard pada (“ 1990)

Diktat Basis Data

(a) Contoh Binary Relationship

Recursive Relationship Set (unary relationship set

contoh Business Relationship yang valid dan paling umum digunakan pada ERD dengan notasi Barker’s (“CASE* METHOD Entity Relationship Modelling

mbar 6.14. berikut adalah aturan sintaksis yang diberikan oleh Mr. Richard Barker untuk

membaca himpunan relationship atau business relationship antara 2 himpunan entitas yaitu

Aturan Sintaksis untuk membaca dan menyatakan business relationshipdianjurkan oleh Mr. Richard pada (“CASE* METHOD Entity Relationship Modelling

127

unary relationship set)

contoh Business Relationship yang valid dan paling umum digunakan pada CASE* METHOD Entity Relationship Modelling”, 1990)

mbar 6.14. berikut adalah aturan sintaksis yang diberikan oleh Mr. Richard Barker untuk

antara 2 himpunan entitas yaitu

elationship yang CASE* METHOD Entity Relationship Modelling”,


Dengan menggunakan aturan sintaksis pada gambar 6.14 maka dapat disimpulkan aturan sintaksis

yang dianjurkan oleh Mr. Richard Barker adalah :

Untuk menyatakan batasan partisipasi, maka :

o digunakan kata must be atau harus, jika himpunan relationship atau business relationship

memiliki batasan partisipasi wajib (full/total/mandatory)

o digunakan kata may be atau mungkin untuk menyatakan himpunan relationship atau

business relationship yang memiliki batasan partisipasi partial (optional)

Untuk menyatakan batasan kardinalitas, maka :

o digunakan kata one and only one atau satu dan hanya satu , jika kardinalitas adalah 1

(satu)

o digunakan kata one or more atau satu atau lebih , jika kardinalitas adalah banyak

(many).

Contoh Soal 6.8. Tentukan gambar diagram ERD dengan notasi Barker’s, jika diketahui pada ERD tersebut:







Jawab : Untuk Notasi Barker’s maka nama himpunan entitas harus menggunakan huruf kapital sehingga penulisan :

Himpunan entitas customer dirubah menjadi CUSTOMER

Himpunan entitas loan dirubah menjadi LOAN

Himpunan entitas asosiatif borrower dirubah menjadi BORROWER Urutan penggambaran Diagram ERD dengan notasi Barker’s yang diperoleh dengan batasan-batasan sistem diatas adalah :


CUSTOMER #*customer_id *customer_name ocustomer_street ocustomer_city

LOAN #*loan_number *amount


2. Gambarkan himpunan relationship dan batasan partisipasi

Batasan Partisipasi jika ditinjau dari CUSTOMER : partial (Optional) : garis putus – putus setengah jarak antar entitas (look here)

Batasan Partisipasi jika ditinjau dari LOAN : wajib (full / total) : garis penuh (solid line) setengah jarak antar entitas (look here)

3. Gambarkan Kardinalitas

Jumlah maksimum entitas LOAN yang dapat dihubungkan ke 1 entitas CUSTOMER jika ditinjau dari entitas CUSTOMER adalah banyak (N) – simbol Fork

Jumlah maksimum entitas CUSTOMER yang dapat dihubungkan ke 1 entitas LOAN jika ditinjau dari entitas LOAN adalah banyak (N) – simbol Fork

4. Hasil akhir dari diagram ERD (Hasil Langkah 2 digabung dengan hasil langkah 3)



(N)

(N)

Look accross LOAN #*loan_number *amount


Look accross



Partial (optional)

wajib (Total)

look here look here


Atau setelah disamakan warnanya :

Hasil akhir dari diagram ERD adalah : (dengan menambahkan end-name)

Uraian Fakta dunia nyata :

Setiap CUSTOMER dapat memiliki 0 atau lebih LOAN dan setiap LOAN diberikan pada 1 atau lebih CUSTOMER

Business Relationship (versi Notasi Barker’s) :

Dalam Bahasa Inggris : EACH CUSTOMER may have one or more LOANs AND EACH LOAN must be given to one or more CUSTOMERs

Dalam Bahasa Indonesia : SETIAP CUSTOMER mungkin memiliki satu atau lebih LOAN DAN SETIAP LOAN harus diberikan pada satu atau lebih CUSTOMER (Dalam bahasa Indonesia)

Jika ERD yang diinginkan adalah ERD dengan Himpunan Relationship set yang tidak menyertakan hubungan dengan derajat kardinalitas Many to Many, maka ERD diatas dapat diubah dengan memasukan associative entity BORROWER sebagai berikut :

Uraian Fakta dunia nyata :

Setiap CUSTOMER dapat menjadi 0 atau lebih BORROWER dan setiap BORROWER adalah seorang (1) CUSTOMER

Setiap BORROWER dapat memiliki 1 LOAN dan setiap LOAN dapat diberikan pada 1 atau lebih BORROWER

CUSTOMER #*customer_id *customer_name

ocustomer_street

ocustomer_city

BORROWER

act as given to LOAN #*loan_number *amount

have be


LOAN #*account_number *amount

have

given to


Business Relationship (versi Notasi Barker’s) :

Business relationship antara CUSTOMER dengan BORROWERo EACH CUSTOMER may

A CUSTOMER Dalam Bahasa Indonesia :SETIAP CUSTOMER BORROWER harus

Business relationship antara BORROWER dengan LOAN o EACH BORROWER must

to one or more CUSTOMERDalam Bahasa Indonesia :SETIAP BORROWER diberikan pada satu

SubType dan SuperType (Spesialisasi dan Generalisasi)

Pada notasi Barker, adanya

dengan menggambarkan simbol himpunan entitas

menjadi super type dari simbol himpunan entitas tersebut.

Gambar 6.14. berikut menunjukkan contoh

ERD yang digambarkan dengan menggunakan notasi ERD Barker’s

(a)

(b) Contoh ERD dengan SubType dan SuperType Entity

Gambar 6.15. Contoh SubType dan SuperType pada Notasi Barker’s (“ Relationship Modelling

Diktat Basis Data

(versi Notasi Barker’s) :

antara CUSTOMER dengan BORROWER may act as one or more BORROWERs AND EACH BORROWER

Dalam Bahasa Indonesia : SETIAP CUSTOMER mungkin menjadi satu atau lebih BORROWER

merupakan seorang CUSTOMER

Business relationship antara BORROWER dengan LOAN must have one and only one LOAN AND EACH LOAN

CUSTOMERs Dalam Bahasa Indonesia : SETIAP BORROWER harus memiliki satu dan hanya satu LOAN DAN diberikan pada satu atau lebih CUSTOMER

SubType dan SuperType (Spesialisasi dan Generalisasi)

adanya Sub Type dan SuperType pada suatu himpunan entitas

barkan simbol himpunan entitas didalam simbol himpunan entitas lain yang

menjadi super type dari simbol himpunan entitas tersebut.

Gambar 6.14. berikut menunjukkan contoh-contoh adanya sub type dan super type pada suatu

ERD yang digambarkan dengan menggunakan notasi ERD Barker’s

(a) Contoh SubType dan SuperType Entity

Contoh ERD dengan SubType dan SuperType Entity

Contoh SubType dan SuperType pada Notasi Barker’s (“CASE*METHOD EntityRelationship Modelling”, 1990)

131

BORROWER must be

BORROWER DAN SETIAP

EACH LOAN must be given

DAN SETIAP LOAN harus

pada suatu himpunan entitas ditunjukkan

am simbol himpunan entitas lain yang

contoh adanya sub type dan super type pada suatu

CASE*METHOD Entity


Mr. Richard Barker juga menganjurkan cara untuk menyatakan atau membaca supertype dan

subtype dalam bahasa inggris, dimana aturan pembacaan sub type dan super type adalah sebagai

berikut :

Untuk membaca supertype entity maka digunakan frasa “which must be either a

subtype_1, subtype_2, … OR … ”.

o Contoh untuk gambar 6.15 a diatas, untuk membaca supertype FLIGHT dapat

digunakan frasa sebagai berikut :

… FLIGHT, which must be either a NON-SCHEDULED FLIGHT OR SCHEDULED FLIGHT …

Untuk membaca subtype entity maka digunakan frasa “which is a type of ….

(supertype)”

o Contoh untuk gambar 6.15 a diatas, untuk membaca subtype NON-SCHEDULED

FLIGHT digunakan frasa sebagai berikut :

… NON-SCHEDULED FLIGHT, which is a type of FLIGHT

Hubungan antara sub-type dengan sub-type lain dalam suatu super type harus bersifat mutually

exclusive. Selain dari sifat mutually exclusive antar subtype, subtype juga memiliki atribut sendiri dan

menerima pewarisan atribut dari supertype atau supertype akan mewariskan (inherit) atribut-

atributnya ke subtype. Contoh lain dari penggunaan sub type dan supertype dapat dilihat pada

gambar 6.16. sebagai berikut.

Gambar 6.16. Contoh Subtype dan Supertype di ERD dengan notasi Barker’s (“Database Design –

Instructor Guide”, Oracle, 2004)


Exclusive Relationship

Pada notasi Barker, dimungkinkan suatu ERD memiliki himpunan

relationship) yang disebut sebagai

di ERD jika terjadi situasi dimana terdapat 2 atau lebih pilih

boleh dipilih salah satunya saja

terlibat pada exclusive relationship tersebut.

Exclusive Relationship pada notasi Barker ditunjukkan dengan menggunakan simbo

lengkung) yang akan menghubungkan beberapa himpunan relationship yang membentuk exclusive

relationship tersebut.

Gambar dan aturan sintaksis yang diberikan oleh Mr. Richard Barker tentang

relationship tersebut dapat dilihat pada ERD

(a) Simbol Arc untuk menunjukkan

(b) Aturan sintaksis pembacaan

Gambar 6.17. Exclusive Relationship (“CASE*METHOD Entity Relationship Modelling”, 1990)

Contoh penggunaan exclusive relationship dan

sebagai berikut :

Diktat Basis Data

Pada notasi Barker, dimungkinkan suatu ERD memiliki himpunan relationship

) yang disebut sebagai exclusive relationship. Exclusive Relationship

di ERD jika terjadi situasi dimana terdapat 2 atau lebih pilihan himpunan relationship

boleh dipilih salah satunya saja (logika XOR) oleh setiap anggota dari himpunan entitas yang

terlibat pada exclusive relationship tersebut.

pada notasi Barker ditunjukkan dengan menggunakan simbo


dan aturan sintaksis yang diberikan oleh Mr. Richard Barker tentang

dapat dilihat pada ERD dibawah ini :

Simbol Arc untuk menunjukkan Exclusive Relationship

Aturan sintaksis pembacaan Exclusive Relationship

Exclusive Relationship (“CASE*METHOD Entity Relationship Modelling”, 1990)

Contoh penggunaan exclusive relationship dan pembacaannya dapat dilihat pada gambar 6.18.

133

relationship (business

Exclusive Relationship perlu digambarkan

an himpunan relationship yang hanya

(logika XOR) oleh setiap anggota dari himpunan entitas yang

pada notasi Barker ditunjukkan dengan menggunakan simbol arc (garis


dan aturan sintaksis yang diberikan oleh Mr. Richard Barker tentang exclusive

Exclusive Relationship (“CASE*METHOD Entity Relationship Modelling”, 1990)

pembacaannya dapat dilihat pada gambar 6.18.


(a) Contoh ERD dengan exclusive relationship

(b) Pembacaan Contoh ERD pada gambar (a)

Gambar 6.18. Contoh Penggunaan dan Pembacaan exclusive relationship pada ERD dengan Notasi Barker’s (“CASE*METHOD Entity Relationship Modelling”, 1990)

Transferable Relationship dan Non Transferable Relationship

Jika ERD yang dibuat adalah ERD yang sudah condong kearah model yang bersifat logis, maka

salah satu karakteristik yang dapat

relationship (business relationship) adalah dengan membagi

relationship) menjadi business relationship yang

bersifat Non Transferable.

Suatu himpunan relationship disebut Non

relationship tersebut, jika suatu anggota relationship sudah dibuat maka relationship tersebut tidak

dapat dirubah. Untuk menunjukkan adan

maka pada notasi ERD Barker’s digunakan simbol

Gambar 6.19 menunjukkan

transferable (Gambar 6.19. a) dan contoh himpunan relationship yang termasuk Non

(Gambar 6.19b).

Gambar 6.19.

PERSON

GUEST

Diktat Basis Data

Contoh ERD dengan exclusive relationship

Pembacaan Contoh ERD pada gambar (a)

Contoh Penggunaan dan Pembacaan exclusive relationship pada ERD dengan Notasi Barker’s (“CASE*METHOD Entity Relationship Modelling”, 1990)

Transferable Relationship dan Non Transferable Relationship


dapat ditambahkan pada ERD tersebut, khususnya pada himpunan

(business relationship) adalah dengan membagi setiap himpunan relationship (business

menjadi business relationship yang bersifat transferable dan business relationship

Suatu himpunan relationship disebut Non-Transferable Relationship bilamana pada himpunan

, jika suatu anggota relationship sudah dibuat maka relationship tersebut tidak

dapat dirubah. Untuk menunjukkan adanya himpunan relationship yang bersifat Non

rker’s digunakan simbol pada sisi himpunan relationship

Gambar 6.19 menunjukkan perbedaan antara contoh himpunan relationship yang term

transferable (Gambar 6.19. a) dan contoh himpunan relationship yang termasuk Non

(a) Transferable Relationship

(b) Non-Transferable Relationship

Contoh Transferable dan Non Transferable Relationship

TOWNbirthplace of

ROOMstay in

house

born in

134

Contoh Penggunaan dan Pembacaan exclusive relationship pada ERD dengan Notasi


ditambahkan pada ERD tersebut, khususnya pada himpunan

mpunan relationship (business

bersifat transferable dan business relationship yang

Transferable Relationship bilamana pada himpunan

, jika suatu anggota relationship sudah dibuat maka relationship tersebut tidak

ya himpunan relationship yang bersifat Non-Transferable

relationship yang sesuai.

perbedaan antara contoh himpunan relationship yang termasuk

transferable (Gambar 6.19. a) dan contoh himpunan relationship yang termasuk Non-Transferable

ansferable dan Non Transferable Relationship

TOWN

ROOM


Gambar 6.20 dibawah ini menunjukkan contoh penggunaan dan pembacaan transferable dan

non transferable relationship yang diberikan oleh Mr. Richard Barker di bukunya “CASE*METHOD

Entity Relationship Modelling”,19

Gambar 6.20. Contoh Penggunaan Transferable dan Non Transferable Relationship (“CASE*METHOD Entity Relationship Modelling”, 1990)

6.6.5. Notasi-Notasi ERD yang Lain

Selain dari notasi-notasi ERD yang sudah dijelaskan diata

Sudarshan), Notasi Chen, Notasi Information Engineering dan Notasi Barker’s, masih terdapat notasi

notasi lain yang juga umum digunakan dalam ERD. Notasi

Bachman yang dibuat oleh Charles William Bachman III, notasi Universal Modelling Language

notasi IDEF1X dan sebagainya.

Untuk notasi ERD IDEF1X (Integration DEFinition For Information Modelling)

notasi yang dibuat oleh US Air Force

ICAM (Integrated Computer Aided Manufacturing). IDEF pada awalnya adalah singkatan dari

DEFinition” tetapi saat ini lebih dikenal sebagai “

mengembangkan 3 bahasa pemodel

Relational Databases”,Terry Halpin and Tony Morgan,

IDEF0 : activity Modelling

IDEF1 : conceptual data Modelling

IDEF2 : Simulation Modelling

Selanjutnya seiring dengan perkembangan

menjadi beberapa bahasa pemodelan seperti :

Databases”,Terry Halpin and Tony Morgan,

IDEF1X : logical data modelling

IDEF1X yang saat ini lebih dikenal sebagai “

sebenarnya diperoleh dari singkatan IDEF1X (“IDEF1 eXtended”) karena bahasa ini adalah

pengembangan dan perluasan dari IDEF1 yang sudah dibuat sebel

IDEF1X digunakan untuk mengganti IDEF1.

Diktat Basis Data



Entity Relationship Modelling”,1990.

Contoh Penggunaan Transferable dan Non Transferable Relationship (“CASE*METHODEntity Relationship Modelling”, 1990)

ERD yang Lain

notasi ERD yang sudah dijelaskan diatas (Notasi Silberschatz

Sudarshan), Notasi Chen, Notasi Information Engineering dan Notasi Barker’s, masih terdapat notasi

notasi lain yang juga umum digunakan dalam ERD. Notasi – Notasi tersebut antara lain adalah notasi

les William Bachman III, notasi Universal Modelling Language

(Integration DEFinition For Information Modelling)

notasi yang dibuat oleh US Air Force pada era 1970-an sebagai bagian dari program yang disebut

ICAM (Integrated Computer Aided Manufacturing). IDEF pada awalnya adalah singkatan dari

tetapi saat ini lebih dikenal sebagai “Integration DEFinition”. Pada awalnya proyek ICAM

pemodelan (Modelling Language) yaitu : (“Information Modelling and

”,Terry Halpin and Tony Morgan, Morgan Kaufmann Publisher Inc

IDEF0 : activity Modelling

IDEF1 : conceptual data Modelling

IDEF2 : Simulation Modelling

iring dengan perkembangan, bahasa-bahasa pemodelan IDEF diatas dikembangkan

menjadi beberapa bahasa pemodelan seperti : (“Information Modelling and Relational

”,Terry Halpin and Tony Morgan, Morgan Kaufmann Publisher Inc., 2001

ata modelling

yang saat ini lebih dikenal sebagai “Integration DEFinition For Information Modelling


pengembangan dan perluasan dari IDEF1 yang sudah dibuat sebel

IDEF1X digunakan untuk mengganti IDEF1.

135



Contoh Penggunaan Transferable dan Non Transferable Relationship (“CASE*METHOD

s (Notasi Silberschatz-Korth-

Sudarshan), Notasi Chen, Notasi Information Engineering dan Notasi Barker’s, masih terdapat notasi-

Notasi tersebut antara lain adalah notasi

les William Bachman III, notasi Universal Modelling Language (UML),

(Integration DEFinition For Information Modelling), notasi ini adalah

program yang disebut

ICAM (Integrated Computer Aided Manufacturing). IDEF pada awalnya adalah singkatan dari “ICAM

”. Pada awalnya proyek ICAM

Information Modelling and

Morgan Kaufmann Publisher Inc., 2001)

diatas dikembangkan

Information Modelling and Relational

., 2001)

Integration DEFinition For Information Modelling”


pengembangan dan perluasan dari IDEF1 yang sudah dibuat sebelumnya. Selanjutnya


IDEF3 : process modelling

IDEF4 : object oriented modelling

IDEF5 : knowledge engineering of enterprise ontologies

IDEF1X97 : logical data modelling with object oriented extensions

6.7. Diagram Drawing Tools dan Data Modeler Tools

Terdapat 2 jenis perangkat lunak atau kakas yang dapat digunakan untuk menggambar Entity

Relation Diagram (ERD) sebagai hasil dari pemodelan konseptual yang telah dilakukan. Kedua jenis

perangkat lunak ini adalah :

Diagram Drawing Tools

Diagram Drawing Tools adalah suatu jenis perangkat lunak atau kakas yang menyediakan

berbagai jenis obyek-obyek diagram yang dapat digunakan oleh penggunanya. Jenis-jenis obyek atau

simbol diagram yang disediakan oleh kakas ini akan dibagi berdasarkan jenis-jenis diagram yang

didukung oleh kakas ini. Untuk jenis diagram ERD maka obyek-obyek diagram yang umumnya

disediakan dan akan digunakan oleh pengguna kakas ini adalah simbol himpunan entitas, simbol

himpunan relationship, simbol atribut, berbagai jenis obyek garis penghubung dan obyek text/label.

Salah satu contoh perangkat lunak diagram drawing tools yang tersedia dan dapat diperoleh

dengan lisensi GNU General Public adalah perangkat lunak yang diberi nama DIA Diagram Editor

(http://live.gnome.org/Dia dan http://dia-installer.de/ ). DIA Diagram Editor dibuat oleh Alexander

Larsson, Steffen Macke, Hans Breuer, Lars Clausen, et al.

Pada DIA Diagram Editor maka obyek utama yang menjadi tempat dari diagram yang dibuat

disebut sebagai obyek canvas. Gambar 6.21. menunjukkan contoh canvas pada DIA Diagram Editor.

Gambar 6.21. Canvas Pada DIA Diagram Editor.

Obyek-obyek diagram yang akan diletakkan pada obyek canvas DIA Diagram Editor disebut

sebagai obyek shape, sedangkan window yang digunakan untuk menampilkan icon dari obyek-obyek

shape tersebut disebut DIA Toolbox. Gambar 6.22. menunjukkan tampilan dari DIA Toolbox.


Gambar 6.22. DIA Toolbox.

Dari gambar 6.22. diatas dapat dilihat bahwa bbyek-obyek shape pada DIA Toolbox akan dibagi menjadi 2 kelompok, yaitu :

a. Obyek Dasar (Basic Object) Yang termasuk obyek dasar adalah Obyek Text, Box, Ellipse, Polygon, Beziergon, Line, Arc, Zigzagline, Polyline, Bezierline, Image dan Outline

b. Obyek Khusus (Special Object) Obyek – obyek yang merupakan simbol khusus dan dikelompokkan sesuai dengan notasi diagram.

Walaupun DIA Diagram Editor sudah menyediakan banyak obyek shape khusus (special object), tetapi pengguna masih dapat menambahkan dan membuat obyek shape sendiri yang disebut sebagai custom shape module. Untuk membuat custom shape module maka pengguna dapat merancang simbol yang dikustomisasi tersebut dan menyimpannya dalam bentuk file XML. File XML ini akan diberi tipe .shape (memiliki extension .shape) dan akan berisi data gambar simbol tersebut dalam bentuk spesifikasi SVG (Scalable Vector Graphics). Gambar 6.23. dibawah ini menunjukkan contoh file .shape dari suatu obyek shape dan tampilan dari obyek shape tersebut pada DIA Diagram Editor. <?xml version="1.0" encoding="UTF-8"?> <shape xmlns="http://www.daa.com.au/~james/dia-shape-ns" xmlns:svg="http://www.w3.org/2000/svg"> <name>Pictures - Diagram2</name> <icon>Diagram2.png</icon> <connections> <point x="2.65" y="4.35"/> <point x="8.85" y="8.2"/> <point x="2.65" y="8.2"/> <point x="2.65" y="6.275"/> <point x="8.85" y="4.35"/> <point x="8.85" y="6.275"/> <point x="5.75" y="8.2"/> <point x="5.75" y="4.35"/> </connections> <aspectratio type="fixed"/> <svg:svg> <svg:rect style="fill: #ffffff" x="2.65" y="4.35" width="6.2" height="3.85"/> <svg:rect style="fill: none; fill-opacity:0; stroke-width: 0.15; stroke: #000000" x="2.65" y="4.35" width="6.2" height="3.85"/> </svg:svg> </shape>

Gambar 6.23. Contoh Berkas XML dari Custom DIA Shape dan tampilan dari custom DIA Shape tersebut

Basic Object

Special Object


Untuk menggambar diagram pada DIA Diagram Editor, maka pengguna hanya perlu memilih obyek-

obyek shape yang diinginkan dan menempatkan pada obyek canvas. Gambar 6.24 berikut

menunjukkan tampilan DIA Diagram Editor pada saat digunakan untuk menggambar suatu ERD.

Gambar 6.24. Tampilan Dia Diagram Editor

Data Modeler Tools

Data Modeler Tools adalah suatu perangkat lunak pemodelan data dan perancangan basis data

yang menyediakan lingkungan untuk mendapatkan, memodelkan, mengelola dan mengekspoitasi

metadata. Data modeler tools berbeda dengan perangkat diagram drawing tools yang hanya

digunakan untuk menggambar simbol-simbol diagram saja. Pada perangkat lunak data modeler,

maka pemodelan dan analisis model basis data dapat dilakukan dengan lebih rinci.

Saat ini sudah tersedia banyak perangkat data modeler, salah satunya adalah Oracle SQL Developer

Data Modeler. Perangkat lunak Oracle SQL Developer Data Modeler memiliki lisensi Free tetapi hak

cipta perangkat lunak ini sepenuhnya adalah milik dari Oracle Corp. Perangkat lunak ini dapat

diperoleh dari website resmi Oracle (https://www.oracle.com/tools/downloads/sql-data-modeler-

downloads.html) dengan terlebih dahulu membuat akun Oracle yang juga bersifat free. Perangkat

lunak Oracle SQL Developer Data Modeler ini dapat digunakan untuk melakukan pemodelan data

dengan 3 pendekatan, yaitu :

1. Top Down Modeling (Forward Engineering)

Pendekatan ini digunakan untuk membuat basis data yang baru (New Database). Pada

pendekatan ini data modeler akan digunakan mulai dari tahapan pengumpulan informasi

tentang kebutuhan (Business requirements), pengembangan model proses (business

function) – data flow diagram, pengembangan model konseptual / logis - ERD,


pengembangan model multidimensional, pengembangan model relasional dan

pengembangan model fisik – DDL Statement.

2. Bottom Up Modeling (Reverse Engineering dilanjutkan dengan Forward Engineering)

Pendekatan ini digunakan, jika pembuatan basis data yang baru (New Database) akan

didasarkan pada basis data yang sudah ada secara fisik (atau dari DDL yang

mengimplementasikan basis data tersebut). Pada pendekatan ini data modeler dapat

digunakan untuk melakukan reverse engineering dari basis data yang sudah ada kembali ke

bentuk model konseptual / logis dari basis data yang sudah ada tersebut. Pengembang Basis

data dapat memodifikasi model konseptual hasil reverse engineering. Tahap berikutnya

adalah data modeler akan kembali digunakan untuk menciptakan model relational dan DDL

statement dari basis data yang baru berdasarkan modifikasi yang telah dilakukan.

3. Targeted Modeling (Reverse Engineering kemudian dilanjutkan dengan Forward

Engineering)

Pendekatan pemodelan dengan pendekatan targeted modeling umumnya digunakan untuk

merawat basis data yang sudah ada dan digunakan agar tetap sesuai dengan kebutuhan dari

penggunanya. Perbaikan yang bisa dilakukan antara lain dengan menambah himpunan

entitas, himpunan relationship yang baru, atribut-atribut tambahan dan sebagainya.

Untuk Oracle SQL Developer Data Modeler, notasi ERD yang dapat digunakan untuk membuat

model konseptual dan model logis dari suatu sistem adalah dengan notasi Barker, notasi Bachman

dan notasi Information Engineering.

Gambar 6.25. berikut adalah tampilan Oracle SQL Developer Data Modeler pada saat digunakan

untuk memodelkan sistem dengan Entity Relationship Model.

Gambar 6.25. Tampilan Oracle SQL Developer Data Modeler untuk Contoh ERD yang dibuat

Gambar 6.26. dibawah ini adalah hasil forward engineering berupa model relasional yang dibuat

oleh Oracle SQL dari model ERD pada gambar 6.25.


Gambar 6.26. Tampilan Model Relasional hasil forward engineering dari Oracle SQL Developer

Data Modeler untuk Contoh ERD yang dibuat

Gambar 6.27. dibawah ini adalah hasil forward engineering berupa DDL Statement yang dibuat

oleh Oracle SQL Developer Data Modeler dari model relasional pada gambar 6.26. Untuk contoh

pada gambar 6.27. pilihan Perintah SQL yang digunakan adalah SQL 99 yang digunakan oleh DBMS

DB2/UDB.7.1

Gambar 6.27. Tampilan DDL Statement hasil forward engineering dari Oracle SQL Developer Data Modeler untuk Contoh model relasional dan model ERD yang dibuat


6.8. Enhanced / Extended Entity Relationship Model

Konsep-konsep dasar dari Entity Relationship Model dapat diperluas dan dikembangkan dengan

menggunakan konsep-konsep seperti specialization/generalization (subtype/supertype atau

subclass/superclass), pewarisan atribut, entity clustering dan sebagainya. Pada diktat ini hanya akan

dibahas sebagian dari konsep-konsep yang ditambahkan pada Entity Relationship Model tersebut

yaitu tentang konsep spesialisasi dan generalisasi, dimana konsep ini sebenarnya sudah disinggung

pada saat pembahasan notasi-notasi ERD di sub bab 6.6.

Spesialisasi dan Generalisasi

Konsep proses spesialisasi dan generalisasi dapat dilihat pada gambar 6.10. diatas dan ditampilkan

ulang pada gambar 6.28. sebagai berikut.

Gambar 6.28. Contoh ERD dengan generalisasi dan spesialisasi (supertype/subtype) pada Tulisan Ilmiah Dr. Peter Chen “English, Chinese and ER Diagrams”, 1997

Dari gambar tersebut dapat disimpulkan bahwa :

proses spesialisasi adalah top-down process untuk mengelompokkan/memisahkan

anggota-anggota dari suatu himpunan entitas (supertype) menjadi beberapa

himpunan(kelompok) entitas lain (subtype) yang bersifat lebih spesifik dengan cara

mengidentifikasikan karakteristik yang berbeda antar himpunan entitas (subtype) tersebut.

proses generalisasi adalah bottom-up process untuk menggabungkan anggota-anggota dari

sejumlah himpunan entitas subtype lebih spesifik menjadi sebuah himpunan entitas

supertype yang lebih bersifat general.

konsep spesialisasi dan generalisasi akan berhubungan erat dengan konsep supertype,

subytype dan pewarisan (Inheritance).


Supertype, Subtype dan Pewarisan

Pada konsep spesialisasi dan generalisasi, maka setiap anggota dari himpunan entitas akan menerima pewarisan atribut dan pewahimpunan entitas supertype. Selain atribut yang diperoleh dari pewarisan entitas subtype juga dapat memiliki atribut yang unik dan hanya dimiliki oleh subtype tersebut saja.

Derajat kardinalitas dari Himpunan relationship antara himpunan entitas supertype dan himpunan entitas subtype adalah One to One (1dan subtype ini sering juga disebut sebagai supertype(superclass)/subtype(

Perlu dicatat juga bahwa setiap subtype dari subtype dapat memiliki suatu type hierachy. Type Hierachygeneralization hierarchy atau IS

Untuk menggambarkan adanya maka simbol-simbol yang digunakan akan bergantung pada notasi diatas dan gambar 6.29 dibawah ini menunjukkan contoh supertype dan subtype dengan menggunakan beberapa notasi ERD yang sudah dibahas pada sub bab 6.6.

(a) “Database System Concepts 5

Gambar 6

Diktat Basis Data

dan Pewarisan (Inheritance)

Pada konsep spesialisasi dan generalisasi, maka setiap anggota dari himpunan entitas atribut dan pewarisan himpunan relationship yang dimiliki oleh

. Selain atribut yang diperoleh dari pewarisan atribut maka himpunan entitas subtype juga dapat memiliki atribut yang unik dan hanya dimiliki oleh subtype tersebut saja.

Derajat kardinalitas dari Himpunan relationship antara himpunan entitas supertype dan himpunan entitas subtype adalah One to One (1 Ke 1) dan himpunan relationship antara supertype dan subtype ini sering juga disebut sebagai IS-A Relationship

subtype(subclass) relationship..

Perlu dicatat juga bahwa setiap subtype pada akhirnya juga dapat memiliki dapat memiliki subtype dan seterusnya, jika hal ini terjadi maka

Type Hierachy juga sering disebut sebagai specialization hierarchyIS- A hierarchy.

menggambarkan adanya supertype dan subtype pada ERD (Entity Relationship Diagramsimbol yang digunakan akan bergantung pada notasi ERD yang digunakan.

diatas dan gambar 6.29 dibawah ini menunjukkan contoh ERD yang menampilkan hubundengan menggunakan beberapa notasi ERD yang sudah dibahas pada sub bab

Notasi Silberschatz – Korth – Sudarshan “Database System Concepts 5th Edition” dan “Database System Concepts 6

(b) Notasi Barker’s

r 6.29. Contoh ERD dengan Supertype – Subtype

142

Pada konsep spesialisasi dan generalisasi, maka setiap anggota dari himpunan entitas subtype risan himpunan relationship yang dimiliki oleh

atribut maka himpunan entitas subtype juga dapat memiliki atribut yang unik dan hanya dimiliki oleh subtype tersebut saja.

Derajat kardinalitas dari Himpunan relationship antara himpunan entitas supertype dan Ke 1) dan himpunan relationship antara supertype

A Relationship atau

pada akhirnya juga dapat memiliki subtype lagi, setiap dan seterusnya, jika hal ini terjadi maka akan terbentuk

specialization hierarchy,

Entity Relationship Diagram) yang digunakan. Gambar 6.28

yang menampilkan hubungan dengan menggunakan beberapa notasi ERD yang sudah dibahas pada sub bab

Edition” dan “Database System Concepts 6th Edition”


Batasan-Batasan Pada Supertype / Subtype Relationship

Batasan-batasan yang ada pada himpunan relationship antara supertype dengan subtype

adalah:

1. Participation Constraint atau Completeness Constraint

Batasan partisipasi akan menentukan apakah setiap anggota dari himpunan entitas

supertype juga harus berpartisipasi pada salah satu himpunan entitas subtype yang

dimilikinya. Jenis dari batasan partisipasi atau completeness constraint adalah :

a. Total / Mandatory / Complete : Keikutsertaan bersifat wajib (Setiap anggota dari

himpunan entitas supertype harus menjadi anggota 1 himpunan entitas subtype)

b. Optional / Partial : Keikut sertaan tidak bersifat wajib (Anggota dari himpunan entitas

supetype mungkin (tidak wajib) menjadi anggota 1 atau lebih himpunan entitas

subtype)

Catatan :

Tidak semua notasi ERD mendukung adanya completeness constraint berjenis optional pada

hubungan antara supertype - subtype, misalnya untuk notasi Barker’s maka hubungan

antara supertype dan subtype haruslah bersifat total (mandatory).

2. Disjoint Constraint

Batasan yang akan menentukan apakah setiap anggota dari himpunan entitas supertype

hanya dapat menjadi anggota 1 himpunan entitas subtype atau dapat menjadi anggota satu

atau lebih (one or more) himpunan entitas subtype yang ada dalam himpunan entitas

supertype tersebut. Jenis nilai dari batasan disjoint adalah :

a. Disjoint : Jika setiap anggota himpunan entitas supertype hanya dapat menjadi anggota

satu himpunan entitas subtype

b. Overlapping / Non Disjoint : Jika setiap anggota himpunan entitas supertype dapat

menjadi anggota satu atau lebih himpunan entitas subtype.

Salah satu contoh notasi ERD yang dapat digunakan untuk menggambarkan adanya batasan

partisipasi dan disjoint constraint seperti yang telah dipaparkan diatas adalah notasi information

engineering. Tabel 6.6. berikut menunjukkan simbol batasan partisipasi dan disjoint constraint pada

notasi Information Engineering. (Coronel. C., Morris, S., Rob, P, “Database Systems – Design ,

Implementation and Management 9th Edition”,Cengage Learning,2010)

Tabel 6.6. Simbol Batasan Partisipasi dan Disjoint Constraint pada Supertype-Subtype Relationship dengan dengan Notasi ERD Information Engineering


Batasan Partisipasi (Completeness

Constraint)

Supertype-subtype relationship dengan batasan partisipasi Total / Mandatory / Complete

Supertype-subtype relationship dengan batasan partisipasi Optional/Partial



Disjoint Constraint

d

keanggotaan subtype bersifat disjoint. Contoh :

dan

O

keanggotaan subtype bersifat overlapping. Contoh :

dan

Contoh penggunaan supertype,subtype, completeness constraint dan disjoint constraint pada

notasi ERD Information Engineering dapat dilihat pada gambar 6.30 sebagai berikut :

Gambar 6.30. Contoh ERD Supertype – Subtype berikut batasannya pada notasi ERD Information Engineering (Coronel. C., Morris, S., Rob, P, “Database Systems – Design , Implementation and Management 9th Edition”,Cengage Learning,2010)

Subtype Discriminator

Subtype Discriminator adalah atribut pada himpunan entitas supertype yang akan menentukan jenis

subtype dari setiap anggota himpunan entitas supertype. Untuk gambar 6.30 diatas maka subtype

discriminator yang dipilih a dalah EMP_TYPE dengan domain nilai {“P”,”M”, “A”}.

d

O

d

O


7

Normalisasi Basis Data

Normalisasi basis data atau Database normalization dapat didefinisikan sebagai berikut: (Wikipedia) :

the process of structuring a relational database in accordance with a series of so-called normal forms in order to reduce data redundancy and improve data integrity.

proses penataan basis data relasional sesuai dengan serangkaian bentuk normal untuk dapat meminimalisasi redundansi data dan meningkatkan integritas data.

Normalisasi basis data pertama kali diusulkan oleh Edgar F. Codd sebagai bagian dari metode perancangan basis data relasional yang perlu dilakukan agar didapatkan model relasional yang optimal. Normalisasi dimulai dengan terlebih dahulu memeriksa hubungan yang disebut sebagai ketergantungan fungsional (KF) atau Functional Dependency (FD) antara atribut-atribut yang ada dalam suatu relation (tabel).

Pada praktiknya, proses normalisasi akan menggunakan sejumlah pengujian terhadap kriteria yang disebut sebagai bentuk normal (normal forms) untuk mendapatkan relation (pengelompokkan atribut) atau tabel yang paling optimal dan sesuai dengan kebutuhan data dari pengguna.

Dari paparan diatas dapat disimpulkan bahwa tujuan dari proses normalisasi adalah mendapatkan sejumlah (sehimpunan) relation (tabel) yang paling optimal dan sesuai dengan kebutuhan dari pengguna. Karakteristik atau ciri – ciri bahwa sejumlah relation (tabel) sudah merupakan relation yang optimal dan memenuhi kebutuhan data dari pengguna adalah : (“Database Systems – A Pratical Approach to Design, Implementation and Management 4th Edition”, Connoly, T.M, Begg, C.E., 2005)

Diperolehnya jumlah atribut yang paling minimal tetapi dapat menunjang kebutuhan data pengguna.

Diperolehnya relation (tabel) yang akan mengelompokkan atribut-atribut yang memiliki keterkaitan yang erat secara logis (dideskripsikan sebagai adanya ketergantungan fungsional) antara atribut non kunci terhadap atribut kunci primer)

Tercapainya redundansi data yang paling minimal, dimana setiap atribut hanya akan ditampilkan dan disimpan dalam satu relation (saja), kecuali untuk atribut kunci tamu (foreign key) karena dibutuhkan untuk menunjukkan hubungan antar relation (tabel) yang saling berkaitan.

Tidak terjadi anomali dalam proses penyisipan, penghapusan dan pembaruan data pada relation.

Normalisasi basis data relasional, jika dilihat dari penggunaannya adalah suatu cara atau teknik formal yang dapat digunakan di berbagai tahapan perancangan dan pengembangan basis data. Walaupun normalisasi dapat digunakan di berbagai tahapan, pada gambar 7.1. dibawah ini, ditampilkan dua pendekatan (approach) yang umum tentang bagaimana proses normalisasi dapat digunakan dalam perancangan basis data relasional. (“Database Systems – A Pratical Approach to Design, Implementation and Management 4th Edition”, Connoly, T.M, Begg, C.E., 2005)


Gambar 7.1. Dua Pendekatan Yang Umum dalam menggunakan Proses Normalisasi Basis Data (“Database Systems – A Pratical Approach to Design, Implementation and Management 4th Edition”, Connoly, T.M, Begg, C.E., 2005)

Dari gambar 7.1. diatas dapat dilihat bahwa perancang basis data dapat menggunakan proses

normalisasi sebagai bagian dari perancangan yang bersifat top down ataupun pada perancangan

yang bersifat bottom up.

7.1. Ketergantungan Fungsional (Functional Dependency)

Ketergantungan fungsional adalah suatu karakteristik dari makna (semantik) tentang atribut-

atribut yang berada dalam suatu relation (tabel). Makna atau semantik yang dimaksud diatas adalah

fungsi yang akan mengindikasikan tentang bagaimana atribut-atribut dalam suatu relation saling

berhubungan.

Jika suatu relation r memiliki schema R = (X,Y) dan terdapat ketergantungan fungsional dalam

relation dengan schema R tersebut yaitu atribut Y bergantung pada atribut X (atau atribut X

menentukan atribut Y), maka ketergantungan fungsional tersebut dapat dinyatakan dengan notasi

KF : X Y dan dapat digambarkan seperti pada gambar 7.2. Pada KF XY, atribut X adalah

determinant attribute sedangkan atribut Y adalah dependent attribute dari KF.

Gambar 7.2. Diagram Ketergantungan Fungsional X Y

X Y Y is functionally

dependent on X

Use normalization as a validation technique

to check structure of relations

Use normalization as a Bottom-up technique

to create set of relations


Full Functional Dependency, Partial Dependency dan Transitive Dependency

Suatu partial dependency dapat terjadi pada suatu relation r jika terdapat suatu KF yang bagian

determinant attribute-nya hanya merupakan sebagian dari atribut kunci primer dari relation r

tersebut.

Contoh : Diberikan relation r dengan schema R = (W,X,Y,Z) dimana atribut (W,Z) adalah kunci primer berbentuk kunci komposit dari dari relation r tersebut. Jika pada relation r berlaku himpunan KF

F = { (W,X)(Y,Z), XY} maka KF : XY adalah KF yang menyebakan adanya partial dependency pada relation r tersebut.

Contoh Soal 7.1. Jika diberikan relation loan_branch = (loan_number, branch_name, amount, assets, branch_city) dimana ditentukan kunci primernya adalah (loan_number,branch_name) dan diberikan himpunan KF :

F = { (loan_number,branch_name) (amount,asset,branch_city), branch_name assets, branch_city , loan_number branch_name,amount } a. Apakah terdapat partial dependency pada relation loan_branch tersebut ? Jelaskan alasannya ! b. Jika pada relation r terjadi partial dependency, sebutkanlah KF apa saja yang menyebabkan

terjadinya partial dependency ! Jawab a. Ya, terjadi partial dependency, karena terdapat atribut atribut bukan kunci primer yang hanya

bergantung pada sebagian kunci primer. b. KF yang menyebabkan partial dependency pada relasi r tersebut adalah himpunan KF :

F = { branch_name assets,branch_city loan_number branch_name,amount }

Jika pada relation r dengan schema R = (X,Y,Z) terdapat himpunan KF F = {X Y, YZ}, maka Z

dikatakan memiliki ketergantungan transitif (Transitive dependency) terhadap atribut X melalui

atribut Y.

Contoh Soal 7.2. Jika diberikan relation loan_branch = (loan_number,amount,branch_name, assets, branch_city) dengan kunci primer atribut loan_number dan diberikan himpunan KF

F = { loan_number amount,branch_name), branch_name assets, branch_city } tentukan atribut yang memiliki ketergantungan transitif pada relation loan_branch tersebut ! Jawab Ketergantungan transitif pada relation r terjadi pada atribut assets dan branch_city yang bergantung secara transitif terhadap atribut loan_number melalui atribut branch_name.


7.2. Bentuk Normal (Normal Form)

Untuk menyatakan dan mendapatkan relation (tabel) yang optimal (tabel memiliki redundansi

data yang minimal), maka relation (tabel) harus memenuhi sejumlah kriteria. Secara informal dapat

didefinisikan bahwa Normal Forms atau bentuk-bentuk normal adalah lapisan (tingkatan) kriteria-

kriteria yang harus dipenuhi / dicapai oleh suatu relation agar dapat disebut sebagai relation (tabel)

yang optimal dan berada dalam bentuk well defined form. Lapisan (tingkatan) kriteria atau

“tingkatan kenormalan” yang dinyatakan sebagai bentuk normal dapat digambarkan seperti gambar

7.3. dibawah ini.

Gambar 7.3. Hubungan antar lapisan (tingkatan) Bentuk Normal (Connoly, T.M, Begg, C.E., “Database Systems – A Pratical Approach to Design, Implementation and Management 4th Edition”, Addison – Wesley, 2005)

Secara umum, para ahli dan pengguna basis data menyatakan bahwa suatu tabel sudah cukup

optimal bila sudah berada pada lapisan bentuk normal ke 3 (3NF) dan atau BCNF. Pemeriksaan suatu

relation terhadap kriteria bentuk normal ke 4 (4NF), 5NF dan seterusnya, umumnya jarang

diperlukan karena akan berhubungan dengan susunan dan struktur tabel yang jarang sekali terjadi.

Perlu dicatat bahwa normalisasi adalah kebijakan atau petunjuk yang harus dilakukan dalam

proses perancangan basis data. Jika pada tahapan implementasi fisik basis data ternyata tabel

dengan kriteria “strict” menyebabkan penurunan hasil unjuk kerja basis data (misalnya query yang

sering dilakukan adalah query membutuhkan jumlah join tabel yang terlalu banyak), maka prinsip

normalisasi dapat dilanggar dengan menurunkan “tingkat kenormalan” tabel tersebut. Proses ini

disebut sebagai denormalisasi basis data. Konsekuensi dari denormalisasi adalah terjadi peningkatan

redundansi data dan kemungkinan terjadinya anomali pada saat penyisipan, penghapusan dan

pembaruan data. Perancang basis data harus benar-benar yakin dan mempersiapkan prosedur-

prosedur di sisi DBMS sehingga dapat meminimalisasi resiko terjadinya anomali tersebut.

Bentuk Normal Ke 1 (1 NF) Suatu relation (tabel) memenuhi kriteria bentuk normal ke 1 (1 NF) bilamana :

1. Seluruh atribut kunci telah dinyatakan pada relation tersebut

2. Setiap atribut pada relation (tabel) tersebut adalah atribut tunggal (Tidak ada atribut yang

bersifat jamak) dan tabel tidak memiliki kelompok atribut yang berulang (misalnya

address1, address2, address3, dsb)

more optimal


3. Seluruh atribut bukan atribut kunci pada relation (tabel) tersebut harus bergantung

(dependent) terhadap kunci primer

Gambar 7.4. dibawah ini menunjukkan contoh relation atau tabel yang tidak memenuhi bentuk

normal ke 1 (1 NF)

customer_id telephone1 telephone2 telephone3

Gambar 7.4. Contoh relation yang tidak memenuhi kriteria bentuk normal ke 1 (1 NF)

Bentuk Normal Ke 2 (2 NF) Suatu relation (tabel) memenuhi kriteria bentuk normal ke 2 (2 NF) bilamana :

1. Relation (tabel) sudah memenuhi kriteria bentuk normal ke 1 (1 NF).

2. Jika relation (tabel) memiliki kunci primer berbentuk kunci komposit (tersusun atas 2 atau

lebih atribut), maka relation (tabel) tersebut tidak boleh memiliki partial dependency.

(Tidak terdapat atribut non kunci pada relation yang hanya bergantung pada sebagian

atribut kunci primer)

Gambar 7.5. dibawah ini menunjukkan relation atau tabel yang sudah memenuhi bentuk normal ke 1

(1 NF) tetapi tidak memenuhi kriteria bentuk normal ke 2 (2 NF) karena masih memiliki partial

dependency.

Gambar 7.5. Contoh relation yang tidak memenuhi kriteria bentuk normal ke 2 (2 NF) (Coronel. C., Morris, S., Rob, P, “Database Systems – Design , Implementation and Management 9th

Edition”,Cengage Learning,2010)


Bentuk Normal Ke-3 (3 NF) Suatu relation (tabel) memenuhi kriteria bentuk normal ke 3 (3 NF) bilamana :

1. Relation (tabel) sudah memenuhi kriteria bentuk normal ke 2 (2 NF).

2. Tidak terdapat ketergantungan yang bersifat transitif (Transitive Dependency) pada

relation (tabel) tersebut. (Tidak ada atribut non kunci yang bergantung pada atribut non

kunci yang lain).

Gambar 7.6. dibawah ini menunjukkan hasil dekomposisi tabel pada gambar 7.5. yang masih

menghasilkan tabel EMPLOYEE yang belum memenuhi kriteria bentuk normal ke 3 (3 NF)

Gambar 7.6. Relation EMPLOYEE sudah memenuhi kriteria bentuk normal ke 2 (2 NF) tetapi tidak memenuhi bentuk normal ke 3 (3 NF) (Coronel. C., Morris, S., Rob, P, “Database Systems – Design , Implementation and Management 9th Edition”, 2010) Gambar 7.7. dibawah ini menunjukkan hasil dekomposisi relation tabel pada gambar 7.6. dan akan menghasilkan tabel-tabel yang memenuhi kriteria bentuk normal ke 3 (3 NF)

Gambar 7.7. Contoh relations atau tabel-tabel yang sudah memenuhi kriteria bentuk normal ke 3 (3 NF) (Coronel. C., Morris, S., Rob, P, “Database Systems – Design , Implementation and Management 9th Edition”, 2010)


Boyce-Codd Normal Form (BCNF) Suatu relation (tabel) memenuhi kriteria BCNF bilamana :

Untuk setiap determinant yang ada pada relation (tabel) tersebut maka determinant

tersebut adalah suatu candidate key bagi relation (tabel) tersebut.

Gambar 7.8. dibawah ini menunjukkan contoh relation yang sudah memenuhi kriteria bentuk normal

ke 3 (3 NF) tetapi belum memenuhi kriteria BCNF.

Gambar 7.8. Contoh relation (tabel) yang sudah memenuhi kriteria bentuk normal ke 3 (3NF) tetapi belum memenuhi kriteria BCNF (Coronel. C., Morris, S., Rob, P, “Database Systems–Design, Implementation and Management 9th Edition”, 2010)

Gambar 7.9. dibawah ini menunjukkan contoh dekomposisi tabel pada gambar 7.8 sehingga

diperoleh tabel-tabel yang memenuhi kriteria BCNF.

Gambar 7.9. Contoh Dekomposisi tabel yang tidak memenuhi kriteria BCNF (Coronel. C., Morris, S., Rob, P, “Database Systems – Design , Implementation and Management 9th Edition”, 2010)


7.3. Aturan Inferensi (Inference Rule) Pada Ketergantungan Fungsional (Armstrong’s Axioms)

Pada teori ketergantungan fungsional, berlaku aksioma Armstrong (Armstrong’s Axioms).

Aksioma Armstrong berisi sejumlah aturan inferensi (inference rule) yang dapat digunakan untuk

melakukan penalaran, penurunan atau deduksi suatu ketergantungan fungsional dari sejumlah

(himpunan) “fakta” ketergantungan fungsional yang diberikan. Aturan-aturan inferensi yang

terdapat pada aksioma Armstrong (Armstrong’s axioms) untuk A , B, C dan D yang merupakan

himpunan atribut adalah : (Date, C.J., “An Introduction to Database Systems 8th Edition”,2004),

(Silberschatz-Korth-Sudarshan,”Database System Concepts 5th Edition”,2005)

1. Reflexivity : Jika B adalah himpunan bagian dari A, maka A B

2. Augmentation : Jika A B, maka AC BC

3. Transitivity : Jika A B dan B C, maka A C

Dari 3 aturan inferensi diatas dapat diperoleh aturan-aturan tambahan sebagai berikut :

4. Self Determination : A A

5. Decomposition : Jika A BC, maka A B dan A C

6. Union : Jika AB dan AC, maka A BC

7. Composition : Jika A B dan C D, maka AC BD

8. Pseudotransitivity : Jika A B dan BC D, maka AC D

dst.

Contoh Soal 7.3. Jika diberikan relation (tabel) r dengan schema R = (A,B,C,D,E,F) dan memiliki “fakta dunia nyata” himpunan Ketergantungan Fungsional (KF) F : { A BC, A E, CD EF} Buktikan (deduksikan/turunkan/inferensikan) bahwa KF : AD F juga berlaku pada relation r tersebut ! Jawab Urutan Penalaran yang dilakukan untuk membuktikan bahwa KF : AD F berlaku pada r adalah sebagai berikut:

Inferensi (Penalaran) Aturan Inferensi Forward Chaining Deduksi

1 Karena A BC maka berlaku AC ABC AC Decomposition

2 Karena A C maka AD CD AC

ADCD Augmentation

3 Karena CD EF dan AD CD , maka AD EF ADCD CDEF

ADEF Transitivity

4 Karena AD EF, maka AD F (Terbukti) ADEF ADF (Terbukti)

Decomposition


7.4. Tutupan / Klosur dari Himpunan Ketergantungan Fungsional (Closure Of Set Of Functional

Dependencies)

Tutupan (Closure) dari suatu Himpunan Ketergantungan fungsional (KF) yang berlaku pada

suatu relation (tabel) adalah himpunan seluruh Ketergantungan Fungsional tersebut beserta KF – KF

lain yang diperoleh dari penurunan KF yang dimiliki dengan menggunakan aturan dan aksioma

Armstrong. Tutupan (Closure) dari himpunan KF F akan dinyatakan dengan menggunakan simbol F+ .

Contoh : Jika diberikan relation (tabel) r yang hanya memiliki 3 atribut X, Y dan Z berlaku himpunan KF F =

{XY} tentukanlah F+ (tutupan KF F) pada relasi r tersebut.

Contoh Hasil-hasil penurunan/inferensi/deduksi yang diperoleh dari KF F untuk mendapatkan F+

adalah :

1. XX (self determination) 2. YY (self determination) 3. XYXY (augmentation) 4. XY X (decomposition dari KF yang ke-3) 5. XYY (decomposition dari KF yang ke-3) 6. XY (fakta yang diberikan) 7. XXY (augmentation dari KF yang ke 6)

Jadi untuk KF F = {X Y} maka F+ = { XX, YY, XYXY, XY X, XYY, XY, XXY}

7.5. Tutupan / Klosur dari Himpunan Atribut (Closure Of Attribute Sets)

Tutupan (Closure) dari suatu Himpunan atribut Z dari suatu relation r dengan schema R yang

memiliki himpunan KF F adalah himpunan yang berisikan seluruh atribut relation r yang bergantung

(dependent) pada himpunan atribut Z. Tutupan (closure) dari himpunan atribut Z akan disimbolkan

dengan simbol Z+.

Untuk mendapatkan suatu tutupan dari himpunan atribut Z dapat digunakan bagian dari

algoritme seperti pada gambar 7.10 sebagai berikut : (Date, C.J., “An Introduction to Database

Systems 8th Edition”,2004)

1. 2. 3. 4. 5. 6. 7.

TEMP_CLOSURE_Z[ ] = Z Repeat For Each FD X Y in F IF X TEMP_CLOSURE_Z THEN

TEMP_CLOSURE [ ] = TEMP_CLOSURE_Z [ ] Y ; End For Until TEMP_CLOSURE_Z [ ]did not change Z+ = TEMP_CLOSURE_Z [ ]

Gambar 7.10. Bagian algoritme untuk mendapatkan himpunan Z+


Contoh Soal 7.4. Jika diberikan suatu relation r dengan schema R = (A,B,C,D,E,F) dan pada relation r tersebut berlaku himpunan KF F = {ABC,

E CF, B E, CDEF}

Tentukanlah tutupan (closure) dari himpunan atribut Z = {A,B} yang disimbolkan Z+ = {A,B}+ pada relation r tersebut ! Jawab Dengan menggunaan algoritme yang sudah diberikan pada gambar 7.10 akan dapat diperoleh langkah-langkah untuk mendapat {A,B}+ sebagai berikut :

1. Pada baris perintah 1 maka TEMP_CLOSURE_Z = Z = {A,B} 2. Pada baris perintah 3 sampai 5 akan dilakukan perulangan sebanyak jumlah KF pada F yaitu :

Untuk KF ABC karena bagian determinant yaitu A adalah himpunan bagian dari TEMP_CLOSURE_Z {A,B} atau (A {A,B}) maka TEMP_CLOSURE_Z = TEMP_CLOSURE_Z {B,C} = {A,B,C}

Untuk KF E CF karena bagian determinant yaitu E {A,B,C} maka : TEMP_CLOSURE_Z tetap {A,B,C}

Untuk KF B E karena bagian determinant yaitu B {A,B,C} maka TEMP_CLOSURE_Z = {A,B,C} U {E} = {A,B,C,E}

Untuk KF CD EF karena bagian determinant yaitu CD {A,B,C,E}, maka : TEMP_CLOSURE_Z tetap {A,B,C,E}

3. Pada baris perintah 6 karena TEMP_CLOSURE_Z sudah berubah dari {A,B} menjadi {A,B,C,E} maka kembali ke baris perintah 2 (REPEAT)

4. Pada baris perintah 3 sampai 5 akan dilakukan perulangan sebanyak jumlah KF pada F yaitu :

Untuk KF ABC karena bagian dependent sudah dimasukkan pada iterasi sebelumnnya maka : TEMP_CLOSURE_Z tetap {A,B,C,E}

Untuk KF E CF karena bagian determinant yaitu E {A,B,C,E}, maka : TEMP_CLOSURE_Z = {A,B,C,E} U {F} = {A,B,C,E,F}

Untuk KF B E karena bagian determinant sudah dimasukkan pada iterasi sebelumnnya maka : TEMP_CLOSURE_Z tetap {A,B,C,E,F}

Untuk KF CD EF karena bagian determinant yaitu CD {A,B,C,E} maka: TEMP_CLOSURE_Z tetap {A,B,C,E,F}

5. Pada baris perintah 6 karena TEMP_CLOSURE_Z sudah berubah dari {A,B,C,E} menjadi {A,B,C,E,F} maka kembali ke baris perintah 2 (REPEAT)

Untuk pemeriksaan KF ABC sampai KF CD EF tidak akan menyebabkan penambahan baru pada TEMP_CLOSURE_Z tetap {A,B,C,E,F}

6. Pada baris perintah 7 karena TEMP_CLOSURE_Z sudah tidak berubah maka hasil akhir dari TEMP_CLOSURE_Z adalah himpunan tutupan (closure) Z atau Z+ atau {A,B}+ yang dicari yaitu: Z+={A,B}+={A,B,C,E,F}

Jika Langkah-Langkah diatas disederhanakan dapat ditulis sebagai berikut :

1. Z+ = Z = {A,B} (nilai awal Z+ = Z= {A,B} ) 2. Z+ = {A,B,C } (karena terdapat KF : ABC) 3. Z+ = {A,B,C,E} (karena terdapat KF : B E) 4. Z+ = {A,B,C,E,F} (karena terdapat KF : CD EF)


Salah satu kegunaan dari tutupan dari himpunan atribut dari himpunan KF adalah dengan

mengetahui tutupan dari suatu himpunan atribut, maka dapat ditentukan apakah himpunan atribut

tersebut adalah superkey dari suatu relation (tabel).

Contoh Soal 7.5. Jika diberikan suatu relation r dengan schema R (A,B,C,D,E,F) dan pada relation r tersebut berlaku himpunan KF F = {ABC,

E CF, B E, CDEF}

Tentukanlah : a. Tutupan (closure) dari himpunan atribut Z = {A,B} yang disimbolkan Z+ = {A,B}+ pada relation r

tersebut ! b. Apakah atribut komposit AB adalah superkey dari relation (tabel) r ? Jelaskan ! c. Tutupan (closure) dari himpunan atribut Z = {A,D} yang disimbolkan Z+ = {A,D}+ pada relation r

tersebut ! d. Apakah atribut komposit AD adalah superkey dari relation (tabel) r ? Jelaskan alasannya ! e. Buktikan dengan derivasi, bahwa KF : AD ABCDEF ada dalam tutupan (closure) Himpunan

Ketergantungan Fungsional F+ ! Jawab a. Berdasarkan algoritme untuk mencari tutupan himpunan atribut (lihat contoh soal 7.4)

didapatkan : Z+ = {A,B}+ = {A,B,C,E,F}

b. Tidak. Atribut komposit AB bukan merupakan superkey karena atribut-atribut yang bergantung pada atribut komposit tersebut (atribut yang menjadi anggota {A,B}+ hanya atribut A,B,C,E,F) sedangkan atribut D tidak bergantung pada atribut AB

c. Berdasarkan algoritme untuk mencari tutupan himpunan atribut didapatkan : Z+ = {A,D} (nilai awal Z+ = Z= {A,D} ) Z+ = {A,B,C,D } (karena terdapat KF : ABC) Z+ = {A,B,C,D,E} (karena terdapat KF : B E) Z+ = {A,B,C,D,E,F} (karena terdapat KF : CD EF)

d. Ya. Atribut komposit AD adalah superkey sekaligus candidate key pada relation r karena seluruh atribut pada relation r bergantung pada AD (atribut yang menjadi anggota {A,D}+ adalah atribut A,B,C,D,E,F).

e. Bukti bahwa KF : AD ABCDEF ada pada F+

Inferensi (Penalaran) Aturan Inferensi Forward Chaining Deduksi

1 Karena ABC maka AC ABC AB

Decomposition

2 Karena AC maka AD CD AC

ADCD Augmentation

3 Karena ADCD dan CDEF maka ADEF

ADCD CDEF ADEF

Transitivity


4 Karena ABC maka AD BCD ABC

ADBCD Augmentation

5 Karena A A maka AD AD AA

ADAD

Self Determination

dan Augmentation

6

Karena ADCD dan ADEF dan AD BCD dan AD AD , maka AD ABCDEF (Terbukti)

ADCD ADEF ADCDEF

ADCDEF ADBCD

ADBCDEF

ADBCDEF ADAD ADABCDEF

(Terbukti)

Union

7.5. Canonical Cover Himpunan Ketergantungan Fungsional

Istilah lain dari Canonical Cover (Silberschatz,Korth,Sudarshan, “Database System

Concepts”,2005) dari Himpunan Ketergantungan Fungsional antara lain adalah :

Irreducible Sets Of Funtional Dependencies (Date, C.J, “An Introduction to Database

Systems 8th Edition”,2004)

Minimal Sets Of Functional Dependencies (Connoly, T.M, Begg, C.E., “Database Systems – A

Pratical Approach to Design, Implementation and Management 4th Edition”, 2005)

Canonical cover dari suatu himpunan ketergantungan Fungsional F dan dinotasikan dengan FC

adalah himpunan Ketergantungan Fungsional (KF) yang diturunkan dan diimplikasikan secara logis

dari F, dimana himpunan KF Fc ini dapat digunakan untuk mendapatkan seluruh anggota KF dari F+

(Tutupan Himpunan KF F).

Menurut Silberschatz-Korth-Sudarshan maka karakteristik dan kriteria yang harus dipenuhi oleh Fc

adalah :

1. Tidak ada KF pada Fc yang memiliki atribut berlebih (Extraneous attribute)

2. Bagian determinant (bagian kiri KF) dari setiap KF dalam Fc bersifat unik, yaitu tidak ada dua

KF dengan bentuk α1 β1 dan α2 β2 pada Fc dimana α1= α2

Menurut C.J. Date (Date, C.J, “An Introduction to Database Systems 8th Edition”,2004) maka

karakteristik dan kriteria yang harus dipenuhi oleh Fc adalah :

1. Bagian Dependent dari setiap KF dalam Fc hanya 1 atribut

2. Bagian Determinant (bagian sisi kiri) dari setiap KF pada Fc bersifat irreducible yang berarti

tidak ada atribut yang dapat diabaikan (dihilangkan) tanpa merubah F+

3. Tidak ada KF pada Fc yang dapat diabaikan (dihilangkan) tanpa merubah F+


Dari 2 pendapat kelompok ahli diatas maka dapat disimpulkan :

1. Hasil Fc dapat tidak bersifat unik sehingga bisa saja dari himpunan KF F yang sama dapat

diperoleh 2 atau lebih Fc yang berbeda.

2. Tersedia beberapa cara (algoritme dan kriteria) yang dapat digunakan untuk mendapatkan

Fc , misalnya :

metode dari CJ Date adalah mewajibkan bagian dependent (bagian kanan KF) harus

terdiri dari singleton attribute (hanya 1 atribut) sedangkan metode Silberschatz-

Korth-Sudarshan tidak mewajibkan bagian dependent (bagian kanan KF) hanya

terdiri dari 1 atribut.

Metode Silberschatz-Korth-Sudarshan mewajibkan setiap KF pada FC harus memiliki

memiliki bagian determinant (bagian kiri KF) yang berbeda, sedangkan metode CJ

Date mengizinkan terdapat 2 KF atau lebih yang memiliki bagian determinant

(bagian Kiri KF) yang sama.

Fc dengan Metode Silberschatz-Korth-Sudarshan

(Canonical Cover )

Fc dengan Metode CJ Date

(Irreducible Sets )

Contoh : KF dalam Fc dapat berbentuk : X YZ Tetapi tidak boleh berbentuk : XY XZ

Contoh : KF dalam Fc dapat berbentuk : XY XZ Tetapi tidak boleh berbentuk : XYZ

3. Walaupun terdapat kemungkinan 2 atau lebih Fc untuk himpunan KF F yang sama tetapi

setiap Fc harus memenuhi syarat utama yaitu :

Setiap Fc memiliki sejumlah minimal KF yang dapat digunakan untuk mendapatkan

seluruh KF pada tutupan himpunan KF F atau yang sering dinotasikan sebagai F+

Setiap Fc tidak memiliki anggota KF dengan atribut berlebih (Extraneous Attribute).

Untuk memeriksa adanya atribut berlebih (Extraneous Attribute) pada suatu KF di F, maka salah satu

cara yang dapat digunakan adalah menggunakan langkah pemeriksaan yang telah diberikan oleh

Silberschatz-Korth-Sudarshan pada gambar 7.11 sebagai berikut :

1. Untuk KF αβ dan B β (B adalah bagian dari sisi dependent) maka B bersifat berlebih (extraneous) hanya jika :

Untuk F’ = {F – (αβ)} U { α(β - B)}, atribut B tetap ada dalam α+ (Tutupan Himpunan Atribut α di Himpunan KF F’)

2. Untuk KF αβ dan A α (A adalah bagian dari sisi determinant) maka A bersifat berlebih (extraneous) hanya jika :

Untuk himpunan KF F dan γ ≡ (α – A), atribut A tetap ada dalam γ+ (Tutupan Himpunan Atribut γ di Himpunan KF F)

Gambar 7.11. Langkah Pemeriksaan Atribut Berlebih (Extraneous Attribute)


Contoh : Untuk KF F = {ABCD,AE,EC} tunjukkan bahwa C adalah atribut berlebih pada KF ABCD

Karena C adalah bagian dari sisi dependent maka digunakan langkah 1 dari dari gambar 7.11 yaitu :

Tentukan F’ = {ABD (atribut C dihapus),

AE,

EC}

Karena α = AB maka α+ = {AB}+ = {A,B,C,D,E}

Karena atribut C tetap ada dalam {AB}+ , maka atribut C berlebih dan akan diperoleh Fc =

{ABD, AE,EC}

Contoh Soal 7.6. Jika diberikan suatu relation r yang terdiri dari atribut (X,Y,Z) dimana pada relation r tersebut berlaku himpunan KF F = {XYZ

YZ, XY, XYZ}

Tentukan Fc dari relation r tersebut dengan menggunakan : a. Metode Silberschatz-Korth-Sudarshan b. Metode CJ Date Jawab a. Metode Silberschatz – Korth – Sudarshan (Canonical Cover)

XY dan XYZ dapat digabung dengan aturan union yaitu : XYZ XY (union) XYZ

Untuk Fc- Sementara = {XYZ,YZ,XYZ} maka :

Z berlebih pada XYZ karena : pada Himpunan KF F’ = {XY,YZ,XYZ} maka {X}+ = {X,Y,Z}

Fc – Sementara = F’ = {XY,YZ,XYZ}

Untuk Fc – Sementara = {XY,YZ,XYZ} maka :

X berlebih pada XYZ karena pada himpunan KF {XY,YZ,XYZ} maka {X}+ = {X,Y,Z}

Fc-Sementara = {XY,YZ,YZ} = {XY,YZ}

Untuk Fc – Sementara = {XY,YZ} tidak memiliki atribut berlebih, maka : Fc = {XY,YZ}

b. Metode CJ Date (Irreducible Sets)

Untuk Fc – Sementara = F = {XYZ, YZ,XY,XYZ}

XYZ tidak memenuhi syarat karena bagian dependent tidak singleton maka didekomposisi menjadi XY dan XZ

Fc Sementara = {XZ, YZ,XY,XYZ}

Untuk Fc – Sementara = {XZ, YZ,XY,XYZ}

XZ dapat dihapus karena dapat diperoleh dari : XY dan YZ XY YZ (transitivity) XZ


Fc Sementara = {YZ,XY,XYZ}

Untuk Fc-Sementara {YZ,XY,XYZ}

XYZ dapat dihapus karena dapat diperoleh dari XY dan YZ : XY (augmentation) XYY XYY YZ (transitivity)

XYZ

Untuk Fc – Sementara = {XY,YZ} tidak ada lagi KF yang dapat dihapus maka: Fc = {XY,YZ}

Contoh Soal 7.7. Jika diberikan suatu relation r yang terdiri dari atribut (X,Y,Z) dimana pada relation r tersebut berlaku himpunan KF F = {XY

YXZ, ZXY }

Buktikan bahwa dari KF F diatas dapat diperoleh beberapa Fc yang berbeda (Fc bukan himpunan yang bersifat unik) ! Jawab

Metode CJ Date : Dengan menggunakan aturan (rule) decomposition dari aksioma Armstrong, maka KF yang memiliki sisi dependent tidak terdiri dari 1 atribut dapat didekomposisi, sehingga akan didapat KF F yang terdiri dari :

XY

YX

YZ

ZX

ZY Alternatif 1 :

Untuk F = {XY, YX,YZ,ZX, ZY}

ZX dapat dihapus karena dapat diperoleh dari ZY dan YX ZY YX (transitivity) ZX

Maka Fc = { XY, YX,YZ,ZY} Alternatif 2 :

Untuk F = {XY, YX,YZ,ZX, ZY}

YX dapat dihapus karena dapat diperoleh dari YZ dan ZX YZ ZX (transitivity) YX

Maka Fc = { XY, YZ,ZX,ZY} Diatas sudah ditunjukkan 2 Fc yang berbeda tetapi dapat menjadi canonical cover dari KF F yang diberikan, sehingga terbukti bahwa Fc dapat bersifat tidak unik.


7.6. Dekomposisi Relation (Tabel) Berdasarkan Ketergantungan Fungsional

Jika suatu relation r tidak memenuhi kriteria 3 NF atau BCNF, maka sebaiknya relation r tersebut

harus didekomposisi, sehingga diperoleh relations (tabel-tabel) yang memenuhi kriteria bentuk

normal 3 NF atau BCNF. Pada bagian dibawah ini akan dipaparkan langkah-langkah yang dapat

digunakan untuk melakukan dekomposisi berdasarkan KF yang dimiliki suatu relation sehingga dapat

diperoleh relations atau tabel-tabel yang memenuhi kriteria bentuk normal ketiga (3NF) dan atau

tabel-tabel yang memenuhi kriteria BCNF.

7.6.1. Dekomposisi Untuk Mendapatkan Relation (Tabel) yang Memenuhi Bentuk Normal 3NF

Untuk mendekomposisi suatu relation r dengan schema R yang telah memenuhi bentuk normal

ke satu (1 NF) tetapi belum memenuhi bentuk normal kedua dan ketiga (2 NF dan 3 NF), dimana

relation r tersebut memiliki KF F, maka dapat digunakan langkah-langkah seperti pada gambar 7.12.

sebagai berikut : (Silberschatz,Korth,Sudarshan, “Database System Concepts”2005)

1. Tentukan Fc dengan metode Silberschatz-Korth-Sudarshan dari relation r tersebut 2. Untuk Setiap KF pada Fc dengan bentuk α β di Fc, ulanglah langkah berikut secara

berurutan :

Jika belum ada relation ri hasil dekomposisi yang berisi atribut himpunan α,β maka buatlah relation ri dengan schema (α, β)

i=i+1 3. Untuk setiap candidate key dari relation r yang belum dinyatakan pada seluruh ri yang

telah diperoleh dari langkah ke 2, maka lakukan :

Buat relation dengan atribut adalah atribut candidate key dan tambahkan relation ini sebagai ri dengan nilai i berikutnya.

4. Periksalah setiap ri hasil dekomposisi, :

Jika seluruh ri telah memenuhi syarat 1 NF, 2NF dan 3NF maka seluruh ri tersebut adalah relation (tabel) hasil dekomposisi.

Gambar 7.12. Dekomposisi untuk menghasilkan relation dengan bentuk normal 3NF

Contoh Soal 7.8 Jika diberikan relation (tabel) dengan candidate key (customer_id,employee_id) dan KF F seperti gambar dibawah ini

customer_id employee_id branch_name type

Tentukan : a. Fc b. Relations (tabel-tabel) yang memenuhi kriteria bentuk normal ketiga (3 NF) dan diperoleh dari

hasil proses dekomposisi tabel diatas.


Jawab a. KF F pada relation atau tabel diatas adalah :

customer_id,employee_id branch_name,type ; employee_id branch_name ; customer_id,branch_name employee_id

1. Untuk KF : customer_id,employee_id branch_name,type

maka atribut branch_name adalah atribut berlebih karena pada KF F’ = { customer_id,employee_id type ; employee_id branch_name ;

customer_id,branch_name employee_id } , maka : {customer_id,employee_id}+ = {customer_id,employee_id, type, branch_name}

Fc-Sementara = { customer_id,employee_id branch_name,type ; employee_id branch_name ;

customer_id,branch_name employee_id 2. Untuk KF : employee id branch_name , tidak memiliki atribut berlebih 3. Untuk KF : customer_id,branch_name employee_id , tidak memiliki atribut berlebih

Sehingga Fc = Fc-sementara = { customer_id,employee_id type ; employee_id branch_name ;

customer_id,branch_name employee_id } b. Berdasarkan langkah-langkah pada gambar 7.12. dan

Fc = { customer_id,employee_id type ; employee_id branch_name ;

customer_id,branch_name employee_id } maka hasil dekomposisi adalah :

Dari langkah ke – 2 :

r1= customer_id employee_id type

r2= employee_id branch_name

r3= customer_id branch_name employee_id

Dari langkah ke – 3 : Tidak ada relation baru yang dapat ditambahkan karena candidate key {customer_id,employee_id) sudah terdapat pada r1 ,

sehingga hasil akhir dari dekomposisi adalah r1, r2 dan r3 seperti pada gambar berikut:

r1= customer_id employee_id type

3 NF


r2= employee_id branch_name

r3= customer_id branch_name employee_id

7.6.2. Dekomposisi Untuk Mendapatkan Relation yang Memenuhi Bentuk Normal BCNF

Terdapat 2 jenis Ketergantungan Fungsional (KF) atau Functional Dependency (FD), jika dilihat

dari keanggotaan atribut sisi dependent di himpunan atribut sisi determinant yaitu : 1. Ketergantungan Fungsional Trivial (Trivial Functional Dependency)

Ketergantungan Fungsional Trivial adalah KF dimana seluruh atribut sisi dependent adalah

anggota dari himpunan atribut sisi determinant. (KF : α β dimana β α)

Contoh :

AB A (Trivial FD karena {A} {A,B}

AB AB (Trivial FD karena Sisi Dependent {A,B} = Sisi Determinant {A,B})

2. Ketergantungan Non Trivial (Non Trivial Functional Dependency)

Ketergantungan Fungsional Non Trivial adalah KF dimana himpunan atribut sisi dependent

tidak sama atau bukan merupakan himpunan bagian dari himpunan atribut sisi

determinant. (KF α β dimana β α)

Contoh :

X Y (KF Non Trivial karena {Y} {X} )

U UV (KF dibagi 2 yaitu KF UU (KF Trivial) dan KF U V (KF Non Trivial))

Jika dilihat dari Ketergantungan Fungsional, maka suatu relation (tabel) r dengan KF F

memenuhi kriteria bentuk normal BCNF, bilamana untuk setiap anggota KF : α β dari F+ yang ada

pada relation r tersebut, maka :

KF : α β merupakan KF Trivial (β α) atau

α adalah superkey dari relation (tabel) r

Untuk mendekomposisi suatu relation r dengan schema R dan KF F yang telah memenuhi

bentuk normal ke satu (1 NF) tetapi tidak memenuhi bentuk normal BCNF, maka dapat digunakan

langkah-langkah sebagai berikut :

3 NF

3 NF


1. R adalah schema relation r yang tidak memenuhi kriteria BCNF dan memiliki KF F 2. Dapatkanlah KF Non Trivial dari F+ dengan bentuk α β dan α ∩ β = 0 (himpunan kosong) 3. Untuk setiap KF hasil dari langkah 2, lakukanlah proses dekomposisi untuk mendapatkan

relation (tabel) dengan schema Ri = (R- β) dan tabel dengan schema Ri+1 = (α, β) 4. Untuk setiap relation (tabel) hasil dekomposisi dengan schema Ri dan Ri+1 yang belum

berada pada bentuk normal BCNF, gunakan KF Berikutnya dan ulanglah langkah 3 5. Seluruh relation hasil dekomposisi dan berada pada bentuk normal BCNF adalah hasil

dekomposisi.

Gambar 7.12. Dekomposisi untuk menghasilkan relation dengan bentuk normal BCNF

Contoh Soal 7.9. Dekomposisilah relation lending (customer_id, loan_number, amount, branch_name, branch_city, assets) sehingga diperoleh tabel-tabel yang memenuhi bentuk normal BCNF, jika diketahui himpunan KF F di relation tersebut adalah: KF F { branch_namebranch_name,branch_city,assets ; loan_number amount, branch_name ; customer_id,loan_number customer_id} !

customer_id loan_number amount branch_name branch_city assets

Jawab untuk setiap KF di F yaitu : branch_name branch_city,assets ; loan_number amount,branch_name ; customer_id,loan_number customer_id ; berdasarkan langkah-langkah pada gambar 7.12 maka :

1. R = {customer_id,loan_number,amount,branch_name,branch_city,assets} 2. Himpunan KF Non Trivial dari F+ diatas adalah : {

branch_name branch_city,assets, loan_number amount,branch_name

3. Untuk KF : branch_namebranch_city,assets maka dekomposisi adalah R1 = {customer_id,loan_number,amount,branch_name} ------ Tidak BCNF R2 = {branch_namebranch_city,assets} ------ BCNF Karena R1 belum BCNF maka: Untuk KF : loan_number amount,branch_name R1 = {customer_id,loan_number} ------ BCNF R3 = {loan_numberamount,branch_name} ------ BCNF

4. Hasil dekomposisi : r1 = borrower = (customer_id , loan_number) r2 = branch = (branch_name,branch_city,assets) r3 = loan = (loan_number,amount,branch_name)


r1 = borrower = customer_id loan_number

r2= branch = branch_name branch_city assets

r3= loan = loan_number amount branch_name

7.7. Lossles – Join Decomposition

Jika suatu relation r memiliki R dan didekomposisi menjadi 2 relation yaitu r1 dengan schema R1

dan relation r2 dengan schema R2, maka proses dekomposisi r menjadi r1 dan r2 disebut Lossles – Join

Decomposition (Lossles Decomposition) bila untuk setiap instansiasi r, r1 dan r2 berlaku :

r1 r2 = r atau

ΠR1 (r) ΠR2 (r) = r

Jika suatu relation r1 dan r2 hasil dekomposisi pada saat di join kan kembali tidak menghasilkan

relation (tabel) yang sama dengan r maka proses dekomposisi dikatakan sebagai Lossy Join

Decomposition (Lossy Decomposition).

Ketergantungan Fungsional dapat digunakan untuk memeriksa apakah suatu proses

dekomposisi bersifat lossless atau tidak. Schema R1 dan R2 adalah suatu hasil dekomposisi yang

bersifat lossless jika salah satu dari kriteria dibawah ini terpenuhi :

Untuk R yang memiliki himpunan KF F maka, R1 ∩ R2 R1 ada dalam F+ atau

Untuk R yang memiliki himpunan KF F, maka R1 ∩ R2 R2 ada dalam F+

Contoh :

Jika diberikan schema R = bor_loan = (customer_id,loan_number,amount) yang memiliki himpunan KF F = { customerid,loan_number (customer_id,loan_number,amount),

loan_number amount } dan R didekomposisi menjadi : R1 = borrower = (customer_id,loan_number) R2 = loan = (loan_number,amount) Buktikanlah bahwa dekomposisi R menjadi R1 dan R2 bersifat lossless (Lossles Decomposition)


Jawab :

Untuk membuktikan bahwa R1 dan R2 merupakan hasil proses dekomposisi yang bersifat lossless,

maka dapat dilakukan dengan cara memeriksa :

KF : R1 ∩ R2 R2 ada didalam F+ , yaitu : (customer_id,loan_number) ∩ (loan_number,amount) (loan_number,amount)

loan_number loan_number,amount (harus ada dalam F+)

Untuk membuktikan bahwa KF : loan_number loan_number,amount ada di dalam F+, maka dapat

digunakan deduksi berdasarkan aksioma Armstrong sebagai berikut :

loan_number amount (Augmentation) loan_number loan_number,amount (terbukti)

Karena terbukti bahwa KF customer_id,loan_number customer_id,loan_number ada di dalam F+,

maka dapat disimpulkan proses dekomposisi R = (customer_id,loan_number,amount) menjadi :

R1 = borrower = (customer_id,loan_number) R2 = loan = (loan_number,amount) adalah proses dekomposisi yang bersifat Lossless Decomposition.

7.8. Dependency Preservation

Proses dekomposisi suatu relation r dengan schema R menjadi r1 dengan schema R1 dan r2

dengan schema R2 disebut bersifat Dependency preservation, jika seluruh tutupan KF F atau F+ di R

sama dengan F1+ U F2

+ .

Untuk meminimalisasi proses komputasi, biasanya pembuktian Dependency Preservation dari

suatu proses dekomposisi dapat dilakukan hanya dengan menggunakan tutupan atribut dari setiap

himpunan atribut determinan KF F di R.

Contoh : Jika diberikan schema R = bor_loan = (customer_id,loan_number,amount) yang memiliki himpunan

KF F = { customerid,loan_number (customer_id,loan_number,amount), loan_number amount } dan R didekomposisi menjadi : R1 = borrower = (customer_id,loan_number) R2 = loan = (loan_number,amount) Buktikanlah bahwa proses dekomposisi diatas bersifat dependency preservation ! Jawab :

Untuk KF customerid,loan_number customer_id,loan_number,amount

α = bagian determinan = customer_id,loan_number β = bagian dependent = customer_id,loan_number,amount dengan menggunakan R1 dan R2 maka :

Untuk R1 (customer_id,loan_number) Hasil_ R1= { α ∩ R1}

+ ∩ R1

Hasil_ R1= {(customer_id,loan_number)∩(customer_id,loan_number)}+ ∩ {(customer_id,loan_number)

Hasil_R1 = customer_id,loan_number


Untuk R2 (loan_number,amount) Hasil_ R2= { α ∩ R2}

+ ∩ R2 Hasil_ R2= {(loan_number)∩(loan_number,amount)}+ ∩(loan_number,amount)

Hasil_R2 = (loan_number,amount)

Hasil = Hasil_ R1 U Hasil_ R2 = (customer_id,loan_number,amount) Karena {α}+ = {customer_id,loan_number}+ = Hasil = (customer_id,loan_number,amount) maka :

KF : customer_id,loan_number customer_id,loan_number,amount

tetap terpelihara di relations (tabel-tabel) hasil dekomposisi yaitu R1= borrower dan R2= loan

Untuk KF loan_number amount

α = bagian determinan = loan_number β = bagian dependent = amount dengan menggunakan R1 dan R2 maka :

Untuk R1 (customer_id,loan_number) Hasil_ R1= { α ∩ R1}

+ ∩ R1

Hasil_ R1= {(loan_number)∩(customer_id,loan_number)}+ ∩ {(customer_id,loan_number)

Hasil_R1 = loan_number

Untuk R2 (loan_number,amount) Hasil_ R2= { α ∩ R2}

+ ∩ R2 Hasil_ R2= {(loan_number)∩(loan_number,amount)}+ ∩(loan_number,amount)

Hasil_R2 = (loan_number,amount)

Hasil = Hasil_ R1 U Hasil_ R2 = (loan_number,amount) Karena {α}+ = {loan_number}+ = Hasil = (loan_number), maka :

KF : loan_number amount tetap terpelihara di relations (tabel-tabel) hasil dekomposisi yaitu R1= borrower dan R2= loan


Reduksi Entity Relationship Model ke Model Relasional

Entity Relationship Model dan Model Relasional adalah duadigunakan untuk mengabstrasikan fakta “dunia nyata” secara alasan tersebut dan kenyataan bahwa kedua pemodelan (ER menggunakan prinsip-prinsip yang bersesuaian satu dengan yang lain, maka hasil pemodelan Entity Relationship dapat dirubah (dipetakanRelasional (Forward Engineering). Hal yang sama juga dapat dilakukan sebaliknya yaitu merubah Model Relasional menjadi Model Entity Relationship (Reverse Engineering).

Pada pembahasan dalam pengubahan dengan pendekatan Forward Engineering (Selain itu, pada bab ini proses reduksi dan pemetaanadalah proses pengubahan ERD notasi Barker.

Gambar 8.1. Proses Pengubahan ( Forward Engineering Oracle, 2001)

Perlu dicatat bahwa sudah banyak tersedia perangkat aplikasi data modeler yang dapat digunakan untuk melakukan otomasi proses Model atau sebaliknya. Oleh karena itu pada pembahasan notasi Barker, akan ditampilkan hasil otomasi pemetaanlunak data modeler yaitu Oracle SQL Data Modeler.

Diktat Basis Data

8

Reduksi dan Pemetaan (Mapping) Entity Relationship Model ke Model Relasional

el dan Model Relasional adalah dua bentuk pemodelan yang dapat digunakan untuk mengabstrasikan fakta “dunia nyata” secara konseptual dan alasan tersebut dan kenyataan bahwa kedua pemodelan (ER – Model dan Relational Model)

prinsip yang bersesuaian satu dengan yang lain, maka hasil pemodelan Entity petakan) dan atau direduksi menjadi schema relasional pada Model

(Forward Engineering). Hal yang sama juga dapat dilakukan sebaliknya yaitu merubah Model Relasional menjadi Model Entity Relationship (Reverse Engineering).

ada pembahasan dalam diktat ini, pengubahan dan pemetaan yang dilakukan adalah pengubahan dengan pendekatan Forward Engineering (merubah Model ER ke

reduksi dan pemetaan ERD ke model relational yang akan dijelERD yang memiliki notasi ERD notasi Silberschatz-Korth

Proses Pengubahan (Mapping dan reduksi) Model ER ke Model RelasionalForward Engineering (“Data Modeling and Relational Database Desi

Perlu dicatat bahwa sudah banyak tersedia perangkat aplikasi data modeler yang dapat otomasi proses pengubahan Entity Relationship Model ke Relational

eh karena itu pada pembahasan pengubahan ERD yang menggunakan ilkan hasil otomasi pemetaan yang diperoleh dari salah satu perangkat

lunak data modeler yaitu Oracle SQL Data Modeler.

167

bentuk pemodelan yang dapat al dan logis. Berdasarkan

Model dan Relational Model) prinsip yang bersesuaian satu dengan yang lain, maka hasil pemodelan Entity

direduksi menjadi schema relasional pada Model (Forward Engineering). Hal yang sama juga dapat dilakukan sebaliknya yaitu merubah

yang dilakukan adalah ke Model Relational).

ERD ke model relational yang akan dijelaskan Korth-Sudarshan dan

dan reduksi) Model ER ke Model Relasional –

Modeling and Relational Database Design - Volume 1”,

Perlu dicatat bahwa sudah banyak tersedia perangkat aplikasi data modeler yang dapat Entity Relationship Model ke Relational

ERD yang menggunakan yang diperoleh dari salah satu perangkat


8.1. Reduksi ERD Notasi Silberschatz – Korth –Sudarshan ke Model Relasional

8.1.1. Representasi Himpunan Entitas Kuat

Setiap Himpunan Entitas Kuat dari suatu Entity Relationship Diagram dalam notasi Silberschatz-

Korth-Sudarshan dapat dirubah menjadi sebuah relation (tabel) dengan schema yang berisi atribut-

atribut dari Himpunan Entitas Kuat tersebut. Contoh proses reduksi dapat dilihat pada gambar 8.2.

dibawah ini. Pada gambar tersebut dapat dilihat bahwa suatu himpunan entitas kuat loan (gambar

8.2.(a)) akan dirubah menjadi suatu schema relation loan (gambar 8.2.(b)) yang atribut-atributnya

adalah atribut dari himpunan entitas kuat tersebut.

(a) Himpunan entitas kuat loan pada ERD

loan= (loan_number,amount)

loan_number amount

PK = loan_number

(b). Relation (tabel) hasil reduksi

himpunan entitas kuat

Gambar 8.2. Contoh Representasi Himpunan Entitas Kuat di schema tabel pada Model Relasional.

8.1.2. Representasi Himpunan Entitas Lemah (Weak Entity Sets)

Jika Y adalah suatu himpunan entitas lemah dengan atribut (y1,y2, …, yn) dan X adalah himpunan entitas kuat dari Y dan X memiliki kunci primer (x1,x2, …, xn), maka untuk merepresentasikan himpunan entitas lemah Y pada model relasional akan dibuat sebuah relation (tabel) Y yang memiliki atribut gabungan dari atribut himpunan entitas lemah Y dan atribut kunci primer dari himpunan entitas kuat X dan dinyatakan sebagai berikut :

(y1,y2, …, yn) U (x1,x2, …, xn)

Relation (tabel) Y yang diturunkan dari himpunan entitas lemah Y tersebut akan memiliki kunci primer (PK) yang merupakan gabungan dari kunci primer X dan atribut discriminator dari himpunan entitas lemah Y. Gambar 8.3. dibawah ini menunjukkan proses reduksi suatu himpunan entitas lemah payment ke relation (tabel) payment pada model relasional. Pada gambar juga terlihat bahwa himpunan entitas lemah payment tersebut bergantung pada himpunan entitas kuat loan.

Pada gambar 8.3 dapat dilihat bahwa selain kunci primer maka himpunan entitas lemah juga akan memiliki kunci tamu (Foreign Key) yang akan digunakan untuk menghubungkan tabel representasi himpunan entitas lemah ke tabel representasi himpunan entitas kuat. Untuk contoh pada gambar 8.3. maka kunci primer dari tabel loan (representasi himpunan entitas kuat) selain akan menjadi bagian dari kunci primer tabel payment, juga akan menjadi kunci tamu di tabel payment tersebut.

loan

loan_number amount


loan=(loan_number,amount) payment = (loan_number,payment_number, payment_amount, payment_date)

loan_number amount loan_number payment_

number payment_

amount payment_

date

PK = loan_number

PK=loan_number,payment_number FK = loan_number

Gambar 8.3. Contoh Representasi Himpunan Entitas lemah di schema tabel pada Model Relasional.

8.1.3. Representasi Himpunan Relationship (Relationship Set)

Secara umum, jika R adalah suatu himpunan relationship dan jika a1, a2, … , an adalah himpunan atribut yang terbentuk dari gabungan kunci primer dari setiap himpunan entitas yang berpartisipasi dalam himpunan relationship R yang memiliki atribut deskriptif (descriptive attribute) b1, b2, … , bn , maka untuk merepresentasikan himpunan relationship R tersebut dalam model relasional akan dibuat suatu relation (tabel) yang memiliki atribut :

(a1,a2, …, an) U (b1,b2, …, bn)

Representasi Himpunan Relationship Many To Many (Banyak Ke Banyak) Gambar 8.4. dan 8.5. menunjukkan contoh proses reduksi dari ERD yang memiliki himpunan

relationship binary many to many ke schema tabel di model relasional.

Dari gambar 8.4. dapat terlihat bahwa Himpunan Relationship borrower yang tidak memiliki atribut deskriptif (descriptive) akan dirubah menjadi relation (tabel) borrower yang akan memiliki atribut berupa atribut gabungan dari atribut kunci primer himpunan entitas customer dan atribut kunci primer himpunan entitas loan.

Kunci primer (PK) pada tabel borrower adalah :

PK = (customer_id,loan_number) Gabungan atribut kunci primer yang juga diperoleh dari himpunan entitas loan dan himpunan entitas customer.

Kunci tamu (FK) dari tabel borrower adalah :

FK1 = customer_id Atribut pada tabel borrower yang akan menghubungkan tabel borrower dengan tabel customer

FK2 = loan_number Atribut pada tabel borrower yang akan menghubungkan tabel borrower dengan tabel loan


borrower = (customer_id,loan_number)

customer_id loan_number

PK = (customer_id,loan_number) FK1 = (customer_id) FK2 = (loan_number)

customer= (customer_id,customer_street, customer_street,customer_city)

loan = (loan_number,amount)

customer_id Customer

_name Customer

_street Customer

_city

loan_number amount

PK = customer_id PK = loan_number

Gambar 8.4. Contoh Reduksi Himpunan Binary Relationship Many To Many Ke Model Relasional

employee = (employee_id,employee_name) work_for = (worker_employee_id, manager_employee_id)

employee_id employee_name worker_employee_id manager_employee_id

PK = employee_id PK = worker_employee_id,manager_employee_id FK1 = worker_employee_id FK2 = manager_employee_id

Gambar 8.5. Contoh Reduksi Himpunan Relationship Many To Many bersifat rekursif Ke Model Relasional (Unary Many To Many Relationship) Representasi Himpunan Relationship One To One (Satu Ke Satu)

Salah satu alternatif yang sering digunakan untuk melakukan reduksi himpunan relationship One to One adalah menggabungkan atribut dari himpunan entitas yang yang berpartisipasi pada himpunan relationship one to one tersebut. Kunci Primer dari relation (tabel) gabungan dapat dipilih

employee

employee_id

work_for

manager

worker employee_name

customer

customer_id

customer_name

customer_street

customer_city

loan

loan_number amount

borrower


dan berasal dari salah satu kunci primer himpunan entitas yang berpartisipasi dalam himpunan relationship tersebut dan memiliki batasan partisipasi total.

Gambar 8.6. (a) menunjukkan alternatif proses reduksi dari ERD yang memiliki himpunan binary relationship one to one ke schema tabel di model relasional. Dari gambar 8.6.(a) dapat terlihat bahwa Himpunan Entitas book, Himpunan Entitas isbn dan Himpunan Relationship book_isbn akan dirubah dan digabungkan menjadi sebuah relation (tabel) yang disebut relation book. Schema dari relation book akan berisi gabungan seluruh atribut himpunan entitas book dan himpunan entitas isbn. Kunci primer yang dipilih untuk relation (tabel) book adalah kunci primer yang digunakan pada himpunan entitas book (karena batasan partisipasi himpunan entitas book adalah total/mandatory).

Gambar 8.6. (b) menunjukkan alternatif ke-2 proses reduksi dari ERD yang memiliki himpunan binary relationship one to one ke schema tabel di model relasional. Dari gambar 8.6.(b) dapat terlihat bahwa Himpunan Entitas book, dan Himpunan Relationship book_isbn akan dirubah dan digabungkan menjadi sebuah relation (tabel) yang disebut relation book. Himpunan Entitas isbn akan dirubah menjadi relation (tabel) isbn.

book = (customer_id, title, year, isbn price )

book_id title year isbn price

PK = (book_id)

(a) Alternatif Ke 1

book=(book_id,title,year,isbn) isbn=(isbn,price)

book_id title year isbn isbn price

PK = book_id FK = isbn

PK = isbn

(b) Alternatif Ke 2

Gambar 8.6. Contoh Alternatif-alternatif Reduksi Himpunan Relationship One To One Ke Model Relasional

book

book_id

title

year

isbn

isbn price

book_isbn

book

book_id

title

year

isbn

isbn price

book_isbn


Representasi Himpunan Relationship ManyTo One (Banyak Ke Satu) Terdapat 2 alternatif yang sering digunakan untuk melakukan reduksi himpunan relationship

Many to One ke model relasional. Alternatif 1 adalah tetap membuat relation (tabel) yang merepresetasikan himpunan relationship, sedangkan alternatif ke 2 adalah dengan menggabungkan relation (tabel) representasi himpunan relationship dengan relation(tabel) yang merepresentasikan himpunan entitas yang memiliki kardinalitas One (satu).

Gambar 8.7. dibawah ini menunjukkan 2 alternatif yang dapat digunakan untuk melakukan reduksi himpunan binary relationship Many To One ke model relasional.

loan_branch = (loan_number, branch_name)

loan_number branch_name

PK = loan_number FK1 = (loan_number) FK2 = (branch_name)

loan=(loan_number,amount) branch=(branch_name,branch_city,assets)

loan_number amount branch_name branch_city assets

PK = (loan_number) PK = (branch_name)

(a) Alternatif ke -1

loan=(loan_number,amount,branch_name) branch=(branch_name,branch_city,assets)

loan_number amount branch_name branch_name branch_city assets

PK = (loan_number) FK = (branch_name)

PK = (loan_number)

(b) Alternatif ke -2

Gambar 8.7. Dua alternatif Reduksi Himpunan Binary Relationship Many To One Ke Model Relasional

loan

loan_number amount

branch

branch_name

branch_city

loan_branch assets

loan

loan_number amount

branch

branch_name

branch_city

loan_branch assets


Gambar 8.8. dibawah ini menunjukkan 2 alternatif yang dapat digunakan untuk melakukan reduksi himpunan relationship Many To One bersifat rekursif ke model relasional.

employee = (employee_id,employee_name) work_for = (worker_employee_id, manager_employee_id)

employee_id employee_name worker_employee_id manager_employee_id

PK = employee_id PK = worker_employee_id FK1 = worker_employee_id FK2 = manager_employee_id

(a) Alternatif ke -1

employee = (employee_id,employee_name,manager_employee_id)

employee_id employee_name manager_employee_id

PK = worker_employee_id FK = manager_employee_id

(b) Alternatif ke -2

Gambar 8.8. Dua alternatif Reduksi Himpunan Relationship Many To One yang bersifat Rekursif Ke Model Relasional

8.1.4. Representasi Atribut Komposit (Composite Attribute) dan Atribut Bernilai Jamak (Multivalue Attribute)

Representasi Atribut Komposit Untuk merepresentasikan atribut komposit pada model relasional, maka atribut komposit tidak

akan dicatat dalam relation (tabel) melainkan hanya atribut-atribut tunggal pembentuk atribut komposit saja yang akan dirubah menjadi atribut dari relation (tabel). Gambar 8.9 menunjukkan proses reduksi himpunan entitas yang memiliki atribut komposit.

employee

employee_id

work_for

manager


employee

employee_id

work_for

manager



customer=(customer_id,customer_name,customer_street,customer_city)


PK = (loan_number)

Gambar 8.9. Contoh Representasi Himpunan Entitas yang memiliki atribut komposit.

Representasi Atribut Bernilai Jamak (Multivalued Attribute) Untuk merepresentasikan atribut bernilai jamak pada model relasional, maka atribut bernilai

jamak akan dirubah menjadi suatu relation yang atribut – atributnya adalah gabungan dari atribut jamak dan atribut kunci primer dari himpunan entitas atau himpunan relationship dimana atribut jamak tersebut berada.

Gambar 8.10 dibawah ini menunjukkan proses pengubahan atribut bernilai jamak dari suatu himpunan entitas ke suatu relation (tabel) dalam model relasional.

employee=(employee_id,employee_name) dependent_name = (employee_id,d_name)

employee_id employee_name employee_id d_name

PK = (loan_number) PK = (employee_id,d_name)

Gambar 8.10. Contoh Representasi Himpunan Entitas yang memiliki atribut komposit.

8.1.5. Representasi Spesialisasi dan Generalisasi (Subtype dan Supertype)

Untuk merepresentasikan subtype dan supertype maka terdapat beberapa alternatif yang dapat digunakan. Gambar 8.11. menunjukkan alternatif-alternatif yang dapat digunakan untuk melakukan proses reduksi suatu contoh ERD dengan subtype dan supertype ke model relasional.

employee

employee_id

employe_name

dependent_ name

customer

customer_id

customer_name

customer_addres

customer_ city

customer_ street


account = (account_number,balance)

account_number balance

PK = account_number

checking_account = (account_number,overdraft_amount)

account_number overdraft_amount

PK = account_number FK = account_number

savings_account=(account_number,interest_rate)

account_number Interest_rate

PK = account_number FK = account_number

(a) Alternatif ke-1

(b) Alternatif ke-2


account=(account_number,acc_type,balance,interest_rate,overdraft_amount)

account_number acc_type balance Interest_rate overdraft_amount

PK = account_number,acc_type

(c) Alternatif ke-3 (Membutuhkan atribut subtype_discriminator)

Gambar 8.11. Alternatif-alternatif representasi supertype – subtype relationship pada model relasional.

Perlu dicatat bahwa pemilihan alternatif-alternatif diatas akan bergantung pada kebutuhan dan batasan-batasan yang ada pada fakta “dunia nyata” yang akan direpresentasikan. Setiap alternatif akan memiliki kelebihan dan kekurangan yang harus dipertimbangkan oleh perancang basis data.

Alasan penggunaan alternatif ke 1 antara lain adalah diantara subtype memiliki banyak atribut-atribut yang berbeda tetapi juga memiliki banyak kesamaan atribut sehingga dibutuhkan tabel subtype dan tabel supertype secara bersamaan.

Alasan penggunaan alternatif ke 2 antara lain adalah diantara subtype memiliki banyak atribut berbeda tetapi tidak memiliki banyak atribut yang diturunkan dari supertype, sehingga tidak membutuhkan adanya tabel supertype

Alasan penggunaan alternatif ke-3 antara lain adalah subtype tidak memiliki banyak atribut dan sebagian besar atribut adalah atribut yang diturunkan dari atribut supertype. Pada alternatif ini juga harus ditambahkan atribut baru yang disebut sebagai atribut subtype_discriminator. subtype_discriminator digunakan untuk membedakan tuple-tuple di tabel supertype berdasarkan subtype yang ada. Untuk Contoh di gambar 8.11 subtype discriminator yang dibuat adalah atribut acc_type.

8.2. Pemetaan (Mapping) ERD Notasi Barker ke Model Relasional

Untuk melakukan pemetaan model entity relationship dengan notasi Barker ke model

relasional, maka istilah dan terminologi pemetaan (mapping) yang sering digunakan untuk

memetakan ERD ke schema basis data relasional dapat dilihat pada gambar 8.12. dibawah ini.

acc_type

Atribut subtype discriminator yang dibuat


Gambar 8.12. Terminologi Mapping pada proses pengubahan Model ER (Notasi Barker’s) ke Model Relasional – Forward Engineering (“Data Modeling and Relational Database Design – Volume 1”, Oracle, 2001)

8.2.1. Pemetaan (Mapping) Entitas di ERD ke Tabel Pada Model Relasional

Setiap Entitas pada Entity Relationship Model akan dipetakan menjadi sebuah tabel pada Model

Relasional. Gambar 8.13. dibawah ini menunjukkan contoh proses pemetaan entitas ke tabel.

Hasil Mapping di Model Relasional :

Tabel CUSTOMERS = (customer_id, customer_name, customer_street,customer_city) PK =CUSTOMER_PK = customer_id

(a) Entitas (b) Tabel

Gambar 8.13. Hasil pengubahan (Forward Engineering) simbol himpunan entitas ERD ke simbol tabel (relation) pada Schema Diagram Model Relasional (CASE Tools : Oracle SQL Developer Data Modeler) 8.2.2. Pemetaan (Mapping) Himpunan Relationship

Pada bagian ini akan dipaparkan sejumlah pemetaan himpunan relationship dengan derajat kardinalitas yang berbeda yaitu :

Pemetaan (Mapping) Himpunan Relationship Many To Many

Pemetaan (Mapping) Himpunan Relationship One To One

Pemetaan (Mapping) Himpunan Relationship Many To One

Relational Model


Pemetaan(Mapping) ERD yang memiliki Himpunan Relationship Many To Many (Banyak Ke Banyak)

Pada gambar 8.14. dibawah ini ditunjukkan contoh hasil pemetaan atau mapping ERD notasi Barker yang memiliki himpunan relationship many to many ke schema relational diagram.

Entity Relationship Diagram

Relational Schema Diagram


1. Tabel CUSTOMERS = (customer_id,customer_name,customer_street,customer_city) PK =CUSTOMER_PK = customer_id

2. Tabel LOANS = (loan_number,amount) PK = LOAN_PK = (loan_number)

3. Tabel BORROWERS = (customer_id,loan_number) PK = BORROWER_PK = (customer_id,loan_number) FK1 = BORROWER_CUSTOMER_FK = (customer_id) FK2 = BORROWER_LOAN_FK = (loan_number)

Gambar 8.14. Pemetaan ERD yang memiliki Himpunan Relationship ManyTo Many Ke diagram schema relasional

Dirubah/resolve

BORROWER_CUSTOMER_FK BORROWER_LOAN_FK


Pada gambar 8.15. dibawah ini ditunjukkan contoh hasil pemetaan (mapping) ERD notasi Barker yang memiliki himpunan relationship many to many yang bersifat rekursif ke schema relational diagram.




1. Tabel EMPLOYEES = (employee_id,employee_name) PK = EMPLOYEE_PK = employee_id

2. Tabel WORK_FOR = (worker_id,manager_id) PK = WORK_FOR_PK = (worker_id,manager_id) FK1 = WORKER_FK (worker_id) FK2= MANAGER_FK (manager_id)

Gambar 8.15. Pemetaan ERD yang memiliki Himpunan Relationship bersifat rekursif ManyTo Many Ke diagram schema relasional

Dirubah/resolve

WORKER_FK MANAGER_FK


Pemetaan(Mapping) ERD yang memiliki Himpunan Relationship One To One (Satu Ke Banyak) Pada gambar 8.16. dibawah ini ditunjukkan 2 alternatif pemetaan (mapping) ERD notasi Barker

yang memiliki himpunan relationship one to one ke relational schema diagram.




1. Tabel BOOKS = (book_id,title,year,isbn) PK = BOOK_PK = book_id FK = BOOK_ISBN_FK = isbn

2. Tabel ISBN = (isbn,price) PK = ISBN_PK = isbn

(a) Alternatif Ke-1



Hasil Mapping di Model Relasional : 1. Tabel BOOKS = (book_id,title,year,isbn,price)

PK = BOOKS_PK = book_id

(b) Alternatif Ke-2

Gambar 8.16. Dua alternatif pemetaan ERD yang memiliki Himpunan Relationship One To One Ke Schema Model Relasional

Dirubah/resolve ke bentuk 1 himpunan entitas

BOOK_ISBN_FK


Pemetaan (Mapping) ERD yang memiliki Himpunan Relationship Many To One (Banyak Ke Satu) Pada gambar 8.17. dibawah ini ditunjukkan hasil pemetaan (mapping) ERD notasi Barker yang

memiliki himpunan relationship many to one ke relational schema diagram.



Hasil Mapping di Model Relasional : 1. Tabel ACCOUNTS = (account_number,balance,branch_name)

PK = ACCOUNT_PK = account_number FK = ACCOUNT_BRANCH_FK = branch_name

2. Tabel BRANCHES = (branch_name,branch_city,assets) PK = BRANCH_PK = branch_name

Gambar 8.17. Pemetaan ERD yang memiliki Himpunan Relationship Many To One Ke Schema Model Relasional

Gambar 8.18. dibawah ini ditunjukkan hasil pemetaan ERD notasi Barker yang memiliki

himpunan relationship many to one yang bersifat rekursif ke relational schema diagram.




Tabel EMPLOYEES = (employee_id,employee_name,manager_id) PK = EMPLOYEE_PK = employee_id FK = MANAGER_FK = manager_id

Gambar 8.17. Pemetaan ERD yang memiliki Himpunan Relationship Many To One Ke Schema Model Relasional

ACCOUNT_BRANCH_FK


Pemetaan (Mapping) ERD yang memiliki Barred Relationship (Identifying Relationship)

Pada gambar 8.18. dibawah ini ditunjukkan hasil pemetaan ERD notasi Barker yang memiliki

Barred relationship (Identifying relationship) one to many ke relational schema diagram.



Hasil Mapping di Model Relasional : 1. Tabel LOANS = (account_number,balance,branch_name)

PK = LOAN_PK = account_number 2. Tabel PAYMENTS = (loan_number,payment_number,payment_amount,payment_date)

PK = BRANCH_PK = branch_name FK = LOAN_PAYMENT_FK = loan_number

Gambar 8.18. Pemetaan ERD yang memiliki Barred Relationship (Identifying Relationship) One To Many Ke Schema Model Relasional

Pemetaan (Mapping) ERD yang memiliki Exclusive Relationship (Arc Relationship) Pada gambar 8.19. dibawah ini, ditunjukkan salah satu alternatif dari hasil pemetaan ERD notasi

Barker yang memiliki Exclusive Relationship (Arc Relationship) One To One ke relational schema

diagram




Hasil Mapping di Model Relasional : 1. Tabel CUSTOMERS = (customer_id,customer_name,customer_street,customer_city,person_id,company_id)

PK = CUSTOMER_PK = customer_id FK1 =CUSTOMER_PERSON_FK = person_id FK2 = CUSTOMER_COMPANY_FK = company_id

2. Tabel PERSONS = (person_id,person_status) PK = _PK = person_id

3. Tabel COMPANIES = (company_id,company_type) PK = COMPANY_PK = company_id

Gambar 8.19. Salah satu alternatif pemetaan ERD yang memiliki Arc Relationship One To One Ke Schema Model Relasional

8.2.3. Pemetaan (Mapping) ERD dengan Supertype dan Subtype Relationship

Untuk merepresentasikan subtype dan supertype maka terdapat beberapa alternatif yang dapat digunakan. Gambar 8.20. menunjukkan alternatif-alternatif yang dapat digunakan untuk melakukan proses pemetaan (mapping) suatu contoh ERD dengan subtype dan supertype ke model relasional.


CUSTOMER_PERSON_FK

CUSTOMER_COMPANY_FK


Hasil Mapping di Model Relasional : 4. Tabel ACCOUNTS = (account_number,balance)

PK = ACCOUNT_PK = account_number 5. Tabel SAVINGS_ACCOUNTS = (account_number,interest_rate)

PK = SAVINGS_ACCOUNT_PK = account_number FK = ACCOUNT_SAVINGS_ACCOUNT_FK = account_number

6. Tabel CHECKING_ACCOUNTS = (account_number,overdraft_amount) PK = CHECKING_ACCOUNT_PK = account_number FK = ACCOUNT_CHECKING_ACCOUNT_FK = account_number

(a) Alternatif ke-1 (Supertype and Subtype Implementation) atau (Arc Implementation)


Hasil Mapping di Model Relasional : 1. Tabel SAVINGS_ACCOUNTS = (account_number,balance,interest_rate)

PK = SAVINGS_ACCOUNT_PK = account_number 2. Tabel CHECKING_ACCOUNTS = (account_number,balance,overdraft_amount)

PK = CHECKING_ACCOUNT_PK = account_number

(b) Alternatif ke-2 (Subtype Implementation)



Tabel ACCOUNTS = (account_number,balance, interest_rate, overdraft_amount, acc_type)

PK = ACCOUNT_PK = account_number

(c) Alternatif ke-3 (Membutuhkan atribut subtype_discriminator) (Supertype Implementation)

Gambar 8.20. Alternatif-alternatif Pemetaan ERD yang memiliki supertype – subtype relationship pada model relasional.

Perlu dicatat bahwa pemilihan alternatif-alternatif diatas akan bergantung pada kebutuhan dan batasan-batasan yang ada pada fakta “dunia nyata” yang akan direpresentasikan. Setiap alternatif akan memiliki kelebihan dan kekurangan yang harus dipertimbangkan oleh perancang basis data.

Alasan penggunaan alternatif ke 1 antara lain adalah diantara subtype memiliki banyak atribut-atribut yang berbeda tetapi juga memiliki banyak kesamaan atribut sehingga dibutuhkan tabel subtype dan tabel supertype secara bersamaan.

Alasan penggunaan alternatif ke 2 antara lain adalah diantara subtype memiliki banyak atribut berbeda tetapi tidak memiliki banyak atribut yang diturunkan dari supertype, sehingga tidak membutuhkan adanya tabel supertype

Alasan penggunaan alternatif ke-3 antara lain adalah subtype tidak memiliki banyak atribut dan sebagian besar atribut adalah atribut yang diturunkan dari atribut supertype. Pada alternatif ini juga harus ditambahkan atribut baru yang disebut sebagai atribut subtype_discriminator. subtype_discriminator digunakan untuk membedakan tuple-tuple di tabel supertype berdasarkan subtype yang ada. Untuk Contoh di gambar 8.19 subtype discriminator yang dibuat adalah atribut acc_type.

Sistem Basis Data

Documents

Transcript of Sistem Basis Data