I have an entity employees with six attributes: employee_number (unique key), first_name, last_name, address, phone_number, and hire_date. However, there are two types of employees: "Service Technicians" and "Sales Associates".
Each distinct type of employee has "job specific" attributes. Service technicians have model_expertise and pager_number attributes, and Sales associates have commission and salary attributes.
I'm not sure how to represent this in an ER diagram. I have an employees entity with the attributes listed, is it possible to have a relationship from employees to both technicians and associates? A relationship like is_type: can a relationship link one entity to two entities like this?
If not, how else?
You've got a classic subtype/supertype relationship. The original ER notation had no specific symbols for this situation, though one could represent subtypes as weak entities without a weak key. A number of extensions to the ER model were developed to address this. Here's one example:
The d in the circle indicates disjoint subtypes, meaning an Employee can be either a Technician or an Associate, but not both. The other option is o for overlapping.
However, don't confuse your supertype/subtype relationships with a 3-way relationship. Rather, it's better viewed as 2 binary relationships, with disjointness being a mutual constraint. True 3-way (and higher) relationships (e.g. a many-to-many-to-many association among suppliers, parts and regions) are certainly possible in ER diagrams. It's one of the features that distinguish the ER model from the older network data model.
Related
We had a discussion today related to W3 lecture case study about how many entities we need for each situation. And I have some confusion as below:
Case 1) An employee is assigned to be a member of a team. A team with more than 5 members will have a team leader. The members of the team elect the team leader. List the entity(s) which you can identify in the above statement? In this cases, if we don't create 2 entities for above requirement, we need to add two more attributes for each employee which can lead to anomaly issues later. Therefore, we need to have 2 entities as below:
EMPLOYEE (PK is employeeId) (0-M)----------------(0-1) TEAM (PK teamId&employeeId) -> 2 entities
Case 2) The company also introduced a mentoring program, whereby a new employee will be paired with someone who has been in the company longer." How many entity/ies do you need to model the mentoring program?
The Answer from Lecturer is 1. With that, we have to add 2 more attributes for each Employee, mentorRole (Mentor or Mentee) and pairNo (to distinguish between different pairs and to know who mentors whom), doesn't it?
My question is why can't we create a new Entity named MENTORING which will be similar to TEAM in Q1? And why we can only do that if this is a many-many relationship?
EMPLOYEE (PK is employeeId) (0-M)----------------(0-1) TEAM (PK is pairNo&employeeId) -> 2 entities
Thank you in advance
First of all, about terminology: I use entity to mean an individual person, thing or event. You and I are two distinct entities, but since we're both members of StackOverflow, we're part of the same entity set. Entity sets are contrasted with value sets in the ER model, while the relational model has no such distinction.
While you're right about the number of entity sets, there's some issues with your implementation. TEAM's PK shouldn't be teamId, employeeId, it should be only teamId. The EMPLOYEE table should have a teamId foreign key (not part of the PK) to indicate team membership. The employeeId column in the TEAM table could be used to represent the team leader and is dependent on the teamId (since each team can have only one leader at most).
With only one entity set, we would probably represent team membership and leadership as:
EMPLOYEE(employeeId PK, team, leader)
where team is some team name or number which has to be the same for team members, and leader is a true/false column to indicate whether the employee in that row is the leader of his/her team. A problem with this model is that we can't ensure that a team has only one leader.
Again, there's some issues with the implementation. I don't see the need to identify pairs apart from the employees involved, and having a mentorRole (mentor or mentee) indicates that the association will be recorded for both mentor and mentee. This is redundant and creates an opportunity for inconsistency. If the goal was to represent a one-to-one relationship, there are better ways. I suggest a separate table MENTORING(menteeEmployeeId PK, mentorEmployeeId UQ) (or possibly a unique but nullable mentorEmployeeId in the EMPLOYEE table, depending on how your DBMS handles nulls in unique indexes).
The difference between the two cases is that teams can have any number of members and one leader, which is most effectively implemented by identifying teams separately from employees, whereas mentorship is a simpler association that is sufficiently identified by either of the two people involved (provided you consistently use the same role as identifier). You could create a separate entity set for mentoring, with relationships to the employees involved - it might look like my MENTORING table but with an additional surrogate key as PK, but there's no need for the extra identifier.
And why we can only do that if this is a many-many relationship?
What do you mean? Your examples don't contain a many-to-many relationship and we don't create additional entity sets for many-to-many relationships. If you're thinking of so-called "bridge" tables, you've got some concepts mixed up. Entity sets aren't tables. An entity set is a set of values, a table represents a relation over one or more sets of values. In Chen's original method, all relationships were represented in separate tables. It's just that we've gotten used to denormalizing simple one-to-one and one-to-many relationships into the same tables as entity attributes, but we can't do the same for many-to-many binary relationships or ternary and higher relationships in general.
Have a simple question, but I think I am overthinking it. I need to make an E/R diagram out of this:
Substantial fees are due every calendar year. Fee payments must be
made via a bank transfer, mentioning the member number and the
membership year it applies to. The database should store the date of
payment.
I am ignoring calendar year, as I think it is not relevant for the E/R diagram. I have an entity called "Members" which I like to "Fee" via *"payed via the relationship (diamond symbol) a bank transfer"*.
Now, my question is: should "member number" and "membership" be part of the "fee" entity or the "member" entity? Or both? Because I am thinking to add a new relationship to "fee" giving it the name "consists of" and then link "member number" and "membership", but I don't know whether that's good or not.
And what to do with the last sentence? "The database should store the date of payment."? Can I ignore it?
From your description I got:
You have entity sets Members and Payments
Members are identified by a member_number
Payments have attributes date, amount and membership_year
Obviously, we also need:
Payments have an attribute amount
How are we going to identify Payments? No combination of the listed attributes are uniquely identifying in my opinion. A Member could make two identical Payments on the same date with the same amount, for the same membership year, e.g. if they accidentally only paid half of the annual fee at first then made a second payment to correct.
Let's introduce a surrogate key:
Payments are identified by a payment_id
We also need a relationship between the two entity sets:
Each Payment is associated with a single Member
Each Member can make multiple Payments
We can put this info into an ER diagram:
To derive a table diagram, Chen's original method implemented every entity relation (entity key and attributes) and relationship relation (relationship keys (i.e. related entity keys) and relationship attributes) as separate tables:
However, it's common practice to denormalize tables with the same primary key:
I recommend you study Chen's paper The Entity-Relationship Model - Toward a Unified View of Data. Codd's paper A Relational Model of Data for Large Shared Databanks provides valuable background.
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.
let me know what categorization is in database and what role of it is ...
i got it from a site, i do not understand...
Categorisation is a process of modelling of a single subtype (or subclass) with a relationship that involves more than one distinct supertype (or superclass). Till now all the relationships that have been discussed, are a single distinct supertype. However, there could be need for modelling a single supertype/subtype relationship with more than one supertype, where the supertypes represent different entity set.
thanks!
https://books.google.co.uk/books?id=9m382yDgxRsC&pg=PA287&lpg=PA287&dq=7.4.+Categorisation+Categorisation+is+a+process+of+modelling+of+a+single+subtype+(or+subclass)+with+a+relationship+that+involves+more+than+one+distinct+supertype+(or+superclass).&source=bl&ots=7JFawUEg3d&sig=peeXz5QajJFdkFHw0TzlvQFwix8&hl=ko&sa=X&ved=0ahUKEwi1u8iHwIHSAhWMVhQKHfr_AkkQ6AEIIDAA#v=onepage&q=7.4.%20Categorisation%20Categorisation%20is%20a%20process%20of%20modelling%20of%20a%20single%20subtype%20(or%20subclass)%20with%20a%20relationship%20that%20involves%20more%20than%20one%20distinct%20supertype%20(or%20superclass).&f=false
As I understand, formally categorization is a process of creating of a relation (category) that contains tupels that are a subset of the union of the tupels of the superclasses. The tupels for that subset are chosen based on certain characteristic. Consider an example:
Lets say, we have Suppliers(id, name, address, email, bank_acct, paypal, ... etc.) relation and Customers(ssn, name, faname, email, address, paypal, ... etc.) relation. So, we could create another relation featuring only those parties (both suppliers and customers) who have paypal accounts - Paypal_account_holders(id, name, address, paypal_acct, email ... etc.) where Paypal_account_holders.id is surrogate primary key for Paypal_account_holders and foreign key to both Suppliers.paypal and Customers.paypal.
Motivation and advantages:
Universal interface for applications;
Security. Restricted access to tables when you allow users to access only
some part of information;
Simplified queries;
Enforcing some business rules for certain category;
etc.
Again, that's how I understand it.
There are couples of questions around asking for difference / explanation on identifying and non-identifying relationship in relationship database.
My question is, can you think of a simpler term for these jargons? I understand that technical terms have to be specific and unambiguous though. But having an 'alternative name' might help students relate more easily to the concept behind.
We actually want to use a more layman term in our own database modeling tool, so that first-time users without much computer science background could learn faster.
cheers!
I often see child table or dependent table used as a lay term. You could use either of those terms for a table with an identifying relationship
Then say a referencing table is a table with a non-identifying relationship.
For example, PhoneNumbers is a child of Users, because a phone number has an identifying relationship with its user (i.e. the primary key of PhoneNumbers includes a foreign key to the primary key of Users).
Whereas the Users table has a state column that is a foreign key to the States table, making it a non-identifying relationship. So you could say Users references States, but is not a child of it per se.
I think belongs to would be a good name for the identifying relationship.
A "weak entity type" does not have its own key, just a "partial key", so each entity instance of this weak entity type has to belong to some other entity instance so it can be identified, and this is an "identifying relationship". For example, a landlord could have a database with apartments and rooms. A room can be called kitchen or bathroom, and while that name is unique within an apartment, there will be many rooms in the database with the name kitchen, so it is just a partial key. To uniquely identify a room in the database, you need to say that it is the kitchen in this particular apartment. In other words, the rooms belong to apartments.
I'm going to recommend the term "weak entity" from ER modeling.
Some modelers conceptualize the subject matter as being made up of entities and relationships among entities. This gives rise to Entity-Relationship Modeling (ER Modeling). An attribute can be tied to an entity or a relationship, and values stored in the database are instances of attributes.
If you do ER modeling, there is a kind of entity called a "weak entity". Part of the identity of a weak entity is the identity of a stronger entity, to which the weak one belongs.
An example might be an order in an order processing system. Orders are made up of line items, and each line item contains a product-id, a unit-price, and a quantity. But line items don't have an identifying number across all orders. Instead, a line item is identified by {item number, order number}. In other words, a line item can't exist unless it's part of exactly one order. Item number 1 is the first item in whatever order it belongs to, but you need both numbers to identify an item.
It's easy to turn an ER model into a relational model. It's also easy for people who are experts in the data but know nothing about databases to get used to an ER model of the data they understand.
There are other modelers who argue vehemently against the need for ER modeling. I'm not one of them.
Nothing, absolutely nothing in the kind of modeling where one encounters things such as "relationships" (ER, I presume) is "technical", "precise" or "unambiguous". Nor can it be.
A) ER modeling is always and by necessity informal, because it can never be sufficient to capture/express the entire definition of a database.
B) There are so many different ER dialects out there that it is just impossible for all of them to use exactly the same terms with exactly the same meaning. Recently, I even discovered that some UK university that teaches ER modeling, uses the term "entity subtype" for the very same thing that I always used to name "entity supertype", and vice-versa !
One could use connection.
You have Connection between two tables, where the IDs are the same.
That type of thing.
how about
Association
Link
Correlation