Access me

Diktat Training TOT : Database Oleh : Nanang Syahroni

Halaman : 1

1. Konsep Perancangan Database

Basis data (database) merupakan kumpulan dari data yang saling berhubungan dengan

yang lainnya, tersimpan di perangkat keras komputer dan digunakan perangkat lunak untuk

memanipulasinya. Database merupakan salah satu komponen yang penting dalam sistem

informasi, karena merupakan basis dalam menyediakan informasi bagi para pemakai.

Penerapan database dalam sistem informasi disebut dengan database system.

Sistem basis data (database system) adalah suatu sistem informasi yang mengintegrasikan

kumpulan dari data yang saling berhubungan satu dengan yang lainnya dan membuatnya

tersedia untuk beberapa aplikasi yang bermacam-macam didalam suatu organisasi.Dengan

sistem basis data ini tiap-tiap orang atau bagian dapat memandang database dari beberapa

sudut pandang yang berbada. Bagian kredit dapat memandangnya sebagai data piutang,

bagian penjualan dapat memandangnya sebagai data penjualan, bagian personalia dapat

memandangnya sebagai data karyawan, bagian gudang dapat memandangnya sebagai data

persediaan.

Semuanya terintegrasi dalam sebuah data yang umum. Berbeda dengan sistem pengolahan

data tradisional, sumber data ditangani sendiri-sendiri untuk tiap aplikasinya.

1.1. Perancangan Database

Dalam membuat suatu database diperlukan suatu langkah atau tahapan suoaya

pengorganisasian file dapat menjadi lebih baik. Langkah utama tersebut adalah menentukan

tipe-tipe file.

1. Basis data dibentuk dari suatu kumpulan file. File dalam pemrosesan transaksi dapat

digolongkan sebagai berikut :

§ File induk (Master file)

§ File transaksi (transaction file)

§ File laporan (report file)

§ File sejarah (history file)

§ File pelindung (backup file)

§ File kerja (working file)


Halaman : 2

2. Membuat akses dan organisasi file

Akses file adalah suatu metode yang menunjukkan bagaimana suatu program komputer

akan membaca record-record dari suatu file. File dapat diakses dengan dua cara yaitu

secara urut (sequential access) atau secara langsung (direct access atau random access).

Metode urut dilakukan dengan membaca atau menulis suatu record di file dengan membaca

terlebih dahulu mulai dari record pertama, urut sampai dengan record yang diinginkan.

Metode akses langsung dilakukan dengan cara langsung membaca record pada posisinya di

file tanpa membaca dari record pertama terlebih dahulu.

Organisasi file adalah pengaturan dari suatu record secara logika dalam file dihubungkan

satu dengan lainnya. File dapat diorganisasikan secara urut atau secara acak. Walaupun

organisasi file dan pengaksesan file dapat dipandang secara terpisah, tetapi biasanya

pembahasan mengenai organisasi file menyangkut keduanya, yaitu sebagai berikut :

§ File urut merupakan file dengan organisasi urut dengan pengaksesan secara urut pula.

§ File urut berindeks atau sering disebut ISAM (Indexed Sequential Access Method)

merupakan file dengan organisasi secara urut dengan pengaksesan secara langsung.

§ File akses langsung atau disebut juga dengan file alamat langsung merupakan file

dengan organisasi acak dengan pengaksesan secara langsung.

1.2. Manajemen Database

Sistem ini merupakan perangkat lunak yang mengatur proses pengelolaan database.

Pengelolaan ini meliputi pembuatan database, akses terhadap database serta penyimpanan

data dalam database.

Sedangkan pengertian dari database adalah sekumpulan file-file yang paling berhubungan

satu sama lain atau beberapa kunci penghubung, tersimpan dalam media penyimpanan

diluar memori komputer. Media simpan ini dapat berupa disket, Hardisk.

Database dapat dinyatakan sebagai suatu sistem yang memiliki karakteristik, antara lain :

§ Merupakan suatu kumpulan "interrelated data" yang disimpan bersama tanpa

menggangu satu sama lain atau membentuk kerangkapan data.

§ Kumpulan data dalam database dapat digunakan oleh sebuah program aplikasi lebih

secara optimal.


Halaman : 3

§ Penambahan data baru, modifikasi dan pengambilan kembali dari data dapat dilakukan

dengan mudah dan terkontrol.

§ Data merupakan suatu sumber yang sangat berguna bagi hampir di semua organisasi.

Dengan tersedianya data yang melimpah, maka masalah pengaturan data secara efektif

menjadi suatu hal yang sangat penting dalam pengembangan sistem informasi manajemen.

Oleh karena itu, maka tujuan dari diadakannya pengaturan data adalah sebagai berikut :

Menyediakan penyimpanan data untuk dapat digunakan oleh organisasi saat sekarang dan

masa yang akan datang.

§ Cara pemasukan data sehingga memudahkan tugas operator dan menyangkut pula

waktu yang diperlukan oleh pemakai untuk mendapatkan data serta hak-hak yang dimiliki

terhadap data yang ditangani.

§ Pengendalian data untuk setiap siklus agar data selalu "up to date" dan dapat

mencerminkan perubahan spesifik yang terjadi di setiap sistem.

§ Pengamanan data terhadap kemungkinan penambahan, modifikasi, pencurian dan

gangguan-gangguan lain.

1.3. Teknik Perancangan Database

Dalam perancangan database ini digunakan untuk merancang database berskala luar,

adaput teknik yang dikenal dua macam cara :

§ Teknik Normalisasi

Cara ini dimulai dari dokumen dasar yang sudah ada pada sistem atau sudah dipakai

sistem tersebut, data-data pada dokumen dasar tersebut dipisah-pisah menjadi file-file

yang tiap field pada file tersebut bergantung penuh pada kunci utama (field kunci) yang

biasanya dikenal dengan bentuk normal ketiga. Kemudian setiap file dalam database

tersebut ditentukan hubungannya dengan file-file yang lain dengan cara memasang field

tamu pada file-file anak atau file konektor.

§ Teknik Entity Relationship

Langkah ini sering digunakan pada perancangan sistem, dimulai dengan pembuatan

diagram arus data yang menghasilkan kamus data yang merupakan daftar semua


Halaman : 4

elemen/field yang dibutuhkan dalam sistem terebut. Dari field-field tersebut dipilih field

kunci yang bersifat unik artinya keseluruhan record dapat dicari dari record tersebut,

kemudian baru dibuat file-file berdasar kunci record tersebut yang mana elemen/field

dalam field tersebut bergantung penuh dengan filed kunci tersebut. Setelah membuat

tabel baru ditentukan relasi dari tiap tabel tersebut seperti halnya teknik normalisasi.

1.4. Data Flow Diagram (DFD)

Untuk memudahkan penggambaran suatu sistem yang ada atau sistem yang baru yang akan

dikembangkan secara logika tanpa memperhatikan lingkungan fisik dimana data tersebut

mengalir atau lingkungan fisik dimana data tersebut akan disimpan, maka kita menggunakan

diagram arus data atau Data Flow Diagram (DFD).

Diagram alur data merupakan alat yang cukup populer sekarang, karena dapat

menggambarkan arus data di dalam suatu sistem dengan terstruktur dan jelas. Dalam

menggambarkan sistem perlu dilakukan pembentukan simbol, berikut ini simbol-simbol yang

sering digunakan dalam diagram alur data (DAD) :

1. External entity (kesatuan luar) atau boundary (batasan)

Setiap sistem pasti memiliki batas sistem yang memisahkan suatu sistem dengan

lingkungan luarnya. Sistem akan menerima input dan menghasilkan output bagi

lingkuangan luarnya. Kesatuan luar merupakan kesatuan di lingkungan luar sistem yang

dapat berupa orang, organisasi atau sistem lain yang berada di lingkungan luarnya yang

akan memberikan input serta menerima output dari sistem. Suatu kesatuan luar dapat

disimbolkan dengan notasi kotak dapat dilihat pada gambar berikut :

2. Data flow (aliran data)

Arus data pada diagram arus data diberi simbol panah. Arus data ini mengalir di antara

proses, penyimpanan data dan kesatuan luar. Arus data ini menunjukkan arus atau aliran

data yang dapat berupa masukan untuk sistem atau hasil dari proses sistem dan dapat

berbentuk sebagai berikut ini :

§ Formulir atau dokumen yang digunakan.

§ Laporan tercetak yang dihasilkan oleh sistem.


Halaman : 5

§ Tampilan atau output di layar komputer yang dihasilkan oleh sistem.

§ Masukan oleh komputer.

§ Komunikasi ucapan.

§ Surat-surat atau memo.

§ Data yang dibaca atau direkam pada suatu file.

§ Surat isian yang dicatat pada buku agenda.

§ Transmisi data dari satu komputer ke komputer yang lain.

3. Proses

Suatu proses adalah kegiatan atau kerja yang dilakukan orang, mesin atau komputer

dari hasil suatu arus data yang masuk ke dalam proses untuk dihasilkan arus data

yang akan keluar dari proses. Untuk physical data flow diagram (PDFD), proses dapat

dilakukan oleh orang, mesin atau komputer. Sedangkan untuk logical data flow

diagram (LDFD), suatu proses hanya menunjukkan proses dari komputer. Suatu

proses dapat ditunjukkan dengan simbol lingkaran atau dengan simbol empat persegi

panjang dengan sudut-sudutnya yang tumpul. Berikut ini simbol untuk proses :

Setiap proses harus diberi penjelasan yang lengkap meliputi :

Identifikasi proses

Identifikasi ini umumnya berupa angka yang menunjukkan nomor acuan dari proses dan

ditulis pada bagian atas simbol proses

Nama Proses

Nama proses menunjukkan apa yang dikerjakan oleh proses tersebut. Nama proses

harus jelas dan lengkap mengggambarkan kegiatan proses. Nama proses biasanya

berbentuk suatu kalimat yang diawali dengan kata kerja dan letaknya berada di bawah

identifikasi proses.

Pemroses

Untuk PDFD yang menunjukkan proses tidak hanya proses dari komputer, tetapi juga

proses manual, seperti proses yang dilakukan oleh orang, mesin, atau komputer, maka

pemroses harus ditunjukkan. Pemroses ini menunjukkan siapa dan dimana suatu proses


Halaman : 6

dilakukan. Untuk LDFD yang prosesnya hanya menunjukkan proses komputersaja, maka

pemroses tidak perlu disebutkan. Untuk LDFD, bila pemroses akan disebutkan dapat juga

untuk menyebutkan nama dari program yang melakukan prosesnya. Keterangan

pemroses ini dapat diletakkan di bawah nama proses.

Gambar 1. Diagram Simbol DFD

1.5. Menggunakan High-Level Conceptual Data Model (CDM)

Dalam menggunakan high-level conceptual data model terdiri dari beberapa langkah, yaitu:

◊ Pengumpulan dan analisis kebutuhan, meliputi kegiatan:

- Interview user dan mengerti kebutuhan dokumentasi data mereka

- Menspesifikasi kebutuhan fungsional dari aplikasi

◊ Membuat skema konseptual database menggunakan high-level conceptual data model,

meliputi:

- Mendeskripsikan secara singkat kebutuhan data dari user dan termasuk deskripsi

detil dari tipe entitas, relationship dan constraint.

- Menspesifikasi operasi high-level user yang didentifikasi selama analisis fungsional.

High level data model mudah dimengerti dan digunakan untuk berkomunikasi dengan user

yang tidak mengerti secara teknis. Juga dapat digunakan sebagai referensi untuk

meyakinkan bahwa semua kebutuhan user dapat dipenuhi tanpa terjadi konflik.

◊ Mengimplementasikan database menggunakan DBMS disebut pemetaan model data

- Skema konseptual ditransformasikan dari high-level data model ke implementasi

model data.

◊ Fase desain fisik,

- Menspesifikasi struktur penyimpanan internal, path akses dan organisasi file untuk

database yang dispesifikasi.


Halaman : 7

- Mendesain program aplikasi dan mengimplementasikan sebagai transaksi databse

berhubungan dengan spesifikasi transaksi high-level.

Gambar 2. Penyederhanaan dari proses desain database.

High level data model mudah dimengerti dan digunakan untuk berkomunikasi dengan user

yang tidak mengerti secara teknis. Juga dapat digunakan sebagai referensi untuk

meyakinkan bahwa semua kebutuhan user dapat dipenuhi tanpa terjadi konflik.

◊ Mengimplementasikan database menggunakan DBMS disebut pemetaan model data

- Skema konseptual ditransformasikan dari high-level data model ke implementasi

model data.

◊ Fase desain fisik,


Halaman : 8

- Menspesifikasi struktur penyimpanan internal, path akses dan organisasi file untuk

database yang dispesifikasi.

- Mendesain program aplikasi dan mengimplementasikan sebagai transaksi databse

berhubungan dengan spesifikasi transaksi high-level.

1.6. Contoh Perancangan Aplikasi Database

Uraian berikut ini adalah sebuah contoh aplikasi database COMPANY yang digunakan untuk

ilustrasi konsep model ER dan penggunaannya dalam desain skema. Kita mendaftar

kebutuhan data untuk database dan kemudian membuat skema konseptual step by step

seperti dalam konsep pemodelan model ER. Database COMPANY terdiri dari employees,

departments dan projects. Setelah fase pengumpulan dan analisis kebutuhan, desainer

database menyatakan deskripsi dari “miniworld”- bagian dari perusahaan yang

direpresentasikan dalam database.

1. Company diorganisasikan dalam departemen-departemen. Masing-masing departemen

mempunyai name yang unik, number yang unik dan employee tertentu tang me-manage

departemen. Sebuah departemen mempunyai beberapa lokasi.

2. Sebuah department mengontrol sejumlah projects, masing-masing mempunyai name

yang unik, number yang unik dan lokasi tunggal.

3. Kita menyimpan masing-masing name employee, social security number, address,

salary, sex dan birth date. Seorang employee bekerja pada satu departemen tetapi boleh

bekerja pada beberapa project, dimana tidak perlu dikontrol oleh departemen yang sama.

Kita juga mempunyai jumlah jam per minggu dimana seorang employee bekerja pada

masing-masing project. Kita juga mencatat supervisor langsung dari masing-masing

employee.

4. Kita ingin mencatat dependents dari masing-masing employee untuk keperluan asuransi.

Kita mempunyai untuk masing-masing dependent first name, sex, birth date dan

relationship ke employee.

Pada gambar 3.2 menunjukkan bagaimana skema untuk aplikasi database ditampilkan

dalam notasi grafik yang dikenal dengan ER diagram. Penjelasan tentang notasi ER diagram

adalah Sebagai berikut.


Halaman : 9

Gambar 3. Skema diagram ER untuk database perusahaan

1.7. Entity Types, Entity Sets, Attributs dan Keys

Model ER mendeskripsikan data sebagai entitas, relationship dan attribut.

1. Entities dan Attributes

Entitas dan atributnya. Object dasar yang di representasikan oleh model ER adalah entity

yang merupakan “sesuatu’ dalam dunia nyata dengan keberadaan yang bebas. Sebuah

entity dapat berupa object dengan eksistensi fisik – seperti manusia, mobil, rumah atau

employee- atau dapat juga sebuah object secara konseptual- seperti company, sebuah job,

atau sebuah mata kuliah. Masing0masing entity mempunyai attribut yang merupakan sifat-

sifat tertentu yang menggambarkan entity tersebut. Contoh entity employee dapat

digambarkan dengan employee name, age, address, salary dan job. Sebuah bagian entity

akan mempunyai sebuah nilai untuk masing-masing attribut ini. Nilai-nilai attribut yang


Halaman : 10

menggambarkan masing-masing entity akan menjadi bagian besar dari penyimpanan data

dalam database.

Pada gambar 3.3 menunjukkan dua entity dan nilai dari attribut mereka. Entity employee e1

mempunyai empat attribut: Name, Address, Age dan HomePhone; nilai-nilai mereka adalah

“John Smith,””2311 Kirby, Houston, Texas 77001,””55,” dan “713-749-2630,”.Entity

company c1 mempunyai tiga attribut: Name, Headquarters dan president; nilai mereka

masing-masing adalah “Sunco Oil,” “Houston.” Dan “John Smith,”.

Gambar 4. Dua entitas employee e1 dam company c1 beserta atributnya

Beberapa tipe dari attribut terjadi dalam model ER: simple versus Composite; Single-valued

versus multivalued; dan stored versus derived. Juga diperkenalkan konsep null value untuk

sebuah attribut.

Composite Versus Simple (Atomic) Attribut. Attribut Composite dapat diturunkan ke

dalam sub bagian yang lebih kecil, yang merepresentasikan attribut yang lebih dasar dengan

arti yang bebas. Contoh, attribut addres dari entity employee pada gambar 3.3 dapat dibagi

ke dalam StreetAddress, City, State dan Zip, dengan nilai “2311 Kirby,” “Houston,” “Texas,”

dan “77001,”. Attribut yang tidak dapat dibagi disebut attribut simple atau atomic. Attribute

composit dapat membentuk sebuah hierarki; contoh: StreetAddress dapat dibagi ke dalam

tiga attribut simple Number, Street dan ApartmentNumber.

Atribut Single-valued Versus Multivalue. Sebagian besar atribut mempunyai single value

untuk sebuah entity tertentu, sehingga disebut single-value. Contoh, Age adalah atribut

single value dari person. Dalam beberapa kasus sebuah atribut dapat mempunyai satu set

nilai untuk entity yang sama. Contoh, atribut warna untuk sebuah mobil atau atribut


Halaman : 11

CollegeDegree untuk person. Mobil dengan satu warna mempunyai single value dan mobil

dengan dua warna memiliki dua value. Serupa dengan itu satu person tidak harus

mempunyai sebuah college degree, person yang lain dapat mempunyai satu college degree

dan orang yang lain dapat memiliki dua atau lebih degree. Sedemikian sehingga person

yang berbeda dapat mempunyai sejumlah nilai yang berbeda untuk atribut college degree.

Dengan demikian atribut tersebut disebut multivalue. Sebuah atribut multivalue dapat batas

mempunyai batas atas dan batas bawah pada sejumlah nilai yang diijinkan untuk masing-

masing entity. Contoh, atribut color dari sebuah mobil dapat berada diantara nilai satu dan

tiga, bila diasumsikan bahwa sebuah mobil dapat mempunyai paling banyak tiga warna.

Atribut Stored versus Derived. Dalam beberapa kasus, value dari dua atau lebih atribut

adalah berhubungan - contoh, atribut age dan BirthDate dari person. Untuk entity person

tertentu, value dari age dapat ditentukan dari date hari ini dan value dari BirthDate person

tersebut. Atribut age oleh karenanya disebut dengan derived atribut dan dikatakan

derivable dari atribut BirthDate, yang disebut Store Atribut. Beberapa value atribut dapat

diturunkan dari entitas yang berhubungan; contoh; atribut NumberEmployee dari entity

departmen dapat diturunkan dengan menhitung jumlah dari employee yang mempunyai

hubungan (working for) dengan departemen itu.

Value Null. Dalam beberapa kasus sebuah entity boleh tidak mempunyai nilai tertentu untuk

sebuah atribut. Contoh, atribut ApartmentNumber dari sebuah alamat diaplikasikan hanya

untuk alamat yang ada di dalam gedung apartemen dan tidak ke tipe tempat tinggal lain

seperti rumah single family. Serupa dengan itu, atribut CollegeDegree diaplikasikan hanya

untuk person yang mempunyai college degree. Untuk situasi yang demikian, sebuah value

khusus yang disebut null dibuat. Sebuah alamat dari single family home akan mempunyai

value null untuk atribut ApartmentNumber dan seorang person yang tidak memiliki college

degree akan mempunyai value null untuk atribut CollegeDegrees. Null dapat juga digunakan

jika kita tidak mengetahui value dari atribut entity tertentu. Contoh, bila kita tidak mengetahui

home phone dari “John Smith” maka arti dari tipe berbentuk null adalah not applicable, atau

tidak diketahui.

Atribut Complex. Perlu dicatat bahwa atribut composite dan multivalue dapat di-nested ke

dalam arbitrary. Kita dapat merepresentasikan arbrtrary nesting dengan mengelompokkan

komponen dari atribut composite diantara kurung () dan memisahkan komponen tersebut

dengan koma, serta menampilkan multivalue atribut di antara kurung kurawal {}. Atribut

demilikian disebut atribut complex. Contoh, bila seorang person dapat mepunyai lebih dari


Halaman : 12

satu residence dan masing-masing residence dapat mempunyai banyak phone, sebuah

atribut AddresPhone untuk entity person dapat dispesifikasi sebagai berikut.

{AddressPhone({Phone(AreaCode,PhoneNumber)},

Address(StreetAddress(Number,Street,ApartmentNumber),City,State,Zip))}

Gambar 5. Contoh Atribut Kompleks

2. Entity Types, Entity Sets, Keys, and Value Sets

Tipe entity dan himpunan entity. Sebuah database biasanya mengandung sekelompok entity

yang serupa. Contoh, Sebuah perusahaan yang mempekerjakan ratusan employee

mungkiningin menyimpan informasi yang serupa untuk masing-masing employee. Entity

employee ini berbagi atribut yang sama tetapi masing-masing enetity mempunyai value

sendiri-sendiri untuk masing-masing atribut. Sebuah tipe entity (Entity Type)

mendefinisikan kumpulan entity yang mempunyai atribut yang sama. Masing-masing entity

type dalam database dalam database digambarkan dengan nama dan atribut. Gambar 3.6

menunjukkan dua tipe entity yaitu Employee dan company, dan daftar atribut dari masing-

masing entity tersebut. Kumpulan dari semua entity dari sebuah tipe entity tertentu dalam

database pada suatu waktu tertentu disebut kumpulan entity (entity set). Entity set

biasanya diacu dengan menggunakan anma yang sama seperti tipe entity. Contoh;

employee mengacu kepada kedua tipe entity yang berarti kumpulan semua entity employee

pada saat ini dalam database.

Sebuah tipe entity direpresentasikan dalam ER diagram dengan kotak persegi panjang

tertutup dengan nama tipe entity. Nama Atribut berada dalam bentuk oval dan dihubungkan

dengan nama entitynya dengan garis lurus. Atribut composite dihubungkan dengan atribut

komponen mereka dengan garis lurus. Atribut multivalue ditampilkan dengan dobel oval.

Sebuah tipe entity menggambarkan skema atau intension untuk sebuah kumpulan dari entity

yang berbagi struktur yang sama. Kumpulan entity dari tipe entity tertentu dikelompokkan

dalam himpunan entity (entity set) yang juga disebut extension dari tipe entity.


Halaman : 13

Atribut key dari sebuah tipe entity constraint yang penting dari sebuah entity dari sebuah

entity adalah key atau constrain yang unik pada sebuah atribut. Sebuah entity biasanya

mempunyai atribut dimana nilainya adalah berbeda untuk masing-masing individu entity

dalam sebuah kumpulan. Atribut demikian disebut dengan atribut key dan nilainya dapat

digunakan untuk mengidentifikasikan masing-masing entity secara unik. Contoh : attribut

NAME adalah key dari tipe entity COMPANY dalam gambar 3.6, karena tidak ada dua

perusahaan yang diijinkan untuk mempunyai nama yang sama. Untuk tipe entity PERSON

atribut key yang dipakai adalah Social Security Number. Kadang-kadang beberapa atribut

bersama-sama membentuk sebuah key, yang berarti bahwa kombinasi dari value atribut

harus berbeda untuk masing-masing entity. Bila sekumpulan atribut memiliki properti seperti

ini, kita dapat mendifinisikan sebuah atibut komposit yang menjadi atribut key dari tipe

entity.perlu dicatat bahwa sebuah key composite haruslah minimal yaitu semua atribut

komponen harus dimasukkan dalam atribut composite agar mempunyai properti yang unik.

Dalam notasi diagram ER, masing-masing atribut key mempunyai nama yang bergaris

bawah didalam bentuk oval.

Menspesifikasi bahwa sebuah atribut adalah key dari sebuah tipe entity berarti bahwa

properti sebelumnya harus bertahan untuk setiap extension dari tipe entity. Oleh karena itu

ini adalah konstrain dimana biasanya ada dua entity yang mempunyai value yang sama

untuk atribut key pada saat yang sama. Ini bukanlah properti dari extension tertentu tetapi ini

adalah constraint pada semua extension dari tipe entity. Constraint key ini diturunkan dari

constraint miniword dimana database direpresentasikan.

Beberapa tipe entity mempunyai lebih dari satu atribut key. Contoh : atribut vehicleID dan

registrasi dari tipe entity CAR (gambar 3.7) adalah key. Atribut registrotion adalah sebuah

contoh key composite yang dibentuk dari dua atribut komponen sederhana. Registrotion

number dan State. Sebuah entity dapat juga tidak memiliki key, yang disebut tipe weak

entity.

Value set (domain, kumpulan nilai) dari atribut masing-masing atribut simple dari sebuah tipe

entity dihubungkan dengan himpunan nilai (atau domain nilai), yang menspesifikasi

kumpulan dari nilai yang dapat diberikan ke atribut tersebut untuk masing-masing individu

entity. Dalam gambar 3.6, bila range dari age diijinkan untuk Employee antara 16 dan 70,

kita dapat menspesifikasi kumpulan nilai atribut Age dan EMPLOYEE menjadi kumpulan

integer antara 16 dan 70. serupa dengan itu kita dapat menspesifikasi sekelompok nilai


Halaman : 14

untuk atribut Name sebagai kumpulan string dari karakter huruf yang dipisahkan oleh

karakter blank dan seterusnya. Kumpulan value tidak ditampilkan dalam ER diagram. Secara

matematis atribut A dari tipe entity E yang mempunyai kumpulan nilai V didefinisikan sebagai

fungsi dari E terhadap power set P(V) dari V:

A : E à P(V)

Kita mengacu terhadap value dari atribut A untuk entity e sebagai A(e). Definisi sebelumnya

mencakup kedua atribut single value dan multivalue seperti null. Null value direpresentasikan

oleh himpunan kosong. Untuk atribut single value , A(e) dibatasi menjadi single untuk

masing-masing entity dalam E sementara itu tidaka ada batasan pada multivalue. Untuk

atribut composite A, himpunan nilai V adalah Cartesian product dari P(V1),P(V2), …, P(Vn),

dimana V1, V2, …, Vn adalah himpunan nilai dari atribut componen simple yang membentuk

A:

V = P(V1) x P(V2) x … x P(Vn)

3. Desain Konseptual awal dari database COMPANY

Kita sekarang dapat mendefinisikan tipe entity untuk database COMPANY, yang didasarkan

pada kebutuhan yang digambarkan pada bagian 3.2. Setelah mendefinisikan tipe entity dan

atributnya, kita memperbaiki desain kita dalam bagian 3.4 (setelah memperkenalkan konsep

relationship). Sesuai dengan daftar requirement pada bagian 3.2, kita dapat mengidentifikasi

empat tipe entity yang saling berhubungan seperti gambar 3.8:

1. Tipe entity DEPARTMENT dengan atribut Name, Number, Locations, Manager dan

ManagerStartDate. Locations adalah satu-satunya atribut multivalue. Kita dapat men-

spesifiksibahwa Name dan Number adalah atribut Key (terpisah), karena masing-

masing dispesifikasi secara unik.

2. Tipe entity PROJECT dengan atribut Name, Number, Locations dan

ControlingDepartment. Nama dan Number adalah atribut key yang saling terpisah.

3. Tipe entity EMPLOYEE dengan atribut Name, SSN, Sex, Address, Salary, BirthDate,

Department dan Supervisor. Name dan Address mungkin atribut composit tetapi hal


Halaman : 15

ini tidak dispesifikasi dalam requirements. Kita harus kembali ke user untuk

mengetahui bila mereka akan mengacu ke individual komponen dari nama seperti

FirstName, MiddleInitial, LastName atau dari alamat.

4. Tipe entity DEPENDENT dengan atribut Employee, DependentName, Sex, BirthDate

dan relationship ke employee.

Gambar 6. Desain awal dari tipe entity untuk database perusahaan

Sejauh ini kita belum merepresentasikan kenyataan bahwa seorang employee dapat bekerja

pada beberapa project juga kita belum merepresentasikan jumlah jam per minggu seorang

employee bekerja pada masing-masing project. Karakteristik ini di list sebagai bagian dari

requirement ke tiga dalam bagian 1.5, dan dia dapat direpresentasikan dengan atribbut

composit multivalue dari EMPLOYEE yang disebut WorksOn dengan komponen simple

(Project, Hours).

Alternatifnya, dia dapat direpresentasikan sebagai atribut composit multivalue dari PROJECT

yang disebut Workers dengan komponen simple (Employee, Hours). Kita memilih alternatif

pertama dalam gambar 6 yang menunjukkan masing-masing dari tipe entity. Atribut Name

dari EMPLOYEE ditunjukkan sebagai atribut composit yang disimpulkan setelah

berkonsultasi dengan user.


Halaman : 16

1.8. Relationship, Tipe Relationship, Role dan Structural Constraints

Dalam gambar 6 terdapat beberapa implicit relationship diantara berbagai tipe entity.

Kenyataannya kapanpun sebuah atribut dari satu tipe entity mengacu ke tipe entity yang lain,

bebepara relationship muncul. Contoh, atribut Manager dari DEPARTMENT mengacu ke

seorang employee yang me-manage deparment; atribut ContrllingDepartment dari

PROJECT mengacu ke Department yang mengontrol project; atribut Supervisor dari

EMPLOYEE mengacu ke employee lain (seseorang yang men-supervisi employee ini);

atribut Department dari EMPLOYEE mengacu ke Department dimana employee bekerja;dsb.

Dalam model ER referensi ini seharusnya tidak direpresentasikan sebagai atribut tetapi

sebagai relationship. Skema database COMPANY akan diperbaiki dalam bagian 3.6 untuk

merepresentasikan relationship secara explisit. Dalam desain awal dari tipe entity,

relationship biasanya di capture dalam bentuk atribut. Ketika desain diperbaiki atribut ini

dokonversi ke dalam relationships diantara tipe entity.

1. Tipe Realationship, Sets dan Instances

Sebuah tipe relationship R diantara n tipe entity E1, E2, … , En mendefinisikan sebuah

himpunan asosiasi- atau himpunan relationship – diantara entity dari tipe-tipe ini. Seperti tipe

entity dan himpunan entity, sebuah tipe relationship dan hubungannya dengan himpunan

relationship biasanya diacu dengan nama yang sama R. Secara matematis himpunan R

adalah sebuah himpunan dari relationship instance (suatu relationship) ri, dimana masing-

masing ri mengasosiasikan n entity individu (e1, e2, …, en), dan masing-masing entity ej

dalam ri adalah sebuah anggota dari tipe entity Ej, 1 ≤ j ≤ n. Oleh karenanya sebuah tipe

relationship adalah sebuah relasi matematis pada E1, E2, … , En, atau alternatifnya dia dapat

didefinisikan sebagai sebuah himpunan bagian dari cartesian product E1 x E2 x … x En.

Masing-masing dari tipe entity E1, E2, … , En dikatakan berpartisipasi (participate) di dalam

tipe relationship R, dan serupa dengan hal itu, masing-masing individu entity e1, e2, …, en

dikatakan berpartisipasi dalam suatu relationship ri = (e1, e2, …, en).

Secara informal masing-masing relationship instance ri dalam R adalah sebuah asosiasi

dari entity, dimana asosiasi memasukkan dengan tepat satu entity dari masing-masing tipe

entity yang berpartisipasi. Dengan demikian masing-masing relationship instance ri

merepresentasikan kenyataan bahwa entity yang berpartisipasi dalam ri dihubungkan

dengan beberapa jalan dalam menghubungan situasi miniworld. Contoh, perhatikan sebuah


Halaman : 17

tipe relationship WORK_FOR antara dua entity EMPLOYEE dan DEPARTMENT, yang

mengasosiasikan masing-masing employee dengan department dari employee bekerja.

Masing-masing relationship instance dalam himpunan relationship WORK_FOR

menghubungkan satu entity employee dan satu entity department. Gambar 3.9

mengilustrasikan contoh ini, dimana masing-masing instansi relationship ri ditunjukkan

menghubungkan entity employee department yang berpartisipasi dalam ri. Miniworld dalam

gambar 3.9 employee e1, e3 dan e6 bekerja untuk department d1; e2 dan e4 work for d2; serta

e5 dan e7 work for d3.

Dalam diagram ER tipe relationship di tampilkan dengan bentuk diamond, yang

dihubungkan dengan garis lurus ke kotak persegipanjang yang merepresentasikan tipe entity

yang berpartisipasi. Nama relationship ditampilkan dalam kolat diamond.

Gambar 7. Beberapa instance darri relasi WORKS_ON antara Empolyee dan

Deparrtement

2. Relationship Degree, Role Name dan Recursive Relationships

Degree dari tipe relationship adalah jumlah dari tipe entity yang berpartisipasi. Oleh

karenanya, relationship WORK_FOR adalah berderajat dua. Tipe relationship ber derajat

dua disebut binary dan berderajat tiga disebut ternary. Contoh dari ternary relationship

adalah SUPPLY seperti ditunujukkan gambar 8, dimana masing-masing instansi dari

relationship ri menghubungkan tiga entity – seoarng suplier s, part p, dan project j – dimana s


Halaman : 18

mensuplai part p untuk project j. Relationship secara umum dapat terdiri dari beberapa

derajat, tetapi yang paling umum adalah relationship binary. Relationship yang lebih tinggi

umumnya lebih kompleks daripada relationship binary.

Gambar 8. Beberapa relasi instance dari SUPPLY secara ternary relationship

Relationship sebagai atribut. Kadang lebih enak untuk berfikir bahwa tipe relationship

dinyatakan dalam atribut. Perhatikan tipe relationship WORKS_FOR pada gambar 3.9. Dia

dapat kita pikirkan sebagai sebuah atribut Department dari tipe entity EMPLOYEE dimana

nilainya untuk masing-masing entity employee adalah entity department dimana employee

bekerja. Oleh karenanya himpunan value untuk atribut department ini adalah himpunan dari

semua entity DEPARTMENT. Ini adalah apa yang kita kertjakan di dalam gambar 3.8 ketika

kita menspesifikasi desain awal dari tipe entity EMPLOYEE untuk database COMPANY.

Bagaimanapun ketika kita berfikir relationship binary sebagai atribut, kita selalu mempunyai

dua pilihan. Dalam contoh ini alternatifnya adalah memikirkan atribut multivalue Employee

dari tipe entity DEPARTMENT dimana nilainya untuk masing-masing entity department

adalah himpunan dari entity employee yang bekerja untuk depertemen tersebut. Himpunan

nilai dari atribut Employee adalah himpunan entity EMPLOYEE. Dua atribut ini Department

dari EMPLOYEE atau Employee dari DEPARTMENT dapat merepresentasikan tipe

relationship WORKS_FOR. Bila keduanya direpresentasikan, mereka adalah constraint yang

berlawanan satu sama lain.


Halaman : 19

Role Name dan Recursive Relationship. Masing-masing tipe entity yang berpartisipasi

dalam tipe relationship memainkan tugas (Role) tertentu dalam relationship. Nama role

menandai role dimana sebuah entity yang berpartisipasi dari tipe entity bermain dalam

masing-masing insatnsi relationship, dan membantu untuk menjelaskan arti dari relationship.

Contoh, dalam tipe relationship WORK_FOR , EMPLOYEE memainkan tugas dari employee

atau worker dan DEPARTMENT memainkan tugas dari department atau employer.

Role name secara teknis tidak perlu dalam tipe relationship dimana semua tipe entity yang

berpartisipasi adalah berbeda, oleh karena masing-masing nama tipe entity dapat digunakan

sebagai role name. Tetapi, dalam banyak kasus tipe entity berpartisipasi lebih dari sekali

dalam tipe relationship dalam role yang berbeda. Dalam banyak kasus juga, role name

menjadi penting untuk membedakan arti dari partisipasi masing-masing. Tipe relationship

demikian disebut recursive relationship, dan gambar 9 menunjukkan contoh untuk ini. Tipe

relasi SUPERVISION menghubungkan seorang employee ke seorang supervisor, dimana

keduanya entity employee dan supervisor adalah anggota dari dari tipe entity EMPLOYEE

yang sama. Oleh karenanya tipe entity EMPLOYEE berpartisipasi dua kali dalam

SUPERVISION. Sekali dalam role sebagai supervisor (atau boss), dan sekali dalam role

sebagai supervisee (atau subordinat). Masing-masing instansi relationship ri dalam

SUPERVISION menghubungkan dua entity employee ej dan ek, dimana yang satu

memainkan role supervisor dan yang lain memainkan role supervisee. Gambar 9, garis

ditandai dengan “1“ merepresentasikan role supervisor, dan tanda “2” merepresentasikan

role supervisee; oleh karenanya e1 mensupervisi e2 dan e3; e4 mensupervisi e6 dan e7; serta

e5 mensupervisi e1 dan e4.


Halaman : 20

Gambar 9. Relasi secara rekursif dari SUPERVISION, dimana entity EMPLOYEE

memainkan role sebagai Supervisor (1) dan yanng disupervisi (2)

3. Constraints pada tipe Relationship

Tipe Relationship biasanya mempunyai constrain-constraint yang membatasi kombinasi

yang mungkin dari entity yang boleh berpartisipasi dalam menghubungkan himpunan relasi.

Constraint-constrint ini ditentukan dari siatuasi miniworld yang merepresentasikan

relationship. Seperti gambar 3.9, bila company mempunyai rule dimana masing-masing

employee harus bekerja untuk tepat satu department, maka kita akan mendeskripsikan

constraint ini dalam skema. Kita dapat membedakan dua tipe utama dari constrain

relationship: perbandingan cardinalitas dan partisipasi.

Cardinality Ratio untu Relationship Binary. Cardinality Ratio untuk relationship binary

menspesifikasi jumlah dari instansi relationship dimana sebuah entity dapat berpartisipasi di

dalamnya. Contoh, dalam tipe relationship binary WORKs_FOR,

DEPARTMENT:EMPLOYEE adalah perbandingan kardinalitas 1:N, yang berarti bahwa

masing-masing department dapat dihubungkan ke (yaitu, employs) sejumlah employee,

tetapi seoarang employee dapat direlasikan hanya ke (work for) satu department saja.

Perbandingan kardinalitas yang mungkin untuk relationship binary adalah 1:1, 1:N, N:1 dan

M:N.


Halaman : 21

Contoh relationship binary 1:1 adalah MANAGE (gambar 10), yang menghubungkan entity

department ke employee yang me-manage departement tersebut. Ini merepresentasikan

constraint miniworld dimana seorang employee dapat me-manage hanya satu department

dan bahwa department hanya mempunyai satu manager.

Gambar 10. Relasi 1:1 dari MANAGES, dengan partisipasi secara parsial dari EMPLOYEE

dan semua partisipan dari DEPARTEMENT

Constraint Partisipasi dan keberadaan Dependency. Constraint partisipasi men-

spesifikasi apakah keberadaan dari suatu entity bergantung pada relasinya dengan entity

lain melalui tipe relationship. Ada dua tipe dari constraint partisipasi, total dan parsial. Bila

sebuah kebijakan company menyatakan bahwa setiap employee harus bekerja untuk

sebuah department, maka sebuah entity employee dapat exist hanya bila dia berpartisipasi

dalam instansi relationship WORKS_FOR (gambar3.9). Kondisi demikian, partisipasi

EMPLOYEE dalam WORKS_FOR disebut partisipasi total,yang berarti bahwa setiap entity

dalam “himpunan total” dari entity employee harus direlasikan ke entity department melalui

WORKS_FOR. Partisipasi total disebut juga existence dependency.

4. Atribut-atribut dari Tipe Relationship

Tipe relationship dapat juga mempunyai atribut, serupa dengan tipe entity. Contoh, Untuk

mencatat jumlah jam per minggu dimana seorang employee bekerja pada project tertentu,


Halaman : 22

kita dapat memasukkan sebuah atribut Hours untuk tipe relationship WORKS_ON pada

gambar 11.

Gambar 11. Relasi M:N dari WORKS_ON antara EMPLOYEE dan PROJECT

Perlu dicatat bahwa atribut tipe relationship 1:1 atau 1:N dapat dipindahkan ke satu dari tipe

entity yang berpartisipasi. Contoh, atribut StratDate untuk relationship MANAGES dapat

menjadi atribut dari EMPLOYEE atau DEPARTMENT meskipun secara konseptual dia

dimiliki oleh TO MANAGE. Ini dikarenakan MANAGE adalah relationship 1: 1 sehingga

setiap entity department atau employee berpartisipasi dalam sebagian besar instansi

relationship. Oleh karenanya value dari atribut StartDate dapat ditentukan secara terpisah

dengan berpartisipasi pada entity department tau dengan berpartisipasi pada entity

employee (manager).

Untuk tipe relationship 1:N atribut relationship dapat dipindahkan hanya ke tipe entity pada

sisi N dari relationship. Dalam tipe relationship 1:1 dan 1:N keputusan dimana sebuah atribut

seharusnya ditempatkan , sebagai sebuah atribut tipe relationship atau sebagai sebuah

atribut dari sebuah tipe entity partisipasi ditentukan secara subjektif oleh desainer skema.

Untuk tipe relationship M:N, beberapa atribut dapat ditentukan dengan kombinasi dari enity

yang berpartisipasi dalam sebuah instansi relationship, tidak oleh entity tunggal/single.

Dengan demikian atribut harus dispesifikasi sebagai atribut relationship.


Halaman : 23

1.9. Tipe Entity Weak

Tipe entity yang tidak mempunyai atribut key untuk mereka sendiri disebut tipe entity lemah

(weak entity types). Entity yang memiliki tipe entity weak diidentifikasi oleh hubungannya

terhadap entity spesifik dari tipe entity lain dalam kombinasi dengan beberapa value atribut

mereka. Kita sebut entity lain ini tipe entity pengidentifikasi atau pemilik. Tipe entity weak

selalu mempunyai constraint total partisipasi (terdapat ketergantungan) karena entity weak

tidak dapat diidentifikasi tanpa entity owner. Tetapi tidak setiap keberadaan dependency

menghasilkan tipe entity weak.

Perhatikan tipe entity DEPENDENT, dihubungkan ke EMPLOYEE yang digunakan untuk

mencatat dependent dari masing-masing employee dengan relationship 1:N (gambar 2).

Atribut dari DEPENDENT adalah Name, BirthDate, Sex dan relationship (ke employee). Dua

dependent dari dua employee yang berbeda , dimana memiliki value yang sama untuk

Name, BirthDate, Sex dan relationship tetapi mereka adalah entity yang berbeda.. Mereka

diidentifikasi sebagai entity yang berbeda hanya setelah menentukan entity employee

tertentu dimana masing-masing dependent dihubungkan. Masing-masing entity employee

dikatakan memiliki entity dependent yang dihubungkan dengannya.

Tipe entity lemah biasanya mempunyai partial key, yaitu sekelompok atribut yang dapat

secara unik diidentifikasi sebagai entity lemah yang berhubungan dengan entity owner yang

sama. Tipe entity lemah dapat juga direpresentasikan sebagai atribut kompleks (Composit,

multivalue).

1.10. Perbaikan Desain ER untuk Database COMPANY

Sekarang kita bisa memperbaiki desain database pada gambar 6 dengan mengubah atribut

yang merepresentasikan relationship ke dalam tipe relationship. Perbandingan kardinalitas

dan constraint partisipasiuntuk masing-masing tipe relationship ditentukan dari daftar

requirement. Bila beberapa perbandingan kardinalitas dependency tidak dapat ditentukan

dari requirement, user harus ditanya untuk menentukan constraint struktural ini. Dalam

contoh kita, kita menspesifikasi tipe-tipe relationship sebagai berikut:

1. MANAGES, sebuah tipe relationship antara EMPLOYEEE dan DEPARTMENT.

EMPLOYEE berpartisipasi secara parsial, sementara partisipasi DEPARTMRNT tidak


Halaman : 24

jelas dari requirement. Dari user diketahui bahwa department harus mempunyai

manager setiap saat yang mengimplikasikan partisipasi total. Atribut StartDate

ditandai untuk tipe relationship ini.

2. WORKS_FOR, sebuah tipe relationship 1:N antara DEPARTMENT dan EMPLOYEE.

Keduanya berpartisipasi secara total.

3. CONTROLS, sebuah tipe relationship 1:N antara DEPARTMENT dan PROJECT.

Partisipasi PROJECT adalah total sementara DEPARTMENT ditentukan parsial

setelah berkonsultasi dengan user.

4. SUPERVISION, adalah tipe relationship 1:N antara EMPLOYEE (dalam Role

Supervisor) dan EMPLOYEE (dalam role supervisee). Kedua partisipasi ditentukan

parsial setelah user menunjukkan bahwa tidak setiap pegawai adalah supervisor dan

tidak setiap employee mempunyai supervisor.

5. WORKS_ON, ditentukan menjadi tipe relationship M:N dengan atribut Hours, setelah

users menunjukkan bahwa project dapat memiliki beberapa pegawai yang bekerja

padanya. Kedua partisipasi ditentukan total partisipasi.

6. DEPENDENTS_OF, adalah tipe relationship antara EMPLOYEE dan DEPENDENT,

yang juga mengidentifikasi relationship untuk tipe entity lemah DEPENDENT.

Partisipasi EMPLOYEE adalah parsial sementara DEPENDENT adalah total.

Setelah menspesifikasi enam tipe relationship tersebut di atas, kita mengganti tipe entity

gambar 6 semua atribut yang telah diperbaiki dalam relationship. Hal ini termasuk Manager

dan managerStartDate dari DEPARTMENT; ControllingDepartment dari PROJECT;

Department, Supervisor dan WorksOn dari EMPLOYEE; dan Employee dari DEPENDENT.

Adalah penting untuk mempunyai sekecil mungkin redundancy ketika kita mendesain skema

konseptual dari database.


Halaman : 25

1.11. ER Diagram, Konvensi Penamaan dan Isu-isu dalam Desain

1. Notasi untuk ER Diagram

Gambar 3.13 mengilustrasikan tipe entity dan tipe relationship dengan menampilkan

extension mereka – entity individu dan instansi relationship. Dalam ER diagram titik beratnya

adalah pada representasi dari skema dibandingkan instansi. Ini lebih bermanfaat karena

sebuah skema database jarang berubah sementara extension sering berubah. Skema lebih

mudah untuk ditampilkan dibanding extension database karena lebih kecil. Gambar 3.14

adalah ringkasan konvensi untuk ER diagram.

2. Penamaan yang Sesuai dari Konstruksi Skema

Dalam memberikan nama untuk tipe entity, atribut dan relationship seharusnya dipilih nama

yang dapat memiliki arti yang dapat menjelaskan konstruksi yang berbeda dalam skema.

3. Pilihan Desain Untuk Desain Konseptual ER

Kadang sulit untuk memutuskan apakah konsep tertentu dalam miniworld seharusnya

dimodelkan sebagai sebuah tipe entity, sebuah atribut atau sebuah relationship. Berikut ini

adalah petunjuk untuk mengkonstruksi pilihan yang seharusnya dipilih dalam siatuasi

tertentu.


Halaman : 26

Gambar 12. Rangkuman notari diagram ER


Halaman : 27

Secara umum proses desain skema seharusnya dilihat sebagai sebuah proses perbaikan

yang iteratif, dimana desain awal dibuat kemudian diperbaiki terus menerus sampai desain

yang cocok diperoleh. Beberapa perbaikan yang sering digunakan adalah sbb:

1. Konsep mungkin pertama kali dimodelkan sebagai sebuah atribut dan kemudian

diperbaiki dalam sebuah relationship karena penentuan atribut tersebut adalah

referensi ke tipe entity lain. Sering terdapat kasus bahwa pasangan atribut tersebut

adalah invers satu dengan yang lain diperbaiki dalam relationship benary.

2. Serupa dengan hal tersebut, sebuah atribut yang ada dalam beberapa tipe

entitymungkin diperbaiki ke dalam tipe entity independentnya sendiri.

3. Perbaikan kebalikan dari kasus sebelumnya mungkin diaplikasikan. Contoh, bila tipe

entity DEPARTMENT ada dalam desain awal dengan sebuah atribut tunggal

DeptName dan berhubungan hanya dengan satu tipe entity lain STUDENT. Dalam

kasus ini DEPARTMENT dapat diperbaiki dalam sebuah atribut dari STUDENT.

4. Perbaikan yang lain adalah tentang spesialisasi/generalisasi dan relationship dari

derajat tinggi.

1.12. Notasi alternatif untuk Diagram ER

Ada banyak alternatif notasi diagramatik untuk menampilkan diagram ER, seperti notasi

Universal Modelling Language (UML) yang telah diajukan sebagai standar untuk pemodelan

object konseptual.

Pada gambar 13 menampilkan skema database COMPANY menggunakan notasi (min,max).

Biasanya hanya menggunakan perbandingan kardinalitas/garis tunggal/garis double atau

notasi min/max. Notasi min/max adalah lebih tepat, dan kita dapat menggunakan dengan

mudah untuk menspesifikasi constraint struktura untuk tipe relationship dari beberapa

degree.


Halaman : 28

Gambar 13. Diagram ER darri skema COMPANY, dengan semua nama role constrainnt

yang terstruktur pada setiap relasinya menggunakan notasi tambahan


Halaman : 29

2. Microsoft Access

Software Microsoft Office merupakan satu software yang sangat popular pada masa

sekarang. Software ini dikategorikan sebagai software automasi perkantoran yang bertujuan

untuk memudahkan kerja-kerja rutin perkantoran, contohnya penyediaan laporan, memo dan

laporan kewangan. Microsoft Access merupakan antara paket yang ditawarkan oleh software

ini. Terdapat beberapa kelebihan dan kelemahan software ini.

Kelebihan penggunaan Microsoft Access

1. Berasaskan platform windows

Pada masa sekarang, software windows telah digunakan dengan meluas pada masa

sekarang. Ini kerana platform windows ini amat sesuai untuk lapisan pengguna

komputer baru. Namun demikian, sistem yang dibangun lebih mudah digunakan oleh

semua lapisan pengguna.

2. Kurang memerlukan pemprograman

Pembangunan sistem menggunakan software ini sangat mudah. Ini kerana software

ini banyak mengandungi bantuan (wizard). Bantuan yang disediakan termasuk

penambahan, pembuangan dan pengemaskinian pangkalan data (update database).

Pengguna hanya perlu memilih ciri-ciri yang diperlukan manakala selebihnya

dilaksanakan oleh Microsoft Access tersebut. Bantuan ini menyebabkan

pembangunan menggunakan software ini hampir tidak memerlukan pemprograman.

3. Mudah implementasi

Dari segi implementasi, sistem yang dihasilkan ini tidak memerlukan konfigurasi yang

kompleks. Sistem tersebut mudah dimasukkan dan mudah dipindahkan ke tempat

lain.

Kelemahan penggunaan Microsoft Access

1. Tahap keselamatan rendah

Software ini tidak sesuai untuk pembangunan sistem yang memerlukan tahap sekuriti

yang tinggi. Selain itu, sistem ini tidak sesuai untuk menyimpan data yang sangat

besar. Ini menyebabkan perusahaan besar tidak memilih software ini untuk

membangunkan sistem mereka.


Halaman : 30

2. Kurang fleksibel

Pembangunan sistem ini banyak bergantung kepada wizard. Oleh demikian, fungsi

menjadi kurang fleksibel kerena tata caranya telah ditetapkan oleh Microsoft Access.

Namun begitu, sistem ini masih lagi sesuai untuk pembangunan sistem data ringkas

dan berukuran kecil.


Halaman : 31

3. Membangun Sistem Buku Alamat

Untuk memulai pembangunan sistem ini, anda dikehendaki memasukkan software Microsoft

Access ke dalam komputer peribadi anda. Kemudian, anda telah siap untuk membangunkan

sistem. Caranya adalah seperti berikut :

1. Buka software Microsoft Access.

2. Klik menu "file" dan kemudian klik "new" untuk memulai pembangunan pangkalan

data baru.

3. Kemudian, satu window baru akan dipaparkan. Terdapat dua bagian pada window

tersebut iaitu "General" dan "Databases". (gambar 14)

1. Databases adalah bagian dimana terdapat template untuk pembangunan

sistem. Anda hanya perlu mengisi data yang diperlukan dan kemudian sistem

tersebut siap digunakan.

2. General adalah bagian untuk membentuk dan membangun sistem pada tahap

awal. Walaupun ia lambat, namun ia lebih fleksibel berbanding dengan sistem

yang anda buat secara template atau wizard.

Gambar 14. Menu Membuat Databse Baru

4. Untuk membangunkan sistem ini, anda dikehendaki memilih "Database" dalam menu

"General".


Halaman : 32

5. Kemudian anda dikehendaki memasukkan nama pangkalan data (nama database)

sistem yang ingin anda buat. Sebagai contoh, letakkan nama sistem tersebut sebagai

"Book Address" (gambar 15)

Gambar 15. Nama File Database

Di bagian kiri window tersebut, terdapat beberapa bagian objects yaitu tables, queries,

forms, reports, pages, macros, modules.

1. Tables - bagian ini merupakan tempat untuk membuat tabel untuk sistem.

2. Queries - bagian ini merupakan tempat untuk mengeluarkan paparan berdasarkan

kekangan dan ciri-ciri tertentu.

3. Forms - bagian ini merupakan tempat untuk membuat antaramuka form untuk

memudahkan pengguna memasukkan data ke pangkalan data.

4. Reports - bagian ini merupakan tempat untuk membuat laporan untuk dijadikan

rujukan kepada pengguna.

5. Pages - bagian ini pula merupakan tempat untuk membuat antaramuka form dalam

bentuk webpage.

6. Macros - bagian ini merupakan tempat untuk membuat set-set arahan kepada sistem.

Contoh set arahan adalah seperti kotak pesan (message) dan pemberitahuan kepada

pengguna.


Halaman : 33

7. Modules - bagian ini merupakan tempat untuk membuat pemprograman terhadap

sub-fungsi untuk tujuan tertentu. Bagian ini juga tidak akan disentuh dalam

perbincangan kali ini.

Di dalam latihan ini, kita hanya akan menyentuh bagian tables, forms dan reports saja.

3.1. Membuat Tabel

Bagi memulai membuat tabel, pengguna diberikan 3 jenis pilihan. Untuk contoh ini,

pengguna disarankan memilih "Create Table in Design View". Apabila pilihan tersebut dipilih,

satu window baru akan dibuka. Terdapat 3 slot utama dalam bagian ini iaitu :

1. Field Name : Slot ini adalah slot untuk nama attribut sebagai contoh no_id , nama,

alamat dan no_tel. Sembarang huruf boleh dimasukkan kecuali huruf khas termasuk

jarak (space bar) dan juga titik.

2. Data Type : Jenis data bagi data tersebut.

3. Description : Keterangan bagi data tersebut.

Sebagai contoh, masukkan data berikut ke dalam tempat yang disediakan :

Field Name Data Type Description

1 NoID Autonumber bil data pengguna

2 Nama Text nama pengguna

3 Alamat Text alamat pengguna

4 NoTel Text no telephon pengguna

5 Email Text alamat e-mail pengguna

Katakunci merupakan data unik bagi seseorang pengguna. Ia amat penting dalam proses

pencarian pengguna. Dalam sistem ini jadikan NoID sebagai primary key (katakunci).

Caranya dengan klik kanan lajur NoID dan kemudian klik pada pilihan "primary key".

Seterusnya, "save" tabel tersebut dengan nama "Utama".


Halaman : 34

3.2. Membuat Form

Dalam contoh kali ini, anda akan belajar membuat form menggunakan wizard. Untuk

membuat form, klik pada bagian form disebelah kiri window. Kemudian, ambil pilihan "Create

Form By Using Wizard".

Gambar 16. Membuat Form Menggunakan Wizard

Satu window baru akan dipaparkan, masukkan ke semua item dalam "Available Fields" ke

dalam "Selected Fields" dengan klik pada simbol ">>". Kemudian, klik pada buton "Finish".

Maka selesailah satu form baru. Kemudian, tutup form tersebut.


Halaman : 35

Gambar 17. "Available Fields" ke dalam "Selected Fields"

Untuk memperbaiki tampilan form tersebut, klik kanan pada nama form dan pilih menu

"Design". Untuk menambah fungsi tambah dan buang data anda dikehendaki untuk

membuat buton (tombol) sendiri.

Gambar 18. Design Form

Cara membuat buton, pergi ke window "Toolbox" seperti yang terletak dibagian kanan

gambar rujukan. Pilih objek di baris ke-3, lajur ke-3 dan klik ke dalam bagian detail form.

Satu window baru akan keluar, anda dikehendaki memilih kategori "Record Operation" dan

pilih actions "Add New Records". Kemudian, tekan buton "Finish" maka selesailah buton

tambah rekod. Buat kaedah yang sama tetapi kali ini pilih action "Delete Record" untuk buat

buton tambah rekod.


Halaman : 36

Gambar 19. Record Operation

Seterusnya, setelah selesai membuat bentuk laporan pada topik seterusnya nanti buat buton

pada bagian ini dengan memasuki "Report Operation" dan pilih menu "open report". Pastikan

pada praktek ini dapat selesai membentuk laporan.

Untuk bagian memperbaiki tampilan, anda hanya memilih rekord dengan menggunakan

navigation button yang terletak dibagian bawah form. Untuk melihat paparan form, klik kanan

pada nama form dan klik open.

3.3. Membuat Laporan

Dalam latihan kali ini, anda akan mencoba membuat laporan menggunakan wizard. Untuk

membuat laporan, klik pada bagian report disebelah kiri window. Kemudian, ambil pilihan

"Create Report By Using Wizard".

Satu window baru akan dipaparkan, masukkan ke semua item dalam "Available Fields" ke

dalam "Selected Fields" dengan klik pada simbol ">>". Kemudian, klik pada buton "Finish".

Maka selesailah satu form baru. Kemudian, tutup klik tersebut.


Halaman : 37

Gambar 20. Create Report By Using Wizard

Untuk mengemaskini paparan report tersebut, klik kanan pada nama report dan pilih menu

"Design".

Kemudian, balik ke bagian form dan buat buton untuk membuka laporan ini.

Gambar 21. Design Report


Halaman : 38

4. Teknik Impot Data Ke Access

Anda dapat mengimpot data dari Visual FoxPro database kepada Microsoft Access database

dengan cara impot opysen berikut.

1. Buka Microsoft Access database.

2. Dari File menu, pilih Get External Data dan seterusnya Impot.

3. Didalam Import dialog box, pilih ODBC Databases( ) yang memaparkan Files type list.

4. Didalam SQL Data Sources dialog box, pilih Visual FoxPro data source yang

menyambung kepada FoxPro data yang anda ingin query and klik OK.

5.Didalam Import Objects dialog box, pilih salah satu tables atau lebih untuk di impot

dan klik OK. Nama Visual FoxPro tables yang anda impot ditayangkan didalam Tables

tab Microsoft Access database.

Sekarang anda boleh guna Microsoft Access untuk manipulate data yang di impot dari

Visual FoxPro tables.

data yang anda impot adalah snapshot dari data yang tersimpan di Visual FoxPro; Jika anda

membuat

perubahaan maka data impot tidak akan dihantar semula kepada Visual FoxPro data source.

4.1. Teknik Lain Dalam Access Data

Jika anda ingin membuat perubahaan didalam Microsoft Access untuk menukar

data di Visual FoxPro data source, anda perlu buat Querying dan Updating

Visual FoxPro Data dari Microsoft Access.Cara Querying dan Updating Visual

FoxPro Data dari Microsoft Access dengan menggunakan the Link Table option.

Untuk link Visual FoxPro database kepada Microsoft Access database

1.buka Microsoft Access database.

2.Dari Tables tab, click New.

3.Di New Table dialog box, pilih Link Table dan klik OK.

4.Di Link dialog box, pilih ODBC Databases( ) dan lihat Files type list.

5.Di SQL Data Sources dialog box, pilih data source yang menhubungi Visual


Halaman : 39

FoxPro data yang anda ingin query dan klik OK.

6.Di Link Tables dialog box, pilih tables yang anda ingin query dan update

serta klik OK. Visual FoxPro tables akan dipaparkan didalam Tables tab

Microsoft Access database.

Anda sekarang boleh menggunakan Microsoft Access untuk query dan update data

terangkai (linked) Visual FoxPro tables.Apa-apa perubahaan dibuat data akan

dihantar semula kepada Visual FoxPro data source.

4.2. Mengenal Microsoft Data Access Components (MDAC)

Tulisan ini penulis translate dari suatu dokumen Microsoft yang berjudul "What are the

Microsoft Data Access Components". Tulisan ini berbicara seputar komponen-komponen

apa saja yang menjadi bagian dari MDAC (Microsoft Data Access Components).

Apa itu Microsoft Data Access Components?

Microsoft Data Access Components (MDAC) adalah sekumpulan komponen yang

merupakan kunci dari teknologi yang membangun Universal Data Access. Aplikasi

database client/server baik itu yang berbasis web ataupun pada suatu LAN dapat

menggunakan komponen-komponen ini untuk mengintegrasikan informasi dari berbagai

macam sumber data, baik itu yang sifatnya relasional (SQL) maupun data yang tidak

relasional. Komponen-komponen dalam MDAC ini diantaranya adalah:

§ Microsoft ActiveX Data Objects (ADO)

§ OLE DB

§ Open Database Connectivity (ODBC)

Gambar 22 berikut ini akan menunjukkan secara keseluruhan mengenai arsitektur MDAC

dan bagaimana MDAC ini menjadi kunci dalam membangun model UDA (Universal Data

Access).


Halaman : 40

Gambar 22. Jenis MDAC pada Microsoft Access

§ ActiveX Data Objects (ADO)

Microsoft ActiveX Data Objects (ADO) adalah suatu Application Programming Interface

(API) strategis yang khusus digunakan dalam pengaksesan data dan informasi. ADO

memberikan cara yang konsisten, pengaksesan data dengan performa tinggi yang

mendukung berbagai kepentingan untuk membangun sebuah aplikasi, termasuk dalam

pembuatan aplikasi client database dan middle-tier business object yang menggunakan

aplikasi, tools, bahasa atau browser internet. ADO didisain sedemikian rupa untuk

menjadi satu data interface yang dapat digunakan untuk kepentingan single dan

multitier client/server dan aplikasi berbasis web. Keuntungan utama dari ADO adalah

kemudahan dalam penggunaan, kecepatan tinggi, penggunaan memory yang minimal

dan small disk footprint.

Anda dapat melihat posisi ADO pada gambar diatas. ADO berada diatas teknologi

akses data yang lain dan memberikan dukungan data akses terhadap para developer.

ADO memberikan kemudahan interface dalam mengakses OLE DB. ADO menerapkan

trafik jaringan secara minimal dan meminimalkan jumlah layer antara fron-end dan

sumber data untuk memberikan interface yang ringan tetapi dengan performa yang


Halaman : 41

tinggi. ADO sangat mudah digunakan karena berbasis interface COM automation yang

saat ini sudah tersedia pada semua RAD development tools, database tools dan

bahasa-bahasa pemrograman di pasaran.

§ OLE DB

OLE DB adalah interface strategis programming pada level sistem untuk mengakses

data. OLE DB adalah suatu spesifikasi terbuka yang didisain atas kesuksesan ODBC

dengan memberikan suatu standard terbuka untuk mengakses berbagai macam data.

ODBC dibuat untuk mengakses database relasional, sedangkan OLE DB didisain untuk

datab relasional maupun non-relasional, ini termasuk mainframe ISAM/VSAM dan

hierarchical database; e-mail dan file system; text, grafis, data geografis; custom

business object dan masih banyak lagi yang lain.

OLE DB digambarkan sebagai sebuah kumpulan dari COM interface yang meng-

encapsulate berbagai macam service database management system. Interface-

interface ini memungkinkan pembuatan suatu komponen software yang digunakan oleh

berbagai macam service. Komponen OLE DB terdiri dari data provider, yang berisi

data; data consumer, yang menggunakan data; dan komponen service, yang

memproses dan mengirimkan data (seperti prosesor query dan cursor engine).

Interface OLE DB didisain untuk membantu komponen-komponen agar dapat

berintegrasi secara mudah sehingga pembuat komponen OLE DB dapat membuat

komponen OLE DB bagi pengguna dengan kualitas yang baik dan cepat. Sebagai

tambahan, OLE DB menawarkan suatu jembatan kepada ODBC untuk menambah

dukungan pada driver database ODBC yang banyak ragamnya saat ini.

§ Open Database Connectivity (ODBC)

Interface Microsoft Open Database Connectivity (ODBC) adalah suatu standard

industri saat ini dan merupakan komponen dari Microsoft Windows Open

Services Architecture (WOSA). Interface ODBC membuat aplikasi-aplikasi

dapat mengakses data dari berbagai macam database management system

(DBMSs). ODBC mengijinkan interoperabilitas secara maksimal terhadap

berbagai macam DBMS hanya dengan melalui satu interface. Ini dapat


Halaman : 42

dikatakan bahwa suatu aplikasi akan berjalan secara independen. Pengguna

aplikasi dapat menambah suatu software komponen yang dinamakan driver,

yang mana menciptakan suatu interface antara suatu aplikasi dan suatu DBMS

spesifik.

Documents

Access me