A junior data engineer is migrating a workload from a relational database system to the Databricks Lakehouse. The source system uses a star schema, leveraging foreign key constraints and multi-table inserts to validate records on write.
Which consideration will impact the decisions made by the engineer while migrating this workload?
One major consideration while migrating a workload to Databricks Lakehouse is that all Delta Lake transactions are ACID compliant against a single table only, and Databricks does not enforce foreign key constraints. This means that the engineer will need to manage referential integrity manually, as the system will not automatically enforce these constraints.
In Databricks Delta Lake, transactions are ACID compliant at the table level, meaning that transactions apply to a single table. However, Delta Lake does not enforce foreign key constraints across tables. Therefore, the data engineer needs to be aware that Databricks does not automatically enforce referential integrity between tables through foreign key constraints, and it becomes the responsibility of the data engineer to manage these relationships appropriately.
Primary and foreign keys are informational only and are not enforced.
D makes more sense. Since there are no database-level transactions, locks, or guarantees, and since primary key & foreign key constraints are informational only, there is no guarantee of enforced relations (the start schema) in place will remain in place after migration. This means B cannot be right.