Models of Database Management Systems (DBMS)

Start Your Free Trial To Continue Watching
As a member, you'll also get unlimited access to over 8,500 lessons in math, English, science, history, and more. Plus, get practice tests, quizzes, and personalized coaching to help you succeed.
Free 5-day trial
It only takes a minute. You can cancel at any time.
Already registered? Login here for access.
Start your free trial to take this quiz
As a premium member, you can take this quiz and also access over 8,500 fun and engaging lessons in math, English, science, history, and more. Get access today with a FREE trial!
Free 5-day trial
It only takes a minute to get started. You can cancel at any time.
Already registered? Login here for access.
  1. 0:43 Flat File
  2. 1:53 Hierarchical DBMS
  3. 3:28 Network DBMS
  4. 4:55 Relational DBMS
  5. 7:03 Object-Oriented DBMS
  6. 9:04 Lesson Summary
Show Timeline
Taught by

Paul Zandbergen

Paul has a PhD from the University of British Columbia and has taught Geographic Information Systems, statistics and computer programming for 15 years.

Get to know the different models of database management systems and learn how each one is used to systematically organize large amounts of data in a logical manner.

DBMS Models

There are a number of different types of database management systems (DBMS), also referred to as DBMS models. Each one represents a somewhat different approach to organizing data in a systematic manner. They include:

Flat file

Hierarchical DBMS

Network DBMS

Relational DBMS

Object-oriented DBMS

Of these five models, the relational DBMS is by far the most widely used, but a quick overview of each model is useful.

Flat File

The most basic way to organize data is as a flat file. You can think of this as a single table with a large number of records and fields. Everything you need is stored in this table, or flat file.

Think of a database of customers. Everything you want to know about the customers is stored in this one table. You start off with a single record for every customer. A customer places an order and you enter this in one of the fields. You continue entering customer orders in this way.

What if the same customer places a second order? Do you enter this as a new record in the table, or do you add a field to the existing record for this customer?

There is no single best answer for this. The key point here is that a flat file is quite limited since it provides very little in terms of structure. In fact, it is so simple that you could argue it is not a DBMS at all. However, it is good to start off with the idea of a flat file, and then you will see how alternative models are more flexible and effective.

Hierarchical DBMS

In a hierarchical DBMS one data item is subordinate to another one. This is called a parent-child relationship. The hierarchical data model organizes data in a tree-like structure.

One of the rules of a hierarchical database is that a parent can have multiple children, but a child can only have one parent. For example, think of an online store that sells many different products. The entire product catalog would be the parent, and the various types of products, such as books, electronics, etc., would be the children. Each type of product can have its own children categories. For example, books could be broken up into fiction and non-fiction. Each of these categories can be broken up into subcategories. You can continue like this by listing individual authors and then the individual book titles.

This is a rather simple way to represent data, but it is very efficient. This model works best for data that is inherently hierarchical in nature. Many datasets cannot easily be organized in this manner and require a more complex approach. For example, in the case of the product catalog, what if a book falls into more than one category? Or what if one author has written several books but also published an audio CD of one of her books? This is where the hierarchical model breaks down.

Network DBMS

In a network DBMS every data item can be related to many others ones. The database structure is like a graph. This is similar to the hierarchical model and also provides a tree-like structure. However, a child is allowed to have more than one parent. In the example of the product catalog, a book could fall into more than one category. The structure of a network database becomes more like a cobweb of connected elements.

For example, consider an organization with an employee database. For each employee there are different pieces of data, such as their name, address, telephone number, social security number and job function. Different units in the organization need different levels of access. For example, the human resources department needs to have access to the social security information for each employee so they can take care of tax deductions and set up benefits. This is somewhat sensitive information, so other departments do not need access to this part of the database. All the pieces of data are connected in a network that implements these rules.

While conceptually relatively simple, this database structure can quickly become very complicated.

Relational DBMS

In a relational DBMS all data are organized in the form of tables. This DBMS model emerged in the 1970s and has become by far the most widely used type of DBMS. Most of the DBMS software developed over the past few decades uses this model. In a table, each row represents a record, also referred to as an entity. Each column represents a field, also referred to as an attribute of the entity.

A relational DBMS uses multiple tables to organize the data. Relationships are used to link the various tables together. Relationships are created using a field that uniquely identifies each record. For example, for a table of books, you could use the ISBN number since there are no two books with the same ISBN. For a table of authors, you would create a unique Author ID to identify each individual author.

Consider a relational database of books and authors. The first table is a table of authors. Each author is identified by a unique author ID, and the table also contains their name and contact information. The second table is a table of books. Each book is identified by its ISBN number, and the table also contains the book's title, the publisher and the author ID associated with the author of the book.

What makes a relational database so effective is that you can link these tables together. In this example you would use the author ID field to do this. For example, you can store multiple books written by the same author or multiple authors for the same book. The detailed information for each author and each book is only stored once and not duplicated in both tables. Yet all the information you need can be accessed using the table relationship.

Unlock Content Over 8,500 lessons in all major subjects

Get FREE access for 5 days,
just create an account.

Start a FREE trial

No obligation, cancel anytime.

Want to learn more?

Select a subject to preview related courses:

People are saying…

"This just saved me about $2,000 and 1 year of my life." — Student

"I learned in 20 minutes what it took 3 months to learn in class." — Student

See more testimonials

Did you like this?
Yes No

Thanks for your feedback!

What didn't you like?

What didn't you like?

Next Video
Create your Account

Sign up now for your account. Get unlimited access to 8,500 lessons in math, English, science, history, and more.

Meet Our Instructors

Meet all 53 of our instructors