BAB 2 LANDASAN TEORI. Sistem merupakan komponen komponen terstruktur yang menjadi satu

BAB 2 LANDASAN TEORI

2.1

Sistem Sistem merupakan komponen – komponen terstruktur yang menjadi satu

kesatuan, saling terhubung satu sama lain dengan mempunyai fungsi tertentu untuk mencapai tujuan dari fungsi tersebut. Sistem biasanya dipakai untuk membuat atau membantu pekerjaan secara manual menjadi otomatis tentu dengan pengendalian orang - orang yang menggunakan sistem tersebut. Di dalam perusahaan – perusahaan menengah dan keatas, sistem sudah banyak digunakan untuk mendukung proses bisnis operasional agar menjadi lebih cepat, menghasilkan laporan yang akurat, menghindari resiko kehilangan data, serta mengurangi job-desk ganda dari karyawan yang ada di perusahaan. Hal ini diperkuat oleh pendapat Satzinger, Jackson, dan Burd (2010, p6) yang mengatakan bahwa sistem adalah sekumpulan (koleksi) komponen – komponen yang saling terintegrasi satu sama lain dengan mempunyai fungsi yang sama untuk mencapai hasil yang dikeluarkan atau diinginkan sistem. Tidak hanya itu, pendapat O'Brian dan Marakas (2011, p26) juga mengatakan bahwa sistem dapat didefinisikan sebagai sekumpulan komponen yang saling berhubungan dengan batasan yang jelas, dan bekerja sama untuk mencapai tujuan bersama dengan menerima input serta menghasilkan output dalam proses yang teratur. Dimana, sistem memiliki tiga fungsi dasar, yaitu : input, process dan output. Penjelasan tiga fungsi dasar sistem adalah sebagai berikut : 1.

Masukan (input), melibatkan penangkapan dan perakitan elemen – elemen yang masuk ke dalam sistem untuk diproses. Contoh masukan : masukan data – data material meliputi harga dan jenis. 9

10

2.

Proses (processing), melibatkan proses yang teratur untuk mengubah “masukan” menjadi “keluaran”. Contoh proses : proses mengolah dan menyusun data – data material menjadi lebih teratur tanpa adanya redudansi data yang sama di dalam sistem (otomatis) atau pencatatan yang sama di dalam dokumen (manual).

3.

Keluaran (output), melibatkan pengiriman elemen – elemen yang dihasilkan dari proses yang teratur untuk memenuhi tujuan utama mereka. Contoh keluaran : input, hasil dari data – data material yang dimasukan ke dalam sistem dapat dilihat dalam bentuk output yaitu, laporan. Misal laporan persediaan material per bulan atau per periode tertentu tergantung dari permintaan pihak manajemen atas.

2.2

Informasi Informasi sangat dibutuhkan oleh perusahaan untuk membantu perusahaan

tersebut dalam mencapai tujuan atau goals. Informasi sendiri merupakan pengolahan dari data – data mentah perusahaan yang ada begitu banyak diolah menjadi data yang mempunyai arti dan berguna untuk menentukan keputusan di dalam perusahaan. Seperti yang kita ketahui bahwa informasi mendukung tujuan dalam konteks perusahaan atau organisasi. Informasi dapat memberikan nilai tambah bagi perusahaan dengan memberikan informasi – informasi mengenai suatu produk atau jasa yang nantinya digunakan oleh pihak manajemen atas perusahaan dalam mengambil keputusan yang tepat, menentukan arah perusahaan kedepannya harus bagaimana, apa yang harus dilakukan dan dihasilkan, serta transfer informasi yang sangat penting di dalam internal perusahaan, berguna untuk meningkatkan pengembangan kualitas produktivitas dari perusahaan tersebut. Hal ini diperkuat oleh pendapat O'Brian dan Marakas (2011, p34) yang mengatakan bahwa informasi

11

adalah data yang telah diubah menjadi isi yang mempunyai arti dan kegunaan untuk pengguna akhir tertentu. Sedangkan Brian K dan Stacey (2007, p25) mendefinisikan informasi adalah data yang telah diolah atau dimanipulasi untuk digunakan dalam pengambilan keputusan. Tidak hanya itu, manfaat informasi bagi perusahaan sendiri tergantung dari seberapa besar informasi tersebut digunakan sehingga memberikan nilai tambah tersendiri bagi perusahaan. Pernyataan ini dipertegas oleh Fattahi dan Afshar (2006) dalam jurnalnya yang menyimpulkan bahwa informasi akan sangat berguna tergantung dari pemberian nilai informasi tersebut. Nilai informasi dapat dilihat dari sudut pandang yang berbeda oleh pihak manajemen atas untuk membuat keputusan manajemen operasional. Nilai informasi berguna sebagai nilai tambah dalam menghemat waktu proses bisnis, produktivitas serta meningkatkan pengembangan kualitas kerja dengan membagi informasi tersebut ke dalam internal perusahaan. 2.3

Sistem Informasi Sistem informasi merupakan penggabungan antara sistem yang terstruktur

dan terintegrasi dengan menghasilkan informasi dari hasil pengolahan data, sudah melewati tahapan proses olah data oleh sistem. Sistem yang terstruktur dan terintegrasi satu sama lain sudah mampu menghasilkan informasi kepada pengguna akhir. Data yang masuk ke dalam sistem diproses, disimpan, dan dikeluarkan menjadi informasi yang dibutuhkan oleh perusahaan atau organisasi. Menurut Satzinger, Jackson, dan Burd (2010, p6), sistem informasi adalah sekumpulan komponen – komponen yang saling berhubungan satu sama lain, yang berfungsi untuk mengumpulkan, melakukan proses, menyimpan serta menyediakan keluaran sistem (output) sebagai informasi yang dibutuhkan untuk menyelesaikan tugas – tugas bisnis. Sedangkan menurut pendapat O'Brien dan Marakas (2011, p4), sistem

12

informasi dikatakan sebagai kombinasi dari orang – orang, perangkat keras, perangkat lunak, jaringan komunikasi, sumber data dan kebijakan serta prosedur yang menyimpan, menerima, mengubah dan menyebarkan informasi di dalam perusahaan. Orang – orang yang menggunakan sistem informasi zaman sekarang bertujuan melakukan komunikasi dengan menggunakan berbagai jenis dari perangkat keras, perintah proses informasi dan prosedur perangkat lunak, jaringan komunikasi, serta data yang disimpan. Contoh komponen sistem informasi dapat dilihat pada gambar 2.1

Gambar 2.1 The Componnent Of Information System Sumber : O'Brien dan Marakas (2011, p31) Salah satu karakteristik dari sistem informasi adalah perbedaan komponen – komponen yang bergantung pada setiap data dan proses mengolahnya. Pola ketergantungan inilah yang disebut sebagai arsitektur sistem informasi berdasarkan kutipan jurnal (Dreyfus, 2009). Dikemukakan juga oleh Connolly dan Begg (2010, p312), bahwa sistem informasi merupakan sekumpulan sumber – sumber daya yang menungkinkan untuk pengumpulan, pengaturan, pengendalian, serta penyebaran informasi di dalam perusahaan.

13

2.4

Data dan Database Seperti yang kita ketahui bahwa data merupakan properti yang sering

ditemukan di dalam entitas – entitas pada dunia nyata yang berguna untuk mengambarkan arti dari entitas tersebut. Sebagai contoh salah satu data dari entitas manusia adalah nama, alamat dan umur. Data juga dapat berbentuk angka, kata, kalimat, gambar, video, maupun audio. Data merupakan potongan informasi kecil, sebelum diolah lebih lanjut, dan bersifat tidak memberikan informasi yang berarti bagi pemilik data. Data yang begitu banyak jumlahnya perlu disimpan ke dalam suatu tempat penyimpanan data yang disebut sebagai database. Christensen, Brandt, dan McCracken (2011) dalam jurnalnya menyatakan bahwa data – data yang nantinya akan menghasilkan informasi, disimpan ke dalam suatu tabel dimana tabel tersebut berhubungan satu sama lainnya. Setiap tabel yang mengandung satu atau lebih atribut digunakan untuk menghasilkan kualifikasi, identifikasi, pengelompokan, kuantitas, atau mendeskripsikan susunan informasi tabel tersebut. Hal ini diperkuat oleh pendapat O'Brian dan Marakas (2011, p34), yang mengatakan bahwa kata data merupakan bentuk jamak dari datum, walaupun data biasanya mewakili baik bentuk tunggal maupun jamak. Data adalah fakta atau observasi mentah yang biasanya mengenai fenomena fisik atau transaksi bisnis. Lebih rincinya, data adalah pengukuran objektif dari atribut (karakteristik) entitas dimana data tersebut perlu disimpan ke dalam suatu tabel basis data, diolah dan menghasilkan suatu informasi. Data yang ada di dalam perusahaan perlu disimpan di dalam suatu tempat penyimpanan data, yang dikatakan sebagai database atau basis data. Database atau basis data itu sendiri merupakan tempat penyimpanan data yang besar jumlahnya terdiri dari kapasitas besar dan fungsi – fungsi yang ada di dalam suatu basis data tersebut. Data – data yang ada di dalam perusahaan perlu disimpan dikarenakan data

14

yang nantinya akan memberikan informasi bagi perusahaan harus terdata lengkap dan tidak boleh kurang atau hilang satupun karena data yang sudah melewati tahapan proses pengolahan data, dapat memberikan nilai informasi tambah bagi perusahaan. Database atau basis data itu sendiri adalah sekumpulan (koleksi) logikal yang dibagi dan berhubungan dengan data beserta deskripsinya, dirancang untuk memenuhi kebutuhan informasi dari perusahaan berdasarkan pendapat Connolly dan Begg (2010, p65). Basis data juga merupakan representasi dari entitas, atribut, dan hubungan logikal diantara entitas tersebut. Pernyataan tersebut juga diperkuat oleh Satzinger, Jackson, dan Burd (2010, p488), yang menyatakan bahwa basis data merupakan sekumpulan data yang terintegrasi sebagai tempat penyimpanan data, diatur dan dikontrol secara terpusat. Contoh database dapat dilihat pada gambar 2.2 Data Client C

Data Client B

Data Client D

Database

Data Client A Gambar 2.2 Database

15

2.5

Database Management System Untuk mengakses basis data yang ada, tentu diperlukan sebuah aplikasi yang

berfungsi sebagai penghubung untuk mengakses basis data tersebut. Aplikasi tersebut membantu para pengguna sistem berhubungan dengan basis data, mempunyai kontrol hak akses ke basis data tersebut. Aplikasi yang dimaksud tersebut dinamakan sebagai database management system. Database management system (DBMS) adalah sistem perangkat lunak yang memungkinkan pengguna sistem untuk mendefinisikan, membuat, mempertahankan, dan mengendalikan akses ke dalam basis data berdasarkan pendapat Connolly dan Begg (2010, p66). Database management system meupakan software yang berinteraksi dengan pengguna program aplikasi dan basis data. DBMS mengijinkan pengguna sistem untuk mendefinisikan basis data, dengan menggunakan data definition language (DDL) serta data manipulation language (DML). Diperkuat dengan pernyataan Brian K dan Stacey C (2007, p420) yang mengatakan bahwa database management system (DBMS) merupakan sebuah perangkat lunak yang dirancang, khususnya untuk mengendalikan struktur sebuah basis data dan berguna untuk mengakses data di dalam basis data tersebut. Contoh skema database management system dapat dilihat pada gambar 2.3

Gambar 2.3 Database Management System Sumber : Connolly dan Begg (2010, p67)

16

Penjelasan database management system pada gambar 2.3 halaman 16. Bagian penjualan dan kontrak (Sales dan Contracts) – deskripsi bagian penjualan dan bagian kontrak pada gambar 2.3 halaman 16 adalah menyatakan bahwa ada dua pengguna sistem yang memasukan data yaitu bagian penjualan dan bagian kontrak. Dua pengguna sistem dengan komputer klien yang berbeda mengakses satu basis data yang sama tentu dengan pemasukan (input) data yang berbeda, seperti pada gambar yang tertera bahwa bagian penjualan memasukan data dan laporan dengan mengakses aplikasi “sales application program” dan bagian kontrak memasukan data dan laporan dengan mengakses aplikasi yang berbeda dari bagian penjualan, yaitu “contracts application program”, hal ini membutuhkan suatu manajemen atau pengendalian ke dalam basis data dengan adanya DBMS. Fungsi DBMS itu sendiri adalah memberikan hak akses kepada dua pengguna bagian penjualan dan bagian kontrak, data – data apa saja yang mereka masukan, modifikasi serta menghapus tergantung dari hak akses mereka, sehingga kontrol terhadap data – data yang berbeda jenis dapat teratasi. Contoh salah satu DBMS yang biasa dipakai adalah mysql. MySQL adalah basis data yang paling populer untuk sistem manajemen server web yang dikembangkan pada pertengahan 1990. Menurut Nixon (2012, p161), sebuah basis data MySQL berisi satu atau lebih tabel, masing-masing berisi records atau baris. Isi dari baris ini adalah berbagai kolom atau bidang yang berisi data itu sendiri. Perintah – perintah yang ada di MySQL dapat dilihat pada tabel 2.1

17

Tabel 2.1 SQL Command Sumber : Nixon (2012, p168)

Mysql DBMS sendiri menyediakan fasilitas – fasilitas dalam menjalankan fungsinya sebagai program penghubung antara aplikasi dengan users. Fasilitas – fasilitas tersebut antara lain adalah -

Data Definition Language Data definition language merupakan fasilitas yang disediakan oleh DBMS. Sintaks yang berfungsi untuk menerjemahkan skema basis data, termasuk tipe dan struktur data. Fungsi – fungsi yang ada pada data definition language adalah sebagai berikut :

1.

Create Statement Fungsi ini berguna untuk membuat atau menciptakan statement baru di dalam membuat objek baru Relational Database Management System (RDBMS). Fungsi create biasanya digunakan untuk membuat basis data baru,

18

tabel basis data, indeks dan store procedure. Contoh sintaks DDL dalam penggunaan mysql : CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name (create_definition,...) [table_options]

2.

Sumber : (MYSQL :: MYSQL 5.0 Reference Manual :: 13.1.10 CREATE TABLE Syntax) Drop Statement Fungsi ini berguna untuk men-drop atau menghilangkan basis data yang sudah ada, tabel, maupun view. Contoh sintaks DDL dalam pengunaan mysql : DROP [TEMPORARY] TABLE [IF EXISTS] tbl_name [, tbl_name] ... [RESTRICT | CASCADE] Sumber : (MYSQL :: MYSQL 5.0 Reference Manual :: 13.1.28 DROP TABLE Syntax)

3.

Alter Statement Fungsi ini berguna untuk memodifikasi basis data. Contoh sintaks DDL dalam pengunaan mysql : ALTER [ONLINE | OFFLINE] [IGNORE] TABLE tbl_name [alter_specification [, alter_specification] ...] [partition_options] Sumber : (MYSQL :: MYSQL 5.0 Reference Manual :: 13.1.7 ALTER TABLE Syntax)

4.

Referential Integrity Statement Fungsi ini berguna untuk mendefinisikan hubungan integritas referensial di dalam basis data yang biasanya diinterpretasikan sebagai primary key dan foreign key.

19

Hal ini diperkuat dengan pendapat Connolly dan Begg (2010, p66) yang mengatakan bahwa DDL merupakan bahasa (language) basis data yang mengijinkan pengguna sistem untuk menspesifikasikan tipe dan struktur serta konstrain data yang disimpan di dalam basis data. -

Data Manipulation Language Data manipulation language merupakan fasilitas kedua yang disediakan oleh DBMS. Sintaks ini berfungsi untuk memodifikasi dan memanipulasi data di dalam basis data. Fungsi – fungsi yang ada pada data manipulation language adalah sebagai berikut :

1.

Insert – digunakan untuk menambah baris di tabel yang sudah ada Contoh sintaks DML dalam pengunaan mysql : INSERT INTO t1 (key,val) VALUES (some_key,some_value; Sumber : (MYSQL :: MYSQL 5.6 Reference Manual :: 14.2.9.10 Adapting DML Statements to memcached Operations)

2.

Update – digunakan untuk memodifikasi baris di tabel yang sudah ada Contoh sintaks DML dalam pengunaan mysql : UPDATE t1 SET val = new_value WHERE key = some_key; UPDATE t1 SET val = val + x WHERE key = some_key; Sumber : (MYSQL :: MYSQL 5.6 Reference Manual :: 14.2.9.10 Adapting DML Statements to memcached Operations)

3.

Delete - digunakan untuk menghapus baris di tabel yang sudah ada Contoh sintaks DML dalam pengunaan mysql : DELETE FROM t1 WHERE key = some_key; Sumber : (MYSQL :: MYSQL 5.6 Reference Manual :: 14.2.9.10 Adapting DML Statements to memcached Operations)

20

Hal ini diperkuat dengan pendapat Connolly dan Begg (2010, p66) yang mengatakan bahwa DML merupakan bahasa basis data yang mengijinkan pengguna sistem untuk melakukan insert, update, delete serta menerima data dari basis data. DML biasanya menyediakan fasilitas untuk memodifikasi basis data, yang dinamakan sebagai bahasa query. 2.5.1 Komponen Database Management System Menurut Connolly dan Begg (2010, p68), ada lima komponen utama di dalam lingkungan database management system yang meliputi : perangkat keras, perangkat lunak, data, prosedur dan manusia. Komponen DBMS diilustrasikan pada gambar 2.4

Gambar 2.4 The DBMS Environtment Sumber : Connolly dan Begg (2010, p68) Penjelasan komponen database management system 1.

Perangkat

keras

(hardware),

DBMS

dan

program

aplikasi

membutuhkan perangkat keras untuk bisa menjalankan fungsi – fungsinya. Perangkat keras yang dimaksud adalah berkisar dari komputer tunggal pribadi ke mainframe atau jaringan dari komputer tersebut. Beberapa DBMS dapat dijalankan pada perangkat keras atau sistem operasi tertentu, sementara yang lain berjalan di berbagai perangkat keras atau sistem operasi. 2.

Perangkat lunak (software), komponen perangkat lunak terdiri dari perangkat lunak DBMS itu sendiri dan program aplikasi yang dijalankan bersamaan dengan sistem operasi, termasuk jaringan perangkat lunak jika DBMS sedang digunakan melalui jaringan.

21

3.

Data,merupakan komponen yang paling penting dalam lingkungan DBMS, tentu dari sudut pandang pengguna akhir. Data juga bertindak sebagai jembatan penghubung antara komponen mesin dengan komponen manusia.

4.

Prosedur (procedures), mengacu pada instruksi dan aturan yang mengatur desain dan penggunaan basis data. Para pengguna dari sistem dan staf

yang

mengelola

basis

data

membutuhkan

prosedur

yang

mendokumentasikan bagaimana cara menggunakan atau menjalankan sebuah sistem. 5.

Orang (People). Komponen terakhir di dalam database management system adalah orang, orang – orang yang terlibat di dalam menggunakan sistem.

2.5.2 Keuntungan dan kerugian Database Management System 2.5.2.1Keuntungan Database Management System (DBMS) Menurut Connolly dan Begg (2010, p77), keuntungan dari DBMS yaitu sebagai berikut: 1.

Pengulangan data berkurang Data yang sama muncul berkali-kali di dalam file dan format yang berbeda sehingga dapat memboroskan ruang penyimpanan. Dengan DBMS informasi hanya muncul sekali sehingga kapasitas penyimpanan masih banyak tersisa.

2.

Konsistensi data Data lebih akurat, konsisten dan terbaru karena semua perubahan hanya dilakukan di satu tempat.

22

3.

Beberapa informasi didapatkan dari jumlah data yang sama Dengan integrasi data dari data operasional, memungkinkan perusahaan untuk memperoleh informasi tambahan dari data yang sama.

4.

Pembagian data Basis data yang dimiliki perusahaan dapat dibagi kepada akses pengguna yang telah terotorisasi atau mendapatkan hak akses. Dengan kata lain, beberapa pengguna dapat membagi banyak data di dalam perusahaan di tiap departemen perusahaan tersebut.

5.

Keamanan Meningkat Adanya pembatasan hak akses dengan menggunakan password dalam mendapatkan informasi, artinya adalah hanya orang-orang tertentu yang memiliki hak akses untuk mendapatkan informasi tersebut.

6.

Kemudahaan Memelihara Data DBMS

menawarkan

prosedur

standar

untuk

menambahkan,

memodifikasi, menghapus rekaman dan menvalidasi pemeriksaan untuk memastikan bahwa data yang tepat sudah dimasukan dengan benar dan lengkap kedalam masing-masing field. 2.5.2.2 Kerugian Database Management System (DBMS) Menurut Connolly dan Begg (2010, p80), kerugian dari DBMS adalah sebagai berikut: 1.

Kompleksitas Penyediaan fungsi yang kita harapkan dari DBMS yang baik justru membuat DBMS menjadi semakin kompleks. Perancang dan pengembang database, data dan database administrator serta para pengguna akhir harus memahami penggunaan fungsi tersebut untuk menjadikannya sebuah

23

keuntungan atau manfaat yang dapat berguna menjalankan tugas – tugas mereka. 2.

Ukuran Kompleksitas dan luasnya fungsi yang dimiliki DBMS menjadikan DBMS sebuah perangkat lunak yang besar, dengan menempati ruang penyimpanan berkapasitas megabyte serta membutuhkan sejumlah memori yang besar untuk bisa menjalankan fungsinya se-efisien mungkin.

3.

Biaya DBMS Biaya

DBMS

bervariasi,

tegantung

pada

lingkungan

dan

fungsionalitas yang digunakan. Semakin besar lingkungan serta fungsinya, semakin besar pula biaya DBMS tersebut. 4.

Biaya tambahan untuk perangkat keras Biaya kebutuhan akan penambahan ruang penyimpanan DBMS dan database tentu membutuhkan biaya tambahan tersendiri.

2.6

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 :

24

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 - Conceptual Database Design

25

- Logical Database Design - Physical Database Design 5.

DBMS selection (optional) - Application Design - Prototyping (optional) - Implementation - Data conversion and loading - Testing - Operational maintenance

Contoh Database System Development Lifecycle dapat dilihat pada gambar 2.6

26

Gambar 2.6 The stages of database system development lifecycle Sumber : Connolly dan Begg (2010, p314)

27

Penjelasan tahapan – tahapan database system development lifecycle adalah sebagai berikut : 2.6.1 Perencanaan Basis Data (Database Planning) Tahapan ini merencanakan bagaimana langkah – langkah dalam daur hidup basis data agar dapat diwujudkan se-efisien dan se-efektif mungkin. Menurut Connolly dan Begg (2010, p315), langkah pertama yang paling penting dalam perencanaan basis data adalah menggambarkan dengan jelas mission statement dari proyek basis data, kemudian menentukan mission objectives, dimana tiap – tiap objektif tertentu didukung oleh basis data. Perencanaan basis data harus dapat diintegrasikan dengan keseluruhan strategi sistem informasi suatu organisasi. Terdapat tiga isu utama dalam merumuskan strategi sistem informasi, diantaranya : 1.

Identifikasi rencana dan sasaran perusahaan dengan menentukan kebutuhan sistem informasi yang diperlukan.

2.

Evaluasi sistem informasi yang ada sekarang untuk menentukan kekuatan – keukuatan dan kelemahan – kelemahan yang ada.

3.

Penilaian terhadap peluang teknologi informasi yang dapat menghasilkan keuntungan yang kompetitif.

2.6.2

Pendefinisian sistem (System Definition) Penentuan System definition digunakan untuk mendeskripsikan jangkauan

dan batasan dari aplikasi basis data serta pandangan – pandangan utama para pengguna aplikasi. Sebelum mendesain suatu aplikasi basis data, terlebih dahulu mengidentifikasikan batasan – batasan dari sistem yang sedang diteliti dan bagaimana kaitannya dengan bagian lain dari sistem informasi perusahaan. Hal ini diperkuat oleh pendapat Connolly dan Begg (2010, p316), yang mengatakan bahwa

28

hal tersebut dilakukan untuk memastikan bahwa tidak ada pengguna utama basis data yang terlupakan ketika dilakukan pengembangan aplikasi. 2.6.3 Pengumpulan analisis dan kebutuhan (Requirement Collection and Analysis) Menurut Connolly dan Begg (2010, p316), requirement collection and analysis merupakan proses pengumpulan dan analisis informasi tentang bagian perusahaan yang akan didukung oleh aplikasi basis data, dan menggunakan informasi ini untuk mengidentifikasikan kebutuhan pengguna aplikasi terhadap sistem baru. Informasi ini kemudian dianalisis untuk mengindentifikasi kebutuhan yang dimasukan untuk aplikasi basis data yang baru. Ada tiga macam pendekatan untuk mengatur kebutuhan dari sebuah aplikasi basis data dengan berbagai cara pandang pengguna yaitu : 1.

Pendekatan terpusat (Centralized) Menurut Connolly dan Begg (2010, p318), kebutuhan untuk setiap sudut pandang pengguna disatukan menjadi satu set kebutuhan untuk aplikasi basis data. Umumnya pendekatan ini digunakan untuk basis data yang tidak terlalu rumit. Contoh pendekatan centralized dapat dilihat pada gambar 2.7

G ambar 2.7 The centralized approach Sumber : Connolly dan Begg (2010, p319)

29

2.

Pendekatan integrasi sudut pandang (View Integration) Menurut Connolly dan Begg (2010, p318), kebutuhan untuk setiap pandangan pengguna digunakan untuk membangun sebuah model data-data terpisah yang merepresentasikan tiap pandangan pengguna sistem. Hasil dari model data – data tersebut kemudian disatukan di bagian perancangan basis data. Contoh pendekatan view integration dapat dilihat pada gambar 2.8

Gambar 2.8 The view integration approach Sumber : Connolly dan Begg (2010, p320) 2.6.4 Perancangan basis data (Database Design) Menurut Connolly dan Begg (2010, p320), perancangan basis data merupakan proses pembuatan suatu desain atau rancangan untuk sebuah basis data yang akan mendukung operasional dan sasaran suatu perusahaan.

30

2.6.4.1 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 EntityRelationship (ER ).

2.6.4.2 Permodelan Data (Data Modeling) Menurut Connolly dan Begg (2010, p321), dua tujuan utama dari permodelan data adalah untuk membantu dalam pemahaman akan arti (semantic) dari data dan untuk memudahkan komunikasi tentang keubutuhan informasi. Membangun permodelan data tentu membutuhkan kebutuhan entitas, hubungan, dan atribut. Permodelan data dapat digunakan untuk menyampaikan pemahaman dari perancangan basis data tersebut akan kebutuhan informasi yang tentu dibutuhkan oleh perusahaan.

31

2.6.4.3 Tahapan Perancangan Basis Data (Phases of Database Design) Menurut Connolly dan Begg (2010, p322), tahapan setelah data modeling di dalam database design adalah selanjutnya diikuti oleh tiga tahapan dalam merancang basis data. Tahapan – tahapan tersebut antara lain adalah 2.6.4.3.1 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

32

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.9 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 terjadi dimana model menggambarkan keadaan dari hubungan antara entitas yang satu dengan yang lainnya, tetapi tidak ada hubungan antara kedua entias yang utama.

33

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

Gambar 2.10 The view integration approach to managing multiple user views 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.

34

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 gabungan dapat 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 tunggal adalah atribut yang memegang nilai tunggal untuk setiap terjadinya suatu entitas tipe. Sedangkan atribut nilai ganda adalah sebuah atribut yang mempunyai nilai – nilai ganda untuk setiap kejadian dari tipe entitas.

3.

Atribut turunan (Derived attributes) Atribut turunan adalah atribut yang merepresentasikan nilai yang didapat dari nilai atribut yang berhubungan, tetapi tidak dalam kondisi yang sama untuk

35

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 alternate key 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 relasi merupakan sekumpulan atribut kecil yang secara unik mengidentifikasikan setiap kejadian dari tipe entitas yang ada. Kunci relasi dibagi 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

36

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

37

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.11

38

Gambar 2.11 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. 2.6.4.3.2 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

39

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.2 Pemetaan Entitas, Relationship, dan atribut sebuah Relasi Sumber : Connolly dan Begg (2010, p500) Entitas / Relationship / Atribut Pemetaan Relasi 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 Mengkombinasikan entitas – entitas a) kewajiban partisipasi di dua sisi menjadi satu relasi. Menyertakan b) kewajiban partisipasi di satu sisi primary key entitas pada sisi ‘optional’ c) Pilihan partisipasi di dua sisi 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, Membuat relasi untuk menggambarkan complex relationship relationship tersebut. sertakan duplikasi primary keys dari masing – masing

40

Multi-valued attribute

owner ke dalam relasi baru untuk berperan sebagai foreign key. 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 entitas yang tidak tergantung pada beberapa jenis entitas lainnya.

b.

Tipe Entitas Lemah Tipe entitas lemah adalah jenis entitas yang tergantung pada beberapa jenis entitas lainnya. Contoh tipe entitas kuat dan tipe entitas lemah dapat dilihat pada gambar 2.12

Gambar 2.12 Strong and weak entity types Sumber : Connolly dan Begg (2010, p384)

41

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.13 Multiplicity Sumber : Connolly dan Begg (2010 ,p387) 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.14 Multiplicity dengan tipe relasi 1:1 Sumber : Connolly dan Begg (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.

42

Gambar 2.15 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.16 Multiplicity dengan tipe relasi *:* Sumber : Connolly dan Begg (2010, p389) Tabel 2.3 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

43

Optional

Disjoint {or}

kombinasi superclass / subclass Banyak relasi: satu relasi untuk superclass dan satu untuk tiap subclass

Langkah 2.2 Validasi relasi menggunakan normalisasi 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.

44

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.5 Meninjau kembali model 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

45

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. Langkah 2.6.3 Review data model logikal global dengan users 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 di masa yang akan datang dan untuk menilai apakah model data logikal dapat menyesuaikan diri dengan perubahan tersebut. 2.6.4.3.3 Physical Database Design Menurut Connolly 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

46

Gambar 2.17 The view integration approach Sumber : Connolly dan Begg (2010, p325) Connolly dan Begg (2010, p523) juga mengatakan secara rinci bahwa physical database design adalah sebuah proses menciptakan atau menghasilkan deskripsi dari implementasi basis data dalam 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) menguraikan langkah – 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

47

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

48

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.

49

2.6.5 Pemilihan DBMS (Optional) Menurut Connolly dan Begg (2010, p325), seleksi DBMS adalah kegiatan memilih DBMS yang akan digunakan dalam pembuatan basis data. Pemilihan DBMS yang tepat sangat mendukung aplikasi basis data. Menurut Connolly dan Begg (2010, p326), langkah utama dalam pemilihan DBMS adalah sebagai berikut : 1.

Mendefiniskan waktu untuk melakukan studi referensi.

2.

Mencatat 2 atau 3 jenis produk yang akan dievaluasi untuk digunakan.

3.

Mengevaluasikan produk tersebut.

4.

Merekomendasikan produk yang dipilih dan membuat laporan yang mendukung DBMS tersebut.

2.6.6 Perancangan Aplikasi (Application Design) Menurut Connolly dan Begg (2010, p329), perancangan aplikasi adalah proses merancang user interface atau antarmuka pengguna dan program aplikasi yang menggunakan dan memproses basis data. Terdapat dua aspek dalam perancangan aplikasi, yaitu : 1.

Perancangan Transaksi Tujuan utama dari perancangan transaksi adalah untuk menetapkan dan mendokumentasikan karakteristik tingkat tinggi dari transaksi yang dibutuhkan pada basis data, meliputi : a.

Data yang digunakan dalam transaksi

b.

Karakteristik fungsional dari transaksi

c.

Keluaran (output) dari transaksi

d.

Kepentingan pengguna

e.

Rata – rata pengguna yang diharapkan

50

Ada tiga tipe transaksi : -

Retrieval transactions digunakan untuk mengambil data yang ditampilkan di layar atau untuk pembuatan laporan.

-

Update transactions digunakan untuk memasukkan data baru, menghapus data lama, atau memodifikasi data yang ada pada basis data.

-

Mixed transaction merupakan penggabungan antara retrieval transactions dan update transactions.

2.

Perancangan User Interface Beberapa langkah dalam membuat rancangan antarmuka yang baik bagi aplikasi basis data yaitu : a.

Judul yang berarti.

b.

Instruksi yang komprehensif.

c.

Rancangan laporan.

d.

Label Field yang dikenal.

e.

Singkatan dan istilah yang konsisten.

f.

Penggunaan warna yang konsisten.

g.

Batasan dan ruang yang terlihat bagi field- data entry.

h.

Pergerakan kursor yang baik.

i.

Perbaikan kesalahan bagi karakter individu dan keseluruhan field.

j.

Pesan kesalahan bagi nilai yang tidak sesuai.

k.

Penandaan field opsional yang jelas.

l.

Pesan penjelasan bagi field.

m.

Sinyal penyelesaian.

51

2.6.7 Prototyping (Optional) Menurut Connolly dan Begg (2010, p333), prototyping merupakan pembuatan model kerja dari aplikasi basis data, yang mengijinkan perancang atau pengguna untuk mengevaluasi hasil akhir sistem baik dari segi tampilan maupun fungsi yang dimiliki sistem tersebut. Tujuan utama dari prototype yaitu : 1.

Menuntun pengguna menggunakan prototype untuk mengidentifikasi fitur – fitur agar sistem berjalan dengan baik.

2.

Sebagai sarana pengembangan atau mungkin menambah fitur baru pada aplikasi basis data.

Ada dua strategi prototype yang umum digunakan yaitu : a.

Requirement prototyping, menggunakan prototipe untuk menetapkan kebutuhan dari tujuan aplikasi basis data. Ketika kebutuhan sudah terpenuhi, prototipe tidak digunakan lagi atau dibuang (discard).

b.

Evolutionary

prototype,

menggunakan

prototipe

untuk

menetapkan

kebutuhan yang selanjutnya dikembangkan menjadi aplikasi basis data yang bekerja. 2.6.8 Implementasi (Implementation) Menurut Connolly dan Begg (2010, p334), pengertian implementasi yaitu membuat definisi basis data secara eksternal, konseptual, dan internal termasuk program aplikasi. Implementasi merupakan realisasi dari basis data dan perancangan aplikasi. Implementasi basis data dicapai menggunakan data definition language (DDL) dari DBMS yang dipilih atau graphical user interface (GUI). Pandangan pengguna (userview) lainnya juga diimplementasikan dalam tahapan ini. Bagian lain

52

aplikasi program adalah transaksi basis data yang diimplementasikan dengan menggunakan data manipulation language (DML) dari sasaran DBMS. 2.6.9

Data Conversion and Loading Menurut Connolly dan Begg (2010, p334), data conversion and loading

mencakup pengambilan data dari sistem yang lama untuk dipindahkan ke dalam sistem yang baru. Tahapan ini memungkinkan pengembang (developer) untuk mengkonversi dan menggunakan aplikasi program lama untuk digunakan pada sistem baru. Ketika conversion and loading dibutuhkan, prosesnya harus direncanakan untuk memastikan kelancaran transaksi dari keseluruhan operasi. 2.6.10 Testing Menurut Connolly dan Begg (2010, p334), testing adalah proses menjalankan aplikasi untuk menemukan kesalahan – kesalahan. Sebelum digunakan, aplikasi basis data yang baru dikembangkan harus diuji secara menyeluruh. Dalam kenyataan testing tidak luput dari kesalahan. Di Dalam merancang basis data, user dari sistem baru seharusnya terlibat didalam proses testing. Jika data yang asli digunakan, perlu backup untuk mengantisipasi kesalahan atau error. Setelah testing selesai, sistem aplikasi telah siap digunakan oleh pengguna akhir. 2.6.11 Operational Maintenance Tahapan terakhir di dalam database life cycle adalah operational maintenance. Menurut Connolly dan Begg (2010, p335), operational maintenance adalah proses memantau dan memelihara sistem setelah di install. Pada tahap ini sistem beralih ke tahapan pemeliharaan diantaranya : 1.

Memantau kinerja dari sistem

2.

Pemeliharaan dan upgrade aplikasi basis data (jika diperlukan) ketika basis data sepenuhnya bekerja, pemantauan harus memastikan kinerjanya dapat

53

berada dalam tingkat yang dapat diterima. Sebuah DBMS biasanya menyediakan berbagai penggunaan (utilities) untuk membantu administrasi basis data termasuk kegunaan (utilities) untuk mengisi data ke dalam basis data dan untuk memantau sistem. Kegunaan ini memperbolehkan sistem pemantauan untuk memberikan informasi seperti tentang penggunaan basis data,

dan

strategi

eksekusi

query.

Database

administrator

dapat

menggunakan informasi ini untuk memperbaiki sistem agar dapat memberikan kinerja yang lebih baik. 2.7

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.18 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.

54

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.8

Normalisasi Menurut Connolly dan Begg (2010, p416), normalisasi adalah teknik untuk

menghasilkan sejumlah relasi tabel dengan karakteristik yang diinginkan sesuai dengan

kebutuhan

menghilangkan

data

anomali

dari atau

perusahaan.

Normalisasi

ketidak-konsistenan

data

digunakan ketika

suatu

untuk data

dimanipuliasi oleh pengguna. -

Tujuan Normalisasi Menurut Connolly dan Begg (2010, p416), tujuan normalisasi adalah

mengidentifikasikan sekumpulan relasi – relasi yang sama yang mendukung kebutuhan data perusahaan.

55

-

Proses Normalisasi Menurut Connolly dan Begg (2010, p428), dalam proses normalisasi terdapat

beberapa tahapan dalam proses menormalikasikan suatu basis data. Tahap – tahap tersebut antara lain : 1.

Unnormalized Form (UNF) Unnormalized form adalah kondisi dimana sebuah tabel belum masuk ke dalam proses normalisasi atau disebut juga dengan bentuk awal dari tabel. Menurut Connolly (2010, p430) Unnormalized Form adalah suatu tabel atau form yang masih memiliki isi yang berulang.

2.

First Normal Form (1NF) Bentuk normal yang pertama ini dapat dicapai bila telah memenuhi syarat dimana setiap perpotongan baris dan kolom hanya memilik satu dan hanya satu nilai. Tahap 1NF bertujuan untuk mengidentifikasi dan menghilangkan data yang bersifat repitisi didalam tabel.

3.

Second Normal Form (2NF) Setelah setiap kolom hanya mengandung satu dan hanya satu nilai, maka tahap selanjutnya dalam 2NF dengan memisahkan atribut yang bersifat partially dependent menjadi satu tabel yang berdiri sendiri. Jadi, tahap 2NF adalah tahap dimana dalam satu tabel semua atribut bersifat fully dependent terhadap primary key tabel tersebut.

4.

Third Normal Form (3NF) Setelah tahap 2NF data tetap memiliki sedikit redundansi data maka tahap selanjutnya akan dilakukan tahapan 3NF agar tidak ada atribut yang bergantungan dengan atribut primary key. Tahap 3NF adalah hubungan hasil dari 1NF dan 2NF yang tidak ada atribut no- primary key yang bersifat

56

transitif dependent terhadap primary key. Jadi, pada tahap 3NF dilakukan untuk memisahkan atribut-atribut yang bersifat transitive dependent. Konsep terpenting dalam keterkaitan dengan normalisasi adalah Functional Dependencies. 5.

BCNF (Boyce-Codd Nomalized Form) BCNF adalah tahap normalisasi dimana suatu relasi memenuhi syarat jika dan hanya jika semua determinan adalah kunci kandidat. BCNF merupakan

perbaikan

terhadap

3NF

karena

bentuk

3NF

masih

berkemungkinan memiliki anomali. Jadi dapat disimpulkan bahwa tahap 1NF sampai 3NF adalah tahap – tahap yang umum digunakan untuk menormalisasikan suatu data agar tidak ditemukan anomali. Sedangkan BCNF adalah revisi terhadap tahap 3NF. Menurut Connolly & Begg (2010, p421), Functional Dependency mendeskripsikan hubungan antar atribut dalam suatu relasi. Sebagai contoh, jika A dan B adalah atribut dari relasi R, maka B dikatakan functionally dependent terhadap A jika setiap nilai yang dimiliki oleh A diasosiasikan dengan salah satu dari nilai yang dimiliki oleh B. Functional dependency memiliki karakteristik, antara lain : a.

Full Functional Dependency Full Functional Dependency adalah menandakan bahwa jika A dan B adalah atribut dalam suatu relasi, B sepenuhnya bergantung pada A tetapi tidak merupakan bagian dari A.

b.

Partial Dependency Partial dependency adalah keadaan dimana ketika A→B, bila ada atribut yang bisa dihilangkan tetapi masih dalam keadaan dependency.

57

c.

Transitive Dependency Transitive dependency adalah keadaan dimana A, B, C merupakan atribut-atribut dari suatu relasi sehingga A→B dan B→C, maka C merupakan transitive dependent terhadap A melalui B dengan syarat A tidak functionally dependent terhadap B atau C.

2.9

Unified Modeling Language (UML) Dalam merancang sistem informasi yang baik dan benar diperlukan suatu

metode analisis sistem dimana terdiri dari kaidah – kaidah serta aturan – aturan model dan notasi berbasis pada object-oriented. Menurut Satzinger, Jackson, dan Burd (2010, p240), unified modeling language (UML) merupakan serangkaian standar konstruksi model dan notasi secara khusus dirancang untuk pengembangan object-oriented. Jenis – jenis sistem model dari komponen sistem yang menggunakan UML, meliputi : 1.

Data Flow Diagram (DFD)

2.

Entity Relationship Diagram (ERD)

3.

Activity Diagram

4.

Use Case Diagram

5.

Use Case Description

6.

Updated Class Diagram

7.

Sequence Diagram

8.

Communication Diagram

9.

User Interface

2.9.1 User Interface Antarmuka pengguna melibatkan input dan output yang lebih langsung melibatkan pengguna sistem atau bisa dikatakan sebagai interaksi antara pengguna

58

sistem

dengan

sistem

yang

akan

dipakai,

bagaimana

sistem

dapat

menginterpretasikan sudut pandang kebutuhan pengguna dengan tampilan di dalam sistem. Menurut Satzinger, Jackson, dan Burd (2010, p531), user interface merupakan bagian dari sistem informasi yang membutuhkan interaksi pengguna sistem untuk membuat input dan output sistem. Pada saat pengguna menggunakan sistem tersebut, pengguna memiliki tiga aspek user interface, yaitu : 1.

Aspek Fisik User Interface Sebuah user interface yang termasuk perangkat-perangkat yang dapat disentuh secara langsung oleh user, termasuk keyboard, mouse, touch screen, atau keypad. Dan beberapa bagian fisik lain dari sebuah user interface yaitu referensi dokumen yang tercetak, form entri data, dan lainnya yang dapat digunakan oleh user untuk menyelesaikan tugasnya.

2.

Aspek Perseptual User Interface Sebuah user interface yang dapat dilihat, didengar, maupun disentuh (tidak secara fisik) oleh end user. Yang dapat dilihat termasuk data dan instruksi yang ditampilkan pada layar, termasuk bentuk-bentuk, garis, nomor, dan kata-kata.

3.

Aspek Konseptual User Interface User interface yang diketahui oleh end user mengenai penggunaan sistem, termasuk dalam hal-hal yang terjadi di dalam problem domain pada sistem yang dimanipulasi oleh user, operasi-operasi yang dapat dijalankan, dan prosedur-prosedur yang ditaati dalam menjalankan operasi. Contoh user interface dapat dilihat pada gambar 2.19 dan gambar 2.20

59

Gambar 2.19 User Interface “Menu Material / Jasa” Cash Advance – QBArchitect

Gambar 2.20 User Interface “Tambah Material / Jasa” Cash Advance - QB Architect

60

2.10

Rich Picture Untuk menggambarkan atau mendeskripsikan proses bisnis dari suatu

perusahaan kepada orang berbasis non-sistem atau sistem bisa menggunakan banyak cara. Diantaranya adalah menggambarkan proses bisnis yang terjadi di perusahaan secara rinci dengan menggunakan simbol – simbol gambar dan deskripsi singkat dimana gambar beserta deskripsi singkat tersebut dapat menjelaskan proses bisnis kepada orang yang membaca gambar dan deskripsi tersebut. Untuk menggambarkan atau mendeskripsikan proses bisnis tersebut dapat menggunakan rich picture. Menurut Mathiassen et al. (2000, p335), rich picture digunakan selama pemilihan sistem untuk mengekspresikan keseluruhan persepsi dan tugas menghadapi proyek pengembangan sistem. Rich picture tidak digambarkan dengan notasi khusus. Bagaimana pun harus meraih beberapa persetujuan dengan proyek yang terkait yaitu bagaimana menjelaskan aspek yang akan dideskripsikan. Rich Picture harus : a.

Mengenali konsep utama atau pemikiran- pemikiran yang berkaitan dengan situasi yang ada.

b.

Menggunakan simbol atau gambar untuk mewakili ide / pemikiran anda.

c.

Menggunakan garis-garis untuk menghubungkan konsep-konsep utamanya atau pemikiran-pemikirannya dengan penjelasan masing-masing secara singkat. Dikutip dari jurnal (Fountas et al, 2008), sebuah rich picture (ringkasan

situasi) dapat disimpulkan sebagai pandangan menyeluruh dari situasi yang rumit dan perspektif individu, menyoroti kepedulian yang mereka lakukan, kegiatan, dan masalah serta interaksi lainnya. Rich picture mencoba untuk merakit segala sesuatu yang mungkin relevan untuk memahami organisasi. Penemuan ini menyatakan

61

bahwa rich picture tidak termasuk batas-batasan sistem atau referensi khusus pada sistem.

Gambar 2.21 Rich Picture 2.11

Panduan dalam Perancangan Layar Antarmuka (Guidelines For

Designing User Inteface) 2.11.1 Standar Perancangan Antarmuka (Interface Design Standards) Di dalam merancang sebuah sistem diperlukan suatu layar antarmuka antara sistem dengan pengguna dengan tujuan untuk memudahkan interaksi antara sistem dengan pengguna sistem. Layar antarmuka dirancang sedemikian rupa untuk memenuhi standarisasi layar antarmuka yang baik dan benar. Menurut Satzinger, Jackson, dan Burd (2010, p540), standar perancangan antarmuka (Interface Design Standards) adalah prinsip dan aturan umum yang harus diikuti untuk membuat interface atau antarmuka dari setiap sistem yang dikembangkan oleh perusahaan atau organisasi.

62

2.11.2 Delapan Aturan Emas (Eight Golden Rules) Dalam merancang sebuah user interface tentu tidak lepas dari kaidah – kaidah penulisan serta aturan yang baik untuk menghasilkan user interface yang baik pula. Hal ini diperkuat Satzinger, Jackson, dan Burd (2010, p541) yang mengatakan bahwa ada delapan aturan emas (eight golden rules). Delapan aturan ini digunakan untuk merancang layar antarmuka yang interaktif dan mendukung fungsi kegunaan. Contoh dapat dilihat pada gambar 2.22

Gambar 2.22 Eight Golden Rules Sumber : Satzinger, Jackson, dan Burd (2010, p541) Penjelasan gambar 2.22 Eight Golden Rules adalah sebagai berikut: 1.

Berusaha untuk konsistensi (strive for consistency). Merancang konsistensi penampilan dan antarmuka yang fungsional merupakan salah satu tujuan perancangan yang sangat penting . Pengaturan informasi yang diatur di dalam form, nama, serta pengaturan item – item menu, ukuran dan bentuk ikon – ikon serta alur dari sistem harus konsisten.

2.

Memungkinkan

pengguna

yang

sering

menggunakan

sistem

untuk

menggunakan jalan pintas (Enable Frequent Users to Use Shortcuts). Umumnya pengguna yang sudah sering menggunakan aplikasi lebih menginginkan kecepatan dalam mengakses informasi yang diinginkan. jadi tingkat interaksi yang diminta lebih pendek / singkat dan langsung menunjuk

63

fungsi tersebut tanpa melewati alur menu yang panjang dan kotak dialog yang ganda. Shortut keys berfungsi untuk mengurangi jumlah interaksi pengguna sistem dengan sistem untuk meringankan tugas pengguna sistem. 3.

Memberikan atau menawarkan

umpan

balik yang informatif (Offer

Informative Feedback). Umpan balik harus diberikan untuk memberikan informasi kepada pengguna sesuai dengan aksi yang dilakukannya. Pengguna akan mengetahui aksi apa yang telah dan akan dilakukan dengan adanya umpan balik. Umpan balik biasanya berupa konfirmasi, informasi atau suatu aksi. 4.

Merancang dialog untuk menghasilkan penutupan (Design Dialogs to Yield Closure). Urutan tindakan sebaiknya diorganisir atau diatur di dalam suatu kelompok bagian awal, tengah dan akhir. Umpan balik yang diberikan akan memberitahukan pengguna sistem bahwa tindakan yang dilakukan sudah benar dan dapat melanjutkan sejumlah tindakan berikutnya.

5.

Memberikan penanganan kesalahan yang sederhana (Offer Simple Error Handling). Sistem dirancang untuk mencegah pengguna sistem agar tidak melakukan kesalahan fatal. Jika kesalahan fatal tersebut terjadi, maka sistem dapat langsung memberikan pencegahan kesalahan dengan cepat dan memberikan mekanisme yang simpel dan mudah dipahami oleh pengguna sistem.

64

6.

Mengijinkan kemudahan untuk kembali ke tindakan sebelumnya (Permit Easy Reversal of Actions). Sistem dirancang bagi pengguna untuk tidak menyulitkan pengguna. Pengguna sistem dibuat untuk tidak takut akan pilihan menu - menu baru karena adanya menu undo atau back dimana memungkinan pengguna untuk melakukan tindakan kembali jika salah melakukan tindakan.

7.

Mendukung tempat pengendalian internal (Support Internal Locus of Control). Pengguna sistem merupakan pengendali utama terhadap sistem yang ada, bukan sistem yang mengendalikan pengguna jadi pengguna mengontrol sistem utama terhadap menu – menu yang ada.

8.

Mengurangi beban ingatan jangka pendek (Reduce Short-Term Memory Load). Pengguna tidak disulitkan dengan menu – menu yang banyak di dalam sistem atau aplikasi sehingga pengguna dapat melakukan tindakan dengan memilih menu yang simpel tanpa harus mengingat semua perintah atau fungsi menu – menu sistem.

2.12

Pembelian Menurut Hall (2008, p235), prosedur pembelian terdiri dari tugas – tugas

yang meliputi 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 :

65

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).

3.

Receive goods Ketika barang yang dipesan dari supplier masuk 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. 2.13

Persediaan 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

66

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

2.13.1 Fungsi persediaan Menurut Yamit (2005, p5), persediaan timbul disebabkan oleh tidak sinkronnya permintaan dengan penyediaan dan waktu yang digunakan untuk memproses bahan baku. untuk menjaga keseimbangan permintaan dengan penyediaan bahan baku dan waktu proses diperlukan persediaan. Oleh karena itu, terdapat empat faktor yang dijadikan sebagai fungsi perlunya persediaan, yaitu 1.

Faktor waktu Faktor waktu menyangkut lamanya proses produksi dan distribusi sebelum barang jadi sampai kepada konsumen. Waktu diperlukan untuk membuat jadwal produksi, memotong bahan baku, pengiriman bahan baku, pengawasan bahan baku, produksi dan pengiriman barang jadi ke pedagang atau konsumen. Persediaan dilakukan untuk memenuhi kebutuhan selama waktu tunggu (lead time).

2.

Faktor ketidakpastian waktu datang Faktor ketidakpastian waktu datang dari supplier menyebabkan perusahaan memerlukan persediaan, agar tidak menghambat proses produksi maupun keterlambatan pengiriman kepada konsumen. Persediaan bahan baku

67

terikat pada supplier, persediaan barang dalam proses terikat pada departemen produksi dan persediaan barang jadi terikat pada konsumen. Ketidak pastian waktu datang mengharuskan perusahaan membuat jadwal operasi lebih detail pada setiap tingkatan. 3.

Faktor ketidakpastian penggunaan dalam pabrik Faktor ketidakpastian penggunaan dari dalam perusahaan disebabkan oleh kesalahan dalam peramalan permintaan, kerusakan mesin, keterlambatan operasi, bahan cacat, dan berbagai kondisi lainnya. Persediaan dilakukan untuk mengantisipasi ketidaktepatan peramalan maupun akibat lainnya tersebut.

4.

Faktor ekonomis Faktor ekonomis adalah adanya keinginan perusahaan untuk mendapatkan alternatif biaya rendah dalam memproduksi atau membeli item dengan menentukan jumlah yang paling ekonomis. Pembelian dalam jumlah besar memungkinkan perusahaan mendapatkan potongan harga yang dapat menurunkan biaya. Selain itu pemesanan dalam jumlah besar dapat pula menurunkan biaya karena biaya transportasi per unit menjadi lebih rendah. Persediaan diperlukan untuk menjaga stabilitas produksi dan fluktuasi bisnis.

2.13.2 Biaya Persediaan Tujuan manajemen persediaan adalah untuk menyediakan jumlah material yang tepat, lead time yang tepat dan biaya yang rendah. Biaya persediaan merupakan keseluruhan biaya operasi atas sistem persediaan. Di dalam bukunya, Yamit (2005, p9) berpendapat bahwa biaya persediaan didasarkan pada parameter ekonomis yang relevan dengan jenis biaya sebagai berikut :

68

1.

Biaya Pembelian Biaya pembelian adalah harga per unit apabila item dibeli dari pihak luar, atau biaya produksi per unit apabila diproduksi di dalam perusahaan. Biaya per unit akan selalu menjadi bagian dari biaya item dalam persediaan. Untuk pembelian item dari luar, biaya per unit adalah harga beli ditambah biaya pengangkutan. Sedangkan untuk item yang diproduksi di dalam perusahaan, biaya per unit adalah termasuk biaya tenaga kerja, bahan baku dan biaya overhead pabrik.

2.

Biaya Pemesanan Biaya pemesanan adalah biaya yang berasal dari pembelian pesanan supplier atau biaya persiapan apabila item diproduksi di dalam perusahaan. Biaya ini diasumsikan tidak akan berubah secara langsung dengan jumlah pemesanan. Biaya pemesanan dapat berupa : biaya membuat daftar permintaan, menganalisis supplier, membuat pesanan pembelian, penerimaan bahan, inspeksi bahan, dan pelaksanaan proses transaksi. Sedangkan biaya persiapan dapat berupa biaya yang dikeluarkan akibat perubahan proses produksi, pembuatan jadwal kerja, persiapan sebelum produksi, dan pengecekan kualitas.

3.

Biaya Simpan Biaya simpan adalah biaya yang dikeluarkan atas investasi dalam persediaan dan pemeliharaan maupun investasi sarana fisik untuk menyimpan persediaan. Biaya simpan dapat berupa : biaya modal, pajak, asuransi, pemindahan persediaan, keuangan dan semua biaya yang dikeluarkan untuk memelihara persediaan.

69

4.

Biaya kekurangan persediaan Biaya kekurangan persediaan adalah konsekuensi ekonomis atas kekurangan dari luar maupun dari dalam perusahaan. Kekurangan dari luar terjadi apabila pesanan konsumen tidak dapat dipenuhi. Sedangkan kekurangan dari dalam terjadi apabila departemen tidak dapat memenuhi kebutuhan departemen yang lain. Biaya kekurangan dari luar dapat berupa biaya backorder, biaya kehilangan kesempatan penjualan dan biaya kehilangan kesempatan menerima keuntungan. Biaya kekurangan dari dalam perusahaan dapat berupa penundaan pengiriman maupun idle kapasitas.

2.14

Permintaan Independen Model Deterministik Salah satu alasan utama mengapa perusahaan mempunyai persediaan adalah

agar perusahaan dapat membeli atau membuat item dalam jumlah yang paling ekonomis. Menurut Yamit (2005, p47), dengan kata lain perusahaan yang dapat menentukan jumlah paling ekonomis secara regular adalah apabila permintaan independen (permintaan satu barang tidak bergantung pada barang lain). Contoh permintaan independen : permintaan barang material semen, batako, cat dan sebagainya. Yang termasuk teknik atau metode di dalam menentukan permintaan independen model deterministik adalah sebagai berikut : 2.14.1 Economic Order Quantity Economic

Order

Quantity

adalah

jumlah

pemesanan

yang

dapat

meminimumkan total biaya persediaan. Diperkuat dengan pendapat Yamit (2005, p47, metode EOQ digunakan untuk menentukan jumlah paling ekonomis (kebijakan persediaan optimum) untuk permintaan independen, baik untuk item berasal dari luar (supplier) maupun berasal dari dalam perusahaan. Contoh permintaan item independen : pasir, semen, paku (yang artinya adalah item yang berdiri sendiri, tidak

70

bergantung atau mempengaruhi satu sama lain). Metode EOQ dapat dihitung dengan formula sebagai berikut : Biaya pesan per tahun = (biaya per pesanan)*(pesanan pertahun)

Biaya simpan per tahun = (tingkat ‘bunga’)*(biaya unit)*(persediaan rata- rata)

Sehingga, akan didapat total biaya persediaan tahunannya, yaitu : Total biaya per tahun = biaya pesan per tahun + biaya simpan per tahun

dimana, D

= tingkat permintaan (unit per tahun)

S

= biaya pemesanan setiap kali pesan (rupiah per unit)

C

= biaya pembelian unit (rupiah per unit)

I

= tingkat suku bunga per tahun (persen)

H

= IC = biaya simpan per unit per tahun (rupiah per unit per tahun)

Q

= ukuran pemesanan barang (unit) = EOQ

TC

= total biaya pemesanan ditambah dengan biaya simpan (rupiah per tahun) Berdasarkan rumus total cost di atas maka dengan menggunakan sistem

turunan secara matematis dan menetapkan TC sama dengan nol akan didapat rumusan Q dimana merupakan economic order quantity-nya atau biasa disingkat dengan EOQ :

71

2.14.2 Periodic Order Quantity Metode periodic order quantity (POQ) digunakan untuk menentukan jumlah periode permintaan Menurut Yamit (2005, p107), POQ menggunakan logika yang sama dengan EOQ, tetapi POQ mengubah jumlah pemesanan menjadi jumlah periode pemesanan. Hasilnya adalah interval pemesanan tetap atau jumlah interval pemesanan tetap dengan bilangan bulat (integer). Untuk menentukan jumlah pemesanan, sistem POQ cukup dengan memproyeksikan jumlah kebutuhan setiap periode interval pemesanan ekonomis. POQ dapat dihitung dengan formula sebagai berikut:

dimana, EOI

= interval pemesanan ekonomis dalam satu periode

S

= biaya pemesanan setiap kali pesan

H

= biaya simpan per unit = I * C

D

= rata – rata permintaan per periode

2.15

Bill Of Material (BOM) atau Product Structure Records (PSR) Di dalam perusahaan manufaktur atau produksi, diperlukan suatu panduan

atau catatan pembentuk produk dimana catatan ini berguna untuk mengetahui struktur produk yang dibentuk. Hal ini berguna ketika perusahaan akan memproduksi sutu barang jadi yang sama, tentu dengan barang mentah yang sama, maka perusahan bisa memprediksi akan permintaan suatu barang serta mengetahui struktur produk yang dibangun dengan barang yang tepat.

72

Menurut (Yamit, 2005, p153), bill of material merupakan rangkaian struktur semua komponen yang digunakan untuk memproduksi barang jadi sesuai dengan master production schedule (MPS). Secara spesifik bill of material tidak saja berisi komposisi komponen, tetapi juga memuat langkah penyelesaian produk jadi. Tanpa adanya struktur bill of material sangat mustahil untuk dapat melaksanakan sistem master requirement planning (MRP). Contoh bill of material dapat dilihat pada gambar 2.24

Gambar 2.23 Bill Of Material Sumber : Yamit (2005, p156)