1. Konsep Perancangan Database

Transkripsi

1 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 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) Halaman : 1

2 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 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. Halaman : 2

3 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 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 Halaman : 3

4 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 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. Halaman : 4

5 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 Halaman : 5

6 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. Halaman : 6

7 - 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, Halaman : 7

8 - 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 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. Halaman : 8

9 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 sifatsifat 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 Halaman : 9

10 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 e 1 mempunyai empat attribut: Name, Address, Age dan HomePhone; nilai-nilai mereka adalah John Smith, 2311 Kirby, Houston, Texas 77001, 55, dan ,.Entity company c 1 mempunyai tiga attribut: Name, Headquarters dan president; nilai mereka masing-masing adalah Sunco Oil, Houston. Dan John Smith,. Gambar 4. Dua entitas employee e 1 dam company c 1 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 Halaman : 10

11 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 masingmasing 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 Halaman : 11

12 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 masingmasing 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. Halaman : 12

13 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 Halaman : 13

14 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(V 1),P(V 2),, P(V n), dimana V 1, V 2,, V n adalah himpunan nilai dari atribut componen simple yang membentuk A: V = P(V 1) x P(V 2) x x P(V n) 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 menspesifiksibahwa Name dan Number adalah atribut Key (terpisah), karena masingmasing 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, Department dan Supervisor. Name dan Address mungkin atribut composit tetapi hal Halaman : 14

15 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. Halaman : 15

16 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 E 1, E 2,, E n 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) r i, dimana masingmasing r i mengasosiasikan n entity individu (e 1, e 2,, e n), dan masing-masing entity e j dalam r i adalah sebuah anggota dari tipe entity E j, 1 j n. Oleh karenanya sebuah tipe relationship adalah sebuah relasi matematis pada E 1, E 2,, E n, atau alternatifnya dia dapat didefinisikan sebagai sebuah himpunan bagian dari cartesian product E 1 x E 2 x x E n. Masing-masing dari tipe entity E 1, E 2,, E n dikatakan berpartisipasi (participate) di dalam tipe relationship R, dan serupa dengan hal itu, masing-masing individu entity e 1, e 2,, e n dikatakan berpartisipasi dalam suatu relationship r i = (e 1, e 2,, e n ). Secara informal masing-masing relationship instance r i 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 r i merepresentasikan kenyataan bahwa entity yang berpartisipasi dalam r i dihubungkan dengan beberapa jalan dalam menghubungan situasi miniworld. Contoh, perhatikan sebuah Halaman : 16

17 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 r i ditunjukkan menghubungkan entity employee department yang berpartisipasi dalam r i. Miniworld dalam gambar 3.9 employee e 1, e 3 dan e 6 bekerja untuk department d 1; e 2 dan e 4 work for d 2 ; serta e 5 dan e 7 work for d 3. 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 r i menghubungkan tiga entity seoarng suplier s, part p, dan project j dimana s Halaman : 17

18 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. Halaman : 18

19 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 r i dalam SUPERVISION menghubungkan dua entity employee e j dan e k, 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 e 1 mensupervisi e 2 dan e 3; e 4 mensupervisi e 6 dan e 7 ; serta e 5 mensupervisi e 1 dan e 4. Halaman : 19

20 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. Halaman : 20

21 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 menspesifikasi 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, Halaman : 21

22 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. Halaman : 22

23 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) 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 Halaman : 23

24 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. Halaman : 24

25 1.11. ER Diagram, Konvensi Penamaan dan Isu-isu dalam Desain Diktat Training TOT : Database 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. Halaman : 25

26 Gambar 12. Rangkuman notari diagram ER Halaman : 26

27 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 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. Halaman : 27

28 Gambar 13. Diagram ER darri skema COMPANY, dengan semua nama role constrainnt yang terstruktur pada setiap relasinya menggunakan notasi tambahan Halaman : 28

29 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. Halaman : 29

30 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. Halaman : 30

31 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". Halaman : 31

32 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. Halaman : 32

33 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 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 Text alamat 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". Halaman : 33