ER or entity relationship model is a conceptual model that is used for formalizing data requirements between business user and information architect. It’s an easy to understand graphical representation of the data requirements that is user friendly. Simple as that.
ER model is made up of three building blocks, which are entity types, attribute types, and relationship types. Entity types simply represents a collection of similar things and are represented in a rectangle in the ER model. Each of these entity types have attribute types that describes the entity types like name, addresses, and social security numbers and are represented in ellipses. Then we have relationship types, which are association between one or more entities like student and course or student and a teacher entity types that are represented in rhombuses.
Entity type student with student id, student name, and student age as its attributes will have multiple entities. Entity type is pretty much a general term that is used to define collection of entities that have similar characteristics while entities are individual items that exists within it. For example, bob with student id 111 and last name billy who is 21 years old is one of the entity. The details of the individual entities are attributes and are categorized by attribute types. For example, age is an attribute type while actual age 21 is an attribute to an entity. Attributes usually have a specified domain, but in the case of ER model, it isn’t shown. For example, attribute type color can be set to have black or white, which means it is specified to have two values.
There are many different attribute types like key attribute types, simple and composite attribute types, single valued and multi valued attribute types, and derived attribute types. Key attribute type is something that is unique like social security number or student identification number, because it doesn’t repeat in the database and can be used to identify individual entities. Height of a person or weight of a person isn’t a key attribute since it can repeat and it can’t uniquely identify each entity. If the entity types don’t have key attribute type, it is a weak entity type. If it has a key attribute type, then it is a strong entity type. Weak entity types will borrow attribute type from a strong entity type and will refer to it as owner entity type. Weak entity types are represented with two rectangles and borrowed attribute type is underlined with a dashed line. Then we have simple or atomic attribute type, which means it is an attribute type that can’t be further divided while composite attribute type means it can be divided into more attribute types. For example, address attribute type can be broken into street number, zip code, and country attribute types. Name is also another composite attribute type that can be broken down into three simple or atomic attribute type first name, middle name, and last name attribute types. Then we have single valued attribute type, which means there can only be one value for that one entity. For example, social security number is a single valued attribute type since you can’t have more than one social security number per entity. Multi valued attribute types on the other hand means you can have more than one value, like email addresses or phone numbers. In the ER model, multi valued attribute types are depicted with double ellipses. Then we have derived attribute types, which are basically an attribute type that can be derived from another attribute type. For example, age attribute type can be derived from date of birth attribute type. Derived attribute types are depicted using dashed ellipses in the ER model.
Now that we talked about the entity types and the attribute types, let’s go over the last building block of the ER model, the relationship type in more detail. Relationship type basically defines association for one or more entity types. Relationship types are depicted using a rhombus symbol and they can be seen as two arrows put together. Relationships are based on degree or number of entity types participating in it, so one is unary, two is binary, and three is ternary relationship types. Roles of the relationship basically indicates the direction of the arrows and are used to describe in more detail on the relationship. For example, relationship type between buyer entity type and seller entity type is binary since two entity types are involved and the roles are buying and selling. Another example is entity type employee itself, which is unary and includes supervisor and regular employee with roles supervises and supervised by. Cardinalities represents relationship instances that entity can participate in and has minimum and maximum number with colon between it. Minimum is either 0 or 1 and maximum is either 1 or N. If minimum is 0, it’s basically stating that the entity can exists without being connected to another entity, which means it’s a partial participation since not all entities may not participate in the relationship. If the minimum is 1, then it’s stating that it must always be connected to some entity and is considered total participation or existence dependency since that entity needs to depend on the existence of another entity. When it comes to maximum, 1 means that entity can be involved with at most 1 entity while N means it can be any integers bigger than 1. Let’s talk example, a middle schooler entity must attend at least minimum of one middle school and they can’t attend more than one middle school at a time, so that will be minimum of 1 and maximum of 1 cardinality 1:1 that is associated with entity type middle school. Just like entity types, relationship types can also have attribute types as well. In the case of M:N relationship, attribute type needs to be specified as a relationship attribute type. 1:1 or 1:N can be moved around to participating entity types as needed.
HansITAcademy 