Conceptual database

design

Group 3:Canaan, Tatenda, Sarah, Shingie, Tsitsi

Conceptual Database
Design
The second phase of database design involves
two parallel activities which are conceptual
schema design and transaction and
application design
Conceptual schema design examines the data
requirements resulting form requirements
collection and analysis and produces a
conceptual database schema
Transaction and application design examines
the database application analysed in
requirements collection and analysis and
Conceptual schema design
The conceptual schema produced by this phase is usually contained in a
DBMS-independent high-level data model for the following reasons:
The goal of conceptual schema design is a complete understanding of
the database structure, meaning (semantics),interrelationships, and
constraints. This is best achieved independently of a specific DBMS
because each DBMS typically has idiosyncrasies and restrictions that
should not be allowed to influence the conceptual schema design.

.The conceptual schema is invaluable as a stable description of the

database contents. The choice of DBMS and later design decisions may
change without changing the DBMS-independent conceptual schema.
Reasons cont.
A good understanding of the conceptual schema is
crucial for database users and application designers.
Use of a high-level data model that is more expressive
and general than the data models of individual DBMSs is
therefore quite important.

.The diagrammatic description of the conceptual schema

can serve as a vehicle of communication among
database users, designers, and analysts.
In this phase of database design, it is
important to use a conceptual high-level
data model with the following
characteristics:
Expressiveness. The data model should be expressive
enough to distinguish different types of
data,relationships,and constraints.
Simplicity and understandability. The model should
be simple enough for typical nonspecialist users to
understand and use its concepts.
Characteristics cont.
Minimality. The model should have a small number of
basic concepts that are distinct and non-overlapping in
meaning.
Diagrammatic representation. The model should
have a diagrammatic notation for displaying a
conceptual schema that is easy to interpret.
Formality. A conceptual schema expressed in the data
model must represent a formal unambiguous
specification of the data.Hence,the model concepts
must be defined accurately and unambiguously.
Approaches to Conceptual Schema
Design
For conceptual schema design, we must identify the
basic components (or constructs) of the schema: the
entity types, relationship types, and attributes
specify key attributes, cardinality and participation
constraints on relationships, weak entity types, and
specialization/ generalization hierarchies
There are two approaches to designing the conceptual
schema,which is derived from the requirements
collected during Phase 1
These are centralized (or one shot) schema design
approach and view integration approach
 Centralized (or one shot) schema
design approach
the requirements of the different applications and user groups
from Phase 1 are merged into a single set of requirements before
schema design begins. A single schema corresponding to the
merged set of requirements is then designed
Once the conceptual schema is designed and finalized, external
schemas for the various user groups and applications can be
specified by the DBA.
reconciliation is done manually by the DBA staff prior to
designing any schemas and is applied directly to the
requirements collected in Phase 1. This places the burden to
reconcile the differences and conflicts among user groups on the
DBA staff.
View integration approach
the requirements are not merged. Rather a schema (or
view) is designed for each user group or application
based only on its own requirement
each user group or application actually designs its own
conceptual (EER) schema from its requirements, with
assistance from the DBA staff. Then an integration
process is applied to these schemas (views) by the DBA
to form the global integrated schema
Strategies for Schema Design
Given a set of requirements, whether for a single user or for a large user
community, we must create a conceptual schema that satisfies these
requirements. Most strategies follow an incremental approachthat is, they
start with some important schema constructs derived from the requirements
and then they incrementally modify,refine,and build on them these Include:
1. Top-down strategy. start with a schema containing high-level
abstractions and then apply successive top-down refinements . The
process of specialization to refine an entity type into subclasses. Eg high
level entity types------- specify their -------lower level entity types -------
specify the relationships
2. Bottom-up strategy. Start with a schema containing basic abstractions
and then combine or add to these abstractions. The process of
generalizing entity types into higher-level generalized superclasses
Strategies cont.
3.Inside-out strategy. This is a special case of a top-down
strategy, where attention is focused on a central set of concepts that
are most evident. Modelling then spreads outward by considering
new concepts in the vicinity of existing ones. We could specify a few
clearly evident entity types in the schema and continue by adding
other entity types and relationships that are related to each.
4 . Mixed strategy. Instead of following any particular strategy
throughout the design, the requirements are partitioned according to
a top-down strategy, and part of the schema is designed for each
partition according to a bottom-up strategy. The various schema
parts are then combined.
Schema (View) Integration
For large databases with many expected users and applications, the view integration
approach of designing individual schemas and then merging them can be used. Because the
individual views can be kept relatively small, design of the schemas is simplified. However, a
methodology for integrating the views into a global database schema is needed. Schema
integration can be divided into the following subtasks:
i. Identifying correspondences and conflicts among the schemas Because the
schemas are designed individually, it is necessary to specify constructs in the schemas
that represent the same real-world concept. These correspondences must be identified
before integration can proceed. During this process, several types of conflicts among the
schemas may be discovered conflicts among the schemas.
a. Naming conflicts. These are of two types: synonyms which occurs when two schemas
use different names to describe the same concept; for example, an entity type
CUSTOMER in one schema may describe the same concept as an entity type CLIENT in
another schema and homonym which occurs when two schemas use the same name
to describe different concepts; for example, an entity type PART may represent computer
parts in one schema and furniture parts in another schema
Continued.
b. Type conflicts. The same concept may be represented in two
schemas by different modelling constructs. For example, the
concept of a DEPARTMENT may be an entity type in one schema
and an attribute in another.
c. Domain (value set) conflicts. An attribute may have different
domains in two schemas. For example, Ssn may be declared as
an integer in one schema and as a character string in the other.
c. Conflicts among constraints. Two schemas may impose
different constraints; for example, the key of an entity type may
be different in each schema.
Schema (View) Integration
continued
ii. Modifying views to conform to one another. Some schemas are
modified so that they conform to other schemas more closely. Some of
the conflicts identified in the first subtask are resolved during this step.
iii. Merging of views. The global schema is created by merging the
individual schemas. Corresponding concepts are represented only
once in the global schema, and mappings between the views and the
global schema are specified.
iv. Restructuring. As a final optional step, the global schema may be
analysed and restructured to remove any redundancies or unnecessary
complexity.
Strategies for the view integration
process
Binary ladder integration. Two schemas that are quite
similar are integrated first. The resulting schema is then
integrated with another schema, and the process is
repeated until all schemas are integrated. The ordering of
schemas for integration can be based on some measure
of schema similarity
N-ary integration. All the views are integrated in one
procedure after an analysis and specification of their
correspondences. This strategy requires computerized
tools for large design problems
* Strategies cont.
Binary balanced strategy. Pairs of schemas are
integrated first, then the resulting schemas are paired
for further integration; this procedure is repeated until a
final global schema results.
Mixed strategy. Initially, the schemas are partitioned
into groups based on their similarity, and each group is
integrated separately. The intermediate schemas are
grouped again and integrated,and so on.
Transaction design
The purpose of transaction design, which proceeds in
parallel with conceptual schema design is to design the
characteristics of known database transactions in a
DBMS independent way
When a database system is being designed the
designers are aware of many known applications that
will run on the database once it is implemented
An important pat of the database design is to specify
functional characteristics of the transactions early in the
design process
This ensures that the schema will include all the
information required by the transactions
Transaction design
In addition, knowing the relative importance of the
various transactions and the expected rates of their
invocation plays a crucial part during the physical
database design
Not all database transactions are known at design time,
after the database system is implemented new
transactions are continuously identifies and
implemented
But the most common transactions are known in
advance of system implementation and should be
specified at an early stage
Transaction design
A common technique for specifying transactions at a
conceptual level is to identify their input/output and
functional behavior. By specifying the input and
output parameters (arguments) and the internal
functional flow of control, designers can specify a
transaction in a conceptual and system-independent
way
Transactions usually can be grouped into 3 categories:
Retrieval transactions(which are used to retrieve data
for display on screen or for printing of a report)
Update transactions(which are used to enter new data
or modify existing data in the database)
Cont.
Mixed transactions(which are used for more complex
applications that do some retrieval and some update)
Several techniques for requirements specification include
notation for specifying processes, which in this context are
more complex operations that can consist of several
transactions
The UML language, which provides for data modeling via
class and object diagrams, has a variety of process
modeling diagrams including state transition diagrams,
activity diagrams, sequence diagrams, and collaboration
diagrams.
Cont.
All these refer to activities, events, and operations
within the information system, the inputs and outputs of
the processes, the sequencing or synchronization
requirements, and other conditions.
It is possible to refine these specifications and extract
individual transactions from them.
Conclusion
Transaction design is just as important as schema
design, but it is often considered to be part of software
engineering rather than database design.
Many current design methodologies emphasize one over
the other. One should go through conceptual schema
design and Transaction design in parallel, using
feedback loops for refinement, until a stable design of
schema and transactions is reached