OMEGALUL

cst363/.gitignore

@@ -0,0 +1 @@
+lab/

cst363/lec/lec1.md

@@ -0,0 +1,25 @@
+# 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.
+

cst363/lec/lec2.md

@@ -0,0 +1,54 @@
+# 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
+
+> Super Key \
+> Candidate Key \
+> Primary Key \
+
+## Problem with rows
+
+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
+
+_one more key type_ \
+### 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.
+

cst363/readme.md

@@ -0,0 +1,8 @@
+# ?
+Notes are ordered from lec[1].md to lec[N].md 
+
+To be stitched later at some point.
+
+## Markkdown flavor?
+
+Pandoc, if this compiles nicely on other platforms then great but idfc tbqh famalam