Entitas adalah objek nyata atau abstrak yang mempunyai arti penting bagi area subjek. Entitas harus mempunyai nama yang dinyatakan dengan kata benda tunggal

Cara informal untuk mengidentifikasi entitas adalah dengan mencari abstraksi yang menggambarkan objek, proses, peran, dan konsep lainnya. Cara formal untuk mengidentifikasi entitas adalah dengan menganalisis deskripsi teks dari area subjek, menyorot kata benda dan memilihnya sebagai abstraksi.

Sebuah instance entitas adalah perwakilan spesifik dari suatu entitas tertentu. Misalnya, contoh entitas Karyawan dapat berupa karyawan Ivanov.

Setiap entitas harus memiliki properti berikut:

memiliki nama yang unik;

memiliki satu atau lebih atribut yang dimiliki entitas atau diwariskan melalui suatu relasi;

memiliki satu atau lebih atribut yang secara unik mengidentifikasi setiap instance dari suatu entitas.

Atribut adalah karakteristik suatu entitas yang signifikan untuk bidang studi yang dipertimbangkan dan dimaksudkan untuk mengidentifikasi, mengklasifikasikan, mengukur atau menyatakan keadaan entitas.

Jenis atribut berikut ada:

sederhana - terdiri dari satu elemen data;

komposit - terdiri dari beberapa elemen data;

tidak ambigu - berisi satu nilai untuk satu entitas;

multi-nilai - berisi beberapa nilai untuk satu entitas;

opsional - dapat memiliki nilai kosong (tidak ditentukan);

turunan - nilai yang diturunkan dari nilai atribut lain.

Pengidentifikasi unik adalah sekumpulan atribut yang nilainya unik untuk setiap instance suatu entitas. Menghapus atribut apa pun dari pengidentifikasi melanggar keunikannya. Pengidentifikasi unik ditampilkan seperti yang digarisbawahi dalam diagram.

Setiap entitas dapat memiliki sejumlah koneksi dengan entitas lainnya.

Hubungan antar entitas

Relasi adalah asosiasi bernama antara entitas yang signifikan untuk bidang subjek yang sedang dipertimbangkan.

Derajat koneksi adalah jumlah entitas yang terlibat dalam koneksi tersebut.

Kekuatan komunikasi - jumlah instance entitas yang berpartisipasi dalam komunikasi.

Tergantung pada nilai dayanya, komunikasi dapat berupa salah satu dari tiga jenis:

satu-ke-satu (dilambangkan 1:1).

satu-ke-banyak (dilambangkan 1:N).

banyak-ke-banyak (dilambangkan M:N).

Satu lawan satu. Berarti dalam hubungan seperti itu, entitas dengan satu peran selalu berkorespondensi dengan tidak lebih dari satu entitas dengan peran lain. Karena derajat keterhubungan setiap entitas adalah 1, maka entitas-entitas tersebut dihubungkan oleh satu garis.

Satu-ke-banyak. Suatu entitas dengan satu peran dapat dikaitkan dengan sejumlah entitas dengan peran lain.

Banyak ke banyak. Dalam hal ini, masing-masing entitas terkait dapat diwakili oleh sejumlah contoh.

Istilah “relasional” berarti “berdasarkan hubungan.” Basis data relasional terdiri dari entitas (tabel) yang memiliki hubungan satu sama lain. Nama itu berasal kata Bahasa Inggris hubungan
Desain basis data terdiri dari dua fase utama: pemodelan logis dan fisik.
Selama pemodelan logis, Anda mengumpulkan persyaratan dan mengembangkan model basis data yang tidak bergantung pada DBMS (sistem manajemen basis data relasional) tertentu. Ini seperti membuat cetak biru untuk rumah Anda. Anda dapat memikirkan dan menggambar semuanya: di mana dapur, kamar tidur, ruang tamu berada. Tapi ini semua hanya di atas kertas dan di mock-up.
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;
• konversi ke model fisik;
• pembuatan basis data.

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

Fase logis

Fase logis terdiri dari beberapa tahap. Semuanya 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.

Mendefinisikan Entitas

Pada tahap ini, Anda perlu mendefinisikan entitas yang akan membentuk database.

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

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

Biasanya database terdiri dari beberapa entitas utama yang berhubungan dengan jumlah besar entitas bawahan. Entitas dasar disebut independen: mereka tidak bergantung pada entitas lain. Entitas bawahan disebut entitas dependen: agar salah satu dari mereka ada, tabel utama yang terkait 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) pada tabel harus memiliki nama yang berbeda;
• elemen dalam kolom yang sama memiliki tipe yang sama (string, angka, tanggal);
• Urutan baris dalam tabel bisa berubah-ubah.

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

Mendefinisikan Atribut

Atribut mewakili properti yang mendeskripsikan suatu entitas. Atribut sering kali 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 Anda mendefinisikan entitas, Anda perlu mendefinisikan semua atribut entitas tersebut.
Dalam diagram, atribut biasanya dicantumkan di dalam persegi panjang entitas. Pada gambar Anda akan menemukan contoh database “Rumah”, hanya sekarang beberapa atribut ditentukan untuk entitas dari database ini.


Untuk setiap atribut, tipe data, ukurannya, nilai yang dapat diterima, dan aturan lainnya ditentukan. Ini termasuk aturan penyelesaian wajib, kemampuan berubah dan keunikan.
Aturan wajib menentukan apakah suatu atribut merupakan bagian wajib dari suatu entitas. Jika suatu atribut adalah bagian opsional dari suatu entitas, maka atribut tersebut dapat mengambil nilai NULL, jika tidak maka tidak.
Anda juga harus menentukan apakah atribut tersebut bisa berubah. Beberapa nilai atribut tidak dapat diubah setelah rekaman dibuat.
Terakhir, Anda perlu menentukan apakah atribut tersebut unik. Jika demikian, maka nilai atribut tidak dapat diulang.

Kunci

Kunci adalah sekumpulan atribut yang secara unik mengidentifikasi suatu record. Kunci dibagi menjadi dua kelas: sederhana dan majemuk.
Kunci sederhana hanya terdiri dari satu atribut. Misalnya, dalam database “Paspor Warga Negara suatu Negara”, nomor paspor akan menjadi kunci sederhana: lagipula, tidak ada dua paspor dengan nomor yang sama.
Kunci komposit terdiri dari beberapa atribut. Dalam database yang sama "Paspor warga negara" mungkin terdapat kunci komposit dengan atribut berikut:
nama belakang, nama depan, patronimik, tanggal lahir. Ini hanyalah sebuah contoh, karena kunci komposit ini, secara teoritis, tidak memberikan jaminan keunikan rekaman.
Ada juga beberapa jenis kunci, yang dijelaskan di bawah ini.

Petunjuk yang mungkin

Kunci kandidat adalah kumpulan atribut apa pun yang secara unik mengidentifikasi catatan dalam tabel. Kunci yang mungkin bisa sederhana atau majemuk.
Setiap entitas harus memiliki setidaknya satu kunci yang mungkin, meskipun mungkin ada lebih dari satu kunci yang mungkin. Tak satu pun dari atribut kunci utama dapat memiliki nilai nol.
Kunci kandidat juga disebut kunci pengganti.

Kunci utama

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

Kunci alternatif

Kunci apa pun yang mungkin bukan kunci utama disebut kunci alternatif. Suatu entitas dapat memiliki beberapa kunci alternatif.

Kunci asing

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

Kunci adalah konstruksi logis, bukan objek fisik. Basis data relasional memiliki mekanisme untuk memastikan bahwa kunci disimpan.

Mendefinisikan hubungan antar entitas

Basis data relasional memungkinkan Anda menggabungkan informasi milik entitas yang berbeda.
Relasi adalah situasi di mana satu entitas mereferensikan kunci utama entitas kedua. Seperti misalnya entitas House dan Master pada gambar sebelumnya.
Hubungan ditentukan selama proses desain database. Untuk melakukan ini, Anda harus menganalisis entitas dan mengidentifikasi hubungan logis yang ada di antara mereka.
Tipe relasi 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 record dari entitas pertama hanya berhubungan dengan satu record 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 boleh memiliki satu akta kelahiran.

Satu-ke-banyak

Setiap record dari entitas pertama dapat berhubungan dengan beberapa record dari entitas kedua. Namun, setiap rekaman entitas kedua hanya berhubungan dengan satu rekaman dari entitas pertama. Misalnya, ada dua entitas: Pesanan dan Item Pesanan. Dan satu pesanan bisa memuat banyak produk.

Banyak ke banyak

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

• Relasi wajib artinya setiap record pada entitas pertama harus terdapat record-record yang berelasi pada entitas kedua.
• Relasi opsional berarti rekaman dari entitas pertama mungkin tidak memiliki rekaman di entitas kedua.

Normalisasi

Normalisasi adalah proses menghilangkan data berlebihan dari database. Setiap elemen data harus disimpan dalam database dalam satu dan hanya satu salinan. Ada lima bentuk normalisasi yang umum. Biasanya, database direduksi menjadi bentuk normal ketiga.
Selama proses normalisasi, langkah-langkah tertentu diambil untuk menghapus data yang berlebihan. Normalisasi meningkatkan kinerja, mempercepat penyortiran dan pembuatan indeks, mengurangi jumlah indeks per entitas, dan mempercepat operasi penyisipan dan pembaruan.
Basis data yang dinormalisasi biasanya lebih fleksibel. Saat memodifikasi kueri atau data yang disimpan, database yang dinormalisasi biasanya memerlukan lebih sedikit perubahan, dan perubahan memiliki konsekuensi yang lebih sedikit.

Bentuk normal pertama

Untuk mengonversi suatu 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 pada dasarnya perlu disimpan hanya dalam satu contoh.
Misalnya, pada gambar, entitas Home tidak dinormalisasi. Ini berisi beberapa atribut untuk menyimpan data tentang pemilik rumah (entitas Rumah tidak sesuai dengan bentuk normal pertama).

Untuk membawa entitas Rumah ke bentuk normal pertama, kelompok nilai yang berulang perlu dihilangkan, yaitu menghapus atribut Pemilik 1-3, dan menempatkannya dalam entitas terpisah. Hasil (Essence House direduksi menjadi bentuk normal pertama):

Bentuk normal kedua

Tabel dalam bentuk normal kedua hanya berisi data yang berhubungan dengannya. Nilai atribut entitas bukan kunci bergantung pada kunci utama. Lebih tepatnya, atribut bergantung pada kunci utama, pada seluruh kunci utama, dan pada kunci utama saja.
Untuk menyesuaikan diri dengan bentuk normal kedua, entitas harus berada dalam bentuk normal pertama.
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). Kami juga mentransfer atribut Walikota ke entitas terpisah - atribut ini bergantung pada kota tempat rumah tersebut berada, dan bukan pada rumahnya.
Gambar tersebut menunjukkan hakikat Rumah dalam bentuk normal kedua (Esensi Rumah direduksi menjadi bentuk normal kedua).

Bentuk normal ketiga

Bentuk normal ketiga tidak termasuk atribut yang tidak bergantung pada keseluruhan kunci. Entitas apa pun 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 sebuah kunci, pada seluruh kunci, dan hanya bergantung pada kunci tersebut.
Misalnya, entitas Pemilik Rumah dalam gambar memiliki atribut Tanda Zodiak, yang bergantung pada tanggal lahir pemilik rumah, dan bukan pada namanya (yang merupakan kuncinya).
Untuk menghadirkan entitas Pemilik Rumah, Anda perlu membuat entitas Tanda Zodiak dan mentransfer atribut Tanda Zodiak ke sana (Entitas Pemilik Rumah direduksi menjadi bentuk normal ketiga):

Pembatasan

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

Prosedur tersimpan

Prosedur tersimpan adalah prosedur yang telah dikompilasi sebelumnya dan disimpan dalam database. Prosedur tersimpan dapat digunakan untuk mendefinisikan peraturan bisnis, dengan bantuannya Anda dapat melakukan penghitungan yang lebih rumit daripada hanya menggunakan batasan.
Prosedur tersimpan dapat berisi logika aliran program serta kueri basis data. Mereka dapat menerima parameter dan mengembalikan hasil sebagai tabel atau nilai tunggal.
Prosedur tersimpan mirip dengan prosedur atau fungsi biasa dalam program apa pun.

CATATAN
Prosedur tersimpan berada di database dan dijalankan di server database. Umumnya lebih cepat dibandingkan pernyataan SQL karena disimpan dalam bentuk terkompilasi.

Integritas data

Setelah mengatur data ke dalam tabel dan menentukan hubungan di antara mereka, kita dapat menganggap bahwa sebuah model telah dibuat, dengan cara yang benar mencerminkan lingkungan bisnis. Sekarang kita perlu memastikan bahwa data yang dimasukkan ke dalam database memberikan gambaran yang benar tentang keadaan. Dengan kata lain, Anda perlu memastikan bahwa aturan bisnis dipatuhi dan integritas database tetap terjaga.
Misalnya, perusahaan Anda mengirimkan buku. Kecil kemungkinan Anda akan menerima pesanan dari klien yang tidak dikenal, karena Anda bahkan tidak akan dapat mengirimkan pesanan tersebut. Oleh karena itu aturan bisnisnya: pesanan hanya diterima dari klien 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 pengidentifikasi unik dan berisi data. Lagi pula, Anda perlu membedakan semua catatan ini di 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 menyisipkan, memperbarui, dan menghapus catatan. Integritas referensial memastikan bahwa untuk setiap kunci asing terdapat kunci utama yang sesuai. Mari kita ambil contoh sebelumnya dengan entitas Pemilik Rumah dan Rumah. Katakanlah Anda adalah Vasya Ivanov dan Anda memiliki rumah. Anda mengubah nama belakang Anda menjadi Sidorov dan membuat perubahan terkait pada entitas Pemilik Rumah. Anda pasti ingin rumah Anda terus didaftarkan dengan nama baru Anda, dan bukan milik Vasya Ivanov tertentu, yang sudah tidak ada lagi.
• Aturan integritas khusus- aturan integritas apa pun yang tidak termasuk dalam kategori mana pun yang tercantum.

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 data dalam tabel diubah.
Dengan menggunakan pemicu, Anda tidak hanya dapat membatalkan perubahan ini, namun juga mengubah data di tabel lainnya.
Misalnya, Anda membuat forum online, dan Anda perlu memastikan bahwa postingan forum terbaru ditampilkan di daftar forum. Tentu saja, Anda dapat mengambil pesan dari entitas Pesan Forum, namun hal ini akan meningkatkan kompleksitas permintaan Anda dan waktu eksekusinya. Lebih mudah untuk menambahkan pemicu ke entitas Postingan Forum, yang akan mencatat pesan terakhir yang ditambahkan ke entitas Forum, di atribut Postingan Terakhir. Ini akan sangat menyederhanakan permintaan tersebut.

Peraturan bisnis

Aturan bisnis menentukan batasan yang diterapkan pada data sesuai dengan kebutuhan bisnis (yang databasenya Anda buat). Aturan bisnis dapat terdiri dari serangkaian langkah yang diperlukan untuk menyelesaikan tugas tertentu, atau mungkin hanya berupa pemeriksaan untuk memastikan bahwa data yang dimasukkan benar. Aturan bisnis mungkin mencakup aturan integritas data. Tidak seperti peraturan lainnya, tujuan utamanya adalah untuk memastikan pelaksanaan transaksi bisnis yang benar.
Misalnya, di perusahaan Very Cool Guys, mungkin sudah menjadi kebiasaan jika hanya mobil berwarna putih, biru, dan hitam yang dibeli untuk keperluan resmi.
Maka aturan bisnis untuk atribut Warna Kendaraan pada entitas Kendaraan Perusahaan adalah kendaraan hanya boleh berwarna putih, biru, atau hitam.
Kebanyakan DBMS menyediakan fasilitas:

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

Semua kemampuan 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, atribut diubah menjadi tabel dan atribut menjadi kolom.
Hubungan antar entitas dapat diubah menjadi tabel atau dibiarkan sebagai kunci asing.
Kunci utama diubah menjadi batasan kunci utama. Kunci yang mungkin ada dalam batasan keunikan.

Denormalisasi

Denormalisasi adalah perubahan yang disengaja pada struktur alas yang melanggar aturan bentuk normal. Hal ini biasanya dilakukan untuk meningkatkan kinerja database.
Secara teori, Anda harus selalu mengupayakan basis yang dinormalisasi sepenuhnya, namun dalam praktiknya, normalisasi basis sepenuhnya hampir selalu berarti penurunan kinerja. Normalisasi database yang berlebihan dapat mengakibatkan beberapa tabel harus diakses setiap kali data diambil. Biasanya, kueri harus melibatkan empat tabel atau kurang.
Teknik denormalisasi yang standar adalah: menggabungkan beberapa tabel menjadi satu, menyimpan atribut yang sama dalam beberapa tabel, dan menyimpan ringkasan atau data hasil perhitungan dalam sebuah tabel.

Atribut.

Bidang subjek.

Basis data. Definisi.

DBMS. Definisi.

Basis data. Definisi.

Bentuk normal ketiga. Definisi. Contoh.

Suatu variabel relasi R berada pada bentuk normal ketiga jika dan hanya jika kondisi berikut:

· R berada pada bentuk normal kedua.

· tidak ada atribut bukan kunci R yang berada dalam ketergantungan fungsional transitif (yaitu ketergantungan tidak diungkapkan melalui atribut lain) pada kunci kandidat R.

Atribut bukan kunci dari suatu relasi R adalah atribut yang tidak termasuk dalam salah satu kunci potensial R.

Basis data- ini adalah satu atau lebih file data yang dimaksudkan untuk menyimpan, mengubah, dan memproses informasi yang saling terkait dalam jumlah besar, disistematisasikan sedemikian rupa sehingga bahan-bahan tersebut 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 memungkinkannya menangani panggilan database dari aplikasi pengguna akhir.

Basis data- otomatis Sistem Informasi penyimpanan terpusat dan penggunaan data secara kolektif. Bank data mencakup satu atau lebih database, direktori database, DBMS, serta perpustakaan query dan program aplikasi.

Bidang subjek- ini adalah bagian dunia nyata, untuk dipelajari guna membuat database untuk mengotomatisasi proses pengelolaan.

Atribut– unit terkecil dari struktur data. Setiap elemen diberi nama unik saat membuat database. Disebut dengan nama ini selama pemrosesan.

Esensi– objek konkrit atau abstrak apa pun dalam bidang 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) Menentukan struktur database yang akan 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 data logis dan fisik.

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

5) Perlindungan integritas fisik - sarana pemulihan database (transaksi).

6) Mengelola izin pengguna untuk mengakses database.

7) Sinkronisasi pekerjaan beberapa pengguna.

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

9) Dukungan terhadap aktivitas personel sistem

Beberapa tahun yang lalu, di antara kegiatan saya yang lain, ada pelajaran online tentang dasar-dasar membangun struktur database logis dan bahasa SQL. Saya tidak sedang melakukan pelajaran saat ini, tetapi rekamannya sendiri tetap ada, jadi saya putuskan untuk mempostingnya, mengapa disia-siakan? 🙂

Hari ini kita akan berbicara tentang model hubungan entitas.

Teori

Model Entity-Relationship atau model ER adalah model data konseptual tingkat tinggi yang dikembangkan untuk menyederhanakan tugas merancang struktur database.

Model ini merupakan sekumpulan konsep yang menggambarkan struktur database sebagai sekumpulan entitas, atribut dan relasi. Tujuan utama pengembangan model data tersebut adalah untuk menciptakan persepsi pengguna terhadap data dan menyelaraskan sejumlah besar aspek teknis yang terkait dengan desain basis data. Perlu dicatat secara khusus bahwa model data konseptual tidak bergantung pada DBMS spesifik atau platform perangkat keras yang digunakan untuk mengimplementasikan database.

Tujuan dari diagram “hubungan entitas” adalah untuk menciptakan representasi yang akurat dan lengkap dari area subjek nyata (SbA), yang selanjutnya digunakan sebagai sumber informasi untuk membangun database sistem pemrosesan informasi otomatis (AISDB).

Diagram atau model konseptual SbA ini harus memenuhi persyaratan berikut:

• Pastikan tampilan SbA memadai;
• Hadir dalam bahasa yang dapat dimengerti oleh pengguna ASOI dan pengembang basis data di masa depan;
• Berisi informasi tentang SbA yang cukup untuk desain database lebih lanjut (pengembangan model logis dan fisik);
• Menjamin interpretasi atau interpretasi model SbA yang jelas.

Konsep utama model ini adalah konsep entitas, atribut, dan relasi.

ESENSI adalah sekumpulan objek di dunia nyata yang mempunyai sifat yang sama. Suatu entitas dicirikan oleh keberadaan yang independen dan dapat berupa objek dengan keberadaan fisik (atau nyata) atau objek dengan keberadaan konseptual (atau abstrak).

Entitas mewakili konten utama dari fenomena atau proses (transaksi atau permintaan) tentang informasi mana yang perlu dikumpulkan, dan merupakan titik simpul untuk mengumpulkan informasi. Entitas mengacu pada sekumpulan objek atau benda yang homogen. Setiap entitas diidentifikasi berdasarkan nama dan daftar properti (atribut). Entitas dapat berupa orang, tempat, benda, dan lain-lain, yang informasinya harus disimpan dalam database.

Praktik

CONTOH. Bidang subjek " Memesan tiket di bioskop" Bioskop menayangkan film, tiketnya dapat dibeli pada hari pemutaran film atau dipesan terlebih dahulu. Basis data berisi informasi tentang semua Pertunjukan Film di bioskop tertentu, termasuk yang lama. Setiap pemutaran film memiliki biayanya masing-masing, yakni tiket untuk film yang sama, tetapi masuk waktu yang berbeda, harga mungkin berbeda. Pameran film terdiri dari sebuah Film yang informasinya juga disimpan dalam database.

Untuk Perangkat Lunak “ Memesan tiket di bioskop” entitasnya adalah konsep berikut:

Pemutaran film

Film

Penonton

Tiket

Reservasi

Harga

Secara grafis, entitas dalam diagram hubungan entitas direpresentasikan sebagai persegi panjang:

ATRIBUT— itu adalah sarana yang mendefinisikan properti suatu entitas atau hubungan. Atribut adalah karakteristik bernama suatu entitas. Nama atribut harus unik untuk entitas tertentu, namun bisa sama untuk entitas berbeda.

Kumpulan atribut spesifik untuk suatu entitas ditentukan oleh tugas di mana atribut tersebut digunakan. Misalnya, entitas SbA “Pemesanan tiket di bioskop” dapat dijelaskan menggunakan serangkaian atribut berikut:

Pemutaran film(Nomor film, Nomor film, Tanggal tayang, Nomor biaya);

Film(Nomor Film, Judul, Durasi, Deskripsi Singkat);

Penonton(Nomor penampil, nama lengkap, tanggal lahir);

Tiket(Nomor Penonton, Nomor Pemutaran Film, Harga Tiket);

Reservasi(Nomor penonton, nomor pemutaran film, tanggal reservasi);

Harga(Nomor biaya, nomor pemutaran film, biaya).

Secara grafis, gambar atribut entitas disajikan dalam bentuk callout yang mencantumkan daftar nama atribut. Misalnya:

Huruf miring tebal dan garis bawah menunjukkan kunci utama - atribut suatu entitas yang menjadi ciri uniknya. Garis bawah menunjukkan kunci asing—atribut yang secara unik mencirikan entitas yang dirujuknya.

KONEKSI adalah hubungan antara instance dari dua (atau lebih) entitas yang berbeda. Mekanisme linkage digunakan untuk menentukan hubungan antar entitas dalam suatu SbA. Selain itu, terdapat hubungan antara atribut dari entitas yang terpisah (akan dipertimbangkan saat membangun model logis).

Setiap tautan diberi nama yang menggambarkan fungsinya. Koneksi mempunyai ciri-ciri seperti nama koneksi, indikator kardinalitas, derajat partisipasi, derajat koneksi, umur koneksi, dan lain-lain.

Nama relasi harus memiliki arti tertentu agar lebih mudah memahami bagaimana entitas-entitas tersebut terkait. Misalnya, hubungan antara entitas Penonton dan Tiket dapat didefinisikan sebagai “Beli”.

Untuk merepresentasikan hubungan secara grafis dalam diagram hubungan entitas, digunakan berlian. Di dalam berlian, nama koneksi ditentukan, dan entitas yang berpartisipasi dalam koneksi ini dihubungkan menggunakan garis.

Indikator kardinalitas tautan (karakteristik keunikan) menunjukkan tingkat interkoneksi antar entitas dan menggambarkan jumlah kemungkinan koneksi untuk setiap entitas yang berpartisipasi:

• satu lawan satu (1:1);
• satu-ke-banyak (1:N);
• banyak-ke-banyak (N:M).

Zaitsev S.L., Ph.D.

Bagian 1. Konsep esensi

Pada artikel ini kami akan menjelaskan entitas dan kunci entitas secara detail. Seperti yang Anda ketahui, esensi- ini adalah konsep tentang informasi mana yang harus disimpan untuk diproses lebih lanjut. DI DALAM entitas ERwin adalah representasi grafis dari pengelompokan data yang logis. Entitas dapat berwujud, objek nyata, atau abstraksi konseptual yang tidak berwujud. Entitas tidak dimaksudkan untuk mewakili satu entitas. Sebaliknya, mereka mewakili kelas yang mencakup atribut yang berisi informasi tentang beberapa contoh.

Pertanyaan mengenai entitas berikut akan dibahas di bawah ini:

• Diagram Relasional Entitas
• Pemilihan entitas
• Mendefinisikan Jenis Entitas
• Memberi nama dan mendeskripsikan entitas
• Kesalahan umum saat bekerja dengan entitas

Karena ERwin menggunakan metodologi pemodelan data UGD(Entitas Relasional) mari kita mulai dengan pengenalan singkat tentang konsep ER. Pertama, mari kita mulai mempelajari entitas - “wadah” untuk menyimpan informasi model logis.

Pengantar Diagram Entitas Relasional

Publikasi ini dan publikasi lain mengenai topik ini menggunakan ERD (Entity Relational Diagram), berdasarkan notasi yang digunakan oleh ERwin. Meskipun ada metodologi pemodelan data lain, seperti Extended Relational Analysis (ERA), Object Oriented (OO), dan Object Role Modeling (ORM), konsep dasar metodologi ER ada dan di dalamnya.

Metodologi pemodelan ER dikembangkan oleh P. Chen pada akhir tahun 1970-an. Persegi panjang digunakan untuk mewakili entitas dalam metodologi ER. Dalam notasi ER asli Chen, relasi mengandung atribut. Kemungkinan yang sama dalam menggunakan atribut dalam entitas dan relasi membuat pembedaan antara entitas dan relasi menjadi cukup sulit.

Pendekatan ER telah berubah dan berkembang seiring berjalannya waktu, namun konsep inti terus memberikan landasan yang kuat untuk pemodelan data cerdas.

Selanjutnya diberikan Detil Deskripsi entitas dan memberikan informasi awal tentang kunci dengan penekanan khusus pada pencarian kunci utama untuk suatu entitas. Deskripsi tipe entitas juga disediakan, dan rekomendasi diberikan untuk penamaan dan deskripsi entitas. Bagian terakhir dikhususkan untuk analisis kesalahan khas terkait dengan entitas dan kunci.

Apa itu entitas?

Esensi adalah representasi fisik dari pengelompokan data secara logis. Entitas dapat berupa objek nyata yang berwujud seperti ORANG atau ES KRIM, atau abstraksi konseptual yang tidak berwujud seperti PUSAT BIAYA atau PASAR. Entitas tidak dimaksudkan untuk mewakili satu entitas tunggal, melainkan kumpulan contoh yang berisi informasi menarik dalam hal keunikannya. Misalnya, entitas PERSON adalah turunan dari objek bertipe Person. Ivan Petrov, Maria Rusanova dan Savely Bogdanov - contoh spesifik contoh entitas PERSON. Contoh spesifik suatu entitas diwakili oleh baris tabel dan diidentifikasi oleh kunci utama.

Entitas tersebut memiliki karakteristik sebagai berikut:

• Ada nama dan deskripsinya.
• Ini mewakili sebuah kelas, bukan satu contoh abstraksi.
• Perwakilan spesifiknya (contoh) dapat diidentifikasi secara unik.
• Ini berisi pengelompokan logis dari atribut yang mewakili informasi yang menarik bagi perusahaan.

Definisi formal suatu entitas

Di bawah ini adalah daftar definisi entitas dari otoritas yang diakui di bidang pemodelan data. Perhatikan persamaannya:

• Chen (1976): “Suatu hal yang dapat diidentifikasi secara unik.”
• Date (1986): "Objek apa pun yang dapat dibedakan yang akan direpresentasikan dalam database."
• Finklestein (1989): "Entitas informasi mewakili 'sesuatu' yang disimpan untuk referensi nanti. Istilah entitas mengacu pada representasi logis dari data."

Pemilihan entitas

Bagaimana cara memulai proses ekstraksi entitas? Sebagian besar entitas diidentifikasi selama sesi kerja dan wawancara. Analisis kebutuhan informasi dari pakar materi pelajaran dan pengguna akhir adalah sumber informasi terbaik.

Sumber bagus lainnya adalah model korporat.

Perhatikan kata benda dan nama objek - kemungkinan besar keduanya akan menjadi entitas logis. Hindari merepresentasikan satu instance sebagai entitas, seperti yang sering terjadi ketika entitas dimodelkan berdasarkan peran. Memodelkan entitas berdasarkan peran adalah kesalahan yang cukup umum. Entitas juga muncul selama proses normalisasi. Mengurangi model logis ke bentuk normal ketiga kemungkinan besar akan menghasilkan munculnya beberapa entitas tambahan.

Ada dua kelompok utama entitas: bergantung dan mandiri. Entitas independen tidak memerlukan informasi dari entitas lain untuk mengidentifikasi instance unik. Dia memperkenalkan dirinya pada ERwin dalam bentuk persegi panjang. Kunci utama suatu entitas independen tidak mencakup kunci utama entitas lain.
Entitas dependen harus mengambil informasi dari entitas lain untuk mengidentifikasi kejadian unik. Pada diagram ER direpresentasikan sebagai persegi panjang dengan sudut membulat. Kunci utama entitas dependen mencakup kunci utama dari satu atau lebih entitas induk.

Beras. 2.1. Contoh entitas inti untuk perusahaan yang menjual es krim.

Perhatikan gambar. 2.1., yang menunjukkan sudut siku-siku dari entitas independen STORE dan ICE CREAM dan sudut membulat dari entitas dependen ICE CREAM STORE.

Mendefinisikan Jenis Entitas

Entitas dependen dan independen dapat dibagi menjadi beberapa jenis:

• Entitas inti - Kadang-kadang disebut entitas inti atau primer. Mereka mewakili objek penting tentang informasi yang harus disimpan.
• Kode/Referensi/Pengklasifikasi - Entitas ini berisi string yang menentukan sekumpulan nilai atau cakupan suatu atribut.
• Entitas Asosiatif - Entitas ini digunakan untuk menyelesaikan hubungan banyak ke banyak.
• Entitas karakteristik - Entitas ini terdiri dari dua jenis: eksklusif dan inklusif.

Entitas inti

Entitas inti mewakili objek informasi perusahaan yang paling penting. Kadang-kadang disebut entitas primer, utama, atau inti. Karena entitas ini sangat penting, kemungkinan besar mereka digunakan di banyak bagian perusahaan. Luangkan waktu untuk mencari entitas serupa, karena entitas inti kemungkinan besar dapat digunakan kembali. Dalam suatu perusahaan, entitas inti harus dimodelkan secara konsisten. Pemodel yang baik memandang pendekatan ini sangat berguna.

Entitas inti dapat bersifat independen atau bergantung. Gambar 2.1 menunjukkan contoh entitas inti perusahaan yang menjual es krim. Entitas ICE CREAM mewakili produk dasar korporasi. Entitas STORE merupakan salah satu contoh saluran distribusi atau perantara penjualan barang.

Mari kita asumsikan bahwa korporasi berjalan dengan baik dan keputusan telah diambil untuk membuka TOKO tambahan. Untuk menambahkan instance baru dari entitas STORE, tidak perlu mengubah model. Hal yang sama berlaku untuk entitas ICE CREAM.

Perhatikan entitas inti ICE CREAM dan STORE. Meskipun contohnya mungkin terlihat mudah, contoh ini menggambarkan kekuatan konsep di balik pemodelan entitas inti.
Memahami kebutuhan untuk memodelkan entitas inti sebagai wadah yang dapat diskalakan dan diperluas mengharuskan pemodel untuk memandang entitas sebagai konsep abstrak dan memodelkan informasi yang tidak bergantung pada cara penggunaannya saat ini. Dalam contoh ini, model entitas ICE CREAM sepenuhnya berada di luar konteks entitas STORE dan sebaliknya. Jadi jika suatu perusahaan memutuskan untuk menjual ES KRIM melalui saluran distribusi baru, seperti Internet atau pengiriman ke rumah, saluran distribusi baru tersebut dapat ditambahkan tanpa perubahan pada entitas lain.

Entitas Kode

Entitas Kode selalu mandiri. Mereka sering disebut referensi, pengklasifikasi, atau tipe entitas, bergantung pada metodologi yang digunakan. Contoh unik yang diwakili oleh entitas kode menentukan cakupan nilai atribut milik entitas lain. Hubungan antara entitas kode dan entitas lain akan dibahas pada postingan mendatang tentang topik ini. Anda mungkin tergoda untuk menggunakan satu atribut dalam tabel kode. Jauh lebih baik untuk menyertakan setidaknya tiga atribut dalam entitas pengkodean: pengidentifikasi, nama (terkadang disebut nama pendek) dan definisi.

Pada Gambar 2.2 ATAS- entitas independen (perhatikan sudut siku-siku). TOP juga merupakan entitas kode atau pengklasifikasi. Instance (baris) dari entitas TOP menentukan daftar puncak yang tersedia.

Entitas kode biasanya berisi atribut dalam jumlah terbatas. Ada implementasi dimana entitas ini hanya memiliki satu atribut. Lebih baik memodelkan entitas kode menggunakan pengidentifikasi buatan. Pengidentifikasi buatan, bersama dengan nama dan definisi, memungkinkan jenis TOP baru ditambahkan sebagai instance (string) ke entitas. Perhatikan tiga atribut entitas TOP.

Para profesional sering menyebut entitas kode sebagai objek bisnis perusahaan. Istilah objek bisnis perusahaan menunjukkan bahwa entitas didefinisikan dan dibagikan pada tingkat perusahaan, bukan pada tingkat aplikasi, sistem, atau unit organisasi tunggal. Entitas ini sering kali dibagi ke dalam beberapa database untuk memberikan pendekatan holistik terhadap ringkasan pelaporan dan analisis tren.

Beras. 2.2. Entitas kode memungkinkan perusahaan untuk menentukan serangkaian nilai untuk penggunaan terpusat dalam perusahaan. Contoh entitas kode menentukan cakupan untuk menentukan nilai untuk digunakan di bagian lain model.

Entitas Asosiatif

Asosiatif adalah entitas yang berisi kunci utama dari dua atau lebih entitas lain. Entitas asosiatif selalu bergantung. Mereka digunakan untuk menyelesaikan hubungan banyak-ke-banyak antara entitas lain. Hubungan banyak-ke-banyak terjadi ketika beberapa instance dari satu entitas dikaitkan dengan beberapa instance dari entitas lainnya. Entitas asosiatif memungkinkan kita memodelkan perpotongan instance dari dua entitas, memastikan bahwa setiap instance asosiasi bersifat unik.

Pada Gambar 2.1, entitas asosiatif digunakan untuk menyelesaikan suatu hubungan banyak ke banyak antara entitas STORE dan ICE CREAM. Pengenalan entitas asosiatif memungkinkan penggunaan ES KRIM yang sama untuk dijual di beberapa salinan TOKO, tanpa perlu menjual jenis ES KRIM yang sama di setiap TOKO. Entitas asosiatif ICE CREAM SHOP memperhitungkan fakta bahwa sebuah instance dari sebuah STORE menjual banyak instance dari ICE CREAM, dan sebuah instance dari ICE CREAM dapat dijual oleh banyak instance dari sebuah STORE.

Entitas Karakteristik

Entitas Karakteristik selalu bergantung. Anda harus menggunakan entitas karakteristik yang memungkinkan instance entitas menyimpan kumpulan atribut yang berbeda. Finklestein menyebut entitas karakteristik sebagai entitas sekunder. Entitas karakteristik selalu memiliki satu atau lebih entitas "rekan". Entitas karakteristik rekan terkait dengan entitas induk melalui tipe hubungan khusus yang dapat bersifat eksklusif atau inklusif.

Gambar 2.3 menunjukkan entitas CONTAINER dan karakteristik entitas HORN dan CUP. Toko es krim tersebut rupanya tidak menjual berdasarkan beratnya, melainkan per porsi. Harap dicatat bahwa instance CONTAINER harus berupa HORN atau CUP. WADAH tidak bisa menjadi TANDUK sekaligus CANGKIR. Ini adalah entitas dengan karakteristik eksklusif.

Entitas PERSON pada Gambar 2.3 memiliki dua entitas karakteristik EMPLOYEE dan CLIENT. Perhatikan bahwa entitas dengan karakteristik eksklusif tidak akan mengizinkan satu contoh PERSON berisi fakta yang umum bagi KARYAWAN dan KLIEN. Tentu saja hal ini bertentangan dengan praktik nyata. Seorang KARYAWAN pasti bisa menjadi KLIEN. PEMASOK juga dapat bertindak sebagai KLIEN. Ini adalah contoh entitas berkarakter inklusif.

Beras. 2.3. Dua contoh entitas karakteristik adalah PERSON dan CONTAINER. Kedua contoh tersebut menggunakan notasi ERwin IE untuk merepresentasikan entitas dengan karakteristik eksklusif dan inklusif. Tidak adanya tanda (X) pada simbol entitas karakteristik menunjukkan hubungan inklusif.

Entitas struktural

Terkadang instance dari entitas yang sama saling terkait. Dalam bukunya tahun 1992 "Pengembangan Sistem Strategis" K. Finklestein mengusulkan penggunaan entitas struktural untuk mewakili hubungan antara instance dari entitas yang sama. Hubungan antar instance dari entitas yang sama disebut hubungan rekursif. Hubungan rekursif akan dibahas pada artikel “Konsep Hubungan”. Hubungan rekursif adalah konsep yang logis, dan konsep tersebut tidak mudah dipahami oleh pengguna.

Gambar 2.4 menunjukkan entitas struktural tambahan yang menggambarkan hubungan antara instance entitas EMPLOYEE. Diagram menunjukkan bahwa entitas karakteristik EMPLOYEE dari entitas PERSON memiliki dua entitas karakteristik EXECUTOR dan MANAGER. Entitas EMPLOYEE STRUCTURE mewakili hubungan antara instance entitas EMPLOYEE.

Beras. 2.4. Esensi struktural merupakan ilustrasi pendekatan K. Finklestein dalam menyelesaikan hubungan rekursif.

Mendefinisikan Kunci Utama

Untuk mengidentifikasi instance spesifik suatu entitas, Anda perlu menentukan kunci utama. Kunci utama adalah atribut atau sekumpulan atribut yang secara unik mengidentifikasi satu instance dari suatu entitas. Dengan kata lain, kunci utama dapat berupa satu atribut atau terdiri dari beberapa atribut. Kunci utama yang terdiri dari lebih dari satu atribut disebut kunci komposit atau komponen. Berikut ini kita akan menggunakan istilah tersebut kunci komposit.

Kunci utama harus statis dan non-volatil. Statis dan tidak dapat dihancurkan berarti kunci utama tidak boleh diubah. Perubahan pada kunci utama sulit untuk dipertahankan, yang sering kali memerlukan pengerjaan ulang yang sangat mahal, jadi pilihan terbaik adalah ketika kunci utama benar-benar independen dari instance entitas.

Menemukan kunci utama memerlukan analisis data yang mendefinisikan entitas. Biasanya, kunci utama untuk entitas inti ditentukan selama sesi kerja dan diskusi. Pakar dan pengguna domain adalah sumber informasi yang baik untuk memilih kunci utama potensial. Data sampel juga memberikan masukan berharga saat memilih kunci utama.

Mulailah proses mengidentifikasi kunci utama dengan mengidentifikasi semua atribut yang berpotensi menjadi kunci, yang disebut kandidat kunci. Kunci kandidat dapat berupa satu atribut atau kombinasi beberapa atribut. Jika tidak ada kunci kandidat, atau kandidat merupakan kunci komposit yang terlalu besar dan berat, pertimbangkan untuk menggunakan pengidentifikasi unik buatan. Kunci yang dipinjam dari entitas induk disebut kunci asing. Kunci asing akan dibahas dalam publikasi mendatang mengenai topik ini. Di bawah ini adalah penjelasan dari berbagai jenis kunci:

• Kandidat kunci. Kunci kandidat adalah atribut atau sekumpulan atribut yang mengidentifikasi satu instance dari suatu entitas. Terkadang satu instance dari suatu entitas diidentifikasi oleh beberapa atribut atau kombinasi dari atribut-atribut tersebut.
• Kunci komposit. Kunci yang terdiri dari lebih dari satu atribut disebut kunci gabungan, kompleks, atau komponen. Untuk kunci komposit, setiap komponen kunci harus memiliki nilai untuk setiap instance. Tidak ada bagian dari kunci yang harus nol. Semua bagian kunci wajib diisi dan tidak dapat dihilangkan.
• Dan kunci primer buatan. Terkadang tidak ada atribut tunggal atau kombinasi atribut yang mendefinisikan sebuah instance. Dalam kasus ini, Anda menggunakan pengidentifikasi unik buatan. Kunci primer buatan sering kali hanya memberi nomor pada setiap instance atau kode.
• Kunci asing. Ketika kunci utama dari satu entitas berpindah ke tabel lain, itu disebut kunci asing. Kunci asing “menghubungkan” entitas dengan mewakili hubungan di antara mereka. Kunci asing akan dibahas lebih detail di artikel mendatang tentang topik ini.

Mengurangi model ke bentuk normal ketiga termasuk memeriksa tidak adanya ketergantungan fungsional dan mengidentifikasi kunci primer atau komposit. Ketergantungan fungsional dibahas dalam artikel play peran penting ketika mengidentifikasi kunci utama dan kandidat kunci.

Penamaan Entitas

Nama yang diberikan pada suatu entitas harus mencirikan contoh entitas tersebut. Namanya harus jelas dan diterima secara umum. Saat memilih nama, ambil perspektif perusahaan dan coba gunakan nama yang mencerminkan cara penggunaan data di dalam perusahaan, bukan di departemen tertentu. Gunakan nama yang bermakna bagi komunitas pengguna dan pakar domain.

Perusahaan Anda kemungkinan besar memiliki serangkaian konvensi penamaan yang Anda gunakan selama pengembangan atau saat membangun model data perusahaan. Penggunaan konvensi memastikan bahwa nama dibangun secara konsisten dalam suatu perusahaan, terlepas dari siapa yang membangun nama tersebut. Bagian berikut memberikan serangkaian konvensi penamaan awal dan memberikan contoh konvensi penamaan yang baik dan buruk.

Konvensi penamaan entitas

Konvensi penamaan mungkin tampak tidak penting jika Anda bekerja di organisasi kecil dengan sedikit pengguna. Namun, dalam organisasi besar dengan banyak tim pengembangan dan sejumlah besar pengguna, konvensi penamaan sangat membantu komunikasi dan berbagi data. Idealnya, Anda mengembangkan dan memelihara konvensi penamaan secara terpusat, lalu mendokumentasikannya dan mempublikasikannya ke seluruh perusahaan.

Berikut adalah beberapa pedoman untuk membuat serangkaian konvensi penamaan awal, jika organisasi Anda belum mengembangkannya:

• Nama entitas harus cukup deskriptif. Gunakan nama satu kata hanya jika nama tersebut merupakan nama konsep yang diterima secara luas. Pertimbangkan untuk menggunakan frasa berbasis kata benda.
• Nama entitas harus berupa kata benda atau frasa kata benda tunggal. Gunakan PERSON sebagai ganti PERSONS atau PEOPLE, dan CONTAINER sebagai ganti CONTAINERS.
• Nama entitas harus unik. Menggunakan nama yang sama untuk entitas yang berisi data berbeda, atau nama berbeda untuk entitas yang berisi data yang sama, tidak akan membingungkan pengembang dan pengguna akhir.
• Nama entitas harus menunjukkan data yang akan disimpan di setiap instance.
• Nama entitas tidak boleh mengandung karakter khusus (seperti!, @, #, $, %, &, * dan sejenisnya) atau menunjukkan kepemilikan (PERSON ICE CREAM).
• Nama entitas tidak boleh mengandung akronim atau singkatan kecuali merupakan bagian dari konvensi penamaan yang diterima.

Contoh nama entitas yang baik

Yang terbaik adalah selalu menggunakan nama yang konsisten dalam perusahaan. Tabel 2.1 menunjukkan contoh nama baik dan buruk suatu entitas.

TABEL 2.1 Contoh nama entitas beserta penjelasannya

Nama baik	Nama yang buruk	Penjelasan
FORMULA MATEMATIKA	RUMUS	FORMULA terlalu kabur; menambahkan kata sifat MATEMATIKA akan sangat memperjelas maknanya.
BUKU	BUKU	BUKU adalah kata benda tunggal.
SOFA	SOFA SOFA	SOFA dan COUCH mempunyai arti yang sama. Pilih satu hal.
ES KRIM	BEBERAPA ES KRIM	Kata ganti BEBERAPA tidak menambahkan arti atau makna tambahan apa pun pada istilah tersebut. Hindari penambahan yang tidak perlu.
FOTO	GAMBAR	FOTO - cukup pasti. GAMBAR - agak buram.
PERKIRAAN WAKTU KEDATANGAN	ORP	Singkatan ORP mungkin tidak jelas bagi pengguna.
PERUSAHAAN	PERUSAHAAN XYZ	XYZ adalah contoh spesifik dari suatu perusahaan dan harus berupa baris dalam entitas PERUSAHAAN.

Deskripsi entitas

Bahkan nama baik yang menunjukkan kepada pengguna informasi apa yang diharapkan dari entitas biasanya tidak cukup. Setiap entitas membutuhkan informasi yang jelas, tepat dan deskripsi lengkap atau definisi agar dapat ditafsirkan dengan jelas di dalam perusahaan. Deskripsi entitas harus menjelaskan arti entitas dan signifikansinya bagi korporasi.

Meskipun deskripsi, definisi, dan tujuan sering digunakan secara bergantian, istilah deskripsi lebih disukai karena mendorong kita untuk mendeskripsikan entitas dalam istilah yang dapat dipahami oleh pengguna.

Aturan untuk membuat deskripsi yang baik

Deskripsi suatu entitas harus menjelaskan maknanya, bukan bagaimana informasi entitas tersebut akan digunakan. Anda harus mengumpulkan deskripsi entitas selama identifikasi entitas. Berhati-hatilah saat menyertakan informasi penggunaan: informasi tersebut harus digunakan untuk tujuan ilustrasi atau ilustrasi saja. Cara informasi digunakan lebih sering berubah daripada informasi itu sendiri, sehingga penggunaan informasi tidak konstan.

Deskripsi entitas harus jelas, tepat, lengkap dan konsisten. Ini harus dirumuskan tanpa menggunakan istilah-istilah teknis, dapat dimengerti oleh siapa saja yang setidaknya sedikit familiar dengan konsep yang sedang dijelaskan. Pastikan deskripsi diungkapkan dalam istilah bisnis dan mencakup penjelasan tentang pentingnya entitas tersebut.

Contoh deskripsi yang bagus

Tabel 2.2 tidak dimaksudkan untuk menjelaskan secara komprehensif, namun berfungsi untuk menunjukkan gambaran yang baik dan alasan mengapa gambaran yang buruk tidak memenuhi prinsip-prinsip dasar.

TABEL 2.2. Deskripsi entitas beserta penjelasannya

Deskripsi yang bagus	Deskripsi buruk	Penjelasan
PERSON berisi informasi tentang individu siapa yang masuk ke dalam interaksi dengan korporasi. Informasi o PERSON membantu korporasi dalam perencanaan, pengembangan produk dan kegiatan promosi.	Klien atau karyawan.	Deskripsi yang baik mencakup definisi entitas dan signifikansinya bagi korporasi.
	Termasuk nama, tanggal lahir, dll. untuk seseorang.	Pencacahan sederhana atribut entitas tidak dapat dilakukan informasi tambahan tentang apa itu entitas dan mengapa hal itu penting bagi perusahaan.
	informasi pengguna dan karyawan.	Pelanggan dan karyawan adalah contoh peran yang dapat dimainkan oleh ORANG. Penggunaan contoh saja tidak dapat menjelaskan apa itu suatu entitas atau mengapa entitas itu penting bagi suatu perusahaan.
	Entitas berisi karakter dan data numerik yang diekstraksi dari POS (Point Of Sale - terminal perdagangan), disimpan menggunakan kompresi standar dan angka desimal yang dikemas.	Itu contoh buatan dimaksudkan untuk menggambarkan bahwa deskripsi teknis dan akronim sulit dipahami oleh pengguna bisnis.

Kesalahan umum saat memodelkan entitas dan memilih kunci

Bagian tentang kesalahan pemodelan umum ini tidak dimaksudkan untuk lengkap. Tujuannya adalah untuk menunjukkan kesalahan paling umum yang dilakukan pemodel.

Pemodelan peran

Apa yang dimaksud dengan role model? Selama sesi kerja, pengguna mungkin memberi tahu Anda bahwa mereka perlu menyimpan informasi karyawan. Sangat menggoda untuk membuat entitas EMPLOYEE. Analisis yang lebih menyeluruh terhadap informasi yang menarik bagi korporasi, seperti nama, alamat dan nomor asuransi sosial menunjukkan bahwa nilai-nilai ini tidak bergantung pada entitas EMPLOYEE. Untuk EMPLOYEE tertentu, nilai atribut NAME tidak bergantung pada entitas EMPLOYEE. Hal ini mudah dimengerti ketika Anda memikirkan fakta bahwa nama Anda tetaplah nama Anda, baik Anda seorang KARYAWAN atau bukan.

Kelebihan Entitas

Entitas yang kelebihan beban adalah entitas yang berisi informasi tentang lebih dari satu objek konseptual. Jika beberapa atribut entitas menjelaskan konsep yang sama, entitas tersebut harus diperiksa. Entitas yang kelebihan beban tidak memiliki nilai untuk setiap atribut.

Terkadang pakar dari bidang studi yang berbeda di suatu perusahaan menggunakan nama entitas yang bunyi dan ejaannya sama, namun memiliki arti berbeda bagi pakar yang berbeda. Satu-satunya cara untuk memastikan bahwa nama yang sama menggambarkan objek yang sama adalah dengan memeriksa deskripsinya. Pastikan entitas berisi data yang menjelaskan satu konsep.

Misalnya, entitas EQUIPMENT mungkin memilikinya secara mutlak arti yang berbeda untuk departemen teknologi informasi dan untuk departemen media dan komunikasi.

Entitas yang Berlebihan

Entitas redundan adalah entitas yang memiliki nama berbeda tetapi berisi informasi tentang konsep serupa. Bahasa Inggris memiliki banyak kata untuk mewakili hal yang sama. Salah satu cara untuk menemukan entitas tersebut adalah dengan mencari entitas yang memiliki atribut serupa. Bandingkan deskripsi masing-masing entitas ini untuk menentukan apakah entitas tersebut mewakili konsep serupa. Entitas yang berlebihan sering kali diakibatkan oleh kecenderungan untuk memodelkan peran sebagai entitas.

Misalnya, entitas MANAGER dan EMPLOYEE mungkin berisi informasi serupa karena keduanya merupakan peran yang dapat dimainkan oleh instance entitas PERSON.

Memilih kunci utama yang salah

Memilih kunci utama yang salah berarti Anda telah memilih kunci utama yang tidak tahan terhadap pengujian. Kesalahan umum terkait kunci utama adalah:

• Non-unik: Kunci utama tidak unik untuk setiap instance. Misalnya, pemodel mungkin menganggap nomor Jaminan Sosial bersifat unik untuk setiap ORANG. Namun, nomor Jaminan Sosial dapat digunakan kembali jika pemilik aslinya meninggal dunia.
• Nilai/ketidakpastian yang diperlukan: Kunci utama tidak memiliki nilai untuk beberapa contoh. Misalnya, tidak semua entitas PERSON memiliki nomor Jaminan Sosial. Orang asing dan anak kecil adalah dua kategori orang yang tidak akan hadir.

Menggunakan nama entitas yang buruk

Nama yang membingungkan, ambigu, atau tidak tepat menyulitkan pengguna baru dan tim pengembangan untuk menggunakan kembali atau memperluas model yang sudah ada.

Jangan gunakan singkatan atau akronim sebagai bagian dari nama Anda. Singkatan dan akronim dapat disalahartikan dan bahkan mungkin memiliki arti yang berbeda dalam bidang studi yang berbeda.

Jangan sertakan lokasi sebagai bagian dari nama. Biasanya, Anda pasti membutuhkan lokasi lain. Nama spesifik lokasi merupakan indikasi bahwa Anda memodelkan instance tertentu, bukan kelas entitas.

Menggunakan Deskripsi Entitas Buruk

Jangan gunakan deskripsi yang hanya diambil dari kamus. Deskripsi kamus tidak akan menyertakan informasi bisnis yang relevan.

Jangan mencoba mengubah nama entitas. Jangan gunakan nama entitas dalam deskripsinya.

Deskripsi yang tidak jelas, tidak jelas, atau lebih buruk lagi, tidak lengkap menyulitkan penggunaan kembali dan memperluas model yang sudah ada. Pengguna tidak akan dapat memeriksa apakah entitas berisi semua informasi yang diperlukan.

Hal ini secara signifikan meningkatkan risiko pembuatan entitas yang kelebihan beban dan menggunakannya untuk menyimpan informasi tentang objek yang berbeda.

Konsep yang tampak jelas bagi semua orang yang terlibat dalam sesi kerja mungkin tidak begitu jelas seiring berjalannya waktu karena tim pengembangan baru ditugaskan untuk memperluas model yang sudah ada.

Kesimpulan

Entitas adalah objek yang informasinya harus dikumpulkan dan dipelihara. Mereka adalah “wadah” untuk mengatur dan mengelompokkan fakta bisnis. Entitas yang paling penting biasanya diidentifikasi dan didokumentasikan selama sesi kerja atau wawancara, dan sebagai hasil dari proses normalisasi.

Entitas dibagi menjadi dua kelompok utama: dependen dan independen. Entitas dependen memerlukan informasi dari entitas lain untuk mengidentifikasi suatu instance secara unik, sedangkan entitas independen tidak. Dalam dua kelompok entitas utama, tipe yang lebih terspesialisasi dibedakan, dengan fitur untuk mendukung tipe hubungan tertentu antara entitas utama dan bawahan.

Setiap entitas harus menyertakan satu atau lebih kumpulan atribut yang merupakan kunci kandidat. Kandidat kunci secara unik mengidentifikasi contoh spesifik dari suatu entitas. Kandidat kunci dapat terdiri dari satu atribut atau sekelompok atribut. Jika kandidat kunci tidak ada atau sulit dipertahankan, Anda mungkin perlu membuat kunci primer buatan. Analisis dan penelitian memainkan peran penting dalam mengidentifikasi kunci utama yang akan tetap unik dan dapat diandalkan seiring berjalannya waktu.

Entitas memerlukan nama dan deskripsi yang baik. Standar dan konvensi penamaan memberikan pendekatan holistik untuk mengembangkan nama dan deskripsi. Karakteristik suatu entitas ditentukan oleh atribut-atribut yang dikandungnya. Atribut entitas mewakili fakta tentang entitas yang ingin dikumpulkan dan dipelihara oleh perusahaan.

Artikel berikutnya dalam seri ini akan menjelaskan proses mengidentifikasi atribut dan karakteristiknya, mendefinisikan atribut kunci dan non-kunci, cakupan dan data opsional, dan menetapkan konvensi untuk menghasilkan nama dan deskripsi atribut yang baik.

Bagian 2. Konsep atribut

Artikel “Konsep Dasar Pemodelan Data” memperkenalkan konsep dasar yang terkait dengan pemodelan data. Di dalam artikel Komponen utama diagram ERwin - entitas, atribut, hubungan. Bagian 1. Konsep entitas, informasi awal tentang entitas dan kunci entitas diberikan. Artikel ini membahas atribut dan menjelaskan normalisasi dan kunci secara lebih rinci.

Dalam artikel ini Anda akan mempelajari cara:

• Identifikasi atribut
• Lakukan normalisasi selama analisis atribut
• Beri nama dan jelaskan atribut, dan pelajari tentang konvensi penamaan atribut
• Tentukan tipe dan karakteristik atribut, seperti cakupan dan tipe data Boolean, dan validasi kunci dari perspektif atribut
• Hindari kesalahan umum saat bekerja dengan atribut

Dalam diagram ER, entitas dan relasi berfungsi untuk mengelompokkan dan menggabungkan atribut. Atribut inilah yang membentuk esensi model. Jadi mari kita mulai mempelajari atribut – fakta yang membentuk informasi model logis.

Apa itu atribut?

Atribut adalah representasi logis dari fakta-fakta yang membuat perusahaan tertarik untuk menyimpan data. Ingatlah bahwa di ERwin, entitas berfungsi untuk secara visual mewakili pengelompokan atribut yang logis. Di sisi lain, atribut mewakili fakta yang dikumpulkan tentang entitas dalam model logis. Atribut adalah fakta yang berfungsi untuk mengidentifikasi, mengkategorikan, mewakili secara numerik, atau menggambarkan keadaan suatu instance entitas.

Atribut harus mewakili satu konsep. Atribut membentuk kelompok logis yang menggambarkan setiap contoh suatu entitas. Contoh spesifik dari suatu atribut adalah arti. Misalnya, atribut bernama Nama mendefinisikan cakupan fakta tentang entitas yang disebut PERSON. Gabriel, RJ, Will dan Vanessa adalah contoh arti Nama yang spesifik untuk contoh PERSON yang spesifik. Nilai spesifik untuk setiap atribut entitas mewakili satu contoh.

Model atribut yang benar memiliki ciri-ciri sebagai berikut:

• Nilai atribut menjadi kepentingan korporasi.
• Hanya ada satu contoh atribut dalam model logis.
• Atribut memiliki tipe data Boolean dan cakupan.
• Nilai atribut didefinisikan sebagai wajib atau opsional.
• Atribut mempunyai nama dan deskripsi.
• Hanya satu nilai yang dapat digunakan untuk setiap instance entitas.

Pengecer Es Krim Betty Wilson ingin memesan lebih banyak rasa yang paling populer dan lebih sedikit rasa yang paling tidak populer. Betty Corporation mengadakan acara spesial es krim dan tertarik untuk mengetahui rasa es krim mana yang dipilih pelanggan untuk hidangan penutup pisang dan fudge selama acara spesial tersebut. Untuk memenuhi kebutuhan bisnis, perlu dilakukan pengumpulan data tentang rasa es krim untuk hidangan penutup pisang, fudge, dan kurma.

Pada Gambar 3.1 ada dua entitas BANANA DESSERT dan CREAM Fudge. Setiap entitas berisi atribut yang mewakili komponen setiap hidangan. Perlu diketahui bahwa untuk esens BANANA DESSERT Anda dapat memilih tiga rasa, tiga topping: pisang, krim kocok, dan ceri. Misalnya Fudge, Anda dapat memilih dari dua rasa dan pisang, krim kocok, dan ceri.

Beras. 3.1. Entitas dan atribut yang mewakili (tidak terlalu baik) dua konsep dasar: Fudge dan BANANA DESSERT

Penemuan Atribut

Di mana memulai proses identifikasi atribut? Sebagian besar atribut diidentifikasi selama sesi kerja dan wawancara selama definisi entitas. Analisis kebutuhan informasi dari pakar domain dan pengguna akhir adalah sumber informasi terbaik untuk mengidentifikasi atribut.

Model korporat juga merupakan dasar yang sangat baik untuk menyoroti atribut. Bandingkan entitas dan atribut model perusahaan dengan entitas dan atribut model logis baru. Model perusahaan berisi atribut-atribut yang sebelumnya telah ditentukan untuk masing-masing entitas, khususnya entitas inti. Jika atribut tersebut tidak ada dalam model perusahaan, analisis tambahan akan memungkinkan Anda menentukan apakah itu perlu ditambahkan atau milik entitas lain.

Atur atribut sesuai dengan kebutuhan informasi

Atribut model logis harus benar-benar memenuhi persyaratan informasi. Masing-masing atribut yang ada dalam model harus berfungsi untuk memenuhi satu atau lebih kebutuhan informasi. Model tersebut harus berisi hanya atribut-atribut yang diperlukan untuk mewakili fakta-fakta yang menarik bagi perusahaan dalam bidang subjek yang sedang dipertimbangkan.

Setiap fakta yang menarik dari sudut pandang perusahaan harus direpresentasikan secara akurat dan lengkap dalam model logika. Persyaratan informasi berfungsi sebagai ukuran kebutuhan untuk menyorot suatu atribut. Hal ini berguna untuk mendokumentasikan hubungan antara atribut dan kebutuhan informasi.

Analisis Atribut

Anda harus menganalisis setiap atribut untuk menentukan hubungannya dengan semua atribut lain dalam model. Analisis yang dilakukan dengan benar memastikan bahwa setiap atribut ada dalam model dalam satu salinan dan ditempatkan di entitas sesuai dengan bentuk normal ketiga.

Sangat penting untuk menganalisis setiap kunci utama dan setiap bagian dari kunci utama gabungan untuk memverifikasi bahwa nilainya ada untuk setiap instance entitas. Anda juga harus memastikan bahwa kunci utama mengidentifikasi satu dan hanya satu contoh entitas.

Analisis juga dapat menentukan apakah perusahaan tertarik untuk mengumpulkan dan memelihara informasi tentang atribut itu sendiri. Jika suatu atribut sangat penting sehingga diperlukan atribut tambahan untuk menyimpan datanya, maka Anda harus mempertimbangkan untuk membuat entitas baru.

Anda harus menganalisis setiap atribut model logis untuk memastikan bahwa hanya ada satu contoh dari setiap atribut dalam model dan hanya ada satu nilai atribut untuk setiap contoh entitas. Anda harus menempatkan atribut di entitas yang sesuai menggunakan aturan normalisasi dan menentukan karakteristiknya.

Seharusnya hanya ada satu yang tersisa

Atribut harus ada dalam model logis dalam satu salinan. "Satu fakta di satu tempat" (Date, 1986). Untuk memastikan bahwa setiap fakta diwakili oleh satu atribut, periksa atribut dengan nama atau deskripsi serupa. Selain itu, Anda harus menentukan apakah atribut tersebut merupakan contoh nyata atau nilai konkret yang secara keliru direpresentasikan dalam model dengan atribut yang berbeda.

Atribut dengan nama dan deskripsi serupa mungkin sebenarnya mewakili konsep yang sama dan harus diwakili oleh satu atribut. Dalam bahasa alami, kata yang sama dapat mewakili banyak konsep. Tapi yang lebih buruk lagi adalah itu bahasa Inggris Mungkin ada beberapa kata berbeda untuk mewakili konsep yang sama.

Atribut yang memiliki kata "indikator" atau "bendera" pada namanya kemungkinan besar mewakili nilai tertentu dari cakupan definisi atribut. Nilai tertentu adalah turunan dari suatu atribut. Menggunakan contoh atribut dalam model adalah kesalahan umum. Misalnya, "Indikator Rambut Hitam" adalah "ya" jika ada rambut hitam, dan "tidak" jika tidak ada rambut hitam. Sebaiknya gunakan atribut Warna Rambut dalam model, yang dapat memiliki nilai spesifik "Hitam".

Atribut harus mewakili hanya satu konsep bisnis. Seharusnya tidak memiliki banyak nilai untuk satu instance entitas. Gambar 3.1 menunjukkan dua entitas, BANANA DESSERT dan Fudge. Kedua entitas berisi atribut multinilai bernama "Tanggal Mulai atau Berakhir" penawaran istimewa". Nama atribut menunjukkan bahwa nilainya dapat mewakili tanggal mulai penawaran khusus atau tanggal akhir penawaran khusus, dan kami tidak memiliki cara untuk membedakannya! Atribut ini harus dibagi menjadi dua, masing-masing yang akan mewakili satu fakta.

Jika kita mengizinkan suatu atribut memiliki beberapa nilai, hal ini dapat mengakibatkan atribut "tersembunyi" yang berkaitan erat. Contoh sebelumnya cukup jelas. Tidak semua atribut multinilai dapat dikonversi dengan mudah. Mungkin Anda terkejut bahwa dalam atribut yang berisi sepotong teks, seperti komentar atau catatan, terdapat banyak nilai atribut penting yang tersembunyi di antara teks tersebut.

Normalisasi: menempatkan atribut ke dalam entitas yang sesuai

Atribut menentukan jumlah entitas yang akan hadir dalam model logis yang direduksi menjadi bentuk normal ketiga. Proses normalisasi terdiri dari analisis ketergantungan atribut satu sama lain dan ketergantungan atribut pada kunci utama.

Normalisasi yang dilakukan dengan benar memastikan bahwa model dapat diskalakan dan diperluas dengan menempatkan atribut ke dalam entitas yang sesuai.

Mengurangi model logis ke bentuk normal ketiga sering kali menyebabkan munculnya entitas baru.

Manfaat lain dari normalisasi adalah:

• Hilangkan atau minimalkan redundansi. Data yang berlebihan mungkin ada dalam atribut yang mewakili konsep yang sama tetapi diberi nama berbeda, atau dalam kelompok duplikat. Menyajikan setiap fakta satu kali di satu tempat meminimalkan redundansi.
• Hilangkan atau minimalkan anomali penyisipan, penghapusan, atau pembaruan. Struktur data yang tidak dinormalisasi memungkinkan fakta yang sama muncul di banyak tempat dengan ketergantungan yang tidak lengkap atau sebagian pada kunci utama. Anomali penyisipan, penghapusan, atau pembaruan melibatkan inkonsistensi data yang, dalam kondisi ini, dapat menyebabkan kejutan atau ketidakakuratan dalam akses data.
• Hilangkan atau minimalkan penggunaan nilai null untuk atribut. Grup atribut berulang sering kali berisi nilai nol untuk banyak contoh karena mewakili fakta di mana beberapa entitas mungkin memiliki banyak nilai sementara yang lain tidak. Memiliki entitas yang berisi instance dengan nilai kosong menghasilkan struktur data yang berpopulasi sedikit (jarang).

Ketika suatu model direduksi menjadi bentuk normal ketiga, setiap atribut menjadi milik entitas yang bersesuaian. Ketika suatu model direduksi menjadi bentuk normal ketiga, atribut dan entitas baru sering kali ditemukan.

Ketergantungan fungsional

Ketergantungan fungsional digunakan untuk menggambarkan hubungan antar atribut dalam suatu model. Setiap atribut entitas harus bergantung secara fungsional pada kunci utama entitas (dan tidak bergantung secara fungsional pada atribut model lainnya). Jika hal ini tidak terjadi, atribut harus dipindahkan ke entitas baru di mana ketentuan ini akan dipatuhi.

Untuk menentukan hubungan fungsional antar atribut, pertama-tama kelompokkan atribut tersebut ke dalam kumpulan dengan tema yang sama. Analisislah topik-topik tersebut dengan cermat berdasarkan kemiripannya. Periksa atribut dalam tema untuk menentukan apakah ada ketergantungan fungsional dari atribut dalam tema. Jika suatu atribut, atau kelompok atribut, tidak bergantung pada kunci utama suatu entitas, atribut tersebut harus dipindahkan ke entitas lain.

Atribut yang termasuk dalam topik yang sama mungkin berlebihan. Atribut redundan dapat dikelompokkan menjadi satu entitas atau dapat menggunakan abstraksi tingkat tinggi yang umum sebagai entitas karakteristik dari entitas induk. Setidaknya ada dua tema umum pada Gambar 3.1: dan Atas. Atribut-atribut ini merupakan kandidat yang baik untuk ditransfer ke entitas lain. Mari kita pertimbangkan dari aspek ketergantungan fungsional. Nilai atribut Bahan tambahan penyedap rasa untuk es krim tidak bergantung pada nilai kunci utama - Bahan Makanan Penutup Pisang. Hal yang sama berlaku untuk kuncinya kue krim.

Gambar 3.2 mengilustrasikan solusi di mana Penyedap rasa es krim Dan Atas dialokasikan dalam suatu entitas, yang nilainya bergantung pada kunci utama. Solusi ini menghilangkan beberapa masalah nyata yang terkait dengan redundansi.

Bentuk normal pertama

Mentransmisikan ke bentuk normal pertama berarti memindahkan semua atribut duplikat ke entitas lain. Atribut duplikat cukup mudah dikenali, karena sering kali hanya diberi nomor sebagai 1 teratas Dan 2 teratas atau Rasa 1 Dan Rasa 2.

Buat entitas dependen yang akan berisi sekumpulan atribut untuk mewakili atribut duplikat. Kunci utama entitas dependen akan menjadi kunci utama gabungan yang mencakup kunci utama entitas induk dan setidaknya satu atribut tambahan untuk memastikan keunikan.

Kelompok yang berulang telah dipindahkan pada Gambar 3.2 Penyedap rasa es krim Dan Atas menjadi entitas yang bergantung. Perhatikan pembuatan entitas TASTE.

Beras. 3.2. Menghilangkan atribut yang berlebihan

Bentuk normal kedua

Mengurangi ke bentuk normal kedua berarti menghilangkan atribut yang berlebihan. Atribut yang berlebihan dapat berupa:

• Atribut berbeda mewakili konsep yang sama
• Atribut entitas berbeda yang terkait dengan topik yang sama
• Atribut yang tidak mempunyai nilai untuk setiap instance dari suatu entitas

Atribut yang mewakili konsep yang sama harus diubah menjadi atribut tunggal. Atribut redundan mungkin tidak memiliki nilai untuk setiap instance suatu entitas, sehingga keberadaannya tidak akan bergantung pada nilai kunci utama. Pindahkan atribut ini ke dalam entitas, di mana atribut tersebut akan memiliki nilai untuk setiap instance.

Buat entitas atribut untuk mewakili atribut redundan. Entitas baru memiliki kunci utama yang mengidentifikasi satu contoh. Kunci utama ini akan menjadi kunci asing di entitas aslinya. Kunci asing akan dibahas nanti.

Gambar 3.2 menunjukkan solusi untuk beberapa atribut redundan dari entitas BANANA DESSERT dan Fudge. Mari pertimbangkan redundansi dari sudut pandang dua entitas inti. Kedua entitas memiliki tema yang sama: penyedap dan topping es krim. Ini adalah tanda bahwa entitas inti dapat digabungkan menjadi lebih banyak level tinggi abstraksi.

Gambar 3.3 menunjukkan pembuatan supertipe bernama MIXTURE, yang implementasinya adalah BANANA DESSERT dan Fudge. Saya menambahkan atribut klasifikasi "Jenis Campuran" ke entitas induk MIXTURE untuk mengidentifikasi apakah MIXTURE merupakan turunan dari entitas BANANA DESSERT atau Fudge. Sebuah instance dari entitas MIXTURE dapat berupa sebuah instance dari entitas BANANA DESSERT atau Fudge, namun tidak keduanya.

Beras. 3.3. Redundansi entitas inti dihilangkan dengan memindahkan atribut umum ke entitas CAMPURAN yang lebih umum. Perhatikan bahwa kunci utama "Blend ID" ditempatkan di entitas BANANA DESSERT dan Fudge.

Bentuk normal ketiga

Mentransmisikan ke bentuk normal ketiga berarti menghilangkan atribut apa pun yang bergantung pada nilai atribut selain kunci utama. Hal ini terkadang disebut ketergantungan transitif.

Buat entitas baru dan pindahkan atribut ke dalamnya yang tidak bergantung pada kunci utama di entitas asli. Tentukan kunci utama untuk entitas baru sehingga menjamin keunikan.

Pada Gambar 3.3 atribut Krim kocok Dan ceri tidak bergantung pada kunci utama entitas BANANA DESSERT dan FANDISH. Faktanya, Anda harus memutuskan apakah atributnya Krim kocok Dan ceri contoh entitas TOP.

Pada Gambar 3.4, perhatikan atribut Blend Date tambahan, yang memberikan informasi tentang kapan instance entitas MIX dibuat. Saya menghapus atribut Tanggal Mulai dan Tanggal Berakhir dari entitas BANANA DESSERT dan FANDISH. Entitas PENAWARAN KHUSUS yang baru sekarang berisi dua tanggal ini dan atribut Rasa Es Krim untuk menunjukkan es krim mana yang memenuhi syarat untuk penawaran tersebut.

Beras. 3.4. Setiap atribut bergantung pada kunci utama, kunci utama penuh, dan hanya kuncinya .

Mendefinisikan Karakteristik Atribut

Atribut dibagi menjadi dua kelompok. Atribut bisa berupa kunci atau bukan. Gambar 3.5 menunjukkan atribut kunci untuk model logis entitas MIXTURE. Perhatikan bahwa, pada dasarnya, atribut kunci utama terletak di atas garis dalam entitas, dan atribut lainnya berada di bawah garis.

Beras. 3.5. Semua atribut yang bukan bagian dari kunci utama terletak di bawah pembatas dalam entitas. Ini bisa berupa kunci kandidat, kunci asing dan alternatif, serta atribut sederhana.

Atribut Utama

Atribut kunci adalah atribut yang nilainya menentukan nilai atribut lainnya. Nilai atribut kunci tidak bergantung pada nilai atribut lainnya. Sebuah kunci dapat terdiri dari satu atribut atau terdiri dari beberapa atribut. Atribut-atribut ini dapat berupa kunci primer, kunci primer komposit, kunci kandidat, kunci asing, atau kunci alternatif.

Atribut kunci utama

Apakah kunci utama adalah atribut tunggal atau grup, nilainya menentukan nilai semua atribut lainnya.

Kunci primer yang baik akan memiliki ciri-ciri sebagai berikut:

• Nilainya dijamin unik untuk setiap instance
• Maknanya tidak memiliki makna tersembunyi
• Cakupan nilai akan tetap konstan seiring berjalannya waktu
• Nilai ada untuk setiap instance entitas

Kunci primer buatan

Kunci primer buatan adalah atribut yang dibuat dengan tujuan mengidentifikasi kejadian spesifik suatu entitas. Dalam beberapa kasus, tidak ada atribut atau grup yang secara unik mengidentifikasi suatu instance entitas. Dalam kasus lain, kunci primer komposit terlalu besar dan sulit dipelihara. Kunci primer buatan terkadang disebut kunci semu atau kunci yang dihasilkan sistem. Ia juga dikenal sebagai pengidentifikasi unik buatan, yang menunjukkan tujuannya.

Kunci primer buatan sering kali dibentuk hanya dengan memberi nomor pada setiap instance entitas secara berurutan. Manfaat tambahan dari kunci buatan tersebut adalah tidak perlu lagi memedulikan arti dari instance entitas yang terkait dengannya, selain menjamin keunikan. Faktanya, kunci utama buatan yang dibuat dengan cara ini dijamin memiliki ciri-ciri kunci utama yang baik.

Perhatikan bahwa sebagian besar kunci utama pada Gambar 3.5 adalah kunci buatan. Pada umumnya, kunci utama hanyalah sebuah nomor unik untuk setiap contoh.

Kandidat kunci

Kunci kandidat adalah atribut atau kelompok atribut yang mengidentifikasi contoh spesifik suatu entitas. Kandidat kunci mewakili mekanisme untuk menentukan kunci utama potensial untuk mengidentifikasi contoh spesifik suatu entitas.

Kandidat kunci yang tidak dipilih sebagai kunci utama disebut juga kunci alternatif. Kunci alternatif adalah atribut atau kelompok atribut yang dapat digunakan untuk pengindeksan.

Kunci asing

Kunci asing adalah atribut atau sekelompok atribut yang membentuk kunci utama entitas lain. Kunci asing mungkin atau mungkin bukan merupakan atribut kunci dalam entitas terkait. Perhatikan istilah entitas terkait. Kunci asing mewakili hubungan antar entitas, yang akan dibahas lebih detail di artikel berikutnya.

Memigrasikan Atribut Kunci Utama

Atribut kunci eksternal adalah atribut kunci utama dari entitas lain yang telah bermigrasi ke entitas ini melalui suatu relasi. Kunci asing dapat berupa pengidentifikasi atau non-identifikasi. Mengidentifikasi kunci asing menjadi bagian dari kunci utama di entitas tempat mereka bermigrasi. Kunci asing yang tidak dapat diidentifikasi menjadi atribut non-kunci.

Atribut bukan kunci

Atribut bukan kunci adalah atribut yang nilainya bergantung pada nilai kunci utama atau kunci utama gabungan. Atribut non-kunci ini harus bergantung pada nilai kunci, kunci lengkap, dan tidak lain selain kunci.

Dalam bukunya Pengembangan Sistem Strategis K. Finklestein mendefinisikan beberapa jenis atribut non-kunci:

• Atribut selektif adalah atribut yang digunakan untuk mengidentifikasi satu instance dari suatu entitas ketika kuncinya tidak unik. Juga disebut kunci sekunder.
• Atribut grup adalah atribut yang menyatukan sekelompok atribut yang lebih detail.
• Atribut grup berulang adalah atribut yang mewakili beberapa kemunculan atribut yang sama dalam suatu entitas.
• Atribut turunan adalah atribut yang nilainya ditentukan dari nilai atribut lainnya.
• Atribut data master adalah atribut yang tidak bersifat selektif, berkelompok, mengelompok berulang, atau atribut turunan.

Atribut grup selektif, grup, dan grup berulang tidak boleh ada dalam model logika yang direduksi ke bentuk normal ketiga. Atribut selektif harus menjadi bagian dari kunci utama jika diperlukan untuk mengidentifikasi satu instance dari suatu entitas. Atribut grup memiliki banyak nilai. Menurut pendapat saya, atribut grup paling baik direpresentasikan dalam model sebagai kode atau entitas klasifikasi. Seperti disebutkan di atas, grup yang berulang harus ditempatkan ke dalam entitas bawahan.

Pada bentuk normal ketiga, atribut bukan kunci harus berupa atribut sederhana (primer) atau turunan.

Atribut sederhana

Atribut sederhana adalah atribut yang, sebagai hasil dekomposisi, telah dibawa ke tingkat detail tertinggi dan, dengan demikian, nilainya sepenuhnya bergantung pada kunci utama dan ditentukan untuk setiap instance entitas. Ini bukan kriteria seleksi dan tidak dapat digunakan untuk mengelompokkan entitas. Mereka mewakili fakta-fakta atom sederhana yang diminati korporasi.

Atribut turunan

Atribut turunan adalah atribut yang nilainya disimpulkan atau dihitung dari nilai satu atau lebih atribut lainnya. Masalah diterimanya kehadiran atribut turunan dalam model logis sedang dibahas secara aktif. Beberapa ahli percaya bahwa karena nilai atribut turunan bergantung pada nilai atribut asli, atribut turunan tidak boleh direpresentasikan dalam model logika.

Model logika dirancang untuk memberikan representasi kebutuhan informasi yang lengkap dan akurat. Anda dapat memutuskan untuk membuat atribut turunan pada tingkat model fisik agar sesuai dengan kebutuhan penggunaan Anda.

Meskipun argumen untuk mengecualikan atribut turunan dapat dimengerti, model logikanya tetap dapat dimengerti tempat terbaik untuk memasukkan nama dan deskripsi semua atribut. Oleh karena itu, lebih baik untuk memasukkan atribut turunan ke dalam model logis. Namun, pemodel harus menghindari penggunaan atribut turunan sebagai kunci utama atau sebagai bagian dari kunci utama gabungan. Pastikan juga untuk menyertakan aturan inferensi dalam deskripsi atribut turunan.

Menemukan ruang lingkup suatu atribut

Cakupan definisi atribut menentukan daftar nilai yang diperbolehkan yang dapat diambil oleh atribut pada instance entitas tertentu. Cakupan definisi mencakup setidaknya cakupan tipe data generik dan dapat mencakup cakupan yang ditentukan pengguna. Dalam model logis yang telah selesai, Anda harus menemukan domain definisi untuk setiap atribut.

Kita dapat mengatakan bahwa cakupan suatu atribut harus mengandung setidaknya dua nilai. Atribut yang selalu diperbolehkan hanya memiliki satu nilai mungkin tidak dipetakan dengan benar dalam model. Pada Gambar 3.5 ada dua atribut seperti itu - Banana dan Fudge.

Intinya BANANA DESSERT mengandung atribut Banana. Aturan bisnis menyatakan bahwa setiap instance dari entitas BANANA DESSERT berisi pisang. Oleh karena itu, atribut Banana hanya dapat memiliki satu nilai dan atribut tersebut mungkin tidak diperlukan. Sebaliknya, deskripsi entitas BANANA DESSERT harus menunjukkan bahwa pisang disertakan dalam setiap contohnya. Hal yang sama berlaku untuk atribut Fudge di esensi Fudge.

Tabel 3.1 menunjukkan ruang lingkup definisi tipe data logis dari entitas PENAWARAN KHUSUS dari model logika CAMPURAN.

TABEL 3.1. Contoh tipe data logis

Ruang Lingkup Definisi Tipe Data Sederhana dan Diperluas

Cakupan tipe data menentukan bagaimana nilai atribut direpresentasikan. Dalam model logis yang lengkap, cakupan definisi tipe data diperlukan untuk setiap atribut. Daftar berikut menyediakan beberapa contoh tipe data ERwin Boolean:

• Tanggalwaktu - tanggal/waktu
• Nomor - nomor
• Tali – tali

Banyak platform database baru mendukung tipe data yang lebih canggih. Namun, penting untuk diingat bahwa tipe data kompleks ini, dengan beberapa pengecualian, spesifik untuk platform. Bagaimanapun, jika pengguna memerlukan suatu atribut, atribut tersebut harus disertakan dalam model, apa pun tipe datanya. Beberapa tipe data tambahan yang umum digunakan diberikan di bawah ini:

• Gambar – gambar
• Suara – suara
• Video - video

Cakupan yang disediakan pengguna

Cakupan yang disediakan pengguna adalah cakupan khusus yang menentukan kumpulan nilai yang diizinkan untuk suatu atribut. Cakupan ini sering kali spesifik untuk organisasi dan harus didefinisikan serta digunakan secara konsisten di seluruh perusahaan. Misalnya, atribut dengan cakupan tipe data Number mungkin juga memiliki cakupan yang disediakan pengguna yang membatasi kemungkinan nilai antara 1 dan 100. Prinsip integritas memungkinkan perusahaan melakukan perubahan pada satu entitas untuk memperluas cakupan. untuk setiap atribut yang digunakannya.

Menentukan apakah suatu atribut bersifat opsional

Nilai atribut mungkin diperlukan atau tidak. Jika suatu nilai diperlukan, atau diperlukan, nilai tersebut harus ada pada saat instance dibuat. Jika nilainya opsional, Anda dapat membuat instance tanpa nilainya.

Di dalam buku Rekayasa Informasi: Pengembangan Sistem Strategis K. Finklestein mendefinisikan properti wajib suatu atribut melalui serangkaian “aturan pengeditan”:

• Ditambahkan segera, tidak dapat diubah nanti.
• Segera ditambahkan, diubah nanti.
• Ditambahkan nanti, diubah nanti.
• Ditambahkan nanti, tidak dapat diubah nanti.

Perhatikan baik-baik atribut opsional. Jika suatu atribut atau kumpulan atribut hanya memiliki nilai untuk instans spesifik suatu entitas, pertimbangkan untuk memindahkannya ke entitas yang nilainya akan ada untuk setiap instans tersebut.

Tabel 3.2 menunjukkan properti wajib untuk atribut entitas PENAWARAN KHUSUS. Perhatikan bahwa saat Anda membuat instance entitas PENAWARAN KHUSUS, nilai diperlukan untuk semua atribut kecuali atribut Tanggal Akhir Penawaran Khusus.

Tabel 3.2. Contoh atribut wajib

Tabel 3.2 menyajikan aturan bisnis yang menyatakan bahwa suatu instance dari entitas PENAWARAN KHUSUS memerlukan informasi berikut:

• ID Entitas (ID Penawaran Khusus)
• ID Rasa Penawaran Spesial (ID Es Krim dan ID Rasa)
• Tanggal mulai penawaran khusus (Mulai penawaran khusus)

Tanggal akhir untuk setiap instance entitas PENAWARAN KHUSUS bersifat opsional. Aturan bisnis menyatakan bahwa PENAWARAN KHUSUS harus memiliki awal, namun belum tentu berakhir.

Atribut yang nilainya wajib diisi tidak boleh mempunyai nilai kosong. Beberapa ahli percaya bahwa suatu nilai harus diperlukan untuk setiap contoh suatu entitas. Tentu saja, dengan asumsi bahwa nilai setiap atribut suatu instance entitas ditemukan atau diketahui sebelum instance tersebut dibuat.

Atribut yang nilainya opsional dapat mempunyai nilai kosong. Beberapa ahli percaya bahwa suatu atribut tidak boleh ada dalam suatu entitas jika nilainya tidak tersedia untuk setiap contohnya. Salah satu alasannya adalah nilai null sulit diinterpretasikan. Apakah nilai kosong berarti nilai tersebut tidak diketahui oleh instance, atau nilai tersebut tidak diambil?

CATATAN Di antara para pemodel, perdebatan tentang kelebihan dan kekurangan nilai wajib dan nilai opsional masih berlangsung. Beberapa pengembang percaya bahwa suatu atribut tidak boleh memiliki nilai kosong, dan berpendapat bahwa cakupan harus berisi nilai seperti tidak diketahui dan belum diperoleh. Yang lain percaya bahwa nilai-nilai diperlukan dan bahwa penggunaan ruang lingkup juga memerlukan penggunaan nilai-nilai default, sehingga menghasilkan nilai-nilai yang tidak dapat diandalkan dan dipertanyakan. Sebaiknya gunakan nilai null dan serahkan tanggung jawab penanganan nilai null kepada program aplikasi atau alat kueri. Ini adalah solusi yang paling tepat dan fleksibel karena memungkinkan nilai null diinterpretasikan secara berbeda agar sesuai dengan kebutuhan bisnis yang berbeda.

Penamaan Atribut

Setiap atribut harus mempunyai nama yang jelas, tepat, dan konsisten. Nama atribut tidak boleh bertentangan dengan deskripsinya. Nama atribut harus menunjukkan nilai yang dikumpulkan untuk contoh atribut. Nama atribut harus dapat dimengerti dan diterima secara umum dalam perusahaan.

Kemungkinan besar Anda memiliki seperangkat konvensi penamaan atribut yang Anda kembangkan di perusahaan Anda atau saat membangun model data perusahaan yang Anda gunakan sebagai panduan. Penggunaan konvensi penamaan atribut memastikan bahwa nama dibuat secara konsisten di seluruh perusahaan, terlepas dari siapa yang membuat nama tersebut.

Konvensi penamaan atribut itu penting, baik Anda bekerja di organisasi kecil atau besar. Namun, dalam organisasi besar dengan banyak tim pengembangan dan sejumlah besar pengguna, konvensi penamaan sangat membantu dalam mengkomunikasikan dan memahami data dasar. Idealnya, Anda akan mengembangkan dan memelihara konvensi penamaan atribut secara terpusat dan kemudian mendokumentasikan dan mempublikasikannya ke seluruh perusahaan.

Berikut adalah beberapa pedoman untuk membuat rangkaian awal konvensi penamaan atribut, untuk berjaga-jaga jika organisasi Anda belum mengembangkan rangkaian konvensi penamaan atribut tersebut:

• Nama atribut harus cukup deskriptif. Pertimbangkan untuk menggunakan frasa kata benda dalam bentuk objek/pengubah/kelas.
• Jika memungkinkan, nama atribut harus menyertakan nama entitas. Gunakan "Nama Orang" bukan hanya "Nama".
• Nama atribut harus menunjukkan nilai contoh atribut tertentu. Menggunakan nama yang sama untuk atribut yang berisi data berbeda, atau nama berbeda untuk atribut yang berisi data yang sama, tidak akan membingungkan pengembang dan pengguna akhir.
• Nama atribut harus menggunakan bahasa bisnis, bukan bahasa teknis.
• Nama atribut tidak boleh mengandung karakter khusus (seperti!, @, #, $, %, l, &, *, dll.) atau menunjukkan kepemilikan (Nama milik seseorang).
• Nama atribut tidak boleh mengandung akronim atau singkatan kecuali merupakan bagian dari konvensi penamaan yang diterima.

Pemodel sebaiknya menggunakan konvensi penamaan yang baik jika ada, atau mengembangkannya jika konvensi tersebut tidak ada.

Nama atribut berupa Object/Modifier/Class

Bentuk objek/pengubah/kelas adalah konvensi penamaan atribut yang banyak digunakan di industri. Konvensi ini mendorong penggunaan nama atribut tiga bagian. Bagian objek kadang-kadang disebut subjek atau kata utama. Objek biasanya merupakan nama entitas.

Pengubah dapat berupa satu istilah atau sekelompok istilah. Meskipun tidak ada daftar pengubah standar, pemodel sebaiknya membuat pengubah yang singkat dan bermakna. Menggunakan pengubah memungkinkan Anda membuat nama atribut yang bermakna secara visual. Jika nama menjadi terlalu berat bagi pengguna atau untuk digunakan secara luas, seperti yang diwajibkan dalam perusahaan, Anda mungkin ingin berkompromi dengan menghilangkan nama atribut tiga suku kata.

Bagian dasar dari nama atribut adalah kelas, yang menentukan jenis informasi yang diwakili oleh atribut tersebut. Beberapa kelas yang umum digunakan:

• Pengidentifikasi
• Nomor
• Besarnya
• Kuantitas
• Frekuensi

Contoh nama atribut

Dalam suatu perusahaan, selalu lebih baik menggunakan nama atribut yang konsisten. Tabel 3.3 memberikan contoh nama atribut yang baik dan buruk. Perhatikan bahwa kata-kata dalam nama atribut dipisahkan dengan spasi, diawali dengan huruf kapital, dan sisanya menggunakan karakter huruf kecil.

TABEL 3.3. Atribut nama beserta penjelasannya

Nama baik	Nama yang buruk	Penjelasan
Nama Depan Orang (nama orang)	Nama (Nama)	Nama adalah nama kelas dan memerlukan penunjukan objek Person dan pengubah Pertama.
Kuantitas Penjualan Es Krim (Volume penjualan es krim)	Kuantitas Penjualan (Volume penjualan)	Kuantitas adalah nama kelas dan harus berada di tempat terakhir (dalam versi bahasa Inggris nama atribut). "The" dan "of" tidak menambahkan arti tambahan apa pun.
Jumlah Biaya Barang (nilai posisi)	Biaya Barang (Nilai posisi)	"dari" tidak menambahkan arti tambahan apa pun. Nama kelas "Jumlah" memberi tahu pengguna apa yang harus ada dalam atribut.
Pengenal Produk (ID Produk)	Pengenal Produk (ID Produk)	"Pengidentifikasi" adalah jamak. Nama atribut harus berupa kata benda tunggal.
Kode Lokasi Tempat Penjualan	Kode POS (Kode POS)	"POS" adalah singkatan. Nama kelas "Kode" yang digunakan memerlukan pengubah.
Tanggal Lahir Orang (Tanggal lahir seseorang)	Hari ulang tahun (Hari ulang tahun)	Ulang tahun tidak berisi nama kelas Tanggal. Menyertakan pengubah dan nama objek membuat arti nama atribut menjadi lebih jelas.

Deskripsi atribut

Deskripsi atribut harus berupa penjelasan singkat tentang arti atribut tersebut, bukan bagaimana atribut tersebut digunakan. Deskripsi suatu atribut tidak boleh bertentangan dengan namanya dan tidak boleh hanya sekedar pengulangan nama. Gunakan nama kelas dan objek dalam pernyataan untuk mendeskripsikan data secara akurat. Jika atribut disimpulkan atau dihitung, sertakan aturan inferensi atau rumus perhitungan. Aturan berikut berlaku untuk deskripsi atribut:

• Deskripsi atribut harus jelas, lengkap, dan tidak ambigu.
• Deskripsi atribut harus sesuai dengan namanya.
• Deskripsi suatu atribut tidak boleh bergantung pada deskripsi atribut lainnya.
• Deskripsi atribut harus ditulis dalam bahasa bisnis, bukan bahasa teknis.
• Nama suatu atribut harus mencerminkan maknanya, bukan cara penggunaannya.
• Deskripsi atribut harus memperjelas semua singkatan dan akronim yang digunakan dalam namanya.

Pemodel didorong untuk memberikan deskripsi yang baik untuk setiap atribut. Deskripsi atribut yang baik membuat model mudah digunakan oleh semua orang. Mereka yang menggunakan model yang dibuat oleh pengembang yang baik merasakan kepuasan karena memiliki persyaratan informasi yang terdefinisi dengan baik dalam model tersebut. Bandingkan contoh pada Tabel 3.4.

Tabel 3.4. Atribut nama dan deskripsi beserta penjelasannya

Nama atribut	Deskripsi yang bagus	Deskripsi buruk	Penjelasan
Nama Depan Orang (Nama orang)	Nama seseorang yang memungkinkan suatu perusahaan berkomunikasi dengan orang tersebut menggunakan istilah ramah.	Bidang dengan panjang 40 karakter.	Bahasa bisnis tidak digunakan. Istilah teknis yang digunakan.
Kuantitas Penjualan Es Krim (Volume penjualan es krim)	Jumlah es krim merek tertentu yang terjual pada acara penjualan tertentu.	Volume penjualan.	Tidak menambahkan arti baru apa pun, tetapi hanya mengubah nama atribut menjadi istilah yang tidak jelas.
Jumlah Biaya Barang (nilai posisi)	Nilai suatu posisi tertentu dalam jangka waktu tertentu. Merupakan total biaya penjualan dan pengiriman.	Angka desimal enam digit dengan dua tempat desimal.	Deskripsi terlalu teknis. Hampir tidak berarti apa-apa bagi pengguna item data.
Pengenal Produk (ID Produk)	Pengidentifikasi numerik unik buatan untuk produk tertentu.	ID Produk.	Pengungkapan ulang sederhana dari nama atribut.
Kode Lokasi Tempat Penjualan (Kode lokasi tempat penjualan)	Identifikasi kode unik posisi geografis tempat penjualan.		Akronim yang digunakan mungkin tidak jelas bagi pengguna. Selain itu, pengubah penting dihilangkan dari deskripsi.
Tanggal Lahir Orang (Tanggal lahir seseorang)	Tanggal lahir orang tersebut.	Ulang tahun seseorang.	Deskripsi tersebut menghilangkan nama kelas "tanggal".

Kesalahan umum saat bekerja dengan atribut

Bagian ini, yang membahas kesalahan umum dalam pemodelan atribut, tidak dimaksudkan untuk menjelaskan secara komprehensif. Tujuannya adalah untuk menunjukkan kesalahan paling umum yang dilakukan pengembang model.

Terkadang, ketika memodelkan sesuatu dengan cara tertentu, pemodel membuat pilihan secara sadar berdasarkan prinsip yang benar. Sangat penting untuk memahami seluruh rantai sebab-akibat dari keputusan yang diambil dan hasil yang dapat dihasilkannya.

Pemodelan dalam hal nilai

Apa yang dimaksud dengan pemodelan dari segi nilai? Selama sesi kerja, pengguna mungkin memberi tahu Anda bahwa mereka menginginkan sekumpulan atribut yang menunjukkan kategori usia dari instance entitas PERSON. Setidaknya ada tiga masalah dalam skenario ini:

1. Metode penentuan kategori umur dalam suatu perusahaan dapat berubah seiring berjalannya waktu.
2. Usia seseorang pasti berubah seiring berjalannya waktu.
3. Semua atribut akan mewakili nilai atribut Usia seseorang. Tentu saja, Usia seseorang akan berubah seiring waktu, jadi solusi terbaik adalah dengan menggunakan atribut sederhana dalam model Tanggal lahir orang tersebut.

Pemodelan Atribut Multinilai

Atribut yang memiliki banyak arti bagi suatu konsep bersifat multinilai. Periksa deskripsi atribut yang menunjukkan beberapa nilai untuk konsep yang sama.

Terkadang pakar dari bidang studi yang berbeda di suatu perusahaan menggunakan nama atribut yang ejaan dan pengucapannya sama, namun memiliki arti berbeda untuk pakar yang berbeda. Salah satu cara untuk memastikan bahwa atribut dengan nama yang sama mendeskripsikan objek yang sama adalah dengan memeriksa deskripsinya. Pastikan nilai atribut menggambarkan satu konsep.

Misalnya, Anda dapat membuat kode buatan dengan menghubungkan satu atau beberapa kode untuk menghubungkan data yang sebelumnya tidak terkait. Fragmen teks dapat menyembunyikan banyak atribut dan makna yang berharga.

Kegagalan untuk menyelesaikan atribut multinilai dapat mengakibatkan beberapa aturan bisnis penting tetap tidak terdeteksi dan tidak terdokumentasi.

Memodelkan Atribut Redundan

Atribut dengan nama berbeda tetapi berisi informasi tentang konsep serupa adalah mubazir. Dalam semua bahasa ada banyak kata yang mewakili hal yang sama. Salah satu cara untuk menemukan atribut redundan adalah dengan melihat entitas dengan atribut serupa. Bandingkan deskripsi semua atribut untuk melihat apakah entitas berisi informasi tentang konsep serupa. Atribut yang berlebihan seringkali merupakan akibat dari kecenderungan untuk memodelkan nilai sebagai atribut. Misalnya, entitas MANAGER dan EXECUTOR mungkin berisi atribut Nama Manajer dan Nama Pelaksana. Karena MANAGER dan EXECUTOR adalah peran yang dapat digunakan oleh instance entitas PERSON, Anda dapat memindahkan atribut ini ke sana dan menamainya PERSONNAME.

Menggunakan nama buruk untuk atribut

Nama atribut yang tidak jelas, ambigu, atau tidak tepat menyulitkan pengguna baru dan tim pengembangan untuk menggunakan kembali atau mengembangkan model yang sudah ada.

Jangan gunakan singkatan atau akronim sebagai bagian dari nama atribut. Singkatan dan akronim dapat disalahartikan dan bahkan mungkin memiliki arti yang berbeda dalam bidang studi yang berbeda.

Jangan gunakan nama diri yang menunjukkan arti suatu kejadian tertentu. Nama atribut yang menggunakan nama yang tepat merupakan indikator masalah pemodelan serius yang melibatkan lebih dari sekadar pilihan nama yang buruk. Jangan sertakan lokasi sebagai bagian dari nama atribut. Jika suatu nilai ada untuk satu lokasi, maka nilai tersebut pasti ada untuk lokasi lain. Nama atribut beserta lokasinya merupakan indikasi bahwa Anda memodelkan instance tertentu, bukan kelas.

Menggunakan deskripsi yang buruk untuk atribut

Jangan gunakan deskripsi atribut yang diambil hanya dari kamus. Deskripsi kamus tidak akan menyertakan informasi relevan dengan bisnis yang menjadikan atribut tersebut penting bagi perusahaan. Jangan hanya mengubah nama atributnya. Jangan gunakan nama atribut dalam deskripsinya.

Deskripsi atribut yang tidak jelas dan tidak jelas, atau lebih buruk lagi, ketidakhadirannya, menyulitkan penggunaan kembali atau pengembangan model yang sudah ada. Pengguna tidak akan dapat memverifikasi bahwa model tersebut berisi semua persyaratan informasi. Hal ini juga meningkatkan kemungkinan penggunaan nilai tertentu dan atribut multinilai dalam model, bukan atribut.

Konsep yang tampak jelas bagi semua orang yang terlibat dalam sesi kerja mungkin tidak begitu jelas seiring berjalannya waktu ketika tim pengembangan baru ditugaskan untuk mengembangkan model yang sudah ada.

Kesimpulan

Entitas mewakili fakta yang membuat perusahaan tertarik untuk mengumpulkan dan memelihara informasi. Mereka merupakan inti dari model dan terutama terungkap selama sesi kerja. Representasi atribut yang lengkap dan akurat dalam model memerlukan analisis yang cermat untuk memastikan bahwa atribut tersebut secara akurat sesuai dengan kebutuhan informasi. Atribut harus ada dalam model dalam satu salinan dan harus mewakili satu konsep bisnis. Aturan normalisasi harus digunakan untuk menempatkan atribut ke dalam entitas yang sesuai.

Atribut dapat berupa key atau non-key. Kunci dapat berupa atribut tunggal atau sekelompok atribut. Kunci utama dipilih dari kunci kandidat yang secara unik mengidentifikasi suatu instance entitas. Atribut kunci primer bermigrasi dari entitas asli menjadi kunci asing entitas sekunder. Nilai atribut non-kunci secara fungsional harus bergantung pada nilai kunci utama.

Ruang lingkup menentukan kumpulan nilai atribut. Cakupan Boolean dapat berupa tipe data sederhana seperti angka atau string. Mereka juga bisa berupa tipe data kompleks yang ditentukan pengguna yang disesuaikan untuk memenuhi kebutuhan spesifik perusahaan. DBMS baru mendukung tipe data tingkat lanjut seperti gambar dan suara.

Nilai atribut mungkin wajib atau opsional. Jika nilai diperlukan, atribut tidak boleh memiliki nilai kosong. Atribut harus memiliki nama dan deskripsi. Dalam memberi nama atribut, disarankan menggunakan standar penamaan berupa objek/pengubah/kelas. Setiap atribut harus menyertakan deskripsi yang baik yang menggunakan terminologi bisnis untuk mendefinisikan atribut tersebut, bukan bagaimana atribut tersebut akan digunakan.