What exactly do database relationships do?

The answer, I fear, is too much to fit in a forum reply.

I found the following book very helpful and well written.
Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design (Paperback)

~ Michael J. Hernandez
Steve

I assume you already checked the following articles in the manual:

http://xlinesoft.com/phprunner/docs/master-detail_relationship.htm

http://xlinesoft.com/phprunner/docs/master-detailes.htm
and 'How to setup master-details relationships' video at http://xlinesoft.com/phprunner/php-database.htm
Do not confuse Master-Details relationships with JOIN SQL queries. Join queries pull data from several tables at once. Master-details are designed to simplify navigation through entities related as one-to-many.
Classic example with Customers, Orders and Order details. Setup Customers as Master, Orders as Details. Add another relation choosing Orders as Master, Order details as Details. Now you can drill-down from customer to her orders and from order to order details. In PHPRunner 5.2 you can even do all this on the same screen.
Hope this makes sense.

Totally agree, studying the concepts of relational database is the place to start.
Here is a basic example of a trivial database: The purchase order.
The purchase order consists of two parts. First, the header which says who the order is for, address, the date, status, etc. The second part is the list of items being ordered, where each "row" in the list has an item description, id number/code, quantity, unit cost, etc.
In a relational database, the data for the header and the data for the items are kept in two separate tables, the jargon is that the header is a master record and list items are details. Master and detail tables/records are linked, via a common "key" or unique identifier. This example is what's known as a 1 to 1:N relationship. It doesn't make sense for there to be a header record without at least one item record. What's an order without something being ordered? So for integrity, there needs to be at least one item record for each order, but there could be dozens of items.
For this example I'll ignore other possible tables in the database such as inventory (the master list of stock items) and customers (the master list of previous customers).
The way this is setup, when a new order is created a unique order number is assigned and stored in the header record master table (along with the other order header information). Then as you start entering the items, records in the items table are created, which include the very same order number in addition to a field which identifies the item (either the item number or a row number). The item records (details) has effectively a two part (field) key (order number + item number) which together makes it unique in the table, and allows you or the engine to find all the items associated with a particular order. Note: There are other ways to structure this, but the effect is the same.
You can tell some database engines that there is a linkage between these two tables, and if you do this then the engine will assist in managing the relational rules you impose. However you don't need to do this in PHPR. In the Tables tab, you connect the tables together by identifying the shared key field, in our case the order number, say which table is the master, and how you want to display the details.
The purpose of reading the book will be to help understand the different types of relationships (how you might use them) and identify the potential issues in operating a relational database, and the implications when rules are not enforced. For instance, what happens to the integrity of your data when the master record is deleted but not the details, or what happens when the order number linking key value is changed in one table but not the other, etc.

The big difference between relational databases and other types of filing systems, is that the relationships and linkages between objects are explicit in the data itself and are dynamic. There is no hidden layer in the metadata that creates structural or fixed relationships, such as tree structures which need to be pre-defined when the database is created. There are no hidden linkage fields in the database.
In a relational database, new tables and relationships can be added at any time. The only practical requirements to link tables together is that the link field(s) be indexed fields, and that both fields be of similar type. In our example the order number is a key/index field in both tables. It is also advisable that the item number field is indexed as well, these things are requirements to achieve reasonable performance.
The downside of relational databases is that usually most intrigity "rules" must be enforced by the designer. If a relationship rule is 1 to 0:N, 1 to 1:N, 1 to 1, 1 to 0,1 etc., how this is handled is often up to the application designer. Some development frameworks provide support for rule definition and support by introducing a layer of data abstraction, but basic PHP/SQL does not.
So the OP is largely correct in failing to observe any real magic in the relational database engine itself. It merely provides tables with indexing, and a simple query language. The only underlying magic is how they take a compound query and process it efficiently, or in the case of INNODB how it journals changes and recovers from minor failures.
Citing our example above again, lets say the designer allows the user to delete items from the purchase order. What happens when the last item is deleted? Now we have a 1 to 0 when the rule calls for 1 to 1:N. The application designer must decide how they wish to handle this situation. They would probably generate a popup window which warns the user and asks the user if they wish to delete the header (master) or add another item (detail), the only two options if integrity is maintained. If they choose to leave an orphan master record, then there will be downstream consequences. Another decision by the designer is how to handle if and when a master record can be deleted, and what happens to the associated detail records.
In summary, of the 4 basic operations on a database - create, read, update, and delete, only read requires no custom coding in PHPR when complex relationships exist. The read (list, view, search) functions provided are truely awesome. And although basic add, edit, delete functions are provided, PHPR provides event traps to allow the addition of custom PHP/SQL code to handle all the exceptions and special integrity rules associated with changing the data.

Thank you,
I appreciate the answers that I have received. It speaks well of this product and support group. I've been looking at an opposition product, but came here, because it became clear that their support was lacking. I'm glad I made the switch.
<img src='https://asprunner.com/forums/file.php?topicimage=1&fieldname=reply&id=48220&image=1&table=forumreplies' class='bbc_emoticon' alt=':)' />