Topic: How 3 facts?

All greetings!
All I plunge in DWH further and here ripened a question under one project...
There is a financial organization which gives credits, in system there is such concept as the Request, it is the first fact, it has the measurement with attributes, further if the request is accepted there is a Contract, it is the second fact, it too has measurements with the attributes (certainly they have the general of type the client, the worker, date etc.), goes further the table of payments, is 3 fact, a question in that as all it to connect?
The contract mandatory has a request connected to it, at the contract request can not be (refused for example and the contract is not reached), payments is traced in a source under contract number.
If to carry out in Dimensioanl the table the Contract or the Request that to the sizes it there will be as the fact though in a source both that and that are permanently updated, in particular not closed contracts (for example at them the status and some other  changes).


Re: How 3 facts?

I will add that business reports in a section as requests and Contracts and together interest.
I.e. for example the total of the arrived requests and the total of the concluded contracts (i.e. I made an application y 100 000, it accepted, but gave only 90, the request will have a status acepted and the total 100, at the contract the status active and the total 90) I need to add this difference at to learn how many we all not "" to clients, in a section of date, the country etc.
Also the contract too can be not concluded, i.e. the request acepted, there was a contract, but the client changed the mind, the contract will be voided.


Re: How 3 facts?

And still I will add that there is a fact sending , in it there is a type , the status, Request and date number.
I.e. 3 facts are connected under request number (, the Request, the Contract) and one under number of the contract (payment)


Re: How 3 facts?

The facts match through measurements. If you want, you can drag the surrogate key of the request to the last fact what to see under what requests there was a payment.


Re: How 3 facts?

The colonel.;
It is clear that not directly, a question through what measurement?
To make separate measurement the request, and to add id requests to all facts but then this measurement will be  big since there is a heap of requests which have been rejected also the client entered the data again, i.e. kol-in Contracts it is % 5, or such measurement is normal?
If to make so then in the fact (we lower other measurements) FactApplication - ., id requests, the total and other., in DimApp it , but these attributes are faster to the fact concern, type id customer or id the manager, what then remains in DimApp?


Re: How 3 facts?

It is not important that big. The resultant request will quickly fulfill. Garbage requests on which contracts could not be dumped in the separate garbage fact table, it too is normal. But the reference manual with id requests all the same should be one.


Re: How 3 facts?

The colonel.;
ok, thanks, I will try.
Then still the question, turns out here will be only id requests, in it Dim? Since all attributes of the request, date type, id customer, id the manager, the status, a cause of a failure (if 0 it is not refused, more than 1 that is the code of a failure and separate Dim to the reasons) and other will be in the fact?
Concerning "the garbage" fact table as a variant, I thought what to do with mountain of requests where the client incorrectly entered easier something and tried again, they can be selected on the failure code, but it is necessary to leave too since the analysis and on them is necessary including.


Re: How 3 facts?

Can not only ID to hold there,  ID the bound reference manuals, date, still, that there at you. Sometimes it gains on debugging of scripts of loading what quickly to select the necessary records from the reference manual. Do not feel sorry for a place on a disk, double the data if it is necessary. In data model in the facts if you select on clients the client should be the separate reference manual. Or here there are cities in them clients what quickly to select the facts on cities, it is necessary in the fact table in which there is only a client to add a city, pulling out it from a sheaf a city-client, and the client from a city to untie or leave but then there will be two cities, one as the reference manual. Another to sit in hierarchy of the reference manual the client.