In SSAS, can parent-child DATAMEMBER name be customised - ssas

In a parent-child dimension in SSAS, the datamember is automatically named the same as the parent.
E.g.
Division X Risk Register
Division X Risk Register
Department A Risk Register
Department B Risk Register
Division Y Risk Register
Division Y Risk Register
Department P Risk Register
Department Q Risk Register
I want all the datamembers to be named "Executive Risk Register", as follows:
Division X Risk Register
Executive Risk Register
Department A Risk Register
Department B Risk Register
Division Y Risk Register
Executive Risk Register
Department P Risk Register
Department Q Risk Register
(b.t.w. if the the children also have children, their datamembers must also be "Executive Risk Register").
Can this be done by setting something on the dimension in SSAS or do I have to handle it separately in every MDX query?

Have you looked at Changing the MembersWithDataCaption property in the Parent attribute to "Executive Risk Register"?

Related

How to algorithmically select the appropriate accounts from a tree of accounts

To create an accounting report (such as Income statement/Balance sheet/ Cash flow statement), certain accounts have to be considered, for an income statement we need to consider the revenue, depreciation, cogs, interest, tax,... and so on.
My qestion is for an accounting software to generate the report, there is a critria/algorithm to use to pick the right group. How would this be approached?
surely not enumerating all the possible accounts, since those will just be names, and can be any value,
Enumerating the the tree then? enumerating the right part of the chart of account tree? This implies some rigidity in the initial setup of the tree, making sure every new account falls somewhere in the current tree (Assets/Liabilities/EQuity/Income/Expense)?
For a report like the income statement this is more involved since the income related to operating activities has to be distinguished from investing and financing, can this be distinguished in software simply from examining the right part of the chart of account tree?
Yes, it can be distinguished in software simply from examining the right part of the chart of account tree

SQL Database Design Timesheet Employee vs Crews

First question here so please let me know how to ask the question better if below is unhelpful.
TLDR - Should I have separates employee times tables for employees assigned to crews and those who are not?
I'm trying to design database, following 'Database Design for mere mortals' book, that tracks employees times. I'm trying to replace the weekly timesheets and crew paper sheets (with start & end times for the crew) being used. There are also individual employee weekly timesheets for those not assigned to crews. Also crew sheets sometimes have an asterisk with if someone is sick etc.
There is a relationship of Projects to crews (1:N) and for the individual employee not assigned to crews are assigned to the project.
Employees are assigned to crews, normally 1:1 but headache comes when 1:N.
'Has' Relationships
So at the moment the are different types of crews say A, B, C, D, E.
Crews D & E will just fill in weekly timesheets (project, names and times, so crews D and E will both be on this same project) and the daily sheets don't include times. Sometimes like 10% of the time employees will be on both D & E on the same day.
A, B, C will have daily times on the daily sheet, but if an employee is on crew C these times take precedance over the times on sheets A or B (if they are also on A or B).
The obvious answer to have {employee, datetimestart, datetimeend} won't work as I care where the times have come from (crew, individual if exception to the crew e.g. sick, individual not assigned to a crew).
I can extend to have {employee, crewtype, datetimestart, datetimeend} this doesn't take care of when employee is both on D & E. I can put DE or F in this case?
Then how do I deal with those assigned to the project only?
if I have {employee, crewtype, projectref, datetimestart, datetimeend} the projectref is redudant and can be derived from crewtype when this is not null. Is this a reasonable approach or would having separate tables be better?
EDIT - or should I have one table {crewid, datetimestart, datetimeend} - derive the times for employees from the crew-employee relationship, and have a separate {employee, datetimestart, datetimeend, category} with category saying if exception (e.g sick) or non-assigned individual?
There are a lot of complicated rules in this description. If you want to create a schema that will never break these rules it will likely be a very complicated normalised schema. I would suggest that some of the rules will be best catered for in your application logic.
In terms of how you store the date, remember that you always need to cater for the exception cases, so something that happens 10% of the time, or 1% or one in a thousand still needs to be catered for, otherwise you just cant save the data.
I would tend to design for the most detailed level, which might be employee,crew,project,date,times, and possible also add an allocation column that defaults to 1, but could be 0.5 if the person is half allocated to two crews at the same time.
You could then write queries so that if a person is allocated to a crew, they get the crew time by default unless they have some overridden values, or whatever other rules you need.
Really, this is the sort of iterative modelling you would do with your business users as you tease out the design. Not always easy in a real-world scenario.
Sorry there is no definitive model here, but maybe a few tips to consider that might help along the way. Good luck with it.

SSAS adding a custom attribute member to a cube for reporting

We have a cube with many measures and one of the main dimensions is a 'site' dimension with about a dozen sites.
I've been asked to add a 'site' that is basically ALL the sites.
They don't want the actual hierarchy,
I tried defining the ALLMEMBER attribute but they don't want another hierarchy level, they want an actual attribute member at the same level. They want the whole displayed as another site next to the actual site values
Example:
Right now with the all member attribute I can show
All Sites - 140
+
New York 45
Chicago 60
Boston 35
But what they want is this:
New York 45
Chicago 60
Boston 35
All Sites 140
I'm not sure where to go from here in BIDS. It's not really a named dataset, nor a calculated measure. It's really a custom attribute member.
You can define a calculated Dimension member in your cube calculation script.
You'd need something like:
Create member Site.site.AllSiteCalc AS SUM(Site.site.children,Measures.currentmember)
Once you've processed the cube this should become available in ssms,excel or to use in a query

SSAS hide measure for certain dimension

How to hide measure or a scope if user choose certain dimension or go to certain dimension hierarchy level?
Thanks.
Try something like this in your MDX script:
FREEZE([Measures].[My Measure], [Product].[Subcategory].[All]);
([Measures].[My Measure], [Product].[Product].Members, [Product].[Subcategory].[Subcategory].Members) = null;
Freeze ensures the next statement won't null out the category level totals. The next statement bulls out that measure for the whole product dimension up to the subcategory totals but not above.
Note this is fine for nulling out meaningless numbers but isn't a security feature. A savvy user could do a drillthrough command to get the product level numbers. Or a savvy user could connect in a special way and clear the whole MDX script for his session so he sees the detailed product data.
For a more secure approach:
If you can null out product data for all measures then setup role based security. In dimension data security only grant access to member Subcategory.All only but uncheck visual totals on the advanced tab so that the subcategory grand total is the real total.
Or setup a second slimmed down Product dimension that only has the top levels not the detailed product levels. Then only tie that dimension to this measure group.
Or create a second measure group that does a group by in SQL and joins to the Product dimension only at the Category level. Thus there is no detailed data only rollups. Then with security control whether a used sees the detailed measures or the summary measures.
On measure properties you can set set visible property to false for the measure you want to hide. Another option is to use perspective and choose again what you want to hide or not.

Assigning multiple values to a single planning entity instance

I'm working on a project in OptaPlanner which is close to the nurse roster example. Besides assigning the employees to shifts i also need to assign the employees to small assignments within the shift. The required number of employees that need to be assigned to the small assignments is not an integer it is a rational number , and every employee besides having a skill (that is required by the small assignment) has a performance meter for that skill that is also a rational number.So the employees needed to meet the required number can be variable based on their performance ,and i can't create N different instances of the small assignment and let OptaPlanner assign an employee to it.
Is there a way to create a single instance of the small assignment ,and have something like a list where employees can be added or removed and the required number is changed accordingly based on the performance that the employee has for that small assignment,in other words can the planning variable be a list that contains the employees assigned?