MODUL PRAKTIKUM

BASIS DATA 1

Oleh :

TIM TEACHING BASIS DATA 1

PROGRAM STUDI TEKNIK INFORMATIKA

POLITEKNIK NEGERI TANAH LAUT

TAHUN 2018

DAFTAR ISI

DAFTAR ISI.........................................................................................................................i

1 Pengantar Basis Data...................................................................................................1

1.1 Pengenalan...........................................................................................................1

1.2 File Tradisional....................................................................................................1

1.3 Pendekatan Basis Data.........................................................................................2

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

1.5 Kelebihan dan Kekurangan dari Sistem Basis Data.............................................5

1.5.1 Kelebihan Sistem Basis Data............................................................................5

1.5.2 Kekurangan Sistem Basis Data........................................................................5

1.6 Komponen Sistem Basis Data..............................................................................6

1.7 Pengguna Basis Data............................................................................................6

1.8 Database Administrator (DBA)............................................................................7

2 Konsep dan Arsitektur Basis Data...............................................................................9

2.1 Model, Skema dan Instances Data.......................................................................9

2.2 Arsitektur Basis Data.........................................................................................10

2.3 Independensi Data..............................................................................................10

2.4 Database Languages...........................................................................................11

3 Basis Data Relasional................................................................................................12

3.1 Pengantar Basis Data Relasional........................................................................12

3.2 Kunci..................................................................................................................14

3.3 Diagram Skema..................................................................................................14

4 Desain Basis Data dengan Model E-R......................................................................16

4.1 Pengantar Model E-R.........................................................................................16

4.2 Entitas dan Atribut.............................................................................................16

4.3 Weak Entity dan Strong Entity..........................................................................17

i

5 Entity Relationship Diagram (ERD).........................................................................19

5.1 Konsep Dasar ERD............................................................................................19

5.2 Komponen ERD.................................................................................................20

5.3 Pemetaan Kardinalitas........................................................................................21

5.4 Contoh Kasus.....................................................................................................24

6 Normalisasi................................................................................................................27

6.1 Pengantar Normalisasi.......................................................................................27

6.2 Bentuk-Bentuk Normal dan Kelebihannya........................................................27

6.3 Contoh Kasus, Bentuk tidak Normal.................................................................28

6.4 First Normal Form 1NF.....................................................................................28

6.5 Second Normal Form 2NF.................................................................................29

6.6 Third Normal Form 3NF....................................................................................30

Daftar Pustaka....................................................................................................................33

ii

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

1

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.

2

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

3

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

4

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.

5

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

6

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.

7

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.

8

Tugas:

1. Bentuklah sebuah kelompok untuk mengerjakan tugas praktikum.

2. Carilah suatu kasus sistem aplikasi yang menggunakan penyimpanan file dan kasus

sistem aplikasi yang menggunakan penyimpanan basis data.

3. Pada kasus tersebut bahaslah mengenai tipe-tipe data, struktur dan batasan datanya.

4. Pada kasus tersebut tentukan pengguna-pengguna basis datanya.

9

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.

10

Gambar 2.3 Model data

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:

11

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.

12

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

Tugas:

Dengan kelompok dan studi kasus yang sama dengan tugas sebelumnya, buatlah

model dan skema data dari studi kasus tersebut pada setiap level.

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

13

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_LAHIR10200123 SULAEMAN TANGERANG 8 MARET 198330100143 DIANA BOGOR 15 NOVEMBER 198350100333 SADIKIN JAKARTA 24 APRIL 198220100296 THAMRIN TANGERANG 13 MEI 198310200928 LINA JAKARTA 8 DESEMBER 198250100375 IRAWATI BEKASI 7 JULI 1982

MTKULIAH

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

NILAI

NPM KD_MK NIL_MID NIL_UAS10200928 KK021 60 8050100375 KK044 90 8550100333 KK021 50 4030100143 KK018 30 5010200928 KK044 70 40

14

10200123 KK021 65 4520100296 KK021 60 6050100333 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

15

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.

Gambar 3.4 Diagram skema universitas

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.

Tugas:

Dengan kelompok dan studi kasus yang sama dengan tugas sebelumnya, bangunlah

diagram skema dari studi kasus tersebut.

16

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:

Gambar 4.5 Contoh entitas dan relationship

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.

Gambar 4.6 Diagram E-R dengan atribut

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.

17

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:

Gambar 4.7 Entitas nasabah dengan relationship terhadap entitas alamat

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

18

juga turut terhapus. Pada diagram E-R, weak entity digambarkan dengan kotak dengan

garis ganda.

Gambar 4.8 Weak entity dan strong entity

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.

Tugas:

Dengan kelompok dan studi kasus yang sama dengan tugas sebelumnya, bangunlah

himpunan entitas dari kasus yang diberikan, beserta relasi dan kardinalitasnya.

19

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

20

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

21

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)

22

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

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

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

23

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.

24

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)

25

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)

26

4. Menggambar ERD diagram

Tugas:

Dengan kelompok dan studi kasus yang sama dengan tugas sebelumnya, bangunlah

ERD berdasarkan kebutuhan sistem dari kasus yang diambil, kemudian konversikan ke

RAT.

27

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

28

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

29

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.

30

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

31

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:

32

Tugas:

Dengan kelompok dan studi kasus yang sama dengan tugas sebelumnya, bangunlah

database relasional dengan melakukan normalisasi.

33

Daftar Pustaka

1. Silberschatz, A., Korth, H.F. & Sudarshan, S., 2011. Database System Concepts Sixth Edition. New York: McGraw-Hill.

2. Elmasri, R. & Navathe, S.B., 2011. Fundamentals of Database System Sixth Edition. Boston: Addison-Wesley.

34