Welcome to Boston Top Previous Next
Welcome to Boston! Boston sets the standard for the development
of Object-Role Modeling diagrams for database and software
analysis and design.
FactEngine approaches software design much like the painstaking
work required to develop a fine watch movement. Boston has well in
excess of 300,000 lines of code and millions of pieces of information
that we bring together to provide the best possible product that we
can deliver. As an art form we constantly hone our skills and adopt
new technologies in order to refine the products that we build, much
like fine watchmakers.
Treated carefully, Boston will give you years of satisfaction when
analysing and designing databases, software structures and
ontologies.
Much like a fine watch movement, the Boston database and
metamodel have been carefully designed to bring to you state of the
art. As the only stand-alone ORM Modeling tool on the market
targeting ORMv2, Boston represents years of research and
development rolled into one product.
We hope that Boston brings you years of enjoyment, assisting to
deliver to the quality levels you aspire to.
The Model Explorer Top Previous Next
The Model Explorer provides a list of ORM Models and their Pages
that are either:
1. Stored within the Boston database; or
2. Have been imported into Boston from a .fbm XML file during the
current session;
The Model Explorer is automatically loaded when Boston starts and
provides an easy way to navigate to the Model and/or Page that you
wish to work with within the Workbench.
The picture below is of the Model Explorer.
The Model Explorer
Using the Model Explorer Form
Each Model is listed, one below the other. If the Model contains
Pages (as most Models do), a [+] symbol appears to the left of the
Model name.
Viewing Pages within a Model
Click on the [+] symbol to expand the view the list of Pages for the
Model (the symbol changes to the [-] symbol).
If the [-] symbol appears next to Model's name in the Model
Explorer, clicking on the [-] symbol will hide the list of Pages for the
Mode (the [-] symbol changes to the [+] symbol).
Adding a Model to the Model
Explorer
Top Previous
Next
There are two ways to add a new Model to the list of Models in the
Model Explorer:
1. Add a new Model directly to the database; or
2. Import an ORM Model from a .fbm XML file.
The following help topics outline the ways to add a new Model to the
Model Explorer.
Adding a Model directly to the
database
Top Previous
Next
The following steps outline how to add a new Model directly to the
database:
1. Make sure the Model Explorer is open within the Boston
workbench;
2. Right-click with the mouse on the "Boston" node at the top of the
tree displayed within the Model Explorer.
A context menu will open with the options that you have to add a
new Model to the Model Explorer and the Boston database.
3. Select the "Add ORM Model" option within the context menu;
A new Model will appear at the bottom of the list of Models
displayed in the Model Explorer.
The following picture shows the Model, "New ORM Model 14"
added to the list of Models in the Model Explorer.
Import an ORM Model from a .fbm XML
file.
Top Previous
Next
You can import Models directly into Boston and the Model Explorer by
importing a .fbm XML file.
"fbm" stands for "Fact-Based Modeling" and all ORM Models are Fact-
Based Models.
The following steps outline how to import a Model directly into Boston
and the Model Explorer by importing a .fbm XML file:
1. Make sure the Model Explorer is open within the Boston workbench;
2. Right-click with the mouse on the "Boston" node at the top of the tree
displayed within the Model Explorer.
A context menu will open with the options that you have to add a new
Model to the Model Explorer and the Boston database.
3. Select the "Import ORM .fbm file" option within the context menu;
4. A "Open File" dialog box will be opened for you to navigate to and
open a .fbm file.
5. Select the Fact-Based Modeling file that you would like to import into
Boston and the Model Explorer, and then select the [Open] button on
the Open File dialog;
6. The ORM Model will be imported into Boston and displayed at the
bottom of the list of Models within the Model Explorer.
Loading an existing ORM Model Top Previous Next
The following steps outline how to load an existing Model for editing.
1. Make sure the Model Explorer is open within the Boston
workbench;
2. Left-click on the Model within the list of Models displayed within
the Model Explorer;
The Model will load from the Boston database.
3. When the Model has finished loading from the Boston database,
the Status Bar at the bottom of the Boston workbench will read
"Model Loaded: <The name of the Model Loaded>"
Deleting an ORM Model Top Previous Next
The following steps outline how to delete an existing ORM Model
from the Boston database.
1. Make sure the Model Explorer is loaded within the Boston
workbench;
2. Right-click on the Model that you would like to delete within the
list of Models within the Model Explorer.
You will be presented with the Model context menu.
3. Select the [Delete Model] menu option within the Model context
menu.
The Model will be deleted from the Boston database and
removed from the list of available Models within the Model
Explorer.
Emptying an ORM Model Top Previous Next
The following steps outline how to Empty an existing ORM Model of
all its Model Elements.
1. Make sure the Model Explorer is open within the Boston
workbench
2. Right-click on the Model that you would like to Empty, within the
list of Models within the Model Explorer.
You will be provided with the Model context menu.
3. Select the [Empty Model] menu option within the Model context
menu;
4. The Model will be emptied of all Model Elements, and will (in
effect) be an empty Model.
Working with a Model's Pages Top Previous Next
Models in Boston are edited by working with views over the Model
called, 'Pages'. Each Page is a view of a subset or entire view of the
Model you are working with.
Conceptually, and at the physical database level, within Boston
each Model stores all of the Model Elements of that Model (i.e. The
ORM Model itself), and each Page is a view over that ORM Model.
The following picture provides a conceptualised view of the
relationship between a Model and the Page views over that Model.
Conceptual view of a Model with three Page views over that Model
The following help topics outline how to Add, Edit and Delete Pages
that are over an ORM Model.
Why work with Pages?
There are numerous reasons why it is convenient to work with
Pages over a Model:
1. Pages offer a convenient way to view a Model, especially large
and complex Models. If a Model is large and complex, each
Page can provide a subset view of that Model which is
convenient to digest and work with;
2. Model Elements within a Page can be deleted from that Page
without deleting the Model Element from the Model;
3. In as much as the collection of Pages over a Model depict that
Model, the collection of Pages for a Model forms the entire
visible view of that Model (i.e. the ORM Diagram of that Model);
4. ORM Models contain Model Elements that are not visible, or
'usually visible' to a user viewing the Model;
e.g. A Subtype Relationship, while viewed as an arrow from the
Subtype Object Type, to the Supertype Object Type within an
ORM Diagram, are stored as Fact Types (called, 'Identity Fact
Types') within the Model. These Fact Types are not visible to a
person viewing the ORM Diagram, but exist within the ORM
Model and play a crucial role in the management of ORM Models
containing Subtype Relationships.
See the help topic, Pages, for instructions on how to Add, Edit and
Delete Pages that are over an ORM Model.
Adding a Page to an ORM Model Top Previous Next
The following steps outline how to add a Page to a Model:
1. Make sure the Model Explorer is open in the Boston workbench
2. Find and select a Model in the Model Explorer by clicking on the
Model in the list of Models within the Model Explorer
3. Right-click on the Model to which you would like to add a Page.
The Model context-menu will appear:
4. Select the option, [Add Page] within the context-menu;
A new Page will appear at the bottom of the list of Pages for the
selected Model:
Editing a Page Top
Previous
Next
Pages are edited within the Boston workbench by opening the Page
from within the Model Explorer. The rich graphic user interface allows
you to manage all Model Elements of a Model within the Page editing
form and associated Toolboxes.
The next topics outline how to open and commence editing a Page
within a Model:
Opening an existing Page for editing
A Page being edited with the Boston workbench
Opening an existing Page for editing Top Previous Next
The following steps outline how to open an existing Page for editing from
within the Model Explorer:
1. Make sure the Model Explorer is open within the Boston workbench;
2. Navigate to a Model and Page within the Model Explorer;
3. Right-click on the Page within the Model that you wish to open for
viewing or editing within the Boston workbench.
A context-menu will appear with the options that you can select for
that Page.
4. Click on the [Edit Page] option within the context-menu;
The Page will be opened within the Boston workbench for viewing and
editing.
Editing a Page Top Previous Next
To edit a Page over a Model, follow the steps in the following help
topics:
1. Adding Model Elements to a Model (Provides the steps to add
Entity Types, Value Types, Fact Types, Role Constraints and
Model Notes to a Model);
2. Working with Model Elements (Provides the steps to view the
properties of a Model Element and how to remove Model
Elements from a Page and/or a Model);
NB The blank (white) area of a Page is called the "canvas".
Deleting a Page Top Previous Next
The following steps outline how to remove or 'Delete' a Page from a
Model:
NB Deleting a Page from a Model does not remove the Model
Elements within that Page from the Model. Each Page is a view
over a Model, and not the Model itself. To remove individual Model
Elements from a Model, see the help-topics Removing a Model
Element from a Page and a Model
1. Make sure the Model Explorer is open within the Boston
workbench;
2. Find and select the Page within the Model
3. Right-click on the Page within the Model Explorer
The Page context-menu will appear
4. Select the [Delete Page] option with the context menu.
The Page will be removed/deleted from the Model.
Copying a Page Top Previous Next
To copy an entire Page to the clipboard, follow the steps below:
1. Make sure the Model Explorer is open within the Boston
workbench;
2. Navigate to the Page that you would like to copy to the clipboard,
within the Model Explorer;
3. Right click on the Page.
The Page context menu will appear:
4. Select the [Copy Page] option within the Page context menu.
The Page will be copied to the clipboard in its entirety.
NB The respective Model Elements at the Model level will also
be copied to the clipboard, so if you paste the Page from the
clipboard to another Model, those Model Elements will be
migrated to the second Model.
Pasting a Page Top Previous Next
The following steps outline how to paste a Page to a Model.
1. Make sure that the Model Explorer is open within the Boston
workbench;
2. Navigate to the Model to which you would like to paste the Page
that is within the clipboard;
3. Right-click on the Model.
You will be presented with the Model context menu:
4. Select the [Paste Page] menu option within the Model context
menu.
The Page (and all associated Model Elements) will be pasted
(appended) to the selected Model.
NB If there are any conflicts in the Model Elements being
appended to the Model (from the Model of the source of the
Page), you will be prompted to resolve the conflicts.
NB If there is no Page within the clipboard, the [Paste Page]
menu option will be disabled (as in the picture above).
Creating an ORM Diagram Top Previous Next
Boston is custom built to develop Object-Role Models, or 'ORM
Diagrams'. Commonly referred to as 'ORM Models' (Object-Role
Modeling Models), ORM Diagrams capture the semantics and
structure of your data model.
Once you have mastered the Model Explorer and learned how to
create ORM Models and Pages over those Models, the following
help topics describe how to create ORM Diagrams using Boston.
Overview Top Previous Next
Boston has what is called a 'Workbench'. A workbench is a Multiple
Document Interface (MDI) where all of the sub-forms (or 'documents')
are presented to the user in one main form, the Boston workbench.
Boston allows you to work with multiple views over an ORM Model,
called 'Pages'.
The following help topic outlines what a Page is, and how Pages
relate to the ORM Model that they represent (Pages).
The Boston Workbench
Pages Top Previous Next
Each Page of an ORM Model is a view over an ORM Model. Pages
are displayed within the Model Explorer as a list of Pages for a
Model.
For a detailed description of Pages, see the help topic, Managing
Pages
Pages are displayed in the Model Explorer as document icons
under the Model icon within the tree displayed within the Model
Explorer. The picture below shows a set of three Pages for a Model
called, 'My Model'.
Pages within a Model within the Model Explorer
To create an ORM Model in Boston you need at least one Page
view over that Model.
This chapter assumes that you have already created a Page for a
Model and opened that Page to start creating an ORM Diagram.
Pan using the mouse
To pan the model elements on a Page, hold down the [Alt] key on
your keyboard while clicking and dragging with the mouse on the
canvas of the Page.
Pan using the keyboard
Hold the [Ctrl] key down and use the arrow buttons on your
keyboard to span using your keyboard.
Adding Model Elements to a Model Top Previous Next
This chapter outlines how to add Model Elements to a Model.
There are many ways to add a Model Element to a Page and
Model:
a) Using the Toolbox;
b) Using Shortcut Key combinations (Shortcut Key
Combinations); c) Copying and Pasting Model Elements from
another Page or Model (Copying and Pasting Model Elements,
Adding a Model Element to one Model from another Model)
For details on how to add a specific type of Model Element to a
Page/Model, use the following links:
Adding an Entity Type to a Model and Page
Adding a Value Type to a Model and Page
Adding a Fact Type to a Model and Page
Adding a Role Constraint to a Model and Page
Adding a Model Note to a Model and Page
The Toolbox Top Previous Next
The Toolbox is a form used within the Boston workbench to add
Model Elements to a Page and Model.
The Toolbox contains a list of Model Elements that can be dragged
from the Toolbox onto the canvas of a Page open for editing or onto
other Model Elements within the Page.
To open the Toolbox, follow the these steps:
1. Make sure a Page is open for viewing within the Boston
workbench
2. Right-click on a blank area within the canvas of the Page, and
select the [View]->[Toolbox] option within the context-menu that
you are presented with
Or...
1. Select the [View]->[Toolboxes]->[Toolbox] menu option from
within the set of menus at the top of the Boston workbench.
The Toolbox will appear on the right hand side of the Boston
workbench. The following is a picture of the Toolbox:
The Toolbox
Shortcut Key Combinations Top Previous Next
Model Elements can be added to a Page by use of Shortcut Key
combinations depressed on the keyboard of your computer.
Other Shortcut Key combinations manipulate the Model Elements
within the Page and the zooming of the Page itself.
The following table is a list of the Shortcut Key combinations that
you can use to add Model Elements to a Page:
Shortcut Key
Combination
Functionality / End Result
Ctrl + E Adds an Entity Type to the current
Page
Ctrl + V Adds a Value Type to the current
Page
R
1. If an Entity Type is selected on the
Page, adds a Fact Type with one Role
(i.e. a Unary Fact Type) joined to that
selected Entity Type 2. If a Role of a
Fact Type is selected and either an
Entity Type, Value Type or Objectified
Fact Type is also selected, selecting
the [R] key automatically adds a Role
to the Fact Type of the selected Role,
joining the selected Entity Type / Value
Type / Objectified Fact Type.
[>] (Right
Arrow)
Moves the currently selected Model
Element to the right
[<] (Left
Arrow)
Moves the currently selected Model
Element to the left
[^] (Up
Arrow)
Moves the currently selected Model
Element upwards
[V] (Down
Arrow)
Moves the currently selected Model
Element downwards
U
1.When a Role is selected within a Fact
Type, adds an Internal Uniqueness
Constraint to the Role / Fact Type over
the selected Role
NB An Internal Uniqueness Constraint
spanning one Role must be valid for the
Fact Type, otherwise no Uniqueness
Constraint is added.
2. If more than one Role is selected
within a Fact Type, adds an Internal
Uniqueness Constraint spanning the
Roles selected.
NB The span of the desired Internal
Uniqueness Constraint must be valid for
the Fact Type, otherwise no Uniqueness
Constraint is added.
P
Opens the Properties Toolbox
M
Adds a Mandatory Constraint to a
selected Role within a Fact Type
G
Adds a Ring Constraint to the set of
selected Roles.
NB More than one Role must be
selected, and a Ring Constraint must be
valid for the selected Roles.
O
Adds an Exclusive-OR Constraint to
the set of selected Roles.
[+] (Add
button)
Zooms the Page in
[-] (Subtract
button)
Zooms the Page out
E
Adds an Equality Constraint to the set of
selected Roles
S
Adds a Subtype Relationship to the set of
two selected Object Types.
T
Creates a Total Internal Uniqueness
Constraint for the selected Fact Type
X
Adds an External Exclusion Constraint to
the set of selected Roles
Alt + X Adds an Exclusive-OR Constraint to the
set of selected Roles
Adding an Entity Type to a Model
and Page
Top Previous
Next
There are four ways to add an Entity Type to a Model and Page.
1. Dragging an Entity Type from the Toolbox;
2. Using a Shortcut Key Combination;
3. Pasting an Entity Type from another Model;
4. Dragging an Entity Type from within the Model Dictionary;
Dragging an Entity Type from the Toolbox To add a new
Entity Type to a Model and Page from the Toolbox, follow the
following steps: 1. Make sure that you have a Page open for the
Model that you are working with within the Workbench; 2. Make
sure that the Toolbox is visible on the right hand side of the
Workbench; a. If the Toolbox isn't visible on the right hand side of
the Workbench, right-click on the canvas of a Page and select
[View]->[Toolbox] within the context menu that is presented to you.
3. Drag the Entity Type shape from the Toolbox onto a blank area of
the canvas of the Page that you are working on within the
Workbench.
Using a Shortcut Key Combination
1. Make sure that you have a Page open for the Model that you are
working with within the Workbench; 2. Press the following key
combination on your keyboard:
[Ctrl] + [E]
Pasting an Entity Type from another Model If you have
copied an Entity Type to the clipboard from within another Model,
the following steps outline how to paste that Entity Type to the
current Model/Page:
1. Make sure that you have a Page open for the Model that you are
working with within the Workbench;
2. Select the [Edit]->[Paste] menu option from the main Boston
menu.
Dragging an Entity Type from within the Model
Dictionary
1. Make sure that you have a Page open for the Model that you are
working with within the Workbench;
2. Open the Model Dictionary;
3. Navigate to the Entity Type that you would like to add to the
current Page/Model;
4. Drag the Entity Type icon from the Model Dictionary to a blank
area of the canvas of the open Page.
The Entity Type will be copied to the open Page.
Adding a Value Type to a Model and
Page
Top Previous
Next
There are four ways to add an Value Type to a Model and Page.
1. Dragging an Value Type from the Toolbox;
2. Using a Shortcut Key Combination;
3. Pasting a Value Type from another Model;
4. Dragging a Value Type from within the Model Dictionary;
Dragging an Value Type from the Toolbox To add a new
Value Type to a Model and Page from the Toolbox, follow the
following steps: 1. Make sure that you have a Page open for the
Model that you are working with within the Workbench; 2. Make
sure that the Toolbox is visible on the right hand side of the
Workbench; a. If the Toolbox isn't visible on the right hand side of
the Workbench, right-click on the canvas of a Page and select
[View]->[Toolbox] within the context menu that is presented to you.
3. Drag the Value Type shape from the Toolbox onto a blank area of
the canvas of the Page that you are working on within the
Workbench.
Using a Shortcut Key Combination
1. Make sure that you have a Page open for the Model that you are
working with within the Workbench; 2. Press the following key
combination on your keyboard:
[Ctrl] + [E]
Pasting an Value Type from another Model If you have
copied a Value Type to the clipboard from with another Model, the
following steps outline how to paste that Value Type to the current
Model/Page:
1. Make sure that you have a Page open for the Model that you are
working with within the Workbench;
2. Select the [Edit]->[Paste] menu option from the main Boston
menu.
Dragging an Value Type from within the Model
Dictionary
1. Make sure that you have a Page open for the Model that you are
working with within the Workbench;
2. Open the Model Dictionary;
3. Navigate to the Value Type that you would like to add to the
current Page/Model;
4. Drag the Value Type icon from the Model Dictionary to a blank
area of the canvas of the open Page.
The Value Type will be copied to the open Page.
Adding a Fact Type to a Model and
Page
Top Previous
Next
There are four ways to add a Fact Type to a Model:
1. Dragging a Role from the Toolbox onto a Page or another Role
2. Using a Shortcut Key Combination;
3. Pasting a Fact Type from another Model;
4. Dragging a Fact Type from within the Model Dictionary;
Dragging an Role from the Toolbox onto a Page or
another Role To add a new Fact Type to a Model and Page from
the Toolbox, follow the steps in the following help topics: Adding a
Fact Type to a Model using the Toolbox
Extending a Fact Type by adding a Role
Using a Shortcut Key Combination
To add a new Fact Type to a Model using a Shortcut Key
combination, follow the steps in the following help topic: Adding a
New Fact Type
Pasting an Fact Type from another Model
If you have copied a Fact Type to the clipboard from with another
Model, the following steps outline how to paste that Fact Type to the
current Model/Page:
1. Make sure that you have a Page open for the Model that you are
working with within the Workbench;
2. Select the [Edit]->[Paste] menu option from the main Boston
menu.
Dragging an Fact Type from within the Model Dictionary
1. Make sure that you have a Page open for the Model that you are
working with within the Workbench;
2. Open the Model Dictionary;
3. Navigate to the Fact Type that you would like to add to the
current Page/Model;
4. Drag the Fact Type icon from the Model Dictionary to a blank
area of the canvas of the open Page.
The Fact Type will be copied to the open Page.
Adding a Role Constraint to a Model
and Page
Top Previous
Next
This chapter outlines how to add Role Constraints to a Model and
Page. Focus is on External Role Constraints (i.e. all Role
Constraints that are not an Internal Uniqueness Constraint) NB To
add an Internal Uniqueness Constraint to a Fact Type, see the help
topic: Adding an Internal Uniqueness Constraint to a Fact Type
There are three ways to add a Role Constraint to a Model/Page:
1. Drag a Role Constraint from the Toolbox;
2. Use a Shortcut Key combination (Shortcut Key Combinations);
3. Copy/Paste a Role Constraint from another Page and/or Model;
4. Drag a Role Constraint from the Model Dictionary onto a Page.
Using the Toolbox to create a new
Role Constraint
Top Previous
Next
The steps below outline how to create a new Role Constraint within
a Model/Page by using the Toolbox.
The Toolbox contains 8 types of Role Constraints that can be added
to a Model and Page:
1. Ring Constraints
2. External Uniqueness Constraints
3. Equality Constraints
4. Exclusion Constraints
5. Inclusive-OR Constraints
6. Exclusive-OR Constraints
7. Subset Constraints
8. Frequency Constraints
Follow the steps below to use the Toolbox to add a new Role
Constraint to a Page/Model:
1. Make sure a Page is open for editing within the Boston
workbench;
2. Make sure the Toolbox is open within the Boston workbench;
3. Drag the type of Role Constraint that you would like to create
within the Page/Model onto a blank area of the canvas of the
open Page;
NB Frequency Constraints are the exception, and must be
dragged and dropped onto the Role to which the Frequency
Constraint applies.
4. Drop the Role Constraint onto a blank area of the open Page;
5. The Role Constraint will be added to the Page/Model.
NB The new Role Constraint will not, at this stage, be allocated
to apply to any specific Roles. See the links to instructions below
for the steps to associate a Role Constraint with specific Roles.
Once the new Role Constraint has been added to the Page/Model,
you need to associate the Role Constraint to the Roles to which the
Role Constraint applies.
The following links point to the help topics, for the specific type of
Role Constraint, that outline how to associate a Role Constraint with
specific Roles.
Ring Constraints - Assigning Roles to a Ring Constraint
External Uniqueness Constraints - Assigning Roles to an External
Uniqueness Constraint
Equality Constraints - Assigning Roles to an Equality Constraint
Exclusion Constraints - Assigning Roles to an Exclusion Constraint
Inclusive-OR Constraints - Assigning Roles to an Inclusive-OR
Constraint
Exclusive-OR Constraints - Assigning Roles to an Exclusive-OR
Constraint
Subset Constraints - Assigning Roles to a Subset Constraint
Frequency Constraints - N/A A Frequency Constraint is
automatically allocated to a Role when the Frequency Constraint is
created.
Adding a Model Note to a Model and
Page
Top Previous
Next
To add a new Model Note to a Model and Page from the Toolbox,
follow the following steps:
1. Make sure that you have a Page open for the Model that you are
working with within the Workbench;
2. Make sure that the Toolbox is visible on the right hand side of the
Workbench;
3. If the Toolbox isn't visible on the right hand side of the
Workbench, right-click on the canvas of a Page and select
[View]->[Toolbox] within the context menu that is presented to
you.
4. Drag the Model Node icon from the Toolbox onto a blank area of
the canvas of the Page that you are working on within the
Workbench.
A new Model Note will be added to the Page/Model.
Working with existing Model
Elements
Top Previous
Next
Model Elements are those conceptual entities and associated text
that provide the structure of an ORM Diagram and a Model.
e.g. Entity Types, Value Types, Fact Types, Role Constraints and
Model Notes are all Model Elements.
In Boston, any shape or text that can be viewed within a Page is a
Model Element. Model Elements are, in effect, the 'elements' that go
into the construction of a Model.
Boston provides a convenient way to view the properties of any
Model Element within a Page of a Model by viewing those
properties within the Properties Toolbox (see The Properties
Toolbox ).
The help topic, Viewing a Model Element's Properties, outlines how
to view the properties of a Model Element within the Properties
Toolbox.
Selecting Model Elements Top Previous Next
The following steps outline how to selected a Model Element within
a Page: NB The steps in this help topic apply to a Page that already
has Model Elements on the Page. For steps on how to add Model
Elements to a Page, see the help topic: Adding Model Elements to a
Model
1. Make sure that a Page is open for editing within the Boston
workbench;
2. With your mouse, maneuver the mouse cursor over the Model
Element that you would like to select;
3. Left-click on your mouse.
The Model Element that you have just selected will now have a
blue outline.
The following picture shows the "Book" Model Element selected
within a Model:
Selecting Multiple Model Elements Top Previous Next
There are two ways to select multiple Model Elements within a
Page:
1. Clicking, [Ctrl] + Clicking on multiple Model Elements; and
2. Dragging a lasso over multiple Model Elements
Selecting Multiple Model Elements -
Clicking, [Ctrl] + Clicking To select multiple Model
Elements within a Page, follow the following steps:
1. Select the first Model Element following the steps above;
2. Hold down the [Ctrl] key on your keyboard, and select other
Model Elements within the Page.
Each of the selected Model Elements will now have a bright blue
outline.
The following picture shows the "Book" and "Language" Model
Elements both selected.
Dragging a Lasso over Multiple Model
Elements To select multiple Model Elements by dragging a
lasso over the Model Elements, use the following steps:
1. Left-Click on any blank area in the canvas of the Page;
2. Drag a lasso over the Model Elements that you would like to
select.
The image below shows a lasso dragged over a set of multiple
Model Elements:
3. Release the left mouse button when you have finished selecting
a set of Model Elements.
The selected multiple elements will have their border colour
changed to bright blue or bright purple.
The image below shows a set of Model Elements selected by
dragging a lasso over the Model Elements:
Viewing a Model Element's
Properties
Top Previous
Next
To view the properties of a Model Element within a Model (e.g. an
Entity Type), open the Properties Toolbox and click on the Model
Element. If the Properties Toolbox is already open on the
workbench, simply click on the Model Element.
The following steps outline how to view a Model Element's
properties within the Properties Toolbox:
1. Make sure the Properties Toolbox is open on the Boston
workbench
2. Left-click on the Model Element within the Page that you are
currently working with within the Boston workbench.
The properties of the Model Element will appear within the
Properties Toolbox.
For example, the following picture shows the properties of the
Fact Type, 'BookIsTranslatedToLanguage', displayed within the
Properties Toolbox
Copying a Model Element Top Previous Next
The following steps outline how to copy a Model Element to the
clipboard:
1. Select the Model Element within the Page that you are working
with within the Boston workbench;
2. From the main Boston menu, select and open the [Edit] menu.
3. Select the [Copy] option.
The selected Model Elements will be copied to the clipboard.
Pasting a Model Element Top Previous Next
The following steps outline how to paste Model Elements from the
clipboard:
1. Make sure that you have a Page open within the Boston
workbench;
2. From the main Boston menu, select and open the [Edit] menu.
3. Select the [Paste] option.
The Model Elements that are in the clipboard will be pasted to
the Page open for editing within the Boston workbench.
Removing a Model Element from a
Page
Top Previous
Next
To remove a Model Element from a Page follow the steps below:
Using the Context Menus for a Model Element
to Remove Model Elements from a Page NB Not all
Model Element types have a context menu. Right-click on a Model
Element within a Page to see if it has a context menu.
1. While editing a Page, right-click on the Model Element that you would
like to remove from the Page
2. If the Model Element type has a context menu, it will open and be
presented to you.
The picture below shows the context menu for a Fact Type
3. Select the menu option, [Remove from Page].
If no model error would occur if removing the Model Element, the
Model Element will be removed from the Page.
Using the Keyboard to Remove Model Elements
from a Page NB Most Model Elements are only removed from the
Page (not the Model) when using the keyboard to remove the Model
Element from a Page.
1. Select the Model Element that you would like to remove from the Page
by right-clicking on the Model Element;
2. Depress the [Delete] key on your keyboard.
If no model error would occur if removing the Model Element, the
Model Element will be removed from the Page.
NB Roles within a Fact Type are deleted from the Page and the Model
when using the keyboard to remove the Role from a Fact Type.
Removing a Model Element from a Page
and a Model
Top Previous
Next
To remove a Model Element from a Page and Model follow the steps
below: Using the Context Menus for a Model
Element to Remove Model Elements from a
Page and Model NB Not all Model Element types have a context
menu. Right-click on a Model Element within a Page to see if it has a
context menu.
1. While editing a Page, right-click on the Model Element that you would
like to remove from the Page and the Model
2. If the Model Element type has a context menu, it will open and be
presented to you.
The picture below shows the context menu for a Fact Type
3. Select the menu option, [Remove from Page & Model].
If no model error would occur if removing the Model Element, the
Model Element will be removed from the Page and the underlying
Model.
Using the Keyboard to Remove Model Elements
from a Page and Model NB Most Model Elements are only
removed from the Page (not the Model) when using the keyboard to
remove the Model Element from a Page.
1. Select the Model Element that you would like to remove from the Page
and Model by right-clicking on the Model Element;
2. Depress the [Delete] key on your keyboard.
If no model error would occur if removing the Model Element, the
Model Element will be removed from the Page and the underlying
Model.
Specific Model Element
Management
Top Previous
Next
This chapter outlines the steps to follow when maintaining the types
of Model Elements visible within an ORM Diagram on a Page, when
editing that Page within the Boston workbench.
Model Elements are all logical grouping of things that you can see
within an ORM Diagram displayed on a Page. For example, Value
Types, Entity Types, Fact Types, Role Constraints and Model Notes
are all Model Elements. The links between an External Role
Constraint and the Roles they join to are Model Elements.
NB The line linking a Role to the Object Type that it joins to is
considered a part of the Role, Model Element.
All Model Elements within an ORM Model can be added and edited
or deleted from within a Page being worked on within the Boston
workbench.
Managing Value Types Top Previous Next
Value Types are named lists of values. Value Types are relatively
easy to maintain, requiring only definition of their Name, their Data
Type and any Value Constraint that applies to the Value Type.
The help topics in this chapter outline how to maintain a Value Type.
Managing Value Type Properties
Managing Value Type Properties Top Previous Next
The following steps outline how to view the properties of a Value
Type:
1. Make sure a Page containing an ORM Diagram containing a
Value Type is open within the Boston workbench;
2. Make sure the Properties Toolbox is open within the Boston
workbench;
3. Left-click on the Value Type.
The Properties Toolbox will show the properties of the Value
Type.
Value Type Properties
The following table outlines the properties of a Value Type and the
data that should be entered for each property:
Property Description and Data
Requirements
Name The name of the Value Type. Enter
a name that is unique amongst all
Value Types, Entity Types, Fact
Types and Role Constraints.
DataType The data type of the
elements of the list of values
of the Value Type.
DataTypeLength /
DataTypePrecision
If the DataType of the Value
Type requires more precision
in the definition of the data
type, this property will
appear. Enter the
appropriate precision for the
DataType.
ValueConstraint If the Value Type has a Value
Constraint edit the values in
the collection of this property.
ShortDescription A short description of the
Value Type.
LongDescription A long description of the Value
Type.
Value Constraints
Value Constraints have three main types:
1. Enumerations
2. Value Ranges
3. Multiple Combinations of Enumerations and/or Value Ranges
Enumerations
An Enumerated Value Constraint lists the discrete Values that are
valid for a Value Type.
The picture below shows an Enumerated Value Constraint for the
Value Type, 'SexCode', which in this instance forms the Reference
Mode for the Entity Type, 'Sex'.
The discrete values are 'M' for Male and 'F' for Female.
Enumerated Value Constraint Value Ranges
A Value Constraint may constrain a Value Type to a range of values.
The picture below shows a Value Constraint Range for the Value
Type, 'LowercaseChar', limiting the values to the letters 'a' through
'z'.
Value Constraint Range Multiple Value Constraints A Value Type
may have multiple Value Constraints.
The picture below shows a Value Type, 'WheelCount' (e.g. the
number of wheels on a vehicle), with values limited in the ranges,
2..4 and 16..18
Multiple Value Constraints
Adding Value Constraints to a Value
Type
Top Previous
Next
The following steps outline how to add a Value Constraint to a Value
Type:
1. Make sure the Properties Toolbox is open within the Boston
workbench
2. Select the Value Type that you would like to add a Value
Constraint to;
The Properties Toolbox will now show the properties of the Value
Type:
3. Within the Properties Toolbox, select the ValueConstraint
property;
4. Click on the ellipsis ( ) icon within the ValueContraint property.
The Value Constraint editor (String Collection Editor) will appear.
5. Select the [Add] button. A new Value Constraint member will
appear:
6. Change the Value in the 'String properties' area:
7. When you have finished modifying the 'Value' property for the
new Value Constraint, press the [Enter] key on your keyboard.
The new Value Constraint will appear under the 'Members' area
of the Value Constraint editor.
Managing Entity Type Properties Top Previous Next
The following steps outline how to view the properties of a Entity
Type:
1. Make sure a Page containing an ORM Diagram containing a
Entity Type is open within the Boston workbench;
2. Make sure the Properties Toolbox is open within the Boston
workbench;
3. Left-click on the Entity Type.
The Properties Toolbox will show the properties of the Entity
Type.
Entity Type Properties
The following table outlines the properties of a Entity Type and the
data that should be entered for each property:
Property Description and Data
Requirements
Name The name of the Entity Type. Enter
a name that is unique amongst all
Entity Types, Value Types, Fact
Types and Role Constraints.
DataType The Data Type of the Value
Type of the Reference
Scheme of the Entity Type, if
the Entity Type does not
have a Compound
Reference Scheme.
NB This property is only
displayed for editing if the
Entity Type's
'ReferenceMode' property is
not blanck.
DataTypeLength /
DataTypePrecision
If the DataType of the Value
Type of the Entity Type's
Reference Scheme (Entity
Types without a Compound
Reference Scheme only)
requires more precision in
the definition of the data
type, this property will
appear. Enter the appropriate
precision for the DataType.
ExpandReferenceMode If the EntityType does not
have a Compound
Reference Scheme (i.e.
the ReferenceMode
property of the Entity
Type is not blank), setting
this property value to
True will expand the
Reference Mode of the
Entity Type so that the
associated Fact Type and
Value Type are visible
within the current Page.
Setting the value to False
will hide the Reference
Mode/Scheme of the
Entity Type.
ReferenceMode If the Entity Type does not
have a Compound Reference
Scheme, but has a Reference
Mode, this property displays
the Reference Mode for the
Entity Type.
ValueConstraint If the Entity Type has a Value
Constraint edit the values in
the collection of this property.
ShortDescription A short description of the
Entity Type.
LongDescription A long description of the Entity
Type.
Setting Inclusive-OR Subtype
Constraints
Top Previous
Next
The following steps outline how to create Inclusive-OR Subtype
Constraints.
1. Make sure you have an ORM Diagram with more than one
Object Type as the Subtype of the same Object Type;
2. Drag an Inclusive-OR Role Constraint from the Toolbox onto the
Page;
3. From just inside the outer edge of the Role Constraint, drag a
connecting link from the Role Constraint to the Subtype
Relationship link of the first Subtype Relationship;
4. From just inside the outer edge of the Role Constraint, drag a
connecting link from the Role Constraint to the Subtype
Relationship link of the other Subtype Relationship that you
would like included in the Inclusive-OR Subtype Constraint.
Setting Exclusive-OR Subtype
Constraints
Top Previous
Next
The following steps outline how to create Exclusive-OR Subtype
Constraints.
1. Make sure you have an ORM Diagram with more than one
Object Type as the Subtype of the same Object Type;
2. Drag an Exclusive-OR Role Constraint from the Toolbox onto the
Page;
3. From just inside the outer edge of the Role Constraint, drag a
connecting link from the Role Constraint to the Subtype
Relationship link of the first Subtype Relationship;
4. From just inside the outer edge of the Role Constraint, drag a
connecting link from the Role Constraint to the Subtype
Relationship link of the other Subtype Relationship that you
would like included in the Exclusive-OR Subtype Constraint.
Managing Fact Type Properties Top Previous Next
The following steps outline how to view the properties of a Fact
Type:
1. Make sure a Page containing an ORM Diagram containing a
Fact Type is open within the Boston workbench;
2. Make sure the Properties Toolbox is open within the Boston
workbench;
3. Left-click on the Fact Type.
The Properties Toolbox will show the properties of the Fact Type.
Fact Type Properties
The following table outlines the properties of a Fact Type and the
data that should be entered for each property:
Property Description and Data
Requirements
Name The name of the Fact Type. Enter a
name that is unique amongst all
Fact Types, Entity Types, Value
Types and Role Constraints.
IsObjectified Set this property to True to
Objectify the Fact Type.
If the Fact Type is already
Objectified, setting this property
to False will change the Fact
Type so that it is no longer
Objectified.
ShowFactTypeName Set this property to True to
show the name of the Fact
Type on the Page.
ShortDescription A short description of the Fact
Type.
LongDescription A long description of the Fact
Type.
Adding a New Fact Type Top Previous Next
The following help topics outline how to add a new Fact Type to a
Model.
Using the keyboard to add a new Fact Type
to a Model The quickest and easiest way to add a new Fact
Type to a Model is to use the keyboard.
The following steps outline how to add a new Fact Type to a Model
using the keyboard: Adding a Unary Fact Type to a Model
1. Select the Object Type to which you would like to add a Unary
Fact Type;
2. Press the [R] key on your keyboard.
A new Fact Type with a single Role will be added to the selected
Object Type
Adding a Fact Type to a Model using
the Toolbox
Top Previous
Next
The following steps outline how to create a new Fact Type within a
Model using the Toolbox.
1. Make sure the Toolbox is open within the Boston workbench;
2. Select and drag the 'Role' icon from the Toolbox onto a blank are
of the Page's canvas.
You will be presented with the 'New Role' dialog box.
3. Enter the desired name of the Fact Type;
4. Enter the name of the Role (if you would like the Role to have a
name);
5. Check the 'Mandatory Role' checkbox if you would like the Role
to be mandatory;
6. Within the 'Joins' groupbox, do the following:
Select either 'Entity Type', 'Value Type', 'Nested Fact Type' to
select the Object Type that you would like the new Role to join to.
7. Select the Object Type, within the dropdown list, that you would
like the Role to join to.
8. Click on [Ok] to create the Fact Type and Role;
9. A new Fact Type with the attributes you have chosen will be
created within the Model and Page, and joined to the Object
Type that you selected.
Extending a Fact Type by adding a
Role
Top Previous
Next
The following steps outline how to extend a Fact Type by adding a
Role.
NB The quickest and easiest way to extend a Fact Type by adding a
Role is to use the keyboard. To use the Toolbox, follow the steps in
this help topic: Using the Toolbox to extend a Fact Type by adding a
Role
Using the keyboard to extend a Fact Type by
adding a Role By far the easiest way to extend a Fact Type
by adding a Role, is to use the keyboard.
The following steps outline how to extend a Fact Type by adding a
Role:
1. Select the last Role in the Fact Type
2. Select the Object Type that you would like the new Role within
the Fact Type to join to;
3. Press the [R] button on your keyboard.
The new Role will be added to the Fact Type and joined to the
Object Type that you have selected.
Using the Toolbox to extend a Fact
Type by adding a Role
Top
Previous
Next
The following steps outline how to use the Toolbox to extend a Fact
Type by adding a Role:
1. Make sure the Toolbox is open within the Boston workbench;
2. Drag the 'Role' icon from within the Toolbox to the last Role
within the Fact Type that you would like to extend;
The Role will appear with a brown outline when you have
dragged over the Role.
3. Release the left mouse button.
You will be presented with the 'New Role' dialog box.
4. Enter the desired name of the Fact Type, if you would like to
change the name of the Fact Type;
5. Enter the name of the Role (if you would like the Role to have a
name);
6. Check the 'Mandatory Role' checkbox if you would like the Role
to be mandatory;
7. Within the 'Joins' groupbox, do the following:
Select either 'Entity Type', 'Value Type', 'Nested Fact Type' to
select the Object Type that you would like the new Role to join to.
8. Select the Object Type, within the dropdown list, that you would
like the Role to join to.
9. Click on [Ok] to create the Fact Type and Role;
10. A new Role will be added to the Fact Type that you have just
extended, and that Role joined to the Object Type that you
selected.
Adding an Internal Uniqueness
Constraint to a Fact Type
Top
Previous
Next
The following steps outline how to add an Internal Uniqueness
Constraint to a Fact Type.
1. Select the Roles that the Internal Uniqueness Constraint will
span;
NB Shortcut - At this step, press the [U] button on your keyboard
and the Internal Uniqueness Constraint will be created.
2. Right-click on a selected Role.
You will be presented with the Role context menu.
3. Select the [Add Uniqueness Constraint] menu option.
The Internal Uniqueness Constraint will be added to the Fact
Type.
Internal Uniqueness Constraints
spanning multiple Roles
Top
Previous
Next
The following steps outline how to add an Internal Uniqueness
Constraint to a Fact Type.
1. Select the Roles that the Internal Uniqueness Constraint will
span;
2. Right-click on a selected Role.
You will be presented with the Role context menu.
3. Select the [Add Uniqueness Constraint] menu option.
The Internal Uniqueness Constraint will be added to the Fact
Type.
Viewing the Fact Table of a Fact Type Top Previous Next
The following steps outline how to display the Fact Table for a Fact Type.
1. Select the Fact Type for which you would like to view the Fact Table;
2. Right-click on the selected Fact Type.
You will be presented with the Fact Type context menu.
3. Select the [View Fact Table] menu option.
The Fact Table for the Fact Type will be displayed below the Fact
Type:
Adding Sample Populations / Facts
to a Fact Type
Top Previous
Next
The following steps outline how to add a Sample Population to a
Fact Type.
1. Make sure the Fact Table is visible for the Fact Type
2. Right-click on the Fact Table.
You will be presented with the Fact Table context menu:
3. Select the [Add Row/Fact] menu option.
A new Sample Population / Fact will be added to the Fact Type.
4. Click on the individual Sample Population Data items to edit their
value.
5. Press [Enter] when you have finished editing a Sample
Population Data item.
The Fact Table now shows the Sample Population for the Fact
Type.
Objectifying a Fact Type Top Previous Next
The following steps outline how to objectify a Fact Type:
NB Fact Types may only be objectified if they have a Total Internal
Uniqueness Constraint or an Internal Uniqueness Constraint that
spans one less Role than the total number of Roles within the Fact
Type.
NB If the Fact Type has no extant Internal Uniqueness Constraint
when you objectify the Fact Type, a Total Internal Uniqueness
Constraint will be created automatically for the Fact Type.
1. Select (left-click) the Fact Type that you would like to objectify
within the Page that you are working with, within the Boston
workbench;
2. Right-Click on the Fact Type.
You will be presented with the Fact Type context menu.
3. Select the option, [Is Objectified]
4. The Fact Type will be objectified.
NB Once a Fact Type is objectified, Roles from other Fact Types
may join to that Objectified Fact Type.
An Objectified Fact Type with a joining Role from another Fact Type
Managing Role Constraint
Properties
Top Previous
Next
The following steps outline how to view the properties of a Role
Constraint:
1. Make sure a Page containing an ORM Diagram containing a
Role Constraint is open within the Boston workbench;
2. Make sure the Properties Toolbox is open within the Boston
workbench;
3. Left-click on the Role Constraint.
The Properties Toolbox will show the properties of the Role
Constraint.
Role Constraint Properties
The following table outlines the properties of a Role Constraint and
the data that should be entered for each property:
Property Description and Data
Requirements
Name The name of the Role Constraint.
Enter a name that is unique
amongst all Role Constraints, Entity
Types, Fact Types and Role
Constraints.
RoleConstraintType Displays the type of the
Role Constraint. This value
cannot be changed.
RingConstraintType Displays the type of Ring
Constraint if the Role
Constraint is a Ring
Constraint (i.e. if the Role
Constraint has a
RoleConstraintType of,
'RingConstraint').
You can change this value to
the type of Ring Constraint
that you would like the
selected Role Constraint to
be.
NB RingConstraintType is
not shown in the picture
above.
IsDeontic Setting this property to True will
make the Role Constraint a
deontic Role Constraint.
A value of False in this property
means that the Role Constraint is
alethic.
NB All Role Constraints are alethic
when first created.
ShortDescription A short description of the Role
Constraint.
LongDescription A long description of the Role
Constraint.
Managing Internal Uniqueness
Constraints
Top Previous
Next
Internal Uniqueness Constraints constrain the uniqueness of data
values for a Fact Type.
Internal Uniqueness Constraints can be added and removed from
Fact Types, but not edited.
The following help topics outline how to add and remove Internal
Uniqueness Constraints to/from a Fact Type:
Adding an Internal Uniqueness Constraint to a Fact Type
Removing an Internal Uniqueness Constraint
Removing an Internal Uniqueness
Constraint
Top Previous
Next
The steps below outline how to remove an Internal Uniqueness
Constraint from a Page and Model.
NB You cannot remove an Internal Uniqueness Constraint from a
Page without removing the Internal Uniqueness Constraint from the
underlying Model.
1. Select the Internal Uniqueness Constraint by left-clicking on the
constraint;
2. Right-click on the Internal Uniqueness Constraint once it has
been selected;
You will be presented with the Internal Uniqueness Constraint
context menu.
3. Select the [Remove from Page & Model] menu option from the
Internal Uniqueness Constraint context menu.
The Internal Uniqueness Constraint will be removed from the
Page and Model.
Assigning Roles to a Ring
Constraint
Top Previous
Next
The following steps outline how to assign Roles to a Ring
Constraint.
1. Make sure that the Page that you are editing has at least one
Fact Types within the Page;
2. Add a new Ring Constraint to the Page by dragging the Ring
Constraint icon from the Toolbox;
3. From just inside the border of the Ring Constraint, drag a link to
one of the Roles of the first Fact Type;
4. From just inside the border of the Ring Constraint, drag a link to
the other Role of the same Fact Type;
The Ring Constraint is complete with Role allocation.
Assigning Roles to an External
Uniqueness Constraint
Top
Previous
Next
The following steps outline how to assign Roles to an External
Uniqueness Constraint.
Steps to assign Roles to an External Uniqueness
Constraint
1. Make sure that the Page that you are editing has at least two
Fact Types within the Page;
2. Add a new External Uniqueness Constraint to the Page by
dragging the External Uniqueness Constraint icon from the
Toolbox;
3. From just inside the border of the External Uniqueness
Constraint, drag a link to the first Role in the set;
4. For each other Role that you would like to include in the set:
- From just inside the border of the External Uniqueness
Constraint, drag a link to that Role.
NB An External Uniqueness Constraint must span at least 2 Roles.
Assigning Roles to an Equality
Constraint
Top Previous
Next
The following steps outline how to assign Roles to an Equality
Constraint.
NB Equality Constraints can only be assigned to a set of Roles that
are compatible and where compatible means the following for an
Equality Constraint: - All Roles in the set are hosted by the same
Object Type or Supertypes/Subtypes of that Object Type
Steps to assign Roles to an Equality Constraint
1. Make sure that the Page that you are editing has at least two
Fact Types within the Page;
2. Add a new Equality Constraint to the Page by dragging the
Equality Constraint icon from the Toolbox;
3. From just inside the border of the Equality Constraint, drag a link
to the first Role in the set;
4. For each other Role that you would like to include in the set:
- From just inside the border of the Equality Constraint, drag a
link to that Role.
NB An Equality Constraint must span at least 2 Roles.
Assigning Roles to an Exclusion
Constraint
Top Previous
Next
The following steps outline how to assign Roles to an Exclusion
Constraint.
NB Exclusion Constraints can only be assigned to a set of Roles
are that compatible and where compatible means the following for
an Exclusion Constraint: - All Roles in the set are hosted by the
same Object Type or Supertypes/Subtypes of that Object Type
Steps to assign Roles to an Exclusion Constraint
1. Make sure that the Page that you are editing has at least two
Fact Types within the Page;
2. Add a new Exclusion Constraint to the Page by dragging the
Exclusion Constraint icon from the Toolbox;
3. From just inside the border of the Exclusion Constraint, drag a
link to the first Role in the set;
4. For each other Role that you would like to include in the set:
- From just inside the border of the Exclusion Constraint, drag a
link to that Role.
NB An Exclusion Constraint must span at least 2 Roles.
Assigning Roles to an Inclusive-OR
Constraint
Top Previous
Next
The following steps outline how to assign Roles to an Inclusive-OR
Constraint.
NB Inclusive-OR Constraints can only be assigned to a set of Roles
that are compatible and where compatible means the following for
an Inclusive-OR Constraint: - All Roles in the set are hosted by the
same Object Type or Supertypes/Subtypes of that Object Type
Steps to assign Roles to an Inclusive-OR Constraint
1. Make sure that the Page that you are editing has at least two
Fact Types within the Page;
2. Add a new Inclusive-OR Constraint to the Page by dragging the
Inclusive-OR Constraint icon from the Toolbox;
3. From just inside the border of the Inclusive-OR Constraint, drag
a link to the first Role in the set;
4. For each other Role that you would like to include in the set:
- From just inside the border of the Inclusive-OR Constraint, drag
a link to that Role.
NB An Inclusive-OR Constraint must span at least 2 Roles.
Assigning Roles to an Exclusive-OR
Constraint
Top Previous
Next
The following steps outline how to assign Roles to an Exclusive-OR
Constraint.
NB Exclusive-OR Constraints can only be assigned to a set of
Roles that are compatible and where compatible means the
following for an Exclusive-OR Constraint: - All Roles in the set are
hosted by the same Object Type or Supertypes/Subtypes of that
Object Type
Steps to assign Roles to an Exclusive-OR Constraint
1. Make sure that the Page that you are editing has at least two
Fact Types within the Page;
2. Add a new Exclusive-OR Constraint to the Page by dragging the
Exclusive-OR Constraint icon from the Toolbox;
3. From just inside the border of the Exclusive-OR Constraint, drag
a link to the first Role in the set;
4. For each other Role that you would like to include in the set:
- From just inside the border of the Exclusive-OR Constraint,
drag a link to that Role.
NB An Exclusive-OR Constraint must span at least 2 Roles.
Assigning Roles to a Subset
Constraint
Top Previous
Next
The following steps outline how to assign Roles to an Subset
Constraint.
NB Subset Constraints can only be assigned to sets of Roles that
are compatible and where compatible means the following for an
Subset Constraint: - The Roles in each set of two Role are hosted
by the same Object Type or Supertypes/Subtypes of that Object
Type.
- Each set of two Roles is where the value members of the first
element are a subset of the values of the second element.
Steps to assign Roles to an Subset Constraint
1. Make sure that the Page that you are editing has at least two
Fact Types within the Page;
2. Add a new Subset Constraint to the Page by dragging the
Subset Constraint icon from the Toolbox;
3. From just inside the border of the Subset Constraint, drag a link
to the first Role in the first set;
a) For every other Role of the argument, drag a link to that Role;
NB Click on the canvas to start a new argument (i.e. e.g. create the
superset);
4. From just inside the border of the Subset Constraint, drag a link
to the Role that provides the superset of Values;
a) Make sure you have clicked on the canvas before starting the
superset set of Roles.
5. Repeat steps 3 (above) and 4 (above) for each other
Subset/Superset set within the Subset Constraint.
NB An Subset Constraint must span at least 2 Roles.
2. MaximumFrequencyCount
Extra Properties on a Frequency Constraint
Together, the value of these properties manage a Frequency Constraint's range.
The following table outlines how the value of the properties MinimumFrequencyCount
and MaximumFrequencyCount affect the appearance of a Frequency Constraint within
an ORM Diagram and the interpretted meaning of the Frequency Constraint.
Relative values of
MinimumFrequencyCount
and
MaximumFreqencyCount
Outcome Appearance on an ORM
Diagram
MinimumFrequencyCount =
0
MaximumFrequencyCount
> 0
Sets the Frequency
Constraint to a 'Less than
or equal to' Frequency
Constraint
MinimumFrequencyCount <
MaximumFrequencyCount
Sets a range from the
MinimumFrequencyCount
to the
MaximumFrequencyCount
for the Frequency
Constraint
MinimumFrequencyCount =
MaximumFrequencyCount
Sets a discrete value for
the Frequency Constraint
MinimumFrequencyCount >
0
MaximumFrequencyCount
= 0
Sets the Frequency
Constraint to a 'Greater
than or equal to'
Frequency Constraint
Managing Model Notes Top Previous Next
Model Notes are relatively simple to maintain.
Changing the Text of a Model Note
To change the text of a Model Note, double-click on the Model Note,
modify the text of the Model Note and then press [Enter] on your
keyboard.
Reassigning the Model Element that the
Model Note is associated with
To reassign the Model Element that a Model Note is associated
with, drag a model note connection from the Model Note to the
desired Model Element.
Managing Subtype Relationships Top Previous Next
The help topics in this chapter outline how to manage Subtype
Relationships.
Subtype Relationships in ORM are defined by drawing a directed
arrow from the Object Type that is the Subtype of another Object
Type, to the Object Type that is the Supertype.
In the ORM Model below, both Student and Teacher are Subtypes
of the Object Type, 'Person'.
Subtype Relationships
Adding a Subtype Relationship to a
Model and Page
Top Previous
Next
The following steps outline how to add a Subtype Relationship to a
Model and Page.
NB Subtype Relationships between Object Types always appear on
a Page if the following conditions are met: a) The Subtype
Relationship has been established between the Subtype and its
Supertype; b) Both the Subtype Object Type and the Supertype
Object Type are displayed on the Page.
Steps to add a Subtype Relationship between a Subtype Object
Type and its Supertype Object Type:
1. Select the Subtype Object Type;
2. Select the Supertype Object Type;
3. Press the [S] button on your keyboard.
The Subtype Relationship will be created in the Model and
displayed on the Page.
Using the Toolbox to create a
Subtype Relationship
Top Previous
Next
The following steps outline how to create a Subtype Relationship
using the Toolbox:
NB The fastest way to create a Subtype Relationship is by using the
keyboard (See help topic, Adding a Subtype Relationship to a
Model and Page)
1. Make sure the Toolbox is open within the Boston workbench;
2. Drag the 'Subtype Connector' icon from the Toolbox over the
Page's canvas;
3. Release the left mouse button;
4. Perform a drag operation, originating at the Subtype Object Type
to the Supertype Object Type;
5. The Subtype Relationship will be created between the Subtype
Object Type and the Supertype Object Type;
The Properties Toolbox Top Previous Next
The Properties Toolbox allows you to view and edit the Properties of
a Model Element directly. Model Elements within an ORM Model
often have properties which are not directly visible on an ORM
Diagram and which can only be edited within the Properties Toolbox
(e.g. The Data Type of a Value Type).
To quickly open the Properties Toolbox within the Boston
workbench, either:
1. Right-click on an open area of the canvas of a Page open for
editing within the Boston workbench, and select the [Vie]->
[Properties] menu option; or
2. Press the [P] button on your keyboard when working with a Page
is open for editing within the Boston workbench.
The picture below is of the Properties Toolbox:
The Properties Toolbox
Opening the Properties Toolbox Top Previous Next
There are three ways to open the Properties Toolbox:
1. Using the Diagram context menu to open the Properties Toolbox
2. Using a Shortcut Key combination to open the Properties
Toolbox
3. Right-clicking on a Model Element, and selecting the [Properties]
menu option
4. Using the [View]->[Toolboxes]->[Properties] menu option within
the main Boston menu
Using the Diagram context menu to open the Properties
Toolbox
1. Make sure a Page is open for editing within the Boston
workbench;
2. Left-click on a blank area of the canvas of the Page;
3. Right-click on the blank area of the canvas of a Page to open the
Diagram context menu;
4. Select the [View]->[Properties] menu option.
The Properties Toolbox will be displayed on the right hand side of
the Boston workbench.
Using a Shortcut Key combination to open the
Properties Toolbox
1. Make sure a Page is open for editing within the Boston
workbench;
2. Left-click on a blank area of the canvas of the Page (to make
sure the Page has the focus within the Boston workbench).
NB You can ignore this step if the Page already has the focus
within the Boston workbench.
3. Press the [P] button on your keyboard.
Right-clicking on a Model Element, and selecting the
[Properties] menu option
1. Make sure a Page with an ORM Diagram is open for editing
within the Boston workbench;
2. Left-click on the Model Element that you would like to see the
properties of;
3. Right-click to open the context menu for the Model Element;
4. Select the [Properties] menu option.
The Properties Toolbox will be displayed on the right hand side of
the Boston workbench.
Using the [View]->[Toolboxes]->[Properties] menu
option within the main Boston menu
1. From within the main Boston menu, select the [View]->
[Toolboxes]->[Properties] menu option.
The Properties Toolbox will be displayed on the right hand side of
the Boston workbench.
The Model Dictionary Top Previous Next
The Model Dictionary Toolbox allows you to:
1. View the lists of Model Elements within a Model by their type
(e.g. Entity Type, Value Type, Fact Type or Role Constraint).
2. Add a Model Element to a Page open for editing within the
Boston workbench, by dragging the Model Element onto the
canvas of the Page.
See also: Adding a Model Element to one Model from another
Model
To open the Model Dictionary Toolbox, follow the following steps:
1. Make sure a Page is open for editing within the Boston
workbench;
2. Right-click on a blank area of the canvas of the Page, and select
the [View]->[Model Dictionary] option within the context menu
that is offered to you.
Or...
1. Select the [View]->[Toolboxes]->[Model Dictionary] menu option
from within the set of menus at the top of the Boston workbench.
The following picture if of the Model Dictionary Toolbox:
The Model Dictionary Toolbox
Adding a Model Element to one Model
from another Model
Top
Previous
Next
The following steps outline how to add a Model Element from one
Model from another Model using the Model Dictionary.
1. Make sure the Model Explorer is open within the Boston
workbench;
2. Make sure a Page of the source Model is open within the Boston
workbench;
3. Make sure the Model Dictionary is open within the Boston
workbench;
4. From within the Model Explorer open a Page of the target Model
(or click on an open Page of that Model within the workbench);
5. Navigate to the open Page of the source Model, so that it is the
presenting Page within the Boston workbench;
6. Within the Model Dictionary, navigate to the Model Element that
you wish to copy to the target Model;
7. Drag that Model Element from the Model Dictionary to the Tab
representing the Page of the target Model;
The Page of the target Model will now appear as the presenting
Page within the Boston workbench.
8. Drop the Model Element on the Page of the target Model;
The Model Element will appear on the Page and is effectively
'copied' to the target Model.
The Error List Top Previous Next
The Error List Workbox provides an automatically updated list of the
errors within the Model currently being worked on within the
Workbench.
NB This version of Boston provides very few errors. Please consult
an appropriate ORM reference for validation of your model. Please
also contact FactEngine support with recommendations for model
errors.
The Error List Toolbox Opening the Error List Toolbox
The following steps outline how to open the Error List Toolbox:
1. Make sure you have a Page open for editing within the Boston
workbench;
2. Right-click on an empty area of the canvas of the Page.
You will be presented with the Diagram context menu.
3. Select the [View]->[Error List] menu option.
The Error List Toolbox will appear at the bottom of the Boston
workbench.
Working with Model Errors within the Error
List Toolbox The following steps outline how to get help on a
particular Model Error: 1. Right-click on the Model Error;
The Model Error [Help] context menu will open (as pictured below);
2. Click on [Help].
The Boston Help Manual will open at a topic specifically related to
the Model Error in question.
3. Follow the instructions within the Help Manual to resolve the
Model Error.
Population Uniqueness Error
An Internal Uniqueness Constraint ranging over one or more Roles
within a Fact Type has been violated by at least one Fact within a
Data Population within the Fact Table of that Fact Type.
The Internal Uniqueness Constraint in question is listed within the
Error.
Error Resolution
To resolve this error, perform one of the following:
1. Modify the Internal Uniqueness Constraint to better suit the type
of data that will be captured for the Fact Type; OR
2. Remove the violating Data Population from the Fact Table of the
Fact Type associated with the Internal Uniqueness Constraint.
Example
The following ORM Diagram shows a Data Population for a Fact
Type where the Internal Uniqueness Constraint ranging over the
Fact Type is violated.
i.e. The Internal Uniqueness Constraint necessitates that each
instance of Person in the Fact Type, "Person drives Car", is unique.
There are two Facts with a Person instance of "Peter", and so the
Internal Uniqueness Constraint is violated.
Example
The following ORM Diagram shows a Fact Type without an Internal
Uniqueness Constraint.
Error Resolution
To resolve this error do one of the following: 1. Add or Remove
Facts within the Fact Table (Data Population) of the Fact Type
associated with the Frequency Constraint; OR
2. Modify the Minimum and/or Maximum value counts of the
Frequency Constraint as required.
Example
The following ORM Diagram shows a "Frequency Constraint
Min/Max Error" (as indicated by the red Frequency Constraint)
where the Frequency Constraint allows no more than 2 instances of
a value of Person within the Fact Type, "Person drives
VehicleType", but where there are 3 instance of the same Person
("Peter") within the Sample Population for the Fact Type.
Example
The following ORM Diagrams show a Fact Type without a Fact Type
Reading, and the same Fact Type with at least one Fact Type
Reading:
Fact Type without a Fact Type Reading
Fact Type with at least one Fact Type Reading
Ring Constraints
Each Ring Constraint must have two different Roles of the same
Fact Type associated (linked to) the constraint, and where that Fact
Type has two Roles played by the same Object Type.
If the Model Error is for a Ring Constraint, then that Ring Constraint
has zero or one Role linked to the Ring Constraint.
Other External Role Constraints Every External Role
Constraint must have at least one associated Role.
Error Resolution
To resolve this error do the following:
1. Make sure that the Role Constraint associated with the Model
Error has the appropriate number of associated Roles for the Role
Constraint and that each Role Constraint Argument of the Role
Constraint has the required number of associated Roles.
See the chapter: Managing Ring Constraints
Example
The following ORM Diagram shows a Ring Constraint with only one
associated Role, and where 2 associated Roles is the required
number of associated Roles for a Ring Constraint.
Example
The following ORM Diagram shows an Equality Constraint that has
a conflicting Exclusion Constraint:
The Fact Type Reading Editor Top Previous Next
The Fact Type Reading Editor allows you to create, edit and delete
Fact Type Readings for Fact Types within the Model currently being
worked on within the Workbench.
The Fact Type Reading Editor
Adding Fact Type Readings to a Fact Type
Editing existing Fact Type Readings
Deleting a Fact Type Reading
Adding Fact Type Readings to a Fact
Type
Top Previous
Next
The following steps outline how to add a Fact Type Reading to a Fact
Type.
1. Make sure the Fact Type Reading Editor is open within the Boston
workbench;
2. Select the Fact Type to which you would like to add a Fact Type
Reading, within the Page;
The name of the Fact Type will appear at the top of the Fact Type
Reading Editor.
3. Type the Fact Type Reading in the textbox at the top of the Fact Type
Reading Editor
4. Press [Enter];
The Fact Type Reading for the Fact Type will be added to the list of
Fact Type Readings for the Fact Type within the grid at the base of the
Fact Type Reading Editor.
Editing existing Fact Type Readings Top Previous Next
The following steps outline how to edit an existing Fact Type Reading for
a Fact Type:
1. Make sure the Fact Type Reading Editor is open within the Boston
workbench;
2. Select a Fact Type with at least one Fact Type Reading, within a Page
open for editing;
The Fact Type Readings for the Fact Type will be displayed within the
grid at the base of the Fact Type Reading form.
3. Click on the Fact Type Reading that you would like to edit, within the
grid at the base of the Fact Type Reading editor.
The Fact Type Reading will become editable.
4. Modify the part of the predicate that you would like to change, and
then press the [Enter] key on your keyboard.
The Fact Type Reading will be changed to the new reading.
Deleting a Fact Type Reading Top Previous Next
The following steps outline how to delete (or 'remove') a Fact Type
Reading from the list of Fact Type Readings for a Fact Type.
1. Make sure the Fact Type Reading editor is open within the Boston
workbench;
2. Select the Fact Type with the Fact Type Reading that you would like to
delete/remove;
3. Select the Fact Type Reading within the grid at the base of the Fact
Type Reading editor (click on the leftmost part of the row within the
grid);
The row within the grid will be highlighted blue, including the leftmost
column.
4. Press the [Delete] key on your keyboard;
The Fact Type Reading will be deleted from the set of Fact Type
Readings for the Fact Type.
The ORM Verbalisation View Top Previous Next
The ORM Verbalisation view shows the verbalisation of a Model
Element in natural language.
The view the verbalisation of a Model Element, follow the steps
below:
1. Make sure the ORM Verbalisation view is open within the Boston
workbench;
2. Left-click on the Model Element that you would like to see the
verbalisation for.
The ORM Verbalisation view will display the verbalisation of the
Model Element that you have selected.
Opening the ORM Verbalisation
View
Top Previous
Next
The following steps outline how to open the ORM Verbalisation
View:
1. Make sure you have a Page open for editing within the Boston
workbench;
2. Right-click on an empty area of the canvas of the Page.
You will be presented with the Diagram context menu.
3. Select the [View]->[ORM Verbalisation View] menu option.
The Error List Toolbox will appear at the bottom of the Boston
workbench.
The Virtual Analyst Top Previous Next
Boston's Virtual Analyst (VA) is designed to make it easier to create
initial ORM Models. The Virtual Analyst analyses Facts and asks
you to confirm its analysis of each Fact it receives. Transactions
with the Virtual Analyst take the form of a "Chat Session", with you
submitting Facts for analysis and answering the questions raised by
the VA after analysing the sentence you have provided.
On analysing a Fact, the Virtual Analyst will ask questions as to
whether you would like the Virtual Analyst to create the Entity
Types, Fact Types and Subset Constraints it has identified.
NB A Model and Page must be open within the Boston workbench
for the Virtual Analyst to work with.
The picture below is a typical conversation with the Virtual Analyst.
Working with the Virtual Analyst
Creating Entity Types and Fact Types
using the Virtual Analyst
Top
Previous
Next
You can create Entity Types and Fact Types by using the Virtual
Analyst by simply typing Facts (or 'predicated') into the chat session
with the Virtual Analyst.
Or, you can use shortcuts to create Entity Types.
Examples statements are:
Person has ONE first-Name - The Virtual Analyst will ask you if you
want to create a 'Person' Entity Type
Person IS IDENTIFIED BY ITS Id - The Virtual Analyst will create a
'Person' Entity Type with '.Id' as its Reference Mode.
Person IS IDENTIFIED BY ITS Id WRITTEN AS AutoCounter - The
Virtual Analyst will create a 'Person' Entity Type with '.Id' as its
Reference Mode, and the associated Value Type for the Reference
Scheme with a data type of AutoCounter.
Creating Fact Types
The steps below outline how to create Entity Types and Fact Types by using the Virtual Analyst.
1. Make sure the Virtual Analyst is open within the Boston workbench;
2. Make sure that a Page is open for editing within the Boston workbench;
3. Within the Virtual Analyst, type the Fact Type's Predicate into the chat-session textbox (click to the righ
'NL:').
E.g. "Student has Enrollment" is an example Predicate.
NB 'NL' stands for 'Natural Language'.
Press the [Enter] key on your keyboard when you have completed writing the Fact Type's Predicate.
================================================================================
Hint: Use ONE and AT MOST ONE to determine the cardinality of a binary fact type/relationship.
E.g. You can say:
"Student has ONE Enrollment" (I.e. Each Student must have an Enrollment)
or
"Student has AT MOST ONE Enrollment" (I.e. It is optional whether a Student has an Enrollment)
================================================================================
The Virtual Analyst will ask you if you would like to create Entity Types for those that it identifies within the
4. Answer 'yes' to those Entity Types that the Virtual Analyst correctly identifies.
NB After the Virtual Analyst has completed analysing the Entity Types, the Virtual Analyst will ask you
to create a Fact Type for the the Fact/Predicate entered.
5. Answer 'yes' to the creation of the Fact Type.
The Entity Types and the Fact Type will automatically be added to the Page open for editing within the
workbench.
Fact Types using the IS WHERE
clause
Top Previous
Next
IS WHERE clauses are used to create Fact Types.
E.g. "PersonHasFirstName IS WHERE Person has first-Name, first-
Name is for Person".
NB Successive FactTypeProductions are used for reverse/alternate
Fact Type Readings. For instance the Fact Type Reading, "Person
has first-Name" has the reverse Fact Type Reading, "first-Name is
for Person".
Creating Subtype Relationships using
the Virtual Analyst
Top Previous
Next
The following steps outline how to create a Subtype Relationship using
the Virtual Analyst.
1. Make sure the Virtual Analyst is open within the Boston workbench;
2. Make sure that a Page is open for editing within the Boston
workbench;
3. Within the chat-session textbox, type in the Subtype Relationship that
you would like to create using the following syntax:
<Subtype> is a <Supertype>
Press the [Enter] key on your keyboard after you have finished writing
the predicate.
The Virtual Analyst will ask you to confirm the creation of any Entity
Types that are required to be created to create the Subtype
Relationship;
The Virtual Analyst will ask you to confirm the creation of the Subtype
Relationship.
4. Answer 'yes' to create the required Entity Types;
5. Answer 'yes' to create the Subtype Relationship.
The virtual analyst will automatically update the Page with the new
Entity Types and Subtype Relationship.
Using FEKL (FactEngine Knowledge
Language)
Top Previous
Next
The Virtual Analyst includes a Controlled Natural Language (CNL)
that called FEKL (FactEngine Knowledge Language). FEKL is a
derivative of Data Constellation's open-source CQL (Constellation
Query Language) (http://www.dataconstellation.com) available
through their Active Facts project
(https://github.com/cjheath/activefacts).
CQL is designed so that analysts can create, edit and publish
models in a CNL. FactEngine's FEKL derives from this language,
using ALLCAPS for reserved words within the language.
A brief example as introduction to FEKL will frame the nature and
intent of the language:
The FEKL statement above defines a Value Type called
"FirstName", with a Data Type of 'String Fixed Length', with the
maximum length of instances of that Value Type being 100
characters long.
"FirstName IS WRITTEN AS StringFixedLength(100)"
While the benefits of defining a Value Type using natural language
may not be immediately apparent, it is the functionality of the Virtual
Analyst toolbox which brings about the unseen benefits.
Using Auto-Completion, Boston's VA augments rapid model
definition by displaying the list of options available to complete a
FEKL sentence. The Auto-Completion list is displayed under the
sentence that you are typing. This allows you to quickly and
efficiently complete the sentence. An example of the Auto-
Completion functionality is displayed below:
Auto-Completion in Boston
The result of entering the verifiable FEKL statement (above) is
either creation of a new Value Type, or modifying of an existing
Value Type within the model.
We estimate that using the VA and FEKL is 2 to 3 times faster than
using the standard drag-and-drop features to modify a model within
Boston.
Creation of new Value Types, or editing the Data Type of an existing
Value Type is a simple example. A more complex example, model-
wise, but just as easy to type into the VA, is that of creating a new
Fact Type with accompanying Entity Type and Value Type all within
one sentence: "Person has ONE FirstName"
This simple sentence exemplifies the speed and grace by which
models can be edited using the VA. Typing "Person has ONE
FirstName" into the VA will set the VA in motion to create an Entity
Type for 'Person' (if the 'Person' Entity Type doesn't already exist
within the model), a Value Type for 'FirstName', a Fact Type with a
reading of 'Person has FirstName', a mandatory constraint and a
uniqueness constraint...all defined within that simple sentence. The
resulting ORM model fragment that is created within Boston is
shown below:
A model fragment created using FEKL
The Value Type, "FirstName", is coloured red because in this
example the Data Type of the Value Type has not been set. Using
the first FEKL statement first listed above ("FirstName IS WRITTEN
AS StringFixedLength(100)") we can quickly and easily define the
Data Type and Data Type Length of the Value Type.
Using the Auto-Complete Tool Top Previous Next
When typing FEKL sentences into the Virtual Analyst toolbox the
Auto-Complete tool/list will periodically appear under the last
character you have typed.
The Auto-Complete tool is designed to significantly accelerate the
process of typing FEKL sentences, and provides a list of the next
words (or 'tokens') to complete the sentence.
In the example below, the Auto-Complete tool shows a list of Data
Types that are valid, to complete the "IS WRITTEN AS" sentence.
A list of valid Data Types displayed in the Auto-Complete Tool The following
help topics outline how to use the Auto-Complete tool, and include:
Accessing the Auto-Complete Tool
Selecting a token in the Auto-Complete Tool
Accessing the Auto-Complete Tool Top Previous Next
The following steps outline how to access the Auto-Complete tool:
NB As you type a FEKL statement the Auto-Complete tool will
automatically appear where required. Sometime the Auto-Complete
tool will be semi-transparent so that you can read sentences already
typed into the Virtual Analyst Toolbox.
The Auto-Complete Tool automatically appearing where required
To access the Auto-Complete Tool, follow the following steps:
1. Press the [v] (down arrow) key on your keyboard
The focus of the Virtual Analyst Toolbox will be transferred to the
Auto-Complete Tool so that you can select a token within the
tool.
2. Use the [^] (up arrow) and [v] (down arrow) keys on your
keyboard to navigate within the set of tokens offered within the
Auto-Complete tool.
3. Once you have located and focused the token that you would
like to include in your FEKL statement, press the [Space] bar on
your keyboard to make your selection and append the token to
the FEKL statement.
Selecting a token in the Auto-
Complete Tool
Top Previous
Next
The following steps outline how to select a token within the Auto-
Complete Tool:
1. Press the [Space] bar on your keyboard
2. The token that you have selected will be appended to the FEKL
statement that you are typing.
NB The Auto-Complete Tool may show further tokens that are
required to complete the FEKL Statement (as above).
Validating a FEKL Statement Top Previous Next
The Virtual Analyst is designed to make the process of entering the
details of a model into Boston as easy as possible. The process of
validating a FEKL statement is automated by colour-coding the
FEKL statement that you have typed into the Virtual Analyst Toolbox
once the FEKL statement is complete and has automatically been
validated by the Virtual Analyst.
The following step/s outline how to initiate the automatic validation
of a FEKL statement:
1. Press the [Space] bar on your keyboard once you have
completed typing in a FEKL statement.
The Virtual Analyst will automatically validate the FEKL
statement and colour-code the FEKL Statement to signify that
the statement is valid.
For example, the following is a valid FEKL statement. Note that the
statement has been colour-coded to signify that the statement is
valid.
Colour-Coding of a valid FEKL Statement
IS WHERE Clause Top Previous Next
IS WHERE clauses are used to create Fact Types.
E.g. "PersonHasFirstName IS WHERE Person has first-Name, first-
Name is for Person".
NB Successive FactTypeProductions are used for reverse/alternate
Fact Type Readings. For instance the Fact Type Reading, "Person
has first-Name" has the reverse Fact Type Reading, "first-Name is
for Person".
Text-to-Speech Top Previous Next
There are multiple ways to turn Text-to-Speech on and off for the
Virtual Analyst.
Turning Text-to-Speech On
The easiest way to turn on Text-to-Speech for the Virtual Analyst is
to type any of the following commands into the Virtual Analyst
Toolbox:
"quietmodeoff"
"speak to me"
Turning Text-to-Speech Off
The easiest way to turn off Text-to-Speech for the Virtual Analyst is
to type any of the following commands into the Virtual Analyst
Toolbox:
"quietmodeon"
"shoosh"
"be quiet"
Displaying Briana
The easiest way to display Briana is to type the following command
into the Virtual Analyst Toolbox: "show Briana"
Hiding Briana
The easiest way to hide Briana is to type the following command
into the Virtual Analyst Toolbox: "hide Briana"
Languages Top Previous Next
Boston lets you view models in different languages, e.g. Entity
Relationship Diagrams and Property Graph Schemas. Each
language view of the model is within a Page within the model.
Boston currently supports the following languages:
1. Object-Role Models;
2. Entity Relationship Diagrams; 3. Property Graph Schemas;
4. State Transition Diagrams;
Unified Modelling
The different language views, as Pages, are unified within Boston
and changing the name or properties of a model element within one
language automatically changes the relevant model element in the
related language.
NB The primary language in Boston is Object-Role Modeling. As
Object-Role Modeling is more semantically verbose than most other
conceptual modelling languages using ORM as the backbone for
management of the model elements in those other languages
makes sense. For instance, it is not always possible to make
changes in an Entity Relationship Diagram and have those changes
reflected within the corresponding ORM diagram as there is not
enough information within the Entity Relationship Diagram to map
back to the corresponding ORM diagram. However, any change
within an ORM diagram can be reflected in its corresponding Entity
Relationship Diagram.
Model Conversion Top Previous Next
Object-Role Models can be converted to Entity Relationship Diagrams and Property Graph Schemas. To
convert an ORM model in Boston, you must right-click on the page of the model that you want converted
select the [Convert Page >] menu item.
For example, to convert an ORM diagram page to an Entity Relationship Diagram page, right-click on the
canvas of the ORM diagram page and select [Convert Page]->[To Language]->[Entity Relationship Diagra
as below.
NB A new page of type, Entity Relationship Diagram, will be added to the set of pages in the model within
the Model Explorer. Open the new Entity Relationship Diagram page for editing the same way that you op
any page in Boston.
Converting an ORM diagram to an Entity Relationship Diagram
Morphing between languages Top Previous Next
To dynamically morph from one language to another, select and right-click on the model element that you
morph to another language and then select the language to which you want to morph the diagram to, as b
NB To morph a model element from one language to another language the chosen model element needs
a page of the second language that is already within the model.
Initiating morphing in Boston
Add Page of Language ... Top Previous Next
To add a page of a particular language type to a model, select and right-click on the model in the Model E
and select the [Language] menu option, then select the language that you want the page for and then sel
option to add a page of that language, as below.
Adding a Property Graph Schema page to a model
Importing and Exporting Models Top Previous Next
Boston stores ORM Models in a Relational Database stored on a
storage device accessible to Boston (See The Boston Database).
You can also import and export ORM Models via .fbm XML files.
The following help topics outline how to perform the following tasks:
1. Importing a new Model from a .fbm XML file (Importing a new
Model)
2. Importing a Model from a .fbm XML file into an existing Model
(Importing to an existing Model)
3. Exporting a ORM Model to a .fbm XML file (Exporting an ORM
Model to a .fbm XML file)
These features vastly expand the data management capacity of
Boston, allowing you to manage hundreds or even thousands of
Models, by storing the .fbm XML files within the permanent storage
platform of your choice.
Importing a new Model Top Previous Next
The following steps outline how to import an ORM Model into
Boston by importing a .fbm XML file.
1. Make sure the Model Explorer is open within the Boston
workbench
2. Follow the steps in the following help topic, which outlines the
steps to import a .fbm XML file containing an ORM Model into
Boston:
Import an ORM Model from a .fbm XML file.
Importing to an existing Model Top Previous Next
The following steps outline how to import an ORM Model into an existing
Model within the Boston database.
NB This is not a 'merge' type procedure. Importing an ORM Model from a
.fbm XML file into an existing ORM Model first requires Boston to 'Empty'
(or 'purge') the Model Elements from within that Model.
1. Make sure the Model Explorer is open within the Boston workbench;
2. Select the Model within the Model Explorer to which you would like to
import the new ORM Model from a .fbm XML file;
3. Right-click with the mouse on the Model node within the Model
Explorer;
A context menu will open with the options that you have to add a new
Model to the Model Explorer and the Boston database.
4. Select the [Import/Export]->[Import]->[From .fbm File] menu option
5. A "Open File" dialog box will be opened for you to navigate to and
open a .fbm file.
6. Select the Fact-Based Modeling file that you would like to import into
Boston and the Model Explorer, and then select the [Open] button on
the Open File dialog;
7. The selected Model will first be Emptied (or 'purged') of all existing
Model Elements, and the ORM Model within the .fbm XML file will be
imported into Boston and Model selected within the Model Explorer.
Exporting an ORM Model to a .fbm
XML file
Top Previous
Next
The following steps outline how to export an ORM Model to a .fbm
XML file:
1. Make sure the Model Explorer is open within the Boston
workbench;
2. Select the Model within the Model Explorer to which you would
like to export to a .fbm XML file;
3. Right-click with the mouse on the Model node within the Model
Explorer;
A context menu will open with the options that you have to add a
new Model to the Model Explorer and the Boston database.
4. Select the [Import/Export]->[Export]->[To .fbm File] menu option.
You will be presented with a 'Browse For Folder' selection dialog
box.
5. Navigate to the folder to where you would like to export the ORM
Model as a .fbm XML file;
6. Select the [OK] button on the 'Select For Folder' dialog box;
7. The selected ORM Model will be exported to a .fbm XML file
within the selected folder.
NB The name of the file produced will be the same name as the
selected ORM Model, and with the .fbm file extension.
Exchanging Models Top Previous Next
Fact-Based Modeling Exchange MetaModel XSD
Specification
You can exchange ORM Models using .fbm XML files which
conform to FactEngine's Fact-Based Modeling Exchange
MetaModel XSD specification. The specification can be found at the
following web address (HTML link below):
>> Download FBMExchangeMetaModel-XSD-Definition-v1.2.pdf
Introduction Top Previous Next
Boston v5.0 saw the Code Generator introduced to Boston.
The Code Generator is template driven and can produce any text
you desire from either a model in Boston or from the schema of a
database. Text output may include Database Definition Language or
software source code. Database Definition Language can be for any
database type.
The key elements of the Code Generator are:
1. Projects;
2. Templates;
3. Sources; and
4. Transformations;
Projects
File Management
Format
A project is one single file in XML format. A project will have multiple
file items, but they are serialised into a single XML format.
Sources
What is a source?
A source defines a connection to a database or Boston model and
the associated meta data to retrieve from that model and from which
to generate text output.
Templates
Templates are used to define how the Code Generator connects to
the source and what text to produce based on the schema exposed
by a source. Templates output generated text to a file
Providers
Model providers are implementations of specific meta data sources
(such as different database systems). Each provider would have its
own particular quirks, but for database providers there are four
components.
Connection
Basically the connection string to the database.
Tables/Views Meta Data
This is meta data for tables and views. There are two ways to
retrieve it (under the radio button selection group approach)
although some providers may restrict the user to only one of these:
Single result set.
Using a SQL query the meta data is returned as a single data set in
order of tables/views and corresponding columns with their
information (type, size, precision, etc).
Table/column retrieval
Tables are retrieved first, and the columns for each table are then
retrieved individually. This supports any restrictions by providers
that cant or dont have column meta data but do have table meta
data.
Routines Meta Data
This is for stored procedures and functions. SQL queries are the
only known way to retrieve them. The result set returned in a single
data set in order of stored procedures/functions and corresponding
parameters with their information(type, size, precision, etc). Any
select routines returning a dataset will have the column meta data
retrieved internally without user specification. The .NET framework
has support for this.
Managed Code
Templates can execute .Net code. The source is in managed code
files supporting either Visual Basic or C Sharp. Code files are
brought together and compiled into an individual assembly. One
assembly for VB code, and a separate assembly for C# code.
This is possible via .Net codeDOM.
Definition
header
is [template_name](argument,list) [for_statement]
return [output_expression]
end
Description
header
Start of the header block.
template_name identifier
The template is named here using the is keyword and is the
identifier for when it is called. The template item name in the project
is not the identifier, and although they are generally the same name,
they do not have to be identical.
Parameters are declared within parenthesis. Parenthesis can be
omitted if the are no parameters, otherwise empty parenthesis
indicate no parameters.
for_statement statement If omitted, the output is a single file
according to the return expression. If a for statement is specified,
the output is multiple according to the return expression (as a rule
the return expression makes use of the for iterator).
output_expression string
The output path. Paths are relative to the location of the Metadrone
project file not the executable.
end Terminates the header block.
For example, for a single file output writing to the file the-output.txt:
header
is Template1
return "the-output.txt"
end
Call
The template can be called by using the call statement:
E.g. call template1
For multiple outputs: (note the use of the for iterator variable in
the return expression).
E.g.
header
is Template2(connection) for table tbl in connection return "the-
output-" + tbl + ".txt"
end
E.g.
A template is called and a parameter passed to the template:
call Template2(sources.Source1)
public double Seconds
{
get { return _Seconds; }
set { _Seconds = value; }
}
public string Location {
get { return _Location; }
set { _Location = value; }
}
Defining safe zone identifiers in main:
#safebegin = "//safe start"
#safeend = "//safe end"
And then in the generated output file, add customisations within
safe zones:
public double Seconds
{
get { return _Seconds; }
set { _Seconds = value; }
}
//safe start
public double Hours
{
get { return Seconds / 3600; }
set { Seconds = value * 3600; }
}
public double Minutes
{
get { return Seconds / 60; }
set { Seconds = value * 60; }
}
public double Minutes
{
get { return Seconds; }
set { Seconds = value; }
}
//safe end
public string Location {
get { return _Location; }
set { _Location = value; }
}
Template Syntax Top Previous Next
Objective of Templates
The aim of each Template is to define how text is output by the
Code Generator. This section outlines the syntax of the language
used within Templates to define how text is output.
For more sophisticated programming needs, managed .Net code
can be executed within the script (see runcs or runvb).
The key principals. Template Code vs Plain
Text
Tags
Tags are used to enclose text to output, variable data to output or
further tags. In essence, tags control the logic of the Template.
The plain text outside of the <<! and !>> tags are output as the text
is. This included line-feeds and the comma. Plain text is to be
enclosed in double quotes (").
Comments
Any text preceded with a double forward slash // on a line are
ignored by the compiler. There is no support for multi-line
commenting (such as a /* a comment like this */).
The For loop
For loops are used to iterate through the list of items associated
with a schema component.
E.g. This sample code looping through tables and columns within
each table and example output:
<<!for table tbl in sources.source1!>>
SELECT
<<!for column col in tbl!>> <<!col!>>,
<<!end!>>
FROM <<!tbl!>> <<!end!>>
...can return this output:
SELECT
FirstName,
LastName,
Address1,
Address2,
FROM Customer
Statement Separation
Statements are separated by a newline. To have more than one
statement on a line, each statement can be separated by a
semicolon ;.
Variables and Typing Variables are declared by using the set
keyword. There is no explicit typing, variable types are determined
dynamically. Additionally there are no classes, enumerations, etc.
The system types provided are:
Numeric
String
Boolean
Source
Model connection used by the for keyword.
Meta
Model components (such as table or column) used by the for
keyword.
Function Calls
There are no function calls, however templates can be treated as
functions and are run by using the call command.
Scope of variables
There is a simple variable scope concept, without any object
oriented information hiding principles deliberately being used. There
are no access modifiers such as public, private, friend, etc. Three
different kinds of references have this behaviour.
1. Sources
Sources have global exposure and can be called anywhere. A
source connection is referenced by qualifying with the reserved
word sources.
2. Templates
Calls to templates are only accessible within its own package.
3. Variables
Variables are visible only within the block construct it has been
declared in. For instance a variable declared within a for loop
(including the variable declared as the iterator), is not accessible
outside of the block (after the end statement).
Preprocessor Directives
In Main, text preceded by a hash # symbol indicates a directive.
Directives apply to the scope of the package. This includes
processing of transformations from within that package. Directives
cannot be specified in templates.
Preprocessor Directives Top Previous Next
#ignorecase Specifies case sensitivity for string comparisons. The
switch is either on or off. If not specified the default is on.
E.g.
#ignorecase on //String comparisons are not case sensitive.
#ignorecase off //String comparisons are case sensitive.
#safebegin and #safeend Specify safe zone identifiers.
E.g.
#safebegin = "// safe begin"
#safeend = "// safe end"
Call Top Previous Next
Call Execute a template by calling it. There is no return value when
calling a template.
Definition call [template_name](argument,list) Description
template_name identifier. The template to execute as identified in its
header.
argument list - Arguments are passed within parenthesis.
Parenthesis can be omitted if the are no arguments, otherwise
empty parenthesis indicate no arguments.
E.g.
call template1
call template2(tablevar,colvar)
Cout and Coutln Top Previous Next
Output a string to the debug console. Cout will output a string
expression. Coutln will output a string expression followed by a new
line.
Definition cout(arg1) Parameters arg1 string. The string
expression to use.
Returns arg1
Definition coutln(arg1) Parameters arg1 string. The string
expression to use.
Returns arg1
E.g.
<<!
coutln("current table is" + tbl) !>>
Command Top Previous Next
Execute a command line operation.
Not executed in preview mode.
Definition
command(arg1, arg2)
Parameters
arg1 string. The application to execute.
arg2 string.Command line arguments for the application set in arg1.
Returns
Null
E.g.
command("cmd", "/c delete c:\dev\file.txt")
command("c:\dev\postbuild.bat", "")
CNum Top Previous Next
Convert expression to numeric.
This is useful for mathematical expressions where you want to avoid
string concatenation if a variables type is a string.
Definition
cnum(arg1)
Parameters
arg1 string. Expression representing a valid numeric.
Returns
A number.
Eg:
coutln(cnum("1") + 2)
Filecopy Top Previous Next
Copy a file. Relative paths are valid. Files are not copied in preview
mode.
Definition
filecopy(arg1, arg2)
Parameters
arg1 string. The source file.
arg2 string. The destination file name to copy to.
Returns
Null
E.g.
filecopy("source.txt", "..\dest.txt")
filecopy("c:\source.txt", "c:\dest.txt")
Out & Outln Top Previous Next
Outputs text commensurate with the parameter. The out function is
actually unnecessary since an expression will resolve to a string
output. However it is supplied for completeness and can assist with
code readability in some situations.
Out will output a string expression. Outln will output a string
expression followed by a new line.
Definition
out(arg1)
Parameters:
arg1 string. The string expression to use.
Returns:
arg1
Definition
outln(arg1)
Parameters:
arg1 string. The string expression to use.
Returns:
arg1
Eg:
<<!
out("text value")
outln(1 + 2)
!>>
Runc Top Previous Next
Execute C Sharp code. The source is located independently and
compiled when the project is built. The function is typically
referenced with the appropriate namespace and class qualifications.
Definition runcs(arg1)
Parameters arg1 string. Function to call.
Returns The return value of the function that was called.
E.g.
runcs("namespace.class.method(args,etc)")
runcs("CS.MyClass.DoThis(123, ""myargval"")")
Runvb Top Previous Next
Execute Visual Basic code. The source is located independently
and compiled when the project is built. The function is typically
referenced with the appropriate namespace and class qualifications.
Definition runvb(arg1)
Parameters arg1 string. Function to call.
Returns The return value of the function that was called.
E.g.
runvb("namespace.class.method(args,etc)")
runvb("VB.MyClass.DoThis(123, ""myargval"")")
Introduction Top Previous Next
FactEngine allows you to query any database supported by
FactEngine in a natural language based syntax.
FactEngine allows you to perform graph analytics over your database,
because natural language queries are graph-based in nature.
Results can be viewed as graphs or columnar values.
Statement/Clause Syntax Top Previous Next
This chapter outlines the syntax of FactEngine queries and
statements.
The FactEngine query and statement syntax is easy to understand
because it is based on natural language.
A typical FactEngine query looks like the below:
WithClause = 12 ' E.g. WITH WHAT Rating (as in "WHICH Person likes
WHICH City WITH WHAT Rating"), can also be WITH (Rating:'10') for
instance.
AndThatIdentityCompatitor = 13 ' E.g. "Person 1 IS NOT Person 2" Or
"Person 1 IS Person 2"
ISNOTClause = 131 ' E.g. Person 1 IS NOT Person 2
ISClause = 132 ' E.g. Person 1 IS Person 2
ModelElementName
When querying a database Model Elements are commensurate to
Tables, Nodes and Attributes in your database.
- Object-Role Models consist of model elements, such as Entity
Types, Value Types and Objectified Fact Types. Role Constraints
and Roles, for instance, are also model elements.
- Entity Relationship Diagrams have Entity and Attribute model
elements.
- Property Graph Schemas have Node and Property model
elements.
So when querying a database if you relate the model elements in
your conceptual models in Boston to their corresponding model
elements within your database, then you understand that the name
of each model element is a ModelElementName. For example, the
following FactEngine query has Lecturer, Room, Position, School
and Faculty as ModelElementNames.
Predicates
As the name suggests, Predicates are the predicates of your
conceptual models in Boston.
The query above has the following predicates;
- occupies
- holds
- is in
- works for
Property Node Identification
If you need to identify a particular data item in your database you do
that with a PropertyNodeIdentification clause.
In the example query above, (Faculty:'IT') finds a particular
row/node in your database that is uniquely identified by the name,
'IT', and where the first unique index of the node/table is used to find
the appropriate attribute/property value.
ModelElementName Top Previous Next
When querying a database Model Elements are commensurate to
Tables, Nodes and Attributes in your database.
- Object-Role Models consist of model elements, such as Entity
Types, Value Types and Objectified Fact Types. Role Constraints
and Roles, for instance, are also model elements.
- Entity Relationship Diagrams have Entity and Attribute model
elements.
- Property Graph Schemas have Node and Property model
elements.
So when querying a database if you relate the model elements in
your conceptual models in Boston to their corresponding model
elements within your database, then you understand that the name
of each model element is a ModelElementName. For example, the
following FactEngine query has Lecturer, Room, Position, School
and Faculty as ModelElementNames.
Property Node Identification
If you need to identify a particular data item in your database you do
that with a PropertyNodeIdentification clause.
In the example query below, (Faculty:'IT') finds a particular row/node
in your database that is uniquely identified by the name, 'IT', and
where the first unique index of the node/table is used to find the
appropriate attribute/property value.
NB The property node identification may span multiple
fields/properties in the table/node that it represents. E.g.
(Lecturer:'Cathy','Donald').
Example
For example, in the Entity Relationship Diagram below, because the
Lecturer entity only has one unique key, spanning FirstName and
LastName, a Property Node Identification for Lecturer can be written
(Lecturer:'Kathy','Stevens')
Comparators Top Previous Next
FactEngine Knowledge Language has three standard comparators,
Equals, Not Equals and LIKE.
They are implemented as part of the syntax for Property Node
Identification.
Equals comparator The colon, :, is used for equals.
Not Equal/s comparator The bang, !, symbol is used for Not
Equals.
LIKE comparator
The tilde, ~, symbol is used for the LIKE comparator.
WHICH Select Statement Top Previous Next
The which select statement allows you to query the database
behind a model in natural language based syntax.
A typical which select statement looks like the below:
Structure of a Which Select Statement A which
select statement is preceded with the WHICH keyword, followed by
a Model Element Name, followed by a set of Which Clauses.
The details are verbose, but the syntax is very easy if you just think
your query in natural language. The sections in this documentation
provide examples of the various Which Clauses that you can use.
Definition
WHICHSELECTSTMT -> KEYWDWHICH MODELELEMENT
(WHICHCLAUSE)* EOF; WHICHCLAUSE -> (KEYWDAND |
KEYWDWHICH)? (WITHCLAUSE | WHICHTHATCLAUSE?
(KEYWDWHICH | KEYWDTHAT | KEYWDAN | KEYWDA)? NODE
MATHCLAUSE?)?; WITHCLAUSE -> KEYWDWITH (KEYWDWHAT
| KEYWDA)? (MODELELEMENT |
NODEPROPERTYIDENTIFICATION); WHICHTHATCLAUSE ->
((KEYWDIS PREDICATE | PREDICATECLAUSE) | KEYWDTHAT
(PREDICATECLAUSE | MODELELEMENT ((KEYWDISNOT |
KEYWDIS) | PREDICATECLAUSE)) | MODELELEMENT
PREDICATECLAUSE); MODELELEMENT ->
PREBOUNDREADINGTEXT? MODELELEMENTNAME
POSTBOUNDREADINGTEXT? MODELELEMENTSUFFIX?;
NODEPROPERTYIDENTIFICATION -> BROPEN
MODELELEMENTNAME MODELELEMENTSUFFIX?
QUOTEDIDENTIFIERLIST* BRCLOSE;
Clauses Top Previous Next
Which select statements consist of one or more Which Select
Clauses.
The example below contains 6 Which Select Clauses. They are:
1. occupies WHICH Room
2. AND holds WHICH Position
3. AND is in WHICH School
4. AND is in A School
5. WHICH is in (Faculty:'IT')
6. AND THAT Lecturer works for THAT Faculty
Example of Use
WHICH <Predicate> <Property Node
Identification>
Top Previous
Next
An example of this clause type is" "WHICH is in (Faculty:'IT') as in
the which select statement below:
NB The property node identification may span multiple
fields/properties in the table/node that it represents. E.g.
(Lecturer:'Cathy','Donald').
Example of Use
CREATE DATABASE Top Previous Next
The CREATE DATABASE statement allows you to create a
database (SQLite at this stage) that is connected to a Model in
Boston.
Syntax
CREATEDATBASESTATEMENT ::= CREATE DATABASE
<ModelDatabaseName>; LOCATIONCLAUSE [;TYPECLAUSE]
ModelDatabaseName : The name of the Model that will be created,
and the name of the database.
LOCATIONCLAUSE ::= LOCATION = <Disk drive location> Disk
drive location : The location on the computer disk where the
database will be created.
NB Must include the name of the database file. E.g. MyModel.db
TYPECLAUSE ::= TYPE = <DatabaseType>
DatabaseType : Limited to 'SQLite' at this stage.
The Boston Database Top Previous Next
The Boston database contains a state of the art MetaModel of Fact-
Based Modeling (FBM). The following help topics describe the
tables and fields of the Fact-Based Modeling MetaModel within
Boston.
NB Tables that are prefixed, 'MetaModel', are at the
MetaMetaModel level of a 4-Layer Architecture when considering
Languages interpreted from the Model (stored within the
MetaModel) that are not ORM or FBM Models. Tables that are
prefixed 'Model' are at the MetaModel level of a 4-Layer
Architecture when considering Languages interpreted from the
Model (stored within the MetaModel) that are not ORM or FBM
Models.
The languages currently supported by Boston are Object-Role
Modeling (ORM), Entity Relationship Diagrams, Property Graph
Schema and State Transition Diagrams. Boston's 4-Layer
Architecture supports Languages other than ORM to be stored
within the one ORM MetaModel as MetaMetaModel.
IMPORTANT Never delete the Model called, "LanguageEnglish",
and with ModelId, "English", from the database backend.. This
model is required by the Virtual Analyst functionality in Boston.
IMPORTANT Never delete the Model called, "Core", and with
ModelId, "Core", from the database backend.. This model is
required by Boston for future extensions including the creation of
ER Diagrams within Boston.
Technical Details
The Boston database is a Microsoft Jet (MS Jet) database, and
Boston uses the embeddable ADO.Net database engine to access
the MS Jet database file.
Release Details
This version of Boston has the following release details:
Boston application version: v6.0
Boston database version: 1.32 (Database documentation is for
version 1.0. Please contact FactEngine for an up to date database
documentation.)
Backing-Up the Boston Database Top Previous Next
If your installation of Boston uses the Microsoft Jet database engine
you can make regular and ad hoc backups of your Boston database
from within Boston.
To backup the Boston database, select the [Boston]->[Database]->
[Backup Database] menu option.
1. Boston will make a backup of the Boston database with a
filename of the following format:
ORMStudioYYYYMMDDHHNNSS.vdb
YYYY
- is the year of the database backup
MM
- is the month of the database backup
DD
- is the day of the month of the database backup
HH
- is the hour of the day of the database backup
NN
- is the minute of the hour of the day of the database backup
SS
- is the second of the minute of the hour of the day of the
database backup
MetaModelConcept Stores the set of Concepts as utilised in
Models in Boston.
MetaModelEntityType Stores the set of Entity Types by Model.
MetaModelFact Stores the set of Facts by Model.
MetaModelFactData Stores the set of Fact Data by Fact, by Model.
MetaModelFactType Stores the set of Fact Types by Model.
MetaModelFactTypeReadingStores the set of Fact Type Readings
by Fact Type, by Model.
MetaModelJoinPathRoleStores Roles that are part of a Join Path
for an Argument of a Role Constraint.
MetaModelModel Stores the set of Models in Boston.
MetaModelModelDictionary Stores the set of Concepts utilised in a
Model.
MetaModelModelNote Stores the set of Model Notes by Model.
MetaModelPredicatePart Stores the set of Predicate Parts of Fact
Type Readings by Model.
MetaModelRole Stores the set of Roles by Fact Type, by Model.
MetaModelRoleConstraint Stores the set of Role Constraints by
Model.
MetaModelRoleConstraintArgumentStores details of Role
Constraint Arguments for those
Role Constraints that have
Arguments.
MetaModelRoleConstraintRole Stores the set of Roles referenced
by a Role Constraint, by Model.
MetaModelRoleValueConstraintStores values for Role Value
Constraints.
MetaModelSubtypeRelationship Stores the set of Subtype
Relationships (Subtype/Supertype
pairs), by Model.
MetaModelValueType Stores the set of Value Types by Model.
MetaModelValueTypeConstraint Stores the set of Value Constraints
for a Value Type, by Model.
ModelConceptInstance Stores the Instance data for Concepts by
Page, by Model.
ModelLanguage Stores the set of Languages supported by
Boston.
ModelPage Stores the set of Pages by Model.
Symbol The Symbol that represents the Concept. e.g. A
Concept of type Person is represented by the Symbol,
'Person'.
The 'Symbol' of a Concept may be a String, Binary Bit
Stream, Number, Chinese Character, Japanese Kanji
Character etc.
In the Boston MetaModel, the word 'runs' (for
example) is thought of as a Symbol in its own right as
if it were an idiomatic Symbol (which, of course, it
conceptually is; only that in English that Concept is
spelt using four characters rather than one).
i.e. The Boston MetaModel takes a nominalistic
approach to conceptual modeling.
Concepts in the Boston database Top Previous Next
Concepts are stored within the Boston database within a table
called, 'MetaModelConcept'.
The MetaModelConcept table has only one field called, 'Symbol',
and stores a list of the Concepts/Symbols used in all Models within
Boston.
Concepts instances within the Boston database accumulate over
time with the development of Models. Periodically, Concepts no
longer used by any Model in Boston should be removed from the
database.
Table Maintenance - MetaModelConcept
To remove unneeded Concepts from the database, open the
[Boston] menu on the main Boston form and select [Database]->
[Remove unneeded Concepts].
You will be presented with the Concept maintenance form.
To remove unneeded Concepts from the database click on the
button [Remove unneeded Concepts]. This operation will not affect
any existing Model in Boston or prevent the import of new Models.
The MetaModelEntityType table Top Previous Next
The MetaModelEntityType table stores the set of Entity Types
utilised by a Model.
Field Description
StartDate Unused at present
EndDate Unused at present
ModelId The unique identifier of the Model to which
the Model Element (Entity Type) belongs.
EntityTypeId The unique identifier of the Entity Type. As
stored as Symbol in
MetaModelModelDictionary and
MetaModelConcept tables.
EntityTypeName The name of the Entity Type. Must be the
same as EntityTypeId in Boston.
ValueTypeId If the Entity Type has a Reference Mode
which is not a Compound Reference
Scheme, set to the unique identifier
(ValueTypeId) of the Value Type that forms
part of the Reference Scheme for the Entity
Type, else this field is NULL.
ReferenceMode If the Entity Type has a Reference Mode
which is not a Compound Reference
Scheme, set the 'Reference Mode' of the
Entity Type, else this field is NULL/""
PreferredIdentifierRCId Set to the unique identifier
(RoleConstraintId) of the Role Constraint
which determines the Reference Scheme
for the Entity Type.
IsMDAModelElement True if the Entity Type is part of the Core
Model in the 4-Layer Architecture used by
Boston. MDA stands for 'Model Driven
Architecture'.
IsPersonal True if the Entity Type should result in ORM
Verbalises that use "who" rather than "that"
for instances of the Entity Type. Currently
not used in Boston.
GUID
Unique universal identifier for the Entity Type. Not
currently used by Boston. Can be used to store
URIs etc in ontologies.
IsAbsorbed True if the corresponding RDS (Relational
Database Structure) Table for the Entity Type is
absorbed into the table of the Primary Subtype
Relationship (Identification Path) of the Entity
Type.
Is only relevant if the Entity Type is a subtype of
another Model Element.
IsIndependent True if the Entity Type is independent (in an ORM
sense).
IsDerived True if there is a derivation rule that defines
instances of the Entity Type.
DerivationText If the Entity Type is derived (see IsDerived above),
the derivation rule that defines instances of the
Entity Type.
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which the Model
Element belongs.
Symbol The unique identifier of the Fact. Equivalent to 'RowId'
in say an ORACLE database. In the Boston generic
Object-Role Modeling MetaModel (gORMmm), a
Lemma is the lowest level of identification of a
Concept/Symbol, of which a Fact (Tuple) can be a
Concept/Symbol in it's own right. I.e. Facts of Fact
Types have identity in the Boston model.
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which the Model
Element belongs.
FactTypeId Foreign Key reference to the MetaModelFactType
table. The Fact Type to which the Fact Data belongs.
FactSymbol Foreign Key reference to the MetaModelFact table.
The Fact to which the Fact Data belongs.
RoleId Foreign Key reference to the MetaModelRole table.
The Role within the Fact Type to which the Fact Data
belongs.
The MetaModelFactType table Top Previous Next
The MetaModelFactType table stores details of each Fact Type in a
Model.
Field Description
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to
which the Model Element belongs.
FactTypeId The unique identifier of the Fact Type.
Is the actual name of the Fact Type.
FactTypeName The name of the Fact Type. Must be the
same as FactTypeId in Boston.
IsObjectified Set to True if the Fact Type is
objectified, else set to False.
IsCoreFactType Not currently used.
IsPreferredReferenceMode If an Entity Type does not have a
Compound Reference Scheme, set to
True where the Fact Type is the Fact
Type that contains the Role Constraint
which defines the Reference Scheme
for the Entity Type, else set to False.
Used to hide Fact Types within the
graphical user interface (GUI), where a
Reference Scheme for an Entity Type
(that does not have a Compound
Reference Scheme) is not displayed to
the user of the software.
ObjectifyingEntityTypeId Set to the unique identifier of the Entity
Type that is the Objectifying Entity Type
of an Objectified Fact Type, else NULL
IsSubtypeFactType Set to True if the Fact Type is a Fact
Type that defines a Subtype
Relationship between Object Types.
IsMDAModelElement True if the FactType is part of the Core
MetaModel stored within the ORM
MetaModel as MetaMetaModel, else
False. MDA stands for 'Model Driven
Architecture'.
IsDerived True if instances of the Fact Type are
defined by a derivation rule, else False.
DerivationText If the Fact Type is derived, the
derivation rule that ranges over
instances of the Fact Type.
IsLinkFactType True if the Fact Type is a Link Fact Type
for an Objectified Fact Type, else False.
GUID
Unique universal identifier for the Fact
Type. Not currently used by Boston. Can
be used to store URIs etc in ontologies.
Used predominantly for model sharing
with other platforms.
LinkFactTypeRoleId If the Fact Type is a Link Fact Type, is a
foreign key reference to the Role to
which the Link Fact Type is related.
IsIndependent. True if the Fact Type is independent in
an ORM sense.
IsSubtypeStateControlling True if the FactType is a relation
between a Supertype and a ValueType
such that values of the ValueType
determine the state of Subtypes of the
Supertype, else False
Used when State Transition Diagrams
are created for a Value Type that is
correlated with the type of Subtypes of a
Supertype linked to that Value Type.
E.g. Person has Gender, where
PersonType is a Value Type with a Value
Constraint ranging over 'Male', 'Female'.
StoreFactCoordinates NB Only used for MDA FactTypes in the
CMML. True if coordinates are stored for
Facts allocated to a Page. Normally
FactData coordinates are stored only.
FactData/Values are not always unique
on a Page. Facts are always unique on a
Page.
See also:
The MetaModelFact table
The MetaModelFactData table
The MetaModelRole table
The MetaModelFactTypeReading table
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which the Model
Element belongs.
FactTypeReadingId The unique identifier of the Fact Type Reading.
FactTypeId Foreign Key reference to the MetaModelFactType
table. The Fact Type to which the Fact Type Reading
belongs.
FrontText Stores the Front Text of a Fact Type Reading. E.g. In
the Fact Type Reading "sometimes Person goes to
Town", 'sometimes' is Front Text.
FollowingText Stores the Following Text of a Fact Type Reading.
E.g. In the Fact Type Reading "Person goes to
Town sometimes", 'sometimes' is Front Text.
TypedPredicateId The Id of the TypedPredicate to which the
FactTypeReading belongs. A TypedPredicate is
an ordered set of Roles of a FactType.
The order of the Roles is always the same as
the FactTypeReading. There may be more than
one FactTypeReading with the same
TypedPredicateId
Not really used in Boston.
See the Fact-Based Modelling Working Group's,
Fact-Based Modelling MetaModel.
IsPreferred True if the FactTypeReading is the preferred Fact
Type Reading for the associated Fact Type, else
False.
See the Fact-Based Modelling Working Group's,
Fact-Based Modelling MetaModel.
StartDate Not currently used.
EndDate Not currently used.
ModelId The Model to which the Model Element belongs.
Foreign Key reference to the MetaModelModel table.
RoleConstraintArgumentId The Role Constraint Argument to which
the Model Element belongs. Foreign
Key reference to the
MetaModelRoleConstraintArgument
table.
RoleId Represents the Role that is part of the Join Path
defined (in part) by instances stored in this table.
Foreign Key reference to the MetaModelRole table.
SequenceNr The ordinal position within the Role Path that the
Role identified by this tuple plays in a Join Path for
a Role Constraint Argument.
The MetaModelModel table Top Previous Next
The MetaModelModel table stores details of a Model.
IMPORTANT Never delete the Model called, "English". This
model is required by the Virtual Analyst functionality in Boston.
IMPORTANT Never delete the Model called, "Core". This model
is required to create ER Diagrams or Property Graph Schemas in
Boston.
Field Description
ModelId The unique identifier of the Model to which the Model
Element belongs.
ModelName The name of the Model.
ShortDescription Not used in this version of Boston. A short
description of the Model.
LongDescription Not used in this version of Boston. A long
description of the Model.
EnterpriseId Not used in this version of Boston. Provided for
consistency with the Richmond product by
FactEngine.
SubjectAreaId Not used in this version of Boston. Provided for
consistency with the Richmond product by
FactEngine.
ProjectId Used in the Boston Online product/configuration of
Boston. I.e. When Boston is in Client/Server mode
with Projects, Users, Groups, Functions, Roles,
Permissions.
ProjectPhaseId Not used in this version of Boston. Provided for
consistency with the Richmond product by
FactEngine.
SolutionId Not used in this version of Boston. Provided for
consistency with the Richmond product by
FactEngine.
IsConceptualModel Not used in this version of Boston. Provided for
consistency with the Richmond product by
FactEngine.
IsPhysicalModel Not used in this version of Boston. Provided for
consistency with the Richmond product by
FactEngine.
IsNamespace Not used in this version of Boston. Provided for
consistency with the Richmond product by
FactEngine.
IsEnterpriseModel Not used in this version of Boston. Provided for
consistency with the Richmond product by
FactEngine.
TargetDatabaseType The target database type, as used by
FactEngine over the database of that type.
TargetDatabaseConnectionString The connection string used to
connect to the database. As used
by ADODB
NamespaceId The Namespace the Model is included within;
especially used when Boston is run under a
Client/Server environment.
CreatedByUserId The User in the Client/Server model that created
the Model.
CoreVersionNumber The version of the Core MetaModel injected
within the Model as part of the 4-Layer
Architecture model of Boston.
Used such that the Core MetaModel injection
can be kept up to date.
Server E.g. As required for connecting to Snowflake or
TypeDB databases.
DatabaseName E.g. As required for connecting to Snowflake or
TypeDB databases.
Schema E.g. As required for connecting to Snowflake
databases.
Warehouse E.g. As required for connecting to Snowflake
databases.
Role E.g. As required for connecting to Snowflake
databases.
Port E.g. As required for connecting to Snowflake or TypeDB
databases.
StoreAsXML True if the Model is stored as XML external to the
Boston database, in which case only the
MetaModelModel table stores information about the
Model. All other Model Element data is then stored
as XML external to the database.
NB A copy of the Model Element data (i.e. the rest
of the Model) can be stored redundantly within the
Boston database, but if stored as XML, the Model is
loaded into memory (for use by Boston) by
deserialising the Model stored in XML.
The Model Dictionary
(MetaModelModelDictionary table)
Top
Previous
Next
Each Model in Boston has a Model Dictionary containing a set of
the Concepts utilised by that Model. Each entry in the
MetaModelModelDictionary table stores the Symbol of the Concept
that the 'Dictionary Entry' represents and the Subtype of Concept
that the Dictionary Entry represents (e.g. Entity Type, Value Type,
Fact Type, Role Constraint, Model Note, Fact or Value).
Field Description
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which the Model
Element belongs.
Symbol The unique Symbol within the Model Dictionary for the
represented Model Element. Foreign Key reference to
the MetaModelConcept table.
E.g. The name of a Value Type, Entity Type or Fact
Type.
ShortDescription A short description of the Model Element.
LongDescription A long description of the Model Element.
IsEntityType Set to True if the value of 'Symbol' is a unique
identifier for an Entity Type within the Model.
IsValueType Set to True if the value of 'Symbol' is a unique
identifier for a Value Type within the Model.
IsFactType Set to True if the value of 'Symbol' is a unique
identifier for a Fact Type within the Model.
IsFact Set to True if the value of 'Symbol' is a unique identifier
for a Fact within the Model.
IsValue Set to True if the value of 'Symbol' is a unique
identifier for a Value within the Model.
IsRoleConstraint Set to True if the value of 'Symbol' is a unique
identifier for a Role Constraint within the Model.
IsModelNote Set to True if the value of 'Symbol' is a unique
identifier for a Model Note within the Model.
IsGeneralConcept True if the Concept/Symbol is valid within the
Model/Universe of Discourse but not yet
assigned to one of Value Type, Entity Type,
Fact Type, Role Constraint, Model Note, Fact or
Value.
NB Only used if the Model Elements of the
Model are stored within the Boston database
and not stored as XML outside of the Boston
database. This is because the XML schema
does not have an Element for Model
Dictionary...only the Model Elements
themselves, so a 'General' concept cannot be
stored in the XML format.
DBName For Entity Types or (Objectified) Fact Types, the
name of the corresponding entity within the target
database of the Model, especially if the database
name of the entity is not the same as the
corresponding Model Element in the Boston Model.
ModelNoteId The unique identifier of the Model Note.
NB To find which ModelNotes are within a Model,
search the MetaModelModelDictionary table.
Note The note text of the Model Note.
JoinedObjectTypeId The unique identifier of the Object Type joined
to the Model Note when displaying the Model
Note within the GUI/an ORM diagram.
Represents the Object Type to which the
Model Note applies.
IsMDAModelElement True if the ModelNote is part of the Core
MetaModel injected within Models within the
4-Layer Architecture used by Boston, else
False.
ModelId The Model to which the ModelNote belongs. Foreign
Key reference to the MetaModelModel table.
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which the Model
Element belongs.
FactTypeReadingId Foreign Key reference to the
MetaModelFactTypeReading table. The Fact
Type Reading to which the Predicate Part
belongs.
SequenceNr The ordinal position of the Predicate Part within the
set of Predicate Parts for a Fact Type Reading.
e.g. in the predicate, "Part is in Bin in Warehouse",
the Predicate Part, 'is in', is the first in the sequence
of Predicate Parts, and this field will have a value of
'1'.
Symbol1 No longer used. See RoleId.
The unique identifier of the Object Type joined by
the Role of the Fact Type to which the Fact Type
Reading applies, and to which this Predicate Part
applies.
e.g. In the predicate, 'Part is in Bin in Warehouse',
the first Predicate Part in the sequence of Predicate
Parts for the predicate will have a value set to 'Part'
for this field.
Symbol2 No longer used. See RoleId.
The unique identifier of the Object Type joined by
the Role of the Fact Type to which the Fact Type
Reading applies, and to which this Predicate Part
applies.
e.g. In the predicate, 'Part is in Bin in Warehouse',
the first Predicate Part in the sequence of Predicate
Parts for the predicate will have a value set to 'Bin'
for this field.
PredicatePartText The part of the predicate represented by this
Predicate Part.
e.g. In the predicate, 'Part is in Bin in
Warehouse', the first Predicate Part in the
sequence of Predicate Parts for the predicate
will have a value set to 'is in' for this field.
NB A Ternary Fact Type, such as "Part is in Bin
in Warehouse" will have three
MetaModelPredicatePart tuples, but the third
Predicate Part will have no PredicatePartText.
See RoleId field.
RoleId The Role that joins to the Model Element for which this
Predicate Part record provides Predicate Part Text.
Foreign Key Reference to the MetaModelRole table.
E.g. In the Fact Type with a reading, "Part is in Bin in
Warehouse", for the Predicate Part Text, "is in", RoleId
is a reference to the Role that joins to the 'Part' Model
Element/Object Type.
PreboundText In a Fact Type Reading, "Person has first-Name",
"first-" is a Prebound Text.
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which the Model
Element belongs.
RoleId The unique identifier of the Role.
RoleName If the Role has a Role Name, set to the 'Role Name'
of the Role, else NULL/"".
FactTypeId Foreign Key reference to the Fact Type table. The
Fact Type to which the Role belongs.
PartOfKey Not used in this version of Boston.
Cardinality Not used in this version of Boston.
SequenceNr The ordinal position of the Role within the set of
Roles of a Fact Type. Especially used in Binary
Fact Types that have Ring Constraints.
Not currently used.
TypeOfJoin '1' if the Role is played by an Entity Type;
'2' if the Role is played by a Value Type; or
'3' if the Role is played by a Fact Type.
IsMandatory Set to True if the Role is Mandatory, else set to
False.
IsArray NB Only used for Models with NoSQL target
databases.
True if the Role (joined to a Model Element) represents
an Array (stored in a NoSQL database such as
MongoDB as a JSON array), rather than a separate
Many-to-Many Table/Entity.
I.e. The Role indicates that the array information forms
part of the document for the joined Model Element.
E.g. If Person drives Car is a Fact Type, and a person
can drive many cars, and the information is stored as
an array in the database, the Role joined to Person in
the Fact Type would be flagged as 'IsArray'.
The MetaModelRoleConstraint
table Top Previous Next
The MetaModelRoleConstraint table stores details of Role
Constraints.
Field Description
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to
which the Model Element belongs.
RoleConstraintId The unique identifier of the Role
Constraint.
RoleConstraintName The name of the Role Constraint. Must
be the same as the RoleConstraintId.
RoleConstraintType The type of Role Constraint represented
by the element.
RingConstraintType If the RoleConstraintType attribute of the
Role Constraint element has a value of
RingConstraint then this attribute has a
value of the type of Ring Constraint.
LevelNr If the RoleConstraint is an,
'InternalUniquenessConstraint', then set
to the displaying 'Level' in the tiered
representation of Internal Uniqueness
Constraints for the Fact Type to which
the Role Constraint applies.
IsPreferredUniqueness Has a value set to true if the Role
Constraint represented by the element
represents the Preferred Identification
Scheme for an Entity Type.
IsDeontic Has a value set to true if the Role
Constraint is Deontic, else has a value
set to false.
MinimumFrequencyCount If the RoleConsrtaintType attribute has a
value of FrequencyConstraint then this
attribute has a value set to the minimum
in the range of the Frequency
Constraint.
MaximumFrequencyCount If the RoleConsrtaintType attribute has a
value of FrequencyConstraint then this
attribute has a value set to the maximum
in the range of the Frequency
Constraint.
Cardinality
CardinalityRangeType
ValueRangeType If the Role Constraint is a Value-
Comparison Constraint, stores values of
'LessThan', 'LessThanOrEqual',
'GreaterThan', 'GreaterThanOrEqual'
IsMDAModelElement True if the Role Constraint is part of the
Core Model in the 4-Layer Architecture
used by Boston. MDA stands for 'Model
Driven Architecture'.
GUID
Unique universal identifier for the Role Constraint.
Not currently used by Boston. Can be used to
store URIs etc in ontologies.
MinimumValue Used in Value Constraints. E.g. Role Value
Constraints.
MaximumValue Used in Value Constraints. E.g. Role Value
Constraints.
See also:
The MetaModelRoleConstraintRole table
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which the Model
Element belongs.
Id The unique Id of the Argument (within the Model)
RoleConstraintId The unique identifier of the Role Constraint.
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which the Model
Element belongs.
RoleConstraintId Foreign Key reference to the
MetaModelRoleConstraint table. The Role
Constraint to which the reference to a 'Role' of
that Role Constraint applies.
RoleId Foreign Key reference to the MetaModelRole table. The
Role referenced by the Role Constraint identified in the
field, 'RoleConstraintId'.
SequenceNr The ordinal position of the RoleConstraintRole
within the sequence of RoleConstraintRole
elements for a RoleConstraint.
IsEntry Not currently used.
Used only for SubsetConstraint, RoleConstraints.
Has a value set to true is the RoleConstraintRole
element represents a RoleConstaint/Role link that is
the Entry link of a Entry/Exit combination of
RoleConstraint/Role links, else has a value set to false.
e.g. If a link to a Role from a RoleConstraint is an Entry
link of a Subset Constraint, the values of Instances
referenced by that Role are the subset of Instances
referenced by the Role of a corresponding
RoleConstraint/Role link that is an Exit link.
IsExit Not currently used.
Used only for SubsetConstraint, RoleConstraints.
Has a value set to True is the RoleConstraintRole
element represents a RoleConstaint/Role link that is the
Exit link of a Entry/Exit combination of
RoleConstraint/Role links, else has a value set to False.
ArgumentId The Id of the Argument to which the
RoleConstraintRole belongs, if the corresponding
Role Constraint requires Arguments.
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which the Model
Element belongs. Foreign Key reference to the
MetaModelModel table.
RoleConstraintId The Role Constraint to which the Role Value
Constraint value relates. Foreign Key reference
to the MetaModelRoleConstraint table.
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which the Model
Element belongs.
ObjectTypeId The Object Type that is a Subtype of another
Object Type within the Subtype Relationship.
SupertypeObjectTypeId The Object Type that is the Supertype of
the Object Type identified as the Subtype
within the Subtype Relationship.
NB May be the unique identifier of the
Objectifying Entity Type of a Fact Type.
SubtypingFactTypeId Foreign Key reference to the
MetaModelFactType table. Represents the
Fact Type that provides the Identity
Relationship between the Subtype and the
Supertype.
IsPrimarySubtypeRelationship True if provides the Identification
Path for a the Subtype.
The MetaModelValueType table Top Previous Next
The MetaModelValueType table stores details of Value Types.
Field Description
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which
the Model Element belongs.
ValueTypeId The unique identifier of the Value Type.
ValueTypeName The name of the Value Type. Must be the
same as the ValueTypeId.
DataType The Data Type of the Value Type.
DataTypeLength The Length of the DataType. E.g. 100 where
the Data Type is TextFixedLength limited to
100 characters. Default is 0.
DataTypePrecision The Precision when for Numeric Data Types
with a Precision Value. E.g. Double Precision
Numerical data type.
IsMDAModelElement True if the Value Type is part of the Core
Model in the 4-Layer Architecture used by
Boston. MDA stands for 'Model Driven
Architecture'.
StartDate Not currently used.
EndDate Not currently used.
ModelId The unique identifier of the Model to which the Model
Element belongs.
ValueTypeId Foreign Key reference to the MetaModelValueType
table. The Value Type for which the Value Type
Constraint applies.
The ModelConceptInstance table Top Previous Next
The ModelConceptInstance table stores the set of Concepts
(identified by their 'Symbol') that appear on a Page within a Model.
Field Data
Type
Description
StartDate DateTime Not currently used.
EndDate DateTime Not currently used.
ModelId Text The unique identifier of the Model to which
the Model Element belongs.
PageId Text Foreign Key reference to the Page table.
The Page for which the Model Element is
included on that Page within the Model.
Symbol Text The unique identifier of the Model Element
included on the Page within the Model.
ConceptType Text The Concept Type of the Model Element
included on the Page within the Model.
RoleId Text Where the 'ConceptType' of the Model
Element is 'RoleName' or 'Value', set to
the RoleId of the corresponding 'Role
Name' or the 'Fact Data' to which the
Model Element belongs.
X
Number The X-Coordinate of the Model Object as it appears
on the Page within the Model. i.e. Within the GUI
interface displaying the Page, the Y-Coordinate of
the Model Element.
NB Where the X-Coordinate of the Model Element is
not required to display the Model Element within the
Page, set to '0'.
Y
Number The Y-Coordinate of the Model Object as it
appears on the Page within the Model. i.e.
Within the GUI interface displaying the Page,
the Y-Coordinate of the Model Element.
NB Where the X-Coordinate of the Model
Element is not required to display the Model
Element within the Page, set to '0'.
Orientation Number Not used by this version of Boston. Always
set to '100' (Horizontal) in this version of
Boston.
IsVisible Boolean True if the Concept Instance is visible on the
corresponding Page, else False.
Not really used by this version of Boston.
Always set to False in this version of Boston.
See also:
The ModelPage table
The ModelLanguage table Top Previous Next
The ModelLanguage table stores details about Languages.
"Pages" in Boston are interpreted by their language. ORM
Models/Diagrams are displayed as ORM Diagrams within Boston
because they are interpreted as ORM Diagrams. Each 'Page' is
flagged as to the language of interpretation.
In this version of Boston, all Pages are interpreted as ORM
Models/Diagrams.
Field Description
LanguageId The unique identifier of the Language
LanguageName The name of the Language. e.g. "ORM Model",
"ER Diagram", "English"
PageId The unique identifier of the Page.
PageName The name of the Page.
ModelId The unique identifier of the Model to which the Page
belongs.
LanguageId Foreign Key Reference to the ModelLanguage table.
Represents the Language that should be used to
interpret Models stored within the MetaModel.
NB Boston currently supports the interpretation of
ORM Models, Entity Relationship Diagrams,
Property Graph Schema and State Transition
Diagrams from within the ORM
MetaModel/MetaMetaModel.
Contact FactEngine for a paper on how this works.
Boston incorporates a 4-Layer Architecture with
different languages as logical injections within the
ORM metamodel.
IsCoreModelPage True if the Page is part of the Core MetaModel
stored within the ORM MetaModel as
MetaMetaModel, else False.
ShowFacts Set to True if the Fact Table of Facts is to be
displayed to the user on loading of the Page within
the graphical user interface (GUI).
The ORM Graphical Notation Top Previous Next
The following table provides a lexicon of the ORM Graphical
Notation.
This lexicon has kindly been provided by its author Dr Terry Halpin
and remains the copyright of Dr Halpin (2015). Dr Halpin provided
the formalisation of ORM in its first incarnation as output of Dr
Halpin's PhD thesis.
This lexicon covers the constructs of ORMv2.
Dr Halpin's PhD thesis and more information about ORM can be
found on Dr Halpin's website dedicated to ORM: www.orm.net
Construct
and
Examples
Description/Notes
Entity type Named soft
rectangle, named
hard rectangle, or
named ellipse. The
soft rectangle
shape is the default.
Value type
Named, dashed,
soft rectangle (or
hard rectangle or
ellipse).
Entity type with popular reference
mode
Abbreviation for
injective reference
relationship to value
type, e.g.
Entity type with unit-based reference
mode
Abbreviation for
reference fact type,
e.g.
Optionally, the unit
type may be
displayed (as
shown opposite).
Entity type with general reference
mode
Abbreviation for
reference fact
types, e.g.
Independent object
type
Instances of
the type may
exist, without
playing any
elementary fact
roles.
External object type
Object type
is defined in
another
model. This
notation is
tentative (yet
to be
finalized)
Predicate (unary, binary,
ternary, etc.)
Ordered set
of 1 or more
role boxes
with at least
one
predicate
reading in
mixfix
notation. If
shown,
object
placeholders
are denoted
by �. If
placeholders
are not
shown,
unaries are
in prefix and
binaries are
in infix
notation
Duplicate type or
predicate shape
If an object
type or
predicate
shape is
displayed
more than
once (on
the same
page or
different
pages) it is
shadowed.
Unary fact type
Attaching a role
box to an object
type shape mean
that only
instances of that
object type may
play that role
(e.g. here, the
smokes role may
be played by
instances of the
Person object
type). A role
name may be
added in square
brackets.
Binary fact type
By
default,
predicate
readings
(binary or
longer)
are read
left-to-
right or
top-to-
bottom.
An arrow-
tip is
used to
display a
different
reading
direction.
Role
names
may be
displayed
in square
brackets
beside
their role.
Forward
and
inverse
readings
for
binaries
may be
shown
together,
separated
by /.
Ternary fact type
Role names
may be
added in
square
brackets.
Arrow-tips
are used to
reverse the
default left-
right or top-
down
reading
order.
Reading
orders other
than forward
and reverse
are shown
using named
placeholders.
Quaternary fact type
The above
notes for the
ternary case
apply here
also. Fact
types of
higher arity
(number of
roles) are
also
permitted.
Objectification
The
enrolment
fact type is
objectified as
an entity type
whose
instances
can play
roles. In this
example, the
objectification
type is
independent,
so we can
know about
an enrolment
before the
grade is
obtained.
Internal uniqueness constraint
(UC) on unary
These
examples are
equivalent.
By default,
fact types are
assumed to
be populated
with sets of
facts (not
bags of
facts), so no
whole fact
may be
duplicated.
Internal UCs on a binary fact type The
examples
show the 4
possible
patterns: 1:n
(one-to-
many); n:1
(many-to-
one); m:n
(many-to-
many); 1:1
(one-to-one)
Internal UCs on
ternaries
The first
example has
two, 2-role
UCs: the top
UC forbids
ties; the other
UC ensures
that each
team gets
only place per
competition (a
dotted line
excludes its
role from the
UC). The
second
example has
a spanning
UC (many-to-
many-to-
many). For an
n-ary (n > 2)
fact type to be
atomic, each
UC on it must
span at least
n-1 roles.
Simple mandatory
role constraint
The example
constraint
means that
each person
was born in
some country.
The mandatory
role dot may be
placed at either
end of the role
connector.
Inclusive-or
constraint
An inclusive-or
constraint is
also called a
disjunctive
mandatory role
constraint. The
constraint is
displayed as a
circled dot
connected to
the constrained
roles. The
example
constraint
means that
each visitor
referenced in
the model must
have a passport
or a driver
licence (or
both).
Preferred internal UC
A double bar
on a UC
indicates it
underlies the
preferred
reference
scheme
External UC
A double-bar
indicates that
the constrained
roles provide
the preferred
reference for
the object type
at the other
end. Here,
each state is
primarily
identified by
combining its
country and
state code.
Each
combination of
country and
state name
also applies to
only one state.
Object type value constraint
The allowed
values may
be specified
as a list of
discrete
values and/or
value ranges.
The two
examples
shown
opposite
specify an
enumerated
list of values.
Ranges are
inclusive of
end values
by default.
Round
brackets are
used to
exclude an
end value.
Square
brackets may
be added to
explicitly
declare
inclusion, e.g.
the constraint
on
PositiveScore
may also be
specified as
{(0..100]}.
Multiple
combinations
may also be
specified.
Role value constraint
As for
object type
value
constraints,
but
connected
to the
constrained
role. Here,
an age of a
person
must be at
most 140
years.
Subset constraint
The arrow
points from
the subset
end to the
superset end
(e.g. if a
person
smokes then
that person
is cancer
prone). The
role
sequences
at both ends
must be
compatible.
A connection
to the
junction of 2
roles
constrains
that role pair.
Join subset constraint
The
constrained
role pair at
the
superset
end is
projected
from a role
path that
involves a
conceptual
join on
Language.
The
constraint
declares
that if an
advisor
serves in a
country
then that
advisor
must speak
a language
that is often
used in that
country.
Exclusion constraint
These
exclusion
constraints
mean that
no person is
both married
and
widowed,
and no
person
reviewed
and
authored the
same book.
Exclusion
may apply
between 2
or more
compatible
role
sequences,
possibly
involving
joins.
Exclusive-or constraint
An
exclusive-or
constraint is
simply the
conjunction
of an
inclusive-or
constraint
and an
exclusion
constraint.
Also known
as an xor
constraint.
Equality constraint
This equality
constraint
means that
a patient s
systolic BP
is recorded
if and only if
his/her
diastolic BP
is recorded.
An equality
constraint
may apply
between 2
or more
compatible
role
sequences,
possibly
involving
joins.
Derived fact type, and
derivation rule
A fact type
is either
asserted,
derived, or
semiderived.
A derived
fact type is
marked with
an asterisk
*. A
derivation
rule is
supplied. A
double
asterisk **
indicates
derived and
stored
(eager
evaluation).
Semiderived fact type, and
derivation rule
A fact type
is
semiderived
if some of its
instances
may be
derived, and
some of its
instances
may be
simply
asserted. It
is marked by
+ (half an
asterisk).
++indicates
semiderived
and stored
(eager
evaluation
for derived
instances).
Subtyping
All subtypes
are proper
subtypes. An
arrow runs from
subtype to
supertype. A
solid arrow
indicates a path
to the subtypes
preferred
identifier (e.g.
here, student
employees are
primarily
identified by
their employee
number). A
dashed arrow
indicates the
supertype has
a different
preferred
identifier.
Subtyping constraints
A circled X
indicates
the
subtypes
are
mutually
exclusive. A
circled dot
indicates
the
supertype
equals the
union of the
subtypes.
The
combination
(xor
constraint)
indicates
the
subtypes
partition the
supertype
(exclusive
and
exhaustive).
Subtype derivation status
A subtype
may be
asserted,
derived
(denoted by
*), or
semiderived
(denoted by
+). If the
subtype is
asserted, it
has no mark
appended
and has no
derivation
rule. If the
subtype
derived or
semiderived,
a derivation
rule is
supplied.
Internal frequency constraint
This
constrains
the number
of times an
occurring
instance of
a role or
role
sequence
may
appear in
each
population.
Here: each
jury has
exactly 12
members;
each panel
that
includes an
expert
includes at
least 4 and
at most 7
experts;
each
expert
reviews at
most 5
papers;
each paper
that is
reviewed is
reviewed
by at least
2 experts;
and each
department
and year
that has
staff
numbers
recorded in
the
quaternary
appears
there twice
(once for
each
gender).
External frequency constraint
The
example
external
frequency
constraint
has the
following
meaning. In
this context,
each
combination
of student
and course
relates to at
most two
enrolments
(i.e. a
student
may enroll
at most
twice in the
same
course)
Value-comparison constraint
The
example
value-
comparison
constraint
verbalizes
as: For
each
Project,
existing
enddate >=
startdate.
Object cardinality constraint'
The
example
constraints
ensure
there is
exactly one
president
and at most
100
senators (at
any given
time).
Role cardinality
constraint
The example
constraint
ensures that at
most one
politician is the
president (at
any given time).
Ring constraints
E.g.
A ring
predicate R is
locally
reflexive if and
only if, for all x
and y, xRy
implies xRx.
E.g. knows is
locally but not
globally
reflexive.
Reflexive,
symmetric
and transitive
properties
may also be
enforced
using
semiderivation
rather than by
constraining
asserted fact
types.
The example
constrains the
subtyping
relationship in
ORM to be
both acyclic
(no cycles can
be formed by
a chain of
subtyping
connections)
and strongly
intransitive
(no object
type A can be
both a direct
subtype of
another type
B and an
indirect
subtype of B,
where indirect
subtyping
means there
is a chain of
two or more
subtyping
relationships
that lead from
A to B).
Ring
constraints
may be
combined only
if they are
compatible,
and one is not
implied by the
other. ORM
tools ensure
that only legal
combinations
are allowed
Deontic constraints
Unlike
alethic
constraints,
deontic
constraint
shapes are
colored
blue rather
than violet.
Most
include o
for
obligatory.
Deontic
ring
constraints
instead use
dashed
lines.
In the
parenthood
example,
the alethic
frequency
constraint
ensures
that each
person has
at most two
parents,
the alethic
ring
constraint
ensures
that
parenthood
is acyclic,
and the
deontic
ring
constraint
makes it
obligatory
for
parenthood
to be
strongly
intransitive.
Textual constraints
Textual
constraints
are also
known as
ad hoc
constraints.
First-order
constraints
with no
graphic
notation
may be
expressed
textually in
the
FORML 2
language.
These
examples
use
footnoting
to capture
a restricted
uniqueness
constraint
and a
restricted
mandatory
role
constraint
Objectification display
options
Internally, link
fact types
connect
objectified
associations to
their
component
object types.
By default,
display of link
fact types is
suppressed. If
displayed, link
predicate
shapes use
dashed lines
instead of
solid lines.
Objectification
object types
may also be
displayed
without their
defining
components,
using an
object type
shape
containing a
small
predicate
shape, as
shown in this
Enrolment
example.
Resources Top Previous Next
The following are links to sites that provide more information on
Object Role Modeling:
Site Link
Object Role
Modeling -
Overview and
papers by Dr
Terry Halpin
http://www.orm.net
The ORM
Foundation -
Papers and
user community
dedicated to
ORM
http://www.ormfoundation.org
The Fact-
Based
Modeling
Working Group
- A group
dedicated to
the
standardisation
of Fact-Based
Modeling.
http://www.factbasedmodeling.org
Wikipedia
article on
Object Role
Modeling
http://en.wikipedia.org/wiki/Object-
role_modeling
Glossary Top Previous Next
The following is a glossary of the terms that you may find in this
help.
NB Those terms that are specific to FactEngine are marked "[Term]
is a term used by FactEngine" (e.g. Model Element).
Term Description
Emptying (a
Model)
Boston uses the term, 'Emptying', to describe the
process of programmatically removing all the
Model Elements from within an ORM Model. The
end result is an ORM Model purged of all Model
Elements, or an 'Empty' ORM Model. i.e. Models
may exist with no Model Elements, and all ORM
Models within Boston begin their existence with no
Model Elements.
Entity Type Represents a conceptual or physical type of thing.
Fact Type Represents the relationship between Entity Types,
Value Types and/or Objectified Fact Types.
Internal
Uniqueness
Constraint
A Role Constraint that is limited to expressing the
uniqueness of values of the Roles it spans and
where those Roles are all within the one Fact
Type.
Lexicon A reference book containing an alphabetical list of
words with information about them.
Meta Means describing
Metadata Describing data (sometimes: self describing data).
The type system is called metamodel
Metalevel The elements of the meta-level (the meta-objects)
describe the objects on the base level
Metamodeling Description of the model elements/concepts within
a Model.
Model Element Any symbol that is used to describe or display a
Model.
e.g. Entity Types, Value Types, Fact Types, Role
Constraints, Model Notes are all Model Elements
of an ORM Model.
Facts and Values are also Model Elements of an
ORM Model.
Role Names are Model Elements of an ORM
Model.
Model Element is a term used by FactEngine.
Objectified Fact
Type
A Fact Type the instances of which are considered
the instances of a conceptual type of thing.
Predicate A logical predicate. e.g. 'Part is in Bin in
Warehouse' is a predicate.
Role Part of a Fact Type that is a placeholder for the
Object Type that it joins, within the Predicate of a
Fact Type.
Role Constraint A Model Element that defines a constraint across
one or many Roles.
UOD
Universe Of Discourse
Value Type A named list of objects. e.g. 'Integer' is a Value
Type.
Total Internal
Uniqueness
Constraint
An Internal Uniqueness Constraint that spans all
the Roles of a Fact Type
McAfee Antivirus Troubleshooting
If you have problems installing Boston it may be because of McAfee
Antivirus if you have that installed on your PC. In this case you will
need to Whitelist the Boston executable with McAfee Antivirus.
1. There is a windows Security setting called "Potentially unwanted
app blocking" (Protect your device from low-reputation apps that
might cause unexpected behaviors.)
McAfee will change that setting from On to Off when you white list
the executable file. You then need to dismiss that warning by
confirming with Windows that you intended to do so.
You can find out more information from the McAfee website at: How
to exclude files from virus scans on Windows or macOS
Reinstalling Boston
If you plan to reinstall Boston your Boston database file is left in the
following directory: C:\ProgramData\FactEngine\Boston (under a
sub directory of this directory) I.e. You can uninstall Boston and
reinstall without deleting you Boston database and all your models.
Fully uninstalling Boston
To completely uninstall Boston from your computer, make sure to
delete the following folder from your Windows machine:
C:\ProgramData\FactEngine
WARNING: This folder contains the Boston database and other files
used by Boston. Only remove this folder if you are sure you want to
delete the Boston database and all your models created in Boston.
