0% found this document useful (0 votes)
106 views

Assignment 3

A database is a collection of data organized in tables that can be related to each other. A relational database management system (RDBMS) uses tables that can reference fields in other tables via relationships. Separating data into normalized tables avoids data redundancy and makes the database easier to maintain by storing different types of data, like customer and order information, in their own tables that can reference each other through relationships.

Uploaded by

Abhinandan
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
106 views

Assignment 3

A database is a collection of data organized in tables that can be related to each other. A relational database management system (RDBMS) uses tables that can reference fields in other tables via relationships. Separating data into normalized tables avoids data redundancy and makes the database easier to maintain by storing different types of data, like customer and order information, in their own tables that can reference each other through relationships.

Uploaded by

Abhinandan
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 1

What Is a Database?

In the broadest definition, a database is anything that collects and organizes


data. A spreadsheet holding customer bookings is a database, and so is a plain-text file con‐ taining
flight schedule data. Plain-text data itself can be stored in a variety of formats, including XML and
CSV. Professionally, however, when one refers to a “database” they likely are referring to a relational
database management system (RDBMS). This term may sound technical and intimidating, but an
RDBMS is simply a type of database that holds one or more tables that may have relationships to
each other. Exploring Relational Databases A table should be a familiar concept. It has columns and
rows to store data, much like a spreadsheet. These tables can have relationships to each other, such
as an ORDER table that refers to a CUSTOMER table for customer information. For example, suppose
we have an ORDER table with a field called CUSTOMER_ID (Figure 2-1). Figure 2-1. An ORDER table
with a CUSTOMER_ID 3 We can reasonably expect there to be another table, maybe called
CUSTOMER (Figure 2-2), which holds the customer information for each CUSTOMER_ID. Figure 2-2.
A CUSTOMER table When we go through the ORDER table, we can use the CUSTOMER_ID to look up
the cus‐ tomer information in the CUSTOMER table. This is the fundamental idea behind a “rela‐
tional database,” where tables may have fields that point to information in other tables. This
concept may sound familiar if you’ve used VLOOKUP in Excel to retrieve information in one sheet
from another sheet in a workbook. Why Separate Tables? But why are these tables separated and
designed this way? The motivation is normal‐ ization, which is separating the different types of data
into their own tables rather than putting them in one table. If we had all information in a single
table, it would be redundant, bloated, and very difficult to maintain. Imagine if we stored customer
information in the ORDER table. Figure 2-3 shows what it would look like. Figure 2-3. A table that is
not normalized Notice that for the Re-Barre Construction orders someone had to populate the cus‐
tomer information three times for all three orders (the name, region, street address, city, state, and
zip). This is very redundant, takes up unnecessary storage space, and is difficult to maintain. Imagine
if a customer had an address change and you had to update all the orders to reflect that. This is why
it is better to separate CUSTOMERS and ORDERS into two separate tables. If you need to change a
customer’s address, you only need to change one record in the CUSTOMER table (Figure 2-4)

You might also like