Normalization: Turning Instinct into Certainty

4.1 Why Normalization: Four Guidelines for a Good Relation

4.1.1 Why These Guidelines Exist at All

Data is the reason any application exists. An airline company needs data to know what its airplanes cost and to decide where to send its planes when a demographic, political, or geopolitical event changes demand. A supply chain company needs to store its data properly so the data makes sense when it is retrieved. An enterprise application, an Android app, a mobile app, or a web app — all of them exist to solve a user's problem, and solving that problem well needs data. So the question is never whether to store data; it is how to store it so that it can be retrieved efficiently, shared concurrently, and trusted.

We could try to program all of that ourselves in Python, Java, or any language we already know. That attempt would fail, or at least become a Herculean task, because a database carries a huge number of requirements, specifications, and constraints. Storing data properly and retrieving it efficiently by hand is exactly why a database management system exists, and why this course is built around one workflow: a client gives us requirements, we turn those requirements into an ER model that connects the client's words to our design, and then we convert the ER diagram into a relational schema, which we later query with SQL.

The recap ends with a confession that frames the entire session: ER modeling is a best-fit model — it runs on the designer's instinct. A relational schema, by contrast, should be judged by something more measurable, because the data sitting between the requirement and the final schema carries no mathematical certainty on its own. Two diagrams can both be "reasonable," and no one can say which is better without a yardstick. The whole point of today's discussion is to replace "this design feels right" with "this design is provably better."

To do that, we need parameters — criteria that tell us whether a given relation is good. Four guidelines capture what a good database relation must satisfy, and the rest of the course on normalization is just the machinery for satisfying them.

The repeated advice in this session: when you meet any rule, ask why. You can write "WHY" in your notebook and hold the class to it. Understand why a rule exists, and even if you forget how to apply it, you can look it up or re-derive it; if you only memorize the application, you cannot adapt it. Books have been wrong in the past, and they need to be updated for current situations — another reason understanding the "why" matters more than memorizing the "how."

4.1.2 Guideline 1: Clear Semantics

A database is a collection of data about a mini world — a slice of reality. The mini world can be an organization, a school, a railway reservation system, an airline reservation system, a university, a supply chain, a healthcare system, a bank, or whatever domain we are modeling. The relations inside that mini world should be self-explanatory: if I create an EMPLOYEE relation with attributes employee ID, employee name, employee phone number, employee email, and address, the semantics are clear. The name of the relation says employee; the attributes say what we store about an employee. There is minimal ambiguity, and anyone who sees the table can make sense of it.

Compare that with the inside of your own room. You know which cupboard holds your books, which holds your clothes, and which holds your utilities. But your knowledge is private: you would have to open every box and every wardrobe to find anything, unless each one carries a label. Clear semantics means putting labels on the boxes — designing tables whose names and attributes speak for themselves.

Why does a label matter? Two students worked through the answer in class. The first answer was about personal efficiency: if we know which box holds what, we go directly to it and save time. The discussion pushed back: that only helps the person who designed the room. The second answer was the bullseye: someone else will use it. In any organization, no single person designs, uses, or maintains the software. A database designer is one member of a team; the people using the application query the database; a separate team maintains it after launch; a product built for 20 years must be solid and valuable to people who never met its original designer. If the stored data does not speak for itself — if the semantics are not clear — the team cannot query it, cannot find bugs, and cannot improve it. Clear semantics is not aesthetics; it is the condition that lets hundreds of people work on one database over decades.

4.1.3 Guideline 2: Least Redundancy and Least Update Anomalies

The second guideline: redundancy should be as small as possible, and tuples should have as few update anomalies as possible. Here update is a broad word: update means insert, delete, and modification.

What is an anomaly? Before anyone looks up a dictionary definition, the discussion started from the felt sense of the word. Some students associate it with an outlier — the gifted player in sports, the single student who scores 100 when the class average is 50 (or the one who scores 0), or the outliers we deliberately exclude when training a machine learning model. That association is wrong, and getting it right matters.

One student's phrasing earned an approving echo: an anomaly is anything that does not follow some pattern. In the database world, the anomalies that matter are the inconsistencies that prevent us from inserting, from deleting, or from modifying data cleanly. There are three classic kinds:

• Insert anomaly — we cannot add a row because some required fact does not exist yet (a work assignment cannot be inserted before the project it references exists).
• Delete anomaly — removing a row silently destroys information that lived only in that row.
• Update anomaly — changing one fact forces us to hunt down and edit the same value in many places.

The root cause of most anomalies is redundancy, though not all of them: foreign key constraints also restrict insertion, deletion, and modification, as we know from the constraint discussion. Redundancy matters for two reasons. First, wasted space: storing the same thing twice consumes hard disk or storage. (Storage has become cheap, so today this alone would not justify the fuss — but when the relational model was formed, it mattered.) Second, and far more important, consistency: if the same fact is stored in two places and an update touches only one of them, we can no longer be certain which copy is the correct one, and we cannot take decisions on uncertain data.

Insert and delete anomalies follow the same logic through foreign keys. The project number inside the employee–project relation is a foreign key referring to the project number in the PROJECT table. Unless that project number already exists in PROJECT, it cannot be inserted into the employee–project relation — that restriction is an insert anomaly waiting to happen whenever we try to record a work assignment before the project itself exists. Now suppose a project is closed, completed, or abandoned and we want to delete it from PROJECT. The employee–project rows still point at a project number that no longer exists — a dangling reference, called a zombie in the discussion. Deleting the parent would orphan the children.

The same three options answer the practical question a student raised from personal experience: when updating, which table do we update first — the primary key side or the foreign key side?

4.1.4 Guideline 3: Least Null Values

The third guideline: the relation should contain as few null values as possible. A null is a missing value, and missing values are a symptom of a bad fit between the schema and the reality it models.

The phone-number discussion in the first normal form section (see 4.4.2) shows why: if we solve a multi-valued attribute by creating phone1, phone2, phone3 columns, most rows carry nulls. A student with one phone number fills only phone1; the other two cells sit empty. And nulls are not passive — they make queries and decisions awkward:

• A query counting phone numbers must remember to exclude nulls, or the count is wrong.
• A query joining on a column that is often null silently drops rows.
• A human reading the table cannot tell whether phone2 = NULL means "no second number" or "second number not yet recorded."

Least nulls is a design goal in its own right, not just a side effect of good design.

4.1.5 Guideline 4: Least Spurious Tuples

The fourth guideline: the design should create as few spurious tuples as possible. Spurious means extra or wrong — a student suggested "duplicate," which the discussion accepted as the everyday sense. Spurious tuples appear when we join two tables and the join produces rows that were not really there. Extra rows look harmless — more is more — but the problem is the reverse: when extra entries appear, we cannot take a decision on the result, because we do not know which rows are real and which are artifacts of the join.

Why do spurious tuples appear? A join that matches on a non-primary-key or non-candidate-key attribute can multiply rows, because the join key is not guaranteed unique on the "one" side.

A second, denser example of the same four guidelines: a schema holding employee department, employee name, social security number, birth date, address, department number, department manager SSN, and a project relation holding project SSN, P number, hours, E name, P name, and location. Here the department number and the department manager are redundant: if the department name changes from Research to R&D (or whatever new name we choose), the change must be propagated everywhere the name appears, and the employee name stored in the project relation repeats across every project row too. Four things, then, to minimize in a good design: semantic confusion, redundancy and update anomalies, nulls, and spurious tuples.

4.1.6 Worked Example: The Marketplace Sales Design

4.1.7 What the Guidelines Are For

Two threads close this section. First, redundancy alone is not the only enemy; the guidelines exist so the design can be justified with mathematical certainty rather than left to the guts, whims, and feelings of the designer. Second — and this is the link to the whole lecture — the four guidelines are exactly what normalization will provide, and functional dependencies are the tool that will let normalization provide them.

4.2 When the Guidelines Apply: NoSQL, Performance, and Change

4.2.1 Different Priorities for Different Eras

A student asked whether these four guidelines are relational-only — she had heard that NoSQL stores things as JSON files. The answer is a history lesson that explains why the rules exist at all.

When the relational model became famous, in the 1960s, 1970s, and early 1980s, the dominant concern was consistency: the database must give the correct answer, and the entire model was built around that. Around 2003–2005, a flood of new data arrived and social media applications appeared. Now the designer had to choose where to spend limited effort: consistency, isolation (availability), or partition tolerance. Which do we value more — consistency or availability? For a social media application the size of Facebook, an insistence on strict relational consistency means the application will not scale. Scaling needs places where entries are null, places where some redundancy is deliberately kept — the same fact stored at three different sites so that even if one site goes down, the others still serve it.

So the two eras have different priorities. Relational priorities fit enterprise-level applications that do not serve a billion users. NoSQL priorities are scalability and performance, and the JSON file format serves them: it gives freedom to store whatever is needed as the need arises; it puts a lot of related data in the same place, which is a performance advantage; it supports replication and sharding; and it can be stored very tightly to the hardware through proprietary file formats — MongoDB, for example, stores documents in BSON (binary JSON), a compact binary encoding of JSON that makes retrieval very fast. Yes — JSON entries sometimes violate relational ideals such as these four guidelines, but they do so because the priorities are different, not because the designers are careless.

4.2.2 Changing a Database That Is Already in Production

Another student asked the course-correction question: suppose a database was built early in the design phase without awareness of good practices like normalization, and only later, in production, do we realize improvements are needed. Can we take a course correction, and what does it do to data integrity?

The answer: yes, we can move from a lower normal form to a higher one (say, from first normal form to third normal form) — every action has a cost, and three things decide the price. First, how strong and how large the existing database and its instances are. Second, how quickly and how often new data arrives — the normalization practices exist for a purpose, and if large amounts of new data keep coming, there is a constraint to enforce. Third, the agenda: why do we want to change, is the current design actually causing problems, and is it stopping us from reaching the next level? On integrity: yes, you stop for some time, redistribute the entire data into the new tables that satisfy the higher normalization levels. The migration is a planned stop-and-redistribute operation, not a live hot-swap.

4.2.3 Principles Apply Even When the Tool Is Different

A student working without a relational database — keeping data manually in an Excel sheet or any tabular form — asked how these guidelines can apply to that. The answer was about principles versus applications. When we learn something, there are two things: the theorem and the application of the theorem. This course teaches the applications first and then asks whether the theorem makes sense. If you know the theorem, you can decide cautiously that a particular rule does not apply to your case and consciously use only one or two rules with different tools — NoSQL instead of ER models and relational schemas. If you do not know the theorem, some of your dates will work and some will not, and you will not know why. The rule is: know why you are doing what you are doing, then violate consciously.

4.2.4 Mixing SQL and NoSQL

A student reported that in one of her projects the team used a combination of Mongo and MariaDB — one NoSQL and one SQL — and asked how that works. First, what NoSQL really is. It is not "the opposite of SQL" as a resume keyword. NoSQL is a family of systems with major categories: key-value stores like Cassandra, document stores like MongoDB, graph databases like Neo4j, and others. Each category has a specific provision: some allow more consistency, some more availability, some more partition tolerance — each exists for its own reason. When storing data, the database must be homogeneous: either we store everything in relational tables or we store everything in the same non-relational format. Two different ways of storing the same thing make it very difficult for the systems to survive simultaneously and add value.

The practical answer for the Mongo-plus-MariaDB case: in application design today we have microservices, and different parts can be programmed in different languages and exposed through different APIs. It is quite likely that the two stores are exposed through separate APIs, each service talking to its own database. The student confirmed the pattern: they process heavy reports through the SQL store and then transfer the result into the NoSQL store to manipulate it. The closing comment: things happen in practice in ways textbooks would not agree with, and as an entrepreneur or decision-maker you take decisions for the application. In commercial applications we have seen rules purposefully violated for scaling: skip the proper requirements initially, make money quickly, then later take a cautious decision to stop, worry about security and other aspects, and migrate.

4.2.5 What Language Is Used to Talk to a Database?

A student from a non-programming background asked what kind of coding makes a database different from plain Java or C — why can we just query and get results without worrying about indexing and such? The answer: the language used to store and retrieve data is SQL. Application languages — Python, Java, and many others — support SQL integration in one way or another. The whole application may be written in Python, but wherever the application needs data, it uses SQL to query the stored sources and retrieve the data. SQL is the query language of this course and of the relational world.

4.2.6 Does Normalization Always Give Good Performance?

A student asked directly: does normalization always give good performance? The answer was an emphatic no — you have to give something to get something. Normalization means dividing tables, and if your workload is heavy on retrieval, the joins you must perform can cost more than the redundancy they remove. This is exactly why JSON files can be faster: everything needed is combined in the same place, which normalization forbids — normalization says split into different tables. If your client frequently asks for large amounts of data and you spend significant time joining tables, normalized design can leave you with worse performance. The follow-up question — when do we stop normalizing? — has no formula. It is your decision as a designer, and you can reverse it: today you normalize for cleaner and faster storage; in a month, if a few clients suffer, you can denormalize. The decision balances performance, efficiency, and the load and volume of the organization.

4.3 Functional Dependencies

4.3.1 Dependency and Function in the Real World

Functional dependencies are the tool that will deliver all four guidelines: clear semantics, least redundancy and update anomalies, least nulls, and least spurious tuples. They are in the textbook and they earn marks, but the real reason to learn them is that they power your career decisions later. To understand functional dependency, take the two words separately.

Dependency exists in the real world. In the insurance world, there is an earning member and other dependent members of the family. In an organization, one team's work depends on another team's code: if there are four verticals or four horizontal pieces, success or failure propagates along the dependencies between them. A functional dependency is the database version of exactly this idea.

Function, too, is an everyday idea. A function is a black box: you put an input in, and an output comes out.

4.3.2 The Formal Definition of a Functional Dependency

In the database world, a functional dependency (FD) says: if there is an attribute $X$ in a table and an attribute $Y$ in the same table, and $X$ functionally determines $Y$, written

$$X\to Y$$

then whenever $X$ repeats in the table, $Y$ also repeats. Here $X$ is called the left-hand side (the determinant) and $Y$ the right-hand side. One attribute can determine several attributes at once, as in $Pnumber\to Pname,Plocation$. The left-hand side can also be a group of attributes that repeats together — when the group repeats, the right-hand side repeats with it.

The definition is one-directional, and that direction is the heart of it. Suppose department number functionally determines department name:

$$Dnumber\to Dname$$

Whenever department number 5 appears, the department name is always Research. But the reverse is not certain: Research may repeat even though the department number is 7 — two departments can share a name. So $X\to Y$ does not imply $Y\to X$. It is a one-way dependency.

What does an FD tell us? It tells semantics: the attributes of a relation are not independent islands; they are related. If employee number repeats, employee name repeats; if employee email ID repeats, employee name repeats. These statements are the semantics of the mini world, made explicit. That is the purpose for the existence of functional dependencies — and how they actually reduce redundancy and update anomalies appears in the normalization section.

4.3.3 Reading Functional Dependencies from a Schema

When we look at an instance of a relation, we can check whether a candidate FD holds. In an example relation, we asked: is there an FD from $A$ to $B$, i.e., whenever $A$ repeats, does $B$ repeat? No. From $B$ to $A$? No. Any other FD in this relation? None visible. Whether an FD exists or not, we cannot always say with certainty from one instance — more on that in 4.3.5.

In a previous example we could decide: is there an FD from department number to department name? Yes — whenever the department number repeats, the name repeats too. From project number to project name? It looks that way. Note the trap: two project names can be equal — project 5 is Research and project 7 is also Research. That does not break $Pnumber\to Pname$ (a number always maps to one name); it only shows the reverse direction fails, because Research does not always map to one number. The FD $Dnumber\to Dname$ means "number 5 is always Research", not "Research is always 5".

4.3.4 Who Decides What the Functional Dependencies Are

A student building a school database — student ID, student name, father's name, mother's name — asked how we decide the functional dependencies there. The answer is the most practical statement of the section: functional dependencies are not decided by the relational schema, and they are not derived from the ER diagram. They exist — that is all. The person who knows them is the person who gave you the constraints: the user, the client, the person who gave the assignment to develop the database. Given only the final relational schema, nobody can say which FDs exist or do not exist; the designer knows them from the user's requirements.

How are they recorded? Functional dependencies form a separate set, written down separately. The relational schema shows candidate keys and the primary key (underlined), and foreign keys from an attribute of one relation to the primary key of another. Functional dependencies are not represented in the relational schema, and the ER diagram cannot produce them. The customer provides the inputs, and the database administrator writes the set down. That set then drives normalization, reduces redundancy, and ensures joins do not create extra or missing entries. FDs also have a second job: when we are given a relation without a primary key, the functional dependencies are used to identify the candidate keys and pick the primary key.

One student summarized an FD as a hard-and-fast business rule that may oblige us to create a composite primary key. The response accepted the direction — "you are correct" — while noting that the composite-primary-key mechanics come later: these things are controlled by the business, meaning user requirements and how the business grows. Constraints, limitations, and regulations from the user help us understand the relational schema better, make normalization better, and ultimately make application performance better.

4.3.5 What a Relation Instance Can and Cannot Prove

A student asked for an example of a subtle claim: we can definitely conclude that certain FDs do not exist — because two tuples in the instance violate them — but we can never conclude that an FD does exist.

On the other hand, for any FD that seems to hold in the instance — say from text to teacher — we can only say it may exist. In short: one counter-example refutes an FD forever; supporting examples never prove one. This is why the FD set comes from the client, not from inspecting instances.

4.3.6 Why Functional Dependencies Matter

Collect the thread: a good schema has clear semantics, least redundancy and update anomalies, least nulls, and least spurious tuples. To guarantee all four with mathematical certainty, we use functional dependencies: they encode the semantics of the mini world, they drive the decomposition that removes redundancy, and they keep joins clean. The rest of the session — first normal form, second normal form, third normal form, BCNF — is the step-by-step use of FDs to reach a good relation.

4.4 The Normalization Process: 1NF, 2NF, 3NF, BCNF

4.4.1 What Normalization Is

Normalization is the process that removes bad, unsatisfactory relations and converts them into good relations. We have seen what a good relation is — clear semantics, least update anomalies, least null entries, least spurious tuples. Anything that does not satisfy those is a bad relation, and normalization breaks bad relations into good ones.

The steps in order:

1. 1NF — one value per cell.
2. 2NF — every non-key fact must depend on the whole key, not just part of it.
3. 3NF — every non-key fact must depend on a key directly, not through another fact.
4. BCNF — even stricter than 3NF; covered in later sessions.

Each step starts from the relation produced by the previous step, and each step uses the functional dependencies given by the client as the ground truth.

4.4.2 First Normal Form (1NF)

First normal form (1NF) says: every record, and every cell in every record, holds a single distinct entry. One value per cell. That sounds trivial, but it is not, and the lecture spent real time on why it exists.

Take a relation storing student name, student ID number, and student phone number. A normal person can have two phone numbers — one mobile and one office — and some people have three: office, home, and a personal contact. Today you might have two; 15 or 20 years ago you had one; within the next 5 to 10 years you might have three or four. Any design that hard-codes a maximum ("no more than three") is planning to fail over a 10-to-20-year application lifetime.

A student summarized it: 1NF solves the problem of storing only a single value of an attribute in a column, not multiple values. The summary was confirmed and extended with the reasons: cleaner design, efficiency, and clear semantics — the unclear semantics of multi-value cells are precisely what produces bad performance.

4.4.3 Second Normal Form (2NF)

Second normal form (2NF) demands full functional dependency: for every functional dependency $\alpha \to \beta$, the left-hand side $\alpha$ must be a complete candidate key — not just part of one.

To parse that, recall the key terminology from the earlier session. A super key is a set of attributes that uniquely identifies every record. A minimal such set is a key. When there is more than one minimal set, each one is a candidate key. One candidate key is chosen as the primary key. An attribute that belongs to some candidate key is a prime attribute; an attribute that belongs to no candidate key is a non-prime attribute.

4.4.4 Worked Example: Splitting the Employee–Project Relation

4.4.5 Third Normal Form (3NF)

Third normal form (3NF) forbids transitive dependencies: no non-prime attribute may determine a non-prime attribute. Formally, for every functional dependency $\alpha \to \beta$, at least one of these must hold: $\alpha$ is a candidate key or a super key, or $\beta$ is a prime attribute. The violation case is: $\alpha$ is not a candidate/super key AND $\beta$ is not a prime attribute.

Because 3NF is built on top of 2NF, it already inherits the ban on partial dependencies; 3NF adds the ban on non-prime-to-non-prime dependencies. BCNF, mentioned as even stricter, comes after 3NF and will be revisited in later sessions.

4.4.6 Worked Example: Splitting the Employee–Department Relation

4.4.7 Class Exercise: Prime Attributes and 3NF Violations

The class worked a property-schema exercise designed to trap people who memorize the rule without the terminology.

The relation has attributes property ID, country name, lot number, tax rate, area, and price. Property ID is a prime attribute and functionally determines everything — it is a candidate key. There is a second candidate key: country name together with lot number. So there are two candidate keys:

• property ID
• (country name, lot number)

All three of these attributes are prime attributes (each belongs to some candidate key). Here is the trap: when either side of a dependency involves prime attributes, the dependency may still violate nothing. Any dependency whose right-hand side is a prime attribute can never violate 2NF or 3NF, because the 3NF rule is satisfied as soon as $\beta$ is prime.

Question 1: does the FD $taxrate\to countryname$ violate 3NF? The class split. One student answered that it violates, because a non-prime attribute is identifying a non-prime attribute. But that reasoning was wrong for this FD: tax rate is indeed non-prime (it belongs to no candidate key), but country name is prime (it is part of the second candidate key). The right-hand side is prime, so the dependency satisfies 3NF: $taxrate\to countryname$ does not violate third normal form.

Question 2: does the FD $area\to price$ violate 3NF? This time, yes. Area is on the left and is not a complete candidate key (it is not a candidate key at all), and price is not a prime attribute. Left side not a candidate/super key, right side not prime — violation. The fix follows the rule: create a separate relation $(area,price)$, and keep all attributes except price in the original relation.

4.4.8 The Order and the Goal

Normalization proceeds in order: satisfy 1NF, then 2NF, then 3NF. First normal form removes multi-valued cells. Second normal form removes partial dependencies — attributes that depend on part of a candidate key. Third normal form removes transitive dependencies — non-prime attributes that depend on other non-prime attributes. Beyond 3NF sits BCNF, which is stricter, and will appear in later sessions.

One closing caution from the session: a summary line stated the 3NF condition backwards (suggesting that a candidate-key left side or a prime right side violates 3NF). That was a slip of the tongue. The correct statement, given throughout the main discussion, is: a dependency $\alpha \to \beta$ violates 3NF only when $\alpha$ is not a candidate/super key and $\beta$ is not a prime attribute. If either condition fails to hold — $\alpha$ is a key, or $\beta$ is prime — the dependency satisfies 3NF.

The goal of the whole exercise, restated once more: a good relation has proper semantics, least null entries, least update anomalies and least redundancy, and no spurious tuples. Functional dependencies give us the mathematical certainty to know we have achieved it — instead of relying on the guts, whims, and feelings of the database designer. That is why normalization exists, and why first normal form, functional dependencies, and their inference rules deserve the attention they get.

Key Industry Applications

Normalization and functional dependencies are not textbook exercises; they are daily decisions in the systems described in this lecture.

• Airline industry: airlines need data about aircraft costs and about demographic, political, and geopolitical events to decide where to redirect planes — a motivating story for why stored, retrievable data matters. Airline reservation systems are also cited as a mini world in their own right: hundreds of agents, concurrent bookings, and one trusted record of every seat.
• Supply chain companies: must store data properly and ensure it makes sense when retrieved. A part number that maps to two names in two tables is not a style problem — it stops a shipment from being assembled. This is exactly the consistency argument behind least redundancy.
• Amazon-style marketplaces: the sales-design exercise (ternary relationship vs. separate sales entity with binary relationships) is a live e-commerce schema decision. In production, the sale usually becomes an entity with its own attributes (quantity, price, status), and the binary links to buyer, seller, and product — Option B from the lecture.
• Social media at scale — Facebook: the history lesson on why NoSQL exists — strict relational consistency does not scale to a billion users, so nulls and deliberate three-way redundancy are accepted for availability. The same fact stored at three sites means one site can fail and the others still answer.
• NoSQL families in production: Cassandra (key-value), MongoDB (document/JSON, stored in the compact BSON binary format), and Neo4j (graph) — each with its own consistency, availability, and partition-tolerance trade-offs, and each deliberately relaxing relational ideals for scale.
• SQL-plus-NoSQL hybrid stacks: the Mongo plus MariaDB combination seen in industry, typically two microservices exposed through different APIs — the SQL store handles heavy reporting, the NoSQL store handles manipulation of the results.
• Microservices and APIs: modern applications split parts into services, sometimes in different languages, each exposing its database through an API — the real-world pattern behind mixed stores, and the reason "which database" is a service-level decision, not a whole-company one.
• Deliberate denormalization: commercial applications purposefully violate normalization rules to scale quickly, then stop and migrate later — normalization versus performance is an active engineering decision (joins cost time; JSON keeps related data together for fast retrieval). The lecture's answer stands: normalize for updates, denormalize for read-heavy workloads, and decide with the theory in hand.
• National ID systems: the SSN discussion uses the Aadhaar number as the everyday equivalent of a social security number — a concrete anchor for key attributes, and a reminder that a single national identifier is a candidate key in hundreds of unrelated schemas.
• Manual data tools: Excel-style manual tabular storage still exists; the principles (not the tools) are what transfer, and knowing the theorem lets you decide when it applies. A spreadsheet with repeated customer names has the same update anomaly as a badly designed table — the fix is the same reasoning, on a smaller stage.
• Query languages in industry: SQL is the standard way applications written in Python, Java, and other languages store and retrieve data — the query language of this course and of the relational world.