Historical Development of Databases
Hierarchical Database Model
- A data model in which data is organized in a top-down, or inverted tree structure with lower level records subordinate to higher-level records
- A lower level record is called a child and a higher level record is called a parent
- Each parent record can have many child records, but each child record can have only one parent record.
- The top of the tree structure consists of a single node that does not have any parent and is called the root node or root record
- Relationships formed must be such that only one-to-many or one-to-one relationships exist between a parent and a child.
- Hierarchical databases are used for very fast, specific-purpose data storage and retrieval. They are used mainly on mainframes.
- Found in large legacy systems requiring intensive high volume transactions (TPS): banks, insurance companies
- A hierarchical database stores data according to a set and rigid design. The only way to access data is through the hierarchy – which can be very fast if you know exactly what you want the database to do.
- Hierarchical databases are constructed for specific purposes where the requirements are not expected to change.
Example: a bank that wants to record information about its customers.
The top-level records may hold information about customers.
The next level down could include records with information about accounts. For instance, a customer can have a savings account, a current account, and a loan account.
The next level down may include records that stored information about transactions in each account.
- Ease with which data can be stored and retrieved in structured, routine types of transactions.
- Ease with which data can be extracted for reporting purposes.
- Routine types of transaction processing are fast and efficient.
- Accessing or updating data is very fast because the relationships have been predefined
- Hierarchical one-to-many relationships must be specified in advance, and are not flexible. Cannot easily handle ad hoc requests for information.
- Since the structure must be defined in advance, hierarchical databases are quite rigid. There is only one parent per child and no relationships among the child records.
- Adding new fields to database records requires that the entire database be redefined.
- A great deal of redundancy because it does not handle many to many relationships
Network Database Model
- A network database is similar to a hierarchical DBMS, but each child record can have more than one parent record.
- In-network database terminology, a child record is known as a member.
- A member can be reached through more than one parent, which is called an owner.
- Basic Structure:
- Set: A relationship is called a set. Each set is composed of at least two record types: an owner (parent) record and a member (child) record.
- A set represents a 1:M relationship between the owner and the member
- More flexible than the hierarchical model because different relationships may be established between different branches of data.
- Ability to provide sophisticated logical relationships among the records
- Network many-to-many relationships must be specified in advance
- User is limited to retrieving data that can be accessed using the established links between records.
- Cannot easily handle ad hoc requests for information.
- It requires that the structure be defined in advance.
- There are limits to the number of links that can be made among records.
- Represents the database as a collection of simple two-dimensional tables called relations.
- Each individual fact or type of information i.e. entity is stored in its own table.
- The rows of a relation are referred to as tuples and the column of a relation are referred to as attributes
- All related tables must have a key field that uniquely identifies each row.
- Data in different relations is connected through the use of a key field.
- Flexible in that it can handle ad hoc information requests.
- Easy for programmers to work with.
- End-users can use this model with little effort or training.
- Easier to maintain than the hierarchical and network models.
- Entries can be easily added, deleted, or modified.
- A relational DBMS requires much more computer memory and processing time than the earlier models.
- It allows only text and numerical information to be stored in the database.
- Cannot process large amounts of business transactions as quickly and efficiently as the hierarchical and network models.
- Some searches can be time-consuming.
- Earlier data models were designed to store text-based data (which includes numbers).
- Object-oriented databases can store other types of data such as audio, video graphics, pictures that can be combined with text into a multimedia format.
- For e.g. a hierarchical or network database would contain only numeric and text data about a student – identification number, name, address, etc. By contrast, an object-oriented database might also contain the student’s photograph, a short piece of video, etc.
- Instead of tables, an object-oriented DBMS stores data in objects.
- An object can store attributes and methods.
- Attributes are data in the form of text, sound, video, and pictures.
- Methods are instructions for actions that can be performed on the object or its attributes.
- Objects can be placed in a hierarchy so that other objects lower in the hierarchy (subclass objects) can obtain (inherit) attributes from objects higher in the hierarchy (superclass objects). This is known as inheritance.
- The figure shows four objects in an object-oriented DBMS.
- The superclass object Employee provides the same set of attributes to each of the subclasses – OfficeWorker, Manager, and ProductionWorker.
- In other words, every Manager would have a name, address, salary, SS# (as would every OfficeWorker and ProductionWorker).
- Objects are divided into three parts: the object name, the attributes, and the methods.
- Can be used to store complex data types
- No Primary Keys: The user of an RDBMS has to worry about uniquely identifying tuples by their values and making sure that no two tuples have the same primary key values to avoid error conditions. In an OODBMS, the unique identification of objects is done behind the scenes via OIDs and is completely invisible to the user. Thus there is no limitation on the values that can be stored in an object.
- A query language is not necessary for accessing data from an OODBMS since interaction with the database is done by transparently accessing objects.
- Objects in an OODBMS can store an arbitrary number of atomic types as well as other objects.
- Lack of OODM standards
- Steep learning curve
- High system overhead slows transactions
- Language Dependence: An OODBMS is typically tied to a specific language via a specific Application Programming Interface (API). This means that data in an OODBMS is typically only accessible from a specific language using a specific API, which is typically not the case with an RDBMS.
- Lack of Ad-Hoc Queries: In an RDBMS, the relational nature of the data allows one to construct ad-hoc queries where new tables are created from joining existing tables then querying them. Since it is currently not possible to duplicate the semantics of joining two tables by “joining” two classes then there is a loss of flexibility with an OODBMS. Thus the queries that can be performed on the data in an OODBMS are highly dependent on the design of the system.