review conference sbd

SBD: sistem untuk menyimpan record yg terkomputerisasi

tujuan utama SBD buat store, update, & retreive data

komponen dari SBD:
1. data (integrated & shared)
2. HW
3. SW (incl. DBMS)
4. users

database : koleksi data persisten
persisten itu artinya disimpan, dan bisa dihapus dgn aksi tertentu. kalau sudah dientry ke database, entry itu harus dihapus secara eksplisit (eksplisit = harus request ke dbms nya, secara eksplisit = hrs pake query buat melakukan operasi2 nya)
maksudnya kalau mau dihapus, harus ada request yang eksplisit

enterprise itu biasanya mengelola dua basisdata
operational data itu ky data karyawan, dst yg mendukung operational organisasi
decision support itu, data yg mendukung pengambilan keputusan misalnya, data ttg customer, data ttg pasar, dst

knapa pake SBD?
klo utk single user : compactness, speed, less drudgery, currency, dan supaya user bisa update data on demand
selain single user (klo yg ngakses banyak, kalo yg bisa ngakses databasenya banyak, kan brarti kemungkinan terjadinya hal2 yg tidak diinginkan lebih besar):
1. share data
2. reduce redundancy
3. avoid inconsistency,
4. provide transaction support
5. maintain integrity
6. enforce security
7. balance conflicting requirement
8. enforce standards

fungsi dbms:
1. utk mendefinisikan data, terutama skema2nya
2. manipulasi data : retreive, update, delete, add
3. optimisasi dan eksekusi
4. keamanan & integritas data
5. recovery & concurrency data
6. data dictionary dan metadata
7. performansi

optimasi query itu termasuk quoery processing, step k2

transaction management
transaksi :kumpulan operasi yang merepresentasikan sebuah fungsi lojik pada aplikasi database
transaksi harus dikelola karena kita harus menjaga konsistensi dari database

Query Processing
(yg dibahas: cara ngukur cost [cost itu adalah waktu yg dibutuhkan buat ngejawab query], algoritma2 buat ngevaluasi operasi aljabar relasional)

basic step ada 3:
parsing+translation, optimization, dan evaluation

logika nya si… yaa…. begitu query masuk, diparser sama komputer (dibacanya jd dalam bentuk aljabar relasional. teruuss,, memasuki ke execution plan,, itu tuh harus dioptimisasi dulu, baru setelah itu melalui tahap ‘evaluation engine’,, baru keluar deh output dr query yg direkuest. *ini bisa ngeliat gambar (yg di slide itu loh).

faktor buat nentuin cost : disk access (yg paling dominan), kinerja CPU, akses IO juga termasuk salah satu faktor2 yg buat nentuin cost

karena dengan kecepatan prosesor juga tinggi, tapi ga sebanding dengan perkembangan disk akses
cost = jumlah transfer blok dari disk,
disk access: yg diitung read block & write block
oiya 1 hal yg penting dr disk access = “cost buat nge-write selalu > cost buat nge-read blok, karena dalam ngewrite kita melakukan read lagi u/ memastikan write sudah sukses”

A1
br = jumlah blok yang dibaca
COST:
– seleksi yang atributnya bukan merupakan key..
cost= br, karena dia harus menelusuri semua tuple dan menseleksinya
– kalau ternyata seleksi itu atributnya berupa key..
cost = br/2, merupakan avg cost maks br, sedangkan min 1
KELEBIHAN:bisa dipakai di segala kondisi, tidak memedulikan ordering ataupun index,

A2 (binary search)
mulai nyarinya dari tengah, liat index yang dicari lebih gede atau lebih kecil, terus buka yang ditengah di bawah atau di atas
syaratnya atribut sudah terurut
kompleksitasnya log2(br)

A3
intinya A3 tu perbadingannya di key atribut (equality on key, dan ada index nya)
costnya tinggi pohon + 1
knapa tambah 1: karena ditambah record yg mau diambil, jadi kn itu indexnya primary index (udah berurutan). trus cost yg dbutuhin kalo misal kita pake struktur b+ tree jadinya height si tree nya + record yg diambil.

b+ tree
mirip binary tree cuma leaf nya ga cm 2, tepatnya sebuah pohon index yang jumlah anaknya selalu sama

A4
masih primary index, tapi equality nya ga di key
jadi ntar cost nya kudu dtambah si block yang masi punya record yang dicari, ga cuma + 1 doank, tergantung blok yg keambil.
klo misal record yg isinya search key ada 5 ya + 5.

yg jelas kl misal kita punya kondisi yg disebutin buat algo2 tadi trus pake lin search jadi lama kan, udah punya index kq masi nyari per blok

A5
indexnya secondary aka ga terurut dan seleksinya masih equality (yg non eq ntar di A6 dst)
index secondary: ga terurut di fisiknya, misal index nya 1 2 3 tapi bisa aja disimpennya 1 3 2, biar ga perlu nyari sampe akhir di indexnya.

A3 A4 itu seleksi kalo indexnya primary, kalo A5 itu seleksi kalo indexnya secondary
(primer sama sekunder, bedanya primer itu urutannya sesuai di physical)

cost buat A5
kalo atribut seleksinya itu unik, maka cost nya HT[i]+1
kalo atribut seleksinya g unik, cost nya HT[i]+jmlh blok

contoh kasus
hobby mahasiswa,kalo secondary yang dibandingkan gak urut, tapi ada atribut yangurut
tepatnya jumlah blok yg mengandung record yg memenuhi syarat
misalnya diurutkan berdasarka hobby, maka hobby yang sama kan urut
ambil berapa jumlah blok yang ada hbby itu + ht

primer : urutan index sesuai dengan urutan di disk; menggunakan primary index : query yang digunakan tercantum dalam primary index

kalo mo pake A3 A4 A5, brarti harus ada index

—-
a nama atributnya
v itu variable nilainya
jadi kalo A>V pada a6, mulai dicari indeks yang lebih besar dari V pertama kali

A6
Operasi perbandingan dengan primary index. Untuk kasus A>V, telusuri index untuk mencari nilai yang lebih besar daripada V, kemudian fetch table fisik, diikuti dengan fetch block selanjutnya yang memenuhi. Untuk kasus A<V, tanpa menelusuri index, langsung fetch blok pertama dan blok-blok selanjutnya sampai didapat nilai yang lebih besar dari V.

A7
Operasi perbandingan dengan secondary index. Untuk kasus A>V, telusuri index untuk mencari nilai yang lebih besar dari V, kemudian fetch blok pada table fisik. Karena index di table fisik tidak terurut, untuk mencari record selanjutnya, kita harus menelusuri index selanjutnya dan menelusuri pointer yang menunjuk ke record di table fisik lalu blok nya di fetch ke memori, begitu selanjutnya. Untuk kasus A<V, sama dengan A>V tetapi dimul

jadi ya ambil dari indeks pertama, sampai ketemu A<V pertama kali
a6 sama a7 mirip, bedanya ya a6 based on primary index, yg a7 dari scondary index

we can use a secondary ordered index to guide retrieval for comparison conditions
involving <, <=, >= ato >

secondary index ini kan pointer ke records, a7 bisa jadi jelek banget daripada lin search, kalo nunjuk ke records yang banyak
jadi a7 terbatas pada misalkan si recordsnya yang dituju dikit


A8: selection conjunctive dengan single index ambil salah satu kondisi, kemudian pilih algoritma dari A1 – A7 yang cost nya paling sedikit. Lalu algoritma yang sudah dipilih, diterapkan ke kondisi yang lain.

A9: selection conjunctive dengan multiple index Index yang kita miliki merupakan index yang komposit,

A10: selection conjunctive dengan mencari intersection dari tiap-tiap kondisi. Tiap-tiap kondisi yang ada indexnya, di proses satu persatu kamudian hasilnya di simpan di memori buffer, kemudian hal yang sama dilakukan terhadap kondisi sisa. Lalu dilakukan intersection dari semua hasil yang ada di memori buffer

contoh composit index: dari NIM khan kita bisa tau jurusan, taun masuk, no mahasiswa
indexnya cuma NIM aja

kalo yg disjungsi itu, seleksi dulu masing2 kondisinya….trus, kan udh dapet tuh index2 yg memenuhi syarat…nah, index2 yg tadi itu, dicari unionnya

kalo udh dapet union daru record2nya, baru fetch dari fisiknya


external sort-merge
sort:
ambil sejumlah M blok terus disorting di memory
hasil sortingnya disimpan disimpan di sebuah file R
untuk setiap Mi yang diambil disimpan di Ri
merge:
untuk setiap R yang ada baca satu blok
untuk semua blok yang diambil, ambil tupple yang paling kecil terus outputin
terus hapus tupple itu dari buffer
kalo ada blok dari sebuah R yang habis maka baca satu blok lagi dari R tersebut selama belum EOF
gitu aja sampai semua sampai buffer habis


nested loop join
misalnya r><s, untuk setiap tuple pada relasi r, makan cocokkan dengan tuple pada s…
jika cocok, tuple tersebut di-join
maka costnya = (Nr*Bs)+Br
Nr: jml tuple relasi r
Br: jml block relasi r

block nested loop join
untuk r><s,
ambil dulu block pertama dari relasi r
trus, ambil block pertama dari relasi s
trus, dicocokin deh masing2 tuplenya
costnya= (Br*Bs)+Br

indexed nested-loop join
prasyaratnya si indexed nested bisa jalan kalo inner relasionnya berindex
indexed nested loop join = nested loop join biasa, cuman yg dalem pake index
algo hasil akhirnya = br + nr * c
c : rata2 dari block read, write, seek
kalo ke2nya punya index, yang outer harus lebih dikit,..

c itu uda termasuk seleksi s yg pake index
jadi initnya c nya dikecilin dengan cara s nya dikecilin.

—–

yang merge join ampe hash join kurang nangkep, jd ga di tulis, drpada salah review..

——

Transaksi (bab 15)

ACID itu adalah properti2 yg harus dijaga oleh sistem basis data, untuk ensure integrity of the data
Atomicity : terjadi ato tidak terjadi
consistency : itu contohnya yg transfer uang 50 dari akun A ke Akun B, maksudnya konsisten ya setelah transaksi terjadi maka akun A berkurang 50, akun B bertambah 50
isolation : itu artinya kl terjadi konkurensi, ga akan ada 2 ato lebih transaksi yang masuk ke critical region bersamaan
Durability : data yang terupdate tidak hilang asalkan transaksinya commited, jadi PASTI ketulis ke hard disk

transcation state
active itu initial statenya. slama state ini, sistem melakukan eksekusi.
kalo udh selesai eksekusi, pindah ke state partially committed.
kalo ternyata prosesnya udh slese, statusnya jadi commit.
klo blm slese, dan ternyata eksekusi tidak bisa dilanjutkan, maka statenya jadi failed.
klo udh failed, jadi aborted deh. pada state aborted ini smua kondisi dibalikin ke kondisi awal sebelum transaksi, terutama databasenya.

shadow database sheme
salah satu cara untuk mengimplementasi atomicity sama durability adalah dengan shadow database
jadi, database yang ada skrg dicopy dulu. jadi kita punya dua database. anggep aja D, trus kopiannya D’. trus, transaksi nya dilakukan terhadap database D’. kalo transaksinya berhasil, pointer yg tadinya nunjuk si D, dipindah ke D’. trus, database yg D diapus deh. pada shadow database ini asumsinya pas ngopi dari D ke D’ g ada kegagalan.

concurrent executions
jadi, ada multiple transactions yang dieksekusi. keuntungannya, increased processor and disk utilization, dan reduce average response time.
untuk menjalankan concurrent executions ini, brarti kita butuh schedules. contoh2 schedule nya ada banyak di buku/slide.
tapi, walaupun beberapa transaksi dieksekusi bersamaan, konsistensi database harus ttp dijaga.

(~’.’)~ hyuuuuuuunngg ~(‘.’~)

serializability
intinya nyari alternatif schedule yang hasilnya sama kaya yg serial. dan jangan lupa harus menjaga konsistensi basis data.
ada dua bentuk schedule yg eqiv: conflict dan view.
klo conflict itu, dy ngeswap proses read dan write sampe g conflict lg, contohnya ada di buku.
brarti read sama write pasti kluar bergantian dalam satu sekuens, dalam satu transaksi.
klo yg view, ada beberapa kondisi yg harus dipenuhi sebelum jadwal itu bisa dibilang view serializability.
view serializability pasti conflict serializability. namun, kalo conflict, blom tentu view. karena view serializable less strict (view : peduli amat conflict ato ngga, asalkan hasilnya sama dengan hasil serial)
klo yang conflict khan selama gak conflict lu boleh swap2, karena hasilnya sama dengan serial.
klo yang view : ADA kemungkinan dia terjadi conflict (write terjadi 2x dengan transaksi beda), tapi hasil yang didapat masih sama dengan serial.
kondisi ada 3, baca halaman 581.

(_ _) o 0

sleting salut

pada umumnya, setiap manusia di dunia memiliki kekurangan. termasuk aku. salah satu kekuranganku adalah kekurangan stok celana panjang untuk kuliah. kurangnya stok celana ini membuatku memberlakukan sistem cuci-kering-pakai yg sudah mahsyur dikalangan mahasiswa kosan.

setelah beberapa bulan berjalan dengan adem ayem, akhirnya sistem ini menemui ancaman, tepatnya pada saat salah satu resleting (bener ga tulisannya?) celanaku rusak. normalnya, sebuah sleting akan tertutup jika ditarik ke arah yang berlawanan dari arah tarikan untuk membukanya. namun sleting tersebut tidak bisa ditutup meskipun sudah ditarik kesana kemari. karena stok celana yg lain sedang dicuci semua (eh, ada yg sedang dijemur), klo mau diservis ke tailor ntar telat kuliah, maka dari itu, aku pun menyiasatinya dgn memakai peniti.

setelah mencari-cari dan mengharap-harap ada orang yang pernah meninggalkan peniti di kosanku, alhasil aku menemukan frame name tag lengkap dgn penitinya. langsung saja kulepas peniti tersebut, dan memindahkannya ke celana. nah, pada saat memasang peniti inilah aku merasa semakin salut kepada perempuan berkerudung.

betapa tidak, dalam kasusku, klo ga ati2 nusukkin penitinya, bisa2 aku kena usus terburai karena penitinya salah colok.. baru sekali itu aja rasa cemasnya udah banget-banget, sedangkan para perempuan berkerudung, mereka mungkin ada yg sering (walau skrg ada model instant) berurusan dgn peniti ato jarum pentul. sugoi!

alhamdulillah setelah satu hari kuliah, aku pulang dengan sehat sentosa tanpa tergores sedikit pun.. fuuuhh..

-just write what you can’t remember, what you can’t tell-