Databases Reference
In-Depth Information
IdentifyingCoreUse-CaseThroughput
Throughput is the measurement of the number of rows input into each entity as the result of a defined
use-case. If you have the metrics for this type of information, you can monitor the performance of the
database in terms that management understands. How many times are you asked what will happen if
two new customers are added to the system? If you know the use cases that the customers will be per-
forming and an instance count, you should be able to provide immediate sizing and performance impact
information. If something performance-based is affecting the system, you should be able to identify
proactively the use cases that are going to be the most affected. You can do these things if you have core
use cases and associate them to the tables in the schema.
If you are involved in the beginning with the database design, keep track of the core use cases. First,
understand what the system is supposed to do. Then identify the core tasks that are architecturally
significant from a database perspective. If you are examining a rating engine, the tasks of creating rate
structures and using rate structures in calculations are the most architecturally significant tasks for the
system. These core use cases are the reason that the system was created in the first case. Creating the
master data entities is important, but this activity is not the essence of a rating system. Once you examine
the core use cases and enumerate them, store this metadata in your database as well. To have this
data available for later benchmarking processes, gather this type of information for core use cases.
Table 14-3 shows an example of mapping use cases to database operations. In the table, each use case may
be represented by multiple database operations, for example, the use case entering a sales order requires
the insertion of 1 SalesorderHeader, and many sales order detail records. In the table, the number of
inserts is shown as 3, which in the case of the example is the average number of detail records inserted
for each header.
Table 14-3: Identifying Use Cases and Table Usage
Use Case
Database Object
Update
Insert
Select
Delete
Entering a sales order
Sales.SalesOrderHeader
0
1
0
0
Sales.SalesOrderDetail
0
3
0
0
Approving a sales order
Sales.SalesOrderHeader
1
0
0
0
Running a sales report
vSalesPersonSalesByFiscalYears
0
0
2000
0
The first use case is entering a sales order. When this activity occurs, you may expect one row to be
inserted into the SalesOrderHeader table and an average of three rows to be inserted into the SalesOr-
derDetail table. The second use case of approving a sales order only involves a single update to the
SalesOrderHeader. If the stored procedures and views that are involved in these use cases were known,
then they would be entered here as well. The last use case is running a report that should result in select-
ing an average of 2,000 rows from the vSalesPersonSalesByFiscalYears view. You could also add the
component tables to the use case that make up the view for even better tracking of resource usage.
If we were to enter the use case of adding a product, we would be looking at many more inserts and
updates, but the point is to know your core use cases. This information is useful if stored as metadata
Search WWH ::
Custom Search