5
LANDASAN TEORI
2.1 Teori Dasar
2.1.1 Data
Menurut (Indrajani, 2011, p2), data adalah fakta atau observasi mentah yang biasanya mengenai fenomena fisik atau transaksi bisnis. Lebih khusus lagi, data adalah ukuran objektif atribut (karakteristik) dari entitas seperti orang – orang, angka, simbol, teks, dan kombinasinya.
Menurut (James A. O’Brien, 2006, p13), data adalah fakta – fakta atau observasi yang mentah mengenai kejadian atau transaksi bisnis pada sebuah perusahaan.
Menurut (Anna Maria, 1998, p1) data adalah bahan yang digunakan dalam perhitungan atau operasi untuk menghasilkan informasi yang berguna. Struktur adalah pengaturan atau hubungan, maka dapat didefinisikan sebagai pengaturan atau hubungan dari data didalam suatu sistem.
Istilah asing teknik pengumpulan data adalah fact finding technique adalah proses formal menggunakan cara seperti wawancara dan daftar pertanyaan untuk mengumpulka fakta tentang sistem, kebutuan, dan pilihan (Indrajani, 2011, p2 – 6).
Menurut (Turban, 2003, p2), data adalah kumpulan fakta yang belum diolah serta transaksi yang direkam dan disimpan, tetapi tidak disusun untuk menyampaikan suatu arti khusus lainnya.
Teknik pencariaan fakta yang digunakan:
Menguji dokumentasi
Uji dokumentasi bermanfaat jika kita sedang berusaha mendalami kebutuhan basis data yang akan datang.
Tabel 2.1 Contoh Menguji Dokumentasi Tujuan Dokumentasi Contoh Dokumentasi
Deskripsi masalah dan kebutuhan basis data.
Memo internal, email, dan keluhan karyawan atau pelanggan saat rapat, serta dokumen yang menjelaskan berbagai masalah.
Pemeriksaan kembali kinerja dan berbagai laporan.
Deskripsi kebutuhan perusahaan yang dapat menimbulkan masalah.
Struktur organisasi, statement misi, dan rencana strategi perusahaan.
Tugas dan deskripsi perusahaan.
Contoh – contoh formulir dan laporan yang masih manual, serta yang telah terkomputerisasi.
Deskripsi sistem sekarang. Diagram aliran data dan bentuk – bentuk diagram lainnya.
Kamus data.
Perancangan sistem basis data.
Dokumentasi program.
Manual user atau pelatihan.
Wawancara
Teknik ini paling sering digunakan dan sangat berguna dibandingkan teknik – teknik pencarian data lainnya. Terdapat 2 jenis wawancara, yaitu:
1. Wawancara tidak terstruktur
Wawancara tidak terstruktur dilakukan jika wawancara bersifat umum dan memiliki sedikit pertanyaan yang bersifat spesifik. Pewancara
mengharapkan orang yang sedang diwawancarai itu menyediakan suati kerangka dan arah kepada pewawancara. Wawancara jenis ini banyak menimbulkan kehilangan fokus dan karena alasan itulah hasil wawancara ini tidak baik bagi analisa dan perancangan basis data.
2. Wawancara terstruktur
Pewawancara mempunyai banyak pertanyaan yang spesifik. Keberhasilannya bergantung kepada tanggapan orang yang sedang diwawancarai dan apakah pewawancara dapat mengarahkan pertanyaan tambahan secara langsung untuk memperoleh klarifikasi atau perluasan.
Terdapat 2 jenis pertanyaan yang dapat diajukan, yaitu pertanyaan terbuka dan pertanyaan tertutup. Perbedaannya adalah pertanyaan terbuka memperbolehkan orang yang sedang diwawancarai untuk memberikan respon pada bagian pertanyaan yang sesuai dengan apa yang terdapat pada pikiran orang yang sedang diwawancarai. Sedangkan pertanyaan tertutup membatasi jawaban pada pilihan tertentu, singkat, dan tanggapan secara langsung.
Tabel 2.2 Keuntungan dan Kerugian Wawancara
Keuntungan Kerugian
Memperbolehkan orang yang sedang diwawancarai untuk menjawab dengan bebas dan secara terbuka ke pertanyaan.
Mahal dan sangat memakan waktu Tidak praktis.
Memperbolehkan orang yang sedang diwawancarai merasakan bagian dari proyek.
Kesuksesan sangat bergantung pada keterampilan komunikasi pewawancara.
Memperbolehkan pewawancara untuk mengikuti komentar menarik yang dibuat oleh orang yang sedang diwawancarai.
Kesuksesan dapat bergantung pada kesediaan orang yang sedang diwawancarai untuk mengambil bagian dari wawancara.
Memperbolehkan pewawancara menyesuaikan atau mengulang kata
yang dipertanyakan ke pewawancara.
Memperbolehkan pewawancara untuk mengamati bahasa tubuh orang yang sedang diwawancarai.
Observasi
Pengamatan adalah salah satu teknik pencarian data yang paling efektif untuk pemahaman suatu sistem.
Tabel 2.3 Keuntungan dan Kerugian Observasi
Keuntungan Kerugian
Memperbolehkan kebenaran fakta dan data untuk diperiksa.
Orang – orang dapat mengetahui atau tidak mengetahui ketika mereka sedang diamati, maka mereka dapat melakukan suatu hal yang berbeda.
Pengamat dapat melihat secara nyata, apa yang dilaksanakan.
Dapat ketinggalan pengamatan ketika terdapat perbedaaan tingkat kesulitan dan jumlah pekerjaan dalam suatu periode.
Pengamat dapat memperoleh gambaran data suatu lingkungan fisik dari suatu tugas.
Beberapa tugas tidak dapat selalu dilakukan cara yang sama dimana mereka diamati.
Relatif murah. Dapat menjadi tidak praktis
Pengamat dapat melakukan pengukuran kerja.
Studi Kepustakaan
Metode ini dilakukan dengan mengumpulkan, membaca, dan mempelajari beberapa data – data diberbagai media. Cth: hasil karya
tulis atau artikel – artikel dari internet yang berhubungan dengan masalah yang dibahas.
2.1.2 Sistem
Menurut (Connolly dan Begg, 2005, p285 – 287), sistem adalah menentukan jangkauan batasan – batasan dari sistem basis data yang terdiri dari pandangan umum dari user serta area pada aplikasi. Pendefinisian sistem menggambarkan ruang lingkup dan batasan aplikasi basis data dan pandangan pengguna, hal ini sangat penting dilakukan dalam proses perancangan basis data agar lebih fokus pada proyek basis data yang sedang dikerjakan. Pandangan (user view) sangat diperlukan untuk mengidentifikasi informasi – informasi yang dibutuhkan oleh user, beserta pandangan apa saja yang dibutuhkan oleh aplikasi basis data seperti manajer atau pengawas maupun dari sudut pandang aplikasi perusahaan dengan data yang disimpan.
Menurut (James A.O'Brien, 2003, p8), sistem adalah kumpulan elemen yang saling terhubung atau berinteraksi membentuk suatu kesatuan atau sekumpulan komponen yang saling terhubung dan bekerja sama untuk mencapai sasaran dengan menerima input dan menghasilkan output dalam sebuah proses transformasi yang terorganisir.
2.1.3 Basis Data
Menurut (Connolly dan Begg, 2010, p66), database adalah kumpulan dari data – data yang saling terhubung secara logika, dan merupakan deskripsi dari data, yang dirancang untuk memenuhi kebutuhan informasi dari suatu organisasi.
Menurut (Connolly dan Begg, 2005, p15) sistem basis data yang menyimpan record yang terkomputerisasi yang dimana tujuan sebenarnya adalah menyimpan informasi dan membuat informasi yang tersedia setiap
saat. Sistem tersebut dapat digunakan kembali untuk diubah informasinya sesuai kebutuhan.
Menurut (Indrajani, 2011, p2), database adalah kumpulan data yang berhubungan secara logis dan deskripsi, yang dirancang untuk memenuhi informasi yang dibutuhkan oleh suatu organisasi. Artinya basis data merupakan tempat penyimpanan data yang besar, dimana dapat digunakan oleh banyak pengguna dan seluruh basis data tidak lagi dimiliki oleh satu departemen melainkan menjadi sumber daya perusahaan yang dapat digunakan bersama.
Menurut (James A. O'Brien, 2003, p145), basis data adalah sebuah kumpulan yang terintegrasi dari elemen data yang terhubung secara logikal. Elemen data mendeskripsikan entitas-entitas dan hubungan antara entitas.
2.1.4 Database Management System (DBMS)
2.1.4.1 Teori Database Management System
Menurut (Connolly dan Begg, 2010, p66), Database Management System (DBMS) adalah sebuah perangkat lunak yang memungkinkan user untuk dapat mendefinisikan, memelihara, membuat, dan mengontrol akses ke dalam basis data.
Gambar 2.1 Database Management System
Sumber : (Connolly dan Begg, 2010, p67)
Pada gambar 2.1 menjelaskan tentang bagian sales dan contracts menyatakan bahwa ada dua pengguna sistem yang memasukkan data yaitu bagian sales dan bagian contracts. Dua pengguna sistem dengan komputer client yang berbeda mengakses
satu basis data yang sama tentu dengan pemasukan data yang berbeda, seperti pada gambar yang tertera bahwa bagian penjualan memasukan data dan laporan dengan mengakses aplikasi “sales application program” dan bagian contracts memasukan data dan laporan dengan mengakses aplikasi yang berbeda dari bagian sales, yaitu “contracts application program”, hal seperti ini membutuhkan suatu manajemen atau pengendalian ke dalam DBMS dan fungsi DBMS itu sendiri adalah memberikan hak akses kepada dua pengguna bagian sales dan bagian contracts, serta data – data apa saja yang mereka masukan, memodofikasi, menghapus hak akses mereka, sehingga kontrol terhadap data – data dapat teratasi.
2.1.4.2 Komponen pada lingkungan DBMS
Menurut (Connolly dan Begg, 2010, p68), komponen pada Database Management System (DBMS) terdiri dari 5 macam, yaitu:
Gambar 2.2 DBMS environment
Hardware
Didalam database sendiri dapat menjangkau jarak yang sangat luas dari bagian komputer, ke bagian computer tunggal, yang dimana dapat saling berhubungan satu dengan yang lainnya.
Software
Didalam database itu sendiri juga terdapat komponen yang sudah ada apliaksi yang saling berhubungan dengan jaringan internet Data
Didalam lingkungan database yang menjadi sudut pandang paling penting adalah data itu sendiri yang merupakan ‘point of view’ bertindak sebagai jembatan antara komponen mesin dengan komponen manusia dan juga memiliki konten basis data yang baik
mengenai operasional dan metadata pada struktur database disebut skema.
Procedures
Prosedur mengacu pada instruksi dan aturan yang mengatur desain dan penggunaan database. Pengguna sistem dan staf yang mengelola database memerlukan prosedur yang terdokumentasi mengenai tentang cara bagaimana menggunakan atau menjalankan sistem. Terdiri dari:
melakukan login pada database
menentukan aplikasi mana yang perlu dipakai pada DBMS menjalan dan memberhentikan DBMS
bagaimana caranya memperbaiki sistem yang rusak, bagaimana caranya memperbaiki database yang gagal, serta meningkatkan perfoma pada database
People
Bagaimana manusia dapat berinteraksi dengan sistem serta mengidentifikasi struktur pada database desain.
2.1.4.3 Komponen pada Database Manager
Database Manager mempunyai komponen yang terdiri dari:(Connolly dan Begg, 2005, p53 – 55)
Database Manager, DM berhadapan dengan program aplikasi dan query yang diajukan oleh user. DM juga menerima query dan memeriksa skema eksternal dan konseptual untuk menentukan laporan konseptual apa yang dapat memenuhi permintaaan user. Query Processor adalah komponen utama dalam DBMS yang
merubah query ke dalam bahasa instruksi tingkat rendah yang ditujukan untuk database manager.
File Manager digunakan untuk memanipulasi file-file dasar yang tersimpan dan mengatur kapasitas pada tempat penyimpanan. DDL Compiler digunakan untuk mengkonversikan pernyataan
DML Processor pada modul ini mengkonversikan pertanyaan DML dan prgram aplikasi ke dalam bentuk standar dari bahasa host.
2.1.4.4 Keuntungan DBMS
Menurut (Connolly dan Begg, 2010, p77 – 81), terdapat keuntungan menggunakan DBMS adalah sebagai berikut:
Data dapat digunakan bersama – sama oleh semua pengguna DBMS.
Dengan adanya kontrol redudansi data maka akan mengurangi resiko terjadinya ketidak konsisten data.
Mendapat banyak informasi yang diperoleh dari sejumlah data yang sama. Contoh: Pada File Base System (FBS) adalah hal yang cukup sulit untuk mendapatkan informasi supplier yang barangnya terlaris dijual. Sedangkan pada DBMS, mendapatkan informasi tersebut sangatlah mudah, mengingat seluruh sistem data dalam DBMS telah terintegrasi.
Meningkatkan keamanan database
Meningkatkan service backup dan recovery Meningkatkan skala ekonomi
Meningkatkan produktifitas Meningkatkan konkurensi Berbagi data Konsistensi data 2.1.4.5 Kerugian DBMS Harga DBMS mahal
Ada pendapatan, ada uang ada barang. Teknologi baru tentunya lebih mahal dari pada teknologi yang terdahulu.
Ukuran
Kerumitan dari banyaknya fungsi yang ada pada DBMS menyebabkan DBMS memerlukan banyak sotfware pendukung yang mengakibatkan penambahan tempat penyimpanan dan memori.
Pada DBMS terdapat pengaturan fungsi – fungsi sehingga DBMS menjadi software yang cukup rumit dan komplekas. Aturan fungsi – fungsi tersebut harus diketahui oleh pengguna DBMS dengan baik. Jika tidak maka pengguna DBMS tidak akan mendapatkan manfaat dari implementasi DBMS.
Penambahan biaya perangkat keras. Adanya biaya konversi
Biaya konversi ini akan digunakan untuk proses konversi File Base System (FBS) ke DBMS.
Dampak yang lebih tinggi jika terjadinya kegagalan pada kerusakan DBMS yang menyebabkan kerugian bagi yang mengakses DBMS
2.1.5 Database System Development Lifecycle
Tahapan – tahapan dalam penerapan database application lifecycle menurut (Connolly dan Begg, 2010, p314), yaitu:
2.1.5.1 Proses – proses Database System Development Life Cycle
Tabel 2.4 Tahapan dan Fungsi Utama pada Tahapan Siklus Basis Data
Database Planning Merencanakan bagaimana tahapan – tahapan dalam siklus basis data dilakukan secara efektif dan efisien.
System Definition Melakukan spesifikasi ruang lingkup dan batasan – batasan dari sistem basis data.
Requirements Collection & Analysis
Mengumpulkan dan menganalisis kebutuhan dari sistem basis data yang baru.
Database Design Conceptual, Logical, dan Physical design pada sistem basis data.
Application Design Merancang aplikasi sesuai dengan kebutuhan user dan program aplikasi yang dibutuhkan dalam sistem basis data.
DBMS Selection Memilih DBMS yang cocok untuk digunakan pada sistem basis data.
Prototyping Membuat model dari sistem basis data yang dimana mengijinkan perancang atau pengguna untuk mengevaluasi bagaimana gambaran dan fungsi dari sistem yang telah dibuat.
Implementation Melakukan penerapan pada sistem yang telah dibuat untuk digunakan dalam DBMS.
Data Conversion and Loading
Mengecek kembali format data yang digunakan pada DBMS.
Testing Melakukan testing pada sistem basis data yang telah dibuat apakah layak digunakan atau tidak apakah sesuai dengan kebutuhan pengguna.
Operational Maintenance
Sistem yang telah diimplementasikan secara penuh akan dipantau terus menerus dan dipelihara secara berkelanjutan untuk mengetahui kebutuhan pengguna kedepannya.
2.1.5.2 Database Planning
Didalam perancangan basis data terdapat sebuah aktivitas manajemen yang memungkinkan tahapan – tahapan dari aplikasi yang terealisasi efektif serta efisie mungkin(Connolly dan Begg, 2010, p313). Dimana terdapat 3 hal penting dalam perumusan strategi sistem informasi, adalah:
Identifikasi rencana serta sasaran perusahaan dengan menentukan kebutuhan sistem informasi selanjutnya.
Melakukan evaluasi mengenai kelemahan dan kelebihan pada sistem informasi yang sedang berjalan.
Mencari peluang teknologi informasi yang mungkin memberikan keuntungan kompetitif.
Langkah – langkah yang dibutuhkan dalam perancangan basis data:
Mengidentifikasi mission statement dari proyek basis data yang menjadi tujuan utama dalam aplikasi basis data
Mengidentifikasi mission objective tertentu yang didukung oleh basis data
2.1.5.3 System Definition
Menurut (Connolly dan Begg, 2010, p316), Pendefinisian sistem menjelaskan batasan – batasan dan mencangkup dari aplikasi basis data dan sudut pandang (user view) yang utama. User View mendefinisikan apa yang diwajibkan dari suatu aplikasi basis data melalui beberapa perpektif. Suatu aplikasi basis data dapat memiliki lebih dari satu user view.
Identifikasi user view membantu memastikan bahwa tidak ada pengguna utama dari suatu basis data yang terlupakan ketika pembuatan aplikasi baru dibutukan. User View juga membantu dalam pengembangan aplikasi basis data yang kompleks memungkinkan permintaan dipecah kedalam bagian – bagian yang lebih mudah diatur.
2.1.5.4 Requirements Collection & Analysis
Menurut (Connolly dan Begg, 2010, p316 – 318), Analisa dan pengumpulan kebutuhan merupakan suatu proses pengumpulan data dan analisa informasi mengenai bagian organisasi yang didukung oleh aplikasi basis data, dan menggunakan informasi tersebut untuk identifikasi kebutuhan pengguna pada sistem baru. Informasi yang dikumpulkan untuk setiap user view meliputi lima teknik fact – finding:
Interview
Mengevaluasi dokumentasi Observasi
Questioner Research
2.1.5.5 Database Design
Menurut (Connolly dan Begg, 2010, p320 – 321), Perancangan basis data merupakan suatu proses pembuatan sebuah desain basis data yang akan mendukung tujuan dan operasi dari perusahaan.
Tujuan utama perancangan basis data adalah sebagai berikut:
Menyediakan model data yang mendukung segala transaksi yang diperlukan.
Merepresentasikan data dan relationship antar data yang dibutuhkan oleh seluruh area aplikasi utama dan grup pengguna. Menspesifikasikan desain dengan struktur yang sesuai dengan
kebutuhan system
Terdapat tipe – tipe pendekatan yang digunakan dalam perancangan basis data:
o Top-Down
Pendekatan Top-Down diawali dengan pembentukan model data yang berisi beberapa entitas tingkat tinggi (high level) dan relationship, yang kemudian menggunakan pendekatan Top-Down secara berturut-turut untuk mengidentifikasi entitas lower level, relationship, dan atribut lainnya.
o Bottom-Up
Pendekatan Bottom-Up dimulai dari atribut dasar dengan analisis dari penggabungan antar atribut, yang dikelompokan ke dalam suatu relasi yang merepresentasikan tipe dari entitas dan relationship antar entitas.
o Inside-Out
Pendekatan Inside-Out mirip seperti 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.
o Mixed
Pendekatan Mixed menggunakan pendekatan Bottom-Up dan Top-Down untuk bagian yang berbeda sebelum pada akhirnya digabungkan menjadi satu.
Menurut (Connolly dan Begg, 2010, p466 – 467), terdiri dari tiga tahapan dalam membuat desain basis data, yaitu:
2.1.5.6 Conceptual Database Design
Merupakan proses pembentukan model yang berasal dari informasi yang digunakan dalam perusahaan yang bersifat independen dari keseluruhan aspek fisik. Model data tersebut dibangun dengan menggunakan informasi dalam spesifikasi kebutuhan user dan merupakan sumber informasi. Identifikasi entitas, relationship, dan atribut. dibagi menjadi beberapa langkah, yaitu:
2.1.5.6.1 Membangun conceptual data model
1. Identifikasi Tipe Entitas
Langkah awal dalam membangun model data konseptual adalah mengidentifikasi tipe entitas. Menurut (Connolly dan Begg, 2010, p65), Entitas adalah sebuah objek yang berbeda (orang, tempat, benda, kejadian, konsep) dalam organisasi yang akan diwakili dalam basis data. Tujuan dari langkah ini adalah untuk menentukan tipe entitas utama yang dibutuhkan. Menentukan entitas dapat dilakukan dengan memeriksa user requirements specification, setelah terdefinisi dengan jelas maka entitas dapat diberi nama, contonya : Mahasiswa, Dosen, atau Mata_Kuliah.
2. Identifikasi Tipe Relationship
Setelah mendapatkan tipe entitas, langkah selanjutnya adalah melakukan identifikasi tipe relasi atau hubungan dari entitas sebelumnya. Menurut (Connolly dan Begg, 2010,
p144), Relasi adalah table dengan kolom dan baris. Tujuan dari langkah pada tahap ini adalah untuk mengidentifikasi suatu hubungan (relationship) yang penting yang telah ada antara entitas yang telah diidentifikasi, nama dari suatu relationship menggunakan kata kerja (verb), contohnya: mempelajari, memiliki, atau mempunyai.
3. Identifikasi dan Asosiasi Atribut dengan Tipe Entitas dan Tipe Relationship
Pada langkah selanjutnya akan dilakukan identifikasi dan hubungan atribut dengan tipe entitas. Menurut (Connolly dan Begg, 2010, p144), Atribut adalah nama kolom dari suatu relasi. Tahap ini bertujuan untuk menghubungkan atribut dengan entitas atau relationship yang tepat. Atribut yang dimiliki setiap entitas atau relationship memiliki identitas atau karakteristik yang sesuai dengan memperhatikan atribut berikut : simple attribute, composite attribute, single-valued attribute, multi-valued attribute dan derived attribute.
4. Menentukan Domain Atribut
Langkah selanjutnya ialah menentukan domain atribut. Menurut (Connolly dan Begg, 2010, p144), Domain adalah himpunan nilai – nilai yang diijinkan untuk satu ata lebih atribut. Tujuan dari tahap ini ialah menentukan domain atribut pada model data konseptual. Meliputi:
o Menentukan ukuran dan format atribut
o Menentukan himpunan nilai yang boleh diisikan pada atribut
o Menentukan Atribut Candidate Key, Primary Key, Alternate Key
Untuk menentukan jenis relasi kunci (key) terlebih dahulu harus mengetahui pengertian dari masing – masing relasi key tersebut. Menurut (Connolly dan Begg, 2010, p150-p151),
Super Key adalah atribut atau kumpulan atribut, yang secara unik mengidentifikasi sebuah tupel dalam relasi,
• Primary Key adalah candidate key yang dipilih untuk mengidentifikasi tupel secara unik dalam relasi,
• Foreign Key adalah atribut atau bagian dari atribut, dalam satu relasi yang cocok dengan candidate key dari beberapa (mungkin sama) relasi.
• Candidate Key merupakan himpunan atribut • minimal yang dapat membedakan setiap baris data
dengan unik dalam sebuah tabel,
• Alternate Key adalah candidate key yang tidak dipilih untuk mengidentifikasi tupel secara unik dalam relasi,
o Memeriksa model dari Redudancy
Mengecek setiap entity dan attribute terhadap redudansi (redundancy) dalam model, tahap ini dilakukan untuk memastikan bahwa tidak ada dua entitas yang sama. Kemudian diperiksa juga apakah ada hubungan antar entitas yang bersifat rangkap. Hal yang biasanya dilakukan (Connolly dan Begg, 2010, p482), yaitu:
Melakukan pengecekan terhadap relasi (1:1) one – to – one
Menghapus redundant relationship
Selanjutnya adalah menjamin model konseptual dapat mendukung kebutuhan transaksi yang diperlukan oleh view. Pengujian dilakukan dengan melakukan operasi – operasi pada entitas secara manual. Dua cara dalam melakukan pengujian (Connolly dan Begg, 2010, p484), yaitu:
Mendeskripsikan transaksi beserta sumber data atributnya
Menggambarkan jalur transaksi (pathways) pada ERD
o Meninjau local conceptual data model dengan pengguna
Melakukan review terhadap model data konseptual dengan pengguna (user) untuk menjamin model telah merepresentasikan user view berdasarkan kebutuhan perusahaan. Jika ditemukan anomali pada model, maka perlu diadakan penyesuian dengan mengulangi beberapa langkah diatas. Proses ini dapat diulang, sampai mendapatkan model konseptual yang dibutuhkan user (Connolly dan Begg, 2010, p485).
2.1.5.7 Logical Database Design
Proses dalam membangun sebuah model dari informasi yang digunakan dalam perusahaan berdasarkan model data spesifik, tetapi tidak bergantung pada DBMS tertentu dan pertimbangan fisikal lainnya (Connolly dan Begg, 2010, p490). Dibagi menjadi beberapa langkah, yaitu:
2.1.5.7.1 Membangun dan memvalidasi logikal data model
1. Menentukan Relasi – relasi untuk Model Data Logikal
Didalam tujuan tahap ini adalah untuk membuat hubungan bagi model data logical untuk mewakili beberapa entitas, hubungan, dan atribut yang telah diidentifikasi.
Beberapa hubungan yang mungkin terjadi pada model data konseptual, (Connolly dan Begg, 2010, p492) yaitu:
o Tipe strong entity o Tipe weak entity
o Tipe hubungan biner one – to – many (1:*) o Tipe hubungan one – to – one (1:1)
o Tipe hubungan rekursif one – to – one (1:1) o Tipe hubungan superclass/subclass
o Tipe hubungan biner many – to – many (*:*) o Tipe complex relationship
o Multi – Value attributes
2. Validasi Model dengan Normalisasi (Normalization Form)
Memvalidasi hubungan – hubungan didalam model data logical menggunakan normalisasi. Tujuan dari normalisasi (normalization) adalah untuk memastikan bahwa himpunan relasi setidaknya memiliki jumlah atribut yang cukup untuk mendukung kebutuhan data pada perusahaan, (Connolly dan Begg, 2010, p501).
Menurut (Connolly dan Begg, 2010, p416), Normalisasi adalah sebuah teknik untuk menghasilkan sebuah hubungan dengan sifat – sifat yang diinginkan sesuai dengan kebutuhan data dari perusahaan.
Proses normalisasi yang pertama dimulai dengan mengirim data dari sumbernya, contohnya adalah bentuk standar entity data ke dalam format table dengan beberapa baris dan kolom. Format yang dimaksud adalah table dengan bentuk yang belum ternomalisasi (unnormalized form) disebut juga sebagai unnormalized table.
Menurut (Connolly dan Begg, 2010, p430), bentuk yang belum ternormalisasi dengan baik (unnormalized form,
UNF), adalah sebuah table yang mengandung satu atau lebih kelompok data yang berulang (repeating groups) adalah sebuah kelompok atribut yang berbeda didalam sebuah tabel dimana atribut tersebut mempunyai beberapa nilai atau satu atribut (nominated key) pada tabel. Key yang dimaksud adalah atribut yang secara unik diidentifikasi pada tiap baris didalam tabel yang belum ternormalisasi.
Menurut (Connolly dan Begg, 2010, p430), Berikut adalah bentuk – bentuk dari normalisasi, yaitu:
A. First Normal Form (1NF)
Sebuah relasi dimana persimpangan setiap baris dan kolom berisi satu dan hanya satu nilai (Connolly dan Begg, 2010, p430). Sebuah relasi akan berada dalam bentuk 1NF jika repeating groups pada tabel yang tidak normal (unnormalized table), yaitu:
• Dengan memasukkan data yang sesuai ke dalam kolom yang kosong dari baris yang mengandung kata yang berulang.
• Dengan menempatkan data yang berulang bersama salinan dari atribut kunci pada relasi yang terpisah.
B. Second Normal Form (2NF)
Menurut (Connolly dan Begg, 2010, p434) relasi dikatakan 2NF jika relasi berada pada 1NF dan setiap atribut yang bukan primary key bergantung sepenuhnya (full functionally dependent) terhadap primary key. Full functionally dependent terjadi jika A dan B merupakan atribut dari suatu relasi, dan B dikatakan bergantung penuh terhadap A (A->B), namun bukan subset dari A.
C. Third Normal Form (3NF)
Menurut (Connolly dan Begg, 2010, p435 – 436), Third Normal Form (3NF) adalah sebuah relasi
yang memenuhi First Normal Form (1NF) dan Second Normal Form (2NF) dimana tidak terdapat atribut non – primary key yang bersifat transitively dependent dari primary key.
Menurut (Connolly dan Begg, 2010, p424), transitive dependency adalah jika kondisi A, B, dan C merupakan atribut – atribut dari sebuah relasi seperti, jika A->B dan B->C, maka C adalah transitively dependent dari A melalui atau via B (disediakan bahwa A bukan functionally dependent dari B dan C). Dalam normalisasi ketiga ini, atribut yang tidak memberikan kontibusi 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 adanya manipulasi.
3. Validasi Relasi dengan User Transaction
Tujuan dari validasi transaksi pengguna adalah untuk memastikan bahwa relasi dalam model data logical mendukung kebutuhan transaksi. Dengan menggunakan relasi, link primary/foreign key yang diperlihatkan pada relasi, diagram ER (Entity Relationship) dan kamus data dilakukan secara manual (Connolly dan Begg, 2010, p502).
4. Mendefinisikan kendala Integrity
Salah satu fungsi dari Database Management System (DBMS) adalah integrity services, yakni memastikan baik data di dalam basis data maupun pengubahan data selalu memenuhi aturan. Integritas basis data berkaitan dengan kebenaran dan konsistensi dari data yang disimpan, dimana berkaitan dengan
constraint yang merupakan aturan didalam basis data yang tidak dapat dilanggar Connolly dan Begg, 2010, p103).
Gambar 2.4 Contoh Basis Data Relational
Tujuan dari memeriksa batasan integritas dalam model data logikal adalah batasan yang dipaksakan untuk melindungi basis data dari ketidaklengkapan, ketidakakuratan dan ketidak konsisten. Tipe – tipe Integrity constraint, (Connolly dan Begg, 2010, p231) yaitu:
o Required data
Misalnya tanggal di tabel Transaksi dan nama di tabel Produk pada gambar 1 harus ada nilainya, jadi keduanya merupakan required data, atau dengan kata lain kedua atribut tersebut tidak diijinkan bernilai null. o Attribute domain constraint
Merupakan sekumpulan nilai yang diijinkan untuk sebuah atau banyak atribut. Misalnya Kode Produk di tabel Produk dan Detail Transaksi pada gambar 1 harus diawali oleh sebuah huruf P capital dan diikuti oleh 3 karakter angka(0-9), yakni dengan range P001-P999.
o Entity integrity
Aturan ini diterapkan untuk primary key dari sebuah tabel, yakni atribut yang merupakan primary key tidak boleh bernilai null. Sebuah primary key merupakan minimal identifier yang digunakan untuk mengidentifikasi data secara unik, artinya tidak ada subset dari primary key yang cukup untuk identifikasi sebuah data secara unik. Misalnya tabel
DetailTransaksi yang ditunjukkan pada gambar 1. Tabel DetailTransaksi memiliki composite key (memiliki lebih dari 1 atribut sebagai primary key) antara lain KodeTransaksi dan KodeProduk, dimana 1 KodeTransaksi bisa terdiri dari banyak KodeProduk dan 1 KodeProduk dapat dibeli dibanyak KodeTransaksi. Penerapan entity integrity pada tabel DetailTransaksi yakni saat memasukkan sebuah data baru maka tidak diijinkan memberikan nilai null baik untuk atribut KodeTransaksi dan KodeProduk, serta keunikan sebuah data merupakan kombinasi dari kedua nilai atribut primary key (KodeTransaksi dan KodeProduk).
o Referential integrity
Aturan ini diterapkan untuk foreign key, yakni jika terdapat sebuah foreign key disebuah tabel maka nilai dari foreign key harus sesuai dengan nilai candidate key dari tabel yang diacu oleh foreign key atau bernilai null (jika atribut foreign key bukan required data). Berdasarkan gambar 1, tabel DetailTransaksi memiliki 2 foreign key antara lain KodeTransaksi yang mengacu pada KodeTransaksi dari tabelTransaksi dan KodeProduk yang mengacu pada KodeProduk dari tabel Produk. Sehingga atribut foreign key pada tabel DetailTransaksi harus sesuai dengan nilai atribut yang diacu, namun tidak boleh bernilai null karena keduanya merupakan primary key seperti yang telah dijelaskan pada poin sebelumnya. o General constraints
Merupakan aturan tambahan yang dispesifikasikan oleh pengguna atau administrator basis data untuk mendefinisikan batasan dari perusahaan. Misalnya sebuah cabang hanya boleh memiliki maksimum 20 karyawan, sehingga setiap
karyawan baru yang akan ditempatkan di sebuah cabang maka dilakukan pengecekan apakah jumlah karyawan di cabang tersebut sudah mencapai 20 orang. Jika sudah terdapat 20 orang karyawan pada cabang tersebut, maka penempatannya tidak dapat di cabang tersebut atau karyawan baru bisa ditempatkan di cabang tersebut jika cabang tersebut belum memiliki 20 orang karyawan.
5. Review data logikal model dengan user
Meninjau kembali model data logikal dengan pengguna untuk memastikan bahwa mereka mempertimbangkan model tersebut untuk menjadi representasi sesungguhnya dari kebutuhan data oleh perusahaan. Jika user puas dengan model tersebut maka langkah selanjutnya yang diambil tergantung pada jumlah user view yang terkait dengan basis data dan bagaimana pengelolaannya (Connolly dan Begg, 2010, p506).
6. Menggabungkan Logical Data Model ke dalam Global Model (Optional)
Tujuannya adalah untuk menggabungkan model data logikal ke dalam model data global yang mewakili semua pandangan pengguna basis data. Meliputi proses penggabungan model data logikal ke dalam global, serta validasi model data logikal dan meninjau ulang model data logikal global dengan pengguna (Connolly dan Begg, 2010, p506).
7. Pemeriksaan untuk perkembangan lebih lanjut
Tujuan dari pemeriksaan perkembangan lebih lanjut adalah untuk menentukan apakah ada perubahan signifikan yang mungkin terjadi dimasa yang akan dating serta menilai
apakah model data logikal dapat mengakomodasi perubahan tersebut (Connolly dan Begg, 2010, p517).
2.1.5.8 Physical Database Design
Proses dalam menghasilkan deskripsi dari implementasi basis data dalam secondary storage, menjelaskan basis relasi, organization file, penggunaan index untuk mencapai pengaksesan data yang efisien dan hal lain yang berhubungan dengan batasan integritas dan masalah keamanan (Connolly dan Begg, 2010, p467). Dibagi menjadi beberapa langkah, yaitu:
2.1.5.8.1 Menerjemahkan logical data model DBMS
1. Merancang relasi – relasi dasar
Tujuannya adalah untuk memutuskan bagaimaa relasi dasar yang diidentifikasi dalam model data logikal dalam target DBMS dapat diwakilkan. Dalam mewakili perancangan relasi dasar menggunakan bentuk (Database Design Language) untuk menentukan domain, default values, dan indicator null (Connolly dan Begg, 2010, p525).
2. Merancang representasi untuk data turunan (derived data) Tujuannya adalah untuk memutuskan bagaimana derived data yang muncul didalam model data logikal dalam target DBMS dapat diwakilkan. Derived atau calculated attributes adalah nilai atribut yang dapat ditemukan dengan memeriksa nilai dari atribut lain (Connolly dan Begg, 2010, p526).
3. Merancang General Constraint
Tujuannya adalah untuk merancang beberapa general constraint pada target DBMS
2.1.5.8.2 Merancang file organization dan indeks
Tujuan dari menganalisa transaksi – transaksi adalah untuk memahami fungsionalitas dari transaksi yang akan berjalan dibasis data dan menganalisa beberapa transaksi penting. Dalam menganalisa transaksi yang harus diidentifikasi berdasarkan performa (Connolly dan Begg, 2010, p529), yaitu:
- Transaksi yang dinilai cukup kritis ke dalam operasi bisnis;
- Waktu dimana pada hari atau minggu tertentu terjadinya permintaan yang tinggi pada basis data yang disebut (peak load);
- Transaksi yang berjalan cukup sering dan akan mempunyai dampak yang signifikan pada performa.
2. Memilih organisasi file (file organization)
Tujuan dari memilih file organization adalah untuk menentukan berkas – berkas organisasi data yang efisien pada setiap base relation (Connolly dan Begg, 2010, p534). Beberapa berkas – berkas oraganisasi data yang ada, sebagai berikut:
Hash B+-tree Clusters Heap
Indexed Sequential Office Access Method (ISAM)
3. Memilih index – index
Tujuan dalam memilih indeks adalah untuk menentukan apakah dengan menambah indeks akan memperbaiki kinerja system (Connolly dan Begg, 2010, p535).
4. Memperkirakan kebutuhan disk space
Memperkirakan jumlah ruang disk yang diperlukan oleh basis data (Connolly dan Begg, 2010, p541).
5. Merancang User View
Tujuannya adalah untuk merancang iuser view yang diidentifikasi saat melakukan tahap pengumpulan dan analisa kebutuhan dari siklur hidup pengembangan sisitem basisi data (Connolly dan Begg, 2010, p542).
6. Merancang mekanisme keamanan
Tujuannya adalah untuk merancang mekanisme keamanan untuk basis data yang telah di tentukan oleh user saat tahap pengumpulan dan analisa kebutuhan dari siklus hidup pengembangan sistem basis data (Connolly dan Begg, 2010, p542).
7. Mempertimbangkan pengenalan redudancy yang dipilih
Didalam perancangan basis data ini perlu adanya pertimbangan denormalisasi skema relasional untuk meningkatkan performa. Hasil dari normalisasi adalah perancangan basis data logikal secara structural konsisten dan menekan jumlah redudansi (Connolly dan Begg, 2010, p545 – 546). Beberapa faktor yang perlu dipertimbangkan, yaitu:
Denormalisasi membuat implementasi semakin kompleks; Denormalisasi selalu mengorbankan fleksibilitas;
Denormalisasi mungkin akan membuat cepat dalam retrieve data tetapi lambat dalam updates
Ukuran performa dari suatu perancangan basis data dapat dari sudut pandang tertentu, yaitu melalui pendekatan efisiensi data (normalized) atau pendekatan efisiensi proses (unnormalized). Efisiensi data dimaksudkan untuk meminimalkan kapasitas disk, dan efisiensi proses saat melakukan retrieve data dari basis data (Connolly dan Begg, 2010, p546).
Bertujuan untuk memonitor sistem operasional, meningkatkan performa, dan menentukan perancangan sistem yang tepat atau menggambarkan perubahan kebutuhan.
2.1.5.9 Application Design
Menurut (Connolly dan Begg, 2010, p329 – 331), Perancangan antarmuka pengguna dan program aplikasi yang menggunakan dan memproses basis data. Perancangan basis data dan aplikasi merupakan aktifitas pararel yang meliputi dua aktifitas penting yaitu: Perancangan Transaksi (Transaction Design).
Transaksi adalah salah satu serangkaian aksi ayng digunakan oleh pengguna tunggal atau program aplikasi yang mengakses atau merubah isi dari basis data. Kegunaan dari perancangan transaksi adalah untuk menetapkan keterangan karakteristik high level dari suatu transaksi yang dibutuhkan pada basis data, sebagai berikut:
Data yang akan digunakan oleh transaksi Karakteristik fungsional dari suatu transaksi Output transaksi
Keuntungan bagi pengguna
Tingkat kegunaan yang diharapkan
Perancangan Antarmuka Pengguna (User Interface Design)
Beberapa hal yang perlu diperhatikan untuk merancang tampilan form atau report adalah sebagai berikut:
o Tampilan form report yang mudah dibaca o Nama field mudah dipahami
o Bentuk tampilan user interface yang mudah dipahami o Pengaturan warna yang konsisten
o Judul yang sesuai
o Intruksi yang komprehensif
Menurut (Connolly dan Begg, 2010, p325 – 329), Pemilihan DBMS dilakukan untuk memilih DBMS yang sesuai dengan aplikasi basis data. Langkah – langkah dalam pemilihan DBMS:
o Mendeskripsikan cangkupan tugas berdasarkan kebutuhan perusahaan
o Membuat perbandingan mengenai dua atau lebih produk DBMS o Mengevaluasi produk – produk DBMS
o Merekomendasikan pemilihan DBMS dan membuat laporan hasil dari evaluasi produk DBMS
2.1.5.11 Prototyping (Optional)
Menurut (Connolly dan Begg, 2010, p333) Pada kondisi tertentu dimana kita dapat memilih apakah akan membuat prototipe atau langsung mengimplementasikan basis data. Tujuan utamanya adalah untuk menguji apakah fitur – fitur yang ada pada sistem telah bekerja sesuai dengan karakteristik pengguna, sehingga kita dapat memperjelas kebutuhan pengguna dan mengembangkan sistem serta mengevaluasi kelayakan desain sistem tesebut.
Menurut (Connolly dan Begg, 2010, p333), ada dua cara strategi membuat protoype yaitu:
o Requirement Prototyping digunakan prototipe untuk menentukan kebutuhkan suatu aplikasi basis data yang diusulkan, ketika kebutuhan dirasakan sudah lengkap maka prototipe untuk menentukan kebutuhan suatu aplikasi basis data yang diusulkan tidak lagi digunakan.
o Prototype Evolutioner digunakan untuk tujuan yang sama, perbedaannya prototipe tidaklah dibuang tetapi dikembangkan lebih lanjut sehingga menjadi aplikasi basis data
2.1.6 Entity – Relationship Modeling (ERD)
Menurut (Connolly dan Begg, 2010, p371), Entity Relationship (ER) merupakan sebuah abstraksi dan representasi konseptual dari data. Entity
Relationship Modeling adalah pendekatan top – down untuk merancang basis data dimana proses perancangan diawali dengan mengidentifikasi data utama yaitu entity dan relationship yang keduanya harus dipresentasikan dalam sebuah model.
Menurut (Connolly dan Begg, 2010, p372 – p392), Entity Relationship Modeling memiliki beberapa konsep dasar, yaitu:
o Tipe entitas
• Strong entity dan weak entity
Menurut (Connolly dan Begg, 2010, p383), strong entity adalah sebuah tipe entitas yang keberadannya tidak bergantung pada tipe entitas lain. Karakteristiknya adalah setiap entitas dapat diidentifikasi dengan primary key dari tipe entitas. Sedangkan weak entity adalah tipe entitas yang keberadaannya bergantung pada tipe entitas lain. Karakteristiknya adalah atribut yang terdapat pada entitas tersebut tidak dapat mengidentifikasi tipe entitas secara unik.
o Tipe–tipe Relasi
Menurut (Connolly dan Begg, 2010, p372), Tipe relasi adalah sebuah kumpulan hubungan yang memiliki arti antara tipe – tipe entitas. Relationship occurrence adalah hubungan yang dapat diidentifikasi secara unik yang dimana hubungan tersebut meliputi satu kejadian dari setiap tipe entitas yang berpatisipasi.
• Degree of relationship type
Menurut (Connolly dan Begg, 2010, p376), derajat tipe relasi merupakan jumlah tipe entitas yang berpatisipasi dalam relasi. Entitas yang berkaitan dalam tipe relasi dikenal sebagai participant dalam relasi. Jumlah participant dalam tipe relasi dikenal sebagai degree dari relasi. Relasi dengan degree dua
disebut binary, sedangkan relasi dengan degree tiga disebut tenary, dan dengan degree empat disebut quantenary.
• Recursive relationship
Menurut (Connolly dan Begg, 2010, p378), relasi rekursif adalah sebuah tipe relasi dimana tipe entity yang sama berpatisipasi lebih dari satu kali dalam peran yang berbeda.
• Attributes on relationship
Attribute on relationship adalah atribut pada relasi yang mengidentifikasi hubungan antar entitas (Connolly dan Begg, 2010, p384).
o Tipe–tipe Atribut (Attribute)
Menurut (Connolly dan Begg, 2010, p379), atribut merupakan property dari sebuah entity atau tipe relasi. Attribute domain adalah kumpulan nilai – nilai yang diperbolehkan untuk satu atau lebih atribut (Connolly dan Begg, 2010, p379 – p381).
- Simple dan Composite Attribute
Simple attribute adalah atribut yang tersusun dari satu komponen secara independen sehingga tidak dapat dipecah menjadi atribut yang lebih kecil. Sedangkan composite attribute adalah atribut yang tersusun dari banyak komponen secara independen sehingga dapat dipecah menjadi komponen independen yang lebih kecil.
- Single – valued attribute adalah atribut yang hanya memiliki satu nilai untuk setiap tipe entitas. Sebagian besar atribut adalah single – value sedangkan, multi – valued attribute adalah atribut yang memiliki banyak nilai untuk setiap tipe entitas.
- Derived Attribute
Derived Attribute adalah sebuah atribut yang merepresentasikan nilai yang berasal dari nilai sebuah atribut yang berhubungan atau kumpulan atribut sehingga tidak perlu berada dalam tipe entity yang sama.
- Kunci (Key)
Kunci merupakan atribut – atribut yang digunakan untuk menjelaskan sebuah entitas. Tipe – tipe dari key yaitu:
• Primary Key adalah candidate key yang dipilih untuk mengidentifikasi secara unik suatu tipe entitas. Candidate key yang tidak dipilih sebagai primary key disebut alternate key.
• Foreign Key adalah kolom yang diambil dari primary key entitas lain yang menunjukkan hubungan antar dua table tersebut.
• Composite Key adalah candidate key yang terdiri dari dua atau lebih atribut (Connolly dan Begg, 2010, p382) • Candidate Key adalah minimal set dari atribut yang
secara unik mengidentifikasi suatu tipe entitas.
• SuperKey adalah satu atau gabungan attribute yang dapat membedakan setiap baris data dalam sebuah table secara unik.
o Structural constraints
Tipe utama didalam batasan hubungan relationship disebut multiplicity (Connolly dan Begg, 2010, p385), multiplicity merupakan jumlah (range) dari kejadian yang mungkin dari satu entitas yang berhubungan dengan kejadian tunggal dari jenis entitas berkaitan dengan hubungan tertentu.
Menurut (Connolly dan Begg, 2010, p386 – 388), terdapat jenis – jenis multiplicity, yaitu:
1. One – to – one (1:1) relationship
Setiap entitas maksimal hanya dapat memiliki satu relasi dengan entitas lain.
Gambar 2.5 Relasi one – to – one
2. One – to – many (1:*) relationship
Setiap entitas dapat memiliki satu atau lebih relasi dengan entitas lain.
Gambar 2.6 Relasi one – to – many
3. Many – to – Many (*:*) relationship
Setiap entitas dapat memiliki lebih dari satu relasi dengan entitas yang lain.
Gambar 2.7 Relasi many – to – many
Menurut (Connolly dan Begg, 2010, p390 – 391), Multiplicity terdiri dari dua kedala (constraints) yang terpisah dikenal sebagai kardinalitas (cardinality) dan partisipasi (participation)
o Cardinality
Menjelaskan jumlah maksimum kejadian kemungkinan hubungan untuk entitas yang berpatisipasi dalam jenis hubungan yang diberikan. o Participation
Menentukan apakah semua atau hanya beberapa kejadian entitas berpatisipasi dalam sebuah hubungan.
2.2 Teori Khusus 2.2.1 Pembelian
Menurut (Mulyadi, 2001, p299), Pembelian adalah suatu usaha yang digunakan perusahaan untuk pengadaan barang yang diperlukan perusahaan. Transaksi pembelian tergolong menjadi dua yaitu:
o Pembelian Lokal
Pembelian lokal adalah pembelian dari pemasok dalam negeri atau produk bikinan negeri sendiri
o Pembelian Impor
Pembelian dari pemasok luar negeri atau barang buatan luar negeri
Menurut (Mulyadi, 2001, p303 – 305), jaringan prosedur yang membentuk sistem pembelian, yaitu:
o Prosedur permintaan pembelian, didalam prosedur ini fungsi gudang mengajukan permintaan pembelian dalam bentuk formulir surat permintaan pembelian.
o Prosedur permintaan penawaran harga dan pemilihan pemasok, fungsi pembelian mengirimkan surat permintaan penawaran harga kepada pemasok untuk memperoleh informasi mengenai harga barang dan berbagai syarat pembelian yang lain untuk memungkinkan pemasok yang akan ditunjuk sebagai pemasok barang yang diperlukan perusahaan.
o Prosedur order pembelian mengirim surat order pembelian kepada pemasok yang dipilih dan memberitahukan kepada unit – unit organisasi lain dalam perusahaan mengenai order pembelian yang dikeluarkan oleh perusahaan.
o Prosedur penerimaan barang melakukan pemeriksaan jenis barang, kuantitasm dan mutu bahan yang diterima dari pemasok dan kemudian membuat penerimaan barang dari pemasok.
o Prosedur distribusi pembelian meliputi distribusi rekening yang didebet dari transaksi pembelian untuk kepentingan pembuatan laporan manajemen.
Contoh beberapa dokumen yang digunakan dalam sistem pembelian, sebagai berikut:
o Surat Order pembelian o Surat permintaan pembelian o Laporan penerimaan barang o Bukti pembelian
2.2.2 Penjualan
Menurut (Mulyadi, 2001, p202), penjualan terdiri dari penjualan barang dan jasa, baik secara kredit maupun tunai. Dalam transaksi penjualan kredit, jika order dari pelanggan telah terpenuhi dengan pengiriman barang atau penyerahan jasa untuk jangka waktu perusahaan memiliki piutang kepada pelanggan. Transaksi penjualan secara tunai, barang atau jasa baru
diserahkan oleh perusahaan kepada pembeli, jika perusahaan telah menerima kas dari pembeli.
Prosedur yang telah membentuk sistem penjualan (Mulyadi, 2001, 219), yaitu:
o Prosedur order penjualan yang menerima order dari pembeli dan menambahkan informasi penting pada surat order.
o Prosedur penagihan adalah membuat faktur penjualan dan mengirimkannya kepada pembeli.
o Prosedur pencatatan piutang, fungsi akutansi mencatat tebusan faktur penjualan kedalam piutang atau dalam metode pencatatan dalam mengarsipkan dokumen tebusan berdasarkan abjad.
Terdapat beberapa dokumen yang digunakan dalam sistem penjualan, adalah:
o Faktur dan tebusannnya o Laporan penjualan
o Surat order pengiriman dan tebusannya
2.2.3 Persediaan
Menurut (Mulyadi, 2001, p556), persediaan bertujuan untuk mencatat mutasi setiap jenis persediaan yang disimpan digudang. Persediaan pada perusahaan dagang disebut persediaan barang dagangan, yang terdiri dari barang – barang yang disediakan untuk dijual kepada para pelanggan atau konsumen selama kegiatan penjualan perusahaan berjalan. Contoh istilah yang sering digunakan, yaitu:
o Stock Opname adalah pemeriksaan stok fisik yang tersedia (gudang) dan membandingkannya dengan stok yang tercantum (komputer). Biasanya dilakukan sebulan atau setahun sekali, tergantung pada banyaknya jenis barang.
o Stock Card
Stock Card adalah catatan berupa stok harian dimana berupa jumlah barang dengan sistem pembelian merupakan penambahan stok barang. Setiap hari catatan stok perlu diperbaharui.
o Adjusment Stock
Setelah dilakukannya stock opname bila ada barang yang rusak, hilang dan sebagainya, maka akan dilakukan penyesuaian terhadap stok fisik yang tercatat.
Menurut (Mulyadi, 2001, p559), beberapa prosedur yang berkaitan dengan sistem persediaan, yaitu:
o Prosedur pencatatan produk jadi
Prosedur ini merupakan salah satu prosedur dalam sistem akutansi biaya produksi, dalam prosedur ini, dicatat harga pokok produk jadi yang didebitkan dalam rekening persediaan produk jadi dan dikreditkan ke dalam rekening barang dalam proses. Catatan akutansi yang digunakan dalam prosedur pencatatan produk jadi adalah kartu gudang, kartu persediaan, jurnal umum.
o Prosedur permintaan dan pengeluaran barang digudang
Prosedur ini merupakan salah satu prosedur yang membentuk sistem akutansi biaya produksi. Pada prosedur ini dicatat harga pokok persediaan bahan baku, bahan habis pakai pabrik, dan suku cadang yang digunakan dalam kegiatan proses produksi dan kegiatan non produksi.
o Sistem perhitungan fisik persediaan
Sistem perhitungan fisik persediaan umumnya digunakan oleh perusahaan untuk menghitung secara fisik persedian yang disimpan digudang. Hasilnya adalah untuk meminta pertanggung jawaban bagian gudang mengenai pelaksanaan fungsi penyimpanan dan pertanggung jawaban bagian kartu persediaan mengenai kendala catatan persediaan yang diselenggarakan, serta melakukan penyesuaian terhadap catatan persediaan dibagian kartu persediaan.
o Prosedur pencatatan harga pokok persediaan yang dikembalikan kepada pemasok
Prosedur ini merupakan salah satu prosedur yang membentuk sistem retur pembelian. Jika persediaan yang dibeli dikembalikan kepada bagian pemasok, maka transaksi retur pembelian ini akan mempengaruhi persediaan yang bersangkutan, yaitu mengurangi kuantitas persediaan dalam kartu gudang yang diselenggarakan oleh bagian gudang serta mengurangi kuantitas dan harga pokok persediaan dalam kartu penyediaan yang bersangkutan.
o Prosedur pencatatan harga produk jadi yang dijual
Prosedur ini merupakan salah satu prosedur dalam sistem penjualan. Catatan akutansi yang digunakan dalam prosedur pencatatan harga produk jadi yang dijual adalah kartu gudang, kartu persediaan, dan jurnal umum.
Beberapa dokumen yang digunakan dalam sistem persediaan, adalah: o Memo Kredit
o Memo debit
o Bukti permintaan dan pengeluaran barang jadi o Bukti pengembalian barang gudang
o Laporan penerimaan barang o Laporan pengiriman barang o Faktur penjualan
o Surat order pengirima
2.2.4 SQL (Srtuctured Query Language)
Menurut (Connolly dan Begg, 2005, p113), SQL merupakan model bahasa pemrograman yang dirancang untuk menggunakan relasi yang dimana menerima input dan menghasilkan output.
Contoh sederhana query SQL, sebagai berikut:
SELECT CustomerID, CompanyName, City
WHERE Country = “Jakarta” AND Region = “Indonesia”
2.2.5 C#
Menurut (Dietel, 2010, p42), C# merupakan bahasa pemrograman yang berorientasi objek dan didesain secara spesifik untuk platform. NET sebagai bahasa yang memungkinkan programmer dapat mudah bermigrasi ke NET, C# memiliki akar dari C, C++, dan mengadaptasikan fitur – fitur terbaik, sehingga memungkinkan programmer untuk mengembangkan aplikasi dengan cepat.
Contoh anatomi sederhana dari C# Program,menurut (Troelsen, 2007, p65):
using System;
class HelloClass
{
public static void main (string [] agrs){
Console.WriteLine(“Hello World!!!”);
Console.ReadLine();
}
{
2.2.6 Activity Diagram
Activity Diagram adalah gambaran diagram yang menjelaskan aliran aktivitas dari sistem yang berbasis object oriented, diagram ini mirip dengan flow chart, menjelaskan bagaimana aliran proses dan aktivitas apa saja yang dilakukan oleh system tersebut serta menentukan control dan fungsi user berinteraksi dengan system
Didalam activity diagram terdapat beberapa komponen (Tegarden, Dennis, dan Haley Wixom, 2013, p166), yaitu:
Tabel 2.5 Komponen Activity Diagram
Simbol Nama Keterangan
Initial State Memulai aktivitas diagram yang dilakukan
Final State Digunakan untuk mengakhiri aktivitas
Control Flow Digunakan untuk menghubungkan Antara action satu dengan action lainnya
State Action yang dilakukan oleh sistem
Decision Menentukan kondisi dimana aktivitas harus terpenuhi atau tidak
