Entity - Relationship Modeling

3.1 Introduction When a relational database is designed, an entity-relationship diagram is drawn at an early stage and developed, as the requirements of the database and its processing become better understood. The details of how to draw the diagrams vary slightly from one method to another, but they all have the same basic elements: entity types, attributes and relationships. These three categories are considered sufficient to model the essentially static databased parts of any organization's information processing needs. 3.2 Entity Types An entity type is any type of object that we wish to store data about. Which entity types you decide to include on your diagram depends on your application. In an accounting application for a business you would store data about customers, suppliers, products, invoices and payments and if the business manufactured the products, you would need to store data about materials and production steps. Each of these would be classified as an entity type because you would want to store data about each one. In an entity-relationship diagram an entity type is shown as a box. There may be many entity types in an entity-relationship diagram. The name of an entity type is singular since it represents a type. An entity type is considered to be a set of objects. For this reason some people use the alternative term entity set. An entity is simply one member or example or element or instance of the type or set. So an entity is one individual within an entity type. For example, within the entity type CUSTOMER, J. Smith might be one entity. He is an individual entity within the type, an element in the set, an instance of the type 'customer'. 3.3 Attributes The data that we want to keep about each entity within an entity type is contained in attributes. An attribute is some quality about the entities that we are interested in and want to hold on the database. Each entity within the entity type will have the same set of attributes, but in general different attribute values. For example the value of the attribute ADDRESS for a customer J. Smith in a CUSTOMER entity type might be '10 Downing St., London' whereas the value of the attribute 'address' for another customer J. Major might be '22 Railway Cuttings, Cheam'. We store the same type of facts (attributes) about every entity within the entity type. If you knew that one of your customers happened to be your cousin, there would be no attribute to store that fact in, unless you wanted to have a 'cousin-yes-no' attribute, in which case nearly every customer would be a `no', which would be considered a waste of space. 3.4 Primary Key Attributes can be shown on the entity-relationship diagram in an oval. It is up to you which attributes you show on the diagram. In many cases an entity type may have ten or more attributes. There is often not room on the diagram to show all of the attributes, but you might choose to show an attribute that is used to identify each entity from all the others in the entity type. This attribute is known as the primary key. In some cases you might need more than one attribute in the primary key to identify the entities. For example the attribute CUS_NO is shown. Assuming the organization storing the data ensures that each customer is allocated a different cus_no, that attribute could act as the primary key, since it identifies each customer; it distinguishes each customer from all the rest. No two customers have the same value for the attribute cus_no. Some people would say that an attribute is a candidate for being a primary key because it is `unique'. They mean that no two entities within that entity type can have the same value of that attribute. As already mentioned, you may need to have a group of attributes to form a primary key, rather than just one attribute, although the latter is more common. Even this may not be sufficient in some cases. Any doubts on this point should be resolved by inspecting the entity description, which shows all the attributes of the entity type and (ideally) their meaning. 3.5 Relationship Types The first two major elements of entity-relationship diagrams are entity types and attributes. The final element is the relationship type. Sometimes, the word 'types' is dropped and relationship types are called simply 'relationships' but since there is a difference between the terms, one should really use the term relationship type. An entity-relationship diagram consists of a network of entity types and connecting relationship types. A relationship type is a named association between entities. Individual entities have individual relationships of the type between them. An idividual

person (entity) occupies (relationship) an individual house (entity). In an entity-relationship diagram, this is generalized into entity types and relationship types. The entity type PERSON is related to the entity type HOUSE by the relationship type OCCUPIES. There are many individual persons, many individual houses, and many individual relationships linking them. There can be more than one type of relationship between entities. The reader of the diagram must know what the relationship type means and it is up to you the designer to make the meaning clear from the relationship type name. The direction of both the relationship type and its inverse should be shown to aid clarity and immediate readability of the diagram. The tense of the relationship type should also be clear from its name. Finally, note that relationships between entity types are represented in a relational database using foreign keys. The value of the primary key of one entity is placed in every entity of the second type to which it is related. 3.6 Ways of Classifying Relationships Types A relationship type can be classified by the number of entity types involved, and by the degree of the relationship type. These methods of classifying relationship types are complementary. To describe a relationship type adequately, you need to say what the name of the relationship type and its inverse are and their meaning, if not clear from their names and you also need to declare the entity type or types involved and the degree of the relationship type that links the entities. 3.6.2 The Degree of a Relationship Type The second way of classifying relationship types is to state their degree. The use of terminology related to the degree of a relationship type varies between different authors. In this book, we use the James Martin terminology. The degree of a relationship type concerns the number of entities within each entity type that can be linked by a given relationship type. There are two directions of a relationship type. Each is named and each has a minimum degree and a maximum degree. 3.6.2.1 Cardinality and Optionality The maximum degree is called cardinality and the minimum degree is called optionality. In another context the terms 'degree' and 'cardinality' have different meanings. In [Date 4th ed. p240] 'degree' is the term used to denote the number of attributes in a relation while `cardinality' is the number of tuples in a relation. Here, we are not talking about relations (database tables) but relationship types, the associations between database tables and the real world entity types they model. There are three symbols used to show degree: A circle means zero A line means one A crowsfoot means many The cardinality is shown next to the entity type and the optionality (if shown at all) is shown behind it. Generally, the degree of a relationship type is described by its cardinality. With optionality, the opposite of 'mandatory' is optional. 3.6.2.2 Deriving a One-Many relationship type For example a part of the sales ledger system; Customers may have received zero or more invoices from us. The relationship type is thus called `received' and is from CUSTOMER to INVOICE. The arrow shows the direction. The minimum number of invoices the customer has received is zero and thus the `received' relationship type is optional. This is shown by the zero on the line. The maximum number of invoices the customer may have received is `many'. This is shown by the crowsfoot. To complete the definition of the relationship type the next step is to name the inverse relationship type. Clearly if a customer received an invoice, the invoice was sent to the customer and this is an appropriate name for this inverse relationship type. Now consider the degree of the inverse relationship type. The minimum number of customers you would send an invoice to is one; you wouldn't send it to no-one. The optionality is thus one. The inverse relationship type is mandatory. The maximum number of customers you would send an invoice to is also one so the cardinality is also one. One-One or One-Many or Many-Many
Questions must begin with the word `one'

Question 1: One customer received how many invoices? Answer: Zero or more. Question 2: One invoice was sent to how many customers?

Answer: One. 3.6.2.3 Deriving a Many-Many relationship type Note that the entity type has been called PRODUCT TYPE rather than PRODUCT which might mean an individual piece that the customer has bought. 3.6.2.4 Deriving a One-One relationship type Example: It concerns a person and his or her birth certificate. We assume that everyone has one and that a certificate registers the birth of one person only. Where there is a one-one relationship type we have the option of merging the two entity types. The birth certificate attributes may be considered as attributes of the person and placed in the person entity type. The birth certificate entity type would then be removed. There are two reasons for not doing this. Firstly, the majority of processing involving PERSON records might not involve any or many of the BIRTH_CERTIFICATE attributes. The BIRTH CERTIFICATE attributes might only be subject to very specific processes which are rarely executed. The second reason for not merging might be that the BIRTH CERTIFICATE entity type has relationship types to other entity types that the PERSON entity type does not have. The two entity types have different relationship types to other entity types. 3.6.3 Mutually Exclusive relationship types In some cases the existence of one kind of relationship type precludes the existence of another. Entities within an entity type A may be related by a relationship type R to an entity in entity type B or entity type C but not both. The relationship types are said to be mutually exclusive. The set of relationship types is normally assumed to be exhaustive in one sense (i.e. there are not any other relationship types) because it is customary to put all relationships of interest on the diagram. However the set of relationship types might not be exhaustive in the sense that a given entity A might not be related to an entity in any of the other entity types in the group marked by the arc. This second type of exhaustiveness (or lack of it) cannot be shown using this arc device. 3.10 Representing Trees and Networks Two data structures that occur frequently in applications are the tree and the network. A graph is just a drawing consisting of number of nodes and edges. The tree is a very general data structure and can be used as a modelling method for many different types of computing application. In the applications we are considering, each node represents an entity and each edge represents a relationship between two nodes or another entity. This tree diagram shows individual entities whereas the entity-relationship version. In a tree, there are no loops. The graph is `open'. Along one direction of an edge, (`down' the tree) a node can be connected to zero or more other nodes, but along the other direction it can be connected to zero or one nodes only.