DATABASE DESIGN Using the Relational ModelLecture Notes Prepared byProf. Melody Angelique C. RiveraFaculty, College of Computer Studies, Silliman University

Based on:Modern Database Systems by Hoffer, Prescott and McFadden (Chap 3)Database Systems by Connolly & Begg (Chap 3)CMSC F Course Material (UPOU)

*Three-step Process in Designing DatabasesFunctional Analysisidentifies data and the business rules which are to be applied to the processThe job of a database analyst is to:Identify and understand the rules that govern dataRepresent the rules so that they can be understood by IS developers and usersImplement the rules in database technology

*Three-step Process in Designing DatabasesData AnalysisThree (3) PhasesConceptual DesignLogical DesignPhysical DesignPhysical Implementationthe outcome of the physical design phase is finally implemented to produce the physical database

*The Functional AnalysisCollection of the data requirements and their analysisDatabase designers interview prospective database users to understand and document their data requirementsResult: concisely written set of user requirements

*The Functional Analysis (continued)User requirements come in the form of business rules and functional requirementscontains user-defined operations that will be applied to the databaseincludes operations like retrieval and updates

*The Functional Analysis (continued)Business Rule:A statement that defines or constrains some aspect of the businessCharacteristicsDeclarativePreciseAtomicConsistentExpressibleDistinctBusiness-oriented

*The Functional Analysis (continued)Example of a Business Rule:A student may enroll in a course in his/her degree only if the prerequisites for the course has been successfully completed.

*The Functional Analysis (continued)Data Names and DefinitionsData names should:Relate to business, not technical (hardware of software) characteristicsExample: CustomerBe meaningful (or self-documenting)Be unique (or distinct from every other data objectBad Example: DateGood Example: Birthdate

*The Functional Analysis (continued)Data names (continued)Be readableBe composed of words taken from an approved listRepeatableDifferent people at different times should develop exactly or almost the same nameThere must be a standard or pattern for namesExample: StudentBirthDate

*The Functional Analysis (continued)Data DefinitionsConsidered a type of business ruleAn explanation of a term or a factTerma word or phrase that has a specific meaning for the businessExample: course, reservationFactAn association between two or more termsExample of a fact that is a definition (the defined term is underlined): A course is a module of instruction in a particular subject area

Data Analysis:Phase 1Conceptual Database Design

*Conceptual Database DesignThe goal is to create a conceptual data model, which is a brief description of the data requirementsShows detailed descriptions of data types, relationships, and data constraintsExpressed using the concepts provided by the data model

*Entity-Relationship Model(ER Model)a popular conceptual data modelthere are several variations but there is one feature that is common to all -- all data may be represented using any one of the following major constructs:ENTITYATTRIBUTERELATIONSHIP

*Entity-Relationship Model(ER Model) (continued)ENTITYan abstract or concrete thing in the real world which is of interest to the organizationex: EMPLOYEEATTRIBUTEa named property or characteristic that describes an entity or a relationshipex: name, address, age, date_hired

*Entity-Relationship Model(ER Model) (continued)RELATIONSHIPan association between two entitiesex: works onEMPLOYEE works on PROJECTEMPLOYEE and PROJECT are entities

Conceptual Database DesignThe Entity-Relationship Diagram (ERD)

*The ERD Symbolsa graphical representation of entities and their relationshipsBasic symbols:entity

attribute

relationship

*ERD ExampleMEMBERborrowsBOOKMemberNoMemLast NameDateBorrowedMemAddressBookNoBookTitleBookAuthorattributesrelationshipentitiesMemFirstName

*The Entity

*EntityEntity Type or SetA collection of entities that share common properties or characteristicsThe name is always singular and written in uppercase or capital lettersEntity InstanceA single occurrence of an entity typeIn simple terms, the record itself

*The Attribute

*AttributeTypes of AttributesSimpleCompositeSingle-ValuedMultivaluedStoredDerivedRequiredOptional

*Simple AttributeAn attribute that cannot be broken down into smaller componentsExample: STUDENT entityStudentIDStudentLastNameStudentDegreeSTUDENTStudentIDStudentLastNameStudentDegree

*Composite AttributeAn attribute that can be broken down into component partsComponent attributes may appear above or below the composite attribute on an E-R diagramThe decision whether to subdivide an attribute into its component parts depends on whether user will need to refer to those individual components

*Composite Attribute ExampleAddressStreet_AddressCityZipCodeProvinceSTUDENTStudentIDYearSemesterNumber

*Required AttributeAn attribute that must have a value for each entity instanceExample: STUDENT entityStudentIDStudentLastNameStudentFirstNameStudentDegree

*Optional AttributeAn attribute that may not have a value for every entity instanceExample: STUDENT entityStudentMajorStudentHomePhone

*Required vs Optional Attributes

Entity Type: STUDENTAttribute NameData TypeEntity InstanceEntity InstanceStudentIDChar (12)2007-1-012542007-2-00349StudentLastNameChar (20)PinedaGonzalezStudentFirstNameChar (30)KatherineBernardoStudentDegreeChar (10)BSMTBBAStudentMajorChar (10)ManagementStudentHomePhoneChar (11)032-4125621

*Single-Valued AttributeAn attribute that has only one valueExample: STUDENT entityStudentGenderPossible values: Female or MaleStudentCivilStatusPossible values: Single, Married, Separated, Widowed

*Multivalued AttributeAn attribute that may take on more than one value for a given entity instanceExample: EMPLOYEE entityEmpSkillAn employee may have more than one skill (C programmer, Java Programmer, Web Designer)Notation: Double oval or ellipse

*Multivalued vs Single-valued Attribute ExampleEMPLOYEEEmpIDEmpNameEmpDateEmployedEmpSkillMultivalued AttributeSingle-valued AttributesEmpGender

*Transforming (Exploding) Multivalued AttributesDORMITORYDorm_NoDorm_NameManagerLocationRoomsMultivalued AttributeOriginal Diagram

*Transforming (Exploding) Multivalued Attributes (continued)Transformation of the Multivalued AttributeHow to read: A dormitory has one or more roomsDorm_NoRoom_NameCapacityRoom_NoStart_RentEnd_RentDorm_NameLocationManagerDORMITORY ROOM has

*Another Multivalued Attribute ExampleCOURSECourse_IDCourse_TitlePrerequisiteOriginal Diagram

*Entities with Multivalued Attributes (continued)Course_IDCourse_TitleIs_A_Prerequisite_forTransformation of the Multivalued AttributeCOURSE

*Stored AttributeAn attribute that gets its value directly from an input device (e.g. keyboard)Example: STUDENT entityStudentIDStudentLastNameStudentFirstNameStudentDegree

*Derived AttributeAn attribute whose values can be calculated from related attribute values (and possibly data not in the database)Example: EMPLOYEE entityEmpYearsEmployedMay be calculated as:PresentDate EmpDateEmployedNotation: Oval or ellipse with a dashed line

*Derived Attribute ExampleEMPLOYEEEmpIDEmpNameEmpDateEmployedEmpSkillEmpYearsEmployedDerived AttributeEmpPhoneNo

*Key AttributeIdentifierAn attribute or combination of attributes that uniquely identifies individual instances of an entity typeMore commonly known as Primary KeyIt is unique (no two instances of an entity type may have the same value)Underlined (solid) in the ERD

*Identifier ExampleEMPLOYEEEmpIDEmpNameEmpDateEmployedEmpSkillEmpYearsEmployedIdentifier or Primary key (Simple key attribute)A simple key attribute is an identifier that consists of a simple or single attribute.

*Identifier ExampleStudentIDStudentLastNameStudentCourseSTUDENTYearSemesterStudentNoComposite key attributeA composite key attribute is an identifier that consists of a composite attribute.

*The Relationship

*Relationship NamesA verbPresent tenseExamples:Manages (or Is_Managed)Receives (or Is_Received)Enrolls (or Is_Enrolled)Stays / Occupies (or Is_Occupied)Marries (or Is_Married)

*Relationships between entitiesDegree of a Relationshipthe number of entities that participate in a relationship unary, binary, ternary or n-aryUNARY RELATIONSHIPEMPLOYEEsupervisesAn employee supervises another employee. For example, one of the employees isa manager/supervisor and the other one is a clerk.- Only one entity is involved in the relationship

*Relationships between entities (continued)EMPLOYEEDEPARTMENTmanagesBINARY RELATIONSHIPAn employee manages a department.- Only two entities are involved in the relationship

*Relationships between entities (continued)VENDORWAREHOUSEPARTshipsTERNARY RELATIONSHIPA vendor ships a part to the warehouse. or A part is being shipped by a vendor to the warehouse- Three entities are involved in the relationship

*Relationships between entities (continued)VENDORWAREHOUSEPARTshipsN-ARYRELATIONSHIPTRANSPORTATIONA vendor ships a part to thewarehouse through a transportation.

*Relationships between entities (continued)CARregistersPERSONMULTIPLERELATIONSHIPSA person owns a car. and A person registers a car.owns

*Relationships with attributes MEMBER Attributes that do not belong to any entity should be placed on the relationship VCD borrowsM_noM_nameV_titleV_codeV_availDate_borDate_due

*Cardinalities in Relationships

*The Cardinality RatioSpecifies the number of instances of entity B that can (or must) be associated with each instance of entity AOne-to-one (1:1)when only one entity can have that relationship with another entityExample 1: in a monogamous society, one husband can only have one wife (legally)Example 2: by default, a student takes up only one degree (at a time) in a college

*Cardinalities in Relationships (continued)Many-to-many (M:N)we can have any number of relationships with other entitiesex: in joint accountsOne-to-many (1:M)one entity can have more than one of that type of relationex: if a customer can own many accounts, but each account can only be owned by one customer (no joint accounts) then the relationship is one-to-manyfrom the perspective of the back account, the relationship is many-to-one

*McFaddens Notation for Minimum and Maximum CardinalityMandatory One

Mandatory One or Many

Optional Zero or One

Optional Zero, One or ManyMinimum Cardinalitythe smallest number of instances allowed to participate in a relationshipMaximum Cardinality- the greatest number of instances allowed to participate in a relationship

*Example of a Mandatory One-to-One RelationshipPERSON CAR ownsMandatory OneAn instance of a person owns one car. (read from left to right )An instance of a car is owned by one person (read from right to left )1:1

*Example of a Mandatory One-to-Many RelationshipMEMBER VCD borrowsMandatory One or ManyAn instance of a member borrows one or more VCDs. An instance of a VCD is borrowed by one member. 1:M

*Example of a Mandatory Many-to-Many RelationshipSTUDENTCOURSEtakesM:NAn instance of a student takes one or more courses. An instance of a course is taken by one or more students. Mandatory One or Many

*Example of an Optional Zero, One or Many RelationshipEMPLOYEEPROJECTIsassigned toThe corresponding rule is that:An employee is assigned to a number of projects, possibly none. An instance of an employee is assigned to zero, one or many projects. Given a project, there should be at least one employee (possibly many employees) assigned to it. Optional Zero, One or Many

*Existence Dependency and Weak Entity

*Existence DependencyOccurs when an instance of one entity cannot exist without the existence of an instance of some other (related) entityPATIENTHISTORYhas

*PATIENTHISTORYhasPatientNoPatientNamePatientNoHistoryNoConsultationDateDiagnosis

*Weak and Strong EntitiesSince HISTORY cannot exist without the PATIENT entity, it is considered a weak entityNOTATION: double rectangleThe PATIENT entity is called a strong entity (others call it the mother entity)

*Another way of explaining this:The entity HISTORY has an existence dependency on the entity PATIENTThat is, an instance of HISTORY cannot exist unless the related PATIENT entity exists

Two Approaches in Conceptual Design

*Top Down vs. Bottom-Uptop downidentify the entityidentify the attributesidentify the relationshipbottom-upentity, attribute, and relationship names are already givenjust attach the attribute to its entity and connect to the relationship

*Top-down Examplein a video shopentities identified: media, memberattributes to be attached? MEDIA MediaNoMediaTitleMain_ActorAvailability MEMBER MemNoMemNameMemAddr

*Bottom-up Examplelist given:s_namestudentcourseteachercoderoomaddresstimelocationenrollsyr_leveltitlethe ERD:STUDENTCOURSEhass_nameaddressyr_levelcodeteachertimelocationtitleroom