1 BAB 2 LANDASAN TEORI 1 1.1 Sistem Sistem adalah
advertisement
BAB 2 LANDASAN TEORI 1.1 Sistem Sistem adalah sekumpulan komponen yang saling terhubung, terkait, saling mendukung satu dengan yang lain untuk mencapai suatu tujuan yang efektif dan efisien. Didukung juga dari beberapa ahli mengenai pengertian sistem, yaitu Satzinger, Jackson, dan Burd (2010, p6), sistem adalah kumpulan dari komponen yang saling berhubungan dan berfungsi bersamaan untuk memperoleh hasil akhir. O'Brien dan Marakas (2010, p26), sistem adalah sekumpulan elemen yang saling berhubungan dengan batas yang jelas dan bekerja bersama mencapai suatu tujuan dengan menerima input serta menghasilkan output dalam suatu proses transformasi yang teratur. Dalam perusahaan diperlukan integrasi dari sistem informasi dalam jumlah yang besar agar dapat mendukung bisnis perusahaan (Wing, 2007, p 1). Menurut O'Brien dan Marakas (2010, p26), sistem memiliki tiga fungsi dasar, yaitu: 1. Input melibatkan elemen yang saling terhubung yang akan diproses oleh sistem. Misalnya data, keyboard, mouse, monitor, dll. 2. Processing melibatkan proses transformasi yang mengubah input menjadi output. Misalnya software, dll. 3. Output melibatkan proses transfer elemen-elemen yang telah diproses transformasi sehingga menghasilkan tujuan akhir. Misalnya printer, monitor, dll. 1.2 Basis Data (Database) Basis data adalah kumpulan data yang terstruktur yang dapat digunakan untuk mendapatkan informasi sesuai dengan kebutuhan organisasi. Basis data menurut O'Brien dan Marakas (2010, p173), yaitu adalah koleksi yang terpadu yang secara logis 6 7 terkait dengan elemen data. Dari kutipan jurnal Widhyaestoeti (2011, p3), database merupakan tempat penyimpanan data yang dapat menampung satu atau lebih tabel dan kueri. Basis data yang diperlukan oleh sistem harus dirancang terlebih dahulu, perancangan basis data yang lengkap dan efisien dalam penggunaan ruang penyimpanan, cepat dalam pengaksesan dan mudah dalam pemanipulasian data. Untuk membuat sebuah database tidak perlu terlihat kompleks, melainkan hanya perlu menyediakan sebuah metode organisasi, akses yang mudah ke data yang tersimpan dalamnya, dapat dilindungi dari pengguna yang tidak sah. Sedangkan menurut Satzinger, Jackson, dan Burd (2010, p11), database adalah sekumpulan data terpusat yang dikelolah dan dapat diakses oleh banyak pengguna dan sistem pada saa t yang sama. Basis data merupakan kumpulan data dan deskripsinya yang secara logika terkait satu sama lain, dirancang untuk menemukan informasi yang dibutuhkan organisasi tersebut (Connolly dan Begg 2010, p65). Data yang disimpan dalam suatu database biasanya menyimpan informasi dari puluhan maupun ratusan tipe entitas atau class. Sehingga untuk mengelolah dan mengendalikannya harus dibutuhkan Database Management System (DBMS). 2.2.1 DBMS (Database Management System) Menurut Connolly dan Begg (2010, p66), DBMS adalah sebuah sistem perangkat lunak yang dapat diakses oleh pengguna untuk mengidentifikasi, menciptakan, memperbaiki, dan mengontrol basis data. Untuk menghubungkan program aplikasi users dengan database maka digunakan Database Management System (DBMS). Pada dasarnya, DBMS menyediakan beberapa fasilitas, yaitu: 8 Data Definition Language (DDL) Data Definition Language (DDL) adalah memungkinkan pengguna mendefinisikan database untuk menentukan jenis data, struktur data dan kendala pada data yang akan disimpan dalam database. Pernyataan yang ada pada DDL yaitu: CREATE SCHEMA DROP SCHEMA CREATE DOMAIN ALTER DOMAIN DROP DOMAIN CREATE TABLE ALTER TABLE DROP TABLE CREATE VIEW DROP VIEW Data Definition Language (DDL) tidak dapat digunakan untuk memanipulasi data. Pernyataan tersebut digunakan untuk membuat, mengubah, dan menghancurkan struktur yang membentuk skema konseptual. 1. Data Manipulation Language (DML) Data Manipulation Language (DML) adalah memungkinkan pengguna untuk memanipulasi (insert, update, delete dan select) data dari database. DML menyediakan fasilitas umum untuk menyelidiki data yang disebut dengan bahas query. Bahasa query yang umum adalah SQL (Structured Query Language). Pernyataan yang ada pada DML yaitu: SELECT, digunakan untuk memanggil data di dalam tabel. pernyataannya berupa “SELECT * FROM [table]” INSERT, digunakan untuk memasukkan data ke dalam tabel. Pernyataannya berupa “INSERT INTO [table] VALUES(‘nilai’, ‘.....’)” Contoh dalam menggunakan statement INSERT: 9 Tabel 2.1 Contoh tabel pelanggan sebelum dilakukan insert custName custAddress custPhone custGender John Street New 69-394812 Male City no 34 C002 Berry Street Bridge 65-298472 Female Stone no5 “INSERT INTO table_Customer VALUES(‘C003’, ‘Michael’, ‘Street Mona no custID C001 134’, ’91-235431’, ‘Male’)” custID C001 C002 C003 Tabel2.2 Contoh tabel pelanggan setelah dilakukan insert custName custAddress custPhone custGender John Street New 69-394812 Male City no 34 Berry Street Bridge 65-298472 Female Stone no5 Michael Street Mona 91-235431 Male no 134 UPDATE, digunakan untuk mengubah data pada tabel. Statement UPDATE berupa “UPDATE SET ([nama kolom] = ‘nilai’, [nama kolom]=’nilai’)” Contoh dalam menggunakan statement UPDATE: Tabel 2.3 Contoh tabel pelanggan sebelum dilakukan update custName custAddress custPhone custGender John Street New 69-394812 Male City no 34 C002 Berry Street Bridge 65-298472 Female Stone no5 C003 Michael Street Mona 91-235431 Male no 134 “UPDATE SET(custID=‘C002’, custName=‘Berry’, ‘Street Stone Cold no 5’, custID C001 custPhone=’65-298472’, custGender=‘Female’) FROM table_Customer WHERE custID = C002” custID C001 C002 Tabel 2.4 Contoh tabel pelanggan setelah dilakukan update custName custAddress custPhone custGender John Street New City no 69-394812 Male 34 Berry Street Stone Cold 65-298472 Female no5 10 C003 Michael Street Mona no 134 91-235431 Male DELETE, digunakan untuk menghapus data dari tabel. Statement DELETE berupa “DELETE [nilai] FROM [nama tabel]” Contoh dalam menggunakan statement DELETE: Tabel 2.5 Contoh tabel pelanggan sebelum dilakukan delete custName custAddress custPhone custGender John Street New 69-394812 Male City no 34 C002 Berry Street Bridge 65-298472 Female Stone no5 C003 Michael Street Mona 91-235431 Male no 134 “DELETE C001 FROM table_Customer” custID C001 custID C002 C003 Tabel 2.6 Contoh tabel pelanggan setelah dilakukan delete custName custAddress custPhone custGender Berry Street Bridge 65-298472 Female Stone no5 Michael Street Mona 91-235431 Male no 134 2. Menyediakan akses terkontrol ke database, yaitu: - Security system, yang mencegah pengguna yang tidak sah untuk mengakses database. - Integrity system, yang menjaga konsistensi data yang tersimpan. - Concurrency control system, yang memungkinkan berbagi akses database. - Recovery control system, yang mengembalikan data database ke keadaan yang konsisten sebelumnya setelah kegagalan hardware dan software. - User-accessible catalog, yang berisikan deskripsi data dalam database. Ada lima komponen utama dalam lingkungan DBMS, yaitu : Gambar 2.1 Lingkungan komponen Database Management System 11 (Sumber : Connolly dan Begg (2010, p68)) 1. Hardware Sebuah DBMS dan aplikasi membutuhkan hardware untuk menjalankannya. Hardware dapat dikisarkan dari komputer tunggal ke mainframe tunggal atau jaringan komputer. Hardware khusus tergantung pada kebutuhan organisasi dan DBMS yang digunakan. 2. Software Perangkat lunak berupa DBMS, aplikasi program itu sendiri, bersama dengan operating system (OS), termasuk dengan jaringan perangkat lunak apabila DBMS digunakan melalui jaringan. Biasanya, aplikasi program ditulis dalam bahasa pemrograman generasi ketiga seperti C, C++, C#, Java, Visual Basic dan lain-lain. 3. Data Mungkin komponen yang paling penting dari DBMS dan pastinya dari pandangan pengguna akhir adalah data. Data merupakan jembatan penghubung antara komponen mesin dan komponen manusia. Sebuah database berisi data operasional dan metadata. 4. Procedures Prosedur lebih kepada instruksi atau aturan yang mengatur desain dan penggunaan dalam database. Pengguna sistem dan staff yang mengatur database memerlukan prosedur yang terdokumentasi untuk menjalankan sistem, seperti: - Cara masuk ke dalam DBMS. - Menggunakan fasilitas DBMS tertentu atau aplikasi program. - Memulai dan menghentikan DBMS. - Membuat back up dari database. - Menangani kesalahan dari hardware atau software. 12 - Merubah struktur dari tabel, mengorganisir ulang database, meningkatkan kinerja, atau mengarsipkan data ke dalam secondary storage. 5. People Komponen terakhir adalah orang-orang yang terlibat dengan sistem. Orang yang terlibat dengan sistem dapat didefinisikan dengan empat tipe dan memiliki tanggung jawab sendiri, yaitu: - Data and Database Administrators Data administrators bertanggung jawab dalam pengelolaan sumber data, termasuk perencanaan database, pengembangan dan pemeliharaan yang standar, kebijakan dan prosedur, konseptual dan logikal desain database. Database administrators bertanggung jawab dalam realisasi fisik database termasuk fisik disain database dan pengimplementasian, keamanan dan integritas kontrol, pemeliharaan operational system (OS) dan menjamin kinerja aplikasi yang memuaskan bagi pengguna. - Database Designers Logical database designers yang bertanggung jawab dalam mengidentifikasi data, hubungan antar data, dan kendala pada data yang akan disimpan dalam database Physical database designers yang bertanggung jawab dalam menentukan bagaimana logical database design direalisasikan. - Application Developers Program aplikasi yang fungsionalitas sesuai dengan yang diinginkan end-user harus dilakukan dan itu merupakan tanggung jawab Application developers. - End-Users 13 End-user adalah klien database yang telah dirancang dan diimplementasikan dan diperbaiki untuk melayani kebutuhan informasi mereka. 14 2.2.1.1 Fungsi DBMS Menurut Connolly dan Begg (2010, p99), database management system (DBMS) memiliki banyak fungsi, yaitu: - Data Storage, Retrieval, and Update Sebuah DBMS dapat menyediakan kemampuan untuk menyimpan data, mengambil data, dan meng-update data, karena ini merupakan fungsi dasar yang harus dimiliki oleh DBMS. - A user-Accessible Catalog Catalog system atau data dictionary, merupakan gudang information yang menggambarkan data dalam database. Sebuah DBMS harus dapat menyediakan catalog sistem yang menyimpan tentang deskripsi item sehingga memudahkan pengguna untuk mengaksesnya. - Transaction Support Transaksi adalah serangkaian tindakan yang dilakukan oleh pengguna individu atau program aplikasi yang mengubah isi database. Sehingga dengan ini, DBMS harus dapat menyediakan sebuah mekanisme untuk memastikan bahwa semua update transaksi sesuai dengan transaksi yang diberikan. - Concurrency Control Services Pengguna yang mengakses database dan melakukan update secara bersamaan akan mengganggu sistem atau akan muncul sebuah gagal sistem sehingga ada data yang hilang atau bahkan terjadi tidak konsistensi data. Sehingga dengan ini, DBMS harus dapat menyediakan sebuah mekanisme untuk memastikan bahwa database ter-update dengan benar saat beberapa pengguna melakukan update secara bersamaan. 15 - Recovery Services Kerusakan sistem bisa saja terjadi seperti crash, media failure, dan error pada hardware dan software sehingga transaksi yang direkam saat itu juga ikut hilang. Sehingga dengan ini, DBMS harus dapat menyediakan sebuah mekanisme untuk memulihkan database saat kerusakan sistem terjadi. Authorization Services Tidaklah sulit untuk membayangkan contoh dimana ingin mencegah data yang disimpan dalam database dari pengguna yang tidak sah. Sebagai contoh seorang manager cabang hanya dapat melihat informasi gaji yang berhubungan dengan staff yang di cabang tersebut. Untuk mencegah penyalahgunaan akses, maka DBMS harus dapat memastikan bahwa hanya pengguna sah yang dapat mengakses database. - Support for Data Communication Kebanyakan pengguna mengakses database dari workstations. Workstation berkomunikasi dengan komputer hosting DBMS melalui jaringan dan dengan cara yang sama DBMS merespon. Semua pengiriman ini ditangani oleh data communication manager (DCM). Sehingga dengan ini, DBMS harus mampu mengintegrasikan dengan perangkat lunak komunikasi. - Integrity Services Integritas database mengacu pada kebenaran dan konsistensi data yang disimpan. Hal tersebut juga dapat dianggap sebagai perlindungan database. Namun hal itu memiliki implikasi secara luas. Integritas berhubungan dengan kualitas data itu sendiri. Sehingga integritas itu pada biasanya dianggap sebuah kendala karena konsistensi database tidak boleh dilanggar. Sehingga dengan ini, sebuah DBMS harus dapat menyediakan sarana 16 untuk memastikan bahwa data pada database dan perubahan pada data dapat mengikuti aturan tertentu. - Services to Promote Data Independence DBMS harus mencakup fasilitas untuk mendukung keterbatasan program dari struktur database yang sebenarnya. Data independence biasanya dicapai melalui sebuah view atau mekanisme subskema. Physical data independence lebih mudah untuk dicapai karena terdapat beberapa jenis perubahan yang dapat dibuat untuk karakteristik fisikal dari database tanpa mempengaruhi view. Bagaimanapun data independence logikal yang lengkap lebih susah untuk dicapai. - Utility Services DBMS harus menyediakan seperangkat layanan utility. Program utility membantu DBA mengelola database secara efektif. Beberapa utility bekerja di tingkat external, sehingga dapat di produksi oleh DBA. Utility lain bekerja di tingkat internal sehingga hanya bisa diberikan oleh vendor DBMS. 2.2.1.2 Keuntungan DBMS Menurut Connolly dan Begg (2010, p77), database management system (DBMS) memiliki banyak keuntungan, yaitu: - Control of Data Redundancy Pengontrolan terhadap data yang redundansi dilakukan dengan mengintegrasikan file sehingga beberapa salinan yang sama tidak tersimpan. Data yang duplikat tidak langsung dimusnahkan, namun dikontrol sehingga jumlah duplikat data yang melekat dalam database tidak banyak. - Data Consistency 17 Menghilangkan redundansi data yaitu mengurangi resiko terjadinya tidak konsisten data. Jika item data disimpan lebih dari sekali dan ada sistem yang menyadari hal ini, maka sistem dapat memastikan bahwa semua penyimpanan item data tetap konsisten. Namun banyak DBMS yang tidak menjamin jenis konsistensi tersebut. - More information from the same amount of data Dengan melakukan integrasi data operasional, memungkinkan sebuah perusahaan atau organisasi mendapatkan informasi tambahan dari data yang sama. - Sharing of Data Pada umumnya data dimiliki oleh penggunanya sendiri atau departement tertentu yang menggunakan data tersebut. Di sisi lainnya, database seharusnya milik seluruh organisasi dan dapat digunakan oleh seluruh pengguna resmi, dengan cara ini lebih banyak pengguna berbagi lebih banyak data. - Improved Data Integrity Integritas data merupakan sebuah kendala, kendala ini berlaku bagi untuk item data dalam catatan tunggal. Misalnya kendala integritas bisa menyatakan bahwa gaji seorang staff tidak dapat lebih besar dari Rp 2,2juta. Integrasi memungkinkan database administrator (DBA) untuk mendefinisikan kendala integritas, dan DBMS yang mengatasi hal tersebut. - Improved Security Keamanan database adalah melindungi database dari pengguna yang tidak sah. Tanpa melakukan langkah-langkah keamanan yang sesuai, integrasi dapat membuat data lebih rentan daripada berbasis file sistem. Keamanan database dapat dilakukan dengan memberikan username dan password untuk mengidentifikasi orang-orang yang 18 berwewenang untuk menggunakan database. Pengguna resmi dapat mengakses data sesuai dengan jabatannya dengan dibatasi oleh jenis operasi (retrieval, insert, update, delete). - Enforcement of Standards Integrasi memungkinkan DBA untuk mendefinisikan DBMS dengan standar yang dibutuhkan. Standar ini termasuk departemental, organisasi, standar nasional, atau internasional untuk dalam hal-hal seperti format data (untuk memfasilitasi pertukaran data antar sistem), konvensi penamaan, standar dokumentasi, prosedur update, dan aturan akses. - Economy of Scale Menggabungkan semua data operasional organisasi ke dalam satu database dan membuat satu set aplikasi yang bekerja pada salah satu sumber data yang dapat menghasilkan penghematan biaya. - Balance of Conflicting Requirement Setiap pengguna atau departemen memiliki kebutuhan yang mungkin bertentangan dengan kebutuhan pengguna lain. Karena database berada dibawah kendali DBA, DBA dapat membuat keputusan tentang penggunaan design dan operasional dari database yang menyediakan penggunaan terbaik sumber daya bagi organisasi secara keseluruhan. - Improved Data Accessiblity and Responsiveness DBMS menyediakan bahasa query atau laporan yang digunakan oleh end-user untuk mengajukan pertanyaan dan memperoleh informasi yang diperlukan diterminal mereka, tanpa memerlukan programmer untuk menulis pada beberapa perangkat lunak dan mengekstrak informasi dari database. - Increased Productivity DBMS banyak menyediakan lingkungan generasi keempat, yang terdiri dari alat-alat untuk menyederhanakan pengembangan aplikasi database. Hasilnya yaitu meningkatkan 19 produktifitas programmer dan mengurangi waktu pengembangan (dengan penghematan biaya yang terkait). - Improved Maintenance Through Data Independence DBMS memisahkan deskripsi data dari aplikasi, sehingga membuat kekebalan aplikasi untuk mengubah dalam deskripsi data, dan ini dikenal sebagai independensi data. Penyediaan independensi data berguna untuk menyederhanakan pemeliharaan aplikasi database. - Increased Concurrency Dalam beberapa sistem database, jika dua atau lebih user diizinkan untuk mengakses data yang sama secara bersamaan, ada kemungkinan bahwa akses tersebut mengakibatkan error (hilangnya informasi atau bahkan hilangnya integritas database) yang mengganggu satu sama lain. Fungsi DBMS yaitu mengelola akses database secara bersamaan dan memastikan masalah yang mungkin muncul tidak akan terjadi. - Improved Backup and Recovery Services Banyak sistem database melibatkan pengguna untuk melindungi data dari masalah kegagalan sistem atau program aplikasi dengan melakukan backup. Sehingga saat terjadi kegagalan pada hari berikutnya, data backup dapat digunakan. Pekerjaan yang telah dilakukan saat sebelum terjadinya kegagalan sistem juga ikut hilang sehingga data harus dimasukan ulang. Sebaliknya dengan DBMS, menyediakan fasilitas untuk meminimalkan jumlah data yang hilang setelah terjadinya kegagalan. 2.2.1.3 Kerugian DBMS Menurut Connolly dan Begg (2010, p80), database management system (DBMS) memiliki banyak kerugian, yaitu: - Complexity 20 Ketentuan fungsi DBMS yang baik membuat DBMS menjadi bagian yang sangat komplek dari perangkat lunak. Hal ini perlu dipahami oleh database designer, pengembang data, database administrator, dan pengguna akhir untuk mengambil keuntungan penuh. Kegagalan dalam memahami sebuah sistem dapat berpengaruh buruk pada pengambilan keputusan dan menjadi konsekuensi serius bagi suatu organisasi. - Size Kompleksitas dan luasnya dari fungsionalitas membuat DBMS menjadi bagian yang sangat komplek dari perangkat lunak, sehingga DBMS menempati ruang disk yang sangat besar dan membutuhkan sejumlah besar memori untuk menjalankannya secara efisien. - Cost of Database Management Systems Biaya DBMS bisa bervariasi, karena biaya-biaya tersebut tergantung dengan lingkungan dan fungsi yang disediakan. Beberapa contoh, sebuah DBMS single-user untuk komputer pribadi hanya seharga $100. Namun, bagaimana dengan sebuah mainframe besar DBMS multi-user yang melayani ratusan pengguna? bisa saja harga sekitar $100,000 bahkan $1,000,000. Selain biaya DBMS ada juga biaya perawatan pertahun yang pada biasanya dihitung dari persentase dari harga daftar. - Additional Hardware costs Persyaratan penyimpanan untuk DBMS dan database memerlukan penambahan ruang penyimpanan terus menerus untuk mencapai kinerja yang maksimal. Sebuah perusahaan mungkin saja membeli mesin yang lebih besar, bahkan sebuah mesin yang didedikasikan untuk menjalankan DBMS. Pengadaan hardware ini merupakan tambahan pengeluaran bagi sebuah perusahaan atau organisasi. - Cost of Conversion 21 Dalam beberapa situasi, biaya DBMS dan tambahan hardware mungkin relatif kecil dibandingkan dengan biaya konversi aplikasi yang ada yang kemudian dijalankan pada DBMS dan hardware yang baru. Biaya konversi ini juga mencakup pelatihan staff untuk menggunakan sistem baru serta merupakan biaya bagi kerja staff ahli untuk membantu proses konversi. Alasan utama mengapa beberapa organisasi atau perusahaan merasa terikat pada sistem lama dan tidak berahli ke teknologi database yang modern karena faktor biaya yang besar. - Performance Pada umumnya, sistem database ditulis pada aplikasi tertentu. Sehingga kinerja aplikasinya sangat baik, namun beda dengan DBMS yang ditulis lebih umum, untuk melayani banyak aplikasi dan bukan hanya satu. Hasilnya bahwa beberapa aplikasi tidak dapat berjalan secepat dulunya. - Greater Impact of a Failure Sentralisasi sumber daya karena semua pengguna dan aplikasi bergantung pada ketersediaan DBMS mengakibatkan kerentanan sistem. Kegagalan komponen tertentu dapat berakibat pada operasi sistem menjadi berhenti. 22 2.2.1.4 Komponen DBMS (Database Management System) Gambar 2.2 Komponen Database Management System (Sumber : Connolly dan Begg (2010, p128)) Menurut Connolly dan Begg (2010, p127), komponen-komponen dari DBMS meliputi : - Query processor Query processor merupakan komponen utama dari DBMS yang mengubah query kedalam bentuk sederetan intruksi tingkat rendah yang ditujukan langsung ke database manager. - Database Manager 23 Database manager menghubungkan program aplikasi user-submitted dan query. Database manager menerima query dan memeriksa skema eksternal dan konseptual untuk menentukan record konseptual seperti apa yang diperlukan untuk memenuhi permintaan. - File manager File manager memanipulasi penyimpanan file dan mengatur penempatan tempat penyimpanan dalam disk. Komponen ini mendirikan dan memelihara daftar struktur dan index yang didefinisikan dalam skema internal. - DML preprocessor Modul ini mengubah pernyataan dari DML yang tertanam dalam program aplikasi ke dalam bentuk fungsi panggilan standar dalam host language. - DDL compiler DDL compiler mengubah pernyataan DDL ke dalam sekumpulan tabel yang berisikan metadata. Tabel ini kemudian disimpan ke dalam katalog sistem dan informasi kendali disimpan ke dalam header dari file data. - Catalog manager Catalog manager mengatur akses dan memelihara katalog sistem. Katalog sistem akan diakses sebagian besar dari komponen DBMS. 2.2.2 Database System Development Lifecycle (DSDL) Dalam pembuatan sistem database penting untuk mengenali bahwa tahap siklus hidup pengembangan sistem database tidak harus berurutan, tetapi harus dilakukan pengulangan tahap melalui umpan balik. Misalnya masalah yang dihadapi selama design database yaitu mengumpulkan persyaratan tambahan dan analisis. Apabila sistem database-nya kecil dan sedikit user-nya maka siklus hidup tidak perlu terlalu komplek, sehingga dapat menghemat waktu dan biaya selama proses pembuatan 24 siklus. Namun, berbeda dengan sistem database yang besar yang mengharuskan ribuan user, ratusan query dan program aplikasi, siklus hidup yang harus dilakukan bisa saja menjadi sangat kompleks. Berikut gambaran kegiatan utama yang terkait dengan setiap tahap siklus hidup pembangunan sistem database secara lebih rinci. 25 Gambar 2.3 Database System Development Lifecycle (Sumber : Connolly dan Begg (2010, p314)) 26 2.2.2.1 Database Planning Perencanaan basis data merupakan tahap yang merencanakan bagaimana tahapantahapan dalam lifecycle dapat direalisasikan secara seefisien dan seefektif mungkin. Terdapat tiga hal utama yang terkait dengan strategi sistem informasi, yaitu: - Identifikasi rencana dan tujuan dari perusahaan dengan menentukan kebutuhan sistem informasi perusahaan. - Evaluasi sistem informasi yang ada untuk menetapkan kekuranagan dan kelebihan yang dimiliki. - Penaksiran peluang TI yang mungkin memberikan keuntungan kompetitif. Langkah pertama terpenting dalam perencanaan database adalah mendefinisikan mission statement untuk sistem database dengan jelas. Setelah menentukan mission statement, maka yang harus dilakukan berikutnya adalah mengidentifikasi mission objective. Mission statement merupakan tujuan utama dari aplikasi basis data. Para pengontrol proyek database dalam sebuah organisasi pada biasanya menentukan mission statement terlebih dahulu. Mission statement digunakan untuk membantu dan memperjelas tujuan dari sebuah sistem database selain itu juga menyediakan jalur yang lebih jelas sehingga sistem basis data yang diperlukan lebih efisien dan efektif. Sedangkan mission objective mengidentifikasi tugas-tugas yang harus didukung oleh sistem basis data karena apabila diasumsikan sistem basis data mendukung mission objective, maka mission statement dapat terpenuhi. 2.2.2.2 System Definition Definisi sistem menjelaskan batasan-batasan dan cakupan dari aplikasi basis data dan sudut pandang pemakai yang utama. Sudut pandang pemakai mendefinisikan apa saja yang 27 diperlukan pada aplikasi basis data dari perspektif peran job tertentu atau area aplikasi perusahaan. Identifikasi sudut pandang pemakai penting untuk memastikan tidak ada pemakai utama basis data yang terlupakan ketika pembuatan basis data baru yang dibutuhkan dan membantu pengembangan aplikasi basis data yang rumit atau kompleks. 2.2.2.3 Requirement Collection and Analysis Pada tahap ini menjelaskan pengumpulan dan analisis informasi. Informasi dikumpulkan kemudian dianalisis untuk mengidentifikasi kebutuhan yang akan dimasukan ke dalam sistem basis data yang baru. Pengumpulan dan analisis data merupakan tahap awal untuk mendesain database, jumlah data yang dikumpulkan tergantung pada sifat dari masalah dan kebijakan perusahaan. Informasi yang dikumpulkan pada tahap ini kurang terstruktur dan mencakup beberapa permintaan informal, sehingga informasi tersebut harus diubah menjadi peryataan yang lebih terstruktur. Ada beberapa teknik yang dapat digunakan, antara lain teknik structured analysis and design (SAD), data flow diagrams (DFD), dan hierarchical input process output (HIPO) yang didukung oleh dokumentasi. Selain mengumpulkan dan menganalisis informasi, tahap ini juga memutuskan bagaimana menangani situasi dimana ada lebih dari satu user view dalam sistem basis data. berikut ada tiga pendekatan untuk mengelola sistem basis data dengan dari beberapa user views; 1. The Centralized Approach 2. The View Integration Approach 3. A Combination of Both Approach 28 2.2.2.4 Database Design Menurut Connolly dan Begg (2010, p320), database design adalah suatu proses dalam membuat sebuah design yang akan mendukung visi dan misi perusahaan untuk keperluan sistem database. Dalam bagian ini akan dijelaskan pendekatan design database, ada beberapa pendekatan desain database, yaitu: - Buttom-Up Pendekatan ini dumulai dari tingkat dasar atribut, dimana melalui analisa hubungan antar atribut digabungkan kedalam suatu relasi yang mempresentasikan tipe dari entitas dan hubungan antar entitas. Pendekatan ini sesuai untuk database design yang sederhana. - Top-Down Pendekatan ini digunakan untuk database design yang kompleks. Pada pendekatan ini dimulai dengan pengembangan data models yang mengandung sejumlah entitas dan hubungan tingkat tinggi dan kemudian melakukan top-down terus menerus untuk mengidentifikasi entitas, hubungan dan atribut yang terkait didalamnya dengan tingkat yang lebih rendah. - Inside-Out Pendekatan ini mirip dengan pendekatan bottom-up, tetapi ada perbedaan. Pendetakan terlebih dahulu mengidentifikasi satu kumpulan entitas utama dan kemudian menyebar keluar untuk mempertimbangkan entitas lain, hubungan, dan atribut yang berhubungan dengan yang pertama kali diidentifikasi. - Mixed Strategy Pendekatan ini menggunakan pendekatan bottom-up dan pendekatan top-down untuk berbagai bagian dalam model sebelum menggabungkan semua bagian. 29 Database design terdiri dari tiga tahap utama, yaitu conceptual database design, logical database design, dan physical database design. Ketiga tahap utama tersebut akan dijelaskan pada berikut ini: 2.2.2.4.1 Conceptual Database Design Menurut Connolly dan Begg (2010, p467), conceptual database design adalah proses perancangan sebuah model data yang digunakan perusahaan atau organisasi tanpa pertimbangan fisik. Pertimbangan Fisik antara lain bahasa pemrograman, hardware platform dan lain-lain. Langkah pertama dalam conceptual database design adalah membangun satu atau lebih konseptual data sesuai dengan kebutuhan data perusahaan. Conceptual data model terdiri dari: 1. Entity Types 2. Relationship Types 3. Attributes 4. Primary Keys and Alternate Keys 5. Integrity Constraints Data model didukung oleh dokumen-dokumen yang dapat dihasilkan dari berbagai langkah. Di sini ada beberapa langkah-langkah yang harus dilakukan untuk merancang conceptual database design, yaitu: 1. Identify Entity Types Bertujuan untuk mengidentifikasi entitas utama yang dibutuhkan. Sebuah metode untuk mengidentifikasi entitas adalah dengan memeriksa spesifikasi kebutuhan pengguna. Dari 30 spesifikasi ini, harus mengidentifikasi kata benda atau frase benda. Objek utama berupa orang, tempat, dan konsep yang menarik. - Entity Name Description Entity name : nama entitas Aliases Occurrence - Deskription : mendeskripsikan entitas yang dimaksud - Aliases : nama lain entitas yang dimaksud - Occurrence : kejadian apa yang membuat entitas yang dimaksud ada. 2. Identify Relationship Types Bertujuan untuk mengidentifikasi relationship penting yang terdapat antara entitas yang telah diidentifikasi. Dalam mengidentifikasi relationship dapat menggunakan grammer dari spesifikasi kebutuhan pengguna. Secara khusus, relationship ditandai dengan kata kerja atau eksoresi verbal. - Entity Name Multiplicity Entitas name : nama entitas Relationship Multiplicity Entity Name - Multiplicity : berapa hubungan satu ID entitas terhadap entitas lain - Relationship : hubungan satu entitas dengan entitas lain. 3. Identify and Associate Attributes with Entity or Relationship Types Bertujuan untuk menghubungkan atribut dengan entitas atau relationship yang sesuai. Di sini mdapat menggunakan kata benda atau frase benda sesuai dengan spesifikasi kebutuhan pengguna. Atribut dapat diidentifikasi dimana kata benda atau frase benda merupakan sifat , kualitas, indentifier, dan karakteristik dari entitas atau relationship. Entity name Atribute s Description Data type and length Nulls Multivalue d Derived - Entity name : nama entitas. - Attributes : Atribut yang dimiliki oleh entitas yang dimaksud. - Description : mendeskripsikan atribut yang dimaksud Composite 31 - Data type and length : menentukan tipe data dan panjang karakter atribut yang dimaksud. - Nulls : “NO”, maka atribut yang dimaksud tidak boleh bernilai NULL. “YES”, maka atribut yang dimaksud boleh bernilai NULL. - Multivalued : “NO”, maka atribut yang dimaksud tidak multivalued. “YES”, maka atribut yang dimaksud boleh multivalued. - Derived : “NO”, maka atribut yang dimaksud tidak derived. “YES”, maka atribut yang dimaksud boleh derived. - Composite : “NO”, maka atribut yang dimaksud tidak composite. “YES”, maka atribut yang dimaksud boleh composite. 4. Determine Attribute Domains Bertujuan untuk menentukan domain bagi atribut didalam model data konseptual lokal. Domain merupakan sebuah kolom nilai dari satu atau lebih atribut yang menggambarkan nilai mereka. Entity name Attributes Data type and length Domain Atribut - Entity name : nama entitas. - Attributes : Atribut dari entitas yang dimaksud - Data type and length : menentukan tipe data dan panjang karakter atribut yang dimaksud. - Domain attributes : batasan dari atribut yang dimaksud. Contoh entitas ‘staff’ memiliki domain attributes ‘Range value 0000000000-9999999999, 10 karakter’ 5. Determinte Candidate, Primary, and Alternate Key Attributes Bertujuan untuk mengidentifikasi candidate key bagi setiap entitas dan jika terdapat lebih dari satu candidate key, pilihlah satu untuk dijadikan primary key. Ketika memilih 32 sebuah primary key diantara candidate key, gunakanlah panduan berikut untuk membantu membuat pilihan: - Sebuah candidate key dengan sekelompok atribut yang minim - Sebuah candidate key yang paling sedikit mempunyai perubahan nilai. - Sebuah candidate key dengan karakter paling sedikit (bagi atribut tekstual) - Sebuah candidate key dengan nilai maksimum terkecil (bagi atribut numeric) - Sebuah candidate key yang paling mudah digunakan dari sudut pandang pengguna. Berikut gambaran dan penjelasan pada tabel Determinte Candidate, Primary, and Alternate Key Attributes - Entity Candidate Key Entity : nama entitas. Primary Key Alternate Key - Candidate Key : kumpulan candidate key dari entitas yang dimaksud. - Primary Key : primary key yang ada pada entitas yang dimaksud. Dan pada umumnya satu entitas hanya memiliki satu primary key. - Alternate Key : candidate-candidate key yang bukan primary key. 6. Consider Use of Enchanced Modeling Concepts (Optional Step) Bertujuan untuk mempertimbangkan penggunaan konsep pemodelan lebih lanjut, seperti spesialisasi/generalisasi, agregrasi dan composition. Jika memilih pendekatan spesialisasi, maka harus berusaha untuk memperhatikan perbedaan antara entitas dengan mendefinisikan satu atau lebih entitas superclass. Jika menggunakan pendekatan generalisasi, maka dapat mengidentifikasi fitur umum antara entitas untuk mendefinisikan penggeneralisasian entitas superclass. Menggunakan agregasi untuk menggambarkan relationship mempunyai atau bagian dari antara entitas dimana yang satu menggambarkan keseluruhan dan yang lainya menggambarkan per bagian. Menggunakan composition untuk 33 menggambarkan hubungan antara entitas dimana terdapat hubungan yang sangat erat antara keseluruhan dan bagian. 34 7. Check Model for Redundancy Bertujuan untuk memeriksa keberadaan berbagai pengulangan didalam model. Terdapat dua aktifitas didalam tahap ini yaitu: - Memeriksa kembali relationship one-to-one (1-1) - Menghilangkan relationship yang berulang 8. Validate Conceptual Data Model Against User Transactions Bertujuan untuk memastikan bahwa model konseptual lokal mendukung transaksi yang diperlukan oleh view. Dengan menggunakan model tersebut, maka dapat diusahakan untuk membentuk operasi manual. Jika dapat memecahkan semua transaksi dengan cara ini, kita telah memastikan bahwa model data konseptual mendukung transaksi yang diperlukan. Ada dua pendekatan untuk memastikan bahwa model data konseptual lokal mendukung transaksi yang diperlukan yaitu: - Menjelaskan transaksi - Menggunakan transaksi pathway 9. Review Conceptual Data Model with User Bertujuan untuk me-review model data konseptual lokal dengan pengguna untuk memastikan bahwa model tersebut merupakan gambaran yang sebenarnya dari view. Model data konseptual termasuk ER diagram dan dokumen pendukung lainnya yang menjelaskan model data. Jika terdapat kesalahan didalam model data, maka harus membuat perubahan yang sesuai, yang mungkin memerlukan kembali ke tahap sebelumnya. 2.2.2.4.2 Logical Database Design Menurut Connolly dan Begg (2010, p467), logical database design adalah proses perancangan sebuah model data yang digunakan perusahaan atau organisasi yang 35 berdasarkan pada model data yang spesifik, tetapi tidak tergantung pada DBMS tertentu dan pertimbangan fisik lainnya. Tujuan dari tahap logical database design adalah menerjemahkan data konseptual ke dalam bentuk data logical dan memvalidasi model yang dibuat apakah telah secara struktur benar dan dapat memenuhi serta menyokong transaksi yang ada. Untuk mencapai tujuan tersebut, berikut langkah-langkah yang harus dilakukan : 1. Derive Relations for Logical Data Model Tujuan dari tahap ini adalah untuk membuat relasi bagi model data logikal untuk menunjukkan entitas, relasi, dan atribut yang telah teridentifikasi. Relasi yang dimiliki oleh satu entitas dengan entitas lainnya dapat dilihat melalui adanya primarykey atau foreignkey di dalam entitas. Untuk menentukan peletakan foreignkey, maka terlebih dahulu harus mengidentifikasi entitas parent dan child dari entitas yang bersangkutan dalam satu relasi. Berikut adalah struktur-struktur yang ada dalam sebuah relasi dari model data konseptual : - Strong entity types - Weak entity tyoes - One-to-many (1:*) binary relationship types - One-to-one (1:1) binary relationship types - One-to-one (1:1) recursive relationship types - Superclass/subclass relationship types - Many-to-many (*:*) binary relationship types - Complex realtionship types - Multi-valued attributes 36 2. Validate Relations Using Normalization Tujuan dari tahap ini adalah untuk memvalidasi relasi yang ada pada model data logikal dengan menggunakan tahap normalisasi. Proses dari normalisasi meliputi langkah-langkah yang akan mengecek apakah suatu atribut dari relasi sudah sesuai dengan aturannya. Tahap-tahap normalisai akan dibahas lebih lanjut pada sub bab selanjutnya. 3. Validate Relations againts User Transactions Tujuan dari tahap ini adalah untuk memastikan bahwa relasi yang ada pada model data logikal dapat menyokong kebutuhan dari transaksi. 4. Check Integrity Constraints Tujuan dari tahap ini adalah mengecek apakah integrity constraints telah diwakili dalam model data logikal. Berikut adalah tipe-tipe dari integrity consraints : - Required data - Attributes DOMAIN constraints - Multiplicity - Entity integrity - Referential integrity - General constraints 5. Review Logical Data Model with User Tujuan dari tahap ini adalah memeriksa ulang model data logikal yang dibuat dengan user untuk memastikan model data yang ada telah benar sebagai untuk mewakili kebutuhan dari perusahaan. 37 6. Merge Logical Data Models into Global Mode (optional) Tujuan dari tahap opsional ini adalah untuk menggabungkan model data logikal lokal ke dalam satu model data logikal global yang mempresentasikan semua database. 7. Check for Future Growth Tujuan dari tahap ini adalah untuk menentukan apakah ada perubahan yang signifikan di waktu kedepan yang masih dapat diduga dan menaksirkan apakah model data logikal dapat menampung atau menangani perubahan tersebut. 2.2.2.4.3 Physical Database Design Menurut Connolly dan Begg (2010, p467), physical database design adalah proses menghasilkan deskripsi dalam implementasi database pada penyimpanan sekunder, proses tersebut mendeskripsikan hubungan dasar, pengorganisasian file, dan indeks yang digunakan untuk mencapai akses data yang efisien, dan integritas constraints serta pengukuran kemanan. Secara umum, tujuan dari tahap perancangan database fisikal adalah untuk mendeskripsikan bagaimana cara mengimplementasikan secara fisikal dari model data logical yang telah dirancang. Dalam model relasionalnya akan terlibat : - Membuat sekumpulan hubungan relasional antar tabel dan constraints berdasarkan informasi dari model data logikal. - Mengeidentifikasi struktur penyimpanan yang spesifik dan metode pengaksesan data untuk mencapai performance yang optimum dari database systems. - Merancang proteksi keamanan sistem. Berikut merupakan langkah-langkah yang dilakukan untuk merancang database fisikal : 38 Langkah 3: Menerjemahkan model data logical kedalam DBMS 1. Merancang relasi dasar Tujuan dari tahap ini adalah untuk menentukan bagaimana cara mempresentasikan relasi dasar yang telah diidentifikasikan dalam tahap model data logikal pada DBMS. Setiap relasi dasar yang telah diidentifikasikan dalam tahap model data logical, didefinisikan yang terdiri dari : - Nama dari relasi - Daftar dari atribut dalam kumpulan - Primary key, alternate key, dan foreign key - Batasan integritas untuk setiap foreign key yang diidentifikasi. Berdasarkan dari kamus data yang ada, dapat diketahui bahwa dari setiap atributnya : - Domain dari atribut yang terdiri dari tipe data, panjang data, dan constraints yang ada pada Domain. - Suatu opsional nilai default untuk atribut. - Apakah atribut boleh bernilai null. - Apakah atribut dapat diperoleh dan bagaimana cara seharusnya mengkomputasi. 2. Merancang representasi dari derived data Tujuan dari tahap ini adalah untuk menetukan bagaimana mempresentasikan suatu derived data pada model data logikal dalam DBMS yang digunakan. Atibut yang nilainya dapat ditemukan dengan memeriksa nilai-nilai dari atibut lainnya disebut dengan atribut turunan (derived) atau calculated attributes. Sebagai contoh, berikut ini merupakan atribut turunan (derived) : - Jumlah karyawan yang bekerja di salah satu cabang perusahaan. 39 - Jumlah total gaji per bulan dari semua karyawan perusahaan. - Jumlah total produksi agen dalam satu tahun. 3. Merancang batasan (constraints) umum Dalam tahap ini tujuannya adalah untuk merancang semua batasan umum pada perusahaan untuk DBMS yang digunakan. Dalam tahap ini akan mempertimbangkan general constraints yang tersisa. Dalam merancang general constraints tergantung pada pilihan DBMS yang digunakan, beberapa sistem telah menyediakan fasilitas yang lebih daripada system lainnya untuk mendefinisikan general constraints. 4. Merancang indeks dan pengaturan file Tujuan dari tahap ini adalah untuk mennetukan cara pengaturan file yang optimal untuk menyimpal relasi dasar dan indeks yang diperlukan untuk mencapai kinerja atau performa yang dapat diterima oleh perusahaan. Berikut merupakan langkah yang dilakukan untuk mencapai tujuan pada tahap ini : Langkah 4: 1. Menganalisa transaksi Tujuannya adalah memahami fungsi yang dimiliki oleh transaksi yang akan berjalan pada database dan juga menganalisa transaksi-transaksi yang penting. Untuk melaksanakan database fisikal yang efektif, maka ada perlunya untuk mengetahui pengetahuan tentang transaksi ataupun query yang akan dijalankan pada database. Dalam menganalisa transaksi , dapat diidentifikasi kriteria dari performa seperti : - Transaksi yang sering digunakan akan memiliki dampak yang besar terhadap performa sistem. - Transaksi yang kritikal penting dalam menjalankan transaksi bisnis. 40 - Waktu-waktu (per hari/minggu) tertentu yang menjadi puncak penggunaan sistem dimana akan ada permintaan atau tuntutan yang tinggi pada database. 41 Memilih cara mengatur file Tujuannya adalah untuk menentukan cara pengaturan file yang efisien bagi semua relasi dasar yang ada. 2. Memilih indeks Tujuannya adalah untuk menentukan apakah dengan menambahkan indeks akan meningkatkan kinerja atau performa dari sistem. Salah satu pendekatan yang digunakan dalam memilih cara pengeturan file yang sesuai adalah dengan menjaga tuple tetap unordered dan membuat atau menciptakan indeks sekunder sebanyak yang diperlukan. 3. Memperkirakan kapasitas disk yang diperlukan Tujuan dari tahap ini adalah untuk memperkirakan jumlah atau besar kapasitas disk yang dibutuhkan oleh database. Langkah 5: 1. Merancang userviews Tujuan dari tahap ini adalah untuk merancang tampilan bagi semua user yang diidentifikasi selama pengumpulan dan analisa dari tahap atau siklus pengembangan sistem database (Database System Development Lifecycle/DSDL). Langkah 6: 1. Merancang mekanisme keamanan Tujuan dari tahap ini adalah merancang mekanisme sistem keamanan atau sekuriti untuk database yang telah ditetapkan oleh users selama tahap kebutuhan sistem dan pengumpulan dari DSDL. 42 2.2.2.5 DBMS Selection (Optional) Memilih DBMS yang tepat untuk mendukung sistem database. Dapat dilakukan kapanpun sebelum menuju design logikal asalkan terdapat cukup informasi mengenai kebutuhan sistem. Tahap-tahap utama memilih DBMS: - Mendefinisikan terminologi studi referensi. - Mendaftar dua atau tiga produk - Evaluasi produk - Rekomendasi pilihan dan laporan produk 2.2.2.6 Application Design Design aplikasi adalah design interface user dan program aplikasi yang menggunakan dan memproses basis data. Design basis data dan aplikasi merupakan aktifitas paralel yang meliputi dua aktifitas penting, yaitu: - Transaction Design Transaksi adalah satu aksi atau serangkaian aksi yang dilakukan oleh user tunggal atau program aplikasi, yang mengakses atau mengubah isi dari basis data. Kegunaan dari design transaksi adalah untuk menetapkan dan keterangan karakteristik high-level dari suatu transaksi yang dibutuhkan pada basis data. Terdapat tiga tipe transaksi, yaitu: Retrieval transaction, digunakan untuk pemanggilan (retrieve) data untuk ditampilkan dilayar atau menghasilkan suatu laporan. Update transaction, digunakan untuk menambah record baru, menghapus record lama, atau memodifikasi record yang sudah ada didalam database. Mixed transaction, meliputi pemanggilan dan perubahan data. 43 - User Interface Design Beberapa aturan pokok dalam pembuatan user interface: Meaningful title, diusahakan pemberian nama suatu form cukup jelas menerangkan kegunaan dari suatu form/report. Comprehensible instructions, penggunaan terminologi yang familiar untuk menyampaikan instruksi ke user dan jika informasi tambahan dibutuhkan, maka harus disediakan help screen. Logical grouping and sequencing of fields, field yang saling berhubungan ditempatkan pada form/report yang sama. Urutan field harus logis dan konsisten. Visually appealing layout of the form/report, tampilan form/report harus menarik, dan sesuai dengan hardcopy agar konsisten. Familiar field labels, penggunaan label yang familiar. Consistent terminology and abbreviation, terminologi dan singkatan yang digunakan harus konsisten. Consistent us of color. Visible space and boundaries for data-entry fields, jumlah tempat yang disediakan untuk data entry harus diketahui oleh user. Convinient cursor movement, user dapat dengan mudah menjalankan operasi yang diinginkan dengan menggerakan cursor pada form/report. Error correction for individual characters and entire fields, user dapat dengan mudah menjalankan operasi yang diinginkan dan dapat melakukan perubahan terhadap nilai field. Error messages for unacceptable values. Optional field marked clearly. 44 Explanatory message for fields, ketika user meletakkan cursor pada suatu field, maka keterangan mengenai field tersebut harus dapat dilihat. Completion signal, indikator yang menjelaskan bahwa suatu proses telah selesai dilaksanakan . 2.2.2.7 Prototyping (Optional) Prototyping adalah membuat model kerja suatu aplikasi basis data. Tujuan utama dari pembuatan prototyping adalah: - Untuk mengidentifikasi feature dari sistem yang berjalan dengan baik atau tidak . - Untuk memberikan perbaikan-perbaikan atau penambahan feature baru. - Untuk klarifikasi kebutuhan pemakai. - Untuk evaluasi feasibilitas (kemungkinan yang akan terjadi) dari design sistem khusus. Terdapat dua macam strategi prototyping yang dapat digunakan saat ini, yaitu: - Requirement prototyping, menggunakan prototype untuk menentukan kebutuhan dari aplikasi basis data yang diinginkan dan ketika kebutuhan itu terpenuhi maka prototype akan dibuang. - Evolutionary prototyping, digunakan untuk tujuan yang sama. Perbedaannya, prototype tidak dibuang tetapi dengan pengembangan lanjutan menjadi aplikasi basis data yang digunakan. 2.2.2.8 Implamentation Implementasi merupakan realisasi fisik dari basis data dan design aplikasi. Implementasi basis data dicapai dengan menggunakan: - DDL untuk membuat skema basis data dan file basis data kosong. - DDL untuk membuat user view yang diinginkan . 45 - 3GL dan 4GL untuk membuat program aplikasi. Termasuk transaksi basis data disertakan dengan menggunakan DML, atau ditambahkan pada bahasa pemrograman. 2.2.2.9 Data Convertion and Loading Pemindahan data yang ada kedalam basis data baru dan mengkonversikan aplikasi yang ada agar dapat digunakan pada basis data yang baru. Tahapan ini dibutuhkan ketika sistem basis data baru menggantikan sistem yang lama. DBMS biasanya memiliki utilitas yang memanggil ulang file yang sudah ada kedalam basis data baru. Dapat juga mengkonversi dan menggunakan program aplikasi dari sistem yang lama untuk digunakan oleh sistem yang baru. 2.2.2.10 Testing Testing adalah suatu proses eksekusi program aplikasi dengan tujuan untuk menemukan kesalahan. Dengan menggunakan strategi tes yang direncanakan dan data yang sesungguhnya. Pengujian hanya akan terlihat jika terjadi kesalahan software. Mendemonstrasikan basis data dan program aplikasi terlihat berjalan seperti yang diharapkan. 2.2.2.11 Operational Maintenance Suatu proses pengawasan dan pemeliharaan sistem setelah instalasi, meliputi: - Pengawasan performa sistem, jika performa menurun maka memerlukan perbaikan atau pengaturan ulang basis data. - Pemeliharaan dan pembaharuan aplikasi basis data (jika dibutuhkan). - Penggabungan kebutuhan baru kedalam aplikasi basis data. 1.3 Struktur Data Relasional Menurut Connolly dan Begg (2010, p144-146), struktur data relasional terbagi menjadi beberapa bagian yaitu: 46 1. Relasi : merupakan sebuah table dengan baris dan kolom. Digunakan untuk menyimpan informasi tentang objek yang digambarkan dalam database. 2. Atribut : merupakan nama kolom dalam relasi. Atribut dapat ditampilkan dalam berbagai perintah dan dalam relasi yang sama sehingga menyampaikan arti yang sama. 3. Domain : merupakan sekelompok nilai yang diizinkan bagi satu atau lebih atribut. Setiap atribut dalam relasi didefinisikan pada sebuah domain. Domain dapat berbeda bagi setiap atribut, atau dua/lebih atribut dapat didefinisikan pada domain yang sama. Konsep domain sangat penting karena memungkinkan pengguna menjelaskan arti dan sumber nilai yang ada pada atribut. 4. Tuple : merupakan baris dari sebuah relasi. Dapat disebut intension jika struktur relasi, domain serta batasan-batasan yang lainnya pada nilai yang mungkin bersifat tetap, namun sebaliknya jika relasi berubah setiap waktu ini disebut extension. 5. Degree : merupakan jumlah atribut yang terdapat dalam relasi. Jika relasi mempunyai satu atribut akan mempunyai derajat satu yang disebut relasi unary / satu tuple. Jika relasi mempunyai dua atribut akan mempunyai derajat dua yang disebut binary. Dan begitu seterusnya memakai istilah nary. 6. Cardinality : merupakan jumlah tuple yang terdapat dalam relasi. Cardinality juga merupakan properti dari extension relasi dan ditentukan dari instance tertentu. 7. Database Relational : merupakan kumpulan dari relasi yang ternomalisasi dengan nama relasi yang berbeda. 1.4 Entity-Relationship Modeling Pada kutipan jurnal Bahl, Sharma, dan Rajpal (2011, p2), entity relationships (ER) model digunakan untuk menunjukkan hubungan antar entitas dan sebagai tool dasar dalam merancang basis data. Entity relationship (ER) data model didasarkan pada persepsi dunia 47 nyata yang terdiri dari kumpulan objek dasar, yang disebut entiti dan relationship antara objek-objek ini : - Entity Type Entity type merupakan konsep dasar dari suatu model ER. Menurut Connolly dan Begg (2010, p372), entity type adalah kumpulan dari objek dengan property yang sama, yang diidentifikasi oleh perusahaan mempunyai keberadaan yang independen. Keberadaan entity type dapat berupa fisik atau ‘nyata’ dan konseptual atau ‘abstrak’. - Relationship Type Menurut Connolly dan Begg (2010, p374), relationship adalah sekumpulan entitas yang memiliki hubungan satu sama lain. Relationship occurence adalah suatu gabungan yang dapat didefinisikan secara unik yang meliputi suatu kejadian dari setiap tipe entitas yang berpartisipasi. Gambar 2.4 Contoh relasi bernama memiliki Biasanya, nama dari suatu relasi menggunakan kata kerja (seperti: memiliki, mengatur, menyebabkan atau melakukan). Dalam gambar xx, dibaca SPA memiliki Rider, arah pembacaan dilihat dari arah tanda panahnya menuju kekelas yang dituju. - Atribut Menurut Connolly dan Begg (2010, p379), atribut dapat diartikan sebagai sebuah property dari sebuah entitas atau tipe dari relasi. Atribut dapat diklasifikasi menjadi : 48 1. Attribute Simple and Composite Attribute simple adalah sebuah atribut yang terdiri dari komponen tunggal dengan keberadaan independen (tetap). Attribute simple kadang disebut juga komponen atomik (tidak bisa dibagi). Attribute composite adalah sebuah atribut yang terdiri dari banyak komponen dengan keberadaan independen (tetap). 2. Single Value and Multi Value Attributes Single value attribute adalah sebuah atribut yang memiliki nilai tunggal untuk masingmasing kejadian dari sebuah entitas. Multi value attribute adalah sebuah atribut yang memiliki banyak nilai untuk masing-masing kejadian dari sebuah entitas. 3. Derived Attribute Derived attributes adalah sesuatu yang menggantikan sebuah nilai yang diturunkan dari nilai atribut yang berhubungan atau kumpulan dari atribut, tidak perlu pada jenis entitas yang sama. 4. Keys Candidate key adalah sekumpulan dikit atribut yang secara unik mengidentifikasi setiap jenis entitas. Primary key adalah candidate key yang dipilih untuk mengidentifikasi tuples yang unik dalam sebuah relasi, karena suatu relasi tidak memiliki duplikat tuples. - Entitas Kuat dan Lemah Menurut Connolly dan Begg (2010, p383), entitas kuat adalah entitas yang keberadaannya tidak bergantung pada beberapa entitas yang lain. Karakter dari entitas ini adalah bahwa setiap kejadian entitas teridentifikasi secara unik menggunakan atribut primary key. Sebagai contoh, kita dapat mengidentifikasi secara unik setiap anggota staff dengan menggunakan atribut staff No. 49 Sedangkan entitas lemah adalah entitas yang keberadaannya bergantung pada beberapa entitas lain. Karakteristik dari entitas ini bahwa setiap kejadian entitas tidak dapat teridentifikasi secara unik hanya dengan menggunakan atribut entitas tersebut. Kita hanya dapat mengidentifikasi secara unik entitas kesukaan melalui relationship yang dimiliki dengan entitas klien yang secara unik teridentifikasi menggunakan primary key bagi entitas klien. - Attribut dalam relasi Sebuah relasi yang menghubungkan antar entitas juga dapat memiliki atribut didalamnya yang mirip dengan atribut dalam sebuah entitas. Dan untuk membedakan antara relasi dan atribut dengan entitas, atribut dari relasi dihubungkan dengan menggunakan garis putus-putus. Untuk lebih jelasnya dapat dilihat pada gambar xx, dimana relasi mencatat memiliki atribut jawaban_pp dan jawaban_tt. Gambar 2.5 Contoh atribut dalam relasi mencatat - StructuralConstrain Menurut Connolly dan Begg (2010, p385), tipe utama dari batasan hubungan dinamakan multiplicity. Multiplicity adalah jumlah kemungkinan kejadian sebuah entitas yang mungkin berhubungan dengan sebuah kejadian tunggal dari sebuah entitas yang tergabung melalui sebuah hubungan khusus. Hubungan binary secara khusus dibedakan menjadi : 50 1. Derajat hubungan one-to-one (1:1) Dapat dilihat dari gambar xx, derajat hubungan ini terjadi bila setiap anggota entitas staff hanya boleh berpasangan dengan satu anggota dari entitas branch. Sebaliknya tiap anggota branch hanya boleh berpasangan dengan satu anggota dari entitas staff. Gambar 2.6 Contoh yang menunjukkan hubungan 1:1 (Sumber : Connolly dan Begg (2010, p386)) 2. Derajat hubungan one-to-many (1:*) Dapat dilihat dari gambar xx, derajat hubungan ini terjadi bila tiap anggota entitas staff boleh berpasangan dengan lebih dari satu anggota entitas propertyForRent. Sebaliknya tiap anggota entitas propertyForRent hanya boleh berpasangan dengan satu anggota dari entitas staff. Gambar 2.7 Contoh yang menunjukkan hubungan 1:* (Sumber : Connolly dan Begg (2010, p387)) 3. Derajat hubungan many-to-many (*:*) 51 Dapat dilihat dari gambar xx, derajat hubungan antar entitas ini terjadi bila tiap anggota entitas barang boleh berpasangan lebih dari satu entitas produksi. Gambar 2.8 Contoh yang menunjukkan hubungan *:* (Sumber : Connolly dan Begg (2010, p388)) 52 4. Multiplicity untuk relasi yang komplek. Multiplicity untuk relasi yang komplek adalah jumlah (atau jangkauan) dari kejadian yang mungkin dari suatu entity dalam nary-relationship ketika nilai entity yang lain (n-1) diketahui. Multiplicity dibentuk dari dua macam batasan pada relationship, yaitu cardinality, menjelaskan jumlah maksimal dari kejadian relationship yang mungkin untuk entity yang berpartisipasi di dalam relationship tersebut. Participation, menetapkan apakah seluruh atau sebagian entity yang berpartisipasi dalam suatu relationship. 1.5 Normalization Menurut Connolly dan Begg (2010, p415), normalisasi adalah teknik yang digunakan untuk menghasilkan sekumpulan relasi tabel dengan properties yang diinginkan, sehingga sesuai dengan kebutuhan perusahaan. Tujuan dari normalisasi adalah untuk mengidentifikasi sekumpulan relasi yang sesuai dan cocok sehingga dapat memenuhi kebutuhan perusahaan. Relasi yang sesuain yang dimaksud memiliki karakteristik seminimalnya redudansi dan minimal jumlah atribut yang dimiliki yang akan memenuhi kebutuhan perusahaan. Jadi tujuan utama dari normalisasi adalah untuk meminimalkan redudansi data dan masalah-masalah yang muncul ketika data di insert, update, dan delete. Masalah-masalah tersebut sering disebut dengan istilah anomali. Menurut Connolly dan Begg (2010, p419) Anomali adalah suatu efek samping yang menyebabkan inconsistency (tidak konsisten) data atau membuat data-data menjadi hilang dan tidak terintegrasi saat data lain dihapus atau dimodifikasi. 53 Gambar 2.9 Ilustrasi yang menggambarkan relasi antara normalforms (Sumber : Connolly dan Begg (2010, p429)) Menurut Connolly dan Begg (2010, p428), berikut merupakan langkah-langkah normalisasi, yaitu: 1. Unnormalized Form (UNF) Unnormalized form adalah kondisi dimana sebuah tabel belum masuk kedalam proses normalisasi atau disebut juga dengan bentuk awal dari tabel. Menurut Connolly dan Begg (2010, p430), unnormalized form adalah “A table that contains one or more repeating groups”, yang artinya adalah suatu table yang berisi satu atau lebih kelompok yang berulang. Contoh unnormalized form(UNF): Tabel 2.7 Contoh bentuk tabel yang belum dinormalisasi (UNF) (Sumber : Connolly dan Begg (2010, p432)) Client No CR76 cNa me John Kay property No PG4 PG16 CR56 Aline PG4 Stew art PG36 PG16 pAddress rentStart rentFinish rent 6 lawrence St, Glasgow 5 Novar Dr, Glasgow 6 lawrence ST, Glasgow 2 Manor Rd, Glasgow 5 Novar DR, Glasgow 1-Jul-07 31-Aug-08 350 owner No CO40 1-Sep-08 1-Sep-09 450 CO93 1-Sep-06 10-Jun-07 350 CO40 10-Oct-07 1-Dec-08 375 CO93 1-Nov-09 10-Aug-10 450 CO93 2. First Normal Form (1NF) oName Tina Murphy Tony Shaw Tina Murphy Tony Shaw Tony Shaw 54 Bentuk normal yang pertama ini dapat dicapai bila telah memenuhi syarat dimana setiap perpotongan baris dan kolom hanya memilik satu dan hanya satu nilai. Tahap 1NF bertujuan untuk mengidentifikasi dan menghilangkan data yang bersifat repitisi didalam tabel. Contoh 1NF: Tabel 2.8 Contoh tabel yang telah memasuki bentuk normal pertama (1NF) (Sumber : Connolly dan Begg (2010, p432)) Client No CR76 proper tyNo PG4 cName pAddress rentStart rentFinish rent oName 350 ownerN o CO40 John Kay 1-Jul-07 31-Aug-08 CR76 PG16 John Kay 1-Sep-08 CR56 PG4 Aline Stewart CR56 PG36 Aline Stewart CR56 PG16 Aline Stewart 6 lawrence St, Glasgow 5 Novar Dr, Glasgow 6 lawrence ST, Glasgow 2 Manor Rd, Glasgow 5 Novar DR, Glasgow 1-Sep-09 450 CO93 Tony Shaw 1-Sep-06 10-Jun-07 350 CO40 Tina Murphy 10-Oct-07 1-Dec-08 375 CO93 Tony Shaw 1-Nov-09 10-Aug-10 450 CO93 Tony Shaw Tina Murphy 55 3. Second Normal Form (2NF) Setelah setiap kolom hanya mengandung satu dan hanya satu nilai, maka tahap selanjutnya dalam 2NF adalah memisahkan atribut yang bersiafat partially dependent menjadi satu tabel yang berdiri sendiri. Jadi, tahap 2NF adalah tahap dimana dalam satu tabel semua atribut bersifat fully dependent terhadap primary key tabel tersebut. Contoh 2NF: Tabel 2.9 Tabel-tabel hasil dari proses 2NF (Sumber : Connolly dan Begg (2010, p435)) Client ClientNo cName CR76 John Kay CR56 Aline Stewart Rental ClientNo propertyNo rentStart rentFinish CR76 PG4 1-Jul-07 31-Aug-08 CR76 PG16 1-Sep-08 1-Sep-09 CR56 PG4 1-Sep-06 10-Jun-07 CR56 PG36 10-Oct-07 1-Dec-08 CR56 PG16 1-Nov-09 10-Aug-10 PropertyOwner propertyNo pAddress rent ownerNo oName PG4 6 lawrence ST, Glasgow 350 CO40 Tina Murphy PG16 5 Novar Dr, Glasgow 450 CO93 Tony Shaw 56 PG36 2 Manor Rd, Glasgow 375 CO93 Tony Shaw 4. Third Normal Form (3NF) Setelah tahap 2NF data tetap memiliki sedikit redundansi data sehingga dilakukan 3NF agar tidak ada atribut yang bergantungan dengan atribut primary key. Tahap 3NF adalah hubungan yang hasil dari 1NF dan 2NF dimana tidak ada atribut non primary key yang yang bersifat transitif dependent terhadap primary key. Jadi, pada tahap 3NF dilakukan untuk memisahkan atribut-atribut yang bersifat transitive dependent. Contoh 3NF: Tabel 2.10 Tabel-tabel hasil dari proses 3NF (Sumber : Connolly dan Begg (2010, p438)) Client ClientNo cName CR76 John Kay CR56 Aline Stewart Rental ClientNo propertyNo rentStart rentFinish CR76 PG4 1-Jul-07 31-Aug-08 CR76 PG16 1-Sep-08 1-Sep-09 CR56 PG4 1-Sep-06 10-Jun-07 CR56 PG36 10-Oct-07 1-Dec-08 CR56 PG16 1-Nov-09 10-Aug-10 PropertyForRent propertyNo pAddress rent ownerNo PG4 6 lawrence ST, Glasgow 350 CO40 PG16 5 Novar Dr, Glasgow 450 CO93 57 PG36 2 Manor Rd, Glasgow 375 CO93 Owner ownerNo oName CO40 Tina Murphy CO93 Tony Shaw Konsep terpenting dalam keterkaitan dengan normalisasi adalah Functional Dependencies. Menurut Connolly dan Begg (2010, p421), functional dependency mendeskripsikan hubungan antar atribut dalam suatu relasi. Sebagai contoh, jika A dan B adalah atribut dari relasi R, B dikatakan functionally dependent terhadap A jika setiap nilai yang dimiliki oleh A diasosiasikan dengan salah satu dari nilai yang dimiliki oleh B. Menurut Connolly dan Begg (2010, p422), functional dependency memiliki karakteristik, yaitu: 1. Full Functional Dependency Full functional dependency adalah menandakan bahwa jika A dan B adalah atribut dalam suatu relasi, B sepenuhnya bergantung pada A tetapi tidak setiap bagian dari A. 2. Partial Dependency Partial dependency ialah keadaan dimana ketika A→B, bila ada atribut yang bisa dihilangkan tetapi masih dalam keadaan dependency. 3. Transitive Dependency 58 Transitive dependency ialah keadaan dimana A, B, C merupakan atribut-atribut dari suatu relasi sehingga A→B dan B→C, maka C merupakan transitive dependent terhadap A melalui B dengan syarat A tidak functionally dependent terhadap B atau C. 59 2.6 Proses Bisnis 1.5.1 Penjualan Menurut Monk dan Bret (2009, p6), bahwa fungsi dari penjualan dan pemasaran adalah mengembangkan produk, menentukan harga, mempromosikan produk kepada pelanggan, dan melayani pemesanan oleh pelanggan. Kegiatan penjualan digambarkan dengan menggunakan rich picture. Menurut Mathiassen, Madsen, dan Nielsen (2000, p27), rich pictures adalah sebuah gambar informal yang menyajikan pemahaman ilustrator terhadap suatu situasi. Dengan menggunakan rich pictures dapat menjelaskan secara lengkap keadaan atau situasi yang penting dari suatu proses dan akan menghasilkan garis besar dari situasi tersebut. Kegiatan penjualan terdiri dari transaksi penjualan barang atau jasa baik secara kredit atau tunai (Mulyadi, 2001:202). Dalam transaksi penjualan secara kredit, jika order dari pelanggan telah dipenuhi dengan adanya permintaan barang atau jasa, maka dalam waktu tertentu perusahaan memiliki piutang kepada pelanggannya. Dalam penjualan ada dua cara pembayaran yang dapat dilakukan yaitu : 1. Penjualan Tunai Penjualan tunai adalah penjualan yang dilaksanakan oleh perusahaan dengan cara mewajibkan pembeli untuk melakukan pembayaran harga barang telebih dahulu sebelum barang diserahkan kepada pembeli. 2. Penjualan Kredit Penjualan kredit adalah penjualan yang dilakukan dengan cara memenuhi permintaan atau pemesanan dari pelanggan lalu mengirimkan barang atau menyerahkan jasa dan untuk jangka waktu tertentu perusahaan memiliki piutang kepada pelanggannya. 60 1.5.2 Asuransi Berdasarkan pada KUHD (Kitab Undang-Undang Hukum Dagang) Republik Indonesia pasal 246, asuransi atau pertanggungan adalah perjanjian, di mana penanggung mengikat diri terhadap tertanggung dengan memperoleh premi, untuk memberikan kepadanya ganti rugi karena suatu kehilangan, kerusakan, atau tidak mendapat keuntungan yang diharapakan, yang mungkin akan dapat diderita karena suatu peristiwa yang tidak pasti. Unsur-unsur dalam asuransi yaitu : - Pihak tertanggung (insecured), merupakan pihak yang berjanji akan membayar uang kepada pihak penanggung. - Pihak penanggung (insurer), merupakan pihak yang berjanji akan membayar jika peristiwa pada unsur ketiga terjadi. - Suatu peristiwa, dimana peristiwa yang dimaksud belum tentu akan terjadi.
