From Newsgroup: comp.databases.theory

On Saturday, 4 July 2020 21:48:32 UTC+10, yanka...@gmail.com wrote:
Derek
Could you please explain a bit more the Open Architecture standard from 1984 perfected in 1990 from a non-hardware point of view? (http://www.softwaregems.com.au/Documents/Article/Application%20Architecture/Open%20Architecture.pdf)

This is a substantial subject, so I have opened a new thread.
First, please note, paying customers obtain documents with far more detail. The documents that I have made available to the public are simplified forms, minus configuration details, and minus the content that I deliver in courses. This is a one-page public doc, of a five-page customer doc or about 10 pages of SQL Developer Course content. Nevertheless, I will answer specific questions.
Second, since you are quoting me, allow me to clarify what I meant:

Open Architecture standard from 1984

Which was known to all professionals at the time. And still is.
But a full 95% of the people who implement systems these dark days are uneducated in the relevant sciences, and unprofessional in their implementation (ie. without standards).
Theoreticians in those days were not interested in Standards, on the basis that it was an implementation concern. Theoreticians and "theoreticians" these days have made that a fortified position. This is so that they can continue generating theory that has no relevance in the practical world, because even the reference to a Standard usually destroys the theory. Eg. You may have noticed that I regularly destroy the anti-Relational theory that the freaks come up with, to fix some fantasised problem, by providing the Relational solution that eliminates said problem (and thus no solution is necessary).

Open Architecture

The purpose. The term means:
- one and only one database where a particular data element is stored
- that is open
- to being queried by anyone, using any database reporting tool (simple & cheap or complex & expensive)
--- (ie. *not* limited to accessing the data via one or more or a mixture of apps)
- which allows the corporation to enjoy the first and foremost principle of a database: one version of the truth, in one place
The Standard provides such a database, one that is available to all compliant apps, and any report tool. Further it prevents non-compliant apps from their destructive actions.
(Separately, a fully Relational database provides full OLAP, in addition to full OLTP, so the report tool is simple and cheap. Whereas the RFS labelled as "relational", which is heavily promoted by the "theoreticians" in this space, require a massive and expensive OLAP transformation layer, such as BusinessObjects.)
The absence of Open Architecture, is not "closed architecture", a term that is somewhat used to identify the counterpoint, but a Non-Arcjitecture.

Open Architecture standard

Thus the term has disappeared from use, because everyone these days pretends that their monolith is "architecture", that their non-architecture is "architecture". Those lies start to crumble when one uses specific terms.
Gee, why would anyone want an open database, when everyone is screaming about the hell they have with closed databases, that the "theoreticians" and the uneducated dummies that implement their methods declare that that is the only architecture there is, that that is the only way to build an app.

perfected in 1990

That is, the details, the standards necessary for the various elements, were either already extant, or extant and then modulated for the context of the Relational Model and an genuine SQL platform.
In those heady days when the first few genuine Relational/SQL platforms came out, the correct method, the correct approach was discussed and easily defined, due to:
a. Codd's Relational Model (the implications that a normal human would determine)
b. Codd's Twelve Rules (famous document at the time, to ensure platform suppliers were supplying genuine Relational capability)
c. existing standards that were well-established in the pre-Relational platforms. Such as OLTP Standards for ACID Transactions (which all SQL-compliant platforms have, and which the fraudulent "sql" providers do NOT have).
----
I doubt that I have answered anything that is relevant to what you are seeking. If you could please as a specific question, maybe quote a term that I use in that condensed document, that you seek exposition for, I would be pleased to provide a specific answer.

from a non-hardware point of view

Please be more specific.
Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Monday, July 6, 2020 at 6:37:03 AM UTC-4, Derek Ignatius Asirvadem wrote:

On Saturday, 4 July 2020 21:48:32 UTC+10, yanka...@gmail.com wrote:

Derek

Could you please explain a bit more the Open Architecture standard from 1984 perfected in 1990 from a non-hardware point of view? (http://www.softwaregems.com.au/Documents/Article/Application%20Architecture/Open%20Architecture.pdf)

This is a substantial subject, so I have opened a new thread.

First, please note, paying customers obtain documents with far more detail. The documents that I have made available to the public are simplified forms, minus configuration details, and minus the content that I deliver in courses. This is a one-page public doc, of a five-page customer doc or about 10 pages of SQL Developer Course content. Nevertheless, I will answer specific questions.

Second, since you are quoting me, allow me to clarify what I meant:

Open Architecture standard from 1984

Which was known to all professionals at the time. And still is.

But a full 95% of the people who implement systems these dark days are uneducated in the relevant sciences, and unprofessional in their implementation (ie. without standards).

Theoreticians in those days were not interested in Standards, on the basis that it was an implementation concern. Theoreticians and "theoreticians" these days have made that a fortified position. This is so that they can continue generating theory that has no relevance in the practical world, because even the reference to a Standard usually destroys the theory. Eg. You may have noticed that I regularly destroy the anti-Relational theory that the freaks come up with, to fix some fantasised problem, by providing the Relational solution that eliminates said problem (and thus no solution is necessary).

Open Architecture

The purpose. The term means:
- one and only one database where a particular data element is stored
- that is open
- to being queried by anyone, using any database reporting tool (simple & cheap or complex & expensive)
--- (ie. *not* limited to accessing the data via one or more or a mixture of apps)
- which allows the corporation to enjoy the first and foremost principle of a database: one version of the truth, in one place

The Standard provides such a database, one that is available to all compliant apps, and any report tool. Further it prevents non-compliant apps from their destructive actions.

(Separately, a fully Relational database provides full OLAP, in addition to full OLTP, so the report tool is simple and cheap. Whereas the RFS labelled as "relational", which is heavily promoted by the "theoreticians" in this space, require a massive and expensive OLAP transformation layer, such as BusinessObjects.)

The absence of Open Architecture, is not "closed architecture", a term that is somewhat used to identify the counterpoint, but a Non-Arcjitecture.

Open Architecture standard

Thus the term has disappeared from use, because everyone these days pretends that their monolith is "architecture", that their non-architecture is "architecture". Those lies start to crumble when one uses specific terms.

Gee, why would anyone want an open database, when everyone is screaming about the hell they have with closed databases, that the "theoreticians" and the uneducated dummies that implement their methods declare that that is the only architecture there is, that that is the only way to build an app.

perfected in 1990

That is, the details, the standards necessary for the various elements, were either already extant, or extant and then modulated for the context of the Relational Model and an genuine SQL platform.

In those heady days when the first few genuine Relational/SQL platforms came out, the correct method, the correct approach was discussed and easily defined, due to:
a. Codd's Relational Model (the implications that a normal human would determine)
b. Codd's Twelve Rules (famous document at the time, to ensure platform suppliers were supplying genuine Relational capability)
c. existing standards that were well-established in the pre-Relational platforms. Such as OLTP Standards for ACID Transactions (which all SQL-compliant platforms have, and which the fraudulent "sql" providers do NOT have).

----

I doubt that I have answered anything that is relevant to what you are seeking. If you could please as a specific question, maybe quote a term that I use in that condensed document, that you seek exposition for, I would be pleased to provide a specific answer.

from a non-hardware point of view

Please be more specific.

Cheers
Derek

I haven't checked in here for a long time. Nice to see
that some one is holding forth on the standard. Keep up the good work.
Ed
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

On Wednesday, 15 July 2020 04:28:02 UTC+10, edpr...@gmail.com wrote:

On Monday, July 6, 2020 at 6:37:03 AM UTC-4, Derek Ignatius Asirvadem wrote:

I haven't checked in here for a long time. Nice to see
that some one is holding forth on the standard. Keep up the good work.

Ed

Thank you
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.databases.theory

The following thread is relevant to this one.
__ https://groups.google.com/g/comp.databases.theory/c/LSoYp9wrv0M

Cheers
Derek
--- Synchronet 3.21d-Linux NewsLink 1.2