mirror of
https://github.com/kristoferssolo/Databases-II-Cheatsheet.git
synced 2025-10-21 18:20:35 +00:00
209 lines
7.0 KiB
Plaintext
209 lines
7.0 KiB
Plaintext
#set page(margin: (
|
||
top: 1cm,
|
||
bottom: 1cm,
|
||
right: 1cm,
|
||
left: 1cm,
|
||
))
|
||
|
||
#set text(7pt)
|
||
#show heading: it => {
|
||
if it.level == 1 {
|
||
// pagebreak(weak: true)
|
||
text(10pt, upper(it))
|
||
} else if it.level == 2 {
|
||
text(9pt, smallcaps(it))
|
||
} else {
|
||
text(8pt, smallcaps(it))
|
||
}
|
||
}
|
||
|
||
|
||
= Indices
|
||
|
||
== Bitmap
|
||
|
||
== B+ tree
|
||
|
||
== Hash-index
|
||
|
||
= Algorithms
|
||
|
||
|
||
== Nested-loop join
|
||
|
||
=== Overview
|
||
|
||
=== Cost
|
||
|
||
== Block-nested join
|
||
|
||
=== Overview
|
||
|
||
=== Cost
|
||
|
||
== Merge join
|
||
|
||
=== Overview
|
||
|
||
=== Cost
|
||
|
||
== Hash-join
|
||
|
||
=== Overview
|
||
|
||
=== Cost
|
||
|
||
|
||
= Relational-algebra
|
||
|
||
== Equivalence rules
|
||
|
||
- Commutativity of Union: $R∪S=S∪R$
|
||
- Commutativity of Intersection: $R∩S=S∩R$
|
||
- Commutativity of Join: $R join S=S join R$
|
||
- Associativity of Union: $(R∪S)∪T=R∪(S∪T)$
|
||
- Associativity of Intersection: $(R∩S)∩T=R∩(S∩T)$
|
||
- Associativity of Join: $(R join S) join T=R join (S join T)$
|
||
- Theta joins are associative in the following manner: $(E_1 join_theta_1
|
||
E_2) join_(theta_2 and theta_3) E_3 ≡E_1 join_(theta_1 or theta_3) (E_2
|
||
join_theta_2 E_3)$
|
||
- Distributivity of Union over IntersectionL $R∪(S∩T)=(R∪S)∩(R∪T)$
|
||
- Distributivity of Intersection over Union: $R∩(S∪T)=(R∩S)∪(R∩T)$
|
||
- Distributivity of Join over Union: $R join (S∪T)=(R join S)∪(R join T)$
|
||
- Selection is Commutative: $ sigma p_1( sigma p_2(R))= sigma p_2( sigma
|
||
p_1(R))$
|
||
- Selection Distributes Over Union: $ sigma p(R∪S)= sigma p(R)∪ sigma p(S)$
|
||
- Projection Distributes Over Union: $pi c(R∪S)=pi c(R)∪pi c(S)$
|
||
- Selection and Join Commutativity: $ sigma p(R join S)= sigma p(R) join S$ if
|
||
p involves only attributes of R
|
||
- Pushing Selections Through Joins: $ sigma p(R join S)=( sigma p(R)) join S$
|
||
when p only involves attributes of R
|
||
- Pushing Projections Through Joins: $pi c(R join S)=pi c(pi_(c sect #[attr])
|
||
(R) join pi_(c sect #[attr]) (S))$
|
||
|
||
== Operations
|
||
|
||
- Projection ($pi$). Syntax: $pi_{#[attributes]}(R)$. Purpose: Reduces the
|
||
relation to only contain specified attributes. Example: $pi_{#[Name,
|
||
Age}]}(#[Employees])$
|
||
|
||
- Selection ($sigma$). Syntax: $sigma_{#[condition]}(R)$. Purpose: Filters rows
|
||
that meet the condition. Example: $sigma_{#[Age] > 30}(#[Employees])$
|
||
|
||
- Union ($union$). Syntax: $R union S$. Purpose: Combines tuples from both
|
||
relations, removing duplicates. Requirement: Relations must be
|
||
union-compatible.
|
||
|
||
- Intersection ($sect$). Syntax: $R sect S$. Purpose: Retrieves tuples common
|
||
to both relations. Requirement: Relations must be union-compatible.
|
||
|
||
- Difference ($-$). Syntax: $R - S$. Purpose: Retrieves tuples in R that are
|
||
not in S. Requirement: Relations must be union-compatible.
|
||
|
||
- Cartesian Product ($times$). Syntax: $R times S$. Purpose: Combines tuples
|
||
from R with every tuple from S.
|
||
|
||
- Natural Join ($join$). Syntax: $R join S$. Purpose: Combines tuples from R
|
||
and S based on common attribute values.
|
||
|
||
- Theta Join ($join_theta$). Syntax: $R join_theta S$. Purpose: Combines tuples
|
||
from R and S where the theta condition holds.
|
||
|
||
- Outer Join. Full Outer Join: $R join.l.r S$. Left Outer Join: $R join.l S$.
|
||
Right Outer Join: $R join.r S$. Purpose: Extends join to include non-matching
|
||
tuples from one or both relations, filling with nulls.
|
||
|
||
|
||
= Concurrency
|
||
|
||
|
||
=== Conflict
|
||
|
||
We say that I and J conflict if they are operations by *different transactions* on the
|
||
*same data item*, and at least one of these instructions is a *write* operation.
|
||
For example: I = read(Q), J = read(Q) -- Not a conflict; I = read(Q), J =
|
||
write(Q) -- Conflict; I = write(Q), J = read(Q) -- Conflict; I = write(Q), J =
|
||
write(Q) -- Conflict.
|
||
|
||
// + I = read(Q), J = read(Q). The order of I and J *does not matter*, since the same
|
||
// value of Q is read by $T_i$ and $T _j$, regardless of the order.
|
||
//
|
||
// + I = read(Q), J = write(Q). If I comes before J, then Ti does not read the value
|
||
// of Q that is written by Tj in instruction J. If J comes before I, then Ti reads the
|
||
// value of Q that is written by Tj. Thus, the order of I and J *matters*.
|
||
//
|
||
// + I = write(Q), J = read(Q). The order of I and J *matters* for reasons similar to
|
||
// those of the previous case.
|
||
//
|
||
// + I = write(Q), J = write(Q). Since both instructions are write operations, the
|
||
// order of these instructions does not affect either Ti or Tj. However, the value
|
||
// obtained by the next read(Q) instruction of S is affected, since the result of only
|
||
// the latter of the two write instructions is preserved in the database. If there is no
|
||
// other write(Q) instruction after I and J in S, then the order of I and J *directly
|
||
// affects the final value* of Q in the database state that results from schedule S.
|
||
|
||
== Conflict-serializability
|
||
|
||
If a schedule $S$ can be transformed into a schedule $S'$ by a series of swaps
|
||
of non- conflicting instructions, we say that $S$ and $S'$ are *conflict
|
||
equivalent*. We can swap only _adjacent_ operations.
|
||
|
||
The concept of conflict equivalence leads to the concept of conflict
|
||
serializability. We say that a schedule $S$ is *conflict serializable* if it is
|
||
conflict equivalent to a serial schedule.
|
||
|
||
=== Serializability graph
|
||
|
||
Simple and efficient method for determining the conflict
|
||
seriazability of a schedule. Consider a schedule $S$. We construct a directed
|
||
graph, called a precedence graph, from $S$. The set of vertices
|
||
consists of all the transactions participating in the schedule. The set of
|
||
edges consists of all edges $T_i arrow T_j$ for which one of three conditions holds:
|
||
|
||
+ $T_i$ executes `write(Q)` before $T_j$ executes `read(Q)`.
|
||
+ $T_i$ executes `read(Q)` before $T_j$ executes `write(Q)`.
|
||
+ $T_i$ executes `write(Q)` before $T_j$ executes `write(Q)`.
|
||
|
||
If the precedence graph for $S$ has a cycle, then schedule $S$ is not conflict
|
||
serializable. If the graph contains no cycles, then the schedule $S$ is
|
||
conflict serializable.
|
||
|
||
== Standard isolation levels
|
||
|
||
- *Serializable* usually ensures serializable execution. However, as we shall explain
|
||
shortly, some database systems implement this isolation level in a manner that
|
||
may, in certain cases, allow nonserializable executions.
|
||
- *Repeatable* read allows only committed data to be read and further requires that,
|
||
between two reads of a data item by a transaction, no other transaction is allowed
|
||
to update it. However, the transaction may not be serializable with respect to other
|
||
transactions. For instance, when it is searching for data satisfying some conditions,
|
||
a transaction may find some of the data inserted by a committed transaction, but
|
||
may not find other data inserted by the same transaction.
|
||
- *Read committed* allows only committed data to be read, but does not require re-
|
||
peatable reads. For instance, between two reads of a data item by the transaction,
|
||
another transaction may have updated the data item and committed.
|
||
- *Read uncommitted* allows uncommitted data to be read. It is the lowest isolation
|
||
level allowed by SQL.
|
||
|
||
== Protocols
|
||
|
||
=== Lock-based
|
||
|
||
=== Timestamp-based
|
||
|
||
=== Validation-based
|
||
|
||
=== Version isolation
|
||
|
||
= Logs
|
||
|
||
== WAL principle
|
||
|
||
== Write ahead principle
|
||
|
||
== Recovery algorithm
|
||
|
||
== Log type examples
|
||
|
||
== Recovery example
|