1 BAB 2 TINJAUAN PUSTAKA 2.1 Teori-Teori

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.