Tables and Attributes
The table name is displayed in the header.
Show this as labels on the diagram.
| Tip |
|---|
When you are creating tables, choose a name that reflects the entity your table represents. Move to creationShould this be on the defining data structures page as we do not cover creation here? |
The table has a list of attributes, which represent the different data you want to record. For example, the Teacher table records the Department, Address and Name of teachers.
It might be better to start here with an example that didn’t include a reference to another table, then introduce an example with a foreign key reference when you get to explaining how they work. e.g. student or this section goes away because its all on the labelled diagram
You can see that the Address and Name attributes have the word "String" next to them to indicate the type of data they represent. PhixFlow needs to know what type of data the attribute contains. remove this next sentence? To make it easy to create an attribute, PhixFlow sets the type to string by default. It is important that you change the attribute to reflect the nature of your data. For example, an attribute of Telephone Number birthday should be integer. Telephone is not a great example as we often see +44 or (020) or spaces in the number, maybe use a account balance or date?a Date.
To see or change the data type for an attribute, click on it's name in the table to open it's properties panel on the right. Can we not make this section more concise by saying something like "PhixFlow sets the data type to string by default, to change this simply click on it's name in the table to open it's properties panel on the right..."
| Tip |
|---|
To refer to an attribute, it's a good idea include the table name. For example, the attribute Name occurs in several tables, so you can specify: Teacher.Name, Student.Name or SchoolDept.Name. Ask if this notation or other notation is being used in the product - order or how would you do it in an expression... |
This tip feels out of context, were do we use this annotation to refer to an attribute?
Primary
Key UID The primary key doesn't have to be called UIDKeys and UIDs
Be careful about whether or not it is a UID
Each table must have a special attribute that contains a unique value for every record. For example, several teachers can have the same first or family name, or even both, so these attributes cannot be a Unique IDentifier or UID. PhixFlow automatically adds an attribute called UID when you create a table.
The UID:
- is the table's
primary key.
If you look at the School ERD example above, you can see that every table has an attribute called UID, and that it has the primary key icon next to it. - is an integer; see the UID properties on the right.
- by default is automatically generated by PhixFlow so that there a unique number for every record in the table.
| Note |
|---|
If your data already has a unique attribute, you can use that as the
PhixFlow cannot make sure all Not sure how specific to be here about creation and setting, as we cover creation in In Defining Data Structures, have the same text available as a NOTE, here just a simple version as text... |
Relationships and Foreign Keys
Sometimes we want to have the same data in different tablesin multiple places, but only update it in one location.... (to show the value). feels a little vague and doesn't do justice to the value of the relationships For example, both the Teacher and ClassRoom tables need to have the name of a department. The ERD represents these relationships using a line that joins the SchoolDept table to the ClassRoom table and to the Teacher table (screenshot below). Why is that important?
You are not just adding a line to a picture - you are creating a relationship that PhixFlow can use data from the other table...
When you create a relationship from a primary key to an attribute, PhixFlow automatically sets the attribute to be a 
foreign key. Foreign keys can have different names to the UIDprimary key, not sure that needs to be said? but they must have the same data type as they contain the same form of dataand properties. For example, in the illustration above the Department attribute on the Teacher table has the same values as the contains UID values that correspond to UID values in the SchoolDept table. However, in the ClassRoom or Teacher table there may be more than one instance of a value. For example, the Maths Department UID could occur 10 times, once for each of the 10 maths teachers.
Usually, you want to use the foreign key attribute name, rather than UID, when the data is shown in a view. PhixFlow automatically ticks the Display Name property for a foreign key, as shown in the properties screenshot on the right.
Display name is used in a view....
I don't think the prev. para is correct - ticking the Display Name box on an attribute means that this attribute should be displayed in place of the foreign key attribute on a related table. In the example here you would set DisplayName=true for SchoolDept.name so that a view of Teacher joined to SchoolDept would show SchoolDept.name (a meaningful string) in place of Teacher.Department (a meaningless id). Note that this isn't implemented yet, so right now setting DisplayName does nothing.
Gary is correct Display Name takes the place of both a Primary Key or Foreign Key to display meaningful information.
One-to-many and Many-to-one
PhixFlow always draws a relationship line from a primary key to foreign key. This makes little sense unless the line has an obvious direction, and now that we're using the crow's foot notation there is no obvious direction. This represents a one-to-many relationship. The "many" end of the line has several lines. For example, one teacher runs many courses. A many-to-one relationship is implied when you read a relationship in the opposite direction. For example, a department has many teachers, and several teachers work for one department.
Come back and add something after doing relational views and aggregation: Gary says: This doesn't really explain why one-to-many / many-to-one are important. You might want to include worked examples showing the data you will get if you build a view starting with Teacher and a similar view starting with SchoolDept. You should also cover the importance of the 'Primary' table (the starting table in a joined view, in particular that you will only be able to edit fields that came from the Primary table, and only then if you haven't followed a one-to-many relationship.
Many-to-many
To create a many-to-many relationship, you need an intermediate table that has foreign key attributes from each of the tables you want to have a relationship. For example, many students take many courses. A many-to-many relationship is shown below, using the intermediate table called CourseAttendee.
- A course is attended by many students
- A student takes many courses.
Show in a relational view with worked examples in a table e.g using data in tables Sketch something up and use mockaroo and powerpoint for images: Again, I think this would benefit from a worked example showing that you get records with combinations of records from each table.
Why ERDs are Important
The ERD's tables, attributes and relationships define the logical structure of the data that your application uses.
Just that it relates to views and views talk about how you access them - keep this simple - show an example with real data....
However, a table has attributes that you may not want an application user to see, such as UIDs or audit data. How does this sentence relate to ERDs? When you are creating views to display data in your application, you may want to combine attributes from different table s into one view. For example, your application might want to show:
- Course Name
- Department Name
- Teacher Name
- Number of Students
Each of these attributes comes from a different table. The relationships that you create between tables in an ERD make it possible for PhixFlow to create views using attributes from different tables. For example:
Check annotation
This is done via a view picker.
Course Table - 1 relationship to Teacher Table
- Course.Teacher to Teacher.UID and display name Teacher.Name
Course Table - 2 relationships to Department Table (Tech check: this is true??)
- Course.Teacher to Teacher.UID
- Teacher.Department to SchoolDept.UID to SchoolDept.Name.
I feel this is too technical an example, where would a user see/ use this annotation? Should we show an example in an application or something more visual with the descriptions?
A Note About
DataRecords
An ERD defines the table, attribute attributes and relationships. It does not show any data records. We can view charts as explained below? If you think of an Excel spreadsheet, an ERD shows the name of the worksheet (table) and the titles of the columns (attributes) but not the rows of data. I feel this is more confusing, can we not just say it defines the structure where your data will be placed?
You can:
eitherYou can:
- define an ERD before adding any data records to PhixFlow. In this case you create the tables, attributes and relationships; see Defining Data Structures using ERDs
- or you can load data records from external sources first. You can then drag tables into the ERD and simply add the relationships; see Setting Up Data for an overview and links.We can also add excel files or at least will be able to
- drag an Excel file directly onto an ERD canvas see 4.10.
If you are working with tables that have records, to see themthe records:
- In the ERD, click on a table to open its properties.
- In the properties toolbar, click
.Insert excerpt _more_options _more_options nopanel true - Select View Chart.
- PhixFlow displays a the default grid view listing all the data records.