Skip to 0 minutes and 1 second The entity-relationship diagram provides you with the structural description of the system. It obviously deals with the relationships between the data storages. It has four components. The first one is called the object type. The object type tells you what kind of objects you are assembling there. Those of you who have some experience with databases will immediately think of the records in the database. This is not the record. This is this kind of meta-level, which describes what kind of fields you will have about the record. Those of you who don’t have experience with databases– just think about that you have different characteristics of those things that you store data about.
Skip to 0 minutes and 47 seconds The second part is the relationship, which is a connection between different object types. And it means that, for example, if an object type is a learner in FutureLearn. Another object type is a teacher in FutureLearn. Now what is interesting is that the same person can belong to different object types at the same time. For example, I am both a learner and a teacher at FutureLearn. Now there are relationships between the various object types. For example I am delivering this lecture to you. That’s one type of the relationship. However, there could be relationships also between objects within the same object type. Just think about the peer assessment exercise, which you will have, for example, in this course.
Skip to 1 minute and 39 seconds It means that that is a relationship between the learners themselves. Now these two are simple components, and there are two that are like compound components. So they are assembled somehow from these. The first has a really, really bad name. It is called associative object type indicator. Now this is a really, really long and really, really difficult-to-remember name, so what you need to remember about this is that this is something that is an object and a relationship at the same time. In even simpler ways, it is a relationship about which we also store some sort of data.
Skip to 2 minutes and 22 seconds For example, if one object type is this course, or the course is in FutureLearn, and you attended some of the courses, and you completed a certain number of steps in some of those courses, the FutureLearn database will store the number of the steps that you completed in the particular courses. So there is a relationship between you and the courses, and there is also some data stored about this. The final fourth type is called object supertype subtype indicator. Now the supertype subtype means that there are objects about which we– so two different object types of which we have some data that is the same. For example, we can say that we have all sorts of participants in FutureLearn.
Skip to 3 minutes and 16 seconds Some of these will be administrators. Some of these will be teachers. Some of these will be learners. But about all of them we store certain data– name, email address, when they logged in and so on. Now this means that here, the object supertype will be, for example, participants. And the subtypes of these will be the learner, the teacher, the administrator, and so on. The most immediate thing that you will store about the different subtypes of this object type participant is who can access what. So for example, I can access all the material. I can access the editing part of the material as a teacher in those courses that I teach.
Skip to 4 minutes and 6 seconds However, I cannot access who is doing what out of the learners. And there are probably some people with higher levels of clearance who can access more of this kind of data. So now, we look at the simple example of a medical facility where we look into the interaction between the patients and the doctors. So if you take the middle line, you see that there are doctors, and there is a relationship between the object type doctor with the object type patient. And the name of this relationship is invoice. What I’m talking about– the doctor is invoicing the patient. Of course, this is not the first step, but the entity-relationship diagram is not about functionality. It is not about time.
Skip to 5 minutes and 3 seconds But why I mention this, because this is the simplest relationship. There is another relationship, which is the diagnosis, which may involve more than two object types. So for example, in some cases, the doctor might invite a consultant, a specialist, about particular diseases to help diagnose the patient. Now once the diagnosis has been done, then some sort of therapy is prescribed to the patient. Now that red thing at the bottom– that’s this very difficult-to-remember component, which is a relationship and an object type at the same time, the associative object type indicator, which means that there is a relationship between the patient and the doctor, which is that the doctor is prescribing the therapy to the patient.
Skip to 5 minutes and 56 seconds However, we also want to store data about the nature of this therapy. For example, which medication need to be taken, how many times a day, when the patient needs to come for the checkup again, and so on. Now on the left end of the diagram, you see the final component, which is the object supertype-subtype indicator. In this case, there are two types of doctors in this particular medical centre. Some of them are employed by the organisation, so they are staff. And some of them are visiting, so they are not employed on permanent basis. Obviously, we need to store lots of the same things about them– again name, address, what their specialty is, and so on.
Skip to 6 minutes and 45 seconds However, about the staff we need to store, for example, monthly salary data, and how those are taxed, and so on. But about the visitors, we need the hourly rate, for example, by which they will be working on this temporary basis when they are actually attending this facility. So I covered now the whole diagram on this occasion, but it is easy if you want to try to add some more objects to this particular diagram. Thank you very much.
Entity-relationship diagram (ERD)
In relation to DFD, the ERD can be considered as a meta-level diagram as it focuses on the types of data/objects and how they are related.
The most significant challenge of ERD is obtaining the data. First you need to be aware of what data you need to build the system, then you will need to describe these on meta-level in the ERD. You need to identify the data owners as you need them to give you access to data. This sounds trivial but often it is a major obstacle as the owners often feel their authority being damaged by giving up their control over the data. Furthermore, you need to clearly map the access to data and in having this described in the system, you also take away the power of the data owner over those seeking access to data.
There are also technical issues that you need to observe:
Occasionally there are relations not only between different object types but also within the same object types (e.g. students are often put into teams).
There may be more than one relation between two object types (e.g. students are submitting their assignments and the teacher is marking them).
And the same object may belong to multiple object types (e.g. I am a teacher and also a learner in FutureLearn courses).
© University of Strathclyde