Mind Map Database

6
INTERNAL MODEL Maps conceptual model to DBMS Represents database ‘seen’ by DBMS Require match conceptual model characteriscs and constraints to selected implementaon model INTERNAL SCHEMA Depicts representaon of internal model, using database constructs DATA DICTIONARY Detailed accounng of all tables within user-created database Contains all aribute names and characteriscs for each table Contains metadata—data about data PARTIAL DEPENDANCE Dependency based on only part of composite primary key (1NF) ATTRIBUTES Composite aribute: notcompositekey.Aribute furthersubdividedtoyieldaddionalaributes Simple aribute: aributecannotbesubdivided Single-valued aribute: haveonlyonevalue Mulvalued aribute: havemanyvalues Derived aribute: aributevaluecalculated (derived)fromotheraributes DATABASE TABLE NORMALIZATION First Normal Form (1NF) = Table format, no repeang groups and PK defined Second Normal Form (2NF) = Table 1NF, no paral dependencies (no aribute dependent on poron of primary key) Third Normal Form (3NF) = Table 2NF, no transive dependencies Boyce-Codd Normal Form (BCNF) = Table 3NF, every determinant in table candidate key Fourth Normal Form (4NF) = Table 3NF, no independent mulvalued dependencies RELATIONAL SCHEMA Textual representaon of database table, each table described by name, list aributes in parenthesis LECTURER (EMP_NUM, LECTURER_OFFICE, LECTURER_EXTENSION, LECTURER_HIGH)DEGREE)

description

Database 1

Transcript of Mind Map Database

Page 1: Mind Map Database

INTERNAL MODEL

• Maps conceptual model to DBMS

• Represents database ‘seen’ by DBMS

• Require match conceptual model characteris�cs

and constraints to selected implementa�on

model

INTERNAL SCHEMA

• Depicts representa�on of internal model, using

database constructs

DATA DICTIONARY

• Detailed accoun�ng of all tables within user-created database

• Contains all a"ribute names and characteris�cs for each table

• Contains metadata—data about data

PARTIAL DEPENDANCE

• Dependency based on only part of composite primary key (1NF)

ATTRIBUTES

• Composite a�ribute: not composite key. A�ribute

further subdivided to yield addi�onal a�ributes

• Simple a�ribute: a�ribute cannot be subdivided

• Single-valued a�ribute: have only one value

• Mul%valued a�ribute: have many values

• Derived a�ribute: a�ribute value calculated

(derived) from other a�ributes

DATABASE TABLE NORMALIZATION

• First Normal Form (1NF) = Table format, no repea�ng groups and PK defined

• Second Normal Form (2NF) = Table 1NF, no par�al dependencies (no a"ribute dependent on por�on of primary

key)

• Third Normal Form (3NF) = Table 2NF, no transi�ve dependencies

• Boyce-Codd Normal Form (BCNF) = Table 3NF, every determinant in table candidate key

• Fourth Normal Form (4NF) = Table 3NF, no independent mul�valued dependencies

RELATIONAL SCHEMA

• Textual representa�on of database table, each table described by name, list

a"ributes in parenthesis

LECTURER (EMP_NUM, LECTURER_OFFICE, LECTURER_EXTENSION,

LECTURER_HIGH)DEGREE)

Page 2: Mind Map Database

KEYS

• Primary Key (PK) = a"ribute (or combina�on) uniquely iden�fies row (not null)

• Composite key = composed more that one a"ribute

• Superkey = uniquely iden�fy each row, func�onally determines rows a"ributes

• Candidate key = Superkey without redundancies (not contain subset a"ributes, itself superkey)

• Secondary key = a"ribute (or combina�on a"ributes) used strictly for data retreival

• Foreign key = a"ribute (or combina�on a"ributes) in one table whose value match primary key in another table,

or be null

• Surrogate key = Ar�ficial PK simplifying assignment PK to table, numeric, automa�c generated, hidden from user

FUNCTIONAL DEPENDENCY

• A"ribute B func�onally dependent on A if A

determines B

• A"ribute B func�onally dependent in A if each

value in column A determines one and one one

value in column B

DESIGN CASES

• Implemen%ng 1:1 Rela%onship

⇒ Foreign key work with primary key

⇒ Primary key ‘one’ side (parent) on ‘many’ sides (dependent en�ty) of foreign key

• Maintaining history over %me and must keep history

⇒ Create 1:* rela�onship

• FAN Traps

⇒ Rela�onship improperly iden�fied, inconsistent with real world

⇒ One en�ty in two 1:* rela�onships to other en��es, produsing associa�on among other en��es

not expressed in model

• Redundant Rela%onship

⇒ Mul�ple rela�onship paths between related en��es

⇒ Remain consistent across model

PRIMARY KEY CHARACTERISTICS

• Unique value

• Cannot contain null value

• No change over �me (stable), permanent,

unchangeable

• Minimal—fewest a"ributes

• Factless—no hidden informa�on, cannot be

composed

• Numeric

• ERM = En�ty Rela�onship Model

• ERD = En�ty Rela�onship diagram

• UML = Unified Modelling Language

PARTIAL AND TOTAL COMPLETENESS

• Par%al Completeness = every supertype occurrenece is member of subtype, may be supertype occurrences not

members of subtype

• Total Completeness = every supertype occurrence must be member of at leat one subtype

Page 3: Mind Map Database

ERM COMPONENTS in CRAW’s FOOT MODEL

• En%ty = person, place, thing store mul�ple instances

|——————|

| DESK |

|——————|

| * desk_id |

| desk_colour |`

| desk_size |

|——————|

|——————|

• Cardinality = indicate rules around rela�onship

->0————— zero or more

->|————— one or more

—||———— one and only one

—|0———— zero or one

• Weak en%ty = existence-dependent, primary key par�ally or totally derived from parent

en�ty.

Condi�ons met before en�ty classified as weak en�ty:

1) En�ty existence-dependent on parent en�ty

2) En�ty inherit part of primary key from parent

|——————–——-| |——————–——– |

| EMPLOYEE | | DEPARTMENT |

|——————–——-| |——————–——– |

| EMP_NUM {PK} | has > | DEP_NUM {PK} |

| EMP_NAME |—————--| EMP_NUM {PK}{FK} |

| EMP_DOB |1..1 0..* | DEP_NAM |

|——————–——-| | DEP_DOB |

|——————–——-| |——————–———|

|——————–———|

• Strong en%ty rela%onship = PK of related en�ty contains PK component of parent en�ty

|——————–——-| |——————–——– |

| COURSE | | CLASS |

|——————–——-| |——————–——– |

| CRS_CODE {PK} | generates | CRS_CODE {PK} {FK} |

| DEPT_CODE |—————--| CLASS_SECTION{PK} |

| SRS_DESCRIPTION |1..1 0..* | CLASS_TIME |

| CRS_CREDITS | | ROOM_CODE |

|——————–——-| |——————–———|

|——————–——-| |——————–———|

COURSE (SRS_CODE, DEPT_CODE, CRS_DESCRIPTION, CRS_CREDITS)

CLASS (CRS_CODE, CLASS_SECTION, CLASS_TIME, ROOM_CODE)

CARDINALITY RELATIONSHIP

• 1:1 STUDENT -||—-fills —-||- SEAT

• 1:M INSTRUCTOR -||--teaches--|<- COURSE

• M:M STUDENT ->-|—takes—|<- COURSE

• 0:N ->-0————-<-

Page 4: Mind Map Database

Create Database Schema

CREATE SCHEMA AUTHORIZATION {creator};

CREATE SCHEMA AUTHORIZATION JONES;

Create Table Structure

CREATE TABLE tablename (

column1 datatype [constarint] [,

Column2 datatype [constraint] [,

PRIMARY KEY (column1 [, column2]) ] [.

FOREIGN KEY (column1 [, column2])

REFERENCES tablename ] [,

CONSTRAINT constraint ] );

CREATE TABLE VENDOR (

V_CODE INTEGER NOT NULL UNIQUE,

V_NAME VARCHAR(35) NOT NULL,

V_CONTACT VARCHAR(15) NOT NULL,

PRIMARY KEY (V_CODE) );

Adding Table Rows

INSERT INTO tablename VALUES (value1, value2, …, valueN );

INSERT INTO VENDOR VALUES (21225, ‘Bryson, Inc’, ‘Smithson’ );

Saving Table Changes

COMMIT;

Restore Table Contents

ROLLBACK;

If not yet used, COMMIT to restore changes

Lis%ng Table Rows

SELECT Columnlist FROM tablename

* (asterisk) as wildchard list all a"ributes

SELECT * FROM PRODUCT;

SELECT P_CODE, P_DESCRIPTION, P_PRICE FROM PRODUCT;

SELECT P_DESCRIPTION, P_INDATE, P_PRICE FROM PRODUCT WHERE V_CODE = 21344;

SELECT P_DESCRIPTION, P_QOH,_PMIN FROM PRODUCT WHERE P_PRICE <= 10;

SELECT P_DESCRIPTION, P_INDATE, P_PRICE FROM PRODUCT

WHERE V_CODE = 21344 OR V_CODE = 24288;

SELECT * FROM PRODUCT WHERE NOT (V_CODE = 21344);

SELECT * FROM PRODUCT WHERE P_PRICE BETWEEN 50.00 AND 100.00;

SELECT P_CODE, P_DESCRIPTION, V_CODE FROM PRODUCT WHERE V_CODE IS NULL;

SELECT V_NAME, V_CONTACT, V+PHONE FROM VENDOR WHERE V_CONTACT LIKE ‘Smith%’;

% any and all following

_ one character

DELETING Table Rows

DELETE FROM tablename [WHERE condi�onlist];

DELETE FROM PRODUCT WHERE P_CODE = ‘BRT-3’;

DELETE FROM PRODUCT WHERE P_MIN = 5;

Deleing all rows:

DELETE FROM PRODUCT;

Upda%ng Table Rows (modify data)

UPDATE tablename SET columnname = expression

[, columnname—expression]

[ WHERE condi�on];

UPDATE PRODUCT SET P_INDATE = ‘18-JAN’

WHERE P_CODE = ‘13-Q.P2’;

Page 5: Mind Map Database

Logical Operators: AND, OR, NOT

SELECT P_DESCRIPT, P_INDATE, P_PRICE, V_CODE FROM PRODUCT

WHERE V_CODE = 21344 OR V_CODE = 24288;

SELECT P_DESCRIPT, P_INDATE, P_PRICE, V_CODE FROM PRODUCT

WHERE P_PRICE < 50 and P_INDATE > ‘15-JAN’;

SELECT P_DESCRIPT, P_INDATE, P_PRICE, V_CODE FROM PRODUCT

WHERE (P_PRICE < 50 AND P_INDATE > ‘15-JAN’)

OR V_CODE = 24288;

SELECT * FROM PRODUCT

WHERE NOT (V_CODE = 21344);

Special Operators

Between:

SELECT * FROM PRODUCT

WHERE P_PRICE BETWEEN 50.00 and 100.00;

Is Null:

SELECT P_CODE, P_DESCRIPT, V_CODE FROM PRODUCT

WHERE V_CODE IS NULL;

Like (%, _ ):

SELECT V_NAME, V_CONTACT, V_AREACODE, V+PHONE FROM VENDOR

WHERE V_CONTACT LIKE ‘Smith%’;

In:

SELECT * FROM PRODUCT

WHERE V_CODE IN (‘21344’, ‘24288’); //same as OR

Exists:

SELECT * FROM VENDOR

WHERE EXISTS (SELECT * FROM PRODUCT WHERE P_QOH < P_MIN * 2 ) ;

Changing Column Characteris%cs

Change column Data Type:

ALTER TABLE PTODUCT MODIFY (V_CODE CHAR (5) );

Changing Column Data Characteris%c:

ALTER TABLE PRODUCT MODIFY (P_PRICE DECIMAN (2,2) );

Adding Column:

ALTER TABLE PRODUCT ADD (P_SALECODE CHAR (1) );

Dropping Column:

ALTER TABLE VENDOR DROP COLUMN V_ORDER;

Copying Parts of Table

INSERT INTO PART (PART_CODE, PART_DESCRIP, PART_PRICE, VODE)

SELECT P_CODE, P_DESCRIPT, P_PRICE, V_CODE FROM PRODUCT;

Ordering Lis%ng

SELECT P_CODE, P_DESCRIPT, P_INDATE, P_PRICE FROM PRODUCT ORDER BY P_PRICE;

Page 6: Mind Map Database