Database Tables 2914

two order-entry scenarios: A customer wants to cancel an order that she's placed. If her address is in a separate table from her order, you can easily delete the order without deleting her address. Or you've just entered a pile of customer orders when your company changes its shipping methods. If the shipping methods are maintained in their own table, you don't have to update each individual order. Access works with separate tables in relational databases, which can help you structure data efficiently, avoid wasted effort, and reduce headaches. Relational databases store data in separate tables, based on subject matter, but the tables are brought together through relationships. For example, a table of customers is related to a table of orders by a customer ID field in each of those tables. Typically, data should not be repeated in more than one table, except for such relating fields.

Why separate tables? Some benefits of this method are: Efficiency You don't have to store redundant information, such as a customer's name or address, in every order that the customer places. Control It's easier to update, delete, and extend data in a well-structured database that doesn't contain duplication. Accuracy By avoiding repetition, you decrease the opportunity for errors. Right once, right everywhere. Data integrity You can add or remove fields or records in unique tables without affecting your data structure, and you will not need to redesign your database. Separation protects your original structure. As you plan your tables, think of ways to structure your data so that it's easy to enter and maintain. Saved space.

Structure your tables to avoid duplication Here are some questions you can ask to help you better structure your data: Is each record unique or is a record repeated somewhere else? Are any details, or any groups of details, repeated in more than one record or table? Can you easily make changes to one record without changing another record? Does each record contain only the details that belong in that record, specifically appropriate to the record's identity? Are any fields dependent on other fields in the table?

Structure your tables to avoid duplication If tables are not designed with the optimal structure, some relations will suffer from undesirable consequences: losing data, having to update data in multiple places, or being unable to add new data. To see an example of how awkward organization can cause problems, consider the situation shown in the first table. Suppose you want to change the details for Exotic Liquids in your database. If you store supplier information such as the address in each record in the Products table, you'll have to modify each record there. By storing supplier information separately in its own Suppliers table, you can change the details just once, in that table. As the second table here shows, every product record that contains the Exotic Liquids Supplier ID number will refer to that updated information. Using the Supplier ID lets you remove supplier names and addresses from the Products table, avoiding duplicate information and a lot of unnecessary data maintenance. Keep in mind: The more sense your tables make to you now, the more sense they will make to you later, and the easier they will be to use in powerful ways.

Why separate tables? The Suppliers table contains all the contact information about those businesses. The Products table refers to the Suppliers table, but doesn't have to include all the suppliers'

Structure your tables to avoid duplication Redundant — supplier details included with each product. Efficient — supplier details in separate Suppliers table, with references from Products table.