NORMALISASI DATA

Ning Ayu Ciptadewi

Teknik Industri, Universitas Gunadarma
Depok, Jawa Barat
Ning.ayuuu@gmail.com

ABSTRAK: Bogor memiliki banyak warung makan dari yang kecil hingga besar.
Namun, masih banyak kendala yang muncul karena tidak adanya sistem informasi yang
membantu dalam hal pengolahan data penjualan hasil produk pada beberapa warung
makan. Kora ini melakukan pengembangan daerah mereka, dengan melakukan proses
transaksi jual beli seperti dengan warung makan. Warung makan ini mempengaruhi
tingkat penjualan dan pendapatan kota Bogor. Karena itu untuk memudahkan pada proses
pengolahan data diperlukan sebuah aplikasi yang dapat membantu dalam mengolah data
transaksi penjualan suatu produk dengan menggunakan media pemrograman. Untuk itu
dalam mendukung kegiatan transaksi diatas aplikasi yang membutuhkan aplikasi atau
metode pengumpulan data dan proses transaksi input/output yang mudah untuk
pengguna. Penelitian ini bertujuan untuk merancang system basis data usaha kecil dan
menengah (UKM) Warung Nasi Bu Wiwit. Data dan informasi yang digunakan sebagai
dasar perancangan berupa data primer yaitu hasil wawancara mendalam (deep interview),
observasi, dan dokumentasi. Metode pengembangan yang digunakan meliputi identifikasi
dan analisis kebutuhan target pengguna, desain konseptual (pengembangan model Entity-
Relationship) dan desain lojik (pengembangan model data relasional).

Kata Kunci: Normalisasi, Bentuk Normal, Database, Redundansi Data, Redundansi

Struktur, Warung Nasi

1. PENDAHULUAN
Sistem informasi merupakan serangkaian prosedur formal dimana data
dikelompokkan, diproses menjadi informasi, dan didistribusikan kepada pemakai. Sistem
informasi erat kaitannya dengan komputer yang menjadi media untuk melakukan proses
pengolahan data yang ada oleh seseorang. Hal tersebut menjadi sudut pandang bahwa
dalam pengolahan data sistem informasi membutuhkan kemampuan komputerisasi yang
baik untuk memudahkan proses input dan output informasi dalam segala bidang terutama
pada kategori usaha. Kemajuan teknologi dalam melakukan pengolahan data dengan
komputerisasi hanya dilakukan oleh beberapa pihak saja dan belum dapat dilakukan oleh
semua orang atau pengusaha yang salah satunya adalah UMKM (Usaha Mikro, Kecil,
dan Menengah). Warung Nasi Ibu Wiwit merupakan salah satu UMKM di bidang pangan
yang masih belum menerapkan sistem informasi dalam pemesanan dengan
komputerisasi. Penerapan sistem informasi pemesanan berbasi komputer akan
memudahkan pelaku usaha dan konsumen dalam melakukan kegiatan pemesanan
makanan yang teratur dan pengolahan input output data terintegrasi.
Membaca dengan teliti buku teks database memperlihatkan ketidaksamaan yang
jelas tentang bagaimana melakukan normalisasi database. Rupanya, ada perbedaan
pendapat tentang apa yang seharusnya dicapai normalisasi. Demikian pula, ada
pernyataan yang bertentangan mengenai bentuk normal (NF) mana yang harus dicapai
oleh desainer database. Jurnal ini mencoba untuk membawa beberapa resolusi untuk
kedua masalah tersebut, untuk meningkatkan pengajaran dan pemahaman tentang
normalisasi database.
Jurnal ini akan meningkatkan pemahaman tentang sifat normalisasi bagi pembaca
sebagai pemahaman tentang topik tersebut. Untuk referensi pembaca, Tabel 1
mencantumkan bentuk normal yang saat ini diketahui. Termasuk di dalamnya adalah
bentuk normal nol (0NF). Tabel bisa dalam bentuk normal nol tetapi, menurut definisi,
relasi tidak bisa.
Berdasarkan penelitian yang dilakukan berikut ini adalah tujuan penelitan yang
menjadi target capaian suatu penelitan, yaitu:
1. Mengetahui pengertian sistem informasi berbasis komputer.
2. Mengetahui proses pembuatan sistem informasi pemesanan berbasis komputer.
3. Menentukan prosedural yang tepat dalam pembuatan sistem informasi pemesanan
berbasis komputer.
4. Mengetahui dampak yang signifikan akibat penerapan sistem informasi
pemesanan berbasis komputer dalam proses pengolahan data.

2. KAJIAN LITERATUR
Normalisasi data bertujuan untuk mendapatkan data dengan ukuran yang lebih kecil
yang mewakili data yang asli tanpa kehilangan karakteristik sendirinya (Indrabayu, dkk,
2012). Proses normalisasi menurut Andri Kristanto ( 2003 ) adalah suatu proses dimana
elemen-elemen data dikelompokkan menjadi tabel-tabel, dimana di dalam tabel tersebut
terdapat entitas-entitas dan relasi antar entitas tersebut. Ada beberapa hal yang perlu
diperhatikan dalam normalisasi suatu data yaitu :
1. Field atau Atribut Kunci
Field kunci merupakan satu field atau satu set field yang terdapat dalam
satu file yang merupakan kunci dan mewakili record. Field yang merupakan kunci
akan menjadi penentu dalam pencarian program.
2. Macam-macam kunci :
a. Candidat Key (Kunci Calon)
Adalah satu atribut atau field yang mengidentifikasikan secara unik dari
suatu kejadian yang sifatnya khusus dari suatu entitas.
b. Primary Key (Kunci Primer)
Adalah kunci kandidat yang dipilih untuk mewakili setiap kejadian dari
suatu entitas. Kunci primer ini sifatnya unik, tidak mungkin sama dan tidak
mungkin ganda.
c. Alternate Key (Kunci Alternatif)
Adalah kunci kandidat yang tidak dipakai sebagai kunci primer.
d. Foreign Key (Kunci Tamu)
Adalah kunci primer yang ditempatkan pada file lain dan biasanya
menunjukkan dan melengkapi suatu hubungan antara file satu dengan file lainnya.
Tahap - tahap di dalam normalisasi data adalah sebagai berikut :
1. Bentuk Tidak Normal
Adalah suatu bentuk dimana semua data dikumpulkan apa adanya tanpa
mengikuti aturan-aturan tertentu. Bisa jadi data yang dikumpulkan akan tidak
lengkap dan terjadi duplikasi data.
2. Bentuk Normal Pertama
 Bentuk normal pertama merupakan suatu bentuk dimana data yang
dikumpulkan menjadi satu field yang sifatnya tidak akan berulang dan tiap field
hanya mempunyai satu pengertian.
3. Bentuk Normal Kedua
Bentuk normal kedua adalah bentuk yang memenuhi syarat-syarat sebagai
berikut:
a. Sudah memenuhi kriteria bentuk normal pertama.
b. Field yang bukan kunci tergantung secara fungsi pada kunci primer.
4. Bentuk Normal Ketiga
Bentuk normal ketiga adalah suatu bentuk yang memenuhi syarat-syarat :
a. Relasi antar file sudah merupakan bentuk normal kedua.
b. Field yang bukan kunci tergantung secara fungsi pada kunci primer.

Tabel 1. Bentuk Normal

Bentuk Definisi
Normal
0NF Tabel yang belum dinormalisasi, yaitu tidak terbukti sebagai relasi
yang benar.
1NF Relasi yang benar (yaitu, tidak ada grup atribut yang berulang dan
setiap baris adalah unik).
2NF Relasi dalam 1NF + semua atribut non-kunci bergantung pada
semua kunci primer.
3NF Relasi dalam 2NF + semua atribut non-kunci hanya bergantung pada
kunci primer.
BCNF Relasi dalam 3NF + hanya ada satu kunci utama di dalam relasi
tersebut.
4NF Relasi dalam BCNF + tanpa dependensi multi-nilai.
5NF Relasi dalam 4NF + dependensi gabungan apa pun didasarkan pada
kunci kandidat.
6NF Relasi dalam 5NF + tanpa dependensi gabungan non-trivial,
termasuk data temporal.
DKNF Relasi di mana semua batasan adalah fungsi domain dan kunci
utama.

3. TUJUAN NORMALISASI
EF Codd, bapak yang diakui dari database relasional dan normalisasi, awalnya
mendefinisikan normalisasi sebagai "prosedur eliminasi yang sangat sederhana" untuk
menghapus domain non-sederhana dari relasi (Codd, 1970, p. 381). Suatu relasi dengan
domain sederhana adalah relasi yang unsur-unsurnya atom atau tidak dapat
didekomposisi (hal. 380). Dengan kata lain, atribut dalam relasi dengan domain
sederhana terikat dengan benar (yaitu, bergantung pada) hanya ke atribut yang secara unik
mengidentifikasi semua yang lain (yaitu, kunci utama). Hoffer et al., (2007)
menyatakannya dengan cukup baik sebagai "Normalisasi adalah proses berturut-turut
mengurangi hubungan dengan anomali untuk menghasilkan hubungan yang kecil dan
terstruktur dengan baik" (hal. 211). Pembaca harus memperhatikan bahwa "kecil" adalah
istilah relatif. Relasi yang dinormalisasi dengan benar dengan beberapa lusin atribut tidak
sekecil relasi yang tidak dinormalisasi dengan setengah lusin atribut. Baik hubungan
besar maupun kecil adalah bagian dari realitas dalam struktur informasi perusahaan.
Namun, Hoffer et al. (2007) masuk ke daftar sebagai “beberapa tujuan utama
normalisasi:
1. Minimalkan redundansi data, sehingga menghindari anomali dan menghemat
ruang penyimpanan.
2. Sederhanakan penegakan integritas referensial kendala
3. Membuat lebih mudah untuk memelihara data (menyisipkan, memperbarui, dan
menghapus)
4. Berikan desain yang lebih baik yang ditingkatkan representasi dari dunia nyata
dan dasar yang lebih kuat untuk pertumbuhan di masa depan ”(p. 211).
Memang, itu mungkin hasil dan manfaat, yang itu dicapai dalam berbagai tingkat dari
satu struktur informasi perusahaan ke yang berikutnya. Namun, tujuan sebenarnya dari
normalisasi tetap seperti pada tahun 1970, untuk menghasilkan hubungan yang terstruktur
dengan benar.
Bukan niat penulis untuk memilih penulis mana pun untuk kritik. Sebaliknya,
harapannya adalah untuk memperjelas tujuan normalisasi, karena Kurangnya pemahaman
tentang tujuan sering kali menyebabkan Kurangnya apresiasi siswa terhadap kekuatan
teknik tersebut. Ini juga dapat menyebabkan desainer beralih ke metode lain untuk
mencapai tujuan tersebut. Namun, ada orang lain yang pernyataannya salah menambah
tantangan belajar.
Misalnya, satu buku teks mengatakan “Normalisasi adalah proses untuk
mengevaluasi dan mengoreksi struktur tabel untuk meminimalkan redundansi data,
sehingga mengurangi kemungkinan anomali data” (Rob & Coronel, 2007, p. 148).
Pertama, kami menganalisis relasi daripada "tabel" karena tabel tidak memenuhi syarat
untuk menjadi relasi kecuali jika ditampilkan setidaknya dalam bentuk normal pertama.
Kedua, kami bertujuan untuk menghilangkan anomali modifikasi daripada mengurangi
"anomali data". Keduanya memang merupakan keberatan yang agak rewel.
Ketiga dan lebih bermasalah, bagaimanapun, adalah gagasan bahwa normalisasi
dimaksudkan untuk "meminimalkan redundansi data." Codd (1970) mencatat bahwa
“Redundansi dalam himpunan relasi bernama harus dibedakan dari redundansi dalam
himpunan representasi yang disimpan. Di sini kami terutama mementingkan yang
pertama ”(hlm. 385). Ini adalah yang terakhir yang dengan tepat disebut sebagai
"redundansi data", sedangkan yang sebelumnya bisa lebih baik disebut "redundansi
struktur".
Selain itu, Codd (1970) selanjutnya menggambarkan redundansi yang kuat dan
lemah. Sekali lagi, bukan tujuan dari makalah ini untuk menjelaskannya secara
menyeluruh. Cukuplah untuk sekali lagi mengutip Codd tentang signifikansi masing-
masing. “Alasan penting untuk keberadaan redundansi yang kuat dalam himpunan relasi
bernama adalah kenyamanan pengguna” (p. 386). “Secara umum, redundansi yang lemah
melekat dalam kebutuhan logis komunitas pengguna. Mereka tidak dapat dilepaskan oleh
sistem atau administrator basis data ”(hlm. 386).
Jadi, sejumlah redundansi struktur diinginkan. Normalisasi, jika diterapkan dengan
benar pada relasi, akan memastikan bahwa redudansi struktur dinyatakan dengan benar.
Contoh umum redundansi struktur adalah penempatan kunci asing ke dalam relasi.
Karena kunci asing adalah kunci utama dan atribut dalam beberapa relasi lain,
penempatan kunci asing menciptakan redundansi dalam struktur database secara
keseluruhan.
 Normalisasi menyeluruh juga dapat meminimalkan kemungkinan terjadinya
redundansi data yang tidak perlu. Namun, biasanya, perlindungan terhadap redundansi
data diberlakukan melalui kontrol integritas yang diberlakukan saat relasi diterapkan
secara fisik. Meskipun demikian, perlindungan seperti itu, redundansi data dapat menjadi
bagian dari desain fisik bahkan dalam rangkaian hubungan yang sangat dinormalisasi.
Contoh hasil redundansi data yang bermanfaat dengan basis data yang di replikasi, saat
data sengaja disalin ke beberapa platform.
Mungkin merupakan kecenderungan alami dari penulis buku teks untuk
mengembangkan konsep untuk membedakan cakupan dalam satu buku dari para
pesaingnya. Namun, ada kalanya yang terbaik adalah tetap berpegang pada definisi
sejarah yang sederhana. Sementara normalisasi dapat menghasilkan lebih banyak
keuntungan, akan lebih baik bagi siswa jika penulis tetap berpegang pada satu-satunya
tujuan normalisasi: untuk menghasilkan hubungan yang terstruktur dengan baik.

4. BANYAK NORMALISASI
Bentuk normal memberikan titik pemeriksaan untuk normalisasi. Sembilan formulir
normal tercantum dalam Tabel 1. Penulis ini menyertakan 0NF-nya sendiri, yang tidak
ditemukan dalam cetakan di tempat lain. Namun, tidak semua penulis buku teks mencatat
keberadaan delapan buku lainnya. Selain itu, ada ketidak-sepakatan mengenai titik di
mana normalisasi harus berakhir.
Rob & Coronel (2007) mengambil pendirian bahwa “Hampir semua desain bisnis
menggunakan 3NF sebagai bentuk normal yang ideal” (hlm. 173). Selain itu, “Tabel di
3NF akan bekerja sesuai dengan database transaksional bisnis. Namun, ada kalanya
bentuk normal yang lebih tinggi berguna ”(hlm. 163). Para penulis tersebut terus
mengilustrasikan BKNF dan 4NF.
Demikian pula, Hoffer et al. (2007) menyatakan "Hubungan dalam bentuk normal
ketiga (3NF) cukup untuk sebagian besar aplikasi database praktis" (p. 572). Namun,
mereka menjelaskan BKNF dan 4NF, meskipun itu diturunkan ke lampiran. Buku teks
itu tidak menjelaskan 5NF dan 6NF.
Pratt dan Adamski (2005) menyatakan “Bentuk normal yang paling umum adalah
bentuk normal pertama (1NF), bentuk normal kedua (2NF), bentuk normal ketiga (3NF),
dan bentuk normal keempat (4NF)” (hal. 140). Mereka tidak membuat perbedaan antara
BKNF dan 3NF tetapi menggunakan definisi BKNF sebagai definisi 3NF (hlm. 153).
Mereka tidak membahas penerapan bentuk normal di atas BKNF, tetapi menyarankan
bahwa seseorang dapat menghindari masalah ketergantungan multinilai (masalah 4NF)
dengan menggunakan metodologi desain (hlm. 166).
Menurut Mannino (2004), “Cerita normalisasi tidak berakhir dengan 4NF. Bentuk
normal lainnya telah diusulkan, tetapi kepraktisannya belum dibuktikan ”(hal 245).
Akibatnya, dia menunjukkan bentuk normal hanya melalui 4NF.
Ulman & Widom (2008) menetapkan pendekatan yang berbeda dengan hanya
membahas Bentuk Normal Boyce-Codd. “Ternyata ada kondisi sederhana di mana
anomali-anomali yang dibahas di atas bisa dijamin tidak akan ada. Kondisi ini disebut
bentuk normal Boyce-Codd, atau BCNF”(hlm. 88).
Kroenke (2006) mengambil pendekatan yang mirip dengan Ulman & Widom,
meskipun ia menggunakan satu bentuk normal lebih tinggi dalam ilustrasinya. Pertama,
dia mengelompokkan bentuk normal menjadi tiga tingkatan (lihat Tabel 2). Kemudian
dia menjelaskan bahwa seseorang dapat mengatasi semua masalah yang ditangani oleh
bentuk normal yang lebih rendah hanya dengan menormalkan ke 4NF. Ia juga
menjelaskan 5NF dan DKNF dengan menyatakan “Sumber anomali ketiga adalah
esoterik. Masalah-masalah ini melibatkan batasan data yang spesifik, jarang, dan bahkan
aneh ”(hlm. 83).

Tabel 2. Pengelompokan Bentuk Normal

Sumber Anomali Bentuk Prinsip Desain
Normal
Ketergantungan 1NF, 2NF, BCNF: Merancang tabel sehingga setiap
Fungsional 3NF, BCNF determinan adalah kunci kandidat
Ketergantungan 4NF 4NF: Pindahkan setiap ketergantungan
Multivalued multinilai ke tabel
Batasan dan keanehan 5NF, DK / NF DK / NF-nya sendiri: Jadikan setiap batasan
data sebagai domain dan kunci kandidat
konsekuensi logis.
Sumber: Kroenke (2006, h. 83)

Ketidak-sepakatan di antara pihak berwenang tentang bentuk normal mana yang

cukup jauh membingungkan baik bagi siswa maupun guru. Konsep yang dikemukakan
oleh Ulman & Widom dan Kroenke bahwa seorang desainer database hanya dapat
menggunakan satu bentuk normal (BCNF atau 4NF, masing-masing) untuk
menghilangkan semua masalah tingkat yang lebih rendah menarik dari perspektif
pengajaran. Tentu saja, mengajar satu bentuk normal bisa lebih mudah dan lebih sedikit
memakan waktu daripada mengajar empat atau lima. Memang, penulis ini menganjurkan
pendekatan Kroenke karena pengalaman kelas menunjukkan pembelajaran yang lebih
cepat dan tingkat pemahaman yang lebih dalam.
Tetapi bagaimana seseorang mengajarkan normalisasi dengan hanya
menggunakan satu bentuk normal? Seperti yang dinyatakan sebelumnya, bukan maksud
makalah ini untuk mengajarkan normalisasi. Juga bukan niat untuk mengajarkan cara
mengajarkan normalisasi. Namun, penulis ini merasa berguna untuk menginstruksikan
siswa untuk mengikuti kebijaksanaan "lagu anonim yang ditemukan dalam Kroenke
(2006): 'Saya bersumpah untuk membangun [hubungan] saya sehingga semua [atribut]
non-kunci bergantung pada kunci, seluruh kuncinya, dan hanya kuncinya, jadi bantu aku
Codd '”(p. 88).
Namun, pertanyaannya tetap "Mengapa tidak beralih ke bentuk normal yang lebih
tinggi?" Apakah bentuk normal yang lebih tinggi tidak praktis atau esoterik, seperti yang
disarankan dalam buku teks? Haruskah cukup memberi kesan kepada siswa bahwa relasi
3NF cocok untuk bisnis atau cukup untuk sebagian besar aplikasi? Sementara banyak
database yang terinstal mungkin memang berakhir dengan relasi kebanyakan dalam 3NF,
adalah menyesatkan untuk memberi tahu siswa bahwa tidak masalah untuk berhenti
dengan 3NF.
Ada pendekatan berorientasi bisnis yang lebih baik untuk masalah ini. Gambar 1
menyajikan bagan kolom bergaya berdasarkan banyak pengalaman penulis dengan
struktur informasi perusahaan secara langsung. Pertama, sumbu horizontal menunjukkan
bahwa untuk mencapai setiap bentuk normal membutuhkan kenaikan waktunya sendiri.
Pengalaman dengan lusinan klien mengatakan, misalnya, bahwa mencapai 5NF
membutuhkan waktu yang jauh lebih lama daripada menjangkau satu sama lain dalam
bentuk normal lainnya. Sumbu vertikal menggambarkan jumlah relatif anomali masa
depan yang dihilangkan dengan berpindah ke setiap bentuk normal yang lebih tinggi.
Jumlah yang dikeluarkan dengan mencapai 5NF sangat rendah dibandingkan dengan
tingkat keberhasilan mencapai bentuk normal yang lebih rendah.
Apa yang ditunjukkan bagan itu adalah model laba atas investasi bisnis sederhana.
Pengembalian (pengurangan anomali masa depan) dari investasi (waktu yang dihabiskan
untuk normalisasi) dari memperjuangkan 5NF sama sekali tidak sebesar itu untuk bentuk
normal yang lebih rendah. Masalah dari berhenti untuk mencapai bentuk normal yang
lebih tinggi adalah bahwa anomali yang terkait dengan bentuk normal tersebut tidak
dihilangkan. Kabar baiknya adalah ada solusi yang berbeda. Jika anomali 5NF seperti itu
ditemui di kemudian hari, perangkat lunak rutin dapat ditulis untuk mengatasinya.
Tidak menormalisasi ke 6NF adalah masalah yang berbeda dengan tidak
menormalkan ke 5NF. Date, et al., (2002) menjelaskan 6NF sebagai data temporal. Dalam
pengalaman penulis ini, data temporal dengan anomali tipe 6NF jauh lebih umum di
instalasi data warehousing daripada di database yang digunakan terutama untuk operasi
harian. Oleh karena itu, pengembalian investasi mungkin tidak dapat dibenarkan kecuali
perusahaan sedang merancang gudang data. Kabar baiknya di sini adalah bahwa
normalisasi 6NF dapat ditunda ke waktu ketika gudang data tersebut direncanakan, dalam
pengalaman penulis ini.
Kegagalan menormalisasi ke DKNF adalah sebuah oxymoron. Tidak ada yang
memiliki pengalaman dengan DKNF karena ini adalah upaya anjing jerami untuk
mendefinisikan kesempurnaan tanpa memberikan metode apa pun untuk sampai ke sana
atau deskripsi yang tepat tentang seperti apa setelah seseorang berada di sana. Jika
perancang database menghabiskan waktu untuk mencoba menormalkan ke DKNF, laba
atas investasi diperkirakan nol.
Di ujung kiri skala, pengembalian (jumlah anomali masa depan yang dihapus) atas
investasi (waktu) untuk mencapai 0NF adalah nol, tetapi kemungkinan besar negatif.
Itulah sifat relasi 0NF, yang merupakan hasil dari tahap desain logis di mana tabel (bukan
relasi) awalnya dibentuk dan, oleh karena itu, tahap ketika anomali masa depan
diperkenalkan ke dalam struktur database. Oleh karena itu, orang dapat berargumen
bahwa ROI sebenarnya negatif.
Penting untuk menangani masalah terkait. Normalisasi biasanya menghasilkan
hubungan yang lebih banyak dan lebih kecil. Sejumlah besar hubungan kecil dapat
mengakibatkan kurangnya efisiensi dalam sub sistem penyimpanan perangkat keras,
lebih banyak biaya perangkat lunak, kurangnya kenyamanan bagi pengguna, dan
kurangnya kesederhanaan manajerial untuk administrator basis data.
Untuk mengatasi situasi tersebut, tentunya ada solusi dari denormalisasi. Namun,
itu harus disimpan sebagai cadangan sampai setelah perancang basis data membuktikan
struktur basis data menjadi senyaman mungkin. Denormalisasi seperti itu harus
diterapkan dengan bijaksana.
Jika denormalisasi digunakan, apakah itu berarti waktu telah terbuang percuma
untuk melakukan normalisasi? Tidak jika normalisasi dianggap sebagai polis asuransi.
Lebih baik menghapus sebanyak mungkin anomali di masa depan. Kemudian,
memperkenalkan kembali masalah potensial melalui denormalisasi memberi
administrator data indikasi yang jelas tentang di mana tepatnya anomali di masa depan
itu mungkin terjadi.
5. METODE PENELITIAN
Pada Metode penelitian ini menggunakan 3 cara yaitu pengamatan, wawancara, dan
dokumentasi.
5.1 Pengamatan (observasi)
Pada saat mengumpulkan data dan informasi dengan melakukan pengamatan
secara langsung ke lapangan terhadap suatu kegiatan yang sedang dilakukan untuk
memperoleh data yang dibutuhkan. Pengamatan peneliti dilakukan pada :
Tempat : Warung Nasi Bu Wiwit, Jl. Baru Sentul, Sentul, Kec. Babakan Madang,
Bogor, Jawa Barat 16710
Waktu : 24 Desember 2020
Berdasarkan pengamatan yang dilakukan, penelitian ini mengumpulkan informasi
mengenai Profil singkat Warung Nasi Bu Wiwit, Menu, dan Sistem pemesanan

5.2 Wawancara
Metode ini merupakan teknik pengumpulan data dengan cara melakukan
kegiatan tanya jawab dan wawancara. Wawancara dilakukan pada tanggal 24
Desember 2020 mulai pukul 14:00 WIB sampai dengan selesai, dengan narasumber
Rini selaku pemilik dan sekaligus pengurus dari warung nasi bu wiwit. Didapatkan
hasil wawancara yaitu menemukan cara yang di harapkan lebih efektif dalam
melakukan pemesanan dan pelayanan yaitu menggunakan sistem komputerisasi pada
saat melakukan pemesanan agar datanya tidak mudah hilang, nomor antrian teratur,
dan tercatat secara jelas.

5.3 Dokumentasi
Studi dokumentasi merupakan merupakan suatu teknik pengumpulan data
dengan menghimpun dan menganalisis dokumen-dokumen berupa gambar atau
digital. Pada penelitian ini yang menggunakan alat dokumentasi berupa kamera yang
untuk memotret Warung Nasi Bu Wiwit sebagai dokumentasi.

6. HASIL PENELITIAN
Pada normalisasi data yang akan dirancang untuk usaha warung nasi bu wiwit
yaitu meliputi batasan yang sudah ditentukan yang akan dirangkum dalam tabel
sebagai berikut.

Tabel 6.1 Normalisasi Data Menu Warung Nasi Bu Wiwit

Kode Menu Harga Kode Menu Harga
A1 Ayam Goreng Rp8.000 A10 Perkedel Rp2.000
A2 Ayam Bakar Rp8.000 A11 Ati Ampela Rp5.000
A3 Opor Ayam Rp8.000 A12 Capcay Rp4.000
A4 Tumis Ikan Tongkol Rp3.000 A13 Bakwan Jagung Rp1.000
A5 Gudeg Rp6.000 A14 Nasi Rp5.000
A6 Mie Sayur Rp3.000 A15 Es Teh Tawar Rp2.000
A7 Sayur Toge Rp3.000 A16 Es Teh Manis Rp4.000
A8 Tempe Orek Rp3.000 A17 Air Mineral Rp4.000
A9 Telor Dadar Rp4.000
Sumber: Peneliti, 2020
 Setelah seluruh menu terinput dan diberikan kode makanan, maka daftar tersebut
yang akan menjadi parameter atau record code yang akan diaplikasikan pada
program yang akan dirancang. Berdasarkan data diatas, penjabaran serta kategori
yang sudah ditentukan dari normalisasi data diatas, berikut tampilannya.

Tabel 6.2 Daftar Menu Warung Nasi Bu Wiwit (Menu Utama)

Kode Menu
A1 Ayam Goreng
A2 Ayam Bakar
A3 Opor Ayam
A4 Tumis Ikan Tongkol
A5 Gudeg
A6 Mie Sayur
A7 Sayur Toge
A8 Tempe Orek
A9 Telor Dadar
Sumber: Peneliti, 2020

Tabel 6.3 Daftar Menu Warung Nasi Bu Wiwit (Lain-lain)

Kode Menu
A10 Perkedel
A11 Ati Ampela
A12 Capcay
A13 Bakwan Jagung
A14 Nasi
Sumber: Peneliti, 2020

Tabel 6.4 Daftar Menu Warung Nasi Bu Wiwit (Minuman)

Kode Menu
A15 Es Teh Tawar
A16 Es Teh Manis
A17 Air Mineral
Sumber: Peneliti, 2020

Tabel 6.5 Daftar Harga Warung Nasi Bu Wiwit (Menu Utama)

Kode Harga
A1 Rp8.000
A2 Rp8.000
A3 Rp8.000
A4 Rp3.000
A5 Rp6.000
A6 Rp3.000
A7 Rp3.000
A8 Rp3.000
A9 Rp4.000
Sumber: Peneliti, 2020
 Tabel 6.6 Daftar Harga Warung Nasi Bu Wiwit (Lain-lain)
Kode Harga
A10 Rp2.000
A11 Rp5.000
A12 Rp4.000
A13 Rp1.000
A14 Rp5.000
Sumber: Peneliti, 2020
Tabel 6.7 Daftar Harga Warung Nasi Bu Wiwit (Minuman)
Kode Harga
A15 Rp2.000
A16 Rp4.000
A17 Rp4.000
Sumber: Peneliti, 2020

Berdasarkan tabel diatas, penggolongan data sudah dikategorikan berdasarkan

penyesuaiannya yaitu berdasarkan menu (utama, minuman dan lain-lain), dan harga
serta dibantu dengan kode sebagai penamaan dari tiap-tiap keterangan.

7. RINGKASAN
Jurnal ini telah menunjukkan perbedaan di antara buku teks mengenai dua konsep
penting normalisasi. Pertama, tujuan normalisasi harus di standarisasi kembali ke definisi
asli Codd. Banyak hasil potensial dan manfaat normalisasi tidak boleh disamakan dengan
tujuan utama, yaitu untuk menciptakan hubungan yang terstruktur dengan baik, karena
mengandung lebih sedikit anomali di masa depan. Berfokus pada manfaat alih-alih tujuan
dapat menyesatkan seseorang untuk melewati normalisasi sama sekali karena ada cara
lain untuk setidaknya
Pertanyaan tentang seberapa jauh database harus dinormalisasi telah dijawab dengan
menggunakan model laba atas investasi sederhana. Menghentikan 4NF bukanlah
keputusan bisnis yang bijaksana karena banyak anomali yang mungkin masih ada.
Seorang desainer harus mencapai bentuk normal keempat. Melampaui 4NF harus
diperiksa dalam hal ROI. Dalam pengalaman penulis ini, memperjuangkan 5NF jarang
menghasilkan hasil yang signifikan dan biasanya tidak dibenarkan berdasarkan ROI.
Namun, bentuk normal keenam harus dicapai jika data temporal lazim, seperti di gudang
data, yang membutuhkan pencapaian 5NF terlebih dahulu.

8. KESIMPULAN
Basis Data UKM Warung Nasi Bu Wiwit dirancang dengan menggunakan tiga buah
model utama, yaitu model proses, model Entity-Relationship, dan model data relasional.
Model-model tersebut digunakan secara berurutan dalam menterjemahkan kondisi nyata
Warung Nasi Bu Wiwit ke dalam basis data. Pengembangan model- model ini di
dasarkan pada kebutuhan informasi yang diperoleh dari daftar menu.
Struktur Basis Data Warung Nasi Bu Wiwit terdiri dari 7 buah table yang saling
berhubungan, yang merupakan hasil implementasi dari himpunan entity dan hasil
implementasi dari himpunan relasi.
9. SARAN
Penelitian ini hanya memfokuskan pada 3 tahapan awal dari desain basis data yaitu
identifikasi kebutuhan, desain konseptual, dan desain logis. Sehingga belum terlihat
kinerjanya dalam penggunaan. Oleh karena itu disarankan untuk melanjutkan penelitian
ini dengan tahapan berikut yaitu desain fisik yang meliputi penentuan index, perhitungan
perkiraan besar volume data, dan implementasi dalam software yang akan digunakan.
 DAFTAR PUSTAKA

Codd, EF (1970). “Model data relasional untuk bank data bersama yang besar.”
Komunikasi ACM, Vol. 13 (6). 377-387.
Tanggal, CJ, Darwen, H., & Lorentzos, NA (2002). Data Temporal dan Model
Relasional: Penyelidikan Mendetail ke dalam Penerapan Teori Interval dan
Relasi dengan Masalah Manajemen Basis Data Temporal. Amsterdam: Elsevier
Science Ltd.
Hoffer, JA, Prescott, MB, & McFadden, FR (2007). Modern Database
Management,8ke- edisi. Upper Saddle River, NJ: Pearson Prentice Hall.
Kroenke, DM (2006). Pemrosesan Basis Data: Fundamentals, Design, and
Implementation,10ke- edisi. Upper Saddle River, NJ: Pearson Prentice Hall.
Mannino, MV (2004). Desain Basis Data, Pengembangan Aplikasi dan Administrasi.
Boston: McGraw Hill Irwin.
Pratt, PJ, & Adamski, JJ (2005). Konsep Manajemen Basis Data,5ke- edisi. Boston:
Teknologi Kursus Thompson.
Rob, P., & Coronel, C. (2007). Sistem Basis Data: Desain, Implementasi, dan
Manajemen,7ke- edisi. Boston: Teknologi Kursus Thompson.
Ulman, JD, & Widom, J. (2008). A Course Pertama di Sistem Basis Data, 3rd ed.
Upper Saddle River, NJ: Pearson Prentice Hall.