gaspersic/freeCodeCamp
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

fix(guide): simplify directory structure

Browse Source
This commit is contained in:
Mrugesh Mohapatra
2018-10-16 21:26:13 +05:30
parent f989c28c52
commit da0df12ab7
35752 changed files with 0 additions and 317652 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
guide/english/computer-science/databases/acid/index.md Normal file
View File

@@ -0,0 +1,23 @@
---
title: ACID
---
## ACID
In computer science, ACID (Atomicity, Consistency, Isolation, Durability) is a set of properties for database modifications. They help guarantee the validity of a transaction, even with errors or failures.
A **transaction** is any sequence of database operations that satisfies the ACID properties and could be viewed as a single logical operation on the data. An example is a transfer of funds from one bank account to another. This involves multiple changes, such as debiting one account and crediting another, but is considered to be a single transaction.
### Atomicity
This means that a complex transaction is either processed completely, or not at all. If one part of the transaction fails, then the entire transaction does not complete and the database is unchanged. This way, if there's a crash, power failure, or error, the database doesn't end up in a state where only parts of a transaction are done.
### Consistency
This means that data will be consistent. Any data entered into the database must be valid and permitted based on any constraints you specify. It makes sure that any transaction changes the database from one valid state to another valid state.
### Isolation
This means that if two transactions execute at the same time, one transaction can't read data from a transaction that hasn't yet completed. Each transaction will see the database as if the transactions were executing sequentially. If one transaction needs to read data that the other is writing, it has to wait until the other transaction is finished. The effects of an incomplete transaction will not affect another transaction.
### Durability
This means that once a transaction is complete, it will remain so, even in the event of a power loss or other errors. It guarantees that all of the changes are recorded to a non-volatile storage medium (such as a hard disk), and it makes a record of the completed transaction.
### More Information:
- ACID article: <a href='https://en.wikipedia.org/wiki/ACID' target='_blank' rel='nofollow'>Wikipedia</a>
- Video overview: <a href='https://www.youtube.com/watch?v=LSB4eceRsw8' target='_blank' rel='nofollow'>YouTube</a>

10
guide/english/computer-science/databases/column-databases/index.md Normal file
View File

@@ -0,0 +1,10 @@
---
title: Column Databases
---
## Column Databases
Column oriented databases are designed to efficiently return data for a limited number of columns. It does it by storing all of the values of a column together. A column oriented database will excel at read operations on a limited number of columns, however write operation will be expensive compared to row oriented databases.
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
Please visit the <a href="https://en.wikipedia.org/wiki/Column-oriented_DBMS">Column-oriented DBMS</a> Wikipedia page for more information.

23
guide/english/computer-science/databases/document-store-databases/index.md Normal file
View File

@@ -0,0 +1,23 @@
---
title: Document Store Databases
---
## Document Store Databases
A document store database is considered to be yet another type of NoSQL database that is very similar to a Key Value database. A record in a document store represents a single structured document that can be different from all other documents in the database. Unlike a relational database, there is no mapping of objects to various table in the database. Instead we can take the entire object and write it directly into a document store database.
For example, we could have the following object inside of our code.
```json
{
"name": "freeCodeCamp",
"job": "contributor"
}
```
This entire object can be written directly into a document store database without further parsing.
#### More Information:
[MongoDB](https://www.mongodb.com/document-databases)
[Elasticsearch](https://www.elastic.co/)

19
guide/english/computer-science/databases/fault-tolerance/index.md Normal file
View File

@@ -0,0 +1,19 @@
---
title: Fault Tolerance
---
## Fault Tolerance
Fault tolerance is the property that enables a system to continue its intended operation, possibly at a reduced level, rather than failing completely, when some portion of the system fails.
A **database** is fault-tolerant when it can access a secondary shard when the primary is unavailable.
This is achieved through:
* Database Replication
* Fault Detection & Failover
A database that maintains multiple copies of all data in different physical nodes located across independent physical sub-systems, such as server racks and network routers, has a higher probability to continue operating when the primary copy of the data is unavailable due to its ability to read data from multiple replications.
In large-scale distribution systems, it becomes increasingly important to have reliable failure detection systems that can identify failing storage drives and provide failover units in order to maximise service uptime.

11
guide/english/computer-science/databases/graph-databases/index.md Normal file
View File

@@ -0,0 +1,11 @@
---
title: Graph Databases
---
## Graph Databases
A graph database is a database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data. A key concept of the system is the graph (or edge or relationship), which directly relates data items in the store. The relationships allow data in the store to be linked together directly, and in many cases retrieved with one operation.
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->
* <a href='https://en.wikipedia.org/wiki/Graph_database' target='_blank' rel='nofollow'>Graph Databases</a>

15
guide/english/computer-science/databases/index.md Normal file
View File

@@ -0,0 +1,15 @@
---
title: Databases
---
## Databases
This is a stub. <a href='https://github.com/freecodecamp/guides/tree/master/src/pages/computer-science/databases/index.md' target='_blank' rel='nofollow'>Help our community expand it</a>.
<a href='https://github.com/freecodecamp/guides/blob/master/README.md' target='_blank' rel='nofollow'>This quick style guide will help ensure your pull request gets accepted</a>.
<!-- The article goes here, in GitHub-flavored Markdown. Feel free to add YouTube videos, images, and CodePen/JSBin embeds -->
#### More Information:
<!-- Please add any articles you think might be helpful to read before writing the article -->

17
guide/english/computer-science/databases/indexes/index.md Normal file
View File

@@ -0,0 +1,17 @@
---
title: Indexes
---
## Indexes
A **database index** is a data structure that improves the efficiency of data retrievals on a database table. A database table can have more than one index and an index could be created on one or more columns of a database table.
### How do indexes work?
Now imagine you are in a library where the books are not arranged in a predetermined order. If you were tasked to find a book, you would have to go shelf by shelf to locate it. This may be fine when there are only a few shelves of books, but the process is very time consuming if it is a multi-storey library.
On the other hand, assume that the books are now arranged by the last name of author. Given that you know the last name of the author for the book you are searching for, for example "Carnegie", you may look for shelve for "C" and then search within the specific shelf. You have saved yourself from going through every single shelf.
### The tradeoff
As described earlier, an **index** is a data structure, hence it takes up storage space. The more indexes are defined, the more storage space is taken up to maintain the data structure. Another cost comes in the form of additional updates (or writes) to keep the indexes up to date. When new records are added to a table that has an index, additional writes are required to update the index data structure.
#### More Information:
[Database Index](https://en.wikipedia.org/wiki/Database_index)

54
guide/english/computer-science/databases/key-value-databases/index.md Normal file
View File

@@ -0,0 +1,54 @@
---
title: Key Value Databases
---
## Key Value Databases
A key-value database, or key-value store, is a type of [NoSQL](https://en.wikipedia.org/wiki/NoSQL) database that uses a key/value storage. This means that the data stored in the database is a collection of key-value pairs.
This type of data structure is used on many programming languages. Key-value pairs are commonly known as associative arrays, dictionaries or hash. For example, consider a dictionary of phone numbers:
| key | value |
|------------|-------------|
| Rick | 1234555 |
| Morty | 7754321 |
| Summer | 5512377 |
### The Key
The `key` in a key-value pair must be unique. Having a unique identifier will allow you to access the value associated with a given key.
In theory, the key can be anything you want. A key can be a string, a binary sequence, an image, among others. However, some databases may impose limitations on the type of keys that can be used.
Here are some recommendations:
- Keys should follow a convention in order to have consistency. Keys in a phone numbers dictionary should always be names, and not a combination of names, e-mail addresses and numbers.
- Keys should not be too long, or you might have performance issues.
- Keys should not be too short, or you might have readability issues.
### The Value
The `value` in a key-value store can be anything you want. This includes strings, numbers, code, an image, a list, or even another key-value pair. Some databases allow you to restrict the data type that can be stored.
### Use Cases
Key-value databases can be used on multiple scenarios. Here is a list of the most common applications:
- Telecom directories.
- User profiles and session information.
- Shopping cart contents.
- Product details or reviews.
- Internet Protocol (IP) forwarding tables.
- Services health status or configuration.
### Examples
Here are some examples of databases that use the key-value approach:
- [Redis](https://redis.io)
- [Oracle NoSQL Database](https://www.oracle.com/database/nosql/index.html)
- [Cassandra](http://cassandra.apache.org) (hybrid between key-value and column-oriented databases)
- [Voldemort](http://www.project-voldemort.com/voldemort/)
- [Consul KV store](https://www.consul.io/intro/getting-started/kv.html) (a tool with it's own key-value store)
#### More Information:
* Key-value databases on [Wikipedia](https://en.wikipedia.org/wiki/Key-value_database)
Key-Value database is a simple database that uses a map or a dictionary as the fundamental data model where each key is associated with one and only one value in a collection and is the most flexible type of NoSQL database.

30
guide/english/computer-science/databases/non-relational-databases/index.md Normal file
View File

@@ -0,0 +1,30 @@
---
title: Non-Relational-Databases
---
## When to Use
If you’re dealing with a phenomenally huge amount of data, it can be way too tedious, and the probability of error (in the form of an ORM Impedance Mismatch issue) increases. In that situation you may need to consider going with a non-relational database. A non-relational database just stores data without explicit and structured mechanisms to link data from different tables (or buckets) to one another. If your data model turns out to be very complex, or if you find yourself having to de-normalize your database schema, non-relational databases may be the best way to go.
Other reasons for choosing a non-relational database include:
- The need to store serialized arrays in JSON objects
- Storing records in the same collection that have different fields or attributes
- Finding yourself de-normalizing your database schema or coding around performance and horizontal scalability issues
- Problems easily pre-defining your schema because of the nature of your data model
## Disadvantages
In non-relational databases, there are no joins like there would be in relational databases. This means you need to perform multiple queries and join the data manually within your code -- and that can get very ugly, very fast.
## Example Databases
- MongoDB
- NoSQL
## References
- (https://www.pluralsight.com/blog/software-development/relational-non-relational-databases)
- (https://en.wikipedia.org/wiki/NoSQL)

115
guide/english/computer-science/databases/normal-form/index.md Normal file
View File

@@ -0,0 +1,115 @@
---
title: Normal Form
---
## Normal Form
Normalization was first introduced as part of the relational model. It is the process of organizing data tables and columns in a way that reduces redundancies and improves integrity. This can either be done through :
* synthesis : creates a normalized database design based on a known set of dependencies.
* decomposition : takes an existing (insufficiently normalized) database design and improves it based on the known set of dependencies
There are three common normal forms (1st, 2nd and 3rd) plus a rather advanced form called BCNF. They are progressive : in orther to qualify for the 3rd normal form, a database schema must satisfy the rules of the 2nd normal form, and so on for the 1st normal form.
* **1st normal form** : The information is stored in a table, each column contains atomic values, and there are not repeating groups of columns. This :
1. Eliminates repeating groups in individual tables.
2. Creates a separate table for each set of related data.
3. Identifies each set of related data with a primary key
##### Example
A design that violates the 1st normal form, the "telephone" column does not contain atomic values
| customer ID | First name | Last name | Telephone |
|-------------|------------|-----------|--------------------------------------|
| 123 | Pooja | Singh | 555-861-2025, 192-122-1111 |
| 789 | John | Doe | 555-808-9633 |
| 456 | San | Zhang | (555) 403-1659 Ext. 53; 182-929-2929 |
One solution would be to have an extra column for each phone number. But then, this will repeat conceptually the same attribute(phone number). Moreover, adding extra telephone number will require reorganizing the table by adding more column.This is definitely not practicle.
Another solution is to have a separate table for the association customer <-> Telephone: This respects the 1st normal form and there can be as many rows per customer as needed.
| customer ID | First name | Last name |
|-------------|------------|-----------|
| 123 | Pooja | Singh |
| 789 | John | Doe |
| 456 | San | Zhang |
| customer ID | Telephone |
|-------------|------------------------|
| 123 | 555-861-2025 |
| 123 | 192-122-1111 |
| 789 | 555-808-9633 |
| 456 | (555) 403-1659 Ext. 53 |
| 456 | 182-929-2929 |
* **2nd normal form** : The table is in the first normal form and all the non-key columns depend on the table's primary key. This narrows the table's purpose.
##### Example
A design that violates the 2nd normal form. The model full name being the primary key, there are other candidate keys like {manufacturer, model}. The "Manufacturer Country" column is dependant on a non-key column (the Manufacturer).
| Manufacturer | Model | Model Full Name | Manufacturer Country |
|---------------------|--------------|----------------------|----------------------|
| Forte | X-Prime | Forte X-Prime | Italy |
| Forte | Ultraclean | Forte Ultraclean | Italy |
| Dent-o-Fresh | EZbrush | Dent-o-Fresh EZbrush | USA |
| Kobayashi | ST-60 | Kobayashi ST-60 | Japan |
| Hoch | Toothmaster | Hoch Toothmaster | Germany |
| Hoch | X-Prime | Hoch X-Prime | Germany |
The normalized design would be to split into two tables like the following:
| Manufacturer | Manufacturer Country |
|---------------------|----------------------|
| Forte | Italy |
| Dent-o-Fresh | USA |
| Kobayashi | Japan |
| Hoch | Germany |
| Manufacturer | Model | Model Full Name |
|---------------------|--------------|----------------------|
| Forte | X-Prime | Forte X-Prime |
| Forte | Ultraclean | Forte Ultraclean |
| Dent-o-Fresh | EZbrush | Dent-o-Fresh EZbrush |
| Kobayashi | ST-60 | Kobayashi ST-60 |
| Hoch | Toothmaster | Hoch Toothmaster |
| Hoch | X-Prime | Hoch X-Prime |
* **3rd normal form** : The table is in second normal form and all of its columns are not transitively dependent on the primary key.
A column is said to be dependant on an another column if it can be derived from it, for example, the age can be derived from the birthday. Transitivity means this dependance might involve other columns. for example, if we consider three columns `PersonID BodyMassIndex IsOverweight` , the column 'IsOverweight' is transitively dependant on 'personID' through 'BodyMassIndex'.
##### Example
A design that violates the 3rd normal form. {Tournament, Year} is the primary key for the table and the column 'Winner Date of Birth' transitively depends on it.
| Tournament | Year | Winner | Winner Date of Birth |
|----------------------|-------------|----------------|----------------------|
| Indiana Invitational | 1998 | Al Fredrickson | 21 July 1975 |
| Cleveland Open | 1999 | Bob Albertson | 28 September 1968 |
| Des Moines Masters | 1999 | Al Fredrickson | 21 July 1975 |
| Indiana Invitational | 1999 | Chip Masterson | 14 March 1977 |
A design compliant with the 3rd normal form would be :
| Tournament | Year | Winner |
|----------------------|-------------|----------------|
| Indiana Invitational | 1998 | Al Fredrickson |
| Cleveland Open | 1999 | Bob Albertson |
| Des Moines Masters | 1999 | Al Fredrickson |
| Indiana Invitational | 1999 | Chip Masterson |
| Winner | Date of Birth |
|----------------|-------------------|
| Chip Masterson | 14 March 1977 |
| Al Fredrickson | 21 July 1975 |
| Bob Albertson | 28 September 1968 |
#### More Information:
* database normalisation on <a href='https://en.wikipedia.org/wiki/Database_normalization' target='_blank' rel='nofollow'>wikipedia</a>
* first normal form on <a href='https://en.wikipedia.org/wiki/First_normal_form' target='_blank' rel='nofollow'>wikipedia</a>
* second normal form on <a href='https://en.wikipedia.org/wiki/Second_normal_form' target='_blank' rel='nofollow'>wikipedia</a>
* third normal form on <a href='https://en.wikipedia.org/wiki/Third_normal_form' target='_blank' rel='nofollow'>wikipedia</a>

73
guide/english/computer-science/databases/relational-databases/index.md Normal file
View File

@@ -0,0 +1,73 @@
---
title: Relational Databases
---
As a database is a way to store data, relational-databases are a model for how the data is being stored. The data is organized into tables, also known as relations. The tables contain a record for each instance of the data, known as records or tuples. Unique identifiers identify each record to describe it across the database.
## Tables
Like the a sheet in excel, tables are made up of columns and rows. Each row is an instance of data with attributes in the column of the table know as fields. There can be several tables for each category for entities. An example could be a table of users. Each row would be a user and each field would be details on the user like email, password, and contact details for that specific user. In Figure 1 you can see diagram of the example.
|             | user       | email     | Telephone                            |
|-------------|------------|------------------|--------------------------------------|
| row 1       | Jerry     | j@j.uk.za       | 771447444121           |
| row 2 | Sally | batgirl@gh.co.za | 771447444121 |
| row 3 | Alex | samwis@tty.fe | 771447444121 |
| row 4 | Doug | 4sure@dam.us | 745151515152 |
Figure 1 - Example of user table.
## Records
A record is a single entity of data. As in the example above, it could be a user, an account, a device, or anything that data can represent. Records do need a unique identifier, sometimes referred to as a key. This key must be unique as it is used to describe relationships a record has with other records in other tables. In Figure 1, we could add keys to each row that identifies each user with a key and the table would now look like Figure 2.
| KEY   | user       | email           | Telephone                          |
|-----------|------------|------------------|--------------------------------------|
| u1       | Jerry     | j@j.uk.za       | 771447444121           |
| u2 | Sally | batgirl@gh.co.za | 771447444121 |
| u3 | Alex | samwis@tty.fe | 771447444121 |
| u4 | Doug | 4sure@dam.us | 745151515152 |
Figure 2 - Example of user database with KEY field.
## Fields
Fields describe the record. This could hold any information on the entity that the record symbolizes. In Figure 3 you can see a table that shows pets. The columns (fields) describe each pet (record) with p\_name, p\_age, p\_type and p\_owner. The p is shorthand for pet and the last column will be explained in the next section on relationships.
| KEY       | p\_name    | p\_age     | p\_owner   |
|-----------|------------|------------------|---------------|
| p1       | Suzy     | j@j.uk.za       | u1 |
| p2 | Little Dip | batgirl@gh.co.za | u1 |
| p3       | Amillë     | samwis@tty.fe  | u2 |
| p4 | Doug | 4sure@dam.us | u3 |
Figure 3 - Example of Pet table.
## Relationships
Relational-databases allow you to describe the relationships entities have with each other. This is sometimes the most difficult topic of relational databases to understand. If we take our example tables we should be able to see the relationship our user table has with the pet table. If you read the p\_owner field you can see it could be also be as in Figure 4. This explains the relation each pet has with a user. Relationship could have different types.
| KEY       | p\_name   | p\_age     | p\_owner   |
|-----------|------------|------------------|---------------|
| p1       | Suzy     | j@j.uk.za       | Jerry |
| p2 | Little Dip | batgirl@gh.co.za | Jerry |
| p3       | Amillë     | samwis@tty.fe  | Sally |
| p4 | Doug | 4sure@dam.us | Doug |
Figure 4 - Example of Pet table with owner field linked.
A one-to-many relationship is one record linked to many other records, the example being the user Jerry having two pets. It could also be a many-to-many relationship where the tables could be books and authors, as authors could co-write many books. Finally the most common relationship type is one-to-one, a record that can only be linked to one, and only one, other record.
## Conclusion
This is just a brief intro into relational-databases. Below links are provided to resources that could help you further study the subject.
#### More Information:
* Relational databases on <a href='https://en.wikipedia.org/wiki/Relational_database' target='_blank' rel='nofollow'>wikipedia</a>
* One-to-many on <a href='https://en.wikipedia.org/wiki/One-to-many_(data_model' target='_blank' rel='nofollow'>wikipedia</a>)
* Many-to-many on <a href='https://en.wikipedia.org/wiki/Many-to-many_(data_model' target='_blank' rel='nofollow'>wikipedia</a>)
* One-to-one on <a href='https://en.wikipedia.org/wiki/One-to-one_(data_model' target='_blank' rel='nofollow'>wikipedia</a>)
* Relationship model on <a href='https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model' target='_blank' rel='nofollow'>wikipedia</a>