Sekarang kita akan menempatkan data bersama-sama untuk menemukan kardinalitas seluruh hubungan. Untuk melakukan hal ini, kita akan menyusun rancangan kardinalitas per hubungan. Untuk membuat ini mudah dilakukan, kami akan menyesuaikan notasi sedikit, dengan mencatat 'backward'-hubungan sebaliknya:
Pelanggan -> Penjualan, pelanggan dapat membeli sesuatu atau beberapa barang 1 kali dalam satu waktu
Penjualan -> Pelanggan, 1 barang yang dijual selalu dibuat oleh 1 customer pada saat itu
Hubungan kedua kita akan berbalik sehingga memiliki urutan entitas yang sama seperti yang pertama. Harap perhatikan panah yang kini dihadapi dengan cara lain!
Pelanggan <- Penjualan, 1 barang yang dijual selalu dibuat oleh 1 customer pada saat itu
Kardinalitas ada dalam empat jenis: satu-ke-satu, satu-ke-banyak, banyak-ke-satu, dan banyak-ke-banyak. Dalam design database ini diindikasikan sebagai: 1:1, 1: N, M: 1, dan M: N. Untuk menemukan indikasi yang tepat hanya meninggalkan '1 '. Jika ada 'banyak' di sisi kiri, ini akan ditandai dengan 'M', jika ada 'banyak' di sisi kanan ditandai dengan 'N'.
Pelanggan -> Penjualan, pelanggan dapat membeli 1 kali sesuatu yang beberapa; 1: N.
Pelanggan <- Penjualan, 1 barang yang dijual selalu dibuat oleh 1 customer pada saat itu; 1:1.
Kardinalitas benar dapat dihitung melalui menempatkan nilai terbesar bagi kiri dan kanan, yang 'N' atau 'M' yang lebih besar dari '1 '. Dalam contoh berikut, dalam kedua kasus ada ''1 di sisi kiri. Di sisi kanan, ada 'N' dan '1 ',' N 'adalah nilai terbesar. Kardinalitas total karena '1: N '. Pelanggan dapat membuat beberapa 'penjualan', tetapi masing-masing 'dijual' hanya memiliki satu pelanggan.
Jika kita melakukan ini untuk hubungan lain juga, kita akan mendapatkan:
Pelanggan -> Penjualan; -> 1: N
Pelanggan -> Produk; -> M: N
Pelanggan -> Toko; -> M: N
Penjualan -> Produk; -> M: N
Toko -> Penjualan; -> 1: N
Toko -> Produk; -> M: N
Jadi, kita memiliki dua 'hubungan, dan empat' '1-ke-banyak hubungan banyak-ke-banyak '.
Antara entitas mungkin ada saling ketergantungan. Ini berarti bahwa salah satu item tidak bisa eksis jika item lainnya tidak ada. Sebagai contoh, tidak mungkin ada penjualan jika tidak ada pelanggan, dan tidak mungkin ada penjualan jika tidak ada produk.
Hubungan Penjualan -> Pelanggan, dan Penjualan -> Produk yang wajib, namun sebaliknya hal ini tidak terjadi. Pelanggan dapat ada tanpa penjualan, dan juga produk dapat eksis tanpa dijual. Ini sangat penting untuk langkah berikutnya.
Rekursif Hubungan
Kadang-kadang suatu entitas mengacu kembali ke dirinya sendiri. Misalnya, memikirkan hirarki kerja: seorang karyawan memiliki bos, dan bosschef adalah seorang karyawan juga. 'Bos' atribut 'karyawan' entitas mengacu kembali ke 'karyawan' entitas.
Dalam ERD (lihat pada artikel berikutnya) ini jenis hubungan adalah garis yang keluar dari badan dan kembali dengan loop bagus untuk entitas yang sama.
Redundant Hubungan
Kadang-kadang dalam model Anda, Anda akan mendapatkan 'hubungan berlebihan'. Ini adalah hubungan yang sudah ditunjukkan oleh hubungan lain, meskipun tidak secara langsung.
Dalam kasus contoh kita ada hubungan langsung antara pelanggan dan produk. Tapi ada juga hubungan dari pelanggan untuk penjualan dan dari penjualan produk, sehingga secara tidak langsung sudah ada adalah hubungan antara pelanggan dan produk melalui penjualan. 'Pelanggan <----> Produk' Hubungan ini dilakukan dua kali, dan salah satunya adalah karena berlebihan. Dalam hal ini, produk hanya dibeli melalui penjualan, sehingga hubungan 'Pelanggan <----> Produk' dapat dihapus. Model kemudian akan terlihat seperti ini:
Menyelesaikan Banyak-ke-Banyak Hubungan
Banyak-ke-banyak hubungan (M: N) tidak secara langsung mungkin dalam database. Apa M: hubungan N mengatakan bahwa sejumlah catatan dari satu meja milik sejumlah catatan dari meja lain. Di suatu tempat Anda perlu untuk menyimpan yang merekam dan ini adalah solusinya adalah untuk membagi hubungan dalam dua satu-ke-banyak hubungan.
Hal ini dapat dilakukan dengan menciptakan sebuah entitas baru yang ada di antara entitas terkait. Dalam contoh kita, ada hubungan banyak-ke-banyak antara penjualan dan produk. Hal ini dapat diatasi dengan menciptakan sebuah entitas baru: penjualan-produk. Entitas ini memiliki hubungan banyak-ke-satu dengan penjualan, dan hubungan banyak-ke-satu dengan Produk. Dalam model logis ini disebut entitas asosiatif dan dalam hal database fisik ini disebut link tabel atau meja persimpangan.
Dalam contoh ada dua banyak-ke-banyak hubungan yang perlu dipecahkan: "Produk <----> Penjualan ', dan' Produk <----> Toko '. Untuk kedua situasi ada perlu dibuat suatu entitas baru, tapi apa entitas itu?
Untuk Produk <----> Penjualan hubungan, setiap penjualan meliputi lebih banyak produk. Hubungan menunjukkan isi dari penjualan. Dengan kata lain, memberikan rincian tentang penjualan. Jadi entitas disebut 'Penjualan detail'. Anda juga bisa nama 'produk yang dijual' itu.
The Produk <----> menunjukkan hubungan Toko yang produk yang tersedia di mana toko-toko, juga dikenal sebagai 'saham'. Model kami sekarang akan terlihat seperti ini:
Mengidentifikasi Atribut
Elemen data yang ingin Anda simpan untuk setiap entitas disebut 'atribut'.
Tentang produk yang Anda jual, Anda ingin tahu, misalnya, apa harga adalah, apa nama pabriknya, dan apa nomor tipe. Tentang pelanggan Anda tahu nomor pelanggan mereka, nama mereka, dan alamat. Tentang toko Anda tahu kode lokasi, nama, alamat. Dari penjualan Anda tahu ketika mereka terjadi, di mana toko, produk apa yang dijual, dan jumlah total dari penjualan. Dari vendor Anda tahu nomor stafnya, nama, dan alamat. Apa yang akan dimasukkan secara tepat tidak penting lagi, itu masih hanya tentang apa yang Anda ingin menyimpan.
Source data
Data yang diperoleh adalah data yang berasal dari data lain yang Anda sudah disimpan. Dalam hal ini 'jumlah total' adalah kasus klasik data yang berasal. Anda tahu persis apa yang telah dijual dan berapa yang masing-masing biaya produk, sehingga Anda selalu dapat menghitung berapa banyak jumlah total dari penjualan. Jadi benar-benar tidak perlu untuk menyimpan jumlah total.
Jadi mengapa itu disimpan di sini? Nah, karena itu adalah penjualan, dan harga produk dapat bervariasi dari waktu ke waktu. Sebuah produk dapat harga di 10 euro hari ini dan pada 8 euro bulan depan, dan untuk administrasi Anda, Anda perlu tahu apa yang biaya pada saat penjualan, dan cara termudah untuk melakukannya adalah dengan menyimpannya di sini. Ada banyak cara yang lebih elegan, tetapi untuk nerengkan hal tersebut saya kira terlalu mendalam untuk artikel ini.
Menyajikan Entitas dan Hubungan: Diagram (ERD)
Entity Relationship Diagram (ERD) memberikan gambaran grafis dari database. Ada beberapa tipe dan jenis Diagram ER. Sebuah notasi yang banyak digunakan adalah 'crowfeet' notasi, di mana entitas yang direpresentasikan sebagai persegi panjang dan hubungan antara entitas yang direpresentasikan sebagai garis antara entitas. Tanda-tanda di ujung garis menunjukkan jenis hubungan. Sisi hubungan yang wajib bagi yang lain untuk eksis akan ditunjukkan melalui dasbor di telepon. Tidak entitas wajib ditunjukkan melalui lingkaran. "Banyak" ditunjukkan melalui 'crowfeet'; de hubungan-line terpecah dalam tiga baris.
Creatif By : Putra Bumi | Tempat Pembelajaran Database
Terimah Kasih telah membaca artikel Pengenalan Terhadap Design Database Part2. Yang ditulis oleh Putra Bumi .Pada hariJumat, 26 April 2013. Jika Anda menyukai Artikel di blog ini, Silahkan klik disini untuk berlangganan gratis via email, dengan begitu Anda akan mendapat kiriman artikel setiap ada artikel yang terbit di blog ilmu database.
0 komentar :
Posting Komentar