bab 2 landasan teori - bina nusantara | library...

9

BAB 2

LANDASAN TEORI

2.1 Teori - Teori Umum

2.1.1 Pengertian Data

Menurut Turban, & Rainer (2009, p. 6), data adalah fakta mentah atau

deskripsi dasar dari benda, peristiwa, aktivitas dan transaksi yang

didapatkan, direkam, disimpan, diklasifikasi tetapi belum terorganisir

untuk menyampaikan suatu arti spesifik.

Menurut Conolly dan Begg (2010, p70), data merupakan komponen

yang paling penting dalam Database Management System (DBMS),

berasal dari sudut pandang dari end-user. Data berperan sebagai

penghubung antara mesin dengan pengguna.

Menurut Williams & Sawyer (2011, p. 25), data terdiri dari fakta –

fakta, dan gambaran mentah yang akan diproses menjadi informasi.

Data penting karena pengguna memerlukan data untuk membuat

informasi yang berguna.

2.1.2 Pengertian Basis Data (Database)

Menurut Thomas Connoly dan Carolyn Begg (2010, p.65), basis data

adalah sekumpulan data yang berelasi secara logikal dan deskripsi

dari data dirancang untuk memenuhi kebutuhan informasi dari sebuah

organisasi.

10

Menurut Thomas Connoly dan Carolyn Begg (2010, p.65), basis data

adalah tempat penyimpanan data tunggal (mungkin dalam skala besar)

yang dapat digunakan secara bersama – sama oleh banyak departemen

dan pengguna. Daripada menggunakan file – file yang berulang

(redundant) dan sama sekali tidak terhubung, basis data menyimpan

semua data yang terintegrasi dengan jumlah duplikasi data seminimal

mungkin. Selain menyimpan data operasional perusahaan, basis data

juga menyimpan deskripsi mengenai hal itu. Oleh karena itu, basis

data sering disebut dengan a self describing collection of integrated

records. Deskripsi mengenai data tersebut dikenal dengan kamus data

atau metadata.

Nadim Obeid and Raj B. K. N. Rao (2010: 129) mengatakan database

yang aktif adalah sistem manajemen database yang dapat melakukan

tindakan ketika beberapa peristiwa tertentu atau pola peristiwa yang

terdeteksi. Pada database yang aktif, merupakan kejadian yang

menarik yang dapat berupa primitif (misalnya menyimpan uang di

bank) atau komposit (Contoh: cash menyimpan di bank, diikuti

penarikan tunai dari bank).

2.1.3 Arsitektur Basis Data

Menurut Thomas Connoly dan Carolyn Begg (2010, p.86), 3 tiga level

arsitektur basis data (Three Level ANSI-SPARC Architecture) adalah:

a. External Level

11

External level merupakan apa yang dilihat oleh pengguna terhadap

basis. Level ini mendeskripsikan bagian basis data yang

berhubungan dengan tiap pengguna.

b. Conceptual Level

Conceptual level menggambarkan data apa saja yang disimpan

dalam basis data dan hubungan antara data tersebut.

c. Internal Level

Internal level merupakan representasi fisik dari basis data yang

ada di dalam komputer. Level ini menggambarkan bagaimana data

disimpan dalam suatu basis data.

Tujuan utama dari tiga level arsitektur basis data adalah untuk

mendapatkan arsitektur basis data adalah untuk mendapatkan data

independence. Dengan adanya data independence pada basis data,

data dapat diubah tanpa mempengaruhi aplikasi yang berhubungan

dengan basis data tersebut.

2.2 Teori-teori Khusus

2.2.1 Bahasa Sistem Basis Data

2.2.1.1 Data Definition Language (DDL)

Menurut Thomas Connolly dan Carolyn Begg (2010, p.92), data

Definition Language (DDL) adalah sebuah bahasa yang mengijinkan

Database Administrator (DBA) atau pengguna untuk menjelaskan

dan memberi nama pada entitas, atribut, dan hubungan yang

12

diperlukan untuk aplikasi, secara bersamaan dengan associated

intergrity dan security constraint.

2.2.1.2 Data Manipulation Language (DML)

Menurut Thomas Connolly dan Carolyn Begg (2010, p.92), data

Manipulation Language (DML) adalah sebuah bahasa yang

menyediakan satu set operasi untuk mendukung dasar dari operasi

manipulasi pada data yang disimpan pada basis data.

2.2.2 Database Management System (DBMS)

2.2.2.1 Pengertian DBMS

Menurut Thomas Connolly dan Carolyn Begg (2010, p.66), DBMS

adalah sebuah sistem software yang memungkinkan penggunanya

untuk mendefinisikan, membuat, memelihara, dan mengendalikan

akses ke basis data.

Menurut Dadashzadeh, Mohammad berdasarkan jurnal (Journal of

Information Systems Education, 2007), mengatakan pernyataan

DBMS yang didukung secara terbatas oleh semua perangkat lunak

DBMS saat ini. Khusus kemampuan untuk menunjuk primary key

tabel tidak lebih dari menyatakan kendala dan membiarkan DBMS

menegakkan selama update database.

13

2.2.2.2 Fungsi DBMS

Menurut Thomas Connolly dan Carolyn Begg (2010, p.99), fungsi

DBMS adalah:

- Menyimpan, memperoleh, dan meng-update data.

- Sebuah katalog yang bisa di akses oleh pengguna.

- Mendukung transaksi.

- Layanan kendali concurrency.

- Layanan recovery.

- Layanan authorization.

- Mendukung data komunikasi.

- Layanan integrity.

- Layanan untuk promote data independents.

- Layanan utility.

2.2.2.3 Fasilitas DBMS

Menurut Thomas Connolly dan Carolyn Begg (2010, p.66), DBMS

menyediakan pengendalian akses ke basis data yaitu:

- Sistem keamanan yang mencegah pemakai yang tidak memiliki

hak akses untuk mengakses basis data.

- Intergrity system yang menangani konsistensi data yang telah

disimpan.

- Sistem concurrency control yang mengijinkan untuk berbagi

akses dari basis data.

14

- Sistem recovery control yang memperbaiki basis data menjadi

seperti sebelumnya yang disebabkan karena adanya kegagalan

yang terjadi pada perangkat keras atau perangkat lunak.

- User–accessible catalog yang berisi tentang deskripsi dari data

yang telah tersimpan dalam basis data.

2.2.2.4 Komponen Lingkungan DBMS

Menurut Thomas Connolly dan Carolyn Begg (2010,p.68), komponen

lingkungan DBMS terdiri dari:

- Hardware

DBMS dan aplikasi memerlukan hardware agar dapat dijalankan.

Beberapa DBMS hanya dapat bekerja pada hardware atau sistem

operasi tertentu. DBMS juga membutuhkan sejumlah minimum

dari main memory dan space disk untuk bekerja.

- Software

Komponen software terdiri dari software DBMS itu sendiri dan

program aplikasi, bersama dengan sistem operasi, termasuk

network software jika DBMS digunakan pada jaringan.

- Data

Mungkin komponen yang paling penting dari lingkungan DBMS

dari pandangan end-user adalah data. Data bertindak sebagai

jembatan antara komponen mesin dan komponen manusia. Basis

data memiliki baik data operasional dan meta-data.

- Prosedur

15

Prosedur merujuk pada instruksi dan peraturan yang mengatur

rancangan dan kegunaan dari basis data. Pengguna dari sistem dan

staff yang mengatur basis data memerlukan dokumentasi prosedur

tentang bagaimana menggunakan atau menjalankan sistem.

- Manusia

Komponen manusia terdiri dari:

1. Data administrator adalah orang yang bertanggung jawab

untuk pengaturan dari sumber data, termasuk perencanaan

basis data, pengembangan dan pemeliharaan, kebijakan dan

prosedur, dan desain konseptual/logikal basis data.

2. Database administrator adalah orang yang bertanggung jawab

untuk realisasi fisikal dari basis data, termasuk desain fisikal

basis data dan implementasi, kontrol keamanan dan integritas,

memelihara sistem operasional, memastikan kepuasan

pengguna untuk peforma dari aplikasi.

3. Database designer terbagi menjadi dua yaitu logical database

designer dan physical database designer.

a. Logical database designer adalah orang yang

mengidentifikasi data (entitas dan atribut), hubungan antar

data, constraint data yang disimpan dalam basis data.

Logical database designer harus memiliki secara

menyeluruh dan mengerti sepenuhnya tentang data

organisasi dan constraint dari data (constraint ini

terkadang disebut dengan peraturan bisnis). Peraturan

16

bisnis menggambarkan karakteristik utama dari data yang

dilihat oleh perusahaan.

b. Physical database designer adalah orang yang

memutuskan bagaimana basis data logical direalisasikan

secara physical.

2.2.2.5 Pemilihan DBMS

Menurut Thomas Connolly dan Carolyn Begg (2010, p.325-329),

pemilihan DBMS merupakan pemilihan dari ketepatan DBMS yang

mendukung sistem basis data. Dalam memilih DBMS perlu

melakukan langkah – langkah sebagai berikut :

1. Mendefinisikan kerangka yang digunakan untuk acuan studi

terlebih dahulu

Kerangka yang menjadi acuan untuk pemilihan DBMS dibangun,

menyatakan tujuan, batasan dari pelajaran, serta tugas – tugas

yang perlu untuk diambil alih.

2. Persiapan dua atau tiga produk

Kriteria cenderung menjadi “penting” untuk sebuah implementasi

yang bisa digunakan untuk menghasilkan sebuah daftar

pendahuluan dari produk DBMS untuk evaluasi.

3. Mengevaluasi produk – produk

Ada fitur yang beragam yang dapat digunakan untuk

mengevaluasi sebuah produk DBMS untuk tujuan evaluasi, fitur

tersebut bisa melakukan analisis secara kelompok maupun

individual.

17

4. Merekomendasikan pilihan – pilihan menghasilkan laporan

Langkah terakhir dari pemilihan DBMS adalah untuk

merekomendasikan dari proses – proses dan untuk menyediakan

sebuah pernyataan dari menemukan dan merekomendasikan untuk

produk DBMS.

2.2.3 Tahapan Perancangan Basis Data

2.2.3.1 The Database Application Lifecycle


untuk merancang aplikasi sistem basis data diperlukan tahapan –

tahapan yang dinamakan dengan siklus hidup aplikasi basis data

(Database Application LifeCycle). Tahapan – tahapan ini dapat dilihat

pada gambar 2.1.

18

Gambar 2.1 Database Application LifeCycle

1. Perancangan Model Basis Data

Menurut Connolly dan Begg (2010, p313), perencanaan basis data

(database planning) merupakan perencanaan bagaimana setiap

tahapan dari siklus dapat direalisasikan menjadi lebih efisien dan

efektif. Perencanaan basis data harus dapat terintegrasi dengan

sistem informasi perusahaan secara umum. Beberapa hal yang

terlibat dalam formula adalah strategi sistem informasi, yaitu :

19

1. Identifikasi dari rencana dan tujuan perusahaan dengan

menentukan kebutuhan sistem informasi.

2. Evaluasi sistem informasi yang sedang berjalan untuk

menentukan kelebihan dan kekurangan.

3. Penilaian dari keuntungan teknologi informasi yang dapat

member keuntungan kompetitif.

a. System Definition

Menurut Connolly dan Begg (2010, p316), definisi sistem adalah

mendeskripsikan cakupan dan batasan dari aplikasi basis data, baik

pengguna dan area aplikasi tersebut. Sebelum mencoba untuk

merancang aplikasi basis data, pertama – tama harus

mengidentifikasi batasan dari sistem yang akan kita investigasi dan

bagaimana membuat antarmuka dengan sistem informasi tiap

bagian dalam organisasi. Dalam mendefinisikan sistem, harus

ditentukan oleh user view, yaitu mendefinisikan apa yang

dibutuhkan oleh aplikasi basis data berdasarkan pandangan dari

tiap bagian tugas (misalnya manager atau supervisor) atau area

aplikasi perusahaan (misalnya marketing, personnel, atau stock

control).

b. Requirement Collection and Analysis

Menurut Connolly and Begg (2010, p316), analisis data dan

pengumpulan kebutuhan adalah proses mengumpulkan dan analisis

informasi tentang bagian dari organisasi yang dapat didukung oleh

aplikasi basis data, dan menggunakan informasi tersebut untuk

mengidentifikasi kebutuhan pengguna dari sistem baru. Banyak

20

teknik yang dapat dilakukan untuk mengumpulkan informasi

tersebut, disebut teknik fact finding. Informasi yang dikumpulkan

untuk setiap user view, mencakup :

1. Deskripsi data yang digunakan.

2. Rincian mengenai bagaimana data dapat digunakan atau

dihasilkan.

3. Kebutuhan tambahan lainnya untuk aplikasi basis data yang

baru.

Informasi ini selanjutnya dianalisis untuk mengidentifikasi

kebutuhan yang dapat dimasukkan ke dalam aplikasi basis data

baru. Kebutuhan ini dideskripsikan ke dalam dokumen bersama

sebagai requirement specifications untuk aplikasi basis data baru.

Ada 3 pendekatan untuk mengelola kebutuhan dari aplikasi basis

data dengan banyak user view, yaitu :

1. The centralized approach : kebutuhan dari setiap user view

digabung menjadi sebuah set kebutuhan dari aplikasi basis data.

2. The view integration approach : kebutuhan dari setiap user view

digunakan untuk membangun model data secara terpisah untuk

merepresentasikan user view tersebut. Model data yang

dihasilkan tersebut nantinya akan digabungkan pada tahapan

database.

3. Kombinasi dari dua pendekatan di atas.

c. Database Design

Menurut Connolly dan Begg (2010, p320), database design adalah

proses membuat perancangan basis data yang dapat mendukung

21

pekerjaan dan tugas perusahaan. Menurut Connolly dan Begg

(2010, p322), perancangan basis data ini memiliki tiga tahapan,

yaitu:

1. Perancangan basis data konseptual, yaitu proses membangun

sebuah model informasi yang digunakan di sebuah

perusahaan, terbebas dari segala pertimbangan fisik.

2. Perancangan basis data logikal, yaitu proses membangun

sebuah model informasi yang digunakan di sebuah perusahaan

berdasarkan pada sebuah model data yang spesifik, tetapi

terbatas dari DBMS tertentu dan pertimbangan –

pertimbangan fisikal lainnya.

3. Perancangan basis data fisikal, yaitu proses menghasilkan

sebuah deskripsi dari pengimplementasian basis data pada

media penyimpanan sekunder, yang mendeskripsikan

hubungan dasar, pengorganisasian file, dan indeks yang

digunakan untuk memperoleh akses data secara efisien serta

segala batasan integritas dan ukuran – ukuran keamanan yang

berhubungan.

Menurut Connoly dan Begg (2010. P321), ada 4 pendekatan

dalam desain basis data yaitu :

1. Top-Down

Diawali dengan pembentukan model data yang berisi

beberapa entitas high-level dan relationship, yang

kemudian menggunakan pendekatan top-down secara

22

berturut – turut untuk mengidentifikasi entitas lower level,

relationship dan atribut lainnya.

2. Bottom-up

Dimulai dari atribut dasar yaitu sifat – sifat entitas dan

relationship, dengan analisis dari penggabungan antar

atribut, yang dikelompokan ke dalam suatu relasi yang

merepresentasikan tipe dari entitas dan relationship antar

entitas.

3. Inside-out

Berhubungan dengan pendekatan bottom-up tetapi sedikit

berbeda dengan identifikasi awal entitas utama dan

kemudian menyebar ke entitas, relationship, dan atribut

terkait lainnya yang lebih dulu diidentifikasi.

4. Mixed

Mengunakan pendekatan bottom-up dan top-down untuk

bagian yang berbeda sebelum pada akhirnya

digabungkan.

d. DBMS Selection

Menurut Connolly dan Begg (2010, p325), pemilihan DBMS yang

sesuai untuk mendukung aplikasi basis data yang mencakup :

1. Mendefinisikan syarat – syarat referensi studi. Menentukan

sasaran, batasan masalah dan tugas yang harus dilakukan.

2. Mendaftarkan 2 atau 3 jenis barang. Membuat daftar barang –

barang, misalkan dari mana barang ini didapat, berapa

biayanya serta bagaimana bila ingin mendapatkannya.

23

3. Mengevaluasi barang – barang yang ada dalam daftar diteliti

lebih lanjut untuk mengetahui kelebihan dan kekurangan

barang tersebut.

4. Merekomendasikan pilihan dan membuat laporan

merupakan langkah terakhir dari DBMS yaitu

mendokumentasikan proses dan untuk menyediakan

pernyataan mengenai kesimpulan dan rekomendasi terhadap

salah satu produk DBMS.

e. Application Design

Menurut Connolly dan Begg (2010, p329), perancangan aplikasi

adalah merancang antarmuka pemakai (user interface) dan

program aplikasi, yang akan memproses basis data. Dalam

merancang aplikasi harus memastikan semua pernyataan

fungsional dari spesifikasi kebutuhan pemakai (user requirement

specification) yang menyangkut perancangan aplikasi program

yang mengakses basis data dan merancang transaksi yaitu cara

akses ke basis data dan perubahan terhadap isi basi data (retrieve,

update dan kegiatan keduanya). Artinya bagaimana fungsi yang

dibutuhkan dengan cara untuk menciptakan user friendly.

f. Prototyping

Menurut Connolly dan Begg (2010, p333), pengertian prototyping

adalah membuat model kerja dari aplikasi basis data, yang

memperbolehkan perancang atau user untuk mengevaluasi hasil

akhir sistem, baik dari segi tampilan maupun fungsi yang dimiliki

sistem. Tujuan utama dari mengembangkan suatu prototype

24

adalah mengijinkan user untuk menggunakan bentuk dasar guna

mengidentifikasi corak sistem apakah bekerja dengan baik dan

jika mungkin meningkatkan corak baru kepada aplikasi basis data.

Dengan cara ini, kebutuhan dari pemakai dan pengembang sistem

dalam mengevaluasi kelayakan design sistem akan semakin jelas

sehingga kelebihan atau kekurangan sistem dapat ditangani

dengan baik.

Strategi prototyping yang umum digunakan ada dua, yaitu

requirement dan evolutionary prototyping. Requirement

prototyping adalah menggunakan bentuk dasar untuk menetapkan

kebutuhan dari tujuan aplikasi basis data dan ketika kebutuhan

sudah terpenuhi, prototype tidak digunakan lagi atau dibuang.

Sedangkan evolutionary prototype menggunakan tujuan yang

sama, tetapi perbedaaannya adalah prototype tetap digunakan

untuk selanjutnya dikembangkan menjadi aplikasi basis data yang

lengkap.

g. Implementation

Menurut Connolly dan Begg (2010, p333), implementation

merupakan realisasi secara fisik dari database dan desain aplikasi.

Pada tahap penyelesaian desain, kini kita dapat menerapkan basis

data dan program aplikasi yang telah kita buat. Implementasi basis

data menggunakan DDL yang kita pilih dalam melakukan

pemilihan DBMS atau dengan menggunakan Graphical User

Interface (GUI), yang menyediakan fungsional yang sama dengan

pernyataan DDL yang low level. Pernyataan DDL digunakan

25

untuk menciptakan struktur basis data dan mengosongkan file

yang terdapat dalam basis data tersebut. Pandangan pemakai

lainnya juga diimplementasikan dalam tahapan ini. Data

Manipulation Language (DML) digunakan untuk

mengimplementasikan transaksi basis data di dalam bagian

aplikasi program dari sasaran DBMS, mungkin termasuk host

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

Java, COBOL, dan Pascal.

h. Data Conversion and Loading

Menurut Connolly dan Begg (2010, p 334), data conversion and

loading adalah mencakup pengambilan data dari sistem lama

untuk dipindahkan ke dalam sistem yang baru. Langkah ini

diperlukan hanya ketika suatu sistem basis data baru sedang

menggantikan sistem yang lama. Sekarang, DBMS yang memiliki

kegunaan yang dapat mengisi file yang ada ke dalam sistem yang

baru telah dianggap umum, kegunaan yang ada umumnya

memerlukan spesifikasi sumber file dan target basis data yang

baru. Ketika conversion and loading dibutuhkan, prosesnya harus

direncanakan untuk memastikan kelancaran transaksi untuk

keseluruhan operasi.

i. Testing

Menurut Connolly dan Begg (2010, p334), testing adalah suatu

proses melaksanakan program aplikasi dengan tujuan menemukan

kesalahan sebelum diterapkan dalam suatu sistem, basis data harus

dilakukan testing terlebih dahulu. Hal ini dicapai dengan

26

penggunaan secara hati – hati untuk merencanakan suatu test dan

data yang realistis sedemikian sehingga keseluruhan proses

pengujian sesuai dengan metode dan dilaksanakan sesuai aturan

yang ada.

j. Operational Maintenance

Menurut Connolly dan Begg (2010, p335), operational

maintenancne adalah proses memantau dan memelihara sistem

setelah di-install. Pada tahapan sebelumnya, basis data benar –

benar diuji dan diimplementasikan. Sekarang sistem beralih ke

tahapan pemeliharaan. Yang termasuk aktivitas dari tahapan ini

adalah sebagai berikut :

- Memantau kinerja dari sistem. Jika kinerjanya menurun

dibawah level yang dapat diterima, mungkin basis data perlu

diorganisasi.

- Pemeliharaan dan upgrade aplikasi basis data (jika

diperlukan). Ketika basis data sepenuhnya bekerja,

pemantauan harus memastikan kinerja hanya dapat berada

dalam tingkat yang diterima. Sebuah DBMS biasanya

menyediakan berbagai kegunaan (utilities) untuk membantu

administrasi basis data termasuk kegunaan untuk mengisi data

kedalam basis data dan untuk memberikan informasi seperti

pemakaian basis data dan strategi eksekusi query. Basis data

administrasi dapat menggunakan informasi ini untuk

memperbaiki sistem agar dapat memberikan kinerja yang lebih

baik.

27

2. Perancangan User Interface

Membuat rancangan user interface untuk aplikasi basis data

manajemen proyek menggunakan C# sesuai dengan permintaan

perusahaan.

2.2.3.2 Tahapan Konseptual


langkah – langkah membangun conceptual database design yaitu:

1. Membangun data model konseptual untuk setiap view.

a. Mendefinisikan tipe entitas

Cara alternatif yang dipakai adalah dengan cara

mendefinisikan entitas untuk mencari objek yang dibutuhkan

oleh pemakai. Pada metode ini perlu untuk

mengidentifikasikan entitas – entitas yang ada untuk

memeriksa keperluan pemakai secara spesifik.

b. Mendefinisikan tipe relationship

Pada kenyataannya catatan keperluan yang spesifik adalah

adanya saran untuk relationship dimana catatan – catatan

tersebut penting untuk perusahaan dan terdapat pada model.

c. Identifikasi dan asosiasi atribut dengan entitas atau tipe

relationship

Metode ini mengidentifikasikan tipe – tipe dari kenyataan

yang ada tentang entitas – entitas dan relationship yang telah

dipilih untuk direpresentasikan pada basis data.

d. Menentukan domain atribut

28

Domain merupakan kumpulan dari nilai – nilai dimana

terdapat satu atau lebih atribut yang tergambar dalam nilai

atribut itu sendiri. Untuk mengembangkan data model secara

spesifik termasuk:

• Mengijinkan kumpulan nilai untuk atribut.

• Ukuran dan bentuk atribut.

Implementasi dari karakteristik domain pada DBMS masih

menjadi subjek dari penelitian. Atribut domain berisi

indentifikasi atribut domain tersebut, catatan nama atribut

domain tersebut, dan karakteristik yang terdapat dalam kamus

data.

e. Menentukan atribut candidate, primary, dan alternate key

Pada metode ini, memilih primary key diantara candidate key

sangat penting sehingga diperlukan pedoman untuk dapat

membantu membedakan key tersebut.

f. Mempertimbangkan penggunaan konsep enhanced modeling

(optional)

Pada metode ini, kita memiliki pilihan untuk melanjutkan

pengembangan dari ER model menggunakan konsep modeling

tingkat lanjut (specification, generalization, aggregation, dan

compotition).

g. Memeriksa ulang model – model untuk redudansi

Pada tahap ini, perlu dilakukan pemeriksaan model konseptual

data dengan objek identifikasi yang lebih spesifik dimana

terdapat model yang redudansi dan menghilangkan yang ada.

29

3 (tiga) aktivitas yang perlu dilakukan pada langkah ini

adalah:

• Meninjau kembali one–to–one relationship (1:1).

• Menghilangkan relationship yang redudansi.

• Mempertimbangkan dimensi waktu.

h. Memvalidasikan model data konseptual dengan transaksi user

Pada tahap ini terdapat dua pendekatan yang mendukung

model konseptual data untuk pemakaian transaksi yaitu:

• Menjelaskan transaksi.

• Menggunakan pathway transaksi.

i. Meninjau model data konseptual dengan pemakai

Pada tahap ini perlu dilakukan pengulangan dengan pemakai.

Model konseptual termasuk ER diagram dan mendukung

dokumentasi yang menjelaskan tentang data model. Titik

tahapan ini perlu ditinjau secara berulang – ulang. Proses

pengulangan ini akan berhenti apabila pemakai menyediakan

model yang telah disetujui sehingga tidak perlu melakukan

pengulangan karena representasi tersebut telah disepakati

bersama.

2.2.3.3 Tahapan Logikal


langkah-langkah membangun logical database design adalah :

1. Membangun data model logikal

a. Menurunkan relasi untuk data model logikal

30

Tahap ini bertujuan untuk membuat relasi data model logikal

untuk merepresentasikan entitas, hubungan, atribut yang telah

diidentifikasi.

b. Memvalidasikan relasi menggunakan normalisasi

Tahap ini bertujuan untuk memvalidasi relasi pada data model

logikal menggunakan normalisasi. Tujuan dari normalisasi

adalah untuk memastikan bahwa set dari relasi memiliki

jumlah artibut minimal yang cukup untuk mendukung

kebutuhan dari perusahaan.

c. Memvalidasikan hubungan dengan transaksi user

Tahapan ini diperlukan untuk memastikan hubungan pada

model data logikal yang mendukung transaksi yang

dibutuhkan. Pada tahapan ini hubungan yang dibuat pada

tahap sebelumnya dalam transaksi yang ada perlu ditinjau

kembali sehingga dapat memastikan bahwa tidak ada

kesalahan yang muncul pada saat membuat relations.

d. Mengecek integrity constraint

Tahap ini bertujuan untuk memeriksa apakah integrity

constraint terdapat pada data model logikal. Integrity

constraint merupakan constraint yang menentukan penjagaan

keamanan basis data dari ketidaksempurnaan, ketidakakuratan,

ataupun ketidakkonsistensian.

e. Meninjau kembali data model lokal logikal dengan transaksi

pengguna

31

Tahap ini bertujuan untuk meninjau kembali data model lokal

logikal dengan pengguna untuk memastikan data model

merupakan representasi nyata dengan kebutuhan data

perusahaan.

f. Menggabungkan data model logikal ke dalam data model

global (optional)

Tujuan pada tahap ini adalah untuk menggabungkan data

model lokal logikal ke dalam sebuah data model global logikal

yang merepresentasikan semua user view pada basis data.

Langkah – langkah pada tahap ini :

• Menggabungkan data model logikal kedalam data model

global logikal.

• Validasi data model global logikal.

• Meninjau kembali data model global logikal dengan user.

g. Cek untuk perkembangan di masa depan

Tahap ini bertujuan untuk menentukan apakah ada perubahan

secara besar pada masa depan dan untuk memperkirakan

apakah data model logikal dapat mengakomodasi perubahan

tersebut.

2.2.3.4 Tahapan Fisikal


langkah-langkah membangun physical database design adalah:

1. Menerjemahkan data model global logikal untuk DBMS tujuan.

a. Merancang relasi dasar

32

Mengidentifikasi logikal data model pada DBMS. Untuk

membuat proses rancangan fisikal, harus menyusun dari

hubungan yang dihasilkan dari data model logikal.

b. Merancang representasi dari data turunan

Langkah ini bertujuan untuk menentukan bagaimana

merepresentasikan data turunan yang ada pada data model

global logikal pada DBMS tujuan.

c. Merancang constraint perusahaan

Tahap ini bertujuan untuk merancang constraint perusahaan

bagi DBMS tujuan.

2. Merancang organisasi file dan index

a. Menganalisa transaksi

Tahap ini bertujuan untuk mengetahui kegunaan dari transaksi

yang akan berjalan pada basis data untuk menganalisa

transaksi yang penting.

b. Memilih organisasi file

Tahap ini bertujuan untuk menentukan organisasi file yang

efisien untuk setiap relasi dasar.

c. Memilih indexes

Tahap ini bertujuan untuk menentukan apakah dengan

menambahkan index akan meningkatkan performa dari sistem.

d. Memperkirakan kebutuhan disk-space

Tahap ini bertujuan untuk memperkirakan jumlah dari disk-

space yang akan diperlukan oleh basis data.

e. Merancang user view

33

Dalam merancang user view yang diidentifikasi selama

pengumpulan persyaratan dan menganalsis tahap – tahap pada

sistem basis data.

f. Merancang mekanisme keamanan

Basis data merepresentasikan sumber daya yang berhubungan

dengan undang – undang atau hukum yang diperlukan. Pada

metode ini diperlukan dokumentasi dari keperluan sistem

secara spesifik. Pada metode ini, perancang basis data harus

menyadari fasilitas yang ditawarkan oleh target DBMS.

Keamanan pada basis data memiliki dua tipe yaitu:

• Keamanan sistem yang menangani akses dan kegunaan

basis data pada level sistem seperti username dan

password.

• Keamanan data yang menangani akses dan kegunaan objek

dari basis data (seperti relation dan view) dan tindakan dari

pemakai yang memakai objek.

2.2.4 Normalisasi

Menurut Thomas Connolly dan Carolyn Begg (2010, p.416),

normalisasi adalah suatu teknik yang menghasilkan satu set relasi

dengan properties yang diinginkan, yang memberikan kebutuhan data

organisasi. Suatu desain basis data harus dipastikan tidak

mengandung anomaly, yaitu kejanggalan yang tejadi dalam

penempatan artibut tertentu dari suatu obyek data. Setiap record yang

34

ada di basis data dibedakan dengan sebuah atribut atau kombinasi

atribut yang disebut primary key (kunci primer).

Menurut Thomas Connolly dan Carolyn Begg (2010, p.430),

Unnormalized Form (UNF) adalah suatu label yang terdiri dari satu

atau beberapa kelompok data berulang (repeating group).

Tujuan dari normalisasi adalah:

1. Meminimalkan data yang rangkap.

2. Menghindari adanya data yang tidak konsisten bila terjadi

penambahan dan penghapusan data sebagai akibat data yang

rangkap.

3. Menjamin bahwa identitas tabel secara tunggal sebagai

determinan semua atribut.


normalisasi terdiri dari beberapa tahap, yaitu:

1. First Normal Form (1NF)

Suatu relasi dikatakan 1NF bila titik temu pada setiap kolom dan

baris relasi tersebut mengandung satu dan hanya satu nilai. Sebuah

relasi dapat dikatakan berada pada bentuk 1NF jika repeating

group dihilangkan. Ada 2 (dua) pendekatan yang digunakan untuk

menghilangkan repeating group tersebut, yaitu :

a. Dengan memasukkan data yang sesuai ke dalam kolom yang

kosong dan baris yang mengandung kata yang berulang.

35

b. Dengan menempatkan data yang berulang selama salinan dari

atribut kunci pada relasi yang terpisah.

2. Second Normal Form (2NF)

Suatu relasi dapat dikatakan bentuk 2NF jika relasi tersebut

berada pada bentuk 1NF dan setiap atribut yang bukan primary

key bergantung sepenuhnya (fully functionally dependent)

terhadap primary key.

Fully functionally dependent menjelaskan hubungan diantara

atribut-atribut dalam relasi. Sebagai contoh, jika A dan B adalah

atribut dalam relasi R, maka B adalah functionally dependent A

(A→B). Jika setiap nilai dari A berasosiasi tepat satu dengan nilai

dari B, maka A dan B mungkin mengandung satu atau lebih

atribut.

3. Third Normal Form (3NF)

Suatu relasi dapat dikatakan 3NF jika relasi tersebut berada pada

bentuk 1NF dan 2NF serta tidak ada atribut yang bukan primary

key bergantung transitif.

Ketergantungan transitif adalah suatu suatu kondisi dimana A, B,

dan C adalah atribut dari sebuah relasi. Jika A→B dan B→C,

maka C bergantung pada A melalui B (A tidak fully dependent

pada B ataupun C).

2.2.5 Entitiy Relationshiop Modeling (ERM)

Menurut Thomas Connolly dan Carolyn Begg (2010, p.371), ERM

adalah salah 1 (satu) model yang dapat digunakan untuk mendapatkan

36

pengertian yang tepat dari sifat data dan bagaimana data tersebut

dapat digunakan oleh perusahaan.

ERM menggunakan pendekatan top-down dalam melakukan

perancangan basis data. Dengan melakukan pendekatan top-down ini,

perancangan dimulai dengan mengidentifikasi data penting yang

biasanya disebut sebagai entity dan perancangan hubungan antar data

yang direpresentasikan dalam model yang biasanya disebut

relationship.

2.2.5.1 Entity Types

Menurut Thomas Connolly dan Carolyn Begg (2010, p.372), entity

types adalah sekumpulan obyek dengan properti yang sama yang

diidentifikasi oleh perusahaan dan memiliki keberadaan yang

independen.

Gambar 2.2 Representasi Diagram dari Entity

Menurut Thomas Connolly dan Carolyn Begg (2010, 373), entity

occurence adalah suatu obyek dari entity type yang diidentifikasikan

secara unik.

Menurut Thomas Connolly dan Carolyn Begg (2010, p.383), entity

type dapat diklasifikasikan menjadi 2 (dua) yaitu:

37

1. Strong Entity

Strong entity adalah entity type yang keberadaannya tidak

bergantung pada entity type lainnya.

2. Weak Entity

Weak Entity merupakan kebalikan dari strong entity yaitu entity

type yang keberadaannya bergantung pada entity type lainnya.

2.2.5.2 Relationship Types

Menurut Thomas Connolly dan Carolyn Begg (2010, p.374), relationship

types adalah sekumpulan asosiasi diantara entity types.

Gambar 2.3 Representasi Diagram dari Relationship


relationship occurance adalah sekumpulan asosiasi yang

diidentifikasi secara unik, termasuk 1 (satu) kejadian/occurance dari

masing – masing entity types yang berpartisipasi. Derajat tipe

relationship adalah jumlah tipe entitas yang berpartisipasi dalam suatu

relationship. Derajat relationship terdiri dari :

• Binary relationship adalah hubungan antara 2 tipe entitas.

• Ternary relationship adalah hubungan antara 3 tipe entitas.

38

• Quarternary relationship adalah hubungan antara 4 entitas.

• Recrusive relationship adalah tipe relationship dimana tipe

entitas yang sama berpartisipasi lebih dari satu dalam role

yang berbeda.

Inti utama dari suatu relationship adalah multiplicity. Multiplicity

adalah jumlah atau hasil dari kejadian yang mungkin terjadi pada

sebuah entitas yang dapat menghubungkan ke kejadian tunggal dari

suatu tipe entitas yang berhubungan melalui particular relationship.

Beberapa jenis multiplicity adalah :

• Hubungan One – to – One (1:1)

• Hubungan One – to – Many (1:*)

• Hubungan Many – to – Many (*:*)

2.2.5.3 Attribute


attribute merupakan properties/sifat dari suatu entity type atau

relationship type.

Arrtibute domain adalah sekumpulan nilai yang diijinkan untuk 1

(satu) atau beberapa attribute. Attribute dapat dibedakan menjadi 4

(empat) jenis, yaitu:

1. Simple dan Composite Attributes

Simple attribute adalah atribut yang terdiri dari 1 (satu) komponen

tunggal yang keberadaannya independen. Atribut ini sering

disebut juga sebagai atomic attribute. Simple attribute tidak dapat

dibagi lagi menjadi komponen yang lebih kecil.

39

Composite attribute adalah atribut yang terdiri dari banyak

komponen yang keberadaannya independen. Atibut ini dapat

dibagi menjadi komponen lain yang lebih kecil, yang masing-

masing memiliki keberadaan yang independen.

2. Single-Valued dan Multi-Valued Attributes

Single-valued attribute adalah atribut yang memiliki nilai tunggal

untuk setiap kejadian/occurence pada setiap entity. Multi-valued

attribute adalah atribut yang memiliki banyak nilai/occurence

pada setiap entity.

3. Derived Attributes

Derived attribute adalah atribut yang nilainya dihasilkan dari satu

atau beberapa atribut lainnya dan tidak harus berasal dari entity

yang sama.

4. Keys

a. Candidate Key

Candidate key merupakan sejumlah kecil atribut dari suatu

entity yang dapat mengidentifikasikan secara unik suatu

kejadian dari entity tersebut. Candidate key tidak boleh berupa

null.

b. Primary Key

Primary key merupakan candidate key yang dipilih untuk

mengidentifikasikan secara unik setiap kejadian pada entity

tersebut. Pemilihan primary key pada suatu entity didasarkan

pada pertimbangan panjang atribut, jumlah minimal atribut

yang dibutuhkan serta keunikannya. Candidate key yang tidak

40

dipilih menjadi primary key pada suatu entity disebut alternate

key.

c. Composite Key

Composite key adalah candidate key yang terdiri dari 2 (dua)

atau lebih atribut.

d. Foreign Key

Foreign key adalah sebuah atribut atau sekumpulan atribut

pada suatu relasi yang sesuai dengan candidate key yang ada

di relasi yang sama ataupun relasi lainnya.

2.2.5.4 Spesialisasi/ Generalisasi (Specialization/Generalization )


konsep dari spesialisasi dan generalisasi adalah asosiasi tipe entitas

dengan tipe entitas khusus yang dikenal sebagai superclass dan

subclass, dan proses dari atribut turunan (inheritance).

Superclass adalah suatu tipe entitas yang mengandung satu atau lebih

subgroup terpisah dari suatu occurance, yang dibutuhkan untuk

direpresentasikan pada suatu data model.

Subclass adalah suatu subgroup terpisah dari occurance suatu tipe

entitas, yang dibutuhkan untuk direpresentasikan pada suatu data

model.

41

2.3 Teori Pendukung

2.3.1 Pengertian Project

Menurut Kathy Schwalbe (2007, p.5), proyek adalah sebuah usaha

keras yang bersifat sementara untuk membuat sebuah produk, jasa,

atau hasil yang unik. Proyek adalah sesuatu hal yang berbeda dengan

operasi saat tujuan atau objektifnya tercapai maka proyek itu akan

selesai.

• Scope

Sebuah batasan dimana pekerjaan yang harus diselesaikan dan

menjadi bagian dalam proyek.

• Time

Lama waktu yang dibutuhkan untuk menyelesaikan proyek

tersebut, dan siapa yang bertanggung jawab apabila ada perubahan

dalam jadwal yang telah di tentukan.

• Cost

Apa saja yang akan menjadi biaya untuk menyelesaikan proyek

tersebut.

Menurut Ludovic-Alexandre Vidal; Marle, Franck berdasarkan jurnal

(Kybernetes journal Vol. 37 No. 8, 2008) mengatakan proyek adalah

usaha yang bersifat sementara dan unik yang dilakukan untuk

memberikan hasil. Hasil ini selalu perubahan dalam organisasi, apa

pun itu dalam proses, kinerja, produk atau jasa.

42

2.3.2 Pengertian Project Management

Menurut Kathy Schwalbe (2007, p.5), project management adalah

penerapan pengetahuan, kemampuan, perangkat, dan teknik untuk

memenuhi aktivitas proyek.

Poston, Robin. S (2011: 52-57) mengatakan permintaan untuk

keterampilan manajemen proyek dalam industri meningkat sehingga

permintaan yang lebih tinggi untuk program manajemen proyek

pendidikan. Proyek mengambil posisi yang lebih menonjol dalam

perencanaan strategis dan keberhasilan organisasi dalam lingkungan

yang kompetitif saat ini.

Menurut Martin, Nancy L;Pearson, J Michael;Furumo, Kimberly

berdasarkan jurnal (The Journal of Computer Information Systems,

2007) mengatakan proyek manajemen IS didefinisikan sebagai

penerapan pengetahuan formal dan informal, keterampilan, alat dan

teknik untuk mengembangkan sebuah sistem yang menyediakan

tingkat yang diinginkan fungsionalitas tepat waktu dan sesuai

anggaran.

43

2.4 Kerangka Pikir Pemecahan Masalah

Gambar 2.4 Kerangka Pikir Pemecahan Masalah

Keterangan Gambar :

1. Mendefinisikan ruang lingkup atau batasan yang akan dibahas dari

masalah yang ada.

2. Menganalisis masalah – masalah yang terdapat dalam sebuah

perusahaan tersebut.

3. Menganalisis kebutuhan dari perusahaan tersebut agar dapat memberi

solusi dan menyelesaikan masalah yang telah dianalisis.

4. Mendesain atau menggambarkan model logika.

5. Mendesain atau menggambarkan model fisikal.

6. Menguji hasil analisis terhadap masalah yang ada.

7. Mengevaluasi hasil dari implementasi yang telah dilakukan terhadap

perusahaan.

bab 2 landasan teori - bina nusantara | library...

Documents