diktat kuliah pengantar basis data - dewapurnama · pdf filemodel data jaringan (network ......

DIKTAT KULIAH PENGANTAR BASIS DATA

o l e h : 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

i

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

ii

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

Handout Pengantar Database Toto Suharto

Pendahuluan Halaman I-1

1 PENDAHULUAN TENTANG DATABASE

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!).

D



• 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.

sophisticatedusers

applicationinterfaces

applicationprograms query database

scheme

data manipulationlanguage

precompiler

queryprocessor

data definitionlanguagecompiler

applicationprograms

object code

databasemanager

naiveusers

applicationprogrammers

databaseadministrator

users

databasemanagementsystem

filemanager

data files

data dictionarydiskstorage

Gambar 1-6 Struktur Sistem Database


Model-model Data Halaman II-1

2 Terminologi dan Model-model Data

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.

D



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.

customer

customer-name

sosial-security

street

customer-city

cust-act account

date

account-number

balance

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

Account Henry

Number Balance Street

Customer

City

adalahpunya

melayani adalah nasabah

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 Shiver Shiver Hodges Hodges

Maple North North Sidehill Sidehill

Queens Bronx Bronx Brooklyn Brooklyn

900 556 647 801 647

900 556 647 801

55 100000 105366 10533

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

Shiver North Bronx

Hodges Sidehill Queens

900 55

556 100000

647 105366

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

Shiver North Bronx

Hodges Sidehill Queens

900 55

556 100000 647 105366

801 10533647 105366

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.


Model Entity-Relationship Halaman III-1

3 Model Entity Relationship (E-R)

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.

M



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

Markum

Kumkum

T-01

T-02

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

Markum

Kumkum

R-01

R-02

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

Markum

Kumkum

Basuki

Paijo

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 MANAGERS

PARTS

MANAGE

USE

(a) Projects

PRICECHANGES SUPPLIERS

PARTS

FROM

TO

(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.

COMPANY

VEHICLES

OWNS LEASES

c1

c2

c3

v1

v2

v3

v4

v5

Sample OWNSinteractions

Sample LEASESinteractions

Samplecompanies

Samplevehicles

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 BUSINESSMAKES

CUSTOMERS

SELLS-TO

(a) Incorrect model

PARTS CUSTOMERSSOLD-TO

(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.

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

p1

p2

p3

p4

v1

v2

v3



D3, maka jawaban yang didapat berdasarkan occurrence diagram tersebut tidak bisa kita berikan, karena bisa Jill bisa juga Richard (informasi jadi bias).

(a) E-R Diagram

(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.

(a) E-R Diagram

(b) Occurrence Diagram

Gambar 3.11 Konversi untuk Relasi Tidak Lengkap

DRIVER TRUCKS DELIVERIES USE FOR N M 1 N

Jill •

Richard •

Ford •

Ferrari •

• D1

• D2

• D3

DRIVER DELIVERIES TRUCKS MAKE USING N M 1 N

Jill •

Richard •

• Ford

• Ferrari

D1 •

D2 •

D3 •



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:

KENDARAAN LOG SERVICE UNTUK JENISLAYANAN

MONTIR

BUTUH

SUKUCADANG

KEAHLIAN

NoPol

Jenis

Pemilik

Kode Nama

Price

PartNo

Descr.

Banyak

NoBukti

Tanggal

Jumlah

Upah

Kode

Nama

Biaya

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.

1 n

m

m n

m

n

m n


Model Data Relasi Halaman IV-1

4 Model Data Relasi

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

N R P Nm_Mhsiswa <data lain> D-003 K-004 96.761 Abdul . . . MENGAJAR96.671 Markum . . . 96.212 Kumkum . . . N R P 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

Database . . . 96.203 K-001 . . .

K-004 Struktur Data . . . 96.203 K-004 . . . KULIAH MENGAMBIL

Gambar 4.1. Contoh Data Model Relasi

M



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:

MAHASISWA

m n 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


Model Data Jaringan Halaman V-1

5 Model Data Jaringan (Network)

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

B



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

Gambar 5.2. Diagram Struktur Data DOSEN-KULIAH

Pendefinisian suatu objek dari record type dideskripsikan dalam record. Misalkan kita punya suatu jaringan sebagai berikut:

Gambar 5.3. Contoh Skema Jaringan

DOSEN

KULIAH

record type

record type

set type

1

n

ST

RT1 RT2 RT3

RT4



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:

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.

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.

record type RT2

record type RT2

record type RT4

record type RT4

rt41

rt41

rt42

rt42

rt43

rt43

rt44

rt44

rt45

rt45

rt21

rt21

rt22

rt22

rt23

rt23

set type ST2

set type ST2



Gambar 5.6. (a) Transformasi (m-n) Menjadi (1-n)(n-1)

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:

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

• b1 • b2 • b3 • b4

b2

a1 • a2 • a3 •

c1

c2

c3

c4

c5

c6

b3

RTA

RTB

VRTC

b4 b1

record type A : owner record type B : owner virtual record type C : member

a1 a2 a3

b4



Transformasi Model Data E-R Menjadi Model Jaringan 1. Untuk asosiasi (m-n)

A

B

R1

m

n

RTA

RTB

ST1

VRTC

ST2

1n

n1

2. Untuk asosiasi (1-n) atau (1-1)

A

B

R2

1

1, n

RTA

RTB

ST1

1

1, n

Contoh: Hubungan antara aircraft dengan pilot

Aircraft

Pilot

R1

m

n

Aircraft

Pilot

ST1

VRTC

ST2

1n

n1



Aircraft Pilot

C1 C2 C3 C4 C5 C6

a1 a2 a3

p1 p2 p3

RTa/c

VRTR1

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.

a1 • a2 • a3 •

• p1 • p2 • p3

(a1, p1) (a1, p2) (a1, p3) (a2, p2) (a2, p3) (a3, p1)



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).


Model Data Hirarki Halaman VI-1

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



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.


Perancangan Database Halaman VII-1

7 Perancangan Database

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

P



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:

SHIPTYPE SHIPTYPE VOYAGESCHEDULE

PORT

ROUTE

BOOKING

ASSIGN

CONTAINER BRING

EXPORTER

ORDERED

Deposit

Amount

OrderStatus

Departure Status

Date_of_AD

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)

M

1 N M N

1

N 1

M

N

N

1

N



2. Dari SHIP SCHEDULE VOYAGE Kedua entitas wajib ada, dan ada atribut baru yang muncul pada hubungan-

antar-entitas SCHEDULE sehingga: SHIP (ShipName, Callsign, Type) 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: VOYAGE (Voyage#, Destination) 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) SHIP (ShipName, Callsign, Type) PORT (PortName, Country) 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:

BOOKING (Booking#, BookDate, BookStatus) 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:



BOOKING (Booking#, BookDate, BookStatus) 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 SHIP (ShipName, Callsign, Type) SHIPTYPE (Type, Tonage, MaxCapacity) VOYAGE (Voyage#, Destination) SCHEDULE (ShipName, Voyage#, Departure, Status) ROUTE (Voyage#, PortName, Date_of_AD) PORT (PortName, Country) BOOKING (Booking#, BookDate, BookStatus) 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: - No. Nama Atribut Jenis Lebar Keterangan 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: - No. Nama Atribut Jenis Lebar Keterangan 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# No. Nama Atribut Jenis Lebar Keterangan 1 ShipName CHAR 20 Nama kapal 2 Voyage# CHAR 7 Nomor 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 No. Nama Atribut Jenis Lebar Keterangan 1 Voyage# CHAR 7 Nomor voyage 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: - No. Nama Atribut Jenis Lebar Keterangan 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: - No. Nama Atribut Jenis Lebar Keterangan 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 No. Nama Atribut Jenis Lebar Keterangan 1 Booking# CHAR 20 Nomor booking 2 ShipName CHAR 20 Nama kapal 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# No. Nama Atribut Jenis Lebar Keterangan 1 Booking# CHAR 20 Nomor booking 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# No. Nama Atribut Jenis Lebar Keterangan 1 Booking# CHAR 20 Nomor booking 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: - No. Nama Atribut Jenis Lebar Keterangan 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: - No. Nama Atribut Jenis Lebar Keterangan 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 (Booking#) REFERENCES Booking, 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 (Booking#) REFERENCES Booking, 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 SELECT Sc.ShipName, R.PortName FROM Schedule Sc, Route R 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 WHERE B.Booking# = A.Booking# AND B.Booking# = Br.Booking# AND 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 FROM Schedule Sc, Route R 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; SELECT Sc.ShipName, R.PortName FROM Schedule Sc, Route R 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 WHERE B.Booking# = A.Booking# AND 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# = Br.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;

diktat kuliah pengantar basis data - dewapurnama · pdf filemodel data jaringan (network ......

Documents