database-design

Design Oracle banking schemas with audit columns, constraints, and DDL templates.

Updated Mar 27, 2026
One-click install
npx skills add https://github.com/minhquan2904/vibe-check-scam --skill database-design-minhquan2904
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: database-design
Source: https://github.com/minhquan2904/vibe-check-scam/tree/main/base_knowledge/standards/base/database-design
Command: npx skills add https://github.com/minhquan2904/vibe-check-scam --skill database-design-minhquan2904

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Banking and data teams struggle to design scalable Oracle schemas that enforce auditability, data integrity, and maintainable structures across modules such as customers, accounts, and transactions.

Core Features & Use Cases

  • Normalization-driven schema design with mandatory audit columns (RECORD_STAT, MAKER_ID, CHECKER_ID, etc).
  • Clear primary key strategies using sequences and triggers, plus guidance on FK relationships and partitioning for large tables.
  • Indexing and performance guidelines tailored for Oracle banking workloads, including when to use composite and bitmap indexes, and how to avoid common anti-patterns.
  • Use Case: Design a robust schema for BO_TRANSACTION and BO_ACCOUNT with consistent auditing and traceability.

Quick Start

Create a first-draft Oracle schema for banking with customers, accounts, and transactions that includes audit columns and example DDL.

Frequently Asked Questions about database-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design an Oracle database schema for banking modules like accounts and transactions?

Design an Oracle database schema for banking by applying normalization, defining primary keys with sequences, and enforcing foreign key constraints across modules like BO_ACCOUNT and BO_TRANSACTION to ensure data integrity and maintainability.

What audit columns should I include in a banking database schema?

Banking database schemas should include mandatory audit columns such as RECORD_STAT, MAKER_ID, and CHECKER_ID to enforce traceability and compliance across customer, account, and transaction tables.

What is the best way to optimize Oracle schema performance for large banking transaction tables?

Optimize Oracle schema performance for large banking transaction tables by applying targeted partitioning strategies, using composite indexes for high-frequency queries, and avoiding common indexing anti-patterns.

Can I generate DDL templates and PL/SQL package scaffolds for a normalized banking schema?

Yes, you can generate DDL templates and PL/SQL package scaffolds that implement recommended Oracle banking designs, including secure object naming, primary key strategies, and foreign key constraints.

When should I use bitmap indexes versus composite indexes in an Oracle banking workload?

Use bitmap indexes for low-cardinality columns in Oracle banking workloads and composite indexes for frequent multi-column queries, avoiding anti-patterns that degrade transaction performance and data integrity.

Does this Oracle schema design approach require specific prerequisites for secure object naming and partitioning?

Oracle schema design for banking requires understanding of normalization, sequence-based primary keys, foreign key relationships, and partitioning to implement secure object naming and scalable structures effectively.