Menu Design, Screen Design

Menu Design, Screen Design,
Performance Analysis, and Process

Modeling
Initial Menu Structure from a Data Model
• We saw that entity dependency analysis which uses business rules,
represented as data model associations, to derive cluster.
• Each cluster becomes a separately implementable subproject,
• These clusters also provide insight into the likely menu structure.
Simple Menu Structure Design for Person
Skill
Tabbed Menu Structure Design for Project
Resource Management
Preliminary Screen Designs from a Data
Model
• We can also gain some insight into preliminary screen designs from an
examination of data model entities, associations, and data attributes.
• We defined the data attributes that are needed in each data entity to
represent the current and future business needs.
• These data attributes are implemented as data fields in screen
designs. The design of screens is part of the presentation interface.
Model
• Following the definition of attributes in the logical data model, each
entity is later implemented as a separate table when installed as part
of a physical database.
• The attributes within the entity become columns of the table and the
entity occurrences become rows of that table.
• When the table is later used in production, its values will change
during processing.
• Data maintenance changes needed to keep each column and row
value up to date require create, read, update, and delete (CRUD)
processing. Screen designs for this CRUD processing
Model
• Two typical screen designs are derived from a logical entity
definition: a columnar screen or a tabular data grid screen.
• A columnar screen design shows the attributes of a single
entity occurrence (implemented as columns of a single row
of a table) as data fields, listed under each other on the
screen.
• A tabular data grid screen shows occurrences of the entity in
a spreadsheet format as rows, with the attributes as columns
of the spreadsheet grid.
Typical Screen Design for One-to-Many Associations
Database Capacity Planning and Transaction Performance
• This physical database design is typically generated automatically by a

modeling tool.
• These tools are also used to automatically generate the DDL scripts
that are needed for database installation in [C1R5].
Database Capacity Planning from a
Logical Data Model
Database Capacity Planning and
Transaction Performance
• As part of logical data modeling in [C1R3], the logical data type of
each attribute is defined.
• This definition is typically carried out automatically by the modeling
tool, based on logical data type to physical data type transformation
rules specified by the data modeler, or the DBA.
• This physical data type specification also indicates the actual number
of bytes needed to implement each column.
• Based on the physical row structure and format used by the target
DBMS, the length of each row of a table can be calculated.
• This is the sum of the actual number of bytes needed to implement
each physical column in that table.
• A spreadsheet is used to carry out these calculations, multiplying the
calculated row length by the data volume of the table, expressed as
row occurrences as shown in Figure 10.10.
• The result is the total number of bytes needed to store each physical
table. For capacity planning, the total database size is thus the sum of
the size of each physical table in the database.
• The same spreadsheet can also be used to calculate the frequency of
occurrence along each association.
• This is based on the respective data volumes for the two entities
joined by the association. For example, we discussed earlier that
there are an average of (10) Job Skills for each Job and an average of
(20) Job Skills for each Skill [3].
• Additionally, if minimum and maximum data volume row occurrences

are available, the same calculation can be used to determine
minimum and maximum association frequencies of occurrence.
Logical Transaction Performance Analysis
• For each Job, first identify all of the Job Skills required by that Job.
• For each of these Skills, next identify each Employee who has the
relevant Skills and determine each Employee’s name.
• The resolution of this query requires a number of logical accesses to
the data map that is shown in Figure 10.11. Each logical access will be
calculated in the following pages as physical I/O accesses for
transaction performance analysis, when the data model is later
implemented as a physical database.
Prototyping from a Data Model
Menu Design and Screen Design from the
Order Entry Data Map

Menu Design, Screen Design

Uploaded by

Copyright:

Available Formats

Menu Design, Screen Design

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Menu Design, Screen Design

Uploaded by

Copyright:

Available Formats

Menu Design, Screen Design,

Performance Analysis, and Process

• This physical database design is typically generated automatically by a

• Additionally, if minimum and maximum data volume row occurrences

You might also like