From what I've found, most of the family tree software packages use a proprietary data system.
For ease of explanation and visual, is you can basically call it a hierarchical system in reverse.
A hierarchical system basically means that at the "top", you have one singular person, you. You have two biological parents, which would be the next layer. They each have two parents, and so on. I say in reverse, because most hierarchical models show the base unit at the top and go down, while family trees show the base unit at the bottom and go up.
It's not an exact relationship, as if you have 4 children, each of them become their own "base" for the tree, etc. However, for a visual representation it should be a good starting point, and at least gets the idea across.
For the rest of it, it becomes a relational model, which is harder to explain. A relational database is more like a really big dresser. The database is the dresser, each drawer in the dresser is it's own table, and then each table can have different fields of information describing it.
Such as a database (dresser) called clothes. This database has a table (drawer) called Socks. Each sock has a description (fields) such as size, color, type, etc.
Now to relate them all together, each time you make a new entry in a table, that table automatically assigns it a unique identifier. That unique identifier can be assigned in various ways to your unique identifier, so that you can say something like "Go to the dresser, and get all of the socks that belong to person # 100". This would get socks numbered 1, 2, 5, 10, etc.
That's pretty simple when you have one person that might own a pair of the socks, it starts getting complicated when you have multiple people that might own the same pair socks. This is where things like pivot tables and other data mechanisms start coming into play. But, the pyramid hierarchical and the dresser of clothes should be enough to start on for now.