BAB 2 LANDASAN TEORI
2.1 Teori-teori Umum 2.1.1 Data Menurut McFadden, Presscott, dan Hoffer (2005,p5), data adalah fakta yang telah diketahui, dikumpulkan dan disimpan dalam media komputer. 2.1.2 Sistem dan Analisis Sistem Menurut Pressman (2003, p246), sistem didefinisikan sebagai kumpulan dari elemen-elemen yang berinteraksi untuk mencapai tujuan dengan cara memproses informasi yang ada. Dalam menganalisis sistem ada beberapa tugas utama yang harus dilakukan, diantaranya adalah menentukan lingkup menganalisis
fakta.
Fakta
sistem,
mengumpulkan dan
merupakan bagian dari
informasi
yang
menunjukkan realita, situasi dan relasi yang menjamin analisis dan pemodelan. Pendekatan analisis sistem yang digunakan penulis antara lain : •
Pendeka tan Model-Driven Analysis Structured Analysis, Information Engineering, dan Object Oriented Analysis merupakan contoh dari Model-Driven Analysis. Pendekatan ini menggunakan gambar untuk
mengkomunikasikan masalah bisnis,
kebutuhan dan solusinya. Contoh model yang cukup dikenal adalah flowchart. Banyak perusahaan mengembangkan pendekatan analisis terstruktur dan Information Engineering dengan model datanya Entity
9
10
Relationship Diagram (ERD). Information Engineering berperan untuk menentuka n sebua h pendekatan yang menggabungka n da n menyamaka n data dan model proses. Sistem analis menggambar ERD untuk menggambarkan
data
mentah
dari
sistem
sebelum
mereka
menggambarkan DFD untuk mengilustrasikan data yang akan diambil, digunakan, dan disimpan. Dasar dari analisis dan perancangan berorientasi objek adalah untuk menekankan perumusan masalah dan penyelesaian logis dari sudut pandang objek (benda, konsep, dan entity). Dalam perancangan berorientasi objek, ditekankan pada pendefinisian objek logis perangkat lunak yang akan diimplementasikan dalam bahasa pemprograman berorientasi objek. •
Requirement Discovery Methods Merupakan proses dan teknik yang digunakan oleh sistem analis untuk menentukan masalah dari sistem dan kebutuhan pemecahan masalah dari kelompok user. Kebutuhan sistem be rgantung pada ke mampuan sistem analis untuk menemukan masalah dan peluang yang terdapat pada sistem yang berjalan. Bentuk da ri Requirement Discovery yang digunakan oleh penulis antara lain : •
Teknik Fact Finding Merupakan
proses
mengumpulkan
fakta
mengenai
sistem,
requirement, dan preferensi dengan menggunakan teknik interview. Penggunaan fact-finding merupakan bagian dari penerapan Database
11
Lifecycle. Secara krusial, hal ini dibutuhkan sebelum perencanaan database, mendefinisikan sistem, mengumpulkan dan menganalisis kebutuhan. Teknik-teknik yang digunakan didalam fact finding antara lain : •
Mempelajari Dokumentasi Pada tahap ini, dokumentasi dari sistem sebelumnya dan perancangan yang dilakukan oleh sistem analis terdahulu akan dipelajari. Dokumentasi yang dimaksud di sini meliputi dok umentasi tentang program, dokumentasi perancangan sistem, manual pengoperasian, manual bimbinga n, dan berbagai jenis flowchart dan diagram dalam perancangan. Melalui proses mempelajari dokumentasi-dokumentasi yang suda h ada diharapka n analis menge rti uraian sistem yang sedang berjalan, uraian detail permasalahan perusahaan da n database yang dibutuhka n.
•
Interview Teknik ini sangat populer dan umum digunakan. Teknik interview ini memungkinkan pengumpulan informasi secara individual secara face-to-face. Tujuan dari interview adalah menemukan fakta baru, verifikasi fakta, memperoleh data sampai pada end-user, identifikasi kebutuhan dan pengumpulan ide dan opini. Salah satu tipe interview yaitu pertanyaan terbuka di mana pewawancara meng-interview mengikuti respon dari sampel dan pertanyaan tertutup di mana
12
jawaban telah dispesifikasi dan menjadi jawaban pendek atau pilihan terhadap responden. •
Observasi organisasi saat pengoperasian Teknik ini sangat efektif untuk mengerti sistem, mudah digunakan untuk memvalidasi data terkumpul terhadap berbagai pertanyaan dan kompleksitasnya sesuai kebutuhan sistem berdasarkan penjelasan end-user. Teknik ini memungkinkan analisis untuk berpartisipasi atau memperhatikan kegiatan tiap orang dalam produksi saat mempelajari sistem. Keuntungan menggunakan teknik ini adalah : • Memungkinkan memvalidasi dan pemeriksaan data berdasarkan fakta. • Observer dapat secara pasti melihat apa yang harus dilakukan. • Observer dapat memperoleh penjelasan mengenai lingkungan fisik data. • Observer dapat mencoba peralatan secara langsung. • Relatif murah. Kerugian menggunakan teknik ini adalah : • Belum tentu diketahui adanya perbedaan / masalah saat melakuka n obs ervasi. • Saat observasi bisa terjadi kehilangan informasi atau adanya perbedaan dengan kondisi normal.
13
• Beberapa task yang diinginka n belum tentu terekam saat observasi. • Tidak praktis. •
Penelitian Menggunakan informasi terkini seperti jurnal komputer, buku referensi, dan internet. Teknik
ini dapat digunakan dengan
mengunjungi perusahaan atau organisasi yang memiliki pengalaman yang sama. Jika perusahaan tersebut mau membagi pengalamannya, maka informasi yang sangat berharga dapat diperoleh dan menghemat waktu dan biaya yang digunakan selama masa pengembangan. Beberapa keuntungan menggunakan teknik ini adalah: • Selalu memperoleh solusi ilmiah. • Peneliti memperoleh solusi berdasarkan hasil perbandingan dengan masalah serupa di tempat lain. • Peneliti akan menggunakan pengembangan sistem berdasarkan informasi up to date. Kerugian menggunakan teknik ini antara lain : • Membutuhka n waktu yang lama. • Membutuhkan lebih banyak akses informasi. • Bisa
tidak
menolong
untuk
pe mecahan
dokum entasi yang buruk da ri pe rusahaan.
masalah karena
14
2.1.3 Perancanga n Sistem Menurut Whitten (2004, p186), perancangan sistem adalah sebuah teknik pemecahan masalah (pada analisis sistem) yang saling melengkapi dengan merancang ulang komponen-komponen dari sistem menjadi seperti pada awalnya dengan mengharapkan peningkatan dalam sistem tersebut. Hal ini meliputi penambahan, penghilangan, atau perubahan pada suatu bagian yang berkaitan dengan sistem aslinya.
2.1.4 Analisis Sistem Informasi Analisis sistem informasi adalah sejumlah tahap-tahap pengembangan dalam sebuah proyek pengembangan sistem informasi, yang diutamakan pada masalah bisnis dan kebutuhan, serta tidak bergantung kepada teknologi yang akan digunakan pada pemecahan masalah yang dimaksud.
2.1.5 Database 2.1.5.1 Penge rtian Database Database adalah kumpulan data, yang dapat digambarkan sebagai aktifitas dari sebuah organisasi dan diatur dengan suatu cara tertentu sehingga sebuah aplikasi program komputer dapat dengan mudah mengakses informasi yang terdapat di dalamnya.
15
Menurut Atzeni(2003,p2) database adalah sekumpulan data yang digunakan untuk merepresentasikan informasi yang diinginkan dari sistem informasi. Menurut Connolly (2002,p14) database adalah suatu kumpulan da ta atau file yang dapat digunakan bersama-sama yang secara logika terkait atau saling berhubungan satu sama lain dan uraian tentang data tersebut dirancang untuk memenuhi kebutuhan informasi suatu organisasi. Suatu database merepresentasikan entities, attributes da n relationship antar entitas. Entity ada lah sebuah ob jek yang keberadaannya dapat dibedakan terhadap objek lain. Attribute adalah karakteristik yang menjabarkan tentang suatu objek yang disimpan di da lam database. Relationship ada lah hubungan yang terjadi antar entitas. Keuntungan menggunakan database diantaranya : 1.
Mengurangi duplikasi data (Data Redundancy)
2.
Meningkatkan hubungan data (Data Relatibilty)
3. Menentukan kualitas informasi, seperti keakuratan, relevan, dan tepat pada waktunya
2.1.5.2
Database Management System (DBMS)
Database Management System adalah sebuah software system yang memungkinkan user
mendefinisi,
membentuk
dan mengatur
16
database dan yang mengendalikan akses ke database. DBMS berinteraksi dengan pengguna aplikasi program dan database. Fasilitas- fasilitas yang disediakan oleh DBMS antara lain: • Data
Definition
Language
(DDL),
yang berguna
untuk
menspesifikasikan tipe data, struktur dan constraint data. Semua spesifikasi di simpan dalam database. • Data Manipulation Language (DML), yang berguna untuk memberikan fasilitas query data. • Pengenda lian akses database, antara lain mengontrol : o Keamanan sistem : mencegah user yang tidak memiliki hak akses untuk mengakses database. o Integritas sistem : menjaga konsistensi data. o Pengenda lian share data. o Backup dan Recovery System. o Katalog deskripsi data dalam database. o Mekanisme View, yang berfungsi untuk menyediakan data yang hanya diing inka n da n dipe rluka n user. Fungsi- fungsi DBMS menurut Codd(1998) yaitu : • Penyimpanan data, perolehan kembali, dan memperbaharui suatu DBMS harus dilengkapi para pemakai dengan kemampuan untuk menyimpan, mendapatkan kembali, dan memperbaharui data di da lam database.
17
• Sebuah katalog yang dapa t diakses. S uatu DBMS harus dilengkapi dengan suatu katalog di mana uraian data item disimpan dan dapat diakses oleh para pemakai. Suatu katalog atau kamus data adalah suatu tempat penyimpanan informasi yang menggambarkan data itu di dalam database, di mana hal itu ada lah metadata (data tentang data). • Transaks i pe ndukung suatu DBMS harus dilengkapi suatu mekasnisme yang akan memastikan bahwa semua update sesuai dengan traksaksi yang ditentuka n. • Jasa pengendalian concurrency ada lah suatu DBMS harus dilengkapi dengan suatu mekanisme untuk memastikan bahwa database itu di-update dengan tepat ketika para pemakai sedang memakai/meng-update database itu secara bersamaan. • Recovery Service, suatu DBMS harus dilengkapi suatu mekanisme untuk mengembalikan database seandainya database itu menjadi rusak. • Jasa otorisasi, suatu DBMS harus dilengkapi suatu mekanisme untuk memastikan bahwa hanya user yang diberi hak untuk dapat mengakses database itu. • Pendukung komunikasi data, suatu DBMS harus mampu untuk mengintegrasikan
dengan
perangkat
lunak
komunikasi.
Kebanyakan para pemakai mengakses database
itu dari
18
workstation. Terkadang station kerja ini dihubungkan secara langsung ke computer yang menjadi hosting DBMS. • Jasa integritas, suatu DBMS harus melengkapi sebuah makna untuk memastikan bahwa kedua data ada di dalam database da n yang berubah ke data mengikuti aturan tertentu. Database integrasi mengacu pada ketepatan dan konsistensi dari data disimpan, hal itu dapat diperlakukan sebagai perlindungan database. • Jasa untuk mempromosikan ketidaktergantungan data; suatu DBMS harus meliputi fasilitas yang mendukung program dari struktur yang nyata dari database itu. • Utility Services, suatu DBMS pe rlu menyediaka n seperangka t utility service. Utility program akan membantu DBA untuk mengurus database secara efektif. Komponen-ko mpo nen DBMS : • Hardware, yaitu berupa PC hingga jaringan komputer-komputer. • Software, yaitu DBMS, sistem operasi, software jaringa n (bila diperlukan) dan juga program-program aplikasi. • Data yang digunakan oleh organisasi dan deskripsi dari data disebut schema. • Prosedur, yaitu instruksi dan aturan yang mengatur perancangan dan penggunaan database.
19
• People, antara lain : • Data Administrator, seorang yang berwenang untuk membuat keputusan strategis dan kebijakan mengenai data yang ada. • Database Administrator, menyediakan dukungan teknis untuk implementasi keputusan tersebut, dan bertanggung jawab atas keseluruhan kontrol sistem pada level teknis. • Desainer Database (Logikal dan Fisikal), perancang sistem database pada tahap konseptual dan logikal. • Programmer Aplikasi, bertanggungjawab untuk membuat aplikasi database dengan menggunakan bahasa pemograman yang ada. • End Users. • Naive : User yang tidak perlu tahu mengenai database da n DBMS. Hanya menggunakan program aplikasi. • Sophisticated : User yang familiar dengan struktur database dan DBMS. Keuntungan DBMS : • Mengontrol redundansi data • Konsistensi data • Lebih banyak informasi dari jumlah data yang sama • Share data • Meningkatkan integritas data
20
• Meningkatkan sekuritas • Standard pelaksanaan (format data, penamaan, prosedur update) • Economy of scale (Data operasional perusahaan dijadikan satu, kemudian aplikasi dibuat dengan menggunakan data source yang tunggal tersebut. Sehingga akan menghemat biaya.) • Keseimbangan konflik kebutuhan (Database untuk berbagai kepentingan) • Meningkatkan aksesibilitas data da n responsiveness • Meningkatkan produktivitas • Meningkatkan maintenance melalui data independence (Data menjadi globa l) • Meningkatkan konkurensi (mengurangi loss information da n loss integration) • Meningkatkan layanan backup dan recovery Kerugian DBMS : • Kompleksitas • Ukuran • Biaya DBMS • Biaya penambahan hardware • Biaya konversi (biaya pelatihan, biaya staf spesialis) • Performance (tidak bisa dijalankan secepat yang diinginkan)
21
2.1.5.3 Database Application Lifecycle Dalam Database Application
Lifecycle, database
merupaka n
komponen dasar dari organisasi besar dengan sistem informasi dimana pengembangan atau pemakaiannya harus dilihat dari perspektif yang lebih luas berdasarkan kebutuhan organisasi. Hal penting yang perlu diperhatikan dalam Database Application Lifecycle adalah bahwa tingkatannya tidak sepenuhnya sequential, ada beberapa tingkatan yang berulang dengan alur balik (feedback loop). Hal ini dapat ditemukan pada tingkatan perancangan database yang membutuhkan tambahan kumpulan kebutuhan dan analisis (requirement collection and analysis).
22
Gambar 2.1 Database Application Lifecycle
23
• Database Planning Menurut Conolly (2002, p273-274) 3 hal penting dalam perencanaan basis data adalah: Identifikasi dari tujuan dan rencana perusahaan dengan
•
penentuan kebutuhan sistem informasi berikutnya. Evaluasi dari sistem informasi sekarang ini untuk
•
menentukan kelebihan
dan kelemahan yang ada
sekarang ini. Penilaian
•
dari
kesempatan-kesempatan
teknik
informatika yang mungkin menghasilkan keuntungan kompetitif. Langkah- langkah dalam perencanaan basis data : •
Mendefinisikan pernyataan misi (mission statement) yang mendefinisikan tujuan utama aplikasi basis data. Mission statement membantu memperjelas tujuan proyek basis data dan menyediakan jalur yang lebih jelas terhadap pembuatan aplikasi basis data yang dibutuhkan dengan efisien dan efektif.
•
Mende finisika n tujuan misi (mission objectives) yang mengidentifikasikan suatu tugas khusus yang harus didukung basis data. Mission statement dan mission objectives dapat disertai beberapa informasi tambahan
24
yang menjelaskan secara umum apa yang harus dilakukan,
sumber
mana
yang diperlukan untuk
melakukannya, dan berapa biaya yang dikeluarkan untuk itu semua. Perencanaan basis data juga harus meliputi pengembangan standar yang mengatur bagaimana data akan dikumpulkan, bagaimana format harus ditentukan, dokumentasi apa saja yang akan diperlukan, dan bagaimana rancangan dan pelaksanaan akan terjadi. • System Definition System Definition menjelaskan lingkup dan batasan aplikasi basis data dan user view utama (Connolly, 2002, p274) . User view menggambarkan apa yang dibutuhkan oleh aplikasi basis data dari sudut pandang jabatan tertentu, seperti manajer atau pengawas, maupun dari sudut pa nda ng bidang aplikasi perusahaan, seperti pemasaran, personalia, atau pengawasan persediaan, dalam hubungannya de ngan data yang aka n disimpa n dan transaks i yang akan dijalankan terhadap data itu (Connolly, 2002, p275). • Requirement Collection and Analysis Proses pengumpulan dan analisa informasi mengenai bagian organisasi
yang
didukung
oleh
aplikasi
database
dan
25
menggunakan informasi tersebut untuk identifikasi kebutuhan user aka n sistem yang baru. • Database Design Menurut Connolly (2002,p279), perancangan database adalah proses pe mbuatan sebuah database yang mendukung ope rasi da n tujuan dari pe rusahaan. Metodologi perancangan adalah sebuah pendekatan terstruktur yang menggunakan teknik, prosedur, alat bantu, dan bantuan dokumentasi yang mendukung proses perancangan. Metodologi perancangan database dibagi menjadi tiga tahapa n yaitu: • Conceptual Database Design Menurut Connolly (2002,p419), Conceptual Database Design adalah proses pembentukan model dari informasi yang digunakan da lam enterprise, independen dari keseluruhan aspek fisik. Model data konseptual merupakan sumber informasi untuk fase design logical. Model data tersebut dibuat dengan menggunakan dokumen dari spesifikasi kebutuhan(requirement spesification) pemakai. Keseluruhan proses dari pengembangan model data adalah diuji dan divalidasikan dari kebutuhan pemakai. Conceptual data model dari organisasi adalah sumber informasi untuk tahapa n selanjutnya yang dinamaka n Logical Database Design. Hasil akhir dari conceptual database design berupa
26
identifika si tipe entity, identifikasi tipe relationship, identifikasi dan hubungan atribut dengan tipe entity atau tipe relasi, menentukan atribut domain, dan menentukan candidate key dan primary key yang kesemuanya didasarkan pada spesifikasi kebutuhan. Beberapa langkah untuk membangun conceptual database design : • Menentuka n tipe entity Langkah pertama adalah menentukan objek-objek
yang
diinginkan oleh user, yaitu jenis-jenis entity yang diperlukan da lam view. Dalam penentuan ini, biasanya berdasarkan kepada kata benda atau frasa kata benda yang disebutkan. • Menentuka n tipe relasi Menentuka n relasi yang pe nting yang terjadi di antara entity yang telah ditentukan. Biasanya relasi yang terjadi ditandai dengan kata kerja atau eksperesi kata kerja. • Menentukan dan menghubungkan atribut dengan entity atau tipe relasi yang telah kita pilih untuk direpresentasikan dalam database. • Menetapka n domain atribut Perancang harus menetapka n do main (kisaran nilai yang diperbolehkan) untuk setiap atribut yang ada dalam local conceptual data model.
27
• Menentukan atribut candidate key dan atribut primary key Menentuka n semua candidate key yang mungkin untuk setiap jenis entiti dan kemudian dipilih salah satu untuk menjadi primary key. Apabila candidate key masih diperlukan maka disebut alternate key. • Mempertimbangkan pemakaian enhanced modeling concepts (optional) Dalam langkah ini perancang akan melanjutkan pengembangan dengan
ER
model
seperti
specialization/generalization,
aggregation dan composition. • Memeriksa model terhadap redundancy Dalam langkah ini perancang akan memeriksa kembali hubungan one-to-one (1:1) dan menghilangkan redundancy relation. • Memvalidasikan local conceptual model terhadap transaksi user Langkah ini memastikan local conceptual model mendukung transaks i- transaksi yang dipe rluka n pada view dengan cara menggambarkan transaksi atau dengan menggunakan alur transaksi. • Meninjau ulang local conceptual data model yang dihasilka n terhadap user.
28
• Meninjau kembali local conceptual data model dengan user untuk memastikan bahwa model tersebut telah benar untuk menggambarkan view.
•
Logical Database Design Menurut Connolly (2002,p419), Logical Database Design adalah proses membangun sebuah model dari informasi yang diperoleh dari sebuah organisasi berdasarkan model data khusus (specific data model), tetapi tidak bergantung kepada hal yang berkaitan dengan DBMS dan pertimbangan fisik lainnya. Model data logical didasarkan pada target model data untuk database (sebagai contoh: model data relasional).
Keseluruhan proses dari
pengembangan model data logical adalah diuji berdasarkan kebutuhan pemakai. Untuk menguji kebenaran dari model data logical menggunakan normalisasi dimana akan dipastikan hubungan yang diperoleh dari model data tidak memperlihatkan kelebihan
atau
redundancy,
yang
bisa
menyebabkan
penyimpangan update ketika diimplementasikan. Model data logical merupakan sumber informasi untuk tahapan selanjutnya yang dina maka n Physical Database Design. Langkah-langka h dalam perancangan logical database,antara lain:
29
• Membangun dan memvalidasikan local logical data model untuk setiap user view Ada beberapa langkah yang harus dilakukan, yaitu: •
Menghilangkan
features yang tidak
sesuai dengan
relational model Langkah ini dilakukan dengan menghilangkan tipe relasi: •
Many-to-many binary
•
Many-to-many recursive
•
Kompleks
•
Menghilangkan multi-valued atributes
•
Mengambil relasi-relasi untuk local logical data model
•
Menciptakan relasi untuk local logical data model untuk menggambarkan relasi antar entitas beserta atribut yang telah ditentukan.
•
Memvalidasikan relasi-relasi menggunakan normalisasi Langkah ini dilakukan untuk memperbaiki model sehingga dapat memenuhi semua constraint yang ada untuk menghindari duplikasi data yang tidak diinginkan. Tahaptahap normalisasi akan dijelaskan pada subbab 2.1.7.
•
Melakukan validasi terhadap relasi-relasi pada transaksi user
30
Langkah ini untuk mamastikan bahwa relasi pada logical data model mendukung transaksi yang diperlukan oleh view. •
Menentuka n integrity constraint yang diberikan dalam view. Ada lima jenis, yaitu:
•
•
Required data
•
Attribute domain
•
Entity intergrity
•
Referencial integrity
•
Enterprise constraint
Meninjau ulang local logical data model terhadap user Langkah ini memastikan local logical data model dan dokumentasi yang mendukung menggambarkan model sebagai representasi dari view. Membangun dan memvalidasikan global logical data model
•
untuk setiap user view. Tujuan dalam langkah ini adalah untuk mengkombinasikan individual local logical data models ke dalam single global logical data models yang menggambarkan perusahaan. Ada beberapa aktifitas dalam langkah ini, yaitu: •
Menggabungkan local logical data model menjadi global logical data model. Langkah ini dilakukan dengan
31
menggabungkan individual local logical data model menjadi sebuah global logical data model tunggal dalam perusahaan. •
Memvalidasikan global logical data model Langkah ini dilakukan untuk memvalidasi relasi yang terbe ntuk dari global logical data model dengan teknik normalisasi dan untuk memastikan data-data tersebut mendukung transaks i yang diperlukan. Langka h ini merupaka n langka h optional.
•
Memeriksa pertumbuhan data pada masa yang akan datang Langka h
ini
menentuka n
dilakuka n apaka h
de ngan
terdapat
tujuan
untuk
pe ruba han
yang
significant seperti yang telah diramalkan dan untuk memastika n global logical data model dapat menutupi masalah ini. •
Meninjau ulang global logical data model terhadap user Merupakan langkah terakhir dari perancangan logical database. Langkah ini dilakukan untuk memastikan bahwa global logical data model sudah merupakan representasi yang benar dari perusahaan.
32
•
Physical Database Design
Menurut Connolly
(2002,p419),
fase
ini
merupakan proses
pembuatan deskripsi dari suatu implementasi database pada secondary storage yang mendeskripsikan hubungan utama (base relation), organisasi file, indeks yang digunakan untuk mencapai akses data yang efisien, dan integrity constraint yang berhubungan, serta pertimbangan keamanan (security measure). Physical database merupakan tahap terakhir dari perancangan database di mana perancang
memutuskan
bagaimana
database
tersebut
diimplementasikan secara fisik dari logical database design. Aktifitas dari physical database design adalah menterjemahkan global logical data model ke dalam sasaran DBMS, dimana dengan membuat base relation menggunakan DBDL (Database Design Language) yang tujuannya untuk memutuskan bagaimana representasi relasi utama yang diidentifikasikan dalam global logical data model ke dalam DBMS. Selain itu aktivitas lainnya adalah merancang constraint perusahaan untuk kegiatan transaksi (update and retrieve data) da n menentukan kebutuhan sumber daya sistem dan organisasi file. Ada beberapa langkah dalam fase ini, yaitu: • Menerjemahkan Global Logical Data Model menjadi sasaran DBMS • Merancang Base Relation
33
Langkah ini untuk memutuskan bagaimana merepresentasikan base relation dalam global logical data model pada sebuah target DBMS dengan menggunakan DBDL. • Merancang representasi dari data yang diambil Dalam
langkah
ini
akan
memutuskan
bagaimana
merepresentasikan derived data sementara dalam globa l logical data model pada sebuah target DBMS dengan menggunakan DBDL. • Merancang General Constraint Dilakuka n untuk merancang enterprise constraint untuk sasaran DBMS. • Merancang representasi secara fisik • Menganalisa transaksi Tujuannya adalah untuk mengerti kegunaan dari transaksi yang akan dijalankan database dan unt uk menganalisa transaks i yang penting. • Memilih organisasi file Untuk menentuka n file or ganisasi yang efisien untuk masingmasing base relation • Memilih Indeks Untuk
memutuskan
apakah
memperbaiki daya guna dari sistem
pertambahan
indeks
akan
34
• Memperkirakan kebutuhan besarnya media penyimpanan yang akan dibutuhka n oleh database • Merancang user view Untuk merancang user view yang diidentifikasikan selama proses pengumpulan kebutuhan dan analisis dari aplikasi relation database • Merancang meka nisme keamanan untuk user database. Merancang dan mendesain keamanan untuk basis seperti yang telah dispesifikasikan oleh user. Menurut Connolly, ada dua tipe keamanan database, yaitu keamanan sistem dan keamanan data. Keamanan sistem memberikan perlindungan terhadap akses dan pengunaan database pada tingkat sistem seperti username da n password.
Keamanan data
memberikan perlindungan
dan
penggunaan objek database seperti relasi dan view dan akses terhadap ob jek yang dapat dimiliki oleh user. • Mempertimbangkan kemungkinan terjadinya redudansi Menentuka n jika pe ngenalan reduda nsi pada controlled manner dengan me-relax peraturan normalisasi akan meningkatkan kinerja dari sistem. • Mengawasi dan menjalankan Operational System
35
Tujuannya adalah untuk memonitorkan operasi sistem dan memperbaiki petunjuk dari sistem untuk keputusan perancangan yang tidak tepat untuk menggambarkan perubahan syarat. • DBMS selection Menurut Connolly (2002,p284), DBMS selection adalah pemilihan DBMS yang tepat untuk mendukung aplikasi database. Tahaptahap utama untuk memilih DBMS: • Mende finisika n persyaratan studi referensi • Menda ftar dua atau tiga prod uk • Evaluasi prod uk • Rekomendasi pilihan dan laporan produk • Application Design Merancang
user
interface
da n
aplikasi
program
yang
menggunakan dan memproses database. Desain database da n aplikasi merupakan aktifitas paralel yang meliputi dua aktifitas penting, yaitu: • Transaction Design Kegunaan dari transaction design adalah untuk menetapkan dan keterangan karakteristik high-level da ri suatu transaks i yang dibutuhkan pada database, diantaranya: • Data yang akan digunaka n oleh transaks i • Karakteristik fungsional dari suatu transaksi
36
• Output transaksi • Keuntungannya bagi user • Tingkat kegunaan yang diharapkan Ada tiga tipe transaksi, yaitu: • Retrieval Transaction, digunakan untuk pemanggilan (retrieve) data untuk ditampilkan di layar atau menghasilkan suatu laporan. • Update Transaction, digunakan untuk menambahkan record baru, menghapus record lama, atau memod ifikasi record yang sudah ada di dalam database. • Mixed Transaction, meliputi pemanggilan dan perubahan data. • User Interface Design • Prototyping Membuat model kerja suatu aplikasi database yang dapat memvisualisasikan dan mengevaluasi bagaimana sistem akhir akan terlihat dan berfungsi. Tujuan pembuatan prototyping adalah untuk mengidentifikasi feature dari sistem yang berjalan dengan baik
atau
tidak,
memberikan
perbaikan-perbaikan
atau
penamba han feature baru, klarifikasi kebutuhan user, dan untuk evaluasi feasibilitas (kemungkinan yang akan terjadi) dari desain sistem khusus. • Implementation
37
Membuat definisi eksternal, conceptual da n internal database serta program aplikasinya. Implementasi database dicapai dengan menggunakan : • Data Definition Language untuk membuat skema database da n file database kosong. • Data Definition Language untuk membuat user view yang diinginkan. • 3GL dan 4GL untuk membuat program aplikasi. Termasuk transaksi database disertakan dengan menggunakan Data Manipulation Language, atau
ditambahkan pada bahasa
pemrograman. • Data Convertion and Loading Langkah ini tidak terdapat dalam penyusunan skripsi ini. • Testing Pengujian aplikasi diuji de ngan tujuan menemukan kesalaha n da n diperlakukan berlawanan dengan penjelasan persyaratan yang dijelaskan user. • Operational Maintenance Suatu proses pengawasan dan pemeliharaan sistem setelah instalasi. Pengawasan tersebut meliputi pengawasan performa sistem, pemeliharaan dan pembaharuan aplikasi database (jika
38
dibutuhkan), dan penggabungan kebutuhan baru ke dalam aplikasi database.
2.1.6 Entity-Relationship Modeling 2.1.6.1 Entity Types Konsep dasar dari Model ER adalah entity types, yaitu kumpulan dari objekobjek dengan sifat (property) yang sama, yang diidentifika si oleh enterprise mempunyai eksistensi yang independen. Keberadaannya dapat berupa fisik maupun abstrak. Entity occurrence adalah pengidentifikasian object yang unik dari sebuah entity types. Setiap entitas diidentifikasikan dan disertakan propertinya.
2.1.6.2 Relation Types Kumpulan keterhubungan yang mempunyai arti (meaningful associations) antara tipe entitas yang ada. Relationship occurrence, yaitu keterhubungan yang diidentifikasi secara unik yang meliputi keberadaan tiap tipe entitas yang berpartisipasi.
2.1.6.3 Derajat Relationship Derajat Relationship merupakan jumlah entitas yang berpartisipasi dalam suatu relationship. Derajat relationship terdiri dari : •
Binary Relationship, keterhubungan antar dua tipe entitas.
39
•
Ternary Relationship, keterhubungan antar tiga tipe entitas.
•
Quaternary Relationship, keterhubungan antar empat tipe entitas.
•
Unary Relationship, keterhubungan antar satu tipe entitas, dimana tipe entitas tersebut berpartisipasi lebih dari satu kali dengan peran yang berbeda. Kada ng disebut juga recursive relationship. Relationship dapat diberikan rule names untuk mengidentifikasikan keterkaitan tipe entitas da lam relationship.
2.1.6.4 Attributes Merupaka n sifat-sifat (property) dari sebuah entity atau relationship type. Attribute domain adalah himpuna n nilai yang diperbo lehkan untuk satu atau lebih atribut. Macam- macam 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
indepe nde n. •
Single-valued Attribute, yaitu atribut yang mempunyai nilai tunggal untuk setiap kejadian.
•
Multi-valued Attribute, yaitu atribut yang mempunyai beberapa nilai untuk setiap kejadian.
40
•
Derived Attribute, yaitu atribut yang memiliki nilai yang dihasilkan dari satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entitas.
2.1.6.5 Keys Ada beberapa macam key, yaitu: •
Super Key : Atribut unik yang mengidentifikasikan row.
•
Candidate Key : Atribut unik yang mengidentifikasikan table. Jumlah minimal
atribut-atribut
yang
dapat
meng- identifikasikan
setiap
kejadian/record secara unik. •
Primary Key : Atribut unik yang mengidentifikasikan setiap row dalam tabel.
Candidate key yang dipilih untuk meng- identifikasikan setiap
kejadian/record dari suatu entitas secara unik. •
Alternate Key : Candidate key yang tidak terpilih menjadi primary key.
•
Composite Key yaitu candidate key yang terdiri dari dua atau lebih atribut.
•
Foreign Key : Atribut sebuah tabel yang menggabungkan diri ke tabel lain.
2.1.6.6 Strong and Weak Entity Types Strong Entity Type, yaitu entitas yang keberadaannya tidak bergantung pada entitas lain sedangkan Weak Entity Type adalah entitas yang keberadaannya bergantung pada entitas lain. Strong Entity Type terkadang disebut dengan
41
parent atau owner dominant dan Weak Entity Type disebut child, dependent, subordinate.
2.1.6.7 Structural Constraints Batasan utama pada relationship disebut multiplicity, yaitu jumlah (atau range) dari kejadian yang mungkin terjadi pada suatu entitas yang terhubung ke satu kejadian dari entitas lain yang berhubungan melalui suatu relationship. Relationship yang paling umum adalah binary relationship. Macam-macam binary relationship yaitu : • One-to-one (1:1) One-to-one relationships terjadi ketika ada 1 record dari tabe l pertama yang berkorespondensi dengan satu record dari tabel lain. Contohnya setiap nama karyawan hanya memiliki satu no I D karyawan. • One-to-many (1 : *) One-to-many relationships terjadi ketika setiap record da lam tabel A bisa memiliki beberapa link dari tabel B namun masing- masing record dari tabel B hanya bisa berkorespondensi de ngan satu record dari tabel A. Contohnya sebuah perusahaan dengan semua karyawannya bekerja di gedung Z (merupakan tabel A). Nama gedung memiliki hubungan dengan banyak karyawan (merupakan tabel B). Jadi, satu record dari tabel A, yaitu tabel nama gedung, memiliki relasi dengan banyak nama karyawan dari tabel B.
42
• Many-to-many (* : *) Many to many relationship terjadi ketika setiap record dari tabel A memiliki hubungan dengan record-record yang ada di tabel B dan sebaliknya.
2.1.7 Normalisasi Menurut Connolly (2002,p411), normalisasi ada lah suatu teknik untuk menghasilkan sekumpulan relasi dengan sifat-sifat (properties) yang diinginkan, memenuhi kebutuhan data pada enterprise. Tujuan utama dalam pengembangan model data logical pada sistem database relasional adalah menciptakan representasi akurat suatu data, relationship antar data dan batasan-batasannya. Untuk mencapai tujuan ini, maka harus ditetapkan sekumpulan relasi. Tujuan utama dari desain database relasional adalah untuk mengelompokkan atribut-atribut kedalam relasi-relasi sehingga meminimalisasi redundansi data dan mengurangi penggunaan tempat penyimpanan yang dibutuhkan untuh sebuah relasi dasar. Proses normalisasi merupakan suatu teknik formal untuk menganalisa relasi berdasarkan primary key dan functional dependencies antar atribut. Proses ini dieksekusi dalam beberapa langkah. Setiap langkah mengacu ke bentuk normal tertentu, sesuai dengan sifat yang dimilikinya. Setelah normalisasi diproses, relasi menjadi secara bertahap lebih terbatas/kuat bentuk formatnya
43
dan juga mengurangi tindakan update yang anomali. Ada 5 tipe bentuk normalisasi, yaitu : • Unnormalized Form (UNF) Merupakan suatu tabel yang berisikan satu atau lebih group yang berulang. Membuat tabel unnormalized yaitu dengan memindahkan data dari sumber informasi kedalam format tabel dengan baris dan kolom. • First Normal Form (1NF) Merupaka n sebuah relasi dimana setiap irisan antara baris dan kolom berisika n satu dan hanya satu nilai. • Second Normal Form (2NF) Berdasarkan pada konsep full functional dependency, yaitu A dan B. 2NF merupakan atribut dari sebuah relasi, B dikatakan fully dependent terhadap A jika B functionally dependent pada A tetapi tidak pada proper subset dari A. 2NF – merupaka n sebuah relasi da lam 1N F dan setiap atribut non-primarykey bersifat fully functionally dependent pada primary key. • Third Normal Form (3NF) Berdasarkan pada konsep transitive dependency, yaitu suatu ko ndisi dimana A, B dan C merupakan atribut dari sebuah relasi, maka jika A B dan B C, maka C transitively dependent pada
A melalui
B.
(Jika A tidak
functionally dependent pada B atau C). 3NF adalah sebuah relasi dalam 1NF dan 2NF dan dimana tidak terdapat atribut non-primary-key attribute yang bersifat transitively dependent pada primary key.
44
• Boyce-Codd Normal Form (BCNF) Relasi yang hanya dan hanya jika setiap determinan adalah kunci kandidat. • Fourth Normal Form Relasi yang terdapat pada Boyce-Codd Normal Form dan tidak mengandung ketergantungan bernilai banyak (Multi-valued dependency). Multi-valued dependency merupaka n keterga ntugan antar atribut dalam suatu relation, misalnya untuk setiap nilai dari A merupakan satu set nilai untuk B dan C, di mana nilai-nilai B dan C tidak bergantung satu sama lain. • Fifth Normal Form Didefinisikan sebagai relasi yang tidak mempunyai join dependency (lossless join dependency). Lossless join dependency merupakan property of decomposition, yang meyakinkan tidak ada spurious tuples yang dihasilka n ketika relasi-relasi disatukan melalui operasi natural join. Proses-proses yang terjadi : • UNF ke 1NF Tunjuk satu atau sekumpulan atribut sebagai kunci untuk tabel unnormalized. Identifikasikan group yang berulang dalam tabel unnormalized yang berulang untuk kunci atribut. Hapus group yang berulang dengan cara : 1. Masukkan data yang semestinya kedalam kolom yang kosong pada baris yang berisikan data yang berulang (flattening the table), 2. Menggantikan data yang ada dengan copy dari kunci atribut yang sesungguhnya kedalam relasi terpisah.
45
• 1NF ke 2 NF 1. Identifikasikan primary key untuk relasi 1NF. 2. Identifikasikan functional dependencies dalam relasi. 3. Jika terdapat partial dependencies terhadap primary key, maka hapus dengan menempatkannya dalam relasi yang baru bersama dengan salinan determinannya. • 2NF ke 3NF 1. Identifikasikan primary key dalam relasi 2NF. 2. Identifikasikan functional dependencies dalam relasi. 3. Jika terdapat transitive dependencies terhadap primary key, hapus dengan menempatkannya dalam relasi yang baru bersama dengan salinan determinannya. • 3NF ke BCNF 1. Merupaka n relasi yang sama dengan relasi yang ada di dalam 3NF 2. Untuk functional dependecy A B, ditetapkan dalam relasi maka A harus merupaka n candidate key. • BCNF ke 4NF Menghilangkan Multi-valued dependency dari relasi dengan menempatkan atribut-atribut ke dalam suatu relasi baru bersama dengan copy of determinant.
2.1.8 Structured Query Language 2.1.8.1
Penge rtian SQL
46
Menurut Connolly(2002,p111) SQL adalah contoh dari transform-oriented language atau bahasa yang didesain untuk menggunakan relasi untuk mengubah input menjadi output yang diinginkan. Database language dapat memungkinkan user untuk: • Membuat struktur relasi da n database • Melakukan operasi penyisipan (insertion), pe ruba han (modification) dan penghapusan (deletion) data dari relasi • Melakuka n query simple dan kompleks. Database language harus melaksanakan operasi-operasi tersebut dengan usaha minimal ya ng dilakuka n user da n syntaks/struktur instruks i harus mudah dipahami/dipelajari. Database Language juga harus portable sehingga memungkinkan untuk pindah dari satu DBMS ke DBMS lainnya. Sebagai suatu bahasa, SQL memiliki dua komponen utama yaitu DDL untuk definisi struktur database dan DML untuk pengambilan (retrieving) dan perubahan (updating) data.
2.1.8.2 Data Manipulation Language • SELECT Statement untuk ambil data dari database, Syntax : SELECT [DISTINCT | ALL]
47
{* | [columnExpression [AS newName]] [,...] } FROM TableName [alias] [, ...] [WHERE condition] [GROUP BY columnList] [HAVING condition] [ORDER BY columnList] • INSERT Statement. Syntax : INSERT INTO TableName [ (columnList) ] VALUES (dataValueList) • UPDATE Statement. Syntax : UPDATE TableName SET columnName1 = dataValue1 [, columnName2 = dataValue2...] [WHERE searchCondition] • DELETE Statement. Syntax : DELETE FROM TableName [WHERE searchCondition]
2.1.8.3 Data Definition Language SQL DDL memungkinkan objek database seperti skema, domain, tabel, view, dan index untuk d ibuat da n dihapuska n. S tatemen SQL-DDL yang utama : • CREATE SCHEMA • DROP SCHEMA • CREATE/ALTER DOMAIN • DROP DOMAIN • CREATE/ALTER TABLE
48
Untuk membuat tabel dasar dalam database, dengan format sbb : CREATE TABLE TableName {(colName dataType [NOT NULL] [UNIQUE] [DEFAULT defaultOption] [CHECK searchCondition] [,...]} [PRIMARY KEY (listOfColumns),] {[UNIQUE (listOfColumns),] […,]} {[FOREIGN KEY (listOfFKColumns) REFERENCES ParentTableName [(listOfCKColumns)], [MATCH { PARTIAL | FULL } [ON UPDATE referentialAction] [ON DELETE referentialAction ]] [,…]} {[CHECK (searchCondition)] [,…] }) Merubah Definisi Tabel (ALTER TABLE), contoh meruba h tabel staff dengan menghapus default dari ‘Assistant’ untuk kolom position dan menentukan default untuk kolom sex menjadi female (‘F’). ALTER TABLE Staff ALTER position DROP DEFAULT; ALTER TABLE Staff ALTER sex SET DEFAULT ‘F’; • DROP TABLE : DROP TABLE TableName [RESTRICT | CASCADE] • CREATE VIEW • DROP VIEW
49
Beberapa DBMS juga menyediakan : • CREATE INDEX • DROP INDEX
2.1.8.4 Kontrol Akses Ada beberapa kontrol akses yang disediakan, yaitu: •
Privileges
Dapat membatasi INSERT/UPDATE/REFERENCES untuk kolom yang ditentukan. Pemilik tabel harus memberikan wewenang kepada user lain hakhak yang dianggap perlu dengan menggunakan statemen GRANT.
Untuk
membuat view, user harus mempunyai hak SELECT pada seluruh tabel yang digunakan untuk membuat view dan hak REFERENCE pada kolom tertentu. 1. GRANT Format penulisan GRANT : GRANT {PrivilegeList | ALL PRIVILEGES} ON ObjectName TO {AuthorizationIdList | PUBLIC} [WITH GRANT OPTION] 2. REVOKE , mengambil kembali hak yang diberikan oleh statemen GRANT, format penulisan REVOKE sbb : REVOKE [GRANT OPTION FOR]
50
{PrivilegeList | ALL PRIVILEGES} ON ObjectName FROM {AuthorizationIdList| PUBLIC} [RESTRICT | CASCADE]
2.1.9 State Transition Diagram (STD) Menurut Jeffrey A. Et al (1996,p364), state transition diagram adalah suatu diagram yang menggambarkan bagaimana suatu proses dihubungkan satu sama lain dalam waktu yang be rsamaan. STD diga mbarkan de ngan sebuah state yang berupa komponen sistem yang menunjukkan bagaimana kejadian-kejadian tersebut dari satu state ke state yang lain. Menurut Whitten (2004,p673), State Transition Diagram adalah alat yang digunakan untuk menggambarkan urutan dan variasi dari screens yang terjadi selama user session. Ada 2 macam simbol yang menggambarkan proses dalam State Transition diagram, yaitu: • Menunjukkan state dari sistem • Menunjukkan transisi antar state. Tiap panah diberi label dengan ekspresi aturan. Label yang diatas menunjukkan kejadian yang menyebabkan transisi yang terjadi. Label yang dibawah menunjukkan aksi yang terjadi akibat kejadian tadi. Contoh STD:
51
Verifikasi Data Valid Login username dan password
Menuu Utama
Data Tidak Valid
2.2 Teori-teori Khusus 2.2.1 Maintenance Definisi maintenance menurut Patrick (2001,p407) adalah suatu kegiatan untuk memelihara dan menjaga fasilitas yang ada serta memperbaiki, melakukan penyesuaian atau penggantian yang diperlukan untuk mendapatkan suatu ko ndisi ope rasi pr od uks i agar sesuai de ngan pe rencanaan yang ada. Pengertian maintenance secara umum yaitu serangkaian aktivitas(baik bersifat teknis dan administratif) yang diperlukan untuk mempertahankan dan menjaga suatu produk atau sistem tetap berada dalam kondisi aman, ekonomis, efisien dan pengoperasian optimal.