Technical FAQ

1. What is kinodb?

kinodb is a technology that enables data-centric applications to be created very rapidly.

2. How can kinodb deliver the claimed productivity benefits?

kinodb maintains metadata that describes the application in terms of its data entities and business rules. kinodb creates and modifies the required tables and indexes in the underlying RDBMS, ensuring that they are always in sync with the metamodel. kinodb uses its understanding of the data structures and associated rules (validation, referential integrity, security constraints etc), to automatically produce the required SQL, forms and control logic. The normal development cycle is therefore short-circuited, as the following diagrams illustrate.

In a conventional development environment, the cycle from gathering requirements to user approval contains several iterations of coding, forms design, logic implementation and testing.

Changes to requirements (resulting either from users viewing a part of the completed system, or from a change in the business environment) require significant rework and involve extensive testing to prevent adverse impact on other parts of the system.

Using kinodb, the design of the application is maintained within kinodb's metadata repository. Any changes to the design are immediately reflected in the application's data structures, forms, generated SQL, reports and so on. The initial implementation is faster, and any changes can be accommodated without the need to extensive rework and testing.

3. Why is this faster than conventional forms-building tools?

Imagine a medium-sized database containing 40 tables and three security levels (read-only, limited access and full rights for an administrator). 15 of these tables present additional complexity in terms of having subtypes (see below for a description of how kinodb allows entity subtyping) requiring the display of different sets of fields - assume an average of five subtypes for each of these tables. Ten tables also contain pictures or other non-alphanumeric data types, again requiring specific treatment.

The application therefore needs 25 forms each requiring three implemented and tested variations, plus 15 forms each requiring an average of 15 variants (three security levels x five variations for different record subtypes). That's 40 forms in a total of 300 different variations.

Using kinodb, you define the business rules for each field as a part of the capture of the design requirements. These will include basics such as the type of the field, its displayed length and format, whether it is mandatory, whether it can be edited once saved and so on. Also defined are validation rules and whether the field inherits the security settings of its owning table, or (if not), what authorisations are required to view or change it.

All of this information is captured as a matter of course during any system design. However, because kinodb maintains this data, it can use it to construct forms on the fly. It can also produce a report documenting the designed behaviour of every field in the application. Total development effort: zero.

When requirements change, the design can be updated and every form that is affected will automatically match the design the next time that it is required. Conventional development tools will require that an impact analysis be performed to determine which forms are affected, followed by further development and testing.

4. What retraining is required for technical teams?

Technical staff with an understanding of relational database design will quickly become productive in using kinodb. Also, kinodb creates standard relational databases that can be used by other development tools as required.

5. How is security implemented?

kinodb supports the concept of 'realms'. A realm contains a number of entities with similar security constraints – for instance an application might have 'HR', 'Finance' and 'Sales' realms. Each realm may then have any number of access levels to which users may then be assigned. The 'Employees' table might belong to the HR realm, with global view access for name & contact fields but with more constrained access levels for sensitive details such as salary and review history. The 'Orders' table might exist in the Sales realm, with view rights available globally; create / view / update capabilities for users of normal access level and delete capabilities reserved for users with Administrative access rights within the Sales realm.

All forms follow this security model, with forms being created appropriately to the access rights of the requesting user. Menu items are also controlled by the security model, so that users only see the menu options for which they are authorised. Additionally, menu structures are built dynamically so that a user with access to a small area of functionality sees the first menu to which they have access as their root menu. This means that large systems with disparate user types can share a single menu structure, which will be presented to them appropriately to their respective access rights.

6. What about Binary Large Object (BLOB) data types?

kinodb supports BLOBs. Pictures (JPEGs, GIFs, BMPs etc) are viewable within kinodb; other types (for instance Word documents) can be saved to disk or launched if the client supports them.

Check in / check out functionality is also available: this allows a BLOB to be checked out for revisions by one user at a time. Only this user can then check that BLOB back in, except when overridden by an administrative user.

7. What are the required browser capabilities?

Browser access to kinodb applications does not require any client-support for ActiveX, Java or Flash. All served content is standard HTML.

kinodb delivers tailors content according to the user's browser, taking advantage of differing capabilities where this is appropriate to the user interface.

Kinodb is tested against Internet Explorer, Netscape Navigator, Opera and Konqueror. The minimum requirement is for HTML Forms and Javascript 1. Best results are achieved if the browser supports DOM DHTML.

For small-screen devices such as PDAs, 'decorative' graphical content is reduced, and BLOBs are resized in order to maximise application usability.

8. Does kinodb support entity subtypes?

Yes. Any number of fields within a record may be designated as subtype definitions. Such fields then control the applicability of other fields within individual records. For instance, a person record can be set up to have a salary field, when the person is defined as a subtype 'Permanent staff' and an hourly rate when defined as 'Temporary staff'.

This functionality is fully integrated with the forms generation functionality, allowing the appropriate fields to be displayed and edited for any subtype.

9. Is data validation supported?

Yes, field values may be validated against:

• Values in the same record (for instance to ensure that a contract end date is after the start date)
• Fixed values (for instance to ensure that a value lies within a particular range)
• Derived values (for instance to ensure that an order being entered does not cause the sum of outstanding orders to exceed a customer's credit limit)
• System variables (for instance, to ensure that the start date is before today)

10. What databases are supported?

Currently, Oracle and Microsoft Access are supported. A database developed on either platform can be migrated to the other in minutes. We are investigating implementation of DB2 and SQL Server versions - if you have a specific interest in either platform please contact us for an update.

11. What client platforms are supported?

There are two clients available for use with a kinodb database. The first is a standard Windows-based executable that is normally used to access a kinodb database over a Local Area Network (LAN). This can be deployed on any current version of Windows (95, 98, NT, 2000, XP), accessing either MS Access or Oracle databases. This executable is also used to design kinodb databases.

The alternative mechanism is to use a standard browser, in which case a web server supporting Java Servlets (e.g. Apache Tomcat, Websphere etc) is required to run the kinodb server.

With the exception of database design functionality (available only using the Windows-based executable), these two mechanisms are functionally identical and entirely compatible: clients of both types can access a single database concurrently. A user can use the Windows-based client when connected via a high-bandwidth connection and a browser-based connection when accessing the same database remotely over the internet.

6. Question not answered?

Please fill out the form below, and we will be happy to answer any questions you may have about kinodb and datb. Alternatively, contact datb.