Changes and Historical Modeling
Tujuan
Pelajaran ini mencakup tujuan berikut:
• Mengidentifikasi kebutuhan untuk melacak data yang berubah
dari waktu ke waktu
• Buat model ERD yang menggabungkan elemen "data
lembur"
• Mengidentifikasi UID entitas yang menyimpan data historis;
menjelaskan dan membenarkan pilihan UID
Tujuan
• Berapa tinggi Anda pada usia 5 tahun? Berapa tinggi Anda
pada usia 10 tahun?
Berapa tinggi kamu sekarang
• Jika orang tua Anda menuliskan ini ketika Anda masih muda,
mereka
sedang melacak data historis.
• Sebagian besar bisnis perlu melacak beberapa data
historis.
• Ini membantu mereka menemukan tren dan pola yang menjadi
dasarnya
inovasi bisnis atau perbaikan proses.
• Misalnya, riwayat rental sebuah film berguna untuk sebuah
video
toko. Ini memberi tahu manajer film mana yang populer dan
mana
harus dipindahkan ke rak belakang
Model Data Seiring Waktu
• Kapan data perlu dimodelkan dari waktu ke waktu?
• Tanyakan kepada klien Anda:
- Apakah jejak audit diperlukan?
- Dapatkah nilai atribut berubah seiring waktu?
- Bisakah hubungan berubah seiring waktu?
- Apakah Anda perlu membuat laporan tentang data lama?
- Apakah Anda perlu menyimpan data versi sebelumnya? Jika
demikian, untuk
berapa lama?
Contoh Data Seiring Waktu
• Organisasi perlu menyimpan data tentang
gaji karyawan.
• Semua karyawan dibayar mingguan.
• Awalnya, entitas KARYAWAN berikut
dimodelkan.
• Persyaratan tambahan sekarang menentukan itu
organisasi perlu menjaga a
catatan sejarah tentang bagaimana dan kapan
gaji karyawan telah berubah selama
pekerjaan mereka.
Model Perubahan Gaji
• Untuk mencontohkan perubahan gaji dari waktu ke waktu,
tambahkan SEJARAH GAJI
kesatuan.
• UID dari entitas SEJARAH GAJI adalah yang terkait
ID KARYAWAN dan tanggal mulai gaji.
Sewa Model Seiring Waktu
• Sebuah toko perhiasan menyewakan barang-barang (kalung,
gelang, dan sebagainya)
kepada bintang film untuk acara-acara khusus, seperti
penghargaan
upacara atau pemutaran perdana film.
• Mereka ingin melacak riwayat sewa sebuah perhiasan.
• Model ER berikut hanya akan melacak penyewa a
sepotong perhiasan.
• Bagaimana Anda akan merevisi hubungan untuk melacak
sejarah?
Selesaikan M: M
• Hubungan antara
JEWELRY PIECE and MOVIE
STAR harus direvisi menjadi a
G: M, yang kemudian diselesaikan
dengan entitas persimpangan
SEJARAH SEWA.
• Selanjutnya kita perlu menentukan
UID RIWAYAT SEWA
Tentukan UID
• Opsi 1: Dilarang
hubungan.
• Menggambar Barred
hubungan bukan
UID yang cocok di sini, sebagai
ini tidak akan memungkinkan a
MOVIE STAR untuk disewa
PERHIASAN yang sama
PIECE berbeda
tanggal
Tentukan UID
• Opsi 2: Dilarang
hubungan dan Persewaan
Tanggal.
• Menambahkan tanggal sewa ke
UID akan memungkinkan MOVIE
STAR untuk menyewa sama
JEWELRY PIECE on
tanggal yang berbeda, tapi
juga akan mengizinkan
BINTANG FILM yang berbeda
untuk menyewa PERHIASAN yang sama
PIECE di tanggal yang sama!
Tentukan UID
• Opsi 3: Dilarang
hubungan antara
MOVIE STAR dan
SEJARAH SEWA dengan
Tanggal Sewa.
• Model ini tidak akan melakukannya
mengizinkan hal yang sama
MOVIE STAR untuk disewa
lebih dari satu
JEWELRY PIECE pada a
hari tertentu
Tentukan UID
• Opsi 4: Dilarang
hubungan antara
JEWELRY PIECE dan
SEJARAH SEWA dengan
Tanggal Sewa.
• Model ini mengatakan bahwa a
JEWELRY PIECE bisa jadi
menyewa hanya sekali di
tanggal yang sama.
Terminologi
Istilah kunci yang digunakan dalam pelajaran ini meliputi:
• Jejak audit
• Data historis
14Hak Cipta © 2015, Oracle dan / atau afiliasinya. Seluruh
hak cipta. DDS8L1
Memodelkan Data Historis
Ringkasan
Dalam pelajaran ini, Anda seharusnya telah mempelajari cara:
• Mengidentifikasi kebutuhan untuk melacak data yang berubah
dari waktu ke waktu
• Buat model ERD yang menggabungkan elemen "data
lembur"
• Mengidentifikasi UID entitas yang menyimpan data historis;
menjelaskan dan membenarkan pilihan UID
Database Design 8-2 Modeling Change: Time
Tujuan
Pelajaran ini mencakup tujuan berikut:
• Bedakan antara menggunakan tanggal sebagai atribut dan
HARI sebagai
entitas dalam model data, bergantung pada kebutuhan bisnis
• Memecahkan masalah menjaga karakteristik tanggal dengan
membangun model yang menggunakan DAY sebagai entitas
• Identifikasi setidaknya tiga kendala terkait waktu yang
dapat terjadi
dari model yang peka waktu
• Definisikan dan berikan contoh non-transferabilitas
bersyarat
dalam model yang dibatasi waktu
Tujuan
• Waktu berperan dalam banyak model bisnis.
• Data historis sering digunakan oleh bisnis untuk menemukan
tren itu
dapat menunjukkan cara berbisnis yang lebih efisien.
• Waktu pemodelan dalam bisnis memungkinkan data tersebut
ditangkap.
• Laporan memberikan informasi yang dapat diperoleh dari
data.
• Laporan yang dirancang dengan baik dapat memberikan
informasi yang berharga itu
bisnis dapat digunakan untuk meningkatkan operasinya
Entitas HARI vs. Tanggal Atribut
• Pertimbangkan PEMBELIAN entitas.
• Anda akan menyertakan atribut "tanggal" jika
Anda ingin tahu kapan barang itu
dibeli.
• Namun, jika kita ingin mengidentifikasi tren -
seperti membeli mantel vs. pakaian renang
vs. sepatu kets - kita mungkin ingin tahu
suhu selama waktu itu.
• Jika kita menambahkan atribut temperatur ke
entitas PURCHASE itu menciptakan masalah
Entitas HARI vs. Tanggal Atribut
• Ingat Bentuk Normal Ketiga:
atribut non-UID tidak boleh memiliki
atributnya sendiri.
• Karena tinggi dan rendah
suhu adalah atribut dari
tanggal, kita perlu terpisah
entitas DAY
Entitas HARI vs. Tanggal Atribut
• Memiliki entitas DAY terpisah memungkinkan kita melacak
lebih banyak
informasi yang mungkin berguna untuk bisnis, misalnya
hari yang merupakan hari libur
Kendala Terkait Waktu
• Waspadai kendala yang dapat timbul dari kebutuhan untuk
melacak
tanggal dan waktu. Berikut ini contohnya:
- Pertimbangkan pameran sekolah yang menampilkan beberapa
bilik.
- Manajer mendaftarkan sukarelawan untuk bekerja pada shift
yang berbeda
bilik yang berbeda.
- Sebuah stan hanya dikelola oleh satu relawan pada satu
waktu.
- Beberapa sukarelawan dapat bekerja selama beberapa jam;
orang lain bisa bekerja
lebih sedikit jam tergantung pada waktu luang mereka.
- Jadwal harus ditentukan terlebih dahulu, sehingga
manajer tahu waktu mana yang tidak dicakup oleh siapa pun
relawan.
Kendala Terkait Waktu
• Berikut adalah pilihan kendala terkait waktu itu perlu
diperhatikan untuk model ini:
• Yang jelas: shift “end waktu ”harus lebih lama dari geser
"waktu mulai".
Kendala Terkait Waktu
• Waktu shift tidak boleh tumpang tindih.
• "Waktu mulai" untuk shift
seorang sukarelawan mungkin tidak
antara "waktu mulai" dan
"Waktu akhir" yang lain
menjadi sukarelawan di stan yang sama.
• Hal yang sama berlaku untuk “akhir
waktu."
Non-transferabilitas bersyarat
• “Waktu mulai” untuk shift
dapat diperbarui nanti
waktu, kecuali shift punya
sudah mulai.
Non-transferabilitas bersyarat
• Anda mungkin tidak akan mengizinkan
shift untuk ditugaskan kembali
relawan lain atau lainnya
stan, kecuali shift belum
belum dimulai.
• Ini adalah contoh dari
non-transferabilitas bersyarat.
Non-transferabilitas bersyarat
• Non-transferability: SHIFT
ASSIGNMENT tidak boleh
diubah ke BOOTH lain
(atau ke RELAWAN lain).
• Hubungan yang tidak dapat dialihkan diwakili oleh berlian
di ERD.
Non-transferabilitas bersyarat
• Non transferabilitas bersyarat: SHIFT
TUGAS terkadang bisa
diubah - dalam hal ini, jika
pergeseran belum dimulai.
• Hubungan ini tidak mungkin terjadi
direpresentasikan dalam diagram,
tapi harus tetap didokumentasikan.
Terminologi
Istilah kunci yang digunakan dalam pelajaran ini meliputi:
• Non-transferabilitas bersyarat
• Non-transferability
• Kendala terkait waktu
Ringkasan
Dalam pelajaran ini, Anda seharusnya telah mempelajari cara:
• Bedakan antara menggunakan tanggal sebagai atribut dan
HARI sebagai
entitas dalam model data, bergantung pada kebutuhan bisnis
• Memecahkan masalah menjaga karakteristik tanggal dengan
membangun model yang menggunakan DAY sebagai entitas
• Identifikasi setidaknya tiga kendala terkait waktu yang
dapat terjadi
dari model yang peka waktu
• Definisikan dan berikan contoh non-transferabilitas
bersyarat
dalam model yang dibatasi waktu
Database Design 8-3 Modeling Change: Price
Tujuan
Pelajaran ini mencakup tujuan berikut:
• Selesaikan kebutuhan bisnis untuk melacak perubahan harga
atau nilai dengan membangun model yang menggunakan entitas
historis
• Menjelaskan arti penjurnalan / logging
• Mengidentifikasi kebutuhan bisnis untuk penjurnalan /
pencatatan dan
membangun model yang memenuhi persyaratan ini
Tujuan
• Harga historis penting saat mencari tren,
menentukan nilai apresiasi atau depresiasi barang,
atau mendapatkan pengembalian dana untuk item yang dibeli di
masa lalu di a
harga sebelumnya.
• Banyak bisnis melacak sejarah perubahan - siapa yang
mengubahnya,
kapan itu diubah, dan seterusnya.
• Contoh: jika nilai siswa diubah, ada baiknya mencatat
ketika diubah, kelas lama, kelas baru, dan siapa
mengubahnya.
Pentingnya Perubahan Harga
• Perubahan harga seringkali menjadi pertimbangan penting
kapan
pemodelan persyaratan bisnis.
• Beberapa contohnya adalah:
- Pasar saham: Harga berubah setiap detik dan Anda
sedang menonton papan pembaca, bertanya-tanya kapan harus
membeli dan
kapan harus menjual. Faktor apa yang akan Anda
pertimbangkan?
- Industri bahan bakar: Mengapa Anda ingin melacak harga
perubahan bahan bakar jika Anda berpikir untuk membeli mobil
atau pemanas
rumah Anda selama musim dingin?
- Bisnis konstruksi: Mengapa perubahan harga penting
seorang kontraktor proyek pembangunan jembatan lima tahun?
Berapa Harga Hari Ini?
• Harga produk berubah seiring waktu.
• Beberapa naik, beberapa turun, dan lainnya berfluktuasi
dan
turun.
• Makanan, pakaian dan biaya sekolah sekarang lebih mahal
daripada
mereka dua puluh tahun yang lalu.
• Teknologi sering kali menjadi lebih murah dari waktu ke
waktu.
• Anda dapat membeli komputer laptop spesifikasi standar
hari ini
sekitar setengah harga sepuluh tahun yang lalu.
• Emas, perak dan mata uang adalah contoh komoditas yang
harga berfluktuasi.
Model Harga Historis
• Seringkali berguna untuk memiliki informasi
pada harga sebelumnya.
• Model yang ditampilkan di sini melacak
harga historis suatu produk.
Melacak Perubahan Harga
• Bisnis sering kali membutuhkannya
catat harga
perubahan.
• Dalam model ini, kami berasumsi
bahwa setiap PEMBELIAN adalah
hanya satu produk.
• Harga yang dibayarkan bisa
ditemukan dengan mencocokkan
tanggal pembelian antara
tanggal mulai dan tanggal akhir
dari PRICE.
Data Lain Berubah Seiring Waktu
• Kami telah melihat bahwa harga berubah seiring waktu.
• Jenis informasi lain juga dapat berubah, berbeda
alasan bisnis
Penjurnalan
• Kapanpun sistem mengizinkan pengguna
untuk mengubah atau menghapus tertentu
informasi, pertanyaannya harus
ditanyakan, “Apakah nilai-nilai lama perlu
untuk disimpan dalam catatan? "
• Ini disebut "logging" atau
"penjurnalan."
• Ini sering menjadi masalah ketika
informasi keuangan atau a
sifat sensitif, seperti a
perubahan nilai siswa
Isi Jurnal
• Sebuah jurnal biasanya terdiri dari
nilai yang dimodifikasi dan informasi tentang
siapa yang melakukan modifikasi dan kapan itu
selesai.
• Tentu saja, informasi tambahan ini bisa
diperluas jika Anda mau.
Terminologi
Istilah kunci yang digunakan dalam pelajaran ini meliputi:
• Apresiasi
• Depresiasi
• Pembuatan jurnal dan / atau logging
13Hak Cipta © 2015, Oracle dan / atau afiliasinya. Seluruh
hak cipta. DDS8L3
Perubahan Model: Harga
Ringkasan
Dalam pelajaran ini, Anda seharusnya telah mempelajari cara:
• Selesaikan kebutuhan bisnis untuk melacak perubahan harga
atau nilai dengan membangun model yang menggunakan entitas
historis
• Menjelaskan arti penjurnalan / logging
• Mengidentifikasi kebutuhan bisnis untuk penjurnalan /
pencatatan dan
membangun model yang memenuhi persyaratan ini
Database Design 8-4 Drawing Conventions for Readability
Tujuan
Pelajaran ini mencakup tujuan berikut:
• Menerapkan konvensi gambar Oracle ke model data
diagram
• Mengidentifikasi entitas volume tinggi dalam diagram model
data dan
menjelaskan signifikansinya bagi bisnis
• Gambar ulang diagram model data yang diberikan untuk
meningkatkan kejelasan dan
keterbacaan
• Kenali kegunaan membagi ERD kompleks menjadi a
jumlah sub-diagram fungsional
Tujuan
• Bagaimana jika semua pembuat sepatu membuat ukurannya
sendiri?
• Bagaimana jika setiap arsitek menggunakan sistem yang
berbeda untuk menggambar denah
untuk sebuah gedung?
• Mengikuti konvensi yang sama membuatnya lebih mudah untuk
bekerja
bagian dari sebuah tim.
Konvensi Menggambar ERD Besar
• Semakin besar dan rumit suatu ERD, semakin banyak
menantang itu menjadi untuk meletakkan potongan-potongan
secara jelas dan
format yang dapat dibaca.
• Ada dua ketentuan menggambar yang banyak digunakan:
- yang menempatkan entitas volume tinggi di kiri atas
halaman, dan halaman yang menempatkan entitas volume tinggi
kanan bawah halaman.
• Tidaklah penting konvensi mana yang Anda ikuti, tetapi
pilihlah
satu dan mencoba menggunakannya secara konsisten.
• Entitas bervolume tinggi adalah entitas yang akan memiliki
entitas besar
jumlah contoh.
Konvensi Menggambar ERD Besar
• Entitas volume tinggi adalah
sering kali "pusat" atau
entitas yang lebih penting
di ERD.
• Mereka akan mendapatkan yang tertinggi
jumlah hubungan
kepada entitas lain, dan
sebagian besar bisnis
fungsi akan mempengaruhi
data yang disimpan di dalamnya
entitas.
Konvensi Menggambar ERD Besar
• Saat volume tinggi
entitas ada di
bagian kiri atas
ERD, burung gagak
kaki akan cenderung
arahkan ke selatan dan timur.
Konvensi Menggambar ERD Besar
• Saat volume tinggi
entitas ada di
bagian kanan bawah
ERD, burung gagak
kaki akan cenderung mengarah
utara dan barat.
Kejelasan adalah Kuncinya
• Gunakan konvensi dengan bijaksana.
• Tujuan utama pembuatan diagram adalah untuk memberikan a
representasi dari model yang dapat digunakan
tujuan komunikasi.
• Ini berarti Anda tidak boleh membiarkan konvensi
mengganggu
dengan keterbacaan dan kejelasan.
• Seringkali Anda akan memiliki campuran konvensi,
tergantung pada
jumlah ruang yang Anda miliki dan preferensi Anda sendiri.
• Kejelasan dan keterbacaan adalah kriteria utama.
Kejelasan adalah Kuncinya
• Untuk kejelasan dan keterbacaan dalam ERD:
• Hindari melintasi garis hubungan
• Hindari entitas yang tumpang tindih
• Hindari garis hubungan yang melintasi entitas
• Gunakan banyak "ruang putih"
• Bagi ERD yang lebih besar menjadi sub-diagram yang lebih
kecil jika diperlukan
Ruang Dibutuhkan
• Keterbacaan membutuhkan ruang dan tergantung selera.
Penggunaan
spasi putih membantu memperjelas ERD.
Gunakan Sub-Diagram
• Jika Anda memiliki file
diagram yang sangat besar,
itu juga dapat membantu
memecahnya menjadi
diagram yang lebih kecil dari
terkait secara fungsional
entitas
Gunakan Sub-Diagram
• Anda bisa menggunakan sub-diagram yang lebih kecil
saat melakukan presentasi ke berbagai kelompok di dalamnya
perusahaan pelanggan.
• Masih penting untuk memiliki diagram besar itu
menunjukkan keseluruhan gambar (bahkan jika itu harus
dicetak pada plotter atau direkatkan dari
potongan kertas yang lebih kecil).
• Mungkin ada hubungan antar entitas
di sub-model yang berbeda, dan ini harus
diwakili di suatu tempat.
Terminologi
Istilah kunci yang digunakan dalam pelajaran ini meliputi:
• Entitas volume tinggi
• Ruang putih
Ringkasan
Dalam pelajaran ini, Anda seharusnya telah mempelajari cara:
• Menerapkan konvensi gambar Oracle ke model data
diagram
• Mengidentifikasi entitas volume tinggi dalam diagram model
data dan
menjelaskan signifikansinya bagi bisnis
• Gambar ulang diagram model data yang diberikan untuk meningkatkan
kejelasan dan
keterbacaan
• Kenali kegunaan membagi ERD kompleks menjadi a
jumlah sub-diagram fungsional
Komentar