Scribd
Upload
2K views4 pages

Database Design Strategies

There are two approaches to database design: top-down which identifies data sets then defines data elements, and bottom-up which identifies data elements then groups them into sets. The selection depends on the scope and size of the database. Database design can also be centralized, with a single designer, or decentralized, using multiple designers for large complex databases. Decentralized design divides the task into modules which are later integrated into a single conceptual model, addressing issues like synonyms and conflicting definitions.

Uploaded by

Mohamed Farook Mohamed Fazrin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
2K views4 pages

Database Design Strategies

There are two approaches to database design: top-down which identifies data sets then defines data elements, and bottom-up which identifies data elements then groups them into sets. The selection depends on the scope and size of the database. Database design can also be centralized, with a single designer, or decentralized, using multiple designers for large complex databases. Decentralized design divides the task into modules which are later integrated into a single conceptual model, addressing issues like synonyms and conflicting definitions.

Uploaded by

Mohamed Farook Mohamed Fazrin
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

DATABASE DESIGN STRATEGIES:

There are two classical approaches to database design:


 Top-down design starts by identifying the data sets and then defines
the data elements for each of those sets. This process involves the
identification of different entity types and the definition of each entity’s
attributes.
 Bottom-up design first identifies the data elements (items) and then
groups them together in data sets. In other words, it first defines
attributes, and then groups them to form entities.

The two approaches are illustrated in the following Figure:

Top-down vs. bottom-up design sequencing

The selection of a primary emphasis on top-down or bottom-up procedures


often depends on the scope of the problem or on personal preferences.
Although the two methodologies are complementary rather than mutually
exclusive, a primary emphasis on a bottom-up approach may be more
productive for small databases with few entities, attributes, relations, and
transactions. For situations in which the number, variety, and complexity of
entities, relations, and transactions is overwhelming, a primarily top-down
approach may be more easily managed.

CENTRALIZED VS. DECENTRALIZED DESIGN:

The two general approaches (bottom-up and top-down) to database design


can be influenced by factors such as the scope and size of the system, the
company’s management style, and the company’s structure (centralized or
decentralized). Depending on such factors, the database design may be
based on two very different design philosophies: centralized and
decentralized.
Centralized design is productive when the data component is composed of
a relatively small number of objects and procedures. The design can be
carried out and represented in a fairly simple database. Centralized design is
typical of relatively simple and/or small databases and can be successfully
done by a single person (database administrator) or by a small, informal
design team. The company operations and the scope of the problem are
sufficiently limited to allow even a single designer to define the problem(s),
create the conceptual design, verify the conceptual design with the user
views, define system processes and data constraints to ensure the efficacy
of the design, and ensure that the design will comply with all the
requirements. The following figure summarizes the centralized design option.
Note that a single conceptual design is completed and then validated in the
centralized design approach.

Centralized design

Decentralized design might be used when the data component of the


system has a considerable number of entities and complex relations on
which very complex operations are performed. Decentralized design is also
likely to be employed when the problem itself is spread across several
operational sites and each element is a subset of the entire data set.
Consider the following diagram.
Decentralized design

In large and complex projects, the database design typically cannot be done
by only one person. Instead, a carefully selected team of database designers
is employed to tackle a complex database project. Within the decentralized
design framework, the database design task is divided into several modules.
Once the design criteria have been established, the lead designer assigns
design subsets or modules to design groups within the team. Each design
group creates a conceptual data model corresponding to the subset being
modeled. Each conceptual model is then verified individually against the user
views, processes, and constraints for each of the modules. After the
verification process has been completed, all modules are integrated into one
conceptual model. Naturally, after the subsets have been aggregated into a
larger conceptual model, the lead designer must verify that the combined
conceptual model is still able to support all of the required transactions.

Keep in mind that the aggregation process requires the designer to create a
single model in which various aggregation problems must be addressed.

 Synonyms and homonyms. Various departments might know the same


object by different names (synonyms), or they might use the same
name to address different objects (homonyms). The object can be an
entity, an attribute, or a relationship.
 Entity and entity subtypes. An entity subtype might be viewed as a
separate entity by one or more departments. The designer must
integrate such subtypes into a higher-level entity.
 Conflicting object definitions. Attributes can be recorded as different
types (character, numeric), or different domains can be defined for the
same attribute. Constraint definitions, too, can vary. The designer
must remove such conflicts from the model.

You might also like