Perancangan Sistem

1. Pemodelan Sistem

1.1 Model Sistem

salah satu cara untuk menstrukturkan permasalahan-permasalahan adalah dengan menggambarkanya dalam bentuk model-model

model dapat dibuat untuk sistem yang sedang berjalan atau sistem baru yang diusulkan sebagai sebuah cara untuk menunjukkan kebutuhan-kebutuhan dokumen bisnis atau perancangan-perancangan teknik.

model dapat dibedakan menjadi 2, yaitu :

• Model Logikal

• Model Fisikal

Contoh Diagram Aliran Data Logika

Contoh Diagram Aliran Data Fisik

system analyst menggunakan model logikal untuk menunjukkan kebutuhan bisnis(business requirments), sedangkan model fisikal digunakan untuk menunjukkan perancangan teknik(technicall design)

Aktivitas-aktivitas dalam analisis sistem (systems analysis) lebih difokuskan pada model logikal karena alasan berikut :

• model logikal dapat menghilangkan "bias" di antara personil tentang hasil yang diberikan oleh sistem yang berjalan atau sistem yang akan diimplementasikan

• model logikal dapat mengurangi resiko kesalahan kebutuhan bisnis (business requirment) karena umumnya kita awan terhadap hal-hal yang bersifat terlalu teknis

• model logikal mengijinkan untuk mengkomunikasikan model logikal kepada para pemakai kahir(end-user) dalam bahasa non-teknik

1.2 Model Proses

Model proses merupakan sebuah teknik untuk mengorganisasikan dan mendokumentasikan struktur dan aliran data melewati sebuah "proses" dalam sistem atau logika, kebijkan, dan prosedur-prosedur yang akan diimplementasikan dengan "proses" dalam sistem

Model sistem yang paling sederhana terdiri atas :

• Input

• Output

• Sistem itu sendiri yang ditunjukan sebagai sebuah proses.

DFD
DFD (Data Flow Diagram) adalah model perancangan database yang menggambarkan sistem sebagai jaringan kerja antar fungsi yang berhubungan satu sama lain dengan aliran serta penyimpanan data dan aliran data. Data flow diagram terdiri dari komponen konteks diagram dan diagram level ke-n.

Diagram konteks adalah kasus khusus (bagian dari DFD yang berfungsi memetakan model lingkungan) yang dipresentasikan dengan lingkaran tunggal yang mewakili keseluruhan siklus. Jadi konteks diagram adalah gambaran umum yang mencakup sistem kerja dengan lingkungan sistem kerja (user).

DFD level ke-n adalah penurunan proses DFD ke level yang lebih rendah. Penurunan mengacu pada aturan-aturan sebagai berikut :

• Setiap penurunan ke level yang lebih rendah harus mampu mempresentasikan proses tersebut dalam spesifikasi proses yang jelas. jika belum jelas harus diturunkan kelevel yang lebih rendah

• penurunan dilakukan jika diperlukan

• tidak semua bagian sistem harus diturunkan dengan jumlah level yang sama, karena yang kompleks bisa diturunkan dan yang sederhana mungkin tidak perlu diturunkan. Tidak semua proses dalam level yang sama mempunyai derajat kompleksitas yang sama

• mengkomfirmasikan DFD yang telah dibuat dengan cara top down.

• Aliran data yang masuk dan keluar pada suatu proses dalam level-X harus berhubungan dengan aliran data yang masuk dan keluar pada level-X+1. Level-X+1 mendefenisikan sub proses pada level-X

• Penyimpanan yang muncul pada level-X harus mendefenisikan kembali pada level-X+1, sedangkan penyimpanan yang muncul pada level-X tidak harus muncul pada level-X+1, karena penyimpanan tersebut bersifat lokal.

• Ketika mulai menurunkan DFD level tertinggi, harus dicoba untuk menidentifikasin eksternal events dimana sistem harus memberikan respon. Eksternal event dalam hal ini berarti suatu kejadian yang berkaitan dengan pengolahan data diluar sistem dan menyebabkan sistem membentuk respon (Husni Iskandar Pohan dan Kusnassriyanto dalam Wahyu Kurniawan).

Komponen-komponen yang digunakan untuk membuat DFD(Data Flow Diagram) adalah:

1. Proses

Menunjukkan transformasi dari masukan menjadi keluaran. Sejumlah masukan dapat menjadi hanya satu keluaran ataupun sebaliknya. proses adalah kegiatan atau kerja yang dilakukan orang, mesin atau komputer. Suatu proses disimbolkan dengan lingkaran atau output persegi panjang tegak dengan sudut-sudutnya tumpul. Didalam simbol proses terdapat penjelasan meliputi :

• Identifikasi proses

berupa suatu angka yang menunjukan nomor acuan dari proses dan ditulis pada bagian atau simbol proses

• Nama proses

Menunjukan apa yang dikerjakan oleh proses, nama harus jelas dan lengkap menggambarkan kegiatan prosesnya dan diletakkan dibawah identifikasi proses

 2. Arus Data

Disimbolkan dengan suatu anak panah yang menunjukan ke atau data proses. Arus data ini mengalir diantara proses, simpanan data dan kesatuan luar. Arus data ini menunjukkan arus dari data yang dapat berupa masukan untuk sistem atau hasil dari proses sistem. Arus data yang digambarkan sebagai panah dengan ujung menggambarkan terjadinya dialog.

 3. Simpanan (Data Store)

Komponen ini digunakan untuk memodelkan kumpulan data atau paket yang dapat berupa file atau database disistem komputer, arsip atau catatan manual, kotak tempat data, tabel acuan manual dan agenda atau buku. Simpanan data digambarkan dengan garis sejajar, segi empat dengan sudut melengkung atau persegi panjang.

4. Kesatuan luar(External Entity)

Merupakan kesatuan dilingkungan luar sistem yang dapat berupa orang atau kelompok orang. Misalnya organisasi diluar sistem, group, departemen, perusahaan pemerintah atau sistem lainnya yang berbeda lingkungan luarnya yang akan memberikan input atau menerima output dari sistem. Kesatuan luar dapat disimbolkan dengan kotak persegi empat.

Dibawah ini akan diberikan contoh sederhana Perancangan Sistem Informasi dengan Data Flow Diagram. disini hanya diberikan DFD Konteks sampai pada level 0 saja. untuk pengmbangan silahkan dicoba sendiri.

1.3 Model Data

Data yang disimpan menggambarkan beberapa aspek dari suatu organisasi. Model data adalah himpunan dekskripsi data level tinggi yang dikonstruksi untuk menyembuyikan beberapa detail dari penyimpanan level rendah.

1. ERD(Entity Relationship Diagram)

ERD merupakan suatu model untuk menjelaskan hubungan antara data dalam basis data berdasarkan objek-objek dasar data yang mempunyai hubungan antar relasi. untuk menggambarkannya digunakan beberapa notasi dan simbol. Pada dasarnya ada tiga simbol yang digunakan, yaitu :

• Entity

Entiti merupakan objek yang mewakili sesuatu yang nyata dan dapat dibedakan dari sesuatu yang lain(Fathansyah, 1999: 30). Simbol dari entiti ini biasanya digambarkan dengan persegi panjang 

• Atribut

Setiap entitas pasti mempunyai elemen yang disebut atribut yang berfungsi untuk mendeskripsikan karakteristik dari entitas tersebut Isi dari atribut mempunyai sesuatu yang dapat mengidentifikasikan isi elemen satu dengan yang lain. Gambar atribut diwakili oleh simbol elibs.

• Hubungan Relasi(Relationship)

Hubungan antara sejumlah entitas yang berasal dari himpunan entitas yang berbeda. Relasi dapat digambarkan sebagai berikut :
Relasi yang terjadi diantara dua entitas (misalnya A dan B) dalam satu basis data yaitu (Abdul Kadir, 2002: 48) :  

1. satu ke satu(one to one)

Hubungan relasi satu ke satu yaitu setiap entitas pada himpunan entitas A berhubungan paling banyak dengan satu entitas pada himpunan entitas B  

     2.  satu ke banyak(one to many)

setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B, tetapi setiap entitas pada entitas B dapat berhubungan dengan satu entitas pada himpunan entitas A

     3.  banyak ke banyak(many to many)

Setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B

  2.  REA(Resource Event Agent)

Pemodelan data menggunak REA(Resource Event Agent) di dunia bisnis pada hakikatnya mendasari aktivitas value-chain dari suatu organisasi. REA digunakan untuk desain database dengan menidentifikasikan entitas apa saja yang termasuk dalam database, serta dengan menggambarkan bagaimana struktur hubungan entitas yang bersangkutan didalam database.

Didalam REA terdapat klasifikasi entitas ke dalam 3 kategori yakni :  

• Resources

Merupakan sesuatu yang memiliki nilai ekonomi dalam suatu organisasi. 

• Events

Merupakan berbagai aktivitas bisnis dimana pihak manajemen inginkan untuk  mengumpulkan informasi yang nantinya digunakan untuk tujuan planing dan kontrol

• Agents

Merupakan orang atau organisasi yang berpartisipasi pada event(kejadian) mengenai bagaimana suatu informasi digunakan untuk tujuan planing, kontrol, serta evaluasi.

Aturan dalam pembuata REA(Basic Template REA)

1. Setiap event terhubung paling sedikit dengan satu resource yang memang memberikan effect pada event tersebut.
2. Setiap event terhubung dengan minimal satu event lainnya.
3. Setiap event terhubung dengan minimal dua participant agent. 

 Berdasarkan aturan diatas, standar REA template disajikan sebagai berikut:

 Terdapat tiga langkah dalam pembuatan REA

1. Identifikasi event-event yang akan digunakan manajemen untuk mengumpulkan informasi.
2. Identifikasi resource yang bereffect pada setiap event serta agent yang berpartisipasi dengan event tersebut.
3. tentukan kardinalitas dari setiap hubungan.

Kardinalitas menggambarkan hubungan antara dua entitas dengan mengindikasikan berapa banyak instance untuk setiap entitas yang dapat dihubungkan dengan setiap instance yang spesifik di entitas yang alin

 3. Normalisasi

Proses normalisasi adalah proses pengelompokan data elemen menjadi tabel-tabel yang menunjukkan entity dan relasinya. Pada proses normalisasi dilakukan pengujian pada beberapa kondisi apakah ada kesulitan pada saat menambah/menyisipkan, menghapus, mengubah dan mengakses pada suatu basis data. Bila terdapat kesulitan pada pengujian tersebut maka perlu dipecahkan relasi pada beberapa tabel lagi atau dengan kata lain perancangan basis data belum optimal.

Tujuan dari normalisasi itu sendiri adalah untuk menghilangkan kerangkapan data, mengurangi kompleksitas, dan untuk mempermudah pemodifikasian data.

  Tahapan Normalisasi

1. Bentuk normal pertama (1NF)

Sebuah model data dikatakan memenuhi bentuk normal pertama apabila setiap atribut yang dimilikinya memiliki satu dan hanya satu nilai. Apabila ada atribut yang memiliki nilai lebih dari satu, atribut tersebut adalah kandidat untuk menjadi entitas tersendiri. Entitas utama untuk database tugas matakuliah tentu saja Tugas Matakuliah. Sebagian atribut yang dimiliki entitas ini tertera dalam Gambar 1.

 Atribut Nama Kelas mencantumkan kelas-kelas di mana tugas tersebut berlaku. Apabila pendaftar untuk sebuah matakuliah melebihi kapasitas ruangan yang dimiliki fakultas, kebijakan yang umum diambil Kepala Program Studi adalah membagi kegiatan perkuliahan untuk matakuliah tersebut menjadi beberapa kelas. Karenanya atribut ini rentan memiliki nilai jamak, dan lebih sesuai menjadi entitas baru atau atribut dari entitas lain. Untuk sementara kita membuat entitas baru, Kelas, dimana sebagian atributnya berasal dari Tugas Matakuliah yang secara logis lebih sesuai menjadi atribut entitas ini. Sementara itu, hampir semua atribut entitas Tugas Matakuliah selain Nama Kelas memiliki nilai tunggal (dengan asumsi setiap matakuliah diampu/diajar oleh satu dosen saja).

• Relasi antar-Entitas dan Identifier

Masalah yang kita hadapi sekarang adalah menghubungkan Tugas Matakuliah dengan Kelas. Satu tugas dapat diberikan pada beberapa kelas yang berbeda, dalam terminologi pemodelan data, ini berarti antara entitas Tugas Matakuliah dan entitas Kelas terdapat relasi 1:N (atau 1-N) untuk nilai N lebih dari satu. Cara paling intuitif untuk menghubungkan kedua entitas tersebut adalah menyertakan identitas satu entitas sebagai atribut entitas lain. Identitas sebuah entitas haruslah unik untuk menghindarkan ambiguitas saat akan merujuk pada satu objek khusus dari entitas tersebut. Entitas Tugas Matakuliah akan menggunakan pengidentifikasi arbitrer berupa angka yang berbeda antara satu objek Tugas Matakuliah dengan objek Tugas Matakuliah lain. Entitas Kelas dapat diidentifikasi dengan matakuliah dan kode kelas yang bersangkutan, sehingga kita

cukup menambahkan atribut pengidentifikasi (identifier) dalam kedua entitas.

Entitas ini beserta semua atribut baru dan hubungannya dengan Tugas Matakuliah diperlihatkan dalam Gambar 2, dengan menggunakan notasi relasi crows foot (dengan simbol “kaki gagak”menunjuk pada entitas jamak). 

 Sejauh ini tidak ada atribut entitas yang memiliki nilai lebih dari satu, sehingga rasanya cukup aman mengatakan bahwa model ini memenuhi bentuk normal pertama.

2. Bentuk Normal kedua(2NF)

Sebuah model data dikatakan memenuhi bentuk normal kedua apabila ia memenuhi bentuk normal pertama dan setiap atribut non-identifier sebuah entitas bergantung sepenuhnya hanya pada semua identifier entitas tersebut.

Apabila kita perhatikan kembali model data yang telah kita hasilkan di atas, segera terlihat bahwa atribut dari entitas Kelas tidak sepenuhnya bergantung pada identitas unik Kelas tersebut. Seorang dosen akan tetap ada meskipun kelas matakuliah yang ia ampu sudah tidak ada lagi. Dalam hal ini, dosen adalah entitas tersendiri (yang nantinya dapat dilekatkan pada entitas Fakultas atau Universitas bilamana kedua entitas tersebut dirasa perlu ada, tergantung pada kebutuhan pemodelan data kita).

• Identifier

Dalam dunia nyata, anggapan yang umum adalah seseorang (“individu”) dapat diidentifikasi secara unik dengan namanya. Tentu saja anggapan ini tidak sepenuhnya benar, karena bisa saja sebuah nama (bahkan satu rangkaian nama lengkap) dimiliki oleh lebih dari satu orang. Pemodelan data yang melibatkan informasi tentang individu jarang

menggunakan nama individu tersebut sebagai satu-satunya pengidentifikasi. Implementasi RDBMS tertentu juga akan lebih cepat memproses query atas suatu tabel apabila tabel tersebut diindeks oleh nilai integer unik daripada bila menggunakan indeks

karakter (rangkaian karakter masih harus diumpankan ke fungsi hash agar dapat digunakan sebagai indeks tabel, sementara untuk integer unik tidak harus).

Karena beberapa alasan tersebut, entitas Dosen pada model data kita akan menggunakan pengidentifikasi arbitrer berupa Nomor Induk Pegawai sebagaimana diperlihatkan dalam Gambar 3. Dalam notasi crows foot, relasi non-identifying digambarkan dengan garis putus-putus atau tersamar.

 Setelah atribut-atribut dari semua entitas dalam sebuah model data hanya bergantung pada seluruh pengidentifikasi entitas yang memilikinya, model data tersebut dikatakan memenuhi bentuk normal kedua

3. Bentuk normal ketiga(3NF)

Sebuah model data dikatakan memenuhi bentuk normal ketiga apabila ia memenuhi bentuk normal kedua dan tidak ada satupun atribut non-identifying (bukan pengidentifikasi unik) yang bergantung pada atribut non-identifying lain. Apabila ada, pisahkan salah satu atribut tersebut menjadi entitas baru, dan atribut yang bergantung padanya menjadi atribut entitas baru tersebut.

Dalam model data sederhana yang kita gunakan di sini, tidak ada satupun atribut non-identifying (seperti Deskripsi Tugas Matakuliah, atau Nama Dosen) yang bergantung pada atribut nonidentifying lain. Namun demi adanya contoh, kita misalkan entitas Dosen memiliki atribut informasi Alamat Rumah dan Nomor Telepon Rumah. Keduanya tidak dapat secara unik mengidentifikasi objek tertentu dari entitas Dosen, namun keduanya saling bergantung. Sebagaimana dalam dua langkah normalisasi sebelumnya, jenis kebergantungan seperti ini dapat dihilangkan dengan membuat entitas baru lagi (yang tidak akan diciptakan karena tiga entitas sudah cukup banyak untuk satu artikel).

Model terakhir yang kita dapat ini telah memenuhi bentuk normal ketiga (third normal form) dan siap dikonversi menjadi tabel. Namun sebelumnya, kita perlu membahas berbagai jenis relasi yang kerap ditemui dalam pemodelan data, termasuk yang kita temui dalam contoh model data kali ini.

Referensi :

Handout Institut Sains & Teknologi Akprind : Pemrograman Basis Data

http://muhhamim.blogspot.com/2008/04/perancangan-sistem-informasi-dengan-dfd.html

http://muhhamim.blogspot.com/2008/04/perancangan-sistem-informasi-dengan-dfd.html

http://www.google.co.id/#q=normalisasi+database&hl=id&ei=3QxdTMLMF4SgvgP3pMGZDA&start=10&sa=N&fp=e8b2c82f5b9cb860