7

 

BAB 2

LANDASAN TEORI

2.1 Teori-teori Dasar/Umum

 

2.1.1 Data

Data adalah fakta yang didapat, di mana kenyataan tambahan dapat

ditarik menjadi simpulan (Date, 2004, p15). Data merupakan fakta yang dapat

dicatat dan mempunyai arti secara implicit (Elmasri, 2000, p24). Dari definisi

data menurut Date dan Elmasri, dapat disimpulkan bahwa data adalah

sekumpulan baris fakta yang mewakili peristiwa yang terjadi pada organisasi

atau pada lingkungan fis ik sebelum diolah ke dalam format yang dapat

dimengerti dan digunakan manusia.

Data yang merupakan bahan baku informasi, adalah nilai yang turut

merepresentasikan deskripsi dari suatu obyek atau kejadian. Dalam bahasa

Inggris yang baku, kata data hanya digunakan untuk menyebut fakta yang

berkuantitas jamak, sedangkan datum digunakan untuk menyebut fakta yang

berkuantitas tunggal.

2.1.2 Informasi

Informasi merupakan hasil dari pengolahan data ke dalam suatu bentuk

yang lebih berguna dan lebih berarti bagi penerimanya dan menggambarkan

suatu kejadian nyata yang dapat digunakan untuk pengambilan keputusan.

8

 

Informasi adalah salah satu sumber daya utama suatu organisasi yang dapat

dikelola seperti halnya sumber daya yang lain.

2.1.2.1 Kualitas Informasi

Informasi mempunyai tingkat kualitas yang dapat ditentukan

oleh beberapa hal, yaitu:

a. Akurasi

Informasi harus tepat dan jelas maksudnya.

b. Ketepatan Waktu

Informasi harus dapat diakses saat dibutuhkan.

c. Relevansi

Informasi harus memiliki manfaat bagi pemakainya.

d. Kelengkapan

Informasi harus berisi data yang dibutuhkan.

2.1.2.2 Nilai Informasi

Nilai informasi ditentukan oleh dua hal, yaitu kualitas dan

biaya mendapatkannya. Suatu informasi dikatakan bernilai apabila

kualitasnya lebih besar dibandingkan dengan biaya mendapatkannya.

2.1.3 Database

Database adalah kumpulan data yang berhubungan secara logika dan

deskripsi dari data tersebut, dirancang untuk memenuhi kebutuhan informasi

9

 

dalam suatu organisasi (Connolly, 2002, p14). Secara lengkap, database

adalah tempat penyimpanan tunggal yang besar dari data yang dapat

digunakan secara simultan oleh banyak departemen dan pengguna (Connolly,

2002, p14).

Database tidak hanya menyimpan data-data operasional suatu organisasi

tetapi juga deskripsi dari data tersebut. Database tidak hanya dimiliki oleh satu

departemen saja, tetapi juga dibagi untuk sumber daya perusahaan.

2.1.4 Database Management System (DBMS)

DBMS (Connolly, 2002, p16), merupakan sistem perangkat lunak yang

memungkinkan pengguna untuk mendefinisikan, membuat, memelihara, dan

mengontrol akses ke database.

DBMS menyediakan beberapa fasilitas (Connolly, 2002, p16), yaitu:

a. Data definition language (DDL), memungkinkan pengguna untuk

mengelompokkan tipe dan struktur data dan batasan-batasan pada data

yang akan disimpan ke dalam database.

b. Data manipulation language (DML), memungkinkan pengguna untuk

memasukkan, mengubah, menghapus, dan mendapatkan kembali data dari

database.

c. Menyediakan akses kontrol ke database, misalnya:

1. Sistem keamanan, mencegah pengguna yang belum sah mengakses

database.

2. Sistem integritas, yang memelihara konsistensi dari penyimpanan data.

10

 

3. Sistem kontrol yang concurrency, yang memungkinkan berbagi akses

database.

4. Sistem kontrol recovery, yang mengembalikan database ke dalam

keadaan yang sesuai sebelumnya setelah kegagalan hardware atau

software.

5. User-accessible catalog, yang berisi deskripsi data dalam database.

2.1.5 Arsitektur Database

Arsiterktur database dibagi menjadi tiga (Connolly, 2002, p34), yaitu:

1. External level

Cara pengguna melihat data disebut dengan external level. Level ini

mendeskripsikan bagian dari database yang bersangkutan dengan setiap

pengguna. External level terdiri dari sejumlah external view dari database.

Di dalam external level terdapat entities, attributes, dan relationships

dalam ’real world’ yang dibutuhkan oleh pengguna. Setiap pengguna

memiliki view yang berbeda-beda. View yang berbeda-beda memiliki cara

yang berbeda-beda dalam menggambarkan data yang sama. View bisa

berisi kombinasi data atau turunan dari beberapa entity.

2. Conceptual level

Level konseptual menyediakan pemetaan dan ketidaktergantungan

yang diinginkan antara level external dan internal. Level ini

menggambarkan data yang disimpan di dalam database dan hubungan di

antara data-data tersebut. Level ini berisi struktur logika dari keseluruhan

11

 

database seperti yang dilihat oleh DBA (Database Administrator). Bagian

ini adalah tampilan keseluruhan data-data kebutuhan dari organisasi.

Level konseptual menggambarkan (Connolly, 2002, p36) :

a. Seluruh entity, atribut, dan relationship.

b. Batasan-batasan pada data.

c. Informasi semantik tentang suatu data.

d. Informasi keamanan dan integritas.

Level konseptual mendukung external view, di mana beberapa data

yang terkandung di dalamnya atau diturunkan dari level konseptual tersedia

bagi pengguna.

3. Internal level

Internal level merupakan representasi fisik database pada komputer.

Tingkatan ini mendeskripsikan bagaimana suatu data disimpan di dalam

database. Internal level meliputi implementasi fisik dari database ke arsip

yang optimal dan pemanfaatan ruang penyimpanan. Internal level

mengulas struktur data dan organisasi file dalam menyimpan data dalam

media penyimpanan.

Internal level berhubungan dengan hal-hal berikut (Connolly, 2002,

p37):

a. Alokasi tempat penyimpana data dan index.

b. Deskripsi penyimpanan (misalnya: ukuran data).

c. Penempatan record.

d. Teknik kompresi dan enkripsi data.

12

 

Tujuan dari three level architecture adalah untuk memisahkan setiap

tampilan yang dilihat oleh pengguna dari suatu database dari cara database

tersebut disimpan secara fisik.

2.1.6 Entity Relationship

ER (Entity Relationship) merupakan pendekatan top-down untuk desain

database yang dimulai dengan mengidentifikasi data yang penting yaitu entity

dan relationship di antara data yang harus direpresentasikan ke dalam model.

Pemodelan ER merupakan teknik yang penting bagi perancang database.

Komponen-komponen dari entity relatioship (Connolly, 2002, p331),

yaitu:

1. Entity Types

Entity types merupakan konsep dasar dalam model ER, adalah

sekumpulan obyek dengan ciri yang sama. Entity type memiliki wujud

yang bebas dan dapat menjadi obyek dengan wujud fisik atau konseptual.

Setiap desainer yang berbeda mengidentifikasikan entity yang berbeda.

Cara untuk mengidentifikasi setiap entity type melalui nama dan ciri-

cirinya. Normalnya, database berisi entity type yang berbeda-beda.

Setiap entity type digambarkan dengan bentuk persegi panjang yang

diberikan nama untuk masing-masing entity dengan kata tunggal. Dalam

UML, setiap huruf pertama dari setiap kata menggunakan huruf besar.

13

 

2. Relationship Types

Merupakan suatu set hubungan antara seluruh entity types. Setiap

relationship type diberikan nama yang mendeskripsikan fungsinya.

Asosiasi tersebut memiliki nama yang unik sesuai dengan kejadian di

antara entity type yang saling berhubungan.

Setiap relationship type digambarkan dengan garis yang

menghubungkan entity-entity, diberi nama yang sesuai dengan nama

relationship-nya. Normalnya, nama relationship ditulis dengan

menggunakan kata kerja. Huruf pertama dari nama relationship ditulis

dengan menggunakan huruf besar. Relationship digambarkan hanya dengan

satu arah.

Nama Entity

User Barang

Gambar 2. 1 Entity Types

14

 

Tingkat tipe relationship adalah jumlah tipe-tipe entity dalam sebuah

relationship. Ada beberapa macam tingkat tipe relationship (Connolly,

2002, p336):

a. Binary, adalah relationship yang memiliki dua tingkat.

b. Ternary, adalah relationship yang memiliki tiga tingkat.

Staff Cabang

Klien

Daftar

Nama relationship

Staff Cabang Memiliki

Pemilik Saham

Gambar 2. 2 Relationship Types

Gambar 2. 3 Binary Relationship

Gambar 2. 4 Ternary Relationship

15

 

c. Quaternary, adalah relationship yang memiliki empat tingkat.

Recursive relationship merupakan tipe relationship di mana entity

yang sama digunakan lebih dari sekali dengan peran yang berbeda.

Recursive relationship biasanya disebut juga unary relationship.

3. Attributes

Staff

supervisor

supervisee

Nama Peran

Nama Peran

mengawasi

Pembeli Keuangan

Tawaran

Mengatur

Pengacara

Gambar 2. 5 Quaternary Relationship

Gambar 2. 6 Recursive Relationship

16

 

Atribut merupakan properti dari suatu entity. Atribut menyimpan

nilai yang dideskripsikan pada setiap entity dan menggambarkan bagian

utama dari data yang disimpan di dalam database. Atribut dapat

diklasifikasikan menjadi tiga (Connolly, 2002, p339), yaitu:

a. Simple and Composite Attributes

Simple attribute merupakan atribut yang tersusun dari komponen

tunggal. Atribut ini tidak dapat dibagi menjadi komponen yang lebih

kecil. Biasanya disebut atomic attributes. Contohnya, gaji, jabatan.

Composite attribute merupakan atribut yang tersusun dari

beberapa komponen. Beberapa atribut dapat dibagi untuk menghasilkan

komponen yang lebih kecil. Contohnya, alamat yang memiliki sub

komponen (Jl.Merpati, Jakarta, 94111) dapat dibagi menjadi jalan

(Jl.Merpati), kota (Jakarta), kode pos (94111).

b. Single-Valued and Multi-Valued Attributes

Single-valued attribute merupakan atribut yang menyimpan nilai

tunggal untuk setiap kejadian dari suatu entity. Contoh, nomor induk

mahasiswa (NIM).

Multi-valued attribute merupakan atribut yang menyimpan

beberapa nilai dari suatu entity. Contoh, nomor telepon.

c. Derived Attributes

Derived attribute merupakan atribut yang menggambarkan nilai

yang diturunkan dari nilai satu set atribut, tidak harus berasal dari entity

yang sama.

17

 

4. Structural Constraints

Constraints seharusnya bisa mewakili batasan-batasan terhadap

hubungan yang dirasakan dalam dunia nyata. Jumlah kejadian yang

mungkin terjadi dari suatu entity yang saling berhubungan dalam suatu

relationship tertentu disebut multiplicity. Ada tiga tipe multiplicity

(Connolly, 2002, p345), yaitu:

a. One-to-one relationship (1:1)

b. One-to-many relationship (1:*)

1..1 0..1

Staff

NoStaff

Cabang

NoCabang

Mengatur

Multiplicity

Setiap cabang diatur oleh 1 staff

Setiap staff dapat mengatur 0 atau 1 cabang

Gambar 2. 7 One-to-one Relationship

18

 

c. Many-to-many relationship (*:*)

Cardinality mendeskripsikan jumlah maksimum dari relationship

yang mungkin terjadi untuk entity yang berpartisipasi dalam memberikan

tipe relationship. Misalnya, cardinality untuk binary relationship yaitu

one-to-one (1:1), one-to-many (1:*), dan many-to-many (*:*).

0..* 1..*

SuratKabar

NamaSurat

Properti

NoProperti

Memasarkan

Setiap properti dipasarkan oleh 0 atau banyak surat kabar

Setiap surat kabar memasarkan 1 atau banyak properti

0..1 0..*

Staff

NoStaff

Propeti

NoProperti

Mengawasi

Setiap properti dapat diawasi oleh 0 atau 1 staff

Setiap staff dapat mengawasi 0 atau banyak properti

Gambar 2. 8 One-to-many Relationship

Gambar 2. 9 Many-to-many Relationship

19

 

Participation menentukan seluruh atau hanya beberapa entity terlibat

dalam suatu relationship. Participation terbagi menjadi dua (Connolly,

2002, p351), yaitu:

a. Mandatory, merupakan participation constraint yang menggambarkan

keseluruhan entity terlibat dalam suatu relationship tertentu.

b. Optional, merupakan participation constraint yang menggambarkan

hanya beberapa entity terlibat dalam suatu relationship tertentu.

2.1.7 Normalisasi

Normalisasi merupakan teknik formal untuk menganalisis hubungan

berdasarkan primary key atau candidate key dan ketergantungan fungsional.

Pada awalnya, proses normalisasi dimulai dengan memindahkan data ke

dalam bentuk tabel dengan format baris dan kolom. Tabel tersebut masih

berbentuk tidak normal yang disebut unnormalized table

(Connolly,2002,p388).

Unnormalized form (UNF), merupakan suatu tabel yang terdiri dari satu atau

lebih kelompok yang berulang (Connolly, 2002,p387). Kelompok yang berulang

(repeating group) adalah atribut atau himpunan atribut di dalam tabel yang memiliki

lebih dari satu nilai (multiple value) untuk sebuah primary key pada tabel tersebut

(Connolly, 2002, p388). Normalisasi sering dieksekusi melalui beberapa tahap.

Tahap-tahap normalisasi (Connolly, 2002, p387), yaitu:

1. First Normal Form (1NF)

20

 

First normal form (1NF), merupakan suatu hubungan di mana

intersection dari setiap baris dan kolomnya hanya memiliki satu nilai.

Untuk mengubah tabel yang belum normal ke dalam 1NF, maka kelompok

yang berulang dalam tabel diidentifikasi dan dibuang. Kelompok yang

berulang merupakan atribut atau sekelompok atribut yang memiliki

multiple values untuk suatu kejadian tunggal. Ada dua pendekatan untuk

membuat kelompok yang berulang (Connolly, 2002, p388), yaitu:

a. Menghilangkan kelompok yang berulang dengan memasukkan data

yang sesuai ke dalam kolom yang kosong dari baris yang berisi data

berulang. Dengan pendekatan ini, redundansi dapat diketahui yang

kemudian dihilangkan selama proses normalisasi.

b. Menghilangkan kelompok yang berulang dengan meletakkan data yang

berulang, bersamaan dengan kopian dari atribut asli, secara terpisah.

Primary key diidentifikasi untuk hubungan yang baru.

2. Second Normal Form (2NF)

Second normal form (2NF), merupakan relasi dari first normal form

dan setiap non-primary-key memiki ketergantungan fungsional secara

penuh terhadap primary key. Second normal form diaplikasikan ke dalam

suatu hubungan dengan composite key, di mana hubungan tersebut dengan

primary key-nya digabungkan dari dua atau lebih atribut.

Normalisasi dari 1NF menjadi 2NF meliputi penghapusan

ketergantungan parsial. Jika terdapat ketergantungan parsial, maka atribut

yang memiliki ketergantungan parsial tersebut dihilangkan dengan

21

 

menempatkannya ke dalam suatu relasi yang baru bersamaan dengan

salinan determinannya.

3. Third Normal Form (3NF)

Third normal form (3NF), relasi dari 1NF dan 2NF, di mana tidak

ada atribut non-primary-key yang memiliki ketergantungan transitif

terhadap primary key.

Normalisasi dari 2NF menjadi 3NF meliputi penghapusan

ketergantungan transitif. Jika terdapat ketergantungan transitif, maka

atribut yang memiliki ketergantungan transitif dihilangkan dengan

meletakkannya ke relasi baru beserta dengan determinannya.

4. Boyce-Codd Normal Form (BCNF)

Suatu relasi dikatakan BCNF jika dan hanya jika setiap determinannya

adalah candidate key. Yang dilakukan agar relasi menjadi BCNF adalah

menghilangkan anomali dari ketergantungan fungsional.

5. Fourth Normal Form (4NF)

Fourth normal form (4NF), merupakan suatu relasi dari bentuk

normal Boyce-Codd dan tidak berisi ketergantungan multi-valued

nontrivial. 4NF lebih kuat daripada BCNF karena memberikan relasi yang

berisi ketergantungan multi-valued dan tidak ada data redundan.

Normalisasi BCNF menjadi 4NF adalah dengan cara menghilangkan

MVD (multi-valued dependencies) dengan cara menempatkan atribut ke

dalam relasi baru beserta dengan determinannya.

6. Fifth Normal Form (5NF)

22

 

Fifth normal form (5NF), merupakan relasi yang tidak memiliki join

dependency.

2.1.8 Fact Finding Technique

Pengembang database menggunakan beberapa teknik fact finding

selama perancangan database. Ada lima teknik fact finding yang biasanya

digunakan (Connolly, 2002, p305), yaitu:

1. Examining Documentation

Pemeriksaan dokumentasi dapat sangat berguna ketika pengetahuan

yang mendalam tentang kebutuhan database ingin diperoleh. Dokumentasi

juga menyediakan informasi pada bagian perusahaan yang terkait dengan

permasalahan. Dengan memeriksa dokumen-dokumen, forms, laporan, dan

file-file yang berhubungan dengan sistem saat ini, dapat dengan cepat

memperoleh pengertian tentang sistem tersebut.

2. Interviewing

Interview dapat digunakan untuk mengumpulkan informasi dari

individu-individu secara langsung (face to face). Ada beberapa tujuan

menggunakan teknik interview, yaitu mengetahui fakta-fakta,

memverifikasi fakta-fakta, klarifikasi fakta-fakta, membangkitkan

antusiasme, mendapatkan pengguna akhir yang terlibat, mengidentifikasi

kebutuhan, dan mengumpulkan ide-ide dan pendapat.

Ada dua tipe dari interview (Connolly, 2002, p306), yaitu

unstructured interview dan structured interview. Unstructured interview,

23

 

dilakukan hanya dengan tujuan umum dan dengan pertanyaan-pertanyaan

yang belum disusun. Pewawancara mengandalkan yang diwawancarai

untuk menyediakan suatu kerangka kerja dan arah interview. Jenis

interview ini sering kehilangan fokus. Structured interview, pewawancara

memiliki set pertanyaan yang spesifik yang akan ditanyakan kepada yang

diwawancarai. Bergantung dari jawaban yang diwawancarai, pewawancara

akan memberikan pertanyaan tambahan untuk memperoleh klarifikasi dan

perluasan informasi.

Adapun keuntungan dari interview (Connoly, 2002, p306), yaitu:

a. Memungkinkan orang yang diwawancara menjawab secara bebas dan

terbuka terhadap pertanyaan-pertanyaan.

b. Memungkinkan orang yang diwawancara merasa menjadi bagian dari

proyek tersebut.

c. Memungkinkan pewawancara ikut tertarik terhadap ulasan yang dibuat

oleh orang yang diwawancara.

d. Memungkinkan pewawancara menyesuaikan pertanyaan selama

wawancara berlangsung.

e. Memungkinkan pewawancara mengamati bahasa tubuh orang yang

diwawancara.

3. Observing the Enterprise in Operation

Observasi merupakan salah satu teknik fact finding yang paling

efektif untuk memahami sistem. Dengan menggunakan teknik ini,

memungkinkan untuk melihat orang beraktivitas dan dapat mempelajari

24

 

sistem tersebut secara langsung. Khususnya, teknik ini berguna ketika

validitas pengumpulan data hingga kompleksitas pada aspek-aspek tertentu

dari sistem.

Adapun keuntungan dari observasi (Connoly, 2002, p307), yaitu:

a. Memungkinkan validitas fakta dan data yang diperiksa.

b. Pengamat dapat melihat dengan tepat apa yang sedang dilakukan.

c. Pengamat juga dapat memperoleh data yang menggambarkan

lingkungan fisik dari tugas.

d. Relatif murah.

e. Pengamat dapat mengukur secara langsung.

4. Research

Salah satu teknik fact finding yang berguna adalah penelitian

terhadap aplikasi dan masalah. Buku referensi dan internet menyediakan

informasi bagaimana orang lain menyelesaikan masalah yang serupa. Ini

merupakan sumber informasi yang cukup baik.

Adapun keuntungan dari penelitian (Connolly, 2002, p308), yaitu:

a. Dapat menghemat waktu apabila solusi sudah ada.

b. Peneliti dapat melihat bagaimana yang lainnya menyelesaikan masalah

yang serupa atau bertemu dengan kebutuhan-kebutuhan yang serupa.

c. Peneliti terus mengikuti perkembangan saat ini.

5. Questionnaires

Teknik fact finding lainnya adalah melakukan survey melalui

kuisioner. Kuisioner memungkinkan fakta-fakta dikumpulkan dari banyak

25

 

orang dan mengontrol jawaban mereka. Ada dua tipe pertanyaan yang

dapat digunakan dalam kuisioner (Connolly, 2002, p308), yaitu free-format

dan fixed-format. Free-format question memberikan kebebasan kepada

responden dalam menjawab. Masalah dari free-format question adalah

jawaban dari responden meningkatkan kesulitan dalam tabulasi data dan

terkadang jawaban yang diberikan tidak cocok dengan pertanyaannya.

Fixed-format question mengharuskan jawaban yang spesifik dari setiap

orang. Hal ini membuat tabulasi menjadi lebih mudah. Dengan kata lain,

responden tidak dapat menyediakan informasi tambahan.

Adapun keuntungan dari kuisioner (Connolly, 2002, p308), yaitu:

a. Orang-orang dapat menyelesaikan dan mengembalikan kuisioner dengan

mudah.

b. Relatif murah dalam mengumpulkan data dari banyak orang.

c. Orang-orang akan lebih suka menyediakan fakta nyata seperti jawaban

yang dirahasiakan.

d. Jawaban dapat ditabulasi dan dianalisis dengan cepat.

2.1.9 Metodologi Perancangan Database

Sistem database merupakan komponen dasar dari sistem informasi yang

luas dalam organisasi yang besar, database application lifecycle berhubungan

secara inheren terhadap sistem informasi. Adapun tahap-tahap dari database

application lifecycle (Connolly, 2002, p273), yaitu:

1. Database Planning

26

 

Merencanakan bagaimana tahap-tahap dalam lifecycle dapat

direalisasi lebih efisien dan efektif. Langkah pertama dalam database

planning adalah mendefinisikan secara jelas pernyataan aplikasi.

Perencanaan database juga harus meliputi pengembangan dari standar yang

mengendalikan bagaimana data dikumpulkan, bagaimana format

ditentukan, dokumentasi yang dibutuhkan, dan bagaimana implementasi

diproses.

2. System Definition

Mendeskripsikan lingkup dan batas dari aplikasi database dan user

views utama. User view mengidentifikasikan apa yang diperlukan oleh

suatu aplikasi database dalam hal data yang ada dan transaksi yang

dilakukan terhadap data tersebut.

3. Requirements Collection and Analysis

Proses mengumpulkan dan menganalisis informasi tentang bagian

dari organisasi yang didukung oleh aplikasi database, dan menggunakan

informasi tersebut untuk mengidentifikasi kebutuhan dari pengguna sistem

yang baru. Dalam mengumpulkan informasi dapat digunakan teknik fact

finding.

4. Database Design

Proses membuat desain untuk database yang akan mendukung

operasi dan tujuan perusahaan. Desain database dibagi menjadi tiga fase

(Connolly, 2002, p281-282), yaitu:

a. Conceptual database design

27

 

Desain database konseptual, merupakan proses membangun suatu

model informasi yang digunakan untuk perusahaan. Model data

dibangun dengan menggunakan informasi yang didokumentasikan dari

spesifikasi kebutuhan pengguna.

b. Logical database design

Desain database logika, merupakan proses membangun model dari

informasi yang digunakan dalam perusahaan sebagai dasar dari model

data tertentu, tetapi tidak bergantung terhadap DBMS.

c. Physical database design

Desain database fisik, merupakan proses untuk menghasilkan

gambaran dari implementasi database ke secondary storage,

mendeskripsikan relasi dasar, organisasi file, dan index yang digunakan

untuk memperoleh akses yang efisien terhadap data dan integritas serta

batasan keamanan.

5. DBMS Selection

Memilih DBMS yang sesuai untuk mendukung aplikasi database.

Dalam memilih DBMS yang baru, ada kesempatan untuk menjamin bahwa

proses seleksi telah direncanakan dengan baik, dan sistem memberikan

manfaat yang nyata kepada perusahaan.

6. Application Design

Mendesain antarmuka pengguna dan program aplikasi yang

menggunakan dan mengolah database. Dalam tahap ini, ada dua aspek

yang dipertimbangkan yaitu transaction design dan user interface design.

28

 

7. Prototyping

Membangun working model dari aplikasi database, yang mengijinkan

desainer atau pengguna untuk menggambarkan dan mengevaluasi

bagaimana sistem akhir akan terlihat dan berfungsi. Ada dua strategi

prototype yaitu requirements prototyping dan evolutionary prototyping.

8. Implementation

Realisasi fisik dari database dan desain aplikasi. Implementasi

database dapat menggunakan Data Definition Language (DDL) dari DBMS

yang telah dipilih atau graphical user interface (GUI), yang menyediakan

fungsi yang sama.

9. Data Conversion and Loading

Memindahkan beberapa data yang ada ke dalam database baru dan

mengkonversi beberapa aplikasi yang ada untuk dijalankan pada database

yang baru. Tahap ini hanya dibutuhkan ketika sistem database yang baru

menggantikan sistem yang lama.

10. Testing

Proses menjalankan program aplikasi dengan tujuan untuk

menemukan error. Jika proses testing telah selesai, maka sistem aplikasi

siap untuk disahkan dan diserahkan kepada pengguna.

11. Operational Maintenance

Setelah aplikasi database telah sepenuhnya diimplementasikan,

selanjutnya sistem dipantau dan dipelihara secara berkelanjutan. Jika

kinerja turun di bawah level, maka reorganisasi database diperlukan. Bila

29

 

perlu, kebutuhan baru dimasukkan ke dalam aplikasi database melalui

tahap sebelumnya dari database lifecycle.

2.1.10 Metodologi Desain Web Database

Perancangan sistem web database, dibandingkan dengan sistem database

konvensional, menambahkan dua pertimbangan (Eaglestone, 2001, p262):

1. Perancangan desain web, berhubungan dengan:

a. Representasi web data, yaitu penyajian data sebagai halaman web, bisa

mengambil dari database atau dimasukkan oleh pengguna.

b. Asosiasi web data, yaitu perancangan link untuk navigasi dalam dan

antar halaman web.

c. Desain tampilan web, yaitu perancangan fitur-fitur halaman web,

termasuk penggunaan grafis, animasi, dan lain-lain.

2. Perancangan konektivitas antara halaman web dan database, berhubungan

dengan:

a. Web database logical mapping, yaitu definisi pemetaan antara data yang

ditampilkan dalam halaman web dan data yang disimpan dalam

database.

b. Web database physical mapping, yaitu implementasi dari mekanisme

data dilewatkan antara halaman web dan database.

Metode yang digunakan secara spesifik membahas perancangan web

database, bukan ruang lingkup perancangan aplikasi web yang lebih luas dan

30

 

kompleks. Oleh sebab itu, terdapat batasan-batasan dari metode yang

digunakan, yaitu (Eaglestone, 2001, p263):

1. Yang diperhatikan hanya isu perancangan yang berhubungan secara

langsung dengan data dalam database dan yang ditampilkan dalam halaman

web. Isu lainnya seperti layout dan fitur-fitur dalam halaman web berada di

luar jangkauan metode perancangan.

2. Yang diperhatikan hanya halaman web yang secara eksplisit dirancang

untuk aplikasi. Hubungan dengan halaman lain di luar sistem tidak

dimodelkan.

Sama dengan database, struktur dari web database dapat digambarkan

dalam abstraksi yang tingkatannya berbeda, sesuai dengan model konseptual,

logika, dan fisik dari sistem database konvensional (Eaglestone, 2001, p263):

1. Model web data konseptual harus menunjukkan struktur informasi yang

diwakili dalam halaman web.

2. Model web data logika harus menunjukkan bagaimana struktur konseptual

secara nyata diwakili dalam halaman web.

3. Model web data fisik harus menunjukkan bagaimana model logika dari

halaman web diimplementasikan.

Sehingga perancangan web database dapat digambarkan sebagai berikut

(Eaglestone, 2001, p264):

31

 

 

Gambar 2. 10 Perancangan Web Database

32

 

Tahapan perancangan web database terdiri dari:

1. Analisis data

Tujuan analisis data adalah untuk menentukan struktur alami dari

data yang akan disimpan dalam database. Analisis data atau pemodelan

data, memerlukan deskripsi kebutuhan organisasi dan sistem sebagai input-

nya, dan menghasilkan model konseptual dari bagian database yang

menyajikan informasi. Dalam kasus di mana database dirancang untuk

mendukung aplikasi web secara spesifik, maka analisis hanya didasarkan

pada deskripsi dari aplikasi tersebut.

Metode analisis data secara umum terbagi atas dua kategori, yaitu

top-down dan bottom-up (Eaglestone, 2001, p271).

A. Analisis Data Bottom-Up

Analisis data dengan pendekatan bottom-up dilakukan dari atribut

menuju ke entity dan relationship yang diwakili dalam database. Metode

ini terkadang disebut agregasi data atau sintesis.

Analisis data bottom-up didasarkan pada gagasan bahwa entity

bersifat implisit dari suatu data. Dengan menganalisis semua atribut

yang terhubung ke deskripsi organisasi, maka akan mungkin

mengidentifikasi relationship di antara entity. Proses analisis data

bottom-up terdiri dari:

1. Identifikasi Data Item

Data item diidentifikasi dari gambaran organisasi yang akan

disajikan oleh database dan kebutuhan sistem. Misalnya identifikasi

33

 

dapat dilakukan pada field-field dalam formulir penyimpanan data

atau dari isi berkas dan catatan organisasi lainnya.

2. Identifikasi Relationship antar Data Item

Perancang harus mengidentifikasi:

a. Atribut-atribut yang berhubungan dengan atribut lainnya;

b. Jenis dari relationship yang ada, bisa one-to-many, one-to-one,

many-to-many, atau zero-or-one-to-many.

Relationship yang teridentifikasi kemudian menjadi dasar untuk

menarik kesimpulan atas suatu entity. Langkah selanjutnya adalah

menentukan kardinalitas dari setiap relationship.

3. Identifikasi Entity

Entity disimpulkan dari atribut dan relationship yang

teridentifikasi. Macam-macam relationship yang menunjukkan

keberadaan suatu entity, yaitu:

a. Many-to-one relationship – nilai dari atribut “many” menentukan

nilai dari atribut “one”, dan umumnya nilai dari atribut “many”

diasumsikan sebagai nama dari entity dan nilai “one”

menunjukkan fakta-fakta entity tersebut.

b. Zero-or-one-to-many relationship – nilai dari atribut “many”

menentukan nilai dari atribut “zero-or-one”, meskipun beberapa

nilai dari atribut “many” mungkin tidak berhubungan dengan nilai

atribut “zero-or-one” mana pun. Kemudian nilai atribut “many”

diasumsikan sebagai nama entity, dan nilai atribut “zero-or-one”

34

 

adalah nama entity lainnya yang terkadang berhubungan

dengannya.

c. Many-to-many relationship – jenis relationship ini

mengidentifikasi tiga entity. Nilai dari dua set atribut “many”

dalam relationship masing-masing diidentifikasi sebagai satu

entity, dan relationship-nya itu sendiri dianggap sebagai entity

asosiasi. Many-to-many relationship digantikan oleh dua one-to-

many relationship.

d. One-to-one relationship – yang dapat diartikan sebagai satu atau

dua entity. Dua atribut dalam relationship dapat secara sederhana

menjadi pengidentifikasi alternatif untuk suatu entity tunggal, atau

dapat juga mengidentifikasi dua entity berbeda.

4. Penggabungan Model Data

Kumpulan dari model data yang dihasilkan kemudian harus

digabungkan untuk membentuk model data tunggal, yang mana akan

menjadi dasar dari database yang dirancang.

B. Analisis Data Top-Down

Analisis data top-down atau entity-attribute-relationship

dikerjakan dari dunia nyata, ke entity yang penting dalam dunia nyata,

ke relationship di antara obyek, lalu ke sifat-sifat dari entity tersebut.

Proses-proses yang dijalankan yaitu:

1. Identifikasi Entity

35

 

Entity adalah sesuatu yang memiliki keberadaan independen

dan diharapkan dapat mewakili informasi. Keberadaan entity dapat

disimpulkan melalui penalaran tentang organisasi, dan khususnya

tentang kegiatan yang terjadi dan data yang dicatat di dalamnya.

Entity biasanya ditunjukkan dengan kata benda atau frasa benda.

2. Identifikasi Relationship antar Entity

Langkah selanjutnya adalah menentukan bagaimana sepasang

entity berhubungan. Relationship mewakili jenis relasi yang dapat

ada di antara fenomena dunia nyata yang disajikan dalam entity.

Relationship tersirat dari frasa yang berjenis “memiliki ...” atau

“memerlukan sejumlah ...” atau “bagian dari ...”. Frasa jenis ini

menunjukkan satu entity yang mendeskripsikan yang lainnya. Tujuan

dari analisis ini adalah untuk mengidentifikasi hanya relationship

yang berhubungan langsung di antara entity. Jenis relationship

ditentukan kemudian.

3. Identifikasi Atribut-Atribut Entity

Langkah ketiga adalah mengidentifikasi jenis-jenis fakta

tentang entity yang harus disajikan dalam database. Atribut ditandai

di mana kata benda atau klausa benda mengidentifikasi sesuatu yang

merupakan sifat, kualitas, atau karakteristik dari suatu entity.

4. Penggabungan Model yang Terpisah

Sejumlah deskripsi mungkin harus dianalisis dan model

konseptual harus digabungkan.

36

 

Analisis top-down mengandalkan lebih banyak pertimbangan

analis. Hal ini biasanya akan menghasilkan model konseptual yang lebih

sederhana, karena analis akan menyaring entity, relationship, dan atribut

yang tidak berhubungan atau tidak berguna dalam hubungannya dengan

masalah yang ada.

2. Conceptual database design

dalam metodologi desain database (Connolly, 2002, p420-516), meliputi:

Langkah 1 Membangun model data konseptual lokal untuk setiap view

Selama analisis, sejumlah user views diidentifikasi dan

beberapa user view dikombinasikan dengan user view kolektif yang

kemudian diberikan nama yang cocok. Setiap model data konseptual

lokal terdiri dari:

1. Entity types

2. Relationship types

3. Attribute dan attribute domains

4. Primary key dan alternate key

5. Integrity constraints

Adapun beberapa langkah yang dapat dilakukan untuk

membangun model data konseptual lokal, di antaranya:

Langkah 1.1 Mengidentifikasi tipe-tipe entity

Salah satu metode untuk mengidentifikasi entity adalah

memeriksa spesifikasi kebutuhan dari pengguna. Dari

spesifikasi ini, dapat diidentifikasi kata benda atau kumpulan

37

 

kata benda yang dapat dikelompokkan menjadi entity yang

kemudian diberikan nama yang cocok sesuai dengan spesifikasi

tersebut.

Langkah 1.2 Mengidentifikasi tipe-tipe relationship

Setelah mengidentifikasi entity-nya, maka langkah

selanjutnya adalah mengidentifikasi seluruh relationship yang

ada di antara entity-entity tersebut. Untuk mengidentifikas i

relationship dapat menggunakan tata bahasa (grammar) dari

spesifikasi kebutuhan pengguna.

Langkah 1.3 Mengidentifikasi dan menghubungkan atribut-atribut

dengan entity dan relationship

Langkah selanjutnya adalah mengidentifikasi atribut

melalui kata benda yang menjadi properti, berkualitas,

pengidentifikasi, dan karakteristik dari setiap entity atau

relationship.

Langkah 1.4 Menentukan domain dari atribut

Langkah selanjutnya adalah menentukan domain dari

seluruh atribut. Domain adalah kumpulan nilai yang diperoleh

dari satu atau beberapa atribut yang menggambarkan nilainya.

Misalnya, menentukan ukuran dan format dari setiap atribut.

Langkah 1.5 Menentukan candidate key dan primary key

Langkah ini berfokus dengan mengidentifikasi candidate

keys untuk setiap entity dan kemudian dipilih satu untuk

38

 

menjadi primary key. Candidate key adalah suatu minimal set

dari atribut-atribut suatu entity yang secara unik

mengidentifikasi setiap peristiwa dari suatu entity. Pemilihan

primary key dari sejumlah candidate key dapat menggunakan

beberapa syarat di bawah ini:

1. Candicate key dengan kumpulan atribut yang paling sedikit.

2. Candicate key yang paling tidak mungkin memiliki nilai

yang berubah.

3. Candicate key dengan karakter yang paling sedikit untuk

tipe data text.

4. Candicate key dengan nilai maksimum yang terkecil untuk

tipe data numeric.

5. Candicate key yang paling mudah digunakan dari user view.

Langkah 1.6 Mempertimbangkan penggunaan konsep model

enhanced (opsional)

Tahap ini merupakan tahap opsional. Ada empat

pendekatan yang dapat digunakan, yaitu:

a. Spesialisasi

Spesialisasi adalah proses memaksimalkan perbedaan

di antara entity-entity dengan cara mengidentifikasi

karakteristik khusus. Spesialisasi menggunakan pendekatan

top-down untuk mendefinisikan superclass dan subclass

yang saling berelasi. Dimulai dengan mengidentifikasi suatu

39

 

set subclass dari entity, kemudian menghubungkan atribut-

atribut yang spesifik untuk setiap subclass, dan juga

mengidentifikasi hubungan di antara tiap subclass.

b. Generalisasi

Generalisasi merupakan proses meminimalisasi

perbedaan-perbedaan di antara entity dengan

mengidentifikasi karakteristik umumnya. Proses generalisasi

menggunakan pendekatan bottom-up, yang hasilnya dari

identifikasi superclass umum dari entity asli.

c. Komposisi

Komposisi merepresentasikan satu asosiasi di antara

entity-entity di mana ada kepemilikan yang kuat di antara

‘seluruh’ dan ‘bagian’ dari entity-entity.

d. Agregasi

Agregasi merepresentasikan hubungan ‘mempunyai’

atau ‘bagian dari’ di antara entity-entity.

Langkah 1.7 Memeriksa model untuk redundansi

Pada tahap ini, model data konseptual lokal diuji dengan

suatu tujuan khusus dengan mengidentifikasi apakah ada data

yang berulang atau tidak. Jika terdapat data yang berulang,

maka harus dihilangkan. Ada dua langkah dalam tahap ini,

yaitu:

1. Menguji hubungan one-to-one (1:1)

40

 

Ada dua entity yang diidentifikasi yang

merepresentasikan obyek yang sama dalam suatu

perusahaan. Dalam hal ini, ada dua entity yang harus

digabungkan. Jika primary key berbeda maka dipilih satu

untuk menjadi primary key dan yang lain menjadi alternate

key.

2. Menghilangkan hubungan yang redundan

Hubungan yang redundan terjadi jika informasi yang

sama dapat diperoleh melalui relationship yang lain. Oleh

karena itu, penting untuk menguji setiap arti dari

relationship di antara entity-entity yang memiliki nilai

redundansi.

Langkah 1.8 Validasi model konseptual lokal terhadap transaksi

pengguna

Tahap ini dilakukan untuk mengecek apakah model data

mendukung transaksi yang dibutuhkan oleh pengguna atau

tidak. Jika model data tidak mendukung transaksi tersebut,

maka ada entity, relationship, atau atribut yang harus

dihilangkan dari model data tersebut. Ada dua pendekatan yang

dapat diuji untuk menjamin bahwa model data konseptual

mendukung transaksi yang dibutuhkan, yaitu:

1. Mendeskripsikan transaksi-transaksi.

2. Menggunakan jalur transaksi.

41

 

Langkah 1.9 Memeriksa model data konseptual lokal dengan

pengguna

Model data konseptual lokal ditinjau kembali dengan

pengguna untuk menjamin bahwa model data tersebut benar-

benar merepresentasikan view.

3. Analisis web data

Analisis web data adalah proses di mana suatu model konseptual

dihasilkan. Proses analisis web data membutuhkan input berupa deskripsi

kebutuhan organisasi dan sistem serta model database konseptual. Tujuan

pemodelan informasi halaman web adalah sebagai berikut (Eaglestone,

2001, p288):

a. Membentuk pemetaan antara informasi yang disajikan pada halaman

web dan yang disimpan dalam database. Juga untuk mengomunikasikan

dan menjelaskan desain konseptual kepada pengguna sistem di masa

akan datang dan dengan demikian memeriksa keabsahan perancangan.

b. Memeriksa kebenaran database sehubungan dengan penggunaannya

dalam aplikasi web database. Analisis ini dapat membantu untuk

mengidentifikasi informasi yang hilang yang dibutuhkan dari database.

c. Memberikan dasar untuk memverifikasi kebenaran desain rinci dan

implementasi halaman web.

d. Dengan bekerja dari tingkat konseptual ke implementasi fisik, dapat

menghindari kompleksitas teknis.

42

 

Proses kemudian dijalankan dalam dua tahapan, seperti terlihat pada

gambar di bawah:

 

Gambar 2. 11 Analisis Web Data

1. Ekstraksi Web Data

Tujuan dari dua tahapan pertama analisis web data adalah untuk

menentukan bagian model database konseptual yang relevan dengan

aplikasi web data. Tugas ekstraksi web data adalah mengidentifikasi

konsep yang berhubungan dengan deskripsi aplikasi web dan

menentukan apakah konsep tersebut sudah dimodelkan dalam model

database konseptual.

Untuk setiap calon entity, atribut, atau relationship, dicari

abstraksi yang berhubungan dalam model database konseptual. Konsep

yang cocok kemudian ditambahkan ke model konseptual untuk aplikasi

web database.

2. Analisis Konektivitas Web Database

43

 

Langkah ini untuk mengidentifikasi jalur akses ke dalam sistem

dan jalur navigasi antar dan di dalam halaman web. Berdasarkan tujuan

tersebut, dibuat modifikasi berikut pada model halaman web konseptual

(Eaglestone, 2001, p293):

a. Di mana ada jalur akses yang tidak berhubungan dengan konsep

dalam model ER untuk halaman web, tambahkan ia sebagai concept

box.

b. Di mana ada jalur navigasi yang teridentifikasi, model ER dianalisis

untuk melihat apakah ia berhubungan dengan suatu relationship.

Karenanya, kepala panah ditambahkan ke garis relationship dalam

model ER, untuk menunjukkan arah navigasi.

A. Pemodelan Halaman Web Konseptual

Model data konseptual yang akan disajikan dalam halaman web

didapat dari analisis web data. Input untuk proses ini adalah deskripsi

kebutuhan organisasi dan sistem, bersama dengan model database

konseptual.

Perluasan Pemodelan ER untuk Pemodelan Web Data

Halaman web memainkan peranan yang sama dengan view atau

model eksternal. Artinya, ia memisahkan bagian database yang

relevan dengan aplikasi dan menyembunyikan sisanya. Seperti view,

halaman web untuk aplikasi mewakili entity-entity, atribut-atribut,

dan relationship sebagai data.

44

 

Ada dua aspek halaman web yang memerlukan perluasan

dalam model ER (Eaglestone, 2001, p285):

1. Hypermedia link – hypermedia menyediakan jalur navigasi antar

entity yang berhubungan. Dapat digambarkan dalam diagram ER

sebagai relationship. Namun, garis relationship harus berupa

tanda panah, untuk menunjukkan arah dari setiap link.

2. Konsep spesifik aplikasi web – halaman web sendiri mewakili

konsep yang penting bagi penggunanya. Konsep tersebut biasanya

akan berhubungan dengan entity-entity, relationship, atau atribut

dalam model database konseptual. Meskipun demikian, pada suatu

waktu dapat saja tidak berhubungan. Dalam kasus tersebut, konsep

yang tidak berhubungan dengan abstraksi dalam model database

konseptual tetap harus digambarkan dalam model konseptual

untuk halaman web, yang diwakili dalam bentuk oval yang disebut

concept boxes untuk mewakili entry point. Entry point menuju

sistem disediakan oleh halaman beranda.

4. Logical database design

Logical database design merupakan proses konstruksi sebuah model

dari informasi yang digunakan dalam suatu perusahaan berdasarkan suatu

model data, tetapi tidak bergantung pada suatu DBMS khusus. Ada dua

langkah dalam tahap desain logika ini, yaitu:

Langkah 2 Membangun dan validasi model data logika lokal untuk setiap

view

45

 

Pada tahap ini, setiap model data konseptual lokal dipetakan

menjadi model data logika lokal yang terdiri dari diagram ER, skema

relasional, dan mendukung dokumentasi. Ada enam langkah yang

dilakukan pada tahap ini, yaitu:

Langkah 2.1 Menghilangkan fitur-fitur yang tidak sesuai dengan

model relasional (opsional)

Pada tahap ini, dilakukan transformasi beberapa struktur

ke dalam bentuk yang ditangani oleh sistem. Tujuan dari tahap

ini adalah:

1. Menghilangkan hubungan binary many-to-many (*:*).

2. Menghilangkan hubungan rekursif many-to-many (*:*).

3. Menghilangkan hubungan yang kompleks.

4. Menghilangkan atribut multi-value.

Langkah 2.2 Menurunkan relasi untuk model data logika lokal

Pada tahap ini, relasi diturunkan untuk model data logika

lokal untuk merepresentasikan entity-entity, relationship, dan

attribute yang didefinisikan dalam view. Pada awalnya, dengan

menggunakan Database Definition Language (DDL) nama

relasi dispesifikasikan berdasarkan atribut-atribut sederhana

yang ditulis dalam tanda kurung. Kemudian mengidentifikas i

primary key dan beberapa alternate key dan foreign key dari

relasi tersebut. Relationship yang dimiliki oleh satu entity

46

 

dengan entity lainnya direpresentasikan dengan mekanisme

primary key / foreign key.

Langkah 2.3 Validasi relasi menggunakan normalisasi

Tahap ini dilakukan untuk menguji setiap

pengelompokkan atribut pada setiap relasi dengan

menggunakan tahapan-tahapan normalisasi yaitu 1NF, 2NF,

3NF, dan BCNF. Sasaran dari langkah ini adalah menjamin

setiap relasi yang diturunkan paling tidak berada dalam bentuk

BCNF. Jika tidak dalam bentuk BCNF, maka model data harus

direstrukturisasi dan model data tersebut harus

merepresentasikan perusahaan.

Langkah 2.4 Validasi relasi terhadap transaksi pengguna

Tujuan dari tahap ini adalah untuk menjamin bahwa

model data tersebut mendukung transaksi yang diperlukan di

view. Pada tahap ini, dilakukan pengecekan relasi yang dibuat

pada langkah sebelumnya mendukung transaksi-transaksi yang

diperlukan, dengan demikian dipastikan tidak ada error yang

ditemukan selama membuat relasi. Operasi ini dilakukan

dengan menggunakan primary key / foreign key yang terhubung

dalam relasi, diagram ER, dan kamus data.

Langkah 2.5 Mendefinisikan integrity constraints

47

 

Integrity constraints adalah batasan yang digunakan

untuk melindungi database menjadi tidak konsisten. Ada lima

tipe integrity constraints, yaitu:

a. Required data, merupakan batasan keberadaan data di mana

beberapa atribut harus selalu berisi nilai yang benar. Dalam

hal ini, atribut tersebut tidak boleh bernilai null.

b. Attribute domain constraints, merupakan batasan yang

menentukan bahwa setiap atribut memiliki domain, yaitu

suatu kumpulan nilai yang benar (legal).

c. Entity integrity, merupakan batasan yang tidak

memperbolehkan primary key bernilai null.

d. Referential integrity, merupakan batasan yang berarti jika

foreign key memiliki nilai, maka nilai tersebut harus

menunjuk ke tuple yang ada dalam relasi parent.

Pada umumnya, ada dua hubungan child dalam suatu

relationship, yaitu:

1. Mandatory, berarti bahwa tidak ada atribut yang boleh

bernilai null.

2. Optional, berarti bahwa ada atribut yang boleh bernilai

null.

e. Enterprise constraints, merupakan batasan-batasan yang

diberikan oleh perusahaan yang menggambarkan dunia

nyata, biasanya disebut dengan aturan bisnis.

48

 

Langkah 2.6 Memeriksa model data logika lokal dengan pengguna

Model data logika lokal untuk view harus dilengkapi dan

didokumentasikan secara keseluruhan. Untuk menyelesaikan

tahap ini, maka model data logika lokal ditinjau kembali dan

mendukung dokumentasi terhadap pengguna. Apabila hanya

memiliki satu view, maka dapat langsung membuat desain

database fisik. Tetapi jika memiliki banyak view, maka langkah

selanjutnya adalah membangun model data logika global.

Langkah 3 Membangun dan validasi model data logika global

Tahap ini dilakukan untuk menggabungkan model-model data

logika lokal individual ke dalam satu model data logika global yang

merepresentasikan perusahaan. Langkah-langkah yang perlu

dilakukan dalam membangun model data logika global adalah:

Langkah 3.1 Menggabungkan model data logika lokal ke dalam

model global

Ada 11 langkah yang harus dilakukan untuk

menggabungkan model data logika lokal menjadi model data

logika global, yaitu:

a) Meninjau kembali nama dan isi dari entity dan candidate key

Pemeriksaan kembali nama dan isi dari entity untuk

mencegah dua hal, yaitu homonyms atau synonyms.

Homonyms adalah keadaan ketika entity memiliki nama

yang sama tetapi pada kenyataan fungsinya berbeda.

49

 

Synonyms adalah keadaan ketika entity fungsinya sama

tetapi memiliki nama yang berbeda. Hal yang harus

dilakukan adalah membandingkan data dari setiap entity

secara khusus, dapat menggunakan candidate key untuk

mengidentifikasi masalah keekuivalenan entity.

b) Meninjau kembali nama dan isi dari relationship / foreign

key

Langkah yang dilakukan sama dengan ketika

memeriksa kembali nama dan isi dari entity, hanya saja pada

tahap ini yang diperiksa kembali adalah nama dan isi dari

relationship / foreign key. Entity atau relationship yang

memiliki nama yang sama harus merepresentasikan konsep

dalam dunia nyata dan nama tersebut membedakan setiap

view dengan konsep yang berbeda.

c) Menggabungkan entity-entity dari model data lokal

Ada tiga aktivitas yang dapat dilakukan dalam tahap

ini, yaitu:

1. Menggabungkan entity-entity yang memiliki nama yang

sama dengan primary key yang sama.

2. Menggabungkan entity-entity dengan nama yang sama

tetapi primary key yang berbeda.

3. Menggabungkan entity-entity dengan nama yang berbeda

menggunakan primary key yang sama atau berbeda.

50

 

d) Memasukkan entity-entity yang unik ke setiap model data

lokal

Tahap sebelumnya telah ditemukan entity-entity yang

memiliki nama atau isi yang sama. Maka dalam tahap ini,

seluruh sisa entity dimasukkan ke dalam model data logika

global tanpa mengalami perubahan.

e) Menggabungkan relationship / foreign key dari model data

lokal

Sebelum menggabungkan relationship / foreign key,

maka perlu memecahkan beberapa masalah dalam suatu

relationship, misalnya multiplicity. Ada dua aktivitas yang

dapat dilakukan dalam tahap ini, yaitu:

1. Menggabungkan relationship / foreign key dengan nama

yang sama dan tujuan yang sama.

2. Menggabungkan relationship / foreign key dengan nama

yang berbeda tetapi dengan tujuan yang sama.

f) Memasukkan relationship / foreign key ke setiap model data

lokal

Tahap sebelumnya telah ditemukan relationship /

foreign key yang memiliki nama atau isi yang sama. Maka

dalam tahap ini, seluruh sisa relationship / foreign key

dimasukkan ke dalam model data logika global tanpa

mengalami perubahan.

51

 

g) Memeriksa entity dan relationship / foreign key yang hilang

Jika model data perusahaan ada untuk perusahaan,

berarti entity dan relationship tidak muncul pada beberapa

model data lokal. Maka, atribut dari setiap entity diperiksa

dan relationship ke entity dalam model data lokal diperiksa.

h) Memberikan foreign key

Selama tahap ini berlangsung, entity-entity dan

relationship / foreign key digabungkan, primary key

berubah, dan relationship yang baru diidentifikasi. Maka

foreign key pada child diperiksa, apakah tetap benar dan

dibuat beberapa modifikasi.

i) Memeriksa integrity constraints

Integrity constraints untuk model data logika global

diuji agar tidak bertentangan dengan persyaratan semula

untuk setiap view. Jika relationship yang baru telah

diidentifikasi dan foreign key yang baru telah dibuat, maka

harus dijamin bahwa referential integrity constraints yang

sesuai ditentukan.

j) Menggambarkan diagram ER secara global

Diagram ER digambarkan di mana diagram tersebut

merepresentasikan seluruh model data logika lokal yang

telah digabungkan.

k) Mengubah dokumentasi

52

 

Mengubah dokumentasi dilakukan untuk

menggambarkan beberapa perubahan yang dibuat selama

pengembangan model data global.

Langkah 3.2 Validasi model data logika global

Pada tahap ini, dilakukan validasi terhadap model data

logika global yang telah dihasilkan dengan menggunakan

teknik normalisasi dan untuk menjamin model data global

mendukung transaksi yang dibutuhkan.

Langlah 3.3 Menguji perkembangan yang akan datang

Tahap ini dilakukan untuk menguji apakah model data

global yang telah dibuat memiliki kemampuan yang luas

dengan dampak yang minimal.

Langkah 3.4 Memeriksa model data logika global dengan pengguna

Model data logika global ini ditinjau kembali berdasarkan

pengguna. Tahap ini dilakukan untuk menjamin bahwa model

data logika global benar-benar merupakan representasi dari

perusahaan.

5. Perancangan web data logika

Proses ini menentukan struktur data dari halaman web. Proses

memerlukan model web konseptual sebagai input dan akan menentukan

skema untuk tiap-tiap halaman web.

A. Skema Halaman Web Logika

53

 

Isi data dari halaman web ditentukan sebagai skema halaman web

logika. Ini digunakan untuk menentukan struktur data yang ditampilkan

dan atau dimasukkan melalui halaman web. Secara spesifik harus dapat

menjelaskan hal-hal berikut (Eaglestone, 2001, p311):

1. Struktur dari halaman unik – beberapa halaman dalam aplikasi web

database memiliki struktur dan isi yang tetap saat ditampilkan.

2. Struktur umum untuk banyak halaman – kebanyakan halaman web

dari sistem web database secara dinamis dibangun dari data yang

diambil dari database untuk menjelaskan instansi atau entity yang

berbeda. Oleh sebab itu, ada kumpulan halaman dalam sistem web

database yang akan memiliki struktur yang sama tetapi dengan nilai

data berbeda.

3. Link – model halaman web logika harus mampu mewakili inter-page

link, karena akan menggambarkan asosiasi dan jalur navigasi antar

data yang diwakili dalam tiap-tiap halaman web.

4. Struktur data kompleks – halaman web dapat berisi field-field dengan

struktur bersarang dan juga daftar nilai.

Dalam metode perancangan web database, struktur halaman web

dijelaskan menggunakan skema. Akan ada satu skema untuk setiap

halaman yang unik, dan satu untuk menjelaskan setiap kumpulan

halaman dengan struktur yang sama. Notasi yang digunakan sama

seperti pada ODMG ODL (Object Definition Language) untuk

menentukan kelas dalam database obyek.

54

 

Skema halaman web menentukan field data (atau atribut) yang

ditampilkan di halaman web (Eaglestone, 2001, p312):

1. Struktur utama skema halaman web adalah sebagai berikut: Dimulai

dengan kata kunci, sebagai nama skema, diikuti daftar definisi field

dalam cabang-cabang.

2. Field data yang terstruktur secara kompleks ditentukan dengan

memasukkan definisi dari struktur bersarang dalam cabang-cabang.

3. Pengulangan data item diindikasikan oleh kata kunci “LIST_OF”.

4. Di samping jenis field biasa, seperti STRING, INTEGER, dan lain-

lain, juga ada field untuk link. Ia mewakili link dalam halaman web

dan karenanya meliputi anchor dan alamat (dinotasikan dengan

mendahului nama skema halaman dengan tanda bintang).

Penggambaran skema halaman web juga dapat disajikan dalam

grafis. Dalam diagram, kotak mewakili skema dan panah mewakili link.

Jika mengandung nilai yang kompleks, skema dapat secara grafis

ditampilkan dengan nested boxes. Outside box mewakili nilai

“LIST_OF”, dan inner box mewakili nilai individual dalam daftar

tersebut, tiap-tiapnya meliputi nilai anchor dan link ke halaman.

Akhirannya diwakili dengan tanda panah, di mana diagram yang

lengkap akan menunjuk ke kotak yang mewakili halaman web.

Skema halaman web didapat dari model web konseptual. Hal ini

dapat dilakukan dengan menggambar sketsa halaman web yang

mendukung aplikasi web database terlebih dulu, untuk mengidentifikasi

55

 

field data ditiap halaman web. Nama field yang digunakan di skema

harus sama dengan yang digunakan dalam skema database, sehingga

membentuk pemetaan pasti antara database dan tiap halaman web.

a. Concept boxes – khususnya diimplementasikan sebagai halaman.

b. Entity – atribut dari tiap entity harus digambarkan, khususnya yang

ada pada halaman yang sama atau pada halaman yang terhubung

secara langsung.

c. Relationship – relationship antar entity harus digambarkan dengan

memasukkan data untuk entity-entity yang berasosiasi pada halaman

yang sama atau dengan menghubungkan masing-masing halaman.

Validasi dari perancangan diuji dengan mencatat bagaimana

halaman akan digunakan, dalam suatu skenario yang diberikan. Sketsa

menggambarkan data yang akan disajikan dalam halaman web, bukan

rancangan rinci bagaimana mereka akan disajikan. Skema ditentukan

untuk tiap-tiap sketsa halaman web. Skema halaman web bersama

dengan skema database membentuk rancangan sistem web database

logika.

6. Phisycal database design

Physical database design adalah proses yang menghasilkan deskripsi

dari implementasi database pada secondary storage, mendeskripsikan

relasi-relasi dasar, organisasi file, dan index yang digunakan untuk

memperoleh akses yang efisien terhadap data dan beberapa hubungan

56

 

integrity constraints dan batasan keamanan. Langkah-langkah dalam

phisycal database design adalah sebagai berikut:

Langkah 4 Menerjemahkan model data logika global untuk target DBMS

Tujuan dilakukan tahap ini adalah untuk menghasilkan skema

relasional database dari model data logika global yang dapat

diimplementasikan untuk target DBMS. Ada tiga aktivitas yang dapat

dilakukan dalam tahap ini, yaitu:

Langkah 4.1 Merancang relasi dasar

Pada tahap ini, informasi mengenai entity-entity yang

telah dihasilkan dalam perancangan logika disusun dan

disatukan. Ada beberapa informasi yang diperoleh dari kamus

data dan definisi dari entity yang dapat digambarkan dengan

menggunakan DDL.

Langkah 4.2 Merancang representasi dari derived data

Derived data merupakan data yang diperoleh dari hasil

perhitungan, tidak terdapat dalam model data logika tetapi

didokumentasikan dalam kamus data. Langkah pertama yang

dilakukan adalah menguji model data logika dan kamus data,

dan menghas ilkan derived attributes. Dalam perancangan

database fisik, derived attributes yang disimpan dalam database

membutuhkan memory. Oleh karena itu, derived attribute tidak

disimpan secara langsung dalam database, dan dikalkulas i

57

 

setiap kali diperlukan. Hal ini dapat dilakukan dengan

menggunakan join.

Langkah 4.3 Merancang enterprise constraints

Mengubah relasi dengan menggunakan aturan dari

perusahaan yang mengatur transaksi-transaksi yang terjadi di

dunia nyata yang direpresentasikan dengan pembaruan.

Perancangan constraint ini mempengaruhi pemilihan DBMS.

Langkah 5 Representasi desain fisik

Tujuan representasi desain fisik adalah untuk menentukan

organisasi file optimal untuk menyimpan relasi dasar dan index yang

diperlukan untuk mencapai suatu kinerja yang cocok, dengan cara

relasi dan tuple disimpan dalam secondary storage. Untuk mencapai

tujuan ini, ada lima langkah yang dapat dilakukan, yaitu:

Langkah 5.1 Analisis transaksi

Tujuan dari analisis transaksi adalah untuk memahami

fungsionalitas dari transaksi-transaksi yang akan dijalankan

pada database dan untuk menganalisis transaksi-transaksi yang

penting. Dalam menganalisis transaksi, perlu untuk

mengidentifikasi kriteria kinerja, seperti:

1. Transaksi-transaksi yang sering dijalankan dan akan

memiliki dampak yang signifikan pada kinerja.

2. Transaksi-transaksi yang penting untuk operasi bisnis.

58

 

3. Tuntutan waktu untuk membuat database selama satu hari

atau satu minggu.

Informasi-informasi ini digunakan untuk

mengidentifikasi bagian database yang menyebabkan masalah

kinerja. Pada saat yang sama, fungsionalitas high-level dari

transaksi diidentifikasi. Informasi ini digunakan untuk memilih

organisasi file dan index. Dalam beberapa kasus, tidak

memungkinkan untuk menganalisis seluruh transaksi. Oleh

karena itu untuk mengatasi hal tersebut, dapat dilakukan

dengan tiga cara di bawah ini:

1. Memetakan seluruh bagian transaksi ke relasi.

2. Menentukan relasi yang paling sering diakses dari transaksi.

3. Menganalisis penggunaan data dari transaksi.

Langkah 5.2 Memilih organisasi file

Tujuannya adalah untuk menentukan organisasi file yang

efisien untuk setiap relasi. Ada beberapa pedoman yang dapat

digunakan untuk memilih organisasi file berdasarkan tipe file,

yaitu:

a. Heap

Heap merupakan tempat penyimpanan yang baik

ketika data yang disimpan dalam relasi dalam jumlah besar,

relasi hanya memiliki sedikit halaman yang panjang. Selain

itu, juga ketika setiap tuple dalam relasi ingin ditampilkan

59

 

kembali setiap relasi yang diakses dan ketika relasi memiliki

struktur akses tambahan seperti index key. Heap tidak baik

digunakan ketika hanya tuple yang dipilih yang diakses.

b. Hash

Hash merupakan tempat penyimpanan yang baik

ketika tuple yang ingin didapatkan kembali berdasarkan

pada kecocokan dengan nilai field hash-nya, khususnya

ketika aksesnya acak.

c. Indexed Sequential Access Method (ISAM)

ISAM mendukung pencarian data berdasarkan key

yang tepat, pencocokan pola, kisaran nilai, dan bagian key

tertentu. Namun, ISAM masih statis karena dibuat ketika file

dibuat. Kinerja ISAM memperburuk perubahan relasi.

Perubahan juga menyebabkan ISAM kehilangan kunci untuk

pencarian secara berurut, sehingga lambat untuk

mendapatkan data.

d. B+-tree

Index B+-tree bersifat dinamis, berkembang seiring

berkembangnya relasi. Kinerja B+-tree tidak mempengaruhi

perubahan relasi. B+-tree menetapkan access key bahkan

ketika relasi tersebut diubah, sehingga pencarian data

menjadi lebih efisien.

e. Clusters

60

 

Clusters mengelompokkan satu atau lebih tabel yang

disimpan bersama-sama secara fisik karena tabel-tabel

tersebut saling berbagi kolom dan kadang digunakan secara

bersamaan. Karena baris-baris yang saling berhubungan

disimpan dalam tempat penyimpanan yang sama, maka

waktu akses ke disk meningkat. Kolom-kolom yang saling

berhubungan dari tabel-tabel dalam cluster disebut cluster

key.

Langkah 5.3 Memilih indeks

Tahap ini dilakukan untuk meningkatkan kinerja sistem.

Ada beberapa pedoman yang dapat digunakan untuk memilih

daftar indeks, yaitu:

a. Jangan memilih indeks dengan relasi yang kecil.

b. Pada umumnya, indeks primary key dari relasi jika bukan

key dari organisasi file.

c. Menambahkan indeks kedua ke foreign key jika sering

diakses.

d. Menambahkan indeks kedua ke beberapa atribut jika sering

digunakan sebagai secondary key.

e. Menambahkan indeks kedua pada atribut yang sering terlibat

dalam selection atau join, ORDER BY, GROUP BY.

f. Menambahkan indeks kedua pada atribut yang dibangun

dengan fungsi agregasi.

61

 

g. Menambahkan indeks kedua apabila hasilnya dalam sebuah

index-only plan.

h. Hindari memberikan indeks pada atribut yang tabelnya

sering diubah.

i. Hindari memberikan indeks pada atribut jika query

menerima proporsi yang signifikan dari tuple dalam relasi.

j. Hindari memberikan indeks pada atribut yang mengandung

karakter string yang panjang.

Langkah 5.4 Mengestimasi kebutuhan disk space

Tujuan dari tahap ini adalah untuk mengestimasi disk

space yang diperlukan untuk implementasi database pada

secondary storage. Ukuran dari disk space dapat berubah

tergantung pada bagaimana suatu relasi berkembang.

Langkah 6 Desain user view

Fase pertama yang dilakukan adalah ketika menghasilkan

model data konseptual, setiap view diidentifikasi selama fase analisis

database. Fase kedua, model data konseptual lokal ini dipetakan

menjadi model data logika lokal berdasarkan model relasional dan

untuk aplikasi dengan lebih dari satu view. Fase ketiga, model data

logika lokal digabungkan menjadi model data logika global.

Langkah 7 Desain mekanisme keamanan

Tujuan dari tahap ini adalah untuk menentukan bagaimana

persyaratan keamanan yang telah dicatat saat proses analisis

62

 

direalisasi. Ada dua macam keamanan yang disediakan oleh DBMS,

yaitu:

1. System security, meliputi akses dan penggunaan database pada

tingkat sistem, seperti username dan password.

2. Data security, meliputi akses dan penggunaan obyek database

seperti tabel dan view dan aksi hanya dapat dilakukan oleh

pengguna yang memiliki obyek.

Langkah 8 Menanggapi pengenalan dari kontrol redundansi

Tujuan dilakukan tahap ini adalah untuk menentukan apakah

pengenalan redundansi dalam cara yang terkontrol dengan melakukan

penyederhanaan aturan normalisasi akan meningkatkan kinerja

sistem. Hasil dari normalisasi adalah perancangan basis data logika

secara structural, konsisten, dan menekan jumlah redundansi. Faktor

yang perlu dipertimbangkan adalah:

1. Denormalisasi membuat implementasi lebih kompleks.

2. Denormalisasi selalu mengorbankan fleksibilitas.

3. Denormalisasi akan membuat cepat dalam retrieve data tetapi

lambat dalam update.

Dipertimbangkan melakukan denormalisasi dalam situasi

berikut, khususnya untuk mempercepat transaksi yang sering terjadi

atau kritis. Adapun langkah-langkah yang dapat dilakukan pada tahap

ini, yaitu:

Langkah 8.1 Menggabungkan hubungan one-to-one (1:1)

63

 

Relasi one-to-one (1:1) diperiksa kembali agar dapat

ditentukan dampak dari penggabungan relasi–relasi ke dalam

sebuah relasi tunggal. Penggabungan hanya dipertimbangkan

untuk hubungan yang sering direferensikan secara bersama dan

jarang direferensikan secara terpisah.

Langkah 8.2 Menggandakan atribut non-key dalam hubungan one-

to-many untuk mengurangi join

Dengan tujuan khusus untuk mengurangi atau

menghilangkan penggabungan dari beberapa query yang sering

terjadi atau kritis, dipertimbangkan keuntungan yang mungkin

dihasilkan dari melakukan duplikasi terhadap satu atau lebih

atribut non-key dari relasi parent ke dalam relasi child dalam

sebuah relasi one-to-many (1:*).

Langkah 8.3 Menggandakan atribut foreign key dalam hubungan

one-to-many (1:*) untuk mengurangi join

Dengan tujuan khusus untuk mengurangi atau

menghilangkan penggabungan dari beberapa query yang sering

terjadi atau kritis, dipertimbangkan keuntungan yang mungkin

dihasilkan dari melakukan duplikasi terhadap satu atau lebih

atribut foreign-key dari relasi parent ke dalam relasi child

dalam sebuah relasi one-to-many (1:*).

Langkah 8.4 Menggandakan atribut dalam hubungan many-to-many

(*:*) untuk mengurangi join

64

 

Saat akan dihasilkan informasi dari relasi many-to-many

(*:*), harus dilakukan penggabungan tiga relasi. Dua relas i

diturunkan dari entity asal, dan relasi baru merepresentasikan

relasi antara dua entity. Dalam beberapa keadaan,

dimungkinkan untuk melakukan pengurangan jumlah relas i

yang akan digabungkan dengan melakukan penggandaan

atribut dari salah satu entity asal dalam relasi intermediate.

Langkah 8.5 Memperkenalkan kelompok yang berulang

Kelompok yang berulang telah dieliminasi dari model

data logika sebagai akibat dari keharusan dalam 1NF.

Kelompok yang berulang dipisahkan keluar ke dalam relas i

baru, membentuk sebuah relasi one-to-many (1:*) dengan relas i

asal (parent). Terkadang, memperkenalkan kembali kelompok

yang berulang merupakan cara yang efektif untuk

meningkatkan kinerja sistem.

Langkah 8.6 Menggabungkan lookup tables dengan relasi dasar

Lookup tables, yang terkadang disebut dengan reference

tables atau pick list, adalah sebuah kasus khusus dalam relasi

one-to-many (1:*). Lookup tables berisi sebuah code dan

sebuah deskripsi. Terdapat beberapa keuntungan dari

penggunaan lookup tables, yaitu:

1. Pengurangan ukuran dari relasi child.

65

 

2. Saat akan dilakukan perubahan terhadap deskripsi, akan

lebih mudah melakukan perubahan satu kali di dalam lookup

tables daripada melakukan perubahan beberapa kali di

dalam relasi child.

3. Lookup tables dapat digunakan untuk melakukan validasi

terhadap user input.

Jika lookup tables digunakan dalam beberapa query yang

sering terjadi atau kritis, dan deskripsi tidak dapat diubah, dapat

dilakukan duplikasi atribut deskripsi di dalam relasi child.

Dengan demikian, penggabungan relasi child terhadap lookup

tables akan dapat dieliminasi.

Langkah 8.7 Membuat extract tables

Terdapat beberapa situasi di mana laporan dapat

dijalankan pada suatu waktu. Laporan melakukan akses

terhadap data dan menampilkan penggabungan multi-relas i

pada set basis relasi yang sama. Akan tetapi, laporan basis data

mungkin relatif statik atau bukan hasil terkini (current data).

Dalam hal ini, dimungkinkan untuk membuat highly

denormalized extract table tunggal pada basis relasi sesuai

kebutuhan laporan, dan mengikuti pengguna saat melakukan

akses terhadap basis relasi.

Langkah 9 Mengawasi dan menyempurnakan sistem operasional

66

 

Bertujuan untuk memonitor sistem operasi dan meningkatkan

performa guna menentukan perancangan sistem yang tepat atau

menggambarkan perubahan kebutuhan. Terdapat beberapa

keuntungan dari tuning basis data, yaitu:

a. Dapat menghindari penambahan hardware yang tidak dibutuhkan.

b. Dapat menurunkan kebutuhan konfigurasi hardware, sehingga

membuat biaya lebih rendah dan memudahkan perawatan.

c. Menghasilkan sistem dengan response time yang cepat dan

throughput yang lebih baik, sehingga akan meningkatkan

produktifitas pengguna.

d. Meningkatkan response time, sehingga akan meningkatkan moral

pegawai.

e. Meningkatkan response time, sehingga akan meningkatkan

kepuasan pelanggan atas pelayanan.

7. Perancangan web database fisik

Perancangan web database fisik meliputi:

1. Merancang bagaimana halaman web diimplementasikan dan

dihubungkan ke sistem database.

2. Software tools dan teknik yang dapat digunakan untuk membuat suatu

sistem database dapat diakses melalui web.

Komponen sistem database dapat diimplementasikan sebagai ekstensi

dari server atau browser, atau eksternal bagi web. Implementasi harus

menganalisis dan memutuskan bagaimana untuk mengkases database dari

67

 

client atau server dan yang mana yang akan memproses aplikasi.

Implementasi juga harus mempertimbangkan arsitektur web di mana

aplikasi web seharusnya dibangun dalam arsitektur client server. Jenis-

jenis arsitektur client server, yaitu:

a. Arsitektur two-tier client server

Client pada first tier sedangkan database server pada second tier.

Tugas client di sini yaitu menyajikan antarmuka pengguna dan logika

bisnis utama dan pemrosesan data. Sedangkan tugas database server

yaitu validasi server-side dan pengaksesan database.

b. Arsitektur three-tier client server

Client pada first tier, server aplikasi pada second tier, dan

database server pada third tier. Tugas client di sini yaitu menyajikan

antarmuka pengguna. Tugas server aplikasi yaitu logika bisnis dan

pemrosesan data. Sedangkan tugas database server yaitu validasi data

dan pengaksesan database.

Dalam memilih cara implementasi apa yang cocok, terdapat beberapa

pertimbangan yang dapat dibandingkan seperti pada tabel berikut:

Tabel 2. 1 Perbandingan Client Side dengan Server Side

Pertimbangan Client side Server side

Sistem terdistribusi

Fungsi didistribusikan ke client.

Fungsi terpusat di server.

Workload dan kecepatan

Memberikan umpan balik yang cepat.

Umpan balik lebih lambat, tergantung pada jaringan dan server workload.

Skala Fungsionalitas skala kecil. Fungsionalitas skala besar.

68

 

fungsionalitas Sumber daya yang cukup

Client harus memiliki sumber daya yang cukup.

Server harus memiliki sumber daya yang cukup.

Ketergantungan Bergantung pada client environment.

Tidak bergantung pada client environment.

Sedangkan untuk memilih bahasa pemrograman yang digunakan ada

beberapa pertimbangan, yaitu: pemrosesan client, tampilan, validasi dan

deteksi database, degradasi yang baik, deteksi browser, fitur bloat, dan isu

antarmuka pengguna.

2.1.11 Perancangan Sistem

Secara formal, perancangan sistem dapat didefinisikan sebagai tugas–

tugas yang terfokus pada spesifikasi–spesifikasi dari sebuah detail solusi

berbasis komputer (Whitten, 2004, p472). Perancangan sistem merupakan

proses iteratif di mana kebutuhan diterjemahkan ke dalam blue print untuk

membangun software. Perancangan direpresentasikan pada sebuah level

abstraksi tingkat tinggi, sebuah level yang dapat ditelusuri secara langsung ke

obyektivitas sistem yang spesifik. Perancangan sistem adalah yang pertama

dari tiga aktivitas teknik yang dibutuhkan untuk membangun sebuah sistem

(perancangan, code generation, dan test).

2.1.11.1 Strategi Perancangan Sistem

Ada banyak strategi untuk melakukan perancangan sistem.

Strategi-strategi itu seringkali terlihat sebagai pendekatan alternatif

69

 

yang bersaing untuk merancang sistem, namun dalam realitas

strategi–strategi itu saling melengkapi satu sama lain (Whitten, 2004,

p473), yaitu:

a. Modern Structured Design

Teknik perancangan terstruktur membantu pengembang

dalam menghadapi besarnya ukuran dan kompleksitas program.

Modern structured design adalah sebuah teknik berorientasi proses

untuk mengubah sebuah program yang besar menjadi modul–

modul (kumpulan instruksi–instruksi) yang dihasilkan dalam

program komputer sehingga menjadi lebih mudah

diimplementasikan dan diubah.

Konsep dari modern structured design cukup sederhana,

yaitu dengan merancang program sebagai sebuah hirarki top-down

dari modul–modul. Modul–modul harus bersifat kohesif, yaitu

masing–masing modul harus menyelesaikan hanya satu fungsi

sehingga membuat modul–modul dapat digunakan kembali pada

program yang akan datang. Modul–modul juga harus mengurangi

tingkat kopling, yaitu tingkat ketergantungan antara satu modul

dengan modul lainnya, sehingga akan meminimalisasi efek

perubahan suatu modul terhadap modul lain.

b. Information Engineering

Information engineering adalah teknik untuk perencanaan,

analisis, dan perancangan sistem informasi. Tool utama dari

70

 

information engineering adalah data model diagram. Contoh

Entity Relationship Diagram (ERD) sederhana:

c. Prototyping

Pendekatan prototyping adalah sebuah proses iteratif yang

melibatkan hubungan kerja yang dekat antara perancang dengan

pengguna sistem. Sebuah prototype membutuhkan partisipasi dari

pengguna akhir. Prototype memungkinkan pengguna akhir untuk

mengubah pemikirannya terkait sistem yang dibutuhkan, karena

implementasi pemenuhan kebutuhan akan memberikan gambaran

yang memperjelas pandangan pengguna akhir akan sistem yang

diharapkan memenuhi kebutuhan. Prototype dapat dibuat untuk

menggambarkan output, cara kerja sistem, fungsi–fungsi navigasi,

seluruh sub sistem, atau bahkan seluruh sistem.

d. Rapid Application Development

Rapid application development adalah sebuah strategi

perancangan yang menggabungkan teknik perancangan

terstruktur, prototyping, dan joint application development

memiliki 1 .. * 1 .. 1

Cabang

NoCabang Alamat

Pegawai

NoPegawai Nama Alamat

Gambar 2. 12 Contoh Entity Relationship Diagram (ERD)

71

 

(sebuah teknik yang melengkapi analisis sistem dan teknik

perancangan lain dengan cara menekankan pembangunan

partisipatif antara pemilik, pengguna, perancang, dan pembangun

sistem) guna mempercepat pengembangan sistem.

2.1.11.2 Karakteristik Perancangan

Perancangan yang baik memiliki tiga karakteristik yang dapat

digunakan sebagai pedoman.

a. Perancangan harus mengimplementasikan semua kebutuhan

eksplisit yang terdapat dalam model analisis, dan harus dapat

mengakomodasi semua kebutuhan implisit yang diinginkan

pelanggan (pemilik maupun pengguna).

b. Perancangan harus dapat dibaca dan dimengerti oleh mereka yang

membuat kode, melakukan tes, dan mendukung sistem.

c. Perancangan harus menyediakan gambaran yang menyeluruh dari

sistem, pengalamatan data, fungsionalitas, serta perilaku domain

dari sebuah perspektif implementasi.

2.1.11.3 Kriteria Perancangan

Untuk mengevaluasi kualitas dari sebuah representasi

perancangan, harus ditetapkan kriteria teknis untuk perancangan yang

baik.

72

 

a. Sebuah rancangan harus menunjukkan struktur arsitektur yang

dibuat menggunakan pola perancangan yang diakui, berisi

komponen yang ditunjukkan oleh karakteristik perancangan, dan

dapat diimplementasikan dalam sebuah cara yang evolusioner.

Dengan demikian akan memungkinkan untuk dilakukan

implementasi dan testing.

b. Sebuah rancangan harus modular. Sistem harus terpartisi secara

logis ke dalam elemen–elemen yang menunjukkan fungsi dan

subfungsi yang spesifik.

c. Sebuah rancangan harus berisi representasi yang jelas dan terpisah

mengenai data, arsitektur, antarmuka, dan komponen–komponen

(modul–modul).

d. Sebuah rancangan harus mengarah ke struktur data yang sesuai

dengan obyek untuk diimplementasi dan ditarik dari pola data

yang dikenali.

e. Sebuah rancangan harus mengarah ke komponen yang

menunjukan karakteristik fungsional yang independen.

f. Sebuah rancangan harus mengarah ke antarmuka yang mampu

mengurangi kompleksitas hubungan antara modul–modul dengan

lingkungan eksternal.

g. Sebuah perancangan harus dihasilkan menggunakan metode

berulang yang digerakkan oleh informasi yang diperoleh selama

analisis kebutuhan sistem.

73

 

2.1.11.4 Prinsip Perancangan

a. Proses perancangan tidak harus terpaku oleh pandangan yang

sempit.

Perancang yang baik harus mempertimbangkan pendekatan

alternatif, menilai berdasarkan masing–masing kebutuhan dari

masalah, ketersediaan sumber daya, dan konsep perancangan.

b. Rancangan harus dapat dilacak ke model analisis.

Karena elemen tunggal dari model perancangan sering

melacak kebutuhan ganda, perlu dimiliki cara untuk melacak

bagaimana kebutuhan telah dipenuhi oleh model perancangan.

c. Rancangan tidak harus menemukan kembali hal yang telah ada

Sistem dikonstruksikan menggunakan serangkaian pola

perancangan, banyak yang kemungkinan besar telah ditemukan

sebelumnya. Pola–pola tersebut harus selalu dipilih sebagai

sebuah alternatif untuk penemuan kembali. Waktu dan sumber

daya terbatas, oleh karena itu waktu perancangan harus

diinvestasikan dalam representasi ide–ide yang benar–benar baru

dan mengintegrasikan pola–pola yang telah ada.

d. Perancangan harus meminimalisasi perbedaan intelektual antara

sistem dan masalah yang terdapat dalam dunia nyata.

Struktur perancangan sistem harus mengikuti struktur pada

sumber masalah.

74

 

e. Perancangan harus menampilkan keseragaman dan integritas.

Rancangan dikatakan seragam apabila peraturan mengenai

jenis dan format disampaikan kepada tim perancangan sebelum

perancangan dimulai. Rancangan disebut terintegrasi jika

antarmuka antara komponen perancangan diperhatikan dengan

baik.

f. Perancangan harus terstruktur guna menyesuaikan perubahan.

Penggunaan konsep yang sesuai memungkinkan rancangan

untuk dapat menyesuaikan diri terhadap perubahan.

g. Perancangan harus terstruktur agar dapat didegradasi secara hati–

hati, bahkan saat ditemukan data, kejadian, ataupun kondisi

operasi yang menyimpang.

Rancangan harus dirancang untuk dapat mengakomodasi

keadaan yang tidak biasa. Jika proses harus dihentikan, maka itu

dapat dilakukan dengan cara yang sesuai.

h. Perancangan bukan coding dan coding bukanlah perancangan.

Bahkan saat detail rancangan prosedural dibuat untuk

komponen program, level abstraksi dari model rancangan lebih

tinggi daripada source code.

i. Perancangan harus dinilai berdasarkan kualitas saat dibuat, bukan

setelah kenyataan.

j. Perancangan harus ditinjau ulang untuk meminimalisasi kesalahan

konseptual.

75

 

Terkadang terdapat kecenderungan untuk fokus kepada

detail dan melewatkan hal yang lebih luas.

2.1.11.5 Konsep Perancangan

a. Abstraction

Abstraksi memungkinkan perancang untuk

menspesifikasikan prosedur dan data. Saat mempertimbangkan

solusi modular dari masalah, terdapat banyak level abstraksi yang

dapat muncul. Pada level abstraksi tertinggi, sebuah solusi

dinyatakan dalam terminologi yang luas menggunakan bahasa dari

lingkungan masalah. Sedangkan pada level abstraksi terendah,

lebih diambil orientasi prosedural. Karena perbedaan level

abstraksi, maka dibuat abstraksi data dan abstraksi prosedural.

Abstraksi data adalah kumpulan data yang mendeskripsikan

sebuah obyek data. Dan abstraksi prosedural adalah sebuah urutan

instruksi yang memiliki fungsi spesifik dan terbatas.

b. Refinement

Refinement membantu perancang untuk menyatakan detail

low-level sebagai perkembangan perancangan. Konsep ini

sesungguhnya adalah sebuah proses elaborasi. Dimulai dari

deskripsi informasi yang didefinisikan pada level abstraksi tingkat

tinggi. Deskripsi informasi tersebut tidak menjelaskan tentang

pekerjaan internal dari fungsi ataupun struktur internal dari

76

 

informasi. Konsep ini mengakibatkan perancang melakukan

elaborasi pada original statement.

c. Modularity

Konsep modularitas berarti pembagian sebuah sistem ke

dalam komponen–komponen terpisah yang memiliki nama dan

dapat dialamatkan (modul–modul) yang diintegrasikan untuk

memenuhi kebutuhan masalah. Dapat dinyatakan bahwa

modularitas adalah atribut tunggal dari sistem yang

memungkinkan sebuah program dapat dikelola secara intelektual.

d. Software Architecture

Software architecture menyinggung keseluruhan struktur

dari sistem dan cara–cara yang menyatakan bahwa struktur

menyediakan integritas konseptual untuk sistem. Secara

sederhana, arsitektur adalah struktur hirarki dari komponen–

komponen program (modul–modul), juga dapat disebut sebagai

cara yang menyatakan interaksi antara komponen–komponen dan

struktur dari data yang digunakan oleh komponen–komponen.

Berikut adalah gambaran terminologi struktur arsitektur:

77

 

e. Control Hierarchy

Control hierarchy disebut juga struktur program yang

merepresentasikan organisasi dari komponen–komponen program

(modul–modul) dan mengimplikasikan hirarki kontrol. Control

hierarchy juga merepresentasikan dua karakteristik berbeda dari

arsitektur software, yaitu visibilitas dan konektivitas. Visibilitas

mengindikasikan rangkaian komponen–komponen program yang

dapat digunakan sebagai data. Sedangkan konektivitas

mengindikasikan rangkaian komponen–komponen program yang

secara langsung digunakan sebagai data.

f. Structural Partitioning

Jika jenis arsitektur dari sistem adalah hirarki, maka struktur

program dapat dipartisi baik secara horizontal maupun vertikal.

Fan-out

Fan-in

M

a b c

d e m

h o q f

k l

g n

i

p

j r

Width

Depth

Gambar 2. 13 Terminologi Struktur Arsitektur

78

 

1. Horizontal Partitioning

Horizontal partitioning mendefinisikan cabang–cabang

terpisah dari hirarki modular untuk setiap fungsi program

utama. Secara sederhana dapat dinyatakan bahwa horizontal

partitioning mendefinisikan tiga partisi, yaitu input, proses, dan

output. Dengan horizontal partitioning, sistem akan lebih

mudah dites, diperluas, dan dipelihara

2. Vertical Partitioning

Vertical partitioning disebut juga factoring. Vertical

partitioning menyarankan bahwa pembuatan keputusan dan

kerja harus didistribusikan secara top-down di dalam struktur

program. Modul pada level tertinggi harus menampilkan fungs i

kontrol dan melakukan sedikit kerja proses yang aktual.

Sedangkan modul–modul di bawahnya harus menjadi pekerja,

menampilkan semua tugas input, komputasi, dan output.

g. Data Structure

Struktur data adalah representasi relasi logika di antara

elemen–elemen individual dari data. Karena struktur informasi

akan selalu mempengaruhi rancangan prosedural akhir, maka

struktur data menjadi sama pentingnya dengan struktur progam

untuk merepresentasikan arsitektur sistem. Struktur data, sama

halnya dengan struktur program, dapat direpresentasikan pada

level abstraksi yang berbeda. Sebagai contoh, sebuah stack adalah

79

 

sebuah model konseptual dari struktur data yang dapat

diimplementasikan sebagai vektor maupun linked-list. Bergantung

pada level dari detail rancangan, pekerjaan internal dari stack

dapat atau tidak dapat dispesifikasikan.

h. Software Procedure

Software procedure berfokus pada detail proses dari setiap

modul individual. Prosedur harus menyediakan sebuah spesifikasi

proses yang tepat, termasuk urutan kejadian, poin keputusan yang

tepat, operasi berulang, dan bahkan organisasi serta struktur data.

i. Information Hiding

Prinsip dasar dari information hiding menyarankan agar

modul–modul digolongkan oleh keputusan perancangan yang

masing–masing tersembunyi satu dari yang lainnya. Dengan kata

lain, modul–modul harus dispesifikasikan dan dirancang sehingga

informasi (prosedur dan data) berisi sebuah modul yang tidak

dapat dilalui oleh modul lain yang tidak membutuhkan informasi

tersebut.

Penggunaan information hiding sebagai sebuah kriteria

perancangan untuk sistem modular memberikan keuntungan yang

lebih besar saat modifikasi dibutuhkan selama dilakukan tes dan

setelahnya, dan selama pemeliharaan sistem. Karena kebanyakan data

dan prosedur tersembunyi dari bagian lain sistem, maka kesalahan

80

 

yang muncul selama modifikasi akan lebih sedikit tersebar ke lokasi

lain dalam sistem.

2.1.11.6 Tahap Perancangan Sistem

Dalam memenuhi sebuah perancangan, maka perlu dilakukan

beberapa tahapan. Dimulai dari perancangan arsitektur aplikasi,

perancangan sistem basis data, perancangan antarmuka, spesifikasi

paket rancangan, hingga memperbarui rencana proyek (Whitten,

2004, p479).

a. Perancangan Arsitektur Aplikasi

Sebuah arsitektur aplikasi mendefinisikan teknologi–

teknologi yang digunakan oleh (dan untuk membangun) satu,

sebagian besar, atau seluruh sistem informasi berkaitan dengan

data, proses, antarmuka, dan komponen jaringan. Dengan

demikian, merancang arsitektur aplikasi melibatkan pertimbangan

teknologi jaringan dan pengambilan keputusan tentang bagaimana

data, proses, dan antarmuka dari sistem didistribusikan di antara

lokasi–lokasi bisnis. Tahap ini dikerjakan dengan menganalisis

model data dan model proses yang telah diinisialisasi selama

analisis kebutuhan. Arsitektur aplikasi menggambarkan urutan

proses dari aktivitas bisnis.

b. Perancangan Sistem Basis Data

81

 

Seorang perancang harus mengutamakan perancangan basis

data yang dapat beradaptasi dengan kebutuhan dan pengembangan

di masa yang akan datang. Perancang juga harus melakukan

analisis tentang bagaimana program akan mengakses data untuk

keperluan peningkatan performa. Tujuan dari tahapan ini adalah

untuk mempersiapkan spesifikasi rancangan teknis untuk basis

data yang dapat beradaptasi dengan kebutuhan dan pengembangan

di masa yang akan datang.

c. Perancangan Sistem Antarmuka

Dalam tahap ini, pengguna sistem harus dilibatkan. Input,

output, dan dialog antarmuka adalah apa yang akan mereka lihat

dan yang akan mereka gunakan. Mereka akan ditanyakan

mengenai masing-masing prototipe input/output. Perancang sistem

memiliki tanggung jawab untuk menyelesaikan tahapan ini.

Perancang sistem dapat menggunakan kemampuannya untuk

merancang graphical user interface. Di samping itu, system

builders dapat melakukan konstruksi beragam rancangan layar

bagi pengguna untuk meninjau ulang selama perancangan dengan

menggunakan prototipe.

d. Pengemasan Spesifikasi Rancangan

Tahap ini melibatkan pengemasan seluruh spesifikasi dari

tugas-tugas perancangan sebelumnya ke dalam sebuah rangkaian

spesifikasi yang akan menuntun aktivitas programmer selama fase

82

 

konstruksi dari metodologi pengembangan sistem. Tetapi tahap ini

lebih dari sekedar melakukan pengemasan. Seberapa banyak yang

akan dilakukan dalam tahapan ini lebih bergantung pada dua hal,

yaitu gambaran hubungan antara tanggung jawab perancang

program dan tanggung jawab programmer, dan apakah

metodologi dan solusi memanggil rancangan dari struktur program

secara keseluruhan. Input dari tahap ini adalah spesifikasi beragam

basis data, input, dan output yang telah dibuat sebelumnya.

e. Perbarui Project Plan

Analis dan pemilik sistem harus mempertimbangkan

kemungkinan yang berdasar pada kinerja perancangan yang

komplit, jadwal kerja keseluruhan, estimasi biaya, dan estimasi

lain yang harus disesuaikan. Tahap ini dimulai saat project

manager memutuskan bahwa perancangan telah selesai. Kunci

utama dari tahap ini adalah memperbarui project plan. Rencana

yang telah diperbarui harus mencakup detail rencana untuk fase

konstruksi.

2.1.12 Web Database

Web dan basis data, dapat digunakan bersama-sama untuk

memungkinkan banyak komputer, mungkin pada lokasi yang berbeda dan

dengan basis datanya masing-masing, bekerja sama demi menyediakan solusi

bagi masalah sederhana hingga yang biasanya kompleks.

83

 

2.1.12.1 Internet dan Web

a. Internet

Internet adalah suatu jaringan yang menghubungkan

jaringan komputer di seluruh dunia (Eaglestone, 2001, p20).

Jaringan komputer menyediakan sambungan antar komputer untuk

transmisi informasi komputer ke komputer dalam bentuk digital

secara langsung melalui sambungan elektronik, seperti kabel, serat

optik, radio, gelombang mikro, atau satelit.

Internet mencapai integrasi jaringan komputer melalui

pengimplementasian protokol komunikasi standar. Protokol

komunikasi adalah suatu kumpulan aturan dan format data yang

dapat dikomunikasikan (Eaglestone, 2001, p22). Aturan tersebut

menjelaskan cara bagaimana pesan dikodekan, dan menentukan

jenis pesan yang dapat dikirim serta pesan yang harus dikirim

sebagai respon. Internet menggunakan set protokol standar yang

disebut TCP/IP (Transmission Control Protocol/Internet Protocol)

yang memungkinkan jaringan komputer yang berbeda dapat

berkomunikasi satu sama lain (Eaglestone, 2001, p23).

Setiap komputer di internet memiliki suatu alamat unik,

yang disebut alamat IP (Internet Protocol) yang memiliki format

numerik (Eaglestone, 2001, p23). Alamat IP digunakan untuk

84

 

memungkinkan komputer berkomunikasi dengan komputer

lainnya melalui internet.

b. Web

Web adalah aplikasi internet yang menyediakan cakupan

luas dari informasi dan layanan untuk disimpan dan diakses

melalui internet (Eaglestone, 2001, p20). Informasi yang disimpan

di web berupa ‘dokumen web’ yang bisa berisi link. Link

digunakan untuk mengalamatkan bagian lain dari dokumen atau

dokumen lain yang berbeda. Web menggunakan internet demi

menyediakan layanan untuk (Eaglestone, 2001, p190):

1. Menyimpan informasi.

2. Menemukan dan mengambil informasi.

3. Menyimpan dan menjalankan program komputer.

4. Memasukkan dan memanipulasi informasi.

Yang membuat fungsi web sangat kuat dan revolusioner

adalah kemampuannya untuk digunakan hampir dari seluruh

daerah di dunia, oleh hampir semua orang, dan menggunakan

sistem komputer dan sumber data komunikasi berbiaya kecil.

Web berbeda dengan teknologi penyimpanan dan

komunikasi informasi sebelumnya dikarenakan beberapa hal

(Eaglestone, 2001, p26):

1. Tidak seperti gagasan penyimpanan informasi terpusat yang

dikelola oleh staf manajemen informasi profesional. Setiap

85

 

organisasi atau individu yang terhubung ke web dapat membuat

serta menyimpan dokumen hypermedia-nya di web. Setiap

orang juga dapat mengacu pada dokumen web lainnya.

2. Lokasi geografis dari dokumen menjadi jelas karena ditentukan

oleh alamat webnya.

3. Web memiliki antarmuka pengguna yang sederhana dan

seragam, tanpa memerhatikan komputer apa yang digunakan

Beberapa konsep yang berhubungan dengan web, yaitu:

1. Hypermedia

Informasi yang disimpan dalam web dihubungkan oleh

dokumen hypermedia yang disimpan di komputer yang

terhubung ke internet. Disebut dokumen media karena tidak

hanya dapat berisi teks, tapi juga media lainnya, seperti

gambar, suara, dan video. Dokumen bersifat hyper karena

memiliki struktur yang kompleks (Eaglestone, 2001, p25).

Hubungan antar bagian dari suatu dokumen disebut hyperlink

(Eaglestone, 2001, p25).

2. HTML

Dokumen web multimedia ditulis menggunakan HTML

(Hyper-Text Mark-Up Language). Mark-up language

mendeskripsikan isi dan penyajian dari dokumen dengan

memasukkan kode (dalam HTML disebut tag) di dalam

dokumen, biasanya sebelum dan sesudah bagian-bagian yang

86

 

dideskripsikan, untuk mengidentifikasi dan membatasi bagian-

bagian yang berbeda, serta menentukan bagaimana seharusnya

ia ditafsirkan oleh browser (Eaglestone, 2001, p29).

3. URL dan HTTP

Setiap sumber daya web memiliki suatu alamat unik yang

menunjukkan di mana ia dapat diakses, yang disebut URL

(Uniform Resource Locator) (Eaglestone, 2001, p29). URL

juga digunakan dalam dokumen web untuk membentuk link

antar dokumen web dan situs web. Protokol komunikasi yang

digunakan web di mana sambungan antara browser dan klien

dibangun, disebut HTTP (HyperText Transfer Protocol)

(Eaglestone, 2001, p30).

4. Browser

Suatu program untuk melihat dan mengakses sumber

daya web, disebut browser (Eaglestone, 2001, p30).

5. Server dan Client

Web diimplementasikan oleh program yang dijalankan di

komputer yang terhubung dengan internet. Tujuan dari program

tersebut adalah membuat beberapa komputer berlaku sebagai

‘web server’, yaitu komputer yang menyediakan informasi dan

layanan (sumber daya web) yang dapat diakses di web.

Program lainnya membuat komputer berlaku sebagai ‘web

client’, yaitu komputer yang memungkinkan penggunanya

87

 

mengakses program dan informasi yang disimpan di web

(Eaglestone, 2001, p197). Web server dan web client

berkomunikasi melalui internet.

Web server digunakan untuk menyimpan informasi dan

layanan yang dapat diakses oleh web client. Ruang di web

server untuk menyimpannya disebut situs web. Situs web

seperti layaknya suatu penyimpanan file konvensional di mana

isinya adalah dokumen web dan sumber daya lainnya.

2.1.12.2 Web Database

a. Aplikasi Web

Kemampuan web untuk berkomunikasi di dalam dan antar

organisasi membawa perubahan bagi organisasi, yaitu

(Eaglestone, 2001, p33):

1. Batas-batas dalam organisasi dihapus – organisasi dasarnya

dibatasi oleh batasan-batasan fisik karena posisi geografisnya.

Web dengan caranya membuat batasan-batasan tersebut

menjadi kurang terasa.

2. Batas-batas antar organisasi dihapus – organisasi dapat bekerja

sama lebih dekat.

b. Web dengan Sistem Basis Data

Internet dan web mengembangkan kemampuan sistem basis

data dalam dua aspek, yaitu (Eaglestone, 2001, p33):

88

 

1. Akses yang lebih luas: dengan menghubungkan sistem ke

internet, populasi pengguna potensial bertambah luas ke

seluruh dunia.

2. Layanan yang lebih: internet dapat menghubungkan sistem

basis data yang berbeda-beda untuk memberikan suatu layanan

baru.

Penggunaan sistem basis data dapat dihubungkan ke internet

melalui web dengan mudah hingga memungkinkan basis data

diakses dari jauh, namun koneksi juga dapat digunakan untuk

mengintegrasikannya dengan sistem lain. Beberapa jenis koneksi

yang mungkin terjadi yaitu (Eaglestone, 2001, p34):

1. Koneksi jarak jauh: suatu sistem basis data, yang mana dapat

diakses melalui web, dapat digunakan dari lokasi manapun di

dunia.

2. Arsitektur client-server.

3. Basis data terdistribusi: beberapa DBMS memiliki fas ilitas

yang memungkinkan bagian berbeda dari basis data disimpan

di komputer yang berbeda. Data didistribusikan dalam suatu

cara di mana pengguna dibuat tidak menyadari hal ini.

Keuntungannya adalah data dapat disimpan di lokasi di mana ia

digunakan.

89

 

4. Multidatabase: memungkinkan sejumlah basis data yang

dikelola secara independen digabung untuk menyediakan akses

ke data yang disimpan secara terintegrasi.

c. Basis Data dengan Sistem Web

Ada kondisi di mana penggunaan DBMS cocok untuk

mengatur data dari aplikasi web tertentu. DBMS akan

menyediakan pengambilan data dan fasilitas untuk manipulasi,

bersama dengan fasilitas keamanan dan integritas. Aplikasi web

diberikan fleksibilitas yang lebih besar dengan menyimpan

datanya dalam basis data, daripada dalam dokumen web. Ketika

diperlukan, data dapat diambil dari basis data untuk membangun

dokumen web baru.

Ada beberapa kondisi kapan harus menggunakan web

database. Penggunaan teknologi basis data dan web dalam suatu

sistem tunggal menjadi menguntungkan jika ingin dicapai situasi

berikut (Eaglestone, 2001, p36):

1. Akses lebih luas ke basis data – dengan menghubungkan sistem

basis data ke web maka memungkinkan adanya akses ke basis

data yang mencakup seluruh dunia.

2. Distribusi sistem – web membuat basis data dan aplikasinya

dapat didistribusikan.

3. Querying, manipulasi, dan administrasi web data yang lebih

baik – DBMS menyediakan fasilitas canggih untuk querying,

90

 

manipulasi, dan administrasi data. Aplikasi web harus

menggunakan data berukuran besar, oleh sebab itu akan

menguntungkan jika menggunakan DBMS untuk menyimpan

datanya.

 

2.2 Teori-teori Khusus yang Berhubungan dengan Topik Yang Dibahas

 

2.2.1 Proses Bisnis Perusahaan

1. Penjualan

Keberhasilan suatu perusahaan umumnya dilihat dari kemampuan

mendapatkan laba. Untuk mencapai keberhasilan tersebut, perusahaan

mengandalkan salah satu kegiatannya, yaitu penjualan. Penjualan adalah

penerimaan yang diperoleh dari pengiriman barang atau pelayanan. Proses

penjualan mencakup penerimaan order pelanggan hingga penerimaan

pembayaran. Dalam penjualan terdapat dua metode pembayaran, yaitu

tunai dan kredit.

2. Pembelian

Untuk mendukung penjualan, perusahaan perlu melakukan pembelian

untuk memenuhi ketersediaan sumber penjualan. Pembelian dapat diartikan

sebagai kegiatan memilih sumber daya, melakukan order, dan memperoleh

barang atau jasa. Pembelian merupakan pengelolaan input ke dalam proses

produksi perusahaan.

3. Pengiriman

91

 

Secara umum pengiriman barang adalah segala upaya yang

diselenggarakan secara sendiri atau bersama-sama dalam suatu organisasi

untuk memberikan pelayanan jasa berupa pengiriman barang.

4. Penerimaan

Pengertian penerimaan barang adalah menerima fisik barang dari

pabrik, prinsipal, atau distributor yang disesuaikan dengan dokumen

pemesanan dan pengiriman, serta dalam kondisi yang sesuai dengan

persyaratan penanganan barangnya.Di dalam aktivitas penerimaan barang

terdapat 3 hal penting yang tidak dapat dipisahkan satu dengan lainnya:

a. Fisik barang yang diterima.

b. Dokumentasi.

c. Cara penangananbarang.

Sehingga, secara umum dapat dinyatakan bahwa penerimaan barang

merupakan aktivitas operasional gudang yang sangat penting karena

merupakan awal dari penanganan barang.

5. Retur

Dalam proses penjualan dan pembelian, seringkali terdapat

ketidakcocokan kuantitas/kualitas antara barang/jasa yang diorder dengan

yang didapat. Hal tersebut dapat mengakibatkan pengembalian barang/jasa

kepada pihak yang memberikan barang. Kegiatan pengembalian

barang/jasa dari penerima ke pengirim karena ketidakcocokan

kualitas/kuantitas disebut dengan retur.

6. Perbaikan

92

 

Perbaikan dapat diartikan sebagai kegiatan mengembalikan nilai

barang/alat ke dalam kondisi semula atau bahkan lebih baik. Dengan

melakukan perbaikan, diharapkan barang/alat yang rusak dapat kembali ke

keadaan awalnya sehingga dapat digunakan kembali sebagai sumber

penjualan.

7. Instalasi

Instalasi dapat diartikan sebagai kegiatan mengaplikasikan sesuatu

sehingga dapat dipergunakan sesuai fungsinya. Instalasi memiliki

persamaan arti dengan pemasangan.

2.2.2 Bahasa Pemrograman PHP

PHP: Hypertext Preprocessor adalah sebuah bahasa script yang dapat

ditanamkan atau disisipkan ke dalam code HTML. PHP banyak dipakai dalam

pemrograman situs web dinamis. Pada awalnya PHP merupakan singkatan

dari Personal Home Page (situs personal). PHP pertama kali dibuat oleh

Rasmus Lerdorf pada tahun 1995. Pada saat itu PHP masih bernama Form

Interpreted (FI), yang wujudnya berupa sekumpulan scrip yang digunakan

untuk mengolah data formulir dari web. Selanjutnya Rasmus merilis kode

sumber tersebut untuk umum dan menamakannya PHP/FI.

Dengan perilisan menjadi sumber terbuka, banyak programmer yang

tertarik untuk ikut mengembangkan PHP. Pada tahun 1997, sebuah

perusahaan bernama Zend menulis ulang interpreter PHP menjadi lebih

bersih, lebih baik, dan lebih cepat. Kemudian pada Juni 1998, perusahaan

93

 

tersebut merilis interpreter baru untuk PHP dan meresmikan rilis tersebut

sebagai PHP 3.0 dan singkatan PHP diubah menjadi akronim berulang PHP:

Hypertext Preprocessing.

Pada Juni 2004, Zend merilis PHP 5.0. Dalam versi ini, inti dari

interpreter PHP mengalami perubahan besar. Versi ini juga memasukkan

model pemrograman berorientasi objek ke dalam PHP untuk menjawab

perkembangan bahasa pemrograman ke arah paradigma berorientasi objek.

PHP sebagai suatu bahasa scripting open source yang tersedia untuk

sejumlah platform biasanya dihubungkan dengan MySQL atau PostgreSQL,

karena kombinasi dari database yang tersedia (untuk Unix) dan bahasa

scripting yang gratis mampu memberikan sebuah paket lengkap guna

membangun aplikasi web database (Eaglestone, 2001, p363).

Beberapa kelebihan PHP, yaitu:

1. Bahasa pemrograman PHP adalah sebuah bahasa script yang tidak

melakukan sebuah kompilasi dalam penggunaannya.

2. Web Server yang mendukung PHP dapat ditemukan di mana-mana dari

mulai Apache, IIS, Lighttpd, hingga Xitami dengan konfigurasi yang relatif

mudah.

3. Dalam sisi pengembangan lebih mudah, karena banyaknya milis-milis dan

developer yang siap membantu dalam pengembangan.

4. Dalam sisi pemahaman, PHP adalah bahasa scripting yang paling mudah

karena memiliki referensi yang banyak.

94

 

5. PHP adalah bahasa open source yang dapat digunakan diberbagai mesin

(Linux, Unix, Macintosh, Windows) dan dapat dijalankan secara runtime

melalui console serta juga dapat menjalankan perintah-perintah sistem.