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 2 months ago.
Improve this question
I have a table that holds student information: the student's name, number, address, courses taken and the instructors and grades from the courses. I want to normalize this table.
What is best practice for this? What will happen to the newly created tables? What are the connections between them?
Start with unique components.
Student - Just stuff about the person themselves
Registration - Their registration info, including such things like Major, Minor, etc.
Instructor - Who are the teachers
CourseCategory - Ex: MATH, COMPUTER, ARTS, etc
Course - Each POSSIBLE course ENG-101, ENG-201, etc
CourseOffering - Each unique offering, such as Each course, timeslot, with whatever instructor at whatever campus.
Enrollment - What student is enrolled in a course offering, status like drop/cancel, final grade (for computing GPA), etc.
Each table would have its own auto-increment ID to JOIN to the respective other tables. You dont want a student record to have columns accounting for 30 classes, their instructors, etc.
Just a sample without more details. For each table, think of the things that can repeat. If so, they probably will be their own table with an ID linking to the parent.
Such as Enrollment would have the student ID, Instructor teaching it, the actual course.
Hopefully this gives you enough to chew on before getting question closed out.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I am working in a database for a college application. There is a Routine table which holds all schedules for five days of a week(mon-fri) for all levels(classes).
Students in each level can also be divided into separate sections and their routine will differ based on their sections. So I thought of adding a "level", "section" column to the "Student" and "Routine" which shows in which section particular student is in and to which section a particular schedule belongs to respectively. With this I could match a particular students with only those routines of the section he/she belongs to.
But I think a better solution would be to create two new table called "Level" and "Section" which will hold the different level and sections in my college. With this the section table can reference level table to determine to which level this sections belongs to. The Student and Routine table will also hold a reference of to the section table so that I can easily match a student with correct routine. But the "Level" table is only going to have one column 'level' and "Section" table is also going to have only two columns 'section' and 'level'.
For this particular case which of the two approaches is better?
I would say the second option but you do not need the table with only 'Levels'.
You should have Tables 'Classes' with Level and Section.
If a Level does not have a Section then this parameter can be NULL.
If you need to get a list of your Levels just do a DISTINCT query and you get the table with all the Levels, so there is no need for a second table.
This is what I would do.
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 5 years ago.
Improve this question
I am having a problem in executing one of my system's features (a parking registration system)
I have set the relationship to a many-to-many relationship which many students are able to register many vehicles.Right now I can't find any solutions on how to add a new record while using an existing primary key (in this case, is the student's id number) A very clear guide would be much appreciated!
A Primary Key, by definition, must be unique for every record. The Primary Key in your table should be neither the StudentID nor the VehicleID. Those should be the Primary Keys within the Student table and the Vehicle table respectively, but the table that stores all of your data should use a separate Autonumber field as a Primary Key.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
OK, I have an Access DB that have an Items Table and a Students Table that contains the monthly subscription fee, this two is linked in a third Table "Payments", that gathers the data from a Student(fee + items) and sum them. But that table only keeps the values and not the description. As the payment is irregular(the student don't need to pay all in the same day), and because of this the student's item debt value needs to be reduced as the way he pays, I need a control of that. So, should I create a new table that copies the data from two other tables and make the changes in this new one, or just use a query to show the data and makes the changes in the "main" table? I'm a bit lost and confuse in this, so sorry this mess.
You need to read a beginner's text about database design before you go any further with this project, imo. The first item found by googling "relational database tutorial" is
http://www3.ntu.edu.sg/home/ehchua/programming/sql/relational_database_design.html
see the section "Create Relationships among Tables". There are countless other tutorials online.
As rule, you don't copy data from one table to another. A piece of information like an item's description nor a user's name should only be stored in one place in a database. When you need that in the context of relating it to data in another table (e.g. to display the description of an entry in the Items table with the cost amount in the Fees or Payments table), you look it up, not copy it.
The way to deal with a student having arbitarily many items is to have a "link" table that mainly stores only a unique identifier of the student and a unique identifier of the Item. Usually, these would be numeric identifiers that are assigned as now student/item/other entities are added to the db.
The point of having a link table is that there is no practical limit to the number of items that can be associated with a particular student.
You call add a column to the link table to relate the student and one or more instance of the same item to particular bills (or or orders or whatever it is that your db is modelling).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have a website I'm building for a friend's business and I am wondering how to go about storing the data. So far I have designed this diagram. Let me give an example:
Say there are 2 events in a karate tournament: Sparring and Forms. Each event can have it's own division: Sparring 4-6 year olds, Sparring 8-10 year olds, etc... And each student can sign up for either 1 or all events.
My question is, does the image below suffice for what I just explained in the example, minus the cardinality.
My second questions is, what is the actual database going to look like? Right now, I can think of the following tables to add:
students
events
divisions
student_divisions (student_id, division_id) Is this correct? Because I need to be able to store multiple divisions to one student
Thanks, any pointers to help me be a better designer would be helpful.
Keep it simple, make it fun.
lose the "id" term (make it student_id or division_id or event_id) Use terms that make it really clear what is being identified. Same for "name".. is that student_name or event_name?
Put as much detail as possible on each student (student_id, current_belt_ranking, date_of_birth (--> age), student_name.
Events (event_name, division_id, date, location) (I'd make key = event_name/division pair) or in the alternative "Sparing_8-10", "Forms_4-6"
Divisions (division id, other stuff as indicated)
student/events table (student_id matched with event_name/division_id pair)
Analyse for first, second, third normal form.
First Normal Form (1NF): In plain English, no row of data can have repeating elements. All occurances of a record type must contain the same number of fields. ex( you would NOT put the events a given student was signed up for within the student table. Put that stuff in a seperate table.)
Second Normal Form (2NF): In plain words, are there any data elements in a single row that are only dependent on a portion of the concatenated primary key? If so, remove those elements into an additional table. (ex: you wouldn't have student name, age, and date_of_birth within the student/events table... )
Third Normal Form (3NF): Every non-prime attribute of your tables is non-transitively dependent on every superkey of tables. 3NF is violated when a non-key field is a fact about another non-key field.(Yeah, like does that even make sense? And frankly I can't provide an example of this for you with your example...Let me do a bit of research... With your system, I don't think there are any tables with large numbers of fields to even get close to this violation. Remember 3NF deals with non-key fields relating to other non-key fields. )
Give it a shot, then build your queries and see if they make sense?
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
I have trouble finding the best solution to create my database. I have 3 entities : Restaurant, Supplier And SubSupplier.
Each restaurant can order to any Supplier. If the Supplier has SubSuppliers, restaurants order directly to one of the SubSupplier but has to know the parent-Supplier for information.
For the moment i have that:
Restaurant (idRestaurant,nameRestaurant,otherStuff,...);
Supplier (idSupplier,nameSupplier,address, phone, ...);
SubSupplier (idSubSupplier, #idSupplier, nameSubSupplier, address, phone,...) ;
But Suppliers and SubSuppliers have exactly the same attributes (like 20) except that the SubSupplier is linked to a parent-Supplier.
I don't really know how to do that correctly because Suppliers and SubSupliers have almost everything in common and i find it repetitive to create 2 distincts table.
Is this a good solution ? What's best ?
A sub-supplier is still a supplier so you shouldn't create a new table for it. What you need is a third table to establish the parent/child relationship between two suppliers. A "sub-supplier" is the child of a supplier. For instance:
Restaurant (idRestaurant,nameRestaurant,otherStuff,...);
Supplier (idSupplier,nameSupplier,address, phone, ...);
SupplierChild (idParentSupplier, idChildSupplier)
Why not have one table for the suppliers, and sub suppliers; with a nullable part "bunny ear" relation. It's then just a left join to find the parent, if there is one, when ordering.
You may want to add a column (superSupplier) to the table Supplier with an ID referenced (foreign key) to a Supplier, so it would be like if you are telling to a Supplier who is its superSupplier and if the value is null, then it's a normal Supplier.