Auto saved by Logseq
This commit is contained in:
Ryan
parent
a3f42768dc
commit
13a3c6298f
|
|
@ -1010,6 +1010,7 @@
|
|||
CLOCK: [2023-06-14 Wed 16:41:52]--[2023-06-14 Wed 16:49:14] => 00:07:22
|
||||
:END:
|
||||
- DONE Deadlock and how it can be resolved. #flashcard
|
||||
id:: 64841da4-d8ce-46f5-bbe6-4dee620cde75
|
||||
- A deadlock is a situation in which two or more transactions are unable
|
||||
to proceed because each is waiting for a resource held by the other,
|
||||
resulting in a circular dependency and a system halt. It is a form of
|
||||
|
|
@ -1017,29 +1018,39 @@
|
|||
database management systems.
|
||||
- Example:
|
||||
- Cascading rollback #flashcard
|
||||
id:: 64897f0b-dda6-4cc3-a9c3-cf630bcb0658
|
||||
- Cascading Rollback: a transaction (T1) causes a
|
||||
failure and a rollback must be performed. Other
|
||||
transactions dependent on T1's actions must also
|
||||
be rollbacked, thus causing a cascading effect.
|
||||
- One transaction's failure causes many to fail.
|
||||
- DONE ACID (Atomicity, Consistency, Isolation, Durability): A set of properties that guarantee the reliability and integrity of database transactions. #flashcard
|
||||
id:: 64841da4-0055-4d34-9f61-1402ff068ec7
|
||||
collapsed:: true
|
||||
- Atomicity: :-> The property that ensures a transaction is treated as a single, indivisible unit of work. It either executes all its operations successfully or rolls back to the initial state if any operation fails.
|
||||
id:: 64841d38-4ea9-4b76-8585-8b9de23915da
|
||||
- Consistency: :-> The property that ensures a transaction transforms the database from one consistent state to another consistent state. It maintains data integrity and adheres to defined business rules.
|
||||
id:: 64841d38-2854-4dfb-8f21-0013fca66a0a
|
||||
- Isolation: :-> The property that ensures concurrent transactions do not interfere with each other. Each transaction operates in isolation until it completes, preventing interference or conflicts.
|
||||
id:: 64841d38-fd2b-435e-bd45-3bf487a74b6f
|
||||
- Durability: :-> The property that ensures committed changes made by a transaction are permanently saved and will survive any subsequent system failures or crashes.
|
||||
id:: 64841d38-950c-431e-8f28-ece98e230554
|
||||
- DONE Concurrency control
|
||||
- DONE Meaning of serialisability. #flashcard
|
||||
id:: 648428e1-5136-4d15-97c0-12087085b47f
|
||||
- The objective of serialisability is to find nonserial schedules that are equivalent to some serial schedule. Such a schedule is called serialisable.
|
||||
- DONE How locking can ensure serialisability. #flashcard
|
||||
id:: 64841da4-8812-405f-b49a-69eec9a069d2
|
||||
- Locking achieves serializability by using locks to control access to
|
||||
shared resources (e.g., database objects like tables or rows) and
|
||||
prevent conflicts between concurrent transactions.
|
||||
- DONE 2PL #flashcard
|
||||
id:: 64841da4-eab4-40db-819f-249fe1437250
|
||||
- In the 2PL protocol, transactions acquire and release locks on database
|
||||
objects (e.g., tables, rows) in two distinct phases: the growing phase
|
||||
and the shrinking phase.
|
||||
- DONE How timestamping can ensure serialisability. #flashcard
|
||||
id:: 64842000-07a7-4439-8ce6-7789e0a3358d
|
||||
- By using transaction timestamps and enforcing the read and write
|
||||
validation checks, concurrency control mechanisms can ensure that
|
||||
transactions are executed in a way that maintains data consistency and
|
||||
|
|
@ -1054,6 +1065,7 @@
|
|||
- User mistakes.
|
||||
- Sabotage.
|
||||
- DONE Purpose of transaction log file. #flashcard
|
||||
id:: 64841f8f-5a9e-4f22-8f51-47931937998a
|
||||
- Contains information about all updates to
|
||||
database:
|
||||
- Transaction records.
|
||||
|
|
@ -1061,12 +1073,14 @@
|
|||
- Often used for other purposes (for example, auditing).
|
||||
- For autiding
|
||||
- DONE Purpose of checkpointing. #flashcard
|
||||
id:: 64841f91-1d24-49f6-9f83-7c8b565c647f
|
||||
- When failure occurs, redo all transactions that
|
||||
committed since the checkpoint and undo all
|
||||
transactions active at time of crash.
|
||||
- DONE Normalization
|
||||
background-color:: yellow
|
||||
- DONE Functional dependencies [g4g](https://www.geeksforgeeks.org/types-of-functional-dependencies-in-dbms/) #flashcard
|
||||
id:: 648428e1-e704-4e23-941d-af9833de6f93
|
||||
- In a relational database management, functional dependency is a concept
|
||||
that specifies the relationship between two sets of attributes where one
|
||||
attribute determines the value of another attribute. It is denoted as **X → Y**, where the attribute set on the left side of the arrow, **X** is called **Determinant** , and **Y** is called the **Dependent**.
|
||||
|
|
@ -1076,32 +1090,42 @@
|
|||
:END:
|
||||
- DONE kinds of NF [tutorial](https://www.geeksforgeeks.org/normal-forms-in-dbms/)
|
||||
- First Normal Form (1NF): :-> This is the most basic level of
|
||||
id:: 648974ba-7334-4e73-a0ae-6b8fc6ec99ab
|
||||
normalization. In 1NF, each table cell should contain _only a single value, and each column should have a unique name_. The first normal form helps to eliminate duplicate data and simplify queries.
|
||||
- Second Normal Form (2NF): :-> 2NF eliminates redundant data by requiring that each _non-key attribute_ be dependent on the primary key. This means that _each column should be directly related to the primary key_, and not to other
|
||||
id:: 648974ba-cc9e-4cdf-a312-3af1bcab23f2
|
||||
columns.
|
||||
- Third Normal Form (3NF): :-> 3NF builds on 2NF by requiring
|
||||
id:: 648974ba-f325-450e-aede-9a7d92bcf888
|
||||
that _all non-key attributes are independent of each other._ This means that each column should be directly related to the primary key, and not to any other columns in the same table.
|
||||
- Boyce-Codd Normal Form (BCNF): :-> BCNF is a stricter form of 3NF that ensures that each determinant in a table is a candidate key. In other words, BCNF ensures that _each non-key attribute is dependent only on the candidate key._
|
||||
id:: 64842000-c15a-4b8f-95c3-d6c6e49e4af0
|
||||
- Fourth Normal Form (4NF): 4NF is a further refinement of BCNF that ensures that _a table does not contain any multi-valued dependencies._
|
||||
- Fifth Normal Form (5NF): 5NF is the highest level of normalization and involves decomposing a table into smaller tables to _remove data redundancy and improve data integrity._
|
||||
- LATER Block 4
|
||||
- DONE Distributed DBMS
|
||||
- DONE client server arch #flashcard
|
||||
id:: 648974ba-9c11-4816-9d5e-0623dc4d4d45
|
||||
- Computers (client) connected over wired or wireless local area network (LAN)
|
||||
- The database itself and the DBMS are stored on a central device called the database server, which is also connected to the network.
|
||||
- Distributed Database #flashcard
|
||||
id:: 648974ba-b13a-4f3f-8409-ea02b5ef5894
|
||||
- A logically interrelated collection of shared data (and a description of this data), physically spread over a computer network.
|
||||
- Distributed DBMS #flashcard
|
||||
id:: 648974ba-997c-4f43-b2d6-d972cfc23d36
|
||||
- Software system that permits the management of the distributed database and makes the distribution transparent to users.
|
||||
- the key issues #flashcard
|
||||
id:: 648974ba-4c63-4215-b420-d537c2a93675
|
||||
- Fragmentation
|
||||
- Allocation
|
||||
- Replication
|
||||
- importance and different types of fragmentation #flashcard
|
||||
id:: 648974ba-07aa-4c51-aa70-1c8dfb4570e7
|
||||
- Horizontal
|
||||
- Vertical
|
||||
- Mixed
|
||||
- different types of transparency #flashcard
|
||||
id:: 648974ba-6db5-4d3a-af62-1695e7c3a9b7
|
||||
- Distribution Transparency: The database feels as a single, logical entity
|
||||
- Transaction Transparency: Ensures that all distributed transactions maintain distributed database’s integrity and consistency.
|
||||
- Performance Transparency: must perform as if it were a centralized DBMS.
|
||||
|
|
|
|||
Loading…
Reference in a new issue