Recently I'm working on a project, in which I need save multiples subjects in my database, and numbers of subject will be change as per student's class. e.g: class "VII" has 6 subject (included 1 option subject), class "VIII" has 8 subjects (1 included option subject) and so on. Even the option subject can be different according to student's choice.
I'm using CheckedListBox control. Here is a screenshot.
I'm using MS Sql Server 2012. I'm facing difficulty to design database table. I can't understand should i create all the subject columns in my student table or ????(best way). Please help me, thanks in advance.
What you are describing is something that is called a Many to Many relationship. Many Classes have Many students.
You will have a students table, a subjects table and then a table student_subject table which links both the primary keys of the students and subjects table.
Reference: Many to Many
If a Student can have multiple Subjects, and a Subject can have multiple Students, then that's a many-to-many relationship. Which means there would need to be an intermediary table to link them.
Start with the tables for the objects themselves:
Student
----------
ID
Name
etc.
and
Subject
----------
ID
Name
etc.
Since these are independent aggregate root objects in the domain and neither one owns another one, their tables just contain information which describes that object. A Subject, for example, could have a name and a description, maybe a list of pre-requisites, etc.
Then you create the relationship table between them. A common practice is to just combine the names:
StudentSubject
----------
StudentID
SubjectID
If no two pairs of Student and Subject can be repeated, then the two foreign keys together can make the primary key. If they can be repeated (if the same Student can have the same Subject more than once) then you'd probably want to add a separate primary key to the table.
At its simplest, all this table does is create the relationships between the records in the main tables. However, this can potentially grow to be a domain entity in and of itself. If there are any attributes which describe the relationship between a Student and a Subject, those would be added to this table.
Your database schema should look something like this......
Students
Student_ID (PK)
Student_Name
etc .......
Subject
Subject_ID (PK)
Fee
etc......
Student_Subjects
Student_ID FK Students(Student_ID)
Subject_ID FK Subject(Subject_ID)
DateStarted
etc.....
Related
Is it possible/or good practice to have one table like an address book that is related to different entities e.g: People, Companies, etc
I am thinking of using a compsite FK (typeid = entity type id e.g: 1 for people, 2 for companies etc, while the other column refers to the pk of the entity's table).
The other alternative I have is to use a junction table between the entities and address book table.
I am using VS 2005 C#, and sql server 2008
Assumption: your entities are all stored in one table with a type discriminator
Yes, a foreign key can have multiple columns.
An address entry only needs to know the PK of the parent entity
It does not need to know the type of entity: entityType is an attribute of entity not address
Junction table or straight FK? It depends on your relationships:
Can one address be shared by more than one entity?
Can one entity have more then one address?
Yes to both: junction table
Yes to Q1 only: address PK is an attribute of entity. Entity is the child table in the FK
Yes to Q2 only: entity PK is an attribute of address. Address is the child table in the FK
And the case I would not expect:
No to both: 1:1 relationship or you need only one table, address is an attribute of entity
I see no need for a type and an entity_id that refers to one table or the other. This is a complicated approach (two tables using the same ID pool and no foreign key to a table possible) that might cause problems later.
Your problem seems so simple that no tricks should be needed here.
You have companies, persons and addresses. If each person and each company has one address, you have the address id in the companies and persons tables. If a person can have more than one address you need a bridge table. Same for more than one address per company. That's all.
I've been used to this kind of convention before starting to work with Entity Framework/MVC:
tblMyItem (id, id_lookup1, val2, val3, val4...) - single, generic table
tblkLookup1 (id, val1, val2,...) - one to many relation table
tblmMyItemLookup2 (id, id_myitem, id_lookup2) - many to many relations table.
Recently I've found somewhere on the web that it's not good to create id column in tblmMyItemLookup2 when using Entity Framework, but I couldn't find more information on that. Could anyone please explain, why this is so significant?
When designing many-2-many relationship(i.e Student - Teacher) based on intermediate table (Student2Teacher) with only 2 foreign key columns, you'll end up having entities with navigation properties without intermediate table(no entity will be created for that table in context at all):
Student.Teachers <- EntityCollection<Teacher>
Teacher.Students <- EntityCollection<Student>
Meanwhile, if you add any extra field to your intermediate table, you'll have navigation properties pointing to intermediate entity:
Student.Student2Teacher
Teacher.Student2Teacher
making your querying uselessly more complex
In general we use lookup tables to macth associated records in two different tables that have a many to many relationship. For instance, let we have three tables: Students, Professors and StudentsProfessors. Since, a student can atten lesson that are serviced by many professors and a professor can teach more than one leasons then this is clearly a many to many relationship. So the lookup table called StudentsProfessors is used to match a student to her/his professors and vice versa. Now, the use of an id for each record of this lookup table is meaningless. We are not going to use this number anywhere. We just need to know that Student with studentId=10 is associated with professors with ids in (1,2,4,9). Just that and not the id of this record in the lookup table.
I have two classes(Book,Software) that inherit from the Product class. these two classes have some fields that are different from each other. if i am to save the data for both these classes to a single table it would cause some columns to have null values.
if i save the data into different tables(Books table and Software Table) and then wanted to view this data in a single gridview, would i have to join the data and then load it to the gridview?
I would like to add 2 more classes(IndividualCustomer, WholesaleCustomer) later on which will inherit the Customer class in the same manner as mentioned above.
please guide me towards the best approach.thank you
I'm no C# programmer, but I'd go with something like
`products` table
- product_id (pk)
- title
- price
- etc
`products_software` table
- software_id (pk)
- product_id (foreign key, relates to a product_id)
- serial_number
- storage_media
`products_books` table
- book_id (pk)
- product_id (foreign key, relates to a product_id)
- pages
- author
In situations like this I create three tables: Product, Book and Software.
In Product I'll put the PK and all common fields; in Book the same PK and book specific fields; the same as Book for Software.
The associations between these kind of tables should be 1:1.
The Books and Softwares are not different Products they are just different Categories.
I would create several tables:
Products
Categories
Properties
PropertiesToCategories
PropertiesToProducts
In this form you can attach some property to each category, example: Books has Author, Title, Publisher
When you want to add a new Product you should choose first it's Category and then you can attach the available (for Books: Author, Title, Publisher) properties to your new product.
Just after some advice regarding this database design situation.
So I have two tables in the database.
Table 1: Patients
Table 2: Claimants
Patients holds attributes data on a private patient, so details about the person, his/her birthday, names, medical conditions, etc etc..
Claimants is the entity who pays on behalf of the patient, so Claimant can be a patient himself, another person, a business (who pays for work injury), private healthcare provider, government bodies etc etc..
Patients and claimants have IDs who are foreign keys in other tables such as invoices, receipts etc...
One Patient can have multiple Claimants (More than one entity can pay on his behalf), each Claimant can have multiple patients.
On further investigation, I've identified that many of the attributes of Patients and Claimants overlap as a Patient can pay for himself thus is a private Claimant.
My thinking is to merge the two tables into one and simply call it accounts and have a claimantType field to identify the type of the account, be it private, healthcare, business or government.
What potential practical drawbacks do I need to keep in mind with this change? Apart from the changing the other linked tables in database?
EDIT: Just to make it clear, There's already a junctional table PatientClaimants which basically just map the patients to the claimants. Thanks!
Merging these two tables I believe is wrong.
A patient is always a human. So it cannot be a business or an organisation.
I believe here you have:
Address
=======
......
Person
=======
AddressId (FK)
BusinessEntity
==============
AddressId (FK)
Patient
=======
PersonId (FK)
Claimant
========
PersonId (FK)
BusinessEntityId (FK)
Here PersonId or BusinessId one of them can be null.
You could either (a) put in an intersection table that relates patient IDs to claimant IDs, or (b) as you discussed, merge them together - but if you already have data out there that could be problematic.
You could also set up a demographics table that shows common data between patients and claimants and references an abbreviated patient/claimant table - this way you do not break your existing structure.
Hey I have 3 tables called STUDENT, COURSE and ENROLLMENT. STUDENT has a PK of S_ID(student ID) and COURSE has PK of C_ID(course ID). In enrollment it only has S_ID and C_ID. I have an object data source to show all the students name (in text, and S_ID as the value) in a drop down menu and it will show which courses he is registered in when clicked, using a datagrid and another object data source. I wont to have the student to have multiple courses to be registered too, but I cant do that because you cannot have the same ID in the COURSE table, so every student is only registered to one course.
Is there some sort of option to have same ID's in a table?
If not, then I must some how manipulate the string in C_ID in the COURSE table because all the courses start with ISDVXXX or ITSXXXX or HGFXXXX. This may be hard to understand but hopefully someone will help.
An example may help
So if a student named Joe with a S_ID of 123 is registered to ISDV, he will be registered to all the courses that start with ISDV. But my problem is that my COURSE table has to have unique ID for each course such as ISDV123, ISDV346, ISDV395 etc... so this also ruins my enrollment table because I cannot simply have ISDV in there, it needs a specific course but he is registered to all of them. Any more clarification will be given :P Thanks...
What you're trying to solve is a multi-valued attribute problem. Basically, you have two tables where one (students) has a primary key which is a foreign key in another table (classes). You don't want to have multiples of the same class in the classes table, but you do want a student to be able to have multiple classes.
So, there is a very simple fix, you create another table which contains at least these two columns: student_id and class_id. This way, you could have a single class that multiple students are linked to, and also multiple classes to which a student can be linked to.
What you are looking for is a many to many relationship - i.e. a single student can have multiple courses, and a single course can have multiple students. So your link table (is this what you intended enrollment for?) should have two columns, one for the course ID and one for the student ID.
So if you had student 123 and student 234, and courses ABC and XYZ, your table would look something like:
S_ID C_ID
123 ABC
123 XYZ
234 ABC
Now, for your PK on enrollments you could either use a composite key, or add a unique integer RowId (Identity or HiLo algorithm).
In that case, your enrollment table would look something like this:
S_ID C_ID RowID
123 ABC 1
123 XYZ 2
234 ABC 3
Then, to see what classes a student was in, you could do something like
Select * from courses c
inner join enrollments e
on c.C_ID = e.C_ID
AND e.S_ID = #StudentId
Your Enrollment table stands for the m:n relationship between the Studend and Course tables.
For instance your student with S_ID = 69 is Enrolled to the Courses with C_ID = ISDVXXX , C_ID = ITSXXXX, C_ID = HGFXXXX
A Student can be Enrolled to more Courses and more Students can be Enrolled to the same Course, that's why you have your Enrollment table. In our example, the Enrollment will have the following rows:
(69, ISDVXXX), (69, ITSXXXX), (69, HGFXXXX).
If later a student with the S_ID = 96 joins to the Course with C_ID = ISDVXXX, the following will be the new rows of the Enrollment table:
(69, ISDVXXX), (69, ITSXXXX), (69, HGFXXXX), (96, ISDVXXX).
The important thing to understand here is that each row in the Enrollment table stands for a Student Enrolled to a Course and there is no need to other fields than the ID of the Student and the ID of the Course, for these two fields together identify an Enrollment.