NORMA doesn't yet provide graphical support for those two constraints. Nor does it directly support a temporal range data type.
As discussed below, there are multiple ways (I show two ways) to model the basic scenario, but currently those constraints need to be added as textual constraints and implemented manually.
We added support for graphical value-comparison constraints a few months ago, but these are not sufficient to capture the two constraints under discussion.
Model 1 Fact Types (role names shown in square brackets):
F1: Teacher(.Nr) reserved ClassRoom(.Nr) for Period. -- Add UCs on the role-pairs for (teacher, period) and for (classroom, period) assuming these are desired.
F2: Period started on DateTime [start]
F3: Period ends on DateTime [end]
Use F2 and F3 to identify Period as a coreferenced entity type.
Model 2 Fact Types (each is mandatory, and n:1):
Reservation(.Nr) is by Teacher(.Nr).
Reservation is for ClassRoom(.Nr).
Reservation starts on DateTime.[start]
Reservation ends on DateTime. [end]
Instead of identifying a reservation by a reservation number (recommended), you could identify it by combining teacher, room and start. At any rate (teacher, room start) and (teacher, room. end) have external UCs so they determine a reservation..
Add value comparison constraint: For each Reservation, start < end. (you can do this graphically)
As an example, one of the two required constraints may be stated informally as "No distinct reservations of a given classroom may non-trivially overlap in time" (if one reservation starts the instant the other ends, this is trivial overlap, which I will allow -- I'm ignoring finer points about discrete vs continuous time).
This constraint may be formally specified in FORML as follows:
For each Reservation1, Reservation2 and Classroom
if Reservation1 <> Reservation2 and Reservation1 is for that ClassRoom and Reservation2 is for that ClassRoom
then (Reservation1.end <= Reservation2.start or Reservation1.start >= Reservation2.end) .
We are currently working on extending NORMA to support such constraints and map them to implementation targets such as relational databases. But this is not yet done, so in the meantime I suggest adding the constraints as notes and implementing them manually.