7
BAB 2 LANDASAN TEORI
2.1
Teori – teori dasar / umum
2.1.1
Pengertian Basis Data Basis data ( database ) adalah kumpulan data yang terhubung secara logika yang
bisa dipakai secara bersama dan deskripsi mengenai data tersebut yang didesain untuk memenuhi kebutuhan informasi dari sebuah organisasi (Connolly, 2002, p14). M enurut Date ( 2000,p5) Sistem basis data merupakan sistem penyimpanan record terkomputerisasi. Dengan kata lain sistem basis data merupakan sistem penyimpanan informasi yang terkomputerisasi sehingga memudahkan pemakainya untuk mengambil kembali dan memperbaharui informasi tersebut. Pengertian data, informasi, dan sistem informasi menurut Turban, Rainer, dan Potter (2003, p15), data adalah fakta-fakta yang belum diolah atau gambarangambaran lebih lanjut dari benda-benda, kejadian-kejadian, kegiatan-kegiatan, dan transaksi-transaksi yang ditangkap, direkam, disimpan dan diklasifikasikan, tetapi tidak disusun untuk menyampaikan arti khusus lainnya. Informasi adalah sebuah kumpulan dari fakta-fakta (data) yang disusun di dalam beberapa cara, jadi kumpulan fakta tersebut bisa berarti bagi penerimanya. Sistem Informasi adalah sebuah sistem yang mengumpulkan, mengolah, menyimpan, menganalisa, dan menyebarkan informasi untuk sebuah tujuan tertentu.
8 2.1.2
DBMS ( Database Management System ) M enurut Connolly dan Begg (2002, p16) Database Management System
(DBM S) merupakan suatu sistem piranti lunak yang membuat pemakai dapat mendefinisikan, menciptakan, mengatur dan mengontrol akses ke dalam basis data. DBM S menyediakan beberapa fasilitas sebagai berikut : •
Data Definition Language (DDL) : memperbolehkan pemakai untuk membuat spesifikasi tipe data, mendefinisikan basis data, struktur data dan data constraint untuk disimpan dalam basis data.
•
Data Manipulation Language (DM L) : memperbolehkan pemakai untuk memasukan, memperbaharui, menghapus, dan mengirim atau mengambil data dari basis data 2.1.2.1
Komponen DBMS M enurut Connolly dan Begg (2002, p18), ada 5 (Lima) komponen DBM S
yaitu: 1. Hardware (Perangkat Keras) Perangkat keras yang dibutuhkan untuk menjalankan DBM S dan aplikasi-aplikasi. Contoh : single personal computer, single mainframe, atau komputer yang menggunakan jaringan. 2. Software (Perangkat Lunak) Komponen perangkat lunak terdiri dari perangkat lunak DBM S itu sendiri dan program-program aplikasi, bersama dengan sistem operasi, termasuk perangkat lunak jaringan jika DBM S menggunakan jaringan. Contoh : ’C’, ’C++’, Java, Visual Basic, COBOL 3. Data
9 Data merupakan komponen yang paling penting dari DBM S, khususnya dari sudut pandang pemakai akhir mengenai data. 4. Prosedur Cara untuk menjalankan sistem, seperti bagaimana masuk ke dalam DBM S, memulai dan menghentikan DBM S, bagaimana membuat data backup dari basis data. 5. M anusia Komponen terakhir adalah manusia yang terlibat dengan sistem, termasuk di dalamnya adalah Database Administrator (DBA), perancang basis data, pengembang aplikasi, dan pemakai akhir. 2.1.2.2
Keuntungan DBMS
M enurut Connolly dan Begg (2002, p26), keuntungan dari DBM S, antara lain: 1. Kontrol terdapat pengulangan data. 2. Data yang konsistensi. 3. Semakin banyak informasi yang didapat dari data yang sama. 4. Data yang dibagikan. 5. M enambah Integritas Data. 6. M enambah Keamanan Data. 7. Penetapan Standarisasi. 8. Pengurangan biaya. 9. M empermudah pengoperasian data. 10. M emperbaiki pengaksesan data dan hasilnya. 11. M enambah Produktivitas. 12. M emperbaiki pemeliharaan data melalui independensi data.
10 13. M emperbaiki pengaksesan data secara bersama-sama. 14. Servis backup dan recovery yang lebih baik. 2.1.2.3
Kerugian DBMS
M enurut Connolly dan Begg (2002, p29) kerugian penggunaan DBM S, antara lain: 1. Kompleksitas 2. Size/ukuran. 3. Biaya dari suatu DBM S. 4. Biaya penambahan perangkat keras. 5. Biaya konversi tinggi. 6. M engurangi perfoma penggunaan aplikasi. 7. Kegagalan dapat berdampak lebih kuat. 2.1.3
Database Application Lifecycle
Siklus hidup aplikasi database merupakan tahapan dalam merancang sistem database. Siklus hidup aplikasi database digambarkan seperti bagan berikut ini (Connolly, 2002, p272).
11
Gambar 2.1 Tahapan Database LifeCycle, Connolly (2002, p272)
2.1.3.1
Database Planning
M engatur atau merencanakan aktifitas-aktifitas dengan mengikuti langkahlangkah dari aplikasi database dan diterapkan se-efektif dan se-efisien mungkin. Ada tiga masalah pokok yang harus diperhatikan dalam merumuskan strategi sistem informasi (Connolly, 2002, p273).
12 •
M engindentifikasi rencana dan tujuan perusahaan dengan menentukan sistem informasi yang diperlukan.
•
M engevaluasi sistem informasi yang ada untuk melihat kelebihan dan kekurangannya.
•
Penilaian mengenai peluang IT yang mungkin dapat menghasilkan keuntungan yang kompetitif.
2.1.3.2
System Definition
M endiskripsikan ruang lingkup dari aplikasi database yang akan dibuat termasuk user tempat aplikasi database diterapkan (Connolly, 2002, p274). Sebelum mencoba untuk merancang suatu aplikasi database, sangatlah penting untuk kita mengidentifikasi batasan-batasan sistem yang ada dan bagaimana sistem tersebut berinteraksi dengan bagian sistem informasi yang lain dalam perusahaan tersebut. Penting juga untuk mengikutsertakan didalam batasan-batasan sistem yang kita buat tidak hanya untuk aplikasi dan pemakai saat ini saja tetapi bisa digunakan dimasa yang akan datang. 2.1.3.3
Requirements Collection and Analysis
Proses mengumpulkan dan menganalisa kebutuhan-kebutuhan user. Langkah ini melibatkan pengumpulan dan analisa dari informasi tentang bagian dari perusahaan yang akan dibuat sebuah basis data. Ada banyak teknik untuk memperoleh informasi, dan disebut dengan fact finding techniques. Informasi yang dibutuhkan mencakup : •
Deskripsi tentang data yang digunakan
•
Keterangan secara lengkap bagaimana data tersebut digunakan
13 •
Kebutuhan tambahan lainnya untuk aplikasi data yang baru Informasi ini kemudian akan dianalisa untuk mengidentifikasikan kebutuhan
yang tercakup dalam aplikasi database yang baru. Kebutuhan ini diuraikan dalam dokumen secara bersama dikenal sebagai spesifikasi kebutuhan untuk aplikasi database yang baru. Analisa dan koleksi kebutuhan adalah suatu langkah persiapan untuk merancang suatu basis data. Jumlah data yang dikumpulkan tergantung pada sifat alami dari masalah
dan
kebijakan
perusahaan.
M engidentifikasi kemampuan yang diperlukan untuk suatu aplikasi database adalah suatu aktifitas yang penting, karena sistem dengan kemampuan yang tidak sempurna atau tidak cukup akan menggangu user, yang memungkinkan sistem tersebut tidak digunakan lagi atau ditolak. Bagaimanapun, kemampuan sistem yang berlebihan dapat juga menjadi masalah misalnya suatu sistem yang terlalu rumit dapat membuat sukar untuk penerapan, pemeliharaan, penggunaan atau belajar menggunakan sistem tersebut. 2.1.3.4
Database Design
Salah satu aplikasi yang umum dikenal dalam aplikasi basis data adalah database design (perancangan basis data). Perancangan basis data dimulai ketika analisis terhadap kebutuhan perusahaan telah dilakukan. Di dalam perancangan basis data terdapat suatu metodologi yang membantu dalam membuat suatu basis data. Yang dimaksud dengan metodologi perancangan basis data adalah sebuah pendekatan struktur yang mencakup prosedur, teknik, alat bantu dan tujuan dokumentasi untuk mendukung dan memberi sarana dalam proses perancangan itu sendiri. M etodologi perancangan basis data terdiri dari tahap-tahap yang membantu para perancang dengan teknik yang tepat dalam setiap merancang basis
14 data. M etodologi perancangan basis data juga membantu perancang untuk merencanakan, mengatur dan mengevaluasi pengembangan dari proyek pembuatan basis data (database) tersebut (Connolly, 2002, p419). Dalam metodologi perancangan basis data (database), proses perancangan dibagi menjadi 3 bagian yaitu conceptual database design, logical database design, dan physical database design. 1) Conceptual database design Proses membangun sebuah model dari informasi yang digunakan dalam perusahaan, terbebas dari semua pertimbangan fisik. Conceptual database design meliputi pembuatan sebuah konseptual data model sebagai bagian dari perusahaan. Data model dibangun menggunakan informasi yang didokumentasi dari user requirement. Konseptual database desain secara keseluruhan terbebas dari detil penerapannya, seperti DBM S software, aplikasi program, programming, language, hardware platform atau pertimbangan fisik lainnya. 2) Logical Database Design Proses membangun sebuah model informasi yang digunakan dalam sebuah perusahaan berdasarkan pada sebuah data model tertentu tetapi terbebas dari penggunaan DBM S tertentu dan pertimbangan fisik lainnya. Konseptual data model yang dibuat pada tahap sebelumnya disempurnakan dan dipetakan menjadi sebuah logikal data model. 3) Physical Database Design Physical Database Design dilakukan untuk memutuskan struktur logik secara fisik diimplementasikan ke dalam tujuan Database Management System
15 (DBM S), para perancang juga harus membuat keputusan mengenai bagaimana basis data (database) tersebut dapat diimplementasikan / diterapkan dalam perusahaan. Oleh karena itu, physical database design
harus disesuaikan
dengan DBM S yang spesifik. Terdapat hubungan antara physical dan logical database design, karena keputusan yang diambil pada physical database design untuk meningkatkan kinerja dari basis data (database) tersebut dapat mempengaruhi logical data model. Berikut ini merupakan faktor-faktor yang penting dalam merancang suatu basis data (database) yaitu (Connolly, 2002, p420) : a. M engadakan
pertemuan
dengan
user
sesering
mungkin
untuk
membicarakan rancangan basis data (database) yang akan dibuat. b. M engikuti langkah-langkah yang terdapat dalam metodologi perancangan basis data (database). c. M elakukan pendekatan terhadap data-data yang akan digunakan. d. M enggabungkan pertimbangan integrity dan struktural ke dalam model data. e. M enggabungkan konseptual, normalisasi, dan validasi transaksi ke dalam metodologi model data. f. Gunakan diagram untuk menjelaskan model data tersebut. g. Gunakan Database Design Language (DBDL) untuk menjelaskan tambahan data yang tidak bisa dijelaskan dengan menggunakan diagram. h. Buat kamus data untuk mendukung diagram dari model data dan DBDL. Ulangi langkah-langkah tersebut.
16 2.1.3.5
DBMS Selection
M enurut Connolly dan Begg (2002, p284), pilihan DBM S yang sesuai untuk mendukung aplikasi database. Pemilihan DBM S bertujuan untuk memenuhi kebutuhan perusahaan sekarang dan masa yang akan datang, menyeimbangkan antara biaya pembelian produk DBM S, software atau hardware yang dibutuhkan untuk mendukung sistem database, dan biaya pergantian dan pelatihan staf. Pendekatan paling mudah dalam pemilihan tersebut adalah memeriksa kebutuhan fitur-fitur DBM S. Dalam memilih produk DBM S baru, harus dipastikan proses pemilihan direncanakan dengan baik dan sistem itu memberikan keuntungan nyata bagi perusahaan. Dibawah ini merupakan tabel perbandingan DBM S antara M icrosoft SQL 2000, MySQL AB MySQL 4.0, dan Oracle 9i (www.database-source.com) Tabel 2.1 Perbandingan DBMS
Pembanding Tipe DBM S
Biaya
Kebutuhan piranti keras
Kebutuhan
Microsoft SQL Server 2000 Transactional relation database server $1,489 - $4,999 (Professional Edition) Processor : Pentium 166 M Hz ( minimum) M emory : 64 M B RAM ( minimum ) Hard disk Space : 145 MB (minimum), 380 M B (typical)
Windows
MySQL AB MyS QL 4.0 Relational Database server (Transactional dengan driver InnoDB) $0 ( lisensi umum ) atau $395 (lisensi komersial ) Kebutuhan minimum yang diperlukan oleh system operasinya.
Oracle 9i Transactional relational database server $1,500 - $15,000
Processor : Pentium 166 M hz ( minimum ) M emory : 128 M B RAM (minimum) Hard disk Space : 140 M B pada System Drive ditambah 4.5 GB untuk Oracle Home Drive (FAT) atau 2.8 GB untuk Oracle Home Drive (NTFS) 2000 Linux / Sistem operasi Oracle 9i mendukung
17 Pembanding piranti lunak
Microsoft SQL Server 2000 server atau Windows .NET Server 2003, Internet Explorer 5.0
MySQL AB MyS QL 4.0 berbasis UNIX, MyODBC ( untuk OBDC driver support ), Connector / J ( for JDBC driver support )
Kelebihan
M endukung Cuma – kehandalan dan dokumentasi keamanan tingkat online. enterprise, dapat menjalankan berbagai basis data dalam satu server
Kekurangan
Biaya cukup tinggi, memerlukan Windows 2000 server
Keterbatasan basis data
Pemenuhan ACID Kehandalan
Cuma, secara
Oracle 9i semua platform termasuk platform berbasis Windows, AIX-Based Systems, Compaq Tru64 UNIX, HP 9000 Series HPUX, Linux Intel, Sun Solaris, dan sebagainya. DBM S dengan standar industri mampu mengatur data tingkat enterprise, mendukung semua akses standar basis data pada umumnya, memiliki kehandalan dan tingkat keamanan yang tinggi. Lisensi berdasarkan per individu bukan medianya, dokumentasi sulit dipahami
Tidak sepenuhnya compatible dengan SQL92 ( yang menyebabkan masalah dengan aplikasi server yang membuat query SQLnya sendiri, versi yang Cuma – Cuma tidak mendapatkan bantuan teknis, tidak dapat mengunci objek dibawah level tabel Terbatas Terbatas hingga 32 Tidak diketahui mendekati 2 M iliar index tiap tabel, objek dalam basis ukuran basis data data terbatas hingga ukuran terbesar file dari sistem operasinya. Ya Ya Ya
M endukung Piranti lunak Open - M endukung failover failover cluster, source clusters, pemulihan pemulihan point in point-in-time dan time, dapat kehandalan tingkat melakukan restart enterprise lainnya. jika berhenti
18 Pembanding Keamanan
Standar
2.1.3.6
Microsoft SQL Server 2000 M enggunakan authentikasi pengguna dengan pilihan untuk menyatukan keamanan basis data dengan keamanan Windows 2000 SQL99, XM L, ODBC, JDBC, TSQL
MySQL AB MyS QL 4.0 Tidak diketahui
Oracle 9i Integrated authentication, extensive transaction logging
SQL92 Intermediate, SQL99, ODBC ( memerlukan PL/SQL, MyODBC), JDBC JDBC,
SQL/J, ODBC,
Application Design
M enurut Connolly dan Begg (2002, p287), application design adalah desain user interface dan program aplikasi yang menggunakan dan memproses database. Dalam banyak kasus tidak mungkin menyelesaikan application design sampai desain database itu sendiri selesai. Di lain pihak database ada untuk mendukung aplikasi, dan harus terjadi aliran informasi antara desain aplikasi dan desain database. Kita harus memastikan semua fungsionalitas yang diutarakan dalam spesifikasi kebutuhan user terdapat dalam desain aplikasi untuk aplikasi database. Hal ini termasuk mendesain program aplikasi yang mengakses database dan mendesain desain transaksi (transaction design). Sebagai tambahan dalam mendesain supaya fungsionalitas yang dibutuhkan tercapai kita harus mendesain user interface yang sesuai untuk aplikasi database. Interface ini harus menyajikan informasi yang dibutuhkan dalam cara yang user friendly.
19 2.1.3.7
Prototyping
M embangun suatu model kerja dari aplikasi database. Tujuan utama mengembangkan suatu prototype aplikasi database adalah mengizinkan user untuk menggunakan prototype guna mengidentifikasikan corak sistem apakah bekerja dengan baik dan jika mungkin meningkatkan corak baru kepada aplikasi database. Dengan cara ini kita dapat memperjelas kebutuhan pemakai dan pengembang sistem dalam mengevaluasi kelayakan desain sistem tertentu. Prototype perlu mempunyai keuntungan yang utama yang secara relatif cepat dan murah untuk dibangun. Ada 2 strategi yang digunakan saat ini yaitu requirement prototyping dan evolutionary prototyping. Requirement prototyping digunakan untuk menentukan kebutuhan suatu aplikasi database yang diusulkan dan ketika kebutuhan terhadap suatu aplikasi database tidak lengkap maka prototype tersebut tidak digunakan lagi. Evolutionary prototyping digunakan untuk tujuan yang sama, perbedaan yang penting adalah bahwa prototype tidak dibuang tetapi dengan pengembangan lebih lanjut. Prototype tersebut bekerjasama dengan aplikasi database. 2.1.3.8
Implementation
Implementation merupakan realisasi secara fisik dari database dan desain aplikasi (Connolly, 2002, p292). Pada tahap penyelesaian desain (dimana dapat melibatkan pembuatan prototype atau tidak), kini kita dapat menerapkan basis data dan program aplikasi yang telah kita buat. Implementation basis data menggunakan DDL yang kita pilih dalam melakukan pemilihan DBM S atau dengan menggunakan Graphical User Interface (GUI), yang menyediakan fungsional yang sama dengan pernyataan DDL yang low level. Pernyataan DDL
20 digunakan untuk menciptakan struktur basis data dan mengosongkan file yang terdapat dalam basis data tersebut. Program aplikasi diterapkan dengan menggunakan bahasa generasi ke-4 atau ke-3 yang lebih disukai. Bagian dari program aplikasi ini adalah transaksi basis data, yang diterapkan dengan menggunakan DM L. Transaksi basis data juga dapat dibuat dalam bahasa pemrograman seperti visual basic, Delphi, c, c++, java, cobol, fortran, ada, atau pascal. Kita juga menerapkan komponen lain dari desain aplikasi seperti layar menu, format masukkan data, dan laporan. Pengendalian keamanan dan integritas untuk aplikasi juga telah diterapkan sebagian dari kendali ini telah diterapkan dengan menggunakan DDL, tetapi yang lain mungkin perlu untuk digambarkan diluar dari DDL, sebagai contoh penggunaan yang disediakan DBM S atau kendali sistem operasi. 2.1.3.9
Data Conversion and Loading
Pemindahan data yang ada dalam basis data yang baru dan mengubah aplikasi yang sedang berjalan agar dapat digunakan dalam basis data yang baru. (Connolly, 2002, p293) langkah ini diperlukan hanya ketika suatu sistem basis data baru sedang menggantikan suatu sistem basis data yang lama. Sekarang ini, telah menjadi umum suatu DBM S untuk mempunyai suatu kegunaan yang dapat mengisi file yang ada ke dalam basis data yang baru. Kegunaan yang ada umumnya memerlukan spesifikasi sumber file dan target basis data dan kemudian secara otomatis menkonversi data itu kepada format yang diperlukan basis data yang baru. Kapan saja konversi dan pembuatan diperlukan proses harus dengan baik direncanakan agar basis data tersebut dapat sesuai dengan kebutuhan yang ada.
21 2.1.3.10 Testing Testing adalah suatu proses melaksanakan program aplikasi dengan tujuan menemukan kesalahan (Connolly, 2002, p293). Sebelum diterapkan dalam suatu sistem, basis data harus dilakukan testing terlebih dahulu. Hal ini dicapai dengan penggunaan secara hati-hati untuk merencanakan suatu test dan data yang realistis sedemikian sehingga keseluruhan proses pengujian sesuai dengan metode dan dilaksanakan sesuai aturan yang ada. 2.1.3.11 Operational Maintenance Suatu proses untuk memonitor dan merawat sistem setelah instalasi. Dalam langkah-langkah yang sebelumnya, aplikasi basis data telah secara penuh diterapkan dan diuji. Sistem sekarang pindah ke suatu langkah pemeliharaan, yang melibatkan aktifitas yang berikut (Connolly, 2002, p293) : •
M onitoring perfomance dari sistem. Jika perfomance jatuh dibawah suatu tingkatan yang bisa diterima, penyetelan atau reorganisasi basis data mungkin diperlukan.
•
M aintaining dan meningkatkan mutu aplikasi basis data (ketika diperlukan). Kebutuhan baru disatukan ke dalam aplikasi data dengan mengikuti langkahlangkah sebelumnya yang terdapat dalam database life cycle. Ketika aplikasi basis data sedang beroperasi, perlu dilakukan monitoring secara
dekat untuk memastikan bahwa perfomance dalam tingkatan yang bisa diterima. Suatu DBM S secara normal menyediakan berbagai kegunaan untuk membantu administrasi basis data yang mencakup kegunaan untuk mengisi data ke dalam suatu basis data dan memonitor sistem tersebut.
22 Kegunaan
yang
mengizinkan
sistem
melakukan
monitoring
secara
berdampingan atau berhadapan informasi sebagai contoh, pemakaian basis data mengunci efisiensi dan Query strategi pelaksanaan. Database Administrator (DBA) dapat menggunakan informasi ini untuk menyetel sistem dan untuk memberi perfomance yang lebih baik, sebagai contoh dengan menciptakan index tambahan untuk mempercepat Query, dengan mengubah struktur basis data, atau dengan melakukan kombinasi terhadap tabel yang ada. M onitoring process akan terus berlanjut pada sepanjang hidup suatu aplikasi basis data tersebut dan pada waktu tertentu boleh melakukan reorganisasi basis data untuk mencukupi kebutuhan dari sistem. Perubahan ini menyediakan informasi pada evolusi sistem dan sumber daya yang ada pada masa yang akan datang mungkin diperlukan. Hal ini memungkinkan DBA untuk terlibat dalam perencanaan kapasitas dan untuk memberi tahu staff senior siaga untuk melakukan penyesuaian rencana jika DBM S kekurangan kegunaan tertentu, DBA dapat mengembangkan kegunaan yang diperlukan atau membeli tools tambahan jika tersedia. 2.1.4
Tahapan Perancangan Basis Data
Connoly & Begg (2002, p417-476) mendefinisikan metodologi perancangan basis data atas tiga tahapan, yaitu : perancangan basis data konseptual, perancangan basis data logikal, dan perancangan basis data fisikal. 2.1.4.1
Perancangan Basis Data Konseptual
Tahap ini merupakan proses pembuatan model informasi yang digunakan dalam sebuah perusahaan yang tidak tergantung pada semua masalah fisik. Awal tahap ini dimulai dengan pembuatan conceptual data model perusahaan yang
23 secara keseluruhan bebas dari detail implementasi seperti DBM S yang digunakan, program aplikasi, bahasa pemrograman, platform untuk hardware, tingkat kinerja, maupun bentuk masalah fisik lainnya. Berikut ini merupakan langkah-langkah
metodologi dari perancangan
konseptual basis data : ¾ M embuat data model lokal yang konseptual untuk setiap tampilan
M engidentifikasikan tipe-tipe dari entity
M engidentifikasikan tipe-tipe dari relationship
M engidentifikasikan dan hubungkan atribut dengan tipe-tipe entity atau relationship
M enentukan domain-domain dari atribut
M enentukan atribut-atribut, candidate key, dan primary key
Pertimbangkan penggunaan konsep enhanced modelling (optional step)
Periksa model dari redundancy
M emvalidasikan
model
konseptual
lokal
terhadap
transaksi
pengguna 2.1.4.2
M elihat kembali data model konseptual lokal dengan pengguna Perancangan Basis Data Logikal
Perancangan basis data secara logikal merupakan proses pembuatan model informasi yang digunakan perusahaan berdasarkan pada model data khusus, tapi bebas dari DBM S tertentu dan masalah fisik lainnya. Tahap ini memetakan model konseptual pada sebuah model logikal yang dipengaruhi oleh data model untuk database tujuan. M odel data logikal merupakan sumber informasi untuk tahap
24 perancangan physical, menyediakan suatu kendaraan bagi perancang physical database untuk melakukan pertukaran yang sangat penting untuk perancangan basis data yang efisien. Aktivitas pada logical database design terdiri dari dua langkah besar, dimana langkah pertama adalah membangun sebuah model data logikal lokal dari model data konseptual lokal yang menggambarkan pandangan tertentu dari perusahaan dan kemudian mengesahkan model ini untuk memastikan strukturnya telah benar atau menggunakan teknik normalisasi. Sedangkan langkah kedua atau langkah selanjutnya adalah untuk membuat kombinasi model data logikal lokal individual ke dalam sebuah model data logikal global tunggal yang
menggambarkan
perusahaan. Hasil akhir dari tahapan ini berupa sebuah kamus data yang berisi semua atribut beserta key-nya (primary key, alternate key dan foreign key) dan ERD secara keseluruhan (relasi global) dengan sebuah atribut key-nya. Berikut ini merupakan langkah-langkah metodologi dari perancangan logikal basis data : ¾ M embuat dan memvalidasikan data model lokal yang logikal untuk setiap tampilan
Hilangkan fitur-fitur yang tidak kompatibel dengan model relasional
(optional step)
Turunkan relasi-relasi untuk data model logikal lokal
M emvalidasikan relasi-relasi menggunakan normalisasi
M emvalidasikan relasi-relasi terhadap transaksi pengguna
25
M enentukan integrity constraints (batasan-batasan yang diberlakukan
dalam rangka menjaga suatu database agar tidak berubah menjadi tidak konsisten)
M elihat kembali data model logikal lokal dengan pengguna
¾ M embuat dan memvalidasikan data model global yang logikal
M enggabungkan data model logikal lokal menjadi model global
M emvalidasikan data model logikal global
Periksa untuk perkembangan mendatang
M elihat kembali data model logikal global dengan pengguna
2.1.4.3
Perancangan Basis Data Fisikal
Perancangan basis data secara fisik merupakan proses pembuatan deskripsi dari implementasi database pada secondary storage yang menjelaskan basis relasi, organisasi file, dan indeks yang digunakan untuk memperoleh akses pada data yang efisien, dan masalah integritas lainnya yang berkaitan, dan menentukan mekanisme security. Tahap ini memungkinkan perancang untuk menentukan bagaimana basis data diimplementasikan. Oleh karena itu, rancangan fisikal dirancang untuk DBM S yang khusus. Antara rancangan logical dan fisikal terdapat keterkaitan, hal ini disebabkan karena keputusan yang diambil selama perancangan fisikal untuk meningkatan kinerja bisa mempengaruhi logical data model. Tujuan utama untuk model relasional ini meliputi : •
M embuat kumpulan tabel relasional dan constraints pada tabel tersebut dari informasi yang didapatkan dalam model data logikal.
•
M engidentifikasi struktur penyimpanan tertentu dan metode akses terhadap data untuk mencapai performa optimal dari sistem basis data.
26 •
M erancang proteksi keamanan untuk sistem. Aktivitas dari physical database design adalah menterjemahkan model data
logikal global ke dalam sasaran DBM S, dimana dengan membuat base relation dengan
menggunakan database design
language yang tujuannya untuk
memutuskan bagaimana representasi relasi utama yang diidentifikasi dalam model data logikal global ke dalam DBM S, merancang constraint perusahaan untuk kegiatan transaksi (update and retrieve data), menentukan kebutuhan sumber daya sistem dan organisasi file. Berikut ini merupakan langkah-langkah metodologi dari perancangan fisikal basis data : ¾ M engubah data model global yang logikal untuk target DBM S
M erancang relasi-relasi dasar
M erancang representasi data turunan
M erancang enterprise constraints
¾ M erancang representasi fisik
Analisa transaksi-transaksi
M emilih pengaturan-pengaturan file
M emilih pengindeksan-pengindeksan
M emperkirakan kebutuhan disk space
¾ M erancang tampilan pengguna ¾ M erancang mekanisme keamanan ¾ M empertimbangkan pengenalan dari kontrol pengulangan ¾ M engawasi dan mengatur sistem operasional
27 2.1.5
Entity Relationship Modelling
M enurut Connoly dan Begg (2002,p30), salah satu aspek yang sulit dalam perancangan database adalah kenyataannya bahwa perancang, programmer, dan pemakai akhir cenderung melihat data dengan cara yang berbeda. Untuk memastikan pemahaman secara alamiah dari data dan bagaimana data digunakan oleh perusahaan dibutuhkan sebuah bentuk komunikasi yang non-teknis dan bebas dari kebingungan. Berikut ini adalah notasi Entity-Relationship M odelling menurut Connolly dan Begg :
Entity Name
A
B Relate to
Relationship Name Gambar 2.2 Notasi Entity-Relationship Modelling
2.1.5.1
Entity Type
Tipe entity adalah kumpulan objek-objek dengan properti yang sama, yang didefinisikan oleh perusahaan yang keberadaannya tidak bergantung. Konsep dasar dari bentuk Entity Relationship adalah tipe entity. Sebuah tipe entity memiliki keberadaan yang bebas dan bisa menjadi objek dengan keberadaan
28 fisik atau menjadi objek dengan keberadaan konseptual. Ini berarti perancang yang berbeda mungkin mengidentifikasi entity yang berbeda. Entity Occurence adalah objek dan tipe entity yang dapat diidentifikasi secara unik. 2.1.5.2
Relationship Type
Pengertian relationship type menurut Connolly dan Begg (2002, p334), “Relationship type is a set of meaningful associations among entity types.” Yang dapat diartikan, “Relationship type adalah sekumpulan hubungan berarti antara tipe-tipe entitas.” Derajat dari relationship type (degree of a relationship type) menurut Connolly dan Begg (2002, p335) adalah jumlah tipe-tipe entitas yang berpartisipasi didalam suatu relationship. Entitas-entitas yang berpartisipasi tersebut dikenal sebagai participant dalam relationship itu. Jumlah participant-nya dikenal dengan nama derajat (degree) dalam relationship itu. Oleh karena itu, derajat dari sebuah relationship menunjukkan jumlah dari entitas yang terkait dalam relationship tersebut. Sebuah relationship berderajat dua disebut binary, relationship berderajat tiga disebut sebagai ternary, dan relatonship berderajat empat disebut sebagai quaternary.
Relationship name
Has
Staff
Branch
Gambar 2.3 Diagram representasi Branch has Staff relationship type (Sumber Connolly dan Begg, 2002, p335)
29 2.1.5.3
Attribute
M enurut Connolly dan Begg (2002, p338-340), attribute adalah properti dari sebuah entitas atau relationship
type.
Attribute menyimpan nilai yang
menggambarkan setiap entity occurrence dan mewakili bagian utama dari data yang disimpan dalam basis data. Attribute domain adalah sekumpulan nilai yang diperkenankan untuk satu atau lebih attribute. Setiap attribute yang diasosiasikan dengan sekumpulan nilai disebut domain. Domain menetapkan nilai potensial yang sebuah attribute dapat simpan atau sama dengan konsep domain pada model relasional. Simple attribute adalah sebuah attribute yang tersusun atas komponen tunggal dengan keadaan yang bebas (independent existence). Simple attribute tidak bisa dibagi lagi menjadi komponen yang lebih kecil. Contohnya, posisi dan gaji dari entitas pegawai. Composed attribute adalah sebuah attribute yang tersusun atas banyak komponen,
dimana setiap
komponennya memiliki keadaan
yang bebas
(independent existence). Beberapa attribute lebih lanjut dapat dibagi menjadi komponen-komponen yang lebih kecil dengan masing-masing komponen memiliki keadaan bebas. Contohnya attribute alamat dari entitas kantor cabang yang mengandung nilai (jalan, kota, dan kode pos) dapat dipecah menjadi simple attribute jalan, kota, dan kode pos. Single-valued attribute adalah sebuah attribute yang menyimpan nilai tunggal untuk setiap kejadian dalam entity type.
30 Multi-valued attribute adalah sebuah attribute yang menyimpan lebih dari satu nilai untuk setiap kejadian dalam entity type. Contohnya attribute telepon pada entitas kantor cabang bisa memiliki lebih dari satu nomor telepon. Derived attribute (atribut turunan) adalah sebuah attribute yang mewakili sebuah nilai yang diturunkan dari nilai attribute yang bersangkutan atau sekumpulan attribute, tidak perlu berasal dari entitas yang sama. 2.1.5.4
Key
M enurut Connolly dan Begg (2002, p340-341), candidate key adalah sekumpulan minimal attribute yang secara unik mengidentifikasikan setiap kejadian (occurrence) dari sebuah entity type. Primary key adalah candidate key yang dipilih untuk mengidentifikasikan secara unik setiap kejadian (occurrence) dari sebuah entity type. Alternate key adalah candidate key yang tidak dipilih menjadi primary key. Composite key adalah candidate key yang terdiri dari dua atau lebih attribute. M enurut Connolly dan Begg (2002, p79), foreign key adalah sebuah attribute atau sekumpulan attribute dalam suatu relasi yang sesuai dengan candidate key dari beberapa relasi atau mungkin relasi yang sama.
31
P rimary Key
Manages
Branch
Staff Has
sraffNo {PK} name position salary totalStaff
Area to list
Derrived Attribute
branchNo {PK} address street city postcode telNo [1..3]
Multi-valued attribute
Composite Attribute
Gambar 2.4 Diagram representasi entity Staff dan Branch dengan attributnya (Sumber Connolly dan Begg, 2002, p342)
2.1.5.5
Strong and weak entity type
M enurut Connolly dan Begg (2002, p342-343), Strong entity adalah sebuah tipe entity yang keberadaannya tidak bergantung pada tipe entity lain. Karakteristiknya
adalah
setiap
kejadian
entitynya
secara
unik
mampu
diidentifikasikan menggunakan atribut primay key pada entitynya. Weak entity adalah tipe entity yang keberadaannya bergantung pada keberadaan entity yang lainnya. Karakteristiknya adalah setiap kejadian entity tidak bisa diidentifikasi secara unik hanya dengan menggunakan atribut yang bergantung pada entitynya.
32
Strong Entity
Weak Entity
Client
States
ClientNo {PK} Name Fname Lname telNo
Preference prefType maxRent
Gambar 2.5 Strong entity type dinamakan Client dan weak entity type dinamakan Prefer ence (Sumber Connolly dan Begg, 2002, p342)
2.1.5.6
Structural Constraints
Tipe utama dari batasan hubungan didalam relationship disebut Multiplicity. Multiplicity adalah sejumlah kemungkinan kejadian-kejadian dari sebuah entity type di dalam sebuah hubungan n-nary ketika nilai-nilai yang lain (n-1) ditentukan. M ultiplicity biasanya terdiri dari dua batasan terpisah, yaitu: •
Cardinality : M endeskripsikan jumlah maksimum dari kemungkinan kejadiankejadian yang saling berhubungan untuk sebuah partisipasi entity dalam proses penentuan tipe relationship.
•
Participation : M enentukan apakah semua kejadian-kejadian entity akan ikut berpartisipasi dalam sebuah relationship atau hanya beberapa saja yang ikut berpartisipasi. Jenis-jenis multiplicity menurut Connolly dan Begg (2002, p345) adalah:
1. One-to-One (1 : 1) Relationships
33
Group 1
Relate to
Group 2
A•
r1 • • r2
•C
B•
•D
Gambar 2.6 Gambar One-to-One Relationships
Pada gambar 2.6 kita bisa melihat bahwa A hanya terhubung One-to-One (1 : 1) dengan C, dan B hanya terhubung One-to-One (1 : 1) dengan D. Jadi dari gambar tersebut kita dapat menulis notasi multiplicity-nya dengan gambar di bawah ini.
Relate to Group 1
Group 2 1..1
1..1
M ultiplicity Gambar 2.7 Notasi One-to-One Relationships
2. One-to-Many (1 : *) Relationships
34
Group 1
Relate to
Group 2
A•
r1 • r2 • r3 •
•D
B• C•
•E •F
Gambar 2.8 Gambar One-to-Many Relationships
Pada gambar 2.8 kita bisa melihat bahwa B terhubung One-to-Many (1 : *) dengan D dan E. Jadi dari gambar tersebut kita dapat menulis notasi multiplicitynya dengan gambar di bawah ini.
Relate to Group 1
Group 2 1..1
0..*
M ultiplicity Gambar 2.9 Notasi One-to-Many Relationships
3. Many-to-Many (* : *)Relationships
35
Group 1
A• B• C•
Relate to
Group 2
r1 • r2 • r3 • r4 •
•D •E •F •G
Gambar 2.10 Gambar Many-to-Many Relationships
Pada gambar 2.10 kita bisa melihat bahwa A terhubung One-to-Many (1 : *) dengan D dan E. Sedangkan E terhubung One-to-Many (1 : *) dengan A dan B. Jadi dari entity Group 1 (value-nya A dari gambar di atas) dan Group 2 (value-nya E dari gambar di atas) terhubung Many-to-Many (* : *). Dari gambar tersebut kita dapat menulis notasi multiplicity-nya dengan gambar di bawah ini.
Relate to Group 1
Group 2 0..*
1..*
M ultiplicity Gambar 2.11 Notasi Many-to-Many Relationships
M asalah yang dapat timbul dari Entity Types Model adalah: •
Fan traps, terjadi ketika sebuah model merepresentasikan sebuah relasi antara tipe-tipe dari entity, tetapi jalur yang terdapat diantara kejadian-kejadian entity tertentu masih ambigu.
36 •
Chasm traps, terjadi ketika sebuah model menganjurkan keberadaan sebuah relasi diantara tipe-tipe dari entity, tetapi tidak terdapat jalur diantara kejadiankejadian entity tersebut.
2.1.5.7
Integrity Constraints
Integrity constraint merupakan batasan yang kita inginkan untuk mencegah database menjadi tidak konsisten. Integrity constraints dibagi menjadi 4 bentuk dasar, yaitu : • Required data, beberapa atribut harus selalu mengandung nilai yang valid, dengan kata lain tidak boleh mengandung nilai null. • Attribute domain constraint, setiap atribut mempunyai domain sendiri, yaitu sekumpulan nilai yang sah untuk suatu atribut. Contohnya pada nilai atribut JenisKelamin hanya terdiri dari ‘P’ atau ‘L’. • Entity integrity, primary key dari sebuah entry tidak boleh mengandung nilai null. Setiap tuple harus mempunyai sebuah primary key. • Referential integrity, sebuah foreign key menghubungkan setiap tuple didalam relasi anak kepada tuple dalam relasi induk yang mengandung nilai candidate key yang cocok. Secara umum ada dua kondisi pada hubungan child pada relationship: Mandatory, null tidak diijinkan. Optional, null diijinkan. Contoh pada hubungan 1:* jika tuple parent dihapus maka ada beberapa strategi yang mempengaruhi nilai child yaitu :
37 NO ACTION, jika tuple parent dihapus maka nilai child-nya tidak terjadi apaapa atau tidak mengalami perubahan. CASCADE, jika tuple parent dihapus maka nilai child-nya juga ikut terhapus. SET NULL, jika tuple parent dihapus maka nilai child-nya diset null. SET DEFAULT, jika tuple parent dihapus maka nilai child-nya ikut berubah sesuai dengan nilai default yang sudah diatur. NO CHECK, jika tuple parent dihapus maka tidak dilakukan pengecekan pada nilai child-nya. 2.1.6
Normalisasi
2.1.6.1
Pengertian Normalisasi
M enurut Connolly dan Begg (2002, p379), normalisasi adalah teknik untuk mengorganisasikan data ke dalam tabel-tabel untuk memenuhi kebutuhan pemakai di dalam sebuah organisasi. Tujuan dari normalisasi adalah untuk mengurangi redudancy (pengulangan detil dari suatu tabel pada tabel yang lain) menghilangkan kerangkapan data, untuk mengurangi kompleksitas dan untuk mempermudah memodifikasi data. 2.1.6.2
Data Redundancy and Update Anomalies
Anomali adalah efek samping yang tidak diharapkan (misalnya menyebabkan inconsistency (tidak konsisten) data atau membuat suatu data menjadi hilang saat data lain dihapus) yang muncul dalam suatu proses perancangan basis data. Suatu tujuan relational desain database yang utama adalah menggolongkan atribut kedalam hubungan-hubungan untuk memperkecil data redundancy dan dengan demikian mengurangi tempat penyimpanan file yang diperlukan oleh hubungan-hubungan dasar yang diimplementasikan. Hubungan-hubungan yang
38 memiliki data redundant mungkin memiliki masalah yang disebut update anomalies, yang diklasifikasikan sebagai insertion, deletion, atau modification anomalies. 2.1.6.3
Functional Dependency
Functional Dependency menguraikan hubungan antara atribut-atribut dalam sebuah relasi. Sebagai contoh, jika A dan B adalah atribut dari relasi R, B adalah secara fungsional bergantung kepada A (ditandai AÆB), jika setiap harga dari A diasosiasikan dengan tepat satu harga dari B. (A dan B masing-masing boleh dari satu atau lebih atribut.) 2.1.6.4
Bentuk Normal
Normalisasi sering dieksekusi sebagai langkah-langkah yang berangkai/berseri. Bentuk normal adalah suatu aturan yang dikenakan pada relasi-relasi dalam basis data dan harus dipenuhi oleh relasi-relasi tersebut pada tingkatan normalisasi. Suatu relasi dikatakan berada dalam bentuk normal tertentu jika memenuhi kondisi-kondisi tertentu. Secara umumnya normalisasi dibagi menjadi tingkatan, yaitu : 1. Bentuk Normal Pertama ( First Normal Form / 1NF) M enurut Connolly dan Begg (2002, p387), Un- normalized form (UNF) adalah sebuah tabel yang mengandung lebih dari satu bagian yang berulang (repeating group). Bentuk normal pertama adalah sebuah hubungan dimana irisan (intersection) dari setiap baris dan kolom hanya mengandung satu nilai. Untuk mengubah table UNF ke dalam bentuk normal pertama (1NF) harus mengidentifikasi dan menghilangkan bagian yang berulang (Repeating Group) pada tabel. Sebuah repeating group adalah sebuah atribut atau kumpulan atribut
39 pada suatu tabel yang terdapat lebih dari satu nilai (multiple) untuk sebuah occurrence tunggal dari kunci (key) atributnya yang ditunjuk dalam tabel. Ada 2 pendekatan umum untuk menghilangkan repeating group pada tabel UNF, antara lain : a.
Pendekatan pertama, dengan menghilangkan repeating group dengan memasukan data yang berlebihan ke dalam kolom dan baris kosong. Sehingga hasil dari table nantinya hanya mengandung nilai atomic (tunggal).
b. Pendekatan kedua, menghilangkan repeating group dengan menempatkan data yang berlebihan, selanjutnya dengan meng-copy atribut kuncinya yang asli dalam sebuat relasi yang dipisahkan. Kedua pendekatan ini benar, tetapi pendekatan kedua awalnya menghasilkan relasi yang paling sedikit pada 1NF dengan mengurangi redudansi. Jika menggunakan pendekatan pertama relasi dari 1NF adalah buruk, selanjutnya selama langkah normalisasi berikutnya akan menghasilkan relasi yang sama yang dihasilkan oleh pendekatan kedua. Akan tetapi hasil dari normalisasi bentuk pertama masih bisa menyebabkan update unomalies, sehingga diperlukan normalisasi ketahapan selanjutnya yang dinamakan bentuk normal kedua (2NF). 2. Bentuk normal kedua (Second Normal Form / 2NF) M enurut Connolly dan Begg (2002, p392), bentuk normal kedua adalah berdasarkan
konsep
ketergantungan
fungsional
penuh
(Full
functional
dependency). Full Functional Dependency dinyatakan dengan jika A dan B adalah atribut dari suatu relasi, B adalah fungsional ketergantungan penuh (fully fungtional dependency) pada A jika B adalah secara fungsional bergantung pada A, tetapi bukan merupakan himpunan bagian dari A, Jelasnya bentuk normal kedua
40 adalah sebuah relasi di dalam bentuk normal pertama dan setiap atribut yang bukan primary key (non-primary key) adalah secara fungsional tergantung pada primary key. Proses normalisasi dari relasi 1NF ke 2NF melibatkan penghilangan dari bagian yang ketergantungan. 3. Bentuk normal ketiga (Third Normal Form / 3NF) M enurut Connolly dan Begg (2002, p394), bentuk normal ketiga adalah berdasarkan pada konsep peralihan ketergantungan (transitive dependency). Transitive dependency adalah sebuah kondisi dimana A, B, dan C adalah atribut dari sebuah relasi bahwa jika A->B dan B->C, maka C adalah secara transitif bergantung pada A melewati B (menyatakan bahwa A tidak secara fungsional tergantung pada B atau C). Pada bentuk normal ketiga, sebuah relasi pada bentuk normal pertama dan kedua dan dimana tidak ada atribut non-primary key secara transitif bergantung (transitively dependent) pada primary key. Proses normalisasi dari relasi 2NF ke 3NF melibatkan penghilangan dari ketergantungan transitif. Jika sebuah ketergantungan transitif muncul, maka dihilangkan ketergantungan transitif antara atributnya dengan menempatkan atribut tersebut ke dalam relasi baru, selanjutnya dengan sebuah salinan dari determinannya. 4. Bentuk Boyce-Codd normal form (BCNF) M enurut Connolly dan Begg (2002, p398), BCNF didasari ketergantungan fungsional (functional depedencies) dengan memperhitungkan semua candidat key dalam sebuah hubungan, akan tetapi BCNF juga mempunyai batasan tambahan bila dibandingkan dengan definisi 3NF. Sebuah hubungan yang ada di BCNF jika dan hanya jika setiap determinant adalah candidat key. Untuk mengetahui status sebuah hubungan didalam BCNF, identifikasi terhadap determinant yang
41 diperlukan dan determinant itu harus dalam bentuk candidat key. Perbedaan dari BCNF dan 3NF : didalam BNCF ketergantungan fungsional A-->B, 3NF memperbolehkan ketergantungan ini dalam hubungan jika B adalah attribut primary key dan A bukan candidat key, sedangkan BCNF menuntut untuk ketergantungan ini tetap dalam sebuah hubungan, A harus candidat key. Untuk itu BCNF lebih kuat dari 3NF, setiap hubungan dalam BCNF juga ada dalam 3NF. Akan tetapi, sebuah hubungan dalam 3NF tidak diperlukan dalam BCNF. 5. Bentuk normal keempat (Fourth Normal Form / 4NF) M enurut Connolly dan Begg (2002, p408),Fourth normal form (4NF) adalah sebuah hubungan yang ada didalam Boyce-Codd normal form (BCNF) dan tidak mengandung nontrivial multi-valued dependencies. Bentuk 4NF adalah bentuk normal form yang lebih kuat dari BCNF yang mencegah relation mengandung nontrivial MVDs dan karenanya data menjadi redudancy (fagin,1997). Normalisasi dari bentuk BCNF menjadi 4NF meliputi penghilangan M VD dari hubungan dengan menempatkan attribut dalam sebuah hubungan yang baru mendekati sebuah salinan dari determinant. M enurut Connolly dan Begg (2002, p407), Multi-valued dependency (M VD) mewakili sebuah ketergantungan attribut (contoh A, B, dan C) dalam sebuah hubungan, untuk setiap nilai dari A ada satu kumpulan nilai untuk B dan satu kumpulan nilai untuk C. Tetapi kumpulan nilai untuk B dan C berdiri satu sama lain. 2.1.7
Structured Query Language ( SQL )
M enurut Connolly dan Begg (2002, p521), Structured Query Language (SQL) merupakan bahasa yang dipergunakan untuk database relasional dan didukung oleh
42 semua produk di pasaran. SQL awalnya dikembangkan oleh IBM Research pada awal tahun 1970. Pertama kali diterapkan pada prototype komputer IBM yang bernama System R. Structured Query Language (SQL) adalah suatu bahasa standard untuk implementasi operasi-operasi pada sistem basis data model relational Standard ANSISQL92 atau International Standard Database Structured Query Language. SQL dapat dibagi menjadi 2 kategori : 1) DDL (Data Definition Language) Adalah bagian dari SQL untuk mendefinisikan objek pada basis data Contoh : a. Create Table Digunakan untuk menciptakan tabel basis data. Tabel berbentuk 2 dimensi berupa atribut atau kolom dan tuple atau row. Sintaks : Create Table Table_Name (Column_Name[,Column_Name].....[,Primary_Key_Definition][,Foreign_Key_ Definition]) b. Alter Table Digunakan untuk mengubah struktur table, untuk menambah kolom baru, mengubah standar dari suatu kolom, menghapus suatu kolom. Sintaks: Alter Table Table_Name add|drop colum data-type c. Drop Table Digunakan untuk menghapus tabel yang sudah ada.
43 Sintaks : Drop Table Table_Name. 2) DM L (Data Modification Language) Adalah bagian dari SQL yang dapat digunakan untuk memanipulasi data yang ditampilkan dalam bentuk seperti tabel. a) SELECT Digunakan untuk mengambil tuple dan kolom dari suatu tabel basis data. Sintaks : SELECT select-list FROM table-list WHERE search-condition GROUP BY grouping-column-list HAVING search-condition ORDER BY order-by-columnlist. b) INSERT Digunakan untuk menyisipkan satu tuple atau record atau baris baru ke dalam suatu tabel basis data. Sintaks : INSERT
INTO
table-name
(Column_Name[,Column_Name])
VALUES
(Column_value[,Column_Value]) c) UPDATE Digunakan untuk memperbaharui nilai dari suatu tuple dalam suatu table basis data. Sintaks : UPDATE table-name SET (Column_name Column_Value[,Column_Name Column_Value]]) WHERE search-condition. d) DELETE
44 Digunakan untuk menghapus satu atau beberapa atau semua tuple dalam suatu tabel basis data. Sintaks: DELETE select-list FROM table-name WHERE search-condition 2.1.8
Database Secu rity
M enurut Connolly dan Begg (2002, p521), Pertimbangan penerapan keamanan tidak hanya pada data dalam suatu basis data, pelanggaran atas keamanan mungkin akan mempengaruhi bagian lain dari sistem, yang mana mungkin akan mempengaruhi basis data itu. Keamanan basis data meliputi perangkat keras, perangkat lunak, data dan orang. Secara efektif menerapkan keamanan basis data memerlukan kontrol yang tepat. Kebutuhan ini sering dilalaikan atau dilewatkan di masa lalu, kini sistem keamanan semakin dikenali oleh organisasi. Alasan untuk perubahan ini adalah terus meningkatnya sejumlah data penting yang disimpan pada komputer dan
akan
membahayakan perusahaan bila tidak disediakan sistem keamanan untuk data penting ini. Suatu basis data mempresentasikan sumber daya penting yang harus dipastikan keamanan untuk kontrol yang tepat. Kita mempertimbangkan keamanan basis data dalam hubungan dengan situasi berikut : •
Pencurian data
•
Hilangnya kerahasiaan
•
Hilangnya privasi
•
Hilangnya integritas
45 2.1.9
Diagram Aliran Dokumen ( DAD )
M enurut Drs.Husein Umar (2001, p98), Sistem yang berdasarkan pada pemakaian teknologi komputer banyak terkait dengan desain salah satunya implementasi pada alur ( aliran ) dokumen. Dimana Diagram / bagan tersebut memperlihatkan input apa saja yang digunakan untuk menghasilkan output yang diinginkan berdasarkan pengolahan yang telah ditentukan. Simbol – simbol pada Diagram Aliran Dokumen :
Simbol arah arus proses Dokumen. Simbol ini digunakan untuk menggambarkan semua jenis dokumen, yang merupakan formulir yang digunakan untuk merekam data terjadinya suatu transaksi. Nama dokumen dicantumkan ditengah simbol. Contoh dokumen yang digambarkan dengan simbol ini adalah: faktur penjualan, surat order pembelian, cek, bukti memorial, bukti kas keluar (voucher), surat permintaan dan pengeluaran barang gudang, faktur dari pemasok, dan bukti kas masuk. Bagan alir harus menunjukkan dengan jelas darimana suatu dokumen masuk ke dalam sistem dan ke mana (sistem lain) dokumen keluar dari sistem. Semua dokumen akhirnya harus mengalir ke (a) simbol arsip, (b) simbol keluar dari sistem, dan (c) simbol penghubung halaman yang berbeda (off-page connector).
46
2 1 faktur
Dokumen dan tembusannya. Simbol ini digunakan untuk menggambarkan dokumen asli dan tembusannya. Nomor lembar dokumen dicantumkan di sudut kanan atas. Berbagai
Dokumen. Simbol ini digunakan
untuk
Surat Muat Srt. Order Penj.1
menggambarkan
berbagai
jenis
dokumen
yang
3
Faktur Penjualan
digabungkan bersama dalam satu paket. Nama dokumen dituliskan di dalam masing-masing simbol dan nomor lembar dokumen dicantumkan di sudut kanan atas simbol dokumen yang bersangkutan. Simbol dalam contoh tersebut menggambarkan faktur penjualan lembar ke 3 dilampiri dengan surat order penjualan lembar ke 1 dan surat muat. Catatan. Simbol ini digunakan untuk menggambarkan catatan akuntansi yang digunakan untuk mencatat data yang direkam sebelumnya dalam dokumen atau formulir. Nama catatan akuntansi dicantumkan di dalam simbol ini. Catatan akuntansi yang digambarkan dengan simbol ini adalah: jurnal, buku pembantu, dan buku besar. Penghubung
pada
halaman
yang
sama.(on-page
connector). Dalam menggambarkan bagan alir, arus dokumen dibuat mengalir dari atas ke bawah dan dari kiri ke kanan. Karena keterbatasan ruang halaman kertas untuk menggambar, maka diperlukan simbol penghubung untuk memungkinkan aliran dokumen berhenti di suatu lokasi
47 pada halaman tertentu dan kembali berjalan di lokasi lain pada halaman yang sama. Dengan memperhatikan nomor yang tercantum dalam simbol penghubung pada halaman yang sama, dapat diketahui aliran dokumen dalam sistem akuntansi yang digambarkan dalam bagan alir. Akhir arus dokumen dan mengarahkan pembaca ke simbol
penghubung
halaman
yang
sama
yang
bernomer seperti yang tercantum dalam simbol tersebut. Awal
arus
dokumen
yang berasal
dari simbol
penghubung halaman yang sama, yang bernomor seperti yang tercantum dalam simbol tersebut. Penghubung pada halaman yang bebeda (off-page connector). Jika untuk menggambarkan bagan alir suatu sistem akuntansi diperlukan lebih dari satu halaman, simbol ini harus digunakan untuk menunjukkan kemana dan bagaimana bagan alir terkait satu dengan lainnya. Nomor yang tercantum dalam simbol penghubung menunjukkan bagaimana bagan alir yang tercantum pada halaman tertentu terkait dengan bagan alir yang tercantum pada halaman yang lain. Kegiatan
manual.
Simbol
ini
digunakan
untuk
menggambarkan kegiatan manual seperti: menerima order dari
pembeli,
mengisi
formulir,
membandingkan,
48 memeriksa dan berbagai jenis kegiatan klerikal yang lain. Uraian singkat kegiatan manual dicantumkan di dalam simbol ini. Keterangan, komentar. Simbol ini memungkinkan ahli sistem menambahkan keterangan untuk memperjelas pesan yang disampaikan dalam bagan alir. Arsip
sementara.
Simbol
ini
digunakan
untuk
menunjukkan tempat penyimpanan dokumen, seperti almari arsip dan kotak arsip. Terdapat dua tipe arsip dokumen: arsip sementara dan arsip permanen. Arsip 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 menunjukkan urutan pengarsipan dokumen digunakan simbol berikut ini:
Arsip
A
=
menurut abjad
N
=
menurut nomor urut
T
=
kronologis, menurut tanggal
permanen.
Simbol
ini
digunakan
untuk
menggambarkan arsip permanen yang merupakan tempat penyimpanan dokumen yang tidak akan diproses lagi dalam sistem akuntansi yang bersangkutan.
49 Online computer process. Simbol ini menggambarkan pengolahan data dengan komputer secara online. Nama program ditulis di dalam simbol Gambar 2.12 Simbol State dalam DAD
2.1.10 State Transition Diagram ( STD ) M enurut Jeffrey A. et al (1996, p364), State Transition Diagram adalah suatu diagram yang menggambarkan bagaimana suatu proses dihubungkan satu sama lain dalam waktu yang bersamaan. State Transition Diagram digambarkan dengan sebuah state yang berupa komponen sistem yang menunjukan bagaimana kejadian-kejadian tersebut dari satu state ke state lain. Ada dua macam simbol yang menggambarkan proses dalam State Transition Diagram (STD), yaitu: 1.
Gambar persegi panjang menunjukan state dari sistem
Gambar 2.13 Simbol State dalam STD
2.
Gambar panah menunjukan transisi antar state. Tiap panah diberi label
dengan ekspresi aturan. Label yang di atas menunjukan kejadian yang menyebabkan transisi yang terjadi. Label yang dibawah menunjukan aksi yang terjadi akibat dari kejadian tadi.
Gambar 2.14 Simbol Transisi dalam STD
50 Contoh STD :
Verifikas i Data Valid
Login Username dan Password
M enu Utama Data tidak valid
Gambar 2.15 Contoh STD
2.2
Teori – teori Khusus
2.2.1
Teori Penjualan
Secara umum, pengertian penjualan dapat dikatakan sebagai ilmu mempengaruhi pribadi yang dilakukan oleh penjual untuk mengajak orang lain membeli barang atau jasa yang ditawarkan. Jadi adanya penjualan dapat tercipta suatu proses pertukaran barang atau jasa antara penjual dan pembeli. Penjualan dapat di bagi menjadi dua jenis, yaitu: 1. Penjualan Kredit Jika order pelanggan telah dipenuhi dengan dikirimnya barang atau penyerahan jasa, untuk jangka waktu tertentu perusahaan mempunyai piutang terhadap pelanggan. 2. Penjualan Tunai Kegiatan yang dilaksanakan oleh perusahaan dengan cara mewajibkan pembeli melakukan pembayaran harga barang lebih dahulu sebelum barang diserahkan oleh perusahaan kepada pembeli. Setelah uang diterima oleh perusahaan, barang kemudian diserahkan kepada pembeli dan transaksi penjualan dicatat 2.2.2
Teori Persediaan
2.2.2.1
Pengertian Persediaan
51 M enurut Render, Heizer yang diterjemahkan oleh Kresnohadi Ariyoto (2001, p.314), persediaan merupakan salah satu aset yang paling mahal di banyak perusahaan, mencerminkan 40% dari total modal yang diinvestasikan. Sedangkan menurut M ulyadi (2001, p.553), dalam perusahaan manufaktur, persediaan terdiri dari : persediaan produk jadi, persediaan produk dalam proses, persediaan bahan baku, persediaan bahan penolong, persediaan bahan habis pakai pabrik, persediaan suku cadang. Dalam perusahaan dagang, persediaan hanya terdiri dari 1 golongan, yaitu persediaan barang dagangan, yang merupakan barang yang dibeli dengan tujuan dijual kembali. Dari definisi di atas dapat disimpulkan bahwa persediaan merupakan bahanbahan yang disediakan perusahaan untuk proses produksi atau untuk dijual kembali. 2.2.2.2
Fungsi Persediaan
M enurut Render, Heizer yang diterjemahkan oleh Kresnohadi Ariyoto (2001, p.314), fungsi dari persediaan adalah sebagai berikut: 1. Untuk memberikan suatu stok barang – barang agar dapat memenuhi permintaan yang diantisipasi akan timbul dari konsumen. 2. Untuk mengambil keuntungan dari potongan jumlah. 3. Untuk melakukan hedging terhadap inflasi dan perubahan harga. 4. Untuk menghindari dari kekurangan stok yang dapat terjadi karena cuaca, kekurangan pasokan, masalah mutu, atau pengiriman yang tidak tepat. 5. Untuk menjaga agar operasi dapat berlangsung dengan baik dengan menggunakan “barang dalam proses” dalam persediaannya. 2.2.2.3
Dokumen yang Digunakan dalam Sistem Persediaan
52 M enurut M ulyadi (2001, p.576), dokumen yang digunakan untuk merekam, meringkas dan membukukan hasil perhitungan fisik persediaan adalah kartu perhitungan fisik, daftar hasil perhitungan fisik dan bukti memorial. 2.2.2.4
Informasi yang Dibutuhkan dalam Sistem Persediaan 1.
Jumlah fisik persediaan yang ada di gudang
2.
Waktu yang dibutuhkan dari pemesanan sampai barang terkirim (lead time).
2.2.2.5
3.
Jumlah minimal dari persediaan yang dibutuhkan (safety stock).
4.
Harga pokok persediaan barang yang ada di gudang.
Catatan yang dibutuhkan dalam Sistem Persediaan
M enurut M ulyadi (2001, p.560), catatan akuntansi yang dibutuhkan dalam prosedur pencatatan produk jadi adalah Kartu gudang, Kartu Persediaan dan Jurnal Umum. 2.2.2.6
Metode Pencatatan Persediaan
M enurut M ulyadi (2001,p.556) ada 2 macam metode pencatatan persediaan : 1. M etode M utasi Persediaan ( perpetual inventory method ) Dalam metode mutasi persediaan, setiap mutasi persediaan dicatat dalam kartu persediaan. 2. M etode Persediaan Fisik ( physical inventory method ) Dalam M etode Persediaan Fisik, hanya tambahan persediaan dari pembelian saja yang dicatat, sedangkan mutasi berkurangnya persediaan karena pemakaian tidak dicatat dalam kartu persediaan. 2.2.2.7
Pengendalian Persediaan
53 Pengendalian Internal atas persediaan merupakan hal yang sangat penting karena persediaan adalah bagian yang amat penting dari suatu perusahaan dagang. M enurut Render, Heizer yang diterjemahkan oleh Kresnohadi Ariyoto (2001, p.318), teknik – teknik yang dapat diterapkan dalam pengendalian persediaan adalah : 1. Pemilihan karyawan, pelatihan, dan disiplin yang baik. Hal-hal ini tidak pernah mudah dilakukan, tetapi sangat penting dalam bisnis makanan, perdagangan besar, dan operasi bisnis eceran dimana karyawannya mempunyai akses kepada barang-barang yang langsung dikonsumsi. 2. Pengendalian yang ketat atas barang yang datang. M isalnya melalui pemakaian sistem kode barang (barcode) yang membaca semua kiriman masuk dan secara otomatis memeriksa isinya dengan catatan pesanan pembelian. Serta pengendalian yang efektif atas semua barang yang keluar dari fasilitas. 2.2.2.8
Metode Penilaian Persediaan
M enurut Niswonger, et al yang diterjemahkan oleh Alfonsus Sirait, Helda Gunawan (1999, p.364), ada 3 macam metode penilaian persediaan, yaitu : 1. M etode First-In,First-Out (FIFO), jika perusahaan menggunakan metode ini, persediaan akhir terdiri dari harga pokok paling belakangan. Jadi dalam hal ini, barang-barang yang pertama kali dibeli merupakan barang yang dijual pertama kali. 2. M etode Last-In,First-Out (LIFO), jika perusahaan menggunakan metode ini, persediaan akhir terdiri dari biaya atau harga pokok paling awal. Jadi
54 dalam hal ini, barang-barang yang terakhir dibeli merupakan barang yang dijual pertama kali. 3. M etode biaya rata-rata (Average cost method), jika perusahaan menggunakan metode ini, biaya unit dalam persediaan adalah rata-rata dari biaya pembelian. Jadi dalam hal ini, harga pokok barang yang dijual merupakan perhitungan rata-rata dari harga pokok barang yang dibeli. Titik Pemesanan Ulang ( Reorder Point ) Setelah menentukan berapa produk yang akan dipesan, maka akan muncul pertanyaan kapan pemesanan persediaan yang kedua dilakukan. M odel persediaan sederhana mengasumsikan bahwa penerimaan suatu pesanan bersifat seketika. M odel – model persediaan mengasumsikan bahwa suatu perusahaan akan menunggu sampai tingkat persediaannya mencapai titik nol sebelum perusahaan memesan lagi, dan dengan seketika kiriman yang dipesan akan diterima. Akan tetapi, waktu antara dilakukannya pemesanan, disebut Lead Time atau waktu pengiriman, bisa cepat, beberapa jam atau lambat, beberapa bulan. M aka, keputusan kapan akan memesan biasanya diungkapkan dalam konteks titik pemesanan ulang, tingkat persediaan dimana harus dilakukan pemesanan. Titik pemesanan ulang ( reorder point ) dicari dengan cara : ROP
=
( permintaan per hari ) ( lead time untuk pemesanan baru dalam
beberapa hari ) = d xL Persamaan diatas mengasumsikan bahwa permintaannya sama dan bersifat konstan. Bila tidak demikian halnya, harus ditambahkan stok tambahan, sering kali disebut stok pengaman ( safety stock ).
55 Permintaan per hari, d, dicari dengan membagi permintaan tahunan, D, dengan jumlah hari kerja per tahun : d=
D Jumlah hari kerja per tahun
2.2.3
Teori Pembelian
M enurut M ulyadi (2001,p299), pembelian adalah suatu usaha pengadaan barang yang diperlukan perusahaan. Transakasi dapat digolongkan menjadi dua, yaitu pembelian lokal dan pembelian impor. Pembelian lokal adalah pembelian dari pemasok dalam negeri, sedangkan impor adalah pembelian dari pemasok luar negeri. Fungsi yang terkait dengan pembelian adalah : 1. Fungsi gudang Bertanggung jawab untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan barang yang ada di gudang dan untuk menyimpan barang yang telah diterima oleh fungsi penerimaan. 2. Fungsi Pembelian Bertanggung jawab untuk memperoleh informasi mengenai harga barang. M enentukan pemasok yang dipilih dalam pengadaan barang dan mengeluarkan order pembelian kepada pemasok yang dipilih. 3. Fungsi Akuntansi Fungsi yang terkait adalah fungsi pencatatan hutang dan persediaan barang. Fungsi pencatatan uang berfungsi untuk mencatat transakasi ke dalam register bukti kas keluar. Fungsi persediaan barang bertanggung jawab untuk mencatat harga produksi barang yang dibeli ke dalam kartu persediaan.
