BAB 2 TINJAUAN PUSTAKA 2.1 Teori-Teori Database 2.1.1
Database Menurut Connolly & Berg, basis data merupakan kumpulan data yang berhubungan secara logis dan deskripsi data tersebut, yang dirancang untuk memenuhi informasi yang dibutuhkan oleh organisasi. (Connolly & Begg, 2015, hal. 63) Menurut Indrajani, database adalah kumpulan terpadu dari elemen data logis yang saling berhubungan. (Indrajani, 2014, hal. 2)
2.1.2
Database Management System (DBMS) Sebuah sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisi, membuat, merawat, dan mengontrol akses ke database.
2.1.3
Bahasa Basis Data Bahasa basis data terbagi atas dua jenis , yaitu : 1.
Data Definition Language Bahasa Administrator
yang atau
memungkinkan user
untuk
Database
mendefinisikan,
menerangkan, dan memberi entitas-entitas, atribut, serta relationship yang dibutuhkan untuk aplikasi termasuk batasan-batasan dan integritasnya. (Indrajani, 2014, hal. 33) 2.
Data Manipulation Language Bahasa
yang
menyediakan
operasi
dasar
manipulasi data pada data yang terdapat dalam basis data. (Indrajani, 2014, hal. 33)
1
2 DML terbagi atas : 1. Procedural DML Bahasa
yang
memungkinkan
user
(programmer) untuk memberi instruksi pada sistem mengenai
data
yang
dibutuhkan
dan
cara
pemanggilannya. 2. Non Procedural DML Bahasa menentukan
yang
memungkinkan
data
yang
user
dibutuhkan
untuk dengan
menyebutkan spesifikasinya tanpa menspesifikasi cara mendapatkan data tersebut. 2.2 Database Lifecycle Database lifecycle atau biasa disebut sebagai daur hidup basis data adalah tahapan-tahapan yang harus dilalui guna mencapai tujuan sistem basis data yang terstruktur, baik, dan benar. Ada 8 (delapan) tahapan dalam pembuatan sistem basis data , dan berikut di bawah ini adalah penjelasan mengenai tiap tahapan pada pembuatan basis data; 2.2.1 Database Planning Merupakan aktvitas manajemen untuk merealisasikan tahapan Database Application Lifecycle secara efektif dan efisien (Connolly & Begg, 2015, hal. 347). Perencanaan basis data mencakup cara pengumpulan data, format data, dokumentasi yang diperlukan, cara membuat rancangan, dan implementasi. Perencanaan basis data terintegrasi dengan keseluruhan startegi sistem informasi organisasi. Metodologi untuk mengatasi hal tersebut terbagi atas 2 (dua) bagian , yaitu; •
Mendefiniskan mission statement untuk sistem basis data.
•
Mendefinisikan mission objectives.
3
2.2.2 Definisi Sistem Definisi sistem bertujuan untuk mendeskripsikan batasan dan ruang lingkup aplikasi basis data serta sudut pandangan user yang utama. Aplikasi basis data seharusnya memiliki satu atau lebih user views. User view mendefinisikan apa yang diharapkan dari aplikasi basis data berdasarkan peranan pekerjaan, seperti manajer dan supervisor, atau berdasarkan area aplikasi perusahaan, seperti pemasaran, personalia, dan pengendalian persediaan. Mengidentifikasi user view membantu untuk memastikan agar tidak ada pengguna basis data yang terlupakan dan mengetahui apa yang diinginkan pengguna saat aplikasi baru akan dibuat. Selain itu, user view membantu pengembangan
aplikasi
basis
data
yang
rumit
dan
dapat
menguraikannya menjadi beberapa sub bagian yang lebih sederhana. 2.2.3 Analisis dan Pengumpulan Kebutuhan Merupakan proses pengumpulan dan menganalisa informasi tentang organisasi yang akan didukung oleh aplikasi basis data dan menggunakan
informasi
tersebut
untuk
mengidentifikasikan
kebutuhan user terhadap sistem yang baru. Aktivitas penting lainnya dalam tahap ini adalah memastikan bagaimana menangani aplikasi basis data dengan multiple user views. Ada tiga macam pendekatan yang dapat digunakan dalam hal ini, yaitu; 1. Centralized Approach Kebutuhan setiap pengguna dibuat kedalam Set og Requirement dan model data global dibuat berdasarkan hal itu. 2. View Integration Approach Kebutuhan tiap user dibuat dalam model data yang terpisah. Model data menggambarkan singel user view disebut model data lokal, disusun dalam bentuk diagram dan dokumentasi yang mendeskripsikan kebutuhan user view
basis data. Model data lokal ini kemudian
4 digabungkan untuk menghasilkan model data global, yang menggambarkan keseluruhan user view basis data. 3. Gabungan
antara
Centralized
Approach
dan
View
Integration Approach. 2.2.4 Desain Basis Data Desain basis data adalah proses membuat desain yang akan mendukung operasional dan tujuan perusahaan. Tujuan desain basis data adalah; •
Menggambarkan relasi data antara data yang dibutuhkan oleh aplikasi dan user view.
•
Menyediakan model data yang mendukung seluruh transaksi yang diperlukan.
•
Menspesifikasilan desain dengan struktur yang sesuai dengan kebutuhan sistem.
Berikut ini adalah beberapa pendekatan yang dapat digunakan dalam mendesain basis data, yaitu; •
Top down
•
Bottom-up
•
Inside-out
•
Mixed Dalam merancang desain basis data dikenal pula adanya Data
Modelling, jadi data modeling memiliki fungsi untuk memahami arti semantik dari data dan juga untuk memudahkan komunikasi mengenai informasi yang dibutuhkan. Terdapat 3 (tiga) fase dalam membuat desain basis data , ke tiga fase tersbut ialah; 1. Conceptual Database Design Suatu proses pembentukan model yang berasal dari informasi yang ingin digunakan dalam perusahaan yang bersifat independent dari keseluruhan aspek fisik. 2. Logical Database Design
5 Sutau proses pembentukan model yang berasal dari informasi
yang digunakan
dalam perusahaan
yang
berdasarkan model data tertentu, namun masih independent dari DBMS tertentu. 3. Physical Database Design Proses yang menghasilkan deskripsi implementasi basis data pada penyimpanan sekunder. Atau , dapat dikatakan juga bahawa tahap ini merupakan cara pembuatan berdasarkan DBMS tertentu. 2.2.5 Perancangan Aplikasi Perancangan aplikasi merupakan perancangan user interface dan program aplikasi yang menggunakan dan melakukan proses terhadap basis data. Terdapat 2 (dua) aktivitas penting di dalam perancangan aplikasi, yakni ; •
Rancangan transaksi Merupakan tindakan yang dilakukan oleh single user atau program aplikasi , yang mengakses atau mengubah isi basis data. Berikut ini adalah 3 (tiga) tipe utama transaksi , yaitu ;
Retrieval : mendapatkan data untuk ditampilkan pada layar atau laporan.
Update : memasukkan record baru, menghapus record lama atau memodifikasi record yang ada dalam basis data.
•
Mixed : gabungan antara transaksi retrieval dan update.
Rancangan user interface
2.2.6 Implementasi Adalah realisasi fisik dari basis data dan rancangan aplikasi. Dapat dicapai menggunakan ; •
DDL untuk membuat skema basis data dan database files yang kosong.
•
DDL untuk membuat user view yang diinginkan.
6 3GL atau 4GL untuk membuat program aplikasi. Termasuk
•
didalamnya transaksi basis data yang menggunakan DML. 2.2.7 Pengujian Suatu proses eksekusi program aplikasi dengan tujuan untuk menemukan kesalahan dengan skenario tes yang direncanakan dan data yang sesungguhnya. Pengujian hanya akan terlihat jika terjadi kesalahan pada perangkat lunak. 2.2.8 Operasional pemeliharaan Suatu proses pengawasan dan pemeliharaan sistem setelah instalasi yang mencakup ; •
Pengawasan kinerja sistem.
•
Pemeliharaan dan pembaruan aplikasi basis data (jika perlu).
•
Penggabungan kebutuhan baru ke dalam aplikasi basis data.
2.3 Entity Relationship Modelling Entity Relationship Modelling adalah sebuh pendekatan top-bottom dalam perancangan basis data, yang dimulai dengan mengidentifikasikan data-data penting yang disebut dengan entitas, dan hubungan antar entitasentitas tersebut yang digambarkan dalam suatu model. (Indrajani, 2014, hal. 405). Namun dikarenakan masih adanya kekurangan pada ER model, maka dibuatlah Enhanced Entity Relational Model. Di dalam ER inilah terdapat generalization, specialization, dan aggregation. 2.3.1
Entity Type Kumpulan dari objek-objek dengan sifat (property) yang sama yang diidentifikasikan oleh perusahaan atau organisasi memiliki kedudukan yang sama. Dapat berupa fisik atau abstrak.
2.3.2
Relationship Type •
Relationship Types Kumpulan hubungan antar tipe entitas yang memiliki arti.
•
Relationship Occurence
7 Hubungan yang unik yang meliputi keberadaan tiap tipe entitas yang berpartisipasi.
•
Derajat Relationship Jumlah entitas yang berpartisipasi dalam sebuah hubungan. Derajat Relationship ini terdiri dari beberapa jenis , yakni ; Hubungan Binary Hubungan antara dua tipe entitas. Hubungan Ternary Hubungan antara tiga tipe entitas. Hubungan Quarternary Hubungan antara empat tipe entitas. Hubungan Unary Hubungan antara satu tipe entitas dimana tipe entitas tersebut berpartisipasi lebih dari satu hubungan dengan peran yang berbeda-beda.
•
Relationship Recursive Hubungan dalam satu entitas yang sama dengans satu atau lebih peranan.
2.3.3 Atribut Atribut merupakan sifat-sifat (property) sebuah entitas atau tipe relasi. -
Atribut Domain Himpunan dari nilai yang diizinkan untuk satu atau lebih atribut. Terdiri atas ; - Atribut Sederhana - Atribut Komposit - Atribut bernilai tunggal - Atribut bernilai banyak - Atribut turunan
-
Keys - Candidate Key
8 -
Primary Key
- Composite Key
2.3.4 Structural Constraints Di dalam setiap relationship terdapat batasan utama yang disebut multiplicity. Multiplicity berarti jumlah dari kejadian yang mungkin terjadi pada sebuah entitas yang terhubung ke satu kejadian dari entitas lain. Hubungan yang terjadi paling umum adalah binary relationship. Binary relationship terdiri atas ; •
One to one (1:1 , 1...1, 1)
•
One to many (1:*, 1..*)
•
Many to many (*:*, *...*)
2.3.5 Composition Merupakan bentuk khusus dari agregat yang menggambarkan hubungan asosiasi antar entitas, dimana terdapat hubungan yang kuat dan kebetulan dalam sebuah seluruh atau sebagian siklus. (Indrajani, 2014). 2.4 Normalisasi Menurut Connolly dan Begg (2015:452), normalisasi merupakan sebuah teknik untuk memproduksi satu set hubungan dengan sifat yang diinginkan, memberikan kebutuhan data pada perusahaan. Tujuan dari normalisasi adalah mengidentifikasi satu set hubungan yang sesuai untuk mendukung kebutuhan data pada perusahaan. Karakteristik yang sesuai antara lain: • Jumlah atribut yang sedikit yang diperlukan untuk mendukung kebutuhan data perusahaan. • Atribut-atribut dengan hubungan logikal yang erat(disebut juga functional dependency) dapat ditemukan pada hubungan yang sama. • Redundansi yang sedikit, dengan setiap atribut hanya merepresentasikan sekali, dengan pengecualian penting untuk atribut yang membentuk seluruh atau sebagian foreign keys, yang penting untuk gabungan hubungan terkait.
9 Bentuk-bentuk normalisasi menurut Connolly dan Begg (2015:466-472), antara lain:
1. Unnormalized Form (UNF) Merupakan sebuah tabel awal yang belum ternormalisasi yang berisikan satu atau lebih kumpulan data yang berulang. Untuk membuat tabel UNF yaitu dengan memindahkan data dari sumber informasi yang didapat ke dalam tabel dengan format baris dan kolom, jika ada atribut yang mempunyai banyak nilai (multivalue) akan masuk ke dalam bentuk UNF. 2. First Normal Form (1NF) Bentuk normalisasi tahap pertama yang merupakan sebuah relasi dimana sebuah titik pertemuan antara setiap baris dan kolom yang berisi satu dan hanya satu nilai. 3. Second Normal Form (2NF) Tahapan kedua setelah 1NF terpenuhi yaitu 2NF dimana merupakan sebuah relasi yang terdapat di dalam 1NF dan setiap atribut yang bukan primary key bergantung pada primary key. 4. Third Normal Form (3NF) Merupakan tahapan ketiga dalam normalisasi dimana sebuah relasi yang terdapat pada bentuk normalisasi pertama dan kedua, yang mana tidak ada atribut yang bukan primary key bergantung pada primary key. 2.5 Metodologi Perancangan Basis Data Menurut Connolly dan Begg (2015:504), metodologi perancangan basisdata merupakan pendekatan terstruktur yang menggunakan bantuan prosedur, teknik, alat, dan dokumentasi untuk mendukung dan memfasilitasi proses perancangan basisdata. Metodologi perancangan basisdata terbagi atas 3 tahap perancangan yaitu perancangan konseptual, perancangan logikal, dan perancangan fisikal. 2.5.1 Perancangan Konseptual
10 Perancangan konseptual merupakan proses membangun model data yang digunakan oleh suatu perusahaan, bebas dari segala pertimbangan fisik (Connolly dan Begg, 2015:505). Langkah-langkah dalam membangun model data konseptual yaitu (Connolly dan Begg, 2015:508-523):
Langkah 1 Membangun model data konseptual Langkah 1.1 Identifikasi tipe entitas Langkah pertama dalam membangun model data konseptual adalah menentukan objek-objek utama atau mengidentifikasi entitasentitas yang diperlukan pengguna. Langkah 1.2 Identifikasi tipe hubungan (relationship types) Mengindentifikasi hubungan-hubungan (relationship) yang penting antara entitas-entitas yang ditemukan pada tahap sebelumnya. Setelah mengidentifikasi entitas, tahap selanjutnya yaitu mengidentifikasi semua hubungan
pada
entitas-entitas
tersebut,
kemudian
menentukan
multiplicity setiap hubungannya dan memeriksa adanya fan dan/atau chasm traps pada model tersebut. a. Fan Traps terjadi dimana model yang merepresentasikan suatu hubungan antar entitas, tetapi alur relasinya memperlihatkan ambiguitas (Connolly dan Begg, 2002:364). b. Chasm Traps terjadi dimana model menggambarkan keadaan dari hubungan antara entitas yang satu dengan yang lainnya, tetapi tidak ada hubungan antara kedua entitas yang utama (Connolly dan Begg, 2002:365). Langkah 1.3 Identifikasi dan hubungkan atribut-atribut
dengan
entitas atau tipe hubungan (relationship types) Menghubungkan atribut-atribut dengan entitas atau hubungan yang tepat. Mengidentifikasi simple/composite attributes, single- valued/multivalued attributes, dan derived attributes. Lakukan dokumentasi atribut yang telah diidentifikasi. Langkah 1.4 Menentukan domain atribut Menentukan doamin atribut dalam model konseptual. Yang dimaksud domain
adalah
sekumpulan
nilai-nilai
dimana
suatu
atribut
11 menggambarkan nilainya. Contoh : nilai yang mungkin untuk atribut Jenis Kelamin dari entitas Admin adalah ‘L’ atau ’P’, wilayah dari atribut ini adalah single character string yang berisi nilai ‘L’ atau ‘P’. Setelah itu, dilakukan dokumentasi domain atribut.
Langkah 1.5 Menentukan atribut candidate, primary, dan alternate key Mengidentifikasi candidate key untuk tiap-tiap entitas dan jika ada lebih dari satu candidate key, pilih salah satu untuk menjadi primary key dan lainnya menjadi alternate key. Dalam menentukan primary key diantara candidate keys, pedoman yang dapat digunakan yaitu: • Candidate key dengan atribut yang paling sedikit. • Candidate key yang memiliki kemungkinan paling kecil untuk berubah nilainya. • Candidate key dengan karakter paling sedikit (untuk textual attribute(s)). • Candidate key dengan nilai maksimum terkecil (untuk numerical attribute(s)). • Candidate key yang paling mudah digunakan dari sisi pengguna. Dokumentasi primary dan alternate key untuk tiap-tiap entitas yang merupakan strong entity. Langkah
1.6.
Mempertimbangkan
penggunaan
Enchanced
Modelling Concept (langkah opsional) Mempertimbangkan
penggunaan
konsep
permodelan,
seperti
specialization/generalization, aggregation, dan composition. a. Specialization, adalah proses memaksimalkan perbedaan antara anggota entitas dengan mengidentifikasi karakteristik yang membedakan seluruh entitas (Connolly dan Begg, 2015:436). b. Generalization, adalah proses meminimalkan perbedaan antara entitas dengan mengidentifikasi karakteristik yang sama dari masing-masing entitas (Connolly dan Begg, 2015:437). c. Aggregation, adalah mempresentasikan hubungan ‘has-a’ atau ‘ispart-of’ antara tipe-tipe entitas, dimana salah satu adalah sebagai ‘whole’ dan yang lainnya sebagai ‘part’ (Connolly dan Begg, 2015:445).
12 d. Composition, adalah sebuah bentuk spesifik dari aggregration yang mempresentasikan penggabungan antara entitas dimana ada kepemilikan yang kuat dan kesamaan lifetime antara ‘whole’ dan ‘part’ (Connolly dan Begg, 2015:446).
Langkah 1.7 Memeriksa model akan adanya redundansi Memeriksa keberadaan redudansi dalam model. Dilakukan pemeriksaan secara spesifik terhadap hubungan one-to-one (1:1),
menghilangkan
hubungan (relationship) yang redundan, dan mempertimbangkan penggunaan dimensi waktu. Langkah 1.8 Validasi model konseptual terhadap transaksi pengguna Memastikan bahwa konseptual data telah mendukung transaksi yang dibutuhkan. Dapat dilakukan dengan dua cara yaitu : a. Mendeskripsikan transaksi secara detail, dengan pendekatan ini berarti akan diperiksa semua informasi (entitas, hubungan, dan atribut) yang dibutuhkan oleh setiap transaksi apakah telah disediakan dalam model, dengan mendokumentasikan setiap kebutuhan transaksi. b. Menggunakan jalur transaksi (transaction pathways), pendekatan ini untuk validasi model data terhadap transaksi yang dibutuhkan termasuk representasi diagram jalur yang digunakan oleh setiap transaksi langsung pada diagram ER. Langkah 1.9 Review model data konseptual dengan pengguna Memeriksa ulang model data konseptual dengan pengguna sistem untuk memastikan bahwa mereka mempertimbangkan model data tersebut secara tepat menggambarkan kebutuhan data perusahaan.
2.5.2
Perancangan Logikal Perancangan logikal merupakan proses membangun model data konseptual menjadi model data logikal dengan memvalidasi model tersebut untuk memeriksa struktur yang benar dan dapat mendukung kebutuhan transaksi. (Connolly dan Begg, 2015:528).
13 Langkah-langkah dalam membangun dan memvalidasikan model data logikal yaitu (Connolly dan Begg, 2015:530-556) : Langkah 2 Membangun Data Model Logika Langkah 2.1 Menurunkan Relasi Untuk Model Data Logika Membuat relasi dari model data konseptual untuk mempresentasikan entitas, hubungan, dan atribut-atribut yang telah teridentifikasi.
(1) Strong entity types Membuat relasi yang menyertakan semua atribut sederhana tiap entitas. (2) Weak entity types Membuat relasi yang menyertakan semua atribut sederhana untuk tiap entitas
yang lemah. Primary key entitas lemah
diturunkan sebagian atau seluruhnya dari tiap entitas pemilik dan primary key dari entitas lemah tidak dapat ditentukan sampai seluruh hubungan dengan entitas pemilik dipetakan. (3) One-to-many (1:*) binary relationship type Pada setiap 1:* binary relationship, entitas “one side” pada suatu hubungan ditentukan sebagai entitas induk dan entitas “many side” ditentukan sebagai entitas anak. Untuk mewakili hubungan ini, diperlukan membuat salinan dari primary key pada entitas induk ke dalam entitas anak, untuk bertindak sebagai foreign key. (4) One-to-one (1:1) binary relationship types Membuat relasi untuk merepresentasi suatu hubungan 1:1 sedikit lebih rumit, sebagaimana cardinality tidak dapat digunakan untuk membantu mengidentifikasi entitas induk dan entitas anak dalam suatu hubungan. (5) One-to-one (1:1) recursive relationships Mengikuti aturan pada hubungan 1:1 sebelumnya. Namun dalam kasus tertentu, entitas untuk kedua sisi dalam suatu hubungan adalah sama, dimana kedua entitas tersebut merupakan primary key.
14 (6) Superclass/subclass relationship types Untuk setiap superclass/subclass relationship dalam model data konseptual, diidentifikasi entitas superclass sebagai parent dan entitas subclass sebagai child. (7) Many-to-many (*:*) binary relationship types Untuk setiap hubungan many-to-many binary relationship, buat sebuah
relasi
untuk
merepresentasikan
hubungan
dan
masukkan setiap atribut yang merupakan bagian dari hubungan tersebut. Satu atau kedua foreign key dari hubungan tersebut akan menghasilkan suatu primary key. (8) Complex relationship types Setiap foreign key yang merepresentasi suatu hubungan “many” secara umum akan menghasilkan primary key dalam hubungan tersebut. (9) Multi-valued attributes Selain atribut yang memiliki banyak nilai, adalah suatu alternate
key,
primary
key
dalam
hubungan
tersebut
merupakan kombinasi dari atribute yang memiliki banyak nilai dan merupakan primary key. Langkah 2.2 Validasi relasi menggunakan normalisasi Memvalidasi relasi-relasi dalam model data logika menggunakan normalisasi. Langkah 2.3 Validasi relasi terhadap transaksi pengguna Memastikan relasi-relasi pada model data logika mendukung kebutuhan transaksi. Langkah 2.4 Memeriksa keutuhan batasan Memeriksa apakah keutuhan batasan telah direpresentasikan dalam model data logika. Langkah 2.5 Meninjau ulang model data logika dengan pengguna Memeriksa kembali model data logika terhadap pengguna untuk memastikan bahwa mereka mempertimbangkan model data tersebut secara tepat menggambarkan kebutuhan data perusahaan.
15 Langkah 2.6 Menggabungkan model data logika ke dalam model global (langkah opsional) Menggabungkan model data logika lokal ke dalam suatu model data logika global yang menggambarkan seluruh pandangan pengguna terhadap basis data. Langkah 2.6.1 Menggabungkan data model logika lokal ke dalam model data logika global Langkah 2.6.2 Validasi model data logika global Langkah 2.6.3 Meninjau ulang model data logika global terhadap pengguna
Langkah 2.7 Memeriksa pertumbuhan di masa depan Menentukan apakah akan terdapat suatu perubahan yang berarti di masa mendatang dan menilai apakah model data logika dapat mengakomodasi perubahan tersebut.
2.5.3 Perancangan Fisikal Langkah 3 Menterjemahkan model data logika untuk target DBMS Menghasilkan skema basis data relational dari model data logika yang dapat diimplementasikan ke dalam target DBMS. Langkah 3.1 Merancang hubungan dasar Menentukan
bagaimana
merepresentasi
hubungan
dasar yang
diidentifikasi dalam model data logika ke dalam target DBMS. Langkah 3.2 Merancang representasi dari derived data Menentukan bagaimana tiap derived data pada model data logika ke dalam target DBMS. Langkah 3.3 Merancang batasan umum Merancang batasan-batasan umum untuk target DBMS. Langkah 3.4 Merancang organisasi file dan indeks Menentukan organisasi file yang optimal untuk menyimpan hubungan dasar dan indeks yang dibutuhkan untuk mencapai perfoma yang cocok, dengan kata lain, cara dimana relasi dan tuple akan disimpan dalam tempat penyimpanan sekunder. Langkah 4 Merancang organisasi file dan indeks
16 Langkah 4.1 Analisa transaksi Memahami fungsi dari transaksi yang akan berjalan pada basis data dan menganalisa transaksi yang penting. Langkah 4.2 Memilih organisasi file Menentukan organisasi file yang efisien untuk setiap relasi dasar. Langkah 4.3 Memilih indeks Menentukan apakah menambahkan indeks akan meningkatkan kinerja sistem. Langkah
4.4
Memperkirakan
ruang
penyimpanan
yang
dibutuhkan Memperkirakan besarnya jumlah ruang penyimpanan yang dibutuhkan yang akan diperlukan basis data. Langkah 5 Merancang user views Merancang user view yang teridentifikasi selama tahap pengumpulan dan analisa kebutuhan dari siklus pengembangan sistem basis data. Langkah 6 Merancang mekanisme keamanan Merancang mekanisme keamanan untuk basis data yang ditentukan oleh pengguna selama tahap pengumpulan kebutuhan dari siklus pengembangan sistem basis data.
2.6 Data Flow Diagram (DFD) Diagram alir data (DFD) adalah perangkat yang menggambarkan aliran data yang melalui sebuah sistem dan pekerjaan atau prosesnya ditampilkan oleh sistem. (Whitten & Bentley, 2015, hal. 325). − Persegi panjang bulat menampilkan proses yang harus dilaksanakan. − Persegi menampilkan external agents yang berarti merupakan batasan dari sistem yang akan dibuat. External agents adalah orang atau badan atau organisasi yang berada di luar scope proyek namun yang berinteraksi langsung dengan sistem. − Kotak tanpa tutup menampilkan data stores biasa disebut dengan file atau basis data (database).
17 − Panah menampilkan aliran data, input dan output dari dan ke proses. Catatan penulis : Terdapat beberapa kumpulan simbol untuk DFD. Namun untuk peracangan aplikasi basis data ini, penulis menggunakan simbol dari Gane dan Sarson karena buku panduan yang digunakan menggunakan simbol ini.
Diagram alir data memiliki tahapan perancangan alur yaitu ; 1. Diagram Konteks 2. Diagram Nol 2.7 Entity Relationship Diagram (ERD) Entity relationship diagram (ERD) adalah diagram yang membahas mengenai permasalahan dan menampilkan semua obyek data yang dimasukkan, disimpan, ditranformasi, dan dihasilkan dari sebuah aplikasi. (Pressman R. , 2010, hal. 172).
2.8
Teori yang Terkait Pembelian dan Penjualan Pembelian dan penjualan adalah hal pokok yang dibahas pada skripsi ini, oleh karena itu harus pula diberikan penjelasan yang cukup untuk memberikan gambaran yang cukup mendefinisikan mengenai penjualan dan pembelian. Berikut ini adalah penjelasan dari dua jenis sistem yaitu sistem penjualan dan pembelian ; 2.8.1 Sistem Pembelian Sistem pembelian digunakan dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Fungsi yang terkait dalam sistem pembelian adalah: 1. Fungsi pembelian Bertanggung jawab untuk memperoleh informasi mengenaiharga barang, kualitas, menentukan pemasok yang dipilih dalam pengadaan barang, mengeluarkan order pembelian kepada pemasok yang dipilih. 2. Fungsi penerimaan
18 Bertanggung jawab untuk melakukan pemeriksaan terhadap jenis, jumlah, mutu dan kuantitas barang yang diterima dari pemasok guna menentukan apakah barang tersebut layak untuk dijual dan dikirim kepada konsumen. Barang yang sudah diterima dari pemasok adakalanya tidak sesuai dengan barang yang dipesan melalui surat order pembelian. Ketidaksesuaian tersebut terjadi kemungkinan karena barang yang diterima tidak cocok dengan spesifikasi yang tercantum dalam surat order pembelian, barang mengalami kerusakan dalam pengiriman, atau jumlah barang tidak sesuai dengan surat order pembelian. Sistem retur pembelian digunakan dalam perusahaan untuk pengembalian barang yang sudah dibeli kepada pemasok. 2.8.2
Sistem Penjualan Kegiatan penjualan terdiri dari transaksi penjualan barang atau jasa, baik secara kredit maupun secara tunai. Proses penjualan dimulai dari departemen penjualan yang menerima pesanan pelanggan yang menunjukan jenis dan jumlah barang yang diminta. Penjualan
tunai
dilaksanakan
oleh
perusahaan
dengan
cara
mewajibkan pembeli melakukan pembayaran harga barang baik uang muka atau langsung lunas lebih dahulu sebelum barang diserahkan oleh perusahaan kepada pembeli. Fungsi yang terkait dalam system penjualan adalah: 1. Fungsi penjualan Bertanggung jawab untuk menerima order dari pembeli dan membuat surat kontrak kepada pembeli untuk menentukan harga jual yang diberikan kepada konsumen 2. Fungsi kas Bertanggun jawab sebagai penerima kas dari pembeli dan memberikan kuitansi kepada konsomen ketika konsumen melakukan pembayaran 3. Fungsi gudang
19 Bertanggung jawab untuk menyesuaikan barang yang dipesan oleh pembeli,
serta
menyerahkan
barang
tersebut
ke
fungsi
pengiriman 4. Fungsi pengiriman Bertanggung jawab untuk membungkus barang dan menyerahkan barang yang dipesan oleh konsumen kepada konsumen itu sendiri. 5. Fungsi akuntansi Bertanggung jawab sebagai pencatat transaksi penjualan dan penerimaan kas dan membuat laporan penjualan. Faktur penjualan adalah dokumen yang digunakan untuk merekam berbagai informasi yang diperlukan oleh manajemen mengenai transaksi penjualan. Menurut Hall (2007,p235), retur penjualan bisa disebabkan oleh beberapa hal sebagai berikut : 1. Penjual mengirimkan barang yang salah. 2. Barang yang dikirim ternyata rusak/cacat. 3. Barang tersebut rusak pada saat pengiriman. 4. Penjual terlalu terlambat mengirimkan barang atau terjadi keterlambatan karena penundaan saat perjalanan, dan pembeli menolak pengiriman tersebut.
2.9 Rich Picture Rich picture merupakan pandangan skematis mengenai permasalahan yang akan diselesaikan dalam proyek. Rich picture memperlihatkan komponen utama dari permasalahan, termasuk di dalamnya berbagai interaksi yang mungkin terjadi. (Irwansyah, 2013, hal. 148) 2.10
Hasil Penelitian dan Produk Sebelumnya Penelitian pertama yang dilakukan diambil dari jurnal “Analisis dan
Perancangan Sistem Basisdata Penjualan dan Pembelian Berbasis Web pada PT. Casuarina Harnessindo” yang disusun pada tahun 2014 oleh mahasiswa Binus University.
Surjadi, Zebua, dan Irawan (2014) dalam jurnal ini
membatasi ruang lingkup dalam pembahasannya, yaitu :
20 1. Guest dapat melihat produk dan melakukan pendaftaran. 2. Pelanggan dapat melihat dan memesan produk. 3. Staff dapat memasukan data penjualan dan pembelian. 4. Admin dapat melihat data pelanggan, data pembelian dan penjualan. Dari hasil penelitian, kami mendapatkan beberapa ide yaitu memperbaiki beberapa hal-hal yang dibutuhkan oleh CV. Benua Baja Abadi. Hal-hal yang diperbaiki adalah perusahaan membutuhkan aplikasi yang membantu staff dalam proses penjualan dan pembelian yang lebih efisien dan menghindari human error. Penulis memberikan usulan dengan membuatkan sistem basis data berbasis web agar admin dapat lebih mudah dalam proses pengerjaan sehari-hari dan tidak perlu menulis hal yang sama berkali kali seperti keterangan produk, alamat, dan sebagainya sehingga hal ini dapat menghindari dari kesalahan penulisan maka dari itu dalam aplikasi yang kami buat membuat admin hanya perlu menulis satu kali data master yang akan digunakan untuk proses penjualan dan pembelian dan dalam semua proses penjualan pembelian admin hanya perlu mengklik jenis data seperti nama atau kode yang dibutuhkan dan aplikasi akan langsung memunculkan semua keterangan tambahan dari nama atau kode tersebut.
