8
Landasan Teori 2.1 Pendekatan BasisData
Penggunaan basisdata yang tradisioanal adalah File-Based System. Setiap program yang menggunakan File-Based System akan mendefinisikan dan mengontrol masing-masing data program itu sendiri. Tetapi aplikasi File-Based System mempunyai banyak kelemahan,contohnya :
Data terpisah-pisah
Data yang terisolasi pada file berbeda mengakibatkan semakin sulitnya pengaksesan terhadap data tersebut.
Duplikasi data
Karena setiap programmer membuat file dan aplikasi dalam jangka waktu yang lama, variasi file memiliki format yang berbeda dan kemungkinan program tersebut ditulis oleh bahasa program yang berbeda-beda. Oleh Karena itu, kemungkianan informasi yang sama dapat berbeda pada beberapa file
Ketergantungan Data
Struktur fisik dari file data dan record didefinisikan pada kode aplikasi. Hal ini mengakibatkan pengubahan dari struktur yang telah ada menjadi sulit dilakukan.
Format data yang tidak kompatibel
Karena struktur file tersimpan pada program aplikasi, struktur tersebut menjadi tergantung pada bahasa pemrograman yang digunakan.
Fixed query
File-Based System menawarkan system yang lebih baik, tetapi seiring dengan perkembangan akan muncul permintaan-permintaan query baru. Hal ini
membutuhkan pembuatan program tambahan untuk menjalankan query tersebut. Hal ini membutuhka waktu yang lama dan tamahan biaya sehingga dapat menurunkan efektifitas dari system.
Dengan adanya kekurangan dari File-Based System, maka dibuatlah sisem basisdata yang merupakan pendekatan baru yang dibutuhkan untuk mengatasi kelemahan tersebut. Salah satu dari sistem basisdata adalah Database dan Database Management System (DBMS).
2.1.1 Pengertian BasisData
Menurut Gerard V. Post (2005,p2) basisdata adalah koleksi penyimpanan data berdasarkan standar format yang dirancang agar bisa digunakan bersama-sama oleh user yang berbeda-beda.
Menurut Ramakrishman (3005, p4) basisdata adalah koleksi data, yang bertipikal penjelasan aktivitas dari satu atau lebih relasi organisasi.
Menurut Atzeni, dkk (2003, p2) basisdata adalah koleksi data, yang digunakan untk merepresentasikan informasi yang menarik ke dalam sistem informasi.
Maka dari itu, kami menyimpulkan bahwa basisdata adalah koleksi data yang bertipikal aktivitas dari satu atau lebih relasi organisasi yang dirancang agar bisa digunakan bersama-sama dan disimpan untuk kepentingan organisasi atau perusahaan.
2.1.2 Database Management System (DBMS)
DBMS (Basisdata Management System) menurut Hofer (2005, p7) adalah sistem yang digunakan untuk membuat, merawat dan menyediakan control akses untuk
pengguna basisdata. DBMS menyediakan metode sistematik untuk pembuatan, updating, penyimpanan dan penerimaan data pada basisdata. DBMS juga menyediakan fasilitas untuk mengontrol akses data, menguatkan integritas data, mengatur control konkurensi, dan menyimpan basisdata.
DBMS menurut Gererd V. Post ( 2005, p2) adalah yang menjelaskan basisdata, penyimpanan data, mendukung bahasa query, memproduksi laporan, dan membuat layer data entry.
DBMS menurut Atzeni dkk (2003, p3) adalah sistem piranti lunak yang memungkinkan untuk mengatur koleksi data yang banyak, berbagi dan persisten serta untuk memastikan reliabilitas dan privacy mereka. Seperti produk yang lainnya, DBMS harus efisien dan efektif. Basisdata adalah koleksi data yang diatur oleh DBMS.
DBMS menurut Connolly (2005, p17) adalah suatu sistem piranti lunak yang memungkinkan user untk mendefinisikan, membuat, merawat, dan mengontrol akses ke dalam basisdata.
2.1.3 Data Definition Language (DDL)
Definisi dari Data Definition Language menurut Connolly (2005, p40) adalah suatu bahasa yang memperbolehkan Database Administrator (DBA) atau user untuk mendeskripsikan nama dari suatu entity, atribut, dan relationship data yang diminta oleh aplikasi, bersamaan dengan integritas data dan batasan keamanan datanya.
2.1.4 Database Manipulation Language (DML)
DML menurut Gerard V. Post (2005, p146) adalah sebuah rangkaian dari perintah-perintah yang digunakan untuk mengakses data. Contohnya Command Insert, Delete, dan Update.
DML menurut Connolly (2005, p40) adalah suatu bahasa yang memberikan fasilitas pengoperasian data yang ada di dalam basis data. Pengoperasian data yang akan dimanipulasi biasanya meliputi:
1. Penambahan data baru ke dalam basisdata.
2. Modifikasi data yang disimpan ke dalam basisdata. 3. Pengambilan data yang terdapat di dalam basisdata.
Sedangkan definisi Procedural DML menurut Connolly (2005, p41) adalah suatu bahasa yang memperbolehkan user untuk mendeskripsikan ke sistem data apa yang dibutuhkan dan bagaimana mendapatkan data tersebut secara persis.
2.1.5 4GL
Fourth-Generalazatin Languages atau 4th GLs menurut Connolly (2005,p42)
adalah generasi bahasa tingkat empat. Tidak ada konsensus tentang apa itu 4th GLs, ditunjukkan untuk bahasa pemrograman yang sederhana suatu operasi yang membutuhkan banyak baris dalam bahasa generasi tingkat tiga (3th GLs), seperti
COBOL, biasanya membutuhkan hanya 10-20 baris 4th GLs. Dibandingkan dengan 3 th
GLs, yang membutuhkan produser,pada 4th GLs tidak diperlukan lagi dan pengguna bisa menentukan apa saja yang harus dilakukan.
4th GLs diharapkan dapat memudahkan penggunanya pada tingkat komponen yang lebih tinggi seperti tools generasi ke-4. Para pengguna tidak mengharapkan untuk
mendefinisikan langkah suatu program untuk melaksanakan suatu tugas, tetapi lebih mendefinisikan parameter untuk tools yang mana untuk menciptakan suatu program aplikasi. 4th GLs diyakini dapat mengembangkan produktivitas dalam batasan jenis masalah yang bisa diatasi oelh 4th GLs:
- Presentasi bahasa, seperti query language and report generator
- Bahasa khusus, seperti spreadsheets dan basisdata language
- Aplikasi generator yang dapat mendefinikan, menyisipkan, memperbaharui, dan membuka kembali data dari suatu basis data untuk membuat aplikasi.
2.1.6 Database Life Cycle
Sistem informasi berbasis computer terdiri dari sebuah database, piranti lunak database, piranti lunak aplikasi, perangkat keras komputer dan pemakanian perseorangan dan perkembangan sistem. Komponen terpenting dari sistem informasi adalah database. Pemakian dan perkembangan dari database harus memenuhi kebutuhan tersebar dari perusahaan.
Tingkat dari information system lifecycle atau software development lifecycle
(SDLC) terdiri dari perencanaan, analisis kebutuhan, perancangan pembuatan prototype,
implementasi, konversi dan operasi pemeliharaan. Tingkatan dari database application
lifecycle memiliki bentuk yang tidak kaku, tetapi mengikuti bentuk dari bentuk semula
yaitu feedback loops.
Untuk aplikasi database kecil, dengan jumlah pemakai yang kecil, siklus hidup yang diperlukan tidak terlalu kompleks. Meskipun begitu, ketika merancang database aplikasi menengah ke atas dengan jumlah pemakai dari 10 hingga 1000, menggunakan ratusan query dan program aplikasi, sisklus hidup dapat menjadi komplek.
Gambar 2.1
Tingkatan dari Database System Development Lifecycle
( Sumber : Connolly dan Begg , 2005 , p284 ) 2.1.6.1 Database Planning
Adalah aktifitas manajemen yang memungkinkan setiap tahapan dalam
Database System Development Lifecycle untuk direalisasikan seefisien dan
keseluruhan strategi Information System dari organisasi. Ada 3 persoalan utama dalam menyusun strategi IS, antara lain :
1. Identifikasi dari rencana dan tujuan perusahaan dengan determinasi secara
subsequent dari kebutuhan sistem informasi.
2. Mengevaluasi sistem informasi yang ada untuk mendefinisikan kekuatan dan kelemahan.
3. Penafsiran dari IT opportunity untuk mendapatkan keuntungan bersaing.
2.1.6.2 Sistem Definition
Sistem definisi mendeskripsikan cakupan dan batasan dari aplikasi basisdata dan user view utama. User view mendeskripsikan apa yang dibutuhkan dari sebuah basisdata dari sudut pandang peran pekerja (seperti manager atau
supervisor) atau area aplikasi perusahaan (seperti marketing, personel, atau
kontrol stok).
2.1.6.3 Requirements Collection and Analysis
Suatu proses yang mengumpulkan dan menganalisis informasi mengenai bagian dari organisasi yang didukung oleh aplikasi basisdata dan penggunaan informasi ini untuk mengidentifikasi kebutuhan pengguna dari sistem yang baru. Untuk mengumpulkan dan menganalisis informasi digunakan teknik yang dinamakan teknik fact-finding.
Menurut Connolly dan Begg ( 2005, p317), terdapat lima teknik fact -
• Mengevaluasi dokumentasi. • Interview. • Observasi. • Research. • Questioner. 2.1.6.4 Database Design
Menurut Connolly dan Begg ( 2005 , p291 ), Database design adalah suatu proses yang membuat suatu rancangan untuk basisdata yang akan mendukung kegiatan operasional dan tujuan dari perusahaan.
Pada bagian ini dibagi menjadi tiga tahap, yaitu conceptual, logical, dan physical
1. Conceptual database design
Pada tahap konseptual ini bertujuan untuk membuat representasi konseptual dari basis data, termasuk identifikasi entitas, relationship, dan atribut. Pada tahap ini dibagi menjadi beberapa langkah, yaitu:
Langkah 1. Membangun conceptual data model
Langkah 1.1 Identifikasikan Tipe Entitas Langkah 1.2 Identifikasikan Tipe Relationship
Langkah 1.3 Identifikasikan dan Asosiasikan Atribut dengan Tipe Entitas dan Tipe Relationship
Langkah 1.4 Menentukan Domain Atribut
Langkah 1.5 Penentuan Atribut Candidate key, Primary Key, dan
Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling
concept (optional)
Langkah 1.7 Memeriksa model dari redundancy
Langkah 1.8 Validasi Model Konseptual dengan user transaction
Langkah 1.9 Meninjau local conceptual data model dengan pengguna
2. Logical database design
Pada tahap ini memetakan model konseptual ke model logikal yang dipengaruhi oleh model data yang menjadi tujuan dari basisdata. Dalam perancangan model logikal, model data yang telah diperoleh dalam basisdata konseptual diubah dalam bentuk dimana data yang ada dipengaruhi oleh model data yang menjadi tujuan basisdata (contoh : relational model). Hal ini dilakukan untuk menerjemahkan representasi konseptual kedalam bentuk struktur logik dalam basisdata. Model data logikal merupakan sumber informasi dalam merancang basisdata fisikal. Perancangan basisdata logikal memberikan sarana yang membantu para perancang dalam merancang basisdata fisikal. Pada tahap ini dibagi menjadi beberapa langkah, yaitu :
Langkah 2. Membangun dan memvalidasi logical data model
Langkah 2.1 Menentukan Relasi – Relasi untukModel Data Logikal Langkah 2.2 Validasi Model dengan Normalisasi
Langkah 2.3 Memvalidasi Relasi dengan User Transaction
Langkah 2.4 Mendefinisikan Kendala Integrity
Langkah 2.6 Menggabungkan Logical Data Model ke dalam Global
Model (optional)
Langkah 2.7 Memeriksa untuk perkembangan lebih lanjut
3. Physical database design
Tahap physical datanbase design memungkinkan perancang basisdata untuk membuat keputusan mengenai bagaimana basisdata akan diimplementasikan. Oleh karena itu, physical databse design harus disesuaikan dengan DBMS yang spesifik. Pada tahap ini dibagi menjadi beberapa langkah, yaitu :
Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih Langkah 3.1 Merancang relasi – relasi dasar
Langkah 3.2 Merancang representasi untuk data Turunan Langkah 3.3 Merancang general constraint
Langkah 4. Merancang file organization dan indexes
Langkah 4.1 Menganalisa transaksi Langkah 4.2 Memilih organisasi file Langkah 4.3 Memillih index – index
Langkah 4.4 Memperkirakan kebutuhan disk space
Langkah 5. Merancang user view
Langkah 6. Merancang mekanisme keamanan
Langkah 7. Mempertimbangkan pengenalan redudancy control
2.1.6.5 DBMS Selection
Pemilihan DBMS dilakukan untuk memilih DBMS yang sesuai dengan aplikasi basisdata. Menurut Connolly dan Begg ( 2005, p295 ), berikut ini adalah langkah –langkah dalam memilih DBMS :
1. Menggambarkan cakupan tugas berdasarkan kebutuhan perusahaan 2. Membuat perbandingan mengenai 2 atau 3 produk DBMS
3. Mengevaluasi produk-produk DBMS tersebut
4. Merekomendasikan pemilihan DBMS dan membuat laporan hasil dari evaluasi produk DBMS tersebut.
Secara khusus DBMS menyediakan fasilitas-fasilitas sebagai berikut :
1. Mengijinkan penggunauntuk menentukan basisdata, biasanya melalui Data Definition Language (DDL). DDL mengijinkan pengguna untuk
menspesifikasikan tipe data, struktur dan batasan-batasan data yang bisa
disimpan di basisdata.
2. Mengijikan pengguna untuk insert, update, delete atau retrive data dari basisdata, biasanya melalui Data Manipulation Language(DML). 3. DBMS menyediakan akses kontrol ke basisdata. Sebagai contohnya DBMS menyediakan :
a. Security system, dimana mencegah autorisasi pengguna untuk
mengakses basisdata.
b. Integrity system, dimana menangani konsistensi penyimpanan data.
c. Concurrency control system, dimana mengijinkan basisdata untuk
d. Recovery control system, dimana basisdata bisa di-restore pada saat terjadi kesalahan pada hardware maupun software.
e. User-accesable catalog, dimana berisi deskripsi data dalam basisdata.
2.1.6.6 Application Design
Menurut Connolly dan Begg ( 2005 , p299 ), Rancangan aplikasi adalah rancangan dari user interface dan program aplikasi yang digunakan dan memproses basisdata. Dalam kebanyakan kasus tidak mungkin dapat menyelesaikan aplication design sebelum menyelesaikan database design itu sendiri. Dengan kata lain database yang ada mendukung aplikasi sehingga ada banyak aliran infomasi anatar application design dan database design.
2.1.6.7 Prototyping (Optional)
Pada kondisi tertentu kita dapat memilih apakah akan membuat prototype
atau langsung mengimplementasikan basisdata. Suatu prototype adalah suatu model aplikasi basisdata yang mempunyai semua corak yang diperlukan dan menyediakan semua kemampuan sistem. Tujuan utama prototype itu untuk menguji apakah fitur-fitur yang ada pada sistem telah bekerja sesuai dengan karakteristik pengguna. Dengan cara ini, kita dapat memperjelas kebutuhan pengguna dan pengembangan sistem dan mengevaluasi kelayakan desain sistem tersebut.
Menurut Connolly dan Begg ( 2005, p303 ), ada dua cara strategi membuat prototype yaitu requirements prototyping dan evolutionerprototyping. Untuk requirements prototyping digunakan prototype untuk menentukan
kebutuhan suatu aplikasi basisdata yang diusulkan dan ketika kebutuhan dirasakan sudah lengkap maka prototype tersebut tidak lagi digunakan. Protype
evolutioner digunakan untuk tujuan yang sama, perbedaannya adalah bahwa
prototype tidaklah dibuang tapi dikembangkan lebih lanjut sehingga menjadi
aplikasi basisdata tersebut.
2.1.6.8 Implementasi
Menurut Connolly dan Begg ( 2005, p304 ), implementasi merupakan perwujudan fisik dari basisdata dan desain aplikasi. Setelah menyelesaikan tahap desain (dengan atau tanpa prototype), selanjutnya pada tahap implementasi basisdata dan program aplikasi. Implementasi basisdata dicapai dengan menggunakan Data Definition Language (DDL) dari DBMS yang telah dipilih atau dengan menggunakan Graphical User Interface (GUI), masing - masing meyediakan fungsi ketika menyembunyikan pernyataan (statement) DDL yang
low - level. Pernyataan DDL digunakan untuk menciptakan struktur basisdata
dan mengosongkan file yang terdapat dalam basisdata tersebut. User view juga diterapkan dalam langkah implementasi.
Program aplikasi diterapkan dengan menggunakan bahasa generasi keempat atau ketiga (4GL atau 3GL). Bagian dari program aplikasi ini adalah transaksi basisdata yang diterapkan menggunakan Data Manipulation Language
(DML). Transaksi basisdata juga dapat dibuat dalam bahasa pemrograman seperti Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada, atau Pascal. Juga dapat diterapkan komponen lain dari desain aplikasi seperti layar menu, format masukan data, dan laporan.
Pengendalian keamanan dan integritas untuk aplikasi juga diimplementasikan. Sebagian dari kendali ini telah diterapkan dengan menggunakan DDL, tetapi yang lain mungkin perlu digambarkan diluar DDL. Sebagai contoh, kegunaan yang disediakan DBMS atau kendali sistem operasi.
2.1.6.9 Data Convertion dan Loading
Menurut Connolly dan Begg ( 2005, p305 ), pemindahan data yang ada ke basisdata yang baru dan mengubah aplikasi yang sedang berjalan agar dapat digunakan dalam basisdata yang baru.
2.1.6.10 Testing
Menurut Connolly dan Begg ( 2005, p305 ), Testing adalah suatu proses yang melaksanakan proses aplikasi dengan tujuan menemukan kesalahan. Dalam melakukan testing, para pengguna baru harus dilibatkan untuk menguji proses aplikasi dan basisdata tersebut. Situasi yang ideal untuk pengujian sistem adalah mempunyai suatu tes basisdata pada suatu sistem perangakat keras, tetapi ini sering tidak tersedia. Jika data real yang diharapkan untuk digunakan, maka adalah penting untuk mempunyai backup. Setelah pengujian diselesaikan, maka sistem aplikasi dan basisdata ini telah siap digunakan.
2.1.6.11 Operational Maintenance
Menurut Connolly dan Begg ( 2005, p306 ), setelah melalui tahapan-tahapan sebelumnya, maka sistem sekarang telah pada tahap pemeiharaan yang melibatkan aktivitas berikut :
1. Monitoring performance dari sistem. Jika performansi berada disuatu
tingkatan yang bisa diterima, penyetelan atau menyusun kembali basisdata
mungkin diperlukan.
2. Memelihara dan meningkatkan mutu aplikasi basisdata. Kebutuhan baru disatukan kedalam aplikasi basisdata dengan mengikuti langkah – langkah sebelumnya yang terdapat dalam database lifecycle.
Ketika aplikasi bisnis data sedang beroperasi, perlu dilakukan monitoring
secara dekat untuk memastikan bahwa performansi dalam tingkatan yang dapat diterima.
Monitoring proses akan terus berlanjut sepanjang seluruh hidup suatu
aplikasi basisdata tersebut dan pada waktu tertentu boleh melakukan menyusun kembali basisdata untuk mencukupi kebutuhan dari sistem. Perubahan ini meyediakan informasi pada evolusi sistem dan sumber daya pada masa yang akan datang mungkin diperlukan. Hal ini memungkinkan DBA untuk terlibat dalam perencanaan kapasitas dan untuk memberitahu staf senior siaga untuk melakukan penyesuaian rencana jika DBMS kekurangan kegunaan tertentu, DBA dapat mengembangkan kegunaan yang diperlukan atau memberi tools tambahan jika tersedia.
2.1.7 Tahap-Tahap Perancangan BasisData
Dalam merancang suatu basisdata melalui beberapa tahapan, sebagai berikut : • Perancanagan Basisdata Konseptual
• Perancanagan Basisdata Fisikal
2.1.7.1 Perancangan Basisdata Konseptual
Menurut Connolly dan Begg ( 2005 , p439 ), perancangan konseptual basisdata adalah proses pembangunan model data yang digunakan di perusahaan, yang tidak bergantung pada semua pertimbangan fisikal. Tujuannya untuk membangun representasi konseptual basisdata, yang meliputi identifikasi dari entitas - entitas, relationship - relationship, dan atribut - atribut yang penting. Menurut Connolly dan Begg ( 2005 , p443 ), langkah - langkah perancangan konseptual basisdata yaitu :
Langkah 1. Membangun Conceptual Data Model
Menurut Connolly dan Begg ( 2005 , p442 ), tujuannya adalah untuk membangun local conceptual data model dari perusahaan untuk tiap view yang spesifik. Tiap local conceptual data model terdiri dari entity type, relation type,
atribut - atribut, domain – domain atribut, primary key, alternate key, dan
integrity constraint. Langkah - langkah yang harus dilakukan pada langkah 1 :
Langkah 1.1 Identifikasikan Tipe Entitas
Menurut Connolly dan Begg ( 2005, p443 ), tujuannya adalah mengidentifikasikan tipe – tipe entitas utama yang dibutuhkan oleh view.
Langkah 1.2 Identifikasikan Tipe Relationship
Menurut Connolly dan Begg ( 2005 , p445 ), tujuannya adalah mengidentifikasikan relationship – relationship penting yang ada diantara tipe – tipe entitas yang telah diidentifikasi.
Langkah 1.3 Identifikasikan dan Asiosiasikan Atribut dengan Tipe Entitas dan Tipe Relationship
Menurut Connolly dan Begg ( 2005 , p447 ), tujuannya adalah untuk menghubungkan atribut – atribut dengan entitas atau relationship type yang sesuai.
Langkah 1.4 Menentukan Domain Atribut
Menurut Connolly dan Begg ( 2005 , p450 ), tujuannya adalah untuk menentukan domain – domain untuk atribut – atribut dalam local conceptual
data model. Domain atribut adalah kumpulan nilai yang diperbolehkan untuk
satu atau lebih atribut. Domain merupakan fitur yang sangat kuat dalam model relational. Setiap atribut di dalam relasi ditetapkan dalam domain. Domain mungkin berbeda untuk tiap atribut, atau dua atau lebih atribut mungkin ditetapkan dalam domain yang sama.
Langkah 1.5 Penentuan Atribut Candidate Key, Primary Key, dan Alternate
Key
Menurut Connolly dan Begg ( 2005 , p451 ), tujuannya adalah untuk mengidentifikasikan candidate – candidate key untuk tiap tipe entitas dan, jika terdapat lebih dari satu candidate key, maka pilih salah satu untuk dijadikan
primary key.
Menurut Connolly dan Begg ( 2005 , p451 ), ketika memilih primary key
diantara candidate key, kita dapat menggunakan panduan berikut untuk membantu pemilihan primary key, yaitu :
- Candidate key dengan kumpulan atribut yang minimal
- Candidate key dengan karakter – karakter yang paling sedikit (untuk yang memiliki textual attributes)
- Candidate key dengan nilai maksimum paling rendah (untuk yang memiliki
numerical attributes)
- Candidate key yang paling mudah digunakan dari sudut pandang user
Langkah 1.6 Mempertimbangkan penggunaan enhanced modeling concept (optional)
Menurut Connolly dan Begg ( 2005 , p453 ), tujuannya adalah untuk mempertimbangkan penggunaan enhanced modeling concepts, seperti
specialization / generalization, aggregation, dan composition.
Langkah 1.7 Memeriksa model dari redundancy
Menurut Connolly dan Begg ( 2005 , p453 ), tujuannya adalah untuk memeriksa apakah terdapat redundancy dalam model. Dua kegiatan dalam langkah ini adalah : memeriksa kembali one-to-one relationship dan menghilangkan redundant relationships.
Langkah 1.8 Validasi Model Konseptual dengan User Transaction
Menurut Connolly dan Begg ( 2005 , p456 ), tujuannya adalah untuk menjamin bahwa model konseptual mendukung transaksi – transaksi yang dibutuhkan oleh view.
Langkah 1.9 Meninjau local conceptual data model dengan pengguna
Menurut Connolly dan Begg ( 2005 , p458 ), tujuannya adalah untuk meninjau local conceptual data model dengan user untuk menjamin bahwa model tersebut adalah representasi yang sebenarnya dari data yang dibutuhkan oleh perusahaan.
Supervisor Staff staffNo {PK} name fName lName position sex DOB Owner ownerNo {PK} address telNo PropertyForRent propertyNo {PK} address street city postcode type rooms rent Client clientNo {PK} name fName lName telNo viewDate comment Preference prefType maxRent PrivateOwner name fName lName BusinessOwner bName bType contactName Lease leaseNo {PK} paymentMethod depositPaid rentStart rentFinish /deposit /duration {Optional} Supervises Registers 1 .. 1 0 .. 10 1 .. 1 0 .. * 0 .. 1 0 .. 100 Manages 0 .. * 0 .. * Views 1 .. * 1 .. 1 Owns AssociatedWith 1 .. 1 0 .. * 1 .. 1 0 .. * 1 .. 1 1 .. 1 Holds States {Mandatory, Or}
Gambar 2.2 ERD Conseptual
( Sumber : Connolly dan Begg , 2005 , p464 )
2.1.7.2 Perancangan Basisdata Logikal
Menurut Connolly dan Begg ( 2005 , p439 ), perancangan logikal basisdata adalah suatu proses pembangunan model data yang digunakan dalam perusahaan berdasar atas model data yang spesifik, tetapi tidak bergantung pada
particular DBMS dan pertimbangan fisikal lainnya. Tujuannya untuk menerjemahkan representasi konseptual ke struktur logikal dari basisdata yang meliputi perancangan relasi – relasi.
Menurut Connolly dan Begg ( 2005 , p462 ), langkah – langkah perancangan basisdata logikal yaitu :
Langkah 2. Membangun dan memvalidasi logical data model
Menurut Connolly dan Begg ( 2005 , p462 ), tujuannya adalah menerjemahkan logical data model dan kemudian untuk memvalidasi model tersebut untuk memeriksa model tersebut benar secara struktural dan memiliki kemampuan untuk mendukung transaksi – transaksi yang dibutuhkan. Tujuan ini akan tercapai dengan mengikuti langkah – langkah berikut :
Langkah 2.1 Menentukan Relasi – Relasi untuk Model Data Logikal
Menurut Connolly dan Begg ( 2005 , p463 ), tujuannya adalah menciptakan relasi – relasi untuk model data logikal untuk merepresentasikan entitas – entitas, relationship – relationship, dan atribut – atribut yang telah diidentifikasikan. Relationship yang dapat muncul pada model data konseptual :
● Strong Entity Type dan Weak Entity Type
Menurut Connolly dan Begg ( 2005 , p354 ), strong entity type
adalah tipe entitas yang keberadaannya tidak bergantung (independent) pada beberapa tipe entitas lainnya. Karakteristik dari strong entity type
adalah tiap entity occurrence dapat diidentifikasi secara unik menggunakan atribut primary key dari tipe entitas. Strong entity type
Menurut Connolly dan Begg ( 2005 , p355 ), weak entity type
adalah tipe entitas yang keberadaannya bergantung (dependent) pada beberapa tipe entitas lainnya. Weak entity type juga disebut child,
dependent, atau subordinate entities.
● One-to-many (1:*) binary relationship types
Menurut Connolly dan Begg ( 2005 , p465 ), untuk tiap 1:* binary
relationship, entitas pada ‘one side’ dari relationship dianggap sebagai
entitas parent dan entitas pada ‘many side’ dianggap sebagai entitas child. Untuk merepresentasikan relationship ini, pasangkan salinan primary key
dari entitas parent ke dalam relation yang merepresentasikan entitas
child, untuk berlaku sebagai foreign key.
● One-to-one (1:1) binary relationsip types
Menurut Connolly dan Begg ( 2005 , p465 ), penciptaan relasi - relasi untuk merepresentasikan 1:1 relationship sedikit lebih kompleks karena cardinality tidak dapat digunakan untuk membantu mengidentifikasikan entitas - entitas parent dan child dalam relationship. Sebagai gantinya participation constraint digunakan untuk membantu memutuskan apakah baik untuk merepresentasikan relationship dengan menggabungkan entitas - entitas yang terlibat kedalam satu relasi atau dengan menciptakan dua relasi dengan menyalin salinan dari primary key
menciptakan relasi – relasi untuk merepresentasikan participation
constraint berikut :
- Mandatory participation pada 2 sisi dari 1:1 relationship
- Mandatory participation pada 1 sisi dari 1:1 relationship
- Optional participation pada 2 sisi dari 1:1 relationship
● Mandatory participation pada 2 sisi dari 1:1 relationship
Menurut Connolly dan Begg ( 2005 , p466 ), pada kasus ini, kita harus menggabungkan entitas – entitas yang terlibat kedalam satu relasi dan memilih salah satu dari primary key dari entitas – entitas aslinya untuk menjadi primary key dari relasi yang baru, sedangkan yang lainnya dijadikan alternate key.
● Mandatory participation pada 1 sisi dari 1:1 relationship
Menurut Connolly dan Begg ( 2005 , p466 ), pada kasus ini, kita dapat mengidentifikasikan entitas - entitas parent dan child untuk 1:1
relationship menggunakan participation constraint. Entitas yang
mempunyai optional participation dalam relationship dianggap sebagai entitas parent, dan entitas yang mempunyai mandatory participation
dalam relationship dianggap sebagai entitas child. Seperti yang diuraikan diatas, salinan primary key dari entitas parent ditempatkan dalam relasi yang merepresentasikan entitas child. Jika relationship mempunyai satu atau lebih atribut, atribut ini harus menyertakan penyalinan primary key
● Optional participation pada 2 sisi dari 1:1 relationship
Menurut Connolly dan Begg ( 2005 , p467 ), kita dapat memilih
primary key mana yang dipilih tergantung dari kasus yang ada.
● One-to-one (1:1) recursive relationship
Menurut Connolly dan Begg ( 2005 , p467 ), untuk 1:1 recursive
relationship, kita mengikuti aturan untuk participation seperti yang
diuraikan untuk 1:1 relationship. Untuk 1:1 recursive relationship dengan
mandatory participation pada 2 sisi, representasikan recursive
relationship sebagai relasi tunggal dengan 2 salinan primary key.
Sedangkan salah satu salinan dari primary key merepresentasikan foreign key dan harus diubah namanya untuk menandakan relationship yang direpresentasikan.
Untuk 1:1 recursive relationship dengan mandatory participation
pada satu sisi, kita mempunyai pilihan untuk menciptakan relasi tunggal dengan 2 salinan primary key atau untuk menciptakan relasi baru untuk merepresentasikan relationship. Relasi baru hanya akan mempunyai 2 atribut, keduanya merupakan salinan primary key.
Untuk 1:1 recursive relationship dengan optional participation
pada 2 sisi, kita menciptakan relasi baru seperti yang telah diuraikan diatas.
● Superclass/subclass relationship types
Menurut Connolly dan Begg ( 2005 , p467 ),untuk tiap superclass
mengidentifikasikan entitas superclass sebagai entitas parent dan entitas
subclass sebagai entitas child. Terdapat banyak pilihan dalam
merepresentasikan relationship sebagai salah satu atau lebih relasi – relasi. Pilihan yang paling sesuai tergantung dari sejumlah faktor seperti
disjointnese dan participation constraint pada superclass / subclass
relationship apakah subclass – subclass terlibat dalam distinct
relationship dan jumlah participant – participant dalam superclass /
subclass relationship.
● Many-to-many (*:*) binary relationship types
Menurut Connolly dan Begg ( 2005 , p469 ), untuk tiap *:* binary
relationship menciptakan relasi untuk merepresentasikan relationship dan
meliputi atribut – atribut yang menjadi bagian dari relationship. Kita menyalin salinan primary key dari entitas yang berhubungan dalam
relationship kedalam relasi baru. Untuk berlaku sebagai foreign key.
● Complex relationship types
Menutur Connolly dan Begg ( 2005 , p470 ), untuk setiap complex
relationship menciptakan sebuah relasi untuk merepresentasikan
relationship dan termasuk semua atribut yang merupakan bagian dari
relationship tersebut. Kita menyalin salinan primary key dari entitas yang
berhubungan dalam complex relationship kedalam relasi baru, untuk berlaku sebagai foreign key.
● Multi-valued attributes
Menurut Connolly dan Begg ( 2005 , p471 ), menciptakan relasi yang merepresentasikan atribut – atribut multi-valued dan menyalin salinan primary key dari entitas owner kedalam relasi baru untuk menjadi
foreign key.
Langkah 2.2 Validasi Model dengan Normalisasi
Menurut Connolly dan Begg ( 2005 , p473 ), tujuannya adalah untuk memvalidasi relasi – relasi dalam model data konseptual menggunakan teknik normalisasi.
Menurut Connolly dan Begg ( 2005 , p388 ), normalisasi adalah teknik untuk menghasilkan sekumpulan relasi – relasi dengan properti – properti yang diinginkan, sesuai dengan kebutuhan data – data yang diberikan oleh perusahaan. Tujuan dari normalisasi ini adalah untuk meminimalkan redudansi data (perulangan data) dan update anomalies, menciptakan representasi data, hubungan antar data dan contraint yang akurat, serta meningkatkan stabilitas. Untuk mencapai tujuan tersebut maka harus dilakukan identifikasi dengan benar atas relasi – relasi yang ada. Pada dasarnya, proses normalisasi ini dilakukan karena terjadinya redundansi data atau kejanggalan pengubahan (update
anomaly).
Menurut Connolly dan Begg ( 2005 , p391 ), update anomaly ada tiga jenis yaitu insert anomaly, delete anomaly, dan modification/update anomaly.
Insert anomaly adalah kejanggalan yang terjadi terhadap sebuah table pada saat
constraint. Delete anomaly adalah kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan penghapusan suatu record, penghapusan bermaksud untuk menghapus suatu data tertentu tetapi menyebabkan kehilangan informasi lain dari tabel tersebut. Modification/update anomaly adalah kejanggalan yang terjadi terhadap suatu tabel pada saat dilakukan pengubahan suatu record, pengubahan terhadap suatu nilai tertentu harus dilakukan lebih dari sekali. Hal ini amat memungkinkan terjadinya inkonsistensi data.
Menurut Connolly dan Begg ( 2005 , p401 ), proses normalisasi meliputi langkah – langkah utama berikut :
- First Normal Form ( 1NF ), yang menghilangkan repeating groups
- Second Normal Form ( 2NF ), yang menghilangkan partial dependency
dalam primary key
- Third Normal Form ( 3NF ), yang menghilangkan transitive dependencies
dalam primary key
- Boyce-Codd Normal Form ( BCNF ), yang menghilangkan anomaly –
anomaly yang tersisa dari functional dependencies
Langkah 2.3 Mendefinisikan Kendala Integrity
Menurut Connolly dan Begg ( 2005 , p474 ), tujuannya adalah memeriksa
integrity constraint yang direpresentasikan dalam model data logical. Integrity
constraint terdiri dari 5 jenis, yaitu : data yang dibutuhkan, attribute domain
● Data yang dibutuhkan
Menurut Connolly dan Begg ( 2005 , p475 ), beberapa atribut harus selalu memiliki nilai yang valid. Dengan kata lain, atribut tersebut tidak boleh bernilai null.
● Attribute domain constraint
Menurut Connolly dan Begg ( 2005 , p475 ), tiap atribut mempunyai domain, yaitu kumpulan nilai – nilai yang legal. Misalnya, ada 2 jenis kelamin yaitu ‘M’ atau ‘F’, jadi domain untuk atribut jenis kelamin adalah karakter string tunggal yang terdiri dari ‘M; atau ‘F’. Batasan ini harus diidentifikasikan ketika kita memilih domain atribut untuk model data.
● Multiplicity
Menurut Connolly dan Begg ( 2005 , p475 ), multiplicity
merepresentasikan batasan yang diletakkan pada relationship antara data di dalam basisdata.
● Entity integrity
Menurut Connolly dan Begg ( 2005 , p475 ), primary key dari entitas tidak boleh bernilai null. Batasan ini harus betul – betul dipertimbangkan ketika kita mengidentifikasikan primary key untuk tiap tipe entitas.
● Referential integrity
Menurut Connolly dan Begg ( 2005 , p475 ), foreign key
menghubungkan tiap tuple dalam relasi child ke tuple dalam relasi parent
bahwa jika foreign key memiliki nilai, maka nilai tersebut harus menunjuk pada tuple yang ada pada relasi parent.
Menurut Connolly dan Begg ( 2005 , p476 ), terdapat 5 strategi untuk mempertahankan referential integrity pada saat penghapusan tuple
pada relasi parent, yaitu :
- NO ACTION
Mencegah penghapusan dari relasi parent jika terdapat tuple –
tuple child yang ditunjuk.
- CASCADE
Ketika tuple parent dihapus, secara otomatis juga dihapus tuple –
tuple child yang ditunjuk
- SET NULL
Ketika tuple parent dihapus, nilai foreign key dalam semua tuple –
tuple child yang berhubungan secara otomastis diubah menjadi
null.
- SET DEFAULT
Ketika tuple parent dihapus, nilai foreign key dalam semua tuple –
tuple child yang berhubungan secara otomatis diubah menjadi
nilai default-nya.
- NO CHECK
Ketika tuple parent dihapus, tidak melakukan apa – apa untuk menjamin referential integrity tetap terjaga.
● General constraints
Pengubahan – pengubahan pada entitas – entitas mungkin diatur oleh batasan – batasan yang memerintah transaksi ’real world’ yang direpresentasikan oleh pengubahan tersebut
Langkah 2.4 Menggabungkan Logical Data Model ke dalam Global Model (optional)
Menurut Connolly dan Begg ( 2005 , p479 ), tujuannya adalah untuk merepresentasikan semua user views dari basisdata.
Langkah 2.5 Memeriksa untuk perkembangan lebih lanjut
Menurut Connolly dan Begg ( 2005 , p490 ), tujuannya adalah menentukan apakah terdapat perubahan signifikan pada masa depan yang dapat diramalkan dan untuk menilai apakah model data logikal dapat mengakomodasi perubahan tersebut.
Gambar 2.3 ERD Logical
( Sumber : Connolly dan Begg , 2005 , p489 )
2.1.7.3 Perancangan Basisdata Fisikal
Menurut Connolly dan Begg ( 2005 , p439 ), perancangan fisik basisdata adalah proses membuat deskripsi dari implementasi basisdata pada secondary
storage, mendeskripsikan relasi dasar, file organization, dan index yang
constraint yang berhubungan dan security measures. Tujuannya adalah untuk memutuskan bagaimana struktur logikal diimplementasikan (sebagai relasi dasar) secara fisik dalam DBMS yang dipilih.
Menurut Connolly dan Begg ( 2005 , p496 ), langkah – langkah perancangan fisik basisdata meliputi :
Langkah 3. Menerjemahkan logical data model untuk DBMS yang dipilih Menurut Connolly dan Begg ( 2005 , p497 ), tujuannya adalah untuk menghasilkan relational database schema dari data model logikal yang dapat diimplementasikan dalam DBMS yang dipilih. 3 aktifitas pada Step 3 :
Langkah 3.1 Merancang relasi – relasi dasar
Menurut Connolly dan Begg ( 2005 , p498 ), tujuannya adalah untuk memutuskan bagaimana merepresentasikan relasi – relasi dasar yang diidentifikasikan dalam model data logikal dalam DBMS yang dipilih. Untuk tiap relasi yang diidentifikasi dalam model data logikal, kita mempunyai definisi yang terdiri dari :
- Nama relasi
- Daftar atribut – atribut sederhana dalam golongan – golongan
- Primary key dan alternate key dan foreign key jika ada
- Referential integrity contraints untuk semua foreign keys yang
diidentifikasikan
Menurut Connolly dan Begg ( 2005 , p498 ), sedangkan dari data dictionary, dari tiap – tiap atribut kita juga mempunyai :
- Domain-nya, yang terdiri dari tipe data, panjang, dan semua batasan dalam domain
- Nilai default optional untuk atribut
- Apakah atribut dapat mempunyai nilai nulls
- Apakah atribut tersebut derived, maka harus dikomputasi
Langkah 3.2 Merancang Representasi untuk Data Turunan
Menurut Connolly dan Begg ( 2005 , p499 ), tujuannya adalah untuk memutuskan bagaimana merepresentasikan semua data derived yang ada dalam model data logikal dalam DBMS yang dipilih. Atribut yang nilainya dapat dicari dengan memeriksa nilai – nilai dari atribut – atribut lainnya disebut derived atau
calculated attribute.
Langkah 3.3 Merancang General Constraint
Menurut Connolly dan Begg ( 2005 , p501 ), tujuannya adalah untuk merancang general constraint untuk DBMS yang dipilih.
Langkah 4. Merancang file organization dan indexes
Menurut Connolly dan Begg ( 2005 , p501 ), tujuannya adalah untuk menentukan file organisasi yang optimal untuk menyimpan relasi – relasi dasar dan indeks – indeks yang dibutuhkan untuk mencapai performansi yang dapat diterima, dengan begitu, relasi dan tuple akan disimpan pada secondary storage.
Terdapat beberapa factor yang dapat digunakan untuk mengukur efisiensi, yaitu :
- Transaction throughput adalah jumlah transaksi yang dapat diproses dalam jangka waktu tertentu. Diukur pada kondisi peak.
- Response time adalah waktu yang diperlukan untuk menyelesaikan satu
transaksi. Dari pandangan pengguna, kita sedapat mungkin ingin meminimalkan response time. Response time ini biasanya dipengaruhi waktu untuk mengakses data yang diperlukan, system load, OS scheduling,
communication delay.
- Disk storage adalah jumlah disk space yang dibutuhkan untuk menyimpan
file – file basisdata. Para perancang sistem biasanya ingin meminimalkan
disk storage yang digunakan.
Langkah 4.1 Menganalisa Transaksi
Menurut Connolly dan Begg ( 2005 , p502 ), tujuannya adalah untuk mengerti fungsi dari transaksi yang akan diterapkan pada basisdata dan untuk menganalisa transaksi – transaksi yang penting.
Langkah 5. Merancang mekanisme keamanan
Menurut Connolly dan Begg ( 2006 , p516 ), tujuannya adalah untuk merancang mekanisme keamanan untuk basisdata seperti yang ditentukan oleh
user pada waktu tahap pengumpulan kebutuhan – kebutuhan dari system
development lifecycle. Mekanisme kemanan yang dirancang dalam basisdata
Langkah 6. Mempertimbangkan pengenalan redudancy control
Menurut Connolly dan Begg ( 2006 , p519 ), tujuannya adalah untuk menentukan apakah pengenalan redundancy yang dikontrol dengan aturan – aturan normalisasi akan meningkatkan performansi sistem.
Langkah 7. Mengawasi dan mengendalikan sistem operasional
Menurut Connolly dan Begg ( 2006 , p532 ), tujuannya adalah untuk mengawasi sistem operasional dan meningkatkan performansi dari sistem untuk memperbaiki keputusan perancangan yang tidak sesuai atau merefleksikan perubahan kebutuhan.
2.1.8 ER Modeling
Terdapat beberpa konsep Model ER yang berupa : 2.1.8.1 Entity Type
Menurut Connolly dan Begg ( 2005, p343) entity type adalah kelompok objek dengan properties yang sama, yang didefinisikan unutk perusahaan selama mempunyai keadaan yang independent. Entity type memepuyai kedaan yang
independent dan dapat berupa objek dengan keberadaan fisik atau
objek-objek denga keberadaan konseptual.
2.1.8.2 Entity Occurrence
Menurut Connolly dan Begg (2005, p346) relationship occurrence adalah penyatuan yang dapat diidentifikasikan secara unik, yang terdiri dari 1 occurrance dari tiap participating entity type
2.1.8.3 Atribut
Menurut Connolly dan Begg (2005, p350) atribut adalah property dari entitas atau relationship type. Atribut domain adalah sekumpulan nilai-nilai yang diperbolehkan untuk satu atau lebih atribut. Atribut dapat diklasifikasikan menjadi
a. Simple Atribut yaitu yang terdiri dari satu komponen tunggal dengan
keberadaan yang idependen dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi
b. Composite Atibut yaitu atribut yang terdiri dari beberpa komponen,
dimana masing-masing komponen memilki keberdaan yang independen
c. Single-valued Atribut yaitu atribut yang mempuyai nilai tunggal untuk
setiap kejadian
d. Multi-valued Atribut yaitu atribut yang mempuyai beberpa nilai untuk
setiap kejadian
e. Derived Atribut yaitu atribut yang memilki nilai yang dihasilakan dari
satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entitas.
2.1.8.4 Key
Menurut Connolly dan Begg ( 2005 , p352 ), candidate key adalah sekelompok atribut yang minimal dan secara unik mengidentifikasikan tiap
occurrence dari entity type.
Menurut Connolly dan Begg ( 2005 , p353 ), primary key adalah key yang dipilih untuk mengidentifikasikan secara unik tiap occurrence dari entity type.
Menurut Connolly dan Begg ( 2005 , p353 ), composite key adalah candidate key
yang terdiri dari dua atau lebih atribut.
Gambar 2.4 ER Diagram
2.1.8.5 Structural constraint
Tipe utama dari constraint dari relationship disebut multiplicity.
Multiplicity adalah jumlah dari kejadian – kejadian yang mungkin dari sebuah
tipe entitas yang terhubung pada kejadian tunggal dari tipe entitas yang berhubungan melalui relationship khusus.
Tiga jenis relationship yang digunakan mengikuti enterprise constraint : • Hubungan one-to-one (1:1)
Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-satu dan dapat pula member entitas yang satu ada yang tidak berhubungan dengan
member dari entitas yang berelasi dengannya dan entitas tersebut juga berelasi maksimal 1.
Contoh : satu produk hanya memiliki satu bonus dan bonus hanya dimiliki oleh satu produk. Diasumsikan hanya produk tertentu saja yang mempunyai bonus dan bonusnya hanya satu.
Gambar 2.5 Hubungan one-to-one (1:1)
• Hubungan one-to-many (1:*)
Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah satu-banyak. Dimana sebuah member dari entitas dapat berhubungan dengan satu atau banyak member dari entitas yang lain dan member dari entitas yang lainnya berhubungan (bisa dari 0) sampai maksimal 1.
Contoh : seorang kepala sekolah dapat memiliki 1 hingga banyak guru, tetapi seorang guru hanya memiliki satu dan hanya satu kepala sekolah.
Gambar 2.6 Hubungan one-to-many (1:*)
KepalaSekolah Guru
1..1 has ► 1..*
• Hubungan many-to-many (*:*)
Hubungan yang terjadi diantara dua entitas yang saling terlibat adalah banyak-banyak. Member dari sebuah entitas dapat berelasi dengan entitas yang lain dengan maksimal multiplicity banyak (*) dan sebaliknya dengan relasi entitas yang berhubungan tersebut.
Contoh : Pembeli dapat memilih 0 hingga banyak produk yang ingin dibeli, tetapi produk dapat dipilih untuk dibeli oleh 0 hingga banyak pembeli pada satu jenis produk.
Gambar 2.7 Hubungan many-to-many (*:*)
2.1.9 Normalisasi
Tujuan uatama dalam pengembangan model data logical pada sistem database relational adlah menciptakan representasi akurat suatu data, relationship anatar data dan batasan-batasannya. Untuk mencapai tujuan ini, maka harus ditetapkan sekumpulan relasi.
2.1.9.1 Pengetian Normalisasi
Menurut Connolly dan Begg ( 2005 , p401 ), normalisasi adalah teknik formal untuk menganalisa relasi berdasarkan pada primary key (atau candidate key) dan functional dependencies.
Pembeli Produk
0..* Order► 0..* ◄ OrderedBy
2.1.9.2 Tahapan- tahapan Normalisasi
Normalisasi memiliki Empat bentuk normal yang biasa digunakan yaitu :
first normal form, second normal form dan third normal form dan beyce-codd normal form
2.1.9.2.1 UNF (Un-Normal Form)
Menurut Connolly dan Begg ( 2005 , p402 ), proses normalisasi dimulai dari bentuk UNF (Un-Normal Form), yaitu tabel yang masih mengandung
repeating group. Tabel UNF ini dibuat dengan mentransformasi data dari sumber
informasi ( seperti formulir ) ke dalam tabel berbentuk baris dan kolom. 2.1.9.2.2 1NF (First Normal Form)
Menurut Connolly dan Begg ( 2005 , p403 ), pada bentuk normal pertama
( First Normal Form – 1NF ), sebuah relasi dimana pada setiap sel ( perpotongan
baris dan kolom ) jika dan hanya jika mengandung satu nilai, setiap sel mengandung nilai atomik ( single value ). Untuk menjadikan bentuk tidak normal menjadi normal pertama dengan mengidentifikasikan dan menghilangkan
repeating groups yang ada di dalam tabel. Repeating group adalah sebuah atau
sekumpulan atribut dalam tabel yang memiliki multiple values untuk single
occurrence dari atribut key yang terpilih untuk tabel tersebut.
2.1.9.2.3 2NF (second Normal Form)
Menurut Connolly dan Begg ( 2005 , p407 ), sebuah tabel disebut berada pada bentuk normal kedua ( 2NF ) jika dan hanya jika setiap atribut bukan
primary key ( PK ) tergantung sepenuhnya pada PK. Untuk mengetahui apakah
2.1.9.2.4 3NF (Third Normal Form)
Menurut Connolly dan Begg ( 2005 , p408 ), sebuah tabel disebut berada pada bentuk normal ketiga jika dan hanya jika tidak ada atribut bukan primary key yang bergantung kepada atribut bukan primary key lainnya. Sebuah tabel yang mengandung atribut bukan PK yang tergantung pada atribut PK lainnya disebut transitive dependency. Dengan kata lain sebuah tabel disebut berada pada 3NF jika dan hanya jika tidak mengandung transitive dependency.
2.1.9.2.5 BCNF(Boyce-Codd Normal Form)
Menurut Connolly dan Begg ( 2005 , p419 ), suatu relasi dianggap sebagai bentuk normal BCNF jika dan hanya jika setiap determinant adalah
candidate key. Untuk mengetahui apakah suatu tabel sudah berada pada bentuk
normal BCNF maka harus dilakukan analisa atas functional dependency dari sebuah tabel.
2.1.10 Tools Yang Digunakan
Untuk menyelesaikan suatu masalah dengan cara mendekomposisi system ke dalam komponen yang lebih kecil dengan tujuan untuk mempelajari bagaimana komponen-komponen tersebut bekerja dan saling berinteraksi maka kita memerlukan tool-tool yang dapat mencerminkan proses. Adapun beberapa tool yaitu :
2.1.10.1 Data Flow Diagram
Menurut Hall ( 2001 , p69 ), DFD yang juga disebut dengan Diagram Arus Data, adalah diagram yang menyajikan rangkaian simbol - simbol untuk mencerminkan proses, sumber-sumber data, arus data, dan entitas dalam sebuah sistem pada tingkatan rinci yang berbeda.
DFD pertama kali diperkenalkan sebagai modeling tools Tom Demarco ( 1978 ), Gane dan Sarson ( 1979 ) dengan menggunakan pendekatan metode analisis sistem terstrukstur (structured system analysis method). DFD juga dapat digunakan untuk merepresentasikan suatu sistem yang otomatis maupun manual dengan menggunakan gambar yang berbentuk jaringan grafik.
Tingkatan Diagram Pada DFD : 1 Diagram Konteks
• Merupakan level tertinggi pada DFD yang menggambarkan seluruh output atau input ke sistem
• Memberikan gambaran tentang keseluruhan sistem
• Terminal yang memberikan masukan kepada sistem disebut source, sedangkan yang menerima keluaran dari sistem disebut sink
• Hanya ada satu proses didalam diagram konteks • Tidak boleh ada proses penyimpanan data (data store)
2. Diagram Nol
• Memperlihatkan proses penyimpanan data (data store) yang digunakan • Untuk proses yang tidak rinci lagi pada level selanjutnya, tambahkan tanda *
pada akhir nomor proses
• Keseimbangan antara input dan output pada diagram nol dan diagram konteks harus terpelihara
Simbol-simbol dalam DFD adalah :
Tabel 2.1 Tabel Simbol DFD
External entity atau terminal
Proses
Penyimpanan data atau data storage
Aliran data atau Data Flow
2.1.10.2 State Transition Diagram (STD)
Menurut Pressman ( 2001 , p302 ), State Transition Diagram merupakan suatu diagram yang menggambarkan bagaimana state dihubungkan dengan state
yang lain pada satu waktu. State Transition Diagram menunjukkan bagaimana sistem bekerja sebagai akibat dari kejadian eksternal. Untuk melakukan hal itu,
State Transition Diagram menampilkan model yang bermacam-macam dari
tindakan sebuah sistem dan dibuat dari state ke state. Komponen dasar dari State Transition Diagram adalah :
1. : menyatakan state atau kondisi dari suatu sistem. State
terdiri dari dua macam, yaitu initial state / state awal dan
final state / state akhir. Final state dapat terdiri atas
beberapa state, tetapi initial state tidak boleh lebih dari satu.
2. : menyatakan perubahan kondisi dari suatu sistem. Digambarkan untuk menghubungkan keadaan sistem yang berkaitan.
3. Kondisi dan Aksi
Kondisi : menyatakan suatu kejadian pada lingkungan eksternal yang dapat dideteksi oleh suatu sistem. Misalnya : suatu sinyal / data.
Aksi : menyatakan sesuatu yang dilakukan oleh sistem apabila terjadi perubahan state / merupakan suatu reaksi terhadap kondisi. Aksi akan menghasilkan output, message display pada monitor dan menghasilkan kalkulasi.
2.1.10.3 Bagan Alir Dokumen (Document FlowChart)
Document FlowChart digunakan untuk menggambarkan bagan alir
dokumen suatu sistem. Berikut adalah simbol – simbol standar beserta keterangannya untuk mengambarkan bagan alir dokumen :
Tabel 2.2 Tabel Simbol Document FlowChart Lambang Keterangan
Dokumen. Simbol ini digunakan untuk menggambarkan semua jenis dokumen, yang merupakan formulir yang diunakan untuk merekam data terjadinya suatu transaksi
Dokumen dan tembusannya. Simbol ini digunakan untuk menggambarkan dokumen asli dan tembusannya. Nomor lembar dokumen dicantumkan di sudut kanan atas
Catatan. Simbol ini digunakan untuk menggambarkan catatan akuntansi yang digunakan untuk mencatat data yang direkam sebelumnya di dalam dokumen atau formulir
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 ini. Penghubung pada halaman yang berbeda (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.
Kegiatan manual. Simbol ini digunakan untuk menggambarkan kegiatan manual seperti : menerima order dari pembeli, mengisi formulir dan kegiatan lainnya
Keterangan, komentar. Simbol ini memungkinkan ahli sistem menambahkan keterangan untuk memperjelas pesan yang disampaikan dalam bagan alir
Arsip permanen. Simbol ini digunakan untuk menggambarkan arsip permanen yang merupakan tempat penyimpanan dokumen yang tidak akan diproses lagi dalam sistem akuntansi yang bersangkutan
Keputusan. Simbol ini menggambarkan keputusan yang harus dibuat dalam proses pengolahan data. Keputusan yang dibuat ditulis di dalam simbol
Garis alir (flowline). Simbol ini menggambarkan arah proses pengolahan data. Anak panah tidak digambarkan jika arus dokumen mengarah ke bawah dan ke kanan. Jika arus dokumen mengalir ke atas atau ke kiri, anak panah perlu dicantumkan
Persimpangan garis alir. Jika dua garis alir bersimpangan, untuk menunjukkan arah masing – masing garis, salah satu garis dibuat sedikit melengkung tepat pada persimpangan ke dua garis tersebut
Pertemuan garis alir. Simbol ini digunakan jika dua garis alir bertemu dan salah satu garis mengikuti arus garis lainnya
Mulai/berakhir (terminal). Simbol ini untuk menggambarkan awal dan akhir suatu sistem akuntansi
Masuk ke sistem. Karena kegiatan di luar sistem tidak perlu digambarkan dalam bagan alir, maka diperlukan simbol untuk menggambarkan masuk ke sistem yang digambarkan dalam bagan alir
Keluar ke sistem lain. Karena kegiatan di luar sistem tidak perlu digambarkan dalam bagan alir, maka diperlukan simbol untuk menggambarkan keluar ke sistem lain
Perbedaan data flow dengan flowchart :
1. Proses dalam data flow dapat dioperasikan secra parallel,sehingga dapat dieksekusi secara terus menerus, sedangkan proses pada data flow dapat dieksekusi sekali
2. Diagram data flow menunjukan aliran data melalui system
3. data flow diagram dapat menunjukan proses yang memiliki perbedaan waktu.
2.2 Teori-Teori Khusus 2.2.1 Persediaan
Menurut Mulyadi ( 2001 , p553 ), sistem persediaan bertujuan untuk mencatat mutasi tiap jenis persediaan yang disimpan di gudang. Sistem ini berkaitan erat dengan sistem penjualan, sistem retur penjualan, sistem pembelian, sistem retur pembelian, dan sistem akuntansi biaya produksi.
2.2.1.1 Jenis-jenis persediaan
Menurut Sofjan Assauri (1999, 221), persediaan yang terdapat di dalam perusahaan dapat di bedakan menurut berbagai cara antara lain sebagai berikut: 1) Menurut fungsinya, persediaan dapat dibedakan atas :
a) Batch Stock atau Lot Size Inventory
Adalah persediaan yang diadakan karena kita membeli atau membuat bahan-bahan atau barang-barang dalam jumlah yang lebih besar daripada jumlah yang dibutuhkan pada saat itu. Jadi dalam hal ini pembelian atau pembuatan yang dilakukan untuk jumlah yang besar, sedangkan penggunaan atau pengeluaran dalam jumlah kecil. Terjadinya persediaan karena pengadaan bahan atau barang yang dilakukan lebih banyak daripada yang dibutuhkan.
b) Fluctuation Stock
Adalah persediaan yang diadakan untuk menghadapi fluktuasi permintaan konsumen yang tidak dapat diramalkan.
c) Anticipation Stock
Adalah persediaan yang diadakan untuk menghadapi fluktuasi permintaan yang dapat diramalkan berdasarkan pola musiman yang
terdapat dalam satu tahun dan untuk menghadapi penggunaan atau penjualan yang meningkat.
2) Menurut jenis dan posisi barang tersebut didalam urutan pengerjaan produk, persediaan dapat dibagi atas :
a) Persediaan bahan baku (Raw Materials)
Yaitu persediaan dari barang-barang berwujud yang digunakan dalam proses produksi. Contoh : kapas dipintal menjadi benang, benang diolah menjadi kain atau kaos.
b) Persediaan bagian produk atau parts yang dibeli (purchased parts /
komponen stock)
Yaitu persediaan barang-barang yang terdiri dari parts yang diterima dari perusahaan lain, yang dapat secara langsung di assembling
dengan parts lain, tanpa melalui proses produksi sebelumnya. Jadi bentuk barang yang merupakan parts tidak mengalami perubahan dalam operasi. Misalnya pabrik mobil, dimana dalam hal ini bagian-bagian (parts) dari mobil tersebut tidak diprodusir dalam pabrik mobil, tetapi
diprodusir oleh perusahaan lain, dan kemudian di assembling menjadi barang yakni mobil.
c) Persediaan barang-barang pembantu atau barang-barang pelengkap
(supplies stock)
Yaitu persediaan barang-barang atau bahan-bahan yang diperlukan dalam proses produksi untuk membantu berhasilnya produksi atau yang dipergunakan dalam bekerjanya suatu perusahaan, tetapi tidak
merupakan bagian atau komponen dari barang jadi. Misalnya minyak solar dan minyak pelumas adalah hanya merupakan bahan pembantu. d) Persediaan barang setengah jadi atau barang dalam proses (work in
process / progress)
Yaitu persediaan barang-barang yang keluar dari tiap-tiap bagian dalam satu pabrik atau bahan-bahan yang telah diolah menjadi suatu bentuk, tetapi lebih perlu diproses kembali untuk kemudian menjadi barang jadi.
e) Persediaan barang jadi (finished goods stock)
Yaitu persediaan barang-barang yang telah selesai diproses atau diolah dalam pabrik dan siap untuk dijual kepada pelanggan atau perusahaan lain.
2.2.1.2 Biaya-biaya yang timbul akibat adanya persediaan
Menurut Hani Handoko (2000:336), ada beberapa biaya-biaya yang timbul dari adanya persediaan antara lain :
1. Biaya penyimpanan
Biaya penyimpanan (holding costs / carrying cost) terdiri atas biaya-biaya yang bervariasi secara langsung dengan kuantitas persediaan biaya-biaya penyimpanan per periode akan semakin banyak apabila kuantitas bahan baku yang di pesan semakin banyak, atau rata-rata persediaan semakin tinggi.
1. Biaya fasilitas-fasilitas penyimpanan (termasuk penerangan, pemanas, atau pendingin).
2. Biaya modal. 3. Biaya keusangan
4. Biaya perhitungan fisik dan konsiliasi laporan 5. Biaya asuransi
6. Biaya pajak persediaan
7. Biaya pencurian, pengrusakan, dan perampokan 8. Biaya penanganan persediaan
2. Biaya pemesanan
Setiap kali suatu bahan dipesan, perusahaan menanggung biaya pemesanan.
Biaya pemesanan secara terperinci meliputi : 1. Pemrosesan pesanan dan biaya ekspedisi 2. Upah
3. Biaya telepon
4. Pengeluaran surat menyurat 5. Biaya pengepakan
6. Biaya pemeriksaan
3. Biaya penyiapan
Bila bahan-bahan tidak dibeli, tetapi diproduksi sendiri”dalam pabrik” perusahaan. Perusahaan menghadapi biaya penyiapan (setup costs) untuk memproduksi komponen tertentu.
Biaya-biaya ini terdiri dari : 1. Biaya mesin menganggur
2. Biaya persiapan tenaga kerja langsung 3. Biaya scheduling
4. Biaya ekspedisi
4. Biaya kehabisan atau kekurangan bahan
Dari semua biaya-biaya yang berhubungan dengan tingkat persediaan, biaya kekurangan (shortage costs) adalah yang paling sulit diperkirakan. Biaya ini timbul bilamana persediaan tidak mencukupi adanya permintaan bahan.
Biaya-biaya yang termasuk biaya kekurangan adalah sebagai berikut : 1. Kehilangan penjualan
2. Kehilangan pelanggan 3. Biaya pemesanan khusus 4. Biaya ekspedisi
5. Selisih harga
6. Terganggunya operasi
2.2.1.3 Fungsi Persediaan
Menurut Sofjan Assauri (1999:230), fungsi persediaan yang efektif adalah:
1. Memperoleh bahan-bahan
Yaitu menetapkan prosedur untuk memperoleh suplai yang cukup dari bahan-bahan yang dibutuhkan baik kuantitas maupun kualitas.
2. Menyimpan dan memelihara bahan-bahan dalam persediaan Yaitu mengadakan suatu system penyimpanan untuk memelihara dan melindungi bahan-bahan yang telah dimasukkan ke dalam persediaan.
3. Pengeluaran bahan-bahan
Yaitu menetapkan suatu pengaturan atas pengeluaran dan penyampaian bahan-bahan dengan tepat pada saat serta tempat dimana dibutuhkan.
4. Meminimalisasi investasi dalam bentuk bahan atau barang (mempertahankan persediaan dalam jumlah yang optimum setiap waktu). 2.2.2 Penjualan
Menurut Mulyadi ( 2001 , p202 ), kegiatan penjualan terdiri dari penjualan barang dan 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. Dalam sistem penjulan secara tunai, barang atau jasa baru diserahkan oleh perusahaan kepada pembeli jika perusahaan telah menerima kas dari pembeli.
Menurut Mulyadi(2001,p226), Transaksi retur penjualan terjadi jika perusahaan menerima pengembalian barang dari pelanggan. Pengembalian barang oleh pelanggan harus diotorisasi oleh fungsi penjualan dan diterima oleh fungsi penerimaan. Fungsi yang terkait dalam melaksanakan transaksi retur penjualan adalah :
1. Fungsi penjualan
Fungsi ini bertanggung jawab atas penerimaan pemberitahuan mengenai pengembalian barang yang telah dibeli oleh pembeli. Otorisasi penerimaan kembali barang yang telah dijual tersebut dilakukan dengan cara membuat memo kredit yang dikirimkan kepada fungsi penerimaan.
2. Fungsi penerimaan
Fungsi ini bertanggung jawab atas penerimaan barang berdasarkan otorisasi yang terdapat dalam memo kredit yang diterima dari fungsi penjualan.
3. Fungsi gudang
Fungsi ini bertanggung jawab atas penyimpanan kembali barang yang diterima dari retur penjualan setelah barang tersebut diperiksa oleh fungsi penerimaan. Barang yang diterima dari transaksi retur penjualan ini dicatat oleh fungsi gudang dalam kartu gudang.
4. Fungsi akuntansi
Fungsi ini bertanggung jawab atas pencatatan transaksi retur penjualan ke dalam jurnal umum dan pencatatan berkurangnya piutang dan bertambahnya persediaan akibat retur penjualan dalam kartu piutang dan kartu persediaan. Disamping itu, fungsi ini juga bertanggung jawab untuk mengirimkan memo kredit kepada pembeli yang bersangkutan.
Menurut Mulyadi(2001,p234), jaringan prosedur dalam sistem retur penjualan adalah sebagai berikut :
1. Prosedur pembuatan memo kredit
Fungsi penjualan membuat memo kredit yang memberikan perintah kepada fungsi penerimaan untuk menerima barang dari pembeli tersebut dan kepada fungsi akuntansi untuk pencatatan pengurangan piutang kepada pembeli yang bersangkutan.
2. Prosedur penerimaan barang
Fungsi penerimaan menerima dari pembeli berdasarkan perintah dari memo kredit yang diterima dari fungsi penjualan. Atas penerimaan barang tersebut fungsi penerimaan membuat laporan penerimaan barang untuk melampiri memo kredit yang dikirim ke fungsi akuntansi.
3. Prosedur pencatatan retur penjualan
Dalam prosedur ini transaksi berkurangnya piutang dagang dan pendapatan penjualan akibat dari transaksi retur penjualan dicatat oleh fungsi akuntansi ke dalam jurnal umum atau jurnal retur penjualan dan ke dalam buku pembantu piutang. Dalam prosedur ini pula berkurangnya harga pokok penjualan dan bertambahnya harga pokok persediaan dicatat oleh fungsi akuntansi ke dalam jurnal umum dan dalam buku pembantu persediaan.
Menurut Mulyadi ( 2001 , p204 ), fungsi yang terkait pada penjualan secara kredit adalah :
Dalam transaksi penjualan kredit, fungsi ini bertanggung jawab untuk menerima surat order dari pembeli, mengedit order dari pelanggan untuk menambahkan informasi yang belum ada pada surat order tersebut (seperti spesifikasi barang dan rute pengiriman), meminta otorisasi kredit, menentukan tanggal pengiriman dan dari gudang nama barang akan dikirim, dan 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 kredit
Fungsi ini berada di bawah fungsi keuangan yang dalam transaksi penjualan kredit, bertanggung jawab untuk meneliti status kredit pelanggan dan memberikan otorisasi pemberian kredit kepada pelanggan. Karena hampir semua penjualan dalam perusahaan manufaktur merupakan penjualan kredit, maka sebelum order dari pelanggan dipenuhi, harus lebih dahulu diperoleh otorisasi penjualan kredit dari fungsi kredit. Jika penolakan pemberian kredit seringkali terjadi, pengecekan status kredit perlu dilakukan sebelum fungsi penjualan mengisi surat order penjualan. Untuk mempercepat pelayanan kepada pelanggan, surat order pengiriman dikirim langsung ke fungsi pengiriman sebelum fungsi penjualan memperoleh otorisasi kredit dari fungsi kredit. Namun, tembusan kredit harus dikirimkan ke fungsi kredit untuk mendapatkan persetujuan kredit dari fungsi tersebut. Dalam hal otorisasi kredit tidak dapat diberikan, fungsi penjualan memberitahu fungsi pengiriman untuk membatalkan pengiriman barang kepada pelanggan.
