I am a little confused on the multiple value entity.Please help me to clarify it.
I have a example like this :
There are many categories of artworks based on their ‘true type’. There are three main types: (i) painting; (ii) sculpture; (iii) statue. Any artworks that cannot be classified in these three main types will be identified as ‘other’.
So, can I group 3 main type "painting","sculpture","statue" by entity "Type" ? if they are in 1 group, how about type "other" ?
If i have to divide these types in many entities ? can some on please tell me the solution.
Much appreciate for your reply
In the Extended ER (EER) model, the terms specialization/generalization are the buzzwords that the describe the relationships between subtypes and supertypes. There are specific diagramming conventions for diagramming these kinds of relationships in EER diagrams.
Knowing how to diagram them isn't the same thing as knowing how to design tables to fit this kind of situation. You may want to look into single-table-inheritance and class-table-inheritance to see a couple of techniques that may apply to your case.
Related
I'm coding an application to create surveys with Symfony3 and Doctrine. I would like to understand which is the best way to model the relation between the survey, items, and answers. A survey is composed by multiple items that have peculiar typologies of answer. For instance I could have the following typologies:
AnswerChoice
AnswerText
AnswerRange
etc..
Which is the best way to model this scenario with Doctrine?
I thought 2 possible solutions:
I create a single Answer object including every possible feature of the answers. The Item object should have a one-to-one relationship with this objects.
Pros: I have just one answer object
Cons: Confusing and against the single responsibility principle
I create a generic Item object containing a specific Answer object (AnswerChoice, AnswerText...) in a predefined class property. The Survey object should have a one-to-many relationship with Item that in turn will have a one-to-one relationship with a specific Answer object;
Pros: Nice solution but...
Cons: I need a property for each type of answer!
Could you please help me to choice the best solution? I have the feeling that I'm not facing well this problem. Thanks
It's inheritance. Actually Doctrine handles inheritance pretty well.
There are a few ways of implementing inheritance in Doctrine but I think, that in your case Single Table Inheritance is what you're looking for.
That way you will be able to get a repository for parent (abstract) answer,but you'll get instances of actual child types in return.
I want to generate a family tree using data i receive from a file. I wonder how I should start. I've seen various examples of peoples using unordered lists but the problem is that the marriage relationship is not displayed correctly. I'm referring to this tutorial: http://thecodeplayer.com/walkthrough/css3-family-tree . If possible I wanted to do it by myself not using any thirdparty libraries.
Do you guys have a idea about it?
The concept of 'family tree' is misleading as it must NOT use a tree! but a graph. then using a tree you will have by definition a root node to the tree and as you know it takes two to give life.
Now that we understand it should be a graph, the relation of each family should be two to many, as every family (married or not) has two parents and unknown number of children.
The question you need to ask yourself is how the data will be modeled and how do you want to display it.
I had to manage relationships between documents over a NoSQL engine (Couchbase), and I figured out this way to solve my problem. Here is my solution and the steps that let me realize it:
https://forums.couchbase.com/t/document-relationships-using-arrays-and-views-passing-though-graph-theory/3281
My questions are:
What do you think about this solution?
Have you ever used something like this? How is it working?
Are there any better ideas? Critical points of this solution should be helpful
Thank you.
Interesting post Matteo. After reading it I realized that you can possibly improve on few aspects:
Consider 1-1 node relationships. In your post you focus on N-N node
relationships (sure one can argue that 1-1 is a subset of
N-N)...however I think there is a potential of having a different (optimized) implememgtaion for 1-1 relationships. for 1-1 I use node key
value as a field in my json doc (e.g. user: {name:string, dob:date,
addressID:string})
Node key design to address relationships: You can encode in the key
value relationship information, e.g. key: "user#11", "user#11#address#123", "address#123#user#11", etc.
Data integrity aspects: Take into consideration missing complex
transactions. i.e. you can't mutate several documents in one
transaction. The design should compensate for that.
I have used similar solution in my model design for Couchbase in the past. Its now in production for several years already and its performing just fine (load is about 250 tps)...I was trying to avoid as much as possible creating complex node relations and ended up having very few 1-1 and 1-N types.
I tested out this solutions and works well. I like the flexibility of the 'always possible' N-N relationships, because you can simply add the relationship document when you need it without changing the application logic. There is a drawback: you need to implement your own application logic constraints to avoid relationships abuse.
I noticed that using arrays there isn't a great advantage compared to JSON objects and sometimes it may be useful to have other relationships data, for example the weight (or cost) of the relationship. So I suggest you to use a relationship document that as it's own type:
{
"type": "relationship",
"documents": ["key1", "key2"],
"all-the-data-you-need": { ... }
}
Looking at the performance there isn't so much difference using objects over arrays.
Hope this helps someone! ;)
In my semester exams I got a question:
Draw class diagram and association diagram for the online booking of movie tickets.
I know how to draw class diagrams so I drew it, but I was confused regarding association diagrams.I took a chance and drew a diagram with my vague understanding.I only drew class boxes and showed associations between them while drawing association diagram,while in class diagram I showed all the relationships like aggregation,composition,inheritance etc.I don't know whether i was right or wrong because when I googled it I found nothing but the examples of class diagrams only.
I would appreciate deeply if anyone alleviate my confusion.thank you!
So, again after a long wait , I am going to answer my question and since it was me only who asked this, suggestions are welcome from the deep bottom of my heart.
Now , so far what I have concluded is that ( obviously after searching many a times on net ) there is nothing specific like Association diagram as such (I am darned of my university for asking question in this way) . If there is anything after all its the association relationships among classifiers which can be otherwise shown as a "association diagram*. So, here is the minute difference which I could make out :
CLASS DIAGRAMS:- Class diagram is basically a detailed one showing classes, their interfaces , attributes and also their relationships. As for example :
While in "association diagrams" ( I am considering for now it as association diagram), classes' attributes and their internal implementation is not given much importance ,all that is shown, is the type of relationships among them.As for example :-
NOTE-- Any kind person who finds any more relevant information regarding this topic, please put suggestions in the comments so that I can edit my answer, for better. Any one is also free to edit my post if he or she feels its right.
I'm currently working on a project that involves moving a database of documents for court records and briefs over to a Drupal environment. One of the problems that we are faced with is how to index these documents.
In our court district, records and briefs all have a docket number which is assigned to a case. The interesting thing is that when multiple cases merge the docket numbers associated to the case become synonymous:
Case 1, documents have Doceket No. A
Case 2, documents have Docket No. B
If case Cases 1 and Case 2 merge, then Docket No. A = Docket No. B
My first inclination is to create a Docket Vocabulary and have the terms of this Taxonomy be the docket numbers. I am hoping to take advantage of the fact that terms can be synonymous.
I understand that there are several functions in the Taxonomy module that I may be able to take advantage of, including:
taxonomy_get_synonyms
taxonomy_get_related
But I'm having problems convincing my colleagues that this is the way to go, and frankly I'm not certain it's the right solution either. (Though one advantage I think is likely is that using Taxonomy in this way means we could take advantage of other taxonomy manipulating modules down the line).
If anyone has had a similar issue and can offer some guidance as to how to move forward, I would greatly appreciate it.
Thanks!
D
I've asked a related question (which I would also need to answer in order to move forward with this solution):
Can Drupal terms in different Taxonomies be synonymous?
This is a case for CCK. The Integer field type, most likely. If the dockets merge, edit the node, change the number. Revision history is tracked.
If you want to get fancy with the Docket Merging procedure, you will want to learn
How to create a custom Action.
How to use the Views Bulk Operations module.
Possibly, how to programmatically invoke the Bulk Operation via Rules.
It is a complex, but not difficult task, meaning there's a bunch to learn, but after that it shouldn't take long.
Trying to use the taxonomy module (and it's related counterparts) to force this behavior is just not a good idea.
Taxonomies are intend to bring some form of order and meaning to the content.
A vocabulary of thousands of terms that consists of numbers is just not a taxonomy.
When I took a closer look at the taxonomy module code, I decided that although I could probably force the behavior I'm seeking, taxonomies are not intended to be used to solve problems of this nature.
Also, the use of taxonomy_get_synonym as proposed in my question is plain wrong. Taking a look at the table were synonym relationships are kept in drupal-6 we see that that synonyms are not terms.
Though, there is the possibility of coming up with a similar solution using the related terms, this would be foolhardy.