Database Reference
In-Depth Information
Estimating the Cost
When estimating the cost of the solution, a good place to start is by evaluating how many hours you thought each
task would take and multiplying it by the hourly wages you expect to pay. Keep in mind that issues can come up
that could block you from performing your tasks in a particular order or on a particular date. In a perfect world,
everything runs smoothly and works as planned. Nevertheless, as we all know, that is not likely to happen for
the vast majority of solutions. A common way to mitigate this is to add a percentage to the estimated cost. This
additional percentage usually varies between 10% to 20% depending on how risky you feel any given project is in
regard to overruns and changes.
Documenting the Solution Plan
You should have a good idea of what the solution consists of after you have examined the tasks your solution will
entail. By this time, you should know the following:
•
Which tables you need
•
Which type of ETL tasks you need to perform
•
What the name of your cube might be
•
The titles of your basic prototype reports
You can choose to put this information directly in your formal Word document or record it in a simple
spreadsheet. Either way, it should be recorded. This formal or informal document is then used for the creation of
your BI solution. Additionally, this documentation should correspond with what is incorporated into the official
contract, if one is necessary.
Assume that you will make mistakes. Assume that you will miss some items. Assume that some of your time
estimates may be incorrect. In the end, it does not matter that you get everything perfect the first time out. What
does matter is that you learn by your mistakes and become better at creating BI solutions as time goes on.
Let's assume you are going to use an informal Excel spreadsheet to start your solution documentation. You
can add another worksheet to the spreadsheet that you have already been using to document your solution plan.
Make a list of the tables that you think you need to document the data warehouse.
You can start with the name of database itself. Try to stay true to whatever naming conventions you decided
on in the planning throughout the project. For example, in the exercises for this topic, we determined that our
naming convention indicates the object's type followed by the object's name. In this case, we recorded the data
warehouse name as Data Warehouse Publication Sales. Because that title is rather long, we abbreviated it to
DWPubsSales.
To continue this example, we needed a fact table to hold our sales information. Therefore, we listed the fact
table under the name FactSales (Figure
3-23
). Its formal name is the name of the database, followed by the name
of the namespace or schema, followed by the name of the object. Therefore, we listed this in the spreadsheet as
DWPubsSales.dbo.FactSales.
