Skip to content

Commit e396ee0

Browse files
committed
Added - Notes about Databases
1 parent 77aafa2 commit e396ee0

File tree

3 files changed

+142
-0
lines changed

3 files changed

+142
-0
lines changed

Notes/18. Flat-file Databases.md

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
# 1. Flat-file Databases
2+
3+
A **flat-file database** is a **database** stored in a file called a _flat file_. Records follow a uniform format, and there are no structures for indexing or recognizing relationship between records. Relationships can be inferred from the data in the **database**, but the format of the **database** doesn't make those relationships explicit.
4+
5+
A flat file can be a **plain text file** (csv, tsv, txt) or a **binary file**.
6+
7+
The **records** in the **database** are separated by delimiters such as _tabs_ or _commas_ and each line holds only one record.
8+
9+
---
10+
11+
## 1.1. Advantages of Flat-file Databases
12+
13+
- all records are stored in one place;
14+
- easy to understand and configure;
15+
- an excellent option for small databases;
16+
- requires less hardware and software components;
17+
18+
---
19+
20+
## 1.2. Disadvantages of Flat-file Databases
21+
22+
- they are harder to update;
23+
- harder to change data format;
24+
- poor in terms of complex queries;
25+
- increased redundancy and inconsistency;

Notes/19. Relational Databases.md

Lines changed: 78 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,78 @@
1+
# 1. Relational Databases
2+
3+
A **relational database** is a type of **database** that stores and provides access to data points that are _related to one another_. **Relational databases** are based on the _relational model_, which is a way of representing data in **tables**. Each row in the **table** is a record with a unique ID called **key**. The columns of the **table** hold attributes of the data, and each record usually has a value of each attribute, making it easy to establish relationships among data points.
4+
5+
**SQL** or **Structured Query Language** is used to write and query data in the **database**. **SQL** allows for four types of commands: _create_, _read_, _update_, and _delete_, also known as _CRUD_.
6+
7+
Although **SQL** is the standard _ANSI_/_ISO_, there are different versions of the language. Most of the **SQL** **database** programs have their own proprietary extensions in addition to the SQL standard.
8+
9+
A **relational database management system** or **RDBMS** is a program used to create, update and manage such **databases**.
10+
11+
---
12+
13+
## 1.1. Database Schema
14+
15+
The **database schema** is the skeleton structure of the **database** described in a _formal language_ supported by the **database management system**. The term _schema_ refers to the organization of data as a blueprint of how the database is constructed (divided into database tables).
16+
17+
---
18+
19+
## 1.2. Relational Model
20+
21+
The **relational database model** allows any table to be related to another table using a common attribute. Instead of using hierarchical structures to organize data, the data is stored, accessed and related in tables without reorganizing the tables that contain them.
22+
23+
---
24+
25+
### 1.2.1. Types of Relational Models
26+
27+
There are three types of relational models in **DBMS**.
28+
29+
1. **One-to-Many Model**
30+
31+
In this type of relationship, one entity is related to multiple other entities. The key feature of the model is that the relationship between two entities is not reciprocal. For example, a customer can have multiple orders on a website, but that order cannot have multiple customers.
32+
33+
2. **One-to-One Model**
34+
35+
The **one-to-one model** states that there is a direct and unique relationship between two specific objects. In other words, each object can only be related to one other object and vice versa. This type of relationship is often used to represent relations between physical things, such as people and their driver's license number.
36+
37+
3. **Many-to-Many Model**
38+
39+
In a **many-to-many model**, each record in the primary table can be linked to multiple records in the foreign table and vice versa. This type of relationship is less common. One such example migh be between students and courses. A student can take multiple courses and a course can have multiple students enrolled.
40+
41+
---
42+
43+
## 1.3. Primary Key & Foreign Key
44+
45+
The **primary key** constraint uniquely identifies each record in a table. **Primary keys** must be _unique_ and cannot contain _null values_. A table can only have one **primary key** and the **key** can consist of single or multiple columns (fields).
46+
47+
The **foreign key** constraint is used to prevent actions that would destroy links between tables, so it's a field or a collection of fields in one table, that refers to the **primary key** in another table.
48+
49+
The table with the **foreign key** is called the _child_ table, and the table with the **primary key** is the _referenced_ or _parent_ table.
50+
51+
---
52+
53+
## 1.4. Example
54+
55+
### **Employees Table**
56+
57+
| PersonID | LastName | FirstName | Age |
58+
|----------|----------|-----------|-----|
59+
| 1 | Halpert | Jim | 28 |
60+
| 2 | Scott | Michael | 42 |
61+
| 3 | Beesly | Pam | 26 |
62+
| 4 | Schrute | Dwight | 34 |
63+
| 5 | Malone | Kevin | 39 |
64+
65+
### **Sales Table**
66+
67+
| SaleID | SaleNumber | PersonID |
68+
|--------|------------|----------|
69+
| 1 | 4985 | 1 |
70+
| 2 | 3455 | 4 |
71+
| 3 | 2321 | 2 |
72+
| 4 | 6752 | 1 |
73+
| 5 | 8795 | 3 |
74+
75+
- the _PersonID_ column in the **Sales Table** points to the _PersonID_ in the **Employees Table**;
76+
- the _PersonID_ in the **Employees Table** is the **Primary Key** in the **Employees Table**;
77+
- the _PersonID_ in the **Sales Table** is the **Foreign Key** in the **Sales Table**;
78+
- the relationship between the two is **one-to-many**, an employee can have multiple sales, but that sale cannot have multiple employees, in this case.
Lines changed: 39 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,39 @@
1+
# 1. Non-Relational Databases
2+
3+
A **non-relational database** is a **database** that does not use the tabular schema of rows and columns found in most traditional database systems. Instead, they use a storage model that is optimized for the specific requirements of the type of data being stored.
4+
5+
These type of **databases** don't use the _relational model_. Also, they tend to be more specific in the type of data they support and how data can be queried.
6+
7+
The term **NoSQL** refers to data stores that do not use **SQL** for queries. Instead, the data stores use other programming languages and constructs to query the data. Although **NoSQL** stands for _non-relational database_, many of these **databases** support **SQL** compatible queries. However, the query execution is usually very different from how a traditional **RDBMS** would execute the same query.
8+
9+
---
10+
11+
## 1.1. Types of Non-Relational Databases
12+
13+
### **1. Document Data Stores**
14+
15+
A document data store manages a set of named string fields and object data values in an entity that's referred to as a _document_. They tend to store data in the form of JSON documents.
16+
17+
### **2. Columnar Data Stores**
18+
19+
A columnar or column-family data store organizes data into columns and rows. They can appear very similar to relational databases, conceptually. The real power of this type of databases lies in its denormalized approach to structuring sparse data, which stems from the column-oriented approach to storing data.
20+
21+
### **3. Key-Value Data Stores**
22+
23+
It's essentially a large hash table/dictionary. You associate each value with a unique key, and the key/value store uses this key to store the data by using an appropiate hashing function. The hashing function is selected to provide an even distribution of hashed keys across the data storage.
24+
25+
### **4. Graph Data Stores**
26+
27+
A graph data store manages two types of information, nodes and edges. Nodes represent entities, and edges specify the relationships between these entities. Both nodes and edges can have properties that provide information about that node or edge, similar to columns in a table. Edges can also have a direction indicating the nature of the relationship.
28+
29+
### **5. Time Series Data Stores**
30+
31+
Time series data is a set of values organized by time, and a time series data store is optimized for this type of data. Time series data stores must support a very high number of writes, as they typically collect large amounts of data in real time from a large number of sources. Time series data stores are optimized for storing telemetry data. Scenarios include IoT sensors or application/system counters.
32+
33+
### **6. Object Data Stores**
34+
35+
Object data stores are optimized for storing and retrieving large binary objects or blobs such as images, text files, video and audio streams, large application data objects and documents, and virtual machine disk images. An object consists of the stored data, some metadata, and a unique ID for accessing the object. Object stores are designed to support files that are individually very large, as well provide large amounts of total storage to manage all files.
36+
37+
### **7. External Index Data Stores**
38+
39+
External index data stores provide the ability to search for information held in other data stores and services. An external index acts as a secondary index for any data store, and can be used to index massive volumes of data and provide near real-time access to these indexes.

0 commit comments

Comments
 (0)