There are many schools of thought regarding what logic & rules you can put in the database, and this will vary somewhat on the capabilities and type of the database.
One thing for sure, though, is that if you don't put sufficient domain logic in your database to maintain your data's integrity, then you should wrap your database in a service and have all your applications access the service instead of the database directly.
I agree with Wikipedia that the entities, their relationships, and requirements about their referential integrity, as well as other constraints, are part of the business/domain logic — yet belong codified in the database (if, say, relational), or in a service wrapping the database, say, if NoSQL. I don't think you can truly separate data & persistence from business/domain logic, as the data's schema simply is logic for and of the business domain. (I don't think that using xml is going to fundamentally solve anything in this regard — it just moves the problem to another technology.)
I personally feel that one-to-many relationships sometimes are exactly what we need, yet other times can be thought of as an optimization on many-to-many relationships, and, as such can be a premature and (business/domain) limiting optimization.
For example, designing the data model to have one office per instructor/professor, or one department per instructor, could work well for a long time, then fall on its face when encountering a rare scenario that an instructor/professor teaches in two (or more) departments.
Other examples of premature optimization in schema is creating a separate identities for Teacher entity and a Student entity. Now a student who teaches or a teacher who themselves takes a course has to have two identities in the system. Preferred would be a Person entity that can play multiple roles as needed over time. (This also goes to using many-to-many relationships over one-to-many.)