Title: Databases

Q: ANSI SPARC architecture levels
A: conceptual, logical, physical

Q: view level
A: application programs hide details of data types

Q: logical level
A: describes data and relations

Q: physical level
A: how data is stored

Q: primary key
A: uniquely identifies row in table

Q: ACID properties
A: atomicity, consistency, isolation, durability

Q: atomicity
A: transaction executes fully or not at all

Q: consistency
A: database remains in consistent state, all integrity constraints hold

Q: isolation
A: multiple users can modify at the same time, won't see each other's partial actions

Q: durability
A: when transaction fully committed, modified data is persistent regardless of disk crashes

Q: key constraint
A: each key value can only appear once

Q: functional dependency
A: if two rows agree on a value in one column, they must agree on the other column

Q: determinant: if [...] holds & [...] & it is [...]
A: functional dependency; lhs is minimal; non-trivial

Q: anomaly types
A: insert, update, deletion

update anomaly: when one value is changed, others need to be updated, taking longer and maybe getting out of sync

Q: [...] anomaly: when [...] are stored together in [...]
A: insert; unrelated concepts; a single table

deletion anomaly: e.g. when last course of instructor is deleted, their phone number is lost

Q: relation is in [...] if for [...] functional dependency, the [...]
A: BCNF; every non-trivial; lhs contains a key

relation is in 3NF if it's in BCNF, the lhs contains a key, or the rhs is an attribute of a minimal key

multivalued dependencies: constraints that give a necessary and sufficient condition for lossless decomposition, lead to 4NF

Q: serial schedule
A: actions of different transactions are executed one after another

Q: serializable schedule
A: has same effect on database as some serial schedule

actions in schedule conflict if they are from different transactions, use the same data item, and there's a write

Q: we can [...] if they are [...]
A: swap actions of different transactions; non-conflicting

Q: conflict-serializable
A: if conflict equivalent to some serial schedule

Q: conflict equivalent schedules
A: if they can be transformed into each other by swapping non-conflicting, adjacent transactions

Q: check [...] with [...]
A: conflict-serializability; a precedence graph

cascadeless schedule: delay reads, only read value produced by already committed transactions

recoverable schedule: delay commit until after required previous transactions have committed. includes cascadeless schedules

Q: strict 2PL
A: transaction releases all locks only when completed

Q: preclaiming 2PL
A: all needed locks declared at start of transaction

optimistic concurrency control: hope for best, maintain read/write sets per transaction, validate when committing

Q: impedance mismatch
A: problems caused by differences between database model and programming language model