文档 (1).docx

° There are SQL extensions that allow construction of JSON objects in each row of a query result. For example, PostgreSQL supports a json build object() function. As an example of its use, json build object(\'ID\', 12345, \'name\' \'Einstein\') returns a JSON object {\"ID\": 12345, \"name\", \"Eins...

° There are SQL extensions that allow construction of JSON objects in each row of a query result. For example, PostgreSQL supports a json build object() function. As an example of its use, json build object(\'ID\', 12345, \'name\' \'Einstein\') returns a JSON object {\"ID\": 12345, \"name\", \"Einstein\"}. ° There are also SQL extensions that allow creation of a JSON object from a collection of rows by using an aggregate function. For example, the json agg aggregate function in PostgreSQL allows creation of a single JSON object from a collection of JSON objects. Oracle supports a similar aggregate function json objectagg, as well as an aggregate json arraytagg, which creates a JSON array with objects in a specified order. SQL Server supports a FOR JSON AUTO clause that formats the result of an SQL query as a JSON array, with one element per row in the SQL query. SQL queries can extract data from a JSON object using some form of path constructs. For example, in PostgreSQL, if a value v is of type JSON and has an attribute "ID", v−\>'ID' would return the value of the "ID" attribute of v. Oracle supports a similar feature, using a "." instead of "−\>", while SQL Server uses a function JSON VALUE(value, path) to extract values from JSON objects using a specified path. The exact syntax and semantics of these extensions, unfortunately, depend entirely on the specific database system. You can find references to more details on these extensions in the bibliographic notes for this chapter, available online. 8.1.3 XML The XML data representation adds tags enclosed in angle brackets, \, to mark up information in a textual representation. Tags are used in pairs, with \ and \ delimiting the beginning and the end of the portion of the text to which the tag refers. For example, the title of a document might be marked up as follows: \Database System Concepts\ Such tags can be used to represent relational data specifying relation names and attribute names as tags, as shown below: \ \ CS-101 \ \ Intro. to Computer Science \ \ Comp. Sci. \ \ 4 \ \ \ \ P-101 \ \ \ Cray Z. Coyote \ \ Route 66, Mesa Flats, Arizona 86047, USA \ \ \ \ Acme Supplies \ \ 1 Broadway, New York, NY, USA \ \ \ \ \ RS1 \ \ Atom powered rocket sled \ \ 2 \ \ 199.95 \ \ \ \ SG2 \ \ Superb glue \ \ 1 \ \ liter \ \ 29.95 \ \ \ \ 429.85 \ \ Cash-on-delivery \ \ 1-second-delivery \ \ Figure 8.2 XML representation of a purchase order. Unlike with a relational schema, new tags can be introduced easily, and with suitable names the data are "self-documenting" in that a human can understand or guess what a particular piece of data means based on the name. Furthermore, tags can be used to create hierarchical structures, which is not possible with the relational model. Hierarchical structures are particularly important for representing business objects that must be exchanged between organizations; examples include bills, purchase orders, and so forth. Figure 8.2, which shows how information about a purchase order can be represented in XML, illustrates a more realistic use of XML. Purchase orders are typically generated by one organization and sent to another. A purchase order contains a variety of information; the nested representation allows all information in a purchase order to be represented naturally in a single document. (Real purchase orders have considerably more information than that depicted in this simplified example.) XML provides a standard way of tagging the data; the two organizations must of course agree on what tags appear in the purchase order and what they mean. The XQuery language was developed to support querying of XML data. Further details of XML and XQuery may be found in Chapter 30. Although XQuery implementations are available from several vendors, unlike SQL, adoption of XQuery has been relatively limited. However, the SQL language itself has been extended to support XML in several ways: XML data can be stored as an XML data type. SQL queries can generate XML data from relational data. Such extensions are very useful for packaging related pieces of data into one XML document, which can then be sent to another application. The extensions allow the construction of XML representations from individual rows, as well as the creation of an XML document from a collection of rows by using an XMLAGG aggregate function. SQL queries can extract data from an XML data type value. For example, the XPath language supports "path expressions" that allow the extraction of desired parts of data from an XML document. You can find more details on these extensions in Chapter 30. 8.1.4 RDF and Knowledge Graphs The Resource Description Framework (RDF) is a data representation standard based on the entity-relationship model. We provide an overview of RDF in this section. 8.1.4.1 Triple Representation The RDF model represents data by a set of triples that are in one of these two forms: 1\. (ID, attribute-name, value) 2\. (ID1, relationship-name, ID2) where ID, ID1 and ID2 are identifiers of entities; entities are also referred to as resources in RDF. Note that unlike the E-R model, the RDF model only supports binary relationships, and it does not support more general n-ary relationships; we return to this issue later. The first attribute of a triple is called its subject, the second attribute is called its predicate, and the last attribute is called its object. Thus, a triple has the structure (subject, predicate, object)