Relational DB Concept

Question

I am trying to lay out the concept for a Relational DB and I ran into some conceptual Problems:

1. If I have multiple discrete Entities that are "nested" in each other/have a hierarchy e.g.:

Bosses can have multiple Employees. These employees have different Projects they do and One Project has again multiple sections.

So

B1-Bn:

      E1-En

           P1-Pn

                Section1 -SectionN

How would that be best mapped in a database?

Or in other words, how is this hierarchy best mapped in a relational db?

1. Now I have Costumers that interact with these Employees.

They are met by the bosses Then they decide which employee will work for them. Then they are assigned Projects, with one or more sections.

How would that be best mapped.

1. the Relations 1-n, m-n, 1-1: Can they be used for e.g.:

This is a Foreignkey because of the 1-n relationship. This is a ManytoManyField because of the m-n relationship.

1. And is there a excellent online tool to better understand/visualize that.

Thanks so much for your time!

Answer 1

You may want to follow a course on relational database design; this subject takes more than a few days to explain or master. But you are on the right track.

The first thing you may be seeing is a hierarchy, but before you know it there will be relationships that aren't hierarchical, so a network is formed. This is why relational databases do not work with hierarchies.

You identify different types of entities and have one table for each type.

For each entity type you identify the properties of such entities - each property will be a column of the table. If a property does not have an atomic value, but a structured value, these structured values must be regarded as an entity, and must be given its own table, and the property will be a foreign key referring that table.

In this way, you will form a network of tables linked by foreign keys. This is called an entity-relationship diagram. Many designers advocate creating such a diagram first, without mapping the entity types to tables directly. They allow many-to-many relationships between entity types in the diagram. A foreign key between tables on the other hand is always many-to-1 or 1-to-1. So these designers have an "implementation" step in which they introduce an additional table for each many-to-many relationship. Personally I don't use many-to-many relationships in my diagrams to begin with.