CIS 315 - Week 5 Lecture
Intro to Entity-Relationship modeling

*   data modeling: the process of creating a
    representation of the USERS' view of the
    data in their scenario;

    "model of a model"

*   this is one classic approach (amongst of
    a number of possible approaches) --
    entity-relationship modeling

    you use entity-relationship modeling
    to come up with an entity-relationship model 
    depicted as an entity-relationship diagram (ERD)

    ...this logical model is then converted
    into a database design/schema;

    *   IMPORTANT:
        AT THE MODELING STAGE,
	YOU SHOULD NOT BE THINKING IN TERMS OF
	TABLES or RELATIONS YET!!

   instead, for ER modeling, we will think in terms
   of ENTITIES and RELATIONSHIPS;

*  ER modeling was introduced by Peter Chen in a
   1976 paper;

   *   key elements of the ER model are:
       entities
       relationships
       attributes
       identifiers

*  entities
   *   an entity class is a set of objects that
       are significant in a scenario and are
       distinguishable from other objects;

      FOR example:
      in University scenario,
      Student might be an entity class;
      Course might be an entity class;
      Course-Registration might be an entity class;

   *  so: need to distinguish between
      entity classes/entities
      and entities/entity instances;

   *  an entity class will EVENTUALLY correspond
      to ONE OR MORE relations in a relational database
      scheme/design;

   *  in an ER-diagram, these are practically
      always indicated by writing a rectangle
      for each entity class, and the rectangle
      is labeled by the name of the entity class...

*   attributes
    *   attributes, or properties, describe
        entity characteristics that are important
	in the user's world/environment;

        *   really, an entity (in the relational
	    model) could be said to be said
	    to be represented by a set of
	    attributes/properties;

        *   e.g. 
	    a Student entity class may have
	    attributes such as last name, first
	    name, student_id, etc.
	    
	    a course-registration may
	    have an attribute such as
	    reg_date

    *   it can be "interesting" to determine
        when something is an attribute,
	and when it is a related entity class;

        *   the answer depends on the
	    scenario,
	    and whether that possible-attribute
	    has its own attributes,
	    and whether other entity classes
	    are related to it...

    *   one option (we will NOT use) to depict
        attributes is written within in ovals connected
	to the entity rectangle;
        *   we'll, instead, list them in a vertical	
            list (labeled by the entity class name)
	    on or near the ER diagram...
 
        *   and, TAKE CARE -- at the ER model level,
	    there should be NO relationship-related
	    attributes amongst an entity class's
	    attributes;

        *   if in doubt, "break up" composite
	    attributes into its "pieces"
	    (last name and first name instead of name,
	     city, state, and zip instead of address...)

    *   each attribute has a set of permitted
        values for that attribute, called its domain

        *   when and how you indicate the domain
	    can vary; we'll be indicating the 
	    physical domains at the design stage;

	    ...some settings have this indicated
	    at the model level, perhaps coordinated
	    by one DB modeling team member;

    *   it will be significant to indicate whether
        an attribute can be multi-valued FOR A
	SINGLE ENTITY INSTANCE;

	...we'll indicate that with (MV) next to
	the attribute name in an entity's attribute
	list;

*   identifiers...
    ...at the MODEL level, are attributes that distinguish
       different entity instances from one another;

       (they are NOT necessarily primary keys! because
       these are not tables...!)
       (and SOME entity classes will not have any
       identifiers!)

    *   IF an attribute seems to be an identifier at
        the model level, then indicate that in the
	entity's attribute list in some clear fashion
	(write in all-uppercase, or boldface, or
	underlined, etc.)

*   relationships
    *   a relationship is an association among
        several entity classes;

	if it is between 2 entity classes, it is
	called a BINARY RELATIONSHIP;

	(and while relationships between more than
	2 entity classes can exist, they do not
	"fit" well in the relational database world,
	and tend to be recast as binary relationships
	possibly with the help of additional
	association-related entity classes...)

    *   we will give a name to each relationship;
    *   we will depict a relationship using
        a line between the entity classes being
	related,
	with a diamond on that line,
	labeled on or near the diamond with the
	relationship name;

        *   try to make them descriptive;
	*   the relationship names don't
	    have to be "readable" both "ways";
        *   try not to repeat relationship names
	    (at least in general...)

        *   (it IS possible to have multiple relationships
	    between the same 2 entity classes -- you'd
	    just have a separate diamonded line for
	    each...)
      
*   we need two more kinds of information in this
    ER model to be able to convert it into a
    design; 

    maximum cardinalities
    minimum cardinalities

*   maximum cardinalities:
    for an INSTANCE of a relationship,
    what is the MAXIMUM number of each entity class
    that can be involved?

    *   USUALLY, a maximum cardinality is either
        1 or "many"
	...and "many" is usually written as N or M

        so really, there are only 3 possibilities
	of combinations of these:
	1:1 (one-to-one)
	in this relationship, an entity in A is associated
	with at most 1 entity in B, and an entity in B
	is related with at most 1 entity in A

        1:N (one-to-many)
        in this relationship, an entity in A is associated
	with possibly-multiple entities in B, but an entity in B
	is related with at most 1 entity in A

        N:M (many-to-many)
        in this relationship, an entity in A is associated
	with possibly-multiple entities in B, and an entity in B
	is related possibly-multiple (maybe a different number 
        of) entities in A       

    *   see the posted PDF reading packet for where you
        place the 1 and N or M for these;

*   minimum cardinalities
    answers the question: does this
    relationship HAVE to exist?
    its possible values: 0 or 1

    put a hash (for 1) or an oval (for 0) on the
    relationship line as demonstrated in the course
    PDF reading packet;