BAB 2 LANDASAN TEORI

Transkripsi

1 BAB 2 LANDASAN TEORI 2.1 Konsep Sistem Basisdata Latar Belakang Munculnya Penggunaan Basisdata Saat ini basisdata merupakan suatu teknologi yang tidak terpisahkan dalam kehidupan sehari-hari. Contohnya: saat kita mengakses suatu situs di internet, secara tidak sadar kita telah menggunakan suatu aplikasi basisdata. Sebelum adanya perangkat lunak basisdata seperti DBMS (Database Management System), penyimpanan data masih menggunakan pendekatan sistem file. Menurut Connolly dan Begg (2005, p7), sistem berbasis file adalah kumpulan program aplikasi yang memberikan fungsi pelayanan kepada end-user, misalnya untuk pembuatan laporan. Setiap program aplikasi mendefinisikan dan mengatur datanya masing-masing. Namun, ternyata banyak keterbatasan dari pendekatan sistem berbasis file, antara lain : Data yang terpisah dan terisolasi. Data yang sering terduplikasi. Ketergantungan data pada program aplikasi tertentu. Format file yang tidak cocok saat ingin digabungkan dengan file dari aplikasi yang berbeda. Format query yang statis. 8

2 9 Untuk mengatasi berbagai keterbatasan tersebut, maka munculah pendekatan yang menggunakan basisdata dan DBMS untuk sistem penyimpanan data Pengertian Data Menurut George Schell dan Raymond McLeod, Jr (2004, p9), data terdiri dari fakta-fakta yang umumnya tidak dapat digunakan karena ukurannya yang besar dan belum terproses. Sebagai contoh, data adalah jumlah jam kerja dari setiap pekerja dalam perusahaan. Saat data diproses, data dapat diubah menjadi informasi. Prosesnya adalah jam kerja dari setiap pekerja ini dikalikan dengan tarif per jam dan menghasilkan pendapatan kotor, kemudian pendapatan kotor dari setiap pekerja ditambahkan dan menjadi daftar gaji total. Jumlah dari daftar gaji ini adalah informasi bagi pemilik perusahaan. Jadi data adalah fakta-fakta yang disimpan di dalam database, sedangkan informasi adalah bagaimana data diartikan dan dimengerti oleh user Pengertian Basisdata Menurut Connolly dan Begg (2005, p15), database adalah suatu kumpulan data komputer yang terhubung secara logikal serta berisi deskripsi dari data tersebut, yang dirancang untuk memenuhi kebutuhan informasi dari suatu perusahaan. Menurut Kroenke (2002, p15), Database is a self describing collection of integrated records, yang berarti basisdata adalah suatu koleksi data yang menggambarkan integrasi antara record yang satu dengan yang lainnya. A self

3 10 describing di sini menjelaskan bahwa struktur data saling terintegrasi dalam suatu tempat yang dikenal sebagai kamus data atau metadata. Menurut Ramakrishnan dan Gehrke (2003, p4), basisdata adalah kumpulan data yang secara khusus menggambarkan kegiatan dari satu atau lebih bagianbagian yang berhubungan. Jadi, basisdata adalah suatu koleksi data yang saling berhubungan dan menggambarkan integrasi antara suatu record dengan record lainnya yang dirancang dan dimanfaatkan untuk memenuhi kebutuhan informasi dari suatu organisasi Sistem Basisdata Menurut C.J. Date (2000, p2), sistem basisdata adalah suatu sistem yang pada dasarnya menyimpan record-record di dalam suatu sistem komputerisasi, yang tujuan keseluruhannya adalah untuk memelihara infomasi dan untuk membuat informasi tersebut tersedia berdasarkan permintaan saat dibutuhkan. Menurut Fathansyah (2004, p2), sistem basisdata merupakan sistem yang terdiri atas kumpulan komponen-komponen yang saling berhubungan dan memiliki ketergantungan (dependence) dalam rangka mencapai suatu tujuan tertentu. Adapun komponen-komponen sistem basisdata yang saling bergantung adalah hardware, software, brainware, dan basisdata. Jadi, sistem basisdata adalah suatu sistem yang terdiri dari hardware, software, brainware, dan basisdata yang saling berhubungan, digunakan untuk penyimpanan data secara terkomputerisasi dengan tujuan untuk diolah menjadi informasi yang bermanfaat saat dibutuhkan oleh user.

4 Bahasa Basisdata (Database Design Language) Database Management System merupakan perantara antara user dengan basisdata. Cara interaksi antara user dengan basisdata tersebut diatur dalam suatu bahasa khusus yang ditetapkan oleh perusahaan yang merancang Database Management System. Bahasa tersebut dapat kita sebut sebagai bahasa basisdata, yaitu sejumlah perintah (statement) terstruktur yang diformulasikan oleh user dan dapat dikenali / diproses oleh sistem aplikasi basisdata untuk melakukan suatu pekerjaan tertentu. Contoh bahasa basisdata adalah SQL dan DBase. Adapun bahasa basisdata terbagi menjadi dua bentuk, yaitu DDL dan DML Data Definition Language (DDL) Menurut Connolly dan Begg (2005, p40), DDL adalah suatu bahasa yang memungkinkan Database Administrator atau user untuk mendefinisikan, menerangkan dan memberi nama entiti, atribut dan hubungan yang dibutuhkan oleh aplikasi. DDL digunakan untuk menspesifikasi suatu skema baru atau untuk memodifikasi skema database yang sudah ada, namun tidak dapat digunakan untuk memanipulasi data. Menurut Fathansyah (2004, p13), DDL adalah struktur atau skema basisdata yang menggambarkan rancangan basisdata secara keseluruhan dengan dispesifikasikan melalui bahasa khusus. Hasil dari kompilasi perintah DDL adalah kumpulan tabel yang disimpan dalam file khusus yang disebut kamus data. Beberapa statement DDL (Connolly dan Begg, 2005, p168 ), yaitu: a) Create Table : untuk membuat tabel dengan mengidentifikasikan tipe data untuk tiap kolom.

5 12 b) Alter Table : untuk menambah atau membuang kolom, nilai default, dan constraint ke atau dari suatu tabel. c) Drop Table : untuk membuang atau menghapus tabel beserta semua data yang terkait di dalamnya. d) Create Index: untuk membuat indeks pada suatu tabel. e) Drop Index: untuk membuang atau menghapus indeks yang telah dibuat sebelumnya Data Manipulation Language (DML) Menurut Connolly dan Begg (2005, p40), DML adalah suatu bahasa yang menyediakan kumpulan operasi yang akan diinginkan untuk mendukung operasi manipulasi data di dalam basisdata. DML menyediakan operasi dasar manipulasi data di basisdata, yaitu : Penyisipan data baru ke dalam basisdata (insertion). Mengubah atau modifikasi data yang disimpan di dalam basisdata (update). Pemanggilan data yang ada dalam basisdata (retrieve). Menghapus data dari basisdata (delete). Menurut Connolly dan Begg (2005, p41-p42), kita dapat membedakan DML menjadi dua tipe yang berbeda, yaitu : a) Procedural DML Procedural DML adalah suatu bahasa yang memungkinkan user (umumnya programmer) untuk memberi instruksi ke sistem mengenai data apa yang dibutuhkan dan bagaimana cara pemanggilannya (retrieve). Artinya user

6 13 harus menjelaskan operasi pengaksesan data yang akan digunakan dengan menggunakan prosedur yang ada untuk mendapatkan informasi yang dibutuhkan. b) Non-Procedural DML Non-Procedural DML adalah bahasa yang memungkinkan user untuk menentukan data apa yang dibutuhkan tanpa perlu menspesifikasikan bagaimana cara mendapatkan data tersebut Database Management System (DBMS) Menurut Connolly dan Begg (2005, p16), DBMS diartikan sebagai suatu software yang memungkinkan user untuk mendefinisikan, membuat, memelihara, dan mengontrol akses ke dalam suatu basisdata. Selain bertanggungjawab atas keamanan (security) dan kesatuan (integrity) basisdata tersebut, DBMS juga menerima permintaan data dari program aplikasi, yang kemudian memerintahkan sistem operasi untuk mengirimkan data yang dimaksudkan. DBMS merupakan program yang mempengaruhi program aplikasi user dan basisdata. Contoh perangkat lunak yang termasuk DBMS adalah Microsoft Access, Microsoft SQL Server, dan Oracle. Suatu DBMS harus mendukung fungsi-fungsi sebagai berikut : 1) Sebagai tempat penyimpanan data, pengambilan kembali data yang diinginkan, dan pembaharuan data. Ini merupakan fungsi pokok DBMS. 2) Sebagai kamus data (sistem katalog) yang bisa diakses oleh user.

7 14 Kamus data (Data Dictionary) adalah tempat penyimpanan dari informasi yang menjelaskan data yang ada di dalam basisdata. Biasanya kamus data menyimpan : nama, tipe, dan ukuran dari item data nama dari relationship (hubungan antar entiti / objek) batasan integritas dari suatu data nama dari user yang memiliki hak akses terhadap data skema eksternal, konseptual, dan internal serta pemetaan antar skema penggunaan statistik, seperti frekuensi dari transaksi dan jumlah akses yang dibuat ke dalam objek di basisdata. 3) Mendukung transaksi. DBMS harus menyediakan mekanisme yang dapat menjamin isi dari basisdata selalu mengikuti perubahan sesuai dengan transaksi yang dilakukan, sehingga data yang ada di dalam basisdata selalu akurat dan terjamin kebenarannya. 4) Mengontrol concurrency. DBMS memungkinkan pemakai untuk dapat mengakses data bersama secara bersamaan dan menjamin tidak terjadinya gangguan pada basisdata. 5) Menyediakan perbaikan data kembali (recovery). Jika terjadi error pada hardware atau software atau adanya transaksi yang gagal dilakukan, maka basisdata dapat dikembalikan pada kondisi semula (konsisten). 6) Menyediakan otorisasi bagi user.

8 15 DBMS harus dapat menjamin bahwa hanya user yang memiliki otorisasi / hak akses saja yang dapat mengakses basisdata 7) Membantu mendukung komunikasi data. 8) Meningkatkan integritas data. 9) Mengurangi ketergantungan data. 10) Menyediakan kegunaan-kegunaan lainnya pada level internal, seperti memonitor pemakaian basisdata dan operasi dan pemakaian program analisa statistik Komponen Penting Lingkungan DBMS Menurut Connolly dan Begg (2005, p18), ada lima komponen penting dalam lingkungan DBMS, yaitu : 1) Perangkat Keras (Hardware) DBMS dan aplikasi-aplikasi memerlukan hardware untuk beroperasi. Hardware tersebut dapat berupa komputer pribadi tunggal, suatu mainframe tunggal, sampai suatu jaringan komputer. Contohnya : harddisk sebagai media penyimpanan yang mempunyai kemampuan untuk penyimpanan basisdata. 2) Perangkat Lunak (Software) Komponen software terdiri dari DBMS itu sendiri, program aplikasi, dan sistem operasi, termasuk software jaringan jika DBMS digunakan melalui suatu jaringan. Contoh software pada Third-Generation Programming Language (3GL) adalah C, C++, Java, Visual Basic, COBOL, Fortran, Ada, dan Pascal.

9 16 3) Data Komponen yang paling penting dari lingkungan DBMS, tentu saja dari sudut pandang end-users, adalah data. Data berperan sebagai suatu jembatan antara komponen-komponen mesin dan komponen-komponen manusia. 4) Prosedur (Procedures) Prosedur menunjuk pada instruksi dan aturan-aturan yang mengatur rancangan dan kegunaan dari basisdata. Pengguna sistem dan staff yang mengatur basisdata membutuhkan dokumentasi prosedur yang menjelaskan bagaimana menggunakan dan menjalankan sistem. Prosedur terdiri dari instruksi mengenai cara masuk ke dalam DBMS, kegunaan fungsi atau fasilitas tertentu dalam DBMS, cara memulai dan menghentikan DBMS, cara membuat salinan (back-up) dari basisdata, cara mengatasi kegagalan hardware atau software, dan cara mengubah struktur dari sebuah tabel, mengatur kembali basisdata, meningkatkan kinerja, atau mengarsipkan data ke dalam secondary storage. 5) Manusia (People) Merupakan user yang menggunakan data secara optimal, seperti pemrograman piranti lunak untuk mengakses basisdata, user akhir yang menggunakan piranti lunak dalam mengakses basisdata, dan administrator yang bertanggung jawab atas kesalahan sistem basisdata. Peran yang ada di lingkungan basisdata, yaitu : Database Administrator (DBA), Database Designers, Application Developers, dan end-users. Berdasarkan cara mereka menggunakan sistem, end-users diklasifikasikan menjadi user ahli dan user awam.

10 Keuntungan dan Kerugian DBMS Menurut Connolly dan Begg (2005, p26-p30), DBMS memiliki keuntungan dan kerugian. Adapun keuntungan DBMS, yaitu: 1) Mengurangi pengulangan data yang sama (data redundancy). 2) Menciptakan data yang konsisten karena adanya pencegahan redundansi data. 3) Mampu mendapatkan semakin banyak informasi dari data yang sama. 4) Data dapat digunakan secara bersama-sama (sharing data). 5) Menambah integritas data, yang berarti keakuratan dan konsistensi dari data yang tersimpan. 6) Meningkatkan keamanan data. 7) Meningkatnya kualitas penyimpanan data dengan menggunakan standarisasi yang dibutuhkan. 8) Dapat mengurangi biaya pengembangan sistem karena menggabungkan data operasional semua bagian perusahaan hanya ke dalam suatu basisdata dan program aplikasinya. 9) Mengurangi terjadinya konflik terhadap kebutuhan data antar user / departemen yang satu dengan lainnya. 10) Meningkatkan kemampuan untuk mengakses data dan hasilnya. 11) Meningkatkan produktivitas user. 12) Memudahkan pemeliharaan data karena data bersifat independent. 13) Meningkatkan concurrency untuk mencegah hilangnya data atau informasi saat dua atau lebih user mengakses data yang sama pada waktu yang bersamaan. 14) Meningkatkan pelayanan terhadap back-up dan recovery service.

11 18 Kerugian DBMS, yaitu : 1) Merupakan software yang kompleks sehingga perancang basisdata harus mengerti fungsi-fungsi yang ada untuk mendapatkan hasil rancangan yang baik. 2) Membutuhkan disk space / memory yang cukup besar untuk instalasinya. 3) Biaya DBMS yang tergantung pada tipe DBMS yang digunakan. 4) Biaya tambahan terhadap kebutuhan perangkat keras. 5) Biaya tambahan lain seperti pelatihan para staff dan spesialis untuk menjalankan sistem yang baru.

12 Siklus Hidup Aplikasi Basisdata (Database Application Lifecycle) Gambar 2.1 berikut ini merupakan diagram tahap-tahap siklus hidup aplikasi basisdata. Gambar 2.1 Tahap-Tahap Siklus Hidup Aplikasi Basisdata ( Sumber : Connolly dan Begg, 2005, p284)

13 Database Planning (Perencanaan Basisdata) Database planning merupakan aktivitas-aktivitas manajemen yang memungkinkan tahap-tahap dalam aplikasi basisdata direalisasikan secara efektif dan efisien. Database planning harus diintegrasikan dengan keseluruhan sistem informasi suatu organisasi. Ada tiga persoalan pokok yang terlibat dalam perumusan suatu strategi sistem informasi, yaitu: Identifikasi rencana, sasaran, dan tujuan perusahaan dengan penentuan kebutuhan sistem informasi. Evaluasi sistem informasi yang sedang berjalan untuk menentukan kelebihan dan kekurangan yang ada. Penilaian terhadap peluang teknologi informasi apakah mampu menghasilkan keuntungan yang kompetitif. Tahap awal yang penting dalam perencanaan basisdata adalah menentukan dengan jelas mission statement (pernyataan misi) untuk proyek basisdata. Mission statement ini menentukan tujuan utama aplikasi basisdata. Mission statement membantu menjelaskan tujuan proyek basisdata dan menyediakan cara yang lebih jelas untuk menciptakan suatu basisdata yang efektif dan efisien. Tahap selanjutnya adalah mission objective. Setiap mission objective harus mengidentifikasi tugas-tugas tertentu yang akan didukung basisdata System Definition (Definisi Sistem) System definition menggambarkan ruang lingkup dan batasan-batasan aplikasi basisdata dan user views (gambaran user) yang utama. User views

14 21 menentukan apa yang dibutuhkan di aplikasi basisdata dari sudut pandang jabatan pekerjaan tertentu (seperti manager atau supervisor) atau dari sudut pandang bagian-bagian di perusahaan (seperti marketing atau stock control) Requirements Collection and Analysis (Pengumpulan dan Analisa Kebutuhan) Merupakan proses pengumpulan dan analisa informasi dari bagian-bagian perusahaan, yang akan digunakan untuk mengidentifikasi kebutuhan-kebutuhan user dari sistem yang baru. Tahap ini melibatkan pengumpulan dan analisa informasi tentang bagian-bagian perusahaan yang akan menerapkan basisdata. Ada tiga pendekatan utama untuk pengaturan kebutuhan aplikasi basisdata dengan multiple user views, antara lain: Pendekatan centralized Kebutuhan-kebutuhan setiap user view digabung dalam suatu kumpulan kebutuhan tunggal untuk aplikasi basisdata baru. Pendekatan view integration Kebutuhan-kebutuhan setiap user view digunakan untuk membangun sebuah model data yang terpisah untuk mewakili kebutuhan user itu sendiri. Model data yang dihasilkan nantinya akan digabung pada tahap perancangan basisdata. Gabungan antara centralized dan view integration

15 Database Design (Perancangan Basisdata) Merupakan proses pembuatan suatu rancangan untuk basisdata yang akan mendukung operasi dan tujuan perusahaan. Perancangan basisdata terdiri dari tiga fase yaitu perancangan konseptual, perancangan logikal, dan perancangan fisikal. Tahap-tahap ini akan dijelaskan di subbab berikutnya DBMS Selection (Pemilihan DBMS) Merupakan pemilihan suatu DBMS yang tepat untuk mendukung aplikasi basisdata. Tahap-tahap pemilihan DBMS: 1) Menentukan DBMS dari rekomendasi yang berasal dari dokumen ilmiah. 2) Membuat daftar sementara dari dua atau tiga produk. 3) Mengevaluasi produk. 4) Terpilih produk yang tepat untuk aplikasi basisdata dan membuat laporannya Application Design (Perancangan Aplikasi) Merupakan perancangan user interface dan memilih program aplikasi yang akan digunakan untuk memproses basisdata. Ada dua aspek penting dalam perancangan aplikasi, yakni: Transaction Design (Perancangan Transaksi) User Interface Design (Perancangan Antarmuka)

16 Prototyping (optional step) Merupakan pembuatan suatu model aplikasi basisdata, yang memungkinkan perancang atau user untuk melihat dan mengevaluasi bagaimana fungsi dari sistem akhir yang dihasilkan. Ada dua strategi prototyping pada zaman sekarang, yaitu: Requirements Prototyping, menggunakan suatu prototype untuk menentukan kebutuhan-kebutuhan dari aplikasi basisdata yang diusulkan dan saat kebutuhan-kebutuhan tersebut lengkap, prototype dibuang. Evolutionary Prototyping, digunakan untuk tujuan yang sama, perbedaan yang penting adalah bahwa prototype tidak dibuang tetapi dengan perkembangan yang lebih jauh menjadi aplikasi basisdata yang digunakan Implementation (Implementasi) Merupakan realisasi fisik dari perancangan basisdata dan aplikasinya. Pada penyelesaian tingkat-tingkat perancangan (dimana melibatkan prototyping atau tidak), sekarang kita dalam posisi mengimplementasikan basisdata dan program aplikasi. Implementasi basisdata dicapai dengan menggunakan DDL dari DBMS yang dipilih, atau Graphical User Interface (GUI) yang menyediakan fungsi yang sama ketika menyembunyikan pernyataan DDL tingkat rendah. Pernyataan DDL tersebut digunakan untuk membuat struktur basisdata dan file basisdata kosong.

17 24 Program aplikasi diimplementasikan dengan menggunakan bahasa generasi ketiga atau keempat (3GL atau 4GL). Bagian dari program aplikasi ini adalah transaksi basisdata, dimana diimplementasikan dengan menggunakan DML dari DBMS sasaran, yang mungkin disimpan dalam sekumpulan bahasa pemrograman, misalnya VisualBasic.NET. Program aplikasi juga mengimplementasikan komponen-komponen lainnya seperti layar menu, form pemasukan data, dan laporan-laporan Data Conversion and Loading (Perubahan dan Pengambilan Data) Merupakan pemindahan data yang ada dari sistem lama ke dalam sistem basisdata baru dan mengubah aplikasi yang ada untuk beroperasi pada sistem basisdata yang baru. Langkah ini diperlukan hanya ketika suatu sistem basisdata baru menimpa sistem yang lama Testing (Pengetesan) Merupakan proses pengeksekusian program aplikasi dengan maksud pencarian kesalahan-kesalahan dan memvalidasi basisdata agar sesuai dengan kebutuhan yang dispesifikasikan oleh user Operational Maintenance (Perawatan Operasional) Merupakan proses pengawasan dan pemeliharaan sistem secara terusmenerus, yang melibatkan aktivitas pengawasan kinerja sistem, dan mempertahankan serta meng-upgrade aplikasi basisdata (ketika dibutuhkan).

18 Metodologi Perancangan Basisdata Menurut Connolly dan Begg (2005, p438), metodologi perancangan adalah suatu pendekatan struktural yang menggunakan bantuan sejumlah prosedur, teknik, tools serta bantuan dokumentasi untuk mendukung dan memfasilitasi proses dari suatu perancangan. Untuk merepresentasikan metodologi dari suatu perancangan basisdata, diperlukan suatu proses perancangan yang dibagi menjadi tiga tahap utama, yaitu perancangan basisdata konseptual, perancangan basisdata logikal, dan perancangan basisdata fisikal Perancangan Basisdata Konseptual Merupakan suatu proses dalam membangun suatu informasi yang digunakan oleh perusahaan dengan mengabaikan segi pengimplementasiannya terlebih dahulu, misalnya DBMS apa yang akan digunakan, program aplikasi, bahasa pemrogramannya, hardware yang akan digunakan, dan hal lainnya yang bersifat fisikal. Kegiatan utama di dalam perancangan basisdata konseptual adalah : Tahap 1 : Membangun Model Data Konseptual Lokal untuk Setiap View. Tujuan tahap ini adalah untuk membangun model data konseptual lokal suatu perusahaan dari sudut pandang masing-masing user. Selama proses analisa, sudut pandang dari masing-masing user diidentifikasikan dan dikombinasikan sehingga membentuk suatu pandangan yang kolektif. Setiap model data konseptual lokal terdiri dari : entiti, hubungan relasi antar entiti, atribut dan atribut domain, primary key dan alternate key, serta batasan integritas. Model data konseptual didukung oleh suatu dokumentasi

19 26 seperti kamus data. Rincian dari kamus data dapat diperoleh melalui sub tahap di bawah ini, yaitu : Tahap 1.1: Mengidentifikasikan Tipe-Tipe Entiti Tujuannya untuk menentukan jenis entiti utama yang diperlukan oleh user. Tahap 1. 2: Mengidentifikasikan Tipe-Tipe Relasi atau Hubungan Tujuannya untuk mengidentifikasi hubungan penting yang terjadi di antara jenis entiti yang sudah diidentifikasi di tahap sebelumnya. Relasi biasanya ditunjukkan dengan menggunakan sebuah kata kerja atau ungkapan yang berhubungan dengan kata kerja. Untuk mencegah hilangnya suatu relasi ketika dilakukan validasi terhadap suatu transaksi, kita harus melakukan hal-hal berikut, yaitu : a) Menggunakan Diagram Hubungan Antar Entiti (ER Diagram) Digunakan untuk merepresentasikan entiti dan bagaimana entiti tersebut mudah berhubungan satu sama lainnya. Hal ini juga membantu terbentuknya suatu gambaran tentang bagian-bagian dalam suatu perusahaan yang akan kita modelkan. b) Menentukan Multiplicity Constraint dari Tipe-Tipe Relasi Setelah menentukan relasi ke dalam suatu model, tahap berikutnya adalah menentukan multiplicity dari masing-masing relasi. Multiplicity constraint digunakan untuk memeriksa dan memelihara kualitas dari data. Constraint menyatakan tentang kejadian dari suatu entiti yang digunakan

20 27 ketika suatu basisdata di-update, untuk menentukan apakah perubahan yang dilakukan melanggar peraturan yang ditetapkan oleh perusahaan. c) Memeriksa Fan Traps dan Chasm Traps Setelah relasi ditentukan, lakukan pemeriksaan terhadap relasi dalam model tersebut apakah sudah merupakan perwujudan dari dunia nyata yang sebenarnya, dan apakah fan trap dan chasm trap telah dibuat dengan sesuai atau tidak. Fan trap adalah suatu model yang menggambarkan relasi antar entiti yang alur relasinya memperlihatkan ambiguitas (kesamaan). Chasm trap adalah suatu model yang menyarankan adanya suatu relasi antar entiti yang satu dengan yang lain, tetapi tidak ada relasi yang digambarkan antara kedua entiti utama. d) Memeriksa Setiap Entiti Memiliki Relasi Minimal Satu Saat pembuatan ER Diagram, pastikan entiti mempunyai minimal satu relasi dengan entiti yang lain. Jika memang entiti sudah mempunyai minimal satu relasi dengan entiti yang lain, maka tahap berikutnya adalah memperhatikan kamus data. e) Mendokumentasikan Tipe-Tipe Relasi Bersamaan dengan tipe relasi diidentifikasi, tetapkan nama yang berarti dan jelas kepada user, lalu dokumentasikan relasi dan constraint yang beragam (multiplicity constraint) tadi ke dalam kamus data. Tahap 1.3 : Mengidentifikasikan dan Menghubungkan Atribut dengan Tipe- Tipe Entiti atau Relasinya Tujuannya untuk menghubungkan atribut dan entiti yang telah kita tentukan sebelumnya untuk direpresentasikan dalam suatu basisdata.

21 28 Tahap 1.4: Menentukan Domain-Domain Atribut Tujuannya adalah menentukan domain untuk semua atribut yang terdapat pada model data konseptual. Domain adalah suatu nilai valid dari satu atau lebih atribut (nilai valid yang berlaku bagi suatu atribut). Misalnya: Domain NIM Binusian adalah bilangan bulat sepanjang sepuluh digit; jenis kelamin dari entiti Pegawai adalah salah satu dari P atau L, jadi domain dari atribut jenis kelamin adalah sebuah karakter string tunggal yang berupa P atau L. Tahap 1.5 : Menentukan Atribut-Atribut Candidate, Primary, dan Alternate Key Tujuannya adalah menentukan candidate key untuk tiap tipe entiti dan jika terdapat lebih dari satu candidate key, pilih salah satu untuk dijadikan sebagai primary key. Ada beberapa key yang dapat diterapkan dalam sebuah tabel yaitu: candidate key, primary key, alternate key, dan foreign key. Candidate key adalah suatu set atribut dari sebuah entiti yang memiliki nilai yang unik. Primary key adalah candidate key dalam suatu relasi yang dipilih untuk menjadi Primary key dimana harga atau nilai atributnya unik dan mampu dipakai untuk membedakan satu record dengan record lainnya. Alternate key adalah candidate key yang tidak terpilih menjadi primary key. Foreign key adalah salah satu atau sejumlah atribut yang melengkapi suatu relasi (hubungan) yang menunjuk ke parent-nya. Foreign key ditempatkan pada entiti child, dan atribut foreign key-nya sama dengan primary key parent yang direlasikannya. Hubungan antara entiti parent dengan child adalah hubungan satu lawan banyak (one-to-many relationship).

22 29 Tahap 1.6 (optional step) : Mempertimbangkan Penggunaan dari Konsep Permodelan Enhanced, dengan Menggunakan Salah Satu dari Konsep Specialization / Generalization, Aggregation, dan Composition. Tahap 1.7: Memeriksa Model untuk Redundansi Tujuannya untuk memeriksa adanya redundansi di model data. Langkah pengecekannya yaitu : a) Periksa Ulang One-to-One Relationship Periksa kembali dua entiti yang menampilkan objek yang sama. Misalnya entiti Klien dan entiti Penyewa. Dalam suatu rental film, Klien adalah sinonim dari Penyewa, maka kedua entiti tersebut dapat digabung menjadi satu. Jika kedua entiti tersebut memiliki primary key yang berbeda, maka pilih salah satu untuk menjadi primary key dan yang lainnya sebagai alternate key. b) Hilangkan Redundansi dari Suatu Relasi Redundansi dari suatu relasi dapat terjadi jika informasi yang sama didapatkan melalui relasi yang lain. Sangat penting untuk memeriksa relasi di antara entiti ketika melakukan pengecekan suatu redundansi. Tahap 1.8 : Memvalidasi Model Data Konseptual Lokal Terhadap Transaksi User Tujuannya untuk meyakinkan bahwa model konseptual lokal dapat mendukung kebutuhan yang diperlukan oleh user. Di sini kita memeriksa bahwa model tersebut mendukung transaksi yang diperlukan oleh user, dua pendekatan yang dilakukan tersebut adalah :

23 30 a) Mendeskripsikan Transaksi Dalam pendekatan ini kita melakukan pemeriksaan terhadap semua informasi yang dibutuhkan seperti entiti, relasi, dan atribut yang diperlukan dalam setiap transaksi yang disediakan oleh suatu model, lalu mendokumentasikan transaksi tersebut ke dalam tiap-tiap kebutuhan transaksi. b) Menggunakan Jalur Transaksi Pendekatan ini menggunakan suatu diagram yang merepresentasikan suatu jalur pada tiap-tiap transaksi secara langsung dalam ER Diagram. Pendekatan ini juga membantu perancang untuk memvisualisasikan suatu model yang tidak diperlukan dan yang sangat kritis dalam suatu transaksi. Tahap 1.9: Meninjau Ulang Model Data Konseptual Lokal dengan User

24 31 Gambar 2.2 Model Data Konseptual untuk Staff View yang Menunjukkan Semua Atribut ( Sumber : Connolly dan Begg, 2005, p464) Perancangan Basisdata Logikal Merupakan proses membangun sebuah model dari informasi yang digunakan di dalam perusahaan berdasarkan model data yang spesifik tanpa menggunakan DBMS atau peralatan fisikal lainnya. Model data logikal meliputi : ER Diagram, skema relasional, dan dokumentasi pendukung seperti kamus data.

25 32 Di dalam perancangan basisdata logikal, tahapan utama adalah : Tahap 2: Membangun dan Memvalidasi Model Data Logikal Global untuk Setiap Sudut Pandang. Tujuannya adalah membangun model data logikal lokal dari model data konseptual lokal yang telah dibuat, yang merepresentasikan sudut pandang tertentu dari perusahaan dan memvalidasi model ini untuk memastikannya benar secara struktural (menggunakan teknik normalisasi) dan mampu mendukung kebutuhan transaksi yang diminta. Adapun kegiatan yang dilakukan pada tahap ini adalah : Tahap 2.1: Menentukan Relasi untuk Model Data Logikal Lokal Tujuannya adalah menciptakan relasi untuk model data logikal untuk mewakili entiti, tipe relasi, dan atribut yang telah diidentifikasi di tahap pertama. Relasi yang dimiliki oleh entiti yang satu dengan entiti yang lain digambarkan dengan primary key / foreign key. Yang dilakukan pertama kali adalah mengidentifikasikan terlebih dahulu entiti parent dan entiti child. Kemudian posting primary key yang ada di entiti parent ke dalam entiti child untuk berperan sebagai foreign key. Berikut adalah penjelasan bagaimana relasi-relasi dibuat untuk strukturstruktur di bawah ini yang mungkin terjadi pada model data konseptual yang telah diidentifikasi di tahap sebelumnya : a) Strong entity types Entiti kuat adalah entiti yang keberadaannya tidak bergantung pada tipe entiti lain. Untuk setiap tipe entiti kuat pada model data, buatlah sebuah relasi yang meliputi semua atribut sederhana di entiti tersebut.

26 33 b) Weak entity types Entiti lemah adalah entiti yang tergantung pada keberadaan entiti lain. Untuk setiap entiti lemah di model data, buatlah sebuah relasi yang meliputi semua atribut sederhana dari entiti tersebut. Primary key pada tipe entiti lemah diturunkan sebagian atau seluruhnya dari entiti tersebut, jadi identifikasi primary key pada tipe entiti lemah tidak dapat dibuat sampai seluruh hubungan dengan entiti asalnya telah dibuat. c) One-to-many (1:*) binary relationship types Untuk relasi one-to-many, entiti parent ditempatkan pada sisi yang memiliki relasi one dan entiti child pada sisi yang memiliki relasi many. d) One-to-one (1:1) binary relationship types Menciptakan relasi yang mewakili hubungan 1:1 lebih kompleks karena kardinalitasnya tidak dapat digunakan untuk membantu mengidentifikasi entiti parent dan child dalam sebuah hubungan. e) One-to-one (1:1) recursive relationships Relasi rekursif merupakan jenis relasi dimana setiap entiti memiliki sebuah relasi dengan dirinya sendiri. Relasi tersebut dapat digantikan dengan mengidentifikasikan sebuah entiti baru sebagai penghubung dengan hubungan one-to-many. f) Superclass / subclass relationship types Untuk setiap hubungan superclass / subclass di model data konseptual, kita mengidentifikasi setiap entiti superclass sebagai entiti parent dan entiti subclass sebagai entiti child. Ada banyak pilihan bagaimana merepresentasikan hubungan tersebut sebagai satu atau lebih

27 34 relasi. Seleksi pilihan yang paling tepat tergantung dari sejumlah faktor, seperti disjointness dan participation constraints dari hubungan superclass / subclass. Tabel 2.1 merupakan panduan untuk merepresentasikan hubungan superclass / subclass berdasarkan disjointness dan participation constraints. Tabel 2.1 Tabel Relasi Superclass / Subclass Participation constraint Mandatory Optional Mandatory Optional Disjoint constraint Nondisjoint {And} Nondisjoint {And} Disjoint {Or} Disjoint {Or} Relations required Relasi tunggal (dengan satu atau lebih pembeda untuk membedakan tipe dari setiap tuple) Dua relasi dimana satu relasi untuk superclass dan satu relasi untuk semua subclass (dengan satu atau lebih pembeda untuk membedakan tipe dari setiap tuple) Banyak relasi dimana satu relasi untuk setiap gabungan superclass / subclass Banyak relasi dimana satu relasi untuk superclass dan relasi lainnya untuk setiap subclass g) Many-to-many ( *:*) binary relationship types Jika masih ada relasi many-to-many pada model data konseptual, maka kita gantikan dengan dua buah relasi one-to-many dengan mengidentifikasikan sebuah entiti baru sebagai penghubung.

28 35 h) Complex relationship types Relasi yang kompleks adalah sebuah relasi yang terjadi antara tiga entiti atau lebih. Relasi yang kompleks ini dapat disederhanakan dengan menempatkan sebuah entiti baru di tengah entiti yang sebelumnya dan mendefinisikan relasi (binary) one-to-many di antara setiap entiti. i) Multi-valued attributes Atribut yang bernilai banyak adalah atribut yang memiliki berbagai macam nilai di dalam sebuah entiti. Kita bisa mendekomposisi atribut tersebut dan menempatkannya ke dalam entiti baru. Tahap 2.2: Validasi Relasi dengan Menggunakan Teknik Normalisasi Normalisasi digunakan untuk menghindari terjadinya duplikasi dari data. Normalisasi menjamin bahwa hasil dari model yang telah kita rancang benar-benar mencerminkan model yang ada di perusahaan, yang memiliki konsistensi, redundansi yang minimal, dan stabilitas yang maksimal. Tahap normalisasi akan dijelaskan di subbab berikutnya. Tahap 2.3 : Validasi Relasi dengan Transaksi-Transaksi yang Sesuai dengan Kebutuhan User Tujuan tahap ini adalah memvalidasi model data logikal lokal untuk menjamin agar model yang telah dirancang dapat mendukung transaksitransaksi yang diperlukan sesuai dengan kebutuhan user. Tahap 2.4 : Menentukan Batasan-Batasan Integritas Batasan-batasan integritas merupakan batasan yang digunakan untuk menjaga basisdata dari inkonsistensi. Pada tahap ini kita menentukan batasan-batasan integritas yang perlu diperhatikan, yaitu :

29 36 a) Data yang Diperlukan (Required Data) Beberapa atribut harus memiliki nilai yang valid, dengan kata lain tidak boleh ada yang bernilai NULL (tidak bernilai). Ketentuan tersebut harus diidentifikasikan pada waktu kita mendokumentasikan atributatribut di dalam kamus data (Tahap 1.3). b) Batasan Domain Atribut (Attribute Domain Constraints) Batasan domain harus diidentifikasi saat kita memilih domain atribut untuk model data (Tahap 1.4). c) Multiplicity Multiplicity mewakili batasan yang ditempatkan pada hubungan antar data dalam basisdata. d) Integritas Entiti (Entity Integrity) Ketentuan yang benar dari sebuah entiti adalah primary key dari sebuah entiti tidak boleh bernilai NULL. Batasan ini seharusnya dipertimbangkan saat kita mengidentifikasi primary key untuk setiap tipe entiti (Tahap 1.5). e) Referential Integrity Maksud dari referential key adalah jika foreign key memiliki sebuah nilai, maka nilai tersebut harus menunjuk kepada tuple (baris dalam suatu relasi) yang terdapat pada relasi parent. f) Batasan Umum (General Constraints) Batasan ini seringkali disebut sebagai aturan bisnis. Untuk melakukan perubahan pada suatu entiti harus sesuai dengan ketentuan transaksi-transaksi yang ada di dunia nyatanya.

30 37 Tahap 2.5: Review Model Data Logikal Lokal terhadap Kebutuhan User Tujuannya adalah untuk menjamin model data logikal lokal dan dokumentasi pendukung yang menjelaskan model tersebut benar-benar menggambarkan proses bisnis yang nyata dari perusahaan dan dapat mendukung transaksi sesuai dengan kebutuhan user. Tahap 2.6 (optional step) : Menggabungkan Model Data Logikal Lokal ke dalam Model Data Logikal Global - Tahap : Menggabungkan Model Data Logikal Lokal ke dalam Model Data Logikal Global Untuk menggabungkan model data logikal lokal ke dalam model data logikal global, yang harus dilakukan adalah : a) Memeriksa kembali nama dan isi dari sejumlah entiti / relasi dan candidate key-nya. Jangan sampai dua entiti / relasi atau lebih memiliki nama yang sama, tetapi pada kenyataannya memiliki peran yang berbeda, demikian juga sebaliknya. b) Memeriksa kembali nama dan isi dari relasi / foreign key. Pada tahap ini kita menjamin bahwa entiti / relasi yang memiliki nilai yang sama menggambarkan konsep yang sama di dunia nyatanya. c) Menggabungkan entiti / relasi dari model data lokal. d) Memasukkan (tanpa menggabungkan) entiti / relasi secara unik ke dalam setiap model data lokal. e) Menggabungkan relasi / foreign key dari model data lokal.

31 38 f) Memasukkan (tanpa menggabungkan) relasi / foreign key secara unik ke dalam setiap model data lokal. g) Memeriksa apakah ada entiti / relasi dan hubungan / foreign keys yang belum diidentifikasi. h) Memeriksa kebenaran dari foreign key yang terdapat di dalam relasi child dan lakukan perubahan bila perlu. i) Memeriksa batasan integritas. j) Menggambarkan ER Diagram global. k) Melakukan update dokumentasi terhadap perubahan yang terjadi selama proses pengembangan model data global. - Tahap : Memvalidasi Model Data Logikal Global Pada tahap ini kita memvalidasi relasi / hubungan yang telah dibuat dari model data logikal global menggunakan teknik normalisasi untuk menjamin agar model data tersebut dapat mendukung transaksi yang dibutuhkan. - Tahap : Review Model Data Logikal Global Terhadap Kebutuhan User Model data yang telah jadi direview kembali oleh user untuk menjamin bahwa model tersebut mencerminkan gambaran dari proses bisnis perusahaan di dunia nyatanya. Tahap 2.7 : Memeriksa Model Data untuk Kebutuhan Masa Depan Tujuannya untuk menjamin model data tersebut dapat juga mendukung kebutuhan perusahaan di masa yang akan datang.

32 39 Gambar 2.3 Diagram Relasi Global untuk DreamHome ( Sumber : Connolly dan Begg, 2005, p489) Perancangan Basisdata Fisikal Merupakan proses yang menghasilkan sebuah gambaran implementasi basisdata pada media penyimpanan yang menggambarkan hubungan dasar, organisasi data, dan indeks-indeks yang memungkinkan pengaksesan data yang

33 40 efisien. Pada umumnya, tujuan utama dari perancangan basisdata fisikal adalah menjelaskan bagaimana cara mengimplementasikan perancangan basisdata logikal secara fisik. Berikut adalah enam tahap utama dalam perancangan basisdata fisikal, yaitu : Tahap 3 : Menerjemahkan Model Data Logikal Global untuk DBMS yang Digunakan. Tujuannya adalah menghasilkan sebuah skema basisdata relasional dari model data logikal global ke dalam bentuk yang dapat diimplementasikan pada relational DBMS yang digunakan. Aktivitas pertama dari perancangan basisdata fisikal adalah menerjemahkan relasi di dalam model data logikal global ke dalam suatu bentuk yang dapat diimplementasikan pada relational DBMS yang digunakan. Bagian pertama dari proses ini memerlukan perbandingan informasi yang dikumpulkan selama perancangan basisdata logikal dan didokumentasikan ke dalam kamus data. Aktivitas kedua yaitu menggunakan informasi ini untuk menghasilkan rancangan dari base relation. Proses ini membutuhkan pengetahuan yang mendalam dari fungsi-fungsi yang dihasilkan oleh DBMS yang digunakan. Kegiatannya antara lain : Tahap 3.1 : Merancang Relasi Dasar (Base Relation) Tujuannya untuk menentukan bagaimana menggambarkan base relation yang diidentifikasikan pada model data logikal global di dalam DBMS yang digunakan.

34 41 Untuk memulai proses perancangan fisikal, kita mulai dengan mengumpulkan dan mengolah informasi tentang relasi yang dihasilkan selama perancangan basisdata logikal. Informasi yang dibutuhkan dapat diperoleh dari kamus data dan definisi dari relasi yang digambarkan menggunakan DDL. Untuk setiap relasi yang diidentifikasikan pada model data logikal global harus memiliki definisi sebagai berikut : - nama relasi - daftar atribut sederhana dalam tanda kurung besar - primary key, alternate key, dan foreign key - daftar dari atribut turunan dan bagaimana mereka dihitung - referential integrity constraint untuk setiap foreign key yang diidentifikasi Dari kamus data, setiap atribut memiliki : - domain yang terdiri dari tipe data, panjang, dan batasan lainnya yang ada pada domain - suatu nilai default optional untuk atribut-atribut - keterangan apakah atribut dapat bernilai NULL Untuk menggambarkan perancangan dari base relation, kita menggunakan suatu bentuk perluasan dari bahasa basisdata untuk mengartikan domain, default values, dan indikasi nilai NULL. Langkah selanjutnya adalah memutuskan bagaimana mengimplementasikan base relation. Keputusan ini tergantung pada DBMS yang digunakan. Rancangan dari base relation harus secara lengkap mendokumentasikan alasan dipilihnya rancangan yang diusulkan.

35 42 Tahap 3.2 : Merancang Representasi dari Derived / Calculated Data. Tujuannya untuk menentukan bagaimana menggambarkan derived data yang ada dalam model data logikal pada DBMS yang digunakan. Nilai suatu atribut yang dapat diperoleh dengan mengambil atau dari hasil perhitungan nilai atribut lainnya yang dikenal sebagai derived / calculated attributes. Sering kali, derived attribute tidak muncul dalam model data logikal, tapi didokumentasikan dalam kamus data. Jika suatu derived attribute muncul dalam model, / digunakan untuk mengidentifikasikan bahwa itu adalah derived attribute. Tahap 3.3 : Merancang Batasan Umum Tujuannya untuk merancang batasan umum untuk DBMS yang digunakan. Rancangan dari batasan umum tergantung lagi dengan pilihan dari DBMS. Beberapa sistem menyediakan lebih banyak fasilitas dari lainnya untuk mengartikan batasan umum. Seperti langkah sebelumnya, jika sistem dipenuhi dengan standar SQL, beberapa batasan dapat dengan mudah diimplementasikan. Tahap 4 : Merancang Organisasi File dan Indeks Tujuannya untuk merancang organisasi file yang optimal untuk menyimpan base relation dan indeks yang dibutuhkan untuk mencapai hasil yang dapat diterima, ini adalah cara yang ditempuh dimana relasi akan berada pada penyimpanan sekunder. Satu tujuan utama dari perancangan basisdata fisikal adalah menyimpan data dengan cara yang efisien. Kegiatan yang ada di tahap ini yaitu :

36 43 Tahap 4.1 : Analisa Transaksi. Tujuannya untuk mengerti kemampuan dari transaksi yang akan berjalan dalam basisdata dan untuk menganalisa transaksi yang penting. Untuk merancang basisdata fisikal yang efektif, kita harus memiliki pengetahuan dari transaksi atau query yang dijalankan dalam basisdata. Ini meliputi informsi yang kualitatif dan kuantitatif. Dalam menganalisa transaksi, kita mengidentifikasi kriteria kinerja, seperti : - Transaksi yang seringkali dilakukan dan mempunyai pengaruh yang signifikan pada kinerja. - Transaksi yang bersifat kritis pada operasi bisnis. - Tingkat transaksi yang tinggi selama satu hari atau satu minggu yang dihasilkan di dalam basisdata. Untuk berfokus pada area-area yang mungkin menyebabkan masalah, cara menelusurinya adalah dengan : a) Memetakan semua jalur transaksi ke relasinya. b) Memutuskan relasi mana yang paling sering diakses oleh transaksitransaksi. c) Menganalisa penggunaan data dari transaksi tertentu yang termasuk relasi tersebut. Tahap 4.2 : Memilih Organisasi File yang Sesuai untuk Setiap Relasi Dasar. Satu tujuan utama perancangan basisdata fisikal adalah menyimpan data dengan cara yang efektif. Tujuan utama dari tahap ini adalah untuk

37 44 memilih organisasi file yang optimal untuk setiap relasi sesuai dengan ketentuan DBMS yang digunakan. Tahap 4.3 : Pemilihan Indeks. Tujuannya adalah menentukan apakah dengan menambah indeks akan meningkatkan kinerja sistem. Secondary indexes menyediakan mekanisme untuk menetapkan suatu key tambahan untuk suatu base relation yang dapat digunakan untuk mendapatkan kembali data secara lebih efisien. Tahap 4.4 : Memperkirakan Kebutuhan Disk Space. Dalam proses perancangan perlu untuk melakukan estimasi terhadap jumlah disk space yang dibutuhkan untuk menyimpan basisdata. Sama seperti tahap sebelumnya, memperkirakan disk space sangat tergantung pada DBMS dan hardware yang akan digunakan untuk mendukung basisdata. Secara umum, estimasi ini berdasarkan pada ukuran setiap record dan jumlah record dalam relasi. Selain itu juga perlu dipertimbangkan faktor peningkatan transaksi di masa mendatang. Tahap 5 : Perancangan User Views Tujuannya adalah untuk merancang user view yang telah diidentifikasikan pada tahap sebelumnya. User view didefinisikan untuk menyederhanakan permintaan pada basisdata. Dalam multiuser DBMS, user view memainkan peran penting dalam mendefinisikan struktur dari basisdata dan menjalankan keamanan.

38 45 Tahap 6 : Perancangan Mekanisme Keamanan Tujuannya adalah untuk merancang standar keamanan basisdata seperti yang dispesifikasi oleh user. Suatu basisdata menggambarkan suatu sumber daya perusahaan yang penting, jadi keamanan untuk sumber daya ini sangat penting. Selama pengumpulan kebutuhan dan tahap analisa dari siklus hidup aplikasi basisdata, kebutuhan keamanan yang spesifik seharusnya didokumentasikan dalam spesifikasi kebutuhan sistem. Beberapa sistem menawarkan fasilitas yang berbeda dari sistem lainnya. Perancang basisdata harus berhati-hati dengan fasilitas yang ditawarkan oleh DBMS yang digunakan. Secara umum relational DBMS menyediakan dua tipe dari keamanan basisdata, yaitu : - Keamanan Sistem Keamanan sistem melindungi akses dan kegunaan basisdata pada tingkat sistem, seperti user name dan password. - Keamanan Data Keamanan data melindungi akses dan kegunaan dari objek basisdata (seperti relasi dan view) dan kegiatan yang user dapat lakukan pada objek. Tahap 7 : Mempertimbangkan Kemunculan Redundansi Terkontrol Tujuannya untuk menentukan apakah kemunculan redundansi secara terkontrol dengan mengendurkan aturan normalisasi akan meningkatkan kinerja sistem. Tahap-tahapnya meliputi : Tahap 7.1 : Menggabungkan relasi 1:1. Tahap 7.2 : Menduplikasi atribut non key pada relasi 1:* untuk mengurangi penggunaan joins.

39 46 Tahap 7.3 : Menduplikasi atribut foreign key pada relasi 1:* untuk mengurangi joins. Tahap 7.4 : Menduplikasi atribut pada relasi *:* untuk mengurangi joins. Tahap 7.5 : Mengenali repeating groups. Tahap 7.6 : Membuat tabel ekstraksi. Teknik yang paling umum digunakan untuk membuat tabel ini adalah dengan membuat dan mempopulasi tabel-tabel dalam sebuah proses yang dijalankan sepanjang malam di saat sistem tidak bekerja berat. Tahap 7.7 : Mempartisi relasi Ada dua cara partisi, yaitu : a) Partisi Horizontal, yaitu mendistribusikan tuples dalam sebuah relasi melalui sejumlah kecil relasi. b) Partisi Vertikal, yaitu mendistribusikan atribut-atribut dari sebuah relasi melalui sejumlah kecil relasi (primary key diduplikasi untuk memperbolehkan relasi aslinya untuk direkonstruksi). Tahap 8 : Mengawasi Sistem Operasional Setelah rancangan dasar diimplementasikan, sistem harus diawasi dan disetel. Tujuannya untuk mengawasi sistem operasional dan meningkatkan kinerja dari sebuah sistem untuk memperbaiki keputusan rancangan yang tidak sesuai atau kebutuhan yang berubah. Ada beberapa faktor yang dapat digunakan untuk mengukur efisiensi, yaitu: - Transaction Throughput Merupakan sejumlah transaksi yang dapat diproses pada interval waktu yang diberikan.

40 47 - Response Time Merupakan waktu untuk menyelesaikan transaksi tunggal. - Disk Storage Merupakan sejumlah disk space yang dibutuhkan untuk menyimpan file basisdata. Perancang bisa meminimumkan jumlah dari disk space yang digunakan. Untuk meningkatkan kinerja, perancang basisdata fisikal harus hati-hati pada bagaimana empat komponen hardware dasar mempengaruhi kinerja sistem, yaitu : main memory, CPU, Disk I/O, dan jaringan Entity-Relationship Modelling (ER Modelling) Menurut Silberschatz, Korth, dan Sudarshan (2002, p27-p34), ER Modelling memiliki tiga notasi dasar, yaitu : 1. Entiti (Entity) Yaitu sesuatu atau sebuah objek dalam dunia nyata yang dapat dibedakan dari objek-objek yang lain. Set entiti adalah sekumpulan entiti-entiti dengan tipe yang sama, yang memiliki properti-properti atau atribut-atribut yang sama. Contohnya : Nasabah, Cabang. 2. Atribut (Attribute) Yaitu properti-properti pembentuk karakteristik yang dimiliki oleh setiap anggota dari sebuah set entiti. Contohnya : pada tabel Nasabah, atributnya yaitu KodeNasabah, NoRekTab, NamaNasabah, Alamat, dan NoTelp.

41 48 3. Relasi (Relation) Yaitu hubungan di antara beberapa entiti. Set relasi adalah sekumpulan relasi dengan tipe yang sama. Di antara dua himpunan entiti (misal A dan B ) terjadi kardinalitas relasi (derajat relasi) yang berupa : Hubungan One-to-One (1:1) Berarti setiap entiti pada himpunan entiti A berhubungan paling banyak dengan satu entiti pada himpunan entiti B, dan sebaliknya setiap entiti pada himpunan entiti B berhubungan paling banyak dengan satu entiti pada himpunan entiti A. Gambar 2.4 Kardinalitas Relasi One-to-One (Sumber : Silberschatz, Korth, dan Sudarshan, 2002, p34) Hubungan One-to-Many (1:*) Berarti setiap entiti pada himpunan entiti A dapat berhubungan dengan banyak entiti pada himpunan entiti B, tetapi tidak sebaliknya, dimana setiap entiti pada himpunan entiti B berhubungan dengan paling banyak dengan satu entiti pada himpunan entiti A.

42 49 Gambar 2.5 Kardinalitas Relasi One-to-Many (Sumber : Silberschatz, Korth, dan Sudarshan, 2002, p34) Hubungan Many-to-One (*:1) Berarti setiap entiti pada himpunan entiti A berhubungan dengan paling banyak dengan satu entiti pada himpunan entiti B, tetapi tidak sebaliknya, dimana setiap entiti pada himpunan entiti B berhubungan dengan banyak entiti pada himpunan entiti A. Gambar 2.6 Kardinalitas Relasi Many-to-One (Sumber : Silberschatz, Korth, dan Sudarshan, 2002, p34) Hubungan Many-to-Many (*:*) Berarti setiap entiti pada himpunan entiti A dapat berhubungan dengan banyak entiti pada himpunan entiti B, dan sebaliknya setiap entiti pada himpunan entiti B berhubungan dengan banyak entiti pada himpunan entiti A.

43 50 Gambar 2.7 Kardinalitas Relasi Many-to-Many (Sumber : Silberschatz, Korth, dan Sudarshan, 2002, p34) Entity-Relationship Diagram (ERD) adalah model entity relationship yang berisi komponen-komponen himpunan entiti dan himpunan relasi yang masing-masing dilengkapi dengan atribut-atribut yang merepresentasikan seluruh fakta yang dapat digambarkan dengan lebih sistematis. Entity name Entiti Relationship name Relasi Relationship name Entity name Role name Relasi Rekursif dengan Role name untuk mengidentifikasi peranan entiti relasi tersebut. Entity name Attribute name Attribute 1 Attribute 2 Attribute n Atribut dituliskan di bagian bawah simbol entiti. Atribut yang merupakan primary key digarisbawahi. Atribut multi-valued diletakkan diantara {}. Relationship name One-to-one relationship Relationship name One-to-many relationship