TSER: A Conceptual Manual

• What is TSER?
• User/Application level views of TSER
• Modeling level views of TSER
• Implementation level views of TSER
• Example1-The Hospital Case
• Example2-The University Case
• TSER In a Nut Shell

What is TSER?

(Not all elements/functionalities are available in this version.)

Modeling Approaches:

1. TSER: Subject-Context Modeling (SER) --> (normalized) Entity-Relationship modeling (OER) --> DBMS Schema.
2. ERA: Entity-Relationship-Attribute modeling through OER --> DBMS Schema.
3. OODB: Object-Oriented modeling through SER --> either mapping directly to OODB schema, or mapping to OER, then to DBMS Schema.
4. DFD: Data Flow Diagramming --> SER (using data stores and data flows) through the built-in mapping process --> OER --> DBMS Schema.

Models Integration and Expansion:

1. Legacy Systems: reverse engineering into (separate) SER's --> integrator OER --> Metadatabase.
2. New systems using non-TSER: same as above.
3. New systems using TSER --> new SER modeling --> integrated with other OER's --> Metadatabase.
4. Extension: --> additional SER modeling --> integrate with other OER's --> DBMS Schema.

User/Application Level Views of TSER

To "picture SER", you probably should try the following perspectives:

1. Application: Consider a basic (non-decomposed) subject being a report, a form, or something corresponding to a (relational) view. On this basis, a subject can also be used to represent an application, application family, activity, or process that can be decomposed (in the manner of DFD/IDEF) into the basic subjects. In this sense, the subject is the exclusive carrier of data semantics while the context defines expressly the interaction rules of data flows among subjects. Thus, contexts are indeed semantic relationships of the semantic entities we now call subjects, except that we don't define data items in these relationship (but merely refer to them in the rules). A context can be compared to a process of DFD in terms of its contents. The subtle difference here is, of course, that a DFD is focused primarily on processes while an SER is anchored methodologically in subjects - this reflects our roots in databases as opposed to application software that DFD/IDEF0/Petri net are. It is also appropriate to use a subject as a universe relation. The single-subject hospital example shows this idea. The result (OER) is highly sensitive to the FD's that one formulates. The resulting OER is designed to be at least in Third Normal Form. The user might want to customize it for system performance purposes. If TSER does not perform acceptably in your cases, let us know. Then we might need to review the mapping algorithms and/or the input.
2. Object: consider a subject as an object in the object oriented paradigm. The main difference here would be the context. "Global rules" that involve data items from more than one subject (object) will be grouped into contexts. The design objective here is to expose these rules to modelers and users for: consolidation of interactive-object behavioral/knowledge modeling, rulebase design, and knowledge model adaptability.
3. Mixed: the above two perspectives can be combined to provide maximum flexibility for semantic data modeling (in the tradition of database design) and information modeling (in the tradition of systems analysis).  

A modeler could proceed along either of these two lines:

• talk to the users about the fixed end-user products of the intended database and model these products as subjects, and then use contexts to model some operating constraints/events/rules etc. for application software development - then to compose/aggregate/generalize them into higher level subjects if desirable; or  
• follow the tradition of structured system analysis and define an application subject for the entire application system, and then decompose from there until the end-user products are defined. In our examples, the banking case shows the first approach, and the CIM case the second. The hospital case has two versions, one shows the universe relation approach (single subject) and the other object-oriented. The project management case in the book, which uses DFD as the front end, shows the comparison of SER with DFD as well as the system analysis approach.

Modeling Level Views of TSER

• Modeling Approaches
  • Subject-Context Modeling
  • Entity-Relationship Modeling
  • Object-Oriented Modeling
  • Data Flow Diagramming
• Models Integration and Expansion
  • Legacy Systems
  • New Systems using non-TSER methods
  • New Systems using TSER
  • Extending existing systems
• TSER Constructs
  • Functional/Semantic Constructs
    • Subject
    • Context
  • Structural/Operational Constructs
    • Operational Entity (OE)
    • Plural Relationship (PR)
    • Functional Relationship (FR)
    • Mandatory Relationship (MR)

Modeling Approaches:

1. TSER: Subject-Context Modeling (SER) --> (normalized) Entity-Relationship modeling (OER) --> DBMS Schema.
2. ERA: Entity-Relationship-Attribute modeling through OER --> DBMS Schema.
3. OODB: Object-Oriented modeling through SER --> either mapping directly to OODB schema, or mapping to OER, then to DBMS Schema.
4. DFD: Data Flow Diagramming --> SER (using data stores and data flows) through the built-in mapping process --> OER --> DBMS Schema.

Models Integration and Expansion:

1. Legacy Systems: reverse engineering into (separate) SER's --> integrator OER --> Metadatabase.
2. New systems using non-TSER: same as above.
3. New systems using TSER --> new SER modeling --> integrated with other OER's --> Metadatabase.
4. Extension: --> additional SER modeling --> integrate with other OER's --> DBMS Schema.

The Two-stage Entity-Relationship (TSER) system is an information modeling CASE tool encompassing the following generic concepts: entity-relationship model, object-oriented paradigm, rule-based method and process representation, to support databases and rule-based systems design. Although TSER has its own unique design and methodology which can be used directly and independently, it is also compatible with three common perspectives of modeling that the user may choose to employ; all of which lead to the same data and knowledge capabilities that the system offers. These perspectives are:

• Entity-Relationship: The user considers the information model as mainly consisting of (high-level, semantic) entities and behaviors. The difference with the traditional E-R model is that the user does not further separate entities from relationships nor defines their types, at the user-oriented modeling stage (the first). The system will later determine these definitions using all of the semantics provided and normalize the semantic entities into structural entities and relationships according to the dependency theory (the second stage). The behaviors are represented using production rules, where those which are internal to the entities are embedded therein and those which are external (i.e., involving multiple entities) are grouped accordingly and exposed independently. The TSER construct SUBJECT is used for the semantic entities and the construct CONTEXT for external behaviors. The other two basic TSER constructs, ENTITY and RELATIONSHIP, are, in this perspective, used by the system at the second stage.
• Object-Oriented: The user considers the information model in terms of objects and behaviors. TSER supports the modeling of objects in the same way as called for by the O-O paradigm, except that it offers two additional features. First, the user may choose to separate out the external behaviors (such as control/information flows and other contextual knowledge that interact different objects) and expose them for global representation and management. Second, the user may choose to have these objects normalized by the system (at the second stage) and thereby relax the concerns of data structure design at the semantic modeling stage (the first). SUBJECT represents objects in this perspective and CONTEXT models external behaviors (internal rules are embedded into objects).
• Process-Activity: The user considers the information model as made up with activities and information flow/work flow controls. Compared to functional modeling techniques such as Data Flow Diagram and IDEF0, activities via TSER have the choices of associating data resources with the processes that use them (or associating the processes with the data resources that they need) into a neat encapsulation unit , using SUBJECT. The contextual knowledge concerning the flows among activities need not be forced into any single activity but globally exposed and modeled through CONTEXT. (Utilities are provided in TSER to translate DFD into SUBJECT and CONTEXT). After this stage, activities are normalized into ENTITY and RELATIONSHIP (the second stage).

TSER Constructs

The Functional (Semantic) Modeling Constructs

The first stage features user-oriented semantic-level constructs for object-hierarchy and processes representation. They are used for system analysis and information requirements modeling; referred to in TSER as the Functional (or SER) Level Modeling Constructs; and employed exclusively for capturing semantics.

Subject: Primitives: Contains data items (attributes), functional dependencies (among data items), intra-SUBJECT rules (triggers, events, and dynamic definitions of data items belonging to a single SUBJECT), and association hierarchies (explodes as well as generalizes and aggregates SUBJECTs). Specific types of association include : classification (single and multiple inheritance and mandatory relationships), grouping (partial and function-defined inheritance and functional relationship) and process (no inheritance and no integrity implications on information management).

Description: Represents functional units of information such as user views and application systems, and is analogous to frame or object.

Context: Primitives: Contains inter-SUBJECT rules (characterized by references to data items belonging to multiple SUBJECTs), typically includes directions of flows for logic (decision and control) and data (communication, etc.). It is allowed to contain only descriptive rules used for holding together a set of SUBJECTs or SER models that otherwise do not have direct associations.

Description: Represents interactions among SUBJECTs and control knowledge such as business rules and operating procedures and is analogous to process logic.

Note:

(1) The full contents (as applicable) must be specified for all SUBJECTs at the leaf level of the SUBJECT hierarchy. The class hierarchy implies integrity rules for applications, but its presence is not required.

(2) Rules are constructed in the form of (a subset of) predicate logic where all clauses must only consist of the logical operators and the data items that have been declared or defined in the SUBJECTs (except for certain key words such as do and execute.). A data item may be defined to represent an executable routine, algorithm, or mathematical expression.

(3) The three types of association of Subjects may exist simultaneously in a model and thereby create three abstraction plains for Subjects; namely, (i) generalization and strong aggregation (the classification type), (ii) ad hoc aggregation (the grouping type), and (iii) simple decomposition similar to Data Flow Diagram and IDEF (the process type).

The Structural (Normalized) Modeling Constructs

The second stage is concerned with providing a neutral normalized representation of data semantics and production rules from functional model for logical database design; and referred to in TSER as the structural (or OER) model. There are four basic constructs described below.

Operational Entity (OE): Description: Entities; identified by a singular primary key and (optional) alternative keys and non-prime attributes, and implies Entity Integrity : no component (attribute) of a primary key may accept null value, and no primary key (as a whole) may accept duplicate values.

Plural Relationship (PR): Description: Association of entities; characterized by a composite primary key and signifying a many-to-many and independent association, and implies Associative Integrity : each of the PK's component attributes must be a PK of some Entity and its values in the PR must match that in the Entity.

Functional Relationship (FR): Description: A many-to-one association that signifies characteristic traits or composition relationships (corresponding to the grouping type of association of SUBJECTs). FRs represent the referential integrity constraints implied by the existence of foreign keys.

The arrow side is called the determined side and points to either an OE or a PR, while the other side is called the determinant and is also linked to either an OE or a PR. The primary key of the determined side is included as a non-prime attribute (i.e., a foreign key) of the determinant side. Referential Integrity : the value of every foreign key in the determined must either be null or be identical to some PK value in the determinant.

Mandatory Relationship (MR): Description: A one-to-many fixed association of OEs that signifies derived and inheritance relationships (corresponding to the classification type of association of SUBJECTs). MRs represent the existence-dependency constraint, and are symbolized as a double diamond with direction.

The "1" side is linked to the owner OE while the arrow side points to the owned OE. Existence Dependency : when the owner instance is deleted, then all owned instances associated will it must also be deleted; and there is a foreign key implied in the owned whose value must match exactly the owner's PK value.

Note:

(1) In both top-down design and reverse engineering, the structural model is typically derived automatically from the functional model by using the TSER normalization and mapping algorithms.
(2) While there usually are multiple functional models representing different views or application systems of an enterprise model, there always exists only one integrated structural model for the global system.

In sum, underlying these constructs at both stages are two types of primitives: data items and predicate logic. Therefore, the basic structure of TSER metadata is characterized by (1) data representation as relations, (2) knowledge representation in the form of production rules, and (3) the two representations being tied via data items.

Modeling using the TSER constructs:

There are two ways a data modeler might want to use TSER to model entities and relationships; one is by using the (OER) Entity-Relationship diagram and the other is using the higher level (SER) Subject-Context diagram. There are outlined below.

1. Using the OER: The definition incorporates cardinality and semantic constraints in this way. There is one type of entity and there are three types of relationships. The entity is defined by a singular key, while the relationships define (1) Plural Relationship (many-to-many) between/among entities, (2) Functional Relationship (many-to-one) between entities, and Mandatory Relationship (one-to-many). One-to-one will be defined as MR if the association is fixed, otherwise FR. MR includes, but are not limited to, the original ER modeling concept of "weak entity"; it signifies fixed association and thereby differenciates it from a mere reverse expression of many-to-one (which will be considered as an FR with the arrow pointing to the one-side). PR's have real data structures (plural keys, with or without additional attributes), but FR's and MR's are integrity constraints, when implemented into a schema.

Once an OER diagram is created, save it. Then, create an application subject to represent the whole model and define each and every data item in it, resulting in a single subject SER model. Save it. You are ready to use a schema generator to create a database design now. The data structures and integrity rules will all be included in the schema for actual implementation.

2. Using the SER: There are two types of information you can model at this level; data (along with semantic constraints) and (business/operating) rules. The first is modeled in Subject, and the second both Subject and Context. For data, you define functional dependencies to specify their semantical relationships. As explained - and illustrated with examples - in the online Help (under the heading "functional dependency"), there are a few ways to model cardinality and other relationships.

"->" implies many-to-one;

"<->" one-to-one, and

"<<-" fixed one-to-many (MR).

In addition, the LHS can be singular or multiple items; thus, a way to model MVD (or many-to-many without dependent attributes) is to group them and specify an (trivial) one-to-one FD for it such as

(a,b) <-> (a,b) when a many-to-many b.

A Subject in this approach represents a view, an application, a form, a report, and so on, thus the user does not have to be asked to specify entities and relationships in the way they do with the ER model. The Subjects will be further linked thru Contexts either horizontally (like in DFD) or hierarchically (in an O-O manner), or combined; and the horizontal model can be aggregated up or decomposed down. If you stop here, save the diagram, and then map it to OER to automatically create a normalized ER diagram. You can map more than one SER diagrams/files at one time and they will be consolidated into one OER. Save it as a file. At this point, you can create a DBMS schema as above. (Note, the schema generator assumes both SER and OER files.)

3. Modeling Rules using TSER: If you want to specify business/operating rules, then use SER. A rule can be entered into either a Subject or a Context, depending on whether or not the data items involved in the rule belonging to the same single Subject. If not, then it populates a Context that link all Subjects taking part in the rule. These rules are/can be automatically implemented in some DBMS (e.g., Oracle v.7), but mostly they are only recorded in the application schema or some manual implementation. They are populated into the metadatabase that consolidates all information models for an enterprise, though.

Implementation Level Views of TSER

The four types of OER (structural) constructs define four types of integrity rules. They are always included in the suggested schema that TSER produces. Whether or not these rules can be automatically created by TSER for implementation into a database, however, depends on the integrity control facilities provided in the DBMS. In latest systems, the key integrity rules (Entity and PR) are commonly available and TSER is able to incorporate them for the schema generators provided. Referential integrity (FR) and existence rules (MR), on the other hand, are not automatically implementable yet in most cases. As you know, even Oracle v7 that provides triggers (and nominal referential rules) has some basic difficulty in this implementation. At this point, we do what the DBMS's have to offer in their standard facility. When the rule implementation/creation capability is developed (see #2 above), we'd be able to implement all integrity rules and more into the schemas.

Example 1: A Simple Hospital Example

The basic mechanism of TSER is illustrated in a simple hospital information system where all information resources are put into one subject. The semantics of these data items are represented using the concept of Functional Dependency, which defines the determinent data item(s) on which certain other item(s) uniquely depends - the latter being clustered around, derived from, or identified by the former. An example is that patient-ID determines ("-->") patient address and date-of-birth. Note that neither address nor date-of-birth determine (or uniquely identify) patient-ID since there could be multiple patients who have the same address or date-of-birth. Similarly, the combination of patient-ID, surgeon_ID and Date-of-surgery determines a unique surgery, but the individual elements of this group on their own do not.

In this first example, a hospital is modeled from the perspective of surgeries performed on patients, and hence a single subject (SER) of surgery is formed in the first stage. The system then determines a primary key for the subject and decomposes it into basic entities and relationships (OER) according to the dependency theory of data normalization; this is the second stage. An Oracle schema is generated for the OER model afterwards. The SER, OER and the Oracle schema generated for this model are given in figures A,B and the table 1, respectively.

Fig. A: The single-subject SER model for the hospital

Fig. B: The OER model for the hospital

Table 1: The Oracle schema definitional statements for the hospital

SET AUTOCOMMIT ON;
REMARK RELATIONS FOR OEs

CREATE TABLE date_surg
(date_surg CHAR(10) NOT NULL);

CREATE TABLE p_number
(p_num CHAR(10) NOT NULL,
p_add CHAR(60),
p_name CHAR(30));

CREATE UNIQUE INDEX p_numberNDX ON p_number
(p_num);

CREATE TABLE s_number
(s_num CHAR(10) NOT NULL,
s_name CHAR(30));

CREATE UNIQUE INDEX s_numberNDX ON s_number
(s_num);

CREATE TABLE po_drug
(po_drug CHAR(20) NOT NULL,
side_effect CHAR(30));

CREATE UNIQUE INDEX po_drugNDX ON po_drug
(po_drug);

REMARK RELATIONS FOR PRs

CREATE TABLE p_surgery
(date_surg CHAR(10) NOT NULL,
p_num CHAR(10) NOT NULL,
s_num CHAR(10) NOT NULL,
po_drug CHAR(20),
surgery CHAR(30));

CREATE UNIQUE INDEX p_surgeryNDX ON p_surgery
(date_surg, p_num, s_num);

REMARK ASSOCIATE CONSTRAINTS
REMARK Value of attribute date_surg in p_surgery relation must match
REMARK Value of primary key date_surg in date_surg relation
REMARK Value of attribute p_num in p_surgery relation must match
REMARK Value of primary key p_num in p_number relation
REMARK value of attribute s_num in p_surgery relation must match
REMARK Value of primary key s_num in s_number relation
REMARK EXISTENCE DEPENDENCY CONSTRAINTS:
REMARK REFERENTIAL INTEGRITY CONSTRAINTS
REMARK Every value of the foreign key po_drug in p_surgery relation must
REMARK either be null or match some value of the primary key
REMARK of the po_drug relation.
REMARK ORACLE SCHEMA HAS COMPLETED

SET AUTOCOMMIT OFF;

Example 2: A University Information System

Table 2: Details of the University SER Model

Here are some details of the above University SER model. These are representative examples and not all details relating to SUBJECTs/CONTEXTs (e.g., inheritance) are presented.

SUBJECT NAME: University

DESCRIPTION:University Information System
CHILD SUBJECTS: Administration, Research, Education

SUBJECT NAME: University

DESCRIPTION:University Information System
CHILD SUBJECTS: Administration, Research, Education

SUBJECT NAME: Education

DESCRIPTION: Information System for University Education
PARENT SUBJECT: University

SUBJECT NAME: Student

DESCRIPTION: Student Information
PARENT SUBJECT: Education
DATA ITEMS: STUD_NO, STUD_NAME, ADDRESS, DOB, TELEPHONE, ADVISOR, COURSE_NO, CREDITS, TERM, GRADE, CLASS_YR
FDS: STUD_NO -> STUD_NAME, ADDRESS, DOB, TELEPHONE, ADVISOR
(STUD_NO, COURSE_NO) -> TERM, CREDITS, GRADE
RULES: IF((CLASS_YR = 2) AND (Total_Credits(STUD_NO) <30))

THEN Request_Record_Verification(STUD_NO) ;
PROCEDURE/FUNCTIONS: Total_Credits, Request_Record_Verification

SUBJECT NAME: Course

DESCRIPTION: Course Information
PARENT SUBJECT: Education
DATA ITEMS: COURSE_NO, COURSE_NAME, PRE-REQ, CREDITS, TERM
FDS: COURSE_NO, TERM -> CREDITS
(COURSE_NO, PRE_REQ) -> (COURSE_NO, PRE_REQ)
COURSE_NO -> COURSE_NAME
ITEM EQUIVALENCE: COURSE_NO = PRE_REQ (In Domain)

SUBJECT NAME: Teacher

DESCRIPTION: Teacher Information
PARENT SUBJECT: Education
DATA ITEMS: STAFF_ID, STAFF_NAME, COURSE_NO, OFFICE, TELEPHONE
FDS: STAFF_ID -> STAFF_NAME, OFFICE, TELEPHONE
RULES: (STAFF_ID, COURSE_NO) -> (STAFF_ID, COURSE_NO)

SUBJECT NAME: Building

DESCRIPTION: Campus Buildings and Rooms
PARENT SUBJECT: Education
DATA ITEMS: BUILDING_NAME, ROOM_NUMBER, ROOM_TYPE, CAPACITY, NUM_OF_ROOMS
FDS: ROOM_NUMBER -> BUILDING_NAME, ROOM_TYPE, CAPACITY
BUILDING_NAME -> NUM_OF_ROOMS
ITEM EQUIVALENCE: Building.ROOM_NUMBER = Teacher.OFFICE

CONTEXT NAME: Univ_IS

DESCRIPTION: Context relating Administration, Research and Education
SUBJECT LINKS: Administration (<->), Research (<->), Education (<->)

CONTEXT NAME: Registration

DESCRIPTION: Student-Class Registration
SUBJECT LINKS: Student (<->), Course (<->), Teacher (<->)
RULES: IF((Request_Registration(STUD_NO, COURSE_NO) AND Course_Taken(STUD_NO, COURSE_NO)) AND (Passing_Grade(STUD_NO, COURSE_NO))), THEN Reject_Request(STUD_NO, COURSE_NO);
PROCEDURE/FUNCTIONS: Request_Registration, Course_Taken, Passing_Grade, Reject_Request

CONTEXT NAME: Scheduled

DESCRIPTION: Student-Class Registration
SUBJECT LINKS: Course (<->), Building (->)
RULES: IF((Request_Registration(STUD_NO, COURSE_NO) AND Course_Taken(STUD_NO, COURSE_NO)) AND (Passing_Grade(STUD_NO, COURSE_NO))), THEN Reject_Request(STUD_NO, COURSE_NO);
PROCEDURE/FUNCTIONS: Request_Registration, Course_Taken, Passing_Grade, Reject_Request

CONTEXT NAME: Residence

DESCRIPTION: Student-Class Registration
SUBJECT LINKS: Building (->), Teacher (<->)

In a nut shell, the SemanticER can be used most easily this way: the Subject is either comparable to Object (in the OO personality) or to Form/application (in a trational requirements analysis methodology). The Context, on the other hand, can be compared to Process which Input/output or these forms/applications and thereby interact plural Subjects. All logic and constraints of the process are represented in production rules in the Context. Rules/triggers can also be included in the Subject if they pertain only to the subject. Functional dependencies are then declared for the data items included in each Subject. The system normalizes (at the level of BCNF with integrity rules) these Subjects into OperationalER. Thus, the resulting ER (in four types: Entity and three Relationships) is comparable to the (final refinement of the) traditional ER which follows some rigorous discipline to ensure relational soundness. The SemanticER does not bear direct resemblance to traditional ER, while OperationalER does. Two of the three Relationships are pure integrity representations (one-to-many and many-to-one) relating Entities and the (Plural) Relationship (many-to-many).