I'm sorry for images but I think this is the best way for expaining the problem.
Relationships in Physical Layer as below;
Relationships in Logical Layer as below;
When I try to get data between 2 fact table I get the result as below;
Lastly, here is sql code of my report;
So, I'm sure that there is no problem between relationships..How can I fix this issue?
Thanks in advance..
You need to set the content levels in the fact LTS to "Grand Total" for the non-conformed dimensions and tie the measures to the grand total level of the non-conformed dimensions as well.
https://greatobi.wordpress.com/2011/06/24/making-dims-facts-work-together/
Related
We're trying to build an imaged based product search for our webshop using the vertex ai image classification model (single label).
Currently we have around 20k products with xx images per product.
So our dataset containing 20k of labels (one for each product - product number), but on import we receive the following error message:
There are too many AnnotationSpecs in the dataset. Up to 5000 AnnotationSpecs are allowed in one Dataset. Check your csv/jsonl format with our public documentation.
Looks like not more than 5000 labels are allowed per Dataset... This quota is not really visible in the documentation - or we didn't find it.
Anyway, any ideas how we can make it work? Does we have to build 5 Datasets with 5 different Endpoints and than query every Enpoint for matching?
You can find those limits in the AutoML quotas and limits documentation.
It is possible to have multiple models for group of products -- Maybe even something like: one initial model to classify the product category (jewery, watches, shoes, toys, etc) and a second step for a specific model (to identify the specific product belong toys, or belong shoes, etc). But to be honest, it seems a bit hard to support - but certainly worth trying.
A second option would be training a custom model where you could do a fine tuning on some larger model (ie. inception, resnet, etc) do know all your 20k+ classes (products). It could add a little bit more work at first, but after established, it will become a single model for inference and re-training would be simpler using MLOps mechanisms (ie. Vertex Pipelines).
Good Evening/Morning,
I am developing a social media type database which will have millions of users, I have not worked with a data that big so I am a bit concerned about the approach I am taking with the comments part. There will be comments on different entities such as Posts, Pages, Groups, and 3 to 4 more. So what I am asking is that if anyone out there have implemented polymorphic relation on big data can you share your experience on its performance on big data?
Because you have a single table for different models.
Take the example on Laravel documentation (User and Post can have an Image). If you need to retrieve something like this
User::find(1)->image
internally Laravel makes a query similar to:
SELECT * FROM images WHERE imageable_id = 1 AND imageable_type = '\App\User';
As you image, if you have a lot of images and imageable_* columns are not indexed, these kind of queries will take a lot of time to run.
So, my suggestion is to try to create a index based on this tuple (imageable_id, imageable_type).
I'm learning how to work on ReportView.
How to proceed when I have a table with multiple 1xN relationship ?
I don't want to show the value that is stored on the DataSet field, I want to resolve it to another table.
I know I could do it from Join command on the DataSet, but I have lots of 1xN fields, so I think it isn't practical, the SQL command would be huge and complex.
Thought about using an pre-processed List of object as DataSource. Don't know if its the right way..
Any help would be appreciate.
Thanks.
I know EAV logic and I know what is eav_entity_attribute for. (about eav_entity_* - the same).
But I'm not clear about table eav_entity. It is always empty.
Could someone give some comments please.
I would be glad to get any assumption.
Google gives nothing on this question, as usual)
Doing a grep of the Community Edition code, the only time eav_entity is mentioned is in the config file (/app/core/code/Mage/Eav/etc/config.xml) and in the database setup files (/app/code/core/Mage/Eav/sql/eav_setup/mysql4-install-0.7.0.php).
To me this says that it was put in just before a release and then never actually used. The devs possibly decided to go with a slightly different way of storing the data...
I expected to see all records of all entities in the table eav_entity. But I see that Magento has created separate tables for each of the 8 entities ( customer, customer_address, category, product, order, invoice, shipment, creditmemo) with the following table names ( customer_entity, customer_address_entity, catalog_category_entity, catalog_product_entity, sales_flat_order, sales_flat_invoice, sales_flat_shipment, sales_flat_creditmemo). So eav_entity table is empty and you get data for entities directly from their respective tables.. Some level of de-EAVing the database design :-)
I'm having a hard time designing a relationship with a few models in my project.
The models are: band, musician, instrument
Bands have multiple musicians
Musicians have multiple bands and multiple instruments
That’s all pretty straightforward, but I also need to keep track of what instruments a musician has for a particular band. So in a sense, I guess, bands have multiple instruments via the musicians.
In the tables, I was going to add instrument_id to the bands_musicians linking table, but I need a musician to be able to have multiple instruments for a band, so I was thinking it would need to go in the musicians_instruments table.
What's the best way to set up the relationships with these models?
Thanks for your time!
Musicians would have a one-to-many relationship with both bands and instruments. So create your musicians table and add all of the information relavent to the musicians themselves into that table.
Create an instruments table to hold information about instruments, and do the same for the bands. That will take care of all of your individual items.
Then create something like 'band_assignments' table that just has the id of a band and the id of a musician and links the two together. Create an 'instrument_assignment' table to do the same thing.
Now when you query a musician you can left join all of these tables together to get the data that you need or selectively join on just instruments, just bands, or sort by 'join date' and limit to get the last band they joined or the last instrument they learned.
Basically 5 tables should cover it all.
musicians (musician_id, first_name, last_name)
bands (band_id, name)
instruments (instrument_id, name)
band_instument_assignments (musician_id, band_id, instrument_id, date_played)
As you can see in the edited version above you will have multiple rows in the 'band_instrument_assignments' table--one for each instrument that each user played in each band. You will need to use some GROUP BY and LIMIT clauses to get the data you want, but it should work for you.
See:
How to handle a Many-to-Many relationship with PHP and MySQL
That should give you an idea on how to go about designing your database structure.
someoneinomaha
Maybe you need 4th model, which will cover and union all of her children entities, e.g. called like 'Mus Model'(or whatever you want) and have some methods like:
get_bands()
get_instruments()
get_musicians()
get_instruments_by_musician()
get_musicians_by_band()
get_instruments_by_band()
get band_by_musician()
and so on...It'll provide you needed data and will not brake entities relationships, imho.
I might be a little late to the party here and I am no database expert but I have found that drawing out your DB schema helps immensely. Just make boxes and fill in your table names and columns then draw arrows to define your relationships and it should be a lot clearer as to how you should structure things and whether you need to add a table to join two other tables.
If all else fails, just copy a schema from databaseanswers.org. I'm sure there is one there that would probably help you.