(Spring 2015)
Instructor: Craig Duckett
Lecture 15: Thursday, May 28, 2015
Visual Studio Walk-Through
1
PHASE 3: DEVELOP DUE TONIGHT Thursday, May 28th , uploaded to Team
Web Site and ZIPPED and uploaded to StudentRacker by Phase 3 Project
Manager
Phase 4: Distribute due Tuesday, June 9th
2
The Team Project
Five Phase Due Dates
•
•
•
•
•
Phase 1: Discovery (200 Points) DUE TUESDAY, APRIL 28
Phase 2: Design (200 Points) DUE TUESDAY, MAY 19
Phase 3: Develop (200 Points) DUE TUESDAY, JUNE 2
Phase 4: Distribute (200 Points) DUE TUESDAY, JUNE 9
Phase 5: Documentation (200 Points) DUE THURSDAY, JUNE 18
3
Today
• Visual Studio Walk-Through
• Building (Non-Working) Prototype Front-Ends (for Screen Capture Only)
4
Database Design for Mere Mortals
Chapter 11 Summary BUSINESS RULES
A Business Rule is a statement that imposes some form of constraint on elements
within a field specification for a particular field or on characteristics of a relationship
between a specific pair of tables. The following statement is an example of a typical
business rule:
A SHIP DATE cannot be prior to an ORDER DATE for any given order.
Types of Business Rules
There are two major types of Business Rules: database-oriented and application
oriented.
Database Design for Mere Mortals
Chapter 11 Summary BUSINESS RULES
Database-oriented Business Rules are those that impose constraints that can be
established within the logical design of the database.
EXAMPLE: You have a VENDORS table and define the following business rule for the
VENDSTATE field in that table:
We conduct business exclusively with vendors from the Pacific Northwest.
This business rule limits the values that you can enter into the VENDSTATE field to WA,
OR, ID, and MT. You can establish the business rule's constraint in a meaningful
manner by modifying the Range of Values element in the field specifications for the
VENDSTATE field.
Database Design for Mere Mortals
Chapter 11 Summary BUSINESS RULES
Application-oriented Business Rules are statements that impose constraints that
cannot be established by modifying a Field Specification or relationship diagram; they
must be established within the physical design of the database or within the design of
a database application.
Here is an example of a typical application oriented business rule:
A customer with a "Preferred" status receives a 15% discount on all purchases.
This business rule determines the amount of discount applied to a customer's
purchases, based on a particular status. You cannot establish this constraint
meaningfully in the logical design for two reasons: There is no field in which to store
the discount amount (the amount is a result of a calculation, and calculated fields are
not allowed in a table), and there is no way to indicate the criterion used the
customer's status to determine the discount. This is a rule that you must establish
within the physical design of the database or the design of the database application.
Database Design for Mere Mortals
Chapter 11 Summary BUSINESS RULES
Categories of Business Rules
Field-Specific Business Rules: Business Rules under this category impose
constraints on the elements of a Field Specification for a particular field.
Relationship-Specific Business Rules: Constraints imposed by relationship specific
business rules affect the characteristics of a relationship between a
particular pair of tables..
Database Design for Mere Mortals
Chapter 11 Summary BUSINESS RULES
Defining and Establishing Business Rules
These rules are based on the manner in which your organization perceives and uses its
data, which will depend on the way the organization functions. You’ll need to work with
users and management to define and establish the appropriate Business Rules.
Field-Specific Business Rules
•
•
•
•
•
•
Select a table.
Review each field and determine whether you need to impose any constraints on it.
Define the necessary Business Rules for the field.
Establish the rules by modifying the appropriate Field Specification elements.
Determine what actions test the rule.
Record the rule on a Business Rule Specification sheet.
Database Design for Mere Mortals
Chapter 11 Summary BUSINESS RULES
Field-Specific Business Rules
This rule only affects one element:
Order dates are to be displayed in long form, such as "January 10, 2003."
This rule affects the Display Format element of the ORDER DATE field in an ORDERS table.
You establish this rule by modifying the Display Format element of the field specifications
for the ORDER DATE field to indicate the manner in which the date should be displayed.
Database Design for Mere Mortals
Chapter 11 Summary BUSINESS RULES
Field-Specific Business Rules
Here's a rule that affects more than one element:
We must be able to store a zip code for our Canadian customers.
This rule affects the Data Type, Character Support, and Display Format elements of the field
specifications for the CUSTZIPCODE field in a CUSTOMERS table. Canadian zip codes include
letters, so you must make the following modifications to these elements in order to impose
the constraints defined by this rule:
•
•
•
Change the Data Type setting to "Alphanumeric."
Include "Letters" under the Character Support element.
Modify the Display Format element to ensure that the letters in Canadian zip codes will be
capitalized.
Database Design for Mere Mortals
Chapter 11 Summary BUSINESS RULES
Defining and Establishing Business Rules
Establishing Relationship-Specific Business Rules
•
•
•
•
•
•
Select a pair of tables that share a relationship.
Review each relationship characteristic and determine whether a constraint is warranted by the
way the organization functions.
Define the necessary Business Rule.
Establish the rule by modifying the relationship characteristics.
Determine what actions will test the rule.
Record the rule on the Business Rule Specification sheet.
Database Design for Mere Mortals
Chapter 11 Summary BUSINESS RULES
Validation Tables
A validation table holds data specifically used to implement data integrity.
There are instances where a rule affects the range of values for a particular field. It
commonly limits the range of values to a specific set of valid entries. In many cases, the
set of values is made up of a relatively fixed number of entries with values that will rarely
change. These entries can be stored in a validation table.
Business Rules: Another Look
How Do Business Rules Affect the Database?
Business rules start out as simple business processes that evolve over time through the implementation of an
organization’s policies and operational procedures.
With an organization’s decision to design a database with which to automate tasks and maintain data,
interviews are eventually administered by elected individuals of the development team who attempt to extract
as much information from the data users as possible. A great deal of this information includes business rules, in
addition to business processes and data.
Without the existence of business rules, there would be a total lack of control. Processes would exist with no
direction for the management of data.
Without rules, users would be walking around aimlessly like zombies, working with data that would eventually
lose all meaning, after progressively deteriorating into complete junk with no apparent use to the organization.
Business rules are the glue that holds an organization’s data together. This is why it is so important to ensure
that business rules are carried over into table design from the logical model. When this far in the design game,
it is no time to compromise the database objectives as set forth in the beginning.
Business Rules: Another Look
During database design, business rules are primarily integrated through the use of database constraints.
Technically speaking, database constraints consist of the following:
• Primary keys
• Foreign keys
• Unique constraints
• Check constraints
• Data types
• Data precision and scale
• NULL/NOT NULL
Most of these constraints were discussed previously. In review, a primary key is a value that’s used to uniquely
identify every row of data in a table. Primary keys are implemented at the table level. A primary key constraint
is created to enforce the concept of row-level uniqueness based on a column value.
A foreign key is a child value that references a parent value in another table. A foreign key constraint ensures
that a foreign key references a primary key. Primary and foreign keys are the basis for referential integrity, and
their use in collaboration with one another is discussed in more detail in this chapter.
Referential integrity is the concept of managing parent
and child records in the database to ensure data
consistency. Primary and foreign keys are the basis for
the implementation of referential integrity.
Business Rules: Another Look
Only one primary key may exist per table, although a primary key might consist of a combination of two or
more columns.
A unique constraint can be specified for a non-primary key column to ensure that all values in the column are
unique.
For instance, if the social security number for employees is stored, a unique constraint would be appropriate on
the SSN column. A telephone company might apply a unique constraint to the PHONE_NUMBER column
because all customers must have unique telephone numbers.
A check constraint may be defined for a column to ensure that the value inserted into the column for a row of
data matches one of the specified values, as listed in the check constraint.
For example, a check constraint may be added to the GENDER column of the EMPLOYEES table to ensure that a
value of either MALE or FEMALE is entered into the column. Whereas check constraints may be used to
validate values based on a static list, a validation table may be used to validate values based on those that
reside in the table.
Business Rules: Another Look
Using Validation Tables to Enforce Business Rules
Validation tables are used mainly for two purposes (both of which work hand in hand with one
another):
• To ensure data consistency through validation
• As a code table to reduce data redundancy
Validation tables can be referenced as follows:
• Using a foreign key constraint
• Using a trigger or stored procedure
• Embedded in application code
Business Rules: Another Look
The following simple example makes use of two validation tables, called STATE_CODES and DEPARTMENTS,
through the use of foreign key constraints that are defined in the EMPLOYEES table:
CREATE TABLE EMPLOYEES
(
EMP_ID int NOT NULL,
L_NAME varchar(20) NOT NULL,
F_NAME varchar(20) NOT NULL,
ADDRESS varchar(30) NOT NULL,
CITY varchar(30) NOT NULL,
STATE varchar(2) NOT NULL,
ZIP varchar(5) NOT NULL,
DEPT_ID int NOT NULL
);
CREATE TABLE STATE_CODES
(
STATE varchar(2) NOT NULL,
STATE_NM varchar(30) NOT NULL
);
CREATE TABLE DEPARTMENTS
(
DEPT_ID int NOT NULL,
DEPT_NM varchar(30) NOT NULL
);
ALTER TABLE EMPLOYEES ADD CONSTRAINT EMPLOYEES_STATE_FK
FOREIGN KEY (STATE) REFERENCES STATE_CODES (STATE);
ALTER TABLE EMPLOYEES ADD CONSTRAINT EMPLOYEES_DEPT_ID_FK
FOREIGN KEY (DEPT_ID) REFERENCES DEPARTMENTS (DEPT_ID);
Using this logic, a user must enter valid values for STATE and DEPT_ID when creating a new employee record.
An error will be returned upon insertion if at least one of the values entered for the two columns does not
match a primary key value in the parent validation tables.
VISUAL STUDIO WALK-THROUGH
SEE: ICE 15 WALK-THROUGH DOC
19