Bab 2 Landasan Teori

Bab 2
Landasan Teori
Pada bab ini, akan dijelaskan mengenai beberapa teori yang berkaitan dengan
permasalahan yang sedang dibahas dalam skripsi ini, dimana tinjauan pustaka yang
digunakan terdiri dari teori umum dan teori khusus.
2.1. Teori Umum
Teori umum merupakan teori pokok yang menjadi landasan bagi pemahaman
sebuah sistem serta metode yang digunakan dalam kegiatan pengembangan terhadap
sistem itu sendiri. Dalam penyusunan karya ilmiah ini, ada beberapa teori dasar yang
digunakan. Teori - teori ini digunakan sebagai acuan dalam membangun konsep yang
akan dipakai untuk merancang aplikasi. Adapun teori umum yang akan dibahas dalam
karya ilmiah ini antara lain :
2.1.1. Data
Menurut Elmasri and Navathe (2004, p4) data adalah fakta yang dapat disimpan
dan memiliki arti.
Menurut Hoffer, Prescott and McFadden (2009, p6), data merupakan representasi
objek dan kejadian yang disimpan yang memiliki arti dan kepentingan bagi pengguna
(user).
Menurut Turban & Rainer (2009, p6), data adalah fakta mentah atau deskripsi
dasar dari benda, peristiwa, aktivitas dan transaksi yang didapatkan, direkam, disimpan
dan diklasifikasi tetapi belum terorganisir untuk menyampaikan suatu arti spesifik.
Sedangkan menurut Connolly & Begg (2010, p70), data adalah komponen yang
paling penting dalam DBMS (Database Management System), berasal dari sudut
pandang end user.
Dari pendapat para ahli dapat disimpulkan bahwa data merupakan fakta-fakta
mentah yang belum diolah dan dapat merepresentasikan suatu aktivitas, kejadian, grafik,
gambar, dan lain-lain. Namun belum mengungkap makna tertentu.
11
12
2.1.2. Informasi
Menurut Turban dan Volonino (2010, p41), informasi adalah data yang telah
diatur sehingga memiliki makna dan nilai bagi penerimanya.
Menurut Widayana (2005, p12), informasi adalah data yang telah tersusun dan
disertai dengan refrensi terhadap suatu hubungan, mempunyai arti untuk membantu
pengambilan keputusan.
Menurut O’Brien (2005, p6) informasi adalah data yang telah diproses dengan
cara tertentu untuk meningkatkan pengentahuan dari orang yang menggunakan data
tersebut.
Dari pernyataan para ahli dapat disimpulkan bahwa informasi adalah sekumpulan
data yang telah diolah dan tersusun sehingga memiliki nilai manfaat untuk digunakan
dalam pengambilan keputusan.
2.1.3. Sistem
Menurut Connolly & Begg (2010, p266), sistem adalah cara untuk menjelaskan
ruang lingkup dan batas-batas dari sistem database dan pandangan pengguna utama.
Menurut O'Brien dan Marakas (2008, p24) sistem adalah sekumpulan komponen
yang saling berhubungan dengan batasan yang jelas, bekerja bersama untuk mencapai
tujuan bersama dengan menerima input serta menghasilkan output dalam proses
transformasi teratur. Sistem memiliki 3 fungsi dasar yaitu: input, process dan output.
James A.Hall (2011, p5) berpendapat bahwa "A system is a group of two or more
interrelated components or subsystems that serve a common purpose", artinya sistem
adalah sekelompok komponen atau subsystem yang memiliki tujuan yang sama.
Dari pendapat para ahli dapat disimpulkan, sistem adalah sekelompok elemen
/kumpulan data yang saling berhubungan dan berinteraksi dalam menerima input dan
menghasilkan output secara berkesinambungan dan terintegrasi yang bertujuan untuk
mencapai suatu tujuan tertentu.
13
2.1.4. Decision Making and Problem Solving
Menurut Mcleod (2001:111), problem adalah sebuah kondisi yang berpotensi
menghasilkan suatu gangguan atau keuntungan, sedangkan decision adalah suatu seleksi
dari suatu strategi dan aksi. Jadi menurut beliau, decision making adalah suatu tindakan
berbentuk strategi dan aksi yang dipercaya manajer dapat menawarkan solusi yang
terbaik terhadap masalah yang dihadapi.
2.1.4.1.
Elements of a Problem-Solving Process
Menurut Mcleod (2001:112), terdapat skema dari proses problem solving
seperti yang tertera pada gambar dibawah:
Gambar 2.1 Elements of a Problem Solving Process
Dalam gambar tersebut, standards menggambarkan desired state, yaitu berarti
apakah yang sistem harus capai? Apa tujuan dari dibentuknya sistem? Dan dalam jangka
waktu tertentu, seorang manajer harus memiliki informasi cukup yang menggambarkan
current state, yang berarti berupa pertanyaan apa yang telah sistem capai hingga saat
ini? Dan perbedaan antara current state dan desired state merepresentasikan solution
14
criterion, dalam arti lain bagaimana solusi yang tepat agar current state mencapai
desired state.
Sementara itu, internal constraints adalah suatu batasan atau aturan yang
diperhatikan dalam pemecahan masalah dengan memperhatikan batas sumber daya yang
ada di dalam perusahaan, dan environmental constraints dibentuk dari tekanan yang
datang dari berbagai macam lingkungan yang mempersulit alur sumber daya masuk atau
keluar dari perusahaan
2.1.5. Basis Data (Database)
Menurut Connolly & Begg (2010, p65), basis data adalah kumpulan data yang
saling berhubungan secara logis dan dideskripsikan serta dirancang untuk memenuhi
kebutuhan informasi dalam suatu organisasi.
Basis data mempresentasikan entitas, atribut, dan hubungan relasional antara
entity - entity. Entity merupakan suatu obyek nyata (manusia, tempat, benda, konsep,
atau kejadian) dalam suatu organisasi yang dipresentasikan dalam basis data. Atribut
merupakan suatu properti yang menjelaskan aspek dari obyek yang ingin disimpan.
Hubungan (relationship) merupakan suatu gabungan entity - entity dalam basis data.
Connolly mengatakan, basis data adalah tempat penyimpanan data tunggal
(mungkin dalam skala besar) yang dapat digunakan secara bersama – sama oleh banyak
departemen dan pengguna. Daripada menggunakan file – file yang berulang (redundant)
dan sama sekali tidak terhubung, basis data menyimpan semua data yang terintegrasi
dengan jumlah duplikasi data seminimal mungkin. Selain menyimpan data operasional
perusahaan, basis data juga menyimpan deskripsi mengenai data tersebut. Oleh karena
itu, basis data sering disebut dengan
“a self describing collection of integrated
Records”. Deskripsi mengenai data tersebut dikenal dengan kamus data atau metadata.
Menurut McLeod & Schell (2007, p181), database adalah kumpulan dari semua
sumber daya berbasis organisasi komputer dan database, hubungan antara data dalam
database dan juga dokumen dan laporan yang bersinggungan dengan database.
Menurut V. Post,Gerald (2005, p2) basis data adalah kumpulan data yang
tersimpan dalam format terstandarisasi, dirancang untuk dibagikan ke berbagai user.
15
Sedangkan menurut Hoffer (2009, p46),basis data adalah kumpulan data yang
terorganisir dan secara logika berkaitan. Terorganisir maksudnya adalah data dibuat
terstruktur sehingga mudah untuk disimpan, dimanipulasi, dan digunakan oleh
pengguna.
Dari pendapat para ahli, dapat disimpulkan bahwa basis data adalah suatu tempat
penyimpanan dari kumpulan data yang saling terhubung secara logis dan terorganisasi
yang dideskripsikan serta dirancang untuk memenuhi kebutuhan informasi serta
memudahkan atau membantu pekerjaan dalam suatu organisasi.
2.1.6. Sistem Basis Data
Menurut Connolly & Begg (2010, p67), sistem basis data adalah sekumpulan
program aplikasi yang berinteraksi dengan basis data.
Jadi dapat disimpulkan sistem basis data adalah aplikasi yang dibuat untuk
membantu pengguna melakukan pengolahan data yang terdapat dalam basis data untuk
mendapatkan suatu informasi yang dibutuhkan.
2.1.7. Sistem Manajemen Basis Data / Database Management System
(DBMS)
Menurut Connolly & Begg (2010, p66) Database Management System (DBMS)
adalah sebuah sistem perangkat lunak yang dapat memungkinkan pengguna untuk
mendefinisikan, membuat, dan memelihara database dan menyediakan kontrol akses
untuk database tersebut.
Menurut Atzeni et al. (2003, p2) DBMS adalah sistem piranti lunak yang
mempunyai kemampuan untuk mengatur database yang sangat besar, terbagi, dan
memastikan reabilitas dan keamanan data.
Dari pendapat para ahli, dapat disimpulkan bahwa DBMS adalah suatu aplikasi
perangkat lunak yang menyediakan akses ke basis data sehingga pengguna dapat
mendefenisikan, membuat, menyimpan, mengatur, dan memelihara basis data.
16
2.1.7.1.
Fasilitas DBMS
Menurut Connolly & Begg (2010, p66) umumnya sebuah DBMS menyediakan
fasilitas sebagai berikut :
a) Data Definition Language (DDL)
Menurut Connolly & Begg (2010, p92) DDL adalah bahasa pemrograman yang
mengijinkan
Database
Administrator
(DBA)
atau
pengguna/user
untuk
menggambarkan nama dari entitas, atribut, serta hubungan-hubungan yang
diperlukan pada aplikasi, bersamaan dengan asosiasi integritas dan keamanan data.
Skema basis data berisi tentang beragam definisi yang ditunjukan sebagai arti
dari bahasa khusus yang disebut DDL. DDL digunakan untuk mendefinisikan suatu
skema atau untuk merubah yang sudah ada, tetapi tidak bisa digunakan untuk
memanipulasi data. Hasil dari kompilasi DDL adalah berbagai macam tabel yang
disimpan secara kolektif di dalam suatu file khusus yang biasa disebut data
dictionary. Data dictionary diintegrasikan dengan metadata. Metadata ialah data
yang medeskripsikan objek di dalam basis data dan membuat data itu lebih mudah
untuk diakses atau dimanipulasi, metadata mengandung isi dari suatu records, jenis
data, dan objek lainnya yang berkaitan pada user atau yang dibutuhkan oleh DBMS.
b) Data Manipulation Language (DML)
Menurut Connolly & Begg (2010, p93) DML adalah bahasa pemrograman yang
menyediakan fasilitas untuk menyokong operasi untuk memanipulasi basis data yang
disimpan dalam basis data.
Operasi manipulasi data biasanya meliputi hal-hal berikut ini :
a.Penginputan data baru ke dalam basis data(insert).
b.Modifikasi data baru yang disimpan dalam basis data(update).
c.Pengambilan data simpanan dari basis data(select).
d.Penghapusan data yang ada di dalam basis data(delete).
17
DML memungkinkan user memasukkan, memperbaharui, menghapus, mengirim,
dan mengambil data dari basis data. Adapun beberapa contoh DML yaitu insert, update,
delete, select.
Sebagai pusat penyimpanan data dan deskripsi data memudahkan DML untuk
menciptakan fasilitas permintaan data umum, disebut juga query language.
.
c) Akses Kontrol
DBMS menyediakan akses kendali penuh ke database, seperti :
Keamanan Sistem / Security system
mencegah pengguna yang tidak memiliki otorisasi untuk mengakses basis
data
Integrasi sistem
menjaga konsistensi data yang tersimpan sehingga data tetap terintegrasi
dengan baik.
Pengendalian Share data/Sistem kontrol konkurensi
mengijinkan akses data untuk dapat diakses oleh basis data dan membagi
data yang diperlukan oleh masing – masing divisi.
Backup and Recovery System
mengembalikan basis data ke keadaan yang konsisten dari sebelumnya
setelah mengalami kegagalan perangkat keras atau perangkat lunak.
User-accessible catalog/catalog yang dapat diakses pengguna
Catalog tersebut berisi deskripsi data dalam basis data.
2.1.7.2.
Komponen DBMS
Menurut Connolly & Begg (2010, p68) terdapat lima komponen utama dalam
lingkungan DBMS, yaitu :
a. Perangkat Keras / Hardware
Hardware dapat berkisar dari komputer tunggal, mainframe tunggal,
hingga jaringan komputer. Penggunaan hardware tergantung pada
kebutuhan suatu organisasi dan DBMS yang akan digunakan.
18
b. Perangkat Lunak /Software
Komponen perangkat lunak merupakan perangkat lunak DBMS itu
sendiri dan program aplikasi yang tergabung dengan sistem operasi,
termasuk perangkat lunak jaringan apabila DBMS digunakan dalam suatu
jaringan komputer. Dalam menjalankan DBMS, software merupakan
program penggerak atau aplikasi yang dijalankan.
c. Data
Komponen paling penting pada lingkungan DBMS, dilihat dari sudut
pandang pengguna akhir adalah data. Data bertindak sebagai jembatan
antara komponen mesin dan komponen manusia. Basis data mencakup
data operasional dan metadata.
d. Prosedur/procedure
Prosedur merupakan instruksi dan aturan yang mengatur perancangan dan
penggunaan basis data dimana pengguna sistem dan pengelolaan basis
data memerlukan dokumentasi untuk menjalankan dan menggunakan
sistem.
e. Orang/People
Orang merupakan komponen terakhir dalam lingkungan DBMS. Ada
empat tipe orang dalam lingkungan DBMS yaitu:
1) Data Administrator (DA)
DA adalah adalah orang yang berwenang untuk mengatur sumber
data termasuk perencanaan basis data, pengembangan dan pemeliharaan
ketentuan, kebijakan dan prosedur, serta desain konseptual atau logikal
basis data.
19
2) Database Administrator(DBA)
DBA adalah orang yang bertanggung jawab untuk realisasi fisikal
dari basis data, termasuk desain fisikal basis data, implementasi, kontrol
keamanan dan integritas, memelihara sistem operasional, dan memastikan
kepuasan performa aplikasi untuk user.
3) Database Designer(DBD)
DBD terbagi menjadi dua yaitu logical database designer dan
physical database designer.
-
Logical database designer adalah orang yang mengidentifikasi
data (entitas dan atribut), hubungan antar data, dan constraint data
yang disimpan dalam basis data. Logical database designer harus
mengerti data perusahaan dan peraturan bisnis secara keseluruhan.
Peraturan bisnis menjelaskan karakteristik utama dari data yang
dilihat oleh perusahaan.
-
Physical database designer adalah orang yang memutuskan
bagaimana desain logikal basis data direalisasikan secara fisikal.
Hal ini termasuk mapping desain logikal basis data ke dalam tabel
dan integrity constraints, memilih struktur penyimpanan spesifik
dan metode akses untuk data disimpan dalam performa yang baik,
dan mendesain ukuran sekuritas yang dibutuhkan data.
4) Application Developer(AD)
AD
adalah
orang
yang
bertanggung
jawab
mengimplementasikan program aplikasi, dimana program aplikasi
yang dibuat dapat menyediakan fungsionalitas sesuai dengan
kebutuhan end user.
20
5) End Users
End Users terdiri dari dua macam yaitu näive users dan
sophisticated users.
1. Näive users yaitu orang yang secara umum tidak
mengetahui mengenai DBMS. Mereka mengakses basis
data melalui program aplikasi yang secara khusus ditulis
semudah mungkin.
2. Sophisticated users yaitu orang yang familiar dengan
struktur basis data dan fasilitas yang disediakan DBMS,
sehingga memungkinkan end users menulis program
aplikasi untuk digunakan sendiri.
2.1.7.3.
Kelebihan dan Kekurangan DBMS
Menurut Connolly & Begg (2010, p77), DBMS memiliki beberapa
keuntungan yaitu :
A. Menghilangkan redudansi data (Control of Data Redudancy)
DBMS dapat mengintegrasikan file sehingga data yang sama tidak
tersimpan berulang kali.
B. Meningkatkan keamanan data
Data yang disimpan diberi hak akses bagi pengguna tertentu yang dapat
membuka atau membaca file.
C. Konsistensi data (Data Consistency)
Dengan berkurangnya redundansi, data juga dapat lebih terjaga
konsistensinya. Jika item data disimpan hanya sekali di dalam basis data,
maka berbagai update bagi nilai data tersebut harus dibuat hanya sekali
dan nilai baru tersebut hanya tersedia dengan segera kepada semua
pengguna.
21
D. Meningkatkan integritas data
Validitas dari data yang disimpan merupakan integritas dari suatu data.
E. Sharing of Data
Data yang disimpan dapat dimiliki oleh perusahaan dan dapat dibagi
kepada semua pengguna yang diberi hak akses.
F. Meningkatkan Produktivitas
Deskripsi data dan logika pengaksesan data dibuat ke dalam beberapa
program aplikasi.
G. Improved Backup and Recovery Services
Jika terjadi kesalahan atau error, backup data dapat di-restored. Jika ada
data yang rusak maka data tersebut dapat di recovery
H. Informasi yang di peroleh data yang sama lebih banyak
Dengan integrasi data operasional, hal ini memungkinkan perusahaan
untuk mendapatkan tambahan informasi dari data yang sama.
I. Penetapan standarisasi pelaksanaan
Integrasi
memperbolehkan
DBA
untuk
menentukan
dan
menyelenggarakan standarisasi yang diperlukan seperti format data,
penamaan, dan prosedur update
J. Pengurangan biaya
Dengan menggabungkan data operasional suatu perusahaan kedalam
suatu basis data, dan membuat sebuah kumpulan aplikasi yang bekerja
pada suatu sumber data, akan dapat menghemat pengeluaran suatu
perusahaan.
22
K. Balance of conflicting requirements
Setiap pengguna atau department memiliki kebutuhan akan data yang
berbeda. Karena basis data berada dibawah kontrol DBA, maka DBA
dapat membuat keputusan tentang perancangan dan operasional data
suatu basis data.
L. Meningkatkan accessibility dan responsedata
Sebagai hasil integrasi, data yang melewati batas department dapat di
akses oleh pengguna akhir, hal ini akan menghasilkan sebuah sistem
dengan tingkat fungsionalitas yang tinggi.
M. Meningkatkan produktifitas
DBMS menyediakan sebuah lingkungan forth-generation environment
yang terdiri dari tools yang menyederhanakan pengembangan aplikasi
basis data. Hal inilah yang dapat meningkatkan produktifitas programmer
dan menghemat waktu pengembangan.
N. Meningkatkan pemeliharaan data melalui data independence (data
menjadi global)
Adapun kekurangan DBMS menurut Connolly(2010, p80) yaitu :
•
Kompleksitas
Ketentuan dari fungsi yang diharapkan dari DBMS yang baik
membuat DBMS menjadi sebuah software yang sangat
kompleks. Perancang dan pengembang basis data, DA (Data
Admnistrator) dan DBA (Database Administrator), serta
pengguna akhir harus memahami fungsi tersebut untuk
mendapatkan banyak keuntungan dari DBMS ini.
23
•
Ukuran
Fungsi yang kompleks dan luas membuat DBMS menjadi software
yang sangat besar, memerlukan banyak ruang hardisk dan jumlah
memory yang sangat besar untuk berjalan dengan efisien.
•
Biaya penggunaan DBMS
Biaya DBMS bervariasi, tergantung pada lingkungan dan fungsi yang
disediakan, disana juga terdapat biaya pemeliharaan yang juga
dimasukkan dalam daftar harga DBMS.
•
Biaya penambahan perangkat keras
Kebutuhan tempat penyimpanan bagi DBMS dan basis data sangat
memerlukan pembelian tempat penyimpanan tambahan. Lebih lanjut,
untuk mencapai performa yang diperlukan, mungkin diperlukan
untuk membeli mesin yang lebih tinggi spesifikasinya tergantung dari
perangkat keras yang dibutuhkan.
•
Biaya konversi
Dalam situasi tertentu, biaya dari DBMS dan perangkat keras yang
berlebihan memungkinkan adanya tambahan biaya yang termasuk
biaya
training,
dan
biaya
staff
spesialis
untuk
membantu
mengkonversi dan menjalankan sistem.
•
Kinerja
Sistem berbasis file biasanya ditulis untuk aplikasi khusus, sehingga
menghasilkan performa yang sangat baik. Akan tetapi, DBMS ditulis
lebih umum sehingga mengakibatkan beberapa aplikasi tidak berjalan
sebagaimana mestinya.
24
•
Dampak yang lebih besar dari kegagalan
Jika semua bergantung pada ketersediaan DBMS, kegagalan
komponen dapat berdampak besar pada operasi perusahaan.
2.1.8. The-Three Level ANSI-SPARC Architecture
Menurut Connolly & Begg (2005, p34) bagian dari three-level
architecture terdiri dari external, conceptual, dan internal level. Cara user
melihat suatu data disebut bagian external, cara DBMS dan sistem melihat suatu
data disebut sebagai internal level, dimana data disimpan menggunakan sebuah
struktur data dan file organization. Conceptual level ini menjelaskan data apa
saja yang disimpan didalam database dan bagaimana hubungan antar datanya.
Gambar 2.2 Arsitektur Three Level ANSI-SPARC
Tujuan utama dari three-level architecture ini sebenarnya adalah untuk
memisahkan setiap hak akses user terhadap database dari keadaan database yang
sebenarnya. Ada beberapa alasan yang mendasari hal tersebut :
25
1. Setiap user harus bisa mengakses setiap data yang ada, tetapi akan berbeda
sudutpandangnya mengenai suatu data, dan setiap user pun bisa mengubah
sudut pandangnya mengenai data, tetapi hal ini tidak akan berpengaruh
terhadap user lainnya.
2. Setiap user tidak bisa langsung mengubah detail data pada database. Dengan
kata lain interaksi user harus bersifat independent dari database.
3. Database administrator harus bisa mengubah struktur database tanpa harus
merubah user’s view.
4. DBA seharusnya bisa merubah struktur konseptual dari database tanpa
mempengaruhi semua user.
5. Internal struktur dari database seharusnya tidak berpengaruh terhadap
perubahan alat penyimpanan.
2.1.9. Cause Effect analysis
Menurut Whitten and Bentley (2007,p180), Cause Effect analysis adalah sebuah
teknik Diana masalah dipelajari untuk mengetahui penyebab dan akibat dari
permasalahan tersebut. Permasalahan harus dianalisis penyebab dan akibatnya sampai
waktu penyebab dan akibat tidak menghasilkan gejala masalah lain. Cause effect
analysis menyebabkan pemahaman yang benar mengenai masalah dan dapat mengarah
pada solusi yang tidak begitu jelas tetapi lebih kreatif dan berharga.
2.1.10. Database system Development Lifecycle
Menurut connoly and Begg (2010, p312), ketika software yang dikembangkan
adalah database system lifecycle yang digunakan adalah database system development
lifecycle (SDLC). Sebuah database system merupakan komponen fundamental dari
organisasi yang besar dengan sistem informasi yang luas, database system development
lifecycle terkait dengan lifecycle dari information system.
Perlu diingat bahwa tahapan dalam database system development lifecycle tidak
harus berurutan, namun juga dapat melibatkan beberapa pengulangan ke tahapan
sebelumnya melalui feedback loops.
26
Untuk database system, dengan user yang sedikit, lifecycle tidak perlu kompleks.
Ketika mendesin sebuah database system yang sedang atau besar dengan sepuluh sampai
ribuan user menggunakan ratusan query dan program aplikasi, lifecycle dapat menjadi
sangat kompleks.
Gambar 2.3 Database system development lifecycle
(sumber : connoly and Begg, 2010, p314)
2.1.10.1.
Database Planning
Database Planning merupakan kegiatan pengaturan yang memungkinkan
tahapan - tahapan database system development lifecycle direalisasikan seefektif dan
seefisien mungkin.
27
2.1.10.2.
System definition
System definition menggambarkan ruang lingkup dan batasan dari database
system dan user view utama.
User view mendefinisikan apa yang dibutuhkan oleh database system dari sudut
pandang peranan pekerjaan tertentu (seperti manager atau supervisor) atau area aplikasi
perusahaan (seperti marketing, personnel, atau stock control).
2.1.10.3.
Requirement Collection and analysis
Requirement collection and analysis merupakan proses mengumpulkan dan
menganalisis informasi mengenai bagian organisasi yang didukung oleh database system
dan menggunakan informasi ini untuk mengidentifikasi kebutuhan untuk sistem baru.
2.1.10.4.
Database design
Database design merupakan proses membuat rancangan yang akan mendukung
pernyataan misi dan tujuan misi suatu perusahaan untuk database system yang
diperlukan.
2.1.10.5.
DBMS(Optional)
Memilih Sebuah DBMS yang cocok untk mendukung database system.
2.1.10.6.
Application design
Application design merancang user interface dan aplikasi program yang
digunakan dan memproses database.
2.1.10.7.
Prototyping (Optional)
Prototyping adalah membangun sebuah model kerja dari database system.
Tujuan utama dari mengembangkan prototype database system adalah untuk
memungkinkan pengguna menggunakan prototype untuk mengidentifikasi fitur yang
bekerja pada sistem bekerja dengan baik atau tidak, dan apabila memungkinkan untuk
menyarankan perbaikan atau bahkan fitur baru untuk database system.
28
2.1.11. Perancangan Basis Data
Menurut Connolly & Begg (2010, p65), database adalah koleksi bersama dari
data yang terkait secara logis dan deskripsi dari data tersebut, yang dirancang untuk
memenuhi kebutuhan informasi suatu organisasi.
Perancangan database adalah proses menciptakan desain untuk sebuah database
yang akan mendukung operasi dan tujuan dari suatu perusahaan. Dua pendekatan utama
untuk perancangan database yaitu bottom – up dan top-down. connoly and Begg (2010,
p320).
a. Pendekatan Bottom - up
Pendekatan bottom-up dimulai dari tingkat dasar atribut, yang melalui
hubungan analisis antar atribut, yang dikelompokan ke dalam hubungan yang
mewakili tipe entitas dan hubungan antar entitas. Pendekatan Bottom-up tepat
untuk rancangan database sederhana dengan jumlah atribut yang relatif kecil.
Namun pendekatan ini menjadi sulit ketika diterapkan pada perancangan
database yang lebih kompleks.
b. Pendekatan top - down
Strategi yang tepat untuk perancangan database yang lebih kompleks adalah
dengan menggunakan pendekatan top - down. Pendekatan top - down
diilustrasikan menggunakan konsep entity relationship model dimulai dengan
mengidentifikasi entitas dan hubungan antar entitas.
Menurut Connoly and Begg (2010, p322), perancangan database terdiri dari 3
tahapan utama yaitu :
1. Perancangan konseptual
Perancangan konseptual adalah proses membangun suatu model informasi
yang digunakan suatu perusahaan, yang berdiri sendiri terhadap semua
pertimbangan fisikal.
29
2. Perancangan logikal
Basis data logikal adalah proses membangun model informasi yang
digunakan dalam suatu perusahaan berdasarkan pada spesifik data model
tetapi berdiri sendiri terhadap semua fakta - fakta DBMS dan pertimbangan
fisikal lainnya.
3. perancangan fisikal
Perancangan basis data fisikal adalah proses menghasilkan suatu deskripsi
mengenai implementasi basis data pada media penyimpanan sekunder,
menggambarkan dasar file organisasi, dan indeks yang digunakan untuk
mencapai efisiensi akses terhadap data, dan semua integritas constraint dan
pengukuran keamanan.
2.1.12. Entity –Relationship (ER) Modelling
Menurut Connolly & Begg (2010, p371), Entity-Relationship (ER) Modelling
merupakan pendekatan up - down untuk model perancangan database yang dimulai
dengan mengidentifikasi data penting yang disebut entitas dan hubungan diantara
data yang harus direpresentasikan ke dalam model. Kemudian menambahkan lebih
banyak detail, seperti informasi yang terus diinginkan mengenai entitas dan
hubungan yang disebut atribut dan setiap constraint pada entitas, hubungan, dan
atribut.
2.1.12.1.
Tipe entitas
Connolly & Begg (2010, P372), tipe entitas adalah kumpulan objek dengan sifat
yang sama, dimana tipe entitas diidentifikasi oleh perusahaan yang mempunyai
keberadaan yang madiri. Tipe entitas merepresentasikann kumpulan objek di dalam
dunia nyata dengan sifat yang sama, objek dengan physical existence (nyata), dan
objek dengan conceptual existence (abstrak).
30
Physical Existence
Pasien
Dokter
Karyawan
Obat
Conceptual Extence
Rawat jalan
Penjualan
Rawat Inap
Rekam Medis
Tabel 2.1 Contoh physical existence dan conceptual existence
2.1.12.2.
Tipe hubungan
Menurut Connolly & Begg (2010, p374), tipe hubungan adalah suatu set
asosiasi yang bermakna diantara tipe entitas derajat tipe hubungan (Degree of
Relationship Type). Tingkat hubungan menunjukan jumlah jenis entitas yang
terlibat dalam suatu hubungan. Oleh karena itu, derajat tipe hubungan
menentukan jumlah dari tipe entitas yang terlibat dalam relationship.
Hubungan dari derajat dua (Degree two) disebut binary. Binary relationship
menujukan dua tipe entittas yang berpartisipasi. Adapun contoh binary yaitu
Hubungan dari derajat tiga (degree three) disebut ternary. Ternary
relationship menunjukan tiga tipe entitas yang berpartisipasi. Hubungan dari
derajat empat (degree four) disebut quaternary. Quatenary relationship
menunjukan empat tipe entitas yang berpartisipasi. Hubungan Rekrusif
(Recrusive Relationship) merupakan tipe hubungan yang merupakan tipe entitas
yang sama yang berpartisipasi dalam lebih dari satu kali peran yang berbeda.
31
2.1.12.3.
Atribut
Atribut adalah property dari sebuah entitas atau tipe hubungan. Domain adalah
setiap atribut yang terkait dengan sekumpulan nilai. Atribut dapat diklasifikasikan
sebagai berikut :
o Simple dan Composite Attributes
Simple atribut adalah atribut yang tersusun dari komponen tunggal,
contohnya: nama pasien rumah sakit.
Composite atribut adalah atribut yang tersusun dari banyak komponen,
contohnya : alamat pasien rumah sakit.
o Single –Value Attributes dan Multi-Value Attributes
Single –Value Atribut adalah atribut yang memiliki nilai tunggal untuk
setiap kejadian. Sebuah tipe entitas, contohnya: nomor rekam medis
pasien rumah sakit.
Multi-Value atribut adalah atribut yang memiliki banyak nilai untuk
setiap kejadian sebuah tipe entitas, contohnya: nomor telpon pasien
rumah sakit.
o Derived Attributes
Derived atribut adalah atribut yang merepresentasikan nilai yang
diturunkan dari nilai atribut terkait atau satu set atribut, tidak perlu dalam
tipe entitas yang sama, contohnya: subtotal pembayaran layanan rumah
sakit.
2.1.12.4.
Keys
Ada beberapa jenis keys yang digunakan dalam membuat ER – Model
antara lain :
•
Candidate key adalah set atribut minimal yang diidentifikasi
secara unik dari masing-masing kejadian tipe entitas.
•
Primary key adalah candidate key yang terpilih.
32
•
Alternate key adalah candidate key yang terdiri dari dua atau
lebih atribut yang terpilih.
2.1.12.5.
Jenis entitas
Ada 2 tipe entitas dalam pembuatan ER – Model yaitu :
•
Strong entity type
Strong entity type merupakan jenis entitas yang tidak tergantung pada
keberadaan beberapa jenis entitas lainnya. Jenis entitas disebut sebagai Strong
entity type jika keberadaannya tidak bergantung pada keberadaan entitas jenis
lain. Strong entity type terkadang disebut sebagai parent, owner atau dominan
entities. Connoly & Begg (2010, p383).
•
Weak Entity type
Weak Entity type merupakan jenis entitas yang keberadaannya tergantung pada
beberapa tipe entitas lainnya. Weak Entity type bergantung pada keberadaan
entitas jenis lain. Karakteristik dari weak entity adalah bahwa setiap kemunculan
entitas tidak dapat diidentifikasi secara unik hanya dengan menggunakan atribut
yang terkait dengan jenis entitas. Weak Entity type terkadang disebut sebagai
child,dependent,or subordinate entities. Connolly & Begg (2010, p384).
2.1.12.6.
Structural Constraint
Tipe hubungan biasanya mempunyai constraint tertentu yang membatasi
kemungkinan kombinasi dari entitas yang mungkin berpartisipasi dalam
sekumpulan hubungan yang terkait Elmasri and Navathe (2000, p56).
Tipe utama dari constraint dalam relationship disebut multiplicity.
Multiplicity adalah jumlah kemungkinan terjadinya suatu tipe entitas yang
mungkin berhubungan dengan kejadian tunggal dari sebuah tipe entitas terkait
melalui hubungan tertentu Connolly & Begg (2010, p385).
33
Ada beberapa jenis multiplicity antara lain :
•
One – to - one (1:1) Relationship
Pada atribut dari One-to-one (1:1) Relationship dapat pindah ke salah satu tipe
entitas yang berpartisipasi
•
One - to - many(1:*) Relationship
Pada hubungan 1:*, hubungan atribut hanya dapat pindah ke tipe entitas pada
bagian -*(many) dari sebuah hubungan.
•
Many – to – many (*:*)Relationship
Untuk tipe hubungan *:*, beberapa atribut dapat ditentukan oleh kombinasi dari
entitas yang berpartisipasi dalam hubungan instance, bukan oleh satu entitas saja.
Atribut tersebut harus ditentukan sebagai hubungan atribut.
2.1.13. Normalisasi
Normalisasi data dapat dilihat sebagai sebuah proses menganalisis skema
relasi
yang
depedencies)
diberikan
dan
property/atribut
berdasarkan
primary
dan
key
ketergantungan
untuk
meminimalkan
fungsi
meminimalkan
update
perulangan
anomalies.
Navathe(2004, p313).
Tabel 2.2 StaffBranch Relation
(Sumber : Connoly and Begg,2010,p419)
(Functional
Elmasri
dari
and
34
Update anomalies diklasifikasikan menjadi beberapa kelompok antara lain :
A. Insertion Anomalies
Terdapat dua tipe utama insertion anomalies, dapat diilustrasikan dengan
menggunakan staffBranch Relation pada tabel 2.2 Connoly & Begg (2010,
p419)
Untuk memasukan rincian anggota baru dari staff ke dalam relasi
staffBranch, harus memasukan juga detail dari cabang dimana
staff akan berada.
Untuk memasukan rincian cabang baru yang pada saat itu belum
mempunyai anggota dari staff di dalam relasi staffBranch, perlu
untuk memasukan null ke atribut staff, seperti StaffNo, namun
StaffNo adalah primary key dari relasi satffBranch, memasukan
null untuk melanggar entity integrity dan tidak diperbolehkan
B. Delete Anomalies
Jika
menghapus
sebuah
basis
dari
relasi
StaffBranch
yang
merepresentasikan anggota lama dari staff yang berlokasi pada sebuah
cabang, rincian mengenai cabang tersebut juga akan hilang dari database.
Connolly & Begg(2010, p419)
C. Modification Anomalies
Jika ingin mengubah nilai dari salah satu atribut pada cabang tertentu di
dalam relasi StaffBranch. Sebagai contoh : alamat dari cabang yang
bernomor B003, update harus dilakukan pada semua baris yang berlokasi
pada cabang tersebut. Connolly & Begg (2010, p420)
D. Functional Dependencies
Ketergantungan fungsi (Functional Dependencies) adalah pembatas
antara dua set atribut dari database. Elmasri & Navathe (2004, p304).
Functional dependencies dibagi menjadi 3 yaitu full functional
dependency, partial dependency, transitive dependency.
35
Full Functional dependency
Full Functional dependency menunjukan jika A dan B adalah atribut
dari sebuah relasi, B merupakan Full Functional dependent pada A,
tetapi tidak pada setiap bagian dari A. Connolly & Begg (2010, p423)
Full Functional dependency dapat ditunjukan sebagai berikut :
StaffNo -----> branchNo
Partial dependency
Partial dependency jika terdapat beberapa atribut yang bisa
dihilangkan dari A dan meskipun dependency masih dimilikiConnolly
& Begg(2010,p423)
StaffNo,sNameBranchNo
Contoh diatas bukan merupakan full function dependency, karena
BranchNo juga functionally dependency pada subset dari (StaffNo,
sName) yaitu StaffNo
Transitive dependency
Transitive dependency merupakan sebuah kondisi dimana A, B, dan C
adalah atribut dari sebuah relasi seperti AB dan BC, maka C
adalah Transitive dependent pada A melalui B. Connolly & Begg,
(2010, p424)
StaffNo sName, Position, Salary, BranchNo, bAddress
BranchNo bAddress
Transitive dependency BranchNo bAddress terjadi pada StaffNo
melalui BranchNo
2.1.13.1.
Unnormalized Form (UNF)
Tabel yang berisi satu atau lebih grup yang berulang.Pada tahap ini
mentransfer data dari sumber menjadi format tabel dengan baris dan
kolom. Connolly & Begg ( 2010, p430)
36
Client
cName
No
Property
pAddress
RentStart RentFinish Rent
No
CR76
John
Owne
oName
rNo
PG4
Kay
6 Lawrence 1-Jul-07
31-Aug-08 350
CO40
St,Glasglow
PG16
5
Tina
Murphy
Novar 1-Sep-08
1-Sep-09
450
CO93
Dr,Glasglo
Tony
Shaw
w
CR56
Aline
PG4
Stewart
6 Lawrence 1-Sep-06
10-Jun-07
350
CO40
St,Glasglow
PG36
PG16
2
Murphy
Manor 10-June-
Rd,
07
Glasglow
1-Nov-
1-Dec-08
375
CO93
10-Aug-10 450
CO93
Glasglow
Tabel 2.3 ClientRental Unnormalized Table
(Sumber : Connolly & Begg,2010,p432)
Berdasarkan gambar diatas struktur dari repeating group adalah sebagai berikut :
(PropertyNo, pAddress, RentStart, RentFinish, Rent,
OwnerNo, oName)
2.1.13.2.
Tony
Shaw
5 Novar Dr, 09
RepeatingGroup =
Tina
First Normal Form (UNF)
1NF didefinisikan untuk melarang atribut bernilai ganda, komposit atribut, dan
kombinasi keduanya. 1NF menyatakan bahwa domain dari atribut harus dan hanya
mencakup nilai atomic (tidak terpisahkan) dan nilai - nilai atribut dalam tuple harus
nilai tunggal dari domain atribut tersebut. Dengan kata lain 1NF melarang
“hubungan dalam hubungan”. Nilai - nilai atribut yang hanya diijinkan oleh 1NF
adalah nilai atomic tunggal. Elmasri and Navathe(2004, p315)
Tony
Shaw
37
ClientNo
CName
CR76
John Kay
CR56
Aline Stewart
Tabel 2.4 1NF Client
(Sumber : Connolly & Begg,2010,p433)
Client
cName
No
CR76
Property
pAddress
RentStart RentFinish Rent
No
John
Owne
oName
rNo
PG4
6 Lawrence 1-Jul-07
Kay
31-Aug-08 350
CO40
St,Glasglow
PG16
5
Tina
Murphy
Novar 1-Sep-08
1-Sep-09
450
CO93
Tony
Shaw
Dr,Glasglo
w
CR56
Aline
PG4
6 Lawrence 1-Sep-06
Stewart
10-Jun-07
350
CO40
St,Glasglow
PG36
PG16
2
Murphy
Manor 10-June-
Rd,
07
Glasglow
1-Nov-
5
1-Dec-08
375
CO93
Tony
Shaw
10-Aug-10 450
CO93
Novar 09
w
Tabel 2.5 1NF PropertyRentalOwner
(Sumber : Connolly & Begg,2010, p433)
Hasil dari relasi 1NF adalah sebagai berikut :
Client (ClientNo, cName)
PropertyRentalOwner (ClientNo, PropertyNo, pAddress, RentStart,
Tony
Shaw
Dr,Glasglo
Rent, OwnerNo, oName)
Tina
RentFinish,
38
2.1.13.3.
Second Normal Form (2NF)
2NF didasarkan pada konsep full function dependency. Ketergantungan
fungsional X→Y akan full functional dependency jika menghapus atribut A dari
X menyebabkan ketergantungan tersebut menjadi tidak ada. Berarti untuk setiap
atribut A bagian dari X secara fungsional tidak menentukan Y. Sebuah
ketergantungan fungsional akan partial dependency jika beberapa atribut A
bagian dari X dapat dihilangkan dan ketergantungan tetap terjaga. Elmasri &
Navathe (2004, p318). Untuk hubungan dimana Primary Key mengandung
beberapa atribut, tidak ada atribut nonkey yang boleh bergantung secara
fungsional pada bagian Primary Key.
ClientNo
CName
CR76
John Kay
CR56
Aline Stewart
Tabel 2.6 2NF Client
(Sumber : Connolly & Begg,2010,p435)
ClientNo
PropertyNo
RentStart
RentFinish
CR76
PG4
1-Jul-07
31-Aug-08
CR76
PG16
1-Sep-08
1-Sep-09
CR56
PG4
1-Sep-06
10-Jun-07
CR56
PG36
10-June-07
1-Dec-08
CR56
PG16
1-Nov-09
10-Aug-10
Tabel 2.7 2NF Rental
(Sumber : Connolly & Begg,2010,p435)
39
PropertyNo
pAddress
PG4
6
Rent
Lawrence 350
OwnerNo
oName
CO40
Tina
St,Glasglow
PG16
5
Novar 450
Murphy
CO93
Dr,Glasglow
PG36
2 Manor Rd, 375
Tony Shaw
CO93
Glasglow
Tony Shaw
Tabel 2.8 2NF PropertyOwner
(Sumber : Connolly & Begg,2010,p435)
Relasi yang didapat adalah sebagai berikut :
Client (ClientNo, cName)
Rental (ClientNo, PropertyNo, RentStart, RentFinish)
PropertyOwner (PropertyNo, pAddress, Rent, OwnerNo, oName)
2.1.13.4. Third Normal Form (3NF)
3NF didasarkan pada konsep transitive dependency. Ketergantungan
fungsional X→Y dalam skema relasi R akan transitive dependency jika ada satu
set atribut Z yang bukan candidate key ataupun subset dari key pada R, dan
kedua X →Z dan Z→Y tetap bertahan. Elmasri & Navathe (2004, p319). Relasi
tidak boleh memiliki atribut nonkey yang bergantung secara fungsional pada
atribut nonkey lainnya. Tidak boleh ada transitive dependency dari atribut
nonkey pada primary key.
40
PropertyNo
pAddres
PG4
6
Rent
Lawrence 350
OwnerNo
CO40
St,Glasglow
PG16
5
Novar 450
CO93
Dr,Glasglow
PG36
2
Manor Rd, 375
CO93
Glasglow
Tabel 2.9 3NF PropertyForRent
(Sumber : Connolly & Begg,2010,p436)
OwnerNo
Oname
CO40
Tina Murphy
CO93
Tony Shaw
CO93
Tony Shaw
Tabel 2.10 3NF Owner
(Sumber : Connolly & Begg,2010,p436)
Hasil dari relasi 3NF adalah sebagai berikut :
Client (ClientNo, cName)
Rental (ClientNo, PropertyNo, RentStart, RentFinish)
PropertyForRent (PropertyNo, pAddress, Rent, OwnerNo, oName)
Owner (OwnerNo, oName)
2.1.17 Perancangan Basis Data Konseptual
Proses membangun data model yang digunakan dalam suatu perusahaan. Conolly
& Begg ( 2010, p322).
41
Tujuan dari perancangan basis data konseptual adalah untuk membangun model
data konseptual dari data yang dibutuhkan oleh perusahaan. Perancangan basis data
konseptual terdiri dari langkah-langkah berikut ini :
Langkah 1 : Membangun model data konseptual
1.1 Mengidentifikasi tipe entitas
Tipe entitas dapat diketahui dengan mengidentifikasi kata benda, mencari
objek utama seperti orang (people), tempat (place) atau konsep yang menarik
(concept of interest). Tahap ini bertujuan untuk mengidentifikasi tipe entitas
yang dibutuhkan sesuai dengan spesifikasi kebutuhaan pengguna.
1.2 Mengidentifikasi tipe hubungan
Bertujuan untuk mengidentifikasi hubungan (relationship) penting yang ada
diantara tipe entitas. Tipe hubungan dapat diindikasikan dengan kata kerja
atau ekspresi verbal (verbal expression).
1.3 Mengidentifikasi dan menghubungkan atribut dengan entitas atau tipe
hubungan
Bertujuan untuk menghubungkan atribut dengan entitas dan tipe hubungan
yang sesuai. Atribut dapat diklasifikasikan sebagai simple/ composite, singlevalued/multi-valued atau derived.
1.4 Menentukan domain atribut
Bertujuan menentukan domain untuk atribut dalam model data konseptual.
Domain atribut adalah himpunan nilai yang diijinkan untuk satu atau lebih
atribut.
1.5 Menentukan atribut candidate, primary, dan alternate key
Bertujuan untuk mengidentifikasi candidate key(s) untuk setiap tipe entitas
dan jika ada lebih dari satu candidate key, pilih satu untuk menjadi primary
key dan yang lainnya sebagai alternate key.
42
1.6 Mempertimbangkan penggunaan enhanced modelling concepts (optional
step)
Bertujuan untuk mempertimbangkan penggunaan dari enhanced modelling
concepts, seperti specialization/generalization, aggregation dan composition.
1.7 Memeriksa model terhadap redundancy
Bertujuan untuk mengecek adanya redundancy pada sebuah model.
1.8 Memvalidasikan model data konseptual terhadap transaksi pengguna
Bertujuan untuk memastikan model data konseptual mendukung transaksi
yang dibutuhkan. Dua kemungkinan pendekatan untuk memastikan model
data konseptual mendukung transaksi yang dibutuhkan :
a.Mendeskripsikan transaksi
b.Menggunakan jalur transaksi
1.9 Meninjau model data konseptual dengan pengguna
Bertujuan untuk mengecek ulang model data konseptual dengan pengguna
untuk memastikan apa yang dipikirkan oleh pengguna menjadi representasi
nyata dari data yang dibutuhkan oleh pengguna.
43
Gambar 2.5 Perancangan basis data konseptual
(Sumber : Connolly & Begg,2010,p480)
2.1.18 Perancangan Basis Data Logikal
Proses membangun data model yang digunakan dalam suatu perusahaan
berdasarkan pada model data yang spesifik tetapi tidak bergantung pada suatu DBMS
tertentu dan pertimbangan fisik lainnya. Connolly & Begg (2010, p322).
Tujuan dari perancangan basis data logikal adalah untuk menerjemahkan model data
konseptual ke dalam model data logikal kemudian memvalidasi model tersebut untuk
mengecek struktur yang benar dan mampu mendukung transaksi yang dibutuhkan.
Perancangan basis data konseptual terdiri dari langkah – langkah berikut ini :
44
Langkah 2 : Membangun model data logikal
2.1 Menurunkan hubungan untuk model data logikal
Bertujuan
membuat
merepresentasikan
hubungan
entitas,
model
hubungan,
data
dan
logikal
atribut
yang
untuk
telah
diidentifikasi. Menjelaskan bagaimana hubungan dapat diturunkan dari
struktur model yang ada sekarang, antara lain :
•
Tipe strong entity
•
Tipe weak entity
•
One – to – many (1:*) binary relationship types
•
One – to – one (1:1) binary relationship types
•
One – to – one (1:1) recursive relationship types
•
Superclass / subclass relationship types
•
Many – to – many (*:*) binary relationship types
•
Complex relationship types
•
Multi – valued attributes
2.2 Memvalidasi hubungan dengan menggunakan normalisasi
Bertujuan untuk memvalidasi hubungan di dalam model data
logikal dengan menggunakan normalisasi.
2.3 Memvalidasi hubungan terhadap transaksi pengguna
Bertujuan untuk memastikan hubungan di dalam model data logikal
mendukung transaksi yang dibutuhkan.
2.4 Memeriksa integrity constraints
Bertujuan
untuk
memeriksa
apakah
integrity
constraints
direpresentasikan di dalam model data logikal. Berikut ini jenis integrity
constraints :
a. Data yang dibutuhkan
b. Attribute domain constraints
45
c. Multiplicity
d. Entity integrity
e. Referential integrity
f. General constraint
2.5 Meninjau model data logikal dengan pengguna
Bertujuan untuk memeriksa kembali model data logikal dengan pengguna
untuk memastikan model
yang mereka pertimbangkan menjadi
representasi nyata dari data yang dibutuhkan oleh pengguna.
2.6 Menggabungkan model data logikal ke dalam model data global
(optional step)
Bertujuan untuk menggabungkan model data logikal lokal ke dalam satu
model data logikal global yang merepresentasikan semua pandangan
pengguna database.
2.7 Memeriksa pertumbuhan yang akan datang
Bertujuan untuk menentukan apakah ada kemungkinan perubahan yang
signifikan di masa mendatang dan untuk menilai apakah model data
logikal dapat mengakomodasi perubahan.
46
Gambar 2.6 Perancangan basis data logikal
(Sumber : Connoly dan Begg, 2010, p516)
2.1.19 Perancangan Basis Data Fisikal
Proses menghasilkan deskripsi dari implementasi database pada penyimpanan
skunder, menggambarkan hubungan dasar, file organisasi, dan indeks yang digunakan
untuk mencapai akses yang efisien terhadap data, dan setiap kendala integritas terkait
dan tindakan keamanan. Connolly & Begg (2010, p322)
Langkah dari metodologi perancangan basis data fisikal
adalah sebagai berikut :
Langkah 3 : Menerjemahkan model data logikal untuk sasaran DBMS
Ada tiga aktifitas dari langkah 3 ini, seperti :
• Merancang base relation
47
• Merancang representasi dari data turunan (derived data)
• Merancang general constraint
3.1 Merancang Base Relation
Bertujuan untuk memutuskan bagaimana merepresentasikan hubungan dasar
yang diidentifikasi pada model data logikal dalam sasaran DBMS.
48
Gambar 2.7 Contoh perancangan basis data fisikal base relation
(Sumber : Connoly dan Begg, 2010, p526)
49
3.2 Merancang representasi dari data turunan (derived data)
Bertujuan untuk memutuskan bagaimana merepresentasikan setiap derived data
yang diperoleh mewakili model data logikal dalam DBMS yang akan digunakan.
3.3 Merancang general constraint
Merancang constraint tergantung pada pilihan DBMS, beberapa sistem
menyediakan fasilitas lebih daripada yang lain dalam mendefinisikan general
constraint.
Langkah 4 : Merancang file organizations dan indexes
Aktifitas yang ada pada langkah 4 adalah sebagai berikut :
• Analisis transaksi
• Memilih file organizations
• Memilih indexes
• Memperhitungkan kebutuhan disk space
4.1 Analisis transaksi
Bertujuan untuk memahami fungsi dari transaksi yang akan dijalankan di
database dan untuk menganalisis transaksi penting.
4.2 Memilih file organizations
Bertujuan untuk menentukan file organization yang efisien untuk setiap base
relation.
4.3 Memilih indexes
Bertujuan untuk menentukan apakah penambahan indeks akan meningkatkan
performa sistem.
4.4 Memperhitungkan kebutuhan disk space
Bertujuan untuk menentukan jumlah dari disk space yang dibutuhkan untuk
mendukung implementasi database dalam secondary storage.
50
Langkah 5 : Merancang user views
Bertujuan untuk merancang user views yang telah diidentifikasi selama
pengumpulan kebutuhan dan dalam tahap analisis dari database system
development lifecycle.
Langkah 6 : Merancang security mechanisms
Bertujuan
merancang
mekanisme
keamanan
untuk
database
yang
dispesifikasikan oleh pengguna selama tahap requirement and collection dari
database system development lifecycle.
2.2 Teori Khusus
Teori Khusus adalah teori yang menyangkut pembahasan dari skripsi ini dimana
teori khusus ini dipakai dalam pembuatan skripsi ini sebagai acuan pembuatan skripsi.
2.2.1 Rumah Sakit
Menurut Undang-Undang Republik Indonesia No.44 Tahun.2009 Pasal.1
Tentang Rumah Sakit, Rumah Sakit adalah institusi pelayanan kesehatan yang
menyelenggarakan pelayanan kesehatan perorangan secara paripurna yang menyediakan
pelayanan rawat inap, rawat jalan dan gawat darurat.
Undang-undang tersebut juga menjelaskan mengenai pembagian rumah sakit
berdasarkan jenis pelayanan yang diberikan, rumah sakit dikategorikan menjadi, rumah
sakit umum dan rumah sakit khusus. rumah sakit umum sebagaimana dimaksud pada
ayat (1) memberikan pelayanan kesehatan pada semua bidang dan jenis penyakit.
Rumah Sakit Khusus sebagaimana dimaksud pada ayat (1) memberikan pelayanan
utama pada satu bidang atau satu jenis penyakit tertentu berdasarkan disiplin ilmu,
golongan umur, organ, jenis penyakit atau kekhususan lainnya. Rumah sakit sebagai
sarana pelayanan kesehatan, yang berjenjang dan fungsi rujukan, rumah sakit umum dan
rumah sakit khusus diklasifikasikan berdasarkan fasilitas dan kemampuan pelayanan
rumah sakit, klasifikasi rumah sakit umum beserta jumlah minimal tempat tidur yang
tersedia adalah:
51
o Rumah Sakit umum kelas A - tempat tidur minimal 400buah ,
o Rumah Sakit umum kelas B - tempat tidur minimal 200buah,
o Rumah Sakit umum kelas C - tempat tidur minimal 100buah,
o Rumah Sakit umum kelas D - tempat tidur minimal 50 buah.
Dalam perancangan sebuah rumah sakit, aspek lokasi menjadi pertimbangan, selain
fungsinya sebagai sarana pelayanan kesehatan, pemilihan lokasi sarana pelayanan
kesehatan menurut pedoman 12 Penentuan Standart Pelayanan Minimal Bidang
Penataan Ruang, Perumahan dan Pemukiman dan Pekerjaan Umum (Keputusan Mentri
Pemukiman dan Prasarana Wilayah No. 534/KPTS/M/2001), yaitu rumah sakit
sebaiknya berada di pusat lingkungan/ kecamatan, bersih, mudah dicapai, tenang, jauh
dari sumber penyakit, sumber bau/sampah, dan pencemaran lainnya. Pertimbangan
lokasi sebuah rumah sakit selain jauh dari sumber pencemaran seperti pabrik. Rumah
sakit juga diharapkan tidak menimbulkan pencemaran bagi lingkungan sekitarnya.
Menurut KEPMENKES RI No.1204/MENKES/SK/X/2004 persyaratan kesehatan
lingkungan rumah sakit tentang pengelolaan limbah
(Hal.17) Limbah rumah sakit adalah semua limbah yang dihasilkan dari
kegiatan rumah sakit dalam bentuk padat, cair, dan gas. Minimasi limbah adalah upaya
yang dilakukan rumah sakit untuk mengurangi jumlah limbah yang dihasilkan dengan
cara mengurangi bahan (reduce), menggunakan kembali limbah (reuse) dan daur ulang
limbah (recycle).
2.2.2 Pasien
Menurut surat Keputusan Menteri Kesehatan RI no.269/MENKES/PER/III/2008
tentang rekam medis, pasien adalah setiap orang yang melakukan konsultasi masalah
kesehatannya untuk memperoleh pelayanan kesehatan yang diperlukan baik secara
langsung mapupun tidak langsung kepada dokter atau dokter gigi.
2.2.3 Rekam Medis
Rekam medis adalah keterangan baik yang tertulis maupun yang terekam tentang
identitas, anamnesa, pemeriksaan fisik, laboratorium, diagnosa segala pelayanan dan
52
tindakan
medik yang diberikan kepada pasien dan pengobatan baik yang rawat
inap,rawat jalan, maupun yang mendapatkan maupun pelayanan gawat darurat
(Sabarguna,2005). Menurut Undang-Undang nomor 29 tahun 2004 disebutkan rekam
medis adalah berkas yang berisikan catatan dan dokumen tentang identitas pasien,
pemeriksaan, pengobatan, tindakan dan pelayanan lain yang diberikan kepada pasien.
Dalam Undang-Undang No.29 tahun 2004 disebutkan secara rinci tentang rekam medis
sebagai berikut:
1. Setiap dokter atau dokter gigi dalam menjalankan praktek kedokteran wajib
membuat rekam medis
2. Rekam medis harus segera dilengkapi setelah pasien menerima pelayanan
kesehatan
3. Setiap catatan rekam medis harus dibubuhi nama, waktu dan tanda tangan
petugas yang memberikan pelayana atau tindakan.
4. Dokumen rekam medis merupakan milik dokter, dokter gigi atau sarana
pelayanan kesehatan, sedangkan isi rekam medis merupakan milik pasien
5. Rekam medis harus disimpan dan dijaga kerahasiaannya oleh dokter atau
dokter gigi dan pimpinan sarana pelayanan kesehatan.
6. Rekam medis adalah berkas yang berisikan catatan dan dokumen tentang
identitas pasien, pemeriksaan, pengobatan, tindakan dan pelayanan lain yang
telah diberikan kepada pasien.
7. Dalam hal terjadi kesalahan dalam melakukan pencatatan pada rekam medis,
berkas dan catatan tidak boleh dihilangkan atau dihapus dengan cara apapun.
Perubahan catatan atau kesalahan dalam rekam medis hanya dapat dilakukan
denan pencoretan dan dibubuhi paraf petugas yang bersangkutan.
2.2.4 Rekam Medis Elektronik (Electronic Medical Record/EMR)
Rekam Medis Elektronik adalah gudang penyimpanan informasi secara elektronik
mengenai status kesehatan dan layanan kesehatan yang diperoleh pasien sepanjang
hidupnya, tersimpan sedemikian hingga dapat melayani berbagai pengguna rekam yang
sah. (Harlan, 2007). Dengan Rekam Medis Elektronik kewajiban dokter untuk
membubuhkan tanda tangan pada setiap pemeriksaan atau diagnosa yang ditegakkan
53
dapat digantikan dengan menggunakan nomor identitas pribadi (Personal Identification
Number/PIN). (UU No.29 tahun 2004).
Beberapa kelebihan Rekam Medis Elektronik dibandingkan dengan Rekam
Medis kertas (paper base) antara lain:
1. Pencatatan data Rekam Medis Elektronik lebih efektif dan efisien
2. Dapat dijadikan basis data untuk kepentingan lain contohnya untuk sistem keuangan,
laporan-laporan RS dan penelitian klinik
3. Kerahasiaan dan keamanan akan lebih terjaga
Sedangkan beberapa kelemahan penggunaan Rekam Medis Elektronik yaitu:
1. Membutuhkan investasi awal yang lebih besar daripada rekam medis kertas
2. Memerlukan waktu yang lama untuk operasionalisasi sistem bagi key person dokter
3. Rekam Medis Elektronik memerlukan terlalu banyak langkah untuk menyelesaikan
tugas sederhana
4. Resiko kegagalan sistem komputer.
2.2.5 LAN (Local Area Network)
Local Area Network dapat dibedakan dari jenis jaringan lainnya berdasarkan tiga
karakteristik: ukuran, teknologi transmisi dan topologinya. Jaringan LAN relatif kecil
yang umumnya dibatasi oleh area lingkungan, seperti sebuah perkantoran, sekolah.
Biasanya jarak antar node tidak lebih dari 200 meter (Syafrizal,2005). Beberapa model
konfigurasi LAN biasanya berupa satu komputer yang di jadikan
file server, yang digunakan untuk menyimpan perangkat lunak (software yang mengatur
aktifitas jaringan), ataupun sebagai perangkat lunak yang dapat digunakan oleh
komputer-komputer yang terhubung ke dalam jaringan lokal. Kebanyakan LAN
menggunakan media kabel untuk menghubungkan antara satu komputer dengan
komputer lainnya. LAN merupakan jaringan komunikasi yang terbatas pada daerah
kecil, misalkan satu gedung atau sekelompok kecil bangunan (Irawan,2005).
54