8

BAB 2

LANDASAN TEORI

2.1 Teori – teori Dasar / Umum

2.1.1 Basis Data

Menurut Whitten (2004,p3) data adalah fakta mentah mengenai

orang, tempat, kejadian, dan hal-hal penting dalam organisasi.

Pengertian basis data sendiri menurut Connolly (2005,p15) adalah

kumpulan relasi logikal data / deskripsi data yang dapat digunakan bersama

dan didesain untuk memenuhi kebutuhan informasi dari sebuah organisasi.

Sedangkan menurut Hoffer (2002,p4), basis data adalah kumpulan

data yang terorganisir dan secara logika berkaitan. Terorganisir maksudnya

data distrukturkan sehingga mudah untuk disimpan, dimanipulasi, dan

diperoleh oleh pengguna. Berkaitan maksudnya data menggambarkan

daerah asal (domain) kepentingan tertentu bagi kelompok pengguna dan

pengguna dapat menggunakan data untuk menjawab pertanyaan seputar

domain itu.

2.1.2 Database Management System (DBMS)

Menurut Silberchatz, Korth, dan Sudarshan (2002,p1), DBMS

adalah kumpulan data yang saling berhubungan dan sekumpulan program

untuk mengakses data tersebut. Kumpulan data ini biasanya menunjuk ke

basis data yang berisi informasi perusahaan.

9

Menurut Elmasri dan Navathe (2005,p5), DBMS adalah

sekumpulan program yang mengizinkan pengguna untuk membuat dan

memelihara basis data.

Sedangkan menurut Connoly (2005,p16), DBMS adalah suatu

sistem software yang memungkinkan pengguna untuk mendefinisikan,

membuat, mengatur, dan mengontrol akses terhadap basis data.

DBMS menyediakan fasilitas sebagai berikut:

1. Data Definition Language (DDL) memberikan fasilitas kepada

pengguna untuk menspesifikasikan tipe data,strukturnya, dan batasan

aturan mengenai data yang bisa disimpan dalam basis data tersebut.

2. Data Manipulation Language (DML) memberikan fasilitas yang

memperbolehkan pengguna untuk menambah, memperbaiki,

menghapus data, dan mendapatkan kembali data.

3. Terdapat fasilitas untuk mengontrol akses ke basis data, seperti :

Suatu sistem keamanan yang mencegah pengguna yang tidak

mempunyai hak untuk mengakses data.

Suatu sistem terintegrasi yang memelihara konsistensi penyimpanan

data.

Suatu sistem kontrol konkurensi yang memperbolehkan berbagi hak

akses ke basis data.

Suatu sistem kontrol pengembalian data yang dapat mengembalikan

data ke keadaan sebelumnya apabila terjadi kegagalan perangkat

keras atau perangkat lunak.

10

Terdapat suatu katalog yang dapat diakses oleh pengguna yang

berisikan deskripsi dari data di dalam basis data tersebut.

2.1.2.1 Komponen DBMS

Menurut Connoly (2005,p18) ada lima komponen Database

Management Systems, yaitu :

1. Hardware (Perangkat Keras)

Digunakan untuk menjalankan DBMS dan aplikasi-aplikasi.

Contoh : single mainframe, single personal computer atau

komputer yang menggunakan jaringan.

2. Software (Perangkat Lunak)

Komponen software terdiri dari software DBMS itu sendiri

dan program-program aplikasi, bersama dengan sistem operasi

termasuk software jaringan jika DBMS digunakan dalam

sebuah jaringan. Contoh : C, C++, Java, Pascal, dan SQL.

3. Data

Merupakan komponen terpenting dari DBMS, terutama dari

sudut pandang pengguna akhir. Data merupakan jembatan

penghubung antara mesin dan manusia.

4. Prosedur

Prosedur merupakan instruksi dan aturan yang mengatur

perancangan dan penggunaan basis data. Contoh : Instruksi

untuk log on ke basis data, cara membuat backup atau salinan

data.

11

5. Manusia

Semua orang yang terlibat dengan sistem. Contoh : Databse

Administrator (DBA), Data Administrator (DA), dan Users.

2.1.2.2 Keuntungan dan Kerugian DBMS

Keuntungan DBMS :

Penggunaan data bersama

Mengurangi kerangkapan data

Menghindari ketidakkonsistenan data

Integritas data terpelihara

Keamanan terjamin

Kebutuhan User yang kompleks dapat teratasi

Pelaksanaan standarisasi

Meningkatkan produktivitas

Layanan back up dan recovery semakin baik

Kerugian DBMS :

Kompleksitas

Ukuran (memerlukan jumlah kapasitas memori yang besar)

Biaya DBMS relatif mahal

Biaya penambahan hardware

Biaya konversi (biaya training,biaya staff specialist )

Performance (tidak bisa running secepat yagn diinginkan)

Higher impact of a failure

12

2.1.3 Database Application Lifecycle

Merupakan tahapan dalam merancang suatu sistem basis data.

Siklus hidup basis data digambarkan seperti bagan berikut ini :

Database Planning

System Definition

Requirements collection and analysis

Application Design

DBMS Selection (optional)

Conseptual database

Logical database

Physical database

Prototyping (optional) Implementation

Data conversion and loading

Testing

Operational maintenance

Gambar 2.1 Database Application Lifecycle (Connoly, 2005, p284)

13

2.1.3.1 Database Planning

Mengatur dan merencanakan aktivitas-aktivitas agar

langkah-langkah dari aplikasi basis data dapat direalisasikan

dengan sebaik mungkin. Terdapat tiga masalah pokok yang harus

diperhatikan dalam merumuskan strategi sistem informasi

(Connolly, 2005, p285), yaitu :

Mengidentifikasikan rencana dan tujuan perusahaan dengan

menentukan sistem informasi yang diperlukan.

Mengevaluasi sistem informasi yang ada untuk menentukan

kelebihan dan kekurangan.

Penilaian mengenai peluang teknologi informasi yang

mungkin dapat menghasilkan keuntungan yang kompetitif.

Metodologi untuk mengatasi hal tersebut di atas, yaitu :

1. Menetapkan Mission Statement

Mission Statement untuk database project mendefinisikan

tujuan utama dari aplikasi basis data. Mission Statement

membantu menjelaskan kegunaan dari database project dan

menyediakan alur yang lebih jelas untuk mencapai efektifitas

dan efisien penciptaan dari suatu aplikasi basis data yang

diinginkan.

2. Menetapkan Mission Objectives

Ketika mission statement telah didefinisikan, maka mission

objectives didefinisikan. Setiap objectives (tujuan) harus

14

mengidentifikasikan tugas khusus yang harus didukung oleh

basis data.

2.1.3.2 System Definition

Mendeskripsikan ruang lingkup dan batasan dari aplikasi

basis data dan sudut pandang user yang utama (Connolly, 2005,

p286). Sebelum memulai rancangan suatu aplikasi basis data, kita

perlu mengidentifikasi batasan-batasan sistem yang ada dan

bagaimana sistem tersebut berinteraksi dengan bagian sistem

informasi yang lain dalam perusahaan tersebut. Penting juga

untuk mengikutsertakan di dalam batasan-batasan sistem yang

kita buat tidak hanya untuk aplikasi dan current user tetapi juga

untuk aplikasi dan user di masa yang akan datang.

2.1.3.3 Requirement Collection and Analysis

Merupakan proses mengumpulkan dan menganalisis

informasi mengenai bagian dari organisasi yang akan didukung

oleh sistem basis data, serta menggunakan informasi tersebut

untuk mengidentifikasi kebutuhan-kebutuhan untuk sistem yang

baru. Terdapat banyak teknik untuk memperoleh informasi, yang

disebut fact-finding techniques. Informasi yang dikumpulkan

mencakup :

Deskripsi tentang data yang digunakan atau di-generate.

15

Keterangan mengenai bagaimana data digunakan atau di-

generate.

Kebutuhan tambahan lainnya untuk sistem basis data yang

baru.

2.1.3.4 Database Design

Merupakan suatu proses pembuatan rancangan basis data

yang akan mendukung operasi dan tujuan perusahaan (Connolly,

2005, p291). Ada dua pendekatan utama dalam database design :

a. Pendekatan bottom-Up

Pendekatan bottom-up dimulai dari analisis atribut-atribut

(properti dari entity dan relationship), relasi antara atribut,

kemudian dikelompokkan ke dalam suatu relasi yang

merepresentasikan tipe dari entiti-entiti, lalu menganalisa

relasi antara entiti. Pendekatan ini lebih cocok untuk

perancangan basis data yang sederhana dengan jumlah atribut

yang relatif kecil.

b. Pendekatan Top-Down

Pada pendekatan ini terlebih dahulu membangun model data

tingkat tinggi, kemudian membangun model data yang lebih

sederhana. Pendekatan ini diilustrasikan melalui konsep model

Entity Relationship (ER).

Perancangan basis data dibagi ke dalam tiga tahapan utama,

yaitu Conceptual Database Design, Logical Database Design,

16

dan Physical Database Design. Dimana ketiga tahap itu akan

dibahas dan dijelaskan pada subbab selanjutnya 2.1.4

2.1.3.5 DBMS Selection (optional)

Melakukan pemilihan basis data yang tepat untuk

mendukung sistem basis data (Connolly, 2005, p295). Pemilihan

dapat dilakukan dengan mengikuti beberapa langkah berikut ini :

Mendefinisikan persyaratan studi referensi

Cakupan penelitian mengenai pemilihan DBMS menyatakan

tujuan, lingkup penelitian dan tugas-tugas yang harus

dilakukan. Dokumen ini juga meliputi deskripsi kriteria

(berdasarkan spesifikasi kebutuhan pengguna) untuk

mengevaluasi produk DBMS, daftar DBMS yang tersedia,

batasan-batasan dan jadwal waktu untuk penelitian.

Mendaftar sementara dua atau tiga produk

Kriteria-kriteria dianggap kritis untuk keberhasilan

implementasi dapat digunakan untuk evaluasi daftar produk

DBMS yang tersedia. Sebagai contoh, pemilihan DBMS dapat

tergantung pada anggaran yang tersedia, tingkat layanan

vemdor, kompatibilitas dengan piranti lunak lainnya dan

apakah dapat berjalan pada perangkat keras tertentu.

Evaluasi produk

Ada banyak fitur yang dapat digunakan untuk mengevaluasi

sebuah produk DBMS. Untuk tujuan evaluasi, fitur-fitur ini

17

dapat dinilai secara berkelompok (contohnya definisi data)

atau secara individual (contohnya tipe data yang tersedia).

Akhirnya, semua bobot nilai dari fitur-fitur tersebut

dijumlahkan untuk mendapatkan nilai sebuah produk DBMS

tertentu yang akan dibandingkan dengan nilai produk DBMS

lainnya. Produk DBMS yang dipilih adalah produk dengan

nilai tertinggi.

Merekomendasi pilihan dan menghasilkan laporan

Tahap akhir dari pemilihan DBMS adalah untuk

mendokumentasikan proses dan untuk menyediakan laporan

dan rekomendasi mengenai produk DBMS tertentu.

2.1.3.6 Application Design

Merancang antar muka pemakai dan program aplikasi yang

menggunakan dan memproses basis data (Connolly, 2005, p299).

Dalam banyak kasus tidak mungkin menyelesaikan application

sampai design database itu sendiri selesai. Di lain pihak, basis

data ada untuk mendukung aplikasi dan harus terjadi aliran

informasi antara desain aplikasi dan desain basis data. Kita harus

memastikan semua fungsionalitas yang diutarakan dalma

spesifikasi kebutuhan pengguna terdapat dalam desain aplikasi

untuk aplikasi basis data. Hal ini termasuk mendesain program

aplikasi yang mengakses basis data dan desain transaksi

(transaction design). Sebagai tambahan dalam mendesain agar

18

fungsionalitas yang dibutuhkan tercapai, kita harus mendesain

antar muka pemakai yang sesuai untuk aplikasi basis data. Antar

muka ini harus menyajikan informasi yang dibutuhkan secara user

friendly.

2.1.3.7 Prototyping (optional)

Membangun suatu model kerja dari sistem basis data

(Connolly, 2005, p304). Tujuan utama dari pembuatan

prototyping adalah :

Memperbolehkan pengguna untuk mengidentifikasi fitur-fitur

dari sistem yang berjalan dengan baik atau tidak.

Untuk memberikan perbaikan-perbaikan / penambahan fitur

baru.

Untuk mengklarifikasi kebutuhan pengguna.

Untuk evaluasi fisibilitas dari desain sistem khusus.

2.1.3.8 Implementation

Merupakan realisasi fisik dari basis data dan desain aplikasi

(Connolly, 2005, p304). Implementasi dari basis data dicapai

dengan menggunakan :

Data Definition Language (DDL) untuk membuat skema dan

file basis data yang kosong.

DDL untuk membuat user view yang diinginkan.

19

Bahasa 3GL dan 4GL untuk membuat program aplikasi.

Termasuk transaksi basis data disertakan dengan

menggunakan Data Manipulation Language (DML), atau

ditambahkan pada bahasa pemograman.

2.1.3.9 Data Convertion and Loading

Merupakan pemindahan data yang ada ke dalam basisdata

baru dan merubah aplikasi yang ada untuk beroperasi pada

basisdata yang baru. Langkah ini diperlukan hanya ketika suatu

sistem basisdata baru menimpa sistem yang lama.

2.1.3.10 Testing

Merupakan proses pengeksekusian program aplikasi dengan

maksud pencarian kesalahan-kesalahan. Sebelum ditunjukkan

secara langsung, aplikasi basisdata yang baru dikembangkan

seharusnya diuji sepenuhnya. Ini dicapai dengan menggunakan

strategi uji yang direncanakan secara hati-hati dan data yang nyata

sehingga keseluruhan proses uji diterima secara teliti dan metodis.

2.1.3.11 Operational Maintenance

Merupakan proses pengawasan dan pertahanan sistem

berikut instalasi. Pada langkah sebelumnya, aplikasi basisdata

telah diimplementasikan dan diuji sepenuhnya. Sekarang sistem

20

memasuki langkah perawatan, yang melibatkan aktivitas-aktivitas

berikut:

• Mengawasi kinerja sistem. Jika kinerja jatuh di bawah

level yang dapat diterima, perbaikan atau reorganisasi basisdata

dibutuhkan.

• Mempertahankan dan meng-upgrade aplikasi basisdata

(ketika dibutuhkan). Kebutuhan baru digabungkan ke dalam

aplikasi basisdata melalui langkah terdahulu dari siklus hidup.

2.1.4 Tahapan – Tahapan Perancangan Basisdata

Menurut Connolly dan Begg (2005,p438) metodologi perancangan

adalah pendekatan terstruktur yang menggunakan bantuan aturan, teknik,

alat - alat, dan dokumentasi yang bertujuan untuk mendukung dan

memfasilitasi proses perancangan basisdata. Metodologi perancangan

basisdata atas tiga tahapan, yaitu : perancangan konseptual, logikal, dan

fisikal.

2.1.4.1 Perancangan Basisdata Konseptual

Perancangan basisdata secara konseptual merupakan proses

pemodelan secara khusus, Menurut Connolly dan Begg

(2005,p439) dalam merancang konseptual basisdata terdapat tahap

– tahap yang dimulai dengan pembuatan sebuah konseptual data

dari sebuah perusahaan, dimana semuanya tergantung dari detail-

21

detail implementasi termasuk dari target DBMS, aplikasi program

– program, bahasa – bahasa pemrogramannya, perangkat keras

yang digunakan, performance issues dan pertimbangan –

pertimbangan yang lainnya.

Langkah 1 : Membangun model data konseptual

Langkah pertama dari konseptual ini bertujuan untuk

membangun sebuah model data konseptual dari sebuah

perusahaan. Model data konseptual didukung dari documentasi

yang terdiri dari ER diagram dan sebuah kamus data. Adapun

langkah – langkah dari membangun model data konseptual

sebagai berikut :

Langkah 1.1 : Mengidentifikasi tipe entity

Tujuan dari langkah ini adalah mengidentifikasikan tipe data

entity yang diperlukan. Langkah ini berguna untuk memudahkan

dan menarik user dalam menspesifikan entity. Dari langkah ini

User dapat mengidentifikasikan kata benda seperti :

Staff number, staff name, property number, property

address, rent, dll.

Langkah 1.2 : Mengindentifikasi tipe relasi

Langkah ini bertujuan untuk mengidentifikasi pentingnya

relasi yang exist di antara tipe entity. Mengidentifikasikan yang

didahului dengan spesifikasi record relasi sangat dibutuhkan

dalam suatu perusahaan yang mempunyai basisdata.

22

Adapun langkah – langkah dalam mengidentifikasi tipe

relasi adalah sebagai berikut :

Gunakan Entity Relationship Diagram (ERD)

ERD digunakan untuk menghadirkan kesatuan dan bagaimana

tipe relasi tersebut berhubungan dengan satu sama lain dengan

mudah. Selain itu ERD dapat kapan saja digunakan untuk

membantu membangun suatu gambar-an dari bagian

perusahaan yang akan dimodelkan.

Tentukan multiplicity contraints dari tipe entity

Multiplicity constraint di gunakan untuk mengecek dan

merawat data quality. Constraints dapat di terapkan ketika

basisdata sedang di-update, tentunya jika tidak melanggar

aturan dari perusahaan.

Mengecek fan dan chasm traps

Setelah mengidentifikasi dari hubungan tipe entity yang

diperlukan, memeriksa bahwa masing-masing hubungan di ER

model yang sesuai dengan true representation.

Document relationship types

Tipe relasi yang diidentifikasi untuk menugaskan nama yang

telah diberi keterangan yang bertujuan untuk memperjelas

keterangan yang berguna bagi user.

23

Langkah 1.3 : Mengidentifikasi dan mengasosiasikan atribut

suatu entity atau tipe relasi

Langkah ini bertujuan untuk mengidentifikasi dan

mengasosiasikan atribut dan tipe relasi. Atribut – atribut dari

entity dapat di identifikasikan melalui property,quality,indentifier

atau characteristic.

Langkah 1.4 : Mengidentifikasi domain attribute

Langkah ini bertujuan untuk menentukan domain dari setiap

atribut dalam model data dan mendokumentasikan detail dari

setiap domain.

Langkah 1.5 : Mengidentifikasi candidate dan primary key

Tujuan dari langkah ini adalah mengidentifikasi candidate

key untuk setiap entity dan menyeleksi untuk dijadikan sebuah

primary key.

Langkah 1.6 : Menggunakan konsep enhanced modeling

(langkah optional)

Langkah ini digunakan untuk spesialisasi, generalisasi,

agregasi dan komposisi yang berguna untuk mendukung enhanced

modeling.

Langkah 1.7 : Mengecek redundancy

Langkah ini bertujuan untuk mengecek apakah di dalam

suatu model terdapat redundancy. Adapun langkah – langkahnya

sebagai berikut:

24

• Memeriksa kembali one to one (1:1) relationship

Dalam mengidentifikasikan entity , ada kemungkinan bahwa

dua entity yang merepresentasikan hal yang sama dalam

perusahaan diidentifikasikan ganda.

• Menghilangkan redundancy pada relationship yang ada

Sebuah relationship dikatakan redundancy,apabila informasi

yang sama dapat di peroleh dari relationship yang lain. Model

data yang dikembangkan diusahakan seminimal mungkin

sehingga relationship yang redundancy tidak diperlukan dan

harus di hilangkan.

• Menentukan dimensi waktu

Dimensi wakitu dari relationship sangat penting dalam menilai

redundancy.

Langkah 1.8 : Memvalidasi model konseptual local dengan

transaksi user

Bertujuan untuk memastikan konseptual data model

mendukung data yang di perlukan dalam transaksi.

Langkah 1.9 : Mereview model data konseptual dengan user

Bertujuan untuk me-review model data konseptual dengan

user untuk memastikan apakah data model sudah benar dari

pengambilan data perusahaan.

25

Gambar 2.2 Contoh gambar model data konseptual untuk view

staff yang menampilkan semua attribute

2.1.4.2 Perancangan Basisdata Logikal

Perancangan basisdata secara logikal merupakan proses

pembuatan model informasi yang digunakan perusahaan

berdasarkan model khusus, tapi bebas dari DBMS tertentu dan

pertimbangan fisik lainnya. Tahap ini memetakan model data

konseptual pada sebuah model data logikal yang dipengaruhi oleh

data model untuk basisdata tujuan. Model data logikal merupakan

sumber informasi untuk tahap perancangan physical,

menyediakan suatu kendaraan bagi para perancang physical

database untuk melakukan pertukaran yang sangat penting untuk

perancangan basis data yang baik.

26

Langkah 2 : Membangun dan memvalidasikan model data

logikal lokal untuk setiap view

Langkah kedua ini bertujuan untuk menterjemahkan model

data konseptual ke dalam model data logikal dan

memvalidasikannya menggunakan teknik normalisasi untuk

memastikan bahwa model data logikal yang di terjemahkan benar

secara struktur dan mendukung transaksi yang diperlukan. Dalam

langkah ini, kita memetakan setiap model data konseptual local

yang di buat pada langkah pertama, menjadi sebuah model data

logikal local yang mengandung ER diagram, skema relasional dan

dokumentasi pendukung.

Langkah 2.1 : Membuat relation untuk model basisdata

logikal

Tujuan dari langkah ini adalah untuk membuat relasi dari

model data logikal yang merepresentasikan entities, relationships,

dan attributes yang telah diketahui. Dalam langkah ini, kita

membuat relasi untuk model data logikal untuk merepresentasikan

entities, relationships, dan attributes yang di definisikan dalam

view.

Sekarang kami akan memaparkan bagaimana relasi dapat di

buat dari stuktur-struktur yang memungkinkan dan berada di

model data.

27

1. Tipe Strong Entity

Untuk setiap Strong Entity yang terdapat dalam model data,

buatlah relasi yang mencakup semua attribut sederhana pada

entity tersebut.

2. Tipe Weak Entity

Untuk setiap Weak Entity yang terdapat dalam model data,

buatlah relasi yang mencakup semua attribut sederhana pada

entity tersebut. Primary Key dari Weak Entity didapat dari

sebagian atau sepenuhnya entity yang memiliki weak entity

(Owner Entity) tersebut sehingga identifikasi primary key dari

sebuah weak entity tidak dapat dilakukan sampai semua

relationship dengan owner entity selesai di petakan.

3. Tipe One-to-many (1:*) binary relationship

Untuk setiap 1:* binary relationship, entity pada sisi 1 (one)

pada relationship ditentukan sebagai parent entity dan entity

yang berada pada sisi * (many) pada relationship akan

ditentukan sebagai child entity. Pada hubungan 1:* binary

relationship, copy dari primary key parent entity harus

ditambahkan ke dalam child entity agar dapat tercipta

relationship yang benar.

4. Tipe One-to-one (1:1) binary relationship

Membuat relasi pada tipe ini lebih kompleks karena

cardinality tak dapat di gunakan untuk mengidentifikasi

28

parent entity dan child entity. Participation Constraint yang

dipertimbangkan dalam pembuatan relasi untuk

merepresentasikannya :

5. One-to-one (1:1) recursive relationship

Untuk kasus seperti ini, aturan pembuatan relasinya sama

dengan kondisi One-to-one (1:1) binary relationship.

6. Tipe superclass/subclass relationship

Untuk membuat relasi pada tipe ini, tentukan superclass

sebagai parent entity dan subclass sebagai child entity. Ada

banyak pilihan dalam merepresentasikan relationship tipe ini

ke dalam satu atau banyak relasi. Pilihan yang paling tepat di

antara pilihan yang ada bergantung pada beberapa faktor

seperti disjointness dan participation constraints pada

superclass/subclass relationship, keterlibatan subclasses

dalam relationship yang berbeda, dan jumlah participants

dalam superclass/subclass relationship.

7. Tipe Many-to-many (*:*) binary relationship

Pada tipe ini, buatlah relasi untuk merepresentasikan

relationshipnya dan masukkan semua attributes yang

merupakan bagian dari relationship tersebut.

8. Tipe complex relationship

Buatlah relasi untuk merepresentasikan relationship ini

dengan memasukkan semua attributes yang merupakan bagian

dari relationship tersebut.

29

9. Tipe Multi-valued attributes

Buatlah relasi yang baru untuk merepresentasikan multivalued

attributes dan masukkan primary key dari entity ke dalam

relasi yang baru untuk bertindak sebagai foreign key.

Langkah 2.2 : Validasikan relasi-relasi menggunakan

normalisasi

Dalam langkah ini kita memvalidasikan relasi-relasi yang

telah dibuat pada model data logikal dengan menggunakan teknik

normalisasi. Tujuannya adalah untuk memastikan bahwa relasi-

relasi yang didapat setidaknya sudah dalam bentuk Boyce-Codd

NormalForm (BCNF). Apabila tidak valid melalui proses

normalisasi,maka hal ini mengindikasikan ada bagian dari model

data logical yang salah atau terdapat kesalahan dalam pembuatan

relasi.

Langkah 2.3 : Validasikan relasi-relasi melalui transaksi user

Dalam langkah ini kita memvalidasikan relasi-relasi yang

ada di model data logikal lokal untuk memastikan bahwa relasi

dalam model data ini mendukung transaksi yang di butuhkan oleh

view seperti yang di sebutkan dalam spesifikasi kebutuhan user.

Langkah 2.4 : Periksa integritas dari batasan-batasan pada

model data (integrity constraint)

Tahap ini digunakan untuk mengecek integritas dari

batasan-batasan yang di representasikan pada model data logikal.

Hal ini meliputi :

30

• Required Data (data yang dibutuhkan)

Beberapa attribut harus mengandung nilai yang valid. Atau

dengan kata lain, attribut tersebut tidak boleh mengandung

null.

• Attribute domain constraints (batasan domain attribut)

Setiap attribut mempunya sebuah domain, yaitu sekumpulan

nilai yang legal/diperbolehkan.

• Multiplicity

• Entity Integrity (Integritas entity)

Primary key dari sebuah entity tidak boleh mengandung null.

• Referential Integrity (Integritas referensial)

Foreign key yang menghubungkan setiap tuple pada child

relation ke tuple pada parent relation harus mengandung nilai

yang sesuai di relasi-relasi yang berhubungan.

• General Constraints (Batasan umum)

Langkah 2.5 : Review model data logikal dengan user

Langkah ini merupakan langkah untuk mereview model data

logical dengan user untuk menjamin bahwa user telah

menentukan representasi model yang benar dari kebutuhan data

enterprise.

31

Langkah 2.6 : Gabungkan model data logikal ke model global

(optional)

Dalam langkah ini, kita menggabungkan model data logikal

ke dalam model data logikal global tunggal yang

merepresentasikan semua user views dari database.

1. Penggabungan model data logikal ke model global

Pada langkah ini langkah-langkah yang dikerjakan meliputi :

a. Review nama-nama dan isi dari entity/relasi dan candidat

ekeysnya.

b. Review nama-nama dan isi dari relationship/foreign keys

c. Menggabungkan entity-entity/relasi-relasi model data

local

d. Memasukkan entity-entity/relasi-relasi secara unik ke

dalam model data lokal

e. Menggabungkan relationship/foreign keys dari model

data lokal

f. Memasukkan relationship/foreign keyssecara unik ke

dalam model data lokal

g. Memeriksa apakah ada entity/relasi dan

relationship/foreign keys yang hilang

h. Memeriksa foreign key

i. Memeriksa integritas batasan-batasan yang ada.

j. Menggambar Entity Relationship Diagram secara global.

k. Update dokumentasi.

32

2. Validasi model data logikal global

Memvalidasikan relasi-relasi yang dibuat dari model data

logikal global menggunakan teknik normalisasi dan

memastikan bahwa relasi-relasi tersebut mendukung transaksi

yang dibutuhkan.

3. Mereview model data logikal global dengan user

Dalam langkah ini, kita mereview model data logical global

dengan user untuk memastikan bahwa model yang dibuat

telah merepresentasikan data yang dibutuhkan oleh

perusahaan.

2.1.4.3 Perancangan Basis Data Physical

Perancangan basisdata fisikal merupakan proses pembuatan

deskripsi dari implementasi database pada secondary strorage

yang menjelaskan basis relasi, organisasi data, dan indeks yang

digunakan untuk memperoleh akses pada yang baik, dan masalah

integritas lainnya yang berkaitan, dan menentukan mekanisme

keamanan.

Perancangan fisikal ini memiliki langkah – langkah sebagai

berikut :

Langkah 3 : Translate logical database design for target DBMS

Menterjemahkan logikal data model ke dalam DBMS).

Langkah ini adalah langkah untuk memproduksi dasar kerja

relasional basisdata dari model data logical. Dalam langkah ini

33

dibutuhkan fungsionalitas dari DBMS target seperti bagaimana

membuat base table dan apakah DBMS mendukung definisi dari :

• PK, FK, dan AK;

• required data – apakah sistem mendukung NOT NULL;

• domains;

• relational integrity rules;

• business rules.

Pada Langkah ini terdapat beberapa langkah lain:

Langkah 3.1 Design base tables (Merancang base table)

Langkah ini merupakan langkah untuk memutuskan

bagaimana menghadirkan base table yang dikenali dalam

modellogical di dalam DBMS target.

Untuk setiap table diperlukan pengertian dari :

• Nama tabel;

• Daftar kolom singkat yang diberi kurung;

• PK, AK dan FK;

• referential integrity constraints untuk setiap FK yang dikenali.

• Untuk setiap kolom diperlukan pengertian dari :

• domain, terdiri dari tipe data, panjang, dan constraints pada

domain;

• nilai default sebagai optional untuk kolom;

• apakah kolom dapat bernilai NULL.

34

Langkah 3.2 Design representation of derived data (Merancang

representasi dari derived data)

Langkah ini merupakan langkah untuk merancang

representasi dari derived data dalam basisdata. Pilihan yang ada

berdasarkan :

• Penambahan biaya untuk menyimpan derived data dan

menjaganya agar tetap consistent dengan data dari tempat data

tersebut berasal;

• Biaya untuk mengkalkulasi setiap waktu diperlukan.

Langkah 3.3 Design remaining business rules (Merancang

peraturan bisnis yang tersisa)

Langkah ini merupakan langkah untuk merancang the

remaining business rules untuk DBMS target.

Langkah 4 : Choose file organizations and indexes (Memilih

data organisasi dan indeks).

Langkah ini adalah langkah untuk menentukan organisasi

data yang optimal dalam menyimpan base table, dan indeks yang

diperlukan untuk mencapai bentuk persetujuan. Langkah ini

terdiri dari beberapa langkah berikut ini :

Langkah 4.1 Analyze transactions (Menganalisa transaksi)

Langkah ini merupakan langkah untuk mengartikan

fungsionalitas dari transaksi dan menganalisa transaksi penting

lainnya. Langkah ini juga menjelaskan bentuk kriteria seperti :

35

• transaksi yang berjalan secara berkala dan mempunyai

dampak penting dalam pertunjukan;

• transaksi yang merupakan kritikal bisnis;

• waktu selama sehari/seminggu ketika ada permintaan

pembuatan basisdata yang tinggi (yang disebut peak load).

Untuk membantu mengindentifikasi mana transaksi yang

akan diinvestigasikan, dapat menggunakan :

• transaction/table cross-reference matrix, menunjukkan table

yang diakses pada tiap transaksi,

• transaction usage map, mengindikasikan table yang

berpotensial sering digunakan dalam transaksi.

Gambar 2.3 Contoh Gambar Pemakaian transaksi untuk

memetakan beberapa transaksi

36

Setiap transaksi menentukan :

• table dan kolom yang diakses dan tipe pengaksesannya.

• kolom yang digunakan dalam search conditions.

• untuk query, meliputi kolom yang di join.

• frekuensi yang jelas dari transaksi.

• bentuk tujuan dari transaksi.

Langkah 4.2 Choose file organizations (Memilih organisasi

data)

Langkah ini merupakan langkah untuk menentukan

keefisienan organisasi data untuk setiap base table.

Organisasi data tersebut meliputi Heap, Hash, Indexed

Sequential Access Method (ISAM), B+-Tree, dan Clusters.

Beberapa DBMS (PC-based DBMS) mempunyai organisasi

data pasti yang tidak dapat di alter.

Langkah 4.3 Choose indexes (memilih indeks)

Langkah ini merupakan langkah untuk menentukan apakah

penambahan indeks akan meningkatkan kinerja system atau tidak.

Pendekatannya yaitu menjaga record tidak tersusun dan

membuat indeks secondary sesuai kebutuhan, atau dapat

menyusun record dalam table dengan menspesifikasikan primary

atau clustering index.

Garis-garis besar dalam pemilihan ‘wish-list’

1. Jangan menunjuk table kecil.

37

2. Tunjuk PK dari table jika bukan key dari organisasi data.

3. Tambahkan indeks secondary ke dalam kolom yang

digunakan sebagai key secondary. (Add secondary index to

any column that is heavily used as a secondary key.)

4. Tambahkan secondary index ke dalam FK jika sering diakses.

5. Tambahkan secondary index ke dalam kolom yang meliputi :

selection atau join criteria; ORDER BY; GROUP BY; dan

operasi lain yang meliputi sorting (seperti UNION atau

DISTINCT).

6. Tambahkan secondary index ke dalam kolo yang meliputi

built-in functions.

7. Tambahkan secondary index ke dalam kolom yang dapat

menghasilkan index-only plan.

8. Hindari menunjukan kolom atau table yang sering diupdate.

9. Hindari penunjukan kolom jika query akan menerima

perbandingan yang jelas dari record dalam table.

10. Hindari penunjukan kolom yang mengandung karakter string

yang panjang.

Langkah 5 : Design user views (Merancang user views)

Design user views dilakukan selama tahap Requirements

Collection and Analysis dari database application lifecycle.

Secara normal view dibuat menggunakan SQL atau fasilitas

QBElike.

38

Langkah 6 : Design security mechanisms (Merancang

mekanisme keamanan)

Secara umum RDBMS menyediakan dua tipe dari keamanan

basisdata :

• system security: mengakses dan menggunakan basisdata pada

level system (seperti username/password);

• data security: mengakses dan menggunakan objek pada

basisdata (seperti tables dan views).

Design Security Measures - SQL

Setiap user basis data yang ditentukan sebagai authorization

identifier dilakukan oleh DBA (biasanya merkaitan dengan

password).

Privileges adalah tindakan dimana user diperbolehkan untuk

mengatur base table atau view yang diberikan (seperti SELECT,

UPDATE).

Perintah GRANT membolehkan owner untuk memberikan

privileges kepada user lain.

Perintah REVOKE melepaskan privileges.

Langkah 7 : Consider introduction of controlled redundancy

(Mempertimbangkan pengenalan dari

pengontrolan redundancy)

39

Langkah ini adalah langkah untuk menentukan apakah

pengenalan redundancy dalam controlled manner oleh aturan

normalisasi akan meningkatan kinerja sistem atau tidak.

Selain itu juga perlu ditentukan bahwa denormalisasi :

• membuat implementasi lebih kompleks;

• sering mengorbankan kefleksibelan;

• dapat meningkatkan penerimaan tapi lama dalam mengupdate.

Menentukan denormalisasi dalam situasi berikut khususnya

untuk meningkatkan transaksi berkala :

Langkah 7.1 Combining 1:1 relationships

Gambar 2.4 Combining 1:1 relationships

40

Langkah 7.2 Duplicating nonkey columns in 1:* relationships

to reduce joins

Gambar 2.5 Duplicating nonkey columns in 1:* relationships to

reduce joins

Langkah 7.3 Duplicating FK columns in 1:* relationships to

reduce joins

Gambar 2.6 Duplicating FK columns in 1:* relationships to

reduce joins

41

Langkah 7.4 Duplicating columns in *:* relationships to reduce

Joins

Gambar 2.7 Duplicating columns in *:* relationships to reduce

joins

Langkah 7.5 Introducing repeating groups

Gambar 2.8 Introducing repeating groups

42

Langkah 7.6 Creating extract tables

Langkah ini dapat membuat extract tabel tunggal,

denormalisasi yang tinggi berdasarkan tabel yang diperlukan oleh

laporan, dan mengizinkan user untuk mengakses extract table

secara langsung sebagai pengganti base tables.

Langkah 7.7 Partitioning tables

Sedikit mengkombinasikan tabel, dapat memisahkan table

ke dalam partisi yang lebih kecil.

Horizontal partition: menyebarkan records bersilangan

dengan beberapa tabel kecil.

Vertical partition: menyebarkan kolom bersilangan dengan

beberapa tabel kecil. Duplikat PK memperbolehkan rekonstruksi.

Partisi berguna untuk aplikasi yang menyimpan dan

menganalisa data yang besar.

Keuntungan:

• Meningkatkan load balancing

• Meningkatkan performance

• Meningkatkan availability

• Meningkatkan recovery

• Keamanan.

Kerugian:

• Complexity

• Reduced performance

43

• Duplication.

Langkah 8 : Monitor and tune operational system (Memonitor

sistem operasional).

Langkah ini merupakan langkah untuk mengawasi system

operasional dan mengembangkan kinerja sistem untuk

memperbaiki perancangan keputusan yang tidak sesuai atau

menunjukan perubahan kebutuhan.

Beberapa faktor yang mungkin digunakan untuk mengukur

keefisienan :

• Transaction throughput: transaksi yang diproses pada saat

interval waktu yang diberikan.

• Response time: elapsed time untuk penyelesaian transaksi

tunggal.

• Disk storage: banyaknya disk space yang diperlukan untuk

menyimpan file basisdata.

Ada 4 komponen penting hardware yang dapat berinteraksi

dan mempengaruhi kinerja, yaitu :

• main memory

• CPU

• disk I/O

• network

44

2.1.5 Entity Relationship Modelling

Menurut Connolly dan Begg (2005,p342), salah satu aspek yang

sulit dalam perancangan basisdata adalah kenyataannya bahwa perancang,

programmer dan pemakai akhir cenderung melihat data dengan cara yang

berbeda.

2.1.5.1 Entity Type

Tipe entity adalah kumpulan objek – objek dengan properti

yang sama, yang didefinisikan oleh perusahaan yang

keberadaannya tidak tergantung.

Konsep dasar dari bentuk entity relationship adalah tipe

entity. Sebuah tipe entity memiliki keberadaan yang bebas dan

bisa menjadi objek dengan keberadaan fisik atau menjadi objek

dengan keberadaan konseptual.

Entity Occurrence adalah objek dan tipe entity yang dapat di

identifikasikan secara unik.

Gambar 2.9 Contoh Gambar Tipe Entity (Sumber Connolly dan

Begg, 2005, p345)

45

2.1.5.2 Tipe Relationship

Tipe relationship adalah sebuah gabungan yang mempunyai

arti di antara tipe – tipe entity. Setiap tipe relationship diberi

nama sesuai dengan fungsinya. Relationship Occurance adalah

gabungan yang dapat di identifikasikan secara unik, yang meliputi

suatu kejadian dari setiap tipe entity yang beradaptasi.

Derajat dari relationship adalah jumlah dari partisipasi tipe

entity dalam sebuah tipe relationship tertentu. Entity yang

berkaitan dalam sebuah tipe relationship dikenal sebagai

participant dalam relationship dan sejumlah participant dalam

relationship disebut sebagai derajat dari relationship.

2.1.5.3 Attributes

Atribut adalah sifat dari sebuah entity atau sebuah tipe

relationship. Atribut menyimpan nilai dari setiap entity

occurrence dan mewakili bagian utama dari data yang disimpan

dalam basisdata.

Attribute domain adalah suatu nilai-nilai untuk satu atau

beberapa atribut. Setiap atribut yang dihubungkan dengan

sejumlah nilai disebut domain. Domain mendefinisikan nilai-nilai

yang dimiliki sebuah atribut dan sama dengan konsep domain

pada model relasional.

Simple attribute adalah atribut yang terdiri dari satu

komponen tunggal dengan keberadaan yang bebas. Simple

46

attribute disebut juga sebagai atomic attribute. Composite

Attribute adalah atribut yang terdiri dari banyak komponen

dengan sebuah keberadaan yang bebas. Dalam hal ini, beberapa

atribut dapat dipisahkan menjadi komponen yang lebih kecil lagi

dengan keberadaan yang bebas. Single value attribute adalah

atribut yang memiliki nilai tunggal untuk masing – masing

kejadian dari entity.

2.1.5.4 Keys

Candidate key adalah kunci yang secara unik mengenali

setiap kejadian di dalam tipe entity. Sebuah candidate key tidak

boleh NULL. Sebuah entity mungkin punya lebih dari satu

candidate key.

Primary key adalah candidate key yang dipilih sebagai kunci

primer untuk mengenali secara unik setiap occurance dari tipe

entity.

Pemilihan primary key untuk sebuah entity adalah

berdasarkan pada pertimbangan panjang atribut, jumlah minimal

dari kebutuhan atribut, dan memenuhi syarat unik.

2.1.5.5 Structural Constraints

Tipe utama dari batasan hubungan di dalam relationship

disebut multiplicity. Multiplicity jumlah kemungkinan kejadian

dari sebuah entity yang mungkin berhubungan ke sebuah kejadian

47

tunggal dari sebuah entity yang tergabung melalui sebuah

hubungan khusus.

Hubungan binary secara umum dibedakan menjadi :

• Derajat hubungan one to one ( 1:1 )

Derajat hubungan antar entity 1:1 terjadi bila tiap anggota

entity Staff hanya boleh berpasangan dengan satu anggota dari

entity Branch. Sebaliknya, tiap anggota dari entity Branch

hanya berpasangan dengan satu anggota dari entity Staff.

Gambar 2.10 Contoh Gambar Diagram representasi hubungan

one-to-many (1:*)

Penjelasan:

Gambar di atas menunjukkan setiap staf mengatur 0 (nol)

atau lebih properti dengan menempatkan “0..*” di samping entity

PropertyForRent. Sedangkan untuk menunjukkan setiap property

diatur oleh 0 (nol) atau 1 (satu) staf, ditempatkan “0..1” disamping

entiti Staff.

48

• Derajat hubungan many to many (* : *)

Derajat hubungan antar entity ini terjadi bila tiap anggota

entity newspaper boleh berpasangan dengan lebih dari suatu

anggota entity PropertyForRent. Sebaliknya tiap anggota

entity PropertyForRent juga boleh berpasangan dengan lebih

dari satu anggota entity newspaper.

Gambar 2.11 Contoh Gambar Diagram representasi hubungan

many-to many (*:*)

Penjelasan:

Gambar di atas menunjukkan setiap properti diiklankan

dalam 0 (nol) atau lebih koran dengan menempatkan “0..*” di

samping entiti Newspaper. Sedangkan untuk menunjukkan setiap

Koran mengiklankan 1 (satu) atau lebih properti, ditempatkan

“1..*” di samping entiti PropertyForRent.

49

2.1.6 Normalisasi

2.1.6.1 Pengertian Normalisasi

Menurut Connolly dan Begg (2005,p387) normalisasi adalah

teknik untuk mengorganisasikan data ke dalam table – table untuk

memenuhi kebutuhan pemakai di dalam sebuah organisasi.

Tujuan dari normalisasi adalah untuk menghilangkan

kerangkapan data, untuk Mengurangi kompleksitas dan untuk

mempermudah memodifikasi data.

Adapun Manfaat dari normalisasi adalah sebagai berikut:

1. Meminimalkan jumlah storage space yang diperlukan untuk

menyimpan data.

2. Meminimalkan resiko data yang tidak konsisten dalam suatu

basisdata.

3. Meminimalkan kemungkinan update dan delete anomally.

4. Memaksimalkan stabilitas dari struktur data.

2.1.6.2 Tingkatan Normalisasi

1. First Normal Form (1NF)

Adalah relasi dimana pertemuan antar setiap baris dan kolom

terdiri 1 (satu) dan hanya 1 (satu) nilai. Dalam normalisasi

pertama ini, data yang berulang-ulang dihilangkan.

2. Second Normal Form (2NF)

50

Adalah relasi yang setiap atributnya adalah Full Function

Dependency pada seluruh primary key dari relasi tersebut.

Dalam normalisasi kedua ini, atribut yang tergantung pada

sebagian dari suatu composite key sebuah tabel dipindahkan

ke sebuah tabel yang terpisah.

3. Third Normal Form (3NF)

Adalah relasi dimana semua atribut yang non-key bersifat

mutually independent. Dengan demikian, tidak ada non-key

atribut yang bersifat functional dependent terhadap non-key

atribut yang lain. Dalam normalisasi ketiga ini, atribut yang

tidak memberikan kontribusi terhadap penjelasan karakteristik

primary key, akan dipindahkan ke sebuah tabel yang terpisah.

Keuntungan dari tabel relasional dalam 3NF adalah

menghilangkan data yang berulang-ulang dengan tujuan

menghemat tempat dan mengurangi anomaly manipulasi.

2.1.7 Denormalisasi

Denormalisasi merupakan proses yang dilakukan pada

database yang sudah dinormalisasi, dengan cara memodifikasi

struktur tabel dan mengabaikan kerangkapan data (yang

terkontrol) untuk meningkatkan kinerja database.

Keuntungan denormalisasi dapat meningkatkan performa

dengan :

51

• Perhitungan kembali data.

• Meminimalisasi kebutuhan akan join.

• Mengurangi jumlah foreign key pada relasi.

• Mengurangi jumlah indexes.

• Mengurangi jumlah relasi.

Kerugian denormalisasi :

• Dapat mempercepat perolehan data tetapi memperlambat

update.

• Mengevaluasi kembali perubahan pada tiap aplikasi.

• Dapat meningkatkan ukuran relasi.

• Memudahkan implementasi pada beberapa kasus tetapi

membuat lebih kompleks pada kasus lainnya.

• Mengorbankan fleksibilitas.

2.1.8 Structured Query Language (SQL)

Menurut Silberschatz et al.(2002, p45), bahasa query adalah suatu

bahasa dimana user meminta informasi dari database. SQL dirancang

untuk menggunakan relasi untuk mengubah input menjadi output yang

diinginkan. SQL memiliki dua komponen utama (Connolly dan Begg,

2005, p113):

1. Data Definition Language (DDL): digunakan untuk menentukan

struktur database dan mengontrol akses ke data. Perintah SQL-nya:

• CREATE TABLE : untuk membuat tabel.

52

• ALTER TABLE : untuk menambah/memindahkan kolom,

menambah/menghapus table constraint, menentukan/menghapus

default kolom.

• DROP TABLE : untuk memindahkan tabel.

• CREATE VIEW :untuk membuat view.

• DROP VIEW : untuk memindahkan view.

2. Data Manipulation Language (DML): digunakan untuk me-retrieve

dan meng-update data. Perintah SQL-nya:

• SELECT : untuk memilih data dalam database

• INSERT : untuk memasukkan data ke dalam tabel.

• UPDATE : untuk memperbarui data dalam tabel.

• DELETE : untuk menghapus data dari tabel.

2.1.8.1 Fungsi Aggregate dan Kontrol Akses

Fungsi aggregate yang dimiliki SQL :

• COUNT : untuk menampilkan banyak nilai dalam suatu

kolom.

• SUM : untuk menampilkan jumlah nilai dalam suatu kolom.

• AVG : menampilkan jumlah nilai rata-rata dalam suatu kolom.

• MIN : untuk menampilkan nilai terkecil dalam suatu kolom.

• MAX : untuk menampilkan nilai terbesar dalam suatu kolom.

Kontrol Akses memberikan hak akses yang berbeda untuk

kelompok user yang berbeda, terdiri dari :

53

• GRANT : untuk memberikan hak akses kepada user yang lain.

• REVOKE : untuk membatalkan pemberian hak akses kepada

user.

2.1.9 Diagram Alir Data

Menurut Whitten (2004,p357-366): “ Diagram aliran data (Data

Flow diagram) merupakan suatu teknik untuk mengorganisasikan struktur

dan aliran data melalui proses sistem dan atau logik, prosedur untuk

diimplementasikan oleh proses sistem.

Dalam diagram alir data ini digunakan beberapa simbol

• Proses : kegiatan atau kerja yang dilakukan oleh orang, mesin atau

komputer dari suatu aliran data yang keluar.

Nama

Proses

• Aliran data : menunjukkan aliran data yang masuk atau keluar dari

suatu proses.

Nama Aliran Data

• Data tersimpan (data store) : merupakan simbol dari data yang dapat

berupa file data base dalam komputer, arsip catatan manual.

Data Store

54

• Eksternal entity : adalah suatu kesatuan dilingkungan luar sistem yang

akan memberikan masukan atau menerima keluaran dari sistem.

External Entity

Jenis-jenis diagram aliran data:

• Diagram konteks, menggambarkan semua entitas luar yang berinteraksi

dengan sistem.

• Diagram nol, menggambarkan proses-proses penting yang ada dalam

suatu sistem informasi.

Gambar 2.12 Contoh Diagram Konteks.

Library ContextDiagram

System ArchitectSat Oct 31, 1998

PUBLISHERS

BORROWERS

PUBLICRELATIONS

STAFF

Library ofCongress

P1LIBRARYSYSTEM

Library Context Diagram

Form Letters

Borrower Information

Published Book InformationMailings

New Book Orders

New Offerings

New BooksBorrowed Books

2.1.10 State Tran

Men

adalah sua

dihubungka

Diagram d

yang menu

state yang

Ada

Transition

1. Gamba

Ga

sition Diagr

nurut Jeffre

atu diagram

an satu sama

digambarkan

unjukkan bag

lain.

a dua macam

Diagram (S

ar persegi pan

ambar 2.13

ram (STD)

y A. Et al (

m yang me

a lain dalam

n dengan seb

gaimana keja

m simbol ya

TD), yaitu :

njang menun

Contoh Diag

(1996, p364

nggambarka

m waktu yang

buah state ya

adian-kejadi

ang mengga

njukkan stat

gram Nol

4), State Tra

an bagaiman

g bersamaan

ang berupa k

ian tersebut

ambarkan pr

te dari sistem

ansition Dia

na suatu p

. State Trans

komponen s

dari satu sta

roses dalam

m

55

agram

proses

sition

istem

ate ke

State

56

2. Gambar panah menunjukkan transisi antar state. Tiap panah diberi label

dengan ekspresi aturan. Label yang di atas menunjukkan kejadian yang

menyebabkan transisi yang terjadi. Label yang di bawah menunjukkan

aksi yang terjadi akibat dari kejadian tadi.

Contoh STD :

Gambar 2.14 Contoh STD

57 2.2 Teori Khusus

2.2.1 Definisi Konten

Pada dasarnya konten dapat dijelaskan sebagai isi dari sebuah

informasi. Konten merupakan informasi yang digunakan dimana informasi

itu dikemas dan dipresentasikan ataupun dipublikasikan untuk tujuan

spesifik. Konten terdiri dari beberapa informasi yang menjadi satu

kesatuan. Sebuah buku memiliki konten atas gabungan beberapa chapter,

paragraf, dan kalimat. Surat kabar berisikan konten dari artikel – artikel,

iklan, index, dan gambar. Dan yang terbaru dalam dunia media adalah web,

yang sama saja, dimana sebuah situs memiliki konten dari artikel – artikel,

iklan, index, dan gambar – gambar yang kesemuanya disusun menjadi satu

kesatuan.

2.2.2 Bagian Pokok Sistem Manajemen Konten

Manajemen konten adalah mengumpulkan, mengelola, dan

mempublikasikan atau menerbitkan konten. Kerangka kerja yang

membangun komponen ini memperbolehkan konten tersebut untuk

diciptakan, dikelola, dan diterbitkan oleh staf yang tindakannya dibimbing

prosedur yang disebut arus kerja.

Sewaktu konten dikumpulkan, konten dibawa ke dalam sistem

manajemen konten. Pengumpulan konten dibagi menjadi 4 kategori :

• Authoring, ini merupakan menciptakan konten dari coretan. Penulis

hampir selalu bekerja dalam kerangka kerja editorial untuk

menyesuaikan kontennya ke dalam tujuan struktur penerbitan. Penulis

58

harus mengetahui tata kerja yang telah dikembangkan untuk

penggunaan konten. Ide penulis dapat dimasukkan ke dalam informasi.

Jadi, penulis harus didorong dan diberi kuasa untuk menjalankan

kerangka kerja informasi ke dalam konten mereka.

• Aggregating, ini merupakan proses pengumpulan konten yang akan

dimasukkan ke dalam sistem.

• Converting, merupakan proses perubahan atau perbaikan unsur di

dalam konten.

• Editorial services, layanan editorial menyesuaikan tambahan

komponen baru dalam konten. Dengan panduan bagaimana untuk

menyesuaikan komponen baru ke dalam sebuah konten.

Sistem manajemen merupakan tempat penyimpanan semua konten

dan informasi yang dikumpulkan dalam sistem. Tempat penyimpanan

mempunyai beberapa fungsi :

• Store content. Tempat penyimpanan mungkin berupa satu atau

kumpulan berbagai jenis database. Tempat penyimpanan harus dapat

menyimpan :

- Textual content, konten dalam bentuk teks.

- Components, tempat penyimpanan harus bisa menghubungkan

konten ke dalam komponen yang mudah dikelola.

- Information, tempat penyimpanan harus efektif menyimpan

keragaman informasi yang perlu dikumpulkan.

59

• Select content, memperbolehkan akses dan pemilihan konten dari

tempat penyimpanan.

• Manage content, tempat penyimpanan harus mempermudahtugas

manajemen di bawah ini :

- Security, ijin akses membaca dan menulis komponen.

- User maintenance, mengatur sumber penggunaan sistem.

- Input/output processes, yang memuat dan mengeluarkan informasi.

Tabel 2.1 Perbandingan Antara Mass Advertising, Traditional Direct

Advertising dan Webvertising

Aspek

Perbandingan

Mass Advertising Traditional

Direct

Advertising

Webvertising

Hasil (outcome)

terbaik

Volume penjualan Data pelanggan Customer

Relationships

Perilaku

Konsumen

Pasif Pasif Aktif

Produk

Terkemuka

Makanan, produk

perawatan pribadi,

bir, mobil

Kartu kredit, biro

perjalanan, mobil

Busana kelas atas,

biro perjalanan,

jasa finansial,

mobil

Ukuran Pasar Sebesar mungkin Nasional hingga

global

Global individual

Ukuran Nadi Pusat perbelanjaan Pusat distribusi Cyberspace

60

Utama pos

Wahana Media

Pokok

TV, radio,

majalah

Mailing list Jasa online

Teknologi Utama Storyboards Database Servers, on-screen

navigator, web

Hasil (outcome)

terburuk

Channel surfing Kotak sampah Log-Off

Sumber : Turban et al.,(2002, p18)

2.2.3 Penjualan

2.2.3.1 Teori Penjualan

Menurut Romney dan Steinbart (2002,p517), penjualan

merupakan suatu set rekursif dari kegiatan bisnis dan operasi

pemrosesan informasi terkait yang dihubungkan dengan

penyediaan barang dan pelayanan pelanggan serta penerimaan

pembayaran dari penjualan tersebut. Penjualan adalah proses

utama dalam suatu perusahaan manufaktur atau ritel. Inventory

menyediakan fasilitas untuk memenuhi kebutuhan perusahaan

seperti ini. Pada Perusahaan manufaktur dimana terjadi proses

pengolahan bahan mentah atau part menjadi barang jadi atau

assemble. Pada perusahaan seperti ini, mutasi barang tidak hanya

terjadi pada saat penjualan saja, tetapi pada proses produksi juga.

Menurut Atqona Technology Systems (2006), proses

penjualan ada dua macam yaitu :

61

1. Penjualan melalui pesanan

2. Penjualan langsung

Penjualan melalui pesanan atau penjualan tidak langsung

biasanya terjadi pada perusahaan – perusahaan besar. Pada

penjualan seperti ini, paling sedikit lebih dari satu bagian dalam

perusahaan yang terlibat. Ada bagian penjualan, memproses dan

membuat penerimaan pesanan pembelian, ada bagian pemenuhan

pesanan yang memproses pemesanan ke bagian gudang

persediaan, ada bagian invoice yang membuat faktur dan surat

pengeluaran/pengiriman barang ke bagian gudang, dan ada bagian

gudang yang mengelola pengemasan dan pengepakan barang

untuk dikirim ke pelanggan. Penjualan langsung terjadi pada

perusahaan ritel dan perusahaan kecil.

Untuk melakukan penjualan melalui pesanan atau penjualan

tidak langsung, maka lakukan langkah – langkah (siklus)

penjualan sebagai berikut ini:

1. Buat SO ( pemesanan penjualan)

2. Cetak form SO

3. Cek Stock on hand

4. Buat Send SO (pemenuhan pesanan)

5. Buat Invoice (faktur Penjualan)

6. Cetak Invoice

7. Posting ke Account Receiveable (buku piutang dagang)

62

8. Kirim barang ke pelanggan + Invoice.

Proses penjualan yang dimulai dari permintaan pembelian

dari pelanggan atau pemesanan biasanya pemesanan ini berupa

PO dari pelanggan yang biasanya diterima via fax, telpon atau

email dll. PO pemesanan selanjutnya diproses pada Sales Order

(SO). Transaksi SO adalah proses pengisian form SO dan

pencetakan form SO berdasarkan PO pelanggan. Selanjutnya

pemesanan berikutnya dibuat dan diurut berdasarkan tanggal.

Begitu seterusnya, seluruh pemesanan pembelian dibuat dan

diarsipkan. Selanjutnya, proses pemenuhan pesanan penjualan

Send SO Transaction. Jika stock on hand mencukupi, pesanan

dipenuhi dengan membuat form Send SO Transaction. Form ini

selesai dibuat, terjadi mutasi barang dari gudang atau tempat

penyimpanan lain ke tempat penjualan. Bagian keuangan

menerima jurnal penjualan (kredit Inventory, debet hpp/cost of

good sales). Barang di gudang di-kredit berkurang sebanyak yang

dikeluarkan atau dijual. Selanjutnya dibuat Invoive penjualan.

Invoice dan barang dikirim ke pelanggan. Bagian keuangan

menerima jurnal (debet penjualan, kredit piutang).

Berikut ini ilustrasi proses penjualan melalui pemesanan.

Siklus dimulai dari pesanan diterima dari pelanggan. Selanjutnya

diproses di bagian penjualan dengan dibuatkannya form sales

63

order. Beberapa atau satu sales order dibuatkan pemenuhan SO

bila cukup stock di gudang.

Dari pemuatan SO ini dibuatlah faktur penagihan dikirim ke

pelanggan bersama dengan barang pesanannya.

Pelanggan membayar cash atau transfer melalui bank. Pada

saat bersamaan, bagian keuangan membuat jurnal piutang dagang.

Untuk lebih jelasnya, gambar secara visul mengilustasikan proses

penjualan tersebut.

Gambar 2.15 Gambar siklus penjualan

Fungsi yang terkait dalam system penjualan (Mulyadi,

2001,p211) adalah :

• Fungsi penjualan, bertanggung jawab untuk menerima order,

mengedit order, meminta otorisasi kredit, menentukan tanggal

pengiriman dan bertanggung jawab atas transaksi penjualan.

• Fungsi gudang, bertanggung jawab untuk menyimpan dan

menyiapkan barang yang dipesan serta menyerahkan barang

ke fungsi pengiriman.

64

• Fungsi pengiriman, bertangggung jawab menyerahkan barang

kepada pelanggan berdasarkan surat jalan yang diterimanya

dari fungsi penjualan.

• Fungsi penagihan, bertanggung jawab membuat dan

mengirimkan faktur penjualan kepada pelanggan, serta

menyiapkan duplikasi faktur bagi kepentingan pencatatan

transaksi penjualan oleh fungsi akuntansi.

• Fungsi akuntansi, bertanggung jawab mencatat piutang yang

timbul dari transaksi penjualan dan membuat laporan

penjualan.

Jaringan prosedur yang membentuk system penjualan

(Mulyadi, 2001, p219) adalah sebagai berikut :

• Prosedur order penjualan

Fungsi penjualan menerima order dari pembeli dan

menambahkan informasi penting pada surat order. Fungsi

penjualan kemudian membuat surat jalan dan

mengirimkannya kepada berbagai fungsi yang lain untuk

memungkinkan fungsi tersebut memberikan kontribusi dalam

melayani order dan pembeli.

• Prosedur pengiriman

Fungsi pengiriman mengirimkan barang kepada pembeli

sesuai dengan informasi yang tercantum dalam surat jalan.

65

• Prosedur penagihan

Fungsi penagihan membuat faktur penjualan dan

mengirimkannya kepada pembeli. Dalam metode tertentu

faktur penjualan dibuat oleh fungsi penjualan sebagai

tembusan pada waktu bagian ini membuat surat jalan.

• Prosedur pencatatan piutang

Fungsi akuntansi mencatat tembusan faktur penjualan ke

dalam kartu piutang atau dalam metode pencatatan tertentu

mengarsipkan dokumen tembusan menurut abjad yang

berfungsi sebagai catatan piutang.

• Prosedur distribusi penjualan

Fungsi akuntansi mendistribusikan data penjualan menurut

informasi yang diperlukan oleh manajemen.

Dokumen – dokumen yang digunakan dalam sistem

penjualan (Mulyadi, 2001, p214) meliputi :

• Surat jalan dan tembusannya

• Faktur dan tembusannya

• Rekapitulasi harga pokok penjualan

• Bukti memorial

Transaksi retur penjualan terjadi jika perusahaan menerima

pengembalian barang dari pelanggan, karena terjadi

ketidaksesuaian seperti barang yang diterima tidak sesuai dengan

spesifikasi pada surat order yang telah kadaluarsa. Pengembalian

66

barang oleh pelanggan harus diotorisasi oleh penjualan dan

diterima oleh fungsi penerima.

2.2.3.2 Faktor – Faktor Yang Mempengaruhi Penjualan

Adapun faktor-faktor yang mempengaruhi penjualan antara

lain:

1. Kualitas barang

Turunnya mutu barang dapat mempengaruhi volume

penjualan, jika barang yang diperdagangkan mutunya

menurun dapat menyebabkan pembelinya yang sudah menjadi

pelanggan dapat merasakan kecewa sehingga mereka bisa

berpaling kepada barang lain yang mutunya lebih baik.

2. Selera konsumen.

Selera konsumen tidaklah tetap dan dia dapat berubah setiap

saat, bilamana selera konsumen terhadap barang-barang yang

kita perjualkan berubah maka volume penjualan akan

menurun.

3. Servis terhadap pelanggan

Servis terhadap pelanggan merupakan faktor penting dalam

usaha memperlancar penjualan terhadap usaha dimana tingkat

persaingan semakin tajam. Dengan adanya servis yang baik

terhadap para pelanggan sehingga dapat meningkatkan

volume penjualan.

67

4. Persaingan menurunkan harga jual.

Potongan harga dapat diberikan dengan tujuan agar penjualan

dan keuntungan perasahaan dapat ditingkatkan dari

sebelumnya. Potongan harga tersebut dapat diberikan kepada

pihak tertentu dengan syarat-syarat tertentu pula.

2.2.4 Pengertian Majalah

Menurut Kamus Besar Bahasa Indonesia majalah adalah terbitan

berkala yg isinya meliputi berbagai liputan jurnalistik, pandangan tentang

topik aktual yang patut diketahui pembaca, dan menurut waktu

penerbitannya dibedakan atas majalah bulanan, tengah bulanan, mingguan,

dan sebagainya. Menurut pengkhususan isinya dibedakan atas majalah

berita, wanita, remaja, olahraga, sastra, ilmu pengetahuan tertentu, dan

sebagainya.