A sub-set of fields selected from a Data Category universe that filters data to create a single business frame of reference for a good data extract or report.


Entities are one of the more important concepts in DSF. They are the core objects that create business context within the system.


Data Categories define the context universe determined by the linked relationships between tables. They maintain every data element available to the user within a specific business context as structured within the database.

Data Categories are only the structures of the data. They describe every field that is possible for the user to choose within its contextual universe.

Data structures CANNOT jump Data Categories.


Example:

    You cannot drive to the next town on the other side of a river if a bridge or tunnel does not link them.

    Nor can you select data elements from one Data Category if there is no logical business rule to link them.


    To repeat; Data structures CANNOT jump Data Categories.

When a user is looking for data they can only select fields defined in a single Data Category.

Data Categories are structures of what is possible to retrieve from the database within a contextual universe of a business object. Entities define a single logical business purpose within that universe.


Entities are sub-contexts of a Data Category. Entities can ONLY be based off a single Data Category. They include a chosen subset of fields that are available from a Data Category universe. Entities are created during discovery. Entities should always make good logical business sense as to what could be used within a visualization/reporting tool.


Example 1:

A single shopping list of items to get from the grocery store to make Chili could be an Entity called the “Chile Recipe” which is based off the “Grocery Store” Data Category.


You could not have a hammer on the “Chile Recipe” list because the hammer should be from a separate unrelated Data Category called “Hardware Store”.


Data elements in an Entity cannot jump Data Category structures. If you’re Entity was named “Build Deck Supplies” and was based off the “Hardware Store” Data Category then it could include a hammer but not tomatoes from the “Grocery Store” Data Category.


Hammer and tomatoes come from different business universes (Data Categories).


Furthermore, Entity field names can be aliased differently than the Data Category. If the “Chili Recipe” called for “Ground Beef” it could be listed on the Data Category as “Ground Chuck”. It was only renamed to “Ground Beef” for the “Chili Recipe”.


Other Entities can alias the Data Category “Ground Chuck” entry to “Ground Round”. It doesn't matter what the Entity calls the data element, it always refers to the same Data Category field.


This is designed to help the business owner and report writers understand the Entities better in the business context of what they are being used for.


Entities are purposeful and closely resemble the names of data extracts (SQL Queries) that have been created for your database in the past.


Example 2:

If you want to send Christmas cards, you could have an Entity named “Christmas Card List”.


It could be based off of a Person Data Category. The Entity's default data fields from the Data Category could be Name, Address, City, State, and Zip Code.


The field names can be aliased for this Entity or when the user creates a View.


City could be changed to Province if the business or the View creator wanted to name it something different..


When organizing data elements either by Data Team or Entity it's a good idea to create a naming convention that the target audience will understand within the business context of your industry.


DSF does not care what Entities are called as long as they are unique. Many businesses already have a naming convention process for their data extracts (SQL Queries) and reports which they should continue to use when naming Entities.


Filters

Entities can declare a filter for data rows. They can limit the rows returned based on a criterion. They define the WHERE clause in an SQL Query.

 

Filters at the Entity level are locked from the View creator. If the Entity creator added the filter of State = ‘NJ’ then the Entity will ONLY return records where the State = 'NJ’ regardless of what the creator of the View wants. Creator of Views can only further filter data within the context of the Entity and cannot increase the record count.


The user of the Entity can filter their usage of the Entity further by limiting the City within ‘NJ’ to ‘Short Hills’. But they can never expand it to include a different State like ‘NY’. 


The entity filter locks them into ‘NJ’ records only. This is to maintain the business context of what the Entity was originally designed for.

 

Example:

You could create two Entities with descriptive names.


One called “FULL Christmas Card List” with no filter and the other “NJ Christmas Card List” with the ‘NJ’ filter.


The FULL list with no filter would return records for ALL the States. Then and only then, will the user of your Entity creating a View be able to include data rows not limited to ‘NJ’.


Security

DSF handles all data security internally. Details of exactly how the data security works can be found in the Security Role Manager. For now, the only thing to understand is that the Entity creator does not need to be concerned with security.


Which fields or rows should be restricted from users of an Entity is determined by Role Membership.


In the example above; the Entity “NJ Christmas Card List” is restricting the data to only include ‘NJ’ records. This is NOT a security restriction but a business restriction.

If you create the “NJ Christmas Card List” Entity and you happen to include the Social Security field because you have the security permissions to do so, but the user of your Entity does not have permission, there is no need for concern. 


If the Entity user has a role restriction the field will simply not be presented to them on execution. Furthering the security example, if the user of your Entity does not have permission to view any data rows with the City = ‘Short Hills’ the Entity will restrict the rows of that data automatically.


This is sometimes referred to has a Chinese Wall. 


Summary:


Entities define a single logical business purpose within a Data Category contextual universe. Entities are sub-contexts of a Data Category. Entities can ONLY be based off a single Data Category. They default to include a chosen subset of fields that are available from a Data Category universe.


  • Are created during the discovery process.
  • Can be named anything you wish.
  • Can ONLY be based off a single Data Category.
  • Default to include a chosen subset of fields that are available from a Data Category universe.
  • Are defined by a business expert.
  • Are purposeful.
  • Closely resemble the names of existing reports.
  • Can limit data rows returned based on a filter criterion.
  • Do not need to worry about data security for fields and rows.
  • Are not SQL Queries.
  • Do not return data.
  • Can alias Data Category field names to make more business sense to users.
  • Can contain User Defined Fields.