Modelling Design issues

[pramodb]

Hello all,

I have this model which was poorly designed with no layers and no tables imported but all Query Subjects made of SQL queries with joins between multiple tables with where clause and that too same tables created across different namespaces to cater to different business scenarios.

As of now, the project is working fine, what can be the drawbacks of such model?

I have listed down some obvious ones.
The basic practice for model design to segment the model into specific sections/layers like Database, Business/Logical, Presentation and/or Dimensional is not followed.
The tables are not imported from the database but, are modified SQLs which result in eliminating Framework Manager's meta-data caching capabilities, and hence overhead on the report server and increase in report runtime.
The calculations and filters(standalone/embbeded) are all defined in the same layer.
CASE conditions are used multiple times which degrades query performance.
Relationships and cardinalities are all defined in the same layer.
Since no layers are present, reusability of the tables does not exist and they have to be replicated multiple times across different query subjects,namespaces.

Any other drawback I am missing out on?
What should have been the best practices to follow to design model?
And, what steps can be taken to change the design now?

thanks in advance.

[cognostechie]

Seems like it was made by someone who was purely a backend guy without knowledge of the concept of modelling.

It would be a better idea to make a new model rather than fixing this one. By the way, what do you mean by layer and namespace. If there are different namespaces, how come there is only one layer?

[pramodb]

By layer i mean there are actually no database, business or presentation layer but all combined in one.

In long run, yes we have to redesign the model but for now time constraints, it doesn't allow.

Can I for now, make database layer and add tables to it and subsequently add business and presentation layers with existing design untouched.

[blom0344]

What good will it do to add more layers on top of a less than ideal concept (to start with) ?  It feels you are a bit too eager to comply to Cognos best practices for the 3 layer concept alone.  I have seen 1 layer concepts functioning very well.   Your arguments  seem to come from case studies, but do you have any substantial 'evidence' to backup that the current model is not worth for production?

What is your goal when you state that the project is performing well at the moment?  Perhaps there is a very valid reason why the model was created the way it is?

[pramodb]

The difficulty I am facing as of now is, if I have to add any new table or make any business logic modification, I have to do it in all the namespaces(which have different business areas like sales, orders etc) which is time consuming.
If there would have been a database layer, I would have simply imported that table and made business logic changes at one place to reflect throughout the model.

The goal is to see if I can make new changes in the model by following the best practices without tampering the current structure as it is already in production so that there is minimum efforts for future changes in new requirements.

[blom0344]

What makes you think you can solve this with - just - adding a database layer?  From your description and the way the model is currently subdivided into namespaces, I conclude that the FM model contains a set of more or less independent submodels entirely based on SQL code. I would therefore expect that adding 1 overall database layer will not help you out. I would at least expect that you need to bring a lot of alias subjects.

Apart from that, you may run into problems resolving the current SQL code in query subjects. The FM model is very flexible, but it is still limited to applying joins/unions. Subselects, inline views etc may need to be resolved as well. It may be quite a challenge and more than just adding layers..

[pramodb]

thanks for replying.
The way I was looking ahead is to make the 3 layers and make new changes in them for future easy maintenance of at least new changes and let the current structure co-exist(untouched). I know this has to be tested, that's why I came here for looking for solutions.
The other way is to redesign the model from scratch which is a long time consuming process.

One other thing I was looking at to know the drawbacks of the current model other than I have listed down.

thanks