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.
8
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
Conseptual database DBMS Selection (optional) Logical database
Application Design
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 digenerate.
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.
2.1.3.8
Untuk mengklarifikasi kebutuhan pengguna.
Untuk evaluasi fisibilitas dari desain sistem khusus.
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 relasirelasi 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 pengontrolan redundancy)
pengenalan
dari
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.
•
2.1.8
Mengorbankan fleksibilitas.
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. Library Context Diagram
PUBLIC RELATIONS STAFF
Form Letters
PUBLISHERS
New Offerings New Book Orders
P1 LIBRARY SYSTEM
Borrowed Books
New Books
Borrower Information BORROWERS Mailings
Published Book Information
Library Context Diagram System Architect Sat Oct 31, 1998
Gambar 2.12 Contoh Diagram Konteks.
Library of Congress
55
Gaambar 2.13 Contoh Diaggram Nol
2.1.10 State Transition Diagrram (STD) Mennurut Jeffrey A. Et al (1996, ( p3644), State Traansition Diaagram adalah suaatu diagram m yang menggambarkaan bagaimanna suatu proses p dihubungkaan satu samaa lain dalam m waktu yangg bersamaan. State Transsition Diagram digambarkan d n dengan sebbuah state yaang berupa komponen k sistem yang menuunjukkan baggaimana kejaadian-kejadiian tersebut dari satu staate ke state yang lain. Adaa dua macam m simbol yaang menggaambarkan prroses dalam State Transition Diagram (STD), yaitu : 1. Gambaar persegi pannjang menunnjukkan statte dari sistem m
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
Mass Advertising
Traditional
Perbandingan
Webvertising
Direct Advertising
Hasil (outcome)
Volume penjualan
Data pelanggan
terbaik Perilaku
Customer Relationships
Pasif
Pasif
Aktif
Produk
Makanan, produk
Kartu kredit, biro
Busana kelas atas,
Terkemuka
perawatan pribadi,
perjalanan, mobil
biro perjalanan,
Konsumen
jasa finansial,
bir, mobil
mobil Ukuran Pasar
Sebesar mungkin
Nasional hingga
Global individual
global Ukuran Nadi
Pusat perbelanjaan Pusat distribusi
Cyberspace
60 Utama
pos
Wahana Media
TV, radio,
Pokok
majalah
Teknologi Utama
Storyboards
Mailing list
Jasa online
Database
Servers, on-screen navigator, web
Hasil (outcome)
Channel surfing
Kotak sampah
Log-Off
terburuk
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.
