Modul Basis Data

MODUL PRAKTIKUM

BASIS DATA 1

Oleh :

TIM TEACHING BASIS DATA 1

PROGRAM STUDI TEKNIK INFORMATIKA

POLITEKNIK NEGERI TANAH LAUT

TAHUN 2019

1         Pengantar Basis Data

1.1         Pengenalan

 Basis data menyediakan fasilitas atau memudahkan dalam memproduksi informasi yang digunakan oleh pemakai untuk mendukung pengambilan keputusan. Hal inilah yang menjadi alasan dari penggunaan teknologi basis data pada saat sekarang (dunia bisnis).

Berikut contoh penggunaan Aplikasi database dalam dunia bisnis :

·         Bank : Pengelolaan data nasabah, akunting, semua transaksi perbankan

·         Bandara : Pengelolaan data reservasi, penjadwalan

·         Universitas : Pengelolaan pendaftaran, nilai, alumni

·         Pabrik : Pengelolaan data produksi, persediaan barang, pemesanan, agen

·         Kepegawaian : Pengelolaan data karyawan, gaji, pajak

·         Telekomunikasi : Pengelolaan data tagihan, jumlah pulsa

1.2         File Tradisional

Gambar 1.1 Sistem pemrosesan file untuk suatu universitas

Sebelumnya, sistem yang digunakan untuk mengatasi semua permasalahan bisnis pengelolaan data secara tradisional dengan cara menyimpan record-record pada file-file yang terpisah, yang disebut sistem pemrosesan file. Dimana masing-masing file diperuntukan hanya satu program aplikasi saja.

Kelemahan dari sistem pemrosesan File:

1.      Timbulnya data rangkap (redundancy data) dan ketidakkonsistensi data (Inconsistency data)

Karena file-file dan program aplikasi disusun oleh programmer yang berbeda, sejumlah informasi mungkin memiliki duplikasi dalam beberapa file. Sebagai contoh nama mata kuliah dan sks dari mahasiswa dapat muncul pada suatu file memiliki record-record mahasiswa dan juga pada suatu file yang terdiri dari record-record mata kuliah. Kerangkapan data seperti ini dapat menyebabkan pemborosan tempat penyimpanan dan biaya akses yang bertambah. Disamping itu dapat terjadi inkonsistensi data. Misalnya, apabila terjadi perubahan jumlah sks mata kuliah, sedangkan perubahan hanya diperbaiki pada file mata kuliah dan tidak diperbaiki pada file mahasiswa. Hal ini dapat mengakibatkan kesalahan dalam laporan nilai mahasiswa.

2.      Kesukaran dalam mengakses data

Munculnya permintaan-permintaan baru yang tidak diantisipasikan sewaktu membuat program aplikasi, sehingga tidak memungkinkan untuk pengambilan data.

3.      Data terisolir (Isolation data)

Karena data tersebar dalam berbagai file, dan file-file mungkin dalam format-format yang berbeda, akan sulit menuliskan program aplikasi baru untuk mengambil data yang sesuai.

4.      Masalah pengamanan (Security problem)

Tidak semua pemakai diperbolehkan mengakses seluruh data. Bagian Mahasiswa hanya boleh mengakses file mahasiswa. Bagian Mata kuliah hanya boleh mengakses file mata kuliah, tidak boleh mengakses file mahasiswa. Tetapi sejak program-program aplikasi ditambahkan secara ad-hoc maka sulit melaksanakan pengamanan seperti yang diharapkan.

5.      Data Dependence

Apabila terjadi perubahan atau kesalahan pada program aplikasi maka pemakai tidak mengakses data.

1.3         Pendekatan Basis Data

Seiring dengan berjalannya waktu lambat laun sistem pemrosesan file mulai ditinggalkan karena masih bersifat manual, yang kemudian dikembangkanlah sistem pemrosesan dengan pendekatan database.

Gambar 1.2 Sistem basis data untuk suatu universitas

Pada sistem ini record-record data disimpan pada satu tempat yakni database dan diatara program aplikasi maupun pemakai terdapat DBMS (Dtabase Management Sistem).

1.4         Konsep Basis Data dan Sistem Manajemen Basis Data (SMBD)

Data adalah Representasi fakta dunia nyata yang mewakili suatu objek seperti manusia (pegawai, mahasiswa, pembeli), barang, hewan, peristiwa, konsep, keadaan dan sebagainya yang direkam dalam bentuk angka, huruf, simbol, teks, gambar, bunyi atau kombinasinya.

Basis Data adalah Sekumpulan data yang terintegrasi yang diorganisasi untuk memenuhi kebutuhan para pemakai di dalam suatu organisasi.

DBMS(Database Management Systems) adalah perangkat lunak yang menangani semua pengaksesan ke database.

Seorang user dari sistem dapat melakukan operasi-operasi terhadap file-file tersebut. Operasi yang dapat dilakukan antara lain :

1.      Menambah file baru ke dalam database

2.      Menambah data ke dalam file yang sudah ada

3.      Mengambil (retrieve) dari file yang sudah ada

4.      Merubah data dari file yang sudah ada

5.      Menghapus data dari file yang sudah ada

6.      Menghapus file dari database

Beberapa istilah yang digunakan pada basis data

1.      Enterprise:

Suatu bentuk organisasi seperti: bank, universitas, rumah sakit, pabrik, dsb. Data yang disimpan dalam basis data merupakan data operasional dari suatu enterprise. Contoh data operasional: data keuangan, data mahasiswa, data pasien.

2.      Entitas:

Suatu obyek yang dapat dibedakan dari lainnya yang dapat diwujudkan dalam basis data.

Contoh Entitas dalam lingkungan Bank terdiri dari: Nasabah, Simpanan, Hipotik

Contoh Entitas dalam lingkungan Pabrik terdiri dari: Supplier, Part, Shipment

Kumpulan dari entitas disebut Himpunan Entitas.

Contoh: semua nasabah, semua supplier

3.    Atribut (Elemen Data):

Karakteristik dari entitas tsb.

Contoh Entitas Nasabah, atributnya terdiri dari: Kode Nasabah, Nama Nasabah, Alamat Nasabah.

4.    Nilai Data (Data Value):

Isi data / informasi yang tercakup dalam setiap elemen data.

Contoh Atribut Nama Nasabah dapat berisi Nilai Data: Nina, Rika, Gema, dsb.

5.    Kunci Elemen Data (Key Data Elemen):

Tanda pengenal yang secara unik mengidentifikasikan entitas dari suatu kumpulan entitas.

Contoh Entitas Nasabah yang mempunyai atribut-atribut Kode Nasabah, Nama Nasabah, Alamat Nasabah, dsb menggunakan Kunci Elemen Data Kode Nasabah.

6.    Record Data:

Kumpulan isi elemen data (atribut) yang saling berhubungan.

Contoh: kumpulan Atribut Kode Nasabah, Nama Nasabah, Alamat Nasabah berisikan "931109", "Nina", "Jl. Keamanan 63A".

1.5         Kelebihan dan Kekurangan dari Sistem Basis Data

1.5.1        Kelebihan Sistem Basis Data

1.      Data dapat dipakai secara bersama.

Data dapat dipakai secara bersama-sama oleh beberapa program aplikasi (secara batch maupun on-line) pada saat bersamaan.

2.      Data dapat distandarisasi.

Dengan adanya pengontrolan yang terpusat maka DBA dapat menerapkan standarisasi data yang disimpan sehingga memudahkan pemakaian, pengiriman maupun pertukaran data.

3.      Mengurangi redudancy (kerangkapan data).

Dalam basis data hanya mencantumkan satu kali saja field yang sama yang dapat dipakai oleh semua aplikasi yang memerlukannya.

4.      Kemandirian data.

Dapat digunakan oleh bermacam-macam program aplikasi tanpa harus merubah format data yang sudah ada.

5.      Keamanan data terjamin.

DBA dapat memberikan batasan-batasan pengaksesan data, misalnya dengan memberikan password dan pemberian hak akses bagi user (missal: modify, delete, insert, retrieve). Data dapat dilindungi dari pemakai yang tidak berwenang.

6.      Terpeliharanya keselarasan (ke-konsistenan data)

Apabila ada perubahan data pada aplikasi yang berbeda maka secara otomatis perubahan itu berlaku untuk keseluruhan.

7.      Terpeliharanya integritas data

Jika kerangkapan data dikontrol dank e konsistenan data dapat dijaga maka data menjadi akurat.

Memelihara keterpaduan data berarti data harus akurat, hal ini sangat erat hubungannya dengan pengontrolan kerangkapan data dan pemeliharaan keselarasan data.

1.5.2        Kekurangan Sistem Basis Data

1.      Storage yang digunakan menjadi besar.

2.      Dibutuhkan tenaga yang terampil dalam mengelola data.

3.      Perangkat lunaknya mahal.

4.      Kerusakan pada sistem basis data dapat mempengaruhi departemen yang terkait.

1.6         Komponen Sistem Basis Data

1.      Data

Disimpan secara terpadu (integrated) dan dapat dipakai secara bersama (shared).

2.      Perangkat Keras

Terdiri dari unit penyimpanan sekunder.

Contoh : disk, drum

3.      Perangkat Lunak

Menghubungkan antara pemakai dan data di dalam sistem basis data

4.      Pengguna Basis Data

1.7         Pengguna Basis Data

a.       System Engineer.

Tenaga ahli yang bertanggungjawab atas pemasangan Sistem Basis Data, dan juga mengadakan peningkatan dan melaporkan kesalahan dari sistem tersebut kepada pihak penjual.

b.      Administrator Basis Data.

Tenaga ahli yang mempunyai tugas untuk mengontrol sistem basis data secara keseluruhan, meramalkan kebutuhan akan sistem basis data, merencanakannya dan mengaturnya.

c.       Programmer.

Membuat program aplikasi yang diperlukan oleh pemakai akhir dengan menggunakan data yang terdapat dalam sistem basis data.

d.      Pemakai Akhir.

Tenaga ahli yang menggunakan data untuk mengambil keputusan yang diperlukan untuk kelangsungan usaha

Pemakai Akhir

Ada beberapa jenis/tipe pemakai terhadap suatu system basis data yang dapat dibedakan berdasarkan cara mereka berinteraksi terhadap system:

Ø  Programmer aplikasi

Pemakai yang berinteraksi dengan basis data melalui Data manipulation Language (DML), yang disertakan (embedded) dalam program yang ditulis dalam bahasa pemrograman induk (seperti C, pascal, cobol, dll).

Ø  User mahir (casual user)

Pemakai yang berinteraksi dengan sistem tanpa menulis modul program. Mereka menyatakan query (untuk akses data) dengan bahasa query yang telah disediakan oleh suatu DBMS.

Ø  User umum (end user/naïve user)

Pemakai yang berinteraksi dengan system asis data melalui pemanggilan satu program aplikasi permanent (executable program) yang telah ditulis/disediakan oleh suatu DBMS.

Ø  User khusus (specialized/sophisticated user)

Pemakai yang menulis aplikasi basis data non konvensional, tetapi untuk keperluan-keperluan khusus seperti aplikasi AI, Sistem Pakar, Pengolahan Citra, dll, yang bias saja mengakses basis data dengan/tanpa DBMS yang bersangkutan.

1.8         Database Administrator (DBA)

DBA memiliki tugas:

1.      Menentukan isi basis data, yaitu dengan menganalisa kebutuhan aplikasi masing-masing pemakai dan menentukan entity-entity beserta isi yang diperlukan oleh enterprise tsb

2.      Menentukan struktur storage dan strategi akses, yaitu bagaimana data tsb diwujudkan di dalam basis data dan bagaimana mengaksesnya.

3.      Sebagai penghubung dari para pemakai, untuk meyakinkan apakah data yang diperlukan pemakai sudah tersedia seluruhnya.

4.      Menentukan prosedur-prosedur pengecekan otorisasi dan validasi, yaitu untuk memberikan pengamanan isi basis data terhadap kesalahan proses atau kesalahan pakai.

5.      Menentukan strategi untuk back up dan recovery, yaitu untuk menyelamatkan isi basis data bila sewaktu-waktu terjadi kesalahan baik oleh manusia, hardware maupun software.

6.      Memonitor penampilan atau keandalan sistem dan selalu menaruh perhatian serta tindakan segera terhadap segala perubahan kebutuhan sehingga sistem selalu memberikan penampilan yang terbaik terhadap enterprise tsb. 

2         Konsep dan Arsitektur Basis Data

2.1         Model, Skema dan Instances Data

Dalam pembuatan basis data, agar basis data yang dibuat bisa sesuai dengan yang diinginkan maka diperlukan proses perancangan terlebih dahulu. Dimana dalam proses ini dilakukan pendeskripsian data dalam bentuk schema serta pembuatan model datanya. Untuk itu kita perlu mengetahui konsep dari schema dan model data dalam basis data.

Schema merupakan deskripsi dari basis data berupa abstraksi data yang terdiri dari nama dan tipe dari record, item-item data, serta constraint dari basis data.

Sedangkan model data merupakan alat utama yang digunakan untuk menyediakan abstraksi data. Sehingga model data merupakan penggambaran dari schema basis data.

Ada tiga kategori dalam model data, yaitu:

1.      Model data tingkat tinggi

Model data ini menggunakan konsep seperti entity, attribute, dan relationship.

2.      Model data representasional atau implementasi

Termasuk dalam jenis ini adalah model data relasional, jaringan, dan hirarki. Dimana data disajikan dengan menggunakan struktur record (record-based data model)

3.      Model data fisik

Model data ini menggambarkan bagaimana data disimpan dalam komputer yaitu dalam format-format record, urutan-urutan record, dan access path. Model data nantinya akan menggambarkan setiap level dari basis data yang tampak seperti pada gambar berikut ini.

2.2         Arsitektur Basis Data

Arsitektur DBMS (DataBase Management System) ini dikenal dengan nama arsitektur tiga skema (three-schema architecture) dimana fungsi ini untuk memisahkan antara basis data fisik dengan program aplikasi user. Skema-skema tersebut adalah sebagai berikut:

o   Internal level (internal schema)

Menjelaskan struktur penyimpanan fisik dari basis data menggunakan model data fisik.

o   Conceptual level (conceptual schema)

Menjelaskan struktur penyimpanan dari keseluruhan basis data untuk dipakai oleh satu komunitas user menggunakan model data tingkat tinggi atau model data implementasi.

o   External atau view level (external schema atau user view)

Menjelaskan sebagian basis data yang menjadi perhatian dari sekelompok user tertentu menggunakan model data tingkat tinggi atau model impelementasi.

2.3         Independensi Data

Arsitektur tiga skema dapat digunakan untuk menjelaskan konsep independensi data (data independence) yang dapat didefinisikan sebagai kemampuan untuk merubah skema pada suatu level dari system basis data tanpa harus menyebabkan perubahan dari skema pada tingkat yang lebih tinggi

Terdapat dua jenis independensi data, yaitu:

o   Logical data independence

Yaitu kemampuan untuk merubah skema konseptual termasuk juga constraint dari basis data tanpa harus merubah skema eksternal. Hanya definisi dari view dan mapping yang perlu dirubah dalam DBMS

o   Physical data independence

Yaitu kemampuan untuk merubah skema internal tanpa harus merubah skema konseptual (eksternal) yang mungkin diperlukan karena file-file fisik yang harus diorganisasikan kembali (misalnya membuat struktur akses tambahan untuk meningkatkan kinerja membacaan atau perubahan data).

2.4         Database Languages

Basis data memiliki bahasa yang digunakan untuk membuat spesifikasi skema konseptual dan internal, serta mapping antara keduanya. Dalam setiap DBMS minimal terdapat empat jenis bahasa yaitu:

1.      DDL (Data Definition Language,)

Yaitu bahasa yang digunakan untuk menspesifikasikan kedua skema konseptual dan internal, jika dalam DBMS tidak ada pemisahan yang ketat antara kedua level tersebut. Jika DBMS memiliki pemisahan yang jelas, maka DDL hanya digunakan untuk menspesifikasikan skema konseptual.

2.      VDL (View Definition Language)

Yaitu bahasa yang digunakan untuk menspesifikasikan user view dan mapping menjadi skema konseptual pada DBMS yang memiliki pemisah yang jelas antara skema konseptual dan internal.

3.      DML (Data Manipulation Language)

Yaitu bahasa yang digunakan untuk melakukan manipulasi data (setelah dilakukan proses kompilasi skema konseptual).

4.      SQL (Structured Query Language)

Yaitu bahasa yang digunakan untuk manipulasi basis data relasional yang mengintegrasikan DDL, DML, dan VDL. Pada DML terdapat dua jenis bahasa, yaitu:

a.       High-Level (Non_procedural) DML.

-         digunakan secara interaktif (interpreter)

-         dapat dijadikan satu dengan general purpose programming language (embedded). High-Level DML yang biasa digunakan secara interaktif disebut “Query Language”.

b.      Low-Level (Proedural) DML.

Digunakan secara embedded dalam suatu general purpose programming language

Bilamana kedua jenis DML diatas digunakan secara “embedded”, maka : bahasa pemrograman yang digunakan disebut sebagai “Host Language” DML-nya disebut “Sub Language”.

3         Basis Data Relasional

3.1         Pengantar Basis Data Relasional

Database Relasional sebenarnya adalah suatu konsep penyimpanan data terstruktur, sebelum konsep database relasional muncul sudah ada uda model database yaitu network database dan hierarchie database. Teori database relasional di kemukakan pertamakali oleh Dr. E.F. Codd.

Dalam database relasional, data disimpan dalam bentuk relasi atau tabel dua dimensi, dan antara tabel satu dengan tabel lainnya terdapat hubungan atau relationship sehingga dapat di simpulkan, database adalah kumpulan dari sejumlah tabel yang saling hubungan atau saling keterkaitan. Kumpulan dari data yang diorganisasikan sebagai tabel tadi disimpan dalam bentuk data elektronik di dalam harddisk komputer dan dikelompokan secara logis berdasarkan schema user.

Untuk membuat struktur tabel, mengisi data ke tabel, memperbarui data dan menghapus data dari tabel diperlukan software. Perangkat lunak yang digunakan membuat tabel, isi data, ubah data, dan hapus data disebut Relational Database Management System atau yang biasa di singkat dengan RDBMS. Sedangkan perintah yang digunakan untuk membuat tabel, mengisi tabel, mengubah tabel, dan menghapus data disebut perintah SQL (Baca : Sequel) yang merupakan singkatan dari Structure Query Language. Jadi, setiap aplikasi perangkat lunak RDBMS pasti bisa dipakai untuk menjalankan perintah SQL.

Sebenarnya fungsi RDBMS bukan cuma untuk buat tabel, isi data, ubah data dan hapus data. Untuk manajemen data dalam skala yang besar dan agar bisa mendukung proses bisnis yang kontinyu atau terus menerus dan real time suatu Relational Database Management System dituntut untuk mempunyai kemampuan manajemen user dan keamanan data yang terjamin, mencadangkan data dan mengembalikan data serta kemampuan lainnya yang berkaitan dengan kecepatan pemrosesan data.
Sebuah aplikasi perangkat lunak RDBMS yang ada di pasaran saat ini dan paling sering digunakan adalah Oracle Database yang di keluarkan oleh Oracle Corporation.

Contoh tabel dan keterhubungannya:

MHS

NPM	NAMA	ALAMAT	TGL_LAHIR
10200123	SULAEMAN	TANGERANG	8 MARET 1983
30100143	DIANA	BOGOR	15 NOVEMBER 1983
50100333	SADIKIN	JAKARTA	24 APRIL 1982
20100296	THAMRIN	TANGERANG	13 MEI 1983
10200928	LINA	JAKARTA	8 DESEMBER 1982
50100375	IRAWATI	BEKASI	7 JULI 1982

MTKULIAH

KD_MK	NAMA_MK	SKS
KK021	BASIS DATA	2
KD034	SIMULASI	3
KK044	STRUKTUR DATA	2
DU025	MIKROPROSESOR	4
KK018	KALKULUS	2

NILAI

NPM	KD_MK	NIL_MID	NIL_UAS
10200928	KK021	60	80
50100375	KK044	90	85
50100333	KK021	50	40
30100143	KK018	30	50
10200928	KK044	70	40
10200123	KK021	65	45
20100296	KK021	60	60
50100333	DU025	77	75

Keuntungan Basis Data Relasional

1. Bentuknya sederhana
2. Mudah untuk melakukan berbagai operasi data

Istilah dalam Basis Data Relasional :

     Relasi                          : Sebuah tabel yang terdiri dari beberapa kolom dan beberapa baris

     Atribut                       : Kolom pada sebuah relasi

     Tupel                         : Baris pada sebuah relasi

     Domain                       : Kumpulan nilai yang valid untuk satu atau lebih stribut

     Derajat (degree)        : Jumlah atribut dalam sebuah relasi

     Cardinality                : Jumlah tupel dalam sebuah relasi

3.2         Kunci

Super Key

Satu atribut / kumpulan atribut yang secara unik mengidentifikasi sebuah tupel di dalam relasi

Candidate Key

Atribut di dalam relasi yang biasanya mempunyai nilai unik

Primary Key

Candidate key yang dipilih untuk mengidentifikasikan tupel secara unik dalam relasi

Alternate Key

Candidate key yang tidak dipilih sebagai primary key

Foreign Key

Atribut dengan domain yang sama yang menjadi kunci utama pada sebuh relasi tetapi pada relasi lai atribut tersebut hanya sebagai atribut biasa

3.3         Diagram Skema

Skema database yang memiliki relasi satu sama lain dan di dalamnya terdapat primary key dan foreign key bisa digambarkan dengan Skema Diagram. Salah satu contoh skema diagram dapat dilihat pada gambar berikut.

Contoh skema diagram di atas berisi informasi setiap tabel yang memiliki primary key dan foreign key tertentu yang kemudian saling berhubungan satu sama lain sehingga membentuk sebuah skema basis data yang lengkap. 

4         Desain Basis Data dengan Model E-R

4.1         Pengantar Model E-R

Model E-R menggambarkan dunia nyata dalam dua kelompok yaitu entitas dan relationship. Entitas adalah objek/konsep yang memiliki karakter yang spesifik. Contoh entitas dalam domain perbankan adalah Nasabah dan Accout. Relationship adalah hubungan antara entitas. Contoh relationship yang dalam domain perbankan adalah relationship antara entitas nasabah dengan acccount (nasabah memiliki account).

Notasi untuk entitas pada diagram E-R adalah menggunakan segiempat. Sedangkan relationship menggunakan simbol diamond. Contoh:

4.2         Entitas dan Atribut

Atribut mendeskripsikan karakteristik entitas dan atribut. Contoh: atribut entitas nasabah adalah nomor nasabah, nama dan alamat. Pada diagram E-R, atribut digambarkan dengan lingkaran.

Atribut utama yang menjadi pembeda satu record dengan record lainnya disebut primary key. Pada gambar diatas “nomor” adalah primary key entitas nasabah dan “nomor acc” adalah primary key account.

Pemilihan entitas dan relationship dalam suatu domain masalah cenderung bersifat subyektif, setiap perancang database dapat menghasilkan rancangan yang berbeda-beda.

Contoh: Nasabah memiliki atribut Alamat. Alamat sendiri sebenarnya bisa dianggap sebagai suatu entitas dengan atribut “Kode Pos” dan “Kabupaten/kota”. Sehingga diagram untuk entitas nasabah dapat diubah menjadi:

Mana yang paling benar? Apakah alamat sebagai atribut ataukah alamat sebagai entitas?

Jawabannya tergantung pada domain masalah. Jika alamat sebagai atribut (Gambar 2), berarti satu nasabah memiliki tepat satu alamat. Sedangkan untuk alamat sebagai entitas (Gambar 3) , satu nasabah dapat memiliki lebih dari satu alamat dan satu alamat dapat ditempati lebih dari satu nasabah. Artinya solusi kedua cakupannya lebih luas dibandingkan yang pertama.

Tetapi untuk atribut “Nama” yang menempel kepada entitas “Nasabah” hal yang sama akan sulit dilakukan. Ini disebabkan atribut “Nama” secara umum tidak dapat dianggap sebagai suatu entitas yang terpisah.

4.3         Weak Entity dan Strong Entity

Strong entity adalah entitas yang berdiri sendiri dan sedangkan weak entity adalah entitas yang bergantung kepada strong entity. Weak entity   akan bergantung kepada strong entity dalam hubungan one to many.

Strong Entity memiliki primary key sedangkan weak entity tidak memiliki atribut yang dapat dijadikan primary key. Walaupun secara konsep tidak memiliki primary key, kita dapat menambahkan discriminator untuk membedakan setiap record.

Contoh: catatan transaski sebuah account adalah weak entity yang bergantung kepada account. Jika account dihapus maka otomatis catatan transaksi account tersebut juga turut terhapus. Pada diagram E-R, weak entity digambarkan dengan kotak dengan garis ganda.

Atribut “Trans Number” berperan sebagai discriminator untuk entitas transaksi.

Terlihat bahwa hubungan antar entitas account dan transaksi adalah one to many. Artinya satu account bisa memiliki beberapa transaksi (debet, kredit, bunga dst). Apa yang akan terjadi kalau hubungan antara account dan transaksi adalah one to one? Pada kasus tersebut, entitas transaksi bisa digabung dengan entitas account. Bagaimana jika hubungannya many to many? Silahkan menjadi latihan.

5         Entity Relationship Diagram (ERD)

5.1         Konsep Dasar ERD

Entity Relationship Diagram (ERD) adalah pemodelan awal basis data yang paling banyak digunakan. ERD dikembangkan berdasarkan teori himpunan dalam bidang matematika. Tidak hanya perangkat lunak yang memiliki alur hidup, dalam membuat perencanaan basis data juga memiliki alur hidup atau Database Life Cycle (DBLC). Alur hidup basis data dapat dilihat pada gambar berikut:

Gambar 5.1 Alur hidup basis data

Fase-fase DBLC antara lain:

1.      Analisis kebutuhan

Hal-hal yang harus dilakukan pada tahap ini adalah:

-          Didefinisikan dengan mewawancarai produsen dan pemakai data, data apa sajakah yang perlu untuk disimpan dan terkait dengan aplikasi komputer yang akan dikembangkan

-          Membuat kontrak spesifikasi basis data

-          ERD sebagai bagian dari desain konseptual

2.      Desain logikal basis data

Pada tahap ini harus dibuat rancangan topik basis data. Biasanya pada tahap ini dibuat Conceptual Data Model (CDM).

3.      Desain fisikal basis data

Pada tahap ini harus dibuat rancangan fisik basis data. Biasanya pada tahap ini dibuat Physical Data Model (PDM).

4.      Implementasi

-          Membuat Query SQL

-          Aplikasi ke DBMS atau file

5.2         Komponen ERD

1.      Entitas

Entitas adalah suatu obyek yang dapat dikenali dari obyek yang lain. Contoh: seseorang yang khusus, perusahaan, peristiwa, tanaman dan lain-lain. Entitas mempunyai atribut, contoh: seseorang mempunyai nama dan alamat. Kumpulan entity adalah suatu kumpulan entity dengan tipe yang sama yang berbagi properti yang sama pula. Contoh: kumpulan orang, perusahaan, tanaman, tempat liburan dan lain-lain.

2.      Atribut

Entitas ditampilkan oleh sekumpulan atribut, yang mana properti deskriptifnya dikuasai oleh seluruh anggota dalam kumpulan Entitas.

Tipe atribut:

-          Simple (sederhana) dan composite (gabungan) attributes.

-          Single-valued (satu-fungsi) dan multi-valued (multi-fungsi) attributes. Contoh: atribut multi-fungsi: nomor telepon

-          Derived (turunan) attributes: dapat diperhitungkan dari atribut lain Contoh: umur, tanggal kelahiran.

3.      Relationship

Relationship adalah kesesuaian antar beberapa entitas. Relationship set adalah hubungan matematika antara entity n>2, tiap bagiannya diambil dari satuan entity {(e1, e2, … en) | e1 Î E1, e2 Î E2, …, en Î En} dimana (e1, e2, …, en) adalah relationship. Atribut dapat merupakan properti dari relationship set. Sebagai contoh: depositor merupakan relationship set antara entity sets customer dan account mungkin beratribut access-date. Mengacu pada jumlah entity sets yang terlibat dalam relationship set. Relationship sets yang melibatkan dua entity sets adalah binary (atau tingkat dua). Umumnya, hampir semua relationship sets dalam sistem database adalah binary. Relationship sets mungkin melibatkan lebih dari dua entity sets. Contoh: misal seorang pegawai bank bekerja (bertanggung jawab) dalam beberapa cabang, dengan tugas yang berlainan dalam setiap cabang yang berlainan pula. Maka disini terdapat relationship set ternary antara entity sets pegawai (employee), tugas (job) dan cabang (branch). Relationships antara lebih dari dua entity sets sangat jarang.

Berikut adalah simbol-simbol ERD dengan notasi Chen:

Tabel 5.1 Simbol-simbol ERD dengan notasi Chen

5.3         Pemetaan Kardinalitas

Mengungkap jumlah entitas ke entitas yang lain bisa dihubungkan melalui relationship set. Cardinalitas pemetaan paling banyak digunakan dalam menggambarkan relationship sets biner. Untuk relationship set biner cardinalitas pemetaan harus merupakan salah satu dari tipe berikut:

1.      One to one (satu ke satu)

2.      One to many (satu ke banyak)

3.      Many to one (banyak ke satu)

4.      Many to many (banyak ke banyak)

Pemetaan kardinalitas dari elemen A ke elemen B diilustrasikan sebagai berikut:

Gambar 5.2 (a) One to one, (b) One to many

Gambar 5.3 (a) Many to one, (b) Many to many

Aturan untuk perancangan database:

1.      Tiap baris harus berdiri sendiri (independent): tidak tergantung baris-baris yang lain, dan urutan baris tidak mempengaruhi model database.

2.      Tiap baris harus unik: tidak boleh ada 2 atau lebih baris yang sama persis.

3.      Kolom harus berdiri sendiri (independent): tidak tergantung kolom-kolom yang lain, dan urutan kolom tidak mempengaruhi model database.

4.      Nilai tiap kolom harus berupa satu kesatuan: tidak berupa sebuah daftar.

Tahap pembuatan database

1.      Tentukan entitas

Tentukan entities (object-object dasar) yang perlu ada di database.

Sifat-sifat entity:

·         Signifikan: memang perlu disimpan di database

·         Umum: tidak menunjuk pada sesuatu yang khusus

·         Fundamental: dapat berdiri sendiri sebagai entity yang dasar dan independent

·         Unitary: merupakan satu kesatuan yang tidak dapat dipecah lagi

2.      Tentukan atribut

Tentukan attributes (sifat-sifat) masing-masing entity sesuai kebutuhan database:

·         Tentukan sifat-sifat (fields atau kolom) yang dimiliki tiap entity, serta tipe datanya.

·         Attribute yang sesuai harus:

Ø  Signifikan: memang penting dan perlu dicatat di dalam database

Ø  Bersifat langsung (direct), bukan derived. Contoh attribute direct: tanggal_lahir. Contoh attribute derived: umur

·         Tentukan attribute yang menjadi Primary Key untuk entity yang bersangkutan.

·         Jika satu attribute tidak cukup, gabungan beberapa attribute bisa menjadi Composite Primary Key.

·         Jika Composite Primary Key banyak (lebih dari 3 attribute), sebaiknya menambahkan attribute buatan yang menjadi Primary Key yang tunggal.

3.      Tentukan relationship

Tentukan relationships (hubungan-hubungan) di antara entities tersebut :

·         Tentukan jenis hubungan di antara entity yang satu dengan entities yang lain.

·         Macam hubungan ada 3:

Ø  One-to-one (1:1)

Ø  One-to-many (1:n)

Ø  Many-to-many (m:n)

·         Dalam membentuk hubungan di antara 2 entities, tentukan attribute mana yang digunakan untuk menghubungkan kedua entities tersebut.

·         Tentukan entity mana yang menjadi tabel utama, dan entity mana yang menjadi tabel kedua.

·         Attribute (dari tabel utama) yang menghubungkannya dengan tabel kedua menjadi Foreign Key di tabel kedua.

4.      Pembuatan ERD

·         Buat Entity Relationship Diagram (ERD) berdasarkan hasil dari Tahap 3.

·         Ada berbagai macam notasi untuk pembuatan ERD.

·         Anda bisa menggunakan software khusus untuk menggambar ERD.

5.      Normalisasi basis data

6.      Implementasi basis data

5.4         Contoh Kasus

Rancanglah basis data untuk menyelesaikan permasalahan berikut ini.

Suatu perusahaan software diminta membuatkan basis data yang akan menangani data-data perbankan. Data-data yang akan ditanganinya adalah: data pribadi mengenai nasabah, data account deposit yang dimiliki oleh nasabah, cabang bank di mana nasabah membuka depositnya, dan data transaksi yang dilakukan nasabah.

Langkah-langkah perancangan database perbankan:

1.      Menentukan entitas (objek-objek dasar) yang perlu ada di database

·         nasabah: menyimpan semua data pribadi semua nasabah

·         rekening: menyimpan informasi semua rekening yang telah dibuka

·         cabang_bank: menyimpan informasi tentang semua cabang bank

·         transaksi: menyimpan informasi tentang semua transaksi yang telah terjadi

2.      Menentukan atribut dari masing-masing entitas sesuai kebutuhan database

·         nasabah:

o   id_nasabah (PK)

o   nama_nasabah

o   alamat_nasabah

·         rekening:

o   no_rekening (PK)

o   pin

o   saldo

·         cabang_bank:

o   kode_cabang (PK)

o   nama_cabang

o   alamat_cabang

·         transaksi:

o   no_transaksi (PK)

o   jenis_transaksi (kredit atau debit)

o   tanggal (tanggal terjadinya transaksi)

o   jumlah (besarnya transaksi)

3.      Menentukan relationship antar entitas

·         Nasabah memiliki rekening

o   Tabel utama: nasabah

o   Tabel kedua: rekening

o   Relationship: 1:m

o   Atribut penghubung: id_nasabah (FK id_nasabah di rekening)

·         Rekening terlibat dalam transaksi

o   Tabel utama: rekening

o   Tabel kedua: transaksi

o   Relationship: 1:m

o   Atribut penghubung: no_rekening (FK no_rekening di transaksi)

·         Cabang_bank menangani rekening

o   Tabel utama: cabang_bank

o   Tabel kedua: rekening

o   Relationship: 1:m

o   Atribut penghubung: kode_cabang (FK kode_cabang di rekening)

4.      Menggambar ERD diagram

6         Normalisasi

6.1         Pengantar Normalisasi

Normalisasi database merupakan suatu pendekatan sistematis untuk meminimalkan redundansi data pada suatu database agar database tersebut dapat bekerja dengan optimal. Jika anda seorang database administrator ketika terjadi sesuatu pada database seperti penurunan kinerja, mungkin anda akan ditanya apakah database tersebut telah di normalisasi?

Tujuan Normalisasi Database

Tujuan normalisasi database adalah untuk menghilangkan dan mengurangi redudansi data dan tujuan yang kedua adalah memastikan dependensi data (Data berada pada tabel yang tepat).

Jika data dalam database tersebut belum di normalisasi maka akan terjadi 3 kemungkinan yang akan merugikan sistem secara keseluruhan.

INSERT Anomali: Situasi dimana tidak memungkinkan memasukkan beberapa jenis data secara langsung di database.

DELETE Anomali: Penghapusan data yang tidak sesuai dengan yang diharapkan, artinya data yang harusnya tidak terhapus mungkin ikut terhapus.

UPDATE Anomali: Situasi dimana nilai yang diubah menyebabkan inkonsistensi database, dalam artian data yang diubah tidak sesuai dengan yang diperintahkan atau yang diinginkan.

6.2         Bentuk-Bentuk Normal dan Kelebihannya

1.      First Normal Form 1NF

Bentuk normalisasi 1NF ini mengelompokkan beberapa tipe data atau kelompok data yang sejenis agar dapat dipisahkan sehingga anomali data dapat di atasi. Contoh adalah ketika kita ingin menghapus, mengupdate, atau menambahkan data peminjam, maka kita tidak bersinggungan dengan data buku atau data penerbit. Sehingga inkonsistensi data dapat mulai di jaga.

2.      Second Normal Form 2NF

Bentuk kedua ini adalah tidak boleh ada field yang berhubungan dengan field lainnya secara fungsional. Contoh Judul Buku tergantung dengan id_Buku sehingga dalam bentuk 2NF judul buku dapat di hilangkan karena telah memiliki tabel master tersendiri.

3.      Third Normal Form 3NF

Normalisasi database dalam bentuk 3NF bertujuan untuk menghilangkan seluruh atribut atau field yang tidak berhubungan dengan primary key. Dengan demikian tidak ada ketergantungan transitif pada setiap kandidat key.

4.      Boyce Codd Normal Form BCNF

Merupakan sebuah teknik normalisasi database yang sering disebut 3.5NF, memiliki hubungan yang sangat erat dengan bentuk 3NF. Pada dasarnya adalah untuk menghandle anomali dan overlooping yang tidak dapat di handle dalam bentuk 3NF. Normalisasi database bentuk ini tergantung dari kasus yang disediakan, tidak semua tabel wajib di normalisasi dalam bentuk BCNF.

6.3         Contoh Kasus, Bentuk tidak Normal

Bentuk ini merupakan kumpulan data yang akan direkam, tidak ada keharusan mengikukti format tertentu, dapat saja data tidak lengkap atau terduplikasi. Data dikumpulkan apa adanya sesuai dengan saat menginput.

Untuk mentransformasikan tabel yang belum ternomalisasi di atas menjadi tabel yang memenuhi kriteria 1NF adalah kita harus merubah seluruh atribut yang multivalue menjadi atribut single value, dengan cara menghilangkan repeating group pada tabel di atas.

Repeating Group (elemen data berulang) adalah (No_Property, Alamat_Property, Tgl_Pinjam, Tgl_Selesai, Biaya, No_Pemilik, Nama_Pemilik).

6.4         First Normal Form 1NF

Pada tahap ini dilakukan penghilangan beberapa group elemen yang berulang agar menjadi satu harga tunggal yang berinteraksi di antara setiap baris pada suatu tabel, dan setiap atribut harus mempunyai nilai data yang atomic (bersifat atomic value). Atom adalah zat terkecil yang masih memiliki sifat induknya, bila terpecah lagi maka ia tidak memiliki sifat induknya.

Syarat normal ke satu (1-NF) antara lain:

1. setiap data dibentuk dalam flat file, data dibentuk dalam satu record demi satu record nilai dari field berupa “atomic value”.

2. tidak ada set atribute yang berulang atau bernilai ganda.

3. telah ditentukannya primary key untuk tabel / relasi tersebut.

4. tiapatribut hanya memiliki satu pengertian.

Langkah pertama yang dilakukan pada Tabel Pelanggan Biaya (pada Tabel 9.3) tersebut adalah menghilangkan elemen data yang berulang dengan data-data Pelanggan yang sesuai pada setiap baris. Hasil dari tabel yang telah memenuhi bentuk normal pertama dapat dilihat pada Tabel 9.4. kita dapat mengidentifikasi primary key untuk relasi Pelanggan_Biaya yang masih memiliki composite key (No_Pelanggan, No_Property). Pada kasus ini kita akan memperoleh primary key yang bersifat composite key. Relasi Pelanggan_Biaya dapat didefinisikan sebagai berikut. Pelanggan_Biaya =(No_Pelanggan, No_Property, Nama, Alamat_Property, Tgl_Pinjam, Tgl_Selesai, Biaya,No_Pemilik, Nama_Pemilik)

6.5         Second Normal Form 2NF

Bentuk normal kedua didasari atas konsep full functional dependency (ketergantungan fungsional sepenuhnya) yang dapat didefinisikan sebagai berikut. Jika A adalah atribut-atribut dari suatu relasi, B dikatakan full functional dependency (memiliki ketergantungan fungsional terhadap A, tetapi tidak secara tepat memiliki ketergantungan fungsional dari subset (himpunan bagian) dari A.

Syarat normal kedua (2-NF) sebagai berikut.

1.      Bentuk data telah memenuhi kriteria bentuk normal kesatu.

2.      Atribute bukan kunci (non-key) haruslah memiliki ketergantungan fungsional sepenuhnya (fully functional dependency) pada kunci utama / primary key.

6.6         Third Normal Form 3NF

Walaupun relasi 2-NF memiliki redudansi yang lebih sedikit dari pada relasi 1-NF, namun relasi tersebut masih mungkin mengalami kendala bila terjadi anomaly peremajaan (update) terhadap relasi tersebut.

Misalkan kita akan melakukan update terhadap nama dari seorang Pemilik (pemilik), seperti Durki (No_Pemilik: CO93), kita harus melakukan update terhadap dua baris dalam relasi Property_Pemilik (lihat Tabel 9.5, (c) relasi Property_Pemilik). Jika kita hanya mengupdate satu baris saja, sementara baris yang lainnya tidak, maka data didalam database tersebut akan inkonsisten / tidak teratur. Anomaly update ini disebabkan oleh suatu ketergantungan transitif (transitive dependency). Kita harus menghilangkan ketergantungan tersebut dengan melakukan normalisasi ketiga (3-NF).

Syarat normal ketiga (Third Normal Form / 3 NF) sebagai berikut.

1. Bentuk data telah memenuhi kriteria bentuk normal kedua.

2. Atribute bukan kunci (non-key) harus tidak memiliki ketergantungan transitif, dengan kata lain suatu atribut bukan kunci (non_key) tidak boleh memiliki ketergantungan fungsional (functional dependency) terhadap atribut bukan kunci lainnya, seluruh atribut bukan kunci pada suatu relasi hanya memiliki ketergantungan fungsional terhadap priamry key di relasi itu saja. Seluruh atribut non-primary key pada relasi Pelanggan dan Biaya di atas terlihat memiliki ketergantungan fungsional (functional dependency) terhadap primary key dari masing-masing tabel / relasi. Relasi / tabel Pelanggan dan Biaya di atas tidak memiliki ketergantungan transitif (transitive dependency), sehingga tabel tersebut telah memenuhi kriteria normal ketiga (3-NF).

Seluruh atribut non-primary key pada relasi Property_Pemilik di atas terlihat memiliki ketergantungan fungsional (functional dependency) terhadap primary key, kecuali Nama_Pemilik yang masih memiliki ketergantungan fungsional (functional dependency) terhadap No_Pemilik. Inilah contoh ketergantungan dari transitif (transitive dependency), yang terjadi ketika atribut non-primary key (Nama_Pemilik) bergantung secara fungsi terhadap satu atau lebih atribut non-primary key lainnya (No_Pemilik). Kita harus menghilangkan ketergantungan transitif (transitive dependency) tersebut dengan menjadikan relasi Property_Pemilik menjadi 2 relasi / tabel dengan format / bentuk sebagai berikut.

· Relasi / Tabel Property_Untuk_Pemilik yang terdiri dari atribut-atribut:

No_property â Alamat_Property, Biaya, No_Pemilik

{No_property sebagai primary key}

· Dan relasi Pemilik yang terdiri dari atribut-atribut:

No_Pemilik â Nama_Pemilik

{No_Pemilik sebagai primary key}

Hasil akhir normalisasi tabel Pelanggan_Biaya sampai ke bentuk normal ketiga adalah sebagai berikut