VICTORIA UNIVERSITY OF WELLINGTON Te Whare Wananga o te Upoko o te Ika a Maui SWEN 432 Advanced Database Design and Implementation Identity Constraints Lecturer : Dr. Pavle Mogin

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 1 Plan for XML Identity Constraints Defining XML Schema identity constraints: –Unique, –Key, –Key reference The syntax of XML Schema constraints The role of relative location path in defining constraints –Reading: XML Schema Part 0: Primer (W3C Recommendation, 2 May 2001) XML Schema Part 1: Structures

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 2 schoolReport.xml (1 of 2) <student id=“007” inTerm=“34.75”/> <student id=“131” inTerm=“30.75”/> <student id=“007” inTerm=“29.50”/> <student id=“505” inTerm=“33.00”/>

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 3 schoolReport.xml (2 of 2) James Bond James Smith Emmy Smith

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 4 student Partial Tree of schoolReport.xml d1d1 SchoolReport.xml e1e1 SchoolReport class students comp302 name classes id inTerm a1a1 e2e2 a2a2 e4e4 a3a3 007 student idinTerm e3e3 student class id inTerm student id inTerm 505 comp442 name a4a4 a4a4 a6a6 a5a5 e5e5 e6e6 e7e7 a7a e8e8 a8a8 a9a9 e 13

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 5 students e 13 Subtree students student 007 id James 131 id Emmy 505 id e 13 e 14 a7a7 a8a8 a9a9 e 15 name Bond surname t5t5 t6t6 Smith surname e 16 e 17 e 18 e 19 t7t7 t8t8 e 20 e 21 Smith surname e 22 t9t9 t 10

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 6 The School Report Schema <xsd:schema xmlns:xsd=“ School Report Schema

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 7 schoolReport Element <xsd:element name=“classes” type=“ClassesType”/> <xsd:element name=“students” type=“StudentsType”/>

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 8 key and keyref Declarations

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 9 Classes Type <xsd:element name=“student” maxOccurs=“unbounded”> <xsd:attribute name=“inTerm” type=“xsd:decimal”/>

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 10 Students Type <xsd:element name=“name” type=“xsd:string”> <xsd:element name=“surname” type=“xsd:string”>

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 11 Identity Constraints(1) An identity constraint is defined using elements: –unique | key | keyref (to declare the type (kind) of the constraint and to name it), –selector (to define the scope of the constraint), and –field (to designate a simple concept whose values have to be checked) A field can be either an element having simple type values, or an attribute If the constraint type is unique or keyref, field value can be declared to be optional or nilable Syntax: The xsd:keyref also has the attribute refer

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 12 Identity Constraints(2) XML Schema enables us to define: –A unique constraint, –A key constraint, and –A referential integrity constraint These three constraints apply to a certain part of a document only and their satisfaction is checked by an XML Schema processor The three important concepts: –The context node of the constraint, –The scope of the constraint, and –The argument of the constraint

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 13 Identity Constraints(3) The context node of a constraint is an element from which there is a downward path to the scope of the constraint The scope of a constraint defines a sequence of element instances within which the constraint has to be valid –A scope element is most often complex and multivalued –It is defined using a relative location path expression starting from the context node The argument of a constraint is a simple concept (a simple element or attribute) whose values have to obey to rules of the constraint within the scope: –To be unique and not null (key constraint), –To be unique (unique constraint), or –To reference an existing value of a key constraint

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 14 Location Path Example Consider the schoolReport.xml document, and suppose we want to values of each student to be unique and not null within students subtree Let schoolReport (e 1 ) be the context node The relative location path expression (called selector xpath ) students/student defines the scope and returns (e 14, e 17, e 20 ) The path (relative to the previously defined defines the argument (called field ) and returns (a 7, a 8, a 9 ) whose values have to be unique and not null

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 15 Where to Declare an Identity Constraint Identity constraints are declared within the content of an element in an XML Schema schema How to decide on this element –The identity constraint has to be valid in a sequence of document concepts (scope of the constraint), –The element from which there is a downward path to the element whose instances make the scope sequence, should be selected as the context node of the identity constraint, –The selector path leads from the context to the scope element, –The field path returns at most one single valued concept for each element instance in the sequence returned by the selector path

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 16 Simple Unique Constraint (Attribute) Suppose the next declaration is specified within the declaration of the classes element of the schoolReport.xsd Then value of each class in the classes have to be unique The context node of the xsd:selector ’s xpath is classes The sequence of context nodes of the xsd:field ’s xpath are class nodes (e 3, e 6 ) So, xsd:field ‘s xpath specifies that there should be a unique value of attribute associated with each class element in (e 3, e 6 ) (this also implies (a 1, a 4 ) should be unique)

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 17 Composite Unique Constraint (Element) Consider the schoolReport.xml and suppose the next declaration is specified within the content model of the students element Then the string values of each combination of name and surname elements in the students/student have to be unique The context node of the xsd:selector ’s xpath is students (e 13 ) The context nodes of the xsd:field ’s xpath are student nodes (e 14, e 17, e 20 )

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 18 Defining Keys & Their References The syntax for the key constraint is very similar to the syntax for defining the unique constraint The key declaration on a field means that (within the scope specified) field values: –Must be unique, and –Cannot be set to nil, or omitted A key enables defining a referential integrity constraint within the given scope

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 19 Key and Referential Integrity Example To insure that each student id in classes/class belongs to a real student in students, a key is defined within the declaration of the schoolReport element and it is referenced by that is also defined within the schoolReport element

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 20 Placement of key and keyref Constraints The key constraint has to be “visible” to the keyref constraint –i.e. there has to exist a non upwards path from the keyref definition to the key definition That means we can place –Both key and keyref within the schoolReport element, or –The key constraint within the students element and keyref within the schoolReport element But we can’t place: –The key constraint within the schoolReport element and the keyref constraint within the classes element, or –The key constraint within the students element and keyref within the classes element

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 21 Schema Versus DTD Constraints (1) XML 1.0 provides mechanisms: –For ensuring uniqueness using an attribute of the ID type and –References using attributes of the IDREF(S) type The ID/IDREF(S) types are applicable on attributes only and the scope of the ID constraint is a whole document Each ID value has to be unique across a whole document Additionally, ID attributes have to be single valued, composite uniqueness constraint can not be defined

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 22 Schema Versus DTD Constraints (2) The XML Schema supports ID and IDREF(S) types for compatibility reasons Contrary to ID/IDREF types, a field of XML Schema unique, keyref and key constraints can be either an element, or an attribute, their type can be any XML Schema basic type, and their scope can be precisely defined using XPath expressions Further, using multiple field elements, one can define a composite identity constraint

SWEN 432 Advanced Database Design and Implementation 2015 Identity Constraints 23 Summary XML Schema supports defining: –unique, –key, and –keyref constraints All three constraints have a very similar syntax containing two relative location path expressions: –The first one defines the hierarchical path to a non empty multivalued complex element that represents the scope –The second one defines either a descendant element having simple values, or an attribute (both are called “ field ”) of the selected complex element whose values have to be constrained