Does multiple data processing violate the principle of interface separation?

I have the code.

@startuml

interface DbReader{
{abstract} read()
}

interface DbWriter{
{abstract} write(obj)
}

class DbConcrete {
read()
write(obj)
}

DbConcrete .up.|> DbReader
DbConcrete .up.|> DbWriter

Reader ..> DbReader
Writer ..> DbWriter

@enduml

The Reader class uses the DbReader interface, and the Writer class uses the DbWriter interface.

But the specific implementation of the read and write methods is in the same class DbConcrete.

And it would seem that the interfaces are separated. But the Reader object has become so dependent on the real object of the DbConcrete class. Yes, it only depends on the reading interface. But whoever writes the DbConcrete class to improve/correct the write() method must also take care of the read() method. It seems that the ISP speaks not so much about the interface as about the prohibition of dependence on fatty entities.

Am I thinking correctly? Is the implementation above violating the ISP principle.

I don't have my copy of APPP with me at the moment, but as far as I recall, the Interface Segregation Principle states that interfaces should be designed in such a way that client code shouldn't be forced to depend on more methods than it needs. It really doesn't have anything to say about whether or not developers are allowed to edit implementation classes.

You're probably thinking of another SOLID principle, the Single Responsibility Principle, which says that a class should have only 'one reason to change'. There's some 'give' in that definition, so you could, for example, say that every database schema change is a reason to change, in which case you may have to edit more than one method of the concrete class.

As I understand it, the design proposed in the OP looks fine.