How to work with dependent (virtual) relations in relational DBMS, is it possible to use foreign keys with them?

Question

MySQL

Let's say there are two tables.
The first one (SAL) contains the id key, the name field, the year field, and the salary field. A person's salary in a given year, a tripartite relationship.
The second one (DEG) contains the id key, the name field, and the ed_degree field. The relationship between a person and something (eg, academic degrees).
In both respects, name is not a key.
Within the framework of the task, it becomes necessary to work with the relation generated by SAL. For example, (key name). This ratio depends on SAL, SAL changes - this ratio changes. But as long as it is formatted as a SQL query, it is Question 1.SELECT name, MAX(salary) FROM SAL GROUP BY name
What is the best way to work with this relation in MySQL? Can it be given its own name? Obviously, I can't create a table with (name, salary) because then it won't be guaranteed to be consistent with the SAL, unless (1) after every change in the SAL I will cause an update of this dependent table, and (2) I won't change it when whatever else. On the other hand, maybe there are ways to cache the result of a query, after all, this should be a frequent task.
Question 2: Is it possible to specify that name in DEG is the foreign key of this virtual/dependent relation?
PS My experience with SQL is two weeks. Perhaps the question is simple, but I do not know what words to google for.

Answer 1

https://dev.mysql.com/doc/refman/5.7/en/views.html
In general, google about views (views) and in particular about materialized views (materialized views) , this is a big topic about dependent tables and their coordination.

The process of setting up a materialized view is sometimes called materialization. This is a form of caching the results of a query, similar to memoization of the value of a function in functional languages, and it is sometimes described as a form of precomputation. As with other forms of precomputation, database users typically use materialized views for performance reasons, ie as a form of optimization.

Answer 2

Google about database normalization.
1.You need to move the name to a separate table, for example, let's call it emploee, which will just have a list of names, possibly with some other information and an id that is unique for each name.
2. Then there will be no name field in SAL, but id_emploee 3.
Change the name in the employee table, it will automatically change everywhere, because everywhere you will have only id_emploee, and not the name itself.
Accordingly, where you need a name, you need to do a join with the employee table in queries. But in the query from the example, you can not do a join, but group by id_emploee, which will work much faster than grouping by a text field.