Network Model (DBTG MODEL)

MR. P. VIJAY

ASSISTANT PROFESSOR

DEPARTMENT OF COMMERCE WITH CA

KONGUNADU ARTS AND SCIENCE COLLEGE

COIMBATORE – 641 029

Network Model (DBTG MODEL)

Basic Concepts

Data-Structure Diagrams

The DBTG CODASYL Model

DBTG Data-Retrieval Facility

DBTG Update Facility

DBTG Set-Processing Facility

Mapping of Networks to Files

Basic Concepts

Data are represented by collections of records.◦ similar to an entity in the E-R model

◦ Records and their fields are represented as record type

typecustomer = recordtype account = recordcustomer-name: string; account-number: integer;customer-street: string; balance: integer;customer-city: string;end end

Relationships among data are represented by links◦ similar to a restricted (binary) form of an E-R relationship

◦ restrictions on links depend on whether the relationship ismany-many, many-to-one, or one-to-one.

Data-Structure Diagrams

Schema representing the design of a network database.

A data-structure diagram consists of two basic components:◦ Boxes, which correspond to record types.

◦ Lines, which correspond to links.

Specifies the overall logical structure of the database.

Data-Structure Diagrams (Cont.)

For every E-R diagram, there is a corresponding data-structure diagram.

Data-Structure Diagrams (Cont.)

Since a link cannot contain any data value,represent an E-R relationship with attributeswith a new record type and links.

General Relationships

To represent an E-R relationship of degree 3 orhigher, connect the participating record typesthrough a new record type that is linked directly toeach of the original record types.

1.Replace entity sets account, customer, and branch withrecord types account, customer, and branch,respectively.

2.Create a new record type Rlink (referred to as adummy record type).

3.Create the following many-to-one links:◦ CustRlink from Rlink record type to customer record type◦ AcctRlnk from Rlink record type to account record type◦ BrncRlnk from Rlink record type to branch record type

The DBTG CODASYL Model

All links are treated as many-to-one relationships.

To model many-to-many relationships, a record type is defined to represent the relationship and two links are used.

DBTG Sets

The structure consisting of two record types that arelinked together is referred to in the DBTG model as aDBTG set

In each DBTG set, one record type is designated as theowner, and the other is designated as the member, of theset.

Each DBTG set can have any number of set occurrences(actual instances of linked records).

Since many-to-many links are disallowed, each setoccurrence has precisely one owner, and has zero ormore member records.

No member record of a set can participate in morethan one occurrence of the set at any point.

A member record can participate simultaneously inseveral set occurrences of different DBTG sets.

Repeating Groups

Provide a mechanism for a field to have aset of values rather than a single value.

Alternative representation of weakentities from the E-R model

Example: Two sets.◦ customer (customer-name)

◦ customer-address (customer-street, customer-city)

The following diagrams represent thesesets without the repeating-groupconstruct.

Repeating Groups (Cont.)

With the repeating-group construct, the data-structure diagram consists of the single record typecustomer.

DBTG Data Manipulation

The DBTG data manipulation language consists of anumber of commands that are embedded in a host

language.

Run unit — system application program consisting ofa sequence of host language and DBTG commandstatements. Statements access and manipulatedatabase items as well as locally declared variables.

Program work-area (or user work area) — a bufferstorage area the system maintains for eachapplication program

DBTG Variables

Record Templates

Currency pointers◦ Current of record type◦ Current of set type◦ Current of run unit

Status flags◦ DB-status is most frequently used◦ Additional variables: DB-set-name, DB-

record-name, and DB-data-name

Example Schema

Example Program Work Area

Templates for three record types: customer, account,and branch.

Six currency pointers◦ Three pointers for record types: one each tot he most

recently accessed customer, account, and branch record◦ Two pointers for set types: one to the most recently

accessed record in an occurrence of the set depositor,one to the most recently accessed record in anoccurrence of the set account-branch

◦ One run-unit pointer.

Status flags: four variables defined previously Following diagram shows an example program

work area state.

The Find and Get Commands find locates a record in the database and sets the

appropriate currency pointers

get copies of the record to which the current of run-unitpoints from the database to the appropriate program workarea template

Example: Executing a find command to locate the customerrecord belonging to Johnson causes the following changes tooccur in the state of the program work area.◦ The current of the record type customer now points to the

record of Johnson.

◦ The current of set type depositor now points to the set ownedby Johnson

◦ The current of run unit now points to customer record Johnson.

Access of Individual Records

find any <record type> using <record-field>Locates a record of type <record type> whose

<record-field>value is the same as the value of <record-field> in the<record type> template in the program work area.

Once such a record is found, the following currencypointers are set to point to that record:◦ The current of run-unit pointer

◦ The record-type currency pointer for <record type>

◦ For each set in which that record belongs, the appropriateset currency pointer

find duplicate <record type> using <record-field>Locates (according to a system-dependent ordering)the next record that matches the <record-field>

Access of Records Within a Set

Other find commands locate records in the DBTGset that is pointed to by the <set-type> currencypointer.

find first <record type> within <set-type>Locates the first database record of type <record

type>belonging to the current <set-type>.

To locate the other members of a set,k we use

find next <record type> within <set-type>

which finds the next element in the set <set-type>. find owner within <set-type>

Locates the owner of a particular DBTG set

Predicates

For queries in which a field value must bematched with a specified range of values,rather than to only one, we need to:

◦ get the appropriate records into memory

◦ examine each one separately for a match

◦ determine whether each is the; target of ourfind statement

Example DBTG Query

Print the total number of accounts in the Perryridgebranch with a balance greater than $10,000.

count := 0;branch.branch-name := “Perryridge”;find any branch using branch-name;find first account within account-branch;while DB-status = 0 do

beginget accountif account.balance > 10000 then count := count +

1;find next account within account-branch;

endprint (count);

DBTG Update Facility

DBTG mechanisms are available to update information in the database.

To create a new record of type <record type>◦ insert the appropriate values in the corresponding

<record type> template

◦ add this new record to the database by executing

store <record type>

Can create and add new records only one at a time

DBTG Update Facility (Cont.)

To modify an existing record of type <record type>◦ find that record in the database

◦ get that record into memory

◦ change the desired fields in the template of <record type>

◦ reflect the changes to the record to which the currency point of <record type> points by executing

modify <record type>

DBTG Update Facility (Cont.) To delete an existing record of type <record type>

◦ make the currency pointer of that type point to the record in the database to be deleted

◦ delete that record by executing

erase <record type>

Delete an entire set occurrence by finding the owner of the set and executing

erase all <record type>

◦ Deletes the owner of the set, as well as all the set’s members.◦ If a member of the set is an owner of another set, the members

of that second set also will be deleted.

◦ erase all is recursive.

Parent—Child E-R Diagram

NORMALIZATION

MR. P. VIJAY

ASSISTANT PROFESSOR

DEPARTMENT OF COMMERCE WITH CA

KONGUNADU ARTS AND SCIENCE COLLEGE

COIMBATORE – 641 029

Normalization

IS 257 – Fall 2008

Normalization theory is based on the observation thatrelations with certain properties are more effective ininserting, updating and deleting data than other sets ofrelations containing the same data

Normalization is a multi-step process beginning withan “unnormalized”relation

Normal Forms

IS 257 – Fall 2008

First Normal Form (1NF)

Second Normal Form (2NF)

Third Normal Form (3NF)

Boyce-Codd Normal Form (BCNF)

Fourth Normal Form (4NF)

Fifth Normal Form (5NF)

Normalization

IS 257 – Fall 2008

Boyce-

Codd and

Higher

Functional

dependency

of nonkey

attributes on

the primary

key - Atomic

values only

Full

Functional

dependency

of nonkey

attributes on

the primary

key

No transitive

dependency

between

nonkey

attributes

All

determinants

are candidate

keys - Single

multivalued

dependency

Functional Dependencies Functional dependencies (FDs) are used to specify formal

measures of the "goodness" of relational designs FDs and keys are used to define normal forms for relations FDs are constraints that are derived from the meaning

and interrelationships of the data attributes

Introduction to Normalization Normalization: Process of decomposing unsatisfactory

"bad" relations by breaking up their attributes intosmaller relations

Normal form: Condition using keys and FDs of arelation to certify whether a relation schema is in aparticular normal form 2NF, 3NF, BCNF based on keys and FDs of a relation schema 4NF based on keys, multi-valued dependencies

Unnormalized Relations

IS 257 – Fall 2008

First step in normalization is to convert the data into a two-dimensional table

In unnormalized relations data can repeat within a column

First Normal Form

IS 257 – Fall 2008

To move to First Normal Form a relation must contain onlyatomic values at each row and column. No repeating groups

A column or set of columns is called a Candidate Key when itsvalues can uniquely identify the row in the relation.

First Normal Form

IS 257 – Fall 2008

Patient # Surgeon # Surgery DatePatient NamePatient Addr Surgeon Name Surgery Drug adminSide Effects

1111 145 01-Jan-95 John White

15 New St.

New York,

NY Beth Little

Gallstone

s removal Penicillin rash

1111 311 12-Jun-95 John White

15 New St.

New York,

NY

Michael

Diamond

Kidney

stones

removal none none

1234 243 05-Apr-94 Mary Jones

10 Main St.

Rye, NY Charles Field

Eye

Cataract

removal

Tetracyclin

e Fever

1234 467 10-May-95 Mary Jones

10 Main St.

Rye, NY Patricia Gold

Thrombos

is removal none none

2345 189 08-Jan-96

Charles

Brown

Dogwood

Lane

Harrison,

NY David Rosen

Open

Heart

Surgery

Cephalosp

orin none

4876 145 05-Nov-95 Hal Kane

55 Boston

Post Road,

Chester,

CN Beth Little

Cholecyst

ectomy Demicillin none

5123 145 10-May-95 Paul Kosher

Blind Brook

Mamaronec

k, NY Beth Little

Gallstone

s

Removal none none

6845 243 05-Apr-94 Ann Hood

Hilton Road

Larchmont,

NY Charles Field

Eye

Cornea

Replacem

ent

Tetracyclin

e Fever

6845 243 15-Dec-84 Ann Hood

Hilton Road

Larchmont,

NY Charles Field

Eye

cataract

removal none none

Second Normal Form

IS 257 – Fall 2008

A relation is said to be in Second Normal Form when everynon-key attribute is fully functionally dependent on theprimary key. That is, every non-key attribute needs the full primary key for

unique identification

Second Normal Form

IS 257 – Fall 2008

Patient # Surgeon # Surgery Date Surgery Drug Admin Side Effects

1111 145 01-Jan-95

Gallstones

removal Penicillin rash

1111 311 12-Jun-95

Kidney

stones

removal none none

1234 243 05-Apr-94

Eye Cataract

removal Tetracycline Fever

1234 467 10-May-95

Thrombosis

removal none none

2345 189 08-Jan-96

Open Heart

Surgery

Cephalospori

n none

4876 145 05-Nov-95

Cholecystect

omy Demicillin none

5123 145 10-May-95

Gallstones

Removal none none

6845 243 15-Dec-84

Eye cataract

removal none none

6845 243 05-Apr-94

Eye Cornea

Replacement Tetracycline Fever

Third Normal Form

IS 257 – Fall 2008

A relation is said to be in Third Normal Form if there isno transitive functional dependency between non-keyattributes When one non-key attribute can be determined with one or

more non-key attributes there is said to be a transitivefunctional dependency.

The side effect column in the Surgery table isdetermined by the drug administered Side effect is transitively functionally dependent on drug so

Surgery is not 3NF

Third Normal Form

IS 257 – Fall 2008

Patient # Surgeon # Surgery Date Surgery Drug Admin

1111 145 01-Jan-95 Gallstones removal Penicillin

1111 311 12-Jun-95

Kidney stones

removal none

1234 243 05-Apr-94 Eye Cataract removal Tetracycline

1234 467 10-May-95 Thrombosis removal none

2345 189 08-Jan-96 Open Heart Surgery Cephalosporin

4876 145 05-Nov-95 Cholecystectomy Demicillin

5123 145 10-May-95 Gallstones Removal none

6845 243 15-Dec-84 Eye cataract removal none

6845 243 05-Apr-94

Eye Cornea

Replacement Tetracycline

Boyce-Codd Normal Form

IS 257 – Fall 2008

Most 3NF relations are also BCNF relations.

A 3NF relation is NOT in BCNF if: Candidate keys in the relation are composite keys (they are not

single attributes)

There is more than one candidate key in the relation, and

The keys are not disjoint, that is, some attributes in the keys arecommon

Fourth Normal Form

IS 257 – Fall 2008

Any relation is in Fourth Normal Form if it is BCNF and anymultivalued dependencies are trivial

Eliminate non-trivial multivalued dependencies byprojecting into simpler tables

Fifth Normal Form

IS 257 – Fall 2008

A relation is in 5NF if every join dependency in the relationis implied by the keys of the relation

Implies that relations that have been decomposed in previous normalforms can be recombined via natural joins to recreate the originalrelation.

8/19/2019