BAB 2 LANDASAN TEORI
2.1 Teori Umum 2.1.1 Definisi Umum 2.1.1.1 Pengertian Analisis M enurut Whitten-Bently-Ditman (2004, p38), analisis adalah suatu proses yang bertujuan untuk memberikan pengertian yang lebih mendalam mengenai masalah-masalah yang dihadapi dan perlunya pembuatan proyek yang bersangkutan. 2.1.1.2 Pengertian Perancangan M enurut Whitten-Bently-Ditman (2004, p38), perancangan adalah suatu proses menelusuri alternatif-alternatif solusi yang bersifat teknis untuk mengatasi permasalahan yang terjadi. 2.1.1.3 Pengertian Sistem M enurut David L. Olson (2001, p7), sistem adalah kumpulan bagianbagian yang saling berkaitan dan keseluruhan bagian tersebut bekerja secara bersama-sama untuk mencapai suatu tujuan. M enurut M cLeod (2001, p11), sistem adalah sekelompok elemen yang terintegrasi dengan maksud yang sama untuk mencapai suatu tujuan. Suatu sistem biasanya terdiri dari komponen-komponen yang dihubungkan untuk memudahkan
6
7 aliran informasi. Istilah ini sering dipergunakan untuk menggambarkan suatu set entitas yang berinteraksi. Sebuah sistem mempunyai karakteristik sebagai berikut: -
Komponen-komponen
-
Batas sistem
-
Lingkungan di luar sistem
-
Penghubung
-
M asukan
-
Keluaran
-
Pengolah
-
Sasaran
-
Tujuan
2.1.1.4 Pengertian Informasi M enurut Turban-Rainer-Potter (2003, p15), informasi adalah kumpulan fakta-fakta (data) yang diorganisasikan dengan beberapa cara sehingga menjadi sesuatu yang yang berarti bagi yang menerimanya. 2.1.1.5 Pengertian Sistem Informasi M enurut Turban-Rainer-Potter (2003, p15), sistem informasi adalah proses mengumpulkan, mengelola, menyimpan, menganalisa, dan menghasilkan informasi untuk tujuan tertentu. Sistem informasi meliputi input dan output. M enurut Connolly-Begg (2005, p270), sistem informasi adalah sumbersumber yang memungkinkan pengumpulan, manajemen, pengendalian, dan penghasilan informasi dalam suatu organisasi.
8 2.1.1.6 Data M enurut Turban-Rainer-Potter (2003, p15), data adalah fakta-fakta dan deskripsi dasar mengenai sesuatu, kejadian, kegiatan, dan transaksi yang diambil, disimpan dan diklasifikasikan tetapi belum terstruktur dengan baik sehingga belum memberikan sesuatu arti yang penting. 2.1.1.7 Database M enurut Connolly-Begg (2005, p15), database adalah kumpulan data yang terkait secara logis, dan merupakan suatu deskripsi dari data, yang dirancang untuk memenuhi kebutuhan informasi dalam suatu organisasi. M enurut Gerard V. Post (2005, p2), database adalah kumpulan data yang disimpan berdasarkan standar format yang dirancang agar bisa digunakan bersama-sama oleh user yang berbeda-beda. M enurut Atzeni (2003, p2), database adalah kumpulan data yang digunakan untuk merepresentasikan informasi yang menarik ke dalam sistem informasi. 2.1.2 Sistem Database M enurut Connolly-Begg (2005, p4), sistem database adalah kumpulan dari program aplikasi yang berinteraksi dengan database dan DBM S. 2.1.2.1 Relational Model M enurut Connolly-Begg (2005, p70), kegunaan dari model relasional di antaranya: •
M emungkinkan data dengan tingkat independen yang tinggi. Program aplikasi seharusnya tidak terpengaruh oleh modifikasi terhadap representasi data
9 internal, khususnya perubahan terhadap organisasi file, urutan record, maupun jalur akses. •
M enjamin pengelolaan data dengan lebih baik dan konsisten, serta dapat mengatasi masalah redundansi.
•
M emungkinkan pengembangan pada kumpulan DM L (Data Manipulation Language) yang terorientasi.
M enurut Connolly-Begg (2005, p72), istilah-istilah dalam model relasi adalah:
Relation, merupakan sebuah tabel dengan kolom dan baris.
Attribute, merupakan nama kolom dari suatu relasi.
Domain, merupakan himpunan nilai-nilai yang valid pada atribut tertentu.
Tuple, merupakan sebuah baris dari suatu relasi.
Degree, merupakan jumlah atribut dalam suatu relasi.
Cardinality, merupakan jumlah tuple dalam suatu relasi.
Relational Database, merupakan kumpulan dari tabel-tabel yang telah dinormalisasi dengan nama relation yang unik.
2.1.2.2 Relational Key M enurut Connolly-Begg (2005, p78), tidak ada tuple yang berduplikasi dalam suatu relation, sehingga diperlukan satu atau lebih atribut yang secara unik mengidentifikasi setiap tuple dalam suatu relation. Atribut-atribut tersebut disebut dengan relational key. Relational key terdiri dari: •
Superkey adalah satu atau lebih atribut yang mengidentifikasi tuple secara unik dalam suatu relation.
10 •
Candidate key adalah sejumlah atribut yang dapat mengidentifikasi setiap kejadian atau record secara unik.
•
Alternate key adalah candidate key yang tidak terpilih menjadi primary key.
•
Primary key adalah candidate key yang terpilih untuk mengidentifikasi entitas-entitas di dalam entity set. Primary key harus merupakan field yang benar-benar unik dan tidak boleh ada nilai NULL.
•
Foreign key adalah primary key dari entitas yang digunakan untuk mengidentifikasi kejadian dari suatu relationship.
2.1.2.3 Database Management Sistem (DBMS ) M enurut Gerard V. Post (2005, p2), DBM S adalah software yang mengelola basis data dan penyimpanan data, mendukung bahasa query, menghasilkan laporan, dan membuat layer data entry. M enurut Atzeni (2003, p3), DBM S adalah sistem piranti lunak yang memungkinkan penanganan kumpulan data yang banyak, shared dan kontinu, serta dapat menjamin reliabilitas dan kerahasiaan data. M enurut Connolly-Begg (2005, p16), DBM S adalah sebuah software system yang memungkinkan user mendefinisi, membentuk dan mengatur database dan yang mengendalikan akses ke database. DBM S berinteraksi dengan pengguna aplikasi program dan database. DBM S menyediakan fasilitas: a. Data definition language (DDL), yang berguna untuk menspesifikasikan tipe data, struktur dan constraint data. Semua spesifikasi disimpan dalam database.
11 b. Data manipulation language (DM L), yang berguna untuk memberikan fasilitas query data. c. Pengendalian akses database, antara lain mengontrol: -
Keamanan sistem: mencegah user yang tidak memiliki hak akses untuk mengakses database.
-
Integritas sistem: menjaga konsistensi data.
-
Pengendalian share data.
-
Sistem backup dan recovery.
-
Katalog deskripsi data dalam database.
d. M ekanisme view, yang berfungsi untuk menyediakan data yang hanya diinginkan dan diperlukan user. M enurut Connolly-Begg (2005, p19), DBM S terdiri dari 5 komponen yaitu: o Hardware, yaitu berupa PC hingga jaringan komputer-komputer. o Software, yaitu DBM S, sistem operasi, software jaringan (bila diperlukan) dan juga aplikasi program. o Struktur database yang digunakan organisasi yang mengandung data operasional dan meta-data disebut schema. o Procedure, yaitu instruksi dan aturan yang mengatur rancangan dan kegunaan dari database. o People, antara lain : -
Data Administration DA lebih memperhatikan tahapan awal dari lifecycle. DA mengatur sumberdaya data, meliputi: perencanaan database, pengembangan dan
12 pemeliharaan standar, kebijakan, prosedur, dan desain database logikal dan konseptual. -
Database Administration DBA mengatur implementasi dari aplikasi database yang meliputi desain fisik database dan implementasi, pengaturan keamanan dan kontrol integritas, pengawasan performa sistem dan pengaturan ulang database.
-
Database designer (Logikal dan Fisikal)
-
Application programmer
-
End User o Naïve: User yang tidak perlu tahu mengenai DB dan DBM S. Hanya menggunakan program aplikasi. o Sophisticated: User yang familiar dengan struktur Database dan DBM S.
2.1.2.4 Analisis Database dan Teknik Desain 2.1.2.4.1
Database Application Lifecycle M enurut Connoly-Begg (2005, p283), database merupakan komponen
dasar sistem informasi, di mana pengembangan dan penggunaannya harus dilihat dari perspektif kebutuhan yang lebih luas dari organisasi. Tahapan database application lifecycle adalah:
13
Database planning
Sys tem definiti on
Requirement collec tion and anal ysis
Database design Conceptual databas e design DBMS selection (optional)
Applicati on design (optional) Logical database design
Physical databas e design
Prototyping (optional)
Impl ementation
Data c onversion and loading
Testing
Operati onal maintenanc e
Gambar 2.1 Database Application Lifecycle 1. Database Planning Database planning merupakan aktivitas manajemen yang memungkinkan tahapan-tahapan aplikasi database dapat direalisasikan seefisien dan seefektif mungkin. Database planning harus terintegrasi dengan keseluruhan strategi
14 sistem informasi. Ada tiga hal yang terlibat dalam penyusunan strategi sistem informasi: -
Identifikasi terhadap rencana dan sasaran usaha dengan rangkaian keputusan dari kebutuhan sistem informasi.
-
Evaluasi terhadap
sistem informasi yang sedang berjalan untuk
mengetahui kelebihan dan kekurangannya. -
Penafsiran terhadap peluang IT yang dapat memberikan keuntungan kompetitif.
2. System Definition System definition menjelaskan cakupan dan batasan dari aplikasi database dan user view utama. User view mendefinisikan apa yang dibutuhkan aplikasi database dari perspektif suatu peran kerja tertentu (misalnya Manager atau Supervisor) atau area aplikasi usaha (misalnya marketing, personnel, atau stock control). Suatu aplikasi database dapat memiliki satu atau lebih user view. M engidentifikasi user view merupakan aspek penting pada pengembangan aplikasi database karena membantu memastikan bahwa tidak ada user utama dari database tersebut yang terlupakan saat pengembangan atas kebutuhan untuk aplikasi baru. User view juga membantu pada pengembangan suatu aplikasi database yang relatif kompleks dengan memungkinkan kebutuhannya dibagi ke dalam bagian-bagian yang lebih mudah diatur.
15 3. Requirement Collection And Analysis Requirement collection and analysis merupakan proses pengumpulan dan penganalisaan informasi mengenai bagian dari organisasi yang didukung aplikasi database, dan penggunaan informasi tersebut untuk mengidentifikasi kebutuhan user pada sistem yang baru. Ada tiga jenis pendekatan untuk menangani kebutuhan aplikasi database dengan user view yang banyak: -
Pendekatan centralized Kebutuhan untuk masing-masing user view digabungkan ke dalam satu set tunggal kebutuhan tersebut untuk aplikasi database yang baru.
-
Pendekatan view integration Kebutuhan untuk masing-masing user view dibangun ke data model yang terpisah yang merepresentasikan user view tersebut. Hasil data model tersebut akan digabungkan kemudian dalam tahapan database design.
-
Kombinasi dari kedua jenis pendekatan tersebut
4. Database Design Database design adalah proses pembuatan rancangan untuk database yang mendukung operasi dan tujuan usaha. Ada dua jenis pendekatan dalam merancang database: -
Pendekatan bottom-up Pendekatan ini dimulai pada level dasar dari attribute (yaitu property dari entity dan relationship), di mana melalui analisa asosiasi antara attribute, dikelompokkan ke dalam relation yang merepresentasikan tipe entity dan relationship antara entity.
16 -
Pendekatan top-down Pendekatan ini dimulai dengan pengembangan data model yang berisi sedikit high-level entity dan relationship dan kemudian melakukan penyaringan top-down secara beruntun untuk mengidentifikasi lower-level entity, relationship, dan attribute terasosiasi.
Ada dua tujuan utama data modelling, yaitu untuk membantu dalam pemahaman arti (semantik) data dan untuk memfasilitasi komunikasi mengenai informasi yang dibutuhkan. Kriteria yang dibutuhkan untuk menghasilkan data model yang optimal: -
Structural validity
-
Simplicity
-
Expressibility
-
Nonredundancy
-
Shareability
-
Extensibility
-
Integrity
-
Diagrammatic representation
Database design terdiri dari tiga fase utama:
Conceptual database design Proses membentuk model informasi yang digunakan dalam suatu perusahaan, independen terhadap seluruh pertimbangan fisik.
17
Logical database design Proses membentuk model informasi yang digunakan dalam suatu perusahaan berdasarkan data model yang spesifik, tetapi independen terhadap suatu DBM S tertentu dan pertimbangan fisik lainnya.
Physical database design Proses menghasilkan deskripsi mengenai penerapan dari database pada secondary storage; hal itu menggambarkan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai pengaksesan data yang efisien, serta batasan integritas dan ukuran keamanan yang berhubungan.
5. DBMS Selection M emilih DBM S harus sesuai dengan yang dibutuhkan agar dapat mendukung aplikasi database dengan baik. Jika belum terdapat DBM S, saat DBMS selection yang paling tepat adalah antara fase conceptual database design dengan logical database design. Langkah utama dalam DBMS selection: a. M endefinisikan studi Terms of Reference b. M endaftarkan dua atau tiga produk c. M engevaluasi produk d. M erekomendasikan pilihan dan menghasilkan laporan 6. Application Design Application design merupakan rancangan user interface dan program aplikasi yang menggunakan dan memproses database. Pada sebagian besar kasus, application design tidak mungkin akan selesai sampai rancangan database itu sendiri telah ada. Di sisi lain, database muncul untuk mendukung aplikasi,
18 dan jadi harus ada alur pergerakan informasi antara application design dengan database design. 7. Prototyping Prototyping merupakan pembuatan model kerja suatu aplikasi database. Tujuan utama mengembangkan prototype adalah mengidentifikasi fitur mana pada sistem yang berjalan baik dan yang berjalan kurang baik; jika memungkinkan, memberikan peningkatan atau bahkan fitur baru pada aplikasi database. Dua strategi prototyping yang umum digunakan: -
Requirement prototyping Setelah kebutuhan terselesaikan, prototype dibuang.
-
Evolutionary prototyping Setelah kebutuhan terselesaikan, prototype tidak dibuang dan terus dikembangkan hingga menjadi aplikasi database yang dapat bekerja.
8. Implementation Implementation merupakan realisasi fisikal dari database design dan application design. Implementasi dari database dapat menggunakan Data Definition Language (DDL) dari DBM S yang dipilih atau Graphical User Interface (GUI), yang memberikan fungsionalitas yang sama ketika menyembunyikan low-level DDL statement. DDL statement digunakan untuk membuat struktur database dan file database kosong. User view yang telah ditentukan juga diimplementasikan pada tahap ini.
19 9. Data Conversion And Loading Data conversion and loading merupakan proses mentransfer data yang ada ke dalam database baru dan mengkonversi aplikasi yang ada agar dapat berjalan di database baru. Tahap ini diperlukan hanya jika database system yang baru menggantikan sistem yang lama. 10. Testing Testing merupakan proses mengeksekusi program aplikasi dengan tujuan untuk menemukan kesalahan. Testing harus dilakukan dengan strategi tes yang matang dan data yang realistis sehingga keseluruhan proses testing dapat secara metodikal dan secara kasar dilihat. Sebenarnya, testing tidak dapat menunjukkan
ketidakberadaannya
kesalahan;
testing
hanya
dapat
menunjukkan jika kesalahan itu muncul. 11. Operational Maintenance Operational maintenance merupakan proses memonitor dan memelihara sistem setelah instalasi dilakukan. Proses ini melibatkan: -
M emonitor performa sistem. Jika performa menurun, perbaikan dan pengaturan ulang database dilakukan.
-
M emelihara dan jika diperlukan meningkatkan kualitas aplikasi database. Kebutuhan yang baru tergabung ke dalam aplikasi database melalui tahapan yang sebelumnya dalam database application lifecycle.
20 2.1.2.4.2
Entity-Relationship Modeling
Konsep dasar ER Modeling: 1. Entity types Entity types merupakan kumpulan dari objek-objek dengan sifat (property) yang sama, yang diidentifikasi oleh perusahaan mempunyai eksistensi yang independen. Keberadaannya dapat berupa fisik maupun abstrak. Entity occurrence, yaitu pengidentifikasian object yang unik dari sebuah entity type. Setiap entitas diidentifikasikan dan disertakan propertynya. 2. Relationship types Relationship types merupakan kumpulan keterhubungan yang mempunyai makna antara entity type yang ada. Relationship occurrence, yaitu keterhubungan yang diidentifikasi secara unik yang meliputi keberadaan tiap entity type yang berpartisipasi. Derajat relationship dikelompokkan menjadi:
Binary relationship, keterhubungan antar dua entity types.
Ternary relationship, keterhubungan antar tiga entity types.
Quaternary relationship, keterhubungan antar empat entity types. Contohnya adalah Arranges. Relasi ini melibatkan 4 entity yaitu Buyer, Solicitor, Financial Institution dan Bid. Relasi ini menggambarkan Buyer, diberi masukan oleh Solicitor, dan didukung oleh Financial Institution, melakukan Bid.
Unary relationship, keterhubungan antar satu entity type, di mana entity type tersebut berpartisipasi lebih dari satu kali dengan peran yang berbeda.
21 Kadang disebut juga recursive relationship. Relationship dapat diberikan role names untuk meng-identifikasikan keterkaitan entity type dalam relationship. Contohnya adalah Staff yang berperan menjadi supervisor dan Staff yang di-supervisor-i. 3. Attributes M erupakan sifat-sifat (property) dari sebuah entity atau relationship type. Contohnya: sebuah entity Staff digambarkan oleh attribut staffNo, name, position dan salary. Attribute domain adalah himpunan nilai yang diperbolehkan untuk satu atau lebih atribut. Jenis-jenis atribut:
Simple attribute, yaitu atribut yang terdiri dari satu komponen tunggal dengan keberadaan yang independen dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi. Dikenal juga dengan nama atomic attribute.
Composite attribute, yaitu atribut yang terdiri dari beberapa komponen, dimana mas ing-masing komponen memiliki keberadaan yang independen. M isalkan atribut Address dapat terdiri dari street, city, postCode.
Single-valued attribute, yaitu atribut yang mempunyai nilai tunggal untuk setiap kejadian. M isalnya entitas Branch memiliki satu nilai untuk atribut branchNo pada setiap kejadian.
Multi-valued attribute, yaitu atribut yang mempunyai beberapa nilai untuk setiap kejadian. M isal entitas Branch memiliki beberapa nilai untuk atribut telpNo pada setiap kejadian.
Derived attribute, yaitu atribut yang memiliki nilai yang dihasilkan dari satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entitas.
22 2.1.2.5 Metodologi Perancangan 2.1.2.5.1
Conceptual Database Design M enurut Connolly-Begg (2005, p442), conceptual database design adalah
suatu proses membangun sebuah model dari informasi dari sebuah perusahaan dan sifatnya independen dari segala pertimbangan physical. Pertimbangan physical yang dimaksud adalah pertimbangan teknis mengenai
bagaimana
implementasi dari model informasi tersebut. Ada beberapa tahapan yang harus diikuti dalam conceptual database design yaitu sebagai berikut: 4. M engidentifikasi entity types Tahap ini adalah tahapan di mana kita mengidentifikasikan entity type utama yang dibutuhkan. Caranya adalah dengan memeriksa user’s requirement specification di mana kita mengidentifikasikan noun ataupun noun phrase dari dokumen tersebut. Setelah kita berhasil mengidentifikasi entity-entity type tersebut, maka langkah selanjutnya adalah memberi nama pada entity tersebut dan terakhir kita mendokumentasikan entity type teridentifikasi ke dalam suatu dokumen yang disebut dengan data dictionary. 5. M engidentifikasi relationship types Tahap ini adalah tahapan di mana kita mengidentifikasi relationship antar entity type yang telah teridentifikasi pada tahapan sebelumnya. Caranya adalah dengan menggunakan ER diagram untuk menggambarkan entity type dan hubungan antar entity tersebut karena dengan memvisualisasikannya dalam gambar maka akan membantu kita dalam menentukan relationship di antara entity type tersebut. Setelah kita menentukan relationship pada model
23 tersebut, maka selanjutnya kita menentukan multiplicity constraint dari relasi tersebut.
Multiplicity
constraint
berfungsi
untuk
memeriksa
dan
mempertahankan kualitas dari data. Langkah selanjutnya yang harus dilakukan adalah memeriksa model yang dibuat apakah mengandung fan traps ataupun chasm traps dan juga memastikan bahwa setiap entity dalam model terlibat paling tidak dalam satu relationship. Setelah relationship type teridentifikasi maka kita kembali menyimpannya dalam dokumen yang disebut data dictionary. 6. M engidentifikasi dan
menghubungkan attributes
dengan entity atau
relationship types Tahap ini adalah tahapan di mana kita menentukan atribut-atribut yang terkait dengan masing-masing entity dan relationship / hubungan antar entity. Atribut-atribut tersebut menggambarkan kepada kita mengenai bagaimana informasi nantinya tersimpan dalam database. Ada beberapa jenis atribut yaitu meliputi: a. Simple / composite attribute Composite attribute adalah atribut yang tersusun dari dua atau lebih simple attribute. Simple attribute itu sendiri adalah attribute yang yang berdiri sendiri. b. Single / multi-valued attribute Single-valued attribute adalah atribut yang hanya memiliki satu nilai tertentu untuk masing-masing entity occurrence, sedangkan pada multi-
24 valued attribute memungkinkan atribut bersangkutan memiliki lebih dari satu nilai untuk setiap entity occurrence. c. Derived attribute Derived attributes adalah atribut yang nilainya berasal dari hasil operasi nilai dari beberapa atribut dalam suatu entity. 7. M enentukan attribute domains Tahap ini adalah tahapan di mana kita mengidentifikasikan domain dari masing-masing atribut yang telah kita tentukan pada tahapan sebelumnya. Domain itu sendiri adalah sejumlah nilai yang dapat diterima (dianggap valid) oleh atribut yang bersangkutan. 8. M enentukan candidates and primary key attributes Tahap ini adalah tahapan di mana kita mengidentifikasikan candidate key untuk masing-masing entity type dan jika ada lebih dari satu candidate key, maka pilihlah satu di antaranya untuk menjadi primary key. Candidate key adalah kumpulan dari atribut pada suatu entity yang mengidentifikasikan secara unik kemunculan dari entity yang bersangkutan. Kita dapat mengidentifikasikan lebih dari satu candidate key pada suatu entity namun kita hanya dapat memilih salah satu untuk dijadikan sebagai primary key. Candidate keys yang tidak ditetapkan sebagai primary key disebut dengan alternate key.
25 9. M empertimbangkan kegunaan konsep enhanced modelling Tahap ini adalah tahapan di mana kita mulai mempertimbangkan untuk menggunakan konsep enhanced modelling seperti misalnya specialication, generalization, aggregation dan composition. 10. M emeriksa redundancy pada model Tahap ini adalah tahapan dimana kita mengidentifikasikan terjadinya redundancy data untuk kemudian menghapusnya bila terjadi. 11. M emvalidasi local conceptual model terhadap transaksi user Tahap ini adalah tahapan dimana kita memastikan bahwa local conceptual model yang dihasilkan telah benar-benar mendukung transaksi-transaksi yang akan terjadi kemudian. Bila kemudian model yang kita hasilkan mampu menghandle semua transaksi-transaksi tersebut, maka itu berarti bahwa model yang dihasilkan telah baik adanya dan siap dikembangkan ke level perancangan selanjutnya. Ada dua langkah untuk memastikan tahap ini terlaksana dengan baik yaitu pertama kita harus memeriksa ulang relasi yang bersifat one to one relationship dan langkah berikutnya adalah menghapus relationship yang berifat redundant. 12. M engkaji ulang local conceptual data model dengan user Tahap ini adalah tahapan dimana kita mengevaluasi local conceptual model yang dihasilkan dengan user untuk memastikan bahwa model tersebut telah sesuai dengan keinginan dan harapan user.
26 2.1.2.5.2
Logical Database Design M enurut Connolly-Begg (2005, p462), logical database design adalah
suatu proses membangun model untuk informasi yang digunakan dalam sebuah perusahaan berdasarkan suatu specific data model, tetapi masih belum memasukkan pertimbangan-pertimbangan physical dalam proses perancangannya. Ada 2 langkah yang harus dilakukan untuk menghasilkan logical data model yaitu sebagai berikut: 1. M embangun dan memvalidasi local logical data model untuk setiap view Langkah ini bertujuan untuk membangun sebuah local logical data model dari local conceptual data model yang menyajikan gambaran utuh perusahaan dan kemudian model tersebut divalidasi untuk memastikan bahwa secara struktural model tersebut sudah benar dan untuk memastikan bahwa model tersebut mendukung transaksi-transaksi yang terjadi pada perusahaan yang bersangkutan. Ada beberapa hal yang dilakukan pada langkah ini yaitu sebagai berikut: o M enghilangkan fitur yang tidak sesuai dengan relational model Tahapan ini bertujuan untuk memperbaiki local conceptual data model dengan menghilangkan fitur-fitur yang tidak compatible dengan relational model. Fitur-fitur pada local conceptual data model yang penting untuk dihilangkan adalah yaitu: 1. relasi many to many (*:*) pada binary relationship type 2. relasi many to many (*:*) pada recursive relationship type
27 3. relasi complex relationship type yang merupakan relasi yang dibangun oleh 3 atau lebih entity type 4. relasi multi-valued attribute (atribut yang memiliki lebih dari satu nilai) o M enurunkan relations untuk local logical data model Tahapan ini bertujuan untuk menghasilkan relasi-relasi untuk local logical data model yang merepresentasikan entity, relationship, dan atribut yang telah teridentifikasi sebelumnya. Ada beberapa hal dari conceptual model yang harus dibenahi untuk menghasilkan local logical data model yaitu: 1. Strong entity type Pada masing-masing strong entity type, maka akan dibuat suatu relation yang berisi atribut-atribut dari strong entity type tersebut. 2. Weak entity type Pada weak entity type juga akan muncul suatu relation yang berisi atribut-atribut dari weak entity type tersebut namun relation tersebut tidak memiliki primary key karena primary key tersebut diperoleh dari masing-masing owner entity. 3. One to many binary relationship type Pada jenis relationship tersebut akan ditentukan parent entity dan child entity dari relasi tersebut untuk kemudian menduplikasi primary key attribute dari parent entity ke dalam child entity di mana key tersebut akan disebut sebagai foreign key.
28 4. One to one binary relationship type dan one to one recursive relationship Pada one to one binary relationship type akan diselidiki secara lebih mendalam apakah kedua entity type yang terlibat dalam relasi perlu untuk disatukan atau tidak. 5. Superclass/subclass relationship type Pada jenis relationship tersebut maka kita akan menetapkan bahwa superclass entity merupakan parent entity dan subclass entity sebagai child entity. 6. Many to many binary relationship type Pada jenis relationship tersebut maka kita perlu menentukan satu entity type tambahan sebagai penengah antar kedua entity type dengan maksud agar relasi yang semula bersifat many to many akan berubah menjadi one to many. 7. Complex relationship type Pada jenis relationship tersebut maka kita perlu membuat satu relation baru yang merepresentasikan relationship tersebut dan kemudian memasukkan atribut-atribut dari relasi tersebut ke dalam relation yang terbentuk. 8. Multi-valued attributes Pada masing-masing multi-valued attribute maka akan dibuat satu entity baru yang merepresentasikan multi-valued attribute tersebut.
29 o M emvalidasi relations menggunakan normalization Tahapan ini bertujuan untuk memvalidasi relaton-relation yang terdapat pada logical data model menggunakan teknik yang disebut dengan normalisasi. Normalisasi ini merupakan proses untuk mengembangkan model supaya tidak terjadi duplikasi data dalam logical data model yang dibuat. o M emvalidasi relations terhadap transaksi user Tahapan ini bertujuan untuk memastikan bahwa relation pada local logical data model mendukung transaksi-transaksi yang terjadi. Di sini kita mencoba untuk memecahkan transaksi-transaksi yang kemungkinan akan terjadi dalam kondisi sesungguhnya dengan berpedoman pada model yang telah dibangun. Bila seluruh transaksi tersebut terpecahkan, maka berarti model yang telah dihasilkan telah memenuhi apa yang diharapan user. o M enentukan integrity constraints Tahapan ini bertujuan untuk menentukan integrity constraint. Integrity constraint itu sendiri merupakan constraint yang kita ingin hilangkan agar database kita terhindar dari inkonsistensi data. Ada beberapa integrity constraint yang akan dihilangkan pada tahap ini yaitu bahwa masingmasing atribut harus selalu memiliki nilai yang valid dan memiliki batasan-batasan nilai yang bisa diterima sebagai suatu nilai yang benar. Selain itu ada dua constraint lagi yang harus dihilangkan yaitu bahwa primary key pada masing-masing entity type tidak boleh bernilai NULL
30 dan bahwa masing-masing foreign key pada entity type memiliki pasangan nilainya pada parent relation. o M engkaji ulang local logical data model dengan user Tahapan ini bertujuan untuk memastikan bahwa local logical data model dan
supporting
documentation
yang
terbentuk
menggambarkan
representasi nyata yang diinginkan oleh user. 2. M embangun dan memvalidasi global logical data model Langkah ini bertujuan untuk menggabungkan beberapa local logical data model yang telah terbentuk pada langkah sebelumnya menjadi sebuah global logical data model yang merepresentasikan perusahaan secara keseluruhan. Setelah itu, maka model tersebut perlu divalidasi untuk memastikan kebenaran model yang dihasilkan. Ada beberapa hal yang dilakukan pada langkah ini yaitu sebagai berikut: a. M enggabungkan local logical data models ke dalam global model Tahapan ini bertujuan untuk menggabungkan masing-masing local logical data model yang telah terbentuk sebelumnya menjadi sebuah global logical data model. b. M emvalidasi global logical data model Seperti yang telah kita lakukan pada masing-masing local logical data model, maka pada global logical data model ini kita juga akan memvalidasi relation-relation yang terbentuk pada global logical data model dengan menggunakan teknik yang disebut normalisasi untuk
31 memastikan bahwa model tersebut mendukung transaksi-transaksi yang terjadi. c. M emeriksa untuk perkembangan di masa yang akan datang Pada tahap ini kita akan menentukan apakah ada perubahan-perubahan signifikan di masa yang akan datang dan untuk memperkirakan apakah global logical data model yang terbentuk dapat mengakomodasi perubahan-perubahan tersebut. d. M engkaji ulang global logical data model dengan users Pada tada tahap ini kita ingin memastikan apakah global logical data model yang terbentuk adalah representasi sesungguhnya dari perusahaan. 2.1.2.5.3
Physical Database Design M enurut Connolly-Begg (2005, p497), physical database design adalah
suatu proses menghasilkan sebuah deskripsi dari database pada secondary storage. Proses ini mendeskripsikan base relation, file organization, dan index yang digunakan untuk mencapai akses yang efisien pada data dan proses ini juga berfokus pada integrity constraint serta security. Pada physical database design terdapat beberapa langkah yang harus dilalui yaitu: 1. Translasi global logical data model untuk target DBMS Langkah ini bertujuan untuk menghasilkan relational database schema dari global logical data model sehingga dapat diimplementasikan dalam target DBMS. Ada beberapa tahapan dalam langkah pertama ini meliputi:
32 a. Design base relations Tahap ini bertujuan untuk merepresentasikan base relation yang teridentifikasi dalam global logical data model ke dalam target DBM S. b. Design representation of derived data Tahap ini bertujuan untuk menentukan bagaimana cara merepresentasikan derived data yang terdapat dalam logical data model ke dalam target DBMS. Derived data adalah data yang dihasilkan dari operasi yang dilakukan pada lebih dari satu data atribut. c. Design enterprise constraints Tahap ini bertujuan untuk merancang enterprise contraint pada target DBM S. Enterprise constraint ini penting untuk dirancang agar data yang ada pada database kita selalu dalam kondisi valid. 2. Design physical representation Langkah ini bertujuan untuk menentukan organisasi file yang optimal untuk menyimpan base relation yang terbentuk dan index-index yang dibutuhkan untuk mencapai performance yang bagus dimana merupakan cara relation dan tuple disimpan dalam secondary storage. Ada beberapa faktor penyebab kenapa kita perlu mengukur efisiensi organisasi file. Pertama adalah bahwa dalam implementasinya, transaksi pada sistem kita bisa berjumlah sangat banyak dan yang kedua adalah bahwa response time yang terkait dengan banyaknya transaksi dalam suatu waktu menjadi tolok ukur keberhasilan aplikasi yang kita buat. Terakhir adalah bahwa kita harus berusaha
33 meminimalisasi penggunaan disk storage. Ada beberapa tahap yang harus dilakukan pada langkah ini meliputi: a. Analisa transaksi Tahap ini bertujuan untuk mengerti kegunaan dan fungsi dari transaksitransaksi yang akan berlangsung pada database dan untuk menganalisa transaksi-transaksi yang penting. Hal ini penting agar kita dapat membuat perancangan database yang efektif. Kegiatan yang dilakukan pada tahap ini di antaranya adalah memetakan transaction path dari relation. Kemudian setelah itu kita memperkirakan frekuensi kemunculan record dalam suatu relation secara rata-rata dan maksimal serta juga memperkirakan frekuensi join yang akan terjadi antara relation yang satu dengan relation lainnya. b. M emilih file organizations Tahap ini bertujuan untuk menentukan organisasi file yang efisien untuk masing-masing base relation. Tahapan ini terkadang menjadi tidak terlalu krusial untuk dilakukan karena jarang sekali ditemukan DBM S yang memungkinkan kita untuk mengeset organisasi file dari DBM S tersebut. c. M emilih indexes Tahap ini bertujuan untuk menentukan apakah index diperlukan untuk meningkatkan performansi sistem. Index dapat meningkatkan performansi karena index memudahkan DBM S dalam mengambil data dalam setiap query yang dilakukan.
34 d. M engestimasi disk space requirements Tahap ini bertujuan untuk memperkirakan jumlah disk space yang diperlukan untuk database kita. 3. Design user views Langkah ini bertujuan untuk merancang user view yang diidentifikasi selama proses requirement collection and analysis. View ini penting artinya dalam kaitannya dengan security karena dengan kita mendesain view yang berbedabeda untuk masing-masing kelompok user, maka kita mencegah user untuk mengakses apa yang tidak seharusnya diakses. 4. Design security measures Langkah ini bertujuan untuk merancang security sistem dengan maksud untuk mempertahankan system security dan data security.
2.2 Teori Khusus 2.2.1 Terminologi Dasar dalam Proses Bisnis Perusahaan 2.2.1.1
Persediaan M enurut M ulyadi (2001, p553), sistem persediaan bertujuan untuk
mencatat tiap jenis persediaan yang disimpan di gudang. Sistem ini berkaitan erat dengan sistem penjualan, sistem retur penjualan, sistem pembelian, sistem retur pembelian, dan sistem akuntansi biaya produksi. 2.2.1.1.1
Jenis-jenis Persediaan M enurut Sofjan Assauri (1999, p221), persediaan yang terdapat di dalam
perusahaan dapat dibedakan menurut berbagai cara antara lain:
35 1. M enurut fungsinya, persediaan dapat dibedakan atas: a. Batch Stock atau Lot Size Inventory Adalah persediaan yang diadakan karena kita membeli atau membuat bahan-bahan atau barang-barang dalam jumlah yang lebih besar daripada jumlah yang dibutuhkan pada saat itu. Jadi dalam hal ini pembelian atau pembuatan yang dilakukan untuk jumlah yang besar, sedangkan penggunaan atau pengeluaran dalam jumlah kecil. Terjadinya persediaan karena pengadaan bahan atau barang yang dilakukan lebih banyak daripada yang dibutuhkan. b.
Fluctuation Stock Adalah persediaan yang diadakan untuk menghadapi fluktuasi permintaan konsumen yang tidak dapat diramalkan.
c. Anticipation Stock Adalah persediaan yang diadakan untuk menghadapi fluktuasi permintaan yang dapat diramalkan berdasarkan pola musiman yang terdapat dalam satu tahun dan untuk menghadapi penggunaan atau penjualan yang meningkat. 2. M enurut jenis dan posisi barang tersebut di dalam urutan pengerjaan produk, produksi dapat dibagi atas: a. Persediaan bahan baku Yaitu persediaan dari barang-barang berwujud yang digunakan dalam proses produksi. M isalnya kapas dipintal menjadi benang, benang diolah menjadi kain atau pakaian.
36 b. Persediaan bagian produk yang dibeli Yaitu persediaan barang-barang yang terdiri dari parts yang diterima dari perusahaan lain, yang dapat secara langsung di assembling dengan parts lain, tanpa melalui proses produksi sebelumnya. Jadi bentuk barang yang merupakan parts tidak mengalami perubahan dalam operasi. c. Persediaan barang-barang pembantu atau barang-barang pelengkap Yaitu persediaan barang-barang atau bahan-bahan yang diperlukan dalam proses produksi untuk membantu berhasilnya produksi atau yang dipergunakan dalam bekerjanya suatu perusahaan, tetapi tidak merupakan bagian atau komponen dari barang jadi. M isalnya minyak solar dan minyak pelumas adalah hanya merupakan bahan pembantu. d. Persediaan barang setengah jadi atau barang dalam proses Yaitu persediaan barang-barang yang keluar dari tiap-tiap bagian dalam satu pabrik atau bahan-bahan yang telah diolah menjadi suatu bentuk, tetapi lebih perlu diproses kembali untuk kemudian menjadi barang jadi. e. Persediaan barang jadi Yaitu persediaan barang-barang yang telah selesai diproses atau diolah dalam pabrik dan siap untuk dijual kepada pelanggan atau perusahaan lain. 2.2.1.1.2
Fungsi Persediaan
M enurut Sofjan Assauri (1999, p230), fungsi persediaan yang efektif adalah: 1. M emperoleh bahan-bahan 2. M enyimpan dan memelihara bahan-bahan dalam persediaan 3. Pengeluaran bahan-bahan
37 4. M eminimalisasi investasi dalam bentuk bahan atau barang 2.2.1.2
Pembelian M enurut M ulyadi (2001, p299), kegiatan pembelian digunakan dalam
perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Fungsi yang terkait dalam sistem pembelian adalah: 1. Fungsi pembelian Dalam sistem pembelian, fungsi ini bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan order pembelian kepada pemasok yang dipilih. 2. Fungsi penerimaan Bertanggung jawab untuk melakukan pemeriksaan terharap jenis, mutu, dan kuantitas barang diterima dari pemasok untuk menentukan dapat atau tidaknya barang tersebut diterima oleh perusahaan. 3. Fungsi gudang Bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang dan untuk menyimpan barang yang telah diterima oleh fungsi penerimaan. 4. Fungsi akuntansi Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi pencatat utang dan fungsi pencatat persediaan. Fungsi pencatat uang bertanggung jawab untuk mencatat transaksi pembelian ke dalam register bukti kas keluar dan untuk menyelenggarakan arsip dukungan sumber yang
38 berfungsi sebagai catatan utang atau menyelenggarakan kartu utang sebagai buku pembantu utang. Fungsi pencatat persediaan bertanggung jawab untuk mencatat harga pokok persediaan barang yang dibeli ke dalam kartu persediaan.
