Basically, any relationship A to B with an eOpposite with Containment=true could be seen as two SQL tables A and B, where B has a foreign key constraint to A with 'on delete cascade', so in classical UML words compositions.

Some more details on the EMF semantics:

EMF models are basically tree models with additional edges that transfer them into graphs. Container and containment manage the model's backbone which is the underlying tree structure: each of your types except for the root and externally defined types needs to be (transitively) contained.

You start by defining types directly under root and can then define more types that rely on those. Often, you allow a type A to contain a list of Bs and each B maintains its parent connection as a 1..1 connection. This is a normal tree connection (many children but exactly one parent). It is also possible to define a 1 to 1 containment connection to a child - and probably even other connections.

But each existing element in your later model has exactly one route to the model's root that follows the containments upwards in the backbone tree. Other relationships that define no containments will not add new elements to your model but just define (helpful) connections between existing elements.