(Winter 2016) Instructor: Craig Duckett Lecture 15: Thursday, February 25 th Visual Studio Walk-Through 1

2 PHASE 3: DEVELOP DUE Tuesday, March 1 st, uploaded to Team Web Site and ZIPPED and uploaded to StudentTracker by Phase 3 Project Manager Phase 4: Distribute due Thursday, March 10 th

3 The Team Project Five Phase Due Dates One (1) Team Project for a Client (3-to-4 Members on Team) 1000 points Total Phase 1: Discovery (200 Points) GRADED! Phase 2: Design (200 Points) GRADED! Phase 3: Develop (200 Points) DUE TUESDAY, MARCH 1 st Phase 4: Distribute (200 Points) DUE THURSDAY, MARCH 10 th Phase 5: Documentation (200 Points) DUE THURSDAY, MARCH 17 th (Last Day of Class)

4 Today Visual Studio Walk-Through Building (Non-Working) Prototype Front-Ends (for Screen Capture Only)

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 ); 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. 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 );

19 VISUAL STUDIO WALK-THROUGH SEE: ICE 15 WALK-THROUGH DOC