Architecture & Data Independence (3-schema view)

The college IT team moves the database from an old hard disk to a new SSD, and reorganizes how rows are physically laid out in the files. Nothing about the data changes — same students, same grades.

Should the results portal break the next morning?

Why & what

Obviously not. But something has to actively guarantee that, because the portal's query and the bytes on disk are two very different things. If your app talks directly to disk layout, then every storage tweak becomes an app rewrite.

The three-schema architecture separates a database into three levels — external (what each user sees), conceptual (the logical table design), and internal (how it's physically stored) — so that a change at one level doesn't force changes at the level above. That protection is called data independence.

Two flavours, and the interview always wants both:

• Physical data independence — change the internal level (storage, file layout, indexes) without touching the conceptual design.
• Logical data independence — change the conceptual level (add a column, split a table) without breaking the external views apps use.

How it works

Now that you know Aisha's data lives in linked tables, let's follow one query down through the levels: "Show Aisha's grade in DBMS 101."

1. External level. The portal doesn't see the whole database — it sees a narrow view: roll_no, course, grade. Aisha's fee details aren't in it at all.
2. Conceptual level. The DBMS translates that view into the real logical design: Student joined to Enrollment, plus the constraints you met in 1.2.
3. Internal level. The DBMS figures out where those rows physically sit — which file, which block, using which index — and fetches them.
4. Now swap the disk. The internal level changes completely. The conceptual tables are untouched, so the query still works. That's physical data independence.
5. Now add a phone column to Student. The conceptual level changed, but the portal's view still asks for the same three fields, so the portal doesn't break. That's logical data independence.

Notice where each label sits: the type of independence is named after the level being changed below the boundary.

Common confusion

Learners flip logical and physical independence constantly. Anchor it to what changed, not to what broke:

• Storage changed (disk, file layout, an index added) → physical independence protected you.
• Table design changed (new column, table split) → logical independence protected you.

One more useful fact for interviews: logical data independence is harder to achieve than physical, because apps genuinely depend on the logical structure, while they never needed to know about disk blocks in the first place.

Interview angle

1. "What is data independence and why does it matter?" — Define it as the ability to change one level without changing the level above, then give one example each for logical and physical. Two examples beat any amount of definition.
2. "Which is harder to achieve, logical or physical data independence?" — Logical, because external views and applications are written against the logical structure, so changing it risks breaking them.
3. "Which schema level does a normal user actually interact with?" — The external level; they never see the conceptual design or the physical storage, which is exactly the point of the split.

Recap

Three levels (external → conceptual → internal) exist so changes stay local — physical independence hides storage changes from the table design, logical independence hides table-design changes from apps.