Upload
vuonghuong
View
221
Download
0
Embed Size (px)
Citation preview
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.