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!!
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'm creating a clinic management system where I need to store Medical History for a patient. The user can select multiple history conditions for a single patient, however, each clinic has its own fixed set of Medical History fields.
For example:
Clinic 1:
DiseaseOne
DiseaseTwo
DiseaseThree
Clinic 2:
DiseaseFour
DiseaseFive
DiseaseSize
For my Patient visit in a specific Clinic , the user should be able to check 1 or more Diseases for the patient's medical history based on the clinic type.
I thought of two ways of storing the Medical History data:
First Option:
Add the fields to the corresponding clinic Patient Visit Record:
PatientClinic1VisitRecord:
PatientClinic1VisitRecordId
VisitDate
MedHist_DiseaseOne
MedHist_DiseaseTwo
MedHist_DisearThree
And fill up each MedHist field with the value "True/False" based on the user input.
Second Option:
Have a single MedicalHistory Table that holds all Clinics Medical History detail as well as another table to hold the Patient's medical history in its corresponding visit.
MedicalHistory
ClinicId
MedicalHistoryFieldId
MedicalHistoryFieldName
MedicalHistoryPatientClinicVisit
VisitId
MedicalHistoryFieldId
MedicalHistoryFieldValue
I'm not sure if these approaches are good practices, is a third approach that could be better to use ?
If you only interested on the diseases the person had, then storing the false / non-existing diseases is quite pointless. Not really knowing all the details doesn't help getting the best solution, but I would probably create something like this:
Person:
PersonID
Name
Address
Clinic:
ClinicID
Name
Address
Disease:
DiseaseID
Name
MedicalHistory:
HistoryID (identity, primary key)
PersonID
ClinicID
VisitDate (either date or datetime2 field depending what you need)
DiseaseID
Details, Notes etc
I created this table because my assumption was that people have most likely only 1 disease on 1 visit, so in case there's sometimes several, more rows can be added, instead of creating separate table for the visit, which makes queries most complex.
If you need to track also situation where a disease was checked but result was negative, then new status field is needed for the history table.
If you need to limit which diseases can be entered by which clinic, you'll need separate table for that too.
Create a set of relational tables to get a robust and flexible system, enabling the clinics to add an arbitrary number of diseases, patients, and visits. Also, constructing queries for various group-by criteria will become easier for you.
Build a set of 4 tables plus a Many-to-Many (M2M) "linking" table as given below. The first 3 tables will be less-frequently updated tables. On each visit of a patient to a clinic, add 1 row to the [Visits] table, containing the full detail of the visit EXCEPT disease information. Add 1 row to the M2M [MedicalHistory] table for EACH disease for which the patient will be consulting on that visit.
On a side note - consider using Table-Valued Parameters for passing a number of rows (1 row per disease being consulted) from your front-end program to the SQL Server stored procedure.
Table [Clinics]
ClinicId Primary Key
ClinicName
-more columns -
Table [Diseases]
DiseaseId Primary Key
ClinicId Foreign Key into the [Clinics] table
DiseaseName
- more columns -
Table [Patients]
PatientId Primary Key
ClinicId Foreign Key into the [Clinics] table
PatientName
-more columns -
Table [Visits]
VisitId Primary Key
VisitDate
DoctorId Foreign Key into another table called [Doctor]
BillingAmount
- more columns -
And finally the M2M table: [MedicalHistory]. (Important - All the FK fields should be combined together to form the PK of this table.)
ClinicId Foreign Key into the [Clinics] table
DiseaseId Foreign Key into the [Diseases] table
PatientId Foreign Key into the [Patients] table
VisitId Foreign Key into the [Visits] table
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.
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.
Im preparing a program for my teacher friends using vb 2010 express. They keep records about their students. I prepared a database that contains a table named "Mystudents". It has columns like "studentId , Name, Surname, etc.." . My problem starts here. Each student attends lots of lessons during a year. I must keep "which lessons they attended", "when they attended", "which topic done in the lessons" for each students. for example
Id: 104
Name : Jason
Surname : Black
Class : 10A
on 12.04.2011 he attended math lesson and they do trigonomtry
on 14.04.2011 he attended physics lesson and they do gravity
.......
.......
Id: 105
Name : Marry
Surname : Steward
Class : 11B
on 02.04.2011 she attended math lesson and they do trigonomtry
on 14.04.2011 he attended physics lesson and they do gravity
.......
........
i mean i have a list of data for each record of databese. Please halp me..?
In a relational database design, you would typically include a "relation table" to keep track of this:
--------------
| Student |
--------------
| 1
|
| 0..*
--------------------
| Students_Lessons |
--------------------
| 0..*
|
| 1
--------------
| Lesson |
--------------
The Student table have StudentID as primary key, the Lesson table has LessonID as primary key, and the Students_Lessons table contains the two columns StudentID and LessonID which will link students to lessons.
As you see in the database design above, each record in the Student table can be linked to zero or more records in the Students_Lessons table. The same goes for the Lesson table; each record can be linked to zero or more records in the Students_Lessons table. However, each record in the Students_Lessons table must be linked to exactly one record in Student, and one record in Lesson.
If each student may attend each lesson once only, you can extend the Students_Lessons table with additional columns for any other information that you require, otherwise it's probably better to extend the data model with additional tables for storing more information.
If I'm not wrong, you're looking for a 1-N and M-N relationship.
Best suggestion would be you should learn more about database design. You can start googing what's a 1-N and M-N relationship in relational databases.
You're looking to support that in VB, but this is out of .NET scope but it's a database design thing :)
What is the question?
Try to write down all the properties/entities you'd like to store in your database. Based on that, you can perform some normalization to achieve the optimal database structure.
For example: a student's got an id, name and surname. Those properties belong together in a students table.
Further; a student will follow lessons. But this is not a 1:1 relationship. So in the first place you'll get a table 'lessons' where all lessons are defined, after that you'll get a StudentsLessons table where the link between lessons and the students attended is created.
I would use 3 tables.
students
student_id student name .. etc ..
1 jane doe
2 jack dee
lessons
lesson_id lesson_name .. etc..
1 gravity 101
2 hard maths
3 hampsters
student_lessons
student_id lesson_id
1 1
1 2
1 3
Google-ing database design stuff like "normal form", "1 to many", "many to many" and "many to 1" relationships would help you here.
CREATE TABLE student
(
id INT NOT NULL PRIMARY KEY,
firstName NVARCHAR(200),
lastName NVARCHAR(200),
)
CREATE TABLE subject
(
id INT NOT NULL PRIMARY KEY,
subjectName NVARCHAR(200)
)
CREATE TABLE class
(
id INT NOT NULL PRIMARY KEY,
subjectId INT NOT NULL
FOREIGN KEY
REFERENCES subject,
classDate DATE,
topic NVARCHAR(200)
)
CREATE TABLE student_class
(
studentId INT NOT NULL
FOREIGN KEY
REFERENCES student,
classId INT NOT NULL
FOREIGN KEY
REFERENCES class,
PRIMARY KEY (studentId, classId)
)