Universe and Data Access enhancements

[dnewton]

Let's start a sticky thread to keep track of suggestions and ideas related to the Semantic Layer (the Universes) as well as Data access from those universes.

Please post replies with your ideas...

[dnewton]

Idea: Better database metadata reuse and support within Designer.

Database tables and columns can have long descriptions or COMMENTs on them in SQL Server, Oracle, and presumably other tables. It would be nice to see this data within the Universe layer. When you drag in a table, you could get not just the list of columns and datatypes, but the metadata too.

Furthermore, when you then drag a table or column over to the left-hand pane to add it to your universe, the object metadata (business terms etc.) should default into the object descriptions.

[dnewton]

Idea: Reusable queries. (This is a grey area between report design and Universe design) I'd like to create a query with complex filtering (WHERE clause) logic, and then reuse that query across 3 separate reports. If I change the single query, all downstream reports would be affected.

This could be hacked by using QaaWS, but I'd like to see it a standalone thing, a sort of "Query Publisher" and then a webi data provider could simply point at a Query and not just a Universe.

[dnewton]

Idea: Make Universe Designer a more object-oriented approach or application.

For example, you might have a field in a table CUSTOMER_DIM.CUSTOMER_NAME. If you could define that column once (pretty name, long description, LOV, etc.), and then reuse and inherit that in all universes, it would make maintenance easier. We have dozens of standard objects that exist in dozens of universes. If we change the description of the object in one place, we have to spend time doing it many other places.

You can do embedded/linked universes, but these are at too high of a grain.

You'd also want your inherited attributes to stick when you aliased a table. Plus have the ability to override that inheritance.

[ajunell]

Allow object and class names to come from a db column or a stored procedure. This would allow them to be dynamic and potentially changed by the end user without having to load up Designer and import/export.

For example, one client might want to call an object 'Employee', but another client might prefer the term 'Colleague'.

[dnewton]

Provide a way to let the Universe layer talk to more than one database/data source. I think this really means baking the Data Federator product into the Universe layer.

[Marek Chladny]

Idea: possibility to reuse once-defined keys for index awareness.

Scenario: I have a dimension table (DT) and a fact table (FT). They are joined via primary key and foreign key. There are many objects defined based on DT.

If I want to set up an index awareness, I need to define keys (primary and foreign) for each of the objects individually. I need to go to Keys tab of properties of each and every object and add keys manually again and again for each object individually.

I would like to have a possibility to define keys between 2 tables once and then to reuse this information for all objects where I need it.

[Dave Rathbun]

But Marek, that won't work. You can't use the same key for anything other than attributes that are unique to the table. If you use a key for a value that is not unique, you get weird LOV results.

I understand where the request is coming from, and in some cases it might work, but it's not guaranteed to be correct. A simple universe like eFashion can demonstrate that.

[Marek Chladny]

[Dave Rathbun]

Yes. Yes, I would.

[itsani07]

Idea : to have an "awareness" functionality on conformed dimensions.

When we have conformed dimensions in a data model, we tend to create aliases for the tables in the schema. Each alias would have to be created as a class to be used with different scenarios.

Instead, if we could have just one class for the conformed dimension and use a kind of @aware(Alias_manualErr.description, AliasEngineerErr.description, Alias_MobileErr.description) and the right column or columns would get picked based on the objects chosen from ManualErr and/or EngineerErr and/or MobileErr tables.

The point here is that these are not measure and need not be aggregated. But to reduce the number of redundant classes that needs to be created based on aliases. Making desinger more intelligent.

[joepeters]

Universe-defined report-level variables. Smart Measures are close, but not quite there.

Improved List View and Context Edit dialog - ability to sort and filter the list of joins by table name.

Ability to sort objects and subclasses in a class.

Auto detection of Aggregate Navigation.

Better SQL editor - syntax coloring, table/column/class windows that don't have to be scrolled on every use.

Merge support - allow multiple developers to work on a universe, then merge changes into a single version.

Get rid of the "Groups" list when exporting!

Ability to store Connections in universe folders, and inherit the parent folder's rights.

Ability to associate universes with preferred Job Servers or Server Groups.

Ability to add a table by name, rather than scrolling through a list.

Direct support for database links.

Define objects to automatically include Predefined Conditions in reports when they are added (giving the user the ability to remove the Condition if so desired).

General PIA fixes - if I'm editing the SELECT of an object, alt-tab away, then alt-tab back, cursor moves to "Name" field and highlights it.

Ability to set which parse warnings are displayed.

Better Help - why, why, why is there nothing in Help about @Prompt syntax?

I could go on

Joe

[dnewton]

[fta]

The advantage would be that you could have schedule queries, and you have multiple reports using the same query.

I remember that in the past you could do something with Impromptu (Cognos). A queryresult (report) could be reused in another report.

[LANFIELD]