2. 2Object-Oriented Analysis and Design with the Unified Process OBJECTIVES  Describe the differences and similarities between relational and object-oriented database management systems  Design an object database schema based on a class diagram  Design a relational database schema based on a class diagram  Describe object-oriented design issues, including data access classes and data types  Describe the different architectural models for distributed databases  Determine when and how to design the database

3. 3Object-Oriented Analysis and Design with the Unified Process OVERVIEW  Databases provide a common Repository for data  Database Management Systems provide sophisticated capabilities to store, retrieve, and manage data  Detailed Database Models are derived from Domain Class Diagrams  Database Models are implemented using Database Management Systems (DBMS)  Databases can be Relational or Object-Oriented Database Models.

4. 4Object-Oriented Analysis and Design with the Unified Process Databases and Database Management Systems  Databases and Database Management Systems are important components of a modern Information System.  A Database is an integrated collection of stored data that is centrally managed and controlled  Databases provide a common repository for data so that it can be shared by the entire organization.  A Database also stores descriptive information about: - Class Attribute names, Restrictions andAaccess Control information and Sensitive data items.  A Database Management System (DBMS) is a system software component that manages and controls access to the Database.  DBMS is generally purchased and installed separately from other software components. ◘ Example of Modern DBMS - Oracle, Access, DB2, Gemstone, ObjectStore

5. 5Object-Oriented Analysis and Design with the Unified Process DBMS Components  Database Consists of two Related information stores:  Physical Data Store Contains raw bit and bytes of the data that are created and used by the information System.  The Database Scheme Contains descriptive information about data stored in the Physical Data Stores including:-  Access and Data Controls including allowable values, value dependencies among data elements, List of Users allowed to read or update element contents  Associations among attributes and group of data attributes (eg..Pointers)  Details of Physical Data Store organization, including Data type, Length, Location of data element, Indexing of key data elements, Sorting of related group of data attributes.

6. 6Object-Oriented Analysis and Design with the Unified Process DBMS COMPONENTS A DBMS has Four Key Components: 1. Query Interface 2. Application Program Interface (API) 3. Administrative Interface 4. Data Access Programs and Subroutines ◘ All Accesses to Database by Users, Application Programs and Database Administrators is via DBMS Interface DBMS Interface uses a defined name in the Schema to Access Physical Data store. ◘ The DBMS accesses Schema to verify that the requested data exist and that the “Requesting User” has appropriate Access privilege. If access is valid DBMS extracts information from the Schema and uses it to access the Physical Data Store on behalf of the Program or User. ◘ Database and DBMS provide several important Data access and Management capability including:- - Simultaneous Access by many Users and Application Programs - Access to Data without writing Application Programs (Via Query language) - Application of Uniform and consistent access and content controls

7. 7Object-Oriented Analysis and Design with the Unified Process The components of a Database and a Database Management System and their interaction with Application programs, Users, and Database Administrators

8. 8Object-Oriented Analysis and Design with the Unified Process Database Models Database Models have evolved since their introduction in the 1960s Four DBMS Models have been widely used:-  Hierarchical (eg. IMS. IDMS)  Network (eg. TOTAL DBMS)  Relational (eg. DB2, ORACLE, ACCESS)  Object-Oriented (eg. GemStone, ObjectStore, Objectivity) A few older Hierarchical and Network Model DBMSs are still in use today especiallyin large scale “Batch Transaction Processing” applications  Most existing and newly developed DBMS use the Relational or Object-Oriented approach.

9. 9Object-Oriented Analysis and Design with the Unified Process Object-Oriented Databases  Object Database Management System (ODBMS ) are a direct extension of O-O Design and O-O Programming paradigm.  ODBMS stores data as Objects or Class instances.  ODBMS are designed specifically to store objects and to interface with Object Oriented Programming Languages.  There are many Advantages of Using ODBMS : - Direct Support for Method Storage - Inheritance - Nested Objects - Object Linking - Programmer-defined Data Types Each of these will be discussed in detail.  ODBMS is the Database technology of choice for newly designed systems implemented with O-O Tools, especially for Scientific and Engineering Applications.  ODBMS is expected to gradually supplant RDBMS in more traditional Business Applications over the next decade.

10. 10Object-Oriented Analysis and Design with the Unified Process Object-Oriented Databases  ODBMS are relatively new and thus there are few widely accepted standards for specifying and Object Database Schema.  Object Database Management Group (ODMG) defined and refined standards for specifying Object Database Schema. called the Object Definition Language (ODL)  Object Definition Language (ODL) A Language for defining the structure and content of an Object database  ODMG Standards become the basis of the Java Data Objects (JDO) Standard as well as basis of some Interfaces between ODBMS and the C++ and SmalTalk Programming languages.

11. 11Object-Oriented Analysis and Design with the Unified Process Designing Object Databases Follow the steps below to create an Object Database from a Class Diagram. 1. Determine which Classes require Persistent storage 2. Represent Persistent Classes 3. Represent Associations among Persistent Classes 4. Choose appropriate Data Types and Value Restrictions (if necessary) for each Field. Note: Classes can be classified into two broad types for purposes of Data Management - Persistent Class which must store one or more Object Attribute Values between instantiations or Method invocations. Persistent Classes is not destroyed when the Program or process creates it ceases execution. - Transient Class doesn’t need to store Object Attribute Values between instantiations or Method invocations. Transient Class exists only during the lifetime of a Program or Process.

12. 12Object-Oriented Analysis and Design with the Unified Process

13. 13Object-Oriented Analysis and Design with the Unified Process Representing Classes  An Object Database Schema requires a Class Definition for each Persistent Class  ODL Class Definitions derive from the Domain Model Customer Class Diagram Class Customer { attribute string accountNo attribute string name attribute string billingAddress attribute string shippingAddress attribute string dayTelephoneNumber attribute string nightTelephoneNumber }

14. 14Object-Oriented Analysis and Design with the Unified Process Representing Associations  ODBMS automatically assigns a unique “ Object Identifier ” to each stored object. An Object Identifier may be a Physical Storage Address or a Reference that can be converted to a Physical Storage Address at Run time.  ODBMS represents Associations by storing the Object Identifier of one Object within related Objects  ODBMS Use Attributes with Object Identifiers to find related Objects called “Navigation’.  Navigation is a process of accessing an Object by extracting its Object Identifier from another (related) Object  Designers represent Associations indirectly by declaring Associations between Objects  Use keywords Relationship and Inverse  Object identifiers are not usually specified directly by an Object Database Schema Designer. Designer specify them indirectly by declaring Associations between objects.

15. 15Object-Oriented Analysis and Design with the Unified Process Representing Associations  Object identifiers are not usually specified directly by an Object Database Schema Designer.  Designer specify them indirectly by declaring Associations between Objects using Keywords:  “Relationship” and “Inverse” that are matching Association in the related Classes. ◘RELATIONSHIP declares an association between one Class and another Class. ◘INVERSE tells the ODBMS that the two relationships are actually mirror images of one another.

16. 16Object-Oriented Analysis and Design with the Unified Process Representing One-To-One Associations ONE- TO- ONE ASSOCIATION Consider a One-To-One Association between the Employee and Workstation Classes Class Employee { attribute string name attribute integer salary relationship Workstation Uses inverse Workstation : : AssignedTo } Class Workstation { attribute string manufacturer attribute string serialNumber relationship Employee AssignedTo inverse Employee : : Uses }  The Class Employee has an association called AssignedTO with the Class Workstation  The Class Workstation has a matching association called AssignedTo with the Class Employee  Each Association includes a declaration of the matching association in the other class using Keyword “Inverse”,

17. 17Object-Oriented Analysis and Design with the Unified Process Representing One-To- Many Associations 

18. 18Object-Oriented Analysis and Design with the Unified Process One-to-Many Relationships Partial ODL class definition Class Customer { attribute string accountNo … relationship set Makes inverse Order::MadeBy } Class Order { attribute string orderID … relationship Customer MadeBy inverse Customer::Makes } The Association MAKES connects a single Customer object to a SET of Order Objects. By Declaring a Set you instruct ODBMS to allocate as many Order Objects Identifier Attributes to each Customer Object as are needed. ODBMS dynamically adds or Delete Object Identifier attributes to the set.

19. 19Object-Oriented Analysis and Design with the Unified Process Representing Associations  Declaring an Association using Relationship instead of creating an attribute containing an Object Identifier has two advantages:- 1.The ODBMS assumes responsibility for determining how to implement the connection among objects. 2.The ODBMS assumes responsibility for maintaining Referential Integrity. (i.e Creation of a new Object causes the Link of the Related Object to be set to NULL Or UNDEFINED)  The ODBMS automatically creates attributes containing Object Identifiers to implement declared Association. The Users and Programmers are shielded from all details of how those Identifiers are actually implemented and manipulated.

20. 20Object-Oriented Analysis and Design with the Unified Process Representing Many-To-Many Associations  Representation depends on whether the association has any Attributes.  Many-To-Many Association without any Attributes are represented as Set of Object Attributes in both associated Classes.  Many-To- Many Association with Attributes require a more complex approach. ODL uses Multivalued Attributes and an Association Class. The Many-To-Many Association has to be decomposed into a pair of One-To-Many Associations between the Original Classes and the Association Class.

21. 21Object-Oriented Analysis and Design with the Unified Process Representing Many-To-Many Associations Without Attributes Consider an Association Between Employee and Project Class Employee { attribute string name attribute string salary relationship set WorksOn inverse Project : : Assigned } Class Project { attribute string projectId attribute string description attribute string startDate attribute string endDate relationship set Assigned inverse Employee : : WorksOn }

22. 22Object-Oriented Analysis and Design with the Unified Process Many-to-Many Relationships with Attributes

23. 23Object-Oriented Analysis and Design with the Unified Process Many-to-Many Relationships with Attributes  Class Catalog { attribute string catalogID attribute integer year ----- relationship set Contains1 inverse CatalogProduct:: AppearsIn1 } Class ProductItem { atribute string productID attribute string description ------- relationship set AppearsIn2 inverse CatalogProduct:: Contains2 } Class CatalogProduct { attribute real specialPrice … relationship Catalog AppearsIn1 inverse Catalog :: Contains1 relationship ProductItem AppearsIn2 inverse ProductItem :: Contains2 }

24. 24Object-Oriented Analysis and Design with the Unified Process A Generalization Hierarchy within the RMO Class Diagram

25. 25Object-Oriented Analysis and Design with the Unified Process Generalization Associations  ODL uses keyword “extends”.  Keyword “extends” indicates that when stored in an Object Database, Objects of the derived Classes (Sub-classes) will inherit all of the Attributes and Relationships defined for the Super-class.

26. 26Object-Oriented Analysis and Design with the Unified Process Generalization Associations Class Order { attribute string orderID … attribute real grandTotal } Class WebOrder extends Order { attribute string emailAddress … attribute string replyMethod } Class TelephoneOrder extends Order { attribute string phoneClerk … attribute string ProcessClerk }

27. 27Object-Oriented Analysis and Design with the Unified Process Relational Databases  Organized data into structures called Tables  Tables contain Rows (records) and Columns (attributes)  Keys are the basis for representing Relationship among Tables:  Each Table must have a Unique Key  A Primary Key uniquely identifies a Row in a Table  A Foreign Key duplicates the Primary key in another Table  Keys may be natural or invented

28. 28Object-Oriented Analysis and Design with the Unified Process A portion of the RMO Class Diagram

29. 29Object-Oriented Analysis and Design with the Unified Process Figure 10-11 An association between data in two tables; the foreign key ProductID in the InventoryItem refers to the primary key ProductID in the ProductItem table.

30. 30Object-Oriented Analysis and Design with the Unified Process Designing Relational Databases Steps to create Relational Schema from a Class Diagram 1. Create a table for each Class 2. Choose a Primary key for each table (invent one, if necessary) 3. Add Foreign Keys to represent One-to-Many Relationships 4. Create new Tables to represent Many-to-Many Relationships 5. Represent classification hierarchies 6. Define referential integrity constraints 7. Evaluate schema quality and make necessary improvements 8.Choose appropriate data types and value restrictions (if necessary) for each field

31. 31Object-Oriented Analysis and Design with the Unified Process Class Tables with Primary Keys identified in bold

32. 32Object-Oriented Analysis and Design with the Unified Process Represent One-to-Many Associations by adding Foreign key attributes (shown in italics)

33. 33Object-Oriented Analysis and Design with the Unified Process The table CatalogProduct is modified to represent the Many-to- Many Association between Catalog and ProductItem

34. 34Object-Oriented Analysis and Design with the Unified Process Classification Hierarchies Classification Hierarchy is a special case in Relational Database Design. we consider that as the Child Class inherits the Data and Methods of a Parent Class, A Table representing a Child Class inherits some or all of its Data from the Table representing its Parent Class. The Inheritance can be represented in two way:- 1. Combine all Tables into a single table containing the superset of all Class Attributes but excluding invented Keys of the Child Classes 2. Use separate Tables to represent the Child classes, and use the Primary key of the Parent Class table as the Primary key of the Child Class tables Either Method is an acceptable approach to representing a Classification Hierarchy in Relational Database design.

35. 35Object-Oriented Analysis and Design with the Unified Process Specialized Classes of Order are represented as separate tables with OrderID as both Primary and Foreign key

36. 36Object-Oriented Analysis and Design with the Unified Process Enforcing Referential Integrity Referential Integrity : A consistent Relational Database state in which every Foreign Key value also exist as a Primary Key value. - Every Foreign Key must also exist as a Primary key value  The RDBMS usually automatically enforces Referential Integrity after the designer has identified Primary and Foreign keys  Any new Row containing an unknown Foreign key value is rejected  If a Primary key is deleted or modified in a Table, the DBMS can be instructed to set all corresponding Foreign keys to NULL.

37. 37Object-Oriented Analysis and Design with the Unified Process Evaluating Database Schema Quality  Database Design is the final step a Modeling process. And as such, it depends on the Analyst’s experience and judgment.  A High-quality Data Model has:  Uniqueness of Table Rows and Primary keys ◘Use internally invented keys – Many DBMSs automate key creation by providing special for invented keys (eg, AutoNumber in type in Ms Access)  Lack of redundant data ◘Non-key attributes are stored only once  Ease of implementing future Data model changes A Database Model is considered flexible and maintainable if changes to the Database Schema can made with minimal destruction to existing data content and structure. ◘e.g. Adding a new Class to the Schema should not require redefining existing tables. ◘Adding a new (One-to-Many) association should only require adding a new foreign key to an existing table. ◘Adding new (Many-to-Many) Association should only require adding a single new table to schema.

38. 38Object-Oriented Analysis and Design with the Unified Process Database Normalization  Normalization is a technique to ensure database schema quality by minimizing redundancy:  First Normal Form (1NF): A table in 1NF contains no repeating Attributes or groups of Attributes in a Table ◘ Functional dependency: is a one-to-one Association between values of two  Second Normal Form (2NF): A table in 2NF If it is in 1NF and if each non-key Attributes is functionally dependent on the entire Primary Key.  Third Normal Form (3NF): A Table in 3NF if it is in second Normal form and if no non-key attribute is functionally dependent on any non-key attribute

39. 39Object-Oriented Analysis and Design with the Unified Process A simplified RMO CatalogProduct table The primary key of CatalogProduct is the combination of CatalogID and ProductID, but CatalogIssueDate is only functionally dependent on CatalogID. This table is not in 2NF.

40. 40Object-Oriented Analysis and Design with the Unified Process Decomposition of a First Normal Form table into two Second Normal Form tables

41. 41Object-Oriented Analysis and Design with the Unified Process Converting a Second Normal Form table into two Third Normal Form tables State is functionally dependent on ZipCode

42. 42Object-Oriented Analysis and Design with the Unified Process Domain Class Modeling and Normalization  Domain Class Modeling and Normalization are complimentary techniques for Relational Database Design.  Attributes of a Class are Functionally Dependent on any Primary key of that Class  Attributes of a Many-to-Many association are Functionally Dependent on unique identifiers of both participating Classes  While creating a Class Diagram, an Analyst must directly or indirectly consider issues of Functional Dependency when deciding which Attributes belong with which Classes or Associations.

43. 43Object-Oriented Analysis and Design with the Unified Process Object-Relational Interaction  O-O Programming Languages and O-O Development Tools have been widely used since mid 1980s with RDBMS.  Many O-O Tool developers exploited the existing base of RDBMS tools and knowledge by using an RDBMS to store Persistent Object states. That made sense because it was: - Economical (There was one less OO Tool to develop) - Many newer O-O Systems needed to manipulate Data stored in existing Relational Databases.  Despite the current availability of Commercial ODBMSs many organization still continue to use “a kind of RDBMS” called ‘ Hybrid Object-Relational Database’, as the prime storage of Persistent Objects.  Hybrid Object-Relational Databases is a RDBMS used to store Object Attributes and Relationship.  Hybrid Object-Relational Databases (also called Hybrid DBMS) approach is still the most widely employed approach for Persistent Object Storage.

44. 44Object-Oriented Analysis and Design with the Unified Process Object-Relational Interaction Designing a Hybrid Database is essentially three Design problems in one. 1. Designing O-O Application Software 2. Designing a Relational Database Schema that can store Persistent Object States 3. Designing an interface between Persistent Classes and the RDBMS. ◘Designing an interface between Persistent classes and the RDBMS is complex because the Designer must bridge the difference between the Object-Oriented and the Relational Views of stored data, which includes:  Class Methods cannot be directly stored or executed in an RDBMS  Inheritance cannot be directly represented in an RDBMS. Thus OO Programs that access the Database must implement Methods internally.  ODBMSs can represent a wider range of Data Types than RDBMSs. New Classes can be defined to store Application-specific data

45. 45Object-Oriented Analysis and Design with the Unified Process Object-Relational Interaction Although the Relational and OO Views of stored data have significant differences they also have significant Overlaps such as:  Grouping of Data items into tables or Classes based on one-to-one Associations among Attributes.  Defining one-to-one and many-to-many Associations among tables or Class

46. 46Object-Oriented Analysis and Design with the Unified Process Data Access Classes  Data Access Classes implement the Bridge between Data stored in Program Objects and in a Relational Database  Data Access Class Methods Encapsulate the logic needed to copy values from the Problem Domain Objects to the Database, and vice versa ◘The logic is a combination of Program code in a language such as Java and embedded Relational Database commands in SQL.

47. 47Object-Oriented Analysis and Design with the Unified Process Interaction among a Problem Domain Class, a Data Access Class, and the DBMS

48. 48Object-Oriented Analysis and Design with the Unified Process Data Types  A data type defines the storage format and allowable content of a program variable or Database attribute.  Primitive Data Types are storage format directly implemented by Computer Hardware or a Programming Language. e,g (Integer, Real, Boolean, Memory address etc)  Complex Data Types Also called User-defined Data Types are user or programmer defined data types as complex combinations of Primitive Data types. e.g (date, time, currency etc..)

49. 49Object-Oriented Analysis and Design with the Unified Process A subset of the Data Type available in the Oracle Relational DBMS

50. 50Object-Oriented Analysis and Design with the Unified Process Object DBMS Data Types  ODBMSs typically provide a set of Primitive and Complex Data Types comparable to those of an RDBMS.  ODBMS also allow Schema Designer to define format and value constraints.  Additionally, ODBMS provides an even more powerful way to define useful Data types and constraints..  Differences to RDBMS  A Schema Designer can define a new Data Type and its associated Constraints as a new Class.  Class Methods can perform many of the error- and type-checking functions usually performed previously by Application Program Code and/or by the DBMS itself. ◘a) DBMS is freed from direct responsibility for Managing complex Data Types and the values stored therein. b) Indirectly performs validity checking and Format conversion by executing Programmer-defined methods stored in the Database

51. 51Object-Oriented Analysis and Design with the Unified Process Object DBMS Data Types  The strength of Programmer-defined Data Types a) DBMS is freed from direct responsibility for managing Complex Data Types and the values stored therein. b) Indirectly performs validity checking and Format conversion by executing Programmer-defined methods stored in the Database.  The flexibility of Define new Data Type is one reason that O-O Tools are so widely used in non-business Information Systems. ( e.g Engineering and Scientific Systems stored data is more complex than simple strings, numbers and Data. O-O Tools enable Database Designers and Programmers to design custom Data Types that are specific to a problem domain.)

52. 52Object-Oriented Analysis and Design with the Unified Process Distributed Databases  Organizations usually do not store all of their data in a single location or on a single Database. Instead they store data in many different locations and Databases.  In today’s networked information Systems, organizations often use Distributed Databases.  REASONS FOR EMPLOYING A VARIETY OF DATABASES & DBMSs 1. Information Systems may have been developed at different times using different DBMSs 2. Parts of an organization’s data may be owned and managed by different organizational units 3. System performance improves when data are physically close to the Application that uses it.

53. 53Object-Oriented Analysis and Design with the Unified Process Distributed Databases  DISTRIBUTED DATABASE ARCHITECTURE  Single Database Servers  Replicated Database Servers  Partitioned Database Servers  Federated Database Servers *** C ombination of these Architectures are also possible

54. 54Object-Oriented Analysis and Design with the Unified Process Single Database Servers  Clients on one or more LANs share a single Database Server located on a single Computer system  Database Server may be connected to one of the LANs or directly to the WAN backbone.  Connection to WAN ensures that no one LAN is overloaded by all the network traffic to and from the Database Server.

55. 55Object-Oriented Analysis and Design with the Unified Process Single Database Servers  A Single Server provides no backup capabilities in the event of failure. Thus Single Database Server Architecture is poorly suited to applications that must be available on 7- day, 24-hour basis.  Performance bottle-neck can occur within a single Database Server or in the Network Segment to which the server is attached as a result of a growth in transaction volumes. In that event Database Server may be insufficient to respond quickly to all of the service requests it receives.  To improve the performance (i.e to solve this type of Performance Bottle-neck problem) a more powerful Computer System may be employed as the Database Server.  However due to cost, System Management or Network performance consideration makes the powerful computer option impractical.

56. 56Object-Oriented Analysis and Design with the Unified Process Single Database Servers NETWORK CONGESTIONS AND PROPOGATION DELAY  Delays in accessing a remote Database Server may result from Network Congestion or Propagation delay from Client to Server Owning to:- a) Request to and response from a Database Server may travel large distances across LAN and Wan networks. b) Database transactions must also compete with other types of network traffic (Such as Voice, Video and Web site access) for available transmission capacity. NETWORK CONGESTION SOLUTIONS ◘Increasing the capacity of the Entire Network. (This approach is expensive and often impractical) ◘Locating Database Servers physically close to their clients (i.e On the same LAN segment) in order to Improve Database access speed. (This approach minimizes the distance related delay for request/response and removes a large amount of traffic from WAN. ) However, moving a Database Server Closer to its clients can only be feasible if clients are located close to each other,

57. 57Object-Oriented Analysis and Design with the Unified Process Single Database Servers ADVANTAGES AND DISADVANTAGES OF SINGLE DATABASE SERVERS  Advantages  Simplicity; since there is only one Server to manage.  Disadvantages  Susceptibility to server failure  Possible overload of the Network or Server  Performance bottlenecks or propagation delays

58. 58Object-Oriented Analysis and Design with the Unified Process A Single Database Server Architecture

59. 59Object-Oriented Analysis and Design with the Unified Process Replicated Database Servers  Replicated Database Servers Architecture eliminate delay in accessing distance Database servers.  Clients interact with the Database Server on their own LAN. Each LAN Server stores a separate copy of the database. ADVANTAGES AND DISADVANTAGES OF REPLICATED DATABASE SERVERS. ADVANTAGES  Elimination of Database access from WAN minimizes Propagation delays.  LAN and Database Server capacity can be independently optimized to local needs.  Information Systems become more fault tolerant.  Applications can direct access request to any available Server, with preference to the nearest Server. A Client can also redirect their requests across WAN to another available server.  Designers can achieve load balancing by interposing a Transaction Server between Clients and Replicated Database Servers. The Transaction Server monitors loads on all Servers and automatically directs Client Requests to the Server with the lowest load

60. 60Object-Oriented Analysis and Design with the Unified Process Replicated Database Servers DISADVANTAGES (DRAWBACS)  Data inconsistency is a problem whenever multiple Database copies are in use. Clients accessing that same data on a different copy will receive an outdated response.  To solve Data inconsistency problem each Database Copy must periodically be updated with changes from other Database servers. This process is called “Database Synchronization” ◘Designers can implement Synchronization by using Synchronization utilities or developing Synchronization programs. Synchronization Utilities are powerful and flexible but also expensive. Also incompatibilities among Synchronization methods make using DBMSs from different vendors impractical ◘Time Delay caused by Synchronization is an important Database Design issue. This problem can be solved by reducing the Synchronization frequency. ◘An optimum Synchronization strategy is a complex trade off among cost, Hardware and network capacity and the need of application programs and users of current data.

61. 61Object-Oriented Analysis and Design with the Unified Process A Replicated Database Server Architecture

62. 62Object-Oriented Analysis and Design with the Unified Process Partitioned Database Servers  Partitioned Database Server minimize the need for Database Synchronization.  Database content is partitioned among multiple Database Server.  A different group of clients accesses each partition.  Traffic among Clients and the Database Server in each group is restricted to a LAN.  Partitioned Database Server Architecture is only feasible when a Schema can be cleanly partitioned among Client access groups..  Client Groups must require access to well-defined subsets of a Database (eg. Marketing data rather than Production data).  Members of a Client access group must be located in small geographic regions. (When the group spread among multiple geographic regions then a combination of Replicated and Partitioned Database Server Architecture is usually required.)  It is seldom possible to partition a Database Schema into mutually exclusive subsets. Therefore, the part of the database that are needed by most or all users must exist in each partition..

63. 63Object-Oriented Analysis and Design with the Unified Process Partitioned Database Servers ADVANTAGES AND DISADVANTAGES OF PARTITIONED DATABASE SERVER  ADVANTAGES  Minimizes need for database synchronization but does not eliminates it entirely  DISADVANTAGES  Database Schema must be cleanly partitioned among client access groups  Members of client access group must be located in small geographic regions

64. 64Object-Oriented Analysis and Design with the Unified Process Partitioning a Database Schema into Client access subsets

65. 65Object-Oriented Analysis and Design with the Unified Process Federated Database Servers  This Architecture is commonly Used to access data stored on incompatible storage models or DBMSs  A single unified Schema is created on a combined Database Server.  Combined database server acts an intermediary, between Application Programs and the Database residing on other Servers.  Database request are first send to Combined Database Server which in turn makes appropriate requests to the underlying Servers. Results from multiple servers are combined and reformatted to fit the Unified schema before returning the response to the client.  Federated Database Server Architecture can be extremely complex, thus difficult to be implemented and maintained and tend to demand considerable amount of Hardware and network capacity therefore it is expensive.  A common use of Federated Database Server Architecture is to implement a “Data Warehouse”.  Data Warehouse is a collection of data used to support structured and unstructured Managerial Decisions. Data warehouse typically draw it content from internal operational Databases and from multiple external databases.  Advantages  Only feasible approach for implementing data warehouses  Disadvantages  Extremely complex to install and maintain thus expensive

66. 66Object-Oriented Analysis and Design with the Unified Process A Federated Database Server Architecture

67. 67Object-Oriented Analysis and Design with the Unified Process RMO Distributed Database Architecture  Two possible approaches  Single server architecture ◘Simple to implement, but high WAN requirements and risk of server failure  Combination of partitioning and replication ◘Reduced fault tolerance and WAN requirements, but need for additional database servers and synchronization techniques  Decision based on analysis of cost and desired system performance

68. 68Object-Oriented Analysis and Design with the Unified Process A Replicated and Partitioned Database Server Architecture for RMO

69. 69Object-Oriented Analysis and Design with the Unified Process Database Design Within the UP  Database design has profound impacts on other development activities  Key questions of Database Design are When to Design Database and how to perform Database design.  The Primary Factors that complicates the Decision of when and how to perform Database Design are:-  Architecture  Decision about DBMSs, Servers and Database Distribution are key Architectural decisions for the entire System. They are tightly Integrate with other Architectural Decisions, including Network design, Web and Component services, and Security.  Existing Databases ◘Most new or upgraded Systems must interact with existing Databases. Thus the Database design must accommodate these preexisting constraints.  Domain Class Diagram ◘Database Design in whole or part cannot proceed until related parts of the Class diagram have been developed.

70. 70Object-Oriented Analysis and Design with the Unified Process Database Design Within the UP  Architecture and Database issues are most significant issues since they make Database Design one of the highest risk elements in many development projects.  The risk associated with Database Design are substantially reduced when the system being developed doesn’t have to interact with existing Databases.  When Database related risk is low, Database tasks can be spread across multiple iterations. Typically the Database Schema is developed incrementally as related portion of Domain model Class Diagram are developed.

71. 71Object-Oriented Analysis and Design with the Unified Process Summary  One of the key activities in design is developing a Relational or Object Database Schema  Schemas are developed from Class Diagrams  An Object Database stores data as a collection of related Objects ◘Associations are represented by storing unique “Object Identifiers” in related objects  A Relational Database stores data in tables ◘Associations are represented with Foreign keys

72. 72Object-Oriented Analysis and Design with the Unified Process Summary (continued)  Architecture for multiple databases  Replicated ◘Multiple copies on different servers  Partitioned ◘Partial copies placed in proximity to user subsets  Federated ◘Multiple databases with a DBMS single point of access  Database design should be performed in an early iteration to minimize risk