Data Modeling & Storage
Data-modeling knowledge for an analyst — model levels, relational vs NoSQL, keys and constraints, indexes, normalization, transactions, ACID, and isolation anomalies.
14 questions
JuniorTheoryVery commonWhat is a relational database, and what are a primary key and a foreign key?
What is a relational database, and what are a primary key and a foreign key?
A relational database stores data as tables of columns and rows with defined relationships. A primary key is the minimal unique attribute that identifies a row; a foreign key references another table's primary key, enforcing referential integrity.
Common mistakes
- ✗Allowing the primary key to repeat across rows
- ✗Confusing a foreign key with a primary key or a backup
- ✗Forgetting foreign keys enforce referential integrity
Follow-up questions
- →What is a composite primary key?
- →Why is referential integrity needed?
MiddleTheoryVery commonWhat is ACID and what does each property guarantee?
What is ACID and what does each property guarantee?
ACID names four transaction guarantees: atomicity applies all statements or none, consistency moves the base between valid states, isolation stops concurrent transactions interfering, and durability keeps committed changes after a crash.
Common mistakes
- ✗Misattributing a property (e.g. durability for atomicity)
- ✗Confusing consistency with isolation
- ✗Treating ACID as performance features rather than guarantees
Follow-up questions
- →Which property is violated by a dirty read?
- →How does isolation relate to isolation levels?
MiddleTheoryVery commonHow do SQL (relational) databases differ from NoSQL, and when should you choose each?
How do SQL (relational) databases differ from NoSQL, and when should you choose each?
SQL databases use a fixed schema and a standard query language, giving strong consistency, integrity and rich joins. NoSQL uses flexible models for unstructured data and scales horizontally. Pick SQL for relations and transactions, NoSQL for scale.
Common mistakes
- ✗Swapping which model has the fixed vs dynamic schema
- ✗Claiming NoSQL is strictly better for transactions and joins
- ✗Choosing a model without considering data volume or access pattern
Follow-up questions
- →Which type of NoSQL suits a cache?
- →Why are joins harder in NoSQL?
JuniorTheoryCommonWhat is a database index and why is it needed?
What is a database index and why is it needed?
An index is a database object that speeds up search by keeping an ordered structure over one or more columns, so the engine locates rows without scanning the whole table. It trades storage and slower writes for much faster reads.
Common mistakes
- ✗Believing an index speeds up writes rather than reads
- ✗Confusing an index with the primary key
- ✗Forgetting the storage and write-cost trade-off
Follow-up questions
- →Why does an index speed up reads but slow down writes?
- →On which column is an index most useful?
JuniorTheoryCommonWhat is a normal form and why is normalization needed?
What is a normal form and why is normalization needed?
A normal form is a property of a relation describing its redundancy and structure. Normalization removes duplication and the insert, update and delete anomalies it causes by splitting tables. Denormalization adds redundancy back for reads.
Common mistakes
- ✗Calling a normal form a file format or storage layout
- ✗Thinking normalization merges tables instead of splitting them
- ✗Not knowing normalization removes update/insert/delete anomalies
Follow-up questions
- →What does first normal form require?
- →When do you deliberately resort to denormalization?
MiddleTheoryCommonWhat constraints exist in a relational DB and how do you enforce uniqueness across several fields?
What constraints exist in a relational DB and how do you enforce uniqueness across several fields?
Constraints enforce integrity at schema level: PRIMARY KEY identifies a row, FOREIGN KEY holds referential integrity, UNIQUE bars duplicates, NOT NULL requires a value, CHECK tests a condition. Multi-column uniqueness needs a composite UNIQUE index.
Common mistakes
- ✗Naming only PRIMARY KEY and omitting CHECK or NOT NULL
- ✗Thinking constraints belong to the application, not the schema
- ✗Not knowing composite uniqueness uses a multi-column UNIQUE/index
Follow-up questions
- →How does UNIQUE differ from PRIMARY KEY?
- →Which constraint checks a value's range?
SeniorTheoryCommonIn what ways is a relational DB scaled and what is the difference between them?
In what ways is a relational DB scaled and what is the difference between them?
Vertical scaling adds CPU and RAM to one server — simple but bounded. Replication copies data to replicas (synchronous is consistent but slower, asynchronous faster but lagging) and scales reads. Sharding splits rows by shard key, scaling writes.
Common mistakes
- ✗Confusing vertical scaling (bigger server) with sharding (split rows)
- ✗Claiming async replication has no lag or sync has no cost
- ✗Forgetting sharding complicates cross-shard joins and transactions
Follow-up questions
- →How does synchronous replication differ from asynchronous in its guarantees?
- →How does the choice of shard key affect load distribution?
SeniorTheoryCommonWhich NoSQL database families do you know, and which tasks is each suited for?
Which NoSQL database families do you know, and which tasks is each suited for?
Four NoSQL families: key-value gives fast lookups for caches and sessions; document stores JSON-like nested entities; column-family suits huge analytical writes; graph stores nodes and edges for connected data. Pick by the dominant access pattern.
Common mistakes
- ✗Naming only key-value and missing document/column/graph
- ✗Mismatching a family to its workload (e.g. key-value for graph traversal)
- ✗Choosing a family by popularity rather than access pattern
Follow-up questions
- →Which family would you choose for a social graph and why?
- →Why is a document database more convenient than a relational one for nested entities?
JuniorTheoryOccasionalWhat is a transaction in a relational database, and is every operation a transaction?
What is a transaction in a relational database, and is every operation a transaction?
A transaction is one or more SQL statements as a single logical unit — an atomic action either committed in full or rolled back. It ends with COMMIT or ROLLBACK. A single statement runs in an implicit transaction, so every operation is transactional.
Common mistakes
- ✗Believing a transaction can be committed partially
- ✗Forgetting COMMIT and ROLLBACK as the two endings
- ✗Thinking only multi-statement blocks are transactions
Follow-up questions
- →What happens if a failure occurs before COMMIT?
- →How does COMMIT differ from ROLLBACK?
MiddleTheoryOccasionalWhat does an index make worse, what is a unique index, and on which field (id/gender) is an index useless?
What does an index make worse, what is a unique index, and on which field (id/gender) is an index useless?
An index slows INSERT/UPDATE/DELETE because it must be maintained, and costs storage. A unique index also forbids duplicate key values. An index on gender is nearly useless — two values means low selectivity; id is far more selective.
Common mistakes
- ✗Indexing a low-cardinality column like gender expecting a speedup
- ✗Forgetting indexes slow writes and cost storage
- ✗Confusing a unique index with an ordinary one
Follow-up questions
- →What is index selectivity?
- →How does a unique index enforce uniqueness across several fields?
MiddleTheoryOccasionalWhat is table partitioning, and where and why is it used?
What is table partitioning, and where and why is it used?
Partitioning splits one large logical table into smaller physical sections by a key such as a date range, while queries still see a single table. Only relevant partitions are scanned, and a whole partition can be dropped for maintenance.
Common mistakes
- ✗Confusing partitioning with indexing
- ✗Thinking queries must scan all partitions regardless of the key
- ✗Applying it to small tables with no natural partition key
Follow-up questions
- →How does partitioning differ from sharding?
- →By which key is a large log table usually partitioned?
MiddleTheoryOccasionalWhich anomalies arise with concurrent transactions, and how do you protect against them?
Which anomalies arise with concurrent transactions, and how do you protect against them?
Concurrency anomalies: lost update (transactions overwrite each other), dirty read (reading uncommitted data), non-repeatable read (different values on re-read) and phantom (more or fewer rows on re-run). Isolation via locking or MVCC prevents them.
Common mistakes
- ✗Confusing non-repeatable read (changed row) with phantom (changed row count)
- ✗Calling dirty read the reading of committed data
- ✗Forgetting isolation levels (locking/MVCC) are the defense
Follow-up questions
- →How does a non-repeatable read differ from a phantom?
- →Which isolation level eliminates dirty reads?
SeniorTheoryOccasionalHow do you tell a table needs an index, what are the guidelines for creating one, and what is the typical index structure?
How do you tell a table needs an index, what are the guidelines for creating one, and what is the typical index structure?
Index a column driving frequent searches or joins on a large read-heavy table; confirm from query plans. Index foreign keys and JOIN/WHERE columns, prefer composite indexes, and limit indexes on write-heavy tables. The usual structure is a B-tree.
Common mistakes
- ✗Over-indexing write-heavy tables, ignoring the write cost
- ✗Ignoring column order in a composite index
- ✗Deciding on indexes without reading query plans
Follow-up questions
- →Why does column order in a composite index matter?
- →When is a hash index preferable to a B-tree?
MiddleTheoryRareHow do the conceptual, logical, and physical levels of a data model differ?
How do the conceptual, logical, and physical levels of a data model differ?
A conceptual model names business entities and their relationships, free of technology. A logical model adds attributes, keys and relationship types but stays DBMS-independent. A physical model maps it to a concrete DBMS — tables, types, indexes.
Common mistakes
- ✗Putting DBMS-specific data types into the conceptual or logical model
- ✗Confusing the order — building physical before conceptual
- ✗Thinking relationship/key types belong to only one level
Follow-up questions
- →At which level does the many-to-many relationship type appear?
- →How do modeling levels differ from data-presentation levels?