Tables and Attributes

The table name is displayed in the header.

The table has a list of attributes. 

Image Removed

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.

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. Provide an example?

, which represent the different data you want to record. For example, the Teacher table records the Department, Address and Name of teachers.

Image Added

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.

Special Attribute: UID or 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 that contains a unique value for this attributeevery record. For  For example, several customers teachers can have the same first or family name, or even both, so these attributes cannot be a UID. PhixFlow makes sure every data record has a unique value, by generating a unique number for the UID.automatically adding an attribute called UID, which is short for Unique IDentifier.   Image Added called its primary key. PhixFlow automatically adds a primary key when you create a table. 

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.

Image Removed

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.  Image Added

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

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. 

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

   Insert excerpt
   _more_options _more_options nopanel true

   .
3. Select tbc

Context menu

To see the context menu for a table:

• in the table header, click 

  Insert excerpt
  _more_options_erd _more_options_erd nopanel true

   
• 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