BAB 2 TINJAUAN PUSTAKA
2.1 Pendekatan Teori Basis Data 2.1.1 Pengertian Basis Data Menurut Connolly dan Begg (2010:15), basis data adalah sekumpulan data yang terbagi dan terhubung secara logikal dan deskripsi dari data-data yang dirancang untuk memenuhi kebutuhan informasi suatu perusahaan. Data tersebut dapat digunakan secara bersamaan oleh banyak departemen dan pengguna. Data terintegrasi dengan jumlah minimum duplikasi. Database tidak lagi dimiliki oleh satu departemen tetapi merupakan sumber daya perusahaan bersama. Database menyimpan data operasional organisasi dan deskripsi dari data tersebut. Menurut Martyn Prigmore (2008:10), basis data adalah sesuatu yang tetap, menjelaskan diri sendiri, koleksi yang terstruktur dari hal-hal yang terkait dengan data. 2.1.1.1 Database Management System (DBMS) Menurut Connolly dan Begg (2010:66), DBMS adalah sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, dan mengatur akses ke basis data. DBMS adalah software yang berinteraksi dengan program aplikasi pengguna dan database. DBMS menyediakan fasilitas sebagai berikut: 1. Data Definition Language (DDL) DDL memungkinkan pengguna untuk menentukan tipe data dan struktur dan kendala pada data yang akan disimpan dalam database.
7
8 2. Data Manipulation Language (DML) DML memungkinkan pengguna untuk memasukkan, mengubah, menghapus, dan mengambil data dari database. Memiliki sebuah repositori pusat untuk semua data dan deskripsi data yang memungkinkan DML untuk memberikan fasilitas yang disebut query language. Query language yang paling umum adalah Structured Query Language (SQL) dan telah menjadi bahasa standar untuk DBMS relasional. 3. DBMS menyediakan akses terkontrol ke database. Sebagai contoh, dapat memberikan: •
Sistem keamanan, yang mencegah pengguna yang tidak sah mengakses database.
•
Sistem integritas, yang mempertahankan konsistensi data yang tersimpan.
•
Sistem kontrol untuk konkurensi, yang memungkinkan akses bersama database.
•
Sistem kontrol untuk pemulihan, yang mengembalikan database ke keadaan yang konsisten sebelumnya setelah kegagalan perangkat keras atau perangkat lunak.
•
Katalog yang dapat diakses pengguna, yang berisi deskripsi dari data dalam database.
Menurut Martyn Prigmore (2008:11), DBMS mengelola semua interaksi dengan basis data, meskipun terlibat dalam memanipulasi skema basis data atau instansi database. Pengguna tidak pernah mengakses data secara langsung dimana basis data tersebut disimpan, melainkan menggunakan DBMS untuk memanipulasi data. Faktanya, DBMS itu rumit dan sangat sulit digunakan. Aplikasi database biasanya menambahkan aplikasi perangkat lunak tambahan diantara pengguna dan DBMS.
9 Menurut Martyn Prigmore (2008:46) DBMS memiliki fungsi utama sebagai berikut: 1. Definisi
data
(DDL)
memungkinkan
pengguna
untuk
mendefinisikan dan merubah skema basis data. Selain itu, DDL juga memungkinkan pengguna untuk menyediakan akses dan pengelolaan untuk kamus data. 2.
Manipulasi data (DML) memungkinkan
pengguna untuk
memanipulasi instansi basis data. 3. Integritas, untuk meyakinkan perubahan instansi pada basis data, memenuhi semua constraint pada basis data. 4. Concurrency,
memungkinkan
banyak
penngguna
untuk
mengakses ke basis data. 5. Keamanan, menyediakan identifikasi, pembuktian keaslian dan otorisasi dari tindakan pengguna. 6. Komunikasi,
memungkinkan
client
dan
server
untuk
berkomunikasi.
2.1.1.1.1 Komponen dari Lingkungan DBMS Menurut (Connolly dan Begg, 2010:68-71), terdapat lima komponen utama dalam lingkungan DBMS yang terdiri dari: 1. Hardware DBMS dan aplikasi memerlukan hardware untuk dijalankan. Hardware dapat berupa personal computer, mainframe atau jaringan komputer. Hardware yang digunakan bergantung pada kebutuhan organisasi dan DBMS yang digunakan. 2. Software Komponen software terdiri dari perangkat lunak DBMS itu sendiri dan program aplikasi, bersama-sama dengan sistem operasi, termasuk
10 perangkat lunak jaringan jika DBMS akan digunakan melalui sebuah jaringan. 3. Data Data adalah sebuah komponen yang mungkin paling penting dalam lingkungan DBMS. Data bertindak sebagai jembatan antara komponen mesin dan komponen manusia. Data juga menggabungkan sistem katalog. 4. Procedures Prosedur mengacu pada instruksi dan aturan yang mengatur desain dan penggunaan database. Para pengguna sistem dan staf yang mengelola database memerlukan sebuah dokumentasi prosedur tentang cara menggunakan atau menjalankan sistem. Sebagai contoh, sebuah prosedur mungkin terdiri dari petunjuk tentang cara untuk log in, memulai dan menutup DBMS atau membuat back up data. 5. People Komponen terakhir adalah orang-orang yang terlibat dengan system dari DBMS itu sendiri. Misalnya DBA (Database Administrator) atau DA (Data Administrator).
2.1.1.1.2 Peran di Lingkungan Database Terdapat tempat jenis peran utama yang dapat di identifikasi dari orang yang berpartisipasi dalam lingkungan DBMS (Connolly dan Begg, 2010:71-73) : 1. Data and Database Administrators Data Administrator (DA) bertanggung jawab atas pengelolaan sumber daya data, yang termasuk perencanaan database, pengembangan dan pemeliharaan standar, kebijakan dan prosedur, dan desain database konseptual atau logikal. Data Administrator berkonsultasi dengan manajer senior dan memberi saran untuk
11 memastikan bahwa arah pengembangan database pada akhirnya akan mendukung tujuan perusahaan.
Database Administrator (DBA) bertanggung jawab untuk realisasi fisik database, termasuk desain fisik database dan implementasi, keamanan dan kontrol integritas, pemeliharaan sistem operasional, dan memastikan kinerja yang memuaskan dari sebuah aplikasi untuk pengguna. Peran DBA lebih berorientasi teknis daripada peran DA, karena membutuhkan pengetahuan yang terperinci dari target DBMS dan lingkungan dari sistem. 2. Database Designers Dalam proyek desain database yang cukup besar dapat didefinisikan dua jenis desainer, yaitu: logical database designer dan physical database designer. Tugas dari logical database designer
berkaitan
dengan
mengidentifikasi
atribut
data,
hubungan antara data, dan kendala pada data yang akan disimpan dalam database. Physical database designer memutuskan bagaimana desain database logis secara fisik diwujudkan. Misalnya memilih struktur penyimpanan yang spesifik dan metode akses untuk data untuk mencapai kinerja yang baik atau merancang langkah-langkah keamanan yang diperlukan pada data. 3. Application Developers Setelah database telah diimplementasikan, program aplikasi yang
menyediakan
fungsionalitas
yang
diperlukan
untuk
pengguna akhir harus diterapkan. Ini adalah tanggung jawab dari seorang application developers. 4. End-Users End-Users dapat disebut sebagai pengguna akhir. Para pengguna akhir adalah client untuk database, yang telah dirancang dan diimplementasikan, dan sedang dipertahankan untuk melayani kebutuhan informasi mereka. Terdapat dua
12 pengguna akhir yang dapat diklasifikasikan menurut cara mereka menggunakan system yaitu naïve users dan sophisticated users.
2.1.1.2 Database Application and System Menurut Connolly and Begg (2010:54), aplikasi database hanyalah sebuah program yang berinteraksi dengan database di beberapa titik dalam pelaksanaannya. Sedangkan database system adalah kumpulan program aplikasi yang berinteraksi dengan database bersama dengan DBMS dan database itu sendiri. 2.1.1.3 Structured Query Language Menurut Connolly dan Begg (2010:184), SQL adalah contoh dari sebuah bahasa yang transform-oriented atau bahasa yang dirancang untuk menggunakan relasi untuk mengubah suatu input menjadi sebuah output yang di perlukan. Sesuai dengan standar ISO, SQL memiliki dua komponen utama yaitu Data Definition Language (DDL) untuk mendefinisikan struktur database atau mengendalikan akses ke data dan Data Manipulation Language (DML). 2.1.1.3.1 Data Manipulation Language (DML) Menurut Connolly dan Begg (2010:188), Data Manipulation Language (DML) digunakan untuk mengambil dan memperbarui data. Terdapat empat statement umum yang digunakan dalam DML yaitu: 1. SELECT Statement SELECT digunakan untuk mengambil data dari sebuah database 2. INSERT Statement INSERT digunakan untuk memasukan data ke dalam database 3. UPDATE Statement UPDATE digunakan untuk merubah data dari sebuah database 4. DELETE
13 Statement DELETE digunakan untuk menghapus data dari sebuah database 2.1.1.3.2 Data Definition Language (DDL) Menurut Connolly dan Begg (2010:235), Data Definition Language (DDL)
digunakan
untuk
mendefinisikan
struktur
database
atau
mengendalikan akses ke data. SQL Data Definition Language (DDL) memungkinkan objek database seperti skema, domain, tabel, views, dan indeks dibuat dan dihapus (Connolly dan Begg (2010:236). Terdapat berapa statement umum yang digunakan dalam DDL yaitu: 1. CREATE SCHEMA 2. DROP SCHEMA 3. CREATE DOMAIN 4. ALTER DOMAIN 5. DROP DOMAIN 6. CREATE TABLE 7. ALTER TABLE 8. DROP TABLE 9. CREATE VIEW 10. DROP VIEW 11. CREATE INDEX 12. DROP INDEX
2.1.2 Database Lifecycles Database merupakan komponen yang sangat penting dari suatu sistem informasi dalam organisasi dengan skala yang cukup besar. Pengembangan sebuah sistem database harus berkaitan dengan siklus hidup dari sistem informasi tersebut. Tahapan pengembangan siklus hidup sistem database tidak harus berurutan, tetapi melibatkan beberapa jumlah pengulangan tahapan sebelumnya melalui sebuah feedback loop.
14 Dalam siklus hidup pengembangan sistem basisdata terdapat beberapa tahapan yang digambarkan sebagai berikut:
Gambar 2.1 Database Lifecycles Sumber: Connolly dan Begg, 2010:314
2.1.2.1 Database Planning Kegiatan manajemen yang memungkinkan tahapan siklus pengembangan sistem database untuk direalisasikan lebih efektif dan efisien. Perencanaan database harus terintegrasi dengan keseluruhan strategi sistem informasi dari sebuah organisasi. Ada tiga isu utama yang terlibat dalam merumuskan strategi sistem informasi, yaitu:
15 1. Identifikasi rencana dan tujuan perusahaan dengan penentuan kebutuhan sistem informasi berikutnya. 2. Evaluasi sistem informasi saat ini untuk menentukan kekuatan dan kelemahan yang ada. 3.
Penilaian
peluang
dari
teknologi
informasi
yang
mungkin
menghasilkan keuntungan kompetitif.
Perencanaan database juga harus mencakup pengembangan standar yang mengatur bagaimana data akan dikumpulkan, bagaimana format harus ditentukan, apa dokumentasi yang diperlukan dan dibutuhkan, dan bagaimana desain dan implementasi harus dilanjutkan. Metodologi yang digunakan untuk menyelesaikan masalah hal di atas menurut (Connolly dan Begg, 2010:315) adalah: 1. Menentukan mission statement untuk sistem database. Mission statement
mendefinisikan
tujuan
utama
dari
database
sistem. Sebuah mission statement membantu untuk memperjelas tujuan dari sistem database dan memberikan jalan yang lebih jelas terhadap penyusunan atau pembuatan sistem database yang diperlukan secara lebih efesien dan efektif.
2. Menentukan mission objectives untuk sistem database. Setiap mission objectives harus mengidentifikasi tugas tertentu yang harus dukung oleh sistem database. Pernyataan misi dan tujuan dapat disertai dengan beberapa informasi tambahan yang menentukan, secara umum, pekerjaan yang harus dilakukan, sumber daya yang dapat digunakan untuk melakukannya, dan uang untuk membayar untuk itu semua.
2.1.2.2 System Definition Menurut Connolly dan Begg (2010:316), System Definition menjelaskan ruang lingkup dan batas-batas dari aplikasi database dari
16 sudut pandang pengguna utama. Hal yang diperlukan di sini adalah mengindentifikasi
batasan-batasan
dalam
sistem
yang
sedang
diinvestigasi dan bagaimana batasan tersebut berinteraksi dengan bagian lain dari sistem informasi organisasi. Hal lain yang sangat penting adalah untuk mengidentifikasi batasan untuk pengguna dan area aplikasi di masa yang akan datang.
2.1.2.3 Requirement Collection and Analysis Menurut Connolly dan Begg (2010:316), requirement collection and analysis adalah proses mengumpulkan dan menganalisis informasi tentang bagian dari organisasi yang didukung oleh sistem database, dan menggunakan informasi ini untuk mengidentifikasi persyaratan untuk sistem baru. Tahap ini melibatkan pengumpulan dan analisis informasi mengenai bagian dari perusahaan yang akan disediakan oleh database. Ada banyak teknik untuk mengumpulkan informasi ini, yang disebut teknik pencarian fakta ( fact-finding technique). Ada lima teknik pencarian fakta umum digunakan menurut Connolly dan Begg (2010:344):
1. Memeriksa dokumentasi (examining documentation) Memeriksa dokumentasi dapat berguna untuk mendapatkan beberapa informasi yang berkaitan dengan kebutuhan yang muncul untuk database atau informasi pada bagian lain dari perusahaan yang terkait dengan masalah. Dengan memeriksa dokumen, formulir, laporan, dan file yang terkait dengan sistem saat ini diharapkan seorang database developer bisa mendapatkan beberapa pemahaman tentang sistem yang berlangsung dalam organisasi dengan cepat. 2. Wawancara (Interviewing) Wawancara adalah teknik yang paling umum digunakan, dan biasanya merupakan teknik yang paling berguna dalam pencarian fakta. Teknik ini dilakukan dengan cara mewawancarai individu yang
17 berkaitan dengan sistem untuk mengumpulkan informasi secara tatap muka. Terdapat beberapa tujuan dari penggunaan teknik wawancara yaitu untuk mengumpulkan fakta-fakta, memeriksa kebenaran fakta yang ada dan mengklarifikasinya, mengidentifikasikan kebutuhankebutuhan, dan mengumpulkan ide-ide atau pendapat.
3. Observasi (Observing the Enterprise in Operation) Observasi merupakan salah satu teknik pencarian fakta yang paling efektif untuk memahami sistem. Teknik ini dilakukan dengan cara berpartisipasi atau menonton seorang individu melakukan kegiatan untuk mempelajari sistem yang sedang berjalan. Sangat berguna ketika terdapat kompleksitas aspek-aspek tertentu dari sistem yang mencegah penjelasan yang jelas oleh pengguna akhir (end-user).
4. Penelitian (Research) Sebuah teknik pencarian fakta yang berguna untuk penelitian aplikasi dan masalahnya. Teknik ini bisa dilakukan dengan mencari referensi seperti jurnal, buku, dan melalui internet untuk menemukan bagaimana orang lain memecahkan masalah serupa atau mirip.
5. Kuesioner (Questionnaires) Kuesioner
adalah
dokumen
dengan
tujuan
khusus
yang
memungkinkan fakta dikumpulkan dari banyak orang dengan tetap menjaga kontrol atas tanggapan mereka. Teknik ini sangat berguna dalam berhadapan dengan banyak orang karena dapat mentabulasi fakta-fakta yang sama secara efisien. Ada dua jenis pertanyaan yang bisa diajukan dalam kuesioner, yaitu free-format dan fixed-format. Free-format menawarkan kebebasan responden yang lebih besar dalam memberikan jawaban sementara fixed-format memerlukan tanggapan dari responden. Responden harus memilih dari jawaban yang tersedia.
18
requirement collection and analysis adalah tahap awal untuk desain database. Jumlah data yang akan dikumpulkan tergantung pada sifat dari masalah dan kebijakan perusahaan. Kegiatan penting lainnya yang terkait dengan tahap ini adalah memutuskan dalam menangani situasi di mana terdapat lebih dari satu tampilan pengguna (user-view) untuk sistem database. Ada beberapa pendekatan utama untuk mengelola persyaratan sistem database dengan beberapa pandangan pengguna (user-view), yaitu: 1. Pendekatan terpusat (Centralized Approach) Persyaratan untuk setiap tampilan pengguna (user-view) digabung menjadi satu set persyaratan untuk sistem database baru. Sebuah model data yang mewakili semua pandangan pengguna (user-view) dibuat selama tahap desain database. 2. Pendekatan tampilan terintregrasi (view integration) Persyaratan untuk setiap tampilan pengguna (user-view) dibuat sebagai daftar terpisah. Model data yang mewakili setiap tampilan pengguna (user-view) dibuat dan digabung selama tahapan desain database.
2.1.2.4 Database Design Menurut Connolly dan Begg (2010:320), database design adalah proses menciptakan desain yang akan mendukung mission statement dan mission objectives perusahaan untuk sistem database yang diperlukan.
2.1.2.4.1 Approaches to Database Design Terdapat beberapa pendekatan dalam melakukan desain database menurut Connolly dan Begg (2010:321), yaitu: 1. Bottom-Up Pendekatan bottom-up dimulai pada tingkat dasar atribut (properties of entities and relationships) dengan melalui
19 proses analisa antar atribut-atribut yang saling berhubungan, mengelompokkan dalam suatu relasi yang mewakili tipe entitas dan relasi antar entitas. Pendekatan bottom-up cocok untuk merancang database yang sederhana dengan jumlah atribut yang relatif kecil
2. Top-Down Pendekatan ini sangat sesuai dalam merancang database yang bersifat
kompleks.
Pendekatan
ini
dimulai
dengan
pengembangan data model yang berisi beberapa entitas tingkat tinggi dan relasinya. Selanjutnya menerapkan top-down refinements untuk mengidentifikasi entitas dengan tingkat yang lebih rendah, relasi, dan atribut terkait. Pendekatan topdown dapat diilustrasikan dengan menggunakan konsep entityrelationship (ER) model, kemudian mengidentifikasikan entitas, dan relasi antar entitas dalam suatu organisasi. 3. Inside-Out Pendekatan ini berkaitan dengan pendekatan bottom-up. Tetapi
terdapat
mengidentifikasi
perbedaan
dengan
terlebih
satu
entitas
utama
set
dahulu sebelum
mengidentifikasi dan mempertimbangkan entitas, hubungan, dan atribut lain yang berkaitan dengan entitas awal yang telah diidentifikasi. 4. Mixed Menggunakan pendekatan bottom up dan top down untuk beberapa bagian dari data model sebelum menggabungkan semua bagian-bagian tersebut.
2.1.2.4.2 Phases of Database Design Tahapan-tahapan dalam merancang database adalah: 1. Conceptual Database Design
20 Menurut Connolly dan Begg (2010:322), conceptual database design adalah suatu proses membangun sebuah model dari data yang digunakan dalam suatu perusahaan dan independen dari semua pertimbangan fisik. 2. Logical Database Design Menurut Connolly dan Begg (2010:323), logical database design adalah suatu proses membangun sebuah model dari data yang digunakan dalam suatu perusahaan berdasarkan model data tertentu, tetapi independen dari DBMS tertentu dan pertimbangan fisik lainnya. 3. Physical Database Design Menurut Connolly dan Begg (2010:324), physical database design adalah suatu proses memproduksi sebuah deskripsi implementasi
pada
penyimpanan
sekunder
yang
menggambarkan relasi dasar, organisasi file, indeks yang digunakan untuk mencapai akses yang efisien terhadap data, kendala integritas terkait dan langkah-langkah keamanan.
2.1.2.5 DBMS Selection Menurut Connolly dan Begg (2010:325-329) DBMS selection adalah pemilihan suatu DBMS yang tepat untuk mendukung sistem database. Terdapat beberapa langkah dalam memilih DBMS yaitu: 1. Mendefinisikan kerangka referensi studi 2. Mendaftar dua atau tiga produk 3. Mengevaluasi produk 4. Merekomendasikan pilihan dan laporan produk
2.1.2.6 Application Design Menurut Connolly dan Begg (2010:329), application design adalah rancangan user interface dan program aplikasi yang menggunakan dan
21 memproses database. Terdapat dua aspek desain aplikasi, yaitu desain transaksi (transaction design) dan desain antarmuka pengguna (userinterface design).
2.1.2.6.1 Transaction Design Menurut Connolly dan Begg (2010:330-331), transaksi adalah suatu tindakan, atau serangkaian tindakan yang dilakukan oleh pengguna tunggal atau program aplikasi, yang mengakses atau mengubah isi database. Dari perspektif DBMS, sebuah transaksi mentransfer database dari satu kondisi yang konsisten ke kondisi lain. Tujuan dari desain transaksi adalah untuk menetapkan dan mendokumentasikan karakteristik tingkat tinggi dari transaksi yang dibutuhkan pada database, termasuk: 1. Data yang akan digunakan dalam transaksi 2. Karakteristik fungsional dari transaksi 3. Output transaksi 4. Hal yang penting bagi pengguna 5. Tingkat yang diharapkan dari penggunaan Ada tiga jenis utama transaksi: retrieval transactions, update transactions, dan mixed transactions.
1. Retrieval transactions digunakan untuk mengambil data yang akan ditampilkan dalam pembuatan laporan. 2. Update transactions digunakan untuk menyisipkan record baru, menghapus catatan lama, atau memodifikasi catatan yang ada dalam database. 3. Mixed transactions melibatkan baik retrieval transactions dan update transactions.
22 2.1.2.6.2 User Interface Design Guidelines Menurut Connolly dan Begg (2010:331-333), terdapat beberapa pedoman dalam merancang sebuah antarmuka pengguna yang baik, yaitu: 1. Judul yang bermakna 2. Instruksi yang mudah dipahami 3. Pengelompokan secara logis dan posisi fields yang berurutan 4. Layout untuk form atau report menarik 5. Label field yang dikenal 6. Terminologi dan singkatan yang konsisten 7. Penggunaan warna yang konsisten 8. Batasan dan ruang yang terlihat bagi field data-entry 9. Pergerakan kursor mudah 10. Perbaikan kesalahan bagi individu dan keseluruhan field 11. Pesan kesalahan dimunculkan untuk data atau nilai yang salah 12. Penandaan optional field yang jelas 13. Pesan Penjelasan untuk field harus muncul 14. Pemberian tanda jika suatu proses telah selesai
2.1.2.7 Prototyping Menurut Connolly dan Begg (2010:333), prototyping adalah membangun sebuah model kerja dari sistem database. Sebuah prototipe adalah model kerja yang biasanya tidak memiliki semua fitur yang diperlukan atau menyediakan semua fungsionalitas dari sistem akhir. Tujuan utama dari pengembangan prototipe adalah untuk memungkinkan pengguna dalam menggunakan prototipe untuk mengidentifikasi fitur dari sistem yang bekerja dengan baik atau tidak, dan mungkin menyarankan perbaikan atau fitur baru ke sistem database. Ada dua strategi prototyping yang digunakan saat ini: requirements prototyping dan evolutionary prototyping.
23 1. Requirements prototyping menggunakan prototipe untuk menentukan persyaratan sistem database yang ditawarkan dan setelah persyaratan tersebut lengkap maka prototipe tersebut akan dibuang.
2. Evolutionary prototyping digunakan untuk tujuan yang sama,tetapi terdapat perbedaan penting yaitu bahwa prototipe tidak dibuang melainkan disimpan dan akan di kembangkan menjadi sistem database yang berkerja.
2.1.2.8 Implementation Menurut Connolly dan Begg (2010:333-334), implementation adalah realisasi fisik database dan perancangan aplikasi. Implementasi database dicapai dengan menggunakan data definition language (DDL) dari DBMS yang dipilih atau graphical user Interface (GUI), yang menyediakan fungsi yang sama dan menyembunyikan laporan low level DDL.
2.1.2.9 Data Conversion and Loading Menurut Connolly dan Begg (2010:334), data conversion and loading adalah mentransfer data yang ada ke dalam database baru dan mengkonversi aplikasi yang ada untuk berjalan pada database baru. Tahap ini diperlukan hanya jika sistem database baru menggantikan sistem lama.
2.1.2.10 Testing Menurut Connolly dan Begg (2010:334), testing adalah suatu proses menjalankan sistem database dengan maksud menemukan kesalahan. Testing juga harus mencakup kegunaan dari sistem database. Evaluasi harus dilakukan terhadap spesifikasi kegunaan. Kriteria- kriteria yang dapat digunakan untuk melakukan evaluasi adalah:
24 1. Learnability - Berapa lama waktu yang dibutuhkan pengguna baru untuk mengerti sebuah sistem 2. Performance - Seberapa baik sistem merespon pekerjaan pengguna 3. Robustness - Seberapa toleran sistem dalam menghadapi kesalahan pengguna 4. Recoverability - Seberapa baik sistem pulih dari kesalahan penggunaannya 5. Adapatability - Seberapa lama sistem beradaptasi dalam suatu model kerja
2.1.2.11 Operational Maintenance Menurut Connolly dan Begg (2010:335), operational maintenance adalah proses pemantauan dan pemeliharaan sistem database setalah proses instalasi dilakukan. Pada tahap sebelumnya, sistem database telah diimplementasikan dan diuji. Sistem sekarang bergerak ke tahap pemeliharaan (Operational Maintenance), yang melibatkan kegiatankegiatan berikut:
1. Memantau
kinerja
sistem.
Jika
performa
mengalami
penurunan maka diperlukan untuk melakukan perbaikan atau pengaturan ulang sistem database 2. Memelihara diperlukan.
dan
meningkatkan
sistem
database
jika
25 2.1.3 Entity Relationship 2.1.3.1 Entity Relationship Modelling Menurut Connolly dan Begg (2010:371), Entity relationship modelling atau ER merupakan pendekatan top-down pada perancangan basis data yang diawali dengan mengidentifikasi data penting yang disebut entitas (entities) dan hubungan (relationship) antar data yang harus di representasikan dalam model. Selain itu, beberapa rincian juga ditambahkan seperti informasi yang akan disimpan mengenai entities dan relationship disebut atribut dan constraint atau kendala pada entitas hubungan dan atribut.
2.1.3.1.1 Entity Types Menurut Connolly dan Begg (2010:372-374), entity type adalah sekelompok objek dengan properti yang sama, yang diidentifikasi oleh perusahaan yang memiliki keberadaan yang independen atau bebas. Keberadaan objek tersebut dapat bersifat asli (physical) dan abstrak (conceptual).
2.1.3.1.2 Relationship Types Menurut Connolly dan Begg (2010:374-376), relationship types adalah seperangkat asosiasi antara satu atau lebih tipe entitas yang berpartisipasi. Tiap jenis hubungan diberi nama yang menggambarkan fungsinya.
2.1.3.1.2.1 Degree of Relationship Type Menurut Connolly dan Begg (2010:376-378), degree of relationship type berkaitan dengan entitas yang terlibat dalam
26 relationship tertentu yang disebut sebagai peserta (participant) dalam hubungan tersebut. Jumlah peserta dalam relationship disebut tingkat hubungan (Degree of Relationship Type). Oleh karena itu, tingkat hubungan menunjukkan jumlah jenis entitas terlibat dalam sebuah relationship.
2.1.3.1.2.2 Recursive Relationship Menurut Connolly dan Begg (2010:378-379), recursive relationship adalah hubungan di mana tipe entitas yang sama berpartisipasi lebih dari sekali dalam peran yang berbeda. Relationship dapat diberikan nama peran untuk menunjukkan tujuan bahwa entitas setiap partisipan bermain dalam sebuah relationship. Nama peran dapat menjadi hal yang penting bagi hubungan rekursif (recursive relationship) untuk menentukan fungsi dari masing-masing partisipan. Nama peran biasanya tidak diperlukan jika fungsi entitas partisipan dalam relationship telah jelas.
2.1.3.1.3 Attributes Menurut Connolly dan Begg (2010:379), attribute adalah sebuah properti dari suatu entitas atau tipe hubungan. Atribut memegang nilainilai yang menggambarkan setiap kejadian entitas dan merupakan bagian utama dari data yang disimpan dalam basis data. Menurut Connolly dan Begg (2010:379), attribute domain adalah himpunan nilai-nilai yang diperbolehkan untuk satu atau lebih atribut. Attribute domain dapat diklasifisikan menjadi 3 bagian yaitu: •
simple dan composite attribute
27 •
single-valued dan multi-valued attribute
•
derived attribute
2.1.3.1.3.1 Simple and Composite Attributes Menurut Connolly dan Begg (2010:379-380), simple attribute merupakan sebuah atribut yang terdiri dari komponen tunggal dengan keberadaan independen. Contohnya position dan salary dari staff. Simple attribute tidak dapat dibagi lagi menjadi komponen yang lebih kecil. Simple attribute bisa disebut juga sebagai atomic attributes. Menurut Connolly dan Begg (2010:380), composite attributes merupakan sebuah atribut yang terdiri dari beberapa komponen, masing-masing dengan keberadaan independen. Beberapa atribut dapat dibagi lagi untuk menghasilkan komponen yang lebih kecil dengan keberadaan independen sendiri. Contohnya street, city dan postal code.
2.1.3.1.3.2 Single-Valued and Multi-Valued Attributes Menurut Connolly dan Begg (2010:380), single-valued attribute merupakan sebuah atribut yang memegang nilai tunggal untuk setiap kejadian dari suatu jenis entitas. Contohnya entitas branch yang mempunyai nilai satuan dari branch number (branchno). Menurut Connolly dan Begg (2010:380), multi-valued attribute merupakan sebuah atribut yang memegang beberapa nilai untuk setiap kejadian dari suatu jenis entitas. Contohnya entitas branch yang mempunyai banyak nilai untuk atribut nomor telepon (telno).
28 2.1.3.1.3.3 Derived Attributes Menurut Connolly dan Begg (2010:380-381), derived attributes merupakan sebuah atribut yang mewakili nilai yang diturunkan dari nilai atribut terkait atau sekumpulan atribut dan tidak perlu sejenis dalam entitasnya. Contohnya, nilai untuk durasi atribut dari entitas sewa dihitung dari rentStart dan rentFinish atribut dan juga dari entitas sewa. Hal tersebut mengacu pada atribut durasi sebagai atribut turunan, dan nilai yang berasal dari atribut rentStart dan rentFinish.
2.1.3.1.3.4 Keys Menurut
Connolly dan
Begg
(2010:381-382),
key
mempunyai tipe-tipe antara lain: •
Candidate key Kumpulan minimal dari suatu atribut yang secara unik mengidentifikasi setiap kejadian dari suatu entitas tersebut.
•
Primary key Kandidat key yang dipilih secara unik untuk mengidentifikasi setiap kejadian dari suatu entitas.
•
Composite key Sebuah kandidat key yang terdiri dari dua atau lebih atribut.
2.1.3.1.4 Strong and Weak Entity Type Menurut Connolly dan Begg (2010:383), strong entity type merupakan sebuah tipe entitas yang keberadaanya tidak bergantung pada entitas lainnya. Menurut Connolly dan Begg (2010:383), weak entity type merupakan sebuah tipe entitas yang keberadaanya bergantung pada entitas lainnya.
29
2.1.3.1.5 Structural Constraints Menurut
Connolly
dan
Begg
(2010:385-388),
structural
constraint dibagi menjadi 3 yaitu: 1. Multiplicity Jumlah dari kemungkinan kejadian dari suatu entitas yang mungkin berhubungan dengan kejadian tunggal dari jenis entitas terkait melalui hubungan tertentu. Tingkatan umum untuk suatu relationship disebut binary. Hubungan relationship biasanya disebut sebagai one-to-one (1:1), one-to-many (1:*), dan many-to-many (*:*). •
one-to-one (1:1)
Tiap relationship merupakan hubungan antara sebuah kejadian pada entitas yang satu dengan sebuah kejadian pada entitas lainnya yang ada dalam relationship tersebut.
Gambar 2.2 One-to-one (1:1) Relationship Sumber: Connolly dan Begg (2010:386) •
one-to-many (1:*)
Tiap relationship merupakan hubungan antara kejadian pada entitas satu dengan satu atau lebih entitas lainnya.
30
Gambar 2.3 One-to-many (1:*) Relationship Sumber: Connolly dan Begg (2010:387)
•
many-to-many (*:*)
Tiap relationship merupakan hubungan antara kejadian pada entitas satu atau lebih dengan satu atau lebih entitas lainnya.
Gambar 2.4 Many-to-many (1:*) Relationship Sumber: Connolly dan Begg (2010:388)
1. Multiplicity for Complex Relationships Menurut Connolly dan Begg (2010:389), multiplicity for complex relationships merupakan jumlah dari kemungkinan kejadian dari suatu entitas dalam suatu hubungan n-ary ketika nilai (n-1) yang lain tetap. Contohnya multiplicity untuk hubungan terner (ternacity) merupakan
31 potensi kejadian entitas (occurences entity) suatu entitas tertentu dalam hubungan ketika dua nilai lainnya yang mewakili dua entitas lainnya adalah tetap. 2. Participation Menurut Connolly dan Begg (2010:390-391), participation menentukan apakah semua atau hanya beberapa kejadian entitas berpartisipasi dalam sebuah hubungan. Partisipasi entitas dalam suatu relationship muncul sebagai nilai minimum untuk rentang multiplicity dalam suatu relationship. 3. Cardinality Menurut
Connolly dan
Begg
(2010:391-392),
cardinality
menjelaskan jumlah maksimum kemungkinan akan hubungan kejadian untuk entitas yang berpartisipasi dalam relationship tertentu.
2.1.3.1.6 Problems with ER Models Menurut Connolly dan Begg (2010:392-393), problem with ER model bisa diartikan sebagai perangkap koneksi (connection trap). Connection trap memiliki 2 tipe sebagai berikut: 1. Fan traps Fan trap terjadi ketika sebuah model merepresentasikan sebuah relationship diantara tipe entitas. Akan tetapi jalan antara entity occurences bersifat ambigu. 2. Chasm traps Chasm trap terjadi ketika sebuah model menyarankan akan keberadaan suatu relationship antara entity type. Akan tetapi, jalan tidak menunjukan di antara entity occurences.
32
2.1.3.2 Enhanced Entity–Relationship Modeling Menurut Connolly dan Begg (2010: 399), sebagai konsep dasar, ER modeling masih memiliki kekurangan dan batasan dalam mewakili atau merepresentasikan persyaratan baru dari sebuah aplikasi yang lebih kompleks. Untuk
memperbaiki
kekurangan
tersebut,
dikembangkanlah
additional
‘semantic’ modeling concepts. Model ER didukung dengan konsep additional ‘semantic’ modeling disebut Enhanced Entity–Relationship (EER) model. Terdapat tiga konsep tambahan yang paling penting dan berguna dalam EER model, yaitu specialization atau generalization, aggregation, dan composition.
2.1.3.2.1 Specialization atau Generalization Menurut Connolly dan Begg (2010:400), konsep spesialisasi atau generalisasi berkaitan erat dengan tipe entitas khusus yang dikenal sebagai superclass dan subclass. Konsep ini juga berkaitan dengan sebuah proses yang disebut attribute inheritance. Terdapat dua jenis batasan utama dalam hubungan superclass atau subclass yang disebut participation and disjoint constraints.
2.1.3.2.1.1 Superclass dan Subclass Menurut Connolly dan Begg (2010:400), superclass adalah sebuah tipe entitas yang mencakup satu atau lebih sub kelompok yang berbeda dari kejadian tersebut, yang perlu diwakili dalam data model. Sedangkan subclass adalah sebuah pengelompokan yang berbeda dari munculnya suatu tipe entitas, yang perlu untuk diwakili dalam sebuah data model. Setiap anggota subclass juga merupakan anggota dari superclass.
33 2.1.3.2.1.2 Attribute Inheritance Menurut Connolly dan Begg (2010:402), sebuah entitas dalam subclass merepresentasikan objek 'real world ' yang sama seperti di dalam superclass dan mempunyai atribut subclass tertentu yang berkaitan dengan superclass. Entitas dalam subclass juga mewarisi semua atribut dari superclass.
2.1.3.2.1.3 Specialization Menurut Connolly dan Begg (2010:402), specialization adalah proses memaksimalkan perbedaan antara anggota dari suatu
entitas
dengan
mengidentifikasi
karakteristik
yang
membedakan mereka. Specialization menggunakan pendekatan top-down untuk mendefinisikan satu set superclasses dan subclass yang berkaitan dengannya.
2.1.3.2.1.4 Generalization Menurut Connolly dan Begg (2010:403), generalization adalah proses meminimalkan perbedaan antara entitas dengan mengidentifikasi karakteristik umum mereka. Proses generalisasi adalah dengan menggunakan pendekatan bottom-up, yang menghasilkan identifikasi superclass yang bersifat umum dari tipe entitas yang asli.
2.1.3.2.2 Aggregation Menurut
Connolly
dan
Begg
(2010:411),
aggregation
mempresentasikan hubungan ‘has-a’ atau ‘is-part-of’ antara tipe-tipe entitas, dimana salah satu adalah sebagai ‘whole’ dan yang lainnya sebagai ‘part’.
34 2.1.3.2.3 Composition Menurut Connolly dan Begg (2010:412), compostion adalah sebuah bentuk agregasi yang khusus yang mereperesentasikan hubungan antar entitas, dimana terdapat strong ownership dan dalam waktu yang bersamaan antara ‘whole’ dengan ‘part’.
2.1.4 Normalization Menurut Connoly dan Begg (2010:415), normalisasi merupakan salah satu teknik desain database, yang dimulai dengan pengecekan hubungan (disebut fungsional dependensi) antar atribut. Atribut menjelaskan beberapa properti dari data atau hubungan antara data yang penting bagi perusahaan. Normalisasi menggunakan serangkaian tes (digambarkan sebagai bentuk NF) untuk membantu mengidentifikasi pengelompokan optimal untuk atribut untuk mengidentifikasi himpunan relasi yang cocok yang mendukung kebutuhan data dari perusahaan.
2.1.4.1 The Purpose of Normalization Menurut Connoly dan Begg (2010:416), normalisasi didefinisikan sebagai sebuah teknik untuk membuat suatu hubungan dengan sifat yang diinginkan sesuai dengan kebutuhan data suatu perusahaan. Menurut Connoly dan Begg (2010:416), tujuan dari normalisasi adalah untuk mengidentifikasi suatu relasi yang cocok yang mendukung data persyaratan suatu perusahaan.
35 Ciri-ciri suatu relasi yang baik antara lain: 1. Jumlah minimal atribut yang diperlukan untuk mendukung kebutuhan data perusahaan. 2. Atribut dengan hubungan logis dekat (digambarkan sebagai ketergantungan fungsional) yang ditemukan dalam hubungan yang sama. 3. Redundansi minimal dengan setiap atribut diwakili hanya sekali dengan penting kecuali atribut yang membentuk semua atau sebagian dari foreign key yang penting untuk bergabung dengan relasi yang terkait. Menurut Connoly dan Begg (2010:416-417), manfaat menggunakan database yang memiliki relasi yang tepat antara lain: 1. Database akan lebih mudah bagi pengguna untuk mengakses dan memelihara data 2. Database mengambil storage disk minimal pada komputer.
2.1.4.2 Data Redundancy Menurut Connoly dan Begg (2010:418), tujuan utama dari desain database relasional adalah untuk pengelompokan atribut ke dalam hubungan untuk meminimalkan data yang redundansi. Jika tujuan ini tercapai, potensi manfaat untuk implementasi database meliputi: 1. Update data yang disimpan dalam database yang dicapai dengan jumlah operasi minimal sehingga mengurangi data yang kurang konsisten yang terjadi dalam database 2. Pengurangan dalam ruang penyimpanan file yang diperlukan oleh relasi dasar sehingga dapat meminimalkan biaya.
36 2.1.4.3 Functional Dependencies and Determinant Menurut
Connoly
dan
Begg
(2010:420-421),
functional
dependencies menggambarkan hubungan antara atribut dalam suatu relasi. Functional dependencies merupakan atau atribut semantik dalam suatu relasi. Semantik menunjukkan bagaimana atribut berhubungan satu sama lain, dan menentukan functional dependencies antar atribut. Ketika terjadi functional dependencies, ketergantungan tersebut ditentukan sebagai kendala (constraint) antar atribut. Menurut Connoly dan Begg (2010:421), determinant mengacu pada atribut, atau kelompok atribut, di sisi pasangan relasi dari ketergantungan fungsional (functional dependencies).
2.1.4.4 The Process of Normalization Menurut
Connoly dan
Begg
(2010:428-436),
normalisasi
memiliki 6 proses antara lain: 1. UNF (Unnormalized Form) Sebuah tabel yang berisi satu atau lebih pengulangan kelompok. 2. 1NF Suatu relasi di mana persimpangan (intersection) tiap baris dan kolom berisi satu dan hanya satu nilai. Dalam format ini, tabel adalah dalam form UNF dan disebut sebagai tabel UNF. Untuk mengubah tabel UNF ke bentuk 1NF, diperlukan untuk mengidentifikasi dan menghapus kelompok yang berulang dalam tabel. Kelompok yang berulang diantaranya atribut, atau kelompok atribut dalam tabel yang terjadi dengan beberapa nilai untuk single occurence dari atribut nominated key untuk table
37 tersebut. Pada konteks ini, istilah key mengacu pada atribut yang secara unik mengidentifikasi setiap baris dalam tabel UNF. 3. 2NF Suatu relasi yang ada di Bentuk 1NF dan tiap atribut nonprimary-key sepenuhnya functional dependent pada primary key. Proses normalisasi dari 1NF ke 2NF melibatkan penghapusan partial
dependencies
(ketergantungan
parsial).
Jika
terdapat
ketergantungan parsial, diperlukan penghapusan atribut sebagian tergantung dari hubungan dengan menempatkan relasi baru bersama dengan determinannya 4. 3NF Suatu relasi yang ada di 1NF dan 2NF dan di mana tidak ada atribut non-primary-key adalah transitif bergantung pada primary key (PK). Proses normalisasi 2NF ke 3NF melibatkan penghapusan transitive dependencies. Jika terdapat dependensi transitif, diperlukan penghapusan menempatkan determinannya.
transitif atribut
tergantung dalam
atribut
relasi
dari
baru
relasi
dengan
bersama
dengan
38 2.1.5 Database Design Methodology 2.1.5.1 Conceptual Database Design Methodology Menurut Connolly dan Begg (2010:322), conceptual database design adalah suatu proses membangun sebuah model dari data yang digunakan dalam suatu perusahaan dan independen dari semua pertimbangan fisik. 2.1.5.1.1 Langkah 1 Membangun Konseptual Data Model Menurut Connolly and Begg (2010:470-471), langkah pertama di dalam perancangan konseptual basis data untuk membuat satu (atau lebih) model data konseptual dari data yang dibutuhkan oleh perusahaan. Model data konseptual terdiri dari: •
Tipe entitas;
•
Tipe relationship;
•
Atribut dan atribut domain;
•
Primary keys dan alternate keys;
•
Integrity constraints. Model data konseptual di dukung oleh dokumentasi, termasuk
diagram ER dan sebuah kamus data, dimana dihasilkan melalui pengembangan
dari
model.
Detail
dari
tipe
pendukung
dokumentasi yang dapat dihasilkan saat melalui bermacammacam tahapan. Proses-proses yang termasuk di langkah 1 adalah: Langkah 1.1 Identifikasi tipe entitas Langkah 1.2 Indentifikasi tipe relasi Langkah 1.3 Identifikasi dan asosiasi atribut dengan entitas atau tipe relasi Langkah 1.4 Menentukan domain atribut
39 Langkah 1.5 Menentukan kandidat, primary, dan alternate key atribut Langkah 1.6 Memilih penggunaan dari konsep model yang ditingkatkan (tahap opsional) Langkah 1.7 Memeriksa model untuk redundansi Langkah 1.8 Memvalidasi model konseptual dengan transaksi pengguna Langkah 1.9 Mengulas data model konseptual dengan user. Langkah 1.1 Identify entity Menurut Connolly and Begg (2010:471), tujuan dari identifikasi entitas adalah mengidentifikasi tipe entitas yang dibutuhkan. Tahap pertama dalam membangun model data konseptual adalah menentukan objek utama yang dibutuhkan oleh pengguna. Objek-objek ini adalah tipe entitas untuk model data. Satu metode untuk
mengidentifikasi
entitas
adalah
dengan
memeriksa
spesifikasi kebutuhan pengguna. Sebuah alternatif untuk mengidentifikasi entitas adalah melihat objek-objek yang mempunyai eksistensi di dalam hak nya masing-masing.
Langkah 1.2 Identifikasi tipe relasi Menurut Connolly and Begg (2010:472-473), tujuan dari identifikasi tipe relasi adalah mengidentifikasi relasi penting yang ada diantara tipe entitas.
40 Setelah mengidentifikasi entitas, langkah berikutnya adalah untuk mengidentifikasi semua hubungan yang ada pada entitas tersebut. Salah satu metode ketika mengidentifikasi entitas adalah dengan melihat kata benda dalam spesifikasi user requirements. Dapat menggunakan tata bahasa dari persyaratan spesifikasi untuk mengidentifikasi relasi. Biasanya, hubungan ditunjukkan oleh verba atau ekspresi verbal. Fakta bahwa persyaratan spesifikasi mencatat hubungan ini adalah penting bagi perusahaan, dan harus dimasukkan dalam model. Untuk membuat model diharuskan berhati-hati untuk melihat hubungan kompleks yang mungkin melibatkan lebih dari dua jenis entitas dan hubungan rekursif yang melibatkan hanya satu jenis entitas.
Penggunaan Entity - Relationship (ER) diagram Penggunaan entity relationship memvisualisasikan sistem yang
kompleks
spesifikasi
daripada
persyaratan
menguraikan
pengguna
yang
deskripsi panjang.
tekstual entity-
relationship (ER) diagram mewakili entitas dan bagaimana mereka berhubungan antara satu dengan yang lainnya dengan lebih mudah. Melalui tahap desain basis data, direkomendasikan bahwa penggunaan ER diagram digunakan untuk membantu membuat sebuah gambaran dari bagian perusahaan yang akan di buat modelnya. Penggunaan object-oriented paling baru yang disebut UML (Unified Modeling Language) tetapi fungsinya yang mirip.
41 Menentukan multiplicity constraints dari relationship types Menurut Connolly and Begg (2010:473-474), setelah mempunyai model relasi yang telah diidentifikasi, langkah selanjutnya adalah menentukan multiplisitas dari setiap relasi. Jika nilai spesifik untuk multiplisitas diketahui, batas atas atau batas bawah membuktikan kebenaran nilai tersebut. Multiplisitas constraints digunakan untuk memeriksa dan merawat kualitas data. Constraints ini adalah pernyataan mengenai kejadian entitas yang dapat diterapkan saat database diperbarui untuk menentukan iya atau tidaknya perbaharuan melanggar aturan dari perusahaan. Model yang termasuk dalam multiplisitas
constraints
lebih
eksplisit
merepresentasikan
semantik dari relasi dan hasil di dalam representasi yang lebih baik dari kebutuhan data perusahaan.
Memeriksa fan dan chasm traps Menurut
Connolly
and
Begg
(2010:474),
setelah
mempunyai identifikasi relasi yang diperlukan, memeriksa setiap relasi di ER model adalah representasi yang benar dari dunia nyata, dan dengan fan atau chasm traps yang belum terbentuk secara tidak sengaja.
Langkah 1.3 Identify and associate attributes with entity or relationship types Menurut Connolly and Begg (2010:474), tujuan dari mengidentifikasi dan mengasosiasi atribut dengan entitas atau tipe
42 relasi adalah untuk mengasosiasi atribut dengan entitas yang layak atau relationship types. Tahap berikutnya di dalam metodologi adalah untuk mengidentifikasi tipe dari fakta mengenai entitas dan relasi yang dipilih untuk di sajikan ulang di dalam basis data. Pada cara yang sesuai untuk mengidenfitikasi entitas dengan melihat nomina atau frase nomina pada spesifikasi persyaratan pengguna. Atributatribut dapat diidentifikasi dimana nomina atau frase nomina adalah sebuah properti, kualitas, tanda pengenal, atau karakteristik dari salah satu relasi atau entitas.
Langkah 1.4 Determine attribute domains Menurut Connolly and Begg (2010 :478 ), tujuan dari menentukan domain atribut adalah untuk menentukan domain untuk atribut pada model data konseptual. Sebuah domain adalah kumpulan dari nilai dari satu atau lebih atribut yang menarik nilanya masing-masing. Untuk contohnya dapat didefinisikan: •
Atribut domain dari nomer staff yang valid sebagai variable dengan lima karakter, dengan dua karakter pertama yang berbentuk huruf dan karakter selanjutnya sebagai angka dengan jangkauan 1-999 seperti SA001;
•
Nilai yang memungkinkan untuk atribut jenis kelamin dari entitas staf adalah ‘M’ atau ‘F’. Domain dari atribut ini adalah single character string yang memuat nilai ‘M’ atau ‘F’.
Data model yang telah sepenuhnya dikembangkan akan menetapkan domains dari setiap atribut yang terdapat didalamnya, yaitu:
43 •
Kumpulan nilai yang dibolehkan untuk atribut;
•
Ukuran dan format dari atribut.
Langkah 1.5 Determine candidate, primary, and alternate key attributes Menurut Connolly and Begg (2010: 479), tujuan dari menentukan atribut candidate, primary, dan alternate key adalah untuk mengidentifikasi candidate key untuk setiap tipe entitas dan jika ada lebih dari satu candidate key, untuk memilih satu untuk menjadi primary key dan yang lain sebagai alternate key. Tahap ini mengidentifikasi candidate key untuk sebuah entitas dan setelah memilihnya salah satu akan menjadi primary key. Sebuah candidate key adalah sebuah kumpulan dari atribut dari sebuah entitas unik yang menjelaskan setiap kejadian dari entitas. Dapat juga mengidentifikasi lebih dari satu candidate key, pada kasus tertentu, diharuskan memilih satu untuk menjadi primary key, dan candidate key yang lainnya disebut alternate key. Saat memilih sebuah primary key diantara candidate keys, gunakan panduan ini untuk membuat pilihan: •
Candidate key dengan set atribut minimal;
•
Candidate key yang nilainya paling jarang berubah;
•
Candidate key dengan karakter paling sedikit (untuk atribut tekstual);
•
Candidate key dengan nilai paling kecil (untuk atribut numerik);
•
Candidate key yang paling mudah digunakan dari sudut pandang pengguna.
44
Langkah 1.6 Consider use of enhanced modeling concepts (optional step) Menurut Connolly and Begg (2010:480), tujuan dari memilih penggunaan dari meningkatkan konsep model seperti specialization/generalization, aggregation, dan composition. Pada tahap ini, terdapat tindakan yang bersifat optional untuk melanjutkan pengembangan dari ER model menggunakan advanced modelling concept yang menggunakan specialization atau generalization, aggregation, dan composition. Jika memilih pendekatan specialization, dapat terlihat perbedaan diantara entitas dengan cara mendefinisikan satu atau lebih dari subclasses dari superclass. Jika memilih pendekatan generalisasi, untuk mengidentifikasi fitur umum antara entitas untuk mendefinisikan sebuah superclass yang digeneralisasi. Agregation digunakan untuk menggambarkan ‘mempunyai’ atau ‘bagian dari’ relasi diantara tipe entitas dimana salah satu merepresentasikan ‘semua’ dan yang satu sebagai ‘bagian’.
Langkah 1.7 Check model for redudancy Menurut Connolly and Begg (2010:482), tujuan dari tahap ini adalah untuk memeriksa pengulangan atau redundansi yang ada pada model. Pada tahap ini, dilakukan pemeriksaan terhadap conceptual data model dengan tujuan spesifik untuk mengidentifikasi dimana terdapat sebuah pengulangan yang terjadi dan menghilangkan pengulangan yang ada. Ada tiga aktifitas yang dilakukan pada tahap ini:
45 1. Memeriksa ulang one-to-one (1:1) relationship; 2. Menghilangkan redundant relationship; 3. Mempertimbangkan time dimension. Langkah
1.8
Validate
conceptual
model
against
user
transactions Menurut Connolly and Begg (2010:483), tujuan dari memvalidasi conceptual model terhadap user transactions adalah memastikan conceptual data model dan mendukung transaksi yang dibutuhkan. Ada
dua
pendekatan
yang
memungkinkan
dalam
memastikan bahwa conceptual data model mendukung transaksi yang dibutuhkan: 1. Describing the transactions Pendekatan ini dilakukan dengan cara memeriksa semua informasi seperti entities, relationships, dan atribut-atributnya yang dibutuhkan dari setiap transaksi yang disediakan oleh model dengan cara mendokumentasikan deskripsi dari setiap transactions requirements.
2. Using transaction pathways. Pendekatan kedua untuk memvalidasi data model dengan required
transactions
melibatkan
diagram
yang
merepresentasikan langkah yang diambil dari setiap transaksi secara langsung pada ER diagram.
46 Langkah 1.9 Review conceptual data model with user Menurut Connolly and Begg (2010:485), tujuan meninjau ulang conceptual data model dengan penguna adalah untuk memastikan model yang dibuat sesuai dengan representasi dari data requirements di perusahaan. Sebelum menyelesaikan tahap pertama pada conceptual data model sebaiknya memeriksa data model terlebih dahulu dengan user, termasuk ER diagram dan dokumen pendukung yang mendeskripsikan data model. Jika ada kejanggalan terdapat pada data model, diharuskan untuk membuat perubahan, dimana membutuhkan pengulangan pada tahap-tahap sebelumnya. Tahap diulang sampai pengguna telah siap menerima model sebagai representasi yang benar dari bagian perusahaan yang dibuat modelnya.
2.1.5.2 Logical Database Design Methodology for the Relational Model Menurut Connolly dan Begg (2010:323), logical database design adalah suatu proses membangun sebuah model dari data yang digunakan dalam suatu perusahaan berdasarkan model data tertentu, tetapi independen dari DBMS tertentu dan pertimbangan fisik lainnya.
2.1.5.2.1 Langkah 2 Build and Validate Logical Data Model Menurut Connolly and Begg (2010:490), tujuan dari membangun dan memvalidasi logical data model adalah untuk menerjemahkan conceptual data model menjadi logical data model dan untuk memvalidasi model ini, dan memeriksanya apakah strukturnya benar dan dapat membantu transaksi yang dibutuhkan. Dalam
langkah
ini,
tujuan
utamanya
adalah
menerjemahkan conceptual data model yang sudah dibuat di Langkah 1 medefinisikan logical data model dari persyaratan perusahaan. Tujuan ini dicapai melalui aktifitas berikut ini:
47 Langkah 2.1 Derive relations for logical data model Langkah 2.2 Validate relations using normalization Langkah 2.3 Validate relations against user transaction Langkah 2.4 Check integrity constraints Langkah 2.5 Review logical data model with user Langkah 2.6 Merge logical data models into global model (optional step) Langkah 2.7 Check for future growth
Langkah 2.1 Derive relations for logical data model Menurut Connolly and Begg (2010:492), langkah ini bertujuan membuat relations untuk logical data model untuk menggambarkan entities, relationship, dan attributes yang sudah diidentifikasi. Dideskripsikan bagaimana relations diperoleh dengan struktur berikut, yang mungkin terdapat di conceptual data model: 1. Strong entity types; 2. Weak entity types; 3. One-to-many (1:*) binary relationship types; 4. One-to-one (1:1) binary relationship types; 5. One-to-one (1:1) recursive relationship types; 6. Superclass/subclass relationship types; 7. Many-to-many (*:*) binary relationship types; 8. Complex relationship types; 9. Multi-valued attributes.
Langkah 2.2 Validate relations using normailzation Menurut Connolly and Begg (2010:501), langkah ini bertujuan untuk memvalidasi relations pada logical data model menggunakan normalisasi. Pada langkah ini terjadi validasi dari kelompok atribut di setiap relasi menggunakan aturan normalisasi.
48 Proses dari normalisasi mengambil sebuah relasi melewati beberapa langkah untuk memeriksa apakah sesuai komposisi atribut di dalam relasinya dengan menggunakan aturan First Normal Form (1NF), Second Normal Form (2NF), dan Third Normal Form (3NF)
Langkah 2.3 Validate relations against user transactions Menurut Connolly and Begg (2010:502), langkah ini bertujuan memastikan relasi di dalam logical data model mendukung transaksi yang dibutuhkan, sesuai dengan user requirements specification.
Langkah 2.4 Check integrity constraints Menurut Connolly and Begg (2010:502), langkah ini bertujuan untuk memeriksa integritas dari constraints yang digambarkan pada logical data model. Tipe dari integritas sebuah constraint adalah: •
Required data;
•
Attribute domain constraints;
•
Multiplicity;
•
Entity integrity;
•
Referential integrity;
•
General constraints;
Langkah 2.5 Review logical data model with user Menurut Connolly and Begg (2010:506), langkah ini bertujuan untuk memeriksa ulang logical data model dengan users untuk memastikan model adalah represesentasi sebenarnya dari persyaratan yang dibutuhkan perusahaan. Jika users tidak
49 puas dengan modelnya maka pengulangan langkah-langkah sebelumnya mungkin dibutuhkan.
Relasi antara Logical Data Model dan Data Flow Diagrams Sebuah logical data model tercermin pada struktur dari penyimpanan data untuk perusahaan. Data flow Diagram (DFD) menunjukan data perusahaan yang bergerak dan disimpan di dalam data stores. Semua atribut seharusnya terlihat jika salah satu entitas diambil, dan mungkin dapat terlihat sedang mengalir disekitar data flow perusahaan. Jika kedua teknik ini digunakan maka dapat melihat konsistensi dan kelengkapan dengan cara: •
Setiap data store harus menggambarkan semua entity types;
•
Atribut pada data flows harus dimiliki oleh entity types.
Langkah 2.6 Merge logical data models into global model (optional step) Menurut Connolly and Begg (2010:506-517), langkah ini bertujuan untuk menggabungkan data logical lokal menjadi satu global logical data model yang menggambarkan semua pengguna dari database. Dalam aktifitas ini terdapat langkah yang akan dilalui: Langkah 2.6.1 Merge logical data models into global model Langkah ini bertujuan untuk menggabungkan local logical data models menjadi satu global logical data model.
50 Langkah 2.6.2 Validate global logical data model Langkah ini bertujuan untuk memvalidasi relasi yang dibuat dari global logical data model menggunakan teknik dari normalisasi dan memastikan mendukung transaksi yang dibutuhkan. Langkah 2.6.3 Review global logical data model with users Langkah ini bertujuan untuk melihat kembali global logical data model dengan users untuk memastikan bahwa data model adalah representasi yang benar dari data requriements perusahaan.
Langkah 2.7 Check for future growth Menurut Connolly and Begg (2010:517), langkah ini bertujuan untuk menentukan apakah ada perubahan yang berarti seperti perkiraan masa depan dan untuk menilai apakah logical data model dapat mengakomodasi perubahan ini.
2.1.5.3 Physical Database Design Menurut Connolly dan Begg (2010:523), physical database design merupakan proses menghasilkan deskripsi implementasi basis data pada penyimpanan sekunder; menggambarkan hubungan dasar, berkas organisasi, dan indeks yang digunakan untuk mencapai akses yang efisien terhadap data, dan setiap kendala integritas terkait dan langkah-langkah keamanan.
51 Physical
Database
Design
Methodology
for
Relational
Databases Menurut Connolly dan Begg (2010:524), terdapat langkahlangkah dalam physical database design antara lain:
2.1.5.3.1 Langkah 3 Menerjemahkan Logical Data Model untuk Target DBMS
Menurut Connolly dan Begg (2010:524), Untuk menghasilkan skema database relasional dari logical data model yang dapat diimplementasikan dalam target DBMS. Proses ini memerlukan pengetahuan yang mendalam tentang fungsi yang diinginkan DBMS. Hal-hal yang perlu diketahui oleh seorang desainer dalam tahap ini antara lain:
1. Cara membuat hubungan dasar (based relation) 2. Apakah sistem mendukung definisi primary key, foreign key, dan alternate key; 3. Apakah sistem mendukung definisi data yang dibutuhkan (apakah sistem memungkinkan atribut didefinisikan sebagai NOTNULL); 4. Apakah sistem mendukung definisi domain 5. Apakah sistem mendukung kendala integritas relasional 6. Apakah sistem mendukung definisi batasan integritas
Pada langkah 3 terdapat 3 aktivitas yang diperlukan antara lain:
Langkah 3.1 Perancangan relasi dasar Menurut Connolly dan Begg (2010:525), Untuk memutuskan bagaimana untuk mewakili relasi dasar yang diidentifikasi dalam logical data model dalam DBMS.
52
Untuk memulai proses desain physical, pertama-tama dilakukan penyusunan dan pengasimilasian informasi tentang hubungan yang dihasilkan selama desain database logical. Informasi yang diperlukan dapat diperoleh dari kamus data dan definisi hubungan dijelaskan dengan menggunakan Database Design Language (DBDL). Untuk setiap relasi yang diidentifikasi dalam model data logis, memiliki definisi yang terdiri dari: 1. Nama relasi 2. Daftar atribut sederhana dalam tanda kurung 3. Primary key, alternate key(AK), dan foreign key(FK) 4. Referensial integritas kendala (constraint) untuk setiap foreign key yang diidentifikasi.
Berdasarkan kamus data, terdapat beberapa atribut yang harus dimilki antara lain: 1. Domain, yang terdiri dari tipe data, panjang, dan setiap kendala pada domain 2. Nilai standar opsional untuk atribut 3. Apakah atribut dapat berupa nulls 4. Apakah atribut berasal dan, jika demikian, bagaimana harus dihitung
Langkah 3.2 Perancangan representasi data turunan Menurut Connolly dan Begg (2010:526), Untuk menentukan bagaimana cara untuk mewakili data turunan dalam logical data model di DBMS. Atribut yang nilainya dapat ditemukan dengan memeriksa
nilai
dari
atribut
sebagai data turunan atau kalkulasi atribut.
lain
dikenal
53 Berdasarkan perancangan basis data secara physical, atribut diturunkan dan disimpan dalam database atau dikalkulasi setiap waktu yang dibutuhkan adalah tradeoff. Hal-hal yang harus dikalkulasi oleh seorang desainer antara lain: 1. Biaya tambahan untuk menyimpan data yang berasal dan tetap konsisten dengan data operasional 2. Dari mana asalnya 3. Biaya untuk menghitung setiap kali diperlukan
Langkah 3.3 Design general constraints Menurut Connolly dan Begg (2010:528), Untuk merancang constraint secara umum untuk DBMS. Perubahan hubungan (relationship) dapat dibatasi oleh integritas constraint yang mengatur transaksi 'real world' yang diwakili oleh update.
Langkah 4: Merancang file organisasi dan index Menurut Connolly dan Begg (2010:529), Untuk menentukan organisasi file yang optimal untuk menyimpan relasi dasar dan indeks yang diperlukan untuk mencapai kinerja yang dapat diterima, yaitu: cara di mana hubungan dan tuple akan diselenggarakan pada penyimpanan sekunder. Desain database fisik harus dipandu oleh data yang alami dan digunakan. Secara umum, database desainer harus memahami beban kerja yang didukung basis data. Selama pengumpulan persyaratan dan tahap analisis, ada persyaratan yang ditetapkan transaksi tertentu mengenai seberapa cepat harus menjalankan atau berapa banyak transaksi harus diproses per detik. Pada langkah 4 terdapat 4 aktivitas yang diperlukan antara lain:
54 Langkah 4.1 Analisa Transaksi Menurut
Connolly
dan
Begg
(2010:529),
Untuk
memahami fungsi dari transaksi yang berjalan pada database dan untuk menganalisis transaksi yang penting. Untuk melakukan physical database design secara efektif, maka diperlukan pengetahuan tentang transaksi atau pertanyaan yang akan berjalan pada basis data. Hal ini mencakup
baik
informasi
kualitatif
dan
informasi
kuantitatif. Dalam menganalisa transaksi, diperlukan untuk mengidentifikasi
kinerja
kriteria,
seperti:
1. Transaksi yang sering dijalankan dan memiliki dampak yang signifikan pada kinerja . 2. Transaksi yang penting untuk operasi bisnis. 3. Ketika ada permintaan yang tinggi dibuat pada database dalam sehari / seminggu (disebut juga peak load). Langkah 4.2 Pemilihan Organisasi File Menurut
Connolly
dan
Begg
(2010:534),
Untuk
menentukan sebuah organisasi file yang efisien untuk setiap relasi dasar (based relation).
Langkah 4.3 Pemilihan Index Menurut
Connolly
menentukan
apabila
dan
Begg
(2010:535),
menambahkan
indeks
Untuk akan
meningkatkan kinerja sistem. Salah satu pendekatan untuk memilih organisasi file yang sesuai untuk relasi adalah untuk menjaga tuple unordered dan membuat banyak indeks sekunder yang diperlukan. Pendekatan lain adalah untuk mengurutkan tuple dalam relasi dengan menentukan indeks utama atau pengelompokan. Dalam hal ini, pemilihan atribut untuk pemesanan atau pengelompokan
55 tuple
antara
lain:
1. Atribut yang paling sering digunakan untuk bergabung dengan operasi, karena hal tersebut membuat operasi yang bergabung berjalan lebih efisien.
2.
Atribut
yang
paling
sering
digunakan
untuk
pengaksesan tuple dalam suatu relasi dalam urutan atribut.
Langkah 4.4 Pengestimasian Jumlah Kapasitas Disk Menurut
Connolly
dan
Begg
(2010:541),
Untuk
memperkirakan jumlah ruang disk yang akan dibutuhkan oleh basis data.
Langkah 5 Membuat User Interface Menurut Connolly dan Begg (2010:542), Untuk merancang user view yang telah diidentifikasi selama persyaratan pengumpulan dan analisis tahap pengembangan DBLC (database lifecycle).
Tujuan dari langkah ini adalah untuk merancang user view yang diidentifikasi sebelumnya. Dalam DBMS pada komputer, user view yang baik didefinisikan untuk menyederhanakan permintaan basis data. Namun, dalam DBMS multi-user user view memainkan peran tengah dalam mendefinisikan struktur basis data dan menegakkan sekuriti.
Langkah 6 Membuat Mekanisme Security Menurut Connolly dan Begg (2010:542), Langkah ini bertujuan untuk merancang mekanisme keamanan untuk basis data sesuai yang ditentukan oleh pengguna selama tahap persyaratan dan koleksi DBLC.
56 DBMS relasional umumnya menyediakan dua jenis keamanan database di antaranya: 1. System security System security meliputi akses dan penggunaan database pada tingkat sistem, seperti nama pengguna dan kata sandi 2. Data security Data security meliputi akses dan penggunaan objek database (seperti sebagai relationship dan view) dan tindakan yang pengguna miliki pada objek.
2.1.6 Tools yang Digunakan 2.1.6.1 DFD (Data Flow Diagram) Menurut Whitten dan Bentley (2007:317), DFD adalah sebuah diagram yang menggambarkan aliran data melalui sistem dan kinerja, pengolahan yang dilakukan oleh sistem tersebut. Hanya ada tiga simbol dan satu koneksi: Simbol
Keterangan Kotak mewakili agen-eksternal batas sistem
Menggambarkan proses atau pekerjaan yang harus diselesaikan
57 Menggambarkan aliran data atau input/output dari dan menuju proses
Menggambarkan penyimpanan data atau disebut data store.
Gambar 2.5 Data Flow Diagram Jenis tingkatan data flow diagram (DFD) 1. Diagram konteks (level 0) merupakan sebuah proses yang berada di posisi pusat. 2. Diagram nol (level 1) merupakan sebuah proses yang terdapat di level 0 yang dipecahkan menjadi beberapa proses lainnya. 3. Diagram rinci (level 2). Pada level ini merupakan diagram yang merincikan diagram nol.
2.1.6.2 Flowchart Menurut Romney dan Steinbart (2006:70) flowchart adalah teknik analisis yang menjelaskan aspek-aspek dalam sistem informasi secara singkat, jelas dan logis. Flowchart menggunakan kumpulan simbol umum untuk menggambarkan prosedur proses transaksi yang digunakan suatu perusahaan serta aliran data pada sistem.
Simbol
Nama
Fungsi
Terminal
Menandakan awal dan akhir atau interupsi.
Input / Output
Merepresentasikan input atau output data atau informasi yang diproses.
58 Anak Panah
Merepresentasikan alur atau arah aliran pemrosesan atau dokumen.
On-Page Connector
Menghubungkan aliran proses dalam satu halaman.
Off-Page Connector
Menghubungkan aliran proses dengan halaman lain.
Keputusan
Merepresentasikan tahapan pembuatan keputusan dengan adanya alternatif aliran proses data
Proses
Merepresentasikan proses.
Dokumen
Merepresentasikan dokumen atau laporan yang tertulis tangan atau hasil print dari komputer.
Manual Operation
Merepresentasikan sebuah proses yang dilakukan secara manual.
Gambar 2.6 Flowchart 2.2 Teori yang Terkait 2.2.1 Internet Menurut Connolly dan Begg (2010:1024), internet merupakan koleksi di seluruh dunia jaringan komputer yang saling berhubungan. Internet terdiri dari banyak jaringan yang terpisah tetapi saling berhubungan milik komersial, organisasi pendidikan dan pemerintah, dan Internet Service Provider (ISP).
59 Layanan yang ditawarkan di Internet antara lain surat elektronik (e-mail), konferensi dan layanan obrolan, mengirim dan menerima file. 2.2.2 The Webs Menurut Connolly dan Begg (2010:1028), the webs merupakan sebuah sistem berbasis hypermedia yang menyediakan sarana informasi browsing di internet dengan cara non-sekuensial menggunakan hyperlink. Webs yang menyediakan point dan click dapat diartikan sebagai cara menjelajahi halaman informasi dalam jumlah besar yang berada di internet. Informasi di web disajikan pada halaman web, yang muncul sebagai kumpulan teks, grafik, gambar, suara, dan video. 2.2.3 HTTP Menurut Connolly dan Begg (2010:1029), HyperText Transfer Protocol (HTTP) mendefinisikan bagaimana client dan server berkomunikasi dan merupakan object-oriented dan protokol untuk mengirimkan informasi antara server dan klien. HTTP didasarkan pada paradigma permintaan-respon. Transaksi HTTP terdiri dari tahapan sebagai berikut: • Connection - client melakukan koneksi dengan server web. • Request - client mengirimkan pesan permintaan ke server web. • Response - web server mengirimkan respon (misalnya, dokumen HTML) ke client. • Close - Sambungan akan terputus oleh server web. 2.2.4 Uniform Resource Locators Menurut Connolly dan Begg (2010:1033), Uniform Resource Locators (URL) mendefinisikan secara unik di mana dokumen (sumber) dapat ditemukan di Internet. Uniform Resource Identifiers (URI) merupakan kumpulan semua nama / alamat secara generik yang merujuk ke internet resources.
60 2.2.5 HyperText Markup Language Menurut Connolly dan Begg (2010: 1031), HyperText Markup Language (HTML) adalah sebuah system untuk menandakan sebuah dokumen yang dipublikasikan pada web. HTML menentukan apa yang dikirim antara nodes dengan
network.
Simpel
tetapi
sangat
mempunyai
pengaruh.
HTML
dikembangkan pertama kali oleh Tim Berners-Lee saat bekerja pada CERN. HTML telah dikembangkan untuk berbagai macam kebutuhan dan alat-alat untuk dapat menerima berbagai macam informasi pada Web. 2.2.6 CSS Rob Larsen (2013: 192), Cascading Style Sheet atau CSS bekerja dengan cara menggabungkan perintah-perintah dengan elemen-elemen yang akan ditampilkan pada halaman web. Perintah CSS, terbagi menjadi dua: 1. Selector mengidikasikan elemen dari deklarasi yang akan diterapkan. Bisa diterapkan untuk lebih dari satu elemen. 2. Declaration memberikan perintah pada elemen yang dituju oleh selector.
2.2.7 PHP (Hypertext Preprocessor) Menurut Marc Delisle (2012:8), PHP biasanya di install sebagai modul di dalam web server. PHP adalah Bahasa pemrograman yang terkenal dimana aplikasi ditulis untuk berkomunikasi dengan MySQL atau database system lainnya di back end dan pada browser (front end). Ironisnya akronim sudah berevolusi dari sejak pertama kali muncul PHP (Personal Home Page) menjadi Professional Home Page dan sekarang menjadi Hypertext Preprocessor. PHP tersedia pada jutaan web domains dan menjalankan web site terkenal seperti Facebook, Yahoo!, Youtube, dan Wikipedia. Menurut Luke W. dan Laura T. (2008:2) Keunggulan PHP adalah:
61 1. Performa 2. Stabilitas 3. Antar muka untuk banyak system basis data yang berbeda 4. Terpasang library untuk banyak web umum 5. Open Source (gratis) 6. Mudah dipelajari dan digunakan 7. Mendukung penuh terhadap object-oriented 8. Probabilitas 9. Fleksibilitas pendekatan perkembangan 10. Ketersediaan source code 11. Ketersediaan support dan dokumentasi 2.2.8 MySQL Menurut Luke W. dan Laura T. (2008:3, MySQL adalah relational database management system (RDMS) yang sangat cepat dan kuat. MySQL server mengontrol akses data anda untuk memastikan banyak user bisa bekerja secara bersamaan, memberikan akses yang cepat, memastikan hanya user yang mempunyai hak akses yang dapat mengakses database. MySQL adalah multiuser dan multi-thread server sehingga dapat digunakan pada server yang memiliki multi –CPU. MySQL menggunakan SQL (Structured Query Language) yang merupakan standar bahasa query database. Keunggulan MySQL adalah: 1. Performa tinggi 2. OpenSource (gratis) 3. Terstruktur dan mudah dipelajari 4. Portabilitas 5. Ketersediaan source code 6. Ketersediaan support
2.2.9 phpMyAdmin
62 Menurut Marc Delisle (2012:8 ), phpMyAdmin adalah aplikasi web yang ditulis didalam bahasa PHP yang berisi XHTML, CSS, dan JavaScript client code seperti aplikasi web lainnya. Aplikasi ini menyediakan web interface yang lengkap untuk administrasi MySQL database, dan terkenal menjadi program paling dipakai di bidangnya. PhpMyAdmin menawarkan fitur yang mencakup dasar dari MySQL database dan table operations. PhpMyAdmin juga mempunyai internal system yang merawat metadata untuk mendukung fitur yang lebih maju. Terakhir, system administrator dapat mengatur user dan hak akses dari phpMyAdmin. Sangat penting untuk diingat phpMyAdmin mempunyai operasi yang tersedia berdasarkan hak akses dari pengguna pada spesifik MySQL server.
2.2.10 The Waterfall Model Menurut Roger S. Pressman (2010:39) ada saatnya kebutuhan untuk menyelesaikan sebuah masalah sudah cukup dimengerti. Saat aliran pekerjaan dari komunikasi sampai pembuatan dengan cara linear. Situasi ini biasanya dihadapi saat adaptasi atau penambahan pada sistem yang sudah ada harus dibuat. (contohnya adaptasi untuk akuntansi software yang sudah diberikan perintah untuk diganti perubahan peraturan pemerintah). Waterfall juga dapat terjadi untuk membuat program yang baru hanya saja jika kebutuhan sudah didefinisikan dan stabil.
2.2.10.1 Communication Menurut
Roger
S.
Pressman
(2010:39)
dalam
tahap
communication, dikumpulkan persyaratan yang dibutuhkan dalam memulai sebuah projek.
2.2.10.2 Planning
63 Menurut Roger S. Pressman (2010:39) dalam tahap planning, diperkirakan jadwal dan memantau pembuatan aplikasi.
2.2.10.3 Modeling Menurut Roger S. Pressman (2010:39) dalam tahap modeling, dilakukan analisis dan desain aplikasi.
2.2.10.4 Construction Menurut Roger S. Pressman (2010:39) dalam tahap construction, dilakukan proses coding dan test aplikasi.
2.2.10.5 Deployment Menurut Roger S. Pressman (2010:39), deployment berkaitan dengan delivery aplikasi, memberikan support untuk aplikasi yang sudah dibuat, dan menerima feedback dari pengguna aplikasi.
2.2.11 Human Computer Interaction Design Guidelines Menurut Schneiderman (2009:76), terdapat delapan aturan emas yang digunakan dalam merancang sebuah user interface antara lain: 1. Berusaha untuk konsisten, dalam penggunaan warna, font, dan ukuran layout. 2. Memenuhi kebutuhan secara menyeluruh seperti pertimbangan fitur untuk pengguna awam sampai pengguna terlatih. 3. Memberikan umpan balik yang informatif dan memberikan kejelasan dari setiap kegiatan yang dilakukan oleh user. 4. Merancang dialog yang memberikan penutupan (keadaan akhir).
64 5. Memberikan desain sederhana untuk pencegahan kesalahan dan penanganan kesalahan. 6. Memungkinkan user melakukan pembalikan aksi (undo). 7. Mendukung pusat kendali internal, dimana sistem hendaknya mampu membuat user sebagai bagian dari sistem itu sendiri memiliki kebebasan sendiri. 8. Mengurangi beban ingatan jangka pendek, keterbatasan manusia dalam menerima informasi yang terlalu banyak dalam waktu bersamaan yang akan menimbulkan ketidaknyamanan. Karena suatu site harus dibuat sederhana agar tidak membingungkan user dengan informasi yang terlalu banyak.
2.2.12 Sistem Informasi Sekolah Pada sub bab ini, akan dijelaskan tentang bagian dari sistem sekolah. 2.2.12.1 Guru Menurut Kamus Besar Bahasa Indonesia (2008:469), guru adalah orang yang pekerjaannya (mata pencahariannya,
profesinya) mengajar.
Guru
mempunyai tugas diantaranya mengajar materi, mendidik murid, melihat jadwal mengajar serta menilai ulangan dan ujian. 2.2.12.1.1 Mengajar Menurut Kamus Besar Bahasa Indonesia (2008:23), mengajar bisa diartikan memberi pelajaran dan melatih. 2.2.12.1.2 Mendidik Menurut Kamus Besar Bahasa Indonesia (2008:326), mendidik bisa diartikan memelihara dan memberi latihan (ajaran, tuntunan, pimpinan) mengenai akhlak dan kecerdasan pikiran. 2.2.12.1.3 Menilai
65 Menurut Kamus Besar Bahasa Indonesia (2008:963), menilai bisa diartikan memperkirakan atau menentukan nilainya, memberi nilai dan memberi angka. 2.2.12.1.4 Jadwal Menurut Kamus Besar Bahasa Indonesia (2008:555), jadwal bisa diartikan pembagian waktu berdasarkan rencana pengaturan urutan kerja, daftar atau tabel kegiatan atau rencana kegiatan dengan pembagian waktu pelaksanaan yang terperinci.
2.2.12.2 Siswa Menurut Kamus Besar Bahasa Indonesia (2008:1322), siswa adalah murid (terutama pada tingkat sekolah dasar dan menengah) dan pelajar. Murid mempunyai tugas diantaranya belajar, mengerjakan tugas dan ujian, melihat jadwal pelajaran dan ujian serta membayar uang sekolah. 2.2.12.2.1 Belajar Menurut Kamus Besar Bahasa Indonesia (2008:23), belajar bisa diartikan berusaha memperoleh kepandaian atau ilmu, berlatih dan merubah tingkah laku atau tanggapan yang disebabkan pengalaman. 2.2.12.2.2 Mengerjakan Menurut
Kamus
Besar
Bahasa
Indonesia
(2008:681),
mengerjakan bisa diartikan melakukan, melaksanakan, mengusahakan, memperbuat sesuatu dan menyelesaikan. 2.2.12.2.3 Ulangan Menurut Kamus Besar Bahasa Indonesia (2008:1521), ulangan bisa diartikan sesuatu yang diulang, ujian untuk mengetahui kemampuan
66 murid tentang bagian pelajaran yang sudah diajarkan dan kata yang diulang. 2.2.12.2.4 Ujian Menurut Kamus Besar Bahasa Indonesia (2008:1237), ujian bisa diartikan hasil menguji, hasil memeriksa, sesuatu yang dipakai untuk menguji mutu sesuatu (kepandaian, kemampuan, hasil belajar, dll) dan cobaan. 2.2.12.2.5 Membayar Menurut kamus besar Bahasa Indonesia (2008:152), membayar bisa diartikan memberi uang (melunasi utang, untuk pengganti harga barang yang diterima), memenuhi dan menunaikan.
2.2.12.3 Administrator Menurut kamus besar Bahasa Indonesia (2008:11), administrator bisa diartikan direktur perusahaan, pengurus, pengusaha atau pembesar setempat, orang
yang
mempunyai
kemampuan
memerintah
yang
sangat
baik.
Administrator atau admin mempunyai tugas diantaranya mengatur semua jalannya sistem informasi sekolah SMPN 229. 2.2.12.3.1 Mengatur Menurut kamus besar Bahasa Indonesia (2008:99), mengatur bisa diartikan membuat (menyusun) sesuatu menjadi teratur (rapi), mengurus, dan menyusun. 2.2.12.4 Orang Tua Menurut kamus besar Bahasa Indonesia (2008:987), orang tua bisa diartikan ayah ibu kandung, orang yang dianggap tua, dan orang yang dihormati.
67
2.3 Hasil Penelitian atau Produk Sebelumnya 2.3.1 SMA Bukit Sion Metode penelitian yang digunakan meliputi: 1. Metode analisis Metode analisis yang digunakan dalam penelitian ini meliputi studi pustaka, serta studi lapangan untuk pengumpulan data dengan teknik pengamatan, wawancara serta kuesioner. 2. Metode perancangan Metode perancangan terdiri dari dua yaitu perancangan basis data dan perancangan aplikasi.Perancangan basis data ini meliputi perancangan konseptual, perancangan logikal, perancangan fisikal kemudian melakukan perancangan aplikasi dengan membuat user interface dan program aplikasi yang digunakan untuk memproses basis data. Bahasa pemrograman yang digunakan adalah PHP, HTML, CSS dan JavaScript. 3. Fitur yang ada pada aplikasi ini diantaranya: a. Halaman fitur yang disediakan untuk admin: •
Class: admin dapat menambahkan tahun ajaran baru, melihat dan mengatur daftar kelas pada tahun ajaran yang sedang berlangsung, dan melakukan penambahan kelas baru.
•
Student: admin dapat melihat dan mengatur daftar siswa/i dan menambahkan data siswa/i baru.
•
Teacher: admin dapat melihat dan mengatur data guru dan menambahkan data guru baru.
•
Schedule: admin dapat melihat dan mengatur jadwal kegiatan belajar.
•
Exam: admin dapat melihat dan mengatur jadwal ujian dari tiap kelas.
68 •
Announcement: admin dapat melakukan insert dan update mengenai informasi sekolah.
b. Halaman menu yang disediakan untuk guru: •
Teaching Schedule: guru dapat melihat jadwalnya mengajar dan melihat data siswa/i dari kelas yang diajarnya.
•
Material: guru dapat melihat dan mengatur material yang sudah diberikan serta membuat material baru.
•
Score: guru dapat menginput hasil nilai ujian siswa/i kemudian mendownload hasil nilai yang telah diinput.
•
Announcement: guru dapat melihat pengumuman mengenai sekolah.
c. Halaman menu yang disediakan untuk siswa/i: •
My Class: siswa/i dapat melihat jadwal pelajaran dan material dari tiap mata pelajaran.
•
Exam Schedule: siswa/i dapat melihat exam schedule yang akan dilaksanakannya.
•
Exam Score: siswa/i dapat melihat exam score dan history exam score yang diperolehnya.
•
Announcement: siswa/i dapat melihat pengumuman mengenai sekolah.
d. Halaman menu yang disediakan untuk orangtua: •
Class: orangtua dapat melihat jadwal pelajaran dan material dari tiap mata pelajaran anaknya.
•
Exam Schedule: orangtua dapat melihat exam schedule yang akan dilaksanakan anaknya.
•
Exam Score: orangtua dapat melihat exam score dan history exam score yang diperoleh anaknya.
•
Announcement: orangtua dapat melihat pengumuman mengenai sekolah.
69 2.3.2 SMA Negeri 90 Metode penelitian yang digunakan adalah metode analisis. Metode analisis dilakukan dengan cara pengumpulan data dan informasi secara langsung pada SMAN 90 Jakarta, dilakukan dengan melakukan wawancara kepada bagian – bagian yang terlibat dalam pengerjaan proyek yang bertujuan untuk mengetahui kebutuhan dari pihak SMAN 90 Jakarta dan mengetahui sistem yang sedang berjalan. Bahasa pemrograman yang digunakan adalah HTML dan PHP. Fitur yang ada pada aplikasi ini diantaranya: 1. Penjadwalan Merupakan proses penyusunan jadwal berupa jadwal pelajaran dan jadwal ujian untuk kelas 10, 11, dan 12 yang disesuaikan dengan jadwal guru yang bersangkutan, ruang yang digunakan, mata pelajaran yang diajarkan, dan shift setiap mata pelajaran untuk masing masing kelas.
2. Penilaian Proses penilaian yang dilakukan meliputi nilai tugas, ulangan harian, UTS , UAS dan praktikum yang dilakukan oleh guru mata pelajaran yang bersangkutan. Siswa/i dapat melihai nilai mereka yang sudah dimasukkan oleh guru pada tiap mata pelajaran.
3. Absensi Proses absensi merupakan proses pencatatan kehadiran siswa baik sakit, izin maupun tanpa keterangan yang dilakukan oleh sekretaris masing – masing kelas yang akan direkap oleh guru piket dan akan diserahkan oleh bidang kesiswaan.
4. Penyusunan program belajar Penyusunan program belajar dilakukan oleh masing – masing guru tiap semester berdasarkan silabus yang sudah tersedia dan disesuaikan dengan jadwal pada kalender akademik.
70 2.3.3 Analisis dan Perancangan Sistem Aplikasi Basis Data Untuk Layanan Murid Secara Online pada SMA Negeri 61 Jakarta
Metode penelitian yang digunakan adalah: 1.
Metode analisis yang digunak an untuk mengumpulkan data dari SMA Negeri 61 Jakarta. Metode analisis yang digunakan adalah survei langsung, studi pustaka, dan wawancara.
2.
Metode perancangan menggunakan model konseptual, logikal, dan fisikal, b eserta
merancang
tampilan
pengguna,
mekanisme
keamanan,
dan
mempertimban gakan p engenalan atas redudansi. Bahasa pemrograman yang digunakan adalah HTML dan PHP. 3. Fitur yang ada pada aplikasi ini diantaranya: 1. Perancangan aplikasi layanan siswa yang meliputi: a. Melihat pengumuman mengenai kurikulum dan pembelajaran siswa b. Melihat nilai siswa
2. Perancangan sistem administrasi bagi siswa yang meliputi: a. Melihat status bayaran SPP per bulan b. Melihat tunggakan keuangan siswa c. Melihat absensi siswa
3. Perancangan sistem layanan sekolah bagi guru meliputi: a. Melihat jadwal mengajar guru b. Mengentry nilai siswa
4. Perancangan sistem administrasi bagi kepala sekolah meliputi: a.
Membuat dan mengatur pengumuman, absensi, serta informasi
terkait guru dan siswa
