how are the two different? Since both of the relationships consist of one set of objects say A which cannot exist independently and another set of objects say B whose existence is necessary for the existence of objects in the set A.
So are the two same or are their some fundamental differences that I am missing out on?
"Composition relationship" isn't a formal relationship type in ER. If I take it to mean a binary relationship (a,b) which is left-total (every a is related to some b) and in which a->b (an a is related to only one b), then an identifying relationship would be a specific kind of composition relationship. An identifying relationship has the form ((x,b),b) in which (x,b)->b. Non-identifying composition relationships would then include cases in which the component set is identified by its own attributes.
Related
I have 2 entities in which totally 12 properties are there of 3 variations of min, max and average of some particular type of fields. Hence I refactored the 2 entities into 3 entities making the 3rd entity as 'Values' which contains 3 properties i.e min, max and average. And reduced the 12 properties into 4 relationships. Here's a replica of my models as an example in the image below.
As you can see I have one-to-one unidirectional relationship with the 3rd entity. However Xcode keeps on complaining about 'Inverse' relationship.
As per me I can add 4 relationships in 'Values' and update all to become 'inverse', however this doesn't seem to be the right solution as when the second entity gets tied to the 'Values', it will have additional 3 nil relationships and whereas in case of first it will have 1 additional nil relationship. Both of these are unnecessary.
Refactoring 'Values' and splitting it into two similar entities also is not a good solution either I believe.
Hence can anyone suggest me what is the right approach or best practice to solve this problem. Let me know if I'm unclear anywhere while describing my issue.
Based on your description, I would undo the refactoring and go back to using properties instead of relationships. You're adding complexity for no real benefit, and the Values entity is (as you're finding) too generic to really be useful or meaningful. This refactoring isn't serving any useful purpose; don't fix it, revert it.
You should look into Weak Relationships (Fetched Properties) for how to manage relationships correctly and the solution for your error code.
Most object relationships are inherently bidirectional. If a
Department has a to-many relationship to the Employees who work in a
Department, there is an inverse relationship from an Employee to the
Department that is to-one. The major exception is a fetched property,
which represents a weak one-way relationship—there is no relationship
from the destination to the source.
Also, if you want to make things easier, you should look into (if possible) avoid 3 objects and have a single object, or two objects, with the propertiesToFetch of the NSFetchRequest in mind. This way you can fetch your Entity , keep the properties in a single Entity, but only fetch the properties you want and avoid the overhead and memory consumption of fetching properties you are not going to use.
Whichever fits your needs, you have the options. GL
When I try to make the inverse relationship of a entity equal to the same as another one to one relationship's inverse I chose, it replaces the other one I chose. Why can't I have multiple?
Because that's how Core Data works. A relationship may (and should) have an inverse relationship. It can't have multiple inverse relationships. If you assign an inverse where one already exists, you replace that inverse. What you're seeing is normal and expected.
I need to create an ER diagram and a relational model for a hospital. I have kept it simple to 3 entities. Please can someone have a look and tell me if I have normalised this correctly?
I am not sure it there should be a : relationship between the trust and patients? Does a person assume that the first entity is a single unit, in this case a hospital has x relationships to....
Diagram 2:
ER Diagram & Relational Schema
Your normalization isn't correct. First of all, you don't list functional dependencies. Without that, any attempt to normalize is just guesswork.
Now, I can make a reasonable guess, but even with that you have some problems. The Hires and Cares for relations aren't reflected in your 1NF/2NF/3NF tables. In your 2NF, you introduce a Shift relation that was presumably derived from Doctor in 1NF, but Patient_ID wasn't present in the latter, unless that's actually what the Shift column was for, but renaming fields isn't part of normalization. Also, what happened to Hospital in 2NF? It reappears in 3NF but with a Location attribute that was derived from where? Also, you're not indicating a primary key for Shift, is it correct to assume the combination of all 4 fields constitute a candidate key? It's good practice to be explicit about your keys.
Can an entity be without attributes?
Your Hospital relation does have an attribute - Hospital_ID, which represents an identity relation. Remember an attribute is a binary relation, and Hospital_ID -> Hospital_ID qualifies.
I am not sure it there should be a : relationship between the trust and patients?
What is the trust? It isn't indicated in your diagram at all.
Does a person assume that the first entity is a single unit, in this case a hospital has x relationships to....
Many-to-many relationships are decomposed into two or more one-to-many relationships, and in reading the cardinality indicators we tend to put the singular entity first, but this isn't a rule or a safe assumption. Be explicit about cardinalities.
I'm new to Core Data and I'm trying to implement it into my existing project. Here is my model:
Now, there's some things that don't make sense to me, likely because I haven't modelled it correctly.
CMAJournal is my top level object with an ordered set of CMAEntry objects and an ordered set of CMAUserDefine objects.
Here's my problem:
Each CMAUserDefine object has an ordered set of objects. For example, the "Baits" CMAUserDefine will have an ordered set of CMABait objects, the "Species" CMAUserDefine will have an ordered set of CMASpecies objects, etc.
Each CMAEntry object has attributes like baitUsed, fishSpecies, etc. that point to an object in the respective CMAUserDefine object. This is so if changes are made, each CMAEntry that references that object is also changed.
Now, from what I've read I should have inverses for each of my relationships. This doesn't make sense in my model. For example, I could have 5 CMAEntry objects whose baitUsed property points to the same CMABait object. Which CMAEntry does the CMABait's entry property point to if there are 5 CMAEntry objects that reference that CMABait? I don't think it should point to anything.
What I want is for all CMAUserDefine objects (i.e. all CMABait, CMASpecies, CMALocation, etc. objects) to be stored in the CMAJournal userDefines set, and have those objects be referenced in each CMAEntry.
I originally had this working great with NSArchiving, but the archive file size was MASSIVE. I mean, 18+ MB for 16 or so entries (which included about 20 images). And from what I've read, Core Data is something I should learn anyway.
So I'm wondering, is my model wrong? Did I take the wrong approach? Is there a more efficient way of using NSArchiver that will better fit my needs?
I hope that makes sense. Please let me know if I need to explain it better.
Thanks!
E: What lead me to this question is getting a bunch of "Dangling reference to an invalid object." = "" errors when trying to save.
A. Some Basics
Core Data needs a inverse relationship to model the relationship. To make a long story short:
In an object graph as modeled by Core Data a reference semantically points from the source object to a destination object. Therefore you use a single reference as CMASpecies's fishSpecies to model a to-one relationship and a collection as NSSet to model a to-many relationship. You do not care about the type of the inverse relationship. In many cases you do not have one at all.
In a relational data base relationships are modeled differently: If you have a 1:N (one-to-many) relationship the relationship is stored on the destination side. The reason for this is, that in a rDB every entity has a fixed size and therefore cannot reference a variable number of destinations. If you have a many-to-many relationship (N:M), a additional table is needed.
As you can see, in an object graph the types of relationships are to-one and to-many only depending on the source, while in rDB the types of relationships are one-to-one, one-to-many, many-to-many depending on both source and destination.
To select the right kind of rDB modeling Core Data wants to know the type of the inverse relationship.
Type Object graph Inverse | rDB
1:1 to-one id to-one id | source or destination attribute
1:N collection to-one id | destination attribute
N:M collection collection | additional table with two attributes
B. To your Q
In your case, if a CMAEntry object refers exactly one CMASpecies object, but a CMASpecies object can be referred by many CMAEntry objects, this simply means that the inverse relationship is a to-many relationship.
Yes, it is strange for a OOP developer to have such inverse relationships. For a SQL developer, it is the usual case. Developing an ORM (object relational mapper) this is one of the problems. (I know that, because I'm doing that for Objective-Cloud right now. But I did if different, more the OOP's point of view.) Every solution is a kind of unusual for one side. Somebody called ORM the "vietnam of software development".
To have a more simple example: Modeling a sports league you will find yourself having a entity Match with the properties homeTeam and guestTeam. You want to have an inverse relationship, no not homeMatches and guestMatches, but simply matches. This is obviously no inverse. Simply add inverse relationship, if Core Data wants and don't care about it.
I'm trying to be a "good little programmer" and implement inverses for all relationships in my core data model. However, I've come across a situation that makes this seem impractical.
For simplicity, consider a general-purpose entity type called Location that contains an x attribute and a y attribute (and might contain other attributes, but let's keep it simple). Several different entity types may need to keep up with one or more location (players have an original location and a current location, cells have locations, destinations have locations, etc). Given all the different uses for such a general type, it seems impractical to make an inverse relationship in the location entity type for every instance in which it's used in other entities.
Is there an better alternative in Core Data for implementing a very general-purpose entity type that would prevent the need for relations without inverses?
Having received no answers, I'll share the pattern I started using to help in this situation:
Basically, I derive an entity type from the general-purpose entity type for each specific use, and then I can make relationships and inverse relationships to the derived entity type as appropriate.
For example, I can have a PlayerLocation entity type and a PlayerOrigin entity type, both with the general purpose "Location" as their parent entity type (so in object-oriented-think, they become classes derived from a Location base class). Then a Player entity type can have a to-one relationship (location) to a PlayerLocation and a to-one relationship (origin) to a PlayerOrigin, and each of those derived location types can have unique inverse relationships (owner) pointing back to the Player. Here's a pictorial:
This may cause me to create many more entity types than I originally envisioned, but it makes for a pretty clean object model with specific entity types that have clear relationships and inverse relationships.
Hope that helps others.