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
