Presentation is loading. Please wait.

Presentation is loading. Please wait.

2011-09-15 SLIDE 1IS 257 – Fall 2011 Physical Database Design University of California, Berkeley School of Information I 257: Database Management.

Similar presentations


Presentation on theme: "2011-09-15 SLIDE 1IS 257 – Fall 2011 Physical Database Design University of California, Berkeley School of Information I 257: Database Management."— Presentation transcript:

1 2011-09-15 SLIDE 1IS 257 – Fall 2011 Physical Database Design University of California, Berkeley School of Information I 257: Database Management

2 2011-09-15 SLIDE 2IS 257 – Fall 2011 Lecture Outline Review –Relational Algebra and Calculus –Introduction to SQL Physical Database Design Access Methods

3 2011-09-15 SLIDE 3IS 257 – Fall 2011 Lecture Outline Review –Relational Algebra and Calculus –Introduction to SQL Physical Database Design Access Methods

4 2011-09-15 SLIDE 4IS 257 – Fall 2011 Relational Algebra Operations Select Project Product Union Intersect Difference Join Divide

5 2011-09-15 SLIDE 5IS 257 – Fall 2011 Restrict (Select) Extracts specified tuples (rows) from a specified relation (table).

6 2011-09-15 SLIDE 6IS 257 – Fall 2011 Project Extracts specified attributes(columns) from a specified relation.

7 2011-09-15 SLIDE 7IS 257 – Fall 2011 Join Builds a relation from two specified relations consisting of all possible concatenated pairs, one from each of the two relations, such that in each pair the two tuples satisfy some condition. (E.g., equal values in a given col.) A1 B1 A2 B1 A3 B2 B1 C1 B2 C2 B3 C3 A1 B1 C1 A2 B1 C1 A3 B2 C2 (Natural or Inner) Join

8 2011-09-15 SLIDE 8IS 257 – Fall 2011 Outer Join Outer Joins are similar to PRODUCT -- but will leave NULLs for any row in the first table with no corresponding rows in the second. A1 B1 A2 B1 A3 B2 A4 B7 B1 C1 B2 C2 B3 C3 A1 B1 C1 A2 B1 C1 A3 B2 C2 A4 * * Outer Join

9 2011-09-15 SLIDE 9IS 257 – Fall 2011 Join Items

10 2011-09-15 SLIDE 10IS 257 – Fall 2011 Relational Algebra What is the name of the customer who ordered Large Red Widgets? –Select “large Red Widgets” from Part as temp1 –Join temp1 with Line-item on Part # as temp2 –Join temp2 with Invoice on Invoice # as temp3 –Join temp3 with customer on cust # as temp4 –Project Name from temp4

11 2011-09-15 SLIDE 11IS 257 – Fall 2011 Relational Calculus Relational Algebra provides a set of explicit operations (select, project, join, etc) that can be used to build some desired relation from the database. Relational Calculus provides a notation for formulating the definition of that desired relation in terms of the relations in the database without explicitly stating the operations to be performed SQL is based on the relational calculus.

12 2011-09-15 SLIDE 12IS 257 – Fall 2011 SQL - History Structured Query Language SEQUEL from IBM San Jose ANSI 1992 Standard is the version used by most DBMS today (SQL92) Basic language is standardized across relational DBMSs. Each system may have proprietary extensions to standard.

13 2011-09-15 SLIDE 13IS 257 – Fall 2011 SQL Uses Database Definition and Querying –Can be used as an interactive query language –Can be imbedded in programs Relational Calculus combines Select, Project and Join operations in a single command: SELECT

14 2011-09-15 SLIDE 14IS 257 – Fall 2011 SELECT Syntax: –SELECT [DISTINCT] attr1, attr2,…, attr3 FROM rel1 r1, rel2 r2,… rel3 r3 WHERE condition1 {AND | OR} condition2 ORDER BY attr1 [DESC], attr3 [DESC]

15 2011-09-15 SLIDE 15IS 257 – Fall 2011 SELECT Syntax: –SELECT a.author, b.title FROM authors a, bibfile b, au_bib c WHERE a.AU_ID = c.AU_ID and c.accno = b.accno ORDER BY a.author ; Examples in Access...

16 2011-09-15 SLIDE 16IS 257 – Fall 2011 SELECT Conditions = equal to a particular value >= greater than or equal to a particular value > greater than a particular value <= less than or equal to a particular value <> not equal to a particular value LIKE “*term*” (may be other wild cards in other systems) IN (“opt1”, “opt2”,…,”optn”) BETWEEN val1 AND val2 IS NULL

17 2011-09-15 SLIDE 17IS 257 – Fall 2011 Relational Algebra Selection using SELECT Syntax: –SELECT * FROM rel1 WHERE condition1 {AND | OR} condition2;

18 2011-09-15 SLIDE 18IS 257 – Fall 2011 Relational Algebra Projection using SELECT Syntax: –SELECT [DISTINCT] attr1, attr2,…, attr3 FROM rel1 r1, rel2 r2,… rel3 r3;

19 2011-09-15 SLIDE 19IS 257 – Fall 2011 Relational Algebra Join using SELECT Syntax: –SELECT * FROM rel1 r1, rel2 r2 WHERE r1.linkattr = r2.linkattr ;

20 2011-09-15 SLIDE 20IS 257 – Fall 2011 Sorting SELECT BIOLIFE.[Common Name], BIOLIFE.[Length (cm)] FROM BIOLIFE ORDER BY BIOLIFE.[Length (cm)] DESC; Note: the square brackets are not part of the standard, But are used in Access for names with embedded blanks

21 2011-09-15 SLIDE 21IS 257 – Fall 2011 Subqueries SELECT SITES.[Site Name], SITES.[Destination no] FROM SITES WHERE sites.[Destination no] IN (SELECT [Destination no] from DEST where [avg temp (f)] >= 78); Can be used as a form of JOIN.

22 2011-09-15 SLIDE 22IS 257 – Fall 2011 Aggregate Functions Count Avg SUM MAX MIN Others may be available in different systems

23 2011-09-15 SLIDE 23IS 257 – Fall 2011 Using Aggregate functions SELECT attr1, Sum(attr2) AS name FROM tab1, tab2... GROUP BY attr1, attr3 HAVING condition;

24 2011-09-15 SLIDE 24IS 257 – Fall 2011 Using an Aggregate Function SELECT DIVECUST.Name, Sum([Price]*[qty]) AS Total FROM (DIVECUST INNER JOIN DIVEORDS ON DIVECUST.[Customer No] = DIVEORDS.[Customer No]) INNER JOIN DIVEITEM ON DIVEORDS.[Order No] = DIVEITEM.[Order No] GROUP BY DIVECUST.Name HAVING (((DIVECUST.Name) Like "*Jazdzewski"));

25 2011-09-15 SLIDE 25IS 257 – Fall 2011 GROUP BY SELECT DEST.[Destination Name], Count(*) AS Expr1 FROM DEST INNER JOIN DIVEORDS ON DEST.[Destination Name] = DIVEORDS.Destination GROUP BY DEST.[Destination Name] HAVING ((Count(*))>1); Provides a list of Destinations with the number of orders going to that destination

26 2011-09-15 SLIDE 26IS 257 – Fall 2011 SQL Commands Data Definition Statements –For creation of relations/tables…

27 2011-09-15 SLIDE 27IS 257 – Fall 2011 Create Table CREATE TABLE table-name (attr1 attr- type PRIMARY KEY, attr2 attr- type,…,attrN attr-type); Adds a new table with the specified attributes (and types) to the database.

28 2011-09-15 SLIDE 28IS 257 – Fall 2011 Access Data Types (Not MySQL) Numeric (1, 2, 4, 8 bytes, fixed or float) Text (255 max) Memo (64000 max) Date/Time (8 bytes) Currency (8 bytes, 15 digits + 4 digits decimal) Autonumber (4 bytes) Yes/No (1 bit) OLE (limited only by disk space) Hyperlinks (up to 64000 chars)

29 2011-09-15 SLIDE 29IS 257 – Fall 2011 Access Numeric types Byte –Stores numbers from 0 to 255 (no fractions). 1 byte Integer – Stores numbers from –32,768 to 32,767 (no fractions) 2 bytes Long Integer(Default) –Stores numbers from –2,147,483,648 to 2,147,483,647 (no fractions). 4 bytes Single –Stores numbers from -3.402823E38 to –1.401298E–45 for negative values and from 1.401298E–45 to 3.402823E38 for positive values.4 bytes Double –Stores numbers from –1.79769313486231E308 to – 4.94065645841247E–324 for negative values and from 1.79769313486231E308 to 4.94065645841247E–324 for positive values.158 bytes Replication ID –Globally unique identifier (GUID)N/A16 bytes

30 2011-09-15 SLIDE 30IS 257 – Fall 2011 Oracle Data Types CHAR (size) -- max 2000 VARCHAR2(size) -- up to 4000 DATE DECIMAL, FLOAT, INTEGER, INTEGER(s), SMALLINT, NUMBER, NUMBER(size,d) –All numbers internally in same format… LONG, LONG RAW, LONG VARCHAR –up to 2 Gb -- only one per table BLOB, CLOB, NCLOB -- up to 4 Gb BFILE -- file pointer to binary OS file

31 2011-09-15 SLIDE 31IS 257 – Fall 2011 Creating a new table from existing tables Access and PostgreSQL Syntax: SELECT [DISTINCT] attr1, attr2,…, attr3 INTO newtablename FROM rel1 r1, rel2 r2,… rel3 r3 WHERE condition1 {AND | OR} condition2 ORDER BY attr1 [DESC], attr3 [DESC]

32 2011-09-15 SLIDE 32IS 257 – Fall 2011 How to do it in MySQL mysql> SELECT * FROM foo; +---+ | n | +---+ | 1 | +---+ mysql> CREATE TABLE bar (m INT) SELECT n FROM foo; Query OK, 1 row affected (0.02 sec) Records: 1 Duplicates: 0 Warnings: 0 mysql> SELECT * FROM bar; +------+---+ | m | n | +------+---+ | NULL | 1 | +------+---+

33 2011-09-15 SLIDE 33IS 257 – Fall 2011 Database Design Process Conceptual Model Logical Model External Model Conceptual requirements Conceptual requirements Conceptual requirements Conceptual requirements Application 1 Application 2Application 3Application 4 Application 2 Application 3 Application 4 External Model External Model External Model Internal Model Physical Design

34 2011-09-15 SLIDE 34IS 257 – Fall 2011 Physical Database Design Many physical database design decisions are implicit in the technology adopted –Also, organizations may have standards or an “information architecture” that specifies operating systems, DBMS, and data access languages -- thus constraining the range of possible physical implementations. We will be concerned with some of the possible physical implementation issues

35 2011-09-15 SLIDE 35IS 257 – Fall 2011 Physical Database Design The primary goal of physical database design is data processing efficiency We will concentrate on choices often available to optimize performance of database services Physical Database Design requires information gathered during earlier stages of the design process

36 2011-09-15 SLIDE 36IS 257 – Fall 2011 Physical Design Information Information needed for physical file and database design includes: –Normalized relations plus size estimates for them –Definitions of each attribute –Descriptions of where and when data are used entered, retrieved, deleted, updated, and how often –Expectations and requirements for response time, and data security, backup, recovery, retention and integrity –Descriptions of the technologies used to implement the database

37 2011-09-15 SLIDE 37IS 257 – Fall 2011 Physical Design Decisions There are several critical decisions that will affect the integrity and performance of the system –Storage Format –Physical record composition –Data arrangement –Indexes –Query optimization and performance tuning

38 2011-09-15 SLIDE 38IS 257 – Fall 2011 Storage Format Choosing the storage format of each field (attribute). The DBMS provides some set of data types that can be used for the physical storage of fields in the database Data Type (format) is chosen to minimize storage space and maximize data integrity

39 2011-09-15 SLIDE 39IS 257 – Fall 2011 Objectives of data type selection Minimize storage space Represent all possible values Improve data integrity Support all data manipulations The correct data type should, in minimal space, represent every possible value (but eliminate illegal values) for the associated attribute and can support the required data manipulations (e.g. numerical or string operations)

40 2011-09-15 SLIDE 40IS 257 – Fall 2011 MySQL Data Types MySQL supports all of the standard SQL numeric data types. These types include the exact numeric data types (INTEGER, SMALLINT, DECIMAL, and NUMERIC), as well as the approximate numeric data types (FLOAT, REAL, and DOUBLE PRECISION). The keyword INT is a synonym for INTEGER, and the keyword DEC is a synonym for DECIMAL Numeric (can also be declared as UNSIGNED) –TINYINT (1 byte) –SMALLINT (2 bytes) –MEDIUMINT (3 bytes) –INT (4 bytes) –BIGINT (8 bytes) –NUMERIC or DECIMAL –FLOAT –DOUBLE (or DOUBLE PRECISION)

41 2011-09-15 SLIDE 41IS 257 – Fall 2011 MySQL Data Types The date and time types for representing temporal values are DATETIME, DATE, TIMESTAMP, TIME, and YEAR. Each temporal type has a range of legal values, as well as a “zero” value that is used when you specify an illegal value that MySQL cannot represent –DATETIME '0000-00-00 00:00:00' –DATE '0000-00-00' –TIMESTAMP (4.1 and up) '0000-00-00 00:00:00' –TIMESTAMP (before 4.1) 00000000000000 –TIME '00:00:00' –YEAR 0000

42 2011-09-15 SLIDE 42IS 257 – Fall 2011 MySQL Data Types The string types are CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM, and SET Maximum length for CHAR is 255 and for VARCHAR is 65,535 VARCHAR uses 1 or 2 bytes for the length For longer things there is BLOB and TEXT

43 2011-09-15 SLIDE 43IS 257 – Fall 2011 MySQL Data Types A BLOB is a binary large object that can hold a variable amount of data. The four BLOB types are TINYBLOB, BLOB, MEDIUMBLOB, and LONGBLOB. These differ only in the maximum length of the values they can hold The four TEXT types are TINYTEXT, TEXT, MEDIUMTEXT, and LONGTEXT. These correspond to the four BLOB types and have the same maximum lengths and storage requirements TINY=1byte, BLOB and TEXT=2bytes, MEDIUM=3bytes, LONG=4bytes

44 2011-09-15 SLIDE 44IS 257 – Fall 2011 MySQL Data Types BINARY and VARBINARY are like CHAR and VARCHAR but are intended for binary data of 255 bytes or less ENUM is a list of values that are stored as their addresses in the list –For example, a column specified as ENUM('one', 'two', 'three') can have any of the values shown here. The index of each value is also shown: Value = Index NULL = NULL ‘’ = 0 'one’ = 1 ‘two’ = 2 ‘three’ = 3 –An enumeration can have a maximum of 65,535 elements.

45 2011-09-15 SLIDE 45IS 257 – Fall 2011 MySQL Data Types The final string type (for this version) is a SET A SET is a string object that can have zero or more values, each of which must be chosen from a list of allowed values specified when the table is created. SET column values that consist of multiple set members are specified with members separated by commas (‘,’) For example, a column specified as SET('one', 'two') NOT NULL can have any of these values: –'' –'one' –'two' –'one,two‘ A set can have up to 64 member values and is stored as an 8byte number

46 2011-09-15 SLIDE 46IS 257 – Fall 2011 Controlling Data Integrity Default values Range control Null value control Referential integrity (next time) Handling missing data

47 2011-09-15 SLIDE 47IS 257 – Fall 2011 Designing Physical Records A physical record is a group of fields stored in adjacent memory locations and retrieved together as a unit Fixed Length and variable fields

48 2011-09-15 SLIDE 48IS 257 – Fall 2011 Designing Physical/Internal Model Overview terminology Access methods

49 2011-09-15 SLIDE 49IS 257 – Fall 2011 Physical Design Internal Model/Physical Model Operating System Access Methods Data Base User request DBMS Internal Model Access Methods External Model Interface 1 Interface 3 Interface 2

50 2011-09-15 SLIDE 50IS 257 – Fall 2011 Physical Design Interface 1: User request to the DBMS. The user presents a query, the DBMS determines which physical DBs are needed to resolve the query Interface 2: The DBMS uses an internal model access method to access the data stored in a logical database. Interface 3: The internal model access methods and OS access methods access the physical records of the database.

51 2011-09-15 SLIDE 51IS 257 – Fall 2011 Physical File Design A Physical file is a portion of secondary storage (disk space) allocated for the purpose of storing physical records Pointers - a field of data that can be used to locate a related field or record of data Access Methods - An operating system algorithm for storing and locating data in secondary storage Pages - The amount of data read or written in one disk input or output operation

52 2011-09-15 SLIDE 52IS 257 – Fall 2011 Lecture Outline Review –Relational Algebra and Calculus –Introduction to SQL Physical Database Design Access Methods

53 2011-09-15 SLIDE 53IS 257 – Fall 2011 Internal Model Access Methods Many types of access methods: –Physical Sequential –Indexed Sequential –Indexed Random –Inverted –Direct –Hashed Differences in –Access Efficiency –Storage Efficiency

54 2011-09-15 SLIDE 54IS 257 – Fall 2011 Physical Sequential Key values of the physical records are in logical sequence Main use is for “dump” and “restore” Access method may be used for storage as well as retrieval Storage Efficiency is near 100% Access Efficiency is poor (unless fixed size physical records)

55 2011-09-15 SLIDE 55IS 257 – Fall 2011 Indexed Sequential Key values of the physical records are in logical sequence Access method may be used for storage and retrieval Index of key values is maintained with entries for the highest key values per block(s) Access Efficiency depends on the levels of index, storage allocated for index, number of database records, and amount of overflow Storage Efficiency depends on size of index and volatility of database

56 2011-09-15 SLIDE 56IS 257 – Fall 2011 Index Sequential Data File Block 1 Block 2 Block 3 Address Block Number 123…123… Actual Value Dumpling Harty Texaci... Adams Becker Dumpling Getta Harty Mobile Sunoci Texaci

57 2011-09-15 SLIDE 57IS 257 – Fall 2011 Indexed Sequential: Two Levels Address 789…789… Key Value 385 678 805 001 003. 150 705 710. 785 251. 385 455 480. 536 605 610. 678 791. 805 Address 1212 Key Value 150 385 Address 3434 Key Value 536 678 Address 5656 Key Value 785 805

58 2011-09-15 SLIDE 58IS 257 – Fall 2011 Indexed Random Key values of the physical records are not necessarily in logical sequence Index may be stored and accessed with Indexed Sequential Access Method Index has an entry for every data base record. These are in ascending order. The index keys are in logical sequence. Database records are not necessarily in ascending sequence. Access method may be used for storage and retrieval

59 2011-09-15 SLIDE 59IS 257 – Fall 2011 Indexed Random Address Block Number 2132121321 Actual Value Adams Becker Dumpling Getta Harty Becker Harty Adams Getta Dumpling

60 2011-09-15 SLIDE 60IS 257 – Fall 2011 Btree F | | P | | Z | R | | S | | Z |H | | L | | P |B | | D | | F | Devils Aces Boilers Cars Minors Panthers Seminoles Flyers Hawkeyes Hoosiers

61 2011-09-15 SLIDE 61IS 257 – Fall 2011 Inverted Key values of the physical records are not necessarily in logical sequence Access Method is better used for retrieval An index for every field to be inverted may be built Access efficiency depends on number of database records, levels of index, and storage allocated for index

62 2011-09-15 SLIDE 62IS 257 – Fall 2011 Inverted Address Block Number 123…123… Actual Value CH 145 CS 201 CS 623 PH 345 CH 145 101, 103,104 CS 201 102 CS 623 105, 106 Adams Becker Dumpling Getta Harty Mobile Student name Course Number CH145 cs201 ch145 cs623

63 2011-09-15 SLIDE 63IS 257 – Fall 2011 Direct Key values of the physical records are not necessarily in logical sequence There is a one-to-one correspondence between a record key and the physical address of the record May be used for storage and retrieval Access efficiency always 1 Storage efficiency depends on density of keys No duplicate keys permitted

64 2011-09-15 SLIDE 64IS 257 – Fall 2011 Hashing Key values of the physical records are not necessarily in logical sequence Many key values may share the same physical address (block) May be used for storage and retrieval Access efficiency depends on distribution of keys, algorithm for key transformation and space allocated Storage efficiency depends on distibution of keys and algorithm used for key transformation

65 2011-09-15 SLIDE 65IS 257 – Fall 2011 Comparative Access Methods Indexed No wasted space for data but extra space for index Moderately Fast Very fast with multiple indexes OK if dynamic OK if dynamic Easy but requires Maintenance of indexes Factor Storage space Sequential retrieval on primary key Random Retr. Multiple Key Retr. Deleting records Adding records Updating records Sequential No wasted space Very fast Impractical Possible but needs a full scan can create wasted space requires rewriting file usually requires rewriting file Hashed more space needed for addition and deletion of records after initial load Impractical Very fast Not possible very easy


Download ppt "2011-09-15 SLIDE 1IS 257 – Fall 2011 Physical Database Design University of California, Berkeley School of Information I 257: Database Management."

Similar presentations


Ads by Google