9
BAB 2 LANDASAN TEORI
2.1
Teori - Teori Umum 2.1.1 Pengertian Data Menurut Turban, & Rainer (2009, p. 6), data adalah fakta mentah atau deskripsi dasar dari benda, peristiwa, aktivitas dan transaksi yang didapatkan, direkam, disimpan, diklasifikasi tetapi belum terorganisir untuk menyampaikan suatu arti spesifik.
Menurut Conolly dan Begg (2010, p70), data merupakan komponen yang paling penting dalam Database Management System (DBMS), berasal dari sudut pandang dari end-user. Data berperan sebagai penghubung antara mesin dengan pengguna.
Menurut Williams & Sawyer (2011, p. 25), data terdiri dari fakta – fakta, dan gambaran mentah yang akan diproses menjadi informasi. Data penting karena pengguna memerlukan data untuk membuat informasi yang berguna.
2.1.2 Pengertian Basis Data (Database) Menurut Thomas Connoly dan Carolyn Begg (2010, p.65), basis data adalah sekumpulan data yang berelasi secara logikal dan deskripsi dari data dirancang untuk memenuhi kebutuhan informasi dari sebuah organisasi.
10
Menurut Thomas Connoly dan Carolyn Begg (2010, p.65), basis data adalah tempat penyimpanan data tunggal (mungkin dalam skala besar) yang dapat digunakan secara bersama – sama oleh banyak departemen dan pengguna. Daripada menggunakan file – file yang berulang (redundant) dan sama sekali tidak terhubung, basis data menyimpan semua data yang terintegrasi dengan jumlah duplikasi data seminimal mungkin. Selain menyimpan data operasional perusahaan, basis data juga menyimpan deskripsi mengenai hal itu. Oleh karena itu, basis data sering disebut dengan a self describing collection of integrated records. Deskripsi mengenai data tersebut dikenal dengan kamus data atau metadata.
Nadim Obeid and Raj B. K. N. Rao (2010: 129) mengatakan database yang aktif adalah sistem manajemen database yang dapat melakukan tindakan ketika beberapa peristiwa tertentu atau pola peristiwa yang terdeteksi. Pada database yang aktif, merupakan kejadian yang menarik yang dapat berupa primitif (misalnya menyimpan uang di bank) atau komposit (Contoh: cash menyimpan di bank, diikuti penarikan tunai dari bank).
2.1.3 Arsitektur Basis Data Menurut Thomas Connoly dan Carolyn Begg (2010, p.86), 3 tiga level arsitektur basis data (Three Level ANSI-SPARC Architecture) adalah: a. External Level
11
External level merupakan apa yang dilihat oleh pengguna terhadap basis. Level ini mendeskripsikan bagian basis data yang berhubungan dengan tiap pengguna. b. Conceptual Level Conceptual level menggambarkan data apa saja yang disimpan dalam basis data dan hubungan antara data tersebut. c. Internal Level Internal level merupakan representasi fisik dari basis data yang ada di dalam komputer. Level ini menggambarkan bagaimana data disimpan dalam suatu basis data.
Tujuan utama dari tiga level arsitektur basis data adalah untuk mendapatkan arsitektur basis data adalah untuk mendapatkan data independence. Dengan adanya data independence pada basis data, data dapat diubah tanpa mempengaruhi aplikasi yang berhubungan dengan basis data tersebut.
2.2
Teori-teori Khusus 2.2.1 Bahasa Sistem Basis Data 2.2.1.1 Data Definition Language (DDL) Menurut Thomas Connolly dan Carolyn Begg (2010, p.92), data Definition Language (DDL) adalah sebuah bahasa yang mengijinkan Database Administrator (DBA) atau pengguna untuk menjelaskan dan memberi nama pada entitas, atribut, dan hubungan yang
12
diperlukan untuk aplikasi, secara bersamaan dengan associated intergrity dan security constraint.
2.2.1.2 Data Manipulation Language (DML) Menurut Thomas Connolly dan Carolyn Begg (2010, p.92), data Manipulation Language (DML) adalah sebuah bahasa yang menyediakan satu set operasi untuk mendukung dasar dari operasi manipulasi pada data yang disimpan pada basis data.
2.2.2 Database Management System (DBMS) 2.2.2.1 Pengertian DBMS Menurut Thomas Connolly dan Carolyn Begg (2010, p.66), DBMS adalah sebuah sistem software yang memungkinkan penggunanya untuk mendefinisikan, membuat, memelihara, dan mengendalikan akses ke basis data.
Menurut Dadashzadeh, Mohammad berdasarkan jurnal (Journal of Information Systems Education, 2007), mengatakan pernyataan DBMS yang didukung secara terbatas oleh semua perangkat lunak DBMS saat ini. Khusus kemampuan untuk menunjuk primary key tabel tidak lebih dari menyatakan kendala dan membiarkan DBMS menegakkan selama update database.
13
2.2.2.2 Fungsi DBMS Menurut Thomas Connolly dan Carolyn Begg (2010, p.99), fungsi DBMS adalah: -
Menyimpan, memperoleh, dan meng-update data.
-
Sebuah katalog yang bisa di akses oleh pengguna.
-
Mendukung transaksi.
-
Layanan kendali concurrency.
-
Layanan recovery.
-
Layanan authorization.
-
Mendukung data komunikasi.
-
Layanan integrity.
-
Layanan untuk promote data independents.
-
Layanan utility.
2.2.2.3 Fasilitas DBMS Menurut Thomas Connolly dan Carolyn Begg (2010, p.66), DBMS menyediakan pengendalian akses ke basis data yaitu: -
Sistem keamanan yang mencegah pemakai yang tidak memiliki hak akses untuk mengakses basis data.
-
Intergrity system yang menangani konsistensi data yang telah disimpan.
-
Sistem concurrency control yang mengijinkan untuk berbagi akses dari basis data.
14
-
Sistem recovery control yang memperbaiki basis data menjadi seperti sebelumnya yang disebabkan karena adanya kegagalan yang terjadi pada perangkat keras atau perangkat lunak.
-
User–accessible catalog yang berisi tentang deskripsi dari data yang telah tersimpan dalam basis data.
2.2.2.4 Komponen Lingkungan DBMS Menurut Thomas Connolly dan Carolyn Begg (2010,p.68), komponen lingkungan DBMS terdiri dari: -
Hardware DBMS dan aplikasi memerlukan hardware agar dapat dijalankan. Beberapa DBMS hanya dapat bekerja pada hardware atau sistem operasi tertentu. DBMS juga membutuhkan sejumlah minimum dari main memory dan space disk untuk bekerja.
-
Software Komponen software terdiri dari software DBMS itu sendiri dan program aplikasi, bersama dengan sistem operasi, termasuk network software jika DBMS digunakan pada jaringan.
-
Data Mungkin komponen yang paling penting dari lingkungan DBMS dari pandangan end-user adalah data. Data bertindak sebagai jembatan antara komponen mesin dan komponen manusia. Basis data memiliki baik data operasional dan meta-data.
-
Prosedur
15
Prosedur merujuk pada instruksi dan peraturan yang mengatur rancangan dan kegunaan dari basis data. Pengguna dari sistem dan staff yang mengatur basis data memerlukan dokumentasi prosedur tentang bagaimana menggunakan atau menjalankan sistem. -
Manusia Komponen manusia terdiri dari: 1. Data administrator adalah orang yang bertanggung jawab untuk pengaturan dari sumber data, termasuk perencanaan basis data, pengembangan dan pemeliharaan, kebijakan dan prosedur, dan desain konseptual/logikal basis data. 2. Database administrator adalah orang yang bertanggung jawab untuk realisasi fisikal dari basis data, termasuk desain fisikal basis data dan implementasi, kontrol keamanan dan integritas, memelihara
sistem
operasional,
memastikan
kepuasan
pengguna untuk peforma dari aplikasi. 3. Database designer terbagi menjadi dua yaitu logical database designer dan physical database designer. a. Logical
database
designer
adalah
orang
yang
mengidentifikasi data (entitas dan atribut), hubungan antar data, constraint data yang disimpan dalam basis data. Logical
database
designer
harus
memiliki
secara
menyeluruh dan mengerti sepenuhnya tentang data organisasi dan constraint dari data (constraint ini terkadang disebut dengan peraturan bisnis). Peraturan
16
bisnis menggambarkan karakteristik utama dari data yang dilihat oleh perusahaan. b. Physical
database
designer
adalah
orang
yang
memutuskan bagaimana basis data logical direalisasikan secara physical.
2.2.2.5 Pemilihan DBMS Menurut Thomas Connolly dan Carolyn Begg (2010, p.325-329), pemilihan DBMS merupakan pemilihan dari ketepatan DBMS yang mendukung sistem basis data. Dalam memilih DBMS perlu melakukan langkah – langkah sebagai berikut :
1. Mendefinisikan kerangka yang digunakan untuk acuan studi terlebih dahulu Kerangka yang menjadi acuan untuk pemilihan DBMS dibangun, menyatakan tujuan, batasan dari pelajaran, serta tugas – tugas yang perlu untuk diambil alih.
2. Persiapan dua atau tiga produk Kriteria cenderung menjadi “penting” untuk sebuah implementasi yang
bisa
digunakan
untuk
menghasilkan
sebuah
daftar
digunakan
untuk
pendahuluan dari produk DBMS untuk evaluasi.
3. Mengevaluasi produk – produk Ada
fitur
yang
beragam
yang
dapat
mengevaluasi sebuah produk DBMS untuk tujuan evaluasi, fitur tersebut bisa melakukan analisis secara kelompok maupun individual.
17
4. Merekomendasikan pilihan – pilihan menghasilkan laporan Langkah
terakhir
dari
pemilihan
DBMS
adalah
untuk
merekomendasikan dari proses – proses dan untuk menyediakan sebuah pernyataan dari menemukan dan merekomendasikan untuk produk DBMS.
2.2.3 Tahapan Perancangan Basis Data 2.2.3.1 The Database Application Lifecycle Menurut Thomas Connolly dan Carolyn Begg (2010, p.313-314), untuk merancang aplikasi sistem basis data diperlukan tahapan – tahapan yang dinamakan dengan siklus hidup aplikasi basis data (Database Application LifeCycle). Tahapan – tahapan ini dapat dilihat pada gambar 2.1.
18
Gambar 2.1 Database Application LifeCycle 1. Perancangan Model Basis Data Menurut Connolly dan Begg (2010, p313), perencanaan basis data (database planning) merupakan perencanaan bagaimana setiap tahapan dari siklus dapat direalisasikan menjadi lebih efisien dan efektif. Perencanaan basis data harus dapat terintegrasi dengan sistem informasi perusahaan secara umum. Beberapa hal yang terlibat dalam formula adalah strategi sistem informasi, yaitu :
19
1. Identifikasi dari rencana dan tujuan perusahaan dengan menentukan kebutuhan sistem informasi. 2. Evaluasi sistem informasi yang sedang berjalan untuk menentukan kelebihan dan kekurangan. 3. Penilaian dari keuntungan teknologi informasi yang dapat member keuntungan kompetitif. a. System Definition Menurut Connolly dan Begg (2010, p316), definisi sistem adalah mendeskripsikan cakupan dan batasan dari aplikasi basis data, baik pengguna dan area aplikasi tersebut. Sebelum mencoba untuk merancang
aplikasi
basis
data,
pertama
–
tama
harus
mengidentifikasi batasan dari sistem yang akan kita investigasi dan bagaimana membuat antarmuka dengan sistem informasi tiap bagian dalam organisasi. Dalam mendefinisikan sistem, harus ditentukan oleh user view, yaitu mendefinisikan apa yang dibutuhkan oleh aplikasi basis data berdasarkan pandangan dari tiap bagian tugas (misalnya manager atau supervisor) atau area aplikasi perusahaan (misalnya marketing, personnel, atau stock control). b.
Requirement Collection and Analysis Menurut Connolly and Begg (2010, p316), analisis data dan pengumpulan kebutuhan adalah proses mengumpulkan dan analisis informasi tentang bagian dari organisasi yang dapat didukung oleh aplikasi basis data, dan menggunakan informasi tersebut untuk mengidentifikasi kebutuhan pengguna dari sistem baru. Banyak
20
teknik yang dapat dilakukan untuk mengumpulkan informasi tersebut, disebut teknik fact finding. Informasi yang dikumpulkan untuk setiap user view, mencakup : 1. Deskripsi data yang digunakan. 2. Rincian mengenai bagaimana data dapat digunakan atau dihasilkan. 3. Kebutuhan tambahan lainnya untuk aplikasi basis data yang baru. Informasi ini selanjutnya dianalisis untuk mengidentifikasi kebutuhan yang dapat dimasukkan ke dalam aplikasi basis data baru. Kebutuhan ini dideskripsikan ke dalam dokumen bersama sebagai requirement specifications untuk aplikasi basis data baru. Ada 3 pendekatan untuk mengelola kebutuhan dari aplikasi basis data dengan banyak user view, yaitu : 1. The centralized approach : kebutuhan dari setiap user view digabung menjadi sebuah set kebutuhan dari aplikasi basis data. 2. The view integration approach : kebutuhan dari setiap user view digunakan untuk membangun model data secara terpisah untuk merepresentasikan user view tersebut. Model data yang dihasilkan tersebut nantinya akan digabungkan pada tahapan database. 3. Kombinasi dari dua pendekatan di atas. c. Database Design Menurut Connolly dan Begg (2010, p320), database design adalah proses membuat perancangan basis data yang dapat mendukung
21
pekerjaan dan tugas perusahaan. Menurut Connolly dan Begg (2010, p322), perancangan basis data ini memiliki tiga tahapan, yaitu: 1. Perancangan basis data konseptual, yaitu proses membangun sebuah
model
informasi
yang
digunakan
di
sebuah
perusahaan, terbebas dari segala pertimbangan fisik. 2. Perancangan basis data logikal, yaitu proses membangun sebuah model informasi yang digunakan di sebuah perusahaan berdasarkan pada sebuah model data yang spesifik, tetapi terbatas
dari
DBMS
tertentu
dan
pertimbangan
–
pertimbangan fisikal lainnya. 3. Perancangan basis data fisikal, yaitu proses menghasilkan sebuah deskripsi dari pengimplementasian basis data pada media
penyimpanan
sekunder,
yang
mendeskripsikan
hubungan dasar, pengorganisasian file, dan indeks yang digunakan untuk memperoleh akses data secara efisien serta segala batasan integritas dan ukuran – ukuran keamanan yang berhubungan.
Menurut Connoly dan Begg (2010. P321), ada 4 pendekatan dalam desain basis data yaitu : 1. Top-Down Diawali dengan pembentukan model data yang berisi beberapa entitas high-level dan relationship, yang kemudian menggunakan pendekatan top-down secara
22
berturut – turut untuk mengidentifikasi entitas lower level, relationship dan atribut lainnya. 2. Bottom-up Dimulai dari atribut dasar yaitu sifat – sifat entitas dan relationship, dengan analisis dari penggabungan antar atribut, yang dikelompokan ke dalam suatu relasi yang merepresentasikan tipe dari entitas dan relationship antar entitas. 3. Inside-out Berhubungan dengan pendekatan bottom-up tetapi sedikit berbeda dengan identifikasi awal entitas utama dan kemudian menyebar ke entitas, relationship, dan atribut terkait lainnya yang lebih dulu diidentifikasi. 4. Mixed Mengunakan pendekatan bottom-up dan top-down untuk bagian
yang
berbeda
sebelum
pada
akhirnya
digabungkan. d. DBMS Selection Menurut Connolly dan Begg (2010, p325), pemilihan DBMS yang sesuai untuk mendukung aplikasi basis data yang mencakup : 1. Mendefinisikan syarat – syarat referensi studi. Menentukan sasaran, batasan masalah dan tugas yang harus dilakukan. 2. Mendaftarkan 2 atau 3 jenis barang. Membuat daftar barang – barang, misalkan dari mana barang ini didapat, berapa biayanya serta bagaimana bila ingin mendapatkannya.
23
3. Mengevaluasi barang – barang yang ada dalam daftar diteliti lebih lanjut untuk mengetahui kelebihan dan kekurangan barang tersebut. 4. Merekomendasikan merupakan
pilihan
langkah
mendokumentasikan
dan
terakhir proses
membuat dari
dan
laporan
DBMS
untuk
yaitu
menyediakan
pernyataan mengenai kesimpulan dan rekomendasi terhadap salah satu produk DBMS. e.
Application Design Menurut Connolly dan Begg (2010, p329), perancangan aplikasi adalah merancang antarmuka pemakai (user interface) dan program aplikasi, yang akan memproses basis data. Dalam merancang
aplikasi
harus
memastikan
semua
pernyataan
fungsional dari spesifikasi kebutuhan pemakai (user requirement specification) yang menyangkut perancangan aplikasi program yang mengakses basis data dan merancang transaksi yaitu cara akses ke basis data dan perubahan terhadap isi basi data (retrieve, update dan kegiatan keduanya). Artinya bagaimana fungsi yang dibutuhkan dengan cara untuk menciptakan user friendly. f.
Prototyping Menurut Connolly dan Begg (2010, p333), pengertian prototyping adalah membuat model kerja dari aplikasi basis data, yang memperbolehkan perancang atau user untuk mengevaluasi hasil akhir sistem, baik dari segi tampilan maupun fungsi yang dimiliki sistem. Tujuan utama dari mengembangkan suatu prototype
24
adalah mengijinkan user untuk menggunakan bentuk dasar guna mengidentifikasi corak sistem apakah bekerja dengan baik dan jika mungkin meningkatkan corak baru kepada aplikasi basis data. Dengan cara ini, kebutuhan dari pemakai dan pengembang sistem dalam mengevaluasi kelayakan design sistem akan semakin jelas sehingga kelebihan atau kekurangan sistem dapat ditangani dengan baik. Strategi prototyping yang umum digunakan ada dua, yaitu requirement
dan
evolutionary
prototyping.
Requirement
prototyping adalah menggunakan bentuk dasar untuk menetapkan kebutuhan dari tujuan aplikasi basis data dan ketika kebutuhan sudah terpenuhi, prototype tidak digunakan lagi atau dibuang. Sedangkan evolutionary prototype menggunakan tujuan yang sama, tetapi perbedaaannya adalah prototype tetap digunakan untuk selanjutnya dikembangkan menjadi aplikasi basis data yang lengkap. g. Implementation Menurut Connolly dan Begg (2010, p333), implementation merupakan realisasi secara fisik dari database dan desain aplikasi. Pada tahap penyelesaian desain, kini kita dapat menerapkan basis data dan program aplikasi yang telah kita buat. Implementasi basis data menggunakan DDL yang kita pilih dalam melakukan pemilihan DBMS atau dengan menggunakan Graphical User Interface (GUI), yang menyediakan fungsional yang sama dengan pernyataan DDL yang low level. Pernyataan DDL digunakan
25
untuk menciptakan struktur basis data dan mengosongkan file yang terdapat dalam basis data tersebut. Pandangan pemakai lainnya juga diimplementasikan dalam tahapan ini. Data Manipulation
Language
(DML)
digunakan
untuk
mengimplementasikan transaksi basis data di dalam bagian aplikasi program dari sasaran DBMS, mungkin termasuk host programming language seperti, Visual basic, Delphi, C, C++, Java, COBOL, dan Pascal. h. Data Conversion and Loading Menurut Connolly dan Begg (2010, p 334), data conversion and loading adalah mencakup pengambilan data dari sistem lama untuk dipindahkan ke dalam sistem yang baru. Langkah ini diperlukan hanya ketika suatu sistem basis data baru sedang menggantikan sistem yang lama. Sekarang, DBMS yang memiliki kegunaan yang dapat mengisi file yang ada ke dalam sistem yang baru telah dianggap umum, kegunaan yang ada umumnya memerlukan spesifikasi sumber file dan target basis data yang baru. Ketika conversion and loading dibutuhkan, prosesnya harus direncanakan untuk memastikan kelancaran transaksi untuk keseluruhan operasi. i. Testing Menurut Connolly dan Begg (2010, p334), testing adalah suatu proses melaksanakan program aplikasi dengan tujuan menemukan kesalahan sebelum diterapkan dalam suatu sistem, basis data harus dilakukan testing terlebih dahulu. Hal ini dicapai dengan
26
penggunaan secara hati – hati untuk merencanakan suatu test dan data yang realistis sedemikian sehingga keseluruhan proses pengujian sesuai dengan metode dan dilaksanakan sesuai aturan yang ada. j. Operational Maintenance Menurut
Connolly
dan
Begg
(2010,
p335),
operational
maintenancne adalah proses memantau dan memelihara sistem setelah di-install. Pada tahapan sebelumnya, basis data benar – benar diuji dan diimplementasikan. Sekarang sistem beralih ke tahapan pemeliharaan. Yang termasuk aktivitas dari tahapan ini adalah sebagai berikut : -
Memantau kinerja dari sistem. Jika kinerjanya menurun dibawah level yang dapat diterima, mungkin basis data perlu diorganisasi.
-
Pemeliharaan
dan
upgrade
diperlukan).
Ketika
basis
aplikasi data
basis
data
sepenuhnya
(jika
bekerja,
pemantauan harus memastikan kinerja hanya dapat berada dalam tingkat yang diterima. Sebuah DBMS biasanya menyediakan berbagai kegunaan (utilities) untuk membantu administrasi basis data termasuk kegunaan untuk mengisi data kedalam basis data dan untuk memberikan informasi seperti pemakaian basis data dan strategi eksekusi query. Basis data administrasi
dapat
menggunakan
informasi
ini
untuk
memperbaiki sistem agar dapat memberikan kinerja yang lebih baik.
27
2. Perancangan User Interface Membuat rancangan user interface untuk aplikasi basis data manajemen proyek menggunakan C# sesuai dengan permintaan perusahaan.
2.2.3.2 Tahapan Konseptual Menurut Thomas Connolly dan Carolyn Begg (2010, p.470-485), langkah – langkah membangun conceptual database design yaitu: 1. Membangun data model konseptual untuk setiap view. a. Mendefinisikan tipe entitas Cara
alternatif
yang
dipakai
adalah
dengan
cara
mendefinisikan entitas untuk mencari objek yang dibutuhkan oleh
pemakai.
Pada
metode
ini
perlu
untuk
mengidentifikasikan entitas – entitas yang ada untuk memeriksa keperluan pemakai secara spesifik. b. Mendefinisikan tipe relationship Pada kenyataannya catatan keperluan yang spesifik adalah adanya saran untuk relationship dimana catatan – catatan tersebut penting untuk perusahaan dan terdapat pada model. c. Identifikasi dan asosiasi atribut dengan entitas atau tipe relationship Metode ini mengidentifikasikan tipe – tipe dari kenyataan yang ada tentang entitas – entitas dan relationship yang telah dipilih untuk direpresentasikan pada basis data. d. Menentukan domain atribut
28
Domain merupakan kumpulan dari nilai – nilai dimana terdapat satu atau lebih atribut yang tergambar dalam nilai atribut itu sendiri. Untuk mengembangkan data model secara spesifik termasuk: •
Mengijinkan kumpulan nilai untuk atribut.
•
Ukuran dan bentuk atribut.
Implementasi dari karakteristik domain pada DBMS masih menjadi subjek dari penelitian. Atribut domain berisi indentifikasi atribut domain tersebut, catatan nama atribut domain tersebut, dan karakteristik yang terdapat dalam kamus data. e. Menentukan atribut candidate, primary, dan alternate key Pada metode ini, memilih primary key diantara candidate key sangat penting sehingga diperlukan pedoman untuk dapat membantu membedakan key tersebut. f. Mempertimbangkan penggunaan konsep enhanced modeling (optional) Pada metode ini, kita memiliki pilihan untuk melanjutkan pengembangan dari ER model menggunakan konsep modeling tingkat lanjut (specification, generalization, aggregation, dan compotition). g. Memeriksa ulang model – model untuk redudansi Pada tahap ini, perlu dilakukan pemeriksaan model konseptual data dengan objek identifikasi yang lebih spesifik dimana terdapat model yang redudansi dan menghilangkan yang ada.
29
3 (tiga) aktivitas yang perlu dilakukan pada langkah ini adalah: •
Meninjau kembali one–to–one relationship (1:1).
•
Menghilangkan relationship yang redudansi.
•
Mempertimbangkan dimensi waktu.
h. Memvalidasikan model data konseptual dengan transaksi user Pada tahap ini terdapat dua pendekatan yang mendukung model konseptual data untuk pemakaian transaksi yaitu: •
Menjelaskan transaksi.
•
Menggunakan pathway transaksi.
i. Meninjau model data konseptual dengan pemakai Pada tahap ini perlu dilakukan pengulangan dengan pemakai. Model konseptual termasuk ER diagram dan mendukung dokumentasi yang menjelaskan tentang data model. Titik tahapan ini perlu ditinjau secara berulang – ulang. Proses pengulangan ini akan berhenti apabila pemakai menyediakan model yang telah disetujui sehingga tidak perlu melakukan pengulangan karena representasi tersebut telah disepakati bersama.
2.2.3.3 Tahapan Logikal Menurut Thomas Connolly dan Carolyn Begg (2010, p.490-560), langkah-langkah membangun logical database design adalah : 1. Membangun data model logikal a. Menurunkan relasi untuk data model logikal
30
Tahap ini bertujuan untuk membuat relasi data model logikal untuk merepresentasikan entitas, hubungan, atribut yang telah diidentifikasi. b. Memvalidasikan relasi menggunakan normalisasi Tahap ini bertujuan untuk memvalidasi relasi pada data model logikal menggunakan normalisasi. Tujuan dari normalisasi adalah untuk memastikan bahwa set dari relasi memiliki jumlah artibut minimal yang cukup untuk mendukung kebutuhan dari perusahaan. c. Memvalidasikan hubungan dengan transaksi user Tahapan ini diperlukan untuk memastikan hubungan pada model
data
logikal
yang
mendukung
transaksi
yang
dibutuhkan. Pada tahapan ini hubungan yang dibuat pada tahap sebelumnya dalam transaksi yang ada perlu ditinjau kembali sehingga dapat memastikan bahwa tidak ada kesalahan yang muncul pada saat membuat relations. d. Mengecek integrity constraint Tahap ini bertujuan untuk memeriksa apakah integrity constraint terdapat pada data model logikal. Integrity constraint merupakan constraint yang menentukan penjagaan keamanan basis data dari ketidaksempurnaan, ketidakakuratan, ataupun ketidakkonsistensian. e. Meninjau kembali data model lokal logikal dengan transaksi pengguna
31
Tahap ini bertujuan untuk meninjau kembali data model lokal logikal dengan pengguna untuk memastikan data model merupakan
representasi
nyata
dengan
kebutuhan
data
perusahaan. f. Menggabungkan data model logikal ke dalam data model global (optional) Tujuan pada tahap ini adalah untuk menggabungkan data model lokal logikal ke dalam sebuah data model global logikal yang merepresentasikan semua user view pada basis data. Langkah – langkah pada tahap ini : •
Menggabungkan data model logikal kedalam data model global logikal.
•
Validasi data model global logikal.
•
Meninjau kembali data model global logikal dengan user.
g. Cek untuk perkembangan di masa depan Tahap ini bertujuan untuk menentukan apakah ada perubahan secara besar pada masa depan dan untuk memperkirakan apakah data model logikal dapat mengakomodasi perubahan tersebut.
2.2.3.4 Tahapan Fisikal Menurut Thomas Connolly dan Carolyn Begg (2010, p.523-544), langkah-langkah membangun physical database design adalah: 1. Menerjemahkan data model global logikal untuk DBMS tujuan. a. Merancang relasi dasar
32
Mengidentifikasi logikal data model pada DBMS. Untuk membuat proses rancangan fisikal, harus menyusun dari hubungan yang dihasilkan dari data model logikal. b. Merancang representasi dari data turunan Langkah
ini
bertujuan
untuk
menentukan
bagaimana
merepresentasikan data turunan yang ada pada data model global logikal pada DBMS tujuan. c. Merancang constraint perusahaan Tahap ini bertujuan untuk merancang constraint perusahaan bagi DBMS tujuan. 2. Merancang organisasi file dan index a. Menganalisa transaksi Tahap ini bertujuan untuk mengetahui kegunaan dari transaksi yang akan berjalan pada basis data untuk menganalisa transaksi yang penting. b. Memilih organisasi file Tahap ini bertujuan untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. c. Memilih indexes Tahap ini bertujuan untuk menentukan apakah dengan menambahkan index akan meningkatkan performa dari sistem. d. Memperkirakan kebutuhan disk-space Tahap ini bertujuan untuk memperkirakan jumlah dari diskspace yang akan diperlukan oleh basis data. e. Merancang user view
33
Dalam merancang user view yang diidentifikasi selama pengumpulan persyaratan dan menganalsis tahap – tahap pada sistem basis data. f. Merancang mekanisme keamanan Basis data merepresentasikan sumber daya yang berhubungan dengan undang – undang atau hukum yang diperlukan. Pada metode ini diperlukan dokumentasi dari keperluan sistem secara spesifik. Pada metode ini, perancang basis data harus menyadari fasilitas yang ditawarkan oleh target DBMS. Keamanan pada basis data memiliki dua tipe yaitu: •
Keamanan sistem yang menangani akses dan kegunaan basis data pada level sistem seperti username dan password.
•
Keamanan data yang menangani akses dan kegunaan objek dari basis data (seperti relation dan view) dan tindakan dari pemakai yang memakai objek.
2.2.4 Normalisasi Menurut Thomas Connolly dan Carolyn Begg (2010, p.416), normalisasi adalah suatu teknik yang menghasilkan satu set relasi dengan properties yang diinginkan, yang memberikan kebutuhan data organisasi.
Suatu
desain
basis
data
harus
dipastikan
tidak
mengandung anomaly, yaitu kejanggalan yang tejadi dalam penempatan artibut tertentu dari suatu obyek data. Setiap record yang
34
ada di basis data dibedakan dengan sebuah atribut atau kombinasi atribut yang disebut primary key (kunci primer).
Menurut Thomas Connolly dan Carolyn Begg (2010, p.430), Unnormalized Form (UNF) adalah suatu label yang terdiri dari satu atau beberapa kelompok data berulang (repeating group). Tujuan dari normalisasi adalah: 1. Meminimalkan data yang rangkap. 2. Menghindari adanya data yang tidak konsisten bila terjadi penambahan dan penghapusan data sebagai akibat data yang rangkap. 3. Menjamin
bahwa
identitas
tabel
secara
tunggal
sebagai
determinan semua atribut.
Menurut Thomas Connolly dan Carolyn Begg (2010, p.430-436), normalisasi terdiri dari beberapa tahap, yaitu: 1. First Normal Form (1NF) Suatu relasi dikatakan 1NF bila titik temu pada setiap kolom dan baris relasi tersebut mengandung satu dan hanya satu nilai. Sebuah relasi dapat dikatakan berada pada bentuk 1NF jika repeating group dihilangkan. Ada 2 (dua) pendekatan yang digunakan untuk menghilangkan repeating group tersebut, yaitu : a. Dengan memasukkan data yang sesuai ke dalam kolom yang kosong dan baris yang mengandung kata yang berulang.
35
b. Dengan menempatkan data yang berulang selama salinan dari atribut kunci pada relasi yang terpisah. 2. Second Normal Form (2NF) Suatu relasi dapat dikatakan bentuk 2NF jika relasi tersebut berada pada bentuk 1NF dan setiap atribut yang bukan primary key bergantung sepenuhnya (fully functionally dependent) terhadap primary key. Fully functionally dependent menjelaskan hubungan diantara atribut-atribut dalam relasi. Sebagai contoh, jika A dan B adalah atribut dalam relasi R, maka B adalah functionally dependent A (A→B). Jika setiap nilai dari A berasosiasi tepat satu dengan nilai dari B, maka A dan B mungkin mengandung satu atau lebih atribut. 3. Third Normal Form (3NF) Suatu relasi dapat dikatakan 3NF jika relasi tersebut berada pada bentuk 1NF dan 2NF serta tidak ada atribut yang bukan primary key bergantung transitif. Ketergantungan transitif adalah suatu suatu kondisi dimana A, B, dan C adalah atribut dari sebuah relasi. Jika A→B dan B→C, maka C bergantung pada A melalui B (A tidak fully dependent pada B ataupun C).
2.2.5 Entitiy Relationshiop Modeling (ERM) Menurut Thomas Connolly dan Carolyn Begg (2010, p.371), ERM adalah salah 1 (satu) model yang dapat digunakan untuk mendapatkan
36
pengertian yang tepat dari sifat data dan bagaimana data tersebut dapat digunakan oleh perusahaan. ERM
menggunakan
pendekatan
top-down
dalam
melakukan
perancangan basis data. Dengan melakukan pendekatan top-down ini, perancangan dimulai dengan mengidentifikasi data penting yang biasanya disebut sebagai entity dan perancangan hubungan antar data yang
direpresentasikan
dalam
model
yang biasanya
disebut
relationship.
2.2.5.1 Entity Types Menurut Thomas Connolly dan Carolyn Begg (2010, p.372), entity types adalah sekumpulan obyek dengan properti yang sama yang diidentifikasi oleh perusahaan dan memiliki keberadaan yang independen.
Gambar 2.2 Representasi Diagram dari Entity
Menurut Thomas Connolly dan Carolyn Begg (2010, 373), entity occurence adalah suatu obyek dari entity type yang diidentifikasikan secara unik. Menurut Thomas Connolly dan Carolyn Begg (2010, p.383), entity type dapat diklasifikasikan menjadi 2 (dua) yaitu:
37
1. Strong Entity Strong entity adalah entity type yang keberadaannya tidak bergantung pada entity type lainnya. 2. Weak Entity Weak Entity merupakan kebalikan dari strong entity yaitu entity type yang keberadaannya bergantung pada entity type lainnya.
2.2.5.2 Relationship Types Menurut Thomas Connolly dan Carolyn Begg (2010, p.374), relationship types adalah sekumpulan asosiasi diantara entity types.
Gambar 2.3 Representasi Diagram dari Relationship
Menurut Thomas Connolly dan Carolyn Begg (2010, p.375-378), relationship
occurance
adalah
sekumpulan
asosiasi
yang
diidentifikasi secara unik, termasuk 1 (satu) kejadian/occurance dari masing – masing entity types yang berpartisipasi. Derajat tipe relationship adalah jumlah tipe entitas yang berpartisipasi dalam suatu relationship. Derajat relationship terdiri dari : •
Binary relationship adalah hubungan antara 2 tipe entitas.
•
Ternary relationship adalah hubungan antara 3 tipe entitas.
38
•
Quarternary relationship adalah hubungan antara 4 entitas.
•
Recrusive relationship adalah tipe relationship dimana tipe entitas yang sama berpartisipasi lebih dari satu dalam role yang berbeda.
Inti utama dari suatu relationship adalah multiplicity. Multiplicity adalah jumlah atau hasil dari kejadian yang mungkin terjadi pada sebuah entitas yang dapat menghubungkan ke kejadian tunggal dari suatu tipe entitas yang berhubungan melalui particular relationship. Beberapa jenis multiplicity adalah : •
Hubungan One – to – One (1:1)
•
Hubungan One – to – Many (1:*)
•
Hubungan Many – to – Many (*:*)
2.2.5.3 Attribute Menurut Thomas Connolly dan Carolyn Begg (2010, p.379-382), attribute merupakan properties/sifat dari suatu entity type atau relationship type. Arrtibute domain adalah sekumpulan nilai yang diijinkan untuk 1 (satu) atau beberapa attribute. Attribute dapat dibedakan menjadi 4 (empat) jenis, yaitu: 1. Simple dan Composite Attributes Simple attribute adalah atribut yang terdiri dari 1 (satu) komponen tunggal yang keberadaannya independen. Atribut ini sering disebut juga sebagai atomic attribute. Simple attribute tidak dapat dibagi lagi menjadi komponen yang lebih kecil.
39
Composite attribute adalah atribut yang terdiri dari banyak komponen yang keberadaannya independen. Atibut ini dapat dibagi menjadi komponen lain yang lebih kecil, yang masingmasing memiliki keberadaan yang independen. 2. Single-Valued dan Multi-Valued Attributes Single-valued attribute adalah atribut yang memiliki nilai tunggal untuk setiap kejadian/occurence pada setiap entity. Multi-valued attribute adalah atribut yang memiliki banyak nilai/occurence pada setiap entity. 3. Derived Attributes Derived attribute adalah atribut yang nilainya dihasilkan dari satu atau beberapa atribut lainnya dan tidak harus berasal dari entity yang sama. 4. Keys a. Candidate Key Candidate key merupakan sejumlah kecil atribut dari suatu entity yang dapat mengidentifikasikan secara unik suatu kejadian dari entity tersebut. Candidate key tidak boleh berupa null. b. Primary Key Primary key merupakan candidate key yang dipilih untuk mengidentifikasikan secara unik setiap kejadian pada entity tersebut. Pemilihan primary key pada suatu entity didasarkan pada pertimbangan panjang atribut, jumlah minimal atribut yang dibutuhkan serta keunikannya. Candidate key yang tidak
40
dipilih menjadi primary key pada suatu entity disebut alternate key. c. Composite Key Composite key adalah candidate key yang terdiri dari 2 (dua) atau lebih atribut. d. Foreign Key Foreign key adalah sebuah atribut atau sekumpulan atribut pada suatu relasi yang sesuai dengan candidate key yang ada di relasi yang sama ataupun relasi lainnya.
2.2.5.4 Spesialisasi/ Generalisasi (Specialization/Generalization ) Menurut Thomas Connolly dan Carolyn Begg (2010, p.400-403), konsep dari spesialisasi dan generalisasi adalah asosiasi tipe entitas dengan tipe entitas khusus yang dikenal sebagai superclass dan subclass, dan proses dari atribut turunan (inheritance). Superclass adalah suatu tipe entitas yang mengandung satu atau lebih subgroup terpisah dari suatu occurance, yang dibutuhkan untuk direpresentasikan pada suatu data model. Subclass adalah suatu subgroup terpisah dari occurance suatu tipe entitas, yang dibutuhkan untuk direpresentasikan pada suatu data model.
41
2.3
Teori Pendukung 2.3.1 Pengertian Project Menurut Kathy Schwalbe (2007, p.5), proyek adalah sebuah usaha keras yang bersifat sementara untuk membuat sebuah produk, jasa, atau hasil yang unik. Proyek adalah sesuatu hal yang berbeda dengan operasi saat tujuan atau objektifnya tercapai maka proyek itu akan selesai. •
Scope Sebuah batasan dimana pekerjaan yang harus diselesaikan dan menjadi bagian dalam proyek.
•
Time Lama waktu yang dibutuhkan untuk menyelesaikan proyek tersebut, dan siapa yang bertanggung jawab apabila ada perubahan dalam jadwal yang telah di tentukan.
•
Cost Apa saja yang akan menjadi biaya untuk menyelesaikan proyek tersebut.
Menurut Ludovic-Alexandre Vidal; Marle, Franck berdasarkan jurnal (Kybernetes journal Vol. 37 No. 8, 2008) mengatakan proyek adalah usaha yang bersifat sementara dan unik yang dilakukan untuk memberikan hasil. Hasil ini selalu perubahan dalam organisasi, apa pun itu dalam proses, kinerja, produk atau jasa.
42
2.3.2 Pengertian Project Management Menurut Kathy Schwalbe (2007, p.5), project management adalah penerapan pengetahuan, kemampuan, perangkat, dan teknik untuk memenuhi aktivitas proyek.
Poston, Robin. S (2011: 52-57) mengatakan permintaan untuk keterampilan manajemen proyek dalam industri meningkat sehingga permintaan yang lebih tinggi untuk program manajemen proyek pendidikan. Proyek mengambil posisi yang lebih menonjol dalam perencanaan strategis dan keberhasilan organisasi dalam lingkungan yang kompetitif saat ini.
Menurut Martin, Nancy L;Pearson, J Michael;Furumo, Kimberly berdasarkan jurnal (The Journal of Computer Information Systems, 2007) mengatakan proyek manajemen IS didefinisikan sebagai penerapan pengetahuan formal dan informal, keterampilan, alat dan teknik untuk mengembangkan sebuah sistem yang menyediakan tingkat yang diinginkan fungsionalitas tepat waktu dan sesuai anggaran.
43
2.4
Kerangka Pikir Pemecahan Masalah
Gambar 2.4 Kerangka Pikir Pemecahan Masalah Keterangan Gambar : 1. Mendefinisikan ruang lingkup atau batasan yang akan dibahas dari masalah yang ada. 2. Menganalisis masalah – masalah yang terdapat dalam sebuah perusahaan tersebut. 3. Menganalisis kebutuhan dari perusahaan tersebut agar dapat memberi solusi dan menyelesaikan masalah yang telah dianalisis. 4. Mendesain atau menggambarkan model logika. 5. Mendesain atau menggambarkan model fisikal. 6. Menguji hasil analisis terhadap masalah yang ada. 7. Mengevaluasi hasil dari implementasi yang telah dilakukan terhadap perusahaan.
