This page is for data modellers or application designers. It explains how to use an ERD to define your system's data and its relationships.
Overview
PhixFlow ERDs are simplified Entity-Relationship Diagrams. "Entities" are things in the world that you want to represent as data tables in your application.| 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.
| Panel | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
| Panel | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
Tables and Attributes
The table name is displayed in the header.
The lines connecting the tables show the relationships between them.
The following illustration shows how an ERD represents a table.
The table has a list of attributes
Student table has attributes:
- StudentID
- Student Name
- Student Address
- Intake Year
Because the ERD defines the data, each attribute has a type for the data, such as string or integer.
To see the context menu for a table:
in the table header, clickSpecial Attribute: Primary Key
Each table must also have a special attribute called its primary key. PhixFlow automatically adds a primary key when you create a table. The primary key is called UID, which is short for Unique IDentifier because every data record will always have a unique value for this attribute. For example, several customers, 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
If an entity has something unique for each instance of it, you can use that as the UID. For example, in the UK a person has a unique National Insurance number. However, if you use something like this, PhixFlow cannot make sure all UIDs are unique.
PhixFlow automatically generates an attribute that is the unique identifier, UID. This is the table's primary key that is used to uniquely identify each record in the table.
Primary keys are indicated by a green key icon.
| Note |
|---|
The UID created by PhixFlow has a data type of integer, because PhixFlow can automatically generate a unique integer value for each new data record. If you want to use a different type of value, for example alpha-numeric, PhixFlow cannot create unique values for each record. You must ensure all records have unique values. |
Primary keys in different tables:
- DepartmentID
- ClassRoomID
- TeacherID
Relationships and Foreign Keys
Using Data Without Duplication
Sometimes we want to have the same data in different tables. For example, the Order table may need to include the customer name and address. It's important not to duplicate data in PhixFlow, so instead you create a relationship between the Customer and Order tables. The order table can "get" the data it needs from the customer table. To make sure it is getting the correct data record, the relationship must be between one table's primary key/UID and an attribute in another table. PhixFlow automatically sets this as the foreign key.
Relationships show that the data in a primary key in one table also appears in an attribute in another table. The attribute may have a different name, but it must represent the same data. This attribute is a foreign key. Do we need to say it needs to represent the same data type and parameter e.g. Integer, precision 10?
Foreign keys are indicated using a grid icon.
When you create a relationship in an ERD, PhixFlow automatically sets the foreign key status for the attribute.
Employee attributes:
- EmployeeID (primary key)
- Name
- Address
- Phone
- Department = foreign key for DepartmentID
Department attributes
- DepartmentID - primary key
- Department Name
- Purpose
- Department Manager = foreign key for EmployeeID
The ERD's entities, attributes and relationships define the logical structure of the data that your application uses.
You can create a relationship between the primary key in one table, to an attribute in another table. On the diagram the relationship is shown as an arrow from a primary key to an attribute in another table. Relationships always point from a primary key to a non-primary attribute.
When you are designing screens, you can create views to display attributes from a table AND from other, related tables.
By convention, set the name of a relationship an action (verb) that follows the left-right flow of the diagram.
- a department→ has→ many teachers
- a teacher has one department
- a teacher → runs→ several courses
- classroom → is used by→ many courses
Relationships between tables have a direction that depends on the table on which you are focused. For example, looking at the Teacher table, shown below, you can see 2 relationships.
- The school DepartmentID primary key has a relationship to the Teacher table. This relationship is highlighted in blue.
- The Teacher table has a relationship from its TeacherID primary key to an attribute in the Course table. This relationship is highlighted in green.
By convention, set the name of a relationship an action (verb) that follows the left-right flow of the diagram.
- a department→ has→ many teachers
- a teacher has one department
- a teacher → runs→ several courses
- classroom → is used by→ many courses
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 | ||||||
|---|---|---|---|---|---|---|
|
Display 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 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 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.
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
Data Structure and Views
PhixFlow uses the relationships between tables when you come to make views of data. You can create views that include include attributes from different tables, provided there is a relationship. When you add an attribute to a view, PhixFlow can provide a list of all the other attributes that you can use in the view.
Data: Tables, Attributes and Records
The ERD does not include the data records. If you think of an Excel spreadsheet, a table in an ERD includes the name of the worksheet and the titles of the columns. It does not show the data records from the rows.
You can add data records to your table: link??
For tables that have data records, you can see the records.
- student takes many courses.
Viewing ERD Data
| Anchor | ||||
|---|---|---|---|---|
|
| Insert excerpt | ||
|---|---|---|
|
|
|
|
Context menu
Jiras
?? Initial Cap only
Configure → Table properties
Hide Attributes - Hide attributes
Remove this item from the Diagram → Remove from ERD... model, screen, workflow, actionflow...
Permanently Delete → Delete everywhere
Inital cap only
ConUsing ERDs in Views
PhixFlow displays data to application users via views most commonly a grid view, which displays data in rows and columns.