Take person for example
Does the Person entity refer to Jon Doe as a single person or the people as a whole ?
For example in a table in a database, is there a Table which holds a set of entities or an Entity which holds some records ?
Apart from database, how about data modelling?
In the Entity Relationship model, entity refers to a thing which
can be distinctly identified. A specific person, company, or event is an example of an entity. A population of entities of the same type is called an entity set. When an entity set is identified and described via attributes, we get an entity relation, which can be represented as a table in a database.
Note that tables are also used to represent relationship relations, so it's not correct to equate tables with entity sets or relations. It's also not correct to equate a row with a single entity - rather, a row represents a fact about one or more entities.
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.
i am getting confused about the entity and entity set in DBMS.
do set of entities forms entity set? Just like set of Student Objects form Array of Students.
should we compare a Table in Relational database to entity set or entity?
If i compare entity set to table then can i compare entity as a record in table. If i am wrong please correct me.
I have gone through some books and blogs regarding this. some times entity is compared with table in Rdbms and some times with entity set. which is true. Not able to get proper explanation.
Pls come up with the examples and clear explanation, thanks in advance!!
There are various descriptions of the terms, and unfortunately blogs, tutorials, enterprise framework documentation and diagramming software tend to conflate the concepts. For more rigorous definitions, consult academic papers and books by the founders of the field.
An entity is a thing which can be distinctly identified, like a specific person, company, or event. Entities are identified by values in a database, e.g. I (an entity in the real world) am represented by the number 532721 in StackOverflow's database.
An entity set is a set of similar things, like a set of persons, companies or events. An example would be all the users on StackOverflow. Entities and entity sets are conceptual and not directly contained in databases. StackOverflow's database talks about its users, those users don't actually live in the database.
A table is a data structure which represents a predicate. A predicate is a fact type, a generic statement with placeholders for values. Records contain values for those placeholders that make the predicate true, thus records represent propositions about entities in the world. Another way to view it is that a table represents a set of attributes and relations on one or more entity sets. Remember attributes are just binary relations.
For example, a table USER (UserId PK, UserName UQ, Reputation, PhotoId UQ) can be understood as saying "There exists in the world a user identified by a number UserId and unique name UserName who has a score of Reputation points and exclusively uses the photo identified as PhotoId as avatar". Each corresponding record represents a known fact about a user and an image.
I recommend you read Codd's paper "A Relational Model of Data for Large Shared Data Banks" and Chen's paper "The Entity-Relationship Model - Toward a Unified View of Data". They're shorter and more focused than a whole book, and can be easily found online.
Can someone tell me the easy way to explain the differentiation between an entity and a table in database?
Entity is a logical concept of relational database model. And table is used to express it, but there is a slight difference. Table expresses not only entities, but also relations.
For example, assume that you want to make a database of projects and employees of a company. Entity is a unit of information that has meanings by itself. In this case, there will be two entities - "Project" and "Employee". Each entity has its own attributes.
In relational DB model, there is another idea, 'relation'. If employees participate in several projects, then we can say that there is a relation with a name 'works_on'.
Sometimes, relation can have its own attribute. In this case, 'works_on' relation can have attribute 'start_date' and so on. And if this relation is M:N relation(Like this case: In project 1, there are 5 employees. Employee A works on two projects.), then you have to make an extra table to express this relation. (If you don't make an extra table when the relation is M:N, then you have to insert too many duplicated rows into both 'Project' and 'Employee' table.)
CREATE TABLE works_on(
employee,
project_id,
start_date
)
An entity resides in a table, it is a single set of information, i.e: if you have a database of employees, then an employee is an entity. A table is a group of fields with certain parameters.
Basically everything is stored in a table, entities goes into tables.
In a relational database the concept is the same. An entity is a table.
In OOP (Oriented Object Programming) there is a nice article in Oracle docs:
In general terms, entity objects encapsulate the business policy and
data for
the logical structure of the business, such as product lines,
departments, sales, and regions
business documents, such as invoices, change orders, and service
requests
physical items, such as warehouses, employees, and equipment
Another way of looking at it is that an entity object stores the
business logic and column information for a database table (or view,
synonym, or snapshot). An entity object caches data from a database
and provides an object-oriented representation of it.
Depending on how you want to work, you can create entity objects from
existing database tables (reverse generation) or define entity objects
and use them to create database tables (forward generation).
There is little difference between an entity and a table, but first we should define the concepts of “tuple” and “attribute”. I want to express those concepts with a table.
Here is an example of a table. As you can see it has some columns. Each column represents an attribute and each line represents a tuple(row). This is the employee table. In this example, the table is being used for representing an entity which is employee. However, if we create a new table named superior to specify the superiority relationship between those employees, it would be a table that represents a relation. In summary, we can use tables for representing both the entities and relations so entities and tables are not the same.
While studying for my IT exam I came across the following sentence:
"A collection of fields that store information about a certain entity, is a record. A record is a whole row of fields."
..but I have always thought that the correct term for an "object" in a database is an "entity".
So is the correct term an "entity" or a "record"? Or are they the same?
In that sentence, entity doesn't refer to anything in the database. It's using entity to refer to a conceptual object, whatever thing in the real world the database record represents. For instance, if you have an inventory database, each row stands for a product in the warehouse, and that's the entity.
An entity is defined as “something that exists as a particular and
discrete unit.” In terms of identity management, an entity is the
logical relationship between two or more records. [...] An entity is
also called a “linkage set.” There can be an unlimited number of
records in an entity or linkage set.
Source
Along these lines, an entity can be a set of records in a table or even across different tables.
I would say that an entity concept is physicalised by 1 or more tables e.g.
a product concept might be encapsulated entirely in 1 table
a person concept might be spread across several tables, for example due to normalisation - all information relating to a person might not exist in the same table.
I just started with the Entity Framework and started to design the model first. So in my model there is a Person who can have a PrivateTelephone, so I created an 0..1 to 1 association. As the picture below shows.
So far so good. But when I generate the database the [PrivateTelephone] is set to NOT NULL. Why can't this be just NULL?
It is becauser your relations are defined in reverse order. You should have 1 on Person and 0..1 on Telecom to specify that Person is the principal which can have one or zero phones. In your mapping you say that Telecom is principal which can have one or zero persons but person must have Telecom. It will also lead to reverse problem due to your incorrect mapping. You have six one-to-one relations to Telecom but if you reverse them as you demand you will say that all six relations (all six FKs in Telecom) will be NOT NULL = each record will have to participate in all six relations.
One-to-one relation is very special and should be used rarely. You should instead have one-to-many relation from Person to Telecom with a new column in Telecom specifying the type.
When using one-to-one relation you must have FK in dependent table configured with unique index. EF doesn't support unique indices so when you model one-to-one relation in model first it is still one-to-many in database and if database is used by another application it can break your application.
Also avoid unnecessary inheritance. Do you need Person as separate entity? = is there any instance which is only person and not employee? Are there more derived types from person? If not you don't need person and if yes it still doesn't mean that base person is a good idea. The same is true with employee. Inheritance has its own rules in EF and when using model first it will by default creates TPT inheritance = the worst one because it results in very complex and slow database queries.