Nickyoktarina's Weblog

Contoh Tahap-tahap Normalisasi

nickyoktarina — Wed, 07 Jan 2009 10:22:50 +0000

Tahap-tahap Normalisasi

nickyoktarina — Wed, 07 Jan 2009 10:13:02 +0000

Normalisasi database biasanya jarang dilakukan dalam database skala kecil, dan dianggap tidak diperlukan pada penggunaan personal. Namun seiring dengan berkembangnya informasi yang dikandung dalam sebuah database, proses normalisasi akan sangat membantu dalam menghemat ruang yang digunakan oleh setiap tabel di dalamnya, sekaligus mempercepat proses permintaan data. Proses normalisasi model data dapat diringkas sebagai berikut:

Menemukan entitas-entitas utama dalam model data.
Menemukan hubungan antara setiap entitas.
Menentukan atribut yang dimiliki masing-masing entitas.

Normalisasi model data dilakukan dengan mengikuti langkah-langkah sederhana, mengubahnya agar memenuhi apa yang disebut sebagai bentuk normal pertama, kedua, lalu ketiga secara berturutan. Langkah-Langkah Normalisasi :

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.

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.

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.

Contoh Kasus :

TOKO ABC

No. Faktur :
Tanggal : Kepada :

No.	Nama	Jumlah	Harga	Total

			Total Bayar
			Diskon
			Jumlah Bayar

Petugas : …………………………..

TAHAP-TAHAP NORMALISASI DATA

A. BASIS DATA BELUM TERNORMALISASI

Berdasarkan faktur di atas, maka gambaran database yang belum ternormalisasi adalah sebagai berikut :

1. Tabel yang memiliki field dengan banyak data / tidak tunggal

No_Faktur	Tanggal	Nama_pelanggan	Daftar_Belanja
05070101	29/05/07	Imelda	Bedak, Beras, Minyak Tanah, Buku
05070102	29/05/07	Bowo	Baby Oil, Garam, Gula, Pensil
05070103	30/05/07	Erlina	Sikat gigi, Sabun, Odol, Sampo
06070001	01/06/07	Dayat	Beras

Tabel dengan field yang mengalami repeating groups

No_Faktur	Tanggal	Pelanggan	Belanja 1	Harga1	Belanja2	Harga2	Belanja3	Harga3	Belanja4	Harga4
05070101	29/05/07	Imelda	Bedak	1500	Beras	10000	Minyak Tanah	3500	Buku	2000
05070102	29/05/07	Bowo	Baby Oil	5600	Garam	2500	Gula	4000	Pensil	1500
05070103	30/05/07	Erlina	Sikat gigi	12000	Sabun	2500	Odol	13000	Sampo	16000
06070001	01/06/07	Dayat	Beras	25000

Walaupun susunan tabel data di atas belum menampilkan keseluruhan atribut dari bentuk faktur yang tertera pada masalahini, tetapi ia telah dapat menggambarkan bentuk basis data yang belum ternormalisasi, karena suatu relasi memenuhi 1-NF jika dan hanya jika setiap atribut hanya memiliki nilai tunggal dalam satu baris / record dan tidak mengalami repeating groups.

B. FIRST NORMAL FORM ( 1NF )

Implementasi 1-NF dari table data yang belum ternormalisasi di atas adalah dengan cara mengeliminasi keberadaan repeating groups dan dekomposisi relasi menjadi dua atau lebih dengan syarat “tidak boleh ada informasi yang hilang karena proses dekomposisi” Adapun caranya adalah :

1. Membuat 3 tabel yang memiliki fungsi sebagai berikut :

TBFaktur, berfungsi untuk menyediakan atribut-atribut yang bersifat atomic dari tiap nomor faktur (ID_Faktur), seperti : Tanggal, Nama_Pelanggan, Total_Bayar, Diskon dan Nama_Petugas
TBProduk, berfungsi untuk menyediakan atribut-atribut yang berulang atau tidak bernilai tunggal pada tiap nomor faktur (ID_Faktur), seperti : Nama_Barang dan harga
TBTransaksiDetail, berfungsi sebagai penghubung antara nomor faktur (ID_Faktur) dengan kode barang (ID_Barang) agar proses dekomposisi tidak menyebabkan kerusakan informasi.

2. Menentukan type data dari tiap atribut dan membuat digram relasional

3. Pada table TBTransaksiDetail terdapat atribut “Harga” yang berfungsi untuk menyimpan harga per transaksi, sedangkan atribut “Harga_Default” yang terdapat pada table TBProduk adalah atribut yang berfungsi untuk menyimpan harga barang terbaru dari tiap jenis barang.Hal ini berguna untuk mengantisipasi adanya perubahan harga dari waktu ke waktu.

4. Primary key yang digunakan pada TBTransaksiDetail adalah “ID_Transaksi”. Atribut kunci tersebut merupakan candidate key yang dibentuk dari superkey hasil penggabungan 2 atribut yaitu : ID_Faktur dan ID_Barang

C. SECOND NORMAL FORM ( 2NF )

Suatu relasi berada dalam 2^nd normal form jika dan hanya jika:

o Berada dalam bentuk first normal form (1-NF)

o Semua atribut bukan kunci memiliki dependensi sepenuhnya dengan kunci primer (Primary Key)

Jika kita lihat kembali relasi bentuk 1-NF yang telah dibuat sebelumnya, maka atribut bukan kunci pada table TBFaktur yang tidak memiliki dependensi sepenuhnya dengan primary key (ID_Faktur), yaitu : “Nama_Petugas”. Oleh sebab itu dekomposisi relasi perlu dilakukan kembali dengan cara :

Mengeliminasi atribut “Nama_Petugas” dari table TBFaktur
Membuat tabel TBPetugas, menyediakan atribut-atribut yang terkait dengan identitas dan data pelanggan

D. THIRD NORMAL FORM ( 3NF )

Pada Second Normal Form (2-NF) atribut yang terkait dengan “Nama_Pelanggan” tidak didekomposisi dari table TBFaktur karena atribut tersebut masih memiliki dependensi fungsional dengan primary key (ID_Faktur) karena tiap nomor faktur akan berbeda untuk tiap pembeli/pelanggan. Tetapi pada tahap 3-NF (Third Normal Form), atribut “Nama_Pelanggan” harus didekomposisi relasi karena pada tahap ini atribut bukan kunci tidak boleh ada yang berdependensi transitif dengan kunci primer.

Atribut “Nama_Pelanggan” dikatakan berdependensi transitif terhadap primary key (ID_Faktur) karena :

1. ID_Pelanggan → Nama_Pelanggan (Nama_Pelanggan berdependensi fungsional terhadap ID_Pelanggan)

2.ID_Faktur → ID_Pelanggan (ID_Pelanggan berdependensi fungsional terhadap ID_Faktur, karena tiap nomor faktur akan dikeluarkan untuk suatu ID_Pelanggan tertentu)

3. Sehingga dikatakan bahwa ID_Faktur memiliki dependensi transitif terhadap atribut Nama_Pelanggan

http://ariswidodo.wordpress.com/2008/05/03/normalisasi-database/

Database Faktur Supermarket

nickyoktarina — Wed, 07 Jan 2009 10:02:22 +0000

Objek Handphone

nickyoktarina — Tue, 30 Dec 2008 14:10:06 +0000

Rental VCD

nickyoktarina — Tue, 30 Dec 2008 14:05:01 +0000

Lingkungan Database

nickyoktarina — Thu, 23 Oct 2008 06:39:02 +0000

Lingkungan database dan Pembuatan Model Data (data modelling) serta penggambaran Grafis Database pada Diagram E-R.Untuk menciptakan lingkungan database, harus dapat memahami relasi antar data, jenis data yang akan dimasukkan dalam database, bagaimana data digunakan dan bagaimana organisasi sewaktu-waktu dapat mengubahnya secara mudah untuk kepentingan perusahaan
Merancang database
Dalam perancangan database ada dua macam model perancangan, yaitu :
Rancangan konseptual Rancangan ini berupa model abstrak dari database dalam sudut pandang bisnis. Rancangan ini membutuhkan deskripsi rinci tentang informasi bisnis yang dibutuhkan oleh pengguna.
Rancangan fisik Dalam rancangan ini menunjukan bagaimana database secara nyata dikelola pada perangkat penyimpanan.
Mendistribusikan Database
Perencanaan database harus mempertimbangkan juga kemungkinan pendistribusiannya. Sistem informasi bisa dirancang dengan sebuah data base pusat yang digunakan oleh suatu prosesor pusat atau beberapa prosesor dalam sebuah jaringan.Database terdistribusi adalah database yang tersimpan dalam lebih dari satu lokasi fisik. Beberapa bagian tersimpan secara fisik pada suatu lokasi, dan bagian-bagian lain tersimpan pada lokasi lain pula. Sistem terdistribusi dapat mereduksi kelemahan-kelemahan dari satu sistem besar pada satu lokasi.Sistem distribusi meningkatkan kecepatan layanan dan respons terhadap pengguna lokal dan sering dijalankan pada komputer yang lebih kecil dan murah. Namun sistem ini bergantung pada saluran telekomunikasi yang kualitasnya sangat baik. Oleh karena itu para perancang harus mempertimbangkan faktor tersebut.
Persyaratan Manajemen untuk Database
Dalam mengembangkan database ada banyak hal yang harus dilakukan, tidak hanya memilih model logika database. Tanpa dukungan dan pemahaman dari manajemen maka usaha membangun database akan gagal. Adapun elemen-elemen inti dalam lingkungan database adalah :
Administrasi data
Sistem database mengharuskan organisasi untuk mengatur kembali peran strategi dari informasi dan mulai secara aktif mengelola dan merencanakan informasi sebagai sumber perusahaan. Ini berarti organisasi harus mengembangkan fungsi administrasi data dengan kekuatan untuk menentukan persyaratan informasi untuk seluruh perusahaan dan akses langsung ke manajemen senior. Prinsip dasar administrasi data adalah semua data merupakan milik organisasi secara keseluruhan dan data tidak bisa dikatakan milik salah satu wilayah bisnis tertentu.
Perencanaan data dan Metodologi pemodelan
Kebutuhan-kebutuhan organisasi yang dilayani oleh DBMS jauh lebih lebar daripada yang dilayani oleh lingkungan file tradisional. Oleh karena itu, organisasi memerlukan perencanaan data yang menyeluruh. Analisis perusahaan sangat diperlukan untuk mengembangkan data base.Adapun tujuan analisis tersebut adalah mengidentifikasi entitas-entitas kunci, atribut dan relasi yang menyusun data organisasi.
Teknologi, manajemen dan penggunaan database
Database membutuhkan perangkat lunak, staf dan struktur manajemen data yang dilatih secara khusus dalam hal teknik-teknik database. Sebagaian besar perusahaan mengembangkan rancangan database dan kelompok manajemen daidalam divisi sistem informasi yang bertanggung jawab dalam menentukan dan mengorganisasian sturtur dan isi database dan memeliharanya. Dalam interaksi erat dengan pengguna, kelompok perancang menetapkan database fisik, relasi logis antar elemen dan peraturan dan prosedur akses.
Pembuatan Model Data (data modelling)
Pembuatan Model Data (data modelling adalah)proses menyusun database, agar database itu benar-benar mewakili seluruh aspek organisasi, termasuk interaksi organisasi dengan lingkungan eksternal.
Proses desain database terbagi dalam beberapa tahap, yaitu:
Perencanaan (planning), mempertimbangkan dua aspek yaitu teknologi dan ekonomi
Analisis Persyaratan (Requirement Analysis)
Desain, disesuaikan dengan eksternal, internal dan konseptualnya.
Pengkodean (Coding)
Implementasi, tahap ini sangat mempertimbangkan bagaimanakah bentuk perubahan dari konsep SIA lama ke konsep SIA yang baru.
Operasional dan pemeliharaan
Satu cara untuk melaksanakan kegiatan definisi persyaratan dan desain konseptual adalah dengan membangun model data SIA. Model data akuntansi REA dikembangkan secara khusus untuk membangun database SIA. Model REA mengklasifikasikan data menjadin tiga kategori dasar, yaitu: Sumber daya, Kegiatan dan Pelaku. Model REA dapat didokumentasikan dalam bentuk diagram E-R, yang menampilkan entitas data yang dikumpulkan dan memperjelas pentingnya hubungan antar-data. Kardinalitas hubungan yang tampak dalam diagram REA juga menyediakan informasi mengenai kebijakan bisnis dasar yang diikuti oleh perusahaan.
Diagram E-R
Digram E-R merupakan representasi dari model data konseptual antara data dictionary yang mengorganisasi data yang direpresentasikan oleh entitas-entitas yang ada dalam suatu organisasi. Ada dua pendekatan dalam pembuatan Entity Relational Digram yaitu :
a. Basic Relational Model
Digram E-R yang direpresentasikan ini menggunakan simbol-simbol yang dasar dengan menghubungkan hubungan antar entitas yang ada dalam satu organisasi .
b. Database Relational Model
Digram E-R dalam model ini menggunakan struktur data sebagai acuan yang merepresentasikan hubungan antar entitas. Struktur data ini biasanya diklasifikasikan sesuai kebutuhan data yang harus tersedia, tabel yang digunakan sebagai satu kualifikasi dari struktur data yang ada.Database relational model merepresentsikan hubungan antar entitas dalam organisasi dengan lebih detail mengarah pada struktur data yang disebut sebagai Relational Database Accounting System.Diagram E-R merupakan teknik grafis yg menggambarkan skema database. Diagram ini menunjukan beberapa entitas yang dimodelkan E-R menunjukan isi databasedan secara grafis merupakan model suatu organisasi. Model data REA digunakan untuk mengambil keputusan mengenai hal berkaitan. Adapun langkah –langkah menyusun diagram REA terdapat 4 cara yaitu :
Identifikasi sumber daya dipengaruhi oleh setiap kegiatan pertukaran yang terlibat dalam kegiatan tersebut.
Masukan kegiatan komitmen
Menetapkan kardinalitas hubungan.

http://eulis.wordpress.com

Edit this entry.

Pengantar Sistem basis data

nickyoktarina — Tue, 16 Sep 2008 09:44:00 +0000

Pengantar Basis Data

Konsep dasar basis data adalah sekumpulan fakta yang dapat digambarkan dengan model diagram hubungan antar entitas (Entity-Relationship Modelling Diagram). Komponen pembentuk ER Diagram sbb:
~

Entity
Suatu kumpulan obyek dengan property yang sama dengan ciri memiliki identitas yang dapat berdiri sendiri; contoh: mahasiswa, kelas, mata kuliah, pegawai, kantor cabang dsb.
~
Dapat berdiri sendiri maksudnya dalam record-recordnya terdapat attribut yang unik yang dapat dijadikan pembeda untuk masing masing record. Sebuah entitas memiliki tipe berdasarkan kemampuannya berdiri sendiri antara lain tipe Strong dan tipe Weak.
1. Strong Entity
  Bila suatu entitas dapat berdiri sendiri tanpa dukungan attribut dari entitas lain; contohnya: entitas Pegawai.
  ~
2. Weak Entity
  Bila suatu entitas tidak dapat berdiri sendiri tanpa dukungan attribut dari entitas lain;contohnya: entitas Tunjungan, Tunjangan tidak dapat berdiri sendiri tanpa ada attribut pegawai.
  ~
Relationship (Hubungan antar entitas)
Hubungan yang dimaksud adalah asosiasi attribut antar entitas yang memiliki makna; contohya: entitas Manajer dan entitas Kantor Cabang memiliki sebuah Relationship “Kelola”, jadi makna yang dibaca adalah “Seorang Manajer mengelola sebuah Kantor Cabang”, (jenis hubungan one-to-one).
~
Sebuah Relationship memiliki derajat (degree) berdasarkan jumlah entitas yang terhubung antara lain: Unary, Binary, Ternary dan Quaternary.
1. Unary
  Tipe hubungan ini berbarti hubungan yang terjadi antara dirinya sendiri dlam sebuah entitas; contohnya: entitas Pegawai yang memiliki Relationship Supervisor. Pegawai yang menjadi Supervisor juga berasal dar entitas yang sama yaitu Pegawai sedangkan entitas yang dituju juga pada entitas Pegawai.
  ~
2. Binary
  Tipe hubungan ini antara dua entitas; contohnya: entitas Pegawai dan entitas Kantor Cabang.
  ~
3. Ternary
  Tipe hubungan ini antara tiga entitas; contohnya :entitas Sales, Produk dan Pelanggan yang memiliki sebuah Relationship yang bernama Penjualan.

Relationship bisa terdapat lebih dari satu dalam sebuah / lebih entitas.

Attribut
Detail dari sebuah entitas; contohnya entitas Mahasiswa memiliki attribut: npm, nama, jenis kelamin, kelas, tgl lahir dst… entitas Pasien memiliki attribut: nama, tgl lahir, berat badan, golongan darah dst…
Attribut memiliki tipe tipe sbb:
1. Simple
  Sebuah attribut yang memiliki komponen tunggal dan independent; contohnya: nama, tgl lahir dst…
  ~
2. Composite
  Sebuah attribut yang memiliki komponen banyak dan masing masing komponennya independent; contohnya: Alamat-> jalan, kota, kode pos dst…
  ~
3. Multi-valued
  Sebuah attribut yang memiliki nilai banyak; contohnya: dalam sebuah entitas Mahasiswa terdapat sebuah attribut nomor HP yang isinya bisa lebih dari satu record.
  ~
4. Derived
  Sebuah attribut yang memiliki nilai turunan dari hasil kalkulasi attribut yang lain; contohnya attribut umur yang dihitung berdasarkan attribut tanggal lahir.
Sebuah entitas harus memiliki Key attribut sebagai pembeda untuk masing masing record. Key attribut memiliki tipe sbb:
1. Candidate Key
  Attribut yang dapat digunakan sebagai Primary Key attribut. Dipilih berdasarkan keunikan nilai attribut; contohya: dalam entitas Mahasiswa terdapat attribut nama, npm yang dipilih sebagai Candidate Key.
  ~
2. Primary Key
  Attribut yang dipilih sebagai attribut pembeda utama dalam sebuah entitas, dipilih dari Candidate Key yang paling baik, baik dalam artian paling unik dan paling mudah dimanipulasi dalam program.
  ~
3. Composite Key
  Candidate Key yang memiliki lebih dari satu attribut; misalnya dalam sebuah entitas yang Weak terdapat dua Key attribut yang dipakai sebagai attribut pembeda; contohnya: dalam entitas Tunjangan ada attribut Nama dan attribut Pegawai sebagai Key, artinya kalau hanya nama bisa jadi lebih dari satu record dan kalau hanya Pegawai bisa jadi lebih dari satu Tunjangan.

Structural Constraints

Dalam sebuah Relationship pada Basis Data terdapat batasan batasan yang terstruktur (Structural Constraints). Tipe utama dari batasan disebut multiplicity yang mencerminkan aturan dari sistem yang akan dibuat oleh user.

Multiplicity dibuat berdasarkan dua batasan yaitu Cardinality dan Participation.

Cardinality
Adalah nilai maximum occurrence dari sebuah Relationship antara dua entitas; contohnya: antara entitas Dosen dan Mata Kuliah terdapat Relationship “Mengajar” dengan multiplicity “0..5“, artinya satu dosen boleh mengajar maximal 5 mata kuliah sedangkan sebuah mata kuliah bisa jadi belum memiliki dosen pengajarnya. Cardinality = 5 dan Participation = 0.
~
Participation
Adalah nilai minimum occurrence dari sebuah Relationship antara dua entitas; contohnya antara entitas Gedung dan Ruang Kelas terdapat Relationship “Terdiri Dari” dengan multiplicity “1..5“, artinya satu Gedung bisa terdapat maximal 5 ruang kelas tapi satu ruang kelas hanya terdapat pada satu gedung. Cardinality = 5 dan Participation = 1
~

Secara umum degree Binary paling banyak dipakai dimana umumnya hubungan itu merujuk pada tiga jenis hubungan sbb:

one-to-one (1..1)
Dimana dalam sebuah occurrence terdapat hanya satu pasangan pada entitas lainnya; contohnya: antara entitas Kantor Cabang dan Manager, sebuah kantor cabang hanay boleh dimanageri oleh sorang manager dan begitu juga sebaliknya seorang manager hanay boleh memanage sebuah kanto cabang.
~
one-to-many (1..*)
Dimana dalam sebuah occurrence terdapat bisa lebih dari satu pasangan pada entitas lainnya.
~
many-to-many (*..*)

http://wibisastro.wordpress.com/2008/02/18/pengantar-basis-data/

teori sistem basis data

nickyoktarina — Tue, 16 Sep 2008 09:41:31 +0000

Tujuan dari mata kuliah ini adalah untuk memberikan pemahaman mengenai konsep dan definisi sistem basis data, komponen dari sistem basis data dan bagaimana membuat sistem basis data. dasar teori yang perlu dipahami dalam mata kuliah ini adalah bagaimana membuat model Entity Relationship Diagram (ER-Diagram) melalui simbol-simbol, selanjutnya adalah proses mapping atau tranformasi model ER-Diagram kedalam slema database. Setelah itu, mahasiswa akan belajar bagaimana melakukan normalisasi tabel dan memanipulasi data melalui query yang dituliskan dalam aljabar relasional. Aljabar relasional ini merupakan notasi simbol matematis sebelum belajar tentang bahasa query (SQL). Terakhir mahasiswa akan belajar mengenai bahasa SQL baik DML maupun DDL.