Versions Compared

Version Old Version 116 New Version Current
Changes made by

Fiona Sargeant (Unlicensed)

Zoe Baldwin

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
This page is for application designers. It explains the concepts of ERDs (entity-relationship diagrams) and how they define your system's data structure.

todo - example 

Insert excerpt
_Banners
_Banners
nameERD
nopaneltrue

Overview

PhixFlow ERDs define the logical structure of the data in your application.

ERDs are simplified Entity-Relationship Diagrams. "Entities" are things in the world that you want to represent as data tables.

 

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

tables show the relationships between them.

Panel
borderColor#00374F
titleColorwhite
titleBGColor#00374F
borderStylesolid
titleSections on this page

Table of Contents
maxLevel4
indent12px
stylenone

Image Removed


Image Added

The following illustration shows how an ERD represents a table.

Image Added



The table has a list of attributes, which represent the different pieces of data you want to record

. For example, the Student table in the ERD above has the attributes: UID, Address, IntakeYear and Name

.

Attributes are configured with

a data type and associated properties, for example the Name and Address attributes are labelled as "String". To make it easy to create an attribute, PhixFlow sets the type to String by default. To

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

it's properties, where you can set the type. For example, IntakeYear is set to Date. It is

and edit its properties.

It is important to set the correct data

type and

type and properties before loading records into a table, as you cannot change the data type once the

data type once the

table contains records.

Tip If

If you do have data

outside of PhixFlow, we recommend you use a PhixFlow analysis model to connect to your data source(s) and use them to create your table structure; see Load Data. This means PhixFlow can create tables and can determine the data type for the attributes. 

Identifying an Attribute

This help page refers to an attribute using the form table.attribute, for example: Teacher.Name, Student.Name or SchoolDept.Name. 

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

it's primary key. The primary key contains a unique value for every

a primary key, which uniquely identifies each record. For example,

several teachers

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

automatically

adds an attribute called UID (short for Unique IDentifier) and configures it as follows:

  • as the table's Image Modified 
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
  • .
  • as an integer
; see the SchoolDept primary key properties on the right
  • .
  • 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
_uid
_uid
nopaneltrue

Display Name 
Anchor
display-name
display-name

Where your table's

Typically a primary key is

a UID, you usually

not user-friendly and you do not want to

show it to the user on a screen. For example the SchoolDept.UID will be a number, for example 1490 or 1550. Application users want to see the department name, such as Arts or Science

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

the 

its Display Name property

, as shown for the SchoolDept.Name attribute on the right. Attribute properties for

. 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 

Primary Key                       

   Name 

Display Name 

 Image Modified        Image Modified

Relationships and Foreign

Keys

Keys 
Anchor
relationships
relationships

Tables in PhixFlow are relational

. This means

, 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

ways without: having

tables without needing to duplicate

datareorganizing the database tables themselves

it.

A foreign key is an attribute in one table, that refers to the primary key in another table.

In

the

an ERD you can connect tables by drawing a line, called a relationship

. This tells PhixFlow that the two tables are related. For

between them. For example,

both

the Teacher

and ClassRoom tables need

table needs to have the name of a department. The ERD

represents these relationships

below shows this relationship using a line that joins

the SchoolDept table to the ClassRoom table and to the Teacher table ( as shown in screenshot below).

SchoolDept.DeptID to Teacher.Department.

Image Added

When you create screens that show data, PhixFlow uses the relationships

from

Image Removed

defined in the ERD to provide options for displaying data from related attributes in the same grid, form, card, graph or chart; see 

Compiling Views.

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 Image Modifiedforeign key.

 

Foreign keys

can have different names to the primary key, but they

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

values

data type as SchoolDept.

UID; as shown in the attribute properties on the right. However, in the Teacher table there may be more than one instance of a value

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

.Although the relationship is between the primary key and a foreign key, when the foreign key is included in a screen, PhixFlow shows the attribute that has Display Name selected, which is the Name attribute by default

.

This gives the user a the meaningful string, rather than the primary key's identifier. For example, a table showing Teacher.Department will have data such as Arts or Science, rather than an ID like1490.

Attribute properties for:

   ClassRoom
   Department

Image Removed

One-to-many and Many-to-one

PhixFlow

always

draws a relationship line between a primary key and a foreign key. This represents a

1:many relationship. The "many" end of the line has several lines.

one-to-many relationship. For example, one teacher runs many courses. 

A many:1 Many-to-

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.

todo - 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.

Image RemovedDefining Data Structures using ERDs Insert excerpt_

Notice that CourseAttendee does not need a unique identifier.

Image Added

  • A course is attended by many students
  • A student takes many courses.

Do a second load of the data with slightly different names to look at how the attributes listed in a grid vary, 

todo - 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.

When you are creating views to display data in your application, you may want to combine attributes from different tables into one view.  For example, the following grid view has the attributes:

  • Department
  • Course Name
  • Classroom
  • Teacher

Image Removed

Most of these attributes come from the Course stream, so the grid view uses this as it's base stream.

Image Removed

The left of the Attribute Selector / View Editor window lists related tables.  By selecting the Teacher table, I can add the Department attribute to the grid view.

Image Removed

For details of creating views and using the attribute selector see Compiling Views and Showing Data on a Screen.

Creating PhixFlow Tables From Existing Data

You can create tables in an ERD, but this is time consuming. If you already have data, PhixFlow can create tables from it.

Starting PointEasiest MethodSeeI have no dataDefine the tables, attributes and their relationships in the ERD.
You will need to add records to the tables.

Defining Data Structures using ERDs

I have data but it's not in PhixFlowFirst use an analysis model to connect to your data. PhixFlow can read the data structures to create tables. When you run analysis on the model, PhixFlow loads the data records.Load DataI have data in PhixFlow alreadyIn the ERD toolbar, click Insert excerpt_table_list_table_listnopaneltrue to display a list of all the tables. Drag tables into the ERD and then add the relationships.

Viewing ERD Data 
Anchor
view
view

Insert excerpt
_view_records
_view_records
nopaneltrue

HTML Comment
hiddentrue
For Creating PhixFlow Tables from Existing Data

Table line...

  • I have data in Excel files
  • Drag the Excel files directly into an ERD. PhixFlow loads the data and adds the table to the ERD.
  • In the ERD, you then add the relationships between tables.
    • Link to doc on XD flow 4.10

     See Creating Dashboards and Reports.

    Using ERDs in Views

    PhixFlow displays data to application users via views most commonly a grid view, which displays data in rows and columns. 

    More Information