I am trying to add an association that I didn't have originally. I realized that two tables were technically related, and that some navigation properties might simplify what I would have otherwise had to do manually. The tables and their keys look like this:
Import
Primary Key:
Number : Int32
Date : DateTime
Hour
Primary Key:
DepartmentID : Int32
UserNumber : Int32
Date : DateTime
The association is named ImportHour. Import.Number maps to Hour.UserNumber, and Import.Date maps to Hour.Date. I am trying to add an association that is 0..1 on Import, and * on Hour with navigation properties and no additional foreign keys. When I do this, the designer tells me that the association is not mapped. If I then generate the DDL, it creates new fields Hours.Import_Date and Hours.Import_Number (Hours is the actual database table name for the Hour entity). If I manually map the fields, I end up with the following error:
Error 3021: Problem in mapping fragments starting at line 332:
Each of the following columns in table Hours is mapped to multiple conceptual side properties:
Hours.Date is mapped to <ImportHour.Hour.Date, ImportHour.Import.Date>
Hours.UserNumber is mapped to <ImportHour.Hour.UserNumber, ImportHour.Import.Number>*
I am not really sure what is happening, and I don't think I understand the 'mapping' process well enough to figure this out. It almost seems as if it wants a quintuple key, instead of realizing that the one key maps to the other. I look at my other one-to-many associations, and they do not even have table mappings; I think they have referential constraints instead, but you obviously can't have a referential constraint with a 0..1 to many association.
There are two ways to define relation but in your case you must use the Foreign key association. It means that once you draw association in entity model you must select it and define referential constraints.
You cannot have 0..1 on Import because in such case UserNumber and Date in Hour must be nullable. That is what that relation mean. If no principal entity exists (Import) FK properties in dependent entity (Hour) will be null.
Btw. using DateTime in primary key is not recommended.
As far as I can tell from other databases I have since used, the issue here seems to be that the EF model requires a foreign key to already exist in the database. While I cannot seem to get EF to generate one, it will accept one if it already exists. (Contrary to what I said in the question, you can have a referential constraint on a 0..1 to many (nullable) foreign key).
#Sahuagin this may be long after your question but did you try after adding the association, deleting the scalar property in the designer -- example after creating the ImportHour association, delete the hour.usernumber and hour.date from your hour entity.
this way the independent association established this way is the only relationship between yuor entities - thats the meaning of independent association
Related
I have two entities: Location and Employee. Each employee works in a single location at a time. For any given moment in time, the model is as follows:
There is, however, a requirement to also store historical information for all locations and employees for every end-of-month. I can achieve this by adding a Month PK attribute in both entities, but: how do I handle the relationship in that case?
A foreign key has to reference a composite PK in its entirety. Several alternatives come to mind:
Option 1: repeat the Month attribute in the Employee entity to get the full PK as FK attributes. This feels a bit redundant? If an employee has existed in a given month, surely she has to work in a location in the same month - i.e. the two Month attributes have to always have the exact same value:
Option 2: re-use the Month attribute in the PK of the Employee entity as a foreign key referencing Location. I don't even know if this is allowed (note: I'm going to be using SQL Server eventually, if it matters here)?
Option 3: create a separate bridge entity that holds the history of Location-Employee relationships. This feels kind of neat, but then again I have some doubts as to whether or not I can use one Month attribute here or if I need two of them. Also, it would allow many-to-many relationships (an employee in several locations on a given month), which is not supposed to happen in this case and I'd like to be able to enforce this in the data model.
Am I missing something obvious here? What is the "correct" and properly normalized solution? Or should I just leave the FK constraints out?
I'm using CoreData for the first time in one of my project. My table involves FOREIGN KEYS and since CoreData doesn't support FOREIGN KEYS, I'm having some issues.
Below is the structure of my tables.
My Problem is the establishment attribute.The establishment attribute is supposed to hold the name of a particular facility from the Facilities table. However, since it's a relationship, Xcode expects a Facility rather than just a name of a facility (NSString).
Is this possible, or am I just mixing up FOREIGN KEYS with RELATIONSHIPS in CoreData? How would I solve this problem?
Thanks in advance.
A relationship is not a property, so it does not have a type. In the model editor you add a relationship explicitly.
From your diagram, I see that you did not set the inverse relationship. There needs to be a corresponding relationship from name to the Assessors entity. (Set the "Destination" to Assessors in the model editor.)
I would also suggest to rename a few items.
First, use singular: Assessor, Facility. These are objects (comparable to classes), not tables.
Second, because your name attribute refers to an assessor, call it assessor, and similarly call its reverse relationship facilities (it is a to-many relationship in this direction, so the plural is appropriate).
If you need the name of the assessor of a facility, you use
facility.assessor.name
This should make it obvious why you do not need foreign keys. Indeed, I would urge you to think that it is not Core Data that does not support foreign keys, but that it is the traditional relational databases that do not support relationships!
I have 2 entities in my domain that have a one-to-one relationship with one another.
Entity Business has a Promotion. And Promotion has a Business. I know this doesn't make a lot of sense and I could as well integrate the fields of Promotion into my Business entity, but I'm dealing with a legacy database here and I'm trying to model my domain on top of it without changing anything in the database for now.
My problem is that although the relationship goes both ways, it's only stored on the side of the promotion table that has a business_id foreign key, but there is no promotion_id foreign key in the business table. So when I try to run my app, Grails can't find the promotion_id column it expects to find for the promotion field in Business.
Is there any way to model my domain entity so that it understands that the column for the relationship is in the destination table only?
Right after I asked this question, I found my own answer: using hasOne as explained in http://grails.org/doc/latest/ref/Domain%20Classes/hasOne.html
I'm using Entity Framework 4 and with a Database First binding, and EF is not generating the entities for a few of my tables. I'm not getting any errors, and no matter how many times I select the tables to generate from the "Update Model from Database" popup menu on the design surface, the same tables are still missing from the model.
I get no errors in the wizard. They just don't get generated. Any clues?
EF requires a primary key on the table. EF will not map tables for which it can't find or derive a primary key. If all columns are nullable, it can't assume a primary key. If one or more columns are not nullable, EF will evidently derive a primary key for the table.
EF will ignore table without primary keys.
Options I can think of:
Did you check the box next to those tables?
Did you previously add them, then delete their entities but keep the cache of the tables?
If so you can remove them from entity browser window and re-add them
or manually add entities and define the table they map to in mappings window.
Perhaps tables were classified as relations instead of entities?
You can manually add the entities and choose the table they map to in mappings window.
Actually, in my case, it doesn't work because I was using a hierarchyid field as a primary key and EF doesn't work with this field type, so, it didn't import the table, because a valid PK is required.
A possibility is when you're using tables with some different field types, as hierarchy in SQL Server.
Without Primary Key Tables where Skip Automatically on EF, OtherWise You Fix a Value as Not Null.
When mapping an ER diagram to a relational schema, my textbook says that in step.. whatever.. a new relation S should be created for multivalued attributes. But if the multivalued attribute is the primary key of R... that leaves the R with no primary key and S with no primary key?
This is an excellent question and something that always bothered me about the textbook explanations of how to eliminate "complex" types.
The question you need to ask is: What is being identified by the sets of values? What are you trying to model? Most database architects working with SQL would probably say that you ought to invent a new attribute to identify the sets of things that would have made up your multivalued attribute.
Another solution is to embrace "complex" types as first class attributes in their own right - not "multivalued" attributes but sets or arrays that can be assigned to a variable as a single value just like any other value. The Tutorial D language permits relation-valued types withing relations. e.g.:
VAR r BASE RELATION {foo RELATION {bar INTEGER} } KEY {foo};
where foo is a relvar nested within r.
SQL however doesn't support anything like this. Nested tables are supported in SQL but are not usually allowed to be part of keys so in SQL you always have to create a new identifying attribute. In a true RDBMS you arguably shouldn't have to create another attribute because any supported type ought to support being part of a key - if it didn't then you wouldn't even be able to project on that attribute because the result wouldn't contain a key.