A design question which I need help with. It's best described with an example.
Using the following Domain models:
- Student
- Enrollment
- Course
Where Student and Course have a many to many relationship to each other, achieved by the Enrollment table, i.e. Enrollment has a StudentID (FK) and CourseID (FK).
Both the Student and Course classes each have a Navigation Property, i.e. an ICollection of the other.
I'm using View models, and would like simple CRUD functionality, to add, edit, delete students and courses. The View models are very similar to their associated Domain models.
To display the student's details is simple enough, but when it comes to displaying the student's course details, which of the below designs would be the best approach?
In the Student View model, declare an ICollection of the Enrollment Domain Model?
Then in the view the enrollment details are accessible.
I feel as if this undoes what the View model is trying to achieve, and that is to have an abstraction layer from the domain model. Using this design, the Enrollment Domain model is accessible from the View, via the Student View Model.
Create a View model for the Enrollment class.
This will be identical to it's Domain model. Doesn't do anything else other that hold the Domain model's values from the View Model. Has to be mapped via AutoMapper. Not sure what to make of this option, feel's inefficient.
First of all, Enrollment should not be a domain model. Enrollment is just a database table which specifies a many-to-many relationship from Students to Courses.
My suggestion is to create a List of Courses in the Student domain model, and use NHibernate or Fluent NHibernate to map the Student and Course, then create a many-to-many relationship from the mapping, and you can simply retrieve the Courses from a Student instance.
Also, you can use cascading operations more freely when using a mapping instead of writing some SQL statements in your code.
Related
Currently, I'm working on design class model and domain class model.
I have entity class Account and class Member .
I know that class diagrams and ER models can differ from each other.
However, Should I in the ER model include such entities as Account and Member , or can I combine them into Account entity?
First of all, it seems to me that Member belongs to the domain and matters to the business users. It should therefore also be «Entity». But your question seems not really about entities, but more about tables:
Members and Accounts are in your UML distinct classes, since they have different structural and behavioral characteristics. But also in an ER model they would be different entities, as their attributes may vary independently:
Considering that Account and Member are associated one to one in your model, you could consider to store both in a combo-table. That’s an implementation decision about the tables. But it does not really change the entity semantics: a member is still something different from an account.
While you can do this combo-table shortcut, you should ask yourself if this is a good idea in view of the principle of separation of concerns. Keeping them separate will ease your ORM mapping and facilitate maintenance.
If the association of Member with Account would be one-to-many or many-to-many, it would be another story: if you’d combine them into a single table, your relational model would no longer be normalised, and this has many inconveniences.
I will preface it by saying I'm a database person, moving into .NET, MVC, EF etc. So I fully understand about joins and foreign keys and so on but I am struggling with the EF side.
I worked through a tutorial where we did the following:
create a Student table (StudentID and personal details), a Course table (CourseID and subject details), and an Enrollment table (EnrollmentID, student and course IDs and the grade given to that student for that class).
create Models, Controllers and Views for Student and Enrollment entities to allow editing the name of a Student, enrolling a student for a class and giving them a grade, list out all enrollments, etc.
In that tutorial the Enrollments table is (what I know as) a "bridge" table because student to class is a many-to-many relationship.
So do I only need this "intermediate" model/view/controller if it's a many-to-many scenario like this?
The actual structure I want to program is:
Article (ArticleID, title, author, summary, content...) is a member of a
Category (CategoryID, title, description, ...)
Then I want to have a drop down list (or whatever UI element) of Categories of which clicking on the selected Category will give a page with a table of Title/Author/Summary of the articles that go in that category.
If an Article can be in more than one category ("Effective Use of Catnip" could be under both "Playing Games with Cats" and "Life Hacks") is that where I would need a 'bridge' table?
Please can someone explain in simple terms - whether I am just being put off by the "many to many" nature of the data in that tutorial, or if the 'bridge' table structure is more fundamental to EF for navigating a PK/FK relationship.
I think the tutorial you are reading is trying to introduce you to the basic concepts of EF. If you have a many-to-many relationship, on database side you will always have three tables:
Student
Course
Enrollment (Student_Id, Course_Id)
On EF world, you can represent those three tables as three different entities. However, if you want to have a more "natural" way of representing the relation between Students and Courses, EF allows you to declare many-to-many as two lists:
public class Student {
... properties
virtual List<Course> Courses;
}
public class Course {
... properties
virtual List<Student> Students;
}
However, you need to instruct EF how this references on both side needs to be treated. For that, you can use fluent API. With this fluent API you can define the table name that references both tables/entities:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<Student>()
.HasMany<Course>(s => s.Courses)
.WithMany(c => c.Students)
.Map(cs =>
{
cs.MapLeftKey("StudentRefId");
cs.MapRightKey("CourseRefId");
cs.ToTable("StudentCourse");
});
}
Check this article explaining the M:N relationship using fluent library API. Is really simple, and with that you don't need this additional element on the middle.
In terms of UI, you just need to select the list of courses the student want to take, or the list of students the course has to have. Is up to you how you want to present the information to the user, as both functionalities (students taking courses and courses defining its students) point to the same m:n relation.
I think a simple way can be to show a </select> list with the students, and then show the list of courses he can apply to.
The project you want to create uses the same ideas. Basically, with EF you will always need to think in terms of "tables". It is true that EF allows you to abstract your tables to entities, but still you need to follow some rules. To sum up: you are right. The "bridge" table is where you need to store the many-to-many relationships.
I’m working with Ruby on Rails, but this question applies to application/database model design in general. I want to model many types of people such as User (someone who can log in), Employee, and Customer. Each of these has common attributes like name and email that should be part of a Person superclass. Each type also has other more specific attributes. A Person can be one or more of these roles (someone can be both an employee and a customer).
In code, the appropriate structure seems like a superclass/subclass relationship, but from a database normalization perspective, there should be a Customer table that references the Person table for its common attributes.
I need to decide how to combine these two approaches.
For example, I want to be able to create a Customer by Customer.create(name: “Johnny Appleseed”, favorite_product: widget) and query Employee.where(email: “someone#company.com”), and avoid duplicating Person fields on every role model. That way I can change the way I model a Person without needing to update all the other tables with the same changes.
It would be better if you use Single Table Inheritance.
You can start from this tutorial https://samurails.com/tutorial/single-table-inheritance-with-rails-4-part-1/
I have a problem with habtm on a single model in rails.
Example:
Let us say i have a User model with two roles "Student" and "teacher". User model is common for two roles. Now
Each student can be associated to many teachers
Each teacher can be associated to many students
In rails notation, their should be habtm between teacher and student
How this can be achieved with single table.
Thanks,
Aashish
It can't be done with a single table. In a many-to-many relationship, no matter what, you always need a table where you store the associations.
In your case, given the association seems to be parent/child, then you just need two tables instead of one.
How to implement it, it depends on your database structure and data organization. You should create an users_users table (as part of the habtm) and configure the references accordingly. If the user table, as it seems to be, is also used for STI, then the configuration may change a little bit.
There are two entities in my app: Class and Student, they are many-to-many relationship, like following:
My problem is that in my app, there are two status of student in a class: pass and fail. I don't know how to model it to class or student. For example, should I make another Entity to express the status of a student? Or just adding a status attribute to Class entity?
Presumably you can't add an attribute to class because then if 20 students are taking the same class there'll be only one attribute between them?
You'll need to add a separate entity which has a to-one relationship with both a class and a student and which contains the status. And in reciprocal both student and class will have a to-many relationship with statuses.
EDIT: I guess an alternative solution would be to insert the status directly in between your existing relationship. So a class has a set of statuses, and each status has a student.
So relationships would be one to many from class to statuses and many to one from statuses to students. There'd be no explicit relationship between class and student.
I would suggest having a third entity which expresses the status for the student in a specific class. For example a Set of "classStatuses". Since you might need to store other information later, for example grades, credits, assistance records, etc etc.
The final scheme would be something like
Class - Student in a many to many relation.
Student - ClassStatus in a one to many. (Picture is as an array of the classes the student is taking with its respective status)
This way you can search for the students in a class, search for the classes a student is taking, check the status of the class.