If a view lacks both sql_table_name and derived_table parameters, what does Looker assume?

If a view lacks both sql_table_name and derived_table parameters, what does Looker assume?

• A. The view is based on a database table matching the view name
• B. The view must be configured manually
• C. The view is invalid and requires correction
• D. The view cannot be referenced in queries

Answer: (A)

When a view in Looker lacks both the `sql_table_name` and `derived_table` parameters, Looker operates under the assumption that the view corresponds to a database table that shares the same name as the view itself. This automatic linkage simplifies the view creation process, as it reduces the need for explicit definitions when the conventions are followed. This means that if a view is named `orders`, Looker will look for a database table called `orders` in the connected database. If it finds a match, it will allow you to use this view in your explorations and queries without additional configuration. The other options present scenarios that are not consistent with how Looker normally processes views. For instance, the idea that the view must be configured manually contradicts Looker's automation in handling standard naming conventions. Additionally, stating that the view is invalid would be misleading since Looker assumes a valid database table can be found, and referencing it in queries is entirely plausible as long as the matching table exists.

When a view in Looker lacks both the sql_table_name and derived_table parameters, Looker operates under the assumption that the view corresponds to a database table that shares the same name as the view itself. This automatic linkage simplifies the view creation process, as it reduces the need for explicit definitions when the conventions are followed.

This means that if a view is named orders, Looker will look for a database table called orders in the connected database. If it finds a match, it will allow you to use this view in your explorations and queries without additional configuration.

The other options present scenarios that are not consistent with how Looker normally processes views. For instance, the idea that the view must be configured manually contradicts Looker's automation in handling standard naming conventions. Additionally, stating that the view is invalid would be misleading since Looker assumes a valid database table can be found, and referencing it in queries is entirely plausible as long as the matching table exists.