Each customer can place: min =0, max = many ordersEach order can be placed by: min one max one customersEach order can list: min one max many productsEach product can be listed on: min zero max many ordersimple Crow’s-Foot notation: 0ne-to-one (1:1) 0ne-to-many (1:M) Many-to-many (M:N)exactly oneone or morezero or one (Optionally one)zero or more (Optionally many)E-R diagram (ERD), a graphical representation of the logical structure of a database.The E-R modeling process identifies three basic elements: entities, attributes and relationships.Guidelines for constructing E-R Diagrams…………Identify entities: An entity is a person, place, object, event or concept, and usually can be identified by a single, unique attribute.Provide a meaningful name for the entity and key attribute.List Business Rules concerning the identification of the key attribute.Identify attributes: for each entity.List appropriate business rules.Identify relationships: between entities, but only one at a time. (Work with just two entities at a time.)Specify the business rule(s) pertaining to the relationship, as these rules should make the cardinality clear(er).Provide a meaningful name, usually a verb (doing word) or phrase.Draw an E-R diagram for each relationship, comprising only the relationship and the entities involved.Combine: all of your relationship diagrams into a single E-R diagram.Construction of E-R diagrams is an iterative process. When defining relationships or constructing the full E-R diagram, new entities, attributes or relationships may be identified.Creating an E-R DiagramStep 1: Model the EntitiesThe first step in creating an E-R diagram is to model the entities.It is particularly helpful to look for possible primary keys for an entity. Generally, when a form has an identifier for a possible entity it is likely to be the entity. For example, if a form contains a space for a customer number, then the database (and the E-R diagram) probably needs to contain a CUSTOMER entity.EntityAttributesORDERORDER-NO, DATE, TOTALPRODUCTPROD-ID, DESCRIPTION, PRICECUSTOMERCUSTOMER-ID, CUST-NAMEIf the price of a product does not change from one order to another, then PRICE is a function of PRODUCT. If, however, different orders for the same product have different prices, then PRICE is a function of the relationship between PRODUCT and ORDER.the database analyst must determine which entities need to be in the database and which should be excluded. These decisions are based on whether a candidate entity is an entity or an attribute. Many of the candidate entities clearly belong in the database the most likely candidate entities that should be rejected are those for which no attributes have been identified. If you are unable to find any attributes for an entity, that entity is probably in reality an attribute for another entity. For example, CUSTOMER_NAME might be identified as a possible entity. However, no attributes can be identified for CUSTOMER_NAME. This leads to the conclusion that CUSTOMER_NAME is not an entity, but is better considered an attribute of the CUSTOMER entity.Not all cases are so clear, however. Take the example of ADDRESS. Perhaps a number of attributes were identified for this candidate entity, such as NUMBER, STREET, CITY, STATE, and POSTAL_CODE. Does the presence of these potential attributes of ADDRESS indicate that ADDRESS is an entity? Although in some situations this will be the case, more often all of these should be attributes of some other entity, such as CUSTOMER.Step 2: Choose Primary KeysAfter identifying and modeling each entity and its attributes, primary keys must be chosen for each entity.the proper functioning of the database requires that primary keys can never be null. The primary key for each entity must always have a unique, valid value for each instance of the entity. Combining these two requirements results in each instance of an entity always having a one and only one primary key (even if it’s a composite primary key), and each primary key is unique.Desirable Primary Key Characteristics1. Uniquely identifies an entity instance.2. Non-null (always has a value)3. Data-less4. Never changesTable 2: Characteristics of a Good Primary KeyStep 3: Model RelationshipsRelationships among entities are a critical part of the Entity Relationship Diagram. When these relationships are implemented in the database, they provide the links among the various tables that give the database its flexibility. To maximize the flexibility of a database, relationships must be properly identified and modeled.Many relationships are relatively easy to recognize, such as those between ORDERS and CUSTOMERS,n the case of the Order Entry Form example, ORDER and CUSTOMER are related, as are ORDER and PRODUCT. However, we know that there may not necessarily be a relationship between PRODUCT and CUSTOMER. Because both are related to ORDER we can report which products are ordered by a particular customer.Step 4: Determine CardinalitiesRecall that there are both maximum and minimum cardinalities. The maximum cardinality of a relationship is the number of instances of one entity in a relationship that can be related to a single instance of another entity in the relationship. In contrast, the minimum cardinality is the number of instances of one entity thatThere are two relationships, one between PRODUCT and ORDER, and the other between ORDER and CUSTOMER. One instance of ORDER can be related to many instances of PRODUCT. In other words, one ORDER can contain many PRODUCTS. Thus, the cardinality from ORDER to PRODUCT is many. Turning to the other side of the relationship, we can see that one instance of PRODUCT can be related to many instances of ORDER—a single PRODUCT can be on many ORDERS. So, the cardinality from PRODUCT to ORDER is many. Combining the two sides gives us a many-to-many cardinality between ORDER and PRODUCT.Now we must analyze the relationship between CUSTOMER and ORDER. A single ORDER can be related to only one CUSTOMER. In other words, a single ORDER can’t be placed by more than one CUSTOMER. This means that the cardinality from ORDER to CUSTOMER is one. On the other side, a single CUSTOMER can place many ORDERS, so the cardinality from CUSTOMER to ORDER is many, and we can say that the cardinality of the CUSTOMER-ORDER relationship is one-to-many.Step 5 – Check the ModelThe final step in creating an E-R diagram is often overlooked, but is just as important as any of the previous steps. Analysts who fail to carefully check their ERD often produce diagrams of poor quality, which of course should be avoided.In order to check the ERD, you must return to your original information sources, the forms, reports, and interviews with users. The basic idea is to go back to the original documents and make sure that the structure represented in the ERD can satisfy the requirements

Post Author: admin


I'm Irvin!

Would you like to get a custom essay? How about receiving a customized one?

Check it out