BAB 2

LANDASAN TEORI

2.1 Teori-teori Dasar atau Umum

2.1.1 Perbedaaan File Based System dengan Sistem Basis Data

Pada saat ini aplikasi basisdata sudah digunakan di kehidupan sehari-hari, seperti

pembelian di supermarket, pembelian dengan kartu kredit, pemesanan hotel melalui

biro perjalanan, penggunaan pada perpustakaan, penggunaan internet, dll.

Penggunaan basisdata yang tradisional adalah File-Based System. Menurut

Thomas M. Connolly (2002, p7) pengertian dari File-Based System adalah kumpulan

program aplikasi yang menyajikan service kepada pemakai seperti pembuatan

laporan. Setiap program akan mendefinisikan dan mengontrol masing-masing data

program itu sendiri. Tetapi aplikasi File-Based System mempunyai banyak

kelemahan, contohnya :

Data yang terpisah-pisah

Data yang terisolasi pada file berbeda mengakibatkan semakin sulitnya

pengaksesan terhadap data tersebut.

Duplikasi data

Karena setiap programmer membuat file dan aplikasi dalam jangka

waktu yang lama, variasi file memiliki format yang berbeda dan

kemungkinan program tersebut ditulis oleh bahasa program yang

berbeda-beda. Oleh karena itu, kemungkinan informasi yang sama dapat

berada pada beberapa file.

7

Ketergantungan data

Seperti yang telah disebutkan di atas, struktur fisik dari file data dan

record didefinisikan pada kode aplikasi. Hal ini mengakibatkan

pengubahan dari struktur yang telah ada menjadi sulit dilakukan.

Format data yang tidak kompatibel

Karena struktur file tersimpan pada program aplikasi, struktur tersebut

menjadi tergantung pada bahasa pemrograman yang digunakan.

Fixed query/proliferation of application programs.

Dibandingkan dengan sistem manual, file-based system menawarkan

sistem yang lebih baik, tetapi seiring dengan perkembangan akan muncul

permintaan-permintaan query baru. Hal ini membutuhkan pembuatan

program tambahan untuk dapat menjalankan query tersebut. Hal ini

membutuhkan waktu dan biaya tambahan sehingga dapat menurunkan

efektifitas dari sistem.

Dengan adanya kekurangan dari File-Based System, maka dibuatlah sistem

basisdata yang merupakan pendekatan baru yang dibutuhkan untuk mengatasi

kelemahan tersebut. Salah satu dari sistem basisdata adalah Database dan Database

Management System (DBMS).

2.1.2 Pengertian Database

Pengertian database menurut Thomas M. Connolly (2002, p14) adalah

kumpulan data yang saling berhubungan secara logical, dan keterangan

mengenai data itu, yang dibuat untuk menemukan informasi yang dibutuhkan

8

oleh sebuah organisasi. Database yang tunggal dapat digunakan oleh berbagai

pengguna atau bagian dalam waktu yang bersamaan.

Menurut C. J. Date (2000, p10) database adalah kumpulan data persistent

yang digunakan oleh sistem aplikasi dari perusahaan tertentu. Persistent

maksudnya adalah sekali data telah diterima oleh DBMS untuk dimasukkan ke

dalam database, data tersebut hanya bisa dihapus dari database dengan

menggunakan permintaan eksplisit ke DBMS.

Sistem Basisdata adalah sistem penyimpanan rekaman atau record yang

terkomputerisasi di mana tujuan sebenarnya adalah menyimpan informasi dan

membuat informasi tersebut selalu tersedia pada saat dibutuhkan

2.1.3 Database Management System (DBMS)

DBMS adalah sistem perangkat lunak yang memungkinkan pengguna

untuk mendefinisikan, membuat, memelihara, dan mengontrol akses ke

database.

Fasilitas-fasilitas yang disediakan DBMS :

• Memungkinkan pengguna mendefinisikan database biasanya melalui DDL

(Data Definition Language). DDL memungkinkan pengguna untuk

menentukan tipe dan struktur data yang akan disimpan pada database.

• Memungkinkan pengguna untuk memasukkan, meng-update, menghapus,

dan mengambil data dari database biasanya melalui DML (Data

Manipulation Language).

• Menyediakan akses terkontrol ke database. Contohnya :

9

Sistem sekuriti, mencegah pengguna yang tidak memiliki hak untuk

mengakses database.

Sistem integrity, memelihara konsistensi dari data yang disimpan

Concurrency control system, memungkinkan akses bersama database

Recovery control system, mengembalikan database ke keadaan

sebelumnya yang masih konsisten ketika terjadi kerusakan perangkat

keras atau perangkat lunak.

User-accessible catalog, berisi deskripsi dari data pada database.

Keuntungan dari DBMS :

Mengontrol duplikasi data

Database dapat mengurangi duplikasi data yang terjadi pada File-Based

System. Tetapi tidak semua duplikasi data dapat dihilangkan, melainkan

hanya dapat dikontrol. Hal ini dikarenakan terkadang duplikasi data tetap

dibutuhkan untuk meningkatkan perfoma.

Data konsisten

Dengan menghilangkan atau mengontrol duplikasi data akan mengurangi

resiko ketidakkonsistenan dari data yang mungkin terjadi.

Data yang sama memiliki lebih banyak informasi

Dengan adanya integrasi data operasional maka memungkinkan bagi

sebuah organisasi mendapatkan informasi tambahan dari data yang sama.

Penggunaan data bersama-sama

Biasanya file dimiliki oleh seseorang atau departemen yang

menggunakannya. Sebaliknya database dimiliki oleh organisasi secara

keseluruhan dan dapat di-share kepada pengguna yang memiliki hak.

10

Integritas data telah dikembangkan

Integritas data memiliki arti dari konsisten dan keabsahan dari data yang

disimpan. Integritas biasanya menegaskan arti dari constraint, yang

merupakan aturan yang tidak dapat di langgar oleh pemakai database.

Keamanan telah dikembangkan

Keamanan database akan melindungi database dari pemakai yang tidak

memiliki hak. Hal ini biasanya dilakukan dengan adanya nama pemakai

dan password untuk mengidentifikasikan hak yang dimiliki oleh setiap

pemakai.

Memiliki standar yang jelas

Integrasi memungkinkan Database Administrator (DBA) untuk

mendefinisikan dan memberikan standar yang dibutuhkan, seperti format

data untuk mendukung pertukaran data antar sistem, aturan penamaan,

standar dokumentasi, prosedur update, dan cara atau hak pengaksesan.

Ekonomis

Dengan menggabungkan semua data operasional organisasi ke dalam satu

database dan membuat beberapa aplikasi yang bekerja dengan

menggunakan satu sumber data, ini dapat menghemat pengeluaran. Jadi

dana yang di keluarkan akan labih kecil dari dana tiap bagian pada file

based system bila digabungkan.

Konflik kebutuhan dapat diseimbangkan

Setiap pengguna atau departemen mempunyai suatu kebutuhan masing-

masing, di mana kebutuhan tersebut dapat menimbulkan konflik dengan

pengguna atau departemen yang lain. Dengan database berada di bawah

11

kendali dari DBA, maka DBA dapat membuat keputusan mengenai

perancangan dan penggunaan operational dari database yang menyediakan

penggunaan sumber daya database terbaik bagi organisasi.

Meningkatkan kemampuan akses dan respon data

Sebagai hasil integrasi, data umum dapat diakses secara langsung oleh

pemakai. Hal ini menyediakan sistem yang memiliki lebih banyak fungsi.

Meningkatkan produktifitas

DBMS menyediakan banyak fungsi standar yang biasanya harus dibuat

oleh seorang programmer pada aplikasi berbasis file. Pada tingkat dasar

DBMS menyediakan semua rutin low level untuk menangani file yang

biasanya ada pada program aplikasi. Kegunaan dari fungsi ini adalah

membuat seorang programmer dapat memusatkan perhatiannya hanya pada

fungsi yang spesifik yang dibutuhkan oleh pengguna, tanpa perlu

memikirkan detil dari implementasi low level-nya.

Mempermudah perawatan dengan menghilangkan ketergantungan data

Dalam file-based system deskripsi dari data dan logika untuk pengaksesan

data dibuat untuk tiap aplikasi, sehingga program sangat tergantung

terhadap data. Sebuah perubahan terhadap struktur data tersebut, sebagai

contoh variabel alamat yang sebelumnya dgn panjang 40 karakter ingin

diubah menjadi 41 karakter, ini memerlukan perubahan yang banyak pada

program yang terpengaruh efek dari perubahan tersebut. Sedangkan pada

DBMS deskripsi data dan aplikasi terpisah, dengan cara demikian membuat

aplikasi tidak terpengaruh terhadap perubahan dari deskripsi data.

12

Meningkatkan concurrency

Pada file-based system, jika dua atau lebih pengguna yang mengakses file

yang sama secara bersamaan, akses itu bisa saling mempengaruhi, dan

bahkan bisa membuat hilangnya informasi. Sedang DBMS dapat mengelola

akses data secara bersamaan.

Meningkatkan kemampuan backup dan perbaikan

Pada file-based system, pengguna sendiri yang bertanggung jawab untuk

melindungi data dari kegagalan sistem komputer atau program aplikasi. Hal

tersebut membutuhkan kerja tambahan di mana pengguna harus melakukan

backup data, dan apabila backup tersebut hilang, pengguna harus

mengulang kembali peng-input-an data. Kebalikannya, DBMS modern

menyediakan fasilitas untuk mengurangi jumlah proses yang harus

dilakukan ketika terjadi kegagalan sistem tersebut.

Kekurangan dari DBMS :

Kompleksitas

Fungsionalitas yang diharapkan dari DBMS membuat DBMS menjadi

software yang sangat kompleks. Pengguna DBMS harus memahami dengan

baik setiap fungsi dari DBMS untuk mendapatkan keuntungan maksimum

dari DBMS tersebut. Ketidakpahaman atas sistem dapat menyebabkan

pengambilan keputusan perancangan yang buruk akan mengakibatkan

dampak serius pada organisasi.

13

Ukuran

Kompleksitas dan fungsionalitas yang baik membuat DBMS menjadi

sebuah software yang berukuran sangat besar dan membutuhkan disk space

yang sangat besar serta jumlah memory yang besar agar dapat dijalankan

seefisien mungkin.

Harga DBMS

Harga DBMS sangat bervariasi tergantung dari lingkungan dan fungsi yang

disediakan termasuk biaya pemeliharaan.

Biaya perangkat keras tambahan

Kebutuhan disk storage untuk DBMS dan database menyebabkan

kemungkinan untuk membeli storage tambahan. Selain itu, untuk

mendapatkan perfoma yang diinginkan, dibutuhkan perangkat keras yang

cepat dan baik tetapi mahal.

Biaya konversi

Pada beberapa situasi, biaya yang dibutuhkan untuk mengubah aplikasi

agar dapat berjalan pada DBMS yang baru dapat jauh lebih mahal dari

biaya perangkat keras tambahan. Biaya tersebut juga termasuk biaya

pelatihan pegawai untuk menggunakan sistem yang baru, dan mungkin juga

biaya pegawai spesialis untuk membantu konversi dan pelaksanaan sistem.

Perfoma

Biasanya file-based system ditulis untuk aplikasi khusus yang

mengakibatkan perfoma secara umum sangat baik. Akan tetapi DBMS

dibuat secara umum untuk dapat menjalankan berbagai aplikasi yang

14

mengakibatkan beberapa aplikasi berjalan lebih lambat dari yang

seharusnya.

Dampak yang besar akibat kegagalan

Pemusatan sumber daya menambah kerawanan pada sistem. Karena semua

pemakai dan aplikasi tergantung pada DBMS, kegagalan pada satu bagian

dapat mengakibatkan sistem terhenti.

2.1.4 Database Language

Data sublanguage terdiri dari dua bagian yaitu Data Definition Language

(DDL) dan Data Manipulation Language (DML). DDL digunakan secara

spesifik untuk skema database, dan DML digunakan untuk membaca dan

memperbarui database. Bahasa ini disebut sebagai data sublanguage karena

tidak memasukkan bentuk pengulangan dan kondisional yang disediakan oleh

bahasa pemrograman tingkat tinggi. Banyak DBMS mempunyai fasilitas untuk

memasukkan sublanguage ke dalam bahasa pemrograman tingkat tinggi seperti

COBOL, Fortran, Pascal, C, C++, Java, Visual Basic, dll.

2.1.4.1 Data Definition Language (DDL)

DDL adalah sebuah bahasa yang membolehkan DBA atau pemakai untuk

menggambarkan dan menamai sebuah entity, attribute, dan relationship yang

dibutuhkan oleh aplikasi, bersama dengan suatu associated integrity dan security

constraint.

Hasil dari kompilasi statement DDL adalah himpunan tabel yang tersimpan

pada kumpulan file tertentu yang disebut sebagai system catalog. System catalog

15

berintegrasi dengan meta-data, di mana data tersebut menjelaskan obyek-obyek

di dalam database dan mempermudah pengaksesan serta manipulasi objek.

Meta-data berisi definisi dari record, data item, dan obyek-obyek lainnya yang

dibutuhkan oleh DBMS. DBMS biasanya memeriksa system catalog sebelum

data aktual diakses pada database. Data dictionary dan data directory biasanya

digunakan untuk menggambarkan system catalog, meskipun data dictionary

biasanya lebih banyak digunakan pada sistem perangkat lunak umum

dibandingkan dengan DBMS.

2.1.4.2 Data Manipulation Language (DML)

DML adalah sebuah bahasa yang menyediakan sejumlah operasi yang

mendukung proses manipulasi data dasar yang ada pada database.

Proses manipulasi data yang biasanya digunakan :

• Memasukkan data baru ke dalam database.

• Memodifikasi data yang tersimpan dalam database.

• Mengambil data yang terdapat dalam database.

• Menghapus data dari database.

Oleh karena itu, salah satu fungsi utama DBMS adalah mendukung DML

yang dapat digunakan oleh pemakai untuk membangun statement agar

manipulasi data dapat terjadi. Manipulasi data berlangsung pada internal,

conceptual, dan external level. Bagian dari DML yang melibatkan pengambilan

data disebut query language.

16

DML dibedakan menurut cara pengambilan data, yaitu procedural dan non-

procedural. Perbedaan utama antara kedua DML bahwa procedural menjelaskan

bagaimana cara mendapatkan hasilnya sedangkan non-procedural menjelaskan

hasil apa yang akan didapatkan.

2.1.5 Database Application Lifecycle

Sistem informasi adalah sumber yang dapat mengumpulkan, mengelola,

mengatur, dan membagi segala informasi untuk organisasi. Menurut Connolly

(2002, p270) sejak tahun 1970, sistem database telah menggantikan penggunaan

file-based system sebagai bagian sistem informasi dari perusahaan. Oleh karena

itu, banyak organisasi mendirikan bagian yang berfungsi khusus sebagai data

administration (DB) dan database administration (DBA), yang bertanggung

jawab untuk mengelola dan mengatur data perusahaan dan database perusahaan.

Sistem informasi berbasis komputer terdiri dari sebuah database, piranti

lunak database, piranti lunak aplikasi, perangkat keras komputer, dan pemakaian

perseorangan dan perkembangan sistem.

Komponen terpenting dari sistem informasi adalah database. Pemakaian dan

perkembangan dari database harus memenuhi kebutuhan terbesar dari

perusahaan. Sistem Basisdata adalah penerapan database ke dalam sistem

informasi

Tingkatan dari information systems lifecycle atau software development

lifecycle (SDLC) terdiri dari perencanaan, analisis kebutuhan, perancangan,

pembuatan prototype, implementasi, testing, konversi, dan operasi pemeliharaan.

17

Tingkatan dari database application lifecycle memiliki bentuk yang tidak kaku,

tetapi mengikuti bentuk dari bentuk semula yaitu feed back loops.

Untuk aplikasi database kecil, dengan jumlah pemakai yang kecil, siklus

hidup yang diperlukan tidak terlalu kompleks. Meskipun begitu, ketika

merancang database aplikasi menengah ke atas dengan jumlah pemakai dari 10

hingga 1000, menggunakan ratusan query dan program aplikasi, siklus hidup

dapat menjadi sangat kompleks.

18

Gambar 2.1 Database Application Lifecycle

Database planning

System definition

Testing

Requirements collection and

analysis

Implementation

Application design

Prototyping

Data conversion and loading

DBMS selection

Operational maintenance

Physical database design

Logical database design

Database design

Conceptual database design

19

Langkah-langkah dalam siklus hidup database aplikasi :

• Database planning, adalah merencanakan bagaimana setiap langkah dapat

dijalankan seefisien dan seefektif mungkin.

• System definition, adalah menspesifikasi ruang lingkup dan batasan dari

aplikasi database, pemakai, dan area aplikasi.

• Requirement collection and analysis, adalah analisa dan pengumpulan

kebutuhan-kebutuhan dari pemakai dan area aplikasi.

• Database design, adalah perancangan conceptual, logical, dan physical dari

database.

• DBMS selection, adalah memilih DBMS yang cocok untuk aplikasi

database.

• Application design, adalah merancang antarmuka pemakai dan program

apikasi yang menggunakan dan memproses database.

• Prototyping, adalah membuat sebuah model kerja dari aplikasi database

yang membolehkan perancang atau pemakai untuk memvisualisasikan dan

mengevaluasi bagaimana sistem yang dibuat akan berjalan.

• Implementation, adalah membuat definisi external, conceptual, dan internal

database dan aplikasi program.

• Data conversion and loading, adalah memasukkan data dari sistem lama ke

sistem baru.

• Testing, adalah aplikasi database akan diuji untuk mendapatkan kesalahan

dan divalidasi dengan kebutuhan yang dispesifikasi pemakai.

20

• Operational maintenance, adalah aplikasi database telah

diimplementasikan sepenuhnya. Sistem tersebut akan diawasi dan dirawat

berkala. Ketika dibutuhkan, kebutuhan baru dapat ditambahkan ke dalam

aplikasi database melalui langkah-langkah siklus hidup.

2.1.6 Normalisasi

Normalisasi adalah sebuah teknik untuk menghasilkan sebuah relasi dengan

properti yang diinginkan sesuai dengan kebutuhan data dari suatu perusahaan.

Menurut Connolly (2002, p376) proses normalisasi pertama kali dikembangkan

oleh E. F. Cood. Normalisasi seringkali dilakukan dengan cara menjalankan

serangkaian tes pada relasi untuk menentukan apakah itu dapat memenuhi

kebutuhan sesuai dengan bentuk normal.

Proses normalisasi merupakan metoda yang mengidentifikasi relasi

berdasarkan primary key atau candidate key dan ketergantungan fungsional di

antara atribut-atributnya. Proses ini juga berguna untuk menghindari anomaly

update. Anomaly update bisa terjadi karena adanya duplikasi data.

Urutan proses dari normalisasi berdasarkan urutannya :

• Unnormalized Form (UNF)

Ini merupakan sebuah tabel yang masih memiliki satu atau lebih kumpulan

data yang berulang.

• First Normal Form (1NF)

Pada tahap ini data yang berada dalam setiap kolom dan baris dibuat

bernilai tunggal. Ini dilakukan dengan cara menghilangkan grup data yang

21

berulang dengan memasukkan data yang cocok pada kolom yang kosong

dari baris yang memiliki data berulang tersebut.

• Second Normal Form (2NF)

Tahap ini berdasarkan pada konsep full functional dependency. Full

functional dependency mengidentifikasi bahwa jika A dan B adalah atribut

dari sebuah relasi, B memiliki full functional dependency terhadap A jika B

memiliki ketergantungan fungsional terhadap A, tapi tidak pada subset dari

A. Jadi definisi dari 2NF adalah relasi yang 1NF dan setiap atribut yang

bukan primary key memiliki full functional dependency terhadap primary

key.

• Third Normal Form (3NF)

Ini adalah relasi yang sudah dalam bentuk 1NF dan 2NF, dan dimana tidak

ada atribut yang bukan primary key memiliki transitive dependency

terhadap primary key.

• Boyce-Codd Normal Form(BCNF)

Suatu relasi dikatakan BCNF jika dan hanya jika, setiap determinan adalah

candidate key. Untuk menentukan apakah suatu relasi adalah BCNF, kita

menentukannya dengan mengidentifikasi semua determinan dan

memastikan semua itu adalah candidate key.

• Fourth Normal Form(4NF)

Sebuah relasi dikatakan 4NF saat relasi tersebut dalam BCNF dan tidak

lagi memiliki non-trivial Multi Valued Dependencies(MVD). MVD sendiri

22

adalah dependensi antara atribut-atribut dalam relasi meskipun relasi

tersebut telah BCNF sehingga menyebabkan redundansi data.

• Fifth Normal Form(5NF)

5NF atau juga disebut Project-Join Normal Form(PJNF) adalah sebuah

relasi yang tidak lagi memiliki join dependency.

2.1.7 Perancangan Database

Metodologi desain adalah pendekatan terstruktur yang menggunakan

prosedur, teknik, tool, dan bantuan dokumentasi untuk mendukung dan

memfasilitasi proses perancangan. Metodologi desain terdiri dari beberapa fase

berisi langkah-langkah yang membantu perancang menentukan teknik yang

cocok untuk digunakan pada setiap langkah, serta membantu perancang untuk

merencanakan, mengelola, mengontrol, dan mengevaluasi proyek pengembangan

database. Perancangan database terbagi menjadi perancangan konseptual,

perancangan logikal, dan perancangan fisikal.

2.1.7.1 Perancangan Konseptual

Perancangan konseptual adalah proses membangun model informasi yang

digunakan oleh perusahaan, dan terlepas dari segala pertimbangan fisik seperti

program aplikasi, bahasa pemrograman yang digunakan, platform perangkat

keras, dll.

Tahap-tahap perancangan konseptual :

23

o Membangun model data konseptual lokal untuk setiap view

Bertujuan untuk membangun model data konseptual lokal dari

perusahaan untuk setiap view tertentu. Selama analisa, sejumlah

view pemakai mungkin telah diidentifikasi dan tergantung dari

jumlah bagian yang saling overlap di antara view tersebut, beberapa

view pemakai mungkin harus digabungkan untuk membentuk

collective view. Tugas-tugas yang termasuk dalam langkah ini

adalah :

• Mengidentifikasi entity type

Tahap ini bertujuan untuk mengidentifikasi entity type utama dari

view. Salah satu metode yang digunakan untuk mengidentifikasi

entity adalah dengan memeriksa spesifikasi kebutuhan pemakai.

Dari spesifikasi ini, perancang mengidentifikasi kata benda atau

frase benda seperti nomor staff, nama staff. Metode alternatif

untuk mengidentifikasi entity adalah dengan mencari obyek yang

keberadaannya tidak bergantung pada obyek lain. Sebagai contoh

staff adalah entity meskipun nama, tanggal lahir, dan posisi

mereka tidak diketahui.

• Mengidentifikasi relationship type

Tahap ini bertujuan untuk mengidentifikasi relationship penting

yang terdapat di antara entity type yang telah diidentifikasi. Salah

satu metode yang digunakan adalah dengan menggunakan

spesifikasi kebutuhan pemakai di mana biasanya relationship

diindikasikan dengan kata benda atau ekspresi verbal.

24

• Mengidentifikasi dan menghubungkan atribut dengan entity atau

relationship type

Tahap ini bertujuan untuk menghubungkan atribut dengan entity

atau relationship type yang sesuai.

• Menentukan domain atribut

Tahap ini bertujuan untuk menentukan domain untuk setiap

atribut pada model data konseptual lokal. Domain atribut adalah

himpunan dari nilai yang diizinkan untuk satu atau lebih atribut.

• Menentukan atribut candidate dan primary key

Tahap ini bertujuan untuk mengidentifikasi candidate key untuk

setiap entity type dan jika terdapat lebih dari satu candidate key

maka dipilih satu untuk menjadi primary key.

• Mempertimbangkan penggunaan enhanced modeling concept

Tahap ini bertujuan untuk mempertimbangkan penggunaan

enhanced modeling concept seperti specialization/generalization,

aggregation, dan composition.

• Mengecek model dari redundancy

Tahap ini bertujuan untuk mengecek redundancy yang mungkin

terdapat pada model untuk kemudian dihilangkan dari model

tersebut.

• Memvalidasi model konseptual lokal terhadap transaksi pemakai

Tahap ini bertujuan untuk memastikan bahwa model konseptual

lokal mendukung transaksi yang dibutuhkan oleh view.

25

• Meninjau ulang model konseptual lokal bersama dengan pemakai

Untuk meninjau model data konseptual lokal bersama dengan

pemakai untuk memastikan bahwa model tersebut sungguh-

sungguh merupakan representasi dari view.

2.1.7.2 Perancangan logikal

Perancangan logikal adalah proses membangun model informasi yang

digunakan perusahaan berdasarkan pada model data khusus, tetapi terlepas dari

DBMS dan pertimbangan fisik tertentu. Tahap-tahap perancangan logikal :

o Membuat dan memvalidasi model data logikal lokal untuk

setiap view

Tahap ini bertujuan untuk membangun model data logikal lokal

dari model data konseptual yang menggambarkan view tertentu dari

perusahaan dan kemudian divalidasi untuk memastikan model

tersebut mendukung transaksi yang diperlukan. Langkah-langkah

pada tahap ini adalah :

• Menghilangkan fitur yang tidak sesuai dengan relational model

(optional)

Langkah ini bertujuan untuk memperbaiki model data konseptual

lokal dengan menghilangkan fitur yang tidak sesuai dengan

relational model. Akan tetapi, model data mungkin berisi

beberapa struktur yang tidak dapat dimodelkan dengan mudah

oleh DBMS konvensional, sehingga pada tahap ini struktur

26

tersebut diubah menjadi bentuk yang lebih mudah dikelola oleh

sistem. Secara lengkap tahap ini bertujuan untuk :

- menghilangkan many-to-many (*:*) binary relationship type

- menghilangkan many-to-many (*:*) recursive relationship

type

- menghilangkan complex relationship type

- menghilangkan atribut multi-valued

• Membuat relasi untuk model data logikal lokal

Langkah ini bertujuan membuat relasi model data logikal lokal

untuk menggambarkan entity, relationship, dan atribut yang telah

diidentifikasi.

Komposisi dari setiap relasi digambarkan dengan Database

Definition Language (DBDL) untuk setiap relasi database lalu

primary key dan alternate/foreign key dari relasi diidentifikasikan.

Perancang harus menggambarkan bagaimana struktur-struktur

dibawah ini dipresentasikan pada model data.

- Strong entity type

- Weak entity type

- One-to-many (1:*) binary relationship type

- One-to-one (1:1) binary relationship type

a. mandatory participation pada kedua sisi

b. mandatory participation pada salah satu sisi

c. optional participation pada kedua sisi

- One-to-one (1:1) recursive relationship

27

- Superclass/subclass relationship type

- Many-to-many (*:*) binary relationship type

- Complex relationship type

- Atribut multi-valued

• Memvalidasi relasi menggunakan normalisasi

Langkah ini bertujuan untuk memvalidasi relasi pada model data

logikal lokal menggunakan teknik normalisasi.

• Memvalidasi relasi terhadap transaksi pemakai

Langkah ini bertujuan untuk memastikan bahwa relasi pada model

data logikal lokal mendukung transaksi yang dibutuhkan oleh

view

• Mendefinisikan integrity constraint

Langkah ini bertujuan untuk mendefinisikan integrity constraint

yang diberikan oleh view. Integrity constraint adalah constraint

yang harus diperhatikan untuk menjaga database agar tetap

konsisten. Ada lima jenis integrity constraint :

- Data yang dibutuhkan

- Attribute domain constraint

- Entity integrity

- Referential integrity

- Enterprise constraint

28

• Meninjau ulang model data logikal lokal bersama dengan pemakai

Langkah ini bertujuan untuk memastikan bahwa model data

logikal lokal dan dokumen pendukung yang menggambarkan

model tersebut sungguh-sungguh merupakan gambaran

sebenarnya dari view.

o Membuat dan memvalidasi model data logikal global

Jika aplikasi database hanya memiliki satu view, maka

perancangan dapat langsung dilanjutkan ke tahap perancangan

fisikal. Akan tetapi, jika aplikasi database memiliki lebih dari satu

view maka langkah selanjutnya adalah membangun dan

memvalidasi model data logikal global. Langkah-langkah pada

tahap ini adalah :

• Menggabungkan model data logikal lokal menjadi model global

Langkah ini bertujuan untuk menggabungkan model data logikal

lokal menjadi sebuah model data logikal global dari sebuah

perusahaan. Pendekatan yang digunakan pada langkah ini

mengacu pada karya tulis oleh Batini dan Lanzerini (1986),

Biskup dan Convent (1986), Spaccapietra et al. (1992), dan

Bouguettaya et al.(1998), dengan tahap-tahap :

- Meninjau ulang nama dan isi dari entiti/relasi dan candidate

key masing-masing.

- Meninjau ulang nama dan isi dari relationship/foreign key.

- Menggabungkan entiti/relasi dari model data lokal.

29

- Memasukkan (tanpa menggabungkan) entity/relasi yang unik

ke setiap model data lokal.

- Menggabungkan relationship/foreign key dari model data

lokal.

- Memasukkan (tanpa menggabungkan) relationship/foreign

key yang unik ke setiap model data lokal.

- Mengecek apakah ada entity/relasi dan relationship/foreign

key yang hilang.

- Mengecek foreign key.

- Mengecek integrity constraint.

- Menggambar diagram ER/relasi.

- Meng-update dokumentasi.

• Memvalidasi model data logikal global

Langkah ini bertujuan untuk memvalidasi relasi yang dibuat dari

model data logikal global menggunakan teknik normalisasi dan

untuk memastikan relasi tersebut mendukung transaksi yang

dibutuhkan.

• Mengecek perkembangan di masa depan

Langkah ini bertujuan untuk menentukan apakah terdapat

perubahan penting yang akan terjadi di masa depan dan untuk

memastikan bahwa model data logikal global dapat

mengakomodasi perubahan tersebut.

30

• Meninjau ulang model data logikal global bersama dengan

pemakai

Langkah ini bertujuan untuk memastikan bahwa model data

logikal global merupakan gambaran sebenarnya dari perusahaan.

2.1.7.3 Perancangan Fisikal

Perancangan fisikal database adalah proses pembuatan deskripsi dari

implementasi database ke dalam media penyimpanan, dimana deskripsi itu

menjelaskan relasi dasar, organisasi file, dan indeks yang digunakan untuk

mendapatkan akses yang efisien terhadap data dan integrity constraint, dan

tingkat keamanan. Langkah dari perancangan fisikal database adalah :

o Menterjemahkan model data logikal global ke dalam DBMS

yang dipilih

Tujuan utama dari langkah ini adalah membuat skema relational

database dari model data logikal global yang dapat

diimplementasikan pada DBMS yang dipilih. Bagian pertama dari

proses ini adalah mengumpulkan informasi yang di dapat selama

perancangan logikal database dan dokumentasi kamus data. Dan

bagian kedua dari proses ini adalah menggunakan informasi tadi

untuk membuat rancangan dari relasi dasar. Proses ini memerlukan

pengetahuan yang dalam mengenai fungsionalitas yang ditawarkan

oleh DBMS yang akan digunakan.

31

• Merancang relasi dasar

Tujuan utama dari bagian ini adalah memutuskan bagaimana

merepresentasikan relasi dasar yang telah diidentifikasi pada

model data logikal global pada DBMS. Yang dilakukan pertama

kali adalah mengumpulkan dan memahami informasi mengenai

relasi yang telah dihasilkan dari perancangan database logikal.

Informasi yang diperlukan dapat diperoleh dari kamus data dan

definisi dari relasi yang digambarkan menggunakan Database

Design Language (DBDL).

• Merancang representasi dari derived data

Tujuan utama dari bagian ini adalah memutuskan bagaimana

merepresentasikan semua derived data yang terdapat pada model

data logikal global pada DBMS. Derived data adalah atribut yang

nilainya didapat dari memeriksa nilai dari atribut-atribut lain.

Contohnya adalah jumlah gaji bulanan adari seluruh pekerja.

Terkadang atribut derived tidak muncul dalam model data logikal,

tetapi ada dalam kamus data.

• Merancang enterprise constraint

Tujuan utama langkah ini adalah merancang enterprise constraint

bagi DM Tujuan utama dari bagian ini adalah memutuskan

bagaimana merepresentasikan relasi dasar yang telah di

identifikasi pada model data logikal global pada DBMS yang akan

digunakan. Pengubahan terhadap relasi sangat tergantung pada

32

peraturan-peraturan organisasi menurut transaksi yang terjadi

yang akan dijelaskan oleh pengubahan itu. Pembuatan enterprise

constraint tergantung terhadap DBMS yang dipilih, beberapa

sistem menyediakan fasilitas yang lebih daripada yang lain untuk

menjelaskan enterprise constraint.

o Merancang Representasi fisikal

Pada langkah ini ditentukan organisasi file yang optimal untuk

menyimpan relasi dasar dan indeks yang dibutuhkan untuk

mendapatkan performa yang dapat diterima. Ada beberapa faktor

untuk menghitung tingkat efisiensi dari database yaitu :

Transaction throughput. Ini adalah jumlah dari transaksi yang

dapat diproses dalam jangka waktu tertentu.

Response time. Ini adalah waktu yang dibutuhkan untuk

menyelesaikan sebuah transaksi.

Disk storage. Ini adalah jumlah dari kapasitas disk yang

dibutuhkan untuk menyimpan database.

Langkah-langkah pada tahap ini adalah :

• Menganalisa transaksi

Pada saat ini, diperlukan untuk mengerti fungsi dari transaksi

yang akan dijalankan oleh database dan untuk menganalisa

transaksi-transaksi yang penting. Untuk menghasilkan

perancangan database fisikal yang efektif, penting untuk

33

mengetahui transaksi atau query yang akan dijalankan pada

database. Ini termasuk kualitatif dan kuantitatif dari informasi.

Pada penganalisaan transaksi, dicoba untuk mengidentifikasi

beberapa kriteria seperti transaksi yang berjalan secara berulang-

ulang dan memiliki dampak yang berarti, transaksi yang penting

bagi operasi bisnis dan sebagainya. Informasi ini digunakan untuk

menentukan bagian dari database yang mungkin menyebabkan

masalah bagi perfoma.

• Memilih organisasi file

Tahapan ini digunakan untuk menentukan organisasi file yang

efisien bagi tiap relasi dasar.

• Memilih indeks

Pada bagian ini ditentukan apakah dengan menambah indeks akan

meningkatkan perfoma dari sistem.

• Memperkirakan kebutuhan kapasitas disk

Pada tahap ini diperkirakan jumlah dari kapasitas disk yang

dibutuhkan oleh database yang dibuat.

o Merancang view pemakai

Pada tahapan ini, tujuan utama adalah merancang view

pengguna yang telah didapat selama pengumpulan kebutuhan dan

tahap analisa dari daur hidup aplikasi database relasional.

34

o Merancang mekanisme keamanan

Di bagian ini, dirancang tingkat keamanan dari database yang

telah ditentukan oleh pengguna. Hal ini diperlukan, karena database

mempresentasikan data perusahaan yang penting sehingga

keamanannya menjadi sangat penting. Secara umum DBMS

menyediakan dua tipe keamanan, yaitu keamanan sistem dan

keamanan data. Keamanan sistem meliputi akses dan penggunaan

dari database pada tingkat sistem seperti nama pemakai dan

password. Keamanan data meliputi akses dan penggunaan dari

obyek database (seperti relasi dan view) dan aksi yang dilakukan

pemakai terhadap obyek.

o Mempertimbangkan pengontrolan redundancy

Tahap ini bertujuan untuk menentukan apakah penggunaan

redundancy pada lingkungan terkontrol dengan mengurangi

normalisasi dapat meningkatkan perfoma dari sistem.

o Memonitor dan mengatur sistem operasional

Tahap ini bertujuan untuk mengawasi sistem operasional dan

perfoma dari sistem untuk memperbaiki keputusan desain yang

kurang tepat atau penggambaran perubahan kebutuhan.

35

2.2 Teori-teori Khusus yang Berhubungan dengan Topik yang Dibahas

2.2.1 UML

2.2.1.1 Use Case

Sebuah bagian penting dari Unified modelling language (UML) adalah

fasilitas yang memungkinkan kita untuk menggambar sebuah diagram, yaitu

diagram use-case. Use case digunakan selama tahap analisis dalam sebuah

proyek untuk mengidentifikasikan dan membagi fungsi dari sistem. Diagram ini

membagi-bagi sistem menjadi actor dan use cases.

Actors mewakili peran-peran yang dapat dikerjakan oleh user di dalam

sistem. User-user ini dapat berupa manusia, bagian hardware komputer atau

bahkan software sistem yang lain. Salah satu kriteria adalah mereka harus berada

di luar bagian dari use case sebuah sistem. Mereka harus menyediakan masukan

(inputan) ke dalam system dan mereka akan mendapatkan keluaran (output) dari

sistem tersebut.

Use case menjelaskan tentang cara kerja dari sistem setelah mendapat

inputan dari actor. Cara kerja ini dijelaskan secara rinci. Use case menjelaskan

tentang hal-hal seperti, masukan dari seorang actor dan bagaimana keluaran yang

diterima oleh actor lain, dan cara kerja yang dapat merubah suatu masukan

menjadi keluaran.

Use case merupakan suatu diagram yang sangat berguna bagi pihak analis

saat mengelompokkan fungsi-fungsi dari sistem. Hubungan-hubungan antara

cases dan diagram-diagram yang berhubungan dapat membantu pihak analis

untuk membuat struktur dari sebuah sistem. Tetapi use cases bukanlah sebuah

alat desain, mereka tidak digunakan untuk memspesifikasikan sebuah software

36

atau mereka tidak melibatkan sebuah keberadaan kelas-kelas dan obyek-obyek.

Use case merupakan sebuah deskripsi tentang sebuah sistem yang secara murni

terpisah dari tahap desain sebuah software.

Gambar 2.2 Use Case Diagram

2.2.1.2 Sequence diagram

Sequence diagram berisi informasi yang sama dengan collaboration

diagram, tetapi menekankan pada alur sekuensial sebuah pesan daripada

hubungan antara obyek-obyek. UML sequence diagram menggambarkan alur

dari logika di dalam sistem secara visual, sehingga memungkinkan kita untuk

menyimpan dan mengvalidasi logika kita. Sequence diagram juga digunakan

secara umum untuk keperluan analisis dan desain.

37

Gambar 2.3 Sequence Diagram

2.2.1.3 Class diagram

UML class diagrams adalah sebuah alat analisis dan desain yang

beorientasi obyek. Class diagrams memperlihatkan kelas-kelas yang ada pada

sistem, hubungan-hubungan yang ada (termasuk inheritance, aggregation, dan

association), dan operasi-operasi serta atribut-atribut dari kelas. Class diagrams

digunakan untuk sebuah variasi tujuan yang luas, termasuk kedua modeling

conceptual atau domain dan desain model secara detil.

Model class di dalam UML adalah sebuah artifak utama yang diciptakan

untuk menggambarkan struktur logika dari sebuah sistem pada software. Model

class mengambil data-data dan cara kerja dari obyek-obyek di dalam domain

model. Class adalah sebuah entity logika dasar pada UML. Class model

menjelaskan data dan cara kerja dari sebuah unit yang terstruktur. Class adalah

38

sebuah template atau model yang merupakan dasar terciptanya obyek-obyek

selama run-time. Ketika kita mengembangkan sebuah model logical seperti

struktur hirarki di dalam UML, kita secara langsung berhubungan dengan class.

Gambar 2.4 Class Diagram

2.2.2 ERD

Entity Relationship modelling banyak digunakan untuk menampilkan

model konseptual khususnya berhubungan dengan desain database.

Entity dan relationship diwakilkan dalam bentuk diagram, di ER diagram:

- Kotak mewakili type entity.

- Diamond dan hubungan garis mewakilkan type dari relationship yang

ada diantara mereka.

39

- Nomor yang ada di persegi yang berada pada akhir garis relationship

menunjukkan nomor minimum atau maksimum dari entity yang bisa

digunakan. Di sebut cardinality relationship.

Untuk menentukan cardinality dari relationship diperlukan beberapa

petunjuk. Jika entity X dan Y berhubungan maka kita harus menganggap X

dihubungkan dengan Y dan Y dihubungkan dengan X.

Berikut type relationship yang diidentifikasikan:

• one-to-one (1:1) Relationship Staff Manages Branch

Multiplicity dari relationship Staff Manages Branch (1:1)

• one-to-many (1 : *) Relationship dari Staff Oversees PropertyForRent

40

Multiplicity dari relationship Staff Oversees PropertyForRent

• many-to-many (* : *) Relationship Newspaper Advertises PropertyForRent

Multiplicity dari relationship Newspaper Advertises PropertyForRent (*:*)