DESIGN REVIEWS

CH6
 01 Design Review

02 Types of design review

AGENDA
03 Design review output

04 additional consideration

3/23/2024 2
WHAT IS A DESIGN
REVIEW?
SOME OF THE AREAS THAT CAN BE ADDRESSED

A validation of the A review and analysis

An assessment of the An assessment of the
intent and purpose of of the physical DBMS
logical data model physical data model
the application parameters

A judgment on the
An analysis of overall
practicality of the
A prediction of SQL performance after
programming
performance production
language techniques
implementation
deployed
RULES OF ENGAGEMENT

A design review is conducted by a group of people—each having different

backgrounds, skills, expectations, and opinions

• Each participant must possess the ability to discuss and reach consensus
• Viewing negative criticism as a personal attack
• blog citations, and experience
• back up assertions and suggestions with facts, manual references
DESIGN REVIEW PARTICIPANTS

make sure that

create formal participants
roles possess the
appropriate skills
CREATE FORMAL ROLES

the
Leader Scribe Mediator
participants
THE LEADER
design review have only one leader of a single design review

• Acts as a master of ceremonies to keep the review process moving along

• Creates and follows an agenda to ensure that all aspects of the current design
review are conducted satisfactorily
• Solicits input from all participants
• Ensures that all participants maintain proper decorum
• Works with the participants before the meeting to ensure that all required
documentation will be available
• Addresses other tasks as necessary to ensure a successful design review

The DBA typically acts as the leader of design reviews for applications using a database.
THE SCRIBE

• capture all points of discussion during the design review

• understanding the technical discussion but need not have a technical position

The scribe could be a member of the development team who has good writing and
listening skills
THE MEDIATOR
The mediator is an optional role

• negotiate settlements when disagreements occur, and given the nature of a design
review
THE PARTICIPANTS
The participants will differ from project to project, and from one design review to the
next

• Design review participants consist of the other actors with a stake in the project
• The scope of each design review should be determined prior to the scheduling of
the review so that only the appropriate participants are invited
THE PARTICIPANTS EX.

Representatives from
Application
other applications that Database
development personnel Data administration Representative end
are affected by the administration
assigned to this representative users
new application or representative
development effort
program

Online support
IT management for the
representatives for Web support personnel
new application and Operational support
End user management transaction processing for Internet-enabled
possibly other impacted representatives
and message queuing applications
applications
systems

IT audit representative
Technical support and
IT security (for regulated and …………………..and
systems programming
representative sensitive applications more
representatives
and data)
KNOWLEDGE AND SKILLS REQUIRED

STRONG TECHNICAL SKILLS: STRONG GOOD INTERPERSONAL DBMS FUNDAMENTALS: ALL

TECHNICIANS, COMMUNICATION SKILLS: SKILLS: ALL PARTICIPANTS PARTICIPANTS TO THE
PROGRAMMERS, AND DBAS ALL PARTICIPANTS DEGREE REQUIRED BY THEIR
POSITIONS
TYPES OF DESIGN REVIEWS

Conceptual design Logical design Physical design

review review review

SQL and
Organizational Pre-implementation
application code
design review design review
review

Post-implementation
design review
CONCEPTUAL DESIGN REVIEW

The conceptual design review

begins with a presentation of
The first review to be The purpose of this review is an overall statement of
conducted is the conceptual to validate the concept of the purpose and a general
design review. database and application. overview of the desired
functionality to be provided
by the application.

The findings of the conceptual

The conceptual design review
review must verify the
should be conducted as early
purpose of the application
as possible in the application
and the clarity of the vision
development lifecycle to
for building the databases
determine the overall
and supporting application
feasibility of the project.
programs.
FAILURE TO CONDUCT A CONCEPTUAL DESIGN
REVIEW CAN RESULT IN

01 02 03 04
Projects that provide Cancellation of projects Projects that run Applications that do not
duplicate or inadequate due to lack of funds, over-budget or take deliver the required
functionality inadequate staffing, longer to complete than features and
poor planning, lack of anticipated functionality to support
user participation, or the business
waning management
interest
CONCEPTUAL DESIGN REVIEW TEAM

data administration

database administration staff

end users

management representatives from the end user team and IT.

LOGICAL DESIGN REVIEW

THE LOGICAL DESIGN IT SHOULD BE CONDUCTED A THOROUGH REVIEW OF ALL

REVIEW FOLLOWS THE WHEN THE FIRST CUT OF THE DATA ELEMENTS,
CONCEPTUAL DESIGN LOGICAL DATA MODEL HAS DESCRIPTIONS, AND
REVIEW. BEEN COMPLETED. RELATIONSHIPS SHOULD
OCCUR DURING THIS REVIEW.
(LOGICAL DESIGN REVIEW) CONT

Has the logical data model been thoroughly examined to ensure that all of the required •
?business functionality can be achieved

?Is the model in (at least) third normal form •

Have all of the data elements (entities and attributes) required for this application been •
?identified

?Have the data elements that have been identified been documented accurately •

?Have appropriate data types and accurate lengths been assigned for each attribute •

?Have all of the relationships been defined properly •

THE RISK OF FAILING TO CONDUCT A LOGICAL
DESIGN REVIEW
• Misaligned design: Without a logical design review, there is a higher
risk that the logical architecture of the system will not align with the
functional requirements and specifications. This can result in a system
that does not meet the intended purpose, is difficult to use, or is
inefficient.
• Inefficient system: A poorly designed logical architecture can lead to
an inefficient system, which can negatively impact the performance
and usability of the system. This can result in slower response times,
increased downtime, and reduced user satisfaction.
THE RISK OF FAILING TO CONDUCT A LOGICAL
DESIGN REVIEW
Higher maintenance costs: If the logical design is not reviewed and •
optimized, it can lead to increased maintenance costs over time. For
example, if the logical design leads to complex or inefficient code, it may be
more difficult and time-consuming to maintain, troubleshoot, and update the
.system

Security vulnerabilities: A poorly designed logical architecture can create •

security vulnerabilities in the system. For example, if the design does not
properly account for access control or data encryption, it can make the
.system more vulnerable to cyber attacks or data breaches 3/23/2024 21
LOGICAL DESIGN REVIEW
TEAM

• Participants in the logical design

review should be the same as
participated in the conceptual
design review.
.

PHYSICAL DESIGN REVIEW

• The physical design review comes next—it's the review most often
associated with the design review process.
• In the physical design review, the database is reviewed in detail to ensure
that all of the proper database parameter settings and other physical design
choices have been made.
• In addition, the DA and DBA should ensure that a proper translation from
logical model to physical database has been made and that all
denormalization decisions are formally documented
PHYSICAL DESIGN REVIEW

• The overall operating environment for the application should be described and
verified at this stage.
• The choice of transaction processor and a complete description of the online
environment should be provided and verified.
• An estimation of workload, throughput, and number of concurrent users should be
provided and reviewed to ensure that the anticipated requirements can be
satisfied.
• Batch workload should also be reviewed; therefore, a complete description of any
batch processes must be provided.
PHYSICAL DESIGN REVIEW TEAM

• application development staff.

• data administration staff.
• online support representatives.
• technical support personnel.
• If the application or database will affect other applications, or be used by
other applications, then it would be wise to include representatives from
those areas as well.
:ORGANIZATIONAL DESIGN REVIEW

Also called Organizational structure, it is a methodology that identify

aspects of workflow, production and system within company, so it allow
businesses to re-evaluate their practices and find better and more
effective way to achieve company’s goals.
ORGANIZATIONAL DESIGN REVIEW ELEMENTS

1. Work Specialization: is a process that assigns each professional to a specific task.

2. Departmentalization and compartments: Departments and compartments are
teams of professionals within a larger company. Compartments refer to teams of
professionals who each are from a different career path and specialty.
Departments refer to groups of professionals of a similar skill set within a
company.

3. Formalization of elements: Formalization specifies the relationships and roles

within a company.
 1. Work Specialization
2. Departmentalization and compartments.
3. Formalization of elements.
ORGANIZATIONAL 4. Centralization and decentralization.
DESIGN REVIEW
ELEMENTS 5. Span of control.
6. The chain of command of a company describes the
business
A SQL AND APPLICATION CODE DESIGN REVIEW

• is a process of evaluating the design and implementation of SQL

queries and application code in a software system. The review is
conducted to identify potential issues or areas of improvement in the
design and implementation of the system
?HOW DOES THE TEAM WORK

• During a SQL and application code design review,

• A team of developers or software engineers will typically examine the SQL queries used by
the application to retrieve data from a database.
• They will evaluate the efficiency and effectiveness of the queries, looking for ways to
optimize them for performance and scalability.
• In addition to reviewing SQL queries, the team will also examine the application code that
interacts with the database.
• They will look for issues such as inefficient algorithms, poor error handling, and security
vulnerabilities.
PRE-IMPLEMENTATION DESIGN REVIEW

• Pre-Implementation Design Review - an overall appraisal of the system

components prior to implementation;

• A pre-implementation design review is a process of evaluating the

proposed design of a system or product before it is implemented. The
purpose of this review is to identify any potential issues, risks, or
limitations in the design and to ensure that it meets the requirements
and specifications of the project.
PRE-IMPLEMENTATION DESIGN REVIEW STEPS

Reviewing Analyzing the Testing the design Providing Approving the

the design design feedback design
documentation
IMPORTANT OF PRE-IMPLEMENTATION DESIGN
REVIEW
• By conducting a pre-implementation design review, the project team can ensure that the
system or product design meets the project requirements and specifications, is free of
defects and errors, and is ready for implementation. This can help to reduce the risk
of project delays, cost overruns, and other issues that can arise during the implementation
phase.
PRACTICES FOR CONDUCTING A
PRE-IMPLEMENTATION DESIGN REVIEW

Use
Establish clear Involve key Focus on Test the
a structured
objectives stakeholders critical areas: design
approach

Document Conduct
Learn from
feedback and Follow up multiple
past reviews
changes: reviews
POST-IMPLEMENTATION DESIGN REVIEW

• Post-Implementation Design Review - formally review the application and database once it
has run in production for awhile to determine if the application is meeting its objectives.

• A post-implementation design review is a process of evaluating the design of a system or

product after it has been implemented. The purpose of this review is to identify any issues,
gaps, or limitations in the design that may have surfaced during the implementation phase
and to determine if the design meets the desired outcomes and objectives.
POST-IMPLEMENTATION DESIGN REVIEW STEPS

1. Reviewing the implemented system or product:

2. Analyzing the performance of the system or product
3. Identifying any issues or gaps
4. Evaluating the design against the requirements
5. Suggesting improvements
6. Documenting the review
IMPORTANT OF POST-IMPLEMENTATION DESIGN REVIEW

• By conducting a post-implementation design review, the project team can ensure that the
design meets the desired outcomes and objectives and is optimized for performance,
reliability, scalability, and maintainability. This can help to improve the overall quality of the
system or product and reduce the risk of issues or limitations arising in the future.
 PRACTICES FOR CONDUCTING A POST-IMPLEMENTATION DESIGN
REVIEW

1. Establish clear objectives.

2. Involve key stakeholders.
3. Use a structured approach.
4. Collect and analyze data.
5. Solicit feedback.
6. Identify issues and gaps.
7. Evaluate against requirements.
8. Suggest improvements.
9. Document findings.
10. Follow up.
DESIGN REVIEW OUTPUT

• Output from reviews should be clear and concise so that any required application, SQL, or database modifications can
be made quickly and correctly.

• It is imperative that the scribe capture notes in sufficient detail that a non-attendee can make sense of the discussion.

• The scribe should edit the notes for grammar and spelling and distribute a copy to all attendees (preferably by e-mail).

• An additional result of each design review is a separate list of action items.

i. This list should contain every modification or change discussed during the design review.

ii. Each action item should be given a deadline and be assigned to a single person, giving that person the
responsibility to make the change, test its impact, and report the progress back to the entire group.
ADDITIONAL CONSIDERATIONS

• There are additional considerations and issues that you will need to deal with as you prepare and conduct your
database design reviews.

• You must be prepared to adapt to changing situations and personnel, as well as to the needs of your organization.

• In this section two additional design review considerations are addressed.

i. The first one is how to overcome a potential pitfall: working with a geographically dispersed staff.

ii. The second issue is more of an opportunity: using design reviews to mentor junior staff members.
DEALING WITH REMOTE STAFF
• In some cases organizations have distributed workforces where DBAs and development staff are not located at the
same site.

• When staff members are remote, the design review process becomes an even more critical piece of the
development project because it forces communication between resources that are not able to interact on a daily
basis.

• Of course, a distributed staff also complicates the design review. Although it is possible to fly team members to a
single location to participate in design reviews, it is rarely cost-effective.

• Instead of bringing every participant into the same room to conduct the review, a conference call,
videoconference, or Web-enabled meeting (such as Live Meeting ) can be set up.

• In such cases it is important that materials be available well in advance of the meeting so that each participant can
review the content beforehand.
MENTORSHIP AND KNOWLEDGE TRANSFER
• Design reviews meetings can be a great opportunity for mentoring junior staff members , The meetings should be
attended by senior technicians, many with teaching abilities.

By inviting junior technicians to the meeting, you potentially can transfer knowledge cost-effectively and efficiently.

• Be sure, though, not to turn the meetings into purely education sessions.

Furthermore, do not let the junior personnel derail the meeting with endless questions or let the senior personnel use
the meeting as a soapbox.

• The purpose of the design review is to ensure the viability of the new application and database for the organization.
Usually it is possible to do a little mentorship at the same time.
THANKS