BAB 2 LANDASAN TEORI
advertisement
BAB 2 LANDASAN TEORI 2.1 Teori Umum 2.1.1 Definisi Umum 2.1.1.1 Pengertian Analisis Menurut Whitten-Bently-Ditman (2004, p38), analisis adalah suatu proses yang bertujuan untuk memberikan pengertian yang lebih mendalam mengenai masalah-masalah yang dihadapi dan perlunya pembuatan proyek yang bersangkutan. 2.1.1.2 Pengertian Perancangan Menurut Whitten-Bently-Ditman (2004, p38), perancangan adalah suatu proses menelusuri alternatif-alternatif solusi yang bersifat teknis untuk mengatasi permasalahan yang terjadi. 2.1.1.3 Pengertian Data Menurut Turban-Rainer-Potter (2003, p15), data adalah fakta-fakta dan deskripsi dasar mengenai sesuatu, kejadian, kegiatan, dan transaksi yang diambil, disimpan dan diklasifikasikan tetapi belum terstruktur dengan baik sehingga belum memberikan sesuatu arti yang penting. 7 8 2.1.1.4 Basis Data Menurut Connolly & Begg (2002, p14), basis data merupakan suatu kumpulan data yang secara logika saling berhubungan dan deskripsi dari data tersebut dirancang untuk memenuhi informasi yang dibutuhkan oleh suatu organisasi. Basis Data merupakan suatu kumpulan data yang berhubungan secara logis, dan deskripsi dari data tersebut, dirancang untuk memenuhi informasi yang dibutuhkan oleh sebuah organisasi. Artinya Database merupakan tempat penyimpanan data yang besar, dimana dapat digunakan secara simultan oleh banyak pengguna. 2.1.2 Sistem Basis Data Menurut date(2000, p5) sistem basis data pada dasarnya adalah sistem penyimpanan record yang terkomputerisasi dimana tujuan sebenarnya adalah penyimpanan informasi dan membuat informasi tersebut selalu tersedia saat dibutuhkan. 2.1.2.1 Relational Model Menurut Connolly-Begg (2005, p70), kegunaan dari model relasional di antaranya: • Memungkinkan data dengan tingkat independen yang tinggi. Program aplikasi seharusnya tidak terpengaruh oleh modifikasi terhadap representasi data internal, khususnya perubahan terhadap organisasi file, urutan record, maupun jalur akses. 9 • Menjamin pengelolaan data dengan lebih baik dan konsisten, serta dapat mengatasi masalah redundancy. • Memungkinkan pengembangan pada kumpulan DML (Data Manipulation Language) yang terorientasi. Menurut Connolly-Begg (2005, p72), istilah-istilah dalam model relasi adalah: Relation, merupakan sebuah tabel dengan kolom dan baris. Attribute, merupakan nama kolom dari suatu relasi. Domain, merupakan himpunan nilai-nilai yang valid pada atribut tertentu. Tuple, merupakan sebuah baris dari suatu relasi. Degree, merupakan jumlah atribut dalam suatu relasi. Cardinality, merupakan jumlah tuple dalam suatu relasi. Relational Database, merupakan kumpulan dari tabel-tabel yang telah dinormalisasi dengan nama relation yang unik. 2.1.2.2 Relational Key Menurut Connolly-Begg (2005, p78), tidak ada tuple yang berduplikasi dalam suatu relation, sehingga diperlukan satu atau lebih atribut yang secara unik mengidentifikasi setiap tuple dalam suatu relation. Atribut-atribut tersebut disebut dengan relational key. Relational key terdiri dari: • Superkey adalah satu atau lebih atribut yang mengidentifikasi tuple secara unik dalam suatu relation. • Candidate key adalah sejumlah atribut yang dapat mengidentifikasi setiap kejadian atau record secara unik. • Alternate key adalah candidate key yang tidak terpilih menjadi primary key. 10 • Primary key adalah candidate key yang terpilih untuk mengidentifikasi entitas-entitas di dalam entity set. Primary key harus merupakan field yang benar-benar unik dan tidak boleh ada nilai NULL. • Foreign key adalah primary key dari entitas yang digunakan untuk mengidentifikasi kejadian dari suatu relationship. 2.1.2.3 Database Management Sistem (DBMS) Menurut Gerard V. Post (2005, p2), DBMS adalah software yang mengelola basis data dan penyimpanan data, mendukung bahasa query, menghasilkan laporan, dan membuat layer data entry. Menurut Atzeni (2003, p3), DBMS adalah sistem piranti lunak yang memungkinkan penanganan kumpulan data yang banyak, shared dan kontinu, serta dapat menjamin reliabilitas dan kerahasiaan data. Menurut Connolly-Begg (2005, p16), DBMS adalah sebuah software system yang memungkinkan user mendefinisi, membentuk dan mengatur database dan yang mengendalikan akses ke database. DBMS berinteraksi dengan pengguna aplikasi program dan database. DBMS menyediakan fasilitas: a. Data definition language (DDL), yang berguna untuk menspesifikasikan tipe data, struktur dan constraint data. Semua spesifikasi disimpan dalam database. b. Data manipulation language (DML), yang berguna untuk memberikan fasilitas query data. c. Pengendalian akses database, antara lain mengontrol: 11 - Keamanan sistem: mencegah user yang tidak memiliki hak akses untuk mengakses database. - Integritas sistem: menjaga konsistensi data. - Pengendalian share data. - Sistem backup dan recovery. - Katalog deskripsi data dalam database. d. Mekanisme view, yang berfungsi untuk menyediakan data yang hanya diinginkan dan diperlukan user. Tujuan pemilihan DBMS adalah untuk memilih sebuah sistem yang sesuai dengan kebutuhan perusahaan saat ini maupun di masa yang akan datang, yang seimbang dengan biaya-biaya yang dikeluarkan termasuk dalam pembelian produk DBMS, perangkat lunak maupun perangkat keras tambahan yang dibutuhkan untuk mendukung sistem basisdata, dan biaya-biaya lain yang berhubungan dengan perubahan dan pelatihan pegawai dalam menggunakan sistem baru. Menurut Connolly-Begg (2005, p19), DBMS terdiri dari 5 komponen yaitu: o Hardware, yaitu berupa PC hingga jaringan komputer-komputer. o Software, yaitu DBMS, sistem operasi, software jaringan (bila diperlukan) dan juga aplikasi program. o Struktur database yang digunakan organisasi yang mengandung data operasional dan meta-data disebut schema. o Procedure, yaitu instruksi dan aturan yang mengatur rancangan dan kegunaan dari database. 12 o People, antara lain : - Data Administration DA lebih memperhatikan tahapan awal dari lifecycle. DA mengatur sumber daya data, meliputi: perencanaan database, pengembangan dan pemeliharaan standar, kebijakan, prosedur, dan desain database logikal dan konseptual. - Database Administration DBA mengatur implementasi dari aplikasi database yang meliputi desain fisik database dan implementasi, pengaturan keamanan dan kontrol integritas, pengawasan performa sistem dan pengaturan ulang database. - Database designer (Logikal dan Fisikal) - Application programmer - End User o Naïve: User yang tidak perlu tahu mengenai DB dan DBMS. Hanya menggunakan program aplikasi. o Sophisticated: User yang familiar dengan struktur Database dan DBMS. Tahap-tahap utama dalam pemilihan DBMS (Connolly, 2005, pp296- 299): • Definisikan batas waktu studi referensi Tahapan ini menetapkan tujuan dan ruang lingkup studi, tugastugas yang akan dikerjakan, uraian kriteria (berdasarkan spesifikasi kebutuhan user) untuk mengevaluasi produk DBMS, 13 daftar awal produk-produk yang mungkin, dan semua batasanbatasan dan skala waktu yang dibutuhkan untuk studi. • Daftar dua atau tiga produk Kriteria yang dianggap penting dalam keberhasilan implementasi dapat digunakan untuk membuat daftar awal produk-produk DBMS dalam evaluasi, seperti dana yang tersedia, tingkat dukungan penjual, kecocokan dengan perangkat lunak lain, dan apakah produk hanya berjalan pada perangkat keras tertentu. • Evaluasi produk Fitur-fitur yang digunakan dalam evaluasi produk-produk DBMS dikelompokkan menjadi pendefinisian data, pendefinisian fisik, kemampuan akses, pengembangan dan lain-lain. • Rekomendasi pilihan dan hasilkan laporan Langkah terakhir adalah mendokumentasikan proses dan membuat pernyataan dalam penemuan dan merekomendasikan produk DBMS tertentu. 2.1.2.4 Analisis Database dan Teknik Desain 2.1.2.4.1 Database Application Lifecycle Menurut Connoly-Begg (2005, p283), database merupakan komponen dasar sistem informasi, di mana pengembangan dan penggunaannya harus dilihat dari perspektif kebutuhan yang lebih luas dari organisasi. Tahapan database application lifecycle adalah: 14 Database planning System definition Requirement collection and analysis Database design Conceptual database design DBMS selection (optional) Application design (optional) Logical database design Physical database design Prototyping (optional) Implementation Data conversion and loading Testing Operational maintenance Gambar 2.1 Database Application Lifecycle 1. Database Planning Database planning merupakan aktivitas manajemen yang memungkinkan tahapan-tahapan aplikasi database dapat direalisasikan seefisien dan seefektif 15 mungkin. Database planning harus terintegrasi dengan keseluruhan strategi sistem informasi. Ada tiga hal yang terlibat dalam penyusunan strategi sistem informasi: - Identifikasi terhadap rencana dan sasaran usaha dengan rangkaian keputusan dari kebutuhan sistem informasi. - Evaluasi terhadap sistem informasi yang sedang berjalan untuk mengetahui kelebihan dan kekurangannya. - Penafsiran terhadap peluang IT yang dapat memberikan keuntungan kompetitif. 2. System Definition System definition menjelaskan cakupan dan batasan dari aplikasi database dan user view utama. User view mendefinisikan apa yang dibutuhkan aplikasi database dari perspektif suatu peran kerja tertentu (misalnya Manager atau Supervisor) atau area aplikasi usaha (misalnya marketing, personnel, atau stock control). Suatu aplikasi database dapat memiliki satu atau lebih user view. Mengidentifikasi user view merupakan aspek penting pada pengembangan aplikasi database karena membantu memastikan bahwa tidak ada user utama dari database tersebut yang terlupakan saat pengembangan atas kebutuhan untuk aplikasi baru. User view juga membantu pada pengembangan suatu aplikasi database yang relatif kompleks dengan memungkinkan kebutuhannya dibagi ke dalam bagian-bagian yang lebih mudah diatur. 16 3. Requirement Collection And Analysis Requirement collection and analysis merupakan proses pengumpulan dan penganalisaan informasi mengenai bagian dari organisasi yang didukung aplikasi database, dan penggunaan informasi tersebut untuk mengidentifikasi kebutuhan user pada sistem yang baru. Ada tiga jenis pendekatan untuk menangani kebutuhan aplikasi database dengan user view yang banyak: - Pendekatan centralized Kebutuhan untuk masing-masing user view digabungkan ke dalam satu set tunggal kebutuhan tersebut untuk aplikasi database yang baru. - Pendekatan view integration Kebutuhan untuk masing-masing user view dibangun ke data model yang terpisah yang merepresentasikan user view tersebut. Hasil data model tersebut akan digabungkan kemudian dalam tahapan database design. - Kombinasi dari kedua jenis pendekatan tersebut 4. Database Design Database design adalah proses pembuatan rancangan untuk database yang mendukung operasi dan tujuan usaha. Ada dua jenis pendekatan dalam merancang database: - Pendekatan bottom-up Pendekatan ini dimulai pada level dasar dari attribute (yaitu property dari entity dan relationship), di mana melalui analisa asosiasi antara attribute, dikelompokkan ke dalam relation yang merepresentasikan tipe entity dan relationship antara entity. 17 - Pendekatan top-down Pendekatan ini dimulai dengan pengembangan data model yang berisi sedikit high-level entity dan relationship dan kemudian melakukan penyaringan top-down secara beruntun untuk mengidentifikasi lower-level entity, relationship, dan attribute terasosiasi. Ada dua tujuan utama data modelling, yaitu untuk membantu dalam pemahaman arti (semantik) data dan untuk memfasilitasi komunikasi mengenai informasi yang dibutuhkan. Kriteria yang dibutuhkan untuk menghasilkan data model yang optimal: - Structural validity - Simplicity - Expressibility - Nonredundancy - Shareability - Extensibility - Integrity - Diagrammatic representation Database design terdiri dari tiga fase utama: Conceptual database design Proses membentuk model informasi yang digunakan dalam suatu perusahaan, independen terhadap seluruh pertimbangan fisik. 18 Logical database design Proses membentuk model informasi yang digunakan dalam suatu perusahaan berdasarkan data model yang spesifik, tetapi independen terhadap suatu DBMS tertentu dan pertimbangan fisik lainnya. Physical database design Proses menghasilkan deskripsi mengenai penerapan dari database pada secondary storage; hal itu menggambarkan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai pengaksesan data yang efisien, serta batasan integritas dan ukuran keamanan yang berhubungan. 5. DBMS Selection Memilih DBMS harus sesuai dengan yang dibutuhkan agar dapat mendukung aplikasi database dengan baik. Jika belum terdapat DBMS, saat DBMS selection yang paling tepat adalah antara fase conceptual database design dengan logical database design. Langkah utama dalam DBMS selection: a. Mendefinisikan studi Terms of Reference b. Mendaftarkan dua atau tiga produk c. Mengevaluasi produk d. Merekomendasikan pilihan dan menghasilkan laporan 6. Application Design Application design merupakan rancangan user interface dan program aplikasi yang menggunakan dan memproses database. Pada sebagian besar kasus, application design tidak mungkin akan selesai sampai rancangan database itu sendiri telah ada. Di sisi lain, database muncul untuk mendukung aplikasi, 19 dan jadi harus ada alur pergerakan informasi antara application design dengan database design. 7. Prototyping Prototyping merupakan pembuatan model kerja suatu aplikasi database. Tujuan utama mengembangkan prototype adalah mengidentifikasi fitur mana pada sistem yang berjalan baik dan yang berjalan kurang baik; jika memungkinkan, memberikan peningkatan atau bahkan fitur baru pada aplikasi database. Dua strategi prototyping yang umum digunakan: - Requirement prototyping Setelah kebutuhan terselesaikan, prototype dibuang. - Evolutionary prototyping Setelah kebutuhan terselesaikan, prototype tidak dibuang dan terus dikembangkan hingga menjadi aplikasi database yang dapat bekerja. 8. Implementation Implementation merupakan realisasi fisikal dari database design dan application design. Implementasi dari database dapat menggunakan Data Definition Language (DDL) dari DBMS yang dipilih atau Graphical User Interface (GUI), yang memberikan fungsionalitas yang sama ketika menyembunyikan low-level DDL statement. DDL statement digunakan untuk membuat struktur database dan file database kosong. User view yang telah ditentukan juga diimplementasikan pada tahap ini. 20 9. Data Conversion And Loading Data conversion and loading merupakan proses mentransfer data yang ada ke dalam database baru dan mengkonversi aplikasi yang ada agar dapat berjalan di database baru. Tahap ini diperlukan hanya jika database system yang baru menggantikan sistem yang lama. 10. Testing Testing merupakan proses mengeksekusi program aplikasi dengan tujuan untuk menemukan kesalahan. Testing harus dilakukan dengan strategi tes yang matang dan data yang realistis sehingga keseluruhan proses testing dapat secara metodikal dan secara kasar dilihat. Sebenarnya, testing tidak dapat menunjukkan ketidakberadaannya kesalahan; testing hanya dapat menunjukkan jika kesalahan itu muncul. 11. Operational Maintenance Operational maintenance merupakan proses memonitor dan memelihara sistem setelah instalasi dilakukan. Proses ini melibatkan: - Memonitor performa sistem. Jika performa menurun, perbaikan dan pengaturan ulang database dilakukan. - Memelihara dan jika diperlukan meningkatkan kualitas aplikasi database. Kebutuhan yang baru tergabung ke dalam aplikasi database melalui tahapan yang sebelumnya dalam database application lifecycle. 21 2.1.2.4.2 Entity-Relationship Modeling Konsep dasar ER Modeling: 1. Entity types Entity types merupakan kumpulan dari objek-objek dengan sifat (property) yang sama, yang diidentifikasi oleh perusahaan mempunyai eksistensi yang independen. Keberadaannya dapat berupa fisik maupun abstrak. Entity occurrence, yaitu pengidentifikasian object yang unik dari sebuah entity type. Setiap entitas diidentifikasikan dan disertakan propertynya. 2. Relationship types Relationship types merupakan kumpulan keterhubungan yang mempunyai makna antara entity type yang ada. Relationship occurrence, yaitu keterhubungan yang diidentifikasi secara unik yang meliputi keberadaan tiap entity type yang berpartisipasi. Derajat relationship dikelompokkan menjadi: Binary relationship, keterhubungan antar dua entity types. Ternary relationship, keterhubungan antar tiga entity types. Quaternary relationship, keterhubungan antar empat entity types. Contohnya adalah Arranges. Relasi ini melibatkan 4 entity yaitu Buyer, Solicitor, Financial Institution dan Bid. Relasi ini menggambarkan Buyer, diberi masukan oleh Solicitor, dan didukung oleh Financial Institution, melakukan Bid. Unary relationship, keterhubungan antar satu entity type, di mana entity type tersebut berpartisipasi lebih dari satu kali dengan peran yang berbeda. 22 Kadang disebut juga recursive relationship. Relationship dapat diberikan role names untuk meng-identifikasikan keterkaitan entity type dalam relationship. Contohnya adalah Staff yang berperan menjadi supervisor dan Staff yang di-supervisor-i. 3. Attributes Merupakan sifat-sifat (property) dari sebuah entity atau relationship type. Contohnya: sebuah entity Staff digambarkan oleh attribut staffNo, name, position dan salary. Attribute domain adalah himpunan nilai yang diperbolehkan untuk satu atau lebih atribut. Jenis-jenis atribut: Simple attribute, yaitu atribut yang terdiri dari satu komponen tunggal dengan keberadaan yang independen dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi. Dikenal juga dengan nama atomic attribute. Composite attribute, yaitu atribut yang terdiri dari beberapa komponen, dimana masing-masing komponen memiliki keberadaan yang independen. Misalkan atribut Address dapat terdiri dari street, city, postCode. Single-valued attribute, yaitu atribut yang mempunyai nilai tunggal untuk setiap kejadian. Misalnya entitas Branch memiliki satu nilai untuk atribut branchNo pada setiap kejadian. Multi-valued attribute, yaitu atribut yang mempunyai beberapa nilai untuk setiap kejadian. Misal entitas Branch memiliki beberapa nilai untuk atribut telpNo pada setiap kejadian. Derived attribute, yaitu atribut yang memiliki nilai yang dihasilkan dari satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entitas. 23 2.1.2.5 Metodologi Perancangan 2.1.2.5.1 Conceptual Database Design Menurut Connolly-Begg (2005, p442), conceptual database design adalah suatu proses membangun sebuah model dari informasi dari sebuah perusahaan dan sifatnya independen dari segala pertimbangan physical. Pertimbangan physical yang dimaksud adalah pertimbangan teknis mengenai bagaimana implementasi dari model informasi tersebut. Ada beberapa tahapan yang harus diikuti dalam conceptual database design yaitu sebagai berikut: 1. Mengidentifikasi entity types Tahap ini adalah tahapan di mana kita mengidentifikasikan entity type utama yang dibutuhkan. Caranya adalah dengan memeriksa user’s requirement specification di mana kita mengidentifikasikan noun ataupun noun phrase dari dokumen tersebut. Setelah kita berhasil mengidentifikasi entity-entity type tersebut, maka langkah selanjutnya adalah memberi nama pada entity tersebut dan terakhir kita mendokumentasikan entity type teridentifikasi ke dalam suatu dokumen yang disebut dengan data dictionary. 2. Mengidentifikasi relationship types Tahap ini adalah tahapan di mana kita mengidentifikasi relationship antar entity type yang telah teridentifikasi pada tahapan sebelumnya. Caranya adalah dengan menggunakan ER diagram untuk menggambarkan entity type dan hubungan antar entity tersebut karena dengan memvisualisasikannya dalam gambar maka akan membantu kita dalam menentukan relationship di antara entity type tersebut. Setelah kita menentukan relationship pada model 24 tersebut, maka selanjutnya kita menentukan multiplicity constraint dari relasi tersebut. Multiplicity constraint berfungsi untuk memeriksa dan mempertahankan kualitas dari data. Langkah selanjutnya yang harus dilakukan adalah memeriksa model yang dibuat apakah mengandung fan traps ataupun chasm traps dan juga memastikan bahwa setiap entity dalam model terlibat paling tidak dalam satu relationship. Setelah relationship type teridentifikasi maka kita kembali menyimpannya dalam dokumen yang disebut data dictionary. 3. Mengidentifikasi dan menghubungkan attributes dengan entity atau relationship types Tahap ini adalah tahapan di mana kita menentukan atribut-atribut yang terkait dengan masing-masing entity dan relationship / hubungan antar entity. Atribut-atribut tersebut menggambarkan kepada kita mengenai bagaimana informasi nantinya tersimpan dalam database. Ada beberapa jenis atribut yaitu meliputi: a. Simple / composite attribute Composite attribute adalah atribut yang tersusun dari dua atau lebih simple attribute. Simple attribute itu sendiri adalah attribute yang yang berdiri sendiri. b. Single / multi-valued attribute Single-valued attribute adalah atribut yang hanya memiliki satu nilai tertentu untuk masing-masing entity occurrence, sedangkan pada multi- 25 valued attribute memungkinkan atribut bersangkutan memiliki lebih dari satu nilai untuk setiap entity occurrence. c. Derived attribute Derived attributes adalah atribut yang nilainya berasal dari hasil operasi nilai dari beberapa atribut dalam suatu entity. 4. Menentukan attribute domains Tahap ini adalah tahapan di mana kita mengidentifikasikan domain dari masing-masing atribut yang telah kita tentukan pada tahapan sebelumnya. Domain itu sendiri adalah sejumlah nilai yang dapat diterima (dianggap valid) oleh atribut yang bersangkutan. 5. Menentukan candidates and primary key attributes Tahap ini adalah tahapan di mana kita mengidentifikasikan candidate key untuk masing-masing entity type dan jika ada lebih dari satu candidate key, maka pilihlah satu di antaranya untuk menjadi primary key. Candidate key adalah kumpulan dari atribut pada suatu entity yang mengidentifikasikan secara unik kemunculan dari entity yang bersangkutan. Kita dapat mengidentifikasikan lebih dari satu candidate key pada suatu entity namun kita hanya dapat memilih salah satu untuk dijadikan sebagai primary key. Candidate keys yang tidak ditetapkan sebagai primary key disebut dengan alternate key. 26 6. Mempertimbangkan kegunaan konsep enhanced modelling Tahap ini adalah tahapan di mana kita mulai mempertimbangkan untuk menggunakan konsep enhanced modelling seperti misalnya specialication, generalization, aggregation dan composition. 7. Memeriksa redundancy pada model Tahap ini adalah tahapan dimana kita mengidentifikasikan terjadinya redundancy data untuk kemudian menghapusnya bila terjadi. 8. Memvalidasi local conceptual model terhadap transaksi user Tahap ini adalah tahapan dimana kita memastikan bahwa local conceptual model yang dihasilkan telah benar-benar mendukung transaksi-transaksi yang akan terjadi kemudian. Bila kemudian model yang kita hasilkan mampu menghandle semua transaksi-transaksi tersebut, maka itu berarti bahwa model yang dihasilkan telah baik adanya dan siap dikembangkan ke level perancangan selanjutnya. Ada dua langkah untuk memastikan tahap ini terlaksana dengan baik yaitu pertama kita harus memeriksa ulang relasi yang bersifat one to one relationship dan langkah berikutnya adalah menghapus relationship yang berifat redundant. 9. Mengkaji ulang local conceptual data model dengan user Tahap ini adalah tahapan dimana kita mengevaluasi local conceptual model yang dihasilkan dengan user untuk memastikan bahwa model tersebut telah sesuai dengan keinginan dan harapan user. 27 2.1.2.5.2 Logical Database Design Menurut Connolly-Begg (2005, p462), logical database design adalah suatu proses membangun model untuk informasi yang digunakan dalam sebuah perusahaan berdasarkan suatu specific data model, tetapi masih belum memasukkan pertimbangan-pertimbangan physical dalam proses perancangannya. Ada 2 langkah yang harus dilakukan untuk menghasilkan logical data model yaitu sebagai berikut: 1. Membangun dan memvalidasi local logical data model untuk setiap view Langkah ini bertujuan untuk membangun sebuah local logical data model dari local conceptual data model yang menyajikan gambaran utuh perusahaan dan kemudian model tersebut divalidasi untuk memastikan bahwa secara struktural model tersebut sudah benar dan untuk memastikan bahwa model tersebut mendukung transaksi-transaksi yang terjadi pada perusahaan yang bersangkutan. Ada beberapa hal yang dilakukan pada langkah ini yaitu sebagai berikut: o Menghilangkan fitur yang tidak sesuai dengan relational model Tahapan ini bertujuan untuk memperbaiki local conceptual data model dengan menghilangkan fitur-fitur yang tidak compatible dengan relational model. Fitur-fitur pada local conceptual data model yang penting untuk dihilangkan adalah yaitu: 1. relasi many to many (*:*) pada binary relationship type 2. relasi many to many (*:*) pada recursive relationship type 28 3. relasi complex relationship type yang merupakan relasi yang dibangun oleh 3 atau lebih entity type 4. relasi multi-valued attribute (atribut yang memiliki lebih dari satu nilai) o Menurunkan relations untuk local logical data model Tahapan ini bertujuan untuk menghasilkan relasi-relasi untuk local logical data model yang merepresentasikan entity, relationship, dan atribut yang telah teridentifikasi sebelumnya. Ada beberapa hal dari conceptual model yang harus dibenahi untuk menghasilkan local logical data model yaitu: 1. Strong entity type Pada masing-masing strong entity type, maka akan dibuat suatu relation yang berisi atribut-atribut dari strong entity type tersebut. 2. Weak entity type Pada weak entity type juga akan muncul suatu relation yang berisi atribut-atribut dari weak entity type tersebut namun relation tersebut tidak memiliki primary key karena primary key tersebut diperoleh dari masing-masing owner entity. 3. One to many binary relationship type Pada jenis relationship tersebut akan ditentukan parent entity dan child entity dari relasi tersebut untuk kemudian menduplikasi primary key attribute dari parent entity ke dalam child entity di mana key tersebut akan disebut sebagai foreign key. 29 4. One to one binary relationship type dan one to one recursive relationship Pada one to one binary relationship type akan diselidiki secara lebih mendalam apakah kedua entity type yang terlibat dalam relasi perlu untuk disatukan atau tidak. 5. Superclass/subclass relationship type Pada jenis relationship tersebut maka kita akan menetapkan bahwa superclass entity merupakan parent entity dan subclass entity sebagai child entity. 6. Many to many binary relationship type Pada jenis relationship tersebut maka kita perlu menentukan satu entity type tambahan sebagai penengah antar kedua entity type dengan maksud agar relasi yang semula bersifat many to many akan berubah menjadi one to many. 7. Complex relationship type Pada jenis relationship tersebut maka kita perlu membuat satu relation baru yang merepresentasikan relationship tersebut dan kemudian memasukkan atribut-atribut dari relasi tersebut ke dalam relation yang terbentuk. 8. Multi-valued attributes Pada masing-masing multi-valued attribute maka akan dibuat satu entity baru yang merepresentasikan multi-valued attribute tersebut. 30 o Memvalidasi relations menggunakan normalization Tahapan ini bertujuan untuk memvalidasi relaton-relation yang terdapat pada logical data model menggunakan teknik yang disebut dengan normalisasi. Normalisasi ini merupakan proses untuk mengembangkan model supaya tidak terjadi duplikasi data dalam logical data model yang dibuat. o Memvalidasi relations terhadap transaksi user Tahapan ini bertujuan untuk memastikan bahwa relation pada local logical data model mendukung transaksi-transaksi yang terjadi. Di sini kita mencoba untuk memecahkan transaksi-transaksi yang kemungkinan akan terjadi dalam kondisi sesungguhnya dengan berpedoman pada model yang telah dibangun. Bila seluruh transaksi tersebut terpecahkan, maka berarti model yang telah dihasilkan telah memenuhi apa yang diharapan user. o Menentukan integrity constraints Tahapan ini bertujuan untuk menentukan integrity constraint. Integrity constraint itu sendiri merupakan constraint yang kita ingin hilangkan agar database kita terhindar dari inkonsistensi data. Ada beberapa integrity constraint yang akan dihilangkan pada tahap ini yaitu bahwa masingmasing atribut harus selalu memiliki nilai yang valid dan memiliki batasan-batasan nilai yang bisa diterima sebagai suatu nilai yang benar. Selain itu ada dua constraint lagi yang harus dihilangkan yaitu bahwa primary key pada masing-masing entity type tidak boleh bernilai NULL 31 dan bahwa masing-masing foreign key pada entity type memiliki pasangan nilainya pada parent relation. o Mengkaji ulang local logical data model dengan user Tahapan ini bertujuan untuk memastikan bahwa local logical data model dan supporting documentation yang terbentuk menggambarkan representasi nyata yang diinginkan oleh user. 2. Membangun dan memvalidasi global logical data model Langkah ini bertujuan untuk menggabungkan beberapa local logical data model yang telah terbentuk pada langkah sebelumnya menjadi sebuah global logical data model yang merepresentasikan perusahaan secara keseluruhan. Setelah itu, maka model tersebut perlu divalidasi untuk memastikan kebenaran model yang dihasilkan. Ada beberapa hal yang dilakukan pada langkah ini yaitu sebagai berikut: a. Menggabungkan local logical data models ke dalam global model Tahapan ini bertujuan untuk menggabungkan masing-masing local logical data model yang telah terbentuk sebelumnya menjadi sebuah global logical data model. b. Memvalidasi global logical data model Seperti yang telah kita lakukan pada masing-masing local logical data model, maka pada global logical data model ini kita juga akan memvalidasi relation-relation yang terbentuk pada global logical data model dengan menggunakan teknik yang disebut normalisasi untuk 32 memastikan bahwa model tersebut mendukung transaksi-transaksi yang terjadi. c. Memeriksa untuk perkembangan di masa yang akan datang Pada tahap ini kita akan menentukan apakah ada perubahan-perubahan signifikan di masa yang akan datang dan untuk memperkirakan apakah global logical data model yang terbentuk dapat mengakomodasi perubahan-perubahan tersebut. d. Mengkaji ulang global logical data model dengan users Pada tada tahap ini kita ingin memastikan apakah global logical data model yang terbentuk adalah representasi sesungguhnya dari perusahaan. 2.1.2.5.3 Physical Database Design Menurut Connolly-Begg (2005, p497), physical database design adalah suatu proses menghasilkan sebuah deskripsi dari database pada secondary storage. Proses ini mendeskripsikan base relation, file organization, dan index yang digunakan untuk mencapai akses yang efisien pada data dan proses ini juga berfokus pada integrity constraint serta security. Pada physical database design terdapat beberapa langkah yang harus dilalui yaitu: 1. Translasi global logical data model untuk target DBMS Langkah ini bertujuan untuk menghasilkan relational database schema dari global logical data model sehingga dapat diimplementasikan dalam target DBMS. Ada beberapa tahapan dalam langkah pertama ini meliputi: 33 a. Design base relations Tahap ini bertujuan untuk merepresentasikan base relation yang teridentifikasi dalam global logical data model ke dalam target DBMS. b. Design representation of derived data Tahap ini bertujuan untuk menentukan bagaimana cara merepresentasikan derived data yang terdapat dalam logical data model ke dalam target DBMS. Derived data adalah data yang dihasilkan dari operasi yang dilakukan pada lebih dari satu data atribut. c. Design enterprise constraints Tahap ini bertujuan untuk merancang enterprise contraint pada target DBMS. Enterprise constraint ini penting untuk dirancang agar data yang ada pada database kita selalu dalam kondisi valid. 2. Design physical representation Langkah ini bertujuan untuk menentukan organisasi file yang optimal untuk menyimpan base relation yang terbentuk dan index-index yang dibutuhkan untuk mencapai performance yang bagus dimana merupakan cara relation dan tuple disimpan dalam secondary storage. Ada beberapa faktor penyebab kenapa kita perlu mengukur efisiensi organisasi file. Pertama adalah bahwa dalam implementasinya, transaksi pada sistem kita bisa berjumlah sangat banyak dan yang kedua adalah bahwa response time yang terkait dengan banyaknya transaksi dalam suatu waktu menjadi tolok ukur keberhasilan aplikasi yang kita buat. Terakhir adalah bahwa kita harus berusaha 34 meminimalisasi penggunaan disk storage. Ada beberapa tahap yang harus dilakukan pada langkah ini meliputi: a. Analisa transaksi Tahap ini bertujuan untuk mengerti kegunaan dan fungsi dari transaksitransaksi yang akan berlangsung pada database dan untuk menganalisa transaksi-transaksi yang penting. Hal ini penting agar kita dapat membuat perancangan database yang efektif. Kegiatan yang dilakukan pada tahap ini di antaranya adalah memetakan transaction path dari relation. Kemudian setelah itu kita memperkirakan frekuensi kemunculan record dalam suatu relation secara rata-rata dan maksimal serta juga memperkirakan frekuensi join yang akan terjadi antara relation yang satu dengan relation lainnya. b. Memilih file organizations Tahap ini bertujuan untuk menentukan organisasi file yang efisien untuk masing-masing base relation. Tahapan ini terkadang menjadi tidak terlalu krusial untuk dilakukan karena jarang sekali ditemukan DBMS yang memungkinkan kita untuk mengeset organisasi file dari DBMS tersebut. c. Memilih indexes Tahap ini bertujuan untuk menentukan apakah index diperlukan untuk meningkatkan performansi sistem. Index dapat meningkatkan performansi karena index memudahkan DBMS dalam mengambil data dalam setiap query yang dilakukan. 35 d. Mengestimasi disk space requirements Tahap ini bertujuan untuk memperkirakan jumlah disk space yang diperlukan untuk database kita. 3. Design user views Langkah ini bertujuan untuk merancang user view yang diidentifikasi selama proses requirement collection and analysis. View ini penting artinya dalam kaitannya dengan security karena dengan kita mendesain view yang berbedabeda untuk masing-masing kelompok user, maka kita mencegah user untuk mengakses apa yang tidak seharusnya diakses. 4. Design security measures Langkah ini bertujuan untuk merancang security sistem dengan maksud untuk mempertahankan system security dan data security. 2.1.2.6 Normalisasi 2.1.2.6.1 Pengertian Normalisasi Normalisasi memberikan panduan yang sangat membantu bagi pengembang untuk mengembangkan struktur tabel yang kurang efisien menjadi efisien dan kompatibel bagi program DBMS. Struktur tabel yang kurang efisien tersebut biasanya disebabkan karena adanya anomali pada tabel tersebut Suatu desain database harus memenuhi kondisi untuk tidak mengandung anomali, yaitu suatu kejanggalan dari suatu penempatan atribut tertentu dari suatu obyek data. Menurut Willis (2000, p69) normalisasi adalah proses menggunakan metodemetode formal untuk mengeliminasi data-data berulang, dan untuk memisahkan data menjadi tabel-tabel yang saling berhubungan. 36 2.1.2.6.2 Bentuk Normal 1. Bentuk Normal Pertama (1st NF) Suatu bentuk dimana sudah tidak ada kelompok repeating group dan sudah memiliki primary key. Suatu data dikatakan un-normalized, jika didalamnya mengandung kelompok berulang (repeating group), sehingga untuk membentuk normalisasi pertama (1st NF) repeating group harus dihilangkan. Suatu relation dikatakan dalam bentuk normal pertama jika dan hanya jika setiap atribut bernilai tunggal bagi setiap record. 2. Bentuk Normal Kedua (2nd NF) Semua atribut yang ada bergantung penuh terhadap primary key. Dapat dihasilkan dengan melihat apakah ada atribut bukan primary key yang merupakan fungsi dari sebagian primary key (partial dependence). Dalam normalisasi kedua (2nd NF) setiap atribut yang tergantung parsial ini harus dipisahkan dengan mengikutsertakan determinannya. Suatu relasi dikatakan berada pada bentuk normal kedua jika dan hanya jika : - Berada pada bentuk normal pertama - Semua atribut non key memiliki ketergantungan sepenuhnya pada primary key 3. Bentuk Normal Ketiga (3rd NF) Tidak ada atribut lain selain primary key bergantung transitif terhadap primary key. Pengujian terhadap 3rd NF dilakukan dengan cara melihat apakah terdapat atribut non key yang tergantung fungsional terhadap atribut non key yang lain (disebut ketergantungan transitif atau transitive dependence). Dengan cara 37 yang sama, maka setiap ketergantungan transitif dipisahkan. Suatu relasi dikatakan berada pada bentuk normal ketiga jika dan hanya jika : - Sudah berada pada bentuk normal kedua - Setiap atribut non key tidak memiliki ketergantungan transitif pada primary key 3rd NF sudah cukup bagus dalam arti bahwa anomali yang dikandungnya sudah sedemikian minimum (hampir tidak ada). 4. Bentuk Normal Boyce-Codd (Boyce-Codd Normal BCNF) Aturan Bentuk normal Boyce-Codd (BCNF) menurut Connoly dan Begg (2002,p398). “A relation is in BCNF, if and only if, every determinant is a candidate key”. Yang dapat diartikan, “Sebuah relasi disebut BCNF jika dan hanya jika setiap determinannya adalah sebuah candidate key” Untuk menguji apakah suatu relasi sudah dalam BCNF, dilakukan identifikasi semua determinan dan memastikan bahwa determinan tersebut adalah candidate key. Determinan adalah sebuah atribut. atau kumpulan atribut. dimana beberapa atribut yang lain masih bergantung secara fungsional penuh (full functionally dependent). Perbedaan antara 3Nfdan BCNF dalam hal ,functional dependency A B .3NFmengijinkan ketergantungan ini dalam sebuah relasi jika B adalah atribut primary key dan A bukan candidate key. Sedangkan dalam BCNF ketergantungan ini tetap ada di dalam sebuah relasi. dimana A harus sebuah candidate key. 38 5. Bentuk Normal Keempat (Fourth Nortnal Forni / 4NF) Aturan bentuk nonnal ke-empat ( 4NF ) menurut Connoly dan Begg (2002,pp407-408), "A relation that is in Boyce-Codd normal form and contains no nontrivial multi valued dependencies" Yang dapat diartikan, "Sebuah relasi dalam Boyce Codd normal form (BCNF) dan tidak mengandung ketergantungan multivalued nontrivial (nontrivial multi valued dependencies ). Bentuk normal ke-empat ( 4NF ) merupakan bentuk yang lebih kuat dari BCNF dimana 4NF mencegah relasi dari nontrivial multi-valued dependency dan data redundancy. Normalisasi dari BCNF ke 4NF meliputi pemindahan multivalued dependency dari relasi dengan menempatkan atribut dalam sebuah relasi baru bersama dengan determinan. Multi-valued dependency (4NF) menggambarkan ketergantungan antara atribut-atribut dalani suatu relasi. 6. Bentuk Normal Kelima (Fifth Normal Form / 5NF) Aturan bentuk normal ( 5NF ) menurut Connoly dan Begg (2002,p410), "A relation that has. No join dependency". Yang dapat diartikan, "Sebuali relasi yang tidak mempunyai ketergantungan gabungan (join dependency). Join dependency menggambarkan sebuall tipe ketergantungan. Sebagai contoh. untuk sebuall relasi R dengan subset-subset atribut dari R yang dimisalkan dengan A.B....,Z sebuah relasi R menunjukkan join dependency, jika dan hanya jika, setiap nilai dari R sama dengan gabungan dari proyeksi proyeksinya pada A,B, ... ,Z 39 2.2 Teori Khusus 2.2.1 Terminologi Sistem Informasi Proyek dalam Proses Bisnis Perusahaan 2.2.1.1 Pengertian Sistem Menurut David L. Olson (2001, p7), sistem adalah kumpulan bagianbagian yang saling berkaitan dan keseluruhan bagian tersebut bekerja secara bersama-sama untuk mencapai suatu tujuan. Menurut McLeod (2001, p11), sistem adalah sekelompok elemen yang terintegrasi dengan maksud yang sama untuk mencapai suatu tujuan. Suatu sistem biasanya terdiri dari komponen-komponen yang dihubungkan untuk memudahkan aliran informasi. Istilah ini sering dipergunakan untuk menggambarkan suatu set entitas yang berinteraksi. Sebuah sistem mempunyai karakteristik sebagai berikut: - Komponen-komponen - Batas sistem - Lingkungan di luar sistem - Penghubung - Masukan - Keluaran - Pengolah - Sasaran - Tujuan 40 2.2.1.2 Pengertian Estimasi Nilai Menurut Iman Soeharto (National Estimating Society - USA), estimasi (perkiraan nilai) adalah seni memperkirakan kemungkinan jumlah nilai yang diperlukan untuk suatu kegiatan yang didasarkan pada informasi yang tersedia pada waktu itu. http://azwaruddin.blogspot.com/2008/06/definisi-estimasibiaya.html 2.2.1.3 Pengertian Proyek Kegiatan proyek dapat diartikan sebagai satu kegiatan sementara yang berlangsung dalam jangka waktu terbatas, dengan alokasi sumber daya tertentu dan dimaksudkan untuk melaksanakan tugas yang sasarannya telah di gariskan dengan jelas. Didalam proses mencapai tujuan tersebut telah ditentukan batasan yaitu besarnya biaya (anggaran) yang dialokasikan, dan jadwal serta mutu yang harus dipenuhi. Ketiga batasan diatas disebut tiga kendala (triple constraint). Hal ini merupakan parameter penting bagi penyelenggara proyek yang sering diasosiasikan sebagai sasaran proyek. http://l-civil.blogspot.com/2009/05/pengertian-proyek.html 2.2.1.4 Diagram Alir Data (DAD) DAD adalah suatu tool yang menggambarkan aliran data yang melalui suatu sistem serta proses yang dilakukan sistem tersebut. DAD adalah tool yang digunakan untuk merepresentasikan suatu sistem yang otomatis atau manual dengan menggunakan gambar yang berbentuk jaringan grafik. 41 SIMBOL Tabel 2.1 Simbol-simbol Bagan Alir dokumen NAMA PENJELASAN Menggambarkan semua jenis Dokumen dokumen, yang merupakan formulir yang digunakan untuk merekam data terjadinya suatu transaksi. Menggambarkan dokumen asli dan Dokumen dan tebusannya. Nomor lembar tebusannya dokumen dicantumkan disudut kanan atas. Berbagai dokumen. Catatan Penghubung pada halaman yang sama (on-page connector) Penghubung pada halaman yang berbeda (off-page connection) Kegiatan manual Keterangan Komentar Menggambarkan berbagai jenis dokumen yang digabungkan bersama didalam suatu paket. Nama dokumen dituliskan didalam masing-masing simbol dan nomor lembar dokumen dicatumkan disudut kanan atas simbol dokumen yang bersangkutan Menggambarkan catatan akutansi yang digunakan untuk mencatat data yang direkam sebelumnnya didalam dokumen atau formulir. Nama catatan akutansi dicantumkan didalam simbol ini Digunakan untuk menghubungkan aliran dokumen yang terhenti di suatu lokasi pada halaman tertentu dan kembali berjalan dilokasi lain pada halaman yang sama dengan memperhatikan nomor yang tercantum pada simbol. Jika untuk menggambarkan bagan alir diperlukan lebih dari satu halaman, simbol ini harus digunakan untuk menunjukan kemana bagan alir terkait. Simbol ini digunakan untuk menggambarkan kegiatan manual, uraian singkat kegiatan manual dicantumkan didalam simbol ini. Simbol ini memungkinkan alih syistem menambahkan keterangan untuk memperjelas pesan yang disampaikan dalam bagan air. 42 Arsip sementara Arsip permanen Keputusan Mulai atau berakhir (Terminal) Menunjukkan tempat penyimpanan dokumen yang dokumennya akan diambil kembali dari arsip tersebut dimasa yang akan datang. Menggambarkan arsip permanent yang merupakan tempat penyimpanan dokumen yang tidak akan diproses lagi dalam sistem yang bersangkutan. Simbol ini menggambarkan keputusan yang harus di buat dalam proses pengolahan data. Simbol ini menggambarkan awal dan akhir dari suatu sistem.