One way to do this would be to define the material-properties table with three values for its primary-key:   material-ID and property-id and version-number.

To obtain the “current” properties of the material, you link on material-ID-plus-version. If you need to look at prior versions, link on material-ID alone.

In a typical ORM-setup, you would probably define one object to return “the current properties only” and a separate object, albeit referencing the same underlying SQL table, which will return “all versions of all properties.” The latter object would most-certainly be defined as read-only.

I respectfully dissent with the admonition to “use triggers,” out of concerns that triggers can be very time-consuming in many implementations. (But I say that having given the prior posting “only a passing glance,” not a careful and thorough consideration, and my dissent should be considered in that light.)