BAB 2 LANDASAN TEORI
2.1
Teori-teori Umum 2.1.1
Data Data adalah komponen yang paling penting dalam DBMS. Data bertindak
sebagai jembatan yang menghubungkan komponen mesin dengan komponen manusia (Connolly, Begg, 2005, p20). Data merupakan fakta mentah tentang orang, tempat, kejadian, dan sesuatu yang penting dalam organisasi (Whitten, 2004, p27). Data juga dapat didefinisikan sebagai penyaluran representasi objek dan kejadian yang memiliki arti dan penting dalam lingkungan user (Hoffer, Prescott, 2005, p5). Selain itu data juga dapat diartikan sebagai fakta mengenai objek orang, dan lain-lain. Data dinyatakan dengan nilai (angka, deretan karakter atau simbol) (Kadir, 2000, p7). Jadi, dapat disimpulkan bahwa data adalah fakta mengenai objek, orang, tempat, serta kejadian yang bertindak sebagai jembatan yang menghubungkan komponen mesin dengan komponen manusia.
2.1.2
Sistem Sistem adalah sekumpulan objek atau elemen yang saling berhubungan
yang dilihat secara keseluruhan dan didesain untuk mencapai tujuan tertentu (Britton, Doake, 2001, p2). 8
9
Sistem adalah sekelompok elemen yang terintegrasi dengan maksud yang sama untuk mencapai suatu tujuan (McLeod, 2001, p11). Jadi, dapat disimpulkan bahwa sistem adalah sekumpulan objek atau elemen yang saling berhubungan untuk mencapai tujuan tertentu.
2.1.3
Basis data Basis data atau database adalah sekumpulan relasi data logika, dan
deskripsi dari data tersebut dirancang untuk memenuhi kebutuhan informasi organisasi (Connolly, Begg, 2005, p15). Basis data juga merupakan kumpulan terintegrasi dari elemen data yang secara logika saling berhubungan (James A. O’Brien, 2005, p211). Basis data adalah kumpulan file yang saling terkait (Whitten, 2004, p548). Selain itu basis data adalah kumpulan data yang terorganisir, relasi antar data, dan objektifnya (Fathansyah, 2004, p7). Jadi, dapat disimpulkan bahwa basis data berisi kumpulan data yang saling berhubungan yang mendeskripsikan berbagai entitas dan hubungan antarentitas yang dirancang untuk memenuhi kebutuhan informasi organisasi.
2.1.4
Sistem Basis Data Sistem basis data adalah sekumpulan aplikasi program yang berinteraksi
dengan basis data (Connolly, Begg, 2005, p4). Sistem basis data pada dasarnya adalah sistem terkomputerasi yang tujuan utamanya adalah memelihara
10
informasi dan membuat informasi tersebut tersedia saat dibutuhkan (Kadir, 2000, p9).
2.1.5
Entity-Relationship ( ER ) Modelling Entity Relationship Modelling adalah sebuah pendekatan top-down dalam
perancangan basis data yang dimulai dari mengidentifikasikan data – data yang penting, yang disebut entiti (entity) dan hubungan (relationship) diantara data datanya tersebut harus ditampilkan di dalam model (Connolly, Begg, 2005, p342). Lalu tambahkan detail – detail lainnya, seperti informasi yang ingin kita ketahui tentang entity dan relationship, yang disebut dengan attribut, dan batasan – batasan (Constraints) pada entity, relationship, dan attribute. Entity Relationship Model adalah suatu teknik dasar terpenting dalam mendesain suatu basis data. Berikut ini adalah simbol-simbol E-R Modeling :
11
Gambar 2.1 Simbol-Simbol ER-Modeling
2.1.5.1 Entity Entity merupakan objek (manusia, tempat, benda, konsep ataupun kejadian) didalam organisasi yang akan diwakilkan dalam basis data (Connolly, Begg, 2005, p15). Konsep dasar dari Entity Relationship (ER) Model adalah Entity yang menggambarkan kumpulan dari ‘objek’ didalam ‘dunia nyata’ dengan properti yang sama.
Gambar 2.2 Representasi diagram dari tipe entitas Pegawai
12
2.1.5.2 Relationship Type Relationship type adalah sekumpulan dari hubungan antar tipe yang memiliki arti/makna diantara satu atau lebih entiti (Connolly, Begg, 2005, p346). Sedangkan relationship occurrence adalah sebuah hubungan yang dapat diidentifikasi secara unik, yang meliputi sebuah kejadian dari setiap entitas didalam relasi (Connolly, Begg, 2005, p346). Setiap relationship type diberi nama sesuai dengan fungsinya masing-masing. Contoh relationship type dapat dilihat pada Gambar 2.3.
‘Pegawai menginput barang’ Gambar 2.3 Contoh Relationship Type
2.1.5.2.1 Derajat Dari Relationship Derajat dari Relationship dihitung dari banyaknya entity yang berpartisipasi dalam suatu relationship. Relasi dengan hanya satu atribut berarti mempunyai satu derajat, dan akan disebut unary relation atau satu tuple, relasi dengan dua atribut disebut binary, relasi dengan tiga atribut disebut ternary, demikian selanjutnya digunakan n-ary untuk penamaannya (Connolly, Begg, 2005, p347).
13
2.1.5.2.2 Recursive Relationship Recursive Relationship merupakan tipe relasi dimana entity yang sama berpartisipasi lebih dari satu dengan peranan yang berbeda. Relationship dapat diberikan role names untuk mengindikasikan tujuan dari peranan setiap entity didalam relationship, role names sangat penting dalam recursive relationship untuk menegaskan fungsi dari setiap entity yang berpartisipasi (Connolly, Begg, 2005, p349).
2.1.5.3 Atribut Atribut adalah properti sebuah entitas atas relationship (Connolly, Begg, 2005, p350). Selain itu ,Atribut juga merupakan properti deskriptif atau karakteristik dari sebuah entitas. Atribut menampung nilai yang menjelaskan setiap entity occurrence dan menggambarkan bagian utama dari data yang disimpan di dalam basis data (Whitten, 2004, p295).
Gambar 2.4 Entity dengan Atribut
14
2.1.5.3.1 Simple Attribute dan Composite Attribute Simple Attribute adalah sebuah atribut yang terdiri dari satu komponen tunggal dengan keberadaannya sendiri sehingga tidak dapat dipecah menjadi komponen-komponen yang lebih kecil lagi, sering juga disebut dengan atomic attribute (Connolly, Begg, 2005, p351). Composite Attribute adalah sebuah atribut yang dibentuk dari banyak komponen (Connolly, Begg, 2002, p351).
2.1.5.3.2 Single-Valued Attribute dan Multi-Valued Attribute Single-Valued Attribute adalah sebuah atribut yang memegang sebuah nilai tunggal untuk setiap occurrence dari sebuah entity. Kebanyakan dari atribut adalah single-valued (Connolly, 2005, Begg, p351). Multi-Valued Attribute adalah sebuah atribut yang memegang banyak nilai untuk setiap kejadian dari sebuah entity (Connolly, Begg, 2005, p352).
2.1.5.3.3 Derived Attribute Merupakan atribut yang diturunkan dari nilai atribut yang berhubungan atau kumpulan atribut, tidak harus dari entity yang sama (Connolly, Begg, 2005, p352).
2.1.5.3.4 Keys Candidate key adalah himpunan atribut yang minimal yang secara unik
15
mengidentifikasikan setiap occurrence dari sebuah tipe entitas (Connolly, Begg, 2005, p352). Composite key adalah sebuah candidate key yang terdiri atas dua atau lebih atribut (Connolly, Begg, 2005, p353). Primary key adalah candidate key yang terpilih untuk mengidentifikasikan secara unik setiap occurrence dari sebuah tipe entitas (Connolly, Begg, 2005, p353). Pada sebuah tipe entitas biasanya terdapat lebih dari satu candidate key yang salah satunya harus dipilih untuk menjadi primary key. Pemilihan primary key didasarkan pada panjang atribut, jumlah minimal atribut yang diperlukan, dan keunikannya. Alternate key adalah setiap candidate key yang tidak terpilih menjadi primary key, atau biasa disebut dengan secondary key (Whitten, 2004, p298. Foreign key adalah sebuah primary key pada sebuah entitas yang digunakan pada entitas lainnya untuk mengidentifikasikan sebuah relationship (Whitten, 2004, p301).
2.1.5.4 Batasan Struktural ( Structural Constaints ) Batasan-batasan yang menggambarkan pembatasan pada relationship seperti yang ada pada ‘real world’ harus diterapkan pada tipe entitas yang ikut serta pada sebuah relationship. Jenis utama dari batasan pada suatu relationship dinamakan multiplicity (Connolly, Begg, 2005, p356). Multiplicity adalah jumlah occurrence yang mungkin terjadi pada sebuah tipe entitas yang berhubungan ke sebuah occurrence dari tipe entitas lain pada suatu relationship (Connolly, Begg, 2005, p356).
16
Derajat yang biasanya digunakan pada suatu relationship adalah binary relationship, yang terdiri atas: 2.1.5.4.1 One-to-One (1:1) Relationship Setiap Partner berarti mempunyai paling sedikit satu document dan paling banyak satu document, dan satu Document dapat dimiliki paling sedikit oleh satu Partner atau paling banyak oleh satu Partner (Connolly, Begg, 2005, p357).
Gambar 2.5 One-To-One Relationship
2.1.5.4.2 One-to-Many (1:*) Relationship Setiap User mendaftarkan banyak Kontrak atau tidak ada sama sekali, dan setiap Kontrak didaftarkan oleh satu dan hanya satu orang User (Connolly, Begg, 2005, p358).
17
Gambar 2.6 One-To-Many Relationship
2.1.5.4.3 Many-to-Many (*:*) Relationship Setiap Kontrak memiliki paling tidak satu atau banyak Aircraft, dan setiap Aircraft dimiliki paling sedikit satu atau banyak Kontrak (Connolly, Begg, 2005, p360).
Gambar 2.7 Many-To-Many Relationship
2.1.6
Database Application Lifecycle Untuk merancang aplikasi sistem basis data diperlukan tahapan-tahapan
terstruktur yang harus diikuti yang dinamakan dengan Daur Hidup Aplikasi Basis Data (Database Application Lifecycle) atau disingkat DBLC. Penting untuk diingat bahwa tahapan pada DBLC tidak selalu berurutan, tetapi meliputi
18
sejumlah perulangan dari tahapan sebelumnya melalui “feed back loops”. Berikut ini adalah tahapan pada DBLC :
Gambar 2.8 Database Application Lifecycle (Connolly, Begg, 2005, p284)
19
2.1.6.1 Perencanaan Basis Data Perencanaan basis data adalah kegiatan pengaturan yang memungkinkan tahap-tahap dalam database application lifecycle dapat diwujudkan secara efisien dan secara efektif mungkin (Connolly, Begg, 2005, p285). Tahap perencanaan basis data juga harus menjelaskan : • Mission statement merupakan sasaran utama sistem basis data. Mission statement ini menjelaskan tujuan sistem basis data dan menyediakan maksud yang lebih jelas dalam pembuatan aplikasi basis data secara efektif dan efisien (Connolly, Begg, 2005, p286). • 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, Begg, 2005, p286).
2.1.6.2 Definisi Sistem Definisi sistem menjelaskan batasan dan ruang lingkup aplikasi basis data dan user view yang utama (Connolly, Begg, 2005, p286). User View mendefinisikan apa yang diperlukan dalam aplikasi basis data dari sudut pandang peran pekerjaan (seperti manajer atau supervisor) atau area aplikasi enterprise (Connolly, Begg, 2005, p287).
20
2.1.6.3 Pengumpulan Kebutuhan dan Analisis Tahap
selanjutnya yang
dilakukan
adalah
tahap pengumpulan
dan analisis. Dalam tahap ini dilakukan proses pengumpulan dan analisa informasi tentang bagian organisasi yang didukung oleh sistem basis data, dan menggunakan informasi ini untuk mengidentifikasi kebutuhan sistem yang baru (Connolly, Begg, 2005, p288). Banyak teknik yang digunakan untuk mengumpukan
fakta-fakta
tentang
sistem
dan
kebutuhan-kebutuhannya
dinamakan dengan teknik fact-finding (Connolly, Begg, 2005, p288). Terdapat lima kegiatan yang dipakai dengan teknik ini, yaitu :
2.1.6.3.1 Memeriksa Dokumentasi Pemeriksaan terhadap dokumen-dokumen, formulir, laporan, dan berkas yang terkait dengan sistem yang berjalan pada perusahaan. Hal ini diharapkan dapat membantu dalam mengetahui data-data apa saja yang akan disimpan dalam basis data.
2.1.6.3.2 Wawancara Wawancara bertujuan untuk mengumpulkan fakta-fakta, memeriksa kebenaran fakta yang ada dan mengklarifikasinya, membangkitkan semangat, melibatkan pengguna akhir, mengidentifikasi kebutuhan-kebutuhan, dan mengumpulkan ide-ide dan pendapat (Connolly, Begg, 2005, p317). Teknik ini memerlukan kemampuan komunikasi yang baik untuk menghadapi pengguna
21
yang memiliki nilai, prioritas, pendapat, motivasi, dan kepribadian yang berbedabeda.
2.1.6.3.3 Observasi Observasi ini memungkinkan untuk mengamati seseorang melakukan kegiatan untuk mempelajari sistem. Salah satu factor pengamatan dapat berhasil adalah dengan mencari informasi sebanyak mungkin tentang aktivitas yang akan diamati serta orang yang melakukan aktivitas tersebut.
2.1.6.3.4 Penelitian Selain melakukan penelitian yang berasal dari dalam organisasi itu sendiri, dapat juga dilakukan pengumpulan informasi yang berasal dari luar organisasi tersebut. Beberapa contoh sumber informasi tersebut antara lain jurnal komputer, buku-buku referensi, dan internet. Sumber informasi tersebut juga dapat digunakan untuk memecahkan masalah serupa.
2.1.6.3.5 Kuesioner Teknik lain yang dapat digunakan untuk mengumpulkan informasi yang dibutuhkan adalah dengan menggunakan kuesioner. Kuesioner adalah suatu dokumen dengan tujuan khusus yang memungkinkan fakta-fakta dikumpulkan dari banyak orang sambil menjaga kontrol terhadap tanggapan yang diberikan (Connolly, Begg, 2005, p320).
22
2.1.6.4 Perancangan Basis Data (Database Design) Merupakan proses pembuatan suatu rancangan untuk sistem basis data yang akan mendukung operasi dan objektif perusahaan (Connolly, Begg, 2005, p291). Ada 4 (empat) pendekatan perancangan basis data:
• Bottom-up Pendekatan ini dimulai dari tingkat paling dasar dari atribut (yakni properti dari entiti dan hubungan relasional) dimana melalui analisis gabungan antara atribut-atribut, dikelompokkan ke dalam relasi-relasi yang merepresentasikan tipe-tipe entiti dan hubungan antara entiti. Pendekatan ini lebih cocok untuk perancangan basis data yang sederhana dengan jumlah atribut yang relatif kecil. • Top-down Pendekatan ini dimulai dari pengembangan model data yang terdiri dari beberapa hubungan dan entiti tingkat tinggi. • Inside-out Pendekatan ini berhubungan dengan pendekatan bottom-up tetapi berbeda dari identifikasi set entiti dan kemudian menyebar ke entiti yang lain. • Mixed strategy Pendekatan ini menggunakan pendekatan bottom-up dan top-down dalam bagian model yang bermacam-macam sebelum digabungkan semuanya.
23
Database design terdiri dari tiga fase, yaitu: Conceptual database design, Logical database design, dan Physical database design.
2.1.6.5 Rancangan Basis Data Konseptual (Conceptual Database Design) Rancangan basis data konseptual merupakan suatu proses untuk membangun sebuah model informasi yang
digunakan oleh perusahaan, tidak tergantung
pertimbangan fisikal (Connolly, Begg, 2005, p439). Pertimbangan fisik yang dimaksud meliputi DBMS yang akan digunakan, program aplikasi, bahasa pemrograman, platform perangkat keras, unjuk kerja, dan pertimbangan fisik lainnya.
Langkah-langkah dalam metodologi conceptual database design yaitu : Langkah 1 : Membangun Conceptual Data Model Bertujuan untuk memecah rancangan menjadi tugas-tugas yang dapat diatur dengan memeriksa sudut pandang yang berbeda dari pengguna di dalam organisasi. Hasil dari langkah ini berupa pembuatan satu atau lebih local conceptual data model yang merupakan penggambaran yang tepat dan lengkap dari suatu organisasi dilihat dari para pengguna yang berbeda. Tugas-tugas yang dilakukan pada langkah ini terdiri dari :
1. Mengidentifikasi tipe entitas Tipe entitas dapat dikenali dengan mengidentifikasikan kata benda atau frase kata benda pada spesifikasi kebutuhan pengguna, objek besar seperti orang (people), tempat (place), benda (thing) atau konsep (concept) (Connolly, Begg, 2005, p443). Alternatif lain adalah dengan mencari obyek yang keberadaannya bebas.
24
2. Mengidentifikasi tipe hubungan antar entitas Bertujuan untuk mengidentifikasi relationship yang penting yang ada antara tipe entitas-tipe entitas yang telah diidentifikasi sebelumnya (Connolly, Begg, 2005, p445). Tipe relationship diidentifikasikan dengan mencari kata kerja atau suatu kata yang berhubungan dengan kata kerja.
3. Mengidentifikasi dan menghubungkan atribut dengan entitas atau hubungan Tujuannya untuk menghubungkan atribut dengan entitas dan tipe relationship yang tepat. Atribut yang dimiliki oleh setiap entitas dan relationship harus memenuhi karakteristik atribut yaitu simple/composite attribute, single/multivalued attribute, dan derived attribute. 4. Menentukan attribute domains Domain adalah sekumpulan nilai dimana satu atau lebih atribut memperoleh nilainya (Connolly, Begg, 2005, p450). Contoh menentukan domain pada atribut JenisKelamin di entitas Mahasiswa adalah dengan ‘L’ atau ’P’. 5. Menentukan Candidate Key, Primary, dan Alternate Key Tujuannya untuk mengidentifikasi candidate key untuk setiap tipe entitas, dan jika terdapat lebih dari satu candidate key maka terpilih satu sebagai primary key dan yang lainnya sebagai alternate key (Connolly, Begg, 2005, p451). 6. Pertimbangkan penggunaan enhance modelling concepts Maksud dari langkah ini adalah untuk menentukan specialization, generalization, aggregation, compotition (Connolly, Begg, 2005, p453).
25
7. Memeriksa model akan redudansi Bertujuan memeriksa conceptual model untuk menghindari adanya redundansi atau pengulangan data dalam model (Connolly, Begg, 2005, p453). Ada dua kegiatan yang dapat dilakukan pada tahap ini, yaitu sebagai berikut : •
Memeriksa kembali one-to-one relationship (1:1) Kemungkinan ada dua entitas yang menggambarkan objek yang sama dalam organisasi. Oleh karena itu, kedua entitas tersebut harus digabungkan.
•
Menghilangkan relasi yang redundan Suatu relationship menjadi redundan jika informasi yang sama dihasilkan melalui relationship yang lainnya. Untuk meminimalkan data model maka relationship yang redundan harus dihilangkan.
8. Validasi model konseptual terhadap transaksi pengguna Bertujuan untuk memastikan conceptual model mendukung transaksi yang dibutuhkan oleh pandangan pengguna (Connolly, Begg, 2005, p456). Dua pendekatan untuk memastikan local conceptual data model mendukung kebutuhan transaksi : •
Menggambarkan transaksi (describing the transaction)
Memeriksa semua informasi (entitas, relationship, dan atributnya) yang dibutuhkan setiap transaksi yang disediakan oleh model (Connolly, Begg, 2005, p456).
26
•
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, Begg, 2005, p457). 9. Melihat kembali conceptual data model dengan pengguna Langkah ini dilakukan dengan tujuan untuk memastikan bahwa data model merupakan representasi yang benar bagi setiap pandangan.
2.1.6.6 Rancangan Basis Data Logikal (Logical Database Design) Rancangan basis data logikal merupakan proses membangun model informasi yang digunakan organisasi berdasarkan model data tertentu, tetapi tidak tergantung dari Database Management System (DBMS) dan pertimbangan fisik lainnya (Connolly, Begg, 2005, p439). Langkah-langkah dalam metodologi logical database design yaitu: Langkah 2 : Membangun dan validasi logical data model Tujuannya untuk membangun sebuah local logical data model dari sebuah local conceptual data model yang mewakili pandangan tertentu dari organisasi dan kemudian memvalidasi model ini untuk memastikan bahwa strukturnya benar (dengan menggunakan teknik normalisasi) dan untuk memastikan dukungannya terhadap transaksi-transaksi yang dibutuhkan. Kegiatan yang dilakukan pada langkah ini meliputi:
27
1. Menghilangkan fitur-fitur yang tidak compatible dengan model relational Bertujuan untuk menyaring local conceptual data model sehingga fitur-fitur yang tidak sesuai dengan model relasional dihilangkan. Langkah-langkahnya antara lain: •
Menghilangkan many-to-many (*:*) binary relationship Dengan memecah relationship yang mengandung many-to-many (*:*) untuk mengidentifikasikan sebuah entitas tengah (intermediate entity) sehingga relationship ini digantikan dengan dua buah one-to-many (1:*) relationship, dengan entitas tengah berada di antara dua buah entitas yang lama.
•
Menghilangkan many-to-many (*:*) recursive relationship types 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-to-many (*:*) binary.
•
Menghilangkan complex relationship types 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.
28
•
Menghilangkan multi-valued attributes Cara menghilangkannya adalah dengan memecah atribut ini untuk mengidentifikasikan sebuah entitas.
2. Membuat relasi untuk model data logical Yang ditentukan pertama kali adalah nama relasi diikuti daftar simple attribute yang disertai dengan tanda kurung, primary key beserta alternate key dan atau foreign key dari relasi. Relationship antara satu entitas dengan entitas lainnya digambarkan dengan mekanisme primary key atau foreign key. 3. Validasi relasi dengan normalisasi Normalisasi merupakan sebuah tehnik yang dapat digunakan untuk menjelaskan relasi-relasi yang akan menjelaskan data, relationship , dan constraints seakurat mungkin (Connolly, Begg, 2005, p473). Normalisasi menggunakan pendekatan bottom-up dalam mendesain basis data yang dimulai dengan melakukan pengecekan relationship diantara atributatributnya. Normalisasi adalah tehnik untuk menghasilkan sebuah set dari relasi dengan properti-properti yang diinginkan, memberikan data yang dibutuhkan dari perusahaan (Connolly, Begg, 2005, p473). Proses normalisasi pertama kali dibangun oleh E.F Codd (1972).
29
Gambar 2.9 Diagram ilustrasi dari relationship diantara Normal Form
Proses normalisasi dimulai dengan memindahkan data sumber ke bentuk tabel dengan format baris dan kolom. Tabel ini berbentuk tidak normal dan disebut dengan unnormalized table (Connolly, Begg, 2005, p388). Tingkatan normalisasi yang digunakan sebagai landasan penulisan skripsi ada tiga tahap yaitu : •
First Normal Form (1NF) Suatu relasi dikatakan 1NF jika titik temu tiap baris dan kolom pada relasi tersebut mengandung satu dan hanya satu nilai (Connolly, Begg, 2005, p403). Sebuah relasi akan berada dalam bentuk 1NF jika repeating groupnya sudah hilang. Ada dua pendekatan untuk menghilangkan repeating group pada tabel yang tidak normal, yaitu: o Dengan memasukkan data yang sesuai ke dalam kolom yang kosong dari baris yang mengandung data berulang. o Dengan menempatkan data yang berulang bersama salinan atribut kunci pada relasi yang terpisah. Sebuah primary key diidentifikasikan ke dalam relasi yang baru.
30
•
Second Normal Form (2NF) Relasi dikatakan 2NF jika relasi tersebut berada pada 1NF dan setiap atribut yang bukan primary key bergantung penuh (fully functionally dependent) terhadap primary key (Connoly, Begg, 2005, p412). Full functional dependency terjadi jika A dan B merupakan atribut dari suatu relasi, dan B dikatakan bergantung penuh terhadap A (A→B), jika B bergantung terhadap A, namun bukan subset dari A. Untuk penghilangan
menghasilkan ketergantungan
relasi
dalam
sebagian
bentuk (partial
2NF
melibatkan
dependency)
dan
menempatkannya pada relasi yang baru bersama salinan atribut penentunya (determinant attribute). •
Third Normal Form (3NF) Suatu relasi dikatakan 3NF jika relasi tersebut berada dalam bentuk 1NF dan 2NF, dan tidak ada atribut bukan primary key bergantung secara transitif (transitively dependent) terhadap primary key (Connolly, Begg, 2005, p412). Transitive dependency ialah sebuah kondisi dimana A, B, dan C merupakan atribut dari relasi yang jika A→B dan B→C maka C disebut bergantung secara transitif (transitively dependent) terhadap A melalui B (A tidak functionally dependent terhadap B atau C) (Connolly, Begg, 2005, p412).
31
4. Validasi relasi terhadap transaksi pengguna Bertujuan untuk memastikan bahwa relasi-relasi pada local logical data model mendukung transaksi-transaksi yang dibutuhkan oleh pengguna, seperti terinci pada spesifikasi kebutuhan pengguna. 5. Memeriksa integrity constraints Integrity constraint adalah batasan-batasan yang harus ditentukan untuk melindungi basis data agar tetap konsisten (Connolly, Begg, 2005, p474). Ada lima jenis integrity constraint, yaitu : •
Required data 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). •
Attribute domain constraint Setiap atribut memiliki domain, yaitu himpunan nilai yang dibolehkan (Connolly, Begg, 2005, p475). Constraint ini harus diidentifikasikan pada saat pemilihan attribute domain untuk data model (langkah 1.4).
•
Entity integrity 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).
•
Referential integrity Jika suatu foreign key memiliki nilai, maka nilai tersebut harus menunjuk
32
ke sebuah baris yang ada pada relasi ‘parent’. •
General constraint (business rules) Kegiatan update entitas dibatasi oleh peraturan atau kebijakan organisasi yang mengatur transaksi yang diwakilkan oleh update yang dilakukan.
6. Meninjau kembali logical data model yang dibuat dengan user Tujuan yang ingin dicapai adalah untuk memastikan bahwa local logical data model dan dokumentasi pendukung yang menggambarkan model merupakan perwakilan yang benar dari pandangan pengguna. 7. Menggabungkan data model kedalam global model Bertujuan menggabungkan masing-masing local logical data model menjadi sebuah global logical data model yang menggambarkan organisasi dengan menyatukan masing-masing local logical data model bagi setiap pandangan pengguna. Kegiatan yang dilakukan pada langkah ini meliputi : •
Menggabungkan semua model logikal data ke dalam model global
Untuk setiap local logical data model telah dihasilkan sebuah diagram Entity-Relationship (ER diagram), skema relasional, kamus data, dan dokumentasi pendukung yang menggambarkan batasan-batasan model. Komponen-komponen
tersebut
digunakan
untuk
mengidentifikasikan
persamaan dan perbedaan antara model-model dan oleh karena itu akan membantu menyatukan model-model tersebut. •
Validasi global logical data model
Bertujuan untuk memvalidasi relasi-relasi yang dibuat dari global logical
33
data model dengan menggunakan teknik normalisasi dan untuk memastikan bahwa model tersebut mendukung transaksi-transaksi yang dibutuhkan. •
Meninjau kembali global logical data model dengan para
pengguna Bertujuan untuk memastikan bahwa global logical data model merupakan representasi yang benar dari organisasi. 8. Memeriksa perkembangan di masa yang akan datang Bertujuan untuk menentukan kemungkinan adanya perubahan yang berarti pada waktu mendatang dan untuk memperkirakan apakah global logical data model yang ada dapat menyesuaikan dengan perubahan tersebut
2.1.6.7 Pemilihan DBMS (Database Management System) Pemilihan DBMS adalah proses memilih DBMS yang cocok untuk mendukung sistem basis data (Connolly, Begg, 2005, p295). Langkah-langkah utama untuk memilih DBMS yaitu : •
Mendefinisikan cakupan tugas yang akan dilakukan
•
Membandingkan dua atau tiga produk
•
Mengevaluasi produk
•
Merekomendasikan pemilihan sistem basis data dan membuat laporan dari
evaluasi produk DBMS. DBMS (Database Management System) adalah perangkat lunak khusus yang digunakan untuk membuat, mengakses, mengontrol, dan mengatur sebuah
34
basis data (Whitten, 2004, p760). 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 dimasa 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: •
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. •
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. •
Evaluasi produk Fitur-fitur yang digunakan dalam evaluasi produk produk DBMS
35
dikelompokkan menjadi definisi data, definisi fisik, kemampuan akses, penanganan keperluan-keperluan, pengembangan, dan fitur-fitur lainnya. •
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.1.6.8 Rancangan Basis Data Fisikal (Physical Database Design) Rancangan basis data fisikal (physical database design) adalah proses untuk menghasilkan penjelasan dari pengimplementasian suatu basis data pada media penyimpanan kedua, juga menjelaskan base relation, pengaturan file, dan indeks yang digunakan untuk mencapai akses data yang efisien, integrity constraint, serta ukuran keamanan (Connolly, Begg, 2005, p439). Langkahlangkah metodologi perancangan basis data fisik terdiri dari: Langkah 3 : Menterjemahkan global logical data model untuk target DBMS Bertujuan untuk menghasilkan skema basis data relasional bagi global logical data model yang dapat diimplementasikan pada target DBMS. 1. Merancang Relasi Dasar Untuk setiap relasi yang diidentifikasikan pada global logical data model, definisinya terdiri dari nama relasi, daftar simple attribute diikuti tanda kurung, primary key berserta alternate key dan foreign key jika ada, dan referential integrity constraint bagi foreign key yang teridentifikasi.
36
Definisi setiap atribut pada kamus data terdiri dari domain yang terdiri atas tipe data, panjang data, setiap constraint pada domain, nilai default jika ada, dan keterangan apakah atribut dapat memiliki nilai null. 2. Merancang representasi derived data Bertujuan untuk menentukan cara untuk merepresentasikan derived data yang ada dalam global logical data model ke dalam target DBMS. Biasanya derived
attribute
tidak
terlihat
pada
logical
data
model
namun
didokumentasikan di dalam kamus data. Untuk setiap derived attribute yang ada, tanda ‘/’ digunakan untuk menandakan atribut tersebut adalah derived attribute. 3. Merancang general constraints Bertujuan untuk merancang batasan-batasan organisasi untuk target DBMS. Update terhadap relasi dibatasi oleh peraturan organisasi yang mengatur transaksi ‘real world’ yang diwakili oleh update tersebut. Langkah 4 : Merancang organisasi file dan indeks Bertujuan untuk menentukan organisasi file yang optimal untuk menyimpan base relation dan indeks yang diperlukan untuk mencapai unjuk kerja yang sesuai, dengan cara penentuan penyimpanan relasi dan baris-baris pada tempat penyimpanan kedua (Connolly, Begg, 2005, p501). Kegiatan yang dilakukan pada
langkah ini meliputi: 1. Analisis transaksi Bertujuan untuk memahami fungsi dari transaksi yang dijalankan pada basis
37
data dan menganalisis transaksi-transaksi yang penting. Dalam menganalisis transaksi, kriteria unjuk kerja yang harus diidentifikasi seperti: • Transaksi yang sering digunakan dan yang memiliki dampak yang signifikan pada unjuk kerja. • Transaksi yang penting bagi kegiatan operasional bisnis. • Peak load, yaitu saat-saat pada hari atau minggu dimana akan ada permintaan yang tinggi terhadap basis data (Connolly, Begg, 2005, p502) 2. Memilih organisasi file Untuk menentukan organisasi file yang efisien untuk setiap base relation. 3. Memilih indeks Untuk menentukan apakah penambahan indeks akan meningkatkan unjuk kerja sistem. Ada tiga jenis indeks yaitu: • Primary index Pengindeksian dilakukan pada kolom kunci (key field), yang diurutkan terlebih dahulu secara sekuensial. • Clustering index Pengindeksian dilakukan pada kolom bukan kunci (non-key field), yang sudah diurutkan terlebih dahulu secara sekuensial. Kolom bukan kunci itu disebut juga dengan clustering attribute. • Secondary index Pengindeksian yang dilakukan pada kolom yang tidak terurut di dalam file data.
38
4. Memperkirakan kebutuhan disk space Memperkirakan besarnya ruang penyimpanan yang dibutuhkan untuk mendukung implementasi basis data pada tempat penyimpanan kedua. Hal ini sangat tergantung pada target DBMS dan perangkat keras yang digunakan. Perkiraan ukuran dapat dilakukan dengan mengukur besar data tiap baris dan jumlah baris pada setiap relasi. Langkah 5 : Merancang user view Bertujuan untuk merancang pandangan pengguna yang diidentifikasikan selama tahap pengumpulan kebutuhan dan analisa pada daur hidup aplikasi basis data relasional (database application lifecycle) (Connolly, Begg, 2005, p515). Langkah 6 : Merancang mekanisme keamanan Bertujuan
untuk
menentukan
bagaimana
kebutuhan
keamanan
akan
direalisasikan. Keamanan bagi basis data sangat diperlukan karena basis data merupakan sumber daya perusahaan yang penting. Dua tipe keamanan basis data (Connolly, Begg, 2005, p516), yaitu: • Keamanan sistem Perlindungan terhadap akses dan penggunaan basis data pada tingkat sistem, seperti user name dan password. • Keamanan data Memberikan perlindungan akses dan penggunaan objek basis data, sepeti relasi dan view dan aksi terhadap objek yang dapat dimiliki oleh pemakai.
39
Langkah 7 : Mempertimbangkan pengenalan pengontrolan redundancy Untuk menentukan apakah pengenalan pengontrolan redundancy dengan mengendurkan aturan normalisasi akan meningkatkan unjuk kerja sistem. Langkah 8 : Memantau operasional sistem Bertujuan untuk memantau operasional sistem dan meningkatkan unjuk kerja sistem untuk memperbaiki keputusan desain yang tidak sesuai atau menggambarkan kebutuhan-kebutuhan perubahan.
2.1.6.9 Merancang Aplikasi (Application Design) Rancangan aplikasi merupakan desain dari user interface dan program aplikasi yang menggunakan dan memproses basis data (Connolly, Begg, 2005, p299). Terdapat dua aspek desain aplikasi, yaitu: desain transaksi dan desain tampilan bagi user.
2.1.6.9.1 Desain Transaksi Transaksi merupakan sebuah aksi, atau sekumpulan aksi yang dibawa oleh user atau program aplikasi, yang mengakses atau merubah isi dari basis data (Connolly, Begg, 2005, p300). Tujuan dari mendesain transaksi adalah untuk menemukan dan mendokumentasikan high-level karakteristik dari transaksi yang dibutuhkan pada basis data, mencakup: • Data yang akan digunakan oleh transaksi • Karakteristik fungsional dari transaksi
40
• Output dari transaksi • Rata-rata pemakaian yang diharapkan Terdapat tiga tipe dari transaksi, diantaranya adalah: 1. Retrieval transaksi, digunakan untuk meretrieve data untuk tampilan dilayar atau untuk produksi report. 2. Update transaksi, digunakan untuk memasukkan record baru, menghapus record lama, atau memodifikasi record yang ada dalam basis data. 3.
Transaksi campuran, yang mencakup kedua transaksi, baik retrieval dan update data.
2.1.6.9.2 Desain Tampilan Bagi User Sebelum pengimplementasian sebuah form atau report, penting untuk mendesain layout. Berikut ini adalah aturan-aturan untuk mendesain user interface (Connolly, Begg, 2005, p301): • Judul yang mempunyai arti Informasi yang ada pada judul harus jelas dan tidak ambigous
dalam
menjelaskan form atau report. • Instruksi yang komprehensif Instruksi harus jelas, dan ketika informasi tambahan dibutuhkan, menu bantuan harus tersedia. • Pengelompokan secara logikal dan mengurutkan field-field Field-field yang berhubungan harus mempunyai posisi yang sama dalam
41
form/report. Pengurutan dari field harus logikal dan konsisten. • Tampilan yang atraktif dari form/report Form/report harus menampilkan tampilan yang atraktif bagi user. Tidak boleh ada daerah dari form/report yang mempunyai terlalu banyak atau terlalu sedikit field. • Nama-nama field yang familiar Nama field harus familiar bagi user. • Consistent terminology dan abbreviations An agreed list dari familiar term dan abbreviation harus digunakan konsisten. • Penggunaan warna yang konsisten Warna harus digunakan untuk meningkatkan penampilan dari form/report dan untuk menandai field penting atau pesan penting. • Spasi dan batasan untuk setiap field data entry Seorang user harus memperhatikan secara visual dari total jumlah dari tempat yang tersedia untuk setiap field. • Pergerakan cursor yang nyaman Seorang user harus mengidentifikasi dengan mudah operasi yang dibutuhkan untuk menggerakkan cursor didalam form/report. • Pengecekan kesalahan untuk karakter individual dan seluruh field Seorang user harus mengidentifikasi dengan mudah operasi yang dibutuhkan untuk membuat masukan untuk nilai field. Mekanisme yang sederhana harus tersedia seperti menggunakan key Backspace.
42
• Pesan kesalahan untuk nilai yang tidak dapat diterima Jika user memasukkan nilai yang salah kedalam field, sebuah pesan kesalahan harus ditampilkan. Pesan harus menginformasikan kepada user dari kesalahan yang terjadi. • Optional field harus ditandai dengan jelas Optional field harus jelas diidentifikasikan untuk user. Hal ini dapat dilakukan menggunakan sebuah nama field yang tepat atau dengan menampilkan field menggunakan warna yang mengindikasikan tipe dari field. • Pesan informasi bagi setiap field Ketika seorang user menempatkan cursor pada field, informasi tentang field harus muncul dilayar. • Completion signal Harus jelas bagi user ketika proses pengisian field pada form sudah selesai.
2.1.6.10 Prototyping Prototype merupakan membangun sebuah model kerja dari aplikasi basis data. Tujuan utama mengembangkan suatu aplikasi basis data prototype adalah mengijinkan para pemakai menggunakan prototype itu untuk mengidentifikasi fitur sistem yang bekerja dengan baik, bahkan meningkatkan fitur baru bagi aplikasi basis data. Dengan demikian, kita dapat memperjelas kebutuhan pemakai dan pengembang sistem dan mengevaluasi kelayakan desain sistem tertentu (Connolly, Begg, 2005, p304).
43
Ada dua strategi dari prototype yaitu menentukan kebutuhan prototype dan membuat
prototype evolusioner. Kebutuhan prototype berguna untuk
menentukan kebutuhan suatu aplikasi basis data yang diusulkan dan ketika kebutuhan terhadap basis data tersebut sudah lengkap maka prototype tidak digunakan lagi. Prototype evolusioner digunakan untuk tujuan yang sama, perbedaannya
adalah
bahwa
prototype
tidak
dibuang,
tetapi
dengan
pengembangan lebih lanjut prototype tersebut bekerjasama dengan aplikasi basis data.
2.1.6.11 Implementasi (Implementation) Implementasi merupakan perwujudan fisik dari basis data dan desain aplikasi (Connolly, Begg, 2005, p304). Pada tahap penyelesaian desain (dimana dapat melibatkan pembuatan prototype atau tidak), dapat diterapkan basis data dan program aplikasi yang telah dibuat. Implementasi basis data dapat dicapai dengan menggunakan DDL (Data Definition Language) yang telah dipilih atau dengan menggunakan GUI (Graphical User Interface). Keamanan dan kontrol integrity untuk aplikasi juga dapat diimplementasikan.
2.1.6.12 Konversi dan Loading Data (Data Conversion and Loading) Pemindahan data yang ada di dalam basis data baru dan konversi aplikasi yang sedang berjalan agar dapat digunakan dalam basis data yang baru (Connolly, Begg, 2005, p305). Langkah ini hanya diperlukan ketika suatu sistem
44
basis data baru sedang menggantikan sistem basis data yang lama. Dewasa ini DBMS mempunyai peralatan yang dapat dipakai untuk mengisi file yang ada ke dalam basis data yang baru, peralatan ini membutuhkan spesifikasi sumber file dan target basis data dan kemudian secara otomatis mengkonversi data pada format yang diperlukan basis data yang baru.
2.1.6.13 Testing Merupakan proses eksekusi program aplikasi dengan tujuan menemukan kesalahan. Dengan menggunakan perencanaan strategi test dan data yang sebenarnya sehingga seluruh proses testing dapat berjalan dengan baik (Connolly, Begg, 2005, p305). Seperti dalam desain basis data, user dari sistem baru ini harus dilibatkan dalam proses testing. Jika data yang sebenarnya yang digunakan, kita perlu membuat back-up, apabila terjadi kesalahan. Setelah testing selesai, sistem aplikasi siap untuk dipindah tangankan pada user.
2.1.6.14 Pemeliharaan Operasional (Operational Maintenance) Merupakan proses memonitor dan memelihara sistem beserta instalasinya (Connolly, Begg, 2005, p306). Langkah pemeliharaan mencakup dari aktivitas sebagai berikut: • Memonitor performansi sistem • Memelihara dan mengup-grade aplikasi basis data (jika diperlukan) Proses memonitor ini dilakukan secara bertahap dan pada waktu tertentu
45
boleh melakukan organisasi ulang basis data untuk mencukupi kebutuhan sistem. Perubahan ini menyediakan informasi pada evolusi sistem dan sumber daya yang pada masa yang akan datang mungkin diperlukan.
2.1.7
Flowchart Flowchart adalah gambaran dalam bentuk diagram alir dari algoritma-
algoritma dalam suatu program, yang menyatakan arah alur program tersebut. Berikut adalah beberapa simbol yang digunakan dalam menggambar suatu flowchart : SIMBOL
NAMA
FUNGSI
TERMINATOR
Permulaan/akhir program
GARIS ALIR (FLOW LINE)
Arah aliran program
PREPARATION
Proses inisialisasi/pemberian harga awal
PROSES
Proses perhitungan/proses pengolahan data
INPUT/OUTPUT DATA
Proses input/output data, parameter, informasi
PREDEFINED PROCESS (SUB PROGRAM)
Permulaan sub program/proses menjalankan sub program
DECISION
Perbandingan pernyataan, penyeleksian data yang memberikan pilihan untuk langkah selanjutnya
46
ON PAGE CONNECTOR
Penghubung bagian-bagian flowchart yang berada pada satu halaman
OFF PAGE CONNECTOR
Penghubung bagian-bagian flowchart yang berada pada halaman berbeda
Gambar 2.10 Simbol-Simbol Flowchart
2.1.8 DFD (Data Flow Diagram) DFD merupakan salah satu komponen dalam serangkaian pembuatan perancangan sebuah sistem komputerisasi. DFD menggambarkan aliran data dari sumber pemberi data (input) ke penerima data (output). Aliran data itu perlu diketahui agar si pembuat sistem tahu persis kapan sebuah data harus disimpan, kapan harus ditanggapi (proses), dan kapan harus didistribusikan ke bagian lain. Menurut Yourdon (1989, p139), data flow diagram atau diagram alir data adalah model atau alat yang digunakan untuk menggambarkan sistem sebagai jaringan dari sekumpulan proses fungsional yang dihubungkan satu dengan lainnya oleh suatu aliran data dan meneruskannya menjadi data. Ada tiga tingkatan dalam data flow diagram yaitu : 1. Diagram Konteks Tingkatan yang paling utama yang menggambarkan ruang lingkup sistem dari sistem yang digunakan. Diagram ini hanya memiliki satu proses yang menggambarkan sistem secara keseluruhan dan hubungan antara sistem dengan unit-unit diluar sistem tersebut.
47
2. Diagram Nol Diagram yang menggambarkan proses-proses dan aliran data yang terjadi didalam suatu sistem. Proses-proses ini dapat dipecah menjadi prosesproses dan aliran data yang lebih terperinci. 3. Diagram Rinci Diagram yang menggambarkan rincian proses-proses yang ada pada diagram nol dan rincian proses-proses ini dapat dipecah lagi menjadi prosesproses yang lebih terperinci. Data flow diagram terdiri dari simbol-simbol sebagai berikut:
atau
Terminator
Proses
Alur Data
Penyimpan Data (data store)
Gambar 2.11 Simbol-Simbol DFD
Keterangan : a. Proses (Bubble) Proses menggambarkan bagian dari sistem yang mengolah masukan menjadi keluaran. Proses digambarkan dengan sebuah lingkaran. b. Aliran data (flow) Aliran menggambarkan perpindahan informasi dari satu bagian kebagian lain dari sistem. Awal panah menggambarkan asal data sedangkan akhir panah menggambarkan tujuan.
48
c. Penyimpanan data (store) Simbol ini digunakan untuk menggambarkan penyimpanan data. d. Terminator Simbol yang menggambarkan entitas yang dapat berupa orang, kelompok, atau organisasi yang berhubungan dengan system
2.1.9
State Transition Diagram (STD) Diagram perubahan data adalah sebuah perlengkapan yang digunakan
untuk menggambarkan urutan dan variasi dari layar yang terjadi menurut sesi pengguna (Whitten, Bentley, Dittman, 2004, p673). State transition diagram juga merupakan suatu diagram yang menggambarkan bagaimana suatu proses dihubungan satu sama lain dalam waktu yang bersamaan. State transition diagram digambarkan dengan sebuah state yang berupa komponen sistem yang menunjukan bagaimana kejadiankejadian tersebut dari satu state ke state lain. State transition diagram diartikan juga sebagai suatu modeling tool yang menggambarkan sifat ketergantungan pada waktu dari suatu sistem. State transition diagram terdiri dari : a. State (keadaan) b. Event atau tindakan yang menyebabkan perpindahan dari satu state ke state lainnya.
49
Ada dua macam simbol yang menggambarkan proses dalam State transition diagram (STD) yaitu : a. Gambar persegi panjang menunjukkan state dari sistem. b. Gambar panah menunjukkan transisi antar state.
State
Transition
50
2.2
Teori - Teori Khusus yang Berhubungan dengan Topik Yang Dibahas 2.2.1 Teori Sumber Daya manusia 2.2.1.1 Sumber Daya Manusia Sumber daya manusia (SDM) merupakan bagian yang penting didalam suatu organisasi atau perusahaan. SDM diperoleh dan disusun agar siap digunakan saat diperlukan. Dari sudut pandang ini, SDM adalah prioritas paling utama untuk semua operasi yang berpusat pada pekerja manusia. Dalam dekade terakhir, perusahaan besar telah mencapai produktivitas yang besar dengan menggunakan solusi SDM yang baik.
Sekarang ini,
perangkat lunak (software) akan mengubah proses SDM menjadi terotomatisasi. Penyimpanan semua informasi yang berkaitan dengan perusahaan secara elektronik akan menghapus kebutuhan akan ruang besar untuk menyimpan kertas-kertas data.
2.2.1.2 Perencanaan Sumber Daya Manusia Perencanaan SDM merupakan fungsi yang pertama harus dijalankan dalam organisasi.
Perencanaan SDM adalah langkah tertentu yang diambil
manajemen guna menjamin bahwa organisasi tersedia tenaga kerja yang tepat untuk menduduki berbagai kedudukan, jabatan dan pekerjaan yang tepat pada waktu yang tepat.
51
2.2.2 Teori Peristilahan Pekerjaan 2.2.2.1 Kepegawaian Sistem kepegawaian adalah suatu sistem atau cara pengelolaan dalam bidang kepegawaian menyangkut semua aspek yang ada dalam sistem kepegawaian mulai dari cara penerimaan, pengangkatan, kenaikan golongan, penggajian pegawai dan sebagainya.(Wursanto, 1987, p34).
2.2.2.2 Klasifikasi Jabatan Klasifikasi jabatan adalah suatu kegiatan penggolongan jabatan-jabatan berdasarkan macam tugas yang dilakukan berikut cara-cara yang diperlukan untuk memangku jabatan tersebut atau suatu kegiatan penyusunan secara teratur dari jabatan-jabatan dalam beberapa golongan atau tingkatan untuk dapat diketahui derajat tiap-tiap jabatan.(Wursanto, 1987, p75).
2.2.2.3 Pelatihan Pelatihan adalah setiap usaha untuk memperbaiki kinerja pekerja pada suatu perusahaan tertentu yang sedang menjadi tanggung-jawabnya. Bentuk latihan dapat berupa kursus-kursus, praktek-praktek denagn pengawasan, dan insturksi- insturksi. Bentuk latihan yang dapat diberikan kepada grup atau rombongan dapat berupa seminar-seminar, konferensi-koferensi, atau diskusidiskusi.(Wursanto, 1987, p114).
52
2.2.2.4 Mutasi Salah satu tindak lanjut yang dilakukan atas hasil penilaian prestasi pegawai
adalah
mutasi
pegawai.
Mutasi
adalah
suatu
perubahan
posisi/jabatan/tempat/pekerjaan yang dilakukan baik secara horizontal maupun vertical dalam suatu organisasi Tujuan mutasi (Faustino, 1995, p197) adalah : a. Meningkatkan produktivitas pegawai b. Menciptakan keseimbangan antara tenaga kerja dengan komposisi pekerjaan atau jabatan c. Memperluas pengetahuan pegawai d. Memeberikan perangsangan agar pegawai dapat meningkatkan karier e. Menghilangkan rasa bosan terhadap pekerjaan f. Melaksanakan hukuman atas pelanggaran pegawai g. Memberikan imbalan terhadap pekerjaan pegawai h. Sebagai alat pendorong agar semangat kerja meningkat i. Menyesuaikan pekerjaan dengan kondisi fisik pegawai j. Mengatasi perselisihan sesama pegawai k. Sebagai tindakan pengamanan yang lebih baik
2.2.2.5 Cuti Jenis cuti yang merupakan hak dari setiap karyawan yaitu : •
Cuti tahunan.
•
Ijin kepentingan keluarga.
53
•
Cuti melahirkan.
•
Cuti menjalankan ibadah agama.
•
Cuti diluar tanggungan perusahaan.
2.2.2.6 Kedisiplinan Menurut asal katanya istilah disiplin berasal dari kata disciple yang berarti murid, disciplinary mengenai kepatuhan, kata itu berubah menjadi kata discipline yang mempunyai arti kepatuhan atau hal yang menyangkut tata tertib. Dengan demikian, makna disiplin ialah merupakan suatu kepatuhan kepada aturan-aturan, norma-norma, patokan-patokan, hukum, dan tata tertib yang berlaku. (Wursanto, 1987, p145).
2.2.2.7 Prestasi Kerja Dalam prestasi kerja pengangkatan seorang pegawai (kenaikan pangkat) didasarkan atas kecakapan dan prestasi yang dicapai oleh seorang pegawai yang bersangkutan. (Wursanto, 1987, p36).
2.2.2.8 Pemberhentian Masalah pemberhentian Pegawai Negeri Sipil diatur di dalam Peraturan Pemerintah No. 32 Tahun 1979 tentang Pemberhentian Pegawai Negeri Sipil. Dalam Peraturan Pemerintah ini diatur hal-hal berikut :
54
1. Pemberhentian atas permintaan sendiri 2. Pemberhentian karena mencapai batas usia pensiun 3. Pemberhentian karena adanya penyederhanaan organisasi 4. Pemberhentian karena melakukan pelanggaran, tindak pidana, atau penyelewengan 5. Pemberhentian karena tidak cakap jasmani atau rohani 6. Pemberhentian karena meninggalkan tugas 7. Pemberhentian karena meninggal dunia atau hilang 8. Pemberhentian karena hal-hal lain. (Wursanto, 1987, p188).
2.2.3 Teori Aplikasi .NET adalah istilah yang sering diassosiasikan/dikaitkan dengan proses yang berjalan pada (menggunakan) platform teknologi .NET, misalnya VB.NET, C#.NET, Visual Studio .NET, ASP.NET, ADO.NET dan sebagainya. Teknologi .NET adalah suatu platform baru di dalam pemrograman yang ditawarkan oleh Microsoft dalam upaya meningkatkan produktivitas penulisan program dan memungkinkan terbukanya peluang untuk menjalankan program pada sistem operasi yang berbeda. Misalnya program yang dibuat pada sitem operasi Unix/Linux tanpa harus mengadakan modifikasi pada program. Pencapaian teknik ini dimungkinkan dengan cara mengubah teknik pengompilasian dan pengeksekusian program. Jika pada masa lalu sebuah program/aplikasi yang telah dibuat akan dikompilasi menjadi sebuah file yang
55
dapat dieksekusi langsung (sistem operasi dapat menerjemahkan kompilasi file menjadi bahasa mesin), maka pada program berbasis teknologi .NET, program akan dikompilasi menjadi Microsoft Intermediate Language (MSIL). Selanjutnya MSIL akan dikompilasi oleh .NET Compiler menjadi bahasa mesin sesuai dengan sistem operasi dan spesifikasi yang dimiliki/terdapat pada peranti keras yang digunakan. Proses kompilasi ganda ini dilakukan/diatur oleh .NET framework SDK ynag telah diinstalasikan pada sistem operasi dari peranti keras yang digunakan. Pada saat ini .NET Framework hanya dapat dijalankan pada peranti keras yang menggunakan sistem operasi berbasis Microsoft Windows.
