conceptual diagram abstraction and null values

In the conceptual scheme, which design solution is preferable to adopt if in a class there is an attribute which 1/10 of the cases has a value and for the rest 9/10 it has none? Should we keep the attribute in the class/entity or is it a solution to separate it and then create an association? I should keep it in the class and then manage it during the restructuring of the scheme.

Conceptually, in UML both designs are equivalent, since a property is either an attribute or an owned association end. More details here, where you could just replace the * multiplicity with 0..1.

Technically, in the database it is however a little bit different: The association is implemented with a join to another table. There is some overhead for doing the join. And if you're going to get it only when needed, there is a higher overhead. Up to you to see what advantage you'd value the most and what inconvenience you prefer to avoid (and benchmark if it's about performance):

• As a benefit of the separate class, you could save a tiny amount of space. But is it really worth it, as most of the DB engine do already save space for null values (at least for strings)?
• The benefit of the attribute is time, as it is available without query overhead. You just have to deal with the potential null value.

As a rule of thumb, attribute implementation is most generally the preferred alternative in your case, unless the the attribute describes a distinct object with its own identity (test: would it have sense to add other attributes to the potential separate class).