# Entities & Fields > Add entities (tables) and edit fields in Schemity. Every field property explained - name, data type, primary key, unique, nullable, and default - in database design software. Source: https://schemity.com/doc/tables-and-fields/ Entities and their fields are the heart of any ERD. In Schemity a table is called an **entity**; the columns are **fields**. This page explains every property so the editor holds no surprises. ## How do I add an entity (table)? Add an entity from the control bar and give it a name (typically a plural noun like `users` or `orders`). At the entity level you can also set: - **Name** - the table name. - **Description** - optional notes. - **Color** - a custom color for the entity header. - **Charset** and **Collation** - shown for MySQL only. ## What can I set on a field? Each field exposes these properties in the field editor: - **Field name** - the column name, for example `email` or `created_at`. - **Data type** - the column type, with **Length**, **Precision**, and **Scale** where the type supports them. The available types match the diagram's database (PostgreSQL, MySQL, SQL Server, SQLite, or Snowflake), shown as "Frequently used" and "All types". - **Default value** - a default chosen from type-specific options, or `CUSTOM` to enter your own expression. - **Description** - optional notes on the field. - **PK** - marks the field as part of the primary key. Mark more than one field to form a composite primary key. - **Unique** - enforces a single-column unique constraint. For multi-column rules, see [Check Constraints & Composite Unique](https://schemity.com/doc/check-constraints-composite-unique/). - **Nullable** - whether the column allows `NULL`. Clear it to make the column `NOT NULL`. - **Auto increment** - whether the database numbers the column itself. Shown for a whole-number key on every database; see [below](#how-do-i-make-the-database-number-a-key). - **Charset** and **Collation** - shown for MySQL only. - **Unsigned** - MySQL integer types only. An unsigned column shows on the canvas with a `u` in front of its type, for example `uBIGINT`. Schemity reads it from the database and from Import SQL and writes it in migrations and exports. A foreign key column follows the `UNSIGNED` of the key it references. That matters for Laravel and WordPress schemas, whose primary keys are `BIGINT UNSIGNED`: MySQL refuses a foreign key whose signedness differs from its key, so a relation drawn to one of those tables gets a matching unsigned column and the migration runs. ## How do I make the database number a key? Tick **Auto increment** on the field. Untick it for a key the application or the data must supply: the database then refuses a row that leaves it out. A whole-number key you draw shows it ticked when it is the table's only key column and has no default, which is what Schemity writes for it, and saving records your choice. Ticked, one row below shows what that database lets you set: | Database | Written as | You can also set | | --- | --- | --- | | PostgreSQL | `GENERATED ALWAYS AS IDENTITY` | Always or By default, start, step | | SQL Server | `IDENTITY(1,1)` | start, step | | Snowflake | `AUTOINCREMENT` | start, step, `ORDER` or `NOORDER` | | MySQL | `AUTO_INCREMENT` | nothing: the step is a server setting | | SQLite | `INTEGER PRIMARY KEY` | never reuse ids (`AUTOINCREMENT`) | On the canvas and in image exports, a numbered column shows `auto` where its default would be, so you can tell at a glance which keys the database fills. The tick is offered where the database allows it: any whole-number column on PostgreSQL, SQL Server and Snowflake, a key column on MySQL, and the table's only primary key column on SQLite. A numbered column takes no default and is `NOT NULL`. Schemity reads the setting from the database and from [Import SQL](https://schemity.com/doc/reverse-engineer-database/), start and step included, so a key with fixed ids comes back without one. Changing it on a connected diagram becomes a migration, except on SQL Server, which cannot add or remove `IDENTITY` on an existing column: Preview changes says so instead. ## How do I document what a field means? Write it in the field's **Description**. A field with a description gets a thin bar on the leading edge of its row, so you can scan down an entity and see which columns are documented and which are not. The bar is drawn in SVG exports too. Open the field editor to read or change the text. The description lives in the diagram, not in the database, so documenting a column never produces a migration. When you [reverse-engineer](https://schemity.com/doc/reverse-engineer-database/) a PostgreSQL or MySQL database, the column comments already in it are imported as descriptions. For a report of which entities and fields still lack one, export a [data dictionary](https://schemity.com/doc/data-dictionary/). Entities, legends, and relationships take descriptions too: see [Legends & Annotations](https://schemity.com/doc/legends-and-annotations/) and [Relationships](https://schemity.com/doc/relationships/). ## How do I make a field a foreign key? A field becomes a foreign key when you draw a [relationship](https://schemity.com/doc/relationships/) from its entity to another entity's key. Schemity adds and keeps the foreign key field in sync with the relationship. ## How do I copy and paste entities and fields? Copy entities or fields with Ctrl/Cmd + C and paste with Ctrl/Cmd + V to duplicate them. Across diagrams, paste is merge-aware. If the target diagram already has an entity with the same name, pasting transfers only its visual attributes - position, size, and color, with the color carrying to the entity's relationships - and leaves the schema untouched. If the entity does not exist in the target, it is pasted in full. This makes an arrangement portable: select a group of entities in one tab, paste them in another, and every matching entity snaps to the copied layout. Relationship shapes and waypoints are not transferred, since the other end of a line may sit somewhere different in the target diagram. Matching is by name, which is safe even across database schemas - Schemity opens PostgreSQL and SQL Server diagrams per schema, so names cannot collide. On a live-connected diagram, a pasted entity the database does not have yet appears as a draft with a dashed border - see [Keep Your ERD in Sync with the Database](https://schemity.com/doc/resync-database/). ## Good habits - Give every entity a primary key. - Use consistent naming - Schemity's **Naming** setting (`snake_case`, `camelCase` or `UPPER_SNAKE_CASE`) keeps generated names uniform, and a generated key or index name follows its table's case: `ORDERS_EMAIL_KEY` beside `ORDERS`. - Set nullability deliberately; defaulting everything to nullable hides real constraints. ## Next Give every new entity the same starting fields with [Templates](https://schemity.com/doc/templates/).