Normalizing advantage

Code:
HR_Financial_Hierarchy
ID (HR_BASELINE.PrimaryKey...if any such column for join),
FH_ID Number, (to hold 1,2,3,..10)
FH_Val Number or Varchar2 (wat ever be)
)

HR_EC(
ID (HR_BASELINE.PrimaryKey...if any such column for join),
EC_ID Number (1..7)
EC_Val Number)
then you can query, as below

Code:
SELECT
........
decode(HR_Financial_Hierarchy.FH_ID, 1, FH_Val)FH1,
decode(HR_Financial_Hierarchy.FH_ID, 2, FH_Val)FH2,
........
decode(HR_EC.EC_ID, 1, EC_Val) EC1,
decode(HR_EC.EC_ID, 2, EC_Val) EC2,
decode(HR_EC.EC_ID, 3, EC_Val) EC3,
........
FROM HR_BASELINE, HR_Financial_Hierarchy, HR_EC
WHERE HR_BASELINE.ID = HR_Financial_Hierarchy.ID
HR_BASELINE.ID = HR_EC.ID
........
GROUP BY ................
HR_Financial_Hierarchy.ID, Financial_Hierarchy_Val,
HR_EC.EC_ID, HR_EC.EC_VAL,
...............................
This query will have some performance overhead becoz of joins. But
I think grouping on 10 columns of Financial_Hierarchy_1..10 and &
8 columns of EC1..Ec8 consumes time than grouping 4 columns
HR_Financial_Hierarchy.ID, Financial_Hierarchy_Val,
HR_EC.EC_ID, HR_EC.EC_VAL

And regarding the Block Size, a Single record of HR_BASELINE consumes more than 1 block, that means lot of block overhead with rowchaining. If having a block size which can fit 1 or 2 records in a single block then it will reduce I/O.

If you are accessing 4 rows from HR_BASELINE which means almost
reading 6-8 blocks if u increase the block size you can reduce the
number of blocks need for accessing those same 4 rows.

Hope its a valid point to both normalize and increasing block size of
the tablespace which holds HR_BASELINE table.