7
LANDASAN TEORI
2.1 Teori Umum
Didalam teori umum ini menjelaskan segala teori yang berhubungan dengan sistem basis data
2.1.1 Pengertian Sistem
Menurut Jogiyanto (1989, p2), sistem adalah kumpulan dari elemen-elemen yang berinteraksi untuk mencapai suatu tujuan tertentu.
2.1.2 Pengertian Data
Menurut Conolly (2002,p19), Data adalah komponen yang paling penting dalam DBMS, berasal dari sudut pandang end-user. Data bertindak sebagai jembatan yang menghubungkan antara mesin dengan pengguna.
Menurut O’Brien, 2003, p13, Data adalah fakta-fakta atau observasi yang mentah, biasanya mengenai kejadian / transaksi bisnis.
Menurut Whitten (2004, p23), Data adalah fakta mentah mengenai orang, tempat, kejadian, dan hal-hal penting dalam organisasi.
Jadi arti data adalah fakta-fakta mengenai segala sesuatu yang dapat diolah untuk menghasilkan informasi yang akan dipakai dalam melakukan transaksi-transaksi di perusahaan / organisasi.
Hirarki Data
Menurut Kadir (2000,p8), suatu data dapat diorganisasikan ke dalam suatu hirarki yang terdiri atas elemen data, record, dan file.
a. Elemen Data
Elemen data merupakan satuan data terkecil yang tidak dapat dipecah lagi menjadi unit lain yang bermakna. Istilah lain untuk elemen data adalah field, kolom, item, dan atribut.
b. Record
Record merupakan gabungan sekumpulan elemen data yang saling terkait satu sama lain. Record biasa disebut dengan istilah tuple atau baris dalam sistem basis data relasional.
c. File
File merupakan himpunan record-record yang bertipe sama. File dapat pula dikatakan sebagai kumpulan record yang berkaitan dengan suatu subjek. Dalam sistem basis data relasional, file mewakili komponen yang disebut tabel atau relasi.
2.1.3 Pengertian Informasi
Menurut Kadir (2000, p7), informasi adalah hasil analisis dan sintesis terhadap data. Dengan kata lain, informasi dapat dikatakan sebagai data yang telah diorganisir ke dalam bentuk yang sesuai dengan kebutuhan seseorang, baik di tingkat staf biasa, manajer, atau siapa saja yang berada dalam suatu organisasi atau perusahaan.
2.1.4 Pengertian Basis Data
Menurut Connolly & Begg (2002, p14), basis data merupakan suatu kumpulan data yang secara logika saling berhubungan dan deskripsi dari data tersebut dirancang untuk memenuhi informasi yang dibutuhkan oleh suatu organisasi.
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 yang saling berelasi, relasi tersebut biasa ditunjukkan dengan kunci dari tiap file yang ada. Basis data menunjukkan suatu kumpulan data yang dipakai dalam 1 lingkup perusahaan.
Menurut Kusumo (2003,p2) basis data adalah kumpulan informasi yang ditulis dalam 1 atau lebih tabel.
Basis Data merupakan suatu kumpulan data yang berhubungan secara logis, dan deskripsi dari data tersebut, dirancang untuk memenuhi informasi yang dibutuhkan 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). Pendekatan dengan sistem database, dimana definisi dari data adalah dipisahkan dari program aplikasi.
2.1.5 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.
Sistem basis data memiliki 4 komponen utama, yaitu: data, hardware (perangkat keras), software (perangkat lunak), dan user. Hardware pada sistem basis data terdiri dari secondary storage devices (perangkat penyimpanan sekunder), I/O devices (perangkat input-output), device controllers (pengontrol peralatan), I/O channel (saluran input-output), database machines (mesin basis data). Software secara umum berfungsi membantu pengguna basis data untuk melakukan operasi terhadap data.
2.1.6 Model data relational
Model data relational dibangun berdasarkan konsep matematika dari relation yang direpresentasikan secara fisik sebagai tabel.
2.1.6.1 Struktur data relational
a. Relation adalah tabel yang memiliki baris dan kolom.
b. Attribute adalah kolom dari suatu relation yang memiliki nama.
c. Domain adalah kumpulan dari nilai-nilai yang diperbolehkan bagi suatu attribute pada relation.
d. Tuple adalah suatu baris yang ada pada relation.
e. Degree dari suatu relation adalah banyaknya attribute yang ada pada relation tersebut.
f. Cardinality adalah banyaknya tuple yang ada pada suatu relation. g. Relational database adalah kumpulan relation yang telah
dinormalisasi serta memiliki nama yang berbeda-beda.
2.1.6.2 Kunci Relational
a. Simple key adalah atribut yang tidak dapat dipecah lagi menjadi attribute yang lebih sederhana.
b. Composite key adalah attribute yang bisa terdiri dari beberapa attribute.
c. Super key adalah sebuah attribute atau kumpulan attribute 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.1.6.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.
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.1.7 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 entry data.
Pada umumnya DBMS menyediakan fasilitas-fasilitas berikut :
1. Fasilitas 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)
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 me-restore database ke keadaan konsisten sebelumnya, setelah terjadinya kesalahan atau error. e. User Accessible Catalog : menyimpan deskripsi dari data yang ada di
2.1.8 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 berikut :
Gambar 2.1 Diagram Database Application Lifecycle Sumber : Database System, Connolly, Figure 9.1 Page 272
Berdasarkan (Connolly, 2002, p272). Database Application Lifecycle terdiri dari langkah-langkah berikut :
2.1.8.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.1.8.2 System Definition
Menurut Connolly (2002, p274), system definition adalah menentukan ruang lingkup dari aplikasi basis data (database) yang akan dibuat termasuk user dan tempat dimana aplikasi basis data tersebut diterapkan. Sebelum mencoba untuk merancang suatu aplikasi
basis data, adalah penting bahwa kita pertama mengidentifikasi batasan-batasan sistem yang ada dan bagaimana sistem tersebut dapat menghubungkan dengan bagian lain yang terdapat dalam sistem informasi organisasi / perusahaan.
2.1.8.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 dengan teknik fact finding (Connolly, 2002, p276):
Examining documentation
Dokumentasi membantu menyediakan informasi pada bagian dari perusahaan berkaitan dengan masalah yang dihadapi.
Interviewing
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.
Questionnaires
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.
Research
Salah satu teknik fact-finding yang berguna adalah melakukan riset terhadap aplikasi dan masalahnya. Majalah-majalah, komputer, buku-buku petunjuk dan internet merupakan sumber-sumber informasi yang bagus. 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.1.8.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 2. Perancangan database tahap logical 3. Perancangan database tahap physical
2.1.8.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.1.8.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. 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.
2.1.8.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 memperjelas kebutuhan pemakai dan pengembang sistem dan mengevaluasi kelayakan desain sistem tertentu.
2.1.8.8 Implementation
Menurut Connolly (2002, p292), implementasi merupakan perwujudan fisik dari basis data dan desain aplikasi. Implementasi basis data dicapai dengan menggunakan Data Definition Language (DDL) atau dengan menggunakan Graphical User Interface (GUI), yang menyediakan fungsional yang sama dengan pernyataan (statement) DDL yang low-level. 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.
2.1.8.9 Data Conversion And Loading
Menurut Connolly (2002, p293), pemindahan data yang ada ke dalam basis data yang baru dan mengubah aplikasi yang sedang berjalan agar dapat digunakan dalam basis data yang baru. Kegunaan yang pada umumnya memerlukan spesifikasi sumber file dan target basis data dan kemudian secara otomatis mengkonversi data itu kepada format yang diperlukan basis data yang baru.
2.1.8.10 Testing
Menurut Connolly (2002, p293), testing adalah suatu proses melaksanakan program aplikasi dengan tujuan menemukan kesalahan. Sebelum diterapkan dalam suatu sistem , basis data harus dilakukan pengujian (testing) terlebih dahulu.
2.1.8.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.1.9 Metodologi Perancangan Database
Merupakan suatu pendekatan yang bersifat terstruktur yang mencakup prosedur, teknik, alat bantu dan tujuan dokumentasi untuk mendukung dan memberi sarana dalam proses itu sendiri. Perancangan basis data dibagi atas tiga bagian, yaitu :
2.1.9.1 Conceptual database design
Langkah awal dalam conceptual database design adalah dengan membuat model data secara konseptual dari perusahaan yang bersangkutan.
Langkah-langkah di atas melibatkan komponen-komponen sebagaimana diperlihatkan pada gambar berikut ini:
Gambar 2.2 Komponen-komponen pada perancangan basis data konseptual
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 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 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 lanjut yang dinamakan spesialisasi / generalisasi, aggregasi, dan komposisi.
Generalisasi / spesialisasi
Konsep dari generalisasi dan spesialisasi dihubungkan dengan tipe-tipe Entity khusus, yaitu superclass dan subclass, dan proses
pewarisan atribut turunan (Connolly,2002,p360). Dimana superclass merupakan induk dari beberapa kelompok-kelompok berbeda keberadaannya pada suatu tipe Entity sedangkan subclass merupakan kelompok bagian yang distinct dari suatu tipe Entity.
Spesialisasi merupakan proses memaksimalkan perbedaan-perbedaan yang ada diantara anggota dari sebuah Entity dengan mengidentifikasi perbedaan-perbedaan karakteristik yang ada. Spesialisasi merupakan pendekatan top-down untuk mendefinisikan sebuah kumpulan dari superclass dan hubungannya dengan subclass-subclassnya, dimana kumpulan subclass dibasiskan pada beberapa perbedaan karakteristik. Sebagai contoh setiap pekerjaan biasanya mempunyai jabatan atau job roles tertentu seperti manajer, sekretaris, maupun sales. Jadi dapat dianggap manajer, sekretaris dan sales merupakan spesialisasi dari pegawai.
Generalisasi merupakan proses memimalisasi perbedaan-perbedaan antar Entity yang ada dengan mengidentifikasi persamaan-persamaan karakteristiknya. Generalisasi merupakan pendekatan bottom-up. Terdapat dua constraints yang mungkin digunakan dalam generalisasi / spesialisasi yaitu (Connolly,2002,p366) :
Participation constraint, constraint ini menentukan apakah setiap anggota dari superclass harus berpartisipasi sebagai anggota dari sebuah subclass. Terdapat dua kemungkinan yaitu:
- Mandatory, dimana setiap anggota superclass harus menjadi anggota dari subclass.
- Optional, dimana tidak setiap anggota superclass harus menjadi anggota subclass.
Disjoint Constraint, constraint yang menjelaskan hubungan antar anggota dari subclass dan mengindikasikan apakah memungkinkan untuk seorang anggota dari superclass menjadi anggota dari satu atau lebih dari satu subclass. Terdapat dua kemungkinan yaitu:
- Or, dimana setiap anggota superclass hanya boleh menjadi salah satu anggota subclass.
- And, dimana setiap anggota superclass boleh menjadi anggota lebih dari satu subclass.
Agregasi
Agregasi merupakan representasi dari sebuah relasi mempunyai sebuah (‘has-a relationship’) atau merupakan bagian dari (‘is-part-of relationship’) diantara tipe-tipe Entity, dimana salah satu direpresentasikan sebagai keseluruhan (‘Whole’) dan yang lainnya menjadi bagian (‘Part’). Dalam agegrasi ‘whole’ merupakan representasi dari Entity yang lebih besar yang mengandung Entity yang lebih kecil ‘Part’.
Komposisi
Komposisi merupakan bentuk spesifik dari agegrasi yang merepresentasikan sebuah hubungan antar Entity, dimana terdapat kepemilikan yang kuat selamanya diantara ‘whole’ dan ‘part’. Pada compotition, ‘whole’ bertanggung jawab atas penempatan dari ‘part’, yang berarti bahwa compotiton harus mengatur penciptaan dan penghilangan dari ‘part’nya. Dengan kata lain, sebuah objek hanya boleh menjadi bagian dari sebuah compotition pada suatu waktu.
Langkah 1.7 Memeriksa redundansi pada model
Pada tahap ini, dijelaskan model data konseptual lokal dengan menspesifikasi objektivitas dari pengidentifikasian, bila terdapat redundansi yaitu duplikasi data atau data yang berulang 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.1.9.2 Logical database design
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 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 lokal, 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 many – to – many (*:*) Binary Relationship Types
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.
- Menghilangkan tipe relasi many – to – many (*:*) rekursif 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 untuk 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.
- Tipe Strong Entity
Untuk setiap Entity strong dalam model data dibentuk relasi yang meliputi semua atribut tunggalnya.
- Tipe Weak Entity
Primary key dari Entity weak diturunkan secara parsial atau penuh dari setiap Entity induk. Jadi identifikasi primary key dari Entity weak tidak dapat dilakukan sampai semua relasi dengan Entity induk telah dipetakan.
- Tipe relasi binary One – to - Many (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 one - to - one (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:
- 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 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 2.5 Mendefinisikan referential integrity constraints
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 :
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.
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.
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.1.9.3 Physical database design
Physical database design dilakukan untuk memutuskan struktur logis secara fisik di implementasikan 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 logikal
Langkah 4.2 Merancang representasi dari data turunan
Pada tahap ini, dipastikan bagaimana memperoleh data dalam model global data logikal ke DBMS.
Langkah 4.3 Merancang aturan-aturan yang dikehendaki perusahaan
Pada tahap ini, dibuat aturan-aturan seperti yang diinginkan perusahaan dalam menampilkan, menambah, ataupun untuk meng-update 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 sistem, terutama kecepatan akses terhadap basis data.
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.
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
Langkah 8 Denormalization
Pada langkah pysical database design ini mempertimbangkan denormalisasi skema relasional untuk meningkatkan performa. Hasil dari normalisasi adalah merancang basis data logikal secara struktural konsisten dan menekan jumlah redudansi. Faktor yang perlu di pertimbangkan adalah:
• Denormalisasi membuat implementasi lebih kompleks • Denormalisasi selalu mengorbankan fleksibilitas
• Denormalisasi akan membuat cepat dalam retrieve data tetapi lambat dalam proses update data.
Ukuran performa dari suatu perancangan basis data dapat dilihat dari sudut pandang tertentu yaitu melalui pendekatan efisiensi data (Normalisasi) atau pendekatan efisiensi proses (Denormalisasi). Efisiensi data dimaksudkan untuk meminimalkan kapasitas disk, dan efisiensi proses dimaksud untuk mempercepat proses saat retrieve data dari basis data.
2.1.10 Normalisasi
2.1.10.1 Pengertian Normalisasi
Normalisasi memberikan panduan yang sangat membantu bagi pengembang untuk mengembangkan struktur tabel yang kurang efisien menjadi efisien dan kompatibel bagi program DBMS. 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 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.
2.1.10.2 Anomali
Anomali adalah proses pada basis data yang memberikan efek samping yang tidak diharapkan (misalnya menyebabkan ketidak konsistenan data). Anomali terdiri dari 3 macam :
- Anomali Update
Anomali ini terjadi ketika pengubahan pada sejumlah data yang mubazir, tapi tidak semuanya diubah.
- Anomali Insert
Anomali insert terjadi pada saat penambahan hendak dilakukan ternyata ada data yang masih kosong, padahal data tersebut adalah primary key.
- Anomali Delete
Anomali yang terjadi ketika dilakukan delete terhadap suatu data dan sebagai akibatnya data lain ikut terhapus juga, padahal data tersebut masih dibutuhkan.
2.1.10.3 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
1. Dependensi Fungsional
Suatu atribut Y mempunyai dependensi fungsional terhadap atribut X jika dan hanya jika setiap nilai X berhubungan dengan tiap nilai Y.
Definisi diatas biasanya dituangkan dalam bentuk notasi sebagai berikut:
2. Dependensi fungsional sepenuhnya
Suatu atribut Y mempunyai dependensi fungsional terhadap atribut X jika :
- Y mempunyai dependensi fungsional terhadap X - Y tidak memiliki dependensi terhadap bagian dari X
3. Dependensi total
Suatu atribut Y mempunyai dependensi fungsional terhadap atribut X jika :
- Y mempunyai dependensi fungsional terhadap X - X memiliki dependensi fungsional terhadap X
Definisi diatas biasanya dituangkan dalm bentuk notasi sebagai berikut:
X Y
4. Dependensi transitif
Suatu atribut Z mempunyai dependensi fungsional terhadap atribut X jika :
- Y mempunyai dependensi fungsional terhadap X - Z memiliki dependensi fungsional terhadap Y
2.1.10.4 Bentuk Normal
1. Bentuk Normal Pertama (1st NF)
Suatu bentuk dimana sudah tidak ada kelompok repeating group dan sudah memiliki primary key. 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. Bentuk Normal Kedua (2nd NF)
Semua atribut yang ada bergantung penuh terhadap primary key. 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 mengikutsertakan 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
3. Bentuk Normal Ketiga (3rd NF)
Tidak ada atribut lain selain primary key bergantung transitif terhadap primary key. Pengujian terhadap 3rd NF dilakukan dengan cara melihat apakah terdapat atribut non key yang tergantung fungsional terhadap atribut non key yang lain (disebut ketergantungan transitif atau transitive dependence). Dengan cara yang sama, maka setiap ketergantungan transitif dipisahkan. Suatu relasi dikatakan berada pada bentuk normal ketiga 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).
4. Bentuk Normal Boyce-Codd (Boyce-Codd Normal BCNF)
Aturan Bentuk normal Boyce-Codd (BCNF) menurut Connoly dan Begg (2002,p398). “A relation is in BCNF, if and only if, every determinant is a candidate key”. Yang dapat diartikan, “Sebuah relasi disebut BCNF jika dan hanya jika setiap determinannya adalah sebuah candidate key”
Untuk menguji apakah suatu relasi sudah dalam BCNF, dilakukan identifikasi semua determinan dan memastikan bahwa determinan tersebut adalah candidate key.
Determinan adalah sebuah atribut. atau kumpulan atribut. dimana beberapa atribut yang lain masih bergantung secara fungsional penuh (full functionally dependent). Perbedaan antara 3Nfdan BCNF dalam hal ,functional dependency A B .3NFmengijinkan ketergantungan ini dalam sebuah relasi jika B adalah atribut primary key dan A bukan candidate key. Sedangkan dalam BCNF ketergantungan ini tetap ada di dalam sebuah relasi. dimana A harus sebuah candidate key.
5. Bentuk Normal Keempat (Fourth Nortnal Forni / 4NF)
Aturan bentuk nonnal ke-empat ( 4NF ) menurut Connoly dan Begg (2002,pp407-408), "A relation that is in Boyce-Codd normal form and contains no nontrivial multi valued dependencies" Yang dapat diartikan, "Sebuah relasi dalam Boyce Codd normal form (BCNF) dan tidak mengandung ketergantungan multivalued nontrivial (nontrivial multi valued dependencies ).
Bentuk normal ke-empat ( 4NF ) merupakan bentuk yang lebih kuat dari BCNF dimana 4NF mencegah relasi dari nontrivial multi-valued dependency dan data redundancy. Normalisasi dari BCNF ke 4NF meliputi pemindahan multi-valued dependency dari relasi dengan menempatkan atribut dalam sebuah relasi baru bersama dengan determinan. Multi-valued dependency (4NF)
menggambarkan ketergantungan antara atribut-atribut dalani suatu relasi.
6. Bentuk Normal Kelima (Fifth Normal Form / 5NF)
Aturan bentuk normal ( 5NF ) menurut Connoly dan Begg (2002,p410), "A relation that has. No join dependency". Yang dapat diartikan, "Sebuali relasi yang tidak mempunyai ketergantungan gabungan (join dependency). Join dependency menggambarkan sebuall tipe ketergantungan. Sebagai contoh. untuk sebuall relasi R dengan subset-subset atribut dari R yang dimisalkan dengan A.B....,Z sebuah relasi R menunjukkan join dependency, jika dan hanya jika, setiap nilai dari R sama dengan gabungan dari proyeksi proyeksinya pada A,B, ... ,Z
2.1.11 Entity relationship diagram
Entity relationship bisa diartikan sebagai entity yang saling berhubungan, pengertian lengkapnya sebagai berikut:
2.1.11.1 Pengertian Entity types & Entity occurrences
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 objek yang dapat diidentifikasikan secara unik pada suatu entity types.
2.1.11.2 Relationship types & relationship occurences
Relationship types adalah Sekelompok hubungan yang bermakna diantara entity type.
Relationship occurrences adalah adalah sebuah asosasi/ hubungan yang termasuk didalamnya satu occurrences dari setiap entity type yang ikut berpartisipasi.
Degree of Relationship types
Degree of Relationship types adalah jumlah dari entity type yang berpartisipasi pada sebuah relationship type.
Contoh relationship bisa dilihat pada Gambar 2.4 dibawah :
2.2 Teori Khusus
Teori khusus berisikan tentang teori yang sesuai dengan topik skripsi.
2.2.1 Persediaan
Fungsi dan Manfaat Persediaan :
Mengatasi risiko keterlambatan pengiriman Mengatasi risiko kesalahan pengiriman Mengatasi risiko kenaikan harga Mengatasi ketergantungan pada musim Mendapatkan keuntungan dari pembelian Untuk melayani konsumen dengan lebih baik Kelangsungan operasional perusahaan
Pengelompokkan Persediaan : Fluctuation Stock
Anticipation Stock Lot-Size Inventory
A. Metode Lot for Lot (LFL)
B. Metode Part Period Balancing (PPB) C. Metode Periode Order Quantity (POQ) Pipeline Inventory
Persediaan ABC
Secara umum dapat dikatakan bahwa pengelompokkan persediaan ABC didasar pada pemahaman bahwa, dalam perusahaan ada item persediaan
yang meskipun jumlahnya tidak panyak, namun nilainya tinggi (A), dan sebaliknya ada item persediaan yang jumlahnya sangat banyak namun tidak besar (C), dan diantara itu dikelompokkan dalam kelompok B
Pengendalian Persediaan : Metode Lot Sizing
Waktu Tenggang (Lead Time)
Perbedaan / selisih waktu antara saat pesan dengan kedatangan barang yang dipesan. Waktu tunggu ini biasanya dipengaruhi oleh :
1. Ketersediaan Barang di supplier. 2. Jarak pengiriman.
3. Transportasi, jenis dan kondisi yang ada.
Persediaan Pengamanan / Safety Stock / Buffer Stock / Iron Stock Persediaan cadangan selama Lead Time / Waktu Tenggang
Titik Pemesanan Kebali (Re-Order Point) / ROP
Saat dimana pemesanan harus dilakukan kembali sedemikian rupa sehingga kedatangan barang tepat waktu
Penentuan Nilai Safety Stock (Persediaan Minimum) Model Expected Value
Inti dari model ini adalah dengan mencari expected value dari biaya kekurangan persediaan dan biaya simpan (biasanya kedua biaya ini sudah diketahui sebelumnya) terendah dari berbagai tingkat safety stock.
Expected Value biaya kekurangan persediaan
Inti dari model ini adalah dengan melihat biaya kekurangan persediaan, nilai safety stock, dan biaya simpan untuk safety stock.
Perhitungan biaya kekurangan dan biaya simpan
Inti dari model ini adalah perusahaan menetapkan jumlah safety stock Penentuan Nilai Safety Stock (Persediaan Minimum) dengan Nilai
distribusi Normal
Inti dari model ini adalah dengan mensyaratkan biaya kekurangan dan simpan
2.2.2 Pembelian
Pembelian adalah suatu kegiatan yang dilakukan oleh perusahaan untuk pengadaan barang atau jasa yang diperlukan oleh perusahaan (Mulyadi, 2001, p299). Pengawasan perlu dilakukan terhadap pelaksanaan proses pembelian ini, karena pembelian menyangkut investasi dana dalam persediaan dan kelancaran arus barang ke dalam perusahaan.
Tujuan dari kegiatan pembelian :
1. Membantu identifikasi produk dan jasa yang dapat diperoleh secara eksternal.
2. Mengembangkan, mengevaluasi dan menentukan pemasok, harga dan pengiriman yang terbaik bagi barang atau jasa tersebut.
2.2.3 Penjualan
Penjualan adalah suatu kegiatan yang terdiri dari transaksi penjualan barang atau jasa, baik secara kredit atau tunai (Mulyadi, 2001, p204)
2.2.4 Diagram Alir Data (DAD)
DAD adalah suatu tool yang menggambarkan aliran data yang melalui suatus sistem serta proses yang dilakukan sistem tersebut.
DAD adalah tool yang digunakan untuk merepresentasikan suatu sistem yang otomatis atau manual dengan menggunakan gambar yang berbentuk jaringan grafik.
Simbol-simbol yang digunakan pada DAD dapat dilihat pada Gambar 2.4 dibawah:
SIMBOL NAMA PENJELASAN
Dokumen
Menggambarkan semua jenis dokumen, yang merupakan formulir yang digunakan untuk merekam data terjadinya suatu transaksi.
Dokumen dan tebusannya
Menggambarkan dokumen asli dan tebusannya. Nomor lembar dokumen dicantumkan disudut kanan atas.
Berbagai dokumen.
Menggambarkan berbagai jenis dokumen yang digabungkan bersama didalam suatu paket. Nama dokumen dituliskan didalam masing-masing simbol dan nomor lembar dokumen dicatumkan
disudut kanan atas simbol dokumen yang bersangkutan
Catatan
Menggambarkan catatan akutansi yang digunakan untuk mencatat data yang direkam sebelumnnya didalam dokumen atau formulir. Nama catatan akutansi dicantumkan didalam simbol ini
Penghubung pada halaman yang sama (on-page connector)
Digunakan untuk menghubungkan aliran dokumen yang terhenti di suatu lokasi pada halaman tertentu dan kembali berjalan dilokasi lain pada halaman yang sama dengan memperhatikan nomor yang tercantum pada simbol.
Penghubung pada halaman yang berbeda
(off-page connection)
Jika untuk menggambarkan bagan alir diperlukan lebih dari satu halaman, simbol ini harus digunakan untuk menunjukan kemana bagan alir terkait.
Kegiatan manual
Simbol ini digunakan untuk menggambarkan kegiatan manual, uraian singkat kegiatan manual dicantumkan didalam simbol ini. Keterangan Komentar
Simbol ini memungkinkan alih syistem menambahkan keterangan untuk memperjelas pesan yang disampaikan dalam bagan air.
Arsip sementara
Menunjukkan tempat penyimpanan dokumen yang dokumennya akan diambil kembali dari arsip tersebut dimasa yang akan datang.
Arsip permanen
Menggambarkan arsip permanent yang merupakan tempat penyimpanan dokumen yang tidak akan diproses lagi dalam sistem yang bersangkutan.
Keputusan
Simbol ini menggambarkan keputusan yang harus di buat dalam proses pengolahan data.
Mulai atau berakhir
(Terminal)
Simbol ini menggambarkan awal dan akhir dari suatu sistem.
External Entity :
- Entity 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 proses 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) data store adalah tempat menyimpan data yang terdapat didalam system.
- Process dapat mengambil data dari data store atau memberikan data ke data store.
2.2.5 State Transition Diagram (STD)
STD adalah tool yang digunakan untuk memodelkan suatu sistem yang menggambarkan sifat ketergantungan terhadap waktu dari suatu system.
Notasi yang digunakan pada STD bisa dilihat pada Gambar 2.5 dibawah :
Gambar 2.5 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
Perubahan state State
2.2.6 Perhitungan disk space
Menurut Elmasri dan Navathe (2000,p131) rumus perhitungan disk space adalah sebagai berikut :
Bfr = B / R b = r / Bfr Dimana :
B = Block (antara 512 byte – 64 kilobyte) r = record number
R = Record Length
Bfr = Banyak record per block b = banyak block per table
