How can I make a schedule table for instructor from tables created

Question

Problem

I need to make scheduale for instructor in training center.

I created tables but relation I cannot do.

What relation do I make between instructor_course table class table and section table? (Must I have a foreign key from table class and table section? Must I add ClassID FK from table class And SectionID from table section to table Inst_Courses Table?)

Table details

I need to show schedule for instructor courses within week from Sunday to Thursday.

E.g. In Sunday from 2 - 4 clock Instructor Michel give C# Course in ClassRoom A Section B

So I created following tables :

Courses (like c#,access,SQL)
Instructor(Teacher)
Int_Courses
Class( Lab or class room)
Section(group of student take courses classified to a,b,c,c2)

I already made relations between Instructor table and Courses table many to many in third table Inst_Courses table.

Result expected

Database Schema

CREATE TABLE [dbo].[Courses](
    [CourseID] [int] IDENTITY(1,1) NOT NULL,
    [CourseName] [nvarchar](50) NOT NULL,
 CONSTRAINT [PK_dbo.Courses] PRIMARY KEY CLUSTERED 
(
    [CourseID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

CREATE TABLE [dbo].[Class](
    [ClassID] [int] IDENTITY(1,1) NOT NULL,
    [ClassName] [nvarchar](50) NOT NULL,
 CONSTRAINT [PK_dbo.Class] PRIMARY KEY CLUSTERED 
(
    [ClassID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

CREATE TABLE [dbo].[Instructor](
    [InstructorID] [int] IDENTITY(1,1) NOT NULL,
    [IstructorName] [nvarchar](50) NOT NULL,
 CONSTRAINT [PK_dbo.Instructor] PRIMARY KEY CLUSTERED 
(
    [InstructorID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

CREATE TABLE [dbo].[InstructorCourses](
    [CourseID] [int] NOT NULL,
    [InstructorID] [int] NOT NULL,
 CONSTRAINT [PK_dbo.InstructorCourses] PRIMARY KEY CLUSTERED 
(
    [CourseID] ASC,
    [InstructorID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

CREATE TABLE [dbo].[Section](
    [SecID] [int] IDENTITY(1,1) NOT NULL,
    [SecName] [nvarchar](50) NOT NULL,
    [Active] [bit] NOT NULL,
 CONSTRAINT [PK_dbo.Section] PRIMARY KEY CLUSTERED 
(
    [SecID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

CREATE TABLE [dbo].[Instructor_Class](
    [ClassID] [int] NOT NULL,
    [InstructorID] [int] NOT NULL,
 CONSTRAINT [PK_dbo.Instructor_Class] PRIMARY KEY CLUSTERED 
(
    [ClassID] ASC,
    [InstructorID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

Answer 1

A table for this report

This report only works if 'Michel' identifies one instructor. Otherwise either you need multiple sub-reports for one weekday-timeslot intersection or you need multiple reports.

Each non-blank sub-report at a row and column of your report tells you: instructor Michel teaches courseCin classroomCRto sectionSfor departmentD.

So the report tells you the same thing overall as a table holding the rows where: instructor Michel teaches courseCin classroomCRto sectionSfor departmentDin timeslotTSon weekdayWD. Notice how we take each column and row of a multi-dimensional report like this and add a column for it to the table for each multi-dimensional sub-report where they intersect.

Probably you want a table telling you the same thing as all reports for all instructors: instructorIteaches courseCin classroomCRto sectionSfor departmentDin timeslotTSon weekdayWD. Notice how we take a parameter in the title and add a column for it to the table.

(Now we don't need to worry about whether Michel identifies one instructor.)

A first design for this report

Instructor names are probably non-unique or non-permanent. So add ids to names and report titles. You probably have more data about instructors, courses and departments. So have tables for them. Apparently a section number is only unique within a course.

-- instructor ID is named NAME and ...
Instructor(id, name, ...)
    CK(id)
-- course NAME ...
Course(name, ...)
    CK (name)
-- department NAME ...
Department(name, ...)
    CK (name)
-- course C_NAME has section S_NUMBER
Course_Has_Section(C_name, S_number)
    CK (C_name, S_number)
    FK(C_name) to Course
-- instructor I_id teaches course C_NAME in classroom CR_NAME to section S_NUMBER 
--     for department D_NAME in timeslot TS_NAME on weekday WD_NAME
Weekly_Lecture(I_id, C_name, CR_name, S_number, D_name, TS_name, WD_name)
    FK(I_id) to Instructor
    FK(C_name, S_number) to Course_Has_Section
    FK(D_name) to Department

Your design details will differ. Maybe courses and/or departments have unique codes. Then you might use them as FKs. Then add a table. Apparently a section can be active, whatever that means.

CKs and Normalizing

A given instructor, timeslot & weekday can only have one weekly lecture. But no smaller subset of those does. So we have Weekly_Lecture CK(I_id, TS_name, WD_name). A given course, section, timeslot & weekday can only have one weekly lecture. But no smaller subset of those does. So we have Weekly_Lecture CK(C_name, S_number, TS_name, WD_name). A given classroom, timeslot & weekday can only have one weekly lecture. But no smaller subset of those does. So we have Weekly_Lecture CK(CR_name, TS_name, WD_name).

Maybe a given course can only be taught for one department? Maybe a given section number can only be taught by a given instructor? By identifying all FDs (functional dependencies) we determine all CKs (candidate keys). Then normalization uses these to possibly suggest "better" choices for base tables.