BAB 2
LANDASAN TEORI
2.1. Teori-Teori Dasar 2.1.1 Pengertian Data
Menurut McFadden, Prescott, dan Hoffer (2002, p5), data adalah fakta yang telah diketahui, yang dapat dikumpulkan dan disimpan dalam media komputer.
2.1.2 Pengertian Sistem
Menurut McLeod dan Schell (2001, p9), sistem adalah sekelompok elemen-elemen yang terintegrasi dengan maksud yang sama untuk mencapai suatu tujuan.
Elemen-elemen sistem :
Gambar 2.1 Elemen – Elemen Sistem (Sumber McLeod, 2001, p9)
Menurut pendapat O’Brien (2002, p4) sistem secara sederhana dapat diartikan sebagai sebuah kumpulan dari elemen-elemen yang saling berhubungan atau berinteraksi yang membentuk suatu kesatuan.
Tujuan
Mekanisme Pengendalian
Sistem adalah kumpulan dari komponen yang terorganisasi, yang digunakan untuk menyelesaikan satu atau beberapa fungsi dan tugas spesifikasi tertentu. (Sumber : www.ichnet.org).
Menurut pendapat Mannino (2001, p192), sistem adalah kumpulan dari komponen-komponen yang berhubungan dan bekerja bersama-sama untuk menghasilkan suatu tujuan tertentu. Tujuan tersebut dicapai dengan interaksi dengan lingkungan dan fungsi tertentu.
2.1.3 Pengertian Basisdata
Menurut pendapat Post (2005, p2), basisdata adalah sebuah kumpulan dari data yang disimpan dalam suatu format yang sudah distandarisasi, yang didesain agar dapat digunakan oleh banyak pengguna (multi user).
Menurut pendapat McFadden, Prescott, dan Hoffer (2002, p27), basisdata adalah sebuah kumpulan terorganisir dari data-data berhubungan secara logika, yang biasanya dirancang untuk memenuhi kebutuhan – kebutuhan informasi dari banyak pengguna (multi user) dalam sebuah organisasi.
Menurut pendapat Ramakrishnan dan Gehrke (2003, p4), basisdata adalah kumpulan data yang biasanya menggambarkan aktifitas dari satu atau lebih organisasi yang berhubungan.
2.1.4 Karakteristik Basisdata
Menurut Mannino (2001, pp4-5), basisdata mempunyai beberapa karakteristik yaitu:
• Persisten
Data berada dalam salah satu bagian dari tempat penyimpanan yang stabil, misalnya magnetic disk, sebagai contoh sebuah organisasi memerlukan data tentang konsumen, supplier dan inventori dalam suatu penyimpanan yang stabil karena data-data ini sering digunakan berulang-ulang.
Sebuah variabel dalam program komputer tidak akan ada terus menerus (persistent) karena berada dalam memori utama dan akan hilang setelah program dimatikan. Persistent tidak berarti bahwa data akan ada selamanya, ketika data tidak diperlukan atau tidak relevan lagi maka data dapat dihilangkan atau tetap disimpan.
• Shared
Basis data dapat digunakan oleh banyak pengguna (multi
user). Sebuah basisdata menyediakan memori yang umum untuk
banyak fungsi dalam organisasi. Misalnya, basisdata dapat mendukung perhitungan gaji, evaluasi kinerja, menyediakan laporan-laporan dan sebagainya.
• Interrelated
Data yang disimpan dalam unit-unit yang terpisah dapat dihubungkan untuk mendapatkan suatu gambaran secara keseluruhan. Misalnya basisdata konsumen menghubungkan dengan data order untuk memfasilitasi proses order (pemesanan).
2.1.5 Kelebihan dan Kekurangan Basisdata
Menurut McFadden, Prescott, dan Hoffer (2002, pp23-25), Basisdata mempunyai beberapa keuntungan antara lain :
• Program Data Independence
Dengan adanya basisdata, maka deskripsi data disimpan dalam lokasi pusat yang disebut repository. Properti sistem basisdata ini memungkinkan data organisasi untuk diubah dan dikembangkan tanpa mengubah aplikasi program yang memproses data.
• Minimal Data Redudancy
Tujuan dari basisdata adalah mengintegrasikan data yang dulunya tersebar menjadi satu struktur logikal. Basisdata tidak menghilangkan semua redudansi tetapi membantu desainer untuk mengontrol tipe dan jumlah redudansi itu secara hati-hati.
• Improved Data Consistency
Dengan mengontrol atau menghilangkan redudansi data, maka akan mengurangi kemungkinan inconsistency data
(meningkatkan konsistensi antar data). Misalnya jika alamat konsumen hanya disimpan dalam satu tempat maka alamat tersebut tidak dapat diragukan lagi kebenarannya.
• Improved Data Sharing
Sebuah basisdata didesain untuk digunakan sebagai sumber informasi perusahaan yang dapat digunakan oleh semua orang. User terotorisasi internal maupun eksternal dapat menggunakan basisdata ini tetapi dengan kemampuan yang berbeda dalam menggunakan fasilitas basis data ini.
• Increased Productivity of Application Development
Keuntungan utama dari basisdata adalah dapat mengurangi waktu dan biaya untuk pengembangan aplikasi bisnis baru.
• Enforcement of Standards
Ketika basisdata diimplementasikan dengan dukungan penuh dari manajemen maka administrator basisdata seharusnya akan berfungsi sebagai orang yang bertanggung jawab untuk menghasilkan suatu standarisasi data untuk organisasi.
• Improved Data Quality
Dengan adanya database maka dapat diberikan batasan-batasan (integrity constraints) sehingga kualitas data dapat terjamin.
• Improved Data Accessibility and Responsiveness
Dengan relational database, end users yang tidak mempunyai kemampuan ataupun pengalaman programming bisa mendapatkan dan menampilkan data bahkan melewati batasan departemen.
• Reduced Program Maintenance
Untuk mengurangi kegiatan maintenance program maka data yang disimpan harus dapat sering diubah untuk beberapa alasan, misalnya adanya tambahan data yang baru, format data berubah dan sebagainya.
Selain itu penggunaan basisdata menurut McFadden, Prescott, dan Hoffer (2002, pp25-26), juga mempunyai resiko dan biaya antara lain : a. New, Spacialized Personnel
Sering kali, organisasi yang menggunakan basisdata perlu untuk mempekerjakan atau melatih orang mendesain dan mengimplementasikan basisdata, menyediakan service basisdata, dan mengatur staf yang terdiri dari orang-orang baru.
b. Installation and Management Cost and Complexity
Multiuser database management system adalah software
yang sangat kompleks dan mempunyai harga initial yang tinggi, memerlukan staf yang terlatih untuk meng-install, mengoperasikan serta setiap tahun memerlukan pemeliharaan dan biaya pendukung. Meng-install suatu sistem juga mungkin
memerlukan hardware yang lebih baik dan sistem komunikasi dalam organisasi.
c. Conversion Cost
Biaya juga diperlukan untuk mengkonversi sistem lama menjadi sistem basis data yang modern, yang dapat diukur dengan uang dan waktu.
d. Need for Explicit Backup and Recovery
Sebuah basisdata yang digunakan secara bersama-sama haruslah akurat dan dapat diguakan setiap saat. Hal ini mengharuskan prosedur-prosedur seperti itu dikembangkan dan digunakan untuk menyediakan backup dari data, untuk memulihkan basisdata bila terjadi kerusakan.
e. Organizational Conflict
Penggunaan basisdata secara bersama-sama dalam suatu perusahaan memerlukan kesepakatan dalam hal definisi data dan kepemilikan data, seperti halnya juga pertanggungjawaban terhadap keakuratan dalam pemeliharaan data. Pengalaman telah membuktikan bahwa konflik yang terjadi pada definisi data, format data, pemograman data (coding), dan kemampuan untuk meng-update data yang digunakan telah menjadi masalah yang sering dan sulit untuk diselesaikan. Untuk menangani masalah ini memerlukan komitmen organisasi dalam basisdata.
2.1.6 Komponen Lingkungan Basisdata
Menurut McFadden, Prescott, dan Hoffer, Jeffrey A. (2002, pp27-28), ada beberapa komponen dalam lingkungan basisdata yaitu :
• Computer-Aided Software Engeneering (CASE) tools
CASE tools merupakan tools automata yang digunakan untuk mendesain basisdata dan program aplikasi.
• Repository
Pusat penyimpanan definisi-definisi data, relasi antar data, format layar dan laporan.
• Database Management System (DBMS)
Perangkat lunak yang digunakan untuk mendefinisikan, membuat, memelihara dan menyediakan akses terkontrol terhadap basisdata dan juga repository.
• Basisdata
Suatu kelompok yang terorganisir dari data-data yang berhubungan, biasanya didesain untuk memenuhi kebutuhan informasi multiple user dalam organisasi.
• Program Aplikasi
Program komputer yang digunakan untuk membuat dan memelihara basisdata serta menyediakan informasi kepada user. • User Interface
Bahasa, menu, dan fasilitas lainnya yang membuat user dapat berinteraksi dengan beragam komponen sistem.
• Administrator Data
Orang-orang yang bertanggungjawab atas seluruh sumber informasi yang ada di organisasi
• System Developer
Orang-orang seperti sistem analis dan programmer yang mendesain program aplikasi baru.
• End Users
Orang-orang yang berada pada organisasi yang menambah, mengurangi serta mengubah data dalam basisdata dan orang yang meminta atau menerima informasi dari basisdata.
2.1.7 Sistem Manajamen Basisdata
Menurut pendapat Post (2005, p2), sistem manajemen basisdata adalah piranti lunak (software) yang mampu mendefinisikan sebuah basisdata, menyimpan data, mendukung bahasa query, menghasilkan laporan (reports) dan membuat layar input data.
Menurut Ramakrishnan (2003, p4), sistem manajemen basisdata adalah suatu perangkat lunak yang didesain untuk mendukung dalam memelihara dan menggunakan koleksi data yang besar.
Sebuah DBMS terdiri dari sebuah kumpulan dari data-data yang saling berhubungan dan kumpulan program-program untuk mengakses data tersebut (Silberschatz, et.al, 2002, p21).
Menurut Connolly (2002, p16), secara khusus DBMS menyediakan fasilitas-fasilitas berikut :
• Mengizinkan pengguna untuk menentukan basisdata, biasanya melalui Data Definition Language (DDL). DDL menyediakan fasilitas untuk menspesifikasi tipe data, struktur, dan batasan data yang bisa disimpan di basis data
• Mengizinkan pengguna untuk memasukkan, meng-update, menghapus dan mengambil data dari basisdata, yang dilakukan melalui Data Manipulation Language (DML).
• DBMS juga menyediakan akses control terhadap basisdata. Contoh akses control yang tersedia di DBMS :
a. Sistem Sekuriti, yang dapat mencegah pengguna yang tidak terautorisasi mengakses basisdata
b. Integrity System, menangani konsistensi penyimpanan
data.
c. Concurrency and Control System, yang memungkinkan
pembagian akses pengguna ke basisdata
d. Recovery Control System, yang dapat mengembalikan
basisdata ke keadaan konsisten awal apabila terjadi kesalahan kepada perangkat lunak maupun perangkat keras
e. User Accessible Catalog, yang berisi deskripsi data yang
2.1.8 Komponen dalam Ruang Lingkup Database Management System (DBMS)
Menurut Connolly dan Begg (2002, p18), ada lima komponen utama dalam ruang lingkup DBMS : perangkat keras, perangkat lunak, data, prosedur, dan orang.
• Hardware (perangkat keras)
Perangkat keras dibutuhkan untuk menjalankan DBMS. Perangkat keras dapat menjangkau dari mulai single personal computer,
single mainframe sampai komputer yang terhubung kepada
jaringan.
• Software (perangkat lunak)
Komponen perangkat lunak terdiri dari perangkat lunak DBMS itu sendiri dan program-program aplikasi, bersama dengan sistem operasi, termasuk perangkat lunak jaringan jika DBMS tersebut menggunakan jaringan.
• Data
Data mungkin merupakan komponen terpenting dalam ruang lingkup DBMS, terutama dari sudut pandang end-users.
• Prosedur
Prosedur dapat dimaksudkan sebagai instruksi-instruksi dan aturan-aturan yang mengatur desain dan penggunaan basisdata. Ini dapat terdiri dari instruksi tentang bagaimana untuk:
penggunaan sebagian fasilitas DBMS atau program aplikasi;
memulai dan menghentikan DBMS; membuat backup dari basisdata;
menangani kegagalan perangkat keras atau perangkat lunak;
mengubah struktur dari sebuah tabel, mengatur kembali basisdata dalam multiple disk, meningkatkan performa, atau membuat arsip data pada penyimpanan sekunder. • Orang
Komponen terakhir dari DBMS adalah orang yang terlibat dengan sistem.
2.1.9 Data Definition Language (DDL)
Menurut Connolly dan Begg (2002, p40), DDL adalah bahasa yang memungkinkan seorang administrator basisdata atau user untuk mendeskripsikan dan menentukan entiti, atribut dan relasi yang dibutuhkan aplikasi, bersama dengan batasan-batasan integritas dan keamanan (integrity and security constraints). Hasil dari kompilasi
statement DDL adalah kumpulan dari tabel yang disimpan di file khusus
yang disebut sistem katalog. Sementara istilah data dictionary dan data
directory digunakan untuk mendeskripsikan sistem katalog.
Menurut Brown (2001, p64), DDL adalah sekumpulan perintah yang akan digunakan untuk mendefinisikan atau memodifikasi struktur
dari fitur skema yang ada, seperti tabel, view, fungsi, prosedur, tipe data dan sebagainya. Prinsip dasar pernyataan DDL adalah create, alter and
drop.
Menurut Post (2005, p146), sekumpulan perintah yang digunakan untuk mendefinisikan data tabel dan fitur-fitur lain dalam basisdata.
2.1.10 Data Manipulation Language (DML)
Menurut Brown (2001, p64), DML adalah sekumpulan perintah yang digunakan untuk membaca dan memodifikasi suatu nilai data yang akan diakses melalui basisdata. Empat operasi utama dari DML adalah
select, insert, update dan delete. Menurut Connolly dan Begg (2002,
p41), DML adalah bahasa yang menyediakan sekumpulan operasi untuk mendukung operasi manipulasi data yang tersimpan pada basisdata.
Secara umum operasi DML mencakup : • Pemasukan data baru ke dalam basisdata
• Pemodifikasian data yang terdapat dalam basisdata • Pengambilan data yang terdapat dalam basisdata • Penghapusan data yang terdapat dalam basisdata
Menurut Post (2005, p146), DML adalah sekumpulan perintah untuk memodifikasikan data.
2.1.11 Entity Relationship Modelling (ER Modelling)
Menurut Silberschatz, et.al (2002, p8), Entity Relationship Data
Model didasarkan pada persepsi terhadap dunia nyata yang terdiri dari
kumpulan objek dasar, yang disebut entities, dan hubungan (relationship) antara objek-objek ini. Sebuah entiti adalah sebuah benda atau objek di dunia nyata yang dapat dibedakan dari objek-objek lainnya. Contohnya setiap pelanggan adalah sebuah entiti.
ER Modelling adalah pendekatan top-down dalam perancangan
basisdata yang dimulai dengan mengidentifikasi data-data penting yang disebut entities dan hubungan (relationship) antara data-data tersebut harus direpresentasikan dalam model. (Connolly and Begg, 2002, p330).
Berikut ini dijelaskan konsep dasar dari ER Modelling sebagai berikut :
a. Tipe Entiti
Tipe entiti merepresentasikan kumpulan dari objek yang ada pada dunia nyata dengan properti yang sama. Sebuah tipe entiti ada secara independen dan bisa berbentuk objek dengan keberadaan fisik atau nyata ataupun objek yang tidak nyata atau abstrak.
Gambar 2.2 Contoh tipe Entiti (Sumber Connolly dan Begg, 2002, p333)
b. Tipe Relasi
Tipe relasi adalah kumpulan hubungan yang mempunyai arti antara tipe-tipe entiti. Setiap tipe relasi akan diberikan nama yang menggambarkan fungsinya, misalnya tipe relasi yang dinamakan Powns, yaitu relasi yang menghubungkan entiti PrivateOwner dan PropertiForRent.
Degree of relationship type
Menyatakan jumlah entiti yang berpartisipasi dalam relasi. Entiti dengan degree dua dinamakan binary, sedangkan entiti dengan degree tiga disebut ternary, entiti dengan
degree empat dinamakan quarternary. Suatu relasi dapat
disebut relasi yang kompleks bila relasi tersebut mempunyai degree yang lebih tinggi dari binary
Gambar 2.3 Contoh Binary Relationship (Sumber : Connolly dan Begg, 2002, p335)
Gambar 2.4 Contoh Ternary Relationship (Sumber : Connolly dan Begg, 2002, p336)
Solicitor
Financial Institution
Client Buyer Arrange
'Seorang pencari langganan (soliciator) menyusun (arrange) tawaran (bid) pada kepentingan dari seorang pembeli (buyer) yang didukung oleh lembaga keuangan (financial institution)'
Gambar 2.5 Contoh Quarternary Relationship (Sumber : Connolly dan Begg, 2002, p337)
Relasi rekursif
Merupakan tipe relasi dimana tipe entiti yang sama berpartisipasi lebih dari satu kali dalam peranan yanng berbeda
c. Atribut
Merupakan sifat dari sebuah entiti atau tipe relasi, misalnya entiti staf bisa digambarkan dengan atribut staffNo, nama, jabatan dan gaji. Atribut ini mempunyai nilai yang menggambarkan setiap entiti dan merepresentasikan bagian utama dari data yang akan disimpan dalam basisdata.
Domain Atribut
Merupakan kumpulan dari nilai-nilai yang diperbolehkan untuk satu atau lebih atribut, misalnya untuk atribut noKamar harus diisi dengan nilai antara 1 sampai 15.
Simple dan Composite Attributes
• Simple Attribute adalah atribut yang tersusun dari
sebuah komponen yang ada secara independen.
Simple Attribute tidak dapat dipecah lagi menjadi
atribut yang lebih kecil, biasanya disebut dengan
atomic atribut, contohnya adalah jabatan, gaji pada
entiti staff.
• Composite Attribute adalah atribut yang tersusun dari
banyak komponen, setiap komponen itu ada secara independen. Composite attribute dapat dipecah lagi menjadi komponen-komponen independen yang lebih kecil, misalnya entiti cabang dengan nilai (163 Main St, Glasgow, G119QX) dapat dipecah menjadi atribut jalan (163 Main St), kota (Glasgow), kodePos (G119QX).
Single-Value dan Multi-Value Attributes
• Single-valued attribute adalah atribut yang hanya
mempunyai sebuah nilai untuk setiap tipe entiti. Hampir sebagian besar atribut adalah single-value, misalnya pada entiti cabang mempunyai noCabang (B003), noCabang ini adalah atribut single-value. • Multi-valued attribute merupakan atribut yang
pada noCabang B003 mempunyai noTelp 0141-339-2178 dan 0141-339-4439.
Derived Attributes
Derived attributes merupakan sebuah atribut yang
merepresentasikan sebuah nilai yang berasal dari nilai sebuah atribut yang berhubungan atau set atribut, dan tidak harus berada dalam tipe entiti yang sama.
Keys
• Candidate key merupakan kumpulan minimal dari
atribut yang secara unik mengidentifikasikan tipe entiti tertentu.
• Primary key adalah candidate key yang dipilih untuk
secara unik mengidentifikasikan suatu tipe entiti.
Candidate key lainnya yang tidak dipilih menjadi primary key disebut dengan alternate key.
• Composite key adalah candidate key yang terdiri dari
dua atau lebih atribut. d. Strong and Weak Entity Types
• Strong Entity adalah entiti yang keberadaannya tidak tergantung dengan entiti lain, misalnya entiti staff dan cabang. Karakteristik dari strong entity adalah setiap entiti dapat diidentifikasikan dengan primary key dari tipe entiti itu.
• Weak entity adalah entiti yang keberadaannya tergantung dari entiti lain. Karakteristik dari weak entity adalah atribut yang terdapat pada entiti tersebut tidak dapat mengidentifikasikan tipe entiti itu secara unik.
e. Structural Constraints
Multiplicity merupakan jumlah kemunculan (occurence)
yang mungkin dari sebuah tipe entiti yang berhubungan dengan kemunculan tunggal dari sebuah tipe entiti yang berhubungan dalam relasi tertentu (Connoly and Begg, 2002, p344).
Contohnya beberapa batasan-batasan (constraints) termasuk syarat bahwa sebuah properti sewa harus mempunyai seorang pemilik dan setiap cabang harus memiliki staf. Tipe utama dari batasan-batasan dalam relasi ini disebut multiplicity.
Tingkat relasi yang umum antar entiti adalah binary. Berikut ini adalah relasi binary yang sering terjadi :
1. Relasi One-to-One (1:1)
Relasi dimana setiap entiti yang ada hanya dapat mempunyai maksimal satu relasi dengan entiti yang lain.
Staf Mengatur Cabang (Entiti) (Tipe relasi) (Entiti)
Gambar 2.6 Relasi one-to-one antara cabang dan staf (Sumber Connolly dan Begg, 2002, p345)
SG5 SG37 SL21 R1 R2 B003 B005
R1 R2 R3 R1 R2 R3 R4 2. Relasi One-to-Many (1:*)
Relasi dimana setiap entiti yang ada dapat mempunyai satu relasi atau lebih dari satu relasi dengan entiti yang lain.
Staf melayani konsumen (Entiti) (tipe relasi) (Entiti) Gambar 2.7 Relasi one-to-many antara staf dan konsumen
(Sumber Connolly dan Begg, 2002, p346)
Pada gambar diatas relasi yang terjadi adalah relasi one-to-many dimana setiap staff dapat melayani lebih dari satu konsumen.
3. Relasi Many-to-Many (*:*)
Relasi dimana setiap entiti dapat mempunyai lebih dari satu relasi dengan entiti lainnya.
Dosen mengajar Mahasiswa (Entiti) (tipe relasi) (Entiti) Gambar 2.8 Relasi many-to-many antara dosen dan
mahasiswa
(Sumber Connolly dan Begg, 2002, p348) SG5 SG37 SA9 PG21 PG36 PA14 PG4 A B C D E F
Pada gambar diatas relasi yang terjadi adalah relasi many-to-many dimana setiap dosen mengajar lebih dari satu mahasiswa.
Cardinality dan Participation Constraints
Multiplicity terdiri dari dua batasan yaitu cardinality dan participation. Cardinality menggambarkan jumlah maksimum
relasi yang mungkin terjadi dari sebuah entiti yang berpartisipasi dalam tipe relasi. One-to-one (1:1), one-to-many(1:*), many-to-many (*:*) merupakan cardinality dari relasi binary. Participation menentukan apakah semua atau hanya sebagian dari entiti yang berpartisipasi dalam relasi.
Gambar 2.9 Cardinality dan Participation antara Cabang dan Staf
(Sumber Connolly dan Begg, 2002, p351) Satu cabang
diatur oleh satu anggota dari staf
Satu cabang diatur oleh satu anggota dari staf
Semua cabang diatur
Tidak semua staf mengatur cabang Staf Cabang noStaf noCabang 1..1 0..1 participation Cardinality
f. Permasalahan dengan model ER
Dalam membangun ER model, terdapat beberapa masalah yang mungkin muncul yang biasanya disebut connection traps karena kesalahan interpretasi dari makna relasi tertentu.
Dua tipe connection traps adalah : • Fan Traps
Fan Traps terjadi ketika sebuah model merepresentasikan
relasi diantara entiti tapi alur antara entiti tersebut tidak jelas (ambigu).
• Chasm Traps
Chasm traps terjadi ketika sebuah model menyatakan
keberadaan relasi antar entiti, tetapi alur antara entiti tesebut tidak ada.
2.1.12 Normalisasi
Menurut Connolly dan Begg (2002, p376), normalisasi adalah teknik untuk menghasilkan sekumpulan relasi dengan properti yang diinginkan, dengan kebutuhan data yang diberikan oleh perusahaan.
Proses normalisasi itu sendiri adalah sebagai berikut : a. First Normal Form (1NF)
Suatu kondisi sebelum masuk ke proses normalisasi adalah
Un-normalized Form (UNF), yaitu kondisi dimana dalam sebuah
clientNo cName propertyNo pAddress rentStart rentFinish rent ownerNo oName Kelompok berulang PG4 John Kay 6 Lawrence St, Glasgow 1-jul-00 31-Aug-01 350 CR76 C040 Tina Murphy PG16 5 Novar Dr, Glasgow
1-Sep-01 1-Sep-02 450 C093 Tony Shaw
CR56 Aline Stewart
PG4 6 Lawrence St, Glasgow
1-Sep-99 10-June-00 350 C040 Tina Murphy
PG36 2 Manor Rd, Glasgow
10-Oct-00 1-Dec-01 375 C093 Tony Shaw PG16 5 Novar Dr,
Glasgow
1-nov-02 10-Aug-03 450 C093 Tony Shaw ClientRental clientNo cName John Kay CR76 CR56 Aline Stewart Client
Berikut merupakan contoh tabel yang masih mengandung
repeating group :
Gambar 2.10. Un-normalized Form (UNF) (Sumber Connolly dan Begg, 2002, p389)
Sedangkan 1NF adalah relasi dimana gabungan dari tiap kolom dan baris mengandung satu dan hanya satu nilai. Pada 1NF,
repeating group dihilangkan dengan menempatkan data berulang
dengan sebuah copy dari original key attribute (dalam hal ini, clientNo) pada tabel terpisah, seperti yang terlihat pada gambar berikut :
propertyNo pAddress rentStart rentFinish rent ownerNo oName PG4 6 Lawrence
St, Glasgow
1-jul-00 31-Aug-01 350 C040 Tina Murphy PG16 5 Novar Dr,
Glasgow
1-Sep-01 1-Sep-02 450 C093 Tony Shaw PG4 6 Lawrence
St, Glasgow
1-Sep-99 10-June-00 350 C040 Tina Murphy PG36 2 Manor Rd,
Glasgow
10-Oct-00 1-Dec-01 375 C093 Tony Shaw 5 Novar Dr,
Glasgow
1-nov-02 10-Aug-03 450 C093 Tony Shaw PG16 PropertyRentalOwner clientNo CR76 CR56 CR56 CR56 CR76 clientNo cName John Kay CR76 CR56 Aline Stewart Client
Gambar 2.11. 1st-normalized Form (1NF) (Sumber Connolly dan Begg, 2002, p391) b. Second Normal Form (2NF)
Yaitu relasi yang terdapat di dalam 1NF dan tiap atribut
non-primary key bersifat bergantung fungsional penuh terhadap non-primary key. Pada normalisasi dari 1NF menjadi 2NF, jika terdapat
ketergantungan parsial, maka atribut-atribut yang bergantung fungsional dari relasi dipindahkan dengan menempatkannya pada sebuah relasi baru dengan meng-copy determinannya. Dengan demikian diperoleh tabel-tabel baru sebagai berikut :
clientNo propertyNo rentStart rentFinish PG4 1-jul-00 31-Aug-01 CR76 PG16 1-Sep-01 1-Sep-02 CR76 CR56 PG4 1-Sep-99 10-June-00 CR56 PG36 CR56 10-Oct-00 1-Dec-01 1-Nov-02 10-Aug-03 PG16
propertyNo pAddress rent ownerNo oName PG4 6 Lawrence St, Glasgow 350 C040 Tina Murphy PG16 5 Novar Dr, Glasgow 450 C093 Tony Shaw PG4 6 Lawrence St, Glasgow 350 C040 Tina Murphy PG36 2 Manor Rd, Glasgow 375 C093 Tony Shaw 5 Novar Dr, Glasgow 450 C093 Tony Shaw PG16 Rental PropertyOwner
Gambar 2.12. 2nd-normalized Form (2NF) (Sumber Connolly dan Begg, 2002, p393) c. Third Normal Form (3NF)
Yaitu relasi yang terdapat pada 1NF dan 2NF, dimana tidak ada atribut non-primary key yang bergantung transitif terhadap
primary key. Pada tahap ini, setiap ketergantungan transitif
dipisahkan dari tabelnya. Dengan demikian, berdasarkan contoh diatas, diperoleh tabel baru sebagai berikut :
clientNo cName John Kay CR76
CR56 Aline Stewart
clientNo propertyNo rentStart rentFinish PG4 1-jul-00 31-Aug-01 CR76 PG16 1-Sep-01 1-Sep-02 CR76 CR56 PG4 1-Sep-99 10-June-00 CR56 PG36 CR56 10-Oct-00 1-Dec-01 1-Nov-02 10-Aug-03 PG16
propertyNo pAddress rent ownerNo oName PG4 6 Lawrence St, Glasgow 350 C040 Tina Murphy PG16 5 Novar Dr, Glasgow 450 C093 Tony Shaw PG4 6 Lawrence St, Glasgow 350 C040 Tina Murphy PG36 2 Manor Rd, Glasgow 375 C093 Tony Shaw 5 Novar Dr, Glasgow 450 C093 Tony Shaw PG16 oName ownerNo C040 Tina Murphy C093 Tony Shaw Client Rental PropertyForRent Owner
Gambar 2.13. 3rd-normalized Form (3NF) (Sumber Connolly dan Begg, 2002, p396) d. Boyce-Codd Normal Form (BCNF)
Relasi yang disebut BCNF, adalah relasi yang hanya dan hanya jika setiap determinan adalah kunci kandidat
e. Fourth Normal Form (4NF)
Yaitu relasi yang terdapat pada Boyce-Codd normal form dan tidak mengandung ketergantungan bernilai banyak
f. Fifth Normal Form (5NF)
Didefinisikan sebagai relasi yang tidak mempunyai join
dependency
2.1.13 4th GL (Generation Language)
Menurut Connolly dan Begg (2002, p42), jika dibandingkan dengan 3rd GL yang prosedural, 4th GL adalah bahasa yang non-prosedural karena user mendefinisikan apa yang akan dikerjakan, bukan bagaimana cara mengerjakannya. User tidak mendefinisikan langkah-langkah yang perlu dikerjakan oleh program, tetapi mendefinisikan parameter untuk tools yang digunakan mereka untuk men-generate suatu program aplikasi.
Keunggulan yang ditawarkan oleh 4th GL adalah lines of codes yang lebih sedikit dibanding 3rd GL dan peningkatan produktivitas. Contoh dari bahasa generasi keempat : SQL dan QBE.
4th GL mencakup :
• bahasa presentasi, seperti bahasa query dan report generators • bahasa spesialisasi, seperti spreadsheets dan bahasa basisdata
• generator aplikasi (application generator) yang mendefinisikan, menambah, mengubah dan mengambil data dari basisdata untuk membuat aplikasi
• bahasa dengan level yang sangat tinggi (very high-level language) yang digunakan untuk membuat kode aplikasi
Perencanaan Basisdata
Definisi Sistem
Pengumpulan dan Analisa Kebutuhan
Desain Basisdata Logikal Desain Basisdata
Konseptual
Desain Basisdata Fisikal
Desain Aplikasi Pemilihan DBMS (Optional)
Prototyping (Optional)
Konversi dan Loading Data
Testing Implementasi
Pemeliharaan Operasional Desain Basisdata
2.1.14 Siklus Hidup Aplikasi Basis Data
Menurut Connolly dan Begg (2002, p272), siklus hidup sebuah aplikasi basisdata digambarkan sebagai berikut :
Gambar 2.14 Tahapan Siklus Hidup Aplikasi Basisdata (Sumber Connolly dan Begg, 2002, p272)
Berikut adalah aktifitas utama dari setiap tahap dalam siklus hidup aplikasi basisdata :
a. Perencanaan Basisdata (Database planning)
Merencanakan bagaimana tahapan dari siklus hidup ini dapat direalisasikan secara lebih efisien dan lebih efektif. Perencanaan basisdata harus dapat diintegrasikan dengan keseluruhan strategi sistem informasi organisasi. Terdapat tiga hal penting yang terlibat dalam memformulasikan sebuah strategi sistem informasi dengan perencanaan basisdata, yaitu :
• Mengidentifikasi rencana dan tujuan perusahaan dengan penentuan sistem informasi yang diperlukan
• Mengevaluasi sistem informasi yang digunakan sekarang untuk menentukan kekuatan dan kelemahan
• Penilaian tentang peluang teknologi informasi yang mungkin menghasilkan keuntungan yang kompetitif
Perencanaan basisdata juga harus meliputi pengembangan standar pengumpulan data, bagaimana penetapan format dan dokumentasi yang diperlukan, bagaimana desain dan implementasi diproses.
b. Definisi Sistem (System definition)
Menspesifikasikan ruang lingkup dan batasan dari aplikasi basisdata, user view utama.
Menurut Connolly dan Begg (2002, p275), user view mendefinisikan apa yang dibutuhkan aplikasi basisdata dari sudut pandang user, dalam hal ini peran pekerja tertentu (misalnya manajer atau supervisor) atau area aplikasi perusahaan (misalnya marketing, personil atau kontrol stok)
Sebuah aplikasi basisdata dapat mempunyai satu atau lebih
user view. Mengidentifikasi user view adalah aspek yang penting
dalam mengembangkan aplikasi basisdata, karena dapat membantu untuk memastikan tidak ada pengguna utama dari basisdata yang terlupakan saat membuat dan mengembangkan kebutuhan-kebutuhan untuk aplikasi yang baru.
c. Analisa dan Pengumpulan (Requirement collection and analysis) Mengumpulkan dan menganalisa informasi mengenai bagian dari organisasi yang akan didukung oleh aplikasi basisdata, dan menggunakan informasi ini untuk mengidentifikasi kebutuhan pengguna sistem baru (kebutuhan user dan area aplikasi).
Informasi tersebut diambil dari tiap user view yang penting, dimana didalamnya termasuk :
• Deskripsi tentang bagaimana data digunakan atau dibuat • Detil dari bagaimana data akan digunakan atau dibuat • Kebutuhan tambahan untuk aplikasi basisdata baru
Pada bagian ini dilakukan pengumpulan dan analisa informasi tentang bagan-bagian dari enterprise yang akan menggunakan atau terkait
dengan basisdata yang akan dibuat. Untuk itu digunakan teknik Fact
Finding Techniques.
Terdapat lima teknik Fact Finding yang umum digunakan : 1. Mengevaluasi dokumen
2. Wawancara
3. Mengobservasi jalannya kegiatan kerja perusahaan 4. Penelitian
5. Kuisioner
d. Desain Basisdata (Database design)
Merancang basisdata yang akan mendukung operasi dan tujuan enterprise.
Desain basisdata dibuat dalam tiga fase utama, yaitu : • Desain konseptual basisdata
Proses membangun model informasi yang digunakan dalam sebuah enterprise, terbebas dari semua pertimbangan fisik.
• Desain logikal basisdata
Proses membangun model informasi yang digunakan dalam sebuah enterprise yang didasarkan oleh data model spesifik, dan terbebas dari DBMS tertentu dan pertimbangan fisik lainnya. • Desain fisikal basisdata
Proses memproduksi sebuah deskripsi dari implementasi basisdata dalam secondary storage, yang menjelaskan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai akses
yang efisien ke data, dan setiap integrity constraint yang saling berhubungan dan juga pengukuran keamanan (security).
e. Pemilhan DBMS ( DBMS selection (optional) )
Memilih DBMS yang sesuai untuk mendukung aplikasi basisdata.
Berikut ini adalah tahapan utama untuk menseleksi basisdata adalah :
• Menggambarkan cakupan tugas berdasarkan kebutuhan perusahaan
• Membuat perbandingan mengenai dua atau tiga produk • Mengevaluasi produk-produk DBMS yang dipilih
• Merekomendasikan pemilihan DBMS dan membuat laporan hasil evaluasi produk-produk DBMS tersebut
f. Desain Aplikasi (Application design)
Merancang user interface dan program aplikasi yang menggunakan dan memproses basisdata.
Pada tahap ini harus dipastikan semua spesifikasi kebutuhan pengguna terdapat di dalam desain aplikasi untuk aplikasi basisdata. Desain aplikasi dibagi menjadi dua aspek, yaitu :
• Desain transaksi
Menurut Connolly dan Begg (2002, p551), transaksi dapat diartikan sebagai sebuah atau serangkaian aksi, yang dilakukan oleh
seorang user atau program aplikasi, yang mengakses atau mengubah isi dari basisdata.
Terdapat tiga tipe utama transaksi :
Retrieval Transaction, contohnya tampilan detil data properti (data ditampilkan dalam bentuk angka)
Update Transaction, contohnya operasi memasukkan detil data properti baru ke dalam basisdata
Mixed Transaction, contohnya operasi untuk mencari detil data properti, menampilkannya dan kemudian meng-update nilainya
• Desain Antarmuka Pengguna g. Prototyping (optional)
Membangun suatu working model dari aplikasi basisdata, yang mengizinkan desainer atau user untuk memvisualisasikan dan mengevaluasi bagaimana final system akan berfungsi.
h. Impelementasi (Implementation)
Realisasi fisik dari basisdata dan desain aplikasi. Implementasi basisdata dilakukan dengan menggunakan Data
Definition Language (DDL) dari DBMS yang dipilih, atau dengan
menggunakan Graphical User Interface (GUI), yang menyediakan fungsionalitas yan sama dengan saat menyembunyikan statement
low-level DDL.
Program aplikasi diimplementasikan menggunakan bahasa generasi ketiga atau keempat (3rd GL atau 4th GL). Bagian dari
program aplikasi ini adalah transaksi basisdata, yang diimplementasikan dengan menggunakan Data Manipulation
Language (DML), yang biasanya sudah terdapat dalam bahasa
pemrograman. Selain itu pada tahap ini diimplementasikan pula sekuriti dan control integritas.
i. Data conversion and loading
Mentransfer semua data dari basisdata lama ke basisdata yang baru dan mengkonversi aplikasi yang ada untuk dijalankan di basisdata yang baru.
j. Testing
Aplikasi basisdata dites dengan tujuan untuk menemukan kesalahan dan validasi kebutuhan yang telah dispesifikasikan oleh
user.
k. Perawatan Operasional (Operational maintenance)
Proses memonitor dan merawat sistem setelah dilakukan instalasi.
Pada tahap perawatan ini melibatkan beberapa aktivitas :
• Memonitor performa sistem. Apabila performa berada di level bawah, maka dibutuhkan tuning atau reorganisasi basisdata
• Memelihara dan meng-upgrade aplikasi basisdata (apabila dibutuhkan).
2.1.15 Perancangan Basisdata Konseptual, Logikal dan Fisikal
Menurut Connolly dan Begg (2002, p419), terdapat tiga tahapan utama dalam perancangan basisdata, yaitu :
a. Desain Konseptual Basisdata
Proses membangun model informasi yang digunakan dalam sebuah enterprise, terbebas dari semua pertimbangan fisik.
Pada konseptual basisdata, desain ini terdiri dari langkah-langkah sebagai berikut :
Langkah 1 : Membangun data model konseptual lokal untuk setiap
view
1.1 Mengidentifikasi tipe entiti
Pada tahapan ini dilakukan identifikasi tipe entiti utama yang diperlukan oleh sebuah view. Salah satu metode dalam mengidentifikasi tipe entiti adalah dengan memeriksa kebutuhan
user. Dari kebutuhan user ini, kita dapat mengidentifikasi kata
benda atau frase yang ada (misalnya nama staff, alamat rumah), selain itu kita bisa mendapatkan objek utama seperti orang, tempat.
Cara lain dalam mengidentifikasi entiti adalah dengan melihat objek-objek yang akan tetap ada dan keberadaannya tidak tergantung pada objek lain, misalnya staff merupakan entiti karena staff tetap akan ada walaupun kita tidak mengetahui nama, posisi dan tanggal lahirnya.
1.2 Mengidentifikasi tipe relasi
Pada tahapan ini dilakukan identifikasi relasi penting yang ada antara tipe entiti yang telah teridentifikasi. Ketika mengidentifikasi relasi kita dapat menggunakan kata kerja dalam spesifikasi kebutuhan user. Misalnya :
• Staff mengatur Property
• PrivateOwner mempunyai Property
Dengan adanya kebutuhan user ini, membuktikan bahwa relasi-relasi yang terjadi adalah penting dan harus dimasukkan dalam model.
1.3 Mengidentifikasi dan menghubungkan atribut dengan entiti atau tipe entiti
Pada tahapan ini, atribut dihubungkan dengan entiti atau tipe entiti yang tepat.
1.4 Menentukan domain atribut
Domain adalah sebuah penampung dari nilai yang dapat ditampung oleh atribut, misalnya domain atribut dari nomor staf hanya dapat menggunakan 5 karakter string dengan 2 karakter pertama adalah huruf dan 3 huruf berikutnya adalah angka. 1.5 Menentukan candidate dan primary key dari atribut
Candidate key adalah set atribut minimal dari sebuah entiti
yang secara unik mengidentifikasi setiap kemunculan dari entiti tersebut. Candidate key dapat didefinisikan lebih dari satu,
tetapi harus dipilih satu sebagai primary key, sedangkan
candidate key yang lain disebut alternate key.
Berikut adalah acuan dalam menentukan primary key dari
candidate key :
• Candidate key dengan set atribut yanng minimal
• Candidate key dengan nilai yang berubah paling sedikit
• Candidate key dengan karakter paling sedikit
• Candidate key dengan isi maksimum yang paling sedikit
• Candidate key yang termudah digunakan dari sudut
pandang user
1.6 Mempertimbangkan penggunaan konsep model yang lebih tinggi (enhanced modelling concepts) Æ optional
Tahapan ini bersifat pilihan, apakah akan digunakan pengembangan dari entiti model dengan menggunakan
enhanced modelling concepts, seperti spesialisasi/generalisasi.
1.7 Memeriksa redudansi pada model
Tahapan ini memeriksa model data konseptual lokal apakah terjadi duplikasi atau tidak dengan dua langkah, yaitu : • Memeriksa ulang relasi one-to-one
1.8 Memvalidasi model data konseptual lokal terhadap transaksi
user
Memeriksa model yang telah dihasilkan apakah mendukung transaksi pada view. Pemeriksaan ini dapat menggunakan dua langkah yaitu :
• Mendeskripsi transaksi • Menggunakan jalur transaksi
1.9 Memeriksa model data konseptual lokal dengan user
Memeriksa model data konseptual lokal termasuk ER, jika terjadi ketidakcocokan maka harus dilakukan perubahan.
b. Desain Logikal Basisdata
Proses membangun model informasi yanng digunakan dalam sebuah enterprise yang didasarkan pada data model spesifik, dan terbebas dari DBMS dan semua pertimbangan fisik.
Pada desain logikal basisdata terdiri dari langkah-langkah sebagai berikut :
Langkah 2 : Membangun dan memvalidasi model data logikal lokal untuk setiap view.
Dari model data konseptual lokal yang telah dibangun pada tahapan pertama akan diubah menjadi model data logikal lokal yang terdiri dari entity relationship diagram, sebuah relationship schema dan dokumentasi-dokumentasi pendukung.
2.1 Menghilangkan hal-hal yang tidak sesuai dengan model relational (optional)
Model data konseptual lokal yang telah ada dapat mengandung struktur yang tidak dapat dimodelkan oleh DBMS konvensional, oleh karena itu pada tahap ini dilakukan perubahan menjadi bentuk yang lebih mudah ditangani oleh sistem ini.
Langkah-langkah yang dapat dilakukan dalam penyesuaian struktur adalah :
• Menghilangkan relasi binary many-to-many (*:*) • Menghilangkan relasi rekursif many-to-many (*:*) • Menghilangkan tipe relasi yang kompleks
• Menghilangkan atribut multi-valued 2.2 Mendapatkan relasi untuk model data logikal
Membentuk relasi dari model data logikal lokal untuk merepresentasikan relasi antar entiti dan atribut yang telah diidentifikasikan.
Untuk mendapatkan relasi dari data model yang ada maka digunakan cara-cara berikut ini :
• Tipe entiti yang kuat • Tipe entiti yang lemah
• Relasi binari one-to-many (1:*) • Relasi binari one-to-one (1:1)
• Relasi rekursif one-to-one • Tipe relasi superclass/subclass
2.3 Memvalidasi relasi menggunakan normalisasi
Normalisasi digunakan untuk meningkatkan model yang telah terbentuk agar duplikasi data yang tidak diperlukan dapat dihindari.
2.4 Memvalidasi relasi dengan transaksi user
Memastikan relasi yang telah ada pada model data logikal dapat mendukung transaksi yang diperlukan oleh view.
2.5 Mendefinisikan integrity constraints
Integrity constraints adalah batasan yang digunakan untuk
menjaga agar basisdata tidak menjadi inkonsisten. Ada 5 tipe integrity constraints :
• Required data (data atau nilai yang valid) • Batasan domain atribut
• Entity integrity (primary key tidak boleh null)
• Referential integrity (foreign key pada suatu entiti harus sesuai dengan candidate key pada entiti lain)
• Enterprise constraints (batasan pada organisasi) 2.6 Memeriksa model data logikal lokal dengan user
Memastikan model data logikal lokal yang terbentuk merupakan representasi dari user view. Untuk memvalidasi
model data logikal ini digunakan data flow diagram (DFD). DFD dapat menunjukkan aliran data dari suatu organisasi.
Langkah 3: Membangun dan memvalidasi nodel data logikal global Pada tahap ini, digabungkan semua model data logikal lokal menjadi sebuah model data logikal global yang merepresentasikan organisasi tersebut.
3.1 Menggabungkan model data logikal lokal ke dalam model global Menggabungkan mode data logikal individual ke dalam model data logikal global.
3.2 Memvalidasi model data logikal global
Memvalidasi relasi yang telah dibuat dari model data global menggunakan teknik normalisasi dan memastikan relasi ini mendukung transaksi yang diperlukan. Langkah ini sama dengan langkah 2.3 dan 2.4 yang memvalidasi setiap model data logikal lokal.
3.3 Memeriksa perkembangan yang akan datang
Memastikan apakah ada perubahan yang signifikan yang dapat diperkirakan dan memastikan apakah model data logikal global ini dapat mendukung perubahan-perubahan.
3.4 Memeriksa model data logikal global dengan user
Memastikan bahwa model data logikal global merupakan representasi nyata dari organisasi.
c. Desain Fisikal Basisdata
Proses memproduksi sebuah deskripsi dari implementasi basisdata dalam secondary storage, yang menjelaskan relasi dasar, organisasi file, dan membuat indeks utnuk mendapat akses yang efisien serta setiap integrity constraint yang saling berhubungan dan juga pengukuran keamanan.
Pada desain fisikal basisdata ini terdiri dari langkah-langkah sebagai berikut :
Langkah 4 : Menerjemahkan model data logikal global untuk DBMS yang akan digunakan
Pada tahap ini akan dihasilkan suatu skema basisdata relasional dari model data logikal global yang dapat diimplementasikan ke dalam DBMS yang digunakan.
4.1 Mendesain relasi dasar (base relation)
Memutuskan bagaimana merepresentasikan duplikasi relasi-relasi yang telah diidentifikasikan pada model data logikal global pada DBMS yang akan dipakai.
4.2 Mendesain representasi dari data yang diturunkan
Memutuskan bagaimana merepresentasikan derived
attribute dalam model data logikal global pada DBMS yang
akan dipakai
4.3 Mendesain enterprise constraint
Langkah 5 : Mendesain gambaran fisik dari basisdata
Menentukan organisasi file yang akan digunakan dan indeks untuk menghasilkan performa yang diinginkan serta menentukan apa saja yang akan disimpan dalam secondary storage.
5.1 Menganalisis transaksi
Memahami fungsi-fungsi dari transaksi yang akan dijalankan pada basisdata dan menganalisis transaksi yang penting.
5.2 Memilih organisasi file yang akan digunakan
Menentukan organisasi file yang efisien. Ada 5 tipe organisasi file :
• Heap • Hash
• Index Sequential Access Method (ISAM) • B-tree
• clusters
5.3 Memilih indeks yang digunakan
Memutuskan apakah dengan menggunakan indeks akan meningkatkan performa dari sistem.
5.4 Memperkirakan disk space yang digunakan
Memperkirakan disk storage yang diperlukan untuk menggunakan sistem basisdata, disk storage yang dimaksud adalah secondary storage.
Langkah 6 : Mendesain user view
Mendesain user view yang telah diidentifikasi Langkah 7 : Mendesain pengukuran keamanan
Membatasi pengaksesan basisdata oleh user yang tidak berhak dan menspesifikasi user terhadap basisdata yang dapat diakses
Langkah 8 : Menentukan apakah redundansi data yang telah dapat dikontrol
Dilakukan normalisasi agar dapat meningkatkan performa dari sistem dan menghilangkan redundansi.
8.1 Menggabungkan relasi one-to-one (1:1)
Mengkombinasikan relasi one-to-one (1:1) untuk menentukan efek dari pengkombinasian relasi menjadi sebuah relasi tunggal.
8.2 Menduplikasi atribut non-key dalam relasi one-to-many (1:*) untuk mengurangi join
Mempertimbangkan keuntungan yang akan dihasilkan dalam penduplikasian satu atau lebih atribut non-key dari relasi parent di dalam relasi child pada sebuah relasi 1:* dengan tujuan untuk mengurangi atau menghilangkan join dari query yang sering digunakan.
8.3 Menduplikasi atribut foreign key dalam relasi one-to-many (1:*) untuk mengurangi join
Mempertimbangkan keuntungan yang akan dihasilkan dalam penduplikasian satu atau lebih atribut foreign-key dalam
sebuah relasi dengan tujuan untuk mengurangi atau menghilangkan join dari query yang sering digunakan.
8.4 Menduplikasi atribut dalam relasi many-to-many (*:*) untuk mengurangi join
Melakukan join dari tiga buah tabel untuk menghasilkan sebuah informasi pada relasi many-to-many dengan tujuan untuk mengurangi atau menghilangkan join.
8.5 Memperkenalkan repeating group
Meningkatkan efektifitas dan performa dari sistem jika dibutuhkan pengaksesan ke sebuah relasi.
8.6 Menggabungkan lookup table dengan relasi dasar
Mengurangi join dari relasi child ke look up table dengan menambahkan deskripsi table parent ke table child.
8.7 Membuat tabel ekstrak
Langkah 9 : Memonitor sistem operasional
Memonitor dan meningkatkan performa dari sistem dengan memperbaiki desain yang tidak sesuai atau perubahan kebutuhan.
2.2 Teori khusus 2.2.1 Sistem Pakar
2.2.1.1 Pengertian Sistem pakar
Secara umum, sistem pakar (expert system) adalah sistem yang berusaha mengadopsi pengetahuan manusia ke komputer, agar komputer dapat menyelesaikan masalah seperti yang biasa oleh dilakukan para ahli. Sistem pakar yang baik dirancang agar dapat menyelesaikan suatu permasalahan tertentu dengan meniru kerja dari para ahli.
Ada beberapa definisi tentang sistem pakar, antara lain: 1. Menurut Durkin
Sistem Pakar adalah suatu program komputer yang dirancang untuk memodelkan kemampuan penyelesaian masalah yang dilakukan oleh seorang pakar.
2. Menurut Ignizio
Sistem Pakar adalah suatu model dan prosedur yang berkaitan, dalam suatu domain tertentu, yang mana tingkat keahliannya dapat dibandingkan dengan keahlian seorang pakar.
3. Menurut Giarratano dan Riley
Sistem Pakar adalah suatu sistem komputer yang bisa menyamai atau meniru kemampuan seorang pakar.
2.2.1.2 Keuntungan dan kelemahan Sistem Pakar
Secara garis besar, banyak manfaat yang dapat diambil dengan adanya sistem pakar, antara lain :
1. Memungkinkan orang awam bisa mengerjakan pekerjaan para ahli.
2. Bisa melakukan proses secara berulang secara otomatis. 3. Menyimpan pengetahuan dan keahlian para pakar. 4. Meningkatkan output dan produktivitas
5. Meningkatkan kualitas
6. Mampu mengambil dan meletarikan keahlian para pakar (terutama yang termasuk keahlian langka).
7. Mampu beroperasi dalam lingkungan yang berbahaya. 8. Memiliki kemampuan untuk mengakses pengetahuan. 9. Memiliki reliabilitas
10. Meningkatkan kapabilitas sistem komputer
11. Memiliki kemampuan untuk bekerja dengan informasi yang tidak lengkap dan mengandung ketidakpastian.
12. Sebagai media pelengkap dalam pelatihan.
13. Meningkatkan kapabilitas dalam penyelesaian masalah. 14. Menghemat waktu dalam pengambilan keputusan
Disamping memiliki beberapa keuntungan, sistem pakar juga memiliki beberapa kelemahan, antara lain:
1. Biaya yang diperlukan untuk membuat dan memeliharanya sangat mahal.
2. Sulit dikembangkan. Hal ini tentu saja erat kaitannya dengan ketersediaan pakar dibidangnya.
3. Sistem pakar tidak 100% bernilai benar
2.2.1.3 Konsep dasar sistem pakar
Menurut Efraim Turban, konsep dasar sistem pakar mengandung keahlian, ahli, pengalihan keahlian, inferensi, aturan dan kemampuan menjelaskan.
2.2.1.4 Keahlian
Keahlian adalah Suatu kelebihan penguasaan pengetahuan di bidang tertentu yang diperoleh dari pelatihan, membaca atau pengalaman. 2.2.1.5 Seorang ahli adalah
Seseorang yang mampu menjelaskan suatu tanggapan, mempelajari hal-hal baru seputar topik permasalahan (domain), menyusun kembali pengetahuan jika dipandang perlu, memecah aturan-aturan jika dibutuhkan, dan membutuhkan relevan tidaknya keahlian mereka.
2.2.1.6 Tujuan utama sistem pakar
Pengalihan keahlian dari para ahli ke komputer untuk kemudian diahlikan lagi ke orang lain yang bukan ahli.
Proses ini membutuhkan 4 aktivitas yaitu :
1. Tambahan pengetahuan (dari para ahli atau sumber-sumber lainnya)
3. Inferensi pengetahuan
4. Pengalihan pengetahuan ke user 2.2.1.7 Basis Pengetahuan ( Knowledge Base)
Basis Pengetahuan adalah pengetahuan yang disimpan di komputer. Ada 2 tipe pengetahuan, yaitu fakta dan prosedur (biasanya berupa aturan).
Basis pengetahuan berisi pengetahuan-pengetahuan dalam penyelesaian masalah, tertentu saja di dalam domain tertentu.
Ada 2 bentuk pendekatan basis pengetahuan yang umum digunakan, yaitu :
1. Penalaran berbasis aturan ( Rule-Based Reasoning ) 2. Penalaran berbasis kasus ( Case-Based Reasoning ) 2.2.1.8 Perbedaan antara Sistem Konvensional dengan Sistem Pakar
Sistem Konvensional dan Sistem Pakar memiliki perbedaan-perbedaan, yaitu seperti terdapat dalam tabel 2.1.
Tabel 2.1 Perbedaan Sistem Konvensional dan Sistem Pakar
Sistem Konvesional Sistem Pakar
Informasi dan pemrosesnya biasanya jadi satu dengan program.
Basis pengetahuan merupakan bagian terpisah dari mekanisme infersi.
Biasanya tidak bisa menjelaskan mengapa suatu input data itu dibutuhkan, atau bagaimana
Penjelasan adalah bagian terpenting dari sistem pakar
Sistem Konvesional Sistem Pakar output itu diperoleh.
Perubahan program cukup sulit dan membosankan
Pengubahan aturan dapat dilakukan dengan mudah
Sistem hanya akan beroperasi jika sistem tersebut sudah lengkap
Sistem dapat beroperasi hanya dengan beberapa aturan
Eksekusi dilakukan langkah demi langkah
Eksekusi dilakukan pada keseluruhan basis pengetahuan
Menggunakan data Menggunakan pengetahuan
Tujuan utamanya adalah efisiensi Tujuan utamanya adalah efektivitas
2.2.1.9 Bentuk Sistem Pakar Ada 4 bentuk sistem pakar, yaitu :
1. Berdiri sendiri. Sistem pakar jenis ini merupakan Software yang berdiris sendiri tidak tergabung dengan software yang lainnya.
2. Tergabung. Sistem pakar jenis ini merupakan bagian program yang terkandung di dalam suatu algoritma ( konvensional ), atau merupakan program dimana di dalamnya memaggil algoritma subrutin lain ( konvensional )
3. Menghubungkan ke software lain. Bentuk ini biasanya merupakan sistem pakar yang menghubungkan ke suatu paket program tertentu, misalnya DBMS.
4. Sistem mengabdi. Sistem pakar merupakan bagian dari komputer khusus yang dihubungkan dengan suatu fungsi tertentu.
2.2.1.10 Struktur Sistem Pakar
Sistem pakar terdiri dari dua bagian pokok, yaitu :
1. Lingkungan pengembangan ( Development ) digunakan sebagai pembangunan sistem pakar baik dari segi pembangunan komponen maupun basis pengetahuan.
2. Lingkungan konsultasi ( Consultation Environment ) digunakan oleh seseorang yang bukan ahli untuk berkonsultasi.
2.2.1.11 Motor Infersi ( Inference Engine )
Ada 2 cara yang dapat dikerjakan dalam melakukan infersi, yaitu :
1. Forward Chaining
2. Backward Chaining
2.2.1.12 Ciri-ciri Sistem Pakar
Sistem pakar yang baik harus memenuhi ciri-ciri sebagai berikut : 1. Memiliki fasilitas informasi yang handal
2. Mudah dimodifikasi
3. Dapat digunakan dalam berbagai jenis komputer 4. Memiliki kemampuan untuk belajar beradaptasi
2.2.1.13 Permasalahan yang disentuh oleh Sistem Pakar
Ada beberapa masalah yang menjadi area luas aplikasi sistem pakar, antara lain : 1. Interpretasi 2. Prediksi 3. Diagnosis 4. Perancangan 5. Perencanaan 6. Monitoring 7. Debugging 8. Perbaikan 9. Instruksi 10. Kontrol 2.2.1.14 Mengembangkan Sistem Pakar
Pada pengembangan sistem pakar diperlukan beberapa tahapan seperti terlihat pada Gambar 2.15.
2.2.2 Proyek
2.2.2.1 Pengertian Kontrak
Kontrak atau perjanjian adalah merupakan bagioan dari Hukum Perdata, oleh karena itu ketentuan-ketentuan mengenai kontrak / perjanjian diatur dalam Kitab Undang-Undang Hukum Perdata (Burgelijk
Wetboek).
Menurut Pasal 1313 KUH Perdata , definisi perjanjian adalah sebagai berikut :
”Suatu perbuatan dengan mana satu orang atau lebih
menegikatkan dirinya terhadap satu orang lain atau lebih”.
Dari definisi tersebut dapat disimpulkan bahwa suatu perjanjian adalah perikatan antara pihak-pihak yang membuat perjanjian. Sebagai contoh, dalam Perjanjian Pelaksanaan Pekerjaan Konstruksi antara Pemilik Proyek dengan Kontraktor, maka Kontraktor terikat untuk melaksanakan pekerjaan pembangunan sedangkan Pemilik terikat untuk membayar hasil pekerjaan Kontraktor.
2.2.2.2 Pengertian Proyek
Proyek adalah sekumpulan aktivitas yang saling berhubungan di mana ada titik awal dan titik akhir serta hasil tertentu.
2.2.2.3 Pengertian Kontraktor
Kontraktor merupakan pelaksana konstruksi yang memiliki tugas dan kewajiban melaksanakan dan menyerahkan proyek itu sesuai kontrak kepada Pengguna Jasa.
2.2.2.4 Pengertian Manajemen Proyek
Manajemen Proyek adalah suatu usaha untuk mengelola dan mengorganisasi beragam sumber daya selama masa proyek, di mana tujuan akhirnya adalah terwujudnya sasaran proyek yang meliputi kualitas, waktu, dan biaya yang telah ditentukan.
2.2.2.5 Organisasi Proyek
2.2.2.5.1 Pengertian Organisasi Proyek
Organisasi adalah sekelompok orang yang melakukan kegiatan dalam wadah dan cara tertentu untuk mencapai tujuan tertentu pula.
Organisasi Proyek adalah sekelompok orang dari berbagai latar belakang ilmu, yang terorganisir dan terkoordinirdalam wadah tertentu yang melaksanakan tugas dengan cara tertentu untuk mencapai tujuan bersama.
2.2.2.5.2 Contoh Organisasi Proyek
2.2.2.6 Perencanaan K3 (Keselamatan dan Kesehatan Kerja)
Perencanaan K3 berkaitan dengan penyusunan Safety Plan, Pengamanan Proyek (Security Plan), dan pengelolaan ketertiban dan kebersihan Proyek (House Keeping) dengan target ’Zero Accident’( tidak ada kecelakaan kerja).
2.2.2.7 Safety Plan
Safety Plan mencakup antara lain penyusunan Safety
Management, Identifikasi bahaya kerja dan penanggulangannya, Rencana
penempatan alat-alat pengamanan seperti pagar, jaring/net pada tangga dan tepi bangunan, railing serta rambu-rambu K3 serta rencana penempatan alat-alat pemadam kebakaran(tabung pemadam api), gudang bahan peledak, dan lain-lain. ++hal101
2.2.2.8 House Keeping (Ketertiban dan Kebersihan Proyek)
Pengelolaan Kebersihan Proyek adalah meliputi penempatan cerobongdan bak sampah, lokasi penempatan dan jumlah toilet pekerja, pengaturan kantor dan jalan sementara, gudang, los kerja, barak pekerja, dan lain-lain.
2.2.2.9 Perpajakan
Perusahaan jasa konstruksi wajib melaksanakan ketentuan perpajakan yang berlaku, antara lain :
1. UU. Pajak No. 16/2000 tentang Ketentuan Umum
Perpajakan 2. UU. Pajak No. 17/2000 tentang Pajak Penghasilan
Nomor Pokok Wajib Pajak (NPWP)
Suatu badan usaha harus memiliki NPWP.
Pengusaha Kena Pajak (PKP)
Dalam hal operasi perusahaan sudah mencapai suatu omset tertentu, maka perusahaan tersebut menjadi PKP.
Surat Pemberitahuan Pajak (SPT)
Perusahaan yang sudah menjadi PKP danNPWP berkewajiban menyampaikan SPT.
