I have difficulty understanding this statement in DL:
∃R.∃S.C(a)
What does this proposition exactly mean?
Thanks in advance!
This means that the individual named a belongs to the concept ∃R.∃S.C. The concept ∃R.∃S.C represents the class of things that have a relation R with something that has a relation S with something that is in the class denoted by C. For instance, if R is the relation married to, S is the relation works for and C is the class of Public organisations, then ∃R.∃S.C represents all the entities that are married to something (or someone) that works for a public organisation. Then ∃R.∃S.C(a) means that the individual named a is such an entity.
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.
As the title states, I need to tell grails GORM that a domain class has a many to many relationship to itself.
In my system, I have a class "course", this "course" class can have none, one or many correlatives.
Taking the example:
mathematical analysis 2
To be able to take the mathematical analysis 2 course, you need to have approved mathematical analysis 1 and physics courses.
mathematical analysis 1 does not have any correlatives or courses to be approved to be able to anyone to take the course.
I have the following:
class Course {
String name
static hasMany = [correlatives: Course]
static belongsTo = [target_course: Course]
}
But it does not seem to have the impact in the Data base that I expect.
Im expecting to have a course_course table that has the many to many to itself like the following:
course_course
int id_course_course
int id_correlative_course
int id_target_course
Am I missing something important here?, help please!
You don't need a many to many table to represent that. While each Course may "have many" correlatives, each correlated course only has one parent.
This is sufficiently represented by a single table like (heavily depending on any mappings you specify):
course:
id (int)
name (varchar)
target_course_id (int, nullable)
I'm new to Neo4J and I have a question about the most appropriate data model for a the problem domain described below.
Background
As I understand it, in Neo4J every relationship has a direction of sorts, outgoing, incoming or undirected. I read that a common mistake newbies make in "bi-directional" relationships is that they might model the relationship in both directions where in reality one undirected relationship would serve the purpose well. I also understand that irrespective of the direction it is possible at query time to ignore it and query based on either side of the relationship.
Problem Domain
This is a bit cliché, but stick with me, in a graph where "People" can connect with one another I felt tempted to model that as an undirected relationship. However, perhaps in my problem domain I want to store meta data on the relationship edge rather than at either of the People nodes. E.g. timestamp of when then connected or type of relationship (friend, family, employer etc...). Perhaps this is a "side effect" of using the spring-data-neo4j libraries but it seems that if I wish to data meta data on the edge rather than at the node I must create a class which is annotated as #RelationshipEntity rather than #NodeEntity. This necessitates a #StartNode and #EndNode which then seems to imply a direction to my otherwise undirected relationship...
Now, as it turns out this might not be a bad thing in my case because perhaps after all it turns out there is something useful about this additional directed context (e.g. perhaps I want to know who initiated the relationship so that the target node (person) must accept the invitation to be friends).
Now imagine that each person can place the "relationship" into a "group" like "friends, family, colleagues" etc I feel like I'd now need to actually have two distinct edges that point in either direction so that the meta data specific to the given direction has a natural place to reside. But this seems to have been described as a newbie anti-pattern.
Questions
I have two questions:
1) Should I use two separate distinct relationship edges that essentially point either way as a bi-directional relationship if I need to store meta data that is specific to the direction. e.g. Person A <--> Person B but person A placed Person B in the friends group whereas Person B placed A in the colleagues group.
2) Given the Java data model below, I am unclear what the direction attribute on the #Relationship annotation of Person should be. If I specify nothing it default to OUTGOING. But since it's a reflective relationship depending on which person instance you look at the relationship could be either outgoing or incoming, e.g. if person A adds person B, both are Person instances, but the direction is outgoing on the person A instance and incoming on the person B instance. Should the annotation be omitted altogether since I'm using a #RelationshipEntity?
Java Data Model
#NodeEntity
#EqualsAndHashCode(of = {"id"})
#NoArgsConstructor
public abstract class Person {
#GraphId
private Long id;
... other attributes
#Relationship(type = "CONNECTION_OF", direction = UNDIRECTED)
private Set<Connection> connections;
}
#Data
#RelationshipEntity(type = "CONNECTION_OF")
public class Connection {
#GraphId
private Long relationshipId;
... other meta-data
#StartNode
private Person from;
#EndNode
private Person to;
}
1) The rule of thumb that works well is to answer a question - if a relationship from A to B exists, can another relationship from B to A still be created, with different metadata? And can you delete one direction of the relationship independently of the other?
If the answer is yes they go for two directed relationships, otherwise stay with UNDIRECTED, and create initiatedBy=userId property or similar.
For your case where you put connections into groups - the thing is that you really categorize the people from another person's view, maybe it is a completely different fact independent of the CONNECTED_TO relationship?
You could e.g. create a group node and link that to owner and all people in the group, with following schema:
(:Person)-[:OWNS]-(:Group)-[:CATEGORIZED]-(:Person)
2) Keep the #Relationship(type = "CONNECTION_OF", direction = UNDIRECTED). For a given person X the connections Set is going to have elements that have from=X for outgoing edges mixed with elements that have to=X for incoming. All of these will be mixed in one collection.
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 new to ASP.NET MVC, so please pardon me if I mentioned wrong terminology on my question
I'm trying to create a soccer related application. Right now I'm trying to design the database / class structures for my application. However I run into a problem when I'm trying to define an appropriate class structure / business logic to represent a soccer match.
On every match 2 teams commonly play, and each team has different attributes (e.g. numbers of red cards, yellow cards and goals it receives), my question is how could you or would you define that business rule in your entity framework structure?
Would it be appropriate for me to use inheritances relationship between those classes?
Here is what I've currently done:
Match Class with these attributes:
MatchID
Date
HomeTeam
AwayTeam
HomeGame
MatchID
TeamID
YellowCards
RedCards
Goals
AwayGame
MatchID
TeamID
YellowCards
RedCards
Goals
My question is what sort of relationship should I used to represent such business logic, perhaps inheritence, or would it be appropriate to use collection of class (Many to many relationship) instead?
I will gladly appreciate your input and/or suggestion
Thanks heaps!
HomeGame and AwayGame doesn't differ at all, so why to differ them on class/database structure level? I would use the same class here (let's call it GameAppearance for example) and just have two differently named properties of that type in Match class. No need to inherit anything here.
Match:
MatchID
Date
HomeTeam (of type GameAppearance)
AwayTeam (of type GameAppearance)
GameAppearance:
MatchID
TeamID
YellowCards
RedCards
Goals