1

Database Planning and Design

March 9, 2015

DATABASE PLANNING AND DESIGN

Database Planning and Design

Databases, efficiently-organized infrastructures that allow for the organization, storage,
and retrieval of files, are employed by countless organizations throughout the world. Underlying
modern enterprise systems, databases must be carefully conceived, modeled, designed, and
implemented in a concerted effort by analysts, developers, and the organization itself. Once
organizational and user requirements for the database have been gathered and analyzed,
participants transition through three successive stages, known as Conceptual, Logical, and
Physical database design. During the conceptual design phase, user requirements are translated
into a conceptual data model, using visual abstractions, such as entity-relationship diagrams
(ERDs), which help users and developers to communicate about existing and potential system
functions. It is important to note that the use of ERDs is not strictly limited to conceptual
modeling, but often employed throughout all phases of database design, in an iterative process.
Once the relationships between system entities are identified and documented, a data dictionary
must be developed as a descriptive catalog of each data item and their associated characteristics,
a set of activities which may occur in parallel with data flow modeling. Collectively, this
interrelated process is known as entity-relationship (ER) modeling. In this report, we shall
further examine the roles of entity-relationship diagrams and data dictionaries, with respect to the
design of an organizational database.
Within an organization, data will ultimately be stored about objects that exist in the real
world, such as people, places, and things that are relevant to the operation of a specific business.
When represented in a database model, these objects become known as entities (Kendall &
Kendall, 2011, p. 405). Examples of entities include things like customers, suppliers, and
products, but entities can also represent events and processes, such as sales transactions,

DATABASE PLANNING AND DESIGN

inventory replenishment, or the act of storing a customer profile. Subsequently, a relationship is

defined as the association that describes interaction among the entities (Kendall & Kendall,
2011, p. 30). As the name implies, these aspects are combined to form entity-relationship
diagrams.
Within an ERD, three main types of relationships exist: one-to-one (1:1), one-to-many
(1:M), and many-to-many (M:N). A one-to-one relationship means that a single instance of an
entity is associated with a single instance of a second entity. An example of this type of
relationship would be an employee name and an employee ID number, within a staff database.
Furthermore, a one-to-many relationship (a single instance of an entity, to multiple instances of
another entity) might represent a lone business location that houses many employees. Finally, a
many-to-many relationship (multiple instances of an entity, to multiple instances of another
entity) could illustrate the association between an organizations multiple staff members and the
projects they are involved with: many employees to multiple different projects. When an ERD is
developed as the foundation for a relational database, during the conceptual design phase, the
diagram will only illustrate entities, their attributes, and the relationships between them.
However, additional information about the ERD components exists in the form of descriptions,
or metadata, which must be catalogued for reference throughout the development process, using
a data dictionary.
A data dictionary is a collection of data about data, also known as metadata, which are
individual descriptions of database objects that are identified and defined during conceptual and
logical modeling (Kendall & Kendall, 2011, p. 228). When used as part of a relational database
management system (DBMS), a data dictionary stores information about various tables (aka
relations), such as table names, table owners, column details, and physical storage requirements,

DATABASE PLANNING AND DESIGN

along with names and descriptions of the tables contents, but omits the contents of the table
itself (data elements) (Ramklass, 2014, p. 57).
Subsequently, when used by individuals, the data dictionary serves as a centralized
source of definitive information about data elements within a system. These living documents,
which begin their lives during the early stages of system development, should be maintained,
modified, and updated for the duration of a life cycle. Potential uses for a data dictionary include
data flow diagram validation; the development of screens, forms, and reports; XML creation; and
any activity that requires one to determine the contents of data stored in files (Kendall &
Kendall, 2011, p. 229).
When placed under the microscope of analysis, the construction of an organizational
database, like any system development project, is shown to occur in a series of orchestrated
phases, known as Conceptual, Logical, and Physical design. As demonstrated here, entityrelationship diagrams and database dictionaries are produced and modified during the conceptual
and logical design stages, as supplements and complements to one another. As visual
abstractions, ERDs facilitate enhanced communication among project participants, allowing
humans to perceive the way systems truly function. Furthermore, data dictionaries contain the
textual descriptions of ERD components, later utilized by both people and programs, during
subsequent activities throughout the duration of the database lifecycle. Both ERDs and data
dictionaries are crucial to the development of an effective and efficient database, as shown in this
report.

DATABASE PLANNING AND DESIGN

References
Kendall, K.E., & Kendall, J.E. (2011). Systems analysis and design (8th ed.). Retrieved from The
University of Phoenix ebook Collection.
Ramklass, R. (2014). Oracle database 12c: SQL fundamentals. . New York, NY: Mcgraw-Hill.