Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 86 Next »

This page is for data modellers or application designers. It explains how to use an ERD to define your system's data structure.

Other pages in this topic

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.

The following example shows an ERD for a school. A school has the entities: departments, teachers, students, classrooms and courses. All these entities are represented as tables.

Sections on this page


Tables and Attributes

The table name is displayed in the header.

When you are creating tables, choose a name that reflects the thing your table represents.

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.

You can see that the Address and Name attributes have the word "String" next to them. PhixFlow needs to know what type of data the attribute contains. 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 the data. For example, an attribute of Telephone Number would be integer.

Primary Key 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 UID. PhixFlow automatically adds an attribute called UID, which is short for Unique IDentifier when you create a table. The UID is the table's  primary key. The UID has a data type of integer with a precision of 10. PhixFlow automatically generates a unique number for every record in the table. 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.

If your data already has a unique attribute you can use that as the UID. For example, our Teacher table could have a National Insurance attribute. 

If you:

  • either use existing data as the UID for a table
  • or set the UID to a type other than integer

PhixFlow cannot make sure all UIDs are unique. In these cases, you must set up your own processes to make sure no duplicate values are present in custome UID attributes.

Relationships and Foreign Keys

Sometimes we want to have the same data in different tables. 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). 

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 UID, but they must have the same data type, for example integer with a precision of 10. For example, the Department attribute has the same values as the UID values for the school department. However, in the ClassRoom or Teacher table there may be more than one instance of a value. For example, there may be 10 teachers who belong to the Maths Department.

The ERD's entities, attributes and relationships define the logical structure of the data that your application uses.

If you want to highlight the relationships that affect a table, click the table to select it. The following screenshot shows the Teacher table is selected.

  • Blue lines indicate relationships to a foreign key in the selected table
  • Green lines indicate relationships from the primary key in the selected table.

Why Relationships are Important

It's important not to duplicate data. 

In an application screen, you can add grids showing data from tables. However, there are attributes from a table that you do not want to include in a view, such as the UIDs, and there may be attributes in other tables that you do want to include in a view. For example, your application might want to show:

  • Course Name
  • Department Name
  • Teacher Name
  • Number of Students

PhixFlow can add names from different tables into the same view using the relationships. For example:

Course Table - 1 step to Teacher Table
  1. Course via Teacher foreign key to Teacher Name
Course Table - 2 steps to Department Table
  1. Course via Teacher foreign key to Teacher Table
  2. Teacher Table via Department Foreign key to SchoolDept Table (and therefore department names).



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

One-to-many and Many-to-one

PhixFlow always draws a relationship arrow from a primary key to another, non-primary, attribute foreign key. This represents a one-to-many relationship, for example, one teacher→ runs→ many courses. 

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-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 multiple courses. This relationship is shown using the intermediate table called CourseAttendee.

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

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. 


If you display the table data in a grid, the attributes are the column headers.

Data: Tables, Attributes and Records

This page does not mention data records. The ERD defines the table, attribute and relationships. It does now show any 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 draw an ERD before adding any data to PhixFlow, or you can load data from external sources and then drag tables into and ERD to define the relationships between tables.

How to load data or add it to empty tables: link??

If your tables have records, to see them:

  1. Click on a table in the ERD to open its properties.
  2. In the properties toolbar, click  More Options.
  3. Select tbc


Context menu

To see the context menu for a table:

  • in the table header, click  More Options 
  • right-click anywhere in the table.

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

Con



  • No labels