A database is a computer system for storing and taking care of data (any kind of information).

When the software that runs a database is separate from the programs that use the database, it is called a database engine.

Information stored inside a database is usually stored in an organized way. Data about a person that would have been written on a piece of paper before databases would be stored in a record in a database. A collection of person records that would have been an address book before databases would be stored in a file or table.

Uses for database systems

[change | change source]

Uses for database systems include:

Changing data

[change | change source]

In most databases, data can change. This also means, that in many cases, changing the data needs to be done in several steps. This is because the data is often stored in more than one tables or files that need to work together to make sense. In many cases all the steps that are needed for a given change are grouped in what is called a transaction. If something goes wrong, all the steps are undone. Being undone is another way of saying the transaction was rolled back. If all the steps are successful, they can be made a permanent part of the database. People talk about a transaction being committed. Both rollback and commit affect all the steps in a transaction.

The reason why a transaction is rolled back could be that the user or program did not want to finish the change. It could also mean that there is a problem. The database system itself might have a problem during the change. The change might break the rules of the data.

Guarantees about the data

[change | change source]

In order to be able to do this, many databases follow the ACID principle:[1]

Most relational databases follow the ACID principle. ACID is expensive, which means that it takes the system enough time and other things to do it that it that some systems might not be able to. Because it is expensive, many database systems that are not relational databases don't use the ACID principle.

CAP Theorem Venn Diagram

Around the year 2000, Eric Brewer presented what he called the CAP theorem. It is not as strong as the ACID principle, but many larger, distributed databases use it. Eric Brewer states that any distributed data store can provide only two of the following three guarantees:[2][3][4]

When they talked about the CAP theorem, people also often mentioned the term eventual consistency. It means that sooner or later, the data will be consistent, if there's enough time without writes, or errors.

Database model

[change | change source]

There are different ways how to represent the data.

Ways to organize the data

[change | change source]

Data can be looked at from different perspectives, and it can be organized in different ways.

Database Normalisation was developed to organize data. Currently there are six Normal forms. These are ways to make some databases faster and make the data take less space.

An example of database normalization is storing a person's address in one place, and linking that address to all the other records about that person. When the address is updated in the one place it is stored, all the other records will be linked to the new address automatically.

References

[change | change source]
  1. "What are the ACID properties? | Data Basecamp". 2022-07-02. Retrieved 2022-07-07.
  2. Seth Gilbert and Nancy Lynch, "Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services", ACM SIGACT News, Volume 33 Issue 2 (2002), pg. 51–59. doi:10.1145/564585.564601.
  3. "Brewer's CAP Theorem", julianbrowne.com, Retrieved 02-Mar-2010
  4. "Brewers CAP theorem on distributed systems", royans.net
  5. "What are NoSQL Databases? | Data Basecamp". 2021-12-10. Retrieved 2022-07-01.
  6. "RDBMS dominate the database market, but NoSQL systems are catching up". DB-Engines.com. 21 Nov 2013. Retrieved 24 Nov 2013.
  7. "Structured Query Language (SQL) | Data Basecamp". 2021-12-26. Retrieved 2022-07-01.
[change | change source]