BAB 2
LANDASAN TEORI 2.1 Teori – teori Dasar/Umum
2.1.1 Sistem
Konsep sistem mendasari seluruh proses bisnis serta pemahaman atas informasi dan teknologi. Konsep sistem akan membantu unutk menjelaskan konsep lainnya atas penggunaan teknologi, aplikasi, pengembangan, dan pengolahan.
Menurut Marakas (2008,p24) Sistem didefinisikan sebagai suatu set komponen yang saling terkait dengan batasan yang jelasdan bekerja sama untuk mencapai tujuan dengan menerima input dan memproduksi output dalam proses transformasi yang terorganisir. Menurut Sutarman (2009,p5) Sistem adalah kumpulan elemen yang saling berhubungan dan berinteraksi dalam suatu kesatuan untuk menjalankan suatu proses pencapaian suatu tujuan utama. Hal ini di pertegas oleh Eti Rochaety (2006,p2) yang menjelaskan Sistem adalah setiap kesatuan secara konseptual atau fisik yang terdiri dari bagian-bagian yang saling mempengaruhi. Jadi dapat disimpulkan sistem itu adalah sekelompok elemen yang saling berhubungan dan membentuk kesatuan atau bisa juga orang, mesin, dan metode yang dibutuhkan untuk menyelesaikan serangkaian fungsi.
2.1.2 Informasi
Informasi dan data saling berkaitan erat, dan dalam keseharian digunakan secara bergantian. Informasi digunakan dibanyak perusahaan yang berfungsi sebagai sumber pengetahuan bagi perusahaan dalam mengambil keputusan bisnis.
Menurut Laudon(2007,p381) informasi didefinisikan sebagai data yang diolah menjadi bentuk yang dapat dimengerti dan berguna bagi manusia. Hal ini di pertegas oleh Marakas (2008,p579) yang menyebutkan informasi didefinisikan sebagai data yang ditempatkan dalam konteks yang bermaknadan berguna untuk pengguna akhir. Jadi dapat disimpulkan informasi itu adalah hasil akhir dari sebuah proses pengolahan data yang dapat digunakan pengetahuan yang dapat dimanfaatkan perusahaan dan banyak orang.
2.1.3 Data
Sejarahnya data disebut sebagai fakta-fakta tentang objek dan peristiwa yang dapat direkam dan disimpan paa media komputer.
Menurut Indrajani (2008,p48) data merupakan fakta mentah tentang orang, tempat, kejadian, dan apapun yang penting bagi perusahaan yang harus dikontrol dan dikelola untuk menghasilkan suatu informasi yang memiliki arti bagi perusahaan. Menurut Laudon (2007,p375) data merupakan kumpulan fakta-fakta kasar yang menunjukan kejadian yang terjadi dalam organisasi atau lingkungan fisik sebelum fakta tersebut diolah dan ditata menjadi bentuk yang dipahami. Hal ini di pertegas oleh Harlinda (2008,p372) yang menyebutkan data merupakan representasi fakta dunia yang mewakili suatu objek seperti manusia, barang, peristiwa, konsep dan sebagainya yang direkam dalam gambar ataupun kombinasinya. Jadi dapat disimpulkan data itu adalah, kumpulan dari objek dan peristiwa yang akan dikontrol dan dikelola yang disimpan untuk kemudian menjadi sebuah informasi.
2.1.4 Basis Data
Dalam dua dekade terakhir ini Basis Data banyak digunakan dan semakin berkembang. Basis Data apat digunakan sebagai menyimpan, memanipulasi, dan menerima data dari semua tipe bisnis seperti misalnya : perusahaan, bidan kesehatan, pemerintahan, dan perpustakan.
Menurut O’Brien (2005,p696) Basis Data adalah kumpulan terpadu dari elemen data logis yang saling berhubungan. Basis data mengonsolidasi banyak catatan yang sebelumnya disimpan dalam file terpisah. Dipertegas oleh Fadil, Firdausy, & Hermawan (2008,p70) Basis Data adalah sekumpulan file-file yang saling berelasi.Cahyono (2009,p83) juga menegaskan bahwa Basis Data adalah satu komponen sistem informasi yang mempunyai posisi yang sangat menentukan dalam menunjang keberhasilan suatu sistem informasi. Jadi dapat disimpulkan Basis Data itu adalah koleksi dari data terkait yang formatnya standart dan dirancang untuk bisa diakses beberapa pengguna.
2.1.5 Database Administrator
Dalam pengolahan Basis Data, tentu dibutuhkan tenaga kerja yang mempunyai keterampilan dalam mengolah data-data tersebut.Itulah yang disebut dengan Database Administrator.
Menurut Harlinda (2008,p377) Database Administrator dapat disimpulkan sebagai orang yang mempunyai kekuasaan sebagai pusat pengontrol terhadap seluruh sistem baik data maupun program. Kroenke (2006,p648) juga menjelaskan bahwa Database Administrator didefinisikan sebagai orang atau sekelompok yang merespon peraturan dan prosedur untuk mengontrol dan melindungi basis data. Bertugas juga untuk
mengolah data, melakukan perawatan terhadap Database. Jadi dapat disimpulkan database administrator itu adalah seorang pakar yang bertanggung jawab untuk memelihara standart untuk pengembangan, pemeliharaan, dan keamanan database organisasi.
2.1.6 Database Management System
Menurut Connolly dan Begg (2010,p66), Database Management System adalah sistem software yang memungkinkan user untuk, menjelaskan, membuat, memaintain, dan mengontrol akses ke database.
DBMS menyediakan fasilitas seperti :
a. Memungkinkan para pengguna untuk mendefinisikan database, dengan Data Definition Language (DDL). DDL memperbolehkan para penggunanya dalam menentukan struktur jenis data, dan batasan data yang akan disimpan pada database. b. Memungkinkan pengguna dapat memasukan, memperbaharui, menghapus, dan memulihkan data dari database melalui DataManipulation Languange (DML).
c. Menyediakan akses kendali dalam database seperti :
a. Security System : sistem yang digunakan untuk mencegah orang yang tidak memiliki hak akses data untuk mengakses data tersebut. b. Integrity System : sistem yang memelihara konsistennya suatu data. c. Concurrency Control System : sistem yang membagi akses kedalam
database.
d. Recovery Control : penyimpan database cadangan untuk mengembalikan keadaan semula jika terjadi kerusakan.
e. User-Accessible Catalog : isi deskripsi data yang ada dalam database.
Menurut Hartmann dan Link (2012) dalam jurnalnya mengatakan Database Management System dapat digunakan untuk mengelola koleksi informasi secara bersamaan, dapat diandalkan, efektif, efisiensi.
Gambar 2.1 Komponen DBMS. (Connolly dan Begg (2010,p68 ) DBMS memiliki lima komponen penting yaitu :
1. Hardware
Hardware dapat berupa PC, mainframe tunggal, dan jaringan antar komputer. 2. Software
Komponen software terdiri dari software DBMS sendiri dan program aplikasi, bersama dengan sistem operasi pada komputer dan perangkat jaringan jika sebuah DBMS diakses melalui sebuah jaringan.
3. Data
Komponen yang paling utama dalam sebuah DBMS adalah data. Tanpa adanya data, DBMS tidak akan dapat digunakan atau dimanfaatkan.
4. Procedure
Merupakan sebuah instruksi yang mengatur desain dan pengunaan database. Pengguna sistem yang mengelola database membutuhkan prosedur yang terdokumentasi tentang bagaimana cara menggunakan atau menjalankan sistem tersebut. Seperti instruksi untuk :
a. Masuk ke dalam DBMS. b. Menggunakan fasilitas DBMS. c. Memulai dan memastikan DBMS. d. Membuat data cadangan dari database.
e. Menangani kegagalan hardware atau software. f. Mengubah struktur table data.
5. User
Komponen akhir yang tentunya dibutuhkan adalah pengguna dari sistem yang dibuat.Pengguna sistem yang menjadi komponen penggerak dari DBMS yang sudah disediakan.
2.1.7.1 Keuntungan penggunaan DBMS Keuntungan DBMS adalah sebagai berikut :
1. Kontrol atas redudansi. 2. Konsistensi data.
4. Data dapat dibagikan. 5. Meningkatkan integasi data. 6. Meningkatkan keamanan data.
7. Meningkatkan aksesbilitas dan respon data 8. Meningkatkan produktivitas
9. Meningkatkan layanan backup dan recovery
2.1.7.2 Kerugian DBMS
Kerugian DBMS adalah sebagai berikut : 1. Kompleksitas
2. Ukuran
3. Biaya dari penggunaan DBMS 4. Biaya konversi
5. Kinerja
6. Dampak yang tinggi dari kegagalan
2.1.7.3 Fungsi DBMS
DBMS sendiri juga memiliki fungsi – fungsi sebagai berikut :
a) Data Storage, retrieval, dan update
Sebuah DBMS harus menyediakan kemampuan untuk menyimpan, penelusuran kembali, dan mengubah data dalam basis data bagi pengguna.
b) A user-accessible catalog
DBMS harus menyediakan katalog yang menjelaskan lokasi penyimpanan data dalam basis data.
c) Transaction support
DBMS juga harus menyediakan mekanisme kegiatan update yang berhubungan dengan transaksi.
d) Concurrency control service
DBMS juga menyediakan mekanisme agar basis data diperbaharui dengan benar ketika beberapa pengguna melakukan update basis data secara bersamaan. e) Recovery service
Menyediakan mekanisme untuk perbaikan basis data yang rusak jika terjadi sebuah kesalahan atau hal yang tak terduga
Menyediakan mekanisme yang menjamin hanya pengguna yang diberi otoritas tertentu saja yang dapat mengakses basis data yang penting.
g) Support for data communication
DBMS harus dapat terintegrasi dengan software yang berhubungan dengan komunikasi data.
h) Integrity service
Menyediakan jaminan bahwa data dalam basis data, keduanya telah mengikuti aturan yang benar.
i) Service to promote data independence
DBMS meliputi fasilitas–fasilitas yang mendukung program independensi dari struktur basis data yang aktual.
j) Utility service
DBMS menyediakan utility service agar basis data dapat di administrasi dengan baik.
2.1.8 Database Definition Language (DDL)
Menurut Connolly dan Begg (2010,p92), database definition language merupakan bahasa yang memungkinkan DBA atau user untuk mendeskripsikan dan memberi nama dari entitas, attribute dan relationships yang diperlukan untuk aplikasi, bersamaan dengan beberapa associated integrity dan securityconstraints.
2.1.9 Database Manipulation Language (DML)
Menurut Connolly dan Begg (2010,p92), database manipulation language merupakan bahasa yang menyediakan satu set operasi untuk mendukung basic data manipulation operasi dalam data yang diadakan di database.
2.1.10 Database Planning
Menurut Connolly & Begg (2005,p299-p2301), perancangan aplikasi (application design) adalah merancang antarmuka pemakai (user interface) dan program aplikasi yang akan memproses basisdata. Ditinjau dari gambar 2.1 bahwa, perancangan basisdata dan perancangan aplikasi adalah aktivitas bersamaan pada database application lifecycle. Dalam kasus sebenemya, adalah tidak mungkin untuk menyelesaikan perancangan aplikasi sebelum perancangan basisdata selesai.
Dalam perancangan aplikasi harus memastikan semua pertanyaan fungsional dari spesifikasi kebutuhan pemakai (user requirement specification) yang menyangkut perancangan aplikasi program yang mengakses basisdata dan merancang transaksi yaitu cara akses ke basisdata dan perubahan terhadap isi basisdata (retireve, update dan kegiatan keduanya). Artinya bagaimana fungsi yang dibutuhkan bisa terpenuhi dan merancang antarmuka pemakai (user interface) yang tepat. Antarmuka yang dirancang harus memberikan informasi yang dibutuhkan dengan cara menciptakan 'user-friendly'. Kebanyakan antarmuka pemakai yang diabaikan akan niscaya membuat masalah. Bagaimanapun, antarmuka pemakai harus diakui sebagai komponen dari sistem yang penting, dimana agar mudah dipelajari dan mudah digunakan, sehingga pemakai akan cenderung memberdayagunakan informasi yang disajikan.
2.1.11 System Definition.
Spesifikasi dari lingkup dan batas dari database system, termasuk major user view, user, dan area aplikasi. User view mendefinisikan apa yang dibutuhkan dalam aplikasi basis data yang berhubungan dengan data dan menampilkan transaksi dalam data.
Menurut Connoly dan Beg (2005,p286), definisi sistem (system definition) adalah proses yang memaparkan jangkauan dan batasan dari aplikasi basis data dan pandangan - pandangan utama para pemakain. Sebelum mendesain Suatu alokasi basis data penting untuk terlebih dahulu. mengidentifikasikan batasan - batasan dari sistem yang sedang diteliti dan bagaimana kaitannya dengan bagian lain sistem informasi perusahaan. Perlu dipikirkan untuk kebutuhan yang akan datang selain dari keadaan saat ini. Dan tak lupa untuk mengidentifikasi pandangan pemakai yang merupakan aspek penting dari pengembangan aplikasi basis data yang merupakan aspek penting dari pengembangan aplikasi basis data karena membantu untuk memastikan bahwa tidak ada pemakai utama basis data yang terlupa ketika pengembangan aplikasi baru tersebut.
2.1.12 Requirements Collection and Analysis
Proses mengumpulkan dan analisis informasi tentang bagian dari organisasi yang dapat didukung oleh aplikasi basis data, dan menggunakan informasi tersebut
untuk mengindetifikasi kebutuhan pengguna dari sistem baru. Banyak tehnik yang dapat dilakukan untuk mengumpulkan informasi tersebut, disebut tehnik fact finding.
Menurut Connolly dan Begg (2005,p288-291), analisis dan pengumpulan kebutuhan (requerment collection and analysis) adalah sebuah proses pengumpulan dan analisis informasi tentang bagian dari perusahaan proses pengumpulan dan analisis informasi tentang bagian dari perusahaan yang akan didukung oleh aplikasi basis data, dan menggunakan informasi ini untuk mengidentifikasi kebutuhan pemakai terhadap sistem baru.
Informasi yang dikumpukan termasuk :
1. Penjabaran dari data yang digunakan,
2. Detail mengenai bagaimmana data digunakan,
3. Kebutuhan tambahan apapun untuk aplikasi basis data yang baru.
Informasi ini kemudian dianalisis untuk mengidentufikasikan kebutuhan yang dimasukan untuk aplikasi basis data yang baru tersebut. Ada tiga macam pendekatan untuk mengatur kebutuhan dari sebuah aplikasi basis data dengan berbagai pemakai, yaitu :
1. Pendekatan Centralized
Kebutuhan untuk tiap pandangan pemakai disatukan menjadi satu set kebutuhan untuk aplikasi basis data. Umunmya pendekatan ini dipakai jika basis datanya tidak terlalu kompleks.
2. Pendekata View Integration
Kebutuhan untuk itap pandangan pemakai digunakan untuk membangun sebuah model yang terpisah yang mempretasikan tiap pandangan pemakai tersebut. Hasil data-data model tersebut kemudian di satukan dibagian desain basis data
3. Kombinasi keduanya
Menurut Connolly dan Begg (2010, p322), tahapan setelah data modeling di dalam database design adalah selanjutnya diikuti olehtiga tahapan dalam merancang basis data. Tahapan – tahapan tersebut antara lain adalah
Conceptual Database Design
Conceptual database design merupakan suatu proses dalam membangun model data yang digunakan di dalam perusahaan, dapat berdiri sendiri dari semua pertimbangan fisikal. Hal ini diperkuat oleh pendapat Connolly dan Begg (2010, p470) yang mengatakan bahwa perancangan konseptual merupakan proses membangun model data yang digunakan oleh suatu perusahan, bebas dari segala pertimbangan – pertimbangan.Langkah pertama dari perancangan basis data dinamakan sebagai conceptual database design yang melibatkan pembentukan permodelan konseptual dari bagian perusahaan yang memang menjadi fokus dari perancangan basis data.Menurut Connolly dan Begg (2010, p323), perancangan konseptual merupakan implementasi dari perangkat DBMS, program aplikasi, bahasa pemrograman, perangkat keras, serta pertimbangan – pertimbaSngan yang berbentuk fisik lainnya. Keseluruhan dari proses pengembangan permodelan konseptual adalah model yang sudah dites dan divalidasi berdasarkan kebutuhan pengguna sistem.
Menurut Connolly dan Begg (2010, p471-485), langkah – langkah dalam membangun model data konseptual yaitu :
Langkah 1 Membangun Model Data Konseptual Langkah 1.1 Identifikasi tipe entitas
Langkah pertama dalam membangun model data konseptual lokal adalah menentukan objek- objek utama atau mengidentifikasikan entitas – entitas yang diperlukan oleh pengguna.Konsep utama di dalam perancangan model ER adalah dengan menentukan tipe entitas yang merepresentasikan sekelompok objek “dunia nyata” yang mempunyai properti yang sama. Diperkuat di dalam bukunya, Connolly dan Begg (2010, p372) mengatakan tipe entitas adalah sekumpulan objek dengan properti yang sama, dimana diidentifikasikan oleh perusahaan yang mempunyai eksistensi independen.Contoh tipe entitas dapat dilihat pada gambar 2.9
Gambar 2.1 Tipe Entitas
Sumber : Connolly dan Begg(2010, p374)
Langkah 1.2 Identifikasi hubungan (relationship)
Identifikasi hubungan (relationship) disini maksudnya adalah mengidentifikasi hubungan – hubungan (relationship) yang penting antara entitas – entitas yang ditemukan pada tahap sebelumnya. Entity - Relationship Modelling digunakan untuk menggambarkan entitas dan hubungannya. Dalam tahap ini juga ditentukan batasan multiplicity dari relationship tersebut dan pengecekan adanya fan atau chasm traps dalam model tersebut. Setelah itu baru dilakukan dokumentasi relationship.
a. Fan Traps terjadi dimana model yang merepresentasikan suatu hubungan antar entitas, tetapi alur relasinya memperlihatkan ambiguitas.
b. Chasm Traps terjadidimana model menggambarkan keadaan dari hubungan antara entitas yang satu dengan yang lainnya, tetapi tidak ada hubungan antara kedua entias yang utama.
Setelah menentukan tipe entitas maka langkah selanjutnya adalah menentukan tipe hiubungan antar entitas tersebut. Menurut Connolly dan Begg (2010, p374), tipe hubungan yang dimaksud adalah sekumpulan asosiasi yang mempunyai makna antar setiap jenis entitasnya. Contoh pendekatan view integration dapat dilihat pada gambar 2.10
Sumber : Connolly dan Begg(2010, p376)
Langkah 1.3 Identifikasi dan hubungkan atribut – atribut dengan tipe entitas atau relasi (relationship)
Menghubungkan atribut – atribut dengan entitas atau relationship yang tepat. Mengidentifikasi simple/composite attributes, single valued/ multi-valued attributes, dan derived attributes.
Tipe entitas dari properti khusus biasa disebut sebagai atribut. Menurut Connolly dan Begg (2010, p379), atribut memegang nilai – nilai yang mendeskripsikan kejadian entitas dan merepresentasikan bagian utama dari data yang disimpan di dalam basis data. Atribut sendiri merupakan properti dari tipe entitas atau hubungan. Tipe hubungan yang menghubungkan beberapa entitas dapat mempunyai atribut yang sama dari tipe entitas mereka sendiri. Setiap atribut yang berhubungan dengan sekumpulan nilai – nilai disebut sebagai domain. Pernyataan ini diperkuat oleh Connolly dan Begg(2010, p379), yang menyatakan bahwa sekumpulan dari nilai – nilai yang ada dari satu atau beberapa atribut dikatakan sebagai domain atribut.
Menurut Connolly dan Begg (2010, p380), atribut sendiri dapat diklasifikasikan menjadi tiga bagian yaitu
1. Atribut sedehana dan atribut gabungan (Simple and composite attribute)
- Atribut sederhana (simple attribute) adalah atribut yang terdiri dari komponen tunggal dengan keberadaan atribut yang independen. Atribut sederhana tidak dapat dibagi lagi ke dalam komponen yang lebih kecil. Sebagai contoh : atribut posisi dari entitas karyawan.
- Atribut gabungan (Composite attribute)adalah atribut yang terdiri dari beberapa komponen dengan keberadaan atribut yang independen. Beberapa atribut yang merupakan atribut gabungandapat dibagi lagi ke dalam komponen yang lebih kecil dengan eksistensi independen atribut itu sendiri.
Sebagai contoh : atribut alamat(Gang Keluarga, Jakarta Barat, 11480) dari entitas pelanggan yang dapat dibagi lagi ke dalam komponen yang lebih kecil yaitu atribut jalan untuk gang keluarga, atribut kota untuk jakarta barat dan atribut kode pos untuk 11480.
2. Atribut nilai tunggal dan atribut nilai ganda(Single-valued and multi-valued attributes)
Atribut nilai tunggaladalahatribut yangmemegangnilai tunggaluntuk setiapterjadinya suatuentitastipe.Sedangkan atribut nilai gandaadalah sebuah atribut yang mempunyai nilai – nilai ganda untuk setiap kejadian dari tipe entitas.
3. Atribut turunan (Derived attributes)
Atribut turunanadalah atribut yang merepresentasikan nilai yang didapat dari nilai atribut yang berhubungan, tetapi tidak dalam kondisi yang sama untuk tipe entitasnya. Contoh atribut turunan adalah umur yang didapat atau merupakan turunan dari tanggal lahir, bulan, dan tahun.
Langkah 1.4 Menentukan domain atribut
Menentukan wilayah atribut dalam model konseptual. Yang dimaksud wilayah adalah sekumpulan nilai – nilai dimana suatu atribut menggambarkan nilainya. Contoh : nilai yang mungkin untuk atribut jenis kelamin dari entitas karyawan adalah ‘M’ atau ‘F’, wilayah dari atribut ini adalah single character string yang berisi nilai ‘M’ atau ‘F’. Setelah itu, dilakukan dokumentasi domain atribut.
Langkah 1.5 Menentukan atribut candidate, primary, dan alternatekey
Mengidentifikasi candidate key untuk tiap – tiap entitas dan jika ada lebih dari suatu candidate key , pilih salah satu untuk menjadi primary key, dan lainnya menjadi alternate key.Diperkuat dengan pendapat Connolly dan Begg (2010, p381), yang mengatakan bahwa kunci relasimerupakan sekumpulan atribut kecil yang secara unik mengidentifikasikan setiap kejadian dari tipe entitas yang ada. Kunci relasidibagi menjadi beberapa jenis yaitu :
- Kunci kandidat (candidate key)
Suatu atribut atau sekumpulan atribut yang mengidentifikasikan secara unik suatu kejadian spesifik dari suatu entitas.
- Kunci primer (Primary key)
Suatu atribut atau sekumpulan atribut yang tidak hanya mengidentifikasikan secara unik suatu kejadian spesifik, tetapi juga terpilih sebagai kunci primer. - Kunci altenatif (Alternative key)
Kunci kandidat yang tidak terpilih sebagai kunci primer
Langkah 1.6 Mempertimbangkan penggunaan enchanced modelling concept (langkah opsional)
Mempertimbangkan penggunaan konsep permodelan, seperti specialization / generalization, aggregation, dan composition.
a. Specialization, adalah proses memaksimalkan perbedaan antara anggota entitas dengan mengidentifikasikan karakteristik yang membedakan seluruh entitas. b. Generalization, adalah proses meminimalkan perbedaan antara entitas dengan
mengidentifikasikan karakteristik yang sama dari masing – masing entitas. c. Aggregation, adalah mempresentasikan hubungan ‘has -a’ atau ‘is-part-of’
antara tipe - tipe entitas , dimana salah satu adalah sebagai ‘whole’ dan yang lainnya sebagai ‘part’.
d. Composition, adalah sebuah bentuk spesifik dari aggregation yang mempresentasikan penggabungan antara entitas dimana ada kepemilikan yang kuat dan kesamaan lifetime antara ‘whole’ dan ‘part’.
Langkah 1.7 Memeriksa model akan adanya redudansi
Memerika keberadaan redudansi dalam model. Dilakukan pemeriksaan secara spesifik terhadap hubungan one-to-one (1:1), menghilangkan hubungan (relationship) yang redudan, dan mempertimbangkan penggunaan dimensi waktu.
Langkah 1.8 Validasi model data konseptual terhadap transaksi pengguna
Memastikan bahwa konseptual data telah mendukung transaksi yang dibutuhkan. Hal ini dapat dilakukan dua cara yaitu :
a. Mendeskripsikan transaksi secara detail, dengan pendekatan ini berarti akan diperiksa semua informasi (entitas, relationship, dan atributte) yang dibutuhkan oleh setiap transaksi apakah telah disediakan dalam model, dengan mendokumentasikan setiap kebutuhan transaksi.
b. Menggunakan jalur transaksi (transaction pathways), pendekatan ini digunakan untuk validasi model data terhadap transaksi yang dibutuhkan termasuk representasi diagram jalur yang digunakan oleh setiap transaksi langsung pada diagram ER.
Setelah requirement collection dan analisis tahapan alur hidup sistem basis data telah selesai dan sudah mendokumentasikan pemenuhan kebutuhan – kebutuhan pengguna yang nantinya digunakan untuk perancangan sistem basis data, maka hal tersebut bisa dikatakan telah siap untuk merancang sistem basis data. Aspek yang sulit dalam melakukan perancangan basis data adalah bagaimana seorang perancang data, programmer serta pengguna akhir bisa melihat data dan menggunakannya dengan caranya sendiri. Kesulitan tersebut akan menimbulkan masalah dalam memenuhi standar kebutuhan pengguna sistem.
Entity-Relationship (ER) Model merupakan solusi dari permasalahan yang terjadi.Menurut Connolly dan Begg (2010, p371), Entity-Relationship Modeling adalah pendekatan top-down di dalam perancangan basis data yang melakukan identifikasi data – data penting yang sering disebut sebagai entitas dan hubungan diantara data yang harus direpresentasikan di dalam model. Setelah menentukan entitas dan hubungan maka langkah selanjutnya adalah menambahkan informasi detail untuk entitas dan hubungan tersebut yang disebut sebagai atribut dan konstrain di dalam entitas, hubungan, dan atribut. Contoh Entity-Relationship Diagram dapat dilihat pada gambar 2.3
Gambar 2.3 An Entity-Relationship (ER) Diagram Sumber : Connolly dan Begg(2010, p373)
Langkah 1.9 Review model data konseptual dengan pengguna
Memeriksa model data konseptual dengan pengguna sistem untuk memastikan bahwa model data tersebut secara tepat menggambarkan transaksi dan kebutuhan data secara nyata dalam perusahaan.
Logical Database Design
Menurut Connolly dan Begg (2010, p323), permodelan data logikal berdasarkan tujuan permodelan data untuk basis data, sebagai contoh : permodelan relasional (the relational data model). Di dalam perancangan logikal terdapat teknik normalisasi untuk mengetes akan kebenaran dari permodelan data logikal tersebut.Logical database design merupakan proses membangun model data yang digunakan di dalam perusahaan berdasarkan model data yang spesifik lanjutan dari tahap pertama conceptual database design. Hal ini diperkuat oleh pernyataan Connolly dan Begg (2010, p490)yang menyatakan bahwa membangun model data logikal untuk mengartikan model data konseptual ke dalam model data logikal dan memvalidasi model untuk mengecek secara struktur basis data dengan benar serta mampu untuk mendukung transaksi yang dibutuhkan.
Menurut Connolly dan Begg (2010, p490-p517), langkah – langkah dalam membangun model data logikal adalah sebagai berikut :
Langkah 2 Membangun dan Memvalidasi Model Data Logikal Langkah 2.1 Membuat relasi untuk model data logikal
Membuat relasi dari model data konseptual untuk merepresentasikan entitas, relationship, dan atribut – atribut yang telah teridentifikasi. Tabel dibawah ini menunjukan bagaimana memetakan entitas, hubungan (relationship) dan atribut sebuah relasi. Dokumentasikan relasi dan atribut foreign key dan juga dokumentasikan primary key atau alternate key baru yang muncul dari hasil proses penurunan relasi.
Tabel 2.1 Pemetaan Entitas, Relationship, dan atribut sebuah Relasi Sumber : Connolly dan Begg(2010, p500)
Strong entity Membuat relasi yang menyertakan semua atribut simple
Weak entity Membuat relasi yang menyertakan semua
atribut simple (primary key masih harus ditentukan setelah relasi dengan tiap – tiap entitas yang telah dipetakan)
1:* (one-to-many) binary relationship Menyertakan primary key entitas pada sisi ‘one’ sebagai foregin key pada relasi yang menggambarkan entitas ‘many’ juga disertakan pada entitas ‘ many’ 1:1 (one-to-one) binary relationship
a) kewajiban partisipasi di dua sisi b) kewajiban partisipasi di satu sisi c) Pilihan partisipasi di dua sisi
Mengkombinasikan entitas – entitas menjadi satu relasi. Menyertakan primary key entitas pada sisi ‘optional’ pada relasi yang menggambarkan entitas pada sisi ‘mandatory’. Berubah – ubah tergantung informasi lebih lanjut mengenai partisipasi entitas.
Superclass / subclass relationship Lihat tabel 2.3 pada halaman 42 *.* (many-to-many) binary relationship,
complex relationship
Membuat relasi untuk menggambarkan relationship tersebut. sertakan duplikasi primary keys dari masing – masing owner ke dalam relasi baru untuk berperan sebagai foreign key.
Multi-valued attribute Membuat relasi untuk menggambarkan atribut multi-valued dan menyertakan duplikat primary key dari masing – masing owner entitas ke dalam relasi baru untuk berperan sebagai foreign key
Penjelasan tabel 2.2 Pemetaan Entitas, Relationship, dan atribut sebuah Relasi adalah
sebagai berikut :
1. Tipe Entitas Kuat dan Tipe Entitas Lemah
Menurut Connolly dan Begg (2010, p334), tipe entitas diklasifikasikan menjadi dua jenis yaitu : tipe entitas kuat dan tipe entitas lemah.
a. Tipe Entitas Kuat
Tipe entitas kuat adalah jenis entitasyang tidaktergantungpada beberapa jenisentitaslainnya.
b. Tipe Entitas Lemah
Tipe entitas lemah adalah jenis entitasyang tergantungpada beberapa jenisentitaslainnya.
Contoh tipe entitas kuat dan tipe entitas lemah dapat dilihat pada gambar 2.12
Gambar 2.4 Strong and weak entity types Sumber : Connolly dan Begg (2010, p384)
2. Batasan struktural
Multiplicity adalah jumlah kejadian yang mungkin terjadi pada sebuah tipe entitas yang berhubungan ke sebuah occurrence dari tipe entitas lain pada suatu relasi. Terdapat tiga macam hubungan binary secara umum, seperti terlihat pada gambar 2.13
Gambar 2.5 Multiplicity
a. Derajat hubungan one - to - one (1:1)
Derajat hubungan (1:1) terjadi apabila tiap anggota suatu entitas hanya boleh berpasangan dengan satu anggota dari entitas yang lain. Begitu juga sebaliknya, anggota dari entitas lain hanya boleh mempunyai satu anggota dari entitas tersebut.
Gambar 2.6 Multiplicity dengan tipe relasi 1:1 Sumber : Connolly danBegg(2010, p391)
b. Derajat hubungan one – to – many (1:*)
Derajat hubungan (1:*) terjadi apabila tiap anggota suatu entitas memiliki lebih dari satu anggota dari entitas yang lain. Begitu juga sebaliknya, anggota dari entitas yang lain hanya boleh berpasangan dengan satu anggota dari entitas tersebut.
Gambar 2.7 Multiplicity dengan tipe relasi 1:* Sumber : Connolly dan Begg(2010, p388)
c. Derajat hubungan many-to-many (*:*)
Derajat hubungan (*:*) terjadi apabila tiap anggota suatu entitas memiliki lebih dari satu anggota dari entitas yang lain dan juga entitas yang lain memiliki lebih dari satu anggota dari entitas tersebut.
Gambar 2.8Multiplicity dengan tipe relasi *:* Sumber : Connolly dan Begg(2010, p389)
Tabel 2.2 Representasi dari superclass/sublcass relationship berdasarkan pada partisipasi dan disjoint constraints
Sumber : Connolly dan Begg (2010, p496)
Batasan Partisipasi Disjoint Constraint Pemetaan Relasi
Mandatory Nondisjoint {And} Relasi tunggal (dengan satu atau lebih diskriminator untuk membedakan tipe relasi) Optional Nondisjoint {And} Dua relasi: satu relasi
untuk superclass (dengan satu atau lebih). Sublcass (dengan satu atau lebih diskriminator untuk membedakan tipe relasi). Mandatory Disjoint {or} Banyak relasi: satu relasi
untuk tiap – tiap kombinasi superclass / subclass
Optional Disjoint {or} Banyak relasi: satu relasi untuk superclass dan satu untuk tiap subclass
Validasi relasi pada model data logikal menggunakan teknik normalisasi. Tujuan langkah ini adalah untuk memastikan tiap – tiap relasi setidaknya berada dalam 3NF (Third Normal Form).
Langkah 2.3 Validasi relasi terhadap transaksi pengguna
Memastikan bahwa relasi yang ada dalam model data logikal telah mendukung transaksi - transaksi yang diperlukan.
Langkah 2.4 Memeriksa batasan – batasan integritas
Menentukan batasan – batasan integritas (integrity constraint), dimana mencakup pemeriksaan lengkap sebagai berikut :
a. Data yang dibutuhkan
Beberapa atribut harus mempunyai nilai yang valid, atau dengan kata lain tidak boleh null.
b. Batasan domain atribut
Setiap atribut mempunyai domain, yaitu kumpulan dari nilai – nilai yang memenuhi persyaratan.
c. Multiplicity
Merupakan batasan jumlah yang ditempatkan pada hubungan antar data di dalam basis data.
d. Integritas entitas (entity integrity)
Primary key dari sebuah entitas tidak boleh bernilai null.
e. Referential Integrity
Sebuah foreign key menghubungkan setiap tuple pada relasi childs ke tuple pada relasi parent candidate key yang merupakan nilai yang sama.
f. Batasan umum
Batasan yang berasal dari persyaratan - persyaratan bisnis perusahaan. Kemudian dokumentasi semua batasan – batasan integritas (integrity constraint). Langkah 2.5Meninjau kembalimodel data logikal dengan pengguna
Meninjau kembali model data logikal dengan pengguna untuk memastikan bahwa pengguna menyetujui model data logikal yang merupakan representasi nyata terhadap persyaratan data perusahaan
Langkah 2.6 Gabungan model data logikal menjadi model data global Langkah 2.6.1 Gabungan model data logikal menjadi model data global
Metodologi perancangan logikal memudahkan perancangan basis data yang sederhana maupun basis data kompleks. Untuk membuat basis data dengan multiple user view, digunakan pendekatan integrasi view. Pada tahap ini, model data ini digabungkan menjadi satu. Kegiatan – kegiatan yang biasanya dilaksanakan dalam langkah ini antara lain :
a. Review nama dan isi entitas / lain dan candidate keys mereka
b. Review nama dan isi dari relationship/foregin keys
c. Menggabungkan entitas/relasi dari model data lokal
d. Menyertakan (tanpa menggabungkan) entitas / relasi untuk dari masing – masing model data lokal
e. Menggabungkan relationship / foreign keys dari model data lokal
f. Menyertakan (tanpa menggabungkan) relationship / foreign keys yang unik dari masing – masing model data logikal
g. Memeriksa adanya entitas / relasi dan relationship/foreign keys yang hilang
h. Memeriksa foreign keys
i. Memeriksa batasan integritas (integrity constraints)
j. Menggambarkan diagram ER global
k. Update dokumentasi
Langkah 2.6.2 Validasi data model logikal global
Validasikan relasi yang dibentuk dari model data logikal global menggunakan teknik normalisasi dan memastikan mereka mendukung transaksi yang dibutuhkan.
Memastikan bahwa data model logikal adalah representasi yang benar dari perusahaan.
Langkah 2.7 Mengecek perkembangan di masa depan
Menentukan apakah akan ada perubahan penting yang dapat muncul yang mungkin terjadi dimasa yang akan datang dan untuk menilai apakah model data logikal dapat menyesuaikan diri dengan perubahan tersebut.
Physical Database Design
MenurutConnolly dan Begg (2010, p324), langkah terakhir dalam perancangan basis data adalah physical database design yang mendeskripsikan bagaimana sebuah basis data diimplementasikan. Tiga langkah perancangan basis data yang terdiri dari perancangan konseptual, logikal dan fisikal termasuk ke dalam the three-level ANSI-SPARC. Contoh gambar The three-level ANSI-SPARC dapat dilihat pada gambar 2.17
Gambar 2.9 The view integration approach Sumber : Connolly dan Begg(2010, p325)
Connolly dan Begg (2010, p523) juga mengatakan secara rinci bahwaphysical database designadalah sebuah proses menciptakan atau menghasilkan deskripsi dari implementasi basis datadalam penyimpanan kedua; mendeskripsikan hubungan dasar, dokumen perusahaan, dan indeks yang digunakan untuk memperoleh akes data yang efisien, dan setiap konstrain integritas yang terkait serta langkah – langkah keamanan.Connolly dan Begg (2010, p523-558) menguraikanlangkah – langkah dalam membangun model data fisikal sebagai berikut :
Langkah 3 Menerjemahkan Model Data Logikal untuk DBMS yang Ditargetkan Langkah 3.1 Merancang relasi dasar
Menentukan bagaimana representasi relasi dasar yang telah diidentifikasi pada model data logikal global, agar dapat diimplementasikan pada tujuan DBMS. Informasi yang dibutuhkan dapat diperoleh dari kamus data dan definisi dari relasi dideskripsikan menggunakan database design language (DBDL)
Langkah 3.2 Merancang representasi derived data
Menentukan bagaimana representasi data turunan yang ada pada model data logikal global, agar dapat diimplementasikan pada DBMS tujuan. Atribut yang nilainya didapatkan dari mengkaji nilai atribut lain dinamakan derives atau calculated attributes. Contoh : jumlah karyawan yang bekerja pada suatu cabang perusahaan atau total gaji semua karyawan. Untuk setiap derives attributes yang ada. Tanda “/” digunakan untuk menandakan atribut tersebut adalah derives attribute.
Langkah 3.3 Merancang batasan – batasan umum (general constraint) Merancang batasan – batasan umum untuk DBMS yang akan digunakan.
Langkah 4 Merancang Organisasi File dan Index Langkah 4.1 Menganalisa transaksi
Memahami fungsionalitas transaksi yang dijalankan pada basis data dan menganalisa transaksi – transaksi yang penting.
Langkah 4.2 Memilih organisasi file
Tujuan langkah ini adalah menentukan organsisasi file yang efisien untuk tiap – tiap relasi dasar jika diperoleh DBMS yang akan digunakan.
Langkah 4.3 Memilih organisasi index
Tujuan langkah ini untuk menentukan apakah kegunaan index akan meningkatkan kinerja sistem. ada tiga jenis index yaitu :
a. Primary index, pengindeksan dilakukan pada kolom kunci (key field), yang diurutkan terlebih dahulu secara sekuensial
b. Clustering index, pengindeksan dilakukan pada kolom bukan kunci (non-key field), yang sudah diurutkan terlebih dahulu secara sekuensial. Kolom bukan kunci itu disebut juga dengan clustering attribute.
c. Secondary index, pengindeksan dilakukan pada kolom yang tidak terurut didalam file data.
Langkah 4.4 Memperkirakan kebutuhan kapasitas disk
Memperkirakan besarnya ruang disk (disk space) yang dibutuhkan untuk mendukung implementasi basis data. estimasi pemakaian disk tergantung pada DBMS dan perangkat keras yang digunakan untuk mendukung basis data. Perkiraan ukuran dapat dilakukan dengan mengukur besar data tiap baris dan jumlah baris pada setiap relasi.
Langkah 5 Merancang sudut pandang pengguna
Merancang view pengguna yang telah diidentifikasi selama tahap pengumpulan kebutuhan dan tahap analisa pada daur hidup pengembangan sistem basis data relasional. (System development lifecycle)
Langkah 6 Merancang mekanisme keamanan
Merancang mekanisme kemanan untuk sistem basis data sesuai yang dibutuhkan pengguna, ada dua macam keamanan sistem mencakup akses dan penggunaan basis data pada level sistem seperti username dan password. Keamanan bagi sistem basis data sangat diperlukan karena basis data merupakan sumber daya perusahaan yang penting.
Langkah 7 Mempertimbangkan pengenalan dan pengendalian terhadap redudansi Dalam langkah ini, digunakan untuk menentukan pengenalan redudansi dalam hal pengendalian dengan aturan normalisasi yang akan meningkatkan performa sistem.
Langkah 8 Mengamati dan memasang sistem operasional
Langkah terakhir di dalam perancangan basis data fisikal adalah mengamati sistem operasional dan meningkatkan performa sistem untuk membenarkan keputusan perancangan yang pantas atau mencerminkan kebutuhan yang berubah – ubah.
2.1.14 DBMS Selection
Desain dari user interface dan program aplikasi yang digunakan dan proses database. Langkah-langkah yang digunakan dalam memilih sebuah DBMS adalah sebagai berikut:
• Menggambarkan cakupan tugas berdasarkan kebutuhan perusahaan • Membuat perbandingan mengenai dua atau tiga produk DBMS • Mengevaluasi produk-produk DBMS tersebut
• Merekomendasikan pemilihan DBMS dan membuat laporan hasil dari evaluasi produk DBMS tersebut.
Menurut Connolly & Begg (2005,p295–296), pemilihan DBMS yang sesuai untuk mendukung aplikasi basisdata. Yang mencakup :
1. Mendefinisikan syarat-syarat referensi studi
Menentukan sasaran, batasan masalah, dan tugas yang harus dilakukan.
2. Mendaftar 2 atau 3 jenis barang
Membuat daftar barang - barang, misalkan dari mana barang ini didapat, berapa biayanya serta bagaimana hila ingin mendapatkannya.
3. Mengevaluasi barang
Barang-barang yang ada dalam daftar diteliti lebih lanjut untuk mengetahui kelebihan dan kekurangan barang tersebut.
4. Merekomendasikan pilihan dan membuat laporan
Merupakan langkah terakhir dari seleksi DBMS yaitu mendokumentasikan proses dan untuk menyediakan pemyataan mengenai kesimpulan dan rekomendasi terhadap salah satu produk DBMS.
2.1.15 Application Design
Proses merancang user interface atau antarmuka pengguna dan program aplikasi yang menggunakan dan memproses basis data.
Menurut Connolly & Begg (2005,p299-230), perancangan aplikasi (application design) adalah merancang antarmuka pemakai (user interface) dan program aplikasi yang akan memproses basisdata. Perancangan basisdata dan perancangan aplikasi adalah aktivitas bersamaan pada database application lifecycle.
Dalam kasus sebenarnya, adalah tidak mungkin untuk menyelesaikan perancangan aplikasi sebelum perancangan basisdata selesai. Dalam perancangan aplikasi harus memastikan semua pertanyaan fungsional dari spesifikasi kebutuhan pemakai (user requirement specification) yang menyangkut perancangan aplikasi program yang mengakses basisdata dan merancang transaksi yaitu cara akses ke basisdata dan perubahan terhadap isi basisdata (retireve, update dan kegiatan keduanya). Artinya bagaimana fungsi yang dibutuhkan bisa terpenuhi dan merancang antarmuka pemakai (user interface) yang tepat. Antarmuka yang dirancang harus memberikan informasi yang dibutuhkan dengan cara menciptakan 'user-friendly'. Kebanyakan antarmuka pemakai yang diabaikan akan niscaya membuat masalah. Bagaimanapun, antarmuka pemakai harus diakui sebagai komponen dari sistem yang penting, dimana agar mudah dipelajari dan mudah digunakan, sehingga pemakai akan cenderung memberdayagunakan informasi yang disajikan.
2.1.16 Prototyping
Membangun model kerja dari database system, yang memungkinkan designer atau user untuk membayangkan dan mengevaluasi bagaimana sistem akhir akan terlihat dan berfungsi. Umumnya sebuah prototype merupakan sebuah model kerja yang tidak memiliki semua fitur atau memberikan semua fungsi dari sistem. Tujuan utama dalam pengembangan prototype pada aplikasi basis data adalah untuk memungkinkan pengguna menggunakan prototype dan mengidentifikasi fitur-fitur sistem, baik yang bekerja dengan baik maupun yang kurang baik, serta memungkinkan pengguna untuk dapat mengusulkan perkembangan beberapa fitur barn untuk aplikasi basis data . Dua jenis prototype yang sering ditemukan adalah :
• Requirement prototyping Penggunaan prototype untuk menunjukkan tujuan dari pembuatan aplikasi basis data.
• Evolutionary prototype (pengembangan model) Digunakan untuk tujuan yang sama, perbedaan terpentingnya adalah prototype tidak dibuang, tetapi dikembangkan selanjutnya menjadi aplikasi basis data yang bekerja.
Menurut Connolly & Begg (2005,p303–304), prototyping adalah membuat model kerja dari aplikasi basisdata, yang membolehkan perancangan atau user untuk mengevaluasi hasil akhir sistem, baik dari segi tampilan maupun fungsi yang dimiliki sistem. Tujuan dari pengembangan prototype aplikasi basisdata adalah untuk
memungkiukan pemakai menggunakan prototype untuk mengidentifikasi keistimewaan sistem atau kekurangannya, dan memungkiukan perancangan untuk memperbaiki atau melengakapi keistimewaan (feature) dari aplikasi basisdata baru.
Ada dua strategi prototyping yang umum digunakan sekarang, yaitu requirement prototyping dan evolutionary prototyping. Requirement prototyping adalah menggunakan prototype untuk menetapkan kebutuhan dari tujuan aplikasi basisdata dan ketika kebutuhan sudah terpenuhi, prototype tidak digunakan lagi atau dibuang (discard). Sedangkan evalutionary prototyping menggunakan tujuan yang sama, tetapi perbedaan pentingnya adalah prototype tetap digunakan untuk selanjutnya dikembangkan menjadi aplikasi basisdata yang bekerja.
2.1.17 Implementation
Membuat definisi physical database dan program aplikasi. Implementasi basis data dapat dicapai dengan menggunakan Data DefinitionLanguage (DDL) dari DBMS yang dipilih. Pernyataan DDL digunakan untuk membuat struktur basis data dan arsip basis data kosong.
Implementation adalah realisasi fisikal dari desain basisdata dan desain aplikasi (Connolly & Begg, 2005,p304). Dalam tahap ini juga akan diimplementasikan komponen lain dari aplikasi basisdata seperti menu ·layar, pemasukan data, security dan kontrol integritas.
2.1.18 Data Conversion and Loading
Loading data dari sistem lama ke sistem baru dan dimana memungkinkan penggabungan antar aplikasi yang sedang berjalan dalam database yang baru. dan mengubah aplikasi yang sudah ada untuk dapat dijalankan pada basis data yang baru. Tahap ini hanya diperlukan ketika sebuah sistem basis data baru menggantikan sistem yang lama.
Data Conversion and loading adalah suatu proses mentransfer data yang ada ke dalam basisdata baru dan mengubah aplikasi yang ada untuk dijalankan dalam basisdata baru (Connolly & Begg, 2005,p305). Tahap ini hanya dibutuhkan ketika sistem basisdata baru menggantikan sistem yang lama
2.1.19 Testing
sistem database di coba apabila ada error dan memvalidasi terhadap spesifikasi kebutuhan user.
Testing adalah suatu proses mengeksekusi program aplikasi dengan tujuan untuk menemukan kesalahan (Connolly & Begg, 2005,p305–306). Jika pengujian berhasil, maka dapat menampilkan error dari program aplikasi dan struktur basisdata. Testing memperlihatkan bahwa basisdata dan program aplikasi bekeija sesuai dengan spesifikasinya dan menampilkan kebutuhan - kebutuhan untuk keija yang memuaskan.
2.1.20 Operational Maintenance
sistem database sudah dijalankan secara penuh. Sistem secara berkesinambungan dimonitor dan dikelola. Pada tahap sebelumnya, aplikasi basis data telah diimplementasikan dan diuji. Setelah itu, sistem dapat memasuki tahap perawatan, yang melibatkan aktivitas sebagai berikut:
- Memantau hasil dari sistem, jika hasil masih kurang dari harapan yang diterima, maka perbaikan basis data akan dibutuhkan
- Memelihara dan melakukan upgrade pada aplikasi basis data (jika dibutuhkan) - Memasukkan kebutuhan baru ke dalam aplikasi basis data dapat dilakukan
melalui tahap dari daur hidup terlebih dahulu
Operational Maintenance adalah suatu proses memonitor dan memelihara sistem berdasarkan instalasi (Connolly & Begg, 2005,p306–307). Tahapan ini terdiri dari aktivitas- aktivitas berikut :
- Memonitor untuk kerja sistem
- Memelihara dan memperbaharui aplikasi basisdata (jika diperlukan)
User Interface adalah merupakan mekanisme komunikasi antara pengguna (user) dengan sistem. Antarmuka pemakai (User Interface) dapat menerima informasi dari pengguna (user) dan memberikan informasi kepada pengguna (user) untuk membantu mengarahkan alur penelusuran masalah sampai ditemukan suatu solusi. User interface menurut Satzinger, Jackson, dan Burd (2005,p442) adalah bagian dari sistem informasi yang membutuhkan interaksi dari user untuk membuat input dan output. Hal ini di pertegas oleh Menurut Mathiassen(2000,p152) user interface adalah sebuah fasilitas bagi user untuk dapat berinteraksi dengan sistem. Kualitas dari user interface umumnya disebut usability. Usability tergantung pada siapa user dan dalam keadaan bagaimana sistem digunakan. Jadi dapat di simpulkan bahwa User Interface adalah interaksi antara manusia dengan komputer yang saling memberikan informasi.
2.1.22 Normalisasi
Normalisasi adalah suatu teknik dimana digunakan untuk mengidentifikasikan hubungan antara atribut dengan memberikan kebutuhan data yang diperlukan oleh suatu perusahaan. Seperti yang disampaikan oleh Connolly dan Begg, (2010, p.416) normalisasi merupakan sebuah teknik untuk memproduksi satu set hubungan dengan sifat yang diinginkan, memberikan kebutuhan data pada perusahaan.
Proses Normalisasi antara lain :
• Suatu teknik formal untuk menganalisis relasi berdasarkan primary key dan fungsi dependensi antar atribut yang ada.
• Dieksekusi dalam beberapa cara. Setiap cara mengacu ke bentuk normal tertentu, sesuai dengan sifat yang dimilikinya.
• Setelah Normalisasi diproses, relasi akan secara bertahap lebih terbatas/kuat bentuk formatnya dan juga mengurangi tindakan anomali pada setiap update.
Gambar 2.10 Diagram ilustrasi dari hubungan antara bentuk normalisasi
Sumber : Connolly dan Begg (2010,p429)
Bentuk-bentuk normalisasi menurut Connolly dan Begg, (2010,p430-438)
antara lain:
1. Unnormalized Form (UNF)
Merupakan sebuah tabel awal yang belum ternormalisasi yang berisikan satu atau lebih kumpulan data yang berulang. Untuk membuat tabel UNF yaitu dengan memindahkan data dari sumber informasi yang di dapat ke dalam tabel dengan format baris dan kolom, jika ada atribut yang mempunyai banyak nilai (multivalue) akan masuk ke dalam bentuk UNF.
2. First Normal Form (1NF)
Bentuk normalisasi tahap pertama yang merupakan sebuah relasi dimana sebuah titik pertemuan antara setiap baris dan kolom yang berisi satu dan hanya satu nilai.
3. Second Normal Form (2NF)
Tahapan kedua setelah 1NF terpenuhi yaitu 2NF dimana merupakan sebuah relasi yang terdapat di dalam 1NF dan setiap atribut yang bukan primary key bergantung pada primary key.
4. Third Normal Form (3NF)
Merupakan tahapan ketiga dalam normalisasi dimana sebuah relasi yang terdapat pada bentuk normalisasi pertama dan kedua, yang mana atribut primary key
bergantung pada primary key.
Proses normalisasi meliputi langkah-langkah sebagai berikut :
a) Unnormalized Normal Form (UNF)
Ada tahap awal sebelum memulai 1NF yaitu unnormalized form (UNF). Pada bentuk
UNF ini merupakan tabel yang terdapat satu atau lebih grup yang berulang
(repeating groups).
b) First Normal Form (1NF)
Pada bentuk pertama ini merupakan sebuah hubungan dimana perpotongan setiap
baris dan kolom yang berisi satu dan hanya satu nilai. Sebelum mentransformasikan 11 tabel tidak normal (UNF) ke bentuk normal pertama (1NF). terlebih dahulu mengidentifikasi repeating groups yang terdapat pada tabel relasi. Kemudian menghilangkan repeating groups untuk menghilangkan data rangkap.
c) Second Normal Form (2NF)
Pada bentuk normalisasi kedua ini yaitu 2NF merupakan relasi yang terdapat dalam bentuk 1NF dan tiap atribut yang bukan primary key sifatnya bergantung penuh secara fungsional pada primary key (full functional dependency)
d) Third Normal Form (3NF)
Untuk menjalankan bentuk ini, maka bentuk 1NF dan 2NF haruslah terpenuhi terlebih dahulu. Dimana tidak ada atribut bukan primary key yang bergantung transitif terhadap primary key. Bentuk normal ketiga ini lebih berdasarkan pada konsep peralihan ketergantungan (transitive dependency). Transitive dependency adalah kondisi dimana A, B, dan C adalah atribut dari sebuah relasi bahwa jika A→B dan B→C, maka C adalah transitive independent pada A melewati B (menyatakan bahwa A bukan merupakan functional dependent pada B atau C).
e) Boyce-Codd Normal Form (BCNF)
Suatu relasi bisa dikatakan BCNF bila didalamnya berisi atribut yang berfungsi sebagai candidate key salah satu dari candidate key tersebut menjadi primary key.
Bentuk normal 4NF terpenuhi dalam sebuah tabel jika telah memenuhi bentuk BCNF, dan tabel tersebut tidak boleh memiliki lebih dari satu multivalued attribute.
g) Fifth Normal Form (5NF)
Bentuk normal 5NF terpenuhi jika tidak dapat memiliki sebuah lossless decomposition menjadi tabel-tabel yang lebih kecil.
2.1.23 Entity Relationship Diagram (ERD)
Menurut Satzinger, Jackson, dan Burd (2010, p57), entity relationship diagram merupakan suatu analisis struktur dan rekayasa informasi dari model data yang diperlukan oleh sistem. Contoh ERD dapat dilihat pada gambar 2.18
Gambar 2.11 Entity Relationship Diagram
Penjelasan proses bisnis ERD gambar 2.18
1. Entitas Pelanggan
Entitas pelanggan mempunyai atribut kode_pelanggan(primary key), nama, alamat, no_telp yang menyatakan isi dari entitas pelanggan.
2. Entitas Purchase Order
Entitas purchase_order mempunyai atribut kode_po (primary key), kode_pelanggan(foreign_key), total, tanggal_po yang menyatakan isi dari entitas purchase_order.
3. Entitas Detail Puchase Order
Entitas detail purchase order terbentuk karena adanya hubungan atau relationship many-to-many (*:*) antara entitas purchase_order dengan barang.
Entitas detail purchase order berisi kode_po, kode_barang yang befungsi sebagai primary dan foreign key dari entitas masing – masing
4. Entitas Barang
Entitas barang mempunyai atribut kode_barang (primary key), nama _barang, jenis, harga yang menyatakan isi dari entitas barang.
Proses bisnis yang terjadi dengan melihat alur ERD pada contoh gambar 2.18 adalah pelanggan yang datang ingin membeli barang akan dicatat semua ke dalam purchase order oleh bagian kasir. Purchase order sendiri berarti dokumen yang mencatat segala transaksi barang yang dibeli oleh pelanggan. Purchase Order yang nantinya berisi daftar barang – barang akan mengambil data – data barangnya di dalam sistem ke dalam tabel barang.
2.1.24 Pendekatan perancangan basis data
Menurut Connolly dan Begg (2010, p321), ada dua pendekatan untuk mendesain sebuah basis data, yaitu :
1. Pendekatan bottom – up
Dimulai pada tingkat awal dari atribut (yaitu, property dari entitas dan relationship), melalui analisis dari asosiasi antar atribut, dikelompokkan menjadi hubungan yang merepresentasikan jenis – jenis entitas dan hubungan antar entitas.Pendekatan ini sesuai untuk mendesain basis data yang sederhana dengan jumlah atribut yang tidak banyak.
2. Pendekatan top-down
Digunakan pada basis data yang lebih kompleks.dimulai dengan pengembangan dari model data yang mengandung beberapa entitas dan hubungan tingkat tinggi, kemudian menggunakan perbaikan top-down berturut – turut untuk mengidentifikasikan entitas, hubungan dan atribut tingkat rendah. Pendekatan ini biasanya digambarkan melalui Entity-Relationship (ER ).
2.1.25 Database System Development Life Cycle
Dalam merancang sebuah basis data diperlukan tahapan – tahapan serta kemampuan dalam menganalisis dan merancang sebuah basis data tersebut. Diperkuat
oleh pendapat Connolly dan Begg (2006) dalam jurnalnya yang mengatakan bahwa dalam menentukan analisis dan perancangan basis data diperlukan kemampuan seorang perancang basis data sebagai berikut :
Gambar 2.5 Tipe pengetahuan kemampuan analisis dan perancangan basis data Sumber :Connolly dan Begg (2006, p46)
Menurut Connolly dan Begg (2010, p313), untuk merancang aplikasi sistem basis data diperlukan tahapan – tahapan yang dinamakan dengan siklus hidup aplikasi basis data (database system development lifecycle).Tahapan – tahapan
database system development life cycle adalah sebagai berikut : 1. Database planning
2. System definition
3. Requirements collection and analysis
4. Database design
- Logical Database Design - Physical Database Design 5. DBMS selection (optional)
- Application Design - Prototyping (optional) - Implementation
- Data conversion and loading - Testing
- Operational maintenance
Gambar 2.6The stages of database system development lifecycle Sumber :Connolly dan Begg (2010, p314)
2.2 Teori Khusus 2.2.1 Penjualan
Menurut Reeve (2009,p255), penjualan adalah total biaya yang dibebankan kepada customer untuk barang yang dijual termasuk penjualan tunai maupun penjualan kredit.
Menurut Dave (2010) dalam jurnalnya mengatakan, menjadi seorang Sales professional tidak ada hubungannya dengan berapa lama dia berada di bidang itu, latar belakang pendidikan atau tingkat pengalaman.
2.2.2 Pembelian
Menurut Indrajani (2011,p71) , pembelian adalah suatu usaha yang digunakan dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Secara umum definisi pembelian adalah usaha pengadaan barang atau jasa dengan tujuan yang akan digunakan sendiri, untuk kepentingan proses produksi maupun untuk dijual kembali, baik dengan atau tanpa proses, dalam proses pembelian yang ada, agar kegiatan pembelian dapat dilakukan dengan benar. Fungsi pembelian bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan pesanan pembelian kepada pemasok yang dipilih.
Menurut Hall (2008, p235), prosedur pembelian terdiri dari tugas – tugas yangmeliputi identifikasi kebutuhan inventory, penempatan order, penerimaan inventory, dan pengenalan akan kewajiban atau liability. Dokumen – dokumen yang terkait atau termasuk dalam prosedur sistem pembelian adalah sebagai berikut :
1. Purchase requisition
Dokumen yang diperlukan untuk pembelian barang ketika barang mencapai titik terendah di dalam persediaan gudang. Purchase Requisition dibuat ketika terjadinya kondisi Re-Order Point (ROP).
2. Purchase order
Dokumen purchase order disiapkan ketika adanya dokumen purchase requisition. Dokumen purchase order disiapkan untuk melakukan pembelian kepada supplier, tentu kepada supplier yang sudah termasuk di dalam daftar list atau telah melewati sistem sort. Duplikat dari purchase order diberikan kepada supplier, bagian keuangan untuk membuat account payable (AP), dan terakhir diberikan kepada bagian gudang (inventory).
Ketika barang yang dipesan dari suppliermasuk atau telah sampai ke perusahaan, maka bagian gudang akan membuat receiving report sebagai laporan bahwa barang yang telah dipesan bagian pembelian telah sampai, barang sesuai atau tidak dengan file purchase order, serta melaporkan kondisi barang. 4. Supplier invoice
Supplier invoice atau tagihan supplier merupakan dokumen tagihan yang diberikan dari supplier kepada bagian pembelian untuk ditanggung pembayaran atas barang yang telah dibeli atau dipesan berdasarkan purchase order.
Dikutip dari jurnal (Sistem informasi pembelian, 2013) sistem pembelian digunakan dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Transaksi pembelian digolongkan menjadi dua yaitu pembelian lokal dan impor. Pembelian lokal adalah pembelian dari pemasok dalam negeri sedangkan pembelian impor adalah pembelian dari pemasok luar negeri.
2.2.3 Persedian
Pengawasan dan pemeliharaan persediaan adalah masalah biasa dalam semua organisasi di setiap faktor sektor ekonomi. Yamit (2005, p3) mengatakan bahwa masalah persediaan tidak hanya terbatas pada perusahaan pencari keuntungan saja tetapi juga dialami oleh organisasi sosial maupun perusahaan non profit oriented, seperti persediaan dalam pabrik, agrobisnis, pedagang besar, pengecer, rumah sakit, sekolah, hotel dan mesjid, rumah tangga, restoran, pemerintah dan lain sebagainya. Istilah (terminologi) persediaan dapat digunakan dalam perbedaan seperti :
1. Persediaan bahan baku di tangan (stock on hand)
2. Daftar persediaan secara fisik
3. Jumlah item di tangan
4. Nilai persediaan barang
Menurut Mulyadi (2001,p553), sistem persediaan bertujuan untuk mencatat mutasi tiap jenis persediaan yang disimpan digudang. Sistem ini berkaitan erat dengan sistem penjualan, sistem retur penjualan, sistem pembelian, sistem retur pembelian, dan sistem akuntasi biaya produski. Dalam perusahaan manufaktur,
persediaan terdiri dari : persediaan produk jadi, persediaan produk dalam proses persediaan bahan baku, persedian bahan penolong, persedian bahan habis pakai pabrik, persedian suku cadang. Dalam perusahaan dagang, persediaan hanya terdiri dari satu golongan yaitu persediaan barang dagang yang merupakan barang yang dibeli untuk tujuan dijual kembali. Sedangkan untuk metode pencatatan persedian dibagi menjadi dua yaitu :
• Metode mutasi persediaan
Setiap mutasi persediaan dicatat dalam kartu persediaan dicatat dalam kartu persediaan.
• Metode persediaan fisik
Hanya tambahan persediaan dari pembelian saja yang dicatat, sedangkan mutasi berkurangnya persediaan karena pemakai tidak dicatat dalam kartu persediaan.
Dikutip dari jurnal (Sistem informasi persedian, 2010), menjelaskan bahwa persedian merupakan aser pengadaan barang di dalam sebuah bisnis, atau yang sedang dalam proses untuk penjualan tertentu, atau dalm wujud material atau pendukung untuk digunakan dalam proses produksi atau penyumbangan jasa
