BAB 2 LANDASAN TEORI
2.1 Teori – Teori Dasar Basis Data Teori yang mendasari suatu perancangan sistem basis data, yaitu:
2.1.1 Pengertian Sistem Menurut James A.O'Brien, (2002,p8), sistem adalah sekumpulan komponen yang saling berkerja sama untuk mencapai sasaran dengan menerima input dan menghasilkan output dalam sebuah proses transformasi yang terorganisir. Menurut Connolly (2002,p270), sistem adalah suatu cara untuk mengumpulkan, mengatur, mengendalikan, dan menyebarkan informasi ke seluruh organisasi.
2.1.2 Pengertian Data Menurut McLeod dan Schell (2004,p9), data terdiri dari fakta – fakta dan simbol – simbol yang secara umum kurang berguna dikarenakan jumlahnya yang besar dan sifatnya yang kasar atau belum diolah. Menurut James A.O’Brien (2002,p13), data adalah fakta – fakta atau observasi yang mentah, biasanya mengenai kejadian atau transaksi bisnis.
6
7 2.1.3 Pengertian Basis Data dan Sistem Basis Data Menurut Connolly (2002,p14), pengertian basis data yaitu suatu kumpulan data yang dapat di share, yang berhubungan secara logika, dan deskripsi dari data tersebut dirancang untuk memenuhi kebutuhan informasi suatu organisasi. Menurut Date (2000,p5), pengertian sistem basis data adalah komputerisasi sistem penyimpanan data yang bertujuan menyimpan dan memelihara informasi serta mengijinkan pengguna untuk melakukan perubahan atau pengambilan data yang dibutuhkan.
2.1.4 Database Management System (DBMS) Definisi Database Management System menurut Connolly (2002,p16), adalah suatu sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, memelihara basis data, dan menyediakan kendali dalam mengakses basis data.
2.1.4.1 Komponen-komponen dalam lingkungan DBMS Menurut Connolly (2002,p18) DBMS memiliki 5 komponen, yaitu: • Hardware DBMS membutuhkan perangkat keras untuk menjalankannya. • Software Karena seluruh kendali DBMS akan dilakukan oleh program aplikasi maka DBMS harus dapat dihubungkan ke program – program aplikasinya.
8 • Data Data yang digunakan oleh suatu organisasi harus dirancang sedemikian rupa sehingga mudah untuk digunakan. • Procedures Perintah – perintah yang harus dilakukan untuk menjalankan DBMS ini. • People Masalah keterkaitan perilaku orang yang menggunakan sistem (pengguna)
dengan
sistem
DBMS
yang
sudah
dirancang
sebelumnya.
2.1.4.2 Fasilitas-fasilitas DBMS Menurut Connolly (2002,p16), fasilitas –fasilitas dalam DBMS adalah sebagai berikut ini : • Mendefinisikan basis data, biasanya menggunakan suatu Data Definition Languange (DDL) yang berguna untuk memberikan fasilitas kepada pengguna untuk mendeklarasikan tipe data, struktur dan isi data yang disimpan ke dalam basis data tersebut. • Memperbolehkan pengguna untuk menambah data, mengubah data, menghapus data, dan menemukan data. Dengan menggunakan suatu Data Manipulation Languange (DML) biasanya ada suatu fasilitas untuk melayani pengaksesan data yang disebut sebagai Query Languange. Bahasa query yang paling diakui adalah
9 Structured Query Languange (SQL), yang secara de facto merupakan standar bagi DBMS.
2.1.4.3 Data Definition Language (DDL) Definisi dari Data Definition Language menurut Connolly (2002, p40) adalah suatu bahasa yang memperbolehkan Database Administrator (DBA) atau pengguna untuk mendefinisikan entitas, atribut, dan hubungan yang dibutuhkan oleh suatu aplikasi serta menambahkan fungsi-fungsi khusus untuk mempermudah atau meningkatkan keamanan data.
2.1.4.4 Data Manipulation Language (DML) Data Manipulation Language menurut Connolly (2002, p41) adalah suatu bahasa yang melakukan operasi-operasi standar pada data yang ada di dalam basis data. Pengoperasian data yang akan dimanipulasi biasanya meliputi : 1. Penambahan data baru ke dalam basis data. 2. Mengubah data yang disimpan ke dalam basis data. 3. Pemanggilan data yang terdapat di dalam basis data. 4. Penghapusan data dari basis data
2.1.4.5 Keuntungan dan kekurangan dari DBMS Keuntungan dari penggunaan DBMS antara lain : 1.
Dapat menghindari terjadinya penyimpanan data-data yang sama berulang kali (control of data redudancy).
10 2.
Data menjadi lebih konsisten.
3.
Data yang sama dapat digunakan bersama-sama oleh pengguna yang berbeda (shared data).
4.
Meningkatkan keterkaitan antar data.
5.
Meningkatkan keamanan.
6.
Membuat suatu standar.
7.
Meningkatkan efisiensi kebutuhan.
8.
Kebutuhan-kebutuhan yang berbeda-beda dapat dipenuhi dengan mudah.
9.
Meningkatkan
kemampuan
akses
data
dan
kecepatan
prosesnya. 10. Meningkatkan produktivitas. 11. Memudahkan perawatan data. 12. Meningkatkan keamanan pada data yang dipakai bersama-sama. 13. Mempermudah fungsi backup dan recovery.
Selain keuntungan juga terdapat kekurangan dari DBMS dibanding File Based System : 1.
Proses di dalamnya lebih rumit.
2.
Mempunyai kapasitas yang lebih besar jika dibandingkan oleh masing-masing file pada File Based System.
3.
Harganya lebih mahal.
11 4.
Membutuhkan biaya tambahan untuk perangkat keras jika DBMS yang digunakan menuntut penggunaan jenis perangkat keras tertentu.
5.
Membutuhkan proses-proses tambahan jika ingin mengubah format-format data dari suatu jenis DBMS ke DBMS jenis lain.
6.
Kehandalan (kecepatan proses), jika suatu DBMS didesain untuk penggunaan yang sangat umum maka kecepatan prosesnya menjadi lambat.
7.
Dampak yang lebih berat jika terjadi kesalahan.
2.1.5 Siklus Hidup Basis Data (Database Life Cycle) Sangat penting untuk mengetahui bahwa tahapan dari siklus hidup basis data tidak sekuensial, tetapi meliputi beberapa jumlah repetisi dari tahapan yang sebelumnya melalui feedback loops. Ketika merancang dari sebuah basis data medium ke basis data yang besar dengan berpuluh-puluh pengguna, dengan menggunakan ribuan query dan program aplikasi, siklus hidup dapat menjadi lebih kompleks.
Tabel 2.1 Tahapan dan Aktivitas Utama dari Siklus Hidup Basis Data Stage
Main Activities
Database Planning
Merencanakan bagaimana fase siklus hidup dapat terealisasi dengan sangat efisien dan efektif
12 System Definition
Menspesifikasikan Scope dari basis data
Requirement collection and analysis
Mengumpulkan
dan
menganalisis
kebutuhan informasi perusahaan Database design
Perancangan
basis
data
konseptual,
logikal, fisikal DBMS selection (optional)
Menyeleksi
DBMS
untuk
database
system Application Design
Merancang user interface dan program aplikasi
Prototyping
Membangun model dari database system
Implementation
Membuat definisi fisik basis data
Data Conversion and Loading
Load data dari sistem lama ke sistem baru
Testing
Mengecek error dan validasinya
Operational Maintenance
Memonitor aplikasi sistem yang sudah diimplementasikan
13 Tahap-tahap dari siklus hidup aplikasi basis data digambarkan sebagai berikut :
Gambar 2.1 Tahapan dalam Siklus Hidup Aplikasi Basis Data
14 2.1.6 Normalisasi Definisi normalisasi menurut Connolly (2002,p376), adalah cara untuk membuat suatu himpunan yang saling berhubungan dengan sifat-sifat yang memenuhi kebutuhan suatu perusahaan. Tujuan dari normalisasi adalah untuk menghasilkan representasi atau penyusunan yang akurat dari data, hubungan, dan batasan-batasan. Tujuan dilakukannya normalisasi : 1.
Mencegah kemungkinan terjadinya update anomalies (redundansi data). Update anomalies merupakan suatu bentuk kumpulan data dimana data-data yang sudah ada disimpan secara berulang-ulang sehingga memperumit proses dan sulit untuk dipahami.
2.
Untuk memvalidasi apakah kebutuhan bisnis sebenarnya sudah sesuai dengan bentuk relasinya. Salah satu konsep utama yang berhubungan dengan normalisasi adalah
ketergantungan
fungsional
(Functional
dependency).
Ketergantungan fungsional menggambarkan hubungan antara atribut dalam sebuah relasi. Ketergantungan fungsional adalah sebuah sifat dari makna (semantic) pada atribut dalam sebuah relasi. Maknanya (semantic) mengindikasikan bagaimana atribut berelasi antara satu dengan yang lainnya, dengan menentukan ketergantungan fungsional diantara atribut. Jika sebuah ketergantungan fungsional muncul, atribut atau kumpulan atribut pada sebelah kiri anak panah disebut sebagai determinan.
15 Hal penting yang perlu diperhatikan dalam proses normalisasi adalah hanya bentuk normal pertama (First normal form / 1NF) yang menjadi kritis dalam membuat relasi. Semua bentuk normal berikutnya adalah optional. Tetapi untuk menghindarkan update anomalies biasanya dianjurkan sampai tahap ketiga (3NF). Normalisasi yang umum dipakai adalah sampai dengan bentuk normal yang ketiga. Berikut adalah penjelasan bentuk normal pertama sampai ketiga :
2.1.6.1 Bentuk Tidak Normal (Unnormalized Form / UNF) Unnormalized form (UNF) adalah sebuah tabel yang mengandung satu atau lebih bagian yang berulang (repeating group).
2.1.6.2 Bentuk Normal Pertama (First Normal Form / 1NF) Untuk membentuk normalisasi pertama (1NF) repeating groups harus dihilangkan. Untuk mentransfer tabel unnormalized ke tabel normalisasi pertama kita harus mencari dan memindahkan data-data yang berulang. Suatu hubungan dikatakan normal pertama jika : • Setiap baris dan kolom berisi atribut yang bernilai tunggal. • Primary key telah ditentukan. • Multi value telah dihilangkan.
16 2.1.6.3 Bentuk Normal Kedua (Second Normal Form / 2NF) Normalisasi kedua (2NF) adalah sebuah relasi pada 1NF dan setiap atribut yang non primary key adalah fully functionally dependent dapat diciptakan dengan menghilangkan partial dependency. Suatu hubungan dikatakan normal kedua jika : • Berada pada normal pertama. • Atribut non primary key telah dihilangkan atau semua atribut non-primary key bergantung sepenuhnya kepada primary key.
2.1.6.4 Bentuk Normal Ketiga (Third Normal Form / 3NF) Normalisasi ketiga (3NF) dilakukan dengan cara melihat apakah terdapat atribut non primary key yang bergantung secara fungsional terhadap atribut non primary key lainnya (Transitive Dependence). Dengan cara yang sama, maka setiap ketergantungan transitive dipisahkan. Suatu hubungan dikatakan normal ketiga jika : • Berada pada normal pertama dan normal kedua. • Setiap atribut non primary key tidak memiliki dependency transitive terhadap primary key.
2.1.7 Model Entitas Relasional (Entity Relational Modelling)
17 Entity relational modelling merupakan sebuah model data yang didasarkan pada
konsep
matematika
dari
relasi,
yang
secara
fisik
direpresentasikan sebagai tabel. Dalam model relasional, semua data terstruktur secara logis dalam sejumlah relasi. Setiap relasi memiliki nama, dan terdiri dari sejumlah atribut.
2.1.7.1 Tipe Entitas (Entity Types) Tipe entitas adalah sekumpulan objek yang memiliki properti yang sama, didefinisikan oleh perusahaan yang keberadaannya independent. Sebuah tipe entitas memiliki keberadaan yang bebas dan bisa menjadi objek dengan keberadaan fisik (nyata) atau menjadi objek dengan keberadaan konseptual (abstrak). Ini menunjukkan bahwa perancangan yang berbeda akan menghasilkan identifikasi entitas yang berbeda pula. Suatu objek dan tipe entitas yang dapat diidentifikasikan secara unik disebut juga entity occurrence. Sebuah entitas digambarkan dalam bentuk segiempat yang dijelaskan dengan nama dari entitas tersebut, yang biasanya merupakan kata benda tunggal. Dalam UML, huruf pertama dari entitas adalah huruf kapital.
Nama Entity
18
Gambar 2.2 Contoh Tipe Entitas (Sumber Connolly, 2002, p333)
2.1.7.2 Atribut (Attribute) Menurut Connolly (2002,pp338-342), sifat tertentu dari entitas disebut atribut. Atribut menyimpan nilai dari setiap entity occurrence dan disimpan di dalam basis data. Attributes domain adalah sejumlah nilai yang diperkenankan untuk satu atau lebih atribut. Setiap atribut yang dihubungkan dengan sejumlah nilai disebut domain. Domain menetapkan nilai potensial sebuah atribut yang bisa disimpan atau sama dengan konsep domain pada model relasional. Simple attribute adalah suatu susunan atribut dari komponen tunggal dengan keberadaan yang bebas (independent exsistence). Simple attribute tidak dapat dibagi ke dalam komponen yang lebih kecil lagi. Sedangkan Composed attribute adalah sebuah susunan atribut dari banyak komponen dengan sebuah keberadaan yang bebas dari masing-masingnya. Dalam hal ini beberapa atribut dapat dipisahkan menjadi komponen yang lebih kecil lagi.
19 Single value attribute adalah atribut yang hanya menyimpan nilai tunggal untuk suatu sifat dari entitas. Multi-valued attribute adalah atribut yang bisa menyimpan nilai lebih dari satu untuk suatu sifat dari entitas. Derived attribute adalah atribut yang menunjukkan nilai, diperoleh dari atribut atau kumpulan atribut yang berhubungan, tidak terlalu dibutuhkan dalam tipe entitas yang sama.
2.1.7.3 Tipe Relasi (Relationship types) Menurut
Connolly
(2002,p334),
relationship
types
adalah
sekumpulan hubungan antara satu atau lebih tipe-tipe entitas. Entitas yang berkaitan dalam sebuah tipe relasi dikenal sebagai participant dalam relasi. Derajat dari relasi adalah jumlah dari partisipasi tipe entitas dalam sebuah tipe relasi tertentu. Sebuah relasi berderajat dua disebut binary, relasi berderajat tiga disebut sebagai ternary, dan relasi berderajat empat disebut sebagai quatenary.
20 Tipe-tipe relasi yaitu : • One-to-one Relationship
Staff entity type (staffNo)
Manages
Branch entity type
Relationship type
(branchNo)
Gambar 2.3 A Relationship One-to-one (1:1) (Sumber: Connolly, p345)
Gambar di atas menggambarkan relationship one-to-one antara entitas Staff dan entitas Branch, dimana satu orang staff hanya mengontrol satu cabang dan satu cabang hanya dikontrol oleh satu orang staff.
21 • One-to-many Relationship
Staff enttity
Oversees
Property For Rent entity
Gambar 2.4 A Relationship One-to-many (1:*) (Sumber: Connolly, p346)
Gambar di atas menggambarkan relationship one-to-many yang sering terjadi antara entitas Staff dengan entitas Properti, dimana dalam relasi ini seorang staff memungkinkan untuk mengurus (oversees) lebih dari satu properti, sedangkan satu properti hanya dapat diurus oleh satu staff. • Many-to-many Relationship
Newspaper entity
Advertise
Property For Rent enttity
Gambar 2.5 A Relationship Many-to-many (*:*) (Sumber: Connolly, p348)
22 Gambar di atas menggambarkan relationship many-to-many yang terjadi diantara entitas Newspaper dengan entitas Property, dimana satu property dapat dipasarkan (advertise) pada lebih dari satu koran, begitu juga satu buah koran dapat memasarkan lebih dari satu property.
2.1.7.4 Key Super key adalah sekumpulan dari satu atau lebih atribut yang diambil untuk mengidentifikasikan secara unik sebuah entitas dalam sebuah kumpulan entitas. Candidate key adalah sejumlah kecil atribut yang secara unik mengenali setiap occurrence dalam tipe entitas. Primary key adalah candidate key yang digunakan untuk mengenali secara unik setiap occurrance key. Pemilihan primary key untuk sebuah entitas adalah berdasarkan pada pertimbangan panjang atribut, jumlah minimal dari kebutuhan atribut, dan seterusnya. Alternate key adalah candidate key yang tidak terpilih menjadi primary key. Foreign key adalah suatu atribut atau kumpulan atribut di suatu tabel yang digunakan di tabel lainnya sehingga berfungsi sebagai penghubung informasi antara tabel. Composite key adalah candidate key yang terdiri lebih dari satu atribut.
23 2.1.8 Tahap-tahap Perancangan Basis Data Menurut Connolly (2002,p418), metodologi perancangan basis data adalah sebuah pendekatan terstruktur yang menggunakan prosedur, teknik, tool, dan dokumentasi yang mendukung dan memfasilitasi proses perancangan. Perancangan basis data dibagi menjadi tiga tahapan utama yang dinamakan perancangan basis data konseptual (conseptual databse design), perancangan basis data logical (logical database design) dan perancangan basis data fisikal (physical database design).
2.1.8.1 Perancangan Basis Data Konseptual (Conceptual Database Design) Perancangan basis data konseptual adalah proses membangun model informasi yang digunakan organisasi, bebas dari semua pertimbangan fisik (Connolly, 2002, p419). Langkah-langkah dalam metodologi perancangan basis data konseptual yaitu :
¾ Langkah 1 Membangun Model Konseptual Data Lokal (Local Conceptual Data Model) untuk setiap pandangan pengguna Bertujuan untuk memecah rancangan menjadi tugas-tugas yang dapat diatur dengan memeriksa sudut pandang yang berbeda dari pengguna di dalam organisasi (Connolly, 2002, p421). Hasil dari langkah ini berupa pembuatan satu atau lebih model konseptual data lokal yang merupakan penggambaran yang tepat dan lengkap dari suatu organisasi dilihat dari para
24 pengguna yang berbeda. Tugas-tugas yang dilakukan pada langkah ini terdiri dari:
Langkah 1.1 Mengidentifikasi Tipe Entitas (Entity Type) Entity type dapat dikenali dengan mengidentifiksikan kata benda atau frase kata benda pada spesifikasi kebutuhan pengguna, objek besar seperti orang (people), tempat (place), benda (thing) atau konsep (concept). Alternatif lain adalah dengan mencari objek yang keberadaannya bebas.
Langkah 1.2 Mengidentifikasi Tipe Relasi (Relationship Type) Bertujuan untuk mengidentifikasi hubungan yang penting yang ada antara tipe entitas yang telah diidentifikasi sebelumnya. Relationship type diidentifikasikan dengan mencari kata kerja atau suatu kata yang berhubungan dengan kata kerja.
Langkah 1.3 Mengidentifikasi dan Menghubungkan Atribut dengan Entitas dan Relasi Tujuannya untuk menghubungkan atribut dengan entitas dan relasi yang tepat. Atribut yang dimiliki oleh setiap entitas dan relasi harus memenuhi karakteristik atribut yaitu simple/composite attribute, single/multi-valued attribute, dan derived attribute.
25 Langkah 1.4 Menentukan Domain Attribute Domain adalah sekumpulan nilai dimana satu atau lebih atribut memperoleh nilainnya (Connolly, 2002, p430).
Langkah 1.5 Menentukan Atribut Primary Key dan Candidate Key Tujuannya untuk mengidentifikasi candidate key setiap tipe entitas, dan jika terdapat lebih dari satu candidate key maka terpilih satu sebagai primary key.
Langkah 1.6 Mempertimbangkan Penggunaan Enhance Modeling Concept (pilihan) Maksud
dari
langkah
ini
adalah
untuk
menentukan
specialization, generalization, aggregation, dan composition. Specialization
merupakan
suatu
proses
memaksimalkan
perbedaan-perbadaan antara anggota-anggota sebuah entitas dengan cara mengidentifikasi karakteristik yang membedakan entitas tersebut (Connolly, 2002, p362). Generalization
merupakan
suatu
proses
meminimalkan
perbedaan antar entitas dengan cara mengidentifikasi sifat umum entitas (Connolly 2002, p363). Aggregation menggambarkan relasi ‘has-a’ atau ‘is-part-of’ antara tipe entitas dimana yang satunya mewakili ‘whole’ (seluruhnya) dan yang satunya lagi mewakili ‘part’ (bagian) (Connolly 2002, p371).
26 Langkah 1.7 Mengecek Redudancy Bertujuan memeriksa model konseptual untuk menghindari adanya redudancy atau pengulangan data. Ada dua kegiatan yang dapat dilakukan pada tahap ini: 1) Memeriksa Kembali One-to-One Relationship
(1:1)
Kemungkinan ada dua entitas yang menggambarkan objek yang sama dalam organisasi. Oleh karena itu, kedua entitas tersebut harus digabungkan. 2)
Menghilangkan Relasi yang Redundan Suatu relasi menjadi redundan jika informasi yang sama dihasilkan melalui relasi yang lainnya. Untuk meminimalkan data model maka relasi yang redundan harus dihilangkan.
Langkah 1.8 Memvalidasi Model Konseptual dengan Transaksi Bertujuan untuk memastikan model konseptual data lokal mendukung transaksi yang dibutuhkan oleh pandangan pengguna (Connolly, 2002, p435). Dua pendekatan untuk memastikan model data lokal konseptual mendukung kebutuhan transaksi: 1)
Menggambarkan Transaksi (Describing The Transaction) Memeriksa semua informasi (entity, relationship, dan attribute) yang dibutuhkan setiap transaksi yang disediakan oleh model (Connolly, 2002, p435).
2)
Menggunakan Transaction Pathways
27 Memvalidasi model data terhadap kebutuhan transaksi dengan menggambar diagram yang mewakili pathway yang diambil oleh setiap transaksi secara langsung pada E-R diagram (Connolly, 2002, p435).
Langkah 1.9 Melihat Kembali Conceptual Data Model dengan Pengguna Langkah ini dilakukan dengan tujuan untuk memastikan bahwa model data merupakan representasi yang benar bagi setiap pandangan.
2.1.8.2 Perancangan Basis Data Logikal (Logical Database Design) Perancangan basis data logikal adalah proses membangun model informasi yang digunakan organisasi berdasarkan model data tertentu, tetapi tidak tergantung dari Database Management System (DBMS) dan pertimbangan fisik lainnya (Connolly, 2002, p441). Langkah-langkah dalam metodologi perancangan basis data logikal yaitu : ¾ Langkah 2 Membangun dan Memvalidasi Model Logikal Data Lokal (Local Logical Data Model) Bagi Setiap Pandangan Pengguna Tujuannya untuk membangun sebuah model logikal data lokal yang
mewakili pandangan tertentu dari organisasi dan kemudian
memvalidasi model ini untuk memastikan bahwa stukturnya benar (dengan
28 menggunakan teknik normalisasi) dan untuk memastikan dukungannya terhadap transaksi-transaksi yang dibutuhkan. Kegiatan yang dilakukan pada langkah ini meliputi :
Langkah 2.1 Menghilangkan Fitur-fitur yang Tidak Sesuai dengan Model Relasional (pilihan). Bertujuan untuk mengambil inti dari model data konseptual dengan menghilangkan hubungan-hubungan antara tabel yang tidak sesuai dengan model relasional.
Langkah 2.2 Membuat Tabel-tabel Dari Model Logikal Data Lokalnya. Tujuannya adalah untuk membuat tabel dari model logikal data lokal untuk mempresentasikan (mewujudkan) entitas, relasi dan atribut-atribut yang sudah diketahui.
Langkah 2.3 Memvalidasi Relasi Menggunakan Normalisasi. Tujuannya adalah untuk memvalidasi tabel-tabel dengan menggunakan normalisasi sehingga kemungkinan redudancy data bisa diperkecil.
29 Langkah 2.4 Memvalidasi Relasi Terhadap Transaksi - Transaksi Pengguna. Tujuannya adalah untuk menjamin bahwa relasi-relasi pada model logikal data lokal mendukung transaksi-transaksi yang dibutuhkan oleh pengguna, seperti terinci pada spesifikasi kebutuhan pengguna.
Langkah 2.5 Mendefinisikan Batasan - Batasan Keterkaitannya. Tujuannya adalah untuk mendefinisikan keterkaitan pada batasan-batasan yang diperlakukan untuk menampilkan data.
Langkah 2.6 Melakukan Pemeriksaan Ulang Bersama Pengguna. Tujuannya adalah untuk memeriksa apakah definisi - definisi yang kita buat sudah sesuai dengan keinginan pengguna atau perlu ada perbaikan dan penambahan.
¾ Langkah 3 Membuat dan Memvalidasikan Model Logikal Data Global. Tujuannya adalah untuk mengkombinasikan masing-masing model logikal data lokal ke satu model logikal data global yang mewakili suatu bentuk perusahaan.
30 Langkah 3.1 Menggabungkan Model Logikal Data Lokal Menjadi Model Logikal Data Global. Tujuan adalah untuk membuat model logikal data global dari model logikal data lokal yang sudah ada sehingga membentuk model data dari suatu perusahaan.
Langkah 3.2 Memvalidasi Model Logikal Data Global. Tujuannya adalah untuk memeriksa model logikal data global yang sudah dibuat dengan menggunakan proses normalisasi dan memastikan model data tersebut dapat bekerja dengan baik untuk memenuhi transaksi yang dibutuhkan oleh pengguna.
Langkah 3.3 Mengantisipasi Perkembangan Selanjutnya. Tujuannya adalah untuk memastikan apakah diperlukan perubahan-perubahan yang cukup penting untuk kebutuhan di masa depan.
Langkah 3.4 Memeriksa kembali Model Data Ini ke Pengguna. Tujuannya adalah untuk memastikan apakah model data yang kita buat sudah sesuai dengan kebutuhan perusahaan. Hasil akhir dari perancangan logikal basis data adalah merancang suatu model informasi berdasarkan model data spesifik yang ada (seperti model relasional), tetapi tidak tergantung terhadap suatu DBMS dan perangkat keras lainnya. Logikal basis data
31 merancang suatu map untuk setiap konseptual data lokal. Jika terdapat lebih dari satu view, maka model logikal data lokal akan dikombinasikan menjadi suatu model logikal data global yang merepresentasikan semua view dari suatu perusahaan.
2.1.8.3 Perancangan Basis Data Fisikal (Physical Database Design) Suatu proses membuat penerapan basis data yang sudah kita rancang. Tujuan dari langkah ini menurut Connolly (2002, p282) adalah untuk mendeskripsikan pengimplementasian dari suatu basis data pada media penyimpanan secondary, itu juga akan mendeskripsikan dasar dari suatu relasi, file perusahaan, dan juga indeks yang digunakan untuk mencapai suatu keefisienan pengaksesan data dan batasan-batasan integritas serta ukuran keamanan.
¾ Langkah 4 Menerjemahkan Model Data Logikal yang Berlaku Global ke dalam Sistem DBMS. Tujuannya adalah untuk membuat rancangan basis data relasional dari model logikal data global yang dapat digunakan pada suatu DBMS.
Langkah 4.1 Merancang Relasi Utama. Tujuannya adalah untuk mendapatkan relasi diantara logikal data global saat diterapkan pada suatu DBMS.
32 Langkah 4.2 Merancang Representasi dari Data yang Sudah Diturunkan. Tujuannya
adalah
untuk
membuat
representasi dengan
menerapkan data-data ke dalam DBMS.
Langkah 4.3 Merancang Batasan - Batasan Perusahaan. Tujuannya adalah merancang batasan-batasan yang ditentukan perusahaan ke dalam DBMS.
¾ Langkah 5 Merancang Representasi Fisikal Tujuannya adalah untuk menentukan pengaturan file yang optimal untuk menyimpan tabel-tabel dan sistem indeks sehingga sistem dapat memenuhi kebutuhan yang diinginkan.
Langkah 5.1 Menganalisa Transaksi. Tujuannya adalah untuk memahami fungsi dari transaksi pada suatu basis data dan menganalisa transaksi-transaksi yang penting.
Langkah 5.2 Memilih Cara Pengaturan File. Tujuannya adalah untuk menentukan pengaturan file yang paling efisien.
33 Langkah 5.3 Memilih Cara Penomoran. Tujuannya adalah untuk menentukan metode penomoran yang akan meningkatkan efisiensi proses akses.
Langkah 5.4 Memperkirakan Kapasitas Disk yang Diperlukan. Tujuannya adalah untuk menentukan kapasitas yang diperlukan basis data.
¾ Langkah 6 Merancang Tampilan Layar Tujuannya adalah untuk merancang tampilan untuk pengguna sesuai kebutuhan masing-masing pengguna yang sudah teridentifikasi sebelumnya pada tahap pencarian dan analisa kebutuhan.
¾ Langkah 7 Merancang Mekanisme Keamanan. Tujuannya adalah untuk merancang sistem keamanan basis data sesuai dengan apa yang diinginkan pengguna. Definisi dari keamanan basis data adalah suatu mekanisme yang memproteksi basis data dari suatu kejadian yang disengaja maupun yang tidak disengaja. Suatu basis data merupakan sumber dari perusahaan yang essential yang perlu dilindungi dengan menggunakan suatu kontrol yang memadai. Beberapa kasus keamanan basis data yang perlu diperhatikan, anatara lain :
34 1.
Pencurian data
2.
Kehilangan kerahasiaan suatu data
3.
Kehilangan hak pribadi
4.
Kehilangan integritas
5.
Kehilangan ketersediaan data
Hasil akhir dari perancangan basis data fisikal adalah suatu proses yang mendeskripsikan suatu implementasi dari suatu basis data pada media penyimpanan.
2.1.9 Data Flow Diagram (DFD) Menurut Whitten, Bentley, dan Dittman (2004, p344) Data Flow Diagram merupakan model proses yang digunakan untuk menggambarkan aliran data yang melalui sistem dan pekerjaan atau proses – proses yang dilakukan oleh sistem. Data Flow Diagram juga disebut sebagai bubble chart, transformation graph, dan process model. Komponen-komponen Data Flow Diagram adalah sebagai berikut : • Terminator / Entitas Luar Adalah entitas di luar sistem yang berkomunikasi atau berhubungan langsung dengan sistem. Terdapat dua jenis entitas luar : a)
Terminator Sumber
Merupakan Terminator yang menjadi sumber. b) Terminator Tujuan Merupakan terminator yang menjadi tujuan data atau informasi sistem.
35 •
Proses
Komponen proses menggambarkan transformasi input menjadi output. Penamaan proses disesuaikan dengan proses atau kegiatan yang sedang dilakukan.
Ada
beberapa
hal
yang
diperhatikan
tentang
proses : a) Proses harus memiliki input dan output b) Proses dapat dihubungkan dengan komponen terminator, data store atau proses melalui alur data. c) Sistem / bagian / divisi / departemen yang sedang dianalisis oleh professional sistem digambarkan dengan komponen proses. •
Data Stores / Penyimpanan Data
Komponen ini digunakan untuk membuat model sekumpulan paket data dan diberi nama dengan kata benda bersifat jamak. Data store dapat berupa file / basis data yang tersimpan dalam disket, harddisk atau bersifat manual seperti buku alamat, file folder. Yang perlu diperhatikan tentang data store : a) Alur data dari proses menuju data store, hal ini berarti data store berfungsi sebagai tujuan / tempat penyimpanan dari suatu proses (process write). b) Alur data dari data store ke proses, hal ini berarti data store berfungsi sebagai sumber / proses memerlukan data (process read). c) Alur data dari proses menuju data store dan sebaliknya berarti berfungsi sebagai sumber dan tujuan.
36 •
Alur Data Alur data digunakan untuk menerangkan perpindahan data / paket data dari satu bagian ke bagian lainnya.
Terminator
Proses
Data Store
Alur Data
Gambar 2.6 Gambar Komponen DFD
2.2 Teori Khusus
2.2.1 Teori Pembelian Menurut Mulyadi (2001, p299) kegiatan pembelian digunakan dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Transaksi pembelian dapat digolongkan menjadi dua, yaitu: •
Pembelian Lokal
Adalah pembelian barang dari pemasok dalam negeri. •
Pembelian Import
Adalah pembelian barang dari pemasok luar negeri.
37 Menurut Mulyadi (2001, p299) fungsi yang terkait dalam sistem pembelian adalah : 1. Fungsi Pembelian Dalam sistem pembelian,
fungsi ini bertanggung
jawab untuk
memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan order pembelian kepada pemasok yang dipilih. 2. Fungsi Penerimaan Bertanggung jawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas barang yang diterima dari pemasok untuk menentukan dapat atau tidaknya barang tersebut diterima oleh perusahaan. 3. Fungsi Gudang Bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang dan untuk menyimpan barang yang telah diterima oleh fungsi penerimaan. 4. Fungsi Akuntansi Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi pencatat utang dan fungsi pencatat persediaan. Fungsi pencatat utang bertanggung jawab untuk mencatat transaksi pembelian ke dalam register bukti kas keluar dan untuk menyelanggarakan arsip dukungan sumber (bukti kas keluar) yang
berfungsi sebagai catatan utang atau
menyelenggarakan kartu utang sebagai buku pembantu utang. Fungsi pencatat persediaan bertanggung jawab untuk mencatat harga pokok persediaan barang yang dibeli ke dalam kartu persediaan.
38 2.2.2 Teori Penjualan Menurut Mulyadi (2001, p202), kegiatan penjualan terdiri dari transaksi penjualan barang atau jasa, baik secara kredit maupun secara tunai.
2.2.2.1 Penjualan Kredit Dalam transaksi penjualan kredit, jika order dari pelanggan telah dipenuhi dengan pengiriman barang atau penyerahan jasa, untuk jangka waktu tertentu perusahaan memiliki piutang kepada pelanggannya. Kegiatan penjualan kredit ini ditangani oleh perusahaan melalui sistem penjualan kredit.
2.2.2.2 Piutang Menurut Mulyadi (2005, p257), prosedur pencatatan piutang bertujuan untuk mencatat mutasi piutang perusahaan kepada setiap debitur. Mutasi piutang disebabkan oleh transaksi penjualan kredit, penerimaan kas dari debitur, retur penjualan, dan penghapusan piutang.
2.2.2.3 Retur Penjualan Menurut Mulyadi (2001, p226), transaksi retur penjualan terjadi jika
perusahaan
menerima
pengembalian
barang
dari
pelanggan.
Pengembalian barang dari pelanggan harus diotorisasi oleh fungsi penjualan dan diterima oleh fungsi penerimaan.
