1: Database SystemsPart II: Data Modeling

*IntroductionIn designing databases, we begin by examining the entities that are of importance to an organization. A conceptual data model is created to capture the overall structure of the entities and the relationships among them

*Conceptual Data ModelA graphical model showing the followingCharacteristics of the entities Relationships among the entitiesIndependent of :How the database will be physically storedThe data model used to implement the databaseThe type of DBMS to be used

*Entity-Relationship Diagram (ERD)Most commonly used conceptual modelConsists of:EntitiesRelationships among entitiesAttributes of both the entities and their relationships

*EntityAn entity is a person, place, thing, or event which an organization wishes to maintain data about Examples:StudentSubjectInstructor

An entity is represented by a rectangle

STUDENTSUBJECT

*Entity Type vs. Entity InstanceEntity type A collection of all occurrences of a given type of entityAlso known as entity class Entity instance A single occurrence of an entity typeAn entity type can have many instances

*Attributes An attribute is a characteristic of an entitySample attributes of the STUDENT entityNameID NumberAddressBirthday

An attribute is represented by an ellipse

STUDENTNameID_NumBirthdayAddress

*Value of an AttributeThe value of the type of characteristic that an attribute representsExample:Attribute: NameValues:Fox MulderDana ScullyThe ERD contains only the attribute type and not its values

*Comparison of Attribute TypesMultivalued vs. single-valuedComposite vs. simple (or atomic)Derived vs. stored

*Multivalued AttributesAttributes having more than one value for each entity instanceExample:Hobby - a student may have more than one hobbiesA multivalued attribute is represented by a double ellipseHobbySTUDENT

*Composite AttributesAn attribute broken into component parts

*Example: An Attribute Both Multivalued and Composite

*Derived AttributeAn attributes whose values can be calculated from related attribute values

*Identification of Entity InstancesThe relational model uses primary keys to link related entities togetherPrimary key - an attribute or a combination of attributes that uniquely identifies an instance of an entityRepresented by underlining the attribute(s) involved

ID_Num

*Characteristics of a Primary KeyUnique - no two entity instances can have the same value for the primary key attributeNot nullMust not change over timeAvoid use of intelligent keysSubstitute new, simple keys for long, composite keys

*RelationshipA relationship is a natural association between the instances of one or more entitiesExample:enrolls - a student enrolls in a subjectRelationships may also have attributes

A relationship is represented by a diamond-shaped symbolenrollsSTUDENTSUBJECT

*Degree of a RelationshipThe number of entity types attached to a relationshipThree (3) most common typesUnary relationshipBinary relationshipTernary relationship

*Unary RelationshipA recursive relationship within a single entityExists within an entity to link related instances of that entity togetheris marriedtoPERSON

*Binary RelationshipAn association between two entity typesMost common relationship

enrollsSTUDENTSUBJECT

*Ternary RelationshipAn association among three related entity typesshipsVENDORWAREHOUSEPART

*Optional and Mandatory RelationshipsOptional RelationshipAn instance of one entity may not be associated with an instance of the related entityMandatory RelationshipEvery instance in one entity type must be associated with at least one instance in the related entity

*Types of RelationshipThree (3) possible types of relationship can exist between the occurrences of related entity types:One-to-one relationshipOne-to-many relationshipMany-to-many relationship

*CardinalityThe number of instances that is associated between a pair of entity typesThe cardinality of the association from A to B is the maximum number of occurrences of B that can be associated with AA pair of associations can exist between any two entities:Ex. from A to B and from B to A

*Examples of Cardinality

*Example Instance Association in a One-to-One Unary Relationship

*Example Instance Association in a Many-to-Many Relationship

*Optional and Mandatory CardinalityOptional cardinalityIf minimum cardinality is 0Mandatory cardinalityIf minimum cardinality is 1

Mandatory 1cardinality

*Optional and Mandatory CardinalityMandatory 1-Manycardinality

Optional 0 or 1cardinality

Optional 0-Manycardinality

*Maximum Cardinality ConstraintsHere, maximum cardinality constraint is 4

*Multiple RelationshipsEntities can be related to one another in more than one way

*Strong vs. Weak Entities, andIdentifying RelationshipsStrong entities Exist independently of other types of entitiesHas its own unique identifierRepresented with single-line rectangleWeak entityDependent on a strong entitycannot exist on its own; has no business meaning in the ERD without the entity (called identifying owner) it depends onDoes not have a unique identifier, only partial identifierRepresented with double-line rectangleIdentifying relationshipLinks strong entities to weak entitiesRepresented with double line diamond

*Example of Strong and Weak EntitiesStrong entityWeak entityIdentifying relationship

*Associative Entities (Gerund)Also known as composite entityA many-to-many relationship modeled as an entity typeIt is a relationship (but would want to maintain data about)It is an entity in disguiseHas independent meaning to end-users and preferably identifiable by a single attribute

A gerund is represented by a diamond within a rectangleSHIPMENT

*Associative Entity ExamplecompletesCOURSEEMPEmp #NameTitleCourse IDDate CompletedCERTIFICATECOURSEEMPEmp #NameTitleCourse IDDate CompletedCertificate #

*Associative Entity Example

*Associative Entity Example

*Supertypes and SubtypesSubtype: A subgroup an entity type which has attributes that are distinct from those in other subgroupsSupertype: An generic entity type that has a relationship with one or more subtypesInheritanceSubtype entities inherit values of all attributes of the supertypeAn instance of a subtype is also an instance of the supertype

*Basic Notation

*Relationships and SubtypesRelationships at the supertype level indicate that all subtypes will participate in the relationshipThe instances of a subtype may participate in a relationship unique to that subtype. In this situation, the relationship is shown at the subtype level

*Example: Supertypes and Subtypes

*Generalization & SpecializationGeneralizationThe process of defining a more general entity type from a set of more specialized entity type (bottom-up)SpecializationThe process of defining one or more subtypes of the supertype and forming supertype/subtype relationships (top-down)

*Completeness ConstraintsWhether an instance of a supertype must also be a member of at least one subtypeTotal Specialization Rule: Yes (double line)Partial Specialization Rule: No (single line)

*Total Specialization Rule

*Partial Specialization Rule

*Disjointness ConstraintsWhether an instance of a supertype may simultaneously be a member of two (or more) subtypesDisjoint Rule: An instance of the supertype can be only ONE of the subtypesOverlap Rule: An instance of the supertype could be more than one of the subtypes

*Disjointness Constraints

*Overlap Constraints

*Constraints in Supertype/Subtype DiscriminatorsSubtype Discriminator: An attribute of the supertype whose values determine the target subtype(s)Two types:Disjoint a simple attribute with alternative values to indicate the possible subtypesOverlapping a composite attribute whose subparts pertain to different subtypes; each subpart contains a boolean value to indicate whether the instance belongs to associated subtype

*Discriminator: Disjoint Rule

*Discriminator: Overlap Rule

*Supertype/Subtype Hierarchy

*Entity Clusters

*Inappropriate DiagramsERDs must not:contain a user of the system contain an output of the database system (e.g. a report)be confused with a user viewSystem userSystem output

********A multivalued attribute can be modeled as such during the first pass of conceptual design. However, this is normalized during subsequent steps of conceptual design. The multivalued attribute is replaced by another entity or relationship.*A specific entity instance can be directly accessed only if it has a primary key whose value the user can specify to identify the desired occurrence.************