Relationship properties in 'Oracle SQL Developer Data Modeler'

Question

I have four questions regarding to 'SQL Language' and 'Oracle SQL Developer Data Modeler':

1. What is the meaning of source optional or target optional in 'Oracle SQL Developer Data Modeler' relationships?

I it something related to'Ordinality' of the relationship?

Actually I make two different logical models. In the first one the source is optional, while in the second one the source is NOT optional.

But the Generated DDL files for both of them are them same. Why?

2. Why when we make a 1:N relationship, 'Identifying' in logical models, then the 'target optional' check box becomes DISABLED??

3. Why an M:N relationship can not be 'identifying' eg in M:N relationships the identifying check box is disabled?

4. What does 'in Arc' check box means in relation properties window?

Answer 1

1. In 1:N relationship, the meaning of 'target optional' is that the corresponding attribute can be NULL (for example, a user exists without any subscriptions). I can't understand what the 'source optional' is in a 1:N relationship, in a relational model. However, in a ER-model, a source can be optional. Why not? Why can't you forbid a citizen to exist without a passport, for example? But I'm sure it can't be implemented in (forward engineered into) a pure relational model. However, it may be forward-engineered into some constraints (triggers, for example). I haven't ever tried that.
2. 'Identifying' actually means the foreign key (in the target) is a part of the primary key, so it can't be NULL. However, anyone decide to use surrogate keys instead, I think.
3. In a ER-model, the term 'Identifying relationship' isn't applicable for M:N relationships. At the worst, an M:N relationship can be treated as always-identifying. It may be confusing, because, in the corresponding relational model, an M:N will always be a table with two foreign keys, and if you imagine them like that then an M:N is always identifying for both foreign keys, but, of course, in a relational model, neither 'identifying' nor 'relationship' exist.
4. You can declare a super type for an entity (so it appears in a super type's rectangle and as well can or can not inherit its attributes). When you create a relationship from a super type to another entity, if the 'subtree generation' is set to 'table per child' for the source entity, the relation is forward-engineered into an arc. The arc means creation of foreign keys on the target table (one per the source's child type) and a constraint for each of the keys allowing non-null for only one of them.