TABLE OR FILE

Data di organisir dalam tabel atau file-file (arsip), suatu tabel atau file berisi sekumpulan record
yang menyimpan data mengenai suatu entitas tertentu.

Tabel dan file ditampilkan sebagai struktur dua dimensi yang terdiri dari kolom vertical dan
baris horizontal. Setiap kolom mewakili field, atau karakteristik dari entitas, dan setiap baris
mewakili record, yang merupakan suatu kejadian individual, atau terjadinya entitas.
Sebagai contoh, jika sebuah Perusahaan memiliki 10.000 pelanggan, tabel CUSTOMER akan
mencakup 10.000 record, masing-masing mewakili pelanggan yang spesifik
FIELD
Suatu Field, disebut juga atribut, yang merupakan karakteristik tunggal atau fakta tentang suatu
entitas. Sebagai contoh, sebuah entitas CUSTOMER mungkin termasuk ID Pelanggan, First
Name, Last Name, Address, City, State, Zip, dan E-mail.
FILE-ORIENTED SYSTEM, biasa disebut juga sistem pemrosesan file, menyimpan data
dalam satu atau lebih file terpisah

Perancangan Berorientasi File, dua sistem menggunakan data terpisah, yang menyebabkan
redudansi.

Contoh bengkel pemeliharaan menggunakan duas sitem terpisah : Satu sistem rekord pekerjaan
dan Sistem penrecord Pekerja.
Perhatikan : data yang sama disimpan dalam lebih dari satu lokasi. Sebagai contoh, tiga item
informasi (Mechanic No, Name dan Pay Rate) disimpan dalam kedua file data. Redudansi ini
merupakan kekurangan utama dari sistem berorientasi file, karena hal tersebut mengurangni
efisiensi dan kualitas data.
DATABASE MANAGEMENT SYSTEM, semua tabel dihubungkan oleh field. Salah satu jenis
field yang umum dapat berupa nomor pelanggan, yang dapat digunakan untuk menempatkan
informasi mengenai pelanggan dalam tabel. Field umum yang menghubungkan dua tabel disebut
link, join atau menghubungkan tabel.

Database Management System, data disimpan dalam tabel terpisah, yang dihubungkan oleh field
umum. Data disimpan hanya dalam saru lokasi fisik.

Ulasan mengenai Pemrosesan file

Beberapa perusahaan masih menggunakan pemrosesan file untuk menangani volume besar dari
data terstruktur dengan basis teratur, banyak penginggalan sistem lama menggunakan
perancangan pemrosesan file karena metode tersbut bekerja dengan baik dengan hardware
mainframe dan batch input. (pemrosesan file akan efisien dan efektif dalam situasi tertentu)
Masalah yang mungkin muncul dengan menggunakan sistem pemrosesan file :
1. Redundancy Data, dimana data bersama untuk dua atau lebih sistem informasi disimpan di
beberapa tempat. Pengulangan data membutuhkan ruang penyimpanan yang besar.
2. Data Integrity, masalah yang muncul jika pemutakhiran (updated) tidak diterapkan pada setiap
file. Perubahan data menyebabkan ketidak konsistenan yang menyebabkan informasi tidak
tepat pada sitem kedua.
3. Structure Data Rigid dari lingkungan pemrosesan file khusus, Kegiatan usaha harus membuat
keputusan berbasiskan pada data perusahaan yang begitu luas, dan mannajer sering
membutuhkan informasi dari berbagai unit dan departemen. Dalam lingkungan pemrosesan
file, berarti bahwa memanggil informasi dari ketidak terikatan, sistem berbasis file yang
lamban dan tidak efisien.

Berbagai jenis file dari sistem informasi berorientasi file, antara lain Master File, Tabel File,
Filne Transaksi, File Kerja, File Keamanan dan File historis.
1. Master File, penyimpanan data yang relatif permanen mengenai suatu entitas. Sebagai
contoh : Master File PRODUK berisi satu logika rekord untuk setiap produk yang perusahaan
jual. Field kuantitas pada setiap rekord bs berubah setiap hari, tetapi data lain seperti kode
produk, nama dan deskripsi tidak berubah.
2. File Tabel, berisi referensi data yang digunakan oleh sistem informasi. Sama halnya dengan
master file file tabel relatif stastis dan tidak di mutakhirkan oleh sistem infomasi. Contoh :
Tabel pajak dan tabel tarif pos.
3. File Transaksi, menyimpan rekord yang berisi kegiatan usaha harian dan data operasional.
File transasksi merupakan input file yang digunakan untuk memutakhirkan File Induk;
sebagai contoh : File Denda dan pembayaran untuk melakukan pemutakhiran file saldo
pelanggan.
4. File kerja, merupakan file temporer yang diciptakan oleh sistem informasi untuk tugas
tunggal. Contoh : File yang diurutkan dan File Laporan yang mempertahankan Laporan
sampai laporan tersebut dicetak.
5. File Kemanan, dibuat dan disimpan untuk tujuan pemulihan dan backup. Contoh : Jejak Audit
dan Back dari Induk, tabel dan file transaksi.
6. File Historis, diciptakan untuk kepentingan pengarsipan, Contoh : pelanggan yang tidak
melakukan registrasi selama dua semester harus dihapus dari file induk pelajar active dan
ditambahkan ke file pelajar yang tidak aktif, yang merupakan file historis yang dapat
digunakan untuk pencarian dan pelaporan.

Komponen DBMS
DBMS menyediakan interface diantara satu database dan user yang memerlukan akses data.
Seorang sistem analis harus memahami semua komponen dari DBMS, sebagai tambahan untuk
interface bagi user, administrator database, dan sistem terkait, database juga memiliki Bahasa
mamanipulasi datam skema dan subskema dan fisik penyimpanan data.

Interface bagi user, Admnistrator Database dan sistem terkait.

Saat user admin database dan sistem informasi terkait meminta data dan layanan, DBMS
memproses permintaan, memanipulasi data dan menyediakan respon.
User, user umumnya bekerja dengan pencarian yang di definisikan dimuka dan perintah
papantombol (switchboard), tetapi juga menggunakan Bahasa pencarian untuk mengakses
penyimpanan data. Suatu Bahasa pencarian (Quary Languange) memungkinkan user untuk
mengkhususkan tugas tanpa menspesifikasi bagaimana tugas akan di capai, Beberapa bahsa
pencarian menggunakan perintah Bahasa alamiah yang menyerupai kalimat bahasa Inggris [ada
umumnya. Dengan menggunakan Bahasa pencarian dengan contoh (QBE), user menyediakan
suatu contoh dari data yang diminta. Beberapa program database juga menhasilkan SQL
(Structured Query Language) yang merupakan bahsa yang memungkinkan Client Workstation
berkomunikasi dengan server dan computer mainframe.
Admnistrator database, bertanggung jawab untuk memenjemen dan mensupport DBMS. DBA
memberi perhatian pada kemanan dan dan integritas data, menjaga kases yang tidak diotorisasi,
menyediakan backup dan pemulihan, jejak auditm pemeilharaan database dan memberikan
dukungan kebutuhan user. Kebanyakan DBMS menyediakan program utility untuk membantu
DBA dalam menciptakan dan mengupdate struktur data, mengumpulkan dan melaporkan pola
dari penggunaan database dan mendeteksi dan melaporkan ketidak teraturan database.
Sistem Informasi terkait, DBMS dapat memberikan dukungan beberapa sistem infomasi yang
berhubungan yang menyediakan input ke dan meminta data khusus dari DBMS. Tidak seperti
user interface, tidak ada intervensi manusia dibutuh untuk komunikasi dua arah antara DBMS
dan sistem terkait.
Bahasa Manipulasi Data (DML), mengontrol bekoperasinya database, mencakup menyimpan,
memanggil, memutakhirkan dan menghapus data.

Skema, Definisi lengkap dari satu database, mencakup deskripsi dari semua field, tabel dan
hubungan . Subskema, merupakan suatu pandangan database yang digunakan oleh satu atau
lebih sistem atau user, Suatu subskema mendefinisikan hanyya bagian-bagian tersebut dari
database yang merupakan sistem khusus atau kebutuhan user atau diperbolehkan mengakses.
Contoh : untuk melindungi privasi individual, tidak diperkenankan untuk sistem menejemen
proyek memanggil tarif pembayaran pekerja, Dalam kasus ini subskema sistem menejemen
proyek tidak akan memasukan field tarif pembayaran. Perancang database juga menggunakan
subskema untuk membatasi level akses yang diperkenankan.
Terminologi Perancangan Data
Definisi, terminology perancangan data mencakup entitas tabel, file, field, record, tuple dan
kunci field.
Entitas (entity), entitas merupakan orang, tempat, benda, atau peristiwa di mana data
dikumpulkan dan di maintain, Contoh : sistem penjualan secara online memerlukan entitas yang
diberi nama PELANGGAN, PESANAN, PRODUK DAN SUPPLIER.
Tabel atau File, dnisir kedalam tabel atau file, suatu tabel atau file, berisi seperangkat record
terkait yang menyimpan data mengenai entitas tertentu, Tabel dan File ditampilkan sebagai
struktur dua dimensi yang berisi kolom vertikal dan baris horizontal. Setiap kolom mewakili satu
field, atau karakteristik entitas dan setiap baris mewakili record.
Field, biasa disebut juga atribut, merupakan karakteristik tunggal atau fakta mengenai suatu
entitas, sebagai contoh : Entitas PELANGGAN dapat mencakup ID, Nama Pertama, Nama
Terakhir, Alamat, Kota, Provinsi, Zip dan alamat email. Atribut bersama (Common Attribute),
merupakan atribut yang muncul pada lebih dari satu entitas. Atribut bersama dapat digunakan
untuk menghubungkan entitas dalam berbagai jenis hubungan.
REKORD ( Record ) Sebuah Record, juga disebut tuple (sajak dengan pasangan), merupakan
satu set Field terkait yang menggambarkan satu kejadian, atau terjadinya suatu entitas, seperti
satu pelanggan, suatu pesanan, atau suatu produk. Sebuah Record mungkin memiliki satu atau
puluhan Field, tergantung pada informasi apa yang diperlukan.

Fields kunci (Key Fields)

Selama tahap desain sistem, Field kunci digunakan untuk mengatur, mengakses, dan memelihara
struktur data. Terdapat empat jenis kunci yaitu kunci primer (primary Keys), kunci kandidat
(Candidate Keys), kunci asing (Foreign Keys), dan kunci sekunder (Secondary Key).

PRIMARY KEY, suatu Kunci Primer merupakan Field atau kombinasi dari Field yang secara
unik dan minimal mengidentifikasi anggota tertentu dari entitas. Sebagai contoh, dalam tabel
pelanggan, Nomor Pelanggan adalah kunci primer yang unik karena tidak ada dua pelanggan
memiliki nomor pelanggan yang sama. Key tersebut juga minimal karena tidak mengandung
informasi melebihi apa diperlukan untuk mengidentifikasi pelanggan. Dalam sebuah tabel
CUSTOMER, Customer ID dapat digunakan sebagai kunci primer yang unik. ID Pelanggan
adalah contoh dari kunci primer berdasarkan satu field tunggal.
Kunci primer juga dapat terdiri dari dua atau lebih field. Sebagai contoh, jika seorang siswa
mendaftar untuk tiga Course , Student ID nya akan muncul dalam tiga record dalam Registration
System. Jika salah satu dari mata kuliah tersebut memiliki 20 mahasiswa, 20 record yang
terpisah akan ada untuk nomor mata kuliah - satu record untuk setiap mahasiswa yang telah
mendaftar.
Dalam File registrasi, baik Nomor Mahasiswa maupun ID Matakuliah adalah unik, sehingga
Filed tidak dapat dijadikan kunci primer. Untuk mengidentifikasi seorang mahasiswa tertentu
terdaftar dalam matakuliah tertentu, kunci primer harus berupa kombinasi Nomor Mahasiswa
dan ID Matakuliah. Dalam hal ini, Kunci Primer disebut Kunci kombinasi (Combination Key).
Sebuah Kunci kombinasi juga bisa disebut kunci komposit (Composite Key), kunci bersambung
(Concatenated Key), atau Multivalued Key.
Gambar 9-12 menunjukkan empat tabel yang berbeda. Tiga tabel pertama memiliki Kunci
Primer Field-Tunggal. Perhatikan bahwa dalam tabel keempat, namun, kunci primer adalah
kombinasi dari dua field: STUDENT-NUMBER dan COURSE-ID.
KUNCI KANDIDAT (Candidate Key) Kadang-kadang Anda memiliki pilihan dari field atau
field kombinasi untuk digunakan sebagai kunci primer (Primary Key). Setiap field yang bisa
berfungsi sebagai kunci primer disebut kandidat kunci. Sebagai contoh, jika setiap karyawan
memiliki Nomor Karyawan yang unik, maka Anda bisa menggunakan baik Nomor Karyawan
atau Nomor Jaminan Sosial sebagai kunci Primer. Karena Anda dapat menetapkan hanya satu
field sebagai kunci primer , Anda harus memilih field yang paling sedikitnya jumlah kandungan
datanya dan adalah yang paling mudah digunakan. Apa saja field yang bukan merupakan kunci
primer atau kandidat kunci disebut nonkey field .

Kunci Primer ditunjukkan pada Gambar 9-12 juga merupakan kunci kandidat. Dua calon lainnya
kunci ada: yang SOSIAL-SECURITY-NUMBER Field dalam tabel ADVISOR dan COURSE-
DESCRIPTION field dalam tabel COURSE.
KUNCI ASING (FOREIGN KEY) Ingat bahwa Field Bersama (Common Field) terdapat lebih
dari satu pada tabel dan dapat digunakan untuk membentuk suatu hubungan, atau
menghubungkan, antara tabel. Misalnya, pada Gambar 9-12, field ADVISOR-NUMBER muncul
di kedua tabel STUDENT dan tabel ADVISOR dan menggabungkan tabel secara bersama-sama.
Perhatikan bahwa ADVISOR-NUMBER adalah kunci primer dalam tabel ADVISOR, di mana
ADVISOR se cara unik mengidentifikasi setiap penasihat, dan merupakan kunci asing di tabel
STUDENT. Kunci asing merupakan suatu filed dalam satu tabel yang harus mencocokan sebuah
Nilai Kunci Primer pada tabel lain dalam rangka membangun hubungan antara dua tabel.

Tidak seperti kunci Primer , kunci asing tidak perlu menjadi unik. Misalnya, Carlton Smith
memiliki penasihat nomor 49. Nilai 49 harus menjadi nilai yang unik dalam tabel ADVISOR
karena itu adalah kunci primer, tetapi 49 dapat muncul berulang kali pada tabel STUDENT, di
mana SEjumlah penasihat berfungsi sebagai kunci asing.
Gambar 9-12 di halaman sebelumnya juga menunjukkan bagaimana dua kunci asing dapat
berfungsi sebagai komposit primary key pada tabel lain. Pertimbangkan tabel GRADE di bagian
bawah gambar. Itu dua field yang membentuk kunci primer untuk tabel GRADE keduanya kunci
asing: the STUDENT-NUMBER, yang harus cocok dengan nomor siswa dalam tabel
STUDENT, dan yang COURSE-ID field, yang harus cocok dengan salah satu ID course dalam
tabel COURSE.
Bagaimana dua kunci asing dapat berfungsi sebagai kunci primer dalam tabel GRADE? Kapan
Anda mempelajari tabel, Anda akan melihat bahwa Student number dan Course ID dapat saja
muncul setiap beberapa kali, namun kombinasi dari seorang mahasiswa tertentu dan matakuliah
tertentu terjadi hanya sekali. Misalnya, mahasiswa 1035 muncul empat kali dan tentu saja
CSC151 muncul tiga kali - tapi hanya ada satu kejadian gabungan dari mahasiswa 1035 dan
matakuliah CSC151. Karena kombinasi dari siswa tertentu (1035) dan matakuliah tertentu
(CSC151) adalah unik, hal ini memastikan bahwa Nilai(grade) (B) akan diditerapkan untuk
mahasiswa yang tepat di jalur matakuliah.
KUNCI SEKUNDER (SCONDARY KEY) Kunci sekunder adalah field atau kombinasi field
yang dapat digunakan untuk mengakses atau mengambil Rrecord. Nilai dari kunci sekunder tidak
unik. Misalnya, jika perlu mengakses record hanya pada para pelanggan dengan kode pos
tertentu, maka akan menggunakan field kode ZIP sebagai kunci sekunder. kunci sekunder juga
dapat digunakan untuk mengurutkan atau menampilkan record dalam urutan tertentu. Sebagai
contoh, Anda bisa menggunakan Field GPA dalam File STUDENT untuk menampilkan semua
record untuk semua mahasiswa agar semua mahasiswa dalam point tingkat urutan. Kebutuhan
kunci sekunder timbul karena tabel hanya dapat memiliki satu kunci primer.
Dalam file CUSTOMER, CUSTOMER-NUMBER merupakan kunci primer, sehingga harus
unik. Anda mungkin tahu nama pelanggan, tetapi tidak nomor pelanggan. Sebagai contoh, Anda
mungkin ingin mengakses pelanggan bernama James Morgan, tapi Anda tidak tahu nomor
pelanggannya. Jika Anda mencari tabel menggunakan field CUSTOMER-NAME sebagai kunci
sekunder, Anda dapat mengambil record untuk semua pelanggan bernama James Morgan dan
Kemudian pilih yang benar.
Pada Gambar 9-12, nama mahasiswa dan nama penasihat diidentifikasi sebagai kunci sekunder,
namun field lain juga bisa digunakan. Misalnya, untuk menemukan semua mahasiswa yang
memiliki penasihat tertentu, Anda bisa menggunakan field ADVISOR-NUMBER di file
STUDENT sebagai kunci sekunder.

Integritas referensial
Pengecekan validitas dapat membantu menghindari kesalahan input data. Salah satu jenis
pengecekan validitas, disebut integritas referensial, yang merupakan seperangkat aturan yang
menghindari inkonsistensi data dan masalah kualitas. Dalam database relasional, integritas
referensial berarti bahwa nilai kunci asing tidak dapat dimasukkan dalam satu tabel kecuali
cocok dengan keseluruhan kunci primer yang ada di tabel lain. Misalnya, integritas referensial
akan mencegah Anda dari memasukan pesanan pelanggan dalam tabel pesanan kecuali bahwa
pelanggan sudah ada dalam tabel pelanggan. Tanpa integritas referensial, Anda mungkin
memiliki perintah yang disebut yatim piatu, karena itu tidak ada pelanggan terkait.
Dalam contoh yang ditunjukkan pada Gambar 9-12, integritas referensial tidak mengizinkan user
untuk memasukkan nomor advisor (nilai kunci asing) pada tabel STUDENT kecuali nomor
penasihat valid (primary value key) sudah ada dalam tabel ADVISOR.
Integritas referensial juga dapat mencegah penghapusan record jika record memiliki kunci
primer yang sesuai kunci asing di tabel lain. Misalnya, bahwa penasihat mengundurkan diri
untuk menerima posisi di sekolah lain. Anda tidak dapat menghapus penasihat dari tabel
ADVISOR sementara record dalam file STUDENT masih menyebut nomor penasihat. Jika tidak,
record STUDENT menjadi yatim. Untuk menghindari masalah, mahasiswa harus dipindahkan ke
penasihat lainnya dengan mengubah nilai dalam field ADVISOR-NUMBER ; maka record
penasihat dapat dihapus.
Ketika membuat sebuah database relasional, Anda dapat membangun integritas referensial ke
Desain. Gambar 9-13 menunjukkan layar Microsoft Access yang mengidentifikasi field umum
dan memungkinkan pengguna untuk menegakkan aturan integritas referensial.

NORMALISASI
Normalisasi adalah proses menciptakan desain tabel dengan menetapkan field tertentu atau
atribut untuk setiap tabel di dalam database. Suatu perancangan tabel menetapkan field dan
mengidentifikasi kunci primer dalam tabel tertentu atau file. Bekerja dengan satu set desain awal
tabel, Anda menggunakan normalisasi untuk mengembangkan desain database secara
keseluruhan yang sederhana, fleksibel, dan bebas dari redundansi data. Normalisasi melibatkan
penerapan seperangkat aturan yang dapat membantu Anda mengidentifikasi dan memperbaiki
masalah yang melekat dan kompleksitas dalam desain tabel. Konsep normalisasi didasarkan pada
karya Edgar Codd, seorang ilmuwan komputer Inggris yang merumuskan prinsip-prinsip dasar
perancangan relasional database.
Proses normalisasi biasanya melibatkan empat tahap: Perancangan unnormalized, bentuk normal
relasional, bentuk normal kedua, dan bentuk normal ketiga. Tiga bentuk normal mencakup
kemajuan bentuk normal ketiga yang merupakan desain terbaik. Database yang paling terkait
dengan bisnis harus dirancang dalam bentuk normal ketiga.

Format Notasi Standar

Merancang tabel lebih mudah jika menggunakan format notasi standar untuk menunjukkan
struktur tabel, field, dan kunci primer. Format notasi standar dalam contoh berikut dimulai
dengan nama tabel, diikuti oleh ekspresi kurung yang berisi nama field dipisahkan dengan koma.
Field kunci primer (s) digarisbawahi, seperti ini:
NAME (FIELD 1, FIELD2, FIELD 3)

Kelompok Berulang dan Desain unnormalized

Selama desain data, Anda harus mampu mengenali kelompok berulang dari field. Kelompok
berulang adalah satu set dari satu atau lebih field yang dapat terjadi dalam beberapa kali dalam
record tunggal, dengan setiap kejadian memiliki nilai yang berbeda. kelompok berulang sering
terjadi dalam dokumen yang disiapkan oleh pengguna. Sebagai contoh, Anggaplah formulir
pendaftaran sekolah dengan informasi siswa di bagian atas formulir, diikuti dengan daftar
matakuliah dari mahasiwa yang diambil. Jika Anda merancang sebuah tabel berdasarkan formulir
pendaftaran ini, matakuliah akan mewakili kelompok berulang dari nilai-nilai untuk setiap
mahasiswa. Contoh dari kelompok berulang ditunjukkan pada Gambar 9-22. Pertama dua record
di tabel PESANAN berisi beberapa produk, yang mewakili field kelompok berulang. Perhatikan
bahwa selain nomor urut dan tanggal, record dengan beberapa produk mengandung pengulangan
dari jumlah produk, deskripsi, dan nomor memerintahkan. Anda dapat menganggap kelompok
berulang sebagai satu set anak (anak entitas) record yang terkandung dalam induk record
(utama). Sebuah desain tabel yang berisi sekelompok berulang disebut unnormalized. Standar
Metode notasi untuk mewakili desain unnormalized adalah untuk menyertakan berulang
kelompok field dalam set kedua kurung. Contoh dari tabel unnormalized akan terlihat seperti ini:
NAME (FIELD 1, FIELD2, FIELD 3, (Mengulangi FIELD 1, mengulangi FIELD2))
Sekarang meninjau unnormalized desain tabel PESANAN ditunjukkan pada Gambar 9-22.
Berikut pedoman notasi, Anda bisa menggambarkan desain sebagai berikut:
ORDER (ORDER-NUM, ORDER-DATE, (PRODUCT-NUM, PRODUCT-DESC, NUM-
ORDER)) notasi menunjukkan bahwa desain tabel PESANAN berisi lima field, yaitu terdaftar
dalam kurung luar. Field PESANAN-NUM digarisbawahi untuk menunjukkan bahwa adalah
kunci primer. The PRODUK-NUM, PRODUK-DESC, dan NUM-MEMERINTAHKAN field
tertutup dalam sebuah set dalam kurung untuk menunjukkan bahwa mereka adalah field dalam
kelompok berulang. Perhatikan bahwa PRODUK-NUM juga digarisbawahi karena bertindak
sebagai kunci primer dari kelompok berulang. Jika pesanan pelanggan tiga produk yang berbeda
dalam satu order, repeat maka field PRODUK-NUM, PRODUK-DESC, dan NUM-
MEMERINTAHKAN tiga kali, seperti yang ditunjukkan pada Gambar 9-22 pada halaman
sebelumnya.
Bentuk Normal Pertama
Sebuah tabel adalah dalam bentuk normal pertama (1NF) jika tidak mengandung kelompok
berulang. Untuk mengubah desain unnormalized ke 1NF, Anda harus memperluas kunci primer
tabel untuk menyertakan kunci primer dari kelompok berulang.
Misalnya, pada tabel PESANAN ditunjukkan pada Gambar 9-22, kelompok berulang terdiri dari
tiga field: PRODUK-NUM, PRODUK-DESC, dan NUM-MEMERINTAHKAN. Dari tiga field,
hanya PRODUK-NUM bisa menjadi kunci primer karena unik mengidentifikasi setiap contoh
dari kelompok berulang. Deskripsi produk tidak dapat menjadi kunci primer karena mungkin
atau mungkin tidak unik. Sebagai contoh, sebuah perusahaan mungkin menjual besar jumlah
bagian dengan nama deskriptif yang sama, seperti mesin cuci, mengandalkan bagian kode nomor
untuk mengidentifikasi secara unik setiap ukuran mesin cuci.
Ketika Anda memperluas kunci primer dari tabel ORDER untuk menyertakan PRODUK-NUM,
Anda menghilangkan kelompok berulang dan tabel PESANAN sekarang di 1NF, seperti yang
ditunjukkan:
ORDER(ORDER-NUM, ORDER-DATE, PRODUCT-NUM, PRODUCT-DESC, NUM-
ORDER)
Gambar 9-23 menunjukkan tabel PESANAN di 1NF. Perhatikan bahwa ketika Anda
menghilangkan mengulangi kelompok, record tambahan muncul - satu untuk setiap kombinasi
tertentu order dan produk tertentu. Hasilnya adalah lebih record, tapi desain sangat
disederhanakan.
Dalam versi baru, kelompok berulang untuk nomor pesanan 40.311 telah menjadi tiga terpisah
record, dan kelompok berulang untuk nomor pesanan 40.312 telah menjadi dua terpisah record.
Karena itu, ketika sebuah tabel dalam 1NF, setiap record menyimpan data tentang satu contoh
dari urutan tertentu dan produk tertentu.
Juga perhatikan bahwa desain 1NF ditunjukkan pada Gambar 9-23 memiliki kunci kombinasi
primer. Kunci primer dari desain 1NF tidak bisa field PESANAN-NUM saja, karena nomor
pesanan tidak unik mengidentifikasi setiap produk dalam urutan beberapa item. Demikian pula,
PRODUK-NUM tidak bisa menjadi kunci primer, karena tampaknya lebih dari sekali jika
beberapa pesanan termasuk produk yang sama. Karena setiap record harus mencerminkan
produk tertentu dalam urutan tertentu, Anda perlu kedua field, ORDER-NUM dan PRODUK-
NUM, untuk mengidentifikasi record tunggal unik. Oleh karena itu, kunci primer adalah
kombinasi dari dua field:
PESANAN-NUM dan PRODUK-NUM.

Bentuk Normal Kedua

Untuk memahami bentuk normal kedua (2NF), Anda harus memahami konsep fungsional
ketergantungan. Misalnya, Field A secara fungsional tergantung pada Field B jika nilai Field
Sebuah tergantung pada Field B. Sebagai contoh, pada Gambar 9-23, nilai PESANAN-DATE
secara fungsional tergantung pada ORDER-NUM, karena untuk sejumlah urutan tertentu, bisa
ada hanya satu tanggal. Sebaliknya, deskripsi produk tidak tergantung pada jumlah pesanan.
Untuk Sebuah nomor urutan tertentu, mungkin ada beberapa deskripsi produk - satu untuk setiap
item dipesan.
Sebuah desain tabel dalam bentuk normal kedua (2NF) jika berada dalam 1NF dan jika semua
field yang bukan merupakan kunci primer secara fungsional tergantung pada seluruh kunci
primer. Jika ada field di tabel 1NF tergantung hanya pada satu field dalam kombinasi tombol
primer, maka tabel tidak dalam 2NF.
Perhatikan bahwa jika desain 1NF memiliki kunci primer yang hanya terdiri dari satu field,
Masalah ketergantungan parsial tidak muncul - karena seluruh kunci primer adalah tunggal field.
Karena itu, tabel 1NF dengan kunci primer-field tunggal otomatis di 2NF.
Sekarang menguji kembali desain 1NF untuk tabel PESANAN ditunjukkan pada Gambar 9-23:
PESANAN (PESANAN-NUM, PESANAN-DATE, PRODUK-NUM, PRODUK-DESC, NUM-
MEMERINTAHKAN) Ingat bahwa kunci primer adalah kombinasi dari jumlah pesanan dan
produk jumlah. Field NUM-MEMERINTAHKAN tergantung pada seluruh kunci primer, karena
NUMORDERED mengacu pada sejumlah produk tertentu dan sejumlah urutan tertentu.
Sebaliknya, ORDER-DATE field tergantung pada jumlah pesanan, yang hanya bagian dari kunci
primer. Demikian pula, field PRODUK-DESC tergantung pada jumlah produk,
yang juga hanya bagian dari primary key. Karena beberapa field tidak tergantung pada
seluruh kunci primer, desain tidak dalam 2NF.
Sebuah proses standar ada untuk mengkonversi tabel dari 1NF ke 2NF. Tujuannya adalah untuk
mematahkan tabel asli menjadi dua atau lebih tabel baru dan menetapkan kembali field sehingga
setiap
field nonkey akan tergantung pada seluruh kunci primer dalam tabel nya. Untuk mencapai hal
ini, Anda
ikuti langkah ini:
1. Pertama, membuat dan nama tabel terpisah untuk masing-masing field dalam primary key
yang ada. Misalnya, pada Gambar 9-23 pada halaman sebelumnya, kunci primer ORDER tabel
memiliki dua field, ORDER-NUM dan PRODUK-NUM, sehingga Anda harus membuat dua
tabel. Elipsis (...) menunjukkan bahwa field akan ditugaskan nanti. Hasilnya adalah:
ORDER (ORDER-NUM, ...)
PRODUCT (PRODUCT-NUM, ...)
2. Selanjutnya, membuat tabel baru untuk setiap kemungkinan kombinasi kunci primer asli field.
Dalam Gambar 9-23 misalnya, Anda akan membuat dan nama tabel baru dengan kombinasi
kunci primer ORDER-NUM dan PRODUK-NUM. tabel ini menggambarkan garis individu
dalam urutan, sehingga diberi nama PESANAN-LINE, seperti yang ditunjukkan:
ORDER-LINE (ORDER-NUM, PRODUCT-NUM, ...)
3. Akhirnya, mempelajari tiga tabel dan tempat masing-masing field dengan primer sesuai yang
kunci, yang merupakan kunci minimal yang menjadi fungsional tergantung. Ketika Anda selesai
menempatkan semua field, menghapus tabel yang tidak memiliki field tambahan ditugaskan
untuk itu. Tabel yang tersisa adalah versi 2NF dari tabel asli Anda. Di
Gambar 9-23 misalnya, tiga tabel akan ditampilkan sebagai:
PESANAN (PESANAN-NUM, ORDER-DATE)
PRODUK (PRODUCT-NUM, PRODUK-DESC)
PESANAN-LINE (PESANAN-NUM, PRODUK-NUM, NUM-MEMERINTAHKAN)
Gambar 9-24 menunjukkan desain tabel 2NF. Dengan mengikuti langkah-langkah, Anda telah
dikonversi tabel 1NF asli ke tiga tabel 2NF.
Mengapa penting untuk berpindah dari 1NF ke 2NF? Empat jenis masalah yang ditemukan
dengan desain 1NF yang tidak ada di 2NF:
Pertimbangkan pekerjaan yang diperlukan untuk mengubah deskripsi produk tertentu.
Misalkan 500 pesanan saat ini ada untuk sejumlah produk 304. Mengubah produk deskripsi
melibatkan memodifikasi 500 record untuk jumlah produk 304. Memperbarui semua 500 record
akan menjadi rumit dan mahal.
tabel 1NF dapat berisi data yang tidak konsisten. Karena seseorang harus memasukkan produk
deskripsi dalam setiap record, tidak ada yang mencegah jumlah produk 304 dari memiliki dif-
deskripsi produk ferent dalam record yang berbeda. Bahkan, jika nomor produk 304 muncul
dalam sejumlah besar record order, beberapa deskripsi produk yang cocok mungkin tidak akurat
atau tidak benar dieja.
Bahkan kehadiran atau tidak adanya tanda penghubung dalam pesanan untuk All-tujuan alat akan
menciptakan masalah konsistensi. Jika Sebuah entri data orang harus memasukkan istilah seperti
IO1 Antre Pengawas banyak sekali waktu, itu pasti ada kemungkinan bahwa beberapa
inkonsistensi akan menghasilkan.
Menambah produk baru adalah masalah. Karena kunci primer harus mencakup nomor urut dan
nomor produk, Anda perlu nilai untuk kedua field untuk menambahkan record. Apa nilai yang
Anda gunakan untuk nomor pesanan bila Anda ingin menambahkan produk baru yang belum
dipesan oleh pelanggan apapun? Anda bisa menggunakannomor pesanan boneka, dan kemudian
menggantinya dengan nomor pesanan nyata ketika Produk diperintahkan untuk memecahkan
masalah, tetapi solusi yang juga menciptakan kesulitan.
 Menghapus produk adalah masalah. Jika semua record terkait dihapus setelah sebuah
Agar diisi dan dibayar, apa yang terjadi jika Anda menghapus record hanya yang berisi
jumlah produk 633? Itu
informasi tentang nomor produk dan fiturnya
deskripsi
hilang.
Telah desain 2NF menghilangkan semua potensi masalah? Untuk mengubah deskripsi produk,
sekarang Anda dapat mengubah hanya satu PRODUK merekam. beberapa, nilai tidak konsisten
untuk itu deskripsi produk tidak mungkin karena deskripsi muncul hanya dalam satu lokasi.
Untuk menambahkan produk baru, Anda cukup membuat PRODUK baru merekam, bukannya
CRE-Ating rekor pesanan boneka. Bila Anda menghapus record terakhir PESANAN-LINE
untuk jumlah produk tertentu, Anda tidak kehilangan nomor produk dan deskripsi karena record
PRODUK masih ada. Keempat potensi masalah dieliminasi, dan tiga 2NF desain yang unggul
baik tabel unnormalized asli dan desain 1NF.

Bentuk Normal Ketiga

Aturan populer yang praktis adalah bahwa suatu desain pada bentuk 3NF jika setiap field nonkey
tergantung pada kunci, seluruh kunci, dan tidak ada yang lain selain kunci. Seperti yang akan
Anda lihat, desain 3NF menghindari redundansi dan masalah integritas data yang masih bisa ada
dalam desain 2NF.
Pertimbangan mengikuti desain tabel CUSTOMER, seperti yang ditunjukkan pada Gambar 9-25:
PELANGGAN (CUSTOMER-NUM, PELANGGAN-NAMA, ALAMAT, SALES-REP-NUM,
PENJUALAN-REP-NAMA)
tabel dalam 1NF karena tidak memiliki kelompok berulang. Desain juga berada dalam 2NF
karena kunci primer adalah satu field. Tapi tabel masih memiliki empat potensi masalah mirip
dengan empat masalah 1NF yang dijelaskan sebelumnya. Mengubah nama perwakilan penjualan
masih membutuhkan perubahan setiap record di mana muncul nama Rep-penjualan. Tidak ada
yang terkait perancangan melarang Rep-penjualan tertentu memiliki nama yang berbeda dalam
record yang berbeda. Selain itu, karena nama rep-penjualan termasuk dalam tabel CUSTOMER,
Anda harus membuat record dummy dari PELANGGAN untuk menambahkan tenaga Rep-
penjualan baru yang belum pernah ditugaskan pelanggan apapun. Pada skhirnya, jika Anda
menghapus semua record untuk pelanggan dari Rep-penjualan no 22, Anda akan kehilangan
jumlah Rep-penjualan dan nama. Masalah-masalah potensial yang disebabkan karena desain
tidak pada bentuk normal 3NF. Jka Sebuah desain tabel dalam bentuk normal ketiga (3NF) jika
berada dalam bentuk normal 2NF dan jika tidak ada field nonkey tergantung pada field nonkey
yang lain. Ingat bahwa field nonkey adalah field yang bukan merupakan kunci kandidat untuk
kunci primer. Contoh PELANGGAN pada Gambar 9-25 tidak berada dalam 3NF karena satu
dari field nonkey, NAMA -REP- PENJUALAN, tergantung di field nonkey lain yaitu SALES-
REP-NUM. Untuk mengkonversi tabel ke 3NF, Anda harus menghapus semua field dari tabel
2NF yang tergantung pada field nonkey lain dan menempatkan mereka di tabel baru yang
menggunakan field nonkey sebagai kunci primer. Dalam contoh PELANGGAN, field NAMA-
REP-PENJUALAN tergantung pada field lain, SALES-REP-NUM, yang bukan merupakan
bagian dari primary key. Oleh karena itu, untuk mencapai 3NF, Anda harus menghapus NAMA
-REP- SALES dan menempatkannya ke dalam tabel baru yang menggunakan SALES-REP-
NUM sebagai kunci primer. Seperti ditunjukkan dalam Gambar 9-26, bentuk normal ketiga
menghasilkan dua tabel terpisah:
CUSTOMER (CUSTOMER-NUM, CUSTOMER-NAME, ADDRESS, SALES-REP-NUM)
SALES-REP (SALES-REP-NUM, SALES-REP-NAME)
Sebuah Contoh Normalisasi
Untuk menunjukkan proses normalisasi, pertimbangkan situasi yang familier pada Gambar 9-27,
yang menggambarkan beberapa entitas di dalam sistem Sistem Perawalian di Kampus:
ADVISOR, COURSE, dan STUDENT. Hubungan antara tiga entitas yang ditampilkan dalam
ERD pada Gambar 9-28 di halaman berikutnya. Bagian berikut membahas aturan normalisasi
untuk tiga entitas tersebut. Sebelum Anda memulai proses normalisasi, Anda lihat Tabel
STUDENT berisi field yang berhubungan dengan ADVISOR dan entitas COURSE, sehingga
putuskan untuk mulai dengan desain awal untuk tabel STUDENT, yang ditunjukkan pada
Gambar 9-29. Perhatikan bahwa desain tabel termasuk jumlah siswa, nama siswa, jumlah kredit
diambil, nilai rata-rata (IPK), jumlah penasihat, nama penasihat, dan, untuk setiap kursus siswa
telah diambil, jumlah saja, deskripsi saja, jumlah kredit, dan kelas diterima.
Tabel STUDENT pada Gambar 9-29 pada halaman berikutnya adalah unnormalized, karena
memiliki kelompok berulang. Itu tabel SISWA Desain dapat ditulis sebagai:
STUDENT(STUDENT-NUMBER, STUDENT-NAME, TOTAL-CREDIT, GPA, ADVISOR-
NUMBER, ADVISOR-NAME, (COURSE-NUMBER, COURSE-DESC, NUM-KREDIT,
GRADE)) Untuk mengkonversi record STUDENT ke 1NF, Anda harus memperluas kunci
primer untuk memasukkan kunci dari kelompok berulang, Menghasilkan:
STUDENT(STUDENT-NUMBER, STUDENT-NAME, TOTAL-CREDIT, GPA, ADVISOR-
NUMBER, ADVISOR-NAME, COURSE-NUMBER, COURSE-DESC, NUM-KREDIT,
GRADE)
Gambar 9-30 menunjukkan versi 1NF dari data sampel STUDENT. Apakah salah satu field
dalam record STUDENT pada 1NF tergantung pada hanya sebagian dari primary key? nama
siswa, jumlah kredit, IPK, nomer penasihat, dan nama penasihat semua hanya berhubungan
dengan no siswa dan tidak memiliki hubungan dengan no kursus. Deskripsi Kursus tergantung
pada nomor kursus saja, tapi tidak pada nomor siswa. Hanya GRADE yang field tergantung pada
seluruh kunci primer.
Sesuai dengan 1NF --2NF proses konversi dijelaskan sebelumnya, Anda akan membuat tabel
baru untuk setiap field dan kombinasi field dalam kunci primer, dan menempatkan field lainnya
dengan kunci yang sesuai mereka. Hasilnya adalah:
STUDENT(STUDENT-NUMBER, STUDENT-NAME, TOTAL-CREDIT, GPA, ADVISOR-
NUMBER, ADVISOR-NAME)
COURSE(COURSE-NUMBER, COURSE-DESC, NUM-KREDIT)
GRADE (STUDENT-NUMBER, COURSE NUMBER, GRADE)

Anda sekarang telah mengkonversi tabel STUDENT 1NF asli untuk tiga tabel, yang semuanya
dalam 2NF. Pada tiap tabel, setiap field nonkey tergantung pada seluruh kunci primer.
Gambar 9-31 pada halaman 420 menunjukkan 2NF STUDENT, KURSUS, dan desain GRADE
dan data sampel. Apakah semua tiga tabel di 3NF? The KURSUS dan GRADE berada di 3NF.
STUDENT tidak dalam 3NF, namun, karena field ADVISOR-NAMA tergantung pada

ADVISOR-NUMBER field, yang bukan bagian dari Kunci Primer STUDENT. Untuk mengubah
STUDENT ke 3NF, hapus field ADVISOR-NAME dari tabel STUDENT dan tempatkan ke
tabel dengan ADVISOR-NUMBER sebagai kunci primer. Gambar 9-32 pada halaman 421
menunjukkan versi 3NF dari data sampel untuk STUDENT, ADVISOR, COURSE, dan GRADE.
Desain 3NF akhir adalah:
STUDENT(STUDENT-NUMBER, STUDENT NAME, TOTAL-CREDIT, GPA, ADVISOR-
NUMBER):
ADVISOR (ADVISOR-NUMBER, ADVISOR-NAME)
COURSE(COURSE-NUMBER, COURSE-DESC, NUM-CREDITS)
GRADE (STUDENT-NUMBER, COURSE-NUMBER, GRADE)
Gambar 9-33 pada halaman 422 menunjukkan ERD lengkap setelah normalisasi. Sekarang
disana empat entitas: STUDENT, ADVISOR, KURSUS, dan GRADE, yang merupakan asosiatif
kesatuan. Jika Anda kembali ke Gambar 9-28 pada halaman 418, yang diambil sebelum Anda
diidentifikasi GRADE sebagai suatu entitas, Anda dapat melihat bahwa M: N hubungan antara
STUDENT dan KURSUS telah diubah menjadi dua 1: hubungan M: satu hubungan antara
MAHASISWA dan GRADE dan hubungan lainnya antara KURSUS dan GRADE. Untuk
membuat desain 3NF, Anda harus memahami sifat pertama, kedua, dan ketiga bentuk normal.
Dalam pekerjaan Anda sebagai analis sistem, Anda akan menemukan desain yang jauh lebih
kompleks daripada contoh dalam bab ini. Anda juga harus tahu bahwa yang normal bentuk luar
3NF ada, tapi mereka jarang digunakan dalam sistem berorientasi bisnis.