# Core Structure Settings

## Content

When a table is created, each record in the data source becomes a row in the table.
The `schema.columns` section defines how each field of a record is modeled as a table column.
For example:

```javascript
const table = dataManager.addTable("employees", {
    data: [
        { id: 1, name: "Alice", birthday: "2000-01-01" },
        { id: 2, name: "Bob", birthday: "2001-05-12" }
    ],
    schema: {
        columns: {
            id: { dataType: "number", isPrimaryKey: true },
            name: { dataType: "string" },
            birthday: { dataType: "date" }
        }
    }
});
```

In this example:

* Each object in `data` is a record.
* Each property of the record (`id`, `name`, `birthday`) becomes a column.
* The `columns` configuration defines how those fields are interpreted and managed by DataManager.

Core structure settings define:

* How a column maps to raw data
* How its value is resolved
* How its type is interpreted
* Whether it uniquely identifies a record

They form the structural foundation of column modeling.

## Column Name

Each entry in `schema.columns` represents a column definition.

```javascript
schema: {
    columns: {
        id: { dataType: "number" },
        name: { dataType: "string" }
    }
}
```

The object key (`id`, `name`) is the column’s logical identifier within the table.
This name is used when:

* Referencing fields in formulas
* Defining relationships
* Accessing row data
* Building views

If the `name` property is specified inside the column definition, it overrides the object key as the internal column name.
In most cases, the object key is sufficient.

## dataName

`dataName` maps a column to a different field name in the raw data.

```javascript
schema: {
    columns: {
        firstName: {
            dataName: "salesperson"
        }
    }
}
```

In this example:

* `salesperson` is the field in the original data
* `firstName` becomes the column name inside the table

This is useful when:

* Backend field names do not match frontend naming conventions
* Multiple fields need to be renamed for clarity
* The same data source is reused with different logical models

`dataName` does not modify the original data.
It only defines how the field is mapped during parsing.

## value

The `value` property defines how the column value is resolved.
It can be:

* A field name
* A formula expression

### Field Mapping

```javascript
columns: {
    name: {
        value: "username",
    }
}
```

This explicitly maps the column to a specific field in the record.
If `value` is not defined, the column name is used as the field name by default.

### Formula Column

If `value` contains a formula expression and `dataType` is set to `"formula"`, the column becomes a computed column.

```javascript
TotalUnits: {
    dataType: "formula",
    value: "=[@UnitsInStock] + [@UnitsOnOrder]"
}
```

In this case:

* The column does not directly map to a raw data field
* Its value is computed from other fields in the same record

Formula columns behave like regular data columns after evaluation.

## dataType

`dataType` defines how the column value is interpreted.
Common types include:

* `"string"`
* `"number"`
* `"boolean"`
* `"date"`
* `"formula"`
* `"object"`
* `"array"`

The data type affects:

* Value parsing (especially for dates and numbers)
* Formula behavior
* Validation logic
* Integration with views

For example, when JSON data contains date strings:

```javascript
columns: {
    birthday: {
        dataType: "date"
    }
}
```

The value is converted into a date value during parsing.
If `dataType` is not specified, the type is inferred from the value.

## isPrimaryKey

`isPrimaryKey` marks a column as part of the table’s primary key.

```javascript
columns: {
    id: {
        isPrimaryKey: true
    }
}
```

A primary key:

* Uniquely identifies each record
* Is required for relationships
* Is required for certain advanced features such as cross views

Primary key constraints are enforced at the table level.
If multiple columns are marked as `isPrimaryKey`, they form a composite key.

## Structural Responsibility

Core structure settings define:

* How a column maps to raw data
* How its value is computed
* How its type is interpreted
* Whether it uniquely identifies records

They do not control:

* Validation rules
* Display formatting
* Filtering behavior
* Styling

Those capabilities are configured separately in other column modeling sections.