I was searching for the meaning of the symbol marked in red in the image below, but I didn't get anything.
So, do you guys know what it means?
It indicates a supertype/subtype relationship. The notation is used in Microsoft Visio, where it's called a category. A double horizontal line is used to indicate a complete category.
In your image, Jurusan records information about the parent/supertype while Animasi, TKJ, RPL and Otomotif describe children/subtypes.
Here's a video on the topic.
Supertype/subtype hierarchies
It does seem to represent supertypes and subtypes. Often the circle will have either a d or an o inside. The d stands for "disjoint" or non-overlapping and the o would stand for "overlapping". These would be constraints. A d would mean that an instance can only appear in one subtype. An o would imply that an instance can be in multiple subtypes. In your example, I'm assuming the supertype instance in question would come from your Colon Siswa table.
Since no information is included in the circle, we do not know. As for the line beneath the circle, there is an option of 1 line - partial completeness or 2 lines - total completeness. The completeness constraint identifies whether an instance in the supertype has to be in one of the subtypes. A single line implies that a supertype instance does not have to be in the subtype. While a double line (2 lines), implies that an instance HAS to be in the subtype.
Supertypes and subtypes are sometimes organized in a specialization hierarchy. The ER model is sometimes called an "enhanced" or "extended" ER Model or EER in that case.
The model you provided is also missing the subtype discriminator. The subtype discriminator would let us know which attribute (field) determines which subtype the instance would belong too. Since you're familiar with the language your model was created in, it may be obvious how it will be determined which instances from the supertype (parent entity) would fall into which subtypes (child entities).
We sometimes call the relationships shown on a specialization hierarchy a "is a" relationship.
You can find examples of these relationships in the textbook below:
Coronel, C. (2017). Database Systems: Design, Implementation, & Management, 12th Edition. [VitalSource Bookshelf Online]. Retrieved from https://bookshelf.vitalsource.com/#/books/9781337509596/
or the following reading room...not my own, but it is an example from the text above.
Reading Room Notes
cardinality symbol, i think one to many symbol
Related
neo4j#neo4j> create (v:player)-[]->();
Exactly one relationship type must be specified for CREATE. Did you forget to prefix your relationship type with a ':'? (line 2, column 18 (offset: 18))
"create (v:player)-[]->();"
I think this is also useful for queries like MATCH p=(v:player)-[]->() RETURN p, so why limit it?
Actually, WHEN I was watching cypher, I was a little confused about why to proposed the concept of relationship type instead of the concept of Edge label.
Can someone help me with this problem?
Relationship type and edge label are identical concepts. Each relationship needs exactly a single type or label to be defined when you import the graph. You can always use a generic edge label like RELATIONSHIP if you don't have a specific edge label in mind.
create (v:player)-[:RELATIONSHIP]->(:player);
This is how the property graph model is defined in Neo4j. However, you can always match relationships and disregard the relationship type as in your example:
MATCH p=(v:player)-[]->() RETURN p
For more details on modelling relationships in Neo4j, check the following blog post: https://medium.com/neo4j/graph-data-modeling-all-about-relationships-5060e46820ce
There is an E.R. diagram like below.
My questions are:
What is the cardinality for the arrowed line between “teacher” and
“offer”? (Or is it possible to talk about cardinality for this
diagram?)
What does this arrow mean about relation of “teacher” and
“course”? (I found out that it is for showing the relation’s way
from left to right and means “teachers offer course”. Is it true?)
Why is this arrowed line between “teacher” and “offer”, but not
between “offer” and “course”? Is there any difference for these
situations? If yes, what are the differences?
What is the notation type of this arrowed line according to third link below (or according to any other source) ? If it is “Shaler/Mellor”, why is the arrowed line in bold style?
I examined the related questions and link below. But I really confused.
entity relationship diagram
One-to many relationships in ER diagram
Class Diagrams
Entity Relationship Diagram
As far as I know, your diagram uses a mixed notation. It's mostly Chen's notation, but he used 1 to indicate unique constraints on a component of a relationship, and variables (M, N, P...) to indicate multiple possible occurrences. Different variables were used per relationship so that numerical correspondence between different roles weren't accidentally implied.
Some online sources (e.g. this one) show that an arrow represents a unique constraint, and a bold line indicates total participation. In your diagram, that would mean mean a teacher must occur exactly once - each teacher offers a single course.
In some examples the arrow is reversed without a change in meaning. It's also possible that the author of your diagram only meant to indicate a preferred reading direction. Without a reference or explanation, we can't be sure.
If the arrow was used to indicate a unique constraint, then it matters on which role its used. An arrow between offer and course would mean each course can only be offered by a single teacher. An arrow on both roles would indicate a one-to-one relationship.
Whether this notation was adopted from data structure diagrams, the Shlaer-Mellor method, or just for a more visual indication of cardinality, I don't know.
Is possible to define a data property of a class as the number of individuals of another class, and this number is computed automatically.
There is no functionality for counting already available, far as I know.
It could be implemented for asserted axioms, but I don't think it can be guaranteed to work reliably. The open world assumption and the default non unique name assumption mean that it's impossible to say if there are unknown individuals or if any of the known individuals are sameAs each other.
Relationship/Arrows in Neo4j can not get more than one type/label (see here, and here). I have a data model that edges need to get labels and (probably) properties. If I decide to use Neo4j (instead of OriendDB which supports labeled arrow), I think I would have then two options to model an arrow, say f, between two nodes A and B:
1) encode an arrow f as a span, say A<--f-->B, such that f is also a node and --> and <-- are arrows.
or
2) encode an arrow f as A --> f -->B, such that f is a node again and two --> are arrows.
Though this seems to be adding unnecessary complexity on my data model, it does not seem to be any other option at the moment if I want to use Neo4j. Then, I am trying to see which of the above encoding might fit better in my queries (queries are the core of my system). For doing so, I need to resort to examples. So I have two question:
First Question:
part1) I have nodes labeled as Person and father, and there are arrows between them like Person<-[:sr]-father-[:tr]->Person in order to model who is father of who (tr is father of sr). For a given person p1 how can I get all of his ancestors.
part2) If I had Person-[:sr]->father-[:tr]->Person structure instead, for modeling father relationship, how the above same query would look like.
This is answered here when father is considered as a simple relationship (instead of being encoded as a node)
Second Question:
part1) I have nodes labeled as A nodes with the property p1 for each. I want to query A nodes, get those elements that p1<5, then create the following structure: for each a1 in the query result I create qa1<-[:sr]-isA-[:tr]->a1 such that isA and qa1 are nodes.
part2) What if I wanted to create qa1-[:sr]->isA-[:tr]->qa1 instead?
This question is answered here when isA is considered as a simple arrow (instead of being modeled as a node).
First, some terminology; relationships don't have labels, they only have types. And yes, one type per relationship.
Second, relative to modeling, I think the direction of the relationship isn't always super important, since with neo4j you can traverse it both ways easily. So the difference between A-->f-->B and A<--f-->B I think should be entirely driven what what makes sense semantically for your domain, nothing else. So your options (1) and (2) at the top seem the same to me in terms of overall complexity, which brings me to point #3:
Your main choice is between making a complex relationship into a node (which I think we're calling f here) or keeping it as a relationship. Making "a relationship into a node" is called reification and I think it's considered a fairly standard practice to accommodate a number of modeling issues. It does add complexity (over a simple relationship) but adds flexibility. That's a pretty standard engineering tradeoff everywhere.
So with all of that said, for your first question I wouldn't recommend an intermediate node at all. :father is a very simple relationship, and I don't see why you'd ever need more than one label on it. So for question one, I would pick "neither of the options you list" and would instead model it as (personA)-[:father]->(personB). More simple. You'd query that by saying
MATCH (personA { name: "Bob"})-[:father]->(bobsDad) RETURN bobsDad
Yes, you could model this as (personA)-[:sr]->(fatherhood)-[:tr]->(personB) but I don't see how this gains you much. As for the relationship direction, again it doesn't matter for performance or query, only for semantics of whatever :tr and :sr are supposed to mean.
I have nodes labeled as A nodes with the property p1 for each. I want
to query A nodes, get those elements that p1<5, then create the
following structure: for each a1 in the query result I create
qa1<-[:sr]-isA-[:tr]->a1 such that isA and qa1 are nodes.
That's this:
MATCH (aNode:A)
WHERE aNode.p1 < 5
WITH aNode
MATCH (qa1 { label: "some qa1 node" })
CREATE (qa1)<-[:sr]-(isA)-[:tr]->aNode;
Note that you'll need to adjust the criteria for qa1 and also specify something meaningful for isA.
What if I wanted to create qa1-[:sr]->isA-[:tr]->qa1 instead?
It should be trivial to modify that query above, just change the direction of the arrows, same query.
I am having a problem with "same individuals property" in protege, when I run a reasoner (pellet 1.5 or fact++)
Lets take ontology example
thing has class sons A and B, A has sons C and D.
B, C and D have individuals of the same class.
Can't I say a individual C is "same individual" as individual B, and then add also individual D is "same individual" as individual B? Which is true, they have different names, but they are same individual.
Why does it only work when I set individual B has "same individual" of type C or D?
The protege error is "InconsistentOntologyException:Fact++.Kernel: inconsistent Ontology" and pellet says ontology is inconsistent.
EDIT: Seems its a more deep rooted problem, this example works, going to keep checking.
EDIT2: After some more experimenting, seems its a conflict with DataType properties.
They all share a DataType properties with same name. In the example domain of property would be A and range string. Any idea how to solve?
Yeah you solved it - you were confusing labels (what you call things) with identity: an instance of a class is unique (you can attach different labels to it - i.e. call it different things) but the instance itself can only exist once - and in your example you effectively asserted that there are "three instances of the same instance"...which, of course, doesn't make any sense.