shockrah/csnotes
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
986a020a8e
csnotes/cst363/lec/lec2.md
shockrahwow 1989680cb1 db: lec1-7 rdy for master
2018-10-03 13:13:17 -07:00

2.9 KiB
Raw Blame History

lec2

Covering tables, tuples, data stuff

Problem Statement

We need to be able to manipulate data easily

For sometime previous databses systems, like IMS, had been using tree structures for a while but, there was still a demand for a system that anyone could use. This issue is what brings us closer to the table structure that we have mentioned in previous lectures.

To actually guide how we use tables we'll use the followig logic:

  • Rows --> Contain whole entries or records

    • all the data in a row is meant to go together

  • Columns --> Individually they are attributes or fields

    • Each column is guaranteed to have only 1 type of data in it(e.g. name, title, balance, id_number)

  • Table --> relation

Relational instance as well for another term

  • Domain
    • The set of values allowed in a field

NULL

NULL is special, especially in sqlite3 because we aren't allowed to perform operations with it at all. If we tried to do for example NULL < 3 then we would just get back NULL; that way we avoid non-deterministic behavior and we are able to parse out bad results later on. There are a few exceptions to NULL however, where they will be accounted for.

  • Count
    • We only count if there is a row there or not, the data inside does not matter in this context.

Keys Types

  • Super Key
  • Candidate Key
  • Primary Key

Problem Statement

The rows are not distinguishable from each other; we still have a mess of data sitting there unlabeled. Some kind of identifier is necessary to be able to access every tuple in the relational set.

SuperKey

A set of attributes 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, because it might be able to identify a unique entry in our 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? As long as it can identify any unique row in a table then it is a superkey for that table.

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. To put it simply it is the most minimal superkey; though this doesn't entail that there can't be multiple candidate keys for a given table.

Primary key

Any candidate key the database designer has chosen to serve as the unique

Foreign Key

If a table/relation includes among it's attributes the primary key for another relation then it is referred to as a foreign key because that key references another relation. The table being refferred to is identified as a referenced relation.