I have three tables:
Student - a table with student information including program, year entered, etc. Each student has a unique ID.
Fellowship packages - each academic year has a selection of fellowships available, though some packages can occur in multiple years. Each package has amounts associated for each semester during the academic year.
Awards - I want a table which has entries for: student, academic year of award, package, amounts associated with each package.
I should say, I also will need a field in "Awards" that denotes the funding source for each semester in each award.
The "Awards" table is linked to the "Student" table by the students ID#. It's linked to the "Package" by Academic Year. My problem is that I keep getting many-to-many relationships between "Awards" and "Packages", even if I create a separate table with just a list of the years and go through that.
Related
Use Case for my application:
There are 8 semesters in a law faculty at a university
There are three chances for a student to pass an exam if she/he fails
There are average 8 subjects in each semester
For the design of database tables in the back-end system there are two options which come into my mind:
i) I should create one table for each semester there which has 8 columns in average with the three changes there will be duplicate ids in it, if a student fails then he/she need to give the second chance exam.
ii) I should create three tables with 8 semester in it that each going to have around 8 subjects, and this is going to be a long table with 64 columns.
Which option should I take or do you have any other option to suggest?
The 4 main entities you've mentioned are:
Semester
Students
Subjects
Exams
So as a starter:
A table called SEMESTERS, primary key SEM_ID, cols START/END dates, NAME
A table called STUDENTS, primary key STU_ID, cols NAME
A table called SUBJECTS, primary key SUB_ID, cols NAME, PASS_MARK, MAX_FAILS
You need a intersection table showing which students attend which classes, so, a table called STUDENT_SUBJECTS, primary STS_ID.
Now, you could have a EXAMS table that is a child of SUBJECTS, then have a table called STUDENT_EXAMS which is a child of EXAMS and STUDENT_SUBJECTS in which you record exam results. Or keep it simple, don't have this EXAMS and STUDENT_EXAMS table, and instead add cols EXAM_RESULT1, EXAM_RESULT2, EXAM_RESULT3 on STUDENT_SUBJECTS to record exam results.
I am attempting to design a DB that houses peoples time that is assigned to a project.
So for example, Bill is assigned to 20 hours on project A, and 20 hours on project B for weeks 50-52 of this year. For weeks 1-9 of next year he is assigned to project C for 40 hours a week.
How would you structure your database so that it could house all of this information for n number of people and projects?
Without knowing more details, it looks like you need three tables:
Person
Project
Person2Project (the join table)
You would enter your employee information in the Person table, Project Information in the Project table, and use the third table to join a person to a project using a primary key/foreign key. The information regarding weeks and hours would be included in the third table.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Note: This is a rough copy i didnt include constraints, weak entities, ..., etc yet. I still need to have a solid understanding of this question.
Questions:
To keep track of what theater company manages performer, what performer is in two theatre companies do i have to make a unique code for each entity set in other entity sets to keep track of them?
Can start_Location simply point to Place for the theatre company entity?
Can an Actor be Born in a place or does it have to have a attribute that points to place?
Do my relationships so far make sense?
Are there any redundant attributes such as Short_Descript in Plays?
Can i make an attribute in Place called "Town, State/Department/Province"? Or does it have to be a composed attribute?
Please note: I will be editing and updating my diagram if I have more questions and such...
I would appreciate any suggestions or hints.
ERD:
Question Information:
An actor is born in a place and he/she lives presently in a place (this information is mandatory).
We store in the database only the last known place where the actor lives.
We need the following information for an actor: actor number, actor name , date when actor was born, and date when actor died (check if died > born).
An actor is a performer, or/and a theater director.
We store for performer the date when he/she started to perform.
We store for theater director the date when starts his/her last employment as theater director
We consider in DBActors the following types of plays: drama, comedy and tragedy.
For each we like to store the following data: play’s number , play’s title , play’s short description , year when it was written ,date when it was first presented on stage(p_date_p, date).
For dramas we store also the drama type,name of the main positive character, and name of main negative character.
The drama type is one of the following:
“classical”, “medieval”, “renaissance”, “nineteenth-century”, “modern”, and
“contemporary”
For comedies we store the comedy type, the name of main
character , and the name of the second character
The comedy type is one of the following: “ancient mroman”, “ancient greek”, “farce”, “comedy of humors”, “comedy of manners”,
“commedia dell’arte”, and “theater of absurd”;
For tragedies we store the tragedy type(t_type, varchar(20)),and name of main
character
The tragedy type is one of the following: “Greek”, “Roman”, “Renaissance”, “Neo
-classical”, and “Modern”
A play is written by one or many dramatists
It is possible that we do not know the dramatist for certain plays.
We store in the database all known plays even if they were not performed (“closet plays”)
Some actors are also dramatists.
We store in the database all known mdramatists.
An actor is hired by a unique theater company at any timestamp
He/she will stay in the same company the whole year when he/she was hired.
We store in the database the year when he/she was hired by the theater company
(small integer)
It is possible that the actor changes the theater company where he/she is
working during his/her life many times. It is possible that an actor is hired by the same company many times in different years. He/she can perform in
one or many plays (at least one)
which are presented by theater companies.
It is possible that an actor is hired by a theater company and performs in a play presented by another theater company.
It is unusual but possible that the same performer plays in the same play
presented by different theater companies. A theater company performs/presents
one or many plays every year.
Same play can be performed by one or many distinct theater companies.
We like to store in the database the date when the play starts to be performed
by a theater company.
It is possible that the same play is performed by different theater companies starting at same date.
We need to store for a dramatist his/her dramatist number,his/her name.
A dramatist wrote one or many plays(at least one).
The information to be stored in the database for each theater company
is: theater company number,theater company name , date when the
theater company started.
For each theater company we store in the database
the first location (place) where the theater company started
There might be more than one theater company starting in the same place.
A theater company must hire at least one actor.
Each theater company has a unique theater director.
He/she starts his/her work at a specific date.
It is possible that the same theater company has different theater directors but at distinct times and the same theater director manages different
theater companies in distinct times(never at the same date).
It is possible that the same theater director manages the same
theater company at different dates.
The information to be stored for place is: place number, town and state/department/province, place country
Here are my responses to your questions:
Whenever you look at two tables and see a Many to Many relationship, you can solve the problem easily using a linker table. Also known as a junction table “is a database table that contains common fields from two or more other database tables within the same database. It is on the many side of a one-to-many relationship with each of the other tables. Junction tables are known under many names, among them cross-reference table, bridge table, join table, map table, intersection table, linking table, many-to-many resolver, link table, pairing table, transition table, crosswalk, associative entity or association table.” Wikipedia example You saw me use these tables in your previous question. In this case you are stating that an actor can be managed my many Theater Companies and A Theater Company and also manage many Actors. This is a many to many so if you created a link table in between those tables for every relastionship between the two you’d add a new row in the link table that only contains a theater Company id and an actor id. If an actor was managed by many theater companies then you’d add several rows to the link table each holding the same actor id but each row having a different theater company’s id.
Yes, you can have start_Location point directly to place. This means that that Start_Location attribute must be a Foreign Key (FK) pointing the theater company to the Primary Key (PK) of the related Place record.
By all means an actor can be born in a place, but just like above, you need a column in Actor, that is a FK to the Place Table’s PK. You could call this column Birth_Place and all it’d hold is the PK of the record in Place that relates to the actor’s birth place. This column would also need to be NOT NULL because all actor’s need a Birth_Place.
So far it seems like your diagram will work to solve this problem, yes. Just see question 1’s answer for that follow up addition.
You’re getting good at removing redundancies. Your diagram looks good. The only suggestion, I’d make is why do you have a play table and then 3 separate play type tables? Why not add them together in on Table called Play. It’d sit exactly where Play currently sits in your diagram and contain the same attributes it already does, but you also add the following:
a. Type – Would be a string that you could place “Drama”, “Comedy”, or “Tradegy” in so you’d know exactly what type of play it is. Also this would allow you to add future play types to the plays table and not have to add a whole new table to the DB.
b. Sub_Type – Would also be a string and hold the type that you currently have under the separate tables. They are all essentially the same attribute in each table and would just hold different type descriptors depending on the parent Type.
c. Main_Character – Would be a string that holds the main character, because in your three separate tables, you have main characters. You’re just calling them 3 separate things. (get the direction I’m going in here? )
d. Secondary_Character – Would be a string that holds the secondary character. You have a secondary character in your dramas and comedies, but non in your tradegies so in tradegy records this column would wind up being null. See what I did there? You now have one table where you used to have 4, and in that one table you can retrieve all the same information you had in those 4 separate tables. Hopefully that’ll make your life easier.
You can do whatever you like, but I’m assuming you mean by best practices and it would be generally considered best practice to separate this single attribute into it’s Simple attribute sub parts. I.E. make it a composed attribute.
So I've volunteer to create a Registering system for my local church's education ministry. It should be able to register new students and keep track of their progress. Here are the requirements I've managed to gather:
The educational institution offers several courses.
Courses have a name and description.
Courses are organized in levels. There are several courses per level.
Courses also have requirements (i.e. other courses that need to be taken first).
A student graduates from a level when it has passed all courses of that level.
If a student cannot pass a course, he may repeat it as many times as he wants/needs.
Students can only take one course per semester.
An inactive student is one that isn't enrolled in the current semester.
Teachers will teach only one course per semester. Teachers may teach a different course each semester.
There could be semesters a teacher doesn't teach.
Now, this is my relational model.
![https://dl.dropbox.com/u/10900918/rmodels.jpg][1]
My questions are:
Are there any tables missing?
Looking at the semester + semester_code_description: is this the best way to do this? Under the assumption that a year has 2 semesters and that each semester have the same start and end months (i.e. semester 1: Aug - Dec, semester 2: Jan - May), is semester_code_description table really necessary?
How could I improve the design?
Sorry I didn't include any arrows. The program I'm using is a mess.
Thanks so much for your valuable time in advance.
1) Nice job on your design. I don't see any missing tables - it looks like you covered all of your requirements.
2) The semester_description table makes sense to me, whether or not you need it depends on whether you plan to do anything with that data.
3) The requirement "students can only take one course per semester" would imply that the Has_Taken relationship's primary key should be (student_id, semester_id). As it stands now, I could insert two different courses for the same student and semester. Similarly for the Has_Teached relationship.
Some other thoughts:
The "last_whatever" columns in some of your tables will force some extra processing on your actual application. You will need some mechanism to monitor/update those. Another option would be to derive them from your tables. I can get a student's last_semester by finding the semester with the max year/code.
One last consideration, how stable are these courses/descriptions/levels? I worked at a university for several years and our courses would change on a semester basis, forcing us to save an entire copy of course records for each change because we want a student's record to reflect what they actually took at that time.
Here's a little example in your app. Let's say I graduated level 1. Then a year later, the church adds a new course (Course A) to level 1. I will effectively be un-graduated b/c now there are level 1 courses I don't have (Course A).
This may not matter to you if your courses are pretty stable. Good luck!
suppose if i need to take different college details and store courses offered by them into databases.Assume number of courses are different for different colleges.how table should be designed to store courses.
here these courses should be able retrieved for further processing
can any one suggest idea for this..
You can start with 2 tables, 1 for Institution (the university/college), and 1 for Course. The Course table should have a foreign key institution_id to the Institution table.
This way you can have as many courses as you want for any college, and looking up courses for a college is as simple as doing a query on institution_id.
Naturally, this is only a start, you will probably have to expand on this. For example, you might want to have another table like College that has a a foreign key to Institution, to model the fact that sometimes universities have many sub-schools within them. You could also have Institution rows reference other Institution rows to model the same thing; what you want to do depends on the details.