Is this schema usable for multi-tenant clients?How to remove multi-cascade paths?
To achieve multi-tennancy you should limit the number of relationships you have to the factor that determines the tennant.

For example, each of Course, Department and Staff have a foreign key to School.  However, these child tables are also interrelated.  Is it necessary for Staff to have a schoolid?  You can get to the school a staff member works for by following the foreign key to Course.

Similarly, you have grand-child tables (SD and DSC) which are relating tables in curious ways.  What has "months indicating duration of the course" to do with which staff member is teaching the course?  Is it really necessary for DSC to relate to Staff?  Also, you appear to have repeating groups defined in your SD and SDC tables.  I believe you may have a normalization issue.  

By over-relating tables you create cascade cycles.  Consider the following ERD as an alternative:



Here there is only one potential cycle to be concerned with, instead of the several that are in your current model.  Fewer potential cycles means less extra work that might need to be done with triggers instead of declarative referential constraints.  This keeps your system simpler and more maintainable.