The aims of this chapter are:
* To explain the need for entity-relationship modelling
* To explain the terms entity-relationship model, entity-relationship diagram * To define the terms entity type, entity, attribute, attribute value, primary key, relationship, relationship type, inverse relationship type * To define the grammar of entity-relationship diagrams
* To describe ways of classifying relationship types
* To describe the terms unary, binary, ternary, degree, cardinality and optionality with regard to relationship types * To define mutually exclusive relationship types
* To show alternative entity-relationship diagramming conventions * To show how many-many relationship types can be split into one-many relationship types * To give various examples of entity-relationship modelling 3.1 Introduction
When a relational database is to be 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. Drawing an entity-relationship diagram aids understanding of an organization's data needs and can serve as a schema diagram for the required system's database. A schema disgram is any diagram that attempts to show the structure of tha data in a database. Nearly all systems analysis and design methodologies contain entity-relationship diagramming as an important part of the methodology and nearly all CASE (Computer Aided Software Engineering) tools contain the facility for drawing entity-relationship diagrams. An entity-relationship diagram could serve as the basis for the design of the files in a conventional file-based system as well as for a schema diagram in a database system. 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 to be sufficient to model the essentially static data-based 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. In Fig. 3.1, CUSTOMER is an entity type. Each entity type is shown once. 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'.
Fig. 3.1 An entity type CUSTOMER and one of its attributes Cus_no 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. In fact we store the value of the attributes 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...