Buku 1. Database Processing (Fundamental, Design, and Implementation) David M.Kroenke, Edisi ke-8, 1992 2.

Object-Oriented Modeling and Design For Database Aplications M.Blaha and W.Premerlani, 1998 Sylabi 1. Pengantar 2. Model Objek-Semantik (O-S) 3. Kesetaraan Semantic Object Models dengan Relational Models 4. Pemrosesan Basis Data Berorientasi Objek 5. Membuat Semantic Object Models menggunakan Tabledesigner

I.PENGANTAR Model Data Relational Databases Hirarchical Databases Networks Databases Object-Oriented Databases Using Model Data Normalization Single-User Multi-User Enterprise Object-Oriented

Design

Processing

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.

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 berrelasi 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.

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.

Cardinality PERGUTING

untuk adalah

attribute 1.1 artinya

objek 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

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.

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.

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 namanama 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.

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.

10

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.

11

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.

12

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 Label menandai item perlengkapan kantor untuk membantu inventarisasi. Perhatikan gambar 4-15(b) sebagai diagram objek PERLENGKAPAN : PERLENGKAPAN ID NoPerlengkapan Deskripsi TanggalTerima Harga Semua attribute Objek PERLENGKAPAN ini tidak ada yang memiliki multi-value.
13

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 HOTEL
Invoice Number : 1234 Customer Name : Mary Jones Arrival Date : 10/12/2001

10/12/2001 10/12/2001 10/12/2001 10/12/2001 10/13/2001 10/13/2001 10/13/2001

Room Food Phone Tax Room Food Tax

$99.00 $37.55 $ 2.50 $15.00 $99.00 $47.90 $15.00

Total Due $315.95

14

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.
HOTEL-BILL ID InvoiceNumber1.1 ArrivalDate1.1 ID CustomerName1.1 LineItem ServiceDate1.1 ServiceDescription1.1 Price1.1 0.N TotalDue1.1

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 layananlayanan.

15

GRANDVIEW HOTEL
Invoice Number : 1235 Customer Name : Murry Jones Arrival Date : 10/12/2001

Fred Jones Sally Jones 10/12/2001 10/12/2001 10/12/2001 10/12/2001 10/13/2001 10/13/2001 10/13/2001 Room Food Phone Tax Room Food Tax $99.00 $37.55 $ 2.50 $15.00 $99.00 $47.90 $15.00

Total Due $315.95

Diagram objek dari instance tersebut :

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

Gambar 4-17(b)

16

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).
GRANDVIEW HOTEL
Invoice Number : 1234 Customer Name : Mary Jones Arrival Date : 10/12/2001

10/12/2001 10/12/2001

10/12/2001 10/12/2001 10/13/2001 10/13/2001

Room $99.00 Food Breakfast $15.25 Dinner $22.30 $37.55 Phone $ 2.50 Tax $15.00 Room $99.00 Food Breakfast $15.25 Snack $ 5.50 Dinner $27.15 $47.90 Tax $15.00 Total Due $315.95

10/13/2001

17

Diagram objek dari instance tersebut dapat dilihat pada gambar 4-18(b).
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

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.

18

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, keduanya adalah compound objects. Relationship dari KARYAWAN ke maka

KENDARAAN adalah one to one.

19

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.

20

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 Rent milik terkait DORMITORY dengan object

(perhatikan

STUDENT juga sebagai pembayar/penyewa).

21

Gambar 4-23(b) adalah diagram objek sebagai model dari form report pada gambar 423(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.

22

Data BARANG (Nomor Barang, Deskripsi, dan HargaUnit) memunculkan multi-value

group. Gambar 4-24(b) memperlihatkan semantic object model (diagram object) dari gambar 424(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 TRANSAKSIPENJUALAN, maka menjadi tidak jelas apakah sebuah objek BARANG dilibatkan sekali atau berkali-kali PENJUALAN. Secara umum, ada empat interpretasi dalam objek TRANSAKSI-

cardinality maksimum untuk attribute yang

23

berpasangan

dalam

Hybrid

Object

TRANSAKSI-PENJUALAN : 1. Sebuah objek BARANG dapat muncul hanya satu kali pada objek TRANSAKSIPENJUALAN dan berada hanya dalam satu LineItem. 2. Sebuah objek BARANG dapat muncul hanya satu kali pada objek TRANSAKSIPENJUALAN namun berada dalam

LineItem yang berbeda-beda. 3. Sebuah objek BARANG dapat muncul berkali-kali pada objek TRANSAKSI-

PENJUALAN namun berada hanya dalam sebuah LineItem. 4. Sebuah objek BARANG dapat muncul berkali-kali pada objek TRANSAKSI-

PENJUALAN dan berada dalam LineItem yang berbeda-beda.

24

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

25

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 memperlihatkan sebuah report dan dua form entri data berdasarkan sebuah Association Object.

26

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 gabungannya. Pada objek FLIGHT terdapat objek

AIRPLANE dan objek PILOT, kedua objek tersebut FLIGHT. Associating yang melibatkan dua (atau lebih) objek dengan data dari association tersebut digunakan dalam aplikasi yang melayani tugas dua atau lebih entity. mengandung multi-value milik

27

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

28

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 427(a). PROJECT dan ARCHITECT adalah object attributes yang tergabung dalam group attribute AssignmentID ASIGNMENT. pada Association Object

AssignmentID

merupakan

identifier dari objek ASSIGNMENT. Catatan bahwa identifier AssignmentID pada gambar 4-27(b) tidak unik, indikasinya bahwa

29

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 salahsatu 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.

30

Pada gambar 4-28(a) attribute-attribute milik objek MANAGER tidak cocok dengan attributeattribute 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

31

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 salahsatu dari INDIVIDUAL atau PARTNERSHIP atau CORPORATION. Ketika SubType Object exclude satu dengan lainnya, maka SubTypes tersebut ditempatkan

32

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 keberadaannya.

33

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).

34

EditionID

group

pada

Version

Object

EDITION terdiri atas dua attribute yaitu ArcheType Object TEXTBOOK, dan simple attribute EditionNumber yang mengidentifikasi vesi dari ArcheType.

35

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 ER 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.

36

Jadi simple attribute tidak memiliki multivalue attribute dan juga tidak memiliki object attribute. Konsekuensinya, simple object disajikan oleh relasi tunggal. Perhatikan gambar 7-1 (a) dan 7-1 (b).
PERLENGKAPAN ID NoPerlengkapan Deskripsi TanggalTerima Harga 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
37

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 relasi

InvoiceNumber

digarisbawahi

dalam

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.

38

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

39

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 dan Many-To-One Compound Objects

40

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 memperlihatkan transformasi secara umum.

Menyajikan Many-To-Many Compound Object Sebagaimana M:N entity relationship, akan didefinisikan tiga relasi, relasi pertama dan

41

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

42

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-

43

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.

44

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 salahsatu 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).

45

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.

46

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 berkalikali 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.

47

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.

48

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 salahsatu 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

49

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 memperlihatkan 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. Kuncikunci 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

50

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 salahsatu 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

51

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

52

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

53

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.

54

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.

55

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 719 (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.

56

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.

57

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

58

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 fasilitasfasilitas 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,

59

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. Pointerpointer 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

60

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 alamatalamat 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

61

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 memori pointer-pointer menjadi objek unik dalam dan

identifier

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.

62

Perhatikan data pada gambar 18-4. Developer harus membuat file pertama untuk diisi methodmethod 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.

63

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

64

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

65

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 diencapsulasikan SALESPERSON, ke dan dalam bukan bagian objek dari

pemikiran objek ORDER. Karakteristik tersebut menguntungkan atau tidak bergantung pada bagaimana hal itu

66

dipikirkan. Misalkan sebuah objek ORDER dapat memiliki beberapa SALESPEOPLE dan sebuah objek SALESPERSON dapat memiliki banyak ORDER. Dalam bahasa database, ORDER relationship relational dan SALESPERSON Konsekuensinya harus dibuat memiliki dalam tabel

M:N. database

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.

67

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

68

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 persistence Relational memang DBMS bagi

objek

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.

69

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

70

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,

71

maka

1000

ORDER

dapat

menggunakan A yang

properti-properti

SALESPERSON

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 keuntungan bahwa yang

ODBMS

menyediakan

substansial bagi OO programmer.

72

Gambar 18-8 :
ODBMS Mintakan ODBMS menyimpan methodmethod RDBMS Convert alamat-alamat memori ke ID yg permanen dan sebaliknya (swizzling) Buat struktur data relasional Buat SQL (dan kode lainnya) Embed SQL ke dalam program Pemrosesan File Tradisional Swizzling

Buat struktur data file Buat kode persistence objek Panggil kode persistence objek Pack and unpack objek ke dalam struktur file Temukan objek-objek berdasarkan permintaaan Kelola ruang file Tugas manajemen file lainnya

73