BAB 2 LANDASAN TEORI

BAB 2 LANDASAN TEORI 2.1 Teori Dasar 2.1.1 Data dan Basis Data Data adalah fakta fakta atau observasi yang mentah, biasanya mengenai kejadian atau transaksi bisnis (James A. O Brien, 2003, p13), sedangkan menurut Hoffer (2005), data adalah representasi objek yang disimpan dan kejadian-kejadian yang memiliki arti dan penting bagi user. Menurut Connolly (2005, p15), basis data adalah kumpulan data yang terhubung satu sama lain secara logikal, dan deskripsi data itu dirancang untuk memenuhi kebutuhan informasi dalam suatu organisasi, dan menurut Date (2000, p10) basis data adalah kumpulan data-data yang digunakan oleh sistem aplikasi dari perusahaan. 2.1.2 Database Management System Database Management System (DBMS) adalah sebuah sistem software yang memperbolehkan user untuk menggambarkan, membuat, menjaga, dan mengontrol akses ke basis data (Connolly, 2005, p16). Database Management System (DBMS) adalah suatu kumpulan data yang interelasi dan seperangkat program untuk mengakses data-data tersebut (Silberschatz, 2002, p1). 7

8 Fasilitas yang disediakan DBMS antara lain (Connolly, 2005, p16) : a. Memperbolehkan user untuk mendefinisikan data, membuat spesifikasi tipe data dan constraint pada data yang akan disimpan dalam basis data. Biasanya menggunakan Data Definition Language (DDL). Constraint adalah peraturan konsistensi nilai pada basis data yang tidak dapat dilanggar. b. Memperbolehkan user untuk menambah data, mengubah data, menghapus data, dan mengambil data dari basis data. Biasanya menggunakan suatu Data Manipulation Language (DML). Bahasa yang umum digunakan adalah Structured Query Language (SQL). c. Menyediakan fungsi-fungsi untuk mengontrol akses ke basis data : i. Sistem keamanan (Security system), mencegah user yang tidak berwenang agar tidak mengakses ke basis data. ii. Sistem integritas (Integrity system), menjaga konsistensi data yang disimpan. iii. Sistem kontrol (Concurency control), mengijinkan agar data dapat dipakai bersama-sama oleh user lainnya. iv. Sistem kontrol perbaikan (Recovery control system), memperbaiki atau mengembalikan basis data ke kondisi sebelumnya jika terjadi kerusakan pada perangkat keras dan perangkat lunak. v. Katalog yang dapat diakses user (User-accessible catalog), catatan yang berisi deskripsi data pada basis data.

9 Database Application Program adalah suatu program komputer yang berinteraksi dengan basis data sesuai dengan permintaan DBMS (Connolly, 2005, p17). Komponen lingkungan DBMS antara lain (Connolly, 2005, p18) : 1. Perangkat keras (hardware) Perangkat keras dapat berupa komputer tunggal personal, mainframe tunggal, hingga jaringan komputer. Perangkat keras dapat tergantung pada kebutuhan perusahaan dan DBMS yang digunakan. 2. Perangkat lunak (software) Program aplikasi yang digunakan biasanya adalah 3 rd GL (third generation language), seperti C, C++, Java, Visual Basic, COBOL, Fortran, Ada, Pascal, atau bahkan 4 th GL (fourth generation language) seperti SQL yang digabungkan pada 3 rd GL. 3. Data (data) Data merupakan komponen yang paling penting dari lingkungan DBMS. Data berperan sebagai penghubung antara komponen mesin dengan komponen manusia. 4. Prosedur (procedure) Prosedur mengandung instruksi dan peraturan yang mengatur rancangan dan kegunaan basis data, seperti bagaimana masuk ke dalam DBMS, menjalankan dan menghentikan DBMS, dan bagaimana membuat cadangan data dari basis data.

10 5. Manusia (people) Manusia merupakan komponen terakhir yang terlibat langsung dengan sistem, termasuk di dalamnya adalah Database Administrator (DBA), perancang basis data pengembang aplikasi, dan pemakai akhir. 2.1.3 Data Definition Language Data Definition Language (DDL) adalah suatu bahasa yang memungkinkan DBA (Database Administrator) atau user untuk mendeskripsikan dan memberi nama entiti, atribut, dan relasi yang diperlukan untuk aplikasi, bersama dengan segala integritas dan batasan keamanan. Database Administrator adalah seseorang yang bertanggung jawab terhadap realisasi fisikal basis data, termasuk rancangan fisik basis data dan implementasi, keamanan dan kontrol integritas, maintenance sistem operasional, dan memastikan kepuasan performance aplikasi kepada user (Connolly, 2005, p40). Data Definition Language (DDL) adalah perintah-perintah yang digunakan untuk mendefinisikan sebuah basis data, termasuk membuat, mengubah, dan menghapus tabel dan memberikan batasan-batasannya (Hoffer, 2005, p291).

11 2.1.4 Data Manipulation Language Data Manipulation Language (DML) adalah sebuah bahasa yang menyediakan sekumpulan operasi untuk mendukung operasi manipulasi data utama pada data di dalam basis data (Connolly, 2005, p40). Data Manipulation Language (DML) adalah suatu bahasa yang memungkinkan user untuk mengakses dan memanipulasi data yang telah diorganisasikan oleh model data yang tepat (Silberschatz, 2002, p12). Data Manipulation Language (DML) adalah suatu bahasa DBMS yang digunakan untuk membuat, membaca, mengubah, dan menghapus records (Whitten, 2004, p555). Operasi manipulasi data antara lain (Connolly, 2005, p41) : a. Memasukkan data baru ke dalam basis data b. Modifikasi data yang disimpan dalam basis data c. Menampilkan kembali data di dalam basis data d. Menghapus data dari basis data Terdapat dua tipe DML (Connolly, 2005, p41), yaitu : 1. Procedural DML, yaitu sebuah bahasa yang memberikan fasilitas kepada user untuk memberitahukan kepada sistem, data apa yang diperlukan dan bagaimana seharusnya data tersebut diambil. 2. Non-procedural DML, yaitu sebuah bahasa yang memberikan fasilitas kepada user untuk menyatakan data apa yang diperlukan daripada tentang bagaimana data tersebut diambil.

12 2.1.5 Normalisasi Normalisasi adalah sebuah teknik untuk menghasilkan sekumpulan relasi dengan properti yang diinginkan, yang akan memberikan kebutuhan data bagi perusahaan. Relasi adalah sebuah tabel dengan kolom dan baris (Connolly, 2005, p388). Normalisasi adalah proses standard untuk menentukan atribut mana yang akan dikelompokan bersama dalam sebuah relasi (Hoffer, 2005, p211). Proses Normalisasi (Connolly, 2005, p401) : 1. First Normal Form (1NF) Sebelum memasuki tahap 1NF, status sebelum 1NF disebut dengan Unormalized Form (UNF), yaitu sebuah tabel yang mengandung satu atau lebih kelompok yang berulang. First Normal Form adalah sebuah relasi dimana persimpangan dari setiap baris dan kolom yang mengandung satu dan hanya satu nilai saja. 2. Second Normal Form (2NF) Sebuah relasi dimana 1NF dan setiap atribut non-primary-key harus bergantung secara fungsional pada primary key. Primary key adalah kandidat key yang dipilih untuk mengindentifikasi tuple secara unik pada sebuah relasi. Sedangkan tuple adalah baris pada sebuah relasi.

13 Proses normalisasi 1NF ke 2NF melibatkan penghilangan partial dependencies. Jika terdapat partial dependencies, maka atribut functionally dependent dari relasi akan dihilangkan dengan menempatkannya pada sebuah relasi baru bersama dengan copy determinant mereka. Full functional dependency adalah suatu keadaan dimana jika A dan B adalah atribut, B full functionally dependent pada A jika B secara fungsional bergantung pada A, tetapi bukan subset dari A. 3. Third Normal Form (3NF) Sebuah relasi dimana bentuk 1NF dan 2NF, dimana tidak ada atribut yang bukan primary key secara transitif bergantung pada primary key. Transitive dependency adalah sebuah kondisi dimana A, B dan C adalah atribut dari relasi dimana A ke B dan B ke C, maka C adalah transitive dependency pada A melalui B. 4. Boyce-Codd Normal Form (BCNF) Sebuah relasi di dalam BCNF, jika dan hanya jika, setiap determinan adalah candidate key. Candidate key adalah superkey yang bukan merupakan subset dalam relasi. Superkey adalah sebuah atribut atau sekumpulan atribut yang secara unik mengindentifikasi sebuah tuple dalam sebuah relasi. 2.1.6 4th GL (Generation Language) 4GL adalah bahasa pemrograman yang tidak memiliki prosedur standard dimana user mendefinisikan apa yang harus diselesaikan, bukan

14 cara yang digunakan. User tidak mendefinisikan langkah-langkah yang dibutuhkan program untuk mengerjakan sebuah tugas, tetapi mendefinisikan parameter bagi tools yang akan digunakan untuk menghasilkan sebuah program aplikasi (Connolly, 2005, p42). 4GL meliputi (Connolly, 2005, p42) : a. Presentation languages, seperti query languages dan report generators. b. Speciality languages, seperti spreadsheets dan sistem basis data languages. c. Application generators yang mendefinisikan, meng-insert, mengupdate, dan me-retrieve data dari sistem basis data untuk membangun aplikasi. d. Bahasa-bahasa tingkat tinggi yang digunakan untuk menghasilkan kode aplikasi. Salah satu contoh 4th GL adalah SQl (Structured Query Language) (Connolly, 2005, p42). SQL adalah sebuah bahasa yang dirancang menggunakan relasi untuk mengubah input ke dalam output yang diinginkan. SQL memiliki dua komponen utama yaitu : Data Definition Language (DDL) dan Data Manipulation Language (Connolly, 2005, p113).

15 Alasan SQL mudah dipelajari (Connolly, 2005, p114) : a. Bukan merupakan bahasa prosedural. b. SQL merupakan suatu bahasa berformat bebas dimana bagian dari perintahnya tidak harus diketikkan pada lokasi tertentu di layar. c. Struktur perintahnya terdiri atas standar kata-kata dalam bahasa Inggris seperti CREATE TABLE, INSERT, SELECT, dll. d. SQL dapat digunakan oleh user dalam berbagai tingkat, termasuk Database Administrator (DBA), management personnel, application developers, dan pengguna akhir lainnya. Beberapa perintah SQL DML adalah (Connolly, 2005, p117) : a. SELECT untuk query data pada basis data. b. INSERT untuk memasukkan data ke dalam tabel. c. UPDATE untuk update data dalam tabel. d. DELETE untuk menghapus data dalam tabel. 2.1.7 Siklus Hidup Basis Data Basis data merupakan komponen fundamental dalam suatu sistem informasi, penggunaan dan pengembangannya harus dilihat dari perspektif yang lebih luas berdasarkan kebutuhan perusahaan. Maka dari itu siklus hidup sistem informasi dari suatu perusahaan berhubungan erat dengan siklus hidup sistem basis data yang mendukung. Berikut ini adalah gambaran siklus hidup basis data :

16 Database Planning Syst em Definition Requirement Collection and Analysis Database Conceptual Database Design DBMS Selection Logical Database Design Application Design Physical Database Design Prototyping Implementation Data Conversion and Loading Testing Operational Gambar 2.1 Gambar Siklus Hidup Basis Data

17 basis data : Berikut ini uraian dari masing-masing aktivitas pada siklus hidup a. Perencanaan Basis Data (Database Planning) Menurut Connolly & Begg (2005, p285-p286), perencanaan basis data (database planning) merupakan aktivitas manajemen yang mengijinkan tingkatan dari aplikasi basis data untuk direalisasikan seefisien dan seefektif mungkin. Database planning harus diintegrasikan dengan keseluruhan strategi sistem informasi dari perusahaan. Tiga hal penting dalam merumuskan strategi informasi : 1. Mengidentifikasi rencana dan tujuan dari perusahaan berikut menentukan sistem informasi yang diperlukan. 2. Evaluasi kelebihan dan kekurangan sistem informasi yang ada. 3. Penilaian peluang penggunaan teknologi informasi yang menguntungkan. Langkah penting dari tahap ini adalah mendefinisikan secara jelas tentang pernyataan misi untuk proyek basis data. Pernyataan tersebut mendefinisikan tujuan utama dari aplikasi basis data. Bila pernyataan tersebut selesai maka langkah selanjutnya adalah mendefinisikan sasarannya. Pernyataan dan sasaran ini perlu didukung oleh informasi-informasi tambahan yang menentukan pekerjaan apa saja yang harus diselesaikan, sumber-sumber yang mendukung dan biaya yang harus dikeluarkan.

18 b. Definisi Sistem (System Definition) Menurut Connolly & Begg (2005, p286), definisi sistem (System Definition) adalah proses yang memaparkan jangkauan dan batasan dari aplikasi basis data dan pandangan-pandangan utama para pemakai. Sebelum mendesain suatu aplikasi 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 karena membantu untuk memastikan bahwa tidak ada pemakai utama basis data yang terlupa ketika pengembangan aplikasi tersebut. c. Analisa dan Pengumpulan Kebutuhan (Requirement Collection and Analysis) Menurut Connolly & Begg (2005, p288-p291), analisis dan pengumpulan kebutuhan (requirement collection and analysis) adalah sebuah 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.

19 Informasi yang dikumpulkan termasuk : 1. Penjabaran dari data yang digunakan, 2. Detail mengenai bagaimana data digunakan, 3. Kebutuhan tambahan apapun untuk aplikasi basis data yang baru. Informasi ini kemudian dianalisis untuk mengidentifikasi kebutuhan yang dimasukkan 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. Umumnya pendekatan ini dipakai jika basis datanya tidak terlalu kompleks. 2. Pendekatan View Integration Kebutuhan untuk tiap pandangan pemakai digunakan untuk membangun sebuah model yang terpisah yang menginterpretasikan tiap pandangan pemakai tersebut. Hasil datadata model tersebut kemudian disatukan di bagian desain basis data. 3. Kombinasi keduanya

20 d. Desain Basis Data (Database Design) Menurut Connolly & Begg (2005, p291), perancangan basis data (database design) merupakan proses pembuatan suatu desain untuk sebuah basis data yang akan mendukung operasional dan sasaran suatu perusahaan. Ada dua pendekatan untuk merancang sebuah basis data, yaitu : 1. Pendekatan bottom-up Yang dimulai pada tingkat awal dari atribut (yaitu, property dari entitas dan relationship), yang mana melalui analisis dari asosiasi antar atribut, dikelompokkan menjadi hubungan yang merepresentasikan jenis-jenis entitas dan hubungan antar entitas. Pendekatan ini cocok untuk mendesain basis data yang simpel dengan jumlah atribut yang tidak banyak. 2. Pendekatan top-down Metode perancangan top-down adalah metode perancangan basis data dimana perancangan dimulai dari pengembangan model data yang awalnya mengandung beberapa entitas tingkat atau beserta relasi-relasi antara entitas tersebut. Kemudian dilakukan penyesuaian bertahap untuk mengidentifikasi entitas dengan tingkat lebih rendah, hubungan antar mereka, dan atribut-atribut yang dimilikinya. Pendekatan ini biasanya digambarkan melalui ER (Entity Relationship).

21 Pada tahap ini ada bagian yang disebut data modelling yang digunakan untuk membantu pemahaman dari data dan untuk memudahkan komunikasi tentang kebutuhan informasi. Dengan dibuatnya model data dapat membantu memahami : 1. Pandangan tiap pemakai mengenai data 2. Kealamian data itu sendiri, kebebasan representasi fisiknya 3. Kegunaan dari data berdasarkan pandangan pemakai Kriteria untuk model data, yaitu : 1. Structural Validity Konsistensi dengan data yang didefinisikan perusahaan dan menyusun informasi. 2. Simplicity Kemudahan untuk pemahaman baik bagi yang profesional di bidang sistem informasi maupun pemakai yang non-teknis. 3. Expressibility Kemampuan untuk membedakan antara data yang berbeda dan hubungan antar data. 4. Nonredudancy Pembuangan informasi yang tidak ada hubungannya; khususnya representasi dari tiap potongan informasi tepatnya hanya sekali.

22 5. Shareability Tidak spesifik untuk aplikasi dan teknologi khusus apapun dan dengan demikian dapat digunakan oleh banyak orang. 6. Extensibility Kemampuan mengembangkan untuk mendukung kebutuhan baru dengan efek yang minimal bagi pemakai yang ada. 7. Integrity Konsistensi tehadap cara yang digunakan perusahaan dan mengatur informasi. 8. Diagramic Representation Kemampuan untuk merepresentasikan sebuah model menggunakan notasi diagram yang dapat dipahami dengan mudah. Menurut Connolly & Begg (2005, p435-p516), Database Design dibagi dalam tiga tahapan yaitu conceptual database design, logical database design, physical database design. e. Pemilihan DBMS (DBMS Selection) Menurut Connolly & Begg (2005, p295-p296), pemilihan DBMS yang sesuai untuk mendukung aplikasi basis data yang mencakup : 1. Mendefinisikan syarat-syarat referensi studi Menentukan sasaran, batasan masalah, dan tugas yang harus dilakukan.

23 2. Mendaftar 2 atau 3 jenis barang Membuat daftar barang-barang, misalkan darimana barang ini didapat, berapa biayanya serta bagaimana bila 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 terkahir dari seleksi DBMS yaitu mendokumentasikan proses dan untuk menyediakan pernyataan mengenai kesimpulan dan rekomendasi terhadap salah satu produk DBMS. f. Desain Aplikasi (Application Design) Menurut Connolly & Begg (2005, p299-p231), perancangan aplikasi (application design) adalah merancang antarmuka pemakai (user interface) dan program aplikasi yang akan memproses basis data. Ditinjau dari gambar 2.1 bahwa, perancangan basis data dan perancangan aplikasi adalah aktivitas bersamaan pada database application lifestyle. Dalam kasus sebenarnya, adalah tidak mungkin untuk menyelesaikan perancangan aplikasi sebelum perancangan basis data selesai. Dalam perancangan aplikasi harus memastikan semua pertanyaan fungsional dari spesifikasi kebutuhan pemakai (user requirement

24 spesification) yang menyangkut perancangan aplikasi program yang mengakses basis data dan merancang transaksi yaitu cara akses ke basis data dan perubahan terhadap isi basis data (retrieve, update, dan 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. g. Prototyping Menurut Connolly & Begg (2005, p303-p304), prototyping adalah membuat model kerja dari aplikasi basis data, yang membolehkan perancangan atau user untuk mengevaluasi hasil akhir sistem, baik dari segi tampilan maupun fungsi yang dimiliki sistem. Tujuan dari pengembangan prototype aplikasi basis data adalah untuk memungkinkan pemakai menggunakan prototype untuk mengidentifikasi keistimewaan sistem atau kekurangannya, dan memungkinkan perancangan untuk memperbaiki atau melengkapai keistimewaan (feature) dari aplikasi basis data baru.

25 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 basis data dan ketika kebutuhan sudah terpenuhi, prototype tidak digunakan lagi atau dibuang (discard). Sedangkan evolutionary prototyping menggunakan tujuan yang sama, tetapi perbedaan pentingnya adalah prototype tetap digunakan untuk selanjutnya dikembangkan menjadi aplikasi basis data yang bekerja. h. Implementasi (Implementation) Implementation adalah realisasi fisikal dari desain basis data dan desain aplikasi (Connolly & Begg, 2005, p304). Dalam tahap ini juga akan diimplementasikan komponen lain dari aplikasi basis data seperti menu layar, pemasukan data, security dan kontrol integritas. Implementasi basis data dilakukan dengan menggunakan Data Definition Language (DDL) dari DBMS yang dipilih, atau dengan menggunakan Graphical User Interface (GUI), yang menyediakan fungsionalitas yang sama dengan saat menyembunyikan pernyataan low-level DDL. Kemudian bagian dari program aplikasi adalah transaksi basis data, yang diimplementasikan dengan menggunakan Data Manipulation Language (DML), yang biasanya sudah terdapat dalam bahasa pemrograman.

26 i. Konversi dan Loading Data (Data Convertion and Loading) Data conversion and loading adalah suatu proses mentransfer data yang ada ke dalam basis data baru (Connolly & Begg, 2005, p305). Tahap ini hanya dibutuhkan ketika sistem basis data baru menggantikan sistem yang lama. j. Pengujian (Testing) Testing adalah suatu proses mengeksekusi program aplikasi dengan tujuan untuk menemukan kesalahan (Connolly & Brgg, 2005, p305-p306). Jika pengujian berhasil, maka dapat menampilkan error dari program aplikasi dan struktur basis data. Testing memperlihatkan bahwa basis data dan program aplikasi bekerja sesuai dengan spesifikasinya dan menampilkan kebutuhan-kebutuhan untuk kerja yang memuaskan. k. Operational Maintenance Operational maintenance adalah suatu proses memonitor dan memelihara sistem berdasarkan instalasi (Connolly & Begg, 2005, p306-p307). Tahapan ini terdiri dari dari aktivitas-aktivitas berikut : i. Memonitor untuk kerja sistem ii. Memelihara dan memperbaharui aplikasi basis data (jika diperlukan)

27 2.1.8 Desain Konseptual, Logikal, dan Fisikal Basis Data Metodologi desain adalah sebuah pendekatan terstruktur yang menggunakan prosedur, teknik, tool, dan dokumentasi yang mendukung dan memfasilitasi proses desain (Connolly, 2005, p438). Dalam metodologi desain, proses desain dibagi ke dalam tiga tahapan utama, yaitu (Connolly, 2005, p439) : 1. Conceptual Database Design Adalah proses membangun model informasi yang digunakan perusahaan, yang tidak bergantung pada semua aspek fisikal. 2. Logical Database Design Adalah proses pembuatan sebuah model dari suatu informasi yang digunakan dalam sebuah perusahaan yang berdasarkan model data spesifik, tetapi bebas dari DBMS tertentu dan pertimbangan fisik lainnya. 3. Physical Database Design Adalah proses menghasilkan gambaran implementasi sistem basis data pada secondary storage. Menjelaskan relasi dasar (base relation), organisasi file, dan indeks yang digunakan untuk mengakses ke data yang efisien, dan integrity constraints yang berhubungan serta pengukuran keamanan.

28 2.1.8.1 Conceptual Database Design Langkah 1 : Membangun model data konseptual lokal untuk setiap view (Connolly, 2005,p422). Tujuannya untuk membangun sebuah model data konseptual dari perusahaan untuk setiap view yang spesifik. Langkah 1.1 : Indentifikasi tipe entiti. Tujuannya adalah untuk mengidentifikasi entiti utama yang dibutuhkan oleh user. Langkah pertama dalam membangun suatu lokal konseptual data model adalah dengan mendefinisikan objek utama atau entiti yang dibutuhkan oleh user. Salah satu metode untuk mengidentifikasi tipe entiti adalah dengan mengidentifikasi kata benda yang dibutuhkan oleh user. Hasilnya adalah dokumentasi tipe entiti. Langkah 1.2 : Identifikasi tipe relasi / relationship. Tujuannya adalah mengidentifikasi relasi yang penting diantara entity type.

29 Hasilnya adalah dokumentasi tipe relationship. Langkah 1.3 : Identifikasi dan asosiasi atribut suatu entiti. Tujuannya adalah menghubungkan atribut dengan entiti atau tipe relationship yang sesuai. Langkah 1.4 : Tentukan domain atribut. Tujuannya adalah menentukan domain untuk atribut pada model data konseptual. Attribute domain adalah sejumlah nilai yang diperkenankan untuk satu atau lebih atribut. Hasilnya adalah dokumentasi atribut domain. Langkah 1.5 : Tentukan candidate key dan atribut primary key. Tujuannya adalah mengidentifikasi candidate key(s) pada tiap-tiap entiti, jika candidate key lebih dari satu, maka dipilih satu primary key dan candidate keys yang lain menjadi alternate keys. Candidate key adalah super key dalam relasi. Super key adalah atribut atau himpunan atribut yang mengidentifikasi seara unik tuple-tuple yang ada

30 dalam relasi. Primary key adalah candidate key yang dipilih untuk mengidentifikasikan tuple secara unik dalam suatu relasi. Alternate key adalah candidate key yang tidak terpilih sebagai primary key. Langkah 1.6 : Mempertimbangkan penggunaan konsep enhanced modelling (langkah optional). Tujuannya adalah mempertimbangkan penggunaan konsep enhanced modelling seperti : specialization / generalization, aggregation, ataupun composition. Specialization adalah proses untuk memaksimalkan perbedaan antara anggota pada sebuah entitas dengan mengidentifikasikan perbedaan karakteristik mereka. Generalization adalah proses meminimalisasi perbedaan antara anggota pada sebuah entitas dengan mengidentifikasi perbedaan karakteristik mereka. Aggregation adalah merepresentasi has a atau is part of relasi antara entitas dimana relasi has a merepresentasikan keseluruhan sedangkan relasi is part of merepresentasikan bagian dari. Composition adalah bentuk spesifik dari

31 aggregation yang merepresentasikan sebuah hubungan antar entitas. Langkah 1.7 : Memeriksa model untuk redundansi. Tujuannya adalah mengecek apakah terjadi redundansi data. Redundansi data adalah data yang berulang. Langkah 1.8 : Validasi model konseptual lokal dengan transaksi user. Tujuannya adalah memastikan bahwa model konseptual mendukung transaksi-transaksi yang dibutuhkan. Langkah 1.9 : Review model data konseptual dengan user. Meninjau kembali model data konseptual yang telah dibangun untuk memastikan bahwa model tersebut sesuai dengan representasi yang sebenarnya dari persyaratan data yang dibutuhkan oleh perusahaan.

32 2.1.8.2 Logical Database Design Langkah 2 : Membuat dan memvalidasi model data logikal lokal untuk setiap view (Connolly, 2005, p462). Tujuannya adalah untuk membangun suatu model data logikal lokal yang merepresentasikan pandangan tertentu dari perusahaan dan kemudian memvalidasi model ini untuk memastikan strukturnya sudah benar (menggunakan teknik normalisasi) dan untuk memastikan bahwa model tersebut mendukung transaksi yang diminta. Langkah 2.1 : Mendapatkan relasi untuk model data logikal. Tujuannya adalah membuat relasi untuk model data logikal lokal untuk mewakili entiti, relationship, dan atribut yang telah diidentifikasi. Relasi-relasi yang didapat dari model data logikal yang ada pada model data konseptual : a. Strong entity types adalah entitas yang keberadaannya tidak tergantung dengan entitas lain, misalnya entitas staff, cabang. Karakteristik dari strong entity adalah setiap entitas dapat diidentifikasikan dengan primary key dari tipe entitas itu.

33 b. Weak entity types adalah entitas yang keberadaannya tergantung dari entitas lain. Karakteristik dari weak entity adalah atribut yang terdapat pada entitas tersebut tidak dapat mengidentifikasikan tipe entitas itu secara unik. c. One-to-many (1:*) binary relationship types adalah relasi dimana setiap entitas yang ada dapat mempunyai satu relasi atau lebih dar satu relasi dengan entitas yang lain. d. One-to-one (1:1) binary relationship types adalah relasi dimana setiap entitas yang ada hanya dapat mempunyai maksimal 1 relasi dengan entitas yang lain. e. One-to-one (1:1) recursive relationship types adalah relasi dimana setiap entitas yang ada sama pada kedua sisi. f. Superclass / subclass relationship types adalah relasi dimana superclass entity merupakan parent dari subclass entity sebagai child. g. Many-to-many (*:*) binary relationship type adalah relasi dimana setiap entitas dapat mempunyai lebih dari satu relasi dengan entitas lainnya.

34 h. Complex relationship types adalah sebuah relasi yang menghasilkan sebuah relasi untuk merepresentasikan relasi yang ada dan meliputi atribut-atribut yang menjadi bagian dari relasi tersebut. i. Multi-valued attributes adalah merupakan atribut yang mempunyai banyak nilai untuk setiap tipe entitas. Langkah 2.2 : Validasi relasi menggunakan normalisasi. Tujuannya adalah untuk memvalidasi relasi pada model data logikal lokal menggunakan normalisasi. Langkah 2.3 : Melakukan validasi relasi terhadap transaksi yang dilakukan user. Tujuannya adalah untuk memastikan bahwa relasi pada model data logikal mendukung transaksitransaksi yang dibutuhkan oleh view.

35 Langkah 2.4 : Menentukan integrity constraint. Tujuannya adalah memeriksa integrity constraints yang direpresentasikan pada model data logikal. Integrity constraints adalah batasan-batasan yang digunakan agar kelengkapan, keakuratan, dan kekonsistensian sistem basis data terjaga dengan baik. Tipe integrity constraints : 1. Required data Harus mengandung nilai valid (tidak boleh null). 2. Attribute domain constraint Setiap atribut harus mempunyai sebuah domain, satu set nilai yang sah. 3. Entity integrity Primary key dari sebuah tabel harus unik dan tidak mengandung nilai null untuk setiap baris. 4. Referential integrity Sebuah foreign key menghubungkan tiap tuple pada relasi child ke tuple pada relasi parent yang mengandung nilai candidate key yang sama.

36 Referential integrity terdiri atas : a) NO ACTION Mencegah parent dihapus b) CASCADE Jika parent dihapus maka child juga akan dihapus secara otomatis. c) SET NULL Jika parent dihapus, foreign key pada semua child akan di-set null. d) SET DEFAULT Jika parent dihapus, foreign key pada semua child akan di-set default. e) NO CHECK Jika parent dihapus, maka tidak akan melakukan apa-apa untuk memastikan referential integrity dijaga. 5. General constraints Perubahan pada tabel mungkin dibatasi oleh aturan yang mengatur transaksi pada dunia nyata yang direpresentasikan oleh perubahan tersebut.

37 Langkah 2.5 : Review model data logikal lokal dengan user. Tujuannya adalah meninjau kembali model data logikal yang telah dibangun untuk memastikan bahwa model tersebut sesuai dengan representasi yang sebenarnya dari persyaratan data yang dibutuhkan oleh perusahaan. Langkah 2.6 : Menggabungkan model-model data logikal yang ada menjadi model global (langkah optional). Tujuannya adalah menggabungkan model-model data logikal lokal menjadi sebuah model data logikal global yang merepresentasikan views sistem basis data bagi semua user. Langkah 2.7 : Cek perkembangan di masa yang akan datang. Tujuannya adalah memperkirakan apakah akan terjadi perubahan yang signifikan di masa yang akan datang dan untuk menilai apakah model data logikal yang ada sekarang dapat mengikuti perubahan tersebut.

38 2.1.8.3 Physical Database Design Langkah 3 : Menerjemahkan model data logikal global terhadap DBMS yang telah ditentukan. Tujuannya adalah untuk menghasilkan skema relasional sistem basis data dari model data logikal sehingga bisa diimplementasikan pada DBMS yang dituju. Langkah 3.1 : Merancang base relation. Tujuannya adalah untuk menentukan bagaimana merepresentasikan base relation yang telah teridentifikasi pada model data logikal di DBMS yang dituju. Langkah 3.2 : Merancang representasi dari data yang diturunkan. Tujuannya adalah menentukan bagaimana merepresentasikan derrived data yang terdapat pada model data logikal global ke dalam DBMS yang dituju.

39 Langkah 3.3 : Merancang general constraint. Tujuannya adalah merancang general constraint untuk DBMS yang dituju. Langkah 4 : Merancang file organizations dan indexes (Connolly,2005,p501). Tujuannya adalah untuk menentukan file organizations yang optimal untuk menyimpan relasi dasar dan indexes yang dibutuhkan untuk mencapai performa yang dapat diterima, yaitu cara dimana relasi dan tuple disimpan dalam secondary storage. Langkah 4.1 : Menganalisis transaksi. Tujuannya adalah untuk mengetahui fungsi-fungsi transaksi yang berjalan pada sistem basis data dan untuk menganalisis transaksi-transaksi yang penting. Langkah 4.2 : Memilih file organizations. Tujuannya adalah untuk mengetahui file organizations yang efisien untuk base relation.

40 Langkah 4.3 : Memilih indexes. Tujuannya adalah untuk menentukan apakah penambahan indexes akan meningkatkan performa sistem. Langkah 4.4 : Memperkirakan besarnya tempat penyimpanan yang dibutuhkan. Tujuannya adalah untuk memperkirakan besarnya tempat penyimpanan yang dibutuhkan oleh sistem basis data. Langkah 5 : Merancang user views (Connolly, 2005, p515). Tujuannya adalah untuk merancang user views yang telah teridentifikasi selama tahap requirements collection and analysis dari siklus pengembangan sistem basis data. Langkah 6 : Merancang mekanisme keamanan (Connolly, 2005, p516). Tujuannya adalah untuk merancang mekanisme keamanan sistem basis data seperti yang dispesifikasikan oleh user selama tahap

41 requirements collection dari siklus pengembangan sistem basis data. Langkah 7 : Mempertimbangkan penggunaan dari redundansi terkontrol (Connolly,2005,p519). Tujuannya adalah untuk menentukan apakah penggunaan redundansi terkontrol yang telah ternormalisasi akan dapat meningkatkan performa sistem. Langkah 8 : Melakukan pengawasan dan pemeliharaan terhadap sistem operasi (Connoly,2005,p519). Tujuannya adalah untuk mengawasi sistem operasi dan meningkatkan performa dari sistem untuk memperbaiki rancangan-rancangan yang kurang sesuai atau sebagai refleksi adanya perubahan kebutuhan. Ukuran efisiensi merancang database fisikal dalam penyimpanan data antara lain: i. Transaction throughput Jumlah transaksi yang dapat diproses dalam jangka waktu tertentu. ii. Waktu respon Waktu yang melengkapi transaksi tunggal.

42 iii. Tempat penyimpanan Jumlah tempat penyimpanan yang dibutuhkan untuk menyimpan file database. 2.1.9 Bagan Aliran Dokumen (Document Flowchart) Menurut Mulyadi (2001, p60) bagan alir dokumen (dokumen flowchart) digunakan untuk menggambarkan aliran dokumen dalam sistem tertentu. Adapun simbol yang digunakan dalam bagan alir dokumen yaitu: Tabel 2.1 Tabel Simbol Bagan Alir Dokumen Simbol Nama Keterangan Dokumen Menggambarkan semua jenis dokumen, formulir yang digunakan untuk merekam data terjadinya suatu transaksi. 2 Dokumen dan Menggambarkan dokumen asli 1 tembusannya dan tembusannya. Nomor Faktur lembar dokumen dicantumkan di sudut kanan atas.

43 SOP Faktur pen jualan Surat j alan Berbagai dokumen Menggambarkan berbagai jenis dokumen yang digabungkan bersama dalam satu paket. Catatan Mengambarkan catatan akuntansi yang digunakan untuk mencatat data yang direkam sebelumnya di dalam dokumen atau formulir. Catatan yang digambarkan dengan simbol ini adalah : jurnal, buku pembantu, dan buku besar. Penghubung pada Karena keterbatasan ruang halaman yang sama (on-page connector) halaman kertas untuk menggambar, maka diperlukan simbol penghubung untuk memungkinkan aliran dokumen berhenti di suatu lokasi pada halaman tertentu dan kembali berjalan di lokasi lain pada halaman yang sama.

44 Penghubung halaman pada yang Jika untuk menggambarkan bagan alir suatu sistem berbeda connector) (off-page akuntansi diperlukan lebih dari satu halaman, simbol ini harus digunakan untuk menunjukkan kemana dan bagaimana bagan alir terkait satu dengan yang lainnya. Kegiatan Manual Menggambarkan kegiatan manual seperti : menerima order pembeli, mengisi formulir Keterangan, Untuk menambahkan komentar keterangan guna memperjelas pesan yang disampaikan bagan alir. Arsip sementara Menunjukkan tempat penyimpanan dokumen, seperti almari arsip dan kotak arsip. Terdapat dua tipe arsip dokumen : arsip sementara dan arsip permanen. Arsip

45 sementara adalah tempat penyimpanan dokumen yang dokumennya akan diambil kembali dari arsip tersebut di masa yang akan datang untuk keperluan pengolahan lebih lanjut terhadap dokumen tersebut. Untuk pengurutan pengarsipan dokumen digunakan simbol berikut ini : A = menurut abjad. N = menurut nomor urut. T = kronologis, menurut tanggal Arsip permanen Menggambarkan arsip permanen yang merupakan tempat penyimpanan dokumen yang tidak akan diproses lagi dalam sistem akuntansi yang bersangkutan. On-line computer Menggambarkan pengolahan process data dengan komputer secara online.

46 Keying (typing, Menggambarkan pemasukan verifying) data ke dalam komputer melalui on-line terminal. Pita magnetik Menggambarkan arsip (magnetic tape) komputer yang berbentuk pita tidak ya magnetik. Online storage Menggambarkan arsip komputer yang berbentuk online (di dalam memory komputer) Keputusan M enggambarkan keputusan yang harus dibuat dalam proses pengolahan data. Garis alir (flowline) Menggambarkan arah proses pengolahan data. Anak panah tidak digambarkan jika dokumen mengalir ke bawah dan ke kanan. Mulai / Berakhir Menggambarkan awal dan akhir suatu sistem akuntansi

47 2.1.10 State Transition Diagram (S TD) State Transition Diagram (STD) merupakan suatu alat bantu perancangan yang menggambarkan sifat ketergantungan waktu dari sistem (Yourdon, 1989, p259). Komponen utama yang digunakan dalam STD adalah : a. Keadaan sistem (System state) State merupakan suatu kumpulan keadaan atau atribut yang mencirikan suatu benda pada waktu atau kondisi tertentu. State disimbolkan dengan gambar kotak persegi panjang. STATE Gambar 2.2 Simbol State dalam S TD b. Perubahan keadaan (Change of state) Perubahan keadaan digambarkan dengan garis panah yang menghubungkan dua keadaan yang berkaitan. Notasinya adalah : STATE STATE STATE Gambar 2.3 Perubahan State

48 Untuk melengkapi STD diperlukan dua komponen tambahan yaitu : 1. Kondisi (Condition), adalah sebuah sinyal yang menyebabkan perubahan keadaan dari state satu ke state berikutnya. 2. Aksi (Action), adalah yang dilakukan sistem bila terjadi perubahan keadaan. Notasinya adalah : STATE Kondisi Aksi STATE Gambar 2.4 Notasi Kondisi dan Aksi 2.2 Teori Pendukung 2.2.1 Penjualan Menurut Mulyadi (2001, p202), kegiatan penjualan terdiri dari transaksi penjualan barang atau jasa, baik secara kredit maupun secara tunai. Dalam transaksi penjualan kredit, jika order dari pelanggan telah dipenuhi dengan pengiriman barang atau penyerahan jasa, untuk jangka waktu tertentu perusahaan memiliki piutang kepada pelanggannya. Kegiatan penjualan secara kredit ini ditangani oleh perusahaan melaui sistem penjualan kredit.

49 Dalam transaksi penjualan tunai, barang atau jasa baru diserahkan oleh perusahaan kepada pembeli jika perusahaan telah menerima kas dari pembeli. Kegiatan penjualan secara tunai ini ditangani oleh perusahaan melalui sistem penjualan tunai. 2.2.1.1 Fungsi yang Terkait dalam Penjualan Fungsi yang terkait dalam sistem penjualan kredit adalah (Mulyadi, 2001, p211) : 1. Fungsi Penjualan Fungsi ini bertanggung jawab untuk menerima surat order dari pembeli, meng-edit order dari pelanggan untuk menambahkan informasi yang belum ada pada surat order tersebut, meminta otorisasi kredit, menentukan tanggal pengiriman dan dari gudang mana barang akan dikirim, serta mengisi surat order pengiriman. Fungsi ini juga bertanggung jawab untuk membuat back order pada saat diketahui tidak tersedianya persediaan untuk memenuhi order dari pelanggan. 2. Fungsi Gudang Fungsi ini bertanggung jawab untuk menyimpan barang dan menyiapkan barang yang dipesan dari pelanggan, serta menyerahkan barang ke fungsi pengiriman. 3. Fungsi Pengiriman Fungsi ini bertanggung jawab untuk menyerahkan barang atas dasar surat order pengiriman yang diterimanya dari

50 fungsi penjualan dan juga menjamin bahwa tidak ada barang yang keluar dari perusahaan tanpa ada otorisasi dari yang berwenang. 4. Fungsi Penagihan Fungsi ini bertanggung jawab untuk membuat dan mengirimkan faktur penjualan kepada pelanggan, serta menyediakan copy faktur penjualan kepada pelangga, serta menyediakan copy faktur bagi kepentingan pencatatan transaksi penjualan oleh fungsi akuntansi. 5. Fungsi Akuntansi Fungsi ini bertanggung jawab untuk mencatat piutang yang timbul dari transaksi penjualan kredit dan membuat serta mengirimkan pernyataan piutang kepada para debitur, serta membuat laporan penjualan. Di samping itu, fungsi ini juga bertanggung jawab untuk mencatat harga pokok persediaan yang dijual ke dalam kartu persediaan. 2.2.2 Pembelian Menurut Render (2001,p414), pembelian adalah perolehan barang dan jasa. Secara umum, definisi pembelian adalah suatu usaha pengadaan barang dan jasa dengan tujuan yang akan digunakan sendiri, untuk kepentingan proses produksi maupun untuk dijual kembali.

51 2.2.2.1 Tujuan Pembelian Tujuan pembelian menurut Render (2001,p414), tujuan dari kegiatan pembelian adalah: a. Membantu identifikasi produk dan jasa yang dapat diperoleh secara eksternal. b. Mengembangkan, mengevaluasi dan menentukan pemasok, harga dan pengiriman yang terbaik bagi barang dan jasa tersebut. 2.2.2.2 Jenis Transaksi Pembelian Jenis transaksi dalam pembelian dibedakan menjadi dua, yaitu: a. Pembelian tunai adalah proses pembayaran yang dilakukan secara langsung pada saat barang diterima b. Pembelian kredit adalah proses pembayaran yang tidak dilakukan langsung pada saat barang diterima, tetapi pembayaran dilakukan selang beberapa waktu setelah barang diterima sesuai dengan perjanjian kedua belah pihak. 2.2.2.3 Hal-hal yang Harus Diperhatikan dalam Proses Pembelian Hal-hal yang harus diperhatikan dalam proses pembelian adalah: a. Kualitas b. Harga

52 c. Waktu proses Pengawasan perlu dilakukan terhadap pelaksanaan proses pembelian ini, karena pembelian menyangkut investasi dana dalam persediaan dan kelancaran arus barang ke dalam perusahaan. 2.2.2.4 Fungsi yang Terkait dalam Sistem Pembelian Menurut Mulyadi(2001,p299) fungsi yang terkait dalam sistem pembelian adalah sebagai berikut: a. Fungsi gudang Bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang dan mengeluarkan order pembelian kepada pemasok yang dipilih. b. Fungsi pembelian Bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang, dan mengeluarkan order pembelian kepada pemasok yang dipilih. c. Fungsi penerimaan Bertanggung jawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas bahan yang diterima dari pemasok guna menentukan dapat atau tidaknya barang tersebut diterima oleh perusahaan.

53 d. Fungsi akuntansi Bertanggung jawab dalam pencatatan transaksi pembelian yang menjadi hutang sebagai dokumen bukti kas keluar. 2.2.2.5 Prosedur Sistem Pembelian Menurut Mulyadi(2001,p301), jaringan prosedur uang membentuk sistem pembelian adalah sebagai berikut: 1. Prosedur Permintaan Pembelian Dalam prosedur ini fungsi gudang mengajukan permintaan pembelian dalam prosedur surat permintaan pembelian kepada fungsi pembelian. 2. Prosedur Permintaan Penawaran Harga dan Pemilihan Pemasok Fungsi pembelian mengirimkan surat permintaan penawaran harga kepada pemasok untuk memperoleh informasi mengenai harga barang dan berbagai syarat pembelian yang lain untuk memungkinkan pemilihan pemasok yang akan ditunjuk sebagai pemasok barang yang diperlukan oleh perusahaan. 3. Prosedur Order Pembelian Fungsi pembelian mengirim surat order pembelian kepada pemasok yang dipilih dan memberitahukan kepada unit-unit lain dalam perusahaan mengenai order pembelian yang sudah dikeluarkan oleh perusahaan.

54 4. Prosedur Penerimaan barang Dalam prosedur ini fungsi penerimaan barang melakukan pemeriksaan mengenai jenis, kuantitas dan mutu bahan yang diterima dari pemasok, kemudian membuat laporan penerimaan barang untuk menyatakan penerimaan barang dari pemasok tersebut. 5. Prosedur Pencatatan Hutang Dalam prosedur ini akuntansi memeriksa dokumendokumen yang berhubungan dengan pembelian (surat order pembelian, laporan penerimaan barang, faktur dari pemasok) dan menyelenggarakan pencatatan hutang atau pengarsipan dokumen sumber sebagai catatan hutang. 6. Prosedur Distribusi Pembelian Prosedur ini meliputi distribusi rekening yang didebet dari transaksi pembelian untuk kepentingan pembuatan laporan manajemen.