Conceptual models such as the ERM can be used to understand and design the data requirements of an organization. Therefore, the ERM is independent of the database type. Conceptual models are used in the conceptual design of databases, while relational models are used in the logical design as databases. The ERM forms the basis of an ERD. The ERD represents the conceptual database as viewed by the end user. ERDs detect the database’s the main components:
Entity – as an object of interest to as the end user; it also represents a real-world object, the words entity and object are often used interchangeably. An entity actually refers to the entity set and not to a single entity occurrence. In other words, the word entity in the ERM corresponds to a table—not to a row—in the relational environment. The ERM refers to a table row as an entity instance or entity occurrence. In both the Chen and Crow’s Foot notations, and entity is represented by a rectangle containing the entity’s a name. The entity name, a noun, is usually written in all capital letters.
Attributes – are characteristics of entities. In the original Chen and notation, attributes are represented by ovals and are connected to the entity rectangle was a line. Each oval contains the name of the attributes that represents. In the Crow’s Foot notation, the attributes are written in the attribute box below the entity rectangle. A required attribute is an attribute that must have a value; in other words, it cannot be left empty. Attributes that are not presented in boldface that do not require a value, which can be left empty, are known as optional attributes. Attributes have a domain which is the set of possible values for a given attribute. Attributes may share a domain. The ERM uses identifiers, that is, one or more attributes that uniquely identifying each entity instance. In the relational model, such identifiers are mapped to primary keys (PKs) in tables. Identifiers are underlined in the ERD. Key attributes are also underlined in a frequently used table structure shorthand notation using the format:
TABLE NAME (KEY_ATTRIBUTE 1, ATTRIBUTE 2, ATTRIBUTE 3 . . . ATTRIBUTE K)
Ideally, and entity identifier is composed of only a single attribute. It is possible to use a composite identifier, that is, a primary key composed of more than one attribute. Attributes are classified as simple or composite. A composite attribute, not to be confused with a composite key, is an attribute that can be further subdivided to yield additional attributes. A simple attribute is an attribute that cannot be subdivided. A single-valued attribute is an attribute that can have only a single value. For example, a person can have only one social security number, and to a manufactured part can have only one serial number. Keep in mind that a single-valued attribute is not necessarily a simple attribute. Multivalued attributes are attributes that can have many values. For instance, a person may have several college degrees, and a household of may have several different telephones, each with its own number. In the Chen ERM, the multivalued attributes are shown by a double line connecting the attribute to the entity. The Crow’s Foot notation does not identify multivalued attributes. Although the conceptual model can handle M:N relationships and multivalued attributes, you should not implement them in the RDBMS. So if multivalued attributes exists, the designer must decide on one of two possible courses of action:
1. Within the original entity, creates several new attributes, one for each of the original multivalued attribute’s come contents.
2. Create a new entity composed of the original multivalued attribute’s come contents. This is the preferred way to deal with multivalued attributes. Creating a new entity in a 1:M relationship with the original entity yields several benefits: it’s a more flexible, expandable solution, and it is compatible with the relational