6
LANDASAN TEORI
2.1 Pendekatan Basisdata 2.1.1 Pengertian data
Definisi data menurut (Jeffrey, 2005, p5) adalah penyimpanan representasi objek dan kejadian yang mempunyai arti dan penting di lingkungan pengguna. Definisi ini termasuk kedalam tipe data yang terstruktur maupun tidak terstruktur. Tipe data struktur dan yang tidak terstruktur sering dikombinasikan bersama didalam database yang sama untuk menciptakan lingkungan multimedia yang baik.
Data adalah fakta atau observasi tentang transaksi suatu bisnis. Selain itu, data juga merupakan pengukuran objektif terhadap atribut pada suatu entitas seperti orang, tempat, benda, dan kejadian (O’Brien,2003,p4).
Dengan demikian dapat disimpulkan bahwa data adalah
penyimpanan representasi objek serta fakta atau observasi tentang transaksi suatu bisnis selain itu data juga dapat disimpulkan bahwa data adalah adalah fakta mengenai transaksi bisnis yang dapat disimpan dan digunakan kapan saja untuk berbagai kepentingan yang akan datang.
2.1.2 Pengertian Basis Data
Sistem basis data juga dapat kita simpulkan sebagai serangkaian program komputer yang mengendalikan pembuatan, pemeliharaan, dan pemanfaatan basis data sebagai sebuah organisasi (O’Brien, 2003,p5). Basis data adalah kumpulan data yang terhubung secara logikal dan juga deskripsi tentang data ini yang dirancang untuk mendapatkan informasi yang dibutuhkan suatu organisasi(Connoly, 2005, p15).
Dengan demikian dapat disimpulkan bahwa basis data adalah sekumpulan data teratur yang saling terhubung secara logis, disimpan dalam bentuk yang terstandarisasi, dan dirancang untuk dapat digunakan oleh banyak pengguna untuk memenuhi kebutuhan informasi.
2.1.3 Database Management System(DBMS)
Database Management System (DBMS) adalah sebuah sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, memelihara, dan juga kontrol akses ke dalam database (Connoly, 2005, p16).
DBMS menyediakan fasilitas sebagai berikut:
a. Data Definition Language (DDL), memungkinkan pengguna untuk mendefinisikan basis data, tipe dan strukturnya serta memberikan batasan pada data untuk disimpan dalam basis data.
b. Data Manipulation Language (DML), memungkinkan pengguna untuk menyisipkan data, meng-update data, menghapus data dan menerima data dari basis data dengan menciptakan fasilitas permintaan data umum yang disebut query language.
c. DBMS juga menyediakan kontrol akses ke basis data sebagai berikut: 1. Security system, dimana mencegah user yang tidak mempunyai
hak akses untuk mengakses basis data.
2. Integrity system, dimana memelihara konsistensi dari data yang disimpan.
3. Concurrency control system, dimana memungkinkan untuk berbagi akses ke basis data.
4. Recovery control system, dimana dapat mengembalikan database ke kondisi semula ketika terjadi kegagalan pada perangkat lunak maupun perangkat keras.
5. User-Accessible catalog, dimana mengandung deskripsi data pada basis data.
2.1.4 Keuntungan DBMS
Menurut Connoly dan Begg (2005,p26)Ada beberapa keuntungan dalam menggunakan DBMS diantara lain:
1. Mengontrol Duplikasi Data
DBMS dapat mengurangi duplikasi basis data yang terjadi tetapi tidak semua duplikasi data dapat dihilangkan, melainkan hanya dapat dikontrol.
2. Konsistensi Data
DBMS menjaga agar data didalamnya tetap konsisten dengan cara menghilangkan atau mengontrol duplikasi data.
3. Pengunaan data secara bersama
DBMS memungkinkan basis data yang dimiliki oleh organisasi bisa digunakan secara bersama oleh user yang memiliki hak akses.
4. Meningkatkan integritas data
Integritas basis data mengacu kepada validitas dan konsistensi dari data yang disimpan. Integritas sendiri biasanya memperdalam arti kata constraintyang berarti basis data tidak diperbolehkan untuk dilanggar oleh pemakai basis data itu sendiri.
5. Meningkatkan keamanan
Keamanan basis data adalah perlindungan basis data dari pengguna yang tidak memiliki akses.
2.1.5 Kerugian DBMS
Menurut Connoly dan Begg(2005,p29)Kerugian dalam menggunakan DBMSdiantara lain:
1. Kompleksitas
Penyediaan fungsi yang kita harapkan dari DBMS membuat DBMS menjadi sebuah perangkat lunak yang sangat kompleks. Desainer basis data, pengembang, admin data dan basis data serta pengguna harus bisa memahami penuh fungsionalitas DBMS untuk bisa mendapatkan
keuntungan dari DBMS ini jika tidak dipahami dengan baik maka kompleksitas DBMS bisa menjadi kesulitan tersendiri.
2. Ukuran
Kompleksitas dan juga fungsionalitas membuat DBMS menjadi sebuah perangkat lunak yang sangat besar ukurannya, sehingga kita harus memperhitungkan jumlah disk spaceyang besar serta jumlah memory yang besar pula agar DBMS ini bisa berjalan dengan efisien.
3. Harga
Harga DBMS sendiri tidaklah murah tergantung dari lingkungan dan juga fungsionalitas yang disediakan oleh DBMS tersebut.
4. Biaya tambahan perangkat keras
Disk storageyang diperlukan untuk DBMS dan juga basis data memungkinkan untuk membeli storage tambahan sehingga perlu disediakan perangkat keras tambahan .
5. Biaya konversi
Di beberapa keadaan, biaya DBMS serta perangkat keras tambahan tidak dapat dibandingkan dengan biaya mengkonversi aplikasi agar dapat berjalan di DBMS baru dan perangkat keras. Biaya ini juga termasuk biaya untuk melatih pengawai agar dapat mengkonversi dan menggunakan sistem baru ini.
2.1.6 Database Lifecycle
Menurut Connoly dan Begg (2005, p284), siklus hidup aplikasi basis data adalah seperti yang ada pada gambar 2.1 di bawah ini:
2.1.6.1 Database planning
Menurut Connolly dan Begg (2005, p285), database planning adalah merupakan aktifitas manajemen yang memungkinkan tahapan-tahapan dari database system development lifecycle direalisasikan seefisien dan seefektif mungkin. Database planning harus berintegrasi dengan strategi sistem informasi dalam organisasi. Terdapat tiga hal pokok yang penting berkaitan dengan strategi sistem informasi, yaitu : a. Identifikasi rencana dan sasaran dari enterprise termasuk mengenai
sistem informasi yang dibutuhkan.
b. Evaluasi sistem yang ada untuk menetapkan kelebihan dan kekurangan yang dimiliki
c. Penilaian kesempatan IT yang mungkin memberikan keuntungan kompetitif.
Tahapan utama yang paling penting dalam database planning adalah menentukan mission statementdan mengidentifikasikan mission objectives. Mission statement untuk mendefinisikan tujuan utama untuk database project dari aplikasi basis data. Mission statement membantu menjelaskan kegunaan dari database project dan menyediakan alur yang lebih jelas untuk mencapai efektifitas dan efisiensi penciptaan dari suatu aplikasis basis data yang diinginkan. Kegiatan selanjutnya adalah mengidentifikasikan mission objectives. Setiap objectives harus mengidentifikasikan tugas khusus yang harus didukung oleh basis data. Mission objectives dapat juga disertai dengan beberapa informasi
tambahan yang menspesifikasikan pekerjaan yang harus diselesaikan, sumber daya yang digunakan dan biaya untuk membayar kesemuanya itu. Database planning harus menyertakan pengembangan standar-standar
yang menentukan bagaimana data dikumpulkan, bagaimana
menspesifikasikan bentuk data, dokumentasi penting apakah yang akan dibutuhkan dan bagaimana desain dan implementasi harus dilakukan.
2.1.6.2 System Definition
Menurut Connoly dan Begg (2005, p286), system definition adalah penjelasan mengenai batasan – batasan dan cakupan dari aplikasi basis data dan sudut pandang user (user view) yang utama. Maksudnya sebelum memulai untuk merancang aplikasi basis data, hal yang paling utama untuk dilakukan adalah mengidentifikasikan batasan sistem yang akan dibangun dan bagaimana sistem tersebut dapat berinteraksi dengan yang lain dari sistem informasi sebuah organisasi.
User view mendefinisikan apa yang dibutuhkan dari suatu basis data yang perspektif, diantaranya aturan kerja khusus dan area aplikasi enterprise. Mengidentifikasikan user view sangat penting karena dapat membantu memastikan bahwa tidak ada user utama didalam suatu basis data yang terlupakan ketika pembuatan aplikasi baru yang dibutuhkan.
2.1.6.3 Requirement Collection and Analysis
Menurut Connolly dan Begg (2005, p288), requirement collection and analysisadalah suatu proses pengumpulan dan analisis informasi mengenai bagian orgnasisasi yang didukung oleh sistem basis data, dan menggunakan informasi tersebut untuk mengidentifikasi kebutuhan untuk sistem yang baru. Informasi dikumpulkan untuk setiap user view utama yang meliputi deskripsi data yang digunakan atau dihasilkan, detail mengenai bagaimana data digunakan atau dihasilkan dan beberapa kebutuhan tambahan untuk aplikasi basis data yang baru.
Terdapat tiga pendekatan untuk menentukan bagaimana mengatur aplikasi basis data dengan multiple user view yaitu:
a. Pendekatan Terpusat
Kebutuhan untuk setiap user view digabungkan menjadi sekumpulan kebutuhan
b. Pendekatan Integrasi View
Kebutuhan untuk setiap user view yang digunakan untuk membangun model data terpisah untuk merepresentasikan user view tersebut. Hasil dari model data tersebut nantinya akan digabungkan dalam tahapan desain basis data.
2.1.6.4 Database Design
Menurut Connolly dan Begg (2005, p291), database design merupakan suatu proses pembuatan sebuah desain basis data yang mendukung misi perusahaan dan misi objektif untuk kebutuhan sistem basis data. Terdapat 4 pendekatan dalam desain basis data :
- Top Down
Pendekatan ini diawali dengan pembentukan model data yang berisi beberapa entitas high level dan relationship. Yang kemudian menggunakan pendekatan top-down secara berturut-turut untuk mengidentifikasikan entitas lower level, relationship dan atribut lainnya.
- Bottom Up
Pendekatan ini dimulai dari atribut dasar (sifat-sifat entitas dan relationship), dengan analisis dari penggabungan antar atribut, yang dikelompokan kedalam suatu relasi yang mempresentasikan tipe dari entitas dan relationship antar entitas.
- Inside Out
Pendekatan ini berhubungan dengan pendekatan bottom up tetapi sedikit berbeda dengan identifikasi awal entitas utama dan kemudian menyebar ke entitas, relationship, dan atribut terkait lainnya yang lebih dahulu diidentifikasikan.
- Mixed Strategy
Pendekatan yang menggunakan pendekatan bottom up dan top down untuk bagian yang berbeda sebelum pada akhirnya digabungkan.
Tiga fase desain basis data menurut Connolly dan Begg (2005, p293), tahapan-tahapan dalam desain basis data:
1. Perancangan Basis data Konseptual (Conceptual Database Design) Menurut Connolly dan Begg (2005, p293), perancangan basis data konseptual merupakan suatu proses pembentukan model dari informasi yang digunakan dalam perusahaan, independen dari keseluruhan aspek fisik.Model data dibangun dengan menggunakan informasi dalam spesifikasi kebutuhan pengguna. Model data konseptual merupakan sumber informasi untuk fase desain logikal.
2. Perancangan Basis data Logikal (Logical Database Design)
Menurut Connolly dan Begg (2005, p294), perancangan basis data logikal merupakan suatu proses pembentukan model dari informasi yang digunakan dalam perusahaan berdasarkan model data tertentu, tetapi independen terhadap DBMS tertentu dan aspek fisik lainnya. Model data konseptual yang telah dibuat sebelumnya, diperbaiki dan dipetakan kedalam model data logikal.
3. Perancangan Basis data Fisikal (Physical Database Design)
Menurut Connolly dan Begg (2005, p294), perancangan basis data fisikal merupakan suatu proses yang menghasilkan deskripsi
implementasi basis data pada penyimpanan sekunder. Menggambarkan struktur penyimpanan dan metode akses yang digunakan untuk mencapai akses yang efisien terhadap data.
2.1.6.5 Database Management System Selection
Menurut Connolly dan Begg (2005, p295), Database
Management System Selection adalah pemilihan DBMS yang tepat untuk mendukung aplikasi basis data. Tahapan-tahapan utama dalam memilih DBMS:
1. Mendefinisikan terminologi dari studi referensi 2. Mendaftar 2 atau 3 produk
3. Evaluasi produk
4. Rekomendasi pilihan dan juga laporan produk
2.1.6.6 Application Design
Menurut Connolly dan Begg (2005, p299), Application Design adalah rancangan dari user interface dan aplikasi program yang digunakan dan proses dari sistem basis data.
2.1.6.7 Prototyping (Optional)
Menurut Connolly dan Begg (2005, p304), Prototyping dalah membangun model kerja suatu aplikasi basis data. Tujuan utama dari pembuatan prototyping adalah :
- Identifikasi fitur-fitur dari sistem yang berjalan dengan baik atau tidak. - Memberikan perbaikan-perbaikan atau penambahan fitur baru.
- Klarifikasi kebutuhan user.
- Evaluasi kemungkinan yang akan terjadi dari desain sistem khusus.
Terdapat dua macam strategi prototyping yang digunakan saat ini yaitu : 1. Requiment prototyping
Menggunakan prototype untuk menentukan kebutuhan dari aplikasi bass data yang diinginkan dan ketika kebutuhan itu terpenuhi prototype akan dibuang.
2. Evolutionary prototyping
Digunakan untuk tujuan yang sama. Perbedaannya, prototype tidak dibuang tetapi dengan pembembangan lanjutan menjadi aplikasi basis data yang digunakan.
2.1.6.8 Implementation
Menurut Connolly dan Begg (2005, p304),
implementationmerupakan realisasi fisik dari basis data dan desain aplikasi. Implementasi basis data dapat dicapai dengan menggunakan Data Definition Language (DDL) untuk membuat skema basis data dan file basis data kosong, DDL untuk membuat user viewyang diinginkan, 3GL dan 4GL untuk membuat program aplikasi. Termasuk transaksi basis
data disertakan dengan menggunakan DML,atau ditambahkan pada bahasa pemrograman.
2.1.6.9 Data Convertion and Loading
Menurut Connolly dan Begg (2005, p305), Data convertion and loading merupakan pemindahan data yang ada kedalam basis data baru dan mengkonvesikan aplikasi yang ada agar dapat digunakan pada basis data yang baru. Tahapan ini dibutuhkan ketika sistem basis data baru menggantikan sistem yang lama. DBMSbiasanya memiliki utilitas yang memanggil ulang fileyang sudah ada kedalam basis data baru, dapat juga mengkonversi dan menggunakan program aplikasi dari sistem yang lama untuk digunakan oleh sistem yang baru.
2.1.6.10 Testing
Menurut Connolly dan Begg (2005, p305), testing merupakan suatu proses eksekusi program aplikasi dengan tujuan untuk menemukan kesalahan. Dengan menggunakan strategi tes yang direncanakan dan data yang sesungguhnya. Pengujian hanya akan terlihat jika terjadi kesalahan software. Mendemonstrasikan basis data dan program aplikasi terlihat berjalan seperti yang diharapkan.
2.1.6.11 Operational Maintenence
Menurut Connolly dan Begg(2005, p306), Operational maintenence merupakan suatu proses pengawasan dan pemeliharaan sistem setelah instalasi, meliputi:
a. Pengawasan performa sistem, jika performa menurun maka menentukan perbaikan atau pengaturan ulang jadwal. b. Pemeliharaan aplikasi basis data jika dibutuhkan
c. Penggabungan kebutuhan baru kedalam aplikasi basis data
2.1.7 Entitiy Relationship Modelling 2.1.7.1 Tipe Entitas
Menurut Connolly dan Begg (2005, p343), tipe entitas adalah kumpulan dari objek-objek dengan sifat atau propertyyang sama, yang di identifikasi oleh enterprisemempunyai eksistensi yang independent. Keberadaannya dapat berupa fisik maupun abstrak.
Representasi diagram dari tipe entitas:
Gambar 2.2 Representasidiagramatikdari tipe entitasstaff dan branch Entity Name
Entity occurrence adalah pengidentifikasian objek yang unik dari sebuah tipe entitas. Setiap entitas di identifikasikan dan disertakan property-nya.
2.1.7.2 Relationship Type
Menurut Connolly dan Begg(2005, p346), relationship typeadalah kumpulan keterhubungan yang mempunyai arti antara tipe entitas yang ada. Relationship occurrence adalah keterhubungan yang diidentifikasi secara unik yang meliputi keberadaan tiap tipe entitas yang berpartisipasi.
Has
GAMBAR 2.3 Representasi relationship tipe branch memiliki staff
Menurut Connolly dan Begg (2005, p347), derajat relationship adalah jumlah entitas yang berpartisipasi dalam suatu relationship.
Derajat relationship terdiri dari :
Relationship Name
3. Binary relationship adalah keterhubungan antar dua tipe entitas. Contoh hubungan binary relationship adalah hubungan has pada gambar dibawah ini:
Has
‘Branch Has Staff’
GAMBAR 2.4 Representasi relationship tipe branch memiliki staff - Ternary relationship adalah keterhubungan antar tiga tipe entitas.
contoh dari ternary relationshipadalah registers dengan tiga tipe entitas.
- Quarternary relationship adalah keterhubungan antar empat tipe entitas.
- Unary relationship adalah keterhubungan antar tipe entitas, dimana tipe entitas tersebut berpartisipasi lebih dari satu kali dengan peran yang berbeda. Kadang disebut juga recursive relations.
Relationship Name
Branch Staff
2.1.7.3 Attribute
Menurut Connolly dan Begg (2005, p350), Attribute adalah sifat-sifat dari sebuah entity atau type relationship.
Domain Attribute adalah himpunan nilai yang diperbolehkan untuk satu atau lebih atribut.
Menurut Connolly dan Begg (2005, p351), jenis-jenis atribut antara lain: 1. Simple Attribute adalah atribut yang terdiri dari satu komponen tunggal
dengan keberadaan yang independent dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi. Dikenal juga dengan nama Atomic Attribute.
2. Composite Attribute adalah atribut yang terdiri dari berbagai komponen, dimana masing – masing komponen memiliki keberadaan yang independent. Misalkan atribut Address dapat terdiri dari Street, City, PostCode.
3. Single – valued Attribute adalah atribut yang mempunyai nilai tunggal untuk setiap kejadian. Misalkan entitas Branch memiliki satu nilai untuk atribut branchNo pada setiap kejadian.
4. Multi-valued Attribute adalah atribut yang mempunyai beberapa nilai untuk setiap kejadian. Misalkan entitas Branch memiliki beberapa nilai untuk atribut telpNo pada setiap kejadian.
5. Derived Attribute adalah atribut yang memiliki nilai yang dihasilkan dari satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entitas.
Menurut Connolly dan Begg (2005, p352), macam-macam tipe keys yaitu:
- Candidate Key adalah jumlah minimal atribut-atribut yang dapat mengidentifikasikan setiap kejadian / record secara unik.
- Primary Keyadalah candidate key yang dipilih untuk meng-identifikasikan setiap kejadian / record dari suatu entitas secara unik. - Composite Key adalah candidate key yang terdiri dari dua atau lebih
atribut.
- Foreign Key adalah atribut sebuah tabel yang menggabungkan diri ke tabel lain.
2.1.7.4 Strong and Weak Entity Type
Menurut Connolly dan Begg (2005, p354), entitas Strong dan Weak Type adalah entitas yang keberadaannya tidak bergantung pada entitas lain, sedangkan Weak TypeEntitas adalah entitas yang keberadaannya bergantung pada entitas lain. Strong TypeEntitas terkadang disebut dengan parent, owner dominant dan Weak Type Entitas disebut child, dependent, subordinate.
2.1.7.5 Structural Constraint
Menurut Connolly (2005, p356), batasan utama pada relationship disebut multiplicity.Multiplicityadalah jumlah kemungkinan dari kejadian yang mungkin terjadi pada suatu entitas yang terhubung ke satu kejadian dari entitas lain yang berhubungan melalui suatu relationship.
Hubungan binary secara umum dibedakan menjadi: a. One-to-One (1:1) Relationships
Gambar 2.5 One to One Relationship
Pada gambar dapat dilihat 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 dapat dituliskan notasi multiplicity-nya dengan gambar di bawah ini.
b. One-to-Many (1:*) Relationships
Gambar 2.7 One to Many Relationship
Pada gambar dapat dilihat bahwa B terhubung One-to-Many (1 : *) dengan D dan E. Jadi dari gambar tersebut dapat dituliskan notasi multiplicity-nya dengan gambar di bawah ini.
c. Many-to-Many (*:*) Relationships
Gambar 2.9 Many-to-Many Relationships
Pada gambar, dapat dilihat bahwa A terhubung One-to-Many (1 : *) dengan A dan B. Jadi dari entitas 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 dapat dituliskan notasi multiplicity-nya dengan gambar di bawah ini.
Gambar 2.10 Notasi Many-to-Many Relationships
2.1.8 Normalisasi
2.1.8.1 Pengertian Normalisasi
Menurut Connolly dan Begg (2005, p388), “Normalization is a technique for producing a set of relations with desirable properties, given
the data requirements of an enterprise” , dapat diartikan sebagai
normalisasi adalah sebuah teknik untuk menghasilkan sekumpulan relasi dengan sifat – sifat yang diinginkan, untuk memenuhi kebutuhan data pada perusahaan.
2.1.8.2 Tahap – tahap Normalisasi
Tahap – tahap Normalisasi yang biasa digunakan terdiri dari: - Unnormalized Form (UNF)
Menurut Connolly dan Begg (2005, hal 402), suatu tabel yang berisikan satu atau lebih grup/data yang berulang.
- First Normal Form (1NF)
Menurut Connolly dan Begg (2005, p403), sebuah relasi dimana setiap irisan antara baris dan kolom berisikan satu dan hanya satu nilai. - Second Normal Form (2NF)
Menurut Connolly dan Begg (2005, p407), suatu relasi yang ada dalam 1NF dan setiap atribut bukan primary keybergantung penuh secara fungsional pada primary key.
- Third Normal Form(3NF)
Menurut Connolly dan Begg (2005, p409), suatu relasi yang ada dalam 1NF dan 2NF dan atribut bukan non-primary keybergantung secara transitif pada primary key.
2.1.9 Metodologi Perancangan Sistem Basis Data 2.1.9.1 Perancangan Sistem Basis Data Konseptual
Menurut Connolly dan Begg (2005, p439), perancangan sistem basis data konseptual adalah suatu proses pembentukan model dari informasi yang digunakan dalam perusahaan, independentdari semua aspek fisik.
Menurut Connolly dan Begg (2005, p442), langkah – langkah yang digunakan antara lain:
Langkah 1 : Membangun model data konseptual lokal untuk masing-masing view
Tahap 1.1 Mengidentifikasi tipe – tipe entitas
Tujuan : untuk mengidentifikasikan tipe entitas utama yang akan dibangun. Langkah pertama dalam membangun model data konseptual lokal mengidentifikasi objek pertama user. Objek ini adalah tipe entitas untuk model tersebut. Salah satu metode untuk mengidentifikasikan entitas adalah dengan memeriksa spesifikasi kebutuhan user. Dari spesifikasi ini, kita mengidentifikasi kata benda. Contoh tipe entitas: StaffNumber, StaffName, PropertyNumber, PropertyAddress, Rent, NumberOfRoom. Sesudah tipe – tipe entitas diidentifikasi, pemberian nama untuk tiap entitas harus jelas. Nama dan deskripsi entitas sebaiknya disimpan dalam kamus data. Jika sebuah entitas dikenal dengan nama lain yang disebut sinonim atau alias maka disimpan pada kamus data.
Tahap 1.2 Identifikasi tipe relationship(relasi)
Tujuan: untuk mengidentifikasi relationship yang penting terdapat diantara tipe entitas yang telah diidentifikasi.
Salah satu metode yang digunakan untuk mengidentifikasi tipe relasi, yaitu dengan cara mencari kata benda didalam spesifikasi kebutuhan user. Contoh : Staff Manage PropertyForRent, PrivateOwner, PrivateOwner Owns PropertyForRent AssociatedWith Lease.
Tahap 1.3 Identifikasi tipe dan menggabungkan attribute dengan entitas atau tipe relasi
Tujuan : untuk mengasosiasikan atribut yang sesuai dengan entitas atau tipe relasi.
Metode yang digunakan mirip dengan identifikasi tipe entitas yaitu dengan dengan mencari kata benda dalam spesifikasi kebutuhan user. Menurut Connoly dan Begg (2003, p339), terdapat 3 jenis atribut: - Simple Attribute
Simple Attribute adalah atribut yang terdiri dari satu komponen tunggal dengan keberadaan yang independent dan tidak dapat dibagi menjadi bagian yang lebih kecil lagi. Dikenal juga dengan nama Atomic Attribute Composite Attribute adalah yang terdiri dari beberapa komponen, dimana masing – masing komponen memiliki keberadaan yang independen. Misalkan atribut Addressdapat terdiri dari Street, City, PostCode.
- Single atau multivalue attributes
Single-valued Attribute adalah atribut yang mempunyai nilai tunggal untuk setiap kejadian. Misalkan entitas Branchmemiliki satu nilai untuk atribut branchNopada setiap kejadian.
Multi-valued Attribute adalah atribut yang mempunyai beberapa nilai untuk setiap kejadian. Misalkan entitas Branch memiliki beberapa nilai untuk atribut telpNopada setiap kejadian.
- Derived attribute
Derived Attribute adalah atribut yang memiliki nilai yang dihasilkan dari satu atau beberapa atribut lainnya, dan tidak harus berasal dari satu entitas.
Tahap 1.4 Menentukan domain attribute
Tujuan : untuk menentukan domain atribut pada model data konseptual. Domain Attribute adalah himpunan nilai yang diperbolehkan untuk satu atau lebih atribut. Contoh: domain atribut dari nomor staff (staffNo) memiliki panjang karakter 5, dengan 2 karakter pertama berupa huruf dan 3 karakter selanjutnya berupa angka antara
1 -999 . Model data yang baik menspesifikasikan domainuntuk setiap atribut meliputi kumpulan nilai untuk setiap atribut dan ukuran beserta format atribut.
Tahap 1.5 Menentukan atribut candidate dan primary key
Tujuan : untuk mengidentifikasi candidate keypada masing – masing tipe entitas dan, jika terdapat lebiih dari satu candidate key, pilih salah satu untuk dijadikan primary key.
Candidate Key adalah jumlah minimal atribut-atribut yang dapat mengidentifikasikan setiap kejadian atau record secara unik.
Primary Key adalah candidate key yang dipilih untuk meng-identifikasikan setiap kejadian atau recorddari suatu entitas secara unik. Composite Key adalah candidate key yang terdiri dari dua atau lebih atribut.Foreign key adalah atribut sebuah tabel yang menggabungkan diri ke tabel lain.
Tahap 1.6 Mempertimbangkan konsep pemodelan echanced (optional step)
Tujuan : untuk mempertimbangkan penggunaan konsep pemodelan enhanced , seperti/generalisasi, agregasi dan komposisi.
Pada pendekatan spesialisasi, harus memperhatikan perbedaan antara entitas dengan mendefinisikan satu atau lebih subclassdari sebuah entitas superclass. Jika memilih pendekatan generalisasi, diusahakan untuk mengidentifikasi fitur-fitur umum antar entitas untuk mendefinisikan sebuah entitas superclass generalisasi. Pendekatan agregasi digunakan
untuk menghadirkan hubungan “mempunyai - sesuatu” atau “bagian dari “ relasi antara tipe entitas, dimana yang satu menghadirkan “keseluruhan” dan yang lainnya sebagai “bagian nya”. Komposisi menghadirkan hubungan diantara tipe entitas dimana terdapat kepemilikan yang kuat keterhubungan antara “keseluruhan” dan bagiannya”.
Tahap 1.7 Cek model dari redundancy
Tujuan : untuk memeriksa adanya redudansi pada model. Terdapat dua aktifitas dalam tahapan ini :
- Memeriksa kembali relasi one to one (1 : 1)
Pada saat mengidentifikasi entitas, mungkin akan teridentifikasi 2 entitas yang mempresentasikan objek yang sama pada perusahaan. Untuk kejadian ini, kedua entitas harus digabung jika primary key berbeda, pilih salah satu primary key tersebut dan biarkan yang ain sebagai alternate key.
- Menghilangkan relasi yang redudansi
Suatu relasi dikatakan redudansi jika informasi yang sama dapat diperbolehkan melalui relasi yang lain.
Tahap 1.8 Validasi model konseptual lokal terhadap transaksi user Tujuan : untuk memastikan bahwa model konseptual lokal mendukung
Dua pendekatan yang mungkin dilakukan untuk memastikan bahwa model data konseptual mendukung transaksi yang dibutuhkan :
- Mendeskripsikan transaksi
Memeriksa apakah semua informasi (entitas, relasi dan atributnya) yang dibutuhkan oleh setiap transaksi telah disediakan oleh model, dengan mendokumentasikan sebuah deskripsi dari kebutuhan transaksi.
- Memakai jalur transaksi
Memvalidasi model data terhadap transaksi yang dibutuhkan yang melibatkan diagram yang menghadirkan jalur setiap transaksi dalam ERD.
Tahap 1.9 Review model konseptual data lokal terhadap need user Tujuan : untuk meninjau kembali model data konseptual lokal dengan user untuk memastikan model yang dihadirkan sesuai.
Pada tahap ini, data konseptual lokal akan ditinjau ulang oleh user. Model data konseptual meliputi ERD dan dokumentasi pendukung yang menggambarkan model data tersebut. Jika terjadi anomali pada model data, maka harus dilakukan perubahan yang mungkin memerlukan pengulangan tahapan-tahapan sebelumnya. Proses ini terus berulang sampai model data benar-benar menjadi representasi aktual dari perusahaan.
2.1.9.2 Perancangan Sistem Basis Data Logikal
Menurut Connolly dan Begg (2005, p439), perancangan sistem basis data logikal adalah proses pembangunan model informasi yang digunakan pada sebuah perusahaan berdasarkan model data spesifik, tetapi tidak tergantung pada database management system dan pertimbangan fisikal lainnya.
Menurut Connolly dan Begg (2005, p462), langkah-langkah yang digunakan antara lain :
Langkah 2 Membangun dan memvalidasi model data logikal lokal untuk masing-masing view
Tujuan : untuk membangun model data logikal lokal dari model data konseptual lokal yang menghadirkan view tertentu dari perusahaan dan memvalidasikan model ini untuk menjamin agar strukturnya benar (menggunakan teknik normalisasi) dan menjamin dalam mendukung transaksi yang dibutuhkan.
Tahap 2.1 Menentukan relasi untuk model data logikal
Tujuan : membuat relasi untuk data logikal yang dapat menghadirkan entitas, relasi, dan hhubungan yang telah teridentifikasi.
Pembagian relasi dari sebuah model data diantaranya : 1. Tipe entitas kuat (Strong Entity)
Pada setiap entitas kuat pada model data, buat sebuah relasi yang memasukkan semua simple atribute dari entitas tersebut. Untuk
composite attribute, seperti name, dimasukkan hanya bagian penting dari simple attribute, dinamakan fName dan lName dalam relasi.
Contoh : Staff(StaffNo, fName, lName, Posisition, Sex, DOB) Primary Key (StaffNo).
2. Tipe entitas lemah (Weak Entity)
Pada setiap entitas lemah pada model data, buat sebuah relasi yang memasukkan semua simple attribute dari entitas. Primary key dari entitas lemah partially atau sepenuhnya diturunkan dari setiap pemilik entitas dan identifikasi dari primary key pada entitas lemah tidak dapat dibuat sampai seluruh relasi dengan pemilik entitas telah ditetapkan.
Contoh : Preference(PrefType, MaxRent) Primary key None (at present). Pada situasi ini,m primary key untuk relasi preference tidak dapat diidentifikasi sampai hubungan states telah dipetakan.
3. Tipe relasi binary One to many (1 : *)
Pada setiap hubungan binary 1 : *, entitas pada “one side” dari hubungan relasi dirancang sebagai parent entity dan entitas pada “many side” dirancang sebagai child entity.
4. Tipe relasi One to one (1 : 1)
Membuat hubungan untuk merepesentasikan relasi 1 : 1 sedikit lebih rumit sebagai cardinality tidak dapat digunakan untuk mengindentifikasi relasi entitas parent dan child.
5. Tiper relasi recursive one to one (1 : 1)
Relasi recursive 1 : 1, aturan untuk partisipasi sebagai penggambaran relasi one to one (1 : 1).
6. Tipe relasi superclass atau subclass
Pada setiap relasi superclass atau subclass pada model data konseptual, kita mengiddentifikasi entitas superclass sebagai parent entity dan entitas subclass sebagai child entity.
7. Tipe relasi binary many to many (* : *)
Pada setiap relasi binary * : *, buat sebuah hubungan untuk menghadirkan relasi dan menyertakan atribut apa saja yang termasuk dalam baguan daari relasi.
8. Tipe relasi kompleks
Pada setiap relasi kompleks, buat sebuah hubungan yang menghadirkan relasi dan sertakan beberapa atribut yang merupakan bagian dari relasi. 9. Atribut multi valued
Pada setiap atribut multi valued dalam entitas, buat relasi baru untuk menghadirkan atribut multi valued dan sertakan juga primary key dari entitas untuk relasi baru dan bertindak sebagai foreign key.
Tahap 2.2 validasi hubungan menggunakan normalisasi
Tujuan : untuk memvalidasikan hubungan pada model data logik lokal menggunakan teknik normalisasi.
1. First normal form (1NF)
Menghilangkan kelompok yang berulang. 2. Second normal form (2NF)
Menghilangkan ketergantungan parsial pada primary key. 3. Third normal form (3NF)
Menghilangkan ketergantungan transitif pada primary key. 4. Boyce codd normal form (BCNF)
Menghilangkan anomali dari ketergantungan fungsional.
Tahap 2.3 Validasikan hubungan terhadap transaksi user
Tujuan : untuk memastikan hubungan pada model data logikal yang mendukung kebutuhan transaksi oleh view.
Pada tahap 1.8 memastikan bahwa model data konseptual lokal mendukung kebutuhan transaksi. Pada tahap ini, dilakukan pengecekkan relasi yang dibuat pada langkah sebelumnya mendukung transaksi tersebut dan memastikan tidak terdapat error yang telah diketahui ketika membuat hubungan.
Tahap 2.4 menetapkan batasan integritas
Tujuan : untuk menetapkan batasan integritas yang telah diberikan pada view.
Batasan integritas adalah batasaan yang telah ditentukan untuk melindungi basis daa dari ketidakkonsistenan.
Lima tipe dari batasan integritas yang harus diperhatikan : 1. Data yang dibutuhkan
Beberapa atribut harus memilki sebuah nilai yang valid (tidak mengandung null).
Contoh : setiap anggota staff harus memiliki jabatan. 2. Batasan domain atribut
Setiap atribut memilki sebuah domain (sekumpulan nilai harus sah). Contoh : jenis kelamin dari anggota staff dapat “M” atau “F”, jadi domain dari atribut jenis kelamin adalah karakter tunggal. Batasaan ini harus diidentifikasi dalam kamus data.
3. Integritas entitas
Primary key dari entitas tidak boleh null.
Contoh : setiap baris dari relasi staff harus memiliki nilai untuk atribut primary key.
4. Integritas referensial
Sebuah foreign key menghubungkan setiap baris pada relasi child kedalam relasi parent dengan menyamakan nilai dari candidate key. 5. Batasan perusahaan
Tahap 2.5 Meninjau kembali model data logikal lokal dengan user Tujuan : untuk memastikan bahwa model data logikal lokal dan dokumentasi pendukung yang menggambarkan model yang sesuai dengan view.
Model data logikal lokal pada view harus diselesaikan dan didokumentasikan. Untuk menyelesaikan tahapan ini, dilakukan peninjauan model logikal dan dukungan dokumentasi dengan user.
Tahap 2.6 Menggabungkan model data logikal kedalam model global Tujuan : untuk menggabungkanmodel data logikal lokal kedalam single model data logikal global yang menghadirkan semua user view dari basis data.
Tahap 2.6.1 Menggabungkan model data logikal lokal kedalam single model data logikal global
Tujuan : untuk menggabungkan model data logikal lokal kedalam single model data logikal global.
1. Review nama-nama dan isi dari entitas dan relasi dan candidate keys nya.Masalah dapat muncull ketika dua atau lebih entitas :
- Memiliki nama yang sama tetapi pada kenyataannya berbeda (homonim).
- Sama tetapi berbeda namanya(sinonim).
3. Menggabungkan entitas atau relasi dari model data lokal. Aktifitas khusus yang terlibat dalam tugas ini antara lain :
- Menggabungkan entitas atau relasi dengan nama yang sama dan primary key yang sama.
- Menggabungkan entitas atau relasi dengan nama yang sama tetapi primary key nya berbeda.
- Menggabungkan entitas atau relasi dengan nama yang berbeda menggunakan primary key yang sama tau berbeda.
4. Memasukkan (tanpa menggabungkan) entitas atau relasi unik pada tiap-tiap model data lokal.
5. Menggabungkan relasi atau foreign keys dari model data lokal. Aktifitas pada langkah ini antara lain :
- Menggabungkan relasi atau foregn keys dengan nama yang sama dan tujuan yang sama.
- Menggabungkan relasi atau fireign keys dengan nama yang berbeda tetapi tujuan yang sama .
6. Memasukkan (tanpa menaggabungkan) relasi atau fireign keys unik pada setiap model data logikal.
7. Memeriksa entitas yang hilang dan relasi atau fireign keys. 8. Memeriksa foreign keys.
9. Memeriksa batasan integritas.
10. Menggambar global ER/ diagram relasi. 11. Update dokumentasi.
Tahap 2.6.2 Memvalidasikan model data logikal global
Tujuan : untuk memvalidasikan relasi yang dibuat dari model data logikal global menggunakan teknik normalisasi dan memastikan dukungan terhadap kebutuhan transaksi.
Tahap 2.6.3 Review model data logikal global dengan user view
Tujuan : untuk mereview model data logikal global dengan pengguna untuk memastikan bahwa mereka menanggap model untuk menjadi representasi sejati dari kebutuhan darta dari perusahaan.
Tahap 2.7 Memeriksa pertumbuhan masa depan
Tujuan : untuk menentukan apakah terdapat perubahan yang nyata dimasa depan dan menilai apakah model data logikal dapat mengakomodasi perubahan ini.
2.1.9.3 Perancangan Sistem Basis Data Fisikal
Menurut Connolly dan begg (2005, p296), Perancangan Sistem basis Data fisikal adalah suatu proses yang menghasilkan deskripsi implementasi basis data pada pemyimpanan sekunder. Menggambarkan struktur pemyimpanan dan metode akses yang digunakan mencapai akses efisien terhadap data. Dapat dikatakan juga desain fisikal merupakan cara pembuatan menuju sistem DBMS tertentu.
Menurut Connolly dan begg (2005, p497), langkah-langkah yang digunakan antara lain :
Langkah 3 Terjemahkan model data logikal global untuk target DBMS
Tujuan : untuk menghasilkan skema basis data relasional dari model data logikal yang dapat diimplementasikan pada sasaran DBMS.
Tahap 3. 1 Merancang relasi dasar
Tujuan : untuk memutuskan bagaimana menghadirkan identifikasi relasi dasar dalam model data logikal kedalam sasaran DBMS.
Pada masing-masing identifikasi relasi pada model data logikal, definisinya terdiri dari :
- Nama relasi.
- Daftar kurung simple attribute.
- Primary key dan, yang sesuai dengan alternate keys dan foreign keys. - Batasan integritas referensial untuk beberapa identifikasi foreign keys. Dari kamus dara, masing-masing atribut antara lain :
- Domainnya, terdiri dari tipe data, panjang dan beberapa batasan domain.
- Sebuah nilai default opsional untuk atribut. - Apakah atribut dapat bernilai null.
- Apakah atribut dihasilkan dan jika demikian bagaimana cara mengkomputasinya.
Tahap 3.2 Merancang representasi dari data yang dihasilkan
Tujuan : untuk memutuskan bagaimana unbtuk mewakili data yang diperoleh dalam model data logikal dalam target DBMS.
Tahap 3.3 Merancang batasan-batasan perusahaan
Tujuan : untuk merancang batasan-batasan umum untuk sasaran DBMS.
Langkah 4 Desain organisasi file dan indeks-indeks
Tujuan : untuk menghasilkan skema basis data relasional dari model data logikal yang dapat diimplementasikan pada sasaran DBMS.
Tahap 4.1 Analisa transaksi-transaksi
Tujuan : untuk memahami fungsi dari transaksi-transaksi yang akan dijalankan pada basis data dan untuk menganalisis transaksi-transaksi yang penting.
Untuk melakukan desain basis data fisikal secara efektif, harus memiliki pengetahuan mengenai transaksi atau query yang akan berjalan pada basis data. Ini mencakup baik informasi kualitatif maupun kuantitatif. Dalam menganalisis transaksi, kita mencoba untuk mengidentifikasi kinerja, sseperti :
- Transaksi yang sering berjalan dan memiliki dampak signifikan pada suatu kinerja.
- Sealama perhari/minggu ketika akan ada permintaan tinggi yang dibuat pada basis data(disebut belum puncak).
Tahap 4.2 Pilih organisasi file
Tujuan : untuk menentukan organisasi file yang efisien untuk setiap relasi dasar.
Adapun tipe organisasi file : - Heap.
- Hash.
- Indexed Sequential Offiece Access Method (ISAM) - B*-tree.
- Clusters.
Tahap 4.3 Pilihan indeks-indeks
Tujuan : untuk memutuskan bagaimana menghadirkan identifikasi relasi dasar dalam model data logikal kedalam sasaran DBMS.
Salah satu pendekatan untuk memilih organisasi file yang sesuai untuk relasi adalah untuk menjaga tupel yang tidak terurut dan membuat sebagai indeks sekunder yang diperlukan. Pendekatan lain adalah uturan tuple dalam relasi dengan menentukan indeks utama atau clustering. Dalam hal ini, pilih atribut untuk mengatur atau clustering tupel sebagai :
- Atribut yang paling sering digunakan untuk bergabung dengan operasi, karena hal ini membuat operasi bergabung lebih efisien.
- Atribut yang digunakan paling sering untuk mengakses tuple dalam suatu relasi dalam urutan yang atribut. Xxxxxx
Jika mengatur atribut yang dipilih adalah sebagai kunci daru relasi, indeks akan menjadi indeks utama; jika mengatur atribut bukan sebagai kunci, indeks akan menjadi indeks clustering. Ingat bahwa setiap relasi hanya dapat memiliki sebuah indeks utama atau indeks clustering.
Tahap 4.4 perkirakan kebutuhan tempat penyimpanan
Tujuan : untuk memperkirakan jumlah tempat penyimpanan yang akan dibutuhkan oleh basis data.
Langkah 5 Merancang user view
Tujuan : untuk merancan user view yang diidentifikasikan selama pengumpulan kebutuhan dan analisis pada tahap Database system development lifecycle.
Langkah 6 Merancang mekanisme keamanan
Tujuan : untuk merancang mekanisme keamanan untuk basis data sebagaimana ditentukan oleh user selama pengumpulan kebutuhan dan analsisis pada tahap Database system development lifecycle.
Pada DBMS relasional umumnya memberikan dua jenis keamanan database yaitu:
- Sistem keamanan
Sistem keamanan meliputi akses dan penggunaan basis data pada tingkat sistem, seperti nama pengguna dan password
- Keamanan data
Keamanan data meliputi akses dan penggunaan objek basis data (seperti sebagai relasi dan view) dan tindakan userdapat memiliki objek.
Langkah 7 : Pertimbangkan pengenalan dari redudansi terkontrol Tujuan : untuk menentukan apakah memperkenalkan redudansi yang dikendalikan oleh aturan normalisasi yang longgar akan meningkatkan kinerja sistem.
Tahap 7.1 Menggabungkan relasi 1 : 1
Tujuan : untuk memeriksa kembali relasi (1: 1) untuk menentukan dampak dari menggabungkan relasi ke dalam relasi tunggal.
Kombinasi hanya harus dipertimbangkan untuk relasi yang sering direferensikan bersama – sama dan jarang direferensikan secara terpisah
Tahap 7.2 Mengurangi join duplikasi atribut nonkey pada relasi 1 : * Tujuan : untuk mengurangi atau menghapus joindari frequent atau critical queries, mempertimbangkan manfaat yang dapat mengakibatkan duplikasi satu atau lebih atribut non-key dari relasi parent dalam relasi child pada relasi 1: *.
Tahap 7.3 Mengurangi join duplikasi atribut foreign key pada relasi 1 : *
Tujuan : untuk mengurangi atau menghapus join dari frequent atau critical queries, mempertimbangkan manfaat yang dapat mengakibatkan duplikasi satu atau lebih atribut foreign key dalam sebuah relasi.
Tahap 7.4 Mengurangi join duplikasi atribut pada relasi * : *
Tujuan : untuk mengurangi jumlah relasi akan bergabung dengan duplikasi atribut dari salah satu entitas asli dalam relasi menengah.
Tahap 7.5 Memperlihatkan grup pengulangan
Tujuan : untuk menghilangkan grup pengulangan dari model data logikal sebagai hasil dari kebutuhan bahwa semua entitas dalam bentuk normal pertama.
Grup pengulangan yang dipisahkan ke relasi baru, membentuk relasi 1:* dengan relasi (parent) asli. Seringkali, grup pengulang memperkenalkan kembali suatu cara yang efektif untuk meningkatkan kinerja sistem.
Tahap 7.6 Membuat tabel ekstra
Tujuan : untuk membuat dan mengisi tabel dalam menjalankan overnight batch bila sistem yang ringan dimuat.
Tahap 7.7 Relasi partisi
Tujuan : untuk mengkombinasikan relasi bersama – sama sebagai pendekatan alternative pada alamat masalah key dengan mendukung relasi yang sangat besar
(dan indeks).
Penguraian tersebut menjadi suatu potongan yang lebih kecil dan lebih mudah dikelola disebut partisi.
Langkah 8: Awasi dan atur sistem operasional
Tujuan : untuk memonitor sistem operasional dan meningkatkan kinerja sistem untuk memperbaiki keputusan perancangan yang tidak tepat atau mencerminkan perubahan kebutuhan.
Terdapat nomor faktor yang kita dapat gunakan untuk mengukur efisiensi :
- Transaksi Throughput adalah jumlah transaksi yang dapat diproses dalam suatu interval waktu. Dalam beberapa sistem, seperti reservasi penerbangan, transaksi throughput yang tinggi adalah penting untuk keberhasilan keseluruhan sistem.
- Response time adalah waktu yang telah berlalu untuk menyelesaikan satu transaksi.Dari sudut pandang user, kami ingin meminimalkan waktu respon sebanyak mungkin.
Namun, ada beberapa faktor yang mempengaruhi waktu respon bahwa perancang mungkin telah tidak ada kontrol atas, seperti loading sistem atau kali komunikasi. Response time dapat diperpendek oleh:
- Mengurangi jumlah waktu yang diperlukan sumber daya. - Menggunakan komponen lebih cepat
- Disk penyimpanan adalah jumlah ruang disk yang diperlukan untuk menyimpan file basis data. Para perancang mungkin ingin meminimalkan jumlah tempat penyimpanan yang digunakan.
2.2 Tools yang digunakan
Pada sub bab ini akan dijelaskan mengenai toolsyang digunakan dalam proses analisis data dan perancangan sistem basis data ini .
2.2.1 Analisis dan Perancangan
Tools yang digunakan dalam analisis dan perancangan sistem basis data ini adalah:
a. Data Flow Diagram(DFD)
Menurut Whitten et al. (2004, p326) , diagram aliran data adalah model proses yang digunakan untuk menggambarkan aliran data melalui sebuah sistem dan tugas atau pengolahan yang dilakukan sistem. Hanya ada tiga simbol dan satu koneksi dalam DFD yaitu :
1. Proses adalah kerja yang dilakukan pada atau sebagai respons terhadap aliran data masuk atau kondisi
2. Data flow menunjukkan input data ke proses atau output data (atau informasi) dari proses. Data flow juga digunakan untuk menunjukkan pembuatan, pembacaan, penghapusan atau pembaruan data dalam file atau database
Gambar 2.12 Simbol Data Flow
3. External Agent mendefinisikan orang, unit organisasi, sistem atau organisasi luar yang berinteraksi dengan sistem
Gambar 2.13 Simbol External Agent
4. Data store adalah penyimpanan data yang ditunjukan untuk penggunaan selanjutnya.Sinonimnya adalah file dan database.
b. Flowchart
Menurut Mulyadi (2001, p60), bagan alir dokumen (flow chart ) digunakan untuk menggambarkan aliran dokumen dalam sistem tertentu. Adapun simbol yang digunakan dalam bagan alir dokumen yaitu :
1. Dokumen
Menggambarkan semua jenis dokumen, formulir yang diperlukan untuk merekan data terjadinya suatu transaksi.
Gambar 2.15 – Simbol Dokumen
2. Penghubung pada halaman yang sama ( on-page connector)
Karena keterbatasan ruang halaman kertas untuk menggambar, maka diperlukan simbol penghubung untuk memungkinkan aliran dokumen berhenti di suatu lokasi pada halaman tertentu dan kembali berjalan di lokasi lain pada halaman yang sama.
3. Kegiatan manual
Menggambarkan kegiatan manual seperti : menerima order pembeli, mengisi formulir.
Gambar 2.17 Simbol Kegiatan Manual 4. Keputusan
Menggambarkan keputusan yang harus dibuat dalam proses pengolahan data
Gambar 2.18 Simbol Keputusan
5. Garis Alir (flowline)
Menggambarkan arah proses pengolahan data. Anak panah tidak digambarkan jika dokumen mengalir ke bawah dan ke kanan.
6. Mulai atau Akhir
Menggambarkan awal dan akhir suatu sistem akuntansi.
Gambar 2.20 Simbol Mulai atau Akhir
c. Use-case Diagram
Menurut Whitten, Bentley dan Dittman (2004, p257), use-case diagram adalah suatu diagram yang menggambarkan interaksi antara sistem eksternal dan pengguna. Dengan kata lain, secara grafis menggambarkan siapa yang akan menggunakan sistem dan dengan cara apa pengguna mengharapkan untuk berinteraksi dengan sistem. Notasi yang digunakan dalam use-case diagram antara lain :
1. Menurut Munawar (2005, p64) , Actoradalah abstraction dari orang dan sistem yang lain yang mengaktifkan fungsi dari target sistem.
2. Menurut Munawar (2005, p65), Use case adalah abstraksi dari interaksi antara sistem dan actor. Use case harus merupakan ‘apa’ yang dikerjakan software aplikasi, bukan ‘bagaimana’ software aplikasi mengerjakannya.
Gambar 2.22 Simbol Use Case
3. Menurut Munawar (2005, p66) , Stereotype adalah sebuah model khusus yang terbatas untuk kondisi tertentu. Untuk menunjukkan stereotype digunakan simbol “<<” diawalnya dan ditutup “>>” diakhirnya. <<extend>> digunakan untuk menunjukkan bahwa satu use case merupakan tambahan fungsional dari use case yang lain jika syarat atau kondisi tertentu dipenuhi, <<include>> digunakan untuk menggambarkan bahwa suatu use case seluruhnya merupakan fungsionalitas dari use case lainnya.
d. Entity-Relationship Diagram(ERD)
Entity – relationship diagram adalah suatu model untuk menjelaskan hubungan antara data dalam basis data berdasarkan objek – objek data yang mempunyai hubungan antar relasi.
ERD mempunyai tiga elemen dasar : 1. Entity types
Dikenal juga sebagai object types. Entity types dapat
merepresentasikan objek-objek fisikal seperti : buku, orang , dan tempat , dan lain – lain.
MsCustomer
Gambar 2.23 Simbol Entity Types 2. Relationships
Nama dari hubungan diantara entity types , sebuah relationship merepresentasikan hubungan dua arah diantara entitas – entitas (bidirectional).
Gambar 2.24 Simbol Relationships
3. Attributes
Setiap entitas pasti mempunyai elemen yang disebut attribute yang berfungsi untuk mendeskripsikan karakteristik dari entitas tersebut. Isi dari attribute mempunyai sesuatu yang dapat mengidentifikasikan isi elemen satu dengan yang lain.
MsCustomer
PK CustomerID
CustomerName
CustomerAddress
CustomerPhone
Gambar 2.25 Simbol Attributes
e. State Transition Diagram(STD)
State Transition Diagram menurut Whitten, Bentley dan Dittman (2004, p673), state transition diagram (STD) adalah suatu alat yang digunakan untuk menggambarkan urutan dan variasi dari layar yang dapat terjadi selama suatu sesi pengguna. Notasi yang digunakan dalam STD adalah:
1.State, adalah kumpulan suatu keadaan atau atribut – atribut yang mencirikan benda atau orang pada keadaan, waktu dan kondisi tertentu.
Gambar 2.26 Notasi State
2. Transition State, menunjukkan perubahan state ditandakan dengan tanda panah.
Kondisi
Aksi
Gambar 2.27 Notasi Transition State
Suatu STD dapat menjadi cukup besar, terutama ketika semua input, output, help, dan layar-layar lainnya dimasukkan ke dalam diagram. Maka dari itu, umumnya diagram dipisah menjadi beberapa diagram yang lebih sederhana dan lebih mudah dibaca. Ada 2 hal yang perlu ditambahkan untuk melengkapi STD, yaitu:
1. Kondisi adalah keadaan lingkungan luar yang dapat dideteksi oleh sistem dan dapat menyebabkan perubahan state. Kondisi dapat berubah sinyal, interrupt , dan lainnya.
2. Aksi adalah apa yang dilakukan sistem jika ada perubahan state. Aksi dapat menghasilkan keluaran, tampilan pesan pada layar pengguna, membuat kalkulasi, dan lainnya.
2.2.2 Programming Tools
Programming tools yang digunakan dalam perancangan sistem ini adalah NetBeans yang merupakan platform aplikasi framework untuk
aplikasi java desktop yang menggunakan gabungan bahasa pemograman
dari Java, PHP, C/C++, dan HTML 5. NetBeans IDE ditulisa dalam Java dan dapat berjalan di Windows, OSX, Linux, Solaris dan paltform lain yang mendukung JVM kompatibel. NetBeans ini telah dikolaborasikan dengan beberapa jenis aplikasi, seperti aplikasi desktop dan aplikasi berbasis web.
2.2.3 Sistem Manajemen Basis Data (DBMS)
Sistem Manajemen Basis Data yang digunakan dalam pembuatan
sistem ini adalah Microsoft SQL Server. SQL Server adalah RDBMS (Relational Database Management System) yang dikembangkan oleh Microsoft. SQL Server dapat digunakan sebagai basis data untuk kebutuhan personal, seperti basis data pada Windows Mobile Device serta aplikasi yang menggunakan basis data dengan banyak server.
2.3 Pemahaman Objek Studi
Pada sub bab ini akan dijelaskan mengenai pemahaman – pemahaman yang berhubungan dengan objek studi pada skripsi ini.
2.3.1 Penjualan
Menurut Kotler (2006, p457), penjualan merupakan proses dimana kebutuhan pembeli dan penjualan dipenuhi, melalui antar pertukaran informasi dan kepentingan.
Menurut Mulyadi (2001,p202), dilihat dari segi pembayarannya,
maka penjualan dapat dikelompokkan menjadi 2, yaitu :
a. Penjualan Kredit
Penjualan kredit dilakukan oleh perusahaan jika order dari pelanggan telah dipenuhi dengan pengiriman barang atau penyerahan jasa, untuk jangka waktu tertentu perusahaan memiliki piutang kepada pelanggannya. Kegiatan penjualan secara kredit ini ditangai oleh perusahaan melalui sistem penjualan kredit.
b. Penjualan Tunai
Dalam transaksi penjualan tunai, barang atau jasa baru diserahkan oleh perusahaan kepada pelanggan apabila perusahaan telah menerima pembayaran tunai dari pelanggan.
2.3.1.1 Fungsi yang terkait dalam penjualan
Menurut Mulyadi (2001, p204), fungsi yang terkait dalam sistem penjualan kredit, antara lain :
a. Fungsi kredit
Dalam transaksi penjualan kredit dengan kartu kredit, fungsi ini bertanggung jawab atas pemberian kartu kredit kepada pelanggan terpilih.
b. Fungsi penjualan
Fungsi penjualan bertanggung jawab melayani kebutuhan barang pelanggan. Fungsi penjualan mengisi faktur penjualan kartu kredit
untuk memungkinkan fungsi gudang dan fungsi pengiriman
melaksanakan penyerahan barang kepada pelanggan.
c. Fungsi gudang
Fungsi gudang menyediakan barang yang diperlukan oleh pelanggan sesuai dengan yang tercantum dalam tembusan faktur penjualan kartu kredit yang diterima dari fungsi penjualan.
d. Fungsi pengiriman
Fungsi pengiriman bertanggung jawab untuk menyerahkan barang yang kuantitas, mutu, dan spesifikasinya sesuai dengan yang tercantum dalam tembusan faktur penjualan kartu kredit yang diterima dari fungsi penjualan. Fungsi ini juga bertanggung jawab untuk memperoleh tanda tangan dari pelanggan di atas faktur penjualan kartu kredit sebagai bukti telah diterimanya barang yag dibeli oleh pelanggan.
e. Fungsi akuntansi
Fungsi akuntansi bertanggung jawab untuk mencatat transaksi bertambahnya piutang kepada pelanggan ke dalam kartu piutang berdasarkan faktur penjualan kartu kredit yang diterima dari fungsi pengiriman. Di samping itu, fungsi akuntansi bertanggung jawab atas pencatatan transaksi penjualan di dalam jurnal penjualan.
f. Fungsi penagihan
Fungsi penagihan bertanggung jawab untuk membuat surat tagihan
2.3.1.2 Jaringan Prosedur yang Membentuk Sistem Penjualan
Jaringan prosedur yang membenuk sistem penjualan dengan kartu kredit adalah :
a. Prosedur order penjualan
Dalam prosedur ini, fungsi penjualan menerima order dari pembeli dan menambahkan informasi penting pada surat order dari pembeli. Fungsi penjualan kemudian membuat faktur penjualan kartu kredit dan mengirimkannya kepada berbagai fungsi yang lain untuk memungkinkan fungsi tersebut memberikan kontribusi dalam melayani order dari pembeli.
b. Prosedur pengiriman barang
Dalam prosedur ini, fungsi gudang menyiapkan barang yang diperlukan oleh pembeli dan gunfsi pengiriman mengirimkan barang kepada pembeli sesuai dengan informasi yang tercantum dalam faktur penjualan kartu kredit yang diterima dari fungsi gudang. Pada saat penyerahan barang, fungsi pengiriman meminta tanda tangan penerimaan barang dari pemegang kartu kredut du atas faktur penjualan kartu kredit.
c. Prosedur pencatatan piutang
Dalam prosedur ini, fungsi akuntansi mencacat tembusan faktur
d. Prosedur penagihan
Dalam prosedur ini, fungsi penagihan menerima faktur penjualan kartu kredit dan mengarsipkannya menurut abjad. Secara periodik fungsi penagihan membuat surat tagihan dan mengirimkannya kepada pemegang kartu kredit perusahaan dilampiri dengan faktur penjualan kartu kredit.
e. Prosedur pencatatan penjualan
Dalam prosedur ini, fungsi akuntansi mencatat transaksi penjualan kartu kredit ke dalam jurnal penjualan.
2.3.1.3 Dokumen pada Sistem Penjualan
Dokumen yang digunakan untuk melaksanakan sistem penjualan kredit, antara lain :
a. Faktur penjualan kartu kredit
Dokumen ini digunakan untuk merekam transaksi penjualan kredit dengan kartu kredit. Lembar ke-1 dan ke-2 berfungsi sebagai dasar pembuatan surat tagihan yang secara periodik dibuat oleh fungsi penagihan dan dikirimkan ke pelanggan. Oleh karena itu, fungsi pengiriman harus mendapatkan tanda tangan di atas faktur penjualan kartu kredit lembar ke-1 dan ke-2 pada saat fungsi tersebut menyerahkan barang kepada pelanggan. Lembar ke-3 berfungsi
sebagai perintah kepada gudang untuk menyiapkan barang yang dibutuhkan oleh pelanggan, dan lembar ke-4 berfungsi sebagai
perintah pengiriman barang kepada fungsi pengiriman. Lembar ke-2 dokumen ini tetap disimpan di dalam arsip fungsi akuntansi, dan lembar ke-1 dilampirkan pada surat tagihan yang dikirimkan secara periodik kepada pelanggan.
b. Surat tagihan
Surat tagihan ini merupakan turnaround document yang isinya dibagi menjadi dua bagian : bagian atas merupakan dokumen yang harus disobek dan dikembalikan bersama cek oleh pelanggan ke perusahaan, sedangkan bagian bawah berisi rincian transaksi pembelian yang dilakukan pelanggan dalam periode tertentu.
2.3.2 Pembelian
Menurut Mulyadi (2001, p299), sistem akuntansi pembelian digunakan dalam perusahaan untuk pengadaan barang yang diperlukan oleh perusahaan. Transaksi pembelian dapat digolongkan menjadi dua : pembelian lokal dan impor. Pembelian lokal adalah pembelian dari pemasok dalam negeri, sedangkan pembelian impor adalah pembelian dari pemasok luar negeri.
2.3.2.1 Fungsi yang Terkait dalam Pembelian
a. Fungsi gudang
Dalam sistem akuntansi pembelian, fungsi gudang bertanggung jawab
untuk mengajukan permintaan pembelian sesuai dengan posisi persediaan yang ada di gudang dan untuk menyimpan barang yang telah diterima oleh fungsi penerimaan. Untuk barang – barang yang langsung dipakai (tidak diselenggarakan persiadaan barang di gudang), permintaan pembelian diajukan oleh pemakai barang.
b. Fungsi pembelian
Fungsi pembelian bertanggung jawab untuk memperoleh informasi mengenai harga barang, menentukan pemasok yang dipilih dalam pengadaan barang dan mengeluarkan order pembelian kepada pemasok yang telah dipilih. Fungsi pembelian membuat perjanjian syarat pembelian dengan pemasok.
c. Fungsi penerimaan
Fungsi penerimaan bertanggung jawab untuk melakukan pemeriksaan terhadap jenis, mutu, dan kuantitas barang yang diterima dari pemasok berdasarkan pesanan pembelian dan faktur pembelian dari pemasok guna menentukan mengnai dapat atau tidaknya barang tersebut diterima oleh perusahaan. Fungsi penerimaan ini juga bertanggung jawab untuk menerima barang dari pemasok yang berasal dari transaksi retur penjualan.
Fungsi akuntansi yang terkait dalam transaksi pembelian adalah fungsi pencatat utang dan fungsi pencatat persediaan. Fungsi pencatat utang bertanggung jawab untuk mencatat transaksi pembelian ke dalam
register bukti kas keluar dan untuk menyelenggarakan arsip dokumen sumber (bukti kas keluar) yang berfungsi sebagai catatan utang atau menyelenggarakan kartu utang sebagai buku pembantu utang. Fungsi pencatat persediaan bertanggung jawab untuk mencatat harga pokok persediaan barang yang dibeli ke dalam kartu persediaan.
2.3.2.2 Jaringan prosedur yang membentuk Sistem Pembelian
Dalam melakukan sistem akuntansi pembelian perlu dilakukan prosedur yang merupakan tahap – tahap proses terjadinya transaksi pembelian. Beberapa prosedur yang membentuk sistem akuntansi pembelian, antara lain :
a. Prosedur permintaan pembelian
Dalam prosedur ini, fungsi gudang mengajukan permintaan pembelian dalam dalam dokumen surat permintaan pembelian kepada fungsi pembelian. Jika barang tidak disimpan di gudang (barang langsung pakai) , fungsi yang memakai barang mengajukan permintaan pembelian langsung ke fungsi pembelian dengan mengajukan surat permintaan pembelian.
Dalam prosedur ini, fungsi pembelian mengirimkan surat permintaan penawaran harga kepada para pemasok untuk memperoleh informasi mengenai harga barang dan berbagai syarat pembelian yang lain, untuk memungkinkan pemilihan pemasok barang yang diperlukan oleh perusahaan. Dari pemasok akan mengirim daftar penawaran harga barang yang dikehendaki.
c. Prosedur order pembelian
Dalam prosedur ini, fungsi pembelian mengirim order pembelian kepada pemasok yang dipilih dan memberitahukan kepada unit – unit organisasi yang lain dalam perusahaan ( contohnya fungsi penerimaan, fungsi yang meminta barang, dan fungsi pencatat utang) mengenai order pembelian yang sudah dikeluarkan oleh perusahaan.
d. Prosedur penerimaan barang
Dalam prosedur ini, fungsi penerimaan barang melakukan pemeriksaan mengenai jenis, kuantitas, dan mutu barang yang diterima dari pemasok dan kemudian membuat laporan penerimaan barang untuk menyatakan penerimaan barang dari pemasok tersebut. Barang yang telah diterima diserahkan ke bagian gudang untuk disimpan.
e. Prosedur pencatatan utang
Dalam prosedur ini, fungsi penerimaan memberi laporan penerimaan barang ke fungsi akuntansi . Fungsi akuntansi juga menerima faktur dari pemasok untuk dicocokan dengan laporan penerimaan barang. Setelah itu fungsi akuntansi akan memeriksa dokumen – dokumen yang berhubungan dengan pembelian dan menyelenggarakan
pencatatan utang atau mengarsipkan dokumen sumber sebagai catatan utang.
2.3.2.3 Dokumen pada sistem pembelian
Dokumen merupakan bukti untuk merekam terjadinya transaksi yang dilakukan oleh perusahaan. Adapun dokumen yang digunakan dalam sistem akuntansi pembelian, antara lain .
a. Surat permintaaan pembelian
Dokumen ini merupakan formulir yang diisi oleh fungsi gudang atau fungsi pemakai barang untuk meminta fungsi pembelian melakukan pembelian barang dagangan dengan jenis , jumlah, dan mutu seperti yang tertera pada surat permintaan pembelian. Surat permintaan pembelian ini biasanya dibuat 2 lembar untuk setiap permintaan, 1 lembar untuk fungsi pembelian, dan tembusannya untuk arsip yang meminta barang.
b. Surat permintaan penawaran harga
Dokumen ini digunakan untuk meminta penawaran harga bagi barang yang pengadaannya tidak bersifat berulang kali terjadi, yang menyangkut jumlah rupiah pembelian yang besar.
c. Surat order pembelian
Dokumen ini digunakan untuk memesan barang kepada pemasok yang telah dipilih.
