Object relational mapping pada pengembangan enterprise resource planning

PENERAPAN OBJECT RELATIONAL MAPPING
PADA PENGEMBANGAN ENTERPRISE RESOURCE PLANNING

DIAN INDAH SAVITRI

DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
2008

PENERAPAN OBJECT RELATIONAL MAPPING
PADA PENGEMBANGAN ENTERPRISE RESOURCE PLANNING

Skripsi
Sebagai salah satu syarat untuk memperoleh gelar Sarjana Komputer
pada Fakultas Matematika dan Ilmu Pengetahuan Alam
Institut Pertanian Bogor

Oleh :
DIAN INDAH SAVITRI
G64104035

DEPARTEMEN ILMU KOMPUTER
FAKULTAS MATEMATIKA DAN ILMU PENGETAHUAN ALAM
INSTITUT PERTANIAN BOGOR
2008

Judul : Object Relational Mapping pada Pengembangan Enterprise Resource
Planning
Nama : Dian Indah Savitri
NRP

: G64104035

Menyetujui:
Pembimbing I,

Pembimbing II,

Wisnu Ananta Kusuma, S.T., M.T.
NIP 132 312 485

Toto Haryanto, S.Kom

Mengetahui:
Dekan Fakultas Matematika dan Ilmu Pengetahuan Alam
Institut Pertanian Bogor

Dr. Drh. Hasim, DEA
NIP 131 578 806

Tanggal Lulus:

iv

ABSTRAK
DIAN INDAH SAVITRI. Penerapan Object Relational Mapping pada Pengembangan Enterprise
Resource Planning. Dibimbing oleh WISNU ANANTA KUSUMA dan TOTO HARYANTO.
Enterprise Resource Planning (ERP) merupakan suatu aplikasi terintegrasi yang difokuskan
untuk mengotomasi seluruh aktivitas infrastruktur pada suatu perusahaan. Sistem ERP
menggabungkan proses bisnis antara perusahaan dan pelanggan, perusahaan dengan supplier, dan

proses perhitungan keuangan perusahaan. Semua proses bisnis yang tergabung mengakses pada
sebuah basis data yang terpusat.
Sistem manajemen basis data yang banyak digunakan pada aplikasi ERP adalah basis data
relasional, sedangkan pengembangan aplikasi skala enterprise sebagian besar menerapkan konsep
berorientasi objek. Dengan demikian terdapat ketidaksesuaian antara basisdata relasional yang
digunakan dengan aplikasi yang dikembangkan dan pendekatan berorientasi objek.
Ketidaksesuaian tersebut antara lain terkait dengan aspek granularity, subtypes, identitas, asosiasi,
dan navigasi data.
Pada penelitian ini dilakukan analisis terhadap rancangan aplikasi ERP. Ditemukan
ketidaksesuaian yang meliputi empat aspek, yaitu aspek granularity, identitas, asosiasi, dan
navigasi data. Untuk mengatasi ketidaksesuaian tersebut, diimplementasikan konsep Object
Relational Mapping (ORM). Setiap objek yang akan dipetakan menjadi tabel-tabel pada basis data
relasional dibungkus oleh suatu interface dengan menerapkan konsep design pattern. Hal tersebut
bertujuan untuk memudahkan integrasi dengan lapisan aplikasi.
Implementasi ORM ini dibagi menjadi beberapa tahapan, yaitu: pemetaan Data Transfer
Object (DTO) dengan menghilangkan paradigma ketidaksesuaian antara basis data relasional dan
pemrograman berorientasi objek, membuat fungsi-fungsi akses data dengan mengimplementasikan
DAO pattern, menyederhanakan fungsi akses data dengan memanfaatkan konsep design pattern,
membuat skema basis data, dan menyatukan lapisan persistensi dengan lapisan aplikasi.
Implementasi konsep ORM terbukti dapat menghilangkan ketidaksesuian tersebut. Selain itu

penerapan ORM yang dilengkapi dengan design pattern membuat sistem ERP menjadi lebih
terstruktur dan mudah untuk dikembangkan.
Kata kunci: Object Relational Mapping (ORM), object relational mismatch, basis data relasional,
object oriented, design pattern.

v

RIWAYAT HIDUP
Penulis dilahirkan di Tasikmalaya pada tanggal 23 Juni 1986 sebagai anak pertama dari dua
bersaudara dari pasangan Ana Suparjana dan Dedeh Juliarsih. Penulis menyelesaikan pendidikan
menengah atas di SMU Negeri 1 Tasikmalaya dan lulus pada tahun 2004.
Pada tahun yang sama penulis diterima sebagai mahasiswa Departemen Ilmu Komputer,
Fakultas Matematika dan Ilmu Pengetahuan Alam, Institut Pertanian Bogor. Penulis diterima
melalui jalur Undangan Seleksi Masuk IPB (USMI). Penulis pernah pelaksanaan kegiatan Praktek
Kerja Lapangan di PT. Sigma Karya Sempurna (Balicamp) sebagai Software Tester untuk Proyek
Panin Business Internet Banking.
Selama kuliah penulis aktif dalam beberapa kegiatan kemahasiswaan terutama di
Himpunan Mahasiswa Ilmu Komputer (Himalkom). Pada saat di Himalkom penulis bertugas
sebagai Bendahara 1. Pada tahun 2007 penulis aktif di komunitas KPLI-Bogor (Kelompok
Pengguna Linux Indonesia-Bogor) sebagai Sekretaris. Saat ini penulis aktif sebagai anggota Java

Campus Team di Departemen Ilmu Komputer.

vi

PRAKATA
Puji dan syukur penulis panjatkan kepada Allah SWT atas limpahan nikmat dan hidayahNya sehingga penulis dapat menyelesaikan karya ilmiah ini. Sholawat dan salam semoga
senantiasa tercurah kepada Nabi besar Muhammad SAW, keluarganya, para sahabat, serta para
pengikutnya yang tetap istiqomah mengemban risalah-Nya.
Penulis ingin menyampaikan penghargaan dan terima kasih kepada Bapak Wisnu Ananta
Kusuma, S.T., M.T. selaku pembimbing I, yang telah meluangkan waktunya untuk membimbing
penulis, memberikan ilmu-ilmu yang berharga, serta dukungan selama penelitian ini berlangsung.
Penulis juga mengucapkan terima kasih kepada Bpk. Toto Haryanto, S.Kom. selaku pembimbing
II, yang telah membimbing penulis dan selalu memberikan semangat, serta penulis mengucapkan
terima kasih kepada Bapak Irman Hermadi, S.Kom.,M.S. yang telah bersedia menjadi penguji
dalam pelaksanaan seminar dan sidang.
Kemudian penulis ucapkan terima kasih kepada seluruh keluarga khususnya kepada kedua
orang tua dan Ulfa atas doa, dukungan, kasih sayang, dan pengorbanannya selama ini. Disamping
itu, penulis ingin mengucapkan terima kasih kepada Mas Ifnu yang selalu memberi semangat,
memberi dukungan untuk terus menyelesaikan tugas akhir, dan pengorbanan yang diberikan
selama penelitian ini berlangsung.

Penulis juga mengucapkan terima kasih kepada Halida dan Dany yang telah memberikan
banyak pengalaman berharga selaku rekan seperjuangan dalam menyelesaikan aplikasi penelitian
ini. Upacan terima kasih dari penulis teruntuk Bang Robi dan Kak Ria yang selalu memberikan
masukan dan meluangkan waktu untuk berdiskusi ERP. Kepada Dhiku dan Pak Endy, terima kasih
untuk referensi dan tutorial Java-nya.
Kemudian penulis ucapkan terima kasih kepada Dwi, Ina, Heni, Endang dan Tri yang telah
membantu selama penulisan tugas akhir dan memberi dukungan ketika seminar dan sidang. Serta
terima kasih kepada Dita, Vina, Dwi, dan teman-teman “New Arini” lainnya yang telah
memberikan wawasan dan keceriaan kepada penulis. Semua teman-teman ilkomerz’41, terima
kasih untuk canda tawa, persahabatan, dan kebersamaan selama kuliah di Ilkom IPB.
Penulis mengucapkan terima kasih kepada seluruh staf pengajar yang telah memberikan
wawasan serta ilmu yang berharga selama penulis menuntut ilmu di Departemen Ilmu Komputer.
Seluruh staf administrasi dan perpustakaan Departemen Ilmu Komputer yang selalu memberi
kemudahan dalam mengurus segala macam hal berkaitan dengan perkuliahan, serta pihak-pihak
lain yang tidak dapat disebutkan satu-persatu.
Sebagaimana manusia yang tidak luput dari kesalahan, penulis menyadari bahwa karya
ilmiah ini jauh dari sempurna. Namun penulis berharap semoga karya ilmiah ini dapat bermanfaat
bagi siapapun yang membacanya. Semoga tulisan ini dapat bermanfaat khususnya untuk penulis
pribadi, umumnya untuk semua warga Institut Pertanian Bogor.

Bogor, Juni 2008

Dian Indah Savitri

DAFTAR ISI
Halaman
DAFTAR ISI ...................................................................................................................................vii
DAFTAR GAMBAR .....................................................................................................................viii
DAFTAR LAMPIRAN ..................................................................................................................viii
PENDAHULUAN
Latar Belakang............................................................................................................................. 1
Tujuan Penelitian ......................................................................................................................... 1
Ruang Lingkup Penelitian ........................................................................................................... 1
Manfaat Penelitian ....................................................................................................................... 1
TINJAUAN PUSTAKA
Enterprise Resource Planning ..................................................................................................... 1
Basis Data Relasional .................................................................................................................. 2
Persistent Object ......................................................................................................................... 2
Object Relational mismatch ......................................................................................................... 2
Object Relational Mapping ......................................................................................................... 3

Framework .................................................................................................................................. 3
Design pattern dan JEE pattern ................................................................................................... 3
Model View Controller ................................................................................................................ 4
Declarative Transaction .............................................................................................................. 4
Dependency Injection / Inversion of Control ............................................................................... 5
METODE PENELITIAN .................................................................................................................. 5
Kerangka Pemikiran .................................................................................................................... 5
Studi Literatur .............................................................................................................................. 5
Analisis Kebutuhan ORM ........................................................................................................... 5
Implementasi ORM dan Design Pattern .................................................................................... 5
Evaluasi ....................................................................................................................................... 5
HASIL DAN PEMBAHASAN
Analisis Kebutuhan ORM pada Sistem ERP ............................................................................... 6
1 Deskripsi Umum Aplikasi Ritel ERP ................................................................................. 6
2 Analisis Masalah Ketidaksesuaian...................................................................................... 6
a granularity ..................................................................................................................... 6
b identitas ......................................................................................................................... 6
c asosiasi .......................................................................................................................... 7
d navigasi data .................................................................................................................. 7
Implementasi ORM dan Design Pattern ..................................................................................... 7

1 Melakukan Konfigurasi Basis Data ................................................................................... 7
2 Membuat Class DTO (Data Transfer Object) ................................................................... 7
a Aspek Granularity ......................................................................................................... 8
b Aspek Identitas .............................................................................................................. 8
c Aspek Asosiasi .............................................................................................................. 8
d Aspek Navigasi data .................................................................................................... 10
3 Membuat Fungsi Akses Data. .......................................................................................... 11
4 Penyederhanaan Fungsi Akses Data ................................................................................ 12
5 Membuat Skema Basis Data. ........................................................................................... 13
6 Menyatukan Lapisan Persistensi dengan Lapisan Aplikasi ............................................ 13
Evaluasi ..................................................................................................................................... 14

viii

KESIMPULAN DAN SARAN
Kesimpulan ................................................................................................................................ 14
Saran .......................................................................................................................................... 15
DAFTAR PUSTAKA ..................................................................................................................... 15
LAMPIRAN .................................................................................................................................... 16

DAFTAR GAMBAR
Halaman
1 Mekanisme ORM. .......................................................................................................................... 3
2 Arsitektur MVC (Wahab 2007). ..................................................................................................... 4
3 Diagram Metodologi Penelitian. .................................................................................................... 5
4 Skema pembuatan DTO. ................................................................................................................ 8
5 Pemetaanf asosiasi one-to-one. ...................................................................................................... 8
6 Pemetaan asosiasi one-to-many. ..................................................................................................... 9
7 Pemetaan asosiasi many-to-many ................................................................................................. 10

DAFTAR LAMPIRAN
Halaman
Lampiran 1 Daftar Tabel ................................................................................................................. 17
Lampiran 2 Class Diagram Data Transfer Object .......................................................................... 19
Lampiran 3 ER Diagram ................................................................................................................. 26
Lampiran 4 Kamus data .................................................................................................................. 30
Lampiran 5 Teknik Inversion of Controls ....................................................................................... 46
Lampiran 6 Declarative Transaction untuk setiap modul ............................................................... 53
Lampiran 7 Contoh Kode Program ................................................................................................. 54

1

PENDAHULUAN

Tujuan Penelitian
Tujuan dari penelitian ini adalah:

Latar Belakang
Enterprise Resource Planning (ERP)
merupakan suatu aplikasi terintegrasi yang
difokuskan untuk mengotomasi seluruh
aktivitas
infrastruktur
dalam
suatu
perusahaan. Sistem ERP menggabungkan
proses bisnis antara perusahaan dan
pelanggan, perusahaan dengan supplier, dan
proses perhitungan keuangan perusahaan.
Semua proses bisnis yang tergabung
mengakses pada sebuah basis data yang
terpusat (Parr 2000).
Sebagian besar aplikasi yang berskala
enterprise
dikembangkan
dengan
pendekatan berorientasi objek menggunakan
three-tier-architecture yang terdiri atas
lapisan presentasi, lapisan aplikasi, dan
lapisan basis data (Rashid et al. 2002).
Sementara itu, sistem manajemen basis data
yang banyak digunakan sekarang ini adalah
basis data relasional. Dengan demikian,
terdapat
ketidaksesuaian
(mismatch
paradigm) antara basis data relasional yang
digunakan dan aplikasi yang dikembangkan
dengan pendekatan berorientasi objek.
Ketidaksesuaian tersebut antara lain aspek
granularity, subtypes, identitas, asosiasi,
dan navigasi data (Bauer & King 2007).
Untuk mengatasi masalah ini Nugraha
(2005) melakukan penelitian mengenai
konsep ORM (Object Relational Mapping)
yang berfungsi memetakan antara class dan
tabel. Pada prinsipnya, penelitian tersebut
menunjukan bahwa Object Relational
Mapping (ORM) adalah sebuah solusi yang
dapat
menjembatani
paradigma
ketidaksesuaian antara sistem basis data
relasional dan pengembangan aplikasi
berorientasi objek.
Namun demikian Nugraha (2005) hanya
membatasi penelitiannya pada aspek
pemetaan dan tidak diimplementasikan pada
aplikasi yang utuh. Pada penelitian ini,
dilakukan analisis terhadap aplikasi Ritel
ERP yang dikembangkan Ernita (2008)
untuk menunjukan adanya ketidaksesuaian
(mismatch) tersebut. Selanjutnya akan
diimplementasikan konsep ORM untuk
menghilangkan ketidaksesuaian tersebut
serta penerapan konsep design pattern yang
berfungsi dalam proses penyatuan dengan
lapisan aplikasi.

1

2

3

Menganalisis ketidaksesuaian yang
muncul dari rancangan sistem Ritel ERP
yang dikembangkan Ernita (2008) dan
basis data relasional yang digunakan.
Menerapkan konsep ORM untuk
mengatasi masalah ketidaksesuaian
tersebut.
Memanfaatkan konsep design pattern
dalam pengaksesan basis data oleh
lapisan aplikasi.

Ruang Lingkup Penelitian
Ruang lingkup penelitian ini adalah :
1

2

Membangun lapisan Model untuk
aplikasi Ritel ERP dengan menerapkan
konsep ORM dengan menggunakan satu
framework yang telah ada tanpa
membandingkan dengan framework
ORM lain.
Menerapkan konsep ORM pada aplikasi
Ritel ERP tetapi tidak disertai konsep
untuk manajemen backup data dan
pengelolaan data yang sudah tidak
terpakai.

Manfaat Penelitian
Penelitian
ini
diharapkan
dapat
bermanfaat dalam
pemeliharaan dan
pengelolaan manajemen basis data pada
pengembangan aplikasi ERP selanjutnya.
Selain itu, penerapan ORM dapat
menghemat koneksi pada server basis data
sehingga aplikasi ERP yang dikembangkan
lebih optimal.

TINJAUAN PUSTAKA
Enterprise Resource Planning
Enterprise Resource Planning (ERP)
adalah suatu aplikasi terintegrasi yang
difokuskan untuk mengotomasi seluruh
aktivitas infrastruktur perusahaan. Aplikasi
ERP menggabungkan proses bisnis antara
perusahaan dan pelanggan, perusahaan dan
supplier, dan proses perhitungan keuangan
perusahaan. ERP mengotomasi proses bisnis
perusahaan baik dari segi produksi,
distribusi, keuangan, waktu, dan sumber
daya manusia (Parr 2000).

2

Inti
modul
ERP
antara
lain
(Rashid et al. 2002) :
 Manajemen akuntasi dan keuangan.
 Manajemen manufacturing dan produksi.
 Manajemen transportasi, penjualan dan
distribusi.
 Manajemen sumber daya manusia
 Supply Chain Management (SCM).
 Customer Relationship Management
(CRM).
Pengembangan
aplikasi
ERP
menggunakan three-tier architecture yang
terdiri atas (Rashid et al. 2002):
 Lapisan presentasi berisi Graphical User
Interface (GUI) atau browser untuk data
entry atau untuk melakukan akses
terhadap fungsi sistem.
 Lapisan aplikasi berisi business rules,
fungsi, logika, perlakuan program
terhadap data yang diterima/ ditransfer
dari/ke server basis data.
fungsi
 Lapisan basis data berisi
manajemen data transaksi termasuk di
dalamnya metadata.
Basis Data Relasional
Basis data merupakan sekumpulan data
atau entitas beserta deskripsinya yang secara
logika berelasi, dibuat untuk memenuhi
kebutuhan informasi suatu organisasi serta
dapat digunakan bersama-sama. Tujuan
utama basis data adalah mengelola dan
mengolah data yang begitu kompleks secara
mudah, cepat dan efisien untuk berbagai
kebutuhan (Connolly & Carolyn 2002).
Pada basis data relasional, relation
berarti tabel, sehingga data disimpan dalam
bentuk tabel-tabel. Relation digunakan untuk
menyimpan informasi yang ditunjukan
dalam basis data. Setiap tabel mempunyai
atribut yang mewakili nama kolom dari tabel
tersebut. Konsep relation hanya berlaku
terhadap struktur lojik tidak mencakup
struktur fisik (Connolly & Carolyn 2002).
Persistent Object
Dalam pengembangan sistem, persistent
object didefinisikan sebagai objek yang
dihasilkan dari suatu sistem dan dapat
disimpan dalam waktu yang lama bahkan
bersifat permanen (Peak & Heudecker
2006).
Persistent object bisa disimpan dalam
bentuk basis data relasional, file system
dalam harddisk, file XML, Web Service,
ODBMS (Object Data Base Management

System), dan LDAP. Media penyimpanan
persistent object yang paling banyak
digunakan dalam pengembangan perangkat
lunak adalah basis data relasional. Hal ini
disebabkan pembuatan dan pengaksesan
basis data pada sistem manajemen basis data
relasional relaif mudah (Peak & Heudecker
2006).
Persistent object memudahkan proses
penyimpanan dan pengaksesan data.
Persistent object bersifat abstrak karena
dapat menyembunyikan detail bagaimana
suatu data disimpan dan diakses, sehingga
seakan-akan prosesnya secara detail tidak
terlihat
oleh
objek
lainnya
(Peak & Heudecker 2006).
Object Relational mismatch
Object Relational Mismatch adalah
ketidaksesuaian yang terjadi disebabkan
adanya perbedaan antara aplikasi yang
diimplementasikan
dengan
pendekatan
berorientasi objek dan penyimpanan data
yang menggunakan sistem basis data
relasional. Ketidaksesuaian tersebut meliputi
aspek:
1 Granularity
Ketidaksesuaian pada aspek granularity
menyangkut pada pemecahan entitas
menjadi atribut-atribut yang lebih
kompleks. Pada basis data relasional
tidak dikenal tipe data yang didefinisikan
oleh pengguna (user-defined-data-type).
Sebagai
contoh
class
Person
mempunyai atribut address dengan
tipe data address. Pada basis data
relasional tidak mungkin mendefinisikan
kolom address dengan tipe data
address juga. Hal yang paling
mungkin dilakukan adalah memecah
address menjadi street_address,
city_address,
zipCode_address
dan tetap dimasukan ke dalam tabel
Person.
2 Subtypes
Ketidaksesuaian pada aspek subtypes
adalah pembeda antara superclass dan
subclass. Pada pemrograman berorientasi
objek dikenal istilah
inheritance
(pewarisan) dari class parent kepada
class child, sedangkan pada basis data
relasional tidak dikenal proses pewarisan
antar tabel.
3 Identitas
Ketidaksesuaian pada aspek identitas
adalah adanya perbedaan pengenal

3

4 Asosiasi
Ketidaksesuaian pada aspek asosiasi
meliputi hubungan dua entitas yang
memiliki keterhubungan. Pada objek,
penghubung dua entitas tersebut dikenal
sebagai references sedangkan pada basis
data relasional dikenal dengan foreign
key. Asosiasi antarentitas terdiri atas:
one-to-one, one-to-many, dan many-tomany.
5 Navigasi data
Ketidaksesuaian pada aspek navigasi
data meliputi proses pengaksesan suatu
objek dari objek lain. Pada basis data
relasional navigasi data dilakukan
menggunakan query join sedangkan
pada pendekatan berorientasi objek
dilakukan dengan memanggil suatu
method getter. Navigasi dibagi dua
macam berdasarkan arahnya, antara lain:
directional
dan
bidirectional
(Bauer & King 2007).
Object Relational Mapping
Object Relational Mapping merupakan
suatu teknik untuk memetakan dari
persistent object pada aplikasi ke dalam
tabel pada basis data secara otomatis dan
transparan. Mekanisme ORM dapat dilihat
pada Gambar 1. ORM menggunakan
metadata untuk mendeskripsikan pemetaan
antara objek dan basis data (Bauer & King
2007).
ORM berperan sebagai lapisan model
dalam MVC pattern. Model adalah sebuah
lapisan yang paling dekat dengan sumber
data, baik itu berasal dari basis data,
webservice, maupun file system. ORM
merupakan solusi yang dapat mengatasi
ketidaksesuaian yang terjadi akibat adanya
perbedaan
antara
aplikasi
yang
diimplementasikan
dengan
pendekatan
berorientasi objek dan penyimpanan data

dengan menggunakan sistem basis data
relasional. Teknologi ORM ada beberapa
macam, seperti Toplink dari Oracle, Kodo
dari Bea System, dan Hibernate dari
RedHat.
Table1

Table3

OR Mapping

identitas antara objek dan tabel. Pada
objek terdapat dua cara untuk
membedakan objek yang satu dengan
objek
lainnya,
yaitu
dengan
menggunakan fungsi antara lambang
sama dengan (==) dan method
equals(). Lambang sama dengan
(==)merujuk pada alamat memori yang
sama, sedangkan method equals()
merujuk pada nilai secara lojik yang
sama. Akan tetapi pada basis data yang
membedakan tabel satu dengan tabel
yang lain adalah primary key.

Table2

database

Gambar 1 Mekanisme ORM
(Thamura et al. 2007).
Framework
Framework adalah aplikasi semicomplete yang dapat digunakan untuk
membuat aplikasi lain yang lebih spesifik
(Husted 2003). Framework yang ideal
merupakan intisari dari pendekatan terbaik
dalam pengembangan perangkat lunak.
Apabila suatu aplikasi dikembangkan
menggunakan framework maka harus
mengadopsi
semua
mekanisme
dan
ketentuan yang ditetapkan pada framework
tersebut. Suatu framework mempunyai
sekumpulan file library khusus. Alasan
pengembangan sebuah framework adalah
dimungkinkannya penggunaan kembali
perangkat lunak dalam pengembangan
selanjutnya.
Salah satu framework ORM adalah
Hibernate. Hibernate adalah salah satu ORM
framework open source yang dikembangkan
untuk menangani masalah data persistence
pada lingkungan Java. Hibernate terdiri atas
dua versi yaitu Hibernate Core dan
Hibernate Annotation. Hibernate Core
menggunakan file XML untuk melakukan
pemetaan terhadap objek-objek tabel pada
basis data, sedangkan Hibernate Annotation
menggunakan Java Annotation untuk
mapping terhadap basisdata.
Implementasi Hibernate pada kode
program
Java
menggunakan
HQL
(Hibernate Query Language) (Bauer dan
King 2007). Sebelum melakukan query
terhadap basisdata, terdapat beberapa
konfigurasi yang harus dilakukan, antara
lain menentukan dialect (jenis DBMS) yang
digunakan, class driver, dan file koneksi.

4

Design pattern dan JEE pattern
Design pattern adalah pola atau unsurunsur rancangan yang seringkali muncul
pada berbagai jenis sistem. Design pattern
merupakan katalog permasalahan yang
sering muncul beserta solusi yang sudah
teruji dalam perancangan sistem (Gamma et
al. 1995). Design pattern yang sering
dijadikan studi adalah design pattern yang
berasal dari Gang of Four (GoF) yaitu, Erich
Gamma, Richard Helm, Ralph Johnson, dan
John Vlissides.
GoF mengumpulkan pattern yang biasa
dipakai dalam membangun sebuah sistem
menjadi suatu katalog lengkap yang dapat
dipakai dalam memecahkan berbagai
masalah dalam pembangunan sebuah sistem.
Dengan mengetahui deskripsi lengkap dari
suatu permasalahan maka akan dapat dengan
mudah diketahui pattern apa yang cocok
sebagai solusi dari permasalahan tersebut
dan ketika menghadapi masalah yang sama
atau mirip maka pattern tersebut dapat
digunakan kembali (Wahab 2007).
Design pattern yang digunakan pada
penelitian ini antara lain (Gamma et al.
1995) :
a. Singleton adalah pola yang mengatur
suatu objek yang hanya mempunyai satu
instansiasi selama aplikasi berjalan.
b. Proxy adalah pola yang merancang
suatu objek untuk mewakili kontrol atau
akses objek lain dan bertindak seolaholeh objek tersebut melakukannya.
c. Façade
adalah
pola
yang
menyederhanakan objek-objek yang
terlihat rumit ke dalam sebuah interface.
d. Factory method adalah pola untuk
mengenkapsulasi suatu objek dan
diinstasiasi satu kali untuk digunakan
berulang-ulang oleh objek.
Selain GoF, juga terdapat Gang of Three
(GoT) yang terdiri atas Deepak Alur, John
Crupi, dan Dan Malks. JEE pattern
sebenarnya mengacu kepada design pattern
berdasarkan GoF dan memiliki fungsi yang
sama yaitu sebagai katalog permasalahan
dan solusi yang sudah teruji dalam
pengembangan spesifik aplikasi JEE. JEE
pattern yang dipakai pada penelitian ini
adalah DTO (Data Transfer Object) dan
DAO (Data Access Object).
Data Transfer Object (DTO) pattern
adalah pola yang mengenkapsulasi bisnis

data dan mengirimkannya secara sekaligus
dalam satu waktu (Alur et al. 2003). DTO
pattern juga berfungsi sebagai jembatan
penghubung antarlapisan dalam aplikasi.
Dengan pola ini proses perpindahan data
menjadi sederhana dan terintegrasi. Data
Access Object (DAO) pattern adalah pola
yang mengenkapsulasi data akses dan
manipulasi ke dalam lapisan yang berbeda
kemudian
diimplementasikan
dengan
membuat sebuah objek yang bersifat abstrak
dan mengenkapsulasi seluruh akses data.
(Alur et al. 2003).
Model View Controller
Model View Controler (MVC) pattern
adalah pola yang memisahkan antara
tampilan antarmuka (View), proses bisnis
(Controller), dan objek data (Model)
(McGovern 2003). Gambar 2 menunjukan
struktur Model View Controller pattern
(Wahab 2007). Lapisan Model merupakan
proses bisnis utama. Di dalamnya terdapat
kode untuk persistensi data dan proses
bisnis. Secara singkat, Lapisan Model ini
menangani isi dari aplikasi. Di lapisan ini
diputuskan data yang akan diberikan pada
client.
Sementara itu, lapisan View menangani
masalah-masalah yang berkaitan dengan
tampilan. Lapisan ini hanya melakukan
pengaturan terhadap data agar tampilannya
sesuai dengan kebutuhan pengguna. Lapisan
terakhir adalah lapisan Controller, lapisan
ini berfungsi mengatur alur pengguna. Pada
lapisan ini dilakukan pemrosesan request
untuk menentukan proses bisnis mana yang
akan dieksekusi. Biasanya layer controller
juga digunakan untuk mengatur ijin akses.
Controller

Manipulasi

Model

Interaksi

Ditampilkan

View

Gambar 2 Arsitektur MVC (Wahab 2007).
Declarative Transaction
Declarative Transaction adalah suatu
teknik untuk
medeklarasikan semua
transaksi dalam suatu file konfigurasi untuk
menangani semua proses transaksi tanpa
harus membuat kode-kode program untuk
menangani transaksi secara eksplisit. Selain

5

itu mengatur rollback (method dan
exception) apabila terjadi kegagalan
transaksi (Walls & Beidenbach 2005 ).
Dependency
Control

Injection

/

Inversion

of

Dependency Injection adalah suatu
konsep yang diterapkan oleh suatu objek
untuk mendapatkan objek lain yang
dibutuhkan tanpa harus mencari dan
memasukan objek tersebut secara eksplisit
(Walls & Beidenbach 2003)
Konsep ini diterapkan dalam Spring
framework. Semua DAO yang didefinisikan
tidak harus menuliskan koneksi basis
datanya secara langsung pada masingmasing DAO, tetapi cukup memasukkan
koneksinya menjadi suatu konstruktor atau
method
setter
dalam
DAO
(Thamura et al. 2007).

METODE PENELITIAN
Kerangka Pemikiran
Tahap-tahap yang dilakukan pada
penelitian ini diilustrasikan pada Gambar 3.
Penelitian diawali dengan studi literatur
kemudian
melakukan
analisis
ketidaksesuaian (mismatch) pada aplikasi
Ritel ERP (Ernita 2008) yang memunculkan
kebutuhan ORM. Tahap selanjutnya adalah
merancang dan mengimplementasikan ORM
dan design pattern untuk mengatasi masalah
ketidaksesuian tersebut. Tahap terakhir
adalah
melakukan
evaluasi
hasil
implementasi konsep ORM tersebut.
Studi literatur

Analisis
permasalahan
ketidaksesuaian

Perancangan dan
implementasi ORM
dan design pattern

evaluasi

Gambar 3 Diagram Metodologi Penelitian.

Studi Literatur
Studi
literatur
diawali
dengan
menganalisis ORM framework yang tersedia
di lingkungan JEE. Selain itu, dilakukan
juga studi literatur dengan menganalisis
paper yang terkait.
Analisis Permasalahan Ketidaksesuaian
Aplikasi Ritel ERP (Ernita 2008)
dikembangkan
dengan
pendekatan
berorientasi objek, sedangkan manajemen
basis
datanya
menggunakan
sistem
manajemen basis data relasional. Oleh
karena itu dilakukan analisis kemungkinan
ketidaksesuaian (mismatch) yang disebabkan
perbedaan paradigma tersebut.
Perancangan dan Implementasi ORM
dan Design Pattern
Pada tahap ini, dilakukan implementasi
ORM
dan
design
pattern
untuk
menghilangkan
ketidaksesuaian
yang
muncul dari tahap analisis. ORM
diimplementasikan menjadi enam tahap,
antara lain:
1
2

3

4

5
6

Membuat konfigurasi basis data.
Membuat pemetaan Data Transfer
Object (DTO) dengan menghilangkan
paradigma ketidaksesuaian antara basis
data relasional dan pemrograman
berorientasi objek.
Membuat fungsi-fungsi akses data
sebagai implementasi dari DAO
pattern, singleton pattern, dan factory
method pattern.
Menyederhanakan fungsi akses data
dengan memanfaatkan konsep facade
pattern dan proxy pattern.
Membuat skema basis data.
Menyatukan lapisan persistensi dengan
lapisan aplikasi.

Evaluasi
Pada tahap evaluasi dilakukan analisis
terhadap hasil implementasi ORM untuk
mengatasi ketidaksesuaian dari rancangan
aplikasi Ritel ERP dan basis data relasional
yang digunakan. Selain itu evaluasi juga
dilakukan terhadap konsep design pattern
yang digunakan.

6

HASIL DAN PEMBAHASAN
Analisis Permasalahan Ketidaksesuaian
Untuk mendapatkan gambaran yang
lebih lengkap terhadap Ritel ERP (Ernita,
2008) yang akan dianalis, berikut ini
diuraikan deskripsi umum ERP untuk
perusahan Ritel tersebut.
1 Deskripsi Umum Aplikasi Ritel ERP
Sistem ERP Ritel yang dikembangkan
Ernita (2008) terdiri atas tiga mudul, antara
lain:
Modul pembelian (Business to Business)
 Purchase Requisition (PR) yang dikirim
oleh kepala gudang kepada pihak
pengadaan barang.
 Request for Quotation (RFQ) dan
Purchase Order (PO) yang dikirim oleh
bagian pengadaan kepada supplier.
 Demand Order (DO) yang dikirim oleh
supplier kepada bagian pengadaan
barang.
 Goods Receive yang diperiksa oleh
kepala gudang saat barang diterima.
 Manajemen Inventory.
 Daftar supplier.
Modul Penjualan (Business-to-Customer)
 Daftar katalog yang ditampilkan kepada
pelanggan.
 Submodul pemesanan (add to cart)
 Konfirmasi tagihan dan pembayaran.
 Pengantaran barang.
 Daftar pelanggan.
Modul akuntansi
 Jurnal buku besar (General Ledger)
 Konfirmasi tagihan dan pembayaran.
 Account Receivable (AR)
 Account Payable (AP)
 Manajemen kode akun.
Masing-masing modul pembangun Ritel
ERP tergabung pada satu basis data yang
terpusat.
2 Analisis Masalah Ketidaksesuaian
Aplikasi Ritel ERP membutuhkan basis
data dalam menjalankan proses bisnisnya.
Tiga modul utama pembangun aplikasi Ritel
ERP mengakses pada satu basis data yang
terpusat. Setiap modul mempunyai tabel
master untuk inisialisasi data dari
lingkungan proses bisnis aplikasi Ritel ERP
dan tabel transaksi sebagai hasil transaksi
saat menjalankan proses bisnisnya. Tabel
master dan tabel transaksi yang dirancang

untuk membangun aplikasi Ritel ERP dapat
dilihat pada Lampiran 1.
Pada penelitian ini, aplikasi Ritel ERP
dikembangkan
dengan
pendekatan
berorientasi objek menggunakan bahasa
pemrograman Java, sedangkan sistem
manajemen basis data yang digunakan
adalah basis data relasional. Oleh karena itu,
terdapat ketidaksesuaian (mismatch) yang
ditimbulkan pada perbedaan konsep
tersebut. Pada penelitian ini, tidak semua
aspek ketidaksesuaian ditemukan. Aspek
ketidaksesuaian yang muncul adalah aspek
granularity, identitas, asosiasi antarentitas,
dan navigasi data.
Uraian berikut memaparkan analisis
ketidaksesuaian pada aspek:
a Granularity
Ketidaksesuaian pada aspek granularity
terjadi karena pada basis data relasional
tidak mengenal user-defined-data-type atau
tipe data yang didefinisikan oleh pengguna.
Ketidaksesuaian aspek granularity yang
ditemukan pada penelitian ini terjadi saat
mendefinisikan properti address pada
entitas Supplier. atribut Address terdiri
atas street, town, state, zip_code.
Aribut address akan dipisahkan menjadi
class berbeda saat pembuatan DTO, akan
tetapi setelah dipetakan tetap masuk sebagai
proserti tabel PU_SUPPLIER.
b Identitas
Ketidaksesuaian pada aspek identitas
terkait dengan perbedaan pengenal identitas
objek dan tabel. Pada objek identitas
dibedakan menjadi nilai dan alamat
memorinya. Oleh karena itu, terdapat dua
notasi yang melambangkan kesamaan suatu
identitas, yaitu lambang sama dengan (==)
dan method equals(). Sebagai contoh
(a == b), berarti variabel a dan b
memegang alamat reference yang sama pada
memori, sedangkan (a.equals(b)),
secara lojik mempunyai nilai yang sama.
Pada basis data relasional, identitas dari
suatu tabel disebut dengan primary key.
Dengan demikian, sering kali terjadi objek
yang secara lojik sama (a.equals(b))
dan mewakili satu baris dalam tabel basis
data, tetapi objek tersebut tidak berada pada
satu lokasi alamat memori yang sama.

7

c Asosiasi

1 Melakukan Konfigurasi Basis Data

Kebanyakan entitas pada basis data
mempunyai keterhubungan dengan entitas
yang lainnya. Elemen yang menghubungkan
kedua tabel tersebut ditandai dengan foreign
key.

Tahap konfigurasi merupakan tahap awal
sebelum melakukan akses terhadap basis
data. Konfigurasi basis data disimpan pada
file jdbc.properties. Isi dari file
jdbc.properties adalah sebagai berikut:

Elemen penghubung dua objek ditandai
dengan
sebuah
reference
object.
Permasalahannya adalah reference object
bergantung pada arah dari asosiasinya
(direction of relationship). Apabila asosiasi
antara dua objek terjadi pada dua arah, maka
harus didefinisikan dua kali pada setiap
classnya. Akan tetapi foreign key pada tabel
relasional tidak mengenal arah dari
asosiasinya, karena asosiasi antara dua tabel
dihubungkan dengan tabel join.

1
2
3
4
5
6
7
8
9
10

Ketidaksesuaian pada aspek asosiasi
meliputi relasi one-to-one, one-to-many, dan
many-to-many. Masing-masing asosiasi
antarentitas bisa dilihat pada class diagram
dan ER diagram pada Lampiran 2 dan
Lampiran 3.
d Navigasi data
Ketidaksesuaian pada aspek navigasi
terkait
dengan
masalah
bagaimana
mengakses suatu objek yang berasal dari
objek lain. Menurut arahnya, navigasi data
terbagi menjadi dua macam, yaitu:
unidirectional dan bidirectional. Pada
konsep pemrograman berorientasi objek
konsep arah navigas menentukan suatu
objek dapat diakses melalui objek lain,
sedangkan pada basis data relasional konsep
arah navigasi tidak mempengaruhi proses
pengaksesan data dari tabel lain.
Pada konsep pemrograman berorientasi
objek, proses akses properti objek dari objek
lain bisa langsung menggunakan method
getter. Lain halnya dengan basis data
relasional,
properti
yang
menjadi
penghubung antara dua tabel yang berelasi
yaitu foreign key.
Perancangan dan Implementasi ORM
dan Design Pattern
Setelah
ditemukan
empat
aspek
ketidaksesuaian tersebut diimplementasikan
ORM. Selain itu juga diterapkan design
pattern
untuk
menghilangkan
ketidaksesuaian yang muncul pada tahap
analisis tersebut, meliputi:

jdbc.username=root
jdbc.password=admin
jdbc.url=jdbc:mysql://localhost:
3306/erp
jdbc.driver=com.mysql.jdbc.Driver
hibernate.dialect=org.hibernate.
dialect.MySQL5InnoDBDialect
hibernate.show_sql=true
hibernate.hbm2ddl.auto=create
hibernate.format_sql=true

Baris pertama sampai ke lima merupakan
properti konfigurasi koneksi basis data yang
berisi username, password, host dan port
basis data, dan library koneksi yang
digunakan.
Kode pada baris ke enam menentukan
jenis dialek SQL yang akan dipetakan. Baris
ke delapan adalah properti untuk
menampilkan hasil query yang telah diubah
ke dalam bentuk SQL. Baris ke sembilan
merupakan
properti
yang
berfungsi
mengotomasi pembuatan basis data dari
awal sampai akhir. Dan baris ke sepuluh
untuk menghasilkan query dengan format
SQL.
2 Membuat Class DTO (Data Transfer
Object)
DTO
merupakan
class
yang
merepresentasikan setiap tabel pada basis
data. DTO dibuat berdasarkan UML class
diagram yang telah dirancang. DTO berisi
class JavaBean yang setiap propertinya akan
merepresentasikan atribut-atribut pada tabel.
Skema
proses
pembuatan
DTO
diilustrasikan pada Gambar 4.

8

Product
-id : int
-prodName : string
-unitPrice : double

public class
private
private
private
//getter and
}

Product{
int id;
String prodName;
Double unitPrice;
setter method

product
PK

id : int
prod_name : varchar
unit_price : longint

Prod_ID

Prod_name

Unit
price

1

pupuk

100

2

bibit

200

Gambar 4 Skema Pembuatan DTO.
Ketidaksesuaian yang muncul pada tahap
analisis diatasi oleh ORM pada saat
merepresentasikan class DTO dan diakses
sebagai objek.
Uraian
berikut
menjelaskan
implementasi konsep ORM untuk mengatasi
ketidaksesuaian pada aspek granularity,
identitas, asosiasi, dan navigasi data.
a Aspek Granularity
Proses pemetaan untuk memecah entitas
menjadi entitas yang lebih kompleks pada
atribut address dalam entitas Supplier
menjadi satu entitas address ditulis sebagai
berikut:

- Class Supplier
1
2
3
4
5
6
7

@Entity
@Table(name = "PU_SUPLIER")
public class Supplier{
@Embedded
private Address address = new
Address();
}

-

Class Address

1
2
3
4
5
6

@Embeddable
public class Address {
private String street;
private String city;
private String zipCode;
}

Properti @Embeddable pada baris
pertama class Address mengindikasikan

bahwa class Address merupakan entitas
yang bisa dilekatkan atau dimasukan ke
dalam entitas lain. Properti @Embedded di
baris ke lima pada class Supplier
menandakan bahwa entitas Address
melekat pada entitas Supplier.
b Aspek Identitas
ORM mengatasi ketidaksesuaian pada
aspek identitas dengan menambah properti
identity pada setiap entitas atau class DTO
seperti pada potongan program berikut:
1
2
3
4
5
6
7
8
9

@Entity
@Table(name = "IN_ITEM")
public class Item{
@Id
@GeneratedValue(strategy=
GenerationType.AUTO)
@Column(name="id")
private Long id;
}

Kode pada baris pertama dan kedua
menandakan bahwa class tersebut mewakili
sebuah entitas pada basis data dengan nama
tabel IN_ITEM.
@Id pada baris ke empat merupakan
properti yang merepresentasikan primary
key, secara lojik properti @Id pada class a
berbeda dengan @Id pada class b. Dengan
demikian pengujian apakah isi class a sama
dengan class b bisa ditulis seperti berikut:
a.getid().equals(b.getId()).
Properti @GeneratedValue (strategy
=
GenerationType.AUTO
merupakan
pengisian id yang secara otomasi seperti
auto_increment pada tabel relasional.

c Aspek Asosiasi
Asosiasi antara dua entitas terdiri atas
one-to-one, one-to-many, dan many-tomany. Proses pemetaan asosiasi antara dua
entitas adalah sebagai berikut:
 One-to-one

Gambar 5 Pemetaan Asosiasi one-to-one.

9

Gambar 5 merupakan ilustrasi dari class

 One-to-many

Demand yang berasosiasi one-to-one dengan
class Order. Letak foreign key atau join
column ditambahkan pada entitas yang

mempunyai total participation pada asosiasi
yang menghubungkannya.
Pada entitas yang mempunyai asosiasi
dua
arah
(bidirectional)
diperlukan
penambahan properti mappedBy oleh
entitas yang tidak total participation (entitas
partial participation), sedangkan pada
entitas yang mempunyai asosiasi satu arah
(unidirectional) tidak perlu menambahkan
properti mappedBy.
Proses pemetaan dua class Demand dan
class Order merupakan contoh asosiasi dua
arah (association bidirectional) dan class
Demand bersifat
total participation.
Pemetaan class Demand dan class Order
dapat dituliskan sebagai berikut:
-

Class Order

1
2
3
4
5
6

@Entity
@Table(name="pu_order")
public class Order {
@OneToOne (mappedBy="order")
private Demand demand;
}

-

Class Demand

1
2
3
4
5
6
7

@Entity
@Table(name="pu_demand")
public class Demand {
@OneToOne
@JoinColumn (name="id_order")
private Order order;
}

Properti Join Column dimasukan pada
class Demand karena entitas Demand
mempunyai total participation. Dengan
demikian, objek Demand menentukan
asosiasi antara dua entitas tersebut.
Asosiasi one-to-one di atas disebut
biderectional karena masing-masing class
memerlukan
reference
yang
menghubungkannya. Baris empat dan baris
enam pada class Demand menandakan suatu
reference yang mewakili foreign key dari
entitas Order. Begitu pula pada class
Order, reference yang menghubungkannya
ditulis dengan mappedBy yang dituliskan
pada baris ke empat dan lima. Properti
mappedBy=”order” pada class Order
merujuk pada nama atribut order pada
class Demand.

Gambar 6 Pemetaan Asosiasi one-to-many.
Gambar 6 merupakan ilustrasi class
yang berasosiasi one-tomany dengan class RequisitionDetail.
Jadi setiap satu objek Requisition terdiri
atas banyak objek RequisitionDetail.
Requisition

Seperti halnya asosiasi one-to-one,
asosiasi one-to-many mempunyai join
column yang disimpan pada entitas yang
mempunyai total participation. Akan tetapi
pada asosiasi one-to-many, entitas yang
mempunyai total participation pasti berada
pada entitas yang berkardinalitas many.
Dengan demikian, dapat dikatakan join
column berada pada entitas dengan
kardinalitas many.
Class Requisition berasosiasi one-tomany dengan class RequisitionDetail.
Apabila asosiasinya bidirectional, maka
dapat
dikatakan
class
RequisitionDetail berasosiasi many-toone dengan class Requisition. Proses
pemetaannya ditulis sebagai berikut:

- Class RequisitionDetail
1
2
3
4
5
6
7

@Entity
@Table (name="pu_req_detail")
Public class RequisitionDetail {
@ManyToOne
@JoinColumn (name="id_req")
private Requisition requisition;
}

-

Class Requisition

1
2
3
4
5
6
7
8
9

@Entity
@Table(name="pu_req")
public class Requisition{
@OneToMany(mappedBy =
"requisition")
private List
reqDetail = new ArrayList
();
}

Asosiasi many-to-one di atas bersifat
biderectional, sehingga properti join

10

berada pada entitas yang
berkardinalitas
many
yaitu
class
RequisitionDetail. Akan tetapi pada
entitas
yang
berkardinalitas
one
ditambahkan properti mappedBy sebagai
reference.
column

Properti asosiasi dan reference dalam
class RequisitionDetail ditulis pada
baris empat dan baris lima. Pada class
PurchaseRequisition, reference yang
menghubungkannya
ditulis
dengan
mappedBy seperti pada baris empat sampai
baris delepan.
Apabila
asosiasinya
unidirectional,
properti
mappedBy
pada
class
Requisition
dihilangkan.
Properti
mappedBy = “requisition” merujuk
kepada atribut “requisition” pada class
RequisitionDetail.
 Many to many

-

Class Group

1
2
3
4
5
6
7
8
9

@Entity
@Table(name = "ad_group")
public class Group {
@ManyToMany(mappedBy=
"groups")
private List
moduls = new ArrayList
();
}

- Class Modul
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

@Entity
@Table(name="ad_modul")
public class Modul {
@ManyToMany
@JoinTable (name =
"ad_modul_group",
joinColumns={
@JoinColumn(name=
"id_ad_modul")},
inverseJoinColumns={
@JoinColumn(name=
"id_ad_group")})
private List groups =
new ArrayList < Group>();
}

Peoperti Join table dimasukan pada
properti yang mempunyai total participation
yaitu class Modul. Objek Modul
menentukan asosiasi pada kedua entitas
tersebut.
Gambar 7 Pemetaan Asosiasi many-to-many.
Gambar 7 merupakan ilusrasi class
Group berasosiasi many-to-many dengan
class Modul. Kedua entitas yang berasosiasi

many-to-many dihubungkan oleh reference
berupa join tabel. Join tabel memiliki
dua buah atribut foreign key yang berasal
dari masing-masing entitas.
Atribut join tabel dimasukan pada
entitas yang memilki total participation
pada asosiasi tersebut. Properti mappedBy
ditambahkan
kepada
entitas
partial
participation apabila asosiasinya dua arah
(bidirectional), sedangkan pada entitas yang
mempunyai
asosiasi
satu
arah
(unidirectional) tidak perlu menambahkan
properti mappedBy.
Proses pemetaan asosiasi di atas
merupakan asosiasi dua arah (association
bidirectional) dan entitas Modul mempunyai
total participation. Pemetaan class Group
dan class Modul dituliskan seperti berikut:

Asosiasi many-to-many di atas bersifat
biderectional karena masing-masing class
memerlukan
reference
yang
menghubungkannya. Properti many-to-many
pada class Modul ditulis pada baris empat.
Kemudian
reference
yang
menghubungkannya berupa join table
yang terdiri atas identity dari masing-masing
entitas. Properti join table ditulis pada
baris lima sampai empat belas dalam class
Modul. Dalam class Group, reference yang
menghubungkannya ditulis pada baris empat
sampai
baris
delapan.
Properti
mappedBy=”groups” pada class Group
merujuk pada nama atribut groups pada
class Modul.
Hasil pemetaan dari asosiasi many-tomany antara dua class tersebut adalah dua
tabel hasil transformasi dari objek yaitu
AD_MODUL dan AD_GROUP kemudian satu
tabel asosiasi AD_MODUL_GROUP.
d Aspek Navigasi data
Pada konsep pemrograman berorientasi
objek, proses akses properti objek dari objek

11

lain bisa langsung menggunakan method
getter. Contoh:

- Class Item
1
2
3
4
5
6
7

@Entity
@Table(name = "IN_ITEM")
public class Item {
@ManyToOne
@JoinColumn(name="id_brand")
private Brand brand;
}

Class Item mempunyai variabel brand
dengan tipe data Brand seperti ditulis pada
baris ke enam. Untuk mengakses nilai
brand dengan tipe data Brand pada class
Item menggunakan method getter seperti
berikut:
invItem.getInvProdBrand.getName();

Apabila arah navigasinya unidirectional,
maka tidak terdapat properti entitas Item
pada class Brand, sehingga class Brand
tidak bisa mengakses properti entitas Item.
Tetapi
apabila
arah
navigasinya
bidirectional, maka pada class Brand
terdapat properti entitas Item seperti
berikut:
-

Class Brand

1
2
3
4
5
6

@Entity
public class Brand {
@OneToMany(mappedBy="brand")
private List item = new
ArrayList();
}

Properti mappedBy pada baris ke tiga
menandakan
bahwa
class
tersebut
mempunyai asosiasi bidirectional. Untuk
mengakses variabel item dengan tipe data
Item
dari class Brand menggunakan
method getter seperti berikut:

Select * from IN_ITEM i left
outer join IN_PROD_BRAND pb on
i.id=pb.id where i.id=123

Properti left outer join menandakan
bahwa foreign key berada pada tabel ITEM.
3 Membuat Fungsi Akses Data
Pada penelitian ini, DAO pattern
digunakan untuk proses enkapsulasi fungsi
untuk mengakses data ke dalam lapisan yang
berbeda, sehingga aplikasi tidak perlu
mengetahui detail proses suatu data diakses.
DAO berisi method (fungsi) untuk
mengakses dan memanipulasi data. Pada
penerapannya,
DAO
dapat
diimplementasikan dengan native query atau
bahasa query basis data relasional (Structure
Query language). DAO juga dapat
diimplementasikan dengan konsep ORM
dengan menggunakan HQL (Hibernate
Query Language).
Proses pembuatan fungsi-fungsi akses
dan manipulasi data memanfaatkan konsep
design pattern, yaitu factory method dan
singleton. Sebelum melak