Merancang model database dalam hal "entity-relationship". Entitas database dan atributnya Apa yang dimaksud dengan entitas dalam database? Contoh

sebutan.

Entitas inti (inti) adalah entitas independen (akan didefinisikan dalam beberapa detail di bawah).

Dalam contoh yang dipertimbangkan sebelumnya, batangnya adalah "Mahasiswa", "Apartemen", "Pria", "Dokter", "Perkawinan" (dari contoh 2.2) dan lainnya, yang namanya ditempatkan dalam persegi panjang.

Entitas asosiatif (asosiasi) adalah hubungan banyak-ke-banyak ("-ke-banyak", dll.) antara dua atau lebih entitas atau instance entitas (seperti dalam Contoh 2.4). Asosiasi diperlakukan sebagai entitas penuh:

mereka dapat berpartisipasi dalam asosiasi dan penunjukan lain dengan cara yang sama seperti entitas inti;

mungkin memiliki properti, mis. tidak hanya memiliki satu set atribut kunci yang diperlukan untuk menunjukkan hubungan, tetapi juga sejumlah atribut lain yang mencirikan hubungan. Misalnya, asosiasi "Perkawinan" dari contoh 2.1 dan 2.4 berisi atribut kunci "Kode_M", "Kode_F" dan "Nomor personel suami", "Nomor personel istri", serta atribut kualifikasi "Nomor sertifikat", "Tanggal pendaftaran ", "Registration_place "," Jumlah entri di buku kantor pendaftaran ", dll.

Entitas karakteristik (ciri) adalah hubungan banyak-ke-satu atau satu-ke-satu antara dua entitas (kasus khusus dari suatu asosiasi). Satu-satunya tujuan karakteristik dalam area subjek yang dipertimbangkan adalah untuk menggambarkan atau mengklarifikasi beberapa entitas lain. Kebutuhan akan mereka muncul karena fakta bahwa entitas dunia nyata terkadang memiliki properti bernilai ganda. Seorang suami dapat memiliki beberapa istri (contoh 2.3), sebuah buku dapat memiliki beberapa karakteristik cetak ulang (dikoreksi, ditambah, direvisi, ...), dll.

Eksistensi suatu sifat bergantung sepenuhnya pada entitas yang dicirikan: perempuan kehilangan status istri jika suaminya meninggal.

Untuk menggambarkan ciri tersebut digunakan kalimat JIM baru, yang pada umumnya berbentuk:

KARAKTERISTIK (atribut 1, atribut 2, ...) (DAFTAR ENTITAS BERKARAKTER).

Kami juga akan memperluas bahasa diagram ER dengan memperkenalkan trapesium untuk gambar karakteristik (Gbr. 2.2).

Beras. 2.2. Elemen Bahasa Diagram Extended ER

menunjukkan entitas atau penamaan adalah hubungan banyak-ke-satu atau satu-ke-satu antara dua entitas dan berbeda dari karakteristik karena tidak bergantung pada entitas yang ditunjuk.

Perhatikan sebuah contoh yang berkaitan dengan pendaftaran karyawan di berbagai departemen dalam suatu organisasi.

Jika tidak ada aturan yang ketat (seorang karyawan dapat secara bersamaan terdaftar di beberapa departemen atau tidak terdaftar di departemen mana pun), Anda harus membuat deskripsi dengan Asosiasi Pendaftaran:

Departemen (Nomor Departemen, Nama Departemen, ...) Karyawan (Nomor Personil, Nama Belakang, ...) Pendaftaran [Departemen M, Karyawan N] (Nomor Departemen, Nomor Personil, Tanggal Pendaftaran).

Namun, dengan syarat setiap karyawan harus terdaftar di salah satu departemen, Anda dapat membuat deskripsi dengan sebutan Karyawan:

Departemen (Nomor Departemen, Nama Departemen, ...) Karyawan (Nomor Personalia, Nama Belakang, ... , Nomor Departemen, Tanggal Pendaftaran) [Departemen]

Dalam contoh ini, karyawan memiliki keberadaan independen (jika departemen dihapus, tidak berarti bahwa karyawan departemen itu juga harus dihapus). Oleh karena itu, mereka tidak dapat menjadi karakteristik departemen dan disebut sebutan.

Penunjukan digunakan untuk menyimpan nilai berulang dari atribut teks besar: "pengkode" disiplin ilmu yang dipelajari oleh siswa, nama organisasi dan departemennya, daftar barang, dll.

Deskripsi sebutan secara lahiriah berbeda dari deskripsi karakteristik hanya dalam entitas yang ditunjuk tidak diapit dalam tanda kurung kurawal, tetapi dalam tanda kurung siku:

DESIGNATION (atribut 1, atribut 2, ...)[DAFTAR ENTITAS YANG DITUNJUK].

Sebagai aturan umum, notasi tidak diperlakukan sebagai entitas yang lengkap, meskipun ini tidak akan menyebabkan kesalahan apa pun.

Sebutan dan karakteristik bukanlah entitas yang sepenuhnya independen, karena mengandaikan kehadiran beberapa entitas lain yang akan "ditunjuk" atau "ditandai". Namun, mereka masih merupakan kasus khusus dari suatu entitas dan dapat, tentu saja, memiliki properti, dapat berpartisipasi dalam asosiasi, penunjukan, dan memiliki karakteristik (tingkat yang lebih rendah) mereka sendiri. Kami juga menekankan bahwa semua contoh karakteristik harus selalu dikaitkan dengan beberapa contoh entitas yang dicirikan. Namun, diperbolehkan bahwa beberapa contoh entitas yang dicirikan tidak memiliki tautan. Benar, jika menyangkut pernikahan, maka esensi "Suami" harus diganti dengan esensi "Pria" (tidak ada suami tanpa istri).

Sekarang mari kita definisikan kembali entitas inti sebagai entitas yang bukan asosiasi, bukan penunjukan, atau karakteristik. Entitas tersebut memiliki keberadaan independen, meskipun mereka dapat merujuk ke entitas lain, seperti, misalnya, karyawan merujuk ke departemen.

Sebagai kesimpulan, mari pertimbangkan contoh membangun model infologis dari database "Makanan", di mana informasi tentang hidangan (Gbr. 2.3), konsumsi hariannya, produk dari mana hidangan ini disiapkan, dan pemasok produk ini harus disimpan. Informasi tersebut akan digunakan oleh koki dan manajer katering kecil, serta pengunjungnya.

Beras. 2.3. Contoh Resep

Dengan bantuan pengguna ini, objek dan karakteristik berikut dari pangkalan yang dirancang diidentifikasi:

  1. Hidangan yang memerlukan data yang disertakan dalam resep kulinernya untuk mendeskripsikannya: nomor hidangan (misalnya, dari buku resep), nama hidangan, jenis hidangan (pembuka, sup, hidangan utama, dll.), resep (teknologi persiapan hidangan), hasil (berat porsi), nama, kandungan kalori, dan berat setiap produk yang termasuk dalam hidangan.
  2. Untuk setiap pemasok produk: nama, alamat, nama produk yang dipasok, tanggal pengiriman dan harga pada saat pengiriman.
  3. Asupan makanan sehari-hari (konsumsi): hidangan, jumlah porsi, tanggal.

Analisis objek memungkinkan Anda untuk menyorot:

  • bar Piring, Produk dan Kota;
  • Komposisi Asosiasi (mengasosiasikan Hidangan dengan Produk) dan

Pengiriman (menghubungkan Pemasok dengan Produk);

  • penunjukan Pemasok;
  • Karakteristik Resep dan Konsumsi.

Diagram ER model ditunjukkan pada gambar. 2.4. dan model dalam bahasa JIM memiliki bentuk sebagai berikut:

Piring (BL, Piring, Jenis) Produk (PR, Produk, Kalori) Pemasok (PIC, Kota, Pemasok) [Kota] Komposisi [Piring M, Produk N] (BL, PR, Berat (g)) Persediaan [Pemasok M, Produk N] (POS, PR, Date_P, Harga, Berat (kg)) Kota (Kota, Negara) Resep (BL, Resep) (Hidangan) Konsumsi (BL, Date_R, Porsi) (Hidangan)

Dalam model ini, Hidangan, Produk, dan Pemasok adalah nama, dan BL, PR, dan POS adalah kode digital hidangan, produk, dan organisasi yang memasok produk ini.

Beras. 2.4. Model infologis dari database "Makanan"

[ Kembali ] [ Isi ] [ Selanjutnya ]

Basis Data: Klasifikasi Entitas

halaman di bagian ini

Pendekatan dokumenter, berdasarkan pertimbangan klasik dari area subjek, melibatkan pembuatan tipe entitas berdasarkan atribut dari setiap dokumen, membentuk kumpulan umum dari tipe entitas (entitas atribut) yang serikat mereka mewakili hubungan dalam normal pertama. bentuk (Gbr. 4.2).


Dalam contoh ini, analisis awal dokumen mengungkapkan satu set atribut yang harus disajikan saat membangun model database. Mari kita perlu membangun model database untuk pembentukan dokumen D1 "Order". Dokumen berisi 10 atribut, yang masing-masing diwakili oleh tipe entitas terpisah yang berisi atribut tipe sederhana yang sesuai. Namun, representasi ini tidak dapat dianggap sepenuhnya benar, karena ada satu atribut dalam dokumen yang tidak pantas untuk dipertimbangkan, mengingat hal itu hanya masuk akal di dalam dokumen dan mencirikan beberapa contoh hubungan dalam representasinya dalam dokumen. Atribut ini adalah "Nomor barang". Bahkan representasinya dalam dokumen, ini menunjukkan analisis dokumen, diimplementasikan dalam proses mencerminkan barang yang dipesan, dan penomoran dibentuk dalam kaitannya dengan dokumen sebagai objek area subjek, dan bukan area. untuk menyimpan informasi tentang barang yang dipesan. Jadi, karena contoh tidak memiliki tugas untuk menyimpan informasi tentang objek "Dokumen" dan presentasinya kepada pengguna, atribut "Nomor item" tidak ada artinya dari sudut pandang hubungan dengan pesanan dan produk. Namun, sekarang kami tidak akan menghapusnya dari daftar atribut dan tipe entitas yang dipertimbangkan, mengingatnya sebagai atribut yang mencirikan urutan barang dalam pesanan.

Saat memilih tipe entitas dari atribut dokumen, pengembang menambahkan satu karakteristik lagi ke yang sudah ada di dokumen, dan deskripsi tipe entitas akan menjadi sedikit lebih lengkap (Tabel 4.5), dengan mempertimbangkan representasi selanjutnya dalam model.

Tabel 4.5

Deskripsi tipe entitas

tipe entitas

Catatan

Jumlah order

Jumlah order

tanggal pemesanan

tanggal pemesanan

Nomor barang

Nomor barang

Nama

harga produk

harga produk

Harga

Harga

Dihitung:

Harga

Harga

Dihitung: 511M(<7>) dalam permintaan<1>

Simbolis

harga

Nilai urutan simbolis

Dibentuk dengan menerjemahkan nilai numerik ke dalam ekspresi simbolis

Kuantitas

Kuantitas



Deskripsi ini mewakili karakteristik yang penting untuk model database:

  • tipe data - deskripsi dalam hal model database dari jenis informasi yang disimpan, mendefinisikan pada tingkat implementasi fisik dari prinsip-prinsip representasi dan pemrosesan dalam database;
  • dimensi - karakteristik yang digunakan untuk beberapa tipe data untuk menentukan jumlah karakter (byte) yang akan digunakan saat menyimpan nilai yang sesuai.

Dalam tabel deskripsi tipe entitas yang disajikan, kolom "Dimensi" untuk beberapa tipe data berisi nilai numerik yang diapit tanda kurung kurawal. Hal ini dilakukan dengan alasan bahwa integer, data logis, serta tanggal dan waktu dalam database diwakili oleh mekanisme representasi standar, dan ukuran dalam byte selalu diketahui untuk menyimpan data jenis ini.

Tipe data numerik dan tipe data logis yang disamakan dengannya selalu memiliki dimensi tetap:

  • Boolean, Logical, Tinylnt, Bit - Logical (Boolean, Logical) data timah yang mengandung nilai "True" (benar) dan "False" (salah), identik dengan bilangan bulat kecil timah (Tinylnt) atau bit (Bit) dengan dimensi minimum 1 byte (1 bit jika identik dengan jenis Bit) dan nilai "O" atau "1";
  • Bit adalah tipe data integer yang mewakili nilai "0" atau "1", dengan dimensi 1 bit;
  • Tinylnt adalah tipe data integer dengan dimensi 1 byte;
  • SmallInt adalah tipe data integer dengan dimensi 2 byte;
  • Integer - tipe data integer dengan dimensi 4 byte;
  • BigInt, Long - tipe integer berdimensi besar (8 byte);
  • Tanggal - tipe data tanggal, direpresentasikan dalam versi karakter, dengan dimensi 8 karakter (byte);
  • Tipe data waktu – waktu, direpresentasikan dalam bentuk karakter, dengan dimensi 8 karakter (byte).

Untuk tipe data dengan dimensi tetap, kolom "Dimensi" biasanya tidak diisi, menyiratkan bahwa indikasi tipe data itu sendiri sudah mendefinisikannya dan tidak diperlukan indikasi tambahan. Untuk semua tipe data lainnya, penting untuk menentukan dimensi maksimum, dengan mempertimbangkan kekhasan nilai yang mungkin ada dalam dokumen. Untuk tipe data numerik, Anda menentukan jumlah byte yang harus ditempati oleh angka dan jumlah digit setelah titik desimal, yang menentukan ketepatan bilangan real. Tipe data karakter menentukan jumlah karakter yang harus disimpan untuk atribut yang sesuai. Tipe karakter dapat direpresentasikan dalam tiga cara berbeda:

Teks, CLOB - tipe data teks yang mewakili informasi teks besar yang disimpan dengan cara khusus, dan dalam tabel database ditunjukkan oleh serangkaian karakter pertama, yang jumlahnya merupakan dimensi atribut tipe ini;

  • - Karakter - tipe data string yang menyimpan dengan tepat jumlah karakter yang ditentukan sebagai dimensi, mengisi karakter yang hilang di akhir string dengan spasi;
  • - Varchar - tipe data string dengan panjang variabel, yang dimensinya menentukan jumlah karakter maksimum yang dapat dimiliki string yang disimpan.

Tipe Karakter dan Varchar pada dasarnya sangat mirip, karena mereka mendefinisikan tipe data string, tetapi rincian representasi data menentukan kondisi di mana satu atau tipe lain digunakan. Jadi, untuk menyimpan data yang ukurannya tetap (misalnya NPWP), BNK (kode pengenal bank) suatu bank, nomor urut, barang produk, dll), biasanya digunakan tipe Character, karena data tidak dapat, mungkin ada opsi ketika jumlah karakter mungkin berbeda dari yang ditentukan dalam dimensi atribut. Jenis Varchar digunakan dalam semua kasus lain di mana tidak perlu menyimpan jumlah karakter yang tepat.

Salah satu poin kunci dalam pembuatan SI untuk mengotomatisasi proses informasi suatu organisasi adalah studi komprehensif objek otomatisasi, propertinya, hubungan antara objek-objek ini, dan penyajian informasi yang diterima dalam bentuk data informasi. model.

Model data informasi dimaksudkan untuk mewakili semantik mata pelajaran dalam hal sarana deskripsi subjektif - entitas, atribut, pengenal entitas, supertipe , subtipe , dll.

Model informasi domain Basis data berisi konstruksi dasar berikut:

  • Diagram Hubungan Entitas;
  • definisi entitas;
  • unik pengenal entitas ;
  • definisi atribut entitas ;
  • hubungan antar entitas;
  • supertipe dan subtipe.

Perhatian! Elemen model data informasi bidang studi adalah data masukan untuk pemecahan masalah desain basis data- kreasi model data logis.

Entitas, atribut dan pengidentifikasi (kunci) dari suatu entitas, domain atribut

Subjek model informasi adalah abstraksi objek atau fenomena dunia nyata dalam area subjek, sebagai akibatnya entitas area subjek terungkap. Sebagai aturan, mereka dilambangkan dengan kata benda bahasa alami.

Entitas dideskripsikan menggunakan data yang disebut properti atau atribut entitas. Sebagai aturan, atribut adalah definisi dalam pernyataan entitas dan dilambangkan dengan kata benda bahasa alami. Entitas berkomunikasi satu sama lain melalui atribut mereka. Setiap kelompok atribut yang menggambarkan satu manifestasi nyata dari suatu entitas adalah turunan dari entitas tersebut. Dengan kata lain, contoh entitas adalah implementasi dari entitas yang berbeda satu sama lain dan memungkinkan identifikasi yang jelas.

Perhatian! Ketika suatu entitas direpresentasikan, hanya atributnya yang disimpan dalam database.

Salah satu cara utama komputer untuk mengenali entitas dalam database adalah dengan menetapkan pengenal entitas (Entity identifier). Sering pengenal entitas disebut kunci. tugas seleksi pengenal entitas secara semantik subjektif. Karena suatu entitas ditentukan oleh sekumpulan atributnya, disarankan bagi setiap entitas untuk memilih subset atribut yang secara unik mengidentifikasi entitas ini.

Beberapa entitas memiliki pengenal alami. Misalnya, pengenal alami faktur adalah nomornya. ID Entitas dapat komposit - terdiri dari beberapa atribut dan atom - terdiri dari satu atribut entitas.

Entitas diidentifikasi oleh analis. Namun, lebih sering daripada tidak, keputusan mereka belum final! Tugas perancang basis data adalah menyediakan contoh entitas dalam database, setiap instance baru memiliki pengidentifikasi unik. pengenal unik entitas- Ini atribut entitas A yang membedakan satu entitas dengan entitas lainnya. Jika suatu entitas memiliki beberapa pengidentifikasi unik, yang disebut kemungkinan kunci, maka desainer harus memilih kunci utama entitas.

Bedakan antara atribut bernilai tunggal dan multinilai. Atribut tidak ambigu jika mereka hanya memiliki satu nilai dalam instance tertentu dari suatu entitas. Jika tidak, mereka dianggap multinilai.

Poin penting dalam studi model informasi oleh perancang adalah pemilihan multi-nilai atribut entitas. Ini karena model database relasional tidak mendukung atribut multinilai, dan atribut tersebut harus diselesaikan pada tahap desain selanjutnya.

Setiap orang atribut entitas memiliki domain. Domain adalah ekspresi yang mendefinisikan nilai yang diizinkan untuk atribut tertentu. Dengan kata lain, domain adalah ruang lingkup atribut. Perancang basis data harus memastikan bahwa untuk setiap atribut entitas domain telah ditentukan.

Pada tingkat pemodelan informasi data, menetapkan domain ke atribut bersifat umum. Misalnya, atributnya adalah teks, numerik, biner, tanggal, atau "tidak ditentukan". Dalam kasus terakhir, analis harus memberikan deskripsi domain. Pada tahap selanjutnya, jenis domain ditentukan, makna konsep domain dalam model logis dan fisik database lebih sempit daripada yang dapat dipahami oleh analis. Hal ini disebabkan oleh fakta bahwa dalam kerangka model database fisik, domain diimplementasikan melalui mekanisme pembatasan domain, DBMS tidak memahami domain yang tidak ditentukan.

Hubungan, koneksi

Entitas tidak ada secara terpisah satu sama lain. Ada hubungan nyata di antara mereka ( Hubungan ), dan mereka harus tercermin dalam model informasi domain. Saat menyoroti hubungan, penekanannya adalah pada memperbaiki hubungan dan karakteristiknya. Relasi (relationship) adalah hubungan (relasi) antara dua entitas atau lebih. Setiap koneksi diwujudkan melalui nilai-nilai atribut entitas. Biasanya koneksi ditunjukkan oleh kata kerja. Setiap tautan juga harus memiliki keunikannya sendiri pengenal koneksi.

Perhatian! Dalam database relasional, hubungan diimplementasikan hanya melalui batasan integritas kunci asing. Oleh karena itu, perancang database harus memastikan bahwa hubungan antara entitas melalui atribut yang ditentukan secara tepat yang akan menentukan kunci unik dari hubungan tersebut. Pilihan kunci entitas adalah salah satu keputusan desain terpenting yang harus dibuat seorang desainer saat berpindah dari model informasi domain ke model basis data logis.

Relasi dicirikan oleh derajat koneksi dan kelas kepemilikan entitas terhadap koneksi tersebut. Derajat (kekuatan) koneksi adalah rasio jumlah entitas yang terlibat dalam pembentukan koneksi. Misalnya, satu-ke-satu, satu-ke-banyak, banyak-ke-banyak. Hubungan yang tidak terdefinisi atau tidak terselesaikan diperbolehkan pada tingkat model informasi. Kelas keanggotaan entitas- ini adalah sifat partisipasi entitas dalam hubungan. Bedakan antara wajib dan opsional kelas keanggotaan entitas untuk koneksi. Kelas keanggotaan diperlukan ketika contoh entitas berpartisipasi dalam pembentukan komunikasi tanpa gagal. Jika tidak, entitas milik kelas keanggotaan opsional. Untuk kelas keanggotaan entitas opsional, derajat hubungan bisa menjadi nol, mis. contoh entitas dapat dikaitkan dengan 0, 1, atau beberapa instance dari entitas lain. Untuk kelas keanggotaan wajib, tingkat koneksi tidak boleh nol.

Hubungan, entitas yang mengikat dengan dirinya sendiri disebut refleksif. Contoh khas dari hubungan refleksif adalah definisi struktur subordinasi dalam kaitannya dengan "Karyawan". Hubungan refleksif sering mencerminkan hubungan hierarkis di dalam struktur data. Mereka menimbulkan sejumlah masalah desain, yang akan dibahas nanti.

Dari sudut pandang hubungan dibedakan entitas yang lemah. Entitas yang lemah adalah entitas yang tidak dapat hadir dalam database sampai ada instance dari entitas lain yang terkait dengannya. Contoh entitas seperti itu adalah pesanan, yang tidak dapat ada tanpa pelanggan. Entitas yang lemah memiliki kelas keanggotaan wajib, dan tingkat koneksi entitas tersebut tidak boleh nol. Hubungan pesanan-pelanggan adalah wajib.

Mengidentifikasi entitas yang lemah dan hubungan wajib yang terkait diperlukan untuk memastikan integritas dan konsistensi data. Jadi, misalnya, tidak mungkin untuk menetapkan pesanan ke pelanggan yang tidak dikenal.

Subtipe dan supertipe

Terkadang entitas yang dibedakan membawa inklusi atau hubungan sebagian-keseluruhan. Dalam hal ini, ada beberapa atribut yang nilainya dihasilkan atur partisi contoh entitas menjadi subset yang tidak tumpang tindih - kategori entitas. Kategori entitas disebut subtipe dan dibedakan menjadi entitas bawahan dalam hubungan, yang merupakan kategori entitas asli.

Terkadang atribut yang umum untuk kategori yang dihasilkan diekstraksi dari entitas asli, dan dengan cara ini entitas diekstraksi yang menjadi supertipe. Nama entitas asli biasanya tertinggal di belakang entitas supertipe yang dipilih, meskipun makna semantiknya berubah.

Supertipe dengan subtipenya adalah contoh dari apa yang disebut entitas majemuk. Entitas komposit adalah konstruksi logis dari model untuk mewakili satu set entitas dan hubungan di antara mereka secara keseluruhan.

Contoh. Entitas Kendaraan dapat dipecah menjadi sub-jenis berikut: kendaraan penggerak dua roda, kendaraan penggerak empat roda, kendaraan penggerak sakelar.

Penting bagi perancang basis data untuk mengetahui bahwa semua contoh entitas Supertipe hanya mengacu pada salah satu subtipenya. Kehadiran subtipe dalam model dan

Istilah "relasional" berarti "berdasarkan hubungan". Sebuah database relasional terdiri dari entitas (tabel) yang memiliki beberapa hubungan satu sama lain. Nama ini berasal dari kata dalam bahasa Inggris relation.
Desain database terdiri dari dua fase utama: pemodelan logis dan fisik.
Selama pemodelan logis, Anda mengumpulkan persyaratan dan mengembangkan model database yang independen dari DBMS tertentu (sistem manajemen database relasional). Ini seperti membuat cetak biru untuk rumah Anda. Anda dapat memikirkan dan menggambar semuanya: di mana dapur, kamar tidur, ruang tamu akan berada. Tapi ini semua di atas kertas dan dalam tata letak.
Selama pemodelan fisik, Anda membuat model yang dioptimalkan untuk aplikasi dan DBMS tertentu. Model inilah yang diterapkan dalam praktik. Jika kita kembali ke rumah dari paragraf sebelumnya, pada tahap ini Anda harus membangun rumah di suatu tempat - membawa kayu gelondongan, batu bata ...

Proses desain database terdiri dari langkah-langkah berikut:

  • pengumpulan informasi;
  • definisi entitas;
  • mendefinisikan atribut untuk setiap entitas;
  • mendefinisikan hubungan antar entitas;
  • normalisasi;
  • transformasi ke model fisik;
  • pembuatan basis data.

5 tahap pertama membentuk fase desain logis dan dua sisanya membentuk fase pemodelan fisik.

Fase logika

Fase logis terdiri dari beberapa tahap. Mereka semua dibahas di bawah ini.

Persyaratan Pengumpulan

Pada tahap ini, Anda perlu menentukan dengan tepat bagaimana database akan digunakan dan informasi apa yang akan disimpan di dalamnya. Kumpulkan informasi sebanyak mungkin tentang apa yang harus dan tidak boleh dilakukan oleh sistem.

Definisi entitas

Pada tahap ini, Anda perlu menentukan entitas yang terdiri dari database.

Entitas adalah objek dalam database yang menyimpan data. Entitas dapat berupa sesuatu yang nyata (rumah, orang, objek, tempat) atau hal abstrak (transaksi perbankan, departemen perusahaan, rute bus). Dalam model fisik, entitas disebut tabel.

Entitas terdiri dari atribut (kolom dalam tabel) dan record (baris dalam tabel).

Biasanya, database terdiri dari beberapa entitas utama yang terkait dengan sejumlah besar entitas bawahan. Entitas inti disebut independen: mereka tidak bergantung pada entitas lain mana pun. Entitas bawahan disebut dependen: agar salah satunya ada, tabel utama yang terkait dengannya harus ada.
Dalam diagram, entitas biasanya direpresentasikan sebagai persegi panjang. Nama entitas ditunjukkan di dalam persegi panjang:

Setiap tabel memiliki karakteristik sebagai berikut:

  • tidak ada garis yang identik di dalamnya;
  • semua kolom (atribut) dalam tabel harus memiliki nama yang berbeda;
  • elemen dalam kolom yang sama memiliki tipe yang sama (string, angka, tanggal);
  • urutan baris dalam tabel bisa sewenang-wenang.

Pada tahap ini, Anda perlu mengidentifikasi semua kategori informasi (entitas) yang akan disimpan dalam database.

Definisi Atribut

Atribut mewakili properti yang menggambarkan entitas. Atribut sering berupa angka, tanggal, atau teks. Semua data yang disimpan dalam suatu atribut harus bertipe sama dan memiliki properti yang sama.
Dalam model fisik, atribut disebut kolom.
Setelah mendefinisikan entitas, perlu untuk mendefinisikan semua atribut entitas ini.
Dalam diagram, atribut biasanya terdaftar dalam persegi panjang entitas. Pada gambar Anda akan menemukan contoh database "Rumah", hanya sekarang beberapa atribut didefinisikan untuk entitas dari database ini.


Setiap atribut mendefinisikan tipe data, ukuran, nilai yang diizinkan, dan aturan lainnya. Ini termasuk aturan wajib, bisa berubah, dan keunikan.
Aturan wajib menentukan apakah suatu atribut adalah bagian yang diperlukan dari suatu entitas. Jika atribut adalah bagian opsional dari entitas, maka itu bisa NULL, jika tidak.
Anda juga harus menentukan apakah atributnya bisa berubah. Beberapa nilai atribut tidak dapat diubah setelah entri dibuat.
Dan akhirnya, Anda perlu menentukan apakah atributnya unik. Jika demikian, maka nilai atribut tidak dapat diulang.

Kunci

Kunci adalah satu set atribut yang secara unik mengidentifikasi entri. Kunci dibagi menjadi dua kelas: sederhana dan majemuk.
Sebuah kunci sederhana hanya terdiri dari satu atribut. Misalnya, dalam basis data "Paspor warga negara", nomor paspor akan menjadi kunci sederhana: lagi pula, tidak ada dua paspor dengan nomor yang sama.
Kunci komposit terdiri dari beberapa atribut. Dalam database yang sama "Paspor warga negara" dapat ada kunci komposit dengan atribut berikut:
nama keluarga, nama, patronimik, tanggal lahir. Ini hanyalah sebuah contoh, karena kunci komposit ini, secara teori, tidak memberikan jaminan keunikan catatan.
Ada juga beberapa jenis kunci, yang dijelaskan di bawah ini.

Kemungkinan Kunci

Kandidat kunci adalah setiap set atribut yang secara unik mengidentifikasi entri dalam tabel. Kunci kandidat bisa sederhana atau majemuk.
Setiap entitas harus memiliki setidaknya satu kemungkinan kunci, meskipun mungkin ada lebih dari satu kemungkinan kunci. Tak satu pun dari atribut kunci utama dapat memiliki nilai NULL.
Kunci kandidat juga disebut kunci pengganti.

Kunci Utama

Kunci utama adalah satu set atribut yang secara unik mengidentifikasi catatan dalam tabel (entitas). Salah satu kunci yang mungkin menjadi kunci utama. Dalam diagram, kunci utama sering ditampilkan di atas daftar atribut utama atau disorot dengan simbol khusus. Entitas pada gambar memiliki atribut kunci dan reguler.

Tombol Alternatif

Setiap kemungkinan kunci yang bukan kunci utama disebut kunci alternatif. Entitas dapat memiliki beberapa kunci alternatif.

Kunci asing

Kunci asing adalah kumpulan atribut yang merujuk ke kunci utama atau alternatif dari entitas lain. Jika kunci asing tidak terkait dengan entitas utama, maka kunci tersebut hanya dapat berisi nilai nol. Jika kuncinya juga komposit, maka semua atribut kunci asing harus tidak terdefinisi.
Dalam diagram, atribut yang digabungkan menjadi kunci asing dilambangkan dengan karakter khusus. Gambar tersebut menunjukkan dua entitas terkait (Rumah dan Pemiliknya) dan kunci asing yang dibentuk oleh mereka (bagaimanapun, satu orang dapat memiliki lebih dari satu rumah).

Kunci adalah konstruksi logis, bukan objek fisik. Database relasional memiliki mekanisme untuk menyimpan kunci.

Mendefinisikan Hubungan Antar Entitas

Database relasional memungkinkan Anda untuk menggabungkan informasi milik entitas yang berbeda.
Sebuah hubungan adalah situasi di mana satu entitas mengacu pada kunci utama dari entitas kedua. Seperti, misalnya, entitas House dan Master pada gambar sebelumnya.
Hubungan didefinisikan selama proses desain dasar. Untuk melakukan ini, Anda harus menganalisis entitas dan mengidentifikasi hubungan logis yang ada di antara mereka.
Jenis hubungan menentukan jumlah rekaman entitas yang terkait dengan rekaman entitas lain. Hubungan dibagi menjadi tiga jenis utama, yang dijelaskan di bawah ini.

Satu lawan satu

Setiap entri dari entitas pertama hanya sesuai dengan satu entri dari entitas kedua. Dan setiap record dari entitas kedua hanya berhubungan dengan satu record dari entitas pertama. Misalnya, ada dua entitas: Orang dan Akta Kelahiran. Dan satu orang hanya dapat memiliki satu akta kelahiran.

Satu-ke-banyak

Setiap record dari entitas pertama dapat berhubungan dengan beberapa record dari entitas kedua. Namun, setiap entri dari entitas kedua sesuai dengan hanya satu entri dari entitas pertama. Misalnya, ada dua entitas: Pesanan dan Item Pesanan. Dan bisa ada banyak item dalam satu urutan.

banyak ke banyak

Setiap record dari entitas pertama dapat berhubungan dengan beberapa record dari entitas kedua. Namun, setiap record dari entitas kedua dapat berhubungan dengan beberapa record dari entitas pertama. Misalnya, ada dua entitas: Penulis dan Buku. Satu penulis bisa menulis banyak buku. Tetapi sebuah buku dapat memiliki banyak penulis.
Menurut kriteria hubungan wajib dibagi menjadi wajib dan opsional.

  • Hubungan wajib berarti bahwa untuk setiap entri dari entitas pertama, harus ada entri terkait di entitas kedua.
  • Hubungan opsional berarti bahwa catatan dari entitas pertama mungkin tidak memiliki catatan di entitas kedua.

Normalisasi

Normalisasi adalah proses menghilangkan data yang berlebihan dari database. Setiap elemen data harus disimpan dalam database dalam satu dan hanya satu instance. Ada lima bentuk normalisasi yang umum. Sebagai aturan, database direduksi menjadi bentuk normal ketiga.
Selama proses normalisasi, tindakan tertentu dilakukan untuk menghapus data yang berlebihan. Normalisasi meningkatkan kinerja, mempercepat pengurutan dan pembuatan indeks, mengurangi jumlah indeks per entitas, dan mempercepat operasi penyisipan dan pembaruan.
Database yang dinormalisasi biasanya lebih fleksibel. Saat memodifikasi kueri atau data yang dipertahankan, database yang dinormalisasi biasanya memerlukan lebih sedikit perubahan, dan perubahan memiliki dampak yang lebih sedikit.

Bentuk normal pertama

Untuk mengonversi entitas ke bentuk normal pertama, Anda harus menghilangkan kelompok nilai duplikat dan memastikan bahwa setiap atribut hanya berisi satu nilai, daftar nilai tidak diperbolehkan.
Dengan kata lain, setiap atribut dalam suatu entitas hanya boleh disimpan dalam satu instance.
Misalnya, pada gambar, entitas DPR tidak dinormalisasi. Ini berisi beberapa atribut untuk menyimpan data tentang pemilik rumah (entitas House tidak sesuai dengan bentuk normal pertama).

Untuk membawa entitas House ke bentuk normal pertama, perlu untuk menghapus grup nilai yang berulang, yaitu, menghapus atribut Pemilik 1-3, menempatkannya di entitas yang terpisah. Hasil (Rumah Entitas dikurangi menjadi bentuk normal pertama):

Bentuk normal kedua

Sebuah tabel dalam bentuk normal kedua hanya berisi data yang berlaku untuk itu. Nilai atribut entitas non-kunci bergantung pada kunci utama. Lebih tepatnya, atribut bergantung pada kunci utama, pada seluruh kunci utama, dan hanya pada kunci utama.
Entitas harus dalam bentuk normal pertama agar sesuai dengan bentuk normal kedua.
Misalnya, entitas Rumah pada gambar memiliki atribut Harga per liter bensin, yang tidak ada hubungannya dengan rumah. Atribut ini dihapus (atau Anda dapat memindahkannya ke entitas lain). Dan juga kami memindahkan atribut Walikota ke entitas yang terpisah - atribut ini tergantung pada kota tempat rumah itu berada, dan bukan pada rumah tersebut.
Gambar tersebut menunjukkan Rumah Esensi dalam bentuk normal kedua (Rumah Esensi direduksi menjadi bentuk normal kedua).

bentuk normal ketiga

Bentuk normal ketiga mengecualikan atribut yang tidak bergantung pada seluruh kunci. Setiap entitas yang berada dalam bentuk normal ketiga juga berada dalam bentuk normal kedua. Ini adalah bentuk database yang paling umum.
Dalam bentuk normal ketiga, setiap atribut bergantung pada kunci, pada seluruh kunci, dan hanya pada kunci.
Misalnya, entitas Pemilik Rumah pada gambar memiliki atribut tanda Zodiak yang bergantung pada tanggal lahir pemilik rumah, bukan pada nama pemilik (yang merupakan kunci).
Untuk mentransmisikan entitas Pemilik rumah, Anda perlu membuat entitas Tanda Zodiak dan mentransfer atribut Tanda Zodiak ke sana (Entitas Pemilik rumah, dikurangi menjadi bentuk normal ketiga):

Pembatasan

Kendala adalah aturan yang ditegakkan oleh sistem manajemen basis data. Batasan menentukan kumpulan nilai yang dapat dimasukkan dalam kolom atau kolom.
Misalnya, Anda tidak ingin jumlah pesanan di toko Anda yang sangat keren kurang dari 500 rubel. Anda cukup menetapkan batas pada kolom Jumlah Pesanan.

Prosedur tersimpan

Prosedur tersimpan adalah prosedur yang telah dikompilasi sebelumnya yang disimpan dalam database. Prosedur tersimpan dapat digunakan untuk mendefinisikan aturan bisnis dan dapat digunakan untuk melakukan perhitungan yang lebih kompleks daripada batasan saja.
Prosedur tersimpan dapat berisi logika aliran program serta kueri basis data. Mereka dapat mengambil parameter dan mengembalikan hasil sebagai tabel atau nilai tunggal.
Prosedur tersimpan sama seperti prosedur atau fungsi biasa dalam program apa pun.

CATATAN
Prosedur tersimpan berada di database dan dijalankan di server database. Mereka umumnya lebih cepat daripada pernyataan SQL karena disimpan dalam bentuk terkompilasi.

Integritas data

Dengan mengatur data ke dalam tabel dan mendefinisikan hubungan di antara mereka, kita dapat mengasumsikan bahwa model telah dibuat yang mencerminkan lingkungan bisnis dengan benar. Sekarang kita perlu memastikan bahwa data yang dimasukkan ke dalam database memberikan gambaran yang benar tentang keadaan masalah tersebut. Dengan kata lain, Anda perlu menegakkan aturan bisnis dan menjaga integritas database.
Misalnya, perusahaan Anda bergerak dalam bidang pengiriman buku. Anda tidak mungkin menerima pesanan dari klien yang tidak dikenal, karena Anda bahkan tidak akan dapat mengirimkan pesanan. Karenanya aturan bisnis: pesanan hanya diterima dari pelanggan yang informasinya ada di database.
Kebenaran data dalam database relasional dijamin oleh seperangkat aturan. Aturan integritas data terbagi dalam empat kategori.

  • Integritas Entitas- setiap catatan entitas harus memiliki pengenal unik dan berisi data. Lagi pula, Anda perlu entah bagaimana membedakan antara semua catatan ini dalam database.
  • Integritas Atribut- setiap atribut hanya menerima nilai yang valid. Misalnya, jumlah pembelian pasti tidak boleh kurang dari nol.
  • Integritas referensial- seperangkat aturan yang memastikan konsistensi logis dari kunci utama dan asing saat memasukkan, memperbarui, dan menghapus catatan. Integritas referensial memastikan bahwa untuk setiap kunci asing ada kunci utama yang sesuai. Mari kita ambil contoh sebelumnya dengan entitas Pemilik Rumah dan Rumah. Katakanlah Anda Vasya Ivanov dan memiliki rumah. Anda mengubah nama belakang Anda menjadi Sidorov dan membuat perubahan yang sesuai dengan entitas pemilik House. Pasti Anda ingin rumah Anda terus menjadi milik Anda dengan nama baru Anda, dan bukan milik Vasya Ivanov tertentu, yang sudah tidak ada lagi.
  • Aturan Integritas Kustom- aturan integritas apa pun yang tidak termasuk dalam kategori mana pun yang terdaftar.

pemicu

Pemicu adalah analog dari prosedur tersimpan, yang dipanggil secara otomatis ketika data dalam tabel berubah.
Pemicu adalah mekanisme yang kuat untuk menjaga integritas database. Pemicu dipanggil sebelum atau sesudah perubahan data dalam tabel.
Dengan bantuan pemicu, Anda tidak hanya dapat membatalkan perubahan ini, tetapi juga mengubah data di tabel lain mana pun.
Misalnya, Anda membuat forum Internet dan Anda ingin memastikan bahwa daftar forum menunjukkan posting forum terbaru. Tentu saja, Anda dapat menerima pesan dari entitas Postingan Forum, tetapi ini akan meningkatkan kerumitan permintaan Anda dan waktu eksekusinya. Lebih mudah untuk menambahkan pemicu ke entitas Postingan Forum yang mencatat postingan terakhir yang ditambahkan ke entitas Forum, di atribut Posting Terakhir. Ini akan sangat menyederhanakan kueri.

Peraturan bisnis

Aturan bisnis menentukan batasan yang ditempatkan pada data sesuai dengan persyaratan bisnis (untuk siapa Anda membuat basis). Aturan bisnis dapat terdiri dari serangkaian langkah yang diperlukan untuk menyelesaikan tugas tertentu, atau mungkin hanya berupa pemeriksaan yang memverifikasi bahwa data yang dimasukkan sudah benar. Aturan bisnis dapat mencakup aturan integritas data. Tidak seperti aturan lain, tujuan utamanya adalah untuk memastikan bahwa transaksi bisnis dilakukan dengan benar.
Misalnya, di perusahaan Very Tough Guys, biasanya hanya mobil putih, biru, dan hitam yang dibeli untuk penggunaan resmi.
Aturan bisnis untuk atribut Warna Kendaraan dari entitas Kendaraan Perusahaan adalah bahwa kendaraan hanya boleh berwarna putih, biru, atau hitam.
Sebagian besar DBMS menyediakan sarana untuk:

  • untuk menentukan nilai default;
  • untuk memeriksa data sebelum memasukkannya ke dalam database;
  • untuk menjaga hubungan antar tabel;
  • untuk memastikan keunikan nilai;
  • untuk menyimpan prosedur tersimpan secara langsung dalam database.

Semua fitur ini dapat digunakan untuk mengimplementasikan aturan bisnis dalam database.

Model fisik

Langkah selanjutnya, setelah membuat model logis, adalah membangun model fisik. Model fisik adalah implementasi praktis dari database. Model fisik mendefinisikan semua objek yang harus Anda implementasikan.
Saat berpindah dari model logis ke entitas fisik, mereka dikonversi ke tabel, dan atribut ke kolom.
Hubungan antar entitas dapat diubah menjadi tabel atau dibiarkan sebagai kunci asing.
Kunci utama diubah menjadi batasan kunci utama. Kemungkinan kunci berada dalam batasan keunikan.

Denormalisasi

Denormalisasi- ini adalah perubahan yang disengaja dalam struktur pangkalan yang melanggar aturan bentuk normal. Hal ini biasanya dilakukan untuk meningkatkan kinerja database.
Secara teoritis, seseorang harus selalu berusaha untuk basis yang sepenuhnya dinormalisasi, tetapi dalam praktiknya, basis yang dinormalisasi sepenuhnya hampir selalu berarti penurunan kinerja. Menormalkan database secara berlebihan dapat mengakibatkan beberapa tabel diakses setiap kali data diambil. Biasanya, empat tabel atau kurang harus berpartisipasi dalam kueri.
Teknik denormalisasi standar adalah: menggabungkan beberapa tabel menjadi satu, menyimpan atribut yang sama dalam beberapa tabel, dan menyimpan ringkasan atau data terhitung dalam sebuah tabel.

Atribut.

bidang subjek.

Basis data. Definisi.

DBMS. Definisi.

Basis data. Definisi.

Bentuk normal ketiga. Definisi. Contoh.

Suatu variabel relasi R berada dalam bentuk normal ketiga jika dan hanya jika kondisi berikut ini benar:

R dalam bentuk normal kedua.

· tidak ada atribut non-kunci R dalam ketergantungan fungsional transitif (yaitu, ketergantungan tidak dinyatakan melalui atribut lain) dari kunci potensial R.

Atribut bukan kunci dari suatu relasi R adalah atribut yang bukan milik salah satu kunci kandidat dari R.

Basis Data- ini adalah satu atau lebih file data yang dirancang untuk menyimpan, mengubah, dan memproses sejumlah besar informasi yang saling berhubungan, disistematisasikan sedemikian rupa sehingga bahan-bahan ini dapat ditemukan dan diproses menggunakan komputer elektronik (komputer)

Sistem manajemen basis data (DBMS) adalah perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, dan memelihara database, dan yang menangani panggilan database dari aplikasi pengguna akhir.

Basis Data- sistem informasi otomatis untuk penyimpanan terpusat dan penggunaan data secara kolektif. Bank data mencakup satu atau lebih database, direktori database, DBMS, serta perpustakaan kueri dan program aplikasi.

bidang subjek adalah bagian dari dunia nyata yang akan dipelajari untuk membuat database untuk mengotomatisasi proses manajemen.

Atribut adalah unit terkecil dari struktur data. Setiap elemen diberi nama unik saat database dibuat. Ini disebut dengan nama ini selama pemrosesan.

Esensi- objek konkret atau abstrak apa pun di area subjek yang sedang dipertimbangkan. Entitas adalah tipe dasar informasi yang disimpan dalam database (dalam database relasional, setiap entitas diberi tabel).

Sebutkan fungsi DBMS

Fungsi utama DBMS:

1) Penentuan struktur database yang dibuat, inisialisasi dan pemuatan awal.

2) Memberi pengguna kemampuan untuk memanipulasi data (memilih data yang diperlukan, melakukan perhitungan, mengembangkan antarmuka input / output, visualisasi).

3) Memastikan independensi logis dan fisik data.

4) Perlindungan integritas logis basis data - keandalan data dapat dilanggar ketika dimasukkan ke dalam basis data atau ketika tindakan ilegal dari prosedur pemrosesan data yang menerima dan memasukkan data yang salah ke dalam basis data. Untuk meningkatkan keandalan data dalam sistem, apa yang disebut batasan integritas dideklarasikan.



5) Perlindungan integritas fisik - alat pemulihan basis data (transaksi).

6) Manajemen izin pengguna untuk mengakses database.

7) Sinkronisasi kerja beberapa pengguna.

8) Manajemen sumber daya lingkungan penyimpanan - DBMS mengalokasikan sumber daya memori untuk data baru, mendistribusikan kembali memori yang dibebaskan, mengatur antrian permintaan ke memori eksternal, dan seterusnya.

9) Dukungan untuk aktivitas personel sistem