Deliverable 4
advertisement
Deliverable 4
ISQS 6338: Database Concepts
Jeff Morris
Derrick Plunk
Brian Wilder
12/2/2009
Deliverable 3
November 13, 2009
Table of Contents
Deliverable 1 (Revisions) ............................................................................................................................... 1
Introduction .............................................................................................................................................. 1
Database Analysis ..................................................................................................................................... 2
Business Rules ....................................................................................................................................... 3
Response Time ...................................................................................................................................... 3
Conceptual Data Model ........................................................................................................................ 3
Identification of Object Types ........................................................................................................... 4
Identification of Relationship ............................................................................................................ 4
Object Oriented Data Model .................................................................................................................... 5
Deliverable 2 (Revisions) ............................................................................................................................... 1
Initial Relational Data Model .................................................................................................................... 1
Definition of Attributes ............................................................................................................................. 2
Admissions ............................................................................................................................................ 2
Admissions_Programs ........................................................................................................................... 2
Advisors ................................................................................................................................................. 2
Classifications ........................................................................................................................................ 2
Concentrations ...................................................................................................................................... 3
Courses.................................................................................................................................................. 3
Curriculums ........................................................................................................................................... 3
Degrees ................................................................................................................................................. 4
Descriptions .......................................................................................................................................... 4
Descriptions_Levels .............................................................................................................................. 4
Divisions ................................................................................................................................................ 5
Groups ................................................................................................................................................... 5
Page ii
Deliverable 3
November 13, 2009
Groups_People...................................................................................................................................... 5
Groups_Permissions ............................................................................................................................. 5
Levels..................................................................................................................................................... 6
People ................................................................................................................................................... 6
People_Positions ................................................................................................................................... 6
Permissions ........................................................................................................................................... 7
Positions ................................................................................................................................................ 7
Programs ............................................................................................................................................... 7
Requirements ........................................................................................................................................ 7
Normalization of Relations ....................................................................................................................... 8
Final Relational Data Model .................................................................................................................... 11
Validation of Relational Data Model ....................................................................................................... 12
Non-Functional Requirements ................................................................................................................ 17
Volume ................................................................................................................................................ 17
Security Needs .................................................................................................................................... 18
Response Time Expectations .............................................................................................................. 18
Integrity constraints: ........................................................................................................................... 18
Deliverable 3 (Revisions) ............................................................................................................................. 19
Physical Database Design ........................................................................................................................ 19
Admissions .......................................................................................................................................... 19
Admissions_Programs ......................................................................................................................... 19
Advisors ............................................................................................................................................... 19
Classifications ...................................................................................................................................... 19
Concentrations .................................................................................................................................... 19
Courses................................................................................................................................................ 20
Page iii
Deliverable 3
November 13, 2009
Curriculums ......................................................................................................................................... 20
Degrees ............................................................................................................................................... 20
Descriptions ........................................................................................................................................ 20
Descriptions_Levels ............................................................................................................................ 20
Divisions .............................................................................................................................................. 21
Groups ................................................................................................................................................. 21
Groups_Permissions ........................................................................................................................... 21
Groups_People.................................................................................................................................... 21
Levels................................................................................................................................................... 21
Permissions ......................................................................................................................................... 21
People ................................................................................................................................................. 22
People_Positions ................................................................................................................................. 22
Positions .............................................................................................................................................. 22
Programs ............................................................................................................................................. 22
Requirements ...................................................................................................................................... 22
Database Size (Disk Space Requirement) ............................................................................................... 23
Deliverable 4 ............................................................................................................................................... 25
Database Implementation ...................................................................................................................... 25
SQL Code to Generate Tables ............................................................................................................. 25
Data Population of the ISQS_Website Database .................................................................................... 30
SQL Code to Populate Tables .............................................................................................................. 31
Stored Procedures .................................................................................................................................. 40
Query 1................................................................................................................................................ 40
Stored Procedure SQL ..................................................................................................................... 40
Stored Procedure Output................................................................................................................ 40
Page iv
Deliverable 3
November 13, 2009
Query 2................................................................................................................................................ 41
Stored Procedure SQL ..................................................................................................................... 41
Stored Procedure Output................................................................................................................ 41
Query 3................................................................................................................................................ 42
Stored Procedure SQL ..................................................................................................................... 42
Stored Procedure Output................................................................................................................ 42
Query 4................................................................................................................................................ 43
Stored Procedure SQL ..................................................................................................................... 43
Stored Procedure Output................................................................................................................ 43
Query 5................................................................................................................................................ 44
Stored Procedure SQL ..................................................................................................................... 44
Stored Procedure Output................................................................................................................ 44
Query 6................................................................................................................................................ 45
Stored Procedure SQL ..................................................................................................................... 45
Stored Procedure Output................................................................................................................ 45
Query 7................................................................................................................................................ 46
Stored Procedure SQL ..................................................................................................................... 46
Stored Procedure Output................................................................................................................ 46
Query 8................................................................................................................................................ 47
Stored Procedure SQL ..................................................................................................................... 47
Stored Procedure Output................................................................................................................ 47
Query 9................................................................................................................................................ 48
Stored Procedure SQL ..................................................................................................................... 48
Stored Procedure Output................................................................................................................ 48
Query 10.............................................................................................................................................. 49
Page v
Deliverable 3
November 13, 2009
Stored Procedure SQL ..................................................................................................................... 49
Stored Procedure Output................................................................................................................ 49
Query 11.............................................................................................................................................. 50
Stored Procedure SQL ..................................................................................................................... 50
Stored Procedure Output................................................................................................................ 50
Query 12.............................................................................................................................................. 51
Stored Procedure SQL ..................................................................................................................... 51
Stored Procedure Output................................................................................................................ 51
Query 13.............................................................................................................................................. 52
Stored Procedure SQL ..................................................................................................................... 52
Stored Procedure Output................................................................................................................ 52
Query 14.............................................................................................................................................. 53
Stored Procedure SQL ..................................................................................................................... 53
Stored Procedure Output................................................................................................................ 53
Query 15.............................................................................................................................................. 54
Stored Procedure SQL ..................................................................................................................... 54
Stored Procedure Output................................................................................................................ 54
Query 16.............................................................................................................................................. 55
Stored Procedure SQL ..................................................................................................................... 55
Stored Procedure Output................................................................................................................ 55
Query 17.............................................................................................................................................. 56
Stored Procedure SQL ..................................................................................................................... 56
Stored Procedure Output................................................................................................................ 56
EXEC GetGroupsByPerID
1 ............................................................................................... 56
Page vi
Deliverable 4
December 2, 2009
Deliverable 1 (Revisions)
Introduction
The Information Systems and Quantitative Sciences (ISQS) Department of Texas Tech University
(TTU) teaches its students to create programs and sites for use on the web. Unfortunately, the website
that potential and current students go to learn more about this department is antiquated. It is the
feeling of our group that the current website is not representative of the skill current TTU ISQS students
possess.
The source of the website’s problems lies in the fact that the information has been hard-coded
in and is not easily modifiable. This has made it difficult for administration to make changes necessary to
the website. Our group proposes that a database driven administration panel would solve these
problems and allow ISQS faculty and staff the ability to make these changes to the website quickly and
easily.
Each administrative person has a position in the ISQS department. These administrative people
include faculty, staff and PH.D. students who teach classes. These administrators will all need to be a
part of a group in order to be allowed the proper permission to alter the website through the database
driven platform. These people will also advise for different programs.
The programs the administrators advise have many different degrees, and each degree is
associated with a level; for example, a Bachelor's in Business Administration would be considered an
undergraduate degree. Each of these levels should provide a description that can be issued wherever
appropriate. Each program has admission requirements that may or may not be identical to basic level
admission requirements. Some programs may have a concentration in a particular discipline.
A program (and its associated concentration, where applicable) will be made up of curriculum
that is required. These curriculum can be split up into several different Divisions and each Division will
have a number of courses that meet the selected criteria.
We will use this information to create a Conceptual Data Model that will help us get started
building a database to serve as the back end of the ISQS website. It is our hope that we can create a
database that will be modifiable by faculty and staff to better relay information to users.
These changes to the information the database holds will occur at least every semester.
Instructors and staff will access the database to change its contents according to what needs to be
displayed for the upcoming academic period. The instructors may alter the courses they teach, the
description of those courses, personal contact information, and more. These courses and descriptions
and additional information will then be accessed by the students so that they can get the information
necessary.
Page 1
Deliverable 4
December 2, 2009
The database should be able to answer the following queries:
1)
2)
3)
4)
5)
6)
7)
8)
9)
10)
11)
12)
13)
14)
15)
16)
17)
Who are the faculty members for the ISQS Department?
What programs does a faculty member advise?
What are the required courses to complete a given program?
What programs are offered for a particular degree (BBA, MBA, and Ph. D)?
What are the admission requirements for a given program?
What is the description of a given program?
What people have permission to modify the content?
What are the permissions for a given person?
What is the classification of a given person?
What courses are needed for a specific concentration?
What are the admissions requirements for a given level?
What courses are available for a degree?
Which positions advise undergraduate degrees?
What is the description of a specific concentration?
What Divisions does a course fall under?
What level is a program associated with?
What group has a specific permission?
It is imperative that the database solution be efficient, flexible, and scalable as the university
may encounter huge increases due to its commitment to continue growing every semester. Also, the
database needs to be secure to keep confidential information out of view of the public, allowing only
staff and students to see the required information.
Database Analysis
Database analysis allows the developer and the client to develop and discuss the business rules
to make an efficient database model, which allows for an optimized solution that appropriately solves
the problem that was described above. Furthermore, it is imperative that any limitations that need to be
placed on the database are discussed, which will help keep data integrity in mind throughout the whole
process. Lastly, you must discuss response time and the physical data model needs such as security
concerns.
Page 2
Deliverable 4
December 2, 2009
Business Rules
Business rules are what define how a process is properly performed. It is the job of the analyst
to work with the client and determine what policies, calculations, regulations, and other constraints
exist within the process. This also covers the topics of data security and/or specific user requirements.
The following ISQS website business rules have been identified as per the needed database:
1) People must be part of a group to receive permissions.
2) Each person who holds a position must also have a classification as staff, faculty or PH.D
student.
3) Each Program must have an advisor.
4) Each Program must lead to a degree.
5) Each degree should be associated with an appropriate level.
6) Each level has a description.
7) A program has certain Admission requirements that should be displayed on the database.
8) A program can have a concentration.
9) Each Program, and consequently each concentration, has a set curriculum.
10) Each curriculum must have at least one Division.
11) Each Division may have many courses.
Response Time
The ISQS department website is an imperative part of recruitment for Texas Tech University.
Therefore tasks processed by the database such as reports, queries, and queries reports need to happen
in an efficient and timely manner. It is necessary for the website to be available as close to 99.99%
uptime as possible. In addition, the response time for each page should be no more than two or three
seconds, as anything longer might discourage users from applying to Texas Tech University.
Conceptual Data Model
Based on the needs of an ISQS department website, an object oriented data model was
developed after analysis of the business requirements. The first step was to identify all the object types
involved and then identify how they relate to each other.
Page 3
Deliverable 4
December 2, 2009
Identification of Object Types
Based on the problem described above, below are the object types needed to solve the problem:
Admission with attributes: AdmID, AdmTitle, and AdmBody
Classification with attributes: ClassID and ClassName
Course with attributes: CourseID, CourseSubject, CourseCallNumber and CourseName
Curriculum with attributes: CurrID, CurrTitle, CurrDesc and CurrDocLocation
Concentration with attributes: ConID and ConName
Degree with attributes: DegreeID, DegreeAbbrev and DegreeName
Description with attributes: DescID, DescTitle and DescBody
Division with attributes: DivID, DivTitle, DivSubTitle, DivBody and DivOrder
Group with attributes: GroupID and GroupName
Level with attributes: LevelID, LevelName and LevelOrder
Person with attributes: PersonID, PersonPrefix, PersonFirstName, PersonLastName,
PersonOffice, PersonEmail, PersonPhone, PersonWebsite, PersonDisplay, eRaider, rNumber and
UserActive
Permission with attributes: PerID and PerAction
Position with attributes: PosID and PosName
Program with attributes: ProgramID, ProgramTitle, ProgramDescLess and ProgramDescMore
Identification of Relationship
After careful analysis of the business rules, the following relationships exist between object types:
There is a many to many relationship between Course and Division
There is a one to many relationship between Curriculum and Division
There is a one to many relationship between Concentration and Curriculum
There is a one to many relationship between Degree and Program
There is a one to many relationship between Level and Degree
There is a many to many relationship between Program and Admission
There is a many to many relationship between Level and Description
There is a many to many relationship between Program and Person
There is a many to many relationship between Person and Position
There is a one to many relationship between Classification and Position
There is a many to many relationship between Person and Group
There is a many to many relationship between Group and Permission
There is a one to many relationship between Programs and Concentrations
Page 4
Deliverable 4
December 2, 2009
Object Oriented Data Model
Once we have examined the business rules and established our conceptual data model, our next
task is to create an Object Oriented Data Model (OODM). This model will show the different object
types and how they relate to each other. The OODM will also display the cardinality for each
relationship, and show which relationships are total and which ones are partial.
Our OODM begins with our permission, group and person objects. These object types will house
the data pertaining to who can access certain areas of the website and what they can use the website
for. Permission and Group have a partial participation relationship - a permission may apply to a specific
group and a group may have a specific permission assigned to it. The same type of relationship is
displayed between Group and Person- a group may involve one specific person and a person may
belong to one specific group.
Next our model finds itself defining persons by the programs they are associated with, the
positions they hold and the classification of that position. A person may hold no position, or a person
may hold many positions. A position may be held by a person, or it may be vacant. This leads to a
partial relationship between Position and Person. Position and Classification have a total participation
relationship - every classification must be associated with a position and a position must have a
classification. A person may be related to no program, or a person may be related to many programs. A
program may have many people associated with it, or it may have no one associated with it. This leads
to a partial participation relationship between Program and Person.
From Programs, our model splits in several directions. The first direction defines the Program
object type as leading to one degree. A degree must be arrived at through one or more programs,
making this a total relationship. Program also has a total relationship with Level. Level has partial
relationships with Description. In addition, there is a partial relationship between Program and
Admission. Program also has a many to many relationship with Admission.
In the last direction, Program shares a total relationship with Concentration. Concentration can
belong to one program and a program can include one or many concentrations. Additionally,
concentration shares a total relationship with Curriculum. Curriculum can belong to one concentration
and a concentration can include one or many curriculums. Curriculum also shares a total relationship
with Division. Division, in turn, shares a partial relationship with Course.
In each of our object types with partial relationships, an associate class has been created to
store information between classes. These associate classes will contain composite keys made up of the
primary keys of the two object types in the partial relationship. This allows us to connect information
between classes that are not totally dependent on each other.
Page 5
Deliverable 4
December 2, 2009
Course
Admission
-CourseID
-CourseSubject
-CourseCallNumber
-CourseName
description_level
-AdmID
-AdmTitle
-AdmBody
Level
-LevelID
-LevelName
-LevelOrder
*
*
admission_program
Requirements
1
*
-Contains
*
-Need
*
*
Description
-DescID
-DescTitle
-DescBody
-Classifies
-Require
1..*
Division
-DivID
-DivTitle
-DivSubTitle
-DivBody
-DivOrder
Curriculum
-Divided
1..*
1
Program
-CurrID
-CurrTitle
-CurrDesc
-CurrDocLocation
Concentration
-Involve
-Split
-ConID
-ConName
1..*
1
*
1
-ProgramID
-ProgramTitle
-ProgramDescLess
-ProgramDescMore
Degree
-lead to
1..*
-DegreeID
-DegreeAbbrev
-DegreeName
1
*
Advisor
*
-Advises
Person
Permission
*
*
Group
*
*
-GroupID
-GroupName
-PerID
-PerAction
-Acquire
group_permission
-Includes
-PersonID
-PersonPrefix
-PersonFirstName
-PersonLastName
-PersonOffice
-PersonEmail
-PersonPhone
-PersonWebsite
-PersonDisplay
-eRaider
-rNumber
-UserActive
group_person
*
*
-Holds
person_position
Page 6
Position
-PosID
-PosName
Classification
-has
1..*
-ClassID
-ClassName
1
Deliverable 4
December 2, 2009
Deliverable 2 (Revisions)
In this deliverable, we will take the observations and decisions made in the Conceptual Data
Model stage and translate the conceptual model into a Logical Data Model. We will introduce foreign
keys into the appropriate object types to help us connect the information based on the relationships
defined in the Object Oriented Data Model (OODM). This process will enable us to complete the queries
necessary to answer the questions the ISQS website and the database associated with it must be able to
answer. In addition, it will solidify the relationships we identified in our first deliverable and allow us to
validate all of these associations.
Initial Relational Data Model
A primary key is indicated by underling the attribute(s). A foreign key is shown in italics.
Admissions (AdmID, AdmTitle, AdmBody)
Admissions_Programs (AdmID, ProgramID)
Advisors (PersonID, ProgramID)
Classifications (ClassID, ClassName)
Concentrations (ConID, ProgramID, ConName)
Courses (CourseID, CourseSubject, CourseCallNumber, CourseName)
Curriculums (CurrID, ConID, CurrTitle, CurrDesc, CurrDocLocation)
Degrees (DegreeID, LevelID, DegreeAbbrev, DegreeName)
Descriptions (DescID, DescTitle, DescBody)
Descriptions_Levels (DescID, LevelID)
Divisions (DivID, CurrID, DivTitle, DivSubTitle, DivBody, DivOrder)
Groups (GroupID, GroupName)
Groups_People (GroupID, PersonID)
Groups_Permissions (GroupID, PerID)
Levels (LevelID, LevelName, LevelOrder)
People (PersonID, PersonPrefix, PersonFirstName, PersonLastName, PersonOffice, PersonEmail,
PersonPhone, PersonWebsite, PersonDisplay, eRaider, rNumber, UserActive )
People_Positions (PersonID, PosID)
Permissions (PerID, PerAction)
Positions (PosID, ClassID, PosName)
Programs (ProgramID, DegreeID, ProgramTitle, ProgramDescLess, ProgramDescMore)
Requirements (DivID, CourseID)
Page 1
Deliverable 4
December 2, 2009
Definition of Attributes
To help the reader better understand the meaning of each attribute listed in the Relational Data
Model, we will provide a detailed description for each attribute and how it will be used in the system. In
total, we have 21 relations in the relational model.
Admissions
Admissions are all the various titles of items related to a program admissions page. Below is a
description of all the information collected for each admission entry:
AdmID – this is the primary key which will be automatically created by the database with an
integer value.
AdmTitle – this is the descriptive title for each admissions section. This will have an
alphanumeric value.
AdmBody – this is the text which will be displayed under the title. This will have an
alphanumeric value.
Admissions_Programs
Admissions_Programs is the associative class between the Admissions and Programs object types, which
captures when a row from each object type will be linked together in this many-to-many relationship.
Below is a description of all the information collected for each Admissions_Programs entry:
AdmID – this is the foreign key for the admissions object type with an integer value.
ProgramID – this is the primary key which will be automatically created by the database with an
integer value.
Advisors
Advisors is the associative class between the People and Programs object types, which captures when a
row from each object type will be linked together in this many-to-many relationship. Below is a
description of all the information collected for each Advisors entry:
PersonID– this is the foreign key for the people object type with an integer value.
ProgramID– this is the foreign key for the programs object type with an integer value.
Classifications
Classifications is used to help keep the People object type more organized, by splitting each position up
into several different classifications. Below is a description of all the information collected for each
classification entry:
ClassID – this is the primary key which will be automatically created by the database with an
integer value.
ClassName – this is simply the name of the classification. This will have an alphanumeric value.
Page 2
Deliverable 4
December 2, 2009
Concentrations
Concentrations split programs into individual disciplines. Below is a description of all the information
collected for each concentration entry:
ConID – this is the primary key which will be automatically created by the database with an
integer value.
ProgramID- this is the foreign key for the programs object type with an integer value.
ConName – This is the name of the concentration, such as “Web Application” or
“Telecommunication”. This will have an alphanumeric value.
Courses
Courses are used to form the required curriculum for each program. Since a program is made up of
various courses and since more than one curriculum can require a course, it made sense to create a
separate object type. Below is a description of all the information collected for each course entry:
CourseID – this is the primary key which will be automatically created by the database with an
integer value.
CourseSubject – This is the three or four letter abbreviation for the subject of the course, such
as ISQS or MATH. This will have an alphanumeric value.
CourseCallNumber – This tells us several things about the course, but more specifically the call
number, such as 3344 or 4385. The first digit tells us what level the course is. The second digit
tells us how many hours the course will be. The last two digits are created by the department.
This will have an alphanumeric value.
CourseName – This is the name of the course, such as “Systems Design” or “Systems Analysis”.
This will have an alphanumeric value.
Curriculums
Curriculums are all the various titles of items related to a program’s curriculum page. Below is a
description of all the information collected for each curriculum entry:
CurrID – this is the primary key which will be automatically created by the database with an
integer value.
ConID– this is the foreign key for the concentrations object type with an integer value.
CurrTitle – this is the descriptive title of curriculum section. This will have an alphanumeric
value.
CurrDesc – this is simply the text which will be displayed under the title. This will have an
alphanumeric value.
CurrDocLocation – this is the name of the document for the advising sheet. It is assumed that
the document will be uploaded to the correct path on the server. This will have an alphanumeric
value.
Page 3
Deliverable 4
December 2, 2009
Degrees
Degrees are used to help keep Programs more organized. Since a particular program leads to a certain
degree, and since there can be multiple programs per degree, it makes sense to form this object type by
itself. Below is a description of all the information collected for each degree entry:
DegreeID – this is the primary key which will be automatically created by the database with an
integer value.
LevelID - this is the foreign key for the levels object type with an integer value.
DegreeAbbrev – this is the known abbreviation for the given degree. For example, MBA. This
will have an alphanumeric value.
DegreeName – this is the official name of the degree. This will have an alphanumeric value.
Descriptions
Descriptions are all the various titles of items related to a program description page. Below is a
description of all the information collected for each description entry:
DescID – this is the primary key which will be automatically created by the database with an
integer value.
DescTitle – this is the descriptive title for each description section. This will have an
alphanumeric value.
DescBody – this is the text which will be displayed under the title. This will have an
alphanumeric value.
Descriptions_Levels
Descriptions_Levels is the associative class between the Descriptions and Levels object types, which
captures when a row from each object type will be linked together in this many-to-many relationship.
Below is a description of all the information collected for each Descriptions_Levels entry:
DescID – this is the foreign key for the descriptions object type with an integer value.
LevelID – this is the foreign key for the levels object type with an integer value.
Page 4
Deliverable 4
December 2, 2009
Divisions
Divisions are used to better organize the structure of the curriculum page. Below is a description of all
the information collected for each Division entry:
DivID – this is the primary key which will be automatically created by the database with an
integer value.
CurrID - this is the foreign key for the curriculums object type with an integer value.
DivTitle – this is the title of the Division. This will have an alphanumeric value.
DivSubTitle – this is the sub title, which will go directly under the title. This will have an
alphanumeric value.
DivBody – this is the description of that Division. Sometimes there is more information beyond
the title and subtitle that needs to be included. This will have an alphanumeric value.
DivOrder – this is the display order of all the Divisions for a given curriculum. This will have an
integer value.
Groups
Groups are used to better keep Users organized. Below is a description of all the information collected
for each group entry:
GroupID – this is the primary key which will be automatically created by the database with an
integer value.
GroupName – this is the descriptive name of each group. Examples include "Admin" and
"Moderator". This will have an alphanumeric value.
Groups_People
Groups_People is the associative class between the Groups and People object types, which captures
when a row from each object type will be linked together in this many-to-many relationship. Below is a
description of all the information collected for each Groups_People entry:
GroupID – this is the foreign key for the groups object type with an integer value.
PersonID– this is the foreign key for the people object type with an integer value.
Groups_Permissions
Groups_Permission is the associative class between the Groups and Permissions object types, which
captures when a row from each object type will be linked together in this many-to-many relationship.
Below is a description of all the information collected for each Groups_Permissions entry:
GroupID – this is the foreign key for the groups object type with an integer value.
PerID – this is the foreign key for the permissions object type with an integer value.
Page 5
Deliverable 4
December 2, 2009
Levels
Levels are used to keep the Degrees object type more organized. This object type will divide Degrees
into three levels: undergraduate, graduate and doctorate. Below is a description of all the information
collected for each levels entry:
LevelID – this is the primary key which will be automatically created by the database with an
integer value.
LevelName – this is simply the name or title of the level. This will have an alphanumeric value.
LevelOrder – this is the display order of the levels. For example, Undergraduate should be
displayed before Graduate. This will have an integer value.
People
People represent any individual in the system or who will use the system. Below is a description of all
the information collected for each person entry:
PersonID – this is the primary key which will be automatically created by the database with an
integer value.
PersonPrefix – this is the person’s prefix, such as, “Dr” or “Mr” or “Ms”. Please leave off periods
as they are automatically added by the system. This will have an alphanumeric value.
PersonFirstName – this is the person’s first name. This will have an alphanumeric value.
PersonLastName – this is the person’s last name. This will have an alphanumeric value.
PersonOffice – this is the person’s office in the BA if they have one. Please only put the office
number. This will have an alphanumeric value.
PersonEmail – this is the person’s official email. This will have an alphanumeric value.
PersonPhone – this is the person’s phone number they wish to be contacted at. This will have
an alphanumeric value.
PersonWebsite – this is the person’s website they will use to provide information. This will have
an alphanumeric value.
PersonDisplay – this will indicate which individuals should be displayed in the Faculty & Staff
listing. This will a boolean data type.
eRaider – this is the user's eRaider username. This will have an alphanumeric value.
rNumber – this is the user's rNumber which will have an integer value.
UserActive – this will be a boolean data type to determine if the user can login.
People_Positions
People_Positions is the associative class between the People and Positions object types, which captures
when a row from each object type will be linked together in this many-to-many relationship. Below is a
description of all the information collected for each People_Positions entry:
PersonID – this is the foreign key for the people object type with an integer value.
PosID – this is the foreign key for the position object type with an integer value.
Page 6
Deliverable 4
December 2, 2009
Permissions
Permissions are used to decide what actions a user can perform on a group basis. Below is a description
of all the information collected for each permission entry:
PerID – this is the primary key which will be automatically created by the database with an
integer value.
PerAction – this is the name of the action that the user can perform. This will have an
alphanumeric value.
Positions
Positions are used to help keep the People object type more organized. Below is a description of all the
information collected for each position entry:
PosID – this is the primary key which will be automatically created by the database with an
integer value.
ClassID - this is the foreign key for the classifications object type with an integer value.
PosName – this is the name of the position. For example, "Area Coordinator" or "Professor".
This will have an alphanumeric value.
Programs
Programs are the central object type in this database. It simply represents all the various degree
programs a student can be enrolled in at any given time. Below is a description of all the information
collected for each program entry:
ProgramID – this is the primary key which will be automatically created by the database with an
integer value.
DegreeID – this is the foreign key for the degrees object type with an integer value.
ProgramTitle – this is the title of the program. This will have an alphanumeric value.
ProgramDescLess – this will be displayed on the main Programs page on the User side. This will
have an alphanumeric value.
ProgramDescMore – this will be display in the first header area of the description page. This will
have an alphanumeric value.
Requirements
Requirements is the associative class between the Divisions and Courses object types, which captures
when a row from each object type will be linked together in this many-to-many relationship. Below is a
description of all the information collected for each Requirements entry:
DivID – this is the foreign key for the Divisions object type with an integer value.
CourseID – this is the foreign key for the courses object type with an integer value.
Now, we go through the normalization process to make sure that each relation is in 3NF.
Page 7
Deliverable 4
December 2, 2009
Normalization of Relations
A relation is in 1NF if it has no non-atomic attributes. Each attribute holds only one value for each row. A
relation is in 2NF if there is no partial dependency between the primary key and the non-key attributes
of the relation. A relation is in 3NF if there is no transitive dependency between the primary key and the
non-key attributes of the relation.
Admissions (AdmID, AdmTitle, AdmBody)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Admissions relation is also
in 3NF because each non-key attribute is not dependent on any other.
Admissions_Programs (AdmID, ProgramID)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Admissions_Programs
relation is also in 3NF because each non-key attribute is not dependent on any other.
Advisors (PersonID, ProgramID)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Advisors relation is also in
3NF because each non-key attribute is not dependent on any other.
Classifications (ClassID, ClassName)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Classifications relation is
also in 3NF because each non-key attribute is not dependent on any other.
Concentrations (ConID, ProgramID, ConName)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Concentrations relation is
also in 3NF because each non-key attribute is not dependent on any other.
Courses (CourseID, CourseSubject, CourseCallNumber, CourseName)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Courses relation is also in
3NF because each non-key attribute is not dependent on any other.
Page 8
Deliverable 4
December 2, 2009
Curriculums (CurrID, ConID, CurrTitle, CurrDesc, CurrDocLocation)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Curriculums relation is
also in 3NF because each non-key attribute is not dependent on any other.
Degrees (DegreeID, LevelID, DegreeAbbrev, DegreeName)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Degrees relation is also in
3NF because each non-key attribute is not dependent on any other.
Descriptions (DescID, DescTitle, DescBody)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Descriptions relation is
also in 3NF because each non-key attribute is not dependent on any other.
Descriptions_Levels (DescID, LevelID)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Descriptions_Levels
relation is also in 3NF because each non-key attribute is not dependent on any other.
Divisions (DivID, CurrID, DivTitle, DivSubTitle, DivBody, DivOrder)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Divisions relation is also in
3NF because each non-key attribute is not dependent on any other.
Groups (GroupID, GroupName)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Groups relation is also in
3NF because each non-key attribute is not dependent on any other.
Groups_People (GroupID, PersonID)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Groups_People relation is
also in 3NF because each non-key attribute is not dependent on any other.
Page 9
Deliverable 4
December 2, 2009
Groups_Permissions (GroupID, PerID)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Groups_Permissions
relation is also in 3NF because each non-key attribute is not dependent on any other.
Levels (LevelID, LevelName, LevelOrder)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Levels relation is also in
3NF because each non-key attribute is not dependent on any other.
People (PersonID, PersonPrefix, PersonFirstName, PersonLastName, PersonOffice, PersonEmail,
PersonPhone, PersonWebsite, PersonDisplay, eRaider, rNumber, UserActive )
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The People relation is also in
3NF because each non-key attribute is not dependent on any other.
People_Positions (PersonID, PosID)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The People_Positions relation
is also in 3NF because each non-key attribute is not dependent on any other.
Permissions (PerID, PerAction)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Permissions relation is also
in 3NF because each non-key attribute is not dependent on any other.
Positions (PosID, ClassID, PosName)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Positions relation is also in
3NF because each non-key attribute is not dependent on any other.
Programs (ProgramID, DegreeID, ProgramTitle, ProgramDescLess, ProgramDescMore)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Programs relation is also
in 3NF because each non-key attribute is not dependent on any other.
Page 10
Deliverable 4
December 2, 2009
Requirements (DivID, CourseID)
The above relation is in 1NF because every attribute of the relation is atomic in nature. Each attribute
contains only one value for each row. The above relation is also in 2NF because there is no question of
partial dependency between the primary key and the non-key attributes. The Requirements relation is
also in 3NF because each non-key attribute is not dependent on any other.
The final list of normalized relations is given below.
Final Relational Data Model
Please note that a primary key is indicated by underling the attribute(s). A foreign key is shown in italics.
Below is the final relational data model:
Admissions (AdmID, AdmTitle, AdmBody)
Admissions_Programs (AdmID, ProgramID)
Advisors (PersonID, ProgramID)
Classifications (ClassID, ClassName)
Concentrations (ConID, ProgramID, ConName)
Courses (CourseID, CourseSubject, CourseCallNumber, CourseName)
Curriculums (CurrID, ConID, CurrTitle, CurrDesc, CurrDocLocation)
Degrees (DegreeID, LevelID, DegreeAbbrev, DegreeName)
Descriptions (DescID, DescTitle, DescBody)
Descriptions_Levels (DescID, LevelID)
Divisions (DivID, CurrID, DivTitle, DivSubTitle, DivBody, DivOrder)
Groups (GroupID, GroupName)
Groups_People (GroupID, PersonID)
Groups_Permissions (GroupID, PerID)
Levels (LevelID, LevelName, LevelOrder)
People (PersonID, PersonPrefix, PersonFirstName, PersonLastName, PersonOffice, PersonEmail,
PersonPhone, PersonWebsite, PersonDisplay, eRaider, rNumber, UserActive )
People_Positions (PersonID, PosID)
Permissions (PerID, PerAction)
Positions (PosID, ClassID, PosName)
Programs (ProgramID, DegreeID, ProgramTitle, ProgramDescLess, ProgramDescMore)
Requirements (DivID, CourseID)
Page 11
Deliverable 4
December 2, 2009
Validation of Relational Data Model
Here, we cross-check the user queries against the relational data model to make sure that we have
appropriate relations and attributes included in the model in order to support the user queries and
other requirements. We will cross-check the model for each query.
Query #1: Who are the faculty members for the ISQS Department?
Given: Preferably, a ClassID will be passed where the ClassName = "Faculty"
Relations:
Positions (PosID, ClassID)
People_Positions (PersonID, PosID)
People (PersonID, PersonPrefix, PersonFirstName, PersonLastName)
Query #2: What programs does a faculty member advise?
Given: Preferably, a PersonID will be passed to the page requesting this information.
Relations:
Advisors (PersonID, ProgramID)
Program (ProgramID, ProgramTitle)
Query #3: What are the required courses to complete a given program?
Given: Preferably, a ProgramID and ConID will be passed to the page requesting this
information.
Relations:
Concentration (ConID, ProgramID)
Curriculums (CurrID, ConID)
Divisions (DivID, CurrID)
Requirements (DivID, CourseID)
Courses (CourseID, CourseSubject, CourseCallNumber, CourseName)
Query #4: What programs are offered for a particular degree (BBA, MBA, Ph. D)?
Given: Preferably, a DegreeID will be passed to the page requesting this information.
Relations:
Programs (ProgramID, DegreeID)
Page 12
Deliverable 4
December 2, 2009
Query #5: What are the admission requirements for a given program?
Given: Preferably, a ProgramID will be passed to the page requesting this information.
Relations:
Admissions_Programs (AdmID, ProgramID)
Admissions (AdmID, AdmTitle, AdmBody)
Query #6: What is the description of a given program?
Given: Preferably, a ProgramID will be passed to the page requesting this information.
Relations:
Programs (ProgramID, DegreeID)
Degrees (DegreeID, LevelID)
Descriptions_Levels (DescID, LevelID)
Descriptions (DescID, DescTitle, DescBody)
Query #7: What people have permission to modify the content?
Given: Preferably, a specific action will be passed to the page requesting the modification.
Relations:
Permissions (PerID, PerAction)
Groups_Permissions (GroupID, PerID)
Groups_People (GroupID, PersonID)
People (PersonID, PersonPrefix, PersonFirstName, PersonLastName)
Query #8: What are the permissions for a given person?
Given: Preferably, a PersonID will be passed to the page requesting this information.
Relations:
Groups_People (GroupID, PersonID)
Groups_Permissions (GroupID, PerID)
Permissions (PerID, PerAction)
Page 13
Deliverable 4
December 2, 2009
Query #9: What is the classification of a given person.
Given: Preferably, a PersonID will be passed to the page requesting this information.
Relations:
People_Person (PersonID, PosID)
Classification (ClassID, ClassName)
Query #10: What courses are needed for a specific concentration?
Given: Preferably, a ConID will be passed to the page requesting this information.
Relations:
Curriculum (CurrID, ConID)
Divisions (DivID, CurrID)
Requirements (DivID, CourseID)
Courses (CourseID, CourseSubject, CourseNumber, CourseName)
Query #11: What are the admissions requirements for a given level?
Given: Preferably, a LevelID will be passed to the page requesting this information.
Relations:
Degree (DegreeID, LevelID)
Program (ProgramID, DegreeID)
Admissions_Programs (AdmID, ProgramID)
Admissions (AdmID, AdmTitle, AdmBody)
Query #12: What courses are available for a degree?
Given: Preferably, a DegreeID will be passed to the page requesting this information.
Relations:
Degrees (DegreeID)
Programs (ProgramID, DegreeID)
Concentrations (ConID, ProgramID)
Curriculums (CurrID, ConID)
Divisions (DivID, CurrID)
Requirements (DivID, CourseID)
Courses (CourseID, CourseSubject, CourseCallNumber, CourseName)
Page 14
Deliverable 4
December 2, 2009
Query #13: Which positions advise undergraduate degrees?
Given: Preferably, a LevelID will be passed to the page requesting this information.
Relations:
Degrees (DegreeID, LevelID)
Programs (ProgramID, DegreeID)
Advisors (PersonID, ProgramID)
People_Positions (PersonID, PosID)
Positions (PosID, PosName)
Query #14: What is the description of a specific concentration?
Given: Preferably, a ConID will be passed to the page requesting this information.
Relations:
Concentrations (ConID, ProgramID)
Programs (ProgramID), DegreeID)
Degrees (DegreeID, LevelID)
Descriptions_Levels (LevelID, DescID)
Descriptions (DescID, DescTitle, DescBody)
Query #15: What Divisions does a course fall under?
Given: Preferably, a CourseID will be passed to the page requesting this information.
Relations:
Courses (CourseID)
Requirements (DivID, CourseID)
Divisions (DivID, DivTitle)
Query #16: What level is a program associated with?
Given: Preferably, a ProgramID will be passed to the page requesting this information.
Relations:
Programs (ProgramID, DegreeID)
Degrees (DegreeID, LevelID)
Levels (LevelID, LevelName)
Page 15
Deliverable 4
December 2, 2009
Query #17: What group has a specific permission?
Given: Preferably, a PerID will be passed to the page requesting this information.
Relations:
Permissions (PerID)
Groups_Permissions (GroupID, PerID)
Groups (GroupID, GroupName)
After listing the relations required to answer each of the eight questions that were presented in
the introduction, we see that the relational data model has the appropriate relations and attributes to
satisfy the business requirements given.
Page 16
Deliverable 4
December 2, 2009
Non-Functional Requirements
Volume
We need to estimate the number of tuples for each relation to properly calculate the total data
volume. Based upon the business requirements specified, below is the estimated number of rows for
each relation:
Relation
Estimated Number of Rows
Comments
Admissions
40
Admissions_Programs
80
Advisors
20
Assume there will be at least 10 admissions
for each level.
Assume that there will be at least 2 relations
for each level.
Each Program can have up to 3 people
advising it.
Classifications
Concentrations
4
16
Courses
Curriculums
100
16
Degrees
Descriptions
4
40
Descriptions_Levels
80
Divisions
80
Groups
Groups_People
Groups_Permissions
4
200
40
Levels
People
People_Positions
Permissions
Positions
Programs
Requirements
4
100
300
10
20
10
150
Assume there will be at least 2
concentrations per program.
Assume there will be a curriculum for each
concentration.
Assume there will be at least 10 descriptions
for each level.
Assume that there will be at least 2 relations
for each level.
Assume there will be at least 10 Divisions
per curriculum.
Assume that each Person can be in 2 Groups.
Assume that each Group can have up to 4
permissions.
Each Person can have up to 3 positions.
Assume that there will be at least 3 relations
for each course.
Page 17
Deliverable 4
December 2, 2009
Security Needs
In its current state, there are no security needs that need to be taken into account.
Response Time Expectations
The website should be able to quickly access information:
On People using PersonFirstName, PersonLastName, eRaider and rNumber
On Programs using ProgramName
Therefore, we need to define indexes for PersonFirstName, PersonLastName, ProgramName, eRaider
and rNumber. In addition to these indexes, we will also define indexes on every primary and foreign key.
Integrity constraints:
The website should abide by the following constraints:
There should be no duplicate eRaider or rNumber values.
There should be no duplicate PersonEmail.
People must be part of a group to receive permissions.
Each person who holds a position must also have a classification as staff, faculty or PH.D
student.
Each Program must have an advisor.
Each Program must lead to a degree.
Each degree should be associated with an appropriate level.
Each level has a description.
A program has certain Admission requirements that should be displayed on the database.
A program can have a concentration.
Each Program, and consequently each concentration, has a set curriculum.
Each curriculum must have at least one Division.
Each Division may have many courses.
Page 18
Deliverable 4
December 2, 2009
Deliverable 3 (Revisions)
In this deliverable, we will go into more detail about the information from our logical database
design using language that can be interpreted by SQL Server 2008, which is the service we will be using
create our database. We use the SQL Server 2008 platform to specify the physical database design.
Using the logical database design, we need to define the attributes, indexes, and security requirements
for each attribute using the SQL Server 2008 terminology.
Physical Database Design
Admissions
Attribute (Field)
AdmID
AdmTitle
AdmBody
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Varchar(45)
Text (150)
No
No
No
Yes (Primary Key)
No
No
N/A
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
No
No
Yes (Foreign Key)
Yes (Foreign Key)
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
No
No
Yes (Foreign Key)
Yes (Foreign Key)
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Varchar(45)
No
No
Yes (Primary Key)
No
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
Varchar(45)
No
No
No
Yes (Primary Key)
Yes (Foreign Key)
No
N/A
N/A
N/A
Admissions_Programs
Attribute (Field)
AdmID
ProgramID
Advisors
Attribute (Field)
PersonID
ProgramID
Classifications
Attribute (Field)
ClassID
ClassName
Concentrations
Attribute (Field)
ConID
ProgramID
ConName
Page 19
Deliverable 4
December 2, 2009
Courses
Attribute (Field)
CourseID
CourseSubject
CourseCallNumber
CourseName
Data Type
Integer (4 bytes)
Varchar(6)
Varchar(4)
Varchar(45)
Null (Yes or No)
Index
Security
No
No
No
No
Yes (Primary Key)
No
No
No
N/A
N/A
N/A
N/A
Curriculums
Attribute (Field)
CurrID
ConID
CurrTitle
CurrDesc
CurrDocLocation
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
Varchar(45)
Text (150)
Varchar(45)
No
No
No
No
Yes
Yes (Primary Key)
Yes (Foreign Key)
No
No
No
N/A
N/A
N/A
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
Varchar(6)
Varchar(45)
No
No
No
No
Yes (Primary Key)
Yes (Foreign Key)
No
No
N/A
N/A
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Varchar(45)
Text (150)
No
No
No
Yes (Primary Key)
No
No
N/A
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
No
No
Yes (Foreign Key)
Yes (Foreign Key)
N/A
N/A
Degrees
Attribute (Field)
DegreeID
LevelID
DegreeAbbrev
DegreeName
Descriptions
Attribute (Field)
DescID
DescTitle
DescBody
Descriptions_Levels
Attribute (Field)
DescID
LevelID
Page 20
Deliverable 4
December 2, 2009
Divisions
Attribute (Field)
DivID
CurrID
DivTitle
DivSubTitle
DivBody
DivOrder
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
Varchar(45)
Varchar(100)
Text (150)
Integer (4 bytes)
No
No
No
Yes
No
No
Yes (Primary Key)
Yes (Foreign Key)
No
No
No
No
N/A
N/A
N/A
N/A
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Varchar(45)
No
No
Yes (Primary Key)
No
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
No
No
Yes (Foreign Key)
Yes (Foreign Key)
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
No
No
Yes (Foreign Key)
Yes (Foreign Key)
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Varchar(45)
Integer (4 bytes)
No
No
No
Yes (Primary Key)
No
No
N/A
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Varchar(45)
No
No
Yes (Primary Key)
No
N/A
N/A
Groups
Attribute (Field)
GroupID
GroupName
Groups_Permissions
Attribute (Field)
GroupID
PerID
Groups_People
Attribute (Field)
GroupID
PersonID
Levels
Attribute (Field)
LevelID
LevelName
LevelOrder
Permissions
Attribute (Field)
PerID
PerAction
Page 21
Deliverable 4
December 2, 2009
People
Attribute (Field)
Data Type
Null (Yes or No)
Index
Security
PersonID
PersonPrefix
PersonFirstName
PersonLastName
PersonOffice
PersonEmail
PersonPhone
PersonWebsite
PersonDisplay
eRaider
rNumber
UserActive
Integer (4 bytes)
Varchar(4)
Varchar(45)
Varchar(45)
Varchar(4)
Varchar(45)
Varchar(10)
Varchar(45)
BIT (1 byte)
Varchar(15)
Integer (4 bytes)
BIT (1 byte)
No
No
No
No
Yes
No
No
Yes
No
Yes
Yes
Yes
Yes (Primary Key)
No
Yes
Yes
No
No
No
No
No
Yes
Yes
No
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
No
No
Yes (Foreign Key)
Yes (Foreign Key)
N/A
N/A
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
Varchar(45)
No
No
No
Yes (Primary Key)
Yes (Foreign Key)
No
N/A
N/A
N/A
Null (Yes or No)
Index
Security
No
No
No
No
No
Yes (Primary Key)
Yes (Foreign Key)
Yes
No
No
N/A
N/A
N/A
N/A
N/A
People_Positions
Attribute (Field)
PersonID
PosID
Positions
Attribute (Field)
PosID
ClassID
PosName
Programs
Attribute (Field)
ProgramID
DegreeID
ProgramTitle
ProgramDescLess
ProgramDescMore
Data Type
Integer (4 bytes)
Integer (4 bytes)
Varchar(45)
Text (150)
Text (150)
Requirements
Attribute (Field)
DivID
CourseID
Data Type
Null (Yes or No)
Index
Security
Integer (4 bytes)
Integer (4 bytes)
No
No
Yes (Foreign Key)
Yes (Foreign Key)
N/A
N/A
Page 22
Deliverable 4
December 2, 2009
Now, we need to calculate the total database size based on the volume requirements and data type
requirements specified above.
Database Size (Disk Space Requirement)
It is important to estimate the total size of the database based upon the table sizes and volumes. We
will follow the following guidelines to compute the database size in bytes:
1. Compute the basic size of each table by adding the attribute-sizes and multiplying it by the
table-volume.
2. Add 40% as overhead for each index (including PK and FKs)
3. Compute the database size by adding the sizes of all tables.
4. Multiply the number in step 3 by 1.5 to account for unexpected future growth
It is estimated that the size of the database will be about 0.26 megabytes. Please see the table below
used to calculate the size.
Page 23
Deliverable 4
December 2, 2009
Relation
Admissions
Admissions_Programs
Advisors
Classifications
Concentrations
Courses
Curriculums
Degrees
Descriptions
Descriptions_Levels
Divisions
Groups
Groups_People
Groups_Permissions
Levels
People
People_Positions
Permissions
Positions
Programs
Requirements
Estimated Number of Rows
Size One Row
40
80
400
4
16
100
16
4
40
80
80
4
200
40
4
100
300
10
20
10
150
199
8
8
49
53
59
248
59
199
8
307
49
8
8
53
223
8
49
53
353
8
Page 24
Base Size of Table # Index
7,960
640
3,200
196
848
5,900
3,968
236
7,960
640
24,560
196
1,600
320
212
22,300
2,400
490
1,060
3,530
1,200
1
2
2
1
2
1
2
2
1
2
2
1
2
2
1
5
2
1
2
2
2
Index Overhead
3,184.00
512.00
2,560.00
78.40
678.40
2,360.00
3,174.40
188.80
3,184.00
512.00
19,648.00
78.40
1,280.00
256.00
84.80
44,600.00
1,920.00
196.00
848.00
2,824.00
960.00
Base Size
50% Growth
Size (Bytes)
Size (MB)
Total
11,144.00
1,152.00
5,760.00
274.40
1,526.40
8,260.00
7,142.40
424.80
11,144.00
1,152.00
44,208.00
274.40
2,880.00
576.00
296.80
66,900.00
4,320.00
686.00
1,908.00
6,354.00
2,160.00
178,543.20
89,271.60
267,814.80
0.26
Deliverable 4
December 2, 2009
Deliverable 4
Database Implementation
Here we will show SQL codes to implement the physical database design specified for the SQL Server
platform. We will use SQL Server 2005 to implement the database. We will call our database as
ISQS_Website.
SQL Code to Generate Tables
Use ISQS_Website
Go
--- Drop Tables
-IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Admissions_Programs') DROP TABLE Admissions_Programs;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Advisors') DROP TABLE Advisors;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Requirements') DROP TABLE Requirements;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Descriptions_Levels') DROP TABLE Descriptions_Levels;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Groups_Permissions') DROP TABLE Groups_Permissions;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Groups_People') DROP TABLE Groups_People;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='People_Positions') DROP TABLE People_Positions;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Admissions') DROP TABLE Admissions;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Courses') DROP TABLE Courses;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Descriptions') DROP TABLE Descriptions;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Positions') DROP TABLE Positions;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Classifications') DROP TABLE Classifications;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Groups') DROP TABLE Groups;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='People') DROP TABLE People;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Permissions') DROP TABLE [Permissions];
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Divisions') DROP TABLE Divisions;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE
TABLE_NAME='Curriculums') DROP TABLE Curriculums;
Page 25
Deliverable 4
December 2, 2009
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
TABLE_NAME='Concentrations') DROP TABLE Concentrations;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
TABLE_NAME='Programs') DROP TABLE Programs;
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
TABLE_NAME='Degrees') DROP TABLE [Degrees];
IF EXISTS (SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES
TABLE_NAME='Levels') DROP TABLE Levels;
--- Create Database Schema
--- SQL Code to create the Admissions Table
CREATE TABLE Admissions
(
AdmID int identity(1,1),
AdmTitle varchar(45) NOT NULL,
AdmBody text NOT NULL,
PRIMARY KEY(AdmID)
)
-- SQL Code to create the Classifications Table
CREATE TABLE Classifications
(
ClassID int identity(1,1),
ClassName varchar(45) NOT NULL,
PRIMARY KEY(ClassID)
)
-- SQL Code to create the Courses Table
CREATE TABLE Courses
(
CourseID int identity(1,1),
CourseSubject varchar(6) NOT NULL,
CourseCallNumber varchar(4) NOT NULL,
CourseName varchar(45) NOT NULL,
PRIMARY KEY(CourseID)
)
-- SQL Code to create the Descriptions Table
CREATE TABLE Descriptions
(
DescID int identity(1,1),
DescTitle varchar(45) NOT NULL,
DescBody text NOT NULL,
PRIMARY KEY(DescID)
)
-- SQL Code to create the Groups Table
CREATE TABLE Groups
(
GroupID int identity(1,1),
GroupName varchar(45) NOT NULL,
PRIMARY KEY(GroupID)
)
Page 26
WHERE
WHERE
WHERE
WHERE
Deliverable 4
December 2, 2009
-- SQL Code to create the People Table
CREATE TABLE People
(
PersonID int identity(1,1),
PersonPrefix varchar(4) NOT NULL,
PersonFirstName varchar(45) NOT NULL,
PersonLastName varchar(45) NOT NULL,
PersonOffice varchar(4) NULL,
PersonEmail varchar(45) NOT NULL,
PersonPhone varchar(10) NOT NULL,
PersonWebsite varchar(45) NOT NULL,
PersonDisplay bit NOT NULL,
eRaider varchar(15) NULL,
rNumber int,
UserActive bit NOT NULL,
PRIMARY KEY(PersonID)
)
-- SQL Code to create the Permissions Table
CREATE TABLE [Permissions]
(
PerID int identity(1,1),
PerAction varchar(45) NOT NULL,
PRIMARY KEY(PerID)
)
-- SQL Code to create the Levels Table
CREATE TABLE Levels
(
LevelID int identity(1,1),
LevelName varchar(45) NOT NULL,
LevelOrder int NOT NULL,
PRIMARY KEY(LevelID)
)
-- SQL Code to create the Degrees Table
CREATE TABLE [Degrees]
(
DegreeID int identity(1,1),
LevelID int NOT NULL,
DegreeAbbrev varchar(6) NOT NULL,
DegreeName varchar(45) NOT NULL,
PRIMARY KEY(DegreeID),
FOREIGN KEY(LevelID) references Levels(LevelID)
)
-- SQL Code to create the Programs Table
CREATE TABLE Programs
(
ProgramID int identity(1,1),
DegreeID int NOT NULL,
ProgramTitle varchar(45) NOT NULL,
ProgramDescLess text NOT NULL,
ProgramDescMore text NOT NULL,
PRIMARY KEY(ProgramID),
Page 27
Deliverable 4
December 2, 2009
FOREIGN KEY(DegreeID) references [Degrees](DegreeID)
)
-- SQL Code to create the Concentrations Table
CREATE TABLE Concentrations
(
ConID int identity(1,1),
ProgramID int NOT NULL,
ConName varchar(45) NOT NULL,
PRIMARY KEY(ConID),
FOREIGN KEY(ProgramID) references Programs(ProgramID)
)
-- SQL Code to create the Curriculums Table
CREATE TABLE Curriculums
(
CurrID int identity(1,1),
ConID int NOT NULL,
CurrTitle varchar(45) NOT NULL,
CurrDesc text NOT NULL,
CurrDocLocation varchar(45) NULL,
PRIMARY KEY(CurrID),
FOREIGN KEY(ConID) references Concentrations(ConID)
)
-- SQL Code to create the Divisions Table
CREATE TABLE Divisions
(
DivID int identity(1,1),
CurrID int NOT NULL,
DivTitle varchar(45) NOT NULL,
DivSubTitle varchar(100) NULL,
DivBody text NOT NULL,
DivOrder int NOT NULL,
PRIMARY KEY(DivID),
FOREIGN KEY(CurrID) references Curriculums(CurrID)
)
-- SQL Code to create the Positions Table
CREATE TABLE Positions
(
PosID int identity(1,1),
ClassID int NOT NULL,
PosName varchar(45) NOT NULL,
PRIMARY KEY(PosID),
FOREIGN KEY(ClassID) references Classifications(ClassID)
)
-- SQL Code to create the Admissions_Programs Table
CREATE TABLE Admissions_Programs
(
AdmID int NOT NULL,
ProgramID int NOT NULL,
PRIMARY KEY (AdmID,ProgramID),
FOREIGN KEY(AdmID) references Admissions(AdmID),
FOREIGN KEY(ProgramID) references Programs(ProgramID)
Page 28
Deliverable 4
December 2, 2009
)
-- SQL Code to create the Advisors Table
CREATE TABLE Advisors
(
PersonID int NOT NULL,
ProgramID int NOT NULL,
PRIMARY KEY (PersonID,ProgramID),
FOREIGN KEY(PersonID) references People(PersonID),
FOREIGN KEY(ProgramID) references Programs(ProgramID)
)
-- SQL Code to create the Requirements Table
CREATE TABLE Requirements
(
DivID int NOT NULL,
CourseID int NOT NULL,
PRIMARY KEY (DivID,CourseID),
FOREIGN KEY(DivID) references Divisions(DivID),
FOREIGN KEY(CourseID) references Courses(CourseID)
)
-- SQL Code to create the Descriptions_Levels Table
CREATE TABLE Descriptions_Levels
(
DescID int NOT NULL,
LevelID int NOT NULL,
PRIMARY KEY (DescID,LevelID),
FOREIGN KEY(DescID) references Descriptions(DescID),
FOREIGN KEY(LevelID) references Levels(LevelID)
)
-- SQL Code to create the Groups_Permissions Table
CREATE TABLE Groups_Permissions
(
GroupID int NOT NULL,
PerID int NOT NULL,
PRIMARY KEY (GroupID,PerID),
FOREIGN KEY(GroupID) references Groups(GroupID),
FOREIGN KEY(PerID) references [Permissions](PerID)
)
-- SQL Code to create the Groups_People Table
CREATE TABLE Groups_People
(
GroupID int NOT NULL,
PersonID int NOT NULL,
PRIMARY KEY (GroupID,PersonID),
FOREIGN KEY(GroupID) references Groups(GroupID),
FOREIGN KEY(PersonID) references People(PersonID)
)
-- SQL Code to create the People_Positions Table
CREATE TABLE People_Positions
(
PersonID int NOT NULL,
Page 29
Deliverable 4
December 2, 2009
PosID int NOT NULL,
PRIMARY KEY (PersonID,PosID),
FOREIGN KEY(PersonID) references People(PersonID),
FOREIGN KEY(PosID) references Positions(PosID)
)
--- Generate Additional Indexes
-CREATE INDEX PersonFirstName ON People(PersonFirstName)
CREATE INDEX PersonLastName ON People(PersonLastName)
CREATE INDEX eRaider ON People(eRaider)
CREATE INDEX rNumber ON People(rNumber)
CREATE INDEX ProgramTitle ON Programs(ProgramTitle)
Data Population of the ISQS_Website Database
The ISQS_Website database is populated in the following order:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
Admissions
Classifications
Courses
Descriptions
Groups
People
Permissions
Levels
Degrees
Programs
Concentrations
Curriculums
Divisions
Positions
Admissions_Programs
Advisors
Requirements
Descriptions_Levels
Groups_Permissions
Groups_People
People_Positions
Page 30
Deliverable 4
December 2, 2009
SQL Code to Populate Tables
Use ISQS_Website
Go
--- Populate Tables
--- SQL Code to populate the Admissions Table
INSERT INTO Admissions (AdmTitle, AdmBody) VALUES
('Application', '\r\n
Requests for applications should be
directed to the Office of New Student Relations, Texas Tech University,
Lubbock, Texas 79409, Telephone (806) 742-1480. Questions concerning
admission should be directed to the Admissions Office, Texas Tech University,
Lubbock, Texas 79409, Telephone (806) 742-3661.The Admissions Office
recommends that applications be on file by March 1 for summer or fall
admissions; November 1 for spring admissions.\r\n
'),
('First-Time Freshman Admission', '\r\n
To enroll for the
first time at Texas Tech, applicants must:\r\n
<br />\r\n
<ul> \r\n
<li> \r\n
Be a high
school graduate, with acceptable credits for high school subjects.\r\n
</li> \r\n
<li> \r\n
File an
application to Texas Tech University.\r\n
</li> \r\n
<li> \r\n
Have acceptable scores on either Scholastic
Aptitude Test (SAT) or the American College Test (ACT).\r\n
</li> \r\n
</ul> \r\n
<br />\r\n
High school graduates who have been out of school for more than five years
are not required to provide test scores.\r\n
'),
('Application', '\r\nThe ISQS Department accepts applications for admission
to the fall, spring and summer terms. Applications are reviewed on a
continual basis by the faculty in the ISQS Department. \r\n<br
/>\r\nAdmission to the Graduate Program in MIS, Business Statistics, and
Production & Operations Management is dependent upon the applicant''s
undergraduate record, scores on the Graduate Management Admissions Test, and
recommendation of the faculty in the ISQS Department. A substantial body of
undergraduate work in the major subject and considerable breadth of
background are essential for graduate study. Therefore, students whose
undergraduate programs are considered deficient in breath or depth may be
required to complete additional preparatory work without degree credit. Such
undergraduate "leveling" courses must be completed with a grade of C or
better.'),
('Contact', '\r\n
<b>Graduate Services Center</b> <br />
\r\n
Rawls College of Business Administration <br /> \r\n
Texas Tech University<br /> \r\n
Room 252<br /> \r\n
Box 42101<br /> \r\n
Lubbock, TX 79409-2101<br /> \r\n
(806) 742 - 3184<br /> \r\n
(800) 882 - 6220 (Toll Free)
<br /> \r\n
Web: <a
href="http://grad.ba.ttu.edu">http://grad.ba.ttu.edu</a>, <br /> \r\n
E-mail: <a href="mailto:bagrad@ba.ttu.edu">bagrad@ba.ttu.edu</a> \r\n
'),
('Application', '\r\n
Admission to the program is very
selective in nature. It requires a distinguished record in previous academic
work, high scores on the GMAT, and potential for research.\r\n <br />\r\nThe
ISQS Department accepts applications for admission to the fall, spring and
summer terms. Applications are reviewed on a continual basis by the faculty
in the ISQS Department.');
Page 31
Deliverable 4
December 2, 2009
-- SQL Code to populate the Classifications Table
INSERT INTO Classifications (ClassName) VALUES
('Faculty'),
('Staff'),
('Student');
-- SQL Code to populate the Courses Table
INSERT INTO Courses (CourseSubject, CourseCallNumber, CourseName) VALUES
('BLAW', '3391', 'Business Law I'),
('FIN', '3320', 'Financial Management'),
('ISQS', '3344', 'Introduction to Production and Operations Man'),
('MKT', '3350', 'Introduction to Marketing'),
('MGT', '3370', 'Organization and Management'),
('MGT', '3373', 'Managerial Communication'),
('ISQS', '3346', 'Internet Programming'),
('ISQS', '3348', 'Database Management Systems'),
('ISQS', '3349', 'Introduction to Data Communication Systems'),
('ISQS', '3351', 'Telecommunications Security using Linux'),
('ISQS', '3360', 'Telecommunications Securities Theory'),
('ISQS', '4348', 'Systems Analysis'),
('ISQS', '4349', 'Information Systems Design'),
('ISQS', '4350', 'Information Systems Project Management'),
('ISQS', '4385', 'Strategic IT and Telecommunications Managemen'),
('ISQS', '4382', 'Internship in Information Systems and Quantit'),
('ISQS', '3345', 'Object Oriented Systems'),
('ISQS', '3358', 'Business Intelligence'),
('ISQS', '4361', 'Web Application Design');
-- SQL Code to populate the Descriptions Table
INSERT INTO Descriptions (DescTitle, DescBody) VALUES
('Educational Objectives', 'The objectives of this program are to prepare
students to take the challenge of adopting and utilizing state-of-the-art MIS
technology and to ensure 100% job placement. The program’s educational
objectives are realized through a dynamic curriculum and a variety of
instructional methods, including: “hands-on” computer experience; class
lecture and discussion; textbook and article study; class assignments,
laboratory projects, and applied (team) projects in the business community;
case studies; demonstrations; field trips; and presentations by practitioners
from the MIS community.'),
('Career Opportunities', 'The MIS field is widely recognized for its current
and future career potential. Specific career opportunities depend on the
student’s interests, coursework, and experience. Some students go into the
MIS function immediately and rise through the ranks. Others become the MIS
specialists in a given functional area such as production or finance and
become the resident experts providing the liaison between MIS and their own
functional organizations. Some go into direct end-user support and often work
in an information center. The baccalaureate and graduate programs in business
administration are fully accredited by the American Assembly of Collegiate
Schools of Business, the national accrediting organization.'),
('Scholarship', 'Several scholarships are available to qualified students.'),
('Facility', 'The ISQS Department is located on the sixth floor in the Rawls
College of Business Administration (RCOBA) building. RCOBA maintains its own
computing facility. The University Library has in excess of 1.1 million
volumes, extensive periodicals, and document resources. Academic Computing
Services (ACS) operates the Advanced Technology Learning Center (ATLC),
located in the west basement of the library. The leading-edge computing
Page 32
Deliverable 4
December 2, 2009
technology includes numerous microcomputer laboratories, the ACS VMS cluster,
a teleconference room, Help Desk, support equipment, and short-term training
courses.'),
('Financial Aid', 'Masters students may apply for scholarships and
assistantships. Students who receive a scholarship or an assistantship
qualify for in-state tuition.'),
('Transfer Work', 'There is no automatic transfer of credit toward a masters
degree, but, in general, work completed in residence at another accredited
graduate school may, on the recommendation of the department concerned, be
accepted for as much as 6 semester hours toward a masters degree. Exceptions
to this rule are granted in the case of the Masters of Engineering degree and
in certain other instances upon agreement between the college of the
department concerned and the Graduate School. Work completed at another
graduate school with a grade less than B will not be accepted. Transfer
credit will not alter a student''s grade-point average at Texas Tech.'),
('Grade Requirement', 'For the masters degree, the minimum requirement for
graduation is an average of 3.0 in the major subject and an overall average
of 3.0 in all courses, exclusive of the thesis, comprising the official
program for the degree. Individual departments or colleges may have higher
standards.'),
('Time Limit', 'With few exceptions work credited toward a masters degree
must be completed within six years. Students whose graduate study here is
interrupted by military service will be granted an extension of time for the
period of their military duty, not exceeding five years.'),
('Financial Aid', 'Most Ph.D. students are offered research or teaching
assistantships (TA). Most of these positions involve 20 hours of service per
week teaching undergraduate courses in the student''s area of doctoral study.
The stipend for a TA is currently about $16,391 for ten and one-half months
of service. The amount of the stipend raises annually. An out-of-state
resident who receives an assistantship qualifies for in-state tuition.\r\n');
-- SQL Code to populate the Groups Table
INSERT INTO Groups (GroupName) VALUES
('Administrators'),
('Moderators');
-- SQL Code to populate the People Table
INSERT INTO People (PersonPrefix, PersonFirstName, PersonLastName,
PersonOffice, PersonEmail, PersonPhone, PersonWebsite, PersonDisplay,
UserActive) VALUES
('Dr', 'Jeff', 'Baker', '615', 'jeff.baker@ttu.edu', '8067423547',
'http://ta.ba.ttu.edu/jbaker', 1, 0),
('Dr', 'Ronald', 'Bremer', '611', 'odron@coba2.ttu.edu', '8067422170',
'http://www.ba.ttu.edu/isqs/bremer/ronbvita.ht', 1, 0),
('Ms', 'Patricia', 'Brown', '606', 'patricia.brown@ttu.edu', '8067421539',
'http://pbrown.ba.ttu.edu/', 1, 0),
('Dr', 'James', 'Burns', '714', 'jburns@ba.ttu.edu', '8067421547',
'http://burns.ba.ttu.edu/', 1, 0),
('Dr', 'Qing', 'Cao', '710', 'caoq@umkc.edu', '8067423919',
'http://qcao.ba.ttu.edu/', 1, 0),
('Dr', 'W', 'Conover', '603', 'conover@ba.ttu.edu', '8067421546',
'http://is.ba.ttu.edu/conover/Conover1.htm', 1, 0),
('Dr', 'Frank', 'Delgadillo', '504', 'f.delgadillo@ttu.edu', '8067422460',
'http://fdelgadillo.ba.ttu.edu/', 1, 0),
('Dr', 'John', 'Durrett', '607', 'john.durrett@ttu.edu', '8067422994',
'http://jdurrett.ba.ttu.edu/', 1, 0),
Page 33
Deliverable 4
December 2, 2009
('Dr', 'Bradley', 'Ewing', '615', 'bradley.ewing@ttu.edu', '8067423939',
'http://courses.ttu.edu/bewing/', 1, 0),
('Mr', 'Phil', 'Flamm', '506', 'flammp@ba.ttu.edu', '8067422190',
'http://isqs3344.ba.ttu.edu/', 1, 0),
('Dr', 'Terri', 'Giddens', '610', 'terri.giddens@ttu.edu', '8067421048',
'http://tgiddens.ba.ttu.edu/', 1, 0),
('Mr', 'Naveen', 'Gudigantala', '612', 'naveen.gudigantala@ttu.edu',
'8067421927', 'http://ta.ba.ttu.edu/naveen', 1, 0),
('Dr', 'Jim', 'Hoffman', '614', 'james.hoffman@ttu.edu', '8067424004',
'http://is.ba.ttu.edu/faculty/hoffman.htm', 1, 0),
('Dr', 'Donald', 'Jones', '506', 'djones@ba.ttu.edu', '8067421988',
'http://djones.ba.ttu.edu/', 1, 0),
('Mr', 'Lowell', 'Lay', '608', 'lowell.lay@ttu.edu', '8067421538',
'http://is.ba.ttu.edu/', 1, 0),
('Dr', 'Zhangxi', 'Lin', '708', 'zhangxi.lin@ttu.edu', '8067421926',
'http://zlin.ba.ttu.edu/', 1, 0),
('Dr', 'Jaeki', 'Song', '712', 'jaeki.song@ttu.edu', '8067428036',
'http://jsong.ba.ttu.edu/', 1, 0),
('Dr', 'Eric', 'Walden', '716', 'eric@ericwalden.net', '8067421925',
'http://ericwalden.net/', 1, 0),
('Dr', 'Peter', 'Westfall', '703', 'peter.westfall@ttu.edu', '8067422174',
'http://westfall.ba.ttu.edu/pwvita.htm', 1, 0),
('Dr', 'James', 'Wetherbe', '164', 'jcwetherbe@aol.com', '5052509999',
'http://wetherbe.ba.ttu.edu/', 1, 0),
('Dr', 'Surya', 'Yadav', '706', 'surya.yadav@ttu.edu', '8067422165',
'http://yadav.ba.ttu.edu/', 1, 0),
('Ms', 'Pam', 'Knighten-Jones', '', 'pam.knighten@ttu.edu', '8067423192', '',
1, 0),
('Mr', 'Jeff', 'Morris', '', 'jeff.morris@ttu.edu', '2149081091', '', 0, 0);
-- SQL Code to populate the Permissions Table
INSERT INTO [Permissions] (PerAction) VALUES ('*');
-- SQL Code to populate the Levels Table
INSERT INTO Levels (LevelName, LevelOrder) VALUES
('Undergraduate', 1),
('Graduate', 2),
('Doctorate', 3);
-- SQL Code to populate the Degrees Table
INSERT INTO [Degrees] (LevelID, DegreeAbbrev, DegreeName) VALUES
(1, 'BBA', 'Bachelor of Business Administration'),
(2, 'MSBA', 'Master of Science in Business Administration'),
(2, 'MBA', 'Master of Business Administration'),
(3, 'Ph.D.', 'Doctor of Philosophy');
-- SQL Code to populate the Programs Table
INSERT INTO Programs (DegreeID, ProgramTitle, ProgramDescLess,
ProgramDescMore) VALUES
(1, 'BBA in MIS', 'Texas Tech''s Management Information Systems (MIS)
undergraduate program is designed to educate future information systems
professionals and managers. This program prepares students to take the
challenge of adopting and utilizing state-of-the-art MIS technology in their
professional lives.', 'Texas Tech''s Management Information Systems (MIS)
undergraduate program is designed to educate future information systems
professionals and managers. This program is interdisciplinary in nature with
Page 34
Deliverable 4
December 2, 2009
specialized training in information systems and management. It builds on the
College of Business Administration''s common core which includes course work
in accounting, economics, business law, mathematics, statistics, computer
programming, finance, marketing, production, and management. The common core
is normally completed before taking coursework in the MIS program.'),
(2, 'MS in MIS', 'The purpose of the Master of Science in Management
Information Systems program is to prepare students with the necessary
knowledge in information technology for industry.', ' \r\n
The purpose of the Master of Science in Management Information Systems
program is to prepare students with the necessary knowledge in information
technology for industry. This program focuses on:\r\n
<br
/>\r\n
<ul> \r\n
<li> \r\n
Systems Development \r\n
</li> \r\n
<li> \r\n
Enterprise information system integration
\r\n
</li> \r\n
<li> \r\n
Data warehousing and business intelligence \r\n
</li> \r\n
<li> \r\n
Business data analytics \r\n
</li> \r\n
<li> \r\n
Data Mining
applications with the state of art tools such as SAS and SQL BI Services \r\n
</li> \r\n
<li> \r\n
Optimum
decision making \r\n
</li> \r\n
<li>
\r\n
Internet and Electronic Commerce\r\n
</li> \r\n
</ul> '),
(2, 'MS in Business Statistics', 'The purpose of the Master of Science in
Business Statistics program is to give students the necessary quantitative
analysis skills for industry. This program provides students with various
quantitative skills, equipping them to perform various functions in
industries.', 'The purpose of the Master of Science in Business Statistics
program is to prepare students with the necessary quantitative analysis
skills for industry. The scientific methods of statistics play an
increasingly important role in managerial analysis and decision-making under
conditions of risk and uncertainty. They are used to describe data and make
decisions and predictions in every functional area of business -- from
strategic forecasting, research, and long-range planning, to auditing and
control.'),
(2, 'MS in Production and Operations Management', 'The purpose of the Master
of Science in Production & Operations Management program is to prepare
students with the necessary Production and Operations Management skills for
the industry.', 'The purpose of the Master of Science in Production &
Operations Management is to prepare students with the necessary production an
operations management skills for industry.'),
(3, 'MBA with Concentration in MIS', 'The purpose of the Master of Business
Administration program in Management Information Systems is to prepare
students with knowledge of business functions as well as the necessary
information technology for industry.', ' The area of ISQS offers a Master of
Science in Management Information Systems in two formats. The traditional MS
in MIS program is designed to prepare students for positions in the
information technology industry. This program focuses on systems development
(including database and analysis and design of systems), networking, and
management of information systems. Courses in electronic commerce, data
mining and data warehousing, IS strategy, and many other area of information
systems are also offered.\r\n</p> \r\n<p> \r\n
\r\n
The Executive MSBA-MIS is designed for working IT
professionals. Complete details on this program are available at <a
href="http://emsba.ba.ttu.edu"
class="external">http://emsba.ba.ttu.edu</a>.'),
Page 35
Deliverable 4
December 2, 2009
(4, 'Ph.D. in MIS', 'The purpose of the Ph.D. program in MIS at Texas Tech is
to prepare students with the necessary skills for academics and research in
the field of MIS. The MIS doctoral degree plan is carefully designed to
provide the theoretical and methodological bases for advancing the state of
knowledge in MIS.', 'The Ph.D. in MIS program''s objective is to provide
students with the necessary skills for academics and research oriented
careers in information systems. The degree program is carefully designed to
provide a theoretical basis for advancing the state of knowledge in MIS.'),
(4, 'Ph.D. in Business Statistics', 'The purpose of the Ph.D. program in
Business Statistics is to prepare students with the necessary skills for
academics and research in the field of Business Statistics. The Business
Statistics doctoral degree plan is carefully designed to provide a
theoretical basis for advancing the state of knowledge in Business
Statistics.', 'The scientific methods of statistics play an increasingly
important role in managerial analysis and decision-making under conditions of
risk and uncertainty. They are used to describe data and make decisions and
predictions in every functional area of business from strategic forecasting,
research, and long-range planning, to auditing and control. A Ph.D. in
Business Statistics from the Jerry S. Rawls College of Business
Administration will give you advanced analytic skills, in addition to core
business knowledge, needed to teach in the university environment or to
operate as a competent analyst in today’s business world. This program has
been designed to train students to develop and apply modern statistical
techniques. Foundational courses include mathematical statistics,
probability, statistical computing, and linear models; additional applied
courses such as Six Sigma and Data and Text Mining give students the tools
needed for success, whether in the academic or industry sectors of
business.'),
(4, 'Ph.D. in Production and Operations Management', 'The purpose of the
Ph.D. program in POM is to prepare students with the necessary skills for
academics and research in the field of POM. The POM doctoral degree plan is
carefully designed to provide a theoretical basis for advancing the state of
knowledge in Production and Operations Management.', 'The purpose of the
Ph.D. in POM program is to prepare students with the necessary skills for
academics and research in the field of POM. The POM doctoral student degree
plan is carefully designed to provide a theoretical basis for advancing the
state of knowledge in Production and Operations Management. Students are
encouraged to pursue advanced studies in POM, as well as one research method
seminar course. More advanced, specialized courses make up the balance of the
POM doctoral program requirements.');
-- SQL Code to populate the Concentrations Table
INSERT INTO Concentrations(ProgramID,ConName) VALUES
(1,'Web Application Design');
-- SQL Code to populate the Curriculums Table
INSERT INTO Curriculums (ConID, CurrTitle, CurrDesc, CurrDocLocation) VALUES
(1, 'Course Structure', 'The MIS undergraduate program is comprised of both
lower and upper division requirements. The lower division requirements can be
found in the Texas Tech Undergraduate Catalog. The upper division
requirements are as follows.', '');
-- SQL Code to populate the Divisions Table
INSERT INTO Divisions (CurrID, DivTitle, DivSubTitle, DivOrder, DivBody)
VALUES
Page 36
Deliverable 4
December 2, 2009
(1, 'UPPER DIVISION CORE', '18 HOURS – MINIMUM GRADES OF C ARE REQUIRED.', 1,
''),
(1, 'MAJOR COURSES', '27 HOURS – MINIMUM GRADES OF C ARE REQUIRED', 2, ''),
(1, 'UPPER LEVEL ECONOMICS OR COMPUTER SCIENCE REQ', '3 HOURS – MINIMUM GRADE
OF C IS REQUIRED.', 3, 'Select any junior- or senior-level Economics course
except ECO 3323 and ECO 4332, or any junior- or senior-level Computer Science
course. Students interested in the\r\nAccelerated Program are advised to take
an Economics course.'),
(1, 'RESTRICTED ELECTIVES', '6 HOURS − MINIMUM GRADE OF C IS REQUIRED.', 4,
''),
(1, 'NON-BUSINESS / NON-ECONOMICS ELECTIVES', '6 HOURS OR ENOUGH TO COMPLETE
THE 120-HOUR REQUIREMENT – MINIMUM GRADES OF D ARE REQUIRED.', 6, 'Six hours
of non-Business/non-Economics electives are needed to have the 50% required
by AACSB accreditation standards. These courses are eligible for the
pass/fail\r\noption provided they are not major courses.'),
(1, 'RESTRICTED ELECTIVES', '6 HOURS − MINIMUM GRADE OF C IS REQUIRED.', 5,
'Choose one from the following:');
-- SQL Code to populate the Positions Table
INSERT INTO Positions (PosName, ClassID) VALUES
('Area Coordinator', 1),
('Professors', 1),
('Associate Professors', 1),
('Assistant Professors', 1),
('Visiting Professor', 1),
('Lecturers', 1),
('Senior Business Assistant', 2),
('Ph.D. Student', 3);
-- SQL Code to populate the Admissions_Programs Table
INSERT INTO Admissions_Programs (AdmID, ProgramID) VALUES
(1,1),
(2,1),
(3,2),
(3,3),
(3,4),
(4,2),
(4,3),
(4,4),
(3,5),
(4,5),
(4,6),
(4,7),
(4,8),
(5,6),
(5,7),
(5,8);
-- SQL Code to populate the Advisors Table
INSERT INTO Advisors (ProgramID, PersonID) VALUES
(1, 8),
(2, 21),
(3, 19),
(4, 4),
(5, 21),
(6, 14),
Page 37
Deliverable 4
December 2, 2009
(7, 19),
(8, 4);
-- SQL Code to populate the Requirements Table
INSERT INTO Requirements (DivID, CourseID) VALUES
(1, 1),
(1, 2),
(1, 4),
(1, 5),
(1, 6),
(2, 7),
(2, 8),
(2, 9),
(2, 10),
(2, 11),
(2, 12),
(2, 13),
(2, 14),
(2, 15),
(4, 16),
(6, 17),
(6, 18),
(6, 19),
(1, 3);
-- SQL Code to populate the Descriptions_Levels Table
INSERT INTO Descriptions_Levels (DescID, LevelID) VALUES
(1, 1),
(2, 1),
(3, 1),
(5, 2),
(6, 2),
(7, 2),
(8, 2),
(4, 2),
(4, 3),
(9, 3);
-- SQL Code to populate the Groups_Permissions Table
INSERT INTO Groups_Permissions (GroupID, PerID) VALUES
(1, 1);
-- SQL Code to populate the Groups_People Table
INSERT INTO Groups_People (GroupID, PersonID) VALUES
(1, 23);
-- SQL Code to populate the People_Positions Table
INSERT INTO People_Positions (PersonID, PosID) VALUES
(9, 1),
(6, 2),
(13, 2),
(20, 2),
(2, 3),
(16, 3),
(17, 3),
(5, 3),
Page 38
Deliverable 4
December 2, 2009
(7, 4),
(18, 4),
(1, 5),
(11, 5),
(3, 6),
(10, 6),
(12, 6),
(12, 8),
(15, 6),
(14, 3),
(4, 2),
(19, 2),
(21, 2),
(8, 3),
(22, 7);
Page 39
Deliverable 4
December 2, 2009
Stored Procedures
We will create 17 stored procedures, one for each of the following queries:
Query 1
Query #1: Who are the faculty members for the ISQS Department?
We will create a stored procedure called GetPeopleByClassID which will list all of the faculty
members of the ISQS Department.
Stored Procedure SQL
CREATE PROCEDURE GetPeopleByClassID
@ClassID INT
AS
BEGIN
SELECT personprefix,personfirstname,personlastname
FROM
people
INNER JOIN people_positions pp ON pp.personid = people.personid
INNER JOIN positions pos ON pos.posid = pp.posid
WHERE classid = @ClassID
END
Stored Procedure Output
EXEC GetPeopleByClassID
1
Page 40
Deliverable 4
December 2, 2009
Query 2
Query #2: What programs does a faculty member advise?
We will create a stored procedure called GetProgAdvisoredByPersonID will list what programs a
particular faculty member advises.
Stored Procedure SQL
CREATE PROCEDURE GetProgAdvisoredByPersonID
@PersonID INT
AS
BEGIN
SELECT programtitle
FROM
programs prog
INNER JOIN advisors ON advisors.programid = prog.programid
WHERE advisors.personid = 4
END
Stored Procedure Output
EXEC GetProgAdvisoredByPersonID
4
Page 41
Deliverable 4
December 2, 2009
Query 3
Query #3: What are the required courses to complete a given program?
We will create a stored procedure called GetCoursesByProgramID will get all of the required
courses to complete a given program.
Stored Procedure SQL
CREATE PROCEDURE GetCoursesByProgramID
@ProgramID INT
AS
BEGIN
SELECT coursesubject,coursecallnumber,coursename
FROM
courses
INNER JOIN Requirements cc ON cc.courseid = courses.courseid
INNER JOIN Divisions cat ON cat.DivID = cc.DivID
INNER JOIN curriculums curr ON cat.currid = curr.currid
INNER JOIN concentrations con ON con.conid = curr.conid
WHERE con.programid = @ProgramID
END
Stored Procedure Output
EXEC GetCoursesByProgramID
1
Page 42
Deliverable 4
December 2, 2009
Query 4
Query #4: What programs are offered for a particular degree (BBA, MBA, Ph. D)?
We will create a stored procedure called GetProgramsByDegreeID will list all of the programs
offered for a particular degree.
Stored Procedure SQL
CREATE PROCEDURE GetProgramsByDegreeID
@DegreeID INT
AS
BEGIN
SELECT programtitle
FROM
programs
WHERE degreeid = @DegreeID
END
Stored Procedure Output
EXEC GetProgramsByDegreeID
1
Page 43
Deliverable 4
December 2, 2009
Query 5
Query #5: What are the admission requirements for a given program?
We will create a stored procedure called GetAdmissionsByProgramID which will list all of the
admissions requirements for a particular program.
Stored Procedure SQL
CREATE PROCEDURE GetAdmissionsByProgramID
@ProgramID INT
AS
BEGIN
SELECT admtitle,admbody
FROM
admissions adm
INNER JOIN admissions_programs ap ON ap.admid = adm.admid
INNER JOIN programs ON programs.programid = ap.programid
WHERE programs.programid = @ProgramID
END
Stored Procedure Output
EXEC GetAdmissionsByProgramID
1
Page 44
Deliverable 4
December 2, 2009
Query 6
Query #6: What is the description of a given program?
We will create a stored procedure called GetDescriptionsByProgramID which will list all of the
descriptions of a particular program.
Stored Procedure SQL
CREATE PROCEDURE GetDescriptionsByProgramID
@ProgramID INT
AS
BEGIN
SELECT desctitle,descbody
FROM
descriptions des
INNER JOIN descriptions_levels dl ON dl.descid = des.descid
INNER JOIN levels l ON l.levelid = dl.levelid
INNER JOIN [Degrees] deg ON deg.levelid = l.levelid
INNER JOIN programs prog ON prog.degreeid = deg.degreeid
WHERE prog.programid = @ProgramID
END
Stored Procedure Output
EXEC GetDescriptionsByProgramID
1
Page 45
Deliverable 4
December 2, 2009
Query 7
Query #7: What people have permission to modify the content?
We will create a stored procedure called GetPeoplePermissions which will list all the people who
have permission to modify content.
Stored Procedure SQL
CREATE PROCEDURE GetPeoplePermissions
AS
BEGIN
SELECT personprefix,personfirstname,personlastname
FROM
people
INNER JOIN groups_people g_people
ON g_people.personid = people.personid
INNER JOIN groups_permissions g_per
ON g_per.groupid = g_people.groupid
INNER JOIN [Permissions] per ON per.perid = g_per.perid
END
Stored Procedure Output
EXEC GetPeoplePermissions
Page 46
Deliverable 4
December 2, 2009
Query 8
Query #8: What are the permissions for a given person?
We will create a stored procedure called GetPermissionsByPersonID which will list all the
permissions for a particular person.
Stored Procedure SQL
CREATE PROCEDURE GetPermissionsByPersonID
@PersonID INT
AS
BEGIN
SELECT peraction
FROM
[Permissions] per
INNER JOIN groups_permissions gper ON gper.perid = per.perid
INNER JOIN groups_people gp ON gp.groupid = gper.groupid
WHERE gp.personid = @PersonID
END
Stored Procedure Output
EXEC GetPermissionsByPersonID
23
Page 47
Deliverable 4
December 2, 2009
Query 9
Query #9: What is the classification of a given person.
We will create a stored procedure called GetClassificaitonByPersonID which will list the
classification for a particular person.
Stored Procedure SQL
CREATE PROCEDURE GetClassificaitonByPersonID
@PersonID INT
AS
BEGIN
SELECT classname
FROM
classifications class
INNER JOIN positions pos ON pos.classid = class.classid
INNER JOIN people_positions pp ON pp.posid = pos.posid
WHERE pp.personid = @PersonID
END
Stored Procedure Output
EXEC GetClassificaitonByPersonID
1
Page 48
Deliverable 4
December 2, 2009
Query 10
Query #10: What courses are needed for a specific concentration?
We will create a stored procedure called GetCoursesByConID which will list all the courses
required for a particular concentration.
Stored Procedure SQL
CREATE PROCEDURE GetCoursesByConID
@ConID INT
AS
BEGIN
SELECT coursesubject,coursecallnumber,coursename
FROM
courses
INNER JOIN Requirements cc ON cc.courseid = courses.courseid
INNER JOIN Divisions cat ON cat.DivID = cc.DivID
INNER JOIN curriculums curr ON cat.currid = curr.currid
INNER JOIN concentrations con ON con.conid = curr.conid
WHERE con.conid = @ConID
END
Stored Procedure Output
EXEC GetCoursesByConID
1
Page 49
Deliverable 4
December 2, 2009
Query 11
Query #11: What are the admissions requirements for a given level?
We will create a stored procedure called GetAdmissionsByLevelID which will list all the
admissions requirements for a particular level.
Stored Procedure SQL
CREATE PROCEDURE GetAdmissionsByLevelID
@LevelID INT
AS
BEGIN
SELECT admtitle,admbody
FROM
admissions adm
INNER JOIN admissions_programs ap ON ap.admid = adm.admid
INNER JOIN programs prog ON prog.programid = ap.programid
INNER JOIN [Degrees] deg ON deg.degreeid = prog.degreeid
WHERE deg.levelid = @LevelID
END
Stored Procedure Output
EXEC GetAdmissionsByLevelID
1
Page 50
Deliverable 4
December 2, 2009
Query 12
Query #12: What courses are available for a degree?
We will create a stored procedure called GetCoursesByDegreeID which will list all the courses
offered for a particular degree.
Stored Procedure SQL
CREATE PROCEDURE GetCoursesByDegreeID
@DegreeID INT
AS
BEGIN
SELECT coursesubject,coursecallnumber,coursename
FROM
courses
INNER JOIN Requirements cc ON cc.courseid = courses.courseid
INNER JOIN Divisions cat ON cat.DivID = cc.DivID
INNER JOIN curriculums curr ON cat.currid = curr.currid
INNER JOIN concentrations con ON con.conid = curr.conid
INNER JOIN programs prog ON prog.programid = con.programid
WHERE prog.degreeid = @DegreeID
END
Stored Procedure Output
EXEC GetCoursesByDegreeID
1
Page 51
Deliverable 4
December 2, 2009
Query 13
Query #13: Which positions advise undergraduate degrees?
We will create a stored procedure called GetAdvisorPositionsByLevelID which will list all the
positions that advise a particular level.
Stored Procedure SQL
CREATE PROCEDURE GetAdvisorPositionsByLevelID
@LevelID INT
AS
BEGIN
SELECT DISTINCT (posname)
FROM
positions pos
INNER JOIN people_positions pp ON pp.posid = pos.posid
INNER JOIN advisors adv ON adv.personid = pp.personid
INNER JOIN programs prog ON prog.programid = adv.programid
INNER JOIN [Degrees] deg ON deg.degreeid = prog.degreeid
WHERE deg.levelid = @LevelID
END
Stored Procedure Output
EXEC GetAdvisorPositionsByLevelID
2
Page 52
Deliverable 4
December 2, 2009
Query 14
Query #14: What is the description of a specific concentration?
We will create a stored procedure called GetDescriptionsByConID which will list all the
descriptions of a particular concentration.
Stored Procedure SQL
CREATE PROCEDURE GetDescriptionsByConID
@ConID INT
AS
BEGIN
SELECT desctitle,descbody
FROM
descriptions des
INNER JOIN descriptions_levels dl ON dl.descid = des.descid
INNER JOIN [Degrees] deg ON deg.levelid = dl.levelid
INNER JOIN programs prog ON prog.degreeid = deg.degreeid
INNER JOIN concentrations con ON con.programid = prog.programid
WHERE con.conid = @ConID
END
Stored Procedure Output
EXEC GetDescriptionsByConID
1
Page 53
Deliverable 4
December 2, 2009
Query 15
Query #15: What Divisions does a course fall under?
We will create a stored procedure called GetDivisionsByCourseID which will list all the various
Divisions a particular course is listed under.
Stored Procedure SQL
CREATE PROCEDURE GetDivisionsByCourseID
@CourseID INT
AS
BEGIN
SELECT DISTINCT (DivTitle)
FROM
Divisions cat
INNER JOIN Requirements cc ON cc.DivID = cat.DivID
WHERE cc.courseid = @CourseID
END
Stored Procedure Output
EXEC GetDivisionsByCourseID
1
Page 54
Deliverable 4
December 2, 2009
Query 16
Query #16: What level is a program associated with?
We will create a stored procedure called GetLevelByProgramID which will list the level a
particular program is associated with.
Stored Procedure SQL
CREATE PROCEDURE GetLevelByProgramID
@ProgramID INT
AS
BEGIN
SELECT levelname
FROM
levels lvl
INNER JOIN [Degrees] deg ON deg.levelid = lvl.levelid
INNER JOIN programs prog ON prog.degreeid = deg.degreeid
WHERE prog.programid = @ProgramID
END
Stored Procedure Output
EXEC GetLevelByProgramID
1
Page 55
Deliverable 4
December 2, 2009
Query 17
Query #17: What group has a specific permission?
We will create a stored procedure called GetGroupsByPerID which will list all the permissions for
a particular group.
Stored Procedure SQL
CREATE PROCEDURE GetGroupsByPerID
@PerID INT
AS
BEGIN
SELECT DISTINCT (groupname)
FROM
groups
INNER JOIN groups_permissions gp ON gp.groupid = groups.groupid
INNER JOIN [Permissions] per ON per.perid = gp.perid
WHERE per.perid = @PerID
END
Stored Procedure Output
EXEC GetGroupsByPerID
1
Page 56
