Introduction to Database Design workshop: March 22-23, 1999 Entity-Relationship Diagrams: Introductory Description What is an Entity-Relationship Diagram (ERD)?

Identifies the data required by the business An entity corresponds to a person, place thing, event, or concept about which we are interested in recording data Entities must be clearly defined so that all understand exactly what is being represented Two entities whose information is somehow dependent on one another or connected with each other are said to have a relationship between them (e.g. friends may have many addresses) Relationships are evaluated in both directions to determine what type of relationship exists (e.g. one friend may have many telephones, and one telephone belongs to a single friend) Whats in an ERD? Entities are drawn in boxes Entities should be expressed in the plural The existence of a relationship between two entities is drawn as a line connecting the entities Arrows at the ends of the lines indicate different types of relationships (one-to-one, one-to-many, many-to-many) Verbs may be placed on the relationship lines that describe what the relationships mean (e.g. addresses locate businesses, where addresses and businesses are related entities, and locate is the verb describing the relationship.) Lists of attributes are developed as you go. (An attribute is a single piece of information that is descriptive of an entity, e.g. friend name, friend e-mail.) A single attribute for each entity is selected (or an arbitrary one is assigned) as being the unique identifier for each occurrence of the entity (e.g. business id number to uniquely identify a business). Tips on building ERDs: Nouns are clues to the entities of a business Start by describing the work that is done in the project or department or area of interest, then pull out nouns in the sentences as potential candidates for entities. (e.g. My address book contains addresses and telephone numbers for both friends and businesses.) Verbs and adjectives sometimes help to get at relationships between entities (e.g. friends have addresses) Many-to-many relationships will cause you lots of trouble! Get rid of them by defining an intermediate third entity (e.g Friends/Kids between Kids and Friends). Spend the time to accurately define your entities so that everyone clearly understand what they represent; you will save yourself a lot of time and headaches later in the process! A step-by-step worksheet to help you through the design process for an ERD will be distributed in this session.

Entity-Relationship Diagrams (ERDs)

Page 1

3/31/99

Ideas excerpted and summarized from Hernandez, Database Design for Mere Mortals, Addison-Wesley, 1998

A Sample Entity-Relationship Diagram (ERD) that describes the address book

Addresses

Sample fields: Address Street Address City Address State Address Zip code

Kids

Friends

Businesses

Sample fields: Business name Business contact first name Business contact last name Business URL

Sample fields: Kid name

Sample fields: Friend first name Friend last name Friend e-mail

Telephones
Sample fields: Telephone Area Code Telephone Number

Entity-Relationship Diagrams (ERDs)

Page 2

3/31/99

Ideas excerpted and summarized from Hernandez, Database Design for Mere Mortals, Addison-Wesley, 1998

Introduction to Database Design workshop: March 22-23, 1999 Entity-relationship diagrams (ERDs): Worksheets for ERD design process 1. Write a mission statement and objectives for your database. Whats in a good mission statement? Its very general It should not describe specific tasks It should define the purpose for the database Your objectives should: Each clearly define a single general task Be free from excess detail Be easy to understand

a. b. c.

a. b. c.

1. Assemble samples of the data you will collect. Look for anything that represents an existing database: post-it notes, index cards, reports on paper, documents on the computer, presentations, anything that might contain the data youre collecting.

2. Write statements about how youll use the database. How do you go about accomplishing the tasks described in your goals? Underline the nouns that represent objects (subjects). Copy the underlined words into the preliminary list of subjects, attached. Write more statements that described the data you need about those subjects. Underline nouns that represent characteristics (facts) about the subjects, and write them in the preliminary list of characteristics, attached. Hint for distinguishing subjects and facts: Can you express your sentence in a possessive form, e.g. students address? Here, student is a subject, and address is a characteristic.

Tests to distinguish characteristics and subjects: 1. Can this word be used to describe something? If so, its a characteristic. 2. Does this word represent a component of something else? If so, its a characteristic. 3. Does this word represent a collection of things? If so, its a subject. 4. Can this thing be broken down into smaller pieces? If so, its either a subject or more than one characteristic.

Entity-Relationship Diagrams

Page 3

3/31/99

Ideas excerpted and summarized from Hernandez, Database Design for Mere Mortals, Addison-Wesley, 1998

3. Try to group the characteristics into logical categories or groupings. Let the data suggest logical groupings to you. Write those groupings across the top of the tables and fields grid, attached. Write each characteristic in the column for the table on your grid. These are your fields.

4. Merge the preliminary list of subjects with your table list. Eliminate true duplicates, or rename tables that look like duplicates but really arent. Pick the clearest name you can for your tables. Use the ideal field test on your fields to see if theyre good fields. Whats in a good table or field name? unique clear and unambiguous no acronyms defines only one subject for tables, or one characteristic for fields expressed in the plural for tables, singular for fields

a. b. c. d. e.

a. b. c. d. e.

The Ideal Field Tests its a fact about the subject of the table it contains only a single value if not, break it out and make it its own table it cant be broken down into smaller pieces if it can, break it into multiple fields it does not contain a calculated value it is unique within the whole database structure

5. Analyze the data samples you collected. Use your samples to load sample data into your subject tables. Test for missing subjects and characteristics and add them to your lists. Tests to find missing subjects or characteristics: Can you find data in your samples thats not included in your characteristic list? Are there elements (especially on existing reports) that you always wished you had access to but dont right now? Do you have reports that treat subjects you havent listed? In general, try to use your samples to remind you of relevant data that you havent thought about yet.

a. b. c. d.

6. Define each table. Try to include an explanation of why each table is important to the organization. Keep them as clear, concise, and unambiguous as possible. Write your definitions below the tables and fields grids.

7. Identify primary keys for each table. A primary key uniquely identifies a single record in this table. If none of the existing fields uniquely identifies a record, add a field that will Entity-Relationship Diagrams Page 4 3/31/99
Ideas excerpted and summarized from Hernandez, Database Design for Mere Mortals, Addison-Wesley, 1998

contain an automatically-assigned sequential number. Draw a symbol, such as *, next to each primary key in your field list. 8. Perform a final check on your tables. Use the ideal table test to see if you have defined good tables. Elements of the Ideal Table It represents a single subject It has a primary key It does not contain multi-part or multi-valued fields It does not contain calculated fields If does not contain unnecessary duplicate fields It contains only an absolute minimum amount of redundant data.

1. 2. 3. 4. 5. 6.

9. Draw a box for each table on the ERD diagram. Label each box with the table name. Draw a line to represent a relationship between appropriate tables. Evaluate the type of relationship represented. Draw a single arrow on the one side, and a double arrow on the many side of the relationships. (See the sample ERD for examples.) Types of relationships (see your glossary of terms for complete definitions) a. one-to-one b. one-to-many c. many-to-many

10. Place verbs at each end of the relationship to describe why the tables are related. See the sample ERD for examples.

11. Assign foreign keys where needed. Make sure you add foreign keys (and possibly new intermediate tables) to your field lists on the Tables and Fields grids. Refer to the rules below. Draw a different symbol, like (!), next to each foreign key in your field list. Rules for foreign key assignments a. one-to-one: copy the primary key from the dominant table as a foreign key into the subordinate table. b. one-to-many: copy the primary key from the one side as a foreign key into the many side. c. many-to-many: insert a third table between the two tables, and copy the primary key from each table into the new third table. The only fields in this new table will be these foreign keys.

Worksheets for Entity-Relationship Diagrams Entity-Relationship Diagrams Page 5 3/31/99

Ideas excerpted and summarized from Hernandez, Database Design for Mere Mortals, Addison-Wesley, 1998

Goals, Objectives, and Statements about Use (steps 1 and 3) Mission statement:

Goals of the database: 1. 2. 3. 4. 5. 6. 7.

Statements about how you will use the database:

Entity-Relationship Diagrams

Page 6

3/31/99

Ideas excerpted and summarized from Hernandez, Database Design for Mere Mortals, Addison-Wesley, 1998

Worksheets for Entity-Relationship Diagrams Preliminary list of subjects (steps 3 through 5) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Worksheets for Entity-Relationship Diagrams Preliminary list of characteristics (steps 3 through 5) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Entity-Relationship Diagrams Page 7 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 3/31/99

Ideas excerpted and summarized from Hernandez, Database Design for Mere Mortals, Addison-Wesley, 1998

Worksheets for Entity-Relationship Diagrams Tables and Fields Grids (#1) (steps 4 through 9) List table names in the top row of the grid. Under each table name, list the fields associated with the table. Use the grid on the next page, as well, if you need more tables.

Table Definitions: 1.

2.

3.

4.

Entity-Relationship Diagrams

Page 8

3/31/99

Ideas excerpted and summarized from Hernandez, Database Design for Mere Mortals, Addison-Wesley, 1998

Worksheets for Entity-Relationship Diagrams Tables and Fields Grids (#2) (steps 4 through 9)

Table Definitions: 1.

2.

3.

4.

Entity-Relationship Diagrams

Page 9

3/31/99

Ideas excerpted and summarized from Hernandez, Database Design for Mere Mortals, Addison-Wesley, 1998

Worksheets for Entity-Relationship Diagrams Drawing your ERD (steps 10 through 12)

Entity-Relationship Diagrams

Page 10

3/31/99

Ideas excerpted and summarized from Hernandez, Database Design for Mere Mortals, Addison-Wesley, 1998

Introduction to Database Design workshop: March 22-23, 1999 Worksheets for Entity-Relationship Diagrams Music Library Hands-On Example Goals, Objectives, and Statements about Use (steps 1 and 3) Mission statement: The purpose of the music library database is to keep track of all the music in my collection and help me better access and enjoy the albums I have. Goals of the database: 1. if you know a song title, be able to find the title of the album the song is on 2. if you know the title of a album, be able to find it on the shelf 3. produce a list of songs by artist 4. produce a list of songs by genre 5. produce a list of songs by composer 6. produce a list of all the albums in the library by a given artist

Statements about how you will use the database:

ERD Hands-On: Music Library

Page 11

3/31/99

Worksheets for Entity-Relationship Diagrams Music Library Hands-On Example Preliminary list of subjects (steps 3 through 5) 1. 2. 3. 4. 5. 6. 7. 8.

Worksheets for Entity-Relationship Diagrams Music Library Hands-On Example Preliminary list of characteristics (steps 3 through 5) 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.

ERD Hands-On: Music Library

Page 12

3/31/99

Worksheets for Entity-Relationship Diagrams Music Library Hands-On Example Tables and Fields Grids (#1) (steps 4 through 9) List table names in the top row of the grid. Under each table name, list the fields associated with the table. Use the grid on the next page, as well, if you need more tables.

Table Definitions: 1.

2.

3.

4. Worksheets for Entity-Relationship Diagrams ERD Hands-On: Music Library Page 13 3/31/99

Music Library Hands-On Example Tables and Fields Grids (#2) (steps 4 through 9)

Table Definitions: 1.

2.

3.

4.

Worksheets for Entity-Relationship Diagrams ERD Hands-On: Music Library Page 14 3/31/99

Music Library Hands-On Example Drawing your ERD (steps 10 through 12)

ERD Hands-On: Music Library

Page 15

3/31/99