Selasa, 03 April 2012

ERD


Entity-Relationship Diagram (ERD) 

Model data adalah alat yang digunakan dalam analisis untuk menjelaskan persyaratan data dan asumsi dalam sistem dari perspektif top-down. Mereka juga mengatur panggung untuk desain database di kemudian hari dalam SDLC.
Ada tiga elemen dasar dalam model ER:
Entitas adalah "sesuatu" tentang apa yang kita mencari informasi.
Atribut adalah data yang kami kumpulkan tentang entitas.
Hubungan menyediakan struktur yang dibutuhkan untuk menarik informasi dari beberapa entitas.
Umumnya, ERD yang terlihat seperti ini:


diadaptasi dari profesor lain .

Mengembangkan sebuah ERD
Mengembangkan ERD membutuhkan pemahaman tentang sistem dan komponen-komponennya. Sebelum membahas prosedur, mari kita lihat narasi yang dibuat oleh Profesor Harman .

Pertimbangkan rumah sakit:
Pasien dirawat di bangsal tunggal oleh dokter yang ditugaskan kepada mereka. Biasanya setiap pasien akan diberi dokter tunggal, tetapi dalam kasus yang jarang mereka akan memiliki dua.
Heathcare asisten juga menghadiri kepada pasien, sejumlah ini berhubungan dengan setiap lingkungan. 
Awalnya sistem akan bersangkutan semata-mata dengan terapi obat. Setiap pasien diminta untuk mengambil berbagai obat sejumlah kali per hari dan untuk berbagai panjang waktu.
Sistem ini harus mencatat rincian tentang perawatan pasien dan pembayaran staf. Beberapa staf dibayar paruh waktu dan dokter dan asisten perawatan bekerja berbagai jumlah lembur dengan harga yang bervariasi (tergantung grade).
Sistem ini juga akan perlu untuk melacak perawatan apa yang dibutuhkan untuk pasien dan kapan dan harus mampu menghitung biaya perawatan per minggu untuk setiap pasien (meskipun saat ini tidak jelas untuk apa menggunakan informasi ini akan dimasukkan). 

Bagaimana kita memulai sebuah ERD?
1. Menentukan Entitas: ini biasanya kata benda yang digunakan dalam deskripsi sistem, dalam pembahasan aturan bisnis, atau dalam dokumentasi; diidentifikasi dalam cerita (lihat item yangdisorot di atas).
2. Tentukan Hubungan: ini biasanya kata kerja yang digunakan dalam deskripsi sistem atau dalam diskusi tentang aturan bisnis (entitas entitas ______); diidentifikasi dalam cerita (lihat item yang disorot di atas).

3. Tambahkan atribut untuk hubungan, ini adalah ditentukan oleh query, dan juga mungkin menyarankan entitas baru, kelas misalnya, atau mereka mungkin menunjukkan kebutuhan untuk kunci atau pengenal.
Pertanyaan apa yang kita minta?
a. Yang dokter yang bekerja di bangsal?
b. Berapa banyak akan dihabiskan di bangsal dalam satu minggu?
c. Berapa biaya pasien untuk mengobati?
d. Berapa biaya dokter per minggu?
e. Yang asisten dapat pasien berharap untuk melihat?
f. Obat mana yang digunakan?

4. Tambahkan kardinalitas untuk hubungan
Banyak-ke-Banyak harus diselesaikan dua satu-ke-manys dengan entitas tambahan
Biasanya terjadi secara otomatis
Kadang-kadang melibatkan pengenalan entitas link (yang akan semua kunci asing) Contoh: Pasien-Obat

5. Fleksibilitas ini memungkinkan kita untuk mempertimbangkan berbagai pertanyaan seperti:
a. Yang tempat tidur bebas?
b. Yang bekerja untuk asisten Dr X?
c. Apa resep paling murah?
d. Berapa banyak dokter yang ada di rumah sakit?
e. Mana pasien adalah keluarga terkait?
6. Menyatakan bahwa informasi dengan simbol. Diagram ER umumnya memerlukan penggunaan simbol-simbol berikut:

Membaca sebuah ERD
Butuh beberapa praktek membaca sebuah ERD, tetapi mereka dapat digunakan dengan klien untuk mendiskusikan aturan bisnis.
Ini memungkinkan kita untuk mewakili informasi dari atas seperti Diagram ER di bawah ini:


ERD memunculkan isu:
Banyak-ke-Manys
Ambiguitas
Entitas dan hubungan mereka
Data apa yang harus disimpan
Gelar dari sebuah hubungan
Sekarang, pikirkan tentang sebuah universitas dalam hal sebuah ERD. Apa entitas, hubungan dan atribut mungkin Anda pertimbangkan? Lihat ini pandangan yang disederhanakan . Ada juga contoh dari pandangan yang disederhanakan dari sebuah maskapai penerbangan di halaman tersebu

DESAIN DATABASE

Desain DataBase

Database yang dirancang menyediakan akses untuk up-to-date, informasi yang akurat. Karena desain yang benar adalah penting untuk mencapai tujuan Anda dalam bekerja dengan database, investasi waktu yang dibutuhkan untuk mempelajari prinsip-prinsip desain yang baik masuk akal. Pada akhirnya, Anda akan jauh lebih mungkin berakhir dengan sebuah database yang memenuhi kebutuhan Anda dan dapat dengan mudah mengakomodasi perubahan.
Artikel ini memberikan pedoman untuk perencanaan database. Anda akan belajar bagaimana untuk memutuskan informasi apa yang Anda butuhkan, bagaimana membagi informasi tersebut ke dalam tabel dan kolom yang sesuai, dan bagaimana tabel berhubungan satu sama lain. Anda harus membaca artikel ini sebelum Anda membuat database pertama Anda.

Beberapa istilah basis data untuk mengetahui

Microsoft Office Access 2007 mengatur informasi Anda ke dalam tabel: daftar baris dan kolom mengingatkan pad akuntan atau Microsoft Office Excel 2007 worksheet. Dalam sebuah database sederhana, Anda mungkin hanya memiliki satu meja. Untuk database yang paling Anda akan membutuhkan lebih dari satu.Sebagai contoh, Anda mungkin memiliki tabel yang menyimpan informasi tentang produk, tabel lain yang menyimpan informasi tentang pesanan Anda, dan tabel lain dengan informasi tentang pelanggan.
Image depicting three tables in datasheets
Setiap baris juga disebut record, dan setiap kolom, juga disebut lapangan.Catatan adalah cara yang berarti dan konsisten untuk menggabungkan informasi tentang sesuatu. Field adalah item tunggal informasi - jenis item yang muncul dalam tiap rekaman. Dalam tabel Produk, misalnya, setiap baris atau record akan menyimpan informasi tentang satu produk. Setiap kolom atau bidang memegang beberapa jenis informasi tentang produk, seperti nama atau harga.

Apa desain database yang baik?

Prinsip-prinsip tertentu memandu proses desain database. Prinsip pertama adalah bahwa informasi duplikat (disebut juga data yang berlebihan) adalah buruk, karena limbah ruang dan meningkatkan kemungkinan kesalahan dan inkonsistensi. Prinsip kedua adalah bahwa kebenaran dan kelengkapan informasi adalah penting. Jika database Anda berisi informasi yang salah, setiap laporan yang menarik informasi dari database juga akan berisi informasi yang salah. Akibatnya, setiap keputusan yang Anda buat yang didasarkan pada laporan-laporan tersebut kemudian akan salah informasi.
Sebuah desain database yang baik, oleh karena itu, yang:
  • Membagi informasi Anda ke subjek berbasis tabel untuk mengurangi data yang berlebihan.
  • Menyediakan akses dengan informasi yang diperlukan untuk bergabung dengan informasi dalam tabel bersama-sama sesuai kebutuhan.
  • Membantu mendukung dan memastikan keakuratan dan integritas informasi Anda.
  • Mengakomodasi data pengolahan dan pelaporan kebutuhan.

Proses desain

Proses desain terdiri dari langkah-langkah berikut:
  • Tentukan tujuan dari database Anda
Hal ini membantu mempersiapkan Anda untuk langkah-langkah yang tersisa.
  • Mencari dan mengatur informasi yang diperlukan
Mengumpulkan semua jenis informasi yang mungkin Anda ingin merekam dalam database, seperti nama produk dan nomor rangka.
  • Bagilah informasi ke dalam tabel
Membagi item informasi Anda menjadi entitas utama atau subjek, seperti Produk atau Perintah. Setiap mata pelajaran kemudian menjadi sebuah tabel.
  • Aktifkan item informasi ke dalam kolom
Tentukan informasi apa yang Anda ingin menyimpan dalam setiap tabel. Setiap item menjadi lapangan, dan ditampilkan sebagai kolom dalam tabel. Sebagai contoh, sebuah tabel Karyawan mungkin termasuk bidang-bidang seperti Nama Belakang dan Tanggal Sewa.
  • Tentukan kunci primer
Pilih primary key setiap tabel. Primary key adalah kolom yang digunakan untuk secara unik mengidentifikasi setiap baris. Sebuah contoh mungkin ID Produk atau ID Order.
  • Mengatur hubungan tabel
Lihatlah setiap tabel dan memutuskan bagaimana data dalam satu tabel yang berkaitan dengan data dalam tabel lainnya. Menambahkan kolom untuk tabel atau membuat tabel baru untuk memperjelas hubungan, sesuai kebutuhan.
  • Pertajam desain Anda
Menganalisis desain Anda untuk kesalahan. Membuat tabel dan menambahkan beberapa catatan dari data sampel. Lihat jika Anda bisa mendapatkan hasil yang Anda inginkan dari tabel Anda. Membuat penyesuaian untuk desain, sesuai kebutuhan.
  • Terapkan aturan normalisasi
Terapkan aturan Data normalisasi untuk melihat apakah tabel Anda terstruktur dengan benar. Melakukan penyesuaian dengan tabel, sesuai kebutuhan.

Menentukan tujuan dari database Anda

Ini adalah ide yang baik untuk menuliskan tujuan dari database di atas kertas - tujuannya, bagaimana Anda berharap untuk 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 memproduksi surat dan laporan." Jika database yang lebih kompleks atau digunakan oleh banyak orang, seperti yang sering terjadi dalam pengaturan perusahaan, tujuannya dengan mudah bisa menjadi paragraf atau lebih dan harus mencakup kapan dan bagaimana setiap orang akan menggunakan database. Idenya adalah untuk memiliki pernyataan misi juga dikembangkan yang dapat disebut selama proses desain. Memiliki pernyataan seperti itu membantu Anda fokus pada tujuan Anda ketika Anda membuat keputusan.

Mencari dan mengatur informasi yang diperlukan

Untuk mencari dan mengatur informasi yang diperlukan, mulailah dengan informasi yang ada. Sebagai contoh, Anda mungkin mencatat pesanan pembelian dalam buku besar atau menyimpan informasi pelanggan pada bentuk kertas di lemari arsip. Kumpulkan dokumen-dokumen dan daftar setiap jenis informasi yang ditampilkan (misalnya, setiap kotak agar Anda mengisi pada formulir). Jika Anda tidak memiliki bentuk yang ada, bayangkan bukan bahwa Anda harus merancang formulir untuk merekam informasi pelanggan. Informasi apa yang akan Anda masukkan pada form? Apa isi-in kotak yang akan Anda buat?Identifikasi dan daftar masing-masing item. Misalnya, saat ini Anda menyimpan daftar pelanggan pada kartu indeks. Meneliti kartu ini mungkin menunjukkan bahwa setiap kartu memiliki nama pelanggan, alamat, kota, negara, kode pos dan nomor telepon. Masing-masing item merupakan potensi kolom dalam sebuah tabel.
Ketika Anda mempersiapkan daftar ini, jangan khawatir tentang mendapatkan itu sempurna pada awalnya. Sebaliknya, daftar setiap item yang datang ke pikiran.Jika orang lain akan menggunakan database, meminta ide-ide mereka juga. Anda dapat menyempurnakan daftar kemudian.
Selanjutnya, pertimbangkan jenis laporan atau surat Anda mungkin ingin menghasilkan dari database. Misalnya, Anda mungkin ingin melaporkan penjualan produk untuk menunjukkan penjualan menurut wilayah, atau ringkasan laporan persediaan yang menunjukkan tingkat persediaan produk. Anda mungkin juga ingin menghasilkan surat formulir untuk mengirim ke pelanggan yang mengumumkan acara penjualan atau menawarkan premium. Desain laporan dalam pikiran Anda, dan bayangkan apa yang akan terlihat seperti. Informasi apa yang akan Anda tempatkan pada laporan? Daftar setiap item. Lakukan hal yang sama untuk huruf bentuk dan untuk setiap laporan lain yang Anda mengantisipasi menciptakan.
A person imagining a product inventory report
Memikirkan untuk laporan dan surat Anda mungkin ingin membuat membantu Anda mengidentifikasi item yang akan butuhkan dalam database Anda. Misalnya, Anda memberikan pelanggan kesempatan untuk mengikuti (atau keluar dari) periodik email update, dan Anda ingin mencetak daftar dari mereka yang telah memilih masuk Untuk merekam informasi itu, Anda menambahkan "Kirim e- mail "kolom ke meja pelanggan. Untuk setiap pelanggan, Anda dapat mengatur lapangan untuk Ya atau Tidak
Persyaratan untuk mengirim e-mail ke pelanggan menunjukkan item lain untuk merekam. Setelah Anda tahu bahwa pelanggan ingin menerima e-mail, Anda juga perlu mengetahui alamat e-mail yang mengirim mereka. Oleh karena itu Anda perlu mencatat alamat e-mail untuk setiap pelanggan.
Masuk akal untuk membangun prototipe tiap daftar laporan atau output dan mempertimbangkan apa yang item yang akan perlu untuk menghasilkan laporan.Misalnya, ketika Anda memeriksa surat formulir, beberapa hal mungkin datang ke pikiran. Jika Anda ingin menyertakan sebuah salam yang tepat - misalnya, "Mr", "Mrs" atau "Ms" string yang dimulai ucapan, Anda harus membuat item salam.Juga, Anda biasanya akan mulai dengan surat "Dear Mr Smith", bukan "Dear. Pak Sylvester Smith ". Ini menunjukkan Anda biasanya akan ingin menyimpan nama belakang terpisah dari nama depan.
Hal penting yang harus diingat adalah bahwa Anda harus istirahat setiap potongan informasi menjadi bagian-bagian terkecil yang berguna. Dalam kasus nama, untuk membuat nama belakang tersedia, Anda akan mematahkan nama menjadi dua bagian - Nama Depan dan Nama Belakang. Untuk menyusun sebuah laporan oleh nama terakhir, misalnya, ada baiknya untuk memiliki nama terakhir pelanggan disimpan secara terpisah. Secara umum, jika Anda ingin menyortir, mencari, menghitung, atau melaporkan berdasarkan item informasi, Anda harus menempatkan item dalam bidang sendiri.
Pikirkan tentang pertanyaan yang mungkin ingin database untuk menjawab.Misalnya, berapa banyak penjualan produk fitur Anda apakah Anda menutup bulan lalu? Di mana pelanggan terbaik Anda tinggal? Siapa pemasok untuk laris produk Anda? Mengantisipasi pertanyaan-pertanyaan ini membantu Anda nol dalam pada item tambahan untuk merekam.
Setelah mengumpulkan informasi ini, Anda siap untuk langkah berikutnya.

Membagi informasi ke dalam tabel

Untuk membagi informasi ke dalam tabel, memilih entitas utama, atau mata pelajaran. Misalnya, setelah mencari dan mengatur informasi untuk database penjualan produk, daftar awal mungkin terlihat seperti ini:
Handwritten information items grouped into subjects
Entitas utama ditampilkan di sini adalah produk, pemasok, pelanggan, dan perintah. Oleh karena itu, masuk akal untuk memulai dengan empat tabel: satu untuk fakta tentang produk, satu untuk fakta tentang pemasok, satu untuk fakta tentang pelanggan, dan satu untuk fakta tentang perintah. Meskipun hal ini tidak menyelesaikan daftar, itu adalah titik awal yang baik. Anda dapat terus menyempurnakan daftar ini sampai Anda memiliki desain yang bekerja dengan baik.
Ketika Anda pertama kali meninjau daftar awal item, Anda mungkin tergoda untuk menempatkan mereka semua dalam satu tabel, bukan empat ditunjukkan pada gambar sebelumnya. Anda akan belajar di sini mengapa itu ide yang buruk.Pertimbangkan sejenak, tabel ditampilkan di sini:
Image showing table that contains both products and suppliers
Dalam hal ini, setiap baris berisi informasi tentang produk dan pemasok. Karena Anda dapat memiliki banyak produk dari pemasok yang sama, nama pemasok dan informasi alamat harus diulang berkali-kali. Ini limbah ruang disk. Mencatat informasi pemasok hanya sekali dalam tabel Pemasok terpisah, dan kemudian menghubungkan tabel yang ke meja Produk, adalah solusi yang jauh lebih baik.
Masalah kedua dengan desain ini timbul pada saat Anda perlu mengubah informasi tentang pemasok. Misalnya, Anda perlu mengubah alamat pemasok.Karena muncul di banyak tempat, Anda mungkin tidak sengaja mengubah alamat di satu tempat tapi lupa untuk mengubahnya dalam yang lain. Merekam alamat pemasok hanya dalam satu tempat memecahkan masalah.
Bila Anda merancang database Anda, selalu mencoba untuk merekam fakta masing-masing hanya sekali. Jika Anda menemukan diri Anda mengulangi informasi yang sama di lebih dari satu tempat, seperti alamat untuk pemasok tertentu, tempat bahwa informasi dalam tabel terpisah.
Akhirnya, misalkan hanya ada satu produk yang dipasok oleh Coho Winery, dan Anda ingin menghapus produk, tetapi mempertahankan nama pemasok dan informasi alamat. Bagaimana Anda menghapus catatan produk tanpa juga kehilangan informasi pemasok? Anda tidak bisa. Karena setiap record berisi fakta-fakta tentang suatu produk, serta fakta tentang pemasok, Anda tidak dapat menghapus satu tanpa menghapus yang lain. Untuk menjaga fakta-fakta yang terpisah, Anda harus membagi tabel satu menjadi dua: satu meja untuk informasi produk, dan meja lain untuk informasi pemasok. Menghapus record produk harus menghapus hanya fakta-fakta tentang produk, bukan fakta-fakta tentang pemasok.
Setelah Anda memilih subjek yang direpresentasikan oleh sebuah tabel, kolom dalam tabel yang harus menyimpan fakta hanya sekitar subjek. Misalnya, tabel produk harus menyimpan fakta hanya sekitar produk. Karena alamat pemasok adalah fakta tentang pemasok, dan bukan fakta tentang produk, itu termasuk dalam tabel pemasok.

Mengubah informasi item ke dalam kolom

Untuk menentukan kolom dalam sebuah tabel, memutuskan apa informasi yang Anda butuhkan untuk melacak tentang subjek direkam dalam tabel. Misalnya, untuk tabel Pelanggan, Nama, Alamat, Kota-Negara-Zip, Kirim e-mail, Salutation dan E-mail terdiri dari daftar awal yang baik dari kolom. Setiap record dalam tabel berisi set yang sama kolom, sehingga Anda dapat menyimpan Nama, Alamat, Kota-Negara-Zip, Kirim e-mail, Salutation dan E-mail informasi alamat untuk setiap record. Sebagai contoh, kolom alamat berisi alamat pelanggan. Setiap record berisi data tentang salah satu pelanggan, dan field alamat berisi alamat untuk pelanggan itu.
Begitu Anda telah menentukan set awal kolom untuk setiap tabel, Anda dapat lebih menyempurnakan kolom. Misalnya, masuk akal untuk menyimpan nama pelanggan sebagai dua kolom terpisah: nama depan dan nama belakang, sehingga Anda dapat mengurutkan, mencari, dan indeks hanya pada kolom tersebut. Demikian pula, alamat sebenarnya terdiri dari lima komponen yang terpisah, alamat, kota, negara, kode pos, dan negara / wilayah, dan juga masuk akal untuk menyimpannya dalam kolom terpisah. Jika Anda ingin melakukan operasi pencarian, filter atau semacam oleh negara, misalnya, Anda memerlukan informasi negara disimpan dalam kolom terpisah.
Anda juga harus mempertimbangkan apakah database akan menyimpan informasi yang berasal dari dalam negeri saja, atau internasional, juga. Misalnya, jika Anda berencana untuk menyimpan alamat internasional, lebih baik untuk memiliki kolom Daerah bukan Negara, karena kolom tersebut dapat mengakomodasi kedua negara domestik dan wilayah negara / daerah. Demikian pula, Kode Pos lebih masuk akal daripada Zip Code jika Anda akan menyimpan alamat internasional.
Daftar berikut menunjukkan beberapa tips untuk menentukan kolom.
  • Jangan menyertakan data dihitung
Dalam kebanyakan kasus, Anda tidak perlu menyimpan hasil perhitungan dalam tabel. Sebaliknya, Anda dapat memiliki akses melakukan perhitungan ketika Anda ingin melihat hasilnya. Misalnya, ada Produk Pada laporan Orde yang menampilkan subtotal unit pada pesanan untuk setiap kategori produk di database. Namun, tidak ada Unit Pada kolom Orde subtotal dalam tabel apapun.Sebaliknya, tabel Produk mencakup Unit Pada kolom Order yang menyimpan unit pada pesanan untuk setiap produk. Menggunakan data tersebut, akses menghitung waktu subtotal setiap Anda mencetak laporan. Subtotal itu sendiri tidak harus disimpan dalam sebuah tabel.
  • Menyimpan informasi dalam bagian-bagian terkecil yang logis
Anda mungkin tergoda untuk memiliki bidang tunggal untuk nama lengkap, atau untuk nama produk beserta deskripsi produk. Jika Anda menggabungkan lebih dari satu jenis informasi di lapangan, sulit untuk mengambil fakta individu kemudian. Cobalah untuk memecah informasi menjadi bagian-bagian logis, misalnya, membuat kolom-kolom terpisah untuk nama pertama dan terakhir, atau untuk nama produk, kategori, dan deskripsi.
List of information items during the design process
Setelah Anda telah disempurnakan kolom data dalam setiap tabel, Anda siap untuk memilih primary key setiap tabel.

Menentukan kunci primer

Setiap tabel harus menyertakan kolom atau set kolom yang secara unik mengidentifikasi setiap baris disimpan dalam tabel. Hal ini sering nomor identifikasi yang unik, seperti nomor ID karyawan atau nomor seri. Dalam database terminologi, informasi ini disebut primary key tabel. Akses menggunakan medan kunci utama untuk cepat mengasosiasikan data dari beberapa tabel dan membawa data bersama-sama untuk Anda.
Jika Anda sudah memiliki sebuah identifikasi unik untuk meja, seperti nomor produk yang secara unik mengidentifikasi setiap produk dalam katalog, Anda dapat menggunakan pengenal bahwa sebagai kunci primer table - tetapi hanya jika nilai-nilai dalam kolom ini akan selalu berbeda untuk setiap rekaman. Anda tidak dapat memiliki nilai ganda dalam kunci primer. Misalnya, jangan menggunakan nama orang sebagai kunci utama, karena nama tidak unik. Anda dengan mudah bisa memiliki dua orang dengan nama yang sama di meja yang sama.
Kunci utama harus selalu memiliki nilai. Jika nilai kolom dapat menjadi unassigned atau tidak dikenal (missing value) di beberapa titik, tidak dapat digunakan sebagai komponen dalam primary key.
Anda harus selalu memilih primary key yang nilainya tidak akan berubah. Dalam sebuah database yang menggunakan lebih dari satu tabel, primary key tabel yang dapat digunakan sebagai acuan dalam tabel lain. Jika perubahan kunci utama, perubahan ini juga harus diterapkan di mana-mana kuncinya direferensikan.Menggunakan kunci primer yang tidak akan berubah mengurangi kesempatan bahwa kunci utama mungkin menjadi tidak sinkron dengan tabel lain yang referensi itu.
Seringkali, nomor unik yang sewenang-wenang digunakan sebagai primary key.Misalnya, Anda dapat menetapkan setiap pesanan sejumlah pesanan unik.Satunya tujuan nomor urut adalah untuk mengidentifikasi perintah. Setelah ditetapkan, itu tidak pernah berubah.
Jika Anda tidak ada dalam pikiran kolom atau set kolom yang mungkin bisa membuat kunci primer yang baik, pertimbangkan untuk menggunakan kolom yang memiliki tipe AutoNumber data. Bila Anda menggunakan tipe data AutoNumber, akses otomatis memberikan nilai untuk Anda. Seperti identifier adalah factless; tidak mengandung informasi faktual yang menggambarkan baris yang yang diwakilinya. Pengidentifikasi Factless ideal untuk digunakan sebagai primary key karena mereka tidak berubah. Kunci utama yang berisi fakta tentang berturut-turut - nomor telepon atau nama pelanggan, misalnya - lebih mungkin untuk berubah, karena informasi faktual itu sendiri bisa berubah.

Image showing Products table with primary key field.
Callout 1 Sebuah kolom set ke tipe data AutoNumber sering membuat primary key yang baik. Tidak ada dua ID produk adalah sama.

Dalam beberapa kasus, Anda mungkin ingin menggunakan dua atau lebih bidang yang, bersama-sama, memberikan primary key dari tabel. Sebagai contoh, sebuah Orde Rincian tabel yang menyimpan item baris untuk pesanan akan menggunakan dua kolom dalam kunci utama: Order ID dan ID Produk. Ketika primary key mempekerjakan lebih dari satu kolom, juga disebut kunci komposit.
Untuk database penjualan produk, Anda dapat membuat kolom AutoNumber untuk setiap tabel untuk berfungsi sebagai primary key: ProductID untuk tabel Produk, OrderID untuk tabel Pesanan, Pelanggan untuk tabel Pelanggan, dan SupplierID untuk tabel Pemasok.
Image showing information items during design process

Menciptakan hubungan tabel

Sekarang bahwa Anda telah membagi informasi Anda ke dalam tabel, Anda membutuhkan cara untuk membawa informasi bersama-sama lagi dalam cara yang berarti. Misalnya, bentuk berikut mencakup informasi dari beberapa tabel.

The Orders form
Callout 1 Informasi dalam formulir ini berasal dari tabel Pelanggan ...
Callout 2 ... Tabel Karyawan ...
Callout 3 ... Tabel Orders ...
Callout 4 Tabel ... Produk ...
Callout 5 ... Dan Orde Rincian tabel.

Akses adalah sistem manajemen database relasional. Dalam database relasional, Anda membagi informasi Anda ke terpisah, subjek berbasis tabel.Anda kemudian gunakan hubungan tabel untuk membawa informasi bersama-sama sesuai kebutuhan.

MENCIPTAKAN HUBUNGAN SATU-KE-BANYAK

Pertimbangkan contoh ini: Pemasok dan tabel Produk dalam database produk pesanan. Seorang pemasok dapat menyediakan sejumlah produk. Maka, agar setiap pemasok diwakili dalam tabel Suppliers, akan ada banyak produk diwakili dalam tabel Produk. Hubungan antara tabel Pemasok dan tabel Produk Oleh karena itu, hubungan satu-ke-banyak.
One to many conceptual
Untuk mewakili hubungan satu-ke-banyak dalam desain database Anda, mengambil kunci utama di sisi "satu" hubungan dan menambahkannya sebagai kolom tambahan atau kolom ke meja di sisi "banyak" hubungan. Dalam hal ini, misalnya, Anda menambahkan kolom ID Pemasok dari tabel Pemasok ke tabel Produk. Akses dapat menggunakan nomor ID pemasok dalam tabel Produk untuk menemukan pemasok yang benar untuk setiap produk.
ID Pemasok kolom dalam tabel Produk yang disebut kunci asing. Kunci asing adalah kunci utama lain meja. ID Pemasok kolom dalam tabel Products adalah kunci asing karena juga primary key pada tabel Pemasok.
List of information items during the design process
Anda memberikan dasar untuk bergabung dengan tabel terkait dengan membentuk pasangan dari kunci primer dan kunci asing. Jika Anda tidak yakin yang tabel harus berbagi kolom umum, mengidentifikasi hubungan satu-ke-banyak memastikan bahwa kedua tabel yang terlibat akan, memang, membutuhkan kolom bersama.

MENCIPTAKAN HUBUNGAN BANYAK-KE-BANYAK

Pertimbangkan hubungan antara tabel Produk dan tabel Orders.
Sebuah perintah tunggal dapat mencakup lebih dari satu produk. Di sisi lain, satu produk dapat muncul di banyak pesanan. Oleh karena itu, untuk setiap record di tabel Orders, akan ada banyak catatan dalam tabel Produk. Dan untuk setiap record dalam tabel Produk, akan ada banyak catatan dalam tabel Orders. Jenis hubungan ini disebut hubungan banyak-ke-banyak karena untuk produk apapun, akan ada banyak pesanan, dan untuk urutan apapun, akan ada banyak produk.Perhatikan bahwa untuk mendeteksi banyak-ke-banyak hubungan antara tabel Anda, penting bahwa Anda mempertimbangkan kedua sisi hubungan.
Subyek dari dua tabel - perintah dan produk - memiliki hubungan banyak-ke-banyak. Ini menyajikan masalah. Untuk memahami masalah, bayangkan apa yang akan terjadi jika Anda mencoba untuk membuat hubungan antara dua tabel dengan menambahkan field ID Produk untuk tabel Orders. Untuk memiliki lebih dari satu produk per pesanan, Anda membutuhkan lebih dari satu record di tabel Orders per pesanan. Anda akan mengulangi informasi pesanan untuk setiap baris yang berhubungan dengan perintah tunggal - menghasilkan desain yang tidak efisien yang dapat menyebabkan data tidak akurat. Anda mengalami masalah yang sama jika Anda menempatkan field ID Ordo dalam tabel Produk - Anda akan memiliki lebih dari satu record pada tabel Produk untuk setiap produk.Bagaimana Anda mengatasi masalah ini?
Jawabannya adalah dengan membuat tabel ketiga, sering disebut sebagai tabel persimpangan, yang memecah hubungan banyak-ke-banyak ke dalam dua satu-ke-banyak hubungan. Anda memasukkan kunci utama dari masing-masing dua tabel ke dalam tabel ketiga. Akibatnya, tabel ketiga mencatat setiap kejadian atau contoh hubungan.
A many-to-many relationship
Setiap record dalam tabel Rincian Orde merupakan salah satu item baris di perintah. Kunci utama Orde Rincian tabel terdiri dari dua bidang - kunci asing dari tabel Orders dan Produk. Menggunakan field ID Ordo saja tidak bekerja sebagai kunci utama untuk meja ini, karena satu urutan dapat memiliki banyak item baris.ID Order diulang untuk setiap item baris dalam pesanan, sehingga lapangan tidak mengandung nilai-nilai yang unik. Menggunakan kolom ID Produk sendiri tidak bekerja baik, karena satu produk dapat muncul atas perintah yang berbeda. Tapi bersama-sama, kedua bidang selalu menghasilkan nilai unik untuk setiap record.
Dalam database penjualan produk, tabel Orders dan tabel Produk tidak berhubungan satu sama lain secara langsung. Sebaliknya, mereka terkait secara tidak langsung melalui tabel Order Details. Hubungan banyak-ke-banyak antara pesanan dan produk diwakili dalam database dengan menggunakan dua hubungan satu-ke-banyak:
  • Tabel Orders dan Order tabel Rincian memiliki hubungan satu-ke-banyak.Setiap pesanan dapat memiliki lebih dari satu item baris, tetapi masing-masing item baris terhubung ke hanya satu urutan.
  • Tabel Produk dan Ketertiban tabel Rincian memiliki hubungan satu-ke-banyak. Setiap produk dapat memiliki banyak item baris terkait dengan itu, tetapi masing-masing item baris hanya mengacu pada satu produk.
Dari tabel Order Details, Anda dapat menentukan semua produk pada urutan tertentu. Anda juga dapat menentukan semua pesanan untuk produk tertentu.
Setelah menggabungkan tabel Order Details, daftar tabel dan bidang mungkin terlihat seperti ini:
List of information items during the design process

MENCIPTAKAN HUBUNGAN SATU-KE-SATU

Tipe lain dari hubungan adalah hubungan satu-ke-satu. Misalnya, Anda perlu untuk merekam beberapa produk informasi tambahan khusus yang akan Anda butuhkan jarang atau yang hanya berlaku untuk beberapa produk. Karena Anda tidak memerlukan informasi sering, dan karena menyimpan informasi dalam tabel Produk akan menghasilkan ruang kosong untuk setiap produk yang tidak berlaku, Anda menempatkannya dalam tabel terpisah. Seperti tabel Produk, Anda menggunakan ProductID sebagai primary key. Hubungan antara tabel ini tambahan dan tabel Produk adalah hubungan satu-ke-satu. Untuk setiap record dalam tabel Produk, terdapat sebuah catatan pencocokan tunggal dalam tabel tambahan. Ketika Anda melakukan mengidentifikasi hubungan tersebut, kedua tabel harus berbagi field umum.
Ketika Anda mendeteksi kebutuhan untuk hubungan satu-ke-satu dalam database Anda, pertimbangkan apakah Anda dapat menempatkan informasi dari dua tabel bersama-sama dalam satu meja. Jika Anda tidak ingin melakukan itu untuk beberapa alasan, mungkin karena itu akan menghasilkan banyak ruang kosong, daftar berikut ini menunjukkan bagaimana Anda akan merepresentasikan hubungan dalam desain Anda:
  • Jika dua tabel memiliki subjek yang sama, Anda mungkin dapat mengatur hubungan dengan menggunakan primary key yang sama di kedua tabel.
  • Jika dua tabel memiliki mata pelajaran yang berbeda dengan kunci primer yang berbeda, pilih salah satu meja (salah satu) dan masukkan primary key di tabel lain sebagai foreign key.
Menentukan hubungan antara tabel membantu Anda memastikan bahwa Anda memiliki tabel yang tepat dan kolom. Ketika hubungan satu-ke-satu atau satu-ke-banyak ada, tabel yang terlibat perlu berbagi kolom biasa atau kolom. Ketika hubungan banyak-ke-banyak ada, meja ketiga diperlukan untuk mewakili hubungan.

Menyempurnakan desain

Setelah Anda memiliki tabel, ladang, dan hubungan Anda butuhkan, Anda harus membuat dan mengisi tabel dengan data sampel dan mencoba bekerja dengan informasi tersebut pada akhirnya membuka query, menambahkan catatan baru, dan sebagainya. Melakukan hal ini akan membantu menyoroti potensi masalah - misalnya, Anda mungkin perlu menambahkan kolom yang Anda lupa untuk menyisipkan selama fase desain Anda, atau Anda mungkin memiliki tabel yang Anda harus membagi menjadi dua tabel untuk menghapus duplikasi.
Lihat apakah Anda dapat menggunakan database untuk mendapatkan jawaban yang Anda inginkan. Buat draft kasar dari formulir Anda dan laporan dan melihat apakah mereka menunjukkan data yang Anda harapkan. Carilah duplikasi yang tidak perlu data dan, ketika Anda menemukan, mengubah desain Anda untuk menghilangkannya.
Ketika Anda mencoba database dasar Anda, Anda mungkin akan menemukan ruang untuk perbaikan. Berikut adalah beberapa hal untuk memeriksa:
  • Apakah Anda lupa kolom? Jika demikian, apakah informasi tersebut termasuk dalam tabel yang ada? Jika informasi tentang sesuatu yang lain, Anda mungkin perlu membuat meja lain. Membuat kolom untuk setiap item informasi yang Anda butuhkan untuk melacak. Jika informasi tidak dapat dihitung dari kolom lain, kemungkinan bahwa Anda akan memerlukan kolom baru untuk itu.
  • Apakah ada kolom yang tidak perlu karena mereka dapat dihitung dari field yang ada? Jika item informasi dapat dihitung dari kolom yang ada lainnya - dengan harga diskon dihitung dari harga eceran, misalnya - biasanya lebih baik untuk melakukan hal itu, dan mencegah timbulnya kolom baru.
  • Apakah Anda berulang kali memasukkan informasi duplikat di salah satu tabel Anda? Jika demikian, Anda mungkin perlu untuk membagi tabel menjadi dua tabel yang memiliki hubungan satu-ke-banyak.
  • Apakah Anda memiliki tabel dengan banyak bidang, sejumlah catatan, dan bidang kosong banyak dalam catatan individu? Jika demikian, berpikir tentang mendesain ulang meja sehingga memiliki bidang yang lebih sedikit dan lebih banyak catatan.
  • Apakah setiap item informasi telah dipecah menjadi bagian-bagian terkecil yang berguna? Jika Anda perlu melaporkan, jenis, mencari, atau menghitung pada item informasi, menempatkan item dalam kolom sendiri.
  • Apakah setiap kolom berisi fakta tentang subjek meja? Jika kolom tidak berisi informasi tentang subjek meja, itu termasuk dalam tabel yang berbeda.
  • Apakah semua hubungan antara tabel diwakili, baik dengan bidang umum atau dengan meja ketiga? Satu-ke-satu dan satu-ke-banyak hubungan memerlukan kolom umum. Banyak-ke-banyak hubungan memerlukan tabel ketiga.

REFINING TABEL PRODUK

Misalkan setiap produk dalam database produk penjualan berada di bawah kategori umum, seperti minuman, bumbu, atau makanan laut. Tabel Produk dapat mencakup bidang yang menunjukkan 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 Description Kategori ke meja Produk, Anda harus mengulangi setiap deskripsi kategori untuk setiap produk yang berada di bawah kategori - ini bukan solusi yang baik.
Solusi yang lebih baik adalah membuat Kategori subjek baru untuk database untuk melacak, dengan meja sendiri dan kunci sendiri utamanya. Anda kemudian dapat menambahkan primary key dari tabel ke tabel Kategori Produk sebagai kunci asing.
Para Kategori dan tabel Produk memiliki hubungan satu-ke-banyak: kategori dapat mencakup lebih dari satu produk, tapi produk dapat dikelompokkan pada hanya satu kategori.
Ketika Anda meninjau struktur tabel Anda, waspada untuk kelompok berulang.Sebagai contoh, perhatikan tabel yang berisi kolom berikut:
  • ID Produk
  • Nama
  • Produk ID1
  • Name1
  • Produk ID2
  • Name2
  • Produk ID3
  • Name3
Di sini, setiap produk adalah sekelompok berulang dari kolom yang berbeda dari yang lain hanya dengan menambahkan nomor ke akhir nama kolom. Bila Anda melihat kolom bernomor cara ini, Anda perlu meninjau ulang desain Anda.
Seperti desain memiliki beberapa kelemahan. Sebagai permulaan, memaksa Anda untuk menempatkan batas atas jumlah produk. Segera setelah Anda melebihi batas itu, Anda harus menambah grup baru dari kolom ke struktur tabel, yang merupakan tugas administratif utama.
Masalah lain adalah bahwa mereka pemasok yang memiliki kurang dari jumlah maksimum produk akan membuang beberapa ruang, karena kolom tambahan akan kosong. Kelemahan yang paling serius dengan desain seperti itu adalah membuat banyak tugas sulit untuk melakukan, seperti sortasi atau mengindeks tabel dengan ID produk atau nama.
Setiap kali Anda melihat kelompok mengulangi meninjau desain erat dengan mata pada pemisahan meja dua. Dalam contoh di atas itu lebih baik menggunakan dua tabel, satu untuk pemasok dan satu untuk produk, dihubungkan oleh ID pemasok.

Menerapkan aturan normalisasi

Anda dapat menerapkan aturan normalisasi data (kadang-kadang aturan normalisasi hanya disebut) sebagai langkah berikutnya dalam desain Anda. Anda menggunakan aturan ini untuk melihat apakah tabel Anda terstruktur dengan benar. Proses penerapan aturan untuk desain database Anda disebut normalisasi database, atau hanya normalisasi.
Normalisasi adalah yang paling berguna setelah Anda telah mewakili semua item informasi dan telah tiba di desain awal. Idenya adalah untuk membantu Anda memastikan bahwa Anda telah membagi item informasi Anda ke dalam tabel yang sesuai. Apa normalisasi tidak bisa lakukan adalah memastikan bahwa Anda memiliki semua item data yang benar untuk mulai dengan.
Anda menerapkan aturan berturut-turut, pada setiap langkah untuk memastikan bahwa desain Anda tiba di salah satu apa yang dikenal sebagai "bentuk normal".Lima bentuk normal diterima secara luas - bentuk normal pertama melalui bentuk normal kelima. Artikel ini memperluas tiga pertama, karena mereka semua yang diperlukan untuk sebagian besar desain database.

PERTAMA BENTUK NORMAL

Bentuk normal pertama menyatakan bahwa pada setiap baris dan persimpangan kolom dalam tabel di sana, ada nilai tunggal, dan tidak pernah daftar nilai.Misalnya, Anda tidak bisa memiliki lapangan bernama Harga di mana Anda menempatkan lebih dari satu harga. Jika Anda memikirkan setiap persimpangan dari baris dan kolom sebagai sel, setiap sel dapat menyimpan satu nilai.

BENTUK NORMAL KEDUA

Bentuk normal kedua mensyaratkan bahwa setiap kolom non-kunci sepenuhnya tergantung pada kunci primer secara keseluruhan, tidak hanya pada bagian dari kunci. Aturan ini berlaku ketika Anda memiliki primary key yang terdiri dari lebih dari satu kolom. Misalnya, Anda memiliki tabel yang berisi kolom berikut, di mana Orde ID dan bentuk ID Produk kunci utama:
  • Orde ID (primary key)
  • ID Produk (primary key)
  • Nama Produk
Desain ini melanggar bentuk normal kedua, karena Nama Produk tergantung pada ID produk, tapi tidak di ID Order, sehingga tidak tergantung pada primary key secara keseluruhan. Anda harus menghapus Nama Produk dari meja. Itu termasuk dalam tabel yang berbeda (Produk).

BENTUK NORMAL KETIGA

Bentuk normal ketiga mensyaratkan bahwa tidak hanya setiap kolom non-key tergantung pada kunci utama seluruh, tetapi bahwa non-key kolom menjadi independen satu sama lain.
Cara lain untuk mengatakan ini adalah bahwa setiap kolom non-kunci harus tergantung pada primary key dan hanya primary key. Misalnya, Anda memiliki tabel yang berisi kolom berikut:
  • ProductID (primary key)
  • Nama
  • SRP
  • Diskon
Asumsikan Diskon yang tergantung pada harga eceran yang disarankan (SRP).Tabel ini melanggar bentuk normal ketiga karena kolom yang tidak penting, Diskon, tergantung pada kolom lain non-key, SRP. Kemerdekaan Kolom berarti bahwa Anda harus dapat mengubah kolom non-kunci tanpa mempengaruhi kolom lain. Jika Anda mengubah nilai dalam bidang SRP, Discount akan berubah sesuai, sehingga melanggar peraturan itu. Dalam hal ini Diskon harus dipindahkan ke meja lain yang mengetik di SRP.