BAB 2 LANDASAN TEORI
Basis Data (Database) sekarang merupakan bagian dari kehidupan kita seharihari yang biasanya tidak kita sadari penggunaannya. Basis data merupakan koleksi dari data yang berhubungan dan Sistem Manajemen Basis Data (Database Management System/DBMS) merupakan perangkat lunak (software) yang mengatur dan mengontrol akses ke basis data. Aplikasi basis data merupakan program yang berinteraksi dengan basis data pada beberapa point dalam eksekusinya. Kita juga menggunakan istilah sistem basis data untuk memasukkan koleksi program aplikasi yang berinteraksi dengan basis data.
2.1
Pengertian Basis Data Menurut Connolly (2002, p14), Basis data adalah kumpulan data yang berhubungan secara logical yang dibagi, dan mendeskripsikan data, didesain untuk menemukan kebutuhan informasi pada suatu organisasi. Ramakrishnan (2003, p4) menyatakan, Basis data adalah koleksi data, secara tipikal menggambarkan aktivitas-aktivitas dari satu atau lebih organisasi yang terkait. Charles (1984, p5) mengemukakan, Basis data adalah koleksi dari bermacam-macam file yang merepresentasikan sumber informasi lengkap, biasanya untuk bisnis.
6
7 Hutchinson dan Sawyer (1996, p349) mengungkapkan, Basis data adalah kumpulan data yang terintegrasi yang diorganisasikan sebagai byte, field, record dan file. Menurut Kamus Istilah Akuntansi (1999, p125), Basis data adalah tempat penyimpanan data yang berkaitan yang dikelola secara bebas terpisah dari segala program khusus atau aplikasi sistem informasi. Dapat menyediakan berbagai macam sistem dalam organisasi. Intinya, merupakan lemari berkas kabinet elektronik yang dapat menyediakan inti dari informasi umum dalam sebuah program.
2.2
Pengertian DBMS Menurut Connolly (2002, p16), Sistem Manajemen Basis Data adalah sistem software yang memungkinkan pemakai (user) untuk mendefinisikan, membuat, memelihara, dan mengontrol akses ke basis data. Ramakrishnan (2003, p4) menyatakan, Sistem Manajemen Basis Data adalah software yang didesain untuk mendukung dalam pemeliharaan dan pemanfaatan koleksi data dalam jumlah besar. Hutchinson
dan
Sawyer
(1996,
p349)
mengemukakan,
Sistem
Manajemen Basis Data adalah sistem komputer untuk mendefinisikan, membuat, memanipulasi, memgontrol, mengatur dan menggunakan basis data. Menurut Kamus Istilah Akuntansi (1999, p125), Sistem Manajemen Basis Data adalah perangkat lunak yang dipakai untuk mengelola data dalam basis data. Merupakan satu set program yang menyediakan penetapan, pengawasan, dan pemasukan data.
8 Silberschatz (2002, p1) mengungkapkan, Sistem Manajemen Basis Data adalah kumpulan data yang saling berhubungan dan kumpulan program untuk mengakses data-data tersebut. Kumpulan data biasanya merujuk kepada basis data, mengandung informasi
yang relevan dengan enterprise. Tujuan utama
DBMS adalah untuk menyediakan dan memperoleh informasi basis data yang nyaman (convenient) dan efisien. Sistem basis data didesain untuk mengatur sejumlah besar informasi, manajemen data termasuk menjelaskan struktur untuk penyimpanan
informasi dan menyediakan mekanisme untuk manipulasi
informasi.
2.3
Komponen Lingkungan DBMS Menurut Connolly (2002, pp18-20), ada lima komponen utama dalam lingkungan DBMS, yaitu : ¾
Perangkap Keras (hardware), terdiri dari : o
Penyimpanan secondary (magnetic disk), I/O device ex : disk drives), device Controller, I/O Channels, dan lainnya.
o
Hardware processor dan main memory, digunakan untuk mendukung saat eksekusi system software database.
¾
Perangkat Lunak, terdiri dari : DBMS, sistem operasi, software jaringan dan program aplikasinya.
¾
Data, digunakan oleh organisasi dan data ini digambarkan dalam bentuk skema.
¾
Prosedur adalah instruksi dan aturan yang harus diterapkan untuk mendesain dan menggunakan basis data dan DBMS.
9 ¾
Orang, terdiri dari : o
Application Programmers, bertanggungjawab untuk membuat aplikasi basis data dengan menggunakan bahasa pemrograman yang ada.
o
End Users, siapapun yang berinteraksi dengan system secara online melalui workstation/terminal.
o
DA (Data Administrator), seseorang yang berwenang untuk membuat keputusan stategis dan kebijakan mengenai data yang ada.
o
DBA (DataBase Administrator), menyediakan dukungan teknis untuk implementasi keputusan tersebut, dan bertanggungjawab atas keseluruhan kontrol system pada level teknis.
Hardware
Software
Mesin
Data
Prosedur
Jembatan
Orang
Manusia
Gambar 2.01 Komponen DBMS
2.4
Entity-Relationship Modeling ER (Entity Relationship) data model didasarkan pada presepsi dunia nyata yang terdiri dari kumpuln objek dasar , yang disebut entiti dan relationship antara objek-objek ini.
10 2.4.1
Tipe Entity Tipe entity merupakan konsep dasar dari suatu model ER. Menurut Connolly (2002, p331), Tipe entity adalah kumpulan dari objek dengan property yang sama, yang diidentifikasi oleh perusahaan mempunyai keberadaan yang independen. Keberadaan tipe entity dapat berupa fisik atau ‘nyata’ dan conceptual atau ‘abstrak’. Entity occurrence adalah pengidentifikasian objek yang unik dari sebuah tipe entity. Nama Entity
Staff
Branch
Gambar 2.02 Contoh Tipe Entity
2.4.2
Tipe Relationship Menurut Connolly (2002, p334), Tipe relationship adalah kumpulan hubungan yang mempunyai arti antara tipe entity.
Relationship occurrence
adalah hubungan yang diidentifikasi secara unik, yang meliputi keberadaan dari setiap tipe entity yang berpartisipasi.
11
Nama Relationship
< Has Staff
"Branch has staff"
Branch
Gambar 2.03 Contoh Tipe Relationship
2.4.3
Derajat Relationship Menurut Connolly (2002, pp335-338), Derajat relationship adalah jumlah tipe entity yang berpartisipasi dalam sebuah relationship. Derajat relationship terdiri dari : ¾
Binary Relationship adalah relationship antara dua tipe entity.
¾
Ternary Relationship adalah relationship antara tiga tipe entity.
¾
Quaternary Relationship adalah relationship antara empat tipe entity.
¾
Unary
Relationship disebut juga
recursive
relationship, adalah
relationship antara satu tipe entity dimana tipe entity tersebut berpartisipasi lebih dari satu kali dengan peran yang berbeda.
12 'Private owner owns property for rent' POwns >
PrivateOwner
PropertyForRent Binary Relationship
Staff
Branch
Register
'Staff register a client at a branch'
Client Ternary Relationship Solicitor
Buyer
'Asolicitor arranges a bid on behalf of buyer supported by a financial institution'
Financial Institution
Arranges
Bid Quaternary Relationship Role name
'Staff (Supervisor) supervises staff (Supervisee)'
< Supervises Supervisor
Role name
Supervisee
Staff
Unary Relationship
Gambar 2.04 Contoh Derajat Relationship
13 2.4.4
Attribute Menurut Connolly (2002, pp338-340), Atribut adalah sifat atau property dari sebuah tipe entity atau tipe relationship. Contohnya : sebuah entity karyawan digambarkan oleh kdKary, nmKary, almtKary dan jabatan. Atribut domain adalah himpunan nilai yang diperbolehkan untuk satu atau lebih atribut. Macam-macam atribut : ¾
Simple Attribute disebut juga Atomic Attribute, yaitu atribut yang terdiri dari satu komponen tunggal dengan keberadaan yang independen dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi.
¾
Composite Attribute yaitu atribut yang terdiri dari beberapa komponen dimana
masing-masing
komponen
memiliki
keberadaan
yang
independen. Misalkan atribut alamat dapat terdiri dari jalan, kota dan kode pos. ¾
Single-value Attribute yaitu atribut yang mempunyai nilai tunggal untuk setiap kejadian. Misalnya entity pemesanan memiliki satu nilai untuk attribut noPesan pada setiap kejadian.
¾
Multi-value Attribute yaitu atribut yang mempunyai beberapa nilai untuk setiap kejadian. Misalnya entity Karyawan memiliki beberapa nilai untuk attribut noTelp pada setiap kejadian.
¾
Derived Attribute yaitu atribut yang memiliki nilai yang dihasilkan dari satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entity.
14 2.4.5
Key Kita harus memiliki cara untuk menspesifikasikan bagaimana entity di dalam kumpulan entity dapat dibedakan. Maka , nilai dari nilai atribut sebuah entity harus sedemikian rupa agar dapat mengidentifikasi entity secara unik. Sebuah key memberikan kemudahan untuk mengidentifikasi kumpulan atribut yang mencukupi untuk dapat membedakan entity yang satu dengan yang lain. Key juga membantu mengidentifikasi relationship secara unik dan membedakan relationship antara yang satu dengan yang lainnya. Menurut Connolly (2002, pp340-341), Key terbagi atas : ¾
Candidate Key adalah jumlah minimal atribut-atribut yang secara unik mengidentifikasikan setiap kejadian pada tipe entity.
¾
Primary
Key
adalah
candidate
key
yang
terpilih
untuk
mengidentifikasikan setiap kejadian pada tipe entity secara unik. ¾
Composite Key adalah candidate key yang terdiri dari dua atau lebih atribut.
2.4.6
Strong and Weak Entity Type Menurut Connolly (2002, pp341-342), Strong entity type adalah tipe entity yang keberadaannya tidak tergantung pada tipe entity lainnya. Sedangkan weak entity type adalah tipe entity yang keberadaannya tergantung pada tipe entity lainnya. Strong entity type disebut juga parent, owner dominant sedangkan weak entity type disebut child, dependent dan subordinate.
15 Strong Entity
Client
Weak Entity
States >
clientNo {PK} name fName lName telNo
Preference prefType maxRent
Gambar 2.05 Contoh Strong dan Weak Tipe Entity
2.4.7
Structural Constraint Batasan atau kendala utama pada relationship adalah multiplicity. Menurut Connolly (2002, p344), Multiplicity adalah jumlah (atau jangkauan) dari kejadian yang mungkin terjadi pada suatu entity yang terhubung ke satu kejadian dari entity lain yang berhubungan melalui suatu relationship. Menurut Connolly (2002, pp345-348), ada 3 tipe relationship binary yang menggunakan batasan enterprise yaitu : ¾
Relasi satu-satu (1:1) yaitu relasi antara dua tipe entity dimana satu tipe entity berelasi tepat satu atau nol dengan tipe entity lainnya.
¾
Relasi satu-banyak (1:*) yaitu relasi antara dua tipe entity dimana satu tipe entity berelasi nol, satu atau banyak dengan tipe entity lainnya.
¾
Relasi banyak-banyak (*:*)yaitu relasi antara dua tipe entity dimana tipe entitynya saling berelasi nol, satu atau banyak.
16 'A member of staff can manage zero or one branch'
'Each branch is managed by one member of staff'
Manages >
Staff staffNo
1..1
Branch branchNo
0..1
Multiplicity
Relasi satu-satu (1:1)
'Each property for rent is overseen by zero or one member of staff'
'Each member of staff overssen zero or more properties for rent'
Oversees >
Staff staffNo
0..1
PropertyForRent propertyNo
0..*
Relasi satu-banyak (1:*)
'Each property for rent is advertised in zero or more newspapers'
Newspaper
'Each newspaper advertises one or more properties for rent'
PropertyForRent
Advertises >
newspaperName
0..*
1..*
propertyNo
Relasi banyak-banyak (*:*)
Gambar 2.06 Contoh Tipe-tipe relationship pada Binary
17 2.4.8
Multiplicity untuk relasi yang komplek Menurut Connolly (2002, p349), Multiplicity untuk relasi yang kompleks adalah jumlah (atau jangkauan) dari kejadian yang mungkin dari suatu entity dalam n-ary relationship ketika nilai entity yang lain (n-1) diketahui. Staff
Register 1..1
1..1
Branch
0..*
Client
Gambar 2.07 Contoh Multiplicity pada Relationship Ternary
Cara
alternatif
untuk
Arti
menggambarkan batasan multiplicity 0..1
Nol atau satu kejadian
1..1 (atau hanya 1)
Hanya satu kejadian
0..* (atau hanya *)
Nol atau banyak kejadian
1..*
Satu atau banyak kejadian
5..10
Minimum 5 dan maksimal 10 kejadian
0,3,6-8
Nol atau tiga atau enam, tujuh, atau delapan kejadian
Tabel 2.01 Tabel Multiplicity
18 Multiplicity dibentuk dari 2 macam batasan pada relationship, yaitu : ¾
Cardinality, menjelaskan jumlah maksimal dari kejadian relationship yang mungkin untuk entity yang berpartisipasi di dalam relationship tersebut.
¾
Participation, menetapkan apakah seluruh atau sebagian entity yang berpartisipasi dalam suatu relationship.
Cardinality
'One member of staff manages one branch'
'One branch is managed by one member of staff'
Manages >
Staff staffNo
Branch 0..1 branchNo
1..1
'not All staff manage branches' (optional participation for staff)
'All branches are managed' (mandatory participation for branch)
Participation Gambar 2.08 Cardinality dan Participation
2.5
Database Application Lifecycle Basis data merupakan komponen mendasar suatu sistem informasi, dimana pengembangan atau pemakaiannya harus dilihat dari perspektif yang
19 lebih luas berdasarkan kebutuhan organisasi. Database Aplication Lifecycle berdampingan dengan lifecycle dari sistem informasi. Sistem
Informasi
merupakan
sumberdaya
yang
memungkinkan
pengumpulan (collection), pengaturan (management), pengawasan (control) dan penyebaran (dissemination) informasi keseluruh organisasi. Database Planning
System Definition
Requirem ent collection and Analysis
Database Design Conceptual Database Design DBMS Selection
Application Design Logical Database Design
Physical Database Design
Prototyping
Im plem entation
Data conversion and loading
Testing
Operational M aintenance
Gambar 2.09 Tahapan dalam Database Application Lifecycle
20 2.5.1
Database Planning Perencanaan basis data merupakan perencanaan bagaimana tahapantahapan dalam lifecycle dapat direalisasikan seefektif dan seefisien mungkin. Perencanaan basis data harus terintegrasi dengan keseluruhan strategi sistem informasi dari organisasi. Terdapat 3 hal pokok yang berkaitan dengan strategi sistem informasi, yaitu : ¾
Identifikasi rencana dan sasaran (goals) dari enterprise termasuk mengenai sistem informasi yang dibutuhkan.
¾
Evaluasi sistem informasi yang ada untuk menetapkan kelebihan dan kekurangan yang dimiliki.
¾
Penaksiran kesempatan IT yang mungkin memberikan keuntungan kompetitif.
Metodologi untuk mengatasi hal tersebut diatas yaitu : ¾
Database Planning – Mission Statement : Mission statement untuk database project mendefinisikan tujuan utama dari aplikasi database. Mengarahkan database project, biasanya mendefinisikan perintah tugas (mission statement). Mission statement membantu menjelaskan kegunaan dari database project dan menyediakan alur yang lebih jelas untuk mencapai efektifitas dan efisiensi penciptaan dari suatu aplikasi database yang diinginkan.
¾
Database Planning – Mission Objectives : Ketika mission statement telah didefinisikan, maka mission objectives
didefinisikan.
Setiap
objective
(tujuan)
harus
21 mengidentifikasikan tugas khusus yang harus didukung oleh database. Dapat juga disertai dengan beberapa informasi tambahan yang menspesifikasikan pekerjaan yang harus diselesaikan, sumberdaya yang digunakan dan biaya untuk membayar kesemuanya itu.
2.5.2
System Definition Definisi system adalah menjelaskan batasan-batasan dan cakupan dari aplikasi basis data dan sudut pandang user atau pemakai yang utama. Sudut pandang pemakai mendefinisikan apa yang diwajibkan dari suatu aplikasi basis data dari perspektif aturan kerja khusus atau area aplikasi perusahaan. Sudut pandang pemakai diperlukan untuk memastikan bahwa tidak ada pemakai utama dari suatu basis data yang terlupakan ketika pembuatan aplikasi baru yang dibutuhkan dan membantu dalam pengembangan aplikasi basis data yang rumit atau komplek juga memungkinkan permintaan-permintaan dipecah ke dalam bagian-bagian yang lebih simple.
2.5.3
Requirement Collection and Analysis Analisis
dan
pengumpulan
kebutuhan
merupakan
suatu
proses
pengumpulan dan analisis informasi mengenai bagian organisasi yang didukung oleh aplikasi basis data, dan menggunakan informasi tersebut untuk identifikasi kebutuhan pemakai akan sistem yang baru. Informasi dikumpulkan untuk setiap user view utama meliputi
:
¾
Deskripsi data yang digunakan atau dihasilkan
¾
Detail mengenai bagaimana data digunakan/dihasilkan
22 ¾
Beberapa kebutuhan tambahan untuk aplikasi database yang baru
Informasi dianalisis untuk identifikasi kebutuhan agar disertakan dalam aplikasi basis data yang baru. Aktifitas penting lainnya, adalah menentukan bagaimana mengatur aplikasi basis data dengan multiple user view, yaitu : ¾
Pendekatan Terpusat (Centralized approach) Kebutuhan untuk setiap user view digabungkan menjadi sekumpulan kebutuhan. Sebuah global data model dibuat berdasarkan atas penggabungan kebutuhan (dimana merepresentasikan seluruh user view).
¾
Pendekatan Integrasi View (View integration approach) Kebutuhan untuk setiap user view digunakan untuk membangun model data terpisah untuk merepresentasikan user view tersebut. Hasil dari model data tersebut nantinya digabungkan dalam tahapan desain database. Model model yang merepresentasikan user view tunggal disebut local data model, dan tersusun atas diagram-diagram dan dokumentasi yang secara formal menggambarkan kebutuhan dari user view khusus terhadap database. Kemudian local data model digabungkan untuk menghasilkan global data model, yang merepresentasikan seluruh user view untuk database.
¾
Kombinasi keduanya (Combination of both approaches)
23 2.5.4
Database Design Desain basis data merupakan suatu proses pembuatan sebuah desain basis data yang akan mendukung tujuan dan operasi suatu perusahaan.
Tujuan
utamanya adalah: ¾
merepresentasikan data dan relationship antar data yang dibutuhkan oleh seluruh area aplikasi utama dan user group.
¾
Menyediakan model data yang mendukung segala transaksi yang diperlukan pada data.
¾
Menspesifikasikan desain minimal yang yang secara tepat disusun untuk memenuhi kebutuhan performa yang ditetapkan pada sistem (misal : waktu respon).
Pendekatan dalam desain basis data : ¾
Top-down Diawali dengan pembentukan model data yang berisi beberapa entitas high-level dan relationship, yang kemudian menggunakan pendekatan top-down secara berturut-turut untuk mengindentifikasikan entitas lower level, relationship dan atribut lainnya.
¾
Bottom-up Dimulai dari atribut dasar (yaitu, sifat-sifat entitas dan relationship), dengan analisis dari penggabungan antar atribut, yang dikelompokan kedalam suatu relasi yang merepresentasikan tipe dari entitas dan relationship antar entitas.
24 ¾
Inside-out Berhubungan dengan pendekatan bottom-up tetapi sedikit berbeda dengan identifikasi awal entitas utama dan kemudian menyebar ke entitas, relationship, dan atribut terkait lainnya yang lebih dulu diidentifikasi.
¾
Mixed Menggunakan pendekatan bottom-up dan top-down untuk bagian yang berbeda sebelum pada akhirnya digabungkan.
Tiga fase desain basis data: ¾
Conceptual database design Suatu proses pembentukan model dari informasi yang digunakan dalam perusahaan, independen dari keseluruhan aspek fisik. Model data dibangun dengan menggunakan informasi dalam spesifikasi kebutuhan pemakai. Model data konseptual merupakan sumber informasi untuk fase desain logical.
¾
Logical database design Suatu proses pembentukan model dari informasi yang digunakan dalam perusahaan berdasarkan model data tertentu (misal : relasional), tetapi independen terhadap DBMS tertentu dan aspek fisik lainnya. Model data konseptual yang telah dibuat sebelumnya, diperbaiki dan dipetakan kedalam model data logical.
25 ¾
Physical database design Suatu proses yang menghasilkan deskripsi implementasi basis data pada penyimpanan sekunder. Menggambarkan struktur penyimpanan dan metode akses yang digunakan untuk mencapai akses yang efisien terhadap data. Dapat dikatakan juga, desain fisikal merupakan cara pembuatan menuju sistem DBMS tertentu
2.5.5
DBMS Selection Pemilihan DBMS yang tepat untuk mendukung aplikasi basis data. Dapat dilakukan kapanpun sebelum menuju desain logical asalkan terdapat cukup informasi mengenai kebutuhan sistem. Tahap-tahap utama untuk memilih DBMS:
2.5.6
¾
Mendefinisikan terminologi studi referensi.
¾
Mendaftar dua atau tiga produk.
¾
Evaluasi produk.
¾
Rekomendasi pilihan dan laporan produk.
Application Design Desain aplikasi adalah desain interface user dan program aplikasi yang menggunakan dan memproses basis data. Desain basis data dan aplikasi merupakan aktifitas paralel yang meliputi dua aktifitas penting, yaitu ¾
:
Transaction design Transaksi adalah satu aksi atau serangkaian aksi yang dilakukan oleh user tunggal atau program aplikasi, yang mengakses atau mengubah
26 isi dari basis data. Kegunaan dari desain transaksi adalah untuk menetapkan dan keterangan karakteristik high-level dari suatu transaksi yang dibutuhkan pada basis data. Terdapat tiga tipe transaksi, yaitu : o
retrieval transaction, digunakan untuk pemanggilan (retrieve) data untuk ditampilkan di layar atau menghasilkan suatu laporan.
o
update transaction, digunakan untuk menambahkan record baru, menghapus record lama, atau memodifikasi record yang sudah ada didalam database.
o
¾
mixed transaction, meliputi pemanggilan dan perubahan data.
User interface design. Beberapa aturan pokok dalam pembuatan user interface: o
Meaningful title, diusahakan pemberian nama suatu form cukup jelas menerangkan kegunaan dari suatu form/report.
o
Comprehensible
instrctions,
penggunaan
terminologi
yang
familiar untuk menyampaikan instruksi ke user dan jika informasi tambahan dibutuhkan, maka harus disediakan helpscreen o
Logical grouping and sequencing of fields, field yang saling berhubungan ditempatkan pada form/report yang sama. Urutan field harus logis dan konsisten.
o
Visually appealing layout of the form/report, tampilan form/report harus menarik, dan sesuai dengan hardcopy agar konsisten.
o
Familiar field labels, penggunaan label yang familiar.
27 o
Consistent terminology and abbreviation, terminology dan singkatan yang digunakan harus konsisten.
o
Consistent use of color.
o
Visible space and boundaries for data-entry fields, jumlah tempat yang disediakan untuk data entry harus diketahui oleh user.
o
Convinient cursor movement, user dapat dengan mudah menjalankan operasi yang diinginkan dengan menggerakkan cursor pada form/report.
o
Error correction for individual characters and entire fields, user dapat dengan mudah menjalankan operasi yang diinginkan dan melakukan perubahan terhadap nilai field.
o
Error messages for unacceptable values.
o
Optional fields marked clearly.
o
Explanatory messages for fields, ketika user meletakkan cursor pada suatu field, maka keterangan mengenai field tersebut harus dapat dilihat.
o
Completion signal, indikator yang menjelaskan bahwa suatu proses telah selesai dilaksanakan.
2.5.7
Prototyping Prototyping adalah membuat model kerja suatu aplikasi basis data. Tujuan utama dari pembuatan prototyping adalah: ¾
Untuk mengidentifikasi feature dari sistem yang berjalan dengan baik atau tidak.
28 ¾
Untuk memberikan perbaikan-perbaikan atau penambahan feature baru .
¾
Untuk klarifikasi kebutuhan pemakai.
¾
Untuk evaluasi feasibilitas (kemungkinan yang akan terjadi) dari desain sistem khusus.
Terdapat dua macam strategi prototyping yang digunakan saat ini, yaitu: ¾
Requirements prototyping, menggunakan prototype untuk menentukan kebutuhan dari aplikasi basis data yang diinginkan dan ketika kebutuhan itu terpenuhi maka prototype akan dibuang.
¾
Evolutionary
prototyping,
digunakan
untuk
tujuan
yang
sama.
Perbedaannya, prototype tidak dibuang tetapi dengan pengembangan lanjutan menjadi aplikasi basis data yang digunakan.
2.5.8
Implementation Implementasi merupakan realisasi fisik dari basis data dan desain aplikasi. Implementasi basis data dicapai dengan menggunakan : ¾
DDL untuk membuat skema basis data dan file basis data kosong.
¾
DDL untuk membuat user view yang diinginkan.
¾
3GL dan 4GL untuk membuat program aplikasi. Termasuk transaksi basis data disertakan dengan menggunakan DML, atau ditambahkan pada bahasa pemrograman.
29 2.5.9
Data Conversion and Loading Pemindahan data yang ada kedalam basis data baru dan mengkonversikan aplikasi yang ada agar dapat digunakan pada basis data yang baru. Tahapan ini dibutuhkan ketika sistem basis data baru menggantikan sistem yang lama. DBMS biasanya memiliki utilitas yang memanggil ulang file yang sudah ada kedalam basis data baru. Dapat juga mengkoversi dan menggunakan program aplikasi dari sistem yang lama untuk digunakan oleh sistem yang baru.
2.5.10 Testing Testing adalah suatu proses eksekusi program aplikasi dengan tujuan untuk menemukan kesalahan. Dengan menggunakan strategi tes yang direncanakan dan data yang sesungguhnya. Pengujian hanya akan terlihat jika terjadi kesalahan software. Mendemostrasikan basis data dan program aplikasi terlihat berjalan seperti yang diharapkan.
2.5.11 Operational Maintenance Suatu proses pengawasan dan pemeliharaan sistem setelah instalasi, meliputi: ¾
Pengawasan performa sistem, jika performa menurun maka memerlukan perbaikan atau pengaturan ulang basis data.
¾
Pemeliharaan dan pembaharuan aplikasi basis data (jika dibutuhkan).
¾
Penggabungan kebutuhan baru kedalam aplikasi basis data.
30 2.6
Normalisasi
2.6.1
Pengertian Normalisasi Menurut Connoly (2002, p376), Normalisasi adalah suatu teknik untuk menghasilkan sekumpulan relasi dengan sifat-sifat (properties) yang diinginkan, memenuhi kebutuhan data pada perusahaan.
2.6.2
Data Redundancy Tujuan utama dilakukan normalisasi adalah untuk meminimalisasi redundansi data dan mengurangi penggunaan tempat penyimpanan yang dibutuhkan untuh sebuah relasi dasar. Redundansi data diakibatkan oleh Update Anomalies, yang terdiri dari tiga tipe yaitu : ¾
Insertion Anomalies adalah keadaan dimana kita tidak dapat menyimpan fakta atau transaksi yang terjadi di dalam perusahaan.
¾
Deletion Anomalies adalah kondisi bahwa fakta hilang dari basis data disebabkan penghapusan file yang lain.
¾
Modification Anomalies adalah kondisi bahwa fakta hilang dari basis data disebabkan perubahan pada file yang lain.
Untuk mengatasi anomalies ini dapat dilakukan decomposotion pada relasi dasar. Terdapat dua sifat Decomposition yaitu ¾
:
Lossless-join Memungkinkan kita menemukan suatu instance relasi dasar dari instance koresponden dalam relasi yang lebih kecil.
31 ¾
Dependency Preservation Properties Memungkinkan kita untuk mengadakan batasan pada relasi dasar dengan menyediakan beberapa batasan pada relasi yang lebih kecil.
2.6.3
Functional Dependency Merupakan konsep inti yang terkait dengan normalisasi. Functional Dependency, menjelaskan relationship antar atribut-atribut dalam relasi. Functional Dependency merupakan sifat dari arti semantik suatu atribut dalam sebuah relasi.
B is functionally
A
B dependent on A
Gambar 2.10 Diagram Function Dependency
Determinant dari functional dependency mengacu kepada atribut atau himpunan atribut disebelah kiri anak panah. Karakteristik utama dari functional dependency yang digunakan dalam normalisasi : ¾
Mempunyai relationship a 1:1 antar atribut di sebelah kiri dan kanan dependency.
¾
Saling terkait (Hold for all time) Misal : staffNo Æ sName dan sName Æ staffNo
¾
Nontrivial.
32 2.6.4
Proses Normalisasi Proses Normalisasi adalah : ¾
Suatu teknik formal untuk menganalisis relasi berdasarkan primary key dan functional dependencies antar atribut.
¾
Dieksekusi dalam beberapa langkah. Setiap langkah mengacu ke bentuk normal tertentu, sesuai dengan sifat yang dimilikinya.
¾
Setelah normalisasi diproses, relasi menjadi secara bertahap lebih terbatas/kuat bentuk formatnya dan juga mengurangi tindakan update yang anomali.
Gambar 2.11 Tahapan Normalisasi
2.6.4.1 UNF (Unnormalized Form) Merupakan suatu tabel yang berisikan satu atau lebih groups yang berulang.
Untuk
membuat
tabel
unnormalized
yaitu
dengan
memindahkan data dari sumber informasi kedalam format tabel dengan baris dan kolom. Jika ada atribut yang bernilai multivalue, maka relasi tersebut dalam kondisi unnormalized.
33 2.6.4.2 1NF (First Normal Form) 1NF merupakan sebuah relasi dimana setiap irisan antara baris dan kolom berisikan satu dan hanya satu nilai (tidak ada atribut yang bernilai multivalue). Cara merubah UNF ke 1NF adalah : ¾
Tunjuk satu atau sekumpulan atribut sebagai kunci untuk tabel unnormalized.
¾
Identifikasikan groups yang berulang dalam tabel unnormalized yang berulang untuk kunci atribut.
¾
Hapus group yang berulang dengan cara o
:
Masukkan data yang semestinya kedalam kolom yang kosong pada baris yang berisikan data yang berulang (flattening the table), atau dengan cara
o
Menggantikan data yang ada dengan copy dari kunci atribut yang sesungguhnya kedalam relasi terpisah.
2.6.4.3 2NF (Second Normal Form) Berdasarkan pada konsep full functional dependency, yaitu A dan B merupakan atribut dari sebuah relasi, B dikatakan fully dependent terhadap A jika B functionally dependent pada A tetapi tidak pada proper subset dari A. 2NF adalah sebuah relasi dalam 1NF dan setiap atribut nonprimary-key bersifat fully functionally dependent pada primary key.
34 Cara merubah 1NF ke 2NF adalah : ¾
Identifikasikan primary key untuk relasi 1NF.
¾
Identifikasikan functional dependencies dalam relasi.
¾
Jika terdapat partial dependencies terhadap primary key, maka hapus dengan menempatkannya dalam relasi yang baru bersama dengan salinan determinan-nya.
2.6.4.4 3NF (Third Normal Form) Berdasarkan pada konsep transitive dependency, yaitu suatu kondisi dimana A, B dan C merupakan atribut dari sebuah relasi, maka jika A Æ B dan B Æ C, maka C transitively dependent pada A melalui B. (Jika A tidak functionally dependent pada B atau C). 3NF adalah sebuah relasi dalam 1NF dan 2NF dan dimana tidak terdapat atribut non-primary-key atribut yang bersifat transitively dependent pada primary key. Transitive dependency adalah jika suatu atribut dependent pada satu atau lebih non-primary-key. Cara merubah 2NF ke 3NF adalah : ¾
Identifikasikan primary key dalam relasi 2NF.
¾
Identifikasikan functional dependencies dalam relasi.
¾
Jika terdapat transitive dependencies terhadap primary key, hapus dengan menempatkannya dalam relasi yang baru bersama dengan salinan determinan-nya.
35 2.6.4.5 BCNF (Boyce-Codd Normal Form) Berdasarkan pada functional dependencies yang dimasukan kedalam
hitungan
bagaimanapun
seluruh
BCNF
juga
candidate memiliki
key
dalam
suatu
batasan-batasan
relasi,
tambahan
disamakan dengan definisi umum dari 3NF. Suatu relasi dikatakan BCNF, jika dan hanya jika setiap determinan merupakan candidate key. Perbedaan antara 3NF dan BCNF yaitu untuk functional dependency A → B, 3NF memungkinkan dependency ini dalam suatu relasi jika
B adalah
atribut primary-key dan A bukan merupakan
candidate key. Sedangkan BCNF menetapkan dengan jelas bahwa untuk dependency ini agar ditetapkan dalam relasi maka A harus merupakan candidate key. Setiap relasi dalam BCNF juga merupakan 3NF, tetapi relasi dalam 3NF belum tentu termasuk kedalam BCNF. Dalam BCNF kesalahan jarang sekali terjadi. Kesalahan dapat terjadi pada relasi yang : ¾
Terdiri dari 2 atau lebih composite candidate key.
¾
Candate key overlap, sedikitnya satu atribut.
2.6.4.6 4NF (Fourth Normal Form) Meskipun sebuah tabel telah mencapai normal BCNF, namun masih mungkin terjadi kesulitan berkenaan dengan adanya informasi berulang yang disebut sebagai multivalue.
36 Multi-valued Dependency adalah representasi ketergantungan antara attribut (contoh : A, B dan C) dalam relasi, misalnya untuk setiap nilai A ada sekumpulan nilai untuk B dan sekumpulan nilai untuk C. Tetapi, kumpulan nilai B dan C independen satu sama lain. 4NF adalah relasi yang termasuk BCNF dan tidak mengandung nontrivial ketergantungan nilai jamak.
2.6.4.7 5NF (Fifth Normal Form) 5NF disebut juga Project Join Normal Form (PJNF) karena berkaitan dengan konsistensi antara tabel asal dengan tabel hasil pengabungan, tabel proyeksi atau tabel dekomposisi. Suatu relasi R berada dalam 5NF jika dan hanya setiap ketergantungan gabungan (Join Dependency) pada relasi R diperoleh dari kunci-kunci kandidat relasi R. Ketergantungan gabungan (Join Dependency) merupakan bentuk umum dari ketergantungan nilai jamak. Ketergantungan nilai jamak (Multi_Valued
Dependency)
merupakan
bentuk
umum
dari
ketergantungan fungsional (Functional Dependency).
2.7
Perancangan Software Model Waterfall Model Waterfall menyarankan pendekatan sistematic, sequential untuk pengembangan software yang dimulai pada level sistem & perkembangan melalui analysis, design, coding & support.
37 Model Waterfall memiliki aktivitas System Engineering and Modeling, Software Requirement Analysis, Design, Code Generation, Testing dan Support. System Engineering dan Modeling Software Requirement and Analysis Design
Code Generation
Testing
Support
Gambar 2.12 Model Waterfall
2.7.1
System Engineering and Modeling Karena software selalu menjadi bagian dari sistem yang besar, pekerjaan dimulai dengan membangun persyaratan untuk semua elemen sistem dan kemudian mengalokasikan beberapa subset dari requirement ini ke dalam software. Pandangan sistem ini sangat penting ketika software harus berinteraksi dengan elemen lain seperti hardware, orang dan database. Langkah ini meliputi pengumpulan requirement pada level sistem dengan sejumlah kecil design dan analysis level atas.
2.7.2
Software Requirement Analysis Proses pengumpulan requirement diintensifkan dan difokuskan spesifik pada software. Untuk mengerti cara kerja program yang akan dibuat, analis harus
38 mengerti domain informasi untuk software. Requirement untuk kedua sistem dan software didokumentasikan dan direview dengan customer.
2.7.3
Design Desain software sebenarnya merupakan proses multistep yang fokus pada 4 atribut berbeda pada program : data struktur, arsitektur software, representasi interface dan detail procedural. Proses desain mentranslasikan pengumpulan requirement menjadi representasi software yang dapat menilai kualitas sebelum coding dimulai.
2.7.4
Code Generation Desain harus ditranslasikan ke dalam form machine-readable. Langkah Code Generation melakukan tugas ini dan dapat dikerjakan secara mekanis.
2.7.5
Testing Ketika code telah dibuat, testing program dimulai. Proses testing fokus pada internal logikal software, memastikan bahwa semua statement telah diuji coba, dan pada external fungsional, melakukan tes untuk mengatasi kesalahan dan memastikan bahwa input terdefinisi akan menghasilkan hasil sebenarnya yang sesuai dengan hasil yang dibutuhkan.
2.7.6
Support
39 Software pasti akan mengalami perubahan setelah diberikan kepada customer. Dukungan software/ pemeliharaan menerapkan kembali setiap fase sebelumnya ke dalam program yang sudah ada daripada ke program yang baru.
2.8 Penjualan 2.8.1
Pengertian Penjualan Menurut Kamus Istilah Akuntansi (1999, p404), Penjualan adalah (1) Penerimaan yang diperoleh dari pengiriman barang dagangan atau dari penyerahan pelayanan dalam bursa sebagai bahan pertimbangan. Pertimbangan ini dapat dalam bentuk tunai, peralatan kas, atau harta lainnya. Pendapatan dapat diperoleh pada saat penjualan, karena terjadi pertukaran, harga jual dapat ditetapkan, dan bebannya diketahui. (2) Dalam penjualan eceran, ada penurunan harga sementara untuk menggerakkan persediaan dan meningkatkan kas.
2.8.2
Tipe-tipe Penjualan Menurut Mulyadi (2001, p202), penjualan dapat dibagi menjadi dua tipe berdasarkan cara pembayarannya, yaitu : ¾
Penjualan Tunai Penjualan tunai adalah transaksi penjualan dimana barang atau jasa baru diserahkan oleh perusahaan kepada pembeli jika perusahaan telah menerima uang atau pembayaran dari pembeli.
¾
Penjualan Kredit Penjualan kredit adalah transaksi penjualan dimana jika pesanan dari pembeli atau pelanggan telah dipenuhi dengan mengirim barang atau
40 penyerahan jasa, maka untuk jangka waktu tertentu perusahaan memiliki piutang kepada pelanggannya.
2.9
Pembelian
2.9.1
Pengertian Pembelian Pembelian adalah transaksi yang dilakukan perusahaan dalam rangka pengadaan barang yang diperlukan oleh perusahaan baik yang digunakan sendiri maupun yang akan dijual kembali.
2.9.2
Tipe-tipe Pembelian Menurut Mulyadi (2001, p299), pembelian dapat dibagi menjadi dua tipe berdasarkan pemasoknya, yaitu : ¾
Pembelian Lokal Pembelian lokal adalah pembelian dari pemasok dalam negeri.
¾
Pembelian Impor Pembelian impor adalah pembelian dari pemasok luar negeri.
2.10
Persediaan Persediaan adalah barang yang dimiliki dengan tujuan untuk dijual kembali atau diproses dan kemudian dijual. Menurut Prinsip Akuntansi Indonesia, persediaan digunakan untuk menyatakan barang berwujud yang : ¾
Tersedia untuk dijual (barang dagang/barang jadi)
¾
Masih dalam proses produksi untuk diselesaikan, kemudian dijual (barang dalam proses/pengolahan)
41 ¾
Akan digunakan untuk produksi barang jadi yang akan dijual (bahan baku dan bahan pembantu) dalam rangka kegiatan normal perusahaan Menurut Kamus Istilah Akuntansi (1999, p251), Persediaan adalah
barang dagangan atau persediaan yang ada ditangan atau dalam perjalanan pada suatu waktu tertentu. Yang termasuk dalam persediaan adalah : (1) barang dalam transit yang fakturnya telah diterima dan (2) barang selain barang titipan. Menurut Mulyadi (2001, p553), persediaan bisa berbeda tergantung jenis usahanya. Dalam perusahaan manufaktur, persediaan terdiri dari : ¾
Persediaan produk jadi
¾
Persediaan produk dalam proses
¾
Persediaan bahan baku
¾
Persediaan bahan penolong
¾
Persediaan bahan habis pakai pabrik
¾
Persediaan suku cadang Sedangkan dalam perusahaan dagang, persediaan hanya terdiri dari satu
golongan, yaitu persediaan barang dagangan, yang merupakan barang yang dibeli untuk tujuan dijual kembali.
