SMART-DB
Why putting the logic in the database makes every number defensible — and every new capability a change you can govern, version and review.
Six principles that move Oracle licensing intelligence out of application code and into the database engine — where it is faster, deterministic, auditable and far easier to extend.
Single source of truth
Data and logic live together in one PostgreSQL schema. There is no hidden calculation in the app, no duplicated rule, no drift between a report and its backing query.
For your audit: your DBA can reproduce the exact boardroom figure in psql — there is no black box to defend.
Implementation: 001.a–001.r own the schema; the app only calls DB::select().
Multi-tenant by design
Every table carries a username holding the tenant's MD5 identifier, and every function filters on it. A strict role hierarchy — Super Admin > Admin > Client > User — keeps tenants isolated inside a shared database.
For compliance: tenant isolation is enforced at the data layer, so no cross-client leak is possible through the UI.
Implementation: username = login.identifier; sec_check() gates every call; roles S > A > C > U.
Analytics inside the engine
Coverage analysis, effective-processor resolution, edition and option costing, ROI and topology traversal are all PL/pgSQL functions. The heavy lifting happens next to the data, not over the wire.
For finance: one engine means consistent numbers across every report — no reconciliation between spreadsheets.
Implementation: 40+ rdb_calc_*() calculators, os_multiplier(), roi_*(); 80+ functions total.
Reactive by construction
Materialized views join raw inventory to the price list; triggers keep Fusion Middleware mappings consistent when contracts are inserted or deleted. Change the inputs and the analysis stays coherent automatically.
For procurement: change a contract and coverage updates itself — no stale report to chase down.
Implementation: contract_f_insert_trigger / contract_f_delete_trigger; materialized db, fmw_view.
Thin application layer
Laravel controllers do one thing: DB::select("SELECT * FROM schema.rdb(...)"). Business rules never leak into PHP. Swap the frontend, the API, or the language — the engine remains the contract.
For governance: the UI is replaceable; the audited truth stays in one governed place.
Implementation: controllers/services are wrappers only — the logic is in the function, not the framework.
Deterministic, testable SQL
Same inputs, same outputs, every time. Functions can be unit-tested, versioned and code-reviewed like any other source. No opaque agent, no proprietary black box — just SQL you can read.
For risk: every figure is repeatable and reviewable — defensible in front of an auditor or a board.
Implementation: SQL assertions in CI; modules independently versioned.
From bare host to boardroom number.
Raw discovery flows through ingest functions into typed views, is analysed by cost engines, and finally surfaces through a thin rendering layer.
Representative functions
A sample of the public functions the application calls. Internally, more than 130 functions and calculators compose to produce a single report row.
| Function | Purpose | Returns |
|---|---|---|
| rdb(mode, username, location) | Database licence cost: contracted vs deployed, by edition and option | SETOF trr |
| rfmw(mode, username, location) | Fusion Middleware cost and coverage analysis | SETOF trr |
| sdb(mode, username, location, edition) | Simulated “what-if” database deployment cost | SETOF trr |
| roi_db / roi_fmw / roi_os | ROI-* module retrievers for database, middleware and server lenses | ROI rows |
| roots / leafs / max_level | Navigate the Region-DC-Env-App-Group location hierarchy | tree sets |
| os_multiplier(...) | Resolve effective Oracle processors from sockets, cores and core factor | numeric |
| granular_tree(...) | Full hierarchy annotated with cost at every granularity | SETOF trtreecost |
| sec_check(...) | Validate caller permissions before returning tenant data | boolean |
What each engine buys you
| Know what's uncovered | rdb('N', …) | not-covered report |
| Price any option | rdb_calc_opt_* | per-option € |
| See dependency | granular_tree() | drill-down chart |
| Alert on drift | add_alert() | severity inbox |
| What-if the cloud | sdb() | migration business case |
One parameter: A · C · U · O · N
- A — All products, deployed and contracted
- C — Coverage only items with anomalies
- U — Underused contract cost > deployment cost
- O — Overused deployment cost > contract cost
- N — Not covered deployed but no contract
Ordered SQL source
Every function is visible
-- list the engine surface
\df u1.*
-- reproduce a report row
SELECT * FROM u1.rdb(
'C', :tenant, :location
);Filter topofmw by location; refresh materialized db/fmw_view before reporting.
Vendor review vs your own evidence.
Agent-based SAM vs SMART-DB.
Spreadsheet / vendor review
- Position estimated, then defended after the fact
- Weeks to answer a simple coverage question
- Discovery shaped by the vendor's own worksheet
- Data handed outside your perimeter
- Number changes with whoever built the sheet
- No view of migration effort per system
- Extension means another vendor engagement
LMS Cloud
- Per-instance
trrrows, reproduced on demand - Coverage answer in seconds from the engine
- You generate your own deep discovery input
- Self-hosted — data never leaves your perimeter
- Deterministic SQL — same inputs, same figures
- Dependency and effort visible per server/database
- Extend with an ROI-* module your team writes
Typical agent-based tool
- Install a component on every server
- Create a monitoring user in every database
- Requires network access to all hosts
- Vendor review-file driven discovery
- Business logic hidden in the application
- Hard to extend without vendor involvement
- Licence data leaves your perimeter
SMART-DB
- One bash file, built-ins only, nothing installed
- No database users created
- Works in segmented, unreachable networks
- Generates its own deep discovery input
- Logic lives in auditable PL/pgSQL (
rdb()) - Extend by shipping a
module.json - Self-hosted — data never leaves your perimeter
When does the change pay for itself?
Where the compute time actually goes.
Payback is modelled from the same cost rows the coverage report uses — no separate spreadsheet.
A single report row composes ~130 functions; the trace shows the breakdown you can optimise.
Break-even at month 14
Cumulative savings reach €682k by month 24, sourced from payback_history + roi_db/roi_fmw/roi_os.
What drives the curve
- Consolidate 12 underused DBs — mode
U - EE → SE2 for 7 QA databases — edition calculator
- Retire 3 Exadata half-racks — appliance model
- Reclaim unused options —
rdb_calc_opt_*
rdb('C', tenant, location)
payback_history
Each payback run stores snap_id, username, location, total_licensing_cost and total_deployment_cost, so the payback curve and the audit snapshot diff come from the same table.
See how a module plugs in.
The ROI-* module system turns Oracle licensing coverage into something your team can extend without touching the core.