26 lines
1.1 KiB
Markdown
26 lines
1.1 KiB
Markdown
# lec1
|
|
|
|
## A few reasons to have them \
|
|
And what they *require* \
|
|
Database systems generally need support for:
|
|
1. querying - \
|
|
* Finding things \
|
|
* Just as well structured data makes querying easier
|
|
|
|
2. access control - \
|
|
* who can access which data segments and what they can do with that data \
|
|
* reading, writing, sending, etc
|
|
|
|
3. corruption prevention - \
|
|
* mirroring/raid/parity checking/checksums/etc as some examples
|
|
|
|
## Modeling Data \
|
|
Just like other data problems we can choose what model we use to deal with data.
|
|
|
|
__Schema__ is the deisgn or structure of a specific database. While the __instance__ is the occurance of that schema with some data inside the fields. _The data inside those fields at this point don't really matter. \
|
|
|
|
__Queries__ are typically known to be declarative; typically we don't care about what goes on behind the scenes in practice since by this point we are assuming we have tools we trust and know to be somewhat efficient. \
|
|
|
|
__Transactions__ are a set of operations. Transactions are not alllowed to fail. If _anything_ fails then everything should be undone and the state should revert to previous state.
|
|
|