Pengantar Umum
Merancang sistem komputerisasi adalah
tugas pokok dari seorang Systems Analyst.
Hasil rancangan tersebut selanjutnya akan ditindaklanjuti dengan pembuatan
program aplikasi oleh programmer.
Sistem komputerisasi yang telah dibuat selanjutnya akan diimplementasikan oleh user.
Pada kenyataannya, banyak sekali
pertimbangan yang harus dilakukan seseorang dalam membuat sistem komputerisasi,
misalkan spesifikasi hardware dan software (teknologi) apa saja yang
dibutuhkan, berapa anggaran yang disediakan, siapa saja yang terlibat dan harus
ditraining, waktu yang tersedia, dan
sebagainya.
Karenanya, perancangan sistem
komputerisasi akan melibatkan banyak orang di dalamnya. Hal ini mengharuskan
dibuatnya ‘master plan,’ ‘blue print,’ atau skenario umum yang
harus disepakati bersama terlebih dulu.
Catatan ini hanya memberikan sedikit
gambaran dari perancangan sistem komputerisasi
yang sangat rumit, yaitu hanya membahas tentang Data Flow Diagram, Entity
Relationship Diagram, dan Normalisasi Data.
Data
Flow Diagram (DFD)
Pengantar
DFD
DFD merupakan salah satu komponen dalam
serangkaian pembuatan perancangan sebuah sistem komputerisasi. DFD
menggambarkan aliran data dari sumber pemberi data (input) ke penerima data
(output). Aliran data itu perlu diketahui agar si pembuat sistem tahu persis
kapan sebuah data harus disimpan, kapan harus ditanggapi (proses), dan kapan
harus didistribusikan ke bagian lain.
Komponen-komponen
DFD
Komponen-komponen DFD terdiri atas :
Terminator Proses Alur Data Penyimpan Data (data store)
Gambar 1. Komponen-komponen DFD
(1). Terminator
Terminator dapat disebut juga ‘Kesatuan
Luar,’ yaitu suatu unit kerja/ jabatan, atau sejenisnya yang berada di luar
sistem tetapi memberi andil atas pemberian atau penerimaan data dari sistem
secara langsung. Terminator dapat pula disebut dengan ‘Sumber Pemberi Data
(input),’ maupun ‘Tujuan Pemberian Data (output).’
Pemberi data dan penerima data yang
dimaksud adalah pihak yang sangat dekat dan memiliki hubungan langsung dengan
sistem. Adapun pihak luar yang berhubungan dengan pihak luar lainnya tidak
boleh digambarkan.
(2). Proses
Proses adalah suatu tindakan yang akan
diambil terhadap data yang masuk. Karena proses adalah tindakan, maka proses
berisi kata kerja, Proses diberikan identifikasi (nomor) agar mempermudah
sekuen untuk diagram detilnya.
(3).
Alur Data
Alur data menggambarkan data yang
mengalir dari terminator ke proses atau dari proses ke proses lainnya. Data
yang dibawa oleh alur data harus disebutkan dan diletakkan di atas lambang alur
data dan bila alur data digambar panjang, sebaiknya penulisan data mendekati
lambang anak panahnya.
Data yang menempati alur data dapat
berupa elemen data tunggal, maupun kumpulan elemen data. Misalkan, pada kumpulan
elemen data : ‘Jawaban Ujian’, dapat ditulis secara lengkap dengan menyebutkan
setiap elemen data yang ada di sana, yaitu : ‘Lembar Jawaban’, dan ‘Naskah
Soal’.
(4). Penyimpan Data (Data Store)
Data yang akan disimpan perlu
ditempatkan ke satu tempat penyimpanan data. Data yang disimpan dapat berupa
data manual maupun data digital. Untuk data digital, penyimpan data tersebut
kelak akan dijadikan file data di
komputer. Alur data yang anak panahnya menuju penyimpan data, kegiatannya
adalah ‘menulis/ merekam’ data, sehingga isi file data akan berubah karenanya. Sedangkan alur data yang anak
panahnya menuju ke proses dari penyimpan data, kegiatannya adalah ‘membaca’
data, sehingga isi file data tidak
akan berubah karenanya.
LEVELISASI
DFD
DFD digambarkan secara bertingkat, dari
tingkat yang global berturut-turut hingga tingkat yang sangat detil. Tingkat
yang global (umum) disebut dengan ‘Diagram Konteks’ atau ‘Context Diagram’. Ini termasuk level
0.
Selanjutnya, dari diagram konteks,
prosesnya dijabarkan lebih rinci lagi di ‘Diagram Nol’ atau ‘Zero Diagram.’ Ini disebut level 1. Pada diagram nol ini yang
berkembang hanya proses dan alur data yang menghubungkan proses-prosesnya,
sedangkan jumlah terminator dan alur data yang masuk atau keluar dari terminator,
tetap.
Bila, masih dirasakan perlu memerinci
proses berikutnya, maka diagram selanjutnya disebut dengan ‘Diagram Detil’ atau
‘Diagram primitif.’ Ini disebut dengan level
2. Dalam diagram detil, yang digambar cukup proses (nomor berapa) yang perlu didetilkan
saja, selain itu (proses lainnya, atau terminatornya) tidak perlu digambarkan.
Bila masih dapat lebih didetilkan lagi,
maka level 3, dan seterusnya bisa
dibuat.
Contoh
Kasus
Di sebuah tempat penyewaan Video Compact Disk (VCD), masih
dilakukan pencatatan manual untuk Penyewaan dan pengembalian VCD oleh Penyewa.
Dalam kasus ini, akan dirancang sistem komputerisasi Penyewaan (saja) VCD
tersebut.
Analisis
1. Pihak-pihak yang terkait :
a.
Penyewa;
b.
Pemilik usaha;
c.
Petugas.
Petugas berada di dalam sistem (yang
menjalankan sistem), sehingga tidak perlu digambarkan. Dari sini, terdapat 2
terminator, yaitu a dan b.
1.a. Penyewa
Data apa saja yang akan diberikan oleh
Penyewa kepada sistem, dan data apa saja yang diberikan sistem kepada penyewa
?. Analisis ini bertujuan untuk menentukan data apa saja yang akan mengalir di
alur data dari terminator Penyewa ke sistem (proses), dan sebaliknya.
1.a.1.
Penyewa Baru
Penyewa baru (di kasus ini) harus
membuat Kartu Anggota terlebih dulu. Pembuatan Kartu Anggota tidak dipungut
biaya tetapi si Penyewa harus menunjukkan identitas diri (contoh : KTP).
Petugas akan mencatat identitas
Penyewa, membuatkan Kartu Anggota, dan bersama dengan KTP tersebut
diserahkan kembali ke Penyewa.
Proses manual bahwa KTP tersebut
dikembalikan ke Penyewa tidak harus digambarkan di dalam arus data.
1.a.2. Prosedur Penyewaan oleh Penyewa
Penyewa yang akan meminjam film
dipersilakan mencari sendiri filmnya, namun, bila mereka enggan mencarinya
(tidak ketemu), mereka dapat langsung bertanya ke petugas. Petugas akan
mengecek data film yang dicari dan akan dipinjam tersebut ke file di komputer. Hasil pengecekan itu
diinformasikan kepada Penyewa.
Bila film dicari ada dan mereka
mau meminjamnya, maka si Penyewa harus menyerahkan Kartu Anggotanya (di
lapangan, bisa saja hanya dengan menyebutkan identitasnya saja), dan uang
sewanya.
Adakalanya, petugas yang tidak yakin
akan keanggotaan si Penyewa, dia melakukan cek keanggotaan ke file komputer. Bila ternyata data
keanggotaannya tidak ada, maka si Petugas akan melakukan penolakan (pembatalan
transaksi).
Bila benar anggota, maka Petugas akan
mencatat data film yang dipinjam si
Penyewa tersebut (transaksi) dan akan menyerahkan kembali Kartu Anggota dan
film yang akan dipinjam tersebut ke Penyewa.
[Film | Informasi Penolakan] bisa
ditulis : Film, Informasi Penolakan.
1.b.
Pemilik Usaha (disingkat dengan Pemilik).
Apa saja data yang dibutuhkan oleh pemilik
atas sistem, dan data apa saja yang diberikan oleh pemilik kepada sistem, perlu
di analisis. Analisis ini akan menghasilkan alur data apa saja yang mengalir
dari Terminator ke sistem dan
sebaliknya.
Pada kasus ini, dicontohkan bahwa
Pemilik hanya butuh laporan keuangan harian.
Dari analisis di atas, dapat dirancang
DFD konteksnya :
Gambar 6. DFD Konteks Kasus di Atas
“Aplikasi Peminjaman” yang tergambar di
atas bisa saja ditulis secara detil, misalkan Bukti Keanggotaan, Uang Sewa, dan
Daftar Film yang akan Disewa. “Identitas” boleh saja ditulis [KTP|SIM].
Sekali lagi, yang mengalir adalah data
yang akan mempegaruhi proses komputerisasi, sedangkan untuk proses manualnya
tidak perlu digambarkan. Misalkan, sewaktu akan meminjam film, Penyewa
menyerahkan Kartu Anggota dan sewaktu menerima film, Kartu Anggota tersebut
dikembalikan. Hal itu tidak perlu digambarkan.
2. Pembuatan Diagram Nol (Level 1)
Diagram Nol adalah pengembangan proses
yang lebih mendetil dari proses (sistem) yang ada di konteksnya. Jadi, jumlah
terminator dan alur data yang masuk dan keluar dari terminator harus tetap.
2.1. Proses Pembuatan Kartu Anggota
Lihat poin 1.a.1. di atas. Gambar
DFD-nya :
Gambar 7. Penggalan Diagram Nol
2.2. Proses Penyewaan VCD
Lihat poin 1.a.2. di atas. DFD-nya akan
digambarkan sebagai :
Gambar 8. Penggalan Diagram Nol
2.3. Proses Permintaan Informasi
Keberadaan Film
Gambar 9. Penggalan
Diagram Nol
2.4. Gambar DFD Zero (level 1) Lengkapnya
Gambar 10. DFD Level 1 Kasus di Atas
Beberapa
catatan tambahan :
(1) Pembuatan rancangan DFD harus sesuai
dengan prosedur yang berlaku di tempat penelitian (jadi harus ada pembahasan
mengenai prosedur yang berlaku, dan prosedur tersebut bukan penguji yang
menentukan);
(2) Penggambaran DFD hendaknya dibuat
sebaik mungkin (mudah ditelusuri, dan tidak rumit, misalkan dengan tidak adanya
alur data yang bersilangan).
(3) Bila akan terjadi persilangan alur di
penyimpan data, maka penyimpan data tersebut dapat digambar kembali dan diberi
tanda ‘*’ yang menandakan bahwa penyimpan data tersebut sama dengan nama
penyimpan data sebelumnya (copy).
(4) Tanda ‘*’ di nomor proses berarti
proses tersebut tidak perlu didetilkan lagi.
3.
Pembuatan Diagram Detil (level
2)
Diagram detil perlu digambarkan bila
masih ada suatu proses yang bisa dirinci lebih lanjut. Di sini dimisalkan
penggambaran dari proses 1.0 (Pembuatan Kartu Anggota).
Gambar 11. Diagram 1.0 Level 2
Gambar 12. Diagram 2.0 Level 2
ENTITY
RELATIONSHIP DIAGRAM (ERD)
Pengantar
ERD adalah gambaran mengenai
berelasinya antarentitas. Sistem adalah kumpulan elemen yang setiap elemen
memiliki fungsi masing-masing dan secara bersama-sama mencapai tujuan dari
sistem tersebut. ‘Kebersama-sama’-an dari sistem di atas dilambangkan dengan
saling berelasinya antara satu entitas dengan entitas lainnya.
Entitas (entity/ entity set), memiliki banyak istilah di dalam ilmu
komputer, seperti tabel (table),
berkas (data file), penyimpan data (data store), dan sebagainya.
Komponen-komponen
ERD
ERD memiliki komponen-komponen :
Entitas Relasi Atribut
Gambar 13. Komponen-komponen ERD.
1.
Entitas dan atribut.
Seperti telah dijelaskan di atas,
entitas adalah tempat penyimpan data, maka entitas yang digambarkan dalam ERD
ini merupakan data store yang
ada di DFD dan akan menjadi file data
di komputer.
Entitas adalah suatu objek dan memiliki
nama. Secara sederhana dapat dikatakan bahwa jika objek ini tidak ada di suatu enterprise (lingkungan tertentu), maka enterprise tersebut tidak dapat berjalan
normal. Contoh, entitas ‘MAHASISWA’ harus ada di lingkungan perguruan tinggi,
begitu juga dengan entitas ‘DOSEN’, ‘MT_KULIAH’, dan sebagainya.
Di dalam entitas ‘MAHASISWA’ berisi
elemen-elemen data (biodata mahasiswa) yang terdiri atas NPM, NAMA, KELAS, ALAMAT,
dan sebagainya. NPM, NAMA, KELAS, dan ALAMAT disebut dengan atribut (field).
Apa saja atribut yang bisa menjadi ciri
dari entitas, secara sederhana dapat dilakukan dengan melakukan pertanyaan
logis. Misalkan, di entitas MAHASISWA ada atribut NILAI. Tanyakan ke mahasiswa,
‘berapa nilai anda ?.’ Tentu si
mahasiswa akan berbalik tanya : ‘nilai apa ?,’ karena pertanyaan tersebut tidak
dapat dijawab langsung, maka NILAI bukanlah atribut dari mahasiswa.
Jika, pertanyaan yang diajukan dapat
dijawab entitas secara logis dan benar, maka ia merupakan atributnya. Misalkan
‘berapa tinggi badan anda ?,’ maka tinggi badan adalah atribut dari mahasiswa,
meskipun hal itu tidak perlu digunakan karena tidak berfungsi apa-apa dalam
kemahasiswaannya.
Jadi, ada atribut yang harus ada,
ada atribut yang boleh ada, dan ada atribut yang tidak boleh ada,
di dalam sebuah entitas. Contoh penggambaran entitas dan atributnya.
Penggambaran ER dari kasus di atas
(lanjutan dari DFD) dilakukan dengan cara :
(1) Data Store (penyimpan data) yang ada di DFD akan menjadi Entity di dalam ERD;
(2) Tentukan atribut-atribut (secara
logika) yang harus ada di dalam setiap entitasnya;
(3) Tentukan serajat kardinalitasnya sesuai
dengan peraturan yang berlaku di rental tersebut (dalam hal ini, setiap Penyewa
boleh menyewa film lebih dari satu);
(4) Tentukan kunci atribut di setiap
entitasnya.
Gambar 16. ERD dari Kasus di Atas
Derajat kardinalitas yang terjadi
adalah M : N (many to many). Mengapa
tidak M : M, karena belum tentu “10 orang penyewa pasti menyewa 10
film.” Karena tidak selalu M = M, maka dipilih M : N saja, jadi, suatu saat M
boleh = N, dan di saat lain boleh M ¹ N.
Cara menentukan many to many-nya adalah dengan membuat dua kalimat bolak-balik.
Derajat kardinalitas kalimat pertama diletakkan di atas, dan derajat
kardinalitas kalimat kedua diletakkan di bawah.
Kalimat pertama : “satu orang
penyewa boleh pinjam satu atau lebih (judul) film.”
Kalimat kedua : “satu (judul)
film boleh dipinjam oleh satu atau lebih penyewa”
Gambar 17. Penentuan Many to Many
Di antara derajat kardinalitas yang
berada di atas dan bawah, dicari yang terbesar (yang kecil dihapus), maka akan
didapatkan M : M yang pada akhirnya dilambangkan dengan M : N.
4.
Penentuan Primary Key
Di setiap entitas di dalam ERD (di
gambar 12 di atas), seharusnya ada atribut (field)
yang dipilih untuk dijadikan kunci utama atribut (primary key/ key field), yaitu atribut yang dijadikan
identitas yang menjamin keunikan (tidak ada yang sama) isi datanya.
Misalkan, untuk entitas mahasiswa
dipilih atribut NPM sebagai kunci utama atributnya karena tidak ada satupun
mahasiswa yang memiliki NPM yang sama.
Penulisan kunci utama atribut di dalam
ERD harus dibedakan dengan atribut lainnya, misalkan dengan pemberian tanda ‘*’
di depan nama atributnya, atau digarisbawahi atributnya.
Secara logika, memang mudah menentukan
sebuah atribut kunci, namun sesungguhnya, kunci utama diperoleh dari kunci
kandidat, dan kunci kandidat diperoleh dari kunci super.
SUPER KEY
Super key adalah satu atau lebih field yang dapat dipilih untuk membedakan (mengkarakteristikkan)
antara satu record dengan record lainnya. Bila filenya adalah MAHASISWA, maka satu atau
lebih field yang dipilih agar dapat
membedakan antara satu orang mahasiswa dengan mahasiswa lainnya.
NPM jelas bisa membedakan, NAMA juga
bisa, namun dengan syarat tidak ada nama yang sama, gabungan NPM dan NAMA pasti
bisa membedakan, apalagi gabungan NPM, NAMA dan TGL_LAHIR. Sehingga, super key bisa merupakan kombinasi dari
satu atau gabungan field yang dapat
mencirikan suatu record.
Super keynya : NPM
NAMA
(dengan syarat tidak ada nama yang sama)
ALAMAT
(dengan syarat alamat tidak ada yang sama)
TGL_LAHIR
(dengan syarat tidak ada tanggal lahir yang sama)
NPM+NAMA
NPM+NAMA+ALAMAT
NPM+TGL_LAHIR
NPM+ALAMAT+TGL_LAHIR
dan
berbagai kombinasi lainnya
CANDIDATE KEY
Kunci kandidat adalah kunci super
dengan jumlah field paling sedikit,
maka diperoleh : NPM, NAMA, ALAMAT, TGL_LAHIR (karena masing-masing hanya
terdiri dari 1 field saja).
PRIMARY KEY
Kunci utama adalah kunci kandidat yang
dipilih dengan kemungkinan kepemilikan nilai data field yang berbeda antara satu record
dengan record lainnya. Maka dipilih
NPM karena tidak ada mahasiswa yang memiliki NPM yang sama. Jelaslah, kunci
utama pastilah merupakan kunci kandidat dan juga kunci super, tetapi
sebaliknya, kunci super dan kunci kandidat belum tentu merupakan kunci utama.
ALTERNATE KEY
Kunci kandidat yang tidak terpilih
menjadi kunci utama disebut dengan kunci alternatif.
NORMALISASI DATA (ND)
Normalisasi data adalah suatu proses/
prosedur/ cara yang menjamin sebuah data menjadi valid, dan efisien. Di dalam
sistem basis data, ND juga berfungsi untuk meniadakan kerangkapan data (redundancy).
Banyak tahapan dalam ND, namun di sini
hanya diperkenalkan 3 tahapan yang disebut dengan 1NF (first normal form), 2NF (second
normal form), dan 3NF (third normal
form).
1.
1NF/ First Normal Form (Bentuk Normal Pertama)
Pada tahap ini, setiap atribut
diperiksa apakah sudah bersifat ‘atomik’, atau apakah atribut tersebut dalam
penggunaannya kelak tidak perlu dibagi-bagi lagi. Contoh : Untuk penulisan
atribut NAMA yang isi datanya adalah “George Washington”.
Apakah nama “George Washington”
selamanya akan ditulis dengan “George Washington ? ”, bila ya, maka atribut NAMA sudah atomik.
Tetapi, adakalanya, “George Washington” akan dituliskan sebagai “Washington,
George”. Kalau demikian, bagaimana caranya mencetak nama “Washington, George”
bila data nama yang disimpan adalah “George Washington” ?.
Untuk itu, atribut NAMA harus dibagi
lagi (karena belum atomik), menjadi NAMA1 yang berisi “George”, dan NAMA2 yang
berisi “Washington”, sehingga untuk mencetak “Washington, George”, cetak dulu
NAMA2, baru NAMA1.
Lihat gambar 16 di atas, atribut ALAMAT
dibagi-bagi lagi menjadi JALAN, RT/RW, NO_RUMAH, dan KD_POS.
2.
2NF/ Second Normal Form (Normalisasi Bentuk Kedua)
Normalisasi bentuk kedua mensyaratkan
bahwa 1NF sudah terpenuhi dan setiap atribut yang bukan merupakan kunci harus
tergantung sepenuhnya dengan atribut kuncinya.
Hal ini merupakan kelanjutan dari
bahasan di ERD tentang entitas dan atribut. Misalkan, untuk data DOSEN, bila
dipilih KD_DOSEN sebagai kunci atributnya, maka semua atribut yang ada harus
tergantung secara fungsional dengan atribut KD_DOSENnya. Artinya, bila isi
KD_DOSEN berganti, maka dosen (orangnya) harus merupakan orang yang lainnya.
Contoh atribut yang salah (bila ada) di
dalam entitas DOSEN yaitu NAMA_MHS. NAMA_MHS tidak tergantung pada KD_DOSEN.
3.
3NF/ Third Normal Form (Normalisasi Bentuk Ketiga)
Normalisasi bentuk ketiga mensyaratkan
bahwa 2NF sudah terpenuhi dan setiap atribut yang bukan merupakan kunci tidak
boleh tergantung dengan atribut yang bukan kunci lainnya. Atau “menghilangkan
ketergantungan transitif”.
Contoh kalimat ketergantungan transitif
adalah : “Bila A tergantung B, dan B tergantung C, maka A akan tergantung pula
oleh C”. Ini harus ditiadakan, menjadi A tergantung B, dan C juga tergantung B.
Contoh : dalam sebuah file ada field NPM, NAMA, TGL_LAHIR,
KD_POS, KOTA dengan catatan KD_POS dan KOTA merupakan alamat dari mahasiswa.
NAMA, TGL_LAHIR, KD_POS, KOTA
tergantung pada NPM-nya. Tetapi, KOTA tergantung pada KD_POS, jadi, susunan
atribut ini tidak memenuhi syarat 3NF. Entitas ini harus dibagi menjadi 2,
yaitu entitas MAHASISWA yang terdiri dari NPM, NAMA, TGL_LAHIR, KD_POS, dan
entitas KODEPOS yang terdiri dari KD_POS dan KOTA.
KD_POS di entitas MAHASISWA merupakan
kunci tamu, dan KD_POS di entitas KODEPOS merupakan kunci utama.
Penyelesaian dari kasus di atas :
Hasil proses normalisasi bentuk pertama
:
Proses normalisasi bentuk kedua :
Hasil proses normalisasi bentuk kedua :
Gambar 19. Hasil Normalisasi Data
Tingkat kedua
Hasil proses normalisasi bentuk ketiga
:
Atribut ‘Kota’ di entitas Penyewa
tergantung transitif kepada ‘Kd_Pos’. Karenanya, atribut ‘Kota’ dijadikan file sendiri dengan kunci atribut
‘Kd_Pos’.
Gambar 20. Hasil Normalisasi Data
Tingkat Ketiga
4.
File-file data yang digunakan
Dari hasil proses normalisasi data di
atas, maka terbentuk tabel-tabel yang di komputer akan menjadi file-file data yang akan digunakan
sebagai tempat menyimpan data. File-file data yang terbentuk tadi akan
disesuaikan formatnya dengan bahasa pemrograman yang akan digunakan.
Dalam data base, pembuatan tabel
tersebut dilakukan dengan DDL (data
definition language) untuk
melakukan create table, dan pemasukan
datanya dilakukan dengan DML (Data
Manipulation Language) untuk melakukan insert
data. Contoh bahasa yang digunakan adalah SQL atau DB2.
Contoh bila dalam bahasa pemrograman dBase :
1.
Nama File :
PENYEWA.DBF
Nama Field
|
Jenis Field
|
Panjang
|
Index
|
NO_ANG
|
Characters
|
6
|
Y
|
NAMA
|
Characters
|
20
|
|
JALAN
|
Characters
|
15
|
|
NO_RUMAH
|
Characters
|
5
|
|
RT_RW
|
Characters
|
8
|
|
Kd_Pos
|
Characters
|
5
|
|
2. Nama File : PINJAM.DBF
Nama Field
|
Jenis Field
|
Panjang
|
Index
|
NO_KWIT
|
Characters
|
6
|
Y
|
NO_ANG
|
Characters
|
6
|
|
KD_FILM
|
Characters
|
6
|
|
TGL_PINJ
|
Characters
|
10
|
|
TGL_KEMB
|
Characters
|
10
|
|
JML_FILM
|
Numeric
|
2
|
|
JML_BYR
|
Numeric
|
6
|
|
JML_DEN
|
Numeric
|
6
|
|
TGL_BYR
|
Characters
|
10
|
|
TGL_DEN
|
Characters
|
10
|
|
3. Nama File : FILM.DBF
Nama Field
|
Jenis Field
|
Panjang
|
Index
|
KD_FILM
|
Characters
|
6
|
Y
|
JUD_FILM
|
Characters
|
20
|
|
STOCK
|
Numeric
|
2
|
|
JNS_FILM
|
Characters
|
15
|
|
HRG_SEWA
|
Numeric
|
5
|
|
4. Nama File : KOTA.DBF
Nama Field
|
Jenis Field
|
Panjang
|
Index
|
KD_POS
|
Characters
|
5
|
Y
|
KOTA
|
Characters
|
15
|
|
DDL :
Ketik
Create;
Kemudian
tentukan field fieldnya melalui menu
Rancangan I/O :
Struk peminjaman
KESIMPULAN :
Mata kuliah Perancangan Sistem ini
bertujuan untuk membuat sistem komputerisasi, di mana di dalamnya terdapat file-file yang merupakan hasil dari
perancangan (data store di DFD, dan Entity di ERD).
Adapun proses atau prosedur
manualnya tidak perlu digambarkan. Di pelajaran ini yang perlu dipikirkan
hanyalah, bagaimana membentuk file-file
dalam satu kesatuan (sistem), bagaimana agar file-file tersebut dapat berdaya-guna secara efisien dan memenuhi
aturan-aturan sebuah perancangan yang baik.