These data structures were inefficient, hard to maintain, and hard to optimize for delivering good application performance. When developers wanted to build applications to use that data, they had to know a lot about the particular data structure to find the data they needed. In the early years of databases, every application stored data in its own unique structure. For example, an integrity rule can specify that duplicate rows are not allowed in a table in order to eliminate the potential for erroneous information entering the database. To ensure that data is always accurate and accessible, relational databases follow certain integrity rules. Logical operations allow an application to specify the content it needs, and physical operations determine how that data should be accessed and then carries out the task. The distinction between logical and physical also applies to database operations, which are clearly defined actions that enable applications to manipulate the data and structures of the database. For example, renaming a database file does not rename the tables stored within it. This separation means that database administrators can manage physical data storage without affecting access to that data as a logical structure. The relational model means that the logical data structures-the data tables, views, and indexes-are separate from the physical storage structures. The warehouse can then pull the correct product, the customer can receive timely delivery of the order, and the company can get paid. Then, when the company’s order processing application submits an order to the database, the database can go to the customer order table, pull the correct information about the product order, and use the customer ID from that table to look up the customer’s billing and shipping information in the customer info table. But because of that common column, the relational database can create a relationship between the two tables. These two tables have only one thing in common: the ID column (the key). In the second table-a customer order table-each record includes the ID of the customer that placed the order, the product ordered, the quantity, the selected size and color, and so on-but not the customer’s name or contact information.
Each bit of information (each attribute) is in its own column, and the database assigns a unique ID (a key) to each row. The first table is a customer info table, so each record includes a customer’s name, address, shipping and billing information, phone number, and other contact information. Here’s a simple example of two tables a small business might use to process orders for its products.
0 kommentar(er)
