Difficult data management

As the content increases, managing the data in a flat database becomes extremely
difficult. For example:

 If you want to change the publisher’s contact information, it would require you
to make changes in every row that contains that data. Missing even one row
in this Find and Replace task would produce an inconsistency in the database
table.
 Storing information just for publishers is also a nuisance. Inserting just data
related to the publisher would create rows with empty fields, which is
considered extremely bad practice when designing a database.
 Deleting all books by a publisher will delete the information about the
publisher as well. At a later date, if you get a book by the same publisher, the
data will have to be entered all over again.
Note: The process of managing errors and inconsistencies in databases is referred to as
referential integrity. It is a type of data integrity that ensures that the relationships between
tables are sound and that the records in the tables are synchronized whenever data is entered
into, updated in, or deleted from either table.

The Hierarchical Database Model

In this model data is structured hierarchically and is typically diagrammed as an
inverted tree. A single table in the database acts as the "root" of the inverted tree
and other tables act as the branches flowing from the root.

Figure 1.1. Diagram of a typical hierarchical database.

In the example above you need to model the processes where agents book
entertainers for clients. The agent can book several entertainers, and each
entertainer has his own schedule. An agent also maintains a number of clients
whose entertainment needs are met by the agent. A client books engagements
through the agent and makes payments to the agent for his services.
The database in the hierarchical model is presented with several tables.
Relationships exist between the tables and they are represented by the term
parent/child. In this type of relationship, a parent table can be associated with one
or more child tables, but a single child table can be associated with only one parent
table. These tables are explicitly linked via a pointer or by the physical arrangement
of the records within the tables. A user accesses data within this model by starting at
the root table and working down through the tree to the target data. This access
method requires the user to be very familiar with the structure of the database.
One advantage to using a hierarchical database is that a user can retrieve data very
quickly because there are explicit links between the table structures. Another
advantage is the improved data management; referential integrity is built in and
automatically enforced. This ensures that a record in a child table must be linked to
an existing record in a parent table, and that a record deleted in the parent table will
cause all associated records in the child table to be deleted as well.
A problem occurs in a hierarchical database when you need to store a record in a
child table that is currently unrelated to any record in a parent table. You cannot
enter a new entertainer in the ENTERTAINERS table until the entertainer is assigned
to an agent in the AGENTS table. Recall that a record in a child table (in this case,
ENTERTAINERS) must be related to a record in the parent table (AGENTS). Yet in
real life, entertainers commonly sign up with the agency well before they are
assigned to specific agents.
Also this type of database cannot support complex relationships, and there is often a
problem with redundant data. For example, there is a many-to-many relationship
between clients and entertainers; an entertainer will perform for many clients, and a
client will hire many entertainers. You can't directly model this type of relationship in
a hierarchical database, so you'll have to introduce redundant data into both the
SCHEDULE and ENGAGEMENTS tables.

The Network Database Model

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. This evolved relationship is called
owner/member and the tables are referred to as nodes. Multiple owner tables for
each member allow for many-to-many relationships, in addition to one-to-many
relationships. In the example bellow 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. Thus, many employees
have many tasks, and visa versa. You can also see how the managers can be part
of both departments and companies. In other words, the network model is taking into
account that not only does each department within a company have a manager, but
also that each company has an overall manager. Additionally, a record in the
member table cannot exist without being related to an existing record in the owner
table.
 Figure 1.2. Diagram of a typical network database.

A network database's main disadvantage is that a user has to be very familiar with
the structure of the database in order to work through the relationships. Another
disadvantage is that it is not easy to change the database structure without affecting
the application programs that interact with it.
Although the network database was clearly a step up from the hierarchical database,
a few people in the database community believed that there must be a better way to
manage and maintain large amounts of data. As each data model emerged, users
found that they could ask more complex questions, thereby increasing the demands
made upon the database. And so, we come to the relational database model.