Free Essay

Schema Design

In:

Submitted By flemon
Words 6100
Pages 25
OpenTravel™ Alliance XML Schema Design Best Practices

Version 3.04 June 2006

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 2

1 2 3

OTA XML Schema Design Best Practices............................................................................. 4 XML Standard Specifications................................................................................................. 5 Best Practices.......................................................................................................................... 6 3.1 Scope.............................................................................................................................. 6 3.2 Schema Design Component Parts and Roles ................................................................. 6 4 OTA XML Schema Design Guidelines .................................................................................. 7 4.1 Tag Naming Conventions .............................................................................................. 7 4.1.1 Mixed Case ................................................................................................................ 7 4.1.2 Underscore................................................................................................................. 7 4.1.3 Acronyms................................................................................................................... 7 4.1.4 Word Abbreviations................................................................................................... 7 4.1.5 Tag Length................................................................................................................. 8 4.1.6 Complex Type Tag Names ........................................................................................ 8 4.1.7 Simple Type Tag Names 1 ........................................................................................ 8 4.1.8 Simple Type Tag Names 2 ........................................................................................ 8 4.1.9 Naming of Elements Based on Simple or Complex Types........................................ 8 4.1.10 Naming of Attributes Based on Simple Types ...................................................... 8 4.1.11 Common Suffixes.................................................................................................. 9 4.1.12 Standard Suffixes .................................................................................................. 9 4.2 Root Element, Message, and File Naming Conventions.............................................. 10 4.2.1 Root Element Naming ............................................................................................. 10 4.2.2 Use of Notif in Root Element Name........................................................................ 11 4.2.3 Message XML Schema File Naming....................................................................... 11 4.2.4 File naming for collections of Attribute Groups, Simple, and Complex Types ...... 11 4.2.5 Naming of XML Schema Files that Contain Common Components ...................... 11 4.3 Use of Elements and Attributes .................................................................................. 11 4.3.1 Elements vs. Attributes............................................................................................ 11 4.3.2 Number of Attributes per Element .......................................................................... 12 4.3.3 Encapsulating Element ............................................................................................ 12 4.4 Use of XML Schema.................................................................................................... 13 4.4.1 OTA Specification Uses XML Schema................................................................... 13 4.5 Global vs. Local Element Types .................................................................................. 13 4.5.1 Simple and Complex Types..................................................................................... 13 4.5.2 Type Attribute vs. Ref Attribute.............................................................................. 13 4.5.3 Attribute Groups ...................................................................................................... 14 4.6 Namespaces.................................................................................................................. 14 4.6.1 OTA Namespace...................................................................................................... 14 4.6.2 No Namespace for Common XML Schema Files ................................................... 15 4.6.3 Use of OTA Namespace in Instance Documents..................................................... 15 4.7 Versioning XML Schemas........................................................................................... 16 4.7.1 Version Attribute in XML Schema.......................................................................... 16 4.7.2 Version Attribute in Common XML Schema Files ................................................. 16 4.7.3 Version Attribute in XML Instance Documents...................................................... 16 4.7.4 ID Attribute in Message and Common XML Schema ............................................ 17 4.7.5 Use of schemaLocation Attribute ............................................................................ 17 4.8 Schema Markup and Annotations ................................................................................ 17 4.8.1 Use of Annotation and Document Elements............................................................ 17 4.8.2 Use of lang Attribute ............................................................................................... 18 4.8.3 Meaningful Annotations .......................................................................................... 18
© 2005 OpenTravel™ Alliance www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 3

4.8.4 Annotation of Typed Elements ................................................................................ 18 4.8.5 Annotations of Root Elements................................................................................. 19 4.8.6 Use of “may be”....................................................................................................... 19 4.8.7 Reference to Code Tables........................................................................................ 19 4.8.8 No Use of Processing Instructions........................................................................... 20 4.9 Enumerations vs. Code Lists........................................................................................ 20 4.9.1 Use of Enumerations................................................................................................ 20 4.9.2 Use of Code Lists .................................................................................................... 20 4.10 Code Lists .................................................................................................................... 20 4.10.1 Name of Code List Table .................................................................................... 20 4.11 OTA General................................................................................................................ 21 4.11.1 Required Attributes of XML Instance Root Elements ........................................ 21 4.11.2 Use of TPA_Extensions ...................................................................................... 21 4.11.3 Standard Simple Types vs. OTA Simple Types.................................................. 22 4.11.4 New Data Types Based on Extending Existing Types........................................ 22 4.11.5 Simple Type Restrictions .................................................................................... 22 4.11.6 Deprecation Policy .............................................................................................. 23 4.11.7 License Agreement Documentation .................................................................... 23

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 4

1 OTA XML Schema Design Best Practices
The IT Business world has long employed the principles of producing high quality products with a reduction of product development cost and faster “time-to-market” product delivery. In today’s global, Internet-ready marketplace, these principles are as critical to the bottom line as ever. One way that corporations can apply these “increased earning potential principles” is by establishing a common set of best practice XML and XML Schema guidelines. The current W3C XML specifications were created to satisfy a very wide range of diverse applications, which is why there may be no single set of “good” guidelines on how best to apply XML technology. However, when the application environment can be restricted by corporate direction or by a common domain, one can determine, by well-informed consensus, a set of effective guidelines that will lead to the best practice of using XML in that environment. This document defines the OpenTravel™ Alliance (OTA) Best Practices Guidelines for all of the OTA XML data assets. OTA message specifications released prior to the 2002A Specification release may not follow the guidelines defined in this document.

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 5

2 XML Standard Specifications
Currently, there are several XML related specification recommendations produced by W3C (http://www.w3.org/Consortium/). This section refers to the W3C recommendations (http://www.w3.org/Consortium/Process-20010719/) and versions listed below: • Extensible Markup Language (XML) 1.0 (Second Edition): • • http://www.w3.org/TR/2000/REC-xml-20001006

XML Schema Parts 0 - 2: • • • • http://www.w3.org/TR/2001/REC-xmlschema-0-20010502/ http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/ http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 6

3 Best Practices
3.1 Scope
The OTA Best Practices Guidelines cover all of the OTA XML components (elements, attributes, tag names, and Schema definitions). This document defines guidelines for all OTA XML data assets. The general OTA guideline approach is to maximize component (element/attribute) reuse for the highly diverse and yet closely related travel industry data. This is accomplished by building messages via context-driven component assembly. An example is the construction of a ‘Flight Leg’ segment from base objects such as ‘Time,’ ‘Date,’ and ‘Location’ (departure/arrival). The best mechanism that XML Schemas have to support this approach is by encapsulating lower level components (element and attribute objects) within named type definitions while using (and reusing) these base components to construct messages.

3.2 Schema Design Component Parts and Roles
The critical XML Schema guidelines that best support the OTA goal of a consistent set of reusable travel industry message content are listed below: • • • • • • • • • • • Tag Naming conventions Root Element, Message, and File Naming Conventions Elements and Attributes Use of XML Schema Global vs. Local Element Types Namespaces Versioning XML Schemas Schema Markup and Annotations Enumerations vs. Code Lists Code Lists General

Each of the items above plays a unique role, supporting a common vocabulary, syntax, and semantic grammar for XML Schema and XML component (element and attribute) definitions.

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 7

4 OTA XML Schema Design Guidelines
The subsections below form the complete set of OTA XML Schema Design Best Practices Guidelines. Each guideline is presented as follows: Guideline: The base rule (or rules) that should be followed for compliance with OTA Best Practices. Rationale: OTA general consensus reasoning for the guideline. Example:
An example (if applicable).

4.1 Tag Naming Conventions
4.1.1 Mixed Case
Guideline: Use mixed case tag names, with the leading character of each word in upper case and the remainder in lower case without the use of hyphens or spaces between words (a.k.a. Upper Camel Case (UCC) or “PascalCasing”). Rationale: This format increases readability and is consistent with common industry practices. Example:

4.1.2 Underscore
Guideline: Where the merger of tag name words and acronyms causes two upper case characters to be adjacent, separate them with an underscore (‘_’). Rationale: This technique eliminates or reduces any uncertainty for tag name meaning. Example:

4.1.3 Acronyms
Guideline: Acronyms are discouraged, but where needed, use all upper case. Rationale: In some cases, common acronyms inhibit readability. This is especially true for internationally-targeted audiences. However, in practice, business requirements and/or physical limitations may require the need to use acronyms. Example:

4.1.4 Word Abbreviations
Guideline: Word abbreviations are discouraged. However, where needed, use UCC camel case. Rationale: Abbreviations may inhibit readability. This is especially true for internationallytargeted audiences. However, in practice, business requirements and/or physical limitations may require the need to use abbreviations. Example:

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 8

4.1.5 Tag Length
Guideline: Element and attribute names should not exceed 25 characters. Tag names should be spelled out except where they exceed 25 characters, when standardized abbreviations should be applied. Rationale: This approach can reduce the overall size of a message significantly and limit impact to any bandwidth constraints. Example:
The tag: can be reduced to:

4.1.6 Complex Type Tag Names
Guideline: Complex type tag names should be suffixed with the word “Type” Rationale: This approach allows for complex types to be easily recognized, which encourages reuse. Example:

4.1.7 Simple Type Tag Names 1
Guideline: OTA data type simpleType tag names should clearly indicate the pattern that is used to define the simple type. Rationale: This approach supports meaningful tag names. Example:

4.1.8 Simple Type Tag Names 2
Guideline: All other OTA simpleType tag names should clearly indicate the usage of that type and should be suffixed with the word “Type”. Rationale: This approach supports meaningful tag names. Example:

4.1.9 Naming of Elements Based on Simple or Complex Types
Guideline: Elements that are based on complex or simple types must not be suffixed by “ComplexType,” “SimpleType,” or “Type.” Rationale: This technique reserves the “Type” suffix for complex and simple types, which allows for easy identification and reuse of types. Example: of type ProfilesType of type UniqueID_Type

4.1.10

Naming of Attributes Based on Simple Types

Guideline: Attributes that are based on simple types must not be suffixed by “SimpleType” or “Type”

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 9

Rationale: This technique reserves the “Type” suffix for complex and simple types, which allows for easy identification and reuse of types. Example: of type StringLength1to32 of type UpperCaseAlphaNumericLength3to5

4.1.11

Common Suffixes

Guideline: Use common tag name suffixes for elements defined by similar or common XML Schema type definitions. Rationale: This approach supports a consistent syntax and semantic meaning for elements and attributes. Example:

4.1.12

Standard Suffixes

Guideline: The OTA XML Schema attribute declarations should incorporate the following list of suffixes. These suffixes were taken from the list of Representation Terms found in the Core Components Technical Specification (CCTS) published by UN/CEFACT1. For simplicity, a ‘Representation Term’ is referred to here as a ‘Suffix’. For cases in which the length of an attribute name may exceed the 25 character limit, the Suffix abbreviation (included parenthetically) should be used since it requires fewer characters. Suffix Amount (Amt) Binary Object (BinObj) Definition A number of monetary units specified in a currency where the unit of currency is explicit or implied A set of finite-length sequences of binary octets. [Note: This Suffix shall also be used for Data Types representing graphics (i.e., diagram, graph, mathematical curves, or similar representation), pictures (visual representation of a person, object, or scene), sound, video, etc.] A character string (letters, figures, or symbols) that for brevity and / or language independence may be used to represent or replace a definitive value or text of a Property. [Note: The term 'Code' should not be used if the character string identifies an instance of an Object Class or an object in the real world, in which case the Suffix identifier should be used.]

Code

United Nations Centre for Trade Facilitation and Electronic Business Core Components Technical Specification- part 8 of the ebXML Framework 15 November 2003 Version 2.01. Available on-line at < http://www.untmg.org/doc_tmg.html>.

1

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 10

Suffix DateTime, Date, Time

Definition A particular point in the progression of time (ISO 8601). [Note: This Suffix shall also be used for Data Types representing only a Date or a Time.]. Examples: (CCYY-MM-DD); (hh:mm:ss[.ssss…[Z | +/-hh:mm]]); (CCYY-MM-DD [Thh:mm:ss [.ssss…[Z | +/-hh:mm]]])

Identifier (ID)

A character string used to establish the identity of, and distinguish uniquely, one instance of an object within an identification scheme from all other objects within the same scheme. A list of exactly two mutually exclusive Boolean values that expresses the only possible states of a Property. [Note: Indicated by a Boolean data type.] A numeric value determined by measuring an object. Measures are specified with a unit of measure. The applicable unit of measure is taken from UN/ECE Rec. 20. [Note: This Suffix shall also be used for measured coefficients (e.g., m/s).] Numeric information that is assigned or is determined by calculation, counting, or sequencing. It does not require a unit of quantity or a unit of measure. [Note: This Suffix shall also be used for Data Types representing Ratios (rates where the two units are not included or where they are the same), Percentages, etc.] A counted number of non-monetary units. Quantities need to be specified with a unit of quantity. [Note: This Suffix shall also be used for counted coefficients (e.g., flowers/m²).] A character string (i.e., a finite set of characters) generally in the form of words of a language. [Note: This Suffix shall also be used for names (i.e., word or phrase that constitutes the distinctive designation of a person, place, thing, or concept).]

Indicator (Ind)

Measure (Meas)

Numeric (Num), Value, Rate, Percent (Pct) Quantity (Qty)

Text

Rationale: This approach supports a consistent syntax and semantic meaning for OTA XML Schema attribute declarations, which is where most OTA data is passed.

4.2 Root Element, Message, and File Naming Conventions
4.2.1 Root Element Naming
Guideline: The format of root elements for messages shall be “OTA_” + Vertical name or area of focus + function + RQ or RS. Rationale: This format allows for easy identification of message, Vertical, and function.
© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 11

Example:

4.2.2 Use of Notif in Root Element Name
Guideline: The word “Notif” in a message name indicates that this message does not follow the normal requirements of a Request/Response transaction. This type of message provides (pushes) information from the originator to the recipient in support of a trading partner agreement. Rationale: This technique allows for quick and easy identification of push messages. Example:

4.2.3 Message XML Schema File Naming
Guideline: The .xsd file is given the same name as the root element of the XML Schema. Rationale: Easily identifies the contents of the .xsd file. Example:
Root element: File name: OTA_AirFlifoRQ.xsd

4.2.4 File naming for collections of Attribute Groups, Simple, and Complex Types
Guideline: CommonType and SimpleType XML Schema files are used to house attribute groups, simple types, and complex types that are used among multiple messages. Items that apply to a specific Vertical are housed in a common file that includes the Vertical name. Rationale: This approach easily identifies reusable components. Example:

4.2.5 Naming of XML Schema Files that Contain Common Components
Guideline: Schema files that are not used as messages by themselves, but contain components for use in messages, should not contain RQ or RS in the Schema name. These files are primarily used for maintaining consistency between common message structures, usually in an RQ/RS set and its Notif counterparts. Rationale: This approach allows for easy differentiation between messages and message components. Example:

4.3 Use of Elements and Attributes
4.3.1 Elements vs. Attributes

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 12

Guideline: For a given OTA data requirement, the preferred method is to represent that data as an attribute. The data is represented as an element if and only if: • • • • it is not atomic (i.e., it has attributes or child elements of its own) OR the anticipated length of the data is greater than 64 characters2 OR

the data requires a choice or branch within the schema OR it is likely that the data in question will be extended in the future

Rationale: The intention is to create a consistent OTA message design approach and to reduce the overall message size as well as avoid the potential of tag name collisions. Example: In the following example, ‘LocationDescription’ is defined as an element since the text it contains is greater than 64 characters. ‘LocationCode’, however, is defined as an attribute since it contains a 3 character code and is not likely to be extended.
Element: Five miles South of highway 85 and Main St. intersection next to Town Square Mall Attribute:

4.3.2 Number of Attributes per Element
Guideline: Element tags should not be overloaded with too many attributes (no more than 10 as a rule of thumb); instead, encapsulate attributes within child elements that are more closely related (or more granular). This should be done for those attributes that are likely to be extended by OTA or by specific trading partners. Rationale: This approach maintains the built-in extensibility that XML provides with elements and is necessary to provide forward compatibility as the specification evolves. It also provides a consistent guide to the level of granularity used to compose OTA Schema objects (or fragments).

4.3.3 Encapsulating Element
Guideline: XML element containers should be used for repeating elements if the XML Schema 'maxOcc' attribute exceeds 5 repetitions. The encapsulating element container is optional if the XML Schema 'maxOcc' attribute is less-than or equal to 5. However, a single XML container can be used for "simpleType" repeating content (via the XML Schema "list" construct). OTA work groups have the option to override this guideline if: 1) Adding the container to existing repeating elements would break backward compatibility. 2) The work group believes that, in practice, there will be minimal instances of messages that will use more than 5 occurrences, such that adding a container adds an unnecessary layer. With respect to this guideline, an OTA work group can remove existing containers only when backwards compatibility is already being broken. Rationale: This technique provides consistency for repeating data fields. Example:

2

URLs are considered to be less than 64 characters.

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 13

complexTypes NY FL CA simpleTypes NY FL CA or

4.4 Use of XML Schema
4.4.1 OTA Specification Uses XML Schema
Guideline: The XML Schema recommendations from W3C should be used to define all XML message documents. Rationale: • • Schemas are written in XML syntax, rather than complex SGML regular expression syntax. Because XML Schemas are themselves well-formed XML documents, they can be programmatically generated and validated using a meta-schema -- a Schema used to define other Schema models. XML Schemas have built-in data types and an extensible data-typing mechanism. (DTDs understand only markup and character data.) Using XML syntax to define data model requirements allows for more constraints, strong data typing, etc. XML Schemas provide for a consistent Data Repository syntax.

• • •

4.5 Global vs. Local Element Types
4.5.1 Simple and Complex Types
Guideline: Define XML Schema element types globally in the namespace for the elements that are likely to be reused (instead of defining the type anonymously in the Element declaration). This applies to both simpleType and complexType element type definitions. Rationale: This approach supports a domain library or repository of reusable XML Schema components. Also, since simpleType and complexType names are not contained in XML instance documents, they can be verbose to avoid element type name collisions.

4.5.2 Type Attribute vs. Ref Attribute
Guideline: Define XML Schema elements as nested elements via the ‘type’ attribute or an inline type definition (‘simpleType’ or ‘complexType’) instead of the ‘ref’ attribute that references a global element. Rationale: This approach for local element naming reduces the possibility of tag name collisions and allows the creation of short tag names. Globally-defined elements should be reserved only

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 14

for travel domain elements with well-defined meanings; such global names should be constructed with sufficient roots and modifiers to identify their domain of use and avoid tag-name collisions. Example:

4.5.3 Attribute Groups
Guideline: Define common attribute parameters globally as a reusable component via the XML Schema ‘attributeGroup’ element definition. Rationale: This approach supports a domain library or repository of reusable XML Schema components. Also, since the names used for the XML Schema ‘attributeGroup’ components are not contained in XML instance documents, they can be verbose to avoid name collisions with other ‘attributeGroup’ definitions. Example:

4.6 Namespaces
4.6.1 OTA Namespace
Guideline: All OTA message Schemas are declared in one targetNamespace, which is http://www.opentravel.org/OTA/2003/05. However, during the specification review period, the domain name will include an extension of alpha or beta corresponding to member review and public review respectively. If additional releases are necessary, they would continue with gamma, delta, etc.

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 15

Starting with release 2003A, the year and month on this targetNamespace is set to the initial publication of the 2003A OTA specification (the baseline specification). This value will not be changed in the subsequent releases, and the same namespace will also be used for new messages. The only reason to change the namespace would be to deprecate the 2003 baseline specification. This value would change to support the new OTA baseline specification, an action which should occur only on a 3- or 4-year cycle. Rationale: This approach supports a consistent way to manage and identify OTA XML-based transaction assets both internally and externally (via trading partners and global e-business repositories such as UDDI). It also avoids the need for explicit prefixes on both XML Schema and XML instance documents. Example: http://www.opentravel.org/OTA/2003/05 or http://www.opentravel.org/OTA/2003/05/alpha

Usage:

4.7.2 Version Attribute in Common XML Schema Files
Guideline: The ‘version’ attribute in the root element of OTA common data type Schema files (e.g., OTA_CommonTypes.xsd) will contain an independent self-describing version value (e.g., version=“19.127”, where ‘19’ is the major version and ‘127’ is the minor version). Rationale: Common data type Schema files (i.e., type definitions only) are version independent from message Schemas that may include them, and this content may be applied to multiple versions of a message. Example: The following example shows the header of an OTA common Schema file.

4.7.3 Version Attribute in XML Instance Documents
Guideline: XML instance documents being validated against an OTA message Schema will contain a ‘Version’ attribute on the root element. The value of this attribute should map directly to the value of the ‘Version’ attribute on the root ‘Schema’ element of the message Schema being used for validation. Rationale: This approach provides version correlation between XML instance message and the corresponding XML Schema.

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 17

Example:
Schema value: version=”1.050” matches instance value: version=”1.050”

4.7.4 ID Attribute in Message and Common XML Schema
Guideline: The ‘id’ attribute in the root element of OTA XML Schemas will contain the release. The ‘id’ attribute in the root element of OTA common data type XML Schemas will contain the range release. The OTA specification manager will update the ‘id’ attribute of all schemas to the current release prior to publishing the schemas. The ‘id’ attribute is only found in the XML Schema, it is not used in the instance. Rationale: This attribute indicates the release in which the XML Schema was published. It is important to note that the ‘id’ attribute does not indicate if a message format has changed between releases, this is determined by comparing the ‘version’ attribute in the root element of the XML Schemas. Example:
Message schema files: id=”OTA2003A” CommonType schema files id=”OTA2003A2003B”

4.7.5 Use of schemaLocation Attribute
Guideline: The attribute schemaLocation is to be used on elements in instances to name the location of a retrievable Schema for that element associated with that namespace. Rationale: This approach supports use of OTA XML Schemas. Example:
Attribute: xsi:schemaLocation=”http://www.opentravel.org/OTA http://www.opentravel.org/OTA/2002AREC/VEH- availability/VehAvailRateRQ-23.xsd”

4.8 Schema Markup and Annotations
4.8.1 Use of Annotation and Document Elements
Guideline: OTA XML Schemas will use the sub-element of the element for Schema documentation. Rationale: Schema comments “” are not part of the core information set of a document and may not be available or in a useful form. Example: Privacy sharing control attributes.

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 18

4.8.2 Use of lang Attribute
Guideline: Documentation elements will include the xs:lang attribute. The initial value of the attribute will be set to “en”. Rationale: This approach allows for future inclusion of documentation in other languages. Example: xs:lang="en" 4.8.3 Meaningful Annotations
Guideline: OTA requires that all complex types, simple types, elements, attribute groups, attributes, and enumerations are meaningfully annotated. • • • Complex type annotation: Describe the overall purpose of a complex type. Simple type annotation: Define the structure and its usage. Element annotation: Must describe the element in a meaningful manner so that the trading parties, who may not always have full understanding of the business context of the messages they are implementing, can understand the usage of the element. Attribute group: At the attribute group declaration, describe the overall functionality of the grouping. Within the element where the attribute group is referenced, include a description of the specific use of the attribute group. Attributes: Must include usage information. Enumerations: Provide an explanation of each value.



• •

Rationale: These standards enable the readers of a Schema to understand the usage of each data item. Example: This identifies the seat map details for the flight segment in the corresponding 'FlightSegmentInfo' element. If the responding system has different seat maps for different passengers for the same flight segment then this element will recur accordingly. The availability of seats can differ based upon various conditions, such as a passenger's status within a loyalty program or by the amount paid or class of service booked for the ticket. For example, if one passenger has a certain status in the Frequent Flyer program of the airline, certain desirable seats may be available for selection. A passenger without such status may not be able to select those seats. Thus the availability of seats can differ by passenger.

4.8.4 Annotation of Typed Elements
Guideline: Annotation of elements that are typed should reflect the specific usage of that complex or simple type at that location. If there is no additional specific usage information, then the global annotation found at the complex or simple type must be duplicated at the element level. Rationale: This approach enables the readers of a Schema to understand the usage of a typed element in its specific context. Example: The following example shows a complexType ‘AirItineraryType’ as defined in an OTA common Schema file. The ‘AirItinerary’ element following it is based on that complexType and contains a shorter annotation that describes only contextual usage of the content.

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 19

Specifies the origin and destination of the traveler. Attributes: DirectionInd - A directional indicator that identifies a type of air booking, either one-way, round-trip, or open-jaw with the enumeration of (OneWay | RT | OpenJaw) respectively. ActionCode - Indicates the status of the booking, such as OK or Wait-List. NumberInParty - Indicates the traveler count. ... A collection of all flight segments requested for booking.

4.8.5 Annotations of Root Elements
Guideline: The root element of each RQ message shall include an overall description of the functionality of the message pair. If an RS message (e.g., OTA_ErrorRS) does not have a companion RQ message, then the full description of the message is to be included in the RS. Rationale: This approach enables the readers of a Schema to understand the functionality of a message. Example: The following example shows message-level annotation for the OTA_HotelAvailRQ Schema file. ... Requests availability of hotel properties by specific criteria that may include: dates, date ranges, price range, room types, regular and qualifying rates, and/or services and amenities. The availability message can be used to get an initial availability or to get availability for the purpose of modifying an existing reservation. ...

4.8.6 Use of “may be”
Guideline: The term “may be” is used only to indicate a possible use of an element or attribute; it does not denote that the element or attribute is optional. Optionality is defined in the Minimum Occurrence (MinOcc) indicator of the element and the Use indicator of the attribute. Rationale: Consistency in terminology helps eliminate confusion between usage and optionality. Example:
“May be used to give further detail on the code or to remove an obsolete item.”

4.8.7 Reference to Code Tables
Guideline: When the OTA_CodeType type is used, the following annotation must be included: "Refer to OTA Code List n..n (xxx)" where n..n is the name of an OTA Code List and xxx is its 3-character identifier.

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 20

Rationale: This reference enables the reader or implementer of a Schema to find the code values of the referenced OTA code table (within either the code list spreadsheet or the XML instance document). Example:
Refer to OTA Code List Room Amenity Type (RMA).

4.8.8 No Use of Processing Instructions
Guideline: OTA XML Schemas will avoid the use of Processing Instructions (PI) by replacing them with the sub-element of the element that supplies this functionality. Rationale: elements are available to users of the Schema. PIs require knowledge of their notation to be parsed correctly. Extensions to the XML Schema can be made using . An extension will not change the Schema-validity of the document.

4.9 Enumerations vs. Code Lists
4.9.1 Use of Enumerations
Guideline: Enumerations are used in the case where the list of values is static or there is little likelihood that additional values will be added. Rationale: This method allows for the values to be validated. Example:

4.9.2 Use of Code Lists
Guideline: Code lists are used in the case where the list of values is dynamic or there is great likelihood that additional values will be added. Rationale: This method allows for new codes to be added and used between releases. Example:
Communication Location Type 1 Home 2 Business 3 Other

4.10 Code Lists
4.10.1 Name of Code List Table www.opentravel.org/ © 2005 OpenTravel™ Alliance

OpenTravel™ Alliance Best Practices Specification

Page 21

Guideline: The name of a code list table should be the same or similar to the name of the attribute in XML Schema, but should be in plain English with spaces between the words. Rationale: This approach provides the reader or implementer with better understanding of how the code values are used. Example:
Code set name Coverage Type for Code set name Phone Technology Type for

4.11 OTA General
4.11.1 Required Attributes of XML Instance Root Elements

Guideline: The root element of all OTA payload documents (XML instance messages), must contain the following attributes:
• • •

xmlns=”http://www.opentravel.org/OTA/2003A/05” Version=”[current version here]” xmlns:xsi=”http://www.w3c.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://www.opentravel.org/…”



Rationale: This format provides a standard way to identify OTA payload messages, message version, and the corresponding XML Schema. Example:

4.11.2

Use of TPA_Extensions

Guideline: Trading partner-specific data can be included in an XML instance message within the global element at OTA-sanctioned plug-in points defined in the XML Schema. This element may also contain the Boolean attribute ‘mustProcess’, which notifies that the message receiver must process the ‘TPA_Extension’ data. TPA_Extension content implemented by specific Trading Partners should be cycled back into the appropriate OTA workgroup for consideration to be incorporated into the specification. Rationale: This approach (along with the versioning Guideline of VI-2) provides a standard way for OTA to integrate and manage specific trading partner information. By filtering the trading partner content back into the workgroups, the specification will better reflect the business needs of the OTA stakeholder community. Additionally, companies will enhance their interoperability by aligning to the published specification as opposed to TPA_Extension content. Example: Schema fragment:

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 22

Sample XML:

4.11.3

Standard Simple Types vs. OTA Simple Types

Guideline: Wherever possible, OTA Schema data types should use the standard built-in simple types defined in the XML Schema specification. Rationale: This approach simplifies OTA message implementation because validation tools support built-in XML Schema simple types.

4.11.4

New Data Types Based on Extending Existing Types

Guideline: Create new Schema data types by using or extending existing OTA type definitions or from built-in XML Schema types whenever possible. Rationale: This technique maximizes reuse and avoids duplicating definitions.

4.11.5

Simple Type Restrictions

Guideline: OTA XML Schemas should avoid rigid simpleType restrictions unless the type is a common industry standard which is unlikely to change. Rationale: This approach allows OTA messages to interoperate globally in a more seamless manner and allows any particular trading partner to locally restrict content values as needed for unique business requirements. Example: The following example represents a valid type restriction since Day of the Week is a common industry standard and is unlikely to change: A three letter abbreviation for the days of the week (e.g. may be the starting date for the availability requested, days of operation, rate effective day, etc.).

© 2005 OpenTravel™ Alliance

www.opentravel.org/

OpenTravel™ Alliance Best Practices Specification

Page 23

4.11.6

Deprecation Policy

Guideline: Any construct (e.g. attribute, element, simpletype, complextype) requiring deprecation shall be annotated in the Schema with the following annotation: Candidate for removal, usage is not recommended. Deprecation Warning added in 2005B.

The following shall be done to document the deprecation intention: • • Any company registered as using a message with a candidate for removal should be notified of the intention to remove the construct. If no registration of a message is documented, due diligence to determine if in fact there are implementations will be served by sending an email via the OTA maintained mail distribution lists to the most appropriate work group(s).

The period of time from which the depreciation is highlighted and any users of the construct notified, to the time of the actual deprecation shall be no less than one public review comment cycle (e.g. notification would be sent before public review and if no feedback is received by the end of public review, the construct may be deprecated for the Publication). The Publication change file shall include all deprecation candidates and deprecated constructs. Rationale: This will provide a consistent and well-published mechanism by which content can be removed from the OTA specification. Also, existing implementations of the OTA specification will be made aware of content marked for deprecation.

4.11.7

License Agreement Documentation

Guideline: All OTA Schema files include a distinct message level annotation that references the OTA License Agreement (http://www.opentravel.org/ota_downloads_form.cfm). Rationale: With the 2004A publication, all OTA Schema files are accessible directly from the OTA public site without having to download a .zip file. Each Schema file is associated with a uniquely resolvable URL. For instance, the OTA_SimpleTypes.xsd file is accessible at: www.opentravel.org/OTA_SimpleTypes.xsd. Providing a reference to the License Agreement in ALL OTA Schema files will ensure that users of the specification are aware of the stipulations by which it is made publicly available. Example: The following example shows the header of the OTA_CommonTypes.xsd file with the License Agreement reference included in the documentation. All Schema files in the OTA specification are made available according to the terms defined by the OTA License Agreement at http://www.opentravel.org/ota_downloads_form.cfm ...

© 2005 OpenTravel™ Alliance

www.opentravel.org/

Similar Documents

Premium Essay

Developing Schemas

...When hearing the word schema people would not be able to explain what it means, and not realize that they use it in their everyday life. However it’s simple, schema is a concept that helps organize and interpret information. Schemas can be useful, because they allow us to take shortcuts in understanding a large amount of information. However, the concept can also cause us to reject relevant information in favor of information that confirms our pre-existing beliefs and ideas. Schemas can contribute to stereotypes and make it difficult to recall new information. So in order to understand schemas and the effects it has on a person’s life I formed a small case study. To start with, when starting the project, I first asked 10 participants who are in my family as well as my friends to help me in a project for psychology. Secondly I told the participants “I’m going to recite 12 words to you and show you those words at the same time.” The words were: Rest, Tired, Awake, Dream, Snore, Bed, Eat, Slumber, Sound, Comfort, Wake, and Night. After reciting the words I asked each participants what their name, age, and occupation was and when I went back to the list of words it seemed as all the words I recited to them didn’t matter, since they were more focused on the series of questions I asked 30 seconds after reciting the words. Next, I had asked the participants to write all the words they could remember within two minutes, but almost all ten participants had given up within a minute, since...

Words: 889 - Pages: 4

Free Essay

Schemata

...SCHEMATA A schema (pl. schemata or schemas), is a mental structure that represents some aspect of the world. People use schemata to organize current knowledge and provide a framework for future understanding. Schemata influence our attention, as we are more likely to notice things that fit into our schema. If something contradicts our schema, it may be encoded or interpreted as an exception or as unique. Thus, schemata are prone to distortion. They influence what we look for in a situation. They have a tendency to remain unchanged, even in the face of contradictory information. We are inclined to place people who do not fit our schema in a "special" or "different" category, rather than to consider the possibility that our schema may be faulty. As a result of schemata, we might act in such a way that actually causes our expectations to come true. Schemata can influence and hamper the uptake of new information (proactive interference), such as when existing stereotypes, giving rise to limited or biased discourses and expectations (prejudices), may lead an individual to "see" or "remember" something that has not happened because it is more believable in terms of his/her schema. For example, if a well-dressed businessman draws a knife on a vagrant, the schemata of onlookers may (and often do) lead them to "remember" the vagrant pulling the knife. Such distortion of memory has been demonstrated. A schema for oneself is called a "self schema". Schemata for other people are called...

Words: 413 - Pages: 2

Free Essay

Best Practices in Data Modeling

...Practices Know Where to Go for More Information QlikView is not SQL (SQL Schemas) SQL take a large schema and queries a subset of tables. Each query creates a temporary “Schema” of only a few tables. Query result sets are independent of each other. Query 1 Query 2 QlikView is not SQL (QV Schemas) QlikView builds a smaller and more reporting friendly schema from the transactional database. This schema is persistent and reacts as a whole to user “queries”. A selection affects the entire schema. QlikView is not SQL (Aggregation and Granularity) Store Table Store A B SqrFootage 1000 800 Sales Table Store A A A B B Prod 1 2 3 1 2 Price $1.25 $0.75 $2.50 $1.25 $0.75 Date 1/1/2006 1/2/2006 1/3/2006 1/4/2006 1/5/2006 Select * From Store, Sales Where Store.Store = Sales.Store will return: SqrFootage 1000 1000 1000 800 800 Store A A A B B Prod 1 2 3 1 2 Price $1.25 $0.75 $2.50 $1.25 $0.75 Date 1/1/2006 1/1/2006 1/1/2006 1/1/2006 1/1/2006 Sum(SqrFootage) will return: 4600 If you want the accurate Sum of SqrFootage in SQL you can not join on the Sales table in the same Query! QlikView is not SQL (Benefits) • QlikView allows you to see the results of a selection across the entire schema not just a limited subset of tables. QlikView is not SQL (Benefits) • QlikView allows you to see the results of a selection across the entire schema not just a limited subset of tables. QlikView will aggregate at the lowest level...

Words: 1267 - Pages: 6

Premium Essay

Star Schem & Snowflake Schema

...we will go through different Schema that can be used during Dimensional Modelling to create a Data Warehouse. Before we start with today's topic , For my viewers those who are new to this field i would like to revisit some of the key points of my previous blogs: 1) Business Intelligence is mainly divided into three parts as per my understanding a) Data Warehouse design and Implementation (ETL process) b) Data Analysis (Using OLAP cubes) c) Reporting and Dashboard Creation For further details revisit my First blog 2) Important Components involved in Dimensional Modelling or Data Warehouse Designing a) Fact Tables (Additive Facts, Semi-Additive Facts, Non- Additive Facts) b) Dimension Table c) Grain For further details revisit my Second blog After a thorough revision of previous concepts lets start our today's discussion about different Schema involved in Dimensional Modelling or Data Warehouse Designing. First of all i would like to explain the meaning of the topic i.e Snow Covered Wagon Hitched to a Star = SnowFlake Schema and Star Schema are two types of Schema that are used while designing a Data Warehouse, Hence they can be explained as follows: Star Schema: A Star Schema is one of the simplest and easiest schema to understand. A schema which consists of Dimension tables only attached to Fact tables. A Star Schema get its name from its physical...

Words: 557 - Pages: 3

Premium Essay

Database Revision Questions for Computer Science and Technology

...difference between controlled and uncontrolled redundancy? Illustrate with examples. 1.9. Name all the relationships among the records of the database shown in Figure 1.2. 1.10. Give some additional views that may be needed by other user groups for the database Shown in Figure 1.2. 1.11. Cite some examples of integrity constraints that you think should hold on the Database shown in Figure 1.2. Chapter 2 Database System Concepts and Architecture Review Questions 2.1. Define the following terms: data model, database schema, database state, internal Schema, conceptual schema, external schema, data independence, DOL, OML, SOL, VOL, query language, host language, data sublanguage, database utility, catalog, client/server architecture. 2.2. Discuss the main categories of data models. 2.3. What is the difference between a database schema and a database state? 2.4. Describe the three-schema architecture. Why do we need mappings between? Schema levels? How do different schema definition languages...

Words: 803 - Pages: 4

Premium Essay

Database Management

...CIV E 603: Information Modeling and Database Systems Lecture 1 1 What to Study?  Introduction to Data base  Relational Model  Database design  Structured Query Language (SQL) 22 Let’s begin the journey !! …. in to fascinating world of databases 23 Today’s outline  Database Management System (DBMS)  Entity-Relationship (ER) Model 24 What is a database?  Many people would like to call it organization… 25 What is a database? Database is a structured collection of related data. Many name it efficiency… 26 A database is  A home for data – since that is where data stay…  A manager for data – since data are organized neatly…  A GOOGLE for data – since a particular record can be found in a snap…  A guardian for data – since a database rejects malicious accesses…  … 27 What is a Database? Database: is a collection of related data Data: known facts that can be recorded and that have implicit meaning Properties of database: • represents some aspect of the real world (mini-world -UoD) • logically coherent collection of data with some inherent meaning. A random assortment of data cannot correctly be referred to as a database. • designed, built, and populated with data for a specific purpose. It has an intended groups of users. 28 What is a Database? A database can be of any size and of varying complexity. • For example, the list of...

Words: 2400 - Pages: 10

Premium Essay

System Analyst

...Data Warehouse Design: Dimensional Modeling II Data Technology Chularat Tanprasert, Ph.D. Recap  Dimensional modeling      Popular, useful, and pragmatic approach Based on Kimball Fact table Dimension tables Design process in steps Database Schema Design Star Schema (With Attributes) Example Designs     A useful way to learn about data warehouse design principles is by using examples – reuse. Kimball – Data warehouse lifecycle toolkit Adamson & Venerable – Data warehouse design solutions Let’s take a look at inventory, shipments, and financial services. Inventory   An inventory system serves as a “middleman” between the manufacturer and the retailer – value adding process. There are threee types of inventory model    Inventory snapshot Delivery status Transaction Inventory Snapshot Model For specific time periods, inventory levels are measured and recorded. Delivery Status Model Create one record for each complete shipment of a product to a warehouse. Transaction Model Record every transaction that affects the inventory. Shipments    The shipments process is where the product leaves a company and is delivered to a customer. Typically, accompanying each shipment is a shipment invoice. Each line item on the shipment invoice corresponds to an SKU. Shipments Shipments Shipments Financial Services   Typically a large bank. Services...

Words: 1220 - Pages: 5

Free Essay

Software

...to know that whilst on occasion questions may look similar to those in past papers, the context and approach is often significantly different, which means that previous answers cannot simply be restated; thus it is not appropriate to memorise and re-state past paper answers. Additionally, the answer pointers provided here give guidance and are only a guideline and should not be merely quoted by candidates, but applied to the topic of the question.” A1 a) i) Explain the role and structure of a DTD in relation to an xml document. ii) Explain the role and structure of an XML schema in relation to an xml document. iii) Explain how an xml document would call:  an internal DTD  an external DTD and;  an XML schema. b) i) Compare and contrast the workings of a DTD and an xml schema. You should state the benefits of using each. [3 marks] ii) Generate an appropriate sample XML document based on the xml schema in figure 1.1 [2 marks] [2 marks] [3 marks] [2 marks]...

Words: 3199 - Pages: 13

Premium Essay

Outline

...RYERSON UNIVERSITY Ted Rogers School of Information Technology Management And G. Raymond Chang School of Continuing Education COURSE OF STUDY 2013-2014 (C)ITM 500 – Data and Information Management 1.0 PREREQUISITE The prerequisite for this course is [(C)ITM100 and (C)ITM207] or (C)ITM 305. Students who do not have the prerequisite will be dropped from the course. 2.0 INSTRUCTOR INFORMATION • • • • • Name: Office Phone Number: E-mail address: Faculty/course web site(s): https://my.ryerson.ca Office Location & Consultation hours: • Your instructor is available for personal consultation during scheduled consultation hours which are posted on their office door or on the course Blackboard site. However, you are advised to make an appointment by e-mail or by telephone before coming to ensure that the professor is not unavoidably absent. • E-mail Usage & Limits: Students are expected to monitor and retrieve messages and information issued to them by the University via Ryerson online systems on a frequent and consistent basis. Ryerson requires that any official or formal electronic communications from students be sent from their official Ryerson Email account. As such emails from other addresses may not be responded to. 3.0 CALENDAR COURSE DESCRIPTION This course provides the students with an introduction to the core concepts in data and information management. It is centered around conceptual data modeling techniques, converting the conceptual data models into relational...

Words: 1132 - Pages: 5

Free Essay

Star Transformation

...About Cognizant Cognizant (NASDAQ: CTSH) is a leading provider of information technology, consulting and business Process outsourcing services. Cognizant’s single-minded passion is to dedicate our global technology and Innovation know-how, our industry expertise and worldwide resources to working together with clients to make their business stronger. With more than 40 global delivery centers and approximately 61,700 employees as of December 31, 2008, we combine onsite/offshore model infused by a distinct culture of customer satisfaction. A member of the NASDAQ-100 Index and S&P 500 Index, Cognizant is a Forbes Global 2000 company and a member of the Fortune 1000 and is ranked among the top information technology companies in Business Week’s Hot Growth and Top 50 Performers listings Start Today For more information on how to drive your business results with Cognizant, contact us at inquiry@cognizant.com or visit our website at: www.cognizant.com. World Headquarters 500 Frank W. Burr Blvd. Teaneck, NJ 07666 USA Phone: +1 201 801 0233 Fax: +1 201 801 0243 Toll Free: +1 888 937 3277 Email: inquiry@cognizant.com European Headquarters Haymarket House 28-29 Haymarket London SW1Y 4SP UK Phone: +44 (0) 20 7321 4888 Fax: +44 (0) 20 7321 4890 Email: infouk@cognizant.com India Operations Headquarters #5/535, Old Mahabalipuram Road Okkiyam Pettai, Thoraipakkam Chennai, 600 096 India Phone: +91 (0) 44 4209 6000 Fax: +91 (0) 44 4209 6060 Email: inquiryindia@cognizant.com ...

Words: 4912 - Pages: 20

Premium Essay

Geographic Information Systems

...An Extended Entity-Relationship Model for Geographic Applications * Thanasis Hadzilacos Computer Technology Institute, University of Patras Box 1122, GR-26110, Patras, Greece thh@cti.gr Nectaria Tryfona National Center for Geographic Information and Analysis Univ. of Maine, Orono, ME 04469-5711, U.S.A nectaria@spatial.maine.edu Abstract. A special-purpose extension of the EntityRelationship model for the needs of conceptual modeling of geographic applications, called the Geo-ER Model, is presented. Handling properties associated to objects not because of the objects’ nature but because of the objects’ position, calls for dealing -at the semantic modeling levelwith space, location and dimensionality of objects, spatial relationships, space-depending attributes, and scale and generalization of representations. In order to accomplish this in the framework of ER and its derivatives, we introduce special entity sets, relationships, and add new constructs. The rationale as well as examples of usage of the Geo-ER model from actual projects are presented. 1. Introduction Is everybody special or are we all alike? Should we develop applications according to a special methodology for each class of applications, such as medical, business process and geographic, or should we use a single blanket approach for all? Personal preferences and philosophical discussions aside, it does seem that the general purpose side has won most battles in computer science, from hardware to programming languages...

Words: 4100 - Pages: 17

Premium Essay

Cs251 Fundamantals of Database Systems Ip 1 - 5

...CS251-1301B-03 Fundamentals of Database Systems Phase 1 -5 Individual Project Robert March 24th, 2013 Table of Contents Project Outline 3 Description of the Database Design Life Cycle 4 The Entity Relationship Diagram 7 The Logical Model and Normalization 9 The Microsoft Access Database 11 The Microsoft Access Database Application 14 References: 18 Project Outline   My idea for a project concept is for a granite fabrication and installation company called MasterStoneWorks. We will perform counter sales, contractor and walk-in customer kitchen and bath design, templates, fabrication, installation, and follow-up. To run efficiently (or at all) we must have a centralized DBMS with access for all employees in order to keep track of the progress of the workload and get the products delivered and installed on time. Issues with the process must be immediately known and corrected as this is a high value product with a small profit margin at this point in our economy. Any miscommunication can be disastrous. The MasterStoneWorks database will have the following tables: * Customers * Sales * Installs * Product choices * Costs (wholesale and retail) * Sales people * Project Managers * Templates * Follow-up * Customer support Description of the Database Design Life Cycle The seven steps of the SDLC/DBDSL: 1. Concept Planning – This first step is where the need to develop, or improve a system is ascertained along...

Words: 1691 - Pages: 7

Free Essay

Logical Modeling in Systems Analysis

...7 Object Oriented Approach Logical Models . . . . . . 9 Chapter Three Current Topics in Data Modeling . . . . . . . . . . . 12 Bibliography . . . . . . . . . . . . . . . . . . 14 CHAPTER ONE Abstract Today’s organizations are utilizing their core competencies while exploiting the core competencies of subcontractors to produce highly differentiated and high quality products at a lower cost. Business process reengineering has played a key role in remaining competitive, enabled through information technology. Existence of the automated information system, developed through Systems Analysis and Design, has become a requirement for survival of today’s companies. Process requirements are identified during the analysis phase and documented through logical modeling. A model is an abstraction that represents some aspect of an IS system to be built and may be high level or low level and include system components and their interactions. Modeling is performed by the systems analyst since it aids in identifying requirements and simplifies the many different views of a new...

Words: 3155 - Pages: 13

Free Essay

The Self Paper

...which is a reflection of a person and their different roles interactions with others. A person’s personality, characteristics, appearances, and social qualities is what makes you, it creates a difficult person of knowing and understanding the real you is not so easy. Finally, this image was created in many ways; however, it is influenced by our interactions with significant people in our lives (Cherry, 2013). Each person self consists of characteristic and personality traits distinguish us from other people. The relational of self is having personal relationships with your husband, wife, mother, father, sister, and brother. Self-concept represents the person I am or the person I have become. Self-concept is also made up as one self schema, which works together with self-esteem, self knowledge and the social self from the self as a whole. This includes the past, present, and future self. It represents each person principles of what they might become, what they would like to become, or why they are afraid of trying. As we go through life things are going to change or getting ready to change. There are some changes that are beyond our control,...

Words: 1262 - Pages: 6

Premium Essay

Rarara

...Dealing with Missing Information in a Data Warehouse Today businesses are investing many resources in building data warehouses and data marts to obtain timely and actionable information that will give them better business insight. This will enable them to achieve, among other things, sustainable competitive advantage, increased revenues and a better bottom line. In the early '90s, data warehousing applications were either strategic or tactical in nature. Trending and detecting patterns was the typical focus of many solutions. Now, companies are implementing data warehouses or operational data stores which meet both strategic and operational needs. The business need for these solutions usually comes from the desire to make near real-time actions in a constantly changing environment while receiving information from both internal as well as external source systems. Dealing with missing or unknown data is critical in these types of environments. Unknowns skew metrics and results to produce incorrect decisions. Knowledge of the unknown allows at least for further examination of any conclusions drawn from incomplete data. Furthermore, in a well-designed business intelligence environment, these unknowns are often resolved later as data that is more complete is entered into the operational systems. Irrespective of the nature of the applications, missing information has always been a problem for data warehouses. As business intelligence environments become more mature, real time and...

Words: 988 - Pages: 4