The Role of Information Systems in Organizations
1. The Organizational Context for Using Database Systems
Database systems have become a part of the information systems of many
organizations. Historically, information systems were dominated by file
systems in the 1960s, but since the early 1970s organizations have gradually
moved to database management systems (DBMSs). To accommodate DBMSs, many
organizations have created the position of database administrator (DBA) and
database administration departments to oversee and control database life-cycle
activities. Similarly, information technology (IT) and information resource
management (IRM) departments have been recognized by large organizations as
being key to successful business management for the following reasons:
Data is regarded as a corporate
resource, and its management and control is considered central to the effective
working of the organization.
More functions in organizations
are computerized, increasing the need to keep large volumes of data available
in an up-to-the-minute current state.
As the complexity of the data and
applications grows, complex relationships among the data need to be modeled and
There is a tendency toward
consolidation of information resources in many organizations.
Many organizations are reducing
their personnel costs by letting end users perform business transactions. This
is evident with travel services, financial services, higher education,
government, and many other types of services. This trend was realized early on
by online retail goods outlets and customer-to-business electronic commerce,
such as Amazon.com and eBay. In these organizations, a publicly accessible and
updatable operational database must be designed and made available for the
Many capabilities provided by database systems have made them integral
compo-nents in computer-based information systems. The following are some of
the key features that they offer:
Integrating data across multiple
applications into a single database.
Support for developing new
applications in a short time by using high-level languages like SQL.
Providing support for casual
access for browsing and querying by managers while supporting major
production-level transaction processing for customers.
From the early 1970s through the mid-1980s, the move was toward creating
large centralized repositories of data managed by a single centralized DBMS.
Since then, the trend has been toward utilizing distributed systems because of
the following developments:
Personal computers and database system-like software products such as
Excel, Visual FoxPro, Access (Microsoft), and SQL Anywhere (Sybase), and public
domain products such as MySQL and PostgreSQL, are being heavily utilized by
users who previously belonged to the category of casual and occasional
database users. Many administrators, secretaries, engineers, scientists,
architects, and students belong to this category. As a result, the practice of
creating personal databases is
gaining popularity. It is sometimes possible to check out a copy of part of a
large database from a mainframe computer or a database server, work on it from
a personal workstation, and then restore it on the mainframe. Similarly, users
can design and create their own databases and then merge them into a larger
The advent of distributed and
client-server DBMSs (see Chapter 25) is open-ing up the option of distributing
the database over multiple computer systems for better local control and
faster local processing. At the same time, local users can access remote data
using the facilities provided by the DBMS as a client, or through the Web.
Application development tools such as PowerBuilder and PowerDesigner (Sybase)
and OracleDesigner and Oracle Developer Suite (Oracle) are being used with
built-in facilities to link appli-cations to multiple back-end database
Many organizations now use data dictionary systems or information repositories, which are mini DBMSs that manage meta-data—that is, data that
describes the database structure, constraints, applications, authoriza-tions,
users, and so on. These are often used as an integral tool for informa-tion
resource management. A useful data dictionary system should store and manage
the following types of information:
Descriptions of the schemas of
the database system.
Detailed information on physical
database design, such as storage struc-tures, access paths, and file and record
Descriptions of the types of
database users, their responsibilities, and their access rights.
High-level descriptions of the
database transactions and applications and of the relationships of users to
The relationship between database
transactions and the data items refer-enced by them. This is useful in
determining which transactions are affected when certain data definitions are
Usage statistics such as frequencies
of queries and transactions and access counts to different portions of the
The history of any changes made
to the database and applications, and documentation that describes the reasons
for these changes. This is some-times referred to as data provenance.
This meta-data is available to DBAs, designers, and authorized users as
online sys-tem documentation. This improves the control of DBAs over the
information sys-tem as well as the users’ understanding and use of the system.
The advent of data warehousing technology (see Chapter 29) has highlighted the
importance of meta-data.
When designing high-performance transaction
processing systems, which require around-the-clock nonstop operation,
performance becomes critical. These data-bases are often accessed by hundreds,
or thousands, of transactions per minute from remote computers and local
terminals. Transaction performance, in terms of the average number of
transactions per minute and the average and maximum transac-tion response time,
is critical. A careful physical database design that meets the organization’s
transaction processing needs is a must in such systems.
Some organizations have committed their information resource management
to certain DBMS and data dictionary products. Their investment in the design
and implementation of large and complex systems makes it difficult for them to
change to newer DBMS products, which means that the organizations become locked
in to their current DBMS system. With regard to such large and complex databases,
we cannot overemphasize the importance of a careful design that takes into
account the need for possible system modifications—called tuning—to respond to changing requirements. We will discuss tuning
in conjunction with query optimization in Chapter 21. The cost can be very high
if a large and complex system cannot evolve, and it becomes necessary to
migrate to other DBMS products and redesign the whole system.
2. The Information
System Life Cycle
In a large organization, the database system is typically part of an information sys-tem (IS), which
includes all resources that are involved in the collection, manage-ment, use,
and dissemination of the information resources of the organization. In a
computerized environment, these resources include the data itself, the DBMS
soft-ware, the computer system hardware and storage media, the personnel who
use and manage the data (DBA, end users, and so on), the application programs
(software) that accesses and updates the data, and the application programmers
who develop these applications. Thus the database system is part of a much
larger organizational information system.
In this section we examine the typical life cycle of an information
system and how the database system fits into this life cycle. The information
system life cycle has been called the macro
life cycle, whereas the database system life cycle has been referred to as
the micro life cycle. The
distinction between them is becoming less pronounced for information systems
where databases are a major integral compo-nent. The macro life cycle typically includes the following phases:
Feasibility analysis. This
phase is concerned with analyzing potential appli-cation areas, identifying the
economics of information gathering and dissemination, performing preliminary
cost-benefit studies, determining the complexity of data and processes, and
setting up priorities among applications.
Requirements collection and analysis. Detailed
requirements are collected by
interacting with potential users and user groups to identify their particu-lar
problems and needs. Interapplication dependencies, communication, and reporting
procedures are identified.
Design. This phase has two aspects: the
design of the database system and the
design of the application systems (programs) that use and process the database
through retrievals and updates.
Implementation. The information system is
implemented, the database is loaded,
and the database transactions are implemented and tested.
Validation and acceptance
testing. The acceptability of the system
in meeting users’ requirements and performance criteria is validated. The
system is tested against performance criteria and behavior specifications.
Deployment, operation, and maintenance. This may be preceded by con-version of users from an older system as
well as by user training. The operational phase starts when all system
functions are operational and have been validated. As new requirements or
applications crop up, they pass through the previous phases until they are validated
and incorporated into the system. Monitoring of system performance and system
maintenance are important activities during the operational phase.
3. The Database
Application System Life Cycle
Activities related to the micro
life cycle, which focuses on the database application system, include the
System definition. The scope of the database system,
its users, and its applications are
defined. The interfaces for various categories of users, the response time
constraints, and storage and processing needs are identified.
Database design. A complete logical and physical
design of the database system on the
chosen DBMS is prepared.
Database implementation. This
comprises the process of specifying the conceptual,
external, and internal database definitions, creating the (empty) database
files, and implementing the software applications.
Loading or data conversion. The
database is populated either by loading the
data directly or by converting existing files into the database system for-mat.
Application conversion. Any
software applications from a previous system are converted to the new system.
Testing and validation. The new
system is tested and validated. Testing and
validation of application programs can be a very involved process, and the
techniques that are employed are usually covered in software engineering
courses. There are automated tools that assist in this process, but a
discussion is outside the scope of this textbook.
Operation. The database system and its
applications are put into operation. Usually, the old and the new systems are
operated in parallel for a period of time.
Monitoring and maintenance. During
the operational phase, the system is constantly
monitored and maintained. Growth and expansion can occur in both data content
and software applications. Major modifications and reorganizations may be
needed from time to time.
Activities 2, 3, and 4 are part of the design and implementation phases
of the larger information system macro life cycle. Our emphasis in Section 10.2
is on activities 2 and 3, which cover the database design and implementation
phases. Most databases in organizations undergo all of the preceding life cycle
activities. The conversion activities (4 and 5) are not applicable when both
the database and the applications are new. When an organization moves from an
established system to a new one, activities 4 and 5 tend to be very
time-consuming and the effort to accomplish them is often underestimated. In
general, there is often feedback among the various steps because new
requirements frequently arise at every stage. Figure 10.1 shows the feedback
loop affecting the conceptual and logical design phases as a result of sys-tem
implementation and tuning.