Database Lesson #1 of 8 - Introduction to
Finally,
Databases
Welcome, everyone. This is Dr. Soper And
today we
will be going through our first lecture for our
database class.
I need to operate under the assumption that
not everyone in the class has had experience
with databases in the past.
And so this first lecture is intended to bring
everyone up to the same basic level of
understanding
with respect to several important database
concepts. We have several different
objectives,
which we will seek to achieve in this lecture.
These are listed on the screen right now.
First, we want to try to understand why
storing data in a list is not necessarily
a very good idea. It can cause many different
types of problems.
Second, we want to see if we can gain some
insight into why an organization might want to
use a database.
Third, we will see how the notion of related
tables of data, which forms a core part of the
relational database
model, provides a basis for eliminating many
of the problems which are associated with
storing data
in a list. We'll also explore the various
components and elements that comprise a
database or a database system.
And we will learn about the purpose of
something that we call a DBMS, a database
management system.
And along the way, we're going to explore
some of the functions that a robust database
application can provide to us. What, then, is
the purpose of a database?
Well, it's important to remember that a
database does not have just a single
purpose.
Instead, there are several key advantages
that databases provide. First, a database
provides a repository for storing data.
That's kind of implicit in the name. Database
implies that we have a place to store data.
However, what might not be so obvious is
that databases provide an organizational
structure
for data. That is, we don't just have a place to
store data, but the database also provides an
organized structure
into which those data can be placed.
a database provides us with a mechanism
for interacting with our data. Now, interacting
with data can generally
be described in four different operations.
Here they're listed as querying, creating,
modifying,
and deleting data. But there's another more
interesting acronym, which may help you to
remember this.
And that acronym is CRUD, C-R-U-D. This
stands for create, read, update, and delete.
These are the four basic operations that we
can use when interacting with data.
A key point to remember here is that, in
business, there are many natural, hierarchical
relationships among data.
For example, a customer can place many
orders. Another way of saying that is many
different orders
can be associated with the same customer.
Or another example is a department
can have many different employees, but a
given employee might work in one, and only
one, department. So these are hierarchical
relationships among the data.
And a relational database allows us to model
and represent these relationships.
Let's take a look at a list of data. What I mean
by a list here is a simple, two-dimensional
table
of data. And in this table, we store information
that is important to us for some reason.
An example might be, say that we have many
different projects in our company, and we
want to keep track of who the project
manager is for each project. Therefore, for
each project, we may
track the project manager's name, their ID
number,
and maybe their phone extension within our
company. Now, ordinarily this wouldn't be
such a big problem.
But imagine if the same person, the same
project manager, is simultaneously managing
multiple projects.
In that case, using a simple list, the project
manager's information
would necessarily appear on the list multiple
times. Now, what is the problem with this?
Well, there isn't really any major problem,
aside from the fact that it's redundant.
Another way of saying that is we are using
more space than is necessary to record
which project manager is
associated with which projects. Another
problem with storing data in a list
is that the list of data may contain more than
one concept
or more than one theme. I want you to
remember this idea of a business concept,
because we will see it again and again
throughout our course. A business theme or
concept refers
to a number of different attributes or
properties
that are all naturally related to one type of
business entity.
An example might be an employee. An
employee is a business concept.
Employees have different attributes that we
may want to track for each employee
in our organization. For example, we may
want to track the employee's ID
number, the employee's name, the
employee's salary.
Other examples of business concepts or
business themes include things like
departments, products, customers, orders,
locations, and so forth. Returning to lists, a
major problem
is with these multiple themes. That is, for
each row of the list,
we might be recording information about
more than one of these business concepts.
As an example, consider our list of project
managers. If we also wanted to include
project information-- that
is, perhaps, a project name, a project ID, any
additional information about the project--
we might store that in the same row along
with the project manager.
Aside from redundancy, as I mentioned
earlier, the problem here is not necessarily
how we are storing this information, but what
might happen to the information
if it is stored in this way. When we store
information in a list, we introduce the
possibility of something
called data anomalies. And specifically, there
are three types of these anomalies.
Here they're listed as a deletion problem, an
update problem, and an insertion problem.
Later in our course, we will refer to these as
deletion anomalies, update anomalies,
and insertion anomalies. So the structure of a
list and its associated problems
of redundancy and multiple themes can
produce a situation in which these
modification problems
potentially could occur. So let's take a look at
some of these modification issues.
Here we have a list of data, which contains
information on students.
So we have a student's last name, first name,
their email address. And then we see who
that student's advisor is.
So the last name of the student's advisor, the
email of the student's advisor,
and the department in which they work, along
with some additional information.
Let's take a look at how some of these
modification anomalies might emerge.
In the first case, imagine that we want to
change a student's advisor. And for this
example, we're going
to change Advisor Baker to Advisor [?
Tiang. ?] When we do this, not only are we
going
to have to update the last name of the advisor
in the list, but to maintain the overall quality of
the data, a concept
that we call data integrity, we are going to
have to also update the advisor's email
address.
Note, in this case, that we do not need to
update the department or the administrator's
last name,
because those are the same for advisors [?
Tiang ?] and Baker. However, if, for some
reason, we wanted
to change the student's advisor from, say,
Baker to Valdez,
well, now not only do we need to update the
last name and the email address,
but we also need to update the department
and the admin last name attributes as well.
Just to do something as simple as changing
the student's advisor with this list approach
requires
that four separate pieces of information be
updated. So this is what we might call an
update anomaly or an update
problem. Next, let's look at a deletion
problem.
Imagine that our student, listed here as Chip
Marino,
decides to drop out of the university. So we
need to remove Chip from our list of students.
Now, look what happens if we delete this row
of data. When the row of data is deleted, not
only
do we lose the student's information, but
we've also lost information about the advisor
and the department in which that advisor
works. That is, you will notice that Advisor [?
Tran ?] is not
currently assigned to advise any other
students. So when we delete this row of data,
we may entirely lose the knowledge that
Advisor [? Tran ?] even exists.
And that can be a problem. In this case, this
is called a deletion problem or a deletion
anomaly. Finally, let's look at an insertion
anomaly.
Let's say that at our university, we decide that
we want to add a new department.
So we create a biology department. Well, this
is fine. We add information to our list.
We now have a biology department and an
administrator's last name.
However, we now have all of this missing
data in our table. There are empty cells.
There's no information for a student. There's
no information for an advisor. All we have
here is information for the department.
This means that data are missing, and we're
not efficiently utilizing our available storage
space. These are some of the problems with
these lists. Now, remember, earlier I
mentioned
that in the business world there are complex
relationships
among different types of data. For example, a
department may have many employees
who work in that department. Or a product
may be assembled from many different
components.
Or a customer might place many different
orders with our company.
So there are these natural complexities that
arise in business.
And relational databases, as we will see, not
only solve
the problems that are associated with lists,
but also allow us to model these natural
relationships
among business data. Now, I've been using
this term relational database.
So it would probably be a good idea for us to
consider what a relational database actually
is.
On a very basic level, relational databases
store data in a table.
Now, a table is simply a two-dimensional grid
of data that contains columns, and it contains
rows.
The convention in the relational database
world is that the columns represent different
attributes
of an entity. And each row in the table
represents
an instance of the entity. So for example, if I
have an employee table
with an employee ID, an employee name,
and an employee telephone
number, we would list those three attributes--
ID, name, and telephone number-- as
columns in the table.
And then each row in the table would
represent an individual employee.
Again, we said that there are these natural
relationships among different business
concepts
out there in the business world. In a relational
database, data for each of these concepts
is stored in its own table. So I may have an
employee table.
I may have a department table. And then I
can create a relationship
between those tables, which will allow me to
figure out which employees work in which
departments.
So a good way of thinking about this is
instead of storing all of the information in one
big list,
we break the list apart into separate pieces
according to which information is
associated with which business theme or
business concept.
Therefore, all of the information associated
with an employee might go into an employee
table.
And all of the information associated with a
department might go into a department table.
Although, inside a relational database,
information about different business concepts
or business
themes is stored in separate tables, it may be
necessary-- say, for reporting purposes-- for
us
to reassemble all of the data from these
different tables
back into a list. Now, we can accomplish this
in the relational database world
by performing something called a join
operation. That is, we join the tables together.
Now, a very, very important concept for you
to understand
is that in the relational database world, we
link the records in different tables
together using matched pairs of values.
These matched pairs of values allow us to
associate a row in one table
with one or more rows in another table. For
example, if we have a project table
and we have a customer table, and we use
an attribute called a customer ID
to uniquely identify each customer, then what
we can do
is we can place a customer ID attribute in the
project table.
And we can then use the ID of the customer
in each table to link related rows together.
Now, of course, you may be listening to this,
and you may think, why do we want to do all
of this extra work?
And it is true that relational databases are
more complicated
than storing data in a list. However, as we will
see, relational databases
have many, many advantages over a list.
Among these, first, a relational database
minimizes data redundancy. In the examples
we saw earlier, we
saw that there exists with lists the possibility
to have all sorts of redundant data.
Relational databases eliminate this.
Relational databases also allow us
to model the natural relationships that exist
among business concepts in the real world.
And there are several other advantages as
well, including providing a solid basis from
which to do things like generate reports
or build user interface forms. I mentioned a
few minutes ago that there
are four basic ways of interacting with data--
create,
read, update, and delete. In the relational
database world,
we have access to something called the
Structured Query Language, often called
SQL, or SEQUEL, if you like.
And this is the primary tool that we can use
for performing these four
basic operations on our data. In a few weeks,
we will begin learning the Structured Query
Language. This is an extremely valuable skill
for you to develop.
If you are able to learn the Structured Query
Language well, then you will be able to sit
down and work
with virtually any modern database with a
very, very
short learning curve. It doesn't matter if you
need to work with a SQL Server
database, or an Access database, or an
Oracle database, or a DB2, or a MySQL
database, or even a database
for, say, a mobile device. Most databases,
including all of those that I mentioned,
support the Structured Query Language. So if
you can learn the Structured Query
Language,
you will be very well positioned to work with
almost any database.
Even though we're still early in our course, I
want to give you an example of the
Structured Query Language
now so that you can see that it's really not
that difficult to understand.
This is certainly not a full scale computer
programming language.
The Structured Query Language was
designed from the ground up to be simple to
use and to be simple to understand.
So what we have here is an example
where we have three tables. There is a
customer table, and a course table,
and an enrollment table. So let's say that
these are art courses.
We have customers who have signed up to
take different art
courses to see, perhaps, if they can learn to
paint or they can learn to sculpt.
Now, although we start with three tables, if
we need to combine all of the information
together in order to restore the original list
structure of the data, we can do that
by using something called a SQL SELECT
statement. Here we see an example of such
a statement.
I know this looks complicated. But hopefully,
you are able to read this even right now
at the beginning of our course and get a good
idea for what this statement is supposed to
do.
So let's take a look. We are selecting the
customer's last name, the customer's
first name, the customer's phone number,
and the date of the art
course, the amount paid out of the enrollment
table,
the course itself, and the total course fee from
our three different tables--
customer, enrollment, and course. We are
then linking the related records in each table
together
using these matched pairs of values that I
mentioned earlier. In the first case, we are
linking the customer table
to the enrollment table using matched pairs of
customer
numbers. And in the second case, we're
linking the course table
to the enrollment table using matched pairs of
course numbers. What this will do for us is
restore
the original list of data. So you can see our
list. It contains the customer's last name and
first name,
customer's phone number, the course date,
the amount that the customer has paid so far,
the course they are taking, and the total
course fee. Now, the SQL statement that we
saw was a SELECT statement.
And that is a statement which just pulls data
from the database.
There are many other things that we can do
with SQL, like deleting data, inserting new
data,
updating data in the database, and so forth.
And we will learn how to do all of those
various tasks
when we study the Structured Query
Language in more depth in a few weeks.
Now I would like to turn our attention to some
conceptual information.
Let's focus on a database system. It's
important to remember that a database
system is not
just the database itself. Rather, it exists in a
broader hierarchy, which
includes users, application software programs
which
rely on the database, something called a
database management system, a DBMS, and
then, of course, the database itself.
The broader picture of a database system
includes these four components.
Here we see the relationships between the
four components of a database system.
On the far left, we see users. Now, users are
people, just like you
or me, who might need to use the data in a
database. But a user doesn't necessarily
have to be a human being.
It is possible, for example, for other software
programs
to be users of our database as well. Now, you
will see that users interact
with database applications. These are the
programs that rely on the database.
So if we are a human user, we might, for
example, use a website, which interacts with
a database.
That website could be considered a database
application. You will notice that the database
application
talks to the DBMS. The DBMS, the database
management system,
acts as a gatekeeper. All of the information
flowing in or out of the database
must travel through the DBMS. It is a critical
mechanism for maintaining the quality
of the data in the database. We do not allow
our users or our database applications
to directly access the data in the database.
To work with the data, to access those data,
database applications must go through the
database management
system. And then, finally, far over on the right
side of our screen,
we see the database itself. And this is where
we actually store the raw data
in their separate tables. So what do the users
of a database system do?
Well, they do many different things. You and I
are users of database systems on almost a
daily basis, even if we don't realize it.
So we can look up our checking account
balances online.
We can produce reports. We can seek
information on Wikipedia.
All of these are examples of us as users
interacting with database applications.
A few interesting things to note about the
database itself is that it is a self-describing
collection
of related records. What this means is that
the database does not just
contain the data, but it also contains a
definition of its own structure.
Databases also contain metadata. The
simplest way to understand metadata
is that metadata are data which describe
other data.
And in the context of the database world,
metadata are data which describe the
structure
of the data in the database. So for example, I
may say that an employee table contains
an attribute called Employee ID, and that ID
value is
an integer. That knowledge that the
Employee ID value is an integer
is metadata. And of course, databases allow
us to establish
relationships between tables. So that means
the tables within a database
are related to each other according to the
relationships that we establish.
So it's important to remember that a database
does not just contain the data that we have
put into it.
A database also contains metadata, which
describe our data.
It contains, or potentially can contain, what
we might refer to as overhead data.
These are tables of data that are used to
improve performance or track
the status of the database or how users are
interacting with the database.
And one of the major types of these overhead
data are called indexes.
Later in our course, we will examine database
indexes. And of course, databases can also
contain application metadata. So these are
data values that are
used by the applications which rely upon the
database.
An application, for example, might store user
preferences in the database.
Now, to reiterate, a DBMS, or a database
management system,
serves as a gatekeeper or an intermediary
between the database and the applications
which rely upon that database. The purpose
of the DBMS is to control and manage
the operations of the database. The DBMS is
a special kind of software program, which
is used to not only create databases, but also
to process and administer those databases.
So a DBMS is a type of application program.
But it is not the database.
The DBMS interacts with the database, but it
itself is not the database.
What, then, can a database management
system do for us? Well, the answer is it can
do many different things,
as we see here on your screen. We can use
the DBMS to create a new database.
And then, within that database, we can create
tables and establish relationships between
tables.
We can read, write, edit, and delete data
using the DBMS.
We can establish rules which regulate and
control the data in the database.
The DBMS provides an additional layer of
security for us. And it also provides
mechanisms through which
we can backup our data and recover our data
if anything
ever goes wrong. So the DBMS is a very
critical piece of software.
Now, businesses often operate with many
different types of business rules or
constraints.
And one of the great things about working
with databases is that the DBMS can
establish and enforce
many different types of constraints. One of
the most useful types of constraint
that a DBMS can enforce is called a
referential integrity constraint.
The purpose of a referential integrity
constraint is to ensure that values that we are
entering in one table
have matching values in another table. Now,
that's a very abstract way of trying
to convey a simple concept. As an example,
imagine that we have a customer
table and a project table. And we are trying to
enter information
about a new project in the project table. And
we specify that the customer ID
that is associated with this project is customer
number 5.
Referential integrity means that the database
will actually check in the customer table to
see
if customer number 5 exists. If customer
number 5 does not exist,
then the database will not allow us to add that
customer ID to our project table.
And in this way, I hope you can see it helps to
maintain the quality of the data
in the database, what we call data integrity.
Now, the fourth component of our database
system were database applications.
And database applications are simply those
software programs that need to use or work
with data in the database. So these might be
data driven websites.
They might be mobile apps. They might be
desktop applications or productivity software.
Just remember that these applications are not
allowed to talk to or use the database directly.
But rather, they must go through the DBMS to
work with or use those data.
Finally, for this lecture, I want to just talk
about some
of the different types of database systems
that are available. First, we can consider
something called a personal database
system. These are very small databases.
They are typically used by a single user at a
time.
They are not complicated. They are simple in
design. And they're not really suitable for
supporting
medium or large businesses. They might be
used by very small businesses just out
of convenience. But as those companies
grow, they will, at some point,
certainly need to choose a more robust
database solution.
An example of a personal database system
might be Microsoft Access.
Convenient, easy to use, but not very
powerful.
One of the interesting characteristics of
personal database systems is that they often
contain the capability to build a database
application, or at least interfaces to the
database
within the DBMS. So in Microsoft Access, for
example,
I can create data entry forms or generate
reports for my Microsoft Access database.
That is, it kind of combines the database
application and the database management
system into a single entity,
conceptually speaking. On the other hand, we
have a class of database systems
that are called Enterprise-Level database
systems. These are databases that are used
by medium and large size
companies to support their operations. And it
is Enterprise-Level databases
that we will learn to use and interact with in
this class.
Compared to personal database systems,
Enterprise-Level databases are designed
to support many different users at the same
time. And this could be thousands or tens of
thousands of users
all at the same time. Enterprise-Level
databases also serve data
to more than one application. For example, if
we are a retailer like Target
or Walmart, we may have a database that
provides data to our website
and also provides data to the dashboards that
are used by our managers.
Enterprise-Level databases are commonly
spread across multiple physical computing
devices.
So many different computers. So a single
database might be running on many physical
servers.
Enterprise-Level databases can also be
geographically distributed.
So I might have part of my database in my
corporate offices in Los Angeles,
another part in Beijing, another part in Berlin
in Germany.
And Enterprise-Level database management
systems support more than one database.
So within the same database management
system, we might, for example, have our
operational database,
which allows us to run our business and keep
track of transactions in real time.
And we might also create a data warehouse
or data marts.
And they can all be managed by the same
Enterprise-Level database management
system.
These are large databases. As an example,
consider an ERP system like SAP.
A typical ERP implementation will have
thousands of tables, all related
to each other in some way. An Enterprise-
Level database management system
can handle this level of complexity with
relative ease.
So here we see a graphical example of these
Enterprise-Level database systems.
The DBMS, again, serves as an intermediary
or a gatekeeper between the databases
and all of the various database applications
that want to rely on the data in those
databases.
And they can be mobile applications,
applications that are written in Java, or C#,
or even web applications. It might be
ASP.NET or PHP apps.
Just as examples of some commercial DBMS
products, again, I mentioned that personal or
desktop DBMS products
might include Microsoft Access. Whereas,
Enterprise-Level products
include SQL Server, which is what we will be
using in this class, Oracle, MySQL, and DB2.
MySQL, if you're interested, is a completely
free and open
source database. Well, my friends, thus ends
our first lecture
for our database class. I hope you learned
something. And come back soon, and we'll
begin our exploration
of our next topic. Until then, have a great day.
INTRODUCTION TO DATABASE MANAGEMENT
SYSTEMS
welcome to the course of database
management
systems or in short we call it as dbms
in this video we will be seeing the
basic introduction to dbms
before dbms we were using the file
system approach
in the later videos we will see more
about file systems
and why we prefer dbms approach over the
file system approach
before we get into the topic let us see
the outlines or the topics that we are
going to cover in this video
the first one we are going to see is the
basic definitions
or the basic terminologies that we need
to know
next we'll be looking into the
definition and
functionalities of database management
system
and then we'll be discussing about the
properties of database
next we'll be briefly looking into an
illustration of a
simplified database system environment
and then finally to understand database
and its functionalities better
we'll be looking into an example of
university database
so as we discussed first we'll be
looking into the basic definitions in
relation to dbms
the first one is data data
is any raw facts or unprocessed
facts that you can record like for
example
any numbers name of a person name of a
place
any kind of text images audio video
etc all these are called as data
next what is information
these unprocessed facts or otherwise
called as
data when they are processed to make a
meaningful context
then that is called as information or in
other words i can say
it is the processed data like for
example
the age of suresh is 25. so here i take
the raw facts or the unprocessed facts
process it to make a meaningful context
and that is called as information next
let us see
what is a database database is a
collection of
related data now a random collection of
data
or data that is not related cannot be
referred to as a database
it has to be a collection of related
data
like for example the data in an
online banking system database has to be
related to that particular bank
similarly the data in library management
system database
has to be related to that particular
library so this is what we call as a
database the next one is metadata
metadata is nothing but the database
definition
or in other words i can say it is the
complete
description of a database or it defines
the database
information like the storage format or
the data
type of the data that we are going to
store in the database
or the constraints on the data all these
information is called as metadata
so these are the basic definitions we
have seen in the further videos we will
see more definitions in relation to dbms
next let us see the definition of
database management
system database management system
is a system to manage the database
and here managing could be either
storing of data
or retrieval of data from the database
now let's look into the proper
definition of database management system
database management system is a system
or it is a software or i can say it is a
collection
of programs that enables users
or that allows the users to create
and maintain the database so this is a
very simple definition
now let's move on to the functionalities
of database management system
database management system allows users
to define the database to construct
the database manipulate and
share the database now defining the
database
involves specifying the data type
for the data that we are going to store
in the database
also specifying the structures and
constraints for the data
now constraints is nothing but the
limits on the data
like for example if i have age as the
data to be stored then i can have a
constraint
say age greater than 18 so only if age
is greater than 18
then only that data can be stored in the
database
so that is what we call as a constraint
the next functionality
constructing the database is nothing but
the process of
storing data on some storage medium
or in other words i can say it is a
storage of data
so when data is stored a database is
being constructed
the next functionality manipulation of a
database
includes functions like querying the
database to retrieve
or to get any data that the user needs
it
also allows users to update the database
and for generating reports the next
functionality
sharing the database allows multiple
users and programs
to access the database concurrently
or simultaneously or in other words i
can say
many users can access or share the same
database
at the same time in an efficient manner
so these are the main functionalities
that dbms provides
the other functions provided by dbms are
protection of the database from
unauthorized access
or from hardware or software failures
and also
maintenance of the database for a long
period of time
so that is with the functionalities of
database management
system next we will be discussing the
properties
of database there are three properties
of database
the first one is a database represents
some aspects of the real world or
otherwise called as the mini world
so anything in this mini world the
objects
their properties the relationships
between them
all that is represented by a database
and if there is any change in the real
world that change will also be reflected
in the
database the second property is
a database is a logically coherent
collection
of data with some inherent meaning
so as i said earlier a random collection
of data
or unrelated data cannot be referred to
as a database
the data in the database has to be
related
or logically coherent the next property
is
a database is designed and then built
and populated with data
for a specific purpose so these are the
three main properties of database
the first one is a database represents
the real world
secondly it is a logically coherent
collection of data
and thirdly a database is designed built
and then filled with data for some
purpose
next let us look into an illustration of
database system
environment so here we have the users or
the programmer
who writes queries or programs and these
queries or programs are processed by the
dbms software
and then based on the processed queries
dbms software
accesses the stored data in the database
that is it accesses the stored database
as well as it accesses the metadata
as we have already seen metadata is the
database definition
so this is a simple illustration of a
database system
environment where users write their
queries
and it is processed by the dbms software
and based on the processed queries
dbms software accesses the store
database as well as the metadata
as we discussed in the outlines finally
to understand
a database and its functionality is
better we'll be taking an example of a
university database
that stores student and course
information
so here i have taken three tables the
first one is the student table
which holds information about the
students in that university
the second table is the course table
which holds information about the
courses available
and third table is a grade report table
which contains
information about the grades received by
each student
in a particular course as we have seen
earlier the four functionalities
provided by dbms
let us try to understand those
functionalities better with this example
as we learn defining the database
involves specifying the data type
structures and constraints for the data
that we are going to store in the
database
so here specifying the structure of each
record
means specifying the different types of
data elements present in that particular
record
so here we have three records the
student record the course record
and the grade report record and these
columns are called as data elements in
each record
now specifying a data type would be now
for example
for student name i can say the data type
should be a string of characters
or for data element role number i can
say the data
type should be an integer and so on and
we've already discussed what a
constraint is
i can give a constraint on the student
name saying that student name cannot be
null so this is all about defining the
database
the next functionality constructing the
database is nothing but
storing data so once data is being
stored a database is being constructed
the next functionality is constructing
the database which is nothing but
storage of data
so when data is stored a database is
being constructed
then we saw database manipulation as the
next functionality
which involves querying and updating the
database
examples of queries would be listing all
the students
in the cs branch in that university or
listing the grades received by a
particular student in each course
and then we saw sharing the database
where this particular database can be
shared
by many users at the same time in an
efficient manner
so this is a very simple example of a
database that i've taken
to help you understand what a database
is and also to understand its
functionalities
with this we come to the end of this
video hope you all have understood the
basic introduction to dbms.
1 DBMS CHARACTERISTICS
hello everyone
and welcome back continuing with the
previous video
introduction to dbms let us see in this
video
the characteristics of dbms
as i mentioned in the previous video
before dbms
we were using the file system approach
in traditional file systems data was
stored in
files now for example
if i have one user say the accounts
department who keeps track of the
student fees
and their dues this user just needs the
student role number student name
the fees paid by the students as well as
any dues
and if i have another user say the exam
department
who keeps track of the grades received
by the students
that is it can have student role number
student name
course and the grades received by that
student in a particular course
here both the users are interested in
data about students
but they have to maintain different
files because both have different
interests the accounts department is
only interested in the fee details
whereas the exam department is only
interested to know about the grades
received by the student in each course
so since both have different interests
they cannot have a common file and hence
have to maintain different files
as we can see here the student details
as the student role number and the
student name
is being repeated in both the files this
leads to redundancy or
duplication of data as well as wastage
of storage space
whereas in the dbms approach the entire
data is stored in a single repository
and multiple users can access the data
based on their interests like for
example
data like student role number student
name the fees paid fees
due the grades they have received etc
can be stored in the single repository
and any number of users can access this
repository
and view whatever data they want
hence there is no duplication of data
so that is why we prefer dbms over the
traditional file system approach
hope you all have understood the
difference between the file system
approach
and the dbms approach now we are going
to discuss
the main characteristics of dbms
approach
the first one is self-describing nature
of a database system the second
characteristic
is insulation between programs and data
and data abstraction the third
characteristic of dbms approach is
support of multiple views of the data
and the last characteristic that we are
going to discuss would be
sharing of data and multi-user
transaction
processing let us look into each of
these in detail
the first one self-describing nature of
a database system
a database system not only consists of a
database but it also contains the
metadata
we have already seen what a metadata is
in the previous video
so it is nothing but the database
definition or a complete description of
the
database information like the data type
and the constraints etc all these
information
is what we call as metadata and this
information
is stored in the dbms catalog
and this catalog is used by the dbms
software
as well as it is used by the database
users who wants to know
what the structure of the database is
let us just see
an example of a catalog so that you
understand better
in the previous video we have taken this
very simple example
of a university database that stores
student and course information
so based on this very simple example let
us see an example of a catalog
so here we'll see an example of a
database catalog
where relations or table name along with
the number of columns are mentioned
in our example of university database we
have three tables or three relations
the first table that we have is the
student table with four columns
then we have the course table with three
columns
and then finally the grade report table
with
three columns and also in our catalog we
can have
another table which defines the columns
present
in each table or in each relation their
data type
and to which table or to which relation
that column belongs to
based on our example of university
database the column
student name has the data type character
of size 30 and it belongs to the
relation or belongs to student table
similarly the column roll number is of
integer data type and belongs to student
relation or student table
so this is an example of a database
catalog
where information about the database or
a description of the database is stored
now going back to the characteristic
that we were discussing
now the next point is dbms software
must work equally well with any number
of
database applications we can have any
number of database applications like for
example
a university database a library database
or a banking database
as long as the database definition or
the metadata
is stored in the catalog dbms software
has to work efficiently or equally well
with any number of database applications
whereas in the traditional file
processing
data definition or what we call as
metadata in dbms
is part of the application programs
itself
so they work with only one specific
database application
because the structure is declared in the
program
itself unlike dbms they cannot work with
more than one
database application so we have seen the
very first characteristic of dbms
approach
now moving on the next characteristic of
dbms approach
is insulation between programs and data
and data abstraction in traditional file
processing the structure of data files
is
embedded in the application programs
itself that is the structure is within
the program
it is not separate so if there is any
change to the structure of data files it
is going to affect the programs we also
need to change the application
program whereas in the database approach
the structure of data files is stored in
the dbms
catalog and it is separate from the
access programs
since the structure is stored separately
from the programs
so if there is any change brought to the
structure of the data files it does not
affect the programs
and that is called as program data
independence we have already seen an
example of university database
so in that database we had a student
table or a student record
so let us see an internal storage format
for that student record
here we have the data item name or the
column name
in that record or in that table the
starting position
and the length in characters in
traditional file systems
this structure is present within the
programs itself
now say if i want to add another piece
of data say the date of birth
since the structure is changed this
program will not work
and the program has to be changed
whereas in the database approach
if you want to add a new piece of data
say the date of birth
we can add it without affecting the
programs
since the structure is separate from the
programs we don't have to change the
programs
we just have to add this new information
in the catalog
so next time a dbms program refers to
the catalog
the new structure will be referred and
used
so that is called as a program data
independence
now the characteristic that allows
program data independence
is called data abstraction dbms
provides users with conceptual
representation of data
that is it hides the behind the scene
details or the complicated details
that are not of interest to the database
user
a data model is a type of data
abstraction
that provides conceptual representation
to the database
users in a way that most users can
understand and the data model hides the
storage and implementation details from
the
users so this is what is insulation
between programs and data or what we
call as program data independence
and the characteristic that allows the
program data independence is called as
data abstraction the next characteristic
of dbms
is support of multiple views of the data
a database has many users and
each of those users will have different
needs
or they may require a different view or
a different
perspective of a database like for
example
one user will be only interested to know
the grades received by the students
while another user will be interested to
only know the courses
taken by each student so dbms will
provide only that necessary data that is
required for each
user a view which is a subset of
database
that is it is derived from a main
database table
it contains virtual data or
data that is not physically stored or
that is not
explicitly stored so that is
support of multiple views of the data
where dbms will provide
as many views as required by each
database user
the next characteristic of dbms is
sharing of data
and multi-user transaction processing
as the name suggests a multi-user dbms
allows multiple users to access the
database
at the same time now for multiple users
to
access the database at the same time
dbms has to provide or it must include
concurrency control now what is
concurrency control
concurrency control is nothing but when
multiple
users are sharing the same database at
the same time
it should prevent two users from
editing the same data at the same time
like for example we have travel agents
or
reservation agents and if one of the
agents
is booking a bus ticket for a particular
passenger
and if he is assigning a seat for that
passenger
then that particular seat should get
blocked and no
other agents should be able to access or
book that seat for any other passenger
and that is what we call as
concurrency control these kind of
applications that require concurrency
control
are called as oltp or online transaction
processing and it is a major part of
database application
dpms must enforce or must ensure
several transaction properties and here
transaction means
program under execution so the two
different transaction properties are
isolation and atomicity now what is
isolation like we already discussed in
the previous example
if one agent assigns a seat to a
particular passenger
then that seat is blocked or it is
isolated from
other agents so that is one of the
transaction properties that dbms must
enforce
the next property is atomicity where
dbms should
ensure that the transaction is executed
completely
or none at all now when an agent is
assigned a seat for a passenger
and if the transaction is stuck midway
or if it is
incomplete then that seat has to be
released for
other agents to access so either the
transaction
should be executed completely or none at
all
so this is sharing of data and
multi-user transaction
processing with this we come to the end
of this video
hope you all have understood the main
characteristics of dbms approach.
Database Users

going to see briefly the different types
of database users
based on their interaction with the
database database users are divided into
two
the first is actors on the scene actors
on the scene
are the people whose jobs involve using
large databases every day or in other
words i can say
people whose jobs involve day-to-day use
of a large
database under that we have four types
of users
the first one is the database
administrators
then we have database designers the
end users and finally system analysts
and application programmers also called
as
software engineers next we have
workers behind the scene workers behind
the scene
are the people whose work is to maintain
the database system environment
we have already seen a simple
illustration of a database system
environment in our previous video these
people
maintain the database system environment
that is they deal with the design
development and
operation of the database system
environment
and they are not interested in the
database itself
under this we have the three types of
users
the system designers and implementers
the tool developers and finally the
operators and maintenance
personnel let us look in detail the
roles and
responsibilities of each of these
database users
so first let us look at the actors on
the scene
under this the first type of database
user that we have
are the database administrators now in
any large
organization we might have many
resources and we always need a main
person or a chief person or a manager to
manage these resources
similarly in the database environment
we have database as the primary resource
and database management system that is
dbms and its related software
as a secondary resource and it is the
responsibility of a database
administrator or a dba
to administer or to manage these
resources that is the primary and the
secondary resources
the other responsibilities of a database
administrator or a dba
are they authorized access to the
database
that is they can grant any user the
permission to access the database
and the next responsibility of a dba is
coordinating and monitoring the use of
database also a dba is responsible for
acquiring or obtaining
any hardware and software resources as
needed
so these are the main responsibilities
of a database administrator
the other responsibilities would be
troubleshooting if any problem arises
or to see if there are any security
issues and so on
in a large organization a dba or a
database administrator
will have a support staff behind to help
him with his duties and responsibilities
so that's about database administrators
or a dba
and his responsibilities moving on to
the next type of database users under
actors on the scene
we have database designers
database designers are responsible for
identifying the data that we're going to
store in the database
and based on this data that we're going
to store in the database
a database designer should choose
appropriate structures
to represent and store this data and a
database designer
is also responsible for communicating
with the database
users and try to understand what their
requirements are
and based on their requirements a
database designer designs a
database now these database designers
they interact with each group of users
and develop
views for each of these group of users
based on their requirement we have
already seen what a view is in the
previous video
a view is a subset of the database
it is derived from the main database and
it only contains
data that is required by a particular
user so database designers develop
views for each group of users and then
each view
is linked with the views of other group
of users
and that final database design should
fulfill the requirements of
all the user groups and that is about
database designers and his
responsibilities now let's look on to
the next type of database user
the end users end users
are the people whose jobs require access
to the database
for querying the database to get any
data that they want
or to update the database to bring in
some changes
and for generating reports now let's
look into the categories
of end users the first one is the casual
end user a casual end user accesses
database occasionally that is they
access the database not
very frequently not very regularly or
not on a daily basis
they access the database only when they
want to query some data or if they want
to update the database
or for generating reports and usually
the middle or high level managers or the
top level managers or
other occasional browsers come under
this category
the next category of end users are the
nav or parametric
end users most of the end users
come under this category and these end
users
constantly query the data from the
database
and also updates the database for any
changes
using canned transactions now what
are canned transactions they are the
standard type of
queries and updates to query the
database for some data or to update the
database for some
changes like for example a reservation
agent for probably
airlines or hotel or train or bus
as per the request from the customer
they check the availability and make
reservations
on a daily basis they use similar set of
functions
to make reservations or to check for
availability
and so they have a predefined set of
queries or a standard type of queries
to query any data that they want or for
updating the database for some
changes the next category of end users
are the sophisticated end users
sophisticated end users
are the engineers scientists business
analyst
and any other users who are familiar
with the dbms or the database management
system
and the facilities that the dbms
provides they develop their own database
applications to meet their requirements
and then we have the standalone users
these users maintain personal databases
by using ready-made program packages
now for example a person running a
business would like to keep track of his
personal financial data
for tax purposes so for that he
maintains his
own personal databases using the
ready-made packages
and these ready-made packages would be
either menu driven or
graphic-based interface so that's all
about the
end users and the categories of end
users
the casual end users and the nav or
parametric
end users don't know in detail the dbms
facilities whereas the sophisticated end
users
are experts or know much about the dbms
facilities to
satisfy their requirements and the
standalone users are experts in the
ready-made packages that they use
now the next type of database users are
the system analysis and
application programmers or otherwise
called as a software
engineers the system analysts determine
the requirements of the end users
especially the nav users or the
parametric end users
and then develop specifications for
canned
transactions we have already seen what a
can transaction is
so a system analyst based on the
requirements of the end users
will design these standard types of
queries
and an application programmer is
responsible for testing
debugging documenting and maintaining
these scanned transactions that are
developed by the system analysts
these system analysis and application
programmers are called as software
engineers
and they have to be experts or
completely familiar with the facilities
provided by the dbms
next let us see the types of database
users under workers behind the scene
we have already seen initially that
workers behind the scene
are the people whose job is to maintain
the database system
environment and these people they are
not
interested in the database itself that
is the work behind the scene and the
types of database users under them
are the first one is system designers
and implementers
these are people who design and
implement the dbms modules
and interfaces as one software package
a dbms is a very complex software system
which consists of many modules like
modules for implementing the catalog
for processing query language for
controlling concurrency
handling recovery of data and security
etc
so the system designers and implementers
have to design
and implement all these modules and
interfaces as one software package
next we have the tool developers they
are persons who design
and implement tools which is nothing but
the software packages
and these software packages are optional
and can be purchased separately
to help improve the performance of a
database system
the next type of database user that we
have under workers behind the scene
are the operators and maintenance
personnel they are responsible for the
actual running and maintenance of the
hardware and software
of the database system environment so
these are the types of database
users under workers behind the scene and
they are involved
in making the database system available
to the end users
but they do not use the database for
their own purpose
with this we come to the end of this
video hope you have understood the
different types of database users
Data Models
Imagine that you’re designing a new home
and that a plumbing sales rep tells you that
he has a packaged plumbing design for 2
story
homes which will reduce the cost of
architecting the plumbing into your future
house.
You think to yourself, “well I’m not the first
person to build a house, and this sounds
like it might save some money.”
So you go ahead and move forward with the
idea.
So you build your house with the packaged
design and to your absolute dismay the
packaged
design is not for your house layout but just
that of a generic 2 story home!
So you have pipes going right through the
middle of your living room and other places
in the house!
Worse yet the bathroom doesn’t even get any
plumbing!
OK…
I’ve made this example as extreme and
obvious as possible.
But I’ve done that so I can introduce you to its
equivalent in the data integration
space called Packaged Data Models.
OK first let’s talk about what a data model is. The ETL, Staging, Data Model, and Reports
A data model represents the framework of are all in place and now need a major rebuild.
what the relationships are within a database. If you are going to use a packaged data
This framework in the world of data model, at the very least, you should vet it
warehousing is a critical component as it will completely
provide the structure which will support the before deploying it in your business.
analytical needs of the decision makers. Rather than thinking of the packaged data
The data itself will literally be stored within model as the end game you’re better off
this framework on a database. thinking of it as a guide while you design your
So building a data model is a critical step in own data warehouse.
the design of the data warehouse. This is because you’re likely to have a lot of
This step requires your business people to deviations from what the vendor would
engage in the process by participating in consider as “standard”.
facilitated sessions with our data architects. And it also enables you to build in your
This can seem intimidating for organizations competitive advantage above and beyond
to take on, so often organizations start your competitors
looking analytics.
for something out of the box. Intricity has extensive experience in the
But here’s the kicker that most people don’t packaged data model space.
realize. We have modified, implemented, replaced,
The amount of effort that you would take in and designed such models for years.
vetting a packaged data model to ensure that We can help you determine what the right
it fits your business; is nearly the same level approach is when implementing a data
of effort to go ahead and design one model.
specifically for your business. I recommend you visit our website and talk
However, this is an easy trap to fall into with one of our specialists.
because data models appear to do more than The small investment in our guidance can
they actually do. bring you huge dividends for the future of
Especially to business people. your project.
The first thing to understand is that a data
model is just a shell.
A Data Model without populated data isn’t
much more than a drawing.
The real expense and heavy lifting in a data
warehouse project is not in the design of
the model, but rather populating that model
with data from your source systems.
And that is where the big money is spent to
create a Data Warehouse.
Now some organizations don’t even vet
packaged data models, assuming they are
well positioned
out of the box.
But they’re usually in for a huge shock once
all the reporting and analytics go live.
They often find that the logic does not mirror
their internal practices and rules.
Additionally, they find entire dimensions not
being represented.
Like our example with the home, fixing the
problem is an expensive rip and replace
process
because the entire house around the pipes is
already built.
The same is true for a data warehouse.