Beginning XML Databases (Wrox Beginning Guides)

This is where I go off at what might appear to be a tangent, describing the object model for data. From what youve read so far, it might be apparent that the object data model has something to do with XML documents. However, without even a brief explanation of the object data model it is unlikely that XML documents can ever truly be understood as being object structured and perhaps never properly understood at all. The last thing you want is to create XML documents containing only single-layer hierarchies, as shown in the previous section. Why? Because a single-layer flat structure does not take advantage of the true power of XML hierarchies, where structure is included within the data itself. In other words, some data that is normally data in a relational data model is likely to become metadata in an object model.

The object model is somewhat different from the relational model. The relational model tends to simplify structures (some may say complicate them) by application of normalization. Normalization helps to remove duplication from data by dividing data into related sets. The object data model, much like object methodologies for application programming languages, tends to simplify by reducing information to the smallest possible parts . Each part can operate independently of every other part in the database. Relationships still exist in the object data model but they are different. The relational model makes a very distinct separation between metadata (tables) and data (values in fields in tables). The object model also links information together, but in addition it can apply structure to the values of data, as well as the metadata.

The structures, connections, and specific terms used for the object data model are as follows :

• Class:  A class defines a structure into which data is stored, and is the equivalent of a relational entity or table. A class contains attributes for storing values in much the same way as a table uses fields for storing values into.

  It is essential to understand that a class is not the same thing as an object. An object is the instantiation or iteration of a class during execution. In other words, objects are created as one or more copies of a class. The class is the structural definitional element. The object is the data copy of the class.

  • Attribute:  An attribute defines specific slots within classes. Attributes are the equivalent of a relational entity column or field.

  • Collection:  A collection is a special type of attribute, and is the term applied to a repetition of elements of one class contained within another class. At run-time, that collection becomes a collection of objects. A collection effectively defines a one-to-many relationship between a parent class and a child class. A collection is similar to a relational entity on the many side of a one-to-many relationship.

• Method:  A method is unique to the object model where a method can contain executable code, applicable to objects instantiated from the class the method is attached to. A method is vaguely equivalent to a relational database stored procedure, except that a method executes on the data contents of an object within the bounds of that object. Methods are far more powerful than relational database stored procedures.

• Inheritance:  One class can inherit structure (attributes) and even methods from another class. In fact, during execution, an object that inherits structure from a parent class can even inherit attribute values. Again, the object model tends to make the difference between data and metadata more of a gray zone. Inheritance allows the application of any structure (attributes), values (attribute values), and functionality (methods), all the way down through a class hierarchy. A class inheriting from a parent class can use what is defined for a parent class, or can even redefine some or all of what is inherited.

  Retrieving attributes and behavior of a class of objects in a hierarchy is known as type casting, in which the specifics of one particular class are extracted from an object.

  • Multiple inheritance:  Some object models allow multiple inheritance. Multiple inheritance allows a class to inherit details from more than one class at the same time. The result is a hierarchy that goes both upward and downward. In fact, a class can be both a parent and a child of another class. Multiple inheritance can create a dual-direction hierarchical structure, which is flexible but can also be exceedingly complicated.

• Specialization and abstraction:  A specialization of a class is an inherited, specific type of a class. Specializations often substitute for what are usually called types in a relational database. For example, an employee and a manager are both employees of a company, but they are different types of employees. So, two specializations for company employees would be employees and managers. The result would be an abstraction of the employees and managers, and that could be a class containing descriptions of all people employed by the company. Specialization and abstraction are effectively the same thing in that they both involve inheritance of one class from another. The difference is semantic rather than syntactical. A specialization is created to divide a class into something like multiple types. An abstraction is created to generalize attributes, values and methods that are common to multiple classes.

Creating an Object Model from a Relational Model

Unlike a relational model, an object model supports relationships between objects through the structure of objects and the classes defining those objects. Classes are defined as containing collections of pointers to other classes, as being inherited from other classes above in a hierarchy, or as being abstractions of other classes below in a hierarchy ( inheritees ).

The relational model forces dependencies to exist between the different tables; otherwise data in different tables might be meaningless. The object model allows each structure to be autonomous of all other structures (self-contained). There is much less inter-object dependency in the object model than for the relational model. This is because, as already stated, the object model includes relationships within the structure of the model itself.

The diagram shown in Figure 8-2 is an ERD showing an enhanced version of the demographics database, relational data model used in this book (see Appendix B). The only change in Figure 8-2, in addition to what appears in Figure B-1 in Appendix B, is that an ECONOMY table is added. The ECONOMY table can contain values such as 1 ^st World, 2 ^nd World, and 3 ^rd World. This implies that each country is classifiable into one of these three economic categories.

Figure 8-2: Enhancing the relational model shown in Figure B-1

Figure 8-3 shows an object data model for the relational model shown in Figure 8-2. The Occupation class in Figure 8-3 is ignored in this case because the diagram is getting a little too cluttered.

Figure 8-3: Converting the enhanced relational model of Figure 8-2 to an object model

Figures 8-2 and 8-3 enhance the relational and object data models, making it clearer how relational types and relational many-to-many relationships are managed by the object data model.

Data models shown in Figures 8-2 and 8-3 are not implemented in this book. These data models are included here merely to demonstrate the way that the object model can handle relational database issues.

You should be able to see some obvious differences between the two diagrams in Figures 8-2 and 8-3. This is because there are two ways in which the object model can help to reduce the complexity of the relational model. The object model does not need types or many-to-many relationships:

• The object model in Figure 8-3 has no types. The ECONOMY table is a type table, as shown in the relational model of Figure 8-2. The object model in Figure 8-3 creates an individual class for each type in the ECONOMY table. This is an example of the object data model beginning to change some relational data into object metadata. Data of economic types of 1 ^st World Class, 2 ^nd World Class, and 3 ^rd World Class are represented in the object model by specializations of the Country Class.

• The many-to-many relationship between the POPULATION and LANGUAGE tables in the relational model is catered to in the object model by creating a class for different language groups. In other words, in Figure 8-3 a population in a country can speak one language (1 ^st language), speak two languages (bilingual), or even be multilingual (speak many languages).

The following can be concluded from the example conversion shown between Figures 8-2 and 8-3, in which a relational data model is converted to an object data model:

• The relationships between classes in an object model are represented by the class structure, those relationships being both collection inclusion and inheritance. The result is that static data, such as types with few unique values, can sometimes become metadata.

• The object model contains objects containing pointers to other contained objects.

• An invisible difference is the power of black-box processing using methods in an object database. The object model uses data abstraction to conceptualize both data and encapsulated functionality using methods. Inheritance allows the passing of data definition and functionality onto specialized objects and extensive coding reuse.

• The crux and greatest benefit of objects is in their simplicity. The more that objects are broken down into smaller granular pieces, the more powerful and efficient the structure becomes. A relational database cannot be broken down to the level of an object structure. Additionally, a relational structure can only be made more granular using normalization. Too much normalization can hurt performance drastically.

• The object model is therefore highly efficient at handling small, precise transactions. However, an object structure is dreadful at handling any kind of reporting because objects can become so very specific. Any kind of reporting using an object data model can require merging of data from an unmanageably large number of different objects, making reporting not viable . A relational structure can handle both reporting and small transaction sizes fairly well. The result is that the practical and commercial uses for object data modeling are in reality very limited.

Another form of a data model mixes both relational and object modeling methodologies. The result is the object-relational data model, which is irrelevant to this book and XML.