Data Acquisition, Management and SQL

Introduction and Context

Data analytics begins before analysis. The quality, meaning, accessibility and governance of analytical results depend on how data is acquired, integrated, stored and documented. Contemporary organizations collect data from transaction-processing systems, mobile applications, sensors, social platforms, partner APIs, documents and machine logs. These sources differ in structure, velocity, ownership, reliability and legal status. Consequently, data acquisition and management are not merely technical activities; they are organizational capabilities that shape what an enterprise can know and responsibly decide.

This chapter examines the data lifecycle from acquisition to analytical use. It explains structured, semi-structured and unstructured data; relational modeling and SQL; APIs and metadata; data warehouses, data lakes and lakehouses; and the quality, lineage, security and governance controls required for trustworthy analytics. The emphasis is on postgraduate-level design judgment: selecting suitable architectures, identifying trade-offs and connecting implementation decisions with business and regulatory consequences.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Distinguish structured, semi-structured and unstructured data and select appropriate acquisition techniques.

2. Design a normalized relational model and formulate SQL queries involving joins, aggregation and analytical functions.

3. Explain API-based acquisition, batch processing, streaming and change-data capture.

4. Use metadata, data catalogs and lineage to improve discoverability and trust.

5. Compare data warehouses, data lakes and lakehouses.

6. Assess data quality, security, privacy, ethical and regulatory risks.

7. Design an acquisition and management approach for an integrated analytical use case.

1. The Data Lifecycle and Data Acquisition

A useful lifecycle is: identify requirements, acquire data, ingest and validate it, store and integrate it, transform and publish it, analyze and share it, retain or archive it, and finally dispose of it according to policy. The lifecycle is iterative rather than strictly linear. Analytical findings may reveal that a source lacks required fields, has unsuitable granularity or contains systematic bias, requiring renewed acquisition or redesign.

Data types and structures

Structured data conforms to a defined schema, commonly rows and columns. Examples include invoices, account records and inventory tables. Its predictable structure supports relational constraints and SQL.

Semi-structured data has organizational markers but not a fixed tabular schema. JSON, XML, event messages and many application logs are examples. A JSON record may contain nested objects, optional attributes and arrays. Such flexibility supports rapid application evolution but complicates validation, joins and historical consistency.

Unstructured data does not have a predefined analytical schema. Text, images, audio, video, scanned documents and email are typical examples. It can still possess valuable metadata and can be transformed through natural-language processing, computer vision, speech recognition or information extraction.

The categories are practical rather than absolute. A document is unstructured with respect to its content, but its filename, author and creation date may be structured metadata. A JSON event is semi-structured at ingestion but may be projected into relational tables for analysis.

Acquisition patterns

Batch acquisition transfers data at scheduled intervals. It is appropriate for payroll extracts, daily financial reports and systems where immediate freshness is unnecessary. Streaming acquisition processes events continuously or in short intervals, supporting fraud detection, telemetry and operational monitoring. It introduces challenges involving ordering, duplication, late arrival and replay.

Common acquisition mechanisms include:

• Database extraction: queries, replicated tables or change-data capture (CDC), which identifies inserts, updates and deletes from transaction logs or system timestamps.
• File transfer: CSV, Parquet, Avro or XML files transferred through secure storage or managed file-transfer services.
• APIs: programmatic interfaces that expose resources or events under defined authentication, rate and versioning policies.
• Message brokers: systems that decouple producers and consumers and support durable event delivery.
• Manual or instrumented collection: forms, sensors, scanners and application telemetry.

A robust ingestion process is usually idempotent: processing the same source event more than once does not create an incorrect additional business effect. This can be achieved with source event identifiers, deduplication keys, merge operations and recorded ingestion status. Idempotency is especially important when networks fail and messages are retried.

APIs as acquisition interfaces

An API contract normally specifies endpoints, parameters, response schemas, authentication, error codes, pagination, rate limits and version policy. REST APIs commonly use HTTP methods such as GET for retrieval and POST for submission, while GraphQL permits clients to request specified fields. Neither style automatically guarantees high data quality.

An acquisition client should record request time, endpoint version, response status, page or cursor, source identifier and retrieval errors. Pagination must be handled explicitly; otherwise only the first part of a dataset may be collected. Rate limits require controlled retries with backoff, and repeated retrieval should respect the provider’s terms of service. API data should be validated against the declared schema, while unknown fields should generally be preserved in a quarantine or raw layer rather than silently discarded.

2. Relational Modeling and SQL

The relational model

A relation is represented as a set of tuples over named attributes. In implementation, a table contains rows and columns, although the mathematical relational model does not depend on physical storage order. A primary key uniquely identifies a row. A foreign key references a key in another table and expresses a relationship. Candidate keys are possible unique identifiers; one may be selected as the primary key.

Consider a retail design:

• Customer(CustomerID, Name, Region)
• Product(ProductID, ProductName, Category, UnitPrice)
• OrderHeader(OrderID, CustomerID, OrderDate)
• OrderLine(OrderID, ProductID, Quantity, SalePrice)

OrderLine uses a composite key (OrderID, ProductID) if a product can occur only once per order. Its foreign keys connect orders to customers and products. In practice, a separate OrderLineID may be introduced when line-level identity is required, but business uniqueness should still be enforced where appropriate.

Normalization

Normalization reduces redundancy and update anomalies. In simplified terms:

• First normal form (1NF): attributes contain atomic values and repeating groups are removed.
• Second normal form (2NF): 1NF is satisfied and every non-key attribute depends on the whole composite key, not merely part of it.
• Third normal form (3NF): 2NF is satisfied and non-key attributes do not depend transitively on another non-key attribute.

Suppose OrderLine(OrderID, ProductID, ProductName, Quantity) has a composite key of OrderID and ProductID. ProductName depends only on ProductID, so it violates 2NF and should be placed in Product. Normalization improves consistency, but excessive normalization may increase joins and reduce convenience for analytical workloads. Consequently, operational systems often favor normalized models, whereas warehouses may use carefully designed dimensional models.

SQL foundations

SQL is declarative: the user states the desired result, while the database optimizer selects an execution strategy. A basic query is:

```sql

SELECT ProductID, ProductName, UnitPrice

FROM Product

WHERE Category = 'Networking'

AND UnitPrice >= 100;

```

Filtering should occur as early as practical, but the optimizer may reorder operations. Explicit column selection is preferable to `SELECT *` because it reduces unnecessary data transfer and protects queries from unintended schema changes.

A join combines related rows:

```sql

SELECT o.OrderID, c.Name, o.OrderDate

FROM OrderHeader AS o

JOIN Customer AS c ON c.CustomerID = o.CustomerID;

```

An inner join returns matching rows. A left join preserves every row from the left table and supplies nulls where no match exists. Analysts must understand join cardinality: joining one customer row to many order rows intentionally repeats customer attributes, while joining two independent one-to-many tables can multiply records and inflate totals.

Aggregation summarizes groups:

```sql

SELECT CustomerID,

COUNT(*) AS NumberOfOrders,

SUM(OrderTotal) AS TotalValue

FROM OrderSummary

GROUP BY CustomerID

HAVING SUM(OrderTotal) > 10000;

```

`WHERE` filters rows before grouping; `HAVING` filters groups after aggregation. Null is not the same as zero or an empty string. `COUNT(*)` counts rows, whereas `COUNT(column)` excludes null values in that column.

A window function calculates across related rows without collapsing them:

```sql

SELECT CustomerID, OrderDate, OrderTotal,

SUM(OrderTotal) OVER (

PARTITION BY CustomerID

ORDER BY OrderDate

ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW

) AS RunningValue

FROM OrderSummary;

```

The partition defines the independent calculation groups, and the ordering defines sequence. Ties and duplicate dates should be handled deliberately, often by adding a stable secondary ordering column.

Worked SQL example

Assume the following order lines:

| OrderID | ProductID | Quantity | SalePrice |

|---|---|---:|---:|

| 101 | P1 | 2 | 50 |

| 101 | P2 | 1 | 120 |

| 102 | P1 | 3 | 50 |

The line value is Quantity multiplied by SalePrice. Order 101 is 2×50 + 1×120 = 220, and Order 102 is 3×50 = 150. A query calculating order totals is:

```sql

SELECT OrderID,

SUM(Quantity * SalePrice) AS OrderTotal

FROM OrderLine

GROUP BY OrderID;

```

The result is 101, 220 and 102, 150. The calculation is valid only if SalePrice is the price actually charged at the time of sale. Replacing it with the current Product.UnitPrice could produce historically incorrect revenue.

Transactions, constraints and performance

Transactions support reliable state changes through the ACID properties: atomicity, consistency, isolation and durability. A transaction may insert an order and its lines together so that a partial order is not committed. Constraints such as `NOT NULL`, `UNIQUE`, `CHECK`, primary keys and foreign keys enforce rules close to the data.

Indexes accelerate selected access paths but consume storage and can slow inserts and updates. Query plans should be examined using the database’s explain facility. Performance depends on data volume, selectivity, join strategy, statistics, partitioning and physical layout; an index is not automatically beneficial for every column.

3. Analytical Data Models and Storage Architectures

Data warehouses

A data warehouse is a curated, integrated repository optimized for reporting and analytical queries. It commonly applies schema-on-write: structure and business rules are established before publication. A dimensional warehouse contains facts, such as sales amount, and dimensions, such as customer, product and date. A star schema places a fact table at the center with denormalized dimension tables. A snowflake schema further normalizes dimensions, reducing redundancy but increasing joins.

A critical design decision is the grain of a fact table: the precise meaning of one row. For example, “one row per product per order line” differs from “one row per order.” Measures must match that grain. Additive measures can be summed across all dimensions; semi-additive measures, such as account balance, may be summed across some dimensions but not time; non-additive ratios should generally be recomputed from their components.

Slowly changing dimensions preserve changes in descriptive attributes. Type 1 overwrites an old value; Type 2 creates a new version with effective dates and a current-row indicator. Type 2 is useful when historical analysis must reflect the attribute that was valid at the time.

Data lakes

A data lake stores large volumes of raw or lightly processed data in object storage, often in diverse formats. Schema-on-read postpones some structural decisions, supporting exploration, machine learning and ingestion of new sources. However, an unmanaged lake can become a “data swamp”: files lack ownership, definitions, quality controls and discoverability.

A practical lake often uses zones such as raw, standardized and curated. Raw data should be immutable where possible and retain source fidelity. Standardized data may apply type normalization, deduplication and common identifiers. Curated data is prepared for specific analytical or operational uses. Open columnar formats such as Parquet can improve scan efficiency, but format choice does not replace governance.

Lakehouses

A lakehouse aims to combine the low-cost, flexible storage of a lake with warehouse capabilities such as transactions, schema enforcement, versioning, governance and efficient analytical access. Its value depends on implementation quality, workload patterns and organizational maturity. It is not a universal replacement: highly regulated reporting may still benefit from a specialized warehouse, while exploratory unstructured workloads may fit a lake more naturally.

Architectural choices should be evaluated against freshness, workload concurrency, data variety, governance, cost, portability, skills and recovery requirements rather than by fashionable labels.

4. Metadata, Quality and Lineage

Metadata and catalogs

Metadata is data about data. Technical metadata describes schemas, data types, partitions and physical locations. Business metadata records definitions, owners, permissible uses and criticality. Operational metadata records load times, row counts, failures and freshness. Provenance metadata identifies origin and transformations.

A data catalog makes these descriptions searchable and supports stewardship. A business glossary distinguishes terms that otherwise appear interchangeable. For example, “customer” may mean a person with an account, a paying organization or a household. Without an agreed definition, technically correct queries can still produce misleading decisions.

Data quality dimensions

Important dimensions include accuracy, completeness, consistency, timeliness, validity, uniqueness and fitness for purpose. Quality is contextual. A missing telephone number may be irrelevant to revenue reporting but critical to an outbound service process.

Quality rules should be measurable, such as “OrderID is unique in OrderHeader,” “Quantity is a positive integer,” or “95% of daily events arrive within ten minutes.” A simple completeness rate for an attribute can be expressed as:

Completeness rate = (number of non-null values / total number of records) × 100%

This measure assumes that nullability is the intended concern and that the record population and denominator are clearly defined. It does not measure whether non-null values are correct.

Validation should occur at ingestion and publication. Failed records can be quarantined with reason codes, while alerts should distinguish transient infrastructure failures from systematic source defects. Silent correction is dangerous because it removes evidence needed for diagnosis.

Lineage

Lineage describes where data came from, how it changed and where it was used. It may be captured at dataset, column or record level. Dataset lineage is easier to maintain; column lineage is more useful for impact analysis but can be difficult with dynamic SQL and complex code. Lineage supports regulatory inquiries, debugging, reproducibility and assessment of whether a metric is affected by a source change.

5. Governance, Security and Responsible Use

Data governance assigns decision rights and accountability. Typical roles include data owner, steward, custodian, producer and consumer. Policies should define classification, retention, access, quality thresholds, naming, change management and disposal.

Security controls include encryption in transit and at rest, identity-based access, least privilege, network segmentation, secrets management, monitoring and tested backups. Fine-grained controls may use row- or column-level security and masking of sensitive fields. Development environments should use appropriately de-identified or synthetic data.

Privacy requires purpose limitation, data minimization, transparency, lawful processing and retention discipline. Sensitive personal data may require stronger controls and additional legal bases depending on jurisdiction. Consent is not the only possible legal basis, and storing more data “just in case” increases exposure. De-identification reduces risk but is not automatically irreversible, especially when datasets can be linked with external information.

Ethical risks include discriminatory historical data, unequal representation, inappropriate secondary use and surveillance. Data quality controls should therefore examine not only technical validity but also coverage and bias. AI systems intensify these concerns because models may infer sensitive attributes or create decisions that are difficult to explain. Provenance, access controls and documented intended use are prerequisites for responsible analytical AI.

6. Integration and Interoperability

Integration requires more than matching column names. Systems may use different identifiers, units, time zones, currencies, event definitions and update semantics. A conformed dimension, such as a shared date or customer identity, allows multiple subject areas to be analyzed consistently. Master data management establishes authoritative or reconciled representations of key entities, while reference data standardizes controlled values such as country codes.

The extract-transform-load (ETL) pattern transforms data before loading it into a target. Extract-load-transform (ELT) loads raw data first and transforms it using the target platform. ETL can enforce early control and reduce target storage; ELT preserves raw data and uses scalable analytical compute. Hybrid approaches are common.

A successful integration pipeline documents source-to-target mappings, handles schema evolution, records rejected data, supports replay and separates business transformation logic from infrastructure code. Data contracts can specify fields, types, semantics, quality expectations and compatibility rules between producers and consumers.

7. Applied Case: Integrating Retail and Delivery Data

Background

The following is an illustrative case. A regional retailer operates an e-commerce platform, physical stores and a third-party delivery service. Management wants a daily view of customer profitability, delivery performance and stock availability.

Problem

Online orders reside in a relational database, store transactions arrive as nightly CSV files, delivery events are available through a REST API, and customer-service interactions are stored as text transcripts. The systems use different customer identifiers and time zones. Executives have observed conflicting revenue totals and cannot determine whether delivery delays arise from the retailer or the carrier.

Analysis

The first task is to define metrics and their grain. Revenue should be based on transaction-level charged prices, excluding cancelled orders according to an approved business rule. Delivery performance requires an event definition: for example, elapsed time from carrier acceptance to confirmed delivery, with explicit treatment of failed attempts. Customer profitability requires cost assumptions and should not be presented as revenue alone.

Source assessment identifies several risks: duplicated API pages after retries, late-arriving delivery events, missing store product codes, transcript privacy concerns and inconsistent time zones. A common customer identity cannot be assumed from email addresses because addresses may be shared, changed or mistyped.

Approach and solution

The retailer establishes a lakehouse with three logical layers. The raw layer stores immutable API responses, source files, database extracts and transcripts with restricted access. The standardized layer converts timestamps to UTC while retaining source time zones, validates types, deduplicates events using provider event IDs and maps product codes through governed reference data. The curated layer publishes a dimensional sales model and delivery fact table.

A warehouse-style model includes a SalesFact at order-line grain, a DeliveryFact at delivery-event or delivery-instance grain, and conformed Date, Product, Store, Customer and Carrier dimensions. Customer identity is resolved through a governed matching process with confidence scores and manual review for ambiguous matches. The API loader records cursors, response hashes, retrieval time and provider version. It retries transient failures but does not endlessly retry authentication or schema errors.

Data quality rules check uniqueness of order keys, positive quantities, valid product mappings, plausible event sequences and freshness thresholds. Rejected records remain available in quarantine. A catalog records owners, definitions and permitted uses. Transcripts are tokenized or excluded from broad analytical access, and retention is limited to the approved service purpose.

Outcome

The organization obtains a consistent daily revenue metric and can separate retailer processing time from carrier transit time. Analysts can reproduce dashboard figures from curated tables and trace them to raw sources. The project also reveals that some apparent delivery failures were caused by missing carrier events rather than actual late deliveries, leading to a new carrier data contract.

Learning points

The case demonstrates that architecture alone does not solve semantic disagreement. Grain, definitions, identifiers, timestamps, lineage and governance determine analytical credibility. It also shows why raw retention, controlled transformation and explicit quality exceptions are more reliable than silently overwriting problematic data.

8. Challenges, Trade-offs and Best Practices

Data management faces scale, changing schemas, vendor dependence, cost growth, skills shortages and conflicting stakeholder priorities. Flexible lakes can reduce upfront modeling but increase discovery and quality costs. Warehouses can provide strong performance and governance but may require earlier design commitments. Streaming can reduce latency while increasing operational complexity. More data does not necessarily produce better analysis; irrelevant, biased or poorly governed data can increase both cost and harm.

Recommended practices include:

1. Begin with analytical and operational decisions, not a technology brand.

2. Define data grain, ownership, permitted use and quality expectations before integration.

3. Preserve source fidelity and record ingestion metadata.

4. Use explicit contracts, schemas and controlled schema evolution.

5. Apply constraints and validation close to the point of ingestion.

6. Make pipelines observable through logs, metrics, alerts and lineage.

7. Design for retries, idempotency, replay and late-arriving data.

8. Separate raw, standardized and curated data with appropriate access controls.

9. Use least privilege, minimization, retention and tested recovery procedures.

10. Test both technical correctness and business semantics, including totals and edge cases.

11. Treat definitions and stewardship as continuing organizational work.

12. Evaluate cloud, lakehouse and AI claims against measurable workload and governance requirements.

Contemporary Developments

Modern data platforms increasingly support open table formats, event-driven pipelines, data products and data mesh approaches. Data mesh emphasizes domain ownership, data as a product, self-service platform capabilities and federated governance. It can improve accountability in large organizations but may reproduce inconsistency if shared standards and interoperability are weak.

Data observability tools monitor freshness, volume, distribution and schema changes. Semantic layers centralize metric definitions so that dashboards and models use consistent logic. Vector stores and retrieval systems introduce new acquisition and lineage requirements for documents and embeddings; an embedding is not a substitute for preserving the source document, access policy and version. Generative AI can assist with schema mapping, SQL drafting and metadata classification, but generated queries and classifications require testing, human review and protection against sensitive-data disclosure.

Chapter Summary

Data acquisition and management establish the foundations of trustworthy analytics. Structured, semi-structured and unstructured data require different ingestion and validation strategies, but all benefit from explicit ownership, metadata and lineage. APIs, CDC, batch files and streaming systems must address authentication, pagination, retries, duplication, schema evolution and replay.

Relational modeling uses keys, constraints and normalization to reduce anomalies, while SQL provides declarative tools for selection, joining, aggregation and window analysis. Analytical warehouses emphasize curated schemas and dimensional grain; lakes provide flexible raw storage; lakehouses seek to combine flexibility with transactional and governance capabilities. No architecture is universally best.

Quality is multidimensional and must be measured in context. Governance, privacy, security, responsible use and regulatory compliance are integral to technical design. The retail case shows that common definitions, identity resolution, event semantics, layered storage and lineage are essential to reconcile heterogeneous sources. Effective professionals therefore design data systems not only for scale and speed, but also for meaning, accountability, reproducibility and appropriate use.

Key Terms

Structured data: Data organized according to a stable schema, commonly rows and columns.

Semi-structured data: Data with organizational markers but a flexible or nested schema.

Unstructured data: Content without a predefined analytical tabular schema, such as text or images.

API: A defined programmatic interface through which software exchanges data or services.

Change-data capture: A method for identifying and extracting source-system inserts, updates and deletes.

Idempotency: The property that repeating an operation produces the same intended result as performing it once.

Primary key: An attribute or attribute set that uniquely identifies a row.

Foreign key: An attribute that references a key in another table.

Normalization: Relational design practice that reduces redundancy and update anomalies.

SQL: A declarative language for defining, querying and manipulating relational data.

Data warehouse: A curated analytical repository optimized for integrated reporting and analysis.

Data lake: Flexible storage for large volumes of raw or lightly processed data in varied formats.

Lakehouse: An architecture combining lake-style storage with warehouse-style management and analytics capabilities.

Metadata: Data describing the structure, meaning, origin, ownership or operation of data.

Data lineage: Information about data origin, transformations and downstream use.

Data quality: The degree to which data is accurate, complete, consistent, timely, valid and fit for purpose.

Data grain: The precise real-world meaning represented by one row of a fact or transactional table.

ETL: Extract-transform-load, in which data is transformed before loading into a target.

ELT: Extract-load-transform, in which raw data is loaded before transformation in the target environment.

Data governance: Policies, roles, standards and decision rights governing data assets.

Review Questions

Short Answer Questions

1. Distinguish structured, semi-structured and unstructured data, giving one example of each.

2. What is the purpose of a primary key and a foreign key?

3. Explain the difference between `WHERE` and `HAVING` in SQL.

4. Define data lineage and state two reasons it is useful.

5. What is meant by the grain of a fact table?

Long Answer Questions

1. Compare batch, streaming and change-data-capture acquisition, including their principal design risks.

2. Explain normalization through 1NF, 2NF and 3NF, and discuss why analytical models may be less normalized.

3. Compare data warehouses, data lakes and lakehouses with respect to schema, governance, workload and flexibility.

4. Develop a data-quality and governance framework for a dataset containing personal information.

5. Explain how metadata, catalogs, business glossaries and lineage collectively improve analytical trust.

Analytical / Application Questions

1. Design an integrated architecture for a bank combining core transactions, mobile-app events, regulatory files and customer-service text. Justify ingestion patterns, storage layers, quality controls and access policies.

2. A query joining customers, orders and order lines reports revenue three times higher than the financial system. Diagnose likely join-cardinality and grain problems and propose SQL or modeling corrections.

3. An API occasionally returns duplicate and late delivery events while changing its JSON schema. Specify an ingestion design that supports validation, idempotency, schema evolution, replay and lineage.

Multiple Choice Questions with Answers

Question 1

Which acquisition property prevents retrying the same event from creating an incorrect duplicate effect?

A. Normalization

B. Idempotency

C. Denormalization

D. Pagination

Correct Answer: B. Idempotency

Question 2

Which SQL clause filters groups after aggregation?

A. WHERE

B. FROM

C. HAVING

D. ORDER BY

Correct Answer: C. HAVING

Question 3

In a normalized design, ProductName should generally be stored with Product rather than OrderLine because it depends on:

A. OrderID only

B. Quantity only

C. ProductID only

D. Both OrderID and Quantity

Correct Answer: C. ProductID only

Question 4

What is the primary purpose of defining fact-table grain?

A. To specify the meaning represented by one row

B. To encrypt every measure

C. To eliminate all dimensions

D. To determine API authentication

Correct Answer: A. To specify the meaning represented by one row

Question 5

Which architecture typically applies schema-on-read and supports diverse raw formats?

A. Data lake

B. Normalized OLTP database only

C. Spreadsheet workbook

D. Static HTML page

Correct Answer: A. Data lake

Question 6

What does COUNT(column_name) generally do with null values in that column?

A. Counts them twice

B. Excludes them

C. Converts them to zero and counts them

D. Raises an error in every SQL system

Correct Answer: B. Excludes them

Question 7

Which metadata type records owners, definitions and permitted uses?

A. Business metadata

B. Only physical metadata

C. Compression metadata

D. Network metadata

Correct Answer: A. Business metadata

Question 8

A Type 2 slowly changing dimension is used primarily to:

A. Delete all historical attributes

B. Preserve versions of changing attributes over time

C. Remove the need for primary keys

D. Convert text into images

Correct Answer: B. Preserve versions of changing attributes over time

Question 9

Which quality dimension asks whether data arrives within the required time window?

A. Timeliness

B. Uniqueness

C. Atomicity

D. Referential indexing

Correct Answer: A. Timeliness

Question 10

Which control most directly limits access to sensitive columns according to user role?

A. Column-level security or masking

B. Increasing file size

C. Removing all metadata

D. Changing a table to CSV

Correct Answer: A. Column-level security or masking