2013101064IFBab2001

BAB 2

TINJAUAN PUSTAKA

2.1 Teori Basis Data

Menurut Connolly dan Begg (2010, p65), basis data adalah

sekumpulan data yang terelasi secara logikal beserta

dengan

deskripsinya,

dirancang untuk memenuhi kebutuhan informasi dari

sebuah organisasi.

Menurut Connolly dan Begg, (2010, p54), sistem basis data

adalah sekumpulan aplikasi yang berinteraksi dengan basis data

melalui Database Management System

(DBMS) dan basis data itu

sendiri.

Menurut Cahyono (2009) pada Jurnal “Perancangan Basis Data:

Antara Pendekatan Model Entity Relationship Dan Model Relasional”

menyatakan bahwa basis data adalah salah satu komponen sistem

informasi yang mempunyai posisi yang sangat menentukan dalam

menunjang keberhasilan suatu sistem informasi.

Berdasarkan

definisi

pada sumber

di atas, dapat disimpulkan

bahwa basis data adalah sekumpulan data yang saling berelasi secara

logikal dan dirancang untuk memenuhi dan menunjang keberhasilan

kebutuhan informasi dari sebuah

organisasi. Sedangkan sistem basis

data adalah sekumpulan aplikasi

yang berinteraksi dengan basis data

melalui DBMS dan basis data itu sendiri dengan tujuan untuk

menyimpan dan memungkinkan pengguna untuk melakukan

manipulasi terhadap informasi sesuai dengan kebutuhan.

2.2 Database Management System (DBMS)

Menurut Connolly dan Begg (2010, p66),

Database

Management System

adalah sistem perangkat lunak yang

memungkinkan pengguna untuk melakukan definisi, membuat,

mengelola, dan mengatur akses terhadap basis data.

2.2.1 Komponen Lingkungan DBMS

Menurut Connolly dan Begg (2010, p68-71), terdapat 5

komponen utama dalam

DBMS Environment, yaitu hardware,

software, data, procedures, dan people.

Hardware

Agar dapat berjalan, pengaplikasian DBMS

memerlukan perangkat keras

yang

terdiri dari

single

personal computer, single mainframe, atau network of

computers.

Tidak semua DBMS dapat berjalan pada

bermacam-macam perangkat keras serta sistem operasi.

Software

Komponen

perangkat lunak terdiri atas

perangkat

lunak DBMS dan program aplikasi beserta sistem operasi

termasuk perangkat lunak jaringan apabila DBMS

digunakan dalam sebuah jaringan.

Data

Data sebagai salah satu komponen penting dalam

DBMS, berdasarkan sudut pandang pengguna adalah

sebagai penghubung antara komponen mesin dengan

komponen manusia.

Procedures

Berisi

instruksi-instruksi dan aturan-aturan yang

mengatur suatu rancangan dan penggunaan basis data.

Proses yang terdapat di dalamnya ialah:

penggunaan fasilitas DBMS

memulai dan mengakhiri DBMS

membuat backup basis data

menangani kegagalan perangkat keras dan perangkat

lunak

mengubah struktur tabel, mengatur ulang basis data

melalui multiple disk, meningkatkan kinerja atau arsip

data pada secondary storage

People

Manusia sebagai salah satu komponen yang terlibat

dalam proses sistem basis data, dapat

diidentifikasikan

antara lain sebagai data

administrators, database

administrators, database designers, application developers,

dan end users.

2.2.2 Keuntungan DBMS

Menurut Connolly dan Begg (2010, p77-81), terdapat 14

keuntungan dari penggunaan DBMS yaitu:

Control of data redundancy

Pendekatan basis data yang ditujukan

untuk

mengeliminasi redundansi dengan mengintegrasikan file-

file sehingga banyaknya

file

dari data yang sama tidak

disimpan. Pendekatan

tersebut tidak menghilangkan

redundansi secara keseluruhan, tetapi mengontrol jumlah

redundansi yang terjadi.

Data consistency

Dengan menghilangkan atau mengontrol redundansi

akan meminimalisir

resiko tidak konsisten yang muncul

terhadap data. Data disimpan hanya sekali dalam basis

data, setiap update

yang dilakukan menghasilkan

perubahan untuk semua pengguna sesegera mungkin.

More information from the same amount of data

Dengan terintegrasinya data operasional,

memungkinkan

organisasi untuk memperoleh informasi

tambahan melalui data tersebut.

Sharing of data

Basis data suatu organisasi digunakan oleh

pengguna yang memiliki otorisasi. Sejauh ini, penggunaan

data dalam membangun sebuah aplikasi adalah data yang

sudah disediakan, sedangkan untuk data yang akan

ditambahkan belum tentu masuk kedalam DBMS

melainkan hanya digunakan untuk mendefinisikan

persyaratan yang ada. Aplikasi yang baru juga dapat

digunakan untuk definisi dan manipulasi data.

Improved data integrity

Integritas basis data menunjukkan validitas dan

konsistensi data yang disimpan. Integritas biasanya

disesuaikan dengan constraint.

Improved security

Keamanan basis data adalah perlindungan basis data

terhadap pengguna-pengguna yang tidak

berwenang.

Akses yang diperbolehkan terhadap pengguna yang

memiliki wewenang dibatasi oleh operasi tertentu

(retrieval, insert, update, delete).

Enforcement of standards

Integrasi memperbolehkan Database Administrator

(DBA) untuk mendefinisikan dan menegaskan standar-

standar yang diperlukan, meliputi skala departemen,

organisasi, nasional, maupun internasional.

Economy of scale

Dengan menggabungkan seluruh data operasional

organisasi kedalam suatu basis data dan membuat sebuah

set aplikasi

pada satu sumber data yang berdampak

terhadap penghematan biaya.

Balance of conflicting requirements

Setiap pengguna atau departemen memiliki

kebutuhan-kebutuhan yang memungkinkan terjadinya

konflik terhadap kebutuhan dari pengguna lainnya. Karena

basis data dikendalikan DBA, maka DBA dapat membuat

keputusan tentang perancangan dan operasional dari basis

data. Keputusan yang dihasilkan akan mendukung

performa yang optimal pada aplikasi tersebut.

10.

Improved data accessibility and responsiveness

Sebagai dampak dari integrasi, data dapat diakses

secara langsung oleh

end user

melalui batasan antar

departemen.

11.

Increased productivity

DBMS menyediakan berbagai fungsi standar yang

memungkinkan programmer

untuk berkonsentrasi pada

fungsionalitas spesifik yang dibutuhkan oleh user

tanpa

harus

mengkhawatirkan rincian low-level implementation.

Hal ini meningkatkan produktivitas

dari programmer dan

mengurangi waktu pengembangan serta efisiensi terhadap

biaya.

12.

Improved maintenance through data independence

Deskripsi dari data dan logika yang digunakan untuk

mengakses data

antar

aplikasi satu sama lainnya,

menyebabkan program tergantung dengan data. DBMS

memisahkan deskripsi data dari aplikasi sehingga

menghilangkan ketergantungan.

13.

Increased concurrency

Dalam basis data, jika terdapat dua atau lebih

pengguna mengakses data yang sama secara bersamaan,

maka akan mengakibatkan terjadinya kehilangan

informasi atau kehilangan integritas. DBMS mengelola

akses konkurensi basis data dan meyakinkan agar masalah

pengaksesan data tersebut tidak terjadi.

14.

Improved backup and recovery services

File-based systems menyediakan batasan dan ukuran

untuk melindungi data dari kegagalan sistem operasi

maupun program aplikasi melalui layanan backup

dan

recovery.

2.2.3 Kerugian DBMS

Menurut Connolly dan Begg (2010, p80-81),

terdapat 7

kerugian dari penggunaan DBMS yaitu:

Complexity

Ketentuan yang diharapkan dari fungsionalitas

DBMS yang baik, menjadikannya sebagai perangkat lunak

dengan kompleksitas yang sangat tinggi.

Size

Karena kompleksitas dan kedalaman dari

fungsionalitas, DBMS memerlukan kapasitas

penyimpanan yang besar.

Cost of DBMS

Variasi dari biaya DBMS secara signifikan

bergantung pada lingkungan dan fungsionalitas yang

tersedia.

Additional hardware costs

Kapasitas penyimpanan yang dibutuhkan DBMS dan

basis data menyebabkan pembelian kapasitas

penyimpanan tambahan.

Cost of conversion

Biaya yang dibutuhkan DBMS dan

perangkat keras

tambahan dibandingkan dengan biaya konversi aplikasi

yang telah ada sebelumnya untuk menjalankan DBMS dan

perangkat keras yang baru.

Performance

DBMS digunakan untuk melayani lebih dari satu

aplikasi, sehingga

tidak memiliki performa yang

sebagaimana mestinya.

Greater impact of a failure

Sentralisasi dari sumber daya meningkatkan

kerentanan dari sebuah sistem dikarenakan semua

pengguna dan aplikasi bergantung pada DBMS.

2.2.4 Fungsi DBMS

Menurut Connolly dan Begg (2010, p100-104), fungsi-

fungsi yang terdapat pada

Database Management System

(DBMS) meliputi:

Data storage, retrieval, dan update

DBMS harus menyediakan kemampuan untuk

melakukan store, retrieve, dan update data terhadap basis

data bagi pengguna.

A user-accesible catalog

DBMS harus menyediakan sebuah catalog

yang

mendeskripsikan

data items

yang disimpan dan

diakses

oleh pengguna.

Transaction support

DBMS harus menyediakan

mekanisme yang

memastikan bahwa seluruh updates

dari transaksi yang

diberikan berhasil dibuat atau tidak ada

transaksi yang

dibuat.

Concurrency control services

DBMS harus menyediakan mekanisme

yang

memastikan bahwa basis data di-update dengan benar jika

beberapa pengguna melakukan update

basis data secara

bersamaan.

Recovery services

DBMS harus menyediakan mekanisme

pengembalian basis data jika mengalami kerusakan.

Authorization services

DBMS harus menyediakan mekanisme agar hanya

pengguna

berwenang

yang dapat melakukan akses pada

basis data.

Support for communication data

DBMS harus mampu

diintegrasikan dengan

perangkat lunak komunikasi.

Integrity services

DBMS harus menyediakan sarana agar seluruh data

dan perubahan data di dalamnya mengikuti aturan tertentu.

Services to promote data independence

DBMS harus mencakup fasilitas yang mendukung

independence programs dari struktur aktual basis data.

10.

Utility services

DBMS harus menyediakan utility services

tertentu,

contohnya:

Fasilitas import untuk load basis data dari flat files, dan

sebaliknya fasilitas export

untuk unload

basis data

kepada flat files.

Fasilitas monitoring

untuk mengawasi penggunaan dan

operasi basis data.

Statistical analysis programs

untuk memeriksa kinerja

dan statistik pemakaian.

Fasilitas index reorganization untuk merombak indexes

dan overflow.

Garbage collection dan reallocation

untuk menghapus

records secara fisik dari storage devices, konsolidasi

terhadap space released, dan alokasi

kembali

saat

dibutuhkan.

2.2.5 Fasilitas yang terdapat di DBMS

Menurut Connolly dan Begg (2010,

p66),

secara khusus,

sebuah DBMS menyediakan fasilitas-fasilitas sebagai berikut:

Memperbolehkan pengguna untuk melakukan definisi

terhadap basis data, umumnya melalui Data Definition

Language

(DDL). DDL memungkinkan pengguna

melakukan spesifikasi terhadap tipe-tipe data dengan

struktur beserta constraints

dari data tersebut untuk

disimpan ke dalam basis data.

Memperbolehkan pengguna untuk melakukan insert,

update, delete dan retrieve data dari basis data, umumnya

melalui Data Manipulation Language

(DML). Memiliki

central repository terhadap seluruh data dan deskripsinya

yang memungkinkan DML untuk menyediakan fasilitas

general inquiry

terhadap data tersebut yang dikenal

sebagai query language.

Menyediakan akses kontrol terhadap basis data sebagai

berikut:

Sistem keamanan yang mencegah pengguna tidak

berwewenang melakukan akses terhadap basis data.

Sistem integritas yang mengelola konsistensi data yang

disimpan.

Sistem pengendalian konkurensi yang mengijinkan

berbagi akses basis data.

Sistem pengendalian pemulihan yang melakukan

restorasi basis data terhadap kondisi sebelumnya

terkait kegagalan perangkat lunak maupun perangkat

keras.

User-accessible catalog yang berisi deskripsi-deskripsi

data di dalam basis data.

2.3 Database System Development Lifecycle

Menurut Connolly dan Begg (2010, p313), tahapan-tahapan

yang terdapat di dalam Database System Development

Lifecycle

adalah sebagai berikut:

Gambar 2.1 Tahapan-tahapan dari DBLC

(Sumber: Connolly dan Begg, 2010, p314)

2.3.1 Database Planning

Menurut Connolly dan Begg (2010, p313-315),

Database

Planning (Perancangan Basis Data) adalah aktivitas manajemen

dengan tahapan-tahapan pengembangan sistem basis data untuk

direalisasikan secara efektif dan efisien. Perencanaan basis data

harus diintegrasikan dengan keseluruhan strategi sistem

informasi dari organisasi.

Terdapat 3 masalah utama dalam merumuskan sistem

informasi, yaitu:

Mengidentifikasikan rencana dan tujuan perusahaan

dengan menentukan kebutuhan berikutnya dari sistem

informasi.

Melakukan evaluasi terhadap sistem informasi untuk

menjelaskan kelebihan dan kekurangan yang ada saat ini.

Melakukan penilaian dari kesempatan-kesempatan

teknologi informasi yang memungkinkan dihasilkannya

keuntungan kompetitif.

Tahap pertama yang penting dalam perencanaan basis data

adalah mendefinisikan secara jelas mission statement

untuk

sistem basis data. Mission statement menjelaskan tujuan utama

dari sistem basis data tersebut. Jika mission statement

sudah

didefinisikan, tahap selanjutnya adalah mengidentifikasikan

mission objectives. Setiap mission objectives harus

mengidentifikasikan tugas-tugas tertentu yang mendukung

sistem basis data.

2.3.2 System Definition

Menurut Connolly dan Begg (2010,

p316), System

Definition

adalah

menjelaskan ruang lingkup, batasan-batasan

dari sistem basis data dan major user view. User view

tersebut

mendefinisikan apa yang dibutuhkan oleh sebuah sistem basis

data dari berbagai perspektif bagian pekerjaan (contoh manager,

supervisor) atau area aplikasi perusahaan (contoh marketing,

stock control).

Sebelum mencoba untuk merancang sistem basis data, hal

pokok pertama yang diperlukan adalah melakukan identifikasi

terhadap batasan-batasan dari sistem yang sedang diteliti dan

bagaimana interface memiliki relevansi dengan bagian lain dari

sistem informasi organisasi tersebut. System definition

sangat

penting dimana batasan-batasan pada sistem tidak hanya terbatas

pada pengguna maupun aplikasi untuk saat ini, tetapi turut

dihadapkan kepada pengguna dan aplikasi pada masa yang akan

datang.

Sebuah sistem basis data dapat memiliki satu atau lebih

user views. Identifikasi terhadap user view merupakan bagian

yang penting karena memastikan bahwa tidak ada pengguna

yang terlupakan dalam pengembangan sistem basis data

tersebut. User view

mendefinisikan apa yang diperlukan dari

sebuah sistem basis data dengan

ketentuan dari data dan

transaksi yang ditampilkan. Kebutuhan-kebutuhan daripada user

view membedakan antara sudut pandang yang ada maupun yang

tumpang tindih terhadap satu sama lainnya.

2.3.3 Requirement Collection and Analysis

Menurut Connolly dan Begg

(2010,

p316-319),

Requirement Collection and Analysis adalah

proses

pengumpulan dan analisis informasi terhadap bagian dari suatu

organisasi yang didukung dengan sistem basis data dan

menggunakan informasi tersebut untuk mengidentifikasi

kebutuhan-kebutuhan yang akan digunakan pada sistem baru.

Tahapan-tahapan ini melibatkan pengumpulan dan analisis

informasi mengenai bagian perusahaan yang didukung oleh

teknologi basis data. Terdapat beberapa teknik dalam

pengumpulan informasi melalui metode fact finding. Informasi

dikumpulkan dengan tujuan untuk setiap major user view

yang

meliputi deskripsi data, rincian penggunaan data dan tambahan

kebutuhan untuk sistem basis data baru. Informasi yang telah

dikumpulkan tersebut kemudian dianalisa untuk

mengidentifikasikan kebutuhan-kebutuhan yang akan

dimasukkan ke dalam sistem basis data baru sebagai

requirements specifications.

Beberapa contoh requirements specifications techniques

meliputi Structured Analysis and Design (SAD) techniques,

Data Flow Diagrams (DFD),

dan Hierarchical Input Process

Output (HIPO) charts supported by documentation. Aktivitas

penting lainnya yang terkait pada tahapan ini adalah

menentukan bagaimana menghadapi situasi dimana terdapat

lebih dari satu sudut pandang pengguna pada sistem basis data.

Terdapat tiga pendekatan utama dalam mengelola kebutuhan-

kebutuhan sistem basis data, yaitu:

The centralized approach

Kebutuhan-kebutuhan setiap user view digabungkan

menjadi sekumpulan kebutuhan sistem basis data baru.

Sebuah model data mewakili seluruh user views

yang

dibuat selama tahapan perancangan basis data.

The view integration approach

Kebutuhan-kebutuhan setiap user view tersisa

sebagai daftar terpisah. Model data mewakili setiap user

view

yang dibuat dan kemudian digabungkan setelahnya

selama tahapan perancangan basis data.

A combination of both approaches

Merupakan penggabungan kedua pendekatan diatas

yang digunakan pada sistem basis data yang bersifat

kompleks.

2.3.4 Database Design

Menurut Connolly dan Begg (2010, p320-322), Database

Design adalah proses perancangan yang mendukung sasaran dan

tujuan dari perusahaan terhadap sistem basis data yang

diperlukan. Terdapat 2 pendekatan utama dalam perancangan

basis data yang meliputi:

Pendekatan bottom-up

Pendekatan yang dimulai pada level fundamental

dari atribut-atribut yang meliputi properties of entities dan

relationship

melalui analisis antar atribut dan

dikelompokkan kedalam relasi yang mewakili tipe-tipe

entitas serta hubungan antar entitas. Pendekatan bottom-up

ini baik digunakan untuk perancangan basis data

sederhana dengan jumlah atribut yang relatif sedikit.

Pendekatan top-down

Pendekatan yang dimulai dengan membangun

model-model data yang berisikan beberapa high level

entities

dan relationship

yang diaplikasikan secara top-

down disertai dengan perbaikan-perbaikan untuk

mengidentifikasikan lower level entities, relationships dan

associated attributes. Pendekatan top-down

ini

menggambarkan penggunaan konsep dari Entity

Relationship

(ER) model yang dimulai dengan

mengidentifikasikan entitas dan hubungan antar entitas.

Pada tahapan ini, terdapat data modeling yang berfungsi

sebagai bantuan dalam memahami pengertian (semantik) dari

data serta merupakan fasilitas komunikasi terhadap informasi

yang dibutuhkan. Pemahaman yang diperoleh melalui

penggunaan data model adalah:

a. Perspektif dari data setiap pengguna

Kealamian dari data tersebut, kebebasan representasi

fisiknya

c. Penggunaan data berdasarkan sudut pandang pengguna

Kriteria yang diperlukan untuk memperoleh model data

yang optimal yaitu:

Structural validity

Konsistensi melalui cara yang telah ditentukan oleh

perusahaan dan informasi dari suatu organisasi.

Simplicity

Kemudahan pemahaman yang ditujukan kepada

information system professionals dan non-technical users.

Expressibility

Kemampuan untuk membedakan antar data yang

berbeda, hubungan dan batasan-batasan yang terdapat

pada data tersebut.

Non redundancy

Pengecualian terhadap informasi yang berlebihan.

Representasi dari suatu informasi tepatnya hanya satu kali.

Shareability

Tidak memiliki batasan yang spesifik terhadap

aplikasi dan teknologi tertentu sehingga dapat digunakan

oleh banyak user.

Extensibility

Kemampuan evolusi yang mendukung kebutuhan-

kebutuhan baru dengan dampak minimalis yang berasal

dari pengguna.

Integrity

Konsistensi terhadap cara dan batasan yang

digunakan perusahaan dalam mengatur informasi.

Diagrammatic representation

Kemampuan untuk merepresentasikan sebuah model

menggunakan diagrammatic notation

yang mudah

dipahami.

Pendekatan lainnya di dalam

perancangan basis data

adalah pendekatan inside-out

dan pendekatan the mixed

strategy. Pendekatan inside-out

memiliki relevansi dengan

pendekatan bottom-up namun dibedakan berdasarkan

identifikasi yang dimulai dengan sekumpulan entitas utama dan

dilanjutkan terhadap entitas lainnya, hubungan-hubungan dan

atribut terkait entitas yang telah teridentifikasi sebelumnya.

Sementara pendekatan the mixed strategy menggunakan

penggabungan dua pendekatan antara bottom-up dengan top-

down pada beberapa bagian-bagian model sebelum disatukan

secara keseluruhan.

Menurut Connolly dan Begg (2010,

p466-468), Design

Methodology

adalah pendekatan terstruktur yang menggunakan

procedures, techniques, tools

dan documentation aids

untuk

mendukung dan memfasilitasi proses perancangan.

Metodologi perancangan terdiri dari tahapan yang masing-

masing berisikan sejumlah langkah panduan bagi perancang

baik dalam perencanaan, pengaturan, kontrol, dan evaluasi

terhadap pengembangan basis data. Dalam merepresentasikan

basis data, proses perancangan dikelompokkan dalam tiga

tahapan utama yaitu conceptual, logical, dan physical database

design. Langkah-langkah yang ada pada ketiga tahapan utama

tersebut meliputi:

Conceptual database design

Step 1: Build conceptual data model

Step 1.1

Identify entity types

Step 1.2

Identify relationship types

Step 1.3

Identify and associate attributes with entity

or relationship types

Step 1.4

Determine attribute domains

Step 1.5

Determine candidate, primary, and

alternate key attributes

Step 1.6

Consider use of enhanced modeling

concepts (optional step)

Step 1.7

Check model for redundancy

Step 1.8

Validate conceptual data model

againts

user transactions

Step 1.9

Review conceptual data model with user

Logical database design

Step 2: Build and validate logical data model

Step 2.1

Derive relations for logical data model

Step 2.2

Validate relations using normalization

Step 2.3

Validate relations against user transactions

Step 2.4

Check integrity constraints

Step 2.5

Review logical data model with user

Step 2.6

Merge logical data models into global

model (optional step)

Step 2.7

Check for future growth

Physical database design

Step 3: Translate logical data model for target DBMS

Step 3.1

Design base relations

Step 3.2

Design representation of derived data

Step 3.3

Design general constraints

Step 4: Design file organizations and indexes

Step 4.1

Analyze transactions

Step 4.2

Choose file organizations

Step 4.3

Choose indexes

Step 4.4

Estimate disk space requirements

Step 5: Design user views

Step 6: Design security mechanisms

Step 7: Consider the introduction of controlled redundancy

Step 8: Monitor and tune the operational system

2.3.4.1 Conceptual Database Design

Proses membangun sebuah data model yang

digunakan oleh perusahaan, bersifat independent

terhadap seluruh pertimbangan fisikal yang ada. Pada

tahapan ini, perancangan dimulai dengan membuat

model data konseptual dari perusahaan terhadap rincian

implementasi seperti target

DBMS,

application

programs, programming languages,

hardware

platform,

performance issues, atau physical

consideration

lainnya. Langkah-langkah yang terdapat

dalam conceptual database design adalah:

Identify entity types

Bertujuan untuk mengidentifikasi tipe entitas

dan objek utama yang dibutuhkan sesuai dengan

kebutuhan user. Salah satu metode yang digunakan

untuk identifikasi entitas adalah dengan memeriksa

users requirements specification.

Melalui

spesifikasi ini, dilakukan identifikasi terhadap

nouns

atau noun phrases

yang disebutkan

(misalnya:

staff number,

staff name,

property

number,

property address,

rent, number of rooms)

serta turut memperhatikan objek utama lainnya

yaitu people, places atau concepts of interest diluar

noun lain sebagai kualitas objek lainnya.

Identify relationship types

Bertujuan untuk mengidentifikasi important

relationships yang muncul antar tipe entitas dengan

melakukan beberapa hal

yaitu menggunakan Entity

Relationship (ER) diagrams, menentukan

multiplicity constraints dari relationship types

yang

ada, memeriksa fan

dan chasm traps

serta

mendokumentasikan relationship types tersebut.

Identify

and associate attributes with entity or

relationship types

Bertujuan untuk menghubungkan atribut-

atribut terkait dengan entitas atau tipe yang telah

disesuaikan. Terdapat beberapa macam atribut yaitu

simple atau composite attributes, single atau

multi-

valued attributes, dan derived attributes.

Determine attribute domains

Bertujuan untuk menentukan domain

dari

attributes

yang terdapat pada model data

konseptual serta melakukan dokumentasi terhadap

setiap rinciannya. Domain

merupakan sekumpulan

nilai dari satu atau lebih atribut yang

menggambarkan nilainya.

Determine candidate, primary, and alternate key

attributes

Bertujuan untuk mengidentifikasi candidate

keys setiap entitas dan memilih sebuah primary key

sebagai simbolik yang unik dari beberapa candidate

yang tersedia, turut mengelompokkan alternate

keys lainnya.

Consider use of enhanced modeling concepts

(optional step)

Bertujuan untuk mempertimbangkan

penggunaan dari modeling concepts

semisal

specialization atau generalization, aggregation, dan

composition.

Pada tahap ini, pengembangan

terhadap ER model dilakukan dengan menggunakan

beberapa konsep modeling yang tersedia.

Check model for redundancy

Bertujuan untuk memeriksa redundansi pada

model dengan objek spesifik dan menghilangkan

keberadaannya. Terdapat 3 aktivitas pada langkah

ini yaitu:

Memeriksa hubungan one-to-one

(1:1)

relationships

Menghilangkan redundansi relationships

Mempertimbangkan dimensi waktu

Validate conceptual data model against user

transactions

Bertujuan untuk memastikan bahwa

conceptual data model

mendukung transaksi-

transaksi yang diperlukan. Dua

pendekatan yang

digunakan sebagai berikut:

Menjelaskan transaksi-transaksi

Menggunakan jalur transaksi

Review conceptual data model with user

Bertujuan untuk melakukan review

pada

conceptual data model

terhadap user

sekaligus

meyakinkan pertimbangan

model tersebut sebagai

representasi sebenarnya

terhadap kebutuhan data

suatu perusahaan. Apabila ditemukan adanya

anomali data,

maka dilakukan perbaikan yang

diperlukan

dan disesuaikan

dengan pengulangan

atas langkah-langkah yang ada.

2.3.4.2 Logical Database Design

Proses membangun sebuah data model yang

digunakan perusahaan berdasarkan sebuah spesifik

model data, tetapi independent

terhadap particular

DBMS dan physical consideration lainnya dengan

tujuan menterjemahkan conceptual data model

dalam logical data model, lalu

divalidasikan untuk

memeriksa kebenarannya

agar mampu mendukung

transaksi yang diperlukan.

Langkah-langkah yang

terdapat dalam logical database design adalah:

Derive relations for logical data model

Bertujuan untuk membangun relasi

logical

data model

yang merepresentasikan entitas, relasi,

dan atribut yang telah teridentifikasi.

Relasi yang

diturunkan dari conceptual data model meliputi:

Strong entity types

Weak entity types

One-to-many (1:*) binary relationship types

One-to-one (1:1) binary relationship types:

Mandatory participation on both sides of

1:1 relationship

Mandatory participation on one sides of

1:1 relationship

Optional participation on both sides of

1:1 relationship

e. One-to-one (1:1) recursive relationship types

f. Superclass/subclass relationship types

Many-to-many (*:*) binary relationship

types

Complex relationship types

i. Multi-valued attributes

Tabel 2.1 Pemetaan dari Entities dan Relationships

Entity/Relationship

Mapping

Strong entity

Membuat suatu relasi yang

menyertakan keseluruhan simple

attributes.

Weak entiy

Membuat suatu relasi yang

menyertakan keseluruhan simple

attributes

(kemudian harus

dilakukan identifikasi terhadap

primary key setelah dilakukan

mapping hubungan dengan setiap

owner entity).

1:* binary relationship

Menyertakan primary key

dari

suatu entitas pada sisi “one” yang

bertindak sebagai foreign key

relasi yang mempresentasikan

entitas pada sisi “many”. Atribut

daripada relasi juga disertakan pada

sisi “many”.

1:1 binary relationship

(a) Mandatory participation on

both sides

(b) Mandatory participation on

one side

(c)

Optional participation on one

side

Menggabungkan entitas-entitas ke

dalam satu relasi.

Menyertakan primary key entitas

pada sisi “optional” sebagai suatu

entitas yang merepresentasikan

entitas pada sisi “mandatory”.

Tidak beraturan dengan tanpa

further information.

Superclass/subclass relationship

Lihat pada table 2.2

Entity/Relationship

Mapping

*:* binary relationship, Complex

relationship

Membuat representasi relasi yang

menghubungkan dan termasuk di

dalamnya atribut yang terdapat di

relationship

tersebut. Menyertakan

duplikat primary keys

dari setiap

owner entities ke dalam suatu relasi

baru sebagai foreign keys.

Multi-valued attribute

Merepresentasikan sebuah

ketergantungan antar atribut dalam

suatu relasi, sehingga untuk setiap

nilai A terdapat satu set nilai untuk

B dan satu set nilai untuk C.

Namun, set nilai untuk B dan C

yang independen satu sama lain.

Tabel 2.2 Representasi dari Subclass/Relationships

Participation

Constraint

Disjoint Constraint

Relations Required

Mandatory

Nondisjoint {And}

Relasi tunggal (dimana

terdapat satu atau lebih

discriminators

untuk

membedakan tipe setiap

tuple).

Optional

Nondisjoint {And}

Dua relasi: satu relasi

untuk superclass

dan satu

relasi untuk seluruh

subclasses, (terdapat satu

atau lebih discriminators

untuk membedakan tipe

setiap tuple).

Mandatory

Disjoint {Or}

Banyak relasi: satu relasi

yang ditujukan untuk

kombinasi yang terdapat

dari superclass/subclass.

Optional

Disjoint {Or}

Banyak relasi: satu relasi

ditujukan pada superclass

dan satu untuk masing-

masing subclass.

Validate relations using normalization

Bertujuan untuk melakukan validasi atas

relasi yang terdapat pada logical data model

dengan menggunakan teknik normalisasi.

Penggunaan teknik tersebut diperlukan untuk

mengidentifikasi ketergantungan fungsional antar

atribut setiap relasi yang melalui beberapa langkah

dalam menentukan komposisi atribut

suatu relasi,

yaitu 1NF, 2NF, dan 3NF, dst. Untuk menghindari

redundansi data, disarankan agar setiap relasi

sekurang-kurangnya mencapai hingga 3NF.

Validate relations against user transactions

Bertujuan untuk memastikan bahwa relasi di

dalam logical data model

dapat mendukung

transaksi-transaksi yang diperlukan sesuai dengan

spesifikasi kebutuhan user.

Check integrity constraints

Bertujuan untuk memeriksa integrity

constraints yang direpresentasikan di dalam logical

data model. Beberapa tipe dari integrity constraints

yang menjadi pertimbangan adalah:

Required data

Terdapat beberapa atribut yang

seharusnya memiliki nilai valid

atau tidak

boleh null.

Atribute domain constraints

Setiap atribut memiliki sebuah domain

yang berupa kumpulan dari nilai yang

memenuhi persyaratan-persyaratan.

Multiplicity

Merepresentasikan batasan jumlah

yang terdapat pada hubungan antara data

yang satu dengan data lainnya di dalam basis

data.

Entity integrity

Primary key yang terdapat pada sebuah

entitas tidak boleh bernilai null.

Referential integrity

Sebuah foreign key

menghubungkan

setiap tuple di dalam child relation

dengan

tuple di dalam parent relation

yang berisikan

nilai candidate key yang bersesuaian.

General constraints

Batasan-batasan umum dimana updates

di dalam suatu entitas ditentukan

berdasarakan representasi yang berasal dari

real worlds.

Review logical data model with user

Bertujuan untuk melakukan review terhadap

logical data model dengan user untuk meyakinkan

bahwa model yang menjadi pertimbangan

merepresentasikan data yang sebenarnya sesuai

dengan kebutuhan perusahaan. Sebelum memasuki

tahap selanjutnya, terdapat hubungan antara logical

data model

dengan data flow diagrams

mengikuti

ketentuan sebagai berikut:

Setiap data yang disimpan harus

merepresentasikan seluruh jumlah entitas

Atribut-atribut pada data flows harus mengacu

kepada tipe entitas

Merge logical data models into global model

(optional step)

Bertujuan untuk mengabungkan logical data

model yang merepresentasikan satu atau lebih

tetapi tidak seluruh sudut pandang pengguna ke

dalam sebuah global logical data model

yang

merepresentasikan sebaliknya. Aktivitas yang

terdapat di dalam tahap ini adalah:

Menggabungkan local

logical data model ke

dalam global logical data model

Melakukan validasi terhadap global logical

data model

Melakukan review

global logical data model

dengan user

Check for future growth

Bertujuan untuk menentukan perubahan yang

diperlukan pada masa mendatang dan menilai

apakah logical data model

dapat menyesuaikan

terhadap perubahan yang terjadi.

2.3.4.3 Physical Database Design

Proses menghasilkan sebuah deskripsi mengenai

implementasi dari basis data pada secondary storage

yang menjelaskan base relations, file organizations, dan

indexes yang digunakan untuk memperoleh akses

efisien terhadap data dengan integrity constraints terkait

serta security measures. Pada tahapan ini, designer

diperbolehkan untuk memilih bagaimana basis data

akan diimplementasikan sekaligus DBMS spesifik yang

akan digunakan. Langkah-langkah yang terdapat dalam

physical database design adalah:

Translate logical data model for target DBMS

Design base relations

Bertujuan untuk menentukan representasi

base relations

teridentifikasi di dalam logical

data model terhadap target DBMS.

Design representation of derived data

Bertujuan untuk menentukan representasi

dari derived data yang ditampilkan pada logical

data model terhadap target DBMS.

Design general constraints

Bertujuan untuk merancang general

constraints terhadap target DBMS.

Design file organizations and indexes

Bertujuan untuk mengoptimalkan file

organizations untuk menyimpan base relations dan

indexes yang diperlukan agar memperoleh kinerja

maksimal. Terdapat beberapa aktivitas pada tahap

ini, sebagai berikut:

Analyze transactions

Bertujuan untuk memahami

fungsionalitas dari transaksi yang akan

dijalankan pada basis data untuk menganalisis

transaksi yang bersifat penting.

Choose file organizations

Bertujuan untuk menentukan efisiensi file

organizations terhadap base relations.

Choose indexes

Bertujuan untuk menentukan penambahan

indexes yang akan meningkatkan kinerja dari

sistem.

Estimate disk space requirements

Bertujuan untuk melakukan estimasi

kapasitas penyimpanan pada disk yang

dibutuhkan oleh basis data.

Design user views

Bertujuan untuk merancang user view

yang

diidentifikasikan selama requirements collection

dan analysis stage

dari Database System

Development Lifecycle.

Design security mechanisms

Bertujuan untuk merancang mekanisme

keamanan basis data yang disesuaikan selama

tahapan requirements dan collection

pada

Database System Development Lifecycle.

Consider the introduction of controlled

redundancy

Bertujuan untuk menentukan introduction of

controlled redundancy

(mengikuti ketentuan

normalisasi) yang digunakan agar sistem

memberikan performa terbaik.

Monitor and tune the operational system

Bertujuan untuk melakukan monitorisasi

pada sistem operasional dan meningkatkan

performa sistem guna memperbaiki pengambilan

keputusan yang tidak tepat sekaligus refleksi

terhadap perubahan persyaratan.

2.3.5 DBMS Selection

Menurut Connolly dan Begg (2010,

p325-329), DBMS

Selection adalah

seleksi terhadap DBMS yang tepat untuk

mendukung sistem basis data. Terdapat beberapa langkah-

langkah utama dalam melakukan seleksi DBMS yaitu:

Define terms of reference of study

Merujuk kepada ketentuan dalam memilih DBMS,

menyatakan tujuan dan ruang lingkup dari pembelajaran

dan kegiatan yang perlu dilakukan. Dokumen terkait

termasuk deskripsi mengenai kriteria yang didasarkan

kepada user requirements

digunakan sebagai evaluasi

terhadap produk DBMS.

Shortlist two or three products

Pertimbangan dalam pengambilan keputusan

terhadap produk DBMS mengacu kepada budget

available, level of vendor support, compatibility

dengan

perangkat lunak lainnya yang menjadi tolak ukur untuk

melakukan komparasi antara kinerja dari produk-produk

DBMS.

Evaluate products

Terdapat beberapa fitur yang digunakan untuk

mengevaluasi produk DBMS dan dikategorikan

berdasarkan data definition, physical definition,

accessibility, transaction handling, utilities, development

dan fitur lainnya.

Recommend selection and produce report

Langkah terakhir dari pemilihan DBMS adalah

dokumentasi proses dan menyediakan saran perbaikan

untuk produk DBMS.

2.3.6 Application Design

Menurut Connolly dan Begg (2010,

p329-333),

Application Design adalah

perancangan user interface

dan

program-program aplikasi yang digunakan serta diproses pada

basis data. Terdapat dua aspek dari perancangan aplikasi yaitu:

Transaction design

Transaction adalah suatu kegiatan maupun

sekumpulan kegiatan

oleh single user

atau program

aplikasi yang mengubah dan mengakses isi dari basis data.

Tujuan dari transaction design

adalah

menjelaskan dan

mendokumentasikan high-level characteristics

yang

diperlukan dalam transaksi basis data meliputi:

Data yang digunakan untuk transaksi

Karakteristik fungsional dari transaksi

Output dari transaksi

Pentingnya untuk pengguna

Tingkat penggunaan

Aktivitas ini seharusnya dihadirkan sejak awal pada

proses perancangan untuk meyakinkan bahwa

implementasi terhadap basis data menunjang seluruh

transaksi yang dibutuhkan. Terdapat 3 jenis

transaksi

utama, yaitu:

Retrieval transactions

Digunakan dalam pengambilan data untuk

ditampilkan pada layar atau sebagai laporan.

Contoh: retrieval transaction sebagai operasi untuk

mencari dan menampilkan rincian data lengkap dari

property jika diberikan property number.

Update transaction

Digunakan untuk menambahkan data baru,

menghapus data lama, atau memodifikasi data yang

telah ada

di dalam basis data. Contoh: update

transaction

sebagai operasi untuk menambahkan

property baru ke dalam basis data.

Mixed transaction

Mixed transaction adalah penggabungan

yang

melibatkan retrieval transaction

dan update

transaction data. Contoh: mixed transaction sebagai

operasi untuk mencari dan menampilkan data

lengkap mengenai suatu property

yang diberikan

property

number

dan kemudian dilakukan

modifikasi terhadap nilai sewa bulanan.

User interface design

Sebelum sebuah form

atau report

diimplementasikan,

merancang tata letak merupakan hal

penting dalam permulaan. Menurut Shneiderman dan

Plaisant (2004), pedoman-pedoman yang digunakan

untuk

merancang form atau report adalah sebagai berikut:

Meaningful title

Informasi yang disampaikan oleh

judul harus

jelas dan tidak ambigu dalam mendefinisikan tujuan

dari form atau report.

Comprehensible instructions

Terminologi yang

familiar

harus digunakan

untuk menyampaikan instruksi-instruksi kepada

user. Intruksi tersebut harus jelas, menggunakan

grammar yang konsisten dengan mengikuti prosedur

standar.

Logical grouping and sequencing of fields

Field-field yang berhubungan harus diletakkan

bersamaan pada form atau report. Urutan dari field-

field tersebut harus konsisten dan bersifat logikal.

Visually appealing layout of the form or report

Form atau report harus menampilkan interface

yang menarik kepada user serta seimbang, tepat dan

konsisten.

Familiar field labels

Nama field harus mudah dikenali. Contoh: jika

sex

diganti dengan gender

tentunya akan

membingungkan bagi user tertentu.

Consistent terminology and abbrevitions

Penggunaan istilah-istilah dan singkatan harus

konsisten.

Consistent use of color

Warna harus dapat memberikan improvisasi

terhadap penampilan dari sebuah form

atau

report

dan menekankan fields

atau informasi penting

lainnya. Untuk mencapai tujuan tersebut,

penggunaan dari warna harus konsisten dan

bermakna. Contoh: fields pada sebuah form dengan

latar belakang warna putih dapat mengindikasikan

data entry fields, sedangkan warna biru

mengindikasikan display-only fields.

Visible space and boundaries for data-entry fields

User harus peka terhadap visualisasi kapasitas

yang tersedia untuk setiap kapasitas field

sekaligus

memperbolehkan user

untuk mempertimbangkan

format yang tepat sebelum memasukkan nilai ke

dalam field tersebut.

Convenient cursor movement

User

harus dengan mudah mengidentifikasi

operasi yang dibutuhkan untuk menggerakan kursor

pada form

atau report

dengan mekanisme tab key,

arrows, dan mouse pointer.

Error correction for individual characters and entire

fields

User

harus dengan mudah mengidentifikasi

operasi yang dibutuhkan untuk melakukan

alterations

terhadap nilai field

menggunakan

mekanisme sederhana backspace key

atau

overtyping.

Error messages for unacceptable values

Jika user mencoba mencoba memasukkan data

yang salah ke sebuah field,

maka

pesan

kesalahan

akan ditampilkan. Pesan tersebut menginformasikan

kepada pengguna tentang kesalahan dan indikasi

nilai akses. Contoh: jika terdapat field username dan

password yang dilanjutkan dengan

menekan tombol

submit

sementara field

tidak diisi maka akan

ditampilkan pesan error “username harus diisi”.

Optional fields marked clearly

Optional fields

harus dapat diidentifikasikan

oleh pengguna secara jelas melalui pendekatan field

label atau dengan menampilkan field

menggunakan

warna yang mengindikasikan tipe dari field tersebut.

Explanatory messages for fields

Ketika user

meletakkan kursor pada field,

informasi mengenainya harus muncul pada posisi

reguler layar seperti window status bar.

Completion signal

Harus jelas ketika proses pengisian form yang

dilakukan user telah selesai. Bagaimanapun, pilihan

proses selesai tidak bersifat otomatis sehingga

pengguna dapat melakukan review

terhadap data

yang telah dimasukkan.

2.3.7 Prototyping

Menurut Connolly dan Begg (2010,

p333), Prototyping

adalah

membuat sebuah model kerja dari sistem basis data.

Sebuah prototype adalah sebuah model kerja yang biasanya

tidak mempunyai keseluruhan fitur atau menyediakan semua

fungsionalitas dari sistem akhir. Tujuan utama dari

pengembangan prototype

basis data adalah untuk

memperbolehkan user

menggunakan prototype sebagai

identifikasi terhadap fitur-fitur yang bekerja dan jika

memungkinkan memberikan saran perbaikan bahkan

penambahan fitur baru ke dalam sistem basis data. Terdapat 2

jenis prototype yang sering digunakan secara umum yaitu:

Requirement prototype

Prototype

ini digunakan untuk menjelaskan

kebutuhan-kebutuhan dari sistem basis data yang

diusulkan, ketika kebutuhan tercapai maka prototype akan

dibersihkan.

Evolutionary prototype

Prototype

ini digunakan dengan tujuan yang sama,

perbedaannya terletak pada proses dimana prototype tidak

dibuang, melainkan digunakan untuk pengembangan lebih

lanjut menjadi sistem basis data yang bekerja.

2.3.8 Implementation

Menurut Connolly dan Begg (2010,

p333),

Implementation

adalah realisasi fisik dari basis data dan design

application. Pada tahap ini, implementasi dari basis data

menggunakan DDL yang dipilih dari DBMS maupun GUI

dimana tersedia fungsionalitas yang sama dengan statements

DDL bersifat low level. Security

dan integrity control

untuk

sistem juga akan diimplementasikan. Beberapa dari kontrol-

kontrol

tersebut diimplementasikan menggunakan DDL

sementara sisanya menggunakan fungsi selain DDL semisal

utilities DBMS atau operating system control.

2.3.9 Data Convertion and Loading

Menurut Connolly dan Begg (2010,

p334), Data

Convertion and Loading adalah

memindahkan data-data yang

tersedia ke dalam basis data baru dan melakukan konversi

terhadap aplikasi-aplikasi yang ada agar dapat berjalan pada

basis data tersebut.

Tahap ini diperlukan ketika mengganti sistem yang lama

menjadi sistem basis data yang baru. DBMS mempunyai

fasilitas untuk memasukkan data yang telah ada ke dalam basis

data yang baru. Fasilitas ini membutuhkan

spesifikasi sumber

file

dan target basis data, kemudian konversi data akan

dilakukan secara otomatis.

2.3.10 Testing

Menurut Connolly dan Begg (2010, p334), Testing adalah

proses dari sistem basis data yang sedang berjalan dengan tujuan

untuk menemukan kesalahan yang terdapat pada sistem basis

data tersebut.

Di dalam perancangan basis data, user

daripada sistem

yang baru seharusnya dilibatkan dalam proses testing. Testing

turut mencakup beberapa usability dari sistem basis data sebagai

berikut:

Learnability : waktu yang diperlukan agar pengguna

menjadi produktif dengan sistem.

Performance : kecocokan antara system response terhadap

user’s work practice.

Robustness : tingkat toleransi sistem terhadap kesalahan

user.

Recoverability : kemampuan pemulihan sistem dari

kesalahan-kesalahan user.

Adaptability : kedekatan antara system tied dengan single

model of work.

2.3.11 Operational Maintenance

Menurut Connolly dan Begg (2010,

p335), Operational

Maintenance

adalah

proses pengawasan dan pemeliharaan

sistem basis data beserta instalasinya.

Pada tahap sebelumnya, sistem basis data telah

diimplementasikan dengan sukses dan teruji. Kemudian, sistem

bergerak maju menuju tahap pemeliharaan yang melibatkan

kegiatan-kegiatan sebagai berikut:

Melakukan pengawasan atau monitorisasi terhadap

performa dari sistem. Jika performa berada dibawah level

yang dapat diterima, maka dilakukan perbaikan atau

reorganization

terhadap basis data sesuai dengan

kebutuhan.

Melakukan pemeliharaan dan peningkatan sistem basis

data ketika diperlukan. Kebutuhan baru akan dimasukkan

kedalam sistem basis data melalui tahap-tahap yang telah

tersedia sebelumnya berdasarkan lifecycle.

2.4 Entity Relationship Modeling

Menurut Connolly dan Begg (2010, p371), Entity

Relationship

Modeling

adalah pendekatan top-down untuk perancangan basis data

yang dimulai dengan mengidentifikasikan data penting berupa entities

dan relationship

antara data yang harus diwakilkan dalam sebuah

model. Kemudian dilakukan penambahan rincian data berupa

informasi yang melengkapi entitites

dan relationship

yang disebut

attribute dan constraints.

2.4.1 Entity Types

Menurut Connolly dan Begg (2010, p372-374), Entity

Types

adalah sekelompok objek dengan properties sama yang

diidentifikasikan oleh perusahaan sebagai keberadaan yang

independent.

Representasi terhadap entity

types

digambarkan dalam

sebuah persegi yang berisi nama entity

dan isi entity. Pada

umumnya, nama entity

adalah kata benda tunggal. Penulisan

nama entity pada UML diawali dengan huruf kapital pada setiap

kata. Contoh entity types

adalah Employee,

PropertyForRent,

dll. Entity Types dibagi menjadi 2, yaitu:

Strong entity types

Tipe entitas yang tidak bergantung pada entitas lain.

Karakteristik dari tipe entitas kuat adalah entitas yang

termasuk dalam tipe entitas ini dapat diidentifikasikan

secara unik dari entitas lain dengan melihat attribute

primary key dari entitas tersebut.

Weak entity types

Tipe entitas yang bergantung pada entitas lain.

Karakteristik dari tipe entitas lemah adalah entitas yang

termasuk dalam tipe entitas ini tidak dapat

diidentifikasikan secara unik dengan hanya menggunakan

attribute dalam entitas tersebut.

2.4.2 Relationship Types

Menurut Connolly dan Begg (2010, p374), Relationship

Types

adalah sekumpulan set asosiasi antara beberapa entity

types. Setiap relationship type diberikan nama yang menjelaskan

fungsinya.

Representasi relasionship

type

digambarkan dengan

sebuah garis yang menghubungkan antar entitas. Contoh

relationship

type

adalah hubungan antara entitas Employee

dan

entitas Branch.

Setiap branch

memiliki employee. Sehingga

relationship types di antara kedua entitas tersebut adalah ‘has’.

Menurut Connolly dan Begg (2010, p375), Relationship

Occurrence

adalah sebuah hubungan yang unik termasuk satu

kejadian dari setiap entity type yang berpartisipasi di dalamnya.

Menurut Connolly dan Begg (2010, p376), Degree of

Relationship Type

adalah jumlah entitas yang ada dalam

relationship. Degree of relationship type dibagi menjadi

beberapa jenis yaitu:

Binary Relationship

Hubungan antara dua entitas.

Ternary Relationship

Hubungan antara tiga entitas.

Quaternary Relationship

Hubungan antara empat entitas.

Recursive Relationship

Menurut Connolly dan Begg (2010, p378),

Recursive Relationship

adalah sebuah hubungan dimana

entitas yang sama ikut serta dalam hubungan tersebut lebih

dari satu kali dengan peranan yang berbeda.

2.4.3 Attribute

Menurut Connolly dan Begg (2010, p379), Attribute

adalah property dari sebuah entity atau relationship type. Setiap

attribute

mempunyai nilai dari sekumpulan nilai yang disebut

domain. Domain

menjelaskan jenjang nilai yang dimiliki

attribute

dalam relational

model. Attribute

domain

adalah

sekumpulan nilai yang terdapat dalam satu atau lebih attribute.

Attribute

dapat diklasifikasikan ke dalam beberapa

kategori yaitu:

Simple and composite attributes

Simple attributes adalah attribute yang tersusun dari

single

component

dengan sebuah independent

existence.

Simple attribute tidak dapat dibagi atau dipecah ke dalam

komponen yang lebih kecil lagi. Simple attributes dikenal

juga dengan sebutan atomic

attributes. Contoh simple

attribute

adalah EmployeeID, EmployeeName

dari

Employee.

Composite attributes adalah sebuah atribut yang

tersusun dari multiple components, dimana setiap

komponennya memiliki sebuah independent existence.

Beberapa attributes

dapat dipecah atau dibagi ke dalam

komponen yang lebih kecil dan masing-masing komponen

memiliki independent existence sendiri. Contoh composite

attribute

adalah EmployeeFirstName

dan

EmployeeLastName yang didapat dari pecahan

EmployeeName.

Single-valued and multi-valued attributes

Single-valued attributes adalah sebuah atribut yang

memiliki single value untuk setiap occurrence dari sebuah

entity type. Contoh single-valued

attributes

adalah

EmployeeID. EmployeeID mempunyai satu nilai.

Multi-valued attributes adalah sebuah atribut yang

memiliki multiple value untuk setiap occurence

pada

sebuah entity type. Contoh multi-valued attributes

adalah

EmployeeSkills. EmployeeSkills

mempunyai satu atau

lebih nilai.

Derived attributes

Sebuah atribut yang merepresentasikan sebuah nilai

yang diturunkan dari nilai atribut terkait atau sekumpulan

atribut, yang tidak seharusnya berada pada entity type

yang sama. Contoh derived

attributes

adalah

EmployeeAge. EmployeeAge

didapatkan dari perhitungan

CurrentDate dan EmployeeBirthDate.

2.4.4 Keys

Menurut Connolly dan Begg (2010, p381-383), terdapat

beberapa jenis keys yang meliputi:

Candidate key

Set minimal dari atribut yang mengidentifikasikan

setiap occurence

dari sebuah entity type secara unik.

Candidate key merupakan kumpulan dari atribut minimal

yang dapat menjadi primary key. Contoh candidate

key

adalah EmployeeID, EmployeeName.

Primary key

Candidate key terpilih yang mengidentifikasikan

sebuah entity type secara unik. Setiap entity type

dapat

memiliki lebih dari satu candidate key. Pertimbangan

dalam memilih primary key

adalah berdasarkan attribute

length, minimal number of attributes required, dan future

certainty of uniqueness. Contoh primary

key

adalah

EmployeeID.

Composite key

Candidate key yang memiliki dua atau lebih atribut.

Pada kasus tertentu, key

pada entity type

tersusun atas

beberapa atributte

yang memiliki nilai unik untuk setiap

occurrence entity type namun tidak terpisah. Contoh

composite

key

adalah SalesID

dan ProductID

dalam

DetailSalesOrder.

2.4.5 Structural Constraint

Menurut Connolly dan Begg (2010, p385-395), Structural

Constraint adalah batasan-batasan di dalam relationships yang

merepresentasikan dunia nyata.

Tipe utama yang terdapat pada constraint relationship

disebut multiplicity. Multiplicity

adalah jumlah

kejadian

yang

mungkin

dari

entitas

yang

berhubungan

pada

kejadian tunggal

dari

sebuah

hubungan

entitas

melalui relationship

tertentu.

Multiplicity

merupakan

gambaran

dari

kebijakan/aturan

bisnis

yang dibuat oleh perusahaan

untuk

memastikan bahwa

semua

batasan perusahaan

teridentifikasi

dan

tergambarkan

sesuai dengan pemodelan perusahaan.

Terdapat

tiga

jenis

relationship sesuai dengan batasan perusahaan yaitu :

Relationship

One To One

Relationship One To Many

Relationship

Many To Many

Cardinality

adalah batasan yang menjelaskan nilai

maksimum yang mungkin dalam kejadian relationship bagi

entitas yang berpartisipasi di dalam relationship yang diberikan.

Cardinality terdiri dari one-to-one, one-to-many, dan many-to-

many.

2.5 Normalization

Menurut Connolly dan Begg (2010, p416), Normalization

adalah teknik untuk menghasilkan sekumpulan relasi terhadap

properties sesuai dengan data requirements dari perusahaan.

Normalisasi bertujuan untuk mengidentifikasi sekumpulan relasi yang

mendukung kebutuhan dari suatu perusahaan.

Berdasarkan definisi diatas, Normalization

adalah teknik untuk

menghasilkan atribut, relasi, dan entitas untuk mengurangi redundasi

data dan menghilangkan anomali data yang disebabkan dari update

anomalies (insertion anomalies, deletion anomalies, dan modification

anomalies). Karakteristik dari normalisasi ialah:

Jumlah minimal atribut yang diperlukan untuk mendukung

persayaratan data dalam sebuah perusahaan.

Atribut dengan hubungan logical

yang dekat (digambarkan

dengan functional dependency), ditemukan dalam hubungan

yang sama.

Meminimalkan redundansi dimana masing-masing atribut hanya

mewakili sekali , kecuali atribut yang membentuk seluruh atau

sebagian foreign keys karena foreign keys adalah

bagian

terpenting untuk penggabungan dalam relasi yang terkait.

Proses yang terdapat pada normalisasi ialah:

Unnormalized Form (UNF)

Menurut Connolly dan Begg (2010, p430),

Unnormalized Form

(UNF) adalah sebuah tabel yang

berisi satu atau lebih repeating groups. Proses normalisasi

yang pertama dilakukan dengan memindahkan data dari

sumber ke dalam tabel sesuai dengan baris dan kolom.

Dalam format tersebut, tabel ini disebut UNF yang

merepresentasikan tabel unnormalized.

First Normal Form (1NF)

Menurut Connolly dan Begg (2010, p430), First

Normal Form (1NF) adalah sebuah relasi dimana

pertemuan antara baris dan kolom yang terdiri dari satu

dan hanya bernilai satu.

Proses untuk mengubah UNF menjadi 1NF adalah

dengan mengindentifikasikan dan menghilangkan

repeating groups dalam tabel. Repeating groups

adalah

sebuah atribut atau kumpulan-kumpulannya yang ada di

dalam tabel yang memiliki beberapa nilai untuk sebuah

atribut pada tabel tersebut.

Second Normal Form (2NF)

Menurut Connolly dan Begg (2010, p434), Second

Normal Form (2NF) adalah sebuah relasi yang terdapat

pada 1NF dimana setiap atribut yang bukan primary key

bergantung penuh terhadap primary key.

Proses untuk mengubah 1NF menjadi 2NF adalah

menghilangkan ketergantungan partial dengan menghapus

atribut yang memiliki ketergantungan tersebut dari relasi

dan menempatkan atribut tersebut kedalam sebuah relasi

yang baru dengan melakukan copy dari determinannya.

Third Normal Form (3NF)

Menurut Connolly dan Begg (2010, p435), Third

Normal Form (3NF) adalah sebuah relasi yang terdapat

pada 1NF dan 2NF, dimana atribut yang bukan primary

key memiliki ketergantungan transitive terhadap primary

key.

Proses untuk mengubah 2NF menjadi 3NF adalah

dengan menghapus ketergantungan transitive pada atribut

dari relasi dan menempatkannya kedalam sebuah relasi

baru dengan melakukan copy dari determinannya.

2.6 Software Development Lifecycle (SDLC)

Menurut Pressman (2005, p79), salah satu model pengembangan

sistem yang digunakan adalah model waterfall. Waterfall model

(classic life cycle) menggunakan pendekatan klasik di dalam daur

hidup sistem. Beberapa tahapan yang terdapat di dalamnya yaitu:

Communication

Kerangka aktivitas yang melibatkan komunikasi dan

kolaborasi dengan stakeholders

meliputi project initiation,

requirements gathering, dan aktivitas terkait lainnya.

Planning

Kegiatan ini melibatkan sebuah perencanaan terhadap

software engineering

yang menjelaskan teknis yang akan

dikerjakan, resiko, sumber-sumber yang dibutuhkan dan

penjadwalan.

Modeling

Aktivitas ini melibatkan penciptaan model yang

memungkinkan pengembang maupun konsumen untuk saling

memahami analisis terhadap software requirements

dan design

yang ingin dicapai.

Construction

Kegiatan ini menggabungkan code generation baik secara

manual maupun otomatis dan testing

yang dibutuhkan untuk

menemukan kesalahan-kesalahan di dalam code.

Deployment

Perangkat lunak yang dihadirkan (secara keseluruhan

maupun partial) menempatkan konsumen untuk melakukan

evaluasi terhadap produk dan menyediakan feedback

berdasarkan evaluasi tersebut.

2.7 Lima Faktor Manusia Terukur

Menurut Shneiderman dan Plaisant

(2004, p16), faktor-faktor

manusia terukur dalam desain antarmuka pengguna terdiri dari:

Time to learn

Berapa lama waktu yang diperlukan orang awam dalam

komunikasi pengguna untuk mempelajari cara relevan untuk

melakukan suatu tugas.

Speed of performance

Berapa lama waktu yang diperlukan untuk melakukan

tugas.

Rate of errors by users

Berapa banyak kesalahan dan kesalahan apa saja yang

dibuat pengguna.

Retention over time

Bagaimanakah kemampuan pengguna mempertahankan

pengetahuannya setelah jangka waktu tertentu. Daya ingat

berkaitan erat dengan waktu belajar dan frekuensi pengguna.

Subjective satisfaction

Seberapa suka pengguna menggunakan variasi aspek dari

sistem. Jawaban dapat dipastikan dengan interview atau survey.

2.8 Delapan Aturan Emas

Menurut Shneiderman dan Plaisant (2004, p74), delapan aturan

emas dalam desain antarmuka pengguna terdiri dari:

Berusaha untuk konsisten

Konsisten pada aksi-aksi dalam situasi tertentu,

konsistensi warna, tampilan, huruf, dan sebagainya.

Menyediakan universal usability

Menyadari kebutuhan dari berbagai user

dan merancang

design yang flexible serta memfasilitasi perubahaan dari isi.

Umpan balik yang informatif

Untuk setiap aksi yang dilakukan pengguna terhadap

sistem, sistem harus memiliki umpan balik yang sopan dan jelas.

Membuat dialog untuk menghasilkan keadaan akhir

Urutan-urutan aksi diatur ke dalam grup-grup dengan

bagian awal, tengah, dan akhir. Feedback

pada saat akhir dari

group aksi tersebut harus memuaskan pengguna.

Memberikan penanganan kesalahan yang sederhana

Jika pengguna melakukan kesalahan, sistem harus dapat

mendeteksinya dan memberikan instruksi sederhana dan

membangun untuk perbaikan.

Mengizinkan pembalikan aksi

Sebanyak mungkin, semua aksi dapat dibalik. Fitur ini

mengurangi kekhawatiran karena pengguna tahu kesalahn dapat

diabaikan.

Mendukung pusat kendali internal

Pengguna yang berpengalaman menginginkan suatu

perasaan bahwa mereka menguasai sistem dan sistem harus

merespon keinginan mereka.

Mengurangi beban ingatan jangka pendek

Untuk mengatasi hal ini dapat dilakukan dengan

mengurangi frekuensi window dan dengan waktu pelatihan yang

cukup.

2.9 Teori Pembelian

Menurut Stevenson (2009, p518), pembelian adalah proses

mendapatkan material, bagian-bagian, persediaan, dan layanan yang

diperlukan untuk memproduksi sebuah produk atau menyediakan

sebuah layanan.

Menurut Himayati (2009, p79), pembelian adalah suatu

transaksi dimanna perusahaan membutuhkan barang atau jasa, baik

untuk dipakai maupun untuk persediaan yang akan dijual.

2.10 Teori Penjualan

Dalam jurnal “Strategi Pemasaran Produk Wisata” oleh

Suardana menyatakan Penjualan adalah ilmu dan seni mempengaruhi

pribadi yang dilakukan oleh penjual untuk mengajak orang lain agar

bersedia membeli barang atau jasa yang ditawarkannya,

mengembangkan keunggulan bersaing yang berkesinambungan

melalui pasar yang dimasuki dengan program pemasaran yang

digunakan untuk melayani pasar sasaran tersebut.

Menurut Kertajaya (2006, p15), Penjualan adalah bagaimana

menciptakan hubungan jangka

panjang dengan pelanggan melalui

produk atau jasa dari sebuah

perusahaan. Dalam hal ini penjualan

adalah bagaimana strategi yang akan

digunakan untuk

mengintegrasikan perusahaan, pelanggan, dan korelasi

antar

keduanya.

2.11 Teori Produksi

Menurut Nasution (2003, p1), produksi adalah metode dan

teknik yang digunakan dalam mengolah bahan baku menjadi suatu

produk jadi atau setengah jadi.

Menurut Gaspersz (2005, p167),

produksi dapat dikatakan

sebagai suatu aktivitas dalam perusahaan industri berupa penciptaan

nilai tambah dari input menjadi output

secara efektif dan efisien

sehingga produk sebagai output dari proses penciptaan

nilai tambah

itu dapat dijual dengan harga yang kompetitif di pasar global.

2.12 Teori Persediaan

Dalam jurnal “Analisis Dan Perancangan Sistem Informasi

Persediaan, Pembeliaan, Dan Penjualan Pada Toko Sinar Jaya” oleh

Saputra menyatakan persediaan merupakan aset pengadaan barang di

dalam sebuah bisnis, atau sedang dalam proses produksi untuk

penjualan tertentu, atau dalam wujud material atau pendukung untuk

digunakan dalam proses produksi atau penyumbangan jasa.

Dalam jurnal “Analisis dan Perancangan Sistem Informasi

dengan Intranet: Studi Kasus Persediaan Material PT Balfour Beatty

Sakti Indonesia” oleh Darudiato dan Punta menyatakan bahwa

persediaan adalah simpanan barang-barang yang disimpan untuk

memenuhi permintaan, baik dari dalam organisasi (internal) ataupun

dari luar organisasi (eksternal). Persediaan meliputi persediaan bahan

mentah,

persediaan barang dalam proses, pemeliharaan, dan

persediaan barang jadi.

Dalam jurnal “Inventory: The Necessary Evil?” oleh Lord

menyatakan bahwa persediaan adalah apa yang manajemen butuhkan.

Ditempatkan

di gudang, pusat distribusi dan di toko sebagai modal

bisnis.