BAB 2 LANDASAN TEORI
2.1 Pendekatan Basis Data 2.1.1
Pengertian Data Menurut Indrajani (2011, p.2), data adalah fakta atau observasi mentah
yang biasanya mengenai fenomena fisik atau transaksi bisnis 2.1.2
Pengertian Database Menurut Connolly dan Begg (2010, p.65), database merupakan suatu
kumpulan data yang terhubung secara logis bserta deskripsinya, dirancang untuk memenuhi kebutuhan informasi di dalam sebuah organisasi. Menurut Anabel(2003, p.37) database adalah bagian fundamental dari sistem informasi, yang dianggap sebagai sudut pandang untuk operasi yang baik dari organisasi modern, selain adaptasi yang cepat untuk suatu perubahan dari media lingkungan dan proses bisnis seperti produksi jasa, logistic, pengambilan strategi dan keputusan. Jadi database dapat dikatakan merupakan kumpulan data yang saling berhubungan dan disimpan untuk memenuhi kebutuhan informasi suatu organisasi yang tersusun dengan rapih dan diterapkan secara sitematis.
6
7
2.1.3 Database Management System (DBMS) 2.1.3.1 Pengertian Database Management System (DBMS) Menurut Connolly dan Begg (2010, p66) Database Management system (DBMS) merupakan sistem software yang memungkinkan user untuk mendefinisikan, membuat, merawat, dan mengontrol akses data ke dalam suatu database. Menurut Joseph (2007, p142), DBMS adalah sebuah komponen komputasi modern kritis, dan hasil dari berbagai dekade penelitian dan pembangunan di kedua akademis dan industri. Berdasarkan sejarahnya DBMS berada di antara multi-user sistem awal server untuk dikembangkan, dan dengan demikian banyak teknik sistem desain untuk skalabilitas dan keandalan yang sekarang ini digunakan dalam konteks lain. Menurut Yvette (2012, p72), DBMS adalah paket perangkat lunak dengan
program
komputer
yang
mengendaikan
pembuatan,
pemeliharaan, dan penggunaan database. memungkinkan sebuah organisasi dengan mudah mengembangkan database untuk berbagai aplikasi yang dilakukan oleh administrator database dan spesialis database lainnya.
8
Beberapa fasilitas yang disediakan dalam DBMS, yaitu : •
DBMS menmungkinkan user untuk menentukan suatu database, biasanya menggunakan Data Definition Language (DDL). DDL memungkinkan user untuk menspesifikasikan tipe dan struktur data serta batasan-batasan data yang akan disimpan dalam database.
•
DBMS memungkinkan user untuk melakukan insert, update, delete dan retrieve terhadap data-data yang ada di dalam database melalui Data Manipulation Language (DML). DML menyediakan suatu fasilitas umum bagi data yang disebut query language.
•
DBMS
menyediakan
kontrol
terhadap
pengaksesan
suatu
database, misalnya sebuah sistem keamanan mencegah user yang tidak berkepentingan dapat mengakses database. 2.1.3.2 Komponen Lingkungan Database Management System Menurut Thomas Connolly dan Begg (2010, p.68), komponen DBMS terdapat 5 komponen penting, yaitu : 1. Hardware Dibutuhkan untuk menjalankan DBMS dan aplikasiaplikasinya. Hardware meliputi dari PC, mainframe, dan jaringan komputer.
9
2. Software Meliputi aplikasi, software DBMS, sistem operasi dan juga sistem jaringan jika dalam penggunaannya menggunakan jaringan. 3. Data Merupakan
komponen
yang
terpenting
dan
juga
merupakan penghubung antara komponen mesin (Hardware dan Software) dan komponen human (Procedures dan people) 4. Prosedur Merupakan
instruksi
dan
aturan
yang
mengatur
perancangan dan penggunaan database. 5. People Komponen ini meliputi database administrator, database designers, application developers, dan end users. 2.1.3.3 Keuntungan dan Kerugian Database Management System Menurut Connolly dan Begg (2010, p.77) keuntungan dari DBMS yaitu : 1. Mengendalikan redudansi data
10
2. Konsistensi data 3. Mendapatkan informasi lebih lanjut dari data yang sama 4. Penggunaan data bersama 5. Meningkatkan integritas data 6. Meningkatkan keamanan 7. Standarisasi 8. Skala ekonomi kecil 9. Menyeimbangkan kebutuhan user 10. Meningkatkan tingkat akses dan respon data 11. Meningkatkan produktifitas 12. Meningkatkan pemeliharaan melalui independensi data 13. Meningkatkan konkurensi 14. Meningkatkan fasilitas backup dan recovery dara Menurut Connolly dan Begg (2010, p.80) kerugian dari DBMS yaitu : 1. Kompleksitas 2. Ukuran
11
3. Biaya DBMS 4. Biaya hardware tambahan 5. Biaya konversi 6. Performance 7. Dampak kegagalan yang besar 2.1.4 Structure Query Language (SQL) Menurut Connolly dan Begg (2010, p.183) SQL adalah sebuah bahasa yang mucul akibat dari pengembangan model relational. Selama beberapa tahun terakhir SQL telah menjadi bahasa standar relasi database. Sudah lebih dari ratusan DBMS sekarang mendukung aplikasi SQL. 2.1.4.1 Data Definition Language (DDL) Menurut Connolly dan Begg (2010, p.92) DDL adalah sebuah bahasa yang memungkinkan sebuah aplikasi database atau user untuk menjelaskan dan memberi nama terhadap sebuah entitas, atribut, dan hubungan yang diperlukan untuk sebuah aplikasi. 2.1.4.2 Data Manipulation Language (DML) Menurut Connolly dan Begg (2010, p.92) DML adalah sebuah bahasa yang menyediakan seperangkat operasi untuk mendukung operasi manipulasi data dasar yang ada di dalam database.
12
2.1.5 Siklus Pengembangan Sistem Basis Data Menurut Thomas Connolly dan Begg (2010, p.314), waktu database dianalisis dan dirancang berdasarkan siklus hidup seperti tergambar pada gambar berikut :
Gambar 2.1 Database System Development Life Cycle Sumber (Connolly dan Begg, 2010, p. 314)
13
a. Database planning Dalam tahap ini dilakukan perencanaan bagaimana tahapan-tahapan perancangan berikutnya dapat direalisasikan secara efektif dan efisien. Perencanaan database ini harus terintegrasi dengan strategi sistem informasi pada sebuah organisasi. Berikut ini adalah 3 hal utama dalam proses memformulasi sebuah strategi sistem informasi : •
Mengidentifikasi rencana dan tujuan perusahaan kemudian menentukan sistem informasi yang dibutuhkan
•
Mengevaluasi sistem informasi yang sedang digunakan, kemudian menentukan kelebihan dan kekurangan dari sistem informasi tersebut
•
Melihat peluang sistem apa yang mampu mendapatkan keuntungan yang kompetitif
b. System definition Tahap ini menjabarkan spesifikasi jangkauan dan batasan dari aplikasi basis data, penggunaannya dan lingkungan tempat aplikasi diimplementasikan. Sebelum melakukan desain terhadap sistem database, pertama – tama kita harus mengidentifikasi batas – batas dari sistem yang kita sedang investigasi dan bagaimana itu dapat berinteraksi dengan bagian lain dari sistem informasi organisasi tersebut. Sangat penting untuk kita untuk tidak hanya
14
melibatkan user dan aplikasi yang sudah ada, tapi juga user dan aplikasi di masa yang akan dating. c. Requirement Collection dan Analysis Pada tahap ini dilakukan proses pengumpulan dan analisis data organisasi yang dapat membantu dalam sistem database dan menggunakan informasi tersebut untuk mengidentifikasi kebutuhan untuk sistem baru yang akan dibuat. Untuk mengumpulkan informasi, terdapat berbagai macam teknik yang disebut fact-finding techniques. Menurut Connolly dan Begg(2010, p.344) berikut ini adalah contoh factfinding techniques : •
Pemeriksaan dokumen Mengumpulkan informasi dengan memeriksa dokumen – dokumen yang memiliki informasi yang mendukung dalam proses pembuatan sistem database.
•
Interview Merupakan
teknik
yang
paling
umum
digunakan
untuk
mengumpulkan data. Teknik ini dijalankan dengan cara bertatap muka dengan orang – orang yang memliki interaksi langsung
15
terhadap sistem dan mencari tahu fakta – fakta yang berguna, mengidentifikasi kebutuhan, dan mengumpulkan ide dan opini. •
Observasi Observasi merupakan teknik fact-finding paling efektif untuk mengerti sebuah sistem. Teknik ini memungkinkan untuk kita untuk melihat secara langsung aktifitas sebuah sistem dan mempelajarinya.
•
Penelitian Merupakan teknik yg cukup berguna untuk meneliti sebuah aplikasi atau permasalahan yang serupa. Pertukaran jurnal, referensi buku, dan internet adalah sumber informasi yang baik. Mereka dapat memberikan informasi yang berguna tentang bagaimana cara orang lain menyelesaikan sebuah permasalahan yang sama.
•
Kuesioner Kuesioner merupakan dokumen dengan tujuan khusus yang digunakan untuk mendapatkan fakta dari orang – orang dengan jumlah yang cukup banyak. Dengan banyaknya informasi yang didapat, maka peneliti akan membuat sebuah kesimpulan secara umum tentang apa yang dihasilkan dari kuesioner tersebut.
16
d. Database design Tahap ini menjelaskan tentang proses pembuatan desain yang akan mendukung misi dan tujuan sebuah organisasi untuk sistem database yang diperlukan Pada tahap ini dilakukan perancangan database secara konseptual, logical dan fisikal. e. DBMS Selection (optional) Pada tahap ini dilakukan pemilihan DBMS yang paling cocok dipilih dengan aplikasi database. Tahap ini hanya merupakan tahap opsional. Apabila tidak terdapat DBMS yang cocok, maka setelah tahap perancangan konseptal langsung menuju perancangan logikal (lihat gambar 2.2) Langkah – langkah dalam memilih DBMS : •
Mendefinisikan DBMS yang diinginkan
•
Memlih 2 atau 3 DBMS
•
Evaluasi DBMS yang sudah dipilih
•
Menetapkan DBMS yang sesuai.
17
f. Application Design Tahap ini dilakukan perancanan interface program aplikasi yang digunakan dan memproses basis data. Pada sebagian besar kasus, tidak memungkinkan untuk menyelesaikan desain aplikasi sampai desain database itu sendiri telah terbentuk. Database ada untuk mendukung sebuah aplikasi, jadi harus ada alur informasi antara desain aplikasi dan desain database. g. Prototyping (optional) Tahap ini ditujukan untuk membangun prototype dari aplikasi basis data. Hasil prototype ini memungkinkan perancang atau pengguna untuk menvisualisasikan dan mengevaluasi bagaimana bentuk fungsionalitas sistem akhir.
Tujuan
dari
Prototyping
ini
adalah
agar
pengguna
dapat
mengidentifikasi fitur – fitur yang terdapat dalam sistem dan memberikan saran untuk lebih meningkatkan kinerja sistem atau mungkin dengan menambah fitur baru ke dalam sistem database. h. Implementation Tahap ini merupakan tahap realisasi fisik dari database dan desain aplikasi. Tahap ini merupakan waktu dimana kita akan mengimplementasikan database dan program aplikasi. Pengimplementasian database dilakukan dengan menggunakan DDL dari DBMS yang telah dipilih atau dengan GUI yang menyediakan fungsi yang sama ketika menghilangkan DDl statement
18
level rendah. Program aplikasi diimplementasi menggunakan bahasa generasi ketiga atau keempat. i. Data Convertion and Loading Dalam tahap ini dilakukan perpindahan data ke database yang baru dan mengkonversi aplikasi agar dapat berjalan pada database yang baru. Tahap ini hanya dapat dilakukan ketika sistem database yang baru sudah menggantikan sistem database yang lama. j. Testing Aplikasi basis data yang telah selesai akan diuji coba dengan tujuan untuk mencari error pada aplikasi. Selain itu, dilakukan pula validasi aplikasi atas kebutuhan yang telah dispesifikasikan sebelumnya oleh pengguna. Setelah dilakukan uji coba terhadap sistem, maka akan dilakukan evaluasi terhadap sistem. Berikut ini adalah beberapa kriteria dalam melakukan evaluasi sistem : •
Kemudahan untuk dipelajari : berapa lama waktu yang dibutuhkan seseorang untuk menjadi produktif dalam memakai system
•
Performa : seberapa baik system dapat merespon kebutuhan user.
•
Kekuatan system : seberapa kuat system dalam mengatasi user error.
•
Kemudahan untuk pemulihan : seberapa baik system untuk melakukan pemulihan akibat dari user error.
19
•
Kemampuan beradaptasi : seberapa mampu system dapat beradaptasi dengan beberapa model kerja.
k. Operational Maintenance Pada tahap ini implementasi basis data dilakukan secara sepenuhnya. Sistem diawasi dan dipelihara secara berkelanjutan. Jika diperlukan, kebutuhan kebutuhan baru dimasukkan dalam aplikasi basis data melalui tahapan basis data terlebih dahulu. 2.1.6 Entity Relationship Modeling 2.1.6.1 Entity type Menurut Connolly dan Begg (2010, p.372), entity type yaitu sekumpulan
objek-objek
dengan
properti
yang
sama
yang
diindentifikasikan dengan keberadaan yang independen di perusahaan. Sebuah enitas mempunyai kumpulan properti dan nilai dari properti tersebut mengidentifikasikan entitas secara unik. Entity terdiri menjadi 2 macam, yaitu : • Strong Entity, yaitu tipe entitas yang keberadaannya tidak bergantung kepada keberadaan entitas yang lain • Weak Entity, yaitu tipe entitas yang keberadaannya bergantung kepada keberadaan entitas yang lain
20
2.1.6.2 Relationship type Menurut Connolly dan Begg (2010, p.374) relationship type adalah sebuah relasi yang bermakna antara beberapa jenis entitas. Setiap relationship type diberikan nama yang menjelaskan fungsinya. Adapula relationship occurrence, yaitu sebuah relasi unik yang diidentifikasi mencakup satu kejadian dari setiap entitas yang berpartisipasi. 2.1.6.2.1 Degree of Relationship Type Menurut Connolly dan Begg (2010, p.376) degree of relationship type adalah jumlah tipe entitas yang berpartisipasi di dalam sebuah relasi. Relasi dengan tingkat derajat dua disebut dengan binary. 2.1.6.2.2 Recursive Relationship Menurut Connolly dan Begg (2010, p.378) recursive relationship adalah sebuah tipe relasi dimana ada tipe entitas yang sama berpartisipasi lebih dari satu kali dengan peran yang berbeda. 2.1.6.3 Attributes Menurut Connolly dan Begg (2010, p.379) attributes adalah sebuah property khusus pada sebuah entitas atau pada tipe relasi. Sebagai contoh, tipe entitas staff bisa dijelaskan dengan atribut staffNo, name, position, dan salary.
21
Setiap atribut dihubungkan dengan seuah set nilai yang disebut domain. Jadi, Attribute domain adalah sebuah set nilai untuk satu atau lebih atribut. 2.1.6.3.1 Simple and Composite Attributes Menurut Connolly dan Begg (2010, p.379) simple attribute adalah sebuah atribut yang terdiri dari sebuah komponen dengan keberadaan yang independen. Menurut Connolly dan Begg (2010, p.380) composite attribute adalah sebuah atribut yang terdiri dari beberapa komponen, dimana setiap komponen tersebut memiliki keberadaan yang independen. 2.1.6.3.2 Single-valued and Multi-valued Attributes Menurut Connolly dan Begg (2010, p.380), singlevalued attributes adalah sebuah atribut yang memiliki sebuah nilai untuk setiap kejadian pada tipe entitas. Menurut Connolly dan Begg (2010, p.380), multivalued attributes adalah sebuah atribut yang memiliki banyak nilai untuk setiap kejadian pada tipe entitas. 2.1.6.3.3 Derived Attributes Menurut Connolly dan Begg (2010, p.380), derived attributes adalah sebuah atribut yang memilili nilai yang berasal
22
dari attribute lain yang berhubungan , dan tidak harus berasal dari satu tipe entitas yang sama. 2.1.6.4 Key Menurut Connolly dan Begg (2010, p.381) keys dibedakan menjadi 3, yaitu : •
Candidate Key Merupakan sebuah kumpulan minimal atribut yang secara unik mengidentifikasi setiap kejadian pada sebuah tipe entitas
•
Primary Key Merupakan candidate key yang dipilih untuk secara unik mengidentifikasi setiap kejadian pada sebuah tipe entitas
•
Composite Key Merupakan sebuah candidate key yang memiliki dua atau lebih atribut.
2.1.6.5 Structural Constraint Menurut Connolly dan Begg (2010, p.385) constraint mungkin diletakkan pada tipe entitas yang berpartisipasi pada sebuah relasi. Constraint harus mencerminkan batasan – batasan pada relasi seperti yang ada pada “dunia nyata”. Tipe utama sebuah constraint pada sebuah relasi disebut multiplicity.
23
Menurut Connolly dan Begg (2010, p.380) multiplicity adalah sebuah angka atau jarak kejadian yang terjadi pada tipe entitas yang mungkin terhubung kepada sebuah kejadian dari tipe entitas yang terasosiasi melalui relasi khusus. 2.1.7 Metodologi Perancangan Database Menurut Connolly dan Begg (2010, p. 466) metodologi perancangan adalah sebuah pendekatan terstruktur yang menggunakan prosedur, teknik, peralatan, dan dokumentasi untuk mendukung dan memfasilitasi proses perancangan Metodologi perancangan terdiri dari beberapa fase dimana setiap fase mengandung
beberapa
langkah
yang
akan
menuntun
desainer
dalam
menggunakan teknik yang sesuai pada setiap tahap dalam proyek. Metode perancangan juga membantu desainer untuk merencanakan, mengelola, mengatur, dan mengevaluasi pengembangan proyek database.
2.1.7.1 Perancangan Konseptual Database Tujuan dari perancangan konseptual database ini adalah untuk membangun sebuah model data konseptual dari kebutuhan data perusahaan. Fase perancangan konseptual database terdiri dari 9 tahap, yaitu :
24
•
Mengidentifikasi Tipe Entitas Tujuan dari langkah ini adalah untuk mengidentifikasi tipe entitas apa saja yang dibutuhkan. Langkah
pertama
dalam
membangun
data
model
konseptual adalah dengan menentukan dan mendefinisikan objek utama yang membuat user tertarik, yaitu tipe entitas. Sebuah metode untuk mengidentifikasi entitas adalah dengan memeriksa spesifikasi kebutuhan user. •
Mengidentifikasi Tipe Relationship. Tujuan dari langkah adalah untuk mengidentifikasi relasi penting yang ada diantara tipe – tipe antitas. Setelah
mengidentifikasi
entitas,
langkah
selanjutnya adalah mengidentifikasi semua relasi yang ada diantara entitas – entitas tersebut. Terdapat beberapa langkah dalam mengidentifikasi tipe relasi, yaitu : a. Menggunakan Entity-Relationship Diagram ERD digunakan untuk merepresentasikan entitas – entitas dan bagaimana mereka berelasi satu dengan yang lainnya dengan lebih mudah.
25
b. Menentukan multiplicity constraints dari tipe relasi Multiplicity constraints digunakan untuk mengecek dan mempertahankan kualitas data c. Mengecek fan dan chasm traps Setelah
mengidentifikasi
relasi
yang
diperlukan, kita harus mengecek setiap relasi yang ada pada ER model adalah representasi dunia nyata yang benar, dan tidak tercipta fan atau chasm traps. Fan traps adalah keadaan dimana model merepresentasikan sebuah relasi diantara beberapa tipe entitas, tapi jalur antara kejadian entitas tertentu bersifat ambigu. Chasm traps adalah keadaan dimana model mengusulkan
munculnya
relasi
diantara tipe
entitas, tapi tidak tersedia jalur diantara kejadian entitas tersebut. d. Laporan tipe relasi Pada
tahap
ini,
tipe
rtelasi
telah
teridentifikasi, lalu diberikan nama yang memiliki arti dan jelas untuk user. Jangan lupa untuk
26
mencatat
deskripsi
relasi
dan
multiplicity
constraints ke dalam kamus data. •
Mengidentifikasi dan menghubungkan atribut dengan entitas atau tipe relasi Tujuan
dari
langkah
ini
adalah
untuk
menghubungkan atribut dengan entitas atau tipe relasi yang sesuai. Pada langkah ini kita akan mengidentifikasi tipe fakta mengenai entitas dan relasi yang telah kita pilih untuk direpresentasi di dalam database. Cara yang digunakan
hampir
sama
dengan
cara
kita
dalam
mengidenfikasi entitas. •
Menentukan domain atribut Tujuan dari langkah ini adalah menentukan domain untuk semua atribut yang ada pada model. Menurut Connolly dan Begg (2010, p. 478) domain adalah tempat kumpulan nilai dimana satu atau lebih atribut mengambil nilai – nilai mereka.
•
Menentukan candidate, primary, dan alternate key
27
Tujuan
dari
langkah
ini
adalah
untuk
mengidentifikasi candidate key. Apabila terdapat lebih dari satu candidate key, maka harus dipilih salah satu untuk dijadikan primary key dan yang lainnya akan menjadi alternate key. Berikut ini adalah petunjuk dalam memilih primary key diantara beberapa candidate key : a. Candidate key dengan atribut yang minimal b. Candidate key yang paling sedikit kemungkinan untuk berubah nilainya c. Candidate key dengan karakter yang paling sedikit d. Candidate key dengan nilai maximum yang paling kecil e. Candidate key yang paling mudah digunakan dari sudut pandang user •
Mempertimbangkan
penggunaan
konsep
permodelan
tingkat tinggi (langkah opsional) Tujuan
dari
mempertimbangkan
langkah penggunaan
ini
adalah
konsep
untuk
permodelan
28
tingkat tinggi seperti spesialisasi/generalisasi, agregasi, dan komposisi. •
Memeriksa redundansi Tujuan dari langkah ini adalah untuk mengecek keberadaan redundansi apapun yang ada di dalam model. Terdapat tiga aktifitas pada tahap ini, yaitu : a. Memeriksa kembali one-to-one relationship b. Menghilangkan relasi yang redundan c. Mempertimbangkan dimensi waktu
•
Memvalidasi model data konseptual terhadap transaksi user Tujuan dari langkah ini adalah untuk memastikan bahwa
model
data
konseptual
dapat
mendukung
kebutuhan transaksi. Pada tahap ini kita sudah memiliki model data konseptual
yang
merepresentasikan
kebutuhan
data
perusahaan. Menggunakan model tersebut, kita melakukan operasi secara manual. Apabila kita dapat menyelesaikan semua transaksi, kita dapat memastikan bahwa model data konseptual tersebut dapat mendukung kebutuhan transaksi.
29
•
Meninjau kembali model data konseptual dengan user. Tujuan dari langkah ini adalah agar user dapat memastikan bahwa model tersebut adalah representasi nyata dari data yang dibutuhkan oleh perusahaan
2.1.7.2 Perancangan logical Database Tujuan dari tahap ini adalah untuk menterjemahkan model data
konseptual
menjadi
sebuah
model
data
logical,
lalu
memvalidasikan model tersebut untuk memastikan bahwa secara structural sudah tepat dan mampu mendukung kebutuhan transaksi Tahap perancangan model data logical memiliki 7 langkah, yaitu : •
Menurunkan relasi untuk model data logical Tujuan dari langkah ini adalah membuat relasi bagi model data logical untuk merepresentasikan antitas, relasi, dan atribut yang telah diidentifikasi.
•
Memvalidasikan relasi menggunakan normalisasi Tujuan
dari
langkah
ini
adalah
untuk
memvalidasikan relasi yang ada pada model data logical menggunakan normalisasi.
30
Pada langkah ini kita mengelompokkan atribut – atribut pada setiap relasi menggunakan aturan normalisasi. Tujuan dari normalisasi ini adalah untuk memastikan bahwa setiap relasi memiliki jumlah atribut minimal untuk mendukung kebutuhan data perusahaan. Relasi juga harus memiliki data redundan yang minimal untuk menghindari anomaly update. •
Memvalidasi relasi terhadap transaksi user Tujuan dari langkah ini adalah untuk memastikan bahwa relasi pada model data logical mendukung kebutuhan transaksi
•
Memeriksa integrity constraint Tujuan dari langkah ini adalah untuk memeriksa apakah terdapat integrity constraint pada model data logikal. Menurut Connolly dan Begg (2010, p.502), integrity constraint adalah pembatas yang kita ingin paksakan untuk melindungi database menjadi tidak lengkap, tidak akurat, atau tidak konsisten.
31
•
Meninjau kembali model data logical dengan user Tujuan dari langkah ini adalah meninjau kembali model data logical dengan user untuk memastikan bahwa model data tersebut telah menjadi representasi nyata dari kebutuhan data perusahaan. Pada tahap ini model data logical seharusnya telah selesai, dan telah didokumentasikan secara penuh. Tapi, untuk
lebih
memastikan
bahwa
ini
sudah
merepresentasikan kebutuhan perusahaan, maka user diminta untuk melakukan review. Apabila user tidak puas dengan model data tersebut, maka harus dilakukan pengulangan kembali dari langkah awal menggunakan metodelogi yang sama. •
Menggabungkan model data logikal ke dalam model global (langkah opsional) Tujuan
dari
langkah
ini
adalah
untuk
menggabungkan model data logical ke dalam sebuah model data logical global yang mewakili semua sudut pandang user terhadap database
32
Pada langkah ini terdapat beberapa aktifitas, yaitu : a. Menggabungkan model data logical ke dalam model data logical global b. Memvalidasi model data logical global c. Meninjau kembali model data logical global dengan user •
Memeriksa pertumbuhan di masa depan Tujuan dari langkah ini adalah untuk menentukan apakah ada kemungkinan perubahan yang signifikan dan untuk
menilai
apakah
model
data
logical
dapat
mengakomodasi perubahan tersebut. Dalam perancangan logikal database kita juga harus memikirkan apakah model data logikal mampu untuk
diperluas
untuk
mendukung
kemungkinan
perkembangan di masa depan 2.1.7.3 Perancangan fisikal database Menurut Connolly dan Begg (2010, p. 523), perancangan fisikal
database
adalah
proses
menghasilkan
deskripsi
dari
pengimplementasian database ke dalam tempat penyimpanan sekunder. Proses ini mendeskripsikan relasi dasar, organisasi file, dan
33
index yang digunakan untuk mencapai keefisienan dalam mengakses data, dan setiap integritas data terkait, dan langkah – langkah keamanan. Terdapat beberapa langkah pada tahap perancangan fisikal database, yaitu : •
Menterjemahkan data model logical ke DBMS yang dituju Tujuan dari langkah ini adalah untuk menghasilkan skema database relasional dari model data logical yang akan diimplementasikan ke dalam DBMS yang dituju Pada tahap ini terdapat 3 aktifitas, yaitu : a. Perancangan relasi dasar Tujuan dari langkah ini adalah untuk menentukan
bagaimana
merepresentasikan
relasi
cara dasar
yang
untuk telah
teridentifikasi yang ada pada model data logikal ke dalam DBMS yang dituju. b. Perancangan representasi dari derived data Tujuan dari langkah ini adalah untuk mengetahui bagaimana cara merepresentasikan
34
derived data apapun yang terdapat di model data logikal ke dalam DBMS yang dituju. c. Perancangan batasan umum Tujuan dari langkah ini adalah merancang batasasn umum untuk DBMS yang dituju •
Perancangan organisasi file dan index Tujuan dari langkah ini adalah menentukan organisasi file untuk menyimpan relasi dasar dan index yang dibutuhkan untuk mencapai performa yang dapat diterima, ini merupakan cara dimana relasi dan tuples juga akan disimpan di dalam tempat penyimpanan sekunder. Pada langkah ini, terdapat empat aktifitas, yaitu: a. Menganalisa transaksi Tujuan dari langkah ini adalah untuk mengenali fungsi dari transaksi yang berjalan pada database dan untuk menganalisa transaksi apa saja yang penting. Dalam menganalisa transaksi, kita harus melihat beberapa criteria, yaitu :
35
i.
Transaksi tersbut dapat sering berjalan dan akan memberikan dampak yang signifikan dalam performa
ii.
Transaksi tersebut sangat penting pada operasi bisnis
iii.
Ada waktu dimana akan terjadi permintaan yang tinggi dibuat dalam database
b. Memilih organisasi file Tujuan dari langkah ini adalah untuk menentukan organisasi file yang efisien untuk setiap relasi dasar c. Memilih index Tujuan dari langkah ini adalah untuk memastikan apakah dengan menambah index maka performa sistem juga akan meningkat. d. Memperkirakan ruang disk yang dibutuhkan Tujuan dari langkah ini adalah untuk memperkirakan jumlah ruang disk yang akan dibutuhkan oleh database.
36
•
Perancangan user views Tujuan dari langkah ini adalah untuk merancang user views yang telah diperoleh pada waktu pengumpulan kebutuhan dan tahap analisa pada siklus pengembagan sistem database
•
Perancangan mekanisme keamanan Tujuan dari langkah ini adalah untuk merancang mekanisme keamanan untuk database seperti yang diinginkan oleh user pada tahap pengumpulan kebutuhan pada siklus pengembangan system database.
2.1.8 Normalisasi Menurut Connolly dan Begg (2010,p. 416), normalisasi adalah sebuah teknik untuk menghasilkan sebuah set relasi dengan property yang diinginkan, dengan diberikan data perusahaan yang dibutuhkan. Tujuan dari normalisasi adalah untuk mendapatkan sebuah set relasi yang cocok dan dapat mendukung kebutuhan data perusahaan. Karakteristik dari set relasi yang cocok, yaitu : •
Jumlah atribut yang diperlukan dengan jumlah yang paling sedikit dalam mendukung kebutuhan data perusahaan
•
Atribut dengan relasi logical yang dekat ditemukan pada relasi yang sama
37
•
Redundansi yang minimal.
2.1.8.1 First Normal Form (1NF) Menurut Connolly dan Begg (2010, p.430), 1NF adalah sebuah relasi dimana pada persimpangan di setiap baris dan kolom mengandung satu dan hanya satu nilai. Pada awal tahap ini, table masih dalam bentuk yang tidak normal, yang sering disebut unnormalized table. Untuk merubah table yang tidak normal menjadi bentuk 1NF, kita mengidentifikasi dan menghilangkan kelompok yang mengalami
pengulangan yang
terdapat pada tabel. Terdapat
dua
macam
pendekatan
umum
dalam
menghilangkan kelompok yang berulang pada table yang tidak normal, yaitu : • Dengan memasukkan data yang sesuai ke dalam baris serta kolom kosong dengan data yang berulang • Dengan meletakkan data yang berulang, bersama dengan salinan dari key atribut yang asli, ke dalam relasi yang berbeda
38
Dengan kedua pendekatan tersebut, maka table yang dihasilkan akan menjadi 1NF. 2.1.8.2 Second Normal Form (2NF) Menurut Connolly dan Begg (2010,p.434), 2NF adalah keadaan dimana sebuah relasi telah pada bentuk 1NF, dan setiap atribut non-primary key fungsinya secara penuh bergantung kepada primary key. Pada proses normalisasi dari bentuk 1NF menuju 2NF, kita harus menghilangkan ketergantungan parsial. Apabila terdapat ketergantungan parsial, kita harus menghilangkan atribut yang memiliki ketergantungan parsial tersebut
dari relasi dengan
meletakkannya ke dalam relasi yang baru bersama dengan salinan dari factor penentunya. 2.1.8.3 Third Normal Form (3NF) Menurut Connolly dan Begg (2010,p.435), 3NF adalah keadaaan dimana relasi sudah pada bentuk 1NF dan 2NF dan dimana tidak ada atribut non-primary key yang memiliki ketergantungan transitif kepada primary key. Pada proses normalisasi dari bentuk 2NF menuju 3NF, kita harus menghilangkan ketergantungan transitif. Apabila terdapat ketergantungan transitif, kita hilangkan atribut yang memliki
39
ketergantungan tersebut dari relasi dengan cara meletakkan atribut tersebut ke dalam sebuah relasi baru bersama dengan salinan dari factor penentunya. 2.1.9
Waterfall model Model Proses merupakan gambaran dari suatu proses rekayasa perangkat
lunak yang terdiri dari aktifitas-aktifitas, tindakan-tindakan, tugas-tugas, tujuantujuan dan hasil kerja yang dibutuhkan untuk menghasilkan perangkat lunak yang berkualitas. Salah satu contoh model proses adalah The Waterfall Model Biasanya model proses ini disebut dengan classic life cycle atau biasa disebut waterfall model, the waterfall model memberikan suatu sistem yang sistematik, pendekatan secara terurut kepada pengembangan perangkat lunak yang ddimulai dari tingkat sistem dan berlanjut melalui communication, planning, modeling, construction, dan deployment.
Gambar 2.3 Classic Life Cycle atau Waterfall Model
Tahapan-tahapan dalam model classic life cycle atau waterfall model adalah sebagai berikut : a. Communication
40
Pada tahapan ini, software engineer harus mengerti dan menganalisa informasi-informasi yang ada dalam perangkat lunak, seperti fungsi yang dibutuhkan, performa, rancangan antarmuka, kemudian menyusun kebutuhankebutuhan (requirements) untuk seluruh elemen sistem b. Planning Pada tahapan ini mulai dilakukan perancangan perangkat lunak, perkiraan waktu yang diperlukan untuk membuat suatu aplikasi. c. Modeling Pada tahapan ini mulai dilakukan perancangan perangkat lunak, pada perancangan perangkat lunak ini, ada proses-proses yang difokuskan pada empat kategori yaitu: struktur data, arsitektur perangkat lunak, perwakilan antarmuka, dan detail prosedur (secara algoritma). d. Construction Desain yang sudah dibuat harus di artikan kedalam bahasa mesin. . Jika desain dibuat secara mendetil, akan membantu proses pengenerasian kode dapat dilakukan secara lebih mekanis. Setelah kode-kode digenerasikan, pengetesan kode dilakukan. Pada tahapan ini, pengetesan kode difokuskan pada bagian dalam perangkat lunak, memastikan bahwa perintah-perintah telah diuji coba, dan pada fungsi bagian luar seperti pengecekan error dan memastikan bahwa masukan-masukan akan menghasilkan hasil yang sesuai dengan hasil yang dibutuhkan. e. Deployment Perangkat lunak pasti akan mengalami perubahan setelah diberikan kepada pelanggan. Perubahan akan terjadi karena masalah-masalah yang telah ditemui
41
oleh pelanggan. Untuk itu, tahapan pemeliharaan dilakukan dengan tujuan melakukan penyesuaian dan perbaikan pada piranti lunak tersebut (Pressman, 2010). 2.2 Tools yang Digunakan Berikut ini adalah tools - tools yang digunakan penulis dalam penyusunan skripsi. 2.2.1 Diagramming Tools 2.2.1.1 Data Flow Diagram (DFD) Menurut Whitten(2004, p326) DFD adalah sebuah alat yang menggambarkan aliran data melalui sistem atau pengolahan yang dilakukan oleh sistem tersebut. Menurut pendekatan DeMarco atau Yourdon simbol-simbol yang digunakan dalam DFD antara lain: •
Process adalah aktifitas yang dilakukan sebagai respons terhadap aliran data masuk atau kondisi.
Gambar 2.3 Simbol Process Sumber: Whitten (2007, p.321)
42
•
Data Flow menunjukkan input data ke proses atau output data dari proses. Data Flow juga digunakan untuk menunjukkan pembuatan, pembacaan, penghapusan, atau pembaruan data dalam file atau database.
Gambar 2.4 Simbol Data Flow Sumber: Whitten (2007, p.325) •
External Agent mendefinisikan orang, unit organisasi, sistem, atau organisasi luar yang berinteraksi dengan sistem.
Gambar 2.5 Simbol External Agent Sumber: Whitten (2007, p.319) •
Data Store adalah penyimpanan data yang ditujukan untuk penggunaan selanjutnya.
Gambar 2.6 Simbol Data Store Sumber: Whitten (2007, p.320)
43
•
Diagram Konteks Merupakan suatu diagram yang Menggambarkan secara detil mengenai semua informasi yang diterima ataupun dihasilkan dari suatu aktivitas.
Gambar 2.7 Contoh diagram konteks •
Diagram Nol Diagram nol adalah diagram yang menggambarkan proses dari data flow diagram. Diagram nol memberikan pandangan secara
menyeluruh
mengenai
sistem.
Diagram
nol
menggambarkan proses yang ada, aliran data, dan eksternal entity.
44
Gambar 2.8 Contoh diagram nol 2.2.1.2 State Transition Diagram (STD) State Transition Diagram (STD) adalah sebuah modeling tool yang menggambarkan ketergantungan waktu pada sistem real time dan human interface pada sistem online. Notasi yang paling penting dari STD adalah: •
State, adalah kumpulan suatu keadaan atau atribut-atribut yang mencirikan benda atau orang pada keadaan, waktu, dan kondisi tertentu.
45
Gambar 2.9 Notasi State •
Transition State, menunjukkan perubahan state ditandakan dengan tanda panah.
Gambar 2.10 Notasi Transition State 2.2.1.3 Entity Relation Diagram (ERD) Diagram Hubungan Entitas atau entity relation diagram merupakan model data berupa notasi grafis dalam permodelan data konseptual yang menggambarkan hubungan antara penyimpan. Model data sendiri merupakan sekumpulan cara, peralatan untuk mendeskripsikan data-data yang hubungannya satu sama lain, semantiknya, serta batasan konsistensi. Model data terdiri dari model hubungan entitas dan model relasional. Diagram hubungan entitas ditemukan oleh Peter Chen dalam buku Entity Relational Model-Toward a Unified of Data. Chen mencoba merumuskan dasar-dasar model dan setelah itu dikembangkan dan dimodifikai oleh Chen dan banyak pakar lainnya. Pada saat itu diagram hubungan entitas dibuat sebagai
46
bagian dari perangkat lunak yang juga merupakan modifikasi khusus, karena tidak ada bentuk tunggal dan standar dari diagram hubungan entitas.
2.2.1.4 Flowchart
Flowchart atau diagram alur merupakan sebuah diagram dengan simbol-simbol grafis yang menyatakan aliran algoritma atau
proses
yang
menampilkan
langkah-langkah
yang
disimbolkan dalam bentuk kotak, beserta urutannya dengan menghubungkan masing masing langkah tersebut menggunakan tanda panah. Simbol-simbol flowchart yang umum digunakan, yaitu : 1. Proses Menyatakan
kegiatan
yang
akan
ditampilkan
dalam
flowchart.
Gambar 2.11 Simbol proses
2. Titik keputusan Proses dimana diperlukan adanya keputusan atau adanya kondisi tertentu. Di titik ini selalu ada dua keluaran untuk melanjutkan aliran kondisi yang berbeda.
47
Gambar 2.12 Simbol titik keputusan 3. Masukan / Keluaran data Masukan atau keluaran data digunakan untuk mewakili data masuk atau data keluar
Gambar 2.13 Simbol masukan / keluaran data 4. Terminasi Terminasi menunjukkan arah aliran proses atau algoritma.
Gambar 2.14 Simbol terminasi 5. Garis alir Garis alir menunjukkan arah aliran proses atau algoritma.
Gambar 2.15 Simbol garis alir 6. Kontrol / Inspeksi Kontrol atau inspeksi menunjukkan proses dimana ada inspeksi atau pengontrolan.
48
Gambar 2.16 Simbol kontrol / inspeksi
2.2.2 Software Tools
Berikut ini adalah software – software yang digunakan pada proses penelitian ini
2.2.2.1 Visual Basic
Menurut Dulaney (2000, p.xv) Visual basic merupakan pengimplementasian secara grafis dari bahasa yang mulai diperluas ke dunia Windows. Visual basic dirilis pada tahun 1991, dan menjadi sebuah sistem operasi berbasis event dimana respon dibangun di sekitar event tersebut.
2.2.2.2 Microsoft SQL Server
Microsoft SQL Server adalah sebuah sistem manajemen basis data relasional (RDBMS) produk Microsoft. Bahasa kueri utamanya adalah Transact-SQL yang merupakan implementasi dari SQL standar ANSI/ISO yang digunakan oleh Microsoft dan Sybase. Umumnya SQL Server digunakan di dunia bisnis yang memiliki basis data berskala kecil sampai dengan menengah,
49
tetapi kemudian berkembang dengan digunakannya SQL Server pada basis data besar.
Microsoft
SQL
Server
dan
Sybase/ASE
dapat
berkomunikasi lewat jaringan dengan menggunakan protokol TDS (Tabular Data Stream). Selain dari itu, Microsoft SQL Server juga mendukung ODBC (Open Database Connectivity), dan mempunyai driver JDBC untuk bahasa pemrograman Java. Fitur yang lain dari SQL Server ini adalah kemampuannya untuk membuat basis data mirroring dan clustering. Pada versi sebelumnya, MS SQL Server 2000 terserang oleh cacing komputer SQL Slammer yang mengakibatkan kelambatan akses Internet pada tanggal 25 Januari 2003.
2.3
IMK
Menurut Shneiderman (2005, p.74), ada delapan aturan emas yang digunakan dalam merancang interface, yaitu:
a.
Mencoba untuk konsisten Konsistensi merupakan aturan yang sering dilanggar karena memiliki banyak bentuk konsistensi, antara lain urutan aksi, istilah yang digunakan, warna, layout, kapitalisasi, huruf, dan lain-lain. Dengan tampilan yang konsisten maka user akan merasa tetap berada dalam aplikasi yang sama walaupun telah berpindah halaman.
b.
Memenuhi kebutuhan universal
50
Memahami kebutuhan user yang bermacam-macam dan membuat desain yang fleksibel yang mendukung perubahan dalam konten. Perbedaan Novice – Expert user, jarak umur, kecacatan fisik, serta
beragam
teknologi masing-masing merupakan syarat yang harus menjadi pertimbangan dalam desain. Dengan menambahkan beberapa fitur untuk novice user seperti shortcut, akan menambah kualitas dari sistem. c.
Memberikan umpan balik yang informatif Umpan balik dari sistem harus ada pada setiap aksi yang dilakukan user. Untuk aksi kecil yang sering dilakukan, tanggapan dapat dibuat dengan sederhana, sedangkan untuk aksi besar dan jarang dilakukan, respon hendaknya dibuat lebih tegas dan jelas agar user dapat mengerti dengan jelas.
d.
Dialog untuk keadaan akhir Urutan aksi hendaknya disusun menjadi kategori awal, tengah, dan akhir. Untuk memberikan kepuasan pencapaian, kelegaan, dan sebagai tanda untuk mempersiapkan diri memasuki kategori aksi selanjutnya, dibuatlah umpan balik yang informatif pada penyelesaian salah satu kategori aksi.
e.
Pencegah kesalahan Sedapat mungkin rancanglah sistem agar user tidak dapat membuat kesalahan yang fatal. Contohnya tidak memperbolehkan karakter alfabet pada kotak entry nomor. Interface harus mendeteksi kesalahan dan memberikan instruksi yang mudah dimengerti, membangun, dan jelas untuk memperbaikinya, jika user membuat kesalahan.
51
f.
Pembalikan aksi yang sederhana Dalam suatu aplikasi, pada setiap aksi harus terdapat pembalikan aksi. Fitur ini dapat memperkecil kesalahan, karena user tahu bahwa aksi bisa dibatalkan. Pembalikan bisa saja atas satu aksi seperti saat memasukkan data, atau serangkaian aksi seperti pada waktu pengisian nama dan alamat.
g.
Mendukung pusat kendali internal User yang udah terbiasa dengan suatu aplikasi, biasanya ingin memiliki kendali atas interface dan tanggapan pada aksinya. Aksi interface yang tidak seperti biasanya, rangkaian pemasukan data yang membosankan, tidak bisa atau sulit mendapatkan informasi yang diperlukan, dan tidak bisa menghasilkan aksi yang diinginkan dapat menimbulkan keresahan dan ketidakpuasan pada user.
h.
Mengurangi beban ingatan jangka pendek Dikarenakan oleh keterbatasan manusia dalam memproses informasi dalam
jangka
penggabungan
pendek,
dibutuhkan
halaman-halaman,
tampilan
pengurangan
yang
ringan,
frekuensi
window-
motion, pemberian waktu latihan yang cukup untuk kode-kode, hafalan, dan rangkaian atas aksi. Oleh karena itu, dalam setiap perancangan aplikasi dibutuhkan alur aplikasi yang mudah diingat oleh user.
52
5 faktor manusia terukur menurut Shneiderman (2005, p.16) yaitu : •
Waktu untuk belajar Berapa lama waktu yang dibutuhkan oleh user untuk mampu menggunakan aksi yang relevan dengan tugas yang ada.
•
Kecepatan performa Berapa lama waktu yang dibutuhkan untuk mengerjakan sekumpulan tugas
•
Tingkat kesalahan yang dibuat oleh user Berapa banyak dan kesalahan seperti apa yang dilakukan user pada waktu mengerjakan sebuah tugas. Walaupun waktu dalam mengatasi kesalahan tergabung dalam kecepatan performa, kemampuan untuk mengatasi kesalahan merupakan komponen yang penting dalam perancangan interface dan itu memerlukan pembelajaran yang lebih lanjut
•
Kemampuan daya ingat Bagaimana kemampuan user dalam mempertahankan pengetahuannya dalam jangka waktu tertentu.
•
Kepuasan subjektif Berapa tingkat kepuasan user terhadap berbagai aspek yang terdapat dalam sistem
53
2.4
Peracangan Transaksi Menurut Connolly dan Begg(2005, p300) transaksi adalah aksi atau sekumpulan
aksi yang dibawa oleh pengguna atau program aplikasi yang mengakses atau mengubah isi basisdata. Tujuan perancangan transaksi adalah untuk mendefinisikan dan mendokumentasikan karakteristik transaksi tingkat tinggi yang dibutuhkan pada basisdata, meliputi: •
Data yang digunakan oleh transaksi
•
Karakteristik fungsional transaksi
•
Output transaksi
•
Kepentingan pengguna
•
Tingkat penggunaan yang diharapkan Terdapat tiga jenis transaksi utama menurut Connolly dan Begg (2005,p301),
yaitu: •
Retrieval transactions Digunakan untuk mengambil data untuk menampilkannya dalam layar atau dalam laporan produksi. Sebagai contoh operasi untuk mencari dan menampilkan rincian aset.
•
Update transactions Digunakan untuk menyisipkan record – record baru, menghapus record – record lama, atau mengubah record – record yang ada dalam basisdata. Sebagai contoh operasi untuk menyisipkan rincian aset baru kedalam basisdata.
54
•
Mixed transactions Meliputi baik pengambilan dan pembaruan data. Sebagai contoh operasi untuk mencari dan menampilkan rincian asset dan kemudian mengubah nilai sewa setiap bulannya.
2.5
Pendekatan Obyek Studi 2.5.1
Pengertian Perpustakaan Menurut Bambang Supriyo Utomo perpustakaan adalah sebuah koleksi
buku dan majalah. Walaupun dapat
diartikan
sebagai
koleksi
pribadi
perseorangan, namun perpustakaan lebih umum dikenal sebagai sebuah koleksi besar yang dibiayai dan
dioperasikan oleh sebuah kota atau institusi, dan
dimanfaatkan oleh masyarakat yang rata-rata tidak mampu membeli sekian banyak buku atas biaya sendiri. 2.5.2
Sistem Perpustakaan Terintegrasi Menurut Emily Gallup Fagen (2005, p249), Sistem perpustakaan
terintegrasi adalah hasil alami dari sistem perpustakaan. Perpustakaan telah bekerja dengan alat apapun yang tersedia untuk membantu dalam tugas yang sangat banyak dalam mengelola perpustakaan. Sistem perpustakaan terintegrasi menggabungkan berbagai komponen dalam berbagai cara untuk memenuhi kebutuhan perpustakaan sekolah mulai dari kecil dan perpustakaan umum, akademisi besar dan perpustakaan pemerintah sampai konsorsium besar.
55
Setiap komponen dari sistem perpustakaan yang terintegrasi telah dikenal dengan istilah module, sistem perpustakaan yang terintegrasi mempunyai 2 atau 3 modul : •
Catalog : untuk penyimpanan dan mengatur bibliografi untuk setiap judul buku yang dimiliki oleh perpustakaan.
•
OPAC (Online Public Access Catalog): menyediakan akses public untuk mencari koleksi buku perpustakaan.
•
Circulation system : melacak peminjaman dan pengembalian setiap buku, menghasilkan pemberitahuan keterlambatan, menghitung denda atau biaya yang harus dibayar.
Kebanyakan modul catalog memberikan dukungan untuk karakter ASCII termasuk special karakter dan diacritics. Banyak katalog modul dan OPAC yang mensupport Unicode. 2.5.3
Istilah-istilah Perpustakaan Menurut Emily Gallup Fagen (2005, p.250) dalam istilah perpustakaan
ada yang dikenal dengan nama OPAC (Online Public Access Catalog) yang sudah biasa dikenal sebagai “public face” dari catalog perpustakaan yaitu sebuah aplikasi yang dirancang untuk menyediakan cara yang sangat mudah dan userfriendly untuk orang yang mencari bahan-bahan yang dibutuhkan atau informasi lainnya dari katalog perpustakaan.
56
Menurut Nurhaidi Magetsari tandon adalah bahan pustaka yang jarang digunakan, karena itu tidak disimpan di rak terbuka, tetapi dapat diminta jika diperlukan. Bahan pustaka diminta karena merupakan bacaan wajib, disimpan di tempat khusus dan hanya dapat dibaca di tempat atau dapat dipinjam untuk jangka waktu pendek, misalnya, satu malam. Menurut Nurhaidi Magetsari nomor induk buku adalah nomor yang diberikan kepada buku sesuai dengan nomor pendaftaran buku itu dalam buku induk. 2.5.4
Peran Perpustakaan Perpustakaan merupakan upaya untuk memelihara dan meningkattkan
efisiensi
dan
efektifitas
proses
belajar-mengajar.
Perpustakaan
yang
terorganisasi secara baik dan sisitematis, secara langsung atau pun tidak langsung dapat memberikan kemudahan bagi proses belajar mengajar di sekolah tempat perpustakaan tersebut berada. Hal ini, terkait dengan kemajuan bidang pendidikan dan dengan adanya perbaikan metode belajarmengajar yang dirasakan tidak bisa dipisahkan dari masalah penyediaan fasilitas dan sarana pendidikan. 2.5.5
Tujuan Perpustakaan Tujuan perpustakaan adalah untuk membantu masyarakat dalam segala
umur dengan memberikan kesempatan dengan dorongan melelui jasa pelayanan perpustakaan agar mereka:
57 •
Dapat mendidik dirinya sendiri secara berkesimbungan
•
Dapat
tanggap
dalam
kemajuan
pada berbagai
lapangan
ilmu
pengetahuan, kehidupan social, dan politik •
Dapat memelihara kemerdekaan berfikir yang konstruktif untuk menjadi anggota keluarga dan masyarakat yang lebih baik
•
Dapat mengembangkan kemampuan berfikir kreatif, membina rohani dan dapat menggunakan kemempuannya untuk dapat menghargai hasil seni dan budaya manusia
•
Dapat
meningkatkan
tarap
kehidupan
sehari-hari
dan
lapangan
pekerjaannya •
Dapat menjadi warga negara yang baik dan dapat berpartisipasi secara aktif dalam pembangunan nasional dan dalam membina saling pengertian antar bangsa
•
Dapat menggunakan waktu senggang dengan baik yang bermanfaat bagi kehidupan pribadi dan sosial
