selamat datang para pengunjung setia kami

Senin, 15 Desember 2008

Database Tersebar


Dalam sebuah database terdistribusi, database disimpan pada beberapa komputer. Komputer komputer dalam sebuah sistem terdistribusi berhubungan satu sama lain melalui bermacam macam media komunikasi seperti high-speed buses atau telephone line. Sebuah sistem database terdistribusi berisikan sekumpulan site, di mana tiap-tiap site dapat berpartisipasi dalam pengeksekusian transaksi-transaksi yang mengakses data pada satu site atau beberapa site. Tiap tiap site dapat memproses transaksi lokal yaitu sebuah transaksi yang mengakses data pada satu site di mana transaksi telah ditentukan.

Sebuah site juga dapat mengambil bagian dalam mengeksekusi transaksi global yaitu transaksi yang mengakses data pada site yang berbeda di mana transaksi telah ditentukan, atau transaksi yang mengakses data pada beberapa site yang berbeda.

Ada 2 aspek penting dari DDB :

1. Distribusi : data tidak disimpan pada tempat (prosesor) yang sama, sehingga DDB dapat dibedakan dari database tunggal, sentralisasi

2. Korelasi logika : data memiliki property yang berhubungan sehingga DDB dapat dibedakan dari sekumpulan database local atau file yang disimpan pada tempat yang berbeda pada jaringan komputer.

SistemManajemen Database Terdistribusi (Distributed DBMS) merupakan system software yang dapat memelihara DDBS dan transparan ke user. DDBS bukan merupakan kumpulan dari file yang dapat disimpan tersendiri di setiap node dari jaringan komputer. Untuk membentuk DDBS, file tidak seharusnya berelasi secara logika saja, tetapi perlu ada struktur di antara file dan akses data bukan merupakan hal yang khusus.

Keuntungan dari DDBS

1. Otonomi local : karena data didistribusikan, user dapat mengakses dan bekerja dengan data tersebut sehingga memiliki kontrol local.

2. Meningkatkan kinerja : karena setiap site menangani hanya bagian dari DB, CPU dan I/ O tidak seberat seperti DB pusat. Data yang dipakai untuk transaksi disimpan dalam beberapa site, sehingga eksekusi transaksi dapat secara parallel.

3. Meningkatkan reliability/ availability : jika satu site mengalami crash, dapat membuat beberapa site tidak dapat diakses. Jika data direplikasi ke banyak site, kerusakan hubungan komunikasi tidak menjadikan sistem total tidak dapat dioperasikan.

4. Ekonomis : dari biaya komunikasi, baik membagi aplikasi dan memproses secara local di setiap site. Dari biaya komunikasi data, akan lebih murah untuk memelihara sistem komputer dalam satu site dan menyimpan data secara local.

5. Expandibility : akan lebih mudah mengakomodasikan ukuran DB yang semakin besar. Ekspansi dapat dilakukan dengan menambah proses dan kekuatan penyimpanan ke jaringan.

6. Shareability : jika sistem informasi tidak terdistribusi, akan sulit untuk berbagi data dan sumber daya. Sistem DB terdistribusi memungkinkan hal ini.

7.

Kerugian dari DDBS:

1. Kurangnya pengalaman : sistem DB terdistribusi bertujuan umum (generalpurpose) tidak sering digunakan. Yang digunakan adalah sistem prototype yang dibuat untuk satu aplikasi (misal : reservasi pesawat)

2. Kompleksitas : masalah DDBS lebih kompleks dibandingkan dengan manajemen database terpusat

3. Biaya : sistem terdistribusi membutuhkan tambahan hardware (untuk mekanisme komunikasi) sehingga biaya hardware meningkat. Yang terpenting pada biaya ini adalah replikasi. Jika fasilitas komputer dibuat di banyak site, akan memerlukan orang2 yang memelihara fasilitas tersebut

4. Kontrol distribusi : sebelumnya menjadi keuntungan. Tetapi karena distribusi menyebabkan masalah sinkronisasi dan koordinasi, kontrol terdistribusi menjadi kerugian atau kekurangan di masalaha ini.

5. Keamanan : akan mudah mengontrol database yang terpusat. Dalam system database terdistribusi, jaringan membutuhkan keamanan tersendiri.

6. Perubahan yang sulit : tidak ada tool atau metodologi untuk membantu user mengubah database terpusat ke database terdistribusi.

Contoh databases tersebar di Universitas Airlangga

Untuk mewujudkan perpustakaan digital di Perpustakaan Universitas Airlangga, program1software yang digunakan untuk memenejemen koleksi digital (skripsi, thesis, disertasi, dan laporan penelitian) dengan mengadopsi software Ganeslza Digital Library (GDL) versi 4.0 milik KMRT (Knowledge Managenzent Research Group) ITB. GDL ini dibuat dengan bahasa pemrograman PHP dan menggunakan database MySQL serta search engine SWISH-E GDL. Dalam perkembangannya perpustakaan digitaldi Perpustakaan Universitas Airlangga menggunakan istilah ADLN (Airlangga Digital Library Network). Dengan adanya sistem ADLN ini sumber-sumber informasi yang berisi tentang koleksi-koleksi civitas akademika (tesis, disertasi, laporan penelitian, dan skripsi) dapat dimasukkan dalam program ini. Saat ini informasi yang tersaji dalam system ADLN selain berisi deskripsi fisik koleksi pustaka juga berisi abstrak dari koleksi pustaka tersebut. Untuk ke depan isinya tidak hanya abstrak namun akan dikembangkan dalam bentuk full text. Full text yang tersaji dalam sistem ADLN saat ini hanya koleksi tesis, skripsi dan laporan penelitian.

Setelah ADLN dapat diterapkan di Perpustakaan Universitas Airlangga, maka sejak tahun 2004ADLN ini diperkenalkan ke ruang baca fakultas dan lembaga di lingkungan Universitas Airlangga. Dengan terhubungnya system ADLN di ruang baca fakultas dan lembaga di lingkungan Universitas Airlangga, diharapkan pengguna perpustakaan dapat mengakses informasi-informasi yang ada di ruang baca fakultasllembaga maupun sebaliknya di perpustakaan.

Selain ADLN, di Perpustakaan Universitas Airlangga saat ini juga menggunakan program LARIS (Library Autonzation Retrieval I~lfortnation System). Program ini juga mengadopsi program yang open source dari LASer sistem otomasi milik MDLRG (Muhamadiyah Digital library Research Group) UMM. LASer dirancang dengan menggunakan bahasa pemrograman PHP serta menggunakan system database MySQL. LARIS merupakan program sistem otomasi perpustakaan yang digunakan dalam proses pengolahan, penelusuran, layanan sirkulasi, dan absensi staf di Perpustakaan Universitas Airlangga. Dengan adanya program ini maka kendala yang dihadapi oleh Perpustakaan Universitas Airlangga yaitu letak kampus A, B, dan C yang saling berjauhan dapat diatasi. Dengan demikian petugas bagian sirkulasi dapat mengetahui buku yang dipinjam oleh seorang mahasiswa, baik buku tersebut ada di lokasi perpustakaan kampus A, B, maupun C. Bagi pengguna bila sistem ini sudah dioperasikan secara maksimal akan dapat mengetahui status buku, apakah buku tersebut sedang dipinjam atau bisa dipinjam. Sedang absensi pegawai berfungsi untuk mengetahui waktu kehadiran dan pulang seorang pegawai, sehingga dapat dipantau.

Contoh basis data terpusat

Sistem informasi Perpustakaan LAGG (SIP), Sistem ini telah beroperasi lebih dahulu secara stand-alone di perpustakaan UPT-LAGG, dimana antar muka pemakai (user interface) yang digunakan dibuat dari Visual Basic (VB). Sistem dirancang untuk memenuhi seluruh kebutuhan pemakai perpustakaan, petugas maupun pengunjung.

Senin, 01 Desember 2008

Oriented Object Data Base Manajement System 4

IV. KESIMPULAN

A. PERBEDAAN PARADIGMA
Ada perbedaan yang mendasar antara ODBMS dengan system basis data konvensional. RDBMS mempresentasikan data kedalam bentuk fable terformat, dngean kolom menggambarkan atribut dan baris yang berisi record data. Table-tabel itu hanya dapat berisi suatu tipe data yang terbatas dan sederhana seperti teks dan integer sehingga sulit untuk mengani tipe data uang komples seperti multimedia.
Data pada RDBMS dapat diakses secara tabular atau dngan menguraikan table tersebut dengan menguraikan table tesebut dngan berbagai cara untuk menampilkan atau mengolah data untuk berbagai keperluan.
ODBMS mengukung pembuatan dan pemodelan data sebagai suatu objek. Pemprogram atau pemakai dapat menambahkan tipe data baru hanya dengan membuat sebuah objek baru. Data pun diakses atau diolah dengan cara orientasi objek.
Pada pembuatan aplikasi dengan RDBMS, pemrograman harus membuat prosedur untuk memetakan table dngen variable atau objek yang ada pada alikasinua. Dngena ODBMS hal ini tidak diprelukan lagi.

B. KEBUTUHAN APLIKASI
Pada beberapa aplikasi tertentu penggunaan OODB mungkin sangat tepat. Sebaliknua untuk beberapa aplikasi tertentu OODB mungkin akan menjadi hambatan serius.
Bila aplikasi yang dibuat menggunakan tipe data multimedia dan bersigat kompleks, maka OODB adalah pilihan yang tepat. Bayangkan menyimpan data sebuah gambar 3 dimensi dari satu rumah saja. Bila harus disimpan dalam bentu basis data konvensial yan berbentuk tabular. Kita harus membuat field yang beragam, relasi yang rumit dan mungkin menghasiklan sebuah basis data dengan normalisasi yang buruk.
Akan tetapi OODB tidak cocok digunakan untuk menyimpan data transaksi yang besar seoerti data keuangan, kepegawaian dan data transaksi bank. Disini mungkin lebih baik memilih RDB.

Oriented Object Data Base Manajement System 3

III.2.KELEMAHAN OODB TIGHT COUPLING
Istilah tight coupling maksudnya antara aplikasi dengan data sedemikian rupa terikat hingga sulit dipisahkan satu dengan lainnya. Misalnya system database Microsoft Acces dengan bahasa pemprograman MS-Visual Basic mempunyai hubungan loose couple karena kita dapa menggunakan banyak pilihan system basis data untuk program dalam program dalam MS-Visual basic dan juga dapat menggunakan banyak pilihan bahasa pemprograman lainnya untuk mengakses data dalam MS-Acces. Sementara bahasa COBOL dengan databasenya sangat tignt couple karena sulit mengakses basis data COBOL dengan bahasa pemprograman lain.
Sementara tight coupling mempunyai keuntungan karena menyederhanakan program dan desainnya, akan tetapi hal ini memiliki kekurangna karena menghilangkan batas antara basis data dengan aplikasi. Juga menyebabkan suatu kendala baru bila kita ingin bermigrasi ke produk ODBMS yang berbeda atau kembali kedalam RDBMS.

KINERJA YANG MUNGKIN KURANG BAIK
Dari uraian diatas telah dipaparkan bagaimana keperkasaan kinerja OODB terutama dalam hal mengakses data. Tetapi perlu juga disampaikan bahwa pada kondisi tertentu mungkin saja OODB menghasilkan kinerja yang buruk. Misalnya pelaksanaan ad-hoc query yang sangat lemah dalam OODB.
Memang dalam beberapa hal produk ODBMS masih kalah dengan produk RDBMS yang telah lebih lama beredar di pasaran. Dianataranya masalah-masalah fungsionalisasi dan optimalisasi query ini. Hal ini wajar saja mengingat usia OODB yang relative muda.
KURANGNYA DUKUNGAN PLATFORM
Pada dasarnya OODB dapat diterapkan pada bahasa pemprograman berorientasi objek apa saja ,tapi produk ODBMS yang ada sekarang ini kebanyakan masih diorientasiakan untuk digunakan dalam bahasa .net, java dan C++. Disamping itu juga belum banyak tersedia komponen untuk pengaksesan OODB untuk bahasa pemprograman lainnya.
Walaupun OODB dapat diimplemetnasikan dalam java yang sifatnya platform independent, belum tentu pada platform yang kita miliki mendukung implemetnasi java. Selain itu java juga memiliki aneka nuansa dan keanehan-keanehan bila diterapkan pada lingkungan berbeda.

SULIT BERMIGRASI
Cara penyimpanan dan pengabilan data pada OODB sangat berbeda dengan RDB. Demikian juga cara pengaksesannya. Oleh karena itu, bila kita bermigrasi ke OODB maka kita harus berkomitmen untuk terus menggunakan OODB. Setelah mengimplementasikan OODB, sangat sulit untuk kembali ke RDB.

KURANG SDM
Mencari seseorang yang memiliki spesifik pada salah satu ODBMS jauh lebih sulit daripada mencari seseorang yang meiliki pemahaman RDB dan penguasaan salahsatu database seperti MS-Access, MS-SQL server Oracle dan lain-lain. Lebih sulit lagi mencari seorang yang benar-benar menguasai administrasi system OODB.
QUERY YANG KOMPLEKS
Pada masing-masing ODBMS kadang memiliki cara query yang berbeda. Selain itu kadang kita tidak mengakses data dengan cara memanggil ObjekID-nya saja, tetapi kadang berdasarkan range, pola dan berangam criteria lain yang mungkin kelihatannya tidak berhubungan. Ini berakibat penggunaan OODB membutuhkan kemampuan logika mendalam.

Oriented Object Data Base Manajement System 2

KELEBIHAN DAN KELEMAHAN OODB :

III.1.KELEBIHAN OODB

A. DESAIN BASIS DATA YANG BAGUS
Pada suatu system yang dinamis pemprogrman sering harus menghabiskan banyak waktu dan tenaga untuk menagnani masalah data. Dengan OODB, masalah ini tidak hilang, tetapi dapat dikurangi. Karena dengan orientasi objek maka proses penyimpanan dan pengambilan data jauh lebih sederhana.
Dengan OOP, program dan data teruntegrasi dengan baik. Dengan paradigma orientasi objek dapat menyederhanakan application modeling, kebutuhan design tool dan visualisasi system serta desainnya. Dengan OODB tidak hanya kita mendapatkan persistensi data tai keseluruhan objek basis data, bahkan termasuk implemented behavior-nya. Juga kita dapat memanggil suatu method dari pbjek tertentu pada basis data di server sehingga sistribusi aplikasinya lebih mudah.
Dalam RDB untuk melaksanakan hal ini kita harus memasukkan stored procedure atau suatu komponen objek. Sehingga arsitektur dari aplikasi jadi lebih rumit dan membutuhkan keahlian pemprograman lebih lanjut.
B. PENYEDERHANAAN PEMBUATAN APLIKASI
Dengan OODB kita dapat menyederhanakan bahasa pemprograman dan implementasi teknologi yang dibutuhkan . terkandang kita tidak menyadari bahwa suatu proyek menjadi lebih tinggi biayanya karena banyak factor teknis seperti penggunaan beberapa tool, bahasa program dan lingkungan dari aplikasi yang berbeda-beda.
Dengan OODB maka kemampuan teknis yang dibutuhkan menjadi berkurang karena pemprograman cukup menguasai konsep orientasi objek (object oriented ) dengan sedikit tambahan mengenai koneksi ke basis data. Tentunya pemrogram harus juga menguasai bahasa pemprograman berorientasi objek seperti .net dan java.
Selain itu program tidanggal memfokuskan pada persistensi obyek. Program tidak perlu lagi menguraikan objke ke dalam table memikirkan relasi antar table , dan sebaliknya.
C. KINERJA YANG TANGGUH
Pada produk ODBMS uang tepat dan sesuai dengan aplikasi yang dibuat, OODB dapat meningkatkan kinerja aplikasi dnegna peningkatan yang tinggi.
Seperti diuraikan di atas, dengan RDB seorang pemprogram harus menghabiskan waktu untuk memetakan data degnan objek, menguraikan table-tabel kedalam objek dan sebagainya. Terkadang hai ini mencapai sepertiga atau bahkan separuh dari watu pembuatan program itu sendiri. Hal ini menyebabkan juga kinterja program lebih lambat kearena harus melaksanakan pemetaan objek tesebut. Belum lagi program harus melaksanakan beberapa query yang makin memperlambat kinerja program tersebut.
Dengan OODB tentu kinerja program dapat lebih baik karena hal-hal diatas tidak lagi diperlukan. Karena program langsung mengakses data dengan objeknya.
Pada beberapa produk OODBMS bahkan dimunkginkan adanya client chaching. Bayangkna kecepatan yag dapat dihasilkan bila program hanya mengakses cache dari basis data yang sudah ada di client.

Oriented Object Data Base Manajement System

I. SEKILAS TENTANG ORIENTED OBJEK DATABASE (OODB)
Oriented Object Database (OODB) mengintegrasikan kemampuan basis data (DBMS) dnegan kemampuan pemprograman berorientasi objek (OOP).
Sebuah objext oriented management system (ODBMS) membuat objek sebuah basis data terlihat seperti objek pemprograman pada beberapa bahasa pemprograman OOP.
OODB atau ODBMS dirancang untuk bekerja pada bahasa pemprograman OOP seperti Java, .net dan lain-lain. Bila kita ingin menyimpan objek pada program jaa atau .net ke dalam sebuah system basis data, kita dapa menggunakan basis data yang berorientasi kepada obyek (ODBMS).
Letak perbedaan utama ODBMS dengan RDBMS adalah pada RDBMS data direpresentasikan ke dalam bentuk table-tabel dengan kolom yang mewakili atribut data, dan beris record data itu sendiri. Sedangkan dalam ODBMS, data direpresentasikan sebagai sebuah objek, baik dalam hal pengaksesannya maupun dalam hal pemodelannya.

I.1.PERKEMBANGAN ODBMS
Pada saat diperkenalkan pertamakali, ODBMS diberikan akan segera menjadi teknologi utama dibidang basis data menggantikan Sistem Basis Data Relasional (RDBMS). Terutama karena RDBMS tidak dirancang untuk menangani tipe data multimedia. Kenyataan pada saat ini ramalan tersebut tidak mengenai sasaran. Saat ini terbutki RDBMS masih jauh lebih banyak dipergunakan. OBDMS hanya mendapatkan sebagian kecicl dari pasar perangkat lunak basisdata. Penjualan RDBMS mencapai 50 kali lipat penjualan ODBMS. Disisi lain pembuat RDBMS menambahkan kemampuan penggunaan objek ke dalam system buatannya menjadi objek relational database management system(ORDBMS).

II.2. BERBAGAI PENDAPAT TENTANG ODBMS
Banyak pihak yang meragukan perkembagan ODBMS diantaranya tersurat pada pendapat yang dikemukakan oleh Michael Stonebraker, CTO dari Informix yang mengeluarkan produk ORDBMS menyatakan bahwa “ODBMS hanya memiliki pangsa pasar kecil yang tidak memeiliki masa depan yang luas dan ORDBMS akan menggeser posisi OBMS dalam waktu hanya 5 tahun saja.”
Akan tetapi dilain pihak, optimisme akan ORDBMS tetap besar, diantaranya mengutip pendapat Rick Cattel dari Sun Mycrosystems yaitu “perkembangan ODBMS masih cukup baik, walaupun skala penjualannya yang tidak besar, akan tetapi ODBMS akan tetap dipergunakan terutama pada bidang CAD (computer-aided design) dan telekomunikasi yang tidak cocok untuk menggunakan RDBMS.”
OODB sangat banyak digunakan dalam bidang CAD/CAM dan Sistem Cerdas Terapan (AI) karena ODBMS mendukung tipe data yang kompleks dan relasi yang sulit. Juga OODB secara efisien mendukung tipe data multimedia yang banyak digunakan dalam aplikasi CAD/CAM.
Pada kesempatan lain Cattell dan Sun Microsystem menyatakan bahwa “OODB juga digunakan pada system pendataan pasiaen rumah sakit karena bagi staf rumah sakit OODB lebih mudah dipergunakan daripada basis data relasional.”
Akmal Chaudhri, seorang ahli system basis data dan doctor di The City University, London diantaranya J.P.morgan, Chase Manhattan dan Citibank menggunakan teknologi ODBMS untuk pemodelan instrument keuangan seperti obligasi.” Hal ini disebabkan teknologi ini membantu mengolah instrument yang dibutuhkan dalam pemodelan secara efektif. Teknologi berorientasi-objek juga mendukung mekanisme pewarisan (inheritance) untuk pemodelan instrument berikutnya dengan cepat dan mudah.
Juga menurut Akmal Chaudhri,”jika kita ingin memodelkan sebuah Boeing 747 dengan ODBMS, maka hubungan antara komponen pesawat dikelola langsung oleh system basis data. Sedangkan jika kita menggunakan RDBMS, kita harus membagi-bagi pesawat tersebut dalam table-tabel dan menghubungkan lagi table-tabel tersebut bila kita ingin membangun pesawat tersebut.”

Jumat, 07 November 2008

DESAIN DATABASE (MODEL RELASIONAL DAN DESKRIPSI ATRIBUT)

Basis data (database) merupakan kumpulan dari data yang saling berhubungan
satu dengan yang lainnya, tersimpan di simpanan luar komputer dan digunakan
perangkat lunak tertentu untuk memanipulasinya. Database merupakan salah
satu komponen yang penting di sistem informasi, karena berfungsi sebagai
basis penyedia informasi bagi para pemakainya. Penerapa database dalam
sistem informasi disebut dengan database system. Sistem basis data
(database system) ini adalah suatu sistem informasi yang mengintegrasikan
kumpulan dari data yang saling berhubungan satu dengan lainnya dan
membuatnya tersedia untuk beberapa aplikasi yang bermacam-macam di dalam
suatu organisasi.
Tujuan dari desain database adalah untuk menentukan data-data yang
dibutuhkan dalam sistem, sehingga informasi yang dihasilkan dapat
terpenuhi dengan baik. Terdapat beberapa alasan mengapa desain database
perlu untuk dilakukan, salah satu adalah untuk menghindari pengulangan data.
Adapun metode untuk meminimasi pengulangan data (data redudancy) antara
lain dengan :
a. Normalisasi.
b. Dekomposisi lossless.
Diperlukan jika ada indikasi bahwa tabel yang kita buat tidak baik
(terjadi pengulangan informasi, potensi inkonsistensi data pada operasi
pengubahan, tersembunyinya informasi tertentu) dan diperlukan supaya
jika tabel-tabel yang didekomposisi kita gabungkan kembali dapat
menghasilkan tabel awal sebelum didekomposisi, sehingga diperoleh tabel
yang baik.
c. ERD (Entity Relationship Diagram).
d. Menentukan kardinalitas relasi.
Terdapat beberapa pengertian tentang key sehubungan dengan normalisasi dan
ERD, antara lain :
a. Superkey adalah gugus dari sejumlah atribut entiti yang dapat digunakan
untuk mengidentifikasi obyek secara unik.
b. Candidate key adalah superkey dengan jumlah atribut minimal dan dapat
berdiri sendiri.
c. Primary key adalah superkey yang dipilih oleh desainer atau administrator
basis data.
4.2. Normalisasi.
Adalah proses yang berkaitan dengan model data relational untuk
mengorganisasi himpunan data dengan ketergantungan dan keterkaitan yang
tinggi atau erat. Hasil dari proses normalisasi adalah himpunan-himpunan
data dalam bentuk normal (normal form). Ada beberapa bentuk normal, yaitu :
a. Bentuk Normal I (First Normal Form / 1-NF).
b. Bentuk Normal II (Second Normal Form / 2-NF).
c. Bentuk Normal III (Third Normal Form / 3-NF).
d. Bentuk Normal IV (Fourth Normal Form / 4-NF).
e. Bentuk Normal Boyce-Codd (Boyce-Codd Normal Form / BCNF).
f. Project-Join Normal I Form (PJNF).
g. Domain-Key Normal I Form (DKNF).
h. Bentuk Normal V (Fifth Normal Form / 5-NF).
Kegunaan normalisasi :
a. Meminimasi pengulangan informasi.
b. Memudahkan indentifikasi entiti / obyek.
4.3. Bentuk Normal I (First Normal Form / 1-NF).
Suatu relasi memenuhi 1-NF jika dan hanya jika setiap atribut dari relasi
tersebut hanya memiliki nilai tunggal dalam satu baris atau record.
Tabel 4.1 : Bentuk tidak Unnormalized Form (Non 1-NF table)
Tabel 4.2 : Bentuk 1-NF table
4.4. Bentuk Normal II (Second Normal Form / 2-NF).
Suatu relasi memenuhi 2-NF jika dan hanya jika :
a. Memenuhi 1-NF.
b. Setiap atribut yang bukan kunci utama tergantung secara fungsional
terhadap semua atribut kunci dan bukan hanya sebagian atribut.
Jika suatu relasi memenuhi 1-NF dan relasi tersebut memiliki tepat satu
atribut yang membentuk kunci utama, maka relasi tersebut memenuhi 2-NF.
Rasionalisasi 2-NF :
a. Memiliki semantik yang lebih eksplisit dari 1-NF.
b. Mencegah beberapa kondisi anomali dalam update data.
Tabel 4.3 : Bentuk 2-NF table (satisfying 1-NF).
Ketergantungan fungsional dilakukan untuk :
a. StudentID => Student, BirthDate (SC1).
b. CourseID => Course, Credit (SC2).
c. StudentID, CourseID => Grade (SC3, SC3A).
d. Grade => Weight (SC3B).
Tabel 4.4 : Tabel yang memenuhi 2-NF.
Tabel 4.5 : Tabel yang memenuhi 3-NF.
Akhirnya semua tabel SC1, SC2, SC3A, SC3B berada dalam kondisi 3-NF,
sehingga semua databases mengalami kondisi 3-NF.
4.5. Bentuk Normal III (Third Normal Form / 1-NF).
Suatu relasi memenuhi bentuk III (3-NF) jika dan hanya jika :
a. Relasi tersebut memenuhi 2-NF.
b. Setiap atribut bukan kunci tidak tergantung secara fungsional kepada
atribut bukan kunci yang lain dalam relasi tersebut.
Suatu relasi yang memenuhi 2-Nf dan hanya memiliki satu atribut bukan kunci
selalu memenuhi 3-NF.
4.6. Bentuk Normal Boyce-Codd (Boyce-Codd Normal Form / BCNF).
Suatu relasi memenuhi BCNF jika dan hanya jika setiap determinan yang ada
pada relasi tersebut adalah kunci kandidat (candidate keys).
Determinan adalah gugus atribut dimanaa satu atau lebih atribut lain
tergantung secara fungsional.
4.7. Model Hubungan atau Relasi Entiti (Entity Realtionship (E-R) Model).
Model relasi entiti didasarkan pada persepsi dunia nyata yang terdiri dari
himpunan obyek dasar yang disebut entiti dan relasi antar entiti.
Entiti adalah obyek yang dapat diidentifikasi secara unik.
Entiti dikarakterisasi dan dipresentasikan dengan suatu gugus atribut.
Contoh gugus atribut dari entiti PEKERJA adalah nama, tanggal lahir, NIP,
golongan/pangkat.
Sekelompok entiti yang memiliki karakterisasi entiti disebut gugus entiti
(entity set).
Setiap entiti dari gugus tersebut disebut anggota gugus (member of set).
Contoh gugus entiti adalah gugus entiti pegawai bank, gugus entiti nasabah
bank. Dari beberapa gugus tadi mungkin terjadi suatu relasi, misalnya relasi
antara gugus bank dengan gugus nasabah bank.
Berdasarkan jumlah gugus yang terlibat maka relasi antar entiti dibedakan
menjadi :
a. Relasi biner (binary), yaitu relasi antar 2 gugus entiti.
b. Relasi trio (ternary), yaitu relasi antar 3 gugus entiti.
c. Relasi N-ary, yaitu relasi antar n gugus entiti.
Khusus untuk relasi biner maka relasi antar anggota dari dua gugus yang
terlibat (kardinalitas relasi biner) dapat bersifat :
a. Relasi 1-1 (one-to-one relationship).
Adalah satu entiti anggota gugus diasosiasikan dengan tepat satu entiti
anggota gugus yang lain.
b. Relasi 1-banyak (one-to-many relationship).
Adalah satu entiti anggota gugus diasosiasikan dengan satu atau lebih
entiti anggota gugus yang lain. Sebaliknya satu entiti anggota gugus
yang lain tersebut diasosiasikan dengan tepat satu entiti anggota gugus
pasangannya.
c. Relasi banyak-1 (many-to-one relationship).
Adalah satu entiti anggota gugus diasosiasikan dengan satu atau lebih
entiti anggota gugus yang lain dan berlaku pula sebaliknya.
4.8. Menterjemahkan ERD ke Tabel
4.9. Tipe file.
Database dibentuk dari kumpulan file. File di dalam pemrosesan aplikasi
dapat dikategorikan ke dalam beberapa tipe, diantaranya yaitu sebagai
berikut :
1. File induk (master file).
Didalam aplikasi, file ini merupakan file yang penting. File ini tetap
terus ada selama hidup dari sistem informasi. File induk dapat dibedakan
lagi menjadi :
a. File induk acuan (reference master file), yaitu file induk yang
recordnya relatif statis, jarang berubah nilainya. Contoh dari file
ini adalah file daftar gaji, file daftar matakuliah.
b. File induk dinamik (dynamic master file), yaitu file induk yang nilai
dari record-recordnya sering berubah atau sering dimutakhirkan
(updated) sebagai akibat dari suatu transaksi. Contoh file ini adalah file induk persediaan, file induk langganan dan lain sebagainya.
2. File transaksi (transaction file).
File transaksi disebut juga dengan nama file input (input file).
File ini digunakan untuk merekam data hasil dari suatu transaksi yang
terjadi. Misalnya nilai unit suatu barang dapat diketahui dari file
induk persediaan. File induk ini hanya menunjukkan status unit akhir
dari barang yang dimaksud. Sedang uni akhir ini berasal dari transaksi-
transaksi yang pernah terjadi. Untuk melihat transaksi-transaksi yang
mempengaruhi nilai di file induk, maka dapat dilihat pada file
transaksinya. Contoh file transaksi yang lain adalah file transaksi
penjualan yang berisi data tentang transaksi penjualan yang terjadi.
Biasanya file transaksi memuat rekaman tanggal dari transaksinya yang
menunjukkan kapan transaksi tersebut terjadi.
3. File laporan (report file).
File ini disebut juga dengan file output (output file), yaitu file yang
berisi dengan informasi yang akan ditampilkan. File ini dibuat untuk
mempersiapkan pembuatan suatu laporan dan biasanya dilakukan bila
printer belum siap atau masih digunakan oleh proses yang lain.
4. File sejarah (history file).
File sejarah dibuat judan dengan file arsip (archival file), yaitu file
yang berisi dengan data masa lalu yang sudah tidak aktif lagi, tetapi
perlu disimpan untuk keperluan mendatang.
5. File pelindung (backup file).
File pelindung merupakan salinan dari file-file yang masih aktif di
database pada suatu saat tertentu. File ini digunakan sebagai cadangan
atau pelindung bila file database yang aktif rusak atau hilang.
6. File kerja (working file).
File kerja disebut juga dengan nama file sementara (temprorary file)
atau scratch file. File ini dibuat oleh suatu proses program secara
sementara karena memori komputer tidak mecukupi atau untuk menghemat
pemakaian memori selama proses dan akan dihapus bila proses telah
selesai.
4.10. Akses dan organisasi file.
Akses file (access file) adalah suatu metode yang menunjukkan bagaimana
suatu program komputer akan membaca record-record dari suatu file.
File dapat diakses dengan dua cara yaitu secara urut (sequential access)
atau secara langsung (direct access atau random access). Metode akses urut
(sequential access method) dilakukan dengan membaca atau menulis suatu
record di file dengan membaca terlebih dahulu mulai dari record pertama,
urut sampai dengan record yang diinginkan. Metode akses langsung (direct
access method) dilakukan dengan cara langung membaca record pada posisinya
di file tanpa membaca dari record pertama terlebih dahulu.
Organisasi file adalah pengaturan dari record secara logika didalam file
dihubungkan satu dengan yang lainnya. File dapat diorganisasikan secara
urut (sequential organization) atau secara acak (random organization).
Walaupun organisasi file dan pengaksesan file dapat dipandang secara
terpisah, tetapi biasanya pembahasan mengenai organisasi file menyangkut
keduanya, yaitu sebagai berikut :
a. File urut (sequential file) merupakan file dengan organisasi urut
(sequential organization) dengan pengaksesan secara urut (sequential
access).
b. File urut berindeks (indexed sequential file) atau sering disebut dengan
ISAM (indexed sequential access method) merupakan file dengan organisasi
urut (sequential organization) dengan pengaksesan secara langsung
(direct access).
c. File akses langsung (direct access file) atau disebut dengan file alamat
langsung (direct address file) merupakan file dengan organisasi acak
(random organization) dengan pengaksesan langsung (direct access).
Organisasi file seperti ini disebut dengan organisasi file tradisional atau
konvensional, karena telah ada sebelum struktur database dikembangkan.
Organisasi file database dapat berbentuk struktur data berjenjang
(hierarchical data structure), struktur data jaringa (network data structure)
dan struktur data hubungan (relational data structure). Struktur data
hubungan merupakan organisasi file database yang terbaru dan mudah dipahami.
Struktur data hubungan mempunyai karakteristik sebagai berikut :
a. File dalam bentuk tabel yang persis dengan file urut.
b. Hubungan antara record didasarkan pada nilai dari field kunci, bukan
berdasarkan alamat atau pointer.
Struktur data hubungan makin banyak digunakan pada paket-paket DBMS, seperti
misalnya Dbase, Foxbase, Sql dan sebagainya.
4.11. Langkah-langkah desain database.
Untuk tahap desain database yang perlu dilakukan adalah mengidentifikasi
terlebih dahulu file-file yang diperlukan dalam sistem informasi yang
dibangun. File-fila database yang dibutuhkan oleh sistem dapat dilihat pada
desain model yang digambarkan dalam bentuk diagram arus data (DFD).
Langkah-langkah desain database secara umum adalah sebagai berikut :
a. Menentukan kebutuhan file database untuk sistem yang baru.
File yang dibutuhkan dapat ditentukan dari DAD sistem baru yang telah
dibuat.
b. Menentukan parameter daru file database.
Setelah file-file yang dibutuhkan telah dapat ditentukan, maka parameter
dari file selanjutnya juga dapat ditentukan. Parameter tersebut, meliputi:
· Tipe dari file : file induk, file transaksi, file sementara (temporary).
· Media dari file : hardisk, disket, pita magnetik, CD.
· Organisasi dari file : fila sequential, random, berindek.
· Field kunci dari file.
Analis sistem dapat menggunakan formulir berikut untuk mengidentifikasi file
database yang akan didesain, sebagai berikut :
Tabel 4.6 : Tabel identifikasi kebutuhan file.
Tabel 4.7 : Tabel identifikasi atribut (field) dalam sebuah file.
window.google_render_ad();