Is my DB design alright or not?
I see two potential issues:

Clarity on frames

I understand that a frame represents one (or more) intervals, as established by a company.

I believe you originally intended a frame to be a  block of time, and to allow multiple companies to use it. The potential problem with that is - what if one company needs to alter that frame? You basically have to create a second frame, and migrate over only the references for the one company to the old frame. This is possible, but would be a maintenance hassle (and would slow things down while you did it).

I also note that a frame can include multiple time intervals, and repeating time frames (allowing, I assume, you to set up weekly standing "appointments" where appropriate). If a frame represents a specific event (even if that "event" is a recurring weekly appointment, or a five-day conference), this shouldn't be a problem; If multiple events are re-using the same frame, then the maintenance issue mentioned above would grow even worse.

If a frame belongs to just one company, you don't really need the company_frame table; you can have the company_id in the frame table directly.

NOTE: One specific clinic may have many rooms, and many doctors, each of whom may have different appointments at the same time. It may be worthwhile to add another distinguishing factor to a frame - perhaps a location ("Room 2" in a doctor's office; "Conference Suite 100"; whatever's appropriate) to help differentiate. In some cases, it may be sufficient to use the doctor and the time interval (in a doctor's office, "Dr. Cameron, 15:00 - 15:30, 2018-03-23" should be distinctive); in other cases, you might need something more.

Data consistency

The next thing that comes to mind is the potential for data consistency issues. This is where the "circular" design comes into play.

In theory, with this design, nothing guarantees that a doctor associated with a frame is connected to the same company as the one that "owns" the frame. However, logically, all doctors associated with a given frame should belong to the same company as the frame.

Based on this, I think that it makes more sense that frame_doctor actually be frame_co_doctor, and that it be used to maintain a many-to-many relationship between company_doctor and frame instead of between doctor and frame (doctor would only be connected to anything else via company_doctor then).

Presumably, if a given doctor stopped working for company X, he would no longer be tied to the frames belonging to that company; he might still be connected to frames owned by other companies, though. And, company_doctor and frame would both have the company_id, making it easy to verify that the correct records are being linked - if company_doctor.company_id &lt;&gt; frame.company_id, then you shouldn't create the frame_co_doctor row.



Those are the biggest potential issues I see with the design as it stand now, and how I'd resolve them, based on what I know of your requirements. I may, of course, have misunderstood a requirement, or there may be some you haven't noted as yet, that would invalidate these approaches, but they're the way I'd look at it.