SURVEY TRANSFORMASI DESAIN BASIS DATA BERBASIS ENTITY-RELATIONSHIP MODEL

SURVEY TRANSFORMASI DESAIN BASIS DATA BERBASIS ENTITY-RELATIONSHIP MODEL

Penerjemah: Komarudin Tasdik. 2011. http://komarudintasdik.wordpress.com. Sumedang

Identitas Paper: Christian Fahrner and Gottfried Vossen. 1995. A Survey of Database Design Transformations Based on the Entity-Relationship Model. Elsevier

Abstrak

Sekarang, Entitas-Relationship (ER) model merupakan paradigma yang sangat penting untuk desain basis data konseptual. Sejak model itu diperkenalkan dalam mid-seventies, sebuah kumpulan besar literatur telah dipublikasikan pada transformasi skema-skema atau diagram-diagram ER konseptual ke dalam model-model data logis. Tujuan paper ini adalah untuk melakukan survey literatur ini. Fokus pertama adalah pada pendekatan-pendekatan transformasi dari ER model ke model-model data logis , yakni ke model relasional, jaringan, atau hirarkis; kemudian ini diimplementasikan dengan sebuah pembahasan transformasi-transformasi yang lebih baru menuju model-model berorientasi objek. Fokus kedua adalah pada pertimbangan proses reverse engineering, yakni transformasi-transformasi dari kekuatan model logis ke dalam ER model; akhirnya, sebuah gambaran umum tentang transformasi-transformasi langsung di antara berbagai model data logis yang dipresentasikan.

Keywords: Conceptual database design (desain basis data konseptual); Entity-Relationship modeling; Schema transformations (transformasi skema); Reverse engineering

  1. Pendahuluan

Entity-Relationship (ER) model, mula-mula diusulkan oleh Chen pada tahun 1976 [22], telah memperoleh penerimaan luas dalam bidang desain basis data dan bidang-bidang terkait. Sebuah alasan untuk ini adalah kesederhanaan dan kejelasan struktur konsep-konsepnya, yang memungkinkan para pengguna memodelkan objek-objek dunia nyata dan hubungannya dengan cara alami. Dalam desain basis data, ER model biasanya dikerjakan pada fase desain konseptual, yang bertujuan untuk memperoleh pandangan global independen sistem tentang aplikasi yang ada untuk basis data yang sedang dibangun. Setelah ER diagram, hasil desain konseptual, telah diperoleh, seorang desainer basis data harus mentransformasi itu ke dalam model data logis dari sistem target. Banyak pendekatan yang telah diusulkan di masa lalu untuk menyelesaikan tugas ini; tujuan paper ini adalah untuk melakukan survey terhadap pendekatan-pendekatan seperti itu.

Konsep-konsep transformasi ER model  ke dalam model data lainnya kembali ke karya Chen [22], yang menunjukkan bahwa ER model memungkinkan dengan mudah memetakan  ke dalam model-model data tradisional, meliputi model relasional, jaringan, dan hirarkis. Ini telah membuat ER model menjadi tool yang sangat populer untuk desain basis data konseptual; saat ini, beberapa tool desain berpusat di sekitar ER model yang bahkan secara komersial tersedia [88], dan yang lainnya masih dalam pengembangan [4]. Penemuan lainnya yang segera dibuat setelah pengenalan model itu adalah bahwa   formalism ER benar-benar menghasilkan framework konseptual di mana sejumlah aspek desain dapat ditangkap (di-capture). Ini telah mengarah pada sejumlah ekstensi model asli dan sebagai konsekuensinya untuk sejumlah proposal transformasi ekstensi seperti itu ke dalam model data komersial. Sebagai hasilnya, literatur dalam bidang ini sekarang sangat banyak, dan menjadi sulit bagi seorang desainer basis data untuk memilih versi ER model yang sesuai bersamaan dengan teknik-teknik transformasi yang relevan. Sebagai contoh, versi berbeda dari gagasan penggunaan model itu dinamai sama, tapi memiliki definisi formal yang berbeda seperti semantik yang berbeda. Juga, sejumlah besar simbol grafis untuk menunjukkan konsepsi ER telah diajukan, yang dapat membingungkan seorang desainer basis data.

Pada paper ini, kami melakukan survey bagian-bagian penting literatur yang relevan dalam bidang ini. Kami melakukannya dengan membuat deskripsi ER model dalam penggunaan seumum mungkin untuk alasan kemudahan dalam pemahaman. Perhatian pertama kami adalah pada yang disebut transformasi forward engineering, yakni transformasi klasik yang digunakan dalam desain basis data. Tentu saja, kami melakukan survey pada sejumlah pendekatan yang berbeda untuk mengubah (convert) ER diagram ke dalam sekam basis data salah satu model data tradisional, di mana sebuah perhatian diletakkan pada transformasi ke dalam model relasional; transformasi ke dalam model hirarkis atau jaringan hanya dibuatkan sketsa untuk alasan-alasan kelengkapan. Sedangkan basis data berbasis dua model terakhir yang peran pentingnya berkurang saat ini, ada perhatian yang muncul dalam penggunaan teknik-teknik ER untuk mendesain basis data berorientasi objek. Dengan demikian, kami juga mendeskripsikan cara-cara transformasi dari ER ke model data berorientasi objek (OO). Sehingga seperti yang terlihat, pendekatan-pendekatan yang sangat relevan diusulkan sesuai dengan sistem OO khusus, yang dapat dijelaskan dengan fakta bahwa standar biasa dalam bidang ini, proposal ODMG-93 [21] baru-baru ini dipublikasikan, dan nilai komersilnya diharapkan hanya selama pertengahan 1995.

Perhatian kedua dari survey kami adalah pada proses sebaliknya reverse engineering, yakni transformasi-transformasi dari suatu model logis kembali ke dalam formalisme ER model. Reverse engineering juga dari peran pentingnya yang bertambah saat ini, untuk contoh dalam konteks penggunaan sistem warisan bersama dengan jenis sistem basis data baru, atau migrasi dari tradisional ke sistem yang lebih baru. Secara spesifik, kami melakukan survey pada teknik-teknik reverse engineering yang berpusat di sekitar tradisional seperti model-model data berorientasi objek, yaitu pusat dalam konteks ini, tapi tidak jelas untuk cerita secara keseluruhan (tentu saja, reverse engineering idealnya juga mengambil informasi yang disediakan dengan program-program aplikasi yang ada atau minimal query-query SQL [104] ke dalam account, yang tidak dipertimbangkan di sini). Akhirnya, kami mempertimbangkan cara-cara untuk melakukan convert skema dalam salah satu model ini secara langsung ke dalam skema dalam model seperti itu lainnya, tanpa kembali ke deskripsi ER. Seperti untuk transformasi forward engineering, kami di sini fokus juga pada transformasi heterogen yang melibatkan model-model relasional dan berorientasi objek untuk alasan-alasan sama di atas. Di sisi lain, penting bahwa transformasi langsung skema jaringan atau hirarkis ke dalam skema berorientasi objek tidak terlihat exist.

Gambaran umum pengorganisasian paper ini tampak pada Gambar 1, di mana label tanda panah menunjukkan bagian-bagian yang relevan. Detilnya, pengorganisasian paper ini sebagai berikut: Bagian 2 merupakan pengenalan singkat tentang proses desain basis data dan untuk berbagai arahan di mana transformasi dapat terjadi pada prose situ. Bagian 3 menetapkan properties karakteristik transformasi berbeda yang dievaluasi;   ini menghasilkan sejenis framework ke dalam pendekatan-pendekatan yang dibahas dalam paper ini akan dibuat. Pada Bagian 4 kami membahas transformasi forward engineering, dalam transformasi tertentu dari ER model ke model data logis. Pada Bab 5 kami membahas pendekatan-pendekatan untuk schemata basis data secara langsung dari satu model logis ke model yang lain. Kami mengungkapkan eksposisi dalam Bagian 4-6 tidak lengkap di mana kami fokus pada mendeskripsi pendekatan-pendekatan untuk forward dan reverse engineering yang kami anggap penting, tapi masih ada sejumlah paper tambahan yang memberikan kontribusi minor untuk subjek ini. Akhirnya, Bagian 7 mempresentasikan beberapa konklusi yang kami peroleh dari studi ini.

  1. Desain Basis Data

Tugas umum desain basis data adalah memetakan aplikasi dunia nyata yang ada ke dalam model data formal dari sistem manajemen basis data yang ada. Kami mengasumsikan pembaca memiliki pemahaman umum tentang desain basis data, contohnya selama line-line Batini, dkk. [5], Elmasri dan Navathe  [36], atau Vossen [105]. Pada bagian ini, kami secara singkat mengklarifikasi berbagai langkah yang harus dilaksanakan ketika melakukan desain basis data. khususnya, kami menganggap langkah penting untuk convert deskripsi konseptual aplikasi yang ada ke dalam deskripsi logis; tambahan pula, kami secara singkat membahas transformasi yang berhubungan dengan converse direction. Akhirnya, kami tunjukkan mengapa pemetaan langsung di antara model-model logis itu cukup menarik perhatian.

Menurut Batini, dkk. [5], desain basis data secara kasar dapat dilihat sebagai proses langkah empat seperti tampak pada Gambar 2. Input untuk proses desain basis data biasanya merupakan varietas informasi dalam berbagai bentuk, contohnya tekstual, formal, atau semi-formal, yang mungkin muncul dari wawancara-wawancara dengan para pengguna yang berpotensi, proses desain terdahulu, basis data desain sebelumnya, dll. Tujuannya adalah untuk berproduksi dari skema basis data yang diproses dengan sistem manajemen basis data. Pada langkah pertama, analisis kebutuhan (requirement analysis), semua informasi dibutuhkan untuk memodelkan aplikasi yang diinginkan secara tepat dikoleksi dan dianalisis. Tujuan utamanya adalah untuk mengumpulkan kebutuhan data, yakni datat tentang apa yang ingin pengguna simpan, bagaimana ini bisa tersusun, bagaimana ia saling berhubungan. Dengan selalu berhubungan, input langkah ini adalah kebutuhan data dalam berbagai bentuk, contohnya bahasa alami (natural language), bentuk (forms), format rekaman (record formats), atau tampilan (views). Output adalah kebutuhan dalam suatu bentuk yang terstruktur, yang merepresentasikan abstraksi pertama dari aplikasi dasar.

Pada langkah kedua, skema konseptual dibuat, menggambarkan struktur independensi basis data sistem dasar. Model konseptual digunakan untuk menggambarkan skema konseptual. Yang sangat umu saat ini adalah penggunaan Entity-Relationship (ER) model pada tahap langkah ini, tapi model semantik lainnya bisa menjadi bagus. Pada langkah ketiga, skema konseptual itu ditransformasikan ke dalam skema logis yang ditetapkan dengan model logis, walaupun ada ketertarikan yang meningkat dalam model logis lebih tinggi, terutama model berorientasi objek. Pada langkah keempat dan terakhir, skema fisik berasal dari skema logis, yang secara kasar menggambarkan implementasi basis data dalam penyimpanan sekunder. Sturktur penyimpanan dan path akses untuk file-file basis data ditetapkan guna mencapai performa yang baik untuk aplikasi yang ada. Langkah ini tergantung pada sistem dasar dan transaksi yang digambarkan untuk basis data.

Secara paralel untuk data-driven design, function-driven design ini [5] dapat dijalankan untuk memodelkan operasi-operasi dan transaksi-transaksi yang harus diproses pada basis data. Proses desain ini mulai dengan koleksi pemrosesan kebutuhan dan berakhir dengan spesifikasi program aplikasi. Berbagai teknik dapat digunakan untuk mendukung desain ini melibatkan HIPO (Hierarchical Input Process Output) atau Petri nets; details dihilangkan. Jelasnya, desain data dan desain fungsional benar-benar saling terkoneksi. Deskripsi detil dari keduanya dan hubungannya dapat ditemukan, contohnya, di Batini, dkk. [5] atau Elmasri dan Navathe [36].

Pada survey ini, kami berkonsentasi pada Lankan 3, yang sering disebut forward engineering transformation. Tambahan untuk forward design, saat ini banyak perhatian exist dalam proses yang berlawanan, biasanya dimasukkan di bawah istilah reverse engineering. Di sini, titik permulaan itu merupakan deskripsi basis data yang ada, dan tujuannya adalah untuk memperoleh deskripsi konseptual dari aplikasi yang sedang menjadi pertimbangan. Motivasi untuk reverse engineering itu bermacam-macam, contohnya untuk menggunakan kembali desain basis data yang ada, untuk migrasi dari satu sistem basis data ke yang lainnya, atau untuk memeperoleh pandangan konseptual tentang aplikasi yang dimodelkan dalam sebuah basis data. dengan demikian, reverse engineering dalam basis data tidak hanya merupakan inverse sederhana dari forward engineering sebelumnya, tapi merupakan proses yang mencoba untuk memperoleh semantik sebuah aplikasi dari abstraksi yang dimodelkan dalam objek-objek dan hubungannya dengan bantuan model data semantik.

Sejak ketertarikan dalam pengerjaan reverse engineering pada basis data masih baru, masih belum ada strategi yang diterima untuk melakukannya. Tentu saja, hanya sedikit publikasi menginvestigasi teknik-teknik reverse engineering yang mudah diaplikasikan untuk model (sumber) yang berbeda; contohnya, Hainaut, dkk. [44, 45, 46] mengusulkan secara umum, prosedur langkah dua untuk reverse engineering (bandingkan dengan Gambar 3): Pada langkah pertama – Ekstraksi Struktur Data – deskripsi lengkap tentang skema sumber yang dihasilkan dengan memperoleh informasi yang secara implisit hanya ada dalam deskripsi basis data, contohnya dalam konten basis data, dalam program aplikasi, atau dalam views. Langkah ini dapat terlihat sebagai inverse desain fisik. Pada langkah kedua – Konseptualisasi Struktur Data – struktur-struktur skema logis dianalisis dan disusun kembali terlbih dahulu kemudian ditransformasikan ke dalam struktur-struktur model target semantik. Langkah ini dapat dilihat sebagai inversi desain logis.

Perbedaan penting di antara forward dan reverse engineering adalah yang terakhir secara khusus membutuhkan interaksi pengguna, sedangkan yang terdahulunya sangat bisa diotomatisasi. Terdapat berbagai alasan untuk ini, yakni sebagai berikut [45, 46, 85, 86]:

  • Informasi tentang struktur dan semantik skema sumber sering tidak diberikan secara eksplisit dalam deskripsi skema tersebut, tapi secara implisit dalam program-program aplikasi. Semantik yang terakhir adalah kesulitan untuk mengekstraksi sebuah program.
  • Konsepsi pemodelan model data sumber sering secara semantic overload dengan respek terhadap konsepsi model target semantik. Ini berarti bahwa struktur yang ada dalam skema sumber itu bisa sering diinterpretasikan dan ditransformasikan ke dalam struktur model target yang berbeda.
  • Struktur skema sumber dapat dioptimisasi untuk alasan-alasan performa. Dengan demikian, struktur relasi bisa menjadi sulit untuk melakukan discover dan interpretasi.

Konsekuensinya, reverse engineering sering membutuhkan suatu bentuk pengayaan semantik skema basis data yang ada (yang disebut  ekstraksi struktur data di atas); lihat juga [19, 39]. Pendekatan-pendekatan yang relevan akan dibahas lebih detil pada Bagian 5.

Di samping dua arah transformasi yang sudah banyak kita bahas, pada arah top-down untuk forward atau arah bottom-up untuk reverse engineering, pendekatan ketiga untuk transformasi model data adalah secara langsung beroperasi pada level model logis (nyata/distinct). Transformasi jenis ini dikonfrontasikan dengan masalah-masalah serupa seperti yang ditemukan pada forward atau reverse engineering. Justifikasinya adalah bahwa aspek-aspek struktural model-model tradisional memiliki banyak commonalities (penggunaan komponen yang sama), sehingga sering menyebabkan upaya tambahan tidak dapat diterima untuk menggunakan E-R model sebagai intermediate model, yang membutuhkan pengayaan semantik, walaupun secara langsung pemetaan berawal dari satu model logis ke model logis lainnya.

  1. Properties Transformasi

Sebelum kami memulai pada deskripsi detil tentang transformasi yang digunakan dalam desain basis data konseptual dan logis, kami mengumpulkan sejumlah properties dengan transformasi mana yang dapat  dievaluasi dan dibandingkan. Tentu saja, tiap pendekatan untuk salah satu arah transformasi yang disebutkan lebih awal memiliki karakteristik dan properties sendiri, contohnya mencakup prakondisi yang dibutuhkan atau metodologi transformasi yang dikerjakan. Kami sekarang melakukan survey pada properties itu yang sangat relevan untuk eksposisi kami dalam bagian-bagian berikut.

  • ER model yang digunakan: Sebagaimana kami telah sebutkan pada Pendahuluan, banyak ekstensi untuk struktur-struktur pemodelan ER model asli Chen [22] pada waktu itu telah diusulkan, mencakup ECR-model [36], ECR+model [94], HERM [100], atau EER-model [99]. Mereka sebagian besar berbeda dalam struktur-struktur yang didukung, contohnya struktur generalisasi, atribut kompleks, agregasi, dan relasi atas relasi. Definisi formal konsepsi kompleks, bahkan jika mereka dinamai sama, terustama berbeda dari satu model ke model berikutnya; di sisi lain, akhirnya semantik konseptual sering kali dinamai konsepsi sama.
  • Prasyarat transformasi: banyak algoritma membutuhkan skema sumber agar berada dalam bentuk khusus, contohnya dinormalisasi dengan suatu cara, atau untuk memenuhi syarat-syarat khusus, contohnya nama unik dari atribut. Kadang-kadang sehimpunan constrain integritas dibutuhkan untuk diberikan sebagai prasyarat; contohnya, pendekatan reverse engineering relasional sering berdasarkan pada sekolompok lengkap dari dependensi-dependensi inklusi, kunci, atau constrain kunci tamu.
  • Constrain integritas: deskripsi khusus yang secara khusus memuat constrain integritas yang inherent, implisit dan eksplisit [36]. Beberapa pendekatan transformasi mengambil semua ini ke dalam account, sementara yang lain menganggapnya hanya secara parsial, atau mengabaikannya sama sekali.
  • Keterlibatan pengguna: kontrasnya forward engineering, reverse engineering dan transformasi heterogen di antara model logis sering kali membutuhkan interaksi pengguna. Sejumlah interaksi pengguna tergantung pada jenis heuristik yang diaplikasikan dan pada asumsi yang dibuat.
  • Operasi: mengambil operasi-operasi yang harus diproses pada basis data di atas skema target ke dalam account selama translasi dapat meningkatkan performa. Mempertimbangkan kebutuhan pemrosesan penting terutama untuk model-model di mana desain logis dan fisik sulit dipisahkan, seperti model hirarkis dan jaringan. Dalam model relasional, optimisasi dengan respek terhadap operasi-operasi sering dikerjakan dalam langkah ekstra setelah transformasi, yakni dalam fase desain fisik. Aspek ini hanya bagian dari kepentingan untuk transformasi ke dalam sebuah model logis.
  • Pemeliharaan informasi: tujuan (dan pada kesulitan waktu yang sama) dari semua transformasi skema adalah untuk mengconvert skema dalam model data sumber ke dalam sebuah skema dengan kapasitas informasi yang sama [5, 48, 50, 65, 73, 102] dari model target. Secara formal, ini berarti bahwa semua contoh basis data yang mungkin bisa direpresentasikan dalam skema sumber bisa juga direpresentasikan dalam skema basis data target dan sebaliknya. Jika sebuah transformasi memenuhi property ini, disebut infroamation preserving. Jika konsepsi pemodelan abstraksi semantik tinggi tidak dapat direpresentasikan secara langsung, atau disimulasikan melalui struktur-struktur dan constrain-constraint integritas dari model target itu, menjadi sulit memnuhi property ini; ini bahkan dimungkinkan jika informasi structural dan constrain integritas dilupakan dalam program-program aplikasi. Seperti yang terlihat, hanya sedikit pendekatan mengambil masalah kebenaran ke dalam account.
  • Kualitas skema yang dihasilkan: terdapat beberapa kriteria kualitas skema yang dapat didefinisikan untuk skema-skema dalam model yang berbeda. Tiga model yang yangat penting untuk ER model [5] adalah correctness, minimality, dan normality. Sebuah skema benar jika semua konsep model dasar digunakan secara tepat dengan respek terhadap sintaks dan semantik. Sebuah skema minimal jika semua redundansi telah dihapus darinya, dan normal jika memenuhi salah satu bentuk normal yang sudah terkenal. Kriteria lain mencakup readability, self-explanation, dan extensibility. Jelasnya kriteria kualitas ini bisa juga didefinisikan untuk skema-skema dalam model-model lainnya. Harus dikatakan bahwa isu kualitas hasil transformasi  sering diabaikan, terutama dalam reverse transformations.
  • Metodologi transformasi: Tiap transformasi secara khusus memiliki metodologi yang berbeda. Dengan demikian, transformasi-transformasi untuk arah khusus kadang-kadang dapat diklasifikasikan dengan respek terhadap sebuah metodologi umum; ini akan diselesaikan sejauh mungkin dalam bagian-bagian yang tersisa. Pada bagian-bagain berikutnya pendekatan-pendekatan berbeda akan dievaluasi dengan respek terhadap poin-poin ini kapanpun sesuai atau dapat diaplikasikan.
  1. Forward engineering: Dari ER ke model logis hanca hal 8

Berikutnya diasumsikan bahwa pembaca cukup familiar dengan konsep dasar model-model data ER, jaringan, relasional, dan hirarkis. Deskripsi tentang konsep-konsep dasarnya dapat ditemukan dalam banyak textbook basis data, contohnya [5, 36, 61, 63, 103, 105]. Deskripsi ER ekstensi ECR, EER dan ECR+ dapat ditemukan pada [37, [99, 101] dan [94]. Untuk kesederhanaan, kami akan sering menggunakan istilah-istilah relasi, entitas, relationship, record, dan set walaupun skema relasi, jenis entitas, tipe relationship, tipe record, dan tipe set, terutama jika pengertian istilah-istilah ini jelas dari konteks itu.

Kesulitan utama dari desain basis data logis, yakni transformasi skema ER ke dalam sebuah ER dalam bahasa suatu model logis, merupakan isu pemeliharaan informasi. Tentu saja, meyakinkan pemetaan lengkap dari semua konsepsi pemodelandan constrain yang inherent, implisit atau eksplisit dalam skema sumber merupakan problematika sejak constraint-constraint model sumber sering tidak dapat direpresentasikan secara langsung dalam istilah-istilah struktur dan constraint model target. Pada kasus seperti itu, mereka harus direalisasikan melalui program-program aplikasi; alternatifnya, transformasi reduksi informasi harus diterima.

4.1  Dari ER ke Relasional

Terdapat sejumlah besar karya yang abdikan pada transformasi skema-skema ER ke dalam skema-skema relasional. Ide-ide dasar transformasi seperti itu dideskripsikan pada banyak sekali textbook basis data, mencakup [5, 36, 61, 63, 68, 103, 105]. Publikasi lain yang menginvestigasi dalam arah transformasi ini adalah, contohnya [1, 7, 13, 12, 22, 30, 33, 34, 55, 62, 66, 69, 70, 71, 72, 73, 82, 87, 95, 97, 101,107]. Sebagian fokus pada versi asli ER model [13, 22, 30, 34, 55, 70, 82, 103, 107]; yang lainnya menggunakan ER model ekstensi, mencakup relationship subtipe/supertipe atau struktur-struktur generalisasi yang lebih kompleks [5, 7, 12, 33, 36, 62, 63, 66, 68, 95, 101, 105]. Hanya sedikit yang berdasarkan pada ER model ekstensi        dengan abstraksi agregasi atau relationship di atas relationship [1, 61, 69, 71-73, 97]. Semua yang pendekatan ini miliki biasanya tidak membutuhkan interaksi pengguna dan, dengan eksepsi [7], tidak mempertimbangkan isu-isu operasional. Pendekatan-pendekatan ini hanya disebutkan berdasarkan metodologi basis sama, yang karenanya kami menyebut pendekatan transformasi umum. Kami mendeskripsikan pendekatan ini dahulu kemudian mengarah ke isu-isu spesifik yang sedang dihadapi.

4.1.1        Pendekatan transformasi umum

Pendekatan transformasi umum untuk struktur-struktur ER berdasarkan pada jenis-jenis langkah berikut:

  • Tiap tipe entitas diterjemahkan ke dalam sebuah relasi. Atribut-atribut dan kunci primer jenis ini menjadi atribut-atribut dan kunci primer relasi itu.
  • Tipe entitas lemah diterjemahkan ke dalam sebuah relasi. Selain atribut-atribut lokal, atribut-atribut kunci primer tipe entitas identifikasi itu tercakup sebagai atribut-atribut. Kunci primer relasi itu terdiri atas atribut-atribut kunci lokal plus atribut-atribut kunci primer dari tipe entitas identifikasi itu.

Pada umumnya, tipe relationship ditransformasikan berdasarkan pada arity-nya dan constraint kardinalitas yang dibutuhkan untuk komponen-komponennya seperi yang dideskripsikan di bawah ini, di mana tipe dan generalisasi relationship IS-A diposisikan secara terpisah dari tipe relationship lain. Mari kita terlebih dahulu mempertimbangkan kasus yang sangat penting tentang tipe-tipe relationship biner, seperti tampak pada Gambar 4; kami berasumsi bahwa constraint kardinalitas diberikan sebagai Min-Max constraints sebagai mana yang dideskripsikan, contohnya, dalam [36]. Tipe-tipe relationship biner dapat ditransformasikan dalam tiga cara yang berbeda, tergantung pada constraint kardinalitas yang ditetapkan untuk komponen-komponennya (bandingkan dengan Gambar 4):

Pilihan 1: Definisi relasi terpisah. Atribut-atribut kunci primer dari komponen relationship A dan B serta atribut-atribut relationship R terlibat seperti atribut-atribut dalam relasi yang dibuat baru RelR. Jika kardinalitas Max komponen sama dengan 1, kunci primer komponen itu dapat dipilih sebagai kunci primer RelR; sebaliknya, perpaduan kunci primer A dan B dipilih sebagai kunci. Transformasi ini dapat diaplikasikan untuk setiap jenis tipe relationship biner, independen dari constraint-constraint kardinalitas. Di samping penggunaan mandatori opsi ini jika kedua komponen memiliki kardinalitas Max lebih besar dari1, juga sering digunakan secara praktis jika tipe relationship memiliki atribut-atribut yang dimilikinya atau jika kedua komponen memiliki partisipasi pilihan (yakni kardinalitas-kardinalitas Min sama dengan 0). Di balik pilihan ini, transformasi relationship R dari Gambar 4 berhasil dalam relasi tiga berikut, di mana kunci-kunci primer digaris-bawahi:

RelA(K1,…) RelR(K1,K2,…) RelB(K1,…)

Pilihan 2: Insertion kunci tamu (foreign key). Kunci primer relasi yang sesuai untuk satu komponen, katakanlah B, di-insert (sisip) sebagai kunci tamu dalam relasi yang berhubungan dengan komponen lain A. Jika atribut-atribut relationship exist, ini juga di-insert-kan ke dalam A. Pilihan ini hanya dapat diaplikasikan jika kardinalitas Max A sama dengan 1. Jika kedua komponen memiliki kardinalitas Max 1, kunci tamu terlibat dalam relasi itu yang komponennya memiliki partisipasi mandatori dalam R (yakni kardinalitas Min-nya sama dengan 1). Catat bahwa partisipasi mandatori mungkin dibutuhkan untuk menghindari nilai-nilai null untuk kunci-kunci tamu. Contohnya dari Gambar 4, pilihan ini mengarah pada dua relasi berikut:

RelA(K1,K2,…) RelB(K1,…)

Pilihan 3: Melakukan collapsing A, B, dan R ke dalam satu relasi. Pilihan ini hanya bermanfaat, jika kardinalitas-kardinalitas Min-Max c dan d adalah keduanya (1,1). Dalam kasus ini, kunci primer dari salah satu komponen dipilih sebagai kunci primer relasi collapse RelA-B. Contohnya dari Gambar 4, ini berhasil dalam relasi berikut:

RelA-B (K1,K2,…)

Berbagai kemungkinan untuk mentransformasi tipe relationship biner R dari Gambar 4 disumarisasikan dalam Table 1 dengan memperhatikan constraint-constraint kardinalitasnya. Tabel ini tidak mengambil ke dalam account kehadiran atribut-atribut relationship. Jika atribut-atribut seperti itu exist, beberapa pendekatan lebih disukai dari pembuatan sebuah relasi individu untuk tipe relationship ini, seperti Storey [97] atau Markowitz [73], sedangkan yang lainnya tidak membuat perbedaan apakah sebuah tipe relationship memiliki atribut-atribut atau tidak, seperti Teorey [101]. Pendekatan-pendekatan yang hanya mendukung notasi 1:N untuk constraint-constraint kardinalitas tanpa perbedaan pilihan dan partisipasi mandatori (lihat Colom 1 dalam Tabel 1) biasanya menggunakan Pilihan 2 di atas kapanpun dapat diaplikasikan.

Tabel 1

Berbagai kemungkinan untuk merepresentasikan tipe-tipe relationship biner

Pada tabel 1, sebuah ‘x’ dalam sebuah kolom berarti bahwa pilihan yang sesuai itu dapat diaplikasikan; sebuah ‘x’ menunjukkan bahwa pilihan ini biasanya digunakan dalam pendekatan-pendekatan yang mendukung constraint-constrain kardinalitas dengan notasi Min-Max atau notasi 1:N dengan perbedaan mandatori/pilihan, dan sebuah ‘x’ menunjukkan penggunaan umum dari pilihan itu untuk notasi 1:N tanpa perbedaan mandatori/pilihan.

Kemudian, kami mempertimbangkan transformasi tipe-tipe relationship lain yang dapat terjadi dalam ER diagram yang diberikan:

  • Tipe-tipe relationship dari arity > 2 ditangani dengan membuat kepemilikan relasi baru sebagai kunci primer, penyatuan kunci primer dari komponen-komponen relationship, dan atribut-atribut tipe relationship sebagai atribut-atribut tambahan.
  • Tipe-tipe relationship rekursif diterjemahkan seperti relationship-relationship non-rekursif, dengan eksepsi nama-nama peran itu harus dihasilkan untuk atribut-atribut kunci yang merepresentasikan relationship tersebut.
  • Tipe-tipe agregasi atau relationship yang merupakan sebuah komponen dari tipe relationship lainnya yang ditransformasikan ke dalam sebuah relasi individu sama halnya dengan tipe-tipe relationship dengan arity > 2.
  • Tipe-tipe IS-A relationship dapat direpresentasikan dengan membuat kunci supertipe sebuah kunci tamu dalam relasi yang merepresentasika subtipe tersebut. Kemungkinan lain yang sering digunakan untuk representasi hirarki-hirarki generalisasi yang komplek itu sebagai berikut:

-          Supertipe S dan subtipenya Si, 1 ≤ i ≤ n direpresentasikan bersama-sama dalam sebuah relasi tunggal Rels. Atribut-atribut Rels merupakan kesatuan atribut-atribut S dan Si’s. Diskriminasi atau atribut-atribut peran dapat ditambahkan untuk menunjukkan keanggotaan suatu entitas dalam subtipe Si; transformasi ini bermanfaat jika subtipe yang tidak memiliki atribut-atribut lokal atau kunci lokal yang paling sedikit.

-          Supertipe itu tidak direpresentasikan sebagai relasi individu, tapi atribut-atributnya di-insert-kan ke dalam masing-masing relasi yang merepresentasikan sebuah subtipe. Transformasi ini hanya praktis jika hirarki generalisasi itu merupakan total dan eksklusif.

Di samping constraint-constraint kunci dibutuhkan untuk memperoleh beberapa jenis constraint integritas lain untuk mendapatkan sebuah transformasi pemeliharaan informasi. Ini mencakup constraint-constraint kunci tamu (secepatnya dalam bentuk dependensi-dependensi inklusi berbasis kunci) untuk menunjukkan relationship-relationship di antara relasi-relasi yang relevan, dependensi eksistensi (terutama constraint-constraint bukan nol) untuk merepresentasikan partisipasi mandatori sebuah komponen dalam tipe relationship atau dependensi tipe relationship pada komponen-komponennya, dan dependensi-dependensi untuk merepresentasikan partisipasi mandatori pada sebuah relationship dalam kasus ini tidak dapat direpresentasikan melalui constraint-constraint eksistensi. Tambahan pula, dependensi-dependensi eksklusi bisa menjadi dibutuhkan untuk menunjukkan hirarki-hirarki generalisasi eksklusif; detil-detil dihilangkan.

Banyak sekali pendekatan yang mengikuti metode umum ini memiliki hanya perbedaan tak kentara. Contohnya, Chen [22] dan Jajodia, dkk. [55] mentransformasikan setiap tipe entitas dan relationship ke dalam relasi individu, yang sering juga disebut transformasi resmi (canonical). Dumpala dan Arora [34], Teorey [101], atau Elmasri dan Navathe [36] mendukung constraint-constraint kardinalitas 1:N tanpa membedakan partisipasi pilihan dan mandatory sehingga selalu menggunakan representasi kunci tamu untuk relationship 1:N dan 1:1, sedangkan Batini, dkk. [5] dan Storey [97] menggunakan semua kemungkinan tersebut dengan memperhatikan kardinalitas Min-Max. Perbedaan besar di antara semua pendekatan ini terletak di dalam constraint-constraint yang diperoleh selama sebuah transformasi.

1.1.1        Pendekatan lain

Pendekatan-pendekatan yang berjalan di luar pendekatan transformasi umum itu dapat ditemukan pada [1, 5, 7, 33, 36, 66, 69, 68, 70-73, 95, 101]. Transformasi-transformasi ini disurvey dalam Tabel 2 dengan memperhatikan aspek-aspek berikut:

  • ER model yang digunakan: Kolom 2 mengkarakterisasikan ER model ekstensi yang digunakan dalam pendekatan respektif. Kami membedakan subtipe/supertipe sederhana dan IS-A relationship dari struktur-struktur generalisasi yang lebih komplek, sejak yang terbaru memuat lebih banyak informasi semantik, contohnya dependensi eksklusi yang secara tidak langsung dipengaruhi dengan hirarki-hirarki generalisasi eksklusif. Dengan demikian, lebih membosankan untuk yang terakhir untuk memperoleh pemeliharaan informasi. Yang samanya adalah benar untuk perbedaan jenis constraint kardinalitas yang berbeda, terutama Min-Max constraints, 1:N-constraints dengan perbedaan pilihan/mandatori, atau 1:N constraints tanpa perbedaan ini.

Tabel 2

Karakteristik transformasi ER

Model: 1 = Subtipe/Supertipe atau IS-A relationships 2 =  Struktur-struktur yang lebih kompleks 3 = Agregasi atau relationship di atas relationship 4 = Constraints kardinalitas 1:N 5 = Constraints kardinalitas Min-Max atau 1:N constraints dengan mandatori vs. perbedaan pilihan 6 = Struktur-struktur atribut yang komplek 7 = Lebih dari satu kunci dapat ditetapkan untuk tiap tipe

ER preprocessing: N = ER normalization S = Simplification of complex structures F = Flattening complex attribute structures

Derived constraints: K = Keys FD = FDs beyond keys IND = Inclusion dependencies NN = Not-Null constraints FK = Foreign key constraints JD = Join dependencies Y = Yes N = No

  • Prapemrosesan skema ER: Kolom 3 menyatakan apakah suatu bentuk prapemrosesan dibutuhkan untuk skema ER inisial, terutama normalisasi atau penyederhanaan konsepsi-konsepsi dengan level abstraksi tinggi untuk konsepsi-konsepsi dengan level abstraksi rendah. Pada proses penyederhanaan seperti itu, struktur-struktur generalisasi dapat diganti dengan tipe-tipe relationship, atau tipe-tipe relationship dibuat biner. Penggantian struktur-struktur atribut komplek dengan yang tepat berarti normalisasi dan penyederhanaan; ini dibedakan dalam tabel itu. Struktur-struktur atribut komplek tidak selalu membutuhkan prapemrosesan, selama flattening kadang-kadang dilakukan secara langsung selama pemetaan.

Kami juga menyebutkan penetapan nama yang tepat dalam Kolom 3, yang sering diabaikan. Perbedaan yang dapat muncul dari penamaan yang tidak tepat w.r.t. untuk normalisasi relasional dideskripsikan dalam [71, 73].

  • Constraint-constraint integritas relasional yang diperoleh: Kolom 4 membuat daftar constraint-constraint integritas relasional yang diperoleh selama transformasi respektif. Constraint-constraint yang diperoleh dapat menjadi kunci-kunci, yang ekuivalen ke dependensi-dependensi fungsional berbasis kunci, dependensi fungsional (FDs) yang tidak berbasis kunci, constraint-constraint kunci tamu (FKs), dependensi-dependensi inklusi (INDs), dependensi join (JDs), dan bentuk khusus constraint-constraint yang ada, Not-Null-constraints (NNs). Perlu dicatat bahwa FKs merupakan bentuk khusus dependensi-dependensi inklusi, dan bahwa banyak sekali pendekatan yang memperoleh hanya INDs yang menunjukkan constraint kunci tamu; sejak INDs lebih lazim dari kunci primer, kami di sini membedakan constraint ini jika digunakan secara ekuivalen.
  • Derajat normalisasi skema yang dihasilkan: Derajat normalisasi yang dicapai, ditunjukkan dalam Kolom 5, tergantung pada set dependensi-dependensi yang diambil ke dalam account. Jika hanya FDs itu dianggap yang secara langsung dinyatakan dengan constraint-constraint kardinalitas dan definisi-definisi kunci, maka berdasarkan [73] bahwa skema EER memuaskan berbagai prakondisi, contohnya penamaan unik terhadap semua atribut seperti tipe-tipe entitas dan relationship, dapat direpresentasikan dengan skema relasional BCNF. Jika FDs juga di antara atribut bukan kunci diambil ke dalam account, normalisasi dapat dilakukan sebelum transformasi pada ER level [28, 66], atau setelah transformasi dengan menormalisasikan skema-skema relasi yang dihasilkan menggunakan algoritma-algoritma yang bagus, contohnya prosedur sintesis Bernstein [6]. Kami di sini hanya menganggap derajat normalisasi skema relasional secara langsung setelah transformasi seperti yang disebutkan dalam pendekatan dasar.
  • Pemeliharaan informasi transformasi: Kolom 6 menyatakan apakah semua konsepsi dan constraint skema ER yang diberikan dipertimbangkan selama pemetaan.

Transformasi canonical:          Sebuah transformasi adalah canonical, jika untuk setiap tipe skema sumber sebuah relasi terpisah ditetapkan. Transformasi seperti ini memiliki kelebihan bahwa informasi yang memelihara properti dapat dengan lebih mudah dipenuhi daripada menggunakan pilihan-pilihan lain, dan bahwa hasil transformasi itu lebih transparan dan lebih mudah dipahami bagi pengguna, kelemahannya adalah adanya redudansi. Markowitz, dkk. [73] mengkombinasikan keunggulan transformasi caconical dan non-caconical, karena mereka terlebih dahulu melakukan transformasi secara caconical, maka kemudian mereka menggabungkan properti-properti struktural w.r.t. relasi yang dihasilkan.

Properti-properti lain dari Bagian 3 yang tidak disebutkan di sini secara eksplisit adalah kesamaan untuk semua pendekatan; dengan lebih tepat, tidak ada pendekatan yang membutuhkan interaksi pengguna, metodologi transformasi itu adalah kesamaan untuk semua pendekatan, dan operasi-operasi yang hanya dipertimbangkan dalam pendekatan Bertaina, dkk. [7].

Kami sekarang berkomentar lebih jauh pada pendekatan-pendekatan yang disumarisasikan pada Tabel 2. Batini, dkk. [5] menggunakan ER model yang dipertinggi  dengan struktur-struktur atribut dan generalisasi yang kompleks untuk desain konseptual. Sebelum transformasi dapat dilakukan, semua struktur yang dipertinggi, contohnya hirarki-hirarki generalisasi dan atribut-atribut kompleks, disederhanakan ke struktur-struktur tipe entitas dan relationship. Beberapa kemungkinan untuk penyederhanaan struktur generalisasi diusulkan. Setelah penyederhanaan, pendekatan transformasi umum itu diaplikasikan, seperti yang dideskripsikan di atas untuk kardinalitas Min-Max.

Pendekatan Bertaina, dkk. [7] merupakan hanya satu yang menyertai kebutuhan-kebutuhan pemrosesan ke dalam sebuah transformasi. Untuk akhir ini, skema ER yang diberikan disederhanan dahulu dengan s.t. yang terdiri atas tipe-tipe entitas kuat dan tipe-tipe relationship biner saja. Kemudian skema itu diperhalus dan direstrukturisasi w.r.t. kebutuhan-kebutuhan pemrosesan, contohnya atribut-atribut diduplikasi dan tipe-tipe entitas di-split, serta sesudah itu dipetakan ke dalam skema relasional       yang menggunakan rule-rule transformasi umum untuk constraint-constraint kardinalitas 1:N. Skema yang dihasilkan umumnya tidak dinormalisasi, tapi optimal dengan memperhatikan operasi-operasi yang sudah ditetapkan. Dogac, dkk. [33] memperoleh insert and delete triggers selama translasi. Trigger-trigger ini dapat dianggap sebagai substitusi untuk dependensi-dependensi inklusi atau kunci-kunci tamu, yang secara tidak langsung dinyatakan dengan constraint-constraint struktur dan kardinalitas skema ER yang diberikan. Pendekatan ini pada dasarnya sangat heuristik; terutama, asal mula trigger tidak dibuat tepat secara formal.

Manfaat pendekatan Elmasri dan Navathe [36] adalah pemetaan struktur-struktur EER yang dipertinggi, seperti konsepsi kategori atau subkelas yang di-share. Abstraksi yang tidak digunakan oleh mereka dalam model sumbernya adalah agregasi atau relationship terhadap relationship, respektif. Ling [66] memperkenalkan sebuah bentuk normal untuk skema-skema ER. Skema sumber itu dibutuhkan untuk mentaati bentuk normal ini; karena itu, prapemrosesan normalisasi harus dilakukan. Transformasi ke dalam model relasional itu berhasil dalam skema-skema relasional 3NF atau 5NF. Perbedaan dengan pendekatan lain, ER model yang digunakan di sini mendukung spesifikasi dependensi-dependensi fungsional berbasis bukan kunci dan beberapa kunci untuk tiap tipe kunci, yang dipertimbangkan dalam transformasi tersebut. Mannila, dkk. [68] menetapkan Entity-Relationship Normal Form (ERNF) untuk skema-skema relasional, dan ternyata, sebagai contoh, hasil-hasil transformasinya berada dalam BCNF. Pemetaan yang digunakan oleh mereka itu berbasis pada pendekatan Markowitz, dkk. [72]; dengan demikian, hanya FDs yang secara langsung diperoleh dari constraint-constraint dan kunci-kunci kardinalitas yang dipertimbangkan.

Yang terakhir, benar juga untuk pendekatan Markowitz, dkk. [73]. Mereka merealisasikan transformasi dalam empat langkah: Pertama, skema ER yang diberikan dipetakan ke skema relasional caconical dengan FDs, INDs, dan constraint-constraint yang ada. Dalam skema ini, tiap tipe entitas atau relationship direpresentasikan dengan sebuah relasi individu. Kedua, sebuah algoritma penetapan nama untuk atribut-atribut itu diaplikasikan, untuk menghindari ambiguitas-ambiguitas dan menghilangkan berbagai asumsi, mencakup asumsi skema universal, asumsi peran universal dan asumsi selera itu. Ketiga, skema itu dinormalisasikan ke dalam BCNF, dan akhirnya skema-skema digabungkan untuk menghapus redundansi-redundansi. Skema yang dihasilkan itu masih berada dalam BCNF. Pendekatan itu secara matematis ditemukan, dan kebenaran tiap langkah dapat dibuktikan. Definisi-definisi diberikan untuk           “kapasitas informasi ekuivalen” skema relasional dan untuk sebuah transformasi yang benar. Pendekatan-pendekatan yang digambarkan dalam [69, 72, 70] dapat dilihat sebagai pendahulu pendekatan ini; sebuah transformasi invers untuk pendekatan yang ada dalam [69].

Springsteel dan Chuang [95] juga menginvestigasi normalisasi skema relasional hasil yang tergantung pada struktur skema sumber ER; transformasi yang diusulkan itu berdasarkan [70].         Dalam pendekatan Storey [97] berbagai kemungkinan untuk menerjemahkan struktur-struktur generalisasi dibahas, seperti yang dideskripsikan dalam pendekatan transformasi umum di atas. Transformasi itu ditempelkan ke dalam sebuah metodologi untuk desain basis data yang dimulai dengan identifikasi konsepsi-konsepsi ER dasar dan berakhir dengan sebuah normalisasi hasilnya. Teorey, Yang, dan Fry [101] memperoleh kunci-kunci, FDs, constraint bernilai null dan constraint-constraint kunc tamu dari skema ER awal. Normalisasi relasional dianggap sebuah langkah ekstra setelah transformasi. Transformasi sendiri bukan pemeliharaan informasi, sejak dependensi-dependensi eksklusi yang secara tidak langsung dinyatakan dengan struktur-struktur generalisasi mengalami kehilangan (missing). Harus dikatakan bahwa pendekatan ini seperti pendekatan Storey [97] dan Markowitz serta Shoshani [73] muncul menjadi yang paling sesuai untuk penggunaan praktis.

1.1  Dari ER ke OO

Sebagaimana dikatakan di awal, terdapat kepentingan yang meningkat saat ini dalam penggunaan teknologi basis data OO, yang menggerakkan sebuah kebutuhan atas teknik-teknik yang sesuai untuk desain basis data OO. Dalam subbagian ini, kami melakukan survey terhadap pendekatan-pendekatan relevan yang mencoba untuk menggunakan kembali pengalaman masa lalu dengan menggunakan model ER untuk pemodelan konseptual, dan dengan mentransformasikan pendekatan-pendekatan yang telah dilaporkan dalam [8, 35, 36, 43, 60, 76, 77, 98]; pendekatan-pendekatan yang menggunakan model data semantik lainnya untuk desain basis data OO dapat ditemukan dalam [11, 47, 84]. Sebuah justifikasi untuk penggunaan ER model dalam setting ini adalah bahwa ia masih dianggap bagus, paling tidak selama selama model-model OO pada sistem saat ini berbasiskan keterbatasan- keterbatasan w.r.t. pemodelan struktural dan aspek-aspek perilaku aplikasi-aplikasi basis data [98]; contohnya, mereka sering tidak dapat memodelkan n-ary relationship atau constraint-constraint integritas, contohnya constraint-constraint atau kunci-kunci yang ada, secara eksplisit.

Aspek baru yang utama dalam transformasi sebuah skema ER ke dalam model OO, yang tidak sebanding dalam transformasi-transformasi relasional, adalah bahwa is sekarang menjadi penting untuk menetapkan (dan mengintegrasikan) operasi-operasi atau metode-metode yang merepresentasikan constraint-constraint integritas yang tidak dapat direpresentasikan secara eksplisit via struktur-struktur. Contohnya, banyak sekali model OO tidak memiliki kemungkinan untuk mendeklarasikan kunci-kunci atau FDs yang lebih umum. Dengan demikian, constraint-constraint seperti itu sekarang dapat dikodekan ke dalam metode-metode, yang mana ketika diintegrasikan secara tepat ke dalam deklarasi-deklarasi tipe atau kelas dapat dipelihara dengan sistem utama secara otomatis.

Seperti untuk kasus relasional, metodologi dasar tentang bagaimana ER-schema dapat dipetakan ke dalam skema OO dapat diperlihatkan. Ia hanya mempertimbangkan definisi struktur tipe itu tanpa operasi-operasi (sejak akhir-akhir ini belum ada pendekatan yang diterima secara umum). Metodologi ini, yang kami sebut juga ‘transformasi   umum’, sangat didukung dengan sebagian besar pendekatan yang disurvey. Integrasi constraint-constraint integritas yang tidak dapat direpresentasikan secara eksplisit melalui struktur tipe itu akan dideskripsikan dalam konteks pendekatan-pendekatan spesifik, sejak tidak ada metodologi yang diterima secara umum untuk yang ini.

1.1.1        Pendekatan transformasi umum

Transformasi struktur-struktur ER dasar mirip dengan berbagai proposal yang baru-baru ini sudah dibuat. Untuk model target berbasis kelas, contohnya O2 [3] atau  antar muka C++ dari ODMG-93 [21], struktur-struktur ER-model dapat ditransformasikan dalam cara berikut ini:

  • Untuk tiap tipe entitas sebuah kelas dibuat. Atribut-atribut tipe entitas menjadi atribut-atribut kelas itu, di mana atribut-atribut kompleks dapat direpresentasikan secara langsung menggunakan tuple, set, bag, atau list constructors yang ada.
  • Tipe-tipe relationship biner dapat direpresentasikan dengan atribut-atribut bernilai objek dalam kelas-kelas yang sesuai dengan komponen-komponen tipe relationship, atau dengan sebuah kelas individu. Dalam kasus pertama ini atribut-atribut didefinsikan sebagai nilai set atau tunggal yang tergantung pada constraint-constraint kardinalitas yang ditetapkan untuk tipe relationship tersebut. Pilihan ini sangat berguna jika tipe relationship dalam pertanyaan tidak memiliki atribut-atribut lokal. Atribut-atribut yang merepresentasikan sebuah tipe relationship harus, jika mungkin, didefinisikan sebagai invers untuk satu dengan yang lainnya dalam dua kelas yang relevan, untuk menjalankan integritas referensial. Jika sebuah path dari satu kelas ke yang lainnya relevan untuk aplikasi pokok saja, ia akan cukup untuk memasukkan sebuah atribut bernilai objek dalam satu kelas komponen (bukan dua), yang kemudian mereferensikan yang lainnya.

Pada kasus kedua dua atribut bernilai tunggal dan objek ditetapkan untuk kelas yang merepresentasikan tipe relationship, yang mereferensikan kelas-kelas yang sesuai dengan komponen-komponen relationship. Terakhir, atribut-atribut bernilai objek terlibat mereferensikan kelas relationship. Tiap pasangan atribut yang merepresentasikan sebuah koneksi seperti itu haru juga didefinisikan sebagai invers masing-masing; kardinalitas atribut-atribut dalam kelas-kelas komponen juga tergantung pada constraint-constraint kardinalitas yang ditetapkan untuk tipe relationship, seperti dalam kasus pertama. Pilihan transformasi ini berguna jika tipe relationship itu memiliki atribut-atribut.

  • Tipe-tipe entitas lemah yang mana bukan komponen tipe relationship lain dapat direpresentasikan sebagai atribut-atribut (mungkin bernilai tuple dan set) dalam kelas yang merepresentasikan tipe identifikasi. Alternatifnya, mereka dapat direpresentasikan sebagai kelas-kelas individu, dan relationship yang ada dimanifetasikan via atribut-atribut bernilai-objek (invers) sebagaimana dideskripsikan di atas.
  • Tipe-tipe relationship rekursif direpresentasikan sebagai atribut-atribut bernilai objek yang mereferensikan kelas di mana mereka sendiri terlibat.
  • Semua agregasi dan tipe relationship lain dipetakan ke dalam sebuah kelas terpisah, dengan atribut-atribut bernilai objek yang sesuai mereferensikan komponen-komponen relationship dalam pertanyaan. Selanjutnya mirip dengan yang dideskripsikan untuk tipe-tipe relationship biner, yang dipetakan ke dalam sebuah kelas individu.
  • IS-A-relationship dan struktur-struktur generalisasi dimodelkan via link-link warisan di antara kelas-kelas yang merepresentasikan supertipe dan subtipe dala ER model. ‘Kelas-kelas interseksi’ tambahan harus ditetapkan di antara dua kelas jika model OO membutuhkan setiap objek untuk menjadi anggota dalam persisnya satu kelas dan subkelas struktur generalisasi mengalami overlap.
  • Semua constraint dan struktur lain dari   ER-schema, yang tidak dapat dideskripsikan secara implisit maupun eksplisit dalam OO-schema, direpresentasikan sebagai operasi-operasi atau metode-metode yang digunakan (attached) ke kelas yang sesuai dengannya. Jika model OO target itu mendukung constraint-constraint integritas,      contohnya atribut-atribut kunci dan invers dalam ODMG-93 [21], mereka dapat digunakan menggunakan metode-metode integritas.

Semua pendekatan yang disebutkan di atas umumnya mengikuti metodologi transformasi ini; mereka sering berbeda-beda, dalam cara mereka mengambil constraint-constraint integritas ke dalam account, jika mereka melakukan ini semua. Perbedaan lainnya berkenaan dengan representasi tipe-tipe relationship biner dan model target spesifik; pokok-pokok muncul dalam subseksi selanjutnya.

1.1.2        Detil

Pada tabel 3, kami melakukan survey beberapa pendekatan untuk transformasi OO yang memperlihatkan varietas model target. Pada tabel ini, kami juga memperlihatkan model ER yang digunakan, di mana klasifikasi mengikuti tabel 2 (dengan pengecualian ‘7’ yang sekarang berdiri untuk ‘atribut-atribut yang diperoleh’). Sebagian pendekatan menggunakan model OO virtual, dalam pengertian bahwa mereka hanya mengandalkan fitur-fitur yang terjadi dalam model OO yang sangat banyak.

Kami mengatakan bahwa tidak satu pun dari pendekatan ini membutuhkan prasyarat atau interaksi pengguna khusus. Hanya Nachouki, dkk. [76] mempertimbangkan syarat pemrosesan selama transformasinya. Kecuali bagi Biskup, dkk. [8], tidak ada yang dapat dikatakan tentang kebenaran pendekatan itu, sejak deskripsi-deskripsi itu sangat informal. Kualitas skema OO dibahas dalam Nachouki, dkk. [76], Kilian [60] dan Biskup et al. [8]. Yang pertama berkonsentrasi pada identifikasi kelas, kedua pada representasi struktur-struktur generalisasi yang benar, dan Biskup, dkk. menginvestigasi bagaimana sebuah skema OO yang merupakan hasil transformasi awal dapat diimprovisasi dengan menggabungkan dan mendekomposisi kelas-kelas.

Kami sekarang berkomentar pada berbagai pendekatan lebih detail. Biskup, dkk. [8] menggunakan F-logic [59], sebuah formalisme berbasis logika untuk menentukan dan beralasan konsep-konsep OO, ditambahkan dengan sebuah notasi dari constraint-constraint semantik untuk transformasinya. Faktanya, skema ER yang diberikan terlebih dahulu ditransformasikan ke dalam sebuah skema OO abstrak dalam F-logic, yang kemudian diimprovisasi dengan mendekompisisi dan menggabungkan kelas-kelas serta menentukan kunci-kunci minimal. Skema hasil kemudian dipetakan ke dalam sebuah skema OO konkrit, dalam kasus ini menggunakan sistem ONTOS [83], yang akhirnya dapat dioptimalisasikan w.r.t. properti-properti sistem spesifik yang ada.

Elmasri dan Navathe [36] mengusulkan sebuah metodologi transformasi umum, menggunakan skema EER sebagai sumber dan model OO virtual sebagai target. Mereka hanya fokus pada pemetaan struktur-struktur ER dasar, mirip dengan pendekatan transformasi umum di atas. Transformasi constraint-constraint integritas  di luar struktur tipe itu tidak dipertimbangkan. Elmasri, dkk. [35] menggunakan model EER diperluas [36] sebagai sumber dan juga sebuah model OO virtual sebagai target. Di samping pemetaan struktur-struktur EER, pendekatan ini fokus pada generasi atomik dan integrasi metode-metode yang menjalankan constraint-constraint integritas yang diberikan secara implisit dan eksplisit dalam skema EER, terutama kunci-kunci, constraint-constraint kardinalitas, dan constraint-constraint yang ada yang diperoleh dari struktur-struktur generalisasi. Untuk akhir ini, metode dasar Constructor, Destructor, Updater, Relater, dan Unrelater ditetapkan dalam masing-masing kelas, yang mengintegrasikan semua constraint integritas yang ditetapkan. Fokus utamanya berada pada transformasi jenis konsepsi generalisasi/spesialisasi yang berbeda.

Gogolla, dkk. [43] menggunakan TROLL light [42] sebagai model target. Di samping fitur lainnya, model ini menyediakan kemungkinan-kemungkinan untuk merepresentasikan constraint-constraint integritas statis, atribut-atribut yang diperoleh, dan perilaku secara eksplisit. Objek-objek dideskripsikan dalam Troll light menggunakan template-template. Constraint-constraint dapat ditetapkan dalam bagian template khusus menggunakan SQL-like query calculus. Fokus pendekatan itu adalah pada transformasi konsepsi-konsepsi dasar, dan pada pemetaan constraint-constraint hanya disebutkan. Kilian [60] menginvestigasi  perbedaan-perbedaan di antara desain basis data OO dan desain ER, dan memperoleh representasi OO struktur-struktur ER dari itu. Fokusnya pada representasi konsepsi-konsepsi kategorisasi dalam sebuah skema OO; dia membedakan relationship subset dan subtipe, dan kategorisasi dalam pengertian [37]. Untuk selanjutnya, dia memperkenalkan sebuah analog OO untuk tipe kategori itu.

bersambung..

One response to “SURVEY TRANSFORMASI DESAIN BASIS DATA BERBASIS ENTITY-RELATIONSHIP MODEL

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s