4 - Enhanced Entity..Relationship and UML Modeling

specialization lattice

a subclass in more that one (sub)class relationship can have more than one parent-> resulting in a lattice can be more than one level inherits all the attributes of its predecessors all the way to the root

shared subclass

a subclass with more than one superclass leads to concept pf multiple inhertence

aggregation

abstract concept for building composite objects form their component objects 3 cases related to EER model 1st- aggregate attribute values to an object to from the whole object 2nd- represent an aggregation relationship as an ordinary relationship 3rd- involves the possibility of combining objects that are related by a particular relationship instance into a higher level aggregate object

Enhanced Entity-Relationship Model (EER)

an ER model with extra concepts of (sub/super)classes, type inheritance, specialization/generalization, union/categories, & abstractions is associated with important mechanism of attribute & relationship inheritence

subtype/class of enitity type supertype/class of enitiy types

an entity type with numerous subgroupings/types of entities that are important & need to be expressed explicitly the set or collection of entities in each group is a subset of enities that belong to one enitity set each of the subgroupings is a subtype/class, and the entity is the supertype/class an entity cannot exist in the database just by being a member of a subclass, is also has to be a member of the superclass such enity can be optionally included as a member of any number of subclasses, but not every enity is necessairilly a member of some subclass subclass- class whose entities must always be a subset of the entities in another class superclass- the class that the subclass must be a part of

Specific/local attributes of the subclass

attributes that apply only to the entities of a particular subclass are attached to the rectangle representing the subclass has arrows pointing to the specialized subclasses

IS-A-PART-OF IS-A-COMPONENT-OF

call the realtionship between the primitive objects and their aggregate object IAPO the inverse is IACO

main reasons for (sub)class relationships and specialization

certain attributes may apply to some but not all entites of the superclass entity type, but may still share a majority of thier attributes with the other members of the superclass some relationship types may be participated in only by entities that are members of the subclass

class

defines a type of entity and represents a set or collection of entities of that type includes any of the EER schema constructs that correspond to collections of entities, such as entity types, (sub/super)classes, categories

Rules that apply to specialization/generalization

deleting an entity form a superclass implies that is is automatically deleted from all the subclasses to which it belongs inserting an entity in a superclass implies that the entity is mandatorily inserted into all predicate/attribute-defined subclasses for which the entity satisfies the predicate inserting an entity in a superclass of a total specialization implies that the entity is mandatorily inserted in at least one of the subclasses of the specialization

Specialization hierarchy

has the constraint that every subclass participates as a subclass in only one (sub)class relationship each subclass has only one parent-> resulting in a tree/hierarchy inherits all the attributes of its predecessors all the way to the root

attribute-defined specialization

if all subclasses in a specialization have their membership condiiton on the same attribute of the superclass the attribute is the defining attribute all the entities with the same value for the attribute belong to the same subclass displayed by placing the defining attribute name next to the arc on the specialization relationship line if a predicate, A = ci, where A is an attribute of the generalization, and ci is a constant value from the domain of A, is used to specify a membership in each subclass in the specialization

single inheritence

if no shared subclasses existed, there is a hierarchy that is formed some models and languages are limited to this, & do not allow for multiple inheritence

overlapping constraint

if the subclasses are not constrained to be disjoint, then their sets of entities may be this the same real-world entity may be a member of more than one subclass of the specialization shown by placing an o in the circle representing specialization is independent to the completeness constraint

Type inheritence

important concept associated with subclasses/types an entity should possess values for its specific attributes as well as values of its attributes as a member of the superclass inherits all the attributes & relationships of the entity as a member of the superclass; can be considered an entity type in its own right

predicate/condition-defined subclasses

in some cases can determine the exact entity that will become members of each subclass by having a condition on some attribute value the condition is the defining predicate of the subclass, and is a constraint is displayed by writing the predicate condition next to the specialization connection/relationship line if a predicate p on the attributes of the superclass is used to specify which entities in the superclass are members of the subclass; Subclass = Superclass[p], where Superclass[p] is the set of entities in the superclass that satisfy p

Leaf node

is a class that has no subclasses of its own but an entity may exist in several leaf nodes some models do not allow an entity to have multiple types, and can only be a member of one leaf

Abstraction of Association

is used to associate objects from several independent classes it is somewhat similar to the second use of aggregation represented in EER by relationship types called an IS-ASSOCIATED-WITH

design choices for specialization/generalization

many specializations/subclasses can be defined to make the conceptual model accurate; drawback is the design becomes quite cluttered; only represent the necessary subclasses if subclass has few specific attributes & no specific relaitonships, it can be merged into the superclass; specific attributes would = Null for entites that are not members of the subclass; type attribute is used if all subclasses have few specific attributes & no specific relationships, they can be merged with 1+ more type attributes that specify the subclass(es) that each entity belongs to choice of disjoint/overlapping & total/partial is driven by the rules in the miniworld, if no constraints are required, the default is overlapping and partial, since is not specific

complete/totalness constraint

may be total or partial second constraint on specialization total specialization- specifies that every entity in the superclass must be a member of at least one subclass in the specialization; shown by double line connecting the superclass to the circle partial specialization- allows an entity to not belong to any of the subclasses; shown by a single line connecting the superclass to the circle is independent to the disjointness constraint is total if ∪ from i to n Subclassi = Generalized entity, otherwise partial

Specialization

process of defining a set of subclass of an entity type/superclass set of subclasses that forms this is defined on the basis of some distinguishing characterisitc of the entities in the superclass, and attached by lines to a circle that represents the specialization that is connected to the superclass there may be several specializations of the same entity types based on different distinguishing characteristics form Z = {S1...Sn}

(sub/super)class/type relationship

relationship between the subtype/class and its corresponding supertype/class represent a member of the subclass as a distinct member of the database that is related via the key attribute to its superclass entity must alwyas have subclass ⊆ superclass

Generalization

reverse process of abstraction in which the differences among the several entity types, are suppressed, and are generalized into a single superclass the original entites then are the subclasses can be functionally viewed as the inverse of specialization has arrows pointing to the generalized superclass usually the superclass that is formed is total participation (completeness constraint)

disjointness constraint

specifies that the subclasses of the specialization must be disjoint sets an entity can be a member of atmost one of the subclasses of the specialization attribute-defined implies the disjointness constraint if it is a single valued attribute shown with the letter d in the circle representing specialization; also applies to user-defined subclasses that must be disjoint is independent to the completeness constraint is disjoint if Subclassi ∩ Subclassj = ∅ for i ≠ j, otherwise is overlapping

top-down conceptual refinement

start with the root entity type and make the specializations/subclasses successively from there; repeatedly defining more specific groupings of the root entity usually leads to a hierarchy

bottom-up conceptual refinement

starting with the ending entities and generalizing successively from there; repeadedly defining more general groupings till the required root entity is reached

specific relationship types

subclass can participate in this relationship type

specification

the language and vocabulary that are used to specify the conceptualization

conceptualization

the set of concepts and relationships that are used to represent the part of reality or knowledge that is of interest to a community of users

user-defined subclass

when there is not a condition for determining the membership in a subclass membership is determined by the database users when they apply the operation to add an entity to the subclass membership is specified individually for each entity by the user, not by any automatically evaluated condition

multiple inheritance

where the shared subclass directly inherits attributes and relationships from multiple superclasses existance of atleast one shared subclasses that leads to a lattice if an attribute or relationship originating in the same superclass is inherited more than once via different paths then it should be included only once in the shared subclass