Entity Ttypes Strong vs Weak Entities

Strong Entities:

If an entity can exist apart from all of its related entities (it is existence-independent), then that entity is referred to as a strong entity or regular entity. For example, suppose that the XYZ Corporation uses parts to produce its products. Furthermore, suppose that some of those parts are produced in-house and other parts are bought from vendors. In that scenario, it is quite possible for a PART to exist independently from a VENDOR in the relationship “PART is supplied by VENDOR,” because at least some of the parts are not supplied by a vendor. Therefore, PART is existence independent from VENDOR.

Weak Entities:

A weak entity is one that meets two conditions:

1. The entity is existence-dependent; that is, it cannot exist without the entity with which it has a relationship.
2. The entity has a primary key that is partially or totally derived from the parent entity in the relationship.

For example, a company insurance policy insures an employee and his/her dependents. For the purpose of describing an insurance policy, an EMPLOYEE might or might not have a DEPENDENT, but the DEPENDENT must be associated with an EMPLOYEE. Moreover, the DEPENDENT cannot exist without the EMPLOYEE; that is, a person cannot get insurance coverage as a dependent unless s(he) happens to be a dependent of an employee. DEPENDENT is the weak entity in the relationship “EMPLOYEE has DEPENDENT.”

    The Chen notation in the following Figure identifies the weak entity by using a double-walled entity rectangle.

 

Associative (Composite) Entities:

The associative entity is used to implement a M:N relationship between two or more entities. This associative entity (also known as a composite or bridge entity) is composed of the primary keys of each of the entities to be connected. An example of such a bridge is shown in the following Figure. The Crow’s Foot notation does not identify the composite entity as such. Instead, the composite entity is identified by the solid relationship line between the parent and child entities, thereby indicating the presence of a strong (identifying) relationship.

Note that the composite ENROLL entity in the above Figure is existence-dependent on the other two entities; the composition of the ENROLL entity is based on the primary keys of the entities that are connected by the composite entity. The composite entity may also contain additional attributes that play no role in the connective process. For example, although the entity must be composed of at least the STUDENT and CLASS primary keys, it may also include such additional attributes as grades, absences, and other data uniquely identified by the student’s  performance in a specific class.

Finally, keep in mind that the ENROLL table’s key (CLASS_CODE and STU_NUM) is composed entirely of the primary keys of the CLASS and STUDENT tables. Therefore, no null entries are possible in the ENROLL table’s key attributes.

Weak Entity Type and Identifying Relationship:
As discussed before, an entity type has a key attribute which uniquely identifies each entity in the entity set. But there exists some entity type for which key attribute can’t be defined. These are called Weak Entity type.

For example, A company may store the information of dependants (Parents, Children, Spouse) of an Employee. But the dependents don’t have existence without the employee. So Dependent will be weak entity type and Employee will be Identifying Entity type for Dependant.

A weak entity type is represented by a double rectangle. The participation of weak entity type is always total. The relationship between weak entity type and its identifying strong entity type is called identifying relationship and it is represented by double diamond.

Derived Attribute –
An attribute which can be derived from other attributes of the entity type is known as derived attribute. e.g.; Age (can be derived from DOB). In ER diagram, derived attribute is represented by dashed oval.

Multivalued Attribute –
An attribute consisting more than one value for a given entity. For example, Phone_No (can be more than one for a given student). In ER diagram, multivalued attribute is represented by double oval.

Composite Attribute –
An attribute composed of many other attribute is called as composite attribute. For example, Address attribute of student Entity type consists of Street, City, State, and Country. In ER diagram, composite attribute is represented by an oval comprising of ovals.

Key Attribute –
The attribute which uniquely identifies each entity in the entity set is called key attribute.For example, Roll_No will be unique for each student. In ER diagram, key attribute is represented by an oval with underlying lines.

Attribute(s):
Attributes are the properties which define the entity type. For example, Roll_No, Name, DOB, Age, Address, Mobile_No are the attributes which defines entity type Student. In ER diagram, attribute is represented by an oval.

DBMS | Anomalies in Relational Model

We strongly recommend to refer below posts as a prerequisite of this.
DBMS | Relational Model Introduction and Codd Rules
DBMS | Keys in Relational Model (Candidate, Super, Primary, Alternate and Foreign)

Anomalies
There are different types of anomalies which can occur in referencing and referenced relation which can be discussed as:

Insertion anomaly: If a tuple is inserted in referencing relation and referencing attribute value is not present in referenced attribute, it will not allow inserting in referencing relation. For Example, If we try to insert a record in STUDENT_COURSE with STUD_NO =7, it will not allow.

Deletion and Updation anomaly: If a tuple is deleted or updated from referenced relation and referenced attribute value is used by referencing attribute in referencing relation, it will not allow deleting the tuple from referenced relation. For Example, If we try to delete a record from STUDENT with STUD_NO =1, it will not allow. To avoid this, following can be used in query:

• ON DELETE/UPDATE SET NULL: If a tuple is deleted or updated from referenced relation and referenced attribute value is used by referencing attribute in referencing relation, it will delete/update the tuple from referenced relation and set the value of referenced attribute to NULL.
• ON DELETE/UPDATE CASCADE: If a tuple is deleted or updated from referenced relation and referenced attribute value is used by referencing attribute in referencing relation, it will delete/update the tuple from referenced relation and referencing relation as well.

This article is contributed by Sonal Tuteja. If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to contribute@geeksforgeeks.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.

Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above.

What is Entity in DDD

http://users.csc.calpoly.edu/~jdalbey/205/Lectures/HOWTO-ERD.html
https://it.toolbox.com/blogs/craigborysowich/understanding-entities-in-e-r-diagrams-020107
https://docs.oracle.com/cd/A97335_02/apps.102/bc4j/developing_bc_projects/bc_awhatisanentityattribute.htm

Many objects are not fundamentally defined by their attributes, but rather by a thread of continuity and identity.

an ER model can be used also in the specification of domain-specific ontologies.

An entity is a 

• Person
• Role
• Property
• Products
• Organizations
• Agreements
• Abstractions
• Place
• Thing
• Idea
• Concept of Interest
• Organization
• Event

to the business or organization about which data is likely to be kept.  

identify the roles, events, locations, tangible things or concepts about which the end-users want to store data. 

A data entity is anything real or abstract about which we want to store data. 

Entity types fall into five classes: roles, events, locations, tangible things, or concepts. 

The best way to identify entities is to ask the system owners and users to identify things about which they would like to capture, store and produce information. 

Another source for identifying entities is to study the forms, files, and reports generated by the current system. E.g. a student registration form would refer to Student (a role), but also Course (an event), Instructor (a role), Advisor (a role), Room (a location), etc.

Identify Entities 

The entities in this system are Department, Employee, Supervisor and Project. One is tempted to make Company an entity, but it is a false entity because it has only one instance in this problem. True entities must have more than one instance. 

Entity

A data entity is anything real or abstract about which we want to store data.

Entity types fall into five classes: 

roles, 

events, 

locations, 

tangible things or 

concepts.

E.g. employee, payment, campus, book. Specific examples of an entity are called instances. E.g. the employee John Jones, Mary Smith's payment, etc. 

Look for the people, places, things, organizations, concepts, and events that an organization needs to capture, store, or retrieve information about.

For example, in a school environment possible entities might be Student, Instructor, and Class.

 Entity‑type refers to a generic class of things such as Company.  Entity is the short form of entity-type.

 Entity‑occurrence refers to specific instances or examples of a type.  For example, one occurrence of the entity Car is Chevrolet Cavalier.

 An entity usually has attributes (i.e., data elements) that further describe it.  Each attribute is a characteristic of the entity.  An entity must possess a set of one or more attributes that uniquely identify it (called a primary key).

The entities on an Entity-Relationship Diagram are represented by boxes (i.e., rectangles).  The name of the entity is placed inside the box.

Identifying Entities

Identifying entities is the first step in Data Modelling.  Start by gathering existing information about the organization.  Use documentation that describes the information and functions of the subject area being analyzed, and interview subject matter specialists (i.e., end-users).  Derive the preliminary entity-relationship diagram from the information gathered by identifying objects (i.e., entities) for which information is kept.  Entities are easy to find.  Look for the people, places, things, organizations, concepts, and events that an organization needs to capture, store, or retrieve information about.

Types of Entities

 Different types of entities are required to provide a complete and accurate representation of an organization's data and to enable the analyst to use the Entity-Relationship Diagram as a starting point for physical database design.  Types of entities include:

Fundamental, Attributive, Associative

·          Fundamental Entity Type where the entity is a base entity that depends on no other for its existence.  

A fundamental entity has a primary key that is independent of any other entity and is typically composed of a single attribute.  

Fundamental entities are real-world, tangible objects, such as, Employee, Customer, or Product.

·          Attributive Entity Type where the entity depends on another for its existence

For example, Employee Hobby depends on Employee. 

An attributive entity depends on another entity for parts of its primary key.  

It can result from breaking out a repeating group, the first rule of normalization, or from an optional attribute.

·          Associative where the entity describes a connection between two entities with an otherwise many-to-many relationship,

for example, assignment of Employee to Project (an Employee can be assigned to more than one Project and a Project can be assigned to more than one Employee).

If information exists about the relationship, this information is kept in an associative entity.

For example, the number of hours the Employee worked on a particular Project is an attribute of the relationship between Employee and Project, not of either Employee or Project.  An associative entity is uniquely identified by concatenating the primary keys of the two entities it connects.

·          Subtype/Supertype where one entity (the subtype) inherits the attributes of another entity (the supertype). 

A super type entity is used to represent two or more entities when they are viewed as the same entity by some other entities.  A sub type entity is an entity that is a special case or refined version of another entity.  Sub type entities are created when attributes or relationships apply to only some occurrences of an entity, the subset of occurrences to which the attributes or relationships apply are separated into entity sub types.  When an attribute applies only to some occurrences of an entity, the subset of occurrences to which it applies should be separated into entity sub types.  The common data elements are put in the super type entity and the specific data elements are placed with the sub type to which they apply.  For example, Employee (super type) may contain three sub types, Permanent Employee, Part-time Employee, and Temporary Employee.  All data elements of the super type must apply to all sub types.  Each sub type contains the same key as the super type.  Relationships between an entity super type and its sub types are always described as "is a."  For example, Employee is a Permanent Employee, Employee is a Part-time Employee.

Identifying Entity Super types/Sub types

Entity supertypes/subtypes involve classes of entities that are truly different, but at the same time, significantly similar.  When identifying supertypes/subtypes, look for:

·          entity types that have the same attributes,

·          entity types that participate in the same relationships,

·          occurrences of an entity that do not participate in all the relationships in which the entity type participates,

·          occurrences of an entity that do not have all the attributes that the entity type has.

Entities on a Data Flow Diagram

Entities will often become data stores on Data Flow Diagrams.  More than one entity may map into a data store.

CATEGORIES OF ENTITIES

There are three general categories of entities:

·          Physical entities are tangible and easily understood.  They generally fall into one of the following categories:

People with different attributes that a business want to save in its data base

People with different behaviors/operations that business want to perform by its application and change its attributes

·          people, for example, doctor, patient, employee, customer,

Attributes of Properties and Operations on the Properties

Attributes of Equipment and Operations on Equipment those change its attributes

Attributes of Buildings and Operations on Building those change its attributes

Attributes of Furniture and Operations on Furniture those change its attributes
Attributes of Fixtures and Operations on Fiextures those change its attributes
Attributes of Supplies and Operations on Supplies those change its attributes 
Business in intersed in both ATTRIBUTES and OPERATIONS related to that Entity

·          property, for example, equipment, land and buildings, furniture and fixtures, supplies,

·          products, such as goods and services.

Attributes and Operations on Products on which in Business in really interested
Attributges and Operations on Goods in which Business is really interested
Attributes and Operations on Services in which Business is really interested to Record and Perform

·          Conceptual entities are not tangible and are less easily understood.  They are often defined in terms of other entity-types.  They generally fall into one of the following categories:

·          organizations, for example, corporation, church, government,

·          agreements, for example, lease, warranty, mortgage,

·          abstractions, such as strategy and blueprint.

Event/State entities are typically incidents that happen and business is interested to store or record those events. 

They are very abstract and are often modeled in terms of other entity-types as an associative entity.  

Examples of events are 

• purchase event has attributes and operations
• negotiation event attributes and operations
• service call event has attributes and operations
• deposit event has attributes and operations
• 
  
• purchase incident
• negotiation incident
• service call incident
• deposit incident

Examples of states are, these are life cycle states of different entities.

During its life cycle, Entities takes different states, these States themselves are 

captured as Entities. these are Usually LOV or List those are assigned to Entities.

• ownership state of any plot
• enrollment status of the student
• employment status of any citizen

IMPOSTER ENTITIES

When an Entity is not an Entity

There are a number of things that may appear to be 

entities about which facts are kept, 
but which should not be defined as such.  These include:

·          processes,

·          calculations,

·          reports,

·          facts about entities.

Processes

Processes may actually perform actions on entities but are not, themselves, entities.  they become the part of Domain Model.

Examples are:

·          payroll deduction,

·          budgeting (an action on an organization unit).

Calculations

Calculations may become VO
Calculations are derived from the attributes of an entity.  Examples are:

·          inventory level,

·          average age,

·          net worth.

Reports

Reports present facts about one or more entities.  Examples are:

·          Project schedule,

·          Income statement.

Facts About Entities

Facts about entities describe characteristics of an entity and should be modeled as attributes.  Examples are:

·          telephone number,

·          date of hire.

RULES FOR DEFINING ENTITIES

Entities are things in an organization that are of interest to the business.  They generally correspond to people, places, things, events, concepts and organizations.

Name each entity using a noun in the singular form (e.g., Employee not Employees).  Use a word that is precise and clearly identifies the object.  When appropriate and needed to distinguish similar entities, use an adjective to further describe the noun (e.g., Permanent Employee, Temporary Employee).

Use a term that is familiar to the business or is commonly used in everyday language. 

Avoid the use of obscure terminology unless it is commonly used in the organization under analysis.

The entity name is representative of the characteristics or attributes of the entity.  

Take this into account when naming entities.  For example, use a term such as Inventory Item rather than Item.

What is Database Entity?

Database entity is a thing, person, place, unit, object or any item about which the data should be captured and stored in the form of properties, workflow and tables. 

While workflow and tables are optional for database entity, properties are required (because entity without properties is not an entity).

Entity workflow is a kind of an entity lifecycle which consists of states, transitions and reasons why entity transits from one state to another. For example, when users change the state of entity ‘Task’ from ‘In Progress’ to ‘Closed’ they can select one of the available reasons: ‘Completed’ or ‘Cancelled’.

An entity may be defined as a thing capable of an independent existence that can be uniquely identified. 

An entity is a thing that exists either physically or logically. 

An entity may be a physical object such as a house or a car (they exist physically), 

an event such as a house sale or a car service, 

or a concept such as a customer transaction or order (they exist logically—as a concept). 

Although the term entity is the one most commonly used, following Chen we should really distinguish between an entity and an entity-type. 

An entity-type is a category. An entity, strictly speaking, is an instance of a given entity-type. 

There are usually many instances of an entity-type. 

Because the term entity-type is somewhat cumbersome, most people tend to use the term entity as a synonym for this term

Entities can be thought of as nouns. Examples: a computer, an employee, a song, a mathematical theorem, etc.

A relationship captures how entities are related to one another. 

Relationships can be thought of as verbs, linking two or more nouns. 

Examples: an owns relationship between a company and a computer, a supervises relationship between an employee and a department, a performs relationship between an artist and a song, a proves relationship between a mathematician and a conjecture, etc.

Entities and relationships can both have attributes. 

Examples: an employee entity might have a Social Security Number (SSN) attribute, while a proved relationship may have a date attribute.

Every entity (unless it is a weak entity) must have a minimal set of uniquely identifying attributes, which is called the entity's primary key.

Entity–relationship diagrams don't show single entities or single instances of relations. 

Rather, they show entity sets (all entities of the same entity type) and relationship sets (all relationships of the same relationship type). 

Examples: a particular song is an entity; the collection of all songs in a database is an entity set; the eatenrelationship between a child and her lunch is a single relationship; the set of all such child-lunch relationships in a database is a relationship set. In other words, a relationship set corresponds to a relation in mathematics, while a relationship corresponds to a member of the relation.