7 BAB 2 LANDASAN TEORI
2.1
Teori Sistem Basis-Data Berikut ini akan dijelaskan teori-teori dasar sistem basis-data, yaitu mulai dari pengertian basis-data, pengertian sistem basis-data, pengertian DBMS, siklus hidup aplikasi basis-data sampai pada tahapan perancangan basis-data.
2.1.1 Pengertian Basis-Data Menurut Connolly & Begg (2002, p14), “Database is a shared collection of logically related data, and a description of this data, designed to meet the information needs of an organization”, yang artinya basis-data adalah kumpulan data yang berhubungan secara logika dan deskripsi mengenai data yang dirancang untuk memenuhi kebutuhan informasi dari suatu organisasi.
2.1.2 Pengertian Sistem Basis-Data Menurut Connolly & Begg (2002, p4), sistem basis-data merupakan kumpulan dari program-program aplikasi yang berinteraksi dengan basis-data.
2.1.3 Pengertian Database Management System (DBMS) Menurut Connolly & Begg (2002, p16), ”Database Management System (DBMS) is a software system that enables users to define, create, 7
8 maintain, and control access to the database”, yang artinya sistem manajemen basis-data adalah suatu sistem piranti lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, memelihara, serta mengendalikan akses terhadap basis-data. DBMS menyediakan beberapa fasilitas antara lain: ¾ Data Definition Language (DDL) Fasilitas ini memungkinkan user untuk mendefinisikan, menerangkan, dan
memberi nama entitas-entitas, atribut, dan
relationship yang dibutuhkan untuk aplikasi, termasuk batasanbatasan pada data untuk disimpan dalam basis-data. ¾ Data Manipulation Language (DML) Fasilitas ini menyediakan operasi dasar manipulasi data terhadap
database,
diantaranya
penyisipan
data
(insert),
modifikasi data (update), pemanggilan data (retrieve), dan penghapusan data (delete). ¾ Akses kontrol terhadap basis-data, diantaranya: a. Security system, mencegah user yang tidak memiliki wewenang untuk mengakses database. b. Integrity system, memelihara konsistensi data yang tersimpan. c. Concurrency
Control
bersama pada database.
System,
memberikan
akses
9 d. Recovery Control System, mengembalikan database ke kondisi konsisten sebelumnya dari kerusakan piranti keras atau piranti lunak. e. User-Accessible Catalog, berisi deskripsi dari data di dalam database. Menurut Elmasri (2001, p5), “Database Management System (DBMS) is a collection of programs that enables users to create and maintain a database”, yang artinya sistem manajemen basis-data adalah suatu kumpulan program yang mengijinkan pemakai untuk menciptakan dan memelihara sebuah basis-data.
2.1.4 Fungsi Database Management System (DBMS) Menurut Connolly (2002, p48-p52), fungsi dari DBMS antara lain sebagai berikut: 1. Data storage, retrieval, dan update DBMS harus melengkapi pengguna dengan kemampuan untuk menyimpan, mengambil, dan mengubah data pada basis-data. 2. A user-accessible catalog DBMS harus dilengkapi dengan katalog yang menyimpan deskripsi data dan dapat diakses oleh pengguna. 3. Transaction support DBMS harus dilengkapi dengan mekanisme yang memastikan seluruh perubahan berhubungan dengan transaksi.
10 4. Conccurency control services DBMS harus dilengkapi dengan mekanisme untuk memastikan basis-data diubah dengan benar saat beberapa pengguna mengubahnya pada waktu yang sama. 5. Recovery services DBMS
harus
dilengkapi
dengan
mekanisme
recovery
sebagai antisipasi jika terjadi kerusakan sewaktu-waktu. 6. Authorization services DBMS harus dilengkapi dengan mekanisme yang memastikan hanya pengguna yang berkepentingan saja yang boleh mengakses basis-data. 7. Support for data communication DBMS harus mampu berintegrasi dengan piranti lunak. 8. Integrity services DBMS harus bisa memastikan data yang ada di dalam basis-data dan perubahan data sesuai dengan aturan. 9. Services to promote data independence DBMS harus memiliki fasilitas yang mendukung kebebasan program dari struktur basis-data. 10. Utility services DBMS harus memiliki sekumpulan layanan kegunaan lainnya.
11 2.1.5 Keuntungan
dan
Kekurangan
Database
Management
System
(DBMS) Keuntungan dari Database Management System (DBMS) berdasarkan Connolly (2002, p25-p29) adalah: 1.
Control of redundancy Pendekatan
basis-data
menggabungkan
setiap
file
sehingga tidak terdapat duplikasi data. 2.
Data consistency Dengan menghilangkan redundansi, maka data akan tetap konsisten.
3.
More information from the same amount of data Dengan penggabungan seluruh data operasional, maka perusahaan dimungkinkan mendapat informasi tambahan.
4.
Sharing of data Pengguna yang memiliki akses pada basis-data dapat menggunakan seluruh data dari bagian sebuah perusahaan.
5.
Improved data integrity Validitas dan konsistensi dari data yang disimpan merupakan integritas dari suatu data.
6.
Improved security Data yang disimpan diberi hak akses bagi pengguna tertentu yang dapat membuka dan membaca suatu file.
12 7.
Enforcement of standard Database
administrator
mendefinisikan
dan
menambahkan standarisasi yang diperlukan. 8.
Economy scale Menggabungkan seluruh operasional data kedalam sebuah basis-data, dan membuat seperangkat aplikasi yang bekerja untuk mengakses data sehingga memperkecil biaya.
9.
Balance of conflicting requirement Oleh karena basis-data dibawah pengawasan database administrator,
maka
database
administrator
akan
membuat keputusan tentang rancangan dan penggunaan operasional dari basis-data yang dapat menyediakan solusi terbaik untuk kepentingan suatu perusahaan. 10.
Increased productivity Ada banyak DBMS yang menyediakan Fourth-generation environment
yang
terdiri
dari
tool-tool
yang
menyederhanakan pengembangan aplikasi basis data. Hal inilah yang dapat meningkatkan produktivitas programmer dan juga mengurangi waktu pengembangan. 11.
Improved maintenance throught data independence DBMS memisahkan aplikasi dengan deskripsi data, sehingga aplikasi tidak terpengaruhi oleh perubahan deskripsi data.
13 12.
Increased concurrency Dengan adanya sistem concurrency dalam basis data maka data yang sama dapat digunakan secara bersamaan oleh beberapa user.
13.
Improved backup and recovery services DBMS memiliki recovery control system yang dapat mengembalikan basis data ke status awal bila terjadi kegagalan hardware atau software.
Kekurangan dari Database Management System (DBMS) berdasarkan Connolly (2002, p29-30) adalah: 1.
Complexity DBMS yang baik mempunyai fungsionalitas yang banyak, sehingga DBMS merupakan piranti lunak yang sangat rumit.
2.
Size Kompleksitas DBMS menyebabkan piranti lunak tersebut membutuhkan tempat penyimpanan dan memori yang besar.
3.
Cost of DBMS Harga dari DBMS tinggi, tetapi bergantung juga pada fungsionalitas yang tersedia.
14 4.
Cost of conversion Biaya yang besar diperlukan untuk perpindahan dari sistem yang lama ke sistem yang baru.
5.
Performance Karena DBMS dirancang untuk banyak aplikasi dalam sebuah perusahaan, maka ada kemungkinan beberapa aplikasi tidak berjalan secepat file-based system.
6.
Higher impact of a failure Jika terjadi suatu kegagalan pada sistem, akan berpengaruh pada komponen-komponen lainnya.
2.1.6 Komponen Database Management System (DBMS) Komponen-komponen Database Management System (DBMS) berdasarkan Connolly (2002, p18-p20), terdiri atas: Hardware DBMS dan aplikasi membutuhkan piranti keras (hardware) untuk tempat bergerak (run). Software Terdiri
dari
piranti
lunak
DBMS,
program-program
aplikasi, dan operating system, termasuk piranti lunak jaringan jika DBMS digunakan lewat jaringan.
15 Data Komponen paling penting dalam DBMS. Database harus mengandung data operasional dan metadata (data tentang data). Procedure Instruksi dan peraturan yang mempengaruhi rancangan dan penggunaan dari basis-data. People Terdiri atas: •
Data Administrator (DA), bertanggungjawab dalam pengaturan sumber data, meliputi perencanaan basisdata,
pengembangan
dan
pemeliharaan
standar,
kebijaksanaan dan prosedur, serta rancangan basis-data konseptual / logikal. •
Database Administrator (DBA), bertanggungjawab untuk
realisasi
fisikal
dari
database,
termasuk
rancangan dan implementasi basis-data fisikal, kendali keamanan
dan
integritas,
pemeliharaan
sistem
operasional, dan menjamin kepuasan penampilan aplikasi bagi pengguna. •
Database designer Mengidentifikasi data, relasi antara data, dan batasan data yang akan disimpan dalam basis-data.
16 •
Application Developer Mengimplementasikan program-program aplikasi yang menyediakan kebutuhan fungsional bagi end-user.
•
End-User Client bagi basis-data, yang telah dirancang dan diimplementasi untuk melayani kebutuhan informasi mereka.
2.1.7 Siklus Hidup Aplikasi Basis Data (Database Application Lifecycle) Tahapan siklus hidup aplikasi basis-data pada gambar 2.1 dibawah ini tidak harus dilakukan secara terurut, melainkan melalui sejumlah pengulangan dari tahapan Requirement Collection and Analysis agar diperoleh hasil yang semaksimal mungkin. Tahap-tahap siklus hidup aplikasi basis-data menurut Connolly and Begg (2002, p270) adalah:
17
Gambar 2. 1 Siklus Hidup Aplikasi Basis Data Sumber: Connolly & Begg (2002, p272)
18 Berikut ini adalah penjelasan tahapan-tahapan pada gambar 2.1. 2.1.7.1
Database Planning Pengaturan aktivitas yang mengijinkan tahap-tahap dari aplikasi basis-data direalisasikan seefektif dan seefisien mungkin.
2.1.7.2
System Definition Menjelaskan batasan-batasan dan cakupan dari aplikasi basis-data dan sudut pandang user (user view) yang utama. User view mendefinisikan mengenai apa yang dibutuhkan sebuah aplikasi basis-data dari sudut pandang jabatan kerja tertentu atau area aplikasi perusahaan.
2.1.7.3
Requirement Collection and Analysis Proses
pengumpulan
dan
analisa
informasi
mengenai bagian organisasi yang didukung oleh aplikasi basis-data
dan
menggunakan
informasi
ini
untuk
mengidentifikasi kebutuhan pengguna dari sistem baru. Untuk mengumpulkan informasi pada tahap ini digunakan berbagai teknik yang disebut teknik fact finding. Teknik ini
terdiri
atas
document
examination,
observation, research, dan kuesioner.
interview,
19 2.1.7.4
Database Design Proses menciptakan suatu rancangan basis-data yang akan mendukung operasi dan tujuan perusahaan. Ada tiga tahap (fase) dalam perancangan basis-data, yaitu perancangan konseptual, logikal, dan fisikal.
2.1.7.5
Database
Management
System
Selection
(Optional) Pemilihan DBMS yang tepat untuk mendukung aplikasi basi-data. Tahap-tahap utama untuk memilih DBMS, yaitu mendefinisikan terminologi studi referensi, mendaftar dua atau tiga produk, evaluasi produk, serta rekomendasi pilihan dan laporan produk.
2.1.7.6
Application Design Perancangan user interface dan program aplikasi yang menggunakan dan memproses basis-data.
2.1.7.7
Prototyping (Optional) Membangun sebuah model kerja dari aplikasi basis-data.
20 2.1.7.8
Implementation Merupakan realisasi fisik dari basis-data dan rancangan aplikasi.
2.1.7.9
Data Conversion and Loading Pemindahan data yang ada ke dalam basis-data baru dan mengubah aplikasi yang ada agar dapat digunakan pada basis-data yang baru.
2.1.7.10
Testing Proses mengeksekusi program aplikasi dengan tujuan untuk menemukan kesalahan.
2.1.7.11
Operational Maintenance Proses pengawasan dan pemeliharaan sistem setelah instalasi. Aktivitasnya adalah memonitor tampilan sistem, memperbaiki, dan memperbarui aplikasi basis-data.
2.1.8 Stored Procedures SQL statement baik berupa Data Definition Language dan Data Manipulation Language adalah cara yang umum bagi aplikasi untuk memperoleh data untuk ditampilkan. Namun, seiring dengan faktor keamanan dan performa, terdapat alternatif SQL statement untuk dibungkus dalam stored procedure. Stored procedure menyimpan
21 pernyataan SQL dalam sebuah berkas yang disimpan pada database server, sehingga dari sisi performa eksekusi, utilitas jaringan, dan keamanan, stored procedure banyak digunakan sebagai solusi akses data. Menurut Mannino (2001, p399), “Stored procedure is a collection of statements that are managed by a DBMS”, yang artinya stored procedure adalah kumpulan pernyataan yang dikelola oleh sebuah DBMS. Keunggulan penggunaan stored procedure ditinjau dari beberapa aspek, antara lain: a.
Kinerja •
Execution plan pada stored procedure sudah dibuat pada saat prosedur itu dikompilasi. Jadi, hanya terjadi 1 kali.
•
Stored procedure dapat ditandai pada memori, maksudnya sebuah stored procedure dapat dipaksa untuk tetap berada di memori fisik meskipun DBMS membutuhkan memori tambahan. Akibatnya, operasi swaping in dan swapping out stored procedure dapat diminimalkan terutama untuk stored procedure yang sering dipakai.
•
Stored procedure dapat digunakan untuk membatasi jumlah record yang dikirim ke client. Hal ini dapat mengurangi beban jaringan.
22 b.
Keamanan •
Stored procedure mencegah terjadinya SQL injection. SQL injection adalah aksi hacking yang dilakukan di aplikasi client dengan cara memodifikasi perintah SQL yang ada di memori aplikasi client.
•
Hak akses stored procedure terhadap data di database bergantung pada hak akses pembuatnya, bukan bergantung pada hak akses pengguna stored procedure. Hal ini memungkinkan user aplikasi tidak diberi hak akses terhadap semua tabel yang ada, namun diberi hak akses untuk menjalankan stored procedure.
•
Perlindungan hak cipta. Stored procedure dapat dienkripsi, sehingga proses tidak dapat dibajak orang dengan mudah.
c.
Fleksibilitas terhadap perubahan proses bisnis Stored procedure tersimpan di server. Modifikasi mudah dilakukan dengan cepat.
d.
Ekonomi Stored procedure menyediakan sebuah pintu masuk untuk proses data entry. Aplikasi client tinggal mengaksesnnya. Stored procedure dibuat satu kali dan dapat diakses oleh aplikasi client yang berbeda-beda. Efisien dan murah.
23 2.2
Entity-Relationship Modeling Menurut Connolly & Begg (2002, p330), Entity-Relationship Modeling adalah pendekatan top down pada perancangan basis-data yang dimulai dengan mengidentifikasi data penting yang disebut dengan entitas dan hubungan diantara data yang harus direpresentasikan dalam model.
2.2.1 Entity Type Entity type adalah kumpulan dari obyek yang memiliki sifat yang sama (Connolly, 2002, p331). Sebuah entiti memiliki keadaan bebas dan bisa merupakan obyek fisik / nyata (seperti staf, pelanggan, dan lain-lain) atau merupakan obyek konseptual / abstrak (seperti penjualan, inspeksi, dan lain-lain). Entity occurrence adalah obyek yang secara unik diidentifikasikan oleh sebuah entity type (Connolly, 2002, p333).
Gambar 2. 2 Entity Type dari Staff dan Branch Sumber: Connolly & Begg (2005, p345)
24 2.2.2 Relationship Type Relationship type adalah kumpulan hubungan antar tipe entiti. Relationship occurrence adalah hubungan yang diidentifikasikan secara unik, yang termasuk sebuah kemunculan dari setiap entity type yang berpartisipasi (Connolly, 2002, p334). Jumlah entity type yang berpartisipasi pada sebuah hubungan (relationship) disebut sebagai degree of a relationship type. Beberapa macam hubungan antar entiti adalah sebagai berikut: 1.
Binary, hubungan dengan dua entiti berpartisipasi di dalamnya.
Gambar 2. 3 Binary Relationship Sumber: Connolly & Begg (2005, p348)
2.
Ternary, hubungan tiga entiti berpartisipasi di dalamnya.
Gambar 2. 4 Ternary Relationship Sumber: Connolly & Begg (2005, p348)
25 3.
Quaternary, hubungan dengan empat entiti berpartisipasi di dalamnya.
Gambar 2. 5 Quaternary Relationship Sumber: Connolly & Begg (2005, p349)
4.
Recursive,
relationship
type
dimana
entiti
yang
sama
berpartisipasi lebih dari satu kali dengan aturan yang berbeda.
Gambar 2. 6 Recursive Relationship Sumber: Connolly & Begg (2005, p349)
26 2.2.3 Attribute Menurut Connolly (2002, p338), atribut (attribute) adalah properti dari sebuah entiti atau relationship type. Attribute domain adalah himpunan nilai untuk satu atau lebih atribut (Connolly, 2002, p338). Domain mendefinisikan nilai potensial yang dapat disimpan oleh sebuah atribut. Beberapa macam atribut: 1. Simple attribute, atribut yang terdiri dari sebuah komponen tunggal dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi. Contohnya adalah jabatan, gaji, dan sebagainya. 2. Composite attribute, atribut yang terdiri dari berbagai komponen lain yang lebih kecil. Contohnya adalah atribut alamat. Atribut ini bisa terdiri dari berbagai komponen lainnya, misalnya jalan, kota, dan kode pos. 3. Single-valued attribute, atribut yang menyimpan sebuah nilai tunggal untuk setiap kemunculan dari entity type. Contohnya adalah nomor induk pegawai pada entiti pegawai. 4. Multi-valued attribute, atribut yang menyimpan beberapa nilai untuk setiap kemunculan dari entity type. Contohnya adalah nomor telepon dari suatu pelanggan yang lebih dari satu. 5. Derived attribut, atribut yang merepresentasikan nilai yang diturunkan dari sebuah nilai atau beberapa atribut yang lain.
27 2.2.4
Key Model entity relationship memiliki beberapa key. Diantaranya
mirip dengan model relasional. Key yang ada pada model ini adalah (Connolly, 2002, p340-p341): 1.
Candidate key, jumlah minimal atribut-atribut yang dapat mengidentifikasikan setiap kejadian dari sebuah entity type secara unik.
2.
Primary
key,
candidate
key
yang
dipilih
untuk
mengidentifikasikan setiap kejadian dari suatu entiti secara unik. 3.
Composite key, candidate key yang terdiri dari dua atau lebih atribut.
2.2.5 Strong and Weak Entity Type Menurut Connolly (2002, p342-p343), entity type dapat diklasifikasikan sebagai berikut: a. Strong entity type, suatu entity type yang keberadaannya tidak bergantung pada entiti lainnya. b. Weak entity type, suatu entity type yang keberadaannya bergantung pada entiti lain.
2.2.6 Structural Constraint Structural constraint adalah batasan yang ditempatkan pada entity type yang berpartisipasi dalam sebuah relationship. Tipe utama dari batasan pada relationship adalah multiplicity. Menurut Connolly (2002,
28 p344), multiplicity adalah jumlah (atau range) dari kejadian yang mungkin terjadi pada suatu entiti, yang terhubung pada kejadian tunggal dari kumpulan entiti melalui suatu relationship khusus. Beberapa jenis relationship berdasarkan multiplicity: 1. One-to-one (1:1) relationship 2. One-to-many (1:*) relationship 3. Many-to-many (*:*) relationship
2.2.7 Cardinality and Participation Constraint Cardinality menjelaskan jumlah maksimum kemunculan dari entiti yang berpartisipasi pada sebuah relationship (Connolly, 2002, p351). Cardinality dari binary relationship adalah one-to-one (1:1), oneto-many (1:*), many-to-many (*:*). Participation menjelaskan apakah seluruh atau hanya beberapa kemunculan entiti yang berpartisipasi pada sebuah relationship (Connolly, 2002, p351). Participation terdiri dari mandatory dan optional.
2.2.8 Masalah pada Model Entity Relationship Menurut Connolly (2002, p351-p355), ada dua buah masalah pada model entity relationship yaitu: 1. Fan trap Masalah
ini
terjadi
dimana
sebuah
model
merepresentasikan hubungan antar entiti, tapi jalurnya ambigu.
29 2. Chasm trap Masalah ini terjadi jika sebuah model memperlihatkan ada sebuah hubungan antar entiti, tapi ternyata jalurnya tidak ada.
2.3
Normalisasi Normalisasi adalah teknik untuk menghasilkan kumpulan relasi dengan properti yang diinginkan, sesuai dengan kebutuhan data perusahaan (Connolly, 2002, p376). Normalisasi merupakan metode formal yang dapat digunakan untuk mengidentifikasikan relasi berdasarkan key dan functional dependencies antar atribut. Tujuan dari normalisasi adalah untuk menghilangkan redundansi data. Berikut ini tabel berisi data yang redundan dan dapat menyebabkan beberapa anomalies: Tabel 2. 1 StaffBranch (Connolly, 2002, p377) StaffBranch
StaffNo sName
position
salary
branchNo
bAddress
SL21
John White
Manager
30000
B005
22 Deer Rd, London
SG37
Ann Beech
Assistant
12000
B003
163 Main St, Glasgow
SG14
David Ford
Supervisor
18000
B003
163 Main St, Glasgow
SA9
Marry Howe
Assistant
9000
B007
16 Argyll St, Aberden
SG5
Susan Brand
Manager
24000
B003
163 Main St, Glasgow
SL41
Julie Lie
Assistant
9000
B005
22 Deer Rd, London
30 Data redundansi dapat menyebabkan: 1. Insertion anomalies Berdasarkan tabel StaffBranch di atas, dapat terjadi dua tipe insertion anomalies yaitu: a.
Untuk menambahkan sebuah data staff yang baru pada relasi StaffBranch, data cabang juga harus dimasukkan. Data cabang tersebut harus sama dengan yang sebelumnya. Jika tidak sama, maka akan terjadi insertion anomalies.
b.
Untuk menambahkan sebuah data cabang yang baru, data tersebut harus disertai dengan data staffnya. Jika tidak, maka akan terjadi insertion anomalies. Hal ini dikarenakan atribut staffNo adalah primary key dan tidak boleh null.
2. Deletion anomalies Masalah ini terjadi jika salah satu tuple dalam relasi StaffBranch dihapus, misalnya data terakhir. Maka data B005 akan hilang. 3. Modification anomalies Masalah ini terjadi jika salah satu atribut dari cabang tertentu pada relasi StaffBranch diubah, misalnya alamat B003 diubah. Maka seluruh data staff yang berada pada B003 harus diubah.
2.3.1 Unnormalized Form (UNF) Merupakan suatu tabel yang berisikan satu atau lebih group yang berulang (Connolly, 2002, p387). Membuat tabel unnormalized, yaitu
31 dengan memindahkan data dari sumber informasi ke dalam format tabel dengan baris dan kolom.
2.3.2 First Normal Form (1NF) First normal fom adalah relasi dimana perpotongan dari setiap baris dan kolom hanya memiliki satu buah nilai (Connolly, 2002, p388). Perubahan dari UNF ke 1NF adalah dengan menghilangkan repeating group. Dua cara pada tahapan ini adalah: 1. Menghilangkan repeating group dengan mengisi data yang sesuai pada kolom yang kosong. 2. Memisahkan repeating group dengan data yang tidak berulang.
2.3.3 Second Normal Form (2NF) Second normal form adalah relasi yang berada pada 1NF dan setiap atribut non primary key memiliki ketergantungan fungsional secara penuh (fully functional dependency) pada primary key (Connolly, 2002, p392). Normalisasi pada tahapan ini bertujuan untuk menghilangkan partial dependencies. Fully functional dependency mengindikasikan jika A dan B adalah atribut pada sebuah atribut, B adalah fully functional dependency pada A jika B functional dependent pada A, tetapi bukan bagian dari A (Connolly, 2002, p391).
32 Functional depenency A→B adalah partial dependent jika beberapa atribut dapat dihapus dari A dan ketergantungan masih tetap terjaga.
2.3.4 Third Normal Form (3NF) Third normal form adalah relasi yang berada pada 1NF dan 2NF dimana tidak ada atribut non primary key yang transitively dependent pada primary key (Connolly, 2002, p394). Transitive dependent adalah kondisi dimana A, B, dan C adalah atribut pada sebuah relasi dan A→B, kemudian B→C, maka C transitively dependent pada A melalui B (Connolly, 2002, p394).
2.4
Perancangan Basis-Data Menurut Connolly (2002, p419), perancangan basis-data adalah proses pembuatan sebuah rancangan untuk sebuah basis-data yang mendukung operasi dan tujuan dari perusahaan. Perancangan basis-data dibagi kedalam tiga tahapan utama, yaitu perancangan basis-data konseptual, perancangan basis-data logika, dan perancangan basis-data fisikal.
2.4.1 Perancangan Konseptual Perancangan konseptual adalah proses membangun sebuah model data dari informasi yang diperoleh dari perusahaan yang bebas dari pertimbangan fisikal. Berikut ini langkah-langkah dalam perancangan basis-data konseptual.
33 Langkah 1 : Membuat model data konseptual lokal untuk setiap view 1.1
Mengidentifikasikan entity type Langkah ini bertujuan untuk mengidentifikasikan entiti utama yang
dibutuhkan
oleh
pengguna.
Hal-hal
yang
dilakukan pada langkah ini: a. Mengidentifikasi entiti dengan membahas spesifikasi kebutuhan pengguna. b. Membuat dokumentasi dari entiti tersebut.
1.2
Mengidentifikasikan relationship type Langkah
ini
bertujuan
untuk
mengidentifikasikan
relationship penting yang ada diantara entiti yang telah diidentifikasi. Beberapa hal yang dilakukan pada langkah ini: a. Menggunakan model Entity Relationship Diagram (ERD) untuk merepresentasikan entiti. b. Menetapkan multiplicity constraint dari relationship. c. Memeriksa fan trap dan chasm trap. d. Memeriksa entiti yang terkait dalam sebuah relationship. e. Mendokumentasikan relationship.
1.3
Mengidentifikasikan dan menggabungkan atribut dengan entity atau relationship Langkah ini bertujuan untuk menggabungkan atribut dengan entiti atau relationship yang tepat yaitu dengan
34 mengidentifikasikan simple / composite attribute, single / multivalue attribute, dan derived attribute.
1.4
Menentukan attribute domain Langkah ini bertujuan untuk menentukan domain atribut pada model data konseptual lokal.
1.5
Menentukan atribut primary key dan candidate key Langkah ini bertujuan untuk mengidentifikasi candidate key untuk setiap entiti dan jika terdapat lebih dari satu candidate key, maka dipilih satu untuk dijadikan primary key.
1.6
Mempertimbangkan
penggunaan
konsep
model
enhanced
(optional) Langkah
ini
bertujuan
untuk
mempertimbangkan
penggunaan dari konsep model enhanced, seperti spesialisasi / generalisasi, aggregasi, dan komposisi.
1.7
Memeriksa model dari redundancy Langkah
ini
bertujuan
untuk
memeriksa
adanya
redunndancy pada model data. Ada dua langkah yang perlu dilakukan pada tahap ini, yaitu: a. Memeriksa ulang relationship (1:1). Mungkin saja teridentifikasi dua entiti yang merepresentasikan obyek
35 yang sama. Penyelesaiannya, dua entiti tersebut harus digabungkan. Jika terdapat dua primary key yang berbeda, maka pilih salah satu menjadi primary key dan yang lainnya menjadi alternate key. b. Menghilangkan relationship yang redundan.
1.8
Memvalidasi model data konseptual lokal terhadap transaksi pengguna Langkah ini bertujuan untuk meyakinkan bahwa model data konseptual lokal telah mendukung transaksi yang dibutuhkan oleh setiap view. Ada dua pendekatan yang mungkin untuk meyakinkan bahwa model data konseptual lokal telah mendukung transaksi antara lain: a. Mendeskripsikan transaksi. b. Menggunakan pathway transaksi.
1.9
Meninjau ulang model data konseptual lokal dengan pengguna Langkah ini bertujuan untuk memeriksa model data konseptual lokal terhadap pengguna untuk meyakinkan bahwa model tersebut sudah benar.
2.4.2 Perancangan Logikal Perancangan basis-data logikal adalah proses membangun model informasi yang digunakan dalam perusahaan berdasarkan model data
36 yang spesifik, tetapi tidak tergantung terhadap DBMS atau pertimbangan fisik lainnya (Connolly, 2002, p419). Langkah 2 : Membuat dan memvalidasi data model lokal logikal untuk setiap view. Tujuannya adalah membangun model data logikal lokal dari model data konseptual lokal yang mewakili view tertentu dari perusahaan dan kemudian memvalidasi model tersebut untuk meyakinkan bahwa sudah terstruktur dengan benar (dengan menggunakan teknik normalisasi) dan untuk meyakinkan bahwa sudah mendukung transaksi yang dibutuhkan. 2.1
Menghilangkan fitur yang tidak kompatibel dengan model relasional (optional) Langkah ini bertujuan untuk memperbaiki model data konseptual lokal dengan menghilangkan fitur yang tidak kompatibel. Ada empat langkah yang harus dilakukan untuk menghilangkan fitur yang tidak kompatibel, yaitu: a. Menghilangkan tipe binary relationship many-to-many (*:*) Penyelesaian dari tipe relationship ini adalah dengan membuat sebuah entiti baru diantara kedua relasi tersebut sehingga muncul dua relationship (1:*).
37 b. Menghilangkan tipe recursive relationship many-to-many (*:*) Penyelesaiannya
adalah
dengan
membuatnya
menjadi dua entiti. Entiti yang baru dibuat adalah sebuah weak entity. c. Menghilangkan tipe complex relationship Penyelesaiannya
adalah
dengan
mengubah
complex relationship menjadi sebuah entiti baru, biasanya dengan membuat sebuah weak entity. d. Menghilangkan multi-valued attribute Penyelesaiannya adalah dengan membuat sebuah entiti bernama baru sebagai tempat atribut tersebut, kemudian duplikasikan primary key kedalam entiti tersebut sebagai foreign key.
2.2
Menentukan relasi untuk model data logikal lokal Langkah ini bertujuan untuk menciptakan relasi untuk model data logikal lokal yang mewakili entiti, relationship, dan atribut
yang
sudah
diidentifikasikan.
mendeskripsikan: a. Strong entity b. Weak entity c. One-to-many (1:*) binary relationship
Langkah
ini
38 Untuk setiap relationship (1:*), entiti di satu sisi dari relationship dibuat sebagai entiti parent dan entiti di banyak sisi dibuat sebagai entiti child, primary key dari entiti parent diduplikasikan kedalam entiti child sebagai foreign key. d. One-to-one (1:1) binary relationship Mempertimbangkan hal-hal berikut : 1) Mandatory participation on both side relationship (1:1) Penyelesaiannya, dengan menggabungkan dua entiti tersebut kedalam satu relasi dan memilih salah satu primary key dari dua entiti awal untuk menjadi primary key. 2) Mandatory participation on one side relationship (1:1) Penyelesaiannya,
dengan
mengidentifikasi
entiti
parent dan entiti child. Entiti yang mempunyai optional participation pada relationship ditunjuk sebagai entiti child. Primary key dari entiti parent ditempatkan pada relasi yang merepresentasikan entiti child. 3) Optional participation on both side relationship (1:1) Misalnya, ada relasi Staff dan Car. Penyelesaiannya dapat berupa membuat duplikasi primary key relasi Staff kedalam relasi Car, atau sebaliknya.
39 e. One-to-one (1:1) recusive relationship Pada relationship rekursif (1:1) dengan partisipasi mandatori
dua
sisi,
penyelesaiannya
dengan
menggabungkan dua relasi tersebut menjadi sebuah relasi. f. Superclass / subclass relationship Identifikasikan entiti superclass sebagai entiti parent dan entiti subclass sebagai entiti child. g. Many-to-many (*:*) binary relationship Penyelesainnya adalah dengan membuat sebuah relasi yang menggambarkan relationship, kemudian duplikasikan primary key dari entiti yang terlibat dalam relationship ke dalam relasi baru tersebut untuk berlaku sebagai foreign key. h. Complex relationship Penyelesainnya adalah dengan membuat sebuah relasi untuk menggambarkan relationship, kemudian duplikasikan primary key dari entiti yang berada dalam relationship ke dalam relasi baru untuk berlaku sebagai foreign key. i. Multi-valued Penyelesaiannya adalah dengan membuat sebuah relasi baru yang menggambarkan atribut multi-valued dan duplikasikan primary key dari entiti ke relasi baru untuk berlaku sebagai foreign key.
40 2.3
Memvalidasi relasi menggunakan normalisasi Langkah ini bertujuan untuk memvalidasi relasi pada model data logikal lokal menggunakan teknik normalisasi.
2.4
Memvalidasi relasi terhadap transaksi pengguna Langkah ini bertujuan untuk memvalidasi model data logikal lokal untuk memastikan model tersebut mendukung kebutuhan pengguna seperti yang sudah diuraikan pada tahap spesifikasi kebutuhan pengguna (user requirement specification).
2.5
Menentukan integrity constraints Langkah ini bertujuan untuk menetapkan integrity constraint yang diberikan pada tiap view. Ada lima tipe integrity constraint, yaitu: a. Required data, beberapa atribut tidak boleh bernilai NULL. NULL digunakan untuk merepresentasikan data yang tidak tersedia, hilang, atau tidak disertakan. b. Domain constraint, setiap field mempunyai domain atau himpunan dari nilai-nilai yang benar. c. Entity integrity d. Referential integrity e. Enterprise constraint
41 2.6
Memeriksa model data logikal lokal dengan pengguna Langkah ini bertujuan untuk meyakinkan bahwa model data logikal lokal dan dokumen-dokumen pendukung yang mendeskripsikan model merupakan representasi dari view.
Langkah 3 : Membangun dan memvalidasi model data logikal Tujuannya adalah mengkombinasikan model data logikal lokal individual menjadi sebuah model data logikal global. 3.1
Menggabungkan model data logikal lokal menjadi model global Langkah ini bertujuan untuk menggabungkan model data logikal lokal individual menjadi sebuah model data logikal global. Ada beberapa tugas yang perlu dilakukan pada langkah ini, yaitu : a. Review nama dan isi dari entiti / relasi dan candidate key b. Review nama dan isi dari relationship / foreign key c. Menggabungkan entiti / relasi dari model data lokal d. Mengikutsertakan (tanpa menggabungkan) entiti dan relasi yang unik ke setiap model data lokal e. Menggabungkan relationship / foreign key dari model data lokal f. Mengikutsertakan (tanpa menggabungkan) relationship / foreign key yang unik ke setiap model data lokal g. Memeriksa entiti / relasi dan relationship / foreign key yang hilang h. Memeriksa foreign key
42 i. Memeriksa integrity constraint j. Menggambar ER / diagram relasi global k. Memperbaharui dokumentasi
3.2
Memvalidasi model data logikal global Langkah ini bertujuan untuk memvalidasi relasi yang dihasilkan dari model data logikal global dan untuk memastikan model data sudah mendukung transaksi yang dibutuhkan.
3.3
Memeriksa perkembangan yang akan datang Langkah ini bertujuan untuk menentukan jika ada perubahan yang signifikan dan untuk memeriksa kemungkinan model data logikal global dapat berakomodasi dengan perubahan tersebut.
3.4
Melihat ulang model logikal dengan pengguna Langkah ini bertujuan untuk meyakinkan bahwa model data logikal global adalah representasi yang tepat dari perusahaan.
2.4.3 Perancangan Fisikal Perancangan basis-data fisikal adalah proses untuk membuat deskripsi dari implementasi basis-data pada secondary storage; perancangan ini menjelaskan relasi dasar, organisasi file, index untuk
43 akses data yang efisien, dan integrity constraint serta keamanan (Connolly, 2002, p419).
Langkah 4 : Menerjemahkan model data logikal global untuk target DBMS 4.1
Mendesain relasi dasar Langkah ini bertujuan untuk memutuskan bagaimana menggambarkan relasi dasar yang diidentifikasikan pada model data global logikal pada target DBMS. Semua informasi yang tersimpan dalam kamus data (data dictionary) dan definisi relasi dideskripsikan dengan Database Design Language (DBDL).
4.2
Mendesain representasi dari derived data Langkah ini bertujuan untuk memutuskan bagaimana beberapa derived data digambarkan pada model data logikal global pada target DBMS.
4.3
Mendesain enterprise constraint Langkah ini bertujuan untuk merancang enterprise constraint pada target DBMS.
Langkah 5 : Mendesain representasi fisikal Langkah ini bertujuan untuk menentukan organisasi file yang optimal untuk menyimpan relasi dasar dan menentukan penggunaan
44 index untuk mencapai performance yang maksimal. Dalam hal ini relasi akan disimpan di dalam secondary storage. 5.1
Menganalisa transaksi Langkah ini bertujuan untuk memahami fungsionalitas transaksi yang akan dijalankan pada basis-data dan untuk menganalisa seberapa pentingnya transaksi.
5.2
Memilih organisasi file Langkah ini bertujuan untuk menentukan organisasi file yang efisien untuk setiap relasi dasar. Jika target DBMS tidak membutuhkan pemilihan ini, maka langkah ini dapat diabaikan.
5.3
Memilih index Langkah ini bertujuan untuk menentukan penambahan index mana yang dapat meningkatkan kinerja sistem.
5.4
Memperkirakan kebutuhan disk Langkah ini bertujuan untuk memperkirakan jumlah ruang atau tempat penyimpanan yang dibutuhkan oleh basis-data.
Langkah 6 : Mendesain user view Tujuannya untuk merancang / mendesain user view yang telah diidentifikasi selama pengumpulan kebutuhan dan tahap penganalisaan aplikasi relational database.
45 Langkah 7 : Mendesain mekanisme security Tujuannya adalah mendesain kebutuhan keamanan untuk basisdata yang diinginkan oleh pengguna.
Langkah 8 : Mempertimbangkan penggunaan kontrol redudansi. Tujuannya adalah menentukan apakah penggunaan kontrol redudansi dengan menggunakan teknik normalisasi akan meningkatkan performa sistem. Jika keadaan ternormalisasi tidak membuat performa sistem meningkat, maka langkah ini dapat dilakukan. Langkah-langkah pada tahap ini adalah: 8.1
Menggabungkan relationship one-to-one (1:1) Penggabungan harus dipertimbangkan jika dua relasi tersebut sering ditunjuk secara bersamaan.
8.2
Duplikasi atribut non-key pada relationship one-to-many (1:*) Menduplikasikan atribut non-key yang sering ditunjuk bersamaan dengan tabel-tabel lain untuk mengurangi operasi join table.
8.3
Duplikasi atribut foreign key pada relationship one-to-many (1:*) Menduplikasikan foreign key ke dalam sebuah relasi untuk mengurangi kerumitan dalam melakukan join banyak tabel.
46 8.4
Duplikasi atribut-atribut pada relationship many-to-many (*:*) Menduplikasi satu atau lebih atribut ke relasi lain, karena atribut sering diakses bersamaan dengan relasi tersebut.
8.5
Penggunaan repeating group Penggunaan repeating group disini adalah dengan menambahkan atribut pada relasi parent. Repeating group digunakan apabila: •
jumlah repeating group diketahui dan absolut,
•
nomornya statis dan tidak akan berubah sepanjang waktu,
•
nomor tidak terlalu besar, meskipun tidak terlalu penting seperti pada dua kondisi pertama.
8.6
Menggabungkan lookup table dengan relasi dasar Lookup table terkadang disebut dengan reference table atau pick list, yang merupakan kasus khusus pada relationship (1:*). Keuntungan dari lookup table yaitu : •
Pengurangan ukuran dari relasi anak; tipe kodenya hanya memakan ukuran 1 byte dari yang sebenarnya 5 byte.
•
Jika
deskripsi
dapat
diubah,
akan
lebih
mengubahnya hanya sekali di lookup table.
mudah
47 •
Lookup table dapat digunakan untuk memvalidasi masukan dari pengguna.
8.7
Membuat extract table Membuat extract table yang sangat terdenormalisasi berdasarkan relasi-relasi yang dibutuhkan dapat mengurangi kerumitan, khususnya pada sistem yang sering diakses.
Langkah 9 : Memonitor dan memperbaiki operasional sistem Tujuannya adalah memonitor sistem yang sudah berjalan dan meningkatkan kinerja sistem sehingga dapat memperbaiki keputusan perancangan yang salah atau karena perubahan kebutuhan. Beberapa keuntungan memonitor sistem basis-data, diantaranya yaitu : 1. Dapat
menghindari
usaha
untuk
mendapatkan
tambahan
perangkat keras. 2. Memungkinkan untuk dapat memperkecil konfigurasi perangkat keras. 3. Sistem yang termonitor dengan baik menghasilkan respon terhadap waktu yang lebih cepat dan lebih baik ketika digunakan oleh pengguna dan oleh karena itu organisasinya lebih produktif. 4. Dengan meningkatkan response time dapat meningkatkan semangat anggota staf. 5. Dengan meningkatnya response time dapat meningkatkan kepuasan hati para pelanggan.
48 2.5
Teori Administrasi 2.5.1 Pengertian Administrasi Menurut Mills (1991, p4), administrasi adalah bagian dari proses manajemen yang berhubungan dengan pelaksanaan prosedur yang digunakan untuk menentukan dan mengkomunikasikan program dan perkembangan kegiatan yang diatur dan diperiksa berdasarkan target dan rencana. Menurut Siagian (1998, p3), administrasi didefinisikan sebagai keseluruhan proses kerjasama antara dua orang manusia atau lebih yang didasarkan atas rasionalitas tertentu untuk mencapai tujuan yang telah ditentukan sebelumnya.
2.6
Teori tentang Produksi 2.6.1 Pengertian Produksi Menurut Groover (2006, p1), produksi merupakan suatu kumpulan orang, peralatan, dan aturan-aturan yang dikelola sedemikian rupa untuk melaksanakan operasi-operasi manufaktur dalam sebuah pabrik (atau organisasi lainnya). Menurut Singh (2000, p8), siklus hidup suatu produk meliputi: •
Fase perancangan
•
Fase pabrikasi (manufacturing)
•
Fase pemakaian produk
•
Fase pembuangan
49
2.6.2 Pengertian Sistem Produksi Menurut Nasution (2006, p2), sistem produksi adalah kumpulan dari subsistem-subsistem yang saling berinteraksi dengan tujuan mentransformasikan input produksi menjadi output produksi. Input produksi ini dapat berupa bahan baku, mesin, tenaga kerja, modal, dan informasi. Output produksi merupakan produk yang dihasilkanberikut hasil sampingannya seperti limbah, informasi, dan sebagainya. Menurut Groover (2006, p2), sistem produksi dapat dibagi menjadi dua kategori, yaitu: 1.
Fasilitas produksi Yang dimaksud dengan fasilitas dalam sistem produksi adalah pabrik, mesin-mesin produksi dan tooling, peralatan pemindahan bahan, peralatan inspeksi dan komputer yang mengendalikan operasi manufaktur di dalamnya (Groover, 2006,
p2).
Peralatan
produksi
biasanya
ditempatkan
berkelompok mengikuti logika tertentu dan kita menyebut cara pengaturan ini serta pekerja yang mengoperasikan mesin tersebut sebagai sistem manufaktur dalam suatu pabrik. 2.
Sistem penunjang manufaktur Agar pengoperasian fasilitas produksi berlangsung efisien, sebuah pabrik harus melakukan swakelola dirinya untuk merancang proses dan peralatannya, merencanakan dan mengendalikan aturan produksi, serta memenuhi persyaratan
50 kualitas produk. Fungsi-fungsi ini harus dilaksanakan oleh sistem penunjang manufaktur yang terdiri dari karyawan dan aturan-aturan yang digunakan perusahaan untuk mengelola operasi produksinya (Groover, 2006, p9).
2.6.3 Fungsi Produksi Aktivitas produksi sebagai suatu bagian dari fungsi organisasi perusahaan bertanggung jawab terhadap pengolahan bahan baku menjadi produksi jadi yang dapat dijual. Menurut Nasution (2006, p1), ada tiga fungsi utama dari kegiatan-kegiatan produksi yang dapat kita identifikasi, yaitu: •
Proses produksi, yaitu metode dan teknik yang digunakan dalam mengolah bahan baku menjadi produk.
•
Perencanaan produksi, yaitu tindakan antisipasi dimasa mendatang sesuai dengan periode waktu yang direncanakan.
•
Pengendalian produksi, yaitu tindakan yang menjamin bahwa semua kegiatan yang dilaksanakan dalam perencanaan telah dilakukan sesuai dengan target yang telah ditetapkan.
2.6.4 Perencanaan dan Pengendalian Produksi (PPC) Menurut Nasution (2006, p13), PPC (Production Planning and Control) dapat didefinisikan sebagai proses untuk merencanakan dan mengendalikan aliran material yang masuk, mengalir, dan keluar dari
51 sistem produksi / operasi sehingga permintaan pasar dapat dipenuhi dengan jumlah yang tepat, waktu penyerahan yang tepat, dan biaya produksi minimum. Perencanaan produksi dilakukan dengan tujuan menentukan arah awal dari tindakan-tindakan yang harus dilakukan di masa mendatang, apa yang harus dilakukan, berapa banyak melakukannya, dan kapan harus melakukan. Karena perencanaan ini berkaitan dengan masa mendatang, maka perencanaan disusun atas dasar perkiraan yang dibuat berdasarkan data masa lalu dengan menggunakan beberapa asumsi (Nasution, 2006, p13). Untuk berhasilnya kegiatan perencanaan produksi, maka perlu adanya kerjasama yang baik dengan bagian-bagian lain, seperti: 1. Bagian teknik dan pengolahan, yaitu mengenai urut-urutan operasi pengerjaan suatu produk, waktu yang dibutuhkan serta fasilitas yang diperlukan. 2. Bagian pembelian, yaitu mengenai pembelian bahan-bahan dan komponen yang dibutuhkan untuk membuat produk tersebut. 3. Manajer persediaan, yaitu mengenai penyimpanan bahan-bahan atau barang-barang yang diterima dan produk yang selesai dikerjakan serta penyediaan bahan-bahan pada saat dibutuhkannya. Rencana produksi yang telah disusun tidak akan dapat dilaksanakan tanpa danya pengendalian terhadap pelaksanaan rencana tersebut. Secara sederhana, pengendalian dapat didefinisikan sebagai proses yang dibuat untuk menjaga supaya realisasi dari suatu aktivitas
52 sesuai dengan yang direncanakan. Oleh karena itu, pengendalian terdiri dari prosedur-prosedur untuk menentukan penyimpangan dari rencana yang telah ditetapkan dan tindakan-tindakan perbaikan yang diperlukan untuk mengeliminir penyimpangan tersebut (Nasution, 2006, p20).
2.7
Teori tentang Manufaktur 2.7.1 Pengertian Manufaktur Manufaktur merupakan suatu aktivitas manusia yang meliputi seluruh tahap kehidupan manusia. Kata manufaktur diperoleh dari bahasa Latin, manus (tangan) dan factus (yang dibuat), dan didefinisikan kamus sebagai proses pembuatan barang-barang dan artikel dengan tangan, terutama dengan mesin, dalam skala besar dan dengan pembagian kerja. Menurut Singh (2000, p5), “Manufacturing is a series of interrelated activities and operations involving design, material selection, planning, production, quality assurance, management, and marketing of discrete consumer and durable goods”, yang artinya manufaktur adalah suatu rangkaian aktivitas yang saling berhubungan dan operasi-operasi yang
meliputi desain, pemilihan material, perencanaan, produksi,
jaminan kualitas, manajemen, dan pemasaran dari barang tahan lama dan konsumen yang terpisah.
53 2.7.2 Material Requirement Planning (MRP) Teknik Perencanaan Kebutuhan Material (MRP) digunakan untuk perencanaan dan pengendalian item barang (komponen) yang bergantung (dependent) pada item-item pada tingkat (level) yang lebih tinggi. Kebutuhan pada item-item yang bersifat tergantung merupakan hasil dari kebutuhan yang disebabkan oleh penggunaan item-item tersebut dalam memproduksi item yang lain. Menurut Singh (2000, p408), “Material Requirements Planning (MRP) system is essentially an information system consisting of logical procedures for managing inventories of component assemblies, subassemblies,
parts,
and
raw
materials
in
a
manufacturing
environment”, yang artinya sistem perencanaan kebutuhan material adalah sebuah sistem informasi yang terdiri dari prosedur logis untuk mengelola inventaris pemasangan komponen, subassembly, bagianbagian, dan bahan mentah dalam sebuah lingkungan manufaktur. Menurut Nasution (2006, p129), ada empat kemampuan yang menjadi ciri utama dari sistem MRP, yaitu: 1. Mampu menentukan kebutuhan pada saat yang tepat Maksudnya adalah menentukan secara tepat kapan suatu pekerjaan harus diselesaikan atau kapan material harus tersedia untuk memenuhi permintaan atas produk akhir yang sudah direncanakan pada jadwal induk produksi.
54 2. Membentuk kebutuhan minimal untuk setiap item Dengan diketahuinya kebutuhan akan produk jadi, MRP dapat menentukan secara tepat sistem penjadwalan (berdasarkan prioritas) untuk memenuhi semua kebutuhan minimal setiap item komponen. 3. Menentukan pelaksanaan rencana pemesanan Maksudnya adalah memberikan indikasi kapan pemesanan atau pembatalan terhadap pesanan harus dilakukan, baik pemesanan yang diperoleh dari luar atau dibuat sendiri. 4. Menentukan penjadwalan ulang atau pembatalan atas suatu jadwal yang sudah direncanakan Apabila kapasitas yang ada tidak mampu memenuhi pesanan yang dijadwalkan pada waktu yang diinginkan, maka MRP dapat memberikan indikasi untuk melakukan rencana penjadwalan ulang dengan menentukan prioritas pesanan yang realistis. Jika penjadwalan masih tidak memungkinkan untuk memenuhi pesanan, berarti perusahaan tidak mampu memenuhi permintaan konsumen, sehingga perlu dilakukan pembatalan atas pesanan konsumen tersebut.
2.7.3 Lead Time Menurut Singh (2000, p411), “the lead time is the time it takes to produce or purchase a part”, yang artinya lead time adalah waktu yang diperlukan untuk menghasilkan atau membeli suatu bagian.
55 Dalam manufaktur, lead time bergantung pada waktu setup, waktu produksi, ukuran bidang, rangkaian mesin dimana operasi dijalankan, penundaan antrian, dan sebagainya.
2.8
Personal Home Page (PHP) Menurut Nugroho (2004, p29), Personal Home Page merupakan bahasa standar yang digunakan dalam dunia website. Personal Home Page adalah bahasa program yang berbentuk script, yang diletakkan kedalam server web. Jika dilihat dari sejarah, mulanya PHP diciptakan dari ide Rasmus Lerdof yang membuat script Perl. Script tersebut sebenarnya digunakan sebagai program untuk dirinya sendiri. Tetapi kemudian dikembangkan lagi, sehingga menjadi bahasa yang disebut “Personal Home Page”. Inilah awal mula munculnya PHP sampai saat ini.
2.9
MySQL Menurut Nugroho (2004, 29), MySQL adalah sebuah program pembuat database yang bersifat open source, yang artinya siapa saja boleh menggunakannya dan tidak akan dicekal. MySQL juga merupakan program pengakses database yang bersifat jaringan, sehingga dapat digunakan untuk aplikasi multi user (banyak pengguna). Kelebihan lain dari MySQL yakni bahasa query standar yang dimiliki SQL (Structur Query Language).
