I am creating an ERD model that is for incoming packages and who receives them. Since it would be useful to know who accepted the package and who the package is intended for my thought was to add an employee table and then an accepter table (who accepted the package) and an orderer table (who ordered the package). My problem is thinking out the relationships. Because the orderer table would draw from the Employee table I need to figure out what relationship they are, but all I am coming up with is a 1:1 relationship.
Each employee can be one orderer.
Each orderer is one employee.
I am struggling to understand if there is just a major flaw in my thinking or if I am just approaching the problem wrong. Any guidance would be greatly appreciated.
Related
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! ;)
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.
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.
My dbml file is just getting bigger and bigger and more unwieldy:
I favoured an all-in-one approach as supposed to multiple data contexts because when I tried that it was near impossible to manage in code. I was advised it was better to have them all in one chart and the difficulty will be simply in managing this chart and not in code.
The chart I've got is becoming a pain to manage, if I want to even remove a table and re-add it it sometimes takes a little while to manually find it! There isn't even a list I can find in VS2010 of the objects you have in that chart!
Is there a better way of doing this?
Generally speaking, group tables related to the same concept in the same diagram, and create multiple diagrams, yes that means you have to MANAGE each diagram; but generally this is a GOOD thing. Here's why... Same database schema, different diagrams. Each diagram representing a specific subset of business. So product catalog section, an order section, a biling section, a returns section, a sales section.. etc.. Just make sure it groups up to a specific line of business. Yes this does mean that tables will be repeated on different diagrams
By segmenting the table structure into business logic groupings, you can quickly see all related tables to that groping. This is helpful to developers as they have to work in those specific sections; they understand the scope of work with out having to understand the entire database structure. When making a change, if you find a table is on multiple groupings/diagrams you can see what areas of the business are impacted by the change. This gives you an idea of the areas of the application which need to be tested and at a minimum considered when your making a change to the database structures. Ideally this type of modeling would be implemented in relation to services offered in a Service Management style of architecture. However starting to group your tables into business processes would help. IF you think this is unwieldy... try looking at an oracle db that has over 1500 tables in its schema.
The overall trick here is to only show those tables/views related to the business process/service someone would NEED to look at to support the system.
Good luck!
I got a weird H.W assignment in requirements engineering seminar .
I was digging through the entire net yet found no example for this one...
I need to find a problem from any engineering field (mechanics,medicine,chemistry,programming etc.) that the ERD model fails to give a complete/any answer to.
Can anyone show me some examples of a loss of information/process/entity while modeling only in ERD ?
maybe a point where I will need to compromise in order to continue modeling?
Or at least what are ERD's limitations ?
I need it to be an example for the limitation/disadvantage and not an example for a common mistake or bad modeling.
Well, ERD only deals with static aspects of the problem (i.e. the structure of the data that needs to be manipulated). All the information about the dynamic aspects of the problem will be lost if you only model using ERD