I am trying to map the tables from a database (of 60 tables) using JPA. I am doing this for a multilingual application, hence every piece of data has to be available in more than one language.
My database table structure is something like this. I have a Region table, which is related to a RegionLanguage table. The RegionLanguage table actually holds the description for that Region in different languages. You may want to have a look at this diagram:
When it comes to JPA, I find it hard to map it in a way that would require as little associations as possible. I have tried to use the Secondary table concept, but it fails in some occasions since this is a #OneToMany relationship. Preferably, I was thinking of a solution that would make these two tables appear as a single object.
Your help is appreciated.
Thanks in advance.
I'm not sure I understand this strange diagram... The RegionLanguage has some some kind of foreign key pointing to Region.id, I take it? If Region has only one column (as shown on the 'diagram'), you can simply map only 'RegionLanguage' and you'll have only one entity as you wanted --- no information lost ;).
But seriously, how would you want it mapped? Do you want to have something like this:
class Region {
//.. the missing fields not shown in diagram
List<String> languages; // take only language to avoid creating separate entity for region language
}
or something like this:
class RegionInnerJoinRegionLanguage {
// all fields from Region
// all fields from RegionLanguage
}
In any case you didn't say how the rest of tables are joined with your i18n tables. From your description, I'm guessing, that all tables have fk to RegionLanguage. I'm not sure what the Region table is used for in the grand scheme of things. I guess it's just for grouping of languages... I imagine this 'models' Switzerland (one 'region' 4 languages)... But what will you do with languages spoken in several regions? Are you going to have several French, English etc. languages (one for each region) and all data multiplied for each of those??
I know you din't ask for this... I just think you oversimplified your data structure for this question... So much so that it's hard to guess what you really want to achieve.
In any case, if you want to use the list of strings approach, you can try this:
#ElementCollection
#CollectionTable(name="RegionLanguage",
joinColumns=#JoinColumn(name="regionID") // or whatever... it's not on your diagram.
)
#Column(name="langage")
private List<String> langages;
I still don't understand why you want to put both tables into a single entity... If it's 'read-only' data, you might try creating a view and mapping it --- always a 'way out' ;). But it's (both of them, in fact) a bit of over-complication, to my mind --- it's going to bite you in future. My advice is to just go with 'simple OneToMany mapping'.
Related
I work in cattle production and I am learning about database design with postgreSQL. Now I am working on an entity attribute relationship model for a database that allows to register the allocation of the pastures in which cattle graze. In the logic of this business an animal can be assigned to several grazing groups during its life. Each grazing group in turn has a duration and is composed of several pastures in which the animals graze according to a rotation calendar. In this way, at a specific time, animals graze in a pasture that is part of a grazing group.
I have a situation in which many grazing groups can be assigned to many animals as well as many pastures. Trying to model this problem I find a fan trap because there are two one-to-many relationships for a single table. According to this, I would like to ask you about how one can deal with this type of relationship in which one entity relates to two others in the form of many-to-many relationships.
I put a diagram on the problem.
model diagram
Thanks
Traditionally, using a link table (the ones you call assignment) between two tables has been the right way to do many-to-many relationships. Other choices include having an ARRAY of animal ids in grazing group, using JSONB fields etc. Those might prove to be problematic later, so I'd recommend going the old way.
If you want to keep track of history, you can add an active boolean field (to the link table probably) to indicate which assignment is current or have a start date and end date for each assignment. This also makes it possible to plan future assignments. To make things easier, make VIEWs showing only current assignment and further VIEWs to show JOINed tables.
Since there's no clear question in your post, I'd just say you are going the right way.
I hope someone can give me some guidance in how to best approach this situation.
I am using dbcontext, wpf and sql server.
I am having situations were the presentation of the data requires other data than just what is coming from a single table. For example, if I had a person table but wanted to show also how many books they had read from related data, say fields would be name, address, NoOfBooks.
I currently create a new class, called say PersonBookPM, that I fill up with data from a linq query which combines the two tables which includes the above three fields.I create an observablecollection of that and make that the itemssource of the grid/listbox.
When I am then adding data to that I then need to use the selecteditem, convert that back to the single entity of person, and attach it back in to the context.
It seems like the classes have already been defined by the code gen and I am repeating the process only slightly differently.
Am I going round the houses here?
Thanks Scott
I am having a model "Events" (Zend_Db_Table_Abstract) that's got various relationships to other models. Usually I think I would do something like this to find it and its relationships:
$events = new Events();
$event = $events->find($id)->current();
$eventsRelationship1 = $event->findDependentRowset('Relationship1');
As the relationship is already set up I am wondering if there's any sort of automatic join available or something. Every time I fetch my event I need to have all the relationships, too. Currently I see only two ways to achieve that:
Build the query myself, hard coded. Don't like this, because it's working around the already set up relationship and "model method convenience".
Fetch every related object with a single query. This one's ugly, too, as I have to trigger too many queries.
This goes even a step further when thinking about getting a set of multiple rows. For a single event I may query the database multiple times, but when fetching 100 rows joins are just elementary.
So, does anyone know a way to create joins by using those relationships or is there no other way than hardcoding the query?
Thanks in advance
Arne
The way to solve this challenge is to 'upgrade' your database access to use the dataMapper pattern.
You are essentially adding an extra layer between the model in your application an their representation in the db. This mapper layer allows you read/write data from different tables - rather than a direct link between one model and one table.
Here is a good tutorial to follow. (There are some bits you can skip - I left out all the getters and setters as its just me using the code).
It takes a little while to get your head round the way it works, when you've just been using Zend_Db_Table_Abstract, but it is worth it.
I have some views that I want to use EF 4.1 to query. These are specific optimized views that will not have keys to speak of; there will be no deletions, updates, just good ol'e select.
But EF wants a key set on the model. Is there a way to tell EF to move on, there's nothing to worry about?
More Details
The main purpose of this is to query against a set of views that have been optimized by size, query parameters and joins. The underlying tables have their PKs, FKs and so on. It's indexed, statiscized (that a word?) and optimized.
I'd like to have a class like (this is a much smaller and simpler version of what I have...):
public MyObject //this is a view
{
Name{get;set}
Age{get;set;}
TotalPimples{get;set;}
}
and a repository, built off of EF 4.1 CF where I can just
public List<MyObject> GetPimply(int numberOfPimples)
{
return db.MyObjects.Where(d=> d.TotalPimples > numberOfPimples).ToList();
}
I could expose a key, but whats the real purpose of dislaying a 2 or 3 column natural key? That will never be used?
Current Solution
Seeming as their will be no EF CF solution, I have added a complex key to the model and I am exposing it in the model. While this goes "with the grain" on what one expects a "well designed" db model to look like, in this case, IMHO, it added nothing but more logic to the model builder, more bytes over the wire, and extra properties on a class. These will never be used.
There is no way. EF demands unique identification of the record - entity key. That doesn't mean that you must expose any additional column. You can mark all your current properties (or any subset) as a key - that is exactly how EDMX does it when you add database view to the model - it goes through columns and marks all non-nullable and non-computed columns as primary key.
You must be aware of one problem - EF internally uses identity map and entity key is unique identification in this map (each entity key can be associated only with single entity instance). It means that if you are not able to choose unique identification of the record and you load multiple records with the same identification (your defined key) they will all be represented by a single entity instance. Not sure if this can cause you any issues if you don't plan to modify these records.
EF is looking for a unique way to identify records. I am not sure if you can force it to go counter to its nature of desiring something unique about objects.
But, this is an answer to the "show me how to solve my problem the way I want to solve it" question and not actually tackling your core business requirement.
If this is a "I don't want to show the user the key", then don't bind it when you bind the data to your form (web or windows). If this is a "I need to share these items, but don't want to give them the keys" issue, then map or surrogate the objects into an external domain model. Adds a bit of weight to the solution, but allows you to still do the heavy lifting with a drag and drop surface (EF).
The question is what is the business requirement that is pushing you to create a bunch of objects without a unique identifier (key).
One way to do this would be not to use views at all.
Just add the tables to your EF model and let EF create the SQL that you are currently writing by hand.
I am trying to do something fairly easy to understand with WCF data services, but can't find how to do it.
I have 3 table, Customer, Product and a joint table Customer_Product linking the two other tables (a basic n to n relationship):
Customer <= Customer_Product => Product
I want to get a customer and its products in the same query, so I would like to do something like:
/Service.svc/Customers(23)?$expand=Products
But it tells me that there is no Products navigation property on the table Customer.
The only option that I found is to do:
/Service.svc/Customers(23)?$expand=Customer_Product
and then make another call to get the Product details.
Is there a clean way to do this?
Thanks a lot in advance.
The many to many relationships are usually modeled by the service by hiding the join table (if the only thing it stores is the relationship and there's no data in it). If you're using EF in the service this should be pretty easy to do.
If you do need to expose the join table for some reason, then you can issue a query like:
/Service.svc/Customers(23)?$expand=Customer_Product/Product
(expands can be multiple levels deep). Of course reading the results will be a bit more complicated because of the two levels there, but you do get the data you need.