So I have some question about the association, aggregation and composition in UML diagram. Here is some scenarios :
Product review rating composition to product review. This means that for each product review rating MUST HAVE product review? If product review doesn't exist, rating for review doesn't make sense.
Customer NRIC associate to cart and order. We cannot use aggregation because if customer does not exist, cart and order cannot exist also.
Can somebody please help me check if my relationships are correct? Is it good to link all your tables with association because I kind of confused on aggregation and association. I do not know when to use that.
Correct me if I am wrong. Thanks in advance.
Take a look at this class diagram example for composition:
Composition declares an ownership associationship. Person owns Leg and Hand. Or other way around, Hand belongs to Person.
Now ask yourself how would you describe each relationship in your model. If you would say Product review rate owns a Product review or Product review belongs to a Product review rate, then your diagram is OK. If the ownership has the opposite direction (Product review rate belongs to Product review, then the diamond must go to the other side of the association.
The same thing applies to aggregation. If the association somehow declares an ownership, then the diamond must go to the side of the owner class.
The difference between aggregation and composition is that objects owned as composites can't be created without their owner, so usually they are created by their owner. These objects are destroyed when their owner is destroyed, they couldn't be used by another owner after their owner dies. Objects owned by an aggregation association can be created without their owner and possibly could outlive him and serve another owner.
Related
I have the following ER diagrams:
customer starts a transaction with account
Bank updates watch_list
I'm new to ER diagram and I want to add an alert system in banking process. Customer entity can start a transaction with his/her bank account in transact_with relationship. In the relationship, there are attributes such as counterpart_name and counterpart_country. If counterpart's name in remittance is the same as the name from watch_list the bank is keeping, the DB creates a new row in the table named Alert. And I wonder how can I establish that Alert entity and relationships between other entities.
Since counterpart_name is a attribute from a relationship, if I want to relate that attribute with watch_list entity, it seems like it becomes ternary relationship but I don't want watch_list to be related with customer and account entity in normal transaction process. Any suggestions on this, please?
ERD won't help you because it doesn't capture rules. See here: https://en.wikipedia.org/wiki/Entity%E2%80%93relationship_model
Of course, if you want to create an ALERT table, then ERD is fine.
The "if" part which fires a trigger (or whatever) could be modeled by a UML sequence diagram (for example).
Put another way, the ALERT table is data, the "if" is control and they are served by different diagram types. Good luck
You can and should relate the ALERT entity with the entity WATCH_LIST and TRANSACT_WITH:
If these relationships would not exist, you would know to which watch list element the transaction is related, and use the score mentioned on the watchlist. Moreover, what's the benefit of having alerts, if not knowing which transaction must be inspected/monitored?
The fact that the ALERT is not systematic but conditional, can be documented with an optional relationship.
The matching of the transaction with the watchlist is based on some criteria, but the relationship with the alert would be based on the id.
The ER diagrams show the structure of the entities and the relationships. They do not describe the processes or the behaviors. Typically, with an ERD, you'd use some DFD to explain what data is consumed by the monitoring process that would generate the ALERT records. And the IF would be documented in the flowchart or pseudocode that documents this process. On the other side, nothing prevents you from informally documenting this informally in a comment within your ERD.
Unrelated remarks:
As you have lots of attributes on the relation TRANSACT_WITH, and since a relation is not supposed to have attributes, I understand that it is in reality an associative entity.
The matching of the watchlist solely on the base of the name (without even considering the country) might lead to a high number of false positives.
UML would allow to constraint the ER-relationship (UML-association) with ER-entity (UML-Class) ALERT, and express the conditionality in a very precise manner.
First I'll explain the statement of diagram and after that I will explain my problem and I'll attach my actual diagram.
I should make an ER diagram about the following statement:
Perform the design and implementation of a database to store information about patients admitted to a hospital, patients can be adults or children. In the case of children we save information from who their parents who in turn can also be patient. In this hospital, patients arriving at the emergency department of the hospital are examined by a doctor and, depending on their health status, are entered in the corresponding plant (traumatology, intensive care...) under the supervision of a nurse.
Each patient receives a treatment that must be stored
Well, I design the following diagram; but my main problem is how to make the relation between fathers that can be patients. I decided put all fathers as patients and don't represent adults as entity, I have considered them implicit into patient's entity. But I'm not very sure about the validity of my solution.
I'd be grateful if someone can help me with my doubt.
How about subtyping patient from person and then creating a relationship from patients who are children to their parent persons? In this way, not every person need to be a patient but parents can be patients too. The relationship between parent and child indicates the role of each so there's no need to specifically subtype patients into parents or children.
Note also that your Doctors can currently only examine one patient.
Considering that this community has questions related to modeling databases, I am here seeking help.
I'm developing an auction system based on another one seen in a book I'm reading, and I'm having trouble. The problem context is the following:
In the auction system, a user makes product announcements (he/she defines a product). It defines
the product name, and the initial offer (called initial bid). The initial bid expresses the minimum amount to be offering. A
product only exists in the database when it is announced by a user. A
user defines a number of products, but a product belongs to a single
user.
Every product has an expiration date. When a certain date arrives, if
there are no offers for the product, it is not sold. If there are
offers for the product, the highest bidder wins the given product.
The offers have a creation date, and the amount offered. An offer is
made to a product from a user. A user can make different offers for
different products. A product can be offered by different users. The
same user can not do more than two offers for the same product.
This kind of context for me is easy to do. The problem is that I need to store a purchase. (I'm sorry, but I do not know if the word is that in English). I need a way to know which offer was successful, and actually "bought" a product. Relative to what was said, part of my Conceptual Model (Entity Relationship Diagram) is as follows:
I've tried to aggregate USERS with PRODUCTS, and make a connection/relationship between the aggregation and PRODUCTS, which would give me the PURCHASES event. When this was broken down (decomposed) I would have a table showing which offer bought what product.
Nevertheless, I would have a cardinality problem. This table would have two foreign keys. One for BIDS, and the other for PRODUCTS. This would allow an N-N relationship of these two, meaning that I could save more than one bid as the buyer of a product, or that the same bid could "buy" many products (so I say in the resulting PURCHASES table).
Am I not seeing something here? Can you guys help me with this? Thank you for reading, for your time, and patience. And if you need some more detail, please do not hesitate to ask.
EDIT
The property "Initial Bid" on the PRODUCTS entity is not a relationship.
This property represents a monetary value, a minimum amount that an offer must have to be given to a particular product.
You are approaching things backwards. First we determine a relevant application relationship, then we determine its properties. Given an application relationship and the possible application situations that can arise, only certain relationship/association sets/tables can arise. A purchase can have only one bid per product and one product per bid. So it is just a fact that the bid:product cardinality of PURCHASES is 1:1. Say so. This is so regardless of what other application relationships you wish to record. If it were a different application relationship between those entities then the cardinality might be different. Wait--USERS_PRODUCTS and BIDS form exactly such a pair of appplication relationships, with user:product being 1:0..N for the former and 0..N:0..N for the latter. Cardinality for each participant reflects (is a property of) the particular application relationship that a diamond represents.
Similarly: Foreign keys are properties of pairs of relationship/association sets/tables. Declaring them tells the DBMS to enforce that participant id values appear in entity sets/tables. Ie {bid} referencing BIDS and {product} referencing PRODUCTS. And candidate keys (of which one can be a primary key) are a property of a relationship set/table. It is the candidate keys of PURCHASES that lead to declaration of a constraint that enforces its cardinality. It isn't many:many on bid:product because "bid BID purchased product PRODUCT at price $AMOUNT on date DATE" isn't many:many on bid:product. Since either its bid or its product uniquely identify a purchase both {bid} and {product} are candidate keys.
Well... I tried to follow the given advices, and also tried to follow what I had previously spoken to do, using aggregation. It seems to me that the result is correct. Please observe:
Of course, a user makes offers for products. A user record can relate to multiple records in PRODUCTS. Likewise, a product can be offered by multiple users, and thus, a record in PRODUCTS can relate to multiple records on USERS. If I'm wrong on this, please correct me.
Looking at purchase, we see that a product is only properly purchased by a single bid. There is no way to say that a user buys a product, or a product purchase itself. It is through the relationship between USERS and PRODUCTS that an bid is created, and it is an bid that is able to buy a product. Thus, it is necessary to aggregate such a relationship, then set the purchase event.
We must remember that only one product can be purchased for a single bid. So here we have a cardinality of 1 to 1. Decomposition here will ask discretion of the data modeler.
By decomposing this Conceptual Model, we will have the following Logic Model:
Notice how relationships are respected with appropriate attributes. We can know who announced a product (the seller), and we can know what offers were made to it.
Now, as I said before, there is the PURCHASES relationship. As we have a relationship of 1 to 1 here, the rule tells us that we must choose which side the relationship will be interpreted (which entity shall keep such a relationship).
It is usually recommended to keep the relationship on the side that is likely in the future to become a "many". There is no need to do so in this case because it is clear that this relationship can not be preserved in a BIDS record. Therefore, we maintain such a relationship portrayed by "Winner Bid" on the PRODUCTS entity. As you can see, I set a unique identifier for BIDS. By defining the Physical Model, we have a surrogate key.
Well, I finish my answer here, but I think I can not consider it right yet. I would like someone to comment anything if possible. Thank you.
EDIT
I'd like to apologize. It seems that there was a mistake on my part. Well, I currently live in Brazil, and here we learn the ER-Diagram in a way that seems to me to be different from what many of you are used to. Until yesterday I've been answering some questions related to the subject here in the community, and I found odd certain different notations used. Only now I'm noticing that we are not speaking the same language. I believe it was embarrassing for me in a way. I'm sorry. Really, I'm sorry.
Oh, and one more thing (it may be interesting for someone):
The cardinality between BIDS and PRODUCTS is really wrong. It should
be 0 to 1 in both, as was said in the comments.
There are no relationships relating with relationships here. We have
what is called here (in my country, or in my past course)
"Aggregation" (Represented in the first drawing by the rectangle with clipped lines). The internal relationship (BIDS) when decomposed will
become an entity, and the relationship between BIDS and PRODUCTS is
made later. An aggregation says that a relationship needs to be resolved first so that it can relate with another entity. This creates a certain restriction, which may be necessary in certain business rules. It says that the joining of two entities define records that relate to records of another entity.
Certain relationships do not necessarily need to be named. Once you
break down certain types of relationships, there is no need (it's
optional) to name them (between relations N to N), especially if new
relationship does not arise from these. Of course, if I were to name the white relationships presented, we then would have USER'S BIDS (between USERS and BIDS), and PRODUCT'S BIDS (between BIDS and PRODUCTS).
With respect to my study material, it's all in portuguese, and I believe you will not understand, I do not know. But here's one of the books I read during my past classes:
ISBN: 978-85-365-0252-6
Title: PROJETO de BANCO de DADOS Uma Visão Prática
Authors: Felipe Machado, Mauricio Abreu
Publishing company: EDITORA ÉRICA
COVER:
LINK:
http://www.editorasaraiva.com.br/produtos/show/isbn:9788536502526/titulo:projeto-de-banco-de-dados-uma-visao-pratica-edicao-revisada-e-atualizada/
Well... What do I do now? Haha... I do not know what to do. I'll leave my question here. If someone with the same method that I can help me, I'll be grateful. Thank you.
To record the winning bid requires a functional dependency Product ID -> Bid ID. This could be implemented as one or more nullable columns (since not all products have been purchased yet) in the Products table, or better in a separate table (Purchases) using Product ID as primary key.
I have three tables: user, friend and family.
User is entity.
Friend is relationship.
Family is relationship.
However, if I would like to set privacy level which can control who can view my full information. i.e. Only friend can see my hobbies, and only family can see my current location.
I don't know how I can implement this on ER design.
Option 1:
User{
attribute 1: ID;
[other attributes]
}
Friend{
Attribute 1: FriendID;
}
Family{
Attribute 1: family ID;
}
How can I meet the requirements? Still confused about it. Anyone has a rational solution ?
ER diagrams are really a seperate issue from security. ER diagrams just state what exists and how it is realated.
The best place for this kind of secuiry is in the model. When you someone asks for your current location, check if they are your family, etc...
This is especially true since current location is likely to be calculated from GPS, not stored as an entity in the database. If it is, you could potentially include a forign key from current location to familyID that would tie these together.
If this doesn't make sense, please provide more details on hobbies and current location.
I am trying to wrap my head around Entity Groups in Google AppEngine. I understand them in general, but since it sounds like you can not change the relationships once the object is created AND I have a big data migration to do, I want to try to get it right the first time.
I am making an Art site where members can sign up as regular a regular Member or as one of a handful of non-polymorphic Entity "types" (Artist, Venue, Organization, ArtistRepresentative, etc). Artists, for example can have Artwork, which can in turn have other Relationships (Gallery, Media, etc). All these things are connected via References and I understand that you don't need Entity Groups to merely do References. However, some of the References NEED to exist, which is why I am looking at Entity Groups.
From the docs:
"A good rule of thumb for entity groups is that they should be about the size of a single user's worth of data or smaller."
That said, I have a couple hopefully yes/no questions.
Question 0: I gather you don't need Entity Groups just to do transactions. However, since Entity Groups are stored in the same region of Big Table, this helps cut down on consistency issues and race conditions. Is this a fair look at Entity Groups and Transactions together?
Question 1: When a child Entity is saved, do any parent objects get implicitly accessed/saved? i.e. If I set up an Entity Group with path Member/Artist/Artwork, if I save an Artwork object, do the Member and Artist objects get updated/accessed? I would think not, but I am just making sure.
Question 2: If the answer to Question 1 is yes, does the accessing/updating only travel up the path and not affect other children. i.e. If I update Artwork, no other Artwork child of Member is updated.
Question 3: Assuming it is very important that the Member and its associated account type entity exist when a user signs up and that only the user will be updating its Member and associated account type Entity, does it make sense to put these in Entity Groups together?
i.e. Member/Artist, Member/Organization, Member/Venue.
Similarly, assuming only the user will be able to update the Artwork entities, does it make sense to include those as well? Note: Media/Gallery/etc which are references to Artwork may be related to lots of Artwork, not just those owned by the user (i.e. many to many relations).
It makes sense to have all the user's bits in an entity group if it works the way I suspect (i.e. Q1/Q2 are "no"), since they will all be in the same region of BigTable. However, adding the Artwork to the entity group seems like it might violate the "keep it small" principal and honestly, may not need to be in Transactions aside from saving bandwidth/retrys when users are uploading artwork images.
Any thoughts? Am I approaching Entity Groups wrong?
0: You do need entity groups for transactions among multiple entities
1: Modifying/accessing children does not modify/access a parent
2: N/A
3: Sounds reasonable. My feeling is, entity groups should not be used unless you need transactions among them.
It is not necessary to have the the Artwork as a child for permission purposes. But if you need transactional modification to them (including e.g. creation and deletion) it might be better. For example: if you delete an account, you delete the user entity but before you delete the child, you get DeadlineExceeded or the server crashes. Now you have an orphaned Artwork. If you have more than 1,000 Artworks for an Artist, you must delete in batches.
Good luck!