human
Write a summary about how a relational database that can be used to take care of the student course coordination requirements at the University of London.
assistant
The essay discusses how a relational database can be used to take care of the student course coordination requirements at the University of London. The relational database for this university includes students and tutors among other users. This study is going to focus on the tutor as one of the user groups found within the university database. The tutor in this setup will also double up as a module coordinator and will therefore need information relating to a module, degree, student, schedule, and campus.
human
Reverse the sentences.
assistant
The tutor in this setup will also double up as a module coordinator and will therefore need information relating to a module, degree, student, schedule, and campus. This study is going to focus on the tutor as one of the user groups found within the university database. The relational database for this university includes students and tutors among other users.The essay discusses how a relational database can be used to take care of the student course coordination requirements at the University of London
human
Provide an essay about how a relational database that can be used to take care of the student course coordination requirements at the University of London. Application only. End with the sentence 'When this query is run with StudentID 12456, the result is shown below.'
assistant
The GetDay query as one of the parameter queries accepts a day of the week as input at the prompt to display the records of all the modules undertaken during that day of the week. The screens below show this query when it is run.
After submitting a parameter as M, for Monday as one of the days of the week and clicking on the modules for the day button, the following screen in displayed:
Other queries include the Student and Student campus parameter queries added to the database based on the requirements. A parameter query is a select query type that retrieves data from the database based on a user-defined parameter. This exercise demonstrates two parameter queries created based on student and campus data.
The student parameter query is a simple query that will return the details of a specified student whose details are submitted in the ‘enter StudentID ‘ prompt box as shown in the screens below.
The student parameter query design is shown below.
Running this query results in the details of the student whose ID was submitted as the parameter.
The following screen shows the prompt box with a valid StudentID (12456)
On clicking the ok button, the student parameter query will retrieve the details of StudentID (12456) as shown below:
It is therefore possible to quickly retrieve the name and module coordinator for any of the thirteen students in the university database using the student parameter query by simply submitting a valid student ID.
It may be necessary to know which campus each of the students is at and this can be achieved by running the Student_campus parameter query. The search criterion is based on the StudentID submitted in a prompt box.
The Student_campus parameter query design is shown below. The tables used here are the Module coordinator, Student and Tutors.
The defined relationship between the three tables student, module coordinator, and tutor enables the query to pick data from the three tables at the same time.
When this query is run with StudentID 12456, the result is shown below.
human
Provide an Relationships section.
assistant
Access and other relational databases have a way of connecting the various tables in the database to enable other database objects like the queries and reports to retrieve consolidated data from these different tables. The simplest database relationship is a one –to –one relationship meaning that each record in one of the tables has only one related record in another table. Alternatively, a one –to – many relationships is where a record in one table has one or more associated records in another table. In order to enable the retrieval and consolidation of data to be meaningful, on how data will be added, updated, and deleted. This process involves setting rules from these tables.
The university database has a number of tables that are related with some having enforced referential integrity.
The relationship between the module coordinator student and module coordinator tutor and is a one- to – many relationship meaning that one record in the module coordinator table refers to one or more records in the student and tutor tables respectively.
The Campus and Degree tables have a one –to – many relationship between them as well with referential integrity enforced.
The relationship between Degree and Student and Schedule and Room Number is indeterminate with the join property along rows where the joined fields from the two tables are equal.
The relationship between the Tutors and Room Number is indeterminate with the join property including all records from Tutors and only those from Room Number where the fields are equal.
human
Table structure documentation
assistant
This university database has a number of tables. They include Campus, Degree, Student, Tutor, Module Coordinator, Room Number, and Schedule.
The Campus table consists of the campus name, county, postcode, address, and telephone. The primary key is the field Campus.
The Degree table consists of ModCode , Campus, SingleHons, and Combined as the fields. The primary key for this table is the ModCode.
The Student table consists of StudentID , Name, Address, County, Postcode, Email, Telephone Number, Group, ModCoord, and ModCode.
The Tutor table consists of CoordID , ModCoord, StudentID, Name, Room, and Campus.
The Module coordinator table consists of ModCoord , Email, Room, Telephone, Campus, and ModCode.
The Room Number table consists of ModCode, Module, Semester, Type, Group, Campus, Room, and RoomID.
The Schedule table consists of ModCode, ModCoord, Semester, Day, Type, Group, StTime, EndTime, RoomID, Campus, and ScheduleID:
The student_degree query has an inner join as indicated in the SQL statements below:
 * SELECT Student. [Student ID], Student.Name, Degree.ModCode, Degree.Combined
 * FROM Degree INNER JOIN Student ON Degree.ModCode = Student.ModCode;
The following is the data in each of the tables captured in the datasheet view:
human
How about a User Guide section.
assistant
This application has been developed in the Microsoft Access 2003 and later environment and therefore will run in this environment.
The application requires the following to successfully run A windows operating system platform.
The Microsoft Office 2003 or later suite that includes the Microsoft Access application.
The application also requires a minimum hard disk capacity of 45 Mb.
The application will run well using RAM of 256Mb and above.
On opening the application, the main switchboard is activated from where the user can call and run other modules of the application. The screen below illustrates the main switchboard with the following options:
 * Student details: Used to open a student form in edit or add mode
 * Tutor details: Used to open a Tutor form in edit or add mode
 * Schedule details: Used to open a Schedule form in add or edit mode
 * Coordinator details: Used to open the Module coordinator form in add or edit mode
 * Exit database: Used to exit from the application
Modules overview
This application consists of a number of modules. The main one are described here below:
Tutor: This module handles all the tutor details in this application. A typical screen for this module is shown below:
Schedule: This module handles all the schedule details in this application. A typical screen for this module is shown below:
Coordinator: This module handles all the module coordinator details in this application. A typical screen for this module is shown below:
The application also contains four main reports namely:
 * Module coordinator report
 * Student report
 * Tutor report
 * Schedule report
An entity relationship diagram (E-R) of the University of London Relational database.
The summary of the attributes for the ER diagram above are shown in the table below:
ENTITY       ATTRIBUTES                              
Tutor        CoordID, ModCoord, StudentID, Name, RoomID, Campus.         
Student       StudentID, Name, Address, County, Postcode, Email, Telephone number, 
          Group, ModCoord, ModCode.                      
Schedule      ScheduleID, ModCode, ModCoord, Semester, Day, Type, Group, StTime,  
          EndTime, RoomID, Campus, Room.                    
Room number     RoomID, Campus, ModCode, Module, Semester, Type, Group, Campus, Room.
Module coordinator RoomID, ModCoord, Email, Room, Telephone, Campus.          
Degree       ModCode, ModCoord, SingleHons, Combined.               
Campus       Campus, Address, County, Postcode, Telephone.
human
Delete the last sentence.
assistant
This application has been developed in the Microsoft Access 2003 and later environment and therefore will run in this environment.
The application requires the following to successfully run A windows operating system platform.
The Microsoft Office 2003 or later suite that includes the Microsoft Access application.
The application also requires a minimum hard disk capacity of 45 Mb.
The application will run well using RAM of 256Mb and above.
On opening the application, the main switchboard is activated from where the user can call and run other modules of the application. The screen below illustrates the main switchboard with the following options:
 * Student details: Used to open a student form in edit or add mode
 * Tutor details: Used to open a Tutor form in edit or add mode
 * Schedule details: Used to open a Schedule form in add or edit mode
 * Coordinator details: Used to open the Module coordinator form in add or edit mode
 * Exit database: Used to exit from the application
Modules overview
This application consists of a number of modules. The main one are described here below:
Tutor: This module handles all the tutor details in this application. A typical screen for this module is shown below:
Schedule: This module handles all the schedule details in this application. A typical screen for this module is shown below:
Coordinator: This module handles all the module coordinator details in this application. A typical screen for this module is shown below:
The application also contains four main reports namely:
 * Module coordinator report
 * Student report
 * Tutor report
 * Schedule report
An entity relationship diagram (E-R) of the University of London Relational database.
The summary of the attributes for the ER diagram above are shown in the table below:
ENTITY       ATTRIBUTES                              
Tutor        CoordID, ModCoord, StudentID, Name, RoomID, Campus.         
Student       StudentID, Name, Address, County, Postcode, Email, Telephone number, 
          Group, ModCoord, ModCode.                      
Schedule      ScheduleID, ModCode, ModCoord, Semester, Day, Type, Group, StTime,  
          EndTime, RoomID, Campus, Room.                    
Room number     RoomID, Campus, ModCode, Module, Semester, Type, Group, Campus, Room.
Module coordinator RoomID, ModCoord, Email, Room, Telephone, Campus.          
Degree       ModCode, ModCoord, SingleHons, Combined.
human
Put it all togegther in the right order.
assistant
##Application
The GetDay query as one of the parameter queries accepts a day of the week as input at the prompt to display the records of all the modules undertaken during that day of the week. The screens below show this query when it is run.
After submitting a parameter as M, for Monday as one of the days of the week and clicking on the modules for the day button, the following screen in displayed:
Other queries include the Student and Student campus parameter queries added to the database based on the requirements. A parameter query is a select query type that retrieves data from the database based on a user-defined parameter. This exercise demonstrates two parameter queries created based on student and campus data.
The student parameter query is a simple query that will return the details of a specified student whose details are submitted in the ‘enter StudentID ‘ prompt box as shown in the screens below.
The student parameter query design is shown below.
Running this query results in the details of the student whose ID was submitted as the parameter.
The following screen shows the prompt box with a valid StudentID (12456)
On clicking the ok button, the student parameter query will retrieve the details of StudentID (12456) as shown below:
It is therefore possible to quickly retrieve the name and module coordinator for any of the thirteen students in the university database using the student parameter query by simply submitting a valid student ID.
It may be necessary to know which campus each of the students is at and this can be achieved by running the Student_campus parameter query. The search criterion is based on the StudentID submitted in a prompt box.
The Student_campus parameter query design is shown below. The tables used here are the Module coordinator, Student and Tutors.
The defined relationship between the three tables student, module coordinator, and tutor enables the query to pick data from the three tables at the same time.
When this query is run with StudentID 12456, the result is shown below.
##Table structure documentation
This university database has a number of tables. They include Campus, Degree, Student, Tutor, Module Coordinator, Room Number, and Schedule.
The Campus table consists of the campus name, county, postcode, address, and telephone. The primary key is the field Campus.
The Degree table consists of ModCode , Campus, SingleHons, and Combined as the fields. The primary key for this table is the ModCode.
The Student table consists of StudentID , Name, Address, County, Postcode, Email, Telephone Number, Group, ModCoord, and ModCode.
The Tutor table consists of CoordID , ModCoord, StudentID, Name, Room, and Campus.
The Module coordinator table consists of ModCoord , Email, Room, Telephone, Campus, and ModCode.
The Room Number table consists of ModCode, Module, Semester, Type, Group, Campus, Room, and RoomID.
The Schedule table consists of ModCode, ModCoord, Semester, Day, Type, Group, StTime, EndTime, RoomID, Campus, and ScheduleID:
The student_degree query has an inner join as indicated in the SQL statements below:
 * SELECT Student. [Student ID], Student.Name, Degree.ModCode, Degree.ModCode = Student.ModCode;
The following is the data in each of the tables captured in the datasheet view:
##Relationships
Access and other relational databases have a way of connecting the various tables in the database to enable other database objects like the queries and reports to retrieve consolidated data from these different tables. The simplest database relationship is a one –to –one relationship meaning that each record in one of the tables has only one related record in another table. Alternatively, a one –to – many relationships is where a record in one table has one or more associated records in another table. In order to enable the retrieval and consolidation of data to be meaningful, on how data will be added, updated, and deleted. This process involves setting rules from these tables.
The university database has a number of tables that are related with some having enforced referential integrity.
The relationship between the module coordinator student and module coordinator tutor and is a one- to – many relationship meaning that one record in the module coordinator table refers to one or more records in the student and tutor tables respectively.
The Campus and Degree tables have a one –to – many relationship between them as well with referential integrity enforced.
The relationship between Degree and Student and Schedule and Room Number is indeterminate with the join property along rows where the joined fields from the two tables are equal.
The relationship between the Tutors and Room Number is indeterminate with the join property including all records from Tutors and only those from Room Number where the fields are equal.
##User Guide
This application has been developed in the Microsoft Access 2003 and later environment and therefore will run in this environment.
The application requires the following to successfully run A windows operating system platform.
The Microsoft Office 2003 or later suite that includes the Microsoft Access application.
The application also requires a minimum hard disk capacity of 45 Mb.
The application will run well using RAM of 256Mb and above.
On opening the application, the main switchboard is activated from where the user can call and run other modules of the application. The screen below illustrates the main switchboard with the following options:
 * Student details: Used to open a student form in edit or add mode
 * Tutor details: Used to open a Tutor form in edit or add mode
 * Schedule details: Used to open a Schedule form in add or edit mode
 * Coordinator details: Used to open the Module coordinator form in add or edit mode
 * Exit database: Used to exit from the application
Modules overview
This application consists of a number of modules. The main one are described here below:
Tutor: This module handles all the tutor details in this application. A typical screen for this module is shown below:
Schedule: This module handles all the schedule details in this application. A typical screen for this module is shown below:
Coordinator: This module handles all the module coordinator details in this application. A typical screen for this module is shown below:
The application also contains four main reports namely:
 * Module coordinator report
 * Student report
 * Tutor report
 * Schedule report
An entity relationship diagram (E-R) of the University of London Relational database.
The summary of the attributes for the ER diagram above are shown in the table below:
ENTITY       ATTRIBUTES                              
Tutor        CoordID, ModCoord, StudentID, Name, RoomID, Campus.         
Student       StudentID, Name, Address, County, Postcode, Email, Telephone number, 
          Group, ModCoord, ModCode.                      
Schedule      ScheduleID, ModCode, ModCoord, Semester, Day, Type, Group, StTime,  
          EndTime, RoomID, Campus, Room.                    
Room number     RoomID, Campus, ModCode, Module, Semester, Type, Group, Campus, Room.
Module coordinator RoomID, ModCoord, Email, Room, Telephone, Campus.          
Degree       ModCode, ModCoord, SingleHons, Combined.               
Campus       Campus, Address, County, Postcode, Telephone.
human
Add another sentence about Combined, Degree, JOIN.
assistant
##Application
The GetDay query as one of the parameter queries accepts a day of the week as input at the prompt to display the records of all the modules undertaken during that day of the week. The screens below show this query when it is run. 
After submitting a parameter as M, for Monday as one of the days of the week and clicking on the modules for the day button, the following screen in displayed:
Other queries include the Student and Student campus parameter queries added to the database based on the requirements. A parameter query is a select query type that retrieves data from the database based on a user-defined parameter. This exercise demonstrates two parameter queries created based on student and campus data. 
The student parameter query is a simple query that will return the details of a specified student whose details are submitted in the ‘enter StudentID ‘ prompt box as shown in the screens below. 
The student parameter query design is shown below. 
Running this query results in the details of the student whose ID was submitted as the parameter. 
The following screen shows the prompt box with a valid StudentID (12456)
On clicking the ok button, the student parameter query will retrieve the details of StudentID (12456) as shown below:
It is therefore possible to quickly retrieve the name and module coordinator for any of the thirteen students in the university database using the student parameter query by simply submitting a valid student ID. 
It may be necessary to know which campus each of the students is at and this can be achieved by running the Student_campus parameter query. The search criterion is based on the StudentID submitted in a prompt box. 
The Student_campus parameter query design is shown below. The tables used here are the Module coordinator, Student and Tutors. 
The defined relationship between the three tables student, module coordinator, and tutor enables the query to pick data from the three tables at the same time. 
When this query is run with StudentID 12456, the result is shown below. 
##Table structure documentation
This university database has a number of tables. They include Campus, Degree, Student, Tutor, Module Coordinator, Room Number, and Schedule. 
The Campus table consists of the campus name, county, postcode, address, and telephone. The primary key is the field Campus. 
The Degree table consists of ModCode , Campus, SingleHons, and Combined as the fields. The primary key for this table is the ModCode. 
The Student table consists of StudentID , Name, Address, County, Postcode, Email, Telephone Number, Group, ModCoord, and ModCode. 
The Tutor table consists of CoordID , ModCoord, StudentID, Name, Room, and Campus. 
The Module coordinator table consists of ModCoord , Email, Room, Telephone, Campus, and ModCode. 
The Room Number table consists of ModCode, Module, Semester, Type, Group, Campus, Room, and RoomID. 
The Schedule table consists of ModCode, ModCoord, Semester, Day, Type, Group, StTime, EndTime, RoomID, Campus, and ScheduleID:
The student_degree query has an inner join as indicated in the SQL statements below:
 * SELECT Student. [Student ID], Student. Name, Degree. ModCode, Degree. Combined
 * FROM Degree INNER JOIN Student ON Degree. ModCode = Student. ModCode;
The following is the data in each of the tables captured in the datasheet view:
##Relationships
Access and other relational databases have a way of connecting the various tables in the database to enable other database objects like the queries and reports to retrieve consolidated data from these different tables. The simplest database relationship is a one –to –one relationship meaning that each record in one of the tables has only one related record in another table. Alternatively, a one –to – many relationships is where a record in one table has one or more associated records in another table. In order to enable the retrieval and consolidation of data to be meaningful, on how data will be added, updated, and deleted. This process involves setting rules from these tables. 
The university database has a number of tables that are related with some having enforced referential integrity. 
The relationship between the module coordinator student and module coordinator tutor and is a one- to – many relationship meaning that one record in the module coordinator table refers to one or more records in the student and tutor tables respectively. 
The Campus and Degree tables have a one –to – many relationship between them as well with referential integrity enforced. 
The relationship between Degree and Student and Schedule and Room Number is indeterminate with the join property along rows where the joined fields from the two tables are equal. 
The relationship between the Tutors and Room Number is indeterminate with the join property including all records from Tutors and only those from Room Number where the fields are equal. 
##User Guide
This application has been developed in the Microsoft Access 2003 and later environment and therefore will run in this environment. 
The application requires the following to successfully run A windows operating system platform. 
The Microsoft Office 2003 or later suite that includes the Microsoft Access application. 
The application also requires a minimum hard disk capacity of 45 Mb. 
The application will run well using RAM of 256Mb and above. 
On opening the application, the main switchboard is activated from where the user can call and run other modules of the application. The screen below illustrates the main switchboard with the following options:
 * Student details: Used to open a student form in edit or add mode
 * Tutor details: Used to open a Tutor form in edit or add mode
 * Schedule details: Used to open a Schedule form in add or edit mode
 * Coordinator details: Used to open the Module coordinator form in add or edit mode
 * Exit database: Used to exit from the application
Modules overview
This application consists of a number of modules. The main one are described here below:
Tutor: This module handles all the tutor details in this application. A typical screen for this module is shown below:
Schedule: This module handles all the schedule details in this application. A typical screen for this module is shown below:
Coordinator: This module handles all the module coordinator details in this application. A typical screen for this module is shown below:
The application also contains four main reports namely:
 * Module coordinator report
 * Student report
 * Tutor report
 * Schedule report
An entity relationship diagram (E-R) of the University of London Relational database. 
The summary of the attributes for the ER diagram above are shown in the table below:
ENTITY       ATTRIBUTES                              
Tutor        CoordID, ModCoord, StudentID, Name, RoomID, Campus.          
Student       StudentID, Name, Address, County, Postcode, Email, Telephone number, 
          Group, ModCoord, ModCode.                       
Schedule      ScheduleID, ModCode, ModCoord, Semester, Day, Type, Group, StTime,  
          EndTime, RoomID, Campus, Room.                    
Room number     RoomID, Campus, ModCode, Module, Semester, Type, Group, Campus, Room. 
Module coordinator RoomID, ModCoord, Email, Room, Telephone, Campus.           
Degree       ModCode, ModCoord, SingleHons, Combined.               
Campus       Campus, Address, County, Postcode, Telephone.