DIKTAT KULIAH PENGANTAR BASIS DATA

oleh: TOTO SUHARTO

KATA PENGANTAR

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

Bandung, Maret 1997

Toto Suharto

DAFTAR ISI
1. PENDAHULUAN TENTANG DATABASE .…………………………………………… 1.1 Apa yang Disebut Database? …..…………………………………………… 1.2 Mengapa Database? .……………..…………………………………………. 1.3 Sistem Database …………………..………………………………………… 1.4 Kebutuhan-kebutuhan Terhadap Pendekatan Database …………………….. 1.5 Arsitektur Sistem Database ..……………………………..…………………. Abstraksi Data …..……………………………………….…………………. Pengorganisasian Data dalam Suatu Database ..………….……………….... Arsitektur Sistem Database Secara Umum …….…………..……………….. Struktur Sistem Database ………………………..…………..……………… TERMINOLOGI DAN MODEL-MODEL DATA …………..…………………………… 2.1 Terminologi Data ………….………………………………………………… 2.2 Model-model Data …………………………………..……………………… 2.2.1 Model Data Logika Berbasis Objek …………..……………………… Model Data Entity-Relationship ……………………………………… Model Data Semantik ………….……………………………………… Model Data Entity-Relationship ……………………………………… 2.2.2 Model Data Logika Berbasis Record ….……………………………… Model Data Relasi …….……….……………………………………… Model Data Jaringan (Network) .……………………………………… Model Data Hirarki …………….………………………………..…… 2.2.3 Model Data Fisik ……………………….…………………………….. I-1 I-1 I-2 I-4 I-6 I-7 I-7 I-8 I-10 I-11 II-1 II-1 II-2 II-2 II-3 II-3 II-3 II-4 II-4 II-5 II-6 II-6

2.

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 MODEL DATA RELASI ……………….…….……………………………………… 4.1 Struktur Model Data Relasi .………………………………………………… 4.2 Transformasi Bentuk E-R Menjadi Model Relasi .………………………….. 4.3 Operasi pada Model Data Relasi .…………………………………………… Operasi Dasar .………………………………………………………………. Operasi Suplemen …………………………………………………………… i IV-1 IV-2 IV-2 IV-3 IV-3 IV-5

4.

5.

MODEL DATA JARINGAN (NETWORK) .…….……………………………………… 5.1 Pengertian Dasar …………..………………………………………………… 5.2 Diagram Struktur Data ………………………..…………………………….. MODEL DATA HIRARKI ……………...…….……………………………………… 6.1 Pengertian Dasar …………..………………………………………………… 6.2 Implementasi Secara Fisik ……………………..……………………………. 6.3 Operasi Pada Model Data Hirarki ……………..……………………………. PERANCANGAN DATABASE .………...…….……………………………………… 7.1 Perancangan Logika Database ……………………………………………… 7.1.1 Perancangan Model Konseptual atau Enterprise ……………………… 7.1.2 Langkah-langkah Perancangan Model Konseptual …………………… 7.1.3 Perancangan Model Logika …………………………………………… 7.2 Perancangan Fisik Database ………………….…..…………………………. 7.3 Contoh Pelaksanaan Perancangan Database ....…..…………………………. 7.3.1 Deskripsi Masalah …………..………………………………………… 7.3.2 Pembuatan Model Entity-Relationship (Model E-R) ………………… 7.3.3 Pembuatan Model Data Relasi ..………………….. ..………………… 7.3.4 Analisis Ketergantungan Fungsional dan Normalisasi ..……………… 7.3.5 Perancangan Fisik Database …….….……………….………………… 7.3.6 Implementasi …………………….….……………….…………………

V-1 V-1 V-2 VI-1 VI-1 VI-3 VI-4 VII-1 VII-1 VII-2 VII-2 VII-3 VII-3 VII-4 VII-4 VII-6 VII-7 VII-9 VII-11 VII-16

6.

7.

DAFTAR PUSTAKA LAMPIRAN-LAMPIRAN

ii

Handout Pengantar Database

Toto Suharto



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.

D

1.1. Apa yang Disebut Database?
Database didefinisikan sebagai kumpulan data yang diorganisasi dengan cara dan aturan tertentu2 pada tempat penyimpanan sekunder guna merepresentasikan dunia nyata (real world)1, sedemian rupa sehingga kita bisa mendapatkan informasi yang kita inginkan3 daripadanya. Definisi database di atas mengandung pengertian: • Merepresentasikan dunia nyata Kumpulan data tersebut jika diinterpretasikan harus bisa mewakili dan menggambarkan satu masalah yang berhubungan dengan kehidupan sehari, misalnya kumpulan data mahasiswa, dosen, mata kuliah, FRS, jadwal dan nilai mewakili masalah akademis (Tapi, kumpulan data barang, mahasiswa, penjualan, kendaraan, pajak tidak bisa disebut database, karena tidak mewakili masalah tertentu!). Diorganisasi dengan cara dan aturan tertentu Kumpulan data tersebut harus diorganisasi dengan salah satu dari tiga cara berikut, yaitu model relasi, hirarki atau jaringan (Tapi, kumpulan data mahasiswa, dosen, mata kuliah, FRS, jadwal dan nilai tidak bisa disebut database jika data mahasiswa dan dosen disimpan dalam file data, dan data mata kuliah, jadwal serta nilai disimpan dalam file worksheet!).



Pendahuluan

Halaman I-1

Handout Pengantar Database

Toto Suharto



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;


Pendahuluan

Halaman I-2

Handout Pengantar Database

Toto Suharto



4.

Adanya ketergantungan struktur file dengan program, metode akses.

dan jumlah file dengan

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


Pendahuluan

Halaman I-3

Handout Pengantar Database

Toto Suharto



Dengan digunakannya konsep database didapat keuntungan sebagai berikut: 1. 2. Bentuk koordinasi yang tegas (consistency/integrity) 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. 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. Minimasi proses update Karena data disimpan secara bersama (komunal), peremajaan data induk dan transaksi cukup dilakukan satu kali, sehingga mengurangi proses update. 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. Mengurangi biaya pemeliharaan untuk perubahan data dan media penyimpanan Meningkatkan produktivitas Akses data yang disimpan dalam suatu database dapat dilakukan oleh siapapun tanpa latar belakang bahwa pemakai harus mengetahui ilmu komputer. Keamanan data lebih terjamin

3.

4. 5.

6. 7. 8.

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. Enduser 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.


Pendahuluan

Halaman I-4

Handout Pengantar Database

Toto Suharto



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



Pendahuluan

Halaman I-5

Handout Pengantar Database

Toto Suharto



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, invertedlist, 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.


Pendahuluan

Halaman I-6

Handout Pengantar Database

Toto Suharto



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.



Pendahuluan

Halaman I-7

Handout Pengantar Database

Toto Suharto



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

Pendahuluan

Halaman I-8

Handout Pengantar Database

Toto Suharto



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


Pendahuluan

Halaman I-9

Handout Pengantar Database

Toto Suharto



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


Pendahuluan

Halaman I-10

Handout Pengantar Database

Toto Suharto



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.



Pendahuluan

Halaman I-11

Handout Pengantar Database

Toto Suharto



Gambar 1-6 memperlihatkan hubungan diantaranya.

komponen-komponen

fungsional

tersebut

dan

users naive users application programmers sophisticated users database administrator

application interfaces

application programs

query

database scheme

data manipulation language precompiler

query processor

data definition language compiler

application programs object code

database manager

database management system

file manager

data files

disk storage

data dictionary

Gambar 1-6 Struktur Sistem Database



Pendahuluan

Halaman I-12

Handout Pengantar Database

Toto Suharto



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

2.1. Terminologi Data
Data didefinisikan sebagai fakta dari suatu kejadian. Fakta dari kejadian tersebut mungkin ditemukan dalam bentuk dokumen (faktur, laporan), gambar, suara, atau media lainnya. Apabila data atau fakta sudah mengalami suatu proses, maka hasilnya disebut informasi. Dalam konteks sistem database data dinyatakan sebagai kumpulan karakterkarakter yang disusun menurut suatu aturan agar mudah untuk dikenali, disimpan, dimanipulasi dan disajikan kembali (retrieve). Secara fisik kumpulan karakter yang mewakili data ini tersimpan dalam sistem komputer dan membentuk suatu database dengan hirarki penyusunan sebagai berikut: • • • • Bit. Adalah suatu sistem angka biner yang hanya mempunyai dua kemungkinan nilai, yaitu 0 dan 1. Sistem angka biner ini merupakan dasar komunikasi antara manusia dan mesin (komputer). Byte. Adalah kumpulan 8 bit data yang kombinasi nilainya digunakan untuk menyatakan satu buah karakter. Item Data. Adalah satuan terkecil dari data yang mempunyai arti. Item data sering disebut juga dengan field data atau elemen data, yang dapat diberi nama sebagai identitasnya. Agregat Data. Kumpulan item data dalam suatu record yang diberi nama tertentu dan dianggap sebagi satu kesatuan yang utuh. Sebagai contoh, agregat data dengan nama tanggal tersusun dari item data hari, bulan dan tahun.



Model-model Data

Halaman II-1

Handout Pengantar Database

Toto Suharto



• •

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 recordrecordnya, 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 Model Model Model Model Model entity-relationship berorientasi objek (object-oriented model) biner data semantik infological data fungsional

Berikut adalah penjelasan singkat beberapa model yang termasuk kedalam kelompok model data logika berbasis objek ini.



Model-model Data

Halaman II-2

Handout Pengantar Database

Toto Suharto



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

Contoh dari model E-R ini bisa dilihat pada Gambar 2.1. sedangkan pembahasan rincinya akan diberikan pada Bab 3.

street sosialsecurity customername customer-city date accountnumber balance

customer

cust-act

account

Gambar 2.1. Contoh Model Data E-R

Model Data Semantik
Model data semantik hampir sama dengan model data E-R, hanya saja pernyataan relasi antar entity tidak digambarkan dengan simbol tetapi menggunakan katakata.



Model-model Data

Halaman II-3

Handout Pengantar Database

Toto Suharto



Bank X melayani punya Account Customer adalah nasabah adalah Henry

Number

Balance

Street

City

Gambar 2.2. Contoh Model Data Semantik Gambar 2.2. di atas menunjukkan contoh model data semantik. Dari gambar tersebut bisa kita lihat bahwa simbol yang digunakan dalam model data semantik ini adalah: • • • Elips, yang menyatakan suatu objek (entity) maupun atributnya. Anak panah, yang menunjukkan relasi antar objek. Garis, yang menghubungkan objek dengan atributnya.

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

Model Data Relasi
Model data relasi merepresentasikan data dan hubungan diantaranya dalam bentuk kumpulan tabel, dimana setiap tabel tersusun dari sejumlah kolom yang mempunyai nama yang unik.



Model-model Data

Halaman II-4

Handout Pengantar Database

Toto Suharto



Gambar 2.3. adalah sebuah contoh database model relasi yang menunjukkan customer dengan account yang dipunyainya. Name Lowery Shiver Shiver Hodges Hodges Street Maple North North Sidehill Sidehill City Queens Bronx Bronx Brooklyn Brooklyn Number 900 556 647 801 647 Number 900 556 647 801 Balance 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

900 556

55 100000 105366 10533

Shiver

North

Bronx 647

Hodges

Sidehill

Queens

801

Gambar 2.4. Contoh Model Data Jaringan



Model-model Data

Halaman II-5

Handout Pengantar Database

Toto Suharto



Model Data Hirarki
Model data hirarki mempunyai kesamaan dengan model jaringan dalam hal representasi data dan hubungan diantaranya, yaitu dengan record-record dan links. Berbeda dengan model data jaringan, record-record dan links tersebut dalam database diorganisasi sebagai kumpulan pohon (tree). Gambar 2.5. memperlihatkan contoh sebuah model data hirarki dengan informasi yang sama seperti Gambar 2.3.

Lowery

Maple

Queens

Hodges

Sidehill

Queens

Shiver

North

Bronx

556

100000

647

105366

900

55

647

105366

801

10533

Gambar 2.5. Contoh Model Data Hirarki

2.2.3. Model Data Fisik
Model data fisik digunakan untuk menggambarkan data pada tingkat paling rendah. Pada model data ini dijelaskan bagaimana data pada sistem database disimpan pada perangkat penyimpanan secara fisik. Berbeda dengan model data logika, hanya ada beberapa model data fisik yang digunakan. Dua model yang sudah cukup dikenal secara luas adalah: • • unifying model memory frame

Karena cakupan dari model data fisik berhubungan dengan aspek mesin (komputer), maka model data tersebut tidak akan dibahas pada tulisan ini.



Model-model Data

Halaman II-6

Handout Pengantar Database

Toto Suharto



3 Model Entity Relationship (E-R)

M

odel Entity-Relationship (model E-R) merupakan suatu model data yang menyatukan beberapa informasi semantik yang penting mengenai dunia nyata. Pembuatan model data E-R didasarkan pada anggapan bahwa dunia nyata terdiri dari kumpulan objek-objek dasar yang disebut entity, dan hubungan yang terjadi diantaranya yang disebut relasi (relationship). Model data E-R digunakan untuk menyederhanakan permasalahan pembuatan basis data secara top down.

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



Model Entity-Relationship

Halaman III-1

Handout Pengantar Database

Toto Suharto



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.



Model Entity-Relationship

Halaman III-2

Handout Pengantar Database

Toto Suharto



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 atributatribut 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 masingmasing 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.



Model Entity-Relationship

Halaman III-3

Handout Pengantar Database

Toto Suharto



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 PASIEN T-01 T-02 T-03 TMP_TIDUR

Gambar 3.2. Contoh Relasi Satu-ke-Satu • Satu-ke-banyak atau banyak-ke-satu (one-to-many atau many-to-one) Setiap elemen dari entity pertama dipasangkan dengan beberapa elemen dari entity kedua dan setiap elemen dari entity kedua tepat dipasangkan dengan satu elemen dari entity pertama, demikian juga sebaliknya. Contoh: relasi antara Pasien dan Ruangan pada masalah medical record.
Abdul R-01 Markum R-02 Kumkum PASIEN RUANGAN

Gambar 3.3. Contoh Relasi Satu-ke-Banyak


Model Entity-Relationship

Halaman III-4

Handout Pengantar Database

Toto Suharto



Banyak-ke-banyak (many-to-many) Setiap elemen dari entity pertama dipasangkan dengan beberapa elemen dari entity kedua dan setiap elemen dari entity kedua juga dipasangkan dengan beberapa elemen dari entity pertama. Contoh: relasi antara PASIEN dan DOKTER.
Abdul Basuki Markum Paijo Kumkum PASIEN DOKTER

Gambar 3.4. Contoh Relasi Banyak-ke-Banyak Penentuan jenis pemetaan untuk kelompok relasi ini tergantung kepada dunia nyata yang dimodelkan oleh kelompok relasi tersebut. Jadi untuk kelompok relasi yang satu mungkin kita dapatkan pemetaan yang berbeda dengan kelompok relasi lainnya

3.6 Diagram E-R
Diagram E-R adalah suatu media untuk menggambarkan model data E-R dalam bentuk diagram. Simbol-simbol yang digunakan untuk menggambarkan model data E-R dengan diagram E-R adalah: 1. 2. 3. 4. Entity Simbol yang digunakan untuk entity berupa kotak persegi panjang, dengan nama entity ditulis didalamnya. Relationship Simbol yang digunakan sama dengan simbol keputusan (belah ketupat), dengan hubungan yang terjadi ditulis didalamnya. Atribut Simbol yang digunakan berupa lingkaran, dengan nama atribut ditulis didalamnya. 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



Model Entity-Relationship

Halaman III-5

Handout Pengantar Database

Toto Suharto



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

2.

PROJECTS

MANAGE

MANAGERS

USE

PARTS (a) Projects

PRICE CHANGES

FROM

SUPPLIERS

TO

PARTS (b) Price changes

Gambar 3.6. Contoh Penamaan Entity dan Relasi



Model Entity-Relationship

Halaman III-6

Handout Pengantar Database

Toto Suharto



3.

Ada kemungkinan terjadi lebih dari satu relasi diantara dua kelompok entity yang sama, misalnya seperti contoh yang ditunjukkan oleh Gambar 3.7.
Sample OWNS interactions Sample companies

COMPANY

v1 c1 v2 v3 v4 v5
Sample vehicles

OWNS

LEASES

c2 c3

VEHICLES

Sample LEASES interactions

Gambar 3.7. Relasi Lebih dari Satu Diantara Dua Kelompok Entity 4. Total sistem tidak diperbolehkan untuk disertakan dalam diagram E-R, dalam arti sistem yang sedang dibuat model E-Rnya tidak diperkenankan untuk dimunculkan. Gambar 3.8. memperlihatkan contoh diagram E-R yang salah yang menyertakan total sistem.

PARTS

MAKES

BUSINESS

SELLS-TO

(a) Incorrect model

CUSTOMERS

PARTS (b) Correct model

SOLD-TO

CUSTOMERS

Gambar 3.8. Contoh Penggambaran Diagram E-R yang Salah



Model Entity-Relationship

Halaman III-7

Handout Pengantar Database

Toto Suharto



3.7 Occurrence Diagram
Occurrence diagram atau diagram kemunculan adalah sebuah diagram semantik yang menggambarkan bagaimana entity-entity pada model berinteraksi satu sama lainnya. Salah satu contoh dari occurrence diagram ini ditunjukkan oleh Gambar 3.9.

p1 p2 p3 p4 v1 v2 v3

Gambar 3.9. Contoh Occurrence Diagram Dari gambar di atas terlihat bagaimana interaksi yang terjadi antara seseorang p1, p2, p3 dan p4 pada kelompok entity Persons dengan sebuah kendaraan v1, v2 dan v3 pada kelompok entity Vehicles. Garis yang menghubungkan pasangan entity diantara kedua kelompok entity tersebut melalui sebuah relasi memperlihatkan orang yang mana yang mengemudi kendaraan apa, seperti p1 mengemudi v1, p2 juga mengemudi v1, p2 mengemudi v2, dan seterusnya. Setiap garis yang memperlihatkan interaksi antara sepasang entity adalah sebuah relasi, dalam hal ini relasi pada kelompok relasi Drive.

3.8 Relasi Tidak Lengkap
Relasi tidak lengkap adalah sebuah relasi yang tidak mengandung semua informasi yang diperlukan oleh suatu kelompok relasi. Ketidaklengkapan informasi ini dapat diakibatkan oleh beberapa sebab, dan diantaranya adalah: • Relasi yang mendasar dari permasalahan tidak disertakan pada model. • Relasi yang dibuat dalam model tidak menggambarkan sistem informasi dari permasalahan. Sebagai contoh, perhatikan Gambar 3.10 (a). Gambar ini memperlihatkan sebuah diagram E-R yang memodelkan pengiriman yang dikerjakan oleh pengemudi dengan menggunakan kendaraan truk. Relasi Use memodelkan Drivers yang mengemudi Trucks, sedangkan relasi For memodelkan Trucks yang digunakan untuk mengirim Deliveries. Occurrence diagram pada Gambar 3.10 (b) memperlihatkan bahwa Jill dan Richard keduanya menggunakan Ferrari. Diagram ini pun memperlihatkan bahwa kendaraan Ferrari digunakan untuk mengirimkan kiriman D2 dan D3. Jika ditanyakan siapa yang mengirim kiriman D2 atau


Model Entity-Relationship

Halaman III-8

Handout Pengantar Database

Toto Suharto



D3, maka jawaban yang didapat berdasarkan occurrence diagram tersebut tidak bisa kita berikan, karena bisa Jill bisa juga Richard (informasi jadi bias).
DRIVER N USE M TRUCKS 1 FOR N DELIVERIES

(a) E-R Diagram
Jill • Richard • • D1 • D2 • D3

Ford • Ferrari •

(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.
DRIVER N MAKE M DELIVERIES 1 USING N TRUCKS

(a) E-R Diagram
Jill • Richard • D1 • D2 • D3 •

• Ford • Ferrari

(b) Occurrence Diagram Gambar 3.11 Konversi untuk Relasi Tidak Lengkap



Model Entity-Relationship

Halaman III-9

Handout Pengantar Database

Toto Suharto



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



Model Entity-Relationship

Halaman III-10

Handout Pengantar Database

Toto Suharto



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

4.



Model Entity-Relationship

Halaman III-11

Handout Pengantar Database

Toto Suharto



3.9.3 Pembuatan Diagram E-R
Berdasarkan hasil identifikasi entitas dan hubungan antar entitas, maka diagram E-R untuk masalah jasa layanan kendaraan bermotor adalah:
Kode Nama Upah

MONTIR

m
Tanggal NoBukti Jumlah

n
KEAHLIAN

m
KENDARAAN

Kode

1

LOG

n

SERVICE

m

UNTUK

n

JENIS LAYANAN

Nama

NoPol Jenis

Pemilik

m
BUTUH
Banyak

Biaya

n
SUKU CADANG

PartNo Descr. Price

Dari diagram E-R tersebut, informasi yang diinginkan dapat diperoleh dengan cara sebagai berikut: • • • • • Laporan penerimaan kas Informasi diperoleh dari entitas SERVICE. Laporan penerimaan kas dari jasa layanan Informasi diperoleh dari hubungan antar entitas UNTUK, entitas SERVICE dan JENIS LAYANAN. Laporan penerimaan kas dari penjualan suku cadang Informasi diperoleh dari hubungan antar entitas BUTUH, entitas SERVICE dan SUKU CADANG. Laporan pemakaian suku cadang Informasi diperoleh dari hubungan antar entitas BUTUH, dan entitas SUKU CADANG. Daftar upah mingguan untuk pembayaran montir Informasi diperoleh dari hubungan antar entitas LOG, UNTUK, KEAHLIAN, dan entitas MONTIR dan JENIS LAYANAN.



Model Entity-Relationship

Halaman III-12

Handout Pengantar Database

Toto Suharto



4 Model Data Relasi
M
odel data relasi adalah suatu model logika database yang menggambarkan entity dan relasi dalam bentuk tabel-tabel yang disebut relasi. Kelompok entity digambarkan dengan suatu relasi yang kolom-kolomnya menunjukkan identifikasi dari entity tersebut. Demikian juga untuk relasi, kolom-kolomnya menunjukkan identifikasi dari entity-entity yang berhubungan, dan informasi tentang hubungan tersebut. Sebagai contoh, tinjau masalah akademik. Entity yang terlibat didalamnya misalnya adalah DOSEN, MAHASISWA dan KULIAH. Relasi yang terjadi antar entity tersebut misalnya MENGAJAR untuk entity DOSEN-KULIAH dan MENGAMBIL untuk entity MAHASISWA-KULIAH. Gambarannya: Dosen# D-001 D-002 D-003 Nm_Dosen Slamet Sanwani Paijo <data lain> ... ... ... DOSEN <data lain> ... ... ... ... ... MHSISWA Dosen# Kuliah# D-001 K-001 D-001 K-002 D-001 K-004 D-002 K-002 D-003 K-003 D-003 K-004 NRP 96.761 96.671 96.671 96.671 96.212 96.212 96.178 96.203 96.203 Kuliah# K-001 K-001 K-003 K-004 K-002 K-003 K-001 K-001 K-004 <data lain>

NRP 96.761 96.671 96.212 96.178 96.203 Kuliah# K-001 K-002 K-003

Nm_Mhsiswa Abdul Markum Kumkum Basuki Sastro

MENGAJAR <data lain> ... ... ... ... ... ... ... ... ... MENGAMBIL

Mata Kuliah <data lain> Algoritma ... Analisa Sistem ... Sistem ... Database K-004 Struktur Data ... KULIAH

Gambar 4.1. Contoh Data Model Relasi



Model Data Relasi

Halaman IV-1

Handout Pengantar Database

Toto Suharto



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, ... ) D-K( NIP, Kode, Hari, Jam, ... ) M-K( NRP, Kode, Nilai, ... )

skema database

4.2. Transformasi Bentuk E-R menjadi Model Relasi
Yang harus diperhatikan pada saat transformasi bentuk E-R ini adalah: 1. Entity pada bentuk E-R berubah menjadi relasi dan key atribut entity menjadi atribut kunci relasi. 2. Relationship pada bentuk E-R berubah menjadi relasi dengan syarat semua atribut kunci relationship akan menjadi key atribut relasi. Sebagai contoh, misalkan diketahui model E-R dari dua entity MAHASISWA dan KULIAH dengan relasi AMBIL sebagai berikut: m MAHASISWA AMBIL n 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).



Model Data Relasi

Halaman IV-2

Handout Pengantar Database

Toto Suharto



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: color Red White Blue Fashion: color Red Magenta Blue 2. colorcode 93471 93474 93476 colorcode 93471 93479 93477 Colors ∪ Fas hion color colorcode Red 93471 White 93474 Blue 93476 Magenta 93479 Blue 93477

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



Model Data Relasi

Halaman IV-3

Handout Pengantar Database

Toto Suharto



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 a d e B b a b C c f d R = σ(B=“b”) ∧ (C=“c”)(R1) A B C a b c

R = σB=“b”(R1) A B a b c b 4.

C c d

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 A a d c B b a b C c f d R2 D b d E g a F a f



Model Data Relasi

Halaman IV-4

Handout Pengantar Database

Toto Suharto



R = R1 X R2 A B a b a b d a d a c b c b

C c c f f d d

D b d b d b d

E g a g a g a

F a f a f 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 A a1 a1 a2 B b1 b2 b2
A=X

R2 C c1 c2 c3 X a2 a1 Y n1 b1 Z n2 b3

R = R1 │X│ R2 A a1 a1 a2 B b1 b2 b2 C c1 c2 c3 Y b1 b1 n1 Z b3 b3 n2



Model Data Relasi

Halaman IV-5

Handout Pengantar Database

Toto Suharto



3.

Natural Join Analog dengan penulisan join, tapi tanpa penulisan kondisi, yaitu R1 │X│ R2. Contoh: SUPPLY S_Id P_Id s1 p1 s1 p3 s2 p2 s2 p3 s2 p4 s4 p4 SUPPLY Ass. 0381 0381 0381 0381 0381 0381 0381 Qty 160 60 140 50 90 100 PART_SKILL Ass. Type 0381 body 0381 body 0381 body 0381 fender 0381 fender P-Id p1 p2 p4 p1 p3 No_Req 10 12 22 26 26 Skill_Req machinist machinist welder machinist welder

│X│ PART_SKILL Type P_Id body p1 body p2 body p4 body p4 fender p1 fender p3 fender p3

S-Id s1 s2 s2 s4 s1 s1 s2

No_Req 10 12 22 22 26 26 26

Skill_Req machinist machinist welder welder machinist welder welder

Qty 160 140 90 100 160 60 50



Model Data Relasi

Halaman IV-6

Handout Pengantar Database

Toto Suharto



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.

B

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 K2

Algoritma Struktur Data Database Matematika

D2

Markum K3

D3

Kumkum

K4

Gambar 5.1. Contoh Model Data Jaringan



Model Data Jaringan

Halaman V-1

Handout Pengantar Database

Toto Suharto



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


Model Data Jaringan

Halaman V-2

Handout Pengantar Database

Toto Suharto



jaringan secara keseluruhan. Diagram struktur data mempunyai dua komponen dasar. Kedua komponen dasar tersebut adalah: • Kotak, yaitu simbol untuk menggambarkan record type atau entity. Record type yang digambarkan dengan simbol ini bisa dikomposisikan menjadi 0, 1 atau lebih atribut-atribut recordnya. • Anak panah, yaitu simbol untuk menggambarkan link antara dua atau lebih record type dan digunakan untuk menyajikan suatu set type. Cara untuk memahami pembuatan diagram struktur data ini adalah dengan melihat bagaimana suatu diagram E-R diubah menjadi diagram struktur data yang sesuai. Sebagai contoh, perhatikan diagram E-R pada Gambar 5.2. berikut ini yang merepresentasikan hubungan antara dua kelompok entity, yaitu Dosen dan Kuliah melalui satu relasi Mengajar. Relasi Mengajar adalah relasi biner satu-ke-banyak dengan atribut-atribut KdDsn dan KdKlh yang diturunkan dari atribut kunci kedua kelompok entity. Diagram E-R tersebut menunjukkan bahwa seorang dosen bisa mengajar beberapa mata kuliah dan satu mata kuliah diajar oleh satu orang dosen. Penggambaran diagram struktur data yang sesuai dengan diagram E-R. Sebagai contoh, misalkan dosen Abdul mengajar kuliah Algoritma, Markum mengajar kuliah Struktur Data dan Database, sedangkan Kumkum mengajar kuliah Matematika
1 DOSEN record type

ST n

set type record type

KULIAH

Gambar 5.2. Diagram Struktur Data DOSEN-KULIAH Pendefinisian suatu objek dari record type dideskripsikan dalam record. Misalkan kita punya suatu jaringan sebagai berikut:
RT1 RT2 RT3

RT4

Gambar 5.3. Contoh Skema Jaringan



Model Data Jaringan

Halaman V-3

Handout Pengantar Database

Toto Suharto



maka secara umum diseskripsikan sebagai berikut: RT RT1 { atribut} ST : ST1 owner : member : dan seterusnya. :

RT1 RT4

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

rt21

rt22

rt23
set type ST2

record type RT2

rt41

rt42

rt43

rt44

rt45

record type RT4

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

rt21

rt22

rt23
set type ST2

record type RT2

rt41

rt42

rt43

rt44

rt45

record type RT4

Gambar 5.5. Contoh Implementasi Secara Fisik yang Salah Transformasi Asosiasi (m-n) Menjadi (1-n)(n-1) Untuk transformasi asosiasi (m-n) menjadi (1-n)(n-1) didalam model jaringan, digunakan virtual record type. Pada prinsipnya virtual record type merupakan record type secara fisik, tetapi dalam implementasinya hanya berisi pointer. Setiap record dalam record type akan merepresentasikan 1 asosiasi.


Model Data Jaringan

Halaman V-4

Handout Pengantar Database

Toto Suharto



• b1 a1 • a2 • a3 • • b2 • b3 • b4

Gambar 5.6. (a) Transformasi (m-n) Menjadi (1-n)(n-1)
c1 a1 • a2 • a3 • c2 c3 c4 c5 c6

• b1 • b2 • b3 • b4

Gambar 5.6. (b) Hasil Transformasi (m-n) Menjadi (1-n)(n-1) Representasi secara logika untuk hasil transformasi di atas dengan diagram struktur data:

RTA

RTB

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

Gambar 5.7. Representasi Logika Transformasi (m-n) Menjadi (1-n)(n-1) Fungsi virtual record type dalam model jaringan adalah untuk menghindari adanya duplikasi record.

a1

a2

a3

b1
Model Data Jaringan

b2

b3

b4

b1

b4
Halaman V-5



Handout Pengantar Database

Toto Suharto



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

RTA ST1 VRTC ST2 RTB

2.

Untuk asosiasi (1-n) atau (1-1)
A 1
1

RTA ST1
1, n

R2 1, n B

RTB

Contoh: Hubungan antara aircraft dengan pilot
Aircraft m R1 n Pilot
n 1 1 n

Aircraft ST1 VRTC ST2 Pilot



Model Data Jaringan

Halaman V-6

Handout Pengantar Database

Toto Suharto



a1 • a2 • a3 •

• p1 • p2 • p3

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

Aircraft

Pilot

a1

a2

a3

RTa/c

C1

C2

C3

C4

C5

C6

VRTR1

p1

p2

p3

RTpilot

Gambar 5.8. Contoh Representasi Fisik Hubungan Aircraft-Pilot

5.3. Operasi Pada Model Data Jaringan
Operasi-operasi yang dapat dilakukan pada model data jaringan, sepert insert, delete, search atau update mengikuti konsep navigasi. Artinya, setiap akses akan dilakukan dengan mengikuti pointer. 1. Insert Mencakup dua macam insert, yaitu: a. Insert asosiasi (tanpa penambahan record) b. Insert record delete Pada operasi ini yang dihapus adalah asosiasinya.

2.

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

Model Data Jaringan

Halaman V-7

Handout Pengantar Database

Toto Suharto



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 Jaringan

Halaman V-8

Handout Pengantar Database

Toto Suharto



6 Model Data Hirarki
6.1. Pengertian Dasar
Model data hirarki adalah suatu model data yang tersusun dari record-record yang diorganisasikan sebagai kumpulan pohon. Seperti pada model data jaringan, pada model data ini data direpresentasikan sebagai kumpulan record sedangkan hubungan antar datanya direpresentasikan oleh suatu links. Sebagai contoh, lihat masalah akademik untuk hubungan antara data DOSEN dan KULIAH. root

D1

D2

D3

K1

K2

K3

K4

K5

Gambar 6.1. Contoh Model Data Hirarki Dosen-Kuliah Skema (diagram struktur) untuk contoh model data hirarki di atas adalah: DOSEN simpul induk

KULIAH

simpul anak (dependent)

Gambar 6.2. Skema Model Data Hirarki Dosen-Kuliah Jika dosen D2 dan D3 adalah pembimbing akademik kelas MIF-3 dan MIF-6, maka skemanya menjadi: DOSEN

KULIAH

KELAS

Gambar 6.3. Skema Model Data Hirarki Dosen-Kuliah-Kelas


Model Data Hirarki

Halaman VI-1

Handout Pengantar Database

Toto Suharto



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


Model Data Hirarki

Halaman VI-2

Handout Pengantar Database

Toto Suharto



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:


Model Data Hirarki

Halaman VI-3

Handout Pengantar Database

Toto Suharto



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.



Model Data Hirarki

Halaman VI-4

Handout Pengantar Database

Toto Suharto



7 Perancangan Database
P
erancangan database pada dasarnya merupakan proses untuk merepresentasikan dunia nyata (real world) yang dikehendaki kedalam sistem komputer, sehingga mudah dimengerti oleh pemakai dengan mempertimbangkan kemudahan implementasi dan pemrosesannya. Perancangan database dikerjakan setelah proses analisis dokumen, yang merupakan salah satu kegiatan dari perancangan sistem, selesai dilaksanakan. Database yang dirancang harus memiliki kemampuan untuk memberikan informasi yang diinginkan mengenai dunia nyata yang diwakilinya. Dengan demikian data tentang dunia nyata tersebut harus diorganisasi kemudian direpresentasikan dalam komputer, sehingga dapat diproses dengan efektif dan efisien. Beberapa tujuan yang ingin dicapai dari perancangan database diantaranya adalah: • memenuhi kebutuhan informasi pada saat ini dan yang akan datang • kemudahan pengembangan sesuai dengan perkembangan organisasi • penerapan mekanisme pengamanan data Untuk mencapai tujuan tersebut, ada dua tahapan proses yang harus dikerjakan pada saat perancangan database ini, yaitu perancangan logika dan perancangan fisik.

7.1. Perancangan Logika Database
Perancangan logika database merupakan proses pendefinisian entity dan relasi (relationship) dari dunia nyata yang dirancang, berdasarkan kebutuhan informasi dan pengolahan data dari organisasi yang bersangkutan. Entity adalah sesuatu (sekumpulan objek) yang dapat diidentifikasi dan dibedakan. Relasi adalah hubungan yang terjadi antara kelompok-kelompok entity. Perancangan logika database terdiri dari dari dua tahapan proses. Pertama, perancangan model konseptual atau model enterprise dari dunia nyata yang dirancang, disebut tahap pendeskripsian semantik. Kedua, perancangan model logika yaitu proses dekomposisi model konseptual untuk memperoleh model logika, disebut tahap dekomposisi skema basis data. Sasaran yang ingin dicapai dari


Perancangan Database

Halaman VII-1

Handout Pengantar Database

Toto Suharto



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

Perancangan Database

Halaman VII-2

Handout Pengantar Database

Toto Suharto



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 anomalianomali (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. 2. 3. Menentukan struktur untuk setiap tabel, meliputi nama field, jenis, lebar dan field kuncinya Menentukan nama database dan nama masing-masing tabel, dan lokasi dimana database akan disimpan (drive, directory). 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 Implementasi

4.



Perancangan Database

Halaman VII-3

Handout Pengantar Database

Toto Suharto



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. 2. Eksportir melakukan kontak dengan bagian Customer Support mengenai rencana pengiriman barang. 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. 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. 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. 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. 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.

3. 4.

5. 6.



Perancangan Database

Halaman VII-4

Handout Pengantar Database

Toto Suharto



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. 2. 3. 4. 5. 6. 7. 8. Pengiriman barang eksportir selalu merujuk pada tanggal labuh/berangkat kapal di setiap pelabuhan tujuan. Peti kemas selalu tersedia saat terjadi transaksi pemesanan (booking). Satu nomor booking hanya untuk satu tujuan pengiriman per voyage. Barang yang dikirim seorang eksportir mungkin memerlukan lebih dari satu peti kemas dengan berbagai tipe yang berbeda. Jadwal perjalanan kapal selalu sudah tersusun (dibuat) pada saat terjadi transaksi booking. 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. Jadwal perjalanan kapal untuk satu pelayaran pada tanggal tertentu mempunyai status penuh (full) jika tonase atau kapasitas maksimum kapal sudah digunakan seluruhnya. 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. 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. Pendapatan kapal tidak termasuk uang muka yang hangus dikarenakan keterlambatan pengiriman peti kemas ke pelabuhan.

9.

10.



Perancangan Database

Halaman VII-5

Handout Pengantar Database

Toto Suharto



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.



Perancangan Database

Halaman VII-6

Handout Pengantar Database

Toto Suharto



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 hubunganantar-entitas di atas, maka diagram E-R untuk masalah pengiriman peti kemas adalah sebagai berikut:
1 N M N

SHIPTYPE

TYPE

SHIP

SCHEDULE

VOYAGE

1
ASSIGN

Departure

Status

M
ROUTE
Date_of_AD

N 1 M
CONTAINER BRING

N

N
BOOKING PORT

N
Deposit

ORDERED

Amount
OrderStatus

1
EXPORTER

7.3.3. Pembuatan Model Data Relasi
Model data relasi adalah suatu model logika database yang menggambarkan entitas dan hubungan-antar-entitas dalam bentuk tabel-tabel yang disebut relasi. Kelompok entitas digambarkan dengan suatu relasi yang kolom-kolomnya menunjukkan identifikasi dari entitas tersebut. Demikian juga untuk hubunganantar-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)



Perancangan Database

Halaman VII-7

Handout Pengantar Database

Toto Suharto



2.

Dari SHIP  SCHEDULE  VOYAGE Kedua entitas wajib ada, dan ada atribut baru yang muncul pada hubunganantar-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 hubunganantar-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:



Perancangan Database

Halaman VII-8

Handout Pengantar Database BOOKING (Booking#, BookDate, BookStatus) EXPORTER (Exporter#, ExpName, Address, Phone) ORDERED (Booking#, Exporter#, Deposit, Amount, OrderStatus)

Toto Suharto



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 anomalianomali 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. 2. 3. Pada skema relasi SHIP ShipName → Callsign, Type Pada skema relasi SHIPTYPE Type → Tonage, MaxCapacity Pada skema relasi VOYAGE Voyage# → Destination



Perancangan Database

Halaman VII-9

Handout Pengantar Database

Toto Suharto



4. 5. 6. 7. 8. 9. 10. 11. 12.

Pada skema relasi SCHEDULE ShipName, Voyage#, Departure → Status Pada skema relasi ROUTE Voyage#, PortName, Date_of_AD → ∅ Pada skema relasi PORT PortName → Country Pada skema relasi BOOKING Booking# → BookDate, BookStatus Pada skema relasi ASSIGN Booking#, ShipName, PortName → ∅ Pada skema relasi BRING Booking#, Container# → ∅ Pada skema relasi ORDERED Booking#, Exporter# → Deposit, Amount, OrderStatus Pada skema relasi CONTAINER Container# → Type, Dimension 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.



Perancangan Database

Halaman VII-10

Handout Pengantar Database

Toto Suharto



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 1 ShipName CHAR 20 2 CallSign CHAR 10 3 Type NUMBER 2

Keterangan Nama kapal Nama (tanda) panggilan Kode jenis kapal

b.

Tabel ShipType Digunakan untuk menyimpan data jenis (spesifikasi) kapal. Struktur data untuk tabel ini adalah:



Perancangan Database

Halaman VII-11

Handout Pengantar Database Nama Tabel : SHIPTYPE Primary Key: ShipName Foreign Key: No. Nama Atribut Jenis Lebar 1 Type NUMBER 2 2 Tonage NUMBER 8

Toto Suharto



Keterangan Kode jenis kapal 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 1 Voyage# CHAR 2 Destination CHAR

Lebar 7 20

Keterangan Nomor voyage 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 1 PortName CHAR 2 Country CHAR

Lebar 20 20

Keterangan Nama pelabuhan Negara dari pelabuhan



Perancangan Database

Halaman VII-12

Handout Pengantar Database

Toto Suharto



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 1 Booking# CHAR 2 BookDate DATE 3 BookStatus CHAR

Lebar 20 10

Keterangan Nomor booking Tanggal booking 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, Foreign Key: Booking#, ShipName, No. Nama Atribut Jenis Lebar 1 Booking# CHAR 20 2 ShipName CHAR 20 3 PortName CHAR 20 PortName PortName Keterangan Nomor booking Nama kapal 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)



Perancangan Database

Halaman VII-13

Handout Pengantar Database

Toto Suharto



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 1 Container# CHAR 2 Type CHAR 3 Dimension CHAR

Lebar 15 8 9

Keterangan Nomor peti kemas Jenis peti kemas 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 1 Exporter# CHAR 2 ExpName CHAR 3 Address CHAR 4 Phone CHAR

Lebar 10 20 20 12

Keterangan Kode ekportir Nama eksportir Alamat eksportir 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. 1 2 3 4 5 6 Nama Atribut Type Status BookStatus Deposit Amount OrderStatus Jenis NUMBER CHAR CHAR NUMBER NUMBER CHAR Nilai Domain 1, 2, 3 dan 4 ‘Empty’, ‘Available’ dan ‘Full’ ‘1’, ‘2’, ‘3’, dan ‘4’ ≥ 0 ≥ 0 ‘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:



Perancangan Database

Halaman VII-14

Handout Pengantar Database

Toto Suharto



• • • c.

setiap nilai atribut kunci (primary key) harus unik nilai atribut yang ada pada setiap tabel boleh bernilai kosong (null) nilai atribut Phone harus unik

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

d.

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#));



Perancangan Database

Halaman VII-15

Handout Pengantar Database

Toto Suharto



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



Perancangan Database

Halaman VII-16

Handout Pengantar Database

Toto Suharto



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. Attribute Rule Dinyatakan melalui clause NOT NULL untuk menyatakan bahwa nilai atribut tidak boleh kosong, dan UNIQUE untuk menyatakan nilai atribut harus unik. 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. 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.

2.

3.

4.

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.



Perancangan Database

Halaman VII-17

Handout Pengantar Database

Toto Suharto



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



Perancangan Database

Halaman VII-18

Handout Pengantar Database

Toto Suharto



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');



Perancangan Database

Halaman VII-19

Handout Pengantar Database

Toto Suharto



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;


Perancangan Database

Halaman VII-20

Handout Pengantar Database

Toto Suharto



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;



Perancangan Database

Halaman VII-21

Sign up to vote on this title
UsefulNot useful