To the best of my knowledge, NORMA imports what is in the catalog of an RDBMS schema. So what you are seeing in the object-role model is what is in the RDBMS catalog. Thus there is no way automate the import of what is not there in the first place.
It's a long time since I looked at the code but I suspect that the import code may use "has" as a default predicate.
One of the aims of NORMA's reverse engineering feature is to allow a NORMA user to "Audit" the contents of an RDBMS schema.
For example, suppose you imported a schema that contained the fact type "Student (.nr) has Address(.nr)"
You could change this to "Student (.nr) lives at Address(.nr)"
or
"Student (.nr) was born at Address(.nr)"
If the two addresses are different, and you need to record both types of facts, then you create two fact types and change the schema accordingly.
This may have a knock-on effect that requires changes to the code that is used to read and write to the database.
In my experience, many database schemas are not well designed.
This means that auditing a database is sometimes a lengthy and detailed process
The ORM audit process enables "domain experts" to validate what the database schema "really" says and then to do what is necessary to get it right.