From Blocks to Meaning: Data Items and Databases

Source: Dev.to

Introduction

Hello, I’m Maneshwar. I’m working on FreeDevTools online, currently building one place for all dev tools, cheat codes, and TLDRs — a free, open‑source hub where developers can quickly find and use tools without the hassle of searching all over the internet.

Yesterday we grounded ourselves in the physical reality of disks—blocks, sectors, seek time, and why storage is slow and unreliable. That gave us the why behind many database‑design choices.

Now it’s time to move one layer up.

Before we can talk about tables, indexes, or transactions, we need to understand what databases actually store and what it means for that stored state to be correct. This starts with the most basic unit of information: the data item.

Data Items: Where Information Begins

A data item is anything that carries a piece of information. The information itself is represented by the value stored in that data item, and the meaning we assign to that value is what makes it useful.

In practice we often use the terms data, value, and information interchangeably, even though they are conceptually distinct.

Examples of data items

• An integer
• A person’s name
• A house address
• A binary blob
• A table
• Something even more abstract

Granularity

The size of a data item is called its granularity. Granularity defines how much information a single data item can carry.

In most database discussions, data items are treated abstractly—their exact size or meaning is often left unspecified. This abstraction is intentional: it lets database systems reason about correctness and performance without being tied to specific representations.

Core properties of a data item

• Location – resides somewhere in storage
• Identifier – has a name or address by which it is referenced
• Type – defines the allowed values and permitted operations

At a minimum, every data item must support:

1. Reading its current value
2. Overwriting it with a new value

That simple ability to read and overwrite is enough to create surprisingly complex systems once persistence and concurrency enter the picture.

From Data Items to Databases

A database is not just a container of data items. It is a single repository of many persistent data items that are related to one another.

Data items in a database rarely exist in isolation. Their values are connected through relationships, and those relationships are governed by integrity constraints—rules that define which combinations of values are allowed.

The complete set of values of all data items at a given moment defines the database state. A database state is said to be consistent if all data items satisfy all defined integrity constraints.

Why consistency matters

A database does not merely store values; it represents a real‑world system at a particular point in time.

• University example – models students, courses, instructors, and enrollments
• A consistent state corresponds to a real, valid university scenario
• An inconsistent state represents something that cannot exist in the real world

The job of a database system is not just to store data, but to prevent impossible worlds from being written to disk.

Database Operations and State Transitions

Users interact with databases by applying database operations. These operations allow users to:

• Retrieve information
• Insert new data
• Modify existing data
• Delete obsolete data

Each operation transitions the database from one state to another.

Internally, these high‑level operations do not directly manipulate disks. Instead, the database management system (DBMS) translates them into lower‑level file operations.

Physical reality

• A database lives in one or more ordinary files
• Those files reside on disk
• Modifying the database means modifying those files

This translation layer is critical: it is where abstract concepts like records and tables meet concrete realities like blocks, writes, and syncs.

Database Applications and Controlled Access

In early systems, users often manipulated data files directly using scripts, editors, or ad‑hoc tools. This approach is commonly called a file‑processing system, and it quickly proved to be fragile and dangerous.

Problems with direct file manipulation

• Error‑prone
• Easily violates integrity constraints
• Unmanageable as data grows
• Breaks down under concurrent access

The alternative is database applications—carefully designed programs that:

• Encapsulate database logic
• Expose only well‑defined operations
• Shield users from storage details

Modern databases are almost always accessed through such applications. Users execute queries and updates without needing to understand:

• How data items are stored
• Where files live on disk
• How concurrency is handled
• How failures are recovered from

Crucially, multiple users may run these applications independently and concurrently, all operating on the same database. This concurrency, combined with persistence on unreliable disks, is where the real complexity of database systems begins.

Why This Layer Matters

By now we’ve moved from:

• Disks and blocks → physical constraints

to

• Data items and databases → logical meaning and correctness

Everything that follows—transactions, concurrency control, logging, recovery—exists to preserve the illusion that:

• Data items behave atomically
• Database states transition cleanly
• Integrity constraints are never violated

Even though, underneath it all, we’re still just overwriting blocks on a disk.

👉 Check out: FreeDevTools

Any feedback or contributors are welcome! It’s online, open‑source, and ready for anyone to use.

⭐ Star it on GitHub: freedevtools