BAB 2 TINJAUAN PUSTAKA

(1)

1 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 yang memungkinkan Database Administrator atau user untuk 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)

(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 yang memungkinkan user untuk menentukan data yang dibutuhkan 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 entitas- entitas 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 entitas- entitas 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/multi- valued 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 ‘is- part-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.