What is an enum?
An enumeration corresponds to a set of values that are each represented by a literal, which is more convenient to deal with. In your example, you'd work with Sunday..Saturday whereas you could, if needed, also work with an integer 0..6, which is less convenient.
What about enum types in ERD?
While we mostly use familiar types of known DBMS systems, the theoretical definition of an attribute according to P.Chen, the inventor or ERD, is much broader:
An attribute can be formally defined as a function which maps from an entity set or a relationship set into a value set or a Cartesian product of value sets.
So you could very well use attributes of a home-grown enum type. It's just that ERD does not provide any convenient way to describe the set of possible literal values. You'd probably have to describe these in a comment box or outside the diagram.
What's the ERD native equivalent?
But do we really need enums in the first place? After all, your enum DayOfTheWeek just corresponds to an entity, that would have the following values:
+---------------------+
| DayOfTheWeek |
|---------------------|
| Id | Day |
|------+--------------|
| 0 | Sunday |
| 1 | Monday |
| 2 | Tuesday |
| ... | .. |
+---------------------+
Son in an ERD, you'd best represent enums as entities.
This has several advantages:
- You abstract from the values whenever possible
- You can add new values whenever needed
- You could easily localise your code, replacing the days with their translation in local language.
- You could easily internationalise your design, by adding Day name in several languages.
- You'd have comparison/matching as efficient as with enums in OOP thanks to the primary key
- You would use the enums as easily as any other entity in relational queries.
The only drawback of this approach is that you still have no way to document in the diagram the entity's values.
