BAB 2 LANDASAN TEORI

BAB 2 LANDASAN TEORI

2.1 Teori Umum 2.1.1 Pengertian Sistem Menurut Mcleod (1996,p13) sistem adalah sekelompok elemen-elemen terintegrasi yang memiliki maksud yang sama untuk mencapai suatu tujuan 2.1.2 Pengertian Data Menurut kadir (1998,P7) data adalah fakta mengenai suatu objek atau orang. Data dinyatakan dengan nilai (angka,deretan karakter,atau symbol). Hirarki data menurut Kadir(1998,P8-P9) terdiri atas elemen data(field), record,dan berkas(file).

- Elemen data Elemen data adalah satuan data terkecil yang tidak dapat dipecah lagi menjadi unit lain yang lebih kecil dan bermakna.Istilah lain untuk elemen data adalah field, kolom, Item, dan atribut

- Record Record adalah gabungan sejumlah elemen data yang saling terkait. Dalam Sistem Basis Data relational,record biasa disebut dengan istilah tuple atau baris

7

8 - File Himpunan seluruh record yang bertipe sama membentuk sebuah file. File dapat dikatakan sebagai kumpulan record yang berkaitan dengan suatu subjek. Dalam Sistem Basis Data relational,file mewakili komponen yang biasa disebut tabel atau relasi 2.1.3 Pengertian basis data Menurut Connolly dan Begg (2002, p14), basis data merupakan suatu kumpulan data yang berhubungan secara logis, dan deskripsi dari data tersebut, dirancang untuk memenuhi informasi yang dibutukan oleh sebuah organisasi. Artinya Database merupakan tempat penyimpanan data yang besar, dimana dapat digunakan secara simultan oleh banyak pengguna. Selain itu Database merupakan suatu objek yang digunakan untuk menyimpan informasi terstruktur, yang diorganisir dan disimpan dengan aturan-aturan tertentu sehingga pemakai dapat mengambil informasi tersebut dengan cepat dan efisien. Database tidak hanya mengandung data operasional saja tetapi juga deskripsi dari data tersebut. Oleh karena itu, sebuah database juga didefinisikan sebagai self – describing of integrated record. Deskripsi dari data yang disimpan oleh database dikenal sebagai sistem katalog (data dictionary atau meta-data). Deskripsi ini menciptakan kebebasan dari program aplikasi (program - data independence). Menurut Ramakrishnan (2003, p4) basis data adalah koleksi data yang secara khusus mendeskripsikan aktivitas 1 atau lebih organisasi yang berhubungan. Menurut Kristanto (1993,p1) basis data adalah kumpulan file-file yang saling berelasi,relasi tersebut biasa ditunjukkandengan kunci dari tiap file yang ada. Basis

9 data menunjukkan suatu kumpulan data yang dipakai dalam 1 lingkup perusahaan / instansi. Menurut Kusumo (2003,p2) basis data adalah kumpulan informasi yang ditulis dalam 1 atau lebih tabel. Menurut Atzeni (2003, p2) basis data adalah koleksi data yang digunakan untuk merepresentasikan informasi yang berguna bagi suatu sistem informasi

2.1.4 Pengertian Sistem Basis Data Menurut date(2000,P5) sistem basis data pada dasarnya adalah sistem penyimpanan record yang terkomputerisasi dimana tujuan sebenarnya adalah penyimpanan informasi dan membuat informasi tersebut selalu tersedia saat dibutuhkan. Keseluruhan sistem terkomputerisasi tersebut memperbolehkan user atau pengguna untuk menelusuri kembali, dan mengubah informasi tersebut sesuai kebutuhan.

2.1.5 Pengertian informasi Menurut Mcleod(1998,P1) informasi adalah data yang diproses dan memiliki arti. Menurut Kadir(1998,P7) informasi adalah data yang telah diorganisasikan ke dalam suatu

bentuk yang sesuai dengan kebutuhan

seseorang,entah itu manajer,staff ataupun orang lain di dalam suatu organisasi atau perusahaan.

2.2 Teori Khusus 2.2.1 Model data relational

10 Model data relational diperkenalkan pertama kali pada tahun 1970 oleh E.F Codd. Model data relational dibangun berdasarkan konsep matematika dari relation yang direpresentasikan secara fisik sebagai tabel. 2.2.1.1 Struktur data relational a. Relation Relation adalah tabel yang memiliki baris dan kolom

b. Atribute Atribute adalah kolom dari suatu relation yang memiliki nama

c. Domain Domain adalah kumpulan dari nilai-nilai yang diperbolehkan bagi suatu atribute pada relation

d. Tuple Tuple adalah suatu baris yang ada pada relation

e. Degree Degree dari suatu relation adalah banyaknya atribute yang ada pada relation tersebut

e. Cardinality Cardinality dari suatu relation adalah banyaknya tuple yang ada pada suatu relation

11 f. Relational database adalah kumpulan relation yang telah dinormlissi serta memiliki nama yang berbeda-beda

Atributes

No Pegawai

Nama Awal

Nama Akhir

Usia

PEG1

I Nyoman

Wirama

22

PEG2

Nathaniel

Soma

24

PEG3

Anthonius

Ferdinand

24

Cardinality

Degree Tabel 2.1 Contoh relation

2.2.1.2 Kunci Relational a. Simple key Adalah atribut yang tidak dapat dipecah lagi menjadi atribut yang lebih sederhana

b. Composite key Adalah atribut yang bisa terdiri dari beberapa attribute

12 c. Super key Adalah

sebuah

attribute

atau

kumpulan

atribute

yang

mengidentifikasikan suatu tuple secara unik pada suatu relation

d. Candidate key Adalah super key yang tidak memiliki bagian yang juga dapat menjadi super key pada suatu relation

e. Primary key Adalah candidate key yang dipilih untuk mengidentifikasikan sebuah tuple secara unik dalam suatu relation

f. Foreign key Adalah atribut atau kumpulan atribut didalam suatu relation yang cocok dengan candidate key dari beberapa relation yang lain

2.2.1.3 Relational Integrity a. Null Merepresentasikan nilai suatu atribut yang pada saat ini tidak diketahui,atau tidak tersedia untuk tuple yang bersangkutan

b. Entity Integrity Pada sebuah relation,tidak boleh ada atribut yang merupakan primary key bernilai null

13

c. Referential Integrity Jika terdapat foreign key pada sebuah relation maka foreign key tersebut harus memiliki nilai yang cocok dengan nilai candidate key pada relation asalnya atau foreign key tersebut harus bernilai null.

2.2.2 Database Management System (DBMS) Menurut Connolly dan Begg (2002, p16), DBMS adalah suatu sistem piranti lunak yang memungkinkan user untuk mendefinisikan, membuat, memelihara, dan mengontrol akses ke database. Menurut Silberschatz (2002, p21) DBMS terdiri dari sebuah koleksi data dan program-program yang mengakses data tersebut. Menurut Post (2002, p2) DBMS adalah piranti lunak yang mendefinisikan basis data, menyimpan data, mendukung query, menghasilkan laporan, dan membuat layer entri data. Menurut Mannino (2001, p9) DBMS adalah koleksi software yang mendukung pembuatan, pemeliharaan dan penggunaan DBMS. Pada umumnya DBMS menyediakan fasilitas-fasilitas berikut : 1. Fasillitas bagi user untuk mendefinisikan database,umumnya melalui data definition language (DDL). DDL memperbolehkan user untuk menspesifikasikan tipe data, struktur, serta constraints dari data yang akan disimpan di database 2. Fasiltas bagi user untuk melakukan insert,update,delete serta retrieve terhadap data yang ada di database, umumnya melalui data manipulation language (DML)

14 3. Menyediakan akses yang terkontrol ke database, misalnya DBMS menyediakan : a. Security system : berfungsi mencegah user yang tidak memiliki ijin mengakses database. b. Integrity system

: berfungsi mempertahankan

konsistensi dari data yang tersimpan c. Conccurrency control

system : berfungsi

menyediakan akses yang tersebar. d. Recovery Control System : berfungsi untuk merestore database ke keadaan konsisten sebelumnya, setelah terjadinya kesalahan atau error. e. User accessible catalog : menyimpan deskripsi dari data yang ada di database. Komponen dari Lingkungan DBMS dapat dibedakan menjadi 5, yaitu perangkat keras, perangkat lunak, data, prosedur, dan people.

Perangkat Keras Sistem database dan aplikasi membutukan perangkat keras untuk dapat berjalan. Perangkat keras dapat dikategorikan mulai dari personal komputer, mainframe, sampai sebuah network dari sejumlah komputer. Beberapa sistem database hanya dapat berjalan pada perangkat keras dan sistem operasi tertentu, sementara yang lainnya dapat berjalan pada berbagai jenis perangkat keras dan sistem operasi. Perangkat Lunak

15 Komponen software terdiri dari sistem database itu sendiri dan program aplikasi yang menggunakannya, serta sistem operasi, termasuk perangkat lunak jaringan jika digunakan pada sebuah jaringan. Biasanya, program aplikasi ditulis dalam third – generation progamming language (3GL), seperti C, C++, Java, Visual Basic atau Pascal, atau menggunakan fourth – generation language (4GL), seperti SQL yang terintegrasi dengan third – generation language.

Data Pada umumnya data dalam basis data bersifat integrated dan shared (Date, 2000, p6)Data merupakan komponen penting dari database. Data merupakan penghubung antara mesin dan manusia. Database terdiri dari data operasional dan meta data.

Prosedur Prosedur merupakan instruksi dan aturan yang menentukan pembuatan dan penggunaan dari database. Pengguna membutuhkan prosedur untuk menjalankan dan menggunakan sistem.

People Adalah orang atau sekelompok orang yang merupakan penanggung jawab pada penyelenggaraan basis data. Database administrator mempunyai fungsi yang meliputi berbagai kegiatan seperti pengaturan penempatan data, pengamanan data, recovery prosedur, backup prosedur.

16 Programmer Merupakan tenaga ahli komputer yang berfungsi untuk mengembangkan program – program aplikasi yang diperlukan dalam manajemen basis data. Seringkali suatu aplikasi dalam basis data memang perlu disiapkan dalam bentuk program misalnya untuk bentuk tampilan layar dalam proses penyiapan dan pemuktahiran data, pembuatan laporan – laporan baik yang melalui printer ataupun layar monitor, dan lain – lain. Program aplikasi basis data dapat dikembangkan dengan menggunakan bahasa pemrograman SQL (PL – SQL), menggunakan alat bantu (tools) form dan laporan ataupun presentasi grafis, menggunakan alat bantu CASE, dan lain – lain. Program aplikasi yang dikembangkan dapat juga ditempelkan pada layar Web pada aplikasi internet dan intranet, sehingga bagi pengguna akhir akan menjadi sangat mudah melakukan akses ke dalam basis data.

End User Termasuk dalam kategori pengguna akhir adalah pemilik sistem (enterprise), para manager, supervisor, operator (misalnya karyawan loket bank, bagian pembukuan), pelanggan, dan sebagainya yang terlibat langsung dalam penggunaan basis data. Penggunaan melakukan akses ke dalam basis data menggunakan alat bantu yang dikembangkan oleh programmer / analis, ataupun browser.

Alasan Penggunaan DBMS

17 Berbagai keuntungan dan kerugian yang diperoleh dari hasil penerapan sistem manajemen basis data pada suatu organisasi meliputi beberapa hal berikut : Keuntungan penggunaan basis data : a. Kontrol terpusat data operasional b. Menghilangkan atau mengurangi duplikasi data (data redundancy). c. Ketidakkonsistenan data dapat dihindarkan d. Data dapat dipakai bersama (sharing) f. Penerapan standarisasi g. Meningkatkan keamanan data (security) h. integritas data dapat dipelihara i. Independensi data / program j. Perusahaan dapat mendapatkan informasi yang lebih banyak dan akurat k. Meningkatkat tingkat respon dan accessibility

Kerugian penggunaan basis data : a. Kompleks, karena kemampuan perangkat lunak yang lebih besar, menjadi terlihat

lebih rumit dan penguasaan yang lebih tinggi antara

lain untuk kebutuhan sistem administrasi, prosedur recovery, prosedur backup, penataan keamanan data, penataan dalam rangka proses yang konkuren.

b. Mahal, karena membutuhkan biaya yang lebih besar untuk perangkat keras, perangkat lunak, dan personil yang lebih berkualitas.

18 c. Ukurannya besar,sehingga membutukan banyak alokasi disk space dan memory

d. Mengurangi performa, Karena umumnya database digunakan untuk menangani berbagai jenis aplikasi sehingga beberapa aplikasi memiliki kemungkinan untuk tidak berjalan secepat biasanya.

e. Pengaruh kegagalan yang lebih besar,karena seluruh user dan aplikasi memiliki ketergantungan pada availability database sehingga kegagalan pada salah satu komponen database dapat menyebabkan seluruh operasi perusahaan terhenti

2.2.3 Database Application Lifecycle Database Application life cycle merupakan komponen yang penting dalam sistem basis data karena aplikasi dari database life cycle berkaitan dengan sistem informasi yang ada. Langkah – langkah dari database life cycle dapat dilihat pada gambar 2.1 berdasarkan (Connolly, 2002, p72).

19

Database planning

System definition

Requirement collection and analysis

Database design Conceptual design DBMS Selection (Optinal)

Application design Logical design

Physical design

Prototyping (Optional)

Implementation

Data conversion and loading

Testing

Operational Maintainence

Gambar 2.2 Diagram Database Application Lifecycle

20

Database Application Lifecycle terdiri dari langkah-langkah berikut :

2.2.3.1 Database Planning Aktivitas-aktivitas manajemen yang memungkinkan tahap-tahap pengembangan aplikasi database untuk diwujudkan secara efektif dan efisien. Perencanaan database (database planning) harus terintegrasi dengan keseluruhan strategi sistem informasi dari organisasi atau perusahaan yang bersangkutan Perencanaan database (database planning)

perlu

juga

meliputi

pengembangan

standard

yang

mengurus/memerintah bagaimana data akan dikumpulkan, bagaimana format harus ditetapkan, dokumentasi apa saja yang akan diperlukan, dan bagaimana rancangan dan implementasi dapat diproses. Dalam merancang suatu standard yang baik harus menyediakan suatu basis untuk staff pelatihan dan mengukur pengendalian mutu (quality), dan dapat memastikan bahwa pekerjaan yang ada menyesuaikan diri kepada suatu pola teladan, tanpa tergantung dengan keterampilan

dan

pengalaman staff.

2.2.3.2 System Definition Menentukan ruang lingkup dari aplikasi basis data (database) yang akan dibuat termasuk user dan tempat dimana aplikasi basis data tersebut diterapkan (Connolly, 2002, p274). Sebelum mencoba untuk merancang suatu aplikasi basis data, adalah penting bahwa kita pertama

21 mengidentifikasi batasan-batasan sistem yang ada

dan bagaimana

sistem tersebut dapat menghubungkan dengan bagian lain

yang

terdapat dalam sistem informasi organisasi/perusahaan. Adalah penting bahwa kita menentukan batasan-batasan sistem tidak hanya area aplikasi dan para pemakai yang sekarang, tetapi juga aplikasi dan para pemakai masa depan

2.2.3.3 Requirement Collection and Analysis Proses mengumpulkan dan menganalisis informasi tentang bagian dari organisasi yang di-support oleh aplikasi database dan menggunakan informasi ini untuk mengidentifikasi kebutuhan user terhadap sistem yang baru. Tahapan ini meliputi pengumpulan dan analisa informasi tentang bagian dari perusahaan yang dilayani oleh database. Ada banyak cara untuk memperoleh informasi ini yang disebut teknik fact finding (Connolly, 2002, p276):

Examining documentation Mempelajari

dokumentasi dapat sangat bermanfaat ketika

berusaha memperoleh pengetahuan untuk membangun kebutuhan dari database. Dokumentasi juga membantu menyediakan informasi pada bagian dari perusahaan berkaitan dengan masalah yang dihadapi. Dengan mempelajari dokumen-dokumen, formulir, laporan dan file berkaitan dengan sistem yang ada, dapat dengan cepat diperoleh beberapa pemahaman tentang sistem.

22 Interviewing Mewawancarai adalah teknik yang paling sering digunakan dan biasanya paling berguna. Dengan wawancara dapat diperoleh informasi dari individu-individu secara langsung face to face. Ada beberapa tujuan dalam menggunakan interview seperti menemukan fakta, verifikasi, klarifikasi, menampilkan antusiasme, melibatkan end-user, identifikasi kebutuhan dan memperoleh ide dan opini atau pendapat. Bagaimanapun

menggunakan

teknik

interview

membutuhkan

kemampuan komunikasi yang baik untuk menghadapi orang-orang yang mempunyai pandangan yang berbeda dalam hal prioritas pendapat, motivasi dan kepirbadian.

Questionnaires Teknik fact-finding yang lain adalah melakukan dengan menggunakan kuisioner. Kuisioner adalah dokumen dengan tujuan khusus untuk mengumpulkan fakta-fakta dari sejumlah orang. Manakala kita ingin mengumpulkan informasi dari orang banyak teknik yang paling efisien adalah kuisioner. Ada dua tipe dari jenis pertanyaan dari kuisioner yaitu

Research Salah teknik fact-finding yang berguna adalah melakukan riset terhadap aplikasi dan masalahnya. Majalah-majalah

omputer, buku-buku

petunjuk dan internet merupakan sumber-sumber informasi yang bagus.

23 Mereka dapat menyediakan informasi, tentang bagaimana orang lain memecahkan masalah yang serupa.

Observing The Enterprise In Operation Pengamatan merupakan salah satu teknik fact-finding yang paling efektif untuk memahami sebuah sistem. Teknik ini memungkinkan untuk berpartisipasi atau mengawasi seseorang dalam beraktivitas untuk mempelajari tentang sistem.

2.2.3.4 Database design Perancangan basis data dimulai ketika analisis terhadap kebutuhan perusahaan telah dilakukan. Di dalam perancangan basis data terdapat suatu metodologi yang membantu dalam membuat suatu basis data. Yang dimaksud dengan metodologi perancangan basis data adalah sebuah pendekatan struktur yang mencakup prosedur, teknik, alat bantu dan tujuan dokumentasi untuk mendukung dan memberi sarana dalam proses perancangan itu sendiri. Metodologi perancangan basis data terdiri dari tahap-tahap yang membantu para perancang dengan teknik yang tepat dalam setiap merancang basis data. Metodologi perancangan basis data juga membantu perancang untuk merencanakan, mengatur dan mengevaluasi pengembangan dari proyek pembuatan basis data (database) tersebut (Connolly, 2002, p419). Perancangan database terdiri dari 3 tahap : 1. Perancangan database tahap konseptual

24 2. Perncangan database tahap logical 3. Perancangan database tahap physical

2.2.3.5 DBMS Selection Pemilihan DBMS (Database Management System) dilakukan untuk memilih DBMS yang cocok atau sesuai dengan aplikasi basis data yang dibuat. Bagaimanapun pemilihan DBMS bisa dilakukan pada setiap waktu sebelum melakukan logical design

yang menyajikan

informasi cukup mengenai kebutuhan sistem seperti performance, security, integrity constraints. Walaupun pemilihan DBMS mungkin jarang, tetapi ketika kebutuhan perusahaan sedang diperluas atau sistem yang berjalan digantikan, mungkin menjadi perlu kadang-kadang untuk mengevaluasi produk DBMS yang baru . Suatu pendekatan sederhana dalam melakukan pemilihan DBMS

adalah dengan mencocokkan

DBMS dengan kebutuhan.

2.2.3.6 Application Design Perancangan user menghubungkan program aplikasi yang menggunakan dan memproses basis data tersebut (Connolly, 2002, p287). Mengamati desain aplikasi dan basis data itu adalah aktivitas parallel pada aplikasi basis data life cycle. Dalam banyak kasus, tidaklah mungkin untuk melengkapi atau menyudahi desain aplikasi itu sampai perancangan basis data terhadap dirinya sendiri yang telah berlangsung. Pada sisi lain, basis data ada untuk mendukung aplikasi

25 tersebut, dan demikian harus ada suatu informasi antar

desain

aplikasi dan desain basis data.Kita harus memastikan bahwa semua kemampuan menyatakan spesifikasi kebutuhan pemakai hadir di dalam desain aplikasi untuk aplikasi basis data. Ini melibatkan program aplikasi yang mengakses basis data akan merancang transaksi tersebut ke dalam metode akses basis data. Sebagai tambahan terhadap perancangan bagaimana kemampuan yang diperlukan (diharapkan) untuk dicapai, kita harus mendesain seorang pemakai yang sesuai untuk menghubungkan ke aplikasi basis data tersebut. Alat penghubung ini menyajikan informasi yang diperlukan sehingga mudah dioperasikan. Bagaimanapun, haruslah dikenali bahwa alat penghubung mungkin adalah salah satu dari komponen yang paling utama dari sistem itu. Pada sisi lain, jika alat penghubung tidak mempunyai satupun karakteristik, sistem akan menyebabkan permasalahan.

2.2.3.7 Prototyping Suatu prototype adalah suatu model aplikasi basis data yang mempunyai semua corak yang diperlukan dan menyediakan semua kemampuan sistem. Tujuan utama mengembangkan suatu aplikasi basis data prototype adalah mengizinkan para pemakai untuk menggunakan prototype itu untuk mengidentifikasi corak sistem yang bekerja dengan baik dan jika mungkin untuk meningkatkan corak baru kepada aplikasi basis data. Dengan cara ini, kita dapat

26 memperjelas kebutuhan pemakai dan pengembang sistem dan mengevaluasi kelayakan desain sistem tertentu.. Ada dua cara strategi membuat prototype yaitu menentukan kebutuhan prototype dan membuat prototype evolusiner(Connolly, 2002, p292). Untuk menentukan kebutuhan

prototype digunakan

suatu prototype untuk menentukan kebutuhan suatu aplikasi basis data yang diusulkan dan ketika kebutuhan terhadap suatu aplikasi basis data sudah lengkap maka prototype tersebut tidak digunakan lagi/dibuang. Prototype evolusiner digunakan untuk tujuan yang sama, perbedaan yang penting adalah bahwa prototype tidaklah dibuang tetapi dengan pengembangan lebih lanjut prototype tersebut bekerja sama dengan aplikasi basis data.

2.2.3.8 Implementation Implementasi merupakan perwujudan fisik dari basis data dan desain aplikasi (Connolly, 2002, p292). Pada tahap penyelesaian desain ( dimana dapat melibatkan pembuatan prototype atau tidak ), kini kita dapat menerapkan basis data dan program aplikasi yang telah kita buat. Implementasi basis data

dicapai dengan

menggunakan Data Definition Language(DDL) yang telah kita pilih dalam melakukan pemilihan DBMS atau dengan menggunakan Graphical User Interface (GUI), yang menyediakan fungsional yang sama dengan pernyataan (statement) DDL yang low-level. Pernyataan (statement) DDL digunakan untuk menciptakan struktur basis data

27 dan mengosongkan file yang terdapat dalam basis data tersebut. User view juga diterapkan pada langkah implementasi.Program aplikasi diterapkan dengan menggunakan bahasa generasi keempat atau ketiga yang lebih disukai ( 3GL atau 4GL). Bagian dari program aplikasi ini adalah transaksi basis data, yang diterapkan dengan menggunakan Data Manipulation Language (DML). Transaksi basis data juga dapat dibuat dalam bahasa pemrograman, seperti Visual Basic, C, C++, Java, COBOL, Fortran, Ada, atau Pascal. Kita juga menerapkan komponen lain dari desain aplikasi

seperti layar menu, format

masukan data, dan laporan. Pengendalian keamanan dan integritas untuk aplikasi juga telah diterapkan. Sebagian dari kendali ini telah diterapkan dengan menggunakan DDL , tetapi yang lain mungkin perlu untuk digambarkan di luar dari DDL sebagai contoh, kegunaan yang disediakan DBMS atau kendali sistem operasi.

2.2.3.9 Data Conversion And Loading Pemindahan data yang ada ke dalam basis data yang baru dan mengubah aplikasi yang sedang berjalan agar dapat digunakan dalam basis data yang baru (Connolly, 2002, p293). Langkah ini diperlukan hanya ketika suatu sistem basis data baru sedang menggantikan suatu sistem basis data yang lama. Sekarang ini, telah menjadi umum suatu DBMS untuk mempunyai suatu kegunaan yang dapat mengisi

file yang

ada ke dalam basis data yang baru.

Kegunaan yang pada umumnya memerlukan spesifikasi sumber file

28 dan target basis data dan kemudian secara otomatis mengkonversi data itu kepada format yang diperlukan basis data yang baru. Kapan saja konversi dan pemuatan diperlukan, proses harus dengan baik direncanakan agar basis data tersebut dapat sesuai dengan kebutuhan yang ada.

2.2.3.10 Testing Testing adalah suatu proses melaksanakan program aplikasi dengan tujuan menemukan kesalahan (Connolly, 2002, p293). Sebelum diterapkan dalam suatu sistem , basis data harus dilakukan pengujian (testing) terlebih dahulu. Hal ini dicapai dengan penggunaan yang secara hati-hati merencanakan strategi test dan data realistis sedemikian sehingga keseluruhan proses pengujian sesuai metodenya dan dengan kaku dilaksanakan.

2.2.3.11 Operational Maintenance Dalam langkah-langkah yang sebelumnya, aplikasi basis data telah secara penuh diterapkan dan di uji. Sistem sekarang pindah ke suatu langkah pemeliharaan sistem seperti melakukan backup data untuk mencegah kehilangan data.

2.2.4 Metodologi Perancangan Database Merupakan suatu pendekatan yang bersifat terstruktur yang mencakup prosedur, teknik, alat bantu dan tujuan dokumentasi untuk mendukung dan

29 memberi sarana dalam proses itu sendiri. Perancangan basis data dibagi atas tiga bagian, yaitu : 2.2.4.1 Conceptual database design / Perancangan database Konseptual Langkah awal dalam conceptual database design adalah dengan membuat model data secara konseptual dari perusahaan yang bersangkutan.

Langkah 1 Membuat model data konseptual untuk setiap View. Model data konseptual didukung oleh dokumentasi, meliputi kamus data yang dihasilkan selama pengembangan model. Langkah -langkah panduan dalam perancangan basis data konseptual sebagai berikut (Connolly, 2002, p422) : Langkah 1.1 Mengidentifikasi tipe entity. Mengidentifikasikan tipe entity utama yang diperlukan oleh view. Salah satu metode untuk mengidentifikasi entity adalah dengan menguji spesifikasi kebutuhan user.

Langkah 1.2 Mengidentifikasi tipe relasi. Setelah mengidentifikasikan entity, selanjutnya adalah mengidentifikasi semua relasi yang ada antar entity. Salah satu metode yang digunakan ketika mengidentifikasi entity, adalah

dengan

menggunakan

struktur

kalimat

pada

30 spesifikasi kebutuhan user. Biasanya relasi ditandai dengan kata kerja.

Langkah 1.3

Mengidentifikasi dan mengasosiasikan

atribut dengan entity atau relationship types. Dengan cara yang sama dalam mengidentifikasi entity, dilakukan pencarian kata benda

dalam spesifikasi

kebutuhan user. Atribut bisa diidentifikasi dimana kata benda tersebut memiliki nilai, kualitas, identifier, atau karakteristik dari satu entity atau hubungan. Dalam menentukan atribut harus mampu mengidentifikasi atribut sederhana atau komposit, single-valued atau multi-valued dan turunan. Setelah atribut diidentifikasi, diperlukan dokumentasi setiap atribut yang terdiri atas:

Langkah 1.4

Menentukan atribut domain

Tujuan dari langkah ini adalah menentukan domain dari semua atribut dalam model. Sebuah domain adalah satuan data yang dapat dipakai oleh satu atau lebih atribut.

Langkah 1.5 Menentukan atribut candidate key dan primary key

31 Langkah ini dilakukan untuk mengidentifikasi candidate key untuk sebuah entity dan kemudian memilih salah satu sebagai primary key (Connolly, 2002, p431). Ketika memilih primary key dari sejumlah candidate key dapat menggunakan pedoman - pedoman untuk membantu membuat pilihan : a. Candidate key dengan jumlah atribut yang minimal b. Candidate key yang perubahan nilainya sedikit c. Candidate key dengan karakter paling sedikit (untuk kunci candidate dengan atribut tekstual) d. Candidate key dengan nilai maksimum terkecil (untuk kunci candidate dengan atribut numerik); e. Candidate key yang paling mudah digunakan dari sudut pandang user.

Langkah 1.6

Mempertimbangkan

kegunaan

dari

konsep model lanjutan (optional step) Pada langkah ini, terdapat pilihan untuk melanjutkan pengembangan model ER menggunakan konsep pemodelan

32 lanjut yang dinamakan spesialisasi / generalisasi, aggregasi, dan komposisi.

Langkah 1.7

Memeriksa redundansi pada model

Pada tahap ini, dijelaskan model datal konseptual lokal dengan menspesifikasi objektivitas dari pengidentifikasian, bila terdapat redundansi yang ada dapat dibuang.

Langkah 1.8

Validasi

model

konseptual

lokal

terhadap transaksi user. Tujuan dari langkah ini adalah untuk mengecek model, agar meyakinkan bahwa model yang mendukung transaksi diperlukan oleh view

Langkah 1.9

Mengkaji ulang model data konseptual

lokal dengan user. Dilakukan pengkajian ulang model data konsep lokal dengan user untuk memastikan bahwa model data yang dihasilkan, merupakan representasi yang benar dari view.

2.2.4.2 Logical database design/ Perancangan database logikal Dalam logical database design, model data yang telah diperoleh dalam conceptual database design diubah dalam bentuk logical model, dimana data yang ada dipengaruhi oleh model data yang menjadi tujuan

33 basis data. Hal ini dilakukan untuk menerjemahkan representasi konseptual ke dalam bentuk struktur logic dalam basis data. Logical data model merupakan sumber informasi dalam merancang physical database. Logical database design memberikan sarana yang membantu para perancang dalam merancang physical database.

Langkah 2 Membangun dan validasi model data logikal lokal untuk setiap view Untuk membangun model data logikal lokal dari model data konseptual local, merepresentasikan view tertentu dari organisasi dan kemudian memvalidasi

model

ini

untuk

meyakinkan

strukturnya

benar

menggunakan teknik normalisasi serta untuk meyakinkan model akan mendukung transaksi yang diperlukan. Langkah 2.1 Menghilangkan fitur-fitur yang tidak sesuai dengan model relasional (optional step) Keobjektivitasan dari langkah ini adalah untuk : - Menghilangkan tipe relasi binary banyak-ke-banyak (*:*) Jika relasi banyak-ke-banyak (*:*) terdapat pada model data konseptual, dapat dilakukan dekomposisi relasi ini untuk mengidentifikasi entity lanjutan. Relasi (*:*) diganti dengan dua relasi satu-ke-banyak (1:*) untuk entity yang baru diidentifikasi tersebut.

34 - Menghilangkan tipe relasi rekursif banyak-kebanyak (*:*) Jika relasi rekursif (*:*) terdapat pada model data konseptual, dapat dilakukan dekomposisi relasi ini untuk mengidentifikasi entity lanjutan.

- Menghilangkan tipe relasi kompleks Relasi kompleks merupakan relasi antara tiga atau lebih tipe relasi. Jika relasi kompleks direpresentasikan dalam model data konseptual,

dapat dilakukan dekomposisi

relasi iuntuk mengidentifikasi entity lanjutan. Relasi kompleks diganti dengan sejumlah relasi satu-ke-banyak (1:*) untuk entity yang baru diidentifikasi tersebut.

- Menghilangkan atribut multi-valued Jika terdapat atribut multi-valued pada model data konseptual, dapat dilakukan dekomposisi atribut untuk mengidentifikasi sebuah entity.

Langkah 2.2 Menurunkan relasi untuk model data logikal lokal Pada langkah ini, dilakukan penurunan relasi untuk model data logikal lokal untuk merepresentasikan entity, relasi, dan atribut yang didefinisikan pada view.

35 - Tipe entity kuat Untuk setiap entity kuat dalam model data dibentuk relasi yang meliputi semua atribut tunggalnya.

- Tipe entity lemah Primary key dari entity lemah diturunkan secara parsial atau penuh dari setiap entity induk. Jadi identifikasi primary key dari entity lemah tidak dapat dilakukan sampai semua relasi dengan entity induk telah dipetakan.

- Tipe relasi binary satu-ke-banyak (1:*) Untuk setiap relasi binary (1:*), entity pada ‘sisi satu’ dari relasi dirancang sebagai entity induk dan entity pada ‘sisi banyak’

dirancang

sebagai

entity

anak.

Untuk

merepresentasikan relasi ini, dilakukan penyalinan atribut primary

key

dari

entity

induk

ke

relasi

yang

merepresentasikan relasi anak sebagai foreign key.

- Tipe relasi binary satu-ke-satu (1:1) Membuat relasi untuk merepresentasikan relasi 1:1 lebih kompleks karena cardinality tidak dapat digunakan untuk membantu mengidentifikasi entity induk dan anak dalam relasi. Berikut batasan partisipasi dan cara membentuk relasinya:

36 - Partisipasi mandatory pada kedua sisi relasi 1:1 Dilakukan penggabungan entity yang dilibatkan kedalam sebuah relasi dan memilih satu primary key dari entity asalnya untuk menjadi primary key relasi yang baru, sedangkan yang lainnya sebagai alternate key.

- Partisipasi mandatory pada satu sisi relasi 1:1 Dalam kasus ini, dapat dilakukan identifikasi entity

induk

dan

anak

untuk

relasi

1:1

menggunakan batasan partisipasi. Entity yang mempunyai partisipasi optional dalam relasi dirancang sebagai entity induk, dan entity yang mempunyai partisipasi mandatory dalam relasi dirancang sebagai entity anak. Sehingga salinan primary key dari entity induk diletakkan pada relasi yang merepresentasikan entity anak.

- Partisipasi opsional pada kedua sisi relasi 1:1 Dalam kasus ini, perancangan entity induk dan anak tak tentu kecuali kalau ditemukan informasi

37 yang lebih tentang relasi yang dapat membantu keputusan yang dibuat. - Tipe relasi superclass / subclass Untuk setiap relasi superclass/subclass pada model data konseptual, diidentifikasi entity superclass sebagai entity induk dan entity subclass sebagai entity anak (Connolly, 2002, p451). Ada beberapa macam pilihan bagaimana merepresentasikan relasi sebagai satu atau banyak relasi tergantung faktor batasan disjoint dan partisipasi.

Langkah 2.3 Validasi relasi menggunakan normalisasi Untuk memvalidasi relasi dalam model data logikal lokal digunakan teknik normalisasi. Proses normalisasi meliputi langkah-langkah utama yaitu : bentuk normal pertama (1NF), normal kedua (2NF), normal ketiga (3NF) dan bentuk normal Boyce-Codd (BCNF). Langkah 2.4 Validasi relasi terhadap transaksi user Tujuan langkah ini untuk menyakinkan bahwa model data logikal lokal mendukung transaksi yang diperlukan oleh view.

Langkah constraints

2.5

Mendefinisikan

referential

integrity

38 Batasan

integriti

merupakan

batasan

yang

digunakan untuk melindungi basis data dari keadaan tidak konsisten. Menurut Connolly (2002, p457) ada lima jenis batasan integriti yaitu : a. Required data, Beberapa atribut harus selalu berisi data yang sah sehingga atribut tersebut tidak diperbolehkan menerima null. b. Attribute domain constraints, Setiap atribut mempunyai domain yang merupakan sekumpulan nilai yang sah. c. Entity integrity, Primary key dari sebuah entity tidak dapat menerima null. d. Referential integrity, Jika foreign key berisi nilai, nilai tersebut harus menunjuk pada tuple yang ada pada relasi induk. Untuk menyakinkan referential integrity perlu dispesifikasikan

existence

constraints

yang

mendefinisikan kondisi dimana candidate key atau foreign key ditambahkan, diubah atau dihapus. Jika sebuah tuple dari relasi induk dihapus, referential integrity hilang jika ada tuple anak menunjuk ke tuple induk yang dihapus. Ada beberapa strategi yang dapat digunakan :

39 NO ACTION, Mencegah penghapusan dari relasi induk jika terdapat referensi ke tuple anak. CASCADE, Jika tuple induk dihapus maka secara otomatis tupel anak akan dihapus. SET NULL, Jika tuple induk dihapus, maka foreign key dari tuple anak akan menjadi null. SET DEFAULT, Jika tuple induk dihapus, maka foreign key pada semua tuple anak akan diberikan nilai default. NO CHECK, Jika tuple induk dihapus, maka tidak dilakukan apapun untuk menyakinkan bahwa referential integrity terjaga. e. Enterprise Constraints, Aturan-aturan tambahan yang ditetapkan oleh perusahaan.

Langkah 2.6 Mengkaji ulang model data logikal lokal dengan user Tujuan langkah ini untuk menyakinkan bahwa model data logikal lokal dan dokumentasi pendukung yang menggambarkan model merupakan representasi yang benar dari view.

40 Langkah 3 Membangun dan validasi model data logikal global Langkah ini bertujuan untuk menggabungkan model data logikal lokal individual

kedalam

satu

model

data

logikal

global

yang

merepresentasikan organisasi.

2.2.4.3. Physical database design/ Perancangan database fisikal Physical database design dilakukan untuk memutuskan struktur logik secara fisik diimplementasikan ke dalam tujuan (DBMS), para perancang juga harus membuat keputusan mengenai bagaimana basis data tersebut dapat diimplementasikan / diterapkan dalam perusahaan. Langkah 4 Menerjemahkan model data logikal kedalam target DBMS Langkah 4.1 Merancang relasi dasar Dengan menggunakan DBMS dapat dibentuk tabel secara nyata dengan mendeklarasikan juga primary key dan foreign key, sehingga terbentuk hubungan antar tabel seperti yang telah dirancang dalam model global data logical

Langkah 4.2 Merancang representasi dari data turunan Pada

tahap

ini,

dipastikan

bagaimana

memperoleh data dalam model global data logikal ke DBMS.

41

Langkah

4.3

Merancang

aturan-aturan

yang

dikehendaki perusahaan Pada tahap ini, dibuat aturan-aturan seperti yang diinginkan perusahaan dalam menampilkan, menambah, ataupun untuk mengupdate data dalam basis data.

Langkah 5 Merancang representasi physical Langkah 5.1 Analisis transaksi Pada tahap ini, dipelajari segala kegiatan transaksi yang terjadi dalam suatu perusahaan yang akan dijalankan pada basis data dan menganalisa transaksi-transaksi yang penting.

Langkah 5.2 Memilih organisasi file Tujuan utamanya adalah untuk memilih organisasi file yang optimal karena akan sangat mempengaruhi efisiensi dari basis data.

Langkah 5.3 Memilih indeks Pemilihan indeks sangat penting dalam meningkatkan kinerja dari sebuah system, terutama kecepatan akses terhadap basis data.

42 Langkah 5.4 Memperkirakan kapasitas disk yang dibutuhkan untuk menyimpan basis data. Dalam

penentuan

kapasitas

penyimpanan

perlu

memperhatikan pertumbuhan data dikemudian hari. Langkah ini bertujuan untuk memperkirakan jumlah kapasitas

disk

yang

diperlukan

untuk

mendukung

implementasi basis data. Tahap yang dapat digunakan untuk memperkirakan jumlah ruang yang dibutuhkan untuk menyimpan data dan banyak tambahan nonclustered indexes pada tabel yang memiliki clustered index. - Menghitung tempat penyimpanan yang digunakan untuk menyimpan data. - Menghitung tempat penyimpanan yang digunakan untuk menyimpan clustered index. -Menghitung tempat penyimpanan untuk menyimpan setiap tambahan nonclustered index. -Menjumlahkan nilai yang dihitung.

Langkah 6 Merancang tampilan user Rancangan

tampilan

sangat

berpengaruh

terhadap

efektifitas

penggunaan oleh user. Dengan rancangan layar yang baik maka user dapat dengan mudah menggunakan aplikasi tersebut.

43 Langkah 7 Merancang mekanisasi keamanan Perancangan keamanan sangat diperlukan karena dapat mencegah sistem dan data dari kerusakan. Keamanan untuk sistem dapat menggunakan password dan keamanan untuk data bisa menggunakan cara diberikan hak untuk akses

2.2.5 Metodologi Perancangan Software Dalam melakukan perancangan software, motodologi yang digunakan adalah metodologi perancangan sequential linier. Menurut Pressman (2001,pp28-29) metode sequential linier. terdiri dari 5 aktivitas yaitu : -

System / information engineering and modeling Merupakan

proses pengumpulan informasi pada berbagai elemen

sistem.

-

Software requirement analysis Merupakan proses analisa kebutuhan software.

-

Design Merupakan proses mengubah kebutuhan software menjadi representasi awal dari software yang dapat diuji kualitasnya sebelum masuk ke tahap coding

44 -

Code generation Merupakan proses mngubah rancangan menjadi suatu bentuk yang dapat dimengerti oleh mesin computer.

-

Testing Merupakan proses pengujian terhadap software yang telah dihasilkan pada tahap coding untuk menemukan adanya kesalahan serta memastikan bahwa software akan menghasilkan output yang tepat sesuai dengan input yang diberikan.

-

Support Merupakan proses penerapan ulang tahap-tahap pada metodologi perancangan sequential linier pada software yang telah dibuat ketika terjadi perubahan pada software setelah dikirimkan pada user karena adanya error dibandingkan harus membuat ulang software yang baru

45

System / Information engineering

Analysis

Design

Code

Test

Gambar 2.3 Diagram Metode Perancangan Software Sequential Linier

2.2.6 Normalisasi Istilah normalisasi berasal dari E.F Codd.Normalisasi memberikan panduan yang sangat membantu bagi pengembang untuk mencegah penciptaan struktur tabel yang kurang efisien. Struktur tabel yang kurang efisien tersebut biasanya disebabkan karena adanya anomali pada tabel tersebut Suatu desain database harus memenuhi kondisi untuk tidak mengandung anomali, yaitu suatu kejanggalan dari suatu penempatan atribut tertentu dari suatu obyek data. Menurut Martina(2003,p4) normalisasi adalah reduksi bertahap yang dilakukan pada sejumlah tabel. Menurut Willis (2000,p69) normalisasi adalah proses menggunakan metode-metode formal untuk mengeliminasi data-data berulang, dan untuk memisahkan data menjadi tabel-tabel yang saling berhubungan.

46 2.2.6.1 Anomali Anomali adalah proses pada basis data yang memberikan efek samping yang tidak diharapkan (misalnya menyebabkan ketidakkonsistenan data).Anomali terdiri dari 3 macam : -

Anomali Update

-

Anomali penyisipan

-

Anomali penghapusan

2.2.6.1.1 Anomali update Anomali ini terjadi ketika pengubahan pada sejumla data yang mubazir,tapi tidak semuanya diubah. Contoh :

Pemasok

Kota

Barang

Jumlah

Kartika

Jakarta

Keyboard

2

Citra

Medan

Mouse Dexia

5

Citra

Medan

Monitor

3

Tabel 2.2 Tabel contoh anomali update Jika pemasok citra berpindah ke kota lain, misalnya ke bandung,dan pengubahan hanya dilakukan pada data pertama maka hasilnya adalah seperti pada tabel dibawah ini : Pemasok Kartika

Kota Jakarta

Barang Keyboard

Jumlah 2

47 Pemasok

Kota

Barang

Jumlah

Citra

Bandung

Mouse Dexia

5

Citra

Medan

Monitor

3

Tabel 2.3 Tabel contoh anomali update 2 Terlihat

bahwa

ada

ketidakkonsistennan,data

pertama

menyatakan bahwa pemasok Citra berlokasi di Bandung,tapi fakta kedua menyatakan bahwa pemasok citra berada di Medan.

Mana

yang

benar

?

Keadaan

inilah

yang

menyebabkan adanya ketidak konsistenan. 2.2.6.1.2 Anomali penyisipan Anomali penyisipan terjadi pada saat penambahan hendak dilakukan ternyata ada data yang masih kosong,padahal data tersebut adalah primary key. Contoh :

Kuliah

Ruang

Tempat

Jaringan Komputer

202

Anggrek

Matematika Diskrit

K3C

Syahdan

Sistem pakar

A202

Kijang Tabel 2.4

Tabel contoh anomali penyisipan

48 Masalahnya bagaimana caranya menyisipkan fakta bahwa ruang baru bernama C804 berada di Kijang ? Penyisipan tidak dapat dilakukan mengingat tak ada informasi kuliah yang menggunakan ruang tersebut.

2.2.6.1.3 Anomali penghapusan Anomali yang terjadi ketika dilakukan penghapusan terhadap suatu data dan sebagai akibatnya data lain ikut terhapus juga,padahal data tersebut masih dibutuhkan

2.2.6.2 Dependensi Dependensi adalah konsep yang mendasari normalisasi. Dependensi menyatakan hubungan antar atribut dan secara khusus menjelaskan nilai suatu atribut yang menentukan nilai atribut lainnya Ada 4 macam dependensi : -

Dependensi fungsional

-

Dependensi fungsional sepenuhnya

-

Dependensi total

-

Dependensi transitif

2.2.6.2.1 Dependensi fungsional Suatu atribut Y mempunyai dependensi fungsional terhadap atrbut X jika dan hanya jika setiap nilai X berhubungan dengan tiap nilai Y.

49 Definisi diatas biasanya dituangkan dalm bentuk notasi sebagai berikut: X

Y

2.2.6.2.2 Dependensi fungsional sepenuhnya Suatu atribut Y mempunyai dependensi fungsional terhadap atrbut X jika : -

Y mempunyai dependensi fungsional terhadap X

-

Y tidak memiliki dependensi terhadap bagian dari X

2.2.6.2.3 Dependensi total Suatu atribut Y mempunyai dependensi fungsional terhadap atrbut X jika : -

Y mempunyai dependensi fungsional terhadap X

-

X memiliki dependensi fungsionalterhadap X

Definisi diatas biasanya dituangkan dalm bentuk notasi sebagai berikut : X

Y

2.2.6.2.4 Dependensi transitif Suatu atribut Z mempunyai dependensi fungsional terhadap atrbut X jika : -

Y mempunyai dependensi fungsional terhadap X

-

Z memiliki dependensi fungsionalterhadap Y

50 2.2.6.3 Bentuk Normal 2.2.6.3.1 Bentuk Normal Pertama (1st NF) Suatu data dikatakan un-normalized, jika didalamnya mengandung kelompok berulang (repeating group), sehingga untuk membentuk normalisasi pertama (1st NF) repeating group harus dihilangkan. Suatu relation dikatakan dalam bentuk normal pertama jika dan hanya jika setiap atribut bernilai tunggal bagi setiap record

2.2.6.3.2 Bentuk Normal Kedua (2nd NF) Dapat dihasilkan dengan melihat apakah ada atribut bukan primary key yang merupakan fungsi dari sebagian primary key (partial dependence). Dalam normalisasi kedua (2nd NF) setiap atribut yang tergantung parsial ini harus dipisahkan dengan mengikut sertakan determinannya. Suatu relasi dikatakan berada pada bentuk normal kedua jika dan hanya jika - Berada pada bentuk normal pertama - Semua atribut non key memiliki ketergantungan sepenuhnya pada primary key

2.2.6.3.3. Bentuk Normal Ketiga (3rd NF) Pengujian terhadap 3rd NF dilakukan dengan cara melihat apakah terdapat atribut bukan key tergantung fungsional terhadap atribut bukan key yang lain (disebut ketergantungan transitif atau transitive dependence). Dengan cara yang sama, maka setiap ketergantungan

51 transitif dipisahkan. Suatu relasi dikatakan berada pada bentuk normal kedua jika dan hanya jika - Sudah berada pada bentuk normal kedua - Setiap atribut non key tidak memiliki ketergantungan transitif pada primary key 3rd NF sudah cukup bagus dalam arti bahwa anomali yang dikandungnya sudah sedemikian minimum (hampir tidak ada).

2.2.7 Entity relationship diagram 2.2.7.1 Pengertian entity types & entity occurrences Menurut Kroenke (2002, p52) entity adalah sesuatu yang dapat diidentifikasikan di lingkungan kerja user, sesuatu yang ingin dilacak kembali oleh user Entity type adalah sekelompok objek dengan property yang sama, serta diidentifikasi oleh perusahaan sebagai objek yang tidak memiliki ketergantungan. Entity

occurrences

adalah

sebuah

object

yang

dapat

diidentifikasikan secara unik pada suatu entity types.

2.2.7.2 Relationship types & relationship occurences Relationship types adalah Sekelompok hubungan yang bermakna diantara entity type

52 Relationship occurrences adalah adalah sebuah asosasi / hubungan yang termasuk didalamnya satu occurrences dari setiap entity type yang ikut berpartisipasi

2.2.7.3 Degree of Relationship types adalah jumlah dari entity type yang berpartisipasi pada sebuah relationship type Contoh : Pegawai_Administrasi

1… 1

1… *

Mendaftarkan►

Perusahaan Klien

Gambar 2.3 Contoh relationship 2.2.7.4 Simbol-simbol ERD

Entity

Relationship

Complex Relatioship Gambar 2.4 Simbol ERD

53

2.2.8 Data Flow Diagram (DFD) Menurut Whitten et al(2004, p344) DFD adalah suatu tool yang menggambarkan aliran data yang melalui suatu sistem serta proses yang dilakukan sistem tersebut. DFD adalah tool yang digunakan untuk merepresentasikan suatu sistem yang otomatis atau manual dengan menggunakan gambar yang berbentuk jaringan grafik. Simbol-simbol yang digunakan pada DFD :

External entity atau terminal

Process

Data flow

Data store

Gambar 2.5 Simbol-simbol DFD

External entity :

54 - Entitas yang berada di luar sistem yang memberikan data ke sistem atau menerima data dari sistem - Tidak termasuk bagian dari sistem

Process - Menggambarkan apa yang dilakukan oleh sistem - Berfungsi mentransformasikan 1 atau beberapa data masukan menjadi 1 atau beberapa data keluaran - Setiap process memiliki 1 atau beberapa data masukan serta menghasilkan 1 atau beberapa data keluaran

Data flow - Menggambarkan aliran data dari 1 entity ke entity lainnya. - arah panah menggambarkan arah aliran data

Data store - Menurut Hawryskiewycz (1998, P142) datastore adalah tempat menyimpan data yang terdapat didalam sistem - Process dapat mengambil data dari data store atau memberikan data ke data store

2.2.9 State Transition Diagram (STD) STD adalah tool yang digunakan untuk memodelkan suatu sistem yang menggambarkan sifat ketergantungan terhadap waktu dari suatu sistem

55 Notasi yang digunakan pada STD adalah : State

Perubahan state

Gambar 2.6 Simbol STD

Untuk melengkapi STD diperlukan 2 hal lagi yaitu : - Condition adalah suatu kejadian pada lingkungan external yang dapat dideteksi oleh sistem

- Action adalah tindakan / perubahan state yang dilakukan oleh sistem sebagai akibat terjadinya condition.Action akan menghasilkan output,message display pada screen,atau melakukan kalkulasi

2.2.10 Perhitungan disk space Menurut Elmasri dan Navathe (2000,p131) rumus perhitungan disk space adalah sebagai berikut : Bfr = B / R Dimana :

b = r / Bfr

56 B = Block (antara 112 byte – 4096 byte) r = record number R = Record Length Bfr = Banyak record per block b = banyak block per tabel

2.3 Kerangka berpikir memecahkan masalah : Dalam skripsi ini ada 3 metode yang dijadikan sebagai dasar kerangka berpikir memecahkan masalah yaitu : -

Metode perancangan aplikasi database : Database application lifecycle

-

Metode perancangan software : Metode Sequential Linier

-

Metode pencarian fakta (fact findings)

Dengan menggunakan metode fact finding dapat dikumpulkan data-data mengenai masalah dari perusahaan, serta bagaimana cara untuk mengatasinya.Dengan menggunakan metodologi Database Application Lifecycle dapat dirancang suatu database yang memiliki kualitas baik sehingga dapat menjadi fondasi yang kuat bagi sistem informasi dalam perusahaan. Dengan menggunakan motode perancangan software sequential Linier dapat dirancang suatu program aplikasi yang memberikan kepuasan bagi penggunanya yaitu mudah digunakan, serta bebas dari error.Sehingga dapat disimpulkan bahwa dengan menerapkan 3 metode diatas dapat dibuat suatu database serta aplikasinya yang dapat memecahkan masalah didalam perusahaan yaitu meningkatkan efektivitas dan efisiensi dalam hal penyimpanan dan pengorganisasian data-data perusahaan

57 Dengan menggunakan 3 metode diatas dapat disusun sebuah kerangka berpikir yang terdiri dari beberapa langkah yang dilakukan untuk memecahkan masalah yang terjadi di PT. Vera Diana Fokus seperti pada gambar 2.1 berikut ini.

Melakukan analisa terhadap permasalah yang dihadapi perusahaan

Membuat suatu rencana perancangan untuk sistem yang akan digunakan untuk memecahkan masalah

Melakukan analisa dan pengumpulan terhadap kebutuhan dari sistem yang dirancang

Merancang basis data menggunakan Database Application Lifecycle

Merancang aplikasi / program untuk mempermudah proses insert,update,dan delete dengan metode Sequential Linier Membuat model dari aplikasi basis data yang akan dibuat agar dapat dievaluasi dan memberi gambaran bagi user

Jika terdapat error

Melakukan pengujian terhadap sistem yang telah dirancang untuk mendeteksi adanya error. Jika tidak ada error

Melakukan konversi terhadap data-data lama perusahaan dan meloadnya ke sistem yang baru

Melakukan pemeliharan dan pengawasan terhadap sistem yang baru

Gambar 2.7 Diagram kerangka berpikir memecahkan masalah