Problem
Which is correct when join section table with class table OR with course table OR with instructor Table .
Details
section is group of student classified to ( aa,bb,cc )can take one course or more courses.
section can teach in one or more class(lab or class room) .
Instructor can teach to more sections and section can have more instructor
raltion is many to many and made in third table Inst_Course
My ER diagram as following :
section table join
Database Schema as following :
CREATE TABLE [dbo].[Instructor](
[InstructorID] [int] NOT NULL,
[InstructorName] [nvarchar](50) NULL,
CONSTRAINT [PK_Instructor] PRIMARY KEY CLUSTERED
(
[InstructorID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [dbo].[Course](
[CourseID] [int] NOT NULL,
[CourseName] [nvarchar](50) NULL,
CONSTRAINT [PK_Course] PRIMARY KEY CLUSTERED
(
[CourseID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [dbo].[Class](
[ClassID] [int] NOT NULL,
[ClassName] [nvarchar](50) NULL,
CONSTRAINT [PK_Class] PRIMARY KEY CLUSTERED
(
[ClassID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [dbo].[Section](
[SectionID] [int] NOT NULL,
[SectionName] [nvarchar](50) NULL,
CONSTRAINT [PK_Section] PRIMARY KEY CLUSTERED
(
[SectionID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [dbo].[Inst_Course](
[InstID] [int] NOT NULL,
[CourseID] [int] NOT NULL,
CONSTRAINT [PK_Inst_Course] PRIMARY KEY CLUSTERED
(
[InstID] ASC,
[CourseID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
CREATE TABLE [dbo].[Course_Class](
[ClassID] [int] NOT NULL,
[CourseID] [int] NOT NULL,
[Fromtime] [int] NULL,
[Totime] [int] NULL,
[day] [nvarchar](50) NULL,
CONSTRAINT [PK_Course_Class] PRIMARY KEY CLUSTERED
(
[ClassID] ASC,
[CourseID] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
Relation between tables as following :
Class table and courses table has many to many relation ship in tableCourse_Class .
Instructor table and courses table has relation many to many in table
Inst_Course .
Section is have many to many with instructor table and course table and class table
which is correct for join section with instructor or course or class
Notes :this diagram not have student courses table because the goal from diagram is design schedule for instructor .
sample data
Sample data to table Course_Class for instructor schedule
join between tables as following :
SELECT dbo.Class.ClassName, dbo.Course_Class.CourseID, dbo.Course_Class.Fromtime, dbo.Course_Class.Totime, dbo.Course_Class.day, dbo.Course.CourseName,
dbo.Inst_Course.InstID, dbo.Inst_Course.CourseID AS Expr3, dbo.Instructor.InstructorID, dbo.Instructor.InstructorName
FROM dbo.Class INNER JOIN
dbo.Course_Class ON dbo.Class.ClassID = dbo.Course_Class.ClassID INNER JOIN
dbo.Course ON dbo.Course_Class.CourseID = dbo.Course.CourseID INNER JOIN
dbo.Inst_Course ON dbo.Course.CourseID = dbo.Inst_Course.CourseID INNER JOIN
dbo.Instructor ON dbo.Inst_Course.InstID = dbo.Instructor.InstructorID
WHERE (dbo.Inst_Course.InstID = 1)
Question is :Actually what i need is which table must join with section table class or course or instructor tables
Update
Class in my case represent classroom or lab meaning class is the place teach courses in it
Section :(group of student)represent who teaches .
I can take course c# in class 1 meaning lab 1 or lab 2 or lab 3
and in lab1 i can get course c# OR c++ OR java in my case .
Here i treat with section to represent group of students .
section can teach more courses c# and c++ and java .
c# course can have more section aa,bb,cc .
Update2
student participate in one section only and cannot more section meaning relation one to many .
relation between section and class is many to many because section aa can take course c# in class a and class bb
and class bb can have course c# and c++
if you mean by session is course you are right .
Courses teaches in more classes in different times from 9-11,11-1,1-3,3-4.30
in different classes .
courses include more sections and every section can have more course
OK, updated based upon your update, I'd suggest you have the following structures:
create table dbo.Instructors (
InstructorID int identity(1,1) not null ,
constraint pkc_Instructors
primary key clustered ( InstructorID ) ,
InstructorName nvarchar(48) not null ,
constraint uni_InstructorName#Instructors
unique nonclustered ( InstructorName )
)
create table dbo.Courses (
CourseID int identity(1,1) not null ,
constraint pkc_Courses
primary key clustered ( CourseID ) ,
CourseName nvarchar(48) not null ,
constraint uni_CourseName#Courses
unique nonclustered ( CourseName )
)
create table dbo.ClassRooms (
ClassRoomID int identity(1,1) not null ,
constraint pkc_ClassRooms
primary key clustered ( ClassRoomID ) ,
ClassRoomName nvarchar(48) not null ,
constraint uni_ClassRoomName#ClassRooms
unique nonclustered ( ClassRoomName )
)
create table dbo.Sections (
SectionID int identity(1,1) not null ,
constraint pkc_Sections
primary key clustered ( SectionID ) ,
CourseID int not null ,
constraint fk_CourseID#Sections
foreign key ( CourseID )
references dbo.Courses ( CourseID ) ,
SectionName nvarchar(48) not null ,
constraint uni_SectionName#Sections
unique nonclustered ( SectionName )
)
create table dbo.StudentSections (
StudentSectionID int identity(1,1) not null ,
constraint pkn_StudentSections
primary key nonclustered ( StudentSectionID ) ,
StudentID int not null ,
constraint fk_StudentID#StudentSections
foreign key ( StudentID )
references dbo.Students ( StudentID ) ,
SectionID int not null ,
constraint fk_SectionID#StudentSections
foreign key ( SectionID )
references dbo.Sections ( SectionID ) ,
constraint uci_StudentID_SectionID#StudentSections
unique clustered ( StudentID , SectionID )
)
create table dbo.SectionClassRooms (
SectionClassRoomID int identity(1,1) not null ,
constraint pkn_SectionClassRooms
primary key nonclustered ( SectionClassRoomID ) ,
SectionID int not null ,
constraint fk_SectionID#SectionClassRooms
foreign key ( SectionID )
references dbo.Sections ( SectionID ) ,
ClassRoomID int not null ,
constraint fk_ClassRoomID#SectionClassRooms
foreign key ( ClassRoomID )
references dbo.ClassRooms ( ClassRoomID ) ,
constraint uci_SectionID_ClassRoomID#SectionClassRooms
unique clustered ( SectionID , ClassRoomID )
)
create table dbo.InstructorSections (
InstructorSectionID int identity(1,1) not null ,
constraint pkn_InstructorSections
primary key nonclustered ( InstructorSectionID ) ,
InstructorID int not null ,
constraint fk_InstructorID#InstructorSections
foreign key ( InstructorID )
references dbo.Instructors ( InstructorID ) ,
SectionID int not null ,
constraint fk_SectionID#InstructorSections
foreign key ( SectionID )
references dbo.Sections ( SectionID ) ,
constraint uci_InstructorID_SectionID#InstructorSections
unique clustered ( InstructorID , SectionID )
)
What this says:
Instructors are their own entities, with each instructor having a unique name.
Courses are similar, with uniqueness on their name.
ClassRooms, ditto.
Sections must be a section of a Course and cannot exist in isolation.
Students participate in one or more Sections.
Sections may take place in one or more ClassRooms (if this is not true, then we need to make ClassRoomID an attribute of each Section, rather than putting this in its own table SectionClassRooms).
An Instructor may teach many Sessions and also a Session may be taught by multiple Instructors (if this is not the case, then InstructorID should be an attribute of Sessions).
Obviously, you're going to have a few more fields in some of these, as needed. For example: when do the Sessions take place? Does a Session have the same time regardless of the classroom in which it takes place? There are nuances here, I'm sure.
Lastly, I'd encourage you to review the clustered vs nonclustered indexing, as this should be optimized for how your information will be retrieved. Not critical, but I made a stab at how I thought it should work, not knowing your application requirements.
I'll modify this again if needed.
This design seems to arise from the relationship/table in this question you recently asked. (Unfortunately both questions are extremely unclear.) From my answer:
Probably you want a table telling you the same thing as all reports for all instructors: instructorIteaches courseCin classroomCRto sectionSfor departmentDin timeslotTSon weekdayWD.
I told you you should learn normalization:
By identifying all FDs (functional dependencies) we determine all CKs (candidate keys). Then normalization uses these to possibly suggest "better" choices for base tables.
In that question and in this question it is not possible to express the big table as a join of smaller tables.
A prerequisite for decomposing a table into smaller ones, ie for joining smaller ones to get it, is that the statement that a row makes when it is in the big table can be expressed as the AND of the statements of the smaller tables.
Apparently Course_Class holds rows that make a true statement from course COURSEID is taught in classroom CLASSID from FROMTIME to TOTIME on day WEEKDAY. Apparently Inst_Course holds rows that make a true statement from instructor INSTID teaches course COURSEID.
Maybe you want the rows where instructor INSTID teaches course COURSEID in classroom CLASSID from FROMTIME to TOTIME on day WEEKDAY. If every instructor that teaches a course teaches every lecture of it then you can join Course_Class and Inst_Course to get this. That seems very unlikely. So more likely, this cannot be rephrased using the AND of smaller statements. So you can't get this table from joining smaller tables.
Maybe you want the rows where instructor INSTID teaches section SECTIONID of course COURSEID in classroom CLASSID from FROMTIME to TOTIME on day WEEKDAY. Then, similarly, adding a Course_Section table for course COURSEID has section SECTIONID is no help unless also every section of a course is taught in every lecture for it.
The information in the separate tables just doesn't collectively tell you what that big tables do. (Although it happens that here the smaller tables can be probably be generated from the big tables.)
You need to learn about (FKs & CKs &) normalization, which replaces big tables by smaller ones that join back to them.
Related
Is a compound index sufficient for queries against a subset of columns ?
CREATE TABLE [FILE_STATUS_HISTORY]
(
[FILE_ID] [INT] NOT NULL,
[STATUS_ID] [INT] NOT NULL,
[TIMESTAMP_UTC] [DATETIME] NOT NULL,
CONSTRAINT [PK_FILE_STATUS_HISTORY]
PRIMARY KEY CLUSTERED ([FILE_ID] ASC, [STATUS_ID] ASC)
) ON [PRIMARY]
CREATE UNIQUE NONCLUSTERED INDEX [IX_FILE_STATUS_HISTORY]
ON [FILE_STATUS_HISTORY] ([FILE_ID] ASC,
[STATUS_ID] ASC,
[TIMESTAMP_UTC] ASC) ON [PRIMARY]
GO
SELECT TOP (1) *
FROM [FILE_STATUS_HISTORY]
WHERE [FILE_ID] = 382748
ORDER BY [TIMESTAMP_UTC] DESC
A composite index on ( File_Id, Timestamp_UTC desc ) should optimize handling the where and top/order by clauses. The actual execution plan will show whether the query optimizer agrees.
A covering index would also have Status_Id as an included column so that the index could satisfy the entire query in a single lookup.
Consider the following table...
CREATE TABLE [dbo].[Alerts]
(
[Id] [int] IDENTITY(1,1) NOT NULL,
[I18NMessageKey] [uniqueidentifier] NOT NULL
PRIMARY KEY CLUSTERED ([Id] ASC)
) ON [PRIMARY]
GO
and the following table...
CREATE TABLE [dbo].[I18NMessages]
(
[Id] [int] IDENTITY(1,1) NOT NULL,
[Key] [uniqueidentifier] NOT NULL,
[Culture] [nvarchar](200) NOT NULL,
[Message] [nvarchar](max) NOT NULL,
PRIMARY KEY CLUSTERED ([Id] ASC)
) ON [PRIMARY]
GO
I would like to add a foreign key constraint to table [Alerts] on the column [I18NMessageKey] to refer to many records in table [I18NMessages].
Is this possible without a third table?
The [I18NMessages] table holds the same message for the [Key] but in different languages depending on [Culture]. The relationship between [Alerts] and [I18NMessages] doesn't care about the culture. The resolution of [Culture] depends on the user at runtime.
In SQL Server, the uniqueness of the referenced key column(s) must be enforced by a primary key, unique constraint, or unique index. You need a third table with a unique I18NMessageKey column key to enforce referential integrity.
You can create a trigger and implement custom business logic
I am a beginner in Oracle databases.
I have a relational diagram and I want to create tables in Oracle, but I don't know how to make the relationships between them and the primary key at each. My teacher say that the tables "patients" and "doctors" have to inherit all the attributes from "Persons" table.
Also, the "prescription" table needs to inherit the attributes from "patients" and "doctors" table. So on with the "prescription" table.
This is the diagram
Everything you need you can find on this page: official oracle docs
Basic syntax of creating simple tables and inheritance of attributes in section "Parallelizing Table Creation".
CREATE TABLE empleat(
emp_no number(6,0) CONSTRAINT fk_empleat PRIMARY KEY,
nom varchar(20) CONSTRAINT nn_empleat_nom NOT NULL,
cognom varchar(20),
departament number(2,0) CONSTRAINT nn_empleat_dept NOT NULL
);
CREATE TABLE departament(
dept_no number(2,0) CONSTRAINT fk_departament_dept_no PRIMARY KEY,
nom varchar(20) CONSTRAINT nn_departament_nom NOT NULL,
localitat varchar2(30),
lider number(6,0) CONSTRAINT nn_departament NOT NULL
);
Not sure why a doctor wouldn't have a date of birth or a gender so you could just merge the people and patients tables
CREATE TABLE people (
id NUMBER CONSTRAINT people__id__pk PRIMARY KEY,
first_name VARCHAR2(250) CONSTRAINT people__first_name__nn NOT NULL,
last_name VARCHAR2(250) CONSTRAINT people__last_name__nn NOT NULL,
phone VARCHAR2(20),
date_of_birth DATE CONSTRAINT people__date_of_birth__nn NOT NULL,
gender CHAR(1) CONSTRAINT people__gender__chk CHECK ( gender IN ( 'M', 'F', 'X', 'Y' ) ),
doctor NUMBER CONSTRAINT people__doctor__fk REFERENCES doctor ( id )
);
CREATE TABLE doctor (
id NUMBER CONSTRAINT doctor__id__pk PRIMARY KEY
CONSTRAINT doctor__id__fk REFERENCES people ( id ),
specialization VARCHAR2(250)
);
My teacher say that the tables "patients" and "doctors" have to inherit all the attributes from "Persons" table.
If by this, they mean that the doctors table has to have all the columns of the people table then this breaks the idea of normalisation. If you are required to do this then it should be implemented as a VIEW rather than duplicating the data.
CREATE VIEW doctor_details IS
SELECT p.*, d.sepcialization
FROM people p
INNER JOIN
doctors d
ON ( p.id = d.id );
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]
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.
Having read many blogs, I have decided to create tables that have a guid/UNIQUEIDENTIFIER as primary key, however using a non clustered index and a bigint as clustered key.
First of all what would be the correct DDL syntax in this scenario. Also, I would think that using the bigints as foreign keys would be the correct choice. Is this correct?
Here is a starter for ten:
IF OBJECT_ID('dbo.Table1', 'U') IS NOT NULL
DROP TABLE dbo.Table1;
CREATE TABLE dbo.Table1
(
[Table1Id] [BIGINT] IDENTITY(1,1) NOT NULL,
[Table1Guid] [UNIQUEIDENTIFIER] NOT NULL,
[PayLoad] NVARCHAR(200) NULL
PRIMARY KEY CLUSTERED
(
[Table1Id] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)
CREATE NONCLUSTERED INDEX IX_Table1_Table1Guid
ON dbo.Table1 (Table1Guid);
GO
Actually when you create table by default primary key is created as clustered index. But you can create nonclustered primary key and add clustered index on another column. The syntax would be:
CREATE TABLE [dbo].[Table1](
[Table1Id] [BIGINT] IDENTITY(1,1) NOT NULL,
[Guid] [UNIQUEIDENTIFIER] NOT NULL,
[PayLoad] NVARCHAR(200) NULL
)
GO
ALTER TABLE [dbo].[Table1] ADD CONSTRAINT [PK_Table1] PRIMARY KEY NONCLUSTERED ([Guid])
GO
CREATE UNIQUE CLUSTERED INDEX IX_Table1_Table1Id ON dbo.Table1 (Table1Id)
GO
Now about the primary key on guid column. It is usually a bad idea to have guid primary key because of space required.
Taken from Exam 70-461: Querying Microsoft SQL Server 2012:
The storage requirements for your surrogate key can have a cascading
effect if your clustered index is defined on the same key columns
(the default for a primary key constraint). The clustered index key
columns are used by all nonclustered indexes internally as the means
to locate rows in the table. So if you define a clustered index on a
column x, and nonclustered indexes—one on column a, one on b, and one
on c—your nonclustered indexes are internally created on column (a,
x), (b, x), and (c, x), respectively.
Unless you really need such a PK(for example in distributed systems, when you need uniqueneess across several systems) I would not recommend to use guids as PK, at least in operational tables.