When you select a table from the contents pane and select Show Related for that object, the Show Related dialog lists any objects with first-level dependencies on that table. These objects can be: aliases, base tables, databases, indexes, packages, plans, synonyms, tables, table spaces, triggers, views. You can view second-level dependencies by selecting Show Related for each object with a first-level dependency.
Whenever a table is directly or indirectly dropped, all privileges on the table, all referential constraints in which the table is a parent or dependent, and all synonyms, views, and indexes defined on the table are also dropped. If the table space for the table was implicitly created, it is also dropped.
You can not drop a table (available from the Control Center) while a DB2 utility has control of the table space that contains the table.
It is not possible to rearrange or delete columns in a table without dropping the entire table. You can, however, create a view on the table, which includes only the columns you want, in the order you want. This has the same effect as redefining the table.
Dropping a table or view does not change its aliases. The advantage of aliases is that aliases allow you to move data around without needing to modify application code or interactive queries. However, if you move a table or view, you must drop aliases that refer to those tables or views and then re-create them with the new location names.
Dropping a table does not change the base table it was dependent on. An auxiliary table cannot be explicitly dropped with DROP TABLE. An auxiliary table is implicitly dropped when the associated base table is dropped.
Creating, altering or dropping a table can make the database that contains the table inaccessible to other users.
If you drop a table, authorization information that is kept in the DB2 catalog authorization tables is updated to reflect the dropping of the table. Users, who were previously authorized to use the table, or views on it, no longer have those privileges because catalog rows are deleted.
If you drop a table, application packages or plans that use the table are invalidated.
If you drop a table, its synonyms are also dropped.
When a triggering table is dropped, the associated trigger and trigger package are also dropped.
If you drop a table, any views and authorizations based on the table are dropped.
Implications for table spaces: If a table is created and the table space is not specified a default table space having the same name as the table is created by default. If the table is dropped, then the default table space is dropped at the same. You must drop the table before creating a new table with the same name. You must also drop any indexes before you can create any new indexes with the same name as the original indexes.
If you alter a table (available from the Control Center) to add primary keys or foreign keys on a table, you leave the table space in check-pending status, which you reset by running check data utility with the delete error rows option selected (available from the Control Center). When the check data utility (deletes) runs it is not bound by delete rules; rather all deletes cascade to all descendents of a deleted row so a delete might propagate through most of the referential structure. To prevent deletion from more than one table at a time, refer to the topic "Adding referential constraints to existing tables" in the DB2 UDB for OS/390 Administration Guide.