BAB 2 LANDASAN TEORI
2.1 Pendekatan Basisdata Pada bab ini akan dijelaskan mengenai teori-teori yang digunakan sebagai dasar dari penelitian ini. Teori-teori tersebut didapat dari sumber-sumber yang terpercaya seperti jurnal, textbook dan internet.
2.1.1 Database (Basisdata) Database merupakan data yang saling terhubung dan deskripsi dari data yang dirancang untuk kebutuhan organisasi (Connolly dan Begg, 2005, p15). Sedangkan menurut Nilkamal Surve (2006, p1-1). database adalah kumpulan dari data yang saling terhubungan. Dari teori-teori tersebut dapat disimpulkan bahwa database adalah sejumlah datayang terorganisasi yang saling terhubung untuk menyediakan informasi yang dibutuhkan oleh perusahaan.
13
14
2.1.2 DBMS (Database Management System) DBMS adalah sebuah sistem perangkat lunak yang mengizinkan pengguna untuk mendefinisikan, membuat, memelihara, dan mengatur akses ke database (Connolly danBegg, 2005, p16). Menurut Jeffery, Lonnie dan Kevin (2004, p524), Database Management System (DBMS) adalah perangkat lunak khusus yang digunakan untuk membuat, mengontrol, dan mengelola sebuah database. Menurut Gerald V. Post (2005, p2), Database Management System (DBMS) merupakan software yang mendefinisikan database, menyimpan data, mendukung query language, menghasilkan report, dan membuat data entry screen. Keuntungan DBMS (Connolly dan Begg, 2005, p26) : 1. Kontrol terhadap pengulangan data 2. Konsistensi data 3. Lebih banyak informasi yang didapat dari jumlah data yang sama 4. Data dapat dipakai bersamaan 5. Peningkatan integritas data 6. Peningkatan keamanan 7. Penetapan standardisasi
15
8. Skala Ekonomis 9. Keseimbangan konflik requirment 10. Peningkatan data aksesibilitas dan respon 11. Peningkatan produktivitas 12. Peningkatan maintenance melalui data independence 13. Peningkatan concurrency 14. Peningkatan layanan recovery dan backup Kekurangan DBMS (Connolly dan Begg, 2005, p29): 1. Kompleksitas 2. Ukuran 3. Biaya DBMS 4. Penambahan biaya hardware 5. Biaya konversi 6. Performa 7. Tingkat kegagalan lebih tinggi
2.1.3 Komponen DBMS Komponen DBMS terdiri dari 5 komponen penting (Connolly dan Begg, 2005, p18) :
16
1. Perangkat keras Aplikasi dan DBMS memerlukan perangkat keras untuk berfungsi. Contoh perangkat keras yang digunakan DBMS dan aplikasi antara lain personal computer,mainframe. 2. Perangkat lunak Komponen dari perangkat lunak terdiri dari DBMS dan program aplikasi bersamadengan sistem operasi. Umumnya, program aplikasi ditulis dalam 3GL (bahasa pemrograman generasi ketiga) seperti java, c++, c, atau menggunakan 4GL (bahasa pemrograman generasi keempat), seperti SQL, yang dikombinasikan dengan 3GL. 3. Data Data adalah komponen terpenting dalam lingkungan DBMS. Menurut Connollydan Begg(2004, p20), data bertindak sebagai penghubung antara komponen mesindan pengguna. Database berisi data operasional dan metadata (data tentang data). 4. Prosedur Prosedur berkaitan dengan instruksi dan aturan yang menentukan rancangan dan penggunaan database.
17
Instruksi-instruksi tersebut umumnya berisi : a. Instruksi untuk menjalankan dan menghentikan DBMS. b. Instruksi untuk menggunakan fasilitas tertentu dari DBMS. c. Instruksi untuk membuat salinan backup dari database. d. Instruksi untuk menangani kegagalan perangkat keras atau perangkat lunak. 5. Manusia Komponen terakhir yaitu manusia yang terlibat dengan sistem
2.1.4 Fungsi DBMS Menurut Connolly dan Begg (2005, p48), DBMS memiliki sepuluh fungsi, yaitu: 1. Data storage, retrieval, and update DBMS harus dapat memungkinkan user untuk menyimpan, mengambil, dan mengupdate data di dalam basis data.
18
2. A user-accessible catalog DBMS harus memiliki sebuah katalog yang berisi deskripsi data item dan dapat diakses oleh user. 3. Transaction support DBMS harus memiliki sebuah mekanisme yang dapat menjamin baik seluruh update yang berhubungan dengan sebuah transaksi dapat dilakukan ataupun keseluruhan update tersebut tidak dilakukan. 4. Concurrency control services DBMS harus memiliki sebuah mekanisme untuk menjamin basis data di-update secara benar ketika banyak user meng-update basis data secara bersamaan. 5. Recovery services DBMS harus memiliki sebuah mekanisme untuk pemulihan basis data apabila terjadi bencana. 6. Authorization services DBMS harus memiliki sebuah mekanisme untuk menjamin bahwa hanya user yang memiliki otorisasi yang dapat mengakses basis data.
19
7. Support for data communication DBMS harus dapat terintegrasi dengan piranti lunak komunikasi, dapat mengakses database dari lokasi yang jauh. 8. Integrity services DBMS harus memiliki sarana untuk menjamin baik data di dalam basis data maupun pengubahan terhadap data mengikuti aturan-aturan tertentu (constraint). 9. Services to promote data independence DBMS harus menyertakan fasilitas-fasilitas untuk mendukung ketidaktergantungan piranti lunak terhadap struktur aktual dari basis data. 10. Utility services DBMS harus menyediakan serangkaian layanan kegunaan seperti program analisis statistik, pengawasan fasilitas, fasilitas reorganisasi indeks, dan lain-lain.
2.1.5 Entity Relationship Modeling Menurut Connolly dan Begg (2005, p342), ER Modeling adalah sebuah pendekatan top-down untuk merancang basisdata yang dimulai dengan mengindentifikasi data penting yang
20
disebut entitas dan relasi antara data yang harus diwakili dalam model. ER Modeling terdiri dari 2 tipe : 1. Tipe Entitas Menurut Connolly dan Begg (2005, p343), tipe entitas adalah kumpulan dari obyek-obyek dengan sifat atau properti yang sama, yang mana diidentifikasi oleh perusahaan yang mempunyai eksistensi yang independen. Konsep dasar dari bentuk Entity Relationship adalah tipe entitas. Sebuah tipe entitas memiliki keberadaan yang bebas dan bisa menjadi obyek dengan keberadaan fisik atau menjadi obyek dengan keberadaan konseptual. Ini berarti
perancang
mengidentifikasikan
yang entitas
berbeda yang
berbeda.
mungkin Entity
orrurrence adalah obyek yang dapat dikenal/diidentifikasi secara unik dari sebuah tipe entitas. 2. Tipe Relasi Menurut Connolly dan Begg (2005, p346), relationship type adalah kumpulan keterhubungan yang mempunyai arti diantara tipe-tipe entitas. Setiap relasi diberi nama sesuai dengan fungsinya. Relationship occurrence adalah
21
suatu asosiasi/hubungan yang dapat diidentifikasikan secara unik, yang mana memasukkan satu kejadian dari setiap tipe entitas yang berpartisipasi. Contoh:
Gambar 2.1 Relationship Occurrence (Connolly
dan
Begg 2005, p346)
Derajat dari relasi adalah jumlah dari partisipasi tipe entitas dalam sebuah tipe relasi. Entitas yang berhubungan dalam sebuah tipe relasi dikenal sebagai participant dalam relationship dan jumlah participant dalam sebuah tipe relationship disebut sebagai derajat dari relationship. Oleh karena itu, derajat dari sebuah relationship berderajat dua disebut binary, sedangkan relationship berderajat tiga disebut sebagai ternary, dan seterusnya.
22
3. Attribute Menurut Connoly dan Begg (2005, p350-352), atribut adalah
sifat
dari
sebuah entity atau
sebuah
tipe
relationship. Atribut menyimpan nilai dari setiap entity occurrence dan mewakili bagian utama dari data yang disimpan dalam basis data. Attribute domain adalah sejumlah nilai yang diperkenankan untuk satu atau lebih atribut. Setiap atribut yang dihubungkan dengan sejumlah nilai disebut domain. Domain mendefinisikan nilai-nilai yang dimiliki sebuah atribut dan sama dengan konsep domain pada model relasional. Simple Attribute adalah atribut yang terdiri dari satu komponen tunggal dengan keberadaan yang bebas. Simple Attribute tidak bisa dibagi lagi ke dalam komponen yang lebih kecil. Contohnya, posisi
dan
gaji
dari
entity
pegawai.
Sedangkan
Composed attribute adalah sebuah susunan atribut dari banyak komponen dengan sebuah keberadaan yang bebas dari masing-masingnya. Dalam hal ini beberapa atribut dapat dipisahkan menjadi komponen yang lebih kecil lagi dengan keberadaan yang bebas dari masingmasingnya.
Contohnya
atribut
alamat
dari
entity
kantor cabang yang mengandung nilai (jalan, kota, kode pos) bisa dipecahkan menjadi simple attribute jalan, kota,
23
dan kode pos. Single value attribute adalah atribut yang hanya menyimpan nilai tunggal untuk suatu sifat dari entity. Multi-valued attribute adalah atribut yang bisa menyimpan nilai lebih dari satu untuk suatu sifat dari entity. Contohnya atribut telepon pada entity kantor cabang yang bisa memiliki lebih dari satu nomor telepon. Derived attribute (atribut turunan) adalah atribut yang menunjukkan
nilai
yang diperoleh dari atribut yang
berhubungan, tidak terlalu dibutuhkan dalam tipe entity yang sama. Atribut turunan mungkin juga menyangkut hubungan dari atribut pada tipe entity yang berbeda. 4. Kunci (Key) Menurut Connoly dan Begg (2005, p78-79), kunci relasi sangat dibutuhkan untuk mengidentifikasi satu atau lebih atribut yang memiliki nilai unik setiap tuple dalam relasi. Macam-macam kunci relasi : 1. Simple Key Simple Key adalah suatu kunci yang dibentuk oleh satu atribut. 2. Composite Key Composite
Key
adalah
kunci
berdasarkan lebih dari satu atribut.
yang
disusun
24
3. Candidate Key Candidate Key adalah suatu atribut atau satu set minimal
atribut
yang mengidentifikasikan secara
unik suatu kejadian spesifik dari entity. 4. Primary Key Primary Key adalah satu atribut atau satu set minimal
atribut
yang
tidak
hanya
mengidentifikasikan secara unik suatu kejadian spesifik, tapi juga dapat mewakili setiap kejadian dari suatu entity. 5. Alternative Key Alternative Key adalah kunci kandidat yang tidak terpakai sebagai kunci primer. 6. Foreign key Foreign key adalah satu atribut yang melengkapi satu hubungan (relationship) yang menunjukkan ke induknya. 5. Structural Constraint Menurut
Connolly
dan
Begg
(2005,
p356-
357),Constraints seharusnya mencerminkan batasan dari hubungan sebagai suatu tanggapan dalam dunia nyata. Tipe
utama
constraints
dalam
hubungan
disebut
multiplicity. Multiplicity adalah sejumlah kejadian yang
25
mungkin terjadi pada sebuah tipe entity dimana memungkinkan berhubungan dengan satu kejadian lain yang bergantung pada sebuah tipe entity melalui sebuah hubungan yang nyata. Multiplicity membatasi jalan setiap entity-entity yang terhubung. Derajat yang paling umum untuk relationship ialah binary(degree two) Binary relationship pada umumnya mengarah pada : 1. One-to-One (1:1) Relationship Pada One-to-one relationship, satu kejadian entity tunggal hanya dapat berhubungan dengan satu kejadian entity tunggal dari entity yang lain.
Gambar 2.2 Contoh representasi One-to-One Relationship (Connolly dan Begg 2005, p357)
(1:1)
26
Gambar 2.3 Multiply One-to-One (Connolly dan Begg 2005, p358)
(1:1)
Relationship
2. One-to-Many (1:*) Relationship Pada one-to-many relationship, satu kejadian entity tunggal dapat berhubungan dengan lebih dari satu kejadian entity tunggal dari entity yang lain.
Gambar
2.4
Contoh
representasi
One-to-Many
Relationship (Connolly dan Begg 2005, p358)
(1:*)
27
Gambar 2.5 Multiply One-to-Many (1:*) Relationship (Connolly dan Begg 2005, p359)
3. Many-to-Many (*:*) Relationship Pada many-to-many relationship, lebih dari satu kejadian entity tunggal dapat berhubungan dengan lebih dari satu kejadian entity tunggal dari entity yang lain.
28
Gambar 2.6 Contoh representasi Many-to-Many (*:*) Relationship (Connolly dan Begg 2005, p360)
Gambar 2.7 Multiply Many-to-Many (*:*) Relationship (Connolly dan Begg 2005, p360)
29
2.1.6 Database Languages Bahasa dalam basisdata dibedakan menjadi dua bentuk : 1. Data Definition Language (DDL) Menurut Connolly dan Begg (2005, p40), pengertian Data Definition Language adalah memperbolehkan
Database
suatu
bahasa
Administrator (DBA)
yang atau
pengguna untuk mendeskripsikan dan memberi nama suatu entitas, atribut, dan relasi data yang dibutuhkan untuk aplikasi, bersama dengan integritas data yang diasosiasikan dan batasan (constraint) keamanan data. 2. Data Manipulation Language (DML) Menurut Connolly dan Begg (2005, p40), pengertian Data
Manipulation Language adalah suatu bahasa yang
menyediakan
seperangkat
operasi
untuk
mendukung
manipulasi data yang berada pada basis data.Pengoperasian data yang akan dimanipulasi biasanya meliputi : 1. Penambahan data baru ke dalam basis data. 2. Modifikasi data yang disimpan ke dalam basis data. 3. Pengembalian data yang terdapat di dalam basis data. 4. Penghapusan data dari basis data. DML dibagi menjadi 2 jenis yaitu Procedural dan Nonprocedural. Menurut Connolly dan Begg (2005, p41), pengertian Procedural DML adalah suatu bahasa yang
30
memperbolehkan pengguna untuk mendeskripsikan ke sistem data apa yang dibutuhkan dan
bagaimana
mendapatkan data tersebut secara tepat, sedangkan Nonprocedural DML adalah
sebuah
bahasa
yang
mengizinkan pengguna untuk menentukan data apa yang dibutuhkan tanpa memperhatikan bagaimana data diperoleh.
2.1.7 Fourth-Generation Language (4GLs) Menurut Connolly dan Begg (2005, p42), tidak terdapat persetujuan umum tentang bahasa generasi keempat. Berbeda dengan bahasa generasi ketiga yang membutuhkan banyak baris untuk sebuah operasi, generasi keempat ini membutuhkan lebih sedikit baris untuk sebuah operasi dibanding dengan bahasa generasi sebelumnya. Sebuah bahasa generasi keempat sangat diharapkan dapat menjadi tumpuan yang sangat besar untuk komponenkomponen yang levelnya lebih tinggi yang dikenal dengan fourth-generation tools. Bahasa generasi keempat meliputi : 1. Presentation language, seperti query languages dan report generators
31
2. Speciality language, seperti spreadsheets dan database language 3. Application generators yang mendefinisi, melakukan insert, update, delete data dari database ke aplikasi yang sedang dibangun 4. Very
high-level
languages
yang
digunakan
untuk
mengenerate applicationcode
2.1.8 Siklus Hidup Basisdata Karena sistem database adalah komponen fundamental dari sistem informasi organisasi yang lebih besar, siklus perkembangan sistem database sangat erat kaitannya dengan siklus dari sistem informasi. Untuk aplikasi basisdata yang kecil dengan jumlah pengguna yang sedikit, tidak dibutuhkan siklus hidup basisdata yang kompleks. Bagaimanapun,
saat
merancang
aplikasi
basisdata
menengah sampai besar dengan jumlah pemakai puluhan hingga ribuan pemakai, menggunakan ratusan query dan aplikasi program, siklus hidup dapat menjadi sangat kompleks. Berikut ini adalah gambar tahapan – tahapan siklus hidup aplikasi basisdata menurut Conolly dan Begg (2005, p284).
32
Diagram 2.1 Siklus Hidup Aplikasi Basisdata (Connolly dan Begg, 2005, p284)
33
2.1.8.1
Perencanaan Basisdata (Database Planning) Merupakan aktifitas yang merencanakan tahapan dari daur hidup sistem basisdata dapat direalisasikan secara lebih efisien dan efektif. Perencanaan basisdata harus terintegrasi dengan seluruh strategi sistem informasi dari organisasi bersangkutan. Ada tiga permasalahan pokok dalam merumuskan suatu strategi sistem informasi (Connolly dan Begg, 2005, p285), yaitu : a. Identifikasi rencana dan tujuan perusahaan dengan penentuan sistem informasi yang dibutuhkan. b. Evaluasi sistem informasi yang berjalan untuk menentukan kelebihan dan kelemahan sistem yang ada. c. Penilaian terhadap peluang-peluang informasi teknologi
yang
mungkin
mendatangkan
keuntungan yang kompetitif.
2.1.8.2
Definisi Sistem (System Definition) Definisi
sistem
menjelaskan
batasan-
batasan dan ruang lingkup aplikasi basisdata dan
34
sudut pandang mayoritas pengguna (Connoly dan Begg, 2005, p286).
2.1.8.3
Pengumpulan dan Analisis kebutuhan (Requirement Collection and Analysis) Pengumpulan
dan
analisis
kebutuhan
adalah proses pengumpulan dan analisa informasi tentang bagian perusahaan yang didukung yang didukung aplikasi basisdata dan menggunakan informasi
untuk
mengidentifikasi
kebutuhan-
kebutuhan pengguna dari sistem yang baru (Connolly dan Begg, 2005, p288). Terdapat banyak teknik untuk menyatukan informasi yang disebut fact-finding techniques. Informasi yang dikumpulkan untuk tiap user view utama (yaitu job role atau enterprise application area) meliputi: •
Deskripsi data yang digunakan atau dihasilkan
•
Rincian bagaimana data digunakan atau dihasilkan
35
•
Semua kebutuhan-kebutuhan tambahan untuk aplikasi basisdata yang baru.
2.1.8.4
Perancangan Basisdata (Database Design) Perancangan basisdata merupakan proses membuat rancangan basisdata yang mendukung operasi- operasi dan tujuan-tujauan perusahaan (Connolly dan Begg, 2005, p291). Terbagi atas 3 tahap antara lain: ∗
Perancangan Basisdata Konseptual (Conceptual Database Design) Proses membuat penjelasan implementasi database pada penyimpanan sekunder, menggambarkan
hubungan
dasar,
organisasi file, dan indeks yang digunakan untuk
mencapai
akses
yang
efisien
terhadap data, dan setiap ruang lingkup integritas yang terkait dan nilai keamanan.
36
∗
Perancangan Basisdata Logikal (Logical Database Design) Proses pembuatan sebuah model data yang digunakan
dalam
suatu
perusahaan
berdasarkan pada model data yang spesifik, tetapi independen dari DBMS tertentu dan pertimbangan fisik lainnya. ∗
Prancangan Basisdata Fisikal (Physical Database Design) Proses membuat penjelasan implementasi database pada penyimpanan sekunder, menggambarkan
hubungan
dasar,
organisasi file, dan indeks yang digunakan untuk
mencapai
akses
yang
efisien
terhadap data, dan setiap ruang lingkup integritas yang terkait dan nilai keamanan.
2.1.8.5
Pemilihan DBMS (DBMS Selection) Pemilihan DBMS adalah pemilihan DBMS yang sesuai untuk mendukung aplikasi basisdata
37
(Connolly dan Begg, 2005, 295). Langkahlangkah utama untuk memilih DBMS adalah: •
Mendefinisikan istilah-istilah yang mengarah pada pembelajaran
•
Daftar pendek dua atau tiga produk
•
Mengevaluasi produk
•
Merekomendasikan pilihan dan membuat laporan
2.1.8.6
Perancangan Aplikasi (Application Design) Perancangan aplikasi adalah perancangan antarmuka
pengguna
dan
program-program
aplikasi yang digunakan dan memproses basisdata.
2.1.8.7
Prototipe (Prototyping) Prototipe adalah pembangunan model kerja aplikasi basisdata (Connolly dan Begg, 2005, p304). Terdapat dua strategi prototipe yang biasa digunakan
sekarang
ini,
yaitu
requirement
prototyping dan evolutionary prototyping.
38
Requirement
prototyping menggunakan
prototipe untuk menentukan kebutuhan-kebutuhan yang diusulkan aplikasi basisdata dan jika kebutuhan -kebutuhan sudah dilengkapi maka prototipe
tidak
dipakai
lagi
atau
dibuang.
Sedangkan evolutionary prototyping digunakan untuk tujuan yang sama, tetapi perbedaannya requirements prototyping adalah prototipe tidak dibuang tetapi dengan perkembangan lebih lanjut menjadi aplikasi kerja basisdata.
2.1.8.8
Implementasi (Implementation) Implementasi adalah realisasi fisik basis data dan perancangan aplikasi (Connolly dan Begg, 2005, p304). Implementasi basisdata dicapai menggunakan DDL (data definition language) dan aplikasi menggunakan 4GL (Fourth generation language).
39
2.1.8.9
Konversi Data dan Muatan Data (Data Conversion and Loading) Konversi data dan muatan data adalah memindahkan semua data yang ada kedalam basisdata yang baru dan mengkonversikan semua aplikasi yang ada untuk digunakan pada basisdata yang baru (Connolly dan Begg, 2005, p305).
2.1.8.10
Pengetesan (Testing) Pengetesan adalah proses mengeksekusi program-program
dengan
tujuan
untuk
menemukan kesalahan-kesalahan (Connolly dan Begg, 2005, p305).
2.1.8.11
Pemeliharaan Operasional (Operational Maintenance) Pemeliharaan operasional adalah proses mengawasi dan memlihara sistem yang meliputi aktifitas mengawasi performa dari sistem dan
40
memelihara dan memperbarui aplikasi basisdata (Connolly dan Begg, 2005, p306).
2.1.9 Methodology Desain Basisdata Sebuah
pendekatan
terstruktur
yang
menggunakan
prosedur, teknik, alat-alat, dan bantuan dokumentasi untuk mendukung dan memfasilitasi proses desain. (Connolly dan Begg, 2005, p306). Rancangan metodologi terdiri dari beberapa fase yang masing-masing berisi sejumlah langkah, yang menjadi acuan perancang menentukan teknik yang tepat pada setiap tahapan proyek. Sebuah rancangan metodologi juga membantu desainer untuk
merencanakan,
mengelola,
mengendalikan,
dan
mengevaluasi pengembangan proyek database. Selain itu, rancangan
ini
merupakan
pendekatan
terstruktur
untuk
menganalisis dan pemodelan persyaratan-persyaratan untuk database dengan cara standar dan terorganisir. Dalam metodologi rancangan database, proses rancangan dibagi menjadi 3 fase:
41
1. Rancangan Basisdata Konseptual Proses pembangunan sebuah model data yang digunakan dalam perusahaan, independen dari semua pertimbangan fisik. Tahap desain konseptual basisdata dimulai dengan penciptaan data model konseptual perusahaan, yang sepenuhnya independen dari rincian implementasi seperti target DBMS, program aplikasi, bahasa pemrograman, platform
perangkat
keras,
masalah
kinerja,
atau
pertimbangan fisik lainnya. Langkah 1 Membangun model konseptual data Tujuan: Untuk membangun sebuah model data konseptual dari kebutuhan data perusahaan. Model data konseptional terdiri dari: tipe entitas, tipe hubungan, atribut dan domain atribut, kunci utama dan alternative, ruang lingkup terintegritasi. Model dta konseptual didukung oleh dokumentasi, termasuk diagram ER dan list data, yang dihasilkan selama perkembangan model ini. Langkah 1.1 Mengidentifikasi jenis entitas Tujuan:
Untuk
dibutuhkan
mengidentifikasi
tipe
entitas
yang
42
Langkah 1.2 Mengidentifikasi jenis hubungan Tujuan: Untuk mengidentifikasi hubungan penting yang ada antara tipe-tipe entitas Langkah 1.3 Mengidentifikasi dan mengasosiasikan atribut dengan tipe entitas atau hubungan Tujuan: Untuk mengasosiasikan atribut dengan tipe entitas atau hubungan yang cocok. Langkah 1.4 Menentukan domain atribut Tujuan: Untuk menentukan domain dari atribut pada model data konseptual. Langkah 1.5 Tentukan atribut calon kunci, primer, dan alternative Tujuan: Untuk mengidentifikasi kandidat kunci untuk setiap jenis entitas dan, jika ada lebih dari satu kandidat kunci, untuk dipilih salah satu untuk menjadi kunci utama dan lainnya sebagai kunci alternatif.
43
Langkah 1.6 Pertimbangkan penggunaan konsep pemodelan enhanced (langkah opsional) Tujuan: Untuk mempertimbangkan penggunaan konsep pemodelan enhanced, seperti spesialisasi /generalisasi, agregasi, dan komposisi. Langkah 1.7 Periksa Redundansi Model Tujuan: Untuk memeriksa keberadaan redudansi pada model Langkah 1.8 Validasi model konseptual terhadap transaksi pengguna Tujuan: Untuk menyakinkan bahwa model konsepsual mendukung transaksi yang dibutuhkan. Langkah 1.9 Review Model data konseptual dengan pengguna Tujuan Untuk meninjau model data konseptual dengan pengguna
untuk
memastikan
bahwa
mereka
mempertimbangkan sebagai representasi yang 'benar' dari data perusahaan yang dibutuhkan.
2. Rancangan Basisdata Logikal
44
Proses pembuatan sebuah model data yang digunakan dalam suatu perusahaan berdasarkan pada model data yang spesifik, tetapi independen dari DBMS tertentu dan pertimbangan fisik lainnya. Tahap rancangan database logis memetakan model konseptual ke model logis, yang dipengaruhi oleh model data untuk database target (misalnya, model relasional). Model data logis merupakan sumber informasi untuk fase desain fisik, menyediakan rancangan database fisik dengan sarana untuk membuat pengorbanan yang sangat penting untuk desain database yang efisien. Langkah 2 Membangun dan memvalidasi model data logis Tujuan: Untuk menerjemahkan model data konseptual menjadi model data logis dan kemudian memvalidasi model ini dan memeriksa bahwa model ini benar secara struktural dan mampu mendukung transaksi yang diperlukan.
Langkah 2.1 Membuat hubungan untuk model data logis
45
Tujuan: Untuk menciptakan hubungan antara model data logis untuk mewakili entitas, hubungan, dan atribut yang telah diidentifikasi. Langkah 2.2 Validasi relasi dengan menggunakan normalisasi Tujuan: Untuk memvalidasi hubungan pada data model logical menggunakan normalisasi Langkah 2.3 Validasi relasi terhadap transaksi pengguna Tujuan: Untuk meyakinkan bahwa relasi pada data model logical mensupport transaksi yang diperlukan. Langkah 2.4 Periksa integritas ruang lingkup Tujuan:
Untuk
memeriksa
ruang
lingkup
yang
terintegrasi diwakili oleh data model logikal
Langkah 2.5 Review Model data logis dengan pengguna
46
Tujuan: Untuk meninjau model data logis dengan pengguna untuk memastikan bahwa mereka menganggap model menjadi representasi yang benar dari data perusahaan yang diperlukan. Langkah 2.6 Menggabungkan model data logis ke model global (langkah opsional) Tujuan: Untuk menggabungkan model data logis lokal ke dalam model data logis global tunggal yang mewakili pandangan pengguna semua database. Langkah 2.7 Periksa perkembangan selanjutnya Tujuan: Untuk menentukan apakah ada perubahan yang signifikan dalam kemungkinan mendatang dan untuk menilai apakah model data logis dapat mengakomodasi perubahan ini. 3. Rancangan Database Fisikal Proses membuat penjelasan implementasi database pada penyimpanan sekunder, menggambarkan hubungan dasar, organisasi file, dan indeks yang digunakan untuk mencapai akses yang efisien terhadap data, dan setiap ruang lingkup integritas yang terkait dan nilai keamanan.
47
Tahap desain database fisik memungkinkan perancang untuk membuat keputusan tentang bagaimana database diimplementasikan. Oleh karena itu, desain fisik disesuaikan dengan DBMS tertentu. Ada umpan balik antara desain fisik dan desain logis, karena keputusankeputusan yang diambil selama membuat desain fisik untuk meningkatkan kinerja dapat mempengaruhi model data logis. Langkah 3 Terjemahkan logis data model untuk target DBMS Tujuan: Untuk menghasilkan skema database relasional dari model data logis yang dapat diimplementasikan dalam DBMS target. Langkah 3.1 Desain hubungan dasar Tujuan:
Untuk
menentukan
bagaimana
mewakili
hubungan dasar yang diidentifikasi dalam Model data logis pada target DBMS.
Langkah 3,2 Desain representasi asal data
48
Tujuan: Untuk menentukan bagaimana mewakili data yang diturunkan dalam Model data logis pada DBMS target. Langkah 3.3 Desain ruang lingkup umum Tujuan: Untuk merancang ruang lingkup umum untu target DBMS Langkah 4 Desain berkas organisasi dan indeks Tujuan: Untuk menentukan organisasi file yang optimal untuk menyimpan hubungan dasar dan indeks yang diperlukan untuk mencapai kinerja yang dapat diterima, yaitu, cara di mana hubungan dan tupel akan diungkapkan pada penyimpanan sekunder. Langkah 4.1 Menganalisis transaksi Tujuan: Untuk memahami fungsi dari transaksi yang akan berjalan pada database dan untuk menganalisis transaksi yang penting.
Langkah 4.2 Pilih file organisasi
49
Tujuan: Untuk menentukan organisasi file yang efisien untuk tiap hubungan dasar. Langkah 4.3 Pilih indeks Tujuan: Untuk menentukan aakah menambahan indeks akan meningkatkan kemampuan system. Langkah
4,4
Perkirakan
harddisk
space
yang
diperlukan Tujuan: Untuk memperkirakan jumlah space hardisk yang diperlukan untuk database. Langkah 5 Desain user views Tujuan: Untuk merancang pandangan pengguna yang telah
diidentifikasi
selama
perkembangan
siklus
pengumpulan dan analisis tahap sistem database yang dibutuhkan. Langkah 6 Desain mekanisme keamanan Tujuan: Untuk merancang mekanisme keamanan untuk database seperti yang ditentukan oleh pengguna selama perkembangan siklus pengumpulan dan analisis tahap sistem database yang dibutuhkan.
50
Langkah 7 Pertimbangkan pengenalan redundansi terkontrol Tujuan: Untuk menentukan apakah memperkenalkan redundansi secara terkendali oleh aturan normalisasi yang ringan akan meningkatkan kinerja sistem. Langkah 7.1 Menggabungkan hubungan satu-ke-satu (1:1) untuk mengurangi penggabungan Langkah 7.2 Menduplikasi atribut non-key dalam hubungan satu-ke-banyak (1: *) untuk mengurangi penggabungan Langkah 7.3 Menduplikasi atribut kunci asing dalam hubungan satu-ke-banyak (1: *) untuk mengurangi penggabungan
Langkah 7.4 Menduplikasi atribut dalam hubungan banyak-ke-banyak (*: *) untuk mengurangi penggabungan
51
Langkah 7.5 Memperkenalkan kelompok pengulangan untuk meningkatkan perfoma sistem Langkah 7.6 Membuat tabel ekstrak untuk membuat dan mengisi tabel dan memprosesnya saat sistem sedang tidak banyak meloading data. Langkah 7.7 Hubungan Partisi untuk menyimpan dan menganalisis sejumlah data yang besar. Langkah 8 Monitor dan menyempurnakan sistem operasional Tujuan: Untuk memonitor sistem operasional dan meningkatkan
kinerja
sistem
untuk
memperbaiki
keputusan desain yang tidak tepat atau mencerminkan perubahan kebutuhan.
2.1.10 Normalisasi Menurut Connolly dan Begg (2005, p388), normalisasi adalah sebuah teknik untuk menghasilkan satu set relasi dengan atribut-atribut
yang
inginkan,
sesuai
dengan
kebutuhan
52
perusahaan.
Tujuan
dari
normalisasi
adalah
untuk
mengidentifikasi suatu set relasi yang sesuai, yang mendukung permintaan data dari perusahaan. Sedangkan menurut Whitten, Bentley, dan Dittman (2004, p306), normalisasi adalah teknik analisis data yang mengatur atribut data dalam kelompok untuk membentuk entitas yang non-redundan, stabil, fleksibel, dan mudah beradaptasi. Unnormalized (UNF) merupakan keadaan dimana sebuah tabel berisi satu atau lebih grup yang berulang. Grup yang berulang adalah sebuah atribut atau kumpulan atribut, dalam sebuah tabel, yang mempunyai multiple value. Untuk membuat entitas data yang normal, tidak redundan, stabil, dan fleksibel, diperlukan normalisasi.
Tahapan-tahapan Normalisasi menurut Connolly dan Begg (2005, p401):
1. First Normal Form (1 NF) Bentuk normal pertama merupakan sebuah relasi dimana irisan dari baris dan kolom hanya memiliki 1 nilai. Bentuk normal pertama ini dicapai apabila setiap nilai atribut adalah
53
tunggal, tidak ada atribut yang dapat memiliki lebih dari satu nilai untuk contoh entitas tunggal. Untuk mencapai bentuk normal pertama, yang harus dilakukan adalah: •
menghilangkan perulangan
•
menghilangkan perhitungan
•
menentukan primary key
2. Second Normal Form (2NF) Bentuk normal kedua merupakan sebuah relasi dari bentuk normal pertama dimana setiap atribut yang bukan primary key harus bergantung sepenuhnya secara fungsional dengan primary key (fully functional dependency). Untuk mencapai bentuk
normal
kedua,
yang
harus
dilakukan
adalah
menghilangkan ketergantuan parsial dari atribut-atribut nonprimary key.
3. Third Normal Form (3NF)
54
Bentuk normal ketiga merupakan sebuah relasi dari bentuk normal pertama dan kedua dimana tidak ada atribut yang nonprimay key tergantung transitif dengan primay key.
2.2 Tools yang digunakan Dalam penulisan skripsi ini, adapun tools yang digunakan dalam perancangan sistem basisdata dan aplikasi basisdata antara lain menggunakan diagramming tools dan software tools.
2.2.1 Diagramming Tools Dalam merancang dan membuat aplikasi sistem basisdata ini, adapun diagramming tools yang digunakan sebagai berikut: 1. Flowchart Flowchart adalah penggambaran secara grafik dari langkah-langkah dan urut-urutan prosedur dari suatu program. Flowchart menolong analis dan programmer untuk memecahkan masalah kedalam segmen-segmen yang lebih kecil dan menolong dalam menganalisis alternatif-alternatif lain dalam pengoperasian. (meftahul.com, 2011) Flowchart biasanya mempermudah penyelesaian suatu masalah khususnya masalah yang perlu dipelajari dan dievaluasi lebih lanjut.
55
Tabel 2.1 Simbol Flowchart (meftahul.com, 2011)
2. Data Flow Diagram (DFD) Menurut Jeffery L.Whitten (2007, p317), data flow diagram adalah sebuah model proses yang digunakan untuk menggambarkan aliran data melalui sebuah sistem dan tugas atau pengolahan yang dilakukan
56
oleh sistem. Konsep untuk modeling DFD terdiri dari (Jeffery L.Whitten, 2007, p319-322): •
Eksternal Agen Persegi empat menyatakan agen eksternal-batasan sistem
tersebut.
Kedua
model
membedakannya hanya ukurannya
Gambar 2.8 Eksternal Agen (Jeffery L.Whitten, 2007, p319)
sama,
yang
57
•
Data Store Untuk model dari DeMarco/Yourdon persegi panjang dengan kedua ujung terbuka menyatakan data store, terkadang disebut file atau database. Sedangkan model dari Gane dan Sareon ditandai dengan warna hijau disebelah kiri dan terbuka disebelah kanan.
Gambar 2.9 Data Store (Jeffery L.Whitten, 2007, p320)
58
•
Proses Name Persegi panjang bersudut (bentuk Gane dan Sarson) menyatakan nama proses (Process Name) atau bagaimana tugas dikerjakan.
Gambar 2.10 Process Name (Jeffery L.Whitten, 2007, p321)
3. State Transition Diagram (STD) State Transition Diagram (STD) menunjukan bagaimana sistem bertingkah laku sebagai akibat dari kejadian eksternal. Untuk melakukannya, STD menunjukkan berbagai model tingkah laku (disebut state) sistem dan cara di mana transisi dibuat dari state satu ke state lainnya. STD berfungsi sebagai dasar bagi pemodelan tingkah laku. (Pressman, 2001, p302)
59
Notasi yang digunakan dalam State Transition Diagram adalah : − Action (Aksi) Merupakan suatu tindakan yang dilakukan oleh sistem saat terjadi perubahan state atau merupakan suatu reaksi terhadap kondisi. Aksi menghasilkan output seperti pesan pada layar, cetakan pada printer, dan lain - lain. − Condition (kondisi) Merupakan suatu kejadian yang terdapat pada lingkungan eksternal yang dapat dideteksi oleh sistem yang akan mengakibatkan perubahan keadaan. − State Merupakan suatu simbol yang menyatakan suatu keadaan atau kondisi dari sebuah sistem. − Transition State Merupakan suatu simbol yang menyatakan perubahan dari state yang satu ke state yang lain.
60
2.2.2 Software Tools 1. PHP Software ini digunakan untuk melakukan interpretasi data kode PHP menjadi kode HTML sehingga hasilnya dapat ditampilkan di webbrowser (Budi Raharjo, 2011,246) 2. Database Management System (DBMS) Kumpulan program yang digunakan untuk mendefinisikan, mengatur, dan memproses database, sedangkan database itu sendiri esensinya adalah sebuah struktur yang dibangun untuk keperluan penyimpanan data. DBMS merupakan alat atau tool yang berperan untuk membangun struktur tersebut. (Budi Raharjo, 2011,10) 3. MySQL Merupakan software RDBMS (atau server database) yang dapat mengelola database dengan sangat cepat, dapat menampung data dalam jumlah sangat besar, dapat diakses oleh banyak user(multiuser), dan dapat melakukan suatu proses secara sinkron atau berbarengan(multi-threaded).
61
2.3 Pemahaman Object Studi Semua penjelasan tentang Object studi yang berkaitan dengan sistem yang berjalan didalam perusahaan dan berguna sebagai penjelasan dalam perancangan sistem basis data yang akan dibuat.
2.3.1 Customer Pelanggan atau Customer merupakan bagian penting dari perencanaan bisnis, tanpa customer maka tidak ada penjualan dan tidak ada perusahaan yang akan bertahan lama. Untuk bertahan perusahaan mengelompokan sesuai dengan dasar kebutuhan, kebiasaan dan atribut lainnya.(Alexander, Yves, 2010, p20). Dapat disimpulkan bahwa customer adalah bagian yang penting untuk memulai sebuah usaha yang kita jalankan.
2.3.2 Produksi Produksi dapat dikatakan sebagai suatu aktivitas dalam perusahaan industri berupa penciptaan nilai tambah dari input menjadi output secara efektif dan efisien sehingga produk sebagai output dari proses penciptaan nilai tambah itu dapat dijual dengan harga yang kompetitif di pasar global (Vincent Gaspersz, 2005:167).
62
2.3.3 Pengangkutan Konunikasi, Distribusi, dan Chanel Pemasaran merupakan bagian dari penampilan sebuah perusahaan ke Customer(Alexander, Yves, 2010, p26). Maka dapat disimpulan Distribusi merupakan bagian yang penting dalam proses binis yang menghubungkan perusahaan dengan customer atau pelanggan.
2.3.4 Supplier Relasi dengan supplier dibuat untuk memaksimalkan alokasi dari barang dan kegiatan perusahaan (Alexander, Yves, 2010, p39). Maka dapat disimpulkan hubungan dengan supplier merupakan bagian penting dari proses binis dalam suatu perusahaan. Dengan adanya relasi dengan supplier dapat memaksimalkan proses alokasi bahan baku dan meninggkatkan produksi ataupun penjualan produk.
2.3.5 Penjualan Penjualan adalah bagaimana menciptakan hubungan jangka panjang dengan pelanggan melalui produk atau jasa dari sebuah perusahaan. Dalam hal ini penjualan adalah bagaimana strategi yang
63
akan digunakan untuk mengintegrasikan perusahaan, pelanggan, dan korelasi antar keduanya (Kertajaya, 2006, p15).
L1
