A database is a tool for storing and manipulating related information efficiently and effectively. "Efficiently and effectively" means that the data is protected from accidental loss or corruption, in a manner that it doesn't use more resources than necessary, and that it can be retrieved in sensible ways within acceptable performance constraints.
To qualify as relational, the database must implement the relational model, which is a way of describing some aspect of the real world according to a set of rules. We normally use the services of a database management system (DBMS) or relational database management system (RDBMS). Relational database is the physical implementation of the relational model (the data model), and it's important to keep these two concepts distinct. A database consists of the physical files you set up on a computer when installing the database software.
The figure below shows that evolutionary process over time from around the late 1940s through and beyond the turn of the millennium, 50 years later. It is very unlikely that network and hierarchical databases are still in use.
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/7667c305-d754-4a78-be71-d87a6970f055/Untitled
The various data models that came before the relational database model were partial solutions to the never-ending problem of how to store data and how to do it efficiently. The relational database model is currently the best solution for both storage and retrieval of data.
Using a file system database model implies that no modeling techniques are applied and that the database is stored in flat files in a file system, utilizing the structure of the operating system alone. The term “flat file” is a way of describing a simple text file, containing no structure whatsoever—data is simply dumped in a file. Any searching through flat files for data has to be explicitly programmed. The advantage of the various database models is that they provide some of this programming for you. For a file system database, data can be stored in individual files or multiple files. Similar to searching through flat files, any relationships and validation between different flat files would have to be programmed and likely be of limited capability.
The hierarchical database model is an inverted tree-like structure. The tables of this model take on a child-parent relationship. Each child table has a single parent table, and each parent table can have multiple child tables. Child tables are completely dependent on parent tables; therefore, a child table can exist only if its parent table does. It follows that any entries in child tables can only exist where corresponding parent entries exist in parent tables. The result of this structure is a database model that supports one-to-many relationships.
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/ce547573-f17a-481a-a943-f3852da4e3c6/Untitled
The network database model is essentially a refinement of the hierarchical database model. The network model allows child tables to have more than one parent, thus creating a networked-like table structure. Multiple parent tables for each child allows for many-to-many relationships, in addition to one-to-many relationships. In an example network database model shown in Figure below, there is a many-to-many relationship between employees and tasks. In other words, an employee can be assigned many tasks, and a task can be assigned to many different employees. So many employees have many tasks, and vice versa.
An object database model provides a three-dimensional structure to data where any item in a database can be retrieved from any point very rapidly. Whereas the relational database model lends itself to retrieval of groups of records in two dimensions, the object database model is efficient for finding unique items. Consequently, the object database model performs poorly when retrieving more than a single item, at which the relational database model is proficient. The object database model does resolve some of the more obscure complexities of the relational database model, such as removal of the need for types and many-to-many relationship replacement tables. Figure below shows an example object database model structure equivalent of the relational database model structure shown in the previous figure. The assignment of tasks to employees is catered for using a collection inclusion in the manager, employee, and employee specialization classes. Also note that the different types of employees are catered for by using specializations of the employee class.
Another benefit of the object database model is its inherent ability to manage and cater for extremely complex applications and database models. This is because of a basic tenet of object methodology whereby highly complex elements can be broken down into their most basic parts, allowing explicit access to, as well as execution against and within those basic parts.
https://s3-us-west-2.amazonaws.com/secure.notion-static.com/24570701-10a2-44c0-8dfd-83e433c37d3e/Untitled
The object database model is somewhat spherical in nature, allowing access to unique elements anywhere within a database structure, with extremely high performance. The object database model performs extremely poorly when retrieving more than a single data item. The relational database model, on the other hand, contains records of data in tables across two dimensions. The relational database model is best suited for retrieval of groups of data, but can also be used to access unique data items fairly efficiently.
The object-relational database model was created in answer to conflicting capabilities of relational database models and object database models. Essentially, object database modeling capabilities are included in relational databases, but not the other way around. Many relational databases now allow binary object storage and limited object method coding capabilities, with varying degrees of success. The biggest issue with storage of binary objects in a relational database is that potentially large objects are stored in what is actually a small-scale structural element as a single field-record entry in a table. This is not always strictly the case because some relational databases allow storage of binary objects in separate disk files outside the table’s two-dimensional record structures.
The evolution of database modeling began with what was effectively no database model whatsoever with file system databases, evolving on to hierarchies to structure, networks to allow for special relationships, onto the relational database model allowing for unique individual element access anywhere in the database. The object database model has a specific niche function at handling high-speed application of small data items within large highly complex data sets. The object-relational model attempts to include the most readily accountable aspects of the object database model into the structure of the relational database model, with varying (and sometimes dubious) degrees of success.
The relational model is based on a collection of mathematical principles drawn primarily from set theory and predicate logic. The rules of the relational model define the way data can be represented (data structure), the way data can be protected (data integrity), and the operations that can be performed on data (data manipulation).