Database


­­­­­­Database


Pengantar Kuliah Database
v  Ilmu Database
Ø  Teori Database
§  Belajar bagaimana cara merancang suatu konsep database
Ø  Pemrograman Database
§  Cursor/Recordset
·         Operasi database didasarkan pada proses secara langsung pada tabel yang bersesuaian
§  SQL
·         Operasi berdasarkan satu baris perintah untuk satu jenis operasi
§  PL/SQL
·         Operasi berdasarkan perintah prosedural (rangkaian langkah-langkah kegiatan, seperti bahasa pemrograman pada umumnya) dari perintah SQL
Ø  Aplikasi Database
§  Bagaimana membangun aplikasi yang menggunakan database
Ø  Database Lanjutan
§  Data Mining à Menggali informasi lebih jauh dari data yang tersedia
§  Ware House à Kumpulan dari berbagai data, berbagai bentuk, berbagai keperluan
§  Distributed Database System à Bagaimana cara supaya database dapat dijalankan pada daerah yang luas
v  Keterkaitan Kuliah Database dengan Kuliah lainnya

v  Tujuan kuliah database
Ø  Banyak aplikasi yang memerlukan penyimpanan
Ø  Tidak standardnya cara penyimpanan pada berbagai aplikasi yang berbeda
Ø  Muncul berbagai model penyimpanan
Ø  Menuju standardisasi database

Pengantar Database
v  Pengantar Database
Ø  Database dan Teknologi Database memiliki peran/pengaruh yang cukup pada perkembangan dunia komputer
Ø  Database adalah kumpulan dari data yang saling berkaitan. Data adalah suatu fakta yang dapat direkam/dicatat/disimpan yang memiliki arti tertentu. Contoh : Alamat, Nama, Nomor Telepon
Ø  Arti Khusus Database:
§  Representasi beberapa aspek dari dunia nyata, yang sering disebut dengan “mini world” atau “universe of Discourse (UoD)”. Jika mini world berubah, database secara keseluruhan ikut berubah
§  Kumpulan dari data-data yang saling berhubungan satu dengan lainnya yang memiliki arti tertentu
§  Dirancang, dibuat, dan dipergunakan untuk keperluan tertentu. Terdapat sekelompok pemakai dan aplikasi tertentu yang saling terikat
Ø  Database bisa berupa sistem manual atau terkomputerisasi
Ø  System manajemen database atau Database Management System (DBMS) adalah kumpulan program yang digunakan untuk pengolahan Database
Ø  Sistem Database atau Database System adalah Database dengan DBMS





Gambar Penyederhanaan ruang lingkup sistem database

Arsitektur Database
-          Database Application
-          Database Engine/Server/Service
-          Database File

Pengantar Database
Pendahuluan
            Database adalah suatu kumpulan data-data yang disusun sedemikian rupa sehingga membentuk informasi yang sangat berguna. Database terbentuk dari sekelompok data-data yang memiliki jenis/sifat sama. Ambil contoh, data-data berupa nama-nama, kelas-kelas, alamat-alamat. Semua data tersebut dikumpulkan menjadi satu menjadi kelompok data baru, sebut saja sebagai data-data mahasiswa. Demikian juga, kumpulan dari data-data mahasiswa, data-data dosen, data-data keuangan dan lainnya dapat dikumpulkan lagi menjadi kelompok besar, misalkan data-data politeknik elektronika. Bahkan dalam perkembangannya, data-data tersebut dapat berbentuk berbagai macam data, misalkan dapat berupa program, lembaran-lembaran untuk entry (memasukkan) data, laporan-laporan. Kesemuanya itu dapat dikumpulkan menjadi satu yang disebut dengan database.

Perlunya Database
            Data secara umum dapat dikatakan sebagai segala sesuatu yang dapat dikumpulkan. Tentu saja hal ini akan membuat segala sesuatu di dunia ini menjadi data, dan masing masing dapat dikumpulkan menurut jenisnya. Segala bentuk catatan mengenai data-data tersebut sebenarnya dapat dianggap sebagai database (tempat kumpulan data-data). Biasanya catatan dari data-data tersebut dilakukan dengan relatif sederhana dan dilakukan dengan cara manual (dicatat di atas lembaran-lembaran kertas, atau paling tidak diketik menggunakan program aplikasi tertentu). Setelah data-data tersebut dikumpulkan, biasanya diperlukan untuk pembuatan laporan, pengambilan keputusan atau segala sesuatu bentuk pengolahan yang berhubungan dengan data tersebut.
            Jika data-data tersebut tercatat secara manual, maka segala bentuk pengolahan juga dilakukan secara manual (disusun, dihitung atau dibuat laporannya secara manual). Cara ini tentu saja membutuhkan ekstra tenaga dan waktu. Dan lebih sering lagi, diperlukan pengumpulan data-data yang sejenis secara berkali-kali dan dilakukan juga pengolahan dan pembuatan laporan secara berkali-kali pula. Bisa dibayangkan ini merupakan pekerjaan yang sangat membosankan.
            Dari kenyataan tersebut, akan lebih mudah jika dibuat suatu sistem yang digunakan untuk menyimpan data-data tersebut secara lebih terorganisasi, dan dengan bantuan program-program aplikasi tertentu, data-data tersebut dapat diolah dan dibuat laporannya secara lebih cepat dan lebih mudah. Hal inilah yang menjadikan perlunya dibuat sistem database.

Beberapa Jenis Database
            Meskipun sebenarnya tujuan dari database tersebut sama, yaitu lebih mempermudah dalam pengolahan data, namun caranya ada berbagai macam. Macam dari database tersebut dapat dilihat dari bentuk konfigurasi sistemnya atau dari bentuk/isi dari database tersebut.
            Ada beberapa jenis dari database, mulai dari yang menggunakan text biasa, menggunakan exel, lotus, foxpro, dbase, paradoc, access, oracle, SQL dan banyak lagi. Masing-masing dapat berbeda dari sisi format datanya, fasilitas yang disediakan dan teknik pengolah databasenya (database engine).

Bentuk Umum Database
            Seperti pada uraian-uraian sebelumnya, database terdiri dari kumpulan sekelompok data, dan biasanya dinyatakan dalam bentuk tabel. Data-data tersebut tersimpan dalam suatu file. Ambil sebagai contoh data-data mahasiswa, yang terdiri dari data nama, kelas, dan NRP. Ada beberapa orang mahasiswa, misalkan 5 mahasiswa, seperti pada contoh berikut.
Tabel Mahasiswa
nomor
NAMA
KELAS
NRP
1
ANDI BARIA
II ELKA
100210001
2
KARMAN
II LISTRIK
100220003
3
SUBARI
I ELKA
100210080
4
MARIA SARI
III LISTRIK
100220033
5
UDIN PURNOMO
I LISTRIK
100220010

            Dari contoh tabel tersebut, nama, kelas dan NRP disebut dengan field (bagian data-data dengan jenis yang sama). Nomor, dapat dianggap satu field tersendiri yang berisi nomor urut dari data, atau hanya dianggap sebagai penunjuk nomor urut saja (bukan sebuah field/tidak ada, dan ditulis hanya untuk mempermudah susunan tabel). Penggunaan dari nomor ini nantinya tergantung dari pembuatan struktur database sesuai dengan yang diinginkan. Urutan data-data dengan nomor 1, 2, 3, 4 dan 5 disebut dengan record (satu kumpulan data lengkap tentang satu mahasiswa). Sedangkan keseluruhan data-data mahasiswa tersebut (terdiri dari beberapa jumlah mahasiswa), disebut dengan tabel.
            Dengan demikian, nanti akan ada data-data dari pegawai (tabel pegawai), data-data dari barang inventaris (tabel  iventaris) dan lainnya. Yang perlu diperhatikan di sini, setiap tabel-tabel tersebut dapat disimpan dalam file-file tersendiri (satu file untuk satu tabel), atau semua tabel disimpan dalam satu file. File-file tersebut disebut dengan file-file database.
MAHASISWA.DBF  - File yang berisi tabel mahasiswa
PEGAWAI.DBF        - File yang berisi tabel pegawai
KEUANGAN.DBF    - File yang berisi tabel keuangan
IVENTARIS.DBF     - File yang berisi tabel barang iventaris
            POLTEK.MDB          - File yang berisi tabel mahasiswa, pegawai, dll.

            Pada contoh di atas, ada beberapa file dengan file ekstensi *.DBF yang setiap file digunakan untuk menyimpan satu jenis tabel. Sedangkan file *.MDB adalah contoh, dimana satu file digunakan untuk menyimpan beberapa jenis tabel. Pemilihan cara penyimpanan tersebut tergantung dari perancangan databasenya atau tergantung dari jenis database yang akan digunakan. Misalkan file *.DBF biasanya digunakan pada database foxpro, dbase. Sedangkan *.MDB digunakan oleh database ACCESS.
            Di dalam penggunaannya, data-data dalam tabel tersebut perlu diolah/dibuat laporannya. Misalkan data mahasiswa kelas satu saja, atau mahasiswa jurusan listrik saja, atau mahasiswa laki-laki saja dan lain sebagainya. Untuk itu diperlukan suatu program atau pengolahan tertentu. Yang menarik di sini adalah, program-program pengolahan atau laporan-laporan tersebut dapat dianggap juga sebagai data, sehingga dapat juga disimpan dalam suatu file database. Namun ini hanya dapat dilakukan pada jenis-jenis database tertentu saja.
Agar file-file database dapat diolah dengan mudah, diperlukan suatu database engine. Database engine adalah suatu program khusus yang dibuat untuk menangani suatu file-file database. Dengan adanya database engine ini, program-program aplikasi yang menggunakan database, tidak memerlukan program khusus untuk pengolahan database (tidak diperlukan pengetahuan khusus mengenai format/susunan dari file-file database). Selain itu, dengan database engine ini, jika ingin mengembangkan aplikasi database yang berbeda, program aplikasi dapat dengan mudah menggunakan database engine yang sama.
            Database engine yang digunakan harus sesuai dengan jenis database yang digunakan agar database engine mengenali dan dapat mengolah file-file database tersebut (karena ada berbagai jenis database, maka setiap jenis dari database tersebut memerlukan database engine yang berbeda pula).







 







 


Gambar a. Tanpa database engine. b. Dengan database engine

            Program aplikasi yang dimaksudkan di sini adalah program-program tertentu yang dikembangkan dan menggunakan database. Misalkan program iventarisari peralatan lab, yang digunakan untuk penyimpanan barang-barang lab dan pembuatan laporan kondisi barang lab.

Konfigurasi Database
            Selain ada beberapa jenis perbedaan database dilihat dari file-file database itu sendiri, database juga dibedakan dari susunan/konfigurasi dari sistem database. Yang terbanyak dapat dibagi menjadi tiga bagian.

Database lokal
Jika file-file database, program database engine dan program aplikasi terletak pada satu mesin komputer yang sama, maka konfigurasi seperti ini disebut dengan database lokal. Keuntungan utama dari konfigurasi ini adalah sederhana, tidak memerlukan banyak peralatan, murah dan tidak banyak memerlukan perhatian khusus.
Kekurangan, tidak dapat multi-user (lebih dari satu user menggunakan database secara bersama-sama), tidak dapat remote access (database dijalankan dari kejauhan).


 









Gambar Database Lokal

Database file server
Jika file-file database diletakkan pada satu komputer khusus (server), sedangkan database engine dan program aplikasi diletakkan pada komputer lain (tersendiri) dan masing-masing komputer tersebut terhubung dalam satu jaringan komputer, maka konfigurasi seperti ini disebut sebagai file server (server hanya melayani file-file database). Kuntungan utamanya adalah, file-file database tersebut dapat digunakan oleh lebih dari satu pengguna (multi-user).
Kekurangan, komunikasi dalam jaringan berat (database engine melakukan proses yang sangat intensif dengan database file melalui jaringan komputer)


 









Gambar Database File Server

Database client-server
            Kalau pada file server, server hanya digunakan untuk menyimpan file database, maka pada client-server, server digunakan untuk menyimpan file database maupun database engine-nya. Database dan database engine terintegrasi menjadi satu yang disebut dengan database server. Pada sisi client hanya terdapat program aplikasi. Dengan teknik ini, client menjadi lebih ringan cara kerjanya karena semua operasi atau proses database dilakukan oleh server. Client hanya perlu untuk memerintahkan pengolahan database dan menerima hasil jadinya.


 










Gambar Database Client Server



v  Arsitektur Umum Database
Ø  Desktop/Form
§  Local Database
§  File Server Database
§  Client Server
§  Kelebihan
·         Operasi lebih cepat dan lebih mudah dalam pembuatan aplikasi
·         Lebih bersifat private (suatu aplikasi hanya digunakan sendiri oleh pihak-pihak yang berkepentingan)
§  Kekurangan
·         Proses pengembangan aplikasi dan instalasi menjadi berat, karena setiap instalasi atau perubahan aplikasi harus dimasukkan satu per satu pada setiap client yang memerlukan
·         Tidak dapat digunakan secara global (suatu aplikasi tidak dapat digunakan secara ramai-ramai oleh banyak orang dimanapun berada)
Ø  Aplikasi Web
§  Kelebihan à mengatasi kekurangan Desktop/Form
§  Kekurangan à aplikasi lambat dan masalah keamanan yang cukup kompleks
§  Aplikasi Database berbasis Web (Web Database)









Ø  Jumlah Tier
§  Single Tier
§  2-Tier
§  3-Tier




PERTEMUAN KE 3

v  Contoh Macam-macam DBMS
Ø  Berbentuk File
§  DBase à *.DBF
§  Fox Pro à *.DBF
§  Paradox à *.DB
§  ACCESS à *.MDB
Ø  Berbentuk Server
§  InterBase
§  MySQL
§  MS SQL Server
§  ORACLE

v  Sebuah Contoh
Ø  Database Universitas, meliputi mahasiswa, matakuliah, nilai, kuliah, masing-masing disimpan pada file terpisah
Ø  Mendefinisikan struktur record setiap file, dengan menentukan jenis dari setiap datanya. Misal mahasiswa terdiri atas nrp, nama, kelas dan sebagainya
Ø  Menyediakan data untuk setiap file dengan data yang sesuai. Ada kemungkinan, suatu data dari suatu file berhubungan dengan data lain pada file lainnya
§  Contoh Struktur Database dan Datanya

MAHASISWA
Nama
NRP
Kelas
Jurusan

Andi
123456789
1
1

Edi
214365870
2
1


Ø  Pada database yang besar, bisa terdapat sejumlah file dengan struktur yang besar, serta banyak hubungan (relasi) antar data-data tersebut
Ø  Adanya manipulasi database, yang terdiri dari query dan pengubahan data (updating).

v  Karakteristik dari Pendekatan Database
Ø  Beberapa perbedaan, antara pendekatan pengolahan file dan database
§  Pada pengolahan file, setiap pengguna mendefinisikan sendiri data-data dalam file yang diperlukan untuk aplikasi tertentu. Muncul adanya redundansi
§  Pada pendekatan database, satu kumpulan data hanya didefinisikan sekali saja, dan dapat digunakan oleh lebih dari satu pengguna
Ø  Karakteristik utama dari pendekatan database dibandingkan pendekatan file,
§  Dengan sendirinya menjelaskan sifat alami dari sistem database
§  Isolasi antara Program dan Data, dan Abstraksi Data
§  Dapat melihat data dari berbagai sudut pandang
§  Bagi-bagi Pemrosesan Data dan Transaksi Multi-user

v  Pelaku Utama pada Sistem Database
Ø  Administrator Database
§  Mengatur Akses pengguna
§  Koordinasi dan mengawasi
§  Mempersiapkan sumber daya
Ø  Perancang Database
§  Mendefinisikan data-data yang akan disimpan pada database, serta menentukan struktur yang sesuai
§  Mengerti keperluan database dari sudut pandang pengguna
Ø  Pengguna Akhir
§  Yang menjalankan suatu aplikasi tertentu yang berhubungan dengan database
Ø  System Analyst dan Programmer Aplikasi
§  System Analyst menentukan kebutuhan dari pengguna akhir, dan membuat spesifikasi tertentu
§  Programmer Aplikasi membuat program sesuai dengan yang telah direncanakan
§  System Analyst dan Programmer Aplikasi sering disebut sebagai Perekayasa Software (software engineers)

v  Pelaku Pembantu pada Sistem Database
Ø  Perancang dan Pembuat Sistem DBMS
Ø  Pengembang/Pembuat Alat Bantu
Ø  Operator dan Perawat Database

v  Kelebihan Penggunaan DBMS
Ø  Mengendalikan adanya Redudansi. Mencegah setiap pengguna memiliki data yang sama
Ø  Membatasi adanya akses pengguna yang tidak diinginkan. Ada beberapa pengguna yang dibatasi kemampuan aksesnya pada data-data tertentu.
Ø  Dapat digunakan sebagai penyimpan tetap untuk obyek program dan struktur data. Ini diterapkan pada Database berorientasi obyek
Ø  Dapat digunakan untuk menghasilkan data-data tambahan yang berasal dari data-data yang telah ada
Ø  Bisa digunakan untuk lebih dari satu pengguna secara bersamaan
Ø  Dapat digunakan untuk menunjukkan hubungan antar data yang cukup rumit sekalipun
Ø  Menyediakan integritas data yang baik
Ø  Menyediakan keperluan backup dan recovery
v  Implikasi dari Pendekatan Database
Ø   
v  Kapan Tidak Menggunakan DBMS

Konsep dan Arsitektur System Database
v  Model Data, Skema dan Instant
Ø  Kategori dari Model Data
Ø  Skema, Instant dan State Database
§  Skema Database, terdiri atas Konstruksi Skema, Misal Mahasiswa, Jurusan

MAHASISWA
Nama
NRP
Kelas
Jurusan

JURUSAN
Kode
Nama


v  Arsitektur DBMS dan Ketidak-tergantungan Data
Ø  Arsitektur Tiga Skema (Tiga Tingkat Abstraksi)
Ø  Ketidak-Tergantungan Data
v  Bahasa Database dan Interface
Ø  Bahasa DBMS
Ø  Interface DBMS
v  Lingkungan Sistem Database
v  Klasifikasi dari Sistem Manajemen Database



PERTEMUAN KE 4

Pemodelan Data menggunakan Model Entity-Relational (ER)
v  Menggunakan Model Data Konsepsual Tingkat Tinggi untuk Perancangan Database
Ø  Penyederhanaan Penjelasan Proses Perancangan Database
§  Analisis Kebutuhan, untuk mendapatkan Kebutuhan Database dan Kebutuhan Fungsional
§  Perancangan konsepsual, untuk mendapatkan Skema konsepsual (HLDM) dan Analisis Fungsional untuk mendapatkan Spesifikasi Transaksi Tingkat Tinggi
§  Perancangan Logikal, untuk mendapatkan Skema Logikan (Konsepsual) (DBMS)
§  Perancangan Fisikal, untuk mendapatkan Skema Internal (Fisik) dan Perancangan Program Aplikasi
§  Implementasi Transaksi, untuk mendapatkan Hasil akhir berupa Program Aplikasi

v  Contoh Aplikasi Database, PERUSAHAAN
Ø  Data-data : PEGAWAI, DEPARTEMEN, PROYEK
Ø  Mini-word/Spesifikasi/User Requirement :
§  Perusahaan dibagi dalam Departemen. Tiap Departemen memiliki Nomor dan Nama yang unik, Pegawai tertentu yang membawahi Departemen (Manajer), dan catat Awal Pegawai tersebut sebagai Manajer. Setiap Departemen bisa memiliki beberapa Lokasi
§  Sebuah Departemen mengendalikan beberapa Proyek. Setiap Proyek memiliki Nomor dan Nama yang unik, serta satu Lokasi.
§  Data Pegawai yang disimpan antara lain, Nama, NIP, Alamat, Gaji, Sex, Tanggal Lahir. Setiap Pegawai menempati satu Departemen, dan mungkin bekerja pada beberapa Proyek, yang mungkin di bawah Departemen lain. Dicatat jumlah Jam/Minggu setiap Pegawai yang bekerja pada tiap Proyek. Termasuk Pengawas untuk tiap Pegawai.
§  Perlu dicatat Tanggungan  tiap Pegawai, dengan mencatat Nama, Sex, Tanggal Lahir dan Hubungan Keluarga.

v  Istilah-istilah
Ø  Entity
§  Strong, Weak
Ø  Attribute
§  Key, Partial Key, Atomic, Multi-valued, Composite, Derived
Ø  Relationship
§  Participation
·         All, Partial
§  Ratio
·         One to One, One to Many, Many to Many
Ø  Tuple
Ø  Instance
v  Jenis Entitas, Set Entitas, Atribut dan Kunci (Key)
Ø  Model ER Menggambarkan Data sebagai Entiti, Hubungan Relasi, dan Atribut.
Ø  Entitas dan Atribut
§  Entiti adalah representasi dari obyek dasar pada Model ER, yang benar-benar secara fisik (contoh orang) atau Konsepsual (contoh perusahaan) ada dan tidak saling bergantung keberadaannya.
§  Atribut adalah sesuatu yang dimiliki oleh Entiti dan menjelaskan segala sesuatu yang berhubungan dengan Entiti.
·         Atribut Sederhana (Atomik) atau Komposit (gabungan atribut sederhana)
·         Atribut dengan satu nilai atau banyak nilai (jamak)
·         Atribut yang tersimpan dan Turunan
·         Atribut dengan nilai NULL
¨      Ada kemungkinan bernilai NULL, atau banyak sekali yang bernilai NULL (tidak diisi)
·         Atribut Kompleks
¨      Kombinasi dari berbagai macam atribut
Ø  Jenis Entitas, Set Entitas, Kunci dan Set Nilai
§  Kumpulan (Set) Entitas yang memiliki atribut sama disebut dengan Jenis Entitas (Entity Type)
§  Jenis Entitas dinyatakan dengan Nama dan Atributnya
§  Atribut Kunci (Key) adalah atribut yang dapat digunakan untuk membedakan satu informasi dengan informasi lainnya dalam suatu entity, yang disebut dengan keunikan (Uniquely)
Ø  Perancangan Kosepsual Awal dari Database PERUSAHAAN
v  Hubungan Relasi, Jenis Hubungan Relasi, Role dan Konstrain Struktural
Ø  Jenis Hubungan Relasi, Set dan Instan
Ø  Jenis-jenis Derajat Relasi
§  Adalah jumlah entiti yang berpartisipasi pada suatu relasi
§  Relasi dua entiti berarti derajad dua, disebut binary
§  Relasi tiga entiti berarti derajad tiga, disebut ternary
§  Derajad relasi dapat berapa saja, namun derajad dua adalah yang paling umum
Ø  Relasi sebagai Atribut
§   
Ø  Nama Role dan Hubungan Relasi Rekursif
§  Nama role adalah nama yang digunakan untuk menunjukkan peran/kegunaan dari suatu entiti dalam suatu relasi
·         Contoh, relasi antara dosen dan mahasiswa dalam memberikan bimbingan tugas akhir (MEMBIMBING). Bagi dosen disebut sebagai PEMBIMBING dan bagi mahasiswa disebut YANG_DIBIMBING (BIMBINGAN atau nama lainnya)
§  Relasi rekursif adalah relasi yang terjadi pada entiti yang sama
·         Contoh, pada entiti pegawai ada kemungkinan relasi antara pegawai dengan pegawai, misalkan relasi MENGATUR/MENGAWASI (TO MANAGE/SUPERVISE), dimana ada yang diatur dan ada yang mengatur (MANAGER/SUPERVISOR)
Ø  Konstrain pada Jenis Hubungan Relasi
§  Perbandingan kardinaliti
·         One to one                 
¨      1 Pegawai menjadi Kajur 1 Jurusan
¨      1 Jurusan memiliki Kajur 1 Pegawai
¨      1 Pegawai bisa menjadi Kajur 1 Jurusan atau tidak (Tidak semua Pegawai menjadi Kajur) dan maksimal 1 Pegawai menjadi Kajur pada 1 Jurusan (0,1)
¨      1 Jurusan memiliki Kajur dari 1 Pegawai (Semua Jurusan memiliki Kajur) dan Maksimal 1 Jurusan dipegang oleh 1 Pegawai (1,1)
·         One to many              
¨      JURUSAN : PEGAWAI memiliki perbandingan 1 : N
¨      1 Jurusan memiliki banyak Pegawai yang Bekerja
¨      1 Pegawai Bekerja pada 1 Jurusan
¨      1 Pegawai minimal Bekerja pada 1 Jurusan (Semua Pegawai Bekerja pada Jurusan) dan maksimal 1 Pekerja Bekerja pada 1 Jurusan (1,1)
¨      1 Jurusan Minimal memiliki 2 Pegawai dan Maksimal banyak Pegawai (2,N)
·         Many to many            
¨      1 Pegawai Mengerjakan banyak Proyek
¨      1 Proyek Dikerjakan oleh banyak Pegawai
¨      1 Pegawai minimal Mengerjakan 1 Proyek dan maksimal banyak Proyek
¨      1 Proyek minimal Dikerjakan oleh 1 Pegawai dan maksimal banyak Pegawai
§  Partisipan
·         Total/All
¨      Semua menjadi bagian dari relasi
·         Partial
¨      Ada anggota yang tidak ikut dalam relasi, contoh relasi PEGAWAI dan JURUSAN dengan relasi KAJUR, tidak semua PEGAWAI menjadi KAJUR pada suatu JURUSAN
Ø  Atribut dari Jenis hubungan Relasi
v  Jenis Entitas “Weak”
Ø  Sebuah entity seharusnya dapat dibedakan antara satu informasi dengan informasi lainnya, sehingga harus memiliki satu atau gabungan beberapa atribut yang dapat digunakan sebagai pembeda, yang disebut dengan key
Ø  Jika key yang ada benar-benar dapat digunakan sebagai pembeda, artinya bersifat uniks (tidak ada yang sama), maka suatu entity dikatakan kuat
Ø  Jika key yang ada memiliki beberapa informasi yang mirip, maka dikatakan key tersebut bersifat tidak penuh (partial), sehingga entity disebut sebagai entity lemah
v  Perbaikan Perancangan ER untuk Database Perusahaan
v  Diagram ER, Perjanjian Penamaan, Isu Perancangan
Ø  Notasi Diagram ER
§  (Strong) Entity                 
·         Pegawai memiliki atribut NIP yang dapat digunakan sebagai kunci
§  Weak Entity                     
·         Keluarga tidak memiliki atribut tertentu yang dapat digunakan sebagai kunci
§  Relationship                     
·         Jika Dosen dan Mahasiswa bertemu pada Jam dan Ruangan tertentu untuk membahas Matakuliah tertentu akan terjadi proses Mengajar
§  Identifying Relationship  
·         Pegawai Menanggung Keluarga
§  Attribute                          
·         Sex merupakan informasi yang sederhana
§  Key Attribute                   
·         NRP merupakan atribut yang dapat digunakan untuk membedakan satu Mahasiswa dengan lainnya
§  Partial Key Attribute       
·         Nama adalah atribut yang dapat digunakan untuk membedakan Keluarga satu dengan lainnya, namun kemungkinan ada yang sama
§  Multi-valued Attribute     
·         Dalam beberapa hal, ada seseorang yang memiliki lebih dari satu alamat
§  Composite Attribute        
·         Dalam beberapa hal, alamat dapat dipecah menjadi beberapa atribut yang lebih sederhana
§  Derived Attribute            
·         Atribut umur tidak perlu disimpan, tetapi dapat dihitung dari tanggal lahir
§  Total Participation of Entity In Relationship       
·         Total Participation      
¨      Semua Dosen harus sebagai Pembimbing
·         Partial Participation
¨      Tidak semua Mahasiswa mengambil TA
§  Cardinality Ratio
·         One to One                
¨      1 Jurusan memiliki 1 Pegawai sebagai Kajur
¨      1 Pegawai bekerja sebagai Kajur pada 1 Jurusan
·         One to Many              
¨      1 Jurusan memiliki N (banyak) Pegawai yang bekerja
¨      1 Pegawai bekerja pada 1 Jurusan
·         Many to Many                       
¨      1 Dosen Membimbing M (banyak) Mahasiswa
¨      1 Mahasiswa Dibimbing oleh N (banyak) Dosen
§  Structural Constraint (min, max) on Participation of Entity in Relationship
·         1 Jurusan harus memiliki minimal 4 sampai N Pegawai yang bekerja
·         1 Pegawai harus bekerja minimal 1 sampai 1 Jurusan
Ø  Penamaan yang Benar dari Pembentukan Skema
Ø  Pilihan Perancangan untuk Perancangan konsepsual ER
Ø  Notasi Alternatif untuk Diagram ER

5. Tata cara penggambaran ERD
v  Penggambaran harus sesuai dengan kebiasaan (model yang umum digunakan)
v  Jangan menggunakan konsep perancangan secara praktek, karena akan mengalami kebingungan saat menggambar ERD. Anggap bahwa komponen dari ERD adalah Entiti, Atribut, Relasi dan garis-garis penghubung. Jangan berfikir mengenai tabel, primary key, foreign key
v  Gambarkan semua item dalam mini world selengkap mungkin, jangan ditambahi atau dikurangi. Untuk memudahkan, catat/coret item yang sudah digambarkan
v  Jika ada suatu permasalahan yang belum jelas (tidak tertulis dalam mini world), dapat dianggap berlaku secara umum (asumsi yang biasa digunakan)
v  Pemahaman pada suatu mini world bisa muncul perbedaan, tergantung bagaimana melihat suatu mini world dari sudut pandang tertentu. Yang penting proses pemindahan dari mini world ke dalam model ERD tidak ada yang terlewatkan dan salah
v  Periksa/catat adanya entiti
Ø  Entiti adalah suatu item yang dia dapat berdiri sendiri (tidak menjelaskan item lainnya, dan keberadaannya tidak bergantung item lain), serta ada item lain yang menjelaskan entiti tersebut
v  Periksa semua atribut dari suatu entiti
Ø  Atribut dari entiti adalah suatu item yang digunakan untuk menjelaskan suatu entiti dan keberadaannya disebabkan entiti tersebut. Atribut dari entiti ini adalah suatu item yang tidak berhubungan dengan entiti lain
Ø  Jika ada yang dianggap sebagai atribut, tetapi terdapat suatu entiti yang dapat dianggap mewakili atribut tersebut, maka atribut ini dianggap sebagai relasi dari kedua entiti tersebut. Misalkan, mahasiswa memiliki dosen wali. Mahasiswa adalah entiti, dan jika tidak ada entiti lain yang berhubungan dengan dosen wali, maka dosen wali dapat dianggap sebagai atribut dari entiti mahasiswa. Namun jika terdapat entiti, misalkan dosen, maka dosen wali dapat dianggap berupa relasi antara mahasiswa dan dosen
Ø  Jika ada di antara atribut tersebut yang dapat dianggap sebagai kunci utama, entiti dianggap sebagai entiti kuat, jika tidak, dianggap entiti lemah
§  Kunci utama adalah atribut yang nilainya unik (tidak ada yang sama) pada entiti tersebut. Kunci utama bisa terdiri dari satu atribut untuk mendapatkan nilai yang unik. Atribut ini ditandai sebagai kunci utama.
§  Meskipun suatu entiti lemah tidak memiliki atribut yang bernilai unik yang dapat digunakan sebagai kunci utama, setidaknya ada atribut yang dapat dianggap sebagai kunci sementara. Misalkan nama, dan tandai sebagai kunci lemah
v  Periksa adanya relasi
Ø  Relasi adalah adanya sesuatu yang menyebabkan lebih dari satu entiti saling bertemu (muncul suatu urusan atau kegiatan atau hubungan antar entiti)
Ø  Periksa partisipan dari relasi, semua atau tidak
Ø  Periksa perbandingan relasi, satu atau banyak
Ø  Relasi bisa muncul pada lebih dari dua entiti
v  Periksa adanya atribut dari suatu relasi
Ø  Atribut ini muncul karena adanya suatu relasi dan hanya digunakan untuk menjelaskan relasi tersebut

v  Keterangan
Ø  Seorang Pengawas adalah Pegawai yang ditugaskan sebagai Pengawas, karena itu, Pengawas menjadi suatu relasi “Pegawasan” antara Pegawai sebagai Pengawas dan Pegawai yang Diawasi
Ø  Nama atau Keterangan pada tiap relasi menunjukkan fungsi relasi dari tiap-tiap entity

PERTEMUAN KE 5

Latihan

PERTEMUAN KE 6

QUIZ


PERTEMUAN KE 7

Pengubahan/Mapping dari ERD ke Skema Database
v  Pendahuluan
Ø  Dua level Skema
§  Logical (conceptual) Level : Bagaimana User menterjemahkan skema relasi dan arti dari atributnya. Level ini akan memberikan pengertian yang benar mengenai data-data dalam suatu relasi.
§  Implementation (storage) Level : Bagaimana baris-baris data disimpan dan diubah.
Ø  Pendekatan perancangan DB
§  Bottom-up design methodology (sintesis) : Dari atribut-atribut yang ada, disusun relasi-relasinya
§  Top-down design methodology : Berangkat langsung dari pengelompokan atribut-atribut beserta relasinya
v  Istilah-istilah
Ø  Skema
§  Suatu gambaran mengenai entiti-entiti beserta atributnya yang saling berelasi
Ø  Entiti
Ø  Atribut
Ø  Relasi
Ø  Instance
§  Suatu nilai atau data atau isi dari entiti
Ø  Tuple
§  Baris data dari instance
v  Catatan
Ø  Pada tahap Pemetaan (mapping atau pembuatan skema), jangan menambahkan atribut baru, misalkan atribut kunci, dengan alasan tidak ada kunci atau alasan lainnya. Lakukan penambahan kunci dan sebagainya pada tahap masih di ERD atau di spesifikasinya. Pada saat Pemetaan (mapping atau pembuatan skema), tidak diperkenankan menambahkan atribut baru, kecuali entiti baru hasil dari relasi N:M atau relasi orde lebih dari 2 atau hasil dari Normalisasi.
Ø  Penambahan kunci baru dapat dilakukan nanti, jika pada tahap Normalisasi (biasanya NF1) ditemukan data yang redundant sehingga harus dibuatkan entiti baru dan terpaksa diberikan atribut kunci baru untuk entiti baru tersebut
v  Entiti
Ø  Gambar skema dari entiti sangat bergantung dari atribut yang dimiliki oleh entiti tersebut
Ø  Atribut Tunggal
§  Atribut tunggal digambarkan dalam bentuk satu kolom atribut dan satu baris (tuple)
Ø  Atribut Turunan
§  Atribut turunan tidak perlu digambarkan, karena ia nantinya (dari program aplikasi) dapat diturunkan dari atribut lainnya
Ø  Atribut Kunci Utama (memiliki nilai unik)
§  Atribut ini dapat terdiri dari satu atribut atau gabungan beberapa atribut yang memiliki nilai unik dan digambarkan dengan pemberian garis bawah
Ø  Atribut Kunci Sementara
§  Seperti pada kunci utama, hanya digambarkan dengan garis titik-titik
Ø  Atribut Komposit
§  Dapat digambarkan sebagai beberapa atribut tunggal dengan jumlah atribut sesuai jumlah atribut komposit
§  Dapat dibuatkan tabel baru dengan relasi 1:1
Ø  Atribut Jamak
§  Seperti pada atribut tunggal, namun memiliki beberapa baris (tuple) sesuai dengan jumlah atribut
Cara menyimpan data:
·         Normalisasi langsung à Atribut jamak diganti dengan entiti baru, dimana nama entiti sama dengan nama atribut dan entiti tersebut memiliki atribut referensi yang sama dengan kunci utama dari entiti sebelumnya, dan atribut jamak
Ø  Catatan: Istilah Redundansi (ada data yang sama)
§  Adalah suatu data yang memang arti atau maksudnya sama yang disimpan lebih dari satu kali
·         Contoh, data jurusan Elektronika disimpan lebih dari satu kali
¨      Tidak mungkin ada dua jurusan yang tidak sama tetapi memiliki nama yang sama
·         Jika data-data tersebut sangat sederhana dan tidak dapat disederhanakan lagi, maka tidak mengapa ada redundansi
¨      Contoh, KODE_JURUSAN, misalkan jurusan Elektronika dikodekan dengan nilai 1, maka tidak mengapa kode 1 disimpan dibanyak tempat, asalkan bukan nama Elektronika yang disimpan di banyak tempat
§  Ini berbeda dengan istilah unik atau tidak unik
§  Tidak unik artinya ada kemungkinan data-data yang berbeda memiliki nilai yang sama
·         Contoh, dua orang yang perbeda bisa memiliki nama yang sama
v  Relasi 1:1
Ø  Relasi dapat diwaliki dengan menambahkan atribut kunci utama (entiti dengan partisipan sebagian/parsial) beserta atribut pada relasi tersebut pada entiti dengan partisipan lebih banyak/penuh (why, sebab menghindari banyaknya nilai NULL)
Ø  Relasi dengan partisipan sama-sama penuh, dapat dimasukkan pada salah satu entiti.
§  Sebenarnya kedua entiti ini dapat dijadikan satu, karena pasti memiliki jumlah tuple yang sama, dengan relasi 1:1
Ø  Relasi dengan parsisipan sama-sama sebagian, dimasukkan pada entiti dengan derajat partisipan paling banyak/penuh
v  Relasi 1:m
Ø  Relasi dapat diwakili dengan menambahkan atribut kunci utama dari entiti yang memiliki relasi 1, termasuk atribut pada relasi tersebut, menjadi atribut dari entiti yang memiliki relasi
v  Relasi m:n
Ø  Relasi m:n harus diubah menjadi entiti baru dengan atribut terdiri dari atribut kunci utama dari kedua entiti, serta kalau ada atribut pada relasi tersebut
v  Relasi lebih dari 2 entiti
Ø  Relasi ini dapat dipecah menjadi beberapa relasi dari dua entiti dan aturan pemetaannya sama dengan sebelumnya
Ø  Relasi dapat juga dibentuk menjadi entiti baru dengan atribut sesuai dengan atribut kunci utama dari setiap entiti, termasuk kalau ada atribut dari relasi tersebut

PERTEMUAN KE 8

Ketergantungan Fungsional (Functional Dependency, FD)
v  Pengertian
Ø  Nilai dari suatu atribut dipengaruhi/tergantung dari nilai atribut lain
v  Suatu konstrain antara dua set atribut
v  Atribut Y bergantung dari atribut X dalam suatu relasi R : X à Y, sehingga
Ø  Akan selalu t1[X] = t2[X] maka t1[Y] = t2[Y], dimana t1 dan t2 adalah tuple dalam R
§  A à B, Jika A maka B, Implikasi
A
B
A à B
Salah
Salah
Benar
Salah
Benar
Benar
Benar
Salah
Salah
Benar
Benar
Benar
§  Pengujian dilakukan untuk semua keadaan A dan B
§  Pengujian paling singkat adalah, B tidak bergantung dari A jika B salah tetapi A benar
·         Jika ada data pada A yang sama, maka apakah data pada B ada kemungkinan tidak sama, jika demikian maka artinya tidak B tidak bergantung dari A
v  Contoh
ABSENSI_MAHASISWA

NRP
NAMA
JURUSAN
KULIAH
TANGGAL
KAJUR
1
1234
Agung
IT
Database
12-01-2008
Arna
2
1235
Enok
IT
Database
12-01-2008
Arna
3
1236
Nono
IT
Database
12-01-2008
Arna
4
1237
Sugi
IT
Database
12-01-2008
Arna
5
1244
Agung
ELKA
RE
12-01-2008
Syafruddin
6
1246
Nanang
ELKA
RE
12-01-2008
Syafruddin
7
1248
Munir
ELKA
RE
12-01-2008
Syafruddin
8
1234
Agung
IT
Database
19-01-2008
Arna

Ø  NRP à NAMA ? Ya
§  t1[NRP]=t8[NRP] à t1[NAMA]=t8[NAMA]
§  Untuk NRP yang sama tidak mungkin dengan dua NAMA yang berbeda
Ø  NRP à JURUSAN ? Ya
§  Untuk NRP yang sama tidak mungkin dua JURUSAN yang berbeda
Ø  NAMA à JURUSAN ? Tidak
§  t1[NAMA]=t5[NAMA] à t1[JURUSAN]≠t5[JURUSAN]
§  Untuk NAMA yang sama (nama kembar) ada kemungkinan JURUSAN yang berbeda
Ø  NRP à KULIAH ? Tidak
§  Untuk NRP yang sama ada kemungkinan KULIAH yang berbeda (lebih dari satu mata kuliah)
Ø  NRP à TANGGAL ? Tidak
§  Untuk NRP yang sama ada kemungkinan pada TANGGAL yang berbeda (kuliah lain pada tanggal yang lain)
Ø  NRP à KAJUR ? Ya
§  Untuk NRP yang sama tidak mungkin ada dua KAJUR yang berbeda
Ø  JURUSAN à KAJUR ? Ya
§  Untuk JURUSAN yang sama tidak mungkin memiliki KAJUR yang berbeda
Ø  KULIAH à NRP ? Tidak
§  Untuk KULIAH yang sama ada kemungkinan NRP berbeda (beda orang)
Ø  TANGGAL à NRP ? Tidak
§  Pada TANGGAL yang sama ada kemungkinan beda NRP (orang lain)
Ø  KULIAH, TANGGAL à NRP ? Tidak
§  Ada kemungkinan KULIAH dan TANGGAL sama, tetapi NRP berbeda (orang lain)
Ø  KULIAH, NRP à TANGGAL ? Ya
§  Untuk satu KULIAH dengan NRP yang sama tidak mungkin ada dua TANGGAL yang berbeda (kecuali kuliah dilakukan dua kali)
Ø  Dalam kasus NRP à JURUSAN, NRP à KAJUR, tetapi JURUSAN à KAJUR, maka ketergantungan fungsionalnya dapat dibuat NRP à JURUSAN à KAJUR, artinya KAJUR bergantung secara tidak langsung kepada NRP.
Ø  Sehingga diagram FD
v  Mengingat banyak kemungkinan adanya saling ketergantungan, maka untuk memudahkan dapat dibuat asumsi-asumsi atau berdasarkan pengamatan sesuai dengan biasanya, suatu atribut biasanya bergantung dengan atribut apa, atau suatu atribut biasanya mempengaruhi atribut apa saja.

Normalisasi
v  Pengertian
Ø  Alasan
§  Informasi dengan Redundansi dalam Tuple
·         Suatu baris data (tuple) memiliki informasi (sekelompok atribut) yang sama dengan baris data lainnya. Ini akan menyebabkan terjadinya ketidak-normalan (Anomaly) pada saat proses pengubahan data (Update)
§  Ketidak-normalan dalam Update
·         Jika akan melakukan penambahan data baris baru dengan kelompok atribut tertentu yang sama dengan data yang sudah ada (misalkan departemen), maka data baru tersebut harus benar-benar sama. Kesulitan akan muncul jika data baru tersebut belum ada pada data yang lama, maka kemungkinan yang dilakukan adalah mengisikan data kosong atau membuat tabel khusus untuk menyediakan data atribut tersebut.
·         Jika melakukan penghapusan pada suatu baris yang mengandung informasi penting pada suatu atribut, maka ini akan menghilangkan informasi tersebut. Lain halnya jika informasi disimpan pada tabel terpisah
·         Jika melakukan pengubahan suatu baris yang memiliki kelompok atribut tertentu (misalkan departemen), maka harus juga dilakukan pengubahan pada semua baris data yang memiliki kelompok atribut yang sama
§  Null Values pada Tuple
·         Jika suatu skema memiliki banyak relasi (relasi yang gemuk/fat relation), maka akan banyak kemungkinan saat melakukan pengisian data, tidak semua atribut terisi yang akan menyebabkan pemborosan media simpan. Hal ini juga banyak menimbulkan masalah saat dilakukan operasi tertentu, misalkan menjumlahkan atau menghitung suatu atribut yang banyak mengandung nilai Null, bisa berarti, tidak digunakan, tidak diisi, atau isinya salah, dan seterusnya.
Ø  Kapan melakukan dan tidak melakukan
v  Super key, Key, Candidate key, Primary Key
Saat suatu skema dianalisa berdasarkan contoh instant, ada atribut atau beberapa atribut atau kombinasi dari beberapa atribut yang memiliki nilai unik, artinya tidak sama satu dengan lainnya. Atribut-atribut tersebut dapat digunakan sebagai key.
Ø  Super key
§  Kombinasi dari beberapa atribut (1 s/d semua atribut) dijadikan kunci (key)
Ø  Key
§  Adalah atribut yang dapat digunakan sebagai kunci (key) dari suatu skema (entiti). Salah satu dari super key yang paling sederhana.
Ø  Candidate key
§  Jika suatu skema memiliki lebih dari satu key, maka setiap key disebut candidate key
Ø  Primary Key
§  Salah satu dari candidate key umumnya dianggap sebagai primary key.
Ø  Contoh, dalam skema PEGAWAI, ada beberapa atribut yang dapat digunakan sebagai key, misalkan
§  {NIP}, atau {NIP, NAMA}, atau {NIP, NAMA, TGLLAHIR}, ketiganya disebut sebagai super key dari PEGAWAI
§  {NIP} dianggap sebagai key
§  Jika {NIP} dan {NAMA} keduanya dapat dianggap key (misalkan isi dari NAMA dianggap unik), maka keduanya dianggap sebagai candidate key, dan NIP dapat dianggap sebagai primary key
v  First Normal Form (1NF)
Ø  Tidak diperkenankan atribut dengan nilai jamak, komposit, dan segala kombinasinya yang akan menyebabkan redundansi
Ø  Contoh
§  Departemen{DNUMBER, DNAME,DMGR,DLOC}
§  DLOC memiliki kemungkinan lebih dari satu lokasi
§  Skema DEPARTEMEN dengan kunci DNUMBER
§  Instant DEPARTEMEN
§  1NF dengan Redundansi, Kunci menjadi {DNUMBER dan DLOC}
§  1NF tanpa redundansi, tabel dipecah menjadi dua
Ø  Contoh Lain:
§  CASHFLOW{NO_TRANSAKSI, ITEM, JUMLAH, NOMINAL, STATUS}
§  STATUS adalah atribut yang berisi data ”Keluar”/”Masuk” atau ”Debit”/”Kredit”
§  Dalam aplikasinya nanti, proses untuk memasukkan data ”Keluar” atau ”Masuk” bisa menimbulkan kesalahan data yang menyebabkan ketidak-konsistenan cara penulisan
§  Normalisasi NF1, STATUS dijadikan entiti baru dengan atribut STATUS dan atribut kunci baru (misalkan) KODE.

CASHFLOW
NO_TRANS
ITEM
JUMLAH
NOMINAL
STATUS
12345
Mendapat Bonus
1
1000000
MASUK
12346
Membeli Sampoo
2
50000
KELUAR
12347
Membeli Rujak
1
10000
KELUAR
12348
Menerima Bagi-hasil
1
500000
MASUK

Dilakukan NF1 menjadi:

CASHFLOW
NO_TRANS
ITEM
JUMLAH
NOMINAL
STATUS
12345
Mendapat Bonus
1
1000000
1
12346
Membeli Sampoo
2
50000
2
12347
Membeli Rujak
1
10000
2
12348
Menerima Bagi-hasil
1
500000
1

STATUS
KODE
STATUS
1
MASUK
2
KELUAR

Ø  Contoh Lain:
§  SISWA{NRP, NAMA, KELAS, JENIS_KELAMIN}
§  Jika penulisan JENIS_KELAMIN misalkan ”Laki-laki” atau ”Pria” atau ”Perempuan” atau ”Wanita” bisa menimbulkan masalah konsistensi
§  Kalau penulisan menggunakan ”L”/”P” atau ”1”/”2” masih dianggap benar
§  Normalisasi NF1, JENIS_KELAMIN dijadikan entiti baru dengan atribut KODE sebagai key dan JENIS_KELAMIN

Ø  Catatan:
§  Perbedaan antara redundansi dan tidak unik à lihat penjelasan mengenai mapping pada atribut jamak
§  Masalah penambahan kunci baru pada entiti yang tidak memiliki kunci (dianggap banyak data yang kembar atau tidak unik) à lihat penjelasan pada Catatan saat dilakukan mapping
·         Data yang “kebetulan kembar” bukan masalah, yang tidak diperbolehkan adalah data yang “benar-benar kembar” à lihat penjelasan mengenai perbedaan redundansi dan tidak unik.
Ø  Contoh lain:
§  Anggap ada suatu relasi MELANGGAR antara SISWA dan GURU dengan rasio N:M sehingga dalam mapping-nya harus dibuatkan entiti baru
§  Pada entiti baru tersebut memiliki atribut NRP, NIP, TANGGAL dan PELANGGARAN
§  Contoh data-datanya
NRP
NIP
TANGGAL
PELANGGARAN
1234
1111
12-01-2010
Mencontek
1233
2222
01-02-2010
Terlambat
1234
2222
10-03-2010
Membuang sampah sembarangan
1234
1111
12-03-2010
Memakai sandal
1233
1111
12-03-2010
Merokok di kelas
1235
1111
12-03-2010
Memakai kaos oblong
1235
1111
12-03-2010
Rambut Gondrong
1235
1111
12-03-2010
Mencoret-coret bangku

§  Apakah atribut NRP, NIP dan TANGGAL tidak unik ? Ya, karena memang banyak data yang kembar
§  Apakah atribut tersebut redundant ? Ya, karena pada atribut tersebut digunakan untuk menyimpan data yang memang maksudnya sama. Contoh NRP 1235 disimpan berulang-ulang
§  Apakah entiti tersebut perlu dibuatkan kunci yang bersifat unik ? Tidak perlu, selama entiti PELANGGARAN dianggap memang tidak memerlukan kunci.
·         Kalau memang diinginkan suatu kunci ? Harus sudah dibuat sejak dirancang spesifikasi atau ERD, misalkan NO_PELANGGARAN
§  Apakah entiti tersebut perlu dinormalisasi (dipisahkan NRP, NIP dan TANGGAL menjadi entiti baru) ? Tidak
·         Mengapa ? Karena atribut tersebut sudah berupa data yang dianggap sederhana dan mungkin tidak dapat disederhanakan lagi.
·         Contoh, apakah ada kunci lain sebagai pengganti NRP ? Kalau ada, kunci ini seharusnya sudah digunaan saat merancang spesifikasi atau ERD
·         Contoh, apakah ada data lain yang lebih sederhana untuk menggantikan tanggal ?
§  Contoh tabel yang sama namun dengan data-data yang berbeda
NRP
NIP
TANGGAL
PELANGGARAN
1234
1111
12-01-2010
Mencontek
1233
2222
01-02-2010
Merokok di kelas
1234
2222
10-03-2010
Memakai kaos oblong
1234
1111
12-03-2010
Memakai sandal
1233
1111
12-03-2010
Merokok di kelas
1235
1111
12-03-2010
Memakai kaos oblong
1235
1111
12-03-2010
Rambut Gondrong
1235
1111
12-03-2010
Mencontek
§  Apakah atribut NRP, NIP, TANGGAL dan PELANGGARAN tidak unik ? Ya, karena memang banyak data yang kembar
§  Khusus untuk NRP, NIP dan TANGGAL sudah dibahas pada penjelasan sebelumnya
§  Apakah atribut PELANGGARAN berisi data yang redundant ? Ya, karena berisi data yang maksudnya sama
§  Apakah entiti tersebut perlu dinormalisasi dengan memisah atribut PELANGGARAN menjadi entiti baru ? Bisa Ya, bisa Tidak. Loh ?
§  Jika data-data pada atribut PELANGGARAN dimaksudkan berupa data yang bersifat mandiri, berupa keterangan yang boleh ditulis bebas, tidak mengapa menuliskan dengan cara yang berbeda meskipun maksudnya sama, maka tidak perlu dilakukan normalisasi.
·         Contoh, tidak mengapa menuliskan pelanggaran, misalkan, ”Memakai sandal”, dan kadang ditulis ”Memakai sandal jepit”.
§  Namun, jika diinginkan untuk jenis-jenis pelanggaran yang sama harus persis dituliskan sama, dan kelak ingin dilakukan analisa dengan cara mengelompokkan jenis pelanggaran, maka ini harus dilakukan normalisasi


v  Second Normal Form (2NF)
Ø  Ketergantungan fungsional secara penuh
§  Suatu atribut harus bergantung sepenuhnya dengan kunci utama, tidak boleh dengan kombinasi antara kunci utama dengan atribut lain
Ø  Contoh
§  Kuliah {Hari, Jam, Ruang MataKuliah}
·         Misalkan, ruang kuliah selalu sama pada satu hari, tetapi mata kuliah berbeda untuk jam kuliah tertentu
§  Ruang bergantung Hari (bergantung penuh)
§  MK bergantung Hari dan Jam (bergantung sebagian/tidak penuh/parsial)
§  Skema
§  Instant
§  Normalisasi bentuk ke dua (2NF)
v  Third Normal Form (3NF)
Ø  Ketergantungan fungsional langsung
§  Suatu atribut harus bergantung secara langsung dengan kunci utama, tanpa melalui perantara atribut lain (bergantung tidak langsung)
Ø  Contoh
§  Data Pegawai {NIP, NAMA, ALAMAT, LULUSAN, JURUSAN, KAJUR, SEKJUR}
§  Nama, Alamat, Lulusan, Jurusan bergantung langsung dengan NIP
§  Kajur dan Sekjur bergantung langsung dengan Jurusan dan bergantung tidak langsung dengan NIP
§  Skema
§  Instant
§  Normalisasi bentuk ke 3 (3NF)
v  Catatan:
Ø  Jika perancangan ERD dilakukan secara detil (segala aspek diperhitungkan), biasanya yang sering dilakukan hanya sampai NF1 (membuang redundansi), Sedangkan NF2 dan NF3 hampur tidak perlu dilakukan
Ø  Jangan menambahkan atribut baru, misalkan atribut kunci, dengan alasan tidak ada kunci atau alasan lainnya. Lakukan penambahan kunci dan sebagainya pada tahap masih di ERD atau di spesifikasinya. Pada saat Pemetaan (mapping atau pembuatan skema), tidak diperkenankan menambahkan atribut baru, kecuali entiti baru hasil dari relasi N:M atau relasi orde lebih dari 2 atau hasil dari Normalisasi.

PERTEMUAN KE 9

ER yang Lebih Maju dan Pemodelan Object
v  Sub-Klas, Super-Klas dan Turunan
v  Spesialisasi dan Generalisasi
v  Konstrain dan Karakteristik dari Spesialisasi dan Generalisasi
v  Pemodelan dari Jenis UNION menggunakan Kategori
v  Sebuah Contoh Skema UNIVERSITAS EER dan Definisi Formal untuk Model EER
v  Pemodelan Obyek Konsepsual Menggunakan Diagram Klas UML
v  Jenis Hubungan Relasi yang Derajatnya Lebih dari Dua

PERTEMUAN 10

Model Data Relasi, Pembatasan Relasi dan Aljabar Relasi
v  Konsep Model Relasi
Ø  Domain, Atribut, Tuple dan Relasi
Ø  Karakteristik dari Relasi
Ø  Notasi Model Relasi

v  Konstrain Relasi dan Skema Database Relasi
Ø  Konstrain Domain
Ø  Konstrain Kunci dan konstrain Null
Ø  Database Relasi dan Skema Database Relasi
Ø  Integritas Entiti, Integritas Referensi, dan Kunci “Foreign”

v  Operasi Update dan Dealing dengan Pelanggaran Konstrain
Ø  Operasi Penyisipan
Ø  Operasi Penghapusan
Ø  Operasi Pengubahan

v  Operasi Aljabar Relasi Dasar
Ø  Operasi PROJECT (p)
§  Memilih Atribut mana yang akan ditampilkan
§  Format :
§  Contoh :
Ø  Operasi SELECT (s)
§  Memilih Tuple mana saja dari suatu relasi R yang akan ditampilkan
§  Format :
§  Contoh :
Ø  Urutan Operasi dan Operasi RENAME
Ø  Operasi Teori Set
§  Union
·         Menggabungkan tuple dari dua relasi
§  Intersect
·         Mencari tuple yang sama dari dua relasi
§  Different
·         Mencari selisih dari suatu relasi
Ø  Operasi JOIN ()
§  Cartesian (Cross Product)
·         Mencari semua kemungkinan yang ada (perkalian silang dua relasi)
·         Format : A  B
·         Hasil :
¨      Atribut merupakan gabungan dari atribut kedua relasi
¨      Tuple merupakan kombinasi (perkalian) dari tuple kedua relasi
§  Inner Join (Equi Join)
·         Mencari data yang ada pada kedua relasi (memasangkan data)
·         Format : A Kondisi Join B
·         Contoh : A A.X=B.X B
·         Hasil :
¨      Atribut merupakan gabungan dari atribut kedua relasi
¨      Tuple merupakan tuple sesuai dengan kondisi dari kedua relasi
§  Outer Join
·         Mencari data tidak ada pasangannya
¨      Format : A Kondisi Join B
¨      Contoh : A A.X=B.X B
¨      Hasil :
Ø  Atribut merupakan gabungan dari atribut kedua relasi
Ø  Tuple merupakan tuple sesuai dengan kondisi dari kedua relasi
·         Left Join
¨      Sisi kiri memiliki data yang tidak ada pasangannya pada sisi kanan
¨      Format : A Kondisi Join B
¨      Contoh : A A.X=B.X B
¨      Hasil :
Ø  Atribut merupakan gabungan dari atribut kedua relasi
Ø  Tuple merupakan tuple dari relasi sisi kiri yang tidak memiliki pasangan pada sisi kanan sesuai dengan kondisi dari kedua relasi
·         Right Join
¨      Sisi kanan memiliki data yang tidak ada pasangannya pada sisi kiri
¨      Format : A Kondisi Join B
¨      Contoh : A A.X=B.X B
¨      Hasil :
Ø  Atribut merupakan gabungan dari atribut kedua relasi
Ø  Tuple merupakan tuple dari relasi sisi kanan yang tidak memiliki pasangan pada sisi kiri sesuai dengan kondisi dari kedua relasi
·         Full Join
¨      Mencari data yang tidak memiliki pasangan baik pada sisi kiri maupun pada sisi kanan. Merupakan gabungan dari Left Outer Join dan Right Outer Join
¨      Format : A Kondisi Join B
¨      Contoh : A A.X=B.X B
¨      Hasil :
Ø  Atribut merupakan gabungan dari atribut kedua relasi
Ø  Tuple merupakan tuple dari relasi sisi kiri dan kanan yang tidak memiliki pasangan pada sisi lain sesuai dengan kondisi dari kedua relasi
Ø  Set Lengkap dari Operasi Aljabar Relasi
Ø  Operasi DIVISION
Ø  Soal
§  Buat Aljabar Relasi untuk mencari mata-kuliah apa saja yang telah diambil oleh mahasiswa semua jurusan kelas 3 program d3 yang mata-kuliah-nya telah dihapuskan dalam proses ekuivalensi saat terjadi pergantian kurikulum. Tampilkan nama mahasiswa beserta jurusannya dan mata-kuliah yang dihapus

v  Operasi Relasi Tambahan
Ø  Fungsi Aggregate dan Pengelompokan (Grouping)
Ø  Operasi “Recursive Closure”
Ø  Operasi OUTER JOIN dan OUTER UNION

PERTEMUAN 11

v  Contoh Query pada Aljabar Relasi
Ø  Skema : Mahasiswa, Dosen, Jurusan, Kelas, Program


Ø  Buat Aljabar Relasi untuk
§  Menampilkan semua data Program Studi
·        
§  Siapa Kajur jurusan Elektronika
·        
atau
·        
§  Menampilkan Data Lengkap Jurusan
§  Menampilkan Data Lengkap Kelas
§  Menampilkan Data Mahasiswa Satu Kelas (NRP, NAMA) untuk Program D3, Jurusan Elektronika, Kelas 2B
Ø  Query 4
Ø  Query 5
Ø  Query 6
Ø  Query 7

PERTEMUAN 12

v  SQL - Standard Database Relasi
Ø  SQL à Structured Query Language
Ø  SEQUEL à Structured English QUEry Language
Ø  Perintah untuk operasi Database dalam bentuk
§  Berupa satu perintah tunggal untuk satu operasi yang ditulis dalam satu baris (biasanya) perintah
Ø  Pertama kali dibuat oleh IBM, dan digunakan dalam DB2
Ø  Pertama kali distandardisasi oleh ANSI tahun 1986 (ANSI SQL 1986)
Ø  Diperbaiki dalam standard SQL ’92 kemudian SQL’99
Ø  SQL dalam DBMS tertentu tidak dapat murni mengikuti standard SQL karena
§  Tergantung DBMS
§  Tergantung Kemampuan
§  Tergantung Riwayat/Sejarah
Ø  SQL dapat dibagi dalam
§  Data Retrieval à SELECT
§  DDL à CREATE, DROP, ALTER, TRUNCATE
§  DML à INSERT, DELETE, UPDATE
§  DCL à GRANT, REVOKE
§  Transaction Control à COMMIT, ROLLBACK, SAVEPOINT
Ø  SELECT
§  Proyeksi (Single-Row Function)
§  Seleksi (Single-Row Function)
·         Perbandingan à =, >, <, <>, >=, <=
·         Boolean à AND, OR
·         Fungsi Single Row à Tergantung DBMS
·         Ekspresi Matematik à *, +, - , /
·         Range à BETWEEN … AND …
·         List à IN(…,…,…,…)
·         Null à IS NULL, IS NOT NULL
§  Join
·         Kartesian
·         Inner (Equi)
·         Outer (Left Outer, Right Outer, Full Outer)
§  GROUP
·         Format : SELECT List_Proyeksi_SingleRow, List_Proyeksi_MultiRow FROM Tabel/Join WHERE List_Seleksi_SingleRow GROUP BY List_Proyeksi_SingleRow HAVING List_Seleksi_MultiRow
·         List_SingleRow pada bagian proyeksi boleh dibuang
·         Multi-Rows Function
·         HAVING
§  Operasi SET
·         UNION
·         UNION ALL
·         INTERSECT
·         DIFFERENCE
§  Sub Query
§  VIEW

PERTEMUAN 13

Ø  DDL
Ø  DML
Ø  DCL
Ø  Transaction Control
v  ER dan Pemetaan dari EER ke Relasi, dan Bahasa Relasi Lainnya
v  Contoh dari System Manajemen Database Relasi (DBMS): Oracle dan Microsoft Access
v  Konsep dari Database Berorientasi Obyek
v  Standard Database Obyek, Bahasa dan Perancangan
v  Relasi Obyek dan Sistem Database Relasi yang Lebih Maju

v  Algoritma Perancangan Database Relasi dan Ketidak-tergantungan
v  Perancangan dan Tuning Database Praktis
v  Arsitektur Sistem Database dan Katalog Sistem
v  Pemrosesan Query dan Optimasi
v  Konsep Pengolahan Transaksi
v  Teknik Pengendalian Konkuren (Pengerjaan Parallel)
v  Teknik Recovery Database
v  Pengamanan dan Autorisasi Database
v  Model Database yang Lebih Maju untuk Aplikasi Lanjutan
v  Database Terdistribusi dan Arsitektur Client-Server
v  Database Deduksi
v  Data Warehousing dan Data Mining
v  Teknologi Database Emerging dan Aplikasi

PERTEMUAN XVI

Organisasi Penyimpanan Record dan File Primer

Struktur Indeks untuk File
v  Penyimpanan à Tidak memerlukan waktu ekstra untuk menyimpan, karena informasi mengenai tuple sudah didapatkan secara pasti
Ø  Tuple Baru à Selalu setelah tuple terakhir (atau pada DBMS tertentu bisa tuple yang tidak digunakan)
Ø  Ubah Tuple à Tuple berasal dari proses pencarian
Ø  Hapus Tuple à Tuple berasal dari proses pencarian
v  Pembacaan à Muncul masalah kecepatan, yaitu diperlukan pencarian untuk mendapatkan beberapa data dari sejumlah data
Ø  Baca Tuple à Hanya untuk baca data dari suatu tuple
Ø  Ubah Tuple à Untuk proses pengubahan data pada suatu tuple
Ø  Hapus Tuple à Untuk proses menghapus data pada suatu tuple
v  Cara mempercepat proses pencarian
Ø  Perangkat Keras
§  Partisi Disk secara fisikal (bukan logikal) à menggunakan beberapa disk, dengan setiap disk untuk data tertentu
§  Penyimpanan secara cluster à entiti-entiti yang berhubungan disimpan dalam disk secara berdampingan
Ø  Perangkat Lunak
§  Index
·         Maksud à Menyalin atribut-atribut tertentu dalam suatu entiti terpisah sekaligus mengurutkan atribut tersebut, serta menyimpan posisi tuple dari entiti aslinya
·         Tujuan à Mempercepat proses pencarian data berdasarkan kata kunci dari suatu atribut yang di-index-kan
·         Mekanisme
¨      Mencari data dari entiti index untuk mendapatkan posisi tuple pada entiti aslinya
¨      Mendapatkan data dari entiti aslinya berdasarkan posisi tuple yang telah ditemukan pada entiti index
·         Macam
¨      ISAM
¨      B-Tree, B+-Tree
¨      Hash
¨      Bitmap
¨      Tabel terorganisasi dalam bentuk Indeks à hanya satu index
·         Batasan/Masalah
¨      Jumlah tuple yang dibaca/dicari kurang dari 10%
¨      Kardinalitas/jumlah data yang berbeda (distinct) lebih dari 10
¨      Hanya menggunakan index jika diperlukan
Ø  Masalah kapasitas penyimpanan
Ø  Index akan selalu di-update setiap terjadi penyimpanan data
¨      Hindarkan penggunaan index pada aplikasi yang melakukan transaksi dalam jumlah yang besar dalam interval waktu tertentu dan memiliki jumlah tuple yang besar

Silabus Database

1.     Pengantar Kuliah Database
2.     Sistem Database
a.      Konsep Dasar
i.       Database dan Pengguna
ii.     Konsep dan Arsitektur System Database
iii.   Pemodelan Database
3.     Perancangan Database
a.      Keterkaitan dengan matakuliah lain : RPL, Pemrograman, Arsitektur Komputer, Jaringan
b.     Praktis : User à User Requirenment à Sistem Analis (Doc Flow Diagram, DFD, ERD) à DBA (ERD) dan Supervisor (DFD) à Programmer
c.      Konsep : Mini word (User Requirenment) à Rancangan Konsepsual à Rancangan Fisikal (DBMS)
d.     Contoh Perancangan dari mini word sampai mendapatkan skema
4.     Pemodelan pada Skema Secara Konsep
a.      Pemodelan Data menggunakan Model Entity-Relational (ER)
i.       Entiti (& Weak Entity)
ii.     Atribut (Tunggal, Jamak, Kompleks, Key, Turunan, …)
iii.   Relasi (1:1, 1:N, N:M, Partisipan, Bersyarat, …)
b.     Model Data Relasi, Pembatasan Relasi dan Aljabar Relasi
c.      Pemodelan Data menggunakan DFD
d.     Hubungan Relasi Entitas yang lebih maju dan Pemodelan Obyek
5.     Latihan - Pemodelan pada Skema Secara Konsep
6.     Latihan - Quiz
7.     Mapping dari ERD ke Skema Database
a.      Entiti dengan Atribut
b.     Relasi antar Entiti
c.      Relasi yang memiliki Atribut
8.     Ketergantungan Fungsional dan Normalisasi untuk Database Relasi
a.      Ketergantungan Fungsional
b.     Bentuk Normal Pertama (1NF)
c.      Bentuk Normal Kedua (2NF)
d.     Bentuk Normal Ketiga (3NF)
9.     Latihan – Perancangan sampai tahap Normalisasi
10. UTS
11. Struktur Indeks untuk File
12. Aljabar Relasi
13. SQL
a.      Standard Database Relasi, Dasar-dasar
b.     DDL
i.       Constraint (primary, foreign, unique, not null, check)
c.      DML
14. SQL
a.      SELECT
i.       Proyeksi
ii.     Seleksi
iii.   Join
15. SQL – Lanjutan
a.      Group, Having
b.     Sub Query
c.      In Line View
16. SQL - Latihan
17. DBMS – ORACLE - SQL – Lanjutan
a.      VIEW
b.     Trigger
18. PL/SQL
a.      Dasar-dasar
b.     Stored Procedure
i.       Prosedur
ii.     Fungsi
19. Database Aplikasi
a.      Komponen Database
b.     Arsitektur Database
c.      Masalah Koneksi Aplikasi dengan Database
d.     Database Web
i.       Konsep  tier
ii.     Macam-macam pemrograman berbasis Web
20. Optimasi Database
a.      Optimasi pada Server Database
b.     Optimasi pada perintah SQL


Iklan Atas Artikel

Iklan Tengah Artikel 1

Iklan Tengah Artikel 2

Iklan Bawah Artikel