In PHP, creating a session is easy. You first declare it using session_start(). It handles creating a session cookie for you, and pretty much all of the hard stuff. When the user navigates throughout your site, you can read from and write to the session variables using the $_SESSION global object, which can affect which content you want to display to the user, and even how it is displayed.
What happens, is the server generates a secure random token on its side and then sends the value as a cookie to the client which the client automatically communicates back to the server on each request. The server takes this value and uses it to determine which object in memory to reference as the $_SESSION object.
However you want to handle the initial login is up to you -- I'm not going to get into that here. But once the user does log in, you want to indicate that in the $_SESSION global. In order to make it secure you will want to destroy any existing session and create a new one on authentication. The way I usually do it is I set $_SESSION['user'] on login (after destroying the previous session and creating a new one). That way it has another use, checking whether a user is logged in: if(isset($_SESSION['user'])).
This is basic functionality, but hopefully it points you in the right direction. Databases aren't necessary for sessions unless you're trying to implement logon/session policies or you're running your website in a cluster. That would be due for a more complicated discussion which I don't think would be appropriate to get into here.
Edit/Update:
It turns out I will in fact get into the specifics of a secure login system; If you want your login system to be up to standards in terms of security, you will need to properly hash (and salt) your password. It turns out there is a PHP method for that as-well.
Hashing basically turns whatever the input is into garbage that can't be turned back into the original input. Password hashing is used to prevent people from gaining access to the original password in the case of a server/database compromise where passwords can be potentially leaked. The most important thing to know when hashing is that the slowest algorithms work the best for passwords.
Salting is almost equally as important as the algorithm used to secure the passwords. The salt is a CSPRNG which simply gets added to the password before hashing. CSPRNG stands for Cryptographically Secure Pseudo Random Number Generator, and it's really just a fancy way of saying that it's a super random and unpredictable set of bytes. These bytes are randomly generated on a per-password basis to protect end-users against rainbow attacks, in which a single produced hash can be checked against large quantities of passwords. By requiring a single hash per attempt per password, it greatly reduces the chances of mass a password leak resulting from a mass hash leak.
A manual system would work as-follows:
When the user account is created, a row is inserted into the database 'users' with the username specified, and the hashed password. The hashed password is first salted (random data added to the password), then hashed using a slow password hashing algorithm. The salt is additionally added to the password hash before being inserted into the database. Optionally you may store something to identify the hashing algorithm used with it as-well. If you feel uncomfortable combining these values, you can also store them as separate database values.
When the login process is initiated, the database is queried in the 'users' table for the row with the key 'username' matching the username requested. That row is pulled which includes the password hash. First, the salt is taken away from the hash. Then the salt is added to the password given during authentication and that whole thing is hashed using the same hashing algorithm used originally. Then, if the end result matches the hash that is stored, the user can be successfully authenticated.
I hope I'm not confusing you too much with my explanations. Ashley Madison apparently missed the memo entirely so if you don't understand, don't feel bad. You're not a multi-million-dollar website. The most issues come from when people take it upon themselves to accomplish things beyond their skill-set. In that regard I certainly recommend that you use the built-in, or at least open-sourced and publicly recommended password hashing functions whenever possible. They take all of the guesswork out of the equation.
