| Insert excerpt | ||||||||
|---|---|---|---|---|---|---|---|---|
|
Overview
PhixFlow ERDs define the logical structure of the data in your application.
The following example shows an ERD for a school. A school has entities, for example: departments, teachers, students, classrooms and so on. All these entities are represented as tables. The lines connecting the
tables show the relationships between them.
| Panel | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
Diagram updates, Change IntakeYear to Date
The following illustration shows how an ERD represents a table.
The table has a list of attributes, which represent the different pieces of data you want to record.
Attributes are configured with
a data type and associated properties; see Understanding Data Types. For example the Address attribute is a String which has an associated length. To change the attribute to reflect the nature of your data, click on the attribute's name to open
and edit its properties.
It is important to set the correct data
type and properties before loading records into a table, as you cannot change the data type once the
table contains records.
If you do have data
and want to change the type you will need to add a new attribute or clear your data; see Clearing and Loading Data in an ERD.
You can create tables in an ERD manually, but if you already have data, PhixFlow can automatically create tables from it; see Adding Content to an ERD.
Primary Keys and UIDs
PhixFlow expects every table to have a special attribute
called
a primary key, which uniquely identifies each record. For example,
teachers have a UID as the primary key. This is because they can have the same first or family name, or even both, so these attributes cannot be a primary key. When you create a table, PhixFlow
adds an attribute called UID (short for Unique IDentifier) and configures it as follows:
- as the table's
primary key.
- as an integer
- .
- to automatically create a unique number for every record in a table.
This means PhixFlow can ensure all
the UIDs have unique values.
| Insert excerpt | ||||||
|---|---|---|---|---|---|---|
|
Relationships and Foreign Keys
Sometimes we want to have the same data in 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 needDisplay Name
| Anchor | ||||
|---|---|---|---|---|
|
Typically a primary key is not user-friendly and you do not want to display it. Instead, you want to display something that makes more sense to a person. For this reason, when you create a table, PhixFlow automatically adds an attribute called Name and ticks its Display Name property. The display name is shown in place of the primary key when displayed on a view or screen. Display names do not need to be unique and should be something user-friendly.
Let's look at the following example. For the SchoolDept table, PhixFlow has created:
- a UID, for example 1490.
- a Name, for example Mathematics.
When any view makes reference to the SchoolDept using it's primary key, PhixFlow displays the department name, not its number; see Using Relational Views. The configuration is shown below:
SchoolDept SchoolDept
Primary Key Display Name
Relationships and Foreign Keys
| Anchor | ||||
|---|---|---|---|---|
|
Tables in PhixFlow are relational, which means information in one table can be related to information in another table. The key benefit is you can access data in many different tables without needing to duplicate it.
A foreign key is an attribute in one table, that refers to the primary key in another table.
In an ERD you can connect tables by drawing a line, called a relationship between them. For example, the Teacher table needs to have the name of a department. The ERD
below shows this relationship using a line that joins
You are not just adding a line to a picture - you are creating a relationship that PhixFlow can use data from the other table...
SchoolDept.DeptID to Teacher.Department.
When you create screens that show data, PhixFlow uses the relationships defined in the ERD to provide options for displaying data from related attributes in the same grid, form, card, graph or chart; see Displaying Data (Views). This means you only need to store the School DeptID against a teacher to be able to access all of the SchoolDept details.
When you create a relationship from a primary key to an attribute, PhixFlow automatically sets the attribute to be a 
foreign key.
Foreign keys
must have the same data type and properties as the corresponding primary key. For example, in the illustration above, the Teacher.Department attribute
contains the same
data type as SchoolDept.DeptID; see Understanding Data Types.
The foreign key represents the many side and the primary key the one side. This means that SchoolDept.DeptID is unique, there is only one record containing this unique information. The Teacher.Department, can have one or more instances of a value of DeptID. For example, the Maths Department UID could occur 10 times, once for each of the
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.
10 maths teachers.
One-to-many and Many-to-one
PhixFlow
draws a relationship line
between a primary key
and a foreign key.
This represents a one-to-many
relationship. 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: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. Notice that CourseAttendee does not need a unique identifier.
- 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 Records
An ERD defines the table, attributes and relationships. You can:
- define an ERD before adding any records to PhixFlow. In this case you create the tables, attributes and relationships; see Defining Data Structures using ERDs
- load 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.
- drag an Excel file directly onto an ERD canvas see 4.10.
If you are working with tables that have records, to see the records:
Viewing ERD Data
| Anchor | ||||
|---|---|---|---|---|
|
| Insert excerpt | ||
|---|---|---|
|
|
|
|
Using ERDs in Views
PhixFlow displays
data to application users via views most commonly a grid view, which displays data in rows and columns.