I am a beginner in Power BI. Just started working on DAX. I have a question regarding relationship.
I have made four tables i.e. Sales, Products, Product Category, Product Sub Category. Found that relatable columns are automatically picked up. ProductKey column in Product table contains unique Product Key and that propagates Sales Table where Product Key gets repeated. The arrow direction is from Products table to Sales table. '1' is added to Products and a '*' is added to Sales. I think this type of relationship is called 'One to Many' but when I check the properties of the relationship it indicates as 'Many to one'. If tried to change to 'One to Many' it shows error statement. Please help me out of this problem. Thanks.
Since you are saying that Product table has '1', while the Sales table has '*', so this is a One-to-Many relationship. However, when you open the relationship properties then you see the 'cardinality' as 'Many to one'. That is only because in the 'Edit relationship' window your table selection sequence is opposite. That is, the Sales table is selected at the top and the Product table is showing in the bottom.
So, summary, the relationship is correct, nothing to be worried about. :)
Rehan
There is no need to worry about your design however I will suggest you merge "Product Category" with "Product SubCategory" tables so you can achieve a star schema which works best with PowerBI.
I have 2 models user and category. each user will select multiple categories of data, I'm using HABTM. Is this right method?. If yes How can I store multiple category details with each user in join table?
Never use HABTM, if you want to add attributes to your join table and interact with your join table.
Use has_many though. You can read more about it in the docs below
http://guides.rubyonrails.org/association_basics.html#choosing-between-has-many-through-and-has-and-belongs-to-many
I have this schema
All the relations here must be one-to-zero/one.
A user can be either an employee or a customer. The user_type ENUM gives me the type so I know where to go from there.
Then an employee can be either basic or a manager. The employee_type discriminator let's me know that.
How am I supposed to build the Eloquent Model relations?
Let's say I have a user that is an employee. I need to get it's common fields from the users table but also need to get common fields from employees table. Do I need to hard code, and know that when user_type=emp I need to select from the employees table? What if I need to add another user type later?
UPDATE
Would it make sense to change my schema into something simpler?
My problem is that by using, as suggested, polymorphic relations I would end up to something like this:
$user = new User::userable()->employable()->...
Would a schema in which I drop the employees table and have employee_managers and employee_basics linked straight to the users table?
this is an polymorphic relationship. but if you want to be easy, you need to fix some things.
in the table employees
- user_id
- employable_id
- employable_type enum(Manager, Basic) # References to the target model
.... this last two are for the polymorphic relation, this is the nomenclature
in the basics and managers table you could delete the user_id field, but you need an id field as increments type
and now in the model Employee you need to make this function
public function employable(){
return $this->morphTo();
}
I hope this works :)
Looking over the magento 1.5 schema I cannot seem to figure out how a product_id relates to an entity_id.
In all my test cases I can verify that the product_id and entity_id are equal (the same int). But I am guessing that somewhere this is a relationship and even though they are equal in my test cases, it's likely this is only a coincidence and not something I should depend on.
In what tables or relationships can I find what this link is so that I can write a reliable query.
I'm just looking for something like this... tho it probably won't be this simple.
select entity_id from <wherever> where product_id = 1234
As per Magento forum post by a Magento Team member entity_id on the EAV side is in fact the same as the product_id on the catalog product end. So, there you go.
Given the following tables in ActiveRecord:
authors
sites
articles
I don't know how to express that an author is paid a different amount depending on the publication, but that authors working for the same publication have different rates:
John publishes an article in Foo for $300
John publishes an article in Bar for $350
John publishes an article in Baz for $400
Dick publishes an article in Foo for $250
Dick publishes an article in Bar for $400
etc.
What kind of relationship am I trying to describe?
At the moment I've got a "rates" table with author_id, site_id and amount columns. Given publication.id and author.id, I derive the cost of the article with
cost = Rate.find(:first, :conditions => ["author_id = ? and site_id = ?", author.id, site.id]).rate
That works, but I'm not sure it's the best way, and I'm not sure how to make sure I don't end up with 'John' having two rates for 'Baz.'
I don't think I want code so much as I want someone to say "Oh, that's a ... relationship" so I can get a grip on what I'm Googleing for.
Its a has and belongs to many with a rich join table.
class Author
has_many :publications, :through => :rates
end
class Publication
has_many :authors, :through => :rates
end
class Rate #rich join table
belongs_to :author
belongs_to :publication
end
And you can then simplify your finding like this:
#author.rates.find_by_site_id(123)
Plus you get direct access accross the join table
#author.publications
#publication.authors
Its straightforward, but I don't know if there's a specific name for this relationship.
It looks like you need three tables:
Author (info about authors)
Site (info about sites)
Rate Author/Site (rate info only)
In the third table you'd have at least:
Author ID (FK to Author, and Primary Key)
Site ID (FK to Site, and Primary Key)
Rate
And the rate table has two fields as primary keys with a unique constraint. And any joins involving the author and sites would involve a 3-table join.
When three entities are related to each other, it's called a ternary relationship.
Most of the relationships we deal with are binary, relating two entities to each other. For example, The "enrolled in" relationship between students and courses. Binary relationships are further categorized into many-to-many, many-to-one, and one-to-one. But you knew that.
Ternary relationships can be categorized as many-to-many-to-many, many-to-many-to-one,
many-to-one-to-one, and so on.
Binary and Ternary relationships can be further generalized to n-ary relationships.
Here's how I see the case you outlined: There are three entities: author, publication, and article. In addition to these three entities, there is a measure, namely rate. I could be wrong about this.
So I would see three entity tables:
Authors with PK AuthorID.
Publications with PK PublicationID.
Articles, with PK ArticleID.
Then there would be a relationship table with four columns:
AuthorID (FK),
PublicationID (FK),
AtricleID (FK),
Rate which is a currency amount.
The PK of this is (AuthorID, PublicationID, ArticleID)
Not that, in this design, there is no rate table. It's just a measure.
Note also that in this design, it's possible for several authors to collaborate on one article, and each be given a separate rate for his/her share of the article. That's not possible in some of the other proposed designs.
It's also possible for the same article to be sold to more than one publication. It might be desirable to impose constraints on the data, if the real world imposes the same constraints.
Anyway, if you want a search term to Google, the term is "ternary relationships".
I would use a third table:
author_site_mapper
------------------
id
author_id
site_id
rate
I've generally heard this referred to as a 'mapper' relationship. It signifies a many-to-many relationship between two tables.