Embed Size (px)
Citation preview
State Farm Insurance: Team Management
Nick Toothman
Computer Science 342: Database SystemsProf. H. Wang
11.26.2008
Table of Contents
Phase I: Information Gathering and E-R Modeling......................................................5
Techniques used.........................................................................................................5
Introduction to Enterprise/Organization.....................................................................6
Structure of the Enterprise.........................................................................................6
Itemized Description of Major Objects........................................................................6
Data Views and Operations for User Groups..............................................................7
Entity Set Description.................................................................................................8
Employee................................................................................................................8
Team.......................................................................................................................9
Skills......................................................................................................................10
TypeOfWork...........................................................................................................11
Relationship Set Description.....................................................................................12
Team_History:.......................................................................................................12
Possesses:.............................................................................................................12
Requires:...............................................................................................................12
Focuses_On:..........................................................................................................12
Related Entity Set:................................................................................................13
E-R Diagram.............................................................................................................14
Phase II: Relational model........................................................................................15
E-R model and the relational model.........................................................................15
Description...............................................................................................................15
Comparison..............................................................................................................15
Conversion from E-R model to relational model.......................................................15
Constraints...............................................................................................................16
E-R database to relational database.........................................................................17
Employee relation.................................................................................................17
Team relation........................................................................................................17
Skills relation.........................................................................................................18
TypeOfWork relation.............................................................................................18
Team_History relation...........................................................................................19
Possesses relation.................................................................................................19
Requires relation...................................................................................................20
Focuses_On relation..............................................................................................20
Relation Instances....................................................................................................21
Employee(UserID, UserName, FullName, OfficeExtension, Location, Belongs_To). . .21
Team(TeamID, Name, Description, Location, Manager)...........................................21
Team_History(UserID, TeamID, StartDate, EndDate)................................................22
Skills(SkillID, Name, Description)..............................................................................22
Possesses(UserID, SkillID)........................................................................................23
TypeOfWork(TOWID, Name, Description).................................................................24
Requires(TOWID, SkillID)..........................................................................................25
Focuses_On(TeamID, TOWID)...................................................................................26
Queries.....................................................................................................................27
Query Representation..............................................................................................27
Phase III: Implementation of the relational database...............................................30
SQL*PLUS.................................................................................................................30
Schema Objects in Oracle........................................................................................30
Tables..........................................................................................................30
Views...........................................................................................................30
Dimensions..................................................................................................31
Sequences...................................................................................................31
Synonyms....................................................................................................31
Indexes........................................................................................................31
Database Links............................................................................................31
Stored procedures and functions.................................................................31
Packages......................................................................................................31
Schema objects in this project..................................................................................32
nt_employee.............................................................................................................33
nt_team....................................................................................................................34
nt_teamhistory.........................................................................................................34
nt_skills.....................................................................................................................35
nt_tow.......................................................................................................................36
nt_possesses............................................................................................................36
nt_requires...............................................................................................................37
nt_focuseson............................................................................................................38
SQL Queries..............................................................................................................39
Phase IV: Stored Procedures.....................................................................................42
Common Features in Oracle PL/SQL and Microsoft Transact-SQL.............................42
Oracle PL/SQL...........................................................................................................42
Oracle PL/SQL Subprograms.....................................................................................46
Stored procedures.................................................................................................46
Functions...............................................................................................................47
Triggers.................................................................................................................48
Daily user activities..................................................................................................50
Relations, views, and subprograms..........................................................................50
Application screen shots...........................................................................................51
Menu.....................................................................................................................51
Main...................................................................................................................51
Teams................................................................................................................52
Skills and Types of Work....................................................................................52
Main form..............................................................................................................54
Code Description and GUI Design.............................................................................55
User interface design............................................................................................55
Data access descriptions.......................................................................................56
Class descriptions..................................................................................................57
Major features.......................................................................................................59
Development process...............................................................................................59
Designing and implementing the application........................................................60
Conclusion................................................................................................................60
Phase I: Information Gathering and E-R Modeling
Fact-Finding TechniquesThe purpose of fact-finding is to learn as much as possible about the database’s purposes, environment, potential users, and goals before constructing a conceptual model. This process eliminates design flaws and implementation problems long before the database is even constructed, so this step is crucial for the establishmentof a functional and concise database, regardless of its complexity or user base. Thefollowing fact-finding techniques were used in preparation for constructing this database.
Interviewing. Our team’s environment was located closely to the potential user base, so this was the first technique used to simply start gathering unorganized facts. Initially, formal meetings were held between the team members and managers from the department. This allowed us to construct our entity types and relationships in their simplest forms, yet these fundamentals remained structurally unchanged for the duration of the project. After this step, informal, individual interviews were held to determine additional details and verify consistency between separate sourcesof information.
Data analysis. System administrators were able to provide detailed information regarding the volume and variety of the work that our target department handles. This process allowed us to classify and quantify many of the details and suggestions made during the interview.
Surveys. To better understand the workflow and duties of our potential userbase, brief surveys were sent via email to gather information regarding personal techniques, time spent on various types of work, and suggestions for making their daily tasks easier, if not automated.
Documentation. An out-of-state division in the company had worked on a similar project in the previous year, and their team had fortunately documented their progress and development for every step, from conceptual design to implementation using ASP.NET pages with their SQL Server. Although our goals had fundamental differences, their well-written documentation served as an excellent model during the initial planning phases of this project.
Techniques used
Data from the interviews and surveys was classified to construct basic entity types and attributes, as well as lay the foundation for creating the relationships. The interviews helped complete the details for most of the relationships, and we were finally prepared to build our model. This experience has given me enough information to use for my own implementation based on the results of the fact-finding stage.
Introduction to Enterprise/Organization
State Farm Mutual Automobile Insurance Company was founded in 1922 by George J. Mecherle in Bloomington, Illinois. Its primary focus was to provide automobile insurance for farmers. The company provided cheaper insurance to its farming customers, believing that farmers had less liability and therefore deserved cheaper rates. This concept helped the company grow and spread its services to home and life insurance. Since 1942, it has remained the largest automobile insurer in the United States, with operation centers providing specialized coverage for every region in the country.
Structure of the Enterprise
The largest division of State Farm has always been Auto Operations. This portion of the company manages all business regarding auto insurance. State Farmagents are individuals that work in their communities, selling auto insurance. They are supported by a team of Underwriters working from a state-wide Operations Center. Underwriters are responsible for approving changes to policies, verifying information on accident claims, and helping their assigned Agents better serve theircustomers. The volume of work that Underwriters handle is too great to be handledby such a small team, so an even larger support team known as Underwriting Service Assistants (USAs) performs the majority of work that passes through Underwriting. They use a client to connect to State Farm’s mainframe, which houses the records for all of their policy-holders, as well as any individual details for each policy.
Currently, the USAs pull items to work on from a personal queue, which is generated automatically by the mainframe every day. Each USA has a designated portion of work to be completed each day. However, the construction of the queue is not as efficient as it could be – some workers receive jobs that they cannot perform because they lack the training, or jobs that span several policies are fragmented and split between several USAs, when a single person would be best suited for the task. Their current system is very reliable, but not always logically optimal. The purpose of this proposed database is to organize the USAs by teams and keep track of the skills and types of work they are capable of performing. Keeping track of this in a local database will let their department organize work given to them by the corporate database in a way that is optimal and efficient for each worker.
Itemized Description of Major Objects
An Employee entity is the standard representation of an employee that can work on a team. The primary function of this object is to represent an employee forinternal relationships in this database. Complimenting this is the Team entity. Eachteam has exactly one team leader. Another entity represents the Skills that Employees can possess. To avoid additional lookups to the external database, an entity called TypesOfWork is used to record all possible types of work that the employees’ work could be classified as.
Data Views and Operations for User Groups
A team’s manager is capable of observing the team’s members and the team’s specific goal (the type of work they focus on). The team manager can assign employees to their team, or dismiss them. The team manager can also change the skill mappings that an employee has to reflect completion of training and new responsibilities. Each team manager is restricted to observing the data fortheir own team. The department head is the only person capable of viewing and modifying all entities and relationships. Standard employees have no access to the actual database.
Conceptual Database Design
Entity Set Description
Employee This entity type describes all of the employees that participate in a team in
the enterprise. Because the purpose of this database is to manage teams and appropriate skills, only the most basic information is recorded for each employee.
Candidate keys: UserID, UserName Primary key: UserID Strong/Weak Entity: strong Fields to be indexed: UserID, UserName, Name Attributes:
Name UserID UserName FullName OfficeExtension
Location
Description
Employee ID number
Employee name for authentication
Employee's full name
Employee's office phone
Employee's office location
Domain/Type
Unsigned Integer
String String Integer String
Value Range
0 … 2^32 Any Any 1000-9999 Any
Default Value
None None None None None
Nullable? No No No Yes YesUnique? Yes Yes Yes No NoSingle or multiple value
Single Single Single Multiple Multiple
Simple or composite
Simple Simple Composite Simple Simple
Team The team entity type is used for organization of employees. Teams can
have specific goals or focuses when it comes to types of work, and the team’s manager is responsible for setting these goals, as well as the skills for each team member.
Candidate keys: TeamID, Manager, Name Primary key: TeamID Strong/Weak Entity: strong Fields to be indexed: TeamID, Manager, Name Attributes:
Name TeamID TeamName
Description Location
ManagerID
Description Internal key to identify team
Given team name
Description of team goals
Team location
UserID of Team Manager
Domain/Type
Integer String String String Integer
Value Range
0 - 2^23 Any Any Any Any
Default Value
None None None None None
Nullable? No No Yes No NoUnique? Yes Yes No No YesSingle or multiple value
Single Single Single Single Single
Simple or Composite
Simple Simple Simple Simple Simple
Skills The skills entity type quantifies all possible skills that an employee can
possess. This can be used as a way to track employee training and progress, in addition to determining the work an employee is capable of handling.
Candidate keys: SkillID Primary key: SkillID Strong/Weak Entity: strong Fields to be indexed: SkillID, Name Attributes:
Name SkillID Name DescriptionDescription Internal
integer key for skill
Short, concise skillname
Provides accurate information about what possessing the skill entails
Domain/Type
Integer String String
Value Range
0 - 2^23 Any Any
Default Value
None None None
Nullable? No No NoUnique? Yes Yes NoSingle or multiple value
Single Single Single
Simple or Composite
Simple Simple Simple
TypeOfWork The TypeOfWork entity type depicts all possible types of work that the
employee may encounter. A team is capable of focusing on a specific type of work for specialization. Certain types of work require certain skills for completion
Candidate keys: TOWID Primary key: TOWID Strong/Weak Entity: strong Fields to be indexed: TOWID, Name Attributes:
Name TOWID Name DescriptionDescription
Internal integer key for Type of Work
Short, concise name for type of work
Accurate description of what is handled by this type of work
Domain/Type
Integer String String
Value Range
0 - 2^32 Any Any
Default Value
None None None
Nullable? No No NoUnique? Yes Yes NoSingle or multiple value
Single Single Single
Simple or Composite
Simple Simple Simple
Relationship Set Description
Team_History:This is another binary relationship between Employee and Team. Whenever an employee’s team mapping changes, the change is recorded by creating a relationship between the employee and the old team. The relationship has attributes to record the employee’s start date on the team (taken from the StartDate field in Belongs_To) and the end date.
- Mapping cardinality: M..M- Descriptive field: none- Participation constraint: Because this is a relationship for historical
purposes, participation is optional for both entities. It is up to the database manager to decide how long to keep entries in this relationship
Possesses:Each employee needs to have at least one skill before being participating on a team and getting entered into the database. This relationship records the skills that each employee has, so it can be determined the types of work that the employee is capable of.
- Mapping cardinality: M..M- Descriptive field: none- Participation constraint: mandatory for Employee, optional for Skill
Requires:Certain types of work require certain skills for assignment and completion. This relationship shows what skills are necessary to perform a specific type ofwork. This relationship can then be used to show the types of work an employee is capable of performing, while adhering to their restrictions based on acquired skills. A type of work can require no skills, or as many skills as the managers see fit.
- Mapping cardinality: M..M- Descriptive field: none- Participation constraint: optional for both Skill and TypeOfWork
Focuses_On:The benefit of team organization in this enterprise is the affinity a team can have for a specific type of work. This sets a goal for the team, and by association, its members. Using this, a manager can see a team’s focus for types of work juxtaposed with an employee’s capabilities. This can also help when assigning teams. A team can have multiple types of work to set as focuses.
- Mapping cardinality: M..M- Descriptive field: none- Participation constraint: Mandatory for Team, optional for TypeOfWork
Related Entity Set:
Currently there are no related entity sets in this database. The structure of the team/work layout stresses simplicity to focus on the ability to create teams and assign them specific types of work. A possible scenario involving specialization would be to add entity types to represent the Underwriters, USAs, and department managers from State Farm. However, only the team managers really need access to the database, and they are fully capable of modifying team mappings, so such an action would be unnecessary.
E-R Diagram
Employee
UserID (PK)UserNameFullNameOfficeExtensionLocationBelongs_To(FK)
Team
TeamID (PK)NameDescriptionLocationManager(FK)
TypeOfWork
TOWID (PK)NameDescription
Skills
SkillID (PK)NameDescription
Team_History
Possesses
Requires
Focuses_On
n
n
n
n
n
n
1n
StartDateEndDate
Phase II: Relational model
E-R model and the relational model
Description
The Entity-relationship model shown in Phase I is a valuable tool for visualizing the data’s organization for the planned database. However, this conceptual form of the database must be converted into a relational form before it can be implemented as an actual, functioning database. The relational model was first described by IMB Researcher Ted Codd in his 1970 paper, “A Relational Model of Data for Large Shared Data Banks.” This model allows for all data to be described as a set of relations with constraints set on given domains. Under these conditions, we can produce a valid, finite description of the theoretical database, which allows for faster, easier conversion into the actual database.
Comparison
The entity-relationship model represents a visual description of the proposed database format, with implied attributes, relations, and cardinality. This serves as the conceptual design for the database. This design omits any sort of implementation details, so no focus is taken away from the design aspects needed for this phase. Because of its visual layout, the entity-relationship model is best used with non-technical potential users of the planned database.
The relational model lays out the previously-described entities and relationships between entities as a table with its attributes as columns. Each row in the table is avalid record, or tuple, in the database, and each table is referred to as a relation. This representation allows the database designers to better understand the size anddomain constraints for the final product. The relational model lacks the visual advantages of the entity-relationship model, but allows for better, more accurate descriptions of domain constraints and tuple entries. It also more closely resemblesthe actual structure of the tables in the implemented database.
Conversion from E-R model to relational model
Creation of a relational model is facilitated by first producing a conceptual model. Aconceptual provides basic structural integrity, from which the relational model’s relations and column attributes can be mapped. An algorithm exists to expedite this process. This algorithm takes into account the existence of an extended entity-
relationship model (one with specialization, generalization, and union types represented), but the structure of this project’s E-R model does not call for these extra steps.
First, a relation is created for each strong entity type in the E-R model. Each relation has the same simple attributes as it did in the E-R model. An attribute is selected as the primary key for the relation, using a combination of attributes if a composite key is used. Secondary keys may also be allowed. Next, weak entities and their attributes are mapped to relations. Their primary key can be denoted as acombination of any partial keys the weak entity has with the primary key of its owner(s). Next, the two participating entities in all 1:1 binary relationship types R from the E-R model are mapped to separate relations S and T. The representation in the relational model can be created using several methods:
Include the primary key of one relation as a foreign key in the other. Best for one total participation.
Merge the two entity types into a single relation. Best for total participation in both entities.
Create another relation to hold the primary keys of each relation. This is necessary for M:N relationships, but can be implemented for any cardinality.
These steps are considered and used for mapping 1:M and M:N relationships to the relational model. The next step is to create a relation to represent multi-valued attributes. This relation will have an attribute for each portion of the E-R model’s multi-valued attribute. This relation can be assigned a primary key that can be referenced from any other relation that uses the multi-valued attribute. Finally, these steps are combined to create relations to represent N-ary relationship types from the E-R model.
For conceptual models that involve specialization or generalization, additional steps are taken for proper representation in the relational model. There are several approaches for this step:
Create one relation for the superclass with {k, a1, a2, …, an} attributes, and create m relations for each subclass with its own attributes unioned with the superclass’ attributes, and specify k as the subclass’ primary key. This worksfor any arrangement of specialization: total, partial, disjoint, or overlapping
Create a relation for each subclass, and union the subclass’ attributes with the superclass’ attributes. This works for when every superclass object belongs to at least one subclass.
Create a single relation with all subclass and superclass attributes unioned. This can create many NULL entries in the resulting tuples.
Following these steps will convert the conceptual model into a valid, complete, relational model.
Constraints
A relation consists of an ordered set of unique tuples, with each tuple having the same amount and type of attributes. Entities are represented as relations in the
relational model, and each row is a valid instance, record, or tuple for the entity. Entity constraints ensure that for a relation, no primary key can be NULL. This ensures that there is a unique element of each tuple in the relation, which is necessary for comparisons and representations in queries and data integrity. Constraints for foreign keys exist to enforce referential integrity: any references to other existing tuples in other relations must be valid. A foreign key constraint states that for a given attribute value in a relation r1, that attribute acts as a primary key for another relation r2, and the value exists for some tuple in r2. Thus, any references made in one tuple actually exist within the database. Check constraints and business rules exist to serve a specific business need for the data. These constraints add further limitations to entries in the database: the data must not only be of the right type, but must meet certain requirements, such as falling within a given range, or making sure a telephone number is from a specific area code.
E-R database to relational database
Employee relation
Attributes
UserIDo Domain: unsigned integer: 1 to 2^32 – 1. Cannot be NULL.
UserNameo Domain: string. Must be at least 4 characters long, only numbers and
letters, beginning with a character. Cannot be NULL. FullName
o Domain: string. Single string that holds name in: “First Last” format. Single space between first name and last name. Only used for display purposes, so no need for splitting into multi-valued attribute. Cannot be NULL.
OfficeExtensiono Domain: integer. In form of office extension, so it will only hold values
in the range {1000…9999}. Can be NULL. Location
o Domain: string. No restrictions on attribute value. Can be NULL. Belongs_To
o Domain: integer. Value corresponds to a team number from the team relation. Every employee must belong to a team, so this relationship isbeing represented as an attribute in the Employee relation.
Constraints Primary key: UserID acts as the primary key. This must be unique and not
NULL. Foreign key: Belongs_To must have a value that exists as a primary key in
the Team relation. This ensures that each employee belongs to one and only one current, existing team.
Business Rule constraint. OfficeExtension must be within the range {1000…9999}. It can be NULL, but if it is not, it must fall in this range.
Candidate Keys UserID UserName
Team relation
Attributes
TeamIDo Domain: unsigned integer: 1 to 2^32 – 1. Cannot be NULL.
TeamNameo Domain: string. Cannot exceed 128 characters. Cannot be NULL.
Descriptiono Domain: string. Variable length. Can be NULL.
Locationo Domain: string. Variable length. Cannot be NULL.
ManagerIDo Domain: unsigned integer: 1 to 2^32 – 1. Cannot be NULL.
Constraints Primary key: TeamID acts as the primary key. This must be unique and not
NULL. Foreign key: ManagerID must be a valid UserID from the Employees table.
This ensures that each team has exactly one current employee as its manager.
Candidate Keys TeamName ManagerID
Skills relation
Attributes
SkillIDo Domain: unsigned integer: 1 – 2^32 – 1. Cannot be NULL.
Nameo Domain: string. Cannot exceed 128 characters. Cannot be NULL.
Descriptiono Domain: string. Variable length. Cannot be NULL.
Constraints Primary key: SkillID. This acts as the primary key for the Skills relation. This
must be unique and not NULL. Business rule: A skill’s name and description must not be null. The name
should concisely describe the skill’s implied meaning, with the description serving to represent any additional information about the skill.
Candidate Keys Name
TypeOfWork relation
Attributes
TOWIDo Domain: unsigned integer: 1 – 2^32 – 1. Cannot be NULL.
Nameo Domain: string. Cannot exceed 128 characters. Cannot be NULL.
Descriptiono Domain: string. Variable length. Cannot be NULL.
Constraints Primary key: TOWID. This acts as the primary key for the Skills relation. This
must be unique and not NULL. Business rule: A Type of Work’s name and description must not be null. The
name should concisely describe the Type of Work’s implied meaning, with thedescription serving to represent any additional information about the Type of Work.
Candidate Keys Name
Team_History relation
Attributes
UserIDo Domain: unsigned integer: 1 – 2^32 – 1. Cannot be NULL.
TeamIDo Domain: unsigned integer: 1 – 2^32 – 1. Cannot be NULL.
StartDateo Domain: valid DateTime. Cannot be NULL.
EndDateo Domain: valid DateTime. Cannot be NULL. Must be larger than or
equal to StartDate.
Constraints Business rule: the EndDate cannot be an entry less than the StartDate. Foreign keys: Because this is a historical relation, the UserID and TeamName
should both exist in their respective relations. The deletion of any Employee or Team tuple should trigger a cascading deletion from this relation. This implies that a deletion should only be made after any necessary information regarding the team or employee is recorded on something outside of this database.
Candidate Keys None
Possesses relation
Attributes
UserIDo Domain: unsigned integer: 1 – 2^32 – 1. Cannot be NULL.
SkillIDo Domain: unsigned integer: 1 – 2^32 – 1. Cannot be NULL.
Constraints Foreign keys: UserID and SkillID must both exist in their respective relations.
Candidate Keys None
Requires relation
Attributes
SkillIDo Domain: unsigned integer: 1 – 2^32 – 1. Cannot be NULL.
TOWIDo Domain: unsigned integer: 1 – 2^32 – 1. Cannot be NULL.
Constraints Foreign keys: SkillID and TOWID must both exist in their respective relations.
Candidate Keys None
Focuses_On relation
Attributes TeamID
o Domain: unsigned integer: 1 – 2^32 – 1. Cannot be NULL. TOWID
o Domain: unsigned integer: 1 – 2^32 – 1. Cannot be NULL.
Constraints Foreign keys: TeamID and TOWID must both exist in their respective
relations.
Candidate Keys None
Relation Instances
Employee(UserID, UserName, FullName, OfficeExtension, Location, Belongs_To)
UserID UserName FullName OfficeExtension
Location Belongs_To
1 AW01 Adam West 1010 Main Office 42 TK91 Scott East 2910 Main Office 43 FP19 Doug Gru 4125 Main Office 54 MOD4 Nick
Toothman6271 Main Office 3
5 Q91T Chad Lane 1908 Main Office 36 FPS9 Duke Seah 1845 Main Office 37 TUN5 Thanatos
Seah8062 Main Office 3
8 DOD5 Brian Johnson
1274 Main Office 2
9 KLS1 John Doe 8915 Main Office 210 WIT5 Jane Doe 1724 Main Office 211 NUM4 Kristie
Summers5189 Bakersfield
Branch1
12 CRE2 Stacy Lane 8925 Bakersfield Branch
1
13 SEK3 Tori O'Riley 1624 Home Office 514 SKE9 Stephanie
Lauren9012 Home Office 5
15 ANY1 Susan Peters
1722 Iceland Office 5
Team(TeamID, Name, Description, Location, Manager)
TeamID TeamName
Description Location
ManagerID
1 North Covers northern clients
Bakersfield
12
2 South Covers southern clients
Main Office
8
3 East Covers eastern clients
Main Office
4
4 West Covers Westernclients
Denmark
1
5 Ramrod Covers various clients 3
Team_History(UserID, TeamID, StartDate, EndDate)
UserID TeamID StartDate
EndDate
1 1 10/17/1985
12/31/1985
1 2 1/1/1986 7/8/20052 3 10/17/19
8512/31/198
52 5 1/1/1986 12/9/20013 1 5/8/1999 6/12/20014 2 4/1/1998 4/1/19995 1 6/15/200
67/19/2007
6 3 6/1/1992 9/15/20006 4 8/4/1994 9/14/19967 1 6/1/1997 3/12/19988 1 5/1/2001 6/8/20039 2 4/1/2003 4/19/2005
10 3 9/6/1987 2/21/199311 2 4/14/200
19/8/2005
12 5 3/1/2000 3/12/200214 3 1/5/1991 7/1/200115 1 6/15/198
67/21/1990
15 2 7/22/1990
6/21/1999
Skills(SkillID, Name, Description)
SkillID Name Description1 Customer
ServiceUser is capable of listening to and meeting customer's needs
2 Quality Assurance
User can verify quality of customer product or service
3 Sales User is qualified to act as vender for product or service
4 Processing User has limited modification access for customer data5 Employee
ManagementUser can modify employee database within limitations
6 Team Management
User can serve as manager for team
7 Data Access User can read and write customer data8 Phone
HandlingUser is trained for answering, forwarding, and blocking calls
9 Customer DataAccess
User has full modification access for customer data
10 Account Creation
User has authority to create a new account for customer
11 Account Handling
User has authority to modify existing accounts
12 Safety Training User is fully-trained on safety regulations and restrictions for customer acccount
13 High-level Access
User has unrestricted access to customer and user data
14 Special Needs Training
User is capable of meeting special needs for a specific work item
15 Database Access
User can modify employee database without limitation
Possesses(UserID, SkillID)
UserID
SkillID
1 11 21 31 51 62 42 52 22 73 53 63 83 94 54 64 84 9
UserID
SkillID
7 37 48 59 69 79 89 9
10 910 1010 1110 1210 1310 1411 111 211 412 5
4 115 85 105 115 136 136 146 156 12
12 613 613 1413 1514 1314 1414 1515 215 315 415 5
TypeOfWork(TOWID, Name, Description)
TOWID
Name Description
1 New claims Handles any new claims that have not been processed by anyone yet
2 Requests All formal requests for existing claims: change of address, fee reductions, etc
3 Renewals Automated requests made for customers whose account is about to expire
4 Complaints Processing
Any formal complaints made by new or existing customers. Handled by Customer Service
5 Cancellation Requests to cancel any currently open work items, but not terminate any associated accounts
6 Termination Requests to close and terminate a customer's account7 Transfers Handles any transfers of ownership, liability, or finances
between customers8 Auditing Automated work items that call for auditing on a
customer's account based on finances and payments9 Managerial Handling team management, data access for internal
employees10 Special Anything that requires eccentric or temporary skills for an
irregular work item.11 Training Used for training new employees
Requires(TOWID, SkillID)
TOWID
SkillID
1 11 31 71 102 42 72 92 113 13 33 73 93 104 14 24 44 74 85 45 75 116 46 76 96 116 13
TOWID
SkillID
7 47 78 48 78 99 59 69 15
10 1210 1310 1411 111 211 311 411 511 611 711 811 911 1011 1111 1211 1311 1411 15
Focuses_On(TeamID, TOWID)
TeamID
TOWID
1 41 92 82 92 113 13 24 14 24 34 44 55 15 35 55 65 7
Queries Select employees who have been on at least 2 teams Select employees who possess all skills Select employees who possess no skills Select types of work that require all skills Select teams with at least 2 members Select teams with only one type of work to focus on Select types of work that are not focused on by any team Select skills that no employee possesses Select types of work that require no skills Select manager’s old teams
Query RepresentationSelect employees who have been on at least 2 teams
Relational algebra: π (UserID) σ (Team_History t1 X Team_History t2) * Employee t1.UserID = t2.UserID ^ t1.TeamID != t2.TeamID
Tuple relational calculus:{e | Employee(e) ^ (∃t1)(Team_History(t1)) ^ (∃t2)(Team_History(t2)) ^ t1.UserID = t2.UserID ^ t1.UserID = e.UserID ^ t1.TeamID != t2.UserID}
Domain relational calculus:{<u,n> | Employee(u,n,_,_,_,_) ^ (∃t1)( ∃t2)(Team_History(u,t1,_,_) ^ (Team_History(u,t2,_,_) ^ t1 != t2}Select employees who possess all skills
Relational algebra:( Possesses ÷ (π(SkillID) (Skills))) * Employee
Tuple relational calculus:{e | Employee(e) ^ ((∀s) (Skills(s)) → (∃p)(Possesses(p)) ^ p.UserID = e.UserID & p.SkillID = s.SkillID }
Domain relational calculus:{ <u> | Employee(u,_,_,_,_,_) ^ ((∀s)(Skills(s,_,_) ^ (Possesses(u,s))) }Select employees who possess no skills
Relational algebra: π(UserID)(Employee) – π(UserID)(Employee * Possesses)
Tuple relational calculus:{e | Employee(e) ^ ~(∃p)(Possesses(p) ^ p.UserID = e.UserID) }
Domain relational calculus:{<u> | Employee(u,_,_,_,_,_) ^ ~(∃p)(Possesses(u,p)) }Select types of work that require all skills
Relational algebra:(Requires ÷ (π(SkillID) (Skills))) * TypeOfWork
Tuple relational calculus:{t | TypeOfWork(t) ^ ((∀s) (Skills(s)) → (∃p)(Requires(p)) ^ p.TOWID = t.TOWID & p.SkillID = s.SkillID }
Domain relational calculus{<t> | TypeOfWork(t,_,_) ^ ((∀s)(Skills(s,_,_) ^ (Requires(u,s))) }Select teams with at least 2 members
Relational algebra:π (TeamID) σ (Employee e1 X Employee e2) * Team e1.UserID != e2.UserID ^ e1.TeamID = e2.TeamID
Tuple relational calculus:{t | Team(t) ^ (∃e1)( Employee (e1)) ^ (∃e2)( Employee (e2)) ^ e1.UserID != e2.UserID ^ e1.TeamID = e2.TeamID ^ t1.TeamID = e1.TeamID}
Domain relational calculus:{<t> | Team(t,_,_,_,_) ^ (∃e1) (∃e2)( Employee (e1,_,_,_,_,t)) ^ (Employee (e2,_,_,_,_,t)) ^ e1 != e2}
Select teams with only one type of work to focus on
Relational algebra:π (TeamID) (Focuses_On - σ (Focuses_On f1 X Focuses_On f2) * Team f1.TeamID = f2. TeamID ^ f1.TOWID != f2. TOWID
Tuple relational calculus:{t | Team(t) ^ (∃f1)(Focuses_On(f2)) ^ ~(∃f2)(Focuses_On(f2)) ^ f1.TeamID = f2.TeamID ^ f1.TOWID != f2.TOWID & t.TeamID = f1.TeamID }
Domain relational calculus:{<t> | Team(t,_,_,_,_) ^ (∃f1)(Focuses_On(t,f1)) ^ ~(∃f2)(Focuses_On(t,f2)) ^ f1 != f2. }Select types of work that are not focused on by any team
Relational algebra:TypeOfWork - π (TOWID)(Focuses_On)
Tuple relational calculus:{t | TypeOfWork(t) ^ ~(∃t1)(Focuses_On(t1)) ^ t.TOWID = t1.TOWID }
Domain relational calculus:{<t> | TypeOfWork(t,_,_) ^ ~(∃t1)(Focuses_On(t1,t) }
Select skills that no employee possesses
Relational algebra:π(SkillID)(Skills) – π(SkillID)(Employee * Possesses)
Tuple relational calculus:{s | Skills(s) ^ ~(∃p)(Possesses(p) ^ p.SkillID = s.SkillID) }
Domain relational calculus:{<s> | Skills(s,_,_) ^ ~(∃p)(Possesses(p,s) }
Select types of work that require no skills
Relational algebra:π(TOWID)(TypeOfWork) – π(TOWID)( TypeOfWork * Requires)
Tuple relational calculus:{t | TypeOfWork (t) ^ ~(∃s)(Requires(s) ^ s.TOWID = t.TOWID) }
Domain relational calculus:{<t> | TypeOfWork (t,_,_) ^ ~(∃s)(Requires(t,s) }
Select manager’s old teams
Relational algebra:π(TeamID) [(π (ManagerID) (Team)) * Team_History] * Teams
ManagerID = UserID
Tuple relational calculus:{t | Team_History(t) ^ (∃t2)(Team(t2)) ^ t.UserID = t2.ManagerID }
Domain relational calculus:{<t> | (∃u)(Team_History(u,t,_,_) ^ (∃t2)(Team(t2,_,_,_,u)}
Phase III: Implementation of the relational database
SQL*PLUS
Now that the relational model has been completed, the description for each relation can be used to actually create a database that meets its requirements regarding attributes, constraints, and relationships. To do this, I will use the implementation of SQL from the Oracle Relational Database Management System (hereafter referred to as Oracle). Structured Query Language, or SQL, was first developed at IBM in the 1970s. Since then, it has undergone rigorous optimization and standardization, and several popular implementations are used for most databases. These include Microsoft’s Transact-SQL, or T-SQL, MySQL, and Oracle. Oracle provides a tool called SQL*PLUS that allows users to interactively run any SQL commands. It’s a command-line tool that supports both user interaction and automated scripts. By using a hierarchy of scripts to call appropriate commands, a database can be destroyed and re-created very quickly using SQL*PLUS.
Schema Objects in Oracle
In oracle, a collection of schema objects forms a schema. A tablespace logically organizes the structure of the database with respect to various schemas. Italso contains the locations used to physically store data on the database’s media. Schema objects are logical data structures that are stored logically in a given tablespace within the database. The physical data for each schema object is stored in the tablespace’s data files. This structure allows any tablespace to logically contain many different types of schema objects, but remain optimized for storage and access. Oracle supports several schema objects. They are as follows:
TablesTables are used to represent relations from the relational model. They serve as the basic storage unit for an Oracle database. A table’s columns representthe relation’s attributes, and rows in the table represent existing records or tuples in the relation. Each column has a unique name and data type. Tables store information about the relation’s primary key, any foreign keys, and any other constraints it may possess (including referential or null). After the table is created, rows can be inserted to represent the existence of tuples.
ViewsViews are essentially read-only query commands that will always return tuples from tables that meet a certain requirement. These are used when thesame commands will be used repeatedly. This allows for clearer
organization, and database optimization. The results of a view can be thoughtof as tables and, as such, can be accessed and modified like a table. Views lose referential or integrity constraints, but these can be implied by the underlying tables that the view accesses in its execution. Views do not use storage space like a table – only the commands that represent the view are saved. Its results are not, since they are implied from other tables. Views can be used to obfuscate data, prevent direct access for certain users, and simplify representation for users. Materialized views are special views that perform a specific function on the data it retrieves, including aggregate functions, sorting, summations, data transfer, and reorganization.
DimensionsDimensions are used to create hierarchical relationships between columns in a table. This can be used between columns of the same table (denormalized)or of separate tables (normalized).
SequencesSequence generators create a sequential set of numbers for use in a multi-user environment. These sequence numbers can then be used to determine order for queued operations or requests. They are not dependent on any table, but they can be used to generate primary keys for a specific table. Sequence numbers can also be used to keep track of roll-backs in transactions, ensuring that the right commands are reversed without confliction between separate users.
SynonymsSynonyms are alternate aliases for certain types of schema objects, such as tables, procedures, functions, or views. They do not require any additional storage space other than their entries in the database’s data dictionary. Synonyms can be used to directly hide internal data for outside users or to simplify complex SQL commands.
IndexesDatabases attempt to optimize traversal of each table by caching the values of unique attributes, such as primary keys. Additional attributes can be specified such that the database more quickly accesses their values during comparisons for overall faster results. Indexes can also be created for combinations of certain attributes. Furthermore, an existing index can be used to create another dependent index. An Oracle system will automaticallymaintain indexes once specified by a user.
Database LinksPut simply, database links are hard-coded, read-only links to another database. This allows one database to perform queries and retrieve results using another database, while simultaneously preventing both databases from risking the integrity of one another.
Stored procedures and functionsThese can be seen as scripts that are stored on the database. When executed, a stored procedure or function always performs the same task as
instructed upon its creation. Functions in Oracle always return a single value to the user, while stored procedures do not.
PackagesPackages are a specific collection of stored procedures, functions, and cursors. Combined, they act as a single unit of instructions. This is critical for large-scale operations performed by stored procedures. Packages organize and simplify design requirements for databases that require persistent, complex tasks.
Schema objects in this project
In this project, the two most frequently used schema objects are the table and the view.
Most of the tables are created using syntax similar to this:
CREATE Table [TableName]
(attributes attribute types nullable? ,… … … ,
… … … ,
Constraints:
pk_tablename PRIMARY KEY (AttributeName) fk_ParentName_ChildName FOREIGN KEY (AttributeName)
REFERENCES ParentName (ParentAttributeName)
);
The scheme objects created using this syntax are as follows:
nt_employee Employee relation nt_team Team relation nt_teamhistory Team_History relation nt_skills Skills relation nt_tow TypesOfWork relation nt_possesses Possesses relation nt_requires Requires relation nt_focuseson Focuses_On relation
Following are the schemas and instances for each relation:
nt_employee
SQL> desc nt_employee; Name Null? Type ----------------------------------------- -------- ---------------------------- USERID NOT NULL NUMBER(10) USERNAME NOT NULL VARCHAR2(10) FULLNAME NOT NULL VARCHAR2(50) OFFICEEXTENSION NUMBER(8) LOCATION VARCHAR2(50) BELONGS_TO NOT NULL NUMBER(10)
SQL> select * from nt_employee;
USERID USERNAME FULLNAME OFFICEEXTENSION LOCATION BELONGS_TO ---------- ---------- ---------- --------------- ---------- ---------- 1 AW01 Adam West 1010 Main Offic 4 e
2 TK91 Scott East 2910 Main Offic 4 e
3 FP19 Doug Gru 4125 Main Offic 5 e
4 MOD4 Nick Tooth 6271 Main Offic 3 man e
USERID USERNAME FULLNAME OFFICEEXTENSION LOCATION BELONGS_TO ---------- ---------- ---------- --------------- ---------- ----------
5 Q91T Chad Lane 1908 Main Offic 3 e
6 FPS9 Duke Seah 1845 Main Offic 3 e
7 TUN5 Thanatos S 8062 Main Offic 3 eah e
8 DOD5 Brian John 1274 Main Offic 2
USERID USERNAME FULLNAME OFFICEEXTENSION LOCATION BELONGS_TO ---------- ---------- ---------- --------------- ---------- ---------- son e
9 KLS1 John Doe 8915 Main Offic 2 e
10 WIT5 Jane Doe 1724 Main Offic 2 e
11 NUM4 Kristie Su 5189 Bakersfiel 1 mmers d Branch
USERID USERNAME FULLNAME OFFICEEXTENSION LOCATION BELONGS_TO ---------- ---------- ---------- --------------- ---------- ---------- 12 CRE2 Stacy Lane 8925 Bakersfiel 1 d Branch
13 SEK3 Tori O Ril 1624 Home Offic 5
ey e
14 SKE9 Stephanie 9012 Home Offic 5 Lauren e
15 ANY1 Susan Pete 1722 Iceland Of 5 rs fice
nt_team
SQL> desc nt_team; Name Null? Type ----------------------------------------- -------- ---------------------------- TEAMID NOT NULL NUMBER(10) TEAMNAME NOT NULL VARCHAR2(16) DESCRIPTION VARCHAR2(32) LOCATION VARCHAR2(16) MANAGERID NOT NULL NUMBER(10)
SQL> spool off
TEAMID TEAMNAM DESCRIPTION LOCATION MANAGERID---------- ------- -------------------- ------------- ---------- 1 North Covers northern clie Bakersfield 12 nts
2 South Covers southern clie Main Office 8 nts
3 East Covers eastern clien Main Office 4 ts
4 West Covers western clien Denmark 1 ts 5 Ramrod Covers misc. clients 3
nt_teamhistory
SQL> desc nt_teamhistory; Name Null? Type ----------------------------------------- -------- ---------------------------- USERID NOT NULL NUMBER(10) TEAMID NOT NULL NUMBER(10) STARTDATE NOT NULL DATE ENDDATE NOT NULL DATE
SQL> spool offSQL> select * from nt_teamhistory;
USERID TEAMID STARTDATE ENDDATE---------- ---------- --------- --------- 1 1 17-OCT-85 31-DEC-85 1 2 01-JAN-86 08-JUL-05 2 3 17-OCT-85 31-DEC-85 2 5 01-JAN-86 09-DEC-01 3 1 08-MAY-99 12-JUN-01 4 2 01-APR-98 01-APR-99 5 1 15-JUN-06 19-JUL-07 6 3 01-JUN-92 15-SEP-00 6 4 04-AUG-94 14-SEP-96
7 1 01-JUN-75 12-MAR-98 8 1 01-MAY-01 08-JUN-03
USERID TEAMID STARTDATE ENDDATE---------- ---------- --------- --------- 9 2 01-APR-03 19-APR-05 10 3 06-SEP-87 21-FEB-93 11 2 14-APR-01 08-SEP-05 12 5 01-MAR-00 12-MAR-02 14 3 05-JAN-91 01-JUL-01 15 1 15-JUN-86 21-JUL-90 15 12 22-JUL-90 21-JUN-99
nt_skills
SQL> desc nt_skills; Name Null? Type ----------------------------------------- -------- ---------------------------- SKILLID NOT NULL NUMBER(10) NAME NOT NULL VARCHAR2(128) DESCRIPTION NOT NULL VARCHAR2(128)
SQL> select * from nt_skills;
SKILLID NAME DESCRIPTION ---------- -------------------- ----------------------------------- 1 Customer Service User is capable of listening to and meeting customer needs
2 Quality Assurance User can verify quality of customer product or service
3 Sales User is qualified to act as vender for product or service
4 Processing User has limited modification acces s for customer data
SKILLID NAME DESCRIPTION ---------- -------------------- -----------------------------------
5 Employee Management User can modify employee database w ithin limitations
6 Team Management User can serve as manager for team 7 Data Access User can read and write customer da ta
8 Phone Handling User is trained for answering, forw arding, and blocking calls
SKILLID NAME DESCRIPTION ---------- -------------------- ----------------------------------- 9 Customer Data Access User has full modification access f or customer data
10 Account Creation User has authority to create a new account for customer
11 Account Handling User has authority to modify existi ng accounts
12 Safety Training User is fully-trained on safety reg ulations and restrictions for custo
SKILLID NAME DESCRIPTION ---------- -------------------- ----------------------------------- mer acccount
13 High-level Access User has unrestricted access to cus tomer and user data
14 Special Needs Traini User is capable of meeting special ng needs for a specific work item
15 Database Access User can modify employee database w ithout limitation
nt_tow
SQL> desc nt_tow; Name Null? Type ----------------------------------------- -------- ---------------------------- TOWID NOT NULL NUMBER(10) NAME NOT NULL VARCHAR2(128) DESCRIPTION NOT NULL VARCHAR2(128)
SQL> select * from nt_tow;
TOWID NAME DESCRIPTION---------- -------------------- ----------------------------------- 1 New claims Handles any new claims that have no t been processed by anyone yet
2 Requests All formal requests for existing cl aims: change of address, fee reduct ions, etc
3 Renewals Automated requests made for custome rs whose account is about to expire
4 Complaints Processing Any formal complaints made by new o r existing customers. Handled by C ustomer Service
5 Cancellation Requests to cancel any currently op en work items, but not terminate an y associated accounts
6 Termination Requests to close and terminate a c ustomer account
7 Transfers Handles any transfers of ownership, liability, or finances between cus tomers
8 Auditing Automated work items that call for auditing on a customer account base d on finances and payments
9 Managerial Handling team management, data acce ss for internal employees
10 Special Anything that requires eccentric or temporary skills for an irregular
work item
11 Training Used for training new employees
nt_possesses
SQL> desc nt_possesses; Name Null? Type ----------------------------------------- -------- ---------------------------- USERID NOT NULL NUMBER(10) SKILLID NOT NULL NUMBER(10)
SQL> select * from nt_possesses;
1 1 1 2 1 3 1 5 1 6 2 2 2 4 2 5 2 7 3 5 3 6 3 8 3 9 4 5 4 6 4 8 4 9 4 11 5 8 5 10 5 11 5 13 6 12 6 13 6 14 6 15 7 3 7 4 8 5 9 6 9 7 9 8 9 9 10 9 10 10 10 11 10 12 10 13 10 14 11 1 11 2 11 4 12 5 12 6 13 6 13 14 13 15 14 13 14 14 14 15 15 2 15 3 15 4
15 5
54 rows selected.
nt_requires
SQL> desc nt_requires; Name Null? Type ----------------------------------------- -------- ---------------------------- SKILLID NOT NULL NUMBER(10) TOWID NOT NULL NUMBER(10)
SQL> select * from nt_requires;
SKILLID TOWID ---------- ---------- 1 1 1 3 1 7 1 10 2 4 2 7 2 9 2 11 3 1 3 3 3 7 3 9 3 10 4 1 4 2 4 4 4 7 4 8 5 4 5 7 5 11 6 4 6 7 6 9 6 11 6 13 7 4 7 7 8 4 8 7 8 9 9 5 9 6 9 15 10 12 10 13 10 14 11 1 11 2 11 3 11 4 11 5 11 6 11 7 11 8 11 9 11 10 11 11 11 12 11 13 11 14
11 15
52 rows selected.
nt_focuseson
SQL> desc nt_focuseson; Name Null? Type ----------------------------------------- -------- ---------------------------- TEAMID NOT NULL NUMBER(10) TOWID NOT NULL NUMBER(10)
SQL> select * from nt_focuseson;
TEAMID TOWID---------- ---------- 1 4 1 9 2 8 2 9 2 11 3 1 3 2 4 1 4 2 4 3 4 4 4 5 5 1 5 3 5 5 5 6 5 7
17 rows selected.
SQL QueriesSelect employees who have been on at least 2 teams
SELECT DISTINCT e.UserName from nt_employee e, nt_teamhistory hWHERE e.UserID = h.UserID
Report:
ANY1AW01CRE2DOD5FP19FPS9KLS1MOD4NUM4Q91TSKE9TK91TUN5WIT5
Select employees who possess all skillsSELECT e.FullNameFROM nt_employee eWHERE ( (SELECT SkillID
FROM nt_possesses p WHERE p.UserID = e.UserID)CONTAINS(SELECT SkillIDFROM nt_skills) );
Report: empty (no single employee possesses all skills)
Select employees who possess no skillsSELECT e.FullNameFROM nt_employee eWHERE NOT EXISTS (SELECT * FROM nt_possesses p WHERE p.UserID =
e.UserID);
Report: empty (all employees have at least 1 skill)
Select types of work that require all skillsSELECT t.*FROM nt_tow tWHERE ( ( SELECT r.SkillID
FROM nt_requires r WHERE r.TOWID = t.TOWID)CONTAINS( SELECT s.SkillIDFROM nt_skills s) );
Report:
TOWID NAME DESCRIPTION---------- -------------------- ----------------------------------- 11 Training Used for training new employees
Select teams with at least 2 membersSELECT DISTINCT t.*FROM nt_team t, nt_employee 2, nt_employee e2WHERE t.TeamID = e.Belongs_To AND e.UserID <> e2.UserID AND
e2.Belongs_To = e.Belongs_To
Report:
TEAMID TEAMNAM DESCRIPTION LOCATION MANAGERID---------- ------- ----------------------------------- ------------- ---------- 1 North Covers northern clients Bakersfield 12 2 South Covers southern clients Main Office 8 3 East Covers eastern clients Main Office 4 4 West Covers western clients Denmark 1 5 Ramrod Covers misc. clients 3
(Every team has at least 2 members)
Select types of work that are not focused on by any teamSELECT t.*FROM nt_tow tWHERE NOT EXISTS (SELECT *
FROM nt_focuseson fWHERE f.TOWID = t.TOWID);
Report:
TOWID NAME DESCRIPTION---------- -------------------- ----------------------------------- 10 Special Anything that requires eccentric or temporary skills for an irregular work item
Select manager’s old teamsSELECT t.ManagerID, h.TeamIDFROM nt_team t, nt_teamhistory hWHERE t.ManagerID = h.UserIDReport:
MANAGERID TEAMID---------- ---------- 1 1 1 2 3 1 4 2 8 1 12 5
Phase IV: Stored Procedures
Common Features in Oracle PL/SQL and Microsoft Transact-SQL
Oracle and Microsoft’s implementations of SQL are not completely independent. Based off of a common language, both Procedural Language/Structured Query Language and Transaction-SQL share many common features, despite being developed separately by Oracle and Microsoft, respectively. Both languages support commands to create tables, constraints, functions, cursors, stored procedures, triggers, and packages. Their biggest differences are in the syntax used to create and maintain these objects in the database. Furthermore, both languages have supported functions to translate and compare variables, look up dates and times, and manage user-defined variables.
Differences between the two forms of SQL often stem from the version being used. For example, Oracle 8i does not have very much support for nested SELECT statements in cursors, but allows this in later versions. It is difficult to perform massupdates on records in early T-SQL, but Oracle provides this functionality. In a way, the necessities of database users and designers have pushed both languages to converge to provide similar functionality so that users who choose one implementation do not miss the benefits of the other.
Depending on the structure and usage of a database, it might be advantageous to define tasks that can be repeatedly and quickly run by specific users. Stored subprograms, or stored procedures, are supported in both PL/SQL and T-SQL for thispurpose. Subprograms can be written to automate otherwise tedious processes, such as inserting, deleting, or updating records in the database. Furthermore, the database designer can obfuscate important, confidential information from its users by storing these tasks in a subprogram. Since the user can only invoke the subprogram, not view or edit it, any sensitive information is protected. Furthermore, having a stored subprogram saves the programmer from designing anapplication that has to repeatedly send dynamically-generated SQL strings to the database. This means the programmer does not have to worry about SQL injection exploits, SQL string sanitization, or any other possible caveats that appear when using dynamic SQL to communicate with front-end database management systems.
Oracle PL/SQL
Most PL/SQL programs follow a similar structure regardless of their purpose. Code statements are organized into blocks. There are three main sections of a block:
Declaration: Declaration of variables, cursors, and user-defined exceptions are made here.
Execution: This portion consists of the SQL statements that perform the task’s job.
Exception: This section catches any exceptions, either system or user-defined, raised during execution of the task.
Layout:
DECLAREvariable_name variable_type := value | DEFAULT
BEGINSELECT | INSERT | UPDATE | DELETE
END;
Variable types:
All variable types supported by the Oracle server should be supported in PL/SQL. This includes numbers, floating points, character arrays, dates, unique IDs, and more.
Cursors:
Cursors are user-defined SQL statements that allow structured traversal of a table using a loop structure. They are defined using the following syntax:
DECLARECURSOR cursor_name [parameters]IS select_statement;
After creation, a cursor can be used in the following format:
BEGINFOR t in cursor_name LOOP
Perform tasksEND LOOP;
END;
Control statements
Control statements manage the logical flow of a PL/SQL subprogram. Since PL/SQL is a procedural language, the location and usage of these statements is extremely important. The following are example control statements:
IF condition THEN statement;ELSEIF condition THEN statement;END IF;
LOOPEXIT WHEN can be used to quit this loop
END LOOP;
FOR I IN lowerbound .. upperbound LOOPstatement
END LOOP;
FOR cursor_variable IN cursor_name LOOPstatement
END LOOP;
Exception Handling
PL/SQL allows users to catch and raise exceptions under certain conditions. The syntax to raise and handle exceptions is simple:
DECLAREUser_defined_exception EXCEPTION;
BEGINIF condition THEN RAISE User_defined_exception;END IF;
EXCEPTIONWHEN Exception_name THEN statement;
END;
Stored procedures
Stored procedures can greatly facilitate performing complex jobs on the SQL server’s data while maintaining abstraction for non-technical users. The structure of a stored procedure depends largely on the type of work it will be performing, but the syntax is the same for all of them:
CREATE [OR REPLACE] PROCEDURE procedure_name[ (variablename IN|OUT variabletype)]AS(DECLARE variables go here)BEGIN
SQL statementsEND;
Execution of a stored procedure from SQL*PLUS can be accomplished as follows:
SQL> exec sp_name(arguments go here);
Stored functions
Stored functions are created and run in a method very similar to the syntax for stored procedures. However, they differ by explicitly declaring a variable type to return after completion. These can be used to guarantee that a variable will be returned. The syntax is as follows:
CREATE [OR REPLACE] FUNCTION function_name[ (variablename IN|OUT variabletype)]RETURN datatype;AS(DECLARE variables go here)BEGIN
SQL statements;RETURN variable;
END;
Packages
Packages are a distinct collection of procedures and functions. Creating a package requires a prototype for each included procedure and function:
CREATE PACKAGE package_name ASPROCEDURE names..;FUNCTION names…;
END package_name;
CREATE PACKAGE BODY package_name ASPROCEDURE name IS…BEGIN
StatementsEND;
FUNCTION name RETURN DATATYPE IS…BEGIN
StatementsRETURN variable
END;
END package_name;
Triggers
Triggers make collecting records, logs, and audits extremely easy. Instead of managing this task and forcing users to use pre-defined stored procedures and packages that manually execute tasks, triggers are executed when a certain condition is met, depending on the action (UPDATE, DELETE, INSERT, etc). Since these tasks are automated after the trigger’s creation, the user does not have to worry about maintaining or checking data before or after the operations.
CREATE [OR REPLACE] TRIGGER trigger_nameBEFORE|AFTER INSERT|DELETE|UPDATE OF COL [column_name] [OR DELETE|UPDATE|INSERT]ON table_nameDECLARE variablesBEGIN
FOR EACH ROW[WHEN CONDITION]Statements;
END;
Oracle PL/SQL Subprograms
This database makes use of several subprograms. There are 3 procedures, 2 functions, and 2 triggers.
Stored procedures
nt_sp_delete_employee
This stored procedure is invoked to delete a record from nt_employee. The procedure is created using the following code. Note that instead of using a cascaded delete to remove any related records from the other tables, the stored procedure simply has 3 delete statements to cover the appropriate tables nt_possesses, nt_teamhistory, and nt_employee. In a larger database, this is hard to manage and quickly becomes inefficient, and a cascaded delete alternative is preferred.
CREATE OR REPLACE PROCEDURE nt_sp_delete_employee( usID IN NUMBER)AS
BEGIN DELETE FROM nt_teamhistory WHERE UserID = usID;
DELETE FROM nt_possesses WHERE UserID = usID;
DELETE FROM nt_employee WHERE UserID = usID;END;/
nt_sp_insert_employee
This stored procedure inserts a new record into nt_employee. All of the constraints on the nt_employee are observed and will be raised as SQL exceptions. There is no exception handling in this statement, but including such an option can let the application inform the user and provide appropriate responses or solutions. The code for it is as follows:
CREATE OR REPLACE PROCEDURE nt_sp_insert_employee( usID IN NUMBER, usName IN VARCHAR2,
fName IN VARCHAR2, OE IN NUMBER, Loc IN VARCHAR2, BT IN NUMBER, StD IN VARCHAR2)ASBEGIN INSERT INTO nt_employee VALUES ( usID, usName, fName, OE, Loc, BT, to_date(StD, 'mm/dd/yyyy') );END;/
nt_sp_getteamavg
This stored procedure returns an average from a table, though with some advanced options. The stored procedure returns the average number of skills per user on each team. This requires the use of 2 extra functions, which will be listed in the next section. Finding the average from the highest or lowest n populated teams would require the use of additional variables or temporary tables, but it can be donein Oracle 8i. The code is as follows:
CREATE OR REPLACE PROCEDURE nt_sp_getteamavgASavgteamskills NUMBER := 0;no_skills NUMBER := 0;no_teammembers NUMBER := 0;
CURSOR teams IS SELECT TeamID FROM nt_team ORDER BY TeamID;CURSOR employees IS SELECT UserID, Belongs_To FROM nt_employee ORDER BY UserID;
BEGINFOR t IN teams LOOP avgteamskills := 0; no_skills := 0; no_teammembers := nt_f_getTeamMembers(t.TeamID); FOR e IN employees LOOP IF e.Belongs_To = t.TeamID THEN no_skills := no_skills + nt_f_getEmployeeSkills(e.UserID); END IF; END LOOP; avgteamskills := trunc(no_skills/no_teammembers, 3); DBMS_output.put_line('TeamID = ' || t.teamid || ', avg skills per user on team = ' || avgteamskills);END LOOP;END;/
Two cursors are used to traverse the teams in nt_team and the employees in nt_employee. The functions nt_f_getTeamMembers() and nt_f_getEmployeeSkills() are detailed in the next section.
Functions
To make design of the nt_sp_getteamavg stored procedure clear and concise, I’ve decided to create and use two separate functions to keep the code organized and maintainable. To do this, I made the following two functions:
nt_f_getTeamMembers(teamID)
This function returns the number of employees on a given team. It is created using the following code:
create or replace function nt_f_getTeamMembers(tmID IN number) return number is team_members number(10); begin select count(*) into team_members from nt_employee where Belongs_To = tmID; return(team_members); end;/
nt_f_getEmployeeSkills(employeeID)
This function returns the number of skills a given employee possesses. It is created using the following code:
create or replace function nt_f_getEmployeeSkills(eID IN number) return number is e_skills number(10); begin select count(*) into e_skills from nt_possesses where nt_possesses.userid = eID; return(e_skills); end;/
Triggers
I made use of two triggers for my tables. These triggers handle the deletion and update of records in the tables nt_focuseson and nt_employee. They are as follows:
nt_tr_update_employee
This trigger inserts an employee’s current team and start date for the current team into nt_teamhistory. This is done because the employee’s record is being assigned a new team. The purpose of the nt_teamhistory table is to record such changes andintervals of team membership, so the functionality of triggers is perfect for making this task easy.
CREATE OR REPLACE TRIGGER nt_tr_update_employeeBEFORE UPDATE ON nt_employee FOR EACH ROW WHEN (old.Belongs_To <> new.Belongs_To)BEGIN INSERT INTO nt_teamhistory VALUES (:old.UserID, :old.Belongs_To, :old.StartDate, SYSDATE);END;/
nt_tr_update_focuseson
Similar to the previous trigger, this trigger records changes made on the nt_focuseson table. The trigger saves the record to be deleted from nt_focuseson into a new table, nt_focuseson_logtable. This can be used to observe a given team’s former Types of Work focuses and goals.
CREATE OR REPLACE TRIGGER nt_tr_update_focusesonBEFORE DELETE ON nt_focuseson FOR EACH ROWBEGIN INSERT INTO nt_focuseson_logtable VALUES(:old.TeamID, :old.TOWID);END;/
Phase V: GUI Design and Implementation
Daily user activities
There are several types of user for this type of database. Some users simply need to view their skills and the types of work they’re capable of performing. Others need to be able to add new users or teams. Simple users may not even need to access the database – the information they need could be generated by a report and sent by email. Due to the nature of the database and its capabilities, I have classified potential database users into the following categories:
Uninvolved users
Database users who fall under this category do not need to access the database directly. Instead, they rely on daily reports that are extensive enough to give them the information they need to complete their work. For this database, these users would be employees that are not team managers. They will need a daily report of their assigned skills and possible types of work. After receiving this, they can perform their work for the day. To reflect training or team transfers, these users will have to stay in contact with their team managers, who fall into the next category.
Team managers
Team managers need to be able to add and remove employees from their teams. They need access to their team’s information so they can update or modify it when necessary. To serve their employees, they should have access to an employee’s listof skills so they may add or remove them to reflect their training and capabilities. These users should receive a daily report detailing their team’s member count and the types of work the team is supposed to focus on. With this information, the teammanagers can instruct their employees to learn the appropriate skills so they can meet their goals, based on the types of work they focus on. They should not be able to change the types of work that their team focuses on. That should be a supervisor decision and not trusted in the hands of the team’s own manager. If thatwere the case, then any team manager could simply remove any types of work goals for their team.
With these categories in mind, the application will be built around the needs of the team manager.
Relations, views, and subprograms
The application needed to meet the requirements listed above needs access to almost every relation in the database. Each of the following will have its own TableAdapter object in code to facilitate data access and manipulation:
nt_employee nt_team nt_skills nt_tow nt_requires nt_possesses nt_teamhistory nt_focuseson
Furthermore, there must be a few additional views constructed to represent some ofthe more complicated joins and relationships in the database. For example, nt_capabletows represents the types of work a user is capable of performing based on their possessed skills. In relational algebra, this could be expressed with the following formula:
π (towid) ( nt_requires ÷ π (skillid) (σ (skillid = userid) nt_possesses)
In English, this can be stated as “Select all types of work whose required skills are possessed by a given user.” Division operations are not as intuitive or easy in Oracle 8i SQL as they are in relational algebra. The following code represents the same query:
SELECT c.towid, tow.nameFROM NT_TOW tow, NT_REQUIRES r, NT_POSSESSES p,(SELECT towid, count(*) AS count2FROM NT_REQUIRESGROUP BY towid) cWHERE r.towid = tow.towidAND p.skillid = r.skillidAND c.towid = r.towidAND p.userid = ?GROUP BY p.userid, c.towid, tow.name, c.count2HAVING c.count2 = count(*)
For queries that require repetitive calls with different parameters, a stored subprogram or TableAdapter object is created. This is one of the more complicated views in the application. Fortunately, the rest are fairly intuitive and easy to represent using normal SQL.
Application screen shots
For an application to be functional and intuitively easy to use, its layout must be discrete, concise, and logically organized. Too much functionality can be just as bad as not enough, especially when the application is used infrequently enough thatthe user cannot remember its layout between uses. The application built to access and modify this database is designed to be employee-record driven. That is,
selection and manipulation of employees produces the most useful information about the database. However, it remains functional enough that the user can modify teams, create skills mappings, and generate reports without much searchingor difficulty.
Menu
The menu consists of 4 main options: Main, Teams, Skills, Types of Work. Each one will now be described in detail:
Main
Main consists of only two options. The program automatically connects to the database, so there is no need to give the user access or control over that. Nearly all of the work to be done on employee records is accessible directly through buttons on the actual form, so those are omitted from the menu. Instead, the Main menu allows the user to generate an employee report, or exit the form. The exit option will confirm the user wants to quit before closing the form. The report optionwill open up a new window consisting of the following information:
Employee: [Employee Name] Team ID: [Team ID]======================Skills:[List of skills the employee possesses]======================Types of work:[Types of work the user can perform]
This is repeated for each employee. This provides enough information about the employee that summarizes their abilities and qualifications for their daily work.
Teams
The Teams menu allows the user to view a list of all teams, edit the team selected from the main form, create a new team, or generate a team report. The list of all teams appears in a new window and allows the user to see all information about all teams immediately. The options to edit and create teams open up two very similar forms. This allows the user to put in brand-new information for a new team, or change existing information about a current team and save the changes. The report generated will detail the following information for each team:
Team [TeamID] | Member count: [Member count of team]Types of Work:[Types of work that the team should focus on]
This report has enough information for team managers to determine what training they should recommend for their team, given their focused types of work and the number of team members they have.
Skills and Types of Work
These two menus have one option each: View. View will load a new form detailing all of the available skills or types of work. For the types of work form, the user can select an individual type of work and press a button to view that type of work’s necessary skills. This can let the user quickly look up what skills to teach to an employee in order to perform that type of work. This process is displayed below:
Main form
The program’s main form is displayed above. When the application loads, this form is built and populated with corresponding data. The main DataGridView (1) lists all of the database’s current employees and the information for each one. This lets theuser quickly see their username, office extension, location, and team information.
When the user selects a row from (1), the rest of the sections are updated to reflect the change of selection. The SkillsBox (2) displays the skills the selected user possesses, and the PotentialTOWBox (3) lists the types of work that the selected user is capable of doing. Pressing the “Add skill” button in this section brings up a form with a list of skills that the user does not possess. Clicking “Add” on this form will immediately show the changes made: (2) will now have the added skill, and the form of unpossessed skills will no longer have it. Likewise, since each type of work has different skill requirements, adding or removing skills requires an update to (3). Clicking “View necessary skills” when a type of work is selected in (3) will load a form populated with the skills needed to complete the selected type of work. This isdone for quick and easy lookup when determining which skills an employee should learn.
To view an employee’s past teams, the user can press “Show employee’s team history” under (1). This will load a form consisting of the team IDs for all teams the selected employee has belonged to. Selecting a row from (1) also changes the information in the TeamInfoGridView (4). This shows the information for the selected user’s team, allowing the application user to quickly bring up all information about an employee’s team. Doing this allows them to also select the team from (4) and edit its information. Clicking “Edit team” in this section brings up
a form loaded with the team’s information. The user can then change everything but the team’s ID, to avoid conflicts with the database primary key constraint. Theycan also designate a new team manager, or optionally keep the same manager. Selecting a new team manager requires that the new manager switch to the currently-selected team. This triggers an update on the employee table in the database to reflect this change, and (1) is updated accordingly.
Code Description and GUI Design
User interface design
Initially, my proposed GUI for this application resembled this layout:
When building the data adapters for my application, I soon realized that this design could not meet the needs of the user in a concise, logical manner. By trying to oversimplify the process of data management, I in fact made it much more convoluted. This led to my current design, described in the previous section. I chose this design because it focuses on one aspect of the database: the employee. Accessing an employee’s record brings up corresponding records for skills, types of work, and teams. Doing this lets the user remain focused on how to perform their necessary tasks without searching for how to do so on a messy form.
The application’s GUI design changed as I built it. While organizing its views and displays, I had to think about what I would prefer to use if I were using this program every single day. Thinking in this state of mind helped me come up with something intuitively easy to use for complicated tasks. Had I more time, I would have liked to include options for printing and saving records into the menu. However, the records
are completely accessible and capable of being copied, and thus can be printed using unrelated applications. Still, even if a user has to print something just once per month, it’s worthwhile to include this sort of functionality into the program.
Any fields that the user has access to when entering or modifying data are controlled and placed under restrictions. These prevent overflow errors, foreign keyconflictions, relational integrity, and general exceptions. However, on certain input forms that are prone to exceptions from the server, there are blocks of code to catch exceptions so the program will gracefully alert the user about the error and continue to run. Without adequate time to check and test for these sorts of problems, there will almost always be a weakness in the final application. For thesereasons, error checking and exception handling are critical for any GUI application, especially one that has access to a sensitive database.
Data access descriptions
One of the most powerful features of .NET in Visual Studio 2005 is the ability to create and use Datasets. Described as a single file, Datasets can hold information about:
Connecting to a database or data provider (Oracle, OLEDB, Microsoft SQL, Access, flat file)
Creating adapter objects (TableAdapters) that can contain multiple queries topopulate local tables given a SQL statement.
Inserting, updating, and deleting records from the database it connects to
Functionalities like this make it an incredibly powerful feature to use when building an application for database access. They do not do anything that cannot be done programmatically through code, but their use can account for fast deployment and easy modification when time is a factor. Adding a TableAdapter to a dataset will prompt the user for a SQL statement or stored procedure on the server that will retrieve the data to be represented by the adapter. Building the TableAdapter automatically builds a datatype of that same query. For example, the NT_POSSESSESTableAdapter has functions to return all records from nt_skills, all records that match a certain userid, and all records that match a certain skillid. Creating these additional queries is still done by hand, so the adapter does not perform the work for you. However, it’s a very efficient way of keeping these functions organized. In code, a DataTable of that type (such as an NT_POSSESESDataTable) will contain fields that match the table in the database that the TableAdapter relates to. Populating such a table can be done in code as follows:
1 NT.NT_POSSESSESDataTable possesses = new NT.NT_POSSESSESDataTable();2 NTTableAdapters.NT_POSSESSESTableAdapter ntp = new NTTableAdapters.NT_POSSESSESTableAdapter();
3 ntp.FillByUserID(possesses, 3);
This segment of code will (1) create a new empty DataTable, (2) create a new TableAdapter for the table, and (3) fill the DataTable with results that use the
parameter 3. After completing this, a control such as a ListBox or DataGridView canbe bound to it by setting its DataSource property to the DataTable variable. Any time an employee is selected, the DataTables for skills, types of work, and teams are cleared, reloaded, and have their views refreshed to reflect the change of selection. This cuts down on coding time and makes reading such powerful code very easy if changes or updates have to be made.
The Dataset for this project is called NT.xsd, and a graphical representation of it is as follows:
To facilitate data access, I created an adapter for each table from the database, andadapters for advanced queries (such as the adapter representing the query to return types of work a given user is capable of performing, described in a previous section). As you can see, adding TableAdapters for tables with constraints updates the graphical view to represent such constraints and cardinality mappings. This allows for a quick, simplified glimpse at the database’s structure without having to refer to its original relational or E-R models. This dataset contains a ConnectionString to the database server, so any TableAdapter requesting results from a query is automatically set up and authorized to perform the work. As far as data management goes, the use of this dataset can definitely be considered a feature of the application.
Class descriptionsNearly every class in this application represents a form object. The use of TableAdapters facilitates data access enough such that the structure of the application relies mainly on its forms.
DBForm
This is the main form of the application. This is displayed when the application is first opened, and contains the views, grids, and menus listed in the previous sections. Its most important functions are
Managing event handlers for when new rows are selected or when buttons are pressed
Refreshing views and grids on selection changes Providing access to all child forms
At any given time during the application’s execution, there is only one instance of the DBForm class. This is to prevent problems with concurrency when accessing the database.
ReportForm
This class holds the form to display a report. A report is passed to its constructor asa string, which is then loaded into a specially-formatted textbox before being displayed to the user. This same class is used for both reporting capabilities found in the application.
AddSkillForm
This class holds the form launched when adding new skills to a user. The form contains a listbox that is populated by a TableAdapter, which returns all of the skills not possessed by a user. Selecting a skill and clicking “Add” calls the adapter’s Insert method to insert a record into the database representing possession of the skill by the user. Like every other add/edit form in this application, a reference to the parent form is passed to the constructor. This is done so that the child form can call its parent’s functions, such as refreshing the views after insertion. This could be done through event handlers in the parent class for when the child class is closed, but this method produces immediate updates.
AddUserForm
This form allows the application user to fill out information for a new employee, assign them a team, and insert them into the database. Doing this requires a refresh on the parent form’s views, so a reference to the parent form is passed in the constructor.
AddTeamForm
This form allows the application user to fillout information for a new team, assign them a manager, and insert them into the database. Assigning a manager requires that manager’s record to be updated and their team changed, so an additional TableAdapter is created for this purpose.
EditTeamForm
This form takes a DataRow as a parameter so that the form’s fields can be populated with the team’s current information. Doing this allows for very fast edits and changes without needless typing. The same technique is used on the EditUserForm. Every field can be changed except for the Team’s ID field. This is a primary key and is not allowed to be changed by the application user.
EditUserForm
Like the previous form, this receives a DataRow in its constructor as a parameter to populate its fields. Again, the primary key for the nt_employee table, USERID, is read-only for the database user.
NecessarySkillsForm
This form’s constructor receives parameter’s representing the TOWID and NAME from the parent form’s selected type of work. It uses that information to properly label the form’s title and retrieve the skills needed to perform the type of work using a TableAdapter.
TeamHistoryForm
This form is launched to show a selected user’s team history. The form’s constructor requires a USERID that can be used to retrieve the results using a TableAdapter
ViewSkills
This form is launched from the menu. It provides quick and fast access to a list of all available skills in the database. No updates, inserts, or deletes are allowed on this list from the application since the application user (a team manager) is not authorized for such operations.
ViewTeams
This form lists all of the teams in the database. For any given team, its id, name, description, and manager are displayed. This provides fast access to a list for reference.
ViewTOW
This form displays a list of all types of work in the database. After clicking on a typeof work, the user can click a button to display the type of work’s required skills. This is done as an additional function in the form’s class.
Major features
As stated before, the menu provides functionality to generate reports for employeesand teams. These reports hold enough detailed information to allow other users to perform their work for the day without any additional access to the database.
For the actual application user, however, there are several nice features. The main form provides easy-to-access buttons to look up related records for reference. Furthermore, the use of child forms for adding, editing, and viewing allows the application user to keep additional forms open with the information they need, whilestill being perfectly capable of using the main form to do work on the database.
Thanks to the structure and organization of the application’s data and table adapters, the user does not need to worry about logging into the database to perform their work. This means they do not need to receive any unnecessary or sensitive information regarding database access, accounts, or passwords.
Development process
Although C# and database programming are not completely new to me, combining these concepts into a desktop-based application is a new experience. I’ve had practice writing ASP.NET pages using C# and accessing Microsoft SQL databases, but there are fundamental differences in code organization and abilities between the two platforms. Desktop programming allows for faster, easier access to the database without having to worry about security issues from the browser, but it brings up new issues about local exploits, de-compilation, and password cracking. For the purposes of this project, these issues are mostly non-existent. However, they become very relevant on actual assignments for clients with sensitive data. Because of this, I tried to follow coding examples from developers at Microsoft, reading blogs on MSDN and looking at tutorials on ASP.NET’s official website. Sincewe’re using Microsoft software and fundamentals to write this application, it’s only logical that we make the best use out of its strengths
Designing and implementing the application
Drawing from my experiences working with databases and ASP.NET pages, I decided to start designing my application using a similar fashion to the one used forweb-based applications. For a professional, well-designed website that accesses a database, access to the database follows this model:
Client-side browser -> Webpage -> Business Logic Layer -> Data Access Layer -> Database
The business logic layer is represented by classes that have strict control over TableAdapters from the Data Access Layer. This allows the designer to implement rules and exceptions for entries that are sound data-wise, but violate some specific business rule. The data access layer represents the adapters needed to access the actual database. For this project, I have omitted the business logic layer for the sake of time and efficiency (they add more overhead and take more time to code properly). A modified model for my application is this:
Client-side desktop application -> Data Access Layer -> Database
Since I started with designing the database, I moved next to the Data Access Layer. Here, I built the adapters I thought I would need for the actual application. Doing this made building the desktop application fairly straightforward. I rarely had to work backwards to implement things I had forgotten or needed to change, and mostobjects connected together successfully without much alteration.
With my dataset complete, I began to focus on the actual application. I threw out my original graphic design in the interest of efficiency and usability. It was here I learned how important it is to look at the application from the perspective of the user who will be using it every single day. That can seriously alter your ideas and help you build a faster, cleaner GUI for a very thankful user.
After completing the application’s basic structure and functionality, I began to perform minor error-checking and exception handling. Thanks to my design structure, most of these were trivial and very easy to fix. I spent enough time
planning the application and the database structure to avoid pitfalls I would have had if I had jumped into designing first. Although the application is not bullet-proof, it demonstrates the functionality needed for a normal team manager in the environment described in this project. There is a minimal amount of exception handling to show that even with improper data or database constraint violations, the client-side application is capable of handling these exceptions gracefully, allowing the user to continue their work quickly and correctly.
Conclusion
The idea for this project came from my own experiences with a handful of very intelligent people at State Farm during the course of my internship. It was there I received my first exposure to a real-world programmer’s environment, challenges, and expectations. The lessons learned there continue to help me improve the way Iwrite code, design layouts, and conquer problems. The database designed and documented in this project is only a small, trivial representation of the actual complexity in State Farm’s business flow, but I hope it serves to demonstrate that the trivial example must be thoroughly and completely understood before attempting the nontrivial problems. Because of this, I would like to thank the EUC team at State Farm for the inspiration they’ve given me to tackle the big ones.
