Cara Membuat Desain Database

Cara Membuat Desain Database

Pengantar desain database

Ini artikel / tutorial akan mengajarkan dasar desain database relasional dan menjelaskan bagaimana membuat desain database yang baik . Ini adalah teks agak panjang , tapi kami menyarankan untuk membaca semua itu . Merancang database sebenarnya cukup mudah , tetapi ada beberapa aturan untuk menempel . Hal ini penting untuk mengetahui apa aturan ini , tetapi yang lebih penting adalah untuk mengetahui mengapa aturan ini ada, jika tidak, anda akan cenderung membuat kesalahan !

Standardisasi membuat model data Anda fleksibel dan yang membuat bekerja dengan data Anda jauh lebih mudah . Silakan , meluangkan waktu untuk mempelajari aturan-aturan ini dan menerapkannya ! Database yang digunakan dalam artikel ini dirancang dengan desain database dan pemodelan alat kami Design untuk Database .

Sebuah desain database yang baik dimulai dengan daftar data yang ingin Anda sertakan dalam database Anda dan apa yang Anda ingin bisa melakukan dengan database nanti . Semua ini dapat ditulis dalam bahasa Anda sendiri , tanpa SQL apapun. Pada tahap ini Anda harus mencoba untuk tidak berpikir dalam tabel atau kolom , tapi hanya berpikir : " Apa yang saya perlu tahu " Jangan mengambil terlalu ringan , karena jika Anda menemukan kemudian bahwa Anda lupa sesuatu , biasanya Anda harus mulai dari awal . Menambahkan hal-hal ke database Anda adalah sebagian besar banyak pekerjaan .

mengidentifikasi Entitas

Jenis-jenis informasi yang disimpan dalam database disebut ' entitas ' . Entitas ini ada dalam empat jenis : orang, benda, peristiwa , dan lokasi . Segala sesuatu yang Anda inginkan untuk dimasukkan ke dalam database cocok dengan salah satu kategori ini . Jika informasi yang ingin Anda sertakan tidak cocok ke dalam kategori ini , daripada mungkin bukan entitas tetapi milik entitas , atribut .

Untuk memperjelas informasi yang diberikan dalam artikel ini kita akan menggunakan contoh . Bayangkan bahwa Anda membuat website untuk toko , apa jenis informasi yang Anda harus berurusan dengan ? Di toko Anda menjual produk Anda kepada pelanggan . The " Toko " adalah lokasi ; " Sale " merupakan acara ; " Produk " hal-hal , dan " Pelanggan " adalah orang-orang . Ini semua adalah entitas yang perlu dimasukkan dalam database Anda .

Tapi apa hal-hal lain yang terjadi ketika menjual produk? Seorang pelanggan datang ke toko , pendekatan vendor , mengajukan pertanyaan dan mendapatkan jawaban . " Vendor " juga berpartisipasi , dan karena vendor adalah orang-orang , kami membutuhkan entitas vendor .

                                                 Gambar 1 : Entitas : jenis informasi .

Mengidentifikasi Hubungan

Langkah selanjutnya adalah menentukan hubungan antara entitas dan menentukan kardinalitas setiap hubungan . Hubungan adalah hubungan antara entitas , seperti di dunia nyata : apa satu kesatuan dengan yang lain , bagaimana mereka berhubungan satu sama lain ? Sebagai contoh, pelanggan membeli produk , produk yang dijual kepada pelanggan , penjualan terdiri dari produk , penjualan terjadi di toko .

Kardinalitas menunjukkan berapa banyak dari satu sisi hubungan milik berapa banyak sisi lain dari hubungan. Pertama , Anda perlu menyatakan untuk setiap hubungan , berapa banyak dari satu sisi milik tepat 1 dari sisi lain . Misalnya : Berapa banyak pelanggan milik 1 penjualan; Berapa banyak penjualan milik 1 customer ; Berapa banyak penjualan terjadi di 1 toko ? ?

Anda akan mendapatkan daftar seperti ini : ( harap dicatat bahwa ' produk ' merupakan jenis produk , tidak terjadinya suatu produk )

Pelanggan - > Penjualan ; 1 pelanggan dapat membeli sesuatu beberapa kali

Penjualan - > Pelanggan ; 1 penjualan selalu dibuat oleh 1 pelanggan pada saat itu

Pelanggan - > produk ; 1 pelanggan dapat membeli beberapa produk

Produk - > Pelanggan , produk 1 dapat dibeli oleh beberapa pelanggan

Pelanggan - > Toko; 1 pelanggan dapat membeli di beberapa toko

Toko - > Pelanggan , 1 toko dapat menerima beberapa pelanggan

Toko - > produk , dalam 1 toko ada beberapa produk

Produk - > Toko; 1 produk ( jenis ) dapat dijual di beberapa toko

Toko - > Penjualan , dalam 1 beberapa toko penjualan dapat saya dibuat

Penjualan - > Toko; 1 penjualan hanya dapat dilakukan dalam 1 toko pada saat itu

Produk - > Penjualan ; 1 produk ( jenis ) dapat dibeli dalam beberapa penjualan

Penjualan - > produk ; 1 penjualan bisa eksis dari beberapa produk

Apakah kita menyebutkan semua hubungan ? Ada empat entitas dan setiap entitas memiliki hubungan dengan setiap entitas lain , sehingga setiap entitas harus memiliki tiga hubungan, dan juga muncul di ujung kiri hubungan tiga kali . Di atas , 12 hubungan yang disebutkan , yaitu 4 * 3 , sehingga kita dapat menyimpulkan bahwa semua hubungan yang disebutkan.

Sekarang kita akan menempatkan data bersama-sama untuk menemukan kardinalitas seluruh hubungan . Untuk melakukan hal ini , kita akan menyusun kardinalitas per hubungan . Untuk membuat ini mudah dilakukan , kami akan menyesuaikan notasi sedikit , dengan mencatat ' backward' - hubungan sebaliknya :

Pelanggan - > Penjualan ; 1 pelanggan dapat membeli sesuatu beberapa kali

Penjualan - > Pelanggan ; 1 penjualan selalu dibuat oleh 1 pelanggan 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 penjualan selalu dibuat oleh 1 pelanggan pada saat itu

Kardinalitas ada dalam empat jenis : satu - ke-satu , satu-ke - banyak, banyak - ke-satu , dan banyak - ke-banyak . Dalam desain 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 itu ditandai dengan ' N ' .

Pelanggan - > Penjualan ; 1 pelanggan dapat membeli sesuatu beberapa kali ; 1 : N.

Pelanggan < - Penjualan ; 1 penjualan selalu dibuat oleh 1 pelanggan pada saat itu; 1:1.

Kardinalitas benar dapat dihitung melalui menempatkan nilai terbesar untuk kiri dan kanan , yang ' N ' atau 'M ' lebih besar dari '1 ' . Dalam thisexample , dalam kedua kasus ada '1 ' di sisi kiri . Di sisi kanan , ada ' N ' dan '1 ' , ' N ' adalah nilai terbesar . Oleh karena itu, total kardinalitas adalah '1 : N ' . Seorang 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 '1 - ke-banyak ' hubungan , dan empat ' banyak-ke - banyak ' hubungan .

                                                      Gambar 2 : Hubungan antara entitas .

Antara entitas mungkin ada saling ketergantungan . Ini berarti bahwa satu item tidak bisa eksis jika item yang lain 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, tetapi sebaliknya hal ini tidak terjadi . Pelanggan bisa ada tanpa penjualan, dan juga produk dapat eksis tanpa penjualan . Hal ini penting untuk langkah berikutnya .

Hubungan rekursif

Kadang-kadang suatu entitas mengacu kembali ke dirinya sendiri . Misalnya, memikirkan sebuah hirarki kerja : karyawan memiliki bos , dan bosschef adalah seorang karyawan juga. Atribut ' bos' dari ' karyawan ' entitas merujuk kembali ke ' karyawan ' entitas .

Dalam ERD ( lihat bab berikutnya ) jenis hubungan adalah garis yang keluar dari entitas dan kembali dengan loop bagus untuk entitas yang sama .

Hubungan redundant

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 hubungan antara pelanggan dan produk melalui penjualan . ' Pelanggan < ---- > produk ' Hubungan ini dilakukan dua kali , dan salah satunya adalah karena itu berlebihan . Dalam hal ini , produk yang hanya dibeli melalui penjualan , sehingga ' Pelanggan < ---- > produk ' hubungan dapat dihapus . Model ini kemudian akan terlihat seperti ini :

                                                 Gambar 3 : Hubungan antara entitas .

Memecahkan Banyak-ke- Banyak Hubungan

Banyak - ke-banyak hubungan ( M : N ) tidak 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 ini dan solusinya adalah untuk membagi hubungan dalam dua hubungan one- to-many .

Hal ini dapat dilakukan dengan membuat entitas baru yang ada di antara entitas terkait . Dalam contoh kita , ada banyak-ke - banyak hubungan antara penjualan dan produk . Hal ini dapat diselesaikan dengan membuat 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 tabel link atau tabel persimpangan .

                           Gambar 4 : Banyak hubungan banyak implementasi melalui entitas asosiatif .

Dalam contoh ada dua banyak-ke - banyak hubungan yang perlu dipecahkan : ' Produk < ---- > Penjualan ' , dan ' Produk < ---- > Toko ' . Untuk kedua situasi ada perlu dibuat entitas baru , tapi apa entitas itu?

Untuk Produk < ---- > hubungan Penjualan , setiap penjualan mencakup lebih banyak produk . Hubungan ini menunjukkan isi dari penjualan. Dengan kata lain, memberikan rincian tentang penjualan. Jadi entitas disebut ' Penjualan detail ' . Anda juga bisa nama itu produk yang dijual ' .

Produk < ---- > hubungan Toko menunjukkan produk mana yang tersedia di mana toko-toko , juga dikenal sebagai ' saham ' . Model kami sekarang akan terlihat seperti ini :

                               Gambar 5 : Model dengan link tabel Stock dan Sales_details .

Mengidentifikasi Atribut

Elemen-elemen data yang ingin Anda simpan untuk setiap entitas disebut ' atribut ' .

Tentang produk yang Anda jual , Anda ingin tahu , misalnya , berapa harganya , apa nama pabriknya , dan apa jenis nomor tersebut. Tentang pelanggan Anda tahu jumlah mereka pelanggan, 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 penjualan. Vendor Anda tahu nomor stafnya , nama , dan alamat . Apa yang akan dimasukkan justru tidak penting belum, itu masih hanya tentang apa yang Anda ingin menyimpan .

Gambar 6 : Entitas dengan atribut .

Asal Data 

Data yang berasal adalah data yang berasal dari data lain yang Anda telah disimpan. Dalam hal ini ' jumlah total ' adalah kasus klasik dari data yang berasal . Anda tahu persis apa yang telah dijual dan apa yang masing-masing biaya produk , sehingga Anda selalu dapat menghitung berapa banyak jumlah total 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 dijual dengan harga € 10 hari dan pada 8 euro bulan depan , dan untuk administrasi Anda, Anda perlu tahu apa biaya pada saat penjualan , dan cara termudah untuk melakukannya adalah dengan menyimpannya di sini . Ada banyak cara yang lebih elegan , tetapi mereka terlalu mendalam untuk artikel ini .

Menyajikan Entitas dan Hubungan : Entity Relationship Diagram ( ERD )

The Entity Relationship Diagram ( ERD ) memberikan gambaran grafis dari database . Ada beberapa gaya dan jenis ER Diagram . Sebuah notasi yang banyak digunakan adalah ' crowfeet ' notasi , di mana entitas direpresentasikan sebagai persegi panjang dan hubungan antara entitas yang direpresentasikan sebagai garis antara entitas . Tanda-tanda pada akhir baris menunjukkan jenis hubungan . Sisi hubungan yang wajib bagi yang lain untuk ada akan ditunjukkan melalui dasbor di telepon . Entitas tidak wajib ditunjukkan melalui lingkaran . " Banyak " ditunjukkan melalui ' crowfeet '; de hubungan -line terpecah dalam tiga baris .

Dalam artikel ini kita memanfaatkan Dezign untuk Database untuk merancang dan menyajikan database kami .

Sebuah 01:01 Hubungan wajib direpresentasikan sebagai berikut :

                                                      Gambar 7 : Wajib 1-1 hubungan .

A 1 : N hubungan wajib :

                                                Gambar 8 : Wajib satu ke banyak hubungan .

A M : N hubungan adalah :

                                             Gambar 9 : Wajib banyak hubungan banyak .

Model contoh kita akan terlihat seperti ini :

                                               Gambar 10 : Model dengan hubungan 

Menetapkan Keys 

Kunci Primer

Sebuah kunci primer ( PK ) adalah satu atau lebih atribut data yang secara unik mengidentifikasi suatu entitas . Sebuah kunci yang terdiri dari dua atau lebih atribut disebut kunci komposit . Semua atribut bagian dari primary key harus memiliki nilai dalam setiap catatan ( yang tidak dapat dibiarkan kosong ) dan kombinasi dari nilai-nilai dalam atribut ini harus unik dalam tabel .

Dalam contoh ada calon yang jelas untuk beberapa primary key . Pelanggan semua memiliki nomor pelanggan , produk semua memiliki nomor produk yang unik dan penjualan memiliki sejumlah penjualan . Masing-masing data ini unik dan setiap record akan berisi nilai , sehingga atribut ini dapat menjadi kunci utama . Seringkali sebuah kolom integer digunakan untuk primary key sehingga catatan dapat dengan mudah ditemukan melalui nomor tersebut.

Link- entitas biasanya mengacu pada atribut primary key dari entitas yang mereka link . Kunci utama dari link - entitas biasanya koleksi referensi - atribut ini . Misalnya dalam entitas Sales_details kita bisa menggunakan kombinasi dari PK dari entitas penjualan dan produk sebagai PK dari Sales_details . Dengan cara ini kita menegakkan bahwa produk yang sama ( jenis ) hanya dapat digunakan sekali dalam penjualan yang sama . Beberapa item dari jenis produk yang sama dalam penjualan harus ditunjukkan oleh kuantitas .

Dalam ERD atribut primary key ditandai dengan teks ' PK ' di belakang nama atribut . Dalam contoh satu-satunya entitas 'toko' tidak memiliki calon yang jelas untuk PK , jadi kami akan memperkenalkan atribut baru untuk entitas yang : shopnr .

Tombol asing

The Foreign Key ( FK ) dalam suatu entitas yang menjadi acuan untuk primary key dari entitas lain . Dalam ERD atribut yang akan ditandai dengan ' FK ' di belakang namanya . Kunci asing dari suatu entitas juga dapat menjadi bagian dari primary key , dalam hal bahwa atribut akan ditandai dengan ' PF ' di belakang namanya . Hal ini biasanya terjadi dengan link- entitas , karena Anda biasanya menghubungkan dua contoh hanya sekali bersama-sama ( dengan 1 penjualan hanya 1 jenis produk yang dijual 1 kali ) .

Jika kita meletakkan semua link- entitas , PK dan FK ke dalam ERD , kita mendapatkan model seperti yang ditunjukkan di bawah ini . Harap dicatat bahwa ' produk ' atribut tidak lagi diperlukan dalam ' Penjualan ' , karena ' produk yang dijual ' sekarang termasuk dalam link - tabel . Dalam link - tabel bidang lain ditambahkan , ' kuantitas ' , yang menunjukkan berapa banyak produk yang dijual . Bidang kuantitas juga ditambahkan pada saham - tabel , untuk menunjukkan berapa banyak produk yang masih di toko .

                                              Gambar 11 : kunci primer dan kunci asing .

Mendefinisikan Atribut ini Jenis Data

Sekarang saatnya untuk mencari tahu mana tipe data harus digunakan untuk atribut . Ada banyak tipe data yang berbeda . Beberapa yang standar , tetapi banyak database memiliki tipe data mereka sendiri bahwa semua memiliki keunggulan sendiri . Beberapa database offerthe kemungkinan untuk menentukan jenis data Anda sendiri , dalam hal jenis standar tidak dapat melakukan hal-hal yang Anda butuhkan .

Tipe data standar bahwa setiap database yang tahu , dan paling banyak digunakan , adalah : CHAR , VARCHAR , TEXT , FLOAT , DOUBLE , dan INT .

teks :

CHAR ( panjang ) - termasuk teks ( karakter , angka, tanda baca ... ) . CHAR memiliki sebagai ciri yang selalu menyimpan jumlah yang tetap posisi . Jika anda mendefinisikan suatu CHAR ( 10 ) Anda dapat menyimpan hingga sepuluh posisi maksimum , tetapi jika Anda hanya menggunakan dua posisi database masih akan menghemat 10 posisi . Sisanya delapan posisi akan diisi oleh spasi .

VARCHAR ( panjang ) - termasuk teks ( karakter , angka, tanda baca ... ) . VARCHAR adalah sama seperti CHAR , perbedaannya adalah bahwa VARCHAR hanya membutuhkan ruang sebanyak yang diperlukan .

TEKS - dapat berisi sejumlah besar teks . Tergantung pada jenis database ini dapat menambahkan hingga gigabyte .

nomor :

INT - berisi seluruh angka positif atau negatif . Banyak database memiliki variasi INT , seperti TINYINT , SMALLINT , MEDIUMINT , BIGINT , INT2 , INT4 , int8 . Variasi ini berbeda dari INT hanya dalam ukuran angka yang sesuai ke dalamnya . Sebuah INT biasa adalah 4 byte ( INT4 ) dan cocok angka dari -2147483647 sampai 2147483646 , atau jika anda mendefinisikan sebagai UNSIGNED 0-4294967296 . The int8 , atau BIGINT , bisa mendapatkan bahkan lebih besar dalam ukuran , 0-18446744073709551616 , tetapi memakan waktu sampai 8 byte diskspace , bahkan jika hanya ada sejumlah kecil di dalamnya .

FLOAT , DOUBLE - Ide yang sama seperti INT , tetapi juga dapat menyimpan angka floating point . . Apakah dicatat bahwa ini tidak selalu bekerja dengan sempurna . Misalnya di MySQL menghitung dengan angka-angka floating point tidak sempurna , ( 1/3 ) * 3 akan menghasilkan dengan mengapung MySQL di 0,9999999 , bukan 1 .

Jenis lain :

Blob - untuk data biner seperti files.INET - untuk alamat IP . Juga bisa digunakan untuk netmasks .

Sebagai contoh kita tipe data adalah sebagai berikut :

                                              Gambar 12 : Data model menampilkan tipe data .

Normalisasi

Normalisasi membuat model data Anda fleksibel dan dapat diandalkan . Itu menghasilkan beberapa overhead karena Anda biasanya mendapatkan lebih tabel , tetapi memungkinkan Anda untuk melakukan banyak hal dengan model data Anda tanpa harus menyesuaikan .

Normalisasi , Formulir Pertama

Bentuk pertama dari normalisasi menyatakan bahwa mungkin tidak ada kelompok mengulangi kolom dalam suatu entitas . Kita bisa menciptakan entitas ' penjualan ' dengan atribut untuk masing-masing produk yang dibeli . Ini akan terlihat seperti ini :

                                              Gambar 13 : Tidak dalam bentuk normal 1.

Apa yang salah tentang hal ini adalah bahwa sekarang hanya 3 produk bisa dijual . Jika Anda harus menjual 4 produk , daripada Anda harus memulai penjualan kedua atau menyesuaikan model data Anda dengan menambahkan atribut ' product4 ' . Kedua solusi yang tidak diinginkan . Dalam kasus ini anda harus selalu membuat sebuah entitas baru yang Anda link ke yang lama melalui hubungan one- to-many .

                                               Gambar 14 : Sesuai dengan bentuk normal 1 .

Normalisasi , Formulir Kedua

Bentuk kedua dari normalisasi menyatakan bahwa semua atribut dari suatu entitas harus sepenuhnya tergantung pada seluruh kunci primer . Ini berarti bahwa setiap atribut dari sebuah entitas hanya dapat diidentifikasi melalui seluruh primary key . Misalkan kita memiliki tanggal dalam entitas Sales_details :

dinormalisasi ( primary key )

Gambar 15 : Tidak dalam bentuk normal 2.

Entitas ini tidak sesuai bentuk normalisasi kedua , karena untuk dapat mencari tanggal penjualan , saya tidak perlu tahu apa yang dijual ( productnr ) , satu-satunya hal yang saya perlu tahu adalah jumlah penjualan . Hal ini diselesaikan dengan berpisah tabel ke dalam penjualan dan tabel Sales_details :

                                            Gambar 16 : Sesuai dengan bentuk normal 2.

Sekarang setiap atribut dari entitas tergantung pada seluruh PK dari entitas . Tanggal ini tergantung pada jumlah penjualan , dan kuantitas tergantung pada jumlah penjualan dan produk yang dijual .

Normalisasi , Formulir Ketiga

Bentuk ketiga normalisasi menyatakan bahwa semua atribut harus langsung tergantung pada primary key , dan bukan pada atribut lainnya . Hal ini tampaknya menjadi apa bentuk kedua negara normalisasi , tetapi dalam bentuk kedua sebenarnya menyatakan sebaliknya . Dalam bentuk kedua normalisasi Anda menunjukkan atribut melalui PK , dalam bentuk ketiga normalisasi setiap atribut harus tergantung pada PK , dan tidak ada lagi .

                                             Gambar 17 : Tidak dalam bentuk normal 3 .

Dalam hal ini harga produk longgar tergantung pada jumlah pemesanan, dan jumlah pemesanan adalah tergantung pada jumlah produk dan jumlah penjualan . Ini bukan sesuai dengan bentuk ketiga normalisasi . Sekali lagi , berpisah tabel memecahkan ini.

                                                 Gambar 18 : Sesuai dengan bentuk normal 3 .

Normalisasi , Lebih Forms

Ada bentuk-bentuk normalisasi lebih dari tiga bentuk yang disebutkan di atas , tetapi mereka tidak menarik untuk rata-rata pengguna . Bentuk-bentuk lain yang sangat khusus untuk aplikasi tertentu . Jika Anda tetap berpegang pada aturan desain dan normalisasi disebutkan dalam artikel ini , Anda akan membuat desain yang bekerja bagus untuk sebagian besar aplikasi .

Normalized Data Model

Jika Anda menerapkan aturan normalisasi , Anda akan menemukan bahwa ' produsen ' dalam tabel produk de juga harus menjadi tabel terpisah :

Gambar 19 : Model data sesuai dengan 1, 2 dan bentuk normal 3d .

glosarium

Atribut - data rinci tentang suatu entitas , seperti harga , panjang , nama

Kardinalitas - hubungan antara dua entitas , dalam angka . Sebagai contoh, seseorang dapat menempatkan beberapa perintah .

Entitas - data abstrak yang Anda simpan dalam database . Sebagai contoh: pelanggan , produk .

Foreign key ( FK ) - rujukan ke Primary Key dari meja lain . Asing Key - kolom hanya dapat berisi nilai-nilai yang ada di kolom Primary Key yang mereka lihat .

Kunci - kunci yang digunakan untuk menunjukkan catatan . Kuncinya paling terkenal adalah Primary Key (lihat Primary Key ) .

Normalisasi - Sebuah model data yang fleksibel perlu mengikuti aturan-aturan tertentu . Menerapkan aturan-aturan ini disebut normalisasi .

Kunci utama - satu atau lebih kolom dalam tabel yang bersama-sama membentuk kombinasi unik dari nilai-nilai yang masing-masing record dapat ditunjukkan secara terpisah . Sebagai contoh: nomor pelanggan, atau nomor seri produk

Cara Membuat Desain Database