1 / 56

Introduction to Database

Introduction to Database. CHAPTER 1 INTRODUCTION. Database-System Applications Purpose of Database Systems View of Data Database Languages Relational Databases Database Design Data Storage and Querying Transaction Management Database Architecture Database Users and Administrators.

neron
Download Presentation

Introduction to Database

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. Introduction to Database CHAPTER 1 INTRODUCTION • Database-System Applications • Purpose of Database Systems • View of Data • Database Languages • Relational Databases • Database Design • Data Storage and Querying • Transaction Management • Database Architecture • Database Users and Administrators

  2. Database System: Introduction • Database Management System (DBMS) • Contains a large bodies of information • Collection of interrelated data (database) • Set of programs to access the data • Goal of a DBMS: • provides a way to store and retrieve database information that is both • convenient and • efficient. • Functions of DBMS: Management of Data (MOD) • Defining structure for storage data • Providing mechanisms for manipulation of data • Ensure safety of data (system crashes, unauthorized access, misused, …) • Concurrent control in multi-user environment • Computer Scientists: developed a lot of concepts and technique for MOD • concepts and technique form the focus of this book, and this course

  3. 1.1 Database-System Applications • Database Applications: • Banking: all transactions • Airlines: reservations, schedules • Universities: registration, grades, student profile, .. • Sales: customers, products, purchases • Manufacturing: production, inventory, orders, supply chain • Human resources: employee records, salaries, tax deductions • Databases touch all aspects of our lives

  4. 1.2 Purpose of Database Systems • In the early days, database applications were built on top of file systems • Drawbacks of using file systems to store data: • Data redundancy and inconsistency • Multiple file formats, duplication of information in different files • Difficulty in accessing data • Need to write a new program to carry out each new task • Data isolation — multiple files and formats • Integrity problems • Integrity constraints (e.g. account balance > 0) become part of program code • Hard to add new constraints or change existing ones

  5. Drawbacks of using file systems (cont.) • Drawbacks of using file systems to store data: (cont.) • Atomicity of updates • Failures may leave database in an inconsistent state with partial updates carried out • E.g. transfer of funds from one account to another should either complete or not happen at all • Concurrent access by multiple users • Concurrent accessed needed for performance • Uncontrolled concurrent accesses can lead to inconsistencies • E.g. two people reading a balance and updating it at the same time • Security problems Database systems offer solutions to all the above problems 原子性, 單一性 Solution

  6. 1.3 View of Data and Data Abstraction • Physical level: describes how a record (e.g., customer information) is stored in disk. • By sequential file, pointer, or hash structure, … • Logical level: describes data stored in database, and the relationships among the data. typecustomer = recordname : string;street : string;city : string; income : integer; end; • View level: application programs hide details of data types. Views can also hide information (e.g., income) for security purposes.

  7. View of Data -1: Three Levels An architecture for a database system

  8. User A1 User A2 User B1 User B2 User B3 Host Language + DSL Host Language + DSL Host Language + DSL Host Language + DSL Host Language + DSL C, C++ DSL (Data Sub. Language) e.g. SQL 3 1 2 External View B External View @ # & External schema A External schema B External/conceptual mapping B External/conceptual mapping A Database management system Dictionary (DBMS) e.g. system catalog Conceptual View Conceptual schema < DBA Conceptual/internal mapping (Build and maintain schemas and mappings) Storage structure definition (Internal schema) ... 1 2 3 100 Stored database (Internal View) # @ & View of Data -2: Three Levels

  9. account customer 1.3.2 Instances and Schemas • Schema – the logical structure of the database • e.g., the database consists of information about a set of customers and accounts and the relationship between them • Analogous to type information of a variable in a program • Physical schema: database design at the physical level • Logical schema: database design at the logical level create tableaccount (account-numberchar(10),balanceinteger) typecustomer = recordname : string;street : string;city : integer; end;

  10. Instances and Schemas (cont.) • Instance – the actual content of the database at a particular point in time • Analogous to the value of a variable • Physical Data Independence– the ability to modify the physical schema without changing the logical schema • Applications depend on the logical schema • In general, the interfaces between the various levels and components should be well defined so that changes in some parts do not seriously influence others. Instance Schema create tableaccount (account-numberchar(10),balanceinteger)

  11. View of Data: Three Levels An architecture for a database system Physical Data Independence

  12. 1.3.3 Data Models • A collection of conceptual tools for describing • data (entities, objects) • data relationships • data semantics • data consistency constraints • Data Models Provide: • A way to describe the design of a database at 3 levels • Physical level • Logical level • View level

  13. Category of Data Models • Category of Data Models: • Entity-Relationship model • Relational model • Object-oriented model • Semi-structured data models • Extensible Markup Language (XML) • Older models: • Network model and • Hierarchical model

  14. 1.4 Database Languages • Data Definition Language (DDL): • Specification notation for defining the database schema • E.g. create tableaccount (account-numberchar(10),balanceinteger) • Data Manipulation Language (DML) • To express database queries or updates • E.g. Selectaccount-numberfrom accountwhere balance >1000 • SQL (Structured Query Language): a single language for both

  15. 1.4.1 Data-Manipulation Language (DML) • Language for accessing and manipulating the data organized by the appropriate data model • DML also known as query language • For retrieval, insertion, deletion, modification (update) • Two classes of languages • Procedural DMLs – user specifies what data is required and how to get those data • E.g. … in C • Declarative DMLs (Nonprocedural DMLs) – user specifies what data is required without specifying how to get those data • E.g. In SQL: Selectaccount-numberfrom accountwhere balance > 700 • SQL is the most widely used query language

  16. 1.4.2 Data-Definition Language (DDL) • Specification notation for defining the database schema • E.g. create tableaccount (account-numberchar(10),balanceinteger) • Define: • Attributes name • Data type • Consistency constraints (integrity constraints) • Domain constraints: e.g. assets are integer type • Assertions: e.g. assets >= 0 • Authorization: for different users • …. create tablebranch (branch-namechar(15),branch-citychar(30),assetsinteger,primary key (branch-name),check (assets >= 0))

  17. Data Dictionary and Storage Definition • Data Dictionary: • DDL compiler generates a set of tables stored in a data dictionary • contains metadata (i.e., data about data) • Database schema • System tables • Users • … • Database system consults the Data dictionary before reading or modifying actual dada. • Data storage and definition language • To specify the storage structure and access methods(ch. 11,12) • Usually an extension of the data definition language

  18. DBMS environments Relational DBMS Relational Data Model C, PASCAL ,PL/1 assembler machine 1.5 Relational Databases • Definition 1: A Relational Database is a databasethat is perceived by the users as a collection oftime-varying, normalized relations (tables). • Perceived by the users: the relational model apply at the view level and logical levels. • Time-varying: the set of tuples changes with time. • Normalized: contains no repeating group (only contains atomic value). • The relational model represents a database system at a level of abstraction that removed from the details of the underlying machine, like high-level language.

  19. 1.5.1 Tables • Definition 2: A Relational Database is a database that is perceived by its users as a collection of tables (and nothing but tables).

  20. 1.5.2 Data-Manipulation Language • SQL (Structured Query Language) : widely used • E.g. find the name of the customer with customer-id 192-83-7465selectcustomer.customer-namefromcustomerwherecustomer.customer-id = ‘192-83-7465’ customer Output: customer-name Johnson

  21. SQL (Structured Query Language) • E.g. find the balances of all accounts held by the customer with customer-id 192-83-7465selectaccount.balancefromdepositor, accountwheredepositor.customer-id = ‘192-83-7465’anddepositor.account-number = account.account-number

  22. 1.5.3 Data-Definition Language • SQL provides DDL to define database schema: • Tables • E.g. create tableaccount (account-numberchar(10),balanceinteger) • Assertions (ref. p.132) • E.g. create assertion balance-constraint check account.balance >= 1000 • integrity Constraints (ref. p.129)

  23. 3. account 4. depositor Referential Integrity Constraint create table account(account-number char(10),branch-name char(15),balance integer, primary key (account-number), create table depositor(customer-name char(20),account-number char(10), primary key (customer-name, account-number), foreign key(account-number) references account, 存款帳 references 存款戶

  24. ODBC/JDBC 1.5.4 Data Access from Application Programs • Application programs generally access databases through one of • Language extensions to allow embedded SQL • Application program interface (e.g. ODBC/JDBC) which allow SQL queries to be sent to a database • ODBC: Open Database Connectivity for C • JDBC: Java Database Connectivity for Java language

  25. 1.6 Database Design • Database Design - The process of designing the general structure of the database: • Logical Design • Physical Design • Logical Design –Deciding on the database schema. • To find a “good” collection of relation schemas. • Business decision– What attributes should we record in the database? • Computer Science decision– What relation schemas should we have and how should the attributes be distributed among the various relation schemas? • Physical Design –Deciding on the physical layout of the database

  26. 1.6.1 Design Process • Phase I • Specification of user requirement (with domain experts) • Phase II • Conceptual design (ch. 6) • Choose a data model • Design tables • Normalization (ch. 7) • Phase III • Specification of functional requirements • Phase IV • Implementation • Logical-design • Physical-design (ch. 11, 12)

  27. 1.6.2 Database Design for Banking • Banking Database: consists 6 relations: • branch (branch-name, branch-city, assets) • customer (customer-name, customer-street, customer-only) • account (account-number, branch-name, balance) • loan (loan-number, branch-name, amount) • depositor (customer-name, account-number) • borrower (customer-name, loan-number)

  28. 6. loan 3. depositor 5. account 存款帳 4. borrower 存款戶 貸款帳 貸款戶 Example: Banking Database 1. branch 2. customer 客戶(存款戶,貸款戶) 分公司

  29. 1.6.3 Entity-Relationship Model (ch.6) • Example: Schema in the Entity-Relationship model 客戶 存款帳 存款帳 客戶(存款戶,貸款戶,信用卡戶) 存款戶

  30. E-R Diagram for a Banking Enterprise, p.240

  31. Entity Relationship Model (cont.) • E-R model of real world • Entities (objects) • E.g. customers, accounts, bank branch • Relationships between entities • E.g. Account A-101 is held by customer Johnson • E.g. Relationship set depositor associates customers with accounts • Widely used for database design • Database design in E-R model usually converted to design in the Relational model (coming up next) which is used for storage and processing • Relational Model (ch. 2) • E-R model (ch. 6)

  32. <e.g.> Supplier-and-Parts Database S SP S# P# QTY S1 P1 300 S1 P2 200 S1 P3 400 S1 P4 200 S1 P5 100 S1 P6 100 S2 P1 300 S2 P2 400 S3 P2 200 S4 P2 200 S4 P4 300 S4 P5 400 S# SNAME STATUS CITY S1 Smith 20 London S2 Jones 10 Paris S3 Blake 30 Paris S4 Clark 20 London S5 Adams 30 Athens P P# PNAME COLOR WEIGHT CITY P1 Nut Red 12 London P2 Bolt Green 17 Paris P3 Screw Blue 17 Rome P4 Screw Red 14 London P5 Cam Blue 12 Paris P6 Cog Red 19 London 1.6.4 Normalization • Definition: A Relational Database is a database that is perceived by its users as a collection of tables (and nothing but tables).

  33. SP' S' P P# ... ... ... . . . . . . . . S1, Smith, 20, London, P1, Nut, Red, 12, London, 300 S1, Smith, 20, London, P2, Bolt, Green, 17, Paris, 200 . . S4, Clark, 20, London, P5, Cam, Blue, 12, Paris, 400 S# CITY P# QTY S1 London P1 300 S1 London P2 200 . . . . S# SNAME STATUS S1 Smith . S2 . . . . . Normalization (異常) Redundancy Update Anomalies! S P SP S# P# QTY . . . . . . S# SNAME STATUS CITY s1 . . London . . . . P# ... ... ... . . . . . . . . Problem of Normalization <e.g.> or

  34. 6. borrower 1.7 Object-Based and Semistructured Databases • Extend the relational data model • by including object orientation and • constructs to deal with added data types. (video, image, …) • Allow attributes of tuples to have complex types, including • non-atomic values such as nested relations. (repeated data, …) • Preserve relational foundations, • in particular the declarative access to data, while extending modeling power.

  35. 1.7.2 Semistructured Data Models • XML (Extensible Markup Language) • Defined by the WWW Consortium (W3C) • Originally intended as a document markup language not a database language • The ability to specify new tags, and to create nested tag structures made XML a great way to exchange data, not just documents • XML has become the basis for all new generation data interchange formats. • A wide variety of tools is available for parsing, browsing and querying XML documents/data 聯合

  36. Query DBMS Language Processor Optimizer Operation Processor Access Method File Manager Database 1.8 Data Storage and Querying • Components of Database System • Query Processor • Helps to simplify to access data • High-level view • Users are not be burdened unnecessarily with the physical details • Storage Manager • Require a large amount of space • Can not store in main memory • Disk speed is slower • Minimize the need to move data between disk and main memory Query Processor Storage Manager Goal of a DBMS: provides a way to store and retrieve data that is both convenient and efficient.

  37. Overall System Structure Overall System Structure low-level data stored database

  38. 1.8.1 Storage Management • Storage Manager • is a program module • that provides the interface between the low-level data stored and the application programs and queries submitted to the system. • Tasks of the Storage Manager: • interaction with the file manager (part of Operating System) • Translates DML into low-level file-system commands, • i.e. responsible for storing, retrieving and updating of data in database • Data Structures of the Storage Manager • Data files: store database itself • Data Dictionary: store metadata • Indices: provide fast access to data items that hold particular values

  39. Storage Management (cont.) • Components of Storage manager: • Authorization and Integrity Manager • Tests for the satisfaction of integrity constraints • Checks the authority of users to access data • Transaction Manager • Ensure the database in a consistent state (correct) after failures • Ensure that concurrent transaction executions proceed without conflicting • File Manager • Manages the allocation of space on disk • Manages the data structures used to representation data stored • Buffer manager • Fetches data from disk into main memory • Decides what data to cache in main memory

  40. 1.8.2 The Query Processor • DDL Interpreter • Interprets DDL statements • write the definitions (schema, view, ..) into the data dictionary • DML Compiler • Translates DML statements into an evaluation plan (or some evaluation plans) which consists low-level instructions • Query Optimization: picks the lowest cost evaluation plan • Query Evaluation Engine: • execute low-level instructions generated by the DML Compiler

  41. Flow of Query Processing 1. Parsing and translation 2. Optimization 3. Evaluation

  42. Query Optimizer • Alternative ways of evaluating a given query • Equivalent expressions • Different algorithms for each operation • Cost difference between a good and a bad way of evaluating a query can be enormous • Need to estimate the cost of operations • Depends critically on statistical information about relations which the database must maintain • Need to estimate statistics for intermediate results to compute cost of complex expressions

  43. DBMS Language Processor Internal Form : • ((S SP) Optimizer Language Processor Operator Processor Access Method Access Method e.g.B-tree; Index; Hashing File System database Example: A Simple Query Processing (補) Query in SQL： SELECT CUSTOMER. NAME FROM CUSTOMER, INVOICE WHERE REGION = 'N.Y.' AND AMOUNT > 10000 AND CUTOMER.C#=INVOICE.C Query Processor Operator : SCAN C using region index, create C SCAN I using amount index, create I SORT C?and I?on C# JOIN C?and I?on C# EXTRACT name field Calls to Access Method： OPEN SCAN on C with region index GET next tuple . . . Storage Manager Calls to file system： GET10th to 25th bytes from block #6 of file #5

  44. 1.9 Transaction Management • Transaction: • A transaction is a collection of operations that performs a single logical function in a database application • Atomicity: all or nothing • Failure recovery manager • ensures that the database remains in a consistent (correct) state, • Failure: • system failures (e.g., power failures and operating system crashes) • transaction failures. • Concurrency-control manager • controls the interaction among the concurrent transactions, to ensure the consistency of the database.

  45. 1.10 Data Mining and Analysis • Data Analysis and Mining • Decision Support Systems • Data Analysis and OLAP (Online analytical processing), • Data Warehousing • Data Mining

  46. Decision-support systems are used to make business decisions, often based on data collected by on-line transaction systems. Examples of business decisions: What items to stock? What insurance premium to change? To whom to send advertisements? Examples of data used for making decisions Retail sales transaction details Customer profiles (income, age, gender, etc.) Decision Support Systems

  47. Data Mining (ch.18) • Data mining: • seeks to discover knowledge automatically in the form of statistical rules and patterns from large databases. E.g. p.23: Young women buy cars. • is the process of semi-automatically analyzing large databases to find useful patterns • Prediction based on past history • Predict if a credit card applicant poses a good credit risk, based on some attributes (income, job type, age, ..) and past history • Predict if a pattern of phone calling card usage is likely to be fraudulent • Descriptive Patterns • Associations • Find books that are often bought by “similar” customers. If a new such customer buys one such book, suggest the others too. (library) • Associations may be used as a first step in detecting causation 欺騙的 引起;因果關係

  48. 1.11 Database Architecture • System Structure of a Database System • Fig. 1.6 (p.25) • Application Structure • User uses database at the site • Users uses database through a network • Client: remote database users work • Sever: database system runs here • Partition of Database Application • Two-tier architecture • Three-tier architecture

  49. Application Architectures ODBC/JDBC • Two-tier Architecture: e.g. client programs using ODBC/JDBC to communicate with a database • Three-tier Architecture: e.g. web-based applications, and applications built using “middleware”

  50. User A1 User A2 User B1 User B2 User B3 Host Language + DSL Host Language + DSL Host Language + DSL Host Language + DSL Host Language + DSL C, C++ DSL (Data Sub. Language) e.g. SQL 3 1 2 External View B External View @ # & External schema A External schema B External/conceptual mapping B External/conceptual mapping A Database management system Dictionary (DBMS) e.g. system catalog Conceptual View Conceptual schema < DBA Conceptual/internal mapping (Build and maintain schemas and mappings) Storage structure definition (Internal schema) ... 1 2 3 100 Stored database (Internal View) # @ & 1.12 Database Users and Administrators

More Related