Databases Reference
In-Depth Information
the database objects and the use cases, roles, or personas that use those objects. This is the difference
between reporting that you've got an abnormal blocking issue with the tables Sales.SalesOrderHeader
and Sales.SalesOrderDetail and reporting that the two use cases for ''Entering a Sales Order'' and
''Approving a Sales Order'' are going to be affected.
If you were following along with the sample tables and created your lists of use cases, classified your
tables by types, and associated your use case to your tables, then you are in great shape to put this
information into a data structure. A data structure like the one shown in Figure 14-6 can be used to build
some meaningful queries. This information becomes even more meaningful when combined with real
data extracted and stored periodically from the DMVs.
Benchmark_Object
Object Id
Benchmark_UseCase_Object_Assn
UseCaseld
Object_Id
Benchmark_UseCase
UseCaseld
PK,I1
PK,FK2,I1
PK,FK1,I1
PK,I1
Object_Type
Object_Name
UseCaseDesc
UpdateRowCount
InsertRowCount
SelectRowCount
DeleteRowCount
Benchmark_Table
Object Id
PK,FK1,I1
FK2
TableTypeld
Benchmark_TableType
TableTypeld
PK,I1
-
TableTypeDesc
Figure 14-6
Figure 14-6 shows the traversal path to get from the database objects that are being benchmarked back to
the use cases that are affected.
By enumerating the use cases in the Benchmark_UseCase table and having the stored number of update,
insert, select, or delete operations for a typical use case such as approving a sales order, you can generate
easy projections when the use case of sales order approval increases or decreases.
You can also use this model to report growth issues in use case terms. Figure 14-7 shows the difference
between reporting the results only in database terms, and folding the use case description into the data
to help provide meaning to the report for external communication.
Figure 14-7
Search WWH ::
Custom Search