Management Information Systems

UNIT I
Lesson 4 Managing Data Resources
Learning Objectives

To analyse the reasons for organisations having trouble in finding their required information.
To understand the benefits of database management system in .improving the organisation of
information
To learn the various types of database models affecting the way a business can access and use
information
To know about the requirements of a database environment

4.1 Introduction
Effective use of information depends on how data are stored, organised and accessed in an
organisation. Proper delivery of information not only depends upon the capabilities of computer hardware
and software but also on the organisations ability to manage data as an important resource. After seeing the
various methods and approaches of System Development, now, let us have some understanding of how
important are the data resources in an organisation and how the information system we developed is going to
handle them.
It has been very difficult for organizations to manage their data effectively. In trying to do so, we
have to meet two very big challenges which are standing out. Implementing a database requires a widespread
organisational change in the role of information and information managers, the allocation of power al senior
levels, the ownership and sharing of information, and patterns of organisational agreement. A database
management system (DBMS) challenges the existing power arrangements in an organisation and for that
reason often generate political resistance. In a traditional file environment, each department constructed files
and programs to fulfill its specific needs. Now, with a database, files and programs must be built that take
into account the full organizations interest in data. Although the organisation has spent the money on
hardware and software for a database environment, it may not reap the benefits it should if it is unwilling to
make the requisite organisational changes.
Moving to database environment can be a costly long-term process. In addition to the cost of DBMS
Software, related hardware, and data modeling, organizations should anticipate heavy expenditure for
integrating, merging and standardizing their data that will populate their database to eliminate
inconsistencies, redundancies and errors that typically arise when overlapping data are stored and maintained
by different systems and different functional areas.
You should understand the managerial and organisational requirements as well as the technologies
for managing data as a resource. Organizations need to manage their data assets very carefully to make sure
that the data can be easily accessed and managed by the managers and employees across the organisation.
First, we describe the typical challenges facing business trying to access information using
traditional file management technologies. Then we describe the technology of database management
systems, which can overcome many of the drawbacks of traditional file management systems and provide the
firm wide integration of information required for digital firm applications.

4.2 Organizing Data in a Traditional File Environment

Information is becoming as important a business resource as money, material, and people.
Businesses are realizing the competitive advantage they can gain over their competition through useful
information, not just data.
Why should you know about organizing data? Because it's almost inevitable that some day you'll be
establishing or at least working with a database of some kind. As with anything else, understanding the lingo

11.602

Copy Right: Rai University

65

Management Information Systems

is the first step to understanding the whole concept of managing and maintaining information. It all comes
down to turning data into useful information, not just a bunch of bits and bytes.
4.2.1 File Organization Terms and Concepts

The data hierarchy in traditional file management system

The first few terms, field, record, file, database, are depicted in Figure 8.1, which shows the
relationship between them.
An entity is basically the person, place, thing, or event about which we maintain information. Each
characteristic or quality describing an entity is called an attribute. Each record requires a key field, or
unique identifier. The best example of this is your PAN Number: there is only one per person. That explains
in part why so many companies and organizations ask for your PAN Number when you do business with
them.
Suppose you decide to create a database for your newspaper delivery business. To succeed, you need
to keep accurate, useful information for each of your customers. You set up a database to maintain the
information. For each customer, you create a record. Within each record you have the following fields:
customer name, address, ID, date last paid. Smith, Jones, and Brooks are the records within a file you decide
to call Paper Delivery. The entities then are Smith, Jones, and Brooks, the people on whom you are
maintaining information. The attributes are customer name, address, ID, and date last paid. The key field in
this file is the ID number; perhaps you'll use their phone number, since it will be unique for each record. This
is a simplistic example of a database, but it should help you understand the terminology.
4.2.2 Accessing Records

11.602

Copy Right: Rai University

66

Management Information Systems

When we were describing secondary storage, we talked about magnetic tape and disk storage for
computer data. To understand how information is accessed from these mediums, think about the difference
between a music cassette tape and a music CD. If you want to get to a particular song on a cassette tape, you
must pass by all the other songs sequentially. If you want to get to a song on CD, you can go directly to that
song without worrying about any of the others. That is the difference between sequential and direct access
organization for database records.
Sequential file organization, in conjunction with magnetic tape, is typically used for processing the
same information on all records at the same time. It is also good for processing many records at once,
commonly called batch processing.
Direct or random file organization is used with magnetic disks. Because of increased speed and
improved technological methods of recording data on disks, many companies now use disks instead of tapes.
The other advantage that disks have over tapes is that disks don't physically deteriorate as fast as tapes do.
There is less danger of damaging the surface of the disks than there is of breaking a tape.
Indexed Sequential Access Method
To explain the indexed sequential access method (ISAM), let's go back to the example of the
cassette tape. A cassette tape label has a printed list of the songs contained on it which gives you a general
idea of where to go on the tape to find a particular tune. So too with computer records on a sequential access
tape using the key field. It gives the computer a pretty accurate idea of where a particular record is located.
That's why it's so a important to have a unique ID as the key field. You and your customer could have a
difficult time if the key field is duplicated among several records. Each key field and the ultimate location of
that record on the storage device is maintained in the index.
Direct file access method
This access method also uses key fields in combination with mathematical calculations to determine
the location of a record. If you order something by phone from a mail order catalog, the person taking your
order does not have to wait for the computer to randomly select your record; using the direct file access
method, the computer can find you very quickly.
Here, you van understand that the records are not stored sequentially but at random. The transform
algorithm uses the value in the key field to find the storage location and access the record.
4.2.3 Problems with the Traditional File Environment
Many problems, such as data redundancy, program-data dependence, inflexibility, poor data security,
and inability to share data among applications, have occurred with traditional file environments.
We've spoken about "islands of information" before. Building and maintaining databases is where
this situation is most evident and most troublesome. Usually it begins in all innocence, but it can quickly
grow to monstrous proportions.
For instance, after you move and change addresses, you notify everyone of your new address,
including your bank. Everything is going smoothly with your monthly statements. All of a sudden, at the end
of the year, the bank sends a Christmas card to your old address. Why? Because your new address was
changed in one database, but the bank maintains a separate database for its Christmas card list and your
address was never changed in it.
If you received two Christmas cards, you're probably a victim of data redundancy. That is, your
information is now in two separate databases with duplicate records. In this instance, each database file has
different data on the same record. That can be a nightmare on Main Street.
Even more troublesome is when several departments or individuals decide to set up their own islands
of information. This usually happens because they find the main system inflexible or it just doesn't fit their
needs. So they set up their own fields and records and files and use them in their own programs to manipulate
data according to their needs. Now each department is spending dollars and time to establish and maintain
separate islands of information.

11.602

Copy Right: Rai University

67

Management Information Systems

Even worse, the fields and records for Marketing probably don't have the same structure and
meaning as the fields and records for Accounting, or those for Production. Each record describes basically
the same entity (customers or products), but it is very possible that each database file will have different
information, or attributes, in records concerning the same entity.
All of this may have happened with the best of intentions. All the departments began with the goal of
making their part of the organization more efficient. Eventually these good intentions can cost big dollars to
bring the islands together, resolve data conflicts between them, and retrain people to understand the new
database structures.
Managers and workers must know and understand how databases are constructed so they know how
to use the information resource to their advantage. Managers must guard against problems inherent with
islands of information and understand that sometimes resolution of short-term problems is far costlier in the
long term.

4.3 Database Management Systems

The key to establishing an effective, efficient database is to involve the entire organization as much
as possible, even if everyone seemingly will not be connected to it or be a user of it. Perhaps they won't be a
part of it in the beginning, but they very well could be later on.
You've heard the old saying, "Don't put all your eggs in one basket." When it comes to data, just the
opposite is true. You want to put all your corporate data in one system that will serve the organization as a
whole. A Database Management System (DBMS) is basically another software program like Word or Excel
or Email. This type of software is more complicated: it permits an organization to centralize data, manage
them efficiently, and provide access to the stored data by application programs.
A DBMS has 3 components, all of them important for the long-term success of the system.
Data Definition Language (DDL). Marketing looks at customer addresses differently from
Shipping. So you must make sure that all users of the database are speaking the same language.
Think of it this way: Marketing is speaking French, Production is speaking German, and Human
Resources is speaking Japanese. They are all saying the same thing, but it's very difficult for them to
understand each other. Defining the data definition language itself sometimes gets shortchanged. The
programmers who are creating the language sometimes say "Hey, an address is an address, so what."
That's when it becomes critical to involve users in the development of the Data Definition Language.
Data Manipulation Language (DML). This is a formal language used by programmers to
manipulate the data in the database and make sure they are formulated into useful information. The
goal of this language should be to make it easy for users. The basic idea is to establish a single data
element that can serve multiple users in different departments depending on the situation. Otherwise,
you'll be tying up programmers to get information from the database that users should be able to get
on their own.
Data Dictionary. Each data element or field should be carefully analyzed to determine what it will
be used for, who will be the primary user, and how it fits into the overall scheme of things. Then
write it all down and make it easily available to all users. This is one of the most important steps in
creating a good database.
Why is it so important to document the data dictionary? Let's say Suvidha, who was in on the initial
design and building of the database, moves on and Joe takes her place. It may not be so apparent to him what
all the data elements really mean, and he can easily make mistakes from not knowing or understanding the
correct use of the data. He will apply his own interpretation, which may or may not be correct. Once again, it
ultimately comes down to a persware problem.
4.3.1 Logical and Physical Views of Data
Physical views of items are often different from the logical views of the same items when they are
actually being used. For instance, assume you store tablets of paper in your lower right desk drawer. You

11.602

Copy Right: Rai University

68

Management Information Systems

store your pencils in the upper left drawer. When it comes time to write your request for a pay raise, you pull
out the paper and pencil and put them together on your desktop. It isn't important to the task at hand where
the items were stored physically; you are concerned with the logical idea of the two items coming together to
help you accomplish the task.
The physical view of data cares about where the data are actually stored in the record or in a file. The
physical view is important to programmers who must manipulate the data as they are physically stored in the
database.
Does it really matter to the user that the customer address is physically stored on the disk before the
customer name? Probably not. However, when users create a report of customers located in Indiana they
generally will list the customer name first and then the address. So it's more important to the end user to
bring the data from their physical location on the storage device to a logical view in the output device,
whether screen or paper.
Database Management Systems have three critical components: the data definition language, the data
manipulation language, and the data dictionary. Managers should ensure that all three receive attention.
Managers should also make sure that end users are involved in developing these three components.
4.3.2 Designing Databases
Every tool has its job. You wouldn't use a screwdriver to pound a nail in the wall (or maybe you
would), nor would you use a hammer to turn a bolt. Each type of database that we discuss in this section has
its own advantages and disadvantages, so you should choose the right type of database for the job you want
to do.
Hierarchical Databases
The hierarchical data model presents data to users in a treelike structure.
Think of a mother and her children. A child only has one mother and inherits some of her
characteristics, such as eye color or hair color. A mother might have one or more children to which she
passes some of her characteristics but usually not exact ones. The child then goes on to develop its own
characteristics separate from the mother.

A hierarchical database for a human resources system.

In a hierarchical database, characteristics from the parent are passed to the child by a pointer just as
a human mother will have a genetic connection to each human child. You can see how this database pointer
works by looking at the above figure..
Network Database

11.602

Copy Right: Rai University

69

Management Information Systems

A network data model is a variation of the hierarchical model.
Take the same scenario with one parent and many children and add a father and perhaps a couple of
stepparents. Now the parents aren't restricted to only one (the mother) but to many parents. That is, a parent
can have many children and a child can have many parents. The parents pass on certain characteristics to the
children, but the children also have their own distinct characteristics.

The network data model.

As with hierarchical structures, each relationship in a network database must have a pointer from all
the parents to all the children and back, as the above figure demonstrates.
These two types of databases, the hierarchical and the network, work well together since they can
easily pass data back and forth. But because these database structures use pointers, which are actually
additional data elements, the size of the database can grow very quickly and cause maintenance and
operation problems.
Relational Data Model
A relational data model uses tables in which data are stored to extract and combine data in different
combinations. The tables are sometimes called files, although that is actually a misnomer, since you can have
multiple tables in one file.
In a relational database, each table contains a primary key, a unique identifier for each record. To
make sure the tables relate to each other, the primary key from one table is stored in a related table as a
secondary key. For instance, in the Customer table the primary key is the unique Customer ID. That primary
key is then stored in the Order Table as the secondary key so that the two tables have a direct relationship.
Customer Table
Customer Name
Customer Address
Customer ID
Order Number

Self Explanatory
Self Explanatory
Primary Key----->
Secondary Key

Order Table
Order Number
Order Item
Number of Items Ordered
Customer ID

Primary Key
Self Explanatory
Self Explanatory
Secondary Key

Use these three basic operations to develop relational databases:

Select: create a subset of records meeting the stated criteria
Join: combine related tables to provide more information than individual tables

11.602

Copy Right: Rai University

70

Management Information Systems

Project: create a new table from subsets of previous tables

The biggest problem with these databases is the misconception that every data element should be stored
in the same table. In fact, each data element should be analyzed in relation to other data elements with the
goal of making the tables as small in size as possible. The ideal relational database will have many small
tables, not one big one. On the surface that may seem like extra work and effort, but by keeping the tables
small, they can serve a wider audience because they are more flexible. This setup is especially helpful in
reducing redundancy and increasing the usefulness of data.
Advantages and Disadvantages
Hierarchical and network databases can be very efficient as long as you plan ahead. But as you
know, needs change, and neither one of these databases offers a lot of flexibility to change with business
needs. It's sort of like parents and children; once you establish the tie, it's pretty hard to amend.
Relational database management systems are more flexible, especially if you keep the tables small. It
is much easier for non-techies to create the query language in a relational system. It's also easier to add new
data elements, although if you do, you'll have to go back and fill in the missing information for the old
records or just forget them altogether.
4.3.3 Comparing of Database Alternatives
Type of
Decisions
Hierarchical
Network
Relational

Processing
Efficiency
High
Medium-High
Low but
Improving

Low
Low-Medium

End-user
friendliness
Low
Low-Medium

Programming
Flexibility
High
High

High

High

Low

Flexibility

The above table compares these alternatives on several dimensions to show you the advantages and
disadvantages of each.
What you should remember is that none of these databases is very good if you don't keep the end
user in mind. If you're not careful, you'll wind up with lots of information that no one can use.
4.3.4 Creating a database
First, you should think long and hard about how you use the available information in your current
situation. Think of the good and the bad of how it is organized, stored, and used. Now imagine how this
information could be organized better and used more easily throughout the organization. What part of the
current system would you be willing to get rid of and what would you add? Involve as many users in this
planning stage as possible. They are the ones who will prosper or suffer because of the decisions you make at
this point.
Determine the relationships between each data element that you currently have (entity-relationship
diagram). The data don't necessarily have to be in a computer for you to consider the impact. Determine
which data elements work best together and how you will organize them in tables. Break your groups of data
into as small a unit as possible (normalization). Even when you say it's as small as it can get, go back again.
Avoid redundancy between tables. Decide what the key identifier will be for each record. See, you've done
all this and you haven't even touched the computer yet!

11.602

Copy Right: Rai University

71

Management Information Systems

Give it your best shot in the beginning: it costs a lot of time, money, and frustration to go back and
make changes or corrections or to live with a poorly designed database.
There are three types of databases: hierarchical, network, and relational. Relational databases are
becoming the most popular of the three because they are easier to work worth, easier to change, and can
serve a wider range of needs throughout the organization.

4.4 Database Trends

Recent database trends include the growth of distributed databases and the emergence of objectoriented and hypermedia databases.

Distributed databases are usually found in very large corporations that require multiple sites to
have immediate, fast access to data. As the book points out, there are lots of disadvantages, so you
should be careful in determining if this is the right way for you to run your business.
Object-Oriented and Hypermedia Databases: Many companies are steering away from strictly
text-based database systems. Data as objects can be pictures, groups of text, voice, audio, etc.
Object-oriented databases bring the various objects from many different sources and get them all
working together.
As we move away from strictly text-based information systems and incorporate video and sound,
graphics and text, the hypermedia database will become more common. The below given figure
helps explain the concept of a hypermedia database by showing how the various elements are
networked. The attraction to this type of database is that it allows the user to decide which path to
follow from one node to another.

Hypermedia database

11.602

Multidimensional Data Analysis: As technology improves, so does our ability to manipulate

information maintained in databases. Have you ever played with a Rubik Cube - one of those cute
little multicolored puzzle boxes you can twist around and around to come up with various color
combinations? That's a close analogy to how multidimensional data analysis or on-line analytical

Copy Right: Rai University

72

Management Information Systems

processing (OLAP) works (see the Figure given below). In theory, it's easy to change data around to
fit your needs.

Multidimensional data model.

Data Warehouses: As organizations want and need more information about the company, the
products, and the customers, the concept of data warehousing has become very popular. Remember
those islands of information we keep talking about? Unfortunately, too many of them have
proliferated over the years, and now companies are trying to rein them in using data warehousing.
No data warehouses are not great big buildings with shelves and shelves of bits and bytes stored on
them. They are huge computer files that store old and new data about anything and everything a
company wants to maintain information on.
Since the data warehouse can be cumbersome, a company can break the information into smaller
groups called data marts. It's easier and cheaper to sort through smaller groups of data. It's still
useful to have a huge data warehouse, though, so that information is available to everyone who
wants or needs it. You can let the user determine how the data will be manipulated and used. Using a
data warehouse correctly can give management a tremendous amount of information that can be used
to trim costs, reduce inventory, put products in the right stores, etc.

4.5 Linking Databases to the Web

Even though Web browsers have been around for only a few years, they are far easier to use than
most of the query languages associated with the other programs on mainframe computer systems. That's why
many companies are starting to link their databases to a Web-like browser. They are finding out that it's
easier to provide their "road warriors" with Web-like browsers attached to the computer at the main office.
Employees anywhere can have up-to-the-minute access to any information they need. It's also proving
cheaper to create browser applications that can more easily link information from disparate systems than to
try to combine all the systems.
There are many ways to manipulate databases so that an organization can save money and still have
useful information. With technological improvements, companies don't have to continually start from scratch
but can blend the old with the new when they want to update their systems.

4.6 Management Requirements

11.602

Copy Right: Rai University

73

Management Information Systems

Key organizational elements in the database environment.

Nothing is ever as easy as it sounds. As the above figure shows, there is a lot more to a viable, useful
database than just its structure.
4.6.1 Data Administration
Ask any manager what his resources are and he's likely to list people, equipment, buildings, and
money. Very few managers will include information on the list, yet it can be more valuable than some of the
others. A data administration function, reporting to senior management, can help emphasize the importance
of this resource. This function can help define and structure the information requirements for the entire
organization to ensure it receives the attention it deserves
Data Administration is responsible for:

Developing information policies

Planning for data
Overseeing logical database design
Data dictionary development
Monitoring the usage of data by techies and non-techies

No one part of the organization should feel it owns information to the exclusion of other departments
or people in the organization. A certain department may have the primary responsibility for updating and
maintaining the information, but that department still has to share it across the whole company. Well-written
information policies can outline the rules for using this important resource, including how it will be shared,
maintained, distributed, and updated.
4.6.2 Data planning
At the beginning we said that as many users as possible should be brought together to plan the
database. We believed it so much then that we'll say it again here. By excluding groups of users in the
planning stages, no matter how insignificant that group may seem a company courts trouble.

11.602

Copy Right: Rai University

74

Management Information Systems

4.6.3 Database Technology, Management, and Users
Change isn't just something you experience by chance; in all likelihood, it will be required
throughout the corporate structure. You need to get the non-techies talking and working with the techies.
Users will take on more responsibility for accessing data on their own through query languages if they
understand the structure of the database. Users need to understand the role they play in treating information
as an important corporate resource. Not only will they require a user-friendly structure for the database, but
they will also need lots of training and hand holding up front. It will pay off in the long run.
Database administration functions can:

Define and organize database structure and content.

Develop security procedures to safeguard the database.
Develop database documentation.
Maintain the database management software.

As with any other resource, managers must administer data, plan their uses, and discover new
opportunities for the data to serve the organization through changing technologies.

4.7 The Database Environment

Now, we are having basic understanding about the databases and the requirements of the
management and the organisation. Let us continues by knowing the database environment which will give
you a clear idea about how it is performing.
Let us recall what we learned earlier in this chapter. Database is an organized collection of logically
related data. Information is data that was processed to increase the knowledge of the person who uses it.
Example, your credit card company is collecting data about your purchases (date, amount,
merchant). The monthly statement contains information about your account. The credit card company
maintains a database of related data such as your name and address, the merchant you bought the
merchandise from and the credit card transaction information.
Let me explain the advantages we are enjoying by having database environment by an example.
The (PVFC) is a manufacturer of high quality all wood furniture. The product line includes:
computer desks, entertainment centers, dinette set, book cases and wall units. The figure below illustrates
how the information systems were developed for each department to run their own applications, without an
overall database design for the entire company. Each file is designed to meet a specific application such as:
order entry, accounting and personnel.

11.602

Copy Right: Rai University

75

Management Information Systems

To emphasize the redundancies of the application approach, let us review another example related to
banks.
Bank Example: Consider a new customer, Smith, opening a savings account. The personal data and the
account information are entered into the Savings file. At a later time, Joe opens a money market account with
the Money Market Department. Same information is entered. Finally, same information is entered again by
the Loan Department where Joe obtains a car loan. These files are shown below:
Savings File in the Savings Department
Account
Number

Depositor
Name

S-100

Smith, Joe

S-101

Doe, Jones

SSN

Address

111-111111

100 Main St., Phila, PA 19100

Phone

Deposit
$amount

(215) 2041234

$1.000

Phone

Deposit
$amount

222-111234

Money Market File in the MM Department

Account
Number
MM-320

Depositor
Name
Smith, Joe

SSN
111-111111

Address
100 Main St., Phila, PA
19100

(215)2041234

$500.

Loan File in the Loan Department:

11.602

Copy Right: Rai University

76

Management Information Systems

Account
Number

Depositor
Name

SSN

Address

Phone

Loan
$amount

LD-123

Smith, Joe

111-111111

100 Main St., Phila, PA

19100

(215)2041234

$2500.

By seeing the above example we may conclude the disadvantages of the file system as the
following:

Duplication of Data (Customer and Inventory data is repeated in each application)

Limited Data Sharing (One department can't access the files of other departments)
Program-Data Dependence (Data definition is hard coded in each program. Thus a change in the data
characteristics requires a change in all programs using this data)

Lengthy Development Time and maintenance (Because there are many duplicated programs to
process same data)
Now, try to answer to the following question.
How would you intuitively 'redesign' the PVFC and the bank file system?

Just observe the following database design where the above listed disadvantages of file system are
completely eliminated.

Compare this database design with the previous 'traditional' file processing bank example, and note
how the redundancies were removed and that the customer record has to be 'related' to the accounts of the
same customer.
4.7.1 How are these relational databases developed?
We begin by analyzing the user's requirements .In the process of the analysis we develop the data
model (conceptual schema) representing the data requirements. The conceptual schema is independent of the

11.602

Copy Right: Rai University

77

Management Information Systems

database type used. Finally we convert the conceptual schema into a physical schema which is peculiar to
the database management we use

Program Report Definition

Program Display Definition

Program - Transaction

User View 1
(Report)

User View 2
(Screen Display)

User View 3
(Transactions)

Conceptual Schema

Physical Schema
Part of the conceptual schema for the PVFC example would actually look like this:

11.602

Copy Right: Rai University

78

Management Information Systems

Note that what we have here is a list of attributes for each entity (only some of the entities are
represented here) along with a designation of primary keys (underlined) and foreign keys (dotted underlines)
and links. (Note that ORDER LINE used to be ORDERED PRODUCT and the two IDs really should be
considered as foreign keys for what we are doing now. But for now these are minor details.)
So -- how do we build the schema above?
As an example, consider the invoice below. It is the user's view of the invoice data. It is a piece of
paper representing one possible output or report from a software system.
The user thinks of it as one 'entity', and we might view it initially as a single entity. In the end,
however, in the database it is likely to be stored in multiples tables.

We would take this output and start to build a conceptual schema from it. Then we would build the physical
schema. The conceptual schema represents the overall logical structure of the database. It is contains all
entities and the list of attributes for these entities. The conceptual schema is used as the bases for
representing primary and foreign keys, and drawing links among the entities. The conceptual schema is also
later used in normalization -- in seeing the need for normalization and in carrying out the normalization
tasks.
Building the conceptual schema requires a careful analysis of ALL output requirements for a
system. This analysis CANNOT be carried out if you do not clearly understand the business parameters or
rules that govern the use of the system. You have to understand the problem domain, not just what is
needed. You need to know

11.602

What is needed?
What is possible?
What is not possible (or at least not likely)?

Copy Right: Rai University

79