SlideShare a Scribd company logo
1 of 96
Download to read offline
ENTITY RELATIONSHIP
     DIAGRAM
DATABASE ARCHITECTURE

External level – concerned with the way individual
users see the data


Conceptual level – can be regarded as a community
user view a formal description of data of interest to
the organization


Internal level – concerned with the way in which the
data is actually stored
   In 1967 Peter Chen developed the ER Model.

   It is a high level data model used for developing the
    conceptual design of the database.

   ER diagram helps designers understand and specify the
    desired components of database and the relationship
    among them.

   It must be flexible enough so that it can be used and
    understood in practically any environment where
    information is modelled
ENTITY
 It is a real world item / concept that can exist on it’s own.
 It may be an object with physical existence (
  person, house) or it may be an object with conceptual
  existence (company ,job, university course)


                  ENTITY TYPE
 Entity type defines collection of entities that have same
  attribute.
 Entity type in a database is defined by it’s name and
  attribute.
 Entity instance is a single occurrence of an entity type.
ENTITY SET
 Collection of entities of a particular entity type in a
  database at any point of time is called entity set
 Entity set is usually referred to by same name as the
  entity type




                   STUDENT
                                        Entity type



   Entity type is represented as rectangle enclosing the type
    name which is singular noun.
ATTRIBUTE
 Attributes are the properties that describe the entities.
 Attribute names are enclosed by ovals and connected to
  their entities by single line.
 Set of attribute values of a given attribute is the value set
  or domain



                                Ssn



             EMPLOYEE            Salary



                              Bdate
SIMPLE ATTRIBUTE              COMPOSITE ATTRIBUTE

• Cannot be split in to further   • Can be divided in to smaller
  attributes(indivisible)           subparts which represent
• Also known as Atomic              more basic attributes with
  attribute                         independent meaning
• Ex: Ssn(Social Security         • Even form hierarchy
  Number)                         • Value of the composite
                                    attribute is the
                                    composition of the
                                    constituent simple
                                    attributes
                                  • Ex: Address
SINGLE VALUED ATTRIBUTE          MULTI VALUED ATTRIBUTE

• Attributes having single       • Attribute having set of
  value for particular entity.     values
• Ex - Age                       • Denoted by double circled
                                   oval
                                 • Ex: Phone-number, College-
                                   degree




  DERIVED ATTRIBUTE               STORED ATTRIBUTE

• Attribute values are derived   • Attributes from which the
  from another attribute.          values of other attributes
• Denoted by dotted oval           are derived
• Ex - Age                       • Ex: Bdate
IDENTIFIER ATTRIBUTE
              OR KEY ATTRIBUTE
     Key              • Data item that allows us to uniquely identify individual
                        occurrences or an entity type.


  Superkey            • Attribute or set of attributes that uniquely identify a
                        tuple.


Candidate key         • Minimal super key with the property of irredusability
                        and uniqueness


Primary key           • An entity type may have one or more possible candidate
                        keys, the one which is selected as primary key.


Composite key         • candidate key that consisting of two or more attributes


 Foreign key          • An attribute or set of attribute that matches the
                        candidate key or other or same relation


   The name of each primary key attribute is underlined.
SIMPLE KEY ATTRIBUTE

             Rollno              Name



                      STUDENT



COMPOSITE KEY ATTRIBUTE
     Date
                                    No-of-
             Flightid
                                  passengers
  Flightno

                        FLIGHT
CRITERIA FOR SELECTING IDENTIFIERS
    Some entities have more than one candidate identifier, so the
    following criteria should be used:

   Choose identifier that will not change in value over the life of
    each instance of the entity type

   Choose identifier that is guaranteed to have valid values and
    will not be null (or unknown). If composite, make sure all
    parts will have valid values
   Avoid the use of intelligent identifiers whose structure
    indicates classifications, locations or people that might
    change. e.g. the first two digits of an identifier may
    indicate a warehouse location, but such codes are often
    changed as conditions change, which renders them
    invalid.
Composite-
      hierarchy
                            City


   Street                 State         Address
                                                   Primary-key
                           Street-
Apartme
                            add                    Ssn
 nt-no


                                     EMPLOYEE       Salary



                                                  Bdate
                          Phone-          Age
                            no                     stored
                                     derived
            multivalued
   COMPLEX ATTRIBUTE
    Composite and mutivalued attribute can also be nested
    arbitrarily to form complex key.

                       Areacode

                        Phoneno
                                             Street
           Phone
                                            Apartment
                              Street-add
                                               no

         Address-
          Phone                             State
                          Address
                                             City

                                      Zip
SHOULD ‘ADDRESS’ ATTRIBUTE BE REPRESENTED
       AS SIMPLE ATTRIBUTE OR COMPOSITE?

   Composite attributes are useful to model situations in which
    user refers to the composite attribute as a unit but other
    times refer specifically to it’s components.

   If the composite attribute is to be referenced only as a
    whole then there is no need to represent it in to component
    attributes.

   Ex: if there is no need to refer to the individual components
    of an address ( ZIP, code, street etc) then the whole address
    can be designated as a simple attribute.
RELATIONSHIP TYPE
   When attribute of an entity refers to another entity type
    there exists relationship

   Ex: attribute ‘Manager’ of DEPARTMENT refers to another
    employee who manages the department.

   Attribute ‘Controlling-dep’t refers to another department
    that controls the project.

   In ER diagram these references must be represented as
    relationship and not attributes.
   Ex: Relationship ‘WORKS-FOR’ between EMPLOYEE and
    DEPARTMENT associates each employee with the
    department for he works.

   The relationship is often denoted by diamond symbol and
    are usually verbs.

   Each relationship instance in relationship set WORKS_FOR
    associates one EMPLOYEE entity and one DEPARTMENT
    entity.


                         WORKS-
    EMPLOYEE                                DEPARTMENT
                          FOR
DEGREE OF A RELATIONSHIP
    It is the number of entity types that participate in a relationship

  If there are two entity types involved it is a binary
  relationship type
 If there are three entity types involved it is a ternary
  relationship type
 It is possible to have a n-array relationship (quaternary)




SALESASSIST                   SELLS                   PRODUCT




                             CUSTOMER             Binary-relationship
 Unary relationships are also known as a recursive
  relationship.
 It is a relationship where the same entity participates
  more than once in different roles.
 In the example above we are saying that employees are
  supervised by employees.




                                     SUPERVI
      EMPLOYEE
                                       SION
CARDINALITY CONSTRAINTS

 The number of instances of one entity that can or must be
 associated with each instance of another entity.

 If we have two entity types A and B, the cardinality
  constraint specifies the number of instances of entity B
  that can (or must) be associated with entity A.
 Four possible categories are
  One to one (1:1) relationship
  One to many (1:m) relationship
  Many to one (m:1) relationship
  Many to many (m:n) relationship
   one-to-one

      EMPLOYEE           MANAGES           DEPARTMENT
                     1             1   1


   one to many

                         WORKS-
     EMPLOYEE                              DEPARTMENT
                     N    FOR          1


   many-to-many

                         WORKS-
      EMPLOYEE                               PROJECT
                    M    ON           N
ROLE NAME
   Some entities participate more than once in a relationship
    type in different roles.

 Role name represents role that a participating entity from the entity
 type plays in the relationship.


 Ex: Employee plays the role of supervisor as well as
  supervisee.
 If the participating entity types are distinct then there is
  no need for role name else role name is a must.
PARITICIPATION
           CONSTRAINTS(OPTIONALITY)
    Specifies if existence of an entity depends on it being related to
                      another entity via relationship.



 Specifies minimum number of relationship instances
  each entity can participate in .
 This is called minimum cardinality constraint.
 Two type of the participation are : Total And Partial



                                         TOTAL

             PARTICIPATION

                                        PARTIAL
    Ex: if company policy says that every employee must work for
     the department then participation of employee in work-for is
     total.

                               WORKS-
    EMPLOYEE                                            DEPARTMENT
                                 FOR               1
                     N



    Total participation is also called existence dependencies.
    Every entity in total set of employee must be related to a
     department via WORKS-FOR
    But we can’t say that every employee must MANAGE a
     department .
    Hence relationship is partial.
    Total participation is indicated by double line and partial
     participation by single line.

             Cardinality + Optionality = multiplicity
ATTRIBUTE OF RELATIONSHIP TYPE
 Relationship can also have attributes
 Ex: Hours for WORKS-ON relationship between
  EMPLOYEE and PROJECT


                        WORKS-
    EMPLOYEE                                PROJECT
                         ON




                         Hours
 Attributes of 1:1 or 1:N relationship can be migrated to
  one of the participating entity types.
 Ex: Start-date attributes of MANAGES can be attribute of
  either DEPARTMENT or EMPLOYEE though conceptually
  it belongs to manages.



               1                       1
EMPLOYEE                MANAGES             DEPARTMENT




                        Start-date
   Because each EMPLOYEE MANAGES is a 1:1 relationship.

   So every DEPARTMENT /EMPLOYEE entity participate in
    atmost one relationship instance.

   So value of the Start-date can be determined separately
    either by participating DEPARTMENT entity or
    participating EMPLOYEE entity.
 For 1:N relationship a relationship attribute can be
  migrated only to entity type on N-side of relationship
 Start-date attribute here can added only to employee.




              N         WORKS-          1
EMPLOYEE                                    DEPARTMENT
                         FOR




                        Start-date
 For M:N relationship types some attribute are determined
  by the combination of the participating entities, not by a
  single enity.
 Such attribute must be specified as the relationship
  attributes
 Ex: No.of hours an employee works on is department is
  determent is determined by the EMPLOYEE-PROJECT
  combination.

              M         WORKS-         N
EMPLOYEE                                      PROJECT
                         ON




                         Hours
WEAK ENTITY AND STRONG ENTITY

Entity type that doesn’t have a key attribute on it’s own is
called weak entity and the Regular entity types that have key
value is called strong entities.


 Entity belonging to weak entity type is identified by being
  related to specific entities from another entity type in
  combination with one of their attribute value.
 We call this entity type as identifying or owner entity
  type (Parent/Dominanat Entity type)
 The relationship that connects owner entity type to weak
  entity is called Identifying relationship.
 The weak entities are also called as child entity type or
  subordinate entity type
Weak entities have always a total participating constraint
  because they cannot be identified without an owner entity.



                                                    Relationship


               1                           N
EMPLOYEE                     HAS                  DEPENDENTS


                                                      Dependent-
                                                        name
                                       Employee
    But converse is not true.
    Every existence dependency does not has result is weak
     entities.
    Ex: Driver license entity can’t exist without person entity
     though it has it’s own key (license number)
    There is total participation but not weak entity
    Weak entity type normally has partial
     key(descriminator)

    Partial key are set of attributes that can uniquely identify weak
             entities that are related to some owner entity
   Partial key attribute is denoted with underlined or dotted line.

   Weak entities can sometimes be represented as complex
    attributes (composite and multivalued attributes)

   Choice of the representation is done by DB designer.

   If there are many attributes then we can better represent
    them as weak entity.


   Also if it participates independently in any other
    relationship type other than it’s own identifying
    relationship then it should not be modeled as complex
    attributes.
DESIGN CHOICE FOR ER CONCEPTUAL
           MODEL
  It is very difficult to determine if a particular concept
   must be represented as entity type or attribute or
   relationship type
  Some important concepts to be remembered are:


  A) Concept may be first modeled as an attribute and then
 refined in to a relationship because it is determined that an
 attribute is reference to another attribute . A pair of such
 attribute that are inverses of one another are refined to as
 binary relationship
EMPLOYEE                Department




DEPARTMENT                Employees


             Can be refined to binary relation



                 N           WORKS-              1
EMPLOYEE                                             DEPARTMENT
                              FOR
   B) An attribute that exists in several entity types may be
    elevated or promoted to an independent entity.

   Ex: Suppose several entity types in an UNIVERSITY
    DATABASE such as student , instructor & course each has
    an attribute named department . Then we can better keep
    an entity named department with a single attribute
    department name and relate it to 3 entity types student ,
    instructor & course via appropriate relationship.
INSTRUCTOR                Dept-name


            STUDENT               Dept-name


             COURSE               Dept-name



                  Can be refined as




                      DEPARTMENT



    WORKS               REGISTE               BELONG
                          RED                  S-TO
     -FOR


INSTRUCTOR             STUDENT                 COURSE
   Inverse refinement to previous case:
   If an entity type department exists in initial design
    with a single attribute dept-name and is related to
    only one other entity type student , in this case
    department may be reduced as an attribute of the
    student
ALTERNATE NOTATIONS
   We can also associate pair of integer (min,max) with each
    participation of entity type in a relationship type. These
    are termed structural constraints

             0<=min<=max and max>=1


            Min>0 implies total particiaption
           Min=0 implies partial participation
CHOOSING BETWEEN BINARY AND
    TERNARY RELATIONSHIP
Consider the ER diagram

                             Qty

SUPPLIER            SUPPLY         PROJECT



  Sname
                                    Pname
                      PART



                    Partno
   We can refine it to three binary relations



Sname                                                           Pname
                                          Qty
                                SUPPLI
        SUPPLIER                  ES               PROJECT




             CAN                                         USES
            SUPPLY


                                  PART



                                 Partno
   CAN_SUPPLY relationship between SUPPLIER and PART
    include instances (s,p) whenever SUPPLIER s can supply
    PART p(to any project).

   USES relationship between PROJECT and PART include
    instances (j,p) whenever PROJECT j uses PART p.

   SUPPLIES relationship between SUPPLIER and PROJECT
    include instances (s,j) whenever SUPPLIER s SUPPLIES
    some PART to PROJECT j.

   The existence of relationship instances (s,p) , (j,p) , (s,j)
    does not necessarily imply that the instance (s,j,p) exists
    in ternary relationship supply because meaning is
    different.
   Solution is to include the ternary relationship plus one or
    more of the binary relationship if they represent different
    meaning and all are needed by the application.

   So ternary relationship supply can be represented as the
    weak entity type with three identifying relationship
Qty
 Sname                                           Pname

                    N             N         1
           1
SUPPLIER       SS       SUPPLY        SPJ       PROJECT
                        N


                            SP


                        1

                        PART



                         Partno
DEALING WITH TERNARY RELATIONSHIPS
    Consider the below relationship. ]It is no longer clear which
     sales assistant sold a customer a particular product.
    So try replacing the ternary relations hip with an entity type and
     a set of binary relationships.




       SALES-
                               SELLS                 PRODUCT
     ASSISTANT


          SELLS                                         SELLS

                             CUSTOMER
 The relationship sells can become the entity type sale .
              So a sales assistant can be linked to a specific customer
               and both of them to the sale of a particular product.

  SALES-             MA                             INVO
                                   SALE                        PRODUCT
ASSISSTANT           KES                            LVES




                                   REQ
                                   UEST




                                CUSTOMER
REMOVING REDUNDANT RELATIONSHIP
   Entities can be related indirectly by two relationships.
    A relationship is redundant if it can be completely
    represented by alternate transitive relationships
How to Draw an Effective ER diagram
CONFIRMING OPTIONALITY AND
    CARDINALITY OF RELATIONSHIP
   Use an `entity set diagram' to show entity examples graphically
   Consider the example of `course is_studied_by student'.
 Use the diagram to show all possible relationship
  scenarios.
 Go back to the requirements specification and check to
  see if they are allowed.
 If not, then put a cross through the forbidden
  relationships
 This allows you to show the cardinality and optionality of
  the relationship
How to Draw an Effective ER diagram
DERIVING THE RELATIONSHIP PARAMETERS
    To check we have the correct parameters (sometimes also
     known as the degree) of a relationship, ask two questions:

1.    One course is studied by how many students?

     Answer = `zero or more'.
    This gives us the degree at the `student' end.
    The answer `zero or more' needs to be split into two parts.
    The `more' part means that the cardinality is `many'.
    The `zero' part means that the relationship is `optional'.
    If the answer was `one or more', then the relationship
     would be `mandatory'.
2.One student studies how many courses?

   Answer = `One'
 This gives us the degree at the `course' end of the
  relationship.
 The answer `one' means that the cardinality of this
  relationship is 1, and is `mandatory'
 If the answer had been `zero or one', then the cardinality
  of the relationship would have been 1, and be `optional'.
CONSTRUCTING AN ER MODEL
 Before beginning to draw the ER model, read the
  requirements specification carefully.
 Document any assumptions you need to make.




1.Identify entities
• list all potential entity types. These are the
  object of interest in the system. It is better to
  put too many entities in at this stage and them
  discard them later if necessary.
2.Remove duplicate entities
• Ensure that they really separate entity types or just
  two names for the same thing
• Also do not include the system as an entity type
• e.g. if modelling a library, the entity types might be
  books, borrowers, etc.
• The library is the system, thus should not be an
  entity type.
3.List the attributes of each entity
• Ensure that the entity types are really needed.
• Are any of them just attributes of another entity
  type?
• If so keep them as attributes a nd cross them
  off the entity list.
• Do not have attributes of one entity as
  attributes of another entity!
4.Mark the primary keys
• Which attributes uniquely identify instances of
  that entity type?
• This may not be possible for some weak
  entities.



5.Define the relationships

• Examine each entity type to see its relationship
  to the others.
6.Describe the cardinality and optionality
of the relationships

    • Examine the constraints betwee n participating
      entities.

7.Remove redundant relationships

    • Examine the ER model for redundant
      relationships.

    ER modelling is an iterative process, so draw several
     versions, refining each one until you are happy with it.
     Note that there is no one right answer to the problem, but
     some solutions are better than others!
EXAMPLE
           “A Country Bus Company owns a number of busses.
    Each bus is allocated to a particular route, although some
    routes may have several busses. Each route passes through
    a number of towns. One or more drivers are allocated to
    each stage of a route, which corresponds to a journey
    through some or all of the towns on a route. Some of the
    towns have a garage where busses are kept and each of the
    busses are identified by the registration number and can
    carry different numbers of passengers, since the vehicles
    vary in size and can be single or double-decked. Each route
    is identified by a route number and information is available
    on the average number of passengers carried per day for
    each route. Drivers have an employee number, name ,
    address, and sometimes a telephone number.”
ENTITIES

   Bus - Company owns busses and will hold information
    about them.
   Route - Buses travel on routes and will need described.
   Town - Buses pass through towns and need to know about
    them
   Driver - Company employs drivers, personnel will hold
    their data.
   Stage - Routes are made up of stages
   Garage - Garage houses buses, and need to know where
    they are.
RELATIONSHIPS

 A bus is allocated to a route and a route may have several
  buses.
   Bus-route (m:1) - is serviced by
 A route comprises of one or more stages.
   route-stage (1:m) comprises
 One or more drivers are allocated to each stage.
   driver-stage (m:1) is allocated
 A stage passes through some or all of the towns on a
  route.
   stage-town (m:n) passes-through
 A route passes through some or all of the towns
  route-town (m:n) passes-through
 Some of the towns have a garage
   garage-town (1:1) is situated
 A garage keeps buses and each bus has one `home' garage
   garage-bus (m:1) is garaged
ER DIAGRAM
ATTRIBUTES
   Bus (reg- no,make,size,deck,no-pass)
   Route (route-no,avg-pass)
   Driver (emp - no,name,address,tel-no)
   Town (name)
   Stage (stage - no)
   Garage (name,address)
ALTERNATIVE DIAGRAMATIC NOTATIONS
         FOR ER MODELS
How to Draw an Effective ER diagram
How to Draw an Effective ER diagram
How to Draw an Effective ER diagram
Symbols for entity type attribute and relationship




             Displaying attributes
Various (min, max) notations
CROW-FOOT NOTATION
ENHANCED ER DIAGRAM

The EER diagram includes the concepts of



         Subclass and super class
    Specialization and Generalization
              Categorization
  Attribute and relationship inheritance.
SUBCLASS SUPERCLASS AND
         INHERITANCE
   In many cases entity types has numerous sub grouping of
    it’s entities that are meaningful and need to be
    represented explicitly because of their significance to
    database application.
 Here each of the sub groupings is called subclass of the
  EMPLOYEE entity type.
 EMPLOYEE entity type is called super class for each of
  these subclasses
 The relationship between super class and any one of it’s
  subclass is called the super class/subclass or simply
  class/subclass relationship.


    Member entity of the subclass represents the same real world
    entity as some member of superclass and the Subclass entity
    has specific distinct role
 An entity that is a member of subclass is also a member of
  super class and can optionally be member of any number
  of subclasses.
 Important concept associated with subclass is type
  inheritance.
 Subclass entity possess it’s own attributes as well inherits
  all the attributes possessed by it’s superclass.
 The entity also inherits the relationships that superclass
  participtes
SPECIALIZATION
Specialisation is a process of defining set of subclasses of an
entity type.


 This entity type is called superclass of the specialisation.
 Set of subclasses that form specialisation is defined based
  on some distinguishing characters of entities in the
  superclass.
 Ex: Job type , method-of-pay
   The subclass that defines a specialisation are attached by
    line to circle to represent the specialisation,which is
    connected to superclass.

   The subset symbol on each line connecting a subclass to
    the circle indicates direction of the superclass/subclass
    relationship.

   Attributes that apply only to entities of particular entity
    types – specific/local attributes.

   Subclass also participates in specific relationships.
WHY INCLUDE SPECIALISATION CONCEPT?


   1. Certain attributes may apply only to
   specific entity.

   • A subclass is defined to group the entities
     to which the attributes apply.


   2. Some relationship types may be
   participated in by only specific entities.
IN SPECIALISATION:

   1.Define a set of subclass of entity type



   2. Establish additional specific attributes with each
   subclass


   3.Establish additional specific relationship types
   between each subclass and other entity types or
   other subclass
GENERALISATION

            The reverse process of abstraction in which we suppress the
            differences among several entity types, identify their common
            features and generalize them in to single super class of which
            original entity types are special subclasses.



         Vehicle-
                            Price                     Vehicle-id        Price
           id

No-of-
 pass               CAR             Licens                    TRUCK             License
                                     e-no                                         -no


                    Max-                     No-of-
                    speed                    axles            Tonnage
Licens
                             e-no
                 Vehicle-
                                     Price
                   id


                       VEHICLE




                            d



No-of-
 pass    CAR                                   TRUCK



         Max-                    No-of-axles           Tonnage
         speed
CONSTRAINTS ON SPECIALIZATION AND
          GENERALIZATION
Predicate-defined   Attribute defined-     User-defined
   subclasses         specialization         subclass
• Determine         • Membership         • no condition
  exactly those       condition for        determines
  entities that       subclasses on        membership
  will become         same attribute     • Membership in
  members of          of the super         a subclass is
  each subclass       class                determined by
  by a condition.   • Attribute is         the database
                      called the           users by
                      defining             applying an
                      attribute of the     operation to
                      specialization       add an entity to
                    • Example:             the subclass
                      JobType
   Hence, we have four types of specialization/generalization
    based on the paticipation of superclass entities in sub classes:

       Disjoint, total
       Disjoint, partial
       Overlapping, total
       Overlapping, partial



Generalization usually is total because the superclass is derived
from the subclasses.
Example of disjoint partial Specialization
SPECIALIZATION / GENERALIZATION
          HIERARCHIES, LATTICES

  A subclass may itself have further subclasses specified on it
  Forms a hierarchy or a lattice.


Hierarchy has a constraint that every subclass has only one
superclass (called single inheritance)


      In a lattice, a subclass can be subclass of more than one
      superclass (called multiple inheritance)
   In a lattice or hierarchy, a subclass inherits attributes not
    only of its direct superclass, but also of all its
    predecessor superclasses

   In specialization, start with an entity type and then define
    subclasses of the entity type by successive specialization
    (top down conceptual refinement process)

   In generalization, start with many entity types and
    generalize those that have common properties (bottom
    up conceptual synthesis process).

   A subclass with more than one superclass is called a
    shared subclass
SPECIALIZATION / GENERALIZATION LATTICE
          EXAMPLE (UNIVERSITY)
CATEGORIES (UNION TYPES)
Model a single super class /subclass relationship with more
than one super class

  Super classes represent different entity types .
  Example:
   Database for vehicle registration, vehicle owner can be a
   person, a bank (holding a lien on a vehicle) or a company.
   ◦ Category (subclass) OWNER is a subset of the union of
     the three super classes COMPANY, BANK, and PERSON
   ◦ A category member must exist in at least one of its
     super classes

This is difference from shared subclass, which is subset of the
intersection of its super classes (shared subclass member must
exist in all of its super classes).
How to Draw an Effective ER diagram
CASE IN POINT: E-R MODEL FOR
 ONLINE SALES FOR BIGHIT VIDEO
 “    BigHit Video Inc. wants to create an information system
for online sales of movies in both DVD and videotape format.
People will be allowed to register as customers of the online site
and to update their stored information. Informa-tion must be
maintained about customers ’ shipping addresses, e-mail ad-
dresses and credit cards. In a single sale, customers will be
allowed to purchase any quantity of videos. The items in a
single sale will be shipped to a single address and will have a
single credit card charge A customer will be provided with a
virtual shopping cart to store items to be purchased. As each
item is selected, it is added to the shopping cart. When the
customer finishes shopping, he will be directed to a checkout
area where he can purchase all of the items in the shopping
cart. At this time, payment and shipping information is entered.
Once the sale is complete, the shopping cart will be deleted and
the customer will be sent a receipt by e-mail.”
IDENTIFY ENTITY AND ATTRIBUTES   ENTITY       ATTRIBUTE           CONSTRAINTS
                                 1.Customer   accountId           Key
                                              lastName            Not null
                                              firstName
                                              shippingAddresses   Multivalued
                                                                  composite with
                                                                  components name,
                                                                  street, city,
                                                                  state, zipcode
                                              emailAddress
                                              creditCards         Multivalued
                                                                  composite with
                                                                  components type,
                                                                  accountNumber ,
                                                                  expiration
                                              password            Not null at least 6
                                                                  characters
ENTITY         ATTRIBUTE     CONSTRAINTS
2. Movie       Movieid       Key
               Title
               Genre
               Media         Either “dvd” or
                             “videotape”
                             determines
                             subclass
3. DVD         Languages     Subclass of Movie
               Videoformat
               Captioning
4. Videotape   Format        Subclass of Movie
               Soundtrack
ENTITY            ATTRIBUTE     CONSTRAINTS
5. Sale           SaleId        Key
                  Totalcost
                  DateSold
                  CreditCard    Composite with
                                components type,
                                accountNumber ,
                                and expiration
6. ShoppingCart   CartId        key
                  DateCreated
Relationsh Entity    Entity     Cardinali Attributes
RELATIONSHIPS

                ip Type    Class     Class      ty Ratio
                Purchases   Customer Sale       one-to-
                                                many
                Includes    Sale     Movie      many-to-   quantity
                                                many
                Selects     Customer Shopping   one-to-
                                     Cart       many
                Includes    Movie    Shopping   many-to-   quantity
                                     Cart       many
How to Draw an Effective ER diagram
THANK YOU

More Related Content

What's hot

Entity Relationship Model
Entity Relationship ModelEntity Relationship Model
Entity Relationship ModelSlideshare
 
Entity Relationship Diagram
Entity Relationship DiagramEntity Relationship Diagram
Entity Relationship DiagramShakila Mahjabin
 
Database - Entity Relationship Diagram (ERD)
Database - Entity Relationship Diagram (ERD)Database - Entity Relationship Diagram (ERD)
Database - Entity Relationship Diagram (ERD)Mudasir Qazi
 
Entity Relationship Diagrams
Entity Relationship DiagramsEntity Relationship Diagrams
Entity Relationship Diagramssadique_ghitm
 
Entity Relationship Diagram
Entity Relationship DiagramEntity Relationship Diagram
Entity Relationship DiagramSiti Ismail
 
Data modeling using the entity relationship model
Data modeling using the entity relationship modelData modeling using the entity relationship model
Data modeling using the entity relationship modelJafar Nesargi
 
Data Modeling PPT
Data Modeling PPTData Modeling PPT
Data Modeling PPTTrinath
 
Desigining of Database - ER Model
Desigining of Database - ER ModelDesigining of Database - ER Model
Desigining of Database - ER ModelAjay Chhimpa
 
Object oriented database model
Object oriented database modelObject oriented database model
Object oriented database modelPAQUIAAIZEL
 
E-R diagram in Database
E-R diagram in DatabaseE-R diagram in Database
E-R diagram in DatabaseFatiha Qureshi
 
Chapter10 conceptual data modeling
Chapter10 conceptual data modelingChapter10 conceptual data modeling
Chapter10 conceptual data modelingDhani Ahmad
 
Relational Data Model Introduction
Relational Data Model IntroductionRelational Data Model Introduction
Relational Data Model IntroductionNishant Munjal
 

What's hot (20)

Entity Relationship Model
Entity Relationship ModelEntity Relationship Model
Entity Relationship Model
 
Entity Relationship Diagram
Entity Relationship DiagramEntity Relationship Diagram
Entity Relationship Diagram
 
Database - Entity Relationship Diagram (ERD)
Database - Entity Relationship Diagram (ERD)Database - Entity Relationship Diagram (ERD)
Database - Entity Relationship Diagram (ERD)
 
Entity Relationship Diagrams
Entity Relationship DiagramsEntity Relationship Diagrams
Entity Relationship Diagrams
 
Entity Relationship Diagram
Entity Relationship DiagramEntity Relationship Diagram
Entity Relationship Diagram
 
Entity relationship diagram (erd)
Entity relationship diagram (erd)Entity relationship diagram (erd)
Entity relationship diagram (erd)
 
Entity relationship modelling
Entity relationship modellingEntity relationship modelling
Entity relationship modelling
 
ER-Model-ER Diagram
ER-Model-ER DiagramER-Model-ER Diagram
ER-Model-ER Diagram
 
Uml class-diagram
Uml class-diagramUml class-diagram
Uml class-diagram
 
Data modeling using the entity relationship model
Data modeling using the entity relationship modelData modeling using the entity relationship model
Data modeling using the entity relationship model
 
Data Modeling PPT
Data Modeling PPTData Modeling PPT
Data Modeling PPT
 
Er diagrams presentation
Er diagrams presentationEr diagrams presentation
Er diagrams presentation
 
ER Diagram
ER DiagramER Diagram
ER Diagram
 
Desigining of Database - ER Model
Desigining of Database - ER ModelDesigining of Database - ER Model
Desigining of Database - ER Model
 
Object oriented database model
Object oriented database modelObject oriented database model
Object oriented database model
 
E-R diagram in Database
E-R diagram in DatabaseE-R diagram in Database
E-R diagram in Database
 
Chapter10 conceptual data modeling
Chapter10 conceptual data modelingChapter10 conceptual data modeling
Chapter10 conceptual data modeling
 
The Relational Model
The Relational ModelThe Relational Model
The Relational Model
 
Relational Data Model Introduction
Relational Data Model IntroductionRelational Data Model Introduction
Relational Data Model Introduction
 
Use case diagram
Use case diagramUse case diagram
Use case diagram
 

Viewers also liked

DBMS topics for BCA
DBMS topics for BCADBMS topics for BCA
DBMS topics for BCAAdbay
 
Project of Airline booking system
Project of Airline booking systemProject of Airline booking system
Project of Airline booking systemmuthahar.sk
 
Hotel reservation system
Hotel reservation systemHotel reservation system
Hotel reservation systemManoj Malshan
 
File organization 1
File organization 1File organization 1
File organization 1Rupali Rana
 
Ciri – ciri negara
Ciri – ciri negara Ciri – ciri negara
Ciri – ciri negara munnianwar
 
Ciri ciri Negara Malaysia
Ciri ciri  Negara MalaysiaCiri ciri  Negara Malaysia
Ciri ciri Negara Malaysiamunnianwar
 
Majlis raja raja
Majlis raja rajaMajlis raja raja
Majlis raja rajamunnianwar
 
Proses pembentukan malaysia
Proses pembentukan malaysiaProses pembentukan malaysia
Proses pembentukan malaysiamunnianwar
 
Entity relationship diagram (erd)
Entity relationship diagram (erd)Entity relationship diagram (erd)
Entity relationship diagram (erd)tameemyousaf
 
Badan Perundangan Parlimen
Badan Perundangan ParlimenBadan Perundangan Parlimen
Badan Perundangan Parlimenmunnianwar
 
Yang di pertuan agong
Yang di pertuan agongYang di pertuan agong
Yang di pertuan agongmunnianwar
 
Kerajaan negeri
Kerajaan negeriKerajaan negeri
Kerajaan negerimunnianwar
 

Viewers also liked (20)

Home delivery restaurants
Home delivery restaurantsHome delivery restaurants
Home delivery restaurants
 
Online computer shop 111 35-181
Online computer shop 111 35-181Online computer shop 111 35-181
Online computer shop 111 35-181
 
DBMS topics for BCA
DBMS topics for BCADBMS topics for BCA
DBMS topics for BCA
 
Erd practice exercises
Erd practice exercisesErd practice exercises
Erd practice exercises
 
Project of Airline booking system
Project of Airline booking systemProject of Airline booking system
Project of Airline booking system
 
Hotel reservation system
Hotel reservation systemHotel reservation system
Hotel reservation system
 
Erd cardinality
Erd cardinalityErd cardinality
Erd cardinality
 
File organization 1
File organization 1File organization 1
File organization 1
 
Airlines Database Design
Airlines Database DesignAirlines Database Design
Airlines Database Design
 
File organization
File organizationFile organization
File organization
 
Ciri – ciri negara
Ciri – ciri negara Ciri – ciri negara
Ciri – ciri negara
 
Ciri ciri Negara Malaysia
Ciri ciri  Negara MalaysiaCiri ciri  Negara Malaysia
Ciri ciri Negara Malaysia
 
Majlis raja raja
Majlis raja rajaMajlis raja raja
Majlis raja raja
 
Proses pembentukan malaysia
Proses pembentukan malaysiaProses pembentukan malaysia
Proses pembentukan malaysia
 
Perlembagaan
PerlembagaanPerlembagaan
Perlembagaan
 
Entity relationship diagram (erd)
Entity relationship diagram (erd)Entity relationship diagram (erd)
Entity relationship diagram (erd)
 
Badan Perundangan Parlimen
Badan Perundangan ParlimenBadan Perundangan Parlimen
Badan Perundangan Parlimen
 
Yang di pertuan agong
Yang di pertuan agongYang di pertuan agong
Yang di pertuan agong
 
Kerajaan negeri
Kerajaan negeriKerajaan negeri
Kerajaan negeri
 
Kabinet
KabinetKabinet
Kabinet
 

Similar to How to Draw an Effective ER diagram

ERD with complete knowledge
ERD with complete knowledgeERD with complete knowledge
ERD with complete knowledgeAsma Rasool
 
39f1b9a797dbms chapter2 b.sc2
39f1b9a797dbms chapter2 b.sc239f1b9a797dbms chapter2 b.sc2
39f1b9a797dbms chapter2 b.sc2Mukund Trivedi
 
39f1b9a797dbms chapter2 b.sc2 (1)
39f1b9a797dbms chapter2 b.sc2 (1)39f1b9a797dbms chapter2 b.sc2 (1)
39f1b9a797dbms chapter2 b.sc2 (1)Mukund Trivedi
 
Fundamentals of database system - Data Modeling Using the Entity-Relationshi...
Fundamentals of database system  - Data Modeling Using the Entity-Relationshi...Fundamentals of database system  - Data Modeling Using the Entity-Relationshi...
Fundamentals of database system - Data Modeling Using the Entity-Relationshi...Mustafa Kamel Mohammadi
 
Entity Relationship Model
Entity Relationship ModelEntity Relationship Model
Entity Relationship ModelA. S. M. Shafi
 
3. Chapter Three.pdf
3. Chapter Three.pdf3. Chapter Three.pdf
3. Chapter Three.pdffikadumola
 
ER Modelling
ER ModellingER Modelling
ER Modellinglubna19
 
Chapter-3 Data Modeling Using the Entity-Relationship Model
Chapter-3  Data Modeling Using the Entity-Relationship ModelChapter-3  Data Modeling Using the Entity-Relationship Model
Chapter-3 Data Modeling Using the Entity-Relationship ModelRaj vardhan
 
Jobs manager vs supervisor.pptx
Jobs manager vs supervisor.pptxJobs manager vs supervisor.pptx
Jobs manager vs supervisor.pptxprosofts1
 
Unit 2-Data Modeling.pdf
Unit 2-Data Modeling.pdfUnit 2-Data Modeling.pdf
Unit 2-Data Modeling.pdfMaryJacob24
 
ECEG 4702-Class7-Entity-Relationship modeling.pptx
ECEG 4702-Class7-Entity-Relationship modeling.pptxECEG 4702-Class7-Entity-Relationship modeling.pptx
ECEG 4702-Class7-Entity-Relationship modeling.pptxmiftah88
 

Similar to How to Draw an Effective ER diagram (20)

ERD with complete knowledge
ERD with complete knowledgeERD with complete knowledge
ERD with complete knowledge
 
39f1b9a797dbms chapter2 b.sc2
39f1b9a797dbms chapter2 b.sc239f1b9a797dbms chapter2 b.sc2
39f1b9a797dbms chapter2 b.sc2
 
39f1b9a797dbms chapter2 b.sc2 (1)
39f1b9a797dbms chapter2 b.sc2 (1)39f1b9a797dbms chapter2 b.sc2 (1)
39f1b9a797dbms chapter2 b.sc2 (1)
 
Chapter3
Chapter3Chapter3
Chapter3
 
Chapter3
Chapter3Chapter3
Chapter3
 
Erm
ErmErm
Erm
 
Erm
ErmErm
Erm
 
Fundamentals of database system - Data Modeling Using the Entity-Relationshi...
Fundamentals of database system  - Data Modeling Using the Entity-Relationshi...Fundamentals of database system  - Data Modeling Using the Entity-Relationshi...
Fundamentals of database system - Data Modeling Using the Entity-Relationshi...
 
Entity Relationship Model
Entity Relationship ModelEntity Relationship Model
Entity Relationship Model
 
27 fcs157al3
27 fcs157al327 fcs157al3
27 fcs157al3
 
Lecture one db
Lecture one dbLecture one db
Lecture one db
 
3. Chapter Three.pdf
3. Chapter Three.pdf3. Chapter Three.pdf
3. Chapter Three.pdf
 
ER Modelling
ER ModellingER Modelling
ER Modelling
 
Chapter-3 Data Modeling Using the Entity-Relationship Model
Chapter-3  Data Modeling Using the Entity-Relationship ModelChapter-3  Data Modeling Using the Entity-Relationship Model
Chapter-3 Data Modeling Using the Entity-Relationship Model
 
Database Modeling
Database ModelingDatabase Modeling
Database Modeling
 
ERD.pptx
ERD.pptxERD.pptx
ERD.pptx
 
Jobs manager vs supervisor.pptx
Jobs manager vs supervisor.pptxJobs manager vs supervisor.pptx
Jobs manager vs supervisor.pptx
 
Unit 2-Data Modeling.pdf
Unit 2-Data Modeling.pdfUnit 2-Data Modeling.pdf
Unit 2-Data Modeling.pdf
 
Erm
ErmErm
Erm
 
ECEG 4702-Class7-Entity-Relationship modeling.pptx
ECEG 4702-Class7-Entity-Relationship modeling.pptxECEG 4702-Class7-Entity-Relationship modeling.pptx
ECEG 4702-Class7-Entity-Relationship modeling.pptx
 

More from Tech_MX

Virtual base class
Virtual base classVirtual base class
Virtual base classTech_MX
 
Theory of estimation
Theory of estimationTheory of estimation
Theory of estimationTech_MX
 
Templates in C++
Templates in C++Templates in C++
Templates in C++Tech_MX
 
String & its application
String & its applicationString & its application
String & its applicationTech_MX
 
Statistical quality__control_2
Statistical  quality__control_2Statistical  quality__control_2
Statistical quality__control_2Tech_MX
 
Stack data structure
Stack data structureStack data structure
Stack data structureTech_MX
 
Stack Data Structure & It's Application
Stack Data Structure & It's Application Stack Data Structure & It's Application
Stack Data Structure & It's Application Tech_MX
 
Spanning trees & applications
Spanning trees & applicationsSpanning trees & applications
Spanning trees & applicationsTech_MX
 
Set data structure 2
Set data structure 2Set data structure 2
Set data structure 2Tech_MX
 
Set data structure
Set data structure Set data structure
Set data structure Tech_MX
 
Real time Operating System
Real time Operating SystemReal time Operating System
Real time Operating SystemTech_MX
 
Mouse interrupts (Assembly Language & C)
Mouse interrupts (Assembly Language & C)Mouse interrupts (Assembly Language & C)
Mouse interrupts (Assembly Language & C)Tech_MX
 
Motherboard of a pc
Motherboard of a pcMotherboard of a pc
Motherboard of a pcTech_MX
 
More on Lex
More on LexMore on Lex
More on LexTech_MX
 
MultiMedia dbms
MultiMedia dbmsMultiMedia dbms
MultiMedia dbmsTech_MX
 
Merging files (Data Structure)
Merging files (Data Structure)Merging files (Data Structure)
Merging files (Data Structure)Tech_MX
 
Memory dbms
Memory dbmsMemory dbms
Memory dbmsTech_MX
 

More from Tech_MX (20)

Virtual base class
Virtual base classVirtual base class
Virtual base class
 
Uid
UidUid
Uid
 
Theory of estimation
Theory of estimationTheory of estimation
Theory of estimation
 
Templates in C++
Templates in C++Templates in C++
Templates in C++
 
String & its application
String & its applicationString & its application
String & its application
 
Statistical quality__control_2
Statistical  quality__control_2Statistical  quality__control_2
Statistical quality__control_2
 
Stack data structure
Stack data structureStack data structure
Stack data structure
 
Stack Data Structure & It's Application
Stack Data Structure & It's Application Stack Data Structure & It's Application
Stack Data Structure & It's Application
 
Spss
SpssSpss
Spss
 
Spanning trees & applications
Spanning trees & applicationsSpanning trees & applications
Spanning trees & applications
 
Set data structure 2
Set data structure 2Set data structure 2
Set data structure 2
 
Set data structure
Set data structure Set data structure
Set data structure
 
Real time Operating System
Real time Operating SystemReal time Operating System
Real time Operating System
 
Parsing
ParsingParsing
Parsing
 
Mouse interrupts (Assembly Language & C)
Mouse interrupts (Assembly Language & C)Mouse interrupts (Assembly Language & C)
Mouse interrupts (Assembly Language & C)
 
Motherboard of a pc
Motherboard of a pcMotherboard of a pc
Motherboard of a pc
 
More on Lex
More on LexMore on Lex
More on Lex
 
MultiMedia dbms
MultiMedia dbmsMultiMedia dbms
MultiMedia dbms
 
Merging files (Data Structure)
Merging files (Data Structure)Merging files (Data Structure)
Merging files (Data Structure)
 
Memory dbms
Memory dbmsMemory dbms
Memory dbms
 

Recently uploaded

Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdfPedro Manuel
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostMatt Ray
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
RAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIRAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIUdaiappa Ramachandran
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?SANGHEE SHIN
 
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataCloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataSafe Software
 
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdfJamie (Taka) Wang
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfinfogdgmi
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...Aggregage
 
Introduction to Quantum Computing
Introduction to Quantum ComputingIntroduction to Quantum Computing
Introduction to Quantum ComputingGDSC PJATK
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesMd Hossain Ali
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsSeth Reyes
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding TeamAdam Moalla
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationIES VE
 
Things you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceThings you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceMartin Humpolec
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.YounusS2
 
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServicePicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServiceRenan Moreira de Oliveira
 

Recently uploaded (20)

Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
Nanopower In Semiconductor Industry.pdf
Nanopower  In Semiconductor Industry.pdfNanopower  In Semiconductor Industry.pdf
Nanopower In Semiconductor Industry.pdf
 
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCostKubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
KubeConEU24-Monitoring Kubernetes and Cloud Spend with OpenCost
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
RAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AIRAG Patterns and Vector Search in Generative AI
RAG Patterns and Vector Search in Generative AI
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?Do we need a new standard for visualizing the invisible?
Do we need a new standard for visualizing the invisible?
 
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial DataCloud Revolution: Exploring the New Wave of Serverless Spatial Data
Cloud Revolution: Exploring the New Wave of Serverless Spatial Data
 
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
20200723_insight_release_plan_v6.pdf20200723_insight_release_plan_v6.pdf
 
Videogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdfVideogame localization & technology_ how to enhance the power of translation.pdf
Videogame localization & technology_ how to enhance the power of translation.pdf
 
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
The Data Metaverse: Unpacking the Roles, Use Cases, and Tech Trends in Data a...
 
Introduction to Quantum Computing
Introduction to Quantum ComputingIntroduction to Quantum Computing
Introduction to Quantum Computing
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just MinutesAI Fame Rush Review – Virtual Influencer Creation In Just Minutes
AI Fame Rush Review – Virtual Influencer Creation In Just Minutes
 
Computer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and HazardsComputer 10: Lesson 10 - Online Crimes and Hazards
Computer 10: Lesson 10 - Online Crimes and Hazards
 
9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team9 Steps For Building Winning Founding Team
9 Steps For Building Winning Founding Team
 
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve DecarbonizationUsing IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
Using IESVE for Loads, Sizing and Heat Pump Modeling to Achieve Decarbonization
 
Things you didn't know you can use in your Salesforce
Things you didn't know you can use in your SalesforceThings you didn't know you can use in your Salesforce
Things you didn't know you can use in your Salesforce
 
Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.Basic Building Blocks of Internet of Things.
Basic Building Blocks of Internet of Things.
 
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer ServicePicPay - GenAI Finance Assistant - ChatGPT for Customer Service
PicPay - GenAI Finance Assistant - ChatGPT for Customer Service
 

How to Draw an Effective ER diagram

  • 2. DATABASE ARCHITECTURE External level – concerned with the way individual users see the data Conceptual level – can be regarded as a community user view a formal description of data of interest to the organization Internal level – concerned with the way in which the data is actually stored
  • 3. In 1967 Peter Chen developed the ER Model.  It is a high level data model used for developing the conceptual design of the database.  ER diagram helps designers understand and specify the desired components of database and the relationship among them.  It must be flexible enough so that it can be used and understood in practically any environment where information is modelled
  • 4. ENTITY  It is a real world item / concept that can exist on it’s own.  It may be an object with physical existence ( person, house) or it may be an object with conceptual existence (company ,job, university course) ENTITY TYPE  Entity type defines collection of entities that have same attribute.  Entity type in a database is defined by it’s name and attribute.  Entity instance is a single occurrence of an entity type.
  • 5. ENTITY SET  Collection of entities of a particular entity type in a database at any point of time is called entity set  Entity set is usually referred to by same name as the entity type STUDENT Entity type  Entity type is represented as rectangle enclosing the type name which is singular noun.
  • 6. ATTRIBUTE  Attributes are the properties that describe the entities.  Attribute names are enclosed by ovals and connected to their entities by single line.  Set of attribute values of a given attribute is the value set or domain Ssn EMPLOYEE Salary Bdate
  • 7. SIMPLE ATTRIBUTE COMPOSITE ATTRIBUTE • Cannot be split in to further • Can be divided in to smaller attributes(indivisible) subparts which represent • Also known as Atomic more basic attributes with attribute independent meaning • Ex: Ssn(Social Security • Even form hierarchy Number) • Value of the composite attribute is the composition of the constituent simple attributes • Ex: Address
  • 8. SINGLE VALUED ATTRIBUTE MULTI VALUED ATTRIBUTE • Attributes having single • Attribute having set of value for particular entity. values • Ex - Age • Denoted by double circled oval • Ex: Phone-number, College- degree DERIVED ATTRIBUTE STORED ATTRIBUTE • Attribute values are derived • Attributes from which the from another attribute. values of other attributes • Denoted by dotted oval are derived • Ex - Age • Ex: Bdate
  • 9. IDENTIFIER ATTRIBUTE OR KEY ATTRIBUTE Key • Data item that allows us to uniquely identify individual occurrences or an entity type. Superkey • Attribute or set of attributes that uniquely identify a tuple. Candidate key • Minimal super key with the property of irredusability and uniqueness Primary key • An entity type may have one or more possible candidate keys, the one which is selected as primary key. Composite key • candidate key that consisting of two or more attributes Foreign key • An attribute or set of attribute that matches the candidate key or other or same relation The name of each primary key attribute is underlined.
  • 10. SIMPLE KEY ATTRIBUTE Rollno Name STUDENT COMPOSITE KEY ATTRIBUTE Date No-of- Flightid passengers Flightno FLIGHT
  • 11. CRITERIA FOR SELECTING IDENTIFIERS Some entities have more than one candidate identifier, so the following criteria should be used:  Choose identifier that will not change in value over the life of each instance of the entity type  Choose identifier that is guaranteed to have valid values and will not be null (or unknown). If composite, make sure all parts will have valid values
  • 12. Avoid the use of intelligent identifiers whose structure indicates classifications, locations or people that might change. e.g. the first two digits of an identifier may indicate a warehouse location, but such codes are often changed as conditions change, which renders them invalid.
  • 13. Composite- hierarchy City Street State Address Primary-key Street- Apartme add Ssn nt-no EMPLOYEE Salary Bdate Phone- Age no stored derived multivalued
  • 14. COMPLEX ATTRIBUTE Composite and mutivalued attribute can also be nested arbitrarily to form complex key. Areacode Phoneno Street Phone Apartment Street-add no Address- Phone State Address City Zip
  • 15. SHOULD ‘ADDRESS’ ATTRIBUTE BE REPRESENTED AS SIMPLE ATTRIBUTE OR COMPOSITE?  Composite attributes are useful to model situations in which user refers to the composite attribute as a unit but other times refer specifically to it’s components.  If the composite attribute is to be referenced only as a whole then there is no need to represent it in to component attributes.  Ex: if there is no need to refer to the individual components of an address ( ZIP, code, street etc) then the whole address can be designated as a simple attribute.
  • 16. RELATIONSHIP TYPE  When attribute of an entity refers to another entity type there exists relationship  Ex: attribute ‘Manager’ of DEPARTMENT refers to another employee who manages the department.  Attribute ‘Controlling-dep’t refers to another department that controls the project.  In ER diagram these references must be represented as relationship and not attributes.
  • 17. Ex: Relationship ‘WORKS-FOR’ between EMPLOYEE and DEPARTMENT associates each employee with the department for he works.  The relationship is often denoted by diamond symbol and are usually verbs.  Each relationship instance in relationship set WORKS_FOR associates one EMPLOYEE entity and one DEPARTMENT entity. WORKS- EMPLOYEE DEPARTMENT FOR
  • 18. DEGREE OF A RELATIONSHIP It is the number of entity types that participate in a relationship  If there are two entity types involved it is a binary relationship type  If there are three entity types involved it is a ternary relationship type  It is possible to have a n-array relationship (quaternary) SALESASSIST SELLS PRODUCT CUSTOMER Binary-relationship
  • 19.  Unary relationships are also known as a recursive relationship.  It is a relationship where the same entity participates more than once in different roles.  In the example above we are saying that employees are supervised by employees. SUPERVI EMPLOYEE SION
  • 20. CARDINALITY CONSTRAINTS The number of instances of one entity that can or must be associated with each instance of another entity.  If we have two entity types A and B, the cardinality constraint specifies the number of instances of entity B that can (or must) be associated with entity A.  Four possible categories are One to one (1:1) relationship One to many (1:m) relationship Many to one (m:1) relationship Many to many (m:n) relationship
  • 21. one-to-one EMPLOYEE MANAGES DEPARTMENT 1 1 1  one to many WORKS- EMPLOYEE DEPARTMENT N FOR 1  many-to-many WORKS- EMPLOYEE PROJECT  M ON N
  • 22. ROLE NAME  Some entities participate more than once in a relationship type in different roles. Role name represents role that a participating entity from the entity type plays in the relationship.  Ex: Employee plays the role of supervisor as well as supervisee.  If the participating entity types are distinct then there is no need for role name else role name is a must.
  • 23. PARITICIPATION CONSTRAINTS(OPTIONALITY) Specifies if existence of an entity depends on it being related to another entity via relationship.  Specifies minimum number of relationship instances each entity can participate in .  This is called minimum cardinality constraint.  Two type of the participation are : Total And Partial TOTAL PARTICIPATION PARTIAL
  • 24. Ex: if company policy says that every employee must work for the department then participation of employee in work-for is total.  WORKS- EMPLOYEE DEPARTMENT FOR 1 N  Total participation is also called existence dependencies.  Every entity in total set of employee must be related to a department via WORKS-FOR  But we can’t say that every employee must MANAGE a department .  Hence relationship is partial.  Total participation is indicated by double line and partial participation by single line. Cardinality + Optionality = multiplicity
  • 25. ATTRIBUTE OF RELATIONSHIP TYPE  Relationship can also have attributes  Ex: Hours for WORKS-ON relationship between EMPLOYEE and PROJECT WORKS- EMPLOYEE PROJECT ON Hours
  • 26.  Attributes of 1:1 or 1:N relationship can be migrated to one of the participating entity types.  Ex: Start-date attributes of MANAGES can be attribute of either DEPARTMENT or EMPLOYEE though conceptually it belongs to manages. 1 1 EMPLOYEE MANAGES DEPARTMENT Start-date
  • 27. Because each EMPLOYEE MANAGES is a 1:1 relationship.  So every DEPARTMENT /EMPLOYEE entity participate in atmost one relationship instance.  So value of the Start-date can be determined separately either by participating DEPARTMENT entity or participating EMPLOYEE entity.
  • 28.  For 1:N relationship a relationship attribute can be migrated only to entity type on N-side of relationship  Start-date attribute here can added only to employee. N WORKS- 1 EMPLOYEE DEPARTMENT FOR Start-date
  • 29.  For M:N relationship types some attribute are determined by the combination of the participating entities, not by a single enity.  Such attribute must be specified as the relationship attributes  Ex: No.of hours an employee works on is department is determent is determined by the EMPLOYEE-PROJECT combination. M WORKS- N EMPLOYEE PROJECT ON Hours
  • 30. WEAK ENTITY AND STRONG ENTITY Entity type that doesn’t have a key attribute on it’s own is called weak entity and the Regular entity types that have key value is called strong entities.  Entity belonging to weak entity type is identified by being related to specific entities from another entity type in combination with one of their attribute value.  We call this entity type as identifying or owner entity type (Parent/Dominanat Entity type)  The relationship that connects owner entity type to weak entity is called Identifying relationship.  The weak entities are also called as child entity type or subordinate entity type
  • 31. Weak entities have always a total participating constraint because they cannot be identified without an owner entity. Relationship 1 N EMPLOYEE HAS DEPENDENTS Dependent- name Employee
  • 32. But converse is not true.  Every existence dependency does not has result is weak entities.  Ex: Driver license entity can’t exist without person entity though it has it’s own key (license number)  There is total participation but not weak entity  Weak entity type normally has partial key(descriminator) Partial key are set of attributes that can uniquely identify weak entities that are related to some owner entity
  • 33. Partial key attribute is denoted with underlined or dotted line.  Weak entities can sometimes be represented as complex attributes (composite and multivalued attributes)  Choice of the representation is done by DB designer.  If there are many attributes then we can better represent them as weak entity.  Also if it participates independently in any other relationship type other than it’s own identifying relationship then it should not be modeled as complex attributes.
  • 34. DESIGN CHOICE FOR ER CONCEPTUAL MODEL  It is very difficult to determine if a particular concept must be represented as entity type or attribute or relationship type  Some important concepts to be remembered are: A) Concept may be first modeled as an attribute and then refined in to a relationship because it is determined that an attribute is reference to another attribute . A pair of such attribute that are inverses of one another are refined to as binary relationship
  • 35. EMPLOYEE Department DEPARTMENT Employees Can be refined to binary relation N WORKS- 1 EMPLOYEE DEPARTMENT FOR
  • 36. B) An attribute that exists in several entity types may be elevated or promoted to an independent entity.  Ex: Suppose several entity types in an UNIVERSITY DATABASE such as student , instructor & course each has an attribute named department . Then we can better keep an entity named department with a single attribute department name and relate it to 3 entity types student , instructor & course via appropriate relationship.
  • 37. INSTRUCTOR Dept-name STUDENT Dept-name COURSE Dept-name Can be refined as DEPARTMENT WORKS REGISTE BELONG RED S-TO -FOR INSTRUCTOR STUDENT COURSE
  • 38. Inverse refinement to previous case:  If an entity type department exists in initial design with a single attribute dept-name and is related to only one other entity type student , in this case department may be reduced as an attribute of the student
  • 39. ALTERNATE NOTATIONS  We can also associate pair of integer (min,max) with each participation of entity type in a relationship type. These are termed structural constraints 0<=min<=max and max>=1 Min>0 implies total particiaption Min=0 implies partial participation
  • 40. CHOOSING BETWEEN BINARY AND TERNARY RELATIONSHIP Consider the ER diagram Qty SUPPLIER SUPPLY PROJECT Sname Pname PART Partno
  • 41. We can refine it to three binary relations Sname Pname Qty SUPPLI SUPPLIER ES PROJECT CAN USES SUPPLY PART Partno
  • 42. CAN_SUPPLY relationship between SUPPLIER and PART include instances (s,p) whenever SUPPLIER s can supply PART p(to any project).  USES relationship between PROJECT and PART include instances (j,p) whenever PROJECT j uses PART p.  SUPPLIES relationship between SUPPLIER and PROJECT include instances (s,j) whenever SUPPLIER s SUPPLIES some PART to PROJECT j.  The existence of relationship instances (s,p) , (j,p) , (s,j) does not necessarily imply that the instance (s,j,p) exists in ternary relationship supply because meaning is different.
  • 43. Solution is to include the ternary relationship plus one or more of the binary relationship if they represent different meaning and all are needed by the application.  So ternary relationship supply can be represented as the weak entity type with three identifying relationship
  • 44. Qty Sname Pname N N 1 1 SUPPLIER SS SUPPLY SPJ PROJECT N SP 1 PART Partno
  • 45. DEALING WITH TERNARY RELATIONSHIPS  Consider the below relationship. ]It is no longer clear which sales assistant sold a customer a particular product.  So try replacing the ternary relations hip with an entity type and a set of binary relationships. SALES- SELLS PRODUCT ASSISTANT SELLS SELLS CUSTOMER
  • 46.  The relationship sells can become the entity type sale .  So a sales assistant can be linked to a specific customer and both of them to the sale of a particular product. SALES- MA INVO SALE PRODUCT ASSISSTANT KES LVES REQ UEST CUSTOMER
  • 47. REMOVING REDUNDANT RELATIONSHIP  Entities can be related indirectly by two relationships. A relationship is redundant if it can be completely represented by alternate transitive relationships
  • 49. CONFIRMING OPTIONALITY AND CARDINALITY OF RELATIONSHIP  Use an `entity set diagram' to show entity examples graphically  Consider the example of `course is_studied_by student'.
  • 50.  Use the diagram to show all possible relationship scenarios.  Go back to the requirements specification and check to see if they are allowed.  If not, then put a cross through the forbidden relationships  This allows you to show the cardinality and optionality of the relationship
  • 52. DERIVING THE RELATIONSHIP PARAMETERS  To check we have the correct parameters (sometimes also known as the degree) of a relationship, ask two questions: 1. One course is studied by how many students? Answer = `zero or more'.  This gives us the degree at the `student' end.  The answer `zero or more' needs to be split into two parts.  The `more' part means that the cardinality is `many'.  The `zero' part means that the relationship is `optional'.  If the answer was `one or more', then the relationship would be `mandatory'.
  • 53. 2.One student studies how many courses? Answer = `One'  This gives us the degree at the `course' end of the relationship.  The answer `one' means that the cardinality of this relationship is 1, and is `mandatory'  If the answer had been `zero or one', then the cardinality of the relationship would have been 1, and be `optional'.
  • 54. CONSTRUCTING AN ER MODEL  Before beginning to draw the ER model, read the requirements specification carefully.  Document any assumptions you need to make. 1.Identify entities • list all potential entity types. These are the object of interest in the system. It is better to put too many entities in at this stage and them discard them later if necessary.
  • 55. 2.Remove duplicate entities • Ensure that they really separate entity types or just two names for the same thing • Also do not include the system as an entity type • e.g. if modelling a library, the entity types might be books, borrowers, etc. • The library is the system, thus should not be an entity type.
  • 56. 3.List the attributes of each entity • Ensure that the entity types are really needed. • Are any of them just attributes of another entity type? • If so keep them as attributes a nd cross them off the entity list. • Do not have attributes of one entity as attributes of another entity!
  • 57. 4.Mark the primary keys • Which attributes uniquely identify instances of that entity type? • This may not be possible for some weak entities. 5.Define the relationships • Examine each entity type to see its relationship to the others.
  • 58. 6.Describe the cardinality and optionality of the relationships • Examine the constraints betwee n participating entities. 7.Remove redundant relationships • Examine the ER model for redundant relationships.  ER modelling is an iterative process, so draw several versions, refining each one until you are happy with it. Note that there is no one right answer to the problem, but some solutions are better than others!
  • 59. EXAMPLE  “A Country Bus Company owns a number of busses. Each bus is allocated to a particular route, although some routes may have several busses. Each route passes through a number of towns. One or more drivers are allocated to each stage of a route, which corresponds to a journey through some or all of the towns on a route. Some of the towns have a garage where busses are kept and each of the busses are identified by the registration number and can carry different numbers of passengers, since the vehicles vary in size and can be single or double-decked. Each route is identified by a route number and information is available on the average number of passengers carried per day for each route. Drivers have an employee number, name , address, and sometimes a telephone number.”
  • 60. ENTITIES  Bus - Company owns busses and will hold information about them.  Route - Buses travel on routes and will need described.  Town - Buses pass through towns and need to know about them  Driver - Company employs drivers, personnel will hold their data.  Stage - Routes are made up of stages  Garage - Garage houses buses, and need to know where they are.
  • 61. RELATIONSHIPS  A bus is allocated to a route and a route may have several buses. Bus-route (m:1) - is serviced by  A route comprises of one or more stages. route-stage (1:m) comprises  One or more drivers are allocated to each stage. driver-stage (m:1) is allocated  A stage passes through some or all of the towns on a route. stage-town (m:n) passes-through
  • 62.  A route passes through some or all of the towns route-town (m:n) passes-through  Some of the towns have a garage garage-town (1:1) is situated  A garage keeps buses and each bus has one `home' garage garage-bus (m:1) is garaged
  • 64. ATTRIBUTES  Bus (reg- no,make,size,deck,no-pass)  Route (route-no,avg-pass)  Driver (emp - no,name,address,tel-no)  Town (name)  Stage (stage - no)  Garage (name,address)
  • 69. Symbols for entity type attribute and relationship Displaying attributes
  • 70. Various (min, max) notations
  • 72. ENHANCED ER DIAGRAM The EER diagram includes the concepts of Subclass and super class Specialization and Generalization Categorization Attribute and relationship inheritance.
  • 73. SUBCLASS SUPERCLASS AND INHERITANCE  In many cases entity types has numerous sub grouping of it’s entities that are meaningful and need to be represented explicitly because of their significance to database application.
  • 74.  Here each of the sub groupings is called subclass of the EMPLOYEE entity type.  EMPLOYEE entity type is called super class for each of these subclasses  The relationship between super class and any one of it’s subclass is called the super class/subclass or simply class/subclass relationship. Member entity of the subclass represents the same real world entity as some member of superclass and the Subclass entity has specific distinct role
  • 75.  An entity that is a member of subclass is also a member of super class and can optionally be member of any number of subclasses.  Important concept associated with subclass is type inheritance.  Subclass entity possess it’s own attributes as well inherits all the attributes possessed by it’s superclass.  The entity also inherits the relationships that superclass participtes
  • 76. SPECIALIZATION Specialisation is a process of defining set of subclasses of an entity type.  This entity type is called superclass of the specialisation.  Set of subclasses that form specialisation is defined based on some distinguishing characters of entities in the superclass.  Ex: Job type , method-of-pay
  • 77. The subclass that defines a specialisation are attached by line to circle to represent the specialisation,which is connected to superclass.  The subset symbol on each line connecting a subclass to the circle indicates direction of the superclass/subclass relationship.  Attributes that apply only to entities of particular entity types – specific/local attributes.  Subclass also participates in specific relationships.
  • 78. WHY INCLUDE SPECIALISATION CONCEPT? 1. Certain attributes may apply only to specific entity. • A subclass is defined to group the entities to which the attributes apply. 2. Some relationship types may be participated in by only specific entities.
  • 79. IN SPECIALISATION: 1.Define a set of subclass of entity type 2. Establish additional specific attributes with each subclass 3.Establish additional specific relationship types between each subclass and other entity types or other subclass
  • 80. GENERALISATION The reverse process of abstraction in which we suppress the differences among several entity types, identify their common features and generalize them in to single super class of which original entity types are special subclasses. Vehicle- Price Vehicle-id Price id No-of- pass CAR Licens TRUCK License e-no -no Max- No-of- speed axles Tonnage
  • 81. Licens e-no Vehicle- Price id VEHICLE d No-of- pass CAR TRUCK Max- No-of-axles Tonnage speed
  • 82. CONSTRAINTS ON SPECIALIZATION AND GENERALIZATION Predicate-defined Attribute defined- User-defined subclasses specialization subclass • Determine • Membership • no condition exactly those condition for determines entities that subclasses on membership will become same attribute • Membership in members of of the super a subclass is each subclass class determined by by a condition. • Attribute is the database called the users by defining applying an attribute of the operation to specialization add an entity to • Example: the subclass JobType
  • 83. Hence, we have four types of specialization/generalization based on the paticipation of superclass entities in sub classes:  Disjoint, total  Disjoint, partial  Overlapping, total  Overlapping, partial Generalization usually is total because the superclass is derived from the subclasses.
  • 84. Example of disjoint partial Specialization
  • 85. SPECIALIZATION / GENERALIZATION HIERARCHIES, LATTICES  A subclass may itself have further subclasses specified on it  Forms a hierarchy or a lattice. Hierarchy has a constraint that every subclass has only one superclass (called single inheritance) In a lattice, a subclass can be subclass of more than one superclass (called multiple inheritance)
  • 86. In a lattice or hierarchy, a subclass inherits attributes not only of its direct superclass, but also of all its predecessor superclasses  In specialization, start with an entity type and then define subclasses of the entity type by successive specialization (top down conceptual refinement process)  In generalization, start with many entity types and generalize those that have common properties (bottom up conceptual synthesis process).  A subclass with more than one superclass is called a shared subclass
  • 87. SPECIALIZATION / GENERALIZATION LATTICE EXAMPLE (UNIVERSITY)
  • 88. CATEGORIES (UNION TYPES) Model a single super class /subclass relationship with more than one super class  Super classes represent different entity types .  Example: Database for vehicle registration, vehicle owner can be a person, a bank (holding a lien on a vehicle) or a company. ◦ Category (subclass) OWNER is a subset of the union of the three super classes COMPANY, BANK, and PERSON ◦ A category member must exist in at least one of its super classes This is difference from shared subclass, which is subset of the intersection of its super classes (shared subclass member must exist in all of its super classes).
  • 90. CASE IN POINT: E-R MODEL FOR ONLINE SALES FOR BIGHIT VIDEO “ BigHit Video Inc. wants to create an information system for online sales of movies in both DVD and videotape format. People will be allowed to register as customers of the online site and to update their stored information. Informa-tion must be maintained about customers ’ shipping addresses, e-mail ad- dresses and credit cards. In a single sale, customers will be allowed to purchase any quantity of videos. The items in a single sale will be shipped to a single address and will have a single credit card charge A customer will be provided with a virtual shopping cart to store items to be purchased. As each item is selected, it is added to the shopping cart. When the customer finishes shopping, he will be directed to a checkout area where he can purchase all of the items in the shopping cart. At this time, payment and shipping information is entered. Once the sale is complete, the shopping cart will be deleted and the customer will be sent a receipt by e-mail.”
  • 91. IDENTIFY ENTITY AND ATTRIBUTES ENTITY ATTRIBUTE CONSTRAINTS 1.Customer accountId Key lastName Not null firstName shippingAddresses Multivalued composite with components name, street, city, state, zipcode emailAddress creditCards Multivalued composite with components type, accountNumber , expiration password Not null at least 6 characters
  • 92. ENTITY ATTRIBUTE CONSTRAINTS 2. Movie Movieid Key Title Genre Media Either “dvd” or “videotape” determines subclass 3. DVD Languages Subclass of Movie Videoformat Captioning 4. Videotape Format Subclass of Movie Soundtrack
  • 93. ENTITY ATTRIBUTE CONSTRAINTS 5. Sale SaleId Key Totalcost DateSold CreditCard Composite with components type, accountNumber , and expiration 6. ShoppingCart CartId key DateCreated
  • 94. Relationsh Entity Entity Cardinali Attributes RELATIONSHIPS ip Type Class Class ty Ratio Purchases Customer Sale one-to- many Includes Sale Movie many-to- quantity many Selects Customer Shopping one-to- Cart many Includes Movie Shopping many-to- quantity Cart many