Database Development Process

Conceptual design
Logical design
Physical Design

> CHANGE, EVERYDAY

Conceptual design
The design phase is where the requirements identified in the
previous phase are used as the basis to develop the new system.
Another way of putting it is that the business understanding of
the data structures is converted to a technical understanding.
The what questions ("What data are required? What are the
problems to be solved?") are replaced by the how questions
("How will the data be structured? How is the data to be
accessed?")
This phase consists of three parts: the conceptual design, the
logical design and the physical design. Some methodologies
merge the logical design phase into the other two phases. This
section is not aimed at being a definitive discussion of database
design methodologies (there are whole books written on that!);
rather it aims to introduce you to the topic. > CHANGE, EVERYDAY
Conceptual design
The purpose of the conceptual design phase is to build a
conceptual model based upon the previously identified
requirements, but closer to the final physical model. A
commonly-used conceptual model is called an entity-
relationship model.

Entities and attributes

Entities are basically people, places, or things you want to keep
information about. For example, a library system may have
the book, library and borrower entities. Learning to identify
what should be an entity, what should be a number of entities,
and what should be an attribute of an entity takes practice, but
there are some good rules of thumb. The following questions
> CHANGE, EVERYDAY
can help to identify whether something is an entity:
Can it vary in number independently of other entities? For example, person
height is probably not an entity, as it cannot vary in number independently
of person. It is not fundamental, so it cannot be an entity in this case.
Is it important enough to warrant the effort of maintaining. For
example customer may not be important for a small grocery store and will
not be an entity in that case, but it will be important for a video store, and will
be an entity in that case.
Is it its own thing that cannot be separated into subcategories? For example,
a car-rental agency may have different criteria and storage requirements for
different kinds of vehicles. Vehicle may not be an entity, as it can be broken
up into car and boat, which are the entities.
Does it list a type of thing, not an instance? The video game blow-em-up 6 is
not an entity, rather an instance of the game entity.
Does it have many associated facts? If it only contains one attribute, it is
unlikely to be an entity. For example, city may be an entity in some cases, but
if it contains only one attribute, city name, it is more likely to be an attribute
of another entity, such as customer.
> CHANGE, EVERYDAY
The following are examples of entities involving a university
with possible attributes in parentheses.
Course (name, code, course prerequisites)
Student (first_name, surname, address, age)
Book (title, ISBN, price, quantity in stock)
An instance of an entity is one particular occurrence of that
entity. For example, the student Rudolf Sono is one instance of
the student entity. There will probably be many instances. If
there is only one instance, consider whether the entity is
warranted. The top level usually does not warrant an entity.
For example, if the system is being developed for a particular
university, university will not be an entity because the whole
system is for that one university. However, if the system was
developed to track legislation at all universities in the country,
then university would be a valid entity. > CHANGE, EVERYDAY
Relationships
Entities are related in certain ways. For example, a borrower
may belong to a library and can take out books. A book can be
found in a particular library. Understanding what you are
storing data about, and how the data relate, leads you a large
part of the way to a physical implementation in the database.
There are a number of possible relationships:
Mandatory
For each instance of entity A, there must exist one or more
instances of entity B. This does not necessarily mean that for
each instance of entity B, there must exist one or more
instances of entity A. Relationships are optional or mandatory
in one direction only, so the A-to-B relationship can be
optional, while the B-to-A relationship is mandatory.
> CHANGE, EVERYDAY
Relationships
Optional
For each instance of entity A, there may or may not exist
instances of entity B.
One-to-one (1:1)
This is where for each instance of entity A, there exists one
instance of entity B, and vice-versa. If the relationship is optional,
there can exist zero or one instances, and if the relationship is
mandatory, there exists one and only one instance of the
associated entity.

One-to-many (1:M)
For each instance of entity A, many instances of entity B can exist,
which for each instance of entity B, only one instance of entity A
> CHANGE, EVERYDAY
exists. Again, these can be optional or mandatory relationships.
Relationships
Many-to-many (M:N)
For each instance of entity A, many instances of
entity B can exist, and vice versa. These can be
optional or mandatory relationships.
There are numerous ways of showing these
relationships. The image below
shows student and course entities. In this case,
each student must have registered for at least
one course, but a course does not necessarily
have to have students registered. The student-
to-course relationship is mandatory, and the
course-to-student relationship is optional.

> CHANGE, EVERYDAY

The image below shows invoice_line and product entities. Each
invoice line must have at least one product (but no more than
one); however each product can appear on many invoice lines,
or none at all. The invoice_line-to-product relationship is
mandatory, while the product-to-invoice_line relationship is
optional.

> CHANGE, EVERYDAY

The figure below shows husband and wife entities. In this system
(others are of course possible), each husband must have one
and only one wife, and each wife must have one, and only one,
husband. Both relationships are mandatory.

An entity can also have a relationship with itself. Such an entity

is called a recursive entity. Take a person entity. If you're
interested in storing data about which people are brothers, you
wlll have an "is brother to" relationship. In this case, the
relationship is a M:N relationship.
> CHANGE, EVERYDAY
Conversely, a weak entity is an entity that cannot exist without
another entity. For example, in a school, the scholar entity is related
to the weak entity parent/guardian.
Without the scholar, the parent or guardian cannot exist in the
system. Weak entities usually derive their primary key, in part or in
totality, from the associated entity. parent/guardian could take the
primary key from the scholar table as part of its primary key (or the
entire key if the system only stored one parent/guardian per
scholar).
The term connectivity refers to the relationship classification.
The term cardinality refers to the specific number of instances
possible for a relationship. Cardinality limits list the minimum and
maximum possible occurrences of the associated entity. In the
husband and wife example, the cardinality limit is (1,1), and in the
case of a student who can take between one and eight courses, the
cardinality limits would be represented as (1,8). > CHANGE, EVERYDAY
Logical design

Logical database design is the process of transforming (or

mapping) a conceptual schema of the application domain
into a schema for the data model underlying a particular
DBMS, such as the relational or object-oriented data model.
This mapping can be understood as the result of trying to
achieve two distinct sets of goals: (i) representation goal:
preserving the ability to capture and distinguish all valid
states of the conceptual schema; (ii) data management
goals: addressing issues related to the ease and cost of
querying the logical schema, as well as costs of storage and
constraint maintenance.
This entry focuses mostly on the mapping of (Extended)
Entity-Relationship (EER) diagrams to relational databases.
> CHANGE, EVERYDAY
Logical design

> CHANGE, EVERYDAY

Physical design
The physical design of your database optimizes performance
while ensuring data integrity by avoiding unnecessary data
redundancies. During physical design, you transform the
entities into tables, the instances into rows, and the attributes
into columns.
After completing the logical design of your database, you now
move to the physical design. You and your colleagues need to
make many decisions that affect the physical design, some of
which are listed below.
How to translate entities into physical tables
What attributes to use for columns of the physical tables
Which columns of the tables to define as keys
> CHANGE, EVERYDAY
Physical design
What indexes to define on the tables
What views to define on the tables
How to denormalize the tables
How to resolve many-to-many relationships
What designs can take advantage of hash access
Physical design is the time when you abbreviate the names that
you chose during logical design. For example, you can abbreviate
the column name that identifies employees, EMPLOYEE_NUMBER,
to EMPNO. In Db2 for z/OS®, you need to abbreviate column
names and table names to fit the physical constraint of a 30-byte
maximum for column names and a 128-byte maximum for table
names. For more information about the conventions and rules for
database object names, see Naming conventions and SQL
identifiers. > CHANGE, EVERYDAY
Physical design
The task of building the physical design is a job that truly
never ends. You need to continually monitor the
performance and data integrity characteristics of the
database as time passes. Many factors necessitate periodic
refinements to the physical design.
Db2 lets you change many of the key attributes of your
design with ALTER SQL statements. For example, assume
that you design a partitioned table so that it stores 36
months' worth of data. Later you discover that you need to
extend that design to 84 months' worth of data. You can add
or rotate partitions for the current 36 months to
accommodate the new design.
> CHANGE, EVERYDAY
Physical design
The remainder of this information includes some valuable information that
can help you as you build and refine the physical design of your database.
However, this task generally requires more experience with Db2 than most
readers of this introductory level information are likely to have.
Database design with denormalization
The rules of normalization do not consider performance. In some cases, you
need to consider denormalization to improve performance.
Customized data views
A view offers an alternative way of describing data that exists in one or more
tables.
Database design with indexes
You can use indexes to optimize data access, to ensure uniqueness, and to
enable clustering.
Database design with hash access
You can organize tables for hash access to individual data rows. Hash-
organized table spaces are deprecated and likely to be unsupported in the
> CHANGE, EVERYDAY
future.
Database Design Example
Based on the provided information, you can begin your logical
design and should be able to identify the initial entities:
Poet
Poem
Publication
Sale
Customer
The Poet's Circle is not an entity, or even of instance an
a publisher entity. Only if the system were developed for many
publishers would publisher be a valid entity.

> CHANGE, EVERYDAY

Database Design Example
Neither website nor poetry community are entities. There is
only one website, and anyway, a website is merely a means of
producing data to populate the database. There is also only
one poetry community as far as this system is concerned, and
there is not much you'd want to store about it.
Next, you need to determine the relationship between these
entities. You can identify the following:
A poet can write many poems. The analysis identified the fact
that a poet can be stored in the system even if there are no
associated poems. Poems may be captured at a later point in
time, or the poet may still be a potential poet. Conversely,
many poets could conceivably write a poem, though the poem
must have been written by at least one poet.
> CHANGE, EVERYDAY
Database Design Example
A publication may contain many poems (an anthology) or just one. It can
also contain no poems (poetry criticism for example). A poem may or may
not appear in a publication.
A sale must be for at least one publication, but it may be for many. A
publication may or may not have made any sales.
A customer may be made for many sales, or none at all. A sale is only made
for one and only one customer.
You can identify the following attributes:
Poet: first name, surname, address, email address
Poem: poem title, poem contents
Publication: title, price
Sales: date, amount
Customer: first name, surname, address, email address
> CHANGE, EVERYDAY
Database Design Example
Based on these entities and relationships, you can construct
the entity-relationship diagram shown below:

> CHANGE, EVERYDAY

Database Design Example
There are two many-to-many relationships in the figure above.
These need to be converted into one-to-many relationships
before you can implement them in a DBMS. After doing so, the
intersection entities poem-publication and sale-publication are
created.

> CHANGE, EVERYDAY

Database Design Example
Now, to begin the logical and physical design, you need to add
attributes that can create the relationship between the entities
and specify primary keys. You do what's usually best, and
create new, unique, primary keys. The following tables show
the structures for the tables created from each of the entities:

> CHANGE, EVERYDAY

Database Design Example

> CHANGE, EVERYDAY

Database Design Example

> CHANGE, EVERYDAY

Database Design Example

> CHANGE, EVERYDAY