Before you can query, clean, or visualize anything, you need the shared vocabulary that every data professional uses to describe what they're working with. This lesson builds the foundation: how data is stored (relational vs. non-relational), how files are labeled and organized, how data structures shape what you can do with information, and the handful of data types you'll encounter in nearly every table you touch.
Relational vs. Non-Relational Databases
A relational database organizes data into tables with predefined columns (a fixed schema), where relationships between tables are enforced through keys -- a primary key uniquely identifies each row, and a foreign key links a row to a row in another table. This structure guarantees consistency: you can't have an order that references a customer who doesn't exist. Relational systems (built on SQL) are the default choice when data is well-structured and relationships matter, such as financial records, inventory, or HR systems.
Non-relational (NoSQL) databases drop the fixed schema requirement. Document stores keep data as flexible, self-describing documents (often JSON); key-value stores pair a unique key with an arbitrary value; wide-column and graph stores optimize for other access patterns entirely. Non-relational systems trade some consistency guarantees for flexibility and horizontal scalability, which is why they show up heavily in web applications, IoT telemetry, and content platforms where the shape of the data varies record to record.
File Extensions You'll Actually See
Data doesn't only live in databases -- it moves around as files, and the extension tells you a lot before you even open it. Delimited text formats like .csv (comma-separated) and .tsv (tab-separated) are the lowest common denominator for exchanging tabular data between tools. .json is the standard for semi-structured, nested data exchanged by APIs. .xml is an older, more verbose markup-based exchange format still common in enterprise and legacy systems. .parquet and similar columnar formats store data by column rather than row, which makes them dramatically faster for analytical queries that only need a few columns out of many.
Data Structures: Structured, Semi-Structured, Unstructured
Structured data fits neatly into rows and columns with a fixed schema -- think a spreadsheet or a relational table. Semi-structured data has some organizational markers (tags, keys) but no rigid schema -- JSON and XML documents are the classic examples, where two records can have different fields entirely. Unstructured data has no predefined model at all -- free text, images, audio, video.
Within structured relational design, you'll also meet the star-schema vocabulary: a fact table holds the measurable events (sales amount, quantity sold), a dimension table holds the descriptive context around those events (customer, product, date), and a bridge table resolves many-to-many relationships between dimensions that a simple foreign key can't express alone.
Core Data Types
Every column you'll ever profile falls into a small set of types: strings (text of varying length), numerics (integers and decimals, each with precision trade-offs), datetime (dates, times, and timestamps -- often the source of timezone and format headaches), BLOB/CLOB (Binary/Character Large Objects, used to store large binary data like images or long text directly in a database), and GUID/UUID (Globally/Universally Unique Identifiers -- long generated strings used as keys when you need uniqueness across systems without coordinating a central counter).
Key Mechanics
- Relational databases enforce schema and referential integrity via primary/foreign keys; non-relational databases trade that rigidity for flexibility and scale.
- Fact tables store measures/events; dimension tables store descriptive context; bridge tables resolve many-to-many relationships.
- Structured data = fixed schema (rows/columns); semi-structured = flexible but tagged (JSON/XML); unstructured = no model (text, media).
- Columnar formats like Parquet outperform row-based formats like CSV for analytical queries touching few columns across many rows.
- GUID/UUID values guarantee uniqueness across systems without a shared sequence generator, unlike auto-incrementing integer keys.
Exam Tip: Don't confuse a fact table (measures/metrics) with a dimension table (descriptive attributes) -- a question describing "sales amount and quantity" is pointing at a fact table, while "customer name and region" points at a dimension table.
Exam Tip: JSON and XML are both semi-structured, not unstructured -- unstructured means no organizational markers at all, like plain free text or an image file.
Exam Tip: A GUID/UUID is not the same as an auto-incrementing primary key -- GUIDs are generated to be unique without any central coordination, which matters when merging data from multiple independent systems.
Diagram
Worked example: An analyst at a retail company receives a nightly export as a .json file from the e-commerce API alongside a .csv extract from the relational order-management database. She recognizes the JSON as semi-structured (nested customer and product attributes that vary by order type) and the CSV as structured, mapping cleanly to the existing fact_orders and dim_customer tables in the warehouse -- with fact_orders holding transaction amounts and dim_customer holding descriptive customer attributes.