Database Reference
In-Depth Information
Backward Engineering. This feature is the converse of forward engineering.
Assume that your new database system includes data already part of some earlier
databases in the organization. The database designers and analysts need to get
details of the data structure in the older databases. They can get the physical schema
of those databases and transform back into generic logical data model. The back-
ward engineering feature of CASE tools accomplishes this.
Let us summarize the major benefits of CASE tools:
Provide data modelers with toolbox capabilities to create the semantic data
model with utmost ease.
Provide adequate documentation for use by database analysts and developers
to communicate among themselves and with users.
Give a simple, clear picture of the information requirements in the form of a
semantic data model diagram.
Provide forward engineering feature, greatly reducing the effort of the data-
base administrator in defining the physical schema.
Documentation Outline
When a logical design document is issued, you arrive at the conclusion of the logical
design step in the database development life cycle. Therefore, it is important that
the results of all the steps leading up to the finish of the logical design process are
reviewed and confirmed with key users. The issuance of the logical design document
marks the beginning of the physical design and leads into the concluding phases of
implementation and ongoing maintenance.
Here is a suggested outline for the logical design document. Review the outline,
amend it, and adapt it for your specific database project.
Introduction. State the overall scope and content of the logical design step.
Include an executive summary.
Semantic data modeling technique. Describe the data modeling technique
adopted—object-based or entity-relationship modeling or any other.
CASE tool features. If a CASE tool is used for the logical design, highlight the
important features of the tool and its use in the logical design.
Partial semantic data models. List the partial data models. Describe why and how
the real-world information requirements are separated out for partial data
modeling.
Consolidated semantic data model. Include the consolidated data model
diagram. Include descriptions of the various components.
Relational schema of logical model. Include the schema definition of the logical
data model.
Data views. Derive and present the subschemas for all the data views of indi-
vidual user groups.
Physical data model. If you use a CASE tool and are able to forward engineer,
include the physical data model.
Special issues. List any special issues, considerations, and assumptions.
Search WWH ::




Custom Search