Download
database environment n.
Skip this Video
Loading SlideShow in 5 Seconds..
Database Environment PowerPoint Presentation
Download Presentation
Database Environment

Database Environment

126 Views Download Presentation
Download Presentation

Database Environment

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Database Environment Week 1, Day 2 (based on Ch 2 of Connolly and Begg) CMPT 355 Sept-Dec 2010 - w1d2

  2. Database Environment - Outline • ANSI-SPARC Architecture • Multiple levels for multiple individuals • Database Languages • Functions of a DBMS • Multi-User DBMS Architectures CMPT 355 Sept-Dec 2010 - w1d2

  3. ANSI-SPARC Architecture - Outline • Objective • Database Levels • Other Terms CMPT 355 Sept-Dec 2010 - w1d2

  4. Architecture - Objective • “To separate each user’s view of the database from the way the database is physically represented” • Each User • has customized views based on need to access • is independent from storage details • Database Administrator (DBA) • controls physical, internal, and conceptual structures • without affecting users’ views Text p.35 Section 2.1 CMPT 355 Sept-Dec 2010 - w1d2

  5. Architecture - Levels The architecture considers 3 (+1) levels • External Level • The user’s view of the database. • This level describes that part of the database that is relevant to each user. (based on an individual user’s need to know) • Conceptual Level • The community view of the database. • This level describes what data is stored in the database and the relationships among the data. (organization’s complete set of data) • Internal Level • The physical representation of the database on the computer. • This level describes the data stored on the computer. (IT only) • Physical Organization of Data (Level) • Managed by the operating system under the direction of the DBMS Text p.35-37 Section 2.1 CMPT 355 Sept-Dec 2010 - w1d2

  6. Architecture – Other Terms Schema • a description of a database • Can exist at each of three ANSI-SPARC levels (external, conceptual, internal) Mapping • consistent correspondence between schemas at different levels Instance • the data in a database (or portion thereof) at a particular instance in time Independence • the immunity of one level of the database to changes at a lower level • the ability to deal with one level of a database and for the DBMS to automatically maintain consistency Text p.35-37 Section 2.1 CMPT 355 Sept-Dec 2010 - w1d2

  7. Database Languages Data Definition Language (DDL) • “A language that allows the DBA or the user to describe and name entities, attributes, and relationships required for the application, together with any associated integrity and security constraints.” • DBA should control defining • Users interact with those defined portions allowed them by the DBA • Users should request DBA’s to make necessary changes Data Manipulation Language (DML) • “A language that provides a set of operations to support the basic data manipulation operations on the data held in the database.” • User (‘s application developer) uses for interfacing applications with the database • DBA uses for maintenance purposes Text p40-41 Section 2.2 CMPT 355 Sept-Dec 2010 - w1d2

  8. Database Languages -cont Procedural DML • “A language that allows the user to tell the system what data is needed and exactly how to retrieve the data.” Non-procedural DML • “A language that allows the user to state what data is needed rather than how it is to be retrieved.” Fourth Generation Languages (4GLs) • Are non-procedural languages that typically include a number of tools to help quickly develop applications, such as: • Forms generators • Report generators • Graphics generators • Application generators • Often limit the developer’s freedom to go beyond those application areas for which the 4GL tools were specifically developed Text p41-43 Section 2.2 CMPT 355 Sept-Dec 2010 - w1d2

  9. Functions of a DBMS • Basic data processing functionality • Data storage, retrieval, and update (DML) • A user-accessible catalog (DDL) Text p.48-52 Section 2.4 CMPT 355 Sept-Dec 2010 - w1d2

  10. Functions of a DBMS – (cont.) • Business Integrity supporting functionality • Transaction support • To ensure all or no parts of a transaction are processed • Concurrency control services • To ensure updates are completed before being updated • Recovery services • To repair damages to a db (e.g. from system crashes) • Authorization services • To protect the database from unauthorized accessing • Support for data communication • To support decentralized access by workers and clients Text p.48-52 Section 2.4 CMPT 355 Sept-Dec 2010 - w1d2

  11. Functions of a DBMS – (cont.) • DB administration functionality • Integrity services • To assist in evolving the database • Services to promote data independence • To separate programs from the data • Utility services • To allow tuning of the database Text p.48-52 Section 2.4 CMPT 355 Sept-Dec 2010 - w1d2

  12. Multi-User DBMS - Outline • Client-Server Architecture • Server-Server Architecture CMPT 355 Sept-Dec 2010 - w1d2

  13. Multi-User DBMS Architectures Client-Server Architecture Text p59 Section 2.6.3 CMPT 355 Sept-Dec 2010 - w1d2

  14. Multi-User DBMS Architectures Client-Server Architecture (cont) • It is typical for both the server and client programs to be developed by the same organization. • There are various tools that act as (or assist in developing) servers and clients • Server • Generally use a standard DBMS e.g. PostgresSQL • Need to be customize DB with a database schema and data • May be fronted by a server side application program / tp monitor • Client • May be a standardized client that allows querying a database e.g. dbvisualizer • May be custom client (often downloaded from the server side ap) • That runs in a Web Browser e.g. most e-Commerce aps • That can run standalone e.g. RealPlayer CMPT 355 Sept-Dec 2010 - w1d2

  15. Multi-User DBMS Architectures Server-Server Architecture – Open-edi • Electronic Data Interchange1 • “the automated exchange of any predefined and structured data for business purposes among information systems of two or more parties.”1 • Requires standardization of: • Communications and database technologies • Data elements 1 ISO 14662 Open-Edi Reference Model ,1997 CMPT 355 Sept-Dec 2010 - w1d2

  16. Multi-User DBMS Architectures Server-Server Architecture – Open-edi (cont.) • Involves two major views • Business Operational View (BOV) • “a perspective of business transactions limited to those aspects regarding the making of business decisions and commitments among persons, which are needed for the description of a business transaction.” 1 • Involves standardized data elements • Functional Service View (FSV) • “a perspective of business transactions limited to those information technology interoperability aspects of IT Systems needed to support the execution of Open-edi transactions.” 1 • Involves standardized communications and database technologies 1 ISO 14662 Open-Edi Reference Model ,1997 CMPT 355 Sept-Dec 2010 - w1d2

  17. Multi-User DBMS Architectures Server-Server Architecture – Open-edi (cont) • Business Operational View (BOV) • used by User communities • to produce Open-edi scenarios • registered by a Registration Authority1 • Functional Service View (FSV) • used by IT designers and IT implementers • combined with Open-eid scenarios • to enable the execution of open-edi transactions From Figure 4 of ISO 14662 Open-Edi Reference Model ,1997 1 Some registration authorities include: Canada Post (postal codes), US Postal Service (state/province codes), Dublin Core Meta-data Elements (title, creator, date) CMPT 355 Sept-Dec 2010 - w1d2

  18. Multi-User DBMS Architectures Server-Server Architecture – Open-edi (cont) Open-edi Scenario1 • “a formal specification of a class of business transactions having the same business goal.” Business Transaction1 • “a predefined set of activities and/or processes of parties which is initiated by a party to accomplish an explicitly shared business goal and terminated upon recognition of one of the agreed conclusions by all parties although some of the recognition may be implicit.” 1 ISO 14662 Open-Edi Reference Model ,1997 CMPT 355 Sept-Dec 2010 - w1d2

  19. Multi-User DBMS Architectures Server-Server Architecture – Open-edi (cont) CMPT 355 Sept-Dec 2010 - w1d2

  20. Multi-User DBMS Architectures Server-Server Architecture – Open-edi (cont) • ISO 15944-1 • Characteristics of Open-edi • Components of a business transaction • Guidelines for scoping Open-edi scenarios • Rules for specification of Open-edi scenarios and their components • Primitive Open-edi scenario template • Requirements on Open-edi description techniques • Consolidated list of terms and definitions • Codes representing presence-type attributes: mandatory, conditionals, optionals, and not applicable • Unambiguous identification of entities • Business transaction models • Person component • Process component • Data component CMPT 355 Sept-Dec 2010 - w1d2