Physical Data Model (PDM)
Purpose: Implement the actual database on a specific platform
Characteristics:
Audience: DBAs, database engineers, DevOps teams
Detail Level: Implementation-specific—every technical detail
Focus Areas: Tables, columns, data types, indexes, constraints, storage strategy
Technology: Database-specific (PostgreSQL, Oracle, MongoDB, etc.)
Tools: SQL scripts, native database tools, migration tools
What It Shows:
Actual table and column names (following naming conventions)
Specific data types ( VARCHAR( 100), INT, TIMESTAMP)
Index definitions and strategies
Constraint implementation (NOT NULL, UNIQUE, CHECK)
Partitioning strategy for large tables
Replication and backup strategy
Access controls and security rules
💡 Example:
SQL
CREATE TABLE customers (
customer_id SERIAL PRIMARY KEY ,
first_name VARCHAR ( 50 ) NOT NULL ,
last_name VARCHAR ( 50 ) NOT NULL ,
email VARCHAR ( 100 ) UNIQUE ,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ,
INDEX idx_email ( email )
);
CREATE TABLE orders (
order_id SERIAL PRIMARY KEY ,
customer_id INT NOT NULL ,
order_date TIMESTAMP ,
total_amount DECIMAL ( 10 , 2 ),
FOREIGN KEY ( customer_id ) REFERENCES customers ( customer_id ),
INDEX idx_customer_date ( customer_id , order_date )
);
Benefits:
Ready for implementation
Optimized for specific database platform
Addresses performance requirements
Includes security and backup considerations
DBAs can implement with clarity
Limitations:
Cannot be easily migrated to different database
Complex and platform-specific
Takes longest to create and modify
