csnotes/cst363/lec/lec2.md
2018-09-12 14:10:16 -07:00

69 lines
1.8 KiB
Markdown

# lec2
Covering `tables, tuples, data stuff`
## Problem Statement \
We need to be able to manipulate data easily
> IMS had been using trees for a while a long time ago
> Rows --> __atributes__
> Columns --> __tuple__
somtimes we refer to the title of the columns to be fields
> Table --> __relation__
relational instance as well for another term
> Domain
The set of values allowed in a field
## NULL
cant operate on it at all
> Count
The only thing that lets you operate on NULL. Even then you only get 0 back.
## Keys Types
> Super Key
> Candidate Key
> Primary Key
## Problem Statement
The rows are not distinguishable from each other; we still have a mes of data sitting there unlabeled. Some kind of identifier is necessary to be able to access every tuple in the relational set.
### SuperKey
Set of attr is a superkey for a table as long as that combination of fields remains unique for every tuple in the relational set.
In other words if we have multiple fields; f1 f3 f5 might be a good combo to use as a key into the table.
> What's a valid superkey?
For starters anything that contains another valid superkey
Any subset of a full tuple that can uniquely identify any row in the table.
> Can a whole row be a superkey?
...full on brainlet.........yes
### Candidate Key
Any super key that wouldn't be a superkey if one of the attr were removed. Say then that we have a super key that takes columns {1,3,5,6,7}, but removing anyone of the rows no longer reliably returns an arbitrary _unique_ row.
### Primary key
Any candidate key the database designer has chosen to serve as the unique
### Foreign Key
Set of attrs in one table that are the primary key attrs of another table. More info about this key type will come later but just know for now that it exists in the wild.