WO2004081698A2 - Outils de base de donnees - Google Patents

Outils de base de donnees Download PDF

Info

Publication number
WO2004081698A2
WO2004081698A2 PCT/GB2004/001086 GB2004001086W WO2004081698A2 WO 2004081698 A2 WO2004081698 A2 WO 2004081698A2 GB 2004001086 W GB2004001086 W GB 2004001086W WO 2004081698 A2 WO2004081698 A2 WO 2004081698A2
Authority
WO
WIPO (PCT)
Prior art keywords
generator
database
schema
data
file
Prior art date
Application number
PCT/GB2004/001086
Other languages
English (en)
Other versions
WO2004081698A3 (fr
Inventor
David Lear
Stuart Hebbes
Original Assignee
Beach Solutions Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB0305914A external-priority patent/GB0305914D0/en
Priority claimed from GB0305906A external-priority patent/GB0305906D0/en
Priority claimed from GB0305911A external-priority patent/GB0305911D0/en
Application filed by Beach Solutions Limited filed Critical Beach Solutions Limited
Priority to EP04720646A priority Critical patent/EP1606735A2/fr
Publication of WO2004081698A2 publication Critical patent/WO2004081698A2/fr
Publication of WO2004081698A3 publication Critical patent/WO2004081698A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/211—Schema design and management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/80—Information retrieval; Database structures therefor; File system structures therefor of semi-structured data, e.g. markup language structured data such as SGML, XML or HTML
    • G06F16/84—Mapping; Conversion
    • G06F16/86—Mapping to a database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]
    • G06F30/30—Circuit design

Definitions

  • This invention relates to tools for handling and documenting data that is stored in large and complex databases.
  • databases are used in the design of complex systems, for example embedded semiconductor systems, system-on-chip, and the like.
  • the data may be captured using EDA software which outputs data to an electronic database file in pre-defined formats.
  • All electronic designs can be thought of as having multiple views. Often these multiple views may contain different versions of the same information. For example, a system-on-chip will have hardware views. These hardware views will contain a representation of the system memory map built in to them in some way. Similarly, software views will also contain a representation of the system memory map built in to them. In addition, documentation such as data sheets that describe the system may also contain a full description of the memory map. This means that any electronic design typically has many different representations of the same data held in different places, and in different formats. This creates an environment that is almost certain to lead to inconsistency between different design views. This is further augmented by the fact that often these different views are usually developed by design teams working independently from each other.
  • the data can be stored in one or more structured databases in order that the data can be easily extracted and used. Design views can then be automatically generated from one single description thus eliminating the possibilities of inconsistency between views. This requires the common information to be stored in a structured way that is suited to generating all of the required design views.
  • a relational database can suit these requirements and provide a good method for storing and retrieving the data required to generate views with common information.
  • the entries in a relational database not only indicate basic data values, but also indicate the relationships between the data entries.
  • One format used to persist these databases is XML (extensible mark-up language), which allows data and data relationships to be encapsulated in an extensible, non-proprietary and platform-independent way.
  • design view generator extracts the desired data and presents it in a user-defined format.
  • the outputs typically called design views, can be executable code or other machine readable files or user manuals or other human readable documents.
  • View generation is just one operation that can be performed on a database, others include data validation and data population.
  • applications may be created to automatically populate a relational database by parsing a document such as a VHDL description, a specification document, or any other file that contains information that can be stored in the relational database. Similar to the generator applications a different parsing application will be required for each file format that is to be parsed.
  • GUI graphical user interface
  • This invention has arisen in an attempt to reduce the amount of time and effort associated with these, and similar, database-related activities and so improve the efficiency of activities such as complex system design.
  • the object of the invention is to provide tools which allow common parts of the activities to be presented in a reusable form and so avoid the need to construct complete tools ab initio for each activity.
  • One aspect of the invention includes the representation of a database design, or schema, such that it (the schema) may be stored in a relational database. All required schema databases are made available to the database tools. Within this invention different database tools use the schema databases to reconfigure their internal data structures such that they can be used to load relational databases with any arbitrary schema.
  • a method for automatically generating a schema database from a schema description is also presented.
  • This aspect of the invention comprises a method for operating on relational databases, comprising defining a series of normalised schemas of similar form and design; modelling the design of the schemas to produce a normalised relational database schema; modelling the normalised relational database schema (which is independent of the view being generated and furthermore, the database being operated on) to produce a reconfigurable datamodel; and using the reconfigurable datamodel to operate on the database.
  • a second aspect of the invention provides a design view generator, comprising a generic reusable generator core, which is independent of the view being generated and furthermore, the database being operated on; and generator module files which interact with the generator core to extract data from a database and output the data in one or more user-defined formats.
  • the generator core is reusable because it can automatically reconfigure itself for any arbitrary schema using the appropriate schema database.
  • the invention can include executable generator module files to create the design view generator.
  • a third aspect of this invention includes a generator module file generator (a generator of generators), which takes as its input description files indicating the information to be included in the output data, and outputs the executable generator module files.
  • the description files can comprise structure files indicating how the view generator should iterate over the data in the database; template files indicating how the generator should arrange the data for the generated design view; and rules files for selectively including or excluding segments of a generated design view.
  • the generator module file generator can include a data model which is used to generate the generator module files.
  • the generator module file generator may also use a schema database to automatically reconfigure itself for any arbitrary description file format.
  • a fourth aspect of the invention comprises a method of creating description files for use with a generator module file generator, comprising a reusable data model that can be automatically configured using a schema database; and generating description files.
  • GUIs for the view generator, generator description file generator and database editor.
  • a fifth aspect of the invention comprises a method of navigating relational databases comprising determining a unique object instance as a starting point for navigation; defining a class of objects; defining one or more relationships between the starting point and members of the class of objects; and returning a list of objects that are related to the starting point by the specified relationship(s) and belong to the defined class.
  • the invention also comprises systems and methods incorporating one or more of the various aspects of the invention defined above.
  • Figure 1 shows a high level view of a design view generator incorporating aspects of the present invention
  • Figure 2 shows an overview of the document generation process
  • Figure 3 shows an overview of generator module file generation
  • Figure 4 shows a simple relational database schema
  • Figure 5 shows a representation of the data held in the schema of Figure
  • Figure 6 shows a document structure definition
  • Figure 7 shows XML code corresponding to the structure of Figure 6
  • Figure 8 shows an example template using a context object to extract information about an object that has been navigated over.
  • Figure 9 shows XML code relating to a template for constructing a register table row
  • Figure 10 shows XML code relating to a method for padding columns in a table
  • Figure 11 shows XML code relating to the use of a new method
  • Figure 12 shows XML code relating to a modified rule
  • Figure 13 shows XML code relating to the entry point of a generator
  • Figure 14 shows XML code relating to a document section for a generator
  • Figure 15 shows a diagram of a simple schema
  • Figure 16 shows an object hash being used to hold instances of objects described in the schema of Figure 15;
  • Figure 17 shows a referredTo hash being used to hold relationship information between object instances as described in the schema of Figure 15;
  • Figure 18 shows a referredBy hash being used to hold relationship information between object instances as described in the schema of Figure 15;
  • Figure 19 shows a refDirectn hash being used to hold relationship information between object instances as described in the schema of Figure
  • Figure 20 shows a schema captured in a specialised information model
  • Figure 21 shows super-type/sub-type data relationships in a database
  • Figure 22 shows flattened super-type/sub-type relationships corresponding to Figure 21;
  • Figure 23 shows super-type with relationship
  • Figure 24 shows flattened super-type relationship
  • Figure 25 shows XML code relating to a document type description
  • Figure 26 shows XML code relating to a translation of schema data
  • Figure 27 shows a schema representation of a schema
  • Figure 28 shows XML code relating to a schema document type description
  • Figures 29-31 show simple representations of three types of schema used in the embodiment of Figure l;and
  • Figure 32 shows a schema example.
  • Figure 1 shows a high level view of an embodiment incorporating the various aspects of the invention summarised above.
  • the system shown in Figure 1 is a system for producing design views.
  • Design views are electronic documents laying out some or all of the data from a database in a prescribed structure, sequence, form, format and style.
  • Design views are typically text files so can ultimately be found in the form of documents for display (printed, screen, etc. for human readable information) or in the form of executable files for use by other programmed systems.
  • the system shown in Figure 1 broadly comprises four main sections: a database section 100, a design view generator 200, a generator module file generator 300, and a schema file generator 400. Each is described further below.
  • the database section comprises a database file 102 and a graphical user interface (GUI) 104.
  • a database is a document, file or collection of files storing a set of data in a structured way in conformance with a defined plan known as a schema, which describes the database design in terms of objects having one or more attributes.
  • the database is a relational database: the relationships between the data are also stored, the object having extra fields to hold references to other object instances.
  • the database file 102 is an electronic file, in this case in XML format, containing the object instances.
  • the database file 102 also contains a reference to a schema database which fully describes the types of object and relationships between objects that the database file contains (the database file may also contain a simple description of the objects it contains for the purpose of assisting XML file verification; such a description is known as a Document Type Definition (DTD)).
  • DTD Document Type Definition
  • the schema database will be discussed in more detail below in relation to the schema database generator 400.
  • the database comprising the database file 102 in the present example can be an IP block database 102a storing IP blocks, registers, bitfields, etc.; or a system database 102b storing systems, components, buses, nets, etc..
  • the database can be implemented programmatically in computer memory in the form of an architecture which primarily maps the database concepts of object, attribute, and relationship into programmatic constructs.
  • the architecture allows instances of objects described by the schema to be created, modified, deleted and related to other schema objects.
  • the architecture is configured by reading a schema file and populated by reading a database file.
  • the GUI 104 allows users to create and maintain the database and includes a data model 106 (an example of an architecture) to hold the database data while it is operated on by the GUI 104.
  • the data model 106 s a generic implementation of the architecture in Java which holds the data whilst they are operated on by the GUI 104.
  • the design view generator 200 comprises a generator core
  • the design view generator is to extract data from the database section 100 and configure it into user-defined design view documents 210.
  • the generator core 202 comprises a dedicated architecture, implemented in Perl (although it is possible that this might be implemented in another language, such as Java).
  • the generator core 202 contains control functions for processing intermediate data and for producing the required output design views 210 according to instructions provided by the generator module file 206.
  • the generator GUI 208 is used to provide options to tailor the design view generation process.
  • the generator uses a generator options file 216 containing user-defined options controlling how design files are generated.
  • the generator command file 212 and generator options file 216 can be produced automatically using the GUI panel 208 or by command line operation.
  • the generator module file generator 300 is used to generate the generator module files 206 used by the design view generator 200.
  • the generator module file generator 300 comprises a generator configuration kit 302 and a data model 304.
  • the data model 304 comprises an implementation, in Java, of the architecture which is also found in the generator core 202 and is used in conjunction with a GUI 306 to create document description files 308 as inputs for the generator configuration kit 302.
  • the document description files comprise document structure files 308a, document template files 308b, document rules files 308c, and can optionally include document new methods files 308d.
  • Document structure files 308a contain XML navigation tags that specify how to iterate over objects in a defined order, specifying when to call document templates 308b and document rules 308c. These navigation tags are used by the generator configuration kit 302 to generate executable code which realise on the API 203 in the generator core 202 which supplies methods to allow the navigation in any route in any schema.
  • Document template files 308b comprise Perl subroutines
  • Document rules files 308c comprise Perl routines
  • Document new methods files 308d comprise Perl routines
  • the schemas used in the database section 100, design view generator 200 and generator module file generator 300 are all derived from a schema tool 400 which includes a database 402 including the various schemas (including its own schema).
  • This invention allows various design views to be generated, from a standardised description of a user's system, captured in an XML format database.
  • FIG. 2 shows an overview of the document generation process ("document” in this context covers any output file format, for example C code, HDL code).
  • generator core 200 extracts information from the database files 102, processes it according to the instructions contained in generator module files 206, and produces the required outputs, the design view files (documents) 210.
  • the generator configuration kit 302 allows users to create generator module files 206, which produce documents 210 formatted to predetermined requirements or standards.
  • Figure 3 shows this process in general.
  • the inputs to the generator configuration kit 302 are document description files 308, which describe the structure of the required documents 210.
  • the generator configuration kit 302 processes the document description files 308 to produce generator module files 206.
  • the document structure file 308a. - This file describes how a generator should iterate over data in a database. Each section of a document is associated with a particular section of the database, for example a list of register, or a list of bitfields within those registers.
  • the file allows a user to specify how a document can be built up from iterations over these different database objects. For example, for a generator that generates a text file containing a short description of each IPBIock in a System, the document structure file is used to specify an iteration over each IPBIock in a specific System.
  • templates are specified using an XML tag in the document structure file 308a.
  • a template is a small subroutine of code written in PERL that returns a string. The returned string will be placed into the output file of the generator. So for the simple example given above, a template would be specified that would be run for each iteration over a list of IPBIocks in a system. The string returned would contain the description to be added into the output file.
  • the template file 308b contains all of the templates called by the document structure file 308a. Each template is a PERL subroutine encapsulated in an XML tag.
  • the document rules file 308c. - This file contains a set of rules, written in PERL and encapsulated in XML tags. A rule is required for each template specified in the document structure file 308a. A rule is also required for each document section in the document structure file 308a. The rule is run before its associated template or section, and returns a 1 or 0 value.
  • the rules can be used to selectively include or exclude segments of the generated document, depending upon user defined criteria. They provide a more efficient method of defining these choices, rather than using decision making code inside the templates. The default is to return a value of 1', which means that the section or template will always run.
  • the document structure file 308a, the templates file 308b and the rules file 308c are all required by the generator configuration kit 302.
  • the new methods file is optional 308d. There can be as many of each type of file as are required. This is so that document sections, rules, and templates can all be re-used across many different generators.
  • Creation of the document description files 308 is made easier by utilities built into the Generator kit. If any templates have been specified in the document structure file 308a but do not exist in the templates file the generator configuration kit 302 automatically generates an XML file which contains empty versions of the required templates. The PERL subroutines in these automatically generated templates just returns an empty string. If any rules are required but do not exist in the rules file the generator kit automatically generates an XML file which contains the required rules. The PERL subroutines in these automatically generated rules always return a 1.
  • the generator configuration kit 302 is used to navigate objects in the database and create lists of object instances. The resulting list of object instances is then iterated over. For each iteration a template is executed which outputs a fragment of the output file. The navigations and iterations are specified in the document structure file. [0049] In order to specify this navigation and iteration, the schema of the database must be understood. A schema is a graphical representation of the data that can be captured in a database. Figure 4 shows a simple schema 420. The XML tags used in the document structure file 308a are used to describe how to navigate over the objects in the database.
  • a system 422 can have many located components 424. This is shown by relationship RI, with a % showing that one system 422 relates to ⁇ *' (one or more) located components 424.
  • An IPBIock 426 can be located in many systems 422, this is relationship R2.
  • R4 shows that an IPBIock 426 can contain many registers 428
  • R5 shows that a register 428 can contain many bitfields 430.
  • the final relationship, R3, represents a different relationship between systems 422 and located components 424. It shows that a system 422 can also be located many times in other systems (not shown).
  • This tag allows a method of navigating to any specific instance of an object in the schema. It provides a reference to a document section. The specified document section is executed once for the specific instance of the specified object in the database being generated from. The specific instance that this tag jumps to is passed into the generator by whichever application runs the generator. Normally this tag will only be used once at the beginning of the document structure file to jump to the starting point for the current generation. You must specify the object type (System, IPBIock etc) that the document section is expecting.
  • This tag allows a method of navigating to any object in the schema. It provides a reference to a document section. The specified document section is repeated for all occurrences of the specified object in the database being generated from. This tag may be used to specify an iteration over all of the registers in a database, for example, in order to check whether a VHDL keyword has been used as a register name. The object type to iterate over must be specified.
  • This tag allows a method of navigating to an object related to the object previously being iterated over.
  • This tag may only be used to navigate a many-to-one or a one-to-one relationship. It provides a reference to a document section.
  • the specified document section is executed once for the specific instance of the specified object that is related to the instance of the previous object being iterated over. For example, for iterating over a list of bitfields, this tag could be used to specify the execution of a template for the register that the current bitfield is contained in. A relationship name and an object name must be passed.
  • This tag allows a method of navigating to an object related to the object previously being iterated over. It provides a reference to a document section. The specified document section is repeated for all instances of the specified object that are related to the instance of the previous object being iterated over. An object name and a list of relationships must be specified. The generator will automatically navigate the list of relationships building a list of object instances as it goes. It will then filter the list so that it only contains objects of the specified type. The final list is then iterated over and the specified document section is executed for each object instance in the list.
  • Figure 5 shows an alternative "tree” view of the data held in the database schema of Figure 4, which will help to explain the iteration process and context.
  • a document is generated by iteration over instances of objects in the database.
  • a system will have a list of IPblocks associated with it.
  • Each IPBIock may have a list of registers associated with it etc.
  • the sequence of iterations over object instances is defined by a set of XML tags in the document structure file.
  • a generator template may be defined to output a fragment of the generated document.
  • Iterations over neighbouring objects may be nested.
  • iterating over a list of IPBIocks for each of the IPBIocks it may be desired to iterate over all of the registers associated with the current IPBIock. Then for each register it may be desired to iterate over all of the bitfields associated with the current register etc.
  • the generator template has access to a context object.
  • the context object has references to all of the objects at the current level and higher in the current iteration hierarchy. So for example in Fig 5 whilst iterating over bitfields it is still possible to access the register that is associated with the current list of bitfields being iterated over, the IPBIock associated with that register can be accessed and so on.
  • a generator commonly starts with a specific instance of an object, for example a system or an IPBIock.
  • a reference to a specific instance of an object is passed in to a generator when it is called from an application.
  • a special XML tag (jumpTo) is used to jump to this specific starting instance. When jumping to this starting instance the context object is reset.
  • the generator templates are written in Perl and interpreted by the generator program.
  • the stages in generating a document are: a. Define the document structure for the generated document and write the generator kit XML files: document structure and empty document template and document rule files. b. Run the generator kit to produce the template code file and the rule code file. c. Copy the rules in the rule code filr into the document rules file. Copy the templates in the template code file into the document templates file. Fill out the empty templates and rules. d. Run the generator kit to produce the generator module files. e. Run the code generator to produce the generated document files (design views).
  • the generator will be used to produce a text document containing a set of tables listing information about the various objects in a database.
  • the generated output is called the tables document.
  • the first step is to define a document structure for the tables document. This is shown in Fig 6 with the corresponding XML description in Figure 7.
  • the Document Structure File The XML description for the tables document is contained in the file in the xml directory (Fig. 7).
  • the first tag [1] in this file is the root tag for a document structure description.
  • the next section [2] sets up some parameters that are used for the generator module files.
  • the Document name and type attributes are used to make up the document type string that is prefixed to all generator module file names. For the tables generator the prefix is ⁇ tablesTxt f .
  • the Document licenceFeature attribute specifies the name of the licence feature that will be used to licence the generator module files.
  • the jumpTo tag refers to a DocumentSection uniquely identified by the documentSectionld attribute. This tag specifies that the specified DocumentSection should be executed for the specific system object specified by the application that invoked the generator. The specified instance of the system object must exist in the current database. Usually there will only be one system object in any database.
  • the section reference contained in the Document tag refers to the top level or root document section.
  • the fileNamePrefix attribute specifies a prefix that will be added to the file name of the generated document file. This feature allows the same document section to be re-used to produce different generated documents with the same structure.
  • the next part [3] describes the root document section.
  • the value of the DocumentSection id attribute matches the jumpTo documentSectionld attribute and must be unique across all document sections for the generator.
  • the object attribute specifies the objects in the schema that the document section is focused on. The focus of a document structure can be changed to any object in the schema at any time using the jumpIterateOverAII, jumpRelated, and jumpIterateOverRelated tags.
  • the relationship attribute specifies which relationships should be navigated to get to the object specified by the object attribute. These relationships are shown in Fig. 4.
  • the Output tag specifies parameters for the generated document. As the Output tag is contained in a document section focused on the system objects, a single generated document file will be produced containing the entire generated document for each system in the current database. Since this document section was executed from a jumpTo command, only one document file will be produced for the instance of the system object that was specified when the generator was invoked. If an Output tag is placed in a document section focused on a different object, e.g. IPBIock, one file is produced for each instance of that item, e.g. one file per IPBIock. For the tables document example the generated document file name is p_objectOnel.txt.
  • the p_ prefix comes from the section reference fileNamePrefix attribute
  • objectOnel is made up from the object name and the unique object identifier
  • the .txt suffix comes from the Output tag fileNameSuffix attribute.
  • the template tag specifies that the tablesProductTitle template will be executed at this point to produce the System Title (See Fig 6) fragment of the generated document.
  • SectionReference with documentSectionld attribute set to tablesCelllnstanceTableSection, indicates that a document section to produce the cell instance table will be included at this point.
  • the jumpIterateOverRelated tag with it's object attribute value set to IPBIock, and its relationship attribute set to "R1,R2" specifies that the referenced documentSection will be repeated for each IPBIock related to the instance of the system that was the starting point for the current generation by the relationships RI and R2.
  • the unique attribute set to "true” specifies that the resulting list to be iterated over will only contain a unique list of IPBIocks. This will be all of the IPBIocks used by the current top-level system. This can be thought of as adding a level of hierarchy to the current iteration.
  • the tablesCellSection document section referred to by the jumpIterateOverRelated tag, will be executed once per IPBIock used by the current top-level system.
  • the first template produces the Cell Instance Table Title (See
  • jumpIterateOverRelated unique attribute is set to false.
  • a system may contain more than one instance of a cell, each with a different location address. Setting the unique to false will cause the referenced document section to execute for each instance of each IPBIock in the system.
  • the final document sections [5] produce a register table for each IPBIock used by the system.
  • the first template produces a title for the cell
  • the second produces a title for the register table
  • the third produces the column headings for the register table.
  • New Methods 308d - An example template, for constructing a register table row, is shown in Fig. 9.
  • the template contains code to pad out each column in the row to 26 characters. Similar code is also contained in the template to produce the register table heading (see template tablesRegisterTableHeading in file tablesTxtTemplatesComplete.xml.)
  • the code to pad out the columns can be localised into a single method that is then used to extend the generator kit API by adding it to the context object.
  • the new method is passed a column width parameter and a list of strings, one for each column in the row. It returns the complete row with each column padded to the column width.
  • the new method can be accessed from both templates.
  • the new method defined in the tablesTxtNewMethods.xml file, is shown in Fig 10.
  • the NewMethod tag contains two attributes.
  • the object attribute specifies which API object to attach the method to and the name attribute denotes the name by which the method is invoked. Note, when the method is called, the first parameter is always a reference to the instance of the object (a "self” or "this" pointer.)
  • Fig. 11 shows how the new method is used in the optimised version of the tablesRegisterTableRow template.
  • OPTIONS_FILE set to: options/ optionsOptimised.txt. Re-run the generator by following the procedure described above.
  • Hierarchical Systems In certain cases recursive iteration may be required, for example to produce a generator that can navigate a hierarchy of systems within systems. In order to do this, it must be possible to be able to recursively iterate over each system that is contained within a system.
  • Fig. 7 is a section of the XML to describe a document generator.
  • a limitation of this XML is that it cannot deal with a hierarchy of systems. It assumes that the top-level system only contains IPBIocks. In order to be able to deal with the possibility of a system containing other systems it must be possible to be able to deal with recursive iteration over the hierarchy of systems.
  • the first thing to do in a document generator is find the system that is the top-level of the current generation run.
  • the unique identifier (ID) of this system is passed into each generator automatically.
  • the jumpTo tag is used to set the focus of the current generation run to this top-level object instance. So the first part of the XML is the same as before, see Fig 13.
  • the tablesSystemSection document section will then only be repeated for the selected top-level system in the current database.
  • Next iterating over the systems and cells in the current database generates the required document sections for each cell/system in the current top-level system, see Fig. 14.
  • the XML has been altered.
  • XML Document Structure File Usually named docTypeGenerateDocument, where docType represents the type of generator e.g. 'tablesTxt'. This XML file describes the structure of the document to be generated.
  • XML document structure file It represents the top-level document section. This is the entry point for the execution of the generator that is being described. This tag can only appear inside an EasiDocument tag. At the entry point the document generator is not focused on any object, therefore a jumpIterateOverAII tag must be used to jump to a particular object in the schema and start iterating over occurrences of that object in the current database.
  • FileNamePrefix "namePrefix” (optional) - where namePrefix is a string that will be prefixed to the file name of the generated document.
  • nameSpacePrefix "namePrefix” (optional) - where namePrefix is a string that will be prefixed to the name of any templates specified in the referenced document section.
  • FileNameElementPart "no" (optional) - where no specifies not to include the current element name (e.g. cell name) in the generated document filename.
  • SubDirectoryPrefix "pref ⁇ xString" (optional) - where prefixString specifies that the output will be placed in a generated output subdirectory with a name prefixed with prefixString.
  • Append true (optional) - where true specifies that the output for the current level should also be appended to the output file for the level above.
  • This tag refers to a document template that specifies how a fragment of the document section is generated. It can appear inside DocumentSection and Match tags.
  • the generator template itself is defined inside a generator template file.
  • Attributes name "templateName” (required) - where templatelMame is the name of a document template.
  • objectName (required) - where objectName specifies the name of an object in the current schema.
  • the jumpIterateOverAII tag can be used with its object attribute set to bitfield.
  • nameSpacePrefix "namePrefix" (optional) - where namePrefix is a string that will be prefixed to the name of any templates specified in the referenced document section.
  • objectName (required) - where objectName specifies the name of an object in the current schema.
  • the jumpIterateOverAII tag can be used with its object attribute set to bitfield.
  • FileNamePrefix "namePrefix” (optional) - where namePrefix is a string that will be prefixed to the file name of the generated document.
  • nameSpacePrefix "namePrefix" (optional) - where namePrefix is a string that will be prefixed to the name of any templates specified in the referenced document section.
  • sortBy "name” (optional) - specifies which order the list of objects should be iterated over. If this is left blank the iteration order will be arbitrary. If an attribute name is specified then the iteration order will be in ascending or descending order of the attribute values.
  • sortOrder "ascending I descending" (optional) - specifies which order the list of objects should be iterated over. If this is left blank but the sortBy field is specified then the sort order will be assumed to be ascending.
  • This tag allows a method of navigating to an object related to the object previously being iterated over.
  • This tag may only be used to navigate a many-to-one or a one-to-one relationship. It provides a reference to a document section that may be either in the same file or in a separate document section file.
  • the specified DocumentSection is executed once for the specific instance of the specified object that is related to the instance of the previous object being iterated over. This tag can only appear inside Document, DocumentSection and Match tags.
  • Attributes relationship "relationshipWame” (required) - where relation ⁇ hipName specifies the name of the relationship between the object that was previously being iterated over, and the object that is being navigated to.
  • object "objectName” (required) - where objectName specifies the name of an object in the current schema. This object must be related to the previous object being iterated over.
  • jumpIterateOverRelated tag can only be used to move from one object to one of its neighbours in the schema.
  • jumpIterateOverRelated tags are nested all attributes relating to the current instance of previous iterations are also available.
  • documentSectionId idRefString" (required) - where idRefString is a string that matches a unique id string for a document section tag.
  • Attributes relationship "relationshipNameList” (required) - where relationshipName specifies the name of the relationship between the object that was previously being iterated over, and the object that is being navigated to. This field can contain a list of relationships, in which case each relationship in the list will be navigated, and the resulting list will be iterated over.
  • unique "true I false" (optional) - specifies whether or not the final list to be iterated over should only contain unique entries, or whether it should contain an entry for each instance of an object.
  • object "objectName” (required) - where objectName specifies the name of an object in the current schema. This object must be related to the previous object being iterated over.
  • the jumpIterateOverRelated tag can only be used to move from one object to one of its neighbours in the schema.
  • jumpIterateOverRelated tags are nested all attributes relating to the current instance of previous iterations are also available.
  • documentSectionId idRefString" (required) - where idRefString is a string that matches a unique id string for a document section tag.
  • nameSpacePref_x "namePrefix" (optional) - where namePrefix is a string that will be prefixed to the name of any templates specified in the referenced document section.
  • sortBy "name" (optional) - specifies which order the list of objects should be iterated over. If this is left blank the iteration order will be arbitrary. If an attribute name is specified then the iteration order will be in ascending or descending order of the attribute values.
  • sortOrder "ascending I descending" (optional) - specifies which order the list of objects should be iterated over. If this is left blank but the sortBy field is specified then the sort order will be assumed to be ascending.
  • startAt "startNumber" (required) - Where startNumber specifies the iteration number at which to start matching.
  • Increment "incrementNumber" (required) - Where incrementNumber specifies the amount by which the match number is incremented each time.
  • XML Document Section File This is an extension of the XML document structure file and may contain any of the tags that are used in the document structure file listed above. The only exception to this is the ⁇ Document>... ⁇ /Document> tags which may only be used in the XML document structure file. [00106] ⁇ EasiDocumentSections> ... ⁇ /EasiDocumentSections > This is the root tag for the Document sections file. All other tags are contained within this tag.
  • XML Template File This file contains the templates for a generator.
  • templateName is the name of the template specified in the document structure file using the ⁇ template/> tag.
  • nameSpacePrefix attribute of a document section is the name of the template specified in the document structure file using the ⁇ template/> tag.
  • the CDATA section contains the definition of the PERL subroutine that will be executed where specified in the document structure file .
  • ruleName is the name of the rule.
  • rules are needed for all templates and document sections specified in the document section file.
  • the ruleName is the same as the templateName described above but has the word Rule postfixed to the end.
  • the ruleName is created from the documentSectionld, prefixed with a name from the nameSpacePrefix attribute of a document section and postfixed with the words section_rule.
  • the CDATA section contains the definition of the PERL subroutine that will be executed in order to decide whether to run the specified document section or template.
  • the PERL subroutine should return a 1 or 0.
  • XML New Methods File This file contains new methods for objects in the generator kit. This file can be used to extend the existing API for an object provided by the generator kit.
  • the CDATA section contains the definition of the PERL subroutine that will be executed added as a method to the specified object.
  • the PERL subroutine specified in this section should have the same name as the methodName specified in the name attribute.
  • the structure of the Generator Core Data Model can be divided into two parts. The first part contains the data structures that will be populated with information from XML databases. This part of the Data Model is generic and is independent of schema version. It is written directly in Perl. The second part is the set of Perl modules that describe the object classes for each object class in the schema in each of the schemas. This part of the Data Model is totally dependant on the version of the schema and is generated from a generic description of a schema.
  • the data model itself is comprised of a single encompassing data model that is capable of holding many database structures. Each instance of a database structure can hold all of the information from one XML database file.
  • the data model provides methods to create, access and navigate between database structures. Each database structure provides methods to create, access and navigate objects within itself. All database structures belong to the same class, which is described in the GenCoreDatabaseStructure perl module.
  • Each database structure is split into six separate hashes, comprising: objectHash, referredTo Hash, referredBy Hash, refDirectn Hash, (Globally unique identifier) GUID hash and counterpart hash.
  • Fig 15 shows a diagram of a simple schema will be used to illustrate how the data in each of the hashes is stored.
  • the object hash (Fig. 16) contains a list of references to objects, keyed by the Id of the objects. This hash is used to store and retrieve objects populated from an XML database. The other two hashes are used to store information about the relationships between objects.
  • the referredTo hash (Fig. 17) contains a hash for each object in the database, keyed by object Id. Each hash contains a list of object Ids that an object has a reference to. These object Ids are keyed by the relationship name.
  • the referredTo hash can be used for navigating from the many end to the one end of a one-to-many relationship
  • the referredBy hash (Fig. 18) contains a list for each object in the database, keyed by object Id. Each list contains a list of object Ids. These Ids are Ids of objects that refer to the current object.
  • the referredBy hash can be used for navigating from a one end to the many end of a one-to-many relationship
  • the refDirectn hash (Fig. 19) contains a hash of relationships for each object class.
  • the hash is keyed by relationship name and the value for each item is the direction in which the relationship should be navigated to get to the object at the other end of the relationship. This information is used to decide whether the referredTo hash or the referredBy hash should be used to navigate a relationship
  • the (Globally unique identifier) GUID hash contains a list of object ids for each object in the database keyed by the GUID of the object. This is used to get an object out of a database structure when you know its GUID.
  • the counterpart hash contains a list of counterpart objects keyed by object ids. If an object is a counterpart of an object in another database, it will have a counterpart object associated with it. The counterpart object will be stored in the counterpart hash.
  • the counterpart object contains information about the object that has been counterparted. It contains specifies the URL of the database that contains the counterparted object, and the GUID of the object that has been counterparted. This information is used to navigate from a counterpart to the object that has been counterparted.
  • GenCoreDatabaseStructure class This class has a number of methods that allow these six hashes to be populated, navigated, and accessed.
  • CreateRefByEntry (s_objId,r_refHash) This method adds an entry into the referredBy hash. It takes the object Id as an argument and a reference to a hash. The hash is in the same format as is required by the CreateRefToEntry method. This method is used to enter the current object Id into the referred by hashes for each of the objects that the current object refers to. This method is not exported.
  • CreateRefDirectnEntry (s_objId,r_refHash) This method adds an entry into the refDirectn hash. It takes the object Id as an argument and a reference to a hash. The hash contains a list of object Ids that the current object refers to, and is in exactly the same format as is required by the CreateRefToEntry method. This method can only be used when the objectHash has been completely populated. This is because this method requires information about which class an object is blessed into. It gets this information by accessing the objectHash. This method is not exported.
  • CreateObjAndRefEntries (s_objId,r_objRef,r_refHash)
  • This method uses the CreateObjEntry, CreateRefToEntry, and CreateRefByEntry methods to make an entry for one object into the objectHash, the referredTo hash and the referredBy hash.
  • the first argument is the Id of the object.
  • the second argument is a reference to the object.
  • the final argument is a hash that identifies the objects that the current object refers to.
  • This method is exported.
  • CreateGUIDEntry Q This method adds an entry into the GUID hash. It takes the id of an object, and a reference to the object as arguments. This method is exported.
  • GetObjEntry(s_objId) This method takes an object Id and returns a reference to the object with that Id. This method is exported.
  • FindAIIReferredBy(s_objId,s_refName) This method is used to find the list of objects that reference the object whose Id you pass into this method. The method takes an object Id and a string containing the name of the relationship between the two objects, as arguments. It returns a list. The list contains a list of object Ids that the specified object is referred by. This method is not exported.
  • FindAIIInClass(s_objClass) This method returns all of the objects in a particular class, regardless of their relationships. The method takes the name of an object class as an argument. It returns a list that contains a list of object references. This method is exported.
  • NavigateTo(s_objId,s_objClass,r_refNameList) This method is exported. This method is used to navigate a list of relationships. The method takes an object Id, a name of an object class and a reference to a list of relationship names as arguments. It returns a list that contains a list of references to NavigatePath objects. Starting with the object whose Id was passed in, the method uses the referredTo, referredBy and refDirectn to navigate the list of relationships passed in as an argument. A reference to each intermediate object passed during the navigation is stored in a NavigationPath object.
  • the resulting list of NavigatePath objects is then filtered to remove all NavigatePath objects that do not belong to an object of the specified class.
  • a list of NavigatePath references is returned. Note if an object is instanced more than once, it or a related object may appear more than once in the returned NavigatePath list.
  • a NavigatePath object is an object containing references to other objects.
  • a method is provided to get each of the object references in a NavigatePath object.
  • the method name for each object is formed using the class name that the object belongs to as follows: get ⁇ class_name>. For instance if one of the objects stored in a NavigatePath object was a reference to a Register object then the method getRegister could be used to retrieve the reference to the register.
  • getObjA will return a reference to the instance of ObjA that object objF_127 has a refers to.
  • getObjB will return a reference to the instance of ObjB that the instance of ObjA refers to. That instance of ObjA is itself referred to by the object objF_127.
  • NavigateToUnique(s_objId,s_objClass,r_refNameList) This method is identical to the NavigateTo method with one exception. If an object or a related object is instantiated more than once the returned object list will only contain a NavigatePath object for each unique object navigated to. This method is exported.
  • the perl modules for each of the object classes are generated from a description of the schema. This description is embodied in the Schema host object. One perl module is generated for each object described in the Schema host. Each perl module contains a constructor and a list of methods that give write and read access to all of the normal type attributes of the object. Lastly, the Core generator is able to read an XML file that specifies methods to add to objects. This route can be used to add methods whose definitions are schema dependent to an object. Any method can be added to any object in the schema.
  • All of the generated object classes belong to one super class (or base class).
  • This super class (ObjectSuperClass.pm) contains attributes that are specific to the architecture of the Data Model.
  • the super class is not a generated perl module. Currently it contains only two attributes: The Id field - containing the Id of an object; And the GUID field - containing the globally unique Id of an object. All generated object classes inherit these two attributes and the methods to get and set them.
  • NavigateTo(s_objId,s_objClass,r_refNameList) Allows the generator kit to navigate from a particular object via any list of relationships and return a list of NavigatePath object references for each object at the end of the navigation that belong to the specified class. If an object is instantiated more than once it will appear more than once in the returned list of NavigatePaths.
  • setld(s_ bjld) Used to set the Id of an object.
  • the Id can be any string. POD documentation is not generated for these methods.
  • get ⁇ attributeName>() One of these methods is generated for each normal attribute of an object. They allow the value of an attribute to be returned. If the attribute is stored as a numerical value instead of getting just one get method, three are generated: get ⁇ attributeName>Bi()Returns the value of the attribute in big integer format. get ⁇ attributeName>Hex()Returns the value of the attribute in Hex string format. get ⁇ attributeName>Bs()Retums the value of the attribute in Binary String format.
  • an attribute may be parameterised.
  • additional get methods will be generated that allow access to the default value, resolved value, (as above these will be split into three if the parametersable attribute is a numerical attribute) parameter name, and true/false indicating whether the attribute is parameterised.
  • getDefault ⁇ attributeName>() Returns the default value of the parameter used for this attribute.
  • getResolved ⁇ attributeName> Returns the fully resolved value of the parameter for this instance of this attribute.
  • get ⁇ attributeName>ParamName() Returns the string representation of the name of the parameter used for this attribute.
  • getIs ⁇ attributeName>Param() Returns true if a parameter has been used to give this attribute a value.
  • POD documentation is only generated for the get methods of normal attributes.
  • the navigation tool as implemented in the system described above, provides a set of navigation methods that may be used to navigate objects in a database and cross links between databases. Each of these navigation methods can be used with reference to a schema drawing of the database structure inside which it is wished to navigate.
  • the navigation methods are completely generic and can be used to navigate any set of object instances inside any database with any schema.
  • Figure 32 is a schema drawing for a fictional database which holds personal records. Clearly, in the case of the present invention, this database would hold design data, the example of Fig. 32 being presented for explanation only.
  • Each person entered into the database can have zero or more personal records and zero or more business records.
  • Each personal record can have zero or more hobbies objects related to it that hold information about the persons hobbies.
  • Both personal and business records may have zero or more telephone objects related to them. The telephone objects hold information about a persons telephone numbers.
  • a business record can have a training course object associated with it.
  • One instance of a training course object may be associated with many business records. This is to allow for the fact that many persons may have attended the same training course.
  • One instance of a business record may also be associated with many training course. This is because a person may have attended many training courses.
  • the person object is labelled as a schema counterpart. This indicates that one or more of the attributes of the person object, actually come from another object in another schema.
  • the person object in this schema is linked by some means to its counterpart in another schema.
  • this list of objects may not be unique. For instance, suppose that it is desired to create a list of training courses that a specific individual had attended. From the schema diagram it can be seen that the same person may have attended the same training course twice. This would mean that if the previous method as used to generate a list of training courses, the same object instance may be repeated in the returned list of object instances.
  • An example of such a navigation tool is implemented within the generator core 202 which is comprised of several parts. Firstly the generator core data model itself. The data model is capable of opening and accessing many databases simultaneously. Methods are provided within the data model to create databases and populate them from a database file. Next the generator core database structure, which is an object class designed to create and hold databases in memory. Finally, a set of object classes, one for each of the objects in the schema drawing for each database that could be held in memory. This last set of object classes can be automatically generated as required when a database is loaded into memory.
  • the SwitchTo method is provided by the generator core data model to allow the navigation of schema counterparts between databases. It takes a reference to a database, and a reference to an object within that database. This is the starting point for the navigation. It also takes a class name. The method then navigates to the object instance that the starting object instance is a counterpart of. If this object instance belongs to the specified class, the method will return a reference to a database. This is the database in which the counterparted object exists. It also returns a reference to the counterparted object.
  • Each database structure within the data model has a number of methods that allow the creation of objects within the database. It also has methods that allow the creation of relationships between object instances.
  • the database structure is completely generic and is capable of holding any database created from any schema drawing. Four of the methods in the database structure are used for navigating the objects within a database.
  • the FindObjEntry method is provided to allow an application to select a specific instance of an object. It takes a unique identifier of an object instance and returns a reference to the identified object.
  • the FindAIIInClass method is provided to allow the selection of all of the objects that belong to a specific class. This method takes a class name. It returns a list of references to all of the object instances that belong to the specified class.
  • the NavigateTo method allows an application to select object instances that are related in some way to a specific object.
  • This method takes a unique identifier of an object instance. This is the starting point for the navigation. It takes a class name. Only object instances that belong to this class will be returned.
  • this method takes a list of relationship names that appear on the schema drawing of the database. This method starts at the specified object instance, and gets a list of all of the object instances that are related to this object by the first relationship in the list. Then for each of these object instances the method creates a list of all of the object instances related to them by the next relationship in the list. This continues until all of the relationships in the list have been navigated. Finally, the resulting list is filtered to only include objects instances belonging to the specified class. This list of object instances is then returned. Each of the returned object instances is returned with a list of the object instances that relate it to the starting point.
  • the NavigateToUnique method takes the same list of arguments as the NavigateTo method. It also works in the same way and returns a list of objects that belong to the specified class, that are related to the starting point by a list of relationships. The important difference is that this method returns a unique list of object instances. This means that if the same object instance is related to the starting point via more than one other object instance this method will still only return one reference to it. The previous method would return multiple references to the same object instance. Each of the returned object instances are returned with a list of the object instances that relate it to the starting point.
  • the schema tool 400 is common to the different function described above. It comprises, broadly, a database of schemas in XML, the schema of this database itself (the schema of schema) being a member of the database.
  • a schema or general Data Model may be represented both programmatically and in XML format.
  • a Schema may be transcribed into an XML format by following a fixed set of rules. These rules mandate the format of a Document Type Description (DTD) and hence the format XML data that can be validated by that DTD.
  • DTD Document Type Description
  • a Schema can itself be analysed as a Data Model, it is possible to write down a Schema representation of a Schema. Given this analysis, and the rules for transcribing a Schema into a DTD and XML, it is possible go create generic descriptions of application data (i.e. Schemas) and to be able to save these descriptions using a Schema-DTD in Schema- XML.
  • Schemas generic descriptions of application data
  • Schema-DTD and the Schema-XML in the same file as the application specific data that the Schema describes, a generalized self-describing data format (SDDF) has been created.
  • SDDF self-describing data format
  • XML files in such a format may be read, validated and processed programmatically by tools that have no explicit knowledge of the application data.
  • Schemas can be captured using either the Shlaer-Mellor Information Model or the Unified Modelling Language (UML) Class Diagram, or a specialized combination of the two. Tools already exist that assist in capturing a Schema in either of these graphical formats, from simple graphical editors to specialized applications. When designing new Schemas is important to capture data objects and their relationships, but not their behaviour. (Behaviour is usually best captured by assigning Methods to an object.)
  • UML Unified Modelling Language
  • referential identifiers will be of the type referencedObjectld. Where an object references another object more than once, the meaning of the relationship must be expressed on the diagram.
  • Attribute names should be mixed case with no spaces, with the first letter lowercase.
  • Attributes of the same name must be of the same type across all objects.
  • Wrapper is a super-type object with PassTheParcel and Layer as sub-types.
  • the Wrapper attributes have been merged into the sub-type data.
  • R2 is a "isA" relationship.
  • LayerForfeit is an associative object for the many-many (R5) relationship.
  • Every object (Object) is always given a key identifier (objectld) that is unique amongst objects of that type. In the database world, this translates to every table having an auto-incrementing (_id) field.
  • objects may have a secondary identifier, if one of its attributes is unique, but this fact is generally not used.
  • R4 is a relationship with a super-type object. For instances of this relationship, it is important to say what the actual sub-type is, not just its identifier number.
  • Object attribute types can be shown on a Schema.
  • the types in the table below are some examples of these:
  • any Schema may be transcribed in to an XML DTD.
  • a set of rules has been defined that describe how to translate the Schema.
  • the translation rules are defined such that there is a one to one relationship between the Schema elements and corresponding XML elements.
  • Objects are represented as elements.
  • the object's key identifier is represented as an ID attribute on the XML element. This attribute is always called “id” irrespective of the Object's name. The attribute is always required.
  • the object's referential attributes are represented as IDREF attributes on the element. The name of this attribute is generally the name of the referenced object (be it either super or sub type) with Id appended. If an object has more than reference to the same object, then the name of the attribute is taken from the meaning of the relationship with Id appended. For example, a Container object might have references to both parent and child Container objects. These references would then be called parentld and childld (or alternatively parentContainerld and childContainerld). These attributes may be either required or implied.
  • IdType attributes that are synthesized by the flattening process described above, are represented by an Enumerated Attribute. These attributes are required if the corresponding super-type referential attribute is required.
  • All the object's non-identifier and non-referential attributes are represented as child elements of the object's XML element.
  • the list of these object attributes is given as the content of the object's element.
  • the child elements are marked to appear optionally or once, but in the given order.
  • An object's non-identifier and non-referential attributes that are of type xmlString are represented as a CDATA section in the content of the child element. This mapping is useful for "description" fields that could themselves contain XML mark-up. (Although the use of a CDATA section in the content is mandated here, this can only be encoded in the DTD as the child element's content being PCDATA solely. Content outside of the CDATA section will in general not be processed.) • An object's non-identifier and non-referential attributes that are of an enumerated type are represented as an Enumerated Attribute in the child element. This attribute is always called value. The attribute is always required. The content of this child element is always empty. o All other non-identifier and non-referential attributes are represented as a CDATA Attribute in the child element. This attribute is always called value. The attribute is always required. The content of this child element is always empty.
  • the data is valid according to the DTD.
  • the DTD should be embedded in the XML file with a DOCTYPE declaration.
  • References both ID and IDREF types must be unique across all elements in the XML data irrespective of their type. Since the Object names are unique and each Object has its own identifier, a unique XML-reference is created by concatenating the Object name, "_" and the Object's identifier.
  • the objects X allow behaviour to be associated with an object via Methods. These objects are an extension to a basic model of a Schema. o
  • the Custom Data object Y allows custom data to be associated with a Table or Field.
  • the Custom Data object is generally used to allow the capture of data that governs Schema-based generators. This object is an extension to a basic model of a Schema.
  • Schema Representation of a Schema given in Fig. 27, may be encoded as an XML DTD according to the rules given in above. The result of this is shown in Fig. 28. This DTD is referred to as the Schema-DTD.
  • Schema-XML XML that describes a Schema according to the Schema-DTD is called Schema-XML.
  • Schema-XML Once a Schema has been captured in Schema-XML, the Schema information can be made available programmatically.
  • programmatic Schema representation we can write Schema-driven tools, generators and applications.
  • any view or process that is applicable for any data model is a candidate for automatic or generated processing using a Schema Object.
  • Schema-XML Using Schema-XML, it is possible to create Self-Describing Data files. These files are XML files that contain both the Schema-XML that describes the nature of some application specific data and the application specific data itself.
  • An XML file the Schema-DTD DOCTYPE declaration followed by Schema-XML.
  • Schema-XML contains the Schema- Data and Application-Data elements.
  • the Schema-Data elements are validated using the Schema-DTD.
  • the Application-Data element is of unspecified content.
  • the Schema Object generates a dynamic DTD for the Application-Data when it processes the Schema-Data.
  • This XML file format is referred to as Self-Describing Data Format (SDDF).
  • SDDF Self-Describing Data Format
  • the processing of SDDF data is two stage: a. First the Schema-XML is read and validated by the XML DOM. Following this, a Schema Class Factory Object is created and the Schema-XML is passed to its GetSchemaObjectForSchemaXml method. This method returns a Schema Object; and b.
  • the Schema Object thus created has a DTD property that describes the Application-Data XML. Using this DTD and the Application-Data XML, the Application-Data can be read and validated by an XML DOM in its own right.
  • Figs. 29-31 show simple representations of three types of schemas used in the schema tool 400.
  • Fig. 29 is a simple schema.
  • the one-to-many relationship between ReferenceField and TableReference is designed to support super type relationships. (A field that references a super type in the schema can reference many sub types.)
  • an "IdType" attribute is used to indicate the sub type; its value is constrained by the DTD to be one of those given by the set of TableReference values.
  • Fig. 30 is a representation of a schema with counterparts.
  • the design implies that in the XML representation of the actual data, super type references are implemented by a single reference attribute whose name is equal to the relationship name.
  • the name attribute is a secondary identifier for Tables (i.e. Table names are unique within the schema).
  • object attributes that are counterparts of NormalField should be conditionally constrained by the application to one of the values that correspond to enumValue.
  • Fig. 31 is a representation of a different schema with counterparts. This design implies that in the XML representation of the actual data, super type references are implemented by as many sub type reference attributes as required. All these reference attributes will be marked as "#IMPLIED" in the DTD, and will share the same Relationship instance. In a single Object where more than one ReferenceAttribute has the same Relationship instance (via ObjectReference), then the ReferenceAttributes will form a group of which no more than one may be instantiated at any time (i.e. they form an mutually exclusive set). In the data domain, object attributes that are counterparts of NormalAttribute should be conditionally constrained by the application to one of the values that correspond to enumValue.
  • the schema tool 400 essentially comprises two elements:
  • This reconfigurable datamodel o Reads a validated database and identifies the associated schema type and version
  • Command Line interface to various tools that Operation operate on EASI databases. These include generators, translators, database validity checking etc.
  • Generator Used by the Generator Core Command File Identifies which Generator to run Identifies location of database to operate on Automatically produced using Generator GUI Panel or Command Line Operation
  • Generator Used by a Generator Options File Contains User-defined options controlling how design files are generated
  • Generator Encrypted Generator program files Module Files Produced by Generator Configuration Kit (Encrypted)
  • Template File Defines how to access data in the Generator Core Defines how to process data in the Generator Core Defines how to translate results into Design View Input to Generator Configuration Kit
  • Panel Layout Handwritten in XML Description Describes graphical layout representing a

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

L'invention concerne un générateur de vues qui comprend un noyau générateur ; et un générateur interagissant avec ledit noyau pour créer un générateur configuré pouvant extraire des données d'une base de données et les produire sous un ou plusieurs formats que définit l'utilisateur. L'invention concerne également des générateurs de fichiers de configurations, des procédés de navigation et des définitions de schémas utilisables avec la base de données.
PCT/GB2004/001086 2003-03-14 2004-03-15 Outils de base de donnees WO2004081698A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP04720646A EP1606735A2 (fr) 2003-03-14 2004-03-15 Outils de base de donnees

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
GB0305914A GB0305914D0 (en) 2003-03-14 2003-03-14 Navigation kit
GB0305906.0 2003-03-14
GB0305911.0 2003-03-14
GB0305906A GB0305906D0 (en) 2003-03-14 2003-03-14 Schema of schemas
GB0305914.4 2003-03-14
GB0305911A GB0305911D0 (en) 2003-03-14 2003-03-14 Automated database views

Publications (2)

Publication Number Publication Date
WO2004081698A2 true WO2004081698A2 (fr) 2004-09-23
WO2004081698A3 WO2004081698A3 (fr) 2004-12-23

Family

ID=32995436

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2004/001086 WO2004081698A2 (fr) 2003-03-14 2004-03-15 Outils de base de donnees

Country Status (2)

Country Link
EP (1) EP1606735A2 (fr)
WO (1) WO2004081698A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104102479A (zh) * 2013-04-10 2014-10-15 北汽福田汽车股份有限公司 一种obd变量定义源文件的自动生成方法

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"dwgBase RAD4CAD Adds Custom CAD Reporting To DMS/Workflow" MANAGIN AUTOMATION, [Online] 9 December 2002 (2002-12-09), XP002293868 Retrieved from the Internet: URL:http://news.managingautomation.com/ful lstory/17264> [retrieved on 2002-08-25] *
"XML and Electronic Design Automation (EDA)" COVER PAGES, [Online] 3 August 2002 (2002-08-03), XP002293867 Retrieved from the Internet: URL:http://xml.coverpages.org/xmlAndEDA.ht ml> [retrieved on 2004-08-25] *
BARU C ED - CAMMELLI A ET AL: "XViews: XML views of relational schemas" DATABASE AND EXPERT SYSTEMS APPLICATIONS, 1999. PROCEEDINGS. TENTH INTERNATIONAL WORKSHOP ON FLORENCE, ITALY 1-3 SEPT. 1999, LOS ALAMITOS, CA, USA,IEEE COMPUT. SOC, US, 1 September 1999 (1999-09-01), pages 700-705, XP010352388 ISBN: 0-7695-0281-4 *
RUNDENSTEINER E A ED - INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS: "Design tool integration using object-oriented database views" 7 November 1993 (1993-11-07), IEEE/ACM INTERNATIONAL CONFERENCE ON COMPUTER AIDED DESIGN. DIGEST OF TECHNICAL PAPERS (ICCAD). SANTA CLARA, NOV. 7 - 11, 1993, LOS ALAMITOS, IEEE. COMP. SOC. PRESS, US, PAGE(S) 104-107 , XP010216480 ISBN: 0-8186-4490-7 the whole document *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104102479A (zh) * 2013-04-10 2014-10-15 北汽福田汽车股份有限公司 一种obd变量定义源文件的自动生成方法

Also Published As

Publication number Publication date
EP1606735A2 (fr) 2005-12-21
WO2004081698A3 (fr) 2004-12-23

Similar Documents

Publication Publication Date Title
US10970474B2 (en) Method and system for editing text with a find and replace function leveraging derivations of the find and replace input
US10606573B2 (en) System and method for computer language migration using a re-architecture tool for decomposing a legacy system and recomposing a modernized system
US20040031015A1 (en) System and method for manipulation of software
US20060015839A1 (en) Development of software systems
US20020123991A1 (en) Method for querying a database in which a query statement is issued to a database management system for which data types can be defined
US20020091677A1 (en) Content dereferencing in website development
US20020002566A1 (en) Transfromation of marked up documents using a base architecture
WO2005029222A2 (fr) Procede et systeme de specification de definitions d'interfaces et de regles commerciales et generation automatique d'un logiciel de transformation et de validation de messages
US7668888B2 (en) Converting object structures for search engines
CN109710220B (zh) 关系型数据库查询方法、装置、设备及存储介质
CN112764743B (zh) 一种基于数据模型驱动自动生成软件的方法
US20080086683A1 (en) Reporting engine for object relational networks
US8433729B2 (en) Method and system for automatically generating a communication interface
Schwabe et al. Design and Implementation of Semantic Web Applications.
Wojszczyk et al. The process of verifying the implementation of design patterns—used data models
JP2003281149A (ja) アクセス権限設定方法および構造化文書管理システム
EP1606735A2 (fr) Outils de base de donnees
Marotta et al. Managing source schema evolution in web warehouses
Jakob et al. View creation of meta models by using modified triple graph grammars
JP3842574B2 (ja) 情報抽出方法および構造化文書管理装置およびプログラム
Troelsen et al. Exploring Entity Framework Core
Pohjonen et al. Interactive television applications using metaedit+
Škrbić et al. Bibliographic records editor in XML native environment
Orhan et al. OptML framework and its application to model optimization
Alonso Generating text search applications for databases

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004720646

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 2004720646

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2004720646

Country of ref document: EP