Bob's SQL Reporting Services Blog : Model Design

Localizing a report model

bobmeyers — Tue, 28 Apr 2009 02:15:00 GMT

Reports and report models can be localized at many levels. Following are some ideas around the current support in SQL Server 2008 for each type of localization.

- Localized metadata at report design time

o Example: Spanish report author sees “Cliente” instead of “Customer” in model explorer

o Report models do not support multiple languages for metadata names in a single model file

o It should not be difficult to build a custom solution to generate localized versions of the model file

§ Original .smdl file + XML file with localized entity/attribute/role names => localized .smdl file

§ Could use either XSLT or minimal code

o If implemented, reports would run against any localized version of the model because IDs are unchanged

o Metadata displayed in the report (such as column labels) would be in the language of the person who designed the report. Since they are merely text values copied in from the model explorer, they would not change at report run time.

- Localized metadata at report run time

o Example: Spanish report consumer sees “Cliente” instead of “Customer” in report column label

o SQL RS reports do not directly support localization of text labels in a report

o Some customers have implemented this using a custom “resource” assembly deployed on the server, and all labels in the report are replaced at report design time with expressions that retrieve the appropriate resource string from the custom assembly (sample)

o This is obviously cumbersome to set up at report design time, but it does work

- Localized data formatting at report run time

o Example: Spanish report consumer sees numeric and date values in the report data formatted as “1.234,56” and “27/04/2009” instead of "1,234.56" and "04/27/2009".

o This is supported by the default number formats available on the ribbon in Report Builder 2.0. In the dialog box, select the “Use regional formatting” checkbox.

- Localized data values at report run time

o Example: Spanish report consumer sees product category “Bicicletas” instead of “Bicycles” in report data

o This is typically done by storing localized values in the database as separate columns or as lookup tables based on user culture.

o Offhand I can’t think of a slick way to do this with report models. If you have some ideas, let me know.

Considerations for a large report model

bobmeyers — Mon, 27 Apr 2009 23:58:00 GMT

Customer report models that vary in size from a few to a few hundred entities. Little Northwind with its 10 or so entities comes in around 200K, but we've seen models a hundred times that size (over 20 MB). One of the key drivers of model size is the constraint that you cannot build a query across multiple models, so the tendency is to pull more and more data into the "main" model.

Given that, I thought I’d share a few tips that may help if you want to build, deploy, and use a large report model.

1. Configure the report server allow upload of large files. By default ASP.NET limits the file upload size to 4 MB. You will need to modify this setting if your model exceeds the limit.

2. Consider removing the diagrams from the DSV. Typically the diagrams in a DSV account for ~20% of the uploaded model size. This information is only used by Model Designer, however, so removing it will not affect either the report server or a client like Report Builder. The DSV editor will not allow you to remove the default “<All Tables>” diagram, and if you do remove it, the editor will recreate it with a default layout the next time you open the file, so you will need to remove this diagram from the XML manually before publishing.

3. Define perspectives in the model. Perspectives allow users to self-select a convenient subset of the model at the time they design the report. This reduces download time (only the subset is retrieved by Report Builder) as well as clutter during the design experience. In extreme cases, you may want to require users to choose a perspective. Note that perspectives are not a security feature. Also note that it is possible, though not particularly easy, to change the perspective used in a query after the query has been created.

4. Use model item security. This reduces the subset of the model available to specific users and groups, which in turn reduces the download time and visual clutter for those users. Note that as of SQL 2008 report subscriptions are not supported when using model item security.

If you are using a large report model and have additional tips or questions, please contact me. We'd love to get your feedback.

A better way to model inheritance

bobmeyers — Thu, 05 Mar 2009 18:00:00 GMT

I've been playing around with a report model we use internally here in the SQL Server product group. At a conceptual level, the data being modeled makes heavy use of inheritance (EntityA "is a" EntityB), but in working with the model and with Report Builder, I'm finding some significant advantages to using the Role.ExpandInline property instead of the Entity.Inheritance property. As I described in an earlier post, both are options for denormalizing or "flattening" the underlying schema.

How to do it

Using the Role.ExpandInline property to model inheritance is just as easy as, if not easier than, using the Entity.Inheritance property. Remember that when a relationship is defined in the DSV between the parent entity and the child or derived entity, a pair of roles are generated in the model initially and bound to that relationship.

When using Entity.Inheritance to model inheritance, you need to:

Delete the generated roles
Set the Inheritance property on the child entity to point to the parent entity
Set the Inheritance binding property to the relationship defined in the DSV

When using Role.ExpandInline to model inheritance, all you need to do is:

On the child->parent role, set ExpandInline=true.
On the parent->child role, rename the role "As <child entity name>".

Also, make sure the child->parent role has Cardinality=One, and the parent->child role has Cardinality=OptionalOne. These should be true regardless of whether you choose to expand the role inline.

Advantages of using Role.ExpandInline

Beyond the initial convenience in expressing an inheritance relationship using Role.ExpandInline, there are several more substantial advantages I see to modeling the concept this way:

1. You can choose where the ancestor entities' fields appear in the field list of the current entity.

When using Entity.Inheritance, all ancestor fields are automatically inserted at the top of the field list of the child entity. The main problem with this is that the auto-generated Count field for the derived entity is no longer at the top of the list where users expect it to be. Instead, they will see the Count field for the most distant ancestor first, with the Count fields for the intervening entities and finally the current entity scattered further down the field list.

When using Role.ExpandInline, you can move the role that represents the inheritance to at any position in the field list of the current entity (even a sub-folder if that makes sense), and the ancestor entities’ fields will be inserted there.

Example: Suppose we have a Person entity whose field list starts with #Persons (typical). Suppose we also have an Employee entity that inherits from Person. Ideally, the Employee field list will be displayed as #Employees, followed by Person fields, and finally other Employee fields. When using Entity.Inheritance, this is not supported. When using Role.ExpandInline, this is easy – simply move the Employee->Person role immediately below the #Employees attribute in the Employee entity field list, and the Person fields will be “expanded inline” there.

2. You have fine-grained control over which of the parent entity's fields are visible in the current entity.

When there is more than one derived entity, it is common for many fields on the parent entity to be relevant to only some of the child entities. If Entity.Inheritiance is used, there is no way to prevent all parent entity fields from being shown all the time. This can be confusing in the cases where they are irrelevant.

When using Role.ExpandInline, you can use the HiddenFields collection on the role that represents the inheritance to control exactly which fields from the parent entity will be visible in the child entity.

Example: Suppose the Person entity mentioned above has three derived entities: Employee, CustomerContact, and VendorContact. It also contains (among other things) a #Persons field and a LastContacted field. The former is relevant to all Persons, but only when they are being treated as Persons. When treated as a derived entity, the derived entity Count field should be used instead. Also, suppose the LastContacted field is present on Person because it is common to CustomerContact and VendorContact, but it is not relevant to Employee. Ideally, the #Persons and LastContacted fields would be omitted in the Employee field list, while only the #Persons field would be omitted from the CustomerContact and VendorContact field lists. When using Entity.Inheritance, this is not supported. When using Role.ExpandInline, this is easy – just use the Role.HiddenField collection in each child entity to define exactly which parent entity fields are hidden in that context.

3. You have fine-grained control over which non-direct ancestor entities related by inheritance (“uncles”) are accessible from the current entity.

When using Entity.Inheritance, you can use the Entity.DisjointInheritance property to control whether the special “As <entity-name>” pseudo-roles are displayed for treating instances of the current entity as instances of a non-direct ancestor entity related by inheritance. However, this is an all-or-nothing option. If DisjointInheritance is false, all non-direct ancestor entities related by inheritance are displayed in all child entity contexts; if true, none of them are displayed in any child entity context.

When using Role.ExpandInline, you can use the Role.HiddenFields collections to define exactly which inheritance roles from the parent entity are hidden in for each child entity context.

Example: Suppose that by company policy, Employees were allowed to be customers, but not vendors. On the other hand, it was perfectly fine for non-employee vendors to also be customers. Because of these constraints, it would make sense to display an “As CustomerContact” role in the Employee context, but not “As VendorContact”. In contast, we would want to display an “As CustomerContact” role in the VendorContact context. When using Entity.Inheritance, this is not supported. When using Role.ExpandInline, this is easy – just use the Role.HiddenFields collections in each child entity to define exactly which inheritance roles from the parent entity make sense in that context.

4. You can prevent the fields of all descendant entities from being added to the field list for the current entity.

When using Entity.Inheritance, the fields from all descendant entities are always inserted at the bottom of the field list of the current entity. Even with only a small number of derived entities, the field list can quickly become quite long and confusing, since there is no clear indicator which fields are associated with which derived entity. The list may even contain multiple fields with the same name (but different meanings), which would be especially confusing.

When using Role.ExpandInline (on the role from the child entity to the parent entity), the reverse role from the parent entity to the child entity is just a role by default, so none of the fields for the child entity appear in the parent entity context. For clarity, you can rename the reverse role “As <entity-name>”, similar to the pseudo-roles metioned earlier.

Example: Continuing the examples above, the Person->Employee role should be renamed “As Employee”, the Person->CustomerContact role should be renamed “As CustomerContact”, and the Person->VendorContact role should be renamed “As VendorContact”.

5. You can inherit from more than one entity.

When using Entity.Inheritance, you can specify at most one parent entity related by inheritance. This is often not an important limitation, but occasionally the data really demands that an entity inherit from more than one parent entity, because it just makes a lot more sense to present it to the user that way.

When using Role.ExpandInline, there is (obviously) no constraint on how many roles can be expanded. Inherit from as many entities as you want.

Example: Suppose the Employee entity inherits from both Person and ProjectResource. When using Entity.Inheritance, this is not supported. When using Role.ExpandInline, this is easy – just expand both roles.

6. You can change your mind later about which relationships to model as inheritance.

When using Entity.Inheritance, the queries generated against your model contain no explicit navigation between entities related by inheritance. This means that adding or removing inheritance later can break existing queries. Now, technically, adding inheritance later will not break queries if you keep around the old role that the inheritance replaced (hidden of course to avoid confusion). But there is no workaround for the opposite situation – if you want to remove inheritance later, you can certainly add a new role to represent the relationship, but if you keep around the inheritance as well to avoid breaking existing queries, there is no way to hide it, and the resulting behavior will be very confusing to users.

When using Role.ExpandInline, you can change your mind at any time. The queries will be the same whether you choose to expand the role or not, so modeling a relationship as inheritance (or not) will have no impact on either new or existing queries.

Disadvantages of using Role.ExpandInline

At this point, I can only think of one disadvantage to using Role.ExpandInline to model inheritance.

1. Users will not have the “Is A” operator available in the filter dialog.

When using Entity.Inheritance, a special “Is A” filter operator is available in the filter dialog when filtering on entities that participate in inheritance relationships. This operator allows you to test whether a particular instance of one entity maps to an instance of another entity related somehow by inheritance. Direct ancestors are not included in the list of options, as it is assume answer is always “true” in those cases. However, descendents and non-direct ancestors (uncles, cousins, etc.) are listed.

When using Role.ExpandInline, this operator is not available. Instead, the user would need to add the related entity and check if it is “empty” (or null).

Example: Suppose the user wants to create a filter condition that tests whether a particular Person is also a VendorContact. When using Entity.Inheritance, the user could use the “Is A” filter condition operator to do so. When using Role.ExpandInline, the “Is A” operator would not be displayed. The user would have to drag in the “As Vendor Contact” role instead, and check if it is empty (or null).

Conclusion

As you can see, there seems to be a clear winner here. So much so, that we are considering deprecating the current Entity.Inheritance construct in a future release, and creating a new construct that explicitly models inheritance similar to the ExpandInline approach. When/if we do this, we would presumably also remove the one current disadvantage associated with it by adding explicit support for it in the filter dialog.

Creating a role to one of several related items

bobmeyers — Thu, 21 Dec 2006 03:43:00 GMT

I call this the Primary Address problem, because a classic example is when you have a Customer table and an Address table, and each customer can have many addresses (Primary, Billing, Shipping, etc.), but no more than one of any given type. If you have a FK constraint defined, the report model wizard will automatically detect the 1:* relationship and create an OptionalMany role from Customer -> Address (and an OptionalOne role coming back). However, this still doesn't make it easy to create a report showing Customers and their Primary Address information. What you really want is a separate 1:1 relationship for each type of address, so you can pull in address information without making Address the primary entity of your report.

The best way to do this I know of is like so:

Add calculated fields in the DSV to the Customer table for each type of address, called "xxxAddressType". Each calculation should be a constant (e.g. 'PRI', or whatever the values in your AddressType field are).
Define a unique constraint on the Address table by opening the DSV in code view (XML). Find the primary key constraint for the Address table, insert a copy immediately after it, set msdata:PrimaryKey="false" on the new one and add xs:field elements for the CustomerID and AddressType fields. You have to do this in code view because you can't define non-PK unique constraints in the DSV editor.
Create relationships in the DSV (using the editor again) from Customer to Address that join CustomerID=CustomerID and xxxAddressType=AddressType.
Create roles in the report model from the Customer entity to the Address entity. Bind the roles to the new relationships you just defined in step 3.

[UPDATE] For reference, here's an example of defining a unique constraint (step 2). In the DSV, find the primary key constaint on the same table, which should look something like this:

<xs:unique name="Address_Constraint1" msdata:ConstraintName="Constraint1" msdata:PrimaryKey=true">
<xs:selector xpath=".//Address" />
<xs:field xpath="AddressID" />
</xs:unique>

Then make a copy, and modify it like this:

<xs:unique name="Address_Constraint2" msdata:ConstraintName="Constraint2" msdata:PrimaryKey="false">
    <xs:selector xpath=".//Address" />
    <xs:field xpath="CustomerID" />
    <xs:field xpath="AddressType" />
</xs:unique>

Evolving your report model over time

bobmeyers — Thu, 28 Sep 2006 21:30:00 GMT

Many factors combine to make report models highly likely to change and evolve over time. Sometimes the underlying schema changes. Sometimes new stuff is added. Sometimes you just want to improve how the schema is presented to users. Report models are designed to accommodate just these kinds of changes.

One of my earlier posts mentions several changes you can make to your models without breaking reports, as well as one that will break reports. Generally speaking, though, I believe you can change anything except the following in a report model, and existing reports will still run:

Entities: ID and Inheritance properties

Attributes:.ID, DataType, and IsAggregate properties, and entity membership

Roles: ID and Cardinality properties, entity membership, related role and its cardinality and entity membership.

Note that if you change attribute expressions, entity/attribute/role bindings, or the definitions of tables and columns in the DSV (e.g. by modifying a Named Query), you may get different results, but the reports will still run.

Obviously, you can organize and re-organize things in and out of folders as often as you want, and all your existing reports will still load and run just fine.

Also, if you want to "deprecate" a field, you can use the Hidden property to exclude it from the design-time experience in Report Builder. This will not affect existing reports.

Creating a report model that can be used against multiple databases

bobmeyers — Thu, 28 Sep 2006 21:20:00 GMT

Sometimes it is useful to create a report model that can be used against multiple databases that have the same structure, but reside on different servers and/or have different schema qualifiers.

Uploading a second copy of a report model and pointing it at a different database is certainly easy enough, but you can run into issues if the second database has different schema qualifiers. The problem is that, by default, the Data Source View wizard creates a DSV that includes schema qualifiers in the bindings. If those qualifiers are not necessary (i.e. the bindings can be fully resolved if a default database is specified in your data source connection string), you can make your report model work for the second database by opening the .dsv file in a text editor and use Find/Replace to simply remove all the schema qualifiers.

Test it out against the old and new databases, and you should be good to go.

How to create a 'company' security filter for a hosted application

bobmeyers — Sat, 25 Mar 2006 04:02:00 GMT

Several customers have asked how to restrict data visibility in a report model for a hosted application, where every table has a "CompanyID" column, and every user that accesses the system is associated (via some other table) with exactly one company. The straightforward solution is to create a security filter on each corresponding entity; the filter should check whether any rows exist in the user table entity where Users.CompanyID=This.CompanyID and UserTable.UserID=GETUSERID(). This will work, but the SQL that is generated for this filter may not be optimal.

~~An alternative is to modify the DSV for the report model such that each table containing a CompanyID is really a named query of the form:~~

~~SELECT t.*, u.UserID FROM MyTable t, UserTable u WHERE t.CompanyID = u.CompanyID~~

Note that this derived table contains n rows for each row in MyTable, where n is the number of users associated with that row's company. To effectively fool the model, you will need to lie in the DSV and claim that the primary key of your derived table is composed of only the key columns for MyTable.

You must then create a security filter on the corresponding model entity for MyTable, which simply states UserID = GETUSERID(). If you create any other security filters for that entity, they MUST contain the same filter condition, in addition to any other conditions. No user should be given access to all the rows of that entity.

~~This approach, while a bit of a hack, should result in much better SQL at runtime.~~

~~Credits to my illustrious colleague~~ ~~Chris Hays~~ ~~for coming up with this.~~

UPDATE: The alternative proposed above does not work correctly in all cases because of an optimization we do in the SQL translation layer. Best practice is to stick with the "straightforward solution" described at the beginning of the post.

Collapsing a many-to-many relationship in a report model

bobmeyers — Fri, 24 Mar 2006 21:51:00 GMT

Often a many-to-many relationship exists between two entities where the intermediate entity has nothing on it except the connecting roles. For example, it might be that an Employee can be assigned to many Regions, and each Region can have many Employees assigned to it, but there is nothing interesting about an Employee Region (the intermediate entity).

In such cases, you can effectively hide the intermediate entity from your users by doing something like the following, where the three entities involved are A -< B >- C:

1. Rename the role from A to B as "Cs"
2. Rename the role from C to B as "As"
3. Set ExpandInline=True on the role from B to C
4. Set ExpandInline=True on the role from B to A
5. Add the role from B to A to the HiddenFields collection of the role from A to B
6. Add the role from B to C to the HiddenFields collection of the role from C to B
7. Set Hidden=True on entity B
8. Set Hidden=True the # Bs attribute (or just delete it)

Once you've done this, entity B is effectively hidden from the user. The only exception will be in the Formula dialog, where if the user displays the expanded formula for a field related via this path, the individual roles from A to B and B to C will be displayed. Other than that, as far as a Report Builder user can tell entity B does not exist.

Report model denormalization: Why, How, and When

bobmeyers — Fri, 20 Jan 2006 02:50:00 GMT

Relational databases are often heavily normalized to improve performance, reduce storage requirements, and ensure data consistency. While performance may be relevant to report execution, neither of these reasons is relevant when presenting the schema to an end-user at design time. Hence denormalization is often a major feature of a well-designed SQL Server 2005 report model.

There are three ways of denormalizing the database schema in a report model to provide more intuitive experience for your end users. They are: entity inheritance, role expansion, and lookup entities.

Entity Inheritance
This type of denormalization should be used when one entity "is" another entity. For example, a Sales Person "is" an Employee, so users would like to see all the attributes and roles of an Employee whenever they navigate to Sales Person. It is also true at report design-time that any given Employee may also be a Sales Person, so the user may also want to see all attributes and roles of Sales Person whenever they navigate to Employee, just in case. In this release, Report Builder will always show the attributes and roles of all entities that are either direct ancestors of the current entity or direct descendents. Uncles, aunts, cousins, etc. are displayed only in the Advanced Explorer mode as special related nodes in the "Entities" panel of the explorer.

Entity inheritance is specified by setting the Inheritance property on a derived entity to point to its "parent" entity, and specifying the foreign key constraint in the underlying DSV that can be used to match up a derived instance with the correct instance of the parent. Note that model generation will initially create a Role to represent this relationship, and if you choose to use inheritance, you should delete the auto-generated role. More information on entity inheritance.

Specifying inheritance where none was specified previously will not break existing reports; doing the opposite will. Obviously, deleting the role that inheritance is meant to replace will also break existing reports. If this is an issue, consider hiding the deprecated role so it will cease to be displayed, but continue to function for existing reports.

Role Expansion
This type of denormalization should be used when an entity contains information that is really considered part of a related entity, but for purely storage-related reasons has been moved into a separate table. Two examples are sparse satellite tables (e.g. AdditionalCustomerInfo) and shared schema tables (e.g. ContactInfo or AddressInfo). In both cases, the table doesn't represent a separate "thing" in the user's mind. It's just a bunch of extra attributes. When Report Builder encounters a role on the current entity that is marked for inline expansion, it displays all attributes and roles of the related entity as if they were attributes and roles of the current entity.

Role expansion is specified by setting the ExpandInline property on a role to True. Note that for shared schema tables (e.g. ContactInfo), you should also use the HiddenFields property on the role to hide the roles to other entities that use the same schema.

Changing the value of the ExpandInline property will not break existing reports and thus may be done at any time.

Lookup Entities
This type of denormalization should be used when an entity corresponds to a "lookup" table, i.e. one that exists only to define a set of valid values for some column on another entity or entities. Classic examples of lookup tables are Country, Status, Category, etc. Note that lookups often come in a series (e.g. Subcategory->Category), often referred to as a hierarchy. When Report Builder encounters a role whose related entity is a lookup entity, it displays the identifying attribute of that entity as if it were an attribute on the current entity. If any roles on the lookup entity are marked for lookup promotion, and their related entities are also lookup entities, their identifying attributes are "promoted" up to the current entity as well.

A lookup entity is specified by setting the IsLookup property on an entity to True. For a hierarchy or series of lookup entities, set this property to True on all of the lookup entities, and set the PromoteLookup property on the intervening roles to True as well. You may also want to set the ContextualName property to Merge or Role on the identifying attribute of a lookup entity, if the attribute has a generic name like "Name". More information on lookup entities. Also, if you have a column in your database that does not have a lookup table, but you still want users to be able to choose values from a list, set the ValueSelection property to Dropdown or List on the corresponding attribute in the model.

Changing the value of the IsLookup, PromoteLookup, ContextualName, or ValueSelection properties will not break existing reports and thus may be done at any time.

These three methods should allow you to create a very natural and intuitive report model navigation experience for your end users.

What to do with IdentifyingAttributes and DefaultDetailAttributes?

bobmeyers — Wed, 26 Oct 2005 00:19:00 GMT

SQL 2005 report models will ship with a curious and admittedly incomplete solution for handling "the information users typically want to see about an instance of entity X". The problem is that there are many scenarios for which the answer to that question differs:

Scenarios

1. Dropdown selection (applies to entities with a relatively small number of instances): The cramped interface and low number of distinct items leads users to want the smallest number of fields -- preferably one -- necessary to identify each instance.

2. Large list selection (applies to entities with a relative large number of instances): The more spacious interface and higher number of distinct items leads users to want a moderate number of fields that allow for multiple ways of identifying an instance.

3. Generating a drillthrough report for multiple instances of entity X: The fact that the report is fundamentally "about" instances of entity X leads users to want an even larger number of fields, including some that are very interesting/useful, though not necessarily identifying.

4. Creating a group on instances of entity X: The uncertainty about whether the report is fundamentally "about" instances of entity X leads users to want just enough fields to easily identify each instance (they can easily add more if they want them).

5. Model item security: Users will not get permission for an entity if they cannot see the canonical minimum set of fields required to identify an instance of that entity. To allow flexibility for granting permission to other fields, administrators want only the absolute minimum number of fields necessary in this set.

Options

In SQL 2005 there are only two collections defined on an entity that accommodate all five of these scenarios. IdentifyingAttributes is used for dropdown selection, large list selection, and model item security. DefaultDetailAttributes is used for generating drillthrough reports and creating a group on instances of entity X. [Note: Use of DefaultDetailAttributes always reverts to IdentifyingAttributes if the first is empty.]

Recommended Approach

Given the limited options and the sometimes conflicting pressure to add/remove fields from each of these collections, the following is my recommended approach.

IdentifyingAttributes should be as small as possible, preferably one field. The exception would be an entity that uses large list selection, which cries out for multiple fields to help the user identify each instance. In this case you should consider adding at most one or two more fields (e.g. including Name along with ID), but keep in mind that in doing so you are giving up the ability to expose these fields independently through model item security.

DefaultDetailAttributes, if used at all, should at most be only slightly larger than the set of fields in IdentifyingAttributes. If you have too many fields, you will quickly start to annoy users when they want to create a group on that entity, especially a chart group (which will display the concatenation of all of those fields in the data label for the corresponding category or series -- ouch).

For entities where the DefaultDetailAttributes selected above are just not enough to generate a decent multi-instance drillthrough report to that entity, use Report Builder to throw together a report with the fields you really want, enable the Drillthrough (to this report) option in the Report Properties dialog, save it to the server, and use SQL Management Studio to specify it as the multi-instance drillthrough report instead.