bleh

cst363/lec/lec21.md

@@ -14,12 +14,12 @@ _pretty formatting on diagrams means stuff_
 
 * solid lines
 	* many 
-	* contributer [solid] contribution [solid] candidate
+	* Contributer [solid] contribution [solid] candidate
 
 * dotted lines
 	* only one 
 
-Say we have solid/arrow
+Let's say we have solid/arrow
 
 ```
 student{id/name} --- [advisor] --> instructor{id/name}
@@ -32,7 +32,7 @@ We can do this because each student will only every 0,1 instructor's in an adivs
 
 ## Composite Structures
 
-Logically compositing makes sense but sql doesn't like much aside from primitives so we can't really do that 
+Logically compositing makes sense but SQL does not like much aside from primitives so we can't really do that 
 
 Say then we have: 
 ```

cst363/lec/lec23.md

@@ -0,0 +1,41 @@
+# lec23
+
+_More on stuff about building a usable model for given data; more specifically BCF(Boyce Codd Normal Form)_
+
+BCNF : any table where the are no redundancies based on functional dependancies
+
+> 
+
+## Lossless Decomposition
+
+If we split a table that isn't in BCN form so that the new tables are in BCN form we should be able to natural join them back to the original state.
+
+## Normalization 3: Third Normal Form
+
+Take everything out from the original table which is part of a functional dependancy.
+
+Example:
+
+original: `id name office` {id -> name}
+
+Table 1: `id name` [functional dependancy participants]
+
+Table 2: `id office` [everything else + root of FD]
+
+This may be more expressive but the problem is then performance takes a hit because if we want to look for all the information from the first table we have to do a bunch of joins.
+This means going off to disk a bunch of times and back to memory bleh its slo.
+
+Let's say we have the following table(text view pls):
+
+student-id	|	dept-name	|	instructor-id
+------------|---------------|----------------
+1			|	Biology		|	10
+1			| 	Chemistry	|	20
+2			|	Biology		|	10
+
+
+## Lab Excercise
+
+1. BCNF: the form a table follows if it doesn't have redundancy which comes from functional dependency
+2. `order(CustID, CustName, ItemNum, Date)`: no because name depends on id?
+	* close: No. we can still create one more table aside with `id name`. we can create `id itemNum date`

cst363/lec/lec24.md

@@ -0,0 +1,27 @@
+# lec24
+
+## NoSQL
+
+Why NoSQL is a thing
+
+1. Scaling
+
+Scaling demands more computing power over time.
+Relational databases require more vertical scaling where machines must be upgraded constantly.
+
+Alternatively horizontal scaling allows for clustering computing style upgrades where computational power can be cheaper for upgrades maintaining support for large userbase.
+
+2. Data Migration
+
+If you change a schema then you have to painfully move everything over with the new schema.
+This means downtime in some cases, no matter how small the change.
+
+3. OOP
+
+`Rows != Objects`: the key distinction here is that objects can contain other objects while SQL rows can not.
+
+4. Open Source
+
+Many of the more popular NoSQL database systems happen to be open source and have permissive licensing.
+
+Getting started can suck though because you have sometimes have to implement certain features with something like _MySQL_ already have.

cst363/lec/lec25.md

@@ -0,0 +1,40 @@
+# lec25
+
+## Master-Slave
+
+Here we'll have a master node which handles updating data, but the slaves only deal with reads.
+
+## Peer to Peer 
+
+In this case we still have a reverse sink where things are input and then sent through some pipes to all the other nodes on that network.
+
+## Redundancy
+
+Apart from being redudant with data we can also do the same thing with workloads.
+
+## CAP Theorem
+
+* consistency 
+* availability 
+* partition tolerance
+
+Definition: You can't have all of these without some large tradeoffs.(shit happens all the time)
+
+If you optimize for accessability then you may not be able to optimize for consistency without sacrificing for one or the other.
+Say we have the following constraints:
+
+* n = number of replicas
+* w = number of nodes that must ack a write
+* r = number of nodes that must ack a read
+
+If you optimize for reads: r=1 w=n 
+
+Then reading is quick, meaning your data is more accessible, but it's also less reliable. 
+
+## Pessimistic Replication
+
+Traditional strategy: 
+
+* block access to data until it is up to date
+
+

cst363/project/todo.md

@@ -0,0 +1,3 @@
+# report
+
+should describe each relationship that entities participate in