# Understanding relations

Since english is not my first language i find hard to understand this paragraph that i'm reading from "Database Fundamentals" book.

I'm trying to figure out, in practice, real world, what this really means.

• Relation -> Table; Heading -> Columns definitions (table structure); Domain- > Column type; Attribute -> Column; Body -> Data(Rows); Tuple -> Row; Value -> specific column of a given row - simplified translation from the "math language" of relational algebra to what you might know from real-world databases. Commented Nov 13, 2015 at 11:09
• I hope this isn't rude, but you can help us by telling us what your first language is. It could be Japanese, or Greek, or Spanish, or something else. The way we phrase our answer might or might not help you understand, depending on where your strength lies. Commented Nov 13, 2015 at 13:32
• My first language is Portuguese (pt-pt) not (pt-br). Commented Nov 16, 2015 at 9:45

English is not the easiest language in the world to describe mathematical concepts and their relationship to the real world. For a few years, I taught short courses in database design and programming in Spanish, even though Spanish is not my first language. But there were a few concepts that came across more clearly in Spanish than they did in English.

The first thing you need to understand is that the relational data model was pretty much invented by one person, Ed Codd in 1970, and he based the data model on the mathematics of relations. A great deal of the terminology is derived from terminology of mathematical relations, although there are subtle differences between mathematical relations and relations in the relational data model.

The second thing you need to understand is that "relation" and "relationship" are two different words with two different underlying concepts, even though there is a huge overlap between the two. The word "relationship" tends to be used in ER modeling, and refers to an association between two or more entities in the real world. These entities may be of different types or of the same type.

The third thing you need to understand is that you understand the subject matter through analysis but you come up with a relational model by design. The difference between analysing the data and designing the database is often not clear even for many English speakers.

When you convert an E-R model into a relational model, both the Entities and the Relationships get expressed as relations. so the difference between the Es and the Rs becomes almost moot as you make progress towards the eventual construction.

I apologize if this is too vague, but you'll have to clarify your question if you want more specific answers.

Some data elements are related with each other. We can make one big relation with all of the data in our business area - one row in the table for the one new fact (co-related data), which we want to store in our DB. But this big relation will have modification anomalies caused by redundancy. So we have to decompose this original big relation to a set of smaller relations in normal forms.

Some of these small relations are related with some others too.