1. Konsep Perancangan Database
Basis data (database) merupakan kumpulan dari data yang saling berhubungan dengan yang lainnya, tersimpan di perangkat keras komputer dan digunakan perangkat lunak untuk memanipulasinya. Database merupakan salah satu komponen yang penting dalam sistem informasi, karena merupakan basis dalam menyediakan informasi bagi para pemakai. Penerapan database dalam sistem informasi disebut dengan database system. Sistem basis data (database system) adalah suatu sistem informasi yang mengintegrasikan kumpulan dari data yang saling berhubungan satu dengan yang lainnya dan membuatnya tersedia untuk beberapa aplikasi yang bermacam-macam didalam suatu organisasi.Dengan sistem basis data ini tiap-tiap orang atau bagian dapat memandang database dari beberapa sudut pandang yang berbada. Bagian kredit dapat memandangnya sebagai data piutang, bagian penjualan dapat memandangnya sebagai data penjualan, bagian personalia dapat memandangnya sebagai data karyawan, bagian gudang dapat memandangnya sebagai data persediaan.
Semuanya terintegrasi dalam sebuah data yang umum. Berbeda dengan sistem pengolahan data tradisional, sumber data ditangani sendiri-sendiri untuk tiap aplikasinya.
1.1. Perancangan Database
Dalam membuat suatu database diperlukan suatu langkah atau tahapan suoaya pengorganisasian file dapat menjadi lebih baik. Langkah utama tersebut adalah menentukan tipe-tipe file.
1. Basis data dibentuk dari suatu kumpulan file. File dalam pemrosesan transaksi dapat digolongkan sebagai berikut :
§ File induk (Master file)
§ File transaksi (transaction file) § File laporan (report file) § File sejarah (history file) § File pelindung (backup file) § File kerja (working file)
2. Membuat akses dan organisasi file
Akses 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 urut 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 dilakukan dengan cara langsung membaca record pada posisinya di file tanpa membaca dari record pertama terlebih dahulu.
Organisasi file adalah pengaturan dari suatu record secara logika dalam file dihubungkan satu dengan lainnya. File dapat diorganisasikan secara urut atau secara acak. Walaupun organisasi file dan pengaksesan file dapat dipandang secara terpisah, tetapi biasanya pembahasan mengenai organisasi file menyangkut keduanya, yaitu sebagai berikut :
§ File urut merupakan file dengan organisasi urut dengan pengaksesan secara urut pula. § File urut berindeks atau sering disebut ISAM (Indexed Sequential Access Method)
merupakan file dengan organisasi secara urut dengan pengaksesan secara langsung. § File akses langsung atau disebut juga dengan file alamat langsung merupakan file
dengan organisasi acak dengan pengaksesan secara langsung.
1.2. Manajemen Database
Sistem ini merupakan perangkat lunak yang mengatur proses pengelolaan database. Pengelolaan ini meliputi pembuatan database, akses terhadap database serta penyimpanan data dalam database.
Sedangkan pengertian dari database adalah sekumpulan file-file yang paling berhubungan satu sama lain atau beberapa kunci penghubung, tersimpan dalam media penyimpanan diluar memori komputer. Media simpan ini dapat berupa disket, Hardisk. Database dapat dinyatakan sebagai suatu sistem yang memiliki karakteristik, antara lain : § Merupakan suatu kumpulan "interrelated data" yang disimpan bersama tanpa
menggangu satu sama lain atau membentuk kerangkapan data.
§ Kumpulan data dalam database dapat digunakan oleh sebuah program aplikasi lebih secara optimal.
§ Penambahan data baru, modifikasi dan pengambilan kembali dari data dapat dilakukan dengan mudah dan terkontrol.
§ Data merupakan suatu sumber yang sangat berguna bagi hampir di semua organisasi. Dengan tersedianya data yang melimpah, maka masalah pengaturan data secara efektif menjadi suatu hal yang sangat penting dalam pengembangan sistem informasi manajemen. Oleh karena itu, maka tujuan dari diadakannya pengaturan data adalah sebagai berikut : Menyediakan penyimpanan data untuk dapat digunakan oleh organisasi saat sekarang dan masa yang akan datang.
§ Cara pemasukan data sehingga memudahkan tugas operator dan menyangkut pula waktu yang diperlukan oleh pemakai untuk mendapatkan data serta hak-hak yang dimiliki terhadap data yang ditangani.
§ Pengendalian data untuk setiap siklus agar data selalu "up to date" dan dapat mencerminkan perubahan spesifik yang terjadi di setiap sistem.
§ Pengamanan data terhadap kemungkinan penambahan, modifikasi, pencurian dan gangguan-gangguan lain.
1.3. Teknik Perancangan Database
Dalam perancangan database ini digunakan untuk merancang database berskala luar, adaput teknik yang dikenal dua macam cara :
§ Teknik Normalisasi
Cara ini dimulai dari dokumen dasar yang sudah ada pada sistem atau sudah dipakai sistem tersebut, data-data pada dokumen dasar tersebut dipisah-pisah menjadi file-file yang tiap field pada file tersebut bergantung penuh pada kunci utama (field kunci) yang biasanya dikenal dengan bentuk normal ketiga. Kemudian setiap file dalam database tersebut ditentukan hubungannya dengan file-file yang lain dengan cara memasang field tamu pada file-file anak atau file konektor.
§ Teknik Entity Relationship
Langkah ini sering digunakan pada perancangan sistem, dimulai dengan pembuatan diagram arus data yang menghasilkan kamus data yang merupakan daftar semua
elemen/field yang dibutuhkan dalam sistem terebut. Dari field-field tersebut dipilih field kunci yang bersifat unik artinya keseluruhan record dapat dicari dari record tersebut, kemudian baru dibuat file-file berdasar kunci record tersebut yang mana elemen/field dalam field tersebut bergantung penuh dengan filed kunci tersebut. Setelah membuat tabel baru ditentukan relasi dari tiap tabel tersebut seperti halnya teknik normalisasi.
1.4. Data Flow Diagram (DFD)
Untuk memudahkan penggambaran suatu sistem yang ada atau sistem yang baru yang akan dikembangkan secara logika tanpa memperhatikan lingkungan fisik dimana data tersebut mengalir atau lingkungan fisik dimana data tersebut akan disimpan, maka kita menggunakan diagram arus data atau Data Flow Diagram (DFD).
Diagram alur data merupakan alat yang cukup populer sekarang, karena dapat menggambarkan arus data di dalam suatu sistem dengan terstruktur dan jelas. Dalam menggambarkan sistem perlu dilakukan pembentukan simbol, berikut ini simbol-simbol yang sering digunakan dalam diagram alur data (DAD) :
1. External entity (kesatuan luar) atau boundary (batasan)
Setiap sistem pasti memiliki batas sistem yang memisahkan suatu sistem dengan lingkungan luarnya. Sistem akan menerima input dan menghasilkan output bagi lingkuangan luarnya. Kesatuan luar merupakan kesatuan di lingkungan luar sistem yang dapat berupa orang, organisasi atau sistem lain yang berada di lingkungan luarnya yang akan memberikan input serta menerima output dari sistem. Suatu kesatuan luar dapat disimbolkan dengan notasi kotak dapat dilihat pada gambar berikut :
2. Data flow (aliran data)
Arus data pada diagram arus data diberi simbol panah. Arus data ini mengalir di antara proses, penyimpanan data dan kesatuan luar. Arus data ini menunjukkan arus atau aliran data yang dapat berupa masukan untuk sistem atau hasil dari proses sistem dan dapat berbentuk sebagai berikut ini :
§ Formulir atau dokumen yang digunakan. § Laporan tercetak yang dihasilkan oleh sistem.
§ Tampilan atau output di layar komputer yang dihasilkan oleh sistem. § Masukan oleh komputer.
§ Komunikasi ucapan. § Surat-surat atau memo.
§ Data yang dibaca atau direkam pada suatu file. § Surat isian yang dicatat pada buku agenda.
§ Transmisi data dari satu komputer ke komputer yang lain.
3. Proses
Suatu proses adalah kegiatan atau kerja yang dilakukan orang, mesin atau komputer dari hasil suatu arus data yang masuk ke dalam proses untuk dihasilkan arus data yang akan keluar dari proses. Untuk physical data flow diagram (PDFD), proses dapat dilakukan oleh orang, mesin atau komputer. Sedangkan untuk logical data flow diagram (LDFD), suatu proses hanya menunjukkan proses dari komputer. Suatu proses dapat ditunjukkan dengan simbol lingkaran atau dengan simbol empat persegi panjang dengan sudut-sudutnya yang tumpul. Berikut ini simbol untuk proses :
Setiap proses harus diberi penjelasan yang lengkap meliputi : Identifikasi proses
Identifikasi ini umumnya berupa angka yang menunjukkan nomor acuan dari proses dan ditulis pada bagian atas simbol proses
Nama Proses
Nama proses menunjukkan apa yang dikerjakan oleh proses tersebut. Nama proses harus jelas dan lengkap mengggambarkan kegiatan proses. Nama proses biasanya berbentuk suatu kalimat yang diawali dengan kata kerja dan letaknya berada di bawah identifikasi proses.
Pemroses
Untuk PDFD yang menunjukkan proses tidak hanya proses dari komputer, tetapi juga proses manual, seperti proses yang dilakukan oleh orang, mesin, atau komputer, maka pemroses harus ditunjukkan. Pemroses ini menunjukkan siapa dan dimana suatu proses
dilakukan. Untuk LDFD yang prosesnya hanya menunjukkan proses komputersaja, maka pemroses tidak perlu disebutkan. Untuk LDFD, bila pemroses akan disebutkan dapat juga untuk menyebutkan nama dari program yang melakukan prosesnya. Keterangan pemroses ini dapat diletakkan di bawah nama proses.
Gambar 1. Diagram Simbol DFD
1.5. Menggunakan High-Level Conceptual Data Model (CDM)
Dalam menggunakan high-level conceptual data model terdiri dari beberapa langkah, yaitu: ◊ Pengumpulan dan analisis kebutuhan, meliputi kegiatan:
- Interview user dan mengerti kebutuhan dokumentasi data mereka - Menspesifikasi kebutuhan fungsional dari aplikasi
◊ Membuat skema konseptual database menggunakan high-level conceptual data model, meliputi:
- Mendeskripsikan secara singkat kebutuhan data dari user dan termasuk deskripsi detil dari tipe entitas, relationship dan constraint.
- Menspesifikasi operasi high-level user yang didentifikasi selama analisis fungsional. High level data model mudah dimengerti dan digunakan untuk berkomunikasi dengan user yang tidak mengerti secara teknis. Juga dapat digunakan sebagai referensi untuk meyakinkan bahwa semua kebutuhan user dapat dipenuhi tanpa terjadi konflik.
◊ Mengimplementasikan database menggunakan DBMS disebut pemetaan model data - Skema konseptual ditransformasikan dari high-level data model ke implementasi
model data. ◊ Fase desain fisik,
- Menspesifikasi struktur penyimpanan internal, path akses dan organisasi file untuk database yang dispesifikasi.
- Mendesain program aplikasi dan mengimplementasikan sebagai transaksi databse berhubungan dengan spesifikasi transaksi high-level.
Gambar 2. Penyederhanaan dari proses desain database.
High level data model mudah dimengerti dan digunakan untuk berkomunikasi dengan user yang tidak mengerti secara teknis. Juga dapat digunakan sebagai referensi untuk meyakinkan bahwa semua kebutuhan user dapat dipenuhi tanpa terjadi konflik.
◊ Mengimplementasikan database menggunakan DBMS disebut pemetaan model data - Skema konseptual ditransformasikan dari high-level data model ke implementasi
model data. ◊ Fase desain fisik,
- Menspesifikasi struktur penyimpanan internal, path akses dan organisasi file untuk database yang dispesifikasi.
- Mendesain program aplikasi dan mengimplementasikan sebagai transaksi databse berhubungan dengan spesifikasi transaksi high-level.
1.6. Contoh Perancangan Aplikasi Database
Uraian berikut ini adalah sebuah contoh aplikasi database COMPANY yang digunakan untuk ilustrasi konsep model ER dan penggunaannya dalam desain skema. Kita mendaftar kebutuhan data untuk database dan kemudian membuat skema konseptual step by step seperti dalam konsep pemodelan model ER. Database COMPANY terdiri dari employees, departments dan projects. Setelah fase pengumpulan dan analisis kebutuhan, desainer database menyatakan deskripsi dari “miniworld”- bagian dari perusahaan yang direpresentasikan dalam database.
1. Company diorganisasikan dalam departemen-departemen. Masing-masing departemen mempunyai name yang unik, number yang unik dan employee tertentu tang me-manage departemen. Sebuah departemen mempunyai beberapa lokasi.
2. Sebuah department mengontrol sejumlah projects, masing-masing mempunyai name yang unik, number yang unik dan lokasi tunggal.
3. Kita menyimpan masing-masing name employee, social security number, address, salary, sex dan birth date. Seorang employee bekerja pada satu departemen tetapi boleh bekerja pada beberapa project, dimana tidak perlu dikontrol oleh departemen yang sama. Kita juga mempunyai jumlah jam per minggu dimana seorang employee bekerja pada masing-masing project. Kita juga mencatat supervisor langsung dari masing-masing employee.
4. Kita ingin mencatat dependents dari masing-masing employee untuk keperluan asuransi. Kita mempunyai untuk masing-masing dependent first name, sex, birth date dan relationship ke employee.
Pada gambar 3.2 menunjukkan bagaimana skema untuk aplikasi database ditampilkan dalam notasi grafik yang dikenal dengan ER diagram. Penjelasan tentang notasi ER diagram adalah Sebagai berikut.
Gambar 3. Skema diagram ER untuk database perusahaan
1.7. Entity Types, Entity Sets, Attributs dan Keys
Model ER mendeskripsikan data sebagai entitas, relationship dan attribut. 1. Entities dan Attributes
Entitas dan atributnya. Object dasar yang di representasikan oleh model ER adalah entity yang merupakan “sesuatu’ dalam dunia nyata dengan keberadaan yang bebas. Sebuah entity dapat berupa object dengan eksistensi fisik – seperti manusia, mobil, rumah atau employee- atau dapat juga sebuah object secara konseptual- seperti company, sebuah job, atau sebuah mata kuliah. Masing0masing entity mempunyai attribut yang merupakan sifat-sifat tertentu yang menggambarkan entity tersebut. Contoh entity employee dapat digambarkan dengan employee name, age, address, salary dan job. Sebuah bagian entity akan mempunyai sebuah nilai untuk masing-masing attribut ini. Nilai-nilai attribut yang
menggambarkan masing-masing entity akan menjadi bagian besar dari penyimpanan data dalam database.
Pada gambar 3.3 menunjukkan dua entity dan nilai dari attribut mereka. Entity employee e1 mempunyai empat attribut: Name, Address, Age dan HomePhone; nilai-nilai mereka adalah “John Smith,””2311 Kirby, Houston, Texas 77001,””55,” dan “713-749-2630,”.Entity company c1 mempunyai tiga attribut: Name, Headquarters dan president; nilai mereka masing-masing adalah “Sunco Oil,” “Houston.” Dan “John Smith,”.
Gambar 4. Dua entitas employee e1 dam company c1 beserta atributnya
Beberapa tipe dari attribut terjadi dalam model ER: simple versus Composite; Single-valued versus multivalued; dan stored versus derived. Juga diperkenalkan konsep null value untuk sebuah attribut.
Composite Versus Simple (Atomic) Attribut. Attribut Composite dapat diturunkan ke dalam sub bagian yang lebih kecil, yang merepresentasikan attribut yang lebih dasar dengan arti yang bebas. Contoh, attribut addres dari entity employee pada gambar 3.3 dapat dibagi ke dalam StreetAddress, City, State dan Zip, dengan nilai “2311 Kirby,” “Houston,” “Texas,” dan “77001,”. Attribut yang tidak dapat dibagi disebut attribut simple atau atomic. Attribute composit dapat membentuk sebuah hierarki; contoh: StreetAddress dapat dibagi ke dalam tiga attribut simple Number, Street dan ApartmentNumber.
Atribut Single-valued Versus Multivalue. Sebagian besar atribut mempunyai single value untuk sebuah entity tertentu, sehingga disebut single-value. Contoh, Age adalah atribut single value dari person. Dalam beberapa kasus sebuah atribut dapat mempunyai satu set nilai untuk entity yang sama. Contoh, atribut warna untuk sebuah mobil atau atribut
CollegeDegree untuk person. Mobil dengan satu warna mempunyai single value dan mobil dengan dua warna memiliki dua value. Serupa dengan itu satu person tidak harus mempunyai sebuah college degree, person yang lain dapat mempunyai satu college degree dan orang yang lain dapat memiliki dua atau lebih degree. Sedemikian sehingga person yang berbeda dapat mempunyai sejumlah nilai yang berbeda untuk atribut college degree. Dengan demikian atribut tersebut disebut multivalue. Sebuah atribut multivalue dapat batas mempunyai batas atas dan batas bawah pada sejumlah nilai yang diijinkan untuk masing-masing entity. Contoh, atribut color dari sebuah mobil dapat berada diantara nilai satu dan tiga, bila diasumsikan bahwa sebuah mobil dapat mempunyai paling banyak tiga warna. Atribut Stored versus Derived. Dalam beberapa kasus, value dari dua atau lebih atribut adalah berhubungan - contoh, atribut age dan BirthDate dari person. Untuk entity person tertentu, value dari age dapat ditentukan dari date hari ini dan value dari BirthDate person tersebut. Atribut age oleh karenanya disebut dengan derived atribut dan dikatakan derivable dari atribut BirthDate, yang disebut Store Atribut. Beberapa value atribut dapat diturunkan dari entitas yang berhubungan; contoh; atribut NumberEmployee dari entity departmen dapat diturunkan dengan menhitung jumlah dari employee yang mempunyai hubungan (working for) dengan departemen itu.
Value Null. Dalam beberapa kasus sebuah entity boleh tidak mempunyai nilai tertentu untuk sebuah atribut. Contoh, atribut ApartmentNumber dari sebuah alamat diaplikasikan hanya untuk alamat yang ada di dalam gedung apartemen dan tidak ke tipe tempat tinggal lain seperti rumah single family. Serupa dengan itu, atribut CollegeDegree diaplikasikan hanya untuk person yang mempunyai college degree. Untuk situasi yang demikian, sebuah value khusus yang disebut null dibuat. Sebuah alamat dari single family home akan mempunyai value null untuk atribut ApartmentNumber dan seorang person yang tidak memiliki college degree akan mempunyai value null untuk atribut CollegeDegrees. Null dapat juga digunakan jika kita tidak mengetahui value dari atribut entity tertentu. Contoh, bila kita tidak mengetahui home phone dari “John Smith” maka arti dari tipe berbentuk null adalah not applicable, atau tidak diketahui.
Atribut Complex. Perlu dicatat bahwa atribut composite dan multivalue dapat di-nested ke dalam arbitrary. Kita dapat merepresentasikan arbrtrary nesting dengan mengelompokkan komponen dari atribut composite diantara kurung () dan memisahkan komponen tersebut dengan koma, serta menampilkan multivalue atribut di antara kurung kurawal {}. Atribut demilikian disebut atribut complex. Contoh, bila seorang person dapat mepunyai lebih dari
satu residence dan masing-masing residence dapat mempunyai banyak phone, sebuah atribut AddresPhone untuk entity person dapat dispesifikasi sebagai berikut.
{AddressPhone({Phone(AreaCode,PhoneNumber)},
Address(StreetAddress(Number,Street,ApartmentNumber),City,State,Zip))}
Gambar 5. Contoh Atribut Kompleks
2. Entity Types, Entity Sets, Keys, and Value Sets
Tipe entity dan himpunan entity. Sebuah database biasanya mengandung sekelompok entity yang serupa. Contoh, Sebuah perusahaan yang mempekerjakan ratusan employee mungkiningin menyimpan informasi yang serupa untuk masing-masing employee. Entity employee ini berbagi atribut yang sama tetapi masing-masing enetity mempunyai value sendiri-sendiri untuk masing-masing atribut. Sebuah tipe entity (Entity Type) mendefinisikan kumpulan entity yang mempunyai atribut yang sama. Masing-masing entity type dalam database dalam database digambarkan dengan nama dan atribut. Gambar 3.6 menunjukkan dua tipe entity yaitu Employee dan company, dan daftar atribut dari masing-masing entity tersebut. Kumpulan dari semua entity dari sebuah tipe entity tertentu dalam database pada suatu waktu tertentu disebut kumpulan entity (entity set). Entity set biasanya diacu dengan menggunakan anma yang sama seperti tipe entity. Contoh; employee mengacu kepada kedua tipe entity yang berarti kumpulan semua entity employee pada saat ini dalam database.
Sebuah tipe entity direpresentasikan dalam ER diagram dengan kotak persegi panjang tertutup dengan nama tipe entity. Nama Atribut berada dalam bentuk oval dan dihubungkan dengan nama entitynya dengan garis lurus. Atribut composite dihubungkan dengan atribut komponen mereka dengan garis lurus. Atribut multivalue ditampilkan dengan dobel oval. Sebuah tipe entity menggambarkan skema atau intension untuk sebuah kumpulan dari entity yang berbagi struktur yang sama. Kumpulan entity dari tipe entity tertentu dikelompokkan dalam himpunan entity (entity set) yang juga disebut extension dari tipe entity.
Atribut key dari sebuah tipe entity constraint yang penting dari sebuah entity dari sebuah entity adalah key atau constrain yang unik pada sebuah atribut. Sebuah entity biasanya mempunyai atribut dimana nilainya adalah berbeda untuk masing-masing individu entity dalam sebuah kumpulan. Atribut demikian disebut dengan atribut key dan nilainya dapat digunakan untuk mengidentifikasikan masing-masing entity secara unik. Contoh : attribut NAME adalah key dari tipe entity COMPANY dalam gambar 3.6, karena tidak ada dua perusahaan yang diijinkan untuk mempunyai nama yang sama. Untuk tipe entity PERSON atribut key yang dipakai adalah Social Security Number. Kadang-kadang beberapa atribut bersama-sama membentuk sebuah key, yang berarti bahwa kombinasi dari value atribut harus berbeda untuk masing-masing entity. Bila sekumpulan atribut memiliki properti seperti ini, kita dapat mendifinisikan sebuah atibut komposit yang menjadi atribut key dari tipe entity.perlu dicatat bahwa sebuah key composite haruslah minimal yaitu semua atribut komponen harus dimasukkan dalam atribut composite agar mempunyai properti yang unik. Dalam notasi diagram ER, masing-masing atribut key mempunyai nama yang bergaris bawah didalam bentuk oval.
Menspesifikasi bahwa sebuah atribut adalah key dari sebuah tipe entity berarti bahwa properti sebelumnya harus bertahan untuk setiap extension dari tipe entity. Oleh karena itu ini adalah konstrain dimana biasanya ada dua entity yang mempunyai value yang sama untuk atribut key pada saat yang sama. Ini bukanlah properti dari extension tertentu tetapi ini adalah constraint pada semua extension dari tipe entity. Constraint key ini diturunkan dari constraint miniword dimana database direpresentasikan.
Beberapa tipe entity mempunyai lebih dari satu atribut key. Contoh : atribut vehicleID dan registrasi dari tipe entity CAR (gambar 3.7) adalah key. Atribut registrotion adalah sebuah contoh key composite yang dibentuk dari dua atribut komponen sederhana. Registrotion number dan State. Sebuah entity dapat juga tidak memiliki key, yang disebut tipe weak entity.
Value set (domain, kumpulan nilai) dari atribut masing-masing atribut simple dari sebuah tipe entity dihubungkan dengan himpunan nilai (atau domain nilai), yang menspesifikasi kumpulan dari nilai yang dapat diberikan ke atribut tersebut untuk masing-masing individu entity. Dalam gambar 3.6, bila range dari age diijinkan untuk Employee antara 16 dan 70, kita dapat menspesifikasi kumpulan nilai atribut Age dan EMPLOYEE menjadi kumpulan integer antara 16 dan 70. serupa dengan itu kita dapat menspesifikasi sekelompok nilai
untuk atribut Name sebagai kumpulan string dari karakter huruf yang dipisahkan oleh karakter blank dan seterusnya. Kumpulan value tidak ditampilkan dalam ER diagram. Secara matematis atribut A dari tipe entity E yang mempunyai kumpulan nilai V didefinisikan sebagai fungsi dari E terhadap power set P(V) dari V:
A : E à P(V)
Kita mengacu terhadap value dari atribut A untuk entity e sebagai A(e). Definisi sebelumnya mencakup kedua atribut single value dan multivalue seperti null. Null value direpresentasikan oleh himpunan kosong. Untuk atribut single value , A(e) dibatasi menjadi single untuk masing-masing entity dalam E sementara itu tidaka ada batasan pada multivalue. Untuk atribut composite A, himpunan nilai V adalah Cartesian product dari P(V1),P(V2), …, P(Vn), dimana V1,V2, …,Vn adalah himpunan nilai dari atribut componen simple yang membentuk A:
V = P(V1) x P(V2) x … x P(Vn)
3. Desain Konseptual awal dari database COMPANY
Kita sekarang dapat mendefinisikan tipe entity untuk database COMPANY, yang didasarkan pada kebutuhan yang digambarkan pada bagian 3.2. Setelah mendefinisikan tipe entity dan atributnya, kita memperbaiki desain kita dalam bagian 3.4 (setelah memperkenalkan konsep relationship). Sesuai dengan daftar requirement pada bagian 3.2, kita dapat mengidentifikasi empat tipe entity yang saling berhubungan seperti gambar 3.8:
1. Tipe entity DEPARTMENT dengan atribut Name, Number, Locations, Manager dan ManagerStartDate. Locations adalah satu-satunya atribut multivalue. Kita dapat men-spesifiksibahwa Name dan Number adalah atribut Key (terpisah), karena masing-masing dispesifikasi secara unik.
2. Tipe entity PROJECT dengan atribut Name, Number, Locations dan ControlingDepartment. Nama dan Number adalah atribut key yang saling terpisah. 3. Tipe entity EMPLOYEE dengan atribut Name, SSN, Sex, Address, Salary, BirthDate,
ini tidak dispesifikasi dalam requirements. Kita harus kembali ke user untuk mengetahui bila mereka akan mengacu ke individual komponen dari nama seperti FirstName, MiddleInitial, LastName atau dari alamat.
4. Tipe entity DEPENDENT dengan atribut Employee, DependentName, Sex, BirthDate dan relationship ke employee.
Gambar 6. Desain awal dari tipe entity untuk database perusahaan
Sejauh ini kita belum merepresentasikan kenyataan bahwa seorang employee dapat bekerja pada beberapa project juga kita belum merepresentasikan jumlah jam per minggu seorang employee bekerja pada masing-masing project. Karakteristik ini di list sebagai bagian dari requirement ke tiga dalam bagian 1.5, dan dia dapat direpresentasikan dengan atribbut composit multivalue dari EMPLOYEE yang disebut WorksOn dengan komponen simple (Project, Hours).
Alternatifnya, dia dapat direpresentasikan sebagai atribut composit multivalue dari PROJECT yang disebut Workers dengan komponen simple (Employee, Hours). Kita memilih alternatif pertama dalam gambar 6 yang menunjukkan masing-masing dari tipe entity. Atribut Name dari EMPLOYEE ditunjukkan sebagai atribut composit yang disimpulkan setelah berkonsultasi dengan user.
1.8. Relationship, Tipe Relationship, Role dan Structural Constraints
Dalam gambar 6 terdapat beberapa implicit relationship diantara berbagai tipe entity. Kenyataannya kapanpun sebuah atribut dari satu tipe entity mengacu ke tipe entity yang lain, bebepara relationship muncul. Contoh, atribut Manager dari DEPARTMENT mengacu ke seorang employee yang me-manage deparment; atribut ContrllingDepartment dari PROJECT mengacu ke Department yang mengontrol project; atribut Supervisor dari EMPLOYEE mengacu ke employee lain (seseorang yang men-supervisi employee ini); atribut Department dari EMPLOYEE mengacu ke Department dimana employee bekerja;dsb. Dalam model ER referensi ini seharusnya tidak direpresentasikan sebagai atribut tetapi sebagai relationship. Skema database COMPANY akan diperbaiki dalam bagian 3.6 untuk merepresentasikan relationship secara explisit. Dalam desain awal dari tipe entity, relationship biasanya di capture dalam bentuk atribut. Ketika desain diperbaiki atribut ini dokonversi ke dalam relationships diantara tipe entity.
1. Tipe Realationship, Sets dan Instances
Sebuah tipe relationship R diantara n tipe entity E1, E2, … , En mendefinisikan sebuah himpunan asosiasi- atau himpunan relationship – diantara entity dari tipe-tipe ini. Seperti tipe entity dan himpunan entity, sebuah tipe relationship dan hubungannya dengan himpunan relationship biasanya diacu dengan nama yang sama R. Secara matematis himpunan R adalah sebuah himpunan dari relationship instance (suatu relationship) ri, dimana masing-masing ri mengasosiasikan n entity individu (e1, e2, …, en), dan masing-masing entity ej dalam ri adalah sebuah anggota dari tipe entity Ej, 1 ≤ j ≤ n. Oleh karenanya sebuah tipe relationship adalah sebuah relasi matematis pada E1, E2, … , En, atau alternatifnya dia dapat didefinisikan sebagai sebuah himpunan bagian dari cartesian product E1 x E2 x … x En. Masing-masing dari tipe entity E1, E2, … , En dikatakan berpartisipasi (participate) di dalam tipe relationship R, dan serupa dengan hal itu, masing-masing individu entity e1, e2, …, en dikatakan berpartisipasi dalam suatu relationship ri = (e1, e2, …, en).
Secara informal masing-masing relationship instance ri dalam R adalah sebuah asosiasi dari entity, dimana asosiasi memasukkan dengan tepat satu entity dari masing-masing tipe entity yang berpartisipasi. Dengan demikian masing-masing relationship instance ri merepresentasikan kenyataan bahwa entity yang berpartisipasi dalam ri dihubungkan dengan beberapa jalan dalam menghubungan situasi miniworld. Contoh, perhatikan sebuah
tipe relationship WORK_FOR antara dua entity EMPLOYEE dan DEPARTMENT, yang mengasosiasikan masing-masing employee dengan department dari employee bekerja. Masing-masing relationship instance dalam himpunan relationship WORK_FOR menghubungkan satu entity employee dan satu entity department. Gambar 3.9 mengilustrasikan contoh ini, dimana masing-masing instansi relationship ri ditunjukkan menghubungkan entity employee department yang berpartisipasi dalam ri. Miniworld dalam gambar 3.9 employee e1, e3 dan e6 bekerja untuk department d1; e2 dan e4 work for d2; serta e5 dan e7 work for d3.
Dalam diagram ER tipe relationship di tampilkan dengan bentuk diamond, yang dihubungkan dengan garis lurus ke kotak persegipanjang yang merepresentasikan tipe entity yang berpartisipasi. Nama relationship ditampilkan dalam kolat diamond.
Gambar 7. Beberapa instance darri relasi WORKS_ON antara Empolyee dan Deparrtement
2. Relationship Degree, Role Name dan Recursive Relationships
Degree dari tipe relationship adalah jumlah dari tipe entity yang berpartisipasi. Oleh karenanya, relationship WORK_FOR adalah berderajat dua. Tipe relationship ber derajat dua disebut binary dan berderajat tiga disebut ternary. Contoh dari ternary relationship adalah SUPPLY seperti ditunujukkan gambar 8, dimana masing-masing instansi dari relationship ri menghubungkan tiga entity – seoarng suplier s, part p, dan project j – dimana s
mensuplai part p untuk project j. Relationship secara umum dapat terdiri dari beberapa derajat, tetapi yang paling umum adalah relationship binary. Relationship yang lebih tinggi umumnya lebih kompleks daripada relationship binary.
Gambar 8. Beberapa relasi instance dari SUPPLY secara ternary relationship
Relationship sebagai atribut. Kadang lebih enak untuk berfikir bahwa tipe relationship dinyatakan dalam atribut. Perhatikan tipe relationship WORKS_FOR pada gambar 3.9. Dia dapat kita pikirkan sebagai sebuah atribut Department dari tipe entity EMPLOYEE dimana nilainya untuk masing-masing entity employee adalah entity department dimana employee bekerja. Oleh karenanya himpunan value untuk atribut department ini adalah himpunan dari semua entity DEPARTMENT. Ini adalah apa yang kita kertjakan di dalam gambar 3.8 ketika kita menspesifikasi desain awal dari tipe entity EMPLOYEE untuk database COMPANY. Bagaimanapun ketika kita berfikir relationship binary sebagai atribut, kita selalu mempunyai dua pilihan. Dalam contoh ini alternatifnya adalah memikirkan atribut multivalue Employee dari tipe entity DEPARTMENT dimana nilainya untuk masing-masing entity department adalah himpunan dari entity employee yang bekerja untuk depertemen tersebut. Himpunan nilai dari atribut Employee adalah himpunan entity EMPLOYEE. Dua atribut ini Department dari EMPLOYEE atau Employee dari DEPARTMENT dapat merepresentasikan tipe relationship WORKS_FOR. Bila keduanya direpresentasikan, mereka adalah constraint yang berlawanan satu sama lain.
Role Name dan Recursive Relationship. Masing-masing tipe entity yang berpartisipasi dalam tipe relationship memainkan tugas (Role) tertentu dalam relationship. Nama role menandai role dimana sebuah entity yang berpartisipasi dari tipe entity bermain dalam masing-masing insatnsi relationship, dan membantu untuk menjelaskan arti dari relationship. Contoh, dalam tipe relationship WORK_FOR , EMPLOYEE memainkan tugas dari employee atau worker dan DEPARTMENT memainkan tugas dari department atau employer.
Role name secara teknis tidak perlu dalam tipe relationship dimana semua tipe entity yang berpartisipasi adalah berbeda, oleh karena masing-masing nama tipe entity dapat digunakan sebagai role name. Tetapi, dalam banyak kasus tipe entity berpartisipasi lebih dari sekali dalam tipe relationship dalam role yang berbeda. Dalam banyak kasus juga, role name menjadi penting untuk membedakan arti dari partisipasi masing-masing. Tipe relationship demikian disebut recursive relationship, dan gambar 9 menunjukkan contoh untuk ini. Tipe relasi SUPERVISION menghubungkan seorang employee ke seorang supervisor, dimana keduanya entity employee dan supervisor adalah anggota dari dari tipe entity EMPLOYEE yang sama. Oleh karenanya tipe entity EMPLOYEE berpartisipasi dua kali dalam SUPERVISION. Sekali dalam role sebagai supervisor (atau boss), dan sekali dalam role sebagai supervisee (atau subordinat). Masing-masing instansi relationship ri dalam SUPERVISION menghubungkan dua entity employee ej dan ek, dimana yang satu memainkan role supervisor dan yang lain memainkan role supervisee. Gambar 9, garis ditandai dengan “1“ merepresentasikan role supervisor, dan tanda “2” merepresentasikan role supervisee; oleh karenanya e1 mensupervisi e2 dan e3; e4 mensupervisi e6 dan e7; serta e5 mensupervisi e1 dan e4.
Gambar 9. Relasi secara rekursif dari SUPERVISION, dimana entity EMPLOYEE memainkan role sebagai Supervisor (1) dan yanng disupervisi (2)
3. Constraints pada tipe Relationship
Tipe Relationship biasanya mempunyai constrain-constraint yang membatasi kombinasi yang mungkin dari entity yang boleh berpartisipasi dalam menghubungkan himpunan relasi. Constraint-constrint ini ditentukan dari siatuasi miniworld yang merepresentasikan relationship. Seperti gambar 3.9, bila company mempunyai rule dimana masing-masing employee harus bekerja untuk tepat satu department, maka kita akan mendeskripsikan constraint ini dalam skema. Kita dapat membedakan dua tipe utama dari constrain relationship: perbandingan cardinalitas dan partisipasi.
Cardinality Ratio untu Relationship Binary. Cardinality Ratio untuk relationship binary menspesifikasi jumlah dari instansi relationship dimana sebuah entity dapat berpartisipasi di dalamnya. Contoh, dalam tipe relationship binary WORKs_FOR, DEPARTMENT:EMPLOYEE adalah perbandingan kardinalitas 1:N, yang berarti bahwa masing-masing department dapat dihubungkan ke (yaitu, employs) sejumlah employee, tetapi seoarang employee dapat direlasikan hanya ke (work for) satu department saja. Perbandingan kardinalitas yang mungkin untuk relationship binary adalah 1:1, 1:N, N:1 dan M:N.
Contoh relationship binary 1:1 adalah MANAGE (gambar 10), yang menghubungkan entity department ke employee yang me-manage departement tersebut. Ini merepresentasikan constraint miniworld dimana seorang employee dapat me-manage hanya satu department dan bahwa department hanya mempunyai satu manager.
Gambar 10. Relasi 1:1 dari MANAGES, dengan partisipasi secara parsial dari EMPLOYEE dan semua partisipan dari DEPARTEMENT
Constraint Partisipasi dan keberadaan Dependency. Constraint partisipasi men-spesifikasi apakah keberadaan dari suatu entity bergantung pada relasinya dengan entity lain melalui tipe relationship. Ada dua tipe dari constraint partisipasi, total dan parsial. Bila sebuah kebijakan company menyatakan bahwa setiap employee harus bekerja untuk sebuah department, maka sebuah entity employee dapat exist hanya bila dia berpartisipasi dalam instansi relationship WORKS_FOR (gambar3.9). Kondisi demikian, partisipasi EMPLOYEE dalam WORKS_FOR disebut partisipasi total,yang berarti bahwa setiap entity dalam “himpunan total” dari entity employee harus direlasikan ke entity department melalui WORKS_FOR. Partisipasi total disebut juga existence dependency.
4. Atribut-atribut dari Tipe Relationship
Tipe relationship dapat juga mempunyai atribut, serupa dengan tipe entity. Contoh, Untuk mencatat jumlah jam per minggu dimana seorang employee bekerja pada project tertentu,
kita dapat memasukkan sebuah atribut Hours untuk tipe relationship WORKS_ON pada gambar 11.
Gambar 11. Relasi M:N dari WORKS_ON antara EMPLOYEE dan PROJECT
Perlu dicatat bahwa atribut tipe relationship 1:1 atau 1:N dapat dipindahkan ke satu dari tipe entity yang berpartisipasi. Contoh, atribut StratDate untuk relationship MANAGES dapat menjadi atribut dari EMPLOYEE atau DEPARTMENT meskipun secara konseptual dia dimiliki oleh TO MANAGE. Ini dikarenakan MANAGE adalah relationship 1: 1 sehingga setiap entity department atau employee berpartisipasi dalam sebagian besar instansi relationship. Oleh karenanya value dari atribut StartDate dapat ditentukan secara terpisah dengan berpartisipasi pada entity department tau dengan berpartisipasi pada entity employee (manager).
Untuk tipe relationship 1:N atribut relationship dapat dipindahkan hanya ke tipe entity pada sisi N dari relationship. Dalam tipe relationship 1:1 dan 1:N keputusan dimana sebuah atribut seharusnya ditempatkan , sebagai sebuah atribut tipe relationship atau sebagai sebuah atribut dari sebuah tipe entity partisipasi ditentukan secara subjektif oleh desainer skema. Untuk tipe relationship M:N, beberapa atribut dapat ditentukan dengan kombinasi dari enity yang berpartisipasi dalam sebuah instansi relationship, tidak oleh entity tunggal/single. Dengan demikian atribut harus dispesifikasi sebagai atribut relationship.
1.9. Tipe Entity Weak
Tipe entity yang tidak mempunyai atribut key untuk mereka sendiri disebut tipe entity lemah (weak entity types). Entity yang memiliki tipe entity weak diidentifikasi oleh hubungannya terhadap entity spesifik dari tipe entity lain dalam kombinasi dengan beberapa value atribut mereka. Kita sebut entity lain ini tipe entity pengidentifikasi atau pemilik. Tipe entity weak selalu mempunyai constraint total partisipasi (terdapat ketergantungan) karena entity weak tidak dapat diidentifikasi tanpa entity owner. Tetapi tidak setiap keberadaan dependency menghasilkan tipe entity weak.
Perhatikan tipe entity DEPENDENT, dihubungkan ke EMPLOYEE yang digunakan untuk mencatat dependent dari masing-masing employee dengan relationship 1:N (gambar 2). Atribut dari DEPENDENT adalah Name, BirthDate, Sex dan relationship (ke employee). Dua dependent dari dua employee yang berbeda , dimana memiliki value yang sama untuk Name, BirthDate, Sex dan relationship tetapi mereka adalah entity yang berbeda.. Mereka diidentifikasi sebagai entity yang berbeda hanya setelah menentukan entity employee tertentu dimana masing-masing dependent dihubungkan. Masing-masing entity employee dikatakan memiliki entity dependent yang dihubungkan dengannya.
Tipe entity lemah biasanya mempunyai partial key, yaitu sekelompok atribut yang dapat secara unik diidentifikasi sebagai entity lemah yang berhubungan dengan entity owner yang sama. Tipe entity lemah dapat juga direpresentasikan sebagai atribut kompleks (Composit, multivalue).
1.10. Perbaikan Desain ER untuk Database COMPANY
Sekarang kita bisa memperbaiki desain database pada gambar 6 dengan mengubah atribut yang merepresentasikan relationship ke dalam tipe relationship. Perbandingan kardinalitas dan constraint partisipasiuntuk masing-masing tipe relationship ditentukan dari daftar requirement. Bila beberapa perbandingan kardinalitas dependency tidak dapat ditentukan dari requirement, user harus ditanya untuk menentukan constraint struktural ini. Dalam contoh kita, kita menspesifikasi tipe-tipe relationship sebagai berikut:
1. MANAGES, sebuah tipe relationship antara EMPLOYEEE dan DEPARTMENT. EMPLOYEE berpartisipasi secara parsial, sementara partisipasi DEPARTMRNT tidak
jelas dari requirement. Dari user diketahui bahwa department harus mempunyai manager setiap saat yang mengimplikasikan partisipasi total. Atribut StartDate ditandai untuk tipe relationship ini.
2. WORKS_FOR, sebuah tipe relationship 1:N antara DEPARTMENT dan EMPLOYEE. Keduanya berpartisipasi secara total.
3. CONTROLS, sebuah tipe relationship 1:N antara DEPARTMENT dan PROJECT. Partisipasi PROJECT adalah total sementara DEPARTMENT ditentukan parsial setelah berkonsultasi dengan user.
4. SUPERVISION, adalah tipe relationship 1:N antara EMPLOYEE (dalam Role Supervisor) dan EMPLOYEE (dalam role supervisee). Kedua partisipasi ditentukan parsial setelah user menunjukkan bahwa tidak setiap pegawai adalah supervisor dan tidak setiap employee mempunyai supervisor.
5. WORKS_ON, ditentukan menjadi tipe relationship M:N dengan atribut Hours, setelah users menunjukkan bahwa project dapat memiliki beberapa pegawai yang bekerja padanya. Kedua partisipasi ditentukan total partisipasi.
6. DEPENDENTS_OF, adalah tipe relationship antara EMPLOYEE dan DEPENDENT, yang juga mengidentifikasi relationship untuk tipe entity lemah DEPENDENT. Partisipasi EMPLOYEE adalah parsial sementara DEPENDENT adalah total.
Setelah menspesifikasi enam tipe relationship tersebut di atas, kita mengganti tipe entity gambar 6 semua atribut yang telah diperbaiki dalam relationship. Hal ini termasuk Manager dan managerStartDate dari DEPARTMENT; ControllingDepartment dari PROJECT; Department, Supervisor dan WorksOn dari EMPLOYEE; dan Employee dari DEPENDENT. Adalah penting untuk mempunyai sekecil mungkin redundancy ketika kita mendesain skema konseptual dari database.
1.11. ER Diagram, Konvensi Penamaan dan Isu-isu dalam Desain
1. Notasi untuk ER Diagram
Gambar 3.13 mengilustrasikan tipe entity dan tipe relationship dengan menampilkan extension mereka – entity individu dan instansi relationship. Dalam ER diagram titik beratnya adalah pada representasi dari skema dibandingkan instansi. Ini lebih bermanfaat karena sebuah skema database jarang berubah sementara extension sering berubah. Skema lebih mudah untuk ditampilkan dibanding extension database karena lebih kecil. Gambar 3.14 adalah ringkasan konvensi untuk ER diagram.
2. Penamaan yang Sesuai dari Konstruksi Skema
Dalam memberikan nama untuk tipe entity, atribut dan relationship seharusnya dipilih nama yang dapat memiliki arti yang dapat menjelaskan konstruksi yang berbeda dalam skema. 3. Pilihan Desain Untuk Desain Konseptual ER
Kadang sulit untuk memutuskan apakah konsep tertentu dalam miniworld seharusnya dimodelkan sebagai sebuah tipe entity, sebuah atribut atau sebuah relationship. Berikut ini adalah petunjuk untuk mengkonstruksi pilihan yang seharusnya dipilih dalam siatuasi tertentu.
Secara umum proses desain skema seharusnya dilihat sebagai sebuah proses perbaikan yang iteratif, dimana desain awal dibuat kemudian diperbaiki terus menerus sampai desain yang cocok diperoleh. Beberapa perbaikan yang sering digunakan adalah sbb:
1. Konsep mungkin pertama kali dimodelkan sebagai sebuah atribut dan kemudian diperbaiki dalam sebuah relationship karena penentuan atribut tersebut adalah referensi ke tipe entity lain. Sering terdapat kasus bahwa pasangan atribut tersebut adalah invers satu dengan yang lain diperbaiki dalam relationship benary.
2. Serupa dengan hal tersebut, sebuah atribut yang ada dalam beberapa tipe entitymungkin diperbaiki ke dalam tipe entity independentnya sendiri.
3. Perbaikan kebalikan dari kasus sebelumnya mungkin diaplikasikan. Contoh, bila tipe entity DEPARTMENT ada dalam desain awal dengan sebuah atribut tunggal DeptName dan berhubungan hanya dengan satu tipe entity lain STUDENT. Dalam kasus ini DEPARTMENT dapat diperbaiki dalam sebuah atribut dari STUDENT. 4. Perbaikan yang lain adalah tentang spesialisasi/generalisasi dan relationship dari
derajat tinggi.
1.12. Notasi alternatif untuk Diagram ER
Ada banyak alternatif notasi diagramatik untuk menampilkan diagram ER, seperti notasi Universal Modelling Language (UML) yang telah diajukan sebagai standar untuk pemodelan object konseptual.
Pada gambar 13 menampilkan skema database COMPANY menggunakan notasi (min,max). Biasanya hanya menggunakan perbandingan kardinalitas/garis tunggal/garis double atau notasi min/max. Notasi min/max adalah lebih tepat, dan kita dapat menggunakan dengan mudah untuk menspesifikasi constraint struktura untuk tipe relationship dari beberapa degree.
Gambar 13. Diagram ER darri skema COMPANY, dengan semua nama role constrainnt yang terstruktur pada setiap relasinya menggunakan notasi tambahan
2. Microsoft Access
Software Microsoft Office merupakan satu software yang sangat popular pada masa sekarang. Software ini dikategorikan sebagai software automasi perkantoran yang bertujuan untuk memudahkan kerja-kerja rutin perkantoran, contohnya penyediaan laporan, memo dan laporan kewangan. Microsoft Access merupakan antara paket yang ditawarkan oleh software ini. Terdapat beberapa kelebihan dan kelemahan software ini.
Kelebihan penggunaan Microsoft Access
1. Berasaskan platform windows
Pada masa sekarang, software windows telah digunakan dengan meluas pada masa sekarang. Ini kerana platform windows ini amat sesuai untuk lapisan pengguna komputer baru. Namun demikian, sistem yang dibangun lebih mudah digunakan oleh semua lapisan pengguna.
2. Kurang memerlukan pemprograman
Pembangunan sistem menggunakan software ini sangat mudah. Ini kerana software ini banyak mengandungi bantuan (wizard). Bantuan yang disediakan termasuk penambahan, pembuangan dan pengemaskinian pangkalan data (update database). Pengguna hanya perlu memilih ciri-ciri yang diperlukan manakala selebihnya
dilaksanakan oleh Microsoft Access tersebut. Bantuan ini menyebabkan
pembangunan menggunakan software ini hampir tidak memerlukan pemprograman. 3. Mudah implementasi
Dari segi implementasi, sistem yang dihasilkan ini tidak memerlukan konfigurasi yang kompleks. Sistem tersebut mudah dimasukkan dan mudah dipindahkan ke tempat lain.
Kelemahan penggunaan Microsoft Access
1. Tahap keselamatan rendah
Software ini tidak sesuai untuk pembangunan sistem yang memerlukan tahap sekuriti yang tinggi. Selain itu, sistem ini tidak sesuai untuk menyimpan data yang sangat besar. Ini menyebabkan perusahaan besar tidak memilih software ini untuk membangunkan sistem mereka.
2. Kurang fleksibel
Pembangunan sistem ini banyak bergantung kepada wizard. Oleh demikian, fungsi menjadi kurang fleksibel kerena tata caranya telah ditetapkan oleh Microsoft Access. Namun begitu, sistem ini masih lagi sesuai untuk pembangunan sistem data ringkas dan berukuran kecil.
3. Membangun Sistem Buku Alamat
Untuk memulai pembangunan sistem ini, anda dikehendaki memasukkan software Microsoft Access ke dalam komputer peribadi anda. Kemudian, anda telah siap untuk membangunkan sistem. Caranya adalah seperti berikut :
1. Buka software Microsoft Access.
2. Klik menu "file" dan kemudian klik "new" untuk memulai pembangunan pangkalan data baru.
3. Kemudian, satu window baru akan dipaparkan. Terdapat dua bagian pada window tersebut iaitu "General" dan "Databases". (gambar 14)
1. Databases adalah bagian dimana terdapat template untuk pembangunan sistem. Anda hanya perlu mengisi data yang diperlukan dan kemudian sistem tersebut siap digunakan.
2. General adalah bagian untuk membentuk dan membangun sistem pada tahap awal. Walaupun ia lambat, namun ia lebih fleksibel berbanding dengan sistem yang anda buat secara template atau wizard.
Gambar 14. Menu Membuat Databse Baru
4. Untuk membangunkan sistem ini, anda dikehendaki memilih "Database" dalam menu "General".
5. Kemudian anda dikehendaki memasukkan nama pangkalan data (nama database) sistem yang ingin anda buat. Sebagai contoh, letakkan nama sistem tersebut sebagai "Book Address" (gambar 15)
Gambar 15. Nama File Database
Di bagian kiri window tersebut, terdapat beberapa bagian objects yaitu tables, queries, forms, reports, pages, macros, modules.
1. Tables - bagian ini merupakan tempat untuk membuat tabel untuk sistem.
2. Queries - bagian ini merupakan tempat untuk mengeluarkan paparan berdasarkan kekangan dan ciri-ciri tertentu.
3. Forms - bagian ini merupakan tempat untuk membuat antaramuka form untuk memudahkan pengguna memasukkan data ke pangkalan data.
4. Reports - bagian ini merupakan tempat untuk membuat laporan untuk dijadikan rujukan kepada pengguna.
5. Pages - bagian ini pula merupakan tempat untuk membuat antaramuka form dalam bentuk webpage.
6. Macros - bagian ini merupakan tempat untuk membuat set-set arahan kepada sistem. Contoh set arahan adalah seperti kotak pesan (message) dan pemberitahuan kepada pengguna.
7. Modules - bagian ini merupakan tempat untuk membuat pemprograman terhadap sub-fungsi untuk tujuan tertentu. Bagian ini juga tidak akan disentuh dalam perbincangan kali ini.
Di dalam latihan ini, kita hanya akan menyentuh bagian tables, forms dan reports saja.
3.1. Membuat Tabel
Bagi memulai membuat tabel, pengguna diberikan 3 jenis pilihan. Untuk contoh ini, pengguna disarankan memilih "Create Table in Design View". Apabila pilihan tersebut dipilih, satu window baru akan dibuka. Terdapat 3 slot utama dalam bagian ini iaitu :
1. Field Name : Slot ini adalah slot untuk nama attribut sebagai contoh no_id , nama, alamat dan no_tel. Sembarang huruf boleh dimasukkan kecuali huruf khas termasuk jarak (space bar) dan juga titik.
2. Data Type : Jenis data bagi data tersebut. 3. Description : Keterangan bagi data tersebut.
Sebagai contoh, masukkan data berikut ke dalam tempat yang disediakan :
Field Name Data Type Description 1 NoID Autonumber bil data pengguna 2 Nama Text nama pengguna 3 Alamat Text alamat pengguna 4 NoTel Text no telephon pengguna 5 Email Text alamat e-mail pengguna
Katakunci merupakan data unik bagi seseorang pengguna. Ia amat penting dalam proses pencarian pengguna. Dalam sistem ini jadikan NoID sebagai primary key (katakunci). Caranya dengan klik kanan lajur NoID dan kemudian klik pada pilihan "primary key". Seterusnya, "save" tabel tersebut dengan nama "Utama".
3.2. Membuat Form
Dalam contoh kali ini, anda akan belajar membuat form menggunakan wizard. Untuk membuat form, klik pada bagian form disebelah kiri window. Kemudian, ambil pilihan "Create Form By Using Wizard".
Gambar 16. Membuat Form Menggunakan Wizard
Satu window baru akan dipaparkan, masukkan ke semua item dalam "Available Fields" ke dalam "Selected Fields" dengan klik pada simbol ">>". Kemudian, klik pada buton "Finish". Maka selesailah satu form baru. Kemudian, tutup form tersebut.
Gambar 17. "Available Fields" ke dalam "Selected Fields"
Untuk memperbaiki tampilan form tersebut, klik kanan pada nama form dan pilih menu "Design". Untuk menambah fungsi tambah dan buang data anda dikehendaki untuk membuat buton (tombol) sendiri.
Gambar 18. Design Form
Cara membuat buton, pergi ke window "Toolbox" seperti yang terletak dibagian kanan gambar rujukan. Pilih objek di baris ke-3, lajur ke-3 dan klik ke dalam bagian detail form. Satu window baru akan keluar, anda dikehendaki memilih kategori "Record Operation" dan pilih actions "Add New Records". Kemudian, tekan buton "Finish" maka selesailah buton tambah rekod. Buat kaedah yang sama tetapi kali ini pilih action "Delete Record" untuk buat buton tambah rekod.
Gambar 19. Record Operation
Seterusnya, setelah selesai membuat bentuk laporan pada topik seterusnya nanti buat buton pada bagian ini dengan memasuki "Report Operation" dan pilih menu "open report". Pastikan pada praktek ini dapat selesai membentuk laporan.
Untuk bagian memperbaiki tampilan, anda hanya memilih rekord dengan menggunakan navigation button yang terletak dibagian bawah form. Untuk melihat paparan form, klik kanan pada nama form dan klik open.
3.3. Membuat Laporan
Dalam latihan kali ini, anda akan mencoba membuat laporan menggunakan wizard. Untuk membuat laporan, klik pada bagian report disebelah kiri window. Kemudian, ambil pilihan "Create Report By Using Wizard".
Satu window baru akan dipaparkan, masukkan ke semua item dalam "Available Fields" ke dalam "Selected Fields" dengan klik pada simbol ">>". Kemudian, klik pada buton "Finish". Maka selesailah satu form baru. Kemudian, tutup klik tersebut.
Gambar 20. Create Report By Using Wizard
Untuk mengemaskini paparan report tersebut, klik kanan pada nama report dan pilih menu "Design".
Kemudian, balik ke bagian form dan buat buton untuk membuka laporan ini.
4. Teknik Impot Data Ke Access
Anda dapat mengimpot data dari Visual FoxPro database kepada Microsoft Access database dengan cara impot opysen berikut.
1. Buka Microsoft Access database.
2. Dari File menu, pilih Get External Data dan seterusnya Impot.
3. Didalam Import dialog box, pilih ODBC Databases( ) yang memaparkan Files type list. 4. Didalam SQL Data Sources dialog box, pilih Visual FoxPro data source yang
menyambung kepada FoxPro data yang anda ingin query and klik OK.
5.Didalam Import Objects dialog box, pilih salah satu tables atau lebih untuk di impot dan klik OK. Nama Visual FoxPro tables yang anda impot ditayangkan didalam Tables
tab Microsoft Access database.
Sekarang anda boleh guna Microsoft Access untuk manipulate data yang di impot dari Visual FoxPro tables.
data yang anda impot adalah snapshot dari data yang tersimpan di Visual FoxPro; Jika anda membuat
perubahaan maka data impot tidak akan dihantar semula kepada Visual FoxPro data source.
4.1. Teknik Lain Dalam Access Data
Jika anda ingin membuat perubahaan didalam Microsoft Access untuk menukar data di Visual FoxPro data source, anda perlu buat Querying dan Updating Visual FoxPro Data dari Microsoft Access.Cara Querying dan Updating Visual FoxPro Data dari Microsoft Access dengan menggunakan the Link Table option. Untuk link Visual FoxPro database kepada Microsoft Access database
1.buka Microsoft Access database. 2.Dari Tables tab, click New.
3.Di New Table dialog box, pilih Link Table dan klik OK.
4.Di Link dialog box, pilih ODBC Databases( ) dan lihat Files type list.
FoxPro data yang anda ingin query dan klik OK.
6.Di Link Tables dialog box, pilih tables yang anda ingin query dan update serta klik OK. Visual FoxPro tables akan dipaparkan didalam Tables tab Microsoft Access database.
Anda sekarang boleh menggunakan Microsoft Access untuk query dan update data terangkai (linked) Visual FoxPro tables.Apa-apa perubahaan dibuat data akan dihantar semula kepada Visual FoxPro data source.
4.2. Mengenal Microsoft Data Access Components (MDAC)
Tulisan ini penulis translate dari suatu dokumen Microsoft yang berjudul "What are the Microsoft Data Access Components". Tulisan ini berbicara seputar komponen-komponen apa saja yang menjadi bagian dari MDAC (Microsoft Data Access Components).
Apa itu Microsoft Data Access Components?
Microsoft Data Access Components (MDAC) adalah sekumpulan komponen yang merupakan kunci dari teknologi yang membangun Universal Data Access. Aplikasi database client/server baik itu yang berbasis web ataupun pada suatu LAN dapat menggunakan komponen-komponen ini untuk mengintegrasikan informasi dari berbagai macam sumber data, baik itu yang sifatnya relasional (SQL) maupun data yang tidak relasional. Komponen-komponen dalam MDAC ini diantaranya adalah:
§ Microsoft ActiveX Data Objects (ADO) § OLE DB
§ Open Database Connectivity (ODBC)
Gambar 22 berikut ini akan menunjukkan secara keseluruhan mengenai arsitektur MDAC dan bagaimana MDAC ini menjadi kunci dalam membangun model UDA (Universal Data Access).
Gambar 22. Jenis MDAC pada Microsoft Access
§ ActiveX Data Objects (ADO)
Microsoft ActiveX Data Objects (ADO) adalah suatu Application Programming Interface (API) strategis yang khusus digunakan dalam pengaksesan data dan informasi. ADO memberikan cara yang konsisten, pengaksesan data dengan performa tinggi yang mendukung berbagai kepentingan untuk membangun sebuah aplikasi, termasuk dalam pembuatan aplikasi client database dan middle-tier business object yang menggunakan aplikasi, tools, bahasa atau browser internet. ADO didisain sedemikian rupa untuk menjadi satu data interface yang dapat digunakan untuk kepentingan single dan multitier client/server dan aplikasi berbasis web. Keuntungan utama dari ADO adalah kemudahan dalam penggunaan, kecepatan tinggi, penggunaan memory yang minimal dan small disk footprint.
Anda dapat melihat posisi ADO pada gambar diatas. ADO berada diatas teknologi akses data yang lain dan memberikan dukungan data akses terhadap para developer. ADO memberikan kemudahan interface dalam mengakses OLE DB. ADO menerapkan trafik jaringan secara minimal dan meminimalkan jumlah layer antara fron-end dan sumber data untuk memberikan interface yang ringan tetapi dengan performa yang
tinggi. ADO sangat mudah digunakan karena berbasis interface COM automation yang saat ini sudah tersedia pada semua RAD development tools, database tools dan bahasa-bahasa pemrograman di pasaran.
§ OLE DB
OLE DB adalah interface strategis programming pada level sistem untuk mengakses data. OLE DB adalah suatu spesifikasi terbuka yang didisain atas kesuksesan ODBC dengan memberikan suatu standard terbuka untuk mengakses berbagai macam data. ODBC dibuat untuk mengakses database relasional, sedangkan OLE DB didisain untuk datab relasional maupun non-relasional, ini termasuk mainframe ISAM/VSAM dan hierarchical database; e-mail dan file system; text, grafis, data geografis; custom business object dan masih banyak lagi yang lain.
OLE DB digambarkan sebagai sebuah kumpulan dari COM interface yang meng-encapsulate berbagai macam service database management system. Interface-interface ini memungkinkan pembuatan suatu komponen software yang digunakan oleh berbagai macam service. Komponen OLE DB terdiri dari data provider, yang berisi data; data consumer, yang menggunakan data; dan komponen service, yang memproses dan mengirimkan data (seperti prosesor query dan cursor engine). Interface OLE DB didisain untuk membantu komponen-komponen agar dapat berintegrasi secara mudah sehingga pembuat komponen OLE DB dapat membuat komponen OLE DB bagi pengguna dengan kualitas yang baik dan cepat. Sebagai tambahan, OLE DB menawarkan suatu jembatan kepada ODBC untuk menambah dukungan pada driver database ODBC yang banyak ragamnya saat ini.
§ Open Database Connectivity (ODBC)
Interface Microsoft Open Database Connectivity (ODBC) adalah suatu standard industri saat ini dan merupakan komponen dari Microsoft Windows Open Services Architecture (WOSA). Interface ODBC membuat aplikasi-aplikasi dapat mengakses data dari berbagai macam database management system (DBMSs). ODBC mengijinkan interoperabilitas secara maksimal terhadap berbagai macam DBMS hanya dengan melalui satu interface. Ini dapat
dikatakan bahwa suatu aplikasi akan berjalan secara independen. Pengguna aplikasi dapat menambah suatu software komponen yang dinamakan driver, yang mana menciptakan suatu interface antara suatu aplikasi dan suatu DBMS spesifik.
