ZEIT2301 – Database Design Entity-Relationship Diagrams ZEIT2301 Design of IS Week 01: Intro ZEIT2301 – Database Design Entity-Relationship Diagrams School of Engineering and Information Technology UNSW@ADFA Dr Kathryn Merrick Bldg 16, Rm 212 (Thursdays and Fridays only) k.merrick@adfa.edu.au Session 2, 2010

Topic 08: Database Design ZEIT2301 Design of IS Week 01: Intro Topic 08: Database Design Objectives: To review Entity Relationship Diagrams for modelling data and its relationships To review the Relational model for database management systems 2 Session 2, 2010

ZEIT2301 Design of IS Week 01: Intro Data Storage The Class Diagram identifies the classes and attributes of interest from the problem domain. We now consider how this data can best be stored in order to support the specified requirements of the system. The most popular storage format today is the relational database. Session 2, 2010 3 Session 2, 2010

ZEIT2301 Design of IS Week 01: Intro Database Design To reap the potential benefits offered by database technology, databases must be properly designed Effort spent in design is always rewarded in data quality There are different (though complementary) approaches to achieving a good design 4 Session 2, 2010

Approaches to Database Design ZEIT2301 Design of IS Week 01: Intro Approaches to Database Design Entity-Relationship (ER) data modelling A graphical technique for understanding and organizing the data independently of the eventual database implementation Normalization (next week’s lecture): An approach for evaluating the quality of a database design - most applicable to relational database designs ER modelling and normalization are the core techniques for good database design 5 Session 2, 2010

Entity-Relationship Diagrams ZEIT2301 Design of IS Week 01: Intro Entity-Relationship Diagrams ER models are based on the following concepts: Entities (or, more correctly, entity types) Relationships (between entities) Attributes (of entities and relationships) Similar to the discussion of Class Diagrams Entities are similar to Classes in OO analysis. But: Entities do not have any methods (data only) Entities have a Primary Key (PK) 6 Session 2, 2010

Entity-Relationship Diagrams ZEIT2301 Design of IS Week 01: Intro Entity-Relationship Diagrams There are various diagrammatic styles for ERDs We will use the UML style notation But note that we are talking about Entities Which store attributes (ie data) only Not Classes Which store attributes (data) and have processes (operations or methods) Session 2, 2010 7 Session 2, 2010

An Entity and its Attributes ZEIT2301 Design of IS Week 01: Intro An Entity and its Attributes student An entity is represented on entity-relationship diagram as a named rectangle with two parts An entity is conventionally named in the singular (because it is a type of thing) 8 Session 2, 2010

ZEIT2301 Design of IS Week 01: Intro Attribute Domain Domain: set of values that may be assigned to an attribute Not shown on an ER diagram; recorded in a data dictionary e.g. for attribute ‘gender’ the possible values are 'Male' and 'Female', so domain(Gender) = {'Male', 'Female'} e.g. for attribute ‘quantityHeld' the possible values range from 0 onwards, so domain(quantityHeld) = {all natural numbers} A particular value doesn’t have to be assigned limits the values for an attribute allowance for large set Example - domain for qty_held would be the same as for an attribute Chapters Used in later stages of database design, important for understanding user requirements 9 Session 2, 2010

Composite Attribute Composite Attribute: component parts ZEIT2301 Design of IS Week 01: Intro Composite Attribute student studentID name address streetAddress suburb state postcode DOB Gender Composite Attribute: component parts indented slightly. 10 Session 2, 2010

Multi-Valued Attribute ZEIT2301 Design of IS Week 01: Intro Multi-Valued Attribute student studentID name DOB phoneNo [1..3] gender Multi-valued Attribute: 1 to 3 occurrences (for a particular student) phoneNo [1..*] means 1 or more occurrences Session 2, 2010 11 Session 2, 2010

Derived Attribute Derived Attribute: ZEIT2301 Design of IS Week 01: Intro Derived Attribute student studentID name DOB /age gender Derived Attribute: use “/” in front of attribute name Session 2, 2010 12 Session 2, 2010

ZEIT2301 Design of IS Week 01: Intro Entity Uniqueness Each entity instance should be distinguishable from all other instances of the same entity type by inspection of the values of all of its attributes eg distinguish one student from another student That distinguishing attribute (or group of attributes) is called the Primary Key This is a significant difference between a Class Diagram and an Entity-Relationship Diagram A Class does not have a PK 13 Session 2, 2010

Identify Primary Key Primary Key ISBN {PK} title textbook edition ZEIT2301 Design of IS Week 01: Intro Identify Primary Key textbook ISBN {PK} title mainTitle subTitle edition author [1..*] publisher price quantityHeld /valueOfStock Primary Key 14 Session 2, 2010

Relationships between Entities ZEIT2301 Design of IS Week 01: Intro Relationships between Entities A relationship is a set of meaningful associations among entities. Three types of relationships are: Unary: one entity involved Binary: two entities involved (the most common) Ternary: three entities involved 15 Session 2, 2010

Multiplicity constraints ZEIT2301 Design of IS Week 01: Intro Multiplicity constraints Multiplicities indicate how many instances of each entity participate in the relationship Generally these are zero, one or many eg: one-to-one (1..1) one-to-many (1..*) many-to-many (*..*) zero-to-one (0..1) zero-to-many (0..*) or simply * 16 Session 2, 2010

Multiplicity Constraints ZEIT2301 Design of IS Week 01: Intro Multiplicity Constraints “A student enrols in up to 4 courses and must enrol in at least one course” “A course may have zero or many students.” student studentID {PK} course courseCode {PK} 1..4 enrols In student studentID {PK} course courseCode {PK} 0..* enrols In 17 Session 2, 2010

Unary (recursive) Relationship ZEIT2301 Design of IS Week 01: Intro Unary (recursive) Relationship 1..* course courseCode {PK} courseName creditPoints is prerequisite for 0..* A course “is a prerequisite for” another course 18 Session 2, 2010

Binary Relationship ISBN {PK} title textbook edition author [1..*] ZEIT2301 Design of IS Week 01: Intro Binary Relationship textbook ISBN {PK} title mainTitle subTitle edition author [1..*] publisher price quantityHeld /valueOfStock student studentID {PK} name DOB address gender buys 1..* 0..* 19 Session 2, 2010

Ternary Relationship “buys” ZEIT2301 Design of IS Week 01: Intro Ternary Relationship “buys” student studentID {PK} textbook ISBN {PK} buys bookshop name{PK} 20 Session 2, 2010

Attributes of a Relationship ZEIT2301 Design of IS Week 01: Intro Attributes of a Relationship student studentID {PK} textbook ISBN {PK} 1..* 0..* buys datePurchased Relationships may also have attributes. These attribute(s) are connected to the relationship via a dashed line. 21 Session 2, 2010

ER Modelling Context is important ZEIT2301 Design of IS Week 01: Intro ER Modelling Context is important an attribute in one context may be an entity in another Is author an attribute of a Book entity or an entity in its own right? The model is about what is possible, not what is a fact at a particular point in time A candidate for employment potentially has many qualifications (or possibly none?) A candidate fills several position (ie over a period of time) 22 Session 2, 2010

Steps to create an ER Diagram: ZEIT2301 Design of IS Week 01: Intro Steps to create an ER Diagram: Identify Entities Look for nouns, major objects that we want to store data about. Identify Relationships Look for associations, verbs between nouns..… then add constraints Identify Attributes Look for nouns, noun phrases that are properties of things … decide if multi-valued, derived, etc … record description in data dictionary Choose Primary Key 23 Session 2, 2010

ZEIT2301 Design of IS Week 01: Intro Case Study Temps for Hire (TFH) has a file of candidates that are willing to work at short notice. The file lists the id, name, address and contact number for each candidate. All candidates at TFH have a number of qualifications and TFH uses a unique code and general description to specify the qualification. TFH also has a list of companies (name and address) that use their services. When a company has a position to be filled, they specify the start date, end date and hourly rate of the position. The company also specifies the essential qualifications required for the position. TFH matches the position qualifications against the candidates' qualifications and selects a candidate to fill the position. 24 Session 2, 2010

1. Identify Entities candidate company position qualification ZEIT2301 Design of IS Week 01: Intro 1. Identify Entities candidate company position qualification look for nouns, major objects Note: TFH itself not an entity in the database Session 2, 2010 25 Session 2, 2010

2. Identify Relationships ZEIT2301 Design of IS Week 01: Intro 2. Identify Relationships All candidates at TFH have a number of qualifications … When a company has a position to be filled, … The company also specifies the essential qualifications required for the position. … and selects a candidate to fill the position. Look for associations, verbs between nouns..… then add constraints 26 Session 2, 2010

2. Identify Relationships ZEIT2301 Design of IS Week 01: Intro 2. Identify Relationships candidate qualification has fills requiredFor company position specifies Session 2, 2010 27 Session 2, 2010

ZEIT2301 Design of IS Week 01: Intro 3. Identify Attributes … the id, name, address and contact number for each candidate … … a unique code and general description to specify the qualification. a list of companies (name and address) … … the start date, end date and hourly rate of the position. Look for nouns, noun phrases that are properties of things … decide if multi-valued, derived, etc … record description in data dictionary 28 Session 2, 2010

3. Identify Attributes candidate qualification company position has ZEIT2301 Design of IS Week 01: Intro 3. Identify Attributes candidate candidateID name address contactNo qualification qualificationCode description has fills requiredFor company name address position startDate endDate hourlyRate specifies 29 Session 2, 2010

ZEIT2301 Design of IS Week 01: Intro 4. Determine Keys … the id, name, address and contact number for each candidate … … a unique code and general description to specify the qualification. a list of companies (name and address) … … the start date, end date and hourly rate of the position. (no obvious key here?) Choose primary key … create artificial key if necessary Session 2, 2010 30 Session 2, 2010

4. Determine Keys candidate qualification company position has fills ZEIT2301 Design of IS Week 01: Intro 4. Determine Keys candidate candidateID {PK} name address contactNo qualification qualificationCode {PK} description has fills requiredFor company Name {PK} address position positionNo {PK} startDate endDate hourlyRate specifies 31 Session 2, 2010

ZEIT2301 Design of IS Week 01: Intro Multiplicity candidate candidateID {PK} name address contactNo qualification qualificationCode {PK} description has 0..* 0..* 1..* requiredFor fills 0..1 0..* 0..* company Name {PK} address position positionNo {PK} startDate endDate hourlyRate specifies 1..1 1..* Some assumptions on multiplicities made here - would need to clarify with stakeholders Session 2, 2010 32 Session 2, 2010

Summary After today’s lecture you should be able to Construct an ER-diagram Identify entities Identify relationships Determine attributes Select keys