Is it an anti-pattern? Depends.
Good database design has a single canonical represention for any particular bit of information. In part this is to avoid all-too-easy inconsistencies--"a person with two watches never knows what time it is." It also improves maintainibility, and by avoid potential inconsistencies simplifies validation of code and data.
The SQL term is "normalization" [0]. In a fully-normalized database you can change the value of any one non-prime (key) attribute and still have an internally-consistent database; it may violdate business rules not modeled, or otherwise not match the real world, but all parts of the data model agree with all the other parts.
If you really have a hard-and-fast rule that "somebody is working" is equivalent to "restaurant is open", and you choose to model that rule in the database, then RESTAURANT.IS_OPEN breaks normalization. You can't flip "is_open" true or false without also changing the "is working" state of at least one employee.
However, it is common to de-normalize databases. For example, you may have "account" and "transaction" tables, and the current balance for an account is the monetary sum of all its transactions. But you may very well choose to have a BALANCE column in ACCOUNT, to avoid summing every transaction every time you want to look at the current total. The trade-off is that you must make really, really sure the redundancy is always known and always processed correctly.
If you do choose to de-normalize, there are better and worse ways to do it. IS_OPEN is pretty bad; every time an employee goes off-shift you have to look at all of the other employees to see if someone else is still on-shift and the restaurant is still open. NUM_WORKING (how many employees currently working at the restaurant) would be better; any on-/off-shift change only requires (atomically) updating a single employee row and the restaurant row. Or, you might have NUM_SERVING, to see if the restaurant can actually process customers.
It is a good idea to identify important potential inconsistencies (balance might not equal sum of the transactions), provide for periodic auditing, and specify how they are resolved (TRANSACTION is truth, BALANCE must be changed).
[0] https://en.wikipedia.org/wiki/Database_normalization
[1] https://en.wikipedia.org/wiki/Second_normal_form