Explain the concept of a derived attribute in Entity Relationship modelling.

A derived attribute in Entity Relationship modelling is an attribute whose value is calculated from other attributes.

In the realm of Entity Relationship (ER) modelling, a derived attribute is a special type of attribute that doesn't store data directly. Instead, its value is derived or calculated from other attributes within the same entity. This concept is particularly useful when the attribute's value can be obtained through a calculation or a logical deduction from other attributes, rather than being stored and updated manually.

For instance, consider an entity 'Employee' with attributes 'Date of Birth' and 'Age'. Here, 'Age' can be considered a derived attribute as it can be calculated from the 'Date of Birth' attribute and the current date. There's no need to store the 'Age' attribute and update it every year. Instead, it can be derived whenever needed.

Derived attributes are typically represented in an ER diagram within double oval shapes to distinguish them from regular attributes. They are not physically stored in the database, but their values can be derived when needed from the stored attributes. This approach can save storage space and ensure data consistency, as there's no risk of forgetting to update the derived attribute when the base attributes change.

However, it's important to note that derived attributes can sometimes lead to increased computational costs. This is because every time the value of a derived attribute is needed, it has to be calculated from the base attributes. In cases where the calculation is complex or the base attributes are large in number, this could potentially slow down the system. Therefore, the decision to use derived attributes should be made carefully, considering the trade-off between storage space and computational efficiency.

In summary, derived attributes in ER modelling are a powerful tool that can help maintain data consistency and save storage space. However, they should be used judiciously, keeping in mind the potential computational costs.