What i know about weak entity is that they cannot exist without strong entity:-
i.e there must be a strong entity from which key(foreign key) has to be taken by weak entity.
example : a HOTEL(strong entity) and ROOM(weak entity),
HOTEL is strong entity because they can have their existence by their own (independently) while ROOM is weak entity as they always need HOTEL without it (HOTEL) room cannot exists.
But while reading book i came across a statement which states that "However not every existence dependency results in weak entity type ".For example a DRIVER_LICENCE entity cannot exist unless it is related to a PERSON entity ,even though it has its own key (licence_number) and hence it is not a weak entity .
My question is how an entity depending upon strong entity cannot be a weak entity?
Weak entities aren't defined as being dependent on another for existence, but as being dependent on another for identity.
Quoting from Peter Chen's 1976 paper "The Entity-Relationship Model - Toward a Unified View of Data":
...we have two forms of entity relations. If relationships are used
for identifying the entities, we shall call it a weak entity relation.
If relationships are not used for identifying the entities, we shall
call it a regular entity relation. Similarly, we also have two forms
of relationship relations. If all entities in the relationship are
identified by their own attribute values, we shall call it a regular
relationship relation. If some entities in the relationship are
identified by other relationships, we shall call it a weak
relationship relation. For example, any relationships between
DEPENDENT entities and other entities will result in weak relationship
relations, since a DEPENDENT entity is identified by its name and its
relationship with an EMPLOYEE entity. The distinction between regular
(entity/relationship) relations and weak (entity/relationship)
relations will be useful in maintaining data integrity.
Thus, an entity that is identified by its own attributes is called a regular entity, regardless of whether it can exist independently or only in relation to another entity.
An entity that is identified by its relationship with another entity is necessarily dependent on it for existence, but that argument doesn't work the other way around. If it rains, the ground is wet, but just because the ground is wet doesn't mean it rained.
Related
Weak entity with 2 owner entities
I have a database I am trying to design with 3 entities: Store, Item, and Wishlist. Stores and Wishlists exist on their own, and are therefore strong. Items, however, will not exist unless they are either in stock at a store or on someone's wishlist.
What's the best practice in designing the ER diagram ?
What you are describing is really two one-many relationships with an extra constraint on participation ("must be in stock or on a wishlist"). This does not mean that an Item is a weak entity type. I think Item in this case must be strong. I don't think there is any standard ER notation for a participation constraint across mutiple entities unless the entities are all subtypes. I suggest you add a text notation to the diagram if it's important to explain that an item must either be in stock or on a wishlist but doesn't have to be both.
It is sometimes said that a weak entity cannot exist independently of a related entity. That alone is not what makes something weak however. An entity type is weak if it does not have its own identifier independent of another entity type. In your situation I would expect that an item could appear on more than one wishlist or be stocked in more than one store and therefore items must have a common identifier (e.g. a name or a UPC) independently of the wishlists and stores that include them. If that was not the case then wishlist items and stock would presumably have to be subtypes of item, which seems a bit unconventional.
If for some reason you did want to treat items of stock and items on wishlists as subtypes of items then the answer to your question would be a subtype relationship with mandatory participation, e.g. represented with double lines using Chen notation:
can i relate an entity with three other entities(weak) over an identifying relationship. For example, an entity item is related to three other entities book_item,cd_item and magazine_item over a "is a" relationship.(book_item,cd_item and magazine_item are weak entities)is this possible ?
While subtyping can be represented as an identifying relationship without a weak key in classic ER diagrams, it's best to distinguish the concepts. A subtype is a subset, meaning identity isn't changed in the process. A subtype of a regular entity set is still regular, a subtype of a weak entity set is weak.
This is different from parent/child entity sets wherein children are identified via the parent identifier and a weak key. Weak children are a different entity set from their parents, whereas subtypes are a subset of the same entity set.
I suggest you use one of the subtyping notations of EER diagrams, and don't mix identifying/weak terminology with subtyping/supertyping, unless for an academic exercise in classic ER.
I am creating an ER diagram and relational schema for a school project. In my ER diagram, I have shown attributes like "street name" and "city" as weak attributes of another attribute "address." How would I convert this to a relational schema? Do weak attributes even appear in my relational schema?
Part of my ER Diagram
I prefer to call Billing Address a composite attribute, and City a component attribute.
The term "weak" is used in ER diagrams to describe entity sets that include another entity set's key as part of its own. For example, if an Invoice is identified by an Invoice_ID, and contains LineItems that are identified by Invoice_ID, Line_Number, that would make LineItem a weak entity set, and Line_Number would be its weak key.
When converting composite/component attributes to a relational schema, the simplest approach is to use only the component attributes. This means the composite attributes are nothing more than a visual aid.
Are there any weak entities. How can I identify an weak entity. If you do find a weak entity, could you please explain to me why it is a weak entity. How is it that you came to that conclusion? Please let me know.
Aggregation:
-Library
Entities:
-Resource
-Book
-Cubicle
-Loan application for book
-Books loaned
-Employee
-Contracted(Signs loan for books)
-Practicing(confirmes loan application for users online)
-Cubicle loan
-User(applies for book loan or cubicle loan)
-Penalty(given to user if they have books overdue)
A weak entity set is one that can't be identified by its own attributes. Weak entity sets are identified, at least partially, by their relationship with another entity set. This means that a weak entity set's primary key will contain a foreign key.
For example:
Invoice (invoice_id PK, ...)
LineItem (invoice_id FK/PK, line_number PK, ...)
In order to identify weak entity sets in your example, we need to know how your entity sets are identified. This is a design decision, not something inherent in any entity set. Any weak entity set can be converted into a regular entity set through the introduction of a surrogate key, which also converts the identifying relationship with its parent into a regular relationship. Thus, there's no way to know until you decide how to identify your entity sets.
Think about how you would identify each entity set. Books are often identified by ISBN numbers, which would count as its own attribute. How would you identify multiple copies of a book? Each could get its own serial number, or one could number the copies of each ISBN. That latter method indicates a weak entity set. How about cubicles? Does each cubicle have its own unique identity, or are they numbered relative to a specific room/floor/building/site/company? In the latter case, it may be a good idea to model it as a weak entity set. Book loans can be identified via a surrogate key or a combination of the book identifier and loan date. For each entity set, it's possible to imagine it as a regular or weak entity set.
I have this following database of a student portal project I am building. I'm new to databases but I know the concepts quite much. I wan't to ask that in my diagram should student be a weak entity as it depends on the department. If there is no department then there won't be any student to that department.
Apart from my main question I am a bit confused about the ATTENDANCE and GRADES Table. Have I related them correctly and are their attributes sufficient and correct ? I know I'm asking much but can you review my diagram and provide me suggestion to improve it even if it takes to make it from scratch.
Thanks.
Student doesn't need to be a weak entity set. While weak entity sets imply an existence dependency, existence dependencies don't imply weak entity sets. Total participation is possible for regular entity sets too.
Instead of looking at existence dependencies, look at identification. Weak entity sets can't be identified by their own attributes alone, they depend on a foreign key (usually in combination with a weak key) for identity. When an entity set has an independent identity like Roll ID (surrogate IDs are always independent), they're regular entities.
You seem to be confusing entity sets with tables, perhaps due to the mixed notation you're using. If I read your model correctly, Grades is a relationship between Student and Courses since it has a primary key that consists of two foreign keys. However, your diagram only links it to Student via an unnecessary has relationship.
You also have embedded relationships in your tables, e.g. Courses has a Department FK, but you didn't link the two in the diagram. Enrolls requires its own table, but you don't show one unlike for the other many-to-many relationships in your diagram.
Attendance, like Grades, represents a relationship between Student and Courses. You show an association with Department but don't indicate an FK. While in original ER notation we never indicate foreign keys as attributes, in your diagram this is inconsistent with most of the rest of your tables.
Edit:
Here's an example of how to represent Grades as a relationship between Student and Courses. I used original ER notation since I don't have a tool that implements your notation.
Attendance table should be linked to Course and Student not Department as shown.