Week 2 Topic 2: Convert an ERD to tables

In the context of converting ERDs to tables, what does an entity typically become?

Which notation correctly represents a table definition?

In table definitions, what does the underline signify?

Which of the following is the best practice when naming tables based on entities?

What is the primary purpose of a foreign key in relational database tables?

In a one-to-many relationship, where does the foreign key typically reside?

In the context of database design, what is a junction table used for?

Which of the following accurately describes a composite primary key?

In the ORDERPRODUCT table, which fields typically function as both primary and foreign keys?

Why might a one-to-one relationship be used in database design?

Which characteristic is unique to foreign keys, compared to primary keys?

Consider a scenario where an attribute should be both a primary key and reference another table. How is this implemented in a junction table?

In a database for a library, books can have multiple authors, and authors can write multiple books. How would you represent this relationship when converting the ERD to tables?

When converting an ERD to tables and implementing a one-to-one relationship for 'access control' on sensitive data, what is the primary design consideration?

What design considerations should be accounted for when a junction table includes additional columns beyond the foreign keys?

Given two entities, A and B, in a one-to-one relationship where A contains critical identification data, and B contains optional supplementary data. If frequent queries only require A's data, how should this relationship be optimized for performance?

In the context of converting ERDs to relational database schemas, how does the choice between using a junction table versus embedding a multi-valued attribute impact query complexity and data integrity?

Consider implementing a 'soft delete' strategy (marking records as deleted instead of physical deletion) in a database converted from an ERD. How does this impact the design of primary and foreign key relationships, especially within junction tables?

Given a scenario where a database is being designed to track complex supply chain relationships, involving multiple entities with varying cardinalities and optional attributes. Which strategy best balances the need for query performance, data integrity, and flexibility in accommodating future changes?

You are tasked with designing a database for a social networking platform where users can follow each other. Considering the potential for billions of users and complex relationship queries, which relational database design strategy would be most scalable and efficient for managing the 'follows' relationship?