1. COMP 430 Intro. to Database Systems Design Process

2. Design Process – Why?!? Is this your reaction?

3. Going beyond simple one-person assignments Specifications not handed to you Complex Vague Not necessarily known by one person An abbreviated guide to Database Specification...

5. Requirements – Data items & meanings Talk to everyone involved to understand what data is needed. Eliminate redundant items Salesperson: Items sold Loading dock worker: Items shipped

6. Identify data items that can be calculated Eliminate redundancy from base tables Use views, calculated fields, application code, … If you knowYou can calculate Game teams + scoresWinning team Student scoresLetter grades Racer timeRace ranking Date shippedHas it shipped? Who manages whomNumber of subordinates Purchased item prices + quantitiesPurchase subtotal Purchased item prices + quantities + location + date Purchase total, including taxes

7. Group/ungroup data items into fields One field or multiple? Game score Height Name Address Days of the week worked Period worked

8. Identify representations & types of fields What type? Height Student number Elapsed time Day of the week Consider abstract types like integer, real, text string, currency, date/time.

9. Avoid data items that need regular updates Data that needs to be updated Age Duration of employment Batting average Total commissions

10. Group fields into entities/tables Largely common sense, but also tied to table/relationship design… PersonCourse Dept code Title Birth date First name Last name Number Instructor RoomPhone number

11. Identify relationships between tables Lots more discussion coming soon! PersonCourse Dept code Title Birth date First name Last name Number Instructor RoomPhone number One/many to one/many?

12. Identify or create keys Entity/TablePrimary key? PersonName, SSN, thumbprint CourseDept code + number Team playerJersey number Campus buildingName, abbreviation Library bookISBN Possibly create surrogate/synthetic keys. Some desirable properties: Unique Exists/Known Immutable Simple/compact

13. Natural vs synthetic keys Advantages of naturalAdvantages of synthetic Field exists already – no extra dataConcise – single short value Human-readable, -searchableImmutable (typically) Data exists

14. Design-related Implementation Issues

15. Field & Table naming conventions Many conflicting conventions What’s important: Consistency Readable but not too long Table names – singular, not plural; typically nouns, not verbs Field names – no type info; typically nouns or adjectives (for Boolean) Foreign keys field names – easy match to primary keys

16. Synthetic key types IntegerText Auto-incrementing integer Unique ID Standard SQL Concise Automatically unique Disallows operations Good for indexing

17. Calculated data Calculated once-and-for-all, or as needed? When? Store result in database? Database management system Calculated field or aggregation in query Procedure/function Application code

18. Data validation User-interface Application Database management system CHECK constraints – including PRIMARY KEY, FOREIGN KEY, NOT NULL Lookup/validation tables (Explore these later.)

19. Next: The core issues of table & relationship design.