Selasa, 21 April 2009

ANALISA PUSKESMAS

TUGAS REKAYASA PERANGKAT LUNAK


ANALISA PUSKESMAS IBRAHIM ADJIE

JL. Ibrahim Adjie No 88



Nama : Lilis.Maisyaroh

NIM : 2106005

Jurusan : Manajemen Informatika
















SEKOLAH TINGGI MANAJEMEN INFORMATIKA DAN KOMPUTER

STMIK GANESHA

2009



1. STRUKTUR ORGANISASI UPT PUSKESMAS IBRAHIM ADJIE

KEPALA UPT PUSKESMAS

Dr. Hj. AWA PURWANTI KEN






KA.SUBAG. TATA USAHA





KELOMPOK JABATAN FUNGSIONAL

ADMINISTRASI

BENDAHARA


UMUM

KUSGIONO

UMUM

HJ.DIAN A. M.KES



PENTOR

SUSI SUSILAWATI



MASKIN

ROSIRA DEWI





PROMKES


KESLING


P2PL

PENINGKATAN KES KEL & REPRODUKSI


PERKESMAS

PENYEMBUHAN PENYAKIT &

RUJUKAN

PERBAIKAN GIZI

KELUARGA

PROGRAM PENGEMBANGAN

PROGRAM PENUNJANG




TITI


KLINIK SANITASI

HJ. DARMILAH

KIA

SUPRIHARTININGSIH

BERSALIN KRISTIANI

KLINIK GIZI

AI. DEWI P. SP



HJ. DIAN M.Kes

IMUNISASI

ASEP OMAN

KB

HJ. BUNTARI

UKS

ERLIS

KES. JIWA

LINA Am.Kep

KES. MATA

LINA Am.Kep


TBC

ECIN K

BP UMUM

LINA.Am.Kep

BP GIGI

Drg. YUDHA H

FARMASI

IIS RUKMAWATI


KES.REMAJA


SURVEYLANCE

WAGE


SPECIALIS

ANAK

Dr. TITA Sp.A

MEDREC/SP3

ANTI S

LABORATORIUM ASEP RAHMAT.Ir





HR

ECIN K


USILA

TITI






Flow Map Pendaftaran


Pasien

Bag. Administrasi & Pendaftraran

Kepala Puskesmas


















































Flowmaf Pemeriksaan Pasien


Pasien

Ruang Tunggu

Ruang Perawatan/Dokter















































































Pasien

Ruang Obat/Petugas

Kep Puskesmas


















































5. Data Flow Diagram




Calon Pasien

Pasien



Pasien

Kep. Puskesmas





Kartu Data Anggota Laporan Pasien Bulanan

Pasien Data Obat

Obat

Calon Pasien Laporan Pasien Tahunan


Laporan Obat










Resep Obat Resep Obat





Laporan


Obat


Laporan data Pasien





4. Kontek Diagram

Lap. Bulanan

Data Pasien



Laporan Obat

Formulir Pendaftaran Lap.Tahunan

Data Pasien








Kartu Pasien

Obat








Sabtu, 07 Maret 2009

Normalisasi Database

TUGAS REKAYASA PERANGKAT LUNAK
Nama : Lilis Maisyaroh
NIM : 2106005
Jurusan : MI/D3

Proses normalisasi pertama kali diperkenalkan oleh E.F.Codd pada tahun 1972. Normalisasi sering dilakukan sebagai suatu uji coba pada suatu relasi secara berkelanjutan untuk menentukan apakah relasi tersebut sudah baik atau masih melanggar aturan-aturan standar yang diperlakukan pada suatu relasi yang normal (sudah dapat dilakukan proses insert, update, delete, dan modify pada satu atau beberapa atribut tanpa mempengaruhi integritas data dalam relasi tersebut).

Proses normalisasi merupakan metode yang formal/standar dalam mengidentifikasi dasar relasi bagi primary keynya (atau candidate key dalam kasus BCNF), dan dependensi fungsional diantara atribut-atribut dari relasi tersebut. Normalisasi akan membantu perancang basis data dengan menyediakan suatu uji coba yang berurut yang dapat diimplementasikan pada hubungnan individualshingga skema relasi dapat di normalisasi ke dalam bentuk yang lebih spesifik untuk menghindari terjadinya error atau inkonsistansi data, bila dilakuan update tehadap relasi tersebut dengan Abnomaly.

1.1 BEBERAPA DEFINISI NORMALISASI
• Normalisasi adalah suatu proses memperbaiki / membangun dengan model data relasional, dan secara umum lebih tepat dikoneksikan dengan model data logika.
• Normalisasi adalah proses pengelompokan data ke dalam bentuk tabel atau relasi atau file untuk menyatakan entitas dan hubungan mereka sehingga terwujud satu bentuk database yang mudah untuk dimodifikasi.
• Normalisasi dapat berguna dalam menjawab 2 pertanyaan mendasar yaitu: “apa yang dimaksud dengan desain database logical?” dan “apa yang dimaksud dengan desain database fisikal yang baik? What is phisical good logical database design?”.
• Normalisasi adalah suatu proses untuk mengidentifikasi “tabel” kelompok atribut yang memiliki ketergantungan yang sangat tinggi antara satu atribut dengan atrubut lainnya.
• Normalisasi bisa disebut jga sebagai proses pengelompokan atribut-atribut dari suatu relasi sehingga membentuk WELL STRUCTURED RELATION

WELL STRUCTURED RELATION adalah sebuah relasi yang jumlah kerangkapan datanya sedikit (Minimum Amount Of Redundancy), serta memberikan kemungkinan bagi used untuk melakukan INSERT, DELETE, MODIFY, terhadap baris-baris data pada relasi tersebut, yang tidak berakibat terjadinya ERROR atau INKONSISTENSI DATA, yang disebabkan oleh operasi-operasi tersebut.

1.2 Model Perancangan Database
Perancangan database dalam penekanan tinjauannya dilakukan pada struktur data dan relasi antar file. Dua Teknik pemodelan perancangan database diantaranya adalah sebagi berikut :
1. Teknik Normalisasi
Yaitu suatu file yang terdiri dari beberapa grup elemen yang berulang – ulang perlu organisaikan kembali. Proses untuk mengorganisaikan file untuk menghilangkan grup elemen yang berulang – ulang ini disebut dengan normalisasi (normalization). Menurut Chris Gane dab Tris Sarson 1979.
Normalisasi juga banyak dilakukan dalam merubah bentuk database dari struktur pohon atau struktur jaringan menjadi truktur hubungan. Konsep dan teknik normalisasi ini dikenalkan oleh Dr.E.F Codd di papernya. Pada tahun 1972 E.F Codd dalam papernya ini mendefinisikan struktur data yang baru, yaitu yang disebut dengan struktur data hubungan (relational data structure).
Tujuan dari normalisasi adalah untuk menghilangkan kumpulan relasi dari insertion, update, dan deletion depentdency yang tidak diharapkan. Aturan normalisasi merupakan suatu aturan yang dikenal pada relasi – relasi dalam basis data serta dipenuhi oleh relasi pada setiap level normalisasi. Beberapa level yang digunakan pada normalisasi yaitu:
a. Bentuk Normal Pertama (First Normal Form Relation)
Bentuk normal pertama biasanya pada sebuah table yang belum normal.Syarat yang harus dipenuhi pada normal pertama jika nilai dari satu atribut dibuat dalam bentuk table yang sederhana dan atribut bernilai tunggal.
b. Bentuk Normal Kedua (Second Normal Form Relation )
Bentuk normal kedua didefinisikan berdasarkan dependensi fungsional. Dengan tujuan menghilangkan redundasi data. Syarat harus dipenuhi dalam normalisasi kedua adalah:
a. Harus memenuhi syarat bentuk normal pertama.
b. Seluruh atribut yang bukan kunci primer, memiliki dependensi sepenuhnya terhadap kunci primer.
Bentuk normal kedua mensyaratkan setiap atribut tergantung pada kunci primer, hal ini pertama yabg harus dilakukan adalah mencari kunci pada table tersebut.
c. Bentuk Normal Ketiga (Third Normal Form Relation)
Suatu relasi memenuhi norma ketiga, jika memenuhi syarat sebagai berikut:
a. Harus memenuhi syarat bentuk normal kedua.
b. Tidak ada ketergantungan fungsi diantara atribut yang bukan kunci primer.
c. Atau setiap atribut yang bukan kunci tidak memiliki depedensi secara transitif terhadap kunci primer. Apabila sudah berada pada tahap ketiiga, dianggap sudah mencapai kondisi normal.
d. Bentuk Tidak Normal
Bentuk ini merupakan ini merupakan kumpulan data yang akan direkam, tidak ada keharusan mengikuti aturan tertentu, dapat saja tidak lengkap atau terduplikasi. Tabel dalam tahap ini terbentuk unnormalized,dengan mencantumkan semua field yang ada.

2. Teknik Relationship
Relationship adalah suatu hubungan antar banyak entity. Relationship set adalah kumpulan relationship dengan type yang sama. Sejumlah entity set dapat berasosiasi dengan entity set yang lain melalui suatu relationship ditujukan dengan mapping cardinalities.
Mapping Cardinality berdasarkan dua entity set ( binary relationship set ) dapat berupa:
1. Satu ke Satu (One to one relationship)
Berarti setiap entitas pada himpunan entitas yang pertama dengan entity yang kedua adalah satu lawan satu.
2. Satu ke banyak (One to many relationship)
Berarti setiap entitas pada himpunan entitas satu dapat berhubungan dengan banyak entitas pada himpunan entitas yang kedua adalahbanyak banding satu atau sebaliknya.
3. Banyak ke banyak (many to many relationship)
Berarti setiap entitas pada himpunan entitas yang satu dapat berhubungan dengan banyak entitas pada himpunan entitas kedua dan demikian juga sebaliknya.
Sebelum berbicara tentang normalisasi pada database, adakalanya kita mengetahui dahulu apa itu database. DataBase (basis data dalam bahasa indonesia) dapat diartikan sebagai kumpulan sejumlah data berupa informasi yang disimpan dengan struktur yang sedemikian rupa sehingga dapat diolah kemudian dengan mudah. Sedangkan untuk membuat suatu database yang harus diperhatikan adalah jenis data;
* Data Master, yaitu data yang sifatnya tidak selalu berubah-ubah. Data master ini digunakan sebagai pendukung di dalam proses input transaksi.
* Data Transaksi, yaitu data yang akan selalu muncul dan berubah. Data transaksi ini selalu bergantung kepada master.
Normalisasi Pada Database,
Yang dimaksud dengan normalisasi pada database adalah proses pernormalan suatu database yang disusun agar menghindari terjadinya redudancy (kemubaziran data). Dalam melakukan normalisasi, ada beberapa tahap yang harus dilakukan,
1. Unnormalized
Pada tahap ini, kita mengambil seluruh data yang ada dan diperlukan dalam database itu sendiri. Misalnya
pada contoh bon faktur di bawah ini,

Kita ambil data-data yang diperlukan pada database nantinya, sperti
* Nama Supplier
* Alamat Supplier
* No. Telp.
* No. Nota
* Tanggal Transaksi
* Kode Barang
* Nama Barang
* Harga
* Quantity
* Total
* Subtotal
* Pemberi
* Penerima

2. Normal Satu
Pada tahap ini, kita bagi seluruh data yang diperlukan menjadi beberapa bagian berdasarkan jenis data tersebut,
Supplier
* Nama Supplier
* Alamat
* No. Telp.
Transaksi
* No. Nota
* Kode Barang
* Tanggal Transaksi
* Nama Barang
* Harga Barang
* Satuan
* Quantity
* Total
* Sub Total


3. Normal Dua
Pada tahap ini, kita bagi berdasarkan jenis dan memberikan primary key pada masing-masing tabel,
Supplier
* Kode Supplier
* Nama Supplier
* Alamat
* No. Telp.
Master Barang
* Kode Barang
* Nama Barang
* Harga
* Satuan
Transaksi
* No. Nota
* Tanggal Transaksi
* Kode Barang
* Nama Barang
* Harga
* Satuan
* Quantity
* Pemberi
* Penerima

4. Normal Tiga
Pada tahap ini, kita bagi menjadi lebih terperinci untuk menghindari terjadinya redudancy,
Supplier
* Tetap
Master Barang
* Tetap
Transaksi
Dibagi menjadi:
Header Transaksi
* No. Nota
* Tanggal Transaksi
* Kode Supplier
* Pemberi
* Penerima
Detail Transaksi
* No. Nota
* Kode Barang
* Quantity


CONTOH STUDY KASUS
PENJUALAN BARANG
Suatu perusahaan software diminta membuatkan basis/data yang akan melayani data-data penjualan barang sebuah toko kecil, toko tersebut diminta agar programnya bisa mengolah data-data penjualan barang disertai rincian atau detail penjualan barang-barang yang dijual.
Software yang akan di gunakan dalam pembuatan database ini adalah dengan Microsoft acces 2003. berikut adalah tabel-tabel yang akan di buat untuk program untuk mengolah data-data Penjualan barang serta serta rincian atau detail penjualan barang yang dijual.

Gambar1. database dengan menggunakan Microsoft acces 2003
Dalam database terdapat juga field-field dan juga kunci primernya unuk setiap tabel yang ada. Kita harus menyertakan tipe data apa yang akan digunakan desesuaikan dengan nama field yang ada.

Berikut ini adalah contoh DB Penjualan Barang dengan Tabel-tabel beserta Penjelasan
- Tabel Anggota
•NoAng
•Nama
•Unit
•Alamat
•Kota
•KodePos
•Telp

- Tabel Barang
•kodebrg
•namabrg
•qty
•Satuan
•hrgpokok

- Tabel DetailJual
•NoFak
•Tanggal
•NoAng

- Tabel FakturJual
•NoFak
•kodebrg
•qry

Teknologi Informasi dan komunikasi (TIK) terus berkembang dengan pesat. Apa yang dapat anda sarankan kepada organisasi anda dalam memilih, menggunakan dan memelihara investasi TIK yang menjamin keberlangsungan, aksebilitas, kemanfaatan serta keamanan Sistem Manajemen Basisdata yang ditawarkan.
Saran saya kepada organisasi dalam memilih, menggunakan dan memelihara investasi TIK yang menjamin keberlangsungan, kemanfaatan serta keamanan Sistem Manajemen Basisdata adalah sebagai berikut :
a. Dalam Pemilihan Sofware database memilih sofware yang opensource, yaitu program yang free atau bebas digunakan oleh siapa saja tanpa harus membeli dan membayar lisensi kepada pembuatnya
b. Software database merupakan database server, yang dapat memungkinkan dapat diakses bersama, atau dapat dihubungkan dengan media internet
c. Software database dapat menyimpan data berkapasitas sangat besar sampai dengan ukuran Gigabyte.
d. Software database memiliki enskripsi password, sehingga tidak semua dapat mengaskesnya.
e. Sofware database yang multi user, artinya database ini tidak hanya digunakan oleh sepihak orang akan tetapi merupakan database yang dapat digunakan oleh banyak pengguna.
f. Software database yang memiliki kecepatan dalam pembuatan tabel maupun peng-update-an tabel
Studi Kasus Student Entrance Test (SET)

A. Data SET

Prototipe bahasa Lingu menggunakan SET debagai studi kasusnya. SET adalah proses seleksi yang dilakukan untuk memasuki perguruan tinggi negeri. Berikut adalah data-data yang digunakan oleh Lingu berdasarkan studi kasus tersebut.

type RegistrationTable = Table
{| ID :: String
; Name :: String
; Sex :: Integer
; Category :: Integer
; StudyProgramme :: Record {| P1,P2,P3 :: String |}
|}

RegistrationTable adalah tabel yang berisi data atau keterangan pribadi dari siswa yang mengikuti tes SET. Datanya terdiri dari nomor identitas (ID), nama, jenis kelamin, kategori, dan program studi yang diambilnya.

type AnswerFormTable = Table
{| ID :: String
; Name :: String
; SheetCode :: String
; Answer :: String
|}

AnswerFormTable adalah tabel yang berisi data jawaban soal-soal yang dikerjakan oleh siswa selama tes SET. Data ini berisi nomor identitas (ID), nama siswa, kode lembar jawaban (SheetCode), dan jawabannya itu sendiri. Untuk prototype ini diasumsikan tiap siswa akan mengisi 3 lembar jawaban yang berbeda sehingga akan terdapat 3 buah AnswerFormTable dengan nama dan ID yang sama namun memiliki SheetCode dan jawaban yang berbeda.

type SolutionTable = Table
{| Answer :: String
|}

SolutionTable adalah tabel yang berisi jawaban dari soal-soal SET. Tabel diatas adalah berdasarkan table di midterm report. Tabel tersebut sangat over-simplify, namun masih dapat digunakan untuk keperluan penjelasan.

type SETdb = Dbase
{| SubmitTab :: AnswerFormTable
; MasterTab :: RegistrationTable
; HealthyAFormTab :: AnswerFormTable
; UnknownAFormTab :: AnswerFormTable
; DoubleAFormTab :: AnswerFormTable
; IncompleteAFormTab :: AnswerFormTable
; SolutionsTab :: SolutionTable
; PassTab :: RegistrationTable
|}

Database Setdb diatas merepresentasikan database dari seluruh kegiatan pelaksanaan SET. SubmitTab adalah tabel jawaban yang dikumpulkan oleh peserta SET. MasterTab adalah data induk dari seluruh siswa yang mengikuti SET. HealthyAFormTab adalah tabel seluruh jawaban yang valid dan sah untuk diperiksa jawabannya. UnknownAFormTAb adalah tabel jawaban-jawaban yang tidak diketahui identitasnya. Kemungkinannya adalah nomor ID yang dituliskan salah atau tidak terbaca dengan benar. DoubleAFormTab adalah tabel dari jawaban yang memiliki id dan SheetCode sama namun mempunyai jawaban berbeda. IncompleteAFormTab adalah tabel dari jawaban yang kelengkapannya kurang. Terdapat 3 buah lembar jawaban dengan SheetCode berbeda yang harus dikerjakan dan dikumpulkan. SolutionsTab adalah tabel yang berisi jawaban dari soal-soal SET. PassTab adalah tabel yang berisi data siswa-siswa yang jawabannya telah dievaluasi dan dinyatakan lolos tes SET.

B. 7 Critical Module

Untuk studi kasus ini kami telah mengidentifikasikan 7 modul kritis yang harus diverifikasi. Modul tersebut adalah :
1. Filter Unknown
2. Filter Double
3. Evaluate
4. Check Safeness
5. Check Fairness
6. Check Completeness
7. Check Names


1. Filter Unknown

Filter ini digunakan untuk menyaring jawaban-jawaban dengan nomor identitasnya tidak terdapat di data induk siswa SET. Berikut adalah pseudocode yang terdapat pada Report #2 RUTI tahun 2003.

Prog Check_UnknownID
( Answer_Form_Table,
Registration_Master_Table,
Unknown_Table,
Answer_Master_Table)

do
{
t1 := Answer_Form_Table;
t2 := Registration_Master_Table;

while ~(t1 = []) do
{
a := head t1;

match := false ;
while ~(t2 = [] AND match = FALSE) do
{
b := head t2;
if a.ID_number = b.ID_number then
{
insert a into Answer_Master_Table;
match := TRUE;
}
else
{
t2 := tail t2;
}
}
if match = FALSE then
{
insert a into Unknown_Master_Table;
}
t1 := tail t1;
}


Pseudocode diatas kemudian direfine lagi untuk menghasilkan kode untuk Lingu seperti tabel di bawah ini. Kode ini diambil dari RUTI Midterm Report 2004.


class SETutility (d::SETdb)

method filterUnknown () :: ()
local
ids,okids :: Table {| ID :: String |}
do
{ ids := findAll s<-d.SubmitTab where T found s.ID ;
insertAll i<-ids, r<-d.MasterTab
where i.ID = r.ID to okids ;
delete i<-ids where i<-okids ;
insertAll s<-d.SubmitTab, i<-ids
where s.ID = i.ID to d.UnknownAFormTab
}
only write d.UnknownAFormTab


Berdasarkan pseudocode diatas, kode LinguHOL yang akan dijalankan diatas HOL theorem prover untuk filter unknown adalah sebagai berikut.



filter_unknown ( SubmitTab : AnswerFormTable set,
MasterTab : RegistrationTable set,
UnknownAFormTab : AnswerFormTable set)
( dummy )
=
let
ids = select SubmitTab (\r. r.ID) (\r. T)
in
let
okids = select MasterTab (\r. r.ID)
(\r. exists ids (\id. id = r.ID))
in
(
delete SubmitTab (\r. exists okids(\t. t = r.ID))
>>
qinsert SubmitTab I (\r. T) UnknownAFormTab
)


Kode diatas adalah representasi LinguHOL dari Lingu yang telah dibuat sebelumnya. Pertama program akan mengambil seluruh ID dari SubmitTab dan menyimpannya pada ids. Program kemudian akan mengambil ID pada MasterTab dimana record yang diambil adalah record yang memiliki ID yang sama dengan ID pada ids. Hal ini dimaksudkan untuk menentukan ID-ID pada SubmitTab yang terdaftar pada MasterTab. Program lalu akan menghapus record pada SubmitTab yang juga terdapat pada okids. Hal ini akan meninggalkan record-record di SubmitTab yang tidak terdaftar pada MasterTab. Akhirnya record-record yang tersisa tersebut akan dimasukkan ke UnknownAFormTab.

Setelah membuat kode dari modul yang diperlukan, selanjutnya adalah membuat spesifikasi yang akan menjaga atau menjamin bahwa perilaku dari modul ini sudah sesuai dengan yang diinginkan. Berikut adalah spesifikasi yang terdapat pada LinguHOL untuk modul filter unknown.


(* pre: *) UnknownAFormTab = {},

(* script: *) filter_unknown (SubmitTab,MasterTab,UnknownAFormTab)
(dummy)

(* post: *) forall UnknownAFormTab
(\r. ~(exists MasterTab (\r'. r.ID = r'.ID)))


Terdapat 3 bagian dari spesifikasi ini yaitu precondition, proses, dan postcondition. Precondition dari modul ini adalah bahwa sebelum dilakukan proses, tabel UnknownAFormTab harus kosong. Di bagian proses program spesifikasi akan menjalankan filter unknown dengan parameter-parameter yang sesuai. Parameter dummy untuk saat ini tidak akan digunakan. Postcondition yang diharapkan setelah eksekusi proses adalah bahwa semua record pada UnknownAFormTab tidak akan terdaftar pada MasterTab.

Spesifikasi tersebut diatas kemudian akan coba dipecahkan dengan theorem prover. Kode untuk proof dari filter unknown adalah sebagai berikut.


val cert_unk = certify (spec_unk,
NORMALIZE_TAC [I_THM]
THEN PROVE_TAC []) ;


Proof diatas menggnakan taktik normalisasi dengan teorema identitas lalu menggunakan teknik proving otomatis yang terdapat pada HOL.


2. Filter Double
Filter ini digunakan untuk menyaring jawaban-jawaban yang mengalami duplikasi. Terdapat kemungkinan bahwa jawaban-jawaban yang masuk memiliki nomor ID yang salah sehingga menyerupai nomor ID siswa lain. Berikut adalah algoritma yang diambil dari Report #2 RUTI tahun 2003.


Prog Check_DoubleID
( Answer_Form_Table,
Double_Table,
Answer_Master_Table )

do
{
t1 := Answer_Form_Table ;
t2 := Answer_Master_Table ;

while ~(t1 = []) do
{
a:= head t1;
while ~(t2 = []) do
{
b := head t2;
if a.ID_number = b.ID_number then
{
insert a into Double_Table ;
return ;
}
else
t2 := tail t2 ;
}
t1 := tail t1;
}
}


Pseudocode diatas kemudian dikembangkan lagi sehingga menjadi bahasa Lingu yang diinginkan. Kode Lingu yang dihasilkan terdapat pada Midterm Report RUTI tahun 2004. Kode tersebut adalah sebagai berikut :


class SETutility (d::SETdb)

method filterDouble () :: ()
local
ids :: Table {| ID :: String |}
do
{ ids := findAll s<-d.SubmitTab, t<-d.SubmitTab
where (s.ID = r.ID) /\ s<>r
found s.ID ;
insertAll s<-d.SubmitTab, i<-ids
where s.ID = i.ID
to d.DoubleAFormTab
}
only write d.DoubleAFormTab


Berdasarkan pseudocode diatas, kode LinguHOL untuk filter unknown adalah sebagai berikut.


filter_double ( SubmitTab : AnswerFormTable set,
DoubleAFormTab : AnswerFormTable set)
( dummy )
=
let
doubleids = select SubmitTab I (\r. exists
SubmitTab (\r'. (r.ID = r'.ID) /\ ~(r = r')) )
in
qinsert doubleids I (\r. T) DoubleAFormTab


Kode diatas adalah bentuk LinguHOL dari kode Lingu untuk filter double diatas. Fungsi filter_double ini hanya mengambil 2 buah parameter yaitu SubmitTab dan DoubleAFormTab. Pertama, program akan mengambil record-record yang memiliki ID sama namun isinya tidak serupa dari SubmitTab. Ini dilakukan karena terdapat kemungkinan kesalahan penulisan ID oleh peserta SET yang mengakibatkan adanya nomor ID ganda. Record-record yang telah berhasil diambil dari SubmitTab itu kemudian akan dimasukkan kedalam tabel sendiri yaitu tabel DoubleAFormTab.

Setelah membuat kode dari modul yang diperlukan, selanjutnya adalah membuat spesifikasi yang akan menjaga atau menjamin bahwa perilaku dari modul ini sudah sesuai dengan yang diinginkan. Berikut adalah spesifikasi yang terdapat pada LinguHOL untuk modul filter double.



(* pre: *) DoubleAFormTab = {},

(* script: *) filter_double(SubmitTab,DoubleAFormTab)(dummy),

(* post: *) forall DoubleAFormTab (\r. exists SubmitTab
(\t. (r.ID = t.ID) ==> ~(r = t)))
/\
forall SubmitTab (\r. forall SubmitTab
(\s. (r.ID = s.ID) /\ ~(r = s)
==>
exists DoubleAFormTab (\t. exists DoubleAFormTab
(\u. (r = t) /\ (u = s)))))


Precondition yang harus dipenuhi sebelum fungsi filter double dilakukan adalah tabel DoubleAFormTab harus kosong. Sedangkan postcondition yang harus dipenuhi setelah eksekusi fungsi ini adalah bahwa jika di tabel DoubleAFormTab dan SubmitTab terdapat record yang memiliki ID sama namun merupakan record yang berbeda, dan pada SubmitTab sendiri juga terdapat record yang Idnya sama namun merupakan record yang berbeda, maka dipastikan akan terdapat record yang sama dalam DoubleAFormTab.

Spesifikasi tersebut diatas kemudian akan coba dipecahkan dengan theorem prover. Kode untuk proof dari filter unknown adalah sebagai berikut.


val cert_dbl = certify (spec_dbl,
NORMALIZE_TAC [I_THM]
THEN PROVE_TAC []) ;


Proof diatas menggnakan taktik normalisasi dengan teorema identitas lalu menggunakan teknik proving otomatis yang terdapat pada HOL.
3. Evaluate
Fungsi ini digunakan untuk memeriksa kebenaran jawaban dari siswa dan sekaligus menentukan apakah siswa yang bersangkutan lolos ujian.


class SETutility (d::SETdb)

method evaluate () :: ()
...
only write d.PassTab


Kode Lingu diatas merupakan kerangka dari fungsi evaluate yang bertanggung jawab untuk menilai lembar jawaban dan menentukan kelulusan peserta SET. Algoritma sesungguhnya belum dimasukkan ke dalam kode ini. Setelah diubah menjadi bentuk LinguHOL, kode yang didapat adalah sebagai berikut.



evaluate ( HealthyAFormTab : AnswerFormTable set,
SolutionsTab : SolutionTable set,
MasterTab : RegistrationTable set,
PassTab : RegistrationTable set
)
( dummy )
=
qinsert MasterTab I (\r. T) PassTab



Seperti terlihat diatas, kode LinguHOL ini tidak melakukan apapun kecuali memasukkan seluruh isi MasterTab kedalam PassTab. Hal ini berarti untuk contoh studi kasus ini seluruh peserta akan dinyatakan lulus. Untuk pengembangan selanjutnya akan dimasukkan algoritma seleksi kelulusan peserta sehingga akan lebih menggambarkan kasus yang sesungguhnya.


(* pre: *) PassTab = {},

(* script: *) evaluate(HeathyAFormTab,SolutionsTab,MasterTab,PassTab)
(dummy),

(* post: *) T


Precondition dari fungsi evaluate ini adalah bahwa PassTab tidak berisi apapun. Sedangkan untuk postconditionnya saat ini tidak berisi constraint apapun. Constraint ini akan berubah sesuai dengan algoritma penilaian yang nantinya akan ditambahkan.

Spesifikasi tersebut diatas kemudian akan coba dipecahkan dengan theorem prover. Kode untuk proof dari fungsi evaluate adalah sebagai berikut.



val cert_eval = certify (spec_eval,
NORMALIZE_TAC [I_THM]);


Proof diatas menggunakan taktik normalisasi dengan teorema identitas lalu menggunakan teknik proving otomatis yang terdapat pada HOL.
4. Check Safeness
Fungsi ini digunakan untuk memeriksa dan menjamin bahwa fungsi evaluate tidak akan secara ilegal meloloskan ujian seseorang yang tidak mengikuti ujian atau tidak terdaftar di data induk.

validation safe1(i::Int) :: Bool
local
do
{ call evaluate() ;
if 0<=i /\ i < #d.PassTab
then r := T
else { id := d.PassTab!!i ;
r := find r<-d.MasterTab
where r.ID = id
found T
otherwise F ;
r := r /\ find r<-d.HealthyFormTab
where r.ID = id
found T
otherwise F } ;
}
return r
pre T
post return = T


Kode validasi diatas akan memanggil fungsi evaluate untuk menilai lembar jawaban yang telah dikumpulkan. Setelah semua lembar jawaban dievaluasi maka tabel PassTab akan terisi record lembar jawaban yang lolos SET. Record-record pada PassTab ini kemudian diperiksa ulang keabsahannya dengan cara mencocokkan ID pada record tersebut dengan yang terdapat pada MasterTab dan HealthyAFormTab. Jika ID benar terdapat pada kedua tabel MasterTab dan HealthyAFormTab maka record jawaban yang lolos tersebut dinyatakan legal / safe.

Kode Lingu diatas kemudian diterjemahkan menjadi kode LinguHOL pada tabel dibawah.

safe ( HealthyAFormTab : AnswerFormTable set,
SolutionsTab : SolutionTable set,
MasterTab : RegistrationTable set,
PassTab : RegistrationTable set,
val : bool
)
(dummy)
=
call ( evaluate (HealthyAFormTab, SolutionsTab,
MasterTab, PassTab) (dummy))
>>
let val1 = forall PassTab
(\r. (exists MasterTab (\t. r.ID = t.ID))
/\
(exists HealthyAFormTab (\y. r.ID = y.ID)))
in
val ::= val1


Sesuai dengan kode untuk fungsi safe, program ini pertama kali akan memanggil fungsi evaluate untuk menentukan lembar jawaban yang lolos. Kemudian program akan memeriksa apakah semua record yang lolos terdapat di tabel MasterTab dan HealthyAFormTab. Nilai kebenarannya akan dimasukkan ke variabel val dan dikembalikan untuk dicocokkan dengan spesifikasi fungsi ini.



(* pre: *) (PassTab = {}) /\ (val = F),

(* script: *) safe(HealthyAFormTab,SolutionsTab,MasterTab,
PassTab,val)
(dummy),

(* post: *) val =
(forall PassTab
(\r. exists MasterTab (\t. r.ID = t.ID)
/\
exists HealthyAFormTab (\y. r.ID = y.ID)))


Precondition yang diminta untuk fungsi ini adalah tabel PassTab tidak berisi record apapun dan nilai dari variabel val adalah false. Postcondition yang diminta setelah eksekusi fungsi adalah bahwa nilai val adalah benar jika semua record pada PassTab terdapat pada tabel MasterTab dan HealthyAFormTab.

Spesifikasi tersebut diatas kemudian akan coba dipecahkan dengan theorem prover. Kode untuk proof dari fungsi safe adalah sebagai berikut.


val cert_safe = certify (spec_safe,
NORMALIZE_TAC [I_THM]
THEN PROVE_TAC []) ;


Proof diatas menggunakan taktik normalisasi dengan teorema identitas lalu menggunakan teknik proving otomatis yang terdapat pada HOL.

5. Check Fairness

Fungsi ini digunakan untuk memeriksa bahwa jenis kelamin tidak memegang peranan apapun dalam menentukan lolos atau tidaknya seorang peserta SET.



validation fair (sex::String) :: Bool
do
{ evaluate() ;
result0 := d.passTab ;
mutate r<-d.MasterTab do r.Sex := sex ;
evaluate()
}
return result0 = d.passTab
pre T
post return = T


Kode Lingu dari fungsi fair diatas akan memanggil fungsi evaluate untuk menghasilkan lembar jawaban yang lolos dari SET. Hasil dari fungsi evaluate ini akan disimpan dalam result0 sebagai acuan untuk verifikasi selanjutnya. Untuk memeriksa aspek fairness, fungsi ini akan merubah seluruh jenis kelamin pada MasterTab. Perubahan ini ditentukan oleh parameter sex. Setelah perubahan terjadi, fungsi ini akan memanggil fungsi evaluate dengan parameter MasterTab yang telah diubah jenis kelaminnya. Hasil dari fungsi evaluate ini kemudian akan dikomparasikan dengan hasil sebelumnya pada variabel result0. Jika hasilnya adalah sama, maka fungsi evaluate tidak terpengaruh oleh variabel jenis kelamin. Apabila hasilnya tidak sama, maka fungsi evaluate ini terbukti tidak memenuhi aspek fairness dalam penilaian lembar jawaban.


fair ( HealthyAFormTab : AnswerFormTable set,
SolutionsTab : SolutionTable set,
MasterTab : RegistrationTable set,
PassTab : RegistrationTable set,
PassTab2 : RegistrationTable set,
sex : int,
valid : bool
)
( dummy )
=
call ( evaluate (HealthyAFormTab, SolutionsTab, MasterTab,
PassTab) (dummy))
>>
update MasterTab (\r. r with Sex := sex ) (\c. ~(c.Sex = sex))
>>
call (evaluate (HealthyAFormTab, SolutionsTab, MasterTab,
PassTab2) (dummy))
>>
if PassTab = PassTab2
then valid ::= T else valid ::= F


Kode LinguHOL diatas merupakan terjemahan dari fungsi fairness pada Lingu. Program akan memanggil fungsi evaluate dan menyimpan record jawaban yang lolos di PassTab. Program kemudian akan merubah semua jenis kelamin pada MasterTab menjadi jenis kelamin pada parameter sex. MasterTab yang telah berubah ini kemudian akan dimasukkan kedalam fungsi evaluate. Hasil dari pemanggilan evaluate yang kedua akan dimasukkan ke PassTab2. Program ini kemudian akan mengembalikan nilai dari komparasi PassTab dan PassTab2.


(* pre: *) (PassTab = {}) /\ (PassTab2 = {}),

(* script: *) fair(HealthyAFormTab,SolutionsTab,MasterTab,
PassTab,PassTab2,val)(dummy),

(* post: *) if val then PassTab = PassTab2
else ~(PassTab = PassTab2)


Precondition dari fungsi fairness adalah PassTab dan PassTab2 tidak memiliki elemen apapun. Setelah eksekusi dari fungsi, postcondition yang diharapkan adalah bahwa jika variabel val bernilai true maka PassTab harus sama dengan PassTab2, namun jika tidak maka PassTab harus berbeda dengan PassTab2.

Spesifikasi tersebut diatas kemudian akan coba dipecahkan dengan theorem prover. Kode untuk proof dari fungsi fair adalah sebagai berikut.

val cert_fair = certify (spec_fair,
NORMALIZE_TAC [I_THM]
THEN PROVE_TAC []) ;


Proof diatas menggunakan taktik normalisasi dengan teorema identitas lalu menggunakan teknik proving otomatis yang terdapat pada HOL.


6. Check Completeness

Fungsi ini digunakan untuk memeriksa kelengkapan lembar jawaban dari peserta SET. Terdapat 3 buah lembar jawaban yang harus dikumpulkan dan dijawab oleh peserta SET. Berikut adalah algoritma yang terdapat pada Report #2 RUTI tahun 2003.


Prog Check_Completness_of_Answer_Form
( Answer_Master_Table,
Registration_Master_Table,
Uncomplete_Answer_Table )

do
{
t1 := Registration_Master_Table ;
t2 := Answer_Master_Table ;

c1 := select all from Answer_Master_Table where time = Time_1 ;
c2 := select all from Answer_Master_Table where time = Time_2 ;
c3 := select all from Answer_Master_Table where time = Time_3 ;

while ~(t1 = []) do
{
a := head t1 ;
if a.category = 1 then
{
if ~(occurs(a,c1) AND occurs (a,c2))
{
b := select all from c1 where ID_number = a.ID_number ;
c := select all from c2 where ID_number = a.ID_number ;

insert b into Uncomplete_Answer_Table ;
insert c into Uncomplete_Answer_Table ;

delete b from t2 ;
delete c from t2 ;

}
}
else if a.category = 2 then
{
if ~(occurs(a,c1) AND occurs (a,c3))
{
b := select all from c1 where ID_number = a.ID_number ;
c := select all from c3 where ID_number = a.ID_number ;

insert b into Uncomplete_Answer_Table ;
insert c into Uncomplete_Answer_Table ;

delete b from t2 ;
delete c from t2 ;

}
}
else
{
if ~(occurs (a,c1) AND occurs (a,c2) AND occurs (a,c3)) then
{
b := select all from c1 where ID_number = a.ID_number ;
c := select all from c2 where ID_number = a.ID_number ;
d := select all from c3 where ID_number = a.ID_number ;

insert b into Uncomplete_Answer_Table ;
insert c into Uncomplete_Answer_Table ;
insert d into Uncomplete_Answer_Table ;

delete b from t2 ;
delete c from t2 ;
delete d from t2 ;
}
}
t1 := tail t1 ;
}
}


Prog occurs (a, t)

do
{
while ~( t = [] )
{
b := head t ;
if a.ID_number = b.ID_number then
{
return TRUE ;
exit ;
}
else
t = tail t ;
}
if t = [] return FALSE ;
}



Pengembangan algoritma diatas lebih lanjut diperlukan untuk menerjemahkannya ke bahasa Lingu. Berikut adalah kode untuk LinguHOL.


CheckCompleteness (HealthyAFormTab : AnswerFormTable set,
MasterTab : RegistrationTable set,
IncompleteAFormTab : AnswerFormTable set)
(dummy)
=
let
cat1_participants = select MasterTab (\r. r.ID) (\r. T)
in
let
c1 = select HealthyAFormTab
I
(\r. (r.SheetCode = "1") /\
exists cat1_participants (\id. id = r.ID))
and
c2 = select HealthyAFormTab
I
(\r. (r.SheetCode = "2") /\
exists cat1_participants (\id. id = r.ID))

and
c3 = select HealthyAFormTab
I
(\r. (r.SheetCode = "3") /\
exists cat1_participants (\id. id = r.ID))

in
(qinsert c1
I
(\r. forall c2 (\r'. ~(r.ID = r'.ID)))
IncompleteAFormTab
>>
qinsert c1
I
(\r. forall c3 (\r'. ~(r.ID = r'.ID)))
IncompleteAFormTab
>>
qinsert c2
I
(\r. forall c1 (\r'. ~(r.ID = r'.ID)))
IncompleteAFormTab
>>
qinsert c2
I
(\r. forall c3 (\r'. ~(r.ID = r'.ID)))
IncompleteAFormTab
>>
qinsert c3
I
(\r. forall c1 (\r'. ~(r.ID = r'.ID)))
IncompleteAFormTab
>>
qinsert c3
I
(\r. forall c2 (\r'. ~(r.ID = r'.ID)))
IncompleteAFormTab


Kode diatas pertama kali akan mengambil seluruh ID peserta SET dari MasterTab dan disimpan pada cat1_participants. Untuk kepentingan presentasi ini diasumsikan ada 3 buah sheetcode yang harus diisi oleh peserta yaitu sheetcode 1,2, dan 3. Fungsi ini kemudian akan mengambil seluruh lembar jawaban dengan sheetcode 1 dari peserta yang ID-nya terdaftar di MasterTab dan disimpan di variabel c1. Demikian juga untuk sheetcode 2 dan 3, data lembar jawaban tersebut akan disimpan di c2 dan c3. Proses pemeriksaan dilakukan untuk semua record pada c1,c2, dan c3. Untuk c1, seluruh record pada c1 diperiksa silang dengan record pada c2 dan c3. Apabila terdapat ID dari peserta pada c1 yang tidak ditemukan pada c2 atau c3, maka record tersebut akan dimasukkan ke tabel IncompleteAFormTab. Proses yang sama juga dilakukan pada c2 dan c3.


(* pre: *) IncompleteAFormTab = {},

(* script: *) CheckCompleteness( HealthyAFormTab,MasterTab,
IncompleteAFormTab)
( dummy ),

(* post: *) forall IncompleteAFormTab
(\r. ~(exists HealthyAFormTab (\r'. (r'.ID = r.ID) /\ (r'.SheetCode = "1"))
/\
exists HealthyAFormTab
(\r'. (r'.ID = r.ID) /\ (r'.SheetCode = "2"))
/\
exists HealthyAFormTab
(\r'. (r'.ID = r.ID) /\ (r'.SheetCode = "3"))
))


Precondition dari fungsi ini adalah bahwa tabel IncompleteAFormTab tidak memiliki elemen apapubn sebelumnya. Kemudian postcondition yang diharapkan setelah eksekusi adalah bahwa untuk semua record di IncompleteAFormTab, maka peserta dari record tersebut dipastikan akan tidak memiliki lembar jawaban dengan sheetcode yang lengkap.

Spesifikasi tersebut diatas kemudian akan coba dipecahkan dengan theorem prover. Kode untuk proof dari fungsi check completness adalah sebagai berikut.


val cert_comp = certify (spec_comp,
NORMALIZE_TAC [I_THM]
THEN PROVE_TAC []) ;


Proof diatas menggunakan taktik normalisasi dengan teorema identitas lalu menggunakan teknik proving otomatis yang terdapat pada HOL.

7. Check Names

Fungsi ini digunakan untuk memeriksa apakah ada peserta yang memiliki nomor identitas sama, namun memiliki nama yang berbeda pada lembar jawaban dan data induk. Hal ini untuk mencegah kemungkinan sebuah lembar jawaban dikerjakan oleh orang lain yang memakai nomor identitas seorang peserta. Berikut adalah algoritma yang diambil dari Report #2 RUTI tahun 2003.


Prog Check_Names
( Answer_Master_Table,
Registration_Master_Table,
Unmatch_Name_Table )

do
{
t1 := Registration_Master_Table ;

c1 := select all from Answer_Master_Table where time = Time_1 ;
c2 := select all from Answer_Master_Table where time = Time_2 ;
c3 := select all from Answer_Master_Table where time = Time_3 ;

while ~( t1 = []) do
{
a := head t1 ;
if a.category = 1 then
{
name1 := select name from c1 where ID_number = a.ID_number ;
name2 := select name from c2 where ID_number = a.ID_number ;

if Not_equal3 (a.name, name1, name2) then
{
insert (a.ID_number, a.name,name1,name2) into
Unmatch_Name_Table;
}
}
else if a.category = 2 then
{
name1 := select name from c1 where ID_number = a.ID_number ;
name2 := select name from c3 where ID_number = a.ID_number ;

if Not_equal3 (a.name, name1, name2) then
{
insert (a.ID_number, a.name,name1,name2) into
Unmatch_Name_Table;
}
}
else if a.category = 3 then
{
name1 := select name from c1 where ID_number = a.ID_number ;
name2 := select name from c2 where ID_number = a.ID_number ;
name3 := select name from c3 where ID_number = a.ID_number ;

if Not_equal4 (a.name, name1, name2, name3) then
{
insert (a.ID_number, a.name,name1,name2,name3) into
Unmatch_Name_Table;
}
}
t1 := tail t1 ;
}
}

Prog Not_equal3 (a,b,c)
do
{
if (~(a=b) OR ~(a=c) OR ~(b=c)) then
{
return TRUE ;
}
else
return FALSE :
}

Prog Not_equal4 (a,b,c,d)
do
{
if (~(a=b) OR ~(a=c) OR ~(a=d) OR ~(b=c) OR ~(b=d) OR ~(c=d)) then
{
return TRUE ;
}
else
return FALSE :
}

Normalisasi

TUGAS REKAYASA PERANGKAT LUNAK

Nama : Lilis Maisyaroh

NIM : 2106005

Jurusan : MI/D3

Proses normalisasi pertama kali diperkenalkan oleh E.F.Codd pada tahun 1972. Normalisasi sering dilakukan sebagai suatu uji coba pada suatu relasi secara berkelanjutan untuk menentukan apakah relasi tersebut sudah baik atau masih melanggar aturan-aturan standar yang diperlakukan pada suatu relasi yang normal (sudah dapat dilakukan proses insert, update, delete, dan modify pada satu atau beberapa atribut tanpa mempengaruhi integritas data dalam relasi tersebut).

Proses normalisasi merupakan metode yang formal/standar dalam mengidentifikasi dasar relasi bagi primary keynya (atau candidate key dalam kasus BCNF), dan dependensi fungsional diantara atribut-atribut dari relasi tersebut. Normalisasi akan membantu perancang basis data dengan menyediakan suatu uji coba yang berurut yang dapat diimplementasikan pada hubungnan individualshingga skema relasi dapat di normalisasi ke dalam bentuk yang lebih spesifik untuk menghindari terjadinya error atau inkonsistansi data, bila dilakuan update tehadap relasi tersebut dengan Abnomaly.

1.1 BEBERAPA DEFINISI NORMALISASI

• Normalisasi adalah suatu proses memperbaiki / membangun dengan model data relasional, dan secara umum lebih tepat dikoneksikan dengan model data logika.

• Normalisasi adalah proses pengelompokan data ke dalam bentuk tabel atau relasi atau file untuk menyatakan entitas dan hubungan mereka sehingga terwujud satu bentuk database yang mudah untuk dimodifikasi.

• Normalisasi dapat berguna dalam menjawab 2 pertanyaan mendasar yaitu: “apa yang dimaksud dengan desain database logical?” dan “apa yang dimaksud dengan desain database fisikal yang baik? What is phisical good logical database design?”.

• Normalisasi adalah suatu proses untuk mengidentifikasi “tabel” kelompok atribut yang memiliki ketergantungan yang sangat tinggi antara satu atribut dengan atrubut lainnya.

• Normalisasi bisa disebut jga sebagai proses pengelompokan atribut-atribut dari suatu relasi sehingga membentuk WELL STRUCTURED RELATION

WELL STRUCTURED RELATION adalah sebuah relasi yang jumlah kerangkapan datanya sedikit (Minimum Amount Of Redundancy), serta memberikan kemungkinan bagi used untuk melakukan INSERT, DELETE, MODIFY, terhadap baris-baris data pada relasi tersebut, yang tidak berakibat terjadinya ERROR atau INKONSISTENSI DATA, yang disebabkan oleh operasi-operasi tersebut.

1.2 Model Perancangan Database

Perancangan database dalam penekanan tinjauannya dilakukan pada struktur data dan relasi antar file. Dua Teknik pemodelan perancangan database diantaranya adalah sebagi berikut :

1. Teknik Normalisasi

Yaitu suatu file yang terdiri dari beberapa grup elemen yang berulang – ulang perlu organisaikan kembali. Proses untuk mengorganisaikan file untuk menghilangkan grup elemen yang berulang – ulang ini disebut dengan normalisasi (normalization). Menurut Chris Gane dab Tris Sarson 1979.

Normalisasi juga banyak dilakukan dalam merubah bentuk database dari struktur pohon atau struktur jaringan menjadi truktur hubungan. Konsep dan teknik normalisasi ini dikenalkan oleh Dr.E.F Codd di papernya. Pada tahun 1972 E.F Codd dalam papernya ini mendefinisikan struktur data yang baru, yaitu yang disebut dengan struktur data hubungan (relational data structure).

Tujuan dari normalisasi adalah untuk menghilangkan kumpulan relasi dari insertion, update, dan deletion depentdency yang tidak diharapkan. Aturan normalisasi merupakan suatu aturan yang dikenal pada relasi – relasi dalam basis data serta dipenuhi oleh relasi pada setiap level normalisasi. Beberapa level yang digunakan pada normalisasi yaitu:

a. Bentuk Normal Pertama (First Normal Form Relation)

Bentuk normal pertama biasanya pada sebuah table yang belum normal.Syarat yang harus dipenuhi pada normal pertama jika nilai dari satu atribut dibuat dalam bentuk table yang sederhana dan atribut bernilai tunggal.

b. Bentuk Normal Kedua (Second Normal Form Relation )

Bentuk normal kedua didefinisikan berdasarkan dependensi fungsional. Dengan tujuan menghilangkan redundasi data. Syarat harus dipenuhi dalam normalisasi kedua adalah:

a. Harus memenuhi syarat bentuk normal pertama.

b. Seluruh atribut yang bukan kunci primer, memiliki dependensi sepenuhnya terhadap kunci primer.

Bentuk normal kedua mensyaratkan setiap atribut tergantung pada kunci primer, hal ini pertama yabg harus dilakukan adalah mencari kunci pada table tersebut.

c. Bentuk Normal Ketiga (Third Normal Form Relation)

Suatu relasi memenuhi norma ketiga, jika memenuhi syarat sebagai berikut:

a. Harus memenuhi syarat bentuk normal kedua.

b. Tidak ada ketergantungan fungsi diantara atribut yang bukan kunci primer.

c. Atau setiap atribut yang bukan kunci tidak memiliki depedensi secara transitif terhadap kunci primer. Apabila sudah berada pada tahap ketiiga, dianggap sudah mencapai kondisi normal.

d. Bentuk Tidak Normal

Bentuk ini merupakan ini merupakan kumpulan data yang akan direkam, tidak ada keharusan mengikuti aturan tertentu, dapat saja tidak lengkap atau terduplikasi. Tabel dalam tahap ini terbentuk unnormalized,dengan mencantumkan semua field yang ada.

2. Teknik Relationship

Relationship adalah suatu hubungan antar banyak entity. Relationship set adalah kumpulan relationship dengan type yang sama. Sejumlah entity set dapat berasosiasi dengan entity set yang lain melalui suatu relationship ditujukan dengan mapping cardinalities.

Mapping Cardinality berdasarkan dua entity set ( binary relationship set ) dapat berupa:

1. Satu ke Satu (One to one relationship)

Berarti setiap entitas pada himpunan entitas yang pertama dengan entity yang kedua adalah satu lawan satu.

2. Satu ke banyak (One to many relationship)

Berarti setiap entitas pada himpunan entitas satu dapat berhubungan dengan banyak entitas pada himpunan entitas yang kedua adalahbanyak banding satu atau sebaliknya.

3. Banyak ke banyak (many to many relationship)

Berarti setiap entitas pada himpunan entitas yang satu dapat berhubungan dengan banyak entitas pada himpunan entitas kedua dan demikian juga sebaliknya.

Sebelum berbicara tentang normalisasi pada database, adakalanya kita mengetahui dahulu apa itu database. DataBase (basis data dalam bahasa indonesia) dapat diartikan sebagai kumpulan sejumlah data berupa informasi yang disimpan dengan struktur yang sedemikian rupa sehingga dapat diolah kemudian dengan mudah. Sedangkan untuk membuat suatu database yang harus diperhatikan adalah jenis data;

* Data Master, yaitu data yang sifatnya tidak selalu berubah-ubah. Data master ini digunakan sebagai pendukung di dalam proses input transaksi.

* Data Transaksi, yaitu data yang akan selalu muncul dan berubah. Data transaksi ini selalu bergantung kepada master.

Normalisasi Pada Database,

Yang dimaksud dengan normalisasi pada database adalah proses pernormalan suatu database yang disusun agar menghindari terjadinya redudancy (kemubaziran data). Dalam melakukan normalisasi, ada beberapa tahap yang harus dilakukan,

1. Unnormalized

Pada tahap ini, kita mengambil seluruh data yang ada dan diperlukan dalam database itu sendiri. Misalnya
pada contoh bon faktur di bawah ini,

Kita ambil data-data yang diperlukan pada database nantinya, sperti
* Nama Supplier
* Alamat Supplier
* No. Telp.
* No. Nota
* Tanggal Transaksi
* Kode Barang
* Nama Barang
* Harga
* Quantity
* Total
* Subtotal
* Pemberi
* Penerima

2. Normal Satu

Pada tahap ini, kita bagi seluruh data yang diperlukan menjadi beberapa bagian berdasarkan jenis data tersebut,

Supplier
* Nama Supplier
* Alamat
* No. Telp.

Transaksi
* No. Nota
* Kode Barang
* Tanggal Transaksi
* Nama Barang
* Harga Barang
* Satuan
* Quantity
* Total
* Sub Total

3. Normal Dua

Pada tahap ini, kita bagi berdasarkan jenis dan memberikan primary key pada masing-masing tabel,

Supplier
* Kode Supplier
* Nama Supplier
* Alamat
* No. Telp.

Master Barang
* Kode Barang
* Nama Barang
* Harga
* Satuan

Transaksi
* No. Nota
* Tanggal Transaksi
* Kode Barang
* Nama Barang
* Harga
* Satuan
* Quantity
* Pemberi
* Penerima

4. Normal Tiga

Pada tahap ini, kita bagi menjadi lebih terperinci untuk menghindari terjadinya redudancy,

Supplier
* Tetap

Master Barang
* Tetap

Transaksi
Dibagi menjadi:
Header Transaksi
* No. Nota
* Tanggal Transaksi
* Kode Supplier
* Pemberi
* Penerima

Detail Transaksi
* No. Nota
* Kode Barang
* Quantity