DDBMS, characteristics, Centralized vs. Distributed Database, Homogeneous DDBMS, Heterogeneous DDBMS, Advantages, Disadvantages, What is parallel database, Data fragmentation, Replication, Distribution Transaction
DDBMS, characteristics, Centralized vs. Distributed Database, Homogeneous DDBMS, Heterogeneous DDBMS, Advantages, Disadvantages, What is parallel database, Data fragmentation, Replication, Distribution Transaction
Replication is useful in improving the availability of data by coping data at multiple sites.
Either a relation or a fragment can be replicated at one or more sites.
Fully redundant databases are those in which every site contains a copy of the entire database.
Depending on the availability and redundancy factor there are three types of replications:
Full replication.
No replication.
Partial replication.
Inter-Process Communication in distributed systemsAya Mahmoud
Inter-Process Communication is at the heart of all distributed systems, so we need to know the ways that processes can exchange information.
Communication in distributed systems is based on Low-level message passing as offered by the underlying network.
program partitioning and scheduling IN Advanced Computer ArchitecturePankaj Kumar Jain
Advanced Computer Architecture,Program Partitioning and Scheduling,Program Partitioning & Scheduling,Latency,Levels of Parallelism,Loop-level Parallelism,Subprogram-level Parallelism,Job or Program-Level Parallelism,Communication Latency,Grain Packing and Scheduling,Program Graphs and Packing
A presentation on a special category of databases called Deductive Databases. It is an attempt to merge logic programming with relational database. Other types include Object-oriented databases, Graph databases, XML databases, Multi-model databases, etc.
Introduction to distributed systems
Architecture for Distributed System, Goals of Distributed system, Hardware and Software
concepts, Distributed Computing Model, Advantages & Disadvantage distributed system, Issues
in designing Distributed System,
Replication is useful in improving the availability of data by coping data at multiple sites.
Either a relation or a fragment can be replicated at one or more sites.
Fully redundant databases are those in which every site contains a copy of the entire database.
Depending on the availability and redundancy factor there are three types of replications:
Full replication.
No replication.
Partial replication.
Inter-Process Communication in distributed systemsAya Mahmoud
Inter-Process Communication is at the heart of all distributed systems, so we need to know the ways that processes can exchange information.
Communication in distributed systems is based on Low-level message passing as offered by the underlying network.
program partitioning and scheduling IN Advanced Computer ArchitecturePankaj Kumar Jain
Advanced Computer Architecture,Program Partitioning and Scheduling,Program Partitioning & Scheduling,Latency,Levels of Parallelism,Loop-level Parallelism,Subprogram-level Parallelism,Job or Program-Level Parallelism,Communication Latency,Grain Packing and Scheduling,Program Graphs and Packing
A presentation on a special category of databases called Deductive Databases. It is an attempt to merge logic programming with relational database. Other types include Object-oriented databases, Graph databases, XML databases, Multi-model databases, etc.
Introduction to distributed systems
Architecture for Distributed System, Goals of Distributed system, Hardware and Software
concepts, Distributed Computing Model, Advantages & Disadvantage distributed system, Issues
in designing Distributed System,
The integration of data from multiple distributed and heterogeneous sources has long been an important issue in information system research. In this study, we considered the query access and its optimization in such an integration scenario in the context of energy management by using SPARQL. Specifically, we provided a federated approach - a mediator server - that allows users to query access to multiple heterogeneous data sources, including four typical types of databases in energy data resources: relational database Triplestore, NoSQL database, and XML. A MUSYOP architecture based on this approach is then presented and our solution can realize the process data acquisition and integration without the need to rewrite or transform the local data into a unified data.
Project number: 224348
Project acronym: AEGIS
Project title: Open Accessibility Everywhere: Groundwork, Infrastructure, Standards
Starting date: 1 September 2008
Duration: 48 Months
AEGIS is an Integrated Project (IP) within the ICT programme of FP7
Lecture Notes by Mustafa Jarrar at Birzeit University, Palestine.
See the course webpage at: http://jarrar-courses.blogspot.com/2014/01/data-schema-integration.html and http://www.jarrar.info
you may also watch this lecture at: http://www.youtube.com/watch?v=VJtF_7ptln4
The lecture covers:
- Challenges of Data Schema Integration
- Framework for Schema Integration
- Schema Transformation
- Reverse Engineering
Data integration is a perennial challenge facing large-scale data scientists. Bio-ontologies are useful in this endeavour as sources of synonyms and also for rules-based fuzzy integration pipelines.
This presentation discusses the following topics:
Concepts
Component Architecture for a DDBMS
Distributed Processing
Parallel DBMS
Advantages of DDBMSs
Disadvantages of DDBMSs
Homogeneous DDBMS
Heterogeneous DDBMS
Open Database Access and Interoperability
Multidatabase System
Functions of a DDBMS
Reference Architecture for DDBMS
Components of a DDBMS
Fragmentation
Transparencies in a DDBMS
Date’s 12 Rules for a DDBMS
Database SystemsDesign, Implementation, and ManagementOllieShoresna
Database Systems:
Design, Implementation, and
Management
Tenth Edition
Chapter 12
Distributed Database Management
Systems
The Evolution of Distributed Database
Management Systems
• Distributed database management system
(DDBMS)
– Governs storage and processing of logically related
data over interconnected computer systems
– Both data and processing functions are distributed
among several sites
• 1970s - Centralized database required that
corporate data be stored in a single central site
– Usually a mainframe computer
– Data access via dumb terminals
Database Systems, 10th Edition 2
Database Systems, 10th Edition 3
• Wasn’t responsive to need for faster response times
and quick access to information
• Slow process to approve and develop new application
The Evolution of Distributed Database
Management Systems
Database Systems, 10th Edition 4
• Social and technological changes led to change
• Businesses went global; competition was now in
cyberspace not next door
• Customer demands and market needs required Web-
based services
• rapid development of low-cost, smart mobile devices
increased the demand for complex and fast networks to
interconnect them – cloud based services
• Multiple types of data (voice, image, video, music)
which are geographically distributed must be managed
The Evolution of Distributed Database
Management Systems
Database Systems, 10th Edition 5
• As a result, businesses had to react quickly to
remain competitive. This required:
• Rapid ad hoc data access became crucial in
the quick-response decision making
environment
• Distributed data access to support
geographically dispersed business units
The Evolution of Distributed Database
Management Systems
Database Systems, 10th Edition 6
• The following factors strongly influenced the shape of the
response
• Acceptance of the Internet as the platform for data access
and distribution
• The mobile wireless revolution
• Created high demand for data access
• Use of “applications as a service”
• Company data stored on central servers but applications are
deployed “in the cloud”
• Increased focus on mobile BI
• Use of social networks increases need for on-the-spot
decision making
The Evolution of Distributed Database
Management Systems
Database Systems, 10th Edition 7
• The distributed database is especially desirable because
centralized database management is subject to problems such
as:
• Performance degradation as remote locations and distances
increase
• High cost to maintain and operate
• Reliability issues with a single site and need for data
replication
• Scalability problems due to a single location (space, power
consumption, etc)
• Organizational rigidity imposed by the database – might not
be able to support flexibility and agility required by modern
global organizations
The Evolution of Distributed Database
Management Systems
8
Distributed Processing and Distributed
Data ...
• Distributed database management (DDBMS) component. The distributed database management component is the management system for the global database. It has many functions, including the following:
• 1. Provides the user interface.
• 2. Locates the data.
• 3. Processes queries.
• 4. Provides network-wide concurrency control and recovery procedures.
• 5. Provides translation of queries and data in heterogeneous systems.
Distributed database design refers to the following problem: given a database and its workload, how should the database be split and allocated to sites so as to optimize certain objective function (e.g., to minimize the resource consumption in processing the query workload).
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
DevOps and Testing slides at DASA ConnectKari Kakkonen
My and Rik Marselis slides at 30.5.2024 DASA Connect conference. We discuss about what is testing, then what is agile testing and finally what is Testing in DevOps. Finally we had lovely workshop with the participants trying to find out different ways to think about quality and testing in different parts of the DevOps infinity loop.
Software Delivery At the Speed of AI: Inflectra Invests In AI-Powered QualityInflectra
In this insightful webinar, Inflectra explores how artificial intelligence (AI) is transforming software development and testing. Discover how AI-powered tools are revolutionizing every stage of the software development lifecycle (SDLC), from design and prototyping to testing, deployment, and monitoring.
Learn about:
• The Future of Testing: How AI is shifting testing towards verification, analysis, and higher-level skills, while reducing repetitive tasks.
• Test Automation: How AI-powered test case generation, optimization, and self-healing tests are making testing more efficient and effective.
• Visual Testing: Explore the emerging capabilities of AI in visual testing and how it's set to revolutionize UI verification.
• Inflectra's AI Solutions: See demonstrations of Inflectra's cutting-edge AI tools like the ChatGPT plugin and Azure Open AI platform, designed to streamline your testing process.
Whether you're a developer, tester, or QA professional, this webinar will give you valuable insights into how AI is shaping the future of software delivery.
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Accelerate your Kubernetes clusters with Varnish CachingThijs Feryn
A presentation about the usage and availability of Varnish on Kubernetes. This talk explores the capabilities of Varnish caching and shows how to use the Varnish Helm chart to deploy it to Kubernetes.
This presentation was delivered at K8SUG Singapore. See https://feryn.eu/presentations/accelerate-your-kubernetes-clusters-with-varnish-caching-k8sug-singapore-28-2024 for more details.
Elevating Tactical DDD Patterns Through Object CalisthenicsDorra BARTAGUIZ
After immersing yourself in the blue book and its red counterpart, attending DDD-focused conferences, and applying tactical patterns, you're left with a crucial question: How do I ensure my design is effective? Tactical patterns within Domain-Driven Design (DDD) serve as guiding principles for creating clear and manageable domain models. However, achieving success with these patterns requires additional guidance. Interestingly, we've observed that a set of constraints initially designed for training purposes remarkably aligns with effective pattern implementation, offering a more ‘mechanical’ approach. Let's explore together how Object Calisthenics can elevate the design of your tactical DDD patterns, offering concrete help for those venturing into DDD for the first time!
Kubernetes & AI - Beauty and the Beast !?! @KCD Istanbul 2024Tobias Schneck
As AI technology is pushing into IT I was wondering myself, as an “infrastructure container kubernetes guy”, how get this fancy AI technology get managed from an infrastructure operational view? Is it possible to apply our lovely cloud native principals as well? What benefit’s both technologies could bring to each other?
Let me take this questions and provide you a short journey through existing deployment models and use cases for AI software. On practical examples, we discuss what cloud/on-premise strategy we may need for applying it to our own infrastructure to get it to work from an enterprise perspective. I want to give an overview about infrastructure requirements and technologies, what could be beneficial or limiting your AI use cases in an enterprise environment. An interactive Demo will give you some insides, what approaches I got already working for real.
Essentials of Automations: Optimizing FME Workflows with ParametersSafe Software
Are you looking to streamline your workflows and boost your projects’ efficiency? Do you find yourself searching for ways to add flexibility and control over your FME workflows? If so, you’re in the right place.
Join us for an insightful dive into the world of FME parameters, a critical element in optimizing workflow efficiency. This webinar marks the beginning of our three-part “Essentials of Automation” series. This first webinar is designed to equip you with the knowledge and skills to utilize parameters effectively: enhancing the flexibility, maintainability, and user control of your FME projects.
Here’s what you’ll gain:
- Essentials of FME Parameters: Understand the pivotal role of parameters, including Reader/Writer, Transformer, User, and FME Flow categories. Discover how they are the key to unlocking automation and optimization within your workflows.
- Practical Applications in FME Form: Delve into key user parameter types including choice, connections, and file URLs. Allow users to control how a workflow runs, making your workflows more reusable. Learn to import values and deliver the best user experience for your workflows while enhancing accuracy.
- Optimization Strategies in FME Flow: Explore the creation and strategic deployment of parameters in FME Flow, including the use of deployment and geometry parameters, to maximize workflow efficiency.
- Pro Tips for Success: Gain insights on parameterizing connections and leveraging new features like Conditional Visibility for clarity and simplicity.
We’ll wrap up with a glimpse into future webinars, followed by a Q&A session to address your specific questions surrounding this topic.
Don’t miss this opportunity to elevate your FME expertise and drive your projects to new heights of efficiency.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Slack (or Teams) Automation for Bonterra Impact Management (fka Social Soluti...Jeffrey Haguewood
Sidekick Solutions uses Bonterra Impact Management (fka Social Solutions Apricot) and automation solutions to integrate data for business workflows.
We believe integration and automation are essential to user experience and the promise of efficient work through technology. Automation is the critical ingredient to realizing that full vision. We develop integration products and services for Bonterra Case Management software to support the deployment of automations for a variety of use cases.
This video focuses on the notifications, alerts, and approval requests using Slack for Bonterra Impact Management. The solutions covered in this webinar can also be deployed for Microsoft Teams.
Interested in deploying notification automations for Bonterra Impact Management? Contact us at sales@sidekicksolutionsllc.com to discuss next steps.
Neuro-symbolic is not enough, we need neuro-*semantic*Frank van Harmelen
Neuro-symbolic (NeSy) AI is on the rise. However, simply machine learning on just any symbolic structure is not sufficient to really harvest the gains of NeSy. These will only be gained when the symbolic structures have an actual semantics. I give an operational definition of semantics as “predictable inference”.
All of this illustrated with link prediction over knowledge graphs, but the argument is general.
2. 12.0 Content
Content
12.1 Objectives
12.2 Overview of Networking
12.3 Introduction to DDBMSs
- Concepts 12.6 Transparency in a DDBMS
- Advantages and Disadvantages - Distribution Transparency
- Homogeneous and Heterogeneous - Transaction Transparency
12.4 Functions and Architecture - Performance Transparency
- Functions of a DDBMS 12.7 Date’s 12 Rules for DDBMs
- Reference Architecture for a 12.8 Summary
DDBMS/ Federated MDBS
12.5 Distributed Relational Database Design
- Data Allocation
- Fragmentation
Slide 2/32
3. 12.1 Objectives
Objectives
In this Lecture you will learn:
• Concepts.
• Advantages and disadvantages of distributed
databases.
• Functions and architecture for a DDBMS.
• Distributed database design.
• Levels of transparency.
• Comparison criteria for DDBMSs.
Slide 3/32
4. 12.2 Overview of Networking
Overview of Networking
Network: interconnected collection of autonomous computers,
capable of exchanging information.
• Local Area Network (LAN) intended for connecting computers at
same site.
• Wide Area Network (WAN) used when computers or LANs need
to be connected over long distances.
•WAN relatively slow
•Less reliable than LANs.
•DDBMS using LAN provides much faster response time than
one using WAN.
Slide 4/32
5. 12.2 Overview of Networking
Overview of Networking
Network: interconnected collection of autonomous computers,
capable of exchanging information.
• Local Area Network (LAN) intended for connecting computers at
same site.
• Wide Area Network (WAN) used when computers or LANs need
to be connected over long distances.
•WAN relatively slow
•Less reliable than LANs.
•DDBMS using LAN provides much faster response time than
one using WAN.
Slide 5/32
6. 12.3 Introduction
Concepts
Databases and networks:
1. A centralized DBMS could be physically processed
by several computers distributed across a network
2. There could be several separate DBMS on several
computers distributed across a network
3. There may be a Distributed DBMS (DDBMS)
• made up of several DBMSs distributed across a network
• each with local autonomy
• Each participates in at least one global DBMS action
• The DDBMS therefore can operate as a single global DBMS
Slide 6/32
7. 12.3 Introduction
Concepts
DDBMS to Avoid `islands of information’ problem…
A “Distributed Database”: is a logically interrelated collection of
shared data (and a description of this data), physically distributed
over a computer network.
A “Distributed DBMS” (DDBMS): is a Software system that
permits the management of the distributed database and makes
the distribution transparent to users.
Fundamental Principle: make distribution transparent to user.
The fact that fragments are stored on different
computers is hidden from the users
Slide 7/32
8. 12.3 Introduction
Concepts
DDBMS has following characteristics:
•Data at each site is under
•Collection of logically-related shared data. control of a DBMS.
•Data split into fragments. •DBMSs handle local
•Fragments may be replicated. applications autonomously.
•Fragments/replicas allocated to sites. •Each DBMS participates in at
•Sites linked by a communication network. least one global application.
Slide 8/32
9. 12.3 Introduction
Important difference between DDBMS and distributed
processing !
Distributed processing of
DDBMS centralised DBMS
Slide 9/32
10. 12.3 Introduction
Distributed Processing
Distributed processing of a centralised DBMS has following
characteristics :
•Much more tightly coupled than a DDBMS.
•Database design is same as for standard DBMS
•No attempt to reflect organizational structure
•Much simpler than DDBMS
•More secure than DDBMS
•No local autonomy
Slide 10/32
11. 12.3 Introduction
Important difference between DDBMS and parallel database
Parallel Database
Architectures:
DDBMS Shared: a)memory b)disk
c)nothing
Slide 11/32
12. 12.3 Introduction
Why use a DDBMS? (!)
Advantages: Disadvantages:
•Reflects organizational •Complexity
structure •Cost
•Improved shareability and •Security
local autonomy •Integrity control more
•Improved availability difficult
•Improved reliability •Lack of standards
•Improved performance •Lack of experience
•Economics •Database design more
•Modular growth complex
Slide 12/32
13. 12.3 Introduction
Homogeneous &
Heterogeneous DDBMSs
Homogeneous: All sites use same DBMS product.
• Much easier to design and manage.
• Approach provides incremental growth
• Allows increased performance.
Heterogeneous: Sites may run different DBMS products,
underlying data models.
• Sites implemented their own databases - integration considered later.
•Translations required to allow for • Different hardware.
• Different DBMS products.
• Different hardware and DBMS products.
•Typical solution is to use gateways.
Slide 13/32
14. 12.3 Introduction
Open Database access and
interoperability
“The Open Group” formed Specification Working Group (SWG)
to provide specifications that create database infrastructure environment
where there is:
• Common SQL API :allows client applications to be written that do
not need to know vendor of DBMS they are accessing.
• Common database protocol : enables DBMS from one vendor
to communicate directly with DBMS from another vendor without
need for a gateway.
•Common network protocol: allows communications between
different DBMSs.
Slide 14/32
15. 12.3 Introduction
Multidatabase system
(MDBS)!
MDBS: DDBMS where each site maintains complete autonomy
• Resides transparently on top of existing database and file systems
• presents a single database to its users.
• Allows users to access and share data without requiring physical
database integration.
2 types:
• Federated MDBS: looks like a DDBMS for global users and a
centralized DBMS for local users.
• Unfederated MDBS: has no “local” users
Slide 15/32
16. 12.4 Functions and Architecture of a DDBMS
Functions and Architecture of
a DDBMS
Slide 16/32
17. 12.4 Functions and Architecture of a DDBMS
Functions of a DDBMS
• Expect DDBMS to have at least the functionality of a DBMS.
Also to have following functionality:
• Extended communication services.
• Extended Data Dictionary.
• Distributed query processing.
• Extended concurrency control.
• Extended recovery services.
Slide 17/32
18. 12.4 Functions and Architecture of a DDBMS
DDBMS Reference Architecture
A reference architecture consists of:
• Set of global external schemas.
• Global conceptual schema (GCS).
• Fragmentation schema and allocation schema (see later …)
• Set of schemas for each local DBMS conforming to 3-level
ANSI/SPARC.
Comparison with federated MDBS:
In DDBMS: GCS is union of all local conceptual schemas.
In FMDBS: GCS is subset of local conceptual schemas (LCS),
consisting of data that each local system agrees to share.
GCS of tightly coupled system involves integration of either parts of
LCSs or local external schemas.
FMDBS with no GCS is called loosely coupled.
Slide 18/32
19. 12.4 Functions and Architecture of a DDBMS
Distributed Relation Database
Design
Slide 19/32
20. 12.5 Distributed Relational Database Design
Data Allocation !
Four alternative strategies regarding placement of data:
• Centralized: single database and DBMS stored at one site with
users distributed across the network.
• Partitioned: Database partitioned into disjoint fragments, each
fragment assigned to one site.
• Complete Replication: Consists of maintaining complete copy
of database at each site.
• Selective Replication: Combination of partitioning, replication,
and centralization.
Comparison of strategies
Slide 20/32
21. 12.5 Distributed Relational Database Design
Data Allocation
Four alternative strategies regarding placement of data:
• Centralized: single database and DBMS stored at one site with
users distributed across the network.
• Partitioned: Database partitioned into disjoint fragments, each
fragment assigned to one site.
• Complete Replication: Consists of maintaining complete copy
of database at each site.
• Selective Replication: Combination of partitioning, replication,
and centralization.
Comparison of strategies
Slide 21/32
22. 12.5 Distributed Relational Database Design
Fragmentation
Why fragment?
Disadvantages: Performance & Integrity.
Usage:
- Apps work with views rather than entire relations.
Efficiency:
- Data stored close to where most frequently used.
- Data not needed by local applications is not stored.
Security:
- and so not available to unauthorized users.
Parallelism:
- With fragments as unit of distribution, T can be divided
into several subqueries that operate on fragments.
Slide 22/32
23. 12.5 Distributed Relational Database Design
Fragmentation !
Three Correctness of fragmentation rules:
1. Completeness: If relation R decomposed into fragments R1, R2, ...
Rn, each data item that can be found in R must appear in at least one
fragment.
2. Reconstruction: Must be possible to define a relational operation
that will reconstruct R from the fragments.
- for horizontal fragmentation: Union operation
- for vertical: Join
3. Disjointness: If data item di appears in fragment Ri, then should not
appear in any other fragment.
- Exception: vertical fragmentation.
- For horizontal fragmentation, data item is a tuple.
- For vertical fragmentation, data item is an attribute.
Slide 23/32
24. 12.5 Distributed Relational Database Design
Fragmentation !
Four types of fragmentation:
1. Horizontal: Consists of a subset of the tuples of a relation.
- Defined using Selection operation
- Determined by looking at predicates used by Ts.
- Involves finding set of minimal (complete and relevant)
predicates.
- Set of predicates is complete, iff, any two tuples in same
fragment are referenced with same probability by any application.
- Predicate is relevant if there is at least one application that
accesses fragments differently.
Slide 24/32
25. 12.5 Distributed Relational Database Design
Fragmentation !
Other possibility is no
Four types of fragmentation: fragmentation:
2. Vertical: subset of atts of a relation.
-If relation is small and not
- Defined using Projection operation updated frequently, may be
- Determined by establishing affinity of one attribute fragment.
better not to to another.
3. Mixed: horizontal fragment that is vertically fragmented, or a
vertical fragment that is horizontally fragmented.
- Defined using Selection and Projection operations
4. Derived: horizontal fragment that is based on horizontal
fragmentation of a parent relation.
- Ensures fragments frequently joined together are at same site.
- Defined using Semijoin operation
Slide 25/32
26. 12.6 Distributed Relational Database Design
Transparency in a DDBMS
Transparency hides implementation details from users.
Overall objective: equivalence to user of DDBMs to
centralised DBMS
- FULL transparency not universally accepted objective
Four main types:
1. Distribution transparency
2. Transaction transparency
3. Performance transparency
4. DBMS transparency (only applicable to heterogeneous)
Slide 26/32
27. 12.6 Distributed Relational Database Design
1. Distribution Transparency
Distribution transparency: allows user to perceive database as
single, logical entity.
If DDBMS exhibits distribution transparency, user does not need to know:
• fragmentation transparency: data is fragmented
• Location transparency: location of data items
• otherwise call this local mapping transparency
• replication transparency : user unaware of replication of fragments
Naming transparency : each item in a DDB must have a unique name.
-One solution: create central name server - loss of some local autonomy.
- central site may become a bottleneck. - low availability: if the central site fails.
Alternative solution: prefix object with identifier of creator site, each
fragment and its copies. Then each site uses alias.
Slide 27/32
28. 12.6 Distributed Relational Database Design
2. Transaction Transparency
Transaction transparency: Ensures all distributed Ts
maintain distributed database’s integrity and consistency.
• Distributed T accesses data stored at more than one
location.
• Each T is divided into no. of subTs, one for each site that
has to be accessed.
• DDBMS must ensure the indivisibility of both the global T
and each of the subTs.
Slide 28/32
29. 12.6 Distributed Relational Database Design
2. Transaction Transparency
Concurrency transparency: All Ts must execute independently and
be logically consistent with results obtained if Ts executed in some
arbitrary serial order.
• Replication makes concurrency more complex
Failure transparency: must ensure atomicity and durability of global T.
• Means ensuring that subTs of global T either all commit or all abort.
• Classification transparency: In IBM’s Distributed Relational
Database Architecture (DRDA), four types of Ts:
– Remote request
– Remote unit of work
– Distributed unit of work
– Distributed request .
Slide 29/32
30. 12.6 Distributed Relational Database Design
3. Performance Transparency
DDBMS: - no performance degradation due to distributed architecture.
- determine most cost-effective strategy to execute a request.
Distributed Query Processor (DQP) maps data request into ordered
sequence of operations on local databases.
- Must consider fragmentation, replication, and allocation schemas.
DQP has to decide:
1. which fragment to access
2. which copy of a fragment to use
3. which location to use.
- produces execution strategy optimized with respect to some cost function.
Typically, costs associated with a distributed request include: I/O cost;
CPU cost, communication cost.
Slide 30/32
31. 12.7 Dates 12 Rules for DDBMS
Date’s 12 Rules for DDBMS
Fundamental Principle: To the user, distributed system should
look exactly like a nondistributed system.
1. Local Autonomy
2. No Reliance on a Central Site
3. Continuous Operation Ideals:
4. Location Independence 9. Hardware Independence
5. Fragmentation Independence 10. Operating System
6. Replication Independence Independence
7. Distributed Query Processing 11. Network Independence
8. Distributed Transaction Processing 12. Database Independence
Slide 31/32
32. 12.8 Summary
Summary
12.1 Objectives 12.6 Transparency in a DDBMS
12.2 Overview of Networking - Distribution Transparency
12.3 Introduction to DDBMSs - Transaction Transparency
Concepts - Performance Transparency
Advantages and Disadvantages 12.7 Date’s 12 Rules for DDBMs
Homogeneous and Heterogeneous
NEXT LECTURE:
12.4 Functions and Architecture III Current Trends
Functions of a DDBMS Part 2: Distributed DBMSs-
Reference Architecture for a Advanced concepts
- advanced concepts
DDBMS/ Federated MDBS
- protocols for distributed
12.5 Distributed Relational Database Designdeadlock control
Data Allocation - X/Open Distributed Transaction
Fragmentation Processing Model
- Oracle.
Slide 32/32
Editor's Notes
So a public key program is used to encrypt a randomly generated encryption key. The random key is used to encrypt the actual message using a symmetric algorithm