Courses Table-WPS Office

### Courses Table:
```plaintext
Courses
-------
CourseID (Primary Key)
CourseName
ProgramID (Foreign Key referencing Programs Table)
YearID (Foreign Key referencing Years Table)
Other relevant fields (e.g., course details)
```
### Professor Table:
```plaintext
Professors
----------
ProfessorID (Primary Key)
FirstName
LastName
Other relevant fields (e.g., contact information)
```
### Building/Room Table:

```plaintext
BuildingsRooms
--------------
RoomID (Primary Key)
BuildingName
RoomNumber
Capacity
Other relevant fields (e.g., facilities)
```
These tables are designed to establish relationships between courses, professors, and buildings/rooms.
Adjust the fields based on your specific requirements and relationships between entities in the
scheduling system. This structure allows for effective management of courses across different programs
and year levels, as well as tracking information about professors and available facilities.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
Certainly! When designing the Professor and Course tables, you would establish a relationship between
them, typically using a junction table to handle the many-to-many relationship since a professor can
teach multiple courses, and a course can have multiple professors. Here's how the tables might look:
### Professor Table:
```plaintext
Professors
----------
ProfessorID (Primary Key)

FirstName
LastName
```
### Course Table:
```plaintext
Courses
-------
CourseID (Primary Key)
CourseName
Other relevant fields (e.g., course details)
```
### ProfessorCourse Table (Junction Table):
```plaintext
ProfessorCourse
---------------
ProfessorCourseID (Primary Key)
ProfessorID (Foreign Key referencing Professors Table)
CourseID (Foreign Key referencing Courses Table)

```
This junction table (`ProfessorCourse`) establishes the many-to-many relationship between professors
and courses. Each record in this table connects a professor with a specific course they are teaching. This
design allows for flexibility and scalability in assigning professors to courses within the scheduling
system.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
### Programs Table:
```plaintext
Programs
--------
ProgramID (Primary Key)
ProgramName
Other relevant fields
```
### Students Table:
```plaintext
Students
--------
StudentID (Primary Key)
FirstName
LastName
```
In this structure, the `Students` table is connected to the `Programs` table through the `ProgramID`
foreign key. This allows you to associate each student with a specific program. Adjust the fields based on
your specific requirements and relationships between entities in the scheduling system.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
Certainly! To represent the connection between buildings and rooms, you can use a structure where
each room is associated with a specific building. Here's how the tables might look:
### Building Table:
```plaintext
Buildings
---------
BuildingID (Primary Key)
BuildingName
Other relevant fields (e.g., location)
```
### Room Table:
```plaintext
Rooms
-----
RoomID (Primary Key)
RoomNumber
Capacity
BuildingID (Foreign Key referencing Buildings Table)
Other relevant fields (e.g., room details)
```
In this structure, the `BuildingID` in the `Rooms` table serves as a foreign key referencing the `Buildings`
table. This establishes a connection between rooms and their respective buildings. You can then query
the database to get information about rooms within a specific building or find out which building a
particular room belongs to.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
The structure of the `Schedule` table would depend on the specific requirements of your scheduling
system. However, here's a general template you can use as a starting point:
### Schedule Table:
```plaintext
Schedule
--------
ScheduleID (Primary Key)
CourseID (Foreign Key referencing Courses Table)
RoomID (Foreign Key referencing Rooms Table)
ProfessorID (Foreign Key referencing Professors Table)
DayOfWeek
StartTime
EndTime
Other relevant fields (e.g., semester, class type)
```
This structure allows you to associate courses with specific rooms, professors, and schedule details.
Adjust the fields based on your system's needs. You can use the foreign keys to establish relationships
with other tables in the database, providing a comprehensive view of the scheduling information.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
Yes, it's generally a good practice to organize student information based on different programs, year
levels, and class sections. Here's a suggested structure for the `Students` table:
### Students Table:
```plaintext
Students
--------
StudentID (Primary Key)
FirstName
LastName
ClassSection
```
This structure allows you to associate students with specific programs, year levels, and class sections.
The `ProgramID` and `YearID` are foreign keys referencing the `Programs` and `Years` tables,
respectively. The `ClassSection` field helps distinguish students within the same year and program.
Adjust the fields based on your specific requirements. This organization makes it easier to manage and
query student data based on their academic details.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
You can establish a relationship between the Room and Building tables by adding a foreign key in the
Room table that references the primary key of the Building table. Here's a simplified example:
1. **Building Table:**
- BuildingID (Primary Key)

- BuildingName
- ...
2. **Room Table:**
- RoomID (Primary Key)
- RoomNumber
- BuildingID (Foreign Key referencing Building)
In this setup:
- Each room in the Room table is associated with a specific building through the BuildingID foreign key.
- RoomNumber uniquely identifies each room.
- BuildingID in the Room table establishes a connection to the corresponding Building in the Building
table.
For example:
Building Table:
| BuildingID | BuildingName |
|------------|--------------|
|1 | Building A |
|2 | Building B |
| ... | ... |
Room Table:
| RoomID | RoomNumber | BuildingID |
|--------|------------|------------|
| 101 | A1 |1 |
| 102 | A2 |1 |
| 201 | B1 |2 |
| ... | ... | ... |
This way, you can link specific rooms (RoomNumber) to their respective buildings (BuildingID) in the
Room table.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
To establish a many-to-many relationship between the Professor and Course tables (assuming a
professor can teach multiple courses, and a course can be taught by multiple professors), you can create
an intermediary table often referred to as a junction table or association table. Here's a simplified
example:
1. **Professor Table:**
- ProfessorID (Primary Key)
- FirstName
- LastName
- ...
2. **Course Table:**
- CourseID (Primary Key)
- CourseName
- ...
3. **ProfessorCourse Table (Junction Table):**
- ProfessorCourseID (Primary Key)
- ProfessorID (Foreign Key referencing Professor)
- CourseID (Foreign Key referencing Course)
In this setup:
- The ProfessorCourse table connects professors to the courses they teach.
- ProfessorCourseID is a unique identifier for each professor-course relationship.
- ProfessorID in the ProfessorCourse table is a foreign key referencing the Professor table.
- CourseID in the ProfessorCourse table is a foreign key referencing the Course table.
For example:
Professor Table:
| ProfessorID | FirstName | LastName |
|-------------|-----------|----------|
|1 | Jimmy | Professor|
|2 | Jane | Doe |
| ... | ... | ... |
Course Table:
| CourseID | CourseName |
|----------|--------------|
| 101 | Math |
| 102 | Science |
| 103 | Filipino |
| ... | ... |
ProfessorCourse Table:
| ProfessorCourseID | ProfessorID | CourseID |
|-------------------|--------------|----------|
|1 |1 | 101 |
|2 |1 | 102 |
|3 |1 | 103 |
|4 |2 | 101 |
| ... | ... | ... |
This way, you can track which professor teaches which courses by referencing their respective IDs in the
junction table.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
To model the relationship between the Program and Course tables, where a program can have multiple
courses and a course can be part of multiple programs, you can use an intermediary table. Here's a
simplified example:
1. **Program Table:**
- ProgramID (Primary Key)
- ProgramName
- ...
- CourseID (Primary Key)
- CourseName
- ...
3. **ProgramCourse Table (Junction Table):**
- ProgramCourseID (Primary Key)
- ProgramID (Foreign Key referencing Program)
- CourseID (Foreign Key referencing Course)
In this setup:
- The ProgramCourse table connects programs to the courses they include.
- ProgramCourseID is a unique identifier for each program-course relationship.
- ProgramID in the ProgramCourse table is a foreign key referencing the Program table.
- CourseID in the ProgramCourse table is a foreign key referencing the Course table.
For example:
Program Table:
| ProgramID | ProgramName |
|-----------|-----------------------|
|1 | Information Technology|
|2 | Computer Science |
| ... | ... |
Course Table:
| CourseID | CourseName |
|----------|-------------|
| 101 | Computer1 |
| 102 | Computer2 |
| 103 | Database |
| ... | ... |
ProgramCourse Table:
| ProgramCourseID | ProgramID | CourseID |
|------------------|-----------|----------|
|1 |1 | 101 |
|2 |1 | 102 |
|3 |1 | 103 |
|4 |2 | 101 |
| ... | ... | ... |
This structure allows you to associate specific courses with particular programs by referencing their
respective IDs in the junction table.
A junction table, also known as an association or linking table, is used to model many-to-many
relationships between two entities in a relational database. It contains foreign keys that reference the
primary keys of the entities involved in the relationship. The purpose of the junction table is to connect
records from both tables, establishing the many-to-many relationship.
Here's a general guide on how to create a junction table:
1. **Identify the Entities:**
- Determine the two entities between which you have a many-to-many relationship. For example,
professors and courses, or programs and courses.
2. **Create the Tables:**
- Create separate tables for each entity involved in the relationship. Define the primary key for each
table.
3. **Create the Junction Table:**
- Create a new table that will serve as the junction table. This table should contain foreign keys that
reference the primary keys of the two entities.
4. **Define Foreign Keys:**
- In the junction table, add foreign key columns that reference the primary keys of the entities
involved. These foreign keys establish the relationship.
5. **Populate the Junction Table:**
- Insert records into the junction table to represent the relationships between specific instances of the
two entities.
Here's an example using the previously discussed case of professors and courses:
```sql
-- Professor Table
CREATE TABLE Professor (
ProfessorID INT PRIMARY KEY,
FirstName VARCHAR(50),
LastName VARCHAR(50)
);
-- Course Table
CREATE TABLE Course (
CourseID INT PRIMARY KEY,
CourseName VARCHAR(50)
);
-- Junction Table
CREATE TABLE ProfessorCourse (

ProfessorCourseID INT PRIMARY KEY,
ProfessorID INT,
CourseID INT,
FOREIGN KEY (ProfessorID) REFERENCES Professor(ProfessorID),
FOREIGN KEY (CourseID) REFERENCES Course(CourseID)
);
-- Inserting data into the junction table
INSERT INTO ProfessorCourse (ProfessorID, CourseID) VALUES (1, 101);
-- ...
```
In this example, the `ProfessorCourse` table serves as the junction table connecting professors to
courses through their respective IDs. The foreign keys in `ProfessorCourse` reference the primary keys in
the `Professor` and `Course` tables.
To create a Student Schedule table that includes information about courses, professors, room numbers,
days of the week, and times, you can design a table like this:
```sql
-- Student Table
CREATE TABLE Student (
StudentID INT PRIMARY KEY,
);
-- Professor Table
);
-- Course Table
);
-- Room Table
CREATE TABLE Room (
RoomID INT PRIMARY KEY,
RoomNumber VARCHAR(10),
Building VARCHAR(50)
);
-- StudentSchedule Table
CREATE TABLE StudentSchedule (

ScheduleID INT PRIMARY KEY,
StudentID INT,
CourseID INT,
ProfessorID INT,
RoomID INT,
DayOfWeek VARCHAR(10),
StartTime TIME,
EndTime TIME,
FOREIGN KEY (StudentID) REFERENCES Student(StudentID),
FOREIGN KEY (CourseID) REFERENCES Course(CourseID),
FOREIGN KEY (RoomID) REFERENCES Room(RoomID)
);
-- Inserting data into the tables
INSERT INTO Student (StudentID, FirstName, LastName) VALUES (1, 'John', 'Doe');
INSERT INTO Professor (ProfessorID, FirstName, LastName) VALUES (1, 'Jane', 'Smith');
INSERT INTO Course (CourseID, CourseName) VALUES (101, 'Math');
INSERT INTO Room (RoomID, RoomNumber, Building) VALUES (1, 'A1', 'Building A');
-- Inserting a schedule record
INSERT INTO StudentSchedule (StudentID, CourseID, ProfessorID, RoomID, DayOfWeek, StartTime,

EndTime)
VALUES (1, 101, 1, 1, 'Monday', '09:00:00', '10:30:00');
```
In this example:
- The `StudentSchedule` table contains information about the student schedules, including foreign keys
referencing the `Student`, `Course`, `Professor`, and `Room` tables.
- `DayOfWeek` represents the day of the week (e.g., Monday, Tuesday).
- `StartTime` and ÈndTime` represent the time range for the scheduled class.
You can adjust the table structure based on your specific requirements and add more features or
constraints as needed.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
Certainly! Below is an example of a simplified database schema based on the tables you've mentioned:
```sql
-- Student Table
LastName VARCHAR(50),
ProgramID INT,
FOREIGN KEY (ProgramID) REFERENCES Program(ProgramID)
);
-- Professor Table
);
-- Program Table
CREATE TABLE Program (
ProgramID INT PRIMARY KEY,
ProgramName VARCHAR(50)
);
-- Course Table
);
-- Building Table
CREATE TABLE Building (
BuildingID INT PRIMARY KEY,

BuildingName VARCHAR(50)
);
-- Room Table
CREATE TABLE Room (
RoomID INT PRIMARY KEY,
RoomNumber VARCHAR(10),
BuildingID INT,
FOREIGN KEY (BuildingID) REFERENCES Building(BuildingID)
);
-- Year Table
CREATE TABLE Year (
YearID INT PRIMARY KEY,
YearName VARCHAR(10)
);
-- ProfessorCourse Table
CREATE TABLE ProfessorCourse (
ProfessorCourseID INT PRIMARY KEY,
ProfessorID INT,
CourseID INT,
);
-- ProgramCourse Table
CREATE TABLE ProgramCourse (
ProgramCourseID INT PRIMARY KEY,
ProgramID INT,
CourseID INT,
FOREIGN KEY (ProgramID) REFERENCES Program(ProgramID),
);
-- StudentSchedule Table
CREATE TABLE StudentSchedule (
StudentID INT,
CourseID INT,
ProfessorID INT,
RoomID INT,
YearID INT,
StartTime TIME,
EndTime TIME,
FOREIGN KEY (RoomID) REFERENCES Room(RoomID),

FOREIGN KEY (YearID) REFERENCES Year(YearID)
);
```
This schema includes tables for students, professors, programs, courses, buildings, rooms, years,
professor-course relationships, program-course relationships, and student schedules. Foreign keys are
used to establish relationships between these tables. Adjustments can be made based on your specific
requirements and constraints.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
Certainly! You can modify the Student table to include the section information, and create a Schedule
table to capture information about student schedules. Here's an example:
```sql
-- Student Table with Section
ProgramID INT,
Section VARCHAR(10), -- Adding the Section column
);
-- Schedule Table
CREATE TABLE Schedule (
StudentID INT,
CourseID INT,
ProfessorID INT,
RoomID INT,
StartTime TIME,
EndTime TIME,
Section VARCHAR(10), -- Adding the Section column
FOREIGN KEY (RoomID) REFERENCES Room(RoomID)
);
```
Now, when you insert data into the Schedule table, you can include the section information:
```sql
-- Inserting data into the Student table
INSERT INTO Student (StudentID, FirstName, LastName, ProgramID, Section)
VALUES (1, 'Rhea', 'Lastname1', 1, 'BSCS 4-1');

VALUES (2, 'Jen', 'Lastname2', 1, 'BSCS 4-1');
VALUES (3, 'Arkin', 'Lastname3', 1, 'BSCS 4-1');
VALUES (4, 'Luna', 'Lastname4', 2, 'BSIT 1-1');
VALUES (5, 'Yanna', 'Lastname5', 2, 'BSIT 1-1');
VALUES (6, 'Sevi', 'Lastname6', 2, 'BSIT 1-1');
-- Inserting data into the Schedule table
INSERT INTO Schedule (ScheduleID, StudentID, CourseID, ProfessorID, RoomID, DayOfWeek, StartTime,
EndTime, Section)
VALUES (1, 1, 101, 1, 1, 'Monday', '09:00:00', '10:30:00', 'BSCS 4-1');
EndTime, Section)
VALUES (2, 2, 102, 2, 2, 'Tuesday', '10:00:00', '11:30:00', 'BSCS 4-1');
EndTime, Section)
VALUES (3, 4, 201, 3, 3, 'Monday', '08:30:00', '10:00:00', 'BSIT 1-1');

-- ...
```
In this example, the `Section` column is added to the `Schedule` table to capture the section information
for each student's schedule. Adjustments can be made based on your specific requirements and
constraints.
To implement this logic in PHP code and ensure that students from the same section can have the same
schedule while students from different sections cannot, you'll need to perform checks before inserting
data into the database. Additionally, you should structure your database to include the necessary
constraints. Below is an example of how you can achieve this:
1. **Database Schema:**
```sql
-- Student Table with Section
ProgramID INT,
Section VARCHAR(10),
);
-- Schedule Table with Unique Constraint

CREATE TABLE Schedule (
StudentID INT,
CourseID INT,
ProfessorID INT,
RoomID INT,
StartTime TIME,
EndTime TIME,
Section VARCHAR(10),
FOREIGN KEY (RoomID) REFERENCES Room(RoomID),
UNIQUE (Section, DayOfWeek, StartTime, EndTime) -- Unique constraint on Section, Day, and Time
);
```
2. **PHP Code for Inserting Schedule:**
```php
<?php
// Assuming you have a database connection established
$studentID_Rhea = 1; // Replace with the actual Student IDs

$studentID_Jenny = 2;
$studentID_Ken = 3;
$section_BSCS = 'BSCS 4-1';
$section_BSIT = 'BSIT 4-1';
// Function to check if a schedule exists for a given section, day, and time
function isScheduleDuplicate($section, $dayOfWeek, $startTime, $endTime, $conn) {
$query = "SELECT COUNT(*) FROM Schedule WHERE Section = '$section' AND DayOfWeek =
'$dayOfWeek' AND StartTime = '$startTime' AND EndTime = '$endTime'";
$result = mysqli_query($conn, $query);
$count = mysqli_fetch_assoc($result)['COUNT(*)'];
return $count > 0;
// Example schedule insertions
$dayOfWeek = 'Monday';
$startTime = '09:00:00';
$endTime = '10:30:00';
if (!isScheduleDuplicate($section_BSCS, $dayOfWeek, $startTime, $endTime, $conn)) {
$query = "INSERT INTO Schedule (StudentID, CourseID, ProfessorID, RoomID, DayOfWeek, StartTime,
EndTime, Section)
VALUES ('$studentID_Rhea', '101', '1', '1', '$dayOfWeek', '$startTime', '$endTime',

'$section_BSCS')";
mysqli_query($conn, $query);
echo "Schedule for Rhea inserted successfully. ";

} else {
echo "Schedule for Rhea already exists. ";
if (!isScheduleDuplicate($section_BSCS, $dayOfWeek, $startTime, $endTime, $conn)) {
EndTime, Section)
VALUES ('$studentID_Jenny', '102', '2', '2', '$dayOfWeek', '$startTime', '$endTime',

'$section_BSCS')";
echo "Schedule for Jenny inserted successfully. ";
} else {
echo "Schedule for Jenny already exists. ";
if (!isScheduleDuplicate($section_BSIT, $dayOfWeek, $startTime, $endTime, $conn)) {
EndTime, Section)
VALUES ('$studentID_Ken', '103', '3', '3', '$dayOfWeek', '$startTime', '$endTime',

'$section_BSIT')";
echo "Schedule for Ken inserted successfully. ";
} else {
echo "Schedule for Ken already exists. ";
mysqli_close($conn);
?>
```
In this example:
- The ÙNIQUE (Section, DayOfWeek, StartTime, EndTime)` constraint in the `Schedule` table ensures
that schedules with the same section, day, and time cannot be duplicated.
- The ìsScheduleDuplicate` function is used to check if a schedule with the given parameters already
exists before insertion.
Note: This is a simplified example, and in a real-world application, you should consider using prepared
statements to prevent SQL injection and handle database errors more gracefully.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
This data schema represents a relational database design for managing information related to students,
professors, academic programs, courses, buildings, rooms, academic years, professor-course
relationships, program-course relationships, and student schedules. Here's an explanation of each table:
1. **Student Table:**
- Captures information about students, including a unique identifier (`StudentID`), first name
(`FirstName`), last name (`LastName`), and the program they are enrolled in (`ProgramID`).
2. **Professor Table:**
- Stores details about professors, including a unique identifier (`ProfessorID`), first name (`FirstName`),
and last name (`LastName`).
3. **Program Table:**
- Represents academic programs offered, with a unique identifier (`ProgramID`) and the program name
(`ProgramName`).
- Contains information about courses, with a unique identifier (`CourseID`) and the course name
(`CourseName`).
5. **Building Table:**
- Describes different buildings on a campus, with a unique identifier (`BuildingID`) and the building
name (`BuildingName`).
6. **Room Table:**
- Represents individual rooms within buildings, including a unique identifier (`RoomID`), room number
(`RoomNumber`), and the building to which the room belongs (`BuildingID`).
7. **Year Table:**
- Stores information about academic years, with a unique identifier (`YearID`) and the year name
(`YearName`).
8. **ProfessorCourse Table:**
- Establishes a many-to-many relationship between professors and courses, with a unique identifier
(`ProfessorCourseID`), professor identifier (`ProfessorID`), and course identifier (`CourseID`).
9. **ProgramCourse Table:**
- Establishes a many-to-many relationship between programs and courses, with a unique identifier
(`ProgramCourseID`), program identifier (`ProgramID`), and course identifier (`CourseID`).
10. **StudentSchedule Table:**
- Manages student schedules, with a unique identifier (`ScheduleID`), student identifier (`StudentID`),
course identifier (`CourseID`), professor identifier (`ProfessorID`), room identifier (`RoomID`), academic
year identifier (`YearID`), day of the week (`DayOfWeek`), start time (`StartTime`), and end time
(ÈndTime`). Foreign keys ensure referential integrity.
Overall, this schema provides a structured way to store and organize information related to an
educational institution, allowing for relationships between students, professors, programs, courses, and
schedules.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
To insert schedules from a schedule interface into the Professor and Student interfaces, you typically
need to follow these steps:
### 1. Collect Schedule Information:
From the schedule interface, gather the necessary information such as student details, course details,
professor details, room details, academic year, day of the week, start time, and end time.
### 2. Insert into StudentSchedule Table:
Use the collected information to insert a record into the `StudentSchedule` table.
```sql
INSERT INTO StudentSchedule (StudentID, CourseID, ProfessorID, RoomID, YearID, DayOfWeek,

StartTime, EndTime)
VALUES ('$studentID', '$courseID', '$professorID', '$roomID', '$yearID', '$dayOfWeek', '$startTime',

'$endTime');
```
### 3. Retrieve Professor and Student IDs:
After inserting into the `StudentSchedule` table, retrieve the generated `ScheduleID` and other relevant
details.
```sql
-- Example query to retrieve information from the inserted schedule
SELECT ScheduleID, StudentID, CourseID, ProfessorID, RoomID, YearID, DayOfWeek, StartTime, EndTime
FROM StudentSchedule
WHERE ScheduleID = LAST_INSERT_ID();
```
### 4. Insert into Professor and Student Interfaces:
Use the retrieved information to update or insert records in the Professor and Student interfaces.
#### For Professor Interface:
```sql
-- Example: Update Professor interface with the schedule information
UPDATE Professor
SET ScheduleID = '$scheduleID'
WHERE ProfessorID = '$professorID';
```
#### For Student Interface:
```sql
-- Example: Update Student interface with the schedule information
UPDATE Student
WHERE StudentID = '$studentID';
```
### 5. Handle Errors and Transactions:
Handle errors and ensure data consistency using transactions. If any part of the process fails, you can
roll back changes to maintain data integrity.
```sql
-- Example: Using transactions
START TRANSACTION;
-- Perform your insert/update operations
-- If everything is successful, commit the changes
COMMIT;
-- If an error occurs, roll back the changes
ROLLBACK;
```
### Important Note:
- Ensure that your PHP code or any other backend logic properly handles user input and guards against
SQL injection.
- Always use prepared statements or parameterized queries to protect against SQL injection attacks.
These are general steps, and the actual implementation might vary based on your specific application
structure and requirements.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
To pass schedule information from a schedule interface to different users in the professor and student
interfaces, you typically need to follow these steps:
### 1. Collect Schedule Information:

From the schedule interface, gather the necessary information such as student details, course details,
professor details, room details, academic year, day of the week, start time, and end time.
### 2. Insert into StudentSchedule Table:
Use the collected information to insert a record into the `StudentSchedule` table.
```sql
INSERT INTO StudentSchedule (StudentID, CourseID, ProfessorID, RoomID, YearID, DayOfWeek,

StartTime, EndTime)
VALUES ('$studentID', '$courseID', '$professorID', '$roomID', '$yearID', '$dayOfWeek', '$startTime',

'$endTime');
```
### 3. Retrieve ScheduleID:
After inserting into the `StudentSchedule` table, retrieve the generated `ScheduleID` and other relevant
details.
```sql
-- Example query to retrieve information from the inserted schedule
SELECT ScheduleID, StudentID, CourseID, ProfessorID, RoomID, YearID, DayOfWeek, StartTime, EndTime
FROM StudentSchedule
WHERE ScheduleID = LAST_INSERT_ID();
```
### 4. Insert into Professor and Student Interfaces:

Use the retrieved information to update or insert records in the Professor and Student interfaces.
#### For Professor Interface:
```sql
-- Example: Update Professor interface with the schedule information
UPDATE Professor
WHERE ProfessorID = '$professorID';
```
#### For Student Interface:
```sql
-- Example: Update Student interface with the schedule information
UPDATE Student
WHERE StudentID = '$studentID';
```
### 5. Handle Errors and Transactions:
Handle errors and ensure data consistency using transactions. If any part of the process fails, you can
roll back changes to maintain data integrity.
```sql
-- Example: Using transactions
START TRANSACTION;
-- Perform your insert/update operations
-- If everything is successful, commit the changes
COMMIT;
-- If an error occurs, roll back the changes
ROLLBACK;
```
### 6. Notify Users:
If you need to notify users about the new schedule, you can use additional mechanisms such as email
notifications, real-time messaging, or push notifications, depending on your application architecture.
### Important Note:
- Ensure that your PHP code or any other backend logic properly handles user input and guards against
SQL injection.
- Always use prepared statements or parameterized queries to protect against SQL injection attacks.
These are general steps, and the actual implementation might vary based on your specific application
structure and requirements. Additionally, consider adding error handling and enhancing security
measures based on your application's needs.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////

Courses Table-WPS Office

Uploaded by

Copyright:

Available Formats

You might also like

Courses Table-WPS Office

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Courses Table-WPS Office

Uploaded by

Copyright:

Available Formats

### Courses Table:

CourseID (Primary Key)

ProgramID (Foreign Key referencing Programs Table)

YearID (Foreign Key referencing Years Table)

Other relevant fields (e.g., course details)

### Professor Table:

ProfessorID (Primary Key)

Other relevant fields (e.g., contact information)

### Building/Room Table:

RoomID (Primary Key)

Other relevant fields (e.g., facilities)

### Professor Table:

ProfessorID (Primary Key)

Other relevant fields (e.g., contact information)

### Course Table:

CourseID (Primary Key)

ProgramID (Foreign Key referencing Programs Table)

YearID (Foreign Key referencing Years Table)

Other relevant fields (e.g., course details)

### ProfessorCourse Table (Junction Table):

ProfessorCourseID (Primary Key)

ProfessorID (Foreign Key referencing Professors Table)

CourseID (Foreign Key referencing Courses Table)

### Programs Table:

ProgramID (Primary Key)

Other relevant fields

### Students Table:

StudentID (Primary Key)

ProgramID (Foreign Key referencing Programs Table)

YearID (Foreign Key referencing Years Table)

Other relevant fields (e.g., contact information)

### Building Table:

BuildingID (Primary Key)

Other relevant fields (e.g., location)

RoomID (Primary Key)

BuildingID (Foreign Key referencing Buildings Table)

Other relevant fields (e.g., room details)

### Schedule Table:

ScheduleID (Primary Key)

CourseID (Foreign Key referencing Courses Table)

RoomID (Foreign Key referencing Rooms Table)

ProfessorID (Foreign Key referencing Professors Table)

Other relevant fields (e.g., semester, class type)

### Students Table:

StudentID (Primary Key)

ProgramID (Foreign Key referencing Programs Table)

YearID (Foreign Key referencing Years Table)

Other relevant fields (e.g., contact information)

- BuildingID (Primary Key)

- RoomID (Primary Key)

- BuildingID (Foreign Key referencing Building)

- RoomNumber uniquely identifies each room.

| ... | ... | ... |

- ProfessorID (Primary Key)

- CourseID (Primary Key)

3. **ProfessorCourse Table (Junction Table):**

- ProfessorCourseID (Primary Key)

- ProfessorID (Foreign Key referencing Professor)

3. ProfessorCourse Table (Junction Table):

3. ProgramCourse Table (Junction Table):

1. Identify the Entities:

2. Create the Tables:

3. Create the Junction Table:

5. Populate the Junction Table: