BAB 2 LANDAS AN TEORI
2.1 Teori-teori Dasar atau Umum 2.1.1 Pengertian Sistem Sistem adalah sekumpulan komponen yang berhubungan yang bekerja sama untuk mencapai tujuan dengan menerima masukan dan menghasilkan keluaran dalam sebuah proses transformasi yang terorganisasi (O’Brien, 2003, p8). M enurut M ulyadi (1997, p2) sistem merupakan sekelompok unsur yang erat berhubungan satu dengan lainnya, yang berfungsi bersama-sama untuk mencapai tujuan tertentu. Jadi, dapat disimpulkan bahwa sistem adalah sekumpulan objek atau komponen yang berhubungan satu dengan lainnya untuk mencapai tujuan tertentu.
2.1.2 Pengertian Data dan Informasi M enurut Turban et al. (2003, p15), dikemukakan bahwa data adalah fakta atau gambaran dasar benda, kejadian, aktivitas dan transaksi yang ditangkap, dicatat, disimpan dan dikelompokkan, tetapi tidak diatur untuk menyampaikan suatu arti khusus. Sedangkan informasi adalah adalah suatu kumpulan fakta (data) yang telah diatur sedemikian rupa sehingga memiliki arti bagi pengguna. 9
2.1.3 Pengertian Basis Data M enurut Connolly dan Begg (2002, p14), basis data merupakan sekumpulan data yang saling berhubungan dan deskripsi dari data itu sendiri, yang didesain untuk mencakup informasi yang diperlukan untuk organisasi. Sedangkan menurut Hoffer, George, dan Valencias (1996, p12), basis data adalah koleksi dari data yang berhubungan secara logical dan diatur sedemikian rupa sehingga dapat memfasilitasi penyimpanan (storage) beserta penarikan data (retrieval) untuk user yang banyak dalam sebuah organisasi. Basis data melibatkan metode dari pengaturan data yang memungkinkan data untuk dibakukan, dibuat konsisten, dan diatur secara terpusat. 2.1.4 Pengertian Sistem Basis Data M enurut Date (1990, p5), sistem basis data merupakan sebuah sistem penyimpanan
record
yang
terkomputerisasi
dengan
tujuan
untuk
mempertahankan informasi dan membuat informasi selalu tersedia pada saat diperlukan. Sistem basis data melibatkan empat komponen utama, antara lain: 1. Data adalah nilai-nilai yang disimpan dalam basis data. 2. Hardware adalah perangkat keras dari komputer yang terdiri atas dua bagian utama, yaitu: a. Penyimpanan sekunder, pada khususnya magnetic disk, yang digunakan untuk menyimpan data, bersamaan dengan peralatan input / output yang berhubungan, device controller, dan input / output channels.
10
b. Prosesor dan memory utama yang berhubungan, yang digunakan untuk mendukung pelaksanaan dari software sistem basis data. 3. Software adalah layer yang berperan untuk menghubungkan user dari sistem dengan basis data physical itu sendiri. Dalam hal ini, yang menjadi software adalah Database Management System. 4. User adalah pengguna sistem basis data. User dapat dibagi menjadi tiga kelas, antara lain: a. Application programmer, yang bertanggung jawab untuk menulis program aplikasi menggunakan basis data, pada khususnya dalam bahasa C atau Pascal. b. End user, adalah pengguna yang berhubungan dengan sistem dari suatu online terminal. Seorang end user dapat mengakses basis data melalui salah satu aplikasi online, ataupun interface yang disediakan sebagai bagian integral daripada software sistem basis data. c. Database Administrator (DBA), adalah orang yang membuat basis data secara nyata dan mengimplementasikan pengendalian teknis yang diperlukan untuk menjalankan berbagai macam kebijaksanaan keputusan yang dibuat oleh Data Administrator. Database administrator juga bertanggung jawab dalam memastikan bahwa sistem beroperasi dengan hasil yang memadai dan menyediakan berbagai layanan teknis lainnya. Data Administrator adalah orang yang menentukan data apa yang harus disimpan dalam basis data dan membangun kebijaksanaan dalam mempertahankan data sejak penyimpanan dilakukan.
2.1.5
Pengertian Database Management System (DBMS ) M enurut Connolly dan Begg (2002, p16), DBM S adalah sebuah software
system yang memungkinkan user untuk menentukan, membuat, mempertahankan dan mengendalikan akses ke basis data. DBM S merupakan software yang menyediakan interaksi antara program aplikasi user dengan basis data. Fasilitas dari DBM S adalah sebagai berikut: 1. Data
Definition
Language,
yang
memungkinkan
user
untuk
menspesifikasikan tipe dan struktur data beserta constraint (batasan) pada data untuk disimpan dalam basis data. 2. Data Manipulation Language, yang memungkinkan user untuk melakukan insert, update, delete, dan penarikan data dari basis data. 3. Pengendalian terhadap pengaksesan basis data, yang menyediakan: a. Sistem keamanan, yang mencegah unauthorized user untuk mengakses basis data. b. Sistem integritas, yang mempertahankan konsistensi dari data yang tersimpan. c. Sistem pengendalian concurrency, yang memperbolehkan akses secara bersamaan ke basis data. d. Sistem pengendalian recovery, yang mengembalikan basis data ke keadaan sebelumnya yang konsisten dari suatu kegagalan hardware atau software. e. Katalog yang dapat diakses oleh user, yang berisi deskripsi dari data di dalam basis data.
M enurut Connolly dan Begg (2002, p26-29), keuntungan dari Database Management System adalah: 1. Pengendalian atas data redundancy. Dengan penggunaan pendekatan basis data, data-data yang berulang bisa menjadi lebih terkendali dan berkurang dibandingkan dengan sistem berbasis file. 2. Konsistensi data Dengan adanya pengendalian dan penghilangan redundancy, inkonsistensi data dapat dihindari. Jika item data di basis data hanya disimpan pada satu tempat, maka update yang dilakukan cukup sekali saja, dan nilai yang baru akan langsung tersedia bagi user. 3. Lebih banyak informasi yang bisa didapatkan dari data yang sama. Dengan melakukan integrasi data operasional yang ada, dapat dilakukan penambahan informasi dari data yang sama. 4. Sharing dari data Pada pendekatan berbasis file, file hanya dimiliki oleh orang atau departemen tertentu yang menggunakannya. Sementara pada pendekatan basis data, basis data dimiliki oleh keseluruhan organisasi dan dibagi antara semua user yang berwenang. 5. Integritas data lebih terjamin Integritas data dilakukan dengan bantuan constraints (batasan). Dengan adanya batasan pada basis data, maka integritas atau konsistensi data yang tersimpan menjadi lebih terjamin.
6. Keamanan meningkat Keamanan basis data adalah perlindungan basis data dari pengaksesan yang dilakukan oleh user yang tidak berwenang. Salah satu cara yang ditempuh adalah meminta user untuk memasukkan user ID dan password sebelum user tersebut
melakukan
suatu
operasi
terhadap
basis
data. Database
Administrator juga bisa menentukan operasi apa saja yang bisa dilakukan oleh seorang user. 7. Kemampuan pengaksesan dan respon data yang lebih baik User bisa mengakses ke basis data untuk melihat informasi dari data yang diperlukan cukup dengan command SQL. 8. Concurrency yang lebih baik Database Management System mengendalikan pengaksesan basis data secara bersamaan oleh beberapa user dan memastikan hal-hal seperti hilangnya informasi ataupun hilangnya integritas data tidak terjadi.
2.1.6 Normalisasi M enurut Connolly dan Begg (2002, p376-377), normalisasi merupakan sebuah teknik untuk menghasilkan sekumpulan relasi dengan sifat-sifat yang diinginkan berdasarkan kebutuhan data dari sebuah perusahaan. Proses normalisasi adalah sebuah metode formal yang mengenali relasi berdasarkan primary atau candidate key dan ketergantungan fungs ional di antara atributatribut. Normalisasi mendukung perancang basis data dengan menyajikan serangkaian pengujian, yang digunakan untuk menguji relasi secara individual
sehingga sebuah relational schema dapat dinormalisasikan ke dalam bentuk yang lebih spesifik untuk mencegah kemungkinan terjadinya update anomalies. M enurut Connolly dan Begg (2002, p26-29), proses dari Normalisasi adalah sebagai berikut: 1. Unnormalized Form (UNF) adalah sebuah tabel yang terdiri atas satu atau lebih kelompok yang berulang (repeating group). 2. First Normal Form (1NF) adalah sebuah relasi di mana titik temu dari setiap baris dan kolom terdiri dari satu dan hanya satu nilai. Untuk mengubah tabel unnormalized ke dalam 1NF, perlu dilakukan penghilangan kelompok yang berulang pada tabel dan mengenali primary key yang ada pada tabel tersebut. 3. Second Normal Form (2NF) adalah sebuah relasi yang ada dalam 1NF dan setiap atribut non-primary-key adalah tergantung secara fungsional (Full Functional Dependency) secara penuh pada primary key. Ketergantungan fungsional penuh menunjukkan bahwa jika A dan B adalah atribut dari sebuah relasi, B dikatakan tergantung secara fungsional secara penuh pada A jika B memiliki ketergantungan fungsional pada A, tetapi bukan bagian dari A. Sebuah ketergantungan fungsional A Æ B adalah bersifat penuh jika penghapusan sembarang atribut dari A akan mengakibatkan ketergantungan tersebut menjadi tidak bisa berlanjut. Sebuah ketergantungan fungsional A Æ B adalah bersifat penuh jika penghapusan sembarang atribut dari A mengakibatkan ketergantungan tersebut tetap bisa bertahan. 4. Third Normal Form (3NF) adalah sebuah relasi yang ada dalam 1NF dan 2NF, dan di mana setiap atribut non-primary-key tergantung secara transitif
pada primary key. 3NF berdasarkan pada ketergantungan transitif. Ketergantungan transitif adalah sebuah kondisi di mana A, B, C adalah atribut dari sebuah relasi, dan jika AÆ B dan B Æ C, maka C adalah tergantung secara transitif terhadap A melalui B.
2.1.7 Update Anomalies Update Anomalies adalah masalah yang timbul dari relasi-relasi yang mempunyai data yang redundant. Update Anomalies dapat dikelompokkan menjadi insertion, deletion dan modification anomalies. Update Anomalies akan diilustrasikan dengan menggunakan relasi StaffBranch yang berisi keterangan dari Staff dan Branch dan mempunyai primary key staffNo. •
Insertion Anomalies M erupakan anomaly yang terjadi pada saat insert data. Insertion Anomalies terdiri dari dua jenis, contohnya : -
Pada relasi StaffBranch, bila ingin dilakukan insert data Staff baru, data Branch tempat Staff bekerja juga harus dimasukkan. Data Branch yang ingin dimasukkan, bila sudah pernah ada juga harus sesuai dengan data Branch yang sama yang sudah ada. Bila tidak hal ini akan menyebabkan inkonsistensi pada basis data.
-
Pada relasi StaffBranch, bila ingin melakukan insert data Branch baru yang belum memiliki Staff, nilai null untuk Staff harus dimasukkan. Tetapi karena staffNo merupakan primary key dari relasi StaffBranch maka insert tidak bisa dilakukan.
•
Deletion Anomalies M erupakan anomaly yang terjadi pada saat delete data. Contoh : Pada relasi StaffBranch, bila delete data dilakukan pada Staff terakhir dari sebuah Branch, maka informasi dari Branch juga akan ikut hilang.
•
Modification Anomalies M erupakan anomaly yang terjadi pada saat update data. Contoh : Pada relasi StaffBranch, bila ingin dilakukan update data Branch, semua baris dari relasi yang berisi Branch tersebut harus di-update. Bila tidak, basis data akan menjadi inkonsisten.
2.1.8
Pengertian ER-Modeling (Entity-Relationship Modeling) M enurut Connolly dan Begg (2002, p330), ER-Modeling adalah sebuah
pendekatan top down untuk perancangan basis data yang dimulai dari mengenali data penting yang disebut entitas dan hubungan di antara data yang harus diwakilkan pada model. Langkah selanjutnya adalah menambahkan detail seperti informasi mengenai entitas dan hubungan yang ingin disimpan yang disebut juga atribut, dan constraint (batasan) yang ada pada entitas, hubungan dan atribut. Salah satu aspek yang tersulit dari perancangan basis data adalah kenyataan bahwa designer, programmer, dan end user cenderung untuk menggambarkan data dan kegunaannya dengan cara yang berbeda. Untuk mendapat pengertian dari data dan bagaimana data tersebut digunakan yang benar, dibutuhkan sebuah model yang non-technical dan tidak ambigu yaitu ER-modelling.
2.1.9
Pengertian Relasi M enurut Connolly dan Begg (2002, p72), Relasi digunakan untuk
menyimpan informasi mengenai objek yang akan digambarkan dalam basis data. Sebuah relasi digambarkan sebagai sebuah tabel dua dimensi di mana baris dari tabel disesuaikan dengan record individu dan kolom dari tabel disesuaikan dengan atribut. 2.1.10 Pengertian Atribut M enurut Connolly dan Begg (2002, p72), atribut adalah sebuah kolom yang dinamakan dari sebuah relasi. 2.1.11 Perancangan Basis Data M enurut Connolly dan Begg (2002, p419-p501), langkah-langkah perancangan basis data adalah sebagai berikut: 2.1.11.1 Conceptual Database Design Conceptual Database Design adalah proses pembangunan model informasi yang digunakan dalam sebuah organisasi, yang tidak tergantung pada semua pertimbangan physical. Pertimbangan physical yang dimaksud meliputi DBM S yang akan digunakan, program aplikasi, bahasa pemrograman, hardware platform, performance issues, dan pertimbangan-pertimbangan physical lainnya. Perancangan basis data conceptual ini terdiri dari langkah-langkah sebagai berikut:
Langkah 1: M embangun model data conceptual local untuk setiap view 1.1. M engidentifikasi Tipe Entitas M engidentifikasi
tipe
entitas
bertujuan
untuk
mengidentifikasikan tipe entitas utama yang dibutuhkan dengan view. Tipe entitas dapat dikenali dengan mengidentifikasikan kata benda pada spesifikasi kebutuhan pengguna, objek besar seperti orang (people), tempat (place), benda (thing) atau konsep (concept). Alternatif lain adalah dengan mencari obyek yang mempunyai keberadaan sendiri. 1.2. M engidentifikasi Tipe Relationship M engidentifikasi
tipe
relationship
bertujuan
untuk
mengidentifikasikan hubungan penting yang ada diantara tipe entitas yang telah diidentifikasikan sebelumnya. Ketika dilakukan identifikasi suatu entitas, metode yang pertama adalah melihat kata benda dalam spesifikasi keperluan dari user. 1.3. Identifikasi dan Asosiasi Atribut suatu Entitas atau Relationship Identifkasi dan Asosiasi Atribut suatu entitas bertujuan untuk menghubungkan atribut-atribut dengan entitas atau tipe-tipe relationship yang tepat. Atribut yang dimiliki oleh setiap entitas dan relationship harus memenuhi karakteristik atribut yaitu simple/composite attribute, single/multi-valued attribute, dan derived attribute. 1.4. Identifkasi Candidate dan Primary Key setiap Entitas Identifkasi Candidate dan Primary Key setiap entitas bertujuan untuk mengidentifikasikan candidate key untuk setiap tipe-tipe entitas dan, jika ada lebih dari satu candidate key, maka salah satu dari candidate
key harus menjadi primary key. candidate key yang lain disebut juga dengan alternate key. Berikut adalah acuan dalam menentukan primary key dari candidate key: •
candidate key dengan set atribut yang minimal.
•
candidate key dengan kemungkinan terjadinya perubahan nilai paling kecil.
•
candidate key dengan jumlah karakter paling sedikit
•
candidate key dengan nilai maksimum yang paling sedikit
•
candidate key yang termudah digunakan dari sudut pandang user.
1.5. Validasi Transaksi Validasi Transaksi bertujuan untuk memastikan bahwa local conceptual model mendukung transaksi yang dibutuhkan dengan view. Pemeriksaan ini dapat dilakukan dengan dua pendekatan, yaitu : a. M endeskripsikan transaksi M endeskripsikan transaksi dengan cara memeriksa semua informasi yang dibutuhkan oleh tiap-tiap transaksi, dimana disediakan oleh model dengan cara menjelaskan tiap-tiap kebutuhan dari setiap transaksi. b. M enggunakan jalur transaksi M enggunakan jalur transaksi untuk menvalidasi model data dengan
transaksi
yang
dibutuhkan
dengan
diagram
yang
menjelaskan jalur-jalur yang ditempuh langsung oleh setiap transaksi pada ER-diagram.
2.1.11.2 Logical Database Design Logical Database Design adalah proses pembangunan sebuah model dari informasi yang digunakan dalam sebuah organisasi yang didasarkan pada sebuah model data tertentu, dan tidak tergantung pada DBM S dan semua pertimbangan physical lainnya. Pada
perancangan
basis data logical terdiri dari langkah-langkah sebagai berikut:
Langkah 2: M embangun dan melakukan validasi model data logical local untuk setiap view Tujuannya adalah untuk membangun sebuah model data logical local dari sebuah model data conceptual local yang mewakili view tertentu dari organisasi dan kemudian melakukan validasi pada model ini untuk memastikan bahwa strukturnya benar ( dengan menggunakan teknik normalisasi) dan untuk memastikan dukungannya terhadap transaksi-transaksi yang dibutuhkan.
2.1. M enghilangkan Fitur yang tidak kompatibel dengan model relational Langkah-langkahnya antara lain :
M enghilangkan tipe relationship binary many-to-many (*:*) Jika
hubungan many-to-many (*:*) direpresentasikan dalam
model data conceptual, Hubungan ini dapat diuraikan dengan cara mengidentifikasikan sebuah intermediate entity. Hubungan many-
to-many (*:*) ini akan digantikan dengan dua entity baru yang berisfat one-to-many (1:*)
M enghilangkan tipe relationship recursive many-to-many (*:*) Sebuah recursive relationship adalah tipe khusus pada sebuah hubungan dimana tipe entitas mempunyai hubungan dengan dirinya sendiri.
M enghilangkan tipe relationship yang kompleks Sebuah relationship yang kompleks adalah relationship di antara tiga atau lebih tipe entitas.
M enghilangkan atribut multi-valued Sebuah atribut multi-valued menyimpan multiple values untuk single entity. Jika sebuah atribut multi-valued direpresentasikan dalam model data conceptual, maka atribut ini dapat diuraikan untuk mengidentifikasi setiap entitas.
2.2. M endapatkan relasi untuk model data logical local M endapatkan relasi untuk model data logical local bertujuan untuk memrepresentasikan relationship, entitas dan atribut yang telah diidentifikasikan. Untuk mendapatkan relasi dari model data yang ada maka digunakan cara-cara berikut ini:
•
Strong entity types Untuk setiap strong entity dalam model data, dibuat sebuah relasi yang mengandung semua simple attributes dari entitas tersebut.
•
Weak entity types Untuk setiap weak entity dalam model data, dibuat sebuah relasi yang mengandung semua simple attributes dari setiap entitas. Primary key dari weak entity adalah penurunan dari sebagian atau seluruhnya setiap entitas pemilik, sehingga identifikasi Primary key dari weak entity tidak dapat dibuat sampai semua hubungan dengan entitas pemilik sudah di mapping.
•
Tipe relationship binary one-to-many (1:*) Untuk setiap relationship binary one-to-many (1:*), entitas pada sisi relationship ‘one side’ dirancang sebagai entitas parent dan entitas pada sisi relationship ‘many side’ dirancang sebagai entitas child.
•
Tipe relationship binary one-to-one (1:1) Pada tipe relationship one-to-one (1:1) binary, participation constraints digunakan untuk membantu menentukan cara yang paling bagus untuk merepresentasikan relationship, apakah dengan cara
menggabungkan entitas-entitas menjadi satu
relasi atau dengan cara membuat dua relasi dan sebuah copy
dari primary key dari sebuah relasi akan ditempatkan di relasi lainnya. Cara untuk membuat relasi untuk merepresentasikan participation constraints adalah sebagai berikut: (a) Mandatory
participation
pada
dua
sisi
dari
1:1
relationship Pada kasus ini, entitas yang berhubungan harus digabungkan menjadi satu relasi dan pilih salah satu dari primary key dari entitas aslinya untuk menjadi primary key dari relasi baru, di mana primary key lainnya dari entitas aslinya (jika ada) digunakan sebagai sebuah alternate key. Contohnya, pada relationship 1:1 Client menyatakan Preference yang mandatory di dua sisi. Pada kasus ini, kita akan menggabungkan kedua relasi dan memilih sebuah primary key yaitu clientNo. (b) Mandatory
participation
pada
satu sisi
dari
1:1
relationship Pada kasus ini, identifikasi entitas parent dan child untuk
1:1
relationship
menggunakan
participation
constraints. Entitas yang memiliki optional participation dalam relationship ditentukan sebagai entitas parent, dan entitas yang memiliki mandatory participation dalam relationship ditentukan sebagai entitas child. Sebuah copy dari primary key dari entitas parent akan ditempatkan dalam relasi yang mewakili entitas child.
Contohnya, jika relasi 1:1 Client menyatakan Preference memiliki partial participation pada sisi Client (dengan kata lain, tidak semua client menyatakan preference), maka entitas Client akan ditentukan sebagai entitas parent dan entitas Preference akan ditentukan sebagai entitas child. Oleh karena itu, sebuah copy dari primary key dari entitas Client (parent) akan ditempatkan pada relasi Preference (child). (c) Optional participation pada dua sisi dari 1:1 relationship Pada kasus ini, penentuan entitas parent dan child akan tidak tetap atau berubah-ubah sebelum bisa mencari tahu lebih banyak informasi mengenai relationship yang bisa membantu dalam pengambilan keputusan untuk dibuat satu arah atau lainnya. Contohnya,
sebuah
relationship
1:1
Staff
menggunakan Car dengan optional participation pada dua sisi dari 1:1 relationship. Jika tidak ada informasi tambahan yang bisa membantu dalam memilih entitas parent dan child, maka pilihannya akan tidak tetap. Dengan kata lain, bisa dilakukan penempatan sebuah copy dari primary key dari entitas Staff ke entitas Car, ataupun sebaliknya. Namun, dapat diasumsikan bahwa sebagian besar mobil, tetapi tidak semuanya, digunakan oleh staff, dan
hanya sebagian kecil dari staff yang menggunakan mobil. Entitas Car, walaupun optional, namun lebih dekat untuk menjadi mandatory dari pada entitas Staff. Sehingga Staff dipilih sebagai entitas parent dan Car dipilih sebagai entitas child, serta dilakukan penempatan sebuah copy dari primary key dari entitas Staff ke entitas Car. •
Tipe relationship recursive one-to-one (1:1) Untuk
hubungan
recursive
(1:1)
dengan
mandatory
participation on both sides, hubungan recursive akan direpresentasikan sebagai sebuah relasi dengan dua copies dari primary key dan salah satu copy dari primary key akan menjadi foreign key dan harus diubah namanya. Untuk
hubungan
recursive
(1:1)
dengan
mandatory
participation on one side, terdapat beberapa pilihan yaitu membuat sebuah relasi dengan dua copies dari primary key dan salah satu copy dari primary key akan menjadi foreign key dan harus diubah namanya atau
membuat relasi baru
untuk merepresentasikan hubungan itu. •
Tipe relationship Superclass/subclass Untuk setiap hubungan Superclass/subclass dalam data model conceptual, dapat dilakukan identifikasi entitas superclass sebagai parent entity dan entitas subclass sebagai child entity.
Pemilihan representasi relationship yang pas bergantung pada beberapa faktor
seperti disjointness
dan participation
constraint. Disjointness menentukan eksklusivitas sebuah relationship. M isalnya bila ada superclass Owner yang mempunyai hubungan disjoint dengan subclass-nya yaitu PrivateOwner dan BusinessOwner maka setiap anggota dari superclass Owner hanya boleh menjadi anggota dari PrivateOwner atau BusinessOwner dan tidak boleh kedua-duanya.
2.3. Validasi relationship menggunakan normalisasi Validasi relasi menggunakan normalisasi bertujuan untuk menvalidasi relasi pada local logical data model menggunakan teknik dari normalisasi.
Langkah 3: M embangun dan validasi model data logical global Bertujuan untuk menggabungkan masing-masing local logical data model
menjadi sebuah
global logical data
model yang
menggambarkan organisasi dengan menyatukan masing-masing local logical data model bagi setiap pandangan pengguna 3.1. M enggabungkan model data logical local ke dalam model data logical global M enggabungkan model data logical individual ke dalam model data logical global organisasi.
3.2. M envalidasi model data logical global M envalidasi relasi yang telah dibuat dari model data global menggunakan teknik normalisasi dan memastikan relasi ini mendukung transaksi yang diperlukan. 3.3. M emeriksa perkembangan yang akan datang Bertujuan untuk memastikan apakah ada perubahan yang signifikan yang dapat diperkirakan dan memastikan apakah model data logical global ini dapat mendukung perubahan-perubahan ini. 3.4. M emeriksa model data logical global dengan user M emastikan bahwa model data logical global merupakan representasi nyata dari organisasi. 2.1.11.3 Physical Database Design Physical Database Design adalah proses yang menghasilkan sebuah deskripsi dari implementasi basis data pada secondary storage; menjelaskan relasi dasar, file organization, dan pembuatan index yang digunakan untuk mengakses data agar lebih efisien dan semua integrity constraint yang berhubungan dan langkah-langkah keamanan.
Langkah 4: M enerjemahkan model data logical global untuk DBM S yang akan digunakan Pada perancangan basis data physical terdiri dari langkah-langkah sebagai berikut: 4.1. Perancangan relasi dasar basis data
Perancangan memutuskan
relasi
bagaimana
dasar
basis
merepresentasikan
data
bertujuan
relasi
dasar
untuk yang
diidentifikasikan pada global logical data model di dalam DBM S. Setiap relasi yang diidentifikasikan pada global logical data model, terdiri dari: •
Nama dari relasi
•
Sekumpulan atribut yang sederhana
•
Primary key. Jika dibutuhkan maka ditambahkan alternate key dan foreign key
•
Sekumpulan atribut derived dan bagaimana atribut tersebut diletakkan.
•
Referential integrity constraints untuk setiap foreign key yang ada.
4.2. M erancang Enterprise Constraint M erancang enterprise constraint bertujuan menentukan enterprise constraint untuk DBM S.
Langkah 5: M endesain gambaran fisik dari basis data M enentukan organisasi file yang akan digunakan dan indeks untuk menghasilkan performa yang diinginkan serta menentukan apa saja yang akan disimpan dalam secondary strorage.
5.1.Analisa Transaksi Analisa transaksi bertujuan untuk memahami functionality dari transaksi yang akan berjalan pada basis data dan untuk menganalisis transaksi yang penting. 5.2.Pembuatan Indeks setiap Entity M emutuskan
apakah
dengan
menggunakan
indeks
akan
meningkatkan performa dari sistem. 5.3.M engestimasi kapasitas penyimpanan yang dibutuhkan M emperkirakan disk storage yang diperlukan untuk menggunakan sistem basis data, disk storage yang dimaksud adalah secondary storage. 2.1.12 Pengertian Index M enurut Connolly dan Begg (2002, p495), sebuah index disebut sebagai primary index jika atribut yang terpilih sebagai index merupakan key dari sebuah relasi. M enurut Farrow (2005), sebuah primary index membantu mempercepat pencarian primary key dari sebuah relasi. M enurut Connolly dan Begg (2002, p495), secondary index menyediakan mekanisme untuk menentukan sebuah key tambahan untuk sebuah relasi dasar yang bisa digunakan untuk melakukan retrieve data secara lebih efisien. Sedangkan menurut Farrow (2005), sebuah secondary index memungkinkan pencarian yang lebih efisien pada atribut lain yang sering digunakan dalam query.
Pedoman dalam memilih secondary index diantaranya adalah sebagai berikut: •
Tambahkan secondary index pada foreign key jika sering diakses.
•
Tambahkan secondary index pada atribut lain yang sering digunakan sebagai kata kunci dalam pencarian.
•
Tambahkan secondary index pada atribut yang sering digunakan pada order by, group by, min, max, avg.
Secondary index tidak diperlukan pada kondisi sebagai berikut: •
Jika relasinya terlalu kecil – tidak banyak baris
•
Jika relasi atau atribut tersebut sering di-update
•
Jika atribut selalu digunakan dalam query yang mendapat bagian terpenting pada baris dalam relasi tersebut.
2.1.13 Pengertian State Transition Diagram M enurut
Whitten et al (2004, p636), State Transition Diagram
digunakan untuk menggambarkan urutan dan variasi screen yang dapat muncul ketika pengguna sistem mengunjungi terminal. Ketika mendesain antarmuka grafis, istilah screen dapat mengacu pada display screen keseluruhan, window, atau dialogue box. Anda dapat menganggapnya sebagai peta jalan (road map). M asing-masing screen dianalogikan sebagai sebuah kota. Tidak semua jalan melewati seluruh kota. Bujur sangkar digunakan untuk menggambarkan display screen. Anak panah menggambarkan aliran kontrol dan menggerakkan kejadian yang akan
menyebabkan screen menjadi aktif atau menerima fokus. Bujur sangkar tersebut hanya menggambarkan apa saja yang akan muncul selama dialogue. Arah anak panah menunjukkan urutan munculnya screen-screen tersebut. Sebuah anak panah yang terpisah, masing-masing memiliki nama, digambar untuk setiap arah karena tindakan yang berbeda akan menggerakkan aliran kontrol dari dan aliran kontrol ke screen yang ada. 2.1.14 Pengertian Intranet M enurut M artin (1999, p6), perbedaan utama intranet dengan internet adalah sifat informasi yang dikandungnya. Informasi pada intranet tidak bisa ditemukan secara umum seperti informasi pada internet karena informasi tersebut dikembangkan oleh suatu perusahaan atau organisasi untuk kebutuhan internal saja. Intranet – yang dijalankan web server internal – telah banyak digunakan oleh perusahaan-perusahaan untuk mengakses aplikasi korporat (Turban et al, 2003, p222). 2.1.15 Framework Framework menurut America Heritage Dictionary adalah suatu struktur yang digunakan untuk mendukung atau melingkupi sesuatu, khususnya sebagai rangka dasar dibangunnya sesuatu. M enurut Wikipedia, Framework aplikasi merupakan framework yang mengimplementasikan struktur yang terstandarisasi dalam pengembangan aplikasi.
Penggunaan
Framework
dalam
pengembangan
aplikasi
akan
meningkatkan efisiensi programming dengan tersedianya kumpulan komponen dan desain proses yang telah well-defined, meningkatkan reuseability, dan menerapkan praktik programming yang baik (Zambon dan Sekler, 2007, p145146). 2.1.16 Account Payable Account Payable adalah liabilitas yang terjadi ketika pembelian dilakukan secara kredit (Warren et al, 2001, p13). Hal ini terjadi ketika perusahaan belum melakukan pembayaran atas barang atau jasa yang telah diterima. M enurut Investopedia, Account Payable adalah hutang yang harus dibayarkan dalam jangka waktu tertentu untuk menghindari keadaan default (gagal bayar). Dalam hal korporat, Account Payable merujuk pada pembayaran hutang jangka pendek kepada supplier dan bank. 2.1.17 Invoice M enurut Warren et al. (2001, p228), Invoice adalah tagihan yang diserahkan oleh penjual (disebut invoice penjualan) kepada pembeli (disebut invoice pembelian) atas barang-barang yang terjual.
2.2 Teori-teori khusus Terdapat beberapa teori khusus yang digunakan dalam analisis dan perancangan aplikasi Account Payable berbasis web di PT Federal International Finance seperti yang diuraikan oleh definisi-definisi berikut.
2.2.1
Oracle Forms Oracle Forms adalah tool pengembangan aplikasi yang digunakan untuk
mendesain dan membangun aplikasi client/server atau sebagai aplikasi three-tier browser-based via Oracle Application Server.
2.2.1.1 Java Applet Java Applet adalah sebuah program yang ditulis dengan bahasa pemrograman Java yang dapat disisipkan di dalam sebuah halaman HTM L, mirip dengan cara sebuah gambar disisipkan dalam halaman HTM L. Java applet dijalankan di dalam web browser dengan menggunakan Java Virtual M achine (JVM ). Java applet dapat digunakan untuk menyediakan fitur-fitur interaktif dari suatu aplikasi web yang tidak dapat disediakan oleh HTM L. Selain itu karena Java bytecode bersifat platform independent maka Java Applet dapat dijalankan oleh banyak browser di beberapa platform yang berbeda. 2.2.1.2 Forms Client Adalah sebuah Java Applet yang menyediakan user interface untuk proses Forms Runtime di middle tier. Ketika Forms dijalankan pertama kali, Forms Client akan secara otomatis di-download ke komputer client. Forms Client yang sama digunakan untuk semua aplikasi form, sehingga Forms Client yang telah di-download akan tersimpan di
cache client. Forms Client memerlukan Java Virtual M achine (JVM ) agar bisa dijalankan. Di platform Windows, Oracle menyediakan JInitiator. 2.2.1.3 Forms Runtime Process Forms Runtime adalah suatu proses yang mengurus koneksi ke database dari Forms Client. Proses ini akan otomatis dibuat ketika user mengakses suatu aplikasi Forms. Proses ini akan secara otomatis berhenti ketika user menutup aplikasi Forms atau menutup window browser. 2.2.1.4 Forms Listener Servlet Forms Listener Servlet adalah sebuah proses yang mengatur: •
Pembuatan proses Forms Runtime baru untuk setiap client ketika user ingin menjalankan aplikasi Forms.
•
M enghentikan proses Forms Runtime ketika user menutup aplikasi Forms atau menutup window browser.
•
Komunikasi network antara client dan Forms Runtime Process.
2.2.1.5 Oracle JInitiator Oracle JInitiator adalah sebuah Java Plug-in versi Oracle yang menyediakan kemampuan untuk menggunakan Java Virtual M achine versi tertentu di client daripada menggunakan Java Virtual M achine default dari browser. Keuntungan-keuntungan dari JInitiator adalah: •
M empercepat JVM yang kompatibel dengan Oracle.
•
M emastikan penggunaan J VM yang sama antar browser.
•
JInitiator menyediakan sebuah platform yang reliable. Oracle JInitiator telah dites seluruhnya dan sepenuhnya kompatibel dengan OracleAS Forms Services dan Oracle Application E-Business suite.
•
JInitiator dapat melakukan cache file-file class secara otomatis sehingga dapat mempercepat start-up aplikasi.
•
JInitiator dapat menginstal sendiri dan meng-update sendiri.
2.2.2 Pengertian Oracle ADF Oracle Application Development Framework (Oracle ADF) adalah sebuah framework pengembangan aplikasi Java Platform, Enterprise Editon (Java EE) yang inovatif namun matang yang dikeluarkan oleh Oracle. Oracle ADF ini didukung secara langsung oleh IDE yang telah memenangkan banyak penghargaan, yakni Oracle JDeveloper 11g. Oracle
ADF
mempermudah
pengembangan
Java
EE
dengan
meminimalisasi kebutuhan untuk menulis code yang mengimplementasikan infrastruktur aplikasi. Hal ini yang memungkinkan developer untuk fokus pada fitur dari aplikasi. Oracle ADF menyediakan infrastruktur implementasi ini sebagai bagian dari framework. Oracle ADF dibuat berdasarkan pola desain M VC. 2.2.2.1 Definisi Arsitektur MVC M enurut Wikipedia, Model View Controller (M VC) adalah sebuah arsitektur yang digunakan dalam proses software engineering. Tujuan M VC adalah memisahkan business logic dari user interface,
sehingga aplikasi yang dihasilkan lebih mudah untuk mengubah desain visual dari aplikasi atau business rule tanpa harus mengubah dua-duanya. Arsitektur M VC terdiri dari: •
Layer Model adalah layer yang berisi informasi/data dari aplikasi dan business rule.
•
Layer View adalah layer yang berisi halaman-halaman UI yang digunakan untuk melihat dan mengubah data-data yang ada di layer Model.
•
Layer Controller adalah layer yang digunakan untuk memproses input user dan menentukan navigasi halaman.
Pemisahan aplikasi ke dalam tiga layer ini memudahkan maintenance dan penggunaan kembali komponen-komponen di aplikasi lain.
Gambar 2.1 Layer MVC Beserta Interaksinya
2.2.2.2 Arsitektur Oracle ADF Oracle ADF mengimplementasikan M VC dan memisahkan lagi Layer Model dari Business Service untuk memungkinkan pengembangan aplikasi yang berorientasi service. Arsitektur Oracle ADF terdiri dari 4 layer: •
Layer Business Services M enyediakan
akses
ke
data
dari
berbagai
sumber,
object/relational mapping dan menangani business logic. Layer Business Services di Oracle ADF bisa diimplementasikan dengan pilihan sebagai berikut: class Java, EJB 2.1/3.0, Web Services, JPA objects, dan Oracle ADF Business Components.
•
Layer Model M enghubungkan Business Service dengan objek yang digunakan di layer lain. Oracle ADF menerapkan implementasi layer model di atas layer Business Service, yang menyediakan suatu interface tunggal yang memungkinkan layer View dan Controller mengakses Business Service yang beragam dengan cara yang konsisten. Layer Model terdiri dari dua komponen, yakni data controls dan data bindings, yang menggunakan file metadata untuk mendefinisikan interface.
Data
controls
mengabstraksi detail
implementasi Business Service, termasuk informasi properties, methods, dan type yang dipakai. Data bindings mengekspos methods dan attributes Data Control ke komponen UI, yang memberikan pemisahan antara View dan Model. •
Layer Controller M enyediakan mekanisme untuk mengontrol task flows di aplikasi web. Ada 3 pilihan controller di JDeveloper: Oracle ADF Controller, JSF Controller atau Apache Struts.
•
Layer View M erepresentasikan UI aplikasi. Layer View bisa berupa web client, aplikasi desktop client-server, atau implementasi wireless untuk mobile device seperti handphone.
Gambar 2.2 Arsitektur Oracle ADF
Oracle ADF memberikan pilihan kepada developer dalam menentukan jenis teknologi yang diimplementasikan di setiap layer. Gambar di atas menunjukan pilihan-pilihan yang bisa dipakai oleh developer ketika membangun suatu aplikasi Oracle ADF. EJB, Web Services, JavaBeans, dan JPA/EclipseLink/TopLink bisa dipakai sebagai Business Services untuk Oracle ADF. Yang termasuk layer View antara lain aplikasi Swing, integrasi dengan M S Office, maupun tampilan HTM L dengan menggunakan JSP, Java Server Faces (JSF) dan ADF Faces.
2.2.2.3 Keuntungan Oracle ADF 1. Pengembangan Java EE secara visual dan deklaratif Aspek yang membuat suatu development framework menjadi berguna
adalah
menyederhanakan
tersedianya pembuatan
tool aplikasi
pengembangan dengan
yang
menggunakan
framework tersebut. Oracle menyediakan tool visual dan deklaratif untuk setiap layer di Oracle ADF. Tool-tool ini, yang terintegrasi di dalam IDE Jdeveloper 11g, memberikan kemudahan bagi developer Java, walaupun jika mereka tidak menggunakan fitur runtime dari Oracle ADF. 2. Business Services Development Oracle Jdeveloper memungkinkan berbagai macam cara dalam membangun business services meliputi: EJB/JPA, web services, Objek Java yang sederhana, ADF BC, dan lain-lain. “Productivity with Choice” merupakan sebuah landasan untuk pendekatan ini. 3. Pengembangan User Interface Fitur pengembangan secara visual dan deklaratif di layer View dan Controller suatu aplikasi banyak tersedia di Oracle JDeveloper. Fitur-fitur tersebut antara lain: •
M odel Page Flow untuk ADF controller, menyediakan pengembangan
model visual dari page flow dengan
menggunakan drag and drop dari komponen ke diagram.
•
Editor visual untuk JSP, JSF, HTM L, Swing, memungkinkan pengembangan secara WYSIWYG.
•
Tool pengembangan yang bersifat deklaratif untuk menambah komponen ke user interface, property inspector, komponen palette yang extensible, dan data control pallete.
•
Fitur reusability, antara lain dalam pembuatan work flow, ADF Libraries, dan komponen deklaratif.
•
Oracle ADF Faces, suatu set komponen UI untuk aplikasi web yang dibuat dengan menggunakan JSF, menyediakan tampilan UI yang lebih kaya dan interaktif – termasuk partial page rendering dan Ajax.
2.2.2.4 ADF Business Component (ADF BC) ADF Business Component adalah sebuah framework dari Oracle yang memudahkan pengembangan aplikasi bisnis dengan menggunakan platform Java EE. ADF Business Components terdiri dari: •
Entity Object Entity
object
adalah
sebuah
komponen
ADF
Business
Components yang mewakili sebuah row dari sebuah tabel di data source
yang
sudah
ditentukan
sebelumnya.
Entity
object
mengenkapsulasi business logic untuk menjaga konsistensi business rule.
•
View Object View object mewakili sebuah query SQL dan menyederhanakan langkah-langkah yang dilakukan untuk melakukan perubahan data dengan hasil dari query SQL.
•
Application Module Application
module adalah
komponen
trasaksional yang
digunakan UI untuk mengakses data aplikasi. Application module mendefinisikan data model yang updateable dan prosedur-prosedur dan function-function.
2.2.2.5 ADF Faces Rich Client ADF Faces Rich Client (RC) adalah kumpulan dari komponenkomponen standar JSF yang memiliki dukungan terhadap fungsionalitas AJAX. AJAX adalah kombinasi JavaScript asynchronous, Dynamic HTM L (DHTM L), XM L dan XmlHttpRequest. Sehingga hasilnya adalah request dapat dikirim ke server tanpa merender halaman tersebut kembali. AJAX akan menyediakan akses pada client dan JSF akan menyediakan akses pada server. Selain ADF Faces Rich Client, Oracle ADF juga mendukung teknologi view Apache MyFaces Trinidad, Java Swing, ADF Swing dan ADF M obile
2.2.3 Java Java adalah sebuah bahasa pemrograman yang dikembangkan oleh Sun M icrosystems dan beredar di tahun 1995 sebagai bagian inti dari platform Java dari Sun M icrosystems. Bahasa pemrograman Java memiliki kemiripan sintaks dengan bahasa pemrograman C dan C++, tetapi memiliki model objek yang lebih sederhana dan fasilitas low-level yang lebih sedikit. Aplikasi-aplikasi Java akan di-compile ke dalam bytecode yang dapat berjalan pada Java Virtual M achine (JVM ). 2.2.4 Java EE Java Platform, Enterprise Edition (Java EE) adalah sebuah platform untuk server programming pada bahasa pemrograman Java. Platform Java EE berbeda dari platform Java Standard Edition (Java SE) dalam hal library-librarynya yang menyediakan fungsionalitas untuk men-deploy software Java yang terdistribusi dan multi-tier
serta didasarkan pada komponen-komponen modular yang
berjalan pada sebuah application server. 2.2.5 JavaS erver Pages (JS P) JavaServer
Pages
(JSP)
adalah
sebuah
teknologi
Java
yang
memungkinkan para software developer untuk meng-generate HTM L, XM L dan dokumen-dokumen lain secara dinamis sebagai response dari request client. Dengan menggunakan JSP, code Java dapat disisipkan ke dalam content statis. Dalam perkembangannya format penulisan sintaks-sintaks JSP menjadi kompatibel dengan XM L.
Keuntungan penggunaan JSP yang kompatibel dengan XM L antara lain: •
M enghindari pencampuran code Java dan tag-tag komponen.
•
M emudahkan parsing halaman untuk membuat dokumentasi.
•
M emudahkan pembuatan layer view yang dapat dipersonalisasi.
2.2.6 JavaS erver Faces (JS F) Dengan munculnya kesadaran dari komunitas pengembang akan perlunya standarisasi framework layer view, Java Community Process (JCP) mulai mengembangkan JSF sebagai standar UI untuk aplikasi web yang berbasis Java. Dari rilis pertamanya di tahun 2004 hingga rilis terbarunya (JSR-252) di tahun 2006, JCP telah mengumpulkan resources dari komunitas, termasuk Oracle, dalam mendefinisikan spesifikasi JSF. JSF menyederhanakan pengembangan User Interface dengan menyediakan pendekatan yang berfokus pada komponen. Sekarang ini, J SF telah menjadi bagian dari standar Java EE.
