I used reverse engineering in myysqlworkbench to map entities.
However, bugs occur in 1:1 identification mapping.
Bug: After one-to-one mapping, it works well until forward engineering (which also uses Synchronize Model)
But when I connect to EER Diagram through reverse engineering again, One-to-one mapping changes to one-to-n-mapping.
(1: Parent / N : Child)
Here are the photos I captured.
user : teacher #OneToOne identification mapping
forward Engeineering Success
Reconnect EER Diagram to reverse Engineering
I tried setting up UQ on user_id (fk,pk) in the teacher table and applied the Synchronize Model, but it doesn't work.
Let me know what bug it is.
Help me~
I think I got the answer from the articles linked below.
The conclusion seems to have been the limitation of the forward and reverse engineering structure of MySql Workbench.
1: after reverse Engineer MySQL Workbench change 1:1 relationship to 1:n
2: MySQL - One To One Relation?
Related
I'm a bit confused about this naming convention.
What is the difference between them and are target/source interchangeable with owning/not owning?
One thing in particular is hard to understand:
"The main difference between a OneToOne and a ManyToOne relationship in JPA is that a ManyToOne always contains a foreign key from the source object's table to the target object's table, where as a OneToOne relationship the foreign key may either be in the source object's table or the target object's table"
JPA wikibooks
I can't imagine such situation in uni one-to-one
Differences between them are a little confusing. You should practice a lot to understand very well.
At first, you should understand some terminology:
Role : In every relationship there are two entities that are related to one another, and each entity is said to play a role in the relationship.
Direction : Relationships can be unidirectional or bidirectional. For e.g.. a Person has an address is normally unidirectional whereas Employee working on a project is normally bidirectional. We will look at how to identify and define directionality while coming up with a Data Model.
In order to have relationships at all, there has to be a way to create, remove, and maintain them. The basic way this is done is by an entity having a relationship attribute that refers to its related entity in a way that identifies it as playing the other role of the relationship. It is often the case that the other entity, in turn, has an attribute that points back to the original entity. When each entity points to the other, the relationship is bidirectional. If only one entity has a pointer to the other, the relationship is said to be unidirectional. A relationship from an Employee to the Project that they work on would be bidirectional. The Employee should know its Project, and the Project should point to the Employee working on it. A UML model of this relationship is shown here. The arrows going in both directions indicate the bidirectionality of the relationship (Form this book >> Pro JPA 2)
Then dive into this link (archived from the original)
I'd like to comment only the links, but I need 50 reputation
2019 Update / TLDR; switch to Entity Framework Core (or whatever else)
While missing some "Features", EF Core properly honors Alternate Keys (aka Unique Constraints) in addition to Primary Keys and thus does a much better job of honoring Relational Algebra. YMMV otherwise; at least it supports many more SQL schemes correctly.
This support added was in the (very outdated) EF Core 1.0 release.. a bit disappointing that the original EF never had this design(ed!) flaw addressed.
This may be related to my other question - which seems to be that either:
Entity Framework is a terrible Relational Algebra mapper1 or;
(which I am hoping for) I am overlooking something with SSDL/CSDL and the EDMX model or EF mappings in general.
I have a Schema First model and the schema looks like this:
ExternalMaps
---
emap_id - PK
Melds
---
meld_id - PK
emap_id - >>UNIQUE INDEX<< over not-null column, FK to ExternalMaps.emap_id
For verification, these are scripted as the following, which should result in a multiplicity of ExternalMaps:1 <-> 0..1:Melds2.
ALTER TABLE [dbo].[Melds] WITH CHECK ADD CONSTRAINT [FK_Melds_ExternalMaps]
FOREIGN KEY([emap_id]) REFERENCES [dbo].[ExternalMaps] ([emap_id])
CREATE UNIQUE NONCLUSTERED INDEX [IX_Melds] ON [dbo].[Melds] ([emap_id] ASC)
However, when I use the EDMX designer to update from the database (SQL Server 2012), from scratch, it incorrectly creates the Association / Foreign Key relation as ExternalMap:1 <-> M:Meld.
When I try to change the multiplicity manually for the Meld (via the "Association Set" properties in the designer) side to either 1 or 0..1, I get:
Running transformation: Multiplicity is not valid in Role 'Meld' in relationship 'FK_Melds_ExternalMaps'. Because the Dependent Role properties are not the key properties, the upper bound of the multiplicity of the Dependent Role must be *.
(As with my other question, this seems to be related to Unique Constraints not being correctly registered/honored as Candidate Keys.)
How can I get EF to honor the 1 <-> 0..1/1 multiplicity, as established by the model?
1 While I hope this is not the case, I am having no end to grief when trying to get EF to map onto a perfectly valid RA model: LINQ to SQL (L2S) does not have this problem. Since my other question was not trivially answered for such a popular ORM, I am losing faith in this tooling.
2 It is by design that the FK is not the other way: "Though shalt not have nullable foreign keys." - It is also not the case that it's a "shared" PK as this answer from 2009 suggests as a fix.
I am using EF 6.1.1, VS 2013 Ultimate, and am not going to use any "OO subtype features" - if that changes anything.
EDIT sigh:
Multiplicity is not valid because the Dependent Role properties are not the key properties? (from 2011) - is this still the case for the EF "Microsoft-endorsed Enterprise-ready" ORM in 2014 2015?
At this rate the next time someone asks why EF wasn't used I'll have a large set of reasons other than "LINQ to SQL works just fine" ..
The problem is that Entity Framework (from EF4 through EF6.1, and who knows how much longer) does not "understand" the notion of Unique Constraints and all that they imply: EF maps Code First, not Relational Algebra *sigh*
This answer for my related question provides a link to a request to add the missing functionality and sums it up:
.. The Entity Framework currently only supports basing referential constraints on primary keys and does not have a notion of a unique constraint.
This can be expanded to pretty much all realms dealing with Unique Constraints and Candidate Keys, including the multiplicity issue brought up in this question.
I would be happy if this severe limitation of EF was discussed openly and made "well known", especially when EF is touted to support Schema First and/or replace L2S. From my viewpoint, EF is centered around mapping (and supporting) only Code First as a first-class citizen. Maybe in another 4 years ..
I use Envers 3.5 with Spring.
Lets say I have a entity A with a relation to Entity B which has a relation to Entity C.
All Entities are audited. When I change something in entity C I can see the change in that audit table. What I want is to see the change in the audittable of entity A, too. It would be ok to see that change in entity B´s table.
Can this be done with envers?
(I´m sorry for my poor English knowledge)
This is a common question about Envers, however that is not possible currently.
First of all Envers doesn't have a way to automatically know what are the roots of entity trees, that is which entities should be marked as modified upon a child-entity modification.
Secondly it would cause a lot more data to be written on each change. It would be possible to implement using some custom annotations and "marker" revisions, but I guess that task waits for a contributor :)
Sorry I don't speak EF lingo that well, having just set up my first EF project. I'm used to working with Linq-to-SQL as a way of avoiding SQL queries, and it worked well with some WCF web services I used. All this in Microsoft Visual Studio 2010.
Now with that background, I created a database using Servr that has Tables A and B in a many to many relationship with Table C. Since it is illegal to do this in database theory, I set up a linking table, as is well known. Two of them: one called A_C, and the other called B_C, each having a foreign key (1 to many) from tables A and B, respectively. Then I linked table C t both these linking tables, with these linking tables receiving a foreign key from C. So now I am OK I thought.
So I create an ADO.NET entity data model, using the Entity Data Model Wizard, I picked the option "from an existing database", and clicked the buttons. Much to my surprise, and chagrin, and shock and awe, I saw ONLY THREE TABLES: A, B and C! No linking tables whatsoever. Are they kidding me?
Think about this for a moment. The engine that runs the EF figured out that tables A and B share a "many-to-many" relationship with Table C. In the schema diagram of the .edmx file there is show asterisks between A,B and C, exactly as expected.
BUT NO LINKING TABLES ARE SHOWN IN THE SCHEMA! What? It's very logical I suppose not to show the linking tables...but unexpected.
Is this your experience, for anybody who has ever done many-to-many table relationships?
BTW, before I hit the Send key, I did a lot of research on EF 4.0, and I find it is a work in progress it seems. Lots of pitfalls, that I will probably fall into. For example, I intend to deploy this in a WCF REST solution that uses web methods that work with a SQL Server database. In the past I've used Linq-to-SQL and now I am going to try, guardedly, to use Linq-to-Entities.
That is exactly what is supposed to happen. And all three tables will be updated correctly.
I understand in Entity Framework you can specify relationships that need to be joined with Include:
Product firstProduct =
db.Product.Include("OrderDetail").Include("Supplier").First();
But we have the opposite issue that a simple LINQ statement is getting making too many JOINs on the SQL server.
So how do we do the opposite, i.e. tell Entity to not do any deep loading of joined tables when it gets all the orders, so that on the SQL Server it executes:
SELECT * FROM Orders
The Entity Framework often goes ahead and loads basic relationship information too.
It does this so users can make updates easily, without violating the EF's unique concurrency policy for relationships.
You can turn this off however by doing a no tracking query.
See Tip 11 - How to avoid relationship span for more information for more information
Alex