This is really a fundamental conceptual question concerning the basics of the relational model of data. Your desire to learn how this really works is admirable, and people should tolerate dumb questions for that reason. Unfortunately this doesn't lend itself to the kind of short, crisp Q&A that this site is really good at.
A major idea in the relational model of data, starting in 1970, was to get rid of pointers embedded in data records. The reasons why embedded pointers were a problem is too deep to go into here, but you can read about it in introductory books on database. CJ Date is a good author, and there are many others. Foreign keys do the work that pointers do in non relational databases.
A foreign key duplicates data, and this is intentional. If you don't want foreign keys, then you don't want a relational database, and you don't want to use SQL.
Other responders have told you how to join data by specifying a match condition between History.EmployeeID and Employee.ID. They have also told you how to get around update synch problems using cascaded update. I would offer the general opinion, in addition, that making ID's mutable is to be avoided, when possible.
What the other responders may not have mentioned is the role played by indexes and the optimizer in making a whole relational DBMS work, and work pretty well, thank you.
Indexes provide a mapping between key values and pointers. These mappings are used by the optimizer to come up with a strategy for retrievals and joins that can be hundreds of times faster than brute force scans of both tables. It doesn't matter much when the tables are small, but it matters a lot when the tables get big. Again, a book on databases will teach you how indexes come into being, and how they are kept up to date.
Non relational databases, that use pointers instead of indexes, can be made to run faster, for certain limited purposes, than relational databases. These non relational databases are good for speed, but they are very limited when it comes to making multiple uses, in different contexts, of the same data. They are also very limited when it comes to adapting the data structures to changing requirements. If you don't need to do any of this, then maybe you don't need a relational database.
Some database systems have been developed since the heyday of relational databases that are even more flexible than relational databases, at a cost of introducing even more overhead than indexes and optimizers do.
This answer just scratches the surface of what I think you are really asking.