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.
Related
The thesis Ontological foundations for structural conceptual models states that
"Every relationally dependent entity (role and role mixins) must be
connected to an association end of a «mediation» relation."
(p.332). Why is a <<member of>> relation not enough to satisfy the relational dependance?
There is indeed a pattern of roles and role mixins for members of collectives, however, the membership to the collective has a truthmaker of its own.
If you only use the «memberOf» relation you'll be hiding the relator of "membership" that makes it true that "the endurant plays the role of a member of some collective". In order to have the complete pattern, you should capture the relator and the «mediation» relation between the role and the relator.
Notice that this is a pattern specific to the case involving roles (e.g., employees, students, band members). You can still have cases where there may not be a relator as the truthmaker of the «memberOf» relation.
Take, for instance, the collective Forest whose members are instances of Tree. In this case, you would not be interested in capturing the "membership" between trees and forests and that is OK as Tree should not be a role, but a category, kind or subkind. (hint: the truthmaker here is something more "tricky")
I am learning about ER modelling about Database systems. My problem is that there is a entity called books,enitity named user and I want to create a borrows relationship between user and book with attribute issue date. I modelled it as described but it was pointed that borrows cannot be a relationship because a same user can borrow a book twice. Can anybody explain me what this is as I am using issue data as an attribute so records in borrows relationship would not collide as I will use PK as userid,bookid and issue date. How can I model this accurately? I am a little confused in this.
In the ER model, entity relations consist of attributes of a single entity set, in which the PK identifies only one entity set. Relationship relations have a composite PK that represents two or more entity sets.
Your question uses a composite PK that represents two entity sets (userid and bookid) and a value set (issue date). Strictly speaking, it's neither an entity relation nor a relationship relation. It's a combination of a relationship relation (two entity keys) and a weak entity set (issue date functions similar to a weak key). If we want to be creative, we might call it a weak relationship.
If I was forced to draw an ER diagram for this, I might present it like this:
The ER model isn't a complete logical model (unlike the relational model) and there are some situations which aren't handled well or at all. This is one of those situations.
As per description, User and Book are the entities.
One user can borrow an instance of book.
Similary, one user can borrow multiple instances of book, whether It can be same
instance or various instances.
So every transaction between the User and Book has the Issue Date.
Neither the user nor the book has the Issue Date.
Here, the relationship between User and Book are Many to Many.
The Bridge table is Transaction. We can name it as Borrow also as per your interest.
Now, The user has one to many transactions.
Every Book has one to many transactions.
Every transaction is a combination of a User and Book.
Note: Since every user can have the same book multiple times and at the same day. So we can have a composite primary key of user_id, book_id and Issue_timestamp as there is a chance of redundancy in the Issue Date in the same combination.
In EER modelling is it possible and correct to have a disjoint specialization where none of the sub-classes have any specific attributes(local to them) but are entirely grouped on the basis of a defining attribute.For example we can have a USER entity with some attributes of which one is "role".Based on value of role(admin or author or editor) we will have the subclass entities ADMIN ,AUTHOR and EDITOR.None of them has any attributed which are only specific to them.Also please note that the specialization is disjoint and the superclass entity USER has total participation.
And if this is possible, can I convert it to relational model by creating a single relation for the superclass entity USER
Yes, it's possible and valid to do so if you want to record relationships that are restricted to the subtypes. If you don't have subtype-specific attributes or relationships, there's no point in distinguishing subtypes in the ER model. A simple role attribute on the User is sufficient for queries.
If you define subtypes in the ER model, this converts to a relation per subtype in the relational model. If you're looking for something like dependent types, you won't find it in the relational model, which corresponds to first-order logic. ER is even more limited.
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 want to create a hierarchical object model in ASP.NET MVC, but I'm not sure what would be the best way to design database for this. I have a Product base class with certain properties like Title, Price, OnHandQty etc. I have several inherited classes like Book, which has extra properties like ISBN number, Author etc. Many of my products will fall under generic (base) Product class, but some products will fall under these derived classes (e.g. Book). I am not sure what is the best methodology to map this to database. Should I create separate tables for each product type (including one for generic product)? Or is there any better way?
Please note that I'm not really asking about OR mapping. I know how to create classes from DB tables using Entity Framework. But in this case I am confused about the database design itself.
If you are going to use Entity Framework then you should check out Inheritance with EF Code First by mortezam. He explains three strategies that can be used for representing an inheritance hierarchy:
Table per Hierarchy (TPH): Enable
polymorphism by denormalizing the
SQL schema, and utilize a type
discriminator column that holds type
information.
Table per Type (TPT): Represent "is
a" (inheritance) relationships as
"has a" (foreign key) relationships.
Table per Concrete class (TPC):
Discard polymorphism and inheritance
relationships completely from the
SQL schema.
The idea (with Code First) is that you define your classes and inheritance and let the framework create the database for you. That way you don't need to worry so much about the database design.
You might also want to think about using an Object Database or one of the NoSQL storage strategies like Mongo DB which work better than relational databases when you have these kind of 'jagged' classes.