I have the 2 dimension tables and 1 fact table. They look like this:
Dimension table 1: Investor_DM
Investor_nr
Investor_name
1
Jack
2
Kelly
Dimension table 2: Company_DM
Company_nr
Company_name
1
Apple
2
Microsoft
Fact table: Positions
Company_nr
Investor_nr
InvestmentDate
InvestmentSize
1
1
2022-jan-02
$1,000
2
1
2022-feb-03
$1,500
1
2
2022-jun-02
$7,000
2
2
2022-jul-03
$7,500
I assigned Investor_nr and Company_nr as PK's in their respective dimension tables, and assigned FK's in the fact table in which I refer to the PK's.
What I want is when I look for data WHERE Investor_nr = '1', I only get the investments in the fact table of investor 1, etc. However, I still get all investments even though I have created one-to-many relationships between the tables. Same goes for the company dimension table.
This is my
SELECT *
FROM Positions
WHERE Investor_nr = '1'
;
query:
I would hope that if I SELECT * from all 3 tables, the Investor_nr's on each row correspond between the fact and dimension table, but this is not the case. Same goes for Company_nr.
What am I missing here? Am I using the wrong query, or are my relationships wrong?
I tried multiple queries, sometimes only on 1 table and sometimes 2 or 3 tables, but I always get data from investors I did not filter on.
Thanks!
Related
I have a teacher who doesn't like to explain to the class but loves putting up review questions for upcoming tests. Can anyone explain the image above? My main concern in the red underline which shows that supplier and supplierPhone are repeated values. I thought that repeated values occurred when there were many occurrences of the same item in a column.
Another question I have is that if the Supplier is a repeating value, why isnt Part_Name a repeating value because they both have 2 items with same names in their columns.
Example:
It's repeated because the result of the tuple is always the same. E.g. ABC Plastics will always have the same phone number, therefore having 2 rows with ABC Plastics means that we have redundant information in the phone number.
Part1 Company1 12341234
Part2 Company1 12341234
We could represent the same information with:
Part1 Company1
Part2 Company1
And
Company1 12341234.
Therefore having two rows with the same phone number is redundant.
This should answer your second question as well.
Essentially you're looking for tuples such that given the tuple (X, Y) exists, if there exists another tuple (X, Y') then Y' = Y
Looks like five tables to me.
model (entity)
modelid description price
1 Laserjet 423.56
1 256 Colour 89.99
part (entity)
partid name
PF123 Paper Spool
LC423 Laserjet cartridge
MT123 Power supply
etc
bill_of_materials (many to many relationship model >--< part )
modelid partid qty
1 PF123 2
1 LC423 4
1 MT123 1
2 MT123 2
supplier (entity)
supplier_id phone name
1 416-234-2342 ABC Plastics
2 905.. Jetson Carbons
3 767... ACME Power Supply
etc.
part_supplier (many to many relationship part >--< supplier )
part_id supplier_id
PF123 1
LC423 2
MT123 3
etc.
You have one row in model, part, supplier for each distinct entity
You have rows in bill_of_materials for each part that goes into each model.
You have a row in part_supplier for each supplier that can furnish each part. Notice that more than one part can come from one supplier, and more than one supplier can furnish each part. That's a many-to-many relationship.
The trick: Figure out what physical things you have in your application domain. Then make a table for each one. Then figure out how they relate to each other (that's what makes it relational.)
I have a relatively simple database design that I will simplify here for the sake of brevity.
I have 4 tables => Products, Product_Sizes, Stores, Catalogs.
There are 6 stores and each store has it's own unique customized catalog, an assortment of different products and sizes that is chosen from the Products and Product_Sizes tables.
I am wondering how to best design the Catalogs table. My ideas are:
id store_id product_id product_size
1 1 53522 1
2 1 40299 1
3 2 43326 1
4 2 43326 2
OR
id store_id product_id product_sizes
1 1 53522 1
2 1 40299 1
3 2 43326 1,2
Each store has it's own unique (and only one) catalog, so a query to fetch all entries by store_id will result in that store's catalog.
Another approach would be to create another table of the combined products and product_size into it's each own unique table, let's call it Products.
id product_id product_size
1 1 1
2 1 2
3 1 3
4 1 4
This separate table gives me a unique id for all the possible products and their size variants. This would result in a single id per product for each Catalogs entry.
I would love to hear some critique and better suggestions as I feel this just isn't right and can't put my finger on how to better design this. Also, if we were to ever implement more than 1 catalog per store, I know this current design would cause me grief. Any feedback would greatly appreciated!!
If it were me, I would create the catalog table as an entity table, with it's own id. If that catalog only belong to one store, I would add a store_id column as a foreign key.
I would then add a catalog_products table. This would have a foreign key to the catalog table, as well as a foreign key to the products and/or product_sizes table. (If a product_size belongs to only one products table, then just the products_sizes table.)
To resolve a many-to-many relationship, we typically add a third relationship table.
a catalog has zero, one or more products (product_sizes)
a product (product_size) appears in zero, one or more catalogs
The relationship table gets us "one-to-many" relationships, which we can represent:
a catalog_product appears in exactly one catalog
a catalog contains zero, one or more catalog_product
a catalog_product is related to exactly one product
a product belongs to zero, one or more catalog_product
id store_id product_id product_size
1 1 53522 1
2 1 40299 1
3 2 43326 1
4 2 43327 2
Different product id for same product name with different sizes.
I would like to create a relational database in which there are two tables Users and products. Each item of each table can be related to many items of the second table.
My current implementation is as follows:
Two main tables-
->Users
User ID
UserInfo
->Products
Product ID
ProductInfo
Two different lookuptables
->UserToProduct
UserID
ProductID
->ProductToUSer
ProductID
UserID
Each time a relation from a user to a product is added, i just add an extra row to the first lookup table, and vice versa.
Is this the right way to do it? Are there any standard models for such scenarios that I can refer to?
You don't need two lookup tables, all you need is users_products. As far as resources, there are zillions, just google "database many to many".
UPDATE
Consider this data:
products
------------
id info
------------
1 car
2 flute
3 football
users
------------
id info
------------
10 bob
20 tim
30 manning
Now, as a simple example, let's say manning owns a football and and a car. Let's say tim owns a flute and a football. Now here's your lookup table:
users_products
----------------------
user_id product_id
----------------------
20 2
20 3
30 3
30 1
That's it. Now you can do queries like "give me all the users that have cars", or "give me all the cars that a user has", etc.
Cheers
You really don't need or want two different lookup tables. You should just have one (either of your tables, UserToProduct or ProductToUser, would be fine). The primary key of the lookup table should be a composite key consisting of both ProductID and UserID.
I need some advice of how to setup my tables I currently have a product table and a product codes table.
In the codes table I have an id and a title such as:
1 567902
2 345789
3 345678
there can be many items in this table.
In my product table I have the usual product id,title, etc but also a code id column that I'm currently storing a comma separate list of ids for any codes the product needs to reference.
in that column I could end up with ids like: 2,5,6,9
I'm going to need to be able to search the products table looking for code ids for a specific set this is where I've come into problems trying to use id IN ($var) or FIND_IN_SET is proving problematic I've been advised to restructure it I'm happy to do just wondering what the best method would be.
Sounds like you have two choices. If this is a 1 to many relationship, then you need to have the foreign key in the code table, not the product table.
i.e.
codeId code productId
1 567902 2
2 345789 6
3 345678 9
4 345690 9
The other option is to have another table which contains productId and codeId (both as foreign keys), this is a many-to-many relationship. This is what you should go for if a code can be assigned to multiple products (I assume not). It will look something like this:
codeId productId
1 2
1 10
2 6
3 9
4 9
I think the first option is what you need.
I have a table User that stores user information - such as name, date of birth, locations, etc.
I have also created a link table called User_Options - for the purpose of storing multi-value attributes - this basically stores the checkbox selections.
I have a front-end form for the user to fill in and create their user profile. Here are the tables I have created to generate the checkbox options:
Table User_Attributes
=====================
id attribute_name
---------------------
1 Hobbies
2 Music
Table User_Attribute_Options
======================================
id user_attribute_id option_name
--------------------------------------
1 1 Reading
2 1 Sports
3 1 Travelling
4 2 Rock
5 2 Pop
6 2 Dance
So, on the front-end form there are two sets of checkbox options - one set for Hobbies and one set for Music.
And here are the User tables:
Table User
========================
id name age
------------------------
1 John 25
2 Mark 32
Table User_Options
==================================================
id user_id user_attribute_id value
--------------------------------------------------
1 1 1 1
2 1 1 2
3 1 2 4
4 1 2 5
5 2 1 2
6 2 2 4
(in the above table 'user_attribute_id' is the ID of the parent attribute and 'value' is the ID of the attribute option).
So I'm not sure that I've done all this correctly, or efficiently. I know there is a method of storing hierarchical data in the same table but I prefer to keep things separate.
My main concern is with the User_Options table - the idea behind this is that there only needs to be one link table that stores multi-value attributes, rather than have a table for each and every multi-value attribute.
The only thing I can see that I'd change is that in the association table, User_Options, you have an id that doesn't seem to serve a purpose. The primary key for that table would be all three columns, and I don't think you'd be referring to the options a user has by an id--you'd be getting them by user_id/user_attribute_id. For example, give me all the user options where user is 1 and user attribute id is 2. Having those records uniquely keyed with an additional field seems extraneous.
I think otherwise the general shape of the tables and their relationships looks right to me.
There's nothing wrong with how you've done it.
It's possible to make things more extensible at the price of more linked table references (and in the composition of your queries). It's also possible to make things flatter, and less extensible and flexible, but your queries will be faster.
But, as is usually the case, there's more than one way to do it.