BAB 2
LANDASAN TEORI
2.1. Pendekatan Basisdata
2.1.1. Pengertian Basisdata
Menurut Thomas Connoly dan Carolyn Begg(2010, p65), database is a shared
collection of logically related data and its description , designed to meet the information
needs of an organization. Basisdata adalah koleksi bersama data logis terkait dan
deskripsi, yang dirancang untuk memenuhi kebutuhan informasi dari suatu organisasi.
Atzeny (2003, p2) berpendapat bahwa basisdata adalah kumpulan data yang
digunakan untuk mempresentasikan informasi yang menarik kedalam sistem informasi.
Menurut indrajani (2010,p2) basis data adalah kumpulan terpadu dari elemen
data logis yang saling berhubungan . Basis data mengkonsolidasi banyak catatan yang
sebelumnya dismpan dalam file terpisah .
Jadi , kesimpulan dari definisa basis data menurut kami adalah kumpulan data –
data yang disimpan dalam sebuah sistem atau perangkat lunak komputer yang saling
terkait satu sama lain dan dapat dipakai untuk menampilkan informasi yang diperlukan
untuk sebuah organisasi.
2.1.2. Sistem Manajemen Basisdata
Menurut Connoly dan Begg (2010,p66) DBMS is a software system that enables
users to define , create maintain and control access to database.
DBMS ialah sebuah sistem perangkat lunak yang memungkinkan pengguna
untuk mendefinisikan, membuat memelihara dan mengontrol akses ke database.
9
2.1.2.1 Komponen DBMS
Menurut Thomas Connoly dan Carolyn Begg(2010, p68), ada 5 komponen utama
dalam lingkungan DBMS.
a. Perangkat Keras
DBMS membutuhkan perangkat keras untuk berjalan. Perangkat keras dapat
menjangkau dari komputer pribadi sampai komputer besar dan jaringan komputer.
b. Perangkat Lunak
Perangkat lunak dalam DBMS ialah perangkat lunak itu sendiri dan aplikasi yang
tergabung dalam sistem operasi, termasuk perangkat lunak jaringan apabila DBMS
digunakan dalam jaringan. SQL merupakan salah satu perangkat lunak dalam DBMS.
c. Data
Data ialah komponen terpenting dalam lingkungan DBMS jika dilihat dari sudut
pandang pengguna akhir. Data bertindak sebagai jembatan antara komponen mesin dan
komponen manusia.
e. Procedure
Prosedur mengacu pada instruksi dan aturan yang mengatur desain dan penggunaan
database.
f. Manusia
Komponen terakhir dalam DBMS ialah manusia yang terlibat dengan sistem. Berikut
manusia-manusia yang terlibat dalam lingkungan DBMS :
- Data dan Database Administrator
Data Administrator ialah orang yang bertanggung jawab atas pengaturan sumber
data termasuk rencana basis data.
10
Database Administrator ialah orang yang bertanggung jawab terhadap realisasi fisik
basis data termasuk desain fisik basis data dan implementasi, keamanan dan kontrol
integritas, pemeliharaan sistem operasional, memastikan penampilan yang memuaskan
dari aplikasi bagi pengguna.
- Database Designer
Database designer ialah orang yang berkonsentrasi mengidentifikasi data.
- Application Developers
Ketika basis data telah diimplementasikan, program aplikasi yang menyediakan
kebutuhan fungsional untuk pengguna terakhir harus diimplementasi.
- End User
End-user ialah pengguna yang menggunakan basis data yang telah dirancang dan
diimplementasikan dan dipelihara untuk melayani kebutuhan informasi mereka.
2.1.2.2 Keuntungan dan Kerugian DBMS
Keuntungan DBMS menurut Connoly dan Begg(2010,p77) ialah
- Mengontrol perulangan data
- Data yang konsisten
- Memperoleh informasi yang lebih banyak dari data yang sama.
- Meningkatkan integritas data
- Meningkatkan keamanan data
- Penetapan standart
- Skala ekonomi
- Menyeimbangkan persyaratan yang bertentangan
- Meningkatkan aksesbilitas dan responsitas data
11
- Meningkatkan produktivitas
- Menigkatkan pemeliharaan melalui ketidaktergantungan data
- Meningkatkan konkurensi
- Meningkatkan layanan cadangan dan pemulihan.
Kerugian DBMS menurut Connoly dan Begg(2010,p80) ialah
- Kompleksitas
- Ukuran
- Biaya penggunaan DBMS
- Biaya perangkat keras tambahan
- Biaya perubahan
- Penampilan
- Dampak kegagalan
2.1.3. Structure Query Language
Menurut Connoly dan Begg (2010,p66), Structure query languange(selanjutnya
disingkat SQL) adalah suatu bahasa query yang paling umum dan paling diakui dan
secara nyata adalah standart bagi DBMS.
2.1.3.1. Data Definition Language
Menurut Connoly dan Begg (2010,p66,p92), Data Definition Languange adalah
sebuah bahasa yang mengijinkan DBA atau pengguna untuk mendeskripsikan nama
entitas, atribut dan hubungan yang dibutuhkan untuk aplikasi, bersama batas-batas
integritas dan keamanan yang dibutuhkan, yang berfungsi bagi pengguna untuk
menentukan tipe, struktur dan batasan-batasan data yang disimpan didalam basisdata.
12
2.1.3.2. Data Manipulation Language
Menurut Connoly dan Begg (2010,p66, p92), Data Manipulation Language
sebuah bahasa yang menyediakan sebuah operasi untuk men dukung operasi manipulasi
basis data terhadap data yang disimpan didalam basis data yang berfungsi memberikan
hak kepada pengguna untuk menambah, memperbaharui, menghapus dan memperoleh
kembali data dari basis data.
2.1.4. Fourth Generation Language
Menurut Thomas Connoly dan Carolyn Begg(2010, p94) tidak ada konsensus
tentang apa yang merupakan bahasa generasi keempat, pada dasarnya, itu adalah bahasa
pemrograman singkatan. Sebuah operasi yang membutuhkan ratusan baris kode dalam
bahasa generasi ketiga, seperti COBOL, biasanya membutuhkan garis secara signifikan
lebih sedikit di sebuah 4GL.Dibandingkan dengan 3GL, yang prosedural, 4GL adalah
non prosedural, sedangkan pengguna dapat mendefinisikan apa yang harus dilakukan,
bukan bagaimana. 4GL yang diharapkan untuk mengandalkan sebagian besar pada level
yang lebih tinggi - komponen tingkat yang dikenal sebagai generasi keempat alat.
pengguna tidak menentukan langkah-langkah yang perlu program untuk melakukan
tugas, melainkan mendefinisikan parameter untuk alat-alat yang menggunakannya untuk
menghasilkan suatu program aplikasi. hal ini diklaim bahwa 4GLs dapat meningkatkan
produktivitas dengan faktor sepuluh, pada biaya membatasi jenis masalah yang dapat
diatasi. Generasi keempat bahasa mencakup :
- Presentasi bahasa, seperti bahasa query dan laporan Generator
- Bahasa khusus, seperti spreadsheet dan bahasa basis data
- Generator aplikasi yang mendefinisikan, insert, update, dan mengambil data dari
13
database untuk membangun aplikasi.
- Bahasa tingkat tinggi yang digunakan untuk menghasilkan kode aplikasi.
Menurut Thomas Connoly dan Carolyn Begg(2010, p94) SQL dan QBE, disebutkan
sebelumnya, adalah contoh dari 4GLs, kita tahu secara singkat membahas beberapa jenis
lain dari 4GL, antara lain :
Generator Bentuk
Generator bentuk merupakan fasilitas interaktif untuk cepat membuat input data
dan layout tampilan untuk bentuk layar.
Generator laporan
Generator laporan adalah fasilitas untuk membuat laporan dari data yang
tersimpan dalam database. itu mirip dengan bahasa query yang memungkinkan
pengguna untuk mengajukan pertanyaan dari database yang mengambil informasi untuk
laporan
Grafis Generator
Generator grafis adalah fasilitas untuk mengambil data dari database dan
menampilkan data sebagai grafik yang menunjukkan tren dan hubungan dalam data.
biasanya, memungkinkan pengguna untuk membuat grafik batang, pie chart, line chart,
dan sebagainya.
Aplikasi Generator
Aplikasi generator adalah fasilitas untuk memproduksi sebuah program yang
antarmuka dengan database. penggunaan generator aplikasi dapat mengurangi waktu
yang dibutuhkan untuk merancang suatu aplikasi perangkat lunak
14
2.1.5. Siklus Hidup Aplikasi Basisdata
Menurut Thomas Connoly dan Carolyn Begg(2010, p313) Sistem database
merupakan komponen fundamental dari sistem informasi organisasi yang lebih besar .
siklus hidup pengembangan sistem basis data berhubungan erat dengan siklus hidup dari
sistem informasi. tahapan dasar siklus hidup pengembangan sistem basis data
ditunjukkan pada gambar 1.1
Gambar 2.1 Siklus hidup pengembangan sistem basis data ,Thomas Connoly dan
Carolyn Begg (2010, p314)
15
Penting untuk mengenali bahwa tahapan siklus hidup pengembangan sistem basis data
tidak selalu berurutan, tetapi melibatkan beberapa jumlah pengulangan tahap
sebelumnya melalui perulangan umpan balik .
2.1.5. Database planning
Menurut Thomas Connoly dan Carolyn Begg(2010, p313)Perencanaan database
kegiatan manajemen yang memungkinkan tahapan dari siklus hidup pengembangan
sistem database untuk direalisasikan seefisien dan seefektif mungkin.
Perencanaan database harus terintegrasi dengan keseluruhan IS strategi
organisasi ada tiga isu utama yang terlibat dalam merumuskan suatu strategi IS. yaitu:
- Identifikasi tanaman perusahaan dan tujuan dengan tekad berikutnya kebutuhan sistem
informasi.
- Evaluasi sistem informasi saat ini untuk menentukan kekuatan dan kelemahan yang
ada.
- Penilaian TI peluang yang mungkin menghasilkan keunggulan kompetitif
merupakan langkah pertama yang penting dalam perencanaan basis data adalah untuk
secara jelas mendefinisikan pernyataan misi untuk sistem basis data.
pernyataan misi mendefinisikan tujuan utama dari sistem database. pernyataan
misi membantu untuk memperjelas tujuan dari sistem database dan menyediakan jalur
yang lebih jelas terhadap penciptaan effisien dan efektif dari sistem database yang
diperlukan. Perencanaan database juga harus mencakup pengembangan standar yang
mengatur bagaimana data akan dikumpulkan, bagaimana format harus ditentukan, apa
16
dokumentasi yang akan dibutuhkan, dan bagaimana desain dan implementasi harus
dilanjutkan.
2.1.5.2. System Definition
Menurut Thomas Connoly dan Carolyn Begg(2010, p316) Definisi sistem
menjelaskan ruang lingkup dan batas-batas dari sistem database dan pandangan
pengguna utama. sebelum mencoba untuk merancang suatu sistem database adalah
penting bahwa kita pertama-tama mengidentifikasi batas-batas dari sistem yang kita
sedang menyelidiki dan bagaimana interface dengan bagian lain dari sistem informasi
organisasi. adalah penting bahwa kita termasuk dalam batas-batas sistem kami tidak
hanya pengguna saat ini dan daerah aplikasi, tetapi juga pengguna masa depan dan
aplikasi .
2.1.5.2 .1 User View
Pengguna pandangan didefinisikan apa yang dibutuhkan dari sistem database
dari perspektif peran pekerjaan tertentu (seperti manajer atau supervisor) atau
perusahaan daerah aplikasi seperti pemasaran kontrol pribadi atau saham.
sistem database dapat memiliki satu atau lebih pandangan pengguna. mengidentifikasi
pandangan pengguna merupakan aspek penting dari pengembangan sistem database
karena membantu untuk memastikan bahwa tidak ada pengguna utama dari database
yang terlupakan ketika mengembangkan persyaratan untuk sistem basis data baru .
Pandangan pengguna juga sangat membantu dalam pengembangan sistem data yang
relatif kompleks dasar dengan memungkinkan persyaratan untuk menjadi dipecah
menjadi potongan-potongan dikelola. tampilan pengguna mendefinisikan apa yang
17
dibutuhkan dari sistem database dalam hal data yang akan diadakan dan transaksi yang
akan dilakukan pada data
Gambar 2.2 Representasi dari sebuah sistem basis data dengan banyak pandangan
pengguna : pandangan pengguna (1,2,3) dan (5,6) yang memiliki persyaratan yang
tumpang tindih, dimana pandangan pengguna 4 memiliki persyaratan yang
berbeda. Thomas Connoly dan Carolyn Begg(2010, p317)
2.1.5.3. Requirement Collection and Analysis
Menurut Thomas Connoly dan Carolyn Begg(2010, p316) persyaratan
pengumpulan dan analisis adalah proses mengumpulkan dan menganalisis informasi
tentang bagian dari organisasi yang akan didukung oleh sistem database. dan
menggunakan informasi ini untuk mengidentifikasi kebutuhan sistem baru.
panggung melibatkan pengumpulan dan analisis informasi tentang bagian dari
perusahaan yang akan dilayani oleh database. ada banyak teknik untuk mengumpulkan
informasi ini, teknik bisa Pencari Fakta. Informasi dikumpulkan untuk tampilan
18
pengguna utama (yaitu, pekerjaan peran perusahaan daerah appliacation), termasuk:
- Deskripsi penggunaan data atau dihasilkan
- Rincian tentang bagaimana data akan digunakan atau dihasilkan
- Persyaratan tambahan untuk sistem databsae baru.
ada tiga pendekatan utama untuk mengelola kebutuhan sistem database dengan
pemandangan beberapa pengguna:
- Pendekatan terpusat; persyaratan untuk setiap tampilan pengguna digabung menjadi
satu set persyaratan untuk sistem database baru. model data yang mewakili pandangan
pengguna dalam dibuat selama tahap desain database
Gambar 2.3 Pendekatan terpusat
- Pendekatan integrasi pandangan, kebutuhan untuk setiap tampilan pengguna tetap
sebagai daftar separed. Data model yang mewakili setiap tampilan pengguna diciptakan
dan kemudian bergabung selama tahap desain database. Thomas Connoly dan Carolyn
Begg (2010, p319)
19
Gambar 2.4 Pendekatan pandangan integrasi Menurut Thomas Connoly dan
Carolyn Begg (2010,p320).
- Kombinasi dari kedua pendekatan
2.1.5.4. Database Design
Menurut Thomas Connoly dan Carolyn Begg(2010, p320)proses menciptakan
desain yang akan mendukung pernyataan misi perusahaan dan tujuan misi untuk sistem
database yang diperlukan.
Pendekatan utama meliputi :
Menurut Thomas Connoly dan Carolyn Begg(2010, p321)Top-down atau Entity
Relationship Modelling Bottom-up atau Normalisasi
- Pendekatan top-down
Mulai dengan tingkat tinggi entitas dan hubungan dengan perbaikan berturut-turut untuk
20
mengidentifikasi model yang lebih rinci data.
Cocok untuk database yang kompleks.
- Bottom-up approach
Mulai dengan satu set terbatas atribut dan mengikuti seperangkat aturan untuk atribut
kelompok ke dalam hubungan yang mewakili entitas dan hubungan.
Cocok untuk sejumlah kecil atribut.
Menurut Thomas Connoly dan Carolyn Begg(2010, p322) Tujuan utama dari pemodelan
data meliputi:
- Untuk membantu dalam memahami makna (semantik) dari data;
- Untuk memfasilitasi komunikasi tentang persyaratan informasi.
Membangun model data memerlukan menjawab pertanyaan tentang entitas, hubungan,
dan atribut.
Sebuah model data memastikan kita memahami:
- Masing-masing perspektif pengguna dari data;
- Sifat data itu sendiri, independen dari representasi fisik;
- Penggunaan data melalui pandangan pengguna.
21
Kriteria untuk Menghasilkan sebuah Data Model Optimal
Gambar Thomas Connoly dan Carolyn Begg(2010, p322).
Menurut Thomas Connoly dan Carolyn Begg(2010, p322) Perancangan basis
data terdiri dari tiga fase utama :
- Perancangan basis data konseptual adalah proses membangun sebuah model dari data
yang digunakan dalam suatu perusahaan, independen dari semua pertimbangan fisik.
- Perancangan basis data logikal adalah proses membangun model data yang digunakan
dalam suatu perusahaan berdasarkan model data yang spesifik, tetapi independen dari
DBMS tertentu suatu pertimbangan fisik lainnya.
- Perancangan basis data fisikal adalah proses memproduksi deskripsi implementasi
basis data pada penyimpanan sekunder: itu menggambarkan relasi, organisasi file
berbasis, dan indexis digunakan untuk mencapai akses yang efisien terhadap data, dan
setiap kendala integritas terkait dan langkah-langkah keamanan.
22
Gambar 2.5 Data modeling dan architecture ansistarc
Menurut Thomas Connoly dan Carolyn Begg(2010, p325)
2.1.5.5. DBMS Selection
Menurut Thomas Connoly dan Carolyn Begg (2010, p325) Pemilihan suatu
DBMS yang tepat untuk mendukung sistem basis data.
Dilakukan setiap saat sebelum desain logis memberikan informasi yang memadai
tersedia mengenai persyaratan sistem.
2.1.5.5.1 Memilih DBMS
23
Menurut Thomas Connoly dan Carolyn Begg(2010, p325)Langkah utama untuk
memilih DBMS:
- Mendefinisikan Kerangka Acuan Studi;
Acuan untuk pemilihan DBMS didirikan, menyatakan tujuan dan ruang lingkup
penelitian dan tugas-tugas yang perlu dilakukan. Dokumen ini juga dapat mencakup
deskripsi kriteria yang akan digunakan untuk eveluate produk DBMS, daftar awal dari
produk yang mungkin, dan semua kendala yang diperlukan DAN rentang waktu untuk
penelitian.
- Daftarkan Dua atau Tiga DBMS;
Kriteria dianggap "penting" untuk implementasi yang sukses dapat digunakan
untuk menghasilkan daftar awal dari produk DBMS untuk evaluasi. misalnya, keputusan
untuk memasukkan produk DBMS mungkin tergantung pada anggaran yang tersedia,
tingkat dukungan vendor, kompatibilitas dengan perangkat lunak lain dan apakah produk
tersebut berjalan pada perangkat keras tertentu
- Mengevaluasi Produk;
Terdapat berbagai fitur yang dapat digunakan untuk mengevaluasi produk
DBMS. untuk tujuan evaluasi, fitur ini dapat dinilai sebagai kelompok atau individu.
24
Tabel 2.1 Daftar fitur yang mungkin untuk kelompok evaluasi produk DBMS
Thomas Connoly dan Carolyn Begg(2010, p327)
25
- Merekomendasikan Seleksi dan Menghasilkan Laporan.
Langkah terakhir dari pemilihan DBMS adalah untuk mendokumentasikan proses dan
untuk memberikan pernyataan temuan dan rekomendasi untuk produk DBMS tertentu
2.1.5.6. Application Design
Menurut Thomas Connoly dan Carolyn Begg(2010, p329) Perancangan user
interface dan program aplikasi yang menggunakan dan memproses basis data. Basis data
dan aplikasi desain adalah kegiatan paralel dari siklus hidup pengembangan sistem basis
data. Kita telaah secara singkat aspek desain applicaton: Transaksi desain dan desain
user interface.
2.1.5.6.1 Transaksi Desain
Suatu tindakan, atau serangkaian tindakan yang dilakukan oleh pengguna
tunggal atau program aplikasi, yang mengakses atau mengubah mengandung
database.
Tujuan desain transation adalah untuk mendefinisikan dan
mendokumentasikan karakteristik tingkat tinggi dari transaksi yang dibutuhkan
pada basis data, termasuk:
- Data yang akan digunakan oleh transaksi
- Fungsional charateristic transaksi
- Output dari transaksi
- Penting bagi pengguna
- Diharapkan tingkat penggunaan
26
Ada 3 tipe transaksi :
- Pengambilan Transaksi
Digunakan untuk mengambil data untuk ditampilkan di layar atau dalam
produksi laporan
- Update Transaksi
Digunakan untuk memasukkan catatan baru, menghapus catatan lama, atau
memodifikasi catatan yang ada dalam database.
- Campuran Transaksi
Melibatkan kedua mengambil data dan memperbarui data.
2.1.5.6.2 User Interface Design
Sebelum menerapkan suatu bentuk atau laporan, adalah penting bahwa
pertama-tama kita merancang pedoman tata letak yang berguna untuk
mengikuti ketika merancang bentuk atau laporan yang tercantum berikut ini :
- Meaningful tittle
- Comprehensible instructions
- Logical grouping and sequencing of fields
- Visually appealing layout of the form/report
- Familiar field labels
- Consistent terminologi and abbreviations
- Consistent use of color
- Visible space and boundaries for data entries field
- Convenient cursor movement
- Error correction for individual characters and entire field
27
- Error message for unacceptable values
- Optional field mark clearly
- Explanatory message for field
- Complation signal
2.1.5.7. Prototyping
Menurut Thomas Connoly dan Carolyn Begg(2010, p333) Menurut Thomas
Connoly dan Carolyn Begg(2010, p333), membangun sebuah model kerja dari sistem
database. prototipe adalah model kerja yang biasanya tidak memiliki semua fitur yang
diperlukan atau menyediakan semua fungsi dari sistem akhir. tujuan utama
mengembangkan sistem database prototipe adalah untuk memungkinkan pengguna
untuk menggunakan prototipe untuk mengidentifikasi fitur dari sistem yang bekerja
dengan baik atau tidak memadai dan jika mungkin untuk menyarankan perbaikan atau
bahkan fitur baru untuk sistem database.
ada strategi prototyping dua umum digunakan saat ini:
- Persyaratan prototyping menggunakan prototipe untuk menentukan persyaratan sistem
database yang diusulkan, dan sekali syarat-syarat yang lengkap, prototipe tersebut akan
dibuang
- Prototyping evolusi digunakan untuk tujuan yang sama, yang berbeda penting adalah
bahwa prototipe tidak dibuang, tetapi dengan perkembangan lebih lanjut menjadi sistem
database yang bekerja.
28
2.1.5.8. Implementation
Menurut Thomas Connoly dan Carolyn Begg (2010, p333), Implementation
adalah realisasi fisik dari basis data dan desain aplikasi. Implementasi basis data dicapai
dengan menggunakan:g
- DDL untuk membuat skema basis data dan database file yang kosong.
- DDL untuk membuat user view yang diinginkan.
- 3GL atau 4GL untuk membuat program aplikasi. Termasuk transaksi basis data
yang menggunakan DML atau ditambahkan ke bahasa pemrograman.
2.1.5.9. Data Converting and Loading
Menurut Thomas Connoly dan Carolyn Begg (2010, p334) Data Converting and
Loading merupakan tahap pemindahan data yang baru dan mengkonversi aplikasi yang
ada untuk dapat menggunakan basis data yang baru. Tahap ini diperlukan ketika sistem
database baru menggantikan yang lama.
2.1.5.10. Testing
Menurut Thomas Connoly dan Carolyn Begg (2010, p334) Testing adalah proses
mengeksekusi program aplikasi dalam rangka untuk menemukan kesalahan dengan
skenario pengujian yang direncanakan dan data yang sesungguhnya. Testing hanya akan
terlihat jika ada kesalahan dalam perangkat lunak.
29
2.1.5.11. Operational Maintenance
Menurut Thomas Connoly dan Carolyn Begg (2010, p335) Operational
Maintenance adalah proses pengawasan dan pemeliharaan sistem setelah instalasi,
meliputi:
- Pemantauan kinerja sistem. Jika kinerja menurun, diperlukan perbaikan atau
pengaturan ulang basis data.
- Pemeliharaan dan pembaharuan aplikasi basis data jika diperlukan.
- Penggabungan kebutuhan baru ke dalam aplikasi basis data.
2.1.6. Entity-Relationship Modeling
Menurut Thomas Connoly dan Carolyn Begg (2010, p371), Entity Relationship
Diagram (ERD) adalah ilustrasi dari entitas - entitas dalam bisnis dan hubungan antar
entitas. ERD memisahkan informasi yang diperlukan dalam kegiatan bisnis dari
aktivitas-aktivitas yang dilakukan dalam bisnis. Dengan demikian, meskipun terjadi
perubahan dalam proses bisnis, jenis informasi hampir tetap konstan. Oleh karena itu,
struktur data juga hampir tidak berubah.
Tujuan utama dari penggambaran ERD adalah untuk menunjukkan struktur objek
data (entity) dan hubungan (relationship) yang ada pada objek. ERD berguna bagi
profesional, sistem karena ERD menunjukkan hubungan antara data store pada Data
Flow Diagram (DFD).
Ada lima jenis konstruksi utama ERD, yaitu:
- Entity
- Attributes
30
- Relationship
- Key
- Structural Constraints
a. EntityTypes
Menurut Thomas Connoly dan Carolyn Begg (2010, p372), Entity atau entitas
adalah konsep dasar dalam pemodelan basis data dalam bentuk individu yang mewakili
sesuatu yang nyata dan dibedakan dari sesuatu yang lain. Sebagai contoh adalah
pemasok, barang, kategori, dan lain - lain. Entitas memiliki hubungan entitas sejenis dan
berada dalam lingkup yang sama.
1) Strong Entity
Untuk setiap entitas yang kuat dalam model data, menciptakan hubungan
mencakup semua atribut sederhana dari setiap entitas.
2) Weak Entity
Untuk setiap entitas lemah dalam model data, menciptakan hubungan mencakup semua
atribut sederhana dari setiap entitas primary key dari entitas lemah merupakan bagian
atau pengurangan penuh dari setiap pemilik entitas sehingga pengenalan kunci utama
entitas lemah tidak dapat dibuat sampai semua hubungan dari pemilik entitas telah
dipetakan.
b. Attribute
Menurut Thomas Connoly dan Carolyn Begg (2010, p379), Attribute ialah
karakteristik dari suatu entitas yang menggambarkan suatu entitas. Atribut juga dapat
31
disebut sebagai karakteristik atau properti dari entitas yang memberikan penjelasan rinci
tentang entitas tersebut. Sebagai contoh, pemasok memiliki atribut seperti identitas
seperti: id_supplier, nama_supplier, alamat dan karakteristik lainnya dapat mewakili
identitas pemasok. Setiap atribut bisa bersifat wajib (wajib diisi, not NULL) dan dapat
juga opsional.
1) Simple Attributes and Composite Attributes (Atribut Sederhana dan Atribute
Komposit)
Contoh yang dapat dikategorikan sebagai atribut sederhana ialah id_supplier,
nama_supplier, alamat dan no_telp. Sementara atribut komposit terdiri dari beberapa
atribut sederhana (dapat dipahami secara hirarki). Sebagai contoh, atribut alamat, yang
dapat dibagi menjadi jalan, kota, dan kode _pos.
2) Atribut Bernilai-Tunggal (Single-Valued Attributes) dan Atribut Bernilai
Ganda (Multivalued Attributes)
Nilai-tunggal berarti hanya mempunyai satu nilai data. Sebagai contoh,
nama_supplier atribut untuk satu pemasok hanya terdiri dari satu nama untuk satu
entitas. Sementara atribut ganda memiliki lebih dari satu nilai data.
3) NULL Attributes (Atribut Bernilai-Null)
Jika sebuah baris tidak memiliki nilai (data) dalam kolom tertentu maka nilai
kolom tersebut disebut NULL. NULL adalah nilai yang unik dalam basis data.
32
4) Derived Atribute (Atribut Turunan)
Nilai atribut ini berasal dari atribut lainnya. Biasanya berlaku untuk perhitungan
selisih yang dibutuhkan oleh suatu atribut, dan perhitungannya tergantung pada atribut
lainnya yang berkaitan dengan atribut yang bersangkutan.
c. RelationshipTypes
Relationship (relasi) menunjukkan adanya hubungan antara sejumlah entitas
berasal dari himpunan entitas yang berbeda. yang berbeda tidak memiliki keberadaan
fisik kecuali yang mewarisi dari hubungan entitas tersebut.
Derajat dari relationshp menjelaskan jumlah entity yang berpartisipasi dalam
suatu relationship. Terdapat tiga jenis derajat dari relationship, unary degree (derajat
satu), binary degree (derajat dua) dan ternary degree (derajat tiga).
1. Unary Degree (Derajat Satu)
Adalah satu buah relationship menghubungkan satu buah entity.
Contoh : Manusia menikah dengan manusia, relationship menikah hanya
menghubungkan entity manusia.
2. Binary ( Derajat Dua )
33
Adalah satu buah relationship yang menghubungkan dua buah entity.
Contoh : Pegawai memiliki kendaraan, sebuah relationship memiliki mengubungkan
entity Pegawai dan entity Kendaraan.
3. Ternary ( Derajat Tiga )
Adalah satu buah relationship menghubungkan tiga buah entity.
Contoh : Pegawai pada kota tertentu mempunyai suatu Proyek.
Entity Bekerja mengubungkan Entity Pegawai, Proyek dan Kota.
d. Key (Kunci)
Menurut Connoly dan Begg (2010, p381-383), kunci relasi sangat dibutuhkan
untuk mengidentifikasi satu atau lebih atribut yang memiliki nilai unik untuk setiap tuple
dalam relasi.
Setiap entitas biasanya memiliki sebuah atribut yang nilainya berbeda untuk
masing - masing individu dalam entity. Oleh karena itu, dua nilai yang sama untuk
atribut key tersebut tidak diperbolehkan.
Macam-macam kunci relasi:
1. Kunci Sederhana (Simple Key)
Kunci sederhana adalah suatu kunci yang dibentuk oleh suatu atribut.
2. Kunci Komposit (Composite Key)
34
Kunci komposit adalah kunci yang disusun berdasarkan lebih dari satu atribut.
3. Kunci Kandidat (Candidate Key)
Kunci kandidat adalah suatu atribut atau satu set minimal atribut yang
mengidentifikasi secara unik suatu kejadian spesifik dari entitas.
4. Kunci Primer (Primary Key)
Kunci primer adalah suatu atribut atau satu set minimal atribut yang tidak hanya
mengidentifikasi secara unik suatu kejadian spesifik dari entitas, tapi juga dapat
mewakili setiap kejadian dari suatu entitas.
5. Kunci Alternatif (Alternative Key)
Kunci alternative adalah kunci kandidat yang tidak sebagai sebagai kunci primer.
6. Kunci Tamu (Foreign Key)
Kunci tamu adalah satu atribut yang melengkapi satu hubungan (relationship)
yang menunjukkan ke induknya.
e. Structural Constraints (Kendala Struktural)
Sekarang kita periksa kendala yang dapat ditempatkan pada jenis entitas yang
berpartisipasi dalam suatu hubungan. kendala harus mencerminkan pembatasan
hubungan seperti yang dirasakan dalam dunia nyata. Contoh kendala tersebut mencakup
persyaratan bahwa properti untuk disewakan harus memiliki pemilik dan setiap cabang
harus memiliki staf. Jenis utama dari kendala pada hubungan yang disebut multiplicity.
35
1. Multiplicity
Ada tiga jenis multiplicity , yaitu:
1) One-to-One Relationships (1:1)
2) One-to-Many Relationships (1:N)
36
3) Many-to-Many Relationships (M:N)
2. Cardinality Constraints (Kendala Kardinalitas)
Kendala kardinalitas menjelaskan jumlah maksimum kejadian dari kemungkinan
hubungan untuk entitas yang berpartisipasi dalam jenis hubungan yang diberikan.
37
3. Participations Constraints (Kendala Partisipasi)
Kendala partisipasi menentukan apakah semua atau hanya beberapa kejadian
entitas yang berpartisipasi dalam suatu hubungan.
2.1.7. Metodologi Perancangan Basis Data
2.1.7.1. Perancangan Basis Data Konseptual
Langkah awal dalam basis data konseptual adalah dengan membuat model data
dari informasi - informasi tentang perusahaan. Data yang ada dikembangkan lagi dengan
representasi konseptual yang meliputi entity, relationship, ,dan atribut yang secara
keseluruhan bebas dari detail implementasi seperti DBMS yang digunakan, program
aplikasi, bahasa pemrograman, platform untuk hardware, tingkat kinerja, dan
pertimbangan fisik lainnya.
Langkah - langkah dalam membuat sebuah model data konseptual:
a. Identify entity types (identifikasi jenis - jenis entitas).
Langkah pertama dalam membangun sebuah model data lokal adalah untuk
mengidentifikasi objek utama di mana pengguna membutuhkannya. Salah satu metode
untuk mengidentifikasi jenis entitas adalah dengan mengidentifikasi kata benda atau
frase kata benda yang salah telah ditentukan oleh pengguna.
b. Identify relationship types (identifikasi jenis - jenis relasi).
Pada tahap ini, identifikasi hubungan penting antara berbagai jenis entitas yang
telah diidentifikasi. Relationship diidentifikasi dengan menggunakan kata kerja atau
38
frase kata kerja. Namun perlu dicatat bahwa relasi yang kompleks yang melibatkan lebih
dari dua entitas dan relasi rekursif hanya melibatkan satu entitas.
c. Identify and associate attributes with entity or relationship types (Identifikasi
dan menghubungkan atribut dengan jenis - jenis entity atau relationship).
Dalam langkah ini, atribut dari entitas atau relasi yang paling sesuai saling
dihubungkan.
d. Determine attribute domain (Tentukan domain dari atribut).
Definisi Domain adalah penampung dari nilai yang dapat ditampung oleh atribut.
Tujuan dari langkah ini adalah untuk menentukan domain dari atribut yang ada dalam
data model lokal konseptual.
e. Determine candidate, primary, and alternate key attributes (Mendefinisikan
atribut - atribut, candidate key, dan primary key).
Tujuan dari langkah ini adalah untuk mengidentifikasi candidate key dari setiap
jenis entitas. Jika ada lebih dari satu candidate key, pilih salah satu-satunya primary key.
Acuan dalam memilih primary key di antara banyak candidate key, antara lain:
- Merupakan candidate key dengan jumlah paling sedikit.
- Merupakan candidate key yang nilainya jarang sekali berubah.
- Merupakan candidate key dengan jumlah karakter paling sedikit..
- Merupakan candidate key dengan jumlah paling sedikit dari nilai maksimum
(untuk atribut jenis numerik).
- Merupakan candidate key termudah digunakan dari sudut pandang pengguna.
f. Consider use enhanced modeling concepts (optional step) (Pertimbangkan
penggunaan konsep enchanced modeling) (langkah ppsional).
39
Langkah ini mempunyai sifat opsional (opsional), kita dapat mempertimbangkan
untuk menggunakan enchanced modelling, seperti spesialisasi, generalisasi, agregasi,
dan komposisi.
g. Check model for redundancy (Periksa model dan redundansi).
Tujuan dari langkah ini adalah untuk memeriksa ada atau tidaknya redudansi
dalam model basis data. Ketika menemukan adanya redudansi, maka redudansi dapat
dihapus oleh dua langkah:
- Meneliti hubungan one-to-one.
- Menghilangkan relasi redundansi.
h. Validate conceptual data model against user transaction (Validasi model
konseptual data terhadap transasksi pengguna).
Tujuan dari langkah ini adalah untuk memeriksa apakah model konseptual
mendukung transaksi yang diperlukan. Pemeriksaan dapat dilakukan dengan
menggunakan dua pendekatan, antara lain:
- Mendeskripsikan transaksi.
- Menggunakan alur transaksi.
i. Review conceptual data model with user (Melihat kembali data model
konseptual lokal dengan pengguna).
Dalam langkah ini dilakukan peninjauan ulang terhadap model data konseptual
termasuk ER bersama dengan pengguna untuk memastikan bahwa model yang ada
dengan sesusai diminta. Jika ada perubahan (anomali), maka harus dibuat perubahan.
2.1.6.2 Perancangan Database Logikal
40
Merancang database logis (Logical Database Design) adalah proses membangun
sebuah model dari data yang digunakan di perusahaan berdasarkan pada model data
yang spesifik tetapi bebas dari DBMS dan semua pertimbangan fisik. Tahap-tahapnya
adalah sebagai berikut:
a. Derive relations for logical data model (Menurunkan kaitannya dengan model
data logis).
Pada tahap ini, kita memperoleh hubungan model data logis untuk mewakili
entitas, hubungan dan atribut. Penurunan hubungan berkomitmen juga dapat ditemukan
pada konseptual model data, yaitu:
1) Entitas Kuat (Strong Entity)
Untuk setiap entitas yang kuat dalam model data, menciptakan hubungan
mencakup semua atribut sederhana dari setiap entitas.
2) Entitas Lemah (Weak Entity)
Untuk setiap entitas lemah dalam model data, menciptakan hubungan mencakup semua
atribut sederhana dari setiap entitas primary key dari entitas lemah merupakan bagian
atau pengurangan penuh dari setiap pemilik entitas sehingga pengenalan kunci utama
entitas lemah tidak dapat dibuat sampai semua hubungan dari pemilik entitas telah
dipetakan.
3) Relasi binnary one-to-many
Untuk setiap relasi biner satu-ke-banyak, entitas dirancang sebagai satu kesatuan
dan entitas induk (parent) banyak yang dirancang sebagai entitas anak (child).
4) Relasi binnary one-to-one
41
Dalam membuat relationship yang mewakili hubungan one-to-one di atas kardinalitas
kompleks tidak dapat digunakan untuk mengidentifikasi entitas induk dan anak entitas
dalam relasi.
5) Relasi rekursif binnary one-to-one
Sama seperti hubungan biner one-to-one, setiap hubungan satu-ke-satu rekursif,
tidak dapat digunakan untuk mengidentifikasi entitas induk dan entitas anak di
hubungan.
6) Relasi superclass / subclass
Untuk setiap subclass superclass hubungan / dalam model data konseptual,
kesatuan superclass diidentifikasi sebagai entitas induk dan entitas subclass sebagai
entitas anak.
7) Relasi binary many-to-many
Untuk setiap relasi biner many-to-many dibuat relasi yang merepresentasikan
relasi dan atribut manapun yang merupakan bagian dari hubungan tersebut. Atribut yang
membentuk primary key dari entitas yang berpartisipasi dalam hubungan ke dalam relasi
baru harus dianggap juga sebagai foreign key. Salah satu dari kedua foreign key juga
akan menjadi primary key dari relasi yang baru, dan cenderung akan bergabung dengan
satu atau lebih atribut.
8) Relasi kompleks
Untuk setiap relasi kompleks, dibuat relasi yang merepresentasikan relasi dan
mencakup semua atribut yang merupakan bagian dari hubungan tersebut. Atribut-atribut
yang membentuk primary key dari entitas yang partisipasi dalam kaitannya dengan
hubungan baru harus dianggap serta foreign key. Setiap foreign key yang mewakili
42
banyak dalam hubungan, secara umum, juga akan berfungsi sebagai primary key dari
relasi baru, dan kemungkinan akan bergabung dengan beberapa atribut lainnya.
9) Atribut Multi-valued
Untuk setiap atribut multi-nilai dalam entitas, membuat sebuah hubungan baru
yang merupakan multi-nilai atribut dan termasuk primary key ke dalam suatu hubungan
yang baru, juga harus dianggap sebagai primary key. Kecuali atribut multi-valued itulah
alternate key dari entitas, primary key dari relasi yang baru adalah kombinasi atribut
multi-valued dan primary key dari entitas tersebut.
b. Validate relations for logical data model (Memvalidasi relasi dengan
menggunakan normalisasi).
Proses normalisasi melibatkan relasi melalui beberapa langkah pemeriksaan
apakah atribut sesuai dengan bentuk peraturan normal. Proses reduksi hubungan model
data konseptual eharusnya udah memproduksi relasi yang ada dalam 3NF. Namun, jika
ternyata mengidentifikasi hubungan yang tidak ditemukan dalam 3NF dapat
menunjukkan bahwa ada beberapa bagian dari model Data logis atau konseptual satu.
Jika diperlukan, maka harus diulang restrukturisasi hubungan yang dipermasalahkan dan
model data untuk memastikan representasi yang tepat dari kebutuhan data dari
perusahaan.
c. Validate relations against user transactions (Memvalidasi pengguna ini
sehubungan dengan transaksi).
Tujuan dari tahap ini adalah untuk memvalidasi model data logis untuk
memastikan bahwa model dapat membantu transaksi yang diperlukan. Jika semua
transaksi dapat berjalan sampai selesai menggunakan model yang telah dibuat, dapat
dipastikan bahwa model ini disediakan untuk membantu menangani perusahaan. Namun,
43
jika ada transaksi yang tidak berjalan sampai selesai, maka harus diperiksa kembali
entitas, hubungan dan atribut dari model data.
d. Check integrity constraints (Memeriksa kendala integritas)
Kendala integritas adalah kendala yang diharapkan dapat mendefinisikan dan
memelihara database menjadi tidak lengkap, tidak akurat dan tidak konsisten. Beberapa
jenis integritas kendala yang harus dipertimbangkan adalah sebagai berikut:
1) Data yang diperlukan
2) Atribut domain constraints
3) Multiplicity
4) Entity Integrity
5) Referential Integrity
6) Kendala umum
e. Review logical data model with user (Meninjau kembali model data logical
dengan pengguna).
Logical data model yang lengkap dan didokumentasikan. Namun, pengguna
diminta untuk meninjau kembali model data logis untuk memastikan bahwa model data
logis sesuai dengan representasi yang diinginkan oleh perusahaan. Jika pengguna tidak
puas dengan model yang diberikan, tahap-tahap awal mungkin perlu restart. Namun, jika
pengguna puas dengan model yang diberikan, langkah berikutnya adalah tergantung
pada bagaimana jumlah pengguna yang akan dihubungkan dengan database, dan
bagaimana database akan dibentuk.
f. Merge logical data models into global model (Mengubah model data logikal ke
dalam model global) (langkah opsional).
44
Tahap ini diperlukan untuk desain database dengan beberapa pengguna dilihat
pendekatan diatur melihat integrasi. Sebuah logis lokal data model mewakili satu atau
lebih dilihat dari database. Namun, tidak semua pandangan, sementara model data logis
mewakili semua pandangan pengguna global database. Dengan demikian, dalam tahap
ini, merger bias dua atau lebih lokal logis data model ke model data global logis.
g. Check for future growth (Memeriksa untuk pertumbuhan di masa depan).
Merancang database logis berakhir dengan baik logis data model mampu
memperpanjang ke perkembangan di masa depan. Jika model hanya dapat mendukung
kebutuhan saat ini, kehidupan model relatif singkat dan pengerjaan ulang dari model
mungkin diperlukan untuk mengakomodasi kebutuhan baru. Hal ini penting untuk
mengembangkan model yang dapat diperluas dan memiliki kemampuan untuk
berkembang dalam rangka mampu mendukung kebutuhan baru dengan efek minimum
sisi dengan pengguna saat ini. Namun, apakah model yang akan diperiksa atau diubah di
masa depan dapat digunakan juga tidak bebas dari permintaan pengguna.
2.1.6.3 Perancangan Database Fisikal
Merancang database fisik (Physical Database Design) adalah proses memproduksi
deskripsi implementasi basis data pada penyimpanan sekunder. Desain ini
menggambarkan hubungan dasar, file organisasi, dan indeks yang digunakan untuk
beberapa mencapai akses data yang efisien dan pembatasan integrasi dan langkah-
langkah keamanan. Tahap-tahap adalah sebagai berikut:
a. Translate logical data model for target DBMS (Menerjemahkan model data
lodikal ke target DBMS).
45
Kegiatan pertama dalam database desain fisik terlibat dalam model
penerjemahan data yang terkait logis ke dalam bentuk yang dapat diimplementasikan
untuk target DMBS. Tahap-tahap yang meliputi:
1) Design base relations (Perancangan relasi dasar)
Untuk memulai proses desain fisikal, yang harus utama dilakukan adalah bersatu
dan memahami informasi tentang hubungan yang dihasilkan dari desain database logis.
Informasi yang dibutuhkan dapat diperoleh dari kamus data dan definisi setiap hubungan
yang dijelaskan dengan menggunakan Bahasa Database Desain (DBDL). Untuk
mewakili desain dari relasi dasar, dapat digunakan untuk mendefinisikan DBDL
domain, nilai-nilai default dan indikator nol.
2) Design representations of derived data (Merancang representasi dari data
yang diperoleh)
Atribut yang nilainya dapat ditemukan dengan menguji nilai atribut lain yang
disebut atribut diturunkan atau dihitung. Tujuan dari tahap ini adalah untuk menjadi
menentukan bagaimana data yang diperoleh dapat terwakili dalam model data dalam
target DBMS.
3) Design general constraints (Merancang kendala umum).
Update dari hubungan mungkin terbatas oleh kendala integritas, yang memimpin
“dunia nyata" transaksi diwakili oleh update. Kendala integritas terdiri dari data yang
diperlukan, domain kendala dan entitas dan integritas referensial. Tujuan dari fase ini
adalah untuk merancang kendala umum untuk DBMS target.
b. Design file organizations and indexes (Merancang indeks dan organisasi file)
Tujuannya adalah untuk menentukan organisasi file optimal untuk menyimpan
dan indeks hubungan-dasar Indeks diperlukan untuk mencapai kinerja yang dapat
46
diterima, yang mana, bagaimana hubungan dan tupel disimpan dalam penyimpanan
sekunder. Kegiatan pada tahap ini dibagi beberapa, yaitu:
1) Analyze transactions (Menganalisis transaksi).
Dalam rangka untuk merancang database fisik yang efektif, diperlukan
pengetahuan tentang transaksi atau query yang akan dijalankan dalam database.
Sekarang mencakup baik informasi kualitatif dan informasi kuantitatif. Menganalisis
kriteria transaksi kinerja adalah sebagai berikut:
• Transaksi yang berjalan dan akan memiliki signifikan berpengaruh pada
kinerja.
• Transaksi sangat penting untuk operasi bisnis.
• Beberapa kali, baik setiap hari atau setiap minggu, di mana akan ada
permintaan yang tinggi dihadapi oleh database.
2) Choose file organizations (Pilih organisasi file).
Salah satu tujuan utama dalam desain fisik database untuk menyimpan dan
mengakses data dengan cara yang efisien. Pemilihan organisasi file dapat dikategorikan
ke dalam jenis file:
• Heap
• Hash
• Indexed Sequential Access Metode (ISAM)
• B *-tree
• Cluster
Jika target tidak mengizinkan DMBS pemilihan organisasi file, maka langkah ini dapat
dihilangkan.
3) Choose indexes (Pilih indeks).
47
Salah satu pendekatan dalam memilih organisasi hak untuk mengajukan suatu
hubungan adalah menjaga unordered tupel dan membuat sebanyak mungkin Indeks
sekunder jika diperlukan. Pendekatan-pendekatan lain adalah untuk menentukan indeks
utama atau clustering.
4) Estimate disk space requirements (Memperkirakan kebutuhan ruang disk)
Ada suatu masa ketika konfigurasi hardware ke kondisi dalam pelaksanaan
database fisik. Meskipun itu bukan masalah utama, desainer tetap harus memperkirakan
jumlah ruang disk yang akan digunakan untuk menyimpan database, jika ada hardware
baru.
c. Design user views (Merancang tampilan untuk pengguna)
Tahap pertama dari metodologi desain database melibatkan produksi model data
yang baik konseptual untuk single-user pandangan atau beberapa kombinasi dari
pengguna pandangan yang diidentifikasi selama pengumpulan persyaratan dan tahap
analisis. Tujuan utama dari tahap ini adalah untuk merancang pandangan pengguna
diidentifikasi dalam tahap sebelumnya desain.
d. Design security machanisms (Merancang mekanisme keamanan).
Database adalah sumber daya penting untuk perusahaan sehingga keamanan
sangat penting. Tujuan tahap utama adalah untuk merancang mekanisme database
keamanan sebagaimana diatur oleh pengguna selama fase pengumpulan persyaratan
database sistem siklus hidup. DBMS menyediakan dua jenis keamanan keamanan
database dan sistem yang keamanan data. Sistem keamanan melindungi akses dan
penggunaan database pada tingkat sistem, seperti username dan sandi keamanan data.
dan melindungi akses penggunaan objek database, seperti hubungan dan pandangan, dan
48
pengguna tindakan yang dapat dilakukan pada objek mereka. Desain juga tergantung
pada izin dari target DBMS, beberapa sistem menyediakan fasilitas lebih dari orang lain
untuk izin desain.
e. Consider the introductions of controlled redundancy (Peninjauan kembali
dari redundansi yang sudah terkontrol).
Normalisasi adalah teknik untuk menentukan atribut yang sesuai dengan relasi.
Merancang database logis adalah hasil dari normalisasi yang konsisten terstruktur dan
memiliki redundansi minimal. Namun, terkadang menormalkan database tidak
menyediakan proses yang efisien dan maksimal. Secara formal, terkait denormalisasi
memperbaiki skema hubungan. Dalam beberapa kasus, denormalisasi khusus digunakan
untuk meningkatkan kecepatan kritis proses atau transaksi, khususnya dengan:
1) Menggabungkan relasi one-to-one
2) Menduplikasi atribut non-key dalam reasi one-to-many untuk mengurangi
joins
3) Menduplikasi atribut foreign-key dalam relasi many-to-many untuk
mengurangi joins
4) Menduplikasi atribut dalam hubungan many-to-many untuk mengurangi joins
5) Memperkenalkan repeating groups
6) Buat tabel extract
7) Partisi relasi
f. Monitor and tune the operational system (Memantau dan menyesuaikan
sistem operasional)
49
Tujuan utama dari tahap ini adalah untuk memonitor operasional sistem dan
meningkatkan kinerja sistem untuk memperbaiki desain yang tidak tepat keputusan atau
perubahan kebutuhan. Ada beberapa faktor yang digunakan untuk mengukur efisiensi:
1) Transaction Throughput
2) Response Time
3) Disk Storage
Untuk meningkatkan efisiensi basis data, beberapa DBMS menyediakan fasilitas
untuk Database Administrator (DBA) untuk tuning, berikut adalah beberapa keuntungan
dari tuning:
1) Tuning dapat menghindari penambahan hardware.
2) Dapat menurunkan konfigurasi hardware, sehingga lebih murah dan
menghindari pemeliharaan hardware.
3) Sebuah sistem-tuning sering menghasilkan lebih cepat response time dan
throughput yang lebih baik, membuat pengguna lebih produktif.
4) Meningkatkan response time membuat moral karyawan juga tinggi.
2.1.8. Normalisasi
Normalisasi sering dieksekusi sebagai langkah-langkah yang berangkai atau
berseri. Bentuk normal adalah aturan yang dikenakan pada relasi-relaso dalam basis data
dan harus dipenuhi oleh relasi-relasi tersebut pada tingkatan normalisasi. Suatu relasi
dikatakan dalam bentuk normal tertentu jika memenuhi kondisi-kondisi tertentu.
50
Tujuan normalisasi ialah untuk mengurangi terjadinya redundansi data dan
mengurangi masalah yang terjadi pada suatu relasi yang dikenal dengan anomaly.
Anomaly adalah suatu masalah yang timbul, seperti data ganda, data hilang,
tempat penyimpanan memory yang boros, dan data yang tidak konsisten akibat dari
proses penghapusan data, pembaruan data, pemasukkan data, dan penggantian data.
(Connoly & Begg, 2010, p.418)
Proses normalisasi yang biasa digunakan dalam normalisasi adalah:
1. UNF
Sebelum membahas bentuk normal pertama, kita mendefinisikan normal form
awal yaitu Unnormalized Form (UNF). UNF adalah tabel yang berisi satu atau lebih
kelompok data yang berulang.
2. Bentuk Normal Pertama (1NF)
Bentuk normal pertama adalah hubungan dimana persimpangan dari setiap baris
dan kolom berisi satu dan hanya satu nilai. Atau dengan kata lain, pada 1NF kita
menghilangkan pengulangan dan data yang merupakan hasil perhitungan.
3. Bentuk Normal Kedua (2NF)
Bentuk normal kedua didefinisikan oleh ketergantungan berfungsi penuh (Full
Functional Dependency). Full Functional Dependency menandai jika A dan B adalah
atribut dari sebuah relasi, B sepenuhnya fungsional tergantung pada A jika B secara
fungsional bergantung pada A, tetapi tidak pada semua himpunan subset dari A.
Sementara 2NF adalah sebuah relasi antara bentuk normal yang pertama, dan setiap
atribut bukam primery key adalah penuh secara fungsional bergantung pada primary
key. Atau dengan kata lain, pada 2NF kita menghilangkan ketergantungan parsial.
51
4. Bentuk Normal Ketiga (3NF)
Bentuk normal ketiga didefinisikan oleh ketergantungan transitif (Transitive
Dependency). Ketergantungan transitif adalah suatu kondisi di mana A, B, dan C
merupakan atribut relasi seperti jika A->B dan B->C, maka C secara transitif bergantung
pada A melalui B. (Dengan ketentuan bahwa A tidak secara fungsional tergantung pada
B atau C). Sementara 3NF adalah sebuah hubungan antara bentuk pertama dan bentuk
kedua, dan dimana tidak ada atribut yang berupa primary key secara transitif bergantung
pada primary key.
5. Boyce-Codd normal Form (BCNF)
Menurut Connolly dan Begg (2010, p447) suatu relasi disebut memenuhi bentuk
normal Boyce-Codd jika dan hanya jika semua determinan (penentu) adalah candidate
key. BCNF adalah bentuk normal sebagai perbaikan untuk 3NF karena bentuk ketiga
yang normal cenderung masih memiliki anomali sehingga perlu dinormalisasi lebih
lanjut. Sebuah relasi yang memenuhi BCNF selalu memenuhi 3NF, tetapi tidak untuk
sebaliknya. Bentuk pertama hingga bentuk ketiga adalah bentuk normal yang umum
digunakan. Ini berarti, bahwa dalam kebanyakan relasi ketika bentuk normal ketiga telah
dipenuhi maka persoalan anomali tidak akan muncul lagi. Bentuk normal Boyce-Codd
adalah revisi ke bentuk normal ketiga. Bentuk normal keempat (4NF) dan kelima (5NF)
hanya digunakan dalam kasus-kasus khusus, yakni pada relasi yang mengandung banyak
ketergantungan nilai.
2.2. Tools Yang Digunakan
2.2.1. Diagramming Tool
a. DFD
52
Data Flow Diagram merupakan suatu bentuk atau model yang memungkinkan
professional sistem untuk menggambarkan sistem sebagai suatu jaringan proses
fungsional atau sebagai jaringan proses dan fungsi yang dihubungkan satu sama lain
oleh suatu penghubung yang disebut alur data (Data Flow).
DFD tidak tergantung pada perangkat keras, perangkat lunak, struktur data dan
organisasi file, tetapi banyak digunakan oleh pengembang sistem karena kemudahannya
untuk dibuat dan dipahami, sehingga DFD sering digunakan sebagai alat penghubung
antara perancang dan pemakai. DFD ini sering disebut juga dengan nama Bubble Chart,
Bubble Diagram, Model Proses, Diagram Alur Kerja atau Model Fungsi.
Levelisasi DFD adalah sebagai berikut:
1. Diagram Konteks
Merupakan diagram tingkat atas yang terdiri dari proses dan menggambarkan
hubungan terminator dengan sistem yang mewakili suatu proses. Hubungan antar
Terminator dan Data Store tidak digambarkan.
2. Diagram Zero
Diagram ini merupakan diagram tingkat menengah yang menggambarkan proses
utama dari dalam sistem, yang terdiri dari hubungan entitas (entity), proses data flow dan
penyimpanan data (data store).
3. Diagram Detail atau Diagram Primitif
Diagram Primitif merupakan diagram paling bawah yang tidak dapat diuraikan
lagi, sedangkan Diagram Detail masih dapat diuraikan.
Komponen-komponen pada DFD
53
Ada terdapat 4 komponen dalam DFD, yaitu :
1. Terminator / Entitas Luar
Terminator mewakili entitas eksternal yang berkomunikasi
dengan system yang sedang dikembangkan. Terdapat dua
jenis terminator yaitu terminator sumber (source) dan
terminator tujuan (sink). Terminator dapat berupa orang, organisasi, departemen didalam
organisasi atau system lainnya yang berada di lingkungan luarnya yang akan
memberikan input atau menerima output dari sistem.
2. Proses
Suatu proses adalah kegiatan atau kerja
yang dilakukan oleh orang, mesin atau
komputer dari hasil suatu arus data yang
masuk ke dalam proses untuk dihasilkan
arus data yang akan keluar dari proses. Proses menggambarkan bagian dari system yang
mentransformalkan input menjadi output. Proses diberi nama untuk menjelaskan proses
atau kegiatan apa yang sedang atau akan dilaksanakan. Pemberian nama proses
dilakukan dengan menggunakan kata kerja yang membutuhkan objek.
3. Data Store
Data store digunakan untuk membuat model sekumpulan
paket data. Data store ini biasanya berkaitan dengan
penyimpanan-penyimpanan, seperti file atau database
yang berkaitan dengan penyimpanan secara
54
komputerisasi, misalnya file disket, file hardisk, fita meagnetik. Data store juga
berkaitan dengan penyimpanan secara manual seperti buku alamat, file folder dan
agenda, yang digambarkan dengan dua garis sejajar.
4. Alur Data
Alur data yang menghubungkan data store dengan suatu
proses mempunyai pengertian sebagai berikut:
a. Alur data yang berasal dari data store, berarti proses
membutuhkan data yang berada pada data store tersebut
b. Alur data yang menuju ke data store, berarti suatu proses akan menghasilkan output
atau keluaran yang disimpan pada data store tersebut.
c. Alur data yang berasal dan yang menuju ke data store berarti suatu proses akan
mengupdate data, menghapus atau mengubah data.
Suatu alur data digambarkan dengan anak panah, yang menunjukan arah menuju ke
dalam dan keluar dari suatu proses. Alur data ini digunakan untuk menerangkan
perpindahan data atau paket data / informasi dari satu bagian system ke bagian lainnya.
Tingkatan DFD
Tingkatan-tingkatan pada DFD adalah sebagai berikut:
a. Diagram konteks : Diagram ini adalah diagram level tertinggi dari DFD yang
menggambarkan hubungan system dengan lingkungannya.
55
b. Diagram level Zero : Diagram ini adalah dekomposisi dari diagram konteks.
Merupakan diagram yang menggambarkan proses-proses utama system dan alur
datanya.
c. Diagram level satu : Diagram ini merupakan dekomposisi dari diagram level zero.
d. DFD level dua,tiga : Diagram ini merupakan dekomposisi dari level sebelumnya.
e. Entity Relationship Diagram : Model Entity Relationship adalah suatu penyajian data
dengan menggunakan Entity dan Relationship.
b. Flowchart
Flowchart adalah penyajian yang sistematis tentang proses dan logika dari
kegiatan penanganan informasi atau 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.
System flowchart adalah urutan proses dalam system dengan menunjukkan alat
media input, output serta jenis media penyimpanan dalam proses pengolahan data.
Program flowchart adalah suatu bagan dengan simbol-simbol tertentu yang
menggambarkan urutan proses secara mendetail dan hubungan antara suatu proses
(instruksi) dengan proses lainnya dalam suatu program.
Simbol Flowchart
Dipakai sebagai alat bantu menggambarkan proses di dalam program. Dibagi
menjadi tiga kelompok :
• Flow Direction Symbols (Simbol penghubung alur)
• Processing Symbols (Simbol proses).
56
• Input-output Symbols (Simbol input-output)
Simbol-simbol ini dapat dilihat pada gambar simbol flowchart standar berikut ini:
57
Tidak ada kaidah yang baku mengenai pedoman dalam membuat flowchart. Flowchart
sama dengan gambaran hasil analisa suatu masalah. Flowchart dapat bervariasi antara
satu pemrogram dengan pemrogram lainnya.
Secara garis besar ada 3 bagian utama:
– Input
– Proses
– Output
Bila seorang analis dan programmer akan membuat flowchart, ada beberapa petunjuk
yang harus diperhatikan, seperti:
1. Flowchart digambarkan dari halaman atas ke bawah dan dari kiri kekanan.
58
2. Aktivitas yang digambarkan harus didefinisikan secara hati-hati dan definisi
ini harus dapat dimengerti oleh pembacanya.
3. Kapan aktivitas dimulai dan berakhir harus ditentukan secara jelas.
4. Setiap langkah dari aktivitas harus diuraikan dengan menggunakan deskripsi
kata kerja
5. Setiap langkah dari aktivitas harus berada pada urutan yang benar.
6. Lingkup dan range dari aktifitas yang sedang digambarkan harusditelusuri
dengan hati-hati. Percabangan-percabangan yang memotong aktivitas yang sedang
digambarkan tidak perlu digambarkan pada flowchart yang sama. Simbol konektor harus
digunakan dan percabangannya diletakan pada halaman yang terpisah atau hilangkan
seluruhnya bila percabangannya tidak berkaitan dengan sistem.
7. Gunakan simbol-simbol flowchart yang standar.
c. State Transition Diagram (STD)
State Transition Diagram (STD) adalah gambaran simbol-simbol yang telah
standar. Pada diagram ini, menggambarkan perubahan setiap kondisi atas peubahan
setiap state dari setiap aksi yangdilakukan oleh user. STD digunakn untuk menuliskan
urutan dan penggantian dari layar yang dapatterjadi ketika user berada pada
terminal.Pada bagian ini akan digambarkan STD dari menu user yang dimulai dari std
menu utama user secara keseluruhan dan bagian-bagian dari setiap menu user secara
rinci.
Ada dua macam simbol yang menggambarkan proses dalam State Transition
Diagram, yaitu:
1. Gambar persegi panjang menunjukkan state dari sistem.
59
2. Gambar panah 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 dari kejadian tadi.
Contoh STD:
d. ERD
60
2.2.2. Software Tools
2.2.2.1. PHP
PHP merupakan singkatan rekursif (akronim berulang) dari PHP Hypertext
Preprocessor. PHP adalah bahasa pemrograman script yang paling banyak dipakai saat
ini atau dalam kata lain bisa diartikan sebuah bahasa pemrograman web yang bekerja di
sisi server (server side scripting) yang dapat melakukan konektifitas pada database yang
di mana hal itu tidak dapat dilakukan hanya dengan menggunakan sintaks-
sintaks HTML biasa. PHP banyak dipakai untuk memrogram situs web dinamis,
walaupun tidak tertutup kemungkinan digunakan untuk pemakaian lain.
Kelebihan PHP dari bahasa pemrograman lain:
Bahasa pemrograman PHP adalah sebuah bahasa script yang tidak melakukan
sebuah kompilasi dalam penggunaanya.
Web Server yang mendukung PHP dapat ditemukan dimana - mana dari
mulaiapache, IIS, Lighttpd, nginx, hingga Xitami dengan konfigurasi yang relatif
mudah.
Dalam sisi pengembangan lebih mudah, karena banyaknya milis - milis
dandeveloper yang siap membantu dalam pengembangan.
Dalam sisi pemahamanan, PHP adalah bahasa scripting yang paling mudah
karena memiliki referensi yang banyak.
PHP adalah bahasa open source yang dapat digunakan di berbagai mesin
(Linux,Unix, Macintosh, Windows) dan dapat dijalankan secara runtime melalui console
serta juga dapat menjalankan perintah-perintah system.
61
2.2.2.2. OLAP Tools
1. SQL Server 2.9
SQL Server adalah sistem manajemen database relasional yang akrab dengan
RDBMS (Relational Database Management System). SQL Server kelompok Klien harus
menangani hubungan dengan Server dalam bentuk pengolahan database relasional
dengan menggunakan Transact-SQL (T-SQL) sebagai bahasa untuk mengirim
permintaan / perintah antara Client dan Server. Server adalah obyek yang fungsinya
adalah untuk memberikan Layanan data yang ada, seperti: analisis, pencarian, dan
update data. Klien merupakan bentuk objek dalam bentuk program yang memiliki User
Interface untuk berkomunikasi atau mengakses data dari server.
Untuk mengakses Database Server SQL Server yang berfungsi sebagai maka ada 4
metode akses yangumum digunakan, yaitu:
ADO (ActiveX Data Objects)
ODBC (Open Database Connectivity)
OLEDB (Object Linking dan Embedding Database)
JDBC (Java Database Connectivity)
2. MySQL
MySQL adalah sebuah open-source bahasa pemrograman yang paling populer
dan banyak digunakan di lingkungan Linux. Popularitas ini karena didukung oleh
kinerja query database-nya yang jarang bermasalah.
MySQL (Struktur Query Language saya) adalah sebuah program televisi
database yang bersifat open source, yang berarti siapapun dapat menggunakannya
secara bebas. MySQL sebenarnya produk yang berjalan pada platform Linux.
Karena open source, MySQL dapat dijalankan pada semua platform baik Windows
62
atau Linux. Selain itu, MySQL juga merupakan program Jaringan akses adalah
database yang dapat digunakan untuk aplikasi multiuser (banyak pengguna). Saat
ini database MySQL telah digunakan oleh hampir semua programmer database,
terutama dalam pemrograman web. Keuntungan lain adalah penggunaan bahasa
query MySQL dimiliki SQL (Structured Query Language). SQL adalah bahasa
permintaan database diakses terstruktur dan standar untuk semua program seperti
Oracle, posgresql, SQL Server, dan lain-lain. Sebagai produsen sebuah program
database, MySQL tidak dapat berjalan sendiri tanpa adanya sebuah aplikasi lain
(interface). MySQL dapat didukung oleh hampir semua program aplikasi baik
sumber yangopen seperti PHP atau yang tidak, yang pada platform Windows
seperti Visual Basic, Delphi, dan banyak lagi.
2.3. Pemahaman Objek Studi
2.3.1. Prosedur Servis di Bengkel
Prosedur di dalam sistem yang sedang berjalan terdiri dari beberapa bagian
dalam pelayanan customer yang saling berkaitan, diantaranya adalah:
1. Pendaftaran booking service dibuat untuk melakukan pendataan pelangan yang
akan melakukan service di bengkel.
2. Permintaan estimasi biaya dan waktu service oleh pelanggan.
3. Pengaturan jadwal service mobil, membuat janji kedatangan ke bengkel.
4. Pelanggan datang ke bengkel dan melakukan service.
2.3.2. Prosedur Penjualan
63
Prosedur penjualan (service dan spare parts) di dalam sistem yang
sedang berjalan terdiri dari beberapa bagian dalam pelayanan customer yang
saling berkaitan, diantaranya adalah:
1. Setelah service selesai, montir akan memberitahukan detail mengenai
service ke customer service bengkel.
2. Customer service akan mencatat dan menghitung biayanya berdasarkan
masing-masing customer.
3. Customer service akan memberitahu biaya yang sudah dihitung tadi ke
customer yang bersangkutan.
4. Customer membayar biaya bengkel sesuai dengan jumlahnya.
64