What is the best practice (and why you consider this as the best) for using of the same dimension in multiple data models (either multid or tabular).
In the case of necessity to have the same dimension in multiple models ("region", "trade net", "product" whatever) should I either use single database view as a datasource for the appropriate dimensions of each data model or create multiple database views based on the same dimension table and use "personal" database view as a source for the dimension of each certain data model?
Unless you are worried about tracking usage by SSAS model, I can't think of a good reason to duplicate the view for each tabular model. If it truly is a shared dimension, it would be easier to have one view. If changes are made to the view, they would then be reflected in all tabular models.
I agree on using views in general to feed a tabular model. They provide a level of abstraction so you can limit columns, add calculations, and control what goes into the tabular model with no surprises from new columns being added.
Related
I have a data model based on a star schema. It stores three date elements. I integrated them into one role play dimension to avoid redundant dates. I would like to store my data into a data vault model in the core DWH and show the star schema as a view. But right now, im not sure how to handle the problem with the role play model. Should I implement three separate Hubs and Sats fpr the dates? and put them together in the View Layer? or can i implement one date hub + sat and reference them to the link table three times (to the three different dates)?
best regards
I consider the dates as reference table. I have draw a logical model If i understood your problem correctly, Then next logical model would be a possible solution on how to use the same in Hub satelitte or link satellite.
A Role playing Dimension or you could have 3 views on this dimension :
Solution :
Note: This is logical model, So "NO" physical foreign keys.
Dan's Definition of "Reference tables" are referenced from Satellites, but never bound with physical foreign keys. There is no prescribed structure for reference tables: use what works best in your specific case, ranging from simple lookup tables to small data vaults or even stars. They can be historical or have no history, but it is recommended that you stick to the natural keys and not create surrogate keys in that case.[20] Normally, data vaults have a lot of reference tables, just like any other Data Warehouse.
https://en.wikipedia.org/wiki/Data_vault_modeling#Reference_tables
I have a Fact Table Service1 (open or latest data) from Mart1 and another Fact Table Service2 (historic data) from Mart2. These tables share few common measures and dimensions but the underlying dataset is mutually exclusive.
Now the business wants to merge these two facts into one table in Tabular model to do Year over Year comparison.
Is it possible to combine these two facts, if so, what should be the approach.
Alternatively, do we have to achieve this.
Things to note down are,
Records in Fact table Service2 will never change
The Dimension keys between Mart1 and Mart2 is not guaranteed to be same
Are these Data Marts different databases? If so, you can create a calculated table that brings the two tables together. To do this, in 2016, on the bottom of the designer, there is a little plus sign on the far right next to the last table tab defined. When you hover over it, it will say "Create new table from DAX formula". Create the DAX that selects from the first table union the second table.
If the marts are in the same database you can create a partition for each on the table properties. In order to do this you would create a tabular model, open a connection to data source and bring in the changing data. Then click on table, partitions, click New, then grab the archived data. You would have to make sure the column definitions are in line in order to do this.
As far the other issues that you describe, it sounds as though you are using the Data Marts as your warehouses. Do you have access to the data before it was transformed into the Data Mart where the surrogate keys were applied? I generally keep a Persisted Staging Area around for these cases. If you employ a Data Vault (http://learndatavault.com/) prior to your Data Mart creation, you could simply create a new Data Mart with both sets of data and all of the Dimension keys will be intact.
I'm trying to join two tables that are in two different databases. These databases don't necessarily have to be the same. So i'm trying to see if I can make a model off of one model and another model off the other model and join the two derived models. Or if there is a way that you know how to join two models of different databases that'd be great too.
It is not possible for a Model to use two Tables/Databases
A model is generally an access point to the database, and more specifically, to a certain table in the database. By default, each model uses the table who's name is plural of its own, i.e. a 'User' model uses the 'users' table.
Source
The second Answer says it is possible, but I don't think it will work the way you want it.
However it is possible for a Model to use a different Database.
You can then create a relationship to link them.
It could be achieved with useDbConfig easily (just tested).
Another way is to use DB view.
I am trying to build a WPF application using the MVVM pattern. It would be my first one.
In my database I have 2 tables a reports table and a columns table. Basically I just want to store the skeleton of reports by storing the name and some minor infos (header row...) and save all columns in the other table.
I am wondering what would be the best approach when creating my model:
should I do 2 models (Report and Column) for each table? And make an observable collection of Columns
Only 1 model and create a POCO Column with a regular list of Columns
If I go with the 2 models approach should I implement 2 modelViews or can I group everything in one modelview as I will work with only one report in the view (like the edit report view)?
Hope I was able to clearly explain my situation.
Just do each separately (i.e. one View/ViewModel/Model per table). You can refactor common items later (and/or as you're building).
ViewModels in MVVM usually have one-to-one relationship to View, unlike Asp.Net MVC. In order to decide how many Views/ViewModels you need you can start thinking of the interface. ViewModels is modeled UI, so if you have one screen in your app then you should start with one viewModel class, later you can refine it if it will be too big. Models are a little bit different, it depends how are you going to interact with them. I'm not sure what are you going to do with them, I had an experience of storing a report definition in database and it may happen that you do not really need two tables at all, you do not even need relational database, just save a blob with serialized XML. But anyway after deserializing it back to your object you will have at least two model classes - Column and Report, model is kind of lowest level of abstraction, if you won't have those two model classes you won't be able to distinguish these entities.
It came up again today how to handle allowing users to add custom fields to the standard entity schemas delivered in your product's database. I favour actually providing a function that gives the user limited DDL functions, so they can actually add a new, custom field to a table. Another approach is to have a separate table for custom fields, e.g. Customers, and CustomersEx, where only CustomersEx can change, but here updates become trickier than normal. The last and most badass option that we discussed was providing a EAV table, where rows are entity name, field name, field value.
Which approach is best?
EAV that is added to the existing relational structure. There is a whitepaer published by SQL Server CAT (Customer Advisor Team) on this topic. Although is vendor specific, the principels discussed and the solutions proposed apply to most RDBMS: Best Practices for Semantic Data Modeling for Performance and Scalability
I favor your second idea. We do something similar but call the tables Attr[ibute] tables, e.g. Company, CompanyAttr. The attributes are a collection in our business object (1:M) and NHibernate handles database operations. We explicitly display these fields as attributes in the UI and don't try to display them as if they were additional fields in the table.
I favor adding fields to a table via DDL, but that table should be separate from the main table. That way, you can script changes to your database schema without affecting your users' custom field additions. A right-join is easy enough to accomplish, and you won't need the record in the separate table if there are no custom fields.
If you just want to display data in a vertical fashion, EAV tables can be a good choice. You can also run a pivot query to display them horizontally.