Attribute Parent-Child Relationships

[Guest_imported]

Hello everyone,

Given below is a sample(subset) database structure that iam working on.


Aggrement

Aggrement_No varchar PK FK
Name varchar
Nf_Dues integer
Sanction_Amt decimal
Future_Receivable decimal
Loan_Type varchar FK
Branch_Id varchar FK

LoanType

Loan_Type varchar PK
Loan_Desc varchar

Percentage

Aggrement_No varchar PK
Percentage decimal


Branch

Branch_Id varchar PK
Branch_Desc varchar


If i have to create a project in MicroStrategy and select
Aggrement_no, Nf_Dues, Name, Branch_Id, Percentage, Loan_Type as
attributes can anyone tell me the parent - child relationships
(detailed) i should be doing...

thanks in advance

cur

 

[nlim]

what is the logical business model? Looks like:

type is parent of agreement
percentage is parent of agreement
Name should be an attribute form of agrrement, maybe desc form

branch should be it's own attribute

 

[Guest_imported]

Hello nlim,

Thanks for the reply! But still have problems understanding. Should I make percentage
as parent of aggrement. Remember percentage is not a primary key. One more
thing is these P-C Relationships should be made only on PK in MicroStrategy
or we can use any attribute.

ex. should we set a relation for Nf_Dues even though it is not a PK. I mean can
I say Nf_Dues is child of Aggrement_no.

What i would like to know is should we try to relate all the attributes selected
irrespective whether they are PK (or) not or one should confine to only relating
primary key attributes.

TIA
cur

 

[nlim]

pleasure to help. depends on what your report needs to look like. If percentage is something you report on, for example

percentage branch #accounts
-----------------------------
where percentage between 5 and 7%,

then you should model percentage as parent of account since many accounts can share the same percentage. ie. 1-M for percentage-account.

again if no.of.dues is something you need to report on:

#dues branch #accounts (count the #accounts with different dues), then you need to model #dues as an attribute. if you need to perform calculations on #dues, then you should also add it as a fact.

It's sometimes easier to work backwards from the report, as opposed to working forward from the schema. What are the top 5 reports you need to create? any drilling from these reports?