com.ibm.db.models.db2.luw
Interface LUWDatabasePartition

All Superinterfaces:
commonj.sdo.DataObject, org.eclipse.emf.ecore.sdo.EDataObject, org.eclipse.emf.ecore.EModelElement, org.eclipse.emf.ecore.ENamedElement, org.eclipse.emf.ecore.EObject, org.eclipse.emf.common.notify.Notifier, java.io.Serializable, org.eclipse.wst.rdb.internal.models.sql.schema.SQLObject
All Known Implementing Classes:
LUWDatabasePartitionImpl

public interface LUWDatabasePartition
extends org.eclipse.wst.rdb.internal.models.sql.schema.SQLObject

A representation of the model object 'Database Partition'. 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.

The following features are supported:

See Also:
LUWPackage.getLUWDatabasePartition()

Method Summary
 LUWBufferPool getBufferPool()
          Returns the value of the 'Buffer Pool' reference.
 LUWPartitionGroup getGroup()
          Returns the value of the 'Group' reference.
 int getNumber()
          Returns the value of the 'Number' attribute.
 void setBufferPool(LUWBufferPool value)
          Sets the value of the 'Buffer Pool' reference.
 void setGroup(LUWPartitionGroup value)
          Sets the value of the 'Group' reference.
 void setNumber(int value)
          Sets the value of the 'Number' attribute.
 
Methods inherited from interface org.eclipse.wst.rdb.internal.models.sql.schema.SQLObject
addEAnnotation, addEAnnotationDetail, getComments, getDependencies, getDescription, getEAnnotation, getEAnnotationDetail, getLabel, getPrivileges, removeEAnnotationDetail, setAnnotationDetail, setDescription, setLabel
 
Methods inherited from interface org.eclipse.emf.ecore.sdo.EDataObject
getInstanceProperties
 
Methods inherited from interface commonj.sdo.DataObject
createDataObject, createDataObject, createDataObject, createDataObject, createDataObject, createDataObject, delete, get, get, get, getBigDecimal, getBigDecimal, getBigDecimal, getBigInteger, getBigInteger, getBigInteger, getBoolean, getBoolean, getBoolean, getByte, getByte, getByte, getBytes, getBytes, getBytes, getChar, getChar, getChar, getContainer, getContainmentProperty, getDataGraph, getDataObject, getDataObject, getDataObject, getDate, getDate, getDate, getDouble, getDouble, getDouble, getFloat, getFloat, getFloat, getInt, getInt, getInt, getList, getList, getList, getLong, getLong, getLong, getSequence, getSequence, getSequence, getShort, getShort, getShort, getString, getString, getString, getType, isSet, isSet, isSet, set, set, set, setBigDecimal, setBigDecimal, setBigDecimal, setBigInteger, setBigInteger, setBigInteger, setBoolean, setBoolean, setBoolean, setByte, setByte, setByte, setBytes, setBytes, setBytes, setChar, setChar, setChar, setDataObject, setDataObject, setDataObject, setDate, setDate, setDate, setDouble, setDouble, setDouble, setFloat, setFloat, setFloat, setInt, setInt, setInt, setList, setList, setList, setLong, setLong, setLong, setShort, setShort, setShort, setString, setString, setString, unset, unset, unset
 
Methods inherited from interface org.eclipse.emf.ecore.ENamedElement
getName, setName
 
Methods inherited from interface org.eclipse.emf.ecore.EModelElement
getEAnnotations
 

Method Detail

getNumber

int getNumber()
Returns the value of the 'Number' attribute.

If the meaning of the 'Number' attribute isn't clear, there really should be more of a description here...

Returns:
the value of the 'Number' attribute.
See Also:
setNumber(int), LUWPackage.getLUWDatabasePartition_Number()

setNumber

void setNumber(int value)
Sets the value of the 'Number' attribute.

Parameters:
value - the new value of the 'Number' attribute.
See Also:
getNumber()

getGroup

LUWPartitionGroup getGroup()
Returns the value of the 'Group' reference. It is bidirectional and its opposite is 'Partitions'.

If the meaning of the 'Group' reference isn't clear, there really should be more of a description here...

Returns:
the value of the 'Group' reference.
See Also:
setGroup(LUWPartitionGroup), LUWPackage.getLUWDatabasePartition_Group(), LUWPartitionGroup.getPartitions()

setGroup

void setGroup(LUWPartitionGroup value)
Sets the value of the 'Group' reference.

Parameters:
value - the new value of the 'Group' reference.
See Also:
getGroup()

getBufferPool

LUWBufferPool getBufferPool()
Returns the value of the 'Buffer Pool' reference. It is bidirectional and its opposite is 'Partitions'.

If the meaning of the 'Buffer Pool' reference isn't clear, there really should be more of a description here...

Returns:
the value of the 'Buffer Pool' reference.
See Also:
setBufferPool(LUWBufferPool), LUWPackage.getLUWDatabasePartition_BufferPool(), LUWBufferPool.getPartitions()

setBufferPool

void setBufferPool(LUWBufferPool value)
Sets the value of the 'Buffer Pool' reference.

Parameters:
value - the new value of the 'Buffer Pool' reference.
See Also:
getBufferPool()