Basis Data

DIKTAT KULIAH
PENGANTAR BASIS DATA
oleh:
TOTO SUHARTO
KATA PENGANTAR
Dengan mengucap syukur alhamdulillah, karena atas ijin dan rahmat Allah S.W.T.,
penulis akhirnya dapat menyelesaikan Diktat Kuliah Pengantar Basis Data ini.
Diktat ini disusun dengan maksud agar dapat digunakan sebagai salah satu
rujukan pelengkap mahasiswa dalam mengikuti kuliah Pengantar Basis Data dan
Sistem Basis Data.
Materi pada diktat kuliah ini dibatasi hanya untuk hal-hal yang sifatnya umum
yang berhubungan dengan konsep basis data, dikarenakan keterbatasan waktu
penyampaian materi di kelas (bobot setiap kuliah masing-masing adalah 2 SKS).
Walaupun demikian, prinsip utama dari basis data tetap penulis sertakan dengan
harapan dapat dikembangkan sendiri oleh mahasiswa di luar waktu kuliah.
Pada kesempatan ini pula, penulis sampaikan ucapan terima kasih dan
penghargaan yang setinggi-tingginya kepada semua pihak yang telah membantu
penulis dalam mewujudkan tulisan ini. Semoga segala bentuk bantuan yang telah
diberikan mendapat balasan yang setimpal dari Allah S.W.T.
Penulis menyadari bahwa tulisan ini masih banyak kekurangannya dan untuk itu,
semua kritik dan saran yang sifatnya membangun dalam menyempurnakan tulisan
ini sangat penulis harapkan. Harapan penulis semoga tulisan ini dapat bermanfaat
bagi semua pihak yang memerlukannya.
Bandung, Maret 1997
Toto Suharto
DAFTAR ISI
1. PENDAHULUAN TENTANG DATABASE .…………………………………………… I-1

1.1 Apa yang Disebut Database? …..…………………………………………… I-1
1.2 Mengapa Database? .……………..…………………………………………. I-2
1.3 Sistem Database …………………..………………………………………… I-4
1.4 Kebutuhan-kebutuhan Terhadap Pendekatan Database …………………….. I-6
1.5 Arsitektur Sistem Database ..……………………………..…………………. I-7
Abstraksi Data …..……………………………………….…………………. I-7
Pengorganisasian Data dalam Suatu Database ..………….……………….... I-8
Arsitektur Sistem Database Secara Umum …….…………..……………….. I-10
Struktur Sistem Database ………………………..…………..……………… I-11
2. TERMINOLOGI DAN MODEL-MODEL DATA …………..…………………………… II-1

2.1 Terminologi Data ………….………………………………………………… II-1
2.2 Model-model Data …………………………………..……………………… II-2
2.2.1 Model Data Logika Berbasis Objek …………..……………………… II-2
Model Data Entity-Relationship ……………………………………… II-3
Model Data Semantik ………….……………………………………… II-3
Model Data Entity-Relationship ……………………………………… II-3
2.2.2 Model Data Logika Berbasis Record ….……………………………… II-4
Model Data Relasi …….……….……………………………………… II-4
Model Data Jaringan (Network) .……………………………………… II-5
Model Data Hirarki …………….………………………………..…… II-6
2.2.3 Model Data Fisik ……………………….…………………………….. II-6
3. MODEL DATA ENTITY-RELATIONSHIP ……….…………………………………… III-1

3.1 Entity dan Kelompok Entity ………………………………………………… III-1
3.2 Relasi dan Kelompok Relasi .……………………………………………….. III-2
3.3 Atribut ………………………..……………………………………………… III-3
3.4 Atribut Kunci ……………….……………………………………………….. III-3
3.5 Pemetaan (Mapping) .………..……………………………………………… III-4
3.6 Diagram E-R ….…………….……………………………………………….. III-5
3.7 Occurrence Diagram ..……….……………………………………………….. III-8
3.8 Relasi Tidak Lengkap ……….……………………………………………….. III-8
3.9 Contoh Pembuatan Model Data E-R ..……………………………………….. III-9
3.9.1 Definisi Masalah ……………………………….……………………… III-9
3.9.2 Penyelesaian Masalah ………………………………………………… III-10
3.9.3 Pembuatan Diagram E-R ……………………………………………… III-12
4. MODEL DATA RELASI ……………….…….……………………………………… IV-1

4.1 Struktur Model Data Relasi .………………………………………………… IV-2
4.2 Transformasi Bentuk E-R Menjadi Model Relasi .………………………….. IV-2
4.3 Operasi pada Model Data Relasi .…………………………………………… IV-3
Operasi Dasar .………………………………………………………………. IV-3
Operasi Suplemen …………………………………………………………… IV-5
i
5. MODEL DATA JARINGAN (NETWORK) .…….……………………………………… V-1
5.1 Pengertian Dasar …………..………………………………………………… V-1
5.2 Diagram Struktur Data ………………………..…………………………….. V-2
6. MODEL DATA HIRARKI ……………...…….……………………………………… VI-1

6.1 Pengertian Dasar …………..………………………………………………… VI-1
6.2 Implementasi Secara Fisik ……………………..……………………………. VI-3
6.3 Operasi Pada Model Data Hirarki ……………..……………………………. VI-4
7. PERANCANGAN DATABASE .………...…….……………………………………… VII-1

7.1 Perancangan Logika Database ……………………………………………… VII-1
7.1.1 Perancangan Model Konseptual atau Enterprise ……………………… VII-2
7.1.2 Langkah-langkah Perancangan Model Konseptual …………………… VII-2
7.1.3 Perancangan Model Logika …………………………………………… VII-3
7.2 Perancangan Fisik Database ………………….…..…………………………. VII-3
7.3 Contoh Pelaksanaan Perancangan Database ....…..…………………………. VII-4
7.3.1 Deskripsi Masalah …………..………………………………………… VII-4
7.3.2 Pembuatan Model Entity-Relationship (Model E-R) ………………… VII-6
7.3.3 Pembuatan Model Data Relasi ..………………….. ..………………… VII-7
7.3.4 Analisis Ketergantungan Fungsional dan Normalisasi ..……………… VII-9
7.3.5 Perancangan Fisik Database …….….……………….………………… VII-11
7.3.6 Implementasi …………………….….……………….………………… VII-16
DAFTAR PUSTAKA
LAMPIRAN-LAMPIRAN
ii
Handout Pengantar Database Toto Suharto

1
PENDAHULUAN
TENTANG DATABASE
D alam suatu aplikasi pengolahan data yang berbasis komputer, data memegang
peranan yang cukup penting. Kecepatan waktu tanggap dari sistem salah
satunya ditentukan oleh bagaimana cara penyimpanan data dalam tempat
penyimpanan (storage). Pada saat sekarang ini, cukup banyak cara yang digunakan
untuk mengorganisasikan data dalam tempat penyimpanan tersebut, mulai dari
penggunaan sistem file konvensional sampai pendekatan database. Dari sekian
banyak cara tersebut, penyimpanan dengan pendekatan database lebih banyak
digunakan. Selain memberikan banyak keuntungan, penyimpanan dengan cara ini
sangat ditunjang oleh tersedianya beragam perangkat lunak DBMS yang mudah
didapatkan di pasaran.
1.1. Apa yang Disebut Database?

Database didefinisikan sebagai kumpulan data yang diorganisasi dengan cara dan
aturan tertentu2 pada tempat penyimpanan sekunder guna merepresentasikan dunia
nyata (real world)1, sedemian rupa sehingga kita bisa mendapatkan informasi yang kita
inginkan3 daripadanya. Definisi database di atas mengandung pengertian:
• Merepresentasikan dunia nyata

Kumpulan data tersebut jika diinterpretasikan harus bisa mewakili dan
menggambarkan satu masalah yang berhubungan dengan kehidupan sehari,
misalnya kumpulan data mahasiswa, dosen, mata kuliah, FRS, jadwal dan nilai
mewakili masalah akademis (Tapi, kumpulan data barang, mahasiswa, penjualan,
kendaraan, pajak tidak bisa disebut database, karena tidak mewakili masalah
tertentu!).
• Diorganisasi dengan cara dan aturan tertentu
Kumpulan data tersebut harus diorganisasi dengan salah satu dari tiga cara
berikut, yaitu model relasi, hirarki atau jaringan (Tapi, kumpulan data
mahasiswa, dosen, mata kuliah, FRS, jadwal dan nilai tidak bisa disebut database
jika data mahasiswa dan dosen disimpan dalam file data, dan data mata kuliah,
jadwal serta nilai disimpan dalam file worksheet!).

Pendahuluan Halaman I-1

• Mendapatkan informasi yang kita inginkan

Kumpulan data tersebut harus bisa memberikan informasi tertentu yang
diinginkan seperti informasi jadwal mengajar dosen, nilai dan IPK mahasiswa,
dsb, dari kumpulan data mahasiswa, dosen, mata kuliah, FRS, jadwal dan nilai.
1.2. Mengapa Database?

Database adalah kumpulan data yang disimpan secara terstruktur dalam tempat
penyimpanan sekunder dengan struktur yang didefinisikan. Konsep database dipakai
jika sistem pengolahan data suatu badan usaha (perusahaan) mempunyai beberapa
seri aplikasi dengan penggunaan satu atau beberapa file untuk setiap seri
aplikasinya. Sebagai gambaran, tinjau suatu aplikasi pengolahan data konvensional
suatu badan usaha yang bergerak di bidang penjualan dan pembelian barang pada
bagian Penjualan, Pengadaan dan Keuangan. Misalkan aplikasi pengolahan data
pada bagian-bagian tersebut menggunakan banyak file dengan organisasi dan cara
akses tertentu seperti ditunjukkan Gambar 1-1.
Gambar 1-1 Contoh Aplikasi Pengolahan Data Konvensional
Dari gambar tersebut kita bisa melihat beberapa kelemahan, diantaranya:

1. Tiap bagian mempunyai aplikasi sendiri-sendiri terpisah dari bagian lainnya,
dimana masing-masing aplikasi mungkin ditulis dalam bahasa pemrograman
yang berbeda-beda;
2. Lingkup dan tanggung jawab sistem informasi tiap bagian terbatas pada bagian
masing-masing;
3. Adanya duplikasi dan redudansi data;


4. Adanya ketergantungan struktur file dengan program, dan jumlah file dengan
metode akses.
Masalah-masalah yang mungkin timbul dari keadaan di atas:

1. Masalah koordinasi
Siapakah yang bertanggung jawab bilamana terjadi perbedaan informasi antara
bagian yang satu dengan bagian yang lain.
2. Masalah duplikasi dan redudansi data
Karena setiap file dan aplikasi mungkin dibuat oleh beberapa pemrogram yang
berbeda, akan terjadi perbedaan format file dan penggunaan bahasa
pemrograman. Akibatnya, data yang sama mungkin terrekam di beberapa tempat
(file), sehingga menghabiskan cukup banyak tempat penyimpanan (storage).
3. Masalah fleksibilitas
Jika bagian produksi ingin merencanakan penjadwalan produksi barang, sistem
informasi dari bagian manakah yang harus digunakan? Dari bagian penjualan,
atau dari bagian persediaan? Atau membuat sistem informasi sendiri?
4. Masalah keamanan data
Karena semua data memungkinkan untuk diakses setiap pemakai program, akan
sulit untuk mengontrol keamanan dari data yang diakses pemakai tersebut.
5. Masalah integritas data
Jika terjadi perubahan salah satu item data, misalnya harga barang, maka proses
update harus dilakukan terhadap semua file yang menyimpan informasi tersebut.
6. Ketidakkonsistenan data
Untuk mengatasi kelemahan pada pengolahan data konvensional di atas, diperlukan

suatu sistem informasi yang terintegrasi, yang diwujudkan melalui pendekatan
penggunaan konsep database.
Gambar 1-2 Contoh Aplikasi dengan Pendekatan Database


Dengan digunakannya konsep database didapat keuntungan sebagai berikut:
1. Bentuk koordinasi yang tegas (consistency/integrity)

2. Pengurangan dalam kasus duplikasi dan ketidakkonsistenan data
Hanya satu salinan file yang disimpan dalam database, walaupun file tersebut
digunakan secara bersama oleh pelbagai user. Dengan demikian duplikasi dan
redudansi data dapat dihilangkan.
3. Fleksibilitas tinggi karena adanya ketidaktergantungan data terhadap program
Fasilitas penggunaan data secara bersama-sama dilakukan dengan memisahkan
data dan program aplikasinya. Bentuk data-independence seperti ini akan
memberikan kesempatan untuk memodifikasi program secara cepat.
4. Minimasi proses update
Karena data disimpan secara bersama (komunal), peremajaan data induk dan
transaksi cukup dilakukan satu kali, sehingga mengurangi proses update.
5. Waktu tanggap sistem meningkat sehingga meningkatkan aksebilitas
Database disimpan pada perangkat akses langsung (DAD = Direct Access Devices),
dimana antara data yang satu dengan yang lain dihubungkan oleh pointer, index
dan teknik relasional lainnya sehingga akses terhadap data relatif lebih cepat.
6. Mengurangi biaya pemeliharaan untuk perubahan data dan media penyimpanan
7. Meningkatkan produktivitas
Akses data yang disimpan dalam suatu database dapat dilakukan oleh siapapun
tanpa latar belakang bahwa pemakai harus mengetahui ilmu komputer.
8. Keamanan data lebih terjamin
1.3. Sistem Database

Sistem database didefinisikan sebagai kombinasi perangkat lunak (software) dan
perangkat keras (hardware) yang memungkinkan untuk melaksanakan tugas
pengolahan database dalam skala yang cukup besar sehingga memenuhi kebutuhan
informasi pemakai dari padanya. Suatu sistem database dapat terwujud apabila ada
kerja sama diantara unsur-unsur pendukungnya, yaitu unsur manusia, hardware
dan software.
Unsur manusia meliputi end-user, programmer dan DBA (DataBase Administrator)

yang kesemuanya bertanggung jawab terhadap kelangsungan sistem database. End-
user adalah orang yang bertindak sebagai pemakai program aplikasi yang dibuat oleh
programmer. Sementara DBA adalah orang yang bertanggung jawab penuh terhadap
keberadaan dan keamanan database, mengatur dan menyesuaikan database dengan
kondisi organisasi, serta mengawasi pemakaian database agar jangan sampai terjadi
kerusakan ataupun pengaksesan dari user yang tidak berwenang.
Hardware adalah perangkat komputer dimana database disimpan yang dibutuhkan

unsur manusia untuk melaksanakan tugasnya. Komputer yang dipakai bisa berupa
komputer mikro (PC), mini maupun mainframe. Demikian pula dengan arsitekturnya,
bisa menggunakan LAN (Local Area Network), dump terminal, atau yang lainnya.


Software adalah perangkat lunak yang digunakan untuk mengoperasikan komputer.

Unsur software ini meliputi sistem operasi yang merupakan dasar pengoperasian
komputer, program aplikasi yang dibuat programmer, dan DBMS (DataBase
Management System). DBMS merupakan software yang tugas utamanya membantu
kita untuk membuat, mengupdate (insert, edit, delete), mengolah dan menyajikan
informasi yang terkandung dalam database.
DBMS yang digunakan dalam suatu sistem database biasanya mempunyai bagian-
bagian sebagai berikut:
1. Data Description Language (DDL)

Suatu bahasa yang digunakan untuk mendeklarasikan skema database menjadi
kumpulan tabel data. Tabel hasil deklarasi ini disimpan dalam suatu file khusus
yang disebut Data Dictionary (atau Directory). Selain untuk mendeklarasikan
skema database, DDL ini pun digunakan untuk menentukan struktur tempat
penyimpanan dan metode akses. Bagian khusus dari DDL yang digunakan untuk
keperluan tersebut disebut data storage and definition language.
2. Data Manipulation Language (DML)

Suatu bahasa yang memungkinkan pemakai untuk mengakses dan memanipulasi
nilai-nilai data dari suatu database. Yang dimaksud dengan manipulasi data
disini adalah:
• Menyajikan informasi yang terkandung dalam database

• Menyisipkan data baru ke database
• Menghapus data dari database
• Mengubah informasi yang tersimpan dalam database
Pada dasarnya ada dua jenis DML yaitu:
• Procedural. DML ini akan meminta pemakai untuk menentukan data apa
yang dibutuhkan dan bagaimana cara untuk mendapatkannya.
• Non-procedural. DML ini akan meminta pemakai untuk menentukan data
apa yang dibutuhkan tanpa harus menentukan bagaimana cara untuk
mendapatkannya.
Jenis DML non-procedural ini mudah sekali untuk dipelajari dan digunakan
pemakai dibanding yang procedural. Tetapi karena pemakai tidak harus
menentukan bagaimana data didapat, DML ini akan membuat kode yang tidak
efisien dibandingkan dengan yang dibuat oleh DML procedural sehingga membuat
kerja sistem menjadi lama.
3. Database Control System (DBCS)

Bagian DBMS yang bertugas mengeksekusi command (perintah) dan queries
(bahasa tanya-jawab), serta mengontrol dan mengendalikan jalannya sistem
DBMS secara keseluruhan.


Beberapa paket perangkat lunak DBMS populer yang tersedia di pasaran pada saat
ini diantaranya adalah MS-Access, Oracle, Clipper, dBase IV dan FoxPro untuk
lingkungan komputer PC. Dalam skala yang lebih besar dikenal DBMS seperti DB II,
Sybase, Informix, Ingres, Progress, dan masih banyak lagi.
1.4. Kebutuhan-kebutuhan Terhadap Pendekatan Database

Untuk mencapai tingkat ideal dari suatu sistem informasi dengan pendekatan
database dibutuhkan beberapa hal, yaitu:
1. Standarisasi
Item-item data pada database harus mempunyai definisi baku sehingga dapat
diakses oleh semua program aplikasi, maupun semua tingkat pemakai sistem
database.
2. Pemilikan data secara bersama

Dari konsep “informasi merupakan sumber daya perusahaan”, harus disadari
bahwa semua data perusahaan merupakan milik semua pihak, sehingga tidak
dikenal lagi konsep eksklusifisme sistem informasi. Hal ini mengandung arti
bahwa sistem informasi perusahaan haruslah merupakan suatu bagian yang
mandiri dan terpadu, yang bebas dari kepentingan masing-masing bagian.
Dengan demikian data dari suatu bagian dapat digunakan oleh bagian lainnya,
demikian pula sebaliknya.
3. Schema
Data yang tersimpan dalam suatu database harus dideskripsikan sedemikian
rupa sehingga struktur logikanya dapat dimengerti oleh pelbagai pemakainya.
Deskripsi logika suatu database dinyatakan dengan schema (skema). Skema
merupakan gambaran logika (logical view) atau cetak biru (blue print) dari disain
database secara keseluruhan. Suatu sistem database mempunyai beberapa
tingkatan skema, yaitu skema fisik, skema konseptual dan sub-skema.
4. Struktur data
Data pada suatu sistem database harus disusun menurut struktur yang
berkaitan secara logika dengan model skema konseptualnya. Bentuk
pengorganisasian data yang digunakan dalam sistem database misalnya adalah
sistem file konvensional seperti sequential, indexed-sequential dan random.
Disamping itu bentuk pengorganisasian data lainnya adalah simple-list, inverted-
list, struktur pohon, struktur jaringan (network), dan sebagainya.
5. Perangkat lunak DBMS

Sebenarnya jika ditinjau secara konseptual, pendekatan database tidaklah selalu
harus menyimpan data pada sistem yang berbasis komputer. Akan tetapi jika
ditinjau dari segi praktis, tanpa implementasi kedalam sistem komputer,
pendekatan database akan menimbulkan berbagai kesulitan. Hal ini dikarenakan
pekerjaan untuk mewujudkan sistem database bukanlah pekerjaan yang mudah.


Kita harus dapat mengatur database yang kita buat sedemikian rupa sehingga
database tersebut dapat digunakan oleh banyak user tanpa terjadi kekacauan
data. Selain itu, pengaturan kepentingan pemakai dari database tersebut,
kesulitan dalam memelihara susunan data, merupakan kendala yang mungkin
kita dapatkan. Oleh karena itu dibutuhkan perangkat lunak DBMS, karena
perangkat lunak inilah yang nantinya akan mengerjakan tugas-tugas di atas.
1.5. Arsitektur Sistem Database

Suatu sistem database tersusun dari beberapa bagian modul yang mempunyai fungsi
dan tugas tertentu, dan masing-masing bertanggung jawab atas jalannya sistem
secara keseluruhan. Berikut adalah penjelasan mengenai hal-hal yang berhubungan
dengan arsitektur suatu sistem database.
Abstraksi Data
Kegunaan utama dari suatu sistem database adalah memberikan user (pemakai)
pandangan abstraksi mengenai data. Itu berarti, sistem akan menyembunyikan
rincian tertentu tentang bagaimana data disimpan dan dipelihara. Bayangan tentang
data tidak lagi seperti kondisi sesungguhnya, tetapi digambarkan menyerupai kondisi
yang dihadapi pemakai sehari-hari yang dinyatakan dalam bahasa dan gambar yang
mudah dimengerti. Dengan demikian, penyajian data bisa dilakukan secara efisien
sehingga sistem menjadi bermanfaat (usable).
Sebenarnya hal-hal di atas dapat menuntun kita pada perancangan struktur data
yang kompleks untuk merepresentasikan data dalam database. Akan tetapi karena
tidak semua pemakai sistem database berlatar belakang komputer, komplektivitas
tersebut disembunyikan menjadi tiga level abstraksi sehingga memudahkan interaksi
pemakai dengan sistem. Tiga level (tingkatan) abstraksi data tersebut adalah:
• Level fisik. Tingkat abstraksi paling rendah yang menggambarkan bagaimana

data disimpan sebenarnya. Pada level fisik ini, struktur data tingkat terrendah
yang sangat kompleks dideskripsikan secara rinci.
• Level konseptual. Tingkat abstraksi berikutnya yang menggambarkan data apa

yang disimpan dalam database, serta hubungan yang ada diantaranya. Pada
tingkat ini keseluruhan database digambarkan dalam bentuk satu struktur kecil
yang relatif sederhana. Walaupun implementasi dari struktur sederhana tersebut
mungkin menyertakan struktur level fisik, pemakai pada tingkat ini tidak perlu
memperhatikannya. Penggambaran cukup dengan menggunakan simbol-simbol
seperti kotak dan garis berikut keterangan secukupnya. Level abstraksi
konseptual biasanya digunakan oleh database administrator.


• Level pandangan pemakai. Tingkat abstraksi tertinggi yang hanya

menggambarkan bagian-bagian dari database. Bila pada tingkat konseptual
database digambarkan secara keseluruhan, maka pada tingkat ini data hanya
dilihat sebagian saja, yaitu yang dipakai dan diperlukan pemakai. Hal ini
dikarenakan tidak semua informasi database diperlukan pemakai. Sebagai
misalnya, bagian Personalia hanya membutuhkan data karyawan dan gaji tapi
tidak membutuhkan data gudang atau transaksi barang masuk. Jadi dengan
demikian akan ada beberapa pandangan yang diberikan oleh sistem dari database
yang sama.
Hubungan antara ketiga tingkatan dari abstraksi data ini bisa dinyatakan oleh
Gambar 1-3 berikut ini.
Gambar 1-3 Tiga Tingkatan Abstraksi Data
Pengorganisasian Data dalam Suatu Database

Dalam terminologi sistem database, dikenal pengorganisasian data dalam bentuk fisik
dan logika sebagai berikut:
1. Organisasi File
Organisasi file, disebut juga sebagai sub-skema atau LVIEW, yaitu suatu
gambaran data yang ditujukan untuk satu atau lebih program aplikasi.
Organisasi ini merupakan gambaran yang terbayangkan oleh programmer aplikasi
atau pemakai yang berinteraksi dengan sistem database untuk keperluan segi
aplikasi.


2. Organisasi Logika
Organisasi database secara logika, disebut juga sebagai skema, merupakan
pengorganisasian yang menggambarkan keseluruhan isi database secara logika.
Organisasi ini merupakan tinjauan menyeluruh tentang data yang dilihat oleh
DBA atau system analyst.
3. Organisasi Fisik
Organisasi database secara fisik adalah suatu gambaran tata letak fisik data pada
perangkat penyimpanan. Organisasi ini merupakan lingkup tugas system
programmer dan system designer, yaitu orang yang berhubungan dengan
performansi bagaimanakah posisi data pada perangkat keras, bagaimana cara
indexing maupun teknik pemampatan datanya.
Gambar 1-4 Deskripsi Organisasi Data dalam Database


Arsitektur Sistem Database Secara Umum

Arsitektur sistem database secara umum dapat dilihat pada Gambar 1-5 berikut ini.
Digambarkan peranan seorang DBA dan juga apa yang diurus oleh DBMS secara
global dipandang dari berbagai sudut pandangan (view).
Gambar 1-5 Arsitektur Umum Sistem Database


Pada gambar tersebut kita bisa melihat bahwa pemakai, baik sebagai programmer
aplikasi maupun online terminal user, berkomunikasi dengan sistem database melalui
bahasa pemrograman yang dikenal oleh sistem database. Bahasa yang digunakan
dapat berupa bahasa konvensional (host language), misalnya COBOL, PL/I dan
lainnya, atau bahasa query (bahasa tanya jawab) secara interaktif. Untuk menunjang
pengaksesan data, bahasa-bahasa tersebut biasanya dilengkapi dengan fasilitas DSL
(Data Sub Language) yang merupakan kombinasi dari DDL dan DML yang disediakan
oleh DBMS.
External view terdiri atas beberapa kejadian dari pelbagai jenis record eksternal.
Pemakai berkomunikasi dengan record eksternal melalui DSL. Tiap external view
didefinisikan oleh suatu skema eksternal, yaitu skema yang mendeskripsikan tiap
jenis record eksternal didalam view tersebut. Skema eksternal ditulis dengan
menggunakan DDL.
Conceptual view merupakan penyajian database secara keseluruhan. Bentuknya agak

abstrak dibandingkan dengan external view. Conceptual view didefinisikan melalui
skema konseptual yang melibatkan pendefinisian masing-masing type record
konseptual.
Internal view merupakan penyajian data dalam bentuk fisik yang mendekripsikan
bagaimana record tersimpan.
Struktur Sistem Database

Pada beberapa sistem komputer, suatu sistem database harus dibangun berdasarkan
sistem operasi yang hanya menyediakan services dasar. Oleh karena itu disain sistem
database harus mempertimbangkan interfaces antara sistem database dengan sistem
operasi.
Komponen-komponen fungsional dari suatu sistem database adalah:
• File manager, yang mengelola alokasi ruangan pada tempat penyimpanan dan
struktur data yang digunakan untuk merepresentasikan informasi yang disimpan
dalam disk.
• Database manager, yang menyediakan interface antara data tingkat terrendah
yang tersimpan pada database dengan program aplikasi dan bahasa queries yang
diberikan kepada sistem.
• Query processor, yang berfungsi menerjemahkan pernyataan pada bahasa query
menjadi instruksi tingkat rendah yang dimengerti database manager.
• DML precompiler, yang menerjemahkan pernyataan DML yang ditulis pada
program aplikasi menjadi prosedur yang dapat dipanggil oleh host language.
• DDL precompiler, yang berfungsi menerjemahkan pernyataan DDL menjadi
kumpulan tabel.


Gambar 1-6 memperlihatkan komponen-komponen fungsional tersebut dan

hubungan diantaranya.
users
naive application sophisticated database

users programmers users administrator
application application database

query
interfaces programs scheme
data manipulation data definition

query
language language
processor
precompiler compiler
application
database database
programs
manager management
object code
system
file
manager
data files
disk data dictionary

storage
Gambar 1-6 Struktur Sistem Database


2
Terminologi dan
Model-model Data
D alam suatu sistem database, data merupakan salah satu objek utamanya.
Untuk itu, perlu kiranya untuk mempelajari konsep tentang data ini terutama
yang berhubungan dengan desain dan pembuatan database. Pada bagian ini akan
dibahas beberapa hal yang berhubungan dengan konsep data tersebut. Pertama,
terminologi tentang data dalam konteks sistem database, dan kedua tinjauan
tentang beberapa alat abstrak yang bisa digunakan untuk modelisasi data.
2.1. Terminologi Data

Data didefinisikan sebagai fakta dari suatu kejadian. Fakta dari kejadian tersebut
mungkin ditemukan dalam bentuk dokumen (faktur, laporan), gambar, suara, atau
media lainnya. Apabila data atau fakta sudah mengalami suatu proses, maka
hasilnya disebut informasi.
Dalam konteks sistem database data dinyatakan sebagai kumpulan karakter-

karakter yang disusun menurut suatu aturan agar mudah untuk dikenali,
disimpan, dimanipulasi dan disajikan kembali (retrieve). Secara fisik kumpulan
karakter yang mewakili data ini tersimpan dalam sistem komputer dan membentuk
suatu database dengan hirarki penyusunan sebagai berikut:
• Bit. Adalah suatu sistem angka biner yang hanya mempunyai dua
kemungkinan nilai, yaitu 0 dan 1. Sistem angka biner ini merupakan dasar
komunikasi antara manusia dan mesin (komputer).
• Byte. Adalah kumpulan 8 bit data yang kombinasi nilainya digunakan untuk
menyatakan satu buah karakter.
• Item Data. Adalah satuan terkecil dari data yang mempunyai arti. Item data
sering disebut juga dengan field data atau elemen data, yang dapat diberi nama
sebagai identitasnya.
• Agregat Data. Kumpulan item data dalam suatu record yang diberi nama
tertentu dan dianggap sebagi satu kesatuan yang utuh. Sebagai contoh, agregat
data dengan nama tanggal tersusun dari item data hari, bulan dan tahun.

Model-model Data Halaman II-1

Agregat data dibedakan menjadi vector dan repeating-group. Vector adalah

agregat data dimana masing-masing item data yang menyusunnya mempunyai
type yang berlainan, sedangkan repeating-group tersusun dari item data dengan
type yang sama.
• Record atau tuple. Adalah kumpulan dari item data dan atau agregat data
yang saling berhubungan untuk menyatakan suatu objek tertentu.
• File. Adalah kumpulan record sejenis yang dapat diidentifikasi dengan suatu
nama. File mungkin mempunyai jumlah item data yang sama pada record-
recordnya, tetapi mungkin juga mempunyai variasi jumlah item data yang
berbeda-beda.
• Database. Adalah kumpulan berbagai file yang record, agregat maupun item
datanya mempunyai hubungan dengan record, agregat maupun item data pada
file lainnya sedemikian rupa sehingga membentuk suatu struktur yang dapat
melayani kebutuhan informasi untuk suatu masalah tertentu.
2.2. Model-model Data

Hal yang mendasari struktur suatu database adalah konsep model data, yaitu
kumpulan perangkat konseptual untuk mendeskripsikan data, hubungan antar
data, semantik data dan kendala konsistensinya. Beberapa model data yang ada
dapat dibagi menjadi tiga kelompok, yaitu model data logika berbasis objek, model
data logika berbasis record dan model data fisik.
2.2.1. Model Data Logika Berbasis Objek

Model data logika berbasis objek (object-based logical model) digunakan untuk
mendeskripsikan data pada tingkat konseptual dan view. Pendeskripsian data pada
model ini dibuat berdasarkan fakta sehingga memberikan kemampuan
penstrukturan secara fleksibel, dan memungkinkan untuk menspesifikasikan
kendala-kendala datanya secara eksplisit. Beberapa model data logika berbasis
objek yang sudah dikenal diantaranya adalah:
• Model entity-relationship
• Model berorientasi objek (object-oriented model)
• Model biner
• Model data semantik
• Model infological
• Model data fungsional
Berikut adalah penjelasan singkat beberapa model yang termasuk kedalam

kelompok model data logika berbasis objek ini.


Model Data Entity-Relationship

Model data entity-relationship (model E-R) adalah model data yang pembuatannya
didasarkan pada anggapan bahwa dunia nyata terdiri dari kumpulan objek dasar
yang disebut entity dan relasi diantaranya. Entity adalah sebuah objek yang bisa
dibedakan dari objek lainnya berdasarkan sekumpulan atribut yang spesifik.
Sebagai contoh, atribut number dan balance menyatakan satu entity account pada
sebuah bank. Relasi adalah hubungan diantara beberapa entity. Sebagai contoh,
relasi CustAcct menyatakan hubungan antara customer dengan setiap account yang
dipunyainya.
Pada model E-R ini struktur logika database secara keseluruhan digambarkan
dengan menggunakan diagram E-R yang mempunyai simbol-simbol tertentu.
Simbol-simbol tersebut adalah:
• Kotak, yang menyatakan suatu kelompok entity.

• Belah ketupat, yang menyatakan relasi antara kelompok entity.
• Elips, yang menyatakan suatu atribut.
• Garis, yang menghubungkan atribut dengan kelompok entity dan kelompok
entity dengan relasi.
Contoh dari model E-R ini bisa dilihat pada Gambar 2.1. sedangkan pembahasan
rincinya akan diberikan pada Bab 3.
street
sosial- account-
customer-city
security number
customer- balance
date
name
customer cust-act account
Gambar 2.1. Contoh Model Data E-R
Model Data Semantik

Model data semantik hampir sama dengan model data E-R, hanya saja pernyataan
relasi antar entity tidak digambarkan dengan simbol tetapi menggunakan kata-
kata.


Bank X
melayani adalah nasabah
punya adalah
Account Customer Henry
Number Balance Street City
Gambar 2.2. Contoh Model Data Semantik
Gambar 2.2. di atas menunjukkan contoh model data semantik. Dari gambar
tersebut bisa kita lihat bahwa simbol yang digunakan dalam model data semantik
ini adalah:
• Elips, yang menyatakan suatu objek (entity) maupun atributnya.

• Anak panah, yang menunjukkan relasi antar objek.
• Garis, yang menghubungkan objek dengan atributnya.
2.2.2. Model Data Logika Berbasis Record

Model logika berbasis record digunakan untuk menggambarkan data pada tingkat
konseptual dan view. Model data ini bersama dengan model data logika berbasis
objek biasanya digunakan untuk menyatakan stuktur logika database secara
keseluruhan. Selain itu juga digunakan untuk mendeskripsikan bagaimana
gambaran penerapannya dalam tingkat yang lebih tinggi daripada gambaran
fisiknya.
Struktur database pada model logika berbasis record ini dinyatakan dengan type
record yang mempunyai format tetap. Artinya setiap type record mempunyai
beberapa field atau atribut dengan jumlah tetap, dan setiap field mempunyai
panjang yang tetap.
Tiga model data pada kelompok ini yang telah diterima secara meluas adalah model
data relasi, jaringan (network) dan hirarki. Berikut adalah penjelasan singkat ketiga
model data ini. Adapun penjelasan secara rincinya akan diberikan di Bab 4-6.
Model Data Relasi

Model data relasi merepresentasikan data dan hubungan diantaranya dalam bentuk
kumpulan tabel, dimana setiap tabel tersusun dari sejumlah kolom yang
mempunyai nama yang unik.


Gambar 2.3. adalah sebuah contoh database model relasi yang menunjukkan
customer dengan account yang dipunyainya.
Name Street City Number Number Balance

Lowery Maple Queens 900 900 55
Shiver North Bronx 556 556 100000
Shiver North Bronx 647 647 105366
Hodges Sidehill Brooklyn 801 801 10533
Hodges Sidehill Brooklyn 647
Gambar 2.3. Contoh Data Model Relasi
Pada contoh di atas, customer dengan Hodges yang tinggal di jalan Sidehill di kota
Brooklyn, mempunyai dua account, yaitu account dengan nomor 801 dengan nilai
10533 dan nomor 647 dengan nilai 105366.
Model data relasi dapat dimengerti, diingat dan divisualkan secara lebih mudah
dibandingkan dengan model data yang lainnya.
Model Data Jaringan (Network)

Data pada model data jaringan direpresentasikan dengan kumpulan record,
sedangkan relasi diantara datanya direpresentasikan dengan links, yang bisa
digambarkan sebagai pointer. Dalam database record dan links tersebut diorganisasi
sebagai kumpulan graph yang bisa berubah-ubah (arbitrary graph). Gambar 2.4.
memperlihatkan contoh sebuah model data jaringan yang menggunakan informasi
yang sama seperti Gambar 2.3.
Lowery Maple Queens 900 55
556 100000
Shiver North Bronx
647 105366
Hodges Sidehill Queens 801 10533
Gambar 2.4. Contoh Model Data Jaringan


Model Data Hirarki

Model data hirarki mempunyai kesamaan dengan model jaringan dalam hal
representasi data dan hubungan diantaranya, yaitu dengan record-record dan links.
Berbeda dengan model data jaringan, record-record dan links tersebut dalam
database diorganisasi sebagai kumpulan pohon (tree). Gambar 2.5. memperlihatkan
contoh sebuah model data hirarki dengan informasi yang sama seperti Gambar 2.3.
Lowery Maple Queens Hodges Sidehill Queens
Shiver North Bronx
556 100000 647 105366
900 55 647 105366 801 10533
Gambar 2.5. Contoh Model Data Hirarki
2.2.3. Model Data Fisik

Model data fisik digunakan untuk menggambarkan data pada tingkat paling
rendah. Pada model data ini dijelaskan bagaimana data pada sistem database
disimpan pada perangkat penyimpanan secara fisik. Berbeda dengan model data
logika, hanya ada beberapa model data fisik yang digunakan. Dua model yang
sudah cukup dikenal secara luas adalah:
• unifying model
• memory frame
Karena cakupan dari model data fisik berhubungan dengan aspek mesin
(komputer), maka model data tersebut tidak akan dibahas pada tulisan ini.


3
Model Entity
Relationship (E-R)
M odel Entity-Relationship (model E-R) merupakan suatu model data yang menyatukan
beberapa informasi semantik yang penting mengenai dunia nyata. Pembuatan model
data E-R didasarkan pada anggapan bahwa dunia nyata terdiri dari kumpulan objek-objek
dasar yang disebut entity, dan hubungan yang terjadi diantaranya yang disebut relasi
(relationship). Model data E-R digunakan untuk menyederhanakan permasalahan pembuatan
basis data secara top down.
3.1 Entity dan Kelompok Entity

Entity adalah suatu objek yang bisa dikenali dan dibedakan dengan objek lainnya. Sebagai
contoh, Abdul dengan nomor induk 170845 adalah sebuah entity, karena bisa dikenali secara
unik sebagai seorang mahasiswa di sebuah perguruan tinggi. Dengan pengertian yang sama,
kuliah Basis Data adalah entity karena bisa dikenali secara unik sebagai sebuah mata kuliah.
Entity dapat berupa sesuatu yang nyata seperti orang (mahasiswa, dosen, dll.), bagian
organisasi (perpustakaan, BAAK, dll.), tempat (ruang kuliah, laborarotium, dll.), atau benda
(buku, FRS, dll.). Atau dapat juga berupa sesuatu yang abstrak seperti kuliah, liburan atau
sebuah konsep.
Entity-entity sejenis akan membentuk kelompok entity atau entity sets. Kumpulan beberapa
orang yang mempunyai NPM tertentu di sebuah perguruan tinggi, sebagai contoh, bisa
didefinisikan sebagai kelompok entity mahasiswa. Demikian juga, kelompok entity kuliah
mungkin mendefinisikan kumpulan semua entity kuliah.
Setiap entity dalam kelompok entity mempunyai atribut, yaitu deskripsi data yang
mengidentifikasikan entity tersebut. Sebagai contoh, atribut yang mungkin dipunyai kelompok
entity mahasiswa adalah NPM, nama, dan alamat. Sedangkan atribut yang mungkin untuk
kelompok entity kuliah adalah kode kuliah, nama kuliah dan SKS. Setiap atribut mempunyai
nilai data. Nilai-nilai data dari atribut yang mempunyai karakteristik sintaks dan semantik
yang sama membentuk domain, misalnya domain untuk nama mahasiswa adalah kumpulan
string teks dan domain untuk SKS adalah kumpulan data integer positif.

Model Entity-Relationship Halaman III-1

3.2 Relasi dan Kelompok Relasi

Relasi (relationship) adalah entity yang menjabarkan hubungan keterkaitan antara individu
dari kelompok entity yang satu dengan individu dari kelompok entity yang lainnya. Gambar
3.1 berikut ini menggambarkan pengertian dari relasi tersebut.
Gambar 3.1. Kelompok Relasi
Dari gambar di atas kita bisa melihat relasi antara kelompok entity Persons dengan Vehicles
yang dinyatakan dalam kelompok relasi Drive. ‘Joe driving the Ford’ adalah satu relasi. ‘Jill
driving the Toyota’ adalah relasi yang lain. Kumpulan dari relasi ini disebut kelompok relasi
(relationship sets).
Relasi Drive adalah sebuah contoh dari relasi biner atau binary relationship, yaitu relasi yang
terbentuk dari dua kelompok entity. Kelompok relasi inilah yang paling banyak ditemukan
dalam sistem database. Akan tetapi tidak tertutup kemungkinan adanya relasi yang terbentuk
dari lebih dua entity yang disebut relasi ternary atau n-ary. Sebagai contoh misalnya relasi
antara entity Sopir, Paket dan Kendaraan pada saat pengiriman paket.
Selain relasi biner dan n-ary di atas, kita mungkin menemukan relasi yang terbentuk oleh dua
entity dari satu kelompok yang sama. Relasi seperti ini disebut relasi unary atau relasi
rekursif. Relasi pada saat merakit suatu barang (parts), misalnya mainboard dirakit dari board,
processor dan memory, bisa kita jadikan sebagai contoh dari relasi ini. Mainboard, board,
processor dan memory dianggap sebagai entity-entity dari satu kelompok yang sama, yaitu
kelompok entity Parts.
Seperti halnya entity, relasi pun mempunyai atribut-atribut. Secara umum, atribut yang
dipunyai relasi terdiri dari atribut kunci yang diturunkan dari entity yang membentuknya
ditambah dengan atribut yang muncul pada saat relasi terjadi.


3.3 Atribut
Atribut adalah deskripsi data untuk mengenali suatu entity. Oleh karena itu seluruh atribut dari
entity harus cukup untuk menyatakan identitas dari objek atau entity tersebut. Sebagai contoh,
atribut nama dan alamat belumlah cukup untuk mengenali entity mahasiswa, karena atribut-
atribut tersebut mungkin juga dipunyai oleh entity dosen atau karyawan. Akan tetapi jika
ditambah dengan atribut NPM, fakultas dan jurusan, maka atribut-atribut tersebut sekarang
sudah cukup untuk bisa mengenali suatu entity, dalam hal ini entity mahasiswa.
Satu atau beberapa atribut yang dipunyai entity bisa kita gunakan untuk membedakan masing-
masing entity secara unik. Atribut yang bisa digunakan untuk membedakan sebuah entity
secara unik tersebut dinamakan atribut kunci atau key attribute.
3.4 Atribut Kunci

Salah satu hal penting dalam membuat model data E-R adalah menentukan bagaimana entity
dan relasi dibedakan. Secara konsep, entity dan relasi memang sudah berbeda. Akan tetapi
dalam sudut pandang basis data, perbedaan tersebut harus diekspresikan oleh atribut-atribut
yang dipunyainya. Untuk menentukan perbedaan entity dan relasi tersebut digunakan suatu
atribut yang dinamakan superkey.
Superkey didefinisikan sebagai satu set dari satu atau lebih atribut yang memungkinkan kita
untuk mengenali sebuah entity secara unik. Sebagai contoh misalnya atribut NPM dalam
entity mahasiswa. Karena atribut NPM dapat membedakan antara mahasiswa yang satu
dengan yang lainnya, maka atribut NPM disebut superkey. Superkey dapat terdiri dari
beberapa atribut, sehingga kurang dapat digunakan untuk semua keperluan. Untuk itu perlu
dicari superkey dengan jumlah atribut sesedikit mungkin yang dikenal sebagai candidate keys.
Untuk selanjutnya istilah candidate key ini kita ganti dengan istilah primary key atau atribut
kunci.
Suatu kelompok entity mungkin tidak mempunyai cukup atribut untuk membentuk atribut
kunci. Kelompok entity semacam ini disebut weak entity (entity lemah). Kebalikan dari entity
lemah adalah strong entity (entity kuat), yaitu kelompok entity yang mempunyai atribut kunci.
Sebagai gambaran, tinjau kelompok entity transaksi dengan atribut nomor-transaksi, tanggal
dan jumlah. Walaupun setiap entity transaksi dapat dibedakan, namun transaksi pada account
yang berbeda dapat menggunakan nomor transaksi yang sama. Jadi kelompok entity ini tidak
mempunyai atribut kunci, oleh karenanya disebut entity lemah. Untuk membedakan entity dari
kelompok entity lemah digunakan atribut yang dinamakan diskriminator. Contoh dari
diskriminator ini misalnya adalah atribut nomor-transaksi untuk kelompok entity transaksi di
atas.


Sejauh ini, pembahasan atribut kunci di atas ditujukan hanya untuk membedakan kelompok
entity. Sekarang bagaimana menentukan atribut kunci kelompok relasi? Atribut kunci
kelompok relasi bisa kita turunkan dari atribut kunci kelompok entity yang membentuknya.
Untuk kasus tertentu, kadang-kadang kita masih memerlukan atribut-atribut lain sebagai
pelengkapnya. Atribut tersebut diambil dari satu atau beberapa atribut yang muncul pada saat
relasi terjadi yang penentuannya tergantung kepada jenis pemetaan dari record-recordnya.
Sebagai contoh, kelompok relasi Jual yang dibentuk oleh kelompok entity Barang dan
Customer mempunyai atribut kunci kode-barang dan kode-customer yang diambil dari atribut
kunci kelompok entity ditambah dengan atribut nomor-faktur yang didapat saat relasi terjadi.
3.5. Pemetaan (Mapping)

Yang dimaksud dengan pemetaan adalah asosiasi (pemasangan) sejumlah entity dengan entity
lainnya dalam kelompok relasi. Pada relasi biner, yaitu relasi antara dua kelompok entity,
pemetaan antara sejumlah entity dapat dibedakan menjadi:
• Satu-ke-satu (one-to-one)
Setiap elemen dari entity pertama tepat dipasangkan dengan satu elemen dari entity
kedua, demikian juga sebaliknya. Contoh: relasi antara Pasien dan Tmp_Tidur pada
masalah medical record.
Abdul T-01
Markum T-02
Kumkum T-03
PASIEN TMP_TIDUR
Gambar 3.2. Contoh Relasi Satu-ke-Satu
• Satu-ke-banyak atau banyak-ke-satu (one-to-many atau many-to-one)

Setiap elemen dari entity pertama dipasangkan dengan beberapa elemen dari entity kedua
dan setiap elemen dari entity kedua tepat dipasangkan dengan satu elemen dari entity
pertama, demikian juga sebaliknya. Contoh: relasi antara Pasien dan Ruangan pada
masalah medical record.
Abdul
R-01
Markum
R-02
Kumkum
PASIEN RUANGAN
Gambar 3.3. Contoh Relasi Satu-ke-Banyak


• Banyak-ke-banyak (many-to-many)
Setiap elemen dari entity pertama dipasangkan dengan beberapa elemen dari entity kedua
dan setiap elemen dari entity kedua juga dipasangkan dengan beberapa elemen dari entity
pertama. Contoh: relasi antara PASIEN dan DOKTER.
Abdul
Basuki
Markum
Paijo
Kumkum
PASIEN DOKTER
Gambar 3.4. Contoh Relasi Banyak-ke-Banyak
Penentuan jenis pemetaan untuk kelompok relasi ini tergantung kepada dunia nyata yang
dimodelkan oleh kelompok relasi tersebut. Jadi untuk kelompok relasi yang satu mungkin kita
dapatkan pemetaan yang berbeda dengan kelompok relasi lainnya
3.6 Diagram E-R

Diagram E-R adalah suatu media untuk menggambarkan model data E-R dalam bentuk
diagram. Simbol-simbol yang digunakan untuk menggambarkan model data E-R dengan
diagram E-R adalah:
1. Entity
Simbol yang digunakan untuk entity berupa kotak persegi panjang, dengan nama entity
ditulis didalamnya.
2. Relationship
Simbol yang digunakan sama dengan simbol keputusan (belah ketupat), dengan hubungan
yang terjadi ditulis didalamnya.
3. Atribut
Simbol yang digunakan berupa lingkaran, dengan nama atribut ditulis didalamnya.
4. Atribut Kunci
Simbol yang digunakan berupa lingkaran sama seperti simbol atribut, akan tetapi atribut
yang akan dijadikan kunci diberi garis bawah.
Gambar 3.5. memperlihatkan contoh diagram E-R untuk menggambarkan hubungan antara
Persons dan Vehicles seperti ditunjukkan pada Gambar 3.1.
Persons Drive Vehicles
Gambar 3.5 Contoh Diagram E-R


Berikut diberikan beberapa hal yang bisa digunakan sebagai petunjuk untuk menggambar
diagram E-R:
1. Kriteria untuk membuat diagram E-R:

• Gunakan diagram E-R sebagai alat komunikasi untuk meyakinkan bahwa seluruh
sistem data sudah dinyatakan dan dideskripsikan secara benar.
• Yakinkan pula bahwa diagram E-R akan menstrukturkan data pada jalan yang
memungkinkan kita untuk mengubahnya menjadi bentuk normal.
2. Penamaan
Gunakan kata benda untuk menamai kelompok entity karena sifanya yang pasif, dan
gunakan kata kerja atau kata sambung (preposisi) untuk menamai kelompok relasi karena
kelompok relasi menyatakan suatu kegiatan. Gambar 3.6. memperlihatkan contoh
bagaimana penamaan untuk kelompok entity dan relasi.
PROJECTS MANAGE MANAGERS
USE
PARTS
(a) Projects
PRICE
FROM SUPPLIERS
CHANGES
TO
PARTS
(b) Price changes
Gambar 3.6. Contoh Penamaan Entity dan Relasi


3. Ada kemungkinan terjadi lebih dari satu relasi diantara dua kelompok entity yang sama,
misalnya seperti contoh yang ditunjukkan oleh Gambar 3.7.
Sample OWNS
interactions
COMPANY
Sample
companies v1
c1 v2 Sample
vehicles
OWNS LEASES c2 v3
c3 v4
v5
VEHICLES Sample LEASES

interactions
Gambar 3.7. Relasi Lebih dari Satu Diantara Dua Kelompok Entity
4. Total sistem tidak diperbolehkan untuk disertakan dalam diagram E-R, dalam arti sistem
yang sedang dibuat model E-Rnya tidak diperkenankan untuk dimunculkan. Gambar 3.8.
memperlihatkan contoh diagram E-R yang salah yang menyertakan total sistem.
PARTS MAKES BUSINESS
SELLS-TO
CUSTOMERS
(a) Incorrect model
PARTS SOLD-TO CUSTOMERS
(b) Correct model
Gambar 3.8. Contoh Penggambaran Diagram E-R yang Salah


3.7 Occurrence Diagram

Occurrence diagram atau diagram kemunculan adalah sebuah diagram semantik yang
menggambarkan bagaimana entity-entity pada model berinteraksi satu sama lainnya. Salah
satu contoh dari occurrence diagram ini ditunjukkan oleh Gambar 3.9.
p1
v1
p2
p3 v2
p4 v3
Gambar 3.9. Contoh Occurrence Diagram
Dari gambar di atas terlihat bagaimana interaksi yang terjadi antara seseorang p1, p2, p3 dan
p4 pada kelompok entity Persons dengan sebuah kendaraan v1, v2 dan v3 pada kelompok
entity Vehicles. Garis yang menghubungkan pasangan entity diantara kedua kelompok entity
tersebut melalui sebuah relasi memperlihatkan orang yang mana yang mengemudi kendaraan
apa, seperti p1 mengemudi v1, p2 juga mengemudi v1, p2 mengemudi v2, dan seterusnya.
Setiap garis yang memperlihatkan interaksi antara sepasang entity adalah sebuah relasi, dalam
hal ini relasi pada kelompok relasi Drive.
3.8 Relasi Tidak Lengkap

Relasi tidak lengkap adalah sebuah relasi yang tidak mengandung semua informasi yang
diperlukan oleh suatu kelompok relasi. Ketidaklengkapan informasi ini dapat diakibatkan oleh
beberapa sebab, dan diantaranya adalah:
• Relasi yang mendasar dari permasalahan tidak disertakan pada model.
• Relasi yang dibuat dalam model tidak menggambarkan sistem informasi dari
permasalahan.
Sebagai contoh, perhatikan Gambar 3.10 (a). Gambar ini memperlihatkan sebuah diagram E-R
yang memodelkan pengiriman yang dikerjakan oleh pengemudi dengan menggunakan
kendaraan truk. Relasi Use memodelkan Drivers yang mengemudi Trucks, sedangkan relasi
For memodelkan Trucks yang digunakan untuk mengirim Deliveries.
Occurrence diagram pada Gambar 3.10 (b) memperlihatkan bahwa Jill dan Richard keduanya
menggunakan Ferrari. Diagram ini pun memperlihatkan bahwa kendaraan Ferrari digunakan
untuk mengirimkan kiriman D2 dan D3. Jika ditanyakan siapa yang mengirim kiriman D2 atau


D3, maka jawaban yang didapat berdasarkan occurrence diagram tersebut tidak bisa kita
berikan, karena bisa Jill bisa juga Richard (informasi jadi bias).
N M 1 N
DRIVER USE TRUCKS FOR DELIVERIES
(a) E-R Diagram
Jill Ford • D1
• •
Richard Ferrari • D2
• •
• D3
(b) Occurrence Diagram
Gambar 3.10 Contoh Relasi Tidak Lengkap
Diagram E-R yang benar dengan informasi yang sama untuk masalah di atas ditunjukkan oleh
Gambar 3.11 (a). Pada diagram yang baru ini ada sebuah relasi Make antara Drivers dan
Deliveries, dan sebuah relasi Using antara Trucks dan Deliveries. Relasi Using sama artinya
dengan relasi For pada diagram dalam Gambar 3.10 (a), sedangkan relasi Make menyatakan
Deliveries yang dikerjakan oleh Drivers. Dari occurrence diagram pada Gambar 3.11 (b), kita
bisa mengetahui bahwa jika Richard mengirimkan kiriman D2 dan D3 dengan Ferrari, maka
kita mengetahui bahwa Richard menggunakan Ferrari.
N M 1 N
DRIVER MAKE DELIVERIES USING TRUCKS
(a) E-R Diagram
Jill
• D1 • Ford
Richard •
D2
• • • Ferrari
D3
•
(b) Occurrence Diagram
Gambar 3.11 Konversi untuk Relasi Tidak Lengkap


3.9 Contoh Pembuatan Model Data E-R

3.9.1 Definisi Masalah
Suatu bengkel kendaraan bermotor memberikan jasa layanan (service) perawatan, perbaikan
dan penjualan suku cadang. Untuk setiap kendaraan yang memanfaatkan jasa bengkel tersebut,
pengerjaan perawatan atau perbaikan kendaraannya dilakukan oleh seorang montir. Kendaraan
yang dirawat atau diperbaiki mungkin membutuhkan satu atau beberapa suku cadang, dan
pembayaran untuk penggunaan suku cadang tersebut disatukan dengan biaya perawatan atau
perbaikannya. Pembayaran dilakukan di Bagian Kasir setelah layanan selesai dikerjakan, dan
sebagai tanda buktinya Bagian Kasir akan membuat kuitansi pembayaran.
Bagaimana bentuk diagram E-R yang harus dibuat untuk memodelkan data yang terlibat pada
masalah jasa layanan kendaraan bermotor tersebut, sehingga pemilik bengkel bisa
mendapatkan informasi tentang:
• jumlah kas yang diterima setiap hari dari jasa layanan dan penjualan suku cadang.
• pemakaian suku cadang.
• jumlah upah mingguan yang harus dibayarkan kepada setiap montir.
Beberapa asumsi dan batasan untuk masalah di atas:

• Proses pengolahan data penjualan suku cadang hanya ditujukan untuk kendaraan yang
meminta layanan perawatan atau perbaikan, dan tidak untuk penjualan lepas.
• Stok suku cadang yang dibutuhkan kendaraan selalu tersedia.
• Upah untuk setiap montir dihitung dari banyaknya pengerjaan layanan yang
dilakukannya.
• Seorang montir dapat mempunyai keahlian tertentu untuk satu atau beberapa jenis
layanan tertentu dengan upah tertentu pula.
• Pembayaran untuk jasa layanan yang diminta dan penjualan suku cadang dilakukan
secara tunai.
3.9.2 Penyelesaian Masalah

1. Identifikasi Masukan
Data yang menjadi masukan (input) untuk masalah jasa layanan kendaraan bermotor ini
adalah dokumen bukti pembayaran (kuitansi). Item-item data yang ada pada dokumen
tersebut adalah:
• nomor bukti pembayaran
• tanggal pembayaran
• identitas kendaraan dan pemiliknya
• identitas montir
• jenis layanan yang diberikan
• suku cadang yang dijual
• jumlah biaya yang harus dibayar


Secara fisik, tata letak dokumen bukti pembayaran ditunjukkan oleh gambar berikut ini:
BUKTI PEMBAYARAN SERVICE KENDARAAN
No.Bukti : Montir:
Tanggal :
Kendaraan:
--------------------------------------------------------------
No. Jenis Service/Spare Part Banyak Harga Jumlah
==============================================================
--------------------------------------------------------------
Total Rp.
--------------------------------------------------------------
2. Identifikasi Keluaran
Informasi yang menjadi keluaran adalah laporan yang diminta pemilik bengkel, yaitu:
• Laporan penerimaan kas:
– dari jasa layanan
– dari penjualan suku cadang
– dari keduanya
• Laporan pemakaian suku cadang
• Daftar upah mingguan untuk pembayaran montir
3. Identifikasi Entitas
Berdasarkan analisis (pengamatan) terhadap dokumen yang menjadi sumber data
masukan, entitas yang terlibat dapat diidentifikasi sebagai berikut:
• KENDARAAN
Mewakili objek kendaraan yang mendapatkan layanan.
• MONTIR
Mewakili objek orang yang mengerjakan layanan.
• LAYANAN atau SERVICE
Mewakili proses pengerjaan layanan.
• JENIS LAYANAN
Mewakili objek jenis-jenis layanan yang dapat diberikan.
• SUKU CADANG
Mewakili objek suku cadang yang dijual.
4. Identifikasi Hubungan antar Entitas

Hubungan antar entitas yang terlibat adalah:
• LOG, yaitu hubungan untuk entitas kendaraan, montir dan layanan
• UNTUK, yaitu hubungan untuk entitas layanan dan jenis layanan
• BUTUH, yaitu hubungan untuk layanan dan suku cadang
• KEAHLIAN, yaitu hubungan untuk montir dan jenis layanan


3.9.3 Pembuatan Diagram E-R
Berdasarkan hasil identifikasi entitas dan hubungan antar entitas, maka diagram E-R untuk
masalah jasa layanan kendaraan bermotor adalah:
Kode Nama Upah
m n
MONTIR KEAHLIAN
Tanggal
NoBukti Jumlah
m Kode
1 n m n JENIS
KENDARAAN LOG SERVICE UNTUK Nama
LAYANAN
Biaya
NoPol Pemilik m
Jenis BUTUH Banyak
n
PartNo
SUKU
Descr.
CADANG
Price
Dari diagram E-R tersebut, informasi yang diinginkan dapat diperoleh dengan cara sebagai
berikut:
• Laporan penerimaan kas
Informasi diperoleh dari entitas SERVICE.
• Laporan penerimaan kas dari jasa layanan
Informasi diperoleh dari hubungan antar entitas UNTUK, entitas SERVICE dan JENIS
LAYANAN.
• Laporan penerimaan kas dari penjualan suku cadang
Informasi diperoleh dari hubungan antar entitas BUTUH, entitas SERVICE dan SUKU
CADANG.
• Laporan pemakaian suku cadang
Informasi diperoleh dari hubungan antar entitas BUTUH, dan entitas SUKU CADANG.
• Daftar upah mingguan untuk pembayaran montir
Informasi diperoleh dari hubungan antar entitas LOG, UNTUK, KEAHLIAN, dan entitas
MONTIR dan JENIS LAYANAN.


4
Model
Data Relasi
M odel data relasi adalah suatu model logika database yang menggambarkan entity
dan relasi dalam bentuk tabel-tabel yang disebut relasi. Kelompok entity
digambarkan dengan suatu relasi yang kolom-kolomnya menunjukkan identifikasi
dari entity tersebut. Demikian juga untuk relasi, kolom-kolomnya menunjukkan
identifikasi dari entity-entity yang berhubungan, dan informasi tentang hubungan
tersebut. Sebagai contoh, tinjau masalah akademik. Entity yang terlibat didalamnya
misalnya adalah DOSEN, MAHASISWA dan KULIAH. Relasi yang terjadi antar entity
tersebut misalnya MENGAJAR untuk entity DOSEN-KULIAH dan MENGAMBIL untuk
entity MAHASISWA-KULIAH. Gambarannya:
Dosen# Nm_Dosen <data lain> Dosen# Kuliah# <data lain>

D-001 Slamet ... D-001 K-001
D-002 Sanwani ... D-001 K-002
D-003 Paijo ... D-001 K-004
DOSEN D-002 K-002
D-003 K-003
NRP Nm_Mhsiswa <data lain> D-003 K-004
96.761 Abdul ... MENGAJAR
96.671 Markum ...
96.212 Kumkum ... NRP Kuliah# <data lain>
96.178 Basuki ... 96.761 K-001 ...
96.203 Sastro ... 96.671 K-001 ...
MHSISWA 96.671 K-003 ...
96.671 K-004 ...
Kuliah#Mata Kuliah <data lain> 96.212 K-002 ...
K-001 Algoritma ... 96.212 K-003 ...
K-002 Analisa Sistem ... 96.178 K-001 ...
K-003 Sistem ... 96.203 K-001 ...
Database
K-004 Struktur Data ... 96.203 K-004 ...
KULIAH MENGAMBIL
Gambar 4.1. Contoh Data Model Relasi

Model Data Relasi Halaman IV-1

4.1. Struktur Model Data Relasi

Skema Relasi
Skema relasi ialah kumpulan nama-nama atribut dari suatu relasi (deskripsi suatu
relasi).
Contoh: R1( nama, alamat, usia, tinggi )
Skema Database
Skema database pada model data relasi adalah kumpulan dari skema relasi yang
mendeskripsikan database model relasi.
Contoh: MHS( NRP, Nama, Alamat, ... )
DOSEN( NIP, Nm_Dsn, Alm_Dsn, ... )
KULIAH( Kode, Nm_Klh, SKS, ... ) skema database
D-K( NIP, Kode, Hari, Jam, ... )
M-K( NRP, Kode, Nilai, ... )
4.2. Transformasi Bentuk E-R menjadi Model Relasi

Yang harus diperhatikan pada saat transformasi bentuk E-R ini adalah:
1. Entity pada bentuk E-R berubah menjadi relasi dan key atribut entity menjadi
atribut kunci relasi.
2. Relationship pada bentuk E-R berubah menjadi relasi dengan syarat semua
atribut kunci relationship akan menjadi key atribut relasi. Sebagai contoh,
misalkan diketahui model E-R dari dua entity MAHASISWA dan KULIAH dengan
relasi AMBIL sebagai berikut:
m n
MAHASISWA AMBIL KULIAH
Jika atribut dari MAHASISWA adalah NRP, nama mahasiswa, jenis kelamin, dan
alamat, sedangkan atribut KULIAH adalah kode kuliah, nama kuliah dan SKS,
maka skema relasinya adalah:
MAHASISWA( NRP, Nama, Kelamin, Alamat )

KULIAH( Kode, Nm_Kuliah, SKS )
AMBIL( NRP, Kode, Semester, Tahun )
Transformasi bentuk E-R menjadi skema relasi bertujuan untuk menyederhanakan

bentuk penggambaran entity dan relasi, dan juga untuk lebih memperlihatkan
keterkaitan antar data pada entity dan relasi tersebut (diwakili oleh duplikasi data
pada relasi).


4.3 Operasi pada Model Data Relasi

Operasi terhadap satu atau lebih relasi dilakukan untuk mendapatkan informasi yang
dikehendaki. Operasi-operasi yang ada pada model data relasi dapat dibedakan
menjadi operasi dasar dan operasi suplemen.
Operasi Dasar
1. Union (∪)
Operasi union dari relasi R1 dan R2 ditulis R1 ∪ R2 adalah kumpulan semua
tuple-tuple (baris) yang dimiliki oleh R1 dan atau R2. Operasi union hanya dapat
dilakukan terhadap relasi-relasi yang mempunyai ariti (baris) yang sama.
Contoh: COLORS( color, colorcode )

FASHION( color, colorcode )
Colors: Colors ∪ Fas hion

color colorcode color colorcode
Red 93471 Red 93471
White 93474 White 93474
Blue 93476 Blue 93476
Magenta 93479
Fashion: Blue 93477
color colorcode
Red 93471
Magenta 93479
Blue 93477
2. Substraksi (Set Diference)

Operasi subtraksi relasi R1 oleh R2 ditulis R1 − R2 adalah kumpulan semua tuple
yang merupakan anggota R1 tetapi bukan anggota R2. Persyaratan operasi ini
sama dengan persyaratan operasi union.
Contoh: Lihat relasi R1 dan R2 sebelumnya.
Colors−Fash ion
color colorcode
White 93474
Blue 93476


3. Seleksi (σ)
Operasi seleksi terhadap relasi R1 dengan kondisi k ditulis σk(R1) adalah
kumpulan tuple dalam R1 yang memenuhi kondisi k. Kondisi k adalah formula
yang terdiri dari:
• Operan-operan yang merupakan konstanta atau nomor urut atribut atau pun
nama atribut dari relasi yang bersangkutan.
• Operator-operator pembanding seperti <, =, >, ≤, ≠, ≥
• Operator-operator logika seperti ∧ (dan), ∨ (atau), ¬ (tidak)
Contoh: R1 merupakan relasi sbb.:
A B C
a b c
d a f
e b d
R = σB=“b”(R1) R = σ(B=“b”) ∧ (C=“c”)(R1)

A B C A B C
a b c a b c
c b d
4. Projeksi (Π)
Operasi projeksi terhadap relasi R1ditulis Πa1,a2,...(R1) adalah kumpulan semua
tuple R dengan arity a1, a2, ...
Contoh: Lihat relasi R1 pada operasi seleksi di atas.
R = ΠA,C(R1)
A C
a c
d f
e d
5. Cartesian Product ( X )
Jika arity R1 adalah k1 dan R2 adalah k2, maka operasi cartesian product dari R1
dan R2 ditulis R1 X R2 adalah kumpulan semua tuple-tuple dengan arity (k1+k2).
Contoh: R1 R2
A B C D E F
a b c b g a
d a f d a f
c b d


R = R1 X R2
A B C D E F
a b c b g a
a b c d a f
d a f b g a
d a f d a f
c b d b g a
c b d d a f
Operasi Suplemen
Operasi suplemen pada dasarnya merupakan operasi yang dapat diturunkan dari
beberapa operasi dasar, yaitu:
1. Irisan (∩)
Operasi irisan dari relasi R1 dan R2 ditulis R1 ∩ R2 adalah kumpulan semua
tuple-tuple yang merupakan anggota R1 dan R2.
Contoh: Lihat relasi R1 dan R2 pada operasi union.
Colors∩Fash ion
color colorcode
White 93474
Persyaratan operasi ini sama dengan persyaratan operasi union.
2. Join (│X│)
Jika R1 dan R2 suatu relasi dengan n1 adalah arity R1 dan n2 adalah arity R2,
operasi join untuk R1 dan R2 dengan atribut yang dibandingkan a1 dan a2 ditulis
R1 │X│ R2, adalah kumpulan tuple t dengan arity sama dengan m = (n1 + n2 ) - 1,
dimana m merupakan arity dari t dan θ adalah operator pembanding.
Contoh: R1 R2
A B C X Y Z
a1 b1 c1 a2 n1 n2
a1 b2 c2 a1 b1 b3
a2 b2 c3
R = R1 │X│ R2
A=X
A B C Y Z
a1 b1 c1 b1 b3
a1 b2 c2 b1 b3
a2 b2 c3 n1 n2


3. Natural Join
Analog dengan penulisan join, tapi tanpa penulisan kondisi, yaitu R1 │X│ R2.
Contoh: SUPPLY PART_SKILL

S_Id P_Id Qty Ass. Type P-Id No_Req Skill_Req
s1 p1 160 0381 body p1 10 machinist
s1 p3 60 0381 body p2 12 machinist
s2 p2 140 0381 body p4 22 welder
s2 p3 50 0381 fender p1 26 machinist
s2 p4 90 0381 fender p3 26 welder
s4 p4 100
SUPPLY │X│ PART_SKILL

Ass. Type P_Id S-Id No_Req Skill_Req Qty
0381 body p1 s1 10 machinist 160
0381 body p2 s2 12 machinist 140
0381 body p4 s2 22 welder 90
0381 body p4 s4 22 welder 100
0381 fender p1 s1 26 machinist 160
0381 fender p3 s1 26 welder 60
0381 fender p3 s2 26 welder 50


5
Model Data
Jaringan (Network)
B erbeda dengan model data relasi yang merepresentasikan data dan relasi antar
datanya dalam bentuk kumpulan tabel, data pada model data jaringan
(network) direpresentasikan dalam bentuk kumpulan record sedangkan relasi antar
datanya direpresentasikan dalam bentuk links atau pointer. Model data jaringan
didasarkan pada konsep directed graph, dimana node pada graph dianalogikan
sebagai kumpulan record sedangkan arc dianalogikan sebagai link.
5.1. Pengertian Dasar

Model data jaringan terdiri dari kumpulan record yang dihubungkan satu sama
lainnya melalui link. Setiap record pada kumpulan record tersusun dari
sekumpulan field atau atribut dimana masing-masing field atau atribut tersebut
berisi hanya satu nilai data. Sebagai gambaran, tinjau sebuah database yang
berhubungan dengan masalah akademik. Misalkan pada database tersebut
diketahui bahwa dosen dengan nama Abdul mengajar kuliah Algoritma, Markum
mengajar kuliah Struktur Data dan Database, dan Kumkum mengajar kuliah
Matematika, maka penggambaran model data jaringannya bisa dinyatakan sebagai
berikut:
D1 Abdul K1 Algoritma
K2 Struktur Data
D2 Markum
K3 Database
D3 Kumkum K4 Matematika
Gambar 5.1. Contoh Model Data Jaringan

Model Data Jaringan Halaman V-1

Dari Gambar 5.1. tersebut kita bisa melihat dua kumpulan record, yaitu Dosen dan
Kuliah. Kumpulan record Dosen tersusun dari field Kd_Dsn dan Nm_Dsn,
sedangkan Kuliah tersusun dari field Kd_Klh dan Nm_Klh. Record pertama dari
kumpulan record Dosen dihubungkan oleh link dengan record pertama dari
kumpulan record Kuliah untuk menyatakan dosen siapa mengajar kuliah apa.
Demikian juga untuk record kedua dengan record kedua dan ketiga, serta record
keempat dengan record ketiga dari kumpulan record Kuliah ke kumpulan record
Dosen.
Kumpulan record pada model data jaringan biasanya disebut record type sedangkan
link yang menghubungkannya disebut set type. Record type bisa dianggap sebagai
entity pada model data E-R, sedangkan set type bisa dianggap sebagai relasi antar
entitynya. Untuk setiap record type yang pendefinisiannya relatif terhadap set type,
dikenal istilah owner (pemilik) dan member (anggota). Owner adalah record type
dominan sedangkan member adalah record type sub-ordinat. Untuk contoh
database pada Gambar 5.1. di atas, record type owner adalah dosen sedangkan
record type member adalah kuliah.
Asosiasi yang diperkenankan antara record type owner dengan record type member
adalah asosiasi satu-ke-satu (1-1) dan satu-ke-banyak (1-n atau n-1). Artinya,
untuk satu record pada record type owner, terdapat satu atau beberapa record pada
record type member. Dengan perkataan lain, untuk satu kejadian (occurrence) dari
record type owner ada satu atau beberapa kejadian pada record type member.
Asosiasi banyak-ke-banyak (m-n) harus ditransformasikan menjadi (1-n) (n-1)
untuk menghindari record dengan panjang berubah-ubah (variabel-length record)
pada saat implementasinya.
Model data jaringan populer pada sekitar tahun 1960-an sampai 1970-an. Paket
DBMS yang digunakan pada saat itu diantaranya adalah:
• DataSaab, buatan Saab Scania AB digunakan pada mesin SAAB D22/D23

• DBMS10, buatan DEC digunakan pada mesin DEC PDP-10
• IDS, buatan Honeywell Inf. System digunakan pada mesin H200, H60, H6000
• Total, buatan Cincom Inc. digunakan pada mesin IBM 360/370
• Codasyl Conference Data System Language) buatan DataBase Task Group
Penjelasan berikut dari model data jaringan ini akan disampaikan dengan merujuk
pada paket DBMS Codasyl buatan DBTG.
5.2. Diagram Struktur Data

Model data jaringan mengkaitkan data dari entity-entity pada suatu enterprise
kedalam suatu jaringan (network). Notasi grafis untuk penyajian model data
jaringan ini menggunakan model diagram struktur data dari C.W. Bachman.
Diagram struktur data adalah sebuah skema yang mempunyai kegunaan seperti
diagram E-R, yaitu untuk merepresentasikan struktur logika dari database model


jaringan secara keseluruhan. Diagram struktur data mempunyai dua komponen

dasar. Kedua komponen dasar tersebut adalah:
• Kotak, yaitu simbol untuk menggambarkan record type atau entity. Record
type yang digambarkan dengan simbol ini bisa dikomposisikan menjadi 0, 1
atau lebih atribut-atribut recordnya.
• Anak panah, yaitu simbol untuk menggambarkan link antara dua atau lebih
record type dan digunakan untuk menyajikan suatu set type.
Cara untuk memahami pembuatan diagram struktur data ini adalah dengan
melihat bagaimana suatu diagram E-R diubah menjadi diagram struktur data yang
sesuai. Sebagai contoh, perhatikan diagram E-R pada Gambar 5.2. berikut ini yang
merepresentasikan hubungan antara dua kelompok entity, yaitu Dosen dan Kuliah
melalui satu relasi Mengajar. Relasi Mengajar adalah relasi biner satu-ke-banyak
dengan atribut-atribut KdDsn dan KdKlh yang diturunkan dari atribut kunci kedua
kelompok entity.
Diagram E-R tersebut menunjukkan bahwa seorang dosen bisa mengajar beberapa
mata kuliah dan satu mata kuliah diajar oleh satu orang dosen. Penggambaran
diagram struktur data yang sesuai dengan diagram E-R. Sebagai contoh, misalkan
dosen Abdul mengajar kuliah Algoritma, Markum mengajar kuliah Struktur Data
dan Database, sedangkan Kumkum mengajar kuliah Matematika
1 DOSEN record type
ST set type
n KULIAH record type
Gambar 5.2. Diagram Struktur Data DOSEN-KULIAH
Pendefinisian suatu objek dari record type dideskripsikan dalam record. Misalkan
kita punya suatu jaringan sebagai berikut:
RT1 RT2 RT3
RT4
Gambar 5.3. Contoh Skema Jaringan


maka secara umum diseskripsikan sebagai berikut:
RT : RT1
{ atribut}
ST : ST1
owner : RT1
member : RT4
dan seterusnya.
Implementasi Secara Fisik

Implementasi secara fisik yang sederhana dari model jaringan adalah dengan list
linear. Contoh untuk record type RT2 sebagai owner dan RT4 sebagai member
sebagai berikut:
rt21 rt22 rt23 record type

RT2
set type ST2
rt41 rt42 rt43 rt44 rt45 record type

RT4
Gambar 5.4. Contoh Implementasi Secara Fisik
Dalam model jaringan di atas, untuk menyatakan hubungan antara record yang
diwakili oleh list rt21 dengan record yang diwakili oleh list rt24 tidak dilakukan
dengan membuat pointer yang menunjuk pada rt42 dari rt21. Jika dilakukan
dengan cara tersebut, maka akan menyebabkan terjadinya jumlah pointer yang
variabel sehingga akan mengakibatkan panjang record yang variabel pula.
rt21 rt22 rt23 record type

RT2
set type ST2
rt41 rt42 rt43 rt44 rt45 record type

RT4
Gambar 5.5. Contoh Implementasi Secara Fisik yang Salah
Transformasi Asosiasi (m-n) Menjadi (1-n)(n-1)

Untuk transformasi asosiasi (m-n) menjadi (1-n)(n-1) didalam model jaringan,
digunakan virtual record type. Pada prinsipnya virtual record type merupakan
record type secara fisik, tetapi dalam implementasinya hanya berisi pointer. Setiap
record dalam record type akan merepresentasikan 1 asosiasi.


• b1
a1 •
• b2
a2 •
• b3
a3 •
• b4
Gambar 5.6. (a) Transformasi (m-n) Menjadi (1-n)(n-1)
c1
• b1
c2
a1 •
c3 • b2
a2 • c4
• b3
a3 • c5
c6 • b4
Gambar 5.6. (b) Hasil Transformasi (m-n) Menjadi (1-n)(n-1)
Representasi secara logika untuk hasil transformasi di atas dengan diagram

struktur data:
RTA RTB
record type A : owner

record type B : owner
virtual record type C : member
VRTC
Gambar 5.7. Representasi Logika Transformasi (m-n) Menjadi (1-n)(n-1)
Fungsi virtual record type dalam model jaringan adalah untuk menghindari adanya
duplikasi record.
a1 a2 a3
b1 b2 b3 b4 b1 b4


Transformasi Model Data E-R Menjadi Model Jaringan

1. Untuk asosiasi (m-n)
A RTA
m 1
ST1
n
R1 VRTC
n
n ST2
1
B RTB
2. Untuk asosiasi (1-n) atau (1-1)
1 RTA
1
R2 ST1
1, n
1, n RTB
B
Contoh:
Hubungan antara aircraft dengan pilot
Aircraft Aircraft
m 1
ST1
n
R1 VRTC
n
n ST2
1
Pilot Pilot


• p1 (a1, p1)
a1 • (a1, p2)
• p2 (a1, p3)
a2 •
(a2, p2)
• p3 (a2, p3)
a3 •
(a3, p1)
Aircraft Pilot
a1 a2 a3 RTa/c
C1 C2 C3 C4 C5 C6 VRTR1
p1 p2 p3 RTpilot
Gambar 5.8. Contoh Representasi Fisik Hubungan Aircraft-Pilot
5.3. Operasi Pada Model Data Jaringan

Operasi-operasi yang dapat dilakukan pada model data jaringan, sepert insert,
delete, search atau update mengikuti konsep navigasi. Artinya, setiap akses akan
dilakukan dengan mengikuti pointer.
1. Insert
Mencakup dua macam insert, yaitu:
a. Insert asosiasi (tanpa penambahan record)
b. Insert record
2. delete
Pada operasi ini yang dihapus adalah asosiasinya.
Database model jaringan (dan model hirarki) merupakan suatu basis data yang
prosedural, dalam arti untuk mendapatkan apa yang diinginkan terlebih dahulu
pemakai harus mendeskrispsikan bagaimana cara mendapatkannya (konsep
navigasi). Berbeda dengan basis data yang non-prosedural, misal model relasi, apa
yang diinginkan pemakai, bagaimana cara mendapatkannya, tidak perlu
dinyatakan.


5.4. Model Data Jaringan vs Model Relasi

Perbedaan Antara Model Jaringan dan Model Relasi
1. Asosiasi yang ada pada model data jaringan (1-1) dan (1-n), sedang pada model
data relasi selalin asosiasi (1-1) dan (1-n), juga asosiasi (n-m).
2. Asosiasi dalam model jaringan diimplementasikan secara fisik dengan pointer,
sedangkan pada model relasi dengan duplikasi data.
Keuntungan dan Kerugian Model Jaringan Dibandingkan Model Relasi

1. Keterjaminan informasi
Misalkan dalam model jaringan satu pointer rusak, maka otomatis si member
akan kehilangan owner atau dengan perkataan lain semua record member
akan hilang (tidak dapat diakses). Sedangkan dalam model relasi, hanya
record yang rusak saja yang hilang.
2. Jika dalam model relasi terjadi perubahan nilai 1 bit (untuk pointer), maka
user masih dapat menginterpretasikannya. Sedangkan dalam model jaringan
relatif tidak dapat diinterpretasikan, karena berupa angka-angka.
3. Response time lebih cepat dibanding model data relasi.
4. tidak banyak menggunakan tempat penyimpanan.
5. Didalam model jaringan, jika terjadi/timbul atribut baru maka atribut tersebut
harus diidentifikasikan pada record type yang baru (integritas data).


6
Model Data
Hirarki
6.1. Pengertian Dasar
Model data hirarki adalah suatu model data yang tersusun dari record-record yang
diorganisasikan sebagai kumpulan pohon. Seperti pada model data jaringan, pada
model data ini data direpresentasikan sebagai kumpulan record sedangkan
hubungan antar datanya direpresentasikan oleh suatu links. Sebagai contoh, lihat
masalah akademik untuk hubungan antara data DOSEN dan KULIAH.
root
D1 D2 D3
K1 K2 K3 K4 K5
Gambar 6.1. Contoh Model Data Hirarki Dosen-Kuliah
Skema (diagram struktur) untuk contoh model data hirarki di atas adalah:
DOSEN simpul induk
KULIAH simpul anak (dependent)
Gambar 6.2. Skema Model Data Hirarki Dosen-Kuliah
Jika dosen D2 dan D3 adalah pembimbing akademik kelas MIF-3 dan MIF-6, maka
skemanya menjadi:
DOSEN
KULIAH KELAS
Gambar 6.3. Skema Model Data Hirarki Dosen-Kuliah-Kelas


Model Data Hirarki Halaman VI-1

Penggambaran model data hirarkinya:
root
D1 D2 D3
K1 K2 K3 K4 K5 MIF-3 MIF-6
Gambar 6.4. Model Data Hirarki Dosen-Kuliah-Kelas
Asosiasi pada model data hirarki selalu (1-1) atau (1-n). Asosiasi (m-n) harus
ditransformasikan menjadi (1-n) dengan duplikasi data. Sebagai contoh, misalkan:
• mahasiswa M1 mengambil kuliah K1 dan mendapat nilai C
• mahasiswa M1 mengambil kuliah K2 dan mendapat nilai B
• mahasiswa M2 mengambil kuliah K1 dan mendapat nilai B
• mahasiswa M3 mengambil kuliah K2 dan mendapat nilai A
maka penggambaran model data hirarkinya adalah:
root
M1 M2 M3
C B B A
K1 K2 K1 K2
Gambar 6.5. (a) Model Data Hirarki Mahasiswa-Kuliah
root
K1 K2
C B B A
M1 M1 M2 M3
Gambar 6.5. (b) Model Data Hirarki Kuliah-Mahasiswa



Jika memanfaatkan virtual record:
root
M1 M2 M3
C B B A
root
K1 K2
C B B A
Gambar 6.6. Model Data Hirarki Kuliah-Mahasiswa dengan Virtual Record
Secara skematis:
MHS KULIAH
AMBIL AMBIL
Gambar 6.7. Skema Model Data Hirarki Mahasiswa-Kuliah dengan Virtual Record
6.2. Implementasi Secara Fisik

Secara fisik, model data hirarki diimplementasikan dengan struktur data list
berkait (linked list) atau dengan tabel-tabel yang satu sama lainnya dihubungkan
dengan pointer. Sebagai gambaran, implementasi secara fisik untuk model data
hirarki seperti yang ditunjukkan oleh Gambar 6.1. adalah:


M1 M2 M3
K1 K2 K3 K4 K5
Gambar 6.8. Contoh Implementasi Fisik Model Data Hirarki
6.3. Operasi Pada Model Data Hirarki

Operasi pada model data hirarki pada dasarnya hanya terdiri dari operasi-operasi
sebagai berikut:
• penelusuran (traversal) untuk proses retrieval informasi

• penyisipan node untuk proses penambahan dan penyisipan data
• penghapusan node untuk proses penghapusan data
dimana operasi tersebut dapat terlaksana jika representasi model data hirarkinya
disajikan dalam bentuk struktur pohon biner.


7
Perancangan
Database
P erancangan database pada dasarnya merupakan proses untuk

merepresentasikan dunia nyata (real world) yang dikehendaki kedalam sistem
komputer, sehingga mudah dimengerti oleh pemakai dengan mempertimbangkan
kemudahan implementasi dan pemrosesannya. Perancangan database dikerjakan
setelah proses analisis dokumen, yang merupakan salah satu kegiatan dari
perancangan sistem, selesai dilaksanakan.
Database yang dirancang harus memiliki kemampuan untuk memberikan informasi

yang diinginkan mengenai dunia nyata yang diwakilinya. Dengan demikian data
tentang dunia nyata tersebut harus diorganisasi kemudian direpresentasikan dalam
komputer, sehingga dapat diproses dengan efektif dan efisien.
Beberapa tujuan yang ingin dicapai dari perancangan database diantaranya adalah:
• memenuhi kebutuhan informasi pada saat ini dan yang akan datang
• kemudahan pengembangan sesuai dengan perkembangan organisasi
• penerapan mekanisme pengamanan data
Untuk mencapai tujuan tersebut, ada dua tahapan proses yang harus dikerjakan
pada saat perancangan database ini, yaitu perancangan logika dan perancangan
fisik.
7.1. Perancangan Logika Database

Perancangan logika database merupakan proses pendefinisian entity dan relasi
(relationship) dari dunia nyata yang dirancang, berdasarkan kebutuhan informasi
dan pengolahan data dari organisasi yang bersangkutan. Entity adalah sesuatu
(sekumpulan objek) yang dapat diidentifikasi dan dibedakan. Relasi adalah
hubungan yang terjadi antara kelompok-kelompok entity.
Perancangan logika database terdiri dari dari dua tahapan proses. Pertama,
perancangan model konseptual atau model enterprise dari dunia nyata yang
dirancang, disebut tahap pendeskripsian semantik. Kedua, perancangan model
logika yaitu proses dekomposisi model konseptual untuk memperoleh model logika,
disebut tahap dekomposisi skema basis data. Sasaran yang ingin dicapai dari

Perancangan Database Halaman VII-1

perancangan logika database ini adalah fleksibilitas model data yang dihasilkan dan
efisiensi pengimplementasiannya dalam komputer. Model data adalah suatu alat
abstrak untuk merepresentasikan data dari dunia nyata yang akan
diimplementasikan dalam sistem komputer tanpa tergantung kepada software
maupun bentuk dan jenis komputer itu sendiri.
7.1.1. Perancangan Model Konseptual atau Enterprise

Perancangan model konseptual atau enterprise bertujuan untuk menentukan entity
dan relasi yang terbentuk diantaranya. Model konseptual yang dikembangkan ini
harus bisa menyajikan semua entity dan relasi tanpa tergantung pada software
DBMS, perangkat komputer yang digunakan, maupun model fisik data dalam
media penyimpanan. Selain itu, model konseptual ini pun harus bebas dari
aplikasi-aplikasi pemrosesan data secara individual.
Penjelasan berikut akan membahas perancangan model konseptual dengan

pendekatan relasional, tapi bukan berarti bahwa sistem database yang akan
dibangun adalah sistem database model relasional. Hal ini dikarenakan metode
pendekatan ini dapat juga diterapkan pada model-model data lainnya (jaringan
maupun hirarki) dengan beberapa penyesuaian pada tahap pelaksanaannya.
7.1.2. Langkah-langkah Perancangan Model Konseptual

Untuk menentukan entity dan relasi pada perancangan model konseptual ini,
terlebih dahulu diperlukan analisis data yang didasarkan pada dokumen yang
menjadi dasar dari kebutuhan pengolahan data, dan eksistensi aplikasi-aplikasi
yang berlaku terhadap data pada dokumen tersebut. Hasil dari analisis data ini
nantinya digunakan sebagai dasar untuk mengerjakan proses selanjutnya, yaitu:
1. Menentukan entity yang terlibat pada permasalahan yang akan dibuat sistem
databasenya dengan melihat data atau fakta pada dokumen yang ada. Caranya:
a. Tentukan urut-urutan kejadian dari permasalahan dengan memperhatikan
batasan waktu;
b. Gambarkan urut-urutan kejadian tersebut dalam bentuk model kejadian
(event model);
c. Tentukan objek atau pelaku, baik pelaku aktif maupun pasif, di setiap
kejadian;
d. Kelompokkan (generalisasi) objek atau pelaku tersebut sesuai dengan sifat
dan fungsinya. Calon entity adalah kelompok objek hasil generaliisasi yang
mempunyai sifat dan fungsi yang sama.
Cara lain adalah dengan melakukan generalisasi item-item data yang ada pada
kamus data hasil analisis sesuai dengan sifat dan fungsinya. Untuk cara ini,
calon entity adalah hasil akhir generalisasi dari item-item data tersebut.
2. Menentukan atribut kunci dan atribut lainnya dari tiap entity berdasarkan
dokumen hasil analisis.
3. Menentukan hubungan (relasi) antar entity yang terlibat berikut jenis relasinya
dengan memperhatikan kebutuhan informasi dari sistem.
4. Menggambarkan entity dan relasinya dalam bentuk diagram E-R.


7.1.3. Perancangan Model Logika

Perancangan model logika adalah proses untuk mengambarkan hasil perancangan
model konseptual ke dalam model logika database. Model logika database yang bisa
digunakan untuk menyatakan hasil perancangan model logika ini adalah model
relasi, model jaringan dan model hirarki. Penggambaran model logika ini ditentukan
oleh software DBMS yang nantinya akan digunakan. Urutan prosedur untuk
perancangan model logika dengan pendekatan terhadap model relasi adalah:
1. Transformasi bentuk model E-R menjadi model relasi.

2. Normalisasi skema relasi untuk mendapatkan skema relasi optimal.
Proses dekomposisi (pemecahan) skema relasi untuk menghilangkan anomali-
anomali (penyimpangan) yang dikandung oleh skema relasi tersebut, yaitu:
3. Buat tabel dari skema relasi hasil normalisasi.
7.2. Perancangan Fisik Database

Perancangan fisik database merupakan proses untuk mengimplementasikan hasil
perancangan logika kedalam sistem komputer secara fisik. Perancangan fisik ini
sangat tergantung kepada software DBMS yang dipilih.
1. Menentukan struktur untuk setiap tabel, meliputi nama field, jenis, lebar dan
field kuncinya
2. Menentukan nama database dan nama masing-masing tabel, dan lokasi
dimana database akan disimpan (drive, directory).
3. Menghitung perkiraan space yang dibutuhkan,
a. untuk seluruh tabel
St = jumlah tabel x panjang record x jumlah record + 10-20% toleransi
b. untuk seluruh index
4. Implementasi


7.3. Contoh Pelaksanaan Perancangan Database

7.3.1. Deskripsi Masalah
Sesuai dengan semangat meningkatkan ekspor Indonesia, PT. Angin Ribut ingin
membuat database bagi operasi bisnisnya yang menyangkut pengiriman peti kemas
ke berbagai pelabuhan dunia. Pengiriman peti kemas yang dilayani oleh perusahan
tersebut dilakukan dengan menggunakan kapal milik sendiri yang masing-masing
mempunyai kapasitas tertentu. Peti kemas memiliki nomor (contoh TRLU 1234567),
ukuran (20 feet atau 40 feet), dan tipe (Full, Reefer, dll.).
Setiap kapal memiliki identifikasi seperti nama kapal, call sign, maksimum peti
kemas yang dapat diangkut, dan sebagainya. Rute perjalanan dan jadwal
labuh/berangkat sudah tetap, dan diumumkan dalam majalah Shipping Gazette.
Perjalanan kapal dikenal dengan nama voyage. Berbeda dengan flight number pada
angkutan udara, pada angkutan laut setiap kedatangan kapal mempunyai voyage
yang berbeda sehingga sebuah kapal dapat mempunyai voyage number yang
berbeda-beda. Sebagai contoh, kapal dengan nama Cape Jervis mempunyai voyage
number 03S saat berlayar dengan tujuan Australia, tapi untuk tujuan yang sama di
waktu lain voyage number untuk kapal tersebut mungkin S, 05S, dan sebagainya.
Sebuah kapal dapat melayani tujuan pengiriman yang berbeda-beda, misalnya pada
bulan ini melayani perjalanan ke Eropa, sedangkan bulan Juni ke Cina, dan
sebagainya.
Prosedur yang harus ditempuh oleh seorang ekportir untuk dapat mengirimkan
barangnya dengan menggunakan peti kemas melalui PT. Angin Ribut adalah
sebagai berikut:
1. Eksportir melakukan kontak dengan bagian Customer Support mengenai
rencana pengiriman barang.
2. Jika sudah sepakat mengenai tarif pengiriman, maka informasi rencana
pengiriman tersebut dicatat dalam buku booking seperti jumlah dan tipe peti
kemas yang akan dikirim, kapal yang akan dipakai, tujuan pengiriman, tarif
yang telah disetujui, dan lain-lain.
3. Setelah membayar sesuai dengan persetujuan (bisa sebagian) dan
mengantongi nomor peti kemas yang akan dipakai, eksportir pergi ke tempat
penyimpanan peti kemas untuk mengambil peti kemas kosongnya.
4. Di tempat eksportir, peti kemas tersebut diisi dengan barang yang akan
dikirim. Setelah diperiksa oleh petugas Customs (Bea Cukai), peti kemas
dikirim pada waktu yang telah ditentukan (sesuai dengan jadwal kapal yang
telah disepakati) ke pelabuhan.
5. PT. Angin Ribut akan memuat peti kemas tersebut pada saat proses muat
kapal dilakukan di pelabuhan, jika peti kemas milik eksportir sudah berada di
pelabuhan pada saat itu.
6. Proses ekspor harus dilengkapi dengan dokumentasi agar si penerima barang
di pelabuhan penerima dapat menerima barangnya. Oleh karena itu, setelah
kapal pergi eksportir harus kembali ke PT. Angin Ribut untuk mengambil
dokumen ekspor tersebut setelah membayar biaya dokumen.


Beberapa informasi yang diperlukan oleh para petugas PT. Angin Ribut ketika
bertugas adalah sebagai berikut:
• Daftar jadwal kapal beserta tujuannya
• Tujuan kapal tertentu (misalnya kapal Seven Seas Chariot)
• Kapal yang tersedia untuk pelabuhan tertentu (misalnya untuk pelabuhan
Hobart)
• Kapal yang tersedia ke pelabuhan tertentu pada bulan tertentu
• Daftar peti kemas yang harus dimuat ke kapal tertentu (dari hasil booking)
• Daftar petik emas beserta pemiliknya yang sudah siap dimuat ke atas kapal
tertentu (sudah ada di pelabuhan)
• Daftar peti kemas yang sudah dimuat ke atas kapal tertentu (realisasi
rencana)
• Daftar peti kemas tipe tertentu untuk tujuan Melbourne yang ada di kapal
tertentu
• Daftar eksportir yang telah mengambil peti kemas tapi peti kemasnya tidak
terangkut di pelabuhan (terlambat tiba di pelabuhan)
• Daftar booking untuk bulan Juni 1999
• Daftar pendapatan untuk kapal tertentu
Beberapa asumsi yang digunakan untuk menyederhanakan permasalahan pada

saat merancang database untuk masalah pengiriman peti kemas di atas adalah:
1. Pengiriman barang eksportir selalu merujuk pada tanggal labuh/berangkat
kapal di setiap pelabuhan tujuan.
2. Peti kemas selalu tersedia saat terjadi transaksi pemesanan (booking).
3. Satu nomor booking hanya untuk satu tujuan pengiriman per voyage.
4. Barang yang dikirim seorang eksportir mungkin memerlukan lebih dari satu
peti kemas dengan berbagai tipe yang berbeda.
5. Jadwal perjalanan kapal selalu sudah tersusun (dibuat) pada saat terjadi
transaksi booking.
6. Kapal tidak akan berangkat berlayar jika tidak ada peti kemas yang akan
dikirim (status voyage empty), dan perusahaan akan menjadwal ulang kapal
tersebut untuk pelayaran berikutnya.
7. Jadwal perjalanan kapal untuk satu pelayaran pada tanggal tertentu
mempunyai status penuh (full) jika tonase atau kapasitas maksimum kapal
sudah digunakan seluruhnya.
8. Transaksi booking mempunyai status unready (peti kemas belum datang di
pelabuhan), ready (peti kemas sudah ada di pelabuhan), loaded (peti kemas
sudah diangkut ke kapal) dan completed (peti kemas sudah diterima di
tujuan). Status booking tersebut akan diubah sesuai dengan perkembangan
kejadian yang selalu diinformasikan ke petugas PT. Angin Ribut.
9. Peti kemas yang sudah berada di pelabuhan mendapat jaminan terangkut di
kapal tertentu sesuai dengan jadwal. Bila terjadi keterlambatan maka uang
muka yang sudah dibayarkan akan hangus, dan peti kemas tersebut akan
diangkut pada voyage berikutnya setelah dilakukan order baru.
10. Pendapatan kapal tidak termasuk uang muka yang hangus dikarenakan
keterlambatan pengiriman peti kemas ke pelabuhan.


7.3.2. Pembuatan Model Entity-Relationship (Model E-R)

Model data entity-relationship (model E-R) adalah model data yang pembuatannya
didasarkan pada anggapan bahwa dunia nyata terdiri dari kumpulan objek dasar
yang disebut entity dan relasi diantaranya. Pada model E-R ini struktur logika
database secara keseluruhan digambarkan dengan menggunakan diagram E-R.
1. Identifikasi Entitas Dan Hubungan-Antar-Entitas

Entity adalah sebuah objek yang bisa dibedakan dari objek lainnya
berdasarkan sekumpulan atribut yang spesifik. Relasi adalah hubungan
diantara beberapa entity. Berdasarkan analisis (pengamatan) terhadap
deskripsi permasalahan yang diberikan, entitas yang terlibat dapat
diidentifikasi sebagai berikut:
• SHIP
Mewakili objek kapal yang menjadi sarana pengangkutan peti kemas.
• SHIPTYPE
Mewakili jenis dan spesifikasi kapal.
• VOYAGE
Mewakili objek dari perjalanan kapal.
• PORT
Mewakili objek pelabuhan yang menjadi tujuan pengiriman.
• BOOKING
Mewakili proses pemesanan (booking) pengiriman ke tujuan tertentu.
• CONTAINER
Mewakili objek peti kemas yang akan dikirim.
• EXPORTER
Mewakili objek eksportir yang akan mengirim peti kemas.
Sedangkan hubungan-antar-entitas yang ada adalah:

• TYPE, yaitu hubungan antara entitas SHIP dengan SHIPTYPE yang
menyatakan suatu kapal mempunyai spesifikasi jenis tertentu.
• SCHEDULE, yaitu hubungan antara entitas SHIP dan VOYAGE yang
menyatakan suatu kapal dijadwalkan untuk perjalanan tertentu.
• ROUTE, yaitu hubungan antara entitas VOYAGE dengan PORT yang
menyatakan suatu voyage akan mempunyai rute pelayaran ke pelabuhan
tertentu.
• ASSIGN, yaitu hubungan antara entitas BOOKING, SHIP, dan PORT yang
menyatakan suatu transaksi booking untuk kapal tertentu ke pelabuhan
tertentu.
• BRING, yaitu hubungan antara entitas BOOKING dan CONTAINER yang
menyatakan suatu transaksi booking akan “membawa” peti kemas
tertentu.
• ORDERED, yaitu hubungan antara entitas BOOKING dan EXPORTER
yang menyatakan suatu transaksi booking yang telah dilakukan oleh
eksportir tertentu.


2. Pembuatan Diagram E-R

Diagram E-R adalah suatu media untuk menggambarkan model data E-R
dalam bentuk diagram. Berdasarkan hasil identifikasi entitas dan hubungan-
antar-entitas di atas, maka diagram E-R untuk masalah pengiriman peti
kemas adalah sebagai berikut:
1 N M N
SHIPTYPE TYPE SHIP SCHEDULE VOYAGE
1 Departure Status M
ASSIGN ROUTE Date_of_AD
N N
1
M N
CONTAINER BRING BOOKING PORT
N
Deposit
ORDERED Amount
OrderStatus
1
EXPORTER
7.3.3. Pembuatan Model Data Relasi

Model data relasi adalah suatu model logika database yang menggambarkan entitas
dan hubungan-antar-entitas dalam bentuk tabel-tabel yang disebut relasi.
Kelompok entitas digambarkan dengan suatu relasi yang kolom-kolomnya
menunjukkan identifikasi dari entitas tersebut. Demikian juga untuk hubungan-
antar-entitas, kolom-kolomnya menunjukkan identifikasi dari entitas-entitas yang
berhubungan, dan informasi tentang hubungan tersebut. Setiap tabel relasi
dideskipsikan dalam suatu skema yang disebut skema relasi.
Skema relasi ialah kumpulan nama-nama atribut dari suatu relasi (deskripsi suatu
relasi). Skema relasi dapat diperoleh dari tranformasi model data E-R menjadi
model data relasi. Berdasarkan beberapa aturan tranformasi, skema relasi yang
dapat diturunkan dari diagram E-R untuk masalah pengiriman peti kemas adalah:
1. Dari SHIPTYPE  TYPE  SHIP

Kedua entitas wajib ada, tetapi data SHIP adalah participants total sehingga:
SHIP (ShipName, Callsign, Type)
SHIPTYPE (Type, Tonage, MaxCapacity)


2. Dari SHIP  SCHEDULE  VOYAGE

Kedua entitas wajib ada, dan ada atribut baru yang muncul pada hubungan-
antar-entitas SCHEDULE sehingga:

VOYAGE (Voyage#, Destination)
SCHEDULE (ShipName, Voyage#, Departure, Status)
Atribut ShipName dan Voyage# pada skema relasi SCHEDULE tidak cukup
unik untuk mengidentifikasi jadwal suatu kapal, oleh karena itu perlu satu
atribut tambahan, yaitu Departure, untuk melengkapi kedua atribut tersebut
sehingga membentuk sebuah primary key (hubungan-antar-entitas
SCHEDULE adalah sebuah weak relationship).
3. Dari VOYAGE  ROUTE  PORT

Kedua entitas wajib ada, dan ada atribut baru yang muncul pada hubungan-
antar-entitas ROUTE sehingga:

PORT (PortName, Country)
ROUTE (Voyage#, PortName, Date_of_AD)
Seperti pada kasus nomor dua, atribut Voyage# dan PortName pada skema
relasi ROUTE tidak cukup unik untuk mengidentifikasi rute perjalanan suatu
kapal, oleh karena itu perlu satu atribut tambahan, yaitu Date_of_AD, untuk
melengkapi kedua atribut tersebut sehingga membentuk sebuah primary key
(hubungan-antar-entitas ROUTE adalah sebuah weak relationship).
4. Dari BOOKING  ASSIGN  SHIP  PORT

Ketiga entitas wajib ada walaupun tidak ada atribut baru yang muncul pada
hubungan-antar-entitas ASSIGN sehingga:
BOOKING (Booking#, BookDate, BookStatus)

ASSIGN (Booking#, ShipName, PortName)
5. Dari BOOKING  BRING  CONTAINER

Salah satu entitas wajib ada, yaitu BOOKING, dan walaupun tidak ada atribut
baru yang muncul pada hubungan-antar-entitas BRING tetapi hubungan yang
terbentuk adalah many-to-many sehingga:

CONTAINER (Container#, Type, Dimension)
BRING (Booking#, Container#)
6. Dari EXPORTER  ORDERED  BOOKING

Salah satu entitas wajib ada, yaitu BOOKING, dan ada atribut baru yang
muncul pada hubungan-antar-entitas ORDERED sehingga:



EXPORTER (Exporter#, ExpName, Address, Phone)
ORDERED (Booking#, Exporter#, Deposit, Amount, OrderStatus)
Dari hasil pembentukan skema relasi di atas, skema database yang didapat
untuk masalah pengiriman peti kemas adalah

SHIPTYPE (Type, Tonage, MaxCapacity)
SCHEDULE (ShipName, Voyage#, Departure, Status)
ROUTE (Voyage#, PortName, Date_of_AD)
ASSIGN (Booking#, ShipName, PortName)
BRING (Booking#, Container#)
ORDERED (Booking#, Exporter#, Deposit, Amount, OrderStatus)
CONTAINER (Container#, Type, Dimension)
EXPORTER (Exporter#, ExpName, Address, Phone)
7.3.4. Analisis Ketergantungan Fungsional dan Normalisasi

Ketergantungan adalah suatu bentuk kendala yang harus selalu dipenuhi oleh data
yang disimpan berdasarkan suatu skema database tertentu. Dalam perancangan
database, teori ketergantungan dapat dipergunakan untuk memperoleh skema
relasi yang baik dari skema basis data yang dirancang, ditinjau dari anomali-
anomali yang dikandungnya dimana anomali-anomali tersebut nantinya dapat
dihilangkan dengan memecah skema relasi menjadi beberapa skema relasi.
Pemecahan suatu skema relasi menjadi beberapa skema relasi disebut proses
normalisasi.
1. Analisis Ketergantungan Fungsional

Ketergantungan fungsional dapat didefinisikan sebagai berikut:
Y secara fungsional tergantung kepada X, ditulis X → Y, dalam suatu skema
relasi R = ( A1, A2, ..., An) dimana X, Y ⊆ { A1, A2, ..., An} jika untuk setiap dua
atau lebih tuple dalam R dan ditemukan nilai yang sama pada X, maka akan
ditemukan nilai yang sama pula pada Y dari tuple-tuple tersebut.
Untuk setiap skema relasi pada skema database untuk masalah pengiriman
peti kemas didapat ketergantungan fungsional sebagai berikut:
1. Pada skema relasi SHIP

ShipName → Callsign, Type
2. Pada skema relasi SHIPTYPE

Type → Tonage, MaxCapacity
3. Pada skema relasi VOYAGE

Voyage# → Destination


4. Pada skema relasi SCHEDULE

ShipName, Voyage#, Departure → Status
5. Pada skema relasi ROUTE

Voyage#, PortName, Date_of_AD → ∅
6. Pada skema relasi PORT

PortName → Country
7. Pada skema relasi BOOKING

Booking# → BookDate, BookStatus
8. Pada skema relasi ASSIGN

Booking#, ShipName, PortName → ∅
9. Pada skema relasi BRING

Booking#, Container# → ∅
10. Pada skema relasi ORDERED

Booking#, Exporter# → Deposit, Amount, OrderStatus
11. Pada skema relasi CONTAINER

Container# → Type, Dimension
12. Pada skema relasi EXPORTER

Exporter# → ExpName, Address, Phone
2. Normalisasi
Normalisasi adalah proses memecah (dekomposisi) suatu skema relasi untuk
menghilangkan anomali proses update. Proses normalisasi akan melibatkan
beberapa langkah transformasi untuk membuat suatu relasi menjadi
konsisten secara internal dan non-redundant. Berikut adalah proses
normalisasi yang dilakukan untuk semua skema relasi pada skema database
masalah pengiriman peti kemas:
First Normal Form (1NF)

Relasi R ada dalam keadaan 1NF jika dan hanya jika semua nilai-nilai atribut
yang menjadi domain R mempunyai nilai atomik (tidak ada atribut repetitif
dan semua tuplenya mempunyai harga (tidak kosong).
Karena semua skema relasi pada skema database tidak mempunyai atribut
repetitif dan semua tuplenya mempunyai harga, maka skema relasi sudah ada
dalam keadaan 1NF.


Second Normal Form (2NF)

Relasi R ada dalam keadaan 2NF jika dan hanya jika R ada dalam 1NF dan
semua atribut bukan kunci pada relasi tersebut hanya tergantung kepada
semua atribut yang merupakan kuncinya (tidak ada ketergantungan parsial).
Ketergantungan parsial A terhadap X terjadi jika X → A dan ada Y ⊂ X
sehingga Y → A.
Berdasarkan analisis ketergantungan fungsional, terlihat bahwa semua skema
relasi pada skema database tidak mempunyai ketergantungan parsial
sehingga skema relasi sudah ada dalam keadaan 2NF.
Third Normal Form (3NF)

Relasi R ada dalam keadaan 3NF jika dan hanya jika R ada dalam 2NF dan
semua atribut bukan kunci pada relasi tersebut tidak memiliki
ketergantungan transitif terhadap atribut-atribut yang merupakan kuncinya.
Ketergantungan transitif A terhadap X dalam suatu relasi terpenuhi jika ada Y
→ A, X → Y tetapi X → A.
Berdasarkan analisis ketergantungan fungsional, terlihat bahwa semua skema
relasi pada skema database tidak mempunyai ketergantungan transisitf
sehingga skema relasi sudah ada dalam keadaan 3NF.
7.3.5. Perancangan Fisik Database

Perancangan fisik database merupakan proses untuk mengimplementasikan hasil
perancangan logika kedalam sistem komputer secara fisik. Pada tugas kuliah ini,
aktivitas perancangan fisik yang dikerjakan dibatasi hanya untuk penentuan
struktur untuk setiap tabel yang akan dibuat meliputi nama atribut, jenis, lebar
dan atribut kuncinya, dan penentuan batasan integritas (integrity contraints).
Secara rinci hasil dari perancangan fisik untuk masalah yang diberikan adalah:
1. Penentuan Struktur Data

a. Tabel Ship
Digunakan untuk menyimpan data kapal yang digunakan untuk
mengangkut peti kemas. Struktur data untuk tabel ini adalah:
Nama Tabel : SHIP
Primary Key: ShipName
Foreign Key: Type
No. Nama Atribut Jenis Lebar Keterangan
1 ShipName CHAR 20 Nama kapal
2 CallSign CHAR 10 Nama (tanda) panggilan
3 Type NUMBER 2 Kode jenis kapal
b. Tabel ShipType
Digunakan untuk menyimpan data jenis (spesifikasi) kapal. Struktur
data untuk tabel ini adalah:


Nama Tabel : SHIPTYPE

Primary Key: ShipName
Foreign Key: -
1 Type NUMBER 2 Kode jenis kapal
2 Tonage NUMBER 8 Kapasitas (tonase) kapal
c. Tabel Voyage
Digunakan untuk menyimpan data daerah tujuan perjalanan kapal.
Struktur data untuk tabel ini adalah:
Nama Tabel : VOYAGE
Primary Key: Voyage#
Foreign Key: -
1 Voyage# CHAR 7 Nomor voyage
2 Destination CHAR 20 Daerah tujuan perjalanan
d. Tabel Schedule
Digunakan untuk menyimpan data inisialisasi jadwal perjalanan awal
kapal. Struktur data untuk tabel ini adalah:
Nama Tabel : SCHEDULE
Primary Key: ShipName, Voyage#, Departure
Foreign Key: ShipName, Voyage#
3 Departure DATE Tanggal berangkat
4 Status CHAR 10 Status jadwal
(Empty, Available, Full)
e. Tabel Route
Digunakan untuk menyimpan data rute perjalanan awal kapal yang
sudah dijadwalkan. Struktur data untuk tabel ini adalah:
Nama Tabel : ROUTE
Primary Key: Voyage#, PortName, Date_of_AD
Foreign Key: Voyage#, PortName
2 PortName CHAR 20 Nama pelabuhan tujuan
3 Date_of_AD DATE Tanggal labuh/berangkat
f. Tabel Port
Digunakan untuk menyimpan data pelabuhan yang menjadi tujuan (rute)
perjalanan kapal. Struktur data untuk tabel ini adalah:
Nama Tabel : PORT
Primary Key: PortName
Foreign Key: -
1 PortName CHAR 20 Nama pelabuhan
2 Country CHAR 20 Negara dari pelabuhan


g. Tabel Booking
Digunakan untuk menyimpan data identitas transaksi booking yang
sudah dipesan eksportir. Struktur data untuk tabel ini adalah:
Nama Tabel : BOOKING
Primary Key: Booking#
Foreign Key: -
1 Booking# CHAR 20 Nomor booking
2 BookDate DATE Tanggal booking
3 BookStatus CHAR 10 Status booking
1 = unready
2 = ready
3 = loaded
4 = completed
h. Tabel Assign
Digunakan untuk menyimpan data identitas kapal dan pelabuhan tujuan
yang dicatat pada transaksi booking. Struktur data untuk tabel ini
adalah:
Nama Tabel : ASSIGN
Primary Key: Booking#, ShipName, PortName
Foreign Key: Booking#, ShipName, PortName
3 PortName CHAR 20 Nama pelabuhan
i. Tabel Bring
Digunakan untuk menyimpan data identitas peti kemas yang digunakan
(dibawa) pada suatu transaksi booking. Struktur data untuk tabel ini
adalah:
Nama Tabel : BRING
Primary Key: Booking#, Container#
Foreign Key: Booking#, Container#
2 Container# CHAR 15 Nomor peti kemas
j. Tabel Order
Digunakan untuk menyimpan data order transaksi booking yang
dilakukan oleh eksportir tertentu. Struktur data untuk tabel ini adalah:
Nama Tabel : ORDER
Primary Key: Booking#, Container#
Foreign Key: Booking#, Container#
2 Exporter# CHAR 10 Kode eksportir
3 Deposit NUMBER 15 Jumlah uang muka
4 Amount NUMBER 15 Jumlah total order
5 OrderStatus CHAR 11 Status order
(Paid, Not Paid)


k. Tabel Container
Digunakan untuk menyimpan data peti kemas. Struktur data untuk
tabel ini adalah:
Nama Tabel : CONTAINER
Primary Key: Container#
Foreign Key: -
1 Container# CHAR 15 Nomor peti kemas
2 Type CHAR 8 Jenis peti kemas
3 Dimension CHAR 9 Ukuran peti kemas
l. Tabel Exporter
Digunakan untuk menyimpan data eksportir. Struktur data untuk tabel
ini adalah:
Nama Tabel : EXPORTER
Primary Key: Exporter#
Foreign Key: -
1 Exporter# CHAR 10 Kode ekportir
2 ExpName CHAR 20 Nama eksportir
3 Address CHAR 20 Alamat eksportir
4 Phone CHAR 12 Nomor telepon eksportir
2. Penentuan Batasan Integritas (Integrity Constraints)

Secara umum ada 4 jenis aturan integritas (integrity rules) yang harus
diperhatikan pada saat merancang sebuah basis data, yaitu domain rule,
attribute rule, relation rule dan database rule. Berikut adalah penjelasan
masing-masing aturan integritas yang diberlakukan untuk setiap tabel relasi
yang dibuat di atas untuk masalah pengiriman peti kemas:
a. Domain Rule
Domain rule adalah aturan integritas yang membatasi nilai-nilai apa saja
yang diperkenankan untuk domain yang sudah ditentukan. Pada tugas
ini, aturan integritas domain rule dipergunakan untuk atribut-atribut:
No. Nama Atribut Jenis Nilai Domain

1 Type NUMBER 1, 2, 3 dan 4
2 Status CHAR ‘Empty’, ‘Available’ dan ‘Full’
3 BookStatus CHAR ‘1’, ‘2’, ‘3’, dan ‘4’
4 Deposit NUMBER ≥ 0
5 Amount NUMBER ≥ 0
6 OrderStatus CHAR ‘Paid’ dan ‘Not paid’
b. Attribute Rule
Atribut rule adalah aturan integritas yang membatasi nilai-nilai apa saja
yang diperkenankan untuk atribut yang sudah ditentukan. Pada tugas
ini, aturan integritas attribut rule yang dibuat adalah:


• setiap nilai atribut kunci (primary key) harus unik

• nilai atribut yang ada pada setiap tabel boleh bernilai kosong (null)
• nilai atribut Phone harus unik
c. Relation Rule
Relation rule adalah aturan integritas yang membatasi nilai-nilai apa saja
yang diperkenankan untuk relasi yang sudah ditentukan. Pada tugas ini,
aturan integritas relation rule yang digunakan hanya ditujukan untuk
atribut-atribut Amount dan Deposit pada tabel Order dimana nilai
Amount ≥ Deposit.
d. Database Rule
Database rule adalah aturan integritas yang membatasi nilai-nilai apa
saja yang diperkenankan untuk database yang sudah ditentukan. Pada
tugas ini, aturan integritas database rule yang digunakan ditujukan
untuk tabel Booking dan Order dimana jika atribut BookStatus pada
tabel Booking bernilai ‘3’ atau ‘4’, maka atribut OrderStatus pada tabel
Order harus bernilai ‘Paid’.
7.3.6. Implementasi
1. Pembuatan Tabel-tabel Database
Tabel-tabel database yang dibuat merujuk kepada hasil perancangan fisik
seperti yang ditunjukkan pada bagian 7.3.5 di atas. Adapun pelaksanaannya
dikerjakan dengan menggunakan perintah CREATE TABLE setelah database
untuk tabel-tabel tersebut dibuat. Perintah pembentukan untuk setiap
tabelnya adalah sebagai berikut:
a. Tabel Ship
CREATE TABLE Ship
(ShipName CHAR (20) NOT NULL, CallSign CHAR (10) NOT NULL,
Type NUMBER (2) NOT NULL,
PRIMARY KEY (ShipName),
FOREIGN KEY (Type) REFERENCES ShipType
ON DELETE CASCADE);
b. Tabel ShipType
CREATE TABLE ShipType
(Type NUMBER (2) NOT NULL, Tonage NUMBER (8) NOT NULL,
PRIMARY KEY (Type),
CHECK (Type > 0 AND TYPE < 5));
c. Tabel Voyage
CREATE TABLE Voyage
(Voyage# CHAR (7) NOT NULL, Destination CHAR (20),
PRIMARY KEY (Voyage#));


d. Tabel Schedule
CREATE TABLE Schedule
(ShipName CHAR (20) NOT NULL, Voyage# CHAR (7) NOT NULL,
Departure DATE NOT NULL, Status CHAR (10) NOT NULL,
PRIMARY KEY (ShipName, Voyage#, Departure),
FOREIGN KEY (ShipName) REFERENCES Ship,
FOREIGN KEY (Voyage#) REFERENCES Voyage ON DELETE CASCADE,
CHECK (Status IN (‘Empty’, ‘Available’, ‘Full)));
e. Tabel Route
CREATE TABLE Route
(Voyage# CHAR (7) NOT NULL, PortName CHAR (20) NOT NULL,
Date_of_AD DATE NOT NULL,
PRIMARY KEY (Voyage#, PortName, Date_of_AD),
FOREIGN KEY (Voyage#) REFERENCES Voyage,
FOREIGN KEY (PortName) REFERENCES Port);
f. Tabel Port
CREATE TABLE Port
(PortName CHAR (20) NOT NULL, Country CHAR (20) NOT NULL,
PRIMARY KEY (PortName));
g. Tabel Booking
CREATE TABLE Booking
(Booking# CHAR (20) NOT NULL, BookDate DATE NOT NULL,
BookStatus CHAR (10) NOT NULL,
PRIMARY KEY (Booking#),
CHECK (BookStatus IN (‘1’, ‘2’, ‘3’, ‘4’));
h. Tabel Assign
CREATE TABLE Assign
(Booking# CHAR (20) NOT NULL, ShipName CHAR (20) NOT NULL,
PortName CHAR (20) NOT NULL,
PRIMARY KEY (Booking#, ShipName, PortName),
FOREIGN KEY (Booking#) REFERENCES Booking,
FOREIGN KEY (ShipName) REFERENCES Ship,
FOREIGN KEY (PortName) REFERENCES Port);
i. Tabel Bring
CREATE TABLE Bring
(Booking# CHAR (20) NOT NULL,Container# CHAR (15) NOT NULL,
PRIMARY KEY (Booking#, Container#),
FOREIGN KEY (Container#) REFERENCES Container);
j. Tabel Order
CREATE TABLE Order
(Booking# CHAR (20) NOT NULL, Exporter# CHAR (10) NOT NULL,
Deposit NUMBER (15), Amount NUMBER (15) NOT NULL,
OrderStatus CHAR (11),
PRIMARY KEY (Booking#, Exporter#),
FOREIGN KEY (Exporter#) REFERENCES Exporter)
CHECK (OrderStatus IN ('Paid', 'Not Paid')
AND Deposit <= Amount));


k. Tabel Container
CREATE TABLE Container
(Container# CHAR (15) NOT NULL, Type CHAR (8) NOT NULL,
Dimension CHAR (9) NOT NULL, PRIMARY KEY (Container#));
l. Tabel Exporter
CREATE TABLE Exporter
(Exporter# CHAR (10) NOT NULL, ExpName CHAR (20) NOT NULL,
Address CHAR (20) NOT NULL, Phone CHAR (12) NOT NULL,
PRIMARY KEY (Exporter#));
2. Pembuatan Integrity Constraints

Dalam bahasa SQL*Plus pada paket aplikasi Oracle 8.0, pembuatan batasan
integritas dilakukan melalui perintah CREATE TABLE dengan menyertakan
constraint clause pada perintah tersebut atau dengan perintah ALTER TABLE
dengan menyertakan clause ADD CONTRAINT. Untuk perintah CREATE
TABLE (lihat rincian perintahnya pada butir 1 di atas), implementasi keempat
aturan integritas dapat dinyatakan sebagai berikut:
1. Domain Rule
Dinyatakan melalui CHECK misalnya CHECK (TYPE > 1 AND TYPE <5))
untuk membatasi nilai TYPE pada domain nilai 1, 2, 3 dan 4.
2. Attribute Rule
Dinyatakan melalui clause NOT NULL untuk menyatakan bahwa nilai
atribut tidak boleh kosong, dan UNIQUE untuk menyatakan nilai atribut
harus unik.
3. Relation Rule
Dinyatakan dengan clause CHECK seperti halnya atrutan integritas
domain rule, misalnya CHECK (Amount >= Deposit) untuk menyatakan
bahwa nilai atribut Amount lebih besar atau sama dengan Deposit.
4. Database Rule
Secara teoritis, seharusnya aturan integritas database rule bisa
dinyatakan dengan clause CHECK dan sub-queries tetapi sampai saat
laporan ini dibuat kombinasi clause CHECK dan sub-queries tersebut
masih belum dapat diimplementasikan.
Perintah ALTER TABLE dengan clause ADD CONTRAINT digunakan untuk

menyatakan aturan integritas jika aturan tersebut belum dibuat saat proses
pembentukan tabel. Sebagai contoh, perintah:
ALTER TABLE Schedule, ADD CONTRAINT Stat_Value,

CHECK (Status IN (‘Empty’, ‘Available’, ‘Full’));
digunakan untuk membatasi nilai atribut Status.


3. Pengisian Tabel-tabel Database

Dilaksanakan dengan menggunakan perintah INSERT dengan nilai data
(values) diketikkan melalui keyboard. Secara rinci, masing-masing perintah
pengisian tabel-tabel database adalah sebagai berikut:
a. Tabel Ship
INSERT INTO Ship (ShipName, CallSign, Type)
VALUES (&ShipName, &CallSign, &Type);
b. Tabel ShipType
INSERT INTO ShipType (Type, Tonage)
VALUES (&Type, &Tonage);
c. Tabel Voyage
INSERT INTO Voyage (Voyage#, Destination)
VALUES (&Voyage, &Destination);
d. Tabel Schedule
INSERT INTO Schedule (ShipName, Voyage#, Departure, Status)
VALUES (&ShipName, &Voyage, &Departure, &Status);
e. Tabel Route
INSERT INTO Route (Voyage#, PortName, Date_of_AD)
VALUES (&Voyage, &PortName, &Date_of_AD);
f. Tabel Port
INSERT INTO Port (PortName, Country)
VALUES (&PortName, &Country);
g. Tabel Booking
INSERT INTO Booking (Booking#, BookDate, BookStatus)
VALUES (&Booking#, &BookDate, &BookStatus);
h. Tabel Assign
INSERT INTO Assign (Booking#, ShipName, PortName)
VALUES (&Booking#, &ShipName, &PortName);
i. Tabel Bring
INSERT INTO Bring (Booking#, Container#)
VALUES (&Booking#, &Container#);
j. Tabel Order
INSERT INTO Order (Booking#, Exporter#, Deposit, Amount, OrderStatus)
VALUES (&Booking#, &Exporter#, &Deposit, &Amount, &OrderStatus);
k. Tabel Container
INSERT INTO Container (Container#, Type, Size)
VALUES (&Container, &Type, &Size);
l. Tabel Exporter
INSERT INTO Exporter (Expoter#, ExpName, Address, Phone)
VALUES (&Expoter#, &ExpName, &Address, &Phone);


4. Update Isi Tabel

Update terhadap isi tabel database adalah proses untuk menyisip
(menambah), memperbaiki dan menghapus data ke/dari tabel database.
Dalam SQL*Plus pada paket aplikasi Oracle 8.0, ketiga proses tersebut dapat
dinyatakan dengan perintah INSERT, UPDATE dan DELETE.
Contoh:
Mengubah tonage kapal menjadi 250000 untuk kapal Cape Howe.
UPDATE Ship SET Tonage = 250000 WHERE ShipName = ‘Cape Howe’;
5. Query Informasi Tertentu
a. Query Seluruh Isi Tabel

Perintah query seluruh isi tabel adalah SELECT * FROM <tablename>. Secara
rinci perintah-perintah query tersebut untuk seluruh tabel yang sudah dibuat
adalah:
SET PAGESIZE 100;

SELECT * FROM Ship;
SELECT * FROM ShipType;
SELECT * FROM Voyage;
SELECT * FROM Schedule;
SELECT * FROM Route;
SELECT * FROM Port;
SELECT * FROM Booking;
SELECT * FROM Assign;
SELECT * FROM Bring;
SELECT * FROM Order;
SELECT * FROM Container;
SELECT * FROM Exporter;
b. Query Informasi Tertentu dengan Formula/Kondisi

1. Kapal yang tersedia untuk pelabuhan tertentu (misalnya untuk Rio De
Janeiro)
SELECT Sc.ShipName, R.PortName
FROM Schedule Sc, Route R
WHERE Sc.Voyage# = R.Voyage# AND Sc.Status <> 'Full' AND
R.PortName = 'Rio De Janeiro' AND
Sc.Departure >= SYSDATE;
2. Kapal yang tersedia ke pelabuhan tertentu pada bulan tertentu

WHERE Sc.Voyage# = R.Voyage# AND Sc.Status <> 'Full' AND
R.PortName = 'Brisbane' AND
TRUNC(R.Date_Of_AD, 'MM') = TO_DATE('01/05/1999');


3. Daftar petikemas yang sudah dimuat ke atas kapal tertentu (realisasi

rencana)
BREAK ON ShipName;
SELECT A.ShipName, Br.Container#, B.BookStatus
FROM Assign A, Bring Br, Booking B
WHERE B.Booking# = A.Booking# AND
B.Booking# = Br.Booking# AND
B.BookStatus = '3';
4. Daftar petikemas tipe tertentu untuk Melbourne yang ada di kapal tertentu
BREAK ON ShipName ON Type;
SELECT A.ShipName, Br.Container#, C.Type, B.BookStatus
FROM Assign A, Bring Br, Booking B, Container C
Br.Container# = C.Container# AND
A.PortName = 'Melbourne' AND
B.BookStatus = '3';
5. Daftar eksportir yang telah mengambil peti kemas tapi peti kemasnya tidak
terangkut di pelabuhan (terlambat tiba di pelabuhan)
SELECT E.ExpName, B.BookStatus, A.ShipName
FROM Exporter E, Booking B, Order O, Assign A, Schedule Sc
WHERE B.Booking# = O.Booking# AND
E.Exporter# = O.Exporter# AND
A.Booking# = B.Booking# AND
Sc.ShipName = A.ShipName AND
B.BookStatus = '1' AND
Sc.Departure < SYSDATE;
6. Daftar booking untuk bulan Juni 1999

SELECT B.Booking#,B.BookDate, E.ExpName,A.ShipName,A.PortName
FROM Booking B, Order O, Assign A, Exporter E
WHERE B.Booking# = O.Booking# AND
E.Exporter# = O.Exporter# AND
A.Booking# = B.Booking# AND
TRUNC(B.BookDate, 'MM') = TO_DATE('01/06/1999');
c. Query Informasi Tertentu dengan WHERE, ORDER dan GROUP

1. Daftar jadwal kapal beserta tujuannya
BREAK ON ShipName ON Voyage# ON Departure;
SELECT Sc.ShipName,Sc.Voyage#,Sc.Departure,R.PortName, r.Date_of_AD
WHERE Sc.Voyage# = R.Voyage#
ORDER BY Sc.ShipName, R.Date_of_AD;
2. Tujuan kapal tertentu (misalnya kapal Seven Seas Chariot)

BREAK ON ShipName;
WHERE Sc.Voyage#=R.Voyage# AND Sc.ShipName='Sevenseas Chariot'
ORDER BY R.Date_Of_AD;


3. Daftar petikemas yang harus dimuat ke kapal tertentu (dari hasil booking)
SELECT A.ShipName, Br.Container#, B.BookStatus
FROM Assign A, Bring Br, Booking B
B.Booking# = Br. Booking# AND B.BookStatus = '1'
ORDER BY A.ShipName;
4. Daftar petikemas beserta pemiliknya yang sudah siap dimuat ke atas kapal
tertentu (sudah ada di pelabuhan)
BREAK ON ShipName ON ExpName;
SELECT A.ShipName, E.ExpName, Br.Container#, B.BookStatus
FROM Assign A, Bring Br, Booking B, Exporter E, Order O
WHERE (B.Booking# = A.Booking# AND
B.Booking#=O.Booking#) AND
(O.Exporter# = E.Exporter#) AND B.BookStatus = '2'
ORDER BY A.ShipName, E.ExpName;
5. Daftar pendapatan untuk kapal tertentu

SELECT A.ShipName, SUM(O.Amount)
FROM Order O, Assign A
WHERE A.Booking# = O.Booking# AND O.OrderStatus = 'Paid'
GROUP BY A.ShipName;


Basis Data

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Basis Data

Uploaded by

Copyright:

Available Formats

DIKTAT KULIAH

PENGANTAR BASIS DATA

Bandung, Maret 1997

1. PENDAHULUAN TENTANG DATABASE .…………………………………………… I-1

2. TERMINOLOGI DAN MODEL-MODEL DATA …………..…………………………… II-1

3. MODEL DATA ENTITY-RELATIONSHIP ……….…………………………………… III-1

4. MODEL DATA RELASI ……………….…….……………………………………… IV-1

6. MODEL DATA HIRARKI ……………...…….……………………………………… VI-1

7. PERANCANGAN DATABASE .………...…….……………………………………… VII-1

1.1. Apa yang Disebut Database?

• Merepresentasikan dunia nyata

• Mendapatkan informasi yang kita inginkan

1.2. Mengapa Database?

Gambar 1-1 Contoh Aplikasi Pengolahan Data Konvensional

Dari gambar tersebut kita bisa melihat beberapa kelemahan, diantaranya:

Masalah-masalah yang mungkin timbul dari keadaan di atas:

Untuk mengatasi kelemahan pada pengolahan data konvensional di atas, diperlukan

Gambar 1-2 Contoh Aplikasi dengan Pendekatan Database

Dengan digunakannya konsep database didapat keuntungan sebagai berikut:

1. Bentuk koordinasi yang tegas (consistency/integrity)

1.3. Sistem Database

Unsur manusia meliputi end-user, programmer dan DBA (DataBase Administrator)

Hardware adalah perangkat komputer dimana database disimpan yang dibutuhkan

Software adalah perangkat lunak yang digunakan untuk mengoperasikan komputer.

1. Data Description Language (DDL)

2. Data Manipulation Language (DML)

• Menyajikan informasi yang terkandung dalam database

Pada dasarnya ada dua jenis DML yaitu:

3. Database Control System (DBCS)

1.4. Kebutuhan-kebutuhan Terhadap Pendekatan Database

2. Pemilikan data secara bersama

5. Perangkat lunak DBMS

1.5. Arsitektur Sistem Database

• Level fisik. Tingkat abstraksi paling rendah yang menggambarkan bagaimana

• Level konseptual. Tingkat abstraksi berikutnya yang menggambarkan data apa

• Level pandangan pemakai. Tingkat abstraksi tertinggi yang hanya

Gambar 1-3 Tiga Tingkatan Abstraksi Data

Pengorganisasian Data dalam Suatu Database

Gambar 1-4 Deskripsi Organisasi Data dalam Database

Arsitektur Sistem Database Secara Umum

Gambar 1-5 Arsitektur Umum Sistem Database

Conceptual view merupakan penyajian database secara keseluruhan. Bentuknya agak

Struktur Sistem Database

Komponen-komponen fungsional dari suatu sistem database adalah:

Gambar 1-6 memperlihatkan komponen-komponen fungsional tersebut dan

naive application sophisticated database

application application database

data manipulation data definition

disk data dictionary

Gambar 1-6 Struktur Sistem Database

2.1. Terminologi Data

Dalam konteks sistem database data dinyatakan sebagai kumpulan karakter-

Agregat data dibedakan menjadi vector dan repeating-group. Vector adalah

2.2. Model-model Data

2.2.1. Model Data Logika Berbasis Objek

Berikut adalah penjelasan singkat beberapa model yang termasuk kedalam

Model Data Entity-Relationship

• Kotak, yang menyatakan suatu kelompok entity.

customer cust-act account

Gambar 2.1. Contoh Model Data E-R

Model Data Semantik

Number Balance Street City

Gambar 2.2. Contoh Model Data Semantik

• Elips, yang menyatakan suatu objek (entity) maupun atributnya.