{"id":1091,"date":"2025-01-13T19:17:40","date_gmt":"2025-01-14T00:17:40","guid":{"rendered":"https:\/\/pressbooks.bccampus.ca\/nelson\/chapter\/chapter-7-redundancy-functional-dependencies-closure-and-normalization\/"},"modified":"2025-01-13T20:25:52","modified_gmt":"2025-01-14T01:25:52","slug":"chapter07thirdedition","status":"publish","type":"chapter","link":"https:\/\/pressbooks.bccampus.ca\/nelson\/chapter\/chapter07thirdedition\/","title":{"raw":"Chapter 7 Redundancy, Functional Dependencies, Closure, and Normalization","rendered":"Chapter 7 Redundancy, Functional Dependencies, Closure, and Normalization"},"content":{"raw":"
\r\n

Original Chapter 10 Author: Adrienne Watt<\/p>\r\n

Original Chapter 11 Author: Adrienne Watt<\/p>\r\n

Original Chapter 12 Author: Adrienne Watt<\/p>\r\n

Rewrite: Fred Strickland<\/p>\r\n\r\n

Learning Outcomes<\/h2>\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
\r\n

Computing Sub Discipline<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Document Code, Reference Code, and Page Number<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Text<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

Computer Science<\/p>\r\n<\/td>\r\n

\r\n

CS2013<\/p>\r\n

IM\/Relational Databases (RD)<\/p>\r\n

(Page 115-116)<\/p>\r\n<\/td>\r\n

\r\n

6. Determine the functional dependency between two or more attributes that are a subset of a relation. [Assessment]<\/p>\r\n

7. Connect constraints expressed as primary key and foreign key, with functional dependencies. [Usage]<\/p>\r\n

8. <\/a>Compute the closure of a set of attributes under given functional dependencies. [Usage]<\/p>\r\n

9. Determine whether a set of attributes form a superkey and\/or candidate key for a relation with given functional dependencies. [Assessment]<\/p>\r\n

Repeated learning outcome.<\/p>\r\n

11. Describe the properties of BCNF, PJNF, 5NF. [Familiarity]<\/p>\r\n

12. <\/a>Explain the impact of normalization on the efficiency of database operations especially query optimization. [Familiarity]<\/p>\r\n

13. Describe what is a multi-valued dependency and what type of constraints it specifies. [Familiarity]<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

CS2023<\/p>\r\n

DM-Core: Core Database Systems Concepts<\/p>\r\n

(Pages 115-116)<\/p>\r\n<\/td>\r\n

\r\n

CS Core 6. Normalization<\/p>\r\n

ILO CS Core 7. Describe the advantages for eliminating duplicate repeated data.<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

CS2023<\/p>\r\n

DM-Relational: Relational Databases<\/p>\r\n

(Pages 117-118)<\/p>\r\n<\/td>\r\n

\r\n

KA Core 5. Introduction to Functional dependency theory.<\/p>\r\n

KA Core 6. Normalization Theory<\/p>\r\n

KA Core 6a. Decomposition of a schema; lossless join, and dependency-preservation properties of a decomposition<\/p>\r\n

KA Core 6b. Normal forms (BCNF)<\/p>\r\n

KA Core 6c. Denormalization (for efficiency)<\/p>\r\n

Non-core 7. Functional dependency theory<\/p>\r\n

Non-core 7a. Closure of a set of attributes<\/p>\r\n

Non-core 7b. Canonical Cover<\/p>\r\n

Non-core 8. Normalization theory<\/p>\r\n

Non-core 8a. Multi-valued dependency (4NF)<\/p>\r\n

Non-core 8b. Join dependency (PJNF, 5NF)<\/p>\r\n

ILO KA Core 6. Describe how functional dependency theory generalizes the notion of key.<\/p>\r\n

ILO KA Core 7. Defend a given decomposition as lossless and or dependency preserving.<\/p>\r\n

ILO KA Core 8. Detect which normal form a given decomposition yields.<\/p>\r\n

ILO KA Core 9. Comment on reasons for denormalizing a relation.<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

Information Technology<\/p>\r\n<\/td>\r\n

\r\n

IT2017<\/p>\r\n

ITE-IMA-02 Data information concepts<\/p>\r\n

(Page 92)<\/p>\r\n<\/td>\r\n

\r\n

c. Illustrate data quality, accuracy, and timeliness, and explain how their absence will impact organizations.<\/p>\r\n

Repeated learning outcome<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

IT2017<\/p>\r\n

ITE-IMA-04 Database query languages<\/p>\r\n

(Page 92)<\/p>\r\n<\/td>\r\n

\r\n

c. <\/a>Express the relationship between functional dependencies and keys, and give examples.<\/p>\r\n<\/td>\r\n<\/tr>\r\n

<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

Introduction to Chapter 7<\/h2>\r\n

Chapter 6 addressed the mechanisms for preventing bad or duplicate data from being entered into a database. We looked at integrity rules, constraints, and cardinality for ensuring the high quality of the data. From the \u201cseat of the pants,\u201d we figured out what tables we might need. What if you are starting with no suggestions and with no guidance? If you have extensive experience with spreadsheets, you might be tempted to create one huge database table. There are issues with this approach. There is a reasonable approach for avoiding these issues.<\/p>\r\n\r\n

The Third Edition Style Guide<\/h2>\r\n

This is the style guide that this book will follow for this chapter and for the other chapters.<\/p>\r\n\r\n\r\n\r\n\r\n\r\n
\r\n

Naming Convention:<\/p>\r\n\r\n

    \r\n \t
  • All English names<\/li>\r\n \t
  • Plural table names<\/li>\r\n \t
  • Singular column names<\/li>\r\n \t
  • Capitalized words<\/li>\r\n \t
  • Pascal Case for composite names<\/li>\r\n \t
  • No underscores or special characters<\/li>\r\n \t
  • No unique SQL commands<\/li>\r\n \t
  • No object prefixes<\/li>\r\n<\/ul>\r\n

    Using the IE\u2019s Notation with Crow\u2019s Foot Notation.<\/p>\r\n<\/td>\r\n<\/tr>\r\n

<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

Figure 7.1 The database style guide. Adapted from https:\/\/vertabelo.com\/blog\/database-schema-naming-conventions\/<\/p>\r\n\r\n

The Redundancy Issue<\/h2>\r\n

Redundancy<\/em> is when data appears in some fashion two more times in a table. This is undesirable, because it causes problems.<\/p>\r\n\r\n\r\n\r\n\r\n\r\n
\r\n

Third edition<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
\r\n

AccountNumber<\/p>\r\n<\/td>\r\n

\r\n

Balance<\/p>\r\n<\/td>\r\n

\r\n

Customer<\/p>\r\n<\/td>\r\n

\r\n

Branch<\/p>\r\n<\/td>\r\n

\r\n

Address<\/p>\r\n<\/td>\r\n

\r\n

Assets<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-101<\/p>\r\n<\/td>\r\n

\r\n

500<\/p>\r\n<\/td>\r\n

\r\n

1313131<\/p>\r\n<\/td>\r\n

\r\n

Downtown<\/p>\r\n<\/td>\r\n

\r\n

Brooklyn<\/p>\r\n<\/td>\r\n

\r\n

9000000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-102<\/p>\r\n<\/td>\r\n

\r\n

400<\/p>\r\n<\/td>\r\n

\r\n

1313131<\/p>\r\n<\/td>\r\n

\r\n

Perryridge<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

1700000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-113<\/p>\r\n<\/td>\r\n

\r\n

600<\/p>\r\n<\/td>\r\n

\r\n

9876543<\/p>\r\n<\/td>\r\n

\r\n

Round Hill<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

8000000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-201<\/p>\r\n<\/td>\r\n

\r\n

900<\/p>\r\n<\/td>\r\n

\r\n

9876543<\/p>\r\n<\/td>\r\n

\r\n

Brighton<\/p>\r\n<\/td>\r\n

\r\n

Brookly<\/p>\r\n<\/td>\r\n

\r\n

7100000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-215<\/p>\r\n<\/td>\r\n

\r\n

700<\/p>\r\n<\/td>\r\n

\r\n

1111111<\/p>\r\n<\/td>\r\n

\r\n

Manus<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

400000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-222<\/p>\r\n<\/td>\r\n

\r\n

700<\/p>\r\n<\/td>\r\n

\r\n

1111111<\/p>\r\n<\/td>\r\n

\r\n

Redwood<\/p>\r\n<\/td>\r\n

\r\n

Palo Alto<\/p>\r\n<\/td>\r\n

\r\n

2100000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-305<\/p>\r\n<\/td>\r\n

\r\n

350<\/p>\r\n<\/td>\r\n

\r\n

1234567<\/p>\r\n<\/td>\r\n

\r\n

Round Hill<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

8000000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

Second Edition<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

\"image\"<\/p>\r\n<\/td>\r\n<\/tr>\r\n

<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

Figure 7.2 Example of a table containing redundant data. The bottom image is a reproduction of Figure 10.1 from the second edition (A. Watt).<\/p>\r\n

In Figure 7.2, Customer 1313131 appears twice, because of two accounts (A-101 and A102). This is true for Customer 976543 and for 1111111. What could go wrong?<\/p>\r\n\r\n

Insertion Anomaly<\/h3>\r\n

An insertion anomaly<\/em> occurs when you are inserting inconsistent information into a table. When we insert a new record, such as account number A-306 in Figure 7.3, we need to check that the branch data is consistent with existing rows.<\/p>\r\n\r\n\r\n\r\n\r\n\r\n
\r\n

Third edition<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
\r\n

AccountNumber<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Balance<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Customer<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Branch<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Address<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Assets<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-101<\/p>\r\n<\/td>\r\n

\r\n

500<\/p>\r\n<\/td>\r\n

\r\n

1313131<\/p>\r\n<\/td>\r\n

\r\n

Downtown<\/p>\r\n<\/td>\r\n

\r\n

Brooklyn<\/p>\r\n<\/td>\r\n

\r\n

9000000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-102<\/p>\r\n<\/td>\r\n

\r\n

400<\/p>\r\n<\/td>\r\n

\r\n

1313131<\/p>\r\n<\/td>\r\n

\r\n

Perryridge<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

1700000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-113<\/p>\r\n<\/td>\r\n

\r\n

600<\/p>\r\n<\/td>\r\n

\r\n

9876543<\/p>\r\n<\/td>\r\n

\r\n

Round Hill<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

8000000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-201<\/p>\r\n<\/td>\r\n

\r\n

900<\/p>\r\n<\/td>\r\n

\r\n

9876543<\/p>\r\n<\/td>\r\n

\r\n

Brighton<\/p>\r\n<\/td>\r\n

\r\n

Brookly<\/p>\r\n<\/td>\r\n

\r\n

7100000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-215<\/p>\r\n<\/td>\r\n

\r\n

700<\/p>\r\n<\/td>\r\n

\r\n

1111111<\/p>\r\n<\/td>\r\n

\r\n

Manus<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

400000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-222<\/p>\r\n<\/td>\r\n

\r\n

700<\/p>\r\n<\/td>\r\n

\r\n

1111111<\/p>\r\n<\/td>\r\n

\r\n

Redwood<\/p>\r\n<\/td>\r\n

\r\n

Palo Alto<\/p>\r\n<\/td>\r\n

\r\n

2100000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-305<\/p>\r\n<\/td>\r\n

\r\n

350<\/p>\r\n<\/td>\r\n

\r\n

1234567<\/p>\r\n<\/td>\r\n

\r\n

Round Hill<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

8000000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-306<\/span><\/p>\r\n<\/td>\r\n

\r\n

800<\/span><\/p>\r\n<\/td>\r\n

\r\n

1111111<\/span><\/p>\r\n<\/td>\r\n

\r\n

Round Hill<\/span><\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/span><\/p>\r\n<\/td>\r\n

\r\n

8000800<\/span><\/p>\r\n<\/td>\r\n<\/tr>\r\n

<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

Second Edition<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

\"image\"<\/p>\r\n

<\/p>\r\n<\/td>\r\n<\/tr>\r\n

<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

Figure 7.3 Example of an insertion anomaly. The bottom image is a reproduction of Figure 10.2 from the second edition (A. Watt).<\/p>\r\n

The issue is that the asset boxes for A-113 and for A-305 do not agree with the figure for A-306. To keep the data consisted, we would need to revise the figures for these other two accounts.<\/p>\r\n\r\n

Update Anomaly<\/h3>\r\n

The last paragraph was a hint to this issue. An update anomaly<\/em> occurs when you are updating data and similar rows need to be found and updated. Figure 7.4 shows this situation for the Round Hill branch.<\/p>\r\n\r\n\r\n\r\n\r\n\r\n
\r\n

Third edition<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
\r\n

AccountNumber<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Balance<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Customer<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Branch<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Address<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Assets<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-101<\/p>\r\n<\/td>\r\n

\r\n

500<\/p>\r\n<\/td>\r\n

\r\n

1313131<\/p>\r\n<\/td>\r\n

\r\n

Downtown<\/p>\r\n<\/td>\r\n

\r\n

Brooklyn<\/p>\r\n<\/td>\r\n

\r\n

9000000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-102<\/p>\r\n<\/td>\r\n

\r\n

400<\/p>\r\n<\/td>\r\n

\r\n

1313131<\/p>\r\n<\/td>\r\n

\r\n

Perryridge<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

1700000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-113<\/p>\r\n<\/td>\r\n

\r\n

600<\/p>\r\n<\/td>\r\n

\r\n

9876543<\/p>\r\n<\/td>\r\n

\r\n

Round Hill<\/p>\r\n<\/td>\r\n

\r\n

Palo Alto<\/span><\/p>\r\n<\/td>\r\n

\r\n

8000000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-201<\/p>\r\n<\/td>\r\n

\r\n

900<\/p>\r\n<\/td>\r\n

\r\n

9876543<\/p>\r\n<\/td>\r\n

\r\n

Brighton<\/p>\r\n<\/td>\r\n

\r\n

Brookly<\/p>\r\n<\/td>\r\n

\r\n

7100000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-215<\/p>\r\n<\/td>\r\n

\r\n

700<\/p>\r\n<\/td>\r\n

\r\n

1111111<\/p>\r\n<\/td>\r\n

\r\n

Manus<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

400000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-222<\/p>\r\n<\/td>\r\n

\r\n

700<\/p>\r\n<\/td>\r\n

\r\n

1111111<\/p>\r\n<\/td>\r\n

\r\n

Redwood<\/p>\r\n<\/td>\r\n

\r\n

Palo Alto<\/p>\r\n<\/td>\r\n

\r\n

2100000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-305<\/p>\r\n<\/td>\r\n

\r\n

350<\/p>\r\n<\/td>\r\n

\r\n

1234567<\/p>\r\n<\/td>\r\n

\r\n

Round Hill<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/span><\/p>\r\n<\/td>\r\n

\r\n

8000000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

Second Edition<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

\"image\"<\/p>\r\n

<\/p>\r\n<\/td>\r\n<\/tr>\r\n

<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

Figure 7.4 Example of an update anomaly. The bottom image is a reproduction of Figure 10.3 from the second edition (A. Watt).<\/p>\r\n

The issue here is that the Round Hill address has changed from Horseneck to Palo Alto. A-113 was updated, but A-305 data was not updated.<\/p>\r\n\r\n

Deletion Anomaly<\/h3>\r\n

A deletion anomaly<\/em> occurs when you are deleting data and the record contains data that might be important to retain. Figure 7.5 shows that A-101 is the last account at the Downtown branch. If we delete this record, then we lose access to the Downtown branch address and to the asset figure.<\/p>\r\n\r\n\r\n\r\n\r\n\r\n
\r\n

Third edition<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
\r\n

AccountNumber<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Balance<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Customer<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Branch<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Address<\/strong><\/p>\r\n<\/td>\r\n

\r\n

Assets<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-101<\/p>\r\n<\/td>\r\n

\r\n

500<\/p>\r\n<\/td>\r\n

\r\n

1313131<\/p>\r\n<\/td>\r\n

\r\n

Downtown<\/span><\/p>\r\n<\/td>\r\n

\r\n

Brooklyn<\/span><\/p>\r\n<\/td>\r\n

\r\n

9000000<\/span><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-102<\/p>\r\n<\/td>\r\n

\r\n

400<\/p>\r\n<\/td>\r\n

\r\n

1313131<\/p>\r\n<\/td>\r\n

\r\n

Perryridge<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

1700000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-113<\/p>\r\n<\/td>\r\n

\r\n

600<\/p>\r\n<\/td>\r\n

\r\n

9876543<\/p>\r\n<\/td>\r\n

\r\n

Round Hill<\/p>\r\n<\/td>\r\n

\r\n

Palo Alto<\/p>\r\n<\/td>\r\n

\r\n

8000000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-201<\/p>\r\n<\/td>\r\n

\r\n

900<\/p>\r\n<\/td>\r\n

\r\n

9876543<\/p>\r\n<\/td>\r\n

\r\n

Brighton<\/p>\r\n<\/td>\r\n

\r\n

Brookly<\/p>\r\n<\/td>\r\n

\r\n

7100000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-215<\/p>\r\n<\/td>\r\n

\r\n

700<\/p>\r\n<\/td>\r\n

\r\n

1111111<\/p>\r\n<\/td>\r\n

\r\n

Manus<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

400000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-222<\/p>\r\n<\/td>\r\n

\r\n

700<\/p>\r\n<\/td>\r\n

\r\n

1111111<\/p>\r\n<\/td>\r\n

\r\n

Redwood<\/p>\r\n<\/td>\r\n

\r\n

Palo Alto<\/p>\r\n<\/td>\r\n

\r\n

2100000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

A-305<\/p>\r\n<\/td>\r\n

\r\n

350<\/p>\r\n<\/td>\r\n

\r\n

1234567<\/p>\r\n<\/td>\r\n

\r\n

Round Hill<\/p>\r\n<\/td>\r\n

\r\n

Horseneck<\/p>\r\n<\/td>\r\n

\r\n

8000000<\/p>\r\n<\/td>\r\n<\/tr>\r\n

<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

<\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

Second Edition<\/strong><\/p>\r\n<\/td>\r\n<\/tr>\r\n

\r\n

\"image\"<\/p>\r\n

<\/p>\r\n<\/td>\r\n<\/tr>\r\n

<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n

Figure 7.5 Example of an update anomaly. The bottom image is a reproduction of Figure 10.4 from the second edition (A. Watt).<\/p>\r\n

Fortunately, Customer 1313131 has an account at the Perryridge branch. Otherwise, we would have lost access to the existence of Customer 1313131.<\/p>\r\n\r\n

Functional Dependency<\/h2>\r\n

How do we break this large table into smaller tables? We could break the large table into two tables such as:<\/p>\r\n\r\n