Misplaced Pages

#659340

21-537: The UUID that is associated with a u-form is immutable, however all data "contained" in the u-form are mutable (including the keys/names). The mutability of contained data combined with an immutable identifier make implementations of fully mutable, replicable digital objects possible. This has applications in distributed computing, non-relational database systems, information visualization, and knowledge representation systems. Navigational databases , Entity and associative entity relationships can be implemented by using

42-788: A UUID, or multiple UUIDs, as attribute values. The u-form's design goals center around supporting an open, extensible distributed information space, emphasizing the unambiguous identity of data objects and the separation between data storage, data characterization, and schema development. The use of non-semantic UUIDs combined with a simple attribute–value model draws a clear distinction between identity and data. Although u-forms share certain design characteristics with serialization formats such as XML , they should not be confused with such representational formats. Since u-forms are abstract, they do not specify any particular representational format. Indeed, they may be stored as or communicated via XML or other types of serialization. The operations defined for

63-419: A u-form are similar to associative arrays: U-forms have the following properties: Note that these are not limited to the standards for ISO, Microsoft, or DCE UUIDs though those are examples of acceptable sources of UUIDs. An important characteristic of u-forms, of significance to distributed database systems , is that they support a clear distinction between copying and replication of data objects. Copying

84-422: A u-form involves the creation of a new u-form (i.e., one with a different UUID), but with all attribute–value pairs identical to those of the original u-form. Replicating a u-form involves creating a new instance of the u-form with the same UUID as the original. Note that in a distributed system, two instances of the same u-form may be inconsistent (i.e., they may contain different attribute–value pairs). However,

105-583: Is both procedural and navigational. By contrast, the same data ( XML or HTML ) can be accessed using XPath , which can be categorized as declarative and navigational: data is accessed by following relationships, but the calling program does not issue a sequence of instructions to be followed in order. Languages such as SPARQL used to retrieve Linked Data from the Semantic Web are also simultaneously declarative and navigational. Procedural programming Too Many Requests If you report this error to

126-445: Is traditionally associated with the network model and hierarchical model of database , and conventionally describes data manipulation APIs in which records (or objects) are processed one at a time, iteratively. The essential characteristic as described by Bachman, however, is finding records by virtue of their relationship to other records: so an interface can still be navigational if it has set-oriented features. From this viewpoint,

147-564: The 1960s. IDS became the basis for the CODASYL database model in 1969. Although Bachman described the concept of navigation in abstract terms, the idea of navigational access came to be associated strongly with the procedural design of the CODASYL Data Manipulation Language . Writing in 1982, for example, Tsichritzis and Lochovsky state that "The notion of currency is central to the concept of navigation." By

168-421: The 1980s, navigational APIs (and in particular, procedural APIs) were criticized and fell out of favour. The 1990s, however, brought a new wave of object-oriented databases that often provided both declarative and procedural interfaces. One explanation for this is that they were often used to represent graph-structured information (for example spatial data and engineering data) where access is inherently recursive:

189-430: The above query would be executed using procedural logic along the lines of the following pseudo-code: On this viewpoint, the key difference between navigational APIs and the relational model (implemented in relational databases ) is that relational APIs use "declarative" or logic programming techniques that ask the system what to fetch, while navigational APIs instruct the system in a sequence of steps how to reach

210-568: The basis of a number of significant research and large-scale production systems, most notably the US Army's Command Post of the Future . Navigational database A navigational database is a type of database in which records or objects are found primarily by following references from other objects. The term was popularized by the title of Charles Bachman 's 1973 Turing Award paper, The Programmer as Navigator . This paper emphasized

231-440: The database structure evolves.) Navigational interfaces, as a result, were gradually eclipsed during the 1980s by declarative query languages. During the 1990s it started becoming clear that for certain applications handling complex data (for example, spatial databases and engineering databases), the relational calculus had limitations. At that time, a reappraisal of the entire database market began, with several companies describing

SECTION 10

#1732779996660

252-427: The fact that the new disk-based database systems allowed the programmer to choose arbitrary navigational routes following relationships from record to record, contrasting this with the constraints of earlier magnetic-tape and punched card systems where data access was strictly sequential. One of the earliest navigational databases was Integrated Data Store (IDS), which was developed by Bachman for General Electric in

273-672: The fact that they have the same UUID means that they are intended to eventually be identical. U-forms were developed at MAYA Design as part of the Visage Information Visualization System , a joint project of MAYA and Carnegie Mellon University funded by DARPA and The Army Research Laboratory . The name "u-form" derives from the term "e-form", a hypothetical "electronic form" proposed by Michael Dertouzos in his 1997 book "What Will Be". In addition to their continuing use in Visage, they have been used as

294-439: The key difference between navigational data manipulation languages and relational languages is the use of explicit named relationships rather than value-based joins: for department with name="Sales", find all employees in set department-employees versus find employees, departments where employee.department-code = department.code and department.name="Sales" . In practice, however, most navigational APIs have been procedural:

315-549: The keys that appear at each level in the hierarchy. Such composite identifiers are found in computer file names ( /usr/david/docs/index.txt ), in URIs, in the Dewey decimal system, and for that matter in postal addresses. Such a composite key can be considered as representing a navigational path to a record; but equally, it can be considered as a simple primary key allowing associative access. As relational systems came to prominence in

336-429: The maintenance of an implicit set of global variables ( currency indicators ) holding the current state. As such, the approach was seen as diametrically opposed to the declarative programming style used by the relational model . The declarative nature of relational languages such as SQL offered better programmer productivity and a higher level of data independence (that is, the ability of programs to continue working as

357-506: The mathematics underpinning SQL (specifically, first-order predicate calculus ) does not have sufficient power to support recursive queries, even those as simple as a transitive closure . A current example of a popular navigational API can be found in the Document Object Model (DOM) often used in web browsers and closely associated with JavaScript . The DOM is essentially an in-memory hierarchical database with an API that

378-558: The new systems using the marketing term NoSQL . Many of these systems introduced data manipulation languages which, while far removed from the CODASYL DML with its currency indicators, could be understood as implementing Bachman's "navigational" vision. Some of these languages are procedural; others (such as XPath ) are entirely declarative. Offshoots of the navigational concept, such as the graph database , found new uses in modern transaction processing workloads. Navigational access

399-466: The notion of currency, they refer to the idea that a program maintains (explicitly or implicitly) a current position in any sequence of records that it is processing, and that operations such as GET NEXT and GET PRIOR retrieve records relative to this current position, while also changing the current position to the record that is retrieved. Navigational database programming thus came to be seen as intrinsically procedural ; and moreover to depend on

420-479: The physical placement of data. It is quite possible to implement navigational APIs without low-level pointer chasing (Bachman's paper envisaged logical relationships being implemented just as in relational systems, using primary keys and foreign keys), so the two ideas should not be conflated. But without the performance benefits of low-level pointers, navigational APIs become harder to justify. Hierarchical models often construct primary keys for records by concatenating

441-448: The required records. Most criticisms of navigational APIs fall into one of two categories: For many years the primary defence of navigational APIs was performance. Database systems that support navigational APIs often use internal storage structures that contain physical links or pointers from one record to another. While such structures may allow very efficient navigation, they have disadvantages because it becomes difficult to reorganize

SECTION 20

#1732779996660
#659340