Merge branch 'staging' of https://gitlab.com/shockrahwow/csnotes into staging
This commit is contained in:
Medium Fries
commit
986a020a8e
BIN
cst337/img/fig0lec10.png
Normal file
BIN
cst337/img/fig0lec10.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
BIN
cst337/img/fig1lec10.png
Normal file
BIN
cst337/img/fig1lec10.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
BIN
cst337/img/fig2lec10.png
Normal file
BIN
cst337/img/fig2lec10.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 11 KiB |
@ -1,4 +1,41 @@
|
||||
# lec10
|
||||
# lec11
|
||||
|
||||
> whole section still needs to be transcribed over fom paper
|
||||
At this point I'l mention that just reading isn't going to get you anywhere, you have to try things, and give it a real earnest attempt.
|
||||
|
||||
__ALU:__ Arithmetic Logic Unit
|
||||
|
||||
## Building a 1-bit ALU
|
||||
|
||||
|
||||
|
||||
First we'll create an example _ALU_ which implements choosing between an `and`, `or`, `xor`, or `add`.
|
||||
Whether or not our amazing _ALU_ is useful doesn't matter so we'll go one function at a time(besides `and/or`).
|
||||
|
||||
First recognize that we need to choose between `and` or `or` against our two inputs A/B.
|
||||
This means we have two inputs and/or, and we need to select between them.
|
||||
_Try to do this on your own first!_
|
||||
|
||||
|
||||
|
||||
Next we'll add on the `xor`.
|
||||
AGAIN: try to do this on your own, the main hint I'll give here is: the current mux needs to be changed.
|
||||
|
||||
|
||||
|
||||
Finally we'll add the ability to add and subtract.
|
||||
You may have also noted that we can subtract two things to see if they are the same dhowever, we can also `not` the result of the `xor` and get the same result.
|
||||
|
||||
|
||||
|
||||
At this point our _ALU_ can `and`, `or`, `xor`, and `add`/`sub`.
|
||||
The mux will choose one which logic block to use; the carry-in line will tell the `add` logic block whether to add or subtract.
|
||||
Finally the A-invert and B-invert line allow us to determine if we want to invert either A or B (inputs).
|
||||
|
||||
## N-bit ALU
|
||||
|
||||
For sanity we'll use the following block for our new ALU.
|
||||
|
||||
|
||||
|
||||
Note that we are chaining the carry-in's to the carry-out's just like a ripple adder.
|
||||
also each ALU just works with `1` bit from our given 4-bit input.
|
||||
|
||||
@ -1,41 +0,0 @@
|
||||
# lec11
|
||||
|
||||
At this point I'l mention that just reading isn't going to get you anywhere, you have to try things, and give it a real earnest attempt.
|
||||
|
||||
__ALU:__ Arithmetic Logic Unit
|
||||
|
||||
## Building a 1-bit ALU
|
||||
|
||||
|
||||
|
||||
First we'll create an example _ALU_ which implements choosing between an `and`, `or`, `xor`, or `add`.
|
||||
Whether or not our amazing _ALU_ is useful doesn't matter so we'll go one function at a time(besides `and/or`).
|
||||
|
||||
First recognize that we need to choose between `and` or `or` against our two inputs A/B.
|
||||
This means we have two inputs and/or, and we need to select between them.
|
||||
_Try to do this on your own first!_
|
||||
|
||||
|
||||
|
||||
Next we'll add on the `xor`.
|
||||
AGAIN: try to do this on your own, the main hint I'll give here is: the current mux needs to be changed.
|
||||
|
||||
|
||||
|
||||
Finally we'll add the ability to add and subtract.
|
||||
You may have also noted that we can subtract two things to see if they are the same dhowever, we can also `not` the result of the `xor` and get the same result.
|
||||
|
||||
|
||||
|
||||
At this point our _ALU_ can `and`, `or`, `xor`, and `add`/`sub`.
|
||||
The mux will choose one which logic block to use; the carry-in line will tell the `add` logic block whether to add or subtract.
|
||||
Finally the A-invert and B-invert line allow us to determine if we want to invert either A or B (inputs).
|
||||
|
||||
## N-bit ALU
|
||||
|
||||
For sanity we'll use the following block for our new ALU.
|
||||
|
||||
|
||||
|
||||
Note that we are chaining the carry-in's to the carry-out's just like a ripple adder.
|
||||
also each ALU just works with `1` bit from our given 4-bit input.
|
||||
118
cst337/lec/lec8.md
Normal file
118
cst337/lec/lec8.md
Normal file
@ -0,0 +1,118 @@
|
||||
# lec9
|
||||
|
||||
This lecture has a corresponding activity found in `lab/` it is called `combinational-logic.md`.
|
||||
It is more useful to practice combinational logic as opposed to read about it so the sub section here will be minimal in information.
|
||||
It's recommended that you try as many of the problems in the activity until you understand the concept, _don't bother doing them all_.
|
||||
|
||||
## Combinational Logic
|
||||
|
||||
### OR
|
||||
|
||||
`a+b` is equivalent to saying `a` or `b`.
|
||||
|
||||
### AND
|
||||
|
||||
`ab` is equivalent to saying `a` and `b`.
|
||||
|
||||
Note that this syntax is simlar to multiplication so `a*b` is equivalent to the above.
|
||||
|
||||
### NOT
|
||||
|
||||
`!a` is equivalent to saying not `a`.
|
||||
We can also denote it with a bar over the expression we want to _not_.
|
||||
|
||||
|
||||
|
||||
### Big AND
|
||||
|
||||
Behavior is the same as an `and` but instead of two inputs we can have many more inputs.
|
||||
It will only ever return a 1 if all inputs are 1.
|
||||
|
||||
### Big OR
|
||||
|
||||
Again we are mimicing the behvior of the normal or gate but this time we can have multiple inputs as opposed to just two.
|
||||
If only one of the many inputs is 1 then we return a 1 for the output of the Big OR.
|
||||
|
||||
## Decoders
|
||||
|
||||
Here we'll learn by doing
|
||||
|
||||
```
|
||||
Selector = 2 Bits
|
||||
Output = 4 Bits
|
||||
```
|
||||
As a challenge you can try using the combinational logic gates from above to try and tackle this yourself
|
||||
|
||||
|s1 |s2 |o3 |o2 |o1 |o0 |
|
||||
|---|---|---|---|---|---|
|
||||
| 0 | 0 | 0 | 0 | 0 | 1 |
|
||||
| 0 | 1 | 0 | 0 | 1 | 0 |
|
||||
| 1 | 0 | 0 | 1 | 0 | 0 |
|
||||
| 1 | 1 | 1 | 0 | 0 | 0 |
|
||||
|
||||
|
||||
## Multiplexor
|
||||
|
||||
Typically we'll refer to multiplexors by their size.
|
||||
|
||||
> what does it do?
|
||||
|
||||
It takes a signal as `2^n` inputs and out puts out `n` signals as output.
|
||||
|
||||
Example: We have a selector(s0), two inputs[in0 & in1], and one output `out`.
|
||||
The selector will select an input and we will generate some output in `out`.
|
||||
|
||||
|s0 | i1 | i0 | out|
|
||||
|---|---|---|---|
|
||||
|0 | 0 | 0 | 0|
|
||||
|0 | 0 | 1 | 1|
|
||||
|0 | 1 | 0 | 0|
|
||||
|0 | 1 | 1 | 1|
|
||||
|1 | 0 | 0 | 0|
|
||||
|1 | 0 | 1 | 0|
|
||||
|1 | 1 | 0 | 1|
|
||||
|1 | 1 | 1 | 1|
|
||||
|
||||
|
||||
This ultimately lets us pick data out of memory given some address.
|
||||
|
||||
## Half Adder
|
||||
|
||||
For now we'll take two inputs and get 1 output, with a carry-output.
|
||||
|
||||
Let's add 2 bits
|
||||
|
||||
|a |b |out|
|
||||
|---|---|---|
|
||||
|0 |0 |0 |
|
||||
|0 |1 |1 |
|
||||
|1 |0 |1 |
|
||||
|1 |1 |0 |
|
||||
|
||||
What about the carry bit however? What would _it_ look like given the preivous operations?
|
||||
|
||||
|a |b |carryout|
|
||||
|---|---|---|
|
||||
|0 |0 |0 |
|
||||
|0 |1 |0 |
|
||||
|1 |0 |0 |
|
||||
|1 |1 |1 |
|
||||
|
||||
Before what this implies note that the result of the carryout resembles
|
||||
|
||||
## Full Adder
|
||||
|
||||
Two inputs, One output, One carry-out, One carry-in
|
||||
|
||||
Here we'll add up `a & b`(inputs) and `c` carry-in
|
||||
|
||||
|c|a|b |output|
|
||||
|---|---|---|---|
|
||||
|0|0|0 |0|
|
||||
|0|0|1 |1|
|
||||
|0|1|0 |1|
|
||||
|0|1|1 |0|
|
||||
|1|0|0 |1|
|
||||
|1|0|1 |0|
|
||||
|1|1|0 |0|
|
||||
|1|1|1 |1|
|
||||
@ -1,118 +1,49 @@
|
||||
# lec9
|
||||
# lec10
|
||||
|
||||
This lecture has a corresponding activity found in `lab/` it is called `combinational-logic.md`.
|
||||
It is more useful to practice combinational logic as opposed to read about it so the sub section here will be minimal in information.
|
||||
It's recommended that you try as many of the problems in the activity until you understand the concept, _don't bother doing them all_.
|
||||
## Half-adder
|
||||
|
||||
## Combinational Logic
|
||||
This will be the building block for adding bit-strings together later on however, for now we are going to just add two singular bits.
|
||||
To accomplish this we'll build a half adder.
|
||||
|
||||
### OR
|
||||
This means our logic circuit must adhere to the following logic table.
|
||||
If both inputs are 0 then our result is 0 and we don't have to carry anything out.
|
||||
If only one input A/B is 1 then our result will clearly be 1 and our carry will be 0.
|
||||
Finally if both inputs are 0 then since we can't fit 2 in a single bit it means we have to carry-out a 1, and our result will be 0.
|
||||
|
||||
`a+b` is equivalent to saying `a` or `b`.
|
||||
With all of this in mind we have a table to guide how we will implement our logic circuit.
|
||||
I __highly__ suggest that you try to build a logic circuit on your own first as most of the content is best learned through practice.
|
||||
|
||||
### AND
|
||||
|
||||
`ab` is equivalent to saying `a` and `b`.
|
||||
|
||||
Note that this syntax is simlar to multiplication so `a*b` is equivalent to the above.
|
||||
|
||||
### NOT
|
||||
|
||||
`!a` is equivalent to saying not `a`.
|
||||
We can also denote it with a bar over the expression we want to _not_.
|
||||
|
||||
|
||||
|
||||
### Big AND
|
||||
|
||||
Behavior is the same as an `and` but instead of two inputs we can have many more inputs.
|
||||
It will only ever return a 1 if all inputs are 1.
|
||||
|
||||
### Big OR
|
||||
|
||||
Again we are mimicing the behvior of the normal or gate but this time we can have multiple inputs as opposed to just two.
|
||||
If only one of the many inputs is 1 then we return a 1 for the output of the Big OR.
|
||||
|
||||
## Decoders
|
||||
|
||||
Here we'll learn by doing
|
||||
|
||||
```
|
||||
Selector = 2 Bits
|
||||
Output = 4 Bits
|
||||
```
|
||||
As a challenge you can try using the combinational logic gates from above to try and tackle this yourself
|
||||
|
||||
|s1 |s2 |o3 |o2 |o1 |o0 |
|
||||
|---|---|---|---|---|---|
|
||||
| 0 | 0 | 0 | 0 | 0 | 1 |
|
||||
| 0 | 1 | 0 | 0 | 1 | 0 |
|
||||
| 1 | 0 | 0 | 1 | 0 | 0 |
|
||||
| 1 | 1 | 1 | 0 | 0 | 0 |
|
||||
|
||||
|
||||
## Multiplexor
|
||||
|
||||
Typically we'll refer to multiplexors by their size.
|
||||
|
||||
> what does it do?
|
||||
|
||||
It takes a signal as `2^n` inputs and out puts out `n` signals as output.
|
||||
|
||||
Example: We have a selector(s0), two inputs[in0 & in1], and one output `out`.
|
||||
The selector will select an input and we will generate some output in `out`.
|
||||
|
||||
|s0 | i1 | i0 | out|
|
||||
| A | B | Carry-out | Result |
|
||||
|---|---|---|---|
|
||||
| 0 | 0 | 0 | 0 |
|
||||
|0 | 0 | 1 | 1|
|
||||
|0 | 1 | 0 | 0|
|
||||
|0 | 1 | 1 | 1|
|
||||
|1 | 0 | 0 | 0|
|
||||
|1 | 0 | 1 | 0|
|
||||
|1 | 1 | 0 | 1|
|
||||
|1 | 1 | 1 | 1|
|
||||
| 0 | 1 | 0 | 1 |
|
||||
| 1 | 0 | 0 | 1 |
|
||||
| 1 | 1 | 1 | 0 |
|
||||
|
||||
|
||||
This ultimately lets us pick data out of memory given some address.
|
||||
|
||||
## Half Adder
|
||||
|
||||
For now we'll take two inputs and get 1 output, with a carry-output.
|
||||
|
||||
Let's add 2 bits
|
||||
|
||||
|a |b |out|
|
||||
|---|---|---|
|
||||
|0 |0 |0 |
|
||||
|0 |1 |1 |
|
||||
|1 |0 |1 |
|
||||
|1 |1 |0 |
|
||||
|
||||
What about the carry bit however? What would _it_ look like given the preivous operations?
|
||||
|
||||
|a |b |carryout|
|
||||
|---|---|---|
|
||||
|0 |0 |0 |
|
||||
|0 |1 |0 |
|
||||
|1 |0 |0 |
|
||||
|1 |1 |1 |
|
||||
|
||||
Before what this implies note that the result of the carryout resembles
|
||||
|
||||
|
||||
## Full Adder
|
||||
|
||||
Two inputs, One output, One carry-out, One carry-in
|
||||
If we only want to add single-bit's then a half-adder works fine but if we want to add multiple bits say `1011 + 0010` then we need to consider that we will likely have to chain these together.
|
||||
The full-adder has 1 main difference from the half-adder, it has 3 inputs, 2 main inputs and 1 input for the carry bit.
|
||||
The carry bit will propagate along the operation now if we chain these together, _just like real addition!_
|
||||
|
||||
Here we'll add up `a & b`(inputs) and `c` carry-in
|
||||
|
||||
|
||||
|c|a|b |output|
|
||||
|---|---|---|---|
|
||||
|0|0|0 |0|
|
||||
|0|0|1 |1|
|
||||
|0|1|0 |1|
|
||||
|0|1|1 |0|
|
||||
|1|0|0 |1|
|
||||
|1|0|1 |0|
|
||||
|1|1|0 |0|
|
||||
|1|1|1 |1|
|
||||
With this we can start chaining together multiple Full-adders we can start adding multiple bits at the same time since the carry now propagates along the chain.
|
||||
|
||||
## Ripple Adders
|
||||
|
||||
An N-bit adder is really just made up of Full adders chained together.
|
||||
Each adder is chained to the next by the carry-out line which then acts as the next adder's carry-in line.
|
||||
If we have say a 4-bit ripple adder, then each bit in the bit strings will go to a different adder.
|
||||
For now the initial carry in bit will be fed a 0 everytime.
|
||||
|
||||
|
||||
|
||||
Here we see that our 4-bit input A & B have the values `1111` & `0000` respectively.
|
||||
The 0th bit goes to Adder0, the 1th goes to Adder1, and so on.
|
||||
You should have also noticed that each one also takes a carry-in, which for now is 0 but it does mean we have to let the comutation happen one adder at a time.
|
||||
None of the sequential adders can do anything if the previous have done anything yet either.
|
||||
At the end of it all we get some bit results, and a carry-out.
|
||||
We can then simply reassemble the results back into one bit-string to assemble our final result.
|
||||
|
||||
@ -1,25 +1,35 @@
|
||||
# lec1
|
||||
|
||||
## A few reasons to have them \
|
||||
And what they *require* \
|
||||
Database systems generally need support for:
|
||||
1. querying - \
|
||||
* Finding things \
|
||||
## Databases introduction
|
||||
|
||||
First off why do we even need a database and what do they accomplish?
|
||||
|
||||
Generally a databse will have 3 core elements to it:
|
||||
|
||||
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 \
|
||||
2. access control
|
||||
* who can access which data segments and what they can do with that data
|
||||
* reading, writing, sending, etc
|
||||
|
||||
3. corruption prevention - \
|
||||
3. corruption prevention
|
||||
* mirroring/raid/parity checking/checksums/etc as some examples
|
||||
|
||||
## Modeling Data \
|
||||
## Modeling Data
|
||||
|
||||
Just like other data problems we can choose what model we use to deal with data.
|
||||
In the case for sqlite3 the main data model we have are tables, where we store our pertinent data, and later we'll learn even data about our data is stored in tables.
|
||||
|
||||
__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. \
|
||||
Because everything goes into a table, it means we also have to have a plan for _how_ we want to lay out our data in the table.
|
||||
The __schema__ is that design/structure for our databse.
|
||||
The __instance__ is the occurance of that schema with some data inside the fields, i.e. we have a table sitting somewhere in the databse which follows the given structure of a aforemention schema.
|
||||
|
||||
__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. \
|
||||
__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.
|
||||
Finally we have __transactions__ which are a set of operations who are not designed to only commit if they are completed successfully.
|
||||
Transactions are not alllowed to fail.
|
||||
If _anything_ fails then everything should be undone and the state should revert to previous state.
|
||||
This is useful because if we are, for example, transferring money to another account we want to make sure that the exchange happens seamlessly otherwise we should back out of the operation altogether.
|
||||
|
||||
|
||||
@ -2,61 +2,64 @@
|
||||
|
||||
Covering `tables, tuples, data stuff`
|
||||
|
||||
## Problem Statement \
|
||||
## Problem Statement
|
||||
|
||||
We need to be able to manipulate data easily
|
||||
|
||||
> IMS had been using trees for a while a long time ago
|
||||
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.
|
||||
|
||||
> Rows --> __atributes__
|
||||
To actually guide _how_ we use tables we'll use the followig logic:
|
||||
|
||||
> Columns --> __tuple__
|
||||
* Rows --> Contain whole entries or records
|
||||
* all the data in a row is meant to go together
|
||||
|
||||
somtimes we refer to the title of the columns to be fields
|
||||
* 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__
|
||||
* Table --> __relation__
|
||||
|
||||
relational instance as well for another term
|
||||
Relational instance as well for another term
|
||||
|
||||
> Domain
|
||||
|
||||
The set of values allowed in a field
|
||||
* Domain
|
||||
* The set of values allowed in a field
|
||||
|
||||
## NULL
|
||||
|
||||
cant operate on it at all
|
||||
`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
|
||||
|
||||
The only thing that lets you operate on NULL. Even then you only get 0 back.
|
||||
* 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
|
||||
* Super Key
|
||||
* Candidate Key
|
||||
* Primary Key
|
||||
|
||||
> Candidate Key
|
||||
### Problem Statement
|
||||
|
||||
> 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.
|
||||
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
|
||||
|
||||
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.
|
||||
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?
|
||||
* 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
|
||||
* 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
|
||||
|
||||
@ -64,5 +67,6 @@ 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.
|
||||
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.
|
||||
|
||||
|
||||
@ -1,15 +1,15 @@
|
||||
# lec4
|
||||
|
||||
This section mostly relies on practicing some of the most basic commands for sqlite3, for that reason most of the content is expressed through practice in the lab sub-section.
|
||||
|
||||
## Lab*
|
||||
|
||||
This lecture has some lab questions in the `lab/` dircory named `table1.pdf` *and* some example data called `patients.sql`.
|
||||
`table1.pdf` will have some exercises to learn the basic commands of sqlite and `patients.sql` should have some example data which _table1_ asks you to query.
|
||||
This lecture has some lab questions in the `lab/` directory named `table1.pdf` *and* some example data called `patients.sql`.
|
||||
`table1.pdf` will have some exercises to learn the basic commands of sqlite3 and `patients.sql` should have some example data which _table1_ asks you to query.
|
||||
|
||||
## Serverless
|
||||
|
||||
Instead of having listen server listen for requests to perform actions upon these requests we simply have some databse held on a machina and we perform all of our sql commands on that machine.
|
||||
|
||||
For now we'll be dealing with small test db's so that we can practice the commands and observe each one's behavior; this will give you a good feeling of what does what in sqlite3.
|
||||
Instead of having listen server listen for requests to perform actions upon these requests we simply have some database held on our own machine and we perform all of our sql commands on that machine.
|
||||
For now we'll be dealing with small test databases so that we can practice the commands and observe each one's behavior; this will give you a good feeling of what does what in sqlite3.
|
||||
|
||||
|
||||
|
||||
@ -7,33 +7,35 @@ This lecture will have a lab activity in `cst366/lab/1994-census-summary.sql` wi
|
||||
|
||||
## Distinct Values
|
||||
|
||||
> Mininum - min(field)
|
||||
* Mininum - min(field)
|
||||
|
||||
Finds the smallest value in the given filed
|
||||
|
||||
> Maximum - max(field)
|
||||
* Maximum - max(field)
|
||||
|
||||
Find the largest value in th given field
|
||||
Find the largest value in the given field
|
||||
|
||||
Say we have a column where we know there are duplicate values but we want to konw what the distinct values in the column may be.
|
||||
SQLite3 has a function for that: `select distinct field, ... from table;`
|
||||
|
||||
> select substr(field, startIndex, length) ...
|
||||
* select substr(field, startIndex, length) ...
|
||||
|
||||
_Note_: the start index starts counting at `1` so keep in mind we are offset `+1`.
|
||||
_Note_: the start index starts counting at `1` so keep in mind we are offset `+1` compared to other language like C.
|
||||
|
||||
## Joins
|
||||
|
||||
Now we want to join to tables together to associate their respective data.
|
||||
To accomplish this we can perform a simple `join` to combine tables.
|
||||
Important to note that a simple join does not necessarily take care of duplicate fields.
|
||||
If we have duplicate fields we must denote them as `target.field`.
|
||||
Here target is the table with the desired table and field is the desired field.
|
||||
Here `target` is the table with the desired table and `field` is the desired field.
|
||||
|
||||
## Type Casting
|
||||
|
||||
If we have say `56` we can use a cast to turn it into an integer.
|
||||
If we have say `"56"` we can use a cast to turn it into an integer.
|
||||
|
||||
> cast(targetString as integer)
|
||||
|
||||
This will return with an error if a non number character is given as input to the cast function, here in this example we denote it with `targetString`.
|
||||
|
||||
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
|
||||
This lecture features a lab activity in the lab/ directory named: `courses-ddl.sql` with instructions in `simple-joins-lab.pdf`.
|
||||
|
||||
* Note: Just make sure to read int courses-ddl.sql first then courses-small.sql second otherwise there will be random errors.(I'm not taking responsibility for that garbage so don't flame me)
|
||||
* Note: Just make sure to read in courses-ddl.sql _first_ then courses-small.sql _second_ otherwise there will be random errors.(I'm not taking responsibility for that garbage so don't flame me)
|
||||
|
||||
## Natural Joins
|
||||
|
||||
@ -15,4 +15,5 @@ Form:
|
||||
```
|
||||
select columns_[...] from tableLeft natural join tableRight
|
||||
```
|
||||
While ther is no need to write extra `where` statements there is also the issue where there may be accidental matches since attributes are dropped.
|
||||
While there is no need to write extra `where` statements there is also the issue where there may be accidental matches since attributes are dropped.
|
||||
This implies that if two tables have attributes with the same field name, then only one will be returned in the resulting table.
|
||||
|
||||
@ -6,14 +6,12 @@ This lecture has two correspondnig lab activities in `lab/` using `1994-census-s
|
||||
|
||||
## Null Operations
|
||||
|
||||
take the following table as a trivial example of working data
|
||||
Take the following table as a trivial example of working data
|
||||
|
||||
```
|
||||
a | b
|
||||
-----
|
||||
1 | 2
|
||||
3 | N
|
||||
```
|
||||
| a | b |
|
||||
|---|---|
|
||||
| 1 | 2 |
|
||||
| 3 | N |
|
||||
|
||||
Where `a` and `b` are attributes and N signifiies a NULL value.
|
||||
If we `select a+b from table` we only get back 2 rows like normal but the second row is left empty since we are operating with a NULL value.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user