I have 3 entities like Member, List and ListMember. Member and List have many-to-many relationship, as a Member can be added to multiple Lists and naturally a list have multiple Members added to itself. I'm trying to keep the related records of Members and List in the ListMember entity. That is, when a Member is added to a List, then there must be a record created in ListMember entity with the Member and List.
My first question is, is there any automated way to do this, that is, can I define ListMember entity as a many-to-many relationship keeper or something like that?
Second question is, if there isn't such a way, how can I trigger a process which creates records with the Member and List in the ListMember entity each time a Member is added into a List, and how can I reach data from both List and the Member in the process?
For more info about the problem, here is my previous question which reduced the situation into this triggering thing:
CRM Dynamics How to set short list - long list relationship
You have 2 basic options when it comes to creating a M:M relationship in CRM:
Add the relationship and defining it as M:M will create your ListMemeber Entity for you, and adding a List to a member, or a member to a list will be populated in the ListMember Entity.
Roll your own Entity that basically does the same thing. You can also auto-populate fields on the form by looking up the regardingojectid
regObj = Xrm.Page.getAttribute("regardingobjectid").getValue();
The regardingobjectid will return the referencing entity that you came from when creating a new entity. This will allow you to populate the side of the relationship that you came from, so the user just has to select the other entity.
It sounds like you want option 1, so I won't go anymore in-depth on Option 2.
Related
I have just started a course on database design and have been given a homework where one of the tasks is to list all the entity types of a fictional hospital according to this pdf: http://docdro.id/mbzdtUg.
I am struggling to figure out what should be an entity type and what should not. I will give you a basic example:
"Staff" is obviously an entity type but each of the staff have to have details regarding their qualifications and work experience. Since a staff member can have multiple qualifications and multiple work experiences these cannot be attributes... right? So should "Staff Qualification" and "Staff Work experience" be an entity type?
According to entity definitions I have read entities should be independent and represent objects that actually exist. What does it mean for an entity to be independent exactly? The "Staff Qualification" and "Staff Work experience" entity types would not exist if the entity type "Staff" didn't exist. Therefore they aren't independent (???) nor do they represent something that exists (physical object). Then what are they if not entity types? Should for example "Appointment" be an entity type? I am really confused... any help is appreciated.
Thanks!
EDIT: Should mention that this should be following a Entity-Relationship model (ER)
EDIT 2: Example 2: A patient can be either a outpatient or a inpatient. Should I make these into 2 entity type or only 1 (Patient)?
Looks like you're on the right track and your understanding is correct. If you foresee that Staff table can have multiple qualifications or work experiences - then qualification and work experience itself should be separated into a different entity table, so should the Appointment.
This is also where the normalization comes into place - because you could have two different staff members have the same work experience (or qualification) - then technically you don't want to just simply have a child table for Staff as that would result in a lot of data duplication. Usually, using normalization principles you would instead create a separate entity table WorkExperience where you would have all your different WorkExperiences. There would be no relationship between Staff and WorkExperiences tables. But you would also create StaffWorkExperiences table (joining table/buffer table), which would be a child of Staff (1:M) , but would also have a constraint to WorkExperiences table (M:1). So essentially you would end up with Staff table linking to StaffWorkExperiences table and the StaffWorkExperiences table in turn linking to WorkExperiences table.
Lastly, if you also have a patient table and the patient can be either outpatient or an inpatient - then that is more like a property and there is no need to have an extra table - so you would have only a patient table and then another column (PatientType or something like that) to describe this particular property.
EDIT
I have added an example schema of how this would look like with a joining table.
I have two entities:
Patient
- firstName
- lastName
- scheduledAppointments <---->> Appointment
Appointment
- date
- times
- scheduledPatient <<----> Patient
Basically I have one Patient with many appointments. How do I set the scheduledPatient in the Appointments entity? I've tried this so far:
[self.appointment setScheduledPatient:[self.patientArray objectAtIndex:indexPath.row]];
self.appointment.scheduledPatient = [self.patientArray objectAtIndex:indexPath.row];
They work when I'm editing an appointment. But it returns a SIGBRT when I'm adding a new appointment.
Your code seems to be correct.
Therefore I suppose that most likely you have not defined the inverse relation properly in the .xcdatamodel file.
For what I understand you have a one-to-many relationships. That is, one Patient may have a number of Appointments. Therefore, an appointment belongs to one patient. In order for this relation to be semantically correct, you need to let it know how they relate to each other. In order to do so you need to specify what is the inverse element of each of the elements in the relation.
In the picture below you can see how a Region may have a number of states, and a state belongs uniquely to a region. Notice the arrow connecting the elements of the relation, how the "many" has a double arrow and the "one" has a single arrow.
I believe that you most likely forgot to specify this in the xcdatamodel file.
Check out this link for more information:https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdRelationships.html
Inverse Relationships
Most relationships are inherently bi-directional. If a Department has a to-many relationship to the Employees that work in a Department, there is an inverse relationship from an Employee to the Department. The major exception is a fetched property, which represents a weak one-way relationship—there is no relationship from the destination to the source (see “Fetched Properties”).
You should typically model relationships in both directions, and specify the inverse relationships appropriately. Core Data uses this information to ensure the consistency of the object graph if a change is made (see “Manipulating Relationships and Object Graph Integrity”). For a discussion of some of the reasons why you might not want to model a relationship in both directions, and some of the problems that might arise if you don’t, see “Unidirectional Relationships.”
I have a standard many-to-many relationship in my database between Person and Widget. A Person in an administrative role has access to ALL Widgets. In my application, I want to see which Widgets a Person has access to.
I have two high level options:
Explicitly manage the relationships. When a Person becomes an administrator, relate that Person to all existing Widgets. When a Widget is created, relate that Widget to all existing administrators.
At run-time, if the Person is an administrator, assume they have access to ALL widgets and bypass the relationship table when loading Widgets.
Is one option better than the other? Is there a name for this scenario?
I have been trying to apply option 2 using NHibernate and I can't seem to figure out how to get it to bypass the relationship table when loading all Widgets for an entity (and even if I could, this would unnecessarily load alot of information unless I load Widgets separately from the Person entity and apply paging).
I would map this by means of Roles.
Roles : Person = 1 : Many
So when you create a person, you also create a new Role, unless they are an Administrator in which case they use the existing Admin Role.
Then the problem is easy: You need a WidgetRole table.
When a new Widget is created, and entry is automatically added to the WidgetRole table for NewWidget, AdminRole
When a Person changes to an Admin Role, simply change their current Role.
imo this setup is logically simpler, than having a special Admin case.
I had to share the final solution - should help anyone trying to force NH to load up a relationship that is not explicit in the DB.
I was already creating sub classes of person and NHibernate is smart enough to recognize Administrator : Person and instantiate that Person as an Administrator (where Administrator has a table with a PK/FK PersonId)
I just added a new mapping override for Administrator...
mapping.HasManyToMany(x => x.Widgets)
.Table("AdministratorWidgetAccess")
.Cascade.None();
And I added a view called AdministratorWidgetAccess...
SELECT a.PersonId as [AdministratorId], w.WidgetId as
FROM dbo.Administrator AS a LEFT OUTER JOIN
dbo.Widget AS w ON 1 = 1
When running, if the Person is an Administrator it loads up all Widgets based on the relationship in the view, otherwise it loads up Widgets based on the join table.
I'm using an ORM (SQLAlchemy, but my question is quite implementation-agnostic) to model a many-to-many relationship between a parent class and its children.. I was wondering, what would be a simple way to express the concept "one of the children is the default/main one"?
For example, I'd need to persist the following:
This Person instance has Address X and Y, the main one is Y.
I saw this implemented using a "middle" class like "PersonAddressRelation" that would contain "Person", "Address" and the "main" flag, but I think it looks a bit cumbersome.. Is there a better way?
The simplest way would be to have a join table, PersonAddressRelation, and also a DefaultAddress column on the Person table that keys to the Address table.
A couple of remarks.
M:N relationships don't specify 'parent' and 'child', as there's no parent nor a child: there are simply two entities having an m:n relationship via a 3rd entity (the intermediate entity).
'Address' is in general not a valid entity type, as semantically it has no identity, similar to a 'name' has no identity (first name, last name). You'll see this when you look at re-using an entity instance of type Address: you won't do that in general. (though you will re-use a Customer entity instance for example, when the customer has multiple orders)
You want to specify an attribute on the M:N relationship (default), as it belongs there. This means that the relationship itself forms an entity (which is the intermediate entity, often it has just two FK fields forming the PK). This is called an 'objectified relationship', as the relationship itself is seen as an entity. Other examples of this are Employee m:n Department and you want to specify the StartDate an employee started for a department the employee works for.
So in general: create the intermediate entity, as it in general should be there, and add the attribute there. In this particular case with Address, be really sure you are re-using Address instances among related entities (Person). If not, merge Address with Person OR if a person can have multiple addresses, create a simple 1:n relationship between Person - Address, to normalize it out, though don't be afraid to merge address data into the entity it is related to, as often address data is really not re-used (so your m:n relationship is really not there: there's no Address instance which is related to multiple person instances.
I am just starting out with ADO.net Entity Framework I have mapped two tables together and receive the following error:
Error 1 Error 11010: Association End 'OperatorAccess' is not mapped. E:\Visual Studio\projects\Brandi II\Brandi II\Hospitals.edmx 390 11 Brandi II
Not sure what it is I am doing wrong.
I believe I can add some more clarity to the issue (learning as I go):
When I look at the Mapping details and look at the association, the column for operatoraccess table (from above) is blank and the drop down only includes field from the linked table.
The Entity Framework designer is terrible - I've had the same problem many times (and your problem too, Craig):
This happens when you have a many-to-one association which is improperly setup. They could very easily fix the designer to make this process simple; but instead, we have to put up with this crap.
To fix:
Click on the association, and go to the mapping details view.
Under association, click on Maps to <tablename>. Choose the table(s) which make up the many side of the relationship (ie. the table(s) which make up the *-side of the association in the designer)
Under Column, choose the table-columns which map to each entity-side Property. You get this error when one of those entries are blank.
I had the exact same problem and this is what I did to fix it.
Make sure you have an Entity Key set in your designer on the tables your making an association with. Also check that StoreGeneratedPattern is set to Identity for that Entity Key.
There's not a lot of information in your question, but, generally speaking, this means that there is an incompletely defined association. It could be that you have tried to map one table with a foreign key to another table, but have not mapped that other table. You can also get this error when you try to do table per type inheritance without carefully following the steps for implementing that feature.
Not sure of the answer, but I've just posted a similar question, which may at least help clarify the issue you are experiencing.
Defining an Entity Framework 1:1 association
I had to go back into the database itself and clarify the foreign key relationship
I had this problem in the case where I was creating both many to 0..1 and 0..1 to 0..1 associations. One entity needed associations to multiple tables, and that entity did not have foreign keys defined for those tables.
I had to do the table mappings step that is given in the accepted answer, but note that it wasn't only for many to many associations; it applied to all the types of associations I added for this entity.
In the Mapping Details view, I had to select the entity with the non-foreign key ID columns to the various tables. This is not always the "many" side of the relationship. Only there was I able to map the related entity property to the appropriate property in the original entity. Selecting the "destination" entity would not allow me to select the properties that I needed to, and the error would still exist.
So in short, I had to map using the table related to the entity that had the "non-foreign key" ID fields corresponding to the various entities' (and their tables') primary keys that I needed to associate.
Entity A
various other properties...
Id
ContactId
OrderId
etc.
Contact entity
Id
FirstName
LastName
etc.
In the mapping details, I selected Entity A's table. It then showed both ends of the association. I mapped its Entity A's Id property to its table's actual ID column (they had different names). I then mapped the Contact entity's Id field to the ContactId field on the A entity.
Simply select the many relationship table (*) from the Association>Edit Mapping & select the appropriate relationship