Database Overview
PaparcApp uses PostgreSQL as its relational database with a normalized schema consisting of 13 tables. The database is designed to support:- Customer and vehicle management
- Reservation lifecycle (pending → in progress → finalized)
- Dynamic pricing with vehicle coefficients and rate tiers
- Additional services and subscription plans
- Photo evidence and notification tracking
Entity Relationship Diagram
Table Definitions
1. CUSTOMER
Stores customer information with three user types: ADMIN, REGISTRADO (registered), and NO-REGISTRADO (guest).id_customer: Auto-incrementing primary keyemail/phone: Unique identifiers for user lookuppassword_hash: bcrypt-hashed password (NULL for guest users)type: User role (ADMIN,REGISTRADO,NO-REGISTRADO)is_active: Soft delete flag
2. VEHICLE
Stores vehicle information independent of ownership (many-to-many relationship with customers).license_plate: Unique vehicle identifiertype: Vehicle category (TURISMO, MOTOCICLETA, FURGONETA, CARAVANA, ESPECIAL)typeis a foreign key tovehicle_coefficient.vehicle_typefor pricing
3. CUSTOMER_VEHICLE
Junction table for the many-to-many relationship between customers and vehicles.4. MAIN_SERVICE
Defines the three core parking services offered by PaparcApp.- ECO - Walk to terminal (cheapest)
- TRANSFER - Minibus to terminal
- MEET - Premium valet service
5. SERVICE_RATE
Pricing tiers based on service type and stay duration (days).6. VEHICLE_COEFFICIENT
Master table for vehicle pricing multipliers.7. ADDITIONAL_SERVICE
Optional services customers can add to reservations (car wash, refueling, etc.).- CLEANING: Washes, interior cleaning, detailing
- MANAGEMENT: Refueling, MOT service
- MAINTENANCE: Fluid checks, tire pressure
- ENERGY: EV charging
8. RESERVATION
Core table tracking parking reservations with lifecycle management.reservation_date: When reservation was createdentry_date: When vehicle enters parkingexit_date: When vehicle leaves (NULL if not yet determined)status: Current reservation statecod_parking_spot: Assigned parking spot (NULL until vehicle arrives)is_paid: Payment statuspayment_method: TARJETA (card) or EFECTIVO (cash)
9. RESERVATION_ADDITIONAL_SERVICE
Junction table linking reservations to additional services (many-to-many).10. PHOTO_EVIDENCE
Stores file paths for vehicle condition photos (5 photos minimum per reservation).- Front view
- Back view
- Left side
- Right side
- Dashboard
11. NOTIFICATION
Audit log of communications sent to customers.12. CONTRACT_PLAN
Subscription plans for frequent customers.13. CONTRACT
Active subscriptions linking customers and vehicles to plans.Database Relationships Summary
One-to-Many Relationships
| Parent Table | Child Table | Relationship |
|---|---|---|
| customer | reservation | One customer → many reservations |
| vehicle | reservation | One vehicle → many reservations |
| main_service | reservation | One service → many reservations |
| main_service | service_rate | One service → many rate tiers |
| reservation | photo_evidence | One reservation → many photos |
| reservation | notification | One reservation → many notifications |
| contract_plan | contract | One plan → many contracts |
Many-to-Many Relationships
| Entity 1 | Junction Table | Entity 2 | Meaning |
|---|---|---|---|
| customer | customer_vehicle | vehicle | Customers can own/share multiple vehicles |
| reservation | reservation_additional_service | additional_service | Reservations can have multiple add-ons |
Master-Detail Relationships
| Master Table | Detail Table | Purpose |
|---|---|---|
| vehicle_coefficient | vehicle | Vehicle types must exist in master table |
| main_service | service_rate | Rate tiers defined per service |
Indexes Overview
All indexes created for query performance optimization:Constraint Summary
Data Integrity Constraints
- Foreign Keys: 15 foreign key relationships ensuring referential integrity
- Check Constraints: 16 validation rules for business logic
- Unique Constraints: 8 uniqueness requirements (email, phone, license_plate, etc.)
- Not Null Constraints: Critical fields cannot be NULL
Business Logic Constraints
- Reservation Lifecycle: Status transitions must follow PENDIENTE → EN CURSO → FINALIZADA
- Payment Validation: FINALIZADA reservations must be marked as paid
- Parking Spot Assignment: EN CURSO and FINALIZADA require assigned spots
- Date Validation: exit_date must be after entry_date
- Pricing Validation: All prices must be non-negative
- Rate Tiers: No overlapping day ranges for same service
Database Initialization
The database is initialized using 4 SQL scripts:- 01_tables.sql: Creates all 13 tables
- 02_constraints.sql: Adds foreign keys and check constraints
- 03_indexes.sql: Creates performance indexes
- 04_initial_data.sql: Loads seed data (services, rates, coefficients, sample users/reservations)
Connection Configuration
PaparcApp connects to PostgreSQL using a connection pool:- Connection reuse
- Automatic reconnection
- Concurrent query handling
- Connection limits and timeouts
Summary
The PaparcApp database schema is:- Normalized to 3rd Normal Form (3NF)
- Performance-optimized with strategic indexes
- Integrity-protected with comprehensive constraints
- Cloud-ready with SSL support and connection pooling
- Well-documented with inline SQL comments and constraint naming
