LAPORAN PERKEMBANGAN

APLIKASI MINIMARKET ‘ASHYLA MART’ BERBASIS WEB

Diajukan untuk memenuhi

tugas besar mata kuliah Perancangan Basis Data

Oleh:
Kelompok 6
1. Latifatuzikra Suhairi 1911522005
2. Intan Yuliana Putri 1911522007
3. Miftah Mussaumi A 1911522009
4. Annisa Putri 1911522011

Dosen Pengampu:
Prof. Ir. Surya Afnarius, M.Sc. Ph.D
196404091995121001

JURUSAN SISTEM INFORMASI

FAKULTAS TEKNOLOGI INFORMASI
UNIVERSITAS ANDALAS
2021
 DAFTAR ISI

DAFTAR ISI 2
1. LATAR BELAKANG 3
2. RUMUSAN MASALAH 3
3. PEMBAHASAN 4
A. LAPORAN DATA SUPPLIER DAN DATA PELANGGAN 5
LATAR BELAKANG

Ashyla Mart adalah sebuah minimarket milik individu perorangan yang terletak pada

kawasan Jl. Raya Padang - Bukittinggi, Lubuak Kapalo Hilalang, Kec. 2 X 11

Menanam Kayu, Kabupaten Padang Pariaman, provinsi Sumatera Barat 25584,

Indonesia. Ashyla Mart sebenarnya adalah semacam toko kelontong atau yang

menjual segala macam barang dan makanan serta perlengkapan kebutuhan sehari -

hari, perbedaan nya disini biasa nya minimarket Asyla Mart menerapkan sebuah

sistem mesin kasir point of sale untuk penjualan nya, namun tidak selengkap dan

sebesar sebuah supermarket. Berbeda dengan toko kelontong, minimarket Ashyla

Mart menerapkan sistem swalayan, dimana pembeli mengambil sendiri barang yang

ia butuhkan dari rak-rak minimarket dan membayarnya di meja mesin kasir. Sistem

ini juga membantu agar pembeli tidak berhutang. Minimarket Ashyla Mart jam

bukanya juga lain dari sebuah supermarket, minimarket Ashyla Mart circle K ini jam

bukanya bisa hingga 24 jam tergantung dari pemilik Ashyla Mart sendiri.

Nah disini pemilik Ashyla Mart membeli software yang telah jadi atau siap

pakai, sehingga tidak semua fungsional software tersebut sesuai kebutuhan yang

menyebabkan penyimpanan data jual belinya diantaranya ada beberapa field yang

tidak diperlukan dan tidak dibutuhkan. Maka dari itu dalam rancangan program ini

diharapkan semua proses transaksi baik itu pembelian dan penjualan serta laporan

data supplier dan pelanggan dimana field-field yang tidak dibutuhkan itu di program

ulang supaya bisa digunakan oleh pemilik minimarket Ashyla Mart. Sehingga proses

transaksi di minimarket Ashyla Mart lebih efesien dan transparan.

RUMUSAN MASALAH

Dari Latar belakang tersebut maka dapat dirumuskan masalah yaitu:

1. Apa saja laporan yang dapat dihasilkan dari kegiatan bisnis yang terjadi di
minimarket “Ashyla Mart”?
2. Apa saja tabel-tabel yang dapat dihasilkan dari laporan tersebut?
3. Bagaimana proses normalisasi tabel dari masing-masing laporan?
4. Bagaimana struktur tabel hasil normalisasi pada masing-masing laporan?
5. Bagaimana relasi antar tabel pada masing-masing laporan?
6. Bagaimana gambaran ERD dari masing-masing laporan?
7. Bagaimana relasi antar tabel-tabel dari masing-masing laporan yang telah
digabungkan?
8. Bagaimana gambaran ERD gabungan dari beberapa laporan tersebut?
LANDASAN TEORI

Normalisasi adalah sebuah teknik yang menghasilkan suatu kumpulan relasi

dengan property yang diinginkan dengan memberikan suatu kebutuhan data pada
perusahaan. Perancangan melalui proses normalisasi mempunyai keuntungan-
keuntungan sebagai berikut :
● Meminimalkan ukuran penyimpanan yang diperlukan untuk penyimpanan data.
● Meminimalkan resiko inkonsistensi data pada basis data.
● Meminimalkan kemungkinan anomaly pembaruan.
● Memaksimalkan stabilitas struktur data.
Dalam melakukan normalisasi terdapat beberapa tahap, yaitu :
1. Bentuk normal pertama (1NF)
Bentuk normal pertama adalah ekivalen dengan definisi model relasional.
Relasi adalah bentuk normal pertama (1NF) jika semua nilai atributnya adalah
sederhana (bukan komposit). Syarat :
● Tidak ada set atribut yang berulang atau bernilai ganda.
● Telah ditentukannya primary key untuk tabel atau relasi.
● Tiap atribut hanya memiliki satu pengertian.
● Tiap atribut yang dapat memiliki banyak nilai sebenarnya menggambarkan
nilai sebenarnya.
2. Bentuk normal kedua (2NF)
Relasi pada bentuk normal kedua harus tidak menyimpan fakta-fakta mengenai
bagian kunci relasi. Bentuk normal kedua menghilangkan ketergantungan
parsial dan masih memiliki anomali-anomali yang secara praktis tidak
Syarat :
● Bentuk data telah memenuhi kriteria bentuk normal ke satu (1NF).
● Atribut bukan kunci (non-key attribute) haruslah memiliki ketergantungan
fungsional sepenuhnya pada primary key.

3. Bentuk normal ketiga (3NF)

 Bentuk normal ketiga menghilangkan kebergantungan transitif, awalnya bentuk
normal ketiga dipikir sebagai bentuk normal puncak/paling akhir. Namun
kemudian dapat ditemukan bentuk normal lebih kuat yaitu bentuk normal
Boyce-Codd.
Syarat :
● Bentuk data telah memenuhi kriteria bentuk normal ke dua (2NF).
● Atribut bukan kunci(non-key attribute) tidak boleh memiliki ketergantungan
fungsional terhadap atribut bukan kunci lainnya. Seluruh atribut bukan
kunci pada suatu relasi hanya memiliki ketergantungan fungsional
terhadap primary key di relasi itu saja.

Dalam perancangan basis data, kita juga akan membuat suatu Entity Diagram
Relationship (ERD) yang merupakan suatu model untuk menjelaskan hubungan antar
data dalam basis data berdasarkan objek-objek dasar data yang mempunyai hubungan
antar relasi. Berikut beberapa fungsi dari ERD :
1. Melakukan pengujian sebuah model yang telah dibuat.
2. Mendokumentasikan data yang terdapat dalam sistem basis data yaitu dengan
menganalisis setiap objek ataupun entitas dan juga relasi atau hubungan yang
dimilikinya.
3. Memberikan kemudahan di dalam menganalisis database dengan cara yang
lebih cepat dan juga murah.

Terdapat beberapa aspek utama dari ERD itu sendiri sebagai berikut :
1. Entity
Entity adalah suatu objek yang dapat diidentifikasikan secara unik atau saling
berbeda.
2. Atribut
Setiap entitas pasti mempunyai elemen yang disebut atribut yang berfungsi untuk
mendeskripsikan karakteristik dari entitas tersebut.
3. Key
 Key adalah sebuah field yang digunakan untuk mengidentifikasikan satu atau
lebih atribut secara unik untuk mengidentifikasi setiap record. Terdapat lima
jenis key yang biasa digunakan, yaitu:
● Candidate Key : Merupakan set atribut minimal yang secara unik
mengidentifikasi setiap kejadian dari sebuah tipe entitas.
● Primary Key : Merupakan candidate key yang dipilih untuk
mengidentifikasikan setiap kejadian dari suatu tipe entitas secara unik.
● Composite Key : Merupakan sebuah candidate key yang terdiri dari dua atau
lebih atribut.
● Foreign Key : Merupakan sebuah atribut pada suatu relasi yang sama dengan
candidate key dari relasi lainya.
● Alternate Key : Merupakan kumpulan sebuah atribut dari candidate key yang
tidak terpilih menjadi primary key.
4. Relasi
Relasi digunakan untuk menghubungkan antar entitas yang memiliki keterkaitan.
Dalam sebuah relasi selalu terjadi proses baru yang tentu menghasilkan sesuatu
yang baru pula.
5. Kardinalitas
Kardinalitas menjelaskan jumlah maksimum hubungan antara satu entitas dengan
entitas lainnya. Kardinalitas relasi yang terjadi antara dua himpunan entitas yang
dapat berupa :
● One to one: setiap entitas hanya bisa mempunyai relasi dengan satu entitas
lain. Contoh: siswa dengan nomor induk siswa
● One to many: hubungan antara satu entitas dengan beberapa entitas dan
sebaliknya. Contoh: guru dengan murid dan sebaliknya.
● Many to many: setiap entitas bisa mempunyai relasi dengan entitas lain, dan
sebaliknya. Contoh: siswa dan ekstrakurikuler.
PEMBAHASAN
Penulis telah mendapatkan lima laporan utama dari minimarket ‘Ashyla Mart’
yaitu: (1) Laporan data supplier; (2) Laporan pembelian barang; (3) Laporan data
item; (4) Laporan data pelanggan; dan (5) Laporan penjualan barang. Laporan ini
selanjutnya akan menjadi landasan dalam pengembangan aplikasi berbasis web yang
berguna untuk menyimpan seluruh data minimarket Ashyla di sebuah basis data yang
sesuai dengan kebutuhan minimarket.
Setelah laporan dikumpulkan, pengembangan aplikasi dimulai dengan
merancang basis data. Basis data merupakan sekumpulan tabel-tabel yang berisi data
dan merupakan kumpulan dari field atau kolom. Tahap awal perancangan basis data
diawali dengan melakukan normalisasi data untuk mengurangi redudansi data yang
mungkin terjadi di laporan. Setelah dilakukan normalisasi data, masing-masing field
laporan ditentukanlah nama field, tipe data, panjang, dan sifatnya yang kemudian
akan diterjemahkan dalam bentuk Entity Relationship Diagram. Berikut penjelasan
ERD dari masing-masing laporan yang telah disebutkan di atas.
A. LAPORAN DATA SUPPLIER
Laporan data supplier menampilkan informasi mengenai supplier yang
menjadi pemasok barang-barang yang dijual di Ashyla Mart. Berikut laporan data
supplier yang telah penulis dapatkan.
Dari laporan di atas, dapat dilihat bahwa terdapat beberapa field, yaitu kode
supplier, nama supplier, alamat supplier, kota supplier, provinsi supplier, dan
telepon supplier. Masing-masing field ini akan dibuat ke dalam sebuah tabel
basis data tanpa perlu melakukan normalisasi data terlebih dahulu. Hal ini
dikarenakan tidak ada field yang memiliki multi data pada satu record satu field
yang sama dan tidak terdapat dependensi fungsional serta dependensi transitif
pada data.
Sesuai dengan isi dari masing-masing field pada laporan, dapat dibuatkan
struktur tabel basis data dengan nama tabel ‘supplier’ sebagai berikut.

Nama_field Tipe Data Length Sifat

kode_supp varchar 6 Primary Key,
Unique, Not Null
nama_supp varchar 20 Not Null
alamat varchar 50 Not Null
kota varchar 20 Not Null
provinsi varchar 20
telepon varchar 13 Unique
 Jika tabel ‘supplier’ digambarkan ke dalam rancangan ERD, maka akan menjadi
seperti berikut.

Field ‘kode_supp’ merupakan primary key dari tabel ‘supplier’ karena setiap
supplier memiliki kode unik yang menunjukkan identitas masing-masing
supplier. Tabel ‘supplier’ ini nantinya akan berelasi dengan tabel ‘pembelian’
dari laporan pembelian item.

B. LAPORAN DATA PELANGGAN

Laporan data pelanggan menampilkan informasi daftar pelanggan yang
melakukan transaksi pembelian item yang di jual di Ashyla Mart. Berikut laporan
data supplier yang telah penulis dapatkan.

Dari laporan di atas, dapat dilihat bahwa terdapat beberapa field, yaitu kode
pelanggan, nama pelanggan, alamat pelanggan, kota pelanggan, provinsi
pelanggan, dan telepon pelanggan. Masing-masing field ini akan dibuat ke dalam
sebuah tabel basis data tanpa perlu melakukan normalisasi data terlebih dahulu.
 Hal ini dikarenakan tidak ada field yang memiliki multi data pada satu record
satu field yang sama dan tidak terdapat dependensi fungsional serta dependensi
transitif pada data.
Sesuai dengan isi dari masing-masing field pada laporan, dapat dibuatkan
struktur tabel basis data dengan nama tabel ‘pelanggan’ sebagai berikut.
Nama_field Tipe Data Length Sifat
kode_pel varchar 7 Primary Key,
Unique, Not Null
nama_pel varchar 20 Not Null
alamat varchar 50 Null
kota varchar 20 Null
provinsi varchar 15 Null
telepon varchar 13 Unique
Jika tabel ‘supplier’ digambarkan ke dalam rancangan ERD, maka akan menjadi
seperti berikut.

Field ‘kode_pel’ merupakan primary key dari tabel ‘pelanggan’ karena setiap
pelanggan akan memiliki kode unik yang menunjukkan identitas masing-masing
pelanggan. Tabel ‘pelanggan’ ini nantinya akan berelasi dengan tabel ‘penjualan’
dari laporan penjualan item.
C. LAPORAN PEMBELIAN ITEM
Laporan data barang merupakan laporan yang berisi tentang data
pembelian item/barang yang dilakukan minimarket Ashyla Mart. Berikut
bentuk laporan dari data item yang telah penulis dapatkan.
Dari laporan diatas terdapat beberapa field yaitu nomor transaksi,departemen,
tanggal, kode supplier, nama supplier, kode item, nama item, jumlah, satuan,
harga, potongan, total, total potongan, pajak, biaya dan total akhir. Terlihat
bahwa dalam satu nomor transaksi terdapat banyak barang yang dapat dibeli,
sehingga diperlukan normalisasi untuk memudahkan penggunaan database.
Berikut adalah tahapan normalisasinya:
1. Bentuk normal tahap 1(1NF)
Tabel diatas belum memenuhi bentuk normal karena dalam satu nomor
transaksi yang merupakan primary key terdapat banyak barang yang dibeli.
misalnya pada nomor transaksi ‘0001/BL/UTM/0221’ terdapat 10 item yang
dibeli. Untuk itu setiap kode item atau setiap baris data harus memiliki
masing-masing nomor transaksi.
2. Bentuk normal tahap 2(2NF)
Normalisasi tahap 2 bertujuan untuk menghilangkan ketergantungan
fungsional antar entitas dari satu tabel. untuk itu, dari hasil normalisasi tahap
1, tabel akan dibagi menjadi beberapa tabel berdasarkan jenis entitasnya,
yaitu:
 a. tabel pembelian, dengan field nomor transaksi(primary key), tanggal,
kode departemen(foreign key), kode supplier(foreign key), kode
item(foreign key), jumlah, satuan, potongan, total, pajak. biaya, dan
total akhir. Field total potongan dihilangkan karena nilai total
merupakan hasil perkalian harga item dengan jumlah dikurangi dengan
potongan pada masing-masing item.
b. tabel departemen, karena pada laporan hanya ada field departemen,
penulis menjadikannya sebuah tabel dengan field kode
departemen(primary key) dan nama departemen.
c. tabel supplier, dengan field kode supplier(primary key) dan nama
supplier.
d. tabel item, dengan field kode item(primary key), nama item, dan
harga.
3. Bentuk normal tahap 3(3NF)
Normalisasi tahap 3 bertujuan untuk menghilangkan ketergantungan transitif
antar field dalam sebuah tabel. Dari hasil tahap 2, terdapat perulangan data
pada nomor transaksi, dimana satu nomor transaksi berada di beberapa baris
data. seperti nomor transaksi ‘0001/BL/UTM/0221’ berada di 10 baris data
karena dalam satu kali pembelian dibeli 10 jenis item. untuk itu tabel
pembelian dapat dipecah menjadi 2 tabel dengan menambahkan tabel detail
pembelian. jadi terdapat 5 tabel yaitu:
a. tabel pembelian, dengan field nomor transaksi(primary key),kode
departemen(foreign key), kode supplier(foreign key), tanggal, pajak.
biaya, dan total akhir.
b. tabel detail pembelian, dengan field nomor transaksi(primary key dan
foreign key), kode item(primary key dan foreign key), jumlah, satuan,
potongan, total
c. tabel departemen, dengan field kode departemen(primary key) dan
nama departemen.
 d. tabel supplier, dengan field kode supplier(primary key) dan nama
supplier.
e. tabel item, dengan field kode item(primary key), nama item, dan
harga.
Berdasarkan hasil normalisasi, dapat dibuatkan struktur tabel sebagai
berikut:
f. Tabel pembelian
Nama_field Tipe Data Length Sifat
no_transaksi varchar 15 Primary Key,
Unique, Not Null
kode_dept varchar 10 Foreign Key, Not
Null
kode_supp Varchar 10 Foreign Key, Not
Null
tanggal Date Not Null
total_item Integer Not Null
biaya Integer Not Null
pajak Integer Not Null
total_bayar Integer Not Null
(sama dengan
total akhir)

g. Tabel detail pembelian

Nama_field Tipe Data Length Sifat
no_transaksi varchar 15 Primary Key,
Foreign key, Unique,
Not Null
kode_item varchar 10 Primary Key,
Foreign key, Unique,
Not Null
jumlah Integer Not Null
satuan Varchar 10 Not Null
potongan Integer Not Null
sub_total Integer Not Null
 (sama dengan
total)

h. Tabel departemen
Nama_field Tipe Data Length Sifat
kode_dept varchar 10 Primary Key,
Unique, Not Null
nama_dept varchar 20 Not Null

i. Tabel supplier
Nama_field Tipe Data Length Sifat
kode_supp varchar 10 Primary Key,
Unique, Not Null
nama_supp varchar 20 Not Null

j. Tabel item
Nama_field Tipe Data Length Sifat
kode_item varchar 10 Primary Key,
Unique, Not Null
nama_item varchar 30 Not Null
harga Integer Not Null

Untuk menghubungkan antar tabel, digunakan relasi, dimana relasi antar tabel
yang terjadi antar tabel adalah sebagai berikut:
1. Tabel departemen-pembelian
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu
departemen dapat terlibat dalam nol atau banyak pembelian.
2. Tabel supplier-pembelian
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu
supplier dapat terlibat dalam nol atau banyak pembelian.
3. Tabel pembelian-detail pembelian
 Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu kali
pembelian dapat memiliki nol atau banyak detail pembelian, tergantung
pada jumlah barang yang dibeli dalam satu kali pembelian.
4. Tabel item-detail pembelian
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu item
dapat tidak dibeli ataupun sering dibeli, sehingga memiliki banyak detail
pembelian.
Jika digambarkan dalam sebuah ERD, maka tampilannya adalah sebagai
berikut:

C. LAPORAN DATA ITEM

Laporan data barang merupakan laporan yang berisi tentang data
item/barang yang tersedia di minimarket Ashyla Mart. Berikut bentuk laporan
dari data item yang telah penulis dapatkan.
Pada laporan diatas, dapat kita lihat bahwa pada laporan tersebut terdapat
beberapa field yaitu kode item, nama item, jenis item, stok, satuan, harga
pokok, dan harga harga jual. Dapat dilihat bahwa pada laporan di atas terdapat
beberapa atribut/field yang berulang atau memiliki nilai ganda. Maka untuk
mengatasi hal tersebut, penulis harus melakukan normalisasi data.
Berikut tahap normalisasinya:
1. Bentuk normal tahap 1 (1NF)
Pada tabel diatas pada laporan data item sudah memenuhi bentuk normal
tahap 1 (1NF) dimana field ‘kode_item’ sebagai primary key. Namun, dari
data tersebut masih terdapat masalah yang muncul yaitu masih adanya
duplikasi data dan inconsistency.

Tabel ? Hasil bentuk 1NF

2. Bentuk normal tahap 2 (2NF)
Tahap 2NF dapat dilakukan jika hanya tahap 1NF telah terpenuhi. Tabel tahap
1NF perlu didekomposisi lagi agar memenuhi tahap 2NF. Dekomposisi sesuai
functional Dependency (FD) adalah sebagai berikut :
● functional dependecy 1 (kode_item, nama_item,

stok,satuan,harga_pokok,harga_jual) → Tabel item

● functional dependency 2 (kode_jenis, nama_jenis) → Tabel jenis_item

Sesuai dengan isi dari masing-masing field pada laporan, dapat dibuatkan
struktur tabel basis data sebagai berikut.:

1) Tabel data item

Nama_field Tipe Data Length Sifat
kode_item varchar 10 Primary Key,
Unique, Not Null
nama_item varchar 30 Not Null
id_jenis varchar 10 Foreign key
references Table
jenis_item
stok integer Null
satuan varchar 10 Not Null
harga_beli integer Not Null
harga_jual integer Not Null

2) Tabel jenis item

Nama_field Tipe Data Length Sifat
id_jenis varchar 10 Primary Key,
Unique, Not Null
nama_jenis varchar 15 Not Null

Sesuai dengan isi dari masing-masing field pada tabel diatas, dapat
dibuatkan struktur tabel basis data sebagai berikut.:
 Dari relasi diatas kita dapat melihat bahwa field ‘id_jenis’ merupakan primary
key pada tabel jenis_item dan menjadi foreign key pada tabel item sehingga
kedua tabel tersebut dapat dibuatkan sebuah relasi. Relasi yang didapat antara
tabel jenis_item dengan tabel item yaitu one to many yang artinya dari satu
jenis item dapat memiliki banyak macam item.

D. LAPORAN PENJUALAN ITEM

Laporan penjualan item merupakan laporan yang berisi tentang data

penjualan item/barang yang dilakukan minimarket Ashyla Mart. Berikut
bentuk laporan dari penjualan data item yang telah penulis dapat kan.
Dari laporan diatas terdapat beberapa field yaitu nomor transaksi,departemen,
tanggal, kode pelanggan, nama pelanggan, alamat, kode item, nama item,
jumlah, satuan, harga, potongan, total, total potongan, pajak, biaya dan total
akhir. Terlihat bahwa dalam satu nomor transaksi terdapat banyak barang yang
dapat dijual, sehingga diperlukan normalisasi untuk memudahkan penggunaan
database.

Berikut adalah tahapan normalisasinya:

1. Bentuk normal tahap 1(1NF)
Tabel diatas belum memenuhi bentuk normal karena dalam satu nomor
transaksi yang merupakan primary key terdapat banyak barang yang dibeli.
misalnya pada nomor transaksi ‘0003836/KSR/UTM/0’ terdapat 5 item
yang dijual. Untuk itu setiap kode item atau setiap baris data harus memiliki
masing-masing nomor transaksi.
2. Bentuk normal tahap 2(2NF)
Normalisasi tahap 2 bertujuan untuk menghilangkan ketergantungan
fungsional antar entitas dari satu tabel. untuk itu, dari hasil normalisasi tahap
1, tabel akan dibagi menjadi beberapa tabel berdasarkan jenis entitasnya,
yaitu:
a. tabel penjualan, dengan field nomor transaksi(primary key),
tanggal, kode departemen(foreign key), kode pelanggan(foreign
key), kode item(foreign key), jumlah, satuan, potongan, total,
pajak. biaya, dan total akhir. Field total potongan dihilangkan
karena nilai total merupakan hasil perkalian harga item dengan
jumlah dikurangi dengan potongan pada masing-masing item.
b. tabel departemen, karena pada laporan hanya ada field departemen,
penulis menjadikannya sebuah tabel dengan field kode
departemen(primary key) dan nama departemen.
 c. tabel pelanggan, dengan field kode pelanggan (primary key) dan
nama pelanggan.
d. tabel item, dengan field kode item(primary key), nama item, dan
harga.
3. Bentuk normal tahap 3(3NF)
Normalisasi tahap 3 bertujuan untuk menghilangkan ketergantungan transitif
antar field dalam sebuah tabel. Dari hasil tahap 2, terdapat perulangan data
pada nomor transaksi, dimana satu nomor transaksi berada di beberapa baris
data. seperti nomor transaksi ‘0003836/KSR/UTM/0’ berada di 5 baris data
karena dalam satu kali penjualan dijual 5 jenis item. untuk itu tabel
penjualan dapat dipecah menjadi 2 tabel dengan menambahkan tabel detail
penjualan. jadi terdapat 5 tabel yaitu:
a. tabel penjualan, dengan field nomor transaksi(primary key),kode
departemen(foreign key), kode pelanggan (foreign key), tanggal,
pajak. biaya, dan total akhir.
b. tabel detail penjualan, dengan field nomor transaksi(primary key
dan foreign key), kode item(primary key dan foreign key), jumlah,
satuan, potongan, total
c. tabel departemen, dengan field kode departemen(primary key) dan
nama departemen.
d. tabel pelanggan, dengan field kode pelanggan(primary key) dan
nama pelanggan.
e. tabel item, dengan field kode item(primary key), nama item, dan
harga.

Berdasarkan hasil normalisasi, dapat dibuatkan struktur tabel sebagai

berikut:
1. Tabel penjualan
Nama_field Tipe Data Length Sifat
no_transaksi varchar 15 Primary Key,
 Unique, Not Null
kode_dept varchar 10 Foreign Key, Not
Null
kode_pel Varchar 10 Foreign Key, Not
Null
tanggal_jual Date Not Null
total_item Integer Not Null
biaya Integer Not Null
pajak Integer Not Null
total_penjualan Integer Not Null
( total akhir)
biaya_lain Integer Not Null

2. Tabel detail penjualan

Nama_field Tipe Data Length Sifat
no_transaksi varchar 15 Primary Key,
Foreign key, Unique,
Not Null
kode_item varchar 10 Primary Key,
Foreign key, Unique,
Not Null
jumlah_jual Integer Not Null
satuan Varchar 10 Not Null
diskon Integer Not Null
sub_total Integer Not Null
( (total)

3. Tabel departemen
Nama_field Tipe Data Length Sifat
kode_dept varchar 10 Primary Key,
Unique, Not Null
nama_dept varchar 20 Not Null

4. Tabel pelanggan
Nama_field Tipe Data Length Sifat
kode_pel varchar 10 Primary Key,
 Unique, Not Null
nama_pel varchar 20 Not Null
alamat_pel varchar 50 Not Null
no_handphone varchar 12 Not Null

5. Tabel item
Nama_field Tipe Data Length Sifat
kode_item varchar 10 Primary Key,
Unique, Not Null
nama_item varchar 30 Not Null
harga Integer Not Null

Untuk menghubungkan antar tabel, digunakan relasi, dimana relasi antar tabel
yang terjadi antar tabel adalah sebagai berikut:
1. Tabel departemen-penjualan
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu
baris data pada tabel departemen dapat terhubung sebanyak nol atau
banyak baris pada tabel penjualan.
2. Tabel pelanggan-penjualan
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu
baris data pada tabel pelanggan dapat terhubung sebanyak nol atau banyak
baris pada tabel penjualan.
3. Tabel penjualan-detail penjualan
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu
baris data pada tabel penjualan dapat terhubung sebanyak nol atau banyak
baris pada tabel detail penjualan.
4. Tabel item-detail penjualan
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu
baris data pada tabel item dapat terhubung sebanyak nol atau banyak baris
pada tabel detail penjualan.
 Jika digambarkan dalam sebuah ERD, maka tampilannya adalah sebagai
berikut:

E. LAPORAN GABUNGAN ERD

Berdasarkan hasil analisis terhadap masing-masing laporan di atas, selanjutnya penulis
menggabungkan seluruh rancangan ERD tiap laporan membentuk sebuah sistem yang
menunjukkan adanya relasi dari masing-masing tabel. Rancangan ERD gabungan tersebut
dapat digambarkan sebagai berikut.
Pada gambar di atas dapat dilihat bahwa satu tabel telah berelasi dengan tabel
lainnya. Jenis relasi yang terjadi antar tabel akan dijelaskan sebagai berikut.
1) Relasi tabel supplier - tabel pembelian
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu baris
data pada tabel supplier dapat terhubung sebanyak nol atau banyak baris data
pada tabel pembelian. Artinya, satu supplier dapat melakukan banyak
pembelian (dapat menyetok beberapa pembelian dari minimarket Ashyla yang
terjadi) atau tidak melakukan pembelian pada supplier tersebut.
2) Relasi tabel pembelian - tabel detail_pembelian
Jenis relasi yang terjadi adalah one to one or many, karena setiap satu data
pembelian minimal memiliki satu hubungan ke tabel detail_pembelian atau
memiliki banyak hubungan ke tabel detail_pembelian, dan sebaliknya.
3) Relasi tabel item - tabel detail_pembelian
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu data
item bisa saja tidak memiliki hubungan ke tabel detail_pembelian atau
memiliki banyak hubungan ke tabel detail_pembelian, dan sebaliknya.
4) Relasi tabel jenis_item - tabel item
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu data
jenis item bisa saja tidak memiliki hubungan ke tabel item atau memiliki
banyak hubungan ke item, dan sebaliknya.
 5) Relasi tabel item - tabel detail_penjualan
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu data
item bisa saja tidak memiliki hubungan ke tabel detail_penjualan atau memiliki
banyak hubungan ke tabel detail_penjualan, dan sebaliknya.
6) Relasi tabel penjualan - tabel detail penjualan
Jenis relasi yang terjadi adalah one to one or many, karena setiap satu data
penjualan minimal memiliki satu hubungan ke tabel detail_penjualan atau
memiliki banyak hubungan ke tabel detail_penjualan, dan sebaliknya.
7) Relasi tabel pelanggan - tabel penjualan
Jenis relasi yang terjadi adalah one to zero or many, karena setiap satu data
pelanggan bisa saja tidak memiliki hubungan ke tabel penjualan atau memiliki
banyak hubungan ke tabel penjualan, dan sebaliknya.
Terdapat dua perubahan yang dilakukan penulis saat melakukan penggabungan ERD,
yaitu:
1) Menghapus tabel departemen dari laporan pembelian
Tabel departemen menyajikan informasi departemen atau cabang mana yang
melakukan pembelian item pada supplier, sedangkan Ashyla Mart hanya
memiliki satu toko atau belum memiliki cabang. Dengan demikian, untuk
menghilangkan ketidakefisienan, penulis memutuskan untuk menghapus tabel
departemen tersebut.
2) Menghapus field ‘satuan’ dari tabel detail_pembelian
Penghapusan ini dilakukan karena atribut satuan dari item yang dibeli bisa
didapatkan dengan menggunakan data dari tabel item, sehingga menghemat
tempat penyimpanan di basis data.