A schema is a formal description of data fields, types, and structural organization. In a relational database, tables contain named columns with defined data types, while schemas organize those tables within a database. A useful schema makes data addressable, joinable, and analyzable without forcing every query to rediscover its structure. section 3.2.2
Schema design is a practical trade-off rather than a one-time specification. A normalized energy dataset separates systems, readings, and prices; keys may be externally generated, sequence-based, or composed from meaningful fields. When requirements change, ALTER TABLE can add, drop, or rename columns and tables, while unsupported constraint changes require recreating the table. section 3.2.2 section 3.3.2
A schema can be inspected or inferred at several layers:
- Inspect relational columns, types, nullability, keys, defaults, and extra metadata with DESCRIBE. section 5.5
- Infer structure from nested JSON, where arrays may contain STRUCT values and inconsistent files may require explicit unnesting, casting, or flattening. section 5.3
- Inspect Parquet’s logical and physical schema separately, including types such as DATE, INT32, INT64, and BYTE_ARRAY. section 5.5
- Combine Parquet files with differing schemas by name when needed; missing or differently named columns become NULL. section 10.4.3
Inspect and evolve a schema
Use DuckDB to inspect a file before querying it, then extend a relational table when a new requirement appears: DESCRIBE FROM 'atp/atp_rankings.parquet'; ALTER TABLE prices ADD COLUMN IF NOT EXISTS valid_until DATE; DESCRIBE reveals fields such as ranking_date, rank, points, and player_id with their inferred types. ALTER TABLE adds price validity without rebuilding the table; changing constraints may still require table recreation. section 5.5 section 3.3.2
Figure 3.1 Energy consumption schema
Use the energy-consumption schema diagram to trace how systems, readings, and prices are separated and related. section 3.2.2
