Database Terminology: Tables, Records, and Fields

The Big Picture

What is a Table? In database terminology, a Table (also called an Entity) is like a digital container that holds all the data about a specific subject. Think of it as a dedicated folder where you organize information about one particular thing — whether it's students, products, library books, or customer orders.

Every well-designed database contains multiple tables, with each table focusing on one specific type of information. For example, a school database might have separate tables for Students, Teachers, Courses, and Grades. This separation prevents混乱 (chaos) and keeps data organized!

The Grid Structure

Tables have a simple but powerful 2D layout made up of:

• Columns (running vertically) — These represent different categories of information
• Rows (running horizontally) — These represent individual entries or items

Together, columns and rows create a grid where every piece of data has its perfect place, making information easy to find and update.

What is a Field?

A Field (also called an Attribute) represents a single, specific category of information within a table. If a table is like a spreadsheet, then fields are the vertical columns — each one storing one type of data for every record in the table.

For example, in a Student table, you might have separate fields for Student ID, First Name, Last Name, Date of Birth, and Email Address. Each field holds one piece of the puzzle!

Naming Conventions: Best Practices

How you name your fields matters! Database software uses field names to organize and access data, so follow these rules to avoid errors:

• Use underscores instead of spaces — Write "First_Name" instead of "First Name"
• Be specific — "Email" is better than just "Name" which is too vague
• Start with letters, not numbers — "Student1_ID" is okay, but "1st_Student_ID" will cause problems
• Avoid special characters — Don't use @, #, $, or % in field names

What is a Record?

A Record (also called a Tuple or Row) is a complete set of related data for ONE specific item or person in a table. While a field stores one type of information across many items, a record gathers all the information about ONE item.

Think of it this way: if each field is like a filing cabinet drawer (holding one type of file), then each record is a complete folder containing all the documents for one person.

The Horizontal Connection

Records run horizontally across the table. When you look at a row from left to right, you're seeing all the different fields that describe one specific entity. All the data in that single row belongs together — it's information about one thing!

The power of records is in their completeness — one glance at a row tells you everything about a single student, product, or order.

What is a Primary Key?

A Primary Key is a special field that uniquely identifies each record in a table. No two records can have the same Primary Key value — it's like each record gets its own exclusive ID number that nobody else can use.

Why Do We Need Primary Keys?

Imagine a school with two students both named "John Brown." Without a Primary Key, how would the database tell them apart? The Primary Key solves this "Data Confusion" problem by giving each student a unique identifier, like a Student ID number that never repeats.

Examples of Primary Keys

• Student IDs — Every student gets a unique number like STU001, STU002, etc.
• ISBN Numbers — Every book has a unique International Standard Book Number
• Social Security Numbers — Each person has a unique government-issued number
• Email Addresses — In user tables, email often serves as the unique identifier

What is a Foreign Key?

A Foreign Key is a field in one table that links to the Primary Key of another table. It creates a "bridge" between tables without having to repeat all the information.

The Purpose of Foreign Keys

Imagine you have a Customers table and an Orders table. Instead of copying all the customer's information (name, address, phone) into every single order, you simply include the Customer ID as a Foreign Key in the Orders table. This:

• Saves storage space
• Prevents data inconsistency (no conflicting addresses)
• Creates logical relationships between data

Understanding the Schema

Now that you understand Fields (columns) and Tables, it's important to distinguish between the structure of a database and the data inside it.

Think of it this way: Defining Fields and Tables is like building a bookshelf. You're creating the structure — deciding how many shelves you need, how wide they should be, and what categories each shelf will hold. The Schema (the blueprint of your database structure) tells the computer exactly what kind of information you'll be storing.

The actual data is like the books you put on the shelf. Once the structure is built, you can add, remove, or update books (records) without changing the shelf design itself.

Technical Term vs. Common Name

Database terminology can be confusing because the same concept has different names! Match the formal CSEC term to its common name:

Quick Quiz

Test your knowledge by identifying the parts of a database table!