6

BAB 2

LANDASAN TEORI

2.1. Teori Basis Data

2.1.1 Pengertian Data

Data adalah fakta - fakta yang telah diketahui dan dapat

dikumpulkan serta dapat disimpan dalam media komputer. Data terdiri dari

fakta-fakta dan simbol-simbol angka yang secara relatif mempunyai arti

bagi pengguna. ( Hoffer, Prescott, dan McFadden , 2005, p5)

2.1.2 Pengertian Sistem

Sistem merupakan kumpulan dari elemen-elemen yang terintegrasi

dengan maksud umum untuk mencapai suatu tujuan. (McLeod and Schell,

2001, p9)

Menurut pendapat O’Brien (2002, p8) sistem secara sederhana

dapat diartikan sebagai sebuah kumpulan dari elemen-elemen yang saling

berhubungan atau berinteraksi yang membentuk suatu kesatuan.

2.1.3 Pengertian Basis Data

Menurut Connolly dan Begg (2002, p14), basis data merupakan

suatu koleksi data yang berhubungan secara logikal , dan sebuah deskripsi

data yang dirancang untuk memenuhi informasi yang dibutuhkan oleh

suatu organisasi. Dapat dikatakan juga basis data adalah kumpulan file

yang saling berhubungan, hubungan tersebut biasa ditunjukkan dengan

7

kunci dari tiap file yang ada. Suatu basis data menunjukkan satu kumpulan

data yang dipakai dalam satu lingkup organisasi. Basis data menjadi salah

satu bagian penting dari perusahaan untuk menyimpan informasi-informasi

yang diinginkan perusahaan tersebut..

2.1.4 Pengertian Sistem Basis Data

Menurut Connolly dan Begg (2002, p4), Sistem basis data pada

dasarnya adalah sistem penyimpanan record yang terkomputerisasi dimana

tujuan sebenarnya adalah menyimpan informasi dan membuat informasi

tersebut selalu tersedia pada saat dibutuhkan.

2.1.5 Entity Relationship Modelling (ER Modelling)

ER Modelling adalah salah satu bentuk pendekatan top-down dalam

perancangan basis data yang dimulai dengan mengidentifikasi data-data

penting yang disebut entities dan hubungan (relationship) antara data - data

tersebut harus direpresentasikan dalam sebuah model. (Connolly and Begg,

2002, p330).

Berikut ini dijelaskan konsep dasar dari ER Modelling, sebagai

berikut:

2.5.1.1 Tipe Entiti

Tipe entiti menggambarkan kumpulan dari objek yang ada pada

‘dunia nyata’ dengan properti yang sama. Sebuah tipe entiti bisa

berbentuk objek dengan keberadaan fisik ( nyata ) ataupun objek yang

tidak nyata ( abstrak ).

8

2.5.1.2 Tipe Relasi

Tipe relationship adalah sekumpulan hubungan antartipe

entitas yang memiliki arti (Connolly and Begg, 2002, p334).

Sedangkan relationship occurrence adalah sebuah hubungan yang

dapat diidentifikasikan secara unik, yang meliputi sebuah kejadian

(occurrence) dari setiap tipe entitas di dalam relationship (Connolly

and Begg, 2002, p334).

Tipe relationship digambarkan dengan sebuah garis yang

menghubungkan tipe entitas - tipe entitas yang saling berhubungan.

Garis tersebut diberi nama sesuai dengan nama hubungannya dan

diberi tanda panah satu arah di samping nama hubungannya.

Biasanya sebuah relationship dinamakan dengan

menggunakan kata kerja, seperti Mengatur, atau dengan sebuah

frase singkat yang meliputi sebuah kata kerja, seperti DisewaOleh.

Sedangkan tanda panah ditempatkan di samping nama relationship

yang mengindikasikan arah bagi pembaca untuk mengartikan nama

dari suatu relationship. Huruf pertama dari setiap kata pada nama

relationship ditulis dengan huruf besar. Representasi diagram dari

suatu tipe relationship terlihat pada gambar 2.1.

Pegawai CabangMemiliki

' Cabang memiliki pegawai '

Gambar 2.1 Representasi diagram dari tipe relationship

(Connolly and Begg, 2002, p335)

9

a. Degree of relationship type

Derajat dari tipe relationship adalah jumlah tipe entitas

yang ikut serta dalam sebuah relationship (Connolly and Begg,

2002, p335).

Complex relationship types adalah sebuah relationship

antara tiga atau lebih tipe entitas (Connolly and Begg, 2002,

p445). Sebuah relationship yang memiliki derajat dua dinamakan

binary (Connolly and Begg, 2002, p336). Gambar 2.1 juga

merepresentasikan diagram relationship derajat dua. Sedangkan

sebuah relationship derajat tiga dinamakan ternary, dan jika

sebuah relationship memiliki derajat empat dinamakan

quarternary (Connolly and Begg, 2002, p336). Suatu relasi dapat

disebut relasi yang kompleks bila relasi tersebut mempunyai

degree yang lebih dari dua ( binary ).

b. Relasi Rekursif

Merupakan sebuah tipe relationship dimana tipe entitas

yang sama ikut serta lebih dari sekali pada peran yang berbeda

(Connolly and Begg, 2002, p337).

Relationship dapat diberikan nama peran untuk

menentukan fungsi dari setiap entitas yang terlibat dalam

relationship tersebut. Representasi diagram recursive relationship

beserta nama perannya terlihat pada gambar 2.2.

10

'Pegawai (Pengawas) mengawasi pegawai (orang yang diawasi)'

Pegawai

Mengawasi

Pengawas

Orang yangdiawasi

Nama peran

Nama peran

Gambar 2.2 Representasi diagram recursive relationship dan nama peran

(Connolly and Begg, 2002, p337)

2.5.1.3 Atribut

Atribut adalah properti sebuah entitas atau relationship (Connolly

and Begg, 2002, p338).

a. Domain Atribut

Merupakan kumpulan dari nilai-nilai yang diperbolehkan untuk

satu atau lebih attribut, misalnya untuk atribut noKamar harus

diisi dengan nilai antara 1 sampai 15.

b. Simple and Composite Attributes

i. Simple attribute adalah atribut yang terdiri dari komponen

tunggal dengan keberadaaannya yang bebas (Connolly and

Begg, 2002, p339), contohnya adalah jabatan, gaji pada entitiy

staff.

ii. Composite attribute adalah atribut yang terdiri dari beberapa

komponen, dan keberadaan setiap komponen tersebut bebas

(Connolly and Begg, 2002, p339). Composite attribute dapat

dipecah lagi menjadi komponen-komponen independen yang

11

lebih kecil, misalnya entity cabang dengan nilai (163 Main St,

Glasgow, G119QX) dapat dipecah menjadi attribut jalan (163

Main St). kota (Glasgow), kodePos(G11 9QX)

c. Single-Value and Multi-Value Attributes

i. Single-value attribute adalah atribut yang hanya mempunyai

sebuah nilai untuk setiap tipe entiti (Connolly and Begg, 2002,

p339). Hampir sebagian besar attribut adalah single-value,

misalnya pada entiti cabang mempunyai noCabang (B003),

noCabang ini adalah single-value attribute.

ii. Multi-valued attribute merupakan attribut yang mempunyai

banyak nilai untuk setiap tipe entiti (Connolly and Begg,

2002, p340), misalnya pada noCabang B003 mempunyai

noTelp 0141-339-2178 dan 0141-339-4439. Pada kasus ini,

noTelp merupakan multi-value attribute.

d. Derived Attributes

Derived attributes merupakan sebuah atribut yang merepresentasikan

sebuah nilai yang berasal dari nilai sebuah atribut yang berhubungan

atau set atribut, dan tidak harus berada dalam tipe entiti yang sama

(Connolly and Begg, 2002, p340).

e. Keys

i. Candidate key merupakan himpunan atribut yang minimal yang

secara unik mengidentifikasikan setiap occurrence dari sebuah

tipe entitas (Connolly and Begg, 2002, p340).

ii. Primary key adalah candidate key yang terpilih untuk

12

mengidentifikasikan secara unik setiap occurrence dari sebuah

tipe entitas (Connolly and Begg, 2002, p341). 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

iii. Composite key adalah candidate key yang terdiri dari dua atau

lebih attribut (Connolly and Begg, 2002, p341).

2.5.1.4 Structural Constraints

Multiplicity merupakan jumlah kemunculan (occurence) yang

mungkin dari sebuah tipe entiti yang berhubungan dengan

kemunculan tunggal dari sebuat tipe entiti yang berhubungan melalui

relasi tertentu (Connolly and Begg, 2002, p344).

Contohnya beberapa batasan-batasan (constraints) termasuk

syarat bahwa sebuah properti sewa harus mempunyai seorang pemilik

dan setiap cabang harus mempunyai staff. Tipe utama dari batasan-

batasan dalam relasi ini disebut multiplicity. Multiplicity membatasi

cara entiti-entiti saling terhubung. Batasan ini dapat dibuat oleh

organisasi ataupun user

Tingkat relasi yang umum antar entiti adalah binary. Berikut

ini adalah relasi binary yang sering terjadi :

1. Relasi One-to-One (1:1)

Relasi dimana setiap entiti yang ada hanya dapat

mempunyai maksimal 1 relasi dengan entiti yang lain

13

Staff mengatur cabang

(Entiti) (tipe relasi) (Entiti)

Gambar 2.3 Relasi one-to-one antara cabang dan staff

Pada gambar diatas relasi yang terjadi adalah relasi one-to-one,

dimana setiap staff yang ada hanya mengatur satu cabang.

2. Relasi One-to-Many (1:*)

Relasi dimana setiap entiti yang ada dapat mempunyai satu

relasi atau lebih dari satu relasi dengan entiti yang lain

Staff Melayani konsumen

(Entiti) (tipe relasi) (Entiti)

Gambar 2.4 Relasi one-to-many antara staff dan konsumen

Pada gambar diatas relasi yang terjadi adalah relasi one-to-many,

dimana setiap staff dapat melayani lebih dari 1 konsumen.

14

3. Relasi Many-to-Many (*:*)

Relasi dimana setiap entiti dapat mempunyai lebih dari satu

relasi dengan entiti lainnya.

Koran mengiklankan Rumah

(Entiti) (tipe relasi) (Entiti)

Gambar 2.5 Relasi many-to-many antara koran dan iklan

Pada gambar diatas relasi yang terjadi adalah relasi many-to-

many, dimana setiap koran dapat mengiklankan lebih dari 1

rumah.

Cardinality dan Participation Constraints

Multiplicity terdiri dari dua batasan yaitu cardinality dan

participation. Cardinality menggambarkan jumlah maksimum

relasi yang mungkin terjadi dari sebuah entiti yang

berpartisipasi dalam tipe relasi. One-to-one (1:1), one-to-many

(1:*), dan many-to-many (*:*) merupakan cardinality dari

relasi binary. Participation menentukan apakah semua atau

hanya sebagian dari entiti yang berpartisipasi dalam relasi.

15

Gambar 2.6 Cardinality dan Participation antara Branch

dan Staff

2.1.6 Normalisasi

Normalisasi adalah suatu teknik untuk menghasilkan himpunan

relasi dengan properti yang diinginkan berdasarkan kebutuhan-kebutuhan

data suatu organisasi (Connolly and Begg, 2002, p376).

Tingkatan normalisasi yang digunakan sebagai landasan penulisan

skrpsi ini ada beberapa tahap, yaitu :

a. First Normal Form (1NF)

Suatu kondisi sebelum masuk ke proses normalisasi adalah

Unnormalized Form (UNF), yaitu kondisi dimana sebuah tabel

mengandung satu atau lebih repeating group (Connolly and Begg,

2002, p387). Sedangkan 1NF adalah relasi dimana gabungan dari

tiap kolom dan baris mengandung satu dan hanya satu nilai

16

(Connolly and Begg, 2002, p388).

Ada dua pendekatan untuk menghilangkan repeating

group pada tabel yang tidak normal, yaitu:

• Dengan memasukkan data yang sesuai ke dalam kolom

yang kosong dari baris yang mengandung data

berulang.

• Dengan menempatkan data yang berulang bersama

salinan atribut kunci pada relasi yang terpisah. Sebuah

primary key diidentifikasikan ke dalam relasi yang

baru.

b. Second Normal Form (2NF)

Yaitu relasi yang terdapat di dalam 1NF dan tiap atribut

non-primary key bersifat bergantung fungsional penuh terhadap

primary key (Connolly and Begg, 2002, p392).

c. Third Normal Form (3NF)

Yaitu relasi yang terdapat pada 1NF dan 2NF, dimana

tidak ada atribut non-primary key yang bergantung transistif

terhadap primary key (Connolly and Begg, 2002, p394).

17

2.1.7 Siklus Hidup Aplikasi Basis Data

Siklus hidup sebuah aplikasi basis data menurut Conolly dan Begg

(2002, p271) digambarkan sebagai berikut :

Gambar 2.7 The Stage of Database Application Lifecycle

18

Adapun penjelasan dari daur hidup diatas adalah :

1. Perencanaan Basis Data

Aktivitas manajemen yang memungkinkan tahapan dari

aplikasi basis data untuk dapat direalisasikan seefisien dan seefektif

mungkin. Perencanaan basis data juga meliputi pengembangan

standar pengumpulan data, penetapan format dan dokumentasi yang

diperlukan serta bagaimana desain dan implementasi diproses.

2. Definisi Sistem

Adalah menggambarkan lingkup (scope) dan batasan dari

aplikasi database dan user view utama.

User View mendefinisikan apa yang diperlukan dalam

aplikasi basis data dari sudut pandang peran pekerjaan tertentu

(misal manajer atau supervisor) atau area aplikasi enterprise (misal

marketing, personil, atau kontrol stok) (Connolly and Begg, 2002,

p275)

3. Analisa dan Pengumpulan Kebutuhan

Proses mengumpulkan dan menganalisa informasi mengenai

bagian dari organisasi yang akan didukung oleh aplikasi basis data,

dan menggunakan informasi ini untuk mengidentifikasi kebutuhan

pengguna sistem baru. (Connolly and Begg, 2002, p276)

Informasi tersebut diambil dari tiap user view yang penting,

dimana didalamnya termasuk :

a. Deskripsi tentang bagaimana data digunakan atau dibuat

b. Detil dari bagaimana data akan digunakan atau dibuat

19

c. Kebutuhan tambahan untuk aplikasi basis data baru

Ada 3 pendekatan utama untuk memenuhi kebutuhan

informasi dari aplikasi sistem basis data, yaitu :

1. Terpusat

Kebutuhan dari setiap pemakai digabung kedalam satu set

kebutuhan untuk aplikasi dari basis data.

2. Tinjauan terintegrasi

Kebutuhan dari setiap pemakai akan digunakan untuk

membangun model data yang terpisah untuk

merepresentasikan pandangan dari pemakai. Hasil dari

data model dapat digabungkan kemudian pada tahap

perancangan basis data.

3. Kombinasi dari 2 pendekatan

Dalam hal ini ada beberapa teknik untuk mendapatkan

analisa informasi yang dinamakan Fact Finding

Techniques

Terdapat lima teknik Fact Finding yang umum digunakan

a. Pemeriksaan Dokumentasi

b. Wawancara

c. Mengobservasi jalannya kegiatan kerja perusahaan

d. Penelitian

e. Kuisioner

4. Desain Basis Data

Sebuah proses dalam menciptakan rancangan desain untuk

20

basis data yang akan mendukung operasi dan tujuan dari

perusahaan.

Ada tiga fase utama dalam desain basis data , yaitu:

a. Desain konseptual basis data.

Proses membangun model data (data mode) dari informasi

yang diperoleh dalam sebuah organisasi, tetapi terbebas dari

semua pertimbangan fisik

b. Desain logikal basis data

Proses membangun sebuah model informasi yang diperoleh

dari sebuah organisasi berdasarkan model data yang khusus

(Specific data model), namun terbebas dari DBMS tertentu

dan pertimbangan fisik lainnya.

c. Desain fisikal basis data

Proses pembuatan deskrpsi dari suatu implementasi database

pada media penyimpanan (secondary storage) hal ini,

mendeskrpsikan hubungan utama, organisasi file, dan indeks

yang digunakan untuk mencapai efisiensi akses kedalam data,

dan hubungan integritas constraint (Associated integrity

constraints) yang lainnya dan hal yang berkaitan dengan

keamanan.

5. Penyeleksian DBMS

Proses Penyeleksian DBMS yang cocok untuk mendukung

aplikasi basis data.( Connolly and Begg, 2002, p284 )

Berikut ini adalah tahapan untuk menyeleksi basis data,

21

yaitu :

a. Membuat gambaran cakupan tugas berdasarkan kebutuhan

perusahaan

b. Membuat perbandingan mengenai dua atau tiga produk

c. Membuat evaluasi produk-produk DBMS yang dipilih

d. Membuat rekomendasi pemilihan DBMS dan membuat

laporan hasil evaluasi produk-produk DBMS tersebut

6. Desain Aplikasi

Pada tahap ini dilakukan proses mendesain antarmuka

pengguna dan program aplikasi yang menggunakan dan memproses

basis data.

Desain aplikasi dibagi menjadi dua aspek, yaitu :

a. Desain transaksi

Transaksi dapat juga diartikan sebagai sebuah atau

serangkaian aksi, yang dilakukan oleh seorang user atau

program aplikasi, yang mengakses atau mengubah isi dari basis

data (Connolly 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.

- Mixed Transaction, contohnya operasi untuk mencari detil

data properti, menampilkannya dan kemudian mengupdate

22

nilainya

b. Panduan Desain Antarmuka Pengguna

7. Prototyping

Menurut Connolly and Begg (2002, p291-292), prototyping

adalah proses membangun model kerja (working model) dari

aplikasi basis data, yang memperbolehkan perancang atau user

untuk mengevaluasi hasil akhir sistem, baik dari segi tampilan

maupun fungsi yang dimiliki sistem.

Tujuan dari prototype aplikasi basis data adalah untuk

memungkinkan pemakai menggunakan prototype untuk

mengidentifikasi keistimewaan sistem atau kekurangannya dan

apabila memungkinkan untuk dapat menyarankan improvisasi atau

bahkan membuat fitur baru ke aplikasi basis data

8. Implementasi

Menurut Connolly And Begg (2002, p292), Implementasi

adalah membuat definisi database secara eksternal, konseptual,

internal dan program aplikasi. Implementasi basis data dilakukan

dengan menggunakan Data Definition Language (DDL) dari

DBMS yang dipilih, atau dengan menggunakan Graphical User

Interface (GUI).

Pandangan dari pemakai (User View) diimplementasikan

juga pada tahapan ini. Bagian dari aplikasi program adalah transaksi

basis data yang diimplementasikan dengan mengunakan data

manipulation language (DML) dari sasaran DBMS, termasuk host

23

programming language seperti, Visual Basic, Delphi, C, C++,

JAVA dan Pascal

9. Loading dan Konversi Data

Pada tahap ini dilakukan pengambilan data dari sistem

yang lama untuk dipindahkan kedalam sistem yang baru. (Connolly

and Begg 2002, p292)

10. Testing

Yaitu proses menjalankan program aplikasi dengan tujuan

menemukan kesalahan – kesalahan.

Beberapa keuntungan melakukan testing :

a. Menemukan kesalahan (error) program aplikasi dan mungkin

juga kesalahan struktur basis data.

b. Mendemonstrasikan bahwa program aplikasi dan basis data

dapat berjalan sesuai dengan kebutuhan performa dan

spesifikasi yang diiginkan atau tidak.

11. Perawatan Operasional

Adalah proses memantau dan memelihara sistem setelah

dilakukannya proses instalasi (Connolly and Begg, 2002, p 293).

Pada tahap maintenance (perawatan) ini melibatkan beberapa

aktivitas :

a. Memantau kinerja sistem. Apabila performa berada di level

bawah, maka dibutuhkan tuning atau reorganisasi basis data

b. Memelihara dan meng-upgrade aplikasi basis data (apabila

dibutuhkan).

24

2.1.8 Desain Konseptual, Logikal dan Fisikal Basis Data

Terdapat tiga tahapan atau fase utama dalam perancangan basis

data (Connolly and Begg, 2002, p419), yaitu :

1. Desain Konseptual Basis data

Proses membangun model informasi yang digunakan dalam

sebuah organisasi, bebas dari semua pertimbangan fisik (Connolly

and Begg, 2002, p419). Pertimbangan fisik yang dimaksud meliputi

DBMS yang akan digunakan, program aplikasi, bahasa pemrograman,

platform perangkat keras, unjuk kerja, dan pertimbangan fisik

lainnya.

Pada konseptual basis data desain ini terdiri dari langkah-langkah

sebagai berikut :

Langkah 1: Membangun data model konseptual lokal untuk setiap

view

1.1 Mengidentifikasi tipe entiti

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). Alternatif lain adalah

dengan mencari obyek yang keberadaannya bebas.

1.2 Mengidentifikasi tipe relasi

Pada tahapan ini bertujuan untuk mengidentifikasi

relationship yang penting yang ada antara tipe entitas - tipe

25

entitas yang telah diidentifikasi sebelumnya. Tipe relationship

diidentifikasikan dengan mencari kata kerja atau suatu kata yang

berhubungan dengan kata kerja. Misalnya:

• Staff mengatur Property

• PrivateOwner mempunyai Property.

1.3 Mengidentifikasi dan menghubungkan atribut dengan entiti

atau tipe entiti

Pada 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/multi-valued attribute, dan derived attribute.

1.4 Menentukan domain atribut

Domain adalah sekumpulan nilai dimana satu atau lebih

atribut memperoleh nilainya (Connolly and Begg, 2002, p430).

Contoh menentukan domain pada atribut JenisKelamin di

entitas pegawai adalah dengan ‘L’ atau ’P’.

1.5 Menentukan candidate dan primary key dari attribut

Candidate key adalah set atribut minimal dari sebuah entiti

yang secara unik mengidentifikasi setiap kemunculan dari entiti

tersebut. Candidate key dapat diidentifikasikan lebih dari satu, tetapi

harus dipilih satu sebagai primary key, sedangkan candidate key yang

lain disebut alternate key.

26

Berikut adalah acuan dalam menentukan primary key dari

candidate key :

• Candidate key dengan set atribut yang minimal

• Candidate key dengan nilai yang berubah paling sedikit

• Candidate key dengan karakter paling sedikit

• Candidate key dengan isi maksimum yang paling sedikit

• Candidate key yang termudah digunakan dari sudut pandang

user

1.6 Mempertimbangkan penggunaan konsep model yang lebih

tinggi (enhanced modelling concepts) / optional

Tahap ini bersifat optional, apakah akan digunakan

pengembangan dari entiti model dengan menggunakan enhanced

modelling concepts, seperti spesialisasi/generalisasi

1.7 Memeriksa redudansi pada model

Tahapan ini memeriksa model data konseptual lokal apakah

terjadi duplikasi atau tidak dengan dua langkah yaitu

• 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.

27

Untuk meminimalkan data model maka relationship yang

redundan harus dihilangkan.

1.8 Memvalidasi model data konseptual lokal terhadap transaksi

user

Memeriksa model yang telah dihasilkan apakah

mendukung transaksi pada view (Connolly and Begg, 2002,

p435).

Pemeriksaan ini dapat menggunakan dua langkah yaitu :

• Mendeskripsikan transaksi

• Menggunakan jalur transaksi

1.9 Memeriksa model data konseptual lokal dengan user

Langkah ini dilakukan dengan tujuan untuk memastikan

bahwa data model merupakan representasi yang benar bagi setiap

pandangan.

2. Desain Logikal Basis Data

Proses membangun model informasi yang digunakan

dalam sebuah enterprise yang didasarkan pada data model spesifik,

dan terbebas dari DBMS dan semua pertimbangan fisik

Pada desain logikal basis data terdiri dari langkah-langkah

sebagai berikut :

Langkah 2: Membangun dan memvalidasi model data logikal lokal

untuk setiap view

28

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:

2.1 Menghilangkan hal-hal yang tidak sesuai dengan model

relational (optional)

Model data konseptual lokal yang telah ada dapat

mengandung struktur yang tidak dapat dimodelkan oleh DBMS

konvensional, oleh karena itu pada tahap ini dilakukan perubahan

menjadi bentuk yang lebih mudah ditangani oleh sistem ini.

Langkah-langkahnya antara lain :

• Menghilangkan relasi binary many-to-many (*:*)

• Menghilangkan relasi rekursif many-to-many (*:*)

• Menghilangkan tipe relasi yang kompleks

• Menghilangkan atribut multi-valued

2.2 Mendapatkan relasi untuk model data logikal

Membentuk relasi dari model data logikal lokal untuk

merepresentasikan relasi antar entiti dengan attribut yang telah

diidentifikasikan.

29

Untuk mendapatkan relasi dari data model yang ada maka

digunakan cara-cara berikut ini :

• Tipe entiti yang kuat

• Tipe entiti yang lemah

• Relasi binary one-to-many (1:*)

• Relasi binary one-to-one (1:1)

• Relasi recursive one-to-one (1:*)

• Tipe relasi superclass/subclass

2.3 Memvalidasi relasi menggunakan normalisasi

Normalisasi digunakan untuk meningkatkan model yang

telah terbentuk agar duplikasi data yang tidak diperlukan dapat

dihindari.

2.4 Memvalidasi relasi dengan transaksi user

Bertujuan untuk memastikan bahwa relasi-relasi pada

local logical data model mendukung transaksi-transaksi yang

dibutuhkan oleh pengguna, seperti terinci pada spesifikasi

kebutuhan pengguna.

2.5 Memdefinisikan integrity constraints

Integrity constraint adalah batasan-batasan yang harus

ditentukan untuk melindungi basis data agar tetap konsisten

(Connolly, 2002, p457).Ada 5 tipe integrity constraints :

• Required data (data/nilai yang valid)

• Batasan domain attribut

30

• Entity integrity (primary key tidak boleh null)

• Referential integrity (foreign key pada suatu entiti harus

sesuai dengan candidate key pada entiti lain)

• Enterprise constraint (batasan pada organisasi)

2.6 Meninjau kembali model data logikal lokal dengan user

Memastikan model data logikal lokal yang terbentuk

merupakan representasi dari user view. Untuk memvalidasi model

data logikal ini digunakan Data Flow Diagram (DFD). DFD dapat

menunjukkan aliran data dari suatu organisasi.

Langkah 3: Membangun dan validasi model data logikal global

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.

3.1 Menggabungkan model data logikal lokal ke dalam model

global

Menggabungkan model data logikal individual ke dalam

model data logikal global organisasi

3.2 Memvalidasi model data logikal global

Memvalidasi relasi yang telah dibuat dari model data

global menggunakan teknik normalisasi dan memastikan relasi ini

mendukung transaksi yang diperlukan. Langkah ini sama dengan

31

langkah 2.3 dan 2.4 yang memvalidasi setiap model data logikal

lokal

3.3 Memeriksa perkembangan yang akan datang

Bertujuan untuk memastikan apakah ada perubahan yang

signifikan yang dapat diperkirakan dan memastikan apakah model

data logikal global ini dapat mendukung perubahan-perubahan ini.

3.4 Memeriksa model data logikal global dengan user

Memastikan bahwa model data logikal global merupakan

representasi nyata dari organisasi

3. Desain Fisikal Basis Data

Proses memproduksi sebuah deskripsi dari implementasi

basis data dalam secondary storage, yang menjelaskan relasi dasar,

organisasi file, dan membuat indeks untuk mendapatkan akses yang

efisien ke data, serta setiap integrity constraint yang saling

berhubungan dan juga pengukuran sekuriti.

Pada desain fisikal basis data ini terdiri dari langkah-

langkah sebagai berikut :

Langkah 4: Menerjemahkan model data logikal global untuk

DBMS yang akan digunakan

Pada tahap ini akan dihasilkan suatu skema basis data

relasional dari model data logikal global yang dapat

diimplementasikan ke dalam DBMS yang akan digunakan

4.1 Mendesain relasi dasar (base relations)

32

Memutuskan bagaimana merepresentasikan relasi-relasi

yang telah diidentifikasikan pada model data logikal global pada

DBMS yang akan dipakai

4.2 Mendesain representasi dari data yang diturunkan

Memutuskan bagaimana merepresentasikan derived

attribut dalam model data logikal global pada DBMS yang akan

dipakai

4.3 Mendesain enterprise constraints

Menentukan enterprise constraint untuk target DBMS

Langkah 5: Mendesain gambaran fisik dari basis data

Menentukan organisasi file yang akan digunakan dan

indeks untuk menghasilkan performa yang diinginkan serta

menentukan apa saja yang akan disimpan dalam secondary storage.

5.1 Menganalisis transaksi

Memahami fungsi-fungsi dari transaksi yang akan

dijalankan pada basis data dan menganalisis transaksi yang penting

5.2 Memilih organisasi file yang akan digunakan

Menentukan organisasi file yang efisien. Ada 5 tipe

organisasi file :

• Heap

• Hash

• Indexed Sequential Access Method (ISAM)

33

• B-tree

• Clusters

5.3 Memilih indeks yang digunakan

Memutuskan apakah dengan menggunakan indeks akan

meningkatkan performa dari sistem.

5.4 Memperkirakan disk space yang diperlukan

Memperkirakan disk storage yang diperlukan untuk

menggunakan sistem basis data, disk stroge yang dimaksud adalah

secondary storage.

Langkah 6: Mendesain user view

Mendesain user view yang telah diidentifikasi.

Langkah 7: Mendesain pengukuran keamanan (security)

Membatasi pengaksesan basis data oleh user-user yang

tidak berhak dan menspesifikasi user terhadap basis data yang dapat

diakses.

Langkah 8: Menentukan apakah redundansi data telah dapat

dikontrol

Dilakukan normalisasi agar dapat meningkatkan

performa dari sistem dan menghilangkan redudansi.

Langkah 9: Memonitor Sistem Operasional

Memonitor dan meningkatkan performa dari sistem

dengan memperbaiki desain yang tidak sesuai atau perubahan

34

kebutuhan.

2.2. Teori Pendukung

2.2.1. Sumber Daya Manusia

Menurut Martoyo ( 1987 , p 5 ), Sumber daya manusia adalah

sumber daya yang timbul dari interaksi antara manusia yang selalu

mencari alat untuk mencapai tujuan dan sesuatu di luar manusia pada saai

ini di sebut “alam“.

2.2.2. Manajemen Sumber Daya Manusia

Menurut Martoyo ( 1987, p3 ) Manajemen sumber daya manusia

adalah bekerja dengan orang orang untuk menentukan,

menginterprestasikan dan mencapai tujuan tujuan organisasi dengan

pelaksaaan fungsi fungsi perencanaan ( planning ), Perorganisasian (

organizing ), penyusunan personalia atau kepegawaian ( staffing ),

pengarahan dan kepemimpinan ( Leading ) dan pengawasan (

Controlling ).

2.2.3. Perekrutan dan Seleksi

Menurut Martoyo ( 1987, p 39 ), dengan kesiapan landasan yang

mantap untuk menarik tenaga kerja, yakni mulai dengan analisa jabatan,

penyususnan deskripsi jabatan, spesialisasi jabatan sampai dengan

penarikan tenaga kerja dari sumber intern maupun ekstern, mulailah

dengan langkah “seleksi”. Dengan istilah “seleksi” di maksudkan

“pemilihan tenaga kerja” yang tersedia.

35

Menurut Gomes ( 195, p105 ), Rekrutment merupakan proses

mencari, menemukan dan menarik para pelamar untuk dipekerjakan

dalam dan oleh suatu organisasi.

2.2.4. Penggajian dan Pengupahan

Gaji menurut kamus Besar Bahasa Indonesia, adalah upah kerja

yang dibayar dalam waktu yang tetap. Balas jasa yang diterima pekerja

dalam bentuk uang berdasarkan waktu tertentu.

Menurut UU No. 13 ( ketentuan umum pasal 1 ) mengenai

ketenagakerjaan , upah adalah hak pekerja / buruh yang di terima dan di

nyatakan dalam bentuk uang sebagai imbalan dari pengusaha atau

pemberi kerja kepada pekerja / buruh yang di tetapkan dan di bayarkan

menurut surat perjanjian kerja, kesepakatan atau perundang undangan,

termasuk tunjangan bagi pekerja / buruh dan keluarganya atas suatu

pekerjaan dan / atau jasa yang telah di lakukannya .

2.2.5. Promosi

Menurut Siagian (1996,p169), promosi terjadi apabila seorang

pegawai dipindahkan dari suatu pekerjaan ke pekerjaan lain yang

tanggung jawabnya dan penghasilannya lebih besar. Promosi didasarkan

pada prestasi kerja menggunakan hasil penilaian atas hasil karya yang

sangat baik dalam promosi atau jabatan sekarang.

36

2.2.6. Pemberhentian Pegawai

Menurut UU No.13 ( ketentuan umum pasal 156 ) mengenai

pemutusan hubungan kerja, apabila terjadi pemberhentian pegawai oleh

perusahaan atau atas keinginan dari pegawai, maka perusahaan

diwajibkan membayar uang pesangon atau uang penghargaan masa kerja

sesuai dengan hak yang seharusnya diterima.

2.2.7. Waktu Kerja

Menurut UU No. 13 ( ketentuan umum pasal 77 ) mengenai

ketenagakerjaan, waktu kerja meliputi :

a. (tujuh) jam 1 (satu) hari dan 40 (empat puluh) jam 1 (satu) minggu

untuk 6 (enam) hari kerja dalam 1 (satu) minggu; atau

b. 8 (delapan) jam 1 (satu) hari dan 40 (empat puluh) jam 1 (satu)

minggu untuk 5( lima) hari kerja dalam 1 (satu) minggu.

2.2.8. Waktu Kerja Lembur

Menurut UU No. 13 ( ketentuan umum pasal 78 ) mengenai

ketenagakerjaan, waktu kerja lembur hanya dapat dilakukan paling

banyak 3 (tiga) jam dalam 1 (satu) hari dan 14 (empat belas) jam dalam 1

(satu) minggu.

2.2.9. Waktu Istirahat

Menurut UU No. 13 ( ketentuan umum pasal 79 ) mengenai

ketenagakerjaan, waktu istirahat dan cuti meliputi :

37

b. Istirahat anatara jam kerja, sekurang-kurangnya setengah jam setelah

bekerja selama 4 (empat) jam terus-menerus dan waktu istirahat

tersebut tidak termasuk jam kerja.

c. Istirahat mingguan 1 (satu) hari untuk 6 (enam) hari kerja dalam 1

(satu) minggu atau 2 (dua) hari untuk 5 (lima) hari kerja dalam 1

(satu) minggu.