BAB 2 LANDASAN TEORI

BAB 2 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.

5

6 Tabel 2.1 Contoh Menguji Dokumentasi Tujuan Dokumentasi Deskripsi

Contoh Dokumentasi

masalah

dan Memo internal, email, dan keluhan

kebutuhan basis data.

karyawan atau pelanggan saat rapat, serta

dokumen

yang

menjelaskan

berbagai masalah. Pemeriksaan

kembali

kinerja

dan

berbagai laporan. Deskripsi perusahaan

kebutuhan Struktur organisasi, statement misi, dan yang

dapat rencana strategi perusahaan.

menimbulkan masalah.

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

7 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 Keberhasilannya

mempunyai

bergantung

banyak

kepada

pertanyaan

tanggapan

yang

orang

spesifik.

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 Mahal dan sangat memakan waktu diwawancarai

untuk

menjawab Tidak praktis.

dengan bebas dan secara terbuka ke pertanyaan. Memperbolehkan orang yang sedang Kesuksesan diwawancarai merasakan bagian dari pada proyek. Memperbolehkan

sangat

bergantung

keterampilan

komunikasi

pewawancara. pewawancara Kesuksesan dapat bergantung pada

untuk mengikuti komentar menarik kesediaan

orang

yang

sedang

yang dibuat oleh orang yang sedang diwawancarai untuk mengambil diwawancarai. Memperbolehkan

bagian dari wawancara. pewawancara

menyesuaikan atau mengulang kata

8 yang

dipertanyakan

ke

pewawancara. Memperbolehkan untuk

mengamati

pewawancara 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 Orang – orang dapat mengetahui dan data untuk diperiksa.

atau

tidak

mengetahui

ketika

mereka sedang diamati, maka mereka dapat melakukan suatu hal yang berbeda. Pengamat dapat melihat secara Dapat nyata, apa yang dilaksanakan.

ketinggalan

pengamatan

ketika terdapat perbedaaan tingkat kesulitan dan jumlah pekerjaan dalam suatu periode.

Pengamat

dapat

memperoleh Beberapa tugas tidak dapat selalu

gambaran data suatu lingkungan dilakukan cara yang sama dimana fisik dari suatu tugas.

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

9 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

10 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

11 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

12 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 DDL ke data, sekumpulan tabel yang berisi data – data.

13
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.
Kompleksitas

14 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

Gambat 2.3 Database System Development Life Cycle

15

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.

16 Implementation

Melakukan penerapan pada sistem yang telah dibuat untuk digunakan dalam DBMS.

Data Conversion and

Mengecek kembali format data yang

Loading

digunakan pada DBMS.

Testing

Melakukan testing pada sistem basis data yang telah dibuat apakah layak digunakan atau tidak apakah sesuai dengan kebutuhan pengguna.

Operational

Sistem yang telah diimplementasikan

Maintenance

secara penuh akan dipantau terus menerus

dan

berkelanjutan

dipelihara untuk

secara

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:

17
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

18
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.

19 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,

20 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

5. Tipe – tipe attribut

21 Untuk menentukan jenis relasi kunci (key) terlebih dahulu harus mengetahui pengertian dari masing – masing relasi key tersebut. Menurut (Connolly dan Begg, 2010, p150p151), 

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

o Validasi Model Konseptual terhadap user transaction

22 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.

23 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,

24 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

25 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

26 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

27 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

28 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 pengguna

kembali

untuk

model

data

memastikan

logikal bahwa

dengan 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

29 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 1. Menganalisa transaksi

30 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).

31 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). 8. Mengawasi dan mengendalikan sistem operasional

32 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 2.1.5.10 DBMS Selection

33 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

34 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

35 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.

36

-

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.

37 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.

38

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:

39 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

40 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.

41 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.

42 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 FROM Customers

43 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:

44 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

Decision

Action yang dilakukan oleh sistem

Menentukan

kondisi

dimana

aktivitas harus terpenuhi atau tidak