6
BAB 2 LANDASAN TEORI
2.1
Data dan Informasi
2.1.1
Pengertian Data dan Informasi Menurut Elmasri dan Navathe (1994, p2), data merupakan fakta-fakta yang telah diketahui untuk dapat disimpan dan yang mempunyai arti yang mutlak atau selengkapnya. Pengertian data, informasi, dan sistem informasi menurut Turban E. et al (2003, p15), data adalah fakta-fakta yang belum diolah atau gambaran-gambaran lebih lanjut dari benda-benda, kejadian-kejadian, kegiatan-kegiatan, dan transaksi-transaksi yang ditangkap, direkam, disimpan dan diklasifikasikan, tetapi tidak disusun untuk menyampaikan arti khusus lainnya. Informasi adalah sebuah kumpulan dari fakta-fakta (data) yang disusun di dalam beberapa cara, jadi kumpulan fakta tersebut bisa berarti bagi penerimanya. Sistem Informasi adalah sebuah sistem yang mengumpulkan, mengolah, menyimpan, menganalisa, dan menyebarkan informasi untuk sebuah tujuan tertentu.
2.1.2
Karakteristik Informasi Dalam lingkup suatu sistem informasi, informasi mempunyai beberapa karakteristik. Menurut Romney dan Steinbart (2000, p13), karakteristik informasi yang berguna adalah sebagai berikut:
7 1. Relevan Informasi
dikatakan
relevan
apabila
informasi
itu
mengurangi
ketidakpastian, meningkatkan kemampuan pembuat keputusan untuk membuat prediksi, atau konfirmasi, atau membenarkan dugaan mereka sebelumnya. 2. Dapat dipercaya Informasi dapat dipercaya jika informasi tersebut bebas dari kesalahan dan secara akurat mewakili events atau aktivitas dari organisasi. 3. Lengkap Informasi yang lengkap yaitu informasi yang tidak mengurangi aspek penting dari event atau aktivitas yang mendasari pengukuran informasi tersebut. 4. Tepat waktu Informasi dikatakan tepat waktu apabila informasi itu tersedia tepat waktu sehingga memungkinkan pembuat keputusan untuk membuat keputusan. 5. Dapat dimengerti Informasi dapat dimengerti jika informasi tersebut dipresentasikan dalam format yang benar dan mudah dipahami. 6. Dapat diuji Informasi dapat diuji jika ada dua orang yang mempunyai pengalaman bekerja secara terpisah, tapi masing – masing menghasilkan informasi yang sama.
8 2.2
Basis Data Menurut Connolly dan Begg (2002, p14), basis data merupakan kumpulan hubungan yang masuk akal dari data atau deskripsi data yang dapat digunakan bersama dan dibuat untuk memperoleh informasi yang dibutuhkan oleh perusahaan. Secara logika, hubungan antar data terdiri dari entitas-entitas, atribut, dan relationship dari informasi organisasi atau perusahaan. Pengertian basis data menurut Date (1990, p10), adalah suatu koleksi atau kumpulan data yang persisten digunakan oleh sistem aplikasi dari suatu perusahaan. Yang dimaksud dengan persisten adalah data yang berbeda satu dengan yang lainnya dan biasanya merupakan data yang bersifat sementara. Sedangkan pengertian basis data menurut Jogiyanto (1990, p13), basis data merupakan kumpulan dari data yang saling berhubungan satu dengan yang lainnya, tersimpan di perangkat keras komputer dan digunakan perangkat lunak untuk memanipulasinya. Dalam praktek, penggunaan istilah basis data menurut Elmasri dan Navathe (1994, p2), lebih dibatasi pada arti implisit yang khusus, yaitu: 1. Basis data merupakan penyajian suatu aspek dari dunia nyata. 2. Basis data merupakan kumpulan data dari berbagai sumber yang secara logika mempunyai arti implisit. Sehingga data yang terkumpul secara acak dan tanpa mempunyai arti, tidak dapat disebut basis data. 3. Basis data perlu dirancang, dibangun, dan data dikumpulkan untuk suatu tujuan. Basis data dapat digunakan oleh beberapa pemakai dan beberapa aplikasi yang sesuai dengan kepentingan pemakai.
9 Dari batasan tersebut, dapat dikatakan bahwa basis data mempunyai berbagai sumber data dalam pengumpulan data bervariasi derajat interaksi kejadian dari dunia nyata, dirancang dan dibangun agar dapat digunakan oleh beberapa pemakai untuk berbagai kepentingan. Menurut Connolly dan Begg (2002, p16), DBMS (Database Management System) adalah sistem software yang memungkinkan atau mengijinkan pengguna untuk mendefinisikan, membuat, memelihara basis data, dan menyediakan akses kontrol kepada basis data. Sedangkan menurut Elmasri dan Navathe (1994, p2), sebuah DBMS merupakan sebuah kumpulan dari program-program yang memungkinkan atau mengijinkan pengguna untuk menciptakan dan memelihara sebuah basis data. Oleh sebab itu, suatu DBMS adalah sebuah sistem generalpurpose software (software bertujuan umum) yang memudahkan proses-proses penentuan, pembangunan, dan pelaksanaan manipulasi data pada banyak basis data untuk berbagai macam aplikasi. Menurut Connolly dan Begg (2002, p18), komponen-komponen dari DBMS: 1. Data Data pada sebuah sistem basis data baik itu sistem single-user maupun sistem multi-user harus terintegrasi (terhubung) dan dapat digunakan bersama. 2. Hardware Terdiri dari:
10 a. Penyimpanan permanen (magnetic disk atau hard disk), perangkat I/O (contohnya : disk drives), Device Controller, I/O Channels, dan lainnya. b. Hardware processor dan main memory, digunakan untuk mendukung saat eksekusi sistem software basis data. 3. Software DBMS, sistem operasi (seperti Microsoft Windows atau Linux), network software (jika diperlukan) dan program aplikasi pendukung lainnya. 4. Users a. Application Programmers, bertanggung jawab untuk membuat aplikasi basis data dengan menggunakan bahasa pemrograman yang ada, seperti: C++, Java, dan lainnya. b. End Users, siapapun yang berinteraksi dengan sistem secara online melalui workstation atau terminal. c. DA (Data Administrator), seseorang yang berwenang untuk membuat keputusan stategis dan kebijakan mengenai data yang ada, DBA (Database
Administrator),
menyediakan
dukungan
teknis
untuk
implementasi keputusan tersebut, dan bertanggungjawab atas keseluruhan kontrol sistem pada tingkatan teknis.
Keuntungan DBMS menurut Connolly dan Begg (2002, p25): 1. Penggunaan data bersama (sharing of data) 2. Mengurangi kerangkapan data
11 3. Menghindari ketidakkonsistenan data 4. Integritas data terpelihara 5. Keamanan terjamin 6. Penyimpanan data dalam jumlah yang besar 7. Penetapan standarisasi 8. Meningkatkan produktivitas 9. Layanan Back up dan Recovery semakin baik
Kerugian DBMS menurut Connolly dan Begg (2002, p29): 1. Rumit Karena penetapan fungsi dari DBMS yang baik, menyebabkan DBMS menjadi software yang cukup rumit. Seluruh user harus mengetahui fungsifungsi yang ada dengan baik, sehingga dapat memperoleh manfaatnya. 2. Ukuran Kerumitan dan banyaknya fungsi yang ada menyebabkan DBMS memerlukan banyak software pendukung yang mengakibatkan penambahan tempat penyimpanan dan memori. 3. Biaya DBMS 4. Biaya tambahan hardware 5. Biaya konversi
12 6. Penampilan (performance) Pada dasarnya DBMS dibuat untuk menyediakan banyak aplikasi, akibatnya mungkin beberapa aplikasi akan berjalan tidak seperti biasanya. 7. Dampak yang tinggi dari kegagalan Karena sistem yang terpusat, jika seluruh pengguna dan aplikasi terakses dari DBMS maka kerusakan pada bagian manapun dari sistem, akan menyebabkan operasi terhenti.
2.3
Perkembangan Basis Data Pada awalnya, perusahaan-perusahaan yang ada masih menggunakan sistem operasional secara manual, yaitu semua proses penyimpanan barang, transaksi-transaksi pembelian, penjualan, dan lain-lain masih dicatat secara langsung dan untuk data penyimpanan barang masih ditempatkan pada sistem pembukuan saja. Namun pada saat sekarang ini, semua proses-proses tersebut sudah dilakukan menggunakan sistem komputerisasi, seperti sistem basis data untuk menyimpan data-data, aplikasi-aplikasi yang dibuat dan terhubung dengan basis data untuk melakukan transaksi-transkasi yang dilakukan suatu perusahaan, dan lain sebagainya. Basis data pada saat sekarang ini sudah merupakan suatu bagian penting bagi perusahaan untuk memenuhi kebutuhan penyimpanan data. Basis data juga sudah mengalami beberapa perkembangan yang sangat penting dengan menggunakan aplikasi-aplikasi yang dibuat dari masing-masing perusahaan. Aplikasi basis data adalah program sederhana yang berinteraksi dengan basis
13 data pada nilai tertentu dalam eksekusinya. Kita juga menggunakan istilah sistem basis data untuk memasukkan koleksi dari program-program aplikasi yang berinteraksi dengan basis data.
2.4
Entity-Relationship Menurut Connolly dan Begg (2002, p330), salah satu bagian yang sulit dalam perancangan basis data adalah suatu fakta bahwa para perancang, pembuat-pembuat program, dan end-user cenderung untuk melihat data dan menggunakannya dengan cara-cara yang berbeda. Kecuali kalau kita memperleh sebuah pemahaman sama yang mencerminkan bagaimana suatu perusahaan beroperasi, suatu perancangan yang kita hasilkan akan gagal untuk memenuhi kebutuhan-kebutuhan user. Untuk meyakinkan bahwa kita mendapat sebuah pemahaman yang tepat dari suatu data dan bagaimana data tersebut digunakan oleh suatu perusahaan, kita harus mempunyai sebuah model untuk membuat komunikasi yang non teknikal dan tidak bersifat ambigu. Entity-Relationship (ER) adalah salah satu contohnya. Pemodelan ER adalah sebuah pendekatan top-down untuk perancangan basis data yang dimulai dengan mengidentifikasi suatu data penting yang disebut entitas-entitas dan relationships diantara suatu data yang harus direpresentasikan dalam suatu model. Lalu kita menambah perincian-perincian lagi seperti suatu informasi yang ingin kita ambil tentang suatu entitas-entitas dan relationships yang disebut atribut-atribut dan batasan-batasan yang lain pada suatu entitasentitas, relationships, dan atribut-atribut.
14 Berikut ini adalah notasi Entity-Relationship Modelling menurut Connolly dan Begg (2002, p333-335):
Entity Name
A
B Relate to
Relationship Name Gambar 2.1 Notasi Entity-Relationship Modelling
Pengertian Multiplicity menurut Connolly dan Begg (2002, p350) adalah sejumlah kemungkinan kejadian-kejadian dari sebuah tipe entitas di dalam sebuah hubungan n-nary ketika nilai-nilai yang lain (n-1) ditentukan. Multiplicity biasanya terdiri dari dua batasan terpisah, yaitu: a. Cardinality:
Mendeskripsikan
jumlah
maksimum
dari
kemungkinan
kejadian-kejadian yang saling berhubungan untuk sebuah partisipasi entitas dalam proses penentuan tipe relationship. b. Participation: Menentukan apakah semua kejadian-kejadian entitas akan ikut berpartisipasi dalam sebuah relationship atau hanya beberapa saja yang ikut berpartisipasi.
15 Jenis-jenis multiplicity menurut Connolly dan Begg (2002, p345) adalah: 1. One-to-One (1 : 1) Relationships Group 1
Relate to
Group 2
A•
r1 • • r2
•C
B•
•D
Gambar 2.2 One-to-One Relationships Pada gambar 2.2, kita bisa melihat bahwa A hanya terhubung One-to-One (1 : 1) dengan C, dan B hanya terhubung One-to-One (1 : 1) dengan D. Jadi dari gambar tersebut kita dapat menulis notasi multiplicity-nya dengan gambar di bawah ini. Relate to
Group 1 1..1
Group 2 1..1
Multiplicity Gambar 2.3 Notasi One-to-One Relationships
16 2. One-to-Many (1 : *) Relationships Group 1
Relate to
Group 2
A•
r1 • r2 • r3 •
•D
B• C•
•E •F
Gambar 2.4 One-to-Many Relationships Pada gambar 2.4, kita bisa melihat bahwa B terhubung One-to-Many (1 : *) dengan D dan E. Jadi dari gambar tersebut kita dapat menulis notasi multiplicity-nya dengan gambar di bawah ini. Relate to
Group 1 1..1
Group 2 0..*
Multiplicity Gambar 2.5 Notasi One-to-Many Relationships
17 3. Many-to-Many (* : *)Relationships Group 1
A• B• C•
Relate to
Group 2
r1 • r2 • r3 • r4 •
•D •E •F •G
Gambar 2.6 Many-to-Many Relationships
Pada gambar 2.6, kita bisa melihat bahwa A terhubung One-to-Many (1 : *) dengan D dan E. Sedangkan E terhubung One-to-Many (1 : *) dengan A dan B. Jadi dari 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 kita dapat menulis notasi multiplicity-nya dengan gambar di bawah ini. Relate to
Group 1 0..*
Group 2 1..*
Multiplicity Gambar 2.7 Notasi Many-to-Many Relationships
18 2.5
Daur Hidup Database (Database Lifecycle) Menurut Connolly dan Begg (2002, p271), sistem basis data adalah komponen penting dari suatu sistem informasi sebuah perusahaan atau organisasi yang besar. Aplikasi daur hidup basis data adalah pengumpulan pewarisan dengan daur hidup dari sistem informasi. Sebagai contoh, masalah yang dihadapi selama perancangan basis data mengharuskan penambahan koleksi dan analisis kebutuhan. Untuk aplikasi basis data yang kecil, dengan jumlah pengguna yang sedikit, tidak dibutuhkan daur hidup yang kompleks. Bagaimanapun, saat merancang aplikasi basis data menengah sampai yang besar dengan sepuluh sampai seribu pengguna, menggunakan ratusan dari query dan aplikasi program, daur hidup dapat menjadi kompleks sekali. Berikut ini adalah gambar tahapan-tahapan aplikasi daur hidup basis data menurut Connolly dan Begg (2002, p272):
19
Database planning
System definition
Requirements collection and analysis Database design
Conceptual database design DBMS selection (optional)
Application design Logical database design Physical database design
Prototyping (optional)
Implementation
Data conversion and loading Testing
Operational maintenance Gambar 2.8 Tahapan Aplikasi Daur Hidup Basis Data
20 Menurut Connolly dan Begg (2002, p273), berikut ini adalah tahapantahapan dari aplikasi daur hidup basis data beserta aktivitas-aktivitas utama yang dilakukan oleh setiap tahapnya:
2.5.1
Database Planning Merencanakan bagaimana tahapan-tahapan daur hidup basis data dapat direalisasikan dengan efisien dan efektif. Tahap perencanaan basis data juga harus menjelaskan : •
Mission statement dari proyek basis data. Mission statement ini menjelaskan tujuan utama aplikasi basis data, juga membantu menjelaskan tujuan proyek basis data, dan menyediakan maksud yang lebih jelas dalam pembuatan aplikasi basis data secara efektif dan efisien (Connolly, 2002, p274). Dengan merumuskan apa sebenarnya yang menjadi tujuan dari proyek basis data ini diharapkan dapat lebih memfokuskan pekerjaan pada tahap selanjutnya.
•
Mission objectives. Selain merumuskan tujuan dari sebuah proyek basis data, harus diperhatikan juga mengenai tugas apa saja yang harus didukung oleh basis data tersebut. Setiap mission objective akan menjelaskan tugas tertentu yang harus didukung oleh basis data, dengan asumsi jika basis data mendukung mission objectives, maka mission statementnya juga akan sesuai (Connolly, 2002, p274).
21 2.5.2
System Definition Menspesifikasikan jangkauan dan batasan-batasan dari aplikasi basis data, pengguna basis data, dan area-area aplikasi. Pandangan pengguna (user view) sangat diperlukan untuk mengidentifikasi informasi-informasi yang dibutuhkan oleh user. Pandangan pengguna menggambarkan apa yang dibutuhkan oleh aplikasi basis data dari sudut pandang jabatan tertentu, seperti manajer atau pengawas, maupun dari sudut pandang area aplikasi perusahaan, seperti pemasaran, personalia, atau pengawasan persediaan, dalam hubungannya dengan data yang akan disimpan dan transaksi yang akan dijalankan terhadap data itu (Connolly, 2002, p275).
2.5.3
Requirements Collection and Analysis Mengkoleksi dan menganalisis kebutuhan pengguna dan area-area aplikasi. Dalam menganalisi kebutuhan digunakan teknik yang disebut fact finding techniques. Terdapat lima teknik fact finding yang umum digunakan (Connolly, 2002, p305) : 1. Mengevaluasi dokumen 2. Interview 3. Mengobservasi jalannya kegiatan kerja pada perusahaan 4. Research riil 5. Quesioner
22 2.5.4
Database Design Menurut Connolly dan Begg (2002, p279), Database design (perancangan basis data) adalah proses pembuatan sebuah perancangan untuk suatu basis data yang akan mendukung operasi dan tujuan suatu perusahaan. Proses perancangan basis data menurut Connolly dan Begg (2002, p419), terdiri dari tiga tahap utama, yang pertama yaitu, perancangan konseptual basis data adalah proses untuk membuat sebuah model informasi yang digunakan dalam suatu perusahaan, serta bebas dari semua pertimbangan fisik. Yang kedua yaitu, perancangan logikal basis data adalah proses untuk membuat sebuah model informasi yang digunakan dalam suatu perusahaan, berdasarkan suatu data model spesifik, namun bebas dari DBMS tertentu dan pertimbangan fisik lainnya. Dan yang ketiga yaitu, perancangan fisikal basis data
adalah
proses
untuk
menghasilkan
sebuah
gambaran
dari
pengimplementasian basis data pada secondary storage, menggambarkan hubungan dasarnya, pengaturan file, pengindeksan yang digunakan untuk memenuhi akses data yang efisien, batasan integritas terkait lainnya, dan pengukuran keamanan. Berikut ini merupakan langkah-langkah metodologi dari perancangan basis data, menurut Connolly dan Begg (2002, p420):
2.5.4.1
Perancangan Konseptual Basis Data Merupakan
proses
membangun
model
informasi
yang
digunakan organisasi, bebas dari semua pertimbangan fisik (Connolly, 2002, p419). Pertimbangan fisik yang dimaksud meliputi DBMS yang akan digunakan, program aplikasi, bahasa pemrograman, platform
23 perangkat keras, unjuk kerja, dan pertimbangan fisik lainnya. Fungsi dari tahap ini adalah untuk membuat representasi konseptual dari basis data, termasuk identifikasi entity-entity yang penting, relationship, atribut.
2.5.4.1.1
Membuat Model Data Konseptual Lokal untuk Setiap Bagian Tujuan dari Perancangan Basis Data Konseptual (2002, p419), adalah untuk memproses pembuatan suatu model informasi yang digunakan didalam suatu organisasi dimana model tersebut tidak tergantung pada perangkat keras lainnya. Berikut ini adalah langkah-langkah dalam membuat model data konseptual lokal :
2.5.4.1.1.1
Mengidentifikasi Tipe Entitas Dalam membangun suatu model data konseptual lokal maka perlu mendefinisikan objek utama dimana user memang membutuhkannya. Salah satu metode untuk mengidentifikasi tipe entitas yang utama adalah dengan mengidentifikasi kata benda atau frase kata benda yang telah disebutkan oleh user. Sebagai contoh: no staff, nama staff, no property, alamat property, rumah kontrakan, banyaknya kamar. Anda juga dapat melihat objek seperti orang, tempat, hobby, tidak termasuk kata benda yang mendefinisikan kualitas dari objek lain. Sebagai contoh, Anda dapat mengelompokkan no staff dan nama staff
24 dengan sebuah objek atau entitas yang disebut Staff dan mengelompokkan no property, alamat property, rumah kontrakan, dan banyaknya kamar menjadi suatu entitas yang disebut PropertyForRent.
2.5.4.1.1.2
Mengidentifikasi Tipe Relasi Tujuan
dari
langkah
ini
adalah
untuk
mengidentifikasi relasi yang penting antara berbagai tipe entitas yang telah diidentifikasikan. Biasanya, relasi diidentifikasi dengan menggunakan kata kerja atau frase kata kerja. Sebagai contohnya adalah: •
Staff Manages PropertyForRent.
•
PrivateOwner Owns PropertyForRent.
•
PropertyForRent Associated With Lease. Relasi yang paling umum adalah relasi binary,
artinya relasi antar entitas yang persis antara dua entitas saja. Bagaimanapun, Anda harus memperhatikan relasi yang kompleks yang melibatkan lebih dari dua entitas dan relasi rekursif yang hanya melibatkan satu entitas. Adapun langkah-langkah dalam mengidentifikasi tipe relasi adalah sebagai berikut:
25 •
Gunakan Entity – Relationship (ER) Diagram. Hal yang sering terjadi adalah Anda akan lebih cepat mengerti
suatu
perancangan
basis
data
yang
tervisualisasikan dibandingkan dengan perancangan basis data yang dituliskan dalam bentuk tekstual. Anda dapat menggunakan Entity-Relationship (ER) Diagram untuk mempresentasikan entitas dan bagaimana relasi antar entitas. Anda disarankan menggunakan EntityRelationship (ER) Diagram untuk membantu Anda membuat gambaran besar dari perancangan basis data yang sedang Anda kembangkan. •
Tentukan pembatas multiplicity dari tipe relasi. Setelah Anda mempunyai relasi antara entitas maka langkah berikutnya adalah Anda dapat menentukan multiplicity setiap relasi. Jika memang ada suatu nilai yang spesifik dari suatu multiplicity maka akan lebih baik apabila didokumentasikan.
•
Memeriksa Fan dan Chasm Traps. Setelah Anda mendefinisikan relasi yang dibutuhkan antar entitas maka langkah berikutnya adalah Anda dapat memeriksa fan dan chasm traps.
•
Memeriksa setiap entitas yang mempunyai relasi minimal satu.
26 Pada saat Anda membuat Entity Relationship (ER) Diagram, pastikan bahwa setiap entitas mempunyai minimal satu relasi dengan entitas yang lain. Jika memang ada entitas yang sudah mempunyai minimal satu relasi dengan entitas yang lain maka langkah berikutnya adalah perhatikan kamus datanya. Apabila memang sudah mempunyai relasi semua, maka berarti Anda telah membuat setiap entitas mempunyai relasi.
2.5.4.1.1.3
Mengidentifikasi dan Mengasosiasikan Atribut Suatu Entitas atau Tipe Relasi Tujuan
dari
langkah
ini
adalah
untuk
mengidentifikasi dan mengasosiasikan atribut dari entitas atau tipe relasi. •
Simple / Composite Attributes Perlu diperhatikan apakah suatu atribut tersebut itu simple atau composite.
•
Single / Multi-valued Attributes Diperhatikan apakah atribut mempunyai satu atau lebih nilai.
•
Derived Attributes Diperhatikan atribut yang nilainya tergantung dengan nilai atribut yang lain
27 2.5.4.1.1.4
Menentukan Domain Atribut Tujuan dari langkah ini adalah untuk menentukan domain dari atribut yang ada didalam model data konseptual lokal. Sebagai contoh antara lain: •
Atribut dari No Staff terdiri dari sembilan karakter tipe string dimana satu karakter utama merupakan huruf, sedangkan delapan karakter sisanya berupa angka.
•
Nilai yang mungkin untuk atribut jenis kelamin adalah ‘L’ atau ‘P’. Ini merupakan domain dari atribut yang menggunakan karakter tunggal.
2.5.4.1.1.5
Menentukan Candidate Key dan Primary Key Tujuan
dari
langkah
ini
adalah
untuk
mengidentifikasi kandidat key dari setiap tipe entitas. Jika terdapat lebih dari satu candidate key, pilihlah salah satunya untuk menjadi primary key. Pada saat Anda memilih suatu primary key di antara banyak candidate key, gunakan petunjuk berikut ini untuk membantu menyeleksi: •
Merupakan candidate key dengan jumlah set paling sedikit.
•
Merupakan candidate key yang nilainya jarang sekali berubah.
28 •
Merupakan candidate key dengan jumlah karakter paling sedikit.
•
Merupakan candidate key dengan jumlah paling sedikit dari nilai maksimumnya (untuk tipe atribut dengan tipe numerik).
•
Merupakan
candidate
key
yang
paling
mudah
digunakan dari sudut pandang pengguna. Beberapa jenis keys yang biasa digunakan, menurut Connolly dan Begg (2002, p340), antara lain: 1. Candidate key candidate key yaitu himpunan atribut minimal yang secara unik mengidentifikasikan tiap-tiap keberadaan suatu tipe entitas. 2. Primary key Primary key yaitu candidate key yang dipilih secara unik untuk mengidentifikasikan tiap-tiap keberadaan suatu tipe entitas. 3. Foreign key Foreign key yaitu himpunan atribut dalam suatu relasi yang cocok dengan candidate key dari beberapa relasi. 4. Alternate key Alternate key yaitu candidate key yang tidak terpilih menjadi primary key.
29 2.5.4.1.1.6
Menggunakan Enhanced Modeling Concepts (langkah optional) Tujuan
dari
mempertimbangkan
langkah penggunaan
seperti
concepts,
ini
adalah
enhanced
specialization,
untuk
modeling
generalization,
aggregation, dan composition. Specialization
merupakan
suatu
proses
memaksimalkan perbedaan-perbedaan antara anggotaanggota sebuah entitas dengan cara mengidentifikasi karakteristik yang membeakan entitas tersebut (Connolly, 2002, p362). Generalization
merupakan
suatu
proses
meminimalkan perbedaan-perbedaan antara entitas-entitas dengan
cara
mengidentifikasi
sifat
umum
entitas
(Connolly, 2002, p363). Aggregation menggambarkan relationship ‘has-a’ atau ‘is-part-of’ antara tipe entitas dimana yang satunya mewakili ‘whole’ (seluruhnya) dan yang satunya lagi mewakili ‘part’ (bagian) (Connolly, 2002, p371). Jika Anda menggunakan pendekatan specialization maka Anda akan memperhatikan perbedaan yang terlihat secara maksimal antara entitas satu atau banyak subclass dari entitas superclasses. Jika Anda menggunakan pendekatan
generalization
maka
Anda
akan
30 mengidentifikasi persamaan antara entitas yang ada untuk membentuk superclass.
2.5.4.1.1.7
Memeriksa Redundansi Tujuan dari langkah ini adalah untuk memeriksa apakah ada redundansi dalam model basis data. Pada langkah ini, Anda akan menguji data model konseptual lokal dengan melihat secara spesifik, apabila ada redundansi maka dapat dihilangkan dengan dua langkah berikut:
2.5.4.1.1.8
•
Menguji kembali hubungan one-to-one.
•
Menghilangkan relasi redundansi.
Validasi Model Konseptual Lokal dengan Transaksi User Bertujuan untuk memastikan local conceptual data model mendukung transaksi yang dibutuhkan oleh pandangan pengguna (Connolly, 2002, p435). Dua pendekatan untuk memastikan local conceptual data model mendukung kebutuhan transaksi.
31 1) Menggambarkan transaksi (describing the transaction) Memeriksa semua informasi (entitas, relationship, dan atributnya) yang dibutuhkan setiap transaksi yang disediakan oleh model (Connolly, 2002, p435). 2) Menggunakan transaction pathways Memvalidasi data model terhadap kebutuhan transaksi dengan menggambar diagram yang mewakili pathway yang diambil oleh setiap transaksi secara langsung pada E-R diagram (Connolly, 2002, p435).
2.5.4.1.1.9
Melihat Kembali Data Model Konseptual Lokal dengan Pengguna Tujuan dari langkah ini adalah untuk melihat kembali model data konseptual lokal bersama user untuk memastikan bahwa model yang ada sudah sesuai dengan yang diminta. Hasil akhir dari perancangan basis data konseptual adalah proses pembuatan suatu model dari informasi yang akan digunakan di dalam suatu organisasi, yang independensinya tidak tergantung dengan apapun.
32 2.5.4.2
Perancangan Logikal Basis Data untuk Model Relasional Merupakan proses dalam membangun suatu model informasi yang digunakan didalam perusahaan, proses tersebut tidak tergantung oleh suatu DBMS dan pertimbangan fisikal tertentu, tetapi berdasarkan pada model data spesifik yang diperlukan. . Dalam logical database design, model data yang telah diperoleh dalam conceptual database design diubah dalam bentuk logical model dimana data yang ada dipengaruhi oleh model data yang menjadi tujuan basis data. (contoh: relational model). Hal ini dilakukan untuk menterjemahkan presentasi konseptual ke dalam bentuk struktur logic dalam basis data. Logical data model merupakan sumber informasi dalam merancang physical database. Logical database design memberikan sarana yang membantu para perancang dalam merancang fisikal database.
2.5.4.2.1
Membuat dan Memvalidasi Model Data Logikal Lokal untuk Setiap Bagian Adapun tujuan dari langkah membuat dan memvalidasi model data logikal lokal untuk setiap bagian adalah untuk membangun suatu model data logikal lokal dari suatu model data konseptual lokal yang merepresentasikan perusahaan kemudian memvalidasi model ini untuk memastikan strukturnya benar, dan memastikan bahwa model tersebut mendukung transaksi yang diminta.
33 2.5.4.2.1.1
Menghilangkan Bagian yang Tidak Sesuai dengan Model Relasi (langkah optional) Tujuan dari langkah ini adalah untuk memperbaiki model data konseptual lokal dengan menghilangkan fitur yang tidak cocok dengan model relasi. Bagian yang akan dibahas pada langkah ini antara lain : 1. Menghilangkan many- to-many (*:*) tipe relasi binary. Dengan memecah relationship yang mengandung many-to-many (*:*) untuk mengidentifikasikan sebuah entitas
tengah
(intermediate
entity)
sehingga
relationship ini digantikan dengan dua buah one-tomany (1:*) relationship, dengan entitas tengah berada di antara dua buah entitas yang lama. 2. Menghilangkan
many-to-many
(*:*)
tipe
relasi
recursive. Jika recursive relationship ada pada conceptual data model, relationship tersebut harus dipecah untuk mengidentifikasikan sebuah entitas tengah dengan cara menganggap entitas yang terlibat pada relationship ini merupakan dua buah entitas dengan jenis relationship many-to-many (*:*) binary sehingga penyelesaiannya sama dengan penyelesaian pada relationship many-tomany (*:*) binary.
34 3. Menghilangkan tipe relasi kompleks. Dihilangkan dengan memecah relationship ini untuk mengidentifikasikan
entitas
tengah
(intermediate
entity). Kemudian complex relationship ini akan digantikan dengan beberapa one-to-many (1:*) binary relationship. 4. Menghilangkan atribut-atribut multi-valued. Cara menghilangkannya adalah dengan memecah atribut ini untuk mengidentifikasikan sebuah entitas.
2.5.4.2.1.2
Membuat Relasi untuk Model Data Logikal Lokal Tujuan dari langkah ini adalah untuk membuat suatu relasi untuk model data logikal lokal yang merepresentasikan suatu entitas, relasinya, dan juga atribut yang telah diidentifikasi. Anda dapat mendeskripsikan bagaimana relasi dapat diturunkan dari struktur model data antara lain: 1. Tipe Entitas Kuat. 2. Tipe Entitas Lemah. 3. One-to-many (1:*) tipe relasi binary. 4. One-to-one (1:1) tipe relasi binary. 5. One-to-one (1:1) tipe relasi recursive. 6. Tipe relasi superclass / subclass. 7. Many-to-many tipe relasi binary.
35 8. Tipe relasi kompleks. 9. Atribut-atribut multi-valued.
2.5.4.2.1.3
Memvalidasi Relasi Menggunakan Normalisasi Menurut Connolly dan Begg (2002, p376), normalisasi adalah sebuah teknik untuk menghasilkan sebuah kumpulan dari relasi-relasi dengan atribut-atribut yang diinginkan, yang berdasarkan kebutuhan-kebutuhan data sebuah perusahaan. Tahapan normalisasi menurut Connolly dan Begg (2002, p386), adalah sebagai berikut: 1. Unnormalized (UNF), sebuah tabel yang berisi satu atau lebih grup yang berulang. Yang dimaksud grup yang
berulang
itu
adalah
atribut-atribut
yang
multivalued. 2. Normalisasi
pertama
(1NF),
menghilangkan
perulangan. Sebuah relasi dimana setiap baris dan kolom hanya berisi satu nilai saja. Bentuk Normal pertama ini, dicapai apabila setiap nilai atribut adalah tunggal.
Kondisi
ini
dapat
diperoleh
dengan
melakukan eliminasi terhadap terjadinya data ganda (repeating groups). Pada kondisi normal pertama ini kemungkinan masih terjadi adanya data rangkap.
36 3. Normalisasi kedua (2NF), bentuk ini mempunyai syarat yaitu data harus memenuhi kriteria 1NF dan setiap data barang yang bukan key harus bergantung secara fungsional pada primary key-nya. Bentuk normal
kedua
adalah
berdasarkan
konsep
ketergantungan fungsional penuh (full functional dependency). Full functional dependency dinyatakan jika A dan B adalah atribut dari suatu relasi, B adalah fungsional ketergantungan penuh (fully functional dependency) pada A jika B adalah secara fungsional bergantung pada A, tetapi bukan merupakan himpunan bagian dari A. Bentuk normal kedua menciptakan sebuah relasi pada bentuk normal pertama dan semua atribut yang bukan primary key adalah fungsional tergantung penuh pada primary key. 4. Normalisasi ketiga (3NF), sebuah relasi dalam bentuk normal pertama dan kedua serta setiap atribut bukan key yang bergantung secara transitif kepada bukan key juga. Bentuk normal ketiga adalah berdasarkan pada konsep
peralihan
ketergantungan
(transitive
dependency). Transitive dependency adalah sebuah kondisi dimana A, B, dan C adalah atribut dari sebuah relasi bahwa jika A p B dan B p C, maka C adalah transitive dependent pada A melewati B (menyatakan
37 bahwa A bukan functional dependent pada B atau C). Pada bentuk normal ketiga, sebuah relasi pada bentuk normal pertama dan kedua serta dimana tidak ada atribut non-primary key secara transitif bergantung (transitively dependent) pada primary key. 5. Normalisasi Boyce-Codd (Boyce-Codd Normal Form / BCNF), suatu relasi dinyatakan BCNF, jika dan hanya jika setiap determinannya adalah sebuah candidate key. Untuk menguji apakah suatu relasi sudah dalam BCNF, dilakukan identifikasi semua determinan dan memastikan bahwa determinan tersebut
adalah
candidate key. Determinan adalah sebuah atribut, atau kumpulan atribut, dimana beberapa atribut yang lain masih bergantung secara fungsional penuh (fully functionally dependent). Perbedaan antara 3NF dan BCNF dalam hal functional dependency. A p B, 3NF mengijinkan ketergantungan ini dalam sebuah relasi jika B adalah atribut primary key dan A bukan candidate
key.
Sedangkan
dalam
BCNF
ketergantungan ini tetap ada di dalam sebuah relasi, dimana A harus sebuah candidate key. 6. Normalisasi keempat (4NF), sebuah relasi dalam BCNF dan tidak mengandung ketergantungan multivalued
nontrivial
(nontrivial
multi-valued
38 dependencies). Bentuk normal keempat merupakan bentuk yang lebih kuat dari BCNF dimana 4NF mencegah
relasi
dari
nontrivial
multi-valued
dependency dan data redundancy. Normalisasi dari BCNF ke 4NF meliputi pemindahan multi-valued dependency dari relasi dengan menempatkan atribut dalam sebuah relasi baru bersama dengan determinan. Multi-valued
dependency
menggambarkan
ketergantungan antara atribut-atribut dalam suatu relasi. 7. Normalisasi kelima (5NF), sebuah relasi yang tidak mempunyai
ketergantungan
dependency).
Join
dependency
gabungan
(join
menggambarkan
sebuah tipe ketergantungan. Sebagai contoh, untuk sebuah relasi R dengan subset-subset atribut dari R yang dimisalkan dengan A, B, ..., Z , sebuah relasi R menunjukkan join dependency, jika dan hanya jika, setiap nilai dari R sama dengan gabungan dari proyeksi-proyeksinya pada A, B, ..., Z. Adapun anomali atau penyimpangan di dalam melakukan perubahan terhadap data yang ada pada suatu tabel. Ada 3 anomali atau penyimpangan menurut Connolly dan Begg (2002, p377), yaitu:
39 1. Insertion Anomalies a. Penyimpangan
yang
terjadi
ketika
ingin
memasukkan suatu data baru yang bersifat foreign key maka harus memasukkan detil dari data tersebut secara berulang apabila ada data yang
sama.
Tujuannya
untuk
mencegah
terjadinya ketidakkonsistenan data. b. Penyimpangan
yang
terjadi
ketika
ingin
memasukkan suatu data baru yang bersifat foreign key, tetapi primary key dari data tersebut belum bisa dimasukkan karena alasan tertentu. Ini melanggar aturan dari integrity constraints, yaitu entity integrity (dalam sebuah relasi, atribut primary key tidak boleh bersifat null) 2. Deletion Anomalies Penyimpangan
yang
terjadi
apabila
ingin
menghapus suatu data di mana data tersebut merupakan foreign key dari tabel gabungan dan tidak ada duplikasi dari foreign key tersebut, maka detil dari foreign key tersebut akan bebar-benar hilang dari basis data.
40 3. Modification Anomalies Penyimpangan
yang
terjadi
apabila
ingin
mengubah suatu detil data foreign key pada tabel gabungan maka harus mengubah detil data foreign key pada setiap baris lainnya sesuai dengan data foreign key yang diubah.
2.5.4.2.1.4
Memvalidasi Relasi dengan Transaksi User Tujuan dari langkah ini adalah untuk memastikan bahwa relasi didalam model data logikal lokal mendukung transaksi yang diminta user . Pada langkah ini, Anda akan memeriksa
bahwa
relasi
yang
dibuat
di
langkah
sebelumnya juga mendukung transaksi ini, dan juga pastikan bahwa tidak ada kesalahan dalam relasi yang telah dibuat.
2.5.4.2.1.5
Memeriksa Integritas Basis Data Tujuan mendefinisikan
dari ruang
langkah lingkup
ini
adalah
untuk
integritas
yang
diperlihatkan kepada user. Dalam hal ini ada lima tipe dari ruang lingkup integritas, antara lain :
41 1. Data yang diminta. Beberapa atribut harus selalu berisi nilai yang benar (valid), tidak dapat bernilai null. Constraint ini harus diidentifikasikan
pada
saat
mendokumentasikan
atribut-atribut pada kamus data (langkah 1.3). 2. Domain pembatas atribut. Setiap atribut memiliki domain, yaitu himpunan nilai yang dibolehkan (Connolly, 2002, p457). Constraint ini harus diidentifikasikan pada saat pemilihan attribute domain untuk data model (langkah 1.4). 3. Integritas entitas. Primary key dari sebuah entitas tidak boleh bernilai null. Constraint ini harus dipertimbangkan pada saat penentuan primary key bagi setiap tipe entitas (langkah 1.5). 4. Integritas referensi. Jika suatu foreign key memiliki nilai, maka nilai tersebut harus menunjuk ke sebuah baris yang ada pada relasi ‘parent’. 5. Pembatas Enterprise. Kegiatan update entitas dibatasi oleh peraturan atau kebijakan organisasi yang mengatur transaksi yang diwakilkan oleh update yang dilakukan.
42 2.5.4.2.1.6
Melihat Kembali Model Data Lokal dengan User Tujuan dari langkah ini adalah untuk memastikan model data logikal lokal dan membuat dokumentasi yang mendeskripsikan model tersebut sebagai representasi yang sesuai dengan keadaan sebenarnya.
2.5.4.2.2
Membangun dan Memvalidasi Model Data Logikal Global Tujuan dari langkah ini adalah untuk mengkombinasikan suatu model data logikal lokal individual ke dalam suatu model data logikal global yang menggambarkan suatu perusahaan.
2.5.4.2.2.1
Menggabungkan Model Data Logikal Lokal Menjadi Model Global Tujuan
dari
langkah
ini
adalah
untuk
menggabungkan suatu model data logikal lokal ke dalam suatu model data logikal global dari suatu perusahaan. Beberapa tugas dari pendekatan ini adalah sebagai berikut: 1. Memeriksa ulang nama dan isi dari suatu entitas / relasi dan candidate key. 2. Memeriksa ulang nama dan isi dari relasi / foreign key. 3. Menggabungkan entitas / relasi dari model data lokal. 4. Memasukkan (tanpa penggabungan) entitas / relasi unik pada setiap model data lokal.
43 5. Menggabungkan relasi / foreign key dari model data lokal. 6. Memasukkan (tanpa penggabungan) relasi / foreign key unik pada setiap model data lokal. 7. Memeriksa untuk entitas, relasi, foreign key yang hilang. 8. Memeriksa foreign key. 9. Memeriksa batasan integritas. 10. Menggambar diagram Entity-Relationship global. 11. Update dokumentasi.
2.5.4.2.2.2
Memvalidasi Model Data Logikal Global Tujuan dari langkah ini adalah untuk memvalidasi relasi yang dibuat dari model data logikal global dengan menggunakan
teknik
dari
normalisasi
dan
juga
memastikan bahwa relasi yang dibuat mendukung transaksi.
2.5.4.2.2.3
Memeriksa Kemungkinan Adanya Pengembangan Dimasa Mendatang Tujuan dari langkah ini adalah untuk menentukan bagian mana yang kelihatannya akan berubah ke masa depannya dan juga memperhatikan supaya model data logikal global dapat mengakomodasi perubahan tersebut.
44 2.5.4.2.2.4
Melihat Kembali Model Data Logikal Global dengan User Tujuan dari langkah ini adalah untuk memastikan bahwa
model
data
logikal
global
itu
memang
merepresentasikan perusahaan yang ada. Hasil akhir dari perancangan basis data logikal adalah merancang suatu model informasi berdasarkan spesifik model yang ada (seperti model relasional), tetapi tidak tergantung terhadap suatu DBMS dan perangkat keras lainnya.
2.5.4.3.2.5
Hubungan Antara Logikal Data Model dan Data Flow Diagram Suatu Logical Data Model merefleksikan struktur dari penyimpanan data dalam suatu perusahaan. Sebuah Data Flow Diagram (DFD) menunjukkan aliran data suatu perusahaan dan disimpan didalam penyimpanan data. Semua atribut seharusnya berada didalam suatu tipe entitas. Jika mereka memang ditangani di dalam perusahaan, kemungkinan akan dilihat mengalir di sekitar perusahaan sebagai aliran data. Ada aturan yang mengontrol antara dua teknik tersebut, antara lain : •
Setiap penyimpanan seharusnya merepresentasikan suatu tipe entitas.
45 •
Atribut dalam aliran data seharusnya merupakan bagian dari tipe entitas.
2.5.4.3
Perancangan Fisikal Basis Data untuk Basis Data Relasional Proses memproduksi sebuah deskripsi dari implementasi basis data dalam secondary storage, yang menjelaskan relasi dasar, organisasi file, dan indeks yang digunakan untuk mencapai akses yang efisien ke data, dan setiap integrity constraint yang saling berhubungan dan juga pengukuran keamanan (security). Pada tahapan ini memungkinkan perancang database untuk membuat keputusan mengenai bagaimana database akan diimplementasikan. Oleh karena itu, Physical database design harus disesuaikan.
2.5.4.3.1
Menterjemahkan Model Data Logikal Global untuk DBMS yang Digunakan Tujuan dari langkah ini adalah untuk membuat suatu skema basis data relasional dari model data logika global yang dapat diimplementasikan ke DBMS yang dipakai.
2.5.4.3.1.1
Merancang Basis Relasional Tujuan dari langkah ini adalah untuk memutuskan bagaimana merepresentasikan relasional dasar yang diidentifikasi dalam model data logikal global pada DBMS yang dipakai. Untuk memulai proses perancangan basis
46 data fisik, pertama-tama Anda dapat mengumpulkan dan mengasimilasikan suatu informasi tentang relasional yang dirancang
selama
perancangan
basis
data
logikal.
Informasi yang diperlukan bisa berasal dari kamus data dan
definisi
dari
relasional
yang
didefinisikan
menggunakan Database Design Language (DBDL). Untuk setiap relasional yang diidentifikasi pada model data logikal global, kita dapat mendefinisikan salah satu sebagai berikut: •
Nama dari relasi yang ada.
•
Suatu daftar untuk atribut yang sederhana.
•
Primary key, alternatif key, dan foreign key.
•
Suatu daftar dari atribut turunan dan bagaimana mereka dihasilkan.
•
Batasan integrasi untuk setiap foreign key yang diidentifikasi.
Dari kamus data dari setiap atributnya dapat diketahui: •
Domain atribut tersebut yang terdiri dari tipe data, panjang dan berbagai keterangan atribut tersebut.
•
Suatu nilai default optional untuk atribut.
•
Apakah atribut bisa diisi nilai NULL.
47 2.5.4.3.1.2
Merancang Representasi Data Turunan Tujuan dari langkah ini adalah untuk memutuskan bagaimana merepresentasikan suatu data turunan pada model data logikal global pada DBMS yang dipakai. Atribut yang nilainya didapatkan dengan mengevaluasi atribut lain dikenal sebagai atribut turunan atau kalkulasi. Sebagai contoh:
2.5.4.3.1.3
•
Jumlah staff yang bekerja di kantor cabang tertentu.
•
Total gaji bulanan yang dibayarkan ke seluruh staff.
•
Jumlah property yang ditangani oleh seorang staff.
Merancang Batasan Aplikasi Tujuan dari langkah ini adalah untuk merancang batasan aplikasi untuk DBMS yang dipakai. Perancangan batasan tersebut sekali lagi tergantung dari DBMS yang digunakan,
fasilitas
yang
dipunyai
oleh
sistem
dibandingkan dengan DBMS yang lain. Pada awalnya, jika sistem tersebut mempunyai aturan sesuai aturan standard SQL, beberapa batasan dapat diterapkan.
2.5.4.3.2
Merancang Representasi Fisikal Tujuan dari langkah ini adalah untuk menentukan organisasi file yang paling optimal untuk menyimpan relasional
48 dasar dan indeks yang diminta untuk performansi yang optimal yang mana relasi dan data yang ada disimpan dalam penyimpanan sekunder. Ada tiga faktor untuk mengukur efisiensi penyimpanan data yaitu: •
Transaction throughput: jumlah transaksi yang dapat diproses pada rentang waktu yang diberikan (Connolly, 2002, p484).
•
Response Time: waktu yang diperlukan untuk menyelesaikan sebuah transaksi (Connolly, 2002, p484).
•
Disk
storage:
besarnya
ukuran
penyimpanan
untuk
menyimpan basis data (Connolly, 2002, p484).
2.5.4.3.2.1
Menganalisis Transaksi Tujuan dari langkah ini adalah untuk mengerti fungsi dari suatu transaksi yang mana yang akan dijalankan pada basis data dan untuk menganalisis transaksi yang penting. Untuk membuat perancangan basis data fisikal efektif maka perlu mempunyai pengetahuan mengenai transaksi atau query yang akan dijalankan didalam basis data. Ini termasuk informasi yang kuantitatif dan kualitatif. Dalam menganalisa transaksi, Anda dapat mengidentifikasi performansi sebagai berikut:
49 •
Transaksi yang sering digunakan dan akan berdampak besar terhadap performansi.
•
Transaksi yang merupakan transaksi bisnis kritis.
•
Peak load yaitu durasi waktu dalam harian atau mingguan yang akan mendapatkan banyak permintaan pada basis data (Connolly, 2002, p486).
2.5.4.3.2.2
Memilih Organisasi File Tujuan dari langkah ini adalah untuk menentukan organisasi file yang efektif untuk setiap relasi dasar. Dalam banyak kasus yang ada, suatu DBMS yang relasional akan memberikan sedikit bahkan tanpa pilihan dalam memilih organisasi file, walaupun beberapa akan mempunyai indeks yang spesifik. Bagaimanapun, berikut ini beberapa organisasi file yang ada adalah sebagai berikut: •
Heap.
•
Hash.
•
Indexed Sequential Access Method (ISAM).
•
B+-tree.
•
Clusters.
50 2.5.4.3.2.3
Memilih Indeks Tujuan dari langkah ini adalah untuk menentukan penambahan indeks yang akan meningkatkan performansi dari suatu sistem. Biasanya pemilihan atribut untuk pengindeksan adalah sebagai berikut: •
Suatu atribut yang digunakan paling sering untuk operasi
penggabungan,
yang
akan
membuat
penggabungan tersebut lebih efektif •
Suatu atribut yang digunakan paling banyak untuk mengakses suatu record di dalam relasi yang ada.
Ada tiga jenis indeks yaitu: •
Primary index Pengindeksan dilakukan pada kolom kunci (key field), yang diurutkan terlebih dahulu secara sekuensial.
•
Clustering index Pengindeksan dilakukan pada kolom bukan kunci (non-key field), yang sudah diurutkan terlebih dahulu secara sekuensial. Kolom bukan kunci itu disebut juga dengan clustering attribute (Connolly, 2002, p1155).
51 •
Secondary index Pengindeksan yang dilakukan pada kolom yang tidak terurut di dalam file data (Connolly, 2002, p1155).
2.5.4.3.2.4
Mengestimasi Kapasitas Disk yang Dibutuhkan Tujuan dari langkah ini adalah untuk mengestimasi ukuran kapasitas disk yang diperlukan untuk basis data.
2.5.4.3.3
Merancang Tampilan Layar untuk User Tujuan dari langkah ini adalah untuk merancang tampilan layar untuk user yang diidentifikasi selama pengumpulan informasi dan analisis dari siklus hidup aplikasi basis data.
2.5.4.3.4
Merancang Ukuran Keamanan Tujuan dari langkah ini adalah untuk merancang ukuran keamanan untuk basis data yang telah dispesifikasi oleh user. Hasil akhir dari perancangan fisik basis data adalah suatu proses yang mendeskripsikan suatu implementasi dari suatu basis data pada penyimpanan sekunder. Ini mendeskripsikan suatu relasi dasar dan struktur penyimpanan dan metodologi pengaksesan yang efisien selama batasan integritas dan ukuran keamanan.
52 2.5.4.3.5
Mempertimbangkan Pengenalan Pengontrolan Redundancy Untuk menentukan apakah pengenalan pengontrolan redundancy dengan mengendurkan aturan normalisasi akan meningkatkan unjuk kerja sistem.
2.5.4.3.6
Memantau Operasional Sistem Bertujuan untuk memantau operasional sistem dan meningkatkan unjuk kerja sistem untuk memperbaiki keputusan desain yang tidak sesuai atau menggambarkan kebutuhankebutuhan
2.5.5
Pemilihan DBMS(optional) Menentukan DBMS mana yang dapat digunakan sesuai dengan aplikasi yang ditentukan. Ini dilakukan setelah dilakukannya perancangan konseptual. Karena suatu organisasi memerlukan perluasan atau perubahan pada sistem yang sedang berjalan, maka akan menjadi hal yang perlu untuk mengevaluasi produk-produk DBMS yang baru. Tujuannya untuk memilih sebuah sistem yang sesuai dengan kebutuhan perusahaan saat ini maupun di masa yang akan datang, yang seimbang dengan biaya-biaya yang dikeluarkan termasuk dalam pembelian produk DBMS, perangkat lunak maupun perangkat keras tambahan yang dibutuhkan untuk mendukung sistem basis data, dan biaya-biaya lain yang berhubungan dengan perubahan dan pelatihan pegawai. Tahapan utama dalam memilih DBMS antara lain:
53 1) Mendefinisikan syarat-syarat sebagai referensi Dibuat dengan menyatakan tujuan dan ruang lingkup pembelajaran, tugas-tugas yang akan dikerjakan, penjelasan kriteria (berdasarkan spesifikasi kebutuhan pengguna) yang akan digunakan dalam mengevaluasi produk-produk DBMS, daftar produk-produk yang dimungkinkan,
semua
batasan-batasan
dan
skala
waktu
yang
dibutuhkan untuk pembelajaran.
2) Daftar singkat dua atau tiga produk Kriteria yang dianggap penting dalam keberhasilan implementasi dapat digunakan untuk membuat daftar produk-produk DBMS dalam evaluasi, seperti dana yang tersedia, tingkat dukungan vendor, kecocokan dengan perangkat lunak lainnya, dan apakah produk hanya berjalan pada perangkat keras tertentu.
3) Evaluasi produk Fitur-fitur yang digunakan dalam evaluasi produk-produk DBMS dikelompokkan menjadi definisi data, definisi fisik, kemampuan akses, penanganan lainnya.
keperluan-keperluan,
pengembangan,
dan
fitur-fitur
54 4) Merekomendasikan pilihan dan memproduksi laporan Langkah terakhir dari pemilihan DBMS adalah mendokumentasikan prosesnya dan membuat pernyataan dalam penemuan dan rekomendasi atas produk DBMS tertentu.
2.5.6
Application Design Langkah ini melakukan perancangan layar atau tampilan untuk user. Dalam merancang user interface dan program aplikasi, langkah ini menggunakan proses basis data yang mengacu pada petunjuk perancangan user interface seperti pemilihan judul, penulisan instruksi-instruksi menggunakan format yang standard sehingga mudah dipahami, pemakaian warna yang konsisten, dan sebagainya. Desain aplikasi dibagi menjadi dua aspek, yaitu :
•
Desain transaksi Transaksi diartikan sebagai sebuah atau serangkaian aksi, yang dilakukan oleh seorang user atau program aplikasi, yang mengakses atau mengubah isi dari basis data (Connoly and Begg, 2002, p551). Terdapat tiga tipe utama transaksi : -
Retrieval Transaction, contohnya tampilan detil data properti (data ditampilkan dalam bentuk angka).
-
Update Transaction, contohnya operasi untuk memasukkan detil data properti baru ke dalam basis data.
55 -
Mixed Transaction, contohnya operasi untuk mencari detil data properti, menampilkannya dan kemudian mengupdate nilainya.
•
2.5.7
Panduan Desain Antarmuka Pengguna
Prototyping (optional) Pada langkah ini kita mengizinkan perancang dan user untuk memvisualisasikan dan mengevaluasi gambaran sistem secara menyeluruh. Seperti yang kita ketahui, tujuan utama dalam mengembangkan suatu aplikasi basis data prototype adalah untuk mengizinkan para pemakai menggunakan prototype, sehingga pemakai dapat mengidentifikasi fitur sistem, apakah sistem sudah bekerja dengan baik atau belum. Jika memungkinkan, pemakai dapat memberikan saran untuk mengadakan perbaikan atau bahkan menambahkan fitur baru dalam aplikasi basis data tersebut.
Keuntungan
prototype
adalah
relatif
murah
dan
proses
pembuatannya yang cepat.
2.5.8
Implementation Implementasi adalah sebuah langkah dimana mengrealisasikan fisikal dari database dan desain aplikasi. Setelah menyelesaikan langkah desain maka dilakukan implementasi database dan aplikasi dari program yang dibuat. Untuk melakukan implementasi database maka digunakan Data Definition Language (DDL).
56 2.5.9
Data Conversion and Loading Memindahkan data dari sistem yang lama ke sistem yang baru. Langkah ini dibutuhkan hanya pada waktu sistem basis data yang lama digantikan dengan sistem basis data yang baru (Connolly, 2002, p293).. Suatu DBMS mempunyai kegunaan memasukkan file ke dalam basis data yang baru, kemudian secara otomatis mengubah data tersebut ke dalam format yang diperlukan oleh file basis data yang baru. Jika dapat diterapkan, pengembang dapat mengubah dan menggunakan program aplikasi dari sistem yang lama untuk digunakan oleh sistem yang baru.
2.5.10
Testing Aplikasi basis data yang telah dibuat maka akan dilakukan pengecekan untuk mencari error yang tedapat pada aplikasi yang dibuat. Dalam melakukan testing, tidak hanya pembuat program tetapi pengguna juga ikut serta dalam melakukan testing tersebut.
2.5.11
Operational Maintenance Aplikasi basis data diimplementasikan secara penuh. Sistem tersebut ditinjau dan dirawat secara terus menerus. Saat dibutuhkan, maka permintaan-permintaan baru akan dimasukkan ke dalam aplikasi basis data melalui tahap-tahap daur hidup sebelumnya.
57 2.6
Data Definition Language (DDL) Menurut Martina (2003, p58), DDL merupakan bagian dari sistem manajemen basis data, dipakai untuk mendefinisikan dan mengatur semua atribut dan properti dari sebuah basis data. DDL digunakan untuk mendefinisikan basis data, tabel, dan view. Berikut ini adalah beberapa pernyataan yang termasuk dalam DDL, yaitu: 1. Create Table Digunakan untuk membuat tabel dengan mengidentifikasikan tipe data untuk tiap kolom. 2. Alter Table Digunakan untuk menambah dan menghapus kolom dan konstrain. 3. Drop Table Menghapus tabel beserta semua data yang terkait di dalamnya. 4. Create Index Digunakan untuk membuat indeks pada suatu tabel. 5. Drop Index Digunakan untuk menghapus indeks yang sudah dibuat sebelumnya.
2.7
Data Manipulation Language (DML) Menurut Martina (2003, p60), DML digunakan untuk menampilkan, menambah, mengubah, dan menghapus data dalam objek-objek yang didefinisikan oleh DDL. Berikut ini adalah beberapa pernyataan yang termasuk dalam DML, yaitu:
58 1. Select Digunakan untuk menampilkan sebagian atau seluruh isi dari suatu tabel dan menampilkan kombinasi isi dari beberapa tabel. 2. Update Digunakan untuk mengubah isi satu atau beberapa atribut dari suatu tabel. 3. Insert Digunakan untuk menambah satu atau beberapa baris nilai baru ke dalam suatu tabel. 4. Delete Digunakan untuk menghapus sebagian atau seluruh isi dari tabel.
2.8
State Transition Diagram STD Menurut Hoffer. J. A. et al (1996, p364), State Transition Diagram adalah suatu diagram yang menggambarkan bagaimana suatu proses dihubungkan satu sama lain dalam waktu yang bersamaan. State Transition Diagram digambarkan dengan sebuah state yang berupa komponen sistem yang menunjukan bagaimana kejadian-kejadian tersebut dari satu state ke state lain. Ada dua macam simbol yang menggambarkan proses dalam State Transition Diagram (STD), yaitu: 1. Gambar persegi panjang menunjukan state dari sistem
Mewakili State dalam STD
59 2. Gambar panah menunjukan transisi antar state. Tiap panah diberi label dengan ekspresi aturan. Label yang di atas menunjukan kejadian atau kondisi yang menyebabkan transisi yang terjadi. Label yang dibawah menunjukan aksi yang terjadi akibat dari kejadian tadi. Mewakili Transisi dalam STD
2.9
Pengertian Rekrutmen, Absensi, Mutasi, Promosi, PHK, Cuti 2.9.1
Rekrutmen Menurut Randall dan Susan (1997,p227), rekrutmen antara lain meliputi upaya pencarian sejumlah calon karyawan yang memenuhi syarat dalam jumlah tertentu sehingga dari mereka perusahaan dapat menyeleksi orang-orang yang paling tepat untuk mengisi lowongan pekerjaan yang ada Bagian dari rekrutmen : -
Menentukan kebutuhan jangka pendek dan jangka panjang perusahaan dalam hal jenis pekerjaan dan levelnya dalam perusahaan.
-
Terus berupaya mendapatkan informasi mengenai perkembangan kondisi pasar tenaga kerja
-
Menyusun bahan-bahan rekrutmen yang sistematis dan terpadu yang berhubungan dengan kegiatan sumber daya manusia lain
-
Mendapatkan pool calon karyawan yang berbobot atau memenuhi syarat
-
Mencatat jumlah dan kualitas pelamar dari berbagai sumber dan masingmasing metode rekrutmennya
-
Melakukan tindak lanjut terhadap para calon karyawan baik yang diterima maupun yang ditolak guna mengevaluasi efektif tidaknya
60 rekrutmen yang dilakukan. Semua kegiatan ini harus dilakukan sesuai konteks hukum yang berlaku.
Tujuan umum rekrutmen adalah menyediakan suatu pool calon karyawan yang memenuhi syarat bagi perusahaan. Sedangkan tujuan spesifiknya adalah : -
Agar konsisten dengan strategi, wawasan dan nilai perusahaan
-
Untuk menentukan kebutuhan rekrutmen perusahaan di masa sekarang dan masa datang berkaitan dengan perubahan besar dalam perusahaan, perencanaan SDM, pekerjaan disain dan analisa jabatan.
-
Untuk meningkatkan pool calon karyawan yang memenuhi syarat seefisien mungkin
-
Untuk mendukung inisiatif perusahaan dalam mengelola tenaga kerja yang beragam
-
Untuk membantu meningkatkan kerberhasilan proses seleksi dengan mengurangi calon karyawan yang sudah jelas tidak memenuhi syarat atau yang terlalu tinggi kualifikasinya
-
Untuk membantu mengurangi kemungkinan keluarnya karyawan yang belum lama bekerja
-
Untuk mengkoordinasikan upaya rekrutmen dengan program seleksi dan pelatihan
-
Untuk mengevaluasi efektif tidaknya berbagai teknik dan lokasi rekrutmen bagi semua jenis pelamar kerja
61 -
Untuk memenuhi tanggung jawab perusahaan terhadap program-program tindakan alternatif dan pertimbangan hukum dan sosial lain menurut komposisi tenaga kerja
2.9.2
Absensi Menurut Jean dan Mary (1985,p14), banyak perusahaan khawatir melihat angka absen yang tinggi. Dalam hal ini harus diadakan catatan sederhana, berapa catatan perorangan. Ini akan menunjukkan luasnya persoalan, alasan-alasannya (misalnya sakit tanpa keterangan), pengaruhnya pada bagian atau pada kategori karyawan (misalnya golongan wanita yang sudah menikah) Menurut Bennet (1983,p104) masalah yang cukup merugikan perusahaan adalah kemangkiran baik yang sah (dengan alasan) maupun yang tidak sah (tanpa alasan atau dengan alasan yang dibuat-buat seperti tetangga meninggal dunia, izin dokter yang dipaksakan, dan sebagainya). Dalam tulisan ini seluruh jenis kemangkiran akan dianggap sebagai satu kesatuan masalh. Angka kemangkiran dapat diperoleh dengan menggunakan rumus :
A.K =
Jumlah kemangkiran setiap bulan Jumlah hari hadir + jumlah hari mangkir
Angka
kemangkiran
yang
tinggi
perlu
diteliti
sebab-musababnya.
Kebanyakan kemangkiran disebabkan perasaan yang jenuh. Karyawan yang bersangkutan merasa bahwa kehidupannya setiap hari dipenuhi dengan tugas
62 dan tanggung jawab yang semakin berat sehingga kemangkiran tidak dapat dielakkan lagi.
2.9.3
Mutasi Menurut Alex (1996,p71), kata mutasi sudah dikenal sebagian masyarakat, baik dalam lingkungan perusahaan maupun di luar lingkungan perusahaan. Mutasi atau pemindahan adalah kegiatan memundahkan karyawan dari suatu pekerjaan ke pekerjaan lain yang dianggap setingkat atau sejajar. Suatu mutasi yang tidak dapat meningkatkan efektivitas dan efisiensi tidak akan mempunyai arti, bahkan mungkin justru akan merugikan perusahaan. Untuk itu, mutasi harus didasarkan pada pertimbangan yang matang. Mutasi dapat didasarkan pada beberapa alasan, antara lain: kemampuan kerja, rasa tanggung jawab, kesenangan, dan sebagainya. Agar mutasi yang kita laksanakan dapat meningkatkan efektivitas dan efisiensi, perlu adanya evaluasi terus-menerus secara objektif terhadap setiap pekerja.
2.9.4
Promosi Menurut Alex (1996,p71), promosi adalah proses pemindahan karyawan dari satu jabatan ke jabatan lain yang lebih tinggi. Dengan demikian, promosi akan selalu diikuti oleh tugas, tanggung jawab, dan wewenang yang tinggi daripada jabatan yang diduduki sebelumnya. Pada umumnya promosi juga diikuti dengan peningkatan income serta fasilitas yang lain. Namun, promosi itu sendiri sebenarnya mempunyai nilai karena merupakan bukti pengakuan, antara lain terhadap prestasinya. Promosi
63 mempunyai arti yang penting bagi perusahaan sebab dengan promosi berarti kestabilan perusahaan dan moral karyawan akan lebih terjamin.
2.9.5
PHK Menurut Marwan dan Awig Dwi (1986,p195-201), dalam mengelola suatu perusahaan tidak bisa lepas dari masalah-masalah yang ada kaitannya dengan ketenagakerjaan. Setiap manager personalia sangat perlu mempelajari dan memahami seluk beluk ketenagakerjaan dengan segala masalahnya, termasuk masalah pemutusan hubungan kerja. PHK merupakan suatu masalah yang kurang menyenangkan bagi pihak buruh maupun majikan serta pemerintah. Namu demikian pada keadaan tertentu terpaksa dilakukan demi kepentingan bersama. Menurut pengertiannya, PHK adalah berakhirnya suatu hubungan kerja antara buruh dan pengusaha. Yang disebabkan karena salah satu pihak tidak dapat memenuhi kewajibannya atau karena berakhirnya suatu perjanjian kerja antara buruh dan pengusaha. Pemutusan hubungan kerja secara hukum dibenarkan dengan syara tidak menyimpang dari ketentuan perundang-undangan yang ada dan masih berlaku (UU perburuhan Nomor 12 tahun 1964).
Mencegah terjadinya PHK -
Meningkatkan hubungan industrial pancasila
-
Meningkatkan keterampilan atau pendidikan karyawan, sehingga dapat menghasilkan tenaga-tenaga yang terampil
64 -
Pengusaha sendiri harus meningkatkan mutu management dalam perusahaannya
-
Perlu dibentuk Organisasi Buruh (FBSI) dalam suatu perusahaan
-
Bantuan pemerintah dalam membina hidup berindustri sangatlah dibutuhkan
2.9.6
Cuti Menurut Sondang (1997,p163), setiap pekerja berhak cuti dalam setiap tahun kerja. Biasanya hak cuti itu adalah selama dua belas hari kerja. Dalam kurun waktu tersebut pegawai yang bersangkutan mendapat gaji penuh dan waktu cuti itu diperhitungkan sebagai bagian masa aktif untuk perhitungan pensiun kelak. Merupakan hal yang sangat wajar apabila para pegawai baru mengetahui haknya mengenai hal ini. Bahkan mereka ingin mendalami berbagai hal mengenai cuti yang menjadi haknya itu, seperti apakah “hangus” kalau tidak diambil ataukah dapat “ditabung” dan sebagainya. Khusus pegawai wanita yang baru bekerja dan sudah menikah, perlu mengetahui ketentuan tentang cuti tertentu yang hanya berlaku bagi pekerja wanita seperti cuti hamil dan cuti melahirkan, misalnya yang menyangkut jangka waktunya, untuk berapa kali hamil dan melahirkan dan sebagainya. Pembatasan cuti hamil dan cuti melahirkan dewasa ini sering diberlakukan karena gencarnya program keluarga berencana diselenggarakan di banyak negara dan yang harus didukung oleh setiap organisasi.
65 2.10
Bagan Alir (Flow Chart) Berikut ini adalah simbol-simbol standar dengan maknanya masingmasing : Simbol
Nama Dokumen
Keterangan Menggambarkan semua jenis dokumen, yang merupakan formulir yang digunakan untuk merekam data terjadinya suatu transaksi.
Dokumen dan
Menggambarkan dokumen asli dan
tembusannya
tembusannya. Nomor lembar dokumen dicantumkan di sudut kanan atas.
Berbagai
Menggambarkan berbagai jenis
dokumen
dokumen yang digabungkan bersama didalam suatu paket. Nama dokumen dituliskan didalam masing-masing simbol dan nomor lembar dokumen dicantumkan di sudut kanan atas simbol dokumen yang bersangkutan.
Catatan
Menggambarkan catatan akuntansi yang digunakan untuk mencatat data yang direkam sebelumnya
66 didalam dokumen atau formulir.
Penghubung
Karena keterbatasan ruang hal
pada halaman
kertas untuk menggambar, maka
yang sama (on-
diperlukan simbol penghubung
page
untuk memungkinkan aliran
connector)
dokumen tertentu di suatu lokasi pada halaman tertentu dan kembali berjalan di lokasi lain pada halaman yang sama. Dengan memperlihatkan nomor yang tercantum didalam simbol penghubung pada halaman yang sama, dapat dikatakan aliran dokumen dalam sistem yang digambarkan dalam bagan alir.
Penghubung
Menunjukkan ke mana dan
pada halaman
bagaimana bagan alir terkait satu
yang berbeda
dengan lainnya. Nomor yang
(off-page
tercantum dalam simbol
connector)
penghubung menunjukkan bagaimana bagan alir yang tercantum pada hal tertentu terkait dengan bagan alir yang tercantum pada hal yang lain.
67 Kegiatan
Uraian singkat kegiaan manual
manual
dicantumkan didalam simbol ini.
proses
Digunakan untuk mewakili sebuah proses
Arsip
Menunjukkan tempat penyimpanan
sementara
dokumen. Terdapat dua tipe arsip dokumen : arsip sementara dan arsip permanent. Arsip sementara adalah tempat penyimpanan dokumen yang dokumennya akan diambil kembali di arsip tersebut di masa yang akan datang untuk keperluan pengolahan lebih lanjut terhadap dokumen tersebut untuk pengurutan pengarsipan dokumen digunakan simbol berikut ini: A = menurut abjad. N = menurut nomor urut. T = kronologis, menurut tanggal
Arsip permanen
Menggambarkan arsip permanen yang merupakan tempat penyimpanan dokumen yang tidak akan diproses lagi dalam sistem
68 yang bersangkutan.
Mulai/ berakhir
Menggambarkan awal dan akhir
(terminal)
suatu sistem.
Keputusan
Menggambarkan keputusan yang harus dibuat dalam proses pengolahan data. Keputusan yang dibuat ditulis dalam bentuk simbol.
Tabel 2.1 Simbol dan penjelasan Bagan Alir (Flow Chart)
