Pengertian ERD dan Contoh ERD (Kardinalitas pada Entitas)

Kardinalitas Entitas
Kardinalitas Entitas adalah penentuan berapa banyak relasi suatu entitas antara entitas satu dengan yang lainnya.
kardinalitas hanya didefinisikan 3 macam:
0 - tidak ada
1 - satu
n - banyak
untuk menentukan banyaknya sesuai 3 macam di atas harus disesuaikan dengan aturan bisnis/organisasi/system yang ada atau biasa disebut SOP(Standart Operating Procedure)
Misalkan menentukan kardinalitas pada sistem penilaian belajar yang di dalamnya terdapat entitas siswa dan matapelajaran. Kita bisa menggunakan pertanyaan:
- bolehkah siswa mengambil pelajaran tertentu?
- matapelajaran manakah yang boleh di ambil atau tidak diambil?
- adakah kuota jumlah siswa pada mata pelajaran tertentu?
tentu pertanyaan diatas mempunyai jawaban yang berbeda-beda baik dimasing-masing sekolah maupun dimasing-masing universitas.

Kardinalitas Atribut
Kardinalitas pada atribut adalah representasi dari jumlah entitas dalam bentuk alur data(data flow)  yang didefinisikan melalui DFD(Data Flow Diagram).
Melalui kardinalitas dapat diketahui bahwa setiap atribut mempunyai minimum kardinalitas yaitu 0 atau 1 dan maksimum kardinalitas yaitu 1 atau banyak.

Minimum:
0   Atribut tersebut adalah optional, boleh ada boleh tidak
1  atribut tersebut harus ada (Not Null)
Maksimum:
1  atribut Normal
N  atribut tersebut melakukan pengulangan (repeating), sehingga proses normalisasi dapat segera dilakukan.

Contoh studi kasus ERD dan kardinalitas entitas:
jika aturan sekolah mempunyai aturan sebagai berikut :
- suatu matapelajaran harus di ajar minimal 1 pengajar dan maximal banyak pengajar
- seorang pengajar tidak boleh mengajar lebih dari satu pelajaran.
maka hubungan kardinalitas entitasnya sebagai berikut:
one to many = 1:n
karena 1 entitas matapelajaran bisa di ajarkan minimum 1 guru dan maximum n entitas guru, namun sebaliknya 1 entitas guru minimum bisa mengajar 1 entitas matapelajaran dan maximum hanya 1 matapelajaran.

Read More

Pengertian ERD dan Contoh ERD

ERD kependekan dari Entity Relationship Diagram, ERD merupakan diagram yang bisa membantu dalam menentukan table-table(entitas-entitas) dan field-fieldnya yang benar
agar tidak terjadi redundancy data, bingung? ok saya gambarkan.
Karena tidak ada larangan dalam membuat table atau entitas, maka boleh saja seorang analis menyusun table seperti berikut:










Gambar di atas menunjukkan bahwa NoIndukSiswa '101'; Nama 'Ahmad'; dan TahunMasuk '2010' di tulis berulang-ulang.
Jika setiap ada penilaian rapot per semester, siswa SD bersekolah selama 6 tahun atau 12 semester jadi 1 siswa tertulis namanya saja terulang minimal 12 kali jika dia tidak pernah tinggal kelas, bayangkan jika total jumlah siswanya pertahunnya 500 berarti total tertulis berulang nama 'Ahmad' tadi (belum NoInduk dan TahunMasuk) 500x12, berarti jika table itu untuk merekap selama 8 tahun maka 12 x 8 x 500, hitung sendiri ya...

Jadi penyusunan table seperti itu untuk kebutuhan database tidak salah namun tidak efektif. Karena mengalami redundancy data (data di tulis berulang).
Terus solusinya bagaimana , muncullah kaidah relational database, yaitu table yang saling terelasi satu sama lain dalam sebuah database.

Konsep ERD
Pengertian entitas adalah elemen yang terlibat dalam sistem baik yang abstrak maupun yang real. Contoh dalam sistem 'penilaian siswa' di atas 'nilai', 'semester', dan 'mata pelajaran'
adalah sesuatu yang abstrak, sedangkan siswa adalah sesuatu yang real. Entitas-entitas inilah yang akan digambarkan dalam sebuah table. Dari pengertian tersebut maka akan ada
beberapa table dalam sistem penilaian yang saya gambarkan  yaitu tabel siswa, tabel nilai, table semester, dan table matapelajaran.

Pengertian entitas adalah elemen yang terlibat dalam sistem baik yang abstrak maupun yang real. Contoh dalam sistem 'penilaian siswa' di atas 'nilai', 'semester', dan 'mata pelajaran'
adalah sesuatu yang abstrak, sedangkan siswa adalah sesuatu yang real. Entitas-entitas inilah yang akan digambarkan dalam sebuah table. Dari pengertian tersebut maka akan ada
beberapa table dalam sistem penilaian yang saya gambarkan  yaitu tabel siswa, tabel nilai, table semester, dan table matapelajaran.

Hubungan Antar Entitas
Ditetapkan oleh business role dalam system Belajar mengajar seperti ini : suatu pelajaran di ajarkan lebih dari satu kali pertemuan dalam suatu kelas dan sebaliknya suatu kelas
menerima beberapa kali pertemuan suatu mata pelajaran dan masing-masing berbeda-beda, misal matematika dan bahasa Indonesia bisa 36 kali dalam satu semester tapi kesenian Cuma 16 kali dll.
Maka ERD-nya adalah sebagai berikut :

Cara membacanya:
1.    Mata Pelajaran Harus di selenggarakan minimal di satu kelas dan boleh lebih dari satu kelas
Maksudnya kelas 1a menerima pelajaran matematikaSD1 begitu juga 1b juga menerima pelajaran matematikaSD1
2.    Kelas minimal mengajarkan suatu mata pelajaran yang di ajarkan minimal 1(one) kali pertemuan, dan maksimal lebih dari satu pertemuan (many).

Jadi Hubungan dua entitas di atas adalah many to many n:n. Penjelasan mengenai hubungan atau relasi antar table akan saya jelaskan pada tulisan lanjutannya ya..
semoga bermanfaat..!

Read More

Pengertian Database

Database adalah asosiasi dari sebuah sistem yang ada didunia nyata. bingung? ok sebentar saya jelaskan kawan. Contoh jika ada sistem penggajian maka kita akan membutuhkan database penggajian saat membuat sistem informasinya.

Di dalam sistem nyata ada komponen yang lebih kecil (baik yang riil maupun yang abstrak,)
komponen terssebut dinamakan entitas atau entity misal yang riil misal:pegawai, gaji, dll.
yang abstrak misal:jabatan, transaksi penerimaan gaji, dll. Dalam database sebuah entitas sering digambarkan sebuah tabel. Maka dalam database penggajian akan ada table pegawai, gaji, golongan, transaksi dll.

Di dalam dunia nyata masing-masing entitas ini mempunyai komponen yang lebih kecil lagi yang dinamakan atribut. misal entitas:pegawai punya atribut:nip, nama, alamat dll. Maka atribut ini jika di gambarkan dalam sebuah database adalah kolom atau field-field sebuah table. jadi dalam table pegawai ada kolom (field) nip, nama, alamat dll. Dalam sebuah entitas pasti akan ada satu atribut kunci, dimana tidak akan pernah sama antara satu objek denga yang lainnya misalkan pada entitas pegawai ada atribut NIP(Nomor Induk Pegawai) dimana tidak  pernah sama antara pegawai satu dan pegawai lainnya, meskipun dia punya nama yang sama. Dalam table atribut kunci ini biasa dinamakan primary key. Objek pegawai-pegawai dalam table di asosiasikan row atau baris, jadi row-row pada NIP tidak akan sama.

             SYSTEM                                                                                                DATABASE

=

Contoh database

ok faham? belajar mudah bukan...

Read More

Setting Codeigniter Untuk Auto Switch Domain Server

Biasanya untuk mengatasi high-availability(ketersedian tinggi) pada server aplikasi tidak jarang kita menyediakan lebih dari satu server agar auto-switch-domain, berikut cara setting auto-switch domain pada CodeIgniter :
Buka path codeigniter/application/config/config.php dan gantilah isi $config["base_url"] dengan kode di bawah ini :

switch($_SERVER["SERVER_NAME"]) {
    case "localhost":
        $config["base_url"] =  
          "http://localhost/path/to/codeigniter/";
        break;
    case "mydomain.com":
        $config["base_url"] = "http://www.mydomain.com/";
        break;
}

Terimakasih semoga bermanfaat

Read More

SQL Server 1.g - Meng-copy Data dengan Log Shipping

Log Shipping merupakan solusi high availability yang sudah sejak lama di perkenalkan dari SQL Server version 2000.
Dia seperti halnya miroring mempunyai server utama yang biasa di sebut primary (dalam istilah log shipping) dan server duplikat biasa di sebut scondary (dalam istilah log shipping) ,
namun kelebihan log shipping adalah :
- bisa mempunyai server duplikat lebih dari 1.
- bisa beda version antara primary dan scondary.
- hanya memanfaatkan fungsi backup dan recovery database.
- lebih murah biaya
Kinerja Log shipping sebagai berikut : server mengcopy transaction-log satu atau beberapa database pada server primary kemudian meng-copy nya pada satu atau beberapa server secondary.
Kita bisa menambahkan server monitor untuk men-tracking (memeriksa) informasi tentang status log-shipping dengan menggunakan alert job.
Penempatan server monitor ini bisa dibebankan server primary maupun scondary. Namun jika ingin meningkatkan performa alert job makan kita harus membangun server monitor sendiri
terpisah dari server primary maupun scondary.
Semua server yang terlibat dalam log-shipping harus menggunakan salah satu dari edition SQL Server enterprise edition, setandart edition atau workgroup edition. Namun jika ingin
memanfaatkan compression log-shipping harus menggunakan enterprise.

Implementasi
Pada log-shipping primary server bisa di set full recovery atau bulk-logged (jika mirroring harus full reecovery). Kelemahan log shipping adalah tidak ada fasilitas automatic failover
maka proses swich ke scondary server harus di lakukan manual. berikut langkahnya:
1. Backup full-backup pada server primary.
2. Restore hasil backup pada server scondary.
3. Create sebuah job pada primary server database untuk mem-backup transaction log database.
4. Create sebuah job pada scondary server untuk mengcopy hasil backup-an transaction log.
5. Create sebuah job pada scondary server untuk merestore transaction log.
6. Create sebuah alert pada monitor server untuk mengindikasikan kegagalan.

Kita bisa menggunakan network load balancing (primary dan scondary) agar kedua kedua server terlihat menggunakan IP yang sama.

Manfaat Menggunakan Log Shipping:
- Tidak menggunakan hardware dan konfigurasi windows kusus
- Tidak terkendala masalah jarak lokasi
- Menduplikasi data untuk keperluan disaster recovery (recovery data sebab bencana)
- Mempunyai capabilitas reporting meski terbatas

Kekurangan Menggunakan Log Shipping:
- Membutuhkan space data yang lebih banyak untuk menyimpan duplikat database
- Masing-masing database harus diconfigure terpisah
- Tidak mempunyai automatic failover (otomatis switch ke server scondary jika ada kegagalan pada primary)
- Memungkinkan sedikit terjadinya data lose manakala ada failover

Read More

SQL Server 1.f - Mirorring SQL Server - High Safety vs High Performance Mirroring SQL Server

Mode High Safety Pada Miroring

Anda dapat menggunakan Mode High Safety dalam database mirroring untuk memberikan salinan/duplikat dari database utama pada server mirror secara sinkron sehingga tidak ada kesempatan untuk kehilangan data antara principle dan mirror. Mode High Safety tersedia pada SQL Server Enterprise dan Standart Edition.  Dengan syarat baik pada Principle maupun Miror harus menggunakan versi SQL Server yang sama.

Dalam rangka untuk memberikan tingkat ketersediaan tertinggi, Anda dapat menggunakan server witness untuk memverifikasi konektivitas antara Principle maupun Miror. Server witness bukan persyaratan untuk mode tinggi keselamatan, tetapi merupakan persyaratan untuk kemampuan failover otomatis. Server witness menjalankan sebuah instance dari SQL Server yang mengkonsumsi sumber daya yang sangat sedikit dan bahkan dapat dijalankan menggunakan SQL Server Workgroup dan Express Editions. Menggunakan witness memberikan cek komunikasi antara principle dan mirror, mirip dengan heartbeat pada failover clustering.

Pengecekan komunikasi ini menyediakan kemampuan mirror untuk mengasumsikan peran dari Principle ketika Principle menjadi tidak tersedia. witness hanya memberikan verifikasi ke server mirror bahwa server principle sedang down. Jika server witness crash, database mirroring masih beroperasi dan benar-benar berfungsi antara principle dan mirror, dan Anda hanya akan kehilangan kemampuan untuk secara automatic failover.


 Mode High Performance Pada Miroring

Anda dapat menggunakan mode kinerja tinggi(High Performance) dalam database mirroring untuk melakukan operasi asynchronous antara database principle dan mirror. Modus Kinerja tinggi(High Performance) hanya mendukung failover manual dengan kemungkinan kehilangan data. Tidak perlu menggunakan server witness dalam mode kinerja tinggi (High Performance) karena tidak ada kemampuan failover otomatis.

Karena database principle(utama) tidak harus menunggu pemberitahuan dari server mirror untuk menjaga permintaan pengolahan,  modus kinerja tinggi dapat meningkatkan kinerja aplikasi jika Anda memiliki koneksi jaringan yang lambat atau masalah latency antara server principle dan mirror.
Pengolahan asynchronous juga berarti bahwa server mirror dapat beberapa menit lebih lambat saat memproses transaksi yang ber-volume tinggi , yang mungkin atau tidak mungkin diterima,  tergantung pada persyaratan yang telah disepakati dalam SLA. Modus Kinerja tinggi hanya didukung jika Anda menggunakan Edisi Enterprise dari SQL Server.

Read More

SQL Server 1.e - Mirorring SQL Server - Implemetasi Mirroring SQL Server

Implementasi

Database mirroring memiliki proses implementasi lebih mudah bila dibandingkan dengan failover
clustering. Hal ini tidak memerlukan konfigurasi hardware khusus dan dapat diterapkan dan dikelola
sepenuhnya melalui SQL Server. Berikut adalah langkah-langkah dasar Anda harus melakukan untuk mengatur
Database mirroring:
1. Buat endpoint untuk komunikasi basis data.
2. Backup database pada server principal.
3. Restore database pada server mirror.
4. Atur server utama sebagai partner pada server mirror.
5. Atur server mirror sebagai partner pada server utama.
Salah satu kelemahan database mirroring dibandingkan dengan failover clustering adalah bahwa Anda harus mengatur mirroring database untuk setiap database, sedangkan pada failover clustering,
seluruh instance diprotect. Karena mirroring dikonfigurasi untuk masing-masing database(principal dan mirror),
Anda harus memastikan bahwa data eksternal yang dibutuhkan oleh database mirror juga tersalin ke
server mirror. Misalnya, Anda perlu menyalin login dari database master pada server principal ke database master pada server mirror,
dan juga memastikan bahwa setiap pekerjaan yang dibutuhkan oleh database mirror
berada di server mirror. Juga, karena database mirroring membuat salinan database, Anda akan
perlu menggunakan dua kali lebih banyak ruang disk dari yang Anda lakukan dengan failover clustering.
Keunggulan Mirroring memiliki salinan duplikat dari database membuat mirroring menjadi solusi yang jauh lebih baik daripada failover clustering ketika Anda khawatir tentang pemulihan bencana dan kegagalan disk. Mirorring dalam SQL Server 2008 termasuk fitur baru. Mirroring yang akan memperbaiki page data yang corupt dengan menyalin page-page tersebut dari partner jika setiap corupt telah terdeteksi.

Snapshots Untuk Reporting
Untuk menggunakan database mirroring sebagai solusi report, Anda juga harus menggunakan fitur database snapshot, yang mengharuskan SQL Server 2008 versi Enterprise. Anda dapat menggunakan
snapshot database dalam hubungannya dengan mirroring database untuk memberikan laporan statis
solusi dengan mengambil snapshot reguler dari database mirror. User tidak dapat terhubung
secara langsung ke database mirror untuk melakukan query, tapi dapat membuat snapshot dari mirror
Database pada waktu tertentu, yang akan memungkinkan pengguna untuk terhubung ke database snapshot.

Dalam rangka untuk menjaga arus data dan ukuran snapshot, Anda harus me-refresh snapshot secara berkala dengan menciptakan snapshot baru dan mengarahkan lalu lintas data di sana.
Kemudian Anda dapat menghapus snapshot lama stelah open transaction selesai semua.
Snapshot database akan terus berfungsi setelah failover terjadi; Anda hanya akan kehilangan konektivitas sementara selama failover database di-restart. Anda mungkin perlu untuk men-drop snapshot dan menangguhkan pelaporan sampai server lain dibawa online.

Redirect dalam Event sebuah Failover
Transparent client redirect adalah fitur yang disediakan dalam Microsoft Data Access Component(MDAC) yang bekerja dengan database mirroring  untuk memungkinkan aplikasi client untuk secara otomatis meridirect dalam kasus failover. Ketika melakukan koneksi ke database yang berpartisipasi dalam database mirroring,  MDAC akan mengenali ada database mirror dan menyimpan informasi koneksi yang diperlukan untuk menyambung ke database mirror, bersama dengan database utama.

Jika koneksi ke database utama gagal, aplikasi akan mencoba untuk menyambung kembali.
Jika aplikasi tidak dapat menyambung kembali ke database utama, koneksi ke database mirror dicoba.  Ada satu peringatan utama ketika bekerja dengan klien redirect transparan:
Aplikasi ini harus terhubung ke database utama sebelum failover telah terjadi untuk menerima informasi koneksi tentang mirror.  Jika aplikasi tidak dapat terhubung ke server utama, itu tidak akan pernah diarahkan ke mirror.

Read More