Auto-updated "control" cubes and entities giving us what cubes, entities etc we have

Krisztina Zappert

At the moment, we only have one set of entities that come pre-built into the system, and that is the time hierarchy. Days, months, years etc.

I propose adding more, control entities, and even cubes to this list. What I think would be beneficial would be:

• entity whose members are a list of all the entities
• entity whose members are a list of all the cubes
• entity whose members are a list of all the rules
• entity whose members are a list of all the data readers
• entity whose members are a list of all the procedures
• (entity whose members are a list of all the users without the need to manually sync every time there is a change in IDP)
• entity whose members are a list of all the screens
• entity whose members are a list of all the capsules (could be in a hierarchy with the previous one)

The code would be their physical names, and the description would be their regular names. These entities would automatically update - so if I change a name of a cube, or create a new cube, they would automatically be added here.

Once these are added, we could easily have attribute cubes for any of these. Every time a new server is created, there could be a new "Cube_Attributes" control cube added to it. Here, one of the entities could be the entity that lists all the cubes, another is an "Attributes" entity. Here, developers could freely add any number of members as entities, and then enter the values as they wish.

Other control cubes that could be beneficial:

• attribute cubes
• basically most things that are currently in the impact analysis
  • cube that tells us what entities are in its structure on version0
  • cube that tells us what data reader an entity is in
  • …
• security cubes
  • security cubes comes with the solution: we could easily have a read/write/none security setting in these security cubes using the user entity (or a permission grouping entity) and the entity listing the cubes (if we wanted to restrict access to cubes), or an entity listing the procedures (so users only see procedures they are allowed to see, even with rights to work in the data model)
  • security cubes spawns every time a new entity, cube etc is created: we could use these to restrict access to cells of a cube or members of an entity (eg. we could have an auto-created security cube for our cost center lv3 entity, and restrict access to John Johnson so he only sees cost center Europe, but not the others)

To have all of this information in entities and cubes would enable us to use the while function in procedures more instead of hard-coding, enabling shorter procedures, less development and maintenance time, and less chance for humar error. It could rapidly decrease development time for any case where we add attributes currently. It could also decrease the development that needs to be done when doing security builds with the new database security possibilities.

Eg.

We have 200 cubes, and 20 of them belong to the solution's "Reports" model. We could have a cube "Cube_Attributes", find the 20 cubes in the Cube_Attributes entity, add a new member to the "Attributes" entity called "Reporting", and flag the 20 cubes with a 1. Then, later, in a procedure, we can cycle through on only these 20 cubes using the while function and selects.