Entity relationship diagrams are another very commonly used set of diagrams. They can display the system that is and the system to be in terms of relationships between different entities within the system. The system as is and the system to be involve conceptual items that are generally structured from finer items and are often interrelated with each other. Diagrams or entity relationship diagrams are classical notation for declaring conceptual items and their structural properties. There are many, many variants and extensions culminating in class diagram notations in the UML standard and they can be built systematically. We are going to go about it the messy way. However, you do need to know that there are three core constructs. These are entities, attributes, and relationships. Entities are classes of concept instances that have distinct identities and share common features. These common features could be attributes or they could be relationships. These components are represented by a rectangle. For example here, we have a meeting being a distinct entity that is characterized by a date. An attribute is an intrinsic feature of an entity regardless of the other entities. It has a name and a range of values. For example here, we have a meeting that has a date, participants, that has a name, address, and an email. A relationship, then, is a feature that conceptually links the entities. Each entity plays a specific role in the conceptual link. The airity of the relationship is the number of entities linked by it. For example, invitation is a binary relationship linking the participant, with the role of invited to, with meeting, with the role of invites the participant. Relationships can also be characterized by attributes, which are displayed in a rectangle that's hanging up at the bottom of the relationship. For example here, we have constraints. A participant may have constraints on particular meeting dates and locations. These are captured by the rectangle which links the participant and the meeting entities. Also contains two attributes. A range for the attributes could also be given. For example, like a set of time intervals. A multiplicity on one side of a relationship specifies the minimum and maximum number of entity instances. Those instances go based on one side to the other. So they can be linked at the same time to a given single sub-tuple of entity instances on the other side. By that, I mean, let's just take an example here. We have one, two asterisk. That's multiplicity on the meeting side of the invitation relationship. And that means that the participant instance may be invited to zero to however many meetings. Conversely, if you look at the other line there, a meeting expects at least one participant. An informal definition should annotate every entity in a diagram to avoid specification errors and flaws. For example, a participant could be listed as, person is expected to attend the meeting at least partially under some specific role. They appear in the system when the meeting is initiated and then they disappear when the meeting is no longer relevant to the system. Entities can also be specialized into subclasses. An instance of the subclass must be an instance of the super class. For example, we have a participant being specialized into important versus normal participants. Important and normal participants inherit the attributes of that superclass. This allows for rich structuring mechanism for factoring out structural commonalities into super classes. This is very similar to inheritance in object-oriented programming. They can also override general attributes and specializations as you see right here in the case of an important participant. Entity-relationship diagrams are very common because they are simple. They are simple graphical notation for structuring and relating domain concepts. These are so much easier to read and understand to, say, just a flat list of definitions and a glossary. They're also more structured than relational tables in which you can't really attach any kind of value pairs to single tuples within a table, at least not easily. Also, Diagrams allow you to put in these multiplicities allowing simple statement patterns to be formalized. Specialization and inheritance help us to factor out commonalities to identify features that need to be reused and enhance modify ability. Thus, we're also helping the developers to relay entities very clearly to objects. However, there is no distinction between the requirements and the domain descriptions. For example, patron and book copy have a relationship, called loan, going from zero to max on the book copy side. This is a prescriptive statement. Zero to one on the patron side, however, is descriptive. This is a descriptive statement because it reveals that a book cannot physically be borrowed by more than one patron at a time. So, as you go about making this diagrams, keep thinking what item should appear. And what are the criteria for making your choices. You can also simplify Diagrams to class diagrams. And here, we have a really brief example. These are very popular due to object-oriented programming. And they're simple to represent in any UML drawing tool because UML in itself is an object-oriented modelling language. Class diagrams don't give you much, but they can be useful.
