BAB 2 LANDAS AN TEORI
2.1
Landasan Teori Umum 2.1.1
Sistem Sistem didefinisikan sebagai sekumpulan komponen y ang saling terkait, dengan b atasan y ang jelas, beker ja bersama-sama untuk mencapai tujuan yang sama dengan menerim a input dan mengh asilkan output dalam sebuah p roses transformasi yang terorganisasi. (O’Brien dan Marakas, 2008, p24) Ketika men gemban gkan aplikasi b aru, perlu ad a aktifitas analisis sistem. Analisis sistem merup akan studi mendalam mengenai kebutuhan informasi end user. Hasil dari analisis sistem adalah requirement fun gsional yang digunakan sebagai d asar untuk mer ancang sistem y ang baru. (O’Brien dan Marakas 2008, p453-454) Perancan gan sistem mencakup 3 aktifitas: antarmuka (user interface), data, dan proses. Hasil perancangan tersebut adalah metode dan p roduk antarmuka, struktur basis data, serta p rosedur proses dan kontrol. (O’Brien dan M arakas, 2008, p 456)
2.1.2
Pengertian Data dan Informasi Data adalah f akta mentah m en genai oran g, temp at-temp at, kejadian-kejadian, d an hal-hal yang p enting dalam sebu ah or ganisasi. Data dip eroleh dari p roses transaksi bisnis.
8
9 Sedan gk an informasi adalah data y ang telah dip roses atau diorganisasi kembali men jadi suatu bentuk yang lebih berarti untuk seseorang. Informasi dibentuk dari data yang telah d iolah sehin gga memp unyai arti bagi penerimanya. (Whitten et al., 2004, p 27)
2.1.3
Pengertian basis data Basis data didefinisikan sebagai kump ulan dari data y ang saling terhubung secara lo gikal dan sebu ah deskrip si dari d ata tersebut, y ang dirancan g untuk memenuh i kebutuhan informasi d ari sebuah or ganisasi. Basis data merupakan temp at p eny imp anan data yang besar dan d apat digun akan secara b ersamaan oleh beberap a departemen dan pengguna. (Connolly dan Begg, 2005, p15)
2.1.4
Pengertian DBMS DBM S (Database Management System) adalah sebuah sistem p erangkat lunak yang memungkinkan pengguna untuk mendef inisikan, membuat, mem elih ara, dan men gontrol akses basis data. DBMS merupakan p erangkat lunak yang b erinteraksi den gan progr am aplikasi p enggun a dan basis datany a. Umumny a, DBMS menyediakan fasilitas sebagai ber ikut (Connolly dan Begg, 2005, pp 16-17): 1.
memungkink an p enggun a mendef inisikan basis d ata, biasanya melalui Data Defin ition Language (DDL). DDL m emun gkink an p enggun a untuk menentukan tipe data, struktur, dan constraint terhadap data yang akan disimp an ke basis data.
10 2.
memungkink an pengguna untuk mem asukkan, men gub ah, menghap us, dan mengambil data dari basis data, biasanya melalui Data Manipu lation Language (DM L).
3.
M eny ediakan akses yang terkontrol ke basis data. Misalnya, dapat menyediakan: a.
Sistem keaman an yang mencegah p enggun a y ang tidak berkepentingan men gakses basis data.
b.
Sistem integrasi y ang menjaga konsistensi data y ang tersimp an.
c.
Sistem kendali konkurensi yang memun gkinkan basis data dap at diakses secara bersamaan.
d.
Sistem
p emulih an
y ang
memun gkinkan
untuk
men gembalikan keadaan basis d ata ke kondisi konsisten y ang sebelumnya jika terjad i kegagalan p ada peran gkat keras ataup un p erangkat lunak. e.
Sebuah
katalo g yang b isa d iakses pengguna, y ang
meny impan deskrip si data yang p ada pada basis data.
2.1.5
Database Application Lifecycle Untuk membuat ap likasi b asis data diperlukan tahapan-tahap an y ang akan menuntun alur dari tahapan kegiatan-kegiatan y ang dilakukan p ada pembuatan ap likasi basis data y ang disebut Database Application Lifecycle. Database Application Lifecycle atau Siklus Hidup Aplikasi Basis data terdiri dari beb erap a tahapan y aitu (Connolly dan Begg, 2005, 285):
11 •
Database Planning Merencanakan bagaimana tahap an pada siklus hidup dapat diwujudkan secar a leb ih efisien dan ef ektif.
•
System Definition Mensp esifikasikan ruang lin gkup dan batasan dari aplikasi basis data, p enggun any a, dan area ap likasi.
•
Requirement collection and analysis Mengump ulkan dan menganalisa kebutuhan dar i pengguna dan area ap likasi.
•
Database Design Perancangan b asis data konsep tual, logikal dan fisik al.
•
DBMS Selection (optional) Memilih DBM S y ang sesuai untuk ap likasi basis data.
•
Aplication Design Merancang user
interface dan
program aplikasi y ang
men ggunakan d an memproses basis data. •
Prototyping (op tional) Membangun rancangan kerja dar i ap likasi basis data, dimana perancang
atau
pengguna
dapat
menggambarkan
dan
men gevaluasi bagaiman a sistem akhir akan terlihat dan berfungsi. •
Implementation Membuat definisi basis d ata eksternal, konseptual, dan internal dan program ap likasi.
•
Data conversionand loading
12 Mengeluarkan d ata dari sistem yang lama ke sistem y ang baru. •
Testing Ap likasi basis data dites untuk eror dan validasi sesuai dengan persyaratan yang diber ikan oleh p engguna.
•
Operational maintenan ce Ap likasi basis data sudah sep enuhny a diimp lem entasi. Sistem diawasi dan dip elih ara secara terus menerus.
Tahap an-tahapan p ada Database Application Lifecycle tidak harus berurutan dan ada beberapa pengulangan ke tahap an sebelumnya. Berikut ini adalah gambar dari Database Application Lifecycle:
Gambar 2.1 Tahap an-tahapan p ada Database Application Lifecycle (Connolly dan Begg, 2005,p284)
13 2.1.6 Perancangan Basis data Perancan gan basis data menurut Connoly dan Begg terdiri dari beberap a fase y aitu p erancangan basis data konseptual, p erancangan basis data logikal, d an p erancan gan basis data fisikal.
2.1.5.1 Perancangan Basis Data Konseptual Perancangan
basis
data
konsep tual
adalah
proses
memban gun suatu model informasi y ang digunakan oleh p erusahaan
atau
organisasi y ang
tidak
tergantung dar i
p ertimbangan fisik. Pada tahap membuat model d ata konsep tual, langkahlangkah y ang dilakukan ad alah seb agai berikut (Connolly dan Begg, 2005, p 442-458): a.
Mengidentifikasi tip e entitas Bertujuan untuk menentukan tip e entitas utama y ang
dibutuhkan.
Menentukan
entitas
dapat
dilakukan d engan memer iksa spesifikasi kebutuhan p enggun a. Setelah terdefinisi, entitas diber ikan nama y ang tepat dan jelas sep erti mahasiswa, dosen, mataKuliah. b.
Mengidentifikasi tip e relasi Bertujuan untuk mengidentifikasi suatu relasi y ang p enting y ang ada antar entitas y ang telah diidentifikasi. Nam a dari suatu relasi menggunakan
14 kata kerja (verb) sep erti memp elajari, memiliki, mempunyai, dan lain-lain. c.
Mengidentifikasikan d an menghubungk an atribut dengan entitas atau tip e relasi Bertujuan
untuk
menghubungk an
atribut
dengan entitas atau r elasi dengan tepat. Atribut y ang dimiliki setiap entitas atau relasi memliliki identitas atau
karakteristik
memperhatikan simple/composite,
y ang
attribute atribut
sesuai
berikut
:
singel-valued,
den gan atribut atribut
turunan. d.
Menentukan domain atribut Bertujuan untuk menentukan domain atribut p ada model data konsep tual. Contohny a y aitu menentukan nilai atribut jenis kelamin p ada entitas mahasiswa den gan ‘M’ atau ‘F’ atau nilai atribut sks p ada entitas mataKuliah dengan ‘1’,’2’,’3’, dan ‘4’.
e.
Menentukan atribut candidate key, primary key, dan alternate key Bertujuan
untuk
mengidentifikasik an
candidate key pada setiap entitas dan memilih primary key jika ada lebih dari satu candidate key. Pemilih an primary key didasari p ada p anjang dari atribut dan keunikan key.
15 f.
Mempertimbangkan
p en ggunaan
konsep
model
(pilihan) Bertujuan p engunaan aggregation,
untuk
memp ertimbangk an
specia lization,
generalization,
composition.
Masing-masing
p endekatan dap at dilakukan sesuai kebutuhan. Specialization
dan
generalization
adalah
p roses dalam mengelompokkan b eberapa entitas dan men ghasilk an entitas y ang baru. Beda dar i keduanya adalah p rosesny a, spesialisasi menggunakan proses top-down dan
gener alisasi men ggunakan proses
bottom-up. Aggregation menggambark an
sebuah
tipe
entitas dengan sebuah tipe relasi dimana suatu relasi akan ada jika telah ada r elasi lainny a. g.
Mengecek redud ansi p ada model Bertujuan untuk mem eriksa model konsep tual untuk menghindari dari adanya inform asi y ang redundan. Yang dilakukan p ada lan gk ah ini adalah : 1.
Memeriksa kembali relasi one-to-on e Setelah entitas diidentifik asikan maka kemun gkinan ad a dua entitas y ang mewakili satu objek. Untuk itu dua entity tersebut harus digabung. Dan jika primary key-ny a berbeda
16 maka h arus dipilih salah satu dan y ang lainya dijadik an alternate key. 2.
Menghilan gkan relasi y an g redudansi Untuk menyederhanakan jumlah model data, maka relasi data y ang redundan harus dihilan gk an.
h.
Memvalidasikan
model
konseptual
terhadap
transaksi pengguna Bertujuan untuk menjamin bahwa model data konseptual mendukung kebutuhan transaksi. Den gan men ggunakan
mod el y ang telah
div alid asikan
tersebut, operasi transaksi pengguna dilakukan secara manu al. Ada dua p endekatan yang mun gkin untuk menjam in bahwa model data konsep tual mendukung kebutuhan transaksi y aitu: 1.
Mendeskripsikan transaksi Memeriksa seluruh informasi (entitas, relasi, dan atribut) y ang diperlukan p ada setiap transaksi y ang disediakan oleh model den gan mendokumentasikan penggambaran dari tiap kebutuhan transaksi
2.
Menggunakan pathway transaksi Pendekatan kedua, untuk memvalidasi data model dengan kep erluan transaksi y ang melib atkan diagram yang mewakili pa thways
17 diambil dari tiap transaksi secara lan gsung yang terdapat pada E-R diagram. i.
Meninjau kembali model data konseptual dengan p enggun a Bertujuan
untuk
melihat
kembali
model
konseptual dan m emastikan bahwa model data tersebut benar.
2.1.5.2 Perancangan Basis Data Logikal Model data logik al lok al m erepresentasikan kebutuhan data untuk satu atau beberapa view p enggun a dari suatu basis data. Model data logik al glob al mer epresentasikan kebutuhan data untuk semua view pengguna. (Connolly dan Begg, 2005, p 461) Model data konseptual y ang telah dirancan g sebelumnya diterjemahkan men jadi mod el data lo gikal. Aktivitas y ang ada p ada langkah tersebut adalah (Connolly dan Begg, 2005, p 462): 1.
Menurunkan relasi untuk model data logikal Relasi diturunkan m enjadi model data lo gikal untuk merep resentasikan entitas-entitas, relasi-relasi, dan atributatribut. Relasi y ang mungk in terjadi pada model d ata konseptual (Connoly dan Begg, 2005, p 463): a.
Tip e entitas kuat Tip e entitas kuat adalah tipe entitas y ang keberadaannya
tidak
bergantun g
pada
entitas
18 lainnya. Karakteristik dari tip e entitas kuat adalah setiap entitas y ang terjadi dap at diidentifikasi secara unik menggun akan atribut primary key dari tipe entitas tersebut. (Connolly dan Begg, 2005, p 354) b.
Tip e entitas lemah Tip e entitas lemah adalah tip e entitas y ang keberadaanny a bergantung p ada entitas lainnya. (Connolly dan Begg, 2005, p 355)
c.
Tip e relasi biner One-to-many (1:*) Untuk setiap relasi biner 1:*, entitas pada ‘satu sisi’ dari relasi dian ggap sebagai entitas parent dan entitas p ada ‘bany ak sisi’ dianggap sebagai entitas child. Untuk merepresentasikan relasi ini, salinan atribut primary key dari entitas parent diberikan ke relasi y ang merep resentasikan entitas child, y ang bertindak sebagai foreign key. (Connolly dan Begg, 2005, p 465)
d.
Tip e relasi biner One-to-one (1:1) Relasi 1 :1 sedik it lebih kompleks karena cardinality tidak dapat digunakan untuk memb antu men gidentifikasi entitas-entitas parent dan child dalam relasi. Pertimbangan untuk m embuat relasi biner 1:1 antara lain (Connolly dan Begg, 2005, p 465):
19 1)
Mandatory Participa tion pada kedua sisi dari relasi 1:1 Entitas-entitas tersebut digabun g menjadi satu relasi. Primary key d ari entitas-entitas aslinya menjad i primary key p ada relasi y ang b aru, sedangkan y ang lainny a dijad ikan a lternate key. (Connolly dan Begg, 2005, p 466)
2)
Mandatory Participa tion p ada satu sisi dari relasi 1:1 Entitas-entitas parent dan child untuk relasi 1:1 dapat dihasilkan den gan men ggunak an participation
constraint.
Entitas
y ang
memp uny ai p ilihan participa tion dalam relasi dianggap sebagai entitas parent, dan entitas yang memp uny ai kewajiban participation dalam r elasi dian ggap sebagai ch ild. (Connolly dan Begg, 2005, p 466) 3)
Optional Participation p ada kedua sisi dar i relasi 1:1 Primary
key
pertimbangan
dap at
dip ilih
berdasarkan
masin g-m asing relasi untuk
setiap kasus. (Connolly dan Begg, 2005, p467) e.
Tip e relasi rekursif One-to-one (1:1) Relasi r ekursif 1:1 mengikuti aturan y ang dijelaskan diatas untuk relasi b iner 1:1. Dalam k asus
20 tertentu relasi 1:1, entitas p ada kedua sisi dari relasi adalah sama. Pada relasi rekursif 1:1 d en gan mandatory participation pada kedua sisi, relasi rekursif direpresentasi sebagai relasi tunggal den gan salinan 2 primary key. Sedangk an salah satu salinan dari primary key merep resentasikan foreign key dan harus dubah nam any a untuk menandakan relasi y ang direp resentasikan. (Connolly dan Begg, 2005, p467) f.
Tip e relasi Superclass/subclass Untuk setiap relasi superclass / subclass dalam model data konsep tual, dapat diidentifikasi entitas superclass sebagai entitas parent dan
entitas
subclass sebagai entitas child. (Connolly dan Begg, 2005, p 467) g.
Tip e relasi biner Many-to-many (*:*) Untuk setiap relasi b iner many-to-many (* :*), buatlah relasi y ang mewakili relasi dan men cakup seluruh atribut yang menjadi bagian dari relasi. Dilakukan p eny alinan atribut primary key untuk entitas y ang berpartisipasi didalam r elasi k edalam relasi y ang baru sebagai foreign key. (Connolly dan Begg, 2005, p469)
h.
Tip e relasi komp leks Untuk setiap relasi komp leks, buat sebuah relasi untuk merep resentasikan relasi dan m elip uti
21 semua atribut y ang merup akan bagian dari relasi tersebut. Lalu buat salinan primary key dari entitas y ang berhubun gan dalam relasi komp leks kedalam relasi baru, untuk berlaku sebagai foreign key. (Connolly dan Begg, 2005, p470) i.
Atribut Multi-value Untuk setiap atribut y ang memiliki bany ak nilai yang ada p ada entity, buatlah relasi untuk mewakili atribut multi-value dan mencakup primary key dari entity p ada relasi y ang baru sebagai foreign key. (Connolly dan Begg, 2005, p471)
2.
Validasikan r elasi men ggunak an normalisasi Proses
menurunkan
relasi
dari
model
data
konseptual seharusny a menghasilkan relasi y ang berada dalam 3NF. Jika ada relasi y ang belum berada dalam 3NF berarti ada bagian model data lo gikal/konsep tual y ang masih salah. (Connolly dan Begg, 2005, p473) Normalisasi lebih lanjut akan dijelaskan p ada bagian 2.1.6. 3.
Validasikan r elasi terhad ap transaksi pengguna Lan gkah ini d ilakukan untuk memastikan bahwa relasi di dalam mod el d ata logikal mendukun g transaksi yang dibutuhkan, sesuai spesifikasi dari pengguna. (Connolly dan Begg, 2005, p 474)
4.
Memeriksa integrity constraint
22 Bertujuan untuk memeriksa integrity constrain t y ang direpresentasikan dalam model data logik al untuk men jaga basis data agar tetap lengkap , akurat dan konsisten. Batasan integritas dib agi
menjadi 5 bagian, y aitu
(Connolly dan Begg, 2005, p 474): a. Required data Atribut tertentu harus selalu memiliki nilai y ang sah (valid), dengan kata lain, tidak boleh bernilai null. b. Constraint domain atribut Setiap atribut memilik i domain, yaitu kumpulan nilai yang diterima (legal). Misalny a, p ada atribut jenis kelamin harus diisi den gan ’lelak i’ atau ’p eremp uan’. c. Multiplicity Multiplicity
mer ep resentasikan
constraint
y ang
ditemp atkan p ada relasi-relasi antara data d alam basis data. d. Integritas entitas Primary key dari sebuah entitas tidak boleh bernilai null. Constraint ini harus dip ertimbangk an ketika sedang men gid entifikasi primary key untuk setiap tipe entitas. e. Integritas referential Integritas referensial berarti jika foreign key memiliki nilai, mak a nilai tersebut harus me-refer ke sebuah baris y ang ada pada relasi parent.
23 f. General constraints Update p ada entitas mungkin d apat diatur oleh constraint
p ada
transaksi
“dunia
ny ata”
y ang
direpresentasikan oleh perubahan tersebut. 5.
Meninjau kembali model data lo gikal den gan p engguna Model data logikal telah selesai dan terdokumentasi secara len gk ap setelah melalui tahapan sebelumnya. Pengguna dim inta untuk meninjau kemb ali mod el d ata logikal untuk memastikan bahwa mod el merupakan rep resentasi yang sebenarnya dari
kebutuhan
data
perusahaan.(Connolly dan Begg, 2005, p 478) 6.
Menggabungk an model data logik al menjad i model global Model data logikal lokal m erep resentasikan satu atau lebih tetapi tidak semua view pengguna basis d ata. Model data lo gikal glob al merep resentasikan semua view pengguna basis data. Model data lokal dan global digabung untuk men ghasilk an model data y ang benar, menyeluruh dan tidak ambigu. Langk ah penggabun gan model data tersebut adalah sebagai b erikut (Connolly dan Begg, 2005, p 479): a. Meninjau kembali nama dan isi dari entitas/relasi serta candidate key-nya. b. Meninjau kembali nam a dan isi d ari relasi/foreign key c. Menggabun gk an entitas/relasi dari model data lokal.
24 d. Menyertakan (tanpa menggabungkan) entitas/relasi yang unik ke dalam setiap model data e. Menggabun gk an relasi/foreign key dari model data lokal f. Menyertakan (tanpa menggabungkan) relasi/foreign key yang unik kedalam setiap model d ata g. Mengecek entitas/relasi dan relasi/foreign key y ang hilang. h. Mengecek foreign key i. Mengecek integrity constraint j. Menggambarkan d iagram ER / r elasi global k. Melakukan update dokumentasi. 7.
Memeriksa p ertumbuhan untuk masa dep an Bertujuan untuk men entukan ap akah ada perubahaan y ang signif ikan di masa y ang akan datan g dan untuk menilai ap akah
model
data
lo gis
dap at
mengakomodasi
perubahan-perubahan tersebut.(Connolly dan Begg, 2005, p490)
2.1.6.1 Perancangan Basis Data Fisikal Suatu proses yang men ghasilkan sebuah deskrip si dari implementasi basis data p ada p eny imp anan sekunder; y ang mendeskripsikan relasi dasar, organisasi file, dan indeks y ang digun akan untuk mendapatkan akses y ang efisien ke data, dan
25 semua constraint integritas y ang berhubungan dan tingkat keamanan.(Connolly dan Begg, 2005, p 496) Lan gkah-langkah perancangan basis data fisikal
adalah
sebagai berikut : 1.
Menerjemahkan model d ata lo gikal untuk DBMS y ang dip ilih Tujuanny a relasional
untuk dari
menghasilk an model
data
skema lo gikal
basis y ang
data d apat
diimp lementasikan dalam DBMS tujuan. 3 aktifitas dalam lan gkah in i, y aitu (Connolly dan Begg, 2005, p 497): a.
Merancang relasi dasar Tujuannya
adalah
untuk
menentukan
cara
representasi relasi dasar y ang teridentifikasi dalam model data logikal pada DBMS tujuan. (Connolly dan Begg, 2005, p498) b.
Merancang representasi dari data turunan Bertujuan untuk menentukan cara mer epresentasikan semua data turunan y ang ada dalam mod el data logikal p ada DBM S tujuan. (Connolly dan Begg, 2005, p 499)
c.
Merancang gen eral constraint Tujuannya untuk merancan g general constraint p ada DBM S tujuan. (Connolly dan Begg, 2005, p501)
2.
Merancang or gan isasi file dan index
26 Tujuannya adalah untuk menentukan or ganisasi file yang optimal untuk menyimpan relasi dasar dan index yang
dibutuhkan
untuk
mencap ai
p erforma
y ang
diin ginkan, y aitu, cara relasi dan tuple akan disimp an p ada penyimpanan sekunder. (Connolly dan Begg, 2005, p501) a.
Menganalisa transaksi Bertujuan untuk mem ahami fun gsi d ari transaksitransaksi y ang akan b erjalan pada b asis data dan untuk
menganalisis
transaksi-transaksi p enting.
(Connolly dan Begg, 2005, p502) b.
Memilih organisasi file Tujuannya adalah untuk m enentukan or ganisasi file y ang efisien bagi setiap relasi dasar. (Connolly dan Begg, 2005, p506)
c.
Memilih index Bertujuan untuk menentukan p enambahan index agar menin gkatkan performa sistem. (Connolly dan Begg, 2005, p508)
d.
Memperkirakan kebutuhan disk space Tujuannya adalah untuk memp erkirakan ukuran dari disk space yang akan dibutuhkan oleh b asis data. (Connolly dan Begg, 2005, p514)
3.
Merancang view p enggun a. Bertujuan untuk merancan g view p enggun a y ang teridentifikasi selama pengu mp ulan kebutuhan dan tahap
27 analisis d ari sik lus pengemban gan sistem basis d ata. (Connolly dan Begg, 2005, p 515) 4.
Merancang mekanism e keamanan Bertujuan untuk merancan g mek anisme keamanan pada
basis
data
sesuai
p engguna
selama
tahap
pengumpulan kebutuhan dari siklus pengemban gan sistem basis data. (Connolly dan Begg, 2005, p 516)
2.1.7
Normalisasi Normalisasi merup akan sekump ulan
relasi
d en gan
suatu
teknik
untuk menghasilkan
p rop erti-p rop erti
y ang
diin ginkan,
berdasarkan kebutuhan data dar i perusahaan. (Connolly dan Begg, 2005, p388) Proses normalisasi y ang digunakan seb agai landasan penulisan Skrip si ada tiga tahap, y aitu (Connolly dan Begg, 2005, p 388): 1.
First Normal Form (1NF) Sebuah relasi dik atakan 1NF jika titik temu tiap baris dan kolom pada relasi tersebut hany a mengandun g satu nilai.(Connolly dan Begg, 2005, p 403) Suatu relasi berada dalam bentuk 1NF jika repeating group-nya sudah hilang. Ada dua pendekatan untuk menghilangkan repeating group p ada tabel y ang tidak norm al, y aitu: a.
Dengan memasukkan data y ang sesuai ke dalam kolom y ang kosong pada baris yang men gandun g data berulang.
28 b.
Dengan menempatkan data berulan g bersamaan salin an atribut kunci p ada relasi y ang terp isah.
2.
Second Normal Form (2NF) Sebuah relasi dikatakan 2NF jika relasi tersebut berada pada 1NF dan setiap atribut y ang bukan primary key ber gantung penuh (fully functionally dependen t) terhadap primary key. (Connolly dan Begg, 2005, p 407)
3.
Third Normal Form (3NF) Sebuah relasi dik atakan 3NF jika relasi tersebut berada dalam bentuk 1NF dan 2NF, dan tidak ada atribut bukan primary key bergantung secara transitif (transitifvely dep endent) terhadap primary key.(Connolly dan Begg, 2005, p 408)
2.1.8
Internet Internet adalah jar in gan besar yan g dibentuk oleh interkoneksi jarin gan komputer dan komputer tunggal di selur uh dunia, melalui salur an telepon, satelit dan sistem kom unikasi lainnya. (Ellsworth, 1997, p3) Internet adalah sistem komunikasi yan g dapat menyajikan informasi ke hadapan pen gguna dan m en gor ganisasik annya sesuai kebut uhan. Internet mer upakan sistem yang terstruktur, teror ganisasi. (Foro uzan, 2007, p16)
2.1.9
Web Server
29 Web server adalah suatu p rogram y ang berjalan p ada suatu website dan bertan ggung jawab untuk membalas p emintaan Web browser akan suatu file. Web server dibutuhkan untuk menerbitkan dokumen pada Web. (Lemay , 1999, p23)
2.1.10 Web Browser Web browser adalah p rogr am yang d igunakan untuk menampilkan halam an dan navigasi pada World Wid e Web. Web browser, juga disebut web client, membuat koneksi-koneksi m elalui internet sampai layanan
jaringan,
m eminta
sumb er
day a
dari
jarin gan
dan
menamp ilkanny a. (Lemay, 1999, p 19)
2.2
Landasan teori khusus 2.2.1
CRM (Custo mer Relationship Management) 2.2.1.1 Pengertian CRM CRM adalah disip lin manajemen atau filosofi y ang men gharuskan
bisnis
untuk
mendalami dan
m emelihara
hubungan d engan pelanggan. CRM mengh itung ked ekatan p elanggan den gan skala ekono mi. Hal tersebutlah y ang mendasari p embangunan hubun gan y ang erat antara wakil dari p emilik bisnis dan p elan gganny a. Dengan CRM, kebutuhan dan p referensi pelanggan tersedia untuk siap a saja y ang berada dalam bisnis agar dapat bekerja p ada antarmuka pelanggan, dan p elanggan dip erlakukan secara konsisten.
30 Dengan men emp atkan p elanggan seb agai p usat bisnis, CRM adalah perwujudan dari fokus kepada p elanggan - sebuah p rinsip y ang didukun g secara lu as tetap i jarang disamp aikan. CRM menjadi p enting ketika kunci p endukung strategi dari sebuah bisnis adalah kedekatan p elanggan. Ide dari CRM bukanlah hal baru. Toko-toko kota kecil mulai meny ediak an layanan CRM seperti, mengantisip asi kebutuhan p elanggan y ang didasarkan p ada pengetahuan y ang mend alam tentang keadaan mereka dan preferensi, dan memperlakukan p elan ggan y ang berbeda den gan car a yang berb eda. (Janice Rey nolds, 2002, p 2) Alasan men ggunkana CRM adalah pelan ggan tidak memikirkan bagaimana p erusahaan meny imp an data dari bany ak sumber dan menggabungkannya menjadi satu untuk ditampilkan sep erti y ang diin ginkan pelan ggan. Yang d iin gink an p elanggan
adalah mer eka m en gin gink an pelayanan y ang
cemer lan g dan mereka men gin gink annya sekarang. Komp etisi y ang menin gkat, globalisasi, biaya yang bertambah untuk mendapatkan p elanggan baru, dan pergantiaan p elanggan y ang tinggi adalah hal-h al utama p ada industri yang berbeda sep erti p elay anan financial, teleko munikasi d an retail. CRM adalah kombinasi dari p roses dan teknologi b isnis y ang men cari untuk mengerti pelanggan perusahaan dari perspektif yang berbedabeda. CRM didefinisikan sebagai strategi p enjualan, p emasaran, dan
pelay anan
y ang
tergantung
p ada
kegiatan
y ang
31 terkoordinasi. Tujuan dari kerangka kerja bisnis ini adalah (Kalakota dan Robinson, 1999, p111-112): •
Memakai
hubungan
meningkatkan
penghasilan.
pandangan y ang luas memaksimalk an
yang
ada
untuk
M enggabungkan
dar i pelanggan untuk
hubun gan
p elan ggan
den gan
perusahaan menggun akan up-selling dan crossselling.
Menin gkatkan
mengenali,
menar ik
k euntungan dan
den gan
memp ertahankan
pelanggan yan g terbaik. •
Menggunakan informasi untuk pelayanan yang terbaik. M enggun akan infor masi p elan ggan untuk melay ani k ebutuhan p elanggan d en gan lebih baik. Hal
ini
mengenai
men ghemat
waktu
dan
menguran gi kek ecewaan p elan ggan. Contohnya, pelanggan tidak harus mengulan gi informasiny a ke beberap a dep artemen y ang b erbeda berulangulang.
Pelan ggan
harus
dik ejutkan
den gan
seberap a baik perusahaan men genal mereka. •
Mengenalkan proses dan prosedur penjualan secara berulang. Dengan pertumbuhan koneksi ke pelanggan, banyak kary awan akan terlibat dalam penjualan. Untuk mendap atkan kesuksesan secara berkesinambun gan,
p erusahaan
harus
32 menin gkatkan konsistensi pada p engaturan account dan penjualan. •
Menciptakan nilai yang baru dan menanamkan kesetiaan. Hal ini dapat menjadi titik perbedaan perusahaan den gan yan g lainny a, keuntungan perusahaan y ang dapat bersaing den gan y ang lainny a, untuk dap at menjadi perusahaan y ang mengetahui
prospek
kemampuan
untuk
dan
p elanggan
meresp on
untuk
kebutuhan
dan
menampung p ermintaan, perusahaan y ang pantas mendap atkan kesetiaan mereka sebagai p elan ggan. •
Melaksanakan stategi solusi yang lebih proaktif. Memakai solusi bisnis
y ang terfokus
p ada
pelanggan yang bek erja melewati seluruh bagian perusahaan. Darip ada hany a mengump ulkan data dan jaran g men ggunak anny a, hilangkan hal-hal yang sebelum hal tersebut mencapai tahap an y ang krisis. Pindahkan dari kump ulan data y ang reaktif ke hubungan p elan ggan yang p roaktif y ang memecahkan masalah pada p anggilan p ertama.
2.2.1.2 Tipe-tipe CRM Tip e-tipe arsitektur CRM adalah (Janice Rey nolds, 2002,p7): 1.
Operational CRM (CRM op erasional)
33 Pengelolaan secar a otomatisasi dari proses bisnis secara terintegrasi dan horisontal termasuk otomatisasi sales, otomasisasi marketing, dan otomatisasi customer service. 2.
Analytical CRM (CRM analitikal) Analisis data y ang dip eroleh dari CRM operasional untuk
mengetahui
perilaku
pelan ggan
dan
dapat
memanfaatkan data y ang ada untuk kep erluan p erusahaan. 3.
Collaborative CRM (CRM kolaboratif) Sep eran gkat
aplikasi
y an g
meliputi
email,
personalized publishing, e-communities dan sejenisnya untuk memudahkan p erusahaan dalam menjalin interaksi antara pelanggan dan perusahaan.
2.2.1.3 Tahapan pada C RM Tiga tahap an pada CRM dalam men gelo la pelanggan, y aitu(Kalakota dan Robinson, 1999, p 113-p116): 1.
Aquiring new customers Perusahaan berusaha mendap atkan p elanggan baru den gan memp romosikan produk-produk dan keunggu lan dalam pelayanannya yang membedakanny a dengan p erusahaan lain.
Pelanggan
p otensial
sangat
terkesan
ketika
perusahaan y ang dap at melay ani merek a sebelum mereka melakukan
p embelian.
Probabilitas
p enjualan
akan
menin gkat ketika calon p elan ggan men erim a resp on
34 permintaan mereka dalam satu samp ai tiga menit. Tujuan untuk memudahkan calon p elanggan dan m enciptakan transisi y ang mudah dari calon p elan ggan men jadi pelanggan. 2.
Enchancing the profitability o f existing customers Perusahaan menin gkatkan nilai tamb ah kep ada pelanggan yang sudah dimilikiny a dengan memberikan lay anan y ang lebih b aik untuk semua hal y ang berhubungan den gan pelanggan. Nilai tambah tersebut dapat berupa penawaran produk atau jasa dengan ku alitas y ang lebih baik. Relasi berkemban g k e ar ah p enjualan y an g bersif at cross-selling (p roduk komp lemen) dan up-selling (produk yang bermutu lebih b aik). Perusah aan dap at membuktikan komitmen mereka p ada keseharian den gan meny ediakan waktu dengan mend engarkan kein ginan p elan ggan dan den gan membangun fokus terhadap p elay anan.
3.
Retain ing profitab le customers for life Perusahaan pelanggan,
m emp ertahankan dimana
p erusahaan
hubun gan diharapkan
den gan dapat
memenuh i ap a yang d ibutuhkan oleh pelan ggan bukan apa yang dibutuhkan oleh p asar. Memp ertahankan pelanggan membutuhkan p engertian y ang len gkap dari kebutuhan pelanggan dan ketetapan untuk tetap menjalin hubun gan. Yan g
diber ikan
kepada
pelanggan
ad alah
sebuah
penawaran akan sebuah hubun gan y ang proaktif y ang
35 mengutamakan
keinginan
p elan ggan.
Perusahaan-
perusahaan y ang besar memfokuskan p ada retention daripada mendap atkan p elanggan baru.
2.2.2
Data Flow Diagram (DFD) Data Flow Diagram atau Diagr am alir an data adalah alat y ang men ggambarkan aliran data melaui sistem dan p roses y ang dilakukan oleh sistem tersebut. (Whitten et al, 2004, pp344-345)
2.2.2.1 Simbol DFD DFD memiliki tiga simbol dan satu koneksi : 1.
Persegi empat tumpul (Gane & Sarson shape), lingkaran (DeMarco/Yourdon
shape)
atau
persegi
p anjang
(SSADM/IDEF0) meny atakan proses y ang dilakukan sistem dalam meresp ons data atau kondisi y ang dih adapi. (Whitten et al, 2004, p 347)
2.
Persegi panjan g (DeMarco/Yourdon shape), bujur sangkar (Gane and Sarson shape) menyatakan orang luar, unit organisasi, sistem, atau organ isasi y ang berinteraksi dengan sistem (external agent). (Whitten et al, 2004,p363365)
36
3.
Kotak
dengan
ujun g
terbuka
dikedua
sisi
(DeMarco/Yourdon shape) atau disalah satu sisi (Gane and Sarson shape) meny atakan data store, atau disebut file atau database (Data) y aitu data y ang disimp an untuk kep erluan nanti. (Whitten et al, 2004,p366)
4.
Panah menyatakan aliran data, atau inp ut dan output, ke dan dari p roses tersebut. (Whitten et al, 2004,p 357)
2.2.3
State Transition Diagram STD adalah suatu diagram y ang menggamb arkan perubahan tahap an-tahapan atau kondisi-kondisi dalam suatu p rogram atau sistem dimana model diagram ter gantung pada definisi suatu state, sedangkan state ad alah suatu kump ulan model dari tingkah laku y ang d apat diamati. STD mewakili suatu tingkah laku dari suatu sistem dengan men ggambarkan state dan kejadian y ang menyebabkan sistem berubah ke state yang lain. STD merup akan suatu alat p erancan gan y ang men ggambarkan sifat keter gantungan p ada waktu dari suatu sistem.
37 Untuk melengkapi STD dip erlukan dua hal lagi, yaitu: Condition dan Action. Condition adalah suatu event pada external environment y ang dap at dideteksi oleh sistem. Action adalah y ang dilakukan oleh sistem bila terjadi p erubahan state atau merupakan reaksi terhadap condition. Action akan menghasilkan outpu t, message display p ada lay ar, men ghasilkan kalkulasi, d an lain-lain. Dalam STD terdapat beberapa komponen-komponen p enting y ang perlu diperhatikan yaitu sebagai ber ikut (Pressman, 2001, p 317318): 1.
Keadaan Sistem (System Sta tus) Digambarkan den gan sebuah kotak persegi p anjang, y ang berisi keadaan dari sebuah sistem. Keadaan dari sistem tersebut dap at berup a menunggu user memasukkan password, menunggu p erintah selanjutnya, dan lain-lain. Notasinya y aitu :
Gambar 2.njdkf Simbol State
2.
Perubahan Keadaan (Change of State) Perubahan keadaan atau state dalam STD digambarkan dengan gar is p anah y ang men ghubun gk an dua keadaan atau state yang salin g berkaitan. Notasinya y aitu :
Simbo l Perubahan S tate
38 3.
Kondisi dan Aksi (Condition and Action) Untuk
melengk api
pembuatan
sebuah
STD, maka
diperlukan adany a suatu komp onen tambahan yaitu kondisi dan aksi. Kondisi merupakan penyebab suatu keadaan m enjadi berubah, sedangkan aksi adalah yang dilakuk an oleh sistem bila terjadi p erubahan keadaan atau reaksi terhadap
kondisi.
Notasiny a y aitu : State 1 Kondisi Aksi State 2 Kondisi dan Aksi
2.2.4
Entitas Relationship Diagram ERD
merupakan
alat
bantu
y ang
digunakan
untuk
men ggambarkan model data y ang did ap at dari spesifikasi kebutuhan. M odel ERD biasany a diny atakan sebagai ERD. Bagian y ang memban gun model ERD adalah En titas types, relationship, dan attributes. (Connolly dan Begg, 2005, p40)
2.2.4.1 Tipe Entitas (Entity Type) Konsep dasar dari model ERD adalah Entity Types y aitu kump ulan dari objek-objek dengan sifat properti y ang sama, y ang diidentifik asi oleh en terprise memp uny ai eksistensi y ang independent. Entity typ e merupakan sekump ulan objek y ang
39 memiliki properties y ang sama didalam sebuah ap likasi. Kejadian entitas (Entity Occurrence) adalah ob jek y ang terindentifikasi
didalam tip e entitas.
Entitas
y ang bisa
didefinisikan antara lain : person, place ataupun concept. Beberap a contoh dari masin g-m asing tip e entitas adalah (Connolly dan Begg, 2005, p 343): •
Person : EMPLOYEE, STUDENT
•
Place : BRANCH, REGION, COUNTRY
•
Concepts of in terest: BID
•
Tip e entitas terbagi dalam 2 jenis, y aitu: a.
Strong
Entity
Type
:
Tip e
entitas
y ang
keberadaannya tidak bergantun g oleh adanya entitas lain. b.
Weak Entity Typ e : Tip e entitas y ang keb eradaannya bergantung oleh adany a entitas lain.
2.2.4.2 Hubungan (Relationship) Relationship adalah suatu hubungan y ang berarti antar satu atau lebih tip e entitas. Didalam suatu relationship terdap at batasan-batasan yang kita sebut dengan multip licity. Mu ltiplicity adalah nilai atau jangkauan n ilai dar i suatu kejadian tip e entitas yang mungkin berhubungan den gan kejadian tipe entitas lain melalui hubun gan y ang bersangkutan. Jenis batasan multip licity terdiri dar i (Connolly dan Begg, 2005, p 346):
40 •
One-to-one (1:1) Relationships
•
One-to-many (1:*) Relationships
•
Many-to-many (*:*) Relationships
2.2.4.3 Attribute Attribute adalah property atau karakter dari tipe entitas atau relationship. Setiap tip e entitas mempunyai satu set attribute. Attribute domain adalah himpunan nilai y ang dip erlukan untuk satu atau lebih attribute. Macam-macam a ttribute (Connolly dan Begg, 2005, p 350): 1.
Simple Attribute, yaitu attribute y ang terdiri d ari satu komp onen tunggal dengan keber adaan yan g indep endent dan tidak dap at dibagi m enjadi leb ih kecil lagi. Dik enal juga dengan n ama atomic attribute.
2.
Composite Attribute, y aitu attribute yang terdiri dari beberap a komponen, dimana masin g- masing komponen memiliki keb eradaan yang indep enden. Misalkan attribute Address dapat terdiri dari Street, City, PostCode.
3.
Single-valued Attribu te, y aitu attribute yang mempunyai nilai tunggal untuk setiap kejadian. Misalnya entitas Branch memiliki satu nilai untuk attribute branchNo p ada setiap kejadian.
41 4.
Multi-valued Attribute, y aitu attribute yan g mempunyai beberap a nilai untuk setiap kejadian. Misal entitas Branch memiliki n ilai untuk attribute telpNo pada setiap kejadian.
5.
Derived Attribute, yaitu attribute yan g m emiliki nilai y ang dihasilkan dari satu atau beber apa attribute lainny a, dan tidak harus berasal dar i satu entitas.
2.2.4.4 Keys Candidate key adalah beber apa attribute yang secara unik mengidentifik asikan setiap entitas. Primary key adalah attribute un ik y ang mengidentifikasi setiap row dalam table. Candidate key yang terp ilih untuk mengidentifik asi secara unik setiap entitas. Alternate key adalah candidate key y ang tidak terp ilih menjadi primary key. Composite key adalah candidate key yan g terdiri d ari dua attribute atau lebih. Foreign
key
adalah
attribute
sebuah
tabel
y ang
menggabungkan diri ke tabel lain. Beberapa entitas mungkin p uny a lebih dari satu candidate key, tetap i p erancang h arus memilih salah satu dari candidate key untuk dijadikan primary key. (Connolly dan Begg, 2005, p 352)
42 2.2.5
Arsitektur Basis data Oracle 2.2.5.1 S truktur Penyimpanan Logikal Oracle Datafiles d alam basis data Oracle dikelomp okkan bersama menjadi satu atau lebih tablespace. Dalam setiap tablespace, struktur logik b asis data Oracle, sep erti tabel dan
indeks,
memungkink an untuk memiliki kontrol y ang lebih efisien atas p enggun aan ruan g d isk. (Lonely dan Bryla, 2005, pp6-8) 1.
Blok Blok basis data adalah unit terkecil p eny imp anan dalam basis data Oracle. Ukuran blok adalah ju mlah by te dari penyimpanan dalam tablespace tertentu dalam b asis data.
2.
Extent Extent ad alah tingk at berikutnya dari p engelompokan logik dalam basis data. Sebuah extent terdiri dari satu atau lebih b lok basis data. Ketika ob jek basis data d ip erbesar, ruang ditamb ahkan ke objek tersebut dialokasikan sebagai sebuah extent.
3.
Segments Tingkat berikutny a dari p engelomp okan logis dalam basis data adalah segmen. Sebuah segmen ad alah sekelomp ok extents yang meliputi objek basis data y ang dip erlakukan sebagai satu unit, sep erti tabel atau indeks. Akibatnya, ini biasany a merupakan unit terkecil p eny imp anan dari b asis data y ang akan ditangani o leh end user. Emp at jenis segmen y ang ditemukan di basis data Oracle: data
43 segment, indeks segment, temporary segment, dan rollback segment. 4.
Tablespace Oracle tablespace terdiri dari satu atau lebih datafiles; sebuah datafiles dap at menjadi bagian dari satu dan hanya satu tablespace. Jika sebuah tablespace yang bersifat sementara mak a tablespace itu sendiri adalah permanen; hanya segmen y ang tersimp an dalam tablespace y ang bersifat sementara. Sebuah tab lespace temporary dapat digunakan untuk op erasi p eny ortiran dan sebagai area kerja untuk memb angun indeks.
2.2.5.2 S truktur Logika Basis data O racle Struktur logika basis data Oracle ad alah( Lonely dan Bry la, 2005, p8-p23): a.
Tabel Sebuah tabel adalah unit dasar penyimpanan dalam basis data oracle. Tanp a tabel, basis data tidak memiliki nilai b agi suatu p erusahaan. Terlepas dari jenis tabel, d ata dalam tabel disimp an dalam bar is dan kolom, mirip dengan bagaiman a data disimpan dalam spreadsheet.
b.
Constraints Oracle constraints adalah aturan - aturan y ang d apat didefinisik an pada satu atau lebih kolom dalam sebuah tabel untuk membantu menegakkan aturan bisnis. Seb agai
44 contoh, sebuah constraints b isnis dapat menegakkan aturan
bahwa seorang k ary awan
gaji awal h arus
setidakny a $ 25,000.00. Contoh lain dar i constraints menegakk an aturan bisnis adalah untuk mensy aratkan bahwa jik a karyawan baru d iberik an sebuah d ep artemen (walaupun
mereka
tidak
p erlu
diserahkan
kep ada
dep artemen tertentu langsun g), nomor dep artemen h arus masih berlaku dan ad a pada tabel DEPT. c.
Indeks Sebuah indeks Oracle memun gkink an akses cep at ke baris dalam sebuah tabel ketika b agian kecil dari baris akan diambil dari tabel. Indeks meny impan nilai kolo m atau kolom yang diind eks, bersam a dengan p ysical RowID dari baris y ang berisi nilai diindeks, kecuali untuk index organized table (IOTs), yang menggun akan p rimary key sebagai RowID lo gis. Entri dalam indeks secar a otomatis dip erbarui setiap
kali isi d ari sebuah
baris tabel
dimasukkan, d iperbarui dan dihap us. Ketika tabel dihap us, semua indeks dibuat di atas tabel juga secara otomatis dihapus. d.
Views Views memun gkinkan p engguna untuk melihat presentasi yang disesuaikan dar i data dalam satu tabel atau bahkan bergabung antara banyak tabel. Sebuah view biasa tidak
45 menyimp an data apap un, hany a definisi, dan p ermintaan yang mendasar i dijalankan setiap tampilan diakses. e.
Users dan schemas Akses ke basis data y ang diberikan ke dalam account basis data adalah p engguna. Seorang pengguna mungk in ada dalam basis data tanp a memiliki ob jek ap apun. Jika pengguna membuat dan memiliki ob jek dalam basis data, objek tersebut merupakan bagian d ari skema y ang memiliki nam a y ang sam a den gan pengguna basis d ata. Sebuah skema dapat memiliki semua jen is objek dalam basis data: tabel, indeks, sequ ences views, d an sebagainya. Pemilik skem a atau DBA dap at memberikan akses ke objek ini ke p engguna b asis data lain. Penggun a selalu memiliki kend ali penuh atas p rivilages dan objek-objek dalam skema p enggun a.
f.
Profiles Resource basis data tidak tak terbatas, karena itu, seorang DBA harus mengelo la dan men galokasikan resource di antara pengguna basis data. Profil b asis data adalah n ama set batas-batas resource y ang dap at ditugaskan untuk pengguna.
g.
Sequence Oracle sequence menetapkan nomor urut urutan, akan menghasilk an urutan yang unik k ecuali urutan diciptakan kembali atau men gatur ulang.
46 h.
Synonyms Oracle synonims hany alah sebuah alias untuk objek b asis data, untuk meny ederhanakan ref erensi ke objek basis data dan untuk meny embuny ikan rincian sumber objek basis data. Sinonim dap at ditugaskan untuk tabel, views, materialized views, sequences, procedures, fun ctions, dan packages.
i.
PL / SQL Oracle PL / SQL ad alah bahasa p rosedural Oracle perluasan dari PL / SQL yang bermanfaat bila pernyataan standart DM L dan p erny ataan select tidak
dapat
menghasilk an hasil yang diin ginkan dalam cara y ang mudah karen a kurangnya elemen-elemen prosedural ditemukan secara tradisional b ahasa gen erasi ketiga sep erti C dan Ada.
2.2.5.3 S trukur Penyimpanan fisik basis data Basis
data Oracle menggunakan sejumlah struktur
p eny imp anan fisik p ada disk untuk meny imp an dan mengelola data
dari
pengguna
transaksi.
Beb erap a
dari
struktur
p eny imp ananny a adalah (Lonely dan Bryla, 2005, p25-p29): a.
Datafiles Setiap basis data Oracle h arus mengandung setidaknya satu datafile. Satu datafile oracle sesuai den gan salah satu sistem op erasi fisik file di d isk. Setiap datafile di b asis
47 data Oracle adalah anggota dari satu dan hany a satu tablespace; tapi sebuah tablespace dap at terdiri dari banyak datafiles. b.
Redolog file Setiap kali data y ang ditambahk an, dihapus, atau diubah dalam tabel, indeks atau objek Oracle lainny a, sebuah entri ditulis pada file redolog. Setiap basis data oracle harus memiliki setidaknya dua file redolo g, karena Oracle menggunakan kembali file redolo g dalam p erulangan.
c.
Control file Setiap basis data Oracle m emiliki setidakny a satu file y ang menjaga metadata basis data (den gan k ata lain, d ata mengenai struktur fisik basis data itu sendiri). Antara lain, berisi nama basis data, ketika basis data dibuat dan namanama dan lokasi dari semua datafiles dan file-file redolo g.
d.
Archive log file Sebuah basis data oracle dap at beroperasi p ada salah satu dari dua mod e; modus archivelog atau noarchivelog. Ketika basis data dalam modus noarchivelog, p enggunaan kembali redolo g f ile secar a beru lang (ju ga diken al seb agai online redo lo g file) ber arti mengu lan g entri yang tidak lagi tersedia. Modus archivelog mengirim file redolog yang terisi ke satu atau beberap a tujuan tertentu dan dapat tersedia untuk merekonstruksi basis data p ada suatu titik
48 waktu tertentu dalam hal media basis data terjadi kegagalan. e.
Initialization parameter files Ketika instance basis data dimu lai, memori untuk Oracle instance dialokasikan, dan salah satu dari dua jenis parameter
initialization
file
dibuka.
Param eter
initialization file, terlepas dari format, menentukan lokasi file untuk trace files, con trol files, filled redo log files, dan sebagainy a. Mereka juga men entukan batas-batas p ada ukuran dari berbagai struktur di Sy stem Global Area dan juga berap a bany ak pengguna dap at terhubung ke basis data secara bersamaan. f.
Backup file Backup file dap at berasal dari berbagai sumber, sep erti sistem op erasi meny alin perintah atau Oracle Recovery Manager (RM AN). RMAN dap at menghasilk an backup penuh dan backup incremental dari datafiles, control files, archived redo log files, dan sebagainya.
g.
Password file Sebuah file p assword oracle adalah sebuah file di dalam Oracle administratif atau
p erangkat
lunak
struktur
direktori p ada disk y ang digunak an untuk p roses otentikasi administrator sistem Oracle untuk tugas seperti membuat basis data atau memulai dan mematikan b asis data. Hak
49 istimewa yang d iberikan m elalui file ini adalah hak istimewa SYSDBA dan SYSOPER.
