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.
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.
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
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.
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.
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).
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
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.
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.
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.
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.
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.
• 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.
• 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 :
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.
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.
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.
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.
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).
Physical Existence Pasien Karyawan Dokter 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.
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.
• 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).
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 diberikan berdasarkan ketergantungan fungsi (Functional depedencies) dan primary key untuk meminimalkan perulangan dari
property/atribut dan meminimalkan update anomalies. Elmasri and
Navathe(2004, p313).
Tabel 2.2 StaffBranch Relation (Sumber : Connoly and Begg,2010,p419)
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.
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,sName
BranchNo
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, bAddressBranchNo
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)
Client No
cName Property No
pAddress RentStart RentFinish Rent Owne rNo oName CR76 John Kay PG4 PG16 6 Lawrence St,Glasglow 5 Novar Dr,Glasglo w 1-Jul-07 1-Sep-08 31-Aug-08 1-Sep-09 350 450 CO40 CO93 Tina Murphy Tony Shaw CR56 Aline Stewart PG4 PG36 PG16 6 Lawrence St,Glasglow 2 Manor Rd, Glasglow 5 Novar Dr, Glasglow 1-Sep-06 10-June-07 1-Nov-09 10-Jun-07 1-Dec-08 10-Aug-10 350 375 450 CO40 CO93 CO93 Tina Murphy Tony Shaw Tony Shaw
Tabel 2.3 ClientRental Unnormalized Table (Sumber : Connolly & Begg,2010,p432)
Berdasarkan gambar diatas struktur dari repeating group adalah sebagai berikut : RepeatingGroup = (PropertyNo, pAddress, RentStart, RentFinish, Rent, OwnerNo, oName)
2.1.13.2. 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)
ClientNo CName CR76 CR56 John Kay Aline Stewart Tabel 2.4 1NF Client
(Sumber : Connolly & Begg,2010,p433)
Client No
cName Property No
pAddress RentStart RentFinish Rent Owne rNo oName CR76 John Kay PG4 PG16 6 Lawrence St,Glasglow 5 Novar Dr,Glasglo w 1-Jul-07 1-Sep-08 31-Aug-08 1-Sep-09 350 450 CO40 CO93 Tina Murphy Tony Shaw CR56 Aline Stewart PG4 PG36 PG16 6 Lawrence St,Glasglow 2 Manor Rd, Glasglow 5 Novar Dr,Glasglo w 1-Sep-06 10-June-07 1-Nov-09 10-Jun-07 1-Dec-08 10-Aug-10 350 375 450 CO40 CO93 CO93 Tina Murphy Tony Shaw Tony Shaw 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, RentFinish, Rent, OwnerNo, oName)
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 CR56 John Kay Aline Stewart Tabel 2.6 2NF Client
(Sumber : Connolly & Begg,2010,p435)
ClientNo PropertyNo RentStart RentFinish CR76 CR76 CR56 CR56 CR56 PG4 PG16 PG4 PG36 PG16 1-Jul-07 1-Sep-08 1-Sep-06 10-June-07 1-Nov-09 31-Aug-08 1-Sep-09 10-Jun-07 1-Dec-08 10-Aug-10 Tabel 2.7 2NF Rental
PropertyNo pAddress Rent OwnerNo oName PG4 PG16 PG36 6 Lawrence St,Glasglow 5 Novar Dr,Glasglow 2 Manor Rd, Glasglow 350 450 375 CO40 CO93 CO93 Tina Murphy Tony Shaw 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.
PropertyNo pAddres Rent OwnerNo PG4 PG16 PG36 6 Lawrence St,Glasglow 5 Novar Dr,Glasglow 2 Manor Rd, Glasglow 350 450 375 CO40 CO93 CO93 Tabel 2.9 3NF PropertyForRent (Sumber : Connolly & Begg,2010,p436)
OwnerNo Oname CO40 CO93 CO93 Tina Murphy Tony Shaw 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).
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.1Mengidentifikasi 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.2Mengidentifikasi 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.3Mengidentifikasi 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, single-valued/multi-valued atau derived.
1.4Menentukan domain atribut
Bertujuan menentukan domain untuk atribut dalam model data konseptual. Domain atribut adalah himpunan nilai yang diijinkan untuk satu atau lebih atribut.
1.5Menentukan 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
1.6 Mempertimbangkan penggunaan enhanced modelling concepts (optional step)
Bertujuan untuk mempertimbangkan penggunaan dari enhanced modelling concepts, seperti specialization/generalization, aggregation dan composition.
1.7Memeriksa model terhadap redundancy
Bertujuan untuk mengecek adanya redundancy pada sebuah model.
1.8Memvalidasikan 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.9Meninjau 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.
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.
Langkah 2 : Membangun model data logikal
2.1 Menurunkan hubungan untuk model data logikal
Bertujuan membuat hubungan model data logikal untuk merepresentasikan entitas, hubungan, dan atribut yang 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
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.
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 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.
Gambar 2.7 Contoh perancangan basis data fisikal base relation (Sumber : Connoly dan Begg, 2010, p526)
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
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:
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
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
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).
