Databases Reference
In-Depth Information
</Object>
<Where>
<Attributes>
<AttributeName>Employee</AttributeName>
<Keys>
<Key xsi:type="xsd:int">275</Key>
</Keys>
</Attribute>
</Where>
</Drop>
If the dimension member had fact data in a fact table associated with him or
her, the fact data will not be available for querying. Even though the data is
processed inside the cube while querying, Analysis Services will not be able
to identify the associated member and hence not return results for this mem-
ber. You can send the following query to the Analysis Services instance be-
fore and after deletion of the member John Wood to see the difference
between the returned result sets.
select measures.members on columns,
{[WB Employee].[Manager].&[7],
[WB Employee].[Manager].&[7].children } on rows
from [Adventure Works DW]
Be aware that Analysis Services automatically deletes dimension entries from
a dimension table, but does not automatically delete the corresponding fact
table entry from the fact table. The fact table entries for the deleted "Wood,
John" (key 275) is still in the fact table. Before you remove the dimension
member, you need to make sure that the dimension member doesn't have
any data in the fact table. The fact data does exist within the UDM; it is just
being restricted by Analysis Services. It is being restricted because the cor-
responding dimension member was deleted. Such fact data is referred to as
orphan fact data. Because the dimension data corresponding to John Wood
has been deleted and the fact data is still available, if you do a full process of
the database you will see processing errors because Analysis Services by
default checks for referential integrity. You can change the error configuration
settings on the cube to handle the rows (delete or associate it with Unknown
member of the dimension) associated with John Wood or you can delete the
entries corresponding to John Wood using the following SQL statement and
then reprocess the entire database:
Search WWH ::
Custom Search