Proper use of one table in different business areas

Question

Hi
We will be using certain DB tables in several business areas and we are more than one person to define them.
If a table is loaded from the database for each of the business areas it will be numbered 'table 1, 2...' which does't seem very desirable. Also I'd rather define hiearchies only once and for all.
If a table is loaded only once and used for all the business areas all the joins which are necessary in the different business areas are shown. This will be confusing. If one of us considers a certain join unnecessary he might accidentially delete the wrong one belonging to a different business area.
Exporting the business areas including the joins regularly is probably not a great help if afterwards new joins for other business areas were added.(?)
Am I misunderstanding the concept of Discoverer?
How do you handle such a situation?
Advice appreciated
Franziska

Answer 1

Hi Michael, et al,
I'm just planning my EUL and your comments in the last post seem relevant.
My general plan is as follows:
(1) Create a BaseMaster BA which is used to bring and tables/views from the database into disco. The folders in here will be created with "New Folder from database" and be fairly straightforward, with only very simple calculations and no aggregations in calculations. The joins will echo the joins in the underlying database. This is not shared with Users.
(2) Create a CustomMaster BA which contains Custom Folders which consist of various SQL views of the database. The SQL in these may use have some more complex calculations and these calculations may include aggregation. This will not be shared with users.
(3) Create a CentralMaster BA which contains Complex Folders which are assembled from items from the BaseMaster BA and the CustomMaster BA. These folders may include more complex calculations and the calculations may include aggregated items.
(4) Create a number of User BA's. Using Manage Folders, share the relevant Folders from the Central Master.
I've got a few questions relating to this.
(a) Custom Folders based on Folders
It would seem nice to me if it were possible to create Custom Folders which were based on other Folders, rather than Database Views. Then, even if you need a view and a complex transformation of that view in your business area, you still only have one place where the EUL brings that view into disco. My understanding is that this is not possible. Am I right? I suppose there could be an argument that complex transformations should be pushed back to the DBA but it seems reasonable to me that sometimes this sort of thing could be within the remit of the disco admin?
(b) SQL Efficiency
Am I right in thinking that generally a complex folder is usually not much less efficient than using a base folder because the SQL interpreter ends up optimising the SQL?
And a last question which has turned out rather complex - by all means ignore it if you like - it's me getting to grips with the process.
(c) Nested Complex Folders
I presume that if a transformation is needed which would in a normal database environment would need a mainquery and a subquery, then this could be done in a
number of ways (adhering to the above methodology) by:
(i) Get the DBA to write a view which does both mainquery and subquery and then bring into the BaseMaster and then straight into the CentralMaster folder.
(ii) Get the DBA to write the subquery, bring this into the BaseMaster and then implement the mainquery in the CentralMaster.
(iii) Create a Folder in CustomMaster which implements both mainquery and subquery and then bring this into the CentralMaster folder.
(iv) Create a Folder in the CustomMaster which implements just the subquery and then implement the main query in the Central Master.
If you've got this far - thankyou for baring with me.
Perhaps there's something written about this sort of thing or maybe it's just a matter of practice!
Any thoughts on all this would be much appreciated.
Kind regards
Suhada