bdbo

1

Buku1. ”Database Processing (Fundamental,

Design, and Implementation)”David M.Kroenke, Edisi ke-8, 1992

2. ”Object-Oriented Modeling and Design ForDatabase Aplications”M.Blaha and W.Premerlani, 1998

Sylabi1. Pengantar2. Model Objek-Semantik (O-S)3. Kesetaraan Semantic Object Models dengan

Relational Models4. Pemrosesan Basis Data Berorientasi Objek5. Membuat Semantic Object Models

menggunakan Tabledesigner

2

I.PENGANTAR

Model Data Relational DatabasesHirarchical DatabasesNetworks DatabasesObject-Oriented Databases

Design Using Model DataNormalization

Processing Single-UserMulti-UserEnterpriseObject-Oriented

3

II. MODEL OBJEK-SEMANTIK

2.1. Definisi Objek-Semantik

Objek Semantik adalah representasi dari

beberapa benda yang dapat diidentifikasi dalam

lingkungan kerja user.

Objek Semantik adalah himpunan attribute

yang menggambarkan suatu identitas yang jelas.

Contoh objek MAHASISWA dapat memiliki

attribute Nim, Nama, AlamatRumah,

AlamatKampus, TanggalLahir, TanggalLulus,

dan MataKuliah. Himpunan attribute ini harus

menyajikan semua karakteristik yang user

perlukan untuk menunjang pekerjaannya.

2.2. Attribute

Ada tiga jenis attribute yaitu simple attribute,

group attribute, dan semantic-object attribute.

4

Single attribute memiliki sebuah elemen

tunggal.

Contohnya TanggalSewa, NomorPermohonan,

dan BanyakPenjualan.

Group attribute adalah gabungan dua/lebih

single attribute, contohnya Alamat, FullName.

Attribute objek adalah attribute yang ber-

relasi dengan attribute objek milik objek

lainnya.

Perhatikan gambar 4-2(a) yang merupakan

contoh Diagram Objek-Semantik.

Objek JURUSAN berisi simple attribute

yaitu NamaJurusan, NomorTelepon, NomorFax,

juga berisi group attribute yaitu AlamatKampus,

serta memiliki attribute objek PERGUTING,

DOSEN, dan MAHASISWA.

5

2.3. Cardinality Attribute

Setiap attribute dalam suatu objek semantik

memiliki cardinality minimum dan maksimum.

Perhatikan gambar 4-2 (b), simple attribute

NamaJurusan memiliki cardinality 1.1 artinya

hanya satu nama yang dibutuhkan suatu

JURUSAN, simple attribute NomorTelepon

memiliki cardinality 1.N artinya JURUSAN

tersebut membutuhkan paling sedikit satu nomor

telepon, simple attribute NomorFax memiliki

cardinality 0.1 artinya JURUSAN hanya

memerlukan satu nomor fax kalau tidak ada

maka tidak apa-apa.

Group attribute AlamatKampus memiliki

cardinality 0.1 artinya JURUSAN tersebut boleh

tidak memiliki gedung (untuk VU boleh null)

atau hanya memerlukan satu alamat.

6

Cardinality untuk attribute objek

PERGUTING adalah 1.1 artinya suatu

JURUSAN hanya berada dalam satu perguruan

tinggi.

Cardinality untuk attribute objek DOSEN

adalah 1.N artinya bahwa JURUSAN tersebut

memerlukan minimal satu orang dosen.

Cardinality untuk attribute objek

MAHASISWA adalah 1.N artinya bahwa

JURUSAN tersebut minimal memiliki satu

orang mahasiswa.

2.4. Paired Attribute

Jika suatu objek berisi objek lain, maka objek

lain tersebut akan berisikan objek pertama.

Contoh, jika objek JURUSAN berisi attribute

objek-semantik PERGUTING, maka objek

7

PERGUTING juga akan berisi attribute objek

JURUSAN.

Attribute objek-semantik yang selalu

berpasangan ini disebut paired attributes.

Mengapa attribute objek harus berpasangan ?

jawabnya karena cara berpikir manusia

mengenai relationship. Jika objek A berrelasi

dengan objek B, maka objek B berrelasi dengan

objek A.

2.5. Object Identifier

Sebuah object identifier adalah satu/lebih

attributes yang user gunakan untuk

mengidentifikasi instances.

Contoh untuk objek CUSTOMER, identifier

yang mungkin adalah IDCustomer dan

NamaCustomer.

8

Contoh group identifier :

[FirstName, LastName], [FirstName,

PhoneNumber], dan [State, LicenseNumber].

Pada Diagram objek-semantik, identifier

ditandai oleh huruf ID di depan attribute. Jika

identifier tersebut unik, maka ID tersebut

digarisbawahi (ID).

Secara normal, jika ada attribute berperan

sebagai identifier, maka nilainya sangat

dibutuhkan (tidak boleh null).

Dalam banyak kasus, default dari cardinality

milik attribute ID adalah 1.1.

2.4. Domains Attribute

Domain milik sebuah attribute adalah

deskripsi nilai-nilai yang mungkin dari attribute

tersebut. Karakteristik dari suatu domain

bergantung pada jenis attribute.

9

Domain milik simple attribute adalah

deskripsi fisik maupun deskripsi semantik.

Deskripsi fisik menunjukkan tipe data,

panjang/ukuran data, dan constraint. Deskripsi

semantik menunjukkan kegunaan attribute.

Contoh domain NamaJurusan didefinisikan

”Himpunan String yang terdiri atas lebih dari 7

karakter, untuk menampung nama-nama jurusan

di Universitas Highline” jadi ”String yang

terdiri atas lebih dari 7 karakter” adalah

deskripsi fisik, sedangkan ”menampung nama-

nama jurusan di Universitas Highline” adalah

deskripsi semantik.

Dalam beberapa kasus, deskripsi secara fisik

milik domain suatu simple attribute adalah

enumerated list, himpunan nilai-nilai milik suatu

attribute.

10

Contoh domain milik attribute warna

misalnya [’Biru’, ’Kuning’, ’Merah’].

Domain milik suatu group attribute juga

terdiri dari deskripsi fisik dan deskripsi

semantik.

Contoh deskripsi fisik milik AlamatKampus

misalnya [’Gedung’, ’NomorKantor’], deskripsi

semantiknya ’menampung lokasi kantor jurusan

di Universitas Highline’.

Domain milik suatu attribute objek adalah

suatu himpunan yang berisi instance-instance

objek dari tipenya.

Contoh, pada diagram objek JURUSAN,

domain milik attribute objek DOSEN adalah

himpunan yang berisi semua instance-instance

objek DOSEN di dalam database. Domain milik

objek PERGUTING adalah himpunan yang

berisi semua PERGUTING di dalam database.

11

2.5. Semantic-Object View

Bagian dari suatu objek yang tampil untuk

diakses oleh suatu aplikasi disebut view.

Suatu view terdiri atas nama view dan daftar

semua attribute yang diakses suatu aplikasi.

Pertama, view digunakan saat merancang

database sebagai model data.

Kedua, view digunakan untuk mendukung

pembuatan form entry data, report, dan query

berdasarkan struktur databasenya.

User mengakses nilai-nilai milik attribute

objek melalui aplikasi database yang

menyediakan form entri data, report-report, dan

querys. Dalam banyak kasus, form entri data,

report-report, dan query tidak mengakses semua

attribute objek.

Contoh gambar 4-4 memperlihatkan dua

aplikasi yang mengakses objek JURUSAN.

12

Beberapa attribute milik JURUSAN (misal

NamaJurusan) tampil di dua aplikasi tersebut.

Attribute objek MAHASISWA hanya

diakses oleh aplikasi StudentListing.

Attribute objek DOSEN hanya diakses oleh

aplikasi StaffListing.

PR. Universitas Highline DataBase (hlm86-94)

2.6. Jenis-Jenis Objek

Simple object adalah objek yang hanya

memiliki simple attribute atau group

attribute, dan nilainya adalah single-value.

Contoh gambar 4-15(a) memperlihatkan dua

instance dari report Label Perlengkapan.

13

Label menandai item perlengkapan kantor

untuk membantu inventarisasi.

Perhatikan gambar 4-15(b) sebagai diagram

objek PERLENGKAPAN :

Semua attribute Objek PERLENGKAPAN

ini tidak ada yang memiliki multi-value.

LABEL PERLENGKAPAN

NoPerlengkapan 100 Deskripsi : Meja

TanggalTerima 2/27/2000 Harga $350.00

LABEL PERLENGKAPAN

NoPerlengkapan 200 Deskripsi:Lampu

TanggalTerima 3/1/2000 Harga $39.95

PERLENGKAPAN

ID NoPerlengkapan Deskripsi TanggalTerima Harga

14

Composite Object adalah objek yang

hanya memiliki simple attribute atau group

attribute, dan nilainya ada yang multi-value.

Gambar 4-16(a) memperlihatkan Hotel Bill

yang berupa composite object. Hotel Bill boleh

mengandung group attribute yang terdiri atas

ServiceDate, ServiceDescription, dan Price.

Instance seorang tamu dapat multi-value

milik group attribute nya, lihat gambar 4-16(a) :

GRANDVIEW HOTELInvoice Number : 1234 Arrival Date : 10/12/2001

Customer Name : Mary Jones

10/12/2001 Room $99.00 10/12/2001 Food $37.55 10/12/2001 Phone $ 2.50 10/12/2001 Tax $15.00

10/13/2001 Room $99.00 10/13/2001 Food $47.90 10/13/2001 Tax $15.00

Total Due $315.95

15

Gambar 4-16(b) memperlihatkan Diagram

Objek HOTEL-BILL. LineItem adalah group

attribute yang memiliki cardinality maksimum

n, artinya ServiceDate, ServiceDescription, dan

Price dapat terjadi berulang untuk seorang

instance milik objek HOTEL-BILL.

Gambar

4-16(b)

Sebuah composite object dapat memiliki

lebih dari satu attribute multi-value, seperti

gambar 4-17(a) attribute-attribute tersebut

adalah CustomerName dan biaya layanan-

layanan.

HOTEL-BILL

ID InvoiceNumber1.1 ArrivalDate1.1 ID CustomerName1.1 LineItem ServiceDate1.1 ServiceDescription1.1 Price1.1 0.N TotalDue1.1

16

Diagram objek dari instance tersebut :

Gambar

4-17(b)


Customer Name : Murry Jones Fred Jones Sally Jones

10/12/2001 Room $99.00 10/12/2001 Food $37.55 10/12/2001 Phone $ 2.50 10/12/2001 Tax $15.00

10/13/2001 Room $99.00 10/13/2001 Food $47.90 10/13/2001 Tax $15.00

Total Due $315.95

HOTEL-BILL

ID InvoiceNumber1.1 ArrivalDate1.1 ID CustomerName1.N LineItem ServiceDate1.1 ServiceDescription1.1 Price1.1 0.N TotalDue1.1

17

Simple attribute maupun group attribute

dapat memiliki multi-value, contoh instance

pada gambar 14-17(a).

Multi-value attribute dapat juga nested di

dalam attribute lainnya, contoh lihat instance

pada gambar 4-18(a).


Customer Name : Mary Jones

10/12/2001 Room $99.00 10/12/2001 Food

Breakfast $15.25 Dinner $22.30

$37.55 10/12/2001 Phone $ 2.50 10/12/2001 Tax $15.00

10/13/2001 Room $99.00 10/13/2001 Food

Breakfast $15.25 Snack $ 5.50 Dinner $27.15

$47.90 10/13/2001 Tax $15.00

Total Due $315.95

18

Diagram objek dari instance tersebut dapat

dilihat pada gambar 4-18(b).

Gambar

4-18(b)

Compound Object adalah objek yang

paling sedikit memiliki satu attribute objek

(boleh ditambah satu/dua jenis attribute lain)

namun nilai single attribute dan nilai group

attribute-nya adalah single-value.

Gambar 4-19(a) memperlihatkan dua form

entri data yang berbeda untuk suatu perusahaan.

HOTEL-BILL

ID InvoiceNumber1.1 ArrivalDate1.1 ID CustomerName1.N LineItem ServiceDate1.1 ServiceDescription1.1 Subdescription1.1 Subprice1.1 1.N LineItemPrice1.1 0.N TotalDue1.1

19

Form pertama digunakan untuk mengelola

data kendaraan dinas. Form kedua digunakan

untuk mengelola data karyawan.

Berdasarkan form-form tersebut, sebuah

kendaraan dipakai oleh seorang karyawan, dan

seorang karyawan memakai 0.1 kendaraan.

Gambar 4-19(b) memperlihatkan diagram

objek KARYAWAN dan diagram objek

KENDARAAN.

Objek KARYAWAN berisi KENDARAAN

sebagai salah-satu attribute nya, dan sebaliknya

objek KENDARAAN berisi KARYAWAN

sebagai salah-satu attribute nya. Karena kedua

objek mengandung object attribute, maka

keduanya adalah compound objects.

Relationship dari KARYAWAN ke

KENDARAAN adalah one to one.

20

Perhatikan juga contoh pada gambar 4-20(a)

yang merupakan instance dari form untuk report

penempatan mahasiswa ke asramanya,

sedangkan diagram objeknya dapat diperhatikan

pada objek ASRAMA dan objek MAHASISWA

pada gambar 4-20(b).

Gambar 4-20 tersebut merupakan contoh

Compound Object dengan relasi one to many.

Selanjutnya perhatikan contoh pada gambar

4-21(a) yang merupakan instance dari form

untuk report Stok Buku, sedangkan diagram

objeknya dapat diperhatikan pada objek BUKU

dan objek PENULIS, pada gambar 4-21(b).

Gambar 4-21 tersebut merupakan contoh

Compound Object dengan relasi many to many.

21

Hybrid Object adalah kombinasi dari

Composite Object dan Compound Object,

minimal memiliki satu sub-attribute objek

pada group attribute-nya yang nilainya

multi-value.

Gambar 4-23(a) adalah versi kedua dari form

report mengenai Penempatan Mahasiswa ke

Asrama. Berbeda dengan gambar 4-20(a) yang

kolom ketiga dari data mahasiswa adalah class,

pada gambar 4-23(a) ini kolom ketiga dari data

mahasiswa adalah Rent (berisi biaya sewanya).

Ini adalah perbedaan penting, karena Rent

bukanlah attribute milik object STUDENT

namun attribute milik DORMITORY

(perhatikan Rent terkait dengan object

STUDENT juga sebagai pembayar/penyewa).

22

Gambar 4-23(b) adalah diagram objek

sebagai model dari form report pada gambar 4-

23(a).

Gambar 4-23(c) adalah model yang salah

dari form report pada gambar 4-23(a), terlihat

bahwa attribute Rent dan objek attribute

STUDENT merupakan multi-value yang saling

independent (terpisah), salah karena attribute

Rent dan object attribute STUDENT adalah

multi-value sebagai pasangan saling bergantung.

Gambar 4-24(a) adalah form report Transaksi

Penjualan yang berbasis Hybrid Object. Form

Transaksi Penjualan berisi data mengenai suatu

transaksi (Nomor Transaksi Penjualan, Tanggal,

Subtotal, Pajak, dan Total), ditambah data

seorang CUSTOMER, kemudian data seorang

SALESPERSON, serta data mengenai

BARANG yang ditransaksikan.

23

Data BARANG (Nomor Barang, Deskripsi,

dan HargaUnit) memunculkan multi-value

group.

Gambar 4-24(b) memperlihatkan semantic

object model (diagram object) dari gambar 4-

24(a). Diagram objek ini ambiguous dari suatu

aspek bergantung pada aplikasinya.

Menurut diagram objek BARANG, sebuah

objek BARANG dapat direlasikan dengan lebih

dari satu objek TRANSAKSI-PENJUALAN.

Namun karena multi-value group LineItem

adalah hidden ke dalam objek TRANSAKSI-

PENJUALAN, maka menjadi tidak jelas apakah

sebuah objek BARANG dilibatkan sekali atau

berkali-kali dalam objek TRANSAKSI-

PENJUALAN.

Secara umum, ada empat interpretasi

cardinality maksimum untuk attribute yang

24

berpasangan dalam Hybrid Object

TRANSAKSI-PENJUALAN :

1. Sebuah objek BARANG dapat muncul

hanya satu kali pada objek TRANSAKSI-

PENJUALAN dan berada hanya dalam satu

LineItem.


hanya satu kali pada objek TRANSAKSI-

PENJUALAN namun berada dalam

LineItem yang berbeda-beda.


berkali-kali pada objek TRANSAKSI-

PENJUALAN namun berada hanya dalam

sebuah LineItem.


berkali-kali pada objek TRANSAKSI-

PENJUALAN dan berada dalam LineItem

yang berbeda-beda.

25

Jika salah satu dari kasus 1 atau 2 terjadi,

maka cardinality maksimum dari Hybrid Object

Attribute harus di set 1. Berdasarkan contoh

tersebut, maka cardinality maksimum dari

Hybrid Object Attribute TRANSAKSI-

PENJUALAN di dalam objek BARANG, harus

di set 1.

Jika sebuah objek BARANG muncul hanya

dalam sebuah attribute LineItem milik objek

TRANSAKSI-PENJUALAN (kasus 1), harus

ditandai sebagai ID yang unik dalam group

tersebut. Jika tidak (kasus 2) tidak perlu ditandai

sebagai ID.

Jika salah satu kasus 3 atau 4 terjadi, maka

cardinality maksimum dari Hybrid Object

attribute harus di set N. Berdasarkan contoh

tersebut, maka cardinality maksimum dari Hyrid

26

Object attribute TRANSAKSI-PENJUALAN di

dalam objek BARANG, harus di set N.

Jika sebuah objek BARANG muncul hanya

dalam sebuah attribute LineItem milik objek

TRANSAKSI-PENJUALAN (kasus 3), harus

ditandai sebagai ID yang unik dalam group

tersebut.

Jika tidak (kasus 4) tidak perlu ditandai

sebagai ID.

Association Object adalah sebuah objek

yang merelisasikan dua (atau lebih) objek

dan menyimpan data yang unik untuk

relationship tersebut.

Perhatikan gambar 4-26(a) yang memper-

lihatkan sebuah report dan dua form entri data

berdasarkan sebuah Association Object.

27

Report tersebut berisi display data sebuah

airline flight (penerbangan) dan data particular

airplane serta data pilotnya.

Dua form entri data untuk memasukkan data

pilot dan airplane.

Gambar 4-26(b) adalah gambar objek

FLIGHT berupa sebuah Association Object

yang menghubungkan objek AIRPLANE dan

objek PILOT serta menyimpan data gabungan-

nya.

Pada objek FLIGHT terdapat objek

AIRPLANE dan objek PILOT, kedua objek

tersebut mengandung multi-value milik

FLIGHT.

Associating yang melibatkan dua (atau lebih)

objek dengan data dari association tersebut

digunakan dalam aplikasi yang melayani tugas

dua atau lebih entity.

28

Contoh lain adalah Association Object JOB

yang menghubungkan objek ARCHITECT

dengan objek CLIENT, Assocition Object

TASK yang menghubungkan objek

EMPLOYEE dengan objek PROJECT, serta

Association Object PURCHASE-ORDER yang

menghubungkan objek VENDOR dengan Objek

SERVICE.

Contoh gambar 4-26, Association Object

FLIGHT memiliki sebuah identifier berupa

group attribute FlightID [FlightNumber, Date].

Association Object yang tidak memiliki

identifier sendiri, boleh membentuk identifier

dari kombinasi identifier objek-objek yang

direlasikan.

Perhatikan gambar 4-27(a) yang menyajikan

report dari Association Object ASSIGNMENT

29

yang menghubungkan objek ARCHITECT

dengan objek PROJECT.

Association Object ASSIGNMENT tidak

memiliki identifier, sehingga attribute

AssignmentID dapat menjadi identifier dengan

mengkombinasikan attribute ProjectName milik

objek PROJECT dengan attribute

ArchitectName milik objek ARCHITECT.

Gambar 4-27(b) menyajikan model (diagram

objek) dari instance untuk form pada gambar 4-

27(a).

PROJECT dan ARCHITECT adalah object

attributes yang tergabung dalam group attribute

AssignmentID pada Association Object

ASIGNMENT. AssignmentID merupakan

identifier dari objek ASSIGNMENT.

Catatan bahwa identifier AssignmentID pada

gambar 4-27(b) tidak unik, indikasinya bahwa

30

seorang arsitek mungkin dipesan lebih dari

sekali oleh sebuah proyek, dan seorang

karyawan pun boleh dipesan lebih dari sekali

oleh suatu proyek. Jika demikian agar identifier

attribute milik objek ASSIGNMENT menjadi

unik, maka attribute waktu (misal Date, Week,

atau lainnya) harus ditambahkan ke dalam group

attribute AssignmentID.

Parent Object dan SubType Object adalah

dua objek yang terhubung secara vertikal

karena SubType Object merupakan salah-

satu jenis (bentuk khusus) dari Parent

Object.

Perhatikan gambar 4-28(a), beberapa

attribute pada objek EMPLOYEE berasal dari

employees, dan attribute lainnya berasal dari

employee sebagai manager.

31

Pada gambar 4-28(a) attribute-attribute milik

objek MANAGER tidak cocok dengan attribute-

attribute milik objek EMPLOYEE non manager.

Model yang lebih baik diperlihatkan pada

gambar 4-28(b), Parent Object EMPLOYEE

berisi attribute berupa SubType Object

MANAGER. Semua attribute yang berasal dari

manajer, dipindahkan ke objek MANAGER.

Employee non Manager memiliki satu

instance dari objek EMPLOYEE namun tidak

memiliki instance dari objek MANAGER.

Employee sebagai Manager memiliki satu

instance dari objek EMPLOYEE dan satu

instance dari objek MANAGER.

Objek boleh memiliki lebih dari satu attribute

yang berupa SubType Object. Gambar 4-29

menyajikan objek EMPLOYEE yang memiliki

32

dua attribute sebagai SubType Object yaitu

MANAGER dan PROGRAMMER, artinya :

Ada EMPLOYEE yang bukan MANAGER dan

bukan PROGRAMMER,

Ada EMPLOYEE yang juga menjadi

MANAGER atau PROGRAMMER,

Ada EMPLOYEE yang juga menjadi menjadi

MANAGER maupun PROGRAMMER.

Kadang-kadang SubType exclude satu

dengan yang lainnya, misal Parent Object nya

VEHICLE dapat berbentuk AUTO atau

TRUCK, namun tidak keduanya.

Parent Object CLIENT dapat menjadi salah-

satu dari INDIVIDUAL atau PARTNERSHIP

atau CORPORATION.

Ketika SubType Object exclude satu dengan

lainnya, maka SubTypes tersebut ditempatkan

33

ke dalam sebuah SubType group, dengan format

cardinality x.y.z.

x adalah cardinality minimum di luar

SubType Attribute bernilai 0 atau 1,

y dan z dihitung dari banyaknya attribute di

dalam group.

y jumlah minimum yang dibutuhkan.

z jumlah maksimum yang dibutuhkan.

Gambar 4-30(a) memperlihatkan tiga jenis

CLIENT sebagai sebuah SubType Object group

dengan cardinality 0.1.1, maksud SubType

Object group ini tidak ada tidak apa-apa, namun

jika ada, minimum bernilai 1 dan maksimum

bernilai 1, SubType Object harus ada di dalam

group attribute. Masing-masing SubType Object

memiliki cardinality 0.ST, maksudnya bahwa

semua SubType tersebut optional keberadaan-

nya.

34

Jika semua SubType Object diperlukan,

maka maks cardinality nya adalah 3 bukan 1.

Notasi ini cukup mendukung kondisi 3 dipilih

dari 5, atau 7 dipilih dari 10, berdasarkan daftar

SubType Object yang diperlukan.

SubType Object group pada gambar 4-30(b)

memodelkan situasi yang mana SubType Object

CORPORATION haruslah salah-satu dari

TAXABLE_CORP / NONTAXABLE_CORP,

dan NONTAXABLE_CORP haruslah salah-satu

GOV_AGENCY atau SCHOOL.

ArcheType Object adalah objek yang

menghasilkan objek lainnya (Version Object)

yang berupa versi, release, atau edisi dari

ArcheType nya.

Contoh gambar 4-31, ArcheType Object

TEXTBOOK menghasilkan Version Object

EDITION (of TEXTBOOK).

35

EditionID group pada Version Object

EDITION terdiri atas dua attribute yaitu

ArcheType Object TEXTBOOK, dan simple

attribute EditionNumber yang mengidentifikasi

vesi dari ArcheType.

36

III. KESETARAAN OBJECT MODELS

TERHADAP RELATIONAL MODELS

Cara terbaik untuk belajar masalah ini

dengan contoh dan membanding-bandingkan

contoh-contoh tersebut.

Pada bagian ini, disajikan cara tranformasi

tersebut dengan diagram-diagram standard.

Kelemahan model objek sama dengan model E-

R yaitu mengabaikan masalah normalisasi.

Kesetaraan Simple Object

Gambar 7-1 mengilustrasikan transformasi

sebuah simple object ke dalam sebuah relasi.

Simple object adalah objek yang hanya

memiliki simple attribute atau group

attribute, dan nilainya adalah single-value.

37

Jadi simple attribute tidak memiliki multi-

value attribute dan juga tidak memiliki object

attribute.

Konsekuensinya, simple object disajikan oleh

relasi tunggal.

Perhatikan gambar 7-1 (a) dan 7-1 (b).

PERLENGKPAN(NoPerlengkapan, Deskripsi, TanggalTerima, Harga)

Composite Objects

Composite Object adalah objek yang

hanya memiliki simple attribute atau group

attribute, dan nilainya ada yang multi-value.

Gambar 7-3 (a) memperlihatkan contoh

composite object, HOTEL-BILL. Untuk

PERLENGKAPANID NoPerlengkapan Deskripsi TanggalTerima Harga

38

menyajikan objek ini, relasi pertama dibuat dari

objek dasar HOTEL-BILL, dan relasi kedua

dibuat dari repeating group attribute yaitu

DailyCharge. Perhatikan pula gambar 7-3 (b).

Pada gambar tersebut, attribute

InvoiceNumber digarisbawahi dalam relasi

DAILY-CHARGE, karena merupakan bagian

dari kunci pada DAILY-CHARGE, dan

InvoiceNumber ditulis dengan font italic karena

attribute ini juga merupakan foreign key.

Attribute ChargeDate digarisbawahi karena

attribute ini merupakan bagian dari kunci pada

DAILY-CHARGE.

Perhatikan pula gambar 7-4 (a) dan 7-4 (b)

yang menggambarkan transformasi secara lebih

umum.

39

Compound Objects

Compound Object adalah objek yang

paling sedikit memiliki satu attribute objek

(boleh ditambah satu/dua jenis attribute lain)

namun nilai single attribute dan nilai group

attribute-nya adalah single-value.

Penyajian relational dari compound object

mirip dengan penyajian entitas.

Pada bab sebelumnya, objek bernama

OBJECT1 dapat berisi satu atau lebih instances

milik objek lain bernama OBJECT2, dan

OBJECT2 dapat berisi satu atau lebih instances

milik OBJECT1.

Relationship dari OBJECT1 ke OBJECT2

dapat 1:1, 1:N, atau N:M.

Menyajikan One-To-One Compound Objects

40

Gambar 7-6 adalah dua objek pada club

kesehatan.

Sebuah LOCKER dialokasikan ke satu

MEMBER, dan setiap MEMBER memiliki satu

dan hanya satu LOCKER.

Gambar 7-6 (a) memperlihatkan diagram

objek. Untuk menyajikan objek-objek ini

dengan relasi, kita buat satu relasi untuk tiap

objek, kemudian entity-relationship 1:1 dibuat

dengan cara menempatkan suatu attribute kunci

pada salah satu relasi ke relasi lain. Jadi

tempatkan attribute kunci milik MEMBER ke

LOCKER, atau sebaliknya menempatkan

attribute kunci milik LOCKER ke MEMBER.

Perhatikan gambar 7-7, yang memperlihatkan

transformasi secara lebih umum.

Menyajikan One-To-Many danMany-To-One Compound Objects

41

Gambar 7-8 (a) memperlihatkan contoh

relationship objek 1:N antara EQUIPMENT

dengan REPAIR. Sebuah alat dapat belum

pernah direparasi atau sudah pernah direparasi

satu kali atau lebih. Sedangkan proses reparasi

(untuk suatu faktur) dilakukan hanya terhadap

satu alat.

Kedua objek dalam gambar 7-8 (a) disajikan

oleh relationship pada gambar 7-8 (b).

Perhatikan bahwa attribute kunci milik objek

sisi one relationship ditempatkan pada objek sisi

many relationship.

Perhatikan pula gambar 7-9 yang memper-

lihatkan transformasi secara umum.

Menyajikan Many-To-Many Compound Object

Sebagaimana M:N entity relationship, akan

didefinisikan tiga relasi, relasi pertama dan

42

kedua merupakan kesetaraan masing-masing

objek, dan relasi ketiga adalah intersection

relation.

Intersection relation memperlihatkan

relationship dari dua objek, relasi ini hanya

berisi attribute-attribute kunci kedua objek.

Gsambar 7-10 (a) memperlihatkan M:N

relationship antara BOOK dan AUHTOR.

Gambar 7-10 (b) memperlihatkan tiga relasi

hasil transformasi objek BOOK, objek

AUTHOR, dan BOOK-AUTHOR-INT.

Kedua attribute pada BOOK-AUTHOR-INT

yaitu ISBN dan SocialSecurityNumber

digarisbawahi serta ditulis dengan font italic.

Perhatikan pula gambar 7-11 yang

memperlihatkan transformasi secara umum.

Cermati bahwa pada R3 hanya memiliki

attribute Q1 dan Q2, bagi M:N compound

43

objects, R3 tidak pernah berisi data non kunci,

bandingkan dengan transformasi dari

association objects.

Hybrid Objects

Hybrid Object adalah kombinasi dari

Composite Object dan Compound Object,

minimal memiliki satu sub-attribute objek

pada group attribute-nya yang nilainya

multi-value.

Hybrid objects dapat ditransformasikan ke

relational design menggunakan kombinasi

teknik composite objects dan compound objects.

Gambar 7-12 (a) memperlihatkan Hybrid

Object yang bernama SALES-ORDER dan

object-object lain yang direlasikan. Untuk

menyajikan tranformasi ini maka tentukan

model relasi untuk hybrid object dan relasi-

44

relasi lain untuk masing-masing objek yang

terkandung yaitu CUSTOMER dan

SALESPERSON, perhatikan untuk kasus ini

tidak ada M:N relationship Compound Objects.

Kemudian sebagaimana Composite Object,

tentukan model relasi untuk multi-value group

attribute, yaitu LineItem. Karena LineItem

adalah group attribute yang mengandung object

ITEM, maka tentukanlah pula model relasi

untuk objek ITEM, semua one-to-many

relationship disajikan dengan menempatkan

kunci milik parent relation ke dalam child

relation, perhatikan gambar 7-12 (a).

Contoh dalam gambar 7-12 adalah gambar

hybrid object beserta transformasinya, objek ini

memiliki empat kasus seperti dicantumkan pada

gambar 7-13.

45

Kasus 3 dan 4 lebih umum dibanding kasus 1

dan 2. OBJECT1 seperti diperlihatkan pada

gambar 7-14, memiliki dua group; Group1

mengilustrasikan kasus 3 dan Group 2

mengilustrasikan kasus 4.

Group1 memiliki cardinality maksimum N,

artinya banyak instance milik Group1 dalam

OBJECT1. Jadi OBJECT2 berperan sebagai

sebuah identifier Group1 dalam OBJECT1.

OBJECT2 ditandai sebagai ID yang unik,

artinya OBJECT2 muncul hanya dalam salah-

satu instance Group1 dalam OBJECT1.

(SALES-ORDER pada gambar 7-12

mengilustrasikan ini. ITEM adalah sebuah

identifier milik LineItem, sehingga suatu ITEM

muncul hanya pada satu instance LineItem

dalam sebuah ORDER tertentu. Namun suatu

ITEM dapat muncul pada banyak ORDER).

46

Perhatikan OBJECT1 sebagai Hybrid

Object. Model relational untuk objek ini dapat

diperlihatkan dalam gambar 7-14. Sebuah model

relasi R1 dibuat untuk OBJECT1, dan model

relasi R2 untuk OBEJCT2. Kemudian dibuat

model relasi R-G1 untuk group attribute Group1

(tidak ada attribute G1 di Group1). Cardinality

milik relationship antara R1 dan R-G1 adalah

1:N, sehingga kunci milik R1 yaitu Q1 harus

ditempatkan ke dalam R-G1 sebagai foreign

key; cardinality milik relationship antar R1 dan

R-G2 adalah 1:N, sehingga kunci milik R2 yaitu

Q2 harus pula ditempatkan ke dalam R-G1

sebagai foreign key. OBJECT2 muncul hanya

sekali bersama suatu nilai milik OBJECT1,

composite (Q1,Q2) unik dalam R-G1, sehingga

dapat menjadi kunci model relasi tersebut.

47

OBJECT3 tidak mengindentifikasi Group2,

sehingga OBJECT3 dapat muncul dalam banyak

instance milik objek yang sama yaitu OBJECT1.

(SALES-ORDER dalam gambar 7-12 akan

seperti ini jika ITEM bukan ID dalam LineItem.

Maksudnya sebuah ITEM dapat muncul berkali-

kali dalam ORDER yang sama).

Karena OBJECT3 bukan identifier milik

Group2, maka diasumsikan bahwa attribute lain

seperti G2 dapat menjadi identifier.

Dalam gambar 7-14, dibuat model relasi R3

untuk OBJECT3 dan model relasi R-G2 untuk

Group2.

Cardinality milik relationship antara R1

dengan R-G2 adalah 1:N, sehingga kunci milik

relasi R1 yaitu Q1 harus ditempatkan ke dalam

R-G2 sebagai foreign key.

48

Cardinality milik relationship antara R3

dengan R-G2 juga 1:N, sehingga kunci milik

relasi R3 yaitu Q3 harus ditempatkan pula ke

dalam R-G2 sebagai foreign key.

Tidak seperti Group1, pasangan attribute

(Q1,Q3) tidak dapat menjadi kunci R-G2 karena

tidak unik (dapat muncul berkali-kali). Sehingga

kunci model relasi R-G2 harus (Q1,G2).

Association Objects

Association Object adalah sebuah objek

yang merelisasikan dua (atau lebih) objek

dan menyimpan data yang unik untuk

relationship tersebut. Ini adalah kasus khusus

dari Compound Object.

Gambar 7-15 (a) memperlihatkan objek

FLIGHT yang menghubungkan sebuah

AIRPLANE dengan seorang PILOT.

49

Cara transformasi association object ke

model relasi, sederhana yaitu buatlah model

relasi untuk tiap objek (tiga relasi untuk tiga

objek), kemudian buatlah pula relationship

antara objek-objek tersebut menggunakan salah-

satu cara pada Compound Objects. Perhatikan

gambar 7-15 (b), satu model relasi untuk objek

AIRPLANE, satu lagi model relasi untuk objek

PILOT, dan satu lagi model relasi untuk objek

FLIGHT. Cardinality milik relationship antara

objek FLIGHT dan objek AIRPLANE adalah

1:N, dan antara objek FLIGHT dan objek

PILOT juga 1:N, sehingga harus ditempatkan

kunci milik objek AIRPLANE ke dalam objek

FLIGHT, dan kunci milik objek PILOT

ditempatkan pula ke dalam objek FLIGHT.

Objek FLIGHT memiliki primary key

sendiri, dan kedua foreign key bukanlah bagian

50

dari kunci milik objek FLIGHT. Namun jika

objek FLIGHT tidak memiliki kunci sendiri,

maka kuncinya dibuat dari kombinasi kedua

foreign key digabung dengan salah-satu attribute

milik objek FLIGHT, misal dalam contoh ini

[TailNumber, PilotNumber, Date].

Perhatikan gambar 7-16 yang memperlihat-

kan transformasi struktur association object ke

dalam model relasi recara lebih umum.

OBJECT3 menghubungkan OBJECT1

dengan OBJECT2, ketiganya ditransformasikan

menjadi model relasi R3, R1, dan R2. Kunci-

kunci milik setiap parent relation, yaitu Q1 dan

Q2, harus ditempatkan ke dalam model relasi

R3 sebagai foreign key. Jika association object

tidak memiliki attribute yang unik, maka

kombinasi dari attribute-attribute milik model

51

relasi R1 dan model relasi R2, dapat menjadi

identifier yang unik.

Perbedaan antara association relation pada

gambar 7-16 dengan intersection relation pada

gambar 7-11 adalah tidak ada attribute

tambahan pada intersection relation kecuali

hanya ada foreign key.

Parent/SubType Objects

Parent Object dan SubType Object adalah

dua objek yang terhubung secara vertikal

karena SubType Object merupakan salah-

satu jenis (bentuk khusus) dari Parent

Object.

Transformasi dari model objek ke model

relational dilakukan dengan cara membuat

sebuah model relasi untuk Parent Object dan

model relasi lainnya untuk setiap SubType

52

Object. Kunci milik relasi dari setiap SubType

Object tersebut diturunkan dari kunci milik

relasi dari Parent Object.

Gambar 7-17 (a) memperlihatkan sebuah

Parent Object yaitu Person, dan dua SubType

Objects yaitu STUDENT dan PROFESSOR.

Gambar 7-17 (b) memperlihatkan model

relational dari ketiga model objek tersebut.

Perhatikan dalam model-model tersebut, kunci

dari semua relasi (id dari semua objek) adalah

sama.

Masih dalam gambar 7-17 (b), program

aplikasi masih mencari di relasi STUDENT dan

relasi PROFESSOR untuk menentukan jenis

PERSON. Jika masukan tersebut ditemukan

dalam relasi STUDENT, maka person tersebut

adalah seorang student, namun jika masukan

ditemukan dalam relasi PROFESSOR, maka

53

person tersebut adalah seorang professor,

sehingga hal tersebut menyebabkan kelambatan

dalam menentukan katagori seorang person.

Untuk mengatasi kelambatan ini, maka perlu

ditambahkan attribute yang menjadi indikator

jenis person dari instance yang ditempatkan

dalam relasi Parent.

Gambar 7-17 (c) memperlihatkan indikator

jenis. Variasi pertama adalah relasi PERSON1,

dan kemungkinan nilai attribute PersonType

adalah salah satu dari ’STUDENT’ atau

’PROFESSOR’. Variasi kedua adalah relasi

PERSON2. dan kemungkinan nilai attribute

StudentType serta attribute ProfessorType,

adalah true/false.

Secara umum, rancangan model relasi

PERSON1 lebih baik jika SubType nya adalah

mutually exclusive, sebaliknya rancangan model

54

relasi PERSON2 lebih baik jika SubType nya

tidak exclusive.

Skema umum untuk menyajikan SubType

Objects diperlihatkan pada gambar 7-18. Satu

model relasi untuk Parent Object sedangkan

model relasi lainnya untuk setiap SubType

Object nya.

Kunci semua model relasi yang termasuk

dalam struktur dari satu parent adalah kunci

milik parent object. Semua relationship antara

parent object dan subtype object adalah 1:1.

Format group cardinality r.m.n (required,

minimum, maksimum) maksudnya :

r adalah nilai boolean yaitu 0 atau 1 tergantung

pada apakah subtype group diperlukan/tidak.

m adalah kuantitas minimum subtype yang

harus memiliki value di dalam group.

55

n adalah kuantitas maksimum subtype yang

harus memiliki value di dalam group.

Contoh suatu group memiliki lima subtypes

misal memiliki cardinality 1.2.4 maksudnya

adalah subtype group tersebut diperlukan,

minimum dua subtypes yang harus memiliki

value, dan maksimum empat subtypes yang

harus memiliki value.

ArcheType/Version Objects

ArcheType Object adalah objek yang

menghasilkan objek lainnya (Version Object)

yang berupa versi, release, atau edisi dari

ArcheType nya.

Objek-objek dalam gambar 7-19 (a)

memodelkan variasi produk perangkat lunak

beserta variasi releasenya.

56

Contoh variasi produk adalah Microsot

Internet Explorer dan Netscape Navigator.

Contoh variasi release adalah Accsess 200

dan Access 2002.

Model relational untuk objek PRODUCT dan

objek RELEASE diperlihatkan pada gambar 7-

19 (b). Satu model relasi untuk objek

PRODUCT dan model relasi lainnya untuk

objek RELEASE.

Kunci dari relasi RELEASE adalah

kombinasi dari kunci relasi PRODUCT dan

attribute lain (local key) yang membentuk

objected milik RELEASE tersebut, dalam

contoh ini adalah ReleaseNumber.

Gambar 7-20 memperlihatkan transformasi

ArcheType Object dan Version Object ke dalam

model relational.

57

Attribute Q1 dari R2 adalah local key sekaligus

foreign key, namun Q2 adalah attribute yang

hanya local key. Kedua local key ini

membentuk objectID milik model relasi R2.

58

IV. PEMROSESAN OODB

Penyimpanan data dengan Relational

Database dalam bentuk tabel, baris, dan kolom.

Relational Database tidak cocok untuk

menyimpan objek-objek, sebab objek dapat

mengandung item-item data yang memiliki

struktur yang kompleks dan juga dapat

mengandung pointer-pointer ke objek lain. Lagi

pula di dalam objek ada statement-statement

yang executable atau methods. Agar objek

presistence maka harus dapat menyimpan

method-method tersebut dengan baik.

Tujuan OODBMS dikembangkan pada awal

1990 untuk menyediakan penyimpanan objek

yang persistence. Produk-produk ini belum

suskses secara komersil, karena memerlukan

konversi data yang ada menjadi format

59

OODBMS. Organisasi-organisasi terpaksa

melakukan konversi walaupun mahal.

OOP membutuhkan penyimpanan objek yang

persistence. Sehingga beberapa DBMS

tradisional menambah kemampuan produknya

agar mampu menyimpan objek sebaik

penyimpanan data yang relational. Produk ini

disebut Object-Relational DBMS, misalnya

Oracle yang telah mengembangkan fasilitas-

fasilitas untuk pemodelan dan penyimpanan

objek.

Persistance Objek

Gambar 18-4 adalah struktur data yang ada

setelah objek ORDER di create. Objek ORDER,

terdiri atas ORDER.Number, ORDER.Date, dan

ORDER.Total, sedangkan repeating group

LINEITEM memiliki ItemNumber, ItemName,

60

Quantity, QuantityBackOrdered, dan

ExtendedPrice. Sebagai tambahan, base order

data memiliki pointer ke objek CUSTOMER,

pointer ke objek SALESPERSON, dan pointer

ke tiap ITEM untuk setiap LineItem. Pointer-

pointer ini adalah bagian dari data objek

ORDER.

Agar objek tersebut persistence, maka semua

data harus disimpan (dalam storage). Kemudian,

meskipun struktur objek CUSTOMER,

SALESPERSON, dan ITEM tidak diketahui,

namun tetap harus disimpan (dalam storage).

Objek CUSTOMER dan objek SALESPERSON

juga menyimpan pointer ke objek ORDER.

Pointer-pointer menjadi problem tersendiri.

pada kebanyakan bahasa berorientasi objek,

pointer berbentuk alamat dalam memori.

Beberapa diantaranya hanya valid selama

61

eksekusi program, jika program berakhir

kemudian restart, maka alamat-alamat objek

akan berubah. Karena itu, ketika suatu objek

disimpan, pointer-pointer dalam memori

tersebut perlu ditransformasikan ke dalam

sebuah identifier unik yang permanen, proses

tersebut akan valid selama lifetime objek, dan

masih dalam memori. Proses transformasi

pointer menjadi identifier permanen dari alamat-

alamat dalam memori disebut swizzling,

kemudian panggil kembali objek tersebut yang

didefinisikan sebagai nilai-nilai data dan

method-methodnya, terakhir simpan nilai-nilai

objek dan method-methodnya.

Tidak seperti nilai-nilai data, setiap objek

dalam suatu class memiliki method-method

yang sama, jadi method-method tersebut

62

disimpan (dalam storage) hanya sekali untuk

semua instance objek dalam class.

Proses persistence objek dapat dirangkum :

1. Save nilai-nilai data instance objek.

2. Convert pointer-pointer objek dalam

memori menjadi identifier unik dan

permanen (swizzling).

3. Save method-method class milik objek

tersebut.

Ada tiga cara menyimpan objek di storage :

1. Menggunakan File Storage yg tradisional

2. Menggunakan RDBMS/R-ODBMS

3. Menggunakan ODBMS

Persistence Objek Menggunakan File Storage

Objek dapat disimpan menggunakan file

storage yang tradisional, namun pekerjaan ini

menjadi beban besar bagi programmer.

63

Perhatikan data pada gambar 18-4. Developer

harus membuat file pertama untuk diisi method-

method semua objek, kemudian membuat file

kedua untuk diisi data semua objek.

Gambar 18-6 adalah contoh sebuah file yang

menyimpan item-item data, file berikutnya perlu

dibuat untuk menyimpan method-methodnya.

Beberapa tahun terakhir masalah-masalah

tersebut telah memiliki solusi dalam sistem

operasi khususnya pada subsistem pemrosesan

file. Namun pemrograman menjadi lambat,

membosankan, mengandung resiko, dan sulit.

Penggunaan file storage tradisional memang

mendukung persistence objek, namun hanya

ketika aplikasi memiliki beberapa simple object

yang strukturnya statis. Beberapa aplikasi bisnis

termasuk dalam katagori ini.

64

Persistence Objek Menggunakan R-ODBMS

Pendekatan kedua ini menyebabkan beban

developer lebih kecil dibanding pendekatan

pertama, sebab masalah manajemen file dasar

seperti alokasi record, indexing, manajemen

space, dan yang lainnya sudah ditangani oleh

DBMS.

Tugas manajemen data masih ditangani

programmer untuk :

Membuat struktur relasional,

Menyajikan objek-objek tersebut,

Menulis kode utk interfacing dgn DBMS,

Mendapatkan/meletakkan objek,

Melakukan swizzling thd pointer-pointer.

Gambar 18-7 memperlihatkan tabel-tabel

yang dibutuhkan untuk menyimpan (storing)

objek ORDER, LINEITEM, CUSTOMER,

SALESPERSON, dan ITEM. Disain ini telah

65

ditinjau sebelumnya, hal yang baru adalah tabel

untuk menyimpan (storing) method-method

objek, tabel ini mengandung sebuah field memo

yang menyimpan kode method.

Database Relasional menyajikan relationship

menggunakan foreign key. Maksudnya bahwa

programmer aplikasi harus menemukan cara

menggunakan foreign key untuk membuat

relationship yang persistent. Cara yang paling

umum membuat relationship yang persistent

adalah membuat kode untuk constructor objek

dengan ID yang unik. ID ini dapat disimpan

(dalam storage) dalam objek yang berbasis tabel

dan diekspose sebagai property yang read-only.

Objek-objek lain yang membutuhkan link ke

objek ini dapat menyimpan nilai ID tersebut.

Strategi tersebut masih menyisakan masalah

ketika objek tersebut di destroy, sehingga semua

66

objek yang link ke objek tersebut harus

diberitahu dapat me remove pointernya, segera

setelah objek tersebut di destroy.

Pemikiran dan perancangan yang berorientasi

objek mestinya melupakan relationship dalam

konteks. Misal, ketika sebuah objek ORDER

assign ke sebuah objek SALESPERSON, ini

adalah relationship. Juga ketika objek ORDER

ingin mengikat banyak objek SALESPEOPLE,

ini juga relationship. Namun objek ORDER

tidak memikirkan apakah sebuah objek

SALESPERSON memiliki relationship ke one

or many ORDER. Pengetahuan seperti itu di-

encapsulasikan ke dalam objek

SALESPERSON, dan bukan bagian dari

pemikiran objek ORDER.

Karakteristik tersebut menguntungkan atau

tidak bergantung pada bagaimana hal itu

67

dipikirkan. Misalkan sebuah objek ORDER

dapat memiliki beberapa SALESPEOPLE dan

sebuah objek SALESPERSON dapat memiliki

banyak ORDER. Dalam bahasa database,

ORDER dan SALESPERSON memiliki

relationship M:N. Konsekuensinya dalam

relational database harus dibuat tabel

intersection yang berisi dua identifier dari kedua

objek tersebut.

Dalam dunia objek, SALESPERSON tahu ia

memiliki banyak ORDER, dan ORDER tahu ia

memiliki SALESPEOPLE, namun mereka tidak

saling mengetahui. Sehingga yang menyebabkan

relationship terpisah adalah struktur data.

ORDER akan berisi simpanan banyak link ke

SALESPERSON, dan SALESPERSON akan

berisi simpanan banyak link ke ORDER.

68

Masing-masing himpunan link akan saling

terisolasi.

Kondisi tersebut menjadi masalah? jawabnya

tidak selama tidak ada error saat pemrosesan

objek. Namun ada resiko, karena link-link objek

walaupun terpisah namun tidak independent.

Jika 1000 ORDER di link ke SALESPERSON

A, maka secara definisi, SALESPERSON A

juga terhubung (is linked) ke 1000 ORDER.

Dalam dunia relational DBMS, relationship

dibawa ke sebuah baris dalam tabel intersection,

penghapusan (deleting) baris tersebut dari satu

sisi, secara otomatis akan menghapus baris

tersebut di sisi lainnya.

Namun dalam dunia objek, relationship dapat

dihapus (deleted) dari satu sisi. Jadi 1000

ORDER harus dihubungkan (linked) ke

SALESPERSON A, namun SALESPERSON A

69

tidak harus dihubungkan (linked) ke 1000

ORDER.

Jelasnya, error ini mestinya tidak boleh

terjadi, namun ini bisa terjadi jika relationship

yang didefinisikan, berasal dari perspektif

object-oriented murni.

Penggunaan Relational DBMS bagi

persistence objek memang mengurangi

pekerjaan developer dibanding penggunaan

struktur file tradisional. Namun masih ada

pekerjaan developer yaitu konversi model objek

ke dalam model relasional, menulis SQL (atau

kode lain), mendapatkan dan menempatkan

objek-objek menggunakan RDBMS, dan

melakukan swzzling. ODBMS dirancang untuk

menyempurnakan tugas-tugas tersebut.

70

Persistence Objek Menggunakan ODBMS

Alternatif ketiga persistence objek adalah

menggunakan ODBMS.

ODBMS dirancang untuk diintegrasikan

dengan bahasa berorientasi-objek. Sehingga

SQL perlu di embedde ke dalam kode aplikasi.

Sebagai contoh dalam gambar 18-4, yang

menyimpan (hasil embedded) adalah method

yang disediakan oleh ODBMS. Jadi kalau

programmer mengakses method tersebut, berarti

juga mengakses ODBMS.

Produk-produk ODBMS meng-include-kan

compiler yang memproses source code dan

secara otomatis membuat struktur data dalam

object database.

Jadi tidak seperti relational database atau file

processing, O-O programmer tidak perlu

mentransform objek ke dalam relational atau

71

dalam struktur file; ODBMS melakukan

semuanya secara otomatis.

ODBMS dirancang untuk persistence objek,

sehingga beberapa bentuk swizzling dibangun di

dalamnya. Jadi kode seperti pada gambar 18-3

akan membuat masalah-masalah yang terjadi

tidak disadarikan oleh developer. Suatu objek

bisa memiliki link (yang tetap valid) ke objek

lain, Jika link memiliki bentuk yang berbeda,

maka program aplikasi tidak menyadarinya.

Beralih ke karakteristik ODBMS yang

disebut single-level memory. Dengan

menggunakan ODBMS, OO programmer tidak

perlu mengetahui apakah suatu objek berada

dalam memori atau tidak.

Jika 1000 ORDER memiliki sebuah link ke

SALESPERSON A,

72

maka 1000 ORDER dapat menggunakan

properti-properti SALESPERSON A yang

diekspose tanpa perlu mengecek data tersebut

berada dalam memory atau issuing a read atau

statement SQL.

Jika objek SALESPERSON A berada dalam

memori, maka ODBMS membuatkan link

tersebut; namun jika objek SALESPERSON A

tidak berada dalam memori, maka ODBMS

membaca SALESPERSON A (tempatkan) ke

dalam memori dan kemudian membuat link nya.

Gambar 18-8 membandingkan pekerjaan tiga

cara persistence objek, perhatikan bahwa

ODBMS menyediakan keuntungan yang

substansial bagi OO programmer.

73

Gambar 18-8 :ODBMS RDBMS Pemrosesan File Tradisional

MintakanODBMSmenyimpanmethod-method

Convertalamat-alamatmemori ke IDyg permanendan sebaliknya(swizzling)

Swizzling

Buat strukturdata relasional

Buat struktur data file

Buat SQL (dankode lainnya)

Buat kode persistence objek

Embed SQL kedalam program

Panggil kode persistenceobjekPack and unpack objek kedalam struktur fileTemukan objek-objekberdasarkan permintaaanKelola ruang fileTugas manajemen filelainnya

bdbo

Documents