Sebuah database yang dirancang dengan baik memberikan akses kepada Anda untuk informasi yang terkini dan akurat. Karena desain yang tepat sangat penting untuk mencapai tujuan Anda dalam bekerja dengan database, maka menginvestasikan waktu yang diperlukan untuk mempelajari prinsip-prinsip desain yang baik adalah langkah yang bijaksana. Pada akhirnya, Anda akan jauh lebih mungkin memiliki database yang sesuai dengan kebutuhan Anda dan dapat dengan mudah menyesuaikan perubahan.

Database mengorganisir informasi Anda ke dalam tabel: yaitu daftar baris dan kolom. Dalam database yang sederhana, Anda mungkin hanya memiliki satu tabel. Namun, untuk sebagian besar database, Anda akan membutuhkan lebih dari satu tabel. Sebagai contoh, Anda mungkin memiliki satu tabel yang menyimpan informasi tentang produk, tabel lain yang menyimpan informasi tentang pesanan, dan tabel lainnya dengan informasi tentang pelanggan.

Image depicting three tables in datasheets

Setiap baris lebih tepatnya disebut sebagai record, dan setiap kolom disebut sebagai field. Record adalah cara yang bermakna dan konsisten untuk menggabungkan informasi tentang sesuatu. Field adalah satu item informasi tunggal - jenis item yang muncul dalam setiap record. Pada tabel Produk, misalnya, setiap baris atau record akan menyimpan informasi tentang satu produk. Setiap kolom atau field menyimpan beberapa jenis informasi tentang produk tersebut, seperti nama atau harga.

Ada beberapa prinsip yang mengarahkan proses desain database. Prinsip pertama adalah bahwa informasi duplikat (juga disebut data redundan) adalah hal yang buruk, karena membuang-buang ruang dan meningkatkan kemungkinan kesalahan dan inkonsistensi. Prinsip kedua adalah kebenaran dan kelengkapan informasi yang penting. Jika database Anda berisi informasi yang salah, maka laporan apa pun yang mengambil informasi dari database juga akan mengandung informasi yang salah. Akibatnya, keputusan apa pun yang Anda buat berdasarkan laporan-laporan tersebut akan salah.

Desain database yang baik, oleh karena itu, adalah desain yang:

  1. Memisahkan informasi Anda ke dalam tabel berbasis subjek untuk mengurangi data yang redundan.
  2. Memberikan akses dengan informasi yang diperlukan untuk menggabungkan informasi di tabel-tabel sesuai kebutuhan.
  3. Membantu mendukung dan memastikan akurasi serta integritas informasi Anda.
  4. Menyesuaikan dengan kebutuhan pemrosesan dan pelaporan data Anda.

Proses desain terdiri dari langkah-langkah berikut:

1. Tentukan tujuan database Anda

   Langkah ini membantu mempersiapkan Anda untuk langkah-langkah selanjutnya.

2. Temukan dan atur informasi yang diperlukan

   Kumpulkan semua jenis informasi yang ingin Anda catat dalam database, seperti nama produk dan nomor pesanan.

3. Bagi informasi ke dalam tabel

   Pisahkan item-item informasi Anda menjadi entitas utama atau subjek, seperti Produk atau Pesanan. Setiap subjek kemudian menjadi sebuah tabel.

4. Ubah item-item informasi menjadi kolom

   Tentukan informasi apa yang ingin Anda simpan di setiap tabel. Setiap item menjadi sebuah field, dan ditampilkan sebagai kolom dalam tabel. Misalnya, tabel Karyawan mungkin mencakup field seperti Nama Belakang dan Tanggal Penggajian.

5. Tetapkan kunci utama (primary keys)

   Pilih kunci utama (primary key) untuk setiap tabel. Kunci utama adalah kolom yang digunakan untuk mengidentifikasi setiap baris secara unik. Contohnya bisa berupa ID Produk atau ID Pesanan.

6. Atur hubungan antar tabel

   Tinjau setiap tabel dan tentukan bagaimana data dalam satu tabel berhubungan dengan data dalam tabel lainnya. Tambahkan field ke tabel atau buat tabel baru untuk menjelaskan hubungan-hubungan tersebut, jika perlu.

7. Perbaiki desain Anda

   Analisis desain Anda untuk mencari kesalahan. Buat tabel-tabel dan tambahkan beberapa data contoh. Lihat apakah Anda dapat mendapatkan hasil yang Anda inginkan dari tabel-tabel Anda. Lakukan penyesuaian pada desain, jika diperlukan.

8. Terapkan aturan normalisasi

   Terapkan aturan normalisasi data untuk melihat apakah tabel-tabel Anda terstruktur dengan benar. Lakukan penyesuaian pada tabel-tabel, jika perlu.

Menentukan tujuan dari database Anda

Tuliskan tujuan dari database di atas kertas, yang terdiri dari: - tujuannya, bagaimana Anda berharap menggunakannya, dan siapa yang akan menggunakannya. Untuk database kecil untuk bisnis berbasis rumah, misalnya, Anda mungkin menulis sesuatu yang sederhana seperti "Database pelanggan menyimpan daftar informasi pelanggan untuk tujuan membuat pengiriman surat dan laporan." Jika database lebih kompleks atau digunakan oleh banyak orang, seperti yang sering terjadi dalam lingkungan perusahaan, tujuannya bisa menjadi satu paragraf atau lebih dan harus mencakup kapan dan bagaimana setiap orang akan menggunakan database tersebut. Fungsinya adalah untuk memiliki pernyataan misi yang baik yang dapat digunakan sebagai panduan sepanjang proses desain. Memiliki pernyataan seperti ini membantu Anda berfokus pada tujuan Anda ketika membuat keputusan.

Menemukan dan Mengatur Informasi yang Diperlukan

Untuk menemukan dan mengatur informasi yang diperlukan, mulailah dengan informasi yang sudah ada. Misalnya, Anda mungkin mencatat pesanan pembelian dalam buku besar atau menyimpan informasi pelanggan pada formulir kertas dalam lemari arsip. Kumpulkan dokumen-dokumen tersebut dan daftar setiap jenis informasi yang tertera (misalnya, setiap kotak yang Anda isi pada suatu formulir). Jika Anda tidak memiliki formulir yang sudah ada, bayangkan saja bahwa Anda harus merancang sebuah formulir untuk mencatat informasi pelanggan. Informasi apa yang akan Anda masukkan ke dalam formulir? Kotak-kotak apa yang akan Anda buat? Identifikasi dan daftar setiap item tersebut. Sebagai contoh, misalkan Anda saat ini menyimpan daftar pelanggan pada kartu indeks. Meninjau kartu-kartu ini mungkin menunjukkan bahwa setiap kartu berisi nama pelanggan, alamat, kota, provinsi, kode pos, dan nomor telepon. Setiap item ini mewakili kolom potensial dalam sebuah tabel.

Saat Anda menyusun daftar ini, jangan khawatir tentang kesempurnaannya pada awalnya. Sebaliknya, daftarlah setiap item yang terlintas dalam pikiran Anda. Jika orang lain akan menggunakan database, mintalah pendapat mereka juga. Anda bisa menyempurnakan daftar tersebut nanti.

Selanjutnya, pertimbangkan jenis laporan atau pengiriman surat yang mungkin ingin Anda hasilkan dari database. Misalnya, Anda mungkin ingin laporan penjualan produk untuk menunjukkan penjualan berdasarkan wilayah, atau laporan ringkasan inventaris yang menunjukkan tingkat inventaris produk. Anda mungkin juga ingin menghasilkan surat formulir untuk dikirim ke pelanggan yang mengumumkan acara penjualan atau menawarkan hadiah. Rancanglah laporan tersebut dalam pikiran Anda, dan bayangkan bagaimana tampilannya. Informasi apa yang akan Anda masukkan ke dalam laporan? Daftarkan setiap item. Lakukan hal yang sama untuk surat formulir dan untuk setiap laporan lain yang Anda perkirakan akan dibuat.

a person imagining a product inventory report

Mempertimbangkan laporan dan pengiriman surat yang mungkin ingin Anda buat membantu Anda mengidentifikasi item-item yang akan Anda butuhkan dalam database Anda. Sebagai contoh, misalkan Anda memberikan pelanggan kesempatan untuk memilih (atau tidak memilih) untuk menerima pembaruan e-mail berkala, dan Anda ingin mencetak daftar mereka yang telah memilih untuk menerima pembaruan tersebut. Untuk mencatat informasi tersebut, Anda menambahkan kolom "Kirim e-mail" ke tabel pelanggan. Untuk setiap pelanggan, Anda dapat mengatur field tersebut menjadi Ya atau Tidak.

Kebutuhan untuk mengirim pesan e-mail ke pelanggan menunjukkan item lain yang perlu dicatat. Setelah Anda tahu bahwa seorang pelanggan ingin menerima pesan e-mail, Anda juga perlu mengetahui alamat e-mail yang akan digunakan untuk mengirim pesan tersebut. Oleh karena itu, Anda perlu mencatat alamat e-mail untuk setiap pelanggan.

Merancang prototipe dari setiap laporan atau daftar output adalah langkah yang bijaksana untuk mempertimbangkan item-item yang Anda butuhkan untuk menghasilkan laporan tersebut. Misalnya, ketika Anda memeriksa surat formulir, beberapa hal mungkin terlintas dalam pikiran. Jika Anda ingin menyertakan sapaan yang benar - misalnya, string "Tuan", "Nyonya" atau "Nona" yang memulai sebuah sapaan, Anda harus membuat sebuah item sapaan. Selain itu, Anda mungkin biasanya memulai surat dengan "Dear Tuan Smith", daripada "Dear. Tuan Sylvester Smith". Ini menunjukkan bahwa Anda biasanya ingin menyimpan nama belakang terpisah dari nama depan.

Poin penting yang perlu diingat adalah Anda harus memecah setiap informasi menjadi bagian-bagian terkecil yang berguna. Dalam kasus nama, untuk membuat nama belakang mudah diakses, Anda akan memecah nama menjadi dua bagian - Nama Depan dan Nama Belakang. Untuk mengurutkan laporan berdasarkan nama belakang, misalnya, berguna untuk menyimpan nama belakang pelanggan terpisah. Secara umum, jika Anda ingin mengurutkan, mencari, menghitung, atau melaporkan berdasarkan suatu item informasi, Anda harus meletakkan item tersebut dalam field terpisah.

Pikirkan tentang pertanyaan-pertanyaan yang mungkin ingin dijawab oleh database. Misalnya, berapa banyak penjualan produk unggulan Anda yang berhasil ditutup bulan lalu? Di mana tinggal pelanggan terbaik Anda? Siapa pemasok untuk produk terlaris Anda? Mengantisipasi pertanyaan-pertanyaan ini membantu Anda menetapkan item-item tambahan yang perlu dicatat.

Setelah mengumpulkan informasi ini, Anda siap untuk langkah selanjutnya.

Membagi Informasi Menjadi Tabel

Untuk membagi informasi ke dalam tabel, pilih entitas utama atau subjek. Sebagai contoh, setelah menemukan dan mengorganisir informasi untuk database penjualan produk, daftar awal mungkin terlihat seperti berikut:

Handwritten information items grouped into subjects

1. Customer (Pelanggan)

   - CustomerID (ID Pelanggan)

   - FirstName (Nama Depan)

   - LastName (Nama Belakang)

   - Address (Alamat)

   - City (Kota)

   - State (Provinsi)

   - PostalCode (Kode Pos)

   - Email (Alamat E-mail)

   - SendEmail (Kirim E-mail)


2. Product (Produk)

   - ProductID (ID Produk)

   - ProductName (Nama Produk)

   - Category (Kategori)

   - Price (Harga)

   - StockQuantity (Kuantitas Stok)


3. Order (Pesanan)

   - OrderID (ID Pesanan)

   - CustomerID (ID Pelanggan)

   - OrderDate (Tanggal Pesanan)

   - TotalAmount (Total Jumlah)


4. OrderItem (Item Pesanan)

   - OrderItemID (ID Item Pesanan)

   - OrderID (ID Pesanan)

   - ProductID (ID Produk)

   - Quantity (Kuantitas)

   - Subtotal (Subtotal)


Setelah membagi informasi ke dalam entitas utama ini, Anda dapat membuat tabel terpisah untuk masing-masingnya. Hal ini memungkinkan Anda untuk menyimpan data secara terorganisir dan menghindari duplikasi informasi yang tidak perlu. Hubungan antara tabel-tabel ini nantinya akan membantu Anda mengambil informasi yang Anda butuhkan dengan lebih efisien. Proses ini adalah bagian penting dalam merancang struktur database yang baik dan efisien.

Entitas utama yang ditunjukkan di sini adalah produk, pemasok, pelanggan, dan pesanan. Oleh karena itu, masuk akal untuk memulai dengan empat tabel ini: satu untuk fakta tentang produk, satu untuk fakta tentang pemasok, satu untuk fakta tentang pelanggan, dan satu untuk fakta tentang pesanan. Meskipun ini belum menyelesaikan daftar, itu adalah titik awal yang bagus. Anda dapat terus menyempurnakan daftar ini sampai Anda memiliki desain yang berfungsi dengan baik.

Ketika Anda pertama kali meninjau daftar awal item, Anda mungkin tergoda untuk menempatkannya semua dalam satu tabel, bukan empat seperti yang ditunjukkan dalam ilustrasi sebelumnya. Anda akan belajar di sini mengapa itu adalah ide yang buruk. Pertimbangkan sejenak, tabel yang ditunjukkan di sini:

Image showing table that contains both products and suppliers

Dalam kasus ini, setiap baris dalam tabel berisi informasi tentang produk dan pemasoknya. Namun, desain ini memiliki beberapa masalah. Pertama, desain ini menyebabkan adanya data yang berulang-ulang karena Anda mungkin memiliki banyak produk dari satu pemasok, yang berarti nama dan alamat pemasok diulang beberapa kali dan membuang-buang ruang disk. Untuk mengatasi hal ini, lebih baik untuk mencatat informasi pemasok hanya satu kali dalam tabel terpisah yang disebut Tabel Pemasok (Suppliers) dan kemudian menghubungkannya dengan Tabel Produk (Products).

Masalah kedua dengan desain ini muncul ketika Anda perlu mengubah informasi tentang pemasok. Misalnya, jika Anda perlu mengubah alamat pemasok, Anda harus mengubahnya di beberapa tempat yang berbeda, yang dapat menyebabkan kesalahan dan ketidaksesuaian data. Dengan menyimpan alamat pemasok hanya dalam satu tempat, yaitu Tabel Pemasok (Suppliers), masalah ini dapat diatasi.

Ketika merancang database, penting untuk mencatat setiap fakta hanya sekali. Jika Anda menemukan bahwa Anda mengulang informasi yang sama di beberapa tempat, seperti alamat pemasok tertentu, lebih baik meletakkan informasi tersebut dalam tabel terpisah.

Selain itu, pertimbangkan skenario di mana Anda memiliki satu produk yang dipasok oleh satu pemasok saja. Jika Anda ingin menghapus data produk tetapi tetap mempertahankan informasi nama dan alamat pemasok, Anda tidak dapat melakukannya dalam desain saat ini. Karena setiap catatan dalam tabel berisi fakta tentang produk dan pemasok, Anda tidak dapat menghapus salah satunya tanpa menghapus yang lainnya. Untuk memisahkan fakta-fakta ini, Anda perlu memisahkan satu tabel menjadi dua: satu tabel untuk informasi produk dan satu tabel untuk informasi pemasok. Menghapus catatan produk hanya akan menghapus fakta tentang produk itu sendiri, sementara fakta tentang pemasok tetap tidak terpengaruh.

Secara keseluruhan, ketika memilih subjek yang direpresentasikan oleh sebuah tabel, pastikan bahwa kolom dalam tabel tersebut hanya menyimpan fakta tentang subjek tersebut. Misalnya, tabel produk harus hanya berisi fakta tentang produk, sementara informasi terkait pemasok harus disimpan dalam tabel pemasok. Pendekatan ini membantu menjaga integritas data, mengurangi pengulangan data, dan memudahkan pengelolaan data.

Mengubah Informasi Menjadi Kolom

Untuk menentukan kolom-kolom dalam sebuah tabel, tentukan informasi apa yang perlu Anda catat tentang subjek yang terdapat dalam tabel tersebut. Sebagai contoh, untuk tabel Pelanggan, Nama, Alamat, Kota-Provinsi-Kode Pos, Kirim E-mail, Sapaan, dan Alamat E-mail merupakan daftar awal yang baik untuk kolom-kolom. Setiap catatan dalam tabel berisi set kumpulan kolom yang sama, sehingga Anda dapat menyimpan informasi Nama, Alamat, Kota-Provinsi-Kode Pos, Kirim E-mail, Sapaan, dan Alamat E-mail untuk setiap catatan. Misalnya, kolom alamat berisi alamat pelanggan. Setiap catatan berisi data tentang satu pelanggan, dan kolom alamat berisi alamat untuk pelanggan tersebut.

Setelah Anda menentukan kumpulan awal kolom untuk setiap tabel, Anda dapat menyempurnakan kolom-kolom tersebut lebih lanjut. Misalnya, masuk akal untuk menyimpan nama pelanggan sebagai dua kolom terpisah: nama depan dan nama belakang, sehingga Anda dapat melakukan pengurutan, pencarian, dan indeksasi hanya pada kolom-kolom tersebut. Demikian pula, alamat sebenarnya terdiri dari lima komponen terpisah, yaitu alamat, kota, provinsi, kode pos, dan negara/wilayah, dan lebih baik untuk menyimpannya dalam kolom-kolom terpisah. Jika Anda ingin melakukan pencarian, filter, atau pengurutan berdasarkan provinsi, misalnya, Anda memerlukan informasi provinsi yang tersimpan dalam kolom terpisah.

Anda juga perlu mempertimbangkan apakah database akan menyimpan informasi yang berasal dari dalam negeri saja, atau juga dari luar negeri. Misalnya, jika Anda berencana menyimpan alamat internasional, lebih baik memiliki kolom Wilayah (Region) daripada Kolom Provinsi (State), karena kolom semacam itu dapat mencakup baik provinsi dalam negeri maupun wilayah di negara/wilayah lain. Demikian pula, Kolom Kode Pos (Postal Code) lebih tepat daripada Kolom Kode Pos (Zip Code) jika Anda berencana menyimpan alamat internasional.

Berikut adalah beberapa tips untuk menentukan kolom-kolom Anda:

1. Jangan sertakan data yang dihitung

   Dalam kebanyakan kasus, Anda tidak perlu menyimpan hasil perhitungan dalam tabel. Sebagai gantinya, lakukan perhitungan dalam fungsi-fungsi di kode program.

2. Simpan informasi dalam bagian logis terkecil

   Anda mungkin tergoda untuk memiliki satu field untuk nama lengkap, atau untuk nama produk beserta deskripsinya. Jika Anda menggabungkan lebih dari satu jenis informasi dalam satu field, akan sulit untuk mengambil fakta-fakta individu kemudian. Cobalah untuk memecah informasi menjadi bagian-bagian logis; misalnya, buat field terpisah untuk nama depan dan nama belakang, atau untuk nama produk, kategori, dan deskripsi.

Image showing information items during design process

Setelah Anda menyempurnakan kolom-kolom data dalam setiap tabel, Anda siap untuk memilih kunci utama (primary key) untuk setiap tabel.

Kunci utama adalah kolom atau sekumpulan kolom dalam sebuah tabel yang secara unik mengidentifikasi setiap baris dalam tabel tersebut. Kunci utama sangat penting karena membantu memastikan bahwa setiap catatan memiliki identitas yang unik dan tidak ada duplikasi data dalam tabel. Selain itu, kunci utama juga berfungsi sebagai acuan untuk membangun hubungan antara tabel-tabel dalam database.

Berikut adalah beberapa tips untuk memilih kunci utama untuk setiap tabel:

  1. Unik: Pastikan kunci utama memiliki nilai yang unik untuk setiap baris dalam tabel. Dengan cara ini, Anda dapat dengan mudah mengidentifikasi setiap catatan secara unik.
  2. Stabil: Pilihlah kolom yang stabil dan tidak berubah-ubah untuk menjadi kunci utama. Kunci utama sebaiknya tidak berubah seiring waktu, sehingga dapat menjadi referensi yang konsisten dalam database.
  3. Singkat: Pilihlah kunci utama yang relatif singkat dan mudah dibaca. Kunci utama yang panjang atau kompleks dapat menyulitkan dalam proses pengelolaan dan pemahaman data.
  4. Integritas Data: Pastikan kunci utama tidak boleh memiliki nilai NULL, karena kunci utama harus selalu memiliki nilai untuk setiap baris.

Beberapa contoh kunci utama yang umum digunakan adalah ID (identifier) atau kode unik yang diberikan kepada setiap baris, seperti CustomerID untuk tabel Pelanggan, ProductID untuk tabel Produk, dan OrderID untuk tabel Pesanan.

Setelah Anda memilih kunci utama untuk setiap tabel, pastikan bahwa kunci tersebut telah diatur dengan benar dalam struktur tabel dan sudah mengikuti prinsip-prinsip yang telah disebutkan di atas. Kunci utama yang tepat akan membantu memastikan integritas data dan mempermudah operasi database secara keseluruhan.

Memilih Primary Key

Setiap tabel harus mencakup kolom atau sekumpulan kolom yang secara unik mengidentifikasi setiap baris yang disimpan dalam tabel. Ini sering kali merupakan nomor identifikasi unik, seperti nomor ID karyawan atau nomor seri. Dalam istilah basis data, informasi ini disebut sebagai kunci utama (primary key) dari tabel. Access menggunakan kolom kunci utama untuk dengan cepat menghubungkan data dari berbagai tabel dan menggabungkan data tersebut untuk Anda.

Jika Anda sudah memiliki identifikasi unik untuk sebuah tabel, seperti nomor produk yang secara unik mengidentifikasi setiap produk dalam katalog Anda, Anda dapat menggunakan identifikasi tersebut sebagai kunci utama tabel - tetapi hanya jika nilai dalam kolom ini selalu berbeda untuk setiap catatan. Anda tidak dapat memiliki nilai duplikat dalam kunci utama. Misalnya, jangan gunakan nama orang sebagai kunci utama, karena nama-nama tersebut tidak unik. Anda dengan mudah dapat memiliki dua orang dengan nama yang sama dalam tabel yang sama.

Sebuah kunci utama selalu harus memiliki nilai. Jika nilai kolom dapat menjadi tidak terisi atau tidak diketahui (nilai yang hilang) pada suatu waktu, maka kolom tersebut tidak dapat digunakan sebagai komponen dalam kunci utama.

Anda selalu harus memilih kunci utama yang nilainya tidak akan berubah. Dalam sebuah database yang menggunakan lebih dari satu tabel, kunci utama tabel dapat digunakan sebagai referensi di tabel lain. Jika kunci utama berubah, perubahan tersebut juga harus diterapkan di mana pun kunci tersebut dijadikan referensi. Menggunakan kunci utama yang tidak akan berubah mengurangi kemungkinan kunci utama menjadi tidak sesuai dengan tabel-tabel lain yang mengacu padanya.

Seringkali, nomor unik acak digunakan sebagai kunci utama. Misalnya, Anda dapat menetapkan setiap pesanan nomor pesanan unik. Nomor pesanan hanya berfungsi untuk mengidentifikasi sebuah pesanan. Setelah ditetapkan, nomor pesanan tidak pernah berubah.

Jika Anda tidak memiliki kolom atau sekumpulan kolom yang cocok sebagai kunci utama, pertimbangkan untuk menggunakan kolom dengan tipe data AutoNumber. Ketika Anda menggunakan tipe data AutoNumber, Access secara otomatis menetapkan nilai untuk Anda. Identifikasi semacam ini tidak mengandung informasi faktual; tidak mengandung informasi faktual yang menggambarkan baris yang diwakilinya. Identifikasi tanpa fakta ideal digunakan sebagai kunci utama karena nilainya tidak berubah. Sebuah kunci utama yang berisi fakta tentang sebuah baris - seperti nomor telepon atau nama pelanggan, misalnya - lebih mungkin berubah, karena informasi faktual itu sendiri mungkin berubah.

Image showing Products table with primary key field.

Kolom yang diatur dengan tipe data AutoNumber sering menjadi kunci utama (primary key) yang baik. Tidak ada dua nomor ID produk yang sama.

Dalam beberapa kasus, Anda mungkin ingin menggunakan dua atau lebih kolom yang, bersama-sama, menyediakan kunci utama dari sebuah tabel. Sebagai contoh, tabel Order Details yang menyimpan item-item garis untuk pesanan akan menggunakan dua kolom dalam kunci utamanya: Order ID dan Product ID. Ketika sebuah kunci utama menggunakan lebih dari satu kolom, hal ini juga disebut sebagai kunci gabungan (composite key).

Untuk basis data penjualan produk, Anda dapat membuat kolom AutoNumber untuk masing-masing tabel sebagai kunci utamanya: ProductID untuk tabel Produk, OrderID untuk tabel Pesanan, CustomerID untuk tabel Pelanggan, dan SupplierID untuk tabel Pemasok.

Membuat Relasi Tabel

Dalam database yang dirancang dengan baik, Anda dapat menggunakan kueri, formulir, dan laporan untuk menggabungkan informasi dari beberapa tabel dan menyajikannya secara bermakna dan terorganisir. Kueri digunakan untuk mengambil dan menggabungkan data dari tabel-tabel yang berbeda berdasarkan kriteria tertentu. Formulir menyediakan antarmuka bagi pengguna untuk melihat dan memasukkan data, dan mereka dapat menampilkan informasi dari beberapa tabel secara bersamaan. Laporan memungkinkan Anda untuk memformat dan menyimpulkan data dari beberapa tabel secara terstruktur untuk dicetak atau dilihat.

Sebagai contoh, mari kita katakan Anda memiliki database dengan tabel Produk, Pesanan, dan Pelanggan. Anda dapat membuat kueri untuk mengambil semua pesanan yang dibuat oleh pelanggan tertentu, menampilkan detail yang relevan seperti nama produk, jumlah, dan tanggal pesanan. Anda juga dapat merancang formulir yang memungkinkan Anda untuk melihat dan mengedit informasi untuk pelanggan tertentu, menampilkan data dari tabel Pelanggan beserta data terkait dari tabel lain, seperti riwayat pesanan mereka. Terakhir, Anda dapat membuat laporan yang merangkum total penjualan berdasarkan kategori produk, mengambil data dari kedua tabel Produk dan Pesanan.

Kemampuan untuk menggabungkan data dari tabel-tabel yang berbeda memungkinkan Anda untuk menganalisis, mengorganisir, dan menyajikan informasi secara berguna dan bermakna sesuai dengan kebutuhan bisnis Anda. Ini adalah salah satu keuntungan utama dari database relasional yang terstruktur dengan baik.

Image of orders form

  1. Informasi dalam formulir ini berasal dari tabel Pelanggan...

  2. ...tabel Karyawan...

  3. ...tabel Pesanan...

  4. ...tabel Produk...

  5. ...dan tabel Detil Pesanan.

Dalam database relasional, Anda membagi informasi menjadi tabel-tabel terpisah berdasarkan subjek. Kemudian, Anda menggunakan hubungan tabel untuk menggabungkan informasi sesuai kebutuhan.

Membuat One-to-Many Relationship

Pertimbangkan contoh ini: tabel Pemasok (Suppliers) dan tabel Produk (Products) dalam database pesanan produk. Seorang pemasok dapat menyuplai banyak produk. Dengan demikian, untuk setiap pemasok yang terdapat dalam tabel Pemasok, dapat ada banyak produk yang diwakili dalam tabel Produk. Hubungan antara tabel Pemasok dan tabel Produk adalah, oleh karena itu, hubungan satu-ke-banyak (one-to-many relationship).

Dalam hubungan satu-ke-banyak, satu baris dalam tabel A dapat berhubungan dengan banyak baris dalam tabel B, tetapi sebaliknya, satu baris dalam tabel B hanya berhubungan dengan satu baris dalam tabel A. Dalam contoh ini, satu pemasok (dari tabel Pemasok) dapat menyuplai banyak produk (dalam tabel Produk), tetapi setiap produk hanya berhubungan dengan satu pemasok.

Ini adalah salah satu jenis hubungan yang umum ditemukan dalam database relasional, dan hal ini memungkinkan untuk mengorganisir dan menyimpan data yang berkaitan secara efisien. Hubungan ini memungkinkan kita untuk menggunakan data dari dua tabel terkait untuk melihat dan menganalisis informasi secara terintegrasi, sehingga membantu dalam manajemen pesanan produk.

One to many conceptual

Untuk merepresentasikan hubungan satu-ke-banyak dalam desain database Anda, ambil kunci utama pada sisi "satu" dari hubungan dan tambahkan sebagai kolom tambahan ke tabel pada sisi "banyak" dari hubungan. Dalam contoh ini, misalnya, Anda menambahkan kolom Supplier ID dari tabel Pemasok ke tabel Produk. Access kemudian dapat menggunakan nomor ID pemasok dalam tabel Produk untuk mencari pemasok yang tepat untuk setiap produk.

Kolom Supplier ID dalam tabel Produk disebut sebagai kunci asing (foreign key). Kunci asing adalah kunci utama dari tabel lain. Kolom Supplier ID dalam tabel Produk adalah kunci asing karena itu juga merupakan kunci utama dalam tabel Pemasok.

Image showing information items during design process

Anda menyediakan dasar untuk menggabungkan tabel-tabel terkait dengan menetapkan pasangan kunci utama dan kunci asing. Jika Anda tidak yakin tabel mana yang harus berbagi kolom yang sama, mengidentifikasi hubungan satu-ke-banyak memastikan bahwa kedua tabel yang terlibat memang memerlukan kolom bersama.

Dalam hubungan satu-ke-banyak, kolom kunci asing dalam tabel "banyak" mengacu pada nilai kunci utama dari tabel "satu." Hal ini memungkinkan Access untuk dengan mudah menghubungkan data dari kedua tabel berdasarkan nilai kunci tersebut.

Misalnya, dalam contoh hubungan antara tabel Pemasok (Suppliers) dan tabel Produk (Products), Supplier ID adalah kunci utama dalam tabel Pemasok dan juga kunci asing dalam tabel Produk. Dengan adanya hubungan ini, Anda dapat menghubungkan produk dengan pemasok yang sesuai berdasarkan nilai Supplier ID yang sama di kedua tabel.

Menggunakan hubungan satu-ke-banyak memungkinkan Anda untuk merancang database dengan cara yang efisien dan menghindari redundansi data. Ini adalah prinsip dasar dalam desain database relasional, dan membantu membangun struktur database yang lebih terorganisir dan mudah diakses.

Membuat Many-to-Many Relationship

Pertimbangkan hubungan antara tabel Produk (Products) dan tabel Pesanan (Orders).

Satu pesanan dapat mencakup lebih dari satu produk. Di sisi lain, satu produk dapat muncul dalam banyak pesanan. Oleh karena itu, untuk setiap catatan dalam tabel Pesanan, dapat ada banyak catatan dalam tabel Produk. Dan untuk setiap catatan dalam tabel Produk, dapat ada banyak catatan dalam tabel Pesanan. Jenis hubungan ini disebut sebagai hubungan banyak-ke-banyak (many-to-many relationship) karena untuk setiap produk, dapat ada banyak pesanan; dan untuk setiap pesanan, dapat ada banyak produk. Perhatikan bahwa untuk mendeteksi hubungan banyak-ke-banyak antara tabel-tabel Anda, penting bagi Anda untuk mempertimbangkan kedua sisi hubungan.

Subjek dari kedua tabel - pesanan dan produk - memiliki hubungan banyak-ke-banyak. Ini menimbulkan masalah. Untuk memahami masalah ini, bayangkan apa yang akan terjadi jika Anda mencoba membuat hubungan antara kedua tabel tersebut dengan menambahkan kolom Product ID ke dalam tabel Pesanan. Untuk memiliki lebih dari satu produk per pesanan, Anda memerlukan lebih dari satu catatan dalam tabel Pesanan per pesanan. Anda akan mengulang informasi pesanan untuk setiap baris yang terkait dengan satu pesanan - menghasilkan desain yang tidak efisien yang dapat menyebabkan data yang tidak akurat. Anda akan menghadapi masalah yang sama jika Anda menempatkan kolom Order ID di dalam tabel Produk - Anda akan memiliki lebih dari satu catatan dalam tabel Produk untuk setiap produk. Bagaimana Anda memecahkan masalah ini?

Jawabannya adalah dengan membuat tabel ketiga, sering disebut sebagai tabel sambungan (junction table), yang memecah hubungan banyak-ke-banyak menjadi dua hubungan satu-ke-banyak. Anda menyisipkan kunci utama dari masing-masing dua tabel ke dalam tabel ketiga. Akibatnya, tabel ketiga mencatat setiap kejadian atau instance dari hubungan tersebut.

Conceptual of a many to many relationship

Setiap catatan dalam tabel Order Details mewakili satu item garis dalam suatu pesanan. Kunci utama dari tabel Order Details terdiri dari dua kolom - kunci asing dari tabel Orders dan tabel Products. Menggunakan kolom Order ID saja tidak berfungsi sebagai kunci utama untuk tabel ini, karena satu pesanan dapat memiliki banyak item garis. Order ID diulang untuk setiap item garis dalam pesanan, sehingga kolom tersebut tidak mengandung nilai unik. Menggunakan kolom Product ID saja juga tidak berfungsi, karena satu produk dapat muncul dalam banyak pesanan yang berbeda. Tetapi bersama-sama, kedua kolom tersebut selalu menghasilkan nilai unik untuk setiap catatan.

Dalam database penjualan produk, tabel Orders dan tabel Products tidak terkait langsung satu sama lain. Sebagai gantinya, mereka terkait secara tidak langsung melalui tabel Order Details. Hubungan banyak-ke-banyak antara pesanan dan produk direpresentasikan dalam database dengan menggunakan dua hubungan satu-ke-banyak:

  1. Tabel Orders dan tabel Order Details memiliki hubungan satu-ke-banyak. Setiap pesanan dapat memiliki lebih dari satu item garis, tetapi setiap item garis hanya terhubung ke satu pesanan.
  2. Tabel Products dan tabel Order Details memiliki hubungan satu-ke-banyak. Setiap produk dapat memiliki banyak item garis yang terkait dengan itu, tetapi setiap item garis hanya merujuk pada satu produk.

Dari tabel Order Details, Anda dapat mengetahui semua produk dalam pesanan tertentu. Anda juga dapat mengetahui semua pesanan untuk produk tertentu.

Setelah memasukkan tabel Order Details, daftar tabel dan kolom mungkin tampak seperti ini:

Image showing information items during design process

Membuat One-to-One Relationship

Jenis hubungan lainnya adalah hubungan satu-ke-satu (one-to-one relationship). Misalkan Anda perlu mencatat beberapa informasi produk tambahan yang akan jarang digunakan atau hanya berlaku untuk beberapa produk tertentu. Karena Anda tidak membutuhkan informasi tersebut secara sering, dan karena menyimpan informasi tersebut dalam tabel Produk akan menyebabkan ruang kosong untuk setiap produk yang tidak berlaku, Anda menempatkannya dalam tabel terpisah. Seperti tabel Produk, Anda menggunakan ProductID sebagai kunci utama. Hubungan antara tabel tambahan ini dan tabel Produk adalah hubungan satu-ke-satu. Untuk setiap catatan dalam tabel Produk, ada satu catatan yang cocok di dalam tabel tambahan. Ketika Anda mengidentifikasi hubungan seperti ini, kedua tabel harus berbagi kolom yang sama.

Ketika Anda mendeteksi kebutuhan akan hubungan satu-ke-satu dalam database Anda, pertimbangkan apakah Anda dapat menggabungkan informasi dari kedua tabel tersebut menjadi satu tabel. Jika Anda tidak ingin melakukannya karena alasan tertentu, mungkin karena akan menghasilkan banyak ruang kosong, daftar berikut menunjukkan bagaimana Anda akan merepresentasikan hubungan tersebut dalam desain Anda:

  1. 1. Jika kedua tabel memiliki subjek yang sama, Anda mungkin dapat menyiapkan hubungan dengan menggunakan kunci utama yang sama di kedua tabel.
  2. 2. Jika kedua tabel memiliki subjek yang berbeda dengan kunci utama yang berbeda, pilih salah satu dari tabel tersebut (tidak masalah yang mana) dan masukkan kunci utama tersebut ke dalam tabel lain sebagai kunci asing.

Menentukan hubungan antara tabel-tabel membantu Anda memastikan bahwa Anda memiliki tabel dan kolom yang tepat. Ketika hubungan satu-ke-satu atau satu-ke-banyak ada, tabel-tabel yang terlibat perlu berbagi kolom atau kolom-kolom yang sama. Ketika hubungan banyak-ke-banyak ada, diperlukan tabel ketiga untuk merepresentasikan hubungan tersebut.

Finalisasi Desain

Setelah Anda memiliki tabel, kolom, dan hubungan yang Anda butuhkan, Anda harus membuat dan mengisi tabel-tabel Anda dengan data contoh dan mencoba bekerja dengan informasi tersebut: membuat kueri, menambahkan catatan baru, dan sebagainya. Melakukan hal ini membantu menyoroti masalah potensial - misalnya, Anda mungkin perlu menambahkan kolom yang terlupa selama fase desain, atau Anda mungkin memiliki tabel yang harus Anda pecah menjadi dua tabel untuk menghilangkan duplikasi.

Lihat apakah Anda dapat menggunakan database untuk mendapatkan jawaban yang Anda inginkan. Buat draf kasar formulir dan laporan Anda dan lihat apakah mereka menampilkan data yang Anda harapkan. Cari duplikasi data yang tidak perlu, dan ketika Anda menemukannya, ubah desain Anda untuk menghilangkannya.

Saat Anda mencoba database awal Anda, Anda mungkin menemukan ruang untuk perbaikan. Berikut adalah beberapa hal yang perlu diperiksa:

  1. Apakah Anda lupa kolom mana pun? Jika ya, apakah informasi tersebut cocok dengan tabel yang ada? Jika itu adalah informasi tentang sesuatu yang berbeda, Anda mungkin perlu membuat tabel lain. Buatlah kolom untuk setiap item informasi yang perlu Anda lacak. Jika informasi tersebut tidak dapat dihitung dari kolom lain, kemungkinan Anda akan membutuhkan kolom baru untuk itu.
  2. Apakah ada kolom yang tidak perlu karena dapat dihitung dari kolom yang ada? Jika sebuah item informasi dapat dihitung dari kolom lain yang ada - misalnya, harga diskon dihitung dari harga ritel, maka biasanya lebih baik melakukan hal tersebut daripada membuat kolom baru.
  3. Apakah Anda berulang kali memasukkan informasi duplikat dalam salah satu tabel Anda? Jika ya, Anda mungkin perlu membagi tabel menjadi dua tabel yang memiliki hubungan satu-ke-banyak.
  4. Apakah Anda memiliki tabel dengan banyak kolom, jumlah catatan terbatas, dan banyak kolom kosong dalam catatan individu? Jika ya, pertimbangkan untuk mendesain ulang tabel agar memiliki lebih sedikit kolom dan lebih banyak catatan.
  5. Apakah setiap item informasi telah dipecah menjadi bagian terkecil yang berguna? Jika Anda perlu melaporkan, mengurutkan, mencari, atau menghitung pada suatu item informasi, letakkan item tersebut dalam kolomnya sendiri.
  6. Apakah setiap kolom berisi fakta tentang subjek tabel? Jika sebuah kolom tidak berisi informasi tentang subjek tabel, maka kolom tersebut mungkin seharusnya ada di tabel lain.
  7. Apakah semua hubungan antara tabel direpresentasikan, baik melalui kolom-kolom yang sama atau melalui tabel ketiga? Hubungan satu-ke-satu dan satu-ke-banyak memerlukan kolom-kolom yang sama. Hubungan banyak-ke-banyak memerlukan tabel ketiga.

Memperbaiki Tabel Produk

Misalkan setiap produk dalam database penjualan produk termasuk dalam kategori umum, seperti minuman, bumbu, atau makanan laut. Tabel Produk bisa mencakup kolom yang menampilkan kategori dari setiap produk.

Misalkan setelah memeriksa dan menyempurnakan desain database, Anda memutuskan untuk menyimpan deskripsi dari kategori bersama dengan namanya. Jika Anda menambahkan kolom Deskripsi Kategori ke Tabel Produk, Anda harus mengulang deskripsi kategori untuk setiap produk yang termasuk dalam kategori tersebut - ini bukanlah solusi yang baik.

Solusi yang lebih baik adalah membuat Kategori sebagai subjek baru untuk database untuk dilacak, dengan tabel sendiri dan kunci utama sendiri. Anda kemudian dapat menambahkan kunci utama dari tabel Kategori ke Tabel Produk sebagai kunci asing.

Tabel Kategori dan Produk memiliki hubungan satu-ke-banyak: satu kategori dapat mencakup lebih dari satu produk, tetapi satu produk hanya dapat dimiliki oleh satu kategori.

Ketika Anda meninjau struktur tabel Anda, selalu perhatikan adanya kelompok berulang. Misalnya, pertimbangkan tabel yang berisi kolom-kolom berikut:


ID Produk
Nama
ID Produk1
Nama1
ID Produk2
Nama2
ID Produk3
Nama3


Di sini, setiap produk adalah kelompok berulang dari kolom yang hanya berbeda dengan menambahkan nomor di akhir nama kolom. Ketika Anda melihat kolom yang dinomori seperti ini, Anda harus meninjau kembali desain Anda.

Desain seperti ini memiliki beberapa kelemahan. Pertama, ini memaksa Anda untuk menetapkan batas atas pada jumlah produk. Begitu Anda melebihi batas itu, Anda harus menambahkan kelompok kolom baru ke struktur tabel, yang merupakan tugas administrasi besar.

Masalah lainnya adalah bahwa pemasok yang memiliki jumlah produk kurang dari jumlah maksimum akan menyia-nyiakan beberapa ruang, karena kolom tambahan akan kosong. Kekurangan yang paling serius dengan desain seperti ini adalah bahwa banyak tugas sulit dilakukan, seperti mengurutkan atau mengindeks tabel berdasarkan ID produk atau nama.

Setiap kali Anda melihat kelompok berulang, tinjau kembali desainnya dengan seksama dengan mempertimbangkan untuk memisahkan tabel menjadi dua. Dalam contoh di atas, lebih baik menggunakan dua tabel, satu untuk pemasok dan satu untuk produk, yang terhubung melalui ID pemasok.

Mengimplementasikan Aturan Normalisasi

Anda dapat menerapkan aturan normalisasi data (sering disebut aturan normalisasi) sebagai langkah berikutnya dalam desain Anda. Anda menggunakan aturan-aturan ini untuk memastikan bahwa tabel-tabel Anda terstruktur dengan benar. Proses menerapkan aturan-aturan ini pada desain database Anda disebut normalisasi database, atau hanya normalisasi.

Normalisasi paling berguna setelah Anda telah mewakili semua item informasi dan telah mencapai desain awal. Tujuannya adalah untuk membantu Anda memastikan bahwa Anda telah membagi item-item informasi Anda ke dalam tabel yang sesuai. Namun, normalisasi tidak dapat memastikan bahwa Anda memiliki semua item data yang benar dari awal.

Anda menerapkan aturan-aturan secara berurutan, memastikan bahwa desain Anda mencapai salah satu dari apa yang dikenal sebagai "normal forms". Ada lima normal forms yang diterima secara luas - normal form pertama hingga normal form kelima. Artikel ini akan menjelaskan lebih lanjut tentang tiga normal form pertama, karena biasanya sudah cukup untuk sebagian besar desain database.

Pertama, First Normal Form (1NF)

Normal form pertama menyatakan bahwa di setiap pertemuan baris dan kolom dalam tabel, harus ada satu nilai, dan tidak pernah ada daftar nilai. Misalnya, Anda tidak dapat memiliki kolom bernama Harga di mana Anda menempatkan lebih dari satu harga. Jika Anda memikirkan setiap pertemuan baris dan kolom sebagai sel, setiap sel hanya dapat memuat satu nilai.

Kedua, Second Normal Form (2NF)

Normal form kedua mensyaratkan bahwa setiap kolom bukan kunci harus sepenuhnya bergantung pada seluruh primary key, tidak hanya pada sebagian dari kunci. Aturan ini berlaku ketika Anda memiliki primary key yang terdiri dari lebih dari satu kolom. Misalnya, anggap Anda memiliki tabel yang berisi kolom-kolom berikut, di mana Order ID dan Product ID membentuk primary key:

Order ID (primary key)
Product ID (primary key)
Product Name

Desain ini melanggar normal form kedua, karena Product Name tergantung pada Product ID, tetapi tidak tergantung pada Order ID, sehingga tidak tergantung pada seluruh primary key. Anda harus menghapus Product Name dari tabel ini. Itu seharusnya ada di tabel lain (Products).

Ketiga, Third Normal Form

Normal form ketiga mensyaratkan bahwa tidak hanya setiap kolom bukan kunci harus bergantung pada seluruh primary key, tetapi juga bahwa kolom-kolom bukan kunci harus mandiri satu sama lain.

Artinya, setiap kolom bukan kunci harus bergantung pada primary key dan hanya primary key saja. Misalnya, anggap Anda memiliki tabel yang berisi kolom-kolom berikut:

ProductID (primary key)
Name
SRP
Discount

Diasumsikan bahwa Discount tergantung pada suggested retail price (SRP). Tabel ini melanggar normal form ketiga karena kolom bukan kunci, Discount, tergantung pada kolom bukan kunci lainnya, yaitu SRP. Kemandirian kolom berarti bahwa Anda harus dapat mengubah setiap kolom bukan kunci tanpa mempengaruhi kolom lainnya. Jika Anda mengubah nilai dalam kolom SRP, maka nilai Discount juga akan berubah, sehingga melanggar aturan tersebut. Dalam kasus ini, Discount sebaiknya dipindahkan ke tabel lain yang diindeks berdasarkan SRP.

Terakhir diubah: Jumat, 4 Agustus 2023, 08:46