Database Design. A Bottom-Up Approach

Transcription

1 Database Design A Bottom-Up Approach

2 Reality Check Why do you need a database? What is the primary use of your database? Fast data entry Fast queries Summary data Who is responsible for the content? Who are the users of your database? Online users Administrator Company departments

3 RDBMS Most Common Database Designs Business Intelligence Database Design Focus on queries and summary data Planned redundancy built into the design Primary purpose is data mining Transactional Database Design Focus on data entry and storage efficiency Limited or no data redundancy in the design Primary purpose is processing transactions

4 Transactional Database Design Meade Rule of Thumb #0: Know your data and look at it often a lot of it. Meade Rule of Thumb #1: If you see it over and over again (redundancy), it needs its own table. Example #1: Example#2: Example#3 Santa Rosa Beatles iphone5 Santa Rosa Beatles iphone5 Santa Rosa Beatles iphone5 (Need a city table) (Need an artist table) (Need a product table) Note: The table name isn t the data, it describes the data group. The column name isn t the data, it describes the type of data. Table: Artist(describes data group that includes artist name and related info organized into columns) Column: artist_name(describes the type of data: string representing an artist s name that is a piece of a larger group of data)

5 Transactional Database Design Meade Rule of Thumb #2: If it doesn t make sense by itself, it belongs in a table with something that explains it. Example #1: Example#2: 5431 Main St $24.99 (need a customer) (need a product)

6 Transactional Database Design Meade Rule of Thumb #3: If something can be explained by more than one thing, those things must be related in some way. Example #1: Thirsty Dog Track 6 1 st Explanation: it s a track! (Track 6 album Let Love In ) 2 nd Explanation: its the track from that album

7 Transactional Database Design Meade Rule of Thumb #4: Keep it simple Data in tables will naturally overlap or cascade. If data is partially explained, it is probably enough (if you follow rule #3) Example: Thirsty Dog Track 6 (Track table) Track 6 Let Love In (Album table) NOT Thirsty Dog Track 6 Let Love In (can be too many layers in one table)

8 Transactional Database Design Meade Rule of Thumb #5: All tables have a primary key, but only one table in a relationship has a foreign key. Play the foreign key game (only one wins): Single row match = foreign key Multiple row matches = no foreign key Example: Single match: one album belongs to only one artist. Album table wins: foreign key Multiple match: one artist has many albums. Artist table loses: no foreign key

9 A Bottom-Up Approach to Design Look at all of your data (or a lot of it) Find a data element that does not make sense by itself and group it with the data that explains it or at least partially explains it (repeat until all data elements are grouped). You now have several groups. These will be your first draft list of tables. Give them all primary keys. Check for overlaps or cascades in your groups. If data in one table further explains data in another table, mark a relationship. Play the foreign key game with data in tables that have a relationship Single match = foreign key (only one wins) Multiple matches = no foreign key Document your initial design. Put real data into your design and look for redundancy. If you find it, split the table. Test it by trying to create SQL for all needed searches, updates, adds and deletes. Can you get to the data you need? If not, refine your initial design by re-grouping or re-defining relationships as needed.

10 A Bottom-Up Approach to Design Document your initial design. Put real data into your design and look for redundancy. If you find it, split the table. Test it by trying to create SQL for all needed searches, updates, adds and deletes. Can you get to the data you need? If not, refine your initial design by re-grouping or re-defining relationships as needed.