This is page 10 from the IRS Form 990 which lists 24 different expense types. What happens if I need to add another expense type? Well, I need to change the schema and provide nulls historically. If we add each expense field as a new column, the table becomes very wide and processing that wide table isn't scalable. The trade off between relationalism and flat structure is called normalization. This process of breaking out fields into another lookup table increasing the relations between the tables is called normalization. Normalization represents relations between tables. Denormalized data represents information in a flat format. Repeated fields tables related data to be handled in a loop making it more efficient to process. The trade off is performance versus efficiency. Normalized is more efficient denormalized is more performant. The original data is organized visually but if you had to write an algorithm to process the data, how might you approach it? Could be by rows, by columns, by rows and fields, and the different approaches would perform differently based on the query. Also, your method might not be parallelizable. The original data can be interpreted and stored in many ways in a database. Normalizing the data means turning it into a relational system. This stores the data efficiently and makes query processing a clear and direct task. Normalizing increases the orderliness of the data. Denormalizing is the strategy of accepting repeated fields in the data to gain processing performance. Data must first be normalized before it can be denormalized. Denormalization is another increase in the orderliness of the data because of the repeated fields in the example the name field is repeated. The denormalized form takes more storage. However, because it's no longer relational, queries can be processed more efficiently and in parallel using columnar processing. Your exam tip, no one understand normalization and denormalization and when to apply each to your data representation and design. BigQuery can use nested schemas for highly scalable queries. In the example shown, the company field has multiple nested transactions.