Design Concepts

DRAFT

Developing with any technology is easier when you have a clear understanding of the theory and concepts behind the actual device. TejonDBT is a NoCode database, so you don’t have to learn a the syntax of a programming language, however, mastering the theory and concepts of TejonDB is necessary for your success as a designer. 

As an Object / Relational / Graph / BI database, TejonDB merges concepts for these three technologies: 

• Object oriented - objects are organized by classes with full inheritance.
• Relational - all data is accessible and updatable using normal SQL.  
• Graph - objects may be flexibly connected to other objects.
• BI - data may be analyzed by class, status, history, and dimensions.

This section is designed to walk through the theory and concepts assuming that you have little or no experience with database design and programming. It covers concepts at a high level without getting into the details of how to configure them in the Configuration Studio. Other articles in this section explain the details of using the Configuration Studio.

Objects and Classes

Every noun (person, place, or thing) can be represented in TejonDB as an object.

An object is considered first-class data, which means that the object is a primary structure that can have a number of functions applied to it and may have several other pieces of data attached to it that further describes the object.

In a relational database system theses nouns would be considered rows (tuples), organized into tables (entities), and uniquely identified by primary keys. An object-oriented system would refer to these as objects or entities. In graph database theory these nouns are referred to as nodes.

Objects are organized into classes. The class defines the attributes, forms, states, connections, workflows, and permissions available to the objects within the class.

Because the typical end-user is non-technical, classes are called types by default in the end user application. (This label can be edited in the Configuration Studio)

Cooking is an excellent example of classes and objects. The basic definition of a class is that it’s a recipe for creating an item. For example, a cookie recipe defines how to make a cookie, but the recipe itself isn’t a cookie. The recipe can be used to create several cookies of the same type.

Recipe = class

Cookie = object

In technical terms, an object is an instance of a class. In the same way, a cookie is a single item baked from a recipe.

Just as it’s impossible to bake a cookie without a recipe (even if it’s a casual impromptu recipe), it’s impossible to create an object without it belonging to a class.

Inside TejonDB there are several types of classes. To differentiate classes that hold objects from other types of classes, this type of class sometimes referred to as an Object Class.

Note: As a rule within TejonDB, for clarity sake,

• Properties are design options that define the behavior of the database. e.g. Classes have properties. 
• Attributes are optional data (fields) that are added to data. e.g. Objects have attributes. 

Classes and Inheritance

Classes can be stand-alone classes without any association to other classes. However, most classes build upon other previously defined classes and are organized in a hierarchy, or tree, structure. In this case the new classes can pull from, or inherit, the definition of the previously defined class. This concept of inheritance is central to the core of TejonDB.

The phrase, "is a", is useful when designing class. If any object of a sub-class is also an object of a a super-class then it's probably a good fit for a super-class sub-class design. For example, a lion "is a" mammal so it's probably true that the lion class is a sib-class of the mammal super-class. 

When inheritance is defined between two classes, they are known as the super-class and the sub-class relative to one another. The sub-class automatically inherits all features that are configured for a super-class.

A class at the top of the hierarchy, without a super-class, is called a top-level class. TejonDB databases may have multiple top-level classes. A hierarchy tree with multiple top-level nodes is sometimes referred to as a forest style hierarchy.

In most object-oriented technologies, inheritance only applies to attributes and methods. In TejonDB, inheritance applies to every feature:

• Attributes (data fields)
• Object States (statuses)
• Forms (optional sets of attributes)
• Connections (object to object connections)
• Data Policies (rules to identify data exceptions)
• Workflow Events
• Permissions
• Type filter element
• Relational access (SQL)

Inheritance also applies when the user browses objects. By default, selecting a super-class includes selecting all the objects in all subclasses. 

A class can be set as an abstract class, which means it's only there for inheritance purposes and cannot itself be directly used by objects. Setting a class as abstract is useful for a top level class that has multiple sub-classes and every object should be in a sub-class. 

Because inheritance is the primary concept in nearly every feature in TejonDB, it’s critical to design the class structure carefully.

Multiple Inheritance

There are certain (uncommon) situations when a class needs to inherit from more that one super-class. TejonDB fully supports multiple inheritance. Any class can inherit from multiple other classes.

The classic example is a pet dog that needs to inherit from both the pet class, and the canine class. By defining the pet-dog class with both the pet super-class and the canine super-class, any object in the pet-dog class automatically includes all the features defined for both pets and a canines.

note: There are some class properties or behaviors that could potentially conflict when a class inherits from multiple super-classes. For these object class properties, the sub-class inherits that property as true if it is true for any super-class.

Object Multi-Class

More common that multiple inheritance i the need for a single object to belong to multiple classes. An object must belong to at least one class, but TejonDB allows an object to belong to several classes. A strict following of object-orientation would require that an object can only belong to one class, and that if the object would benefit from designs from multiple classes, the solution would be multiple inheritance. While multiple inheritance does solve some problems, there are many real-life situations where an object participates in multiple roles and classes, and defining every possible combination would be inefficient.

Object multi-class allows an object to belong to multiple classes, assign a state for each class, and log the full history of the object’s classes and states for every class.

If the object belongs to multiple classes, it can use all the features - all the states, state flows, attributes, forms, connections, and workflows - for every class it belongs to.

Mixing classes is sometimes illogical. An employee is not also a building. Therefore, by default, classes may not be mixed if one class has IsPerson = true, and the other class has IsPerson = false. This can be overridden if either class has MultiClassCompatiable set to true. 

Object Multi-Class is not configured by the designer. The users will select multiple classes for the object as needed. However, understanding how Object Multi-class works gives the database designer more freedom when designing the class structure.

Classes and States

In the real world, every person, place and thing moves through a flow of states, or statuses. For example, below is a possible state flow diagram for a university student.

Every object will be in one of those states for every class it belong to and the object’s state history is automatically logged in the database.

For every class, states and the possible flow from state to state, must be defined. 

States are very important to the design of the database. Connection rules and workflow triggers are based on the object’s class and state. Applying connections and workflow triggers based on states is one way that TejonDB eliminates the need for programming code.

Users can easily filter, browse, and analyze objects and their data based on class and state.

States have several properties that help define the behavior of TejonDB: 

Default State - When a new object is created, or a new class is aded to an existing object, the default state is normally the initial state. 

Inactive - a State that is flagged as inactive will be disabled in the browse selection until it is toggled on by the user. This is useful for automatically not including some states (e.g. deceased or Inactive) in user searches. 

State Flow Universal - an object may be set to this state without a pre-defined state flow path. This is useful for states that are outside a strict flow. 

Retired - an object may not be set to a state that is retired, but the object history of the state remains in the database.

States, and stateflow, is inherited just like attributes.

Attributes

An attribute is a field of data that describes or provides details about the object. Classes, forms, and connections may have attributes. Attributes may be 

Attributes typically apply only once and are not repeated. For example, a person has only one birthdate and one place of birth.

All Objects have common columns (ObjectCode, LegacyCode, Name, source code, audit data).

Some sets of attributes are be added to a class with a single property:

• Person - if a class is defined as a "Person" class, then that class automatically includes first name, middle name, last name, nickname, title, and suffix. The advantage to using predefined person attributes is that TejonDB knows to use these attributes in the browse names column and include these in the QuickSearch. 
• Contact Data - enabling the "contact" feature automatically includes multiple addresses, phone numbers, and emails.   

Objects have all the attributes as defined by their class(es) and superclass(es).

Attributes can be data typed as character, memo, date, integer, numeric, binary, or lookup.The data type automatically determines the type of control used by the end-user application to display the attribute. 

Attributes can have the following properties:

• Searhable
• Static
• Immutable
• Default, min and max values (integer, numeric, date).
• Required
• Validation Type
• Mask
• Lookup to a defined domain class (with default item)
• Bit search Phrase

Dimensions

Objects are primarily classified by their class(es), however, dimensions are additional optional classifications.

The dimension is created as a dimension class, with it's own objects and attributes. The classes that use the dimensions use them as attributes with a Lookup Data Type. Therefore, the dimension only applies to objects belonging to classes with that lookup attribute. If an object has the dimension from multiple inherited classes or multiple times via object multi-class, the object will still only have that dimension once.  

Every Lookup attribute (dropdown list field) is also dimensions, which becomes a potential way that users can group or categorize objects. 

Dimensions have several properties or options: 

• Dimensions may require a pre-defined list, or allow users to add items on the fly.
• Dimensions may be a single list or a hierarchy.
• Dimensions may allow a single selection per object or multiple selections.
• Dimension history is saved for every object.
• Dimensions may have additional attributes that become read-only details for the selected item when displayed in the object.

Dimensions are used for selecting objects in the Browse and the user-defined Filter.

Dimensions with history may be displayed in the Object Timeline as selected by the user.

Dimensions are used in the BI charts to segment and analyze data.

Enterprise Edition: A Dimension can be used as part of a Team Permission. 

note: currently the Windows user interface is limited to a single dimension.

Forms

A form is an optional set of a data that can be applied to an object. The form describes the object or connection and is not a stand-alone object. One way to think of a form is to think of the object as a file folder and the form as an additional paper form that’s inserted into the object’s file folder.

As a rule of thumb, a form is a set of attributes that either all apply to the object or they all don’t apply.

Typically forms may be applied multiple times to the object or connection. For example a person may have multiple forms describing educational achievements or performance reviews.

A relational database designer would think of forms as a many-to-one relationship.

Connections

The relationships between objects are called connections. Every connection connects two objects. Any object can be connected to any other object depending on the connection meta-data. The connection type configuration defines the rules about which classes and states are permissible for each end-point of the connection.

In a relational database these connections would be called foreign keys or many-to-many relationships. In Graph database theory these connections are referred to as edges.

Every connection has start and end dates, and connections can also have attributes and forms, just like object classes.

When querying the database for objects connected to a specific object, a node-connection database lets you find every connection and every connected type of object regardless of the type of connection or the class of the connected object. This flexibility is a key benefit of

 

WorkFlow

A real-world operational database sees thousands of the same tasks repeated over and over. To improve the consistency of these commonly repeated tasks, TejonDB has a workflow system.

Triggers, based on common events, fire Workflow events, which fire common action.