Consider an entity called “Employee”.
We are interested in the following details of each employee: ID, Last Name, First Name, and Date of Birth.
We collect these details of each employee and tabulate them.
This snippet of the table has the following database structure elements-
- Attribute (Column Header) – with the values ID, Last Name, First Name, Date of Birth
This names the details of the entity. It is created with CREATE statements of Data Definition Language (DDL) and at design-time. It is considered “metadata” i.e. “data about data”, as it defines the data that is being stored.
It cannot be altered through front-end database transactions or on the run (on the fly). Altering it would involve re-designing of the database table at design-time.
It is a subset of metadata created to identify the kind of details we are collecting about a subject, the type of data it is (integer, string etc.), its length (to specify buffer in storage and in memory), a default value, and whether it can hold a NULL as its value.
It is one-dimensional and is used to identify and define primary and foreign keys.
- Tuple (Rows) – Row 1 (A1 Smith John 1/1/1950), Row 2 (N3 Doe Jane 2/2/1960), Row 3 (J5 Jones Tim 3/3/1970)
This gives the actual values of all the details, for one instance of the entity.
- Field (Cell) – Cell A2 (EXZ873), Cell C3 (Jane), Cell B4 (Jones), Cell D1 (1/1/1950)
This gives the actual value of one detail, for one instance of the entity.
A field cannot exist without an attribute.
It is two-dimensional and needs the attribute, as well as the primary key to identify the specific cell in a given tuple.
Its value is filled based on its definition in its identifying attribute. The value can be created, altered, and manipulated on the fly, based on front-end interactions.
It is managed through Data Manipulation Language (DML) commands like SELECT, INSERT, UPDATE etc.