Week 2 notes completed
This commit is contained in:
@ -0,0 +1,45 @@
|
||||
# What shape is your data?
|
||||
## Sorts of structure
|
||||
* Structures in programming environments
|
||||
* Structures in data models
|
||||
* Structures in serializations (data formats)
|
||||
* Structures in exchange protocols
|
||||
* Structures in user interfaces
|
||||
|
||||
## Shapes available
|
||||
* Tables
|
||||
* Trees
|
||||
* Graphs
|
||||
* Media (raw data)
|
||||
* Documents/objects
|
||||
|
||||
# Tables
|
||||
## What does a table look like?
|
||||
A table can be seen as a collection of cells where each _row_ represents a thing and each column represents a type of information about the thing.
|
||||
|
||||
A strength of a table is that it's easy to understand, search and communicate meaning.
|
||||
|
||||
However, conveying hierarchy cannot be done.
|
||||
|
||||
# Trees
|
||||
They have only one parent node instead of two in family trees.
|
||||
The root node is represented at the top in diagrams.
|
||||
|
||||
# Other
|
||||
Tree nodes can only have one parent at the most. However, when there start to be more parents for a node, we're now talking about a graph.
|
||||
|
||||
Tables: General-purpose
|
||||
Trees: Heterogeneous and hierarchical, structured data
|
||||
Graphs: Heterogeneous, non-hierarchical, structured data
|
||||
Blobs: Inaccessible data for storage
|
||||
Features: Searchable information derived from blobs
|
||||
Documents: Rich, but not interrelated data
|
||||
|
||||
# Summary
|
||||
* Where does your data come from?
|
||||
* How well does it fit your needs?
|
||||
* How is it structured?
|
||||
* How well can it be integrated?
|
||||
* How should your data be structured?
|
||||
* How will you use yoru data?
|
||||
* Will others use your data?
|
||||
Reference in New Issue
Block a user