- 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.
