BAB 2
LANDASAN TEORI
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, 2.1 Teori Sistem Basis-Data
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
batasan-batasan 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 System, memberikan akses bersama pada database.
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.
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
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.
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
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.
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
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 basis-data, 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.
• 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:
Gambar 2. 1 Siklus Hidup Aplikasi Basis Data Sumber: Connolly & Begg (2002, p272)
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, interview, observation, research, dan kuesioner.
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.
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
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
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
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) 2.2 Entity-Relationship Modeling
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)
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)
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.
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
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 to-one (1:1), one-to-many (1:*), many-one-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.
2. Chasm trap
Masalah ini terjadi jika sebuah model memperlihatkan ada sebuah hubungan antar entiti, tapi ternyata jalurnya tidak ada.
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 2.3 Normalisasi
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
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).
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).
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.
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
mengidentifikasikan simple / composite attribute, single / value 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
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
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:*).
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. Langkah ini mendeskripsikan:
a. Strong entity
b. Weak entity
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.
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.
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
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
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
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
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.
Langkah 7 : Mendesain mekanisme security
Tujuannya adalah mendesain kebutuhan keamanan untuk basis-data 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
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 mudah
• 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.
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.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 2.5 Teori Administrasi
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
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
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
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.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.
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, bagian-bagian, 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.
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
Dalam manufaktur, lead time bergantung pada waktu setup, waktu produksi, ukuran bidang, rangkaian mesin dimana operasi dijalankan, penundaan antrian, dan sebagainya.
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.
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).
2.8 Personal Home Page (PHP)
