Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Has Google (or DuckDuckGo) been any help yet? ;)

Here's one example of an explanation of table relationships in relational databases. There are, of course, loads of online tutorials about this.

Also, do check out Chapter 3 of the LIbO Base Handbook which covers this info; that should help with Base itself.

Has Google (or DuckDuckGo) been any help yet? ;)

Here's one example of an explanation of table relationships in relational databases. And Microsoft provides some help related to Access which transfers to Base. There are, of course, loads of online tutorials about this.

Also, do check out Chapter 3 of the LIbO Base Handbook which covers this info; that should help with Base itself.

Has Google (or DuckDuckGo) been any help yet? ;)

Here's one example of an explanation of table relationships in relational databases. And Microsoft provides some help related to Access which transfers to Base. There are, of course, loads of online tutorials about this.

Also, do check out Chapter 3 of the LIbO Base Handbook which covers this info; that should help with Base itself.

@mrmister - in your answer you write:

... the aim of relationships is to combine databases to obtain certain results from queries and report, right?

No, not quite.

The aim of relationships is to ensure the integrity of the data stored in related tables of a single database.

It's important to keep the terminology straight. Think of it this way (the analogy is limited, and will only help so far, though!). Your database is like a bookcase, your tables are like the shelves, and the fields in the tables like the books, magazines (different types) on the shelves.

  • One bookcase has some/many shelves, each shelf has numbers of books (which contain your information).
  • One database has some/many tables, each table has numbers of fields (which contain your information).

Back to relations, then. In a relational database, the "1:many", "1:1", etc., relations connect fields in different tables.

An example. Let's stick with the library analogy. Say we have a database for our library collection. Two of our tables would be "Authors" and "Books":

  • Table:Authors / Fields: AuthorID, Author_LastName, Author_FirstName, Author_DoB
  • Table:Books / Fields: BookID, Title, PubDate, Publisher, Location

(We could have another for publishers. After reading this example, you could work out how a "Publishers" table would be "related" to "Authors", "Books".) How to connect the data between these tables in our "Library" database?

One way would be to add an "AuthorID" field to the "Books" table. (In databases, one rule you try to work with: never enter the same data more than once!) (We'll let the database worry about how the numbers of these ID fields work: it's designed to do that.)

So, one author could write many books, but any title will only have a single author (for the sake of this example). Or, in abstract:

Authors.AuthorID : 1 ... ∞ : Books.AuthorID

That is, any one instance of an AuthorID field from the "Authors" table, could have many (∞) corresponding entries in the AuthorID field of the "Books" table. The one-to-many relationship defnition ensures this connection between tables in your database links the information correctly (e.g., Charles Dickens connects to Great Expectations, and Bleak House, and Oliver Twist, but the Oliver Twist entry, ONLY connects to one "Charles Dickens".

Here's another database tutorial site with some practical explanations and examples.

Hope that helps.

Has Google (or DuckDuckGo) been any help yet? ;)

Here's one example of an explanation of table relationships in relational databases. And Microsoft provides some help related to Access which transfers to Base. There are, of course, loads of online tutorials about this.

Also, do check out Chapter 3 of the LIbO Base Handbook which covers this info; that should help with Base itself.

@mrmister - in your answer you write:

... the aim of relationships is to combine databases to obtain certain results from queries and report, right?

No, not quite.

The aim of relationships is to ensure the integrity of the data stored in related tables of a single database.

It's important to keep the terminology straight. Think of it this way (the analogy is limited, and will only help so far, though!). Your database is like a bookcase, your tables are like the shelves, and the fields in the tables like the books, magazines (different types) on the shelves.

  • One bookcase has some/many shelves, each shelf has numbers of books (which contain your information).
  • One database has some/many tables, each table has numbers of fields (which contain your information).

Back to relations, then. In a relational database, the "1:many", "1:1", etc., relations connect fields in different tables.

An example. Let's stick with the library analogy. Say we have a database for our library collection. Two of our tables would be "Authors" and "Books":

  • Table:Authors / Fields: AuthorID, Author_LastName, Author_FirstName, Author_DoB
  • Table:Books / Fields: BookID, Title, PubDate, Publisher, Location

(We could have another for publishers. After reading this example, you could work out how a "Publishers" table would be "related" to "Authors", "Books".) How to connect the data between these tables in our "Library" database?

One way would be to add an "AuthorID" field to the "Books" table. (In databases, one rule you try to work with: never enter the same data more than once!) (We'll let the database worry about how the numbers of these ID fields work: it's designed to do that.)

So, one author could write many books, but any title will only have a single author (for the sake of this example). Or, in abstract:

Authors.AuthorID : 1 ... ∞ : Books.AuthorID

That is, any one instance of an AuthorID field from the "Authors" table, could have many (∞) corresponding entries in the AuthorID field of the "Books" table. The one-to-many relationship defnition ensures this connection between tables in your database links the information correctly (e.g., Charles Dickens connects to Great Expectations, and Bleak House, and Oliver Twist, but the Oliver Twist entry, ONLY connects to one "Charles Dickens".

Here's another database tutorial site with some practical explanations and examples.

Hope that helps.

Has Google (or DuckDuckGo) been any help yet? ;)

Here's one example of an explanation of table relationships in relational databases. And Microsoft provides some help related to Access which transfers to Base. There are, of course, loads of online tutorials about this.

Also, do check out Chapter 3 of the LIbO Base Handbook which covers this info; that should help with Base itself.

@mrmister - in your answer you write:

... the aim of relationships is to combine databases to obtain certain results from queries and report, right?

No, not quite.

The aim of relationships is to ensure the integrity of the data stored in related tables of a single database.

It's important to keep the terminology straight. Think of it this way (the analogy is limited, and will only help so far, though!). Your database is like a bookcase, your tables are like the shelves, and the fields in the tables like the books, magazines (different types) on the shelves.

  • One bookcase has some/many shelves, each shelf has numbers of books (which contain your information).
  • One database has some/many tables, each table has numbers of fields (which contain your information).

Back to relations, then. In a relational database, the "1:many", "1:1", etc., relations connect fields in different tables.

An example. Let's stick with the library analogy. Say we have a database for our library collection. Two of our tables would be "Authors" and "Books":

  • Table:Authors / Fields: AuthorID, Author_LastName, Author_FirstName, Author_DoB
  • Table:Books / Fields: BookID, Title, PubDate, Publisher, Location

(We could have another for publishers. After reading this example, you could work out how a "Publishers" table would be "related" to "Authors", "Books".) How to connect the data between these tables in our "Library" database?

One way would be to add an "AuthorID" field to the "Books" table. (In databases, one rule you try to work with: never enter the same data more than once!) (We'll let the database worry about how the numbers of these ID fields work: it's designed to do that.)

So, one author could write many books, but any title will only have a single author (for the sake of this example). Or, in abstract:

Authors.AuthorID : 1 ... ∞ : Books.AuthorID

That is, any one instance of an AuthorID field from the "Authors" table, could have many many (∞) corresponding entries in the AuthorID field of the "Books" table. The one-to-many relationship defnition ensures this connection between tables in your database links the information correctly (e.g., Charles Dickens connects to Great Expectations, and Bleak House, and Oliver Twist, but the Oliver Twist entry, ONLY connects to one "Charles Dickens".

Here's another database tutorial site with some practical explanations and examples.

Hope that helps.

Has Google (or DuckDuckGo) been any help yet? ;)

Here's one example of an explanation of table relationships in relational databases. And Microsoft provides some help related to Access which transfers to Base. There are, of course, loads of online tutorials about this.

Also, do check out Chapter 3 of the LIbO Base Handbook which covers this info; that should help with Base itself.

@mrmister - in your answer you write:

... the aim of relationships is to combine databases to obtain certain results from queries and report, right?

No, not quite.

The aim of relationships is to ensure the integrity of the data stored in related tables of a single database.

It's important to keep the terminology straight. Think of it this way (the analogy is limited, and will only help so far, though!). Your database is like a bookcase, your tables are like the shelves, and the fields in the tables like the books, magazines (different types) on the shelves.

  • One bookcase has some/many shelves, each shelf has numbers of books (which contain your information).
  • One database has some/many tables, each table has numbers of fields (which contain your information).

Back to relations, then. In a relational database, the "1:many", "1:1", etc., relations connect fields in different tables.

An example. Let's stick with the library analogy. Say we have a database for our library collection. Two of our tables would be "Authors" and "Books":

  • Table:Authors / Fields: AuthorID, Author_LastName, Author_FirstName, Author_DoB
  • Table:Books / Fields: BookID, Title, PubDate, Publisher, Location

(We could have another for publishers. After reading this example, you could work out how a "Publishers" table would be "related" to "Authors", "Books".) How to connect the data between these tables in our "Library" database?

One way would be to add an "AuthorID" field to the "Books" table. (In databases, one rule you try to work with: never enter the same data more than once!) (We'll let the database worry about how the numbers of these ID fields work: it's designed to do that.)

So, one author could write many books, but any title will only have a single author (for the sake of this example). Or, in abstract:

Authors.AuthorID : 1 ... ∞ : Books.AuthorID

That is, any one instance of an AuthorID field from the "Authors" table, could have many (∞) corresponding entries in the AuthorID field of the "Books" table. The one-to-many This one-to-many relationship defnition definition ensures this connection between tables in your database links the information correctly (e.g., Charles Dickens correctly. For example, one author, "Charles Dickens", connects to many books: Great Expectations, and Bleak House, and Oliver Twist, ; but the book entry Oliver Twist entry, ONLY connects to one author, "Charles Dickens".

Here's another database tutorial site with some practical explanations and examples.

Hope that helps.