Dataphor is an open-source truly-relational database management system (RDBMS) and its accompanying user interface technologies, which together are designed to provide highly declarative software application development. The Dataphor Server has its own storage engine or it can be a virtual, or federated, DBMS, meaning that it can utilize other database engines for storage.
3.0 / February 2012
Dataphor has been praised for its adherence to relational principles, more closely so than any SQL product.
The stated purpose of Dataphor is to attempt to raise the bar of automation when building and maintaining complex software applications. Originally referred to as a framework, Dataphor provides more of a software development platform, complete with its own programming and user interface paradigms.
Dataphor is broadly divided into two components: the Dataphor Server, and the Dataphor Frontend. The purpose of the Dataphor Server is to provide a standardized language and runtime for the definition, manipulation, and integrity of application data. The Frontend is concerned with the dynamic derivation of user interfaces and the presentation thereof in either the Windows or Web thin client.
Dataphor does not employ SQL as its primary database language since SQL purportedly violates important principles of the relational model. Dataphor's D4 language is based on the principles of Christopher J Date's and Hugh Darwen's Tutorial D, but with a Pascal-like imperative syntax.
Though Dataphor espouses to be truly relational, it does incorporate the concept of NULLs as found in SQL, which many claim to be contraindicated by the Relational Model. NULLs and the matter of managing missing information, however, continue to be debated.
In addition to the data management focus of the Dataphor Server, Dataphor includes tools which allow the presentation of user interfaces through Windows and Web "thin" clients. Dataphor takes advantage of the relational inference capabilities of the Dataphor compiler in order to allow complete GUI forms to be derived directly from the data model. The unique aspect of Dataphor's user interface "derivation" is that it may be based on any relational expression (query) rather than merely base tables.
Dataphor strives for theoretical compliance to relational principles. While they try to adhere to the principles in The Third Manifesto, they deviated in a few places from what the Third Manifesto strived for, but not in places that were violations of Codd's 12 rules. E.g. they included nulls, but they claim to have a systematic treatment of them.
While many systems built on SQL fail miserably with respect to Codd's rule 9 "Logical data independence", Dataphor applications can automatically change when the logical layer change. E.g. when a new column is added to the system, no additional development is needed to have that be a new field visible to the users for viewing or editing.
Expert opinions on DataphorEdit
Hugh Darwen has referred to D4, as a notable project in his talk entitled The Askew Wall. Chris Date refers to Dataphor as a product that attempts to implement the Third Manifesto. Fabian Pascal calls Dataphor "Truly Relational", and "superior to SQL"
In 1999, point of sale systems developer Softwise Inc, found they were writing much of the same code over and over again, and looked for a tool to automate their database applications. They didn't find an application which did what they want, so they created a division of their company, called it Alphora, and set some of their developers to build such a tool. That tool became Dataphor. It is said to be the first truly relational DBMS since IBM Business System 12. Development of Dataphor began shortly before 2000, with a 1.0 release in 2001.
In early 2008, the Alphora name and the Dataphor product were acquired by Database Consulting Group, which was founded by the original architects of Dataphor, who left Softwise in 2007. After the acquisition, Dataphor was re-licensed as open source under the BSD License.
Dataphor utilizes the Microsoft .NET Framework and is written entirely in C#. The following is a summary of the various technology components of Dataphor:
The Dataphor Server has several components including:
- Call-level interface - session management, process scheduler, etc.
- Data Dictionary Catalog - containing all of the Tables, Views, Operators, Constraints, References, and other schema objects.
- D4 Scanner, Parser, Emitter, and Compiler.
- D4 Runtime - including relational, and scalar processing
- Storage Integration layer - real-time translation to various dialects of SQL
While Dataphor supports a SQL flavor they call "RealSQL", D4 is the preferred language for use within Dataphor, D4 supports DDL and DML statements. D4 queries tend to look like Relational Algebra expressions with written out names of operators. For example:
|SQL statement||Equivalent D4 statement|
Data Definition LanguageEdit
The DDL for Dataphor bears many similarities to other DBMSs, but with an obviously Pascal-like twist. Many of the allowed DDL operations, like constraints, allow relational declarative statements to be used, which many believe is superior to the procedural style operations used in SQL.
Data Manipulation LanguageEdit
The DML syntax at first glance may appear to be similar to SQLs syntax, but because of D4's closer ties to relational algebra, the syntax has a cleaner definition, and most users greatly prefer it over SQL.
The Imperative Language in D4 is remarkably similar to Pascal in many respects. The largest distinction being that D4 also allows DDL and DML statements to be run in regular procedural code.
D4 was named after the similar-sounding Dataphor, the system that uses the language. It was some time after these names were decided that its creators discovered Tutorial D, and the coincidence it had with that name. Since discovering Tutorial D and The Third Manifesto, the creators have used The Third Manifesto as a guide in making Dataphor and D4. Since then, Hugh Darwen has referred to D4, as a notable project in his talk entitled The Askew Wall.
Federated Storage EngineEdit
While Dataphor has a storage engine of its own, it can also connect to other RDBMSes, and use them as a storage engine. Dataphor can use the following DBMSes as storage engines:
Dataphor can access Oracle, IBM Db2, Microsoft SQL Server, PostgreSQL, MySQL and any other storage engine with a single unified language.
The Dataphor Frontend library provides for the delivery of dynamically derived, or pre-designed static forms. The library is exposed as a standard set of D4 functions (called operators in D4) such as Form ('<library>', '<name>') and Derive ('<D4 expression>', '<form type>'). The resulting forms are described in an XML dialect called a Dataphor Form Document (DFD). The form description is high-level, consisting of a general description of the user interface aspects as they apply independent of client platform.
Dataphoria is an integrated development environment for:
- Editing D4
- Ad hoc execution of D4
- Creating, Editing, and Customizing (inherited) forms
- Managing libraries
- Analyzing execution plans
The Dataphor Windows Client is a thin client in the sense that it is not pre-programmed for a particular application. The Windows client establishes a connection to a Dataphor Server, from which it (through D4) requests form definitions and coordinates the manipulation of application data. The DFD documents are interpreted into concrete Windows Forms controls, but while maintaining the conceptual DOM of the DFD.
The Dataphor Web Client is a basic implementation of a Dataphor client, which is manifest as an ASP.NET web application. Like the Windows Client, the Web Client connects to and requests forms and data from and instance of the Dataphor Server. Rather than synchronizing a DFD to Windows controls, however, the Web Client renders HTML which is displayed in a browser. In this way, the Web "Client" is a client relative to the Dataphor Server, but a server relative to the end web browser.