How to build a SQL DB based on the existing 3.1/ 4.0 Universe.

[former_member193591]

Is there a way to plan/design a relational database based on the existing Universe design/architecture; Client doesn't want us to migrate to a SQL like based on the existing DB. The joins Alias should be built based on the existing Universe. Can someone please let me know the best option to go ahead! also please let me know the limitation & Advantages in doing so.

If it is possible, please let me know how to start the process??

[Henry_Banks]

Hi,

discussion moved to Semantic Layer.

please could explain what you are trying to do?  trying to reverse engineer a new datasource, based on an old universe? (i've never heard of this)

normally, the db schema is available as a prerequisite from the outset, then the universe is build based on top of this, after captuing the business & reporting requirements .

Regards,

H

[former_member193591]

Yes Henry, new to me as well; The client has an existing DB and Universe; now their DB is messed and they are planning to do away with that; however their universes that are used for reporting are good and they do not want to disturb it;

So if someone designs a new DB, then the schema/architecture would change; this will not work at all for the old unv and they will have again invest in Universe and BO dev along with DB dev; so they wanted to know if we could refer to the UNV architecture/ blueprint and design the DB so that they can continue with existing UNV with few modifications or enhancements.

[Henry_Banks]

well each table in the universe will have a db identifier and a table reference, so that will work to some extent .... providing you recreate everything the same at source.

but they should not be under any illusion that this is normal practice, and given that not all db tables are surfaced into a universe, the list will not be exhaustive, so you're not going to end up with a 'whole' db.

regards,

H

[former_member193591]

Thank you Henry,

Well that's a start! We are at the investigating phase;

Are there any other limitations or risk other than the above mentioned; Given the client's scenario when they want to redo the DB but do not want to recreate or disturb the existing UNV/UNX & Reporting, what are the better approaches that can be suggested to them.

I am sure there can be better approaches other than designing the DB from the existing UNV.

Regards,

Arvind E

[Henry_Banks]

yes effectively!  let's be clear: creating a new database schema from an old universe is the worst starting point ever..  this is not normal so we can't comment on your chances of success

[former_member193591]

Well that's a concrete response Henry; Thank you.

Thank you for your time.

Regards,

Arvind E

[former_member182521]

Hi Arvind,

Though your requirement is logically possible, as Henry rightly said, It is not recommended to create underlying database tables based on your existing Universe structure. There are so many features which you cannot address during the process of reengineering which will leads you to redundancy in your work.

Try with the Universe documenter available here and see if you could do something using this.

http://www.forumtopics.com/busobj/viewtopic.php?t=141886&sid=aee067222dd7a057f8fb94e142f5da51

Regards,

Mani

[former_member193591]

Thank you Mani;

Did speak to the client and we agreed on one situation;

Primarily they now want monitor their ticketing flow and resolution, for which we do have a separate universe and reports built on it;

we have decided to build a separate data mart [Data will be fed by the original DB] based on the existing UNV blue print; now once this is built, we will move the source to the data mart than the original source DB; this might make the situation light.

Is there any limitation on this process; if not is there a best practice to accomplish them.

Regards,

Arvind E