BIS3635 - Database Systems School of Management, Business Information Systems, Assumption University A.Thanop Somprasong

BIS3635 - Database Systems

School of Management, Business Information Systems,Assumption University

A.Thanop SomprasongChapter # 4Entity Relationship (ER) Modeling

In this chapter, you will learn:The main characteristics of entity relationship componentsHow relationships between entities are defined, refined, and incorporated into the database design processHow ERD components affect database design and implementationThat real-world database design often requires the reconciliation of conflicting goalsObjectives

Basic Vocabulary forRelational Database Model

Relational DatabaseModelE-R ModelProgrammerGeneral UserRelationEntityFileTableAttributeAttributeFieldColumnTupleEntity MemberRecordRow

ER model forms the basis of an ER diagramERD represents conceptual database as viewed by end userERDs depict databases main components:EntitiesAttributesRelationshipsEntity Relationship (ER) Modeling

Refers to entity set and not to single entity occurrenceCorresponds to table and not to row in relational environmentIn Chen and Crows Foot models, entity represented by rectangle with entitys nameEntity name, a noun, written in capital lettersEntities

Characteristics of entitiesChen notation: attributes represented by ovals connected to entity rectangle with a lineEach oval contains the name of attribute it representsCrows Foot notation: attributes written in attribute box below entity rectangleAttributes

Attributes (2)

Required attribute: must have a valueOptional attribute: may be left emptyDomain: set of possible values for an attributeAttributes may share a domainIdentifiers: one or more attributes that uniquely identify each entity instanceComposite identifier: primary key composed of more than one attributeAttributes (3)

Attributes (4)

Composite attribute can be subdividedSimple attribute cannot be subdividedSingle-value attribute can have only a single valueMultivalued attributes can have many valuesAttributes (5)

Attributes (6)

M:N relationships and multivalued attributes should not be implementedCreate several new attributes for each of the original multivalued attributes componentsCreate new entity composed of original multivalued attributes componentsDerived attribute: value may be calculated from other attributesNeed not be physically stored within databaseAttributes (7)

Attributes (8)

Association between entitiesParticipants are entities that participate in a relationshipRelationships between entities always operate in both directionsRelationship can be classified as 1:MRelationship classification is difficult to establish if only one side of the relationship is knownRelationships

Connectivity Describes the relationship classificationCardinality Expresses minimum and maximum number of entity occurrences associated with one occurrence of related entityEstablished by very concise statements known as business rulesConnectivity and Cardinality

Connectivity and Cardinality (2)

Existence dependenceEntity exists in database only when it is associated with another related entity occurrenceExistence independenceEntity can exist apart from one or more related entitiesSometimes such an entity is referred to as a strong or regular entityExistence Dependence

Weak (non-identifying) relationshipsExists if PK of related entity does not contain PK component of parent entityStrong (identifying) relationshipsExists when PK of related entity contains PK component of parent entityRelationship Strength

Relationship Strength (2)

Relationship Strength (3)

Weak entity meets two conditionsExistence-dependentPrimary key partially or totally derived from parent entity in relationshipDatabase designer determines whether an entity is weak based on business rulesWeak Entities

Weak Entities (2)

Weak Entities (3)

Optional participationOne entity occurrence does not require corresponding entity occurrence in particular relationshipMandatory participationOne entity occurrence requires corresponding entity occurrence in particular relationshipRelationship Participation

Relationship Participation (2)

Relationship Participation (3)

Indicates number of entities or participants associated with a relationship

Unary relationshipAssociation is maintained within single entity Binary relationship Two entities are associatedTernary relationship Three entities are associatedRelationship Degree

Relationship Degree (2)

Relationship Degree (3)

Relationship can exist between occurrences of the same entity setNaturally found within unary relationshipRecursive Relationships

Recursive Relationships (2)

Recursive Relationships (3)

Also known as bridge entitiesUsed to implement M:N relationshipsComposed of primary keys of each of the entities to be connectedMay also contain additional attributes that play no role in connective processAssociative (Composite) Entities

Associative (Composite) Entities (2)

Associative (Composite) Entities (3)

Database design is an iterative processCreate detailed narrative of organizations description of operationsIdentify business rules based on description of operationsIdentify main entities and relationships from business rulesDevelop initial ERDIdentify attributes and primary keys that adequately describe entitiesRevise and review ERDDeveloping an ER Diagram

Developing an ER Diagram (2)

Database designers must make design compromisesConflicting goals: design standards, processing speed, information requirementsImportant to meet logical requirements and design conventionsDesign of little value unless it delivers all specified query and reporting requirementsSome design and implementation problems do not yield clean solutionsDatabase Design Challenges:Conflicting Goals

Database Design Challenges:Conflicting Goals (2)

Two questionsCompare and contrast between E-R Diagram and UML Class Diagram. (Show the example between each of them) (2 Marks)Give an example of the three types of relationships (Draw in Crows Foot E-R Diagram only !) (2 examples per each) (3 Marks)BIS3635 : ASSIGNMENT # 1Submission Date: July 13, 2009 (Late submission will not be accepted)Individual AssignmentsSubmit in form of hard-copy format + hand writing with ABAC papers only !Total : 5 Marks

THE END

*

Documents

BIS3635 - Database Systems School of Management, Business Information Systems, Assumption University A.Thanop Somprasong