Pemodelan data: merancang struktur data Anda

Bila Anda menyimpan atau melihat data dengan aplikasi, bagian penting dari desain adalah struktur data. Pertimbangkan tidak hanya bagaimana data tersebut akan digunakan di satu aplikasi atau layar tertentu, namun bagaimana pengguna lain akan menggunakan data tersebut. Merujuk kembali ke persona, tugas, proses bisnis, dan sasaran akan membantu Anda menentukan data apa yang akan disimpan dan cara menstrukturkannya.

Tip

Meskipun ditulis untuk database Access, artikel tentang dasar-dasar desain data ini memiliki diskusi umum prinsip pemodelan data yang baik: dasar-dasar desain database.

Mari ambil laporan biaya berikut sebagai contoh.

Anda melihat bagian utama dari laporan pengeluaran, yang memiliki nama karyawan dan rincian Departemen. Di bawah bagian utama, Anda melihat beberapa baris Deskripsi untuk setiap item yang dibeli. Mari kita panggil item baris ini. Item baris memiliki struktur yang berbeda dari bagian utama laporan pengeluaran. Sehingga kita dapat mengatakan bahwa untuk setiap laporan pengeluaran, ada beberapa item baris.

Untuk menyimpan data jenis ini ke database, kita harus memodelkan struktur data dalam desain database.

Struktur data satu-ke-banyak (1: N)

Ini adalah jenis struktur data yang dijelaskan dalam contoh sebelumnya. Bagian utama dari laporan pengeluaran dikaitkan ke beberapa item baris. (Anda juga dapat melihat relasi dari perspektif item baris: banyak item baris ke satu laporan pengeluaran (N:1).)

Struktur data banyak ke-banyak (N:N)

Struktur data Beberapa ke beberapa adalah jenis khusus. Ini adalah untuk kasus di mana beberapa rekaman dapat dikaitkan dengan beberapa rangkaian rekaman lain. Contoh yang baik adalah jaringan mitra bisnis Anda. Anda memiliki beberapa mitra bisnis (pelanggan dan vendor) yang bekerja dengan Anda, dan mitra bisnis tersebut juga bekerja dengan beberapa rekan kerja dari Anda.

Contoh pemodelan data

Ada beberapa jenis pemodelan yang dapat terjadi dengan sistem. Mari lihat beberapa contoh.

Contoh 1: permintaan persetujuan waktu nonaktif

Contoh sederhana ini menunjukkan dua kumpulan data. Salah satunya adalah karyawan, yang lain adalah permintaan waktu nonaktif. Karena setiap karyawan akan mengirimkan beberapa permintaan, relasi di sini adalah satu-ke-banyak, di mana "satu" adalah karyawan dan "banyak" adalah permintaannya. Data karyawan dan data permintaan waktu nonaktif terkait satu sama lain dengan memiliki jumlah karyawan sebagai bidang umum (juga dikenal sebagai kunci).

Contoh 2: persetujuan pembelian

Di sini, struktur data terlihat cukup canggih namun sangat mirip dengan contoh laporan biaya yang dibahas di bagian awal artikel ini. Setiap vendor atau pemasok dikaitkan dengan beberapa pesanan pembelian. Setiap karyawan bertanggung jawab atas beberapa pesanan pembelian. Oleh karena itu, kedua kumpulan data ini memiliki struktur data satu-ke-banyak.

Karena karyawan mungkin tidak selalu menggunakan vendor atau pemasok yang sama, vendor digunakan oleh beberapa karyawan dan setiap karyawan bekerja dengan beberapa vendor. Oleh karena itu, hubungan antara karyawan dan vendor adalah banyak-ke-banyak.

Contoh 3: Pelaporan pengeluaran

Langkah berikutnya: Menentukan jenis aplikasi yang akan dibuat

Catatan

Apa bahasa dokumentasi yang Anda inginkan? Lakukan survei singkat. (perlu diketahui bahwa survei ini dalam bahasa Inggris)

Survei akan berlangsung kurang lebih selama tujuh menit. Tidak ada data pribadi yang dikumpulkan (pernyataan privasi).