Both are looking same to me. i am not getting the exact deference. i search on different forums and sites but not getting clear. what is the difference between them?
The exact difference is as follows. You have to first separate the total/partial participation constraints to understand this better and we'll take them into account later on.
Disjoint Constraint
Any instance can map to at most one subclass. Not more than that. e.g Bank Account can be either 'Savings Account' or 'Current Account' not both. So when the database is operational, every given instance will be mapped to exactly one subclass defined under the super class. Another example would a meal will be mapped to either Veg or Non-veg..It can't be both.
Partial Constraint
Any instance may or may not map to multiple sub classes of a given super class. This usually happens when an instance play multiple roles and not limited to a single one. e.g Employee may map to either supervisor, manager or both. This means an employee can play both the roles of a manager and a supervisor. Another example would be a musician who maybe mapping to either violin player, guitar player, flutist,saxophonist or all of them.
Note:
So when you specify an 'ISA' relationship your subclasses may behave in either disjoint way or overlap way.. They can't be both, meaning that Disjoint is the exact opposite of Overlap constraint.
Now let's focus on Total and Partial constraints.
Regardless of the overlapping/disjoint constraints, total/partial mean 'do all the instances support the specialization?' question. So when the database is operational and if your ISA relationship is total, any instance coming will be directed to one of the sub classes and nothing will stay in the super class. Conversely, if it's partial, some instances may not have an appropriate subclass so they will stay in the super class.
This brings up the interesting notions as follows.
Total-Disjoint- All the instances coming, will map to one subclass only and will not be shared among other subclasses
Partial-Disjoint- All instances coming, may stay with superclass or map to one of the sub classes only
Total-Overlap- All instances coming, will map to multiple subclasses.
Partial-Overlap- All instances coming, may stay with the super class or map to multiple sub classes.
Total Participation vs Partial Participation.
In total participation, patient must be an outpatient or resident patient, it can not simply be the superclass patient type. Partial participation allows you to have a patient be just a patient.
Under Total specialization, there can be no entities that are of a superclass but are not of any of the subclasses. This is represented by the double line drawn from patient
Disjoint means a subclass type patient can be either an outpatient or resident patient but not both. Subclasses can only be one subclass from the superclass not both.
So in both diagrams a patient must be a one of the subclasses, but the disjoint means it can not be both subclasses.
When you use a total specialization, in the example shown, a patient must be either a outpatient or a resident patient, which means that all patients needs to be one of the sub types(outpatient or resident).
The disjoint rule is different in the way that a patient needs to be in only one subtype.
Basically, as I understand, the difference is that the total specialization says a super type needs to be in a sub type and the disjoint says it need to be in only one sub type.
I hope this helps.
There is a link that you can read about all these types and rules:
http://www.tomjewett.com/dbdesign/dbdesign.php?page=subclass.php
There are 2 different decisions {Total participation vs Partial participation} and {Disjoint vs Overlap}.
Participation -> ∈ {subclass1,..,subclassN} vs ∈ {subclass1,..,subclassN, superclass}
Subclass Type -> ∈ {S1 xor S2 xor ... xor SN} vs ∈ {S1 or S2 or ... or SN}
where S is the entities.
Related
Problem description
I am currently working on a project which requires a relational database for storage.
After thinking about the data and its relations for a while I ran into a quite repetitive problem:
I encountered a common data schema for entity A which contains some fields e.g. name, description, value. This entity is connected with entity B in multiple n-1 relations. So entity B has n entities A in relation rel1 and n entities A in relation rel2.
Now I am trying to break down this datamodel into a schema for a relational database (e.g. Postgres, MySQL).
After some research, I have not really found "the best" solution for this particular problem.
Some similar questions I have found so far:
Stackoverflow
DBA Stackexchange
My ideas
So I have thought about possible solutions which I am going to present here:
1. Duplicate table
The relationship from entity B to entity A has a certain meaning to it. So it is possible to create multiple tables (1 per relationship). This would solve all immediate problems but essentially duplicate the tables which means that changes now have to be reflected to multiple tables (e.g. a new column).
2. Introduce a type column
Instead of multiple relationships, I could just say "Entity B is connected with n entity A". Additionally, I would add a type column that then tells me to which relation entity A belongs. I am not exactly sure how this is represented with common ORMs like Spring-Hibernate and if this introduces additional problems that I am currently unaware of.
3. Abstract the common attributes of entity A
Another option is to create a ADetails entity, which bundles all attributes of entity A.
Then I would create two entities that represent each relationship and which are connected to the ADetails entity in a 1-to-1 relationship. This would solve the interpretation problem of the foreign key but might be too much overhead.
My Question
In the context of a medium-large-sized project, are any of these solutions viable?
Are there certain Cons that rule out one particular approach?
Are there other (better) options I haven't thought about?
I appreciate any help on this matter.
Edit 1 - PPR (Person-Party-Role)
Thanks for the suggestion from AntC. PPR Description
I think the described situation matches my problem.
Let's break it down:
Entity B is an event. There exists only one event for the given participants to make this easier. So the relationship from event to participant is 1-n.
Entity A can be described as Groups, People, Organization but given my situation they all have the same attributes. Hence, splitting them up into separate tables felt like the wrong idea.
To explain the situation with the class diagram:
An Event (Entity B) has a collection of n Groups (Entity A), n People (Entity A) and n Organizations (Entity A).
If I understand correctly the suggestion is the following:
In my case the relationship between Event and Participant is 1-n
The RefRoles table represents the ParticipantType column that descibes to which relationship the Participant belongs (is it a customer or part of the service for the event for example)
Because all my Groups, People and Organizations have the same attributes the only table required at this point is the Participant table
If there are individual attributes in the future I would introduce a new table (e.g. People) that references the Participant in a 1-1 relationship.
If there are multiple tables going to be added, the foreign key of the multiple 1-1 relationship is mutually exclusive (so there can only be one Group/Person/Organization for a participant)
Solution suggested by AntC and Christian Beikov
Splitting up the tables does make sense while keeping the common attributes in one table.
At the moment there are no individual attributes but the type column is not required anymore because the foreign keys can be used to see which relationship the entity belongs to.
I have created a small example for this:
There exist 3 types (previously type column) of people for an event: Staff, VIP, Visitor
The common attributes are mapped in a 1-1-relationship to the person table.
To make it simple: Each Person (Staff, VIP, Visitor) can only participate in one event. (Would be n-m-relationship in a more advanced example)
The database schema would be the following:
This approach is better than the type column in my opinion.
It also solves having to interprete the entity based on its type in the application later on. It is also possible to resolve a type column in an ORM (see this question) but this approach avoids the struggle if the ORM you are using does not support resolving it.
IMO since you already use dedicated terms for these objects, they probably will diverge and splitting up a table afterwards is quite some work, also on the code side, so I would suggest you map dedicated entities/tables from the beginning.
I am designing a Database management project of gym management. There are 2 users, one is the clerk who can add,remove and edit all trainers, centers and members and the second user is the member who can only see and edit certain attributes related to him. Member ,center and trainers are 3 entities in the ER diagram so the question should I introduce entity for clerk and if so should it have a relationship with any of the three entities described above?
I wouldn't split up the two Entities based on the Fact that they have different permissions in your system.
I recommend you focus on the concepts behind the entities:
First, if all Attributes are equal I would start considering building 1 Entity out of the two. Once you end up with multiple columns that are mainly null it might have been a mistake to "merge" two entities.
In addition to that you should check if there is a central name that you can give your merged entity. For example if you have the two Entities: Manager, Employee and you want to merge them I would maybe just call it User and check if the Properties still make sense in that context.
Last but not least you should think about how the Entities are used later in the development. If you need two Joins instead of one once you split up your Entities that could be an argument for merging them. Maybe later in the development your 'clark' Entity will be extended by a few columns, this way you might end up with null columns again.
I think a general answer is not suitable since the Domain is unclear. Just collect arguments for and against merging the entities and compare those.
I have what I think should be a common problem in OWL ontology design, but it proves a bit hard to get direct advice on this.
Summary: I need to restrict a ternary relation of 3 taxonomically rich class structures so that the range of the relation is dependent on the respective domain. And I don't absolutely have to model this as schema, I just want to store the information "this subclass is connected to that one" somehow. I see as best options object property restrictions or storing the information as instances, which directly realize the relations I need as instances of a general relation.
Situation:
I have a ternary relation that I modeled by an additional class
There are two taxonomically rather rich classes A,B with respectively many subclasses and a third class C with some subclasses that connects to the relationship between subclasses of A and B
I introduced class D which connects to subclasses of A,B,C
An obfuscated example is: A are herbivores, B are carnivores and C are climatological settings. Now I want to model that certain carnivores hunt certain herbivores and in addition, certain climatological settings affect the hunting behaviour. But not all climatological settings affect all pairs (a,b), so there's interestig information to be stored
Since I can't point from climatological settings directly to a pair (a,b), I introduce D, the class of hunting habits, which relate to carnivores as hunting participants, to herbivores as hunted participants and to climatological settings as modifying setting.
Problem:
I now have a relation from A to D which is general, yet I don't want every hunting habit (pair of hunting and hunted) to be affected by the same climatological settings
For example: Maybe I want rain to affect only the hunting habits between macroscopic animals, or I want volcano eruptions to only affect animals that live near volcanoes
Solution Options:
introduce object property restrictions, which are like virtual superclasses (e.g. the class of animals that participate in hunting habits which are affected by volcano eruptions)
directly introduce all the information in the instance level: create instances of all the animals I want to make assertions about, then also create instances of the climatological settings and hunting habits, then link those instances together
create a bunch of sub-relations that have domain and range the specific animals, hunting habits and climatological settings
I suspect the answer will be "It depends". In that case, I am really thankful to understand some of the advantages and disadvantages of the options. Of course there might be a really good solution that I am missing.
Weak entity with 2 owner entities
I have a database I am trying to design with 3 entities: Store, Item, and Wishlist. Stores and Wishlists exist on their own, and are therefore strong. Items, however, will not exist unless they are either in stock at a store or on someone's wishlist.
What's the best practice in designing the ER diagram ?
What you are describing is really two one-many relationships with an extra constraint on participation ("must be in stock or on a wishlist"). This does not mean that an Item is a weak entity type. I think Item in this case must be strong. I don't think there is any standard ER notation for a participation constraint across mutiple entities unless the entities are all subtypes. I suggest you add a text notation to the diagram if it's important to explain that an item must either be in stock or on a wishlist but doesn't have to be both.
It is sometimes said that a weak entity cannot exist independently of a related entity. That alone is not what makes something weak however. An entity type is weak if it does not have its own identifier independent of another entity type. In your situation I would expect that an item could appear on more than one wishlist or be stocked in more than one store and therefore items must have a common identifier (e.g. a name or a UPC) independently of the wishlists and stores that include them. If that was not the case then wishlist items and stock would presumably have to be subtypes of item, which seems a bit unconventional.
If for some reason you did want to treat items of stock and items on wishlists as subtypes of items then the answer to your question would be a subtype relationship with mandatory participation, e.g. represented with double lines using Chen notation:
I am trying to show the following in the ER diagram:
There are instructors and courses, a course is taught by only one instructor
whereas an instructor can give many courses.
My question is, is there any difference between two diagrams, in other words, does it matter which line we turn into an arrow, or what only matters is only the direction of the arrow?
Also, if we think about the mapping cardinalities; is it 1 to many or many to 1? If we think in terms of courses, then it is many to one but if we think in terms of instructors, then it is one to many. How do we decide this?
Thank you.
In ER diagrams when the relationship is denoted the arrows are not used. Some instructors use this arrow when they want to decide the cardinalities but that is just to get the cardinality (1:1, 1:M and N:M)
I have attached the ER diagram for this in Chen notation and also using Crow Notation you can use either of them.
Deciding the cardinality for a relationship is a practical scenario there is no hard and pass rule to obtain it. What you need to do is start from one side of the relationship and take one tuple (instance) and see how many tuples from the other entity participate for the relationship. Then do the vise versa. Then you know the participation number of tuples) from each entity to the relationship. Think about set theory and functions in mathematics when you decide the cardinality (ie Set of instructors, Set of Courses and set of Teaches relationship type) then this is so easy but if you are not from a mathematic background just think of practical scenario.
For Example
a) For 1 instructor he or she can teach Many (M) courses
b) For 1 Course there is only 1 instructor
so in instructor side there is always 1 in a) and b) but in Courses there is M and 1 in a) and b) there for Instructor:Course cardinality is 1:M
I don't think the other answer is fully correct.
I would say that one should use arrows, and one should use a notation that gives a meaningful name to each direction of the relationship. In this case it will be "teaches" in one direction, and "is taught by" in the other. Either use arrows next to the names or put the name near to the entity to which it refers. You could use one line (with two arrow heads) or two lines (with one arrow each).
I would also suggest that cardinality is just one kind of constraint, and the notation should reflect that. For example, the two names for the relationship could be "teaches (many)" and "is taught by (exactly one)". The point is you might have "teaches (one or two)" or "is taught by (exactly two)" and so on.
It is better to be explicit and clear about exactly what your constraints really are.
Both are having exactly opposite cardinality
🔸Simple clean line means many.
🔸Arrow means one.
If we consider both with same cardinality.
then, many to many should be represented by following the second convention as (please assume diamond for relationship set and rectangle for entity set)
INSTRUCTOR <---- TEACHES -----> COURSE
which is actually of no meaning.
If we consider both with opposite cardinality.
then, many to many should be represented by following the second convention as (please assume diamond for relationship set and rectangle for entity set)
INSTRUCTOR ----- TEACHES ------ COURSE
No explicit arrow is always considered many to many. So, it is correct (only if we consider both opposite)
Consider an 'employee' entity set and 'department' entity set, having relationship set as 'manage'.
Employee-------------Manage--------------------Department
(entity set) (Relationship set) (entity set)
One to many relationship means one entity of employee set can be associated with more than one entity of Department entity set but, an entity of Department set can be associated with at most one entity of employee entity set.
That means if there is one to many relationship between employee and department entity sets, then each employee can manage more than one department and at the same time each department is managed by at most one employer.