CompTIA Data+ DA0-002 · Free study guide

Objective 1.1 — Explain data concepts

Data analysis starts before a calculation is made. An analyst must recognize how data is organized, what a file can preserve, and which data type protects the meaning of a value. A technically valid storage choice can still be a poor analytical choice: an account number stored as an integer loses leading zeroes, a currency amount stored as a binary float can accumulate rounding error, and an image forced into a table is not suddenly structured data.

Practice these ideas as selection problems. Read the requirement first, then identify the property that matters: relationships, flexibility, history, precision, size, or structure.

Relational and non-relational databases

A relational database stores data in tables connected by keys. A primary key uniquely identifies a row, while a foreign key refers to a row in another table. Relational systems are a strong fit when the organization needs consistent schemas, joins, and transaction rules. Orders, customers, and payments are classic relational entities because their relationships and constraints matter.

Non-relational databases trade some of that fixed tabular structure for a model optimized around a particular access pattern.

Non-relational does not mean disorganized or unreliable. It means the database does not require the same row-and-column model as a relational system. Choose it because its model fits the workload, not because the word “big” appears in a scenario.

Files and what they preserve

File extensions give useful clues, but the extension alone does not guarantee good data.

• CSV stores delimited rows as plain text. It is easy to exchange, but types, formulas, formatting, and workbook features are not preserved.
• XLSX is a spreadsheet workbook. It can contain multiple sheets, formulas, formatting, and typed cells, which makes it useful for human-led work but risky as an uncontrolled pipeline source.
• JSON stores named values and nested objects or arrays. It is well suited to APIs and changing records.
• TXT is generic text. Its structure depends entirely on an agreed convention such as delimiters or fixed-width fields.
• JPG is a compressed image. Its pixels may contain useful evidence, but the image itself is unstructured until another process extracts features or labels.
• DAT is a generic data file. The producing system’s documentation is required because the extension does not specify one universal layout.

Treat an extension as the beginning of inspection, not the end. A file named .csv can still contain the wrong delimiter or character encoding, and changing a filename does not convert its underlying format.

Structured, semi-structured, and unstructured data

Structured data follows an explicit schema, usually rows and columns whose fields have defined types. Semi-structured data has recognizable organization without a rigid table. JSON is the standard example because keys and nesting describe each record even when optional fields differ. Unstructured data lacks an inherent record model that an analytical engine can use directly, such as images, audio, free-form documents, or video.

A schema describes the organization and rules of a data set. In dimensional analytics, a fact table records measurable events such as sales, clicks, or shipments. A dimension table supplies descriptive context such as customer, date, product, or region. Facts commonly contain numeric measures and foreign keys to dimensions.

A slowly changing dimension handles attributes that change over time. A Type 1 change overwrites the prior value when history does not matter. A Type 2 change creates a new version, often with effective dates, so an old transaction continues to report against the dimension value that was valid at that time.

A bridge table connects records when a simple one-to-many relationship is insufficient. For example, one customer may belong to several segments and one segment may contain many customers. The bridge holds those many-to-many associations without duplicating the customer or segment records.

Data types protect meaning

Choose a type by the operations and values the field must support.

• String types hold text. char uses a fixed length, varchar uses variable length, and nvarchar is commonly used when broad Unicode character support is required.
• Null represents an unknown, missing, or inapplicable value. It is not zero, an empty string, or the word “null.” Comparisons with null require explicit null logic.
• Spatial data represents locations or shapes such as points, routes, and boundaries. It supports operations such as distance and containment.
• Boolean data represents true and false states, sometimes with a nullable third state when the answer is unknown.
• Numeric types include integers for whole numbers, fixed-precision decimals for exact base-ten values such as money, and floating-point numbers for approximate scientific measurements.
• Datetime types represent dates and times. A time-zone-aware timestamp can identify an instant, while a timestamp without zone context may be only a local date and time. Product terminology also varies: some systems use timestamp for a row-version value rather than a datetime. Confirm the vendor's type semantics and make time-zone handling explicit when events span regions.
• Large objects hold content too large for ordinary scalar fields. A BLOB stores binary content such as an image, while a CLOB stores very large character content.
• GUIDs and UUIDs are broadly unique identifiers useful when many systems create records without coordinating sequential numbers.

Identifiers that contain only digits may still be strings. ZIP codes, product codes, and account numbers are labels, not quantities, because arithmetic on them has no business meaning.

Scenario: designing an order analytics store

A retailer receives orders in relational tables, changing product attributes through a JSON API, product photos as JPG files, and exact monetary amounts. Analysts need historical reports that preserve a product’s category at the time of sale.

The order event belongs in a fact table, with date, customer, and product keys. Descriptive product data belongs in a dimension. A Type 2 product dimension preserves category history. JSON is semi-structured and can land before its fields are standardized. JPG photos remain unstructured or can be stored as BLOBs when the database must retain them. Monetary amounts should use a fixed-precision decimal, not a float. Product codes should remain strings if leading zeroes matter.

Notice that no single classification answers the entire scenario. Each choice protects a different requirement.

Exam traps

• Choosing a database because it is fashionable rather than because its access pattern fits.
• Calling JSON unstructured simply because it is not tabular.
• Assuming XLSX and CSV preserve the same workbook features.
• Treating null as zero or as an empty string.
• Using floating point for exact currency arithmetic.
• Confusing a fact with a dimension: facts record events; dimensions describe them.
• Selecting Type 1 when the requirement explicitly asks to preserve history.
• Assuming a BLOB is a kind of database rather than a large binary data type.

Readiness checklist

• I can distinguish relational, document, key-value, graph, and wide-column models from a scenario.
• I can explain what CSV, XLSX, JSON, TXT, JPG, and DAT files do and do not preserve.
• I can classify structured, semi-structured, and unstructured data.
• I can identify fact, dimension, slowly changing dimension, bridge, and schema roles.
• I can choose among string, null, spatial, Boolean, integer, decimal, float, datetime, BLOB, CLOB, GUID, and UUID types.
• I can explain why an identifier may need a string type even when it contains only digits.
• I can justify every storage choice by the requirement it protects.