Importance of database design (1)
- 2. Database design is the process of producing a detailed data model of a database.
- 3. This logical data model contains all the needed logical and physical design choices and physical storage parameters needed to generate a design in a Data Definition Language, which can then be used to create a database.
- 4. A fully attributed data model contains detailed attributes for each entity.
- 5. Usually, the designer must: Determine the relationships between the different data elements. Superimpose a logical structure upon the data on the basis of these relationships.
- 6. THE DESIGN PROCESS Determine the purpose of the database - This helps prepare for the remaining steps.
- 7. Find and organize the information required - Gather all of the types of information to record in the database, such as product name and order number.
- 8. Divide the information into tables - Divide information items into major entities or subjects, such as Products or Orders. Each subject then becomes a table.
- 9. Turn information items into columns - Decide what information needs to stored in each table. Each item becomes a field, and is displayed as a column in the table. For example, an Employees table might include fields such as Last Name and Hire Date.
- 10. Specify primary keys - Choose each table’s primary key. The primary key is a column that is used to uniquely identify each row.
- 11. Setup the table relationships - Look at each table and decide how the data in one table is related to the data in other tables. Add fields to tables or create new tables to clarify the relationships, as necessary.
- 12. Refine the design - Analyze the design for errors. Create tables and add a few records of sample data. Check if results come from the tables as expected. Make adjustments to the design, as needed.
- 13. Apply the normalization rules - Apply the data normalization rules to see if tables are structured correctly. Make adjustments to the tables
- 14. THE TABLES
- 15. The core table of the database is Incident. This tracks the bulk of information submitting about a particular incident. For example, under injuries there might be multiple parts of the body that were injured. There are several ways to deal with this.
- 16. Solution Pros Cons Add one field for Keeps all the data in one Makes the table extremely large. Adding each item table. a new piece of information to be stored means adding an entirely new field. If there are multiple copies of the database in use synchronization becomes extremely difficult. Many database fields will be empty. Poor database design practice. Less efficient database storage. Allow multiple Keeps all the data in one Extremely poor database design pieces of data to be table. practice. Makes querying the database entered in each for incidents that meet certain criteria field. extremely difficult and time consuming. Create Child Tables Best practice for database Spreads data out over multiple tables design. Allows for easily which means that greater database adding new types of expertise is needed to develop and work information. Does not with the data. create a "bulky" core table. More efficient for querying the database for incidents that meet certain criteria.
- 17. The recommendation is to create an idb_Incidents Table to handle the information that is discrete (that is can only have one value such as the date of the incident) and create a series of Child tables that store information where there may be multiple pieces of data.
- 18. This makes the database much more extendable. If new information needs to be collected, either a new field would be added to the idb_Incidents Table or a new Child table could be created.