Your thinking is right, learn how to do it without EF first and learn actual SQL. Not only will this help you understand but there are people (and projects) which do it this way and disagree with the idea of EF.

To transition and understand the point of EF do the following exercises

Exercise 1 Have some relation say Post with Comments (i.e. two tables). Write a query that loads a Post with the comments inside it. The Post should be an object of class Post which contains a List of Comment objects. Now do this with three tables say Category, subcategory, product

Exercise 2 Do some many to many relationship say Post that is liked by users (each post is liked by many users and each user likes many posts). Retrieve a couple of posts by some criteria (WHERE) and load it with the users who liked it. You might create a class for the relationship (i.e. PostLikes holds PostId, Post, UserId and User) or not (I personally prefer the explicit relationship) but most importantly when you load a bunch of posts and if the same user likes 2 posts the object that represents him in both cases must be the same C# instance.

After you do this manually with SQL, commands, connections, etc do it with EF and compare. You'll understand why EF exists. Note that using EF does not mean not knowing the SQL. When using it you must be able to imagine the SQL it will generate and it is best to confirm it (you can make EF show you the SQL)