Transforming ER models into database designs - Webfuse

Transforming ER models into database designs Objectives On completion of this chapter, you should be able to: »» understand and describe rules for enforcing referential integrity »» understand and describe referential integrity actions, specifically: »» cascade update »» cascade delete »» be able to convert a given ER diagram into a relational database design.

Introduction This chapter explains how to convert an Entity-Relationship diagram into a set of relational database tables. This is an important skill that will require some practice. As you can see, the chapter objectives contain few theory and knowledge objectives—this chapter is largely about acquiring the practical skill of database design. Textbook Kroenke 2006 Ch. 6, pp. 171-194.

Reading notes »» Kroenke p. 172—Illustrating tables: In addition to the style of writing tables shown by Kroenke in Figure 6-3(b), you can also write them out in the more prosaic form shown like that on the top of p. 180. This latter form is more concise and is handy if you are using a word processor. When writing relational tables out by hand, it can be difficult to clearly show the difference between italic handwriting and normal handwriting. In such circumstances, you can show foreign keys with dotted underline; the foreign keys will be visually distinct and the meaning of the dotted underline will be clear to anyone familiar with database design. »» Kroenke p. 173—Surrogate key: Actually a surrogate key does not have to be DBMS-supplied. Some people use the term surrogate key only to refer to a meaningless DBMS-supplied key; others (including this author) use it to refer to any meaningless key regardless of whether it is created automatically by the DBMS or explicitly by database program code as needed. The important part about a surrogate key is that it is meaningless and created by the database or DBMS and not entered by the user. The advantage of such a surrogate key is that key values should never need to change. Imagine if we changed your student number on you every few months? This would be frustrating for you, but worse for anyone maintaining our databases! Part of the reason why we choose such a number for your student ID is because we should never need to change the student number assigned to you. »» Kroenke p. 174—Surrogate key: Like Kroenke, this author also strongly prefers the use of surrogate keys.

COIT12167 - Module 5 - Page 17

»» Kroenke p. 174—Alternate keys and candidate keys: Actually these two words are not quite synonymous. A candidate key is any attribute or set of attributes that can uniquely identify each row in the relation. A relation might have several candidate keys. Of the candidate keys, one and only one would be selected as the primary key, the remaining candidates are known as alternate keys. »» Kroenke p. 174—Alternate keys: Kroenke lists (Name, City) and Email as candidate keys for the Customer relation. These would be very poor candidate keys indeed. Remember that a candidate key is any attribute or set of attributes that are capable of acting as a primary key. To say that (Name, City) is a candidate key is to state that no two customers in the same city can ever have the same name. This is obviously a very poor assumption. To state that Email is a candidate key is even more ridiculous – people change their email addresses all the time, they can have more than one, occasionally even multiple people share one email address. »» Kroenke p. 175—It would be better to simply specify that Email must be unique by specifying a unique index (which you will learn about later) on that column. This would enforce uniqueness on the Email column without requiring that every Employee must have an email addresses. This crazy use of terminology by Kroenke seems to be an artefact of ERWin. »» Kroenke p. 174-176—Kroenke’s discussion here is actually quite important. Careful selection of data types, default values, constraints etc can considerably improve the integrity of your database. It makes no sense, for example, to use a character or string data type for an Australian post code. There is no such thing as a post code that looks like 43DE in Australia. Every Australian post code is a 4-digit number; therefore an Australian post code attribute should be defined as an integer (no decimal places) which must be greater than 0 and less than 10,000. (Even better, if you can obtain a list of all valid post codes from Australia Post, you could use this list to verify any post code entered by the user.) Whether or not the post code is nullable would depend on the particular situation at hand. »» Kroenke p. 176ff—There is a lot of information in this chapter, possibly too much for you to absorb in a single week. If you are finding this chapter a bit overwhelming, then concentrate on the conversion of entities and simple binary 1:1, 1:N and M:N relationships, as these are by far the most common. The remaining structures, such as recursive, nested ID-dependent relationships, etc. are much less common. Concentrate on the simple binary relationships, get them under your belt, and not only will this see you through most of your database design, but understanding them will help you to understand how to convert the other types of relationships. You may wish to return to this chapter at a later point in the term when you are more confident with basic database design.

Closing remarks Don’t let the large amount of detail overwhelm you. Practise the conversion of binary 1:1, 1:N and M:N relationships; this will cover most of the modelling that you need to do and help you to gain a more firmly grounded understanding before tackling the more unusual relationships.


Review questions Review question 5–1 Kroenke Review Questions: 6.4, 6.5, 6.8, 6.10, 6.25, 6.26

Review question 5–2 Kroenke Project Questions: 6.52, 6.53, 6.56–6.58

References Kroenke, DM 2006, Database processing: fundamentals, design and implementation, 10th edn, Prentice Hall, New Jersey.
