I have three tables:
student
id (pk)
name
course
id (pk)
course_name
course_duration
course_fee
student_course
student_course_id (pk)
student_id (fk)
course_id (fk)
If after a certain period of time course fee changes then how can I maintain the record of student having previous course fee?
Logically you copy it into the enrolments table (student_course). This supposes that the price will not change after the registration.
Related
Wondering if you think the following table for storing employees in a database would be consider a database in BCNF ?
- Employee Table
Employee_ID (Primary Key, unique)
First_Name
Surname
Religion
Sex
Job Title
Nationality
- Employee_Address Table
Employee_ID (Foreign Key)
Line_One_Address
Line_Two_Address
District
Country
- Employee_Conact Table
Employee_ID (Foreign Key)
Mobile_Number
So my question is do you think this will meet the critria for being in BCNF ? Or should I have a Nationaility table, Job Title Table, Religion table etc. as they will be duplicate information in the db for it
I am just new to the learning normilzation, so any thoughts and tips will be helpful
i would suggest renaming the EMPLOYEE table to PERSON
then you will notice that job title does not belong with the person definiton- so at least that one should be in another table - like a linking table between people and organizations - where you would put the title and hire date etc.
I have 2 tables I plan on creating, Employee and Student. Employee and Student tables have some common fields and also some different ones. Is it a good idea to put those same fields in a common table like Person and then relate them?
For example, both Employee and Student have FirstName and LastName fields.
PersonType
personTypeID (1 ,2 )
personTypeName (student,employee )
Person
PersonID
PersonType (foreignKey From PersonType)
PersonName
PersonSurname
Employee
EmployeeID (ForeignKey from Person table and also primaryKey of this table, since all employees are person or you can make a unqiue empID for this table and make a column like fkPersonID which must be unique fot this table as well)
EmployeeDepID (fk from departmens)
Budget
and so on
Students
Exactly same approach as Employee table.
Since you didn't mentioan about for a student which might be an employee or vice versa i didn't consider this situation. Assuming that a student might be an employee as well just create a column in students table which is fkEmpID from employee table. But in this situation if you create fkPersonID in both employee and student table you have to guarantee these two columns matches. To provide in your student table get both (fkPersonID, fkEmpID) and match them (fkPersonID,fkEmpID) this is called multi-column foreign keys.
I'm designing a database for school. So far I have the following tables:
course: topic: level leveltopic_junc: student:
courseID (PK) topicID (PK) levelID (PK) levelID (fK) studentID
date topicname levelname topicID (fK) studentname
level(fK)
coursestudent_junc:
courseID (fK)
studentID(fK)
topicID (fK)
mark
Now I'm at a dead point.
What I need is: every student, at the end of the course pass an exam and gets a mark for every topic of the course and a final mark that is the average of the previuos marks.
Also, the leveltopic_junc can change: for instance, for this year topic1 can be in level1, but next year topic1 could be in level2. This shouldn't change topics assigned to the EDIT:courses for previous years. If courseID:564 (level1) this year has topic1, when next year I will modify the leveltopic_junc table, courseID:564 should maintain topic1, even if now level1 it's not anymore in level1. So the leveltopic_junc table it's just a reference table so that (later, when writing php) I can populate the coursestudent_junc table with topics, without have to manually search or write topics.
Would be better to break the coursestudent_junc in two tables (or this will break the one of normalization rules?)
coursetopic_junc: mark:
courseID (fK) courseID (fK)
topicID (fK) studentID (fK)
topicID (fK)
mark
What is the best database design in this scenario?
Hope I was clear, it isn't to easy to explain in words :)!
Thanks!!
I have a database with 5 millions records,
i have Person table having 5 million records and its have 13 columns.
Forename and surname column is heavily populated as compared to other columns.
My question is it appropriate to separate forename and surname tables with relevant ID’s. Will it reduced the load on database or What would be the benefits/disadvantages of this approach?
Structure of my table(HCP) is
HCP-ID (PK)
Title-ID (FK)
Surname
Forename
Forename-Initial
Specialty-Code
Specialty
Gender
Eligibility-ID (FK)
Loyalty-ID (FK)
Designation-ID (FK)
HCP-Language-ID
Source-ID (FK)
Updated-By-Staff-ID (linked to User-ID) (FK)
Update-Date
Stored-Payment-Details (y/n)
Contact-Mobile-Number-ID
I have some experience of working with Healthcare Providers database and looking at this table I think you can do the following.
Main HCP Table
HCP-ID (PK)
Title-ID (FK) --<-- every HCP will have a title
Surname --<-- every HCP will have a Surname
Forename --<-- every HCP will have a Forname
Forename-Initial --<-- You dont need this column as you have this info stored in
-- Forename column all you need to do is use LEFT(Forename, 1)
Specialty-Code --<-- One HCP could be responsible for multiple Specialities therefore
-- I would move this column to another table.
Gender --<-- Keep this Every HCP will have some Gender
HCP-Language-ID --<-- Every HCP will have a Language ID (Mother Tongue )
Updated-By-Staff-ID --<-- required to Audit Table who has updated the record.
Update-Date --<-- required to Audit Table when was the record updated.
Now for the rest of the columns you can put them In a separate table and Reference records back to your main table using a FK or put them in multiple separate table and use Fks.
HCP Details
Eligibility-ID (FK)
Loyalty-ID (FK)
Designation-ID (FK)
Source-ID (FK)
Stored-Payment-Details (y/n)
Update-Date
Updated-By-Staff-ID
Contact-Mobile-Number-ID
Specialty --<-- When you have Specialty-Code why store Specialty Name ???
-- use JOIN to retrieve the info when ever needed.
I need to create an ER where users can add and delete their personal contacts.
Contacts can be any person including other users.
Users can also check who of the other users have added them to their contact list.
I don't know how to start. Can someone please help me draw this ER?
Person
PersonID (PK)
OtherUserInfo...
Contact
PersonId (FK to UserID)
contactId (FK to ContactID) Composite PK these 2 together.
PersonProfile
PersonID (FK to userID)
PersonCategoryID (FK to UserCategoryID) Composite PK these 2 together.
PersonCategory
personCategoryID (PK)
PersonCategory (User, Contact etc) depending on if a user can be a contact or just a contact or just a user.
when a user adds a contact the entry is put in Person table and an associated record is in personProfile with a personcategoryID for contact and the contact is linked to the person putting in the etnry via contact table
If a person is added as a contact from the other users, (found by joining person to personprofile where personcategory links to "user" entry, then an entry is saved in contact with the personId doing the seach and the personid of the contact they just added.
if a person is removed from personporfile as a contact, all entries in contact table for that contactId are removed as that person is no longer a valid contact. (assuming history isn't needed)
Just my thoughts... there's lots of ways to skin this cat based on additional requirements, desired growth etc.