Class LUWDatabasePartition {Analysis} derived from: SQLObject

Documentation
DB2 Universal Database SQL Reference Version 8.1 (Vol.1 and 2)
http://www7b.software.ibm.com/dmdd/library/techarticle/0206sqlref/0206sqlref.html

Usually, a single database partition exists on each physical node, and the processors on each system are used by the database manager at each database partition to manage its part of the total data in the database.

Because data is divided across database partitions, you can use the power of multiple processors on multiple physical nodes to satisfy requests for information. Data retrieval and update requests are decomposed automatically into sub-requests, and executed in parallel among the applicable database partitions. The fact that databases are split across database partitions is transparent to users issuing SQL statements.

User interaction occurs through one database partition, known as the coordinator node for that user. The coordinator runs on the same database partition as the application, or in the case of a remote application, the database partition to which that application is connected. Any database partition can be used as a coordinator node.

DB2 supports a partitioned storage model that allows you to store data across several database partitions in the database. This means that the data is physically stored across more than one database partition, and yet can be accessed as though it were located in the same place. Applications and users accessing data in a partitioned database do not need to be aware of the physical location of the data.

The data, while physically split, is used and managed as a logical whole. Users can choose how to partition their data by declaring partitioning keys. Users can also determine across which and how many database partitions their table data can be spread, by selecting the table space and the associated database partition group in which the data should be stored. In addition, an updatable partitioning map is used with a hashing algorithm to specify the mapping of partitioning key values to database partitions, which determines the placement and retrieval of each row of data. As a result, you can spread the workload across a partitioned database for large tables, while allowing smaller tables to be stored on one or more database partitions. Each database partition has local indexes on the data it stores, resulting in increased performance for local data access.

You are not restricted to having all tables divided across all database partitions in the database. DB2 supports partial declustering, which means that you can divide tables and their table spaces across a subset of database partitions in the system.

An alternative to consider when you want tables to be positioned on each database partition, is to use materialized query tables and then replicate those tables. You can create a materialized query table containing the information that you need, and then replicate it to each node.


Parent PackageLUWAbstractNo
Export ControlPublicAccessLink Class forNone
Class KindNormalClassCardinalityn
Space ConcurrencySequential
PersistenceNo  


Operations
NameSignatureClass
addEAnnotationEAnnotation addEAnnotation (String source)SQLObject
addEAnnotationDetailvoid addEAnnotationDetail (EAnnotation eAnnotation, String key, String value)SQLObject
getEAnnotationDetailString getEAnnotationDetail (EAnnotation eAnnotation, String key)SQLObject
setAnnotationDetailvoid setAnnotationDetail (EAnnotation eAnnotation, String key, String value)SQLObject
removeEAnnotationDetailvoid removeEAnnotationDetail (EAnnotation eAnnotation, String key)SQLObject
getEAnnotationEAnnotation getEAnnotation (String source)SQLObject
getEAnnotationEAnnotation getEAnnotation (String source)EModelElement
eClassEClass eClass ()EObject
eIsProxyboolean eIsProxy ()EObject
eResourceEResource eResource ()EObject
eContainerEObject eContainer ()EObject
eContainingFeatureEStructuralFeature eContainingFeature ()EObject
eContainmentFeatureEReference eContainmentFeature ()EObject
eContentsEEList eContents ()EObject
eAllContentsETreeIterator eAllContents ()EObject
eCrossReferencesEEList eCrossReferences ()EObject
eGetEJavaObject eGet (EStructuralFeature feature)EObject
eGetEJavaObject eGet (EStructuralFeature feature, boolean resolve)EObject
eSet eSet (EStructuralFeature feature, EJavaObject newValue)EObject
eIsSetboolean eIsSet (EStructuralFeature feature)EObject
eUnset eUnset (EStructuralFeature feature)EObject


Attributes
NameClassTypeInitial Value
numberLUWDatabasePartitionint 
descriptionSQLObjectString 
labelSQLObjectString 
nameENamedElementString 


Associations
NameMy RoleMy ClassOther RoleOther Element
--Not Named--partitionsLUWDatabasePartitiongroupLUWPartitionGroup
--Not Named--partitionsLUWDatabasePartitionbufferPoolLUWBufferPool
--Not Named----Not Named--SQLObjectcommentsComment
=--Not Named--SQLObjectdependenciesDependency
--Not Named--objectSQLObjectprivilegesPrivilege
--Not Named--actionObjectsSQLObject--Not Named--Privilege
--Not Named--eModelElementEModelElementeAnnotationsEAnnotation
--Not Named--contentsEObject--Not Named--EAnnotation
--Not Named--referencesEObject--Not Named--EAnnotation
--Not Named--targetEndEObject--Not Named--Dependency


Generalization Relationships
NameClassSupplier
--Not Named--LUWDatabasePartitionSQLObject
--Not Named--SQLObjectENamedElement
--Not Named--ENamedElementEModelElement
--Not Named--EModelElementEObject



Property Settings

Data Modeler
dmItemFalseDMName 
IsTableFalseIsViewFalse
IsDomainFalseIsSPPackageFalse
Synonymns TableSpaceID 
SourceId SourceType 
CorrelationName SelectClause 
IsUpdateableTrueCheckOptionNone
IsSnapShotFalseIsDistinctFalse
PersistToServer IsPackageFalse