MENDESAIN BASIS DATA

BAB 12 MENDESAIN BASIS DATA

Slide 2 dan 3 tentang Tujuan Pembelajaran

GAMBARAN UMUM

  • Bab ini menjelaskan desain model data relasional dan OO
  • Para pengembang mentranformasikan model-model data konseptual ke dalam model-model basis data yang rinci

–          Entity-relationship diagrams (ERDs) untuk analisis tradisional

–          Class diagrams untuk analisis berorientasi objek (OO)

  • Model-model basis data yang rinci diimplementasikan dengan Database Management System (DBMS)

Basis data dan Database Management System (DBMS)

  • Basis data (Database [DB]) – kumpulan data yang telah disimpan dan terintegrasi yang dimanage dan dikontrol secara terpusat
  • Database Management System (DBMS)—software sistem yang memanage dan mengontrol akses ke basis data
  • Database dideskripsikan dengan skema—deskripsi struktur, konten, dan kontrol akses

Komponen-Komponen DB dan DBMS, lihat slide 6

Kemampuan DBMS yang Penting

  • Akses bersamaan oleh berbagai user dan aplikasi
  • Akses ke data tanpa program aplikasi (via bahasa query)
  • Management data organisasional dengan akses dan kontrol konten yang sama

Model-Model Basis Data

  • Dipengaruhi oleh perubahan teknologi sejak tahun 1960
  • Jenis-jenis model

–          Hirarkis

–          Jaringan

–          Ralasional

–          Berorientasi objek

  • Banyak sekali sistem saat ini yang menggunakan model-model data berorientasi objek dan relasional

Basis Data Relasional

  • Relational database management system (RDBMS) mengorganisir data ke dalam tabel-tabel atau relasi-relasi
  • Table –struktur data dua dimensi

–          Tuples – baris atau record

–          Fields –kolom atau atribut

  • Tabel memiliki field kunci utama yang bisa digunakan untuk mengidentifikasi record yang unik
  • Kunci menghubungkan tabel antar tabel

Display parsial dari Tabel Basis Data Relasional, slide 10

Mendesain Basis Data Relasional

  • Buatlah tabel untuk tiap jenis entitas
  • Pilih atau temukan kunci utama (primary key) untuk tiap tabel
  • Tambahkan foreign key (kunci tamu) untuk menunjukkan hubungan satu ke banyak
  • Buatlah tabel baru untuk menunjukkan hubungan banyak ke banyak

Mendesain Basis Data Relasional (lanjutan)

  • Menentukan hambatan-hambatan integritas referensial
  • Mengevaluasi kualitas skema dan membuat pengembangan yang diperlukan
  • Memilih jenis data dan pembatasan nilai yang tepat (jika perlu) untuk tiap field

Data antar Relasi dalam Dua Tabel, lihat slide 13

RMO Entity-Relationship Diagram, slide 14

Menunjukkan Relasi

  • Basis Data relasional menggunakan foreign key untuk menunjukkan relasi
  • Relasi satu ke banyak

–          Menambah field kunci utama dari jenis entitas “satu”  sebagai foreign key dalam tabel yang menunjukkan jenis entitas “banyak”

  • Relasi banyak ke banyak

–          Menggunakan field kunci utama dari kedua jenis entitas

–          Menggunakan (atau membuat) tabel entitas asosiatif untuk menunjukkan relasi

Tabel Entitas dengan Kunci Utama

Tabel Atribut
Katalog IDKatalog, Sesi, Tahun, Deskripsi, TanggalEfektif, TanggalAkhir
ProdukKatalog IDProdukKatalog, Harga, HargaKhusus
Pelanggan NoAccount, Nama, AlamatPenagihan, AlamatPengiriman, NomorTelponSiang, NomorTelponMalam
ItemInventori IDInventori, Ukuran, Warna, Pilihan, KuantitasDiTangan, HargaRata-Rata, KuantitasPemesananKembali
Pesanan IDPesanan, TanggalPesan, KodePrioritas, PengirimanDanPenanganan, Pajak, GrandTotal, AlamatEmail, CaraBalas, ClerkTelpon, WaktuMulaiMenelpon, LamaMenelpon, TanggalDiterima, ClerkPemroses
ItemPesanan IDItemPesanan, Kuantitas, Harga, StatusBackOrder
TransaksiPesanan IDTransaksiPesan, Tanggal, JenisTransaksi, Jumlah, CaraPembayaran
ItemProduk IDProduk, Vendor, JenisKelamin, Keterangan
ItemPengembalian IDItemKembali, Kuantitas, Harga, Alasan, Syarat, Penyelesaian
Pengiriman NoTracking, Tanggalkirim, WaktuKirim, BiayaPengiriman, TanggalDatang, WaktuDatang
Pengirim IDPengirim, Nama, Alamat, ContactName, Telpon

Menunjukkan Relasi Satu ke Banyak dengan Menambahkan Kunci Tamu (yang dicetak miring)

Tabel Atribut
Katalog IDKatalog, Sesi, Tahun, Deskripsi, TanggalEfektif, TanggalAkhir
ProdukKatalog IDProdukKatalog, Harga, HargaKhusus
Pelanggan NoAccount, Nama, AlamatPenagihan, AlamatPengiriman, NomorTelponSiang, NomorTelponMalam
ItemInventori IDInventori, IDProduk,Ukuran, Warna, Pilihan, KuantitasDiTangan, HargaRata-Rata, KuantitasPemesananKembali
Pesanan IDPesanan, NoAccount, TanggalPesan, KodePrioritas, PengirimanDanPenanganan, Pajak, GrandTotal, AlamatEmail, CaraBalas, ClerkTelpon, WaktuMulaiMenelpon, LamaMenelpon, TanggalDiterima, ClerkPemroses
ItemPesanan IDItemPesanan, IDPesanan, IDInventori, NoTracking, Kuantitas, Harga, StatusBackOrder
TransaksiPesanan IDTransaksiPesan, IDPesanan, Tanggal, JenisTransaksi, Jumlah, CaraPembayaran
ItemProduk IDProduk, Vendor, JenisKelamin, Keterangan
ItemPengembalian IDItemKembali, IDPesanan, IDInventori, Kuantitas, Harga, Alasan, Syarat, Penyelesaian
Pengiriman NoTracking, IDPengirim, Tanggalkirim, WaktuKirim, BiayaPengiriman, TanggalDatang, WaktuDatang
Pengirim IDPengirim, Nama, Alamat, ContactName, Telpon

Menguatkan Integritas Referensial

  • Keadaan data base relasional konsisten
  • Setiap nilai kunci tamu juga exist (ada) sebagai nilai kunci utama
  • DBMS menguatkan integritas referensial secara otomatis setelah desainer skema mengidentifikasi kunci utama dan tamu

Penguatan Integritas Referensial DBMS

  • Apabila baris yang memiliki kunci tamu dibuat

–          DBMS memastikan bahwa nilai juga exist sebagai kunci utama dalam tabel yang direlasikan

  • Apabila baris dihapus

–          DBMS memastikan tidak ada kunci tamu dalam tabel relasi yang memiliki nilai sama dari baris yang dihapus

  • Apabila nilai kunci utama diubah

–          DBMS memastikan tidak ada nilai kunci tamu dalam tabel relasi yang memiliki nilai sama

Mengevaluasi Kualitas Skema

  • Model data kualitas tinggi memiliki

–          Keunikan baris tabel dan kunci utama

–          Kemudahan dalam mengimplementasikan perubahan model data yang akan datang (fleksibilitas dan dapat dimaintain/dipelihara)

–          Sedikit data yang redundansi (normalisasi basis data)

  • Desain basis data itu bukan objek atau tidak diukur secara kuantitaif; tapi berbasis pengalaman dan keputusan

Normalisasi Basis Data

  • Bentuk-bentuk normal meminimalisir redundansi data
  • Normal bentuk pertama (First normal form [1NF)) –tidak mengulang field atau grup field
  • Ketergantungan secara fungsional (Functional dependency) – hubungan satu ke satu di antara nilai dua field
  • 2NF – dalam 1NF dan jika tiap elemen yang bukan kunci secara fungsional tergantung pada semua kunci utama
  • 3NF—dalam 2NF dan jika tidak ada elemen yang bukan kunci secara fungsional tergantung pada elemen yang bukan kunci

Dekomposisi Tabel 1NF ke dalam Tabel-Tabel 2NF, slide 22

Konversi Tabel 2NF ke dalam Tabel 3NF, slide 23

Basis Data Berorientasi Objek

  • Ekstensi langsung dari paradigma desain dan pemrograman OO
  • ODBMS menyimpan data sebagai objek
  • Dukungan langsung untuk metode storage (penyimpanan), inheritance (warisan), objek bersarang, hubungan objek, dan jenis data yang ditentukan programmer
  • Object Definition Language (ODL)

–          Bahasa standar untuk mendeskripsikan struktur dan            konten basis data objek

Mendesain Basis Data Objek

  • Menentukan kelas mana yang membutuhkan penyimpanan terus menerus
  • Menetapkan persistent classes
  • Menunjukkan relasi antar persistent classes
  • Memilih jenis data dan pembatasan nilai yang tepat (jika perlu) untuk tiap field

Menunjukkan Kelas-Kelas

  • Transient classes (kelas sementara)

–          Objek exist hanya selama berjalannya (lifetime) program atau proses

–          Contoh: view layer window, pop-up menu

  • Persistent classes (kelas tetap)

–          Objek tidak rusah ketika program atau proses menghentikan eksekusi. Pernyataan yang harus diingat

–          Exist secara independen dari program atau proses

–          Contoh: informasi pelanggan, informasi pekerja

Menunjukkan Relasi

  • Object identifiers

–          Digunakan untuk mengidentifikasi objek-objek secara unik

–          Alamat atau referensi penyimpanan fisik

–          Menghubungkan objek-objek dari satu kelas ke kelas lain

  • ODBMS menggunakan atribut yang memuat object identifiers untuk menemukan objek-objek yang direlasikan ke objek lain
  • Kunci relasi bisa digunakan untuk menyatakan relasi antar kelas

Menentukan Relasi (lanjutan)

  • Keuntungan mencakup

–          ODBMS mengasumsikan responsibilitas untuk menentukan koneksi antar objek

–          ODBMS mengasumsikan responsibilitas untuk maintaining integritas referensial

  • Jenis relasi

–          1:1, 1:M, M:M (satu ke satu [one-to-one], satu ke banyak [one-to-many], banyak ke banyak [many-to-many])

–          Kelas asosiasi digunakan bersama M:M

RMO Domain Model Class Diagram, slide 29

Relasi Satu ke Satu Ditunjukkan dengan Atribut yang memiliki Object Identifiers, slide 30

Relasi Satu ke Banyak antar Pelanggan dan Order Classes, slide 31

Relasi Satu ke Banyak ditunjukkan dengan Atribut yang memiliki Object Identifiers, slide 32

Relasi Banyak ke Banyak antara Kelas Karyawan dan Proyek, slide 33

Hierarki generalisasi dalam RMO Class Diagam, slide 34

Desain Basis Data Relasional Objek Hybrid

  • RDBMS (hybrid DBMS) digunakan untuk menyimpan atribut dan relasi objek
  • Mendesain skema relasional yang lengkap dan secara bersamaan mendesain kelompok class yang equivalen
  • Mismatches (tidak sebanding) antara data relasional dan OO

–          Metode kelas tidak dapat disimpan secara langsung atau dieksekusi secara otomatis

–          Relasi terbatas dibandingkan dengan ODBMS

–          ODBMS bisa menunjukkan range jenis data yang lebih luas

Relasi

  • Relasi ditunjukkan dengan kunci tamu
  • Nilai kunci tamu melayani tujuan yang sama sebagai object identifiers dalam ODBMS
  • Relasi 1:M –menambah field kunci utama dari class di derajat “satu”  dari relasi tersebut ke tabel yang menunjukkan class dalam derajat “banyak”
  • Relasi M:M – membuat tabel baru yang memuat field kunci utama dari tabel-
  • tabel class relasi dan atribut relasinya

Data Access Classes

  • Desain OO berbasis pada arsitektur tiga layer
  • Data Access Classes jembatan implementasi di antara data yang disimpan dalam objek-objek program dan data dalam basis data relasional
  • Metode menambah, mengubah, mencari, dan menghapus field dan baris dalam tabel serta tabel-tabel yang  menunjukkan kelas
  • Logika enkapsulasi metode dibutuhkan untuk menyalin nilai-nilai data  dari domain class bermasalah ke basis data dan vice versa (kejahatan)

Interaksi antar domain class, data access class, dan DBMS, slide 40

Tipe Data

  • Format penyimpanan dan konten yang diperbolehkan dari variabel program, variabel object state, atau field basis data atau atribut
  • Tipe data primitif –diimplementasikan langsung

–          Alamat memori (pointer), Boolean, integer, dan sebagainya

  • Tipe data kompleks—ditentukan oleh user

–          Tanggal, waktu, suara audio, gambar video, URLs

Tipe Data DBMS Relasional

  • Designer harus memilih tipe data yang tepat untuk tiap field dalam skema basis data relasional
  • Pilihan untuk beberapa field jelas

–          Nama dan alamat menggunakan himpunan array karakter fixed-length atau variable-length

–          Kuantitas inventori dapat menggunakan integer

–          Harga barang dapat menggunakan angka-angka real

  • Tipe data kompleks (DATE, LONG, LONGRAW)

Sub bagian Tipe Data Oracle RDBMS, 43

Tipe Data DBMS Objek

  • Menggunakan himpunan tipe data primitif dan kompleks yang dapat dibandntanganingkan dengan tipe data RDBMS
  • Designer skema dapat membuat tipe data baru dan hambatan terkait
  • Class merupakan tipe data user-defined (ditentukan oleh pengguna) kompleks yang mengkombinasikan konsep tradisional dari data dengan proses-proses (metode-metode) untuk memanipulasi data
  • Fleksibilitas untuk menentukan tipe-tipedata baru merupakan satu alasan yang menyebabkan OO tools digunakan di mana-mana

Basis Data Terdistribusi

  • Jarang semua data organisasi disimpan dalam basis data tunggal dalam satu lokasi
  • Sistem informasi yang berbeda dalam sebuah organisasi dikembangkan dalam waktu yang berbeda
  • Bagian-bagian dari data organisasi memungkinan dimiliki dan dimanage oleh unit-unit yang berbeda
  • Kinerja sistem dikembangkan ketika data mendekati aplikasi-aplikasi utama

Arsitektur Server Basis Data Tunggal, slide 46

Arsitektur Server Basis Data Replikasi (Tiruan), slide 47

Membagi Skema Basis Data ke dalam Sub-Sub Bagian Akses Client, slide 48

Arsitektur Server Basis Data Partisi, slide 49

Arsitektur Server Basis Data Federasi (Digabungkan), slide 50

Arsitektur Server Basis Data Terdistribusi RMO

  • Memulai poin untuk desain adalah informasi tentang kebutuhan data dari para user yang tersebar secara geografis
  • RMO mengumpulkan informasi selama fase analisis
  • RMO dibuat untuk memanage basis data menggunakan mainframe pusat data Park City
  • RMO mengevaluasi single-server vs. Arsitektur server basis data partisi dan replikasi
  • Informasi pada lalu lintas jaringan dan biaya-biaya yang dibutuhkan

Arsitektur Server Basis Data Single-Server untuk RMO, slide 52

Arsitektur Server Basis Data Partisi dan Repliasi untuk RMO, slide 53

Rangkuman

  • Sistem informasi modern menyimpan data dalam basis data dan mengakses serta memanage data dengan menggunakan DBMS
  • DBMS relasional biasa digunakan
  • Object DBMS bertambah dalam popularitasnya
  • Aktivitas kunci dari desain sistem mengembangkan skema basis data relasional dan objek
  • Basis data relasional adalah kumpulan data yang disimpan dalam tabel-tabel dan dikembangkan dari diagram relasi entitas (entity-relationship diagram)

Rangkuman (lanjutan)

  • Basis data objek menyimpan data sebagai kumpulan objek-objek yang terhubung dan dikembangkan dari class diagram
  • Objek-objek bisa juga disimpan dalam RDBMS

–          RDBMS tidak dapat menyimpan metode-metode

–          RDBMS tidak dapat merepresentasikan inheritance (data warisan) secara langsung

  • Sistem informasi menengah dan besar secara khusus menggunakan berbagai basis data dan server-server basis data di berbagai lokasi geografis

One response to “MENDESAIN BASIS DATA

  1. Pingback: Archive for Satzinger -riandragon89

Leave a comment