Navigational models is a legacy of obsolete databases tachnologies that have been supplanted by the relational model:
- The prehistoric hierarchical model allowed to group records in a tree. So every record has pointer to the related records. Navigation goes top down and was as far as I know unidirectional.
- The less prehistoric network model was an alternative where navigation between records was more powerful, and not necessarily limited to tree structures. It gained some popularity as it could relate records very efficiently in a time where relational databases were not very performant on smaller computers (remember Oracle 5 had a table locking mecanism!)
Both where based on fixed, structured records, and the navigation needed to be fixed up-front. THis is the past. Don't go-there if you want to learn modern ORM or NoSQL. The translation from an UML class diagram to a database model is straightforward. If you need to subdivide large classes into smaller one (like Employee and Address), it means that your classes are too large. Fix it in the original UML model: decompose the classes in smaller classes.
UML allow to make associations navigable (but it's not useful if you target a relational database in the end). THere are then a coupe of techniques that allow you to easily build the tables from that model, using for example identity fields, foreign key mapping (for one-to-one or one-to-many) or association table mapping (for many-to-many). But there are full articles or books on these techniques and it would be too long to develop this here.
P.S: you need to improve your English. French literature on the topic is too poor. I can tell from my own experience. ;-)