Re: Normalization (was Left AS/400 and Returned) -- MIDRANGE-L

The best, although somewhat less than perfect, database that we know is the human brain. I am sure that that is not normalised, at least mine certainly isn't after a few beers. There is plenty of redundant data. But, unlike most computer databases, it doesn't need to be shut down to accomodate new types of data and no physical database design is required. The brain is a "slow" mechanism, yet, in many areas, can achieve results, such as recognising other human beings, that the fastest supercomputer is no where near achieving.

The perfect solution doesn't exist - what matters is that the resulting system meets initial end user needs and is able to evolve in line with the ever changing real world of the end user. It must be stable and scaleable and have very rapid performance.

Because of the limitations of existing databases, including RDMBS's, I decided to develop a "Neural Database", that, since it defines its own structure, can be changed whilst it is live. I have patented this.

No physical database design is required. Although the database is always highly normalised, it can be created and changed by people with no understanding of 3rd normal form. All data definitions, menus, business rules, application definitions, etc., and the user data that these define, are all stored in the same nine physical files. All have the same structure and the same single key field. All are journalled. No logical files are used. There is no limit to the amount of data that can be stored in any "logical" record. The NDB can store both hierarchical (up to 1 billion**2 levels) and network structures and relationships, all totally integrated. Entities can belong to multiple entity types. All attributes can have, by default, multiple iterations. Attributes can store independent data, such as text, or relatonships. There can be relationships at any level in an hierarchical structure so there can be relationships with relationships. All relationships, by default, are many to many, although one to many and many to one are also possible. Everything is indexed so there are no joins. The NDB allows the storage of both public and private data definitions and user data and these can be mixed as desired.

The NDB drives a small set of kernel programs that read the NDB and interpret the rules and data. They allow users to navigate relationships or drill down through hierarchies or display directories on the IFS. When new applications are created, no new files are created. The kernel progams handle the interface, including HTML and Javascript generation, the equivalent of triggers, etc. Commitment control boundaries are defined in the NDB.

It is astonishingly simple, allows incremental development without a detailed written specifcation, is largely self documenting and is extremely productive for development and maintenance (e.g. 10 man months work using traditional methods reduced to 2 hours). It has outstanding performance and is very scaleable.

Many complex applications can be created without any program coding. No code is generated (it is not a case tool) and mostly no new AS/400 objects are created. Security is outstanding and can be at the field level. Security for the same data for the same user can be different in different applications. The biggest problem with existing methods is that, unlike the brain, the rules are separated from the data and it is this that makes maintenance such a nightmare.

I checked with David before posting this .

Rob Dixon
www.erros.co.uk