Attributes

Data requirements should specify the data that is to be recorded for an entity type. What may not be easily visible, is exactly which entity type should hold which data. There has to be a critical view taken of the data requirements to ensure that the correct data is attributed to the correct entity type.

Identifiers

Attributes can be specified as identifiers of entity types. The main purpose of an identifier is to relate each occurrence of an entity type to the one subject it represents. As such they should possess uniqueness. Some entity types may have more than one attribute that can be said to be unique. In such cases, all such attributes can be considered as candidate identifiers but only one can become the entity types identifier. Which one can usually be determined from the context of the data requirements.

The identifier may often be a combination of attributes. This may be neccessary because an individual identifier may not possess the right level of uniqueness. Such composite identifiers are inferred from the data requirements. The manner in which they are inferred is important including how each of the occurrences can be distinguished.

Where a m:n relationship is resolved to an entity type and a pair of 1:n relationships, it is possible to use the identifiers of the related entities to form the composite identifier. It is permissible to change the identifiers name in order to help with its meaning. Importantly, this process is a general mechanism. The method, although it should be considered in m:n relationship situations, will not always hold true. It is important that the resultant identifier distinguishes occurrences corresponding to subjects.

Not all composite identifiers are identifiers of other entity types. A persons name cannot always be unique, even with an address.

Complex values

The assumption that attributes hold a single, atomic value is a simplification for the purposes of an E-R diagram and a requirement for when using relations. However, for data such as address details it may be required to split the address into its components of house number, street, post code etc. How should this be modelled? Such data is non-atomic holding multi-part values each having separate attributes. If the data requirements stipulate that a single, atomic value is required then an attribute of Address will suffice.

Entities or attributes

If a subject is seen as having existence, it can be an entity. If, however, it is a property dependent on the existence of another subject it may be an attribute. Representing data as entities or attributes is dependent on how the data requirements is examined. It may be possible for an entity to have a single identifying attribute, although its existence may depend on the existence of another subject. Attributes are simpler to use but entities will provide greater flexibility. Choices.......

Derived data

This is data that, in general, should not be included in E-R model as an attribute of an entity type. It is arrived at by processing data. Derived data may be included in data requirements. The inclusion of derived data in an E-R model leads to the inclusion of redundant data. Redundant because it can be obtained both as an occurrence of the attribute and by the processing to derive it. There may be occassions where it is neccessary to include it. A constraint will be required to prevent inconsistency with duplication.

Comments, suggestions, ideas to
Stuart Banner