THE DATABASE DEVELOPMENT PROCESS
How do organizations start developing a database? In many organizations, database development
begins with enterprise data modeling, which establishes the range and general
contents of organizational databases. Its purpose is to create an overall picture or explanation
of organizational data, not the design for a particular database. A particular
database provides the data for one or more information systems, whereas an enterprise
data model, which may encompass many databases, describes the scope of data maintained
by the organization. In enterprise data modeling, you review current systems, analyze
the nature of the business areas to be supported, describe the data needed at a very
high level of abstraction, and plan one or more database development projects.
Figure 1-3a showed a segment of an enterprise data model for Pine Valley
Furniture Company, using a simplified version of the notation you will learn in
Chapters 2 and 3. Besides such a graphical depiction of the entity types, a thorough enterprise
data model would also include business-oriented descriptions of each entity
type and a compendium of various statements about how the business operates, called
business rules, which govern the validity of data. Relationships between business
objects (business functions, units, applications, etc.) and data are often captured using
matrixes and complement the information captured in the enterprise data model.
Figure 1-9 shows an example of such a matrix.
Enterprise data modeling as a component of a top-down approach to information
systems planning and development represents one source of database projects. Such
projects often develop new databases to meet strategic organizational goals, such as improved
customer support, better production and inventory management, or more accurate
sales forecasting. Many database projects arise, however, in a more bottom-up fashion.
In this case, projects are requested by information systems users, who need certain
information to do their jobs, or from other information systems professionals, who see a
need to improve data management in the organization.
Atypical bottom-up database development project usually focuses on the creation of
one database. Some database projects concentrate only on defining, designing, and implementing
a database as a foundation for subsequent information systems development. In understanding any new database requirements and defining a database to be used by
the prototype. This is typically a new database, which is a copy of portions of existing
databases, possibly with new content. If new content is required, it will usually come
from external data sources, such as market research data, general economic indicators, or industry standards.
How do organizations start developing a database? In many organizations, database development
begins with enterprise data modeling, which establishes the range and general
contents of organizational databases. Its purpose is to create an overall picture or explanation
of organizational data, not the design for a particular database. A particular
database provides the data for one or more information systems, whereas an enterprise
data model, which may encompass many databases, describes the scope of data maintained
by the organization. In enterprise data modeling, you review current systems, analyze
the nature of the business areas to be supported, describe the data needed at a very
high level of abstraction, and plan one or more database development projects.
Figure 1-3a showed a segment of an enterprise data model for Pine Valley
Furniture Company, using a simplified version of the notation you will learn in
Chapters 2 and 3. Besides such a graphical depiction of the entity types, a thorough enterprise
data model would also include business-oriented descriptions of each entity
type and a compendium of various statements about how the business operates, called
business rules, which govern the validity of data. Relationships between business
objects (business functions, units, applications, etc.) and data are often captured using
matrixes and complement the information captured in the enterprise data model.
Figure 1-9 shows an example of such a matrix.
Enterprise data modeling as a component of a top-down approach to information
systems planning and development represents one source of database projects. Such
projects often develop new databases to meet strategic organizational goals, such as improved
customer support, better production and inventory management, or more accurate
sales forecasting. Many database projects arise, however, in a more bottom-up fashion.
In this case, projects are requested by information systems users, who need certain
information to do their jobs, or from other information systems professionals, who see a
need to improve data management in the organization.
Atypical bottom-up database development project usually focuses on the creation of
one database. Some database projects concentrate only on defining, designing, and implementing
a database as a foundation for subsequent information systems development. In understanding any new database requirements and defining a database to be used by
the prototype. This is typically a new database, which is a copy of portions of existing
databases, possibly with new content. If new content is required, it will usually come
from external data sources, such as market research data, general economic indicators, or industry standards.
Database implementation and maintenance activities are repeated as new versions
of the prototype are produced. Often security and integrity controls are minimal
because the emphasis is on getting working prototype versions ready as quickly as possible.
Also, documentation tends to be delayed until the end of the project, and user
training occurs from hands-on use. Finally, after an accepted prototype is created, the
developer and the user decide whether the final prototype, and its database, can be put
into production as is. If the system, including the database, is too inefficient, the system
and database might need to be reprogrammed and reorganized to meet performance
expectations. Inefficiencies, however, have to be weighed against violating the core
principles behind sound database design.
With the increasing popularity of visual programming tools (such as Visual Basic,
Java, or C#) that make it easy to modify the interface between user and system, prototyping is becoming the systems development methodology of choice to develop new
applications internally. With prototyping, it is relatively easy to change the content and
layout of user reports and displays.
The benefits from iterative approaches to systems development demonstrated
by RAD and prototyping approaches have resulted in further efforts to create ever
more responsive development approaches. In February 2001, a group of 17 individuals
interested in supporting these approaches and created “The Manifesto for Agile
Software Development.” For them, agile software development practices include
valuing.
Emphasis on the importance of people, both software developers and customers, is evident
in their phrasing. This is in response to the turbulent environment within which
software development occurs, as compared to the more staid environment of most engineering development projects from which the earlier software development methodologies came. The importance of the practices established in the SDLC continues to be recognized and accepted by software developers including the creators of The
Manifesto for Agile Software Development. However, it is impractical to allow these
practices to stifle quick reactions to changes in the environment that change project
requirements.
The use of agile or adaptive processes should be considered when a project
involves unpredictable and/or changing requirements, responsible and collaborative
developers, and involved customers who understand and can contribute to the process
(Fowler, 2005). If you are interested in learning more about agile software development,
investigate agile methodologies such as eXtreme Programming, Scrum, the DSDM
Consortium, and feature-driven development.
Three-Schema Architecture for Database Development
The explanation earlier in this chapter of the database development process referred to
several different, but related, models of databases developed on a systems development
project. These data models and the primary phase of the SDLC in which they are developed are summarized below:
• Enterprise data model (during the Information Systems Planning phase)
• External schema or user view (during the Analysis and Logical Design phases)
• Conceptual schema (during the Analysis phase)
• Logical schema (during the Logical Design phase)
• Physical schema (during the Physical Design phase)
of the prototype are produced. Often security and integrity controls are minimal
because the emphasis is on getting working prototype versions ready as quickly as possible.
Also, documentation tends to be delayed until the end of the project, and user
training occurs from hands-on use. Finally, after an accepted prototype is created, the
developer and the user decide whether the final prototype, and its database, can be put
into production as is. If the system, including the database, is too inefficient, the system
and database might need to be reprogrammed and reorganized to meet performance
expectations. Inefficiencies, however, have to be weighed against violating the core
principles behind sound database design.
With the increasing popularity of visual programming tools (such as Visual Basic,
Java, or C#) that make it easy to modify the interface between user and system, prototyping is becoming the systems development methodology of choice to develop new
applications internally. With prototyping, it is relatively easy to change the content and
layout of user reports and displays.
The benefits from iterative approaches to systems development demonstrated
by RAD and prototyping approaches have resulted in further efforts to create ever
more responsive development approaches. In February 2001, a group of 17 individuals
interested in supporting these approaches and created “The Manifesto for Agile
Software Development.” For them, agile software development practices include
valuing.
Emphasis on the importance of people, both software developers and customers, is evident
in their phrasing. This is in response to the turbulent environment within which
software development occurs, as compared to the more staid environment of most engineering development projects from which the earlier software development methodologies came. The importance of the practices established in the SDLC continues to be recognized and accepted by software developers including the creators of The
Manifesto for Agile Software Development. However, it is impractical to allow these
practices to stifle quick reactions to changes in the environment that change project
requirements.
The use of agile or adaptive processes should be considered when a project
involves unpredictable and/or changing requirements, responsible and collaborative
developers, and involved customers who understand and can contribute to the process
(Fowler, 2005). If you are interested in learning more about agile software development,
investigate agile methodologies such as eXtreme Programming, Scrum, the DSDM
Consortium, and feature-driven development.
Three-Schema Architecture for Database Development
The explanation earlier in this chapter of the database development process referred to
several different, but related, models of databases developed on a systems development
project. These data models and the primary phase of the SDLC in which they are developed are summarized below:
• Enterprise data model (during the Information Systems Planning phase)
• External schema or user view (during the Analysis and Logical Design phases)
• Conceptual schema (during the Analysis phase)
• Logical schema (during the Logical Design phase)
• Physical schema (during the Physical Design phase)
In 1978, an industry committee commonly known as ANSI/SPARC published an
important document that described three-schema architecture—external, conceptual
and internal schemas—for describing the structure of data. Figure 1-12 shows the
relationship between the various schemas developed during the SDLC and the ANSI
three-schema architecture. It is important to keep in mind that all these schemas are just
different ways of visualizing structure of the same database by different stakeholders.
The three schemas as defined by ANSI (depicted down the center of Figure 1-12)
are as follows:
1. External schema This is the view (or views) of managers and other employees
who are the database users. As shown in Figure 1-12, the external schema can be
represented as a combination of the enterprise data model (a top-down view) and
a collection of detailed (or bottom-up) user views.
2. Conceptual schema This schema combines the different external views into a
single, coherent, and comprehensive definition of the enterprise’s data.
The conceptual schema represents the view of the data architect or data administrator.
3. Internal schema As shown in Figure 1-12, an internal schema today really consists
of two separate schemas: a logical schema and a physical schema. The logical
schema is the representation of data for a type of data management technology (e.g., relational). The physical schema describes how data are to be represented
and stored in secondary storage using a particular DBMS (e.g., Oracle).
important document that described three-schema architecture—external, conceptual
and internal schemas—for describing the structure of data. Figure 1-12 shows the
relationship between the various schemas developed during the SDLC and the ANSI
three-schema architecture. It is important to keep in mind that all these schemas are just
different ways of visualizing structure of the same database by different stakeholders.
The three schemas as defined by ANSI (depicted down the center of Figure 1-12)
are as follows:
1. External schema This is the view (or views) of managers and other employees
who are the database users. As shown in Figure 1-12, the external schema can be
represented as a combination of the enterprise data model (a top-down view) and
a collection of detailed (or bottom-up) user views.
2. Conceptual schema This schema combines the different external views into a
single, coherent, and comprehensive definition of the enterprise’s data.
The conceptual schema represents the view of the data architect or data administrator.
3. Internal schema As shown in Figure 1-12, an internal schema today really consists
of two separate schemas: a logical schema and a physical schema. The logical
schema is the representation of data for a type of data management technology (e.g., relational). The physical schema describes how data are to be represented
and stored in secondary storage using a particular DBMS (e.g., Oracle).