1 / 20

Database Environment

Database Environment. Week 1, Day 2 (based on Ch 2 of Connolly and Begg). Database Environment - Outline. ANSI-SPARC Architecture Multiple levels for multiple individuals Database Languages Functions of a DBMS Multi-User DBMS Architectures. ANSI-SPARC Architecture - Outline. Objective

otylia
Télécharger la présentation

Database Environment

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related