13

BAB 2

LANDASAN TEORI

2.1 Pendekatan Basisdata

Pada bab ini akan dijelaskan mengenai teori-teori yang digunakan

sebagai dasar dari penelitian ini. Teori-teori tersebut didapat dari sumber-sumber

yang terpercaya seperti jurnal, textbook dan internet.

2.1.1 Database (Basisdata)

Database merupakan data yang saling terhubung dan

deskripsi dari data yang dirancang untuk kebutuhan organisasi

(Connolly dan Begg, 2005, p15). Sedangkan menurut Nilkamal

Surve (2006, p1-1). database adalah kumpulan dari data yang

saling terhubungan.

Dari teori-teori tersebut dapat disimpulkan bahwa

database adalah sejumlah datayang terorganisasi yang saling

terhubung untuk menyediakan informasi yang dibutuhkan oleh

perusahaan.

14

2.1.2 DBMS (Database Management System)

DBMS adalah sebuah sistem perangkat lunak yang

mengizinkan pengguna untuk mendefinisikan, membuat,

memelihara, dan mengatur akses ke database (Connolly danBegg,

2005, p16). Menurut Jeffery, Lonnie dan Kevin (2004, p524),

Database Management System (DBMS) adalah perangkat lunak

khusus yang digunakan untuk membuat, mengontrol, dan

mengelola sebuah database.

Menurut Gerald V. Post (2005, p2), Database

Management System (DBMS) merupakan software yang

mendefinisikan database, menyimpan data, mendukung query

language, menghasilkan report, dan membuat data entry screen.

Keuntungan DBMS (Connolly dan Begg, 2005, p26) :

1. Kontrol terhadap pengulangan data

2. Konsistensi data

3. Lebih banyak informasi yang didapat dari jumlah data

yang sama

4. Data dapat dipakai bersamaan

5. Peningkatan integritas data

6. Peningkatan keamanan

7. Penetapan standardisasi

15

8. Skala Ekonomis

9. Keseimbangan konflik requirment

10. Peningkatan data aksesibilitas dan respon

11. Peningkatan produktivitas

12. Peningkatan maintenance melalui data independence

13. Peningkatan concurrency

14. Peningkatan layanan recovery dan backup

Kekurangan DBMS (Connolly dan Begg, 2005, p29):

1. Kompleksitas

2. Ukuran

3. Biaya DBMS

4. Penambahan biaya hardware

5. Biaya konversi

6. Performa

7. Tingkat kegagalan lebih tinggi

2.1.3 Komponen DBMS

Komponen DBMS terdiri dari 5 komponen penting (Connolly

dan Begg, 2005, p18) :

16

1. Perangkat keras

Aplikasi dan DBMS memerlukan perangkat keras untuk

berfungsi. Contoh perangkat keras yang digunakan

DBMS dan aplikasi antara lain personal

computer,mainframe.

2. Perangkat lunak

Komponen dari perangkat lunak terdiri dari DBMS dan

program aplikasi bersamadengan sistem operasi.

Umumnya, program aplikasi ditulis dalam 3GL (bahasa

pemrograman generasi ketiga) seperti java, c++, c, atau

menggunakan 4GL (bahasa pemrograman generasi

keempat), seperti SQL, yang dikombinasikan dengan 3GL.

3. Data

Data adalah komponen terpenting dalam lingkungan

DBMS. Menurut Connollydan Begg(2004, p20), data

bertindak sebagai penghubung antara komponen

mesindan pengguna. Database berisi data operasional dan

metadata (data tentang data).

4. Prosedur

Prosedur berkaitan dengan instruksi dan aturan yang

menentukan rancangan dan penggunaan database.

17

Instruksi-instruksi tersebut umumnya berisi :

a. Instruksi untuk menjalankan dan menghentikan

DBMS.

b. Instruksi untuk menggunakan fasilitas tertentu dari

DBMS.

c. Instruksi untuk membuat salinan backup dari

database.

d. Instruksi untuk menangani kegagalan perangkat

keras atau perangkat lunak.

5. Manusia

Komponen terakhir yaitu manusia yang terlibat dengan

sistem

2.1.4 Fungsi DBMS

Menurut Connolly dan Begg (2005, p48), DBMS memiliki

sepuluh fungsi, yaitu:

1. Data storage, retrieval, and update

DBMS harus dapat memungkinkan user untuk

menyimpan, mengambil, dan mengupdate data di

dalam basis data.

18

2. A user-accessible catalog

DBMS harus memiliki sebuah katalog yang berisi

deskripsi data item dan dapat diakses oleh user.

3. Transaction support

DBMS harus memiliki sebuah mekanisme yang dapat

menjamin baik seluruh update yang berhubungan

dengan sebuah transaksi dapat dilakukan ataupun

keseluruhan update tersebut tidak dilakukan.

4. Concurrency control services

DBMS harus memiliki sebuah mekanisme untuk

menjamin basis data di-update secara benar ketika

banyak user meng-update basis data secara bersamaan.

5. Recovery services

DBMS harus memiliki sebuah mekanisme untuk

pemulihan basis data apabila terjadi bencana.

6. Authorization services

DBMS harus memiliki sebuah mekanisme untuk

menjamin bahwa hanya user yang memiliki otorisasi

yang dapat mengakses basis data.

19

7. Support for data communication

DBMS harus dapat terintegrasi dengan piranti lunak

komunikasi, dapat mengakses database dari lokasi

yang jauh.

8. Integrity services

DBMS harus memiliki sarana untuk menjamin baik

data di dalam basis data maupun pengubahan terhadap

data mengikuti aturan-aturan tertentu (constraint).

9. Services to promote data independence

DBMS harus menyertakan fasilitas-fasilitas untuk

mendukung ketidaktergantungan piranti lunak

terhadap struktur aktual dari basis data.

10. Utility services

DBMS harus menyediakan serangkaian layanan

kegunaan seperti program analisis statistik,

pengawasan fasilitas, fasilitas reorganisasi indeks, dan

lain-lain.

2.1.5 Entity Relationship Modeling

Menurut Connolly dan Begg (2005, p342), ER Modeling

adalah sebuah pendekatan top-down untuk merancang basisdata

yang dimulai dengan mengindentifikasi data penting yang

20

disebut entitas dan relasi antara data yang harus diwakili dalam

model.

ER Modeling terdiri dari 2 tipe :

1. Tipe Entitas

Menurut Connolly dan Begg (2005, p343), tipe entitas

adalah kumpulan dari obyek-obyek dengan sifat atau

properti yang sama, yang mana diidentifikasi oleh

perusahaan yang mempunyai eksistensi yang independen.

Konsep dasar dari bentuk Entity Relationship adalah tipe

entitas. Sebuah tipe entitas memiliki keberadaan yang

bebas dan bisa menjadi obyek dengan keberadaan fisik

atau menjadi obyek dengan keberadaan konseptual. Ini

berarti perancang yang berbeda mungkin

mengidentifikasikan entitas yang berbeda. Entity

orrurrence adalah obyek yang dapat dikenal/diidentifikasi

secara unik dari sebuah tipe entitas.

2. Tipe Relasi

Menurut Connolly dan Begg (2005, p346), relationship

type adalah kumpulan keterhubungan yang mempunyai

arti diantara tipe-tipe entitas. Setiap relasi diberi nama

sesuai dengan fungsinya. Relationship occurrence adalah

21

suatu asosiasi/hubungan yang dapat diidentifikasikan

secara unik, yang mana memasukkan satu kejadian dari

setiap tipe entitas yang berpartisipasi.

Contoh:

Gambar 2.1 Relationship Occurrence (Connolly dan

Begg 2005, p346)

Derajat dari relasi adalah jumlah dari partisipasi tipe

entitas dalam sebuah tipe relasi. Entitas yang berhubungan

dalam sebuah tipe relasi dikenal sebagai participant dalam

relationship dan jumlah participant dalam sebuah tipe

relationship disebut sebagai derajat dari relationship. Oleh

karena itu, derajat dari sebuah relationship berderajat dua

disebut binary, sedangkan relationship berderajat tiga

disebut sebagai ternary, dan seterusnya.

22

3. Attribute

Menurut Connoly dan Begg (2005, p350-352), atribut

adalah sifat dari sebuah entity atau sebuah tipe

relationship. Atribut menyimpan nilai dari setiap entity

occurrence dan mewakili bagian utama dari data yang

disimpan dalam basis data. Attribute domain adalah

sejumlah nilai yang diperkenankan untuk satu atau lebih

atribut. Setiap atribut yang dihubungkan dengan sejumlah

nilai disebut domain. Domain mendefinisikan nilai-nilai

yang dimiliki sebuah atribut dan sama dengan konsep

domain pada model relasional. Simple Attribute adalah

atribut yang terdiri dari satu komponen tunggal dengan

keberadaan yang bebas. Simple Attribute tidak bisa dibagi

lagi ke dalam komponen yang lebih kecil. Contohnya,

posisi dan gaji dari entity pegawai. Sedangkan

Composed attribute adalah sebuah susunan atribut dari

banyak komponen dengan sebuah keberadaan yang

bebas dari masing-masingnya. Dalam hal ini beberapa

atribut dapat dipisahkan menjadi komponen yang lebih

kecil lagi dengan keberadaan yang bebas dari masing-

masingnya. Contohnya atribut alamat dari entity

kantor cabang yang mengandung nilai (jalan, kota, kode

pos) bisa dipecahkan menjadi simple attribute jalan, kota,

23

dan kode pos. Single value attribute adalah atribut yang

hanya menyimpan nilai tunggal untuk suatu sifat dari

entity. Multi-valued attribute adalah atribut yang bisa

menyimpan nilai lebih dari satu untuk suatu sifat dari

entity. Contohnya atribut telepon pada entity kantor

cabang yang bisa memiliki lebih dari satu nomor telepon.

Derived attribute (atribut turunan) adalah atribut yang

menunjukkan nilai yang diperoleh dari atribut yang

berhubungan, tidak terlalu dibutuhkan dalam tipe entity

yang sama. Atribut turunan mungkin juga menyangkut

hubungan dari atribut pada tipe entity yang berbeda.

4. Kunci (Key)

Menurut Connoly dan Begg (2005, p78-79), kunci

relasi sangat dibutuhkan untuk mengidentifikasi satu

atau lebih atribut yang memiliki nilai unik setiap

tuple dalam relasi. Macam-macam kunci relasi :

1. Simple Key

Simple Key adalah suatu kunci yang dibentuk oleh

satu atribut.

2. Composite Key

Composite Key adalah kunci yang disusun

berdasarkan lebih dari satu atribut.

24

3. Candidate Key

Candidate Key adalah suatu atribut atau satu set

minimal atribut yang mengidentifikasikan secara

unik suatu kejadian spesifik dari entity.

4. Primary Key

Primary Key adalah satu atribut atau satu set

minimal atribut yang tidak hanya

mengidentifikasikan secara unik suatu kejadian

spesifik, tapi juga dapat mewakili setiap kejadian

dari suatu entity.

5. Alternative Key

Alternative Key adalah kunci kandidat yang tidak

terpakai sebagai kunci primer.

6. Foreign key

Foreign key adalah satu atribut yang melengkapi satu

hubungan (relationship) yang menunjukkan ke

induknya.

5. Structural Constraint

Menurut Connolly dan Begg (2005, p356-

357),Constraints seharusnya mencerminkan batasan dari

hubungan sebagai suatu tanggapan dalam dunia nyata.

Tipe utama constraints dalam hubungan disebut

multiplicity. Multiplicity adalah sejumlah kejadian yang

25

mungkin terjadi pada sebuah tipe entity dimana

memungkinkan berhubungan dengan satu kejadian lain

yang bergantung pada sebuah tipe entity melalui sebuah

hubungan yang nyata. Multiplicity membatasi jalan setiap

entity-entity yang terhubung. Derajat yang paling umum

untuk relationship ialah binary(degree two) Binary

relationship pada umumnya mengarah pada :

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

Pada One-to-one relationship, satu kejadian entity

tunggal hanya dapat berhubungan dengan satu

kejadian entity tunggal dari entity yang lain.

Gambar 2.2 Contoh representasi One-to-One (1:1) Relationship (Connolly dan Begg 2005, p357)

26

Gambar 2.3 Multiply One-to-One (1:1) Relationship (Connolly dan Begg 2005, p358)

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

Pada one-to-many relationship, satu kejadian

entity tunggal dapat berhubungan dengan

lebih dari satu kejadian entity tunggal dari

entity yang lain.

Gambar 2.4 Contoh representasi One-to-Many (1:*)

Relationship (Connolly dan Begg 2005, p358)

27

Gambar 2.5 Multiply One-to-Many (1:*) Relationship

(Connolly dan Begg 2005, p359)

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

Pada many-to-many relationship, lebih dari satu

kejadian entity tunggal dapat berhubungan dengan

lebih dari satu kejadian entity tunggal dari entity

yang lain.

28

Gambar 2.6 Contoh representasi Many-to-Many (*:*) Relationship

(Connolly dan Begg 2005, p360)

Gambar 2.7 Multiply Many-to-Many (*:*) Relationship (Connolly

dan Begg 2005, p360)

29

2.1.6 Database Languages

Bahasa dalam basisdata dibedakan menjadi dua bentuk :

1. Data Definition Language (DDL)

Menurut Connolly dan Begg (2005, p40), pengertian Data

Definition Language adalah suatu bahasa yang

memperbolehkan Database Administrator (DBA) atau

pengguna untuk mendeskripsikan dan memberi nama

suatu entitas, atribut, dan relasi data yang dibutuhkan

untuk aplikasi, bersama dengan integritas data yang

diasosiasikan dan batasan (constraint) keamanan data.

2. Data Manipulation Language (DML)

Menurut Connolly dan Begg (2005, p40), pengertian

Data Manipulation Language adalah suatu bahasa yang

menyediakan seperangkat operasi untuk mendukung

manipulasi data yang berada pada basis data.Pengoperasian

data yang akan dimanipulasi biasanya meliputi :

1. Penambahan data baru ke dalam basis data.

2. Modifikasi data yang disimpan ke dalam basis data.

3. Pengembalian data yang terdapat di dalam basis data.

4. Penghapusan data dari basis data.

DML dibagi menjadi 2 jenis yaitu Procedural dan Non-

procedural. Menurut Connolly dan Begg (2005, p41),

pengertian Procedural DML adalah suatu bahasa yang

30

memperbolehkan pengguna untuk mendeskripsikan ke

sistem data apa yang dibutuhkan dan bagaimana

mendapatkan data tersebut secara tepat, sedangkan Non-

procedural DML adalah sebuah bahasa yang

mengizinkan pengguna untuk menentukan data apa yang

dibutuhkan tanpa memperhatikan bagaimana data diperoleh.

2.1.7 Fourth-Generation Language (4GLs)

Menurut Connolly dan Begg (2005, p42), tidak terdapat

persetujuan umum tentang bahasa generasi keempat. Berbeda

dengan bahasa generasi ketiga yang membutuhkan banyak baris

untuk sebuah operasi, generasi keempat ini membutuhkan lebih

sedikit baris untuk sebuah operasi dibanding dengan bahasa

generasi sebelumnya. Sebuah bahasa generasi keempat sangat

diharapkan dapat menjadi tumpuan yang sangat besar untuk

komponenkomponen yang levelnya lebih tinggi yang dikenal

dengan fourth-generation tools. Bahasa generasi keempat

meliputi :

1. Presentation language, seperti query languages dan report

generators

31

2. Speciality language, seperti spreadsheets dan database

language

3. Application generators yang mendefinisi, melakukan insert,

update, delete data dari database ke aplikasi yang sedang

dibangun

4. Very high-level languages yang digunakan untuk

mengenerate applicationcode

2.1.8 Siklus Hidup Basisdata

Karena sistem database adalah komponen fundamental

dari sistem informasi organisasi yang lebih besar, siklus

perkembangan sistem database sangat erat kaitannya dengan

siklus dari sistem informasi. Untuk aplikasi basisdata yang kecil

dengan jumlah pengguna yang sedikit, tidak dibutuhkan siklus

hidup basisdata yang kompleks.

Bagaimanapun, saat merancang aplikasi basisdata

menengah sampai besar dengan jumlah pemakai puluhan hingga

ribuan pemakai, menggunakan ratusan query dan aplikasi

program, siklus hidup dapat menjadi sangat kompleks. Berikut ini

adalah gambar tahapan – tahapan siklus hidup aplikasi basisdata

menurut Conolly dan Begg (2005, p284).

32

Diagram 2.1 Siklus Hidup Aplikasi Basisdata (Connolly dan Begg, 2005, p284)

33

2.1.8.1 Perencanaan Basisdata (Database Planning)

Merupakan aktifitas yang merencanakan

tahapan dari daur hidup sistem basisdata dapat

direalisasikan secara lebih efisien dan efektif.

Perencanaan basisdata harus terintegrasi dengan

seluruh strategi sistem informasi dari organisasi

bersangkutan. Ada tiga permasalahan pokok dalam

merumuskan suatu strategi sistem informasi

(Connolly dan Begg, 2005, p285), yaitu :

a. Identifikasi rencana dan tujuan perusahaan

dengan penentuan sistem informasi yang

dibutuhkan.

b. Evaluasi sistem informasi yang berjalan untuk

menentukan kelebihan dan kelemahan sistem

yang ada.

c. Penilaian terhadap peluang-peluang informasi

teknologi yang mungkin mendatangkan

keuntungan yang kompetitif.

2.1.8.2 Definisi Sistem (System Definition)

Definisi sistem menjelaskan batasan-

batasan dan ruang lingkup aplikasi basisdata dan

34

sudut pandang mayoritas pengguna (Connoly dan

Begg, 2005, p286).

2.1.8.3 Pengumpulan dan Analisis kebutuhan

(Requirement Collection and Analysis)

Pengumpulan dan analisis kebutuhan

adalah proses pengumpulan dan analisa informasi

tentang bagian perusahaan yang didukung yang

didukung aplikasi basisdata dan menggunakan

informasi untuk mengidentifikasi kebutuhan-

kebutuhan pengguna dari sistem yang baru

(Connolly dan Begg, 2005, p288).

Terdapat banyak teknik untuk menyatukan

informasi yang disebut fact-finding techniques.

Informasi yang dikumpulkan untuk tiap user view

utama (yaitu job role atau enterprise application

area) meliputi:

• Deskripsi data yang digunakan atau

dihasilkan

• Rincian bagaimana data digunakan atau

dihasilkan

35

• Semua kebutuhan-kebutuhan tambahan untuk

aplikasi basisdata yang baru.

2.1.8.4 Perancangan Basisdata (Database Design)

Perancangan basisdata merupakan proses

membuat rancangan basisdata yang mendukung

operasi- operasi dan tujuan-tujauan perusahaan

(Connolly dan Begg, 2005, p291).

Terbagi atas 3 tahap antara lain:

∗ Perancangan Basisdata Konseptual

(Conceptual Database Design)

Proses membuat penjelasan implementasi

database pada penyimpanan sekunder,

menggambarkan hubungan dasar,

organisasi file, dan indeks yang digunakan

untuk mencapai akses yang efisien

terhadap data, dan setiap ruang lingkup

integritas yang terkait dan nilai keamanan.

36

∗ Perancangan Basisdata Logikal

(Logical Database Design)

Proses pembuatan sebuah model data yang

digunakan dalam suatu perusahaan

berdasarkan pada model data yang spesifik,

tetapi independen dari DBMS tertentu dan

pertimbangan fisik lainnya.

∗ Prancangan Basisdata Fisikal

(Physical Database Design)

Proses membuat penjelasan implementasi

database pada penyimpanan sekunder,

menggambarkan hubungan dasar,

organisasi file, dan indeks yang digunakan

untuk mencapai akses yang efisien

terhadap data, dan setiap ruang lingkup

integritas yang terkait dan nilai keamanan.

2.1.8.5 Pemilihan DBMS (DBMS Selection)

Pemilihan DBMS adalah pemilihan DBMS

yang sesuai untuk mendukung aplikasi basisdata

37

(Connolly dan Begg, 2005, 295). Langkah-

langkah utama untuk memilih DBMS adalah:

• Mendefinisikan istilah-istilah yang mengarah

pada pembelajaran

• Daftar pendek dua atau tiga produk

• Mengevaluasi produk

• Merekomendasikan pilihan dan membuat

laporan

2.1.8.6 Perancangan Aplikasi (Application Design)

Perancangan aplikasi adalah perancangan

antarmuka pengguna dan program-program

aplikasi yang digunakan dan memproses basisdata.

2.1.8.7 Prototipe (Prototyping)

Prototipe adalah pembangunan model kerja

aplikasi basisdata (Connolly dan Begg, 2005,

p304). Terdapat dua strategi prototipe yang biasa

digunakan sekarang ini, yaitu requirement

prototyping dan evolutionary prototyping.

38

Requirement prototyping menggunakan

prototipe untuk menentukan kebutuhan-kebutuhan

yang diusulkan aplikasi basisdata dan jika

kebutuhan -kebutuhan sudah dilengkapi maka

prototipe tidak dipakai lagi atau dibuang.

Sedangkan evolutionary prototyping digunakan

untuk tujuan yang sama, tetapi perbedaannya

requirements prototyping adalah prototipe tidak

dibuang tetapi dengan perkembangan lebih lanjut

menjadi aplikasi kerja basisdata.

2.1.8.8 Implementasi (Implementation)

Implementasi adalah realisasi fisik basis

data dan perancangan aplikasi (Connolly dan Begg,

2005, p304). Implementasi basisdata dicapai

menggunakan DDL (data definition language) dan

aplikasi menggunakan 4GL (Fourth generation

language).

39

2.1.8.9 Konversi Data dan Muatan Data

(Data Conversion and Loading)

Konversi data dan muatan data adalah

memindahkan semua data yang ada kedalam

basisdata yang baru dan mengkonversikan semua

aplikasi yang ada untuk digunakan pada basisdata

yang baru (Connolly dan Begg, 2005, p305).

2.1.8.10 Pengetesan (Testing)

Pengetesan adalah proses mengeksekusi

program-program dengan tujuan untuk

menemukan kesalahan-kesalahan (Connolly dan

Begg, 2005, p305).

2.1.8.11 Pemeliharaan Operasional

(Operational Maintenance)

Pemeliharaan operasional adalah proses

mengawasi dan memlihara sistem yang meliputi

aktifitas mengawasi performa dari sistem dan

40

memelihara dan memperbarui aplikasi basisdata

(Connolly dan Begg, 2005, p306).

2.1.9 Methodology Desain Basisdata

Sebuah pendekatan terstruktur yang menggunakan

prosedur, teknik, alat-alat, dan bantuan dokumentasi untuk

mendukung dan memfasilitasi proses desain. (Connolly dan Begg,

2005, p306).

Rancangan metodologi terdiri dari beberapa fase yang

masing-masing berisi sejumlah langkah, yang menjadi acuan

perancang menentukan teknik yang tepat pada setiap tahapan

proyek. Sebuah rancangan metodologi juga membantu desainer

untuk merencanakan, mengelola, mengendalikan, dan

mengevaluasi pengembangan proyek database. Selain itu,

rancangan ini merupakan pendekatan terstruktur untuk

menganalisis dan pemodelan persyaratan-persyaratan untuk

database dengan cara standar dan terorganisir.

Dalam metodologi rancangan database, proses rancangan

dibagi menjadi 3 fase:

41

1. Rancangan Basisdata Konseptual

Proses pembangunan sebuah model data yang digunakan

dalam perusahaan, independen dari semua pertimbangan

fisik. Tahap desain konseptual basisdata dimulai dengan

penciptaan data model konseptual perusahaan, yang

sepenuhnya independen dari rincian implementasi seperti

target DBMS, program aplikasi, bahasa pemrograman,

platform perangkat keras, masalah kinerja, atau

pertimbangan fisik lainnya.

Langkah 1 Membangun model konseptual data

Tujuan: Untuk membangun sebuah model data konseptual

dari kebutuhan data perusahaan.

Model data konseptional terdiri dari: tipe entitas, tipe

hubungan, atribut dan domain atribut, kunci utama dan

alternative, ruang lingkup terintegritasi. Model dta

konseptual didukung oleh dokumentasi, termasuk diagram

ER dan list data, yang dihasilkan selama perkembangan

model ini.

Langkah 1.1 Mengidentifikasi jenis entitas

Tujuan: Untuk mengidentifikasi tipe entitas yang

dibutuhkan

42

Langkah 1.2 Mengidentifikasi jenis hubungan

Tujuan: Untuk mengidentifikasi hubungan penting yang

ada antara tipe-tipe entitas

Langkah 1.3 Mengidentifikasi dan mengasosiasikan

atribut dengan tipe entitas atau hubungan

Tujuan: Untuk mengasosiasikan atribut dengan tipe

entitas atau hubungan yang cocok.

Langkah 1.4 Menentukan domain atribut

Tujuan: Untuk menentukan domain dari atribut pada

model data konseptual.

Langkah 1.5 Tentukan atribut calon kunci, primer,

dan alternative

Tujuan: Untuk mengidentifikasi kandidat kunci untuk

setiap jenis entitas dan, jika ada lebih dari satu kandidat

kunci, untuk dipilih salah satu untuk menjadi kunci utama

dan lainnya sebagai kunci alternatif.

43

Langkah 1.6 Pertimbangkan penggunaan konsep

pemodelan enhanced (langkah opsional)

Tujuan: Untuk mempertimbangkan penggunaan konsep

pemodelan enhanced, seperti spesialisasi /generalisasi,

agregasi, dan komposisi.

Langkah 1.7 Periksa Redundansi Model

Tujuan: Untuk memeriksa keberadaan redudansi pada

model

Langkah 1.8 Validasi model konseptual terhadap

transaksi pengguna

Tujuan: Untuk menyakinkan bahwa model konsepsual

mendukung transaksi yang dibutuhkan.

Langkah 1.9 Review Model data konseptual dengan

pengguna

Tujuan Untuk meninjau model data konseptual dengan

pengguna untuk memastikan bahwa mereka

mempertimbangkan sebagai representasi yang 'benar' dari

data perusahaan yang dibutuhkan.

2. Rancangan Basisdata Logikal

44

Proses pembuatan sebuah model data yang

digunakan dalam suatu perusahaan berdasarkan pada

model data yang spesifik, tetapi independen dari DBMS

tertentu dan pertimbangan fisik lainnya.

Tahap rancangan database logis memetakan model

konseptual ke model logis, yang dipengaruhi oleh model

data untuk database target (misalnya, model relasional).

Model data logis merupakan sumber informasi untuk fase

desain fisik, menyediakan rancangan database fisik

dengan sarana untuk membuat pengorbanan yang sangat

penting untuk desain database yang efisien.

Langkah 2 Membangun dan memvalidasi model data

logis

Tujuan: Untuk menerjemahkan model data konseptual

menjadi model data logis dan kemudian memvalidasi

model ini dan memeriksa bahwa model ini benar secara

struktural dan mampu mendukung transaksi yang

diperlukan.

Langkah 2.1 Membuat hubungan untuk model data

logis

45

Tujuan: Untuk menciptakan hubungan antara model data

logis untuk mewakili entitas, hubungan, dan atribut yang

telah diidentifikasi.

Langkah 2.2 Validasi relasi dengan menggunakan

normalisasi

Tujuan: Untuk memvalidasi hubungan pada data model

logical menggunakan normalisasi

Langkah 2.3 Validasi relasi terhadap transaksi

pengguna

Tujuan: Untuk meyakinkan bahwa relasi pada data model

logical mensupport transaksi yang diperlukan.

Langkah 2.4 Periksa integritas ruang lingkup

Tujuan: Untuk memeriksa ruang lingkup yang

terintegrasi diwakili oleh data model logikal

Langkah 2.5 Review Model data logis dengan

pengguna

46

Tujuan: Untuk meninjau model data logis dengan

pengguna untuk memastikan bahwa mereka menganggap

model menjadi representasi yang benar dari data

perusahaan yang diperlukan.

Langkah 2.6 Menggabungkan model data logis ke

model global (langkah opsional)

Tujuan: Untuk menggabungkan model data logis lokal ke

dalam model data logis global tunggal yang mewakili

pandangan pengguna semua database.

Langkah 2.7 Periksa perkembangan selanjutnya

Tujuan: Untuk menentukan apakah ada perubahan yang

signifikan dalam kemungkinan mendatang dan untuk

menilai apakah model data logis dapat mengakomodasi

perubahan ini.

3. Rancangan Database Fisikal

Proses membuat penjelasan implementasi database

pada penyimpanan sekunder, menggambarkan hubungan

dasar, organisasi file, dan indeks yang digunakan untuk

mencapai akses yang efisien terhadap data, dan setiap

ruang lingkup integritas yang terkait dan nilai keamanan.

47

Tahap desain database fisik memungkinkan

perancang untuk membuat keputusan tentang bagaimana

database diimplementasikan. Oleh karena itu, desain fisik

disesuaikan dengan DBMS tertentu. Ada umpan balik

antara desain fisik dan desain logis, karena keputusan-

keputusan yang diambil selama membuat desain fisik

untuk meningkatkan kinerja dapat mempengaruhi model

data logis.

Langkah 3 Terjemahkan logis data model untuk

target DBMS

Tujuan: Untuk menghasilkan skema database relasional

dari model data logis yang dapat diimplementasikan

dalam DBMS target.

Langkah 3.1 Desain hubungan dasar

Tujuan: Untuk menentukan bagaimana mewakili

hubungan dasar yang diidentifikasi dalam Model data

logis pada target DBMS.

Langkah 3,2 Desain representasi asal data

48

Tujuan: Untuk menentukan bagaimana mewakili data

yang diturunkan dalam Model data logis pada DBMS

target.

Langkah 3.3 Desain ruang lingkup umum

Tujuan: Untuk merancang ruang lingkup umum untu

target DBMS

Langkah 4 Desain berkas organisasi dan indeks

Tujuan: Untuk menentukan organisasi file yang optimal

untuk menyimpan hubungan dasar dan indeks yang

diperlukan untuk mencapai kinerja yang dapat diterima,

yaitu, cara di mana hubungan dan tupel akan diungkapkan

pada penyimpanan sekunder.

Langkah 4.1 Menganalisis transaksi

Tujuan: Untuk memahami fungsi dari transaksi yang akan

berjalan pada database dan untuk menganalisis transaksi

yang penting.

Langkah 4.2 Pilih file organisasi

49

Tujuan: Untuk menentukan organisasi file yang efisien

untuk tiap hubungan dasar.

Langkah 4.3 Pilih indeks

Tujuan: Untuk menentukan aakah menambahan indeks

akan meningkatkan kemampuan system.

Langkah 4,4 Perkirakan harddisk space yang

diperlukan

Tujuan: Untuk memperkirakan jumlah space hardisk yang

diperlukan untuk database.

Langkah 5 Desain user views

Tujuan: Untuk merancang pandangan pengguna yang

telah diidentifikasi selama perkembangan siklus

pengumpulan dan analisis tahap sistem database yang

dibutuhkan.

Langkah 6 Desain mekanisme keamanan

Tujuan: Untuk merancang mekanisme keamanan untuk

database seperti yang ditentukan oleh pengguna selama

perkembangan siklus pengumpulan dan analisis tahap

sistem database yang dibutuhkan.

50

Langkah 7 Pertimbangkan pengenalan redundansi

terkontrol

Tujuan: Untuk menentukan apakah memperkenalkan

redundansi secara terkendali oleh

aturan normalisasi yang ringan akan meningkatkan kinerja

sistem.

Langkah 7.1 Menggabungkan hubungan satu-ke-satu

(1:1)

untuk mengurangi penggabungan

Langkah 7.2 Menduplikasi atribut non-key dalam

hubungan satu-ke-banyak (1: *)

untuk mengurangi penggabungan

Langkah 7.3 Menduplikasi atribut kunci asing dalam

hubungan satu-ke-banyak (1: *)

untuk mengurangi penggabungan

Langkah 7.4 Menduplikasi atribut dalam hubungan

banyak-ke-banyak (*: *) untuk

mengurangi penggabungan

51

Langkah 7.5 Memperkenalkan kelompok pengulangan

untuk meningkatkan perfoma sistem

Langkah 7.6 Membuat tabel ekstrak

untuk membuat dan mengisi tabel dan memprosesnya saat

sistem sedang tidak banyak meloading data.

Langkah 7.7 Hubungan Partisi

untuk menyimpan dan menganalisis sejumlah data yang

besar.

Langkah 8 Monitor dan menyempurnakan sistem

operasional

Tujuan: Untuk memonitor sistem operasional dan

meningkatkan kinerja sistem untuk memperbaiki

keputusan desain yang tidak tepat atau mencerminkan

perubahan kebutuhan.

2.1.10 Normalisasi

Menurut Connolly dan Begg (2005, p388), normalisasi

adalah sebuah teknik untuk menghasilkan satu set relasi dengan

atribut-atribut yang inginkan, sesuai dengan kebutuhan

52

perusahaan. Tujuan dari normalisasi adalah untuk

mengidentifikasi suatu set relasi yang sesuai, yang mendukung

permintaan data dari perusahaan. Sedangkan menurut Whitten,

Bentley, dan Dittman (2004, p306), normalisasi adalah teknik

analisis data yang mengatur atribut data dalam kelompok untuk

membentuk entitas yang non-redundan, stabil, fleksibel, dan

mudah beradaptasi.

Unnormalized (UNF) merupakan keadaan dimana sebuah

tabel berisi satu atau lebih grup yang berulang. Grup yang

berulang adalah sebuah atribut atau kumpulan atribut, dalam

sebuah tabel, yang mempunyai multiple value. Untuk membuat

entitas data yang normal, tidak redundan, stabil, dan fleksibel,

diperlukan normalisasi.

Tahapan-tahapan Normalisasi menurut Connolly dan

Begg (2005, p401):

1. First Normal Form (1 NF)

Bentuk normal pertama merupakan sebuah relasi dimana

irisan dari baris dan kolom hanya memiliki 1 nilai. Bentuk

normal pertama ini dicapai apabila setiap nilai atribut adalah

53

tunggal, tidak ada atribut yang dapat memiliki lebih dari satu

nilai untuk contoh entitas tunggal. Untuk mencapai bentuk

normal pertama, yang harus dilakukan adalah:

• menghilangkan perulangan

• menghilangkan perhitungan

• menentukan primary key

2. Second Normal Form (2NF)

Bentuk normal kedua merupakan sebuah relasi dari bentuk

normal pertama dimana setiap atribut yang bukan primary key

harus bergantung sepenuhnya secara fungsional dengan

primary key (fully functional dependency). Untuk mencapai

bentuk normal kedua, yang harus dilakukan adalah

menghilangkan ketergantuan parsial dari atribut-atribut non-

primary key.

3. Third Normal Form (3NF)

54

Bentuk normal ketiga merupakan sebuah relasi dari bentuk

normal pertama dan kedua dimana tidak ada atribut yang non-

primay key tergantung transitif dengan primay key.

2.2 Tools yang digunakan

Dalam penulisan skripsi ini, adapun tools yang digunakan dalam

perancangan sistem basisdata dan aplikasi basisdata antara lain menggunakan

diagramming tools dan software tools.

2.2.1 Diagramming Tools

Dalam merancang dan membuat aplikasi sistem basisdata ini, adapun

diagramming tools yang digunakan sebagai berikut:

1. Flowchart

Flowchart adalah penggambaran secara grafik dari langkah-langkah

dan urut-urutan prosedur dari suatu program. Flowchart menolong

analis dan programmer untuk memecahkan masalah kedalam

segmen-segmen yang lebih kecil dan menolong dalam menganalisis

alternatif-alternatif lain dalam pengoperasian. (meftahul.com, 2011)

Flowchart biasanya mempermudah penyelesaian suatu masalah

khususnya masalah yang perlu dipelajari dan dievaluasi lebih lanjut.

55

Tabel 2.1 Simbol Flowchart (meftahul.com, 2011)

2. Data Flow Diagram (DFD)

Menurut Jeffery L.Whitten (2007, p317), data flow diagram adalah

sebuah model proses yang digunakan untuk menggambarkan aliran

data melalui sebuah sistem dan tugas atau pengolahan yang dilakukan

56

oleh sistem. Konsep untuk modeling DFD terdiri dari (Jeffery

L.Whitten, 2007, p319-322):

• Eksternal Agen

Persegi empat menyatakan agen eksternal-batasan

sistem tersebut. Kedua model sama, yang

membedakannya hanya ukurannya

Gambar 2.8 Eksternal Agen

(Jeffery L.Whitten, 2007, p319)

57

• Data Store

Untuk model dari DeMarco/Yourdon persegi panjang

dengan kedua ujung terbuka menyatakan data store,

terkadang disebut file atau database. Sedangkan model dari

Gane dan Sareon ditandai dengan warna hijau disebelah kiri

dan terbuka disebelah kanan.

Gambar 2.9 Data Store

(Jeffery L.Whitten, 2007, p320)

58

• Proses Name

Persegi panjang bersudut (bentuk Gane dan Sarson)

menyatakan nama proses (Process Name) atau bagaimana

tugas dikerjakan.

Gambar 2.10 Process Name

(Jeffery L.Whitten, 2007, p321)

3. State Transition Diagram (STD)

State Transition Diagram (STD) menunjukan bagaimana

sistem bertingkah laku sebagai akibat dari kejadian eksternal.

Untuk melakukannya, STD menunjukkan berbagai model tingkah

laku (disebut state) sistem dan cara di mana transisi dibuat dari state

satu ke state lainnya. STD berfungsi sebagai dasar bagi pemodelan

tingkah laku. (Pressman, 2001, p302)

59

Notasi yang digunakan dalam State Transition Diagram adalah :

− Action (Aksi)

Merupakan suatu tindakan yang dilakukan oleh sistem saat

terjadi perubahan state atau merupakan suatu reaksi terhadap

kondisi. Aksi menghasilkan output seperti pesan pada layar,

cetakan pada printer, dan lain - lain.

− Condition (kondisi)

Merupakan suatu kejadian yang terdapat pada lingkungan

eksternal yang dapat dideteksi oleh sistem yang akan

mengakibatkan perubahan keadaan.

− State

Merupakan suatu simbol yang menyatakan suatu keadaan atau

kondisi dari sebuah sistem.

− Transition State

Merupakan suatu simbol yang menyatakan perubahan dari state

yang satu ke state yang lain.

60

2.2.2 Software Tools

1. PHP

Software ini digunakan untuk melakukan interpretasi data kode PHP

menjadi kode HTML sehingga hasilnya dapat ditampilkan di web-

browser (Budi Raharjo, 2011,246)

2. Database Management System (DBMS)

Kumpulan program yang digunakan untuk mendefinisikan, mengatur,

dan memproses database, sedangkan database itu sendiri esensinya

adalah sebuah struktur yang dibangun untuk keperluan penyimpanan

data. DBMS merupakan alat atau tool yang berperan untuk

membangun struktur tersebut. (Budi Raharjo, 2011,10)

3. MySQL

Merupakan software RDBMS (atau server database) yang dapat

mengelola database dengan sangat cepat, dapat menampung data

dalam jumlah sangat besar, dapat diakses oleh banyak user(multi-

user), dan dapat melakukan suatu proses secara sinkron atau

berbarengan(multi-threaded).

61

2.3 Pemahaman Object Studi

Semua penjelasan tentang Object studi yang berkaitan dengan sistem yang

berjalan didalam perusahaan dan berguna sebagai penjelasan dalam perancangan

sistem basis data yang akan dibuat.

2.3.1 Customer

Pelanggan atau Customer merupakan bagian penting dari

perencanaan bisnis, tanpa customer maka tidak ada penjualan dan tidak

ada perusahaan yang akan bertahan lama. Untuk bertahan perusahaan

mengelompokan sesuai dengan dasar kebutuhan, kebiasaan dan atribut

lainnya.(Alexander, Yves, 2010, p20). Dapat disimpulkan bahwa

customer adalah bagian yang penting untuk memulai sebuah usaha yang

kita jalankan.

2.3.2 Produksi

Produksi dapat dikatakan sebagai suatu aktivitas dalam perusahaan

industri berupa penciptaan nilai tambah dari input menjadi output secara

efektif dan efisien sehingga produk sebagai output dari proses penciptaan

nilai tambah itu dapat dijual dengan harga yang kompetitif di pasar global

(Vincent Gaspersz, 2005:167).

62

2.3.3 Pengangkutan

Konunikasi, Distribusi, dan Chanel Pemasaran merupakan bagian

dari penampilan sebuah perusahaan ke Customer(Alexander, Yves, 2010,

p26). Maka dapat disimpulan Distribusi merupakan bagian yang penting

dalam proses binis yang menghubungkan perusahaan dengan customer

atau pelanggan.

2.3.4 Supplier

Relasi dengan supplier dibuat untuk memaksimalkan alokasi dari

barang dan kegiatan perusahaan (Alexander, Yves, 2010, p39). Maka

dapat disimpulkan hubungan dengan supplier merupakan bagian penting

dari proses binis dalam suatu perusahaan.

Dengan adanya relasi dengan supplier dapat memaksimalkan

proses alokasi bahan baku dan meninggkatkan produksi ataupun

penjualan produk.

2.3.5 Penjualan

Penjualan adalah bagaimana menciptakan hubungan jangka

panjang dengan pelanggan melalui produk atau jasa dari sebuah

perusahaan. Dalam hal ini penjualan adalah bagaimana strategi yang

63

akan digunakan untuk mengintegrasikan perusahaan, pelanggan, dan

korelasi antar keduanya (Kertajaya, 2006, p15).

L1