ketchup on stuff from before break

cst363/lec/lec20.md

@@ -0,0 +1,32 @@
+# lec20
+
+_more on mapping cardinalities_
+
+## Pariticipation Constraints
+
+These are _perscriptive_ constraints.
+
+* total 
+
+If _all_ the entities in a set participate we say that the participation is total for that set.
+
+* partial
+
+If even one entity in the set is not participating then the pariticpation is _partial_ for that set.
+
+## Entity Keys
+
+If we have a table for a relationship, we can identify all the relationships if we can uniquely identify enties from either given set.
+Essentially if we can identify both(all) pariticipants in a given relationship table we can find any relationship in our relation-set.
+
+## Weak Entity Sets
+
+Any set where we can not uniquely all entities in that set.
+Let's say we have a tournament.
+
+We'll have players, with some _name_ and _jersey number_.
+We also have teams with a _team-name_ and likely some _team-id_.
+
+This means our players entity set is a weak set, but, because _all_ players participate in a team by definition of what a player is.
+Furthermore we may use the relationship between teams and players to idetify players.
+

cst363/lec/lec21.md

@@ -0,0 +1,56 @@
+# lec21
+
+## Strong & Weak Entity sets
+
+Strong: has a primary key in the set
+
+Weak: opposite of strong
+
+## Diagram things 
+
+_pretty formatting on diagrams means stuff_ 
+
+* Arrows
+
+* solid lines
+	* many 
+	* contributer [solid] contribution [solid] candidate
+
+* dotted lines
+	* only one 
+
+Say we have solid/arrow
+
+```
+student{id/name} --- [advisor] --> instructor{id/name}
+```
+Students can have at most 1 advisor \
+Instructor's can advise multiple students
+
+If we want to have some kind of advisor table we can identify each relationship with _just_ the student-id.
+We can do this because each student will only every 0,1 instructor's in an adivsory relationship
+
+## Composite Structures
+
+Logically compositing makes sense but sql doesn't like much aside from primitives so we can't really do that 
+
+Say then we have: 
+```
+contributor:
+id
+name
+address		<-- f to pay respects
+	city
+	state
+	zip
+```
+
+We just drop the address part if we wanted to convert this to something in sql.
+Reasoning here is case by case likewise need-to-know basis: ergo stick to da plan.
+
+## Normalization
+
+Process used to imporve schemas
+
+Basically a method of setting up rules to stop random bs from happennig.
+Also we typically remove redundancy from our schemas through this process 

cst363/lec/lec22.md

@@ -0,0 +1,34 @@
+# lec22
+
+## Functional Dependancy
+
+If we have an attribute a that could produce `b,c,d` reliably everytime then we would only need to keep track of `a` instead of keeping track of all the repeats because the dependants depend on `a`.
+
+Example:
+```
+building -> roomNumber
+```
+This one makes sense since we would likely be able to find duplicate room numbers in different buildings.
+Most places have a name for each building however.
+
+## BCNF
+
+> Boyce Codd Normal Form
+
+If we have a key which sources our redundancy we're ok because we can easily find all redundancies.
+If we're not looking at a key then we could be in the middle of a dependancy nest.
+
+Say we have a schema like `advisees(inst_id, student_id, student_name)`.
+Student name depends on `student_id` so there's no reason to have it in the schema.
+
+
+A schema follows BCNF if there's a non-trivial functional dependancy
+
+* x -> y for r
+* then x is a superkey for r
+
+## Example
+
+```
+instructor_offices(inst_id, name, office)
+```