Skip to end of metadata
Go to start of metadata

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

Compare with Current View Version History

« Previous Version 61 Next »

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

Overview

An ERD is an entity relationship diagram. Use an ERD to represent the information that your application will use and how it is connected. PhixFlow uses the connections between data when you come to make views. When you select something to add to a view, PhixFlow can offer all the connected tables and attributes. This means you can easily create views that combine data from different tables.

PhixFlow's ERDs are simplified Entity-Relationship Diagrams. If you are unfamiliar with the general concepts of ERDs, they are explained in this article: ER Diagram Tutorial in DBMS.  

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. 

Sections on this page

Example ERD

The following example shows an ERD for a school. Each box represents a different table.

Key Concepts

TermMeansSchool Example

Table


A table represents a thing or entity. The table name is displayed in the blue area.

Choose a name that reflects the thing your table represents.

Tables:

  • School Department
  • Class Room
  • Teacher
  • Course
  • Student
Attributes

The table has a list of attributes. If you display the table data in a grid, the attributes are the column headers. They name what the data is, and sets the type (date, integer, string etc.) and any format details. 

Student table has attributes:

  • StudentID
  • Student Name
  • Student Address
  • Intake Year
Primary key

PhixFlow automatically generates an attribute that is the unique identifier, UID. This is the table's primary key. The records for this attribute will all have a unique value. You may want to rename UID to something more descriptive, although it's a good idea to include ID in the name.

Primary keys are indicated using a green key icon.

We recommend that a primary key attribute is an integer, because PhixFlow can automatically generate a unique integer value for each new data record.

Primary keys in different tables:

  • DepartmentID
  • ClassRoomID
  • TeacherID
Relationship

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.

Between two tables with multiple relationships, each connection must have a unique name.

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 → runs→ several courses
  • classroom → is ued by→ many courses
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. 

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

Understanding Relationships

Relationships From and To

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 connect into the Teacher table. This inbound relationship is highlighted in blue.
  • The Teach table connects from its TeacherID primary key to an attribute in the Course table. This outbound relationship is highlighted in green.

One-to-many and Many-to-One

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

For this type of relationship, PhixFlow automatically sets it to be aggregate. This means the relationship reports the total number. So a teacher runs 3 courses. In the ?? properties, you can clear the aggregate setting to report the full list of their courses.

A many-to-one relationship is implied when you read a relationship in the opposite direction. For example, a departhment has many teachers, and several teachers work for one department.

Finding out about the relationships between tables

  1. Use the ERD. You can highlight relationships From and To
  2. Use the properties?? Relationships are listed under From and To

Many-to-many

To create a many-to-many relationship, you need an intermediate table that has foreign key attributes from the tables you want to connect.

For example, there is a many-to-many relationship between customers and products.

  • A customer → buys → many products
  • A product → is bought by → many customers

The intermediate Customer Purchase Record table has both the CustomerID and ProductID as foreign keys.

  • Customer purchase → records → CustomerIDs
  • Customer purchase record → lists → ProductIDs





  • No labels