🌍 Backend Development · flashcards

Backend Development Databases and Data Modeling Flashcards

51 question-and-answer cards covering Databases and Data Modeling as it is examined in Backend Development. 24 of them are printed below, taken from across the deck — no signup, no paywall on the preview.

51Cards in deck
24Free preview
31Syllabus topics
~259Chars per answer
FreePrice

24 sample cards from the Databases and Data Modeling deck

Sampled from the end of the deck, so these are different cards from the ones shown on the syllabus page.

  1. What is a database trigger?

    A trigger is a stored procedure that automatically executes in response to a table event—BEFORE or AFTER an INSERT, UPDATE, or DELETE. Triggers are used to enforce complex rules, maintain audit logs, or keep derived data consistent.

  2. In Entity-Relationship modeling, define entity, attribute, and relationship.

    An entity is a real-world object or concept about which data is stored (becomes a table). An attribute is a property of an entity (becomes a column). A relationship is an association between entities (e.g., 'a customer places an order'), often implemented via foreign keys.

  3. What are the three cardinality types of relationships in ER modeling?

    One-to-one (1:1), one-to-many (1:N), and many-to-many (M:N). A 1:N is implemented with a foreign key on the 'many' side; an M:N requires a junction/associative table holding foreign keys to both entities.

  4. What is a weak entity in ER modeling?

    A weak entity cannot be uniquely identified by its own attributes alone and depends on a related 'strong' (owner) entity. Its full key is a partial key combined with the owner's key, and it is connected by an identifying relationship.

  5. Define First Normal Form (1NF).

    A relation is in 1NF if every attribute holds only atomic (indivisible) single values, there are no repeating groups or arrays within a column, and each row is unique. Essentially, no multivalued or composite cells.

  6. Define Second Normal Form (2NF).

    A relation is in 2NF if it is in 1NF and every non-key attribute is fully functionally dependent on the whole primary key—there are no partial dependencies on part of a composite key. It becomes relevant only when the primary key is composite.

  7. Define Third Normal Form (3NF).

    A relation is in 3NF if it is in 2NF and has no transitive dependencies—no non-key attribute depends on another non-key attribute. Every non-key attribute must depend only on the primary key, informally 'the key, the whole key, and nothing but the key.'

  8. What is Boyce-Codd Normal Form (BCNF) and how does it strengthen 3NF?

    BCNF requires that for every non-trivial functional dependency $X \to Y$, $X$ must be a superkey. It is stricter than 3NF because it removes anomalies that remain when a non-key attribute determines part of a candidate key.

  9. What is a functional dependency, written $X \to Y$?

    A functional dependency $X \to Y$ means that each value of attribute set $X$ uniquely determines the value of attribute set $Y$; whenever two tuples agree on $X$ they must agree on $Y$. Functional dependencies are the basis for normalization.

  10. What update anomalies does normalization aim to eliminate?

    Insertion anomalies (cannot add data without unrelated data), update anomalies (redundant data must be changed in many places, risking inconsistency), and deletion anomalies (removing a row unintentionally loses other needed facts).

  11. What is denormalization and what are its main tradeoffs?

    Denormalization deliberately introduces redundancy (e.g., duplicated columns, precomputed aggregates) to reduce expensive joins and speed reads. The tradeoff is faster reads versus slower/complex writes, extra storage, and the risk of data inconsistency that must be managed.

  12. When is denormalization typically justified over a fully normalized schema?

    When read performance is critical and reads vastly outnumber writes, when joins are expensive at scale, or in analytical/reporting (OLAP) systems and caches. Normalized schemas are preferred for write-heavy transactional (OLTP) systems needing integrity.

  13. What is a schema migration and why is it version-controlled?

    A schema migration is a controlled, incremental change to the database structure (adding tables/columns, altering types, adding indexes). It is version-controlled so changes are reproducible, ordered, reviewable, and applied consistently across environments alongside application code.

  14. What is the difference between an 'up' migration and a 'down' (rollback) migration?

    An 'up' migration applies a schema change to move the database forward to a new version. A 'down' migration reverses that change to roll back to the previous version. Paired scripts allow safe forward and backward transitions.

  15. Describe the expand-and-contract (parallel change) pattern for zero-downtime migrations.

    Expand: add the new schema element (e.g., new column) without removing the old. Then deploy code that writes to both and backfill data. Contract: once all code uses the new element, remove the old one. This avoids breaking running application versions.

  16. What is a document store, and how does MongoDB represent data?

    A document store is a NoSQL database that stores semi-structured, self-contained documents. MongoDB stores documents as BSON (binary JSON) with flexible schemas, grouped into collections; related data can be nested (embedded) rather than split across joined tables.

  17. In MongoDB, contrast embedding documents versus referencing them.

    Embedding nests related data inside a single document for fast atomic reads of a whole entity (good for one-to-few, tightly coupled data). Referencing stores an ObjectId pointer to another document and requires a lookup/join, preferred for large, shared, or independently growing data.

  18. What is Redis and what core data structures does it provide?

    Redis is an in-memory key-value store known for very low latency. Beyond simple strings, it supports rich value types: lists, sets, sorted sets (with scores), hashes, bitmaps, HyperLogLogs, and streams, making it useful for caching, queues, leaderboards, and counters.

  19. Name common use cases where Redis is chosen as a key-value store.

    Caching (with TTL expiry), session storage, rate limiting, real-time leaderboards (sorted sets), pub/sub messaging, distributed locks, and job queues. Its in-memory design gives speed but limits total data to available RAM (with optional persistence).

  20. What kind of database is Cassandra, and what is its data model built around?

    Cassandra is a wide-column (column-family) NoSQL store designed for massive write throughput and horizontal scale. Its data model is query-driven: tables are organized around a partition key (which determines data distribution) plus clustering columns that order rows within a partition.

  21. How does Cassandra achieve high availability and scalability architecturally?

    Cassandra uses a masterless (peer-to-peer) ring architecture with consistent hashing to partition data across nodes, tunable replication factor, and tunable consistency levels (e.g., ONE, QUORUM, ALL). There is no single point of failure, favoring availability and partition tolerance.

  22. What is a graph database like Neo4j optimized for, and what are its core elements?

    A graph database is optimized for highly connected data and relationship traversal. Neo4j stores nodes (entities) and edges/relationships (typed, directed connections), both carrying properties. It excels at queries like shortest path, recommendations, and social/network analysis using the Cypher query language.

  23. According to the CAP theorem, what tradeoff must a distributed database make during a network partition?

    CAP states a distributed system can guarantee at most two of Consistency, Availability, and Partition tolerance. Since partitions are unavoidable, during one the system must choose between Consistency (reject/stale-free) and Availability (respond, possibly with stale data)—i.e., CP versus AP.

  24. List key criteria for choosing SQL (relational) versus NoSQL databases.

    Choose SQL for structured data, complex queries/joins, strong ACID transactions, and stable schemas (e.g., PostgreSQL, MySQL). Choose NoSQL for flexible/evolving schemas, very large scale, high write throughput, or specialized access patterns—document, key-value, wide-column, or graph—often trading strict consistency for scalability.

What this deck covers

The Databases and Data Modeling deck follows the Backend Development Databases and Data Modeling syllabus — 7 chapters and 31 topics — so questions land on material that is genuinely examinable rather than trivia around it. That works out to roughly 7.3 cards per chapter.

Answers are written to be recallable, not just readable — averaging about 259 characters, which is long enough to carry the reasoning and short enough to say out loud.

A deck like this earns its keep on the second and third pass. Read the syllabus first so you know the shape of the subject, then use the cards to find the specific facts that have not stuck.

Databases and Data Modeling flashcards FAQ

How many Databases and Data Modeling flashcards are in this Backend Development deck?

51 cards. This page previews 24 of them, sampled evenly across the deck so you can judge the difficulty before installing anything.

Are these Backend Development flashcards free?

Yes. The preview here is free to read with no signup, and the full 51-card deck is free inside the Examius app.

What do the Databases and Data Modeling cards cover?

They follow the Backend Development Databases and Data Modeling syllabus — 7 chapters and 31 topics — so the questions track what is actually examinable.

How should I use these flashcards?

Read the syllabus first so you know the shape of the subject, then drill the deck. Examius schedules each card with spaced repetition, so cards you keep missing come back sooner and ones you know drift further apart.