The information here is mostly metaphorical examples of real life to help explain complex database concepts in regards to Fluxx data model to serve a more general audience.
Tables
Imagine the database being made out of different spreadsheets which we call Tables. Every row on that table is representing one record of a type represented by that table. For example, if we are adding a Jane Doe as a contact to our database, here is how it would look like:
Table would be People (Users). It would look like this:
| Person ID | Last Name | First Name | Prefix | Salutation | Suffix | User Title | Work Phone | Mobile Phone | Primary Organization | Primary Title | Personal Street Address | Personal Street Address2 | Personal City | State | Country | Postal Code | Date Created | Date Updated | Highest Degree Year | UW Department | Primary Affiliation | Highest Degree | Prefix Dynamic | Track | Co-Investigator / Collaborator / Academic Partner Affiliation | Department | Role Name | Citizenship Status | SMPH Division | Primary Affiliation Other | office_telephone | office_fax | office_extension | employee_id | department_division | degree | academic_partner_affiliation_other | Job Title | Individual Vendor Number | Middle Name | Bulk Update Test Field | Alias (or AKA) | Biographical Statement | |
| 3055 | User | Testing | exampleemail@wisc.edu | (608) 123-9874 | One Test Organization | Chief Executive Officer | 9/20/2021 | 2/11/2022 |
Person ID is a unique number that has no particular meaning other than uniquely identifying the record in that table/spreadsheet in our database.
In the Fluxx database, the column names are not the same as the labels we see in our views; column names are technically the "back-end names" of these fields (e.g. office_telephone and not "Office Telephone Number"). Everywhere else, we will see the human readable labels.
Links
Let's start this section with a story:
When we invite a guest to our house, we prepare for them. We make sure that we make space for them to come and we expect them to come. The other way around is not the case; they do not expect us to go to their house. When they show up to our house, we know what their name is and other information related to them. So, if anyone asks us who is your guest, we are able to tell them the name of our guest and their relationship to us and also their food allergies, because we were expecting them and we were cooking for them.
Imagine at the same time some birds flying and sitting on our roof. We don't expect them and we don't even know they exist. So, if anyone asks us about those birds, we would probably say "what birds?!". The birds however, know about our house. They were expecting to sit on a roof and that's what they did. There is only one way relationship between our house and the birds. Our house is going to be our house with or without the birds. But the birds need a roof to sit on.
The same idea is happening in our database. As we mentioned in Tables section, we can imagine tables as spreadsheets. So, like spreadsheets, a Request spreadsheet would not know anything about Organization spreadsheets unless we connect them together somehow. In databases, we can Link the spreadsheets that have relationship together. For example, a Request would like to know which Organization it belongs to. So, there is an empty seat in Requests spreadsheets that refers to the related Organization:
Organizations spreadsheet:
| ID | Name | Tax_ID | EMail_Address | Primary_Contact_ID |
| 11 | Test Organization | 111111111 | test@org.com | 111 |
Requests spreadsheet:
| ID | First_Name | Middle_Name | Last_Name | Birth_Date | Organization_ID |
| 1111 | Jane | Melanie | Doe | 19690401000000 | 11 |
In other words, there is one empty space for an organization in a certain request. That is why we can only have one organization for a request.
Organization however, is independent from the request. Requests are like birds on its roof. It doesn't even know that they are there (we can retrieve the information when we do a query).
The following chart is showing the main linking that is in place in Blackbaud Grantmaking Database: