Class 6: Design Methodologies

1
Class 6Design Methodologies
2
Overview of Class

• Review of Important Terms
• Object Oriented Architecture
• Star Schema Architecture

3
Motivation for Studying Design Methodologies

• To provide understaning
• To provide the analyst with an ability to

4
Important Terms

• Before examing new design methodologies, it is
  necessary to review some key points which will be
  referred to in our evaluation.
• This includes defining
• Transactions and Transaction Control
• OnLine Transaction Processing
• OnLine Analytical Processing

5
Transaction Control - An example

• A transaction is a unit of interaction with a
  production database. A good example would be
  debiting or crediting your bank account at an
  Automated Teller Machine.
• Several smaller database interactions are
  combined in each ATM transaction (PIN, cash
  amount, account selection, etc.)

6
Transaction Control Rule

• If the ATM runs out of cash after you have
  requested a withdrawal, you want to be sure that
  your account will not be debited.
• Transaction Control Rule
• the rule is that the entire transaction must
  succeed or fail as a unit.
• Only successful transactions will be committed
  and all unsuccessful or incomplete transactions
  will be rolled back to a neutral state.

7
Online Transaction vs Analytical Processing

• We will briefly examine the basic conepts behind
  OLTP and OLAP architecture.
• Understanding both provides useful reference
  examine Star Schema Architecture, the contrast
  with OLTP and parallels with OLAP.

8
OnLine Transaction Processing

• OLTP Technical Definition
• three-tiered client/server database applications
  that use a separate middleware program (a
  transaction server) to control transactions.

9
OLTP

• OLTP General Purpose Definition
• any production database, or any database
  application that is updated constantly and
  queried infrequently.

10
OnLine Analytical Processing

• As weve seen before, OLAP is a database where
  users simply query the database and do not update
  it.
• OLAP is still responsive (the online component),
  but with enhanced processsing capabilities of
  newer systems, is able to do complex queries for
  unique business intelligence.

11
Purpose of OLAP

• The purpose of an OLAP application is to allow
  people to analyze data stored in production
  databases without interfering with the
  availability or integrity of the production system

12
OLAP Operations

• While production databases must be current to the
  split second, OLAP databases contain historical
  records of transactions that have already been
  completed.
• OLAP databases are not structured according to
  the relational model but are often structured
  more like reports.

13
Contrasting OLTP and OLAP

• OLTP databases are updated continuously, while
  OLAP databases are updated periodically by taking
  batch snapshots of a production database.

14
Examining Architecture Methodologies

• We will look at
• Object Oriented Arhictecture
• Star Schema Arhictecture

15
Relating Architecture with Methodologies

• The evolution of certain database architecture
  types has derived from an entirely different
  approach to designing databases.
• Traditional architecture, while providing many
  examples with unique characteristics, follow many
  of the same principals in their approach to basic
  database design.

16
New Methodologies

• With newer business requirements came new needs,
  requiring a different approach.
• The new approach to database design also spawned
  entirely new architecture.
• Two we will look at are
• Object Oriented Architecture
• Star Schema Architecture

17
Common Database Problems

• As databases have grown, certain problems have
  emerged
• The development process has grown cumbersome
• Databases are not as integrated as needed to
  reflect their business model
• Increasing the size and scope of databases can
  become difficult past a certain point
• Much information remains hidden from view

18
Focus of Object Oriented Architecture

• Each architectures is a response to different set
  of problems and conditions. Analysts have become
  increasingly concerned with
• Improving efficiency and effectiveness of the
  database
• Streamlining the development process with greater
  integration of components
• These are addressed by Object Oriented approach

19
Focus of Star Schema Architecture

• A different concern can be seen in the need to
  address
• The increasing complexity of interrelationships
• Recognizing the existence of new information and
  insight that can be gained by combining data in
  new ways.
• These are addressed by Star Schema approach

20
Review of Object Oriented Approach

• Recall from earlier classes, the object oriented
  modeling approach is a way of looking at all
  components in a system, whether data or
  processes, as an object.
• This approach underlines the structure inheirent
  in object oriented database architecture.

21
Object Oriented Modeling

• Objects can be categorized into classes, then
  assigned attributes (values describing the
  object) and operations (processes the object
  participates in)
• As with ER modeling, relationships are used, like
  11, 1m, mn, though they refer to the
  interrelation of objects, rather than mere
  entities, and are called links

22
Object Oriented Modeling

• These objects can be categorized into classes,
  then assigned attributes (values describing the
  object) and operations (processes the object
  participates in)
• associative attributes, roles and aliases,
  aggregate relationships (as part of the whole),
  superclasses and subclasses, or generalization,
  and flowing down of attributes and operations to
  lower level objects or inhieritence.

23
The Object Oriented Approach to Database

• The OO programming and modeling approaches have
  been with us for some time, the object oriented
  approach to database architecture is a more
  recent phenomenon.
• Consequently, the existence of standards and time
  tested techniques are still in the formative
  stages of development.
• The similarity between OO programming and
  modeling, and object oriented databases provides
  a guide.

24
Object Oriented Architecture

• We define object oriented architecture as
• A structure where all components, whether
  processes or data, are objects
• The difference between data and processes are
  functional characteristics, rather than
  fundamentally different concepts.
• You could regard the difference between data and
  processes as existing on a continium, rather than
  one or the other.

25
Advantages of Object Oriented Architecture

• object oriented architecture provides a
  simplified view of a system
• As with object oriented modeling, object oriented
  architecture lends itself to a streamlined
  development process
• Modeling inherient in system design leads to
  greater scalability, reliability, and
  distributive capability.

26
Object Model

• Object Oriented Architecture is based on the
  object oriented approach, which in turn, is
  described by the Object Model.
• This is a conceptual model describing a
  hieararchy of objects, based on classes, which
  best illustrates the object oriented approach

27
Object Oriented Architecture Concepts

• A number of concepts are essential to
  understanding how object oriented architecture
  works, including
• Abstraction
• Encapsulation
• Sharing
• Polymorphism
• Inheritence

28
Abstraction

• Abstraction is more concerned with the meaning
  and purpose of processes than the description of
  those processes.
• This allows for easier understanding of the
  system, and consequently better design outcomes.

29
Encapsulation

• Encapsulation is a principle that as much of the
  system as possible be a collection of black boxes
  (unknown detail). All operations are autonomous
  in this concept.
• This allows for greater modularity in design.

30
Sharing

• Sharing is the principle that no function or data
  be stored, moved, or manipulated more than
  necessary.
• In other words, sharing is possible in this
  system because the object maintains its
  characteristics regardless of how it is accessed.

31
Polymorphism

• With polymorphism, the object focus means the
  developer or analyst is concerned with the object
  that contains the process or data, rather than
  the process or data itself.
• By accessing simple objects rather than complex
  processes and data, polymorphism simplifies the
  tasks required of end user applications.

32
Inheritence

• By using classes, objects receive the
  characteristics of higher classes in the object
  hierarchy.
• By using inheritence, data storage and retrieval
  required to gather information about a system is
  minimized.

33
The Application of the object oriented approach

• The object oriented approach can be found in the
  development of many components of computer
  systems, including
• Hardware
• Operating Systems
• Graphical User Interfaces
• Graphical Constructs

34
Object Oriented Approach to Hardware Construction

• Using this approach in hardware construction
  results in
• self contained parts (encapsulation)
• parts which can be accessed by other system
  components (sharing)
• function as autonomous black boxes (polymorphism)
  in the execution of a system

35
Object Oriented Approach to Operating Systems

• We can see this approach in the development of
  certain OSs, such as UNIX based systsems
• This is evident in the way UNIX describes all
  system components as objects (ranging from
  printers, terminals, disks, files, byte streams,
  and so on).
• The Linux operating system follows this approach
  as well.

36
Object Oriented Approach to Graphical User
Interfaces

• The object oriented approach is also evident in
  modern GUI applications, especially now that many
  are tightly interwoven with the underlying
  operating systems, such as
• Windows NT, Windows95/98, Xwindows, Linux, OS/2
  Warp, and MacIntosh
• These systems treat many system components as
  objects, and are placed in a hierarchy or
  directory and object properties (such as
  permissions) are inherited.

37
Graphical Constructs

• WIMP (windows, icons, menus, and pointers)
• This arrangement of features in a user friendly
  way helps us to build OO systems easily and more
  intuitively.
• NERD (navigation, evaluation, refinement, and
  demonstration)
• This concept refers to the way WIMP is organized
  in a system (such as an operating system or
  platform)

38
The Organizational Effect of Object Oriented
Approach

• Changing roles have resulted from the object
  oriented approach, particularly with the adoption
  of the Object Oriented database architecture.
• This can be seen by tracking the responsibilites
  of programmers and programs, and databases and
  DBAs over time.

39
Changing Areas of Responsibility

• Tracking these changes from the pre database data
  processing period, to the object oriented
  databases of today can be seen in the control
  over
• Presentation of Data
• Preparation and Processing of Data
• Enforcement of Business and Integrity Rules
• Management of Access to the Data

40
Pre Database Processing

• No databases existed to process data
• The role of the programmer and the responsibility
  of programs included
• Presentation of Data
• Preparation and Processing of Data
• Enforcement of Business and Integrity Rules
• Management of Access to the Data

41
Early Database Environment

• As databases came into being, the traditional
  responsibilites of programmers and programs
  remained
• Presentation of Data
• Preparation and Processing of Data
• Enforcement of Business and Integrity Rules
• While databases assumed responsibilities for
  management of access to the data.

42
Relational Database Environment

• While the responsibility for presentation,
  preparation and processing of data still remains
  for programmers and programs
• The expanding functionality of relational
  databases, the scope of work available to DBAs
  and databases incresed to include
• Enforcement of Business and Integrity Rules
• Management of Access to the Data

43
The Object Oriented Environment

• The scope of control in this envinronment now
  includes
• Preparation and Processing of Data
• Enforcement of Business and Integrity Rules
• Management of Access to the Data
• With only the presentation of data the domain of
  the programmers

44
The Future of Object Oriented Programming

• We can expect the role of preparation and
  processing of Data and enforcement of business
  and integrity rules to become the responsibility
  of object oriented programmers, leaving the
  management of access to the data to DBAs
• Increasingly, the OO programmer is in high
  demand, especially as object oriented databases
  become available on the internet.

45
Object Oriented Programming

• Now that weve seen how object oriented approach
  has resulted in a new database architecture, it
  is possible to see how it has changed the
  functionality of programming.
• A good example is the popular C, which is
  essentially a 3GL (C Language) with Object
  Oriented extensions.

46
C

• Based on the C Language, C uses many of the
  same basic elements, including
• the INCLUDE and MAIN sections for declaring
  library files of command sets, and main body of
  program instructions, respectively
• Code is divided into blocks
• Functions are called to provide modular code
• Arrays and pointers are also used

47
Object Oriented Extensions

• C has additional features apart from C,
  including the addition of classes
• By adding a class statement in the code,
  reference can be made to objects using the object
  oriented approach
• Functions and variables in the class can be
  public (any calling program can use them), or
  private (only available to the program that
  contains it).

48
Storage Terminology in C

• Constructors and Destructors
• Functions which initialize and terminate the
  available storage area for data generated by C
  instructions
• Instance vs. Persistence
• Instance refers to the eventuality of data
  occuring as a result of values and instructions
  from programming, and is temporary, while
  persistence is the permanent physical storing of
  data, it persists

49
The ODMG-93 Standard

• The Object Database Management Group (ODMG) has
  set a standard for object databases which defines
  specifications for
• A Base Object Model (the basis for object
  oriented architecure)
• Object Definition Language
• Object Query Language
• Database Bindings (for C and Smalltalk)

50
Standards for Object Definition Language

• Each object in the database schema must be
  defined
• Each table, which represent the collection of
  objects, is regarded as an object type within the
  schema.
• ODL provides the syntax for each type.

51
Standards for Object Query Language and Bindings

• Object Query Language is regarded as similar to
  SQL, and is with its focus on cross table
  queries, is perhaps less than ideal in an object
  oriented environment.
• Database bindings are defined to allow
  programmers of C and Smalltalk language to
  program without worrying about how the object
  database will handle storage issues.

52
Object Oriented Concepts (Objectivity/DB)

• Objectivity/DB is a database architecture
  example, with the following concepts
• Federated Object The system object, the top of
  the model
• Database objects The object representing one
  database in a larger system, subordinate to
  Federated Object

53
Object Oriented Concepts (Objectivity/DB)

• Container Object Collections of BASIC OBJECT
  (lowest level), used when multiple objects are
  accessed together for better performance
• Associations A link between two files to relate
  them, similar to a pointer

54
Review Object Oriented Terms

• Schema Organization of all objects in a system
• Object Types Logical collection of objects or
  tables
• Attributes Fields
• Associations links
• Containers collections of base objects

55
Review of Object Oriented Architecture
Characteristics

• Data Descriptions include
• Schemas, object types, attributes, and
  relationships
• Organization Structure
• Collections of autonomous objects of the same
  type, related via pointers (associations)
• Data Constructs
• Object Definition Language

56
Object Oriented Architecture Navigational
Characteristics

• Search Functionality
• Simple, complex search via programs or OQL
• Cross Referencing Capability
• Via Pointers (associations)
• Mapping
• Dynamic and Static
• Processing
• Record at a time

57
Review

• The object oriented approach is fundamentally
  different than other architectures because it
  describes systems in a different way.
• Object oriented database may be complex, but they
  provide great advantages in development of
  integrated, efficient, reliable systems.

58
Star Schema

• The star schema architecture was developed for an
  entirely different set of reasons.
• As with Object Oriented Architecture, it is very
  much derived from a different approach than is
  the case with other architectures.

59
Motivation for a New Approach

• Many existing systems have grown in complexity
  and depth arising out of individual business
  needs.
• Today, we recognize the sum total of these
  different systems can, taken together, provide
  important insights not available by looking at
  the individual parts.

60
How Star Schema Addresses the Need

• Put another way, we recognize the need to access
  data across systems in a meaningful way that was
  not available before.
• The Star Schema Architecture validates this
  approach, and utilizes new terms in database
  analysis, data mining or data warehousing.

61
Data Mining and Data Warehousing

• Data Mining
• Accessing large amounts of data across numerous
  systems and database for unique analysis to
  provide new insights.
• Data Warehousing
• Management of the storage of large amounts of
  data, with the intention of providing a platform
  to enable data mining.

62
Star Schema Defined

• Star Schema Architecture is query centric
• The idea behind Star Schema is creating a
  centralized access point to asks questions of
  data for meaningful information.
• Star Schema is well suited to analysis of unique
  situations.

63
Data Warehousing as represented by Star Schema

• Star Schema is an improvement over an OLTP system
  in many respects.
• Better able to handle analysis of complex
  interrelationships
• Tracks patterns to generate new business
  intelligence
• No counter intuitive navigation is required for
  complex queries, you simply select parameters and
  run the analysis.

64
Star Schema Fundamentals

• Star Schema is a query centric view of data
• Information in Star Schema is classed in 2 table
  types
• fact tables
• indexed facts in rows
• Dimension tables
• fact attributes

65
Fact vs Dimension Tables

• Fact tables are the main data analyzed
• Dimension tables contain attributes
  characteristic of a given fact
• For example, if an item is purchased, the
  purchase is a fact, and the item (and any other
  items) are the dimensions.

66
Star Schema Trade Offs

• Star Schema is an ideal architecture for looking
  up facts.
• This structure poses a problem with pair-wise
  joins, by creating potentially enormous
  intermediate search results (temporary output to
  storage generated in pursuit of a final answer).
  This could result in correspondingly poor
  performance.

67
Performance Enhancement Approaches

• Mutliplyin the rows of each joined table
  (cartesian products)
• Symmetric Multi Processing (SMP)
• Massively Parallel Processing (MPP)
• We will cover the last two in further detail in a
  later class
• Each method has advantages and disadvagtages

68
Star Schema Solution

• To get around the problem posed by each option,
  Star Schema architecture uses an indexing method
  to increase join performance called a Star Index.

69
Star Index

• The star index relates the dimensions of a fact
  table to which ever row contains the dimensions
  being accessed.
• This accelerates queries that join related tables.

70
Parallel Join Processing

• Another approach to improve performance involves
  parallel processors.
• Parallel processors are more than one processor
  running instructions simultaneously in a single
  computer system.
• The method used is the single pass multi table
  join. The join process is spread relatively
  evenly across all available processors.

71
Intelligent Optimization

• A final approach is to run incremental queries
• This involves only analyzing sections of the
  scope of the data requested to determine the time
  and result sets for further processing, and then
  rerun the analysis with the new estimates.
• This is obviously an iteriative process that is
  run over and over till the query is completed.

72
Star Schema Summary

• Data warehousing as designed by Star Schema is
  very efficient for intuitive queries, but
  presents problems with transactions more suitable
  to OLTP Relational Databases.
• Using optimizing indexing schemes and joining
  techniques, Star Schema can overcome these
  performance barriers.

73
Conclusion

• Object Oriented and Star Schema Architecture
  represent different methodologies and, above all,
  reflect an entirely different approach to
  defining and desinging databases.

74
Contrasting Object Oriented and Star Schema
Architecture

• Object Oriented architecture is a new apporach to
  understaning systems in a modular, streamlined,
  integrated way.
• Star Schema architecture is geared towareds the
  recent focus on finding and utilizing vast stores
  of data to produce new insights, while still
  providing acceptable performance for complex
  queries.

75
Implications for the Analyst

• Choosing the right architecture for your database
  design depends on whether your goals are
  streamlined development, higher levels of
  integration in design, or accessing vast amounts
  of information in new, more insightful, ways.