I am trying to represent a 1:N relationship in Visio 2010 Professional using Crow's Foot notation. I want the parent side of the relation to be mandatory and the child side to be optional.

ie: -||-----O<-

When I click on the relationship, and select the miscellaneous properties/categories I find the: Child Has Parent Optional checkbox. However, the checkbox is grayed out and I can't deselect the option. So my relation looks like this: -|O-------O<-. I was wondering if I am doing something wrong or if there is any way to fix this. From searching google it appears to be some sort of bug or problem with Visio.

In the Miscellaneous settings for the Relationship, you will set the Relationship Type to "Identifying" to get the expected Crow's Foot notation.

I am grateful somebody has taken time to respond! Thank you!

However, by selecting 'Identifying' I change the entity from being a typical "weak entity" to a "ID Dependent weak entity" (Identifying Relationship) , which means a few things.

1.) The relation line will change from a dotted line to a solid line. (Which means a weak ID Dependent relationship, dotted line means Non-ID Dependent weak/strong)
2.) The identifier/primary key of the parent entity will be added to the child entity and form a composite identifier/ primary key in the child entity.

Both are undesired and cause the ERD to be inaccurate. 

I don't want to make the entity ID dependent. (Which means the entity depends upon another entity to exist. i.e. InvoiceLineItem entity would be dependent upon the Invoice entity) I want to alter the minimum cardinality or make the parent part of the relation mandatory. In Visio I can only alter one side of the relationship.

The parent side is always -|O which means a maximum cardinality of 1 and a minimum cardinality of 0 (or optional). I want to change it to -|| so the parent side has maximum cardinality of 1 and a minimum cardinality of 1 (or mandatory).

This also means I can't represent a N:M (many to many) relationship in the ERD. (I know you would never have a N:M in a data model, instead you would use two 1:Ns that create an intersection table or association entity)

The DBAs I have talked to told me its a flaw with Visio (unsolvable); and told me I probably can't get a refund. $560 Loss :(

Sorry for the necro-thread revival, but thought you might like to know about this workaround...

I only know this since it was specifically mentioned in my ISYS 340 class.

 

Basically, you can get around this issue with a workaround, but it has to be the very first thing you do upon creating the relationship.  Once you create the relationship, immediately change it to identifying, then change it back to non-identifying.  It will retain the double-bars indicating maximum / minimum cardinality of 1, but it will be dotted indicating a weak relationship.  

Graphical directions:

http://imageshack.us/photo/my-images/806/visio2010relationshipwo.jpg/

 

thank you so much for the workaround solution for this.  it worked!  i had wasted hours trying to figure out what i was doing wrong.  no telling how many more hours you saved me. 

Great thank you! 

Has anyone found a solution for this, or is MS working on it? 

I have several large data models that are maintained in Visio.  I find myself needing to make a change to one, and I cannot erase the model and restart it every time I need to change a cardinality.  At this point, I'm starting a search for a Visio replacement -- it is more important that our data model documentation be correct than to protect our investment in Visio. 

MS needs to get this fixed quickly!

As another user pointed out, making the relationship "identifying" has a much larger impact than just changing the cardinality -- it changes the PK.  This is not an acceptable solution.

I just saw your post. Did you remember to make the FK "Required"? If a value is required in the FK field, then the Parent must be "Mandatory" in VISIO's mind. The other posters are correct, you wouldn't want to tweak the identifying versus non-identifying UNLESS that's what you really meant. There are other implications.

Vwebster this bug exists in case of FK is required too. I can change FK from required to non-required many times but in ERD, relationship stays optional.

I hope that this workaround is simplest an works in any situation.

1) Disconnect relationship by simple button press in its Properties / Categories / Definition

2) Redefine Cardinality and Type of relationship in Properties / Categories / Miscellaneous as you want. (Ugli logic is out of action, all is possible now)

3) Associate relationship back by simple button press in Properties / Categories / Definition

 

I know this thread is abit old now, but is there any solution to this? Just got the license from my school. Gonna use this program hopefully for my next 2 years on uni. Can't go on using it if weak relations doesn't show properly.

I agree - PLEASE FIX THIS BUG

There is another solution.

Make the Foreign Key in the child Required BEFORE you draw the relationship to the parent.

It will then correctly show what you want  ie: -||-----O<-

If the Foreign Key is not marked as Required it will, by default, correctly draw  -|O-------O<-.

And thank you again; you just saved me a late night. Cheers.

Vwebster this bug exists in case of FK is required too. I can change FK from required to non-required many times but in ERD, relationship stays optional.

I hope that this workaround is simplest an works in any situation.

1) Disconnect relationship by simple button press in its Properties / Categories / Definition

2) Redefine Cardinality and Type of relationship in Properties / Categories / Miscellaneous as you want. (Ugli logic is out of action, all is possible now)

3) Associate relationship back by simple button press in Properties / Categories / Definition

Finally an answer that works for me. Use the above guidance, after disconnecting (but not deleting) the relationships in the properties page you can clear the "Child has parent - Optional" and then re-connect the relationships.

Some of the other answers do work however on a large diagram with a lot of tabs that repeat the same entities the above works best.