The ERA Data Model: Entities, Relations and Attributes

1. Specifies each Attribute (property or data field) by its Data Type or permitted set of values. Specifies each Entity, Class or Record type in terms of its component attributes, data members or fields, respectively. Specifies each Relation type in terms of its component Entity Types or Classes. Three important questions: Can Relation components be nested relation instances? Can Relation instances have attributes or properties? Can an ERA Data Model be specified by a diagram? The ERA Data Model: Entities, Relations and Attributes

2. A set-theoretic abstract model: An N-ary Relation is a Set of relation instances. N is called the ‘arity’ or dimension of the relation. Each N-ary relation instance is an N-tuple (N-dimensional vector) which groups, associates, or relates one specific instance from each of the relation’s N component data types or classes. Example: Ternary relation R(x,y,z) relates elements of entity types X, Y, Z so it is a set of 3-tuples: {<x,y,z>} An algebraic model, with operations defined among its relation members: union, intersection, projection, (subset) selection; ‘joins’ of various types. Questions: What is ‘join’? What is ‘projection’? Relational Algebra

3. It must be possible to recognize whether a candidate N-tuple is a legal value of some particular N-ary relation. This set of legal values may be enumerated as a set of points and/or intervals, computed by an algorithm, or tested for membership by a logical predicate based on a set of rules. Examples: The relation from an offered Course to its (set of) Pre-requisite Courses is a tabulated multi-valued function. The Father to Son relation between two Persons must obey the constraint Sex=‘Male’ on any Person having the role of Father or Son. The relation isLengthOf(h, Vector(x, y)) must satisfy the Pythagorean Theorem (h2 = x2 + y2). Validating a Relation Instance

4. An Entity Type is a named, structured data type whose named components are called attributes, properties or fields. A Class extends an abstract data type by allowing multiple instances. A class extends an Entity Type by defining a set of methods or operations that can be applied to any class instance. Instances of a Class are called objects. Class methods may update values The value of an Entity or Class Instance is specified by assigning a value to each of its component attributes or data members. Each attribute has a data type which defines (and is defined by) its ‘Attribute Domain’ (set of legal values). An Entity Domain is [a subset of] the set-theoretic direct or Cartesian product of its attribute domains. Entities and Classes

5. We will use a vector notation to represent the value of an entity or object as an ordered list, sequence, or N-tuple of values of its attributes or data members. This avoids the redundancy of listing N <name,value> pairs which a pure set-theoretic notation requires. We can then represent a set of entity instances in a tabular format with one column per attribute, and one row for each instance of the entity type. An entity’s data type or class is independent of the relationships it may have with other entities. In OOP, a table is a container whose members are instances of its item’s Entity Type or Class. Entity Sets as Tables

6. The N-tuples of a Relation R(x,y,z) have values in the Direct Product space XxYxZ of its participating component domains. In other words, the value of any Relation is a subset of points in the direct product space of its components: Range(Relation(x,y,z))  Range(x) x Range(y) x Range(z) An N-ary relation is a set of N-tuples, each of which specifies or contains one instance of each of the participating entity types. Binary relations(N=2) are common. Ternary(N = 3) and higher relations are rare (Examples?) Relations are Sets of Points

7. A relation is characterized by its ‘arity’ N, which is the dimension of the relation as an N-tuple or vector of component entity types. Arity is independent of the types of entities in an N-ary relation. In practice, any or all participating instances may be represented as reference types instead of value types. Dimension or Arity

8. Two other properties must be specified for each of the N component entity types in the relation: (1) The entity’s multiplicity or cardinality (the min and max number of relation instances in which it may occur). (2) The entity’s role or semantic meaning (how it is used, its meaning or significance in the relation). Role and Multiplicity

9. Multiplicity is a [meta-] property of relations that counts the number of N-tuples in which a specific instance of the corresponding entity type can appear. Each N-ary relation has a defined set of N possible multiplicity [meta-]attributes. Each multiplicity attribute denotes the size or number of instances in the projection of the relation (as a set of points) on a single component of the N-tuple. This is the number of instances of one entity type/role that can be related to one tuple of instance values for the N-1 other types/roles. Multiplicity (1)

10. Example: An arbitrary but specified instance of Person in the role of Father or Mother can be associated with ‘zero to many’ other persons in the role of Child. How should this range be specified? UML (Unified Modeling Language) is a proposed standard from the Object Management Group’s Analysis and Design Task Force (OMG/ADTF). UML uses [0..M] or [0..N] to denote this range of values. EIA/CDIF (CASE Data Interchange Format) is a standard for meta-models that capture software design information inside of CASE (Computer-Aided Software Engineering) tools. CDIF uses 0:M or 0:N to denote this range of values. Multiplicity Notations

11. What is the meaning of 0:M or [0..M]? The two symbols 0 and M are called the minmum and maximum cardinality, respectively, of the corresponding role in the relation. I call this the MinCard:MaxCard notation - RJL MinCard is called Optionality in many older notations. Traditional notations denote MaxCard pairs and Optionality in different ways: E.g. in a genealogical {Family, Person} data model, for the many-to-many relation [Parent] <----> [Child] MaxCard(Parent):MaxCard(Child) has the value 2:M : [Parent]<2--------------M>[Child] Mincard:MaxCard Notation (1)

12. Modern notation includes both MinCard and Max Card at each end of a binary relation. E.g., [Parent]<0:2--------------0:M>[Child] ( 0:2 because we assume children can be orphans.) When both MInCard and MaxCard are specified at each end, 2:M expands to 0:2::0:M in CDIF, or [0..1]:[[0..M] in UML. MinCard:MaxCard::Mincard:MaxCard is confusing (CDIF). [MinCard..MaxCard]::[Mincard:MaxCard] is better (UML). Mincard:MaxCard Notation (2)

13. UML uses Multiplicity where CDIF and earlier models use [Outer] Cardinality: UML uses [0..M] and calls it multiplicity; the CASE Data Interchange Format (EIA/CDIF) standard uses 0:M and calls it cardinality; both have the same meaning and denote the same interval range. 0 and M are called, respectively, the min and max cardinality or multiplicity. UML vs CDIF Notation(Multiplicity vs. Cardinality)

14. CDIF notation is more confusing when both minimum and maximum cardinality or multiplicity values are paired together for each end of a binary relation: If onlyMax-Card is specified, a one-to-many relation is diagrammed for example as: [Parent]2--------->M[Child] If Min and Max Cards are both specified a 1:M relation is denoted [e.g.,if orphans are identified]: 0:1::0:M in CDIF: [Parent]0:2------>0:M[Child] [0..1]:[0..M] in UML: [Parent][0:2]------>[0:M][Child] UML or CDIF: Which is better?

15. Multiplicity used to be called Cardinality, before the Unified Modeling Language of became a new de facto standard for the semantics of information metamodels. [Ref. 1] Booch/Rumbaugh/Jacobsen/Rational Corp. [Ref. 2] Object Management Group Analysis & Design Task Force. The rationale for the change of name was that the cardinality of each participating entity type/role is easily confused with the size of the relation itself: An N-ary relation is a set of N-tuples contained in the direct product of its N entity type/role components. Multiplicity vs. Cardinality

16. The multiplicity count can be fixed or variable. It is usually specified as a range or interval of integer values. E.g., [0..1], [1..1], [0..M], [1..M] M denotes an unspecified upper bound. [0..M] is equivalent to the regular expression exponent ‘*’; [1..M] is equivalent to the regular expression exponent ‘+’. Complex rules need algorithmic specifications: E.g., “the set of integers congruent to zero mod 3”; E.g., “the set of strings over alphabet V specified by grammar G ”. Complex rules can also be specified by a [meta-]data model which enumerates a set of valid values, intervals and/or data types. Multiplicity (2)

17. A ‘Role’ is a name for the way an entity participates in a Relation; a role name has an associated explanation or semantic meaning of the relation from this entity’s perspective. ‘Role’ is also a discriminator for multiple appearances of the same entity type at multiple positions within each N-tuple. An entity type may participate in a relation more than once, provided its ‘role’ differs each time: Manager is a specific role for some Employees; Husband, Father and Son are particular roles of (Male) Persons in Family relationships; Origin and Destination are particular roles of Node instances in the binary relation called Edge which, together with a set of Nodes, defines a digraph. Entities have ‘Roles’ in Relations

18. Let R(x, y) be a binary relation between two finite (co)domains or data types X and Y. R is defined assymetrically as a multivalued function or mapping (MVM) y = R(x) from Domain X to Range or CoDomain Y. R is defined symmetrically by its Characteristic Function, CFR: XxY --> {TRUE, FALSE}. CFR(x,y) is a Boolean expression which defines the exact subset of XxY for which R is TRUE. The rules defining the CFR are usually extensible at run-time: they supply a recognition rule or criterion for recognizing membership in R. Relations as Characteristic Functions

19. F = Domain Female; M = CoDomain Male. R = Relation HusbandOf from F to M Assume the relation is fully defined 1. Relation as Multi-Valued Function (MVF) y = R(x) is “y = HusbandOf(x)” (y  M). R(x) is generally multi-valued: Example: IsOrWasHusbandOf(y,x)?. In general, R maps X into PowerSet(Y). 2. Relation as Characteristic Function: CFR(y, x) is “IsHusbandOf(x, y)?”. CFR maps MxF into {TRUE, FALSE}. y  HusbandOf(x) iff IsHusbandOf(y, x) is True. Alternate way to write CFR: Y.IsHusbandOf.X. Example of MVF and CFR:

20. CFR(x, y) is often specified as a query on a database of retrievable facts: CFR(x,y) = “( (There exists a valid Marriage License between x and y) and (There exists no subsequent record of Divorce between x and y) )”. CFR as a Database Query

21. CFR has the advantages of symmetry and bilateral navigability (relation inverse exists): We can iterate over all members of R by using an SQL-style statement: “Select x from X, y from Y where CFR(x, y) == TRUE”. We can iterate over all y related to a given xo or over all x related to a given yo: “Select y from Y, x from X where x=xo and CFR(x, y) = TRUE”. “Select y from Y, x from X, where y = yo and CF(x,y) = TRUE”. Advantages of Characteristic Function Representation:

22. Let integer coordinates i = pk(xi) and j = pk(yj) index the elements of X and Y, and redefine CFR(x,y) as CFK(i,j) in {TRUE, FALSE}. Then members of R(x, y) correspond 1 to 1 with integer pairs or 2-D points where CFK(i,j) = 1. If x and y are two entity or record types in a database, the integer variables i and j play the role of primary keys on the Domain and CoDomain. Ref: 96f523 project on binary Join extension of chgen. Question:What if the relation is ternary (N=3)? Relations may represent a participating entity instance by reference, as a foreign key or fkey, whose value matches the pkey of the referenced object. Primary Keys as Indices

23. If ni >= 1 for all xi then each xi has exactly one related yij = R(xi), and the relation R(x,y) is, by definition, total(I.e., totally defined). If ni = 0 for at least one xi, then that xi has no related yij and the relation is, by definition, partial (i.e., its value is not defined for somex in its domain). The same reasoning applies symmetrically for the inverse relation Rinv(y,x). Partial vs. Total Relations

24. For each xi in X, let Yi be the subset of Y whose members are related to xi by some relation R(x,y). Yi has ni members iff xi is related to ni members of Y. Likewise for each yj there is a subset Xj of X whose members are all related to yj. Xj has mj members iff mj elements of X are related to yj. If ni > 1 for at least one xi then this relation is a multivalued (generalization of) a function. Do not call it a function unless you explicitly identify it as multivalued. Relations Are Multi-valued

25. If the size of relation R(X, Y) is ‘small’ compared to the size M*N of the direct product XxY, the relation is called sparse (a small number of matrix elements have a non-zero value). A sparse matrix can be efficiently represented as a list of ordered pairs of related elements <x, y>. Note that this list can be in row-major order or column-major order, but not both at the same time. If instances of X and/or Y are large in size (I.e. many scalar property values are needed to specify an instance of either type), then R is more efficiently represented as a set of pairs of references <x*, y*> to elements of X and Y. Example: the set of all road segments which directly join two towns or road intersections on a map. Sparse Matrix Representation

26. The Edge set E of a directed graph or digraph is a binary relation on its Node set N. Questions: What are the Co-Domains? Can E be a ternary relation? How is the Edge matrix defined? When is E a sparse or dense relation? Can an Edge relate a Node instance to itself? Can an undirected graph be a special case? What predicate constrains a digraph to be a DAG (directed acyclic graph)? Directed Graph Example

27. A binary relation is a set of ordered pairs, and a subset of a direct product (DP) of the two sets of instances which it pairwise relates. Example: IsMarriedTo(man, woman) is a subset of the direct product of all pairs in Male x Female. This relation is sparse, not dense. It has an inverse relation IsMarriedTo(woman, man). The inverse (in this case) has the same name but a different argument type sequence or signature (I.e. it is polymorphic). The rules for membership in Male, Female and IsMarriedTo must be defined very precisely. Question: State alternate possibilities for these rules? Binary Relations as Subsets

28. Every C-struct, every C++-class ‘with state’, and every record declaration declares a composite or stuctured data type to represent entity instances. This type is also a relation over the direct product set of its M >= 1 ‘member’ or component data types. Every variable of a composite type must have a value that is an M-tuple of values, one from each if its component types (including reference types). Each instance of an entity class or type must also be a tuple of values belonging to its respective member data types. Structured or Composite Data Types as Relations

29. Computer-aided design programs (e.g., CASE tools) use hierarchicl data models to describe complex objects wth 1:M parent-child or container-component relationships. These tools often need to access multiple instances of some child or component type BB from one instance of a related parent or composite container or M-to-1 associated type AA. A fast way to do this is to traverse a linked-list structure from an instance of struct AA to its related instances of struct BB. Macros in chgen or templates in gencpp can be used to replicate generic declarations and functions. When the database is too large for memory-resident tables or lists, caches and/or indices must be maintained on disk and used efficiently. Relation Implementation

30. Pkeys and fkeys • Every row of a table contains a unique primary key, or ‘pkey’ as its first field. This key identifies the record or table type (2 or 4 upper-case letters), a version number (2 or 3 digits) and a row number (4 or 5 digits) • Table types optionally include foreign-key (fkey) fields. The value of an fkey must match the pkey value of its associated container or superclass ‘parent’. • Non-key attributes, fkeys to ‘is_a’ superclasses, and fkeys to ‘is-part-of’ containers are distinguished by different values for the is_key meta-attribute in meta-table TA: • fKey type: Not a Key isPartOf is_a • is_key value: 0 +/- 1 s

31. Maintenance of efficient linked lists is a guiding principle behind the classical network and new OO databases. GEN declares and maintains a circular list for every fkey attribute that it finds in the schema (i.e. for every 1:M relation link on the schema diagram). When pr_load reads any database into virtual memory (VM), the links become VM address pointers. The result is a network data structure called VMNetDB. Organization of VMNetDB

32. Tables in VMNetDB • A table definition in the schema represents a set of rows that are instances of its contained record type and a set of columns that contain attribute values. • This table definition can be converted by chgen to a ‘C’ struct declaration and threaded lists for its relatinships,. • Data types available for table columns include primary and foreign key, int, float, word, text. • A Data Structure Diagram (DSD) is an ERA diagram after all M:N relationships have been converted to Associative Entity tables. • A DSD can be drawn by any drawing tool and a corresponding chgen input schema.sch file can be created using any text editor.

33. Relational databases (RDB’s) and ERA data models support containment or aggregation (isPartOf) relations. Object-Oriented databases (OODB’s) also support inheritance by means of superclass - subclass (is-a) relations. Is-a relations are also called generalization - specialization (genspec) relations. UML and CDIF use different drawing conventions to distinguish gen-spec from isPartOf relations in EERA Diagrams. (BDE uses CDIF’s convention.) Super-to-Subclass or Gen-Spec Relations

34. Schemas from ERA Diagrams • A schema ER-diagram drawn with BDE is saved as a persistent database file. Thje latter can be automatically converted into meta-tables TT, TA and/or schema.sch via 96s523/bde2tt1/{b2t,t2s}. • A schema diagram drawn with another tool (e.g., PowerPoint or Idraw) must be manually edited into schema.sch. The latter cannot be automatically checked to see if it corresponds to the drawing. • In either case, full attribute descriptions must be added at some point(by appending HA text to HN nodes in bde or by post-editing tables TT and TA or file schema.sch). Each attribute line in schema.sch must contain the 5-tuple <name, altname, format, iskey, description> .

35. Parent and Child Roles • A table may participate in any number of ‘is-part-of’ relations or associations in either of two ways: as parent container or child component (but not both). • A table’s child roles are explicitly identified by the fact that it contains a foreign key or ‘fkey’ field for each child role (e.g. ‘XXid’ identifies parent type as ‘XX’). • Chgen finds out a table’s parent roles indirectly (by detecting the parent table type in the name of some fkey attribute in another (child) table. • Chgen does not suport cyclic schemas in which an fkey references the table type which contains it.

36. Drawing Relations: • 1:M relations are drawn as directed linksbetween nodes that represent parent and child entity types on a DSD. An arrow head OR arrow tail denotes the child end. • Either half of the link may be dashed or solid. Dashed link ends indicate mincard = 0 (optional). Solid links indicate mincard = 1 (mandatory). Source code from GEN does not yet enforce this distinction. • bde2sch creates one foreign (f)key field in the child table for each arrow head (or tail) that points into (or out of) the child table type, respectively. • Chgen creates distinct fkey names for two links connecting the same table pair (AAid1 and AAid2 in table BB above). AA AAid BB BBid AAid1 AAid2

37. Inheritance Relations • A table may also play the role of a superclass ‘generalization’ or subclass ‘specialization’ in an ‘inheritance’ relation. • This relation associates exactly one instance of the superclass generalization type AA with one of a set of subclass or specialization types BB, CC, etc. AA This relation associates exactly one instance of the superclass generalization type AA with one of a set of subclass or specialization types BB, CC, etc. CC BB

38. Although a gen-spec relation is actually 1:1 among instances, its schema diagram must describe a set of subclass types that specialize their superclass type. Therefore, a different link drawing style is used: Gen-Spec Relation Notation • The superclass is placed above a crossbar, and each of its subclasses is placed below the cross-bar; vertical lines connect all classes to the crossbar beween them. • UML (but not CDIF) uses a white triangle on one link to denote the entity with the superclass role. The triangle is placed over the crossbar end of the link, as shown at right. AA CC BB

39. An inheritance relation is indicated on a data structure diagram by a T-shaped branch structure from the superclass type to each subclass type (with no arrow heads or tails). Bde supports this EERA extension of ERA diagrams. The cross-bar is a special node type, identified by its height-to-width ratio. Notation for Inheritance AA (this implies a mutually exclusive relationship, not a 1:M parent-child relation, among instances.) BB CC DD

40. Reflective databases: • GEN (v10) supports reflective or self-describing databases. This description is called a meta-schema*: • Meta-table TT describes table or record types. Meta-table TA defines key and non-key attributes. The relation TT-->TA is 1:many. • A reflective database can process its own description as data, at runtime. • Examples: the names of fields in a particular table can be used to print a header row of column labels over a tabular report containing record instances as rows; format rules can be checked (validated) before accepting input data. TT: table descriptions TA: attribute descriptions • _____ • *Tables TT and TA must be read-only; changing TT or TA modifies database format and requires re-compilation.

41. Tables TT and TA together define a database. Each row of table TT describes one table type. Each TA-row describes one field of one table. Tables TT and TA can reside in the application database, and can be processed by chgen macros, because they have the sameformat as other tables. Tables TT and TA are self-describing: One TT-row describes table TT; another TT_row describes table TA; every TT-row has a set of TA-child rows. Each TA-row contains these field meta-attributes: <name, altname, format, iskey, description> Run ‘chgen -meta ...’ to generate tables TT and TA. Metatables TT and TA TT TA

42. Gencpp is a replacement for chgen that generates C++ code skeletons, taking data member definitions from DSD models, and (TBD) method definitions from state models. Each table definition in the schema will be converted by gencpp into a declaration of three or more classes: a corresponding C++ class whose data members are the table’s attributes and whose instances are the table rows; an instantiation of a generic container class for the table itself; a linked list class for each parent-child relationship that appears in the schema. TBD: Add action (method) names and signatures as attributes in schema diagrams. Schemas and Gencpp

43. Intension vs. Extension • Application database ‘intension’ • is a set of type definitions for the database • describes the format of each database table • is described in schema.sch (input to GEN) • is described in meta-tables TT and TA • is an output of chgen (v10 emits TT and TA) • is also called metadata (data about data) • Application database ‘extension’: • is the actual content or ‘population’ of a database • contains actual values of table rows or instances • has record types that are described in table TT • has data fields that are described in table TA

44. Example (Tree Schema SU->WH->IT) Non-key fields:: Vendor name Expiration date of price quotation Supplier SU Each arrow implies a foreign key in each child table record. (Phone number and address) Warehouse WH Only one warehouse of one supplier can supply a particular part in this (over-simplified) model. (Non-key fields: ourItemNo, vendorPartNo, unitPrice, unitQuantity, and description) Item IT

45. Schema as Drawn by BDE Top line of each node is HN.name text; rest are HA.hlabel text; New schema supports multi-word hlabel text; border=HN; dashed line=TBD. Supplier SU/*a supplier of some items we buy */ name NA c24 0 /* name of company we buy from */ expDate NA c10 0 /* last date price quotes are valid */ Warehouse WH /* where vendor stores items */ phone NA c10 0 /*warehouse phone number */ address NA t80 0 /* address of warehouse */ Item IT /* an item supplied by a vendor */ ourItemNo NA i4 0 /* our integer part identifier */ vendorCode NA c12 0 /* vendor’s item code */ unitPrice NA i4 0 /* vendor price in $/100 */ unitQuantity NA i4 0 /* quantity in package */ itemDesc NA i4 0 /* item description */

46. Supplier SU /* a supplier of some items we buy */ { . . . } Warehouse WH /* where vendor stores items */ { WHid NA c8 1 /* primary key (always first) */ SUid NA c8 1 /* foreign key from link */ phone NA c10 0 /* warehouse phone number */ address NA t80 0 /* address of warehouse */ } Item IT /* an item stored in vendor’s warehouse */ { . . . } Schema produced by b2t + t2s: This format may not be reproduced exactly. Attributes are shown only for table WH. Full-line comments are ignored by chgen.

47. struct WH /* where vendor stores items */ { hcg_key WHid /* 32bit primary key, from table type */ hcg_key SUid /* 32bit foreign key, from link source */ char phone[11] /* warehouse phone number + \n */ char address[81] /* address of warehouse + \n */ struct SU* SUid_pp /* direct pointer to WH parent */ dummy_ptr SUid_fpp /* forward pointer via siblings to parent */ dummy_ptr ITid_fcp /* pointer to first IT-child of this WH */ struct WH* next /* pointer to next row of table WH */ } Struct declared by chgen: /*The dashed line separates external fields declared in schema.sch from pointers inVMNetDB.These are declared in schema.h. Pr_load derives pointer values from external pkey and fkey values.. Struct types SU and IT are similar, but need fewer pointers. Back-ptrs SUid_bpp and ITid_bcp are suppressed if you run ‘chgen -nobp ...’.*/

48. MetaSchema Tables TT and TA TTid TableName TableAbbrev TableDescription TT000001 Supplier SU /*a supplier of some items we buy */ TT000002 Warehouse WH/* where vendor stores items */ T0000003 Item IT/* an item supplied by a vendor */ TAid TTid name altName fmt is_key description TA000001 TT000001 SUid NA c8 1 /* unique pkey of SUpplier */ TA000002 TT000001 name NA c24 0 /* name of company we buy from */ TA000003 TT000001 expDate NA c10 0 /* last date price quotes are */ TA000004 TT000002 WHid NA c8 1 /* unique pkey of WareHouse */ TA000005 TT000002 SUid NA c24 0 /* unique fkey(xref to SUpplier*/ TA000006 TT000002 phone NA c10 0 /*warehouse phone number */ TA000007 TT000002 address NA t80 0 /* address of warehouse */ TA000008 TT000003 ITid NA c8 1 /* unique pkey of ITem */ TA000009 TT000003 WHid NA c8 1 /* unique fkey (xref to WareHou*/ TA000010 TT000003 ourItemNo NA i4 0 /* our integer part identifier*/ TA000011 TT000003 vendorCode NA c12 0 /* vendor’s item code */ TA000012 TT000003 unitPrice NA i4 0 /* vendor price in $/100 */ TA000013 TT000003 unitQuant NA i4 0 /* quantity in packag */ TA000014 TT000003 itemDesc NA i4 0 /* item description */ Each table type is in a row of meta-table TT with its TT-row identifier or pkey TTid. Each attribute of a table type is in a row of meta-table TA with its TA-row pkey TAid. Each TA-row has a cross-reference fkey TTid to the TT_row of its containing table type. The remaining columns of table TA are copied directly from schema.sch.

49. Meta-tables TT, TA are Self-Describing: TTid* tableName ttAbbrev ttDescription TT000001 TableType TT /* meta-table that defines tables */ TT000002 TableAttribute TA /* meta-table that defines attributes */ TAid TTid name altName fmt is_key description TA000001 TT000001 TTid NA c8 1 /* unique pkey of TT-row */ TA000002 TT000001 tableName NA c32 0 /* Long name of this table */ TA000003 TT000001 ttAbbrev NA c2 0 /* abbreviated name (UCltrs)*/ TA000004 TT000001 ttDescription NA c24 0 /* meaning of table */ /*----------------------------------------------------------------*/ TA000005 TT000002 TAid NA c8 1 /* unique pkey of TA-row */ TA000006 TT000002 TTid NA c8 1 /*unique fkey xref to TableType */ TA000007 TT000002 name NA t80 0 /* name of attribute (field) */ TA000008 TT000002 altName NA c24 0 /* unique pkey of ITem */ TA000009 TT000002 fmt NA c4 0 /* field format: i4,f4,f8,c8,t80..*/ TA000010 TT000002 is_key NA c3 0 /* values: nonkey:0; key:1,-1,s */ TA000011 TT000002 description NA t80 0 /* meaning of table field */ Descriptions of meta-tables TT and TA occupy rows 1 and 2 of meta-table TT Meta-attributes of tables TT and TA appear in rows 1..11 of meta-table TA. Each TA-row includes a foreign key TTid to identify its parent row 1 or 2 of table TT. Other attributes of tables TT and TA are merely copied from schema tables TT and TA.

50. A database converter (bde2sch, bde2SM, etc.) must combine an input data model or subschema with an output data model or subschema to define a common schema with separate input and output views. Input and output schema.sch files must be concatenated before running chgen, which accepts exactly one schema.sch and emits tables TT + TA. Concatenating independent metaschematables derived from independent schema diagrams (e.g., two TT-tables with same TTid for distinct ttAbbrev’s) would require renaming all TTid keys of one subschema to avoid overlap. (Combining two bde diagram files into one would have the same problem and solution). Merging Sub-schemas