rdbms Basic Notes

7/29/2019 rdbms Basic Notes

1/33

KSR COLLEGE OF ARTS AND SCI ENCE

DEPARTMENT OF COMPUTER APPLI CATI ONS ( UG)

UNI T - I

NOTES

ON

RELATI ONAL

DATABASE MANAGEMENT

SYSTEM

(RDBMS)

(09BCAM402)


2/33

Contents

Introduction..................................................................................................................... 1

1.

Database

System

Applications

................................................................................

1

2.PurposeofDatabaseSystems................................................................................... 2

3.ViewofData................................................................................................................ 3

3.1DataAbstraction.................................................................................................... 3

3.2InstancesandSchemas.......................................................................................... 4

4.DataModels................................................................................................................. 4

5.DataBaseLanguages.................................................................................................. 5

5.1DataManipulationLanguage(DML)................................................................. 5

5.2DataDefinitionLanguage(DDL)........................................................................ 5

6.DatabaseArchitecture................................................................................................ 6

7.DatabaseUsersandAdministrators........................................................................ 8

7.1DatabaseUsersandUserInterfaces.................................................................... 8

7.2DatabaseAdministrator........................................................................................ 8

8.Structure

of

Relational

Database

.............................................................................

9

8.1BasicStructure........................................................................................................ 98.2DatabaseSchema.................................................................................................. 10

8.3Keys........................................................................................................................ 138.4QueryLanguages................................................................................................. 14

9.TheEntityRelationshipModel.............................................................................. 14

9.1Entity

Sets

..............................................................................................................

15

9.2RelationshipSets.................................................................................................. 15

9.3Attributes............................................................................................................... 16

10.Constraints............................................................................................................... 18

10.1MappingCardinalities...................................................................................... 18


3/33

10.2Keys...................................................................................................................... 20

10.2.1EntitySets..................................................................................................... 20

10.2.2RelationshipSets......................................................................................... 20

11.TheEntityRelationshipDiagram........................................................................ 20

12.ExtendedERFeatures............................................................................................ 25

12.1Specialization(Topdownapproach).............................................................. 25

12.2Generalization(Bottomupapproach)............................................................ 25

13.TheNetworkModel............................................................................................... 26

14.TheHierarchicalModel......................................................................................... 28


4/33

I n t r o d u c t i o n

1. Adatabasemanagement system (DBMS),or simplyadatabase system (DBS),consistsof

o Acollectionofinterrelatedandpersistentdata(usuallyreferredtoasthedatabase(DB)).

o Aset

of

application

programs

used

to

access,

update

and

manage

that

data(whichformthedatamanagementsystem(MS)).

2. ThegoalofaDBMS is toprovideanenvironment that isbothconvenientandefficienttousein

o Retrievinginformationfromthedatabase.o Storinginformationintothedatabase.

3. Databases are usually designed to manage large bodies of information. Thisinvolves

o Definitionofstructuresforinformationstorage(datamodeling).o Provision ofmechanisms for themanipulation of information (file and

systemsstructure,queryprocessing).

o Providing for the safetyof information in thedatabase (crash recoveryandsecurity).

o Concurrencycontrolifthesystemissharedbyusers.1 . Da tabase-Sys tem App l i cat ion s

o Banking:forcustomerinformation,account,loans,andbankingtransactions.o Airlines:forreservationsandscheduleinformation.o Universities:forstudentinformation,courseregistrations,andgrades.o Credit card transactions: for purchases on credit cards and generation of

monthlystatements.

o Telecommunication:forkeepingrecordsofcallsmade,generatingmonthlybills,maintainingbalancesonprepaidcallingcards,andstoringinformationaboutthe

communicationnetworks.o Finance:forstoringinformationaboutholdings,sales,andpurchasesoffinancial

instrumentssuchasstocksandbonds.o Sales:forcustomer,product,andpurchaseinformationo Onlineretailers:onlineordertracking,generationofrecommendationlists,and

maintenanceofonlineproductevaluations.o Manufacturing:formanagementofthesupplychainandfortrackingproduction

of

items

in

factories,

inventories

of

items

in

warehouses

and

stores,

and

orders

foritems.o Human resource: for information about employees, salaries, Payroll taxes,

benefits,andforgenerationofpaychecks.


5/33

2. Pur pose o f Dat abase Syst em s

1. Toseewhydatabasemanagementsystemsarenecessary,let'slookatatypical``fileprocessingsystem''supportedbyaconventionaloperatingsystem.

Theapplicationisasavingsbank:

o Savingsaccountandcustomerrecordsarekeptinpermanentsystemfiles.o Applicationprogramsarewrittentomanipulatefilestoperformthe

followingtasks:

Debitorcreditanaccount. Addanewaccount. Findanaccountbalance. Generatemonthlystatements.

2. Developmentofthesystemproceedsasfollows:o Newapplicationprogramsmustbewrittenastheneedarises.o Newpermanentfilesarecreatedasrequired.o But

over

along

period

of

time

files

may

be

in

different

formats,

and

o Applicationprogramsmaybeindifferentlanguages.3. Sowecanseethereareproblemswiththestraightfileprocessingapproach:

o Dataredundancyandinconsistency Sameinformationmaybeduplicatedinseveralplaces. Allcopiesmaynotbeupdatedproperly.

o Difficultyinaccessingdata Needtowriteanewprogramtocarryouteachnewtask E.g.findallcustomerswiththesamepostalcode. Couldgeneratethisdatamanually,butalongjob...

o Dataisolation

Dataindifferentfilesanddifferentformats. Difficulttowritenewapplicationprograms.

o Integrityproblems Integrityconstraints (e.g.accountbalance>0)becomeburied

inprogramcoderatherthanbeingstatedexplicitly

Hardtoaddnewconstraintsorchangeexistingoneso Atomicityproblems

Failuresmayleavedatabaseinaninconsistentstatewithpartialupdatescarriedout

Example:Transferoffundsfromoneaccounttoanothershouldeithercompleteornothappenatall

o Concurrentaccessanomalies Concurrentaccessedneededforperformance Uncontrolledconcurrentaccessescanleadtoinconsistencies Example:Twopeoplereadingabalanceandupdatingitatthe

sametime.

o Securityproblems


6/33

Everyuserofthesystemshouldbeabletoaccessonlythedatatheyarepermittedtosee.

E.g.payrollpeopleonlyhandleemployeerecords,andcannotseecustomeraccounts;tellersonlyaccessaccountdataandcannot

seepayrolldata.

Difficulttoenforcethiswithapplicationprograms.Theseproblemsandothersledtothedevelopmentofdatabasemanagementsystems.

3 . View o f Da ta

Themajorpurposeofadatabasesystemistoprovideuserswithanabstractviewofthe

system. The system hides certain details of how data is stored and created and

maintained.Complexityshouldbehiddenfromdatabaseusers.

3 .1 Da ta Abs t rac t ion

Thereareseverallevelsofabstraction:

1. PhysicalLevel: Howarecordisstored.E.g.index,Btree,hashing. Lowestlevelofabstraction. Complexlowlevelstructuresdescribedindetail.

2. LogicalLevel: Nexthighestlevelofabstraction. Describeswhatdataarestored. Describestherelationshipsamongdata. Databaseadministratorlevel.

3. ViewLevel: Highest

level.

Describespartofthedatabaseforaparticulargroupofusers. Canbemanydifferentviewsofadatabase. E.g.tellersinabankgetaviewofcustomeraccounts,butnotof

payrolldata.

Figure1.1:Thethreelevelsofdataabstraction


7/33

3 .2 I ns tances and Schemas

Similartotypesandvariablesinprogramminglanguages Schemathelogicalstructureofthedatabase

o Example:Thedatabaseconsistsofinformationaboutasetofcustomersandaccountsandtherelationshipbetweenthem)

o Analogoustotypeinformationofavariableinaprogramo Physicalschema:databasedesignatthephysicallevelo Logicalschema:databasedesignatthelogicallevel

Instancetheactualcontentofthedatabaseataparticularpointintimeo Analogoustothevalueofavariable

PhysicalDataIndependencetheabilitytomodifythephysicalschemawithoutchangingthelogicalschema

o Applicationsdependonthelogicalschemao Ingeneral,theinterfacesbetweenthevariouslevelsandcomponents

shouldbewelldefinedsothatchangesinsomepartsdonotseriously

influenceothers.

4. Data Models

Datamodelsareacollectionofconceptualtoolsfordescribingdata,data

relationships,datasemanticsandconsistencyconstraints.Therearefour

differentgroups:

1. RelationalModel2. TheEntityRelationshipModel3. ObjectBasedLogicalModel4. SemistructuredDataModel

1. RelationalModel Acollectionoftablestorepresentbothdataandtherelationshipamongthose

data.

Thedatabaseisstructuredinfixedformatrecordsofseveraltypes.

Mostwidelyuseddatamodel

2. TheEntityRelationshipModel Anentityisathingorobjectintherealworldthatisdistinguishablefrom

otherobjects.

Thecollectionofbasicobjectscalledentities,andofrelationshipsamongthese

objects.3. ObjectBasedDataModel

Combinesthefeaturesoftheobjectorienteddatamodelandrelationaldata

model.

ExtendingtheERmodelwithnotionsofencapsulation,methods(functions),

andobjectidentity.


8/33

4. SemistructuredDataModel Individualdataitemsofthesametypemayhavedifferentsetofattributes.

TheExtensibleMarkupLanguage(XML)isanexampleforsemistructureddata.

5. Data Base Langu ages

Adatabase

system

provides

two

different

types

of

languages:

adata

definition

languagetospecifythedatabaseschemaandadatamanipulationlanguagetoexpress

databasequeriesandupdates.

5 .1 Da ta Man ipu la t ion Language ( DML)

1. DataManipulationis:o Retrievalofinformationstoredinthedatabaseo Insertionofnewinformationintothedatabaseo Deletionofinformationfromthedatabaseo Modificationofinformationstoredinthedatabase

2. ADMLisalanguagewhichenablesuserstoaccessandmanipulatedata.Thegoalistoprovideefficienthumaninteractionwiththesystem.

3. TherearetwotypesofDML:o Procedural:theuserspecifieswhatdataisneededandhowtogetito Declarative:theuseronlyspecifieswhatdataisneededwithout

specifyinghowtogetthosedata.

Easierforuser Maynotgeneratecodeasefficientasthatproducedby

procedurallanguages

4. AquerylanguageisaportionofaDMLinvolvinginformationretrievalonly.ThetermsDMLandquerylanguageareoftenusedsynonymously.

5 .2 Da ta Def in i t i on Language ( DDL) 1. UsedtospecifyadatabaseschemeasasetofdefinitionsexpressedinaDDL2. DDLstatementsarecompiled,resultinginasetoftablesstoredinaspecialfile

calledadatadictionaryordatadirectory.

3. Thedatadirectorycontainsmetadata(dataaboutdata)4. Thestoragestructureandaccessmethodsusedbythedatabasesystemare

specifiedby

aset

of

definitions

in

aspecial

type

of

DDL

called

adata

storage

and

definitionlanguage

5. basicidea:hideimplementationdetailsofthedatabaseschemesfromtheusers DomainConstratins

Avalueisassociatedwitheveryattribute.

Aparticularattributeactsasaconstraintonthevaluesthatitcantake.


9/33

ReferentialIntegrity Avaluethatappearsinonerelationforanattributealsoappearsforacertain

setofattributesinanotherrelation.

Databasemodificationcancauseviolationsofreferentialintegrity.

Assertions Anassertionisanyconditionthatthedatabasemustalwayssatisfy.

If

the

assertion

is

valid,

then

the

database

modification

is

allowed

in

future.

Authorization Thetypeofaccessarepermittedonvariousdatavaluestousers.

Ex:Read/insert/update/deleteauthorization

6 . Da tabase Arch i tec tu r e

1. Database systems are partitioned intomodules for different functions. Somefunctions(e.g.filesystems)maybeprovidedbytheoperatingsystem.

2. Componentsinclude:o Filemanagermanagesallocationofdiskspaceanddatastructuresused

torepresentinformationondisk.

o Databasemanager:Theinterfacebetweenlowleveldataandapplicationprogramsandqueries.

o Queryprocessortranslatesstatementsinaquerylanguageintolowlevelinstructions the databasemanager understands. (May also attempt to

findanequivalentbutmoreefficientform.)

o DMLprecompilerconvertsDMLstatementsembedded inanapplicationprogram tonormalprocedurecalls inahost language.Theprecompiler

interactswiththequeryprocessor.

o DDL compiler converts DDL statements to a set of tables containingmetadata

stored

in

adata

dictionary.

In addition, several data structures are required for physical system

implementation:

o Datafiles:storethedatabaseitself.o Datadictionary:stores informationaboutthestructureofthedatabase.

Itisusedheavily.Greatemphasisshouldbeplacedondevelopingagood

designandefficientimplementationofthedictionary.

o Indices:providefastaccesstodataitemsholdingparticularvalues.


10/33

Fig1.2:Systemstructure

Fig1.3:Twotierandthreetierarchitectures


11/33

7 . Database Users and Adm in is t ra t o rs

7 .1 Da tabase Users and User I n t e r faces

1. Thedatabaseusersfallintoseveralcategories:o Application programmers are computer professionals interacting with

thesystem

through

DML

calls

embedded

in

aprogram

written

in

ahost

language(e.g.C,PL/1,Pascal).

Theseprogramsarecalledapplicationprograms. TheDMLprecompiler convertsDML calls (prefacedbya special

character like $, #, etc.) to normal procedure calls in a host

language.

Thehostlanguagecompilerthengeneratestheobjectcode. Some special types of programming languages combine Pascal

like control structures with control structures for the

manipulationofadatabase.

Theseare

sometimes

called

fourth

generation

languages.

Theyoften include features to help generate forms and displaydata.

o Sophisticatedusersinteractwiththesystemwithoutwritingprograms. They form requests by writing queries in a database query

language.

These are submitted to a query processor that breaks a DMLstatement down into instructions for the database manager

module.

o Specialized users are sophisticated users writing special databaseapplication programs. These may be CADD systems, knowledgebased

andexpertsystems,complexdatasystems(audio/video),etc.o Naiveusersareunsophisticateduserswho interactwith the systemby

usingpermanentapplicationprograms(e.g.automatedtellermachine).

7 .2 Database Adm in is t ra t o r

1. The database administrator is a person having central control over data andprogramsaccessingthatdata.Dutiesofthedatabaseadministratorinclude:

o Scheme definition: DBA Creates the original database schema byexecutingasetofdatadefinitionstatementsintheDDL.

o Storagestructure

and

access

method

definition:

writing

aset

of

definitions translated by the data storage and definition language

compiler.

o Scheme and physical organization modification: The DBA carries outchanges to the schema and physical organization to improve

performance.


12/33

o Granting of authorization for data access: granting different types ofauthorizationfordataaccesstovarioususers

o Integrityconstraintspecification:generatingintegrityconstraints.Theseareconsultedbythedatabasemanagermodulewheneverupdatesoccur.

o Routinemaintenance:1.PeriodicallybackinguptheDB.

2.Ensuring

free

disk

space.

3.MonitoringJobsrunningontheDB.

8 . St r uc tu re o f Re lat iona l Da tabase

1. Arelationaldatabaseconsistsofacollectionoftables,eachhavingauniquename.

Arowinatablerepresentsarelationshipamongasetofvalues.

Thusatablerepresentsacollectionofrelationships.

2. Thereisadirectcorrespondencebetweentheconceptofatableandthemathematical

concept

of

arelation.

A

substantial

theory

has

been

developed

for

relationaldatabases.

8 .1 Basic St r uc tu r e

1. Theaccounttablehasthreecolumnheaders:account_number,brance_name,andbalance.Theseareheaders,theheadersareattributes.Foreachattribute,

thereisasetofpermittedvalues,calledthedomainofthatattribute.

LetD1denotethesetofallaccountnumbers,D2thesetofallbranchnames,D3

theset

of

all

balances.

Any

row

of

account

must

consist

of

a3tuple

(v1,v2,v3),

wherev1isanaccountnumber.

Ingeneral,accountcontainsasubsetofthesetofallpossiblerows.

Thatis,accountisasubsetof


13/33

Example:accountrelationwithunorderedtuples

2. MathematiciansdefinearelationtobeasubsetofaCartesianproductofalistofdomains.Youcanseethecorrespondencewithourtables.

Wewill

use

the

terms

relation

and

tuple

in

place

of

table

and

row

from

now

on.

3. Somemoreformalities:o letthetuplevariable refertoatupleoftherelation .o Wesay todenotethatthetuple isinrelation .o Then [branch_name] = [1] = the value of on the branch_name

attribute.

o So [branch_name]= [1]=``Downtown'',o and

[customer_name]

=[3]

=``Johnson''.

4. We'llalsorequirethatthedomainsofallattributesbeindivisibleunits.o Adomainisatomicifitselementsareindivisibleunits.o Forexample,thesetofintegersisanatomicdomain.o Thesetofallsetsofintegersisnot.o Why?Integersdonothavesubparts,butsetsdo theintegerscomprising

them.

o Wecould

consider

integers

non

atomic

ifwe

thought

of

them

as

ordered

listsofdigits.

8.2 Database Schem a

1. Wedistinguishbetweenadatabasescheme(logicaldesign)andadatabaseinstance(datainthedatabaseatapointintime).


14/33

2. Arelationschemeisalistofattributesandtheircorrespondingdomains.3. Thetextusesthefollowingconventions:

o italicsforallnameso lowercasenamesforrelationsandattributeso namesbeginningwithanuppercaseforrelationschemes

These

notes

will

do

the

same.

Forexample,therelationschemeforthedepositrelation:

o Depositscheme=(bname,account#,cname,balance)

Figure1.4: Thedepositandcustomerrelations

WemaystatethatdepositisarelationonschemeDepositschemebywriting

deposit(Depositscheme).

Ifwewishtospecifydomains,wecanwrite:

o (bname:string,account#:integer,cname:string,balance:integer).Notethatcustomersareidentifiedbyname.Intherealworld,thiswouldnotbeallowed,astwoormorecustomersmightsharethesamename.


15/33

Figure1.5:ERdiagramforthebankingenterprise

4. Therelationschemesforthebankingexampleusedthroughoutthetextare:o Account_schema=(account_number,branch_name,balance)o Branchscheme=(branch_name,branch_city,assets)o Customerscheme=(customer_name,customer_street,customer_city)o Depositscheme=(customer_name,account_number)o Loan_schema=(loan_number,branch_name,amount)o Borrowscheme=(bname,loan#,cname,amount)

Note:someattributesappearinseveralrelationschemes(e.g.bname,cname).

This

is

legal,

and

provides

a

way

of

relating

tuples

of

distinct

relations.

5. Whynotputallattributesinonerelation?Supposeweuseonelargerelationinsteadofcustomeranddeposit:

o Accountscheme=(bname,account#,cname,balance,street,ccity)


16/33

o Ifacustomerhasseveralaccounts,wemustduplicateherorhisaddressforeachaccount.

o Ifacustomerhasanaccountbutnocurrentaddress,wecannotbuildatuple,aswehavenovaluesfortheaddress.

o Wewouldhavetousenullvaluesforthesefields.o Nullvaluescausedifficultiesinthedatabase.o By

using

two

separate

relations,

we

can

do

this

without

using

null

values

8.3 Keys

1. Thenotionsofsuperkey,candidatekeyandprimarykeyallapplytotherelationalmodel.

Loanrelation Borrowerrelation

LetKR KisasuperkeyofRifvaluesforKaresufficienttoidentifyauniquetupleofeach

possiblerelationr(R)

oby

possible

r

we

mean

a

relation

r

that

could

exist

in

the

enterprise

we

aremodeling.

o Example: {customer_name,customer_street}and{customer_name}

arebothsuperkeysofCustomer,ifnotwocustomerscanpossiblyhave

thesamename

Inreallife,anattributesuchascustomer_idwouldbeusedinsteadofcustomer_nametouniquelyidentifycustomers,butwe

omitittokeepourexamplessmall,andinsteadassumecustomer

namesareunique.

KisacandidatekeyifKisminimalExample:

{customer_name}

is

acandidate

key

for

Customer,

since

it

is

a

superkeyandnosubsetofitisasuperkey.

Primarykey:acandidatekeychosenastheprincipalmeansofidentifyingtupleswithinarelation

o Shouldchooseanattributewhosevaluenever,orveryrarely,changes.o E.g.emailaddressisunique,butmaychange


17/33

ForeignKeys

Arelationschemamayhaveanattributethatcorrespondstotheprimarykeyofanotherrelation. Theattributeiscalledaforeignkey.

o E.g.customer_nameandaccount_numberattributesofdepositorareforeignkeystocustomerandaccountrespectively.

o Onlyvaluesoccurringintheprimarykeyattributeofthereferencedrelation

may

occur

in

the

foreign

key

attribute

of

the

referencing

relation.

Schemadiagram

8 .4 Query Languages 1. Aquerylanguageisalanguageinwhichauserrequestsinformationfroma

database.Thesearetypicallyhigherlevelthanprogramminglanguages.

Theymaybeoneof:

o Procedural,where

the

user

instructs

the

system

to

perform

asequence

ofoperationsonthedatabase.Thiswillcomputethedesiredinformation.

o Nonprocedural,wheretheuserspecifiestheinformationdesiredwithoutgivingaprocedureforobtainingtheinformation.

2. Acompletequerylanguagealsocontainsfacilitiestoinsertanddeletetuplesaswellastomodifypartsofexistingtuples.

9. The Ent i t y - Re la t ion sh ip Model

TheER(entityrelationship)datamodelviewstherealworldasasetofbasic

objects(entities)andrelationshipsamongtheseobjects.

ItisintendedprimarilyfortheDBdesignprocessbyallowingthespecificationof

anenterprisescheme.ThisrepresentstheoveralllogicalstructureoftheDB.


18/33

9 .1 En t i t y Se ts

Anentityisathingorobjectintherealworldthatisdistinguishablefromallotherobjects.Forinstance,JohnHarriswithS.I.N.890123456isanentity,ashe

canbeuniquelyidentifiedasoneparticularpersonintheuniverse.

Anentitymaybeconcrete(apersonorabook,forexample)orabstract(likeaholiday

or

a

concept).

Anentitysetisasetofentitiesofthesametypethatsharethesameproperties,orattributes.(e.g.,allpersonshavinganaccountatabank).

Entitysetsneednotbedisjoint.Forexample,theentitysetemployee(allemployeesofabank)andtheentitysetcustomer(allcustomersofthebank)

mayhavemembersincommon.

Anentityisrepresentedbyasetofattributes.o E.g.name,S.I.N.,street,cityfor``customer''entity.o Thedomainoftheattributeisthesetofpermittedvalues(e.g.the

telephonenumbermustbesevenpositiveintegers).

Formally,anattributeisafunctionwhichmapsanentitysetintoadomain.o Every

entity

is

described

by

aset

of

(attribute,

data

value)

pairs.

o Thereisonepairforeachattributeoftheentityset.o E.g.aparticularcustomerentityisdescribedbytheset{(name,Harris),

(S.I.N.,890123456),(street,North),(city,Georgetown)}.

Fig1.6EntitysetsCustomerandLoan Fig1.7Relationshipsetborrower

9.2 Rela t io nsh ip Sets

Arelationshipisanassociationamongseveralentitieso Example:

Hayesdepositor

A

102

customerentity relationshipset accountentity

Arelationshipsetisamathematicalrelationamongn2entities,eachtakenfromentitysets

{(e1,e2,en)|e1E1,e2 E2,,en En}where(e1,e2,,en)isarelationship


19/33

Example:(Hayes,A102)depositor

Anattributecanalsobepropertyofarelationshipset. Forinstance,thedepositorrelationshipsetbetweenentitysetscustomerand

accountmayhavetheattributeaccessdate

Fig1.8Access_dateasattributeofthedepositorrelationshipset.

Forexample,considerthetwoentitysetscustomerandaccount.Wedefinethe

relationshipCustAccttodenotetheassociationbetweencustomersandtheiraccounts.

Thisisabinaryrelationshipset.

Goingbacktoourformaldefinition,therelationshipsetCustAcctisasubsetofallthe

possiblecustomerandaccountpairings.

Thisisabinaryrelationship.Occasionallytherearerelationshipsinvolvingmorethan

twoentitysets.

Theroleofanentityisthefunctionitplaysinarelationship.Forexample,the

relationshipworksforcouldbeorderedpairsofemployeeentities.Thefirstemployee

takestheroleofmanager,andthesecondonewilltaketheroleofworker.

Arelationshipmayalsohavedescriptiveattributes.Forexample,date(lastdateof

accountaccess)couldbeanattributeoftheCustAcctrelationshipset.

9 .3 At t r i bu tes

Anentityisrepresentedbyasetofattributes,thatisdescriptivepropertiespossessedbyallmembersofanentityset.


20/33


21/33

10 . Cons t r a in ts

10 .1 Mapp ing Card ina l i t i es

MappingCardinalities,orcardinalityratios,expressthenumberofentitiestowhich

anotherentitycanbeassociatedviaarelationshipset.

Itdescribesbinaryrelationshipset.

OnetoOne OnetoMany

ManytoOne ManytoMany

OnetoOne:AnentityinAisassociatedwithatmostoneentityinB,andanentityinBisassociatedwithatmostoneentityinA.

Example:

o Acustomerisassociatedwithatmostoneloanviatherelationshipborrowero Aloanisassociatedwithatmostonecustomerviaborrower

Onetomany:AnentityinAisassociatedwithanynumber(zeroormore)ofentitiesinB.AnentityinB,however,canbeassociatedwithatmostoneentityinA.

Example:


22/33

o Intheonetomanyrelationshipaloanisassociatedwithatmostonecustomerviaborrower,acustomerisassociatedwithseveral(including0)loansvia

borrower

Manytoone:AnentityinAisassociatedwithatmostoneentityinB.AnentityinB,however,canbeassociatedwithanynumber(zeroormore)ofentitiesinA.

Example:

o Inamanytoonerelationshipaloanisassociatedwithseveral(including0)customersviaborrower,acustomerisassociatedwithatmostoneloanvia

borrower

Manytoone:AnentityinAisassociatedwithanynumber(zeroormore)ofentitiesinB,andanentityinB,isassociatedwithanynumber(zeroormore)ofentitiesinA.

Example:

o Acustomerisassociatedwithseveral(possibly0)loansviaborrowero Aloanisassociatedwithseveral(possibly0)customersviaborrower


23/33

10 .2 Keys

Touniquelyidentifytheentity. Toidentityasetofattributesthatsufficetodistinguishentitiesfromeachother.

10 .2 .1 En t i t y Se ts

Asuperkeyofanentitysetisasetofoneormoreattributeswhosevaluesuniquelydetermineeachentity.

Ex:Customer_id

Acandidatekeyofanentitysetisaminimalsuperkeyo Thecombinationofattributes,thatdistinguishtherecords.o Customer_idiscandidatekeyofcustomero account_numberiscandidatekeyofaccount

Althoughseveralcandidatekeysmayexist,oneofthecandidatekeysisselectedtobetheprimarykey.

Akey(primary,candidate,andsuper)isapropertyoftheentityset,ratherthanof

the

individual

entities.

10 .2 .2 Rela t ion sh ip Sets

Thecombinationofprimarykeysoftheparticipatingentitysetsformsasuperkeyofarelationshipset.

o (customer_id,account_number)isthesuperkeyofdepositoro NOTE: thismeansapairofentitysetscanhaveatmostonerelationship

inaparticularrelationshipset.

Example:ifwewishtotrackallaccess_datestoeachaccountbyeachcustomer,wecannotassumearelationshipforeachaccess.

Wecanuseamultivaluedattributethough

Mustconsiderthemappingcardinalityoftherelationshipsetwhendecidingwhatarethecandidatekeys

Needtoconsidersemanticsofrelationshipsetinselectingtheprimarykey incaseofmorethanonecandidatekey

11 . The En t i t y Re la t ionsh ip D iag ram

WecanexpresstheoveralllogicalstructureofadatabasegraphicallywithanER

diagram.

Itscomponentsare:

Rectanglesrepresententitysets. Diamondsrepresentrelationshipsets. Lineslinkattributestoentitysetsandentitysetstorelationshipsets. Ellipsesrepresentattributes


24/33

Doubleellipsesrepresentmultivaluedattributes. Dashedellipsesdenotederivedattributes. Underlineindicatesprimarykeyattributes(willstudylater) Doublelinetotalparticipationofanentityinarelationshipset Doublerectanglesrepresentweakentitysets.

Example

for

ER

diagram:

Adirected

line

()from

the

relationship

set

borrower

to

the

entity

set

loan

specifiesthatborroweriseitheraonetooneormanytoonerelationshipset,

fromcustomertoloan;borrowercannotbeamanytomanyoraonetomany

relationshipsetfromcustomertoloan.

Anundirectedline( )fromtherelationshipsetborrowertotheentitysetloanspecifiesthatborroweriseitheramanytomanyoronetomanyrelationshipset

fromcustomertoloan.

ERDiagramwithcomposite,multivalued,andderivedattributes.

o Compositeattribute:addresso Multivaluedattribute:phone_numbero Derivedattribute:age


25/33

CompositeandMultivaluedAttributes

Compositeattributesareflattenedoutbycreatingaseparateattributeforeachcomponentattribute

o Example:givenentitysetcustomerwithcompositeattributenamewithcomponentattributesfirst_nameandlast_nametheschema

correspondingto

the

entity

set

has

two

attributes

name.first_name andname.last_name

AmultivaluedattributeMofanentityEisrepresentedbyaseparateschemaEMo SchemaEMhasattributescorrespondingtotheprimarykeyofEandan

attributecorrespondingtomultivaluedattributeM

o Example: Multivaluedattributedependent_namesofemployeeisrepresentedbyaschema:

employee_dependent_names =(employee_id,dname)

o EachvalueofthemultivaluedattributemapstoaseparatetupleoftherelationonschemaEM

Forexample, anemployeeentitywithprimarykey 123456789and

dependents

Jack

and

Jane

maps

to

two

tuples:

(123456789,Jack)and(123456789,Jane)

RolesinERDiagrams

Entitysetsofarelationshipneednotbedistinct Thelabelsmanagerandworkerarecalledroles;theyspecifyhowemployee

entitiesinteractviatheworks_forrelationshipset.

RolesareindicatedinERdiagramsbylabelingthelinesthatconnectdiamondsto

rectangles.

Rolelabelsareoptional,andareusedtoclarifysemanticsoftherelationship

ERdiagramwithroleindicators

Cardinalitylimitscanalsoexpressparticipationconstraints


26/33

o Eachloanmusthaveexactlyoneassociatedcustomer.Thelimit0..*ontheedgefromcustomertoborrowerindicatesthatacustomercanhavezeroor

moreloans,Thus,therelationshipborrowerisonetomanyfromcustomerto

loan,andfurthertheparticipationofloaninborroweristotal.

ERdiagramwithaternaryrelationship

SymbolsusingforERNotation


27/33


28/33

12 . Ext ended E-R Featu res 12 .1 Spec ia l i za t ion ( Top dow n appr oach)

Topdowndesignprocess;wedesignatesubgroupingswithinanentitysetthataredistinctivefromotherentitiesintheset.

Thesesubgroupingsbecomelowerlevelentitysetsthathaveattributesorparticipateinrelationshipsthatdonotapplytothehigherlevelentityset. DepictedbyatrianglecomponentlabeledISA(E.g.customerisaperson). Attributeinheritancealowerlevelentitysetinheritsalltheattributesand

relationshipparticipationofthehigherlevelentitysettowhichitislinked.

12 .2 Genera l i za t ion ( Bo t tom -up approach)

Abottomupdesignprocesscombineanumberofentitysetsthatsharethesamefeaturesintoahigherlevelentityset.


29/33

Specializationandgeneralizationaresimpleinversionsofeachother;theyarerepresentedinanERdiagraminthesameway.

Thetermsspecializationandgeneralizationareusedinterchangeably.Ageneralizationrelationshipspecifiesthatseveraltypesofentitieswithcertain

commonattributescanbegeneralizedintohigherlevelentityclassorsuperclassentity.

(ie.Combine

number

of

entity

set

that

share

the

same

features

into

ahigher

level

entity

set)

Generalizationhidesdifferencesandemphasizessimilarities. Distinctionmadethroughattributeinheritance. Attributesofhigherlevelentityareinheritedbylowerlevelentities. Twomethodsforconversiontoatableform:

o Createatableforthehighlevelentity,plustablesforthelowerlevelentitiescontainingalsotheirspecificattributes.

o Createonlytablesforthelowerlevelentities.13 . The Netw o rk Mode l

Dataarerepresentedbycollectionsofrecords.o similartoanentityintheERmodelo Recordsandtheirfieldsarerepresentedasrecordtype

type customer=record type account=record

customername:string; accountnumber:integer;

customerstreet:string; balance:integer;

customercity:string;

end

end

Relationshipsamongdataarerepresentedbylinkso similartoarestricted(binary)formofanERrelationshipo Restrictionsonlinksdependonwhethertherelationshipismanymany,

manytoone,oronetoone.

Sincealinkcannotcontainanydatavalue,representanERrelationshipwithattributeswithanewrecordtypeandlinks.


30/33

Example

SampleDatabaseforNetwork


31/33

14 . The Hierar ch ica l Mode l

Ahierarchicaldatabaseconsistsofacollectionofrecordswhichareconnectedtooneanotherthroughlinks.

Arecordisacollectionoffields,eachofwhichcontainsonlyonedatavalue. Alinkisanassociationbetweenpreciselytworecords. Thehierarchicalmodeldiffersfromthenetworkmodelinthattherecordsare

organizedascollectionsoftreesratherthanasarbitrarygraphs.

TreeStructureDiagram

Theschemaforahierarchicaldatabaseconsistsofo boxes,whichcorrespondtorecordtypeso lines,whichcorrespondtolinks

Recordtypesareorganizedintheformofarootedtree.o Nocyclesintheunderlyinggraph.o

Relationships

formed

in

the

graph

must

be

such

that

only

one

to

many

or

onetoonerelationshipsexistbetweenaparentandachild.

GeneralStructure

Aparentmayhaveanarrowpointingtoachild,butachildmusthaveanarrowpointingtoitsparent.


32/33


33/33

REFERENCES:

Abraham Silberschatz, Henry Korth.F and Sudarsham.S, 2006. Database System

Concepts, [Fifth Edition], Tata McGraw Hill, New Delhi.

Web Reference :

http://db-book.com/ - Book Author Home Page

www.cs.sfu.ca/CC/354/zaiane

Educationisaprogressivediscoveryofourownignorance. WillDurant

***ALLTHEBEST***

Documents

rdbms Basic Notes