Placing into the database context
In Farseer, the nomenclature is partially inherited from database theory because the elements we work with are very similar. The table below provides a comparison of objectsand nomenclatures. Where it is not possible to equate the language used, we clearly map the language to the objects in the table.
Description | Farseer | Database/Data Warehouse/BI |
Table of values (data structure) | Variable | Fact table |
Dimension structure | Dimension/Dimension table | Dimension/ Dimension table |
Single column in the table | A column in the dimension table (Name, Description, Property) | Attribute |
Single row in the table | Member, Row | Member, Row, Entity, ID |
Table 1: Farseer nomenclature
Snowflake schema
Dimensional tables in Farseer are connected in a snowflake schema. This is a term from relational databases where the schema describes the visual and logical configuration of the entire database. The process of building a database is called data modeling.
Example of data modeling
For example, let's say we have a hierarchy of connected tables as shown below:
Image 1: Example Dimension Hierarchy
From the table above, our database could be populated with four different dimensions: Product, Brand, Group 1, and Group 2. Each dimension contains one or more unique entries (rows).
Image 2. Example Dimension Hierarchy, Populated
The tables above represent objects in the Dimensions section as they would be defined in Farseer. Let's see how some of these objects are connected:
Product -> Brand (one brand has multiple products [1:n])
Product -> Group 1 -> Group 2 (Devices have multiple groups (from Group 1), and each of these groups has multiple Brands [1:n])
Let's expand the example table we looked at earlier by adding columns for Customer and Quantity.
Image 3. Example Dimension Hierarchy, expanded
Thus, we added another table to the database - Customer. It contains rows Customer 1 and Customer 2.
To connect the Product and Customer tables, we need a third table - Quantity. This brings us to the Variable. It consists of rows that link the Product hierarchy to our newly created Customer table.
Image 4. Snowflake schema
The previously shown image with the connected dimensions "Product" and "Customer" via the "Quantity" variable is a snowflake schema - it branches out like a snowflake. We mentioned earlier that this term is inherited from DB/DWH/BI (Business Intelligence) terminology, but what does it mean? Why should we arrange tables in schemas?
Tables are arranged in schemas in databases. The snowflake schema is often used in
DWH/BI systems. It is an extension of the star schema.
A star schema is a simple DWH/BI data model where a central fact table (e.g., sales or quantity) is directly connected to multiple denormalized dimension tables (such as Product or Customer), forming a star-like structure. It is designed to make analytical queries fast and easy to understand by minimizing joins and complexity.
Image 5. Snowflake schema vs Star schema, (https://www.integrate.io/blog/snowflake-schemas-vs-star-schemas-what-are-they-and-
how-are-they-different/)
To wrap everything up, viewing Farseer through familiar database and BI concepts makes data modeling easier to understand and work with. By organizing dimensions and variables in a snowflake schema, relationships stay clear, scalable, and consistent with proven DWH/BI practices. This structure helps users build models that are easy to extend, analyze, and maintain as complexity grows.