sdo.das.rel.metadata.html

php的帮助文档,涉及到PHP的案例和基本语法,以及实际应用内容

    many departments and a department can contain many employees.
    This distinction will become evident when the remainder of the metadata 
    picks out the company-department and department-employee relationships 
    as containment relationships.
   </p>

   <p class="para">
    There are a few simple rules to be followed when constructing the 
    database metadata:
   </p>

   <ul class="itemizedlist">
    <li class="listitem">
     <p class="para">
      All tables must have primary keys, and the primary keys must be
      specified in the metadata. Without primary keys it is not possible 
      to keep track of object identities. As you can see from the SQL 
      statements that create the tables, primary keys can be 
      auto-generated, that is, generated and assigned by the database when
      a record is inserted. In this case the auto-generated primary key 
      is obtained from the database and inserted into the data object 
      immediately after the row is inserted into the database.
     </p>
    </li>

    <li class="listitem">
     <p class="para">
      It is not necessary to specify in the metadata all the columns 
      that exist in the database, only those that will be used. 
      For example, if the company table had another column that the 
      application did not want to access with SDO, this need not be 
      specified in the metadata. On the other hand it would have done 
      no harm to specify it: if specified in the metadata but never 
      retrieved, or assigned to by the application, then the unused column 
      will not affect anything.
     </p>
    </li>

    <li class="listitem">
     <p class="para">
      In the database metadata note that the foreign key definitions 
      identify not the destination column in the table which is pointed 
      to, but the table name itself. Strictly, the relational model 
      permits the destination of a foreign key to be a non-primary key.
      Only foreign keys that point to a primary key are useful for 
      constructing the SDO model, so the metadata specifies the table name.
      It is understood that the foreign key points to the primary key of 
      the given table.
     </p>
    </li>
   </ul>

   <p class="para">
    Given these rules, and given the SQL statements that define the 
    database, the database metadata should be easy to construct.
   </p>

   <div id="sdo.das.rel.metadata.database.model" class="section">
    <h2 class="title">What the Relational DAS does with the metadata</h2>
    <p class="para">
     The Relational DAS uses the database metadata to form most of the 
     SDO model. For each table in the database metadata, an SDO type 
     is defined. Each column which can represent a primitive value 
     (columns which are not defined as foreign keys) are added 
     as properties to the SDO type.
    </p>
    <p class="para">
     All primitive properties are given a type of string in the SDO model, 
     regardless of their SQL type. When writing values back to the 
     database the Relational DAS will create SQL statements that treat 
     the values as strings, and the database will convert them to the 
     appropriate type.
    </p>

    <p class="para">
     Foreign keys are interpreted in one of two ways, depending on the 
     metadata in the third argument to the constructor that defines
     the SDO containment relationships.
     A discussion of this is therefore deferred until the section on
     <a href="sdo.das.rel.metadata.html#sdo.das.rel.metadata.crels" class="link">
      SDO containment relationships
     </a>
     below.
    </p>
   </div>

   <div id="sdo.das.rel.metadata.approottype" class="section">
    <h2 class="title">Specifying the application root type</h2>
    <p class="para">
     The second argument to the constructor is the application root type.
     The true root of each data graph is an object of a special root type 
     and all application data objects come somewhere below that. Of the 
     various application types in the SDO model, one has to be the 
     application type immediately below the root of the data graph.
     If there is only one table in the database metadata, the application 
     root type can be inferred, and this argument can be omitted.
    </p>
   </div>

   <div id="sdo.das.rel.metadata.crels" class="section">
    <h2 class="title">Specifying the SDO containment relationships</h2>

    <p class="para">
     The third argument to the constructor defines how the types in the 
     model are to be linked together to form a graph. It identifies the 
     parent-child relationships between the types which collectively form a 
     graph. The relationships need to be supported by foreign keys to be 
     found in the data, in a way shortly to be described.
    </p>

    <p class="para">
     The metadata is an array containing one or more associative arrays, 
     each of which identifies a parent and a child. The example below shows 
     a parent-child relationship from company to department, and another 
     from department to employee. Each of these will become an SDO property 
     defining a multi-valued containment relationship in the SDO model.

    </p>
    <div class="example-contents">
<div class="phpcode"><code><span style="color: #000000">
<span style="color: #0000BB">&lt;?php<br />$department_containment&nbsp;</span><span style="color: #007700">=&nbsp;array(&nbsp;</span><span style="color: #DD0000">'parent'&nbsp;</span><span style="color: #007700">=&gt;&nbsp;</span><span style="color: #DD0000">'company'</span><span style="color: #007700">,&nbsp;</span><span style="color: #DD0000">'child'&nbsp;</span><span style="color: #007700">=&gt;&nbsp;</span><span style="color: #DD0000">'department'</span><span style="color: #007700">);<br /></span><span style="color: #0000BB">$employee_containment&nbsp;</span><span style="color: #007700">=&nbsp;array(&nbsp;</span><span style="color: #DD0000">'parent'&nbsp;</span><span style="color: #007700">=&gt;&nbsp;</span><span style="color: #DD0000">'department'</span><span style="color: #007700">,&nbsp;</span><span style="color: #DD0000">'child'&nbsp;</span><span style="color: #007700">=&gt;&nbsp;</span><span style="color: #DD0000">'employee'</span><span style="color: #007700">);<br /><br /></span><span style="color: #0000BB">$SDO_containment_metadata&nbsp;</span><span style="color: #007700">=&nbsp;array(</span><span style="color: #0000BB">$department_containment</span><span style="color: #007700">,&nbsp;</span><span style="color: #0000BB">$employee_containment</span><span style="color: #007700">);&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br /></span><span style="color: #0000BB">?&gt;</span>
</span>
</code></div>
    </div>


    <p class="para">
     Foreign keys in the database metadata are interpreted as properties 
     with either multi-valued containment relationships or single-valued 
     non-containment references, depending on whether they have a 
     corresponding SDO containment relationship specified in the metadata. 
     In the example here, the foreign keys from department to company (the 
     <var class="varname">co_id</var>
     column in the department table)
     and from employee to department (the
     <var class="varname">dept_id</var>
     column in the employee table) are interpreted as supporting the
     SDO containment relationships.
     Each containment relationship mentioned in the SDO containment relationships
     metadata must have a corresponding foreign key present in the
     database and defined in the database metadata. The values of the 
     foreign key columns for containment relationships do not appear in the 
     data objects, instead each is represented by a containment relationship 
     from the parent to the child. So the
     <var class="varname">co_id</var>
     column in the department row in the database, for example, does not 
     appear as a property on the department type, but instead as a 
     containment relationship called
     <var class="varname">department</var>
     on the company type.
     Note that the foreign key and the parent-child relationship appear to 
     have opposite senses: the foreign key points from the department to 
     the company, but the parent-child relationship points from company to 
     department.
    </p>

    <p class="para">
     The third foreign key in this example, the
     <var class="varname">employee_of_the_month</var>
     ,
     is handled differently.
     This is not mentioned in the SDO containment relationships metadata.
     As a consequence this is interpreted in the second way: it becomes 
     a single-valued non-containment reference on the company object, to
     which can be assigned references to SDO data objects of the employee 
     type. It does appear as a property on the company type. The way to 
     assign a value to it in the SDO data graph is to have a graph that 
     contains an employee object through the containment relationships, and 
     to assign the object to it. This is illustrated in the later examples 
     below.
    </p>
   </div>
  </div> 
 </div><hr /><div style="text-align: center;">
 <div class="prev" style="text-align: left; float: left;"><a href="sdo.das.rel.examples.html">Examples</a></div>
 <div class="next" style="text-align: right; float: right;"><a href="sdo.das.rel.examples.one-table.html">One-table examples</a></div>
 <div class="up"><a href="sdo.das.rel.examples.html">Examples</a></div>
 <div class="home"><a href="index.html">PHP Manual</a></div>
</div></body></html>