The table is a logical structure, visible to SQL statements as a single whole.
Partition A
Partition A contains an exclusive subset of the data in Table A. The data in Partition A is not repeated in other partitions.
Partition B
Partition B contains an exclusive subset of the data in Table A. The data in Partition B is not repeated in other partitions.
Partition C
Partition C contains an exclusive subset of the data in Table C. The data in Partition C is not repeated in other partitions.
Why Partitioning is needed
Partitioning addresses key issues in supporting very large tables and indexes by letting you decompose them into smaller and more manageable pieces called partitions. SQL queries and DML statements do not need to be modified in order to access partitioned tables. However, after partitions are defined, DDL statements can access and manipulate individuals partitions rather than entire tables or indexes.
This is how partitioning can simplify the manageability of large database objects. Also, partitioning is entirely transparent to applications.
Each partition of a table or index must have the same logical attributes, such as column names, datatypes, and constraints, but each partition can have separate physical attributes such as pctfree, pctused, and tablespaces.
Partitioning is useful for many different types of applications, particularly applications that manage large volumes of data. OLTP systems often benefit from improvements in manageability and availability, while data warehousing systems benefit from performance and manageability.