Section 4 “Supetype / subtypes and Bussiness Rules

4.1 Supertype and Subtypes

 Tujuan
Pelajaran ini mencakup tujuan yang mengikuti:
mendefinisikan dan memberikan contoh subtipe.
mendefinisikan dan memberikan contoh supertype.
menyatakan aturan yang berkaitan dengan entitas dan subtipe, dan contoh memberi
masing-masing.
menerapkan aturan supertipe dan subtipe dengan mengevaluasi ketepatan diagram Er
yang mewakilinya.
menerapkan aturan supertipe dan subtipe dan memasukkannya ke dalam diagram bila
perlu.
 Tujuan.
supertipe dan subtipe sering terjadi di dunia nyata:
jenis pesanan makanan (makan di, untuk pergi).
jenis tas belanjaan (kertas, plastik).
jenis pembayaran (cek, tunai, kredit).
Anda biasanya dapat mengaitkan "pilihan" dari sesuatu dengan suertype dan subtipe.
misalnya, apa yang akan menjadi metode pembayaran tunai, cek atau kartu kredit ?.
memahami contoh dunia nyata membantu kita memahami bagaimana dan kapan
memodelkannya.
 Mengevaluasi entitas.
sering kali beberapa instance dari suatu entitas memiliki atribut dan / atau hubungan
yang tidak dimiliki oleh instance lain.
pencitraan bisnis yang perlu melacak pembayaran dari pelanggan. pelanggan dapat
membayar dengan uang tunai, dengan cek, atau dengan kartu kredit.
 Haruskah kita membuat entitas pembayaran tunggal berupa uang tunai, cek, dan kartu
kredit?
dan apa yang terjadi jika di masa depan kami memperkenalkan metode pembayaran
keempat?
 Membagi sebuah entitas.
terkadang masuk akal untuk membagi entitas menjadi subtipe. Ini mungkin terjadi
ketika sekelompok instance memiliki properti khusus, seperti atribut atau hubungan
yang hanya ada untuk grup itu.Dalam hal ini, entitas disebut "supertipe" dan masing-
masing kelompok disebut "subtipe".
 Karakteristik subtipe.
subtipe:
mewarisi semua atribut dari supertype.
mewarisi semua hubungan supertype.
biasanya memiliki atribut atau hubungan sendiri.
ditarik dalam supertype.
tidak pernah hidup sendiri.
mungkin memiliki subtipe sendiri.
 Contoh supertype.
ujian adalah supertpe dari kuis, ujian tengah semester, dan final.
subtipe memiliki beberapa atribut yang sama.
atribut umum ini terdaftar di tingkat supertype.
hal yang sama berlaku untuk hubungan.
subtipe mewarisi semua atribut dan hubungan entitas supertipe.
 Selalu lebih dari satu subtipe.
1. ketika model ER selesai, subtipe tidak pernah berdiri sendiri. dengan kata lain, jika
suatu entitas memiliki subtipe, subtipe kedua juga harus ada. ini masuk akal.
2. subtipe tunggal persis sama dengan supertipe.
3. ide ini mengarah pada dua aturan subtipe:
lengkap: setiap instance dari supertype juga merupakan instance dari salah satu
subtipe. semua subtipe terdaftar tanpa kelalaian.
saling eksklusif: setiap instance dari supertype adalah turunan hanya satu subtipe yang
mungkin.
4. pada tahap pemodelan konseptual, adalah praktik yang baik untuk memasukkan
subtipe lain untuk memastikan bahwa subtipe Anda lengkap - bahwa Anda
menyerahkan setiap instance dari supertype.
 Subtipe selalu ada
entitas apa pun dapat subtipe dengan membuat aturan yang membagi instance menjadi
grup. Tetapi bisa subtipe bukanlah masalahnya, memiliki alasan untuk subtipe adalah
masalahnya. Ketika ada kebutuhan dalam bisnis untuk menunjukkan persamaan dan
perbedaan antara contoh, maka subtipe.
 Mengidentifikasi subtipe dengan benar.
Saat memodelkan supertipe dan subtipe, Anda dapat menggunakan tiga pertanyaan
untuk melihat apakah subtipe diidentifikasi dengan benar:
Apakah subtipe ini semacam supertipe?
sudahkah dibahas semua kemungkinan kasus? (lengkap).
apakah setiap instance cocok menjadi satu dan hanya satu subtipe? (saling eksklusif).
 Subtipe bersarang.
Anda dapat membuat subtipe sarang.
untuk kemudahan membaca - "keterbacaan" - Anda biasanya akan menampilkan
subtipe dengan hanya dua level, tetapi tidak ada aturan yang akan menghentikan Anda
untuk melampaui dua level.


Ringkasan
dalam pelajaran ini, Anda seharusnya belajar bagaimana:
mendefinisikan dan memberikan contoh subtipe.
mendefinisikan dan memberi contoh supertype.
nyatakan aturan yang berkaitan dengan entitas dan subtipe dan berikan masing-
masing contoh.
menerapkan aturan supertipe dan subtipe dengan mengevaluasi keakuratan diagram
ER yang mewakilinya.
menerapkan aturan supertipe dan subtipe dan memasukkannya ke dalam diagram bila
perlu.
4.2 Mendokumentasikan Aturan Bisnis (Documenting Business Rules)

 Tujuan.
Salah satu tujuan utama pemodelan data adalah untuk memastikan bahwa semua
informasi yang diperlukan untuk menjalankan bisnis diakui.
Mengidentifikasi dan mendokumentasikan aturan bisnis adalah kunci untuk memeriksa
model data Anda untuk akurasi dan kelengkapan.
Penting untuk menyadari bahwa tidak semua aturan bisnis dapat diwakili dalam ERD.
beberapa aturan bisnis harus diterapkan oleh pemrograman.
 Aturan bisnis struktural dan prosedural.
Aturan struktural bisnis menunjukkan jenis informasi yang akan disimpan dan bagaimana
elemen-elemen informasi saling berhubungan.
aturan prosedural menangani prasyarat, langkah, proses, atau persyaratan alur kerja suatu
bisnis.
banyak aturan bisnis prosedural terkait dengan waktu: peristiwa A harus terjadi sebelum
acara B.
aturan bisnis struktural hampir selalu dapat digambarkan dalam ERD.
beberapa aturan bisnis prosedural tidak dapat dibuat diagramnya, tetapi masih harus
didokumentasikan sehingga dapat diprogramkan nanti.
 Contoh aturan prosedural.
aturan bisnis prosedural terkait dengan alur kerja atau proses.
berikut adalah beberapa contoh proses yang harus diikuti dalam skenario departemen
sumber daya manusia:
beberapa karyawan kami diharuskan menghadiri acara pelatihan wajib. Peristiwa ini
terjadi di salah satu lokasi perusahaan yang ada dan karyawan melakukan perjalanan ke
lokasi untuk mengambil bagian dalam pelatihan.
persetujuan untuk semua permintaan perjalanan ke acara pelatihan harus ditandatangani
oleh manajer karyawan sebelum karyawan dapat mendaftar untuk acara tersebut.
 Aturan bisnis yang digambarkan dalam ERD.
Skenario departemen sumber daya manusia:
beberapa karyawan kami diharuskan menghadiri acara pelatihan wajib. acara-acara ini
 berlangsung di salah satu lokasi perusahaan yang ada, dan karyawan pergi ke lokasi untuk
mengambil bagian dalam pelatihan.

 Mendokumentasikan aturan.
dalam proses pengembangan model data konseptual, tidak semua aturan bisnis dapat
dimodelkan.
beberapa aturan seperti dua yang tercantum di bawah ini harus diterapkan dengan
memprogram proses yang berinteraksi dengan data:
setiap karyawan yang lemburnya melebihi 10 jam per minggu harus dibayar 1,5 kali dari
tarif jam.
cumtomer yang saldo rekeningnya sudah lewat 90 hari tidak akan diizinkan untuk
mengisi pesanan tambahan.
 Ringkasan.
dalam pelajaran ini, Anda seharusnya belajar bagaimana:
mendefinisikan dan menyusun aturan bisnis struktural.
mendefinisikan dan menyusun aturan bisnis prosedural.
mengakui bahwa beberapa aturan bisnis akan memerlukan pemrograman.
diagram aturan bisnis ketika mereka dapat diwakili dalam model ER.
Section 5 – Dasar Relasi

5.1 Relasi yang bersifat dapat dipindahkan

Objektivitas

Pelajaran berikut ini mencakup

- Mendeskripsikan dan emberikan sebuah contoh dari dasar relasi

- Memahami perbedaan antara sifat yang dapat diganti dan tidak dapat diganti dalam relasi
- Menggambarkan relasi sifat yang tidak dapat diganti pada ERD

Tujuan

- Sekali suatu kelas telah dialokasikan untuk seorang guru, akankah kelas akan ditransfer
ke guru lainnya, mungkinkah di pertengahan semester?
- Biasanya iya, karea jika tidak, apa yang harus dilakukan untuk guru aslinya jika sedang
sakit?
- Beberapa klub kesehatan mengizinkan keanggotaannya diganti darri satu orang ke
lainnya, tetapi klub kesehatannya tidak mengizinkan
- Aturan bisnis ini normal ditentukan oleh apa yang lebih efesien dan lebih menguntungkan
untuk klub.

Ulasan Relasi

- Mari kita ulas sebuah simple relasi antara EMPLOYEE dan DEPARTMENT.
- Pilihan :
Haruskah setiap employee ditugaskan pada setiap DEPARTMENT?
Haruskah setiap department bertanggungjawab untuk setiap employee?
- Kardinalitas
Berapa banyak employee’s yang bertanggungjawab department
Berapa banyak department yang menugasi employee?

- Sifat yang dapat diganti :

Bisakah seorang Employee digantikan dari satu DEPARTMENT ke DEPARTMENT
lainnya?

Relasi yang dapat diganti

- Sifat yang dapat diganti : seorang murid diizinkan untuk pindah dari satu study group ke
group lainnya.

- Sifat yang tidak dapat diganti : seorang student dapat mengeluarkan receipt untuk
membayar uang sekolah, mengambil sertifikat ujian, atau pembelian barang di toko buku.
- Sekali sebuah receipt dikeluarkan, tidak dapat digantikan oleh student lainnya.

Contoh lain relasi yang tidak dapat digantikan sifatnya.

- Pemilik sebuah puisi milik penulisnya
- Kepengarangan dalam sebuah relasi tidak dapat dipindahkan ke orang lainnya.
Terminologi : Dapat digantikan dan tidak dapat digantikan
5.2 Tipe Relasi

Objektivitas
- Mengenali dan memberikan contoh dari hubungan one-to-one
- Mengenali dan memberikan contoh dari hubungan one-to-many
- Mengenali dan memberikan contoh dari hubungan many-to-many
- Mengenali kelebihan relasi dan menghapusnya dari ERD

Tujuan

- Bisakah seseorang memiliki banyak DVD atau hanya satu ?

- Bisakah satu DVD dimiliki oleh satu orang saja?
- Seperti yang kita sempurnakan dan memperbaiki model, kita ingin membuat relasi entits
yang sesuatu dengan benar sesuai aturan bisnis

One-to-Many (1:M)

- Tipe Variasi dari relasi 1:M paling umum dalam sebuah ER model.

Many-to-Many (M:M)
- Tipe Variasi dari relasi M:M paling umum, terutama pada versi pertama dari sebuah ER
Model
 -

One-to-One (1:1)
- Biasanya kamu akan menemukan beberapa tipe dari relasi 1:1 di setiap ER Model.
- Pada salah satu akhir dari relasi 1:1, umumnya terjadi ketika peran dimodelkan.
- Relasi 1:1 (dari semua variasi) juga terjadi ketika beberapa dari entitas merepresentasikan
tahapan variasi proses.

Kelebihan relasi
- Namun, hati-hati dalam menyimpulkan bahwa sebuah relasi berlebihan berdasarkan
strukturnya sendiri.
- Baca relasi untuk memeriksa
- ERD tidak menunjukkan bahwa relasi berlebihan
Kata kunci : Many-to-Many, One-to-Many, One-to-One, Kelebihan
5.3 Menyelesaikan Relasi Many-to-Many

Objektivitas
- Mengindetifikasikan atribut milik relasi M:M
- Mendemonstrasikan langkah-langkah untuk menyelesaikan sebuah relasi M:M dengan
menggunakan entitas titik potong

Tujuan

- Pelajaran ini akan membantu kamu memenuhi model, mungkin membutuhkan untuk
membuat entitas baru atau relasi baru berdasarkan kebutuhan bisnis
- Ini juga akan membantu kamu menetapkan ruang lingkup dari data model, model yang
penting untuk bisnis.

Relasi menutupi sebuah atribut

- Di sebuah sekolah , seorang student mungkin belajar satu atau lebih subjects
- Setiap subject mungkin dipelajari oleh satu atau lebih student.
- Ketika seorang student mendaftar sebuah subject , kita ingin mencatat nilai yang mereka
capai pada subject itu
- Entitas mana yang mana menjadi milik atribut “Grade” ?
- Jika kita menginput “Grade” pada entitas student, bagaimana jika itu untuk subject?
- Jika kita menginput “Grade” pada entitas subject, bagaimana jika itu untuk student tidak
pada tingkatnya?
-

Resolusi dari relasi M:M

- Entitas ketiga dibutuhkan untuk menyelesaikan M:M, ini disebut dengan perpotpngan
entitas.
- Sebuah titik potong entitas, - enrollment- sudah ditambhakan, termasuk atribut grade.
- Relasi M:M yang original menjadi dua relasi 1:M
- Apa yang seharusnya menjadi UID titik potong entitas?

Larangan relasi
- UID (unique identifier) dari ttik potong entitas jarang berasal dari relasi yang orisinil dan
tereprensentasikan lagi
- Pada kasus ini, relasi berasal dari entitas orisinal ke relasi baru

Contoh penyelesaian M:M TV Shows

- Setiap TV show mungkin dilihat oleh seseorang atau lebih
- Setiap orang mungkin melihat satu atau lebih TV show.

Contoh penyelesaian M:M Cleaning Services

- Setiap perusahaan mungkin menyediakan seseorang atau lebih
- Setiap CS mungkin disedikakan satu atau lebih perusahaan

Kata kunci :
Relasi dilarang, titik potong entitas
 5.4 Persyaratan CRUD

Analisis CRUD
- Jalan terbaik untuk validasi sebuah ERD adalah dengan analisis CRUD
- CRUD merupakan akronim dari Create, Retrieve, Update, Delete
- Ada empat fungsi dasar
- Bagaian untuk mememriksa data model untuk kelengkapan akurasi untuk meyakinkan
semua fungsi CRUD ditampilkan di ERD

Fungsi Create
- Selama wawancara klien dan ketika menulis scenario bisnis dan aturan, lihat kata kunci :
input, enter, load, import, record, dan create
- Semua diindikasikan bahwa data yang tersimpan dibuat dalam database dalam satu waktu
- Ulasan tentang persyaratan untuk kata kunci ini
- Apakah akun data model untuk semua berfungsi?

Fungsi Retrieve
- Selama wawancara klien dan ketika menulis scenario bisnis dan aturan, lihat kata kunci :
View, report, bring up, print, find, read, dan look up
- Semua poin ini untuk mengambil informasi dari database
- Ulasan syarat untuk kata kunci ini
- Apakah akun data model untuk semua berfungsi?

Fungsi Update
- Selama wawancara klien dan ketika menulis scenario bisnis dan aturan, lihat kata kunci :
Change, modify, alter, update
- Semua poin ini untuk mengupdate informasi dari database
- Ulasan syarat untuk kata kunci ini
- Apakah akun data model untuk semua berfungsi?

Fungsi Delete
- Selama wawancara klien dan ketika menulis scenario bisnis dan aturan, lihat kata kunci :
Dircard, remove, trash, purge, delete
- Semua poin ini untuk menghapus informasi dari database
- Ulasan syarat untuk kata kunci ini
- Apakah akun data model untuk semua berfungsi?
 SECTION 6 – UIDS DAN NORMALISASI

6.1. Pembuatan, Penggabungan dan Secondary Unique Identifier (UIDs)

Target
Target dari pembelajaran ini diantaranya:
 Mendefinisikan perbedaan tipe UID
 Mendefinisikan kandidat UID dan menjelaskan mengapa sebuah entitas
terkadang dapat mempunyai lebih dari satu UID
 Menganalisis aturan dan memilih UID yang lebih cocok dari beberapa hal yang
akan dijadikan UID
 Mengetahui dan berdiskusi mengenai persoalan identifikasi di dunia nyata
Tujuan
 Unique identifier (UID) sangat penting dalam relasi database
 Hasil atau kombinasi hasil memungkinkan pengguna untuk menemukan bahwa
satu item yang unik berada diantara semua rest
 Uniqe identifier memungkinkan untuk menemukan catatan atau isi dalam suatu
file, bagian kartu dalam sebuah deck, package pada sebuah warehouse, atau
bagian spesifik pada data di dalam sebuah database
Simple UIDs vs. Composite UIDs
 Sebuah UID yang merupakan sebuah atribut single merupakan sebuah Simple
UID (UID sederhana)
 Namun, terkadang sebuah atribut single tidak cukup digunakan sebagai unique
identifier pada sebuah entitas
 Apabila UID merupakan gabungan atribut, hal ini disebut dengan Composite
UID
Pembuatan UIDs
 Pembuatan UID merupakan suatu yang tidak terjadi di dalam dunia nyata,
melainkan dibuat untuk tujuan identifikasi sistem
  Seseorang tidak lahir dengan “angka”, namun banyak dari sistem menentukan
angka yang unik untuk mengidentifikasi orang, seperti ID siswa, ID kustomer,
dll.
 Sebuah sepatu memiliki warna, ukuran, jenis, namun tidak benar-benar
mendeskripsikan angka
 Namun, sebuah sepatu akan menentukan angka unik untuk pasangannya
sehingga sepatu dapat diidentifikasi secara unik
Contoh Pembuatan UID
 Bagaimana kita dapat mengidentifikasi secara unik seorang siswa?
 Dapatkah kita menggunakan kombinasi dari nama awal dan nama akhir?
 Terkadang, hal ini lebih sederhana untuk membuat sebuah atribut dan membuat
unique identifier
 Sebuah UID dapat dibuat berdua dan digabungkan
UID dari barred relationship
 Terkadang UID adalah sebuah kombinasi dari sebuah atribut dan sebuah relasi
 Apa yang dimaksud dengan UID dari akun? Apakah dibuat? Apakah
digabungkan?
 Dua orang dapat mempunyai nomor akun bank yang sama, namun di bank yang
berbeda
 Transfer dari bank satu ke bank yang lain selalu membutuhkan nomor routing
bank dalam tambahan nomor akun bank
UID dari barred relationshipentitas intersection
 Sebagaimana yang telah kita ketahui sebelumnya, resolusi dari relasi many to
many pada barred relationship dari entitas interscetion ke yang lainnya
 Dalam contoh ini, UID dari entrollment berasal dari student dan subject
Pembuatan UID entitas intersection
 hal ini memungkinakn untuk sebuah entitas intersection untuk menggunakan
sebuah pembuatan atribut sebagai UID
 sebuah perusahaan dapat memproduksi satu atau lebih produk seperti sepatu,
baju, jeans, dll)
 sebuah produk dapat diproduksi oleh satu atau lebih perusahaan seperti nike
shoes, adidas shoes, levi’s shoes, dll)

 item catalog mengatasi relasi many to many tersebut

 Sebuah item pada catalog dapat diidentifikasi secara unik oleh nomor
perusahaan dan kode produk
 Relasi tidak barred, karena sebuah UID yang dibuat telha digantikan oleh nomor
catalog
Kandidat UIDs
 Terkadang dua atau lebih UID memungkinkan untuk digunakan
  Sebagai contoh, ketika kamu memesan sebuah produk dari sebuah website
komersioal, kamu biasanya akan dikenali dengan menggunakan kode unik
kustomer dan diminta untuk memasukkan email dan alamatmu
 Salah satu dari hal tersebut mengidentifikasimu secara unik, dan salah satunya
dapat dipilih sebagai UID. Kedua hal tersebut merupakan kandidat UIDs
 Hanya satu kandidat UIDs yang dipilih sebagai UID yang sebenarnya. Hal ini
disebut dengan UID primer
 Dan kandidat yang lain disebut dengan UID sekunder

 ID student telah dipilih sebagai UID primer dalam kedua entitas student
 Entitas pertama memiliki UID sekunder
Identifikasi : Database vs. Dunia Nyata
 Unique identifier membuat kemungkinan untuk kita membedakan satu hal pada
sebuah entitas dari yang lainnya
 Sebagaimana yang kita lihat selanjutnya, hal ini menjadi primary key pada
sebuah database
 Sebuah primary key memungkinkanmu untuk mengakses catatan/data spesifik
dalam sebuah database
 Dalam dunia nyata, terkadang tidak mudah untuk membedakan satu hal dari
yang lainnya.

6.2. Normalisasi dan First Normal Form

 Target
Target dari pembelajaran ini diantaranya:
 Mendefinisikan tujuan dari normalisasi pada model database
 Mendefinisikan aturan dari normal form pertama pada proses normalisasi
 Menentukan sebuah entitas sesuai dengan aturan pada normal form pertama
 Mengonversi sebuah entias ke normal form pertama apabila dibutuhkan
Tujuan
 Berfikir tentang menceritakan nomor handphone temanmu pada tiga tempat
yang berbeda: buku alamatmu, telepon genggammu, dan sebuah lembar kertas
yang kamu tempel pada refrigerator
 Ini menimbulkan banyak pekerjaan apabila temanmu mengganti nomor
teleponnya
 Kamu harus menggantinya pada buku alamatmu, telepon genggammu, dan
sebuah lembar kertas yang kamu tempel
 Apa yang terjadi apabila data terdapat pada lebih dari satu tempat di dalam
sebuah database?
 Apakah jika seseorang mengubah informasi di sebuah tempat dan tidak pada
tempat yang lain, bagaimana kamu tahu mana informasi yang benar?
 Redudansi seperti ini menyebabkan terjadinya masalah dalam sebuah database
 Normalisasi adalah sebuah proses yang digunakan untuk mengeliminasi masalah
seperti ini
 Salah satu tujuanmu sebagai pembuat database adalah untuk menampilkan data
di satu tempat dan di tempat yang baik
 Apabila kamu mengikuti aturan normalisasi, kamu akan mencapai tujuan ini.
First Normal Form (1NF)
 First Normal Form memerlukan atribut yang ditampilkan tidak memiliki multi-
valued
 Untuk mengecek 1NF, validasi masing-masing atribut mempunyai single value
untuk masing-masing perusahaan pada entitas
  Satu kode, satu nama, dan satu alamat ditampilkan dalam bangunan sekolah,
namun tidak untuk satu ruang kelas

 Sejak banyak ruang kelas di dalam bangunan sekolah, ruang kelas merupakan
multi-valued dan terjadi violasi 1NF
 Apabila sebuah atribut merupakan multi-valued, buat sebuah entitas tambahan
dan relasikan ke entitas original (asli) dengan relasi 1 to many

1NF Violation
 Periksa entitas
 Apakah terdapat multi-valued atribut?
  Ketika semua atribut dalam sebuah entitas adalah single-valued, entitas dapat
dikatakan menjadi first normal form

6.3. Second Normal Form

Target
Target dari pembelajaran ini diantaranya:
 Mendefinisikan aturan dari second normal form dalam proses normalisasi
 Memeriksa entitas yang belum ternormalisasi dan menentukan mana aturan atau
aturan normalisasi yang terviolasi
 Mengaplikasikan aturan second normal form untuk mengatasi violasi pada
model
Tujuan
 Tujuanmu sebagai pembuat database adalah menampilkan informasi hanya di
satu tempat dan di tempat yang terbaik
  Konsistensi pengaplikasian aturan normalisasi membantumu mencapai tujuan ini
 Ketika pengorganisasian informasi seperti nomor telepon dan alamat temanmu,
kamu ingin untuk memastikan bahwa kamu menampilkan informasi sesuai
tempatnya seperti sebuah buku alamat pribadi
 Apabila kamu menampilkan alamat temanmu di buku, dan kamu tidak
menemukannya hingga kamu melihat pada buku itu
 Normalisasi adalah sebuah proses yang membantu mengeliminasi permasalahan
seperti ini
Second Normal Form
 Memeriksa entitas suplier produk
 UID adalah gabungan UID yang terdiri atas nomor suplier dan nomor produk
 Apabila satu suplier menyuplai 5 produk yang berbeda, kemudian dibuat 5 hal
perbedaan
 Apa yang terjadi apabila nama suplier berubah?
 Nama suplier akan perlu mengubah kelima hal yang berbeda tersebut
 Bagaimana user tahu mana nama yang benar?
Deskripsi Second Normal Form
 Second Nomal Form (2NF) memerlukan atribut non-UID menjadi karakteristik
atau properti UID yang telah ada
 Apakah nama suplier merupakan properti dari nomor suplier, nomor produk,
atau keduanya?
 2NF memerlukan keduanya

e
Garis Relasi Second Normal Form
 UID untuk akun adalah gabungan ID dari sebuah barred relationship yang terdiri
atas nomor akun dan nomor bank
  Apakah balance merupakan sebuah properti dari nomor akun, nomor bank, atau
keduanya?
 Apakah date opened merupakan sebuah properti dari nomor akun, nomor bank,
atau keduanya?

Violasi Second Normal Form

 Dalam ERD ini, atribut lokasi bank telah ditambahkan. Apakah lokasi bank
merupakan sebuah properti dari nomor akun, nomor bank, atau keduanya?
 Ini merupakan properti nomor bank saja. Ini merupakan sebuah violasi dari
second normal form
 Apakah yang terjadi jika lokasi bank berubah?
 Setiap akun pada bank tersebut akan butuh pengupdatean

Order ERD
 Apakah yang salah dari diagram di bawah?

 ERD saat ini telah dalam 2NF

  Jawaban: atribut price mengalami salah tempat
 Item price hanya bergantung pada produk
 Ini merupakan violasi pada secod normal form

6.4. Third Normal Form

Target
Target dalam pembelajaran ini diantaranya:
 Mengidentifikasi dependen transitif pada data model
 Mendefinisikan aturan pada third normal form pada proses normalisasi data
 Memeriksa entitas yang belum ternormalisasi dan menentukan aturan mana atau
aturan normalisasi yang terviolasi
 Mangaplikasikan aturan third normal form untuk mengatasi violasi pada model
Tujuan
 Tujuanmu sebagai pembuat database adalah untuk menampilkan informasi di
satu tempat saja dan di tempa yang terbaik
 Mengikuti aturan normalisasi membantumu dalam mencapai tujuan ini
 Kamu dapat memasukkan jenis informasi temanmu yang berbeda pada buku
alamat pribadi: nomor telepon, alamat, nama sekolah atau tempat kerja
 Apabila kamu mempunyai beberapa teman yang berada di dalam sekolah yang
sama dan kamu memasukkan alamat seolah di masing-masing data temanmu,
kamu tidak hanya menduplikasi data, namun juga menyebabkan terjadinya suatu
permasalahan. Sebagai contoh, apabila sekolah berpindah tempat dan mengubah
alamatnya, kamu harus kembali lagi dan mengubahnya dimana saja
 Normalisasi adalah sebuah proses yang membantu mengeliminasi permasalahan
seperti ini
Aturan Third Normal Form
 Aturan dari third normal form (3NF) menyatakan bahwa tidak ada atribut non-
UID dapat menjadi dependen pada atribut non-UID lainnya
 Third normal form tidak memperbolehkan adanya dependen transitif
 Sebuah dependen transitif ditampilkan ketika atribut pada sebuah entitas bersifat
dependen terhadap atribut non UID lainnya dalam sebuah entitas
  Berfikir mengenai jenis informasi yang akan kamu tampilkan adalah mengenai
koleksi Cdmu
 Apakah informasi mengenai toko dimana kamu membelinya terdapat pada satu
entitas yang sama?
 Apabila alamat buku berubah, kamu harus merubah informasi pada semua CD
yang kamu beli di toko tersebut.
Dependen Transitif Third Normal Form
 Alamat yang ditampilkan bersifat dependen pada nomor CD yang merupakan
UID pada entitas CD. Jadi entitas ini berada pada 1NF dan 2NF
 Namun, alamat toko juga bersifat dependen pada nama toko yang merupakan
atribut non UID
 Ini merupakan contoh dari dependen transitif dan violansi dari third normal form

 Normalisasi model yang benar ditunjukkan disini:

Contoh Third Normal Form
 Pertimbangan sebuah sistem yang memiliki informasi tentang cities-size,
population, mayor dan lain sebagainya
 Model pertama menunjukkan sebuah entitas yang memasukkan informasi state
 Meskipun state adalah sebuah atribut dari city, state flower adalah benar-benar
sebuah atribut state

 Model kedua, dengan entitas state baru, merupakan third normal form

Contoh Kedua Third Normal Form

 Pada contoh ini, anggap aturan: setiiap employee dapat mempunyai satu partner
 Model ini mengalami violasi third normal form karena partner birth date
merupakan atribut dari partner, bukan employee
  Cara lain: atribut non UID tidak dapat mempunyai atribut dari dirinya sendiri

Solusi contoh kedua 3NF

 Relasi 1 : 1 opsional pada employee karena terdapat beberapa employee yang
tidak memiliki partner
 Section 7 (Arcs, Hierarchies, and Recursive Modelling)

7.1 ARC

Objective (Tujuan)

Pelajaran ini mencakup tujuan-tujuan berikut

 Mendefinisikan istilah "kendala" yang berlaku untuk pemodelan data

 Mengidentifikasi hubungan atau eksklusif dalam skenario bisnis
 Diagram kendala busur untuk mewakili hubungan atau eksklusif
 Membedakan antara penggunaan Arc (busur) dan subtipe dalam model data

Purpose / Tujuan

 Arc (busur) dalam pemodelan data membantu desainer menjelaskan hubungan eksklusif
atau lintas hubungan
 Semakin eksplisit Anda dapat menentukan persyaratan klien, semakin akurat
implementasi akhir Anda

Apa yang menjadi kendala?

 Setiap bisnis memiliki batasan nilai atribut mana dan hubungan mana yang diizinkan
 Pembatasan ini disebut kendala
 Mereka dapat merujuk pada satu atribut entitas, atau hubungan antara entitas
 Kita sudah tahu tentang beberapa macam kendala; misalnya, setiap karyawan harus
bekerja di satu dan hanya satu departemen
 Dalam pelajaran ini, kita akan melihat jenis kendala lain - eksklusif atau kendala

Eksklusif atau hubungan

 Hubungan yang saling eksklusif kadang-kadang ada antara entitas dan juga dikenal
sebagai eksklusif atau hubungan
 Eksklusif atau hubungan adalah hubungan antara satu entitas dan dua (atau lebih) entitas
lain di mana hanya satu dari hubungan itu yang bisa ada pada suatu waktu
 di ERD, kami memodelkan jenis hubungan ini dengan Arc
Eksklusif atau Hubungan

 Sebagai contoh, acara pelatihan dapat diselenggarakan oleh pelatih di rumah atau
perusahaan pelatihan eksternal

 Setiap acara pelatihan harus diselenggarakan oleh satu dan hanya satu in-house trainer
atau satu dan hanya satu perusahaan pelatihan

 Contoh lain : Papan iklan adalah ruang iklan yang dapat menampilkan film, produk, atau
pengumuman publik. Ini mungkin mengandung iklan tentang hanya satu saja dalam satu
waktu
  Setiap "fitur" memiliki karakteristik atau atributnya sendiri
 Arc memberitahu pembaca diagram bahwa hanya satu dari "fitur" ini yang akan memiliki
hubungan dengan setiap instance dari papan iklan

Mewakili Eksklusif atau Hubungan di ERD

 Arc (busur) adalah cara untuk mewakili hubungan yang saling eksklusif di ERD
  Arc (busur) ini mewakili eksklusif atau hubungan - masing-masing keanggotaan harus
dipegang oleh satu perusahaan atau harus dipegang oleh satu pelanggan, tetapi tidak
keduanya

 Arc (busur) diwakili pada ERD sebagai garis padat dengan ujung melengkung
 Sebuah lingkaran digambar pada busur untuk setiap hubungan yang merupakan bagian
dari Arc (busur)

Arcs

 Sebuah Arc (busur) selalu menjadi milik satu entitas

 Arc (busur) dapat mencakup lebih dari dua hubungan
 Tidak semua hubungan entitas perlu dimasukkan dalam busur
  Suatu entitas dapat memiliki beberapa busur
 Arc (busur) harus selalu terdiri dari hubungan dengan opsionalitas atau pilihan yang sama
 Semua hubungan dalam Arc (busur) harus bersifat wajib atau semua harus opsional
 hubungan dalam busur mungkin berbeda kardinalitas, meskipun ini jarang terjadi

Arc, Supertypes, dan Subtypes

 Arc dan super/subtype keduanya memodelkan eksklusivitas timbal balik

 Situasi tertentu dimodelkan sebagai busur, dan yang lainnya adalah Supertype dan
Subtype
 Contoh 1 : Checking account dan savings account adalah "tipe" dari account

 Ini harus dimodelkan sebagai Supertype dan subtipe

 Contoh 2 : Sebuah acara dapat diadakan di rumah pribadi atau ruang publik
 Jika entitas yang terkait melalui busur serupa, mungkin ada kasus untuk membuat super /
subtipe tanpa busur
 Dalam hal ini, baik rumah pribadi maupun ruang publik adalah tipe tempat, dan mereka
memiliki atribut yang hampir sama, sehingga mereka bisa menjadi Supertype dan subtipe

 Contoh 3 : Di rumah pelatihan dan perusahaan pelatihan bukanlah jenis acara pelatihan,
dan mereka tidak memiliki atribut yang sama. ini yang terbaik untuk dimodelkan dengan
busur
Terminologi

Istilah kunci yang digunakan dalam pelajaran ini termasuk

 Arc
 Constraint
 Exclusive or relationship
 Mutually exclusive relationship (Hubungan yang saling eksklusif)

Summary (Ringkasan)

Dalam pelajaran ini, Anda seharusnya belajar caranya:

 Mendefinisikan istilah "kendala" yang berlaku untuk pemodelan data

 Mengidentifikasi hubungan ATAU eksklusif dalam skenario bisnis
 Diagram kendala busur untuk mewakili hubungan OR eksklusif
 Membedakan antara penggunaan busur dan subtipe dalam model data
7.2 Hierarchies and Recursive Relationships

Objective (Tujuan)

Pelajaran ini mencakup tujuan-tujuan berikut:

 Mendefinisikan dan memberikan contoh hubungan hierarkis

 Mengidentifikasi UID dalam model hierarkis
 Mendefinisikan dan memberi contoh hubungan rekursif
 Mewakili hubungan rekursif dalam ERD yang diberikan skenario
 Membangun model menggunakan rekursi dan hierarki untuk mengekspresikan makna
konseptual yang sama

Purpose atau Tujuan

 Seringkali, peran diatur oleh hierarki -- pada pekerjaan (manajer, kepala kru, petugas
front-counter, pembuat makanan), atau di sekolah (kepala sekolah atau kepala sekolah,
asisten kepala sekolah atau asisten kepala sekolah, guru, staf).
 Data hierarkis sangat umum
 Memahaminya akan membantu Anda menjadi model :
 Bagan organisasi bisnis
 Struktur bangunan
 Pohon keluarga
 Dan banyak hierarki lain yang ditemukan di dunia nyata

Hubungan dalam Bagan Organisasi

 Hierarki pelaporan organisasi dapat diwakili oleh bagan organisasi ini

 Bagan organisasi dapat direpresentasikan oleh model data ini
 Kami membuat entitas untuk setiap level, dengan hubungan ke level berikutnya
 Apa UID untuk setiap entitas?

Contoh Hubungan Lain

 Perhatikan hubungan yang dilarang
 Di sini Anda memiliki kasus UID
 UID lantai adalah kombinasi nomor lantai dan ID bangunan
 UID suite adalah kombinasi nomor suite dan nomor lantai dan ID bangunan
 UID kamar adalah kombinasi nomor kamar dan nomor suite serta nomor lantai
dan nomor bangunan
Hierarki Versus Hubungan Rekursif

 Kedua model ini mewakili semua karyawan

 Yang sebelah kiri adalah struktur hierarkis
 Salah satu dari kanan menggunakan hubungan rekursif

 Suatu hubungan tidak bisa sekaligus hierarkis dan rekursif pada saat yang sama
 Mana yang menurut Anda lebih baik?
  Hierarkis: struktur hierarkis lebih eksplisit dan lebih mudah dipahami kebanyakan orang
karena sangat mirip dengan bagan organisasi
 Setiap entitas dapat memiliki atribut dan hubungan wajibnya sendiri, jika bisnis
membutuhkan ini (alih-alih semua atribut dan hubungan opsional, seperti yang Anda
miliki dalam rekursif)
 Dengan cara ini, model data Anda benar-benar mencerminkan aturan bisnis
 Rekursif: hubungan rekursif cenderung lebih sederhana karena Anda hanya
menggunakan satu entitas
 Diagram Anda akan kurang "sibuk"
 Namun, mereka kurang spesifik - Anda tidak dapat memiliki atribut atau hubungan wajib
kecuali mereka wajib dalam semua hal pada entitas

Konvensi Gambar

 Konvensi ERD untuk menunjukkan hubungan rekursif digambarkan sebagai sebuah

lingkaran, juga dikenal sebagai "telinga babi"

Skenario Bisnis Manufaktur Mobil

 Untuk organisasi manufaktur mobil, pertimbangkan semua bagian dasar, subrakitan,

rakitan, dan produk sebagai contoh dari entitas yang disebut komponen
 Model dapat dibuat sebagai hubungan rekursif sederhana
  Model tagihan data material sebagai hubungan rekursif many-to-many:
 Setiap komponen dapat menjadi bagian dari satu atau lebih komponen
 Setiap komponen dapat terdiri dari satu atau lebih komponen

Terminologi

Istilah kunci yang digunakan dalam pelajaran ini termasuk

 Hubungan Hierarkis
 Hubungan Rekursif

Summary (Ringkasan)

Dalam pelajaran ini, Anda seharusnya belajar caranya:

 Mendefinisikan dan memberikan contoh hubungan hierarkis

 Mengidentifikasi uid dalam model hierarkis
 Mendefinisikan dan memberi contoh hubungan rekursif
 Mewakili hubungan rekursif dalam erd yang diberikan skenario
 Membangun model menggunakan rekursi dan hierarki untuk mengekspresikan makna
konseptual yang sama