Object-Based Logical Models: Logical, View, or Physical Level?

Verified Sources

Sep 12, 2026

In database design, object-based logical models are primarily used at the logical level to describe what data and relationships exist in the system (conceptual structure and integrity constraints), independent of how data is physically stored. This aligns with the standard database architecture separation between logical (meaning/structure), view (user-specific perspectives), and physical (storage implementation).2

To connect this to your multiple-choice prompt: object-based logical modeling belongs to (i) logical level, not (ii) view level (external/user views) and not (iii) physical level (storage structures and access methods).2

Key terms:

object-based logical model
logical level
view level
physical level

Database architecture and schema levels (external/view, conceptual/logical, internal/physical) - Wikipedia https://en.wikipedia.org/wiki/Database_schema ↩ ↩²
Three-schema architecture (external, conceptual, internal) and abstraction levels - Wikipedia https://en.wikipedia.org/wiki/Three-schema_architecture ↩ ↩²

Database architecture: logical vs physical vs views (external/internal schemas)

Why object-based logical models map to the logical level

An object-based logical model typically represents:

classes/objects as the central modeling constructs,
relationships among them,
and constraints that define valid states.

These are “logical” concerns—i.e., they characterize the meaning and structure of data rather than the storage mechanism.

By contrast:

view level focuses on different presentations of the same underlying logical model.
physical level focuses on how records/objects are persisted (e.g., files, page layouts, indexes).

This separation is consistent with the three-schema (external/internal/conceptual or logical/physical) ideas used to describe databases at different levels of abstraction.2

Database architecture and schema levels (external/view, conceptual/logical, internal/physical) - Wikipedia https://en.wikipedia.org/wiki/Database_schema ↩
Three-schema architecture (external, conceptual, internal) and abstraction levels - Wikipedia https://en.wikipedia.org/wiki/Three-schema_architecture ↩

How object-based logical modeling fits in database abstraction

Define structure and constraints

1. Logical level

Model classes/objects, relationships, and integrity constraints."

Derive user-specific views

2. View level

Select/filter/reformat parts of the logical model for users/apps."

Choose storage/access strategy

3. Physical level

Map logical objects to storage structures, indexes, and files."

From object-based logical model to database implementation

1
Step 1
Identify entity/object classes, define attributes/relationships, and state integrity constraints.
2
Step 2
Create external/view definitions for different users/apps, choosing relevant subsets or join paths from the logical schema.
3
Step 3
Implement the logical model using storage structures (e.g., record formats, indexes, file organization) and define access paths.
4
Step 4
Ensure constraints preserved logically; confirm views reflect correct semantics; verify physical mapping supports performance and correctness.

Which level does an object-based logical model describe?

Correct choice corresponds to the primary abstraction level for object-based logical modeling.

Quick exam heuristic

If the question says logical model, it’s about structure/meaning (not storage). If it says view, it’s about user-specific presentations.

Common confusion

Object-oriented/object-based modeling can feel like it’s “implementation-oriented,” but in database architecture it’s used here at the logical (meaning) layer, with physical storage decided later.

Exam-focused clarifications

Knowledge Check

Question 1 of 4

Q1Single choice

Object-based logical models are used to describe data at which level?

(i) logical level

(ii) view level

(iii) physical level

(iv) None of the above

Explore Related Topics

OSI Model

The OSI model is a seven‑layer framework that defines data flow, encapsulation, and troubleshooting across networks.

Layers 1‑7 progress from raw bits to user services; examples include Ethernet, IP, TCP, and HTTP.
Encapsulation adds a header (and optional trailer) at each layer: $Payload + Header_n + Trailer_n$ , ending as bits.
The model enables layered troubleshooting; e.g., Layer 3 problems involve routing/IP, Layer 7 involve application protocols.
Compared to TCP/IP, OSI splits functions into more layers; Session and Presentation map into TCP/IP’s Application layer.

Reasoning Models

Reasoning models are language models that allocate extra inference‑time compute to perform multi‑step problem solving, boosting performance on math, coding, planning, and scientific tasks.

Employ chain‑of‑thought, tree‑of‑thought, self‑verification, tool use, and compute budgeting.
Test‑time scaling (e.g.,  $o1$ ) improves accuracy as inference compute grows.
Higher effort raises accuracy (55→84%) but adds latency and cost, so budgets match task difficulty.
Deploy via cascaded inference: cheap models for easy cases, reasoning models for hard ones, with external checks for safety.

Database Indexing: Which Options Are Used for Indexing?

Browse all research articles