数据库系统概念全套配套课件PPT ch1.ppt 33页

'Chapter1:Introduction DatabaseManagementSystem(DBMS)DBMScontainsinformationaboutaparticularenterpriseCollectionofinterrelateddataSetofprogramstoaccessthedataAnenvironmentthatisbothconvenientandefficienttouseDatabaseApplications:Banking:transactionsAirlines:reservations,schedulesUniversities:registration,gradesSales:customers,products,purchasesOnlineretailers:ordertracking,customizedrecommendationsManufacturing:production,inventory,orders,supplychainHumanresources:employeerecords,salaries,taxdeductionsDatabasescanbeverylarge.Databasestouchallaspectsofourlives UniversityDatabaseExampleApplicationprogramexamplesAddnewstudents,instructors,andcoursesRegisterstudentsforcourses,andgenerateclassrostersAssigngradestostudents,computegradepointaverages(GPA)andgeneratetranscriptsIntheearlydays,databaseapplicationswerebuiltdirectlyontopoffilesystems DrawbacksofusingfilesystemstostoredataDataredundancyandinconsistencyMultiplefileformats,duplicationofinformationindifferentfilesDifficultyinaccessingdataNeedtowriteanewprogramtocarryouteachnewtaskDataisolation—multiplefilesandformatsIntegrityproblemsIntegrityconstraints(e.g.,accountbalance>0)become“buried”inprogramcoderatherthanbeingstatedexplicitlyHardtoaddnewconstraintsorchangeexistingones Drawbacksofusingfilesystemstostoredata(Cont.)AtomicityofupdatesFailuresmayleavedatabaseinaninconsistentstatewithpartialupdatescarriedoutExample:TransferoffundsfromoneaccounttoanothershouldeithercompleteornothappenatallConcurrentaccessbymultipleusersConcurrentaccessneededforperformanceUncontrolledconcurrentaccessescanleadtoinconsistenciesExample:Twopeoplereadingabalance(say100)andupdatingitbywithdrawingmoney(say50each)atthesametimeSecurityproblemsHardtoprovideuseraccesstosome,butnotall,dataDatabasesystemsoffersolutionstoalltheaboveproblems LevelsofAbstractionPhysicallevel:describeshowarecord(e.g.,customer)isstored.Logicallevel:describesdatastoredindatabase,andtherelationshipsamongthedata.typeinstructor=recordID:string;name:string;dept_name:string;salary:integer;end;Viewlevel:applicationprogramshidedetailsofdatatypes.Viewscanalsohideinformation(suchasanemployee’ssalary)forsecuritypurposes. ViewofDataAnarchitectureforadatabasesystem InstancesandSchemasSimilartotypesandvariablesinprogramminglanguagesSchema–thelogicalstructureofthedatabaseExample:ThedatabaseconsistsofinformationaboutasetofcustomersandaccountsandtherelationshipbetweenthemAnalogoustotypeinformationofavariableinaprogramPhysicalschema:databasedesignatthephysicallevelLogicalschema:databasedesignatthelogicallevelInstance–theactualcontentofthedatabaseataparticularpointintimeAnalogoustothevalueofavariablePhysicalDataIndependence–theabilitytomodifythephysicalschemawithoutchangingthelogicalschemaApplicationsdependonthelogicalschemaIngeneral,theinterfacesbetweenthevariouslevelsandcomponentsshouldbewelldefinedsothatchangesinsomepartsdonotseriouslyinfluenceothers. DataModelsAcollectionoftoolsfordescribingDataDatarelationshipsDatasemanticsDataconstraintsRelationalmodelEntity-Relationshipdatamodel(mainlyfordatabasedesign)Object-baseddatamodels(Object-orientedandObject-relational)Semistructureddatamodel(XML)Otheroldermodels:NetworkmodelHierarchicalmodel RelationalModelRelationalmodel(Chapter2)ExampleoftabulardataintherelationalmodelColumnsRows ASampleRelationalDatabase DataManipulationLanguage(DML)LanguageforaccessingandmanipulatingthedataorganizedbytheappropriatedatamodelDMLalsoknownasquerylanguageTwoclassesoflanguagesProcedural–userspecifieswhatdataisrequiredandhowtogetthosedataDeclarative(nonprocedural)–userspecifieswhatdataisrequiredwithoutspecifyinghowtogetthosedataSQListhemostwidelyusedquerylanguage DataDefinitionLanguage(DDL)SpecificationnotationfordefiningthedatabaseschemaExample:createtableinstructor(IDchar(5),namevarchar(20),dept_namevarchar(20),salarynumeric(8,2))DDLcompilergeneratesasetoftabletemplatesstoredinadatadictionaryDatadictionarycontainsmetadata(i.e.,dataaboutdata)DatabaseschemaIntegrityconstraintsPrimarykey(IDuniquelyidentifiesinstructors)Referentialintegrity(referencesconstraintinSQL)e.g.dept_namevalueinanyinstructortuplemustappearindepartmentrelationAuthorization SQLSQL:widelyusednon-procedurallanguageExample:FindthenameoftheinstructorwithID22222selectnamefrominstructorwhereinstructor.ID=‘22222’Example:FindtheIDandbuildingofinstructorsinthePhysicsdept.selectinstructor.ID,department.buildingfrominstructor,departmentwhereinstructor.dept_name=department.dept_nameanddepartment.dept_name=‘Physics’ApplicationprogramsgenerallyaccessdatabasesthroughoneofLanguageextensionstoallowembeddedSQLApplicationprograminterface(e.g.,ODBC/JDBC)whichallowSQLqueriestobesenttoadatabaseChapters3,4and5 DatabaseDesignTheprocessofdesigningthegeneralstructureofthedatabase:LogicalDesign–Decidingonthedatabaseschema.Databasedesignrequiresthatwefinda“good”collectionofrelationschemas.Businessdecision–Whatattributesshouldwerecordinthedatabase?ComputerSciencedecision–Whatrelationschemasshouldwehaveandhowshouldtheattributesbedistributedamongthevariousrelationschemas?PhysicalDesign–Decidingonthephysicallayoutofthedatabase DatabaseDesign?Isthereanyproblemwiththisdesign? DesignApproachesNormalizationTheory(Chapter8)Formalizewhatdesignsarebad,andtestforthemEntityRelationshipModel(Chapter7)ModelsanenterpriseasacollectionofentitiesandrelationshipsEntity:a“thing”or“object”intheenterprisethatisdistinguishablefromotherobjectsDescribedbyasetofattributesRelationship:anassociationamongseveralentitiesRepresenteddiagrammaticallybyanentity-relationshipdiagram: TheEntity-RelationshipModelModelsanenterpriseasacollectionofentitiesandrelationshipsEntity:a“thing”or“object”intheenterprisethatisdistinguishablefromotherobjectsDescribedbyasetofattributesRelationship:anassociationamongseveralentitiesRepresenteddiagrammaticallybyanentity-relationshipdiagram:Whathappenedtodept_nameofinstructorandstudent? Object-RelationalDataModelsRelationalmodel:flat,“atomic”valuesObjectRelationalDataModelsExtendtherelationaldatamodelbyincludingobjectorientationandconstructstodealwithaddeddatatypes.Allowattributesoftuplestohavecomplextypes,includingnon-atomicvaluessuchasnestedrelations.Preserverelationalfoundations,inparticularthedeclarativeaccesstodata,whileextendingmodelingpower.Provideupwardcompatibilitywithexistingrelationallanguages. XML:ExtensibleMarkupLanguageDefinedbytheWWWConsortium(W3C)OriginallyintendedasadocumentmarkuplanguagenotadatabaselanguageTheabilitytospecifynewtags,andtocreatenestedtagstructuresmadeXMLagreatwaytoexchangedata,notjustdocumentsXMLhasbecomethebasisforallnewgenerationdatainterchangeformats.Awidevarietyoftoolsisavailableforparsing,browsingandqueryingXMLdocuments/data StorageManagementStoragemanagerisaprogrammodulethatprovidestheinterfacebetweenthelow-leveldatastoredinthedatabaseandtheapplicationprogramsandqueriessubmittedtothesystem.Thestoragemanagerisresponsibletothefollowingtasks:InteractionwiththefilemanagerEfficientstoring,retrievingandupdatingofdataIssues:StorageaccessFileorganizationIndexingandhashing QueryProcessing1.Parsingandtranslation2.Optimization3.Evaluation QueryProcessing(Cont.)AlternativewaysofevaluatingagivenqueryEquivalentexpressionsDifferentalgorithmsforeachoperationCostdifferencebetweenagoodandabadwayofevaluatingaquerycanbeenormousNeedtoestimatethecostofoperationsDependscriticallyonstatisticalinformationaboutrelationswhichthedatabasemustmaintainNeedtoestimatestatisticsforintermediateresultstocomputecostofcomplexexpressions TransactionManagementWhatifthesystemfails?Whatifmorethanoneuserisconcurrentlyupdatingthesamedata?AtransactionisacollectionofoperationsthatperformsasinglelogicalfunctioninadatabaseapplicationTransaction-managementcomponentensuresthatthedatabaseremainsinaconsistent(correct)statedespitesystemfailures(e.g.,powerfailuresandoperatingsystemcrashes)andtransactionfailures.Concurrency-controlmanagercontrolstheinteractionamongtheconcurrenttransactions,toensuretheconsistencyofthedatabase. DatabaseUsersandAdministratorsDatabase DatabaseSystemInternals DatabaseArchitectureThearchitectureofadatabasesystemsisgreatlyinfluencedbytheunderlyingcomputersystemonwhichthedatabaseisrunning:CentralizedClient-serverParallel(multi-processor)Distributed HistoryofDatabaseSystems1950sandearly1960s:DataprocessingusingmagnetictapesforstorageTapesprovidedonlysequentialaccessPunchedcardsforinputLate1960sand1970s:HarddisksalloweddirectaccesstodataNetworkandhierarchicaldatamodelsinwidespreaduseTedCodddefinestherelationaldatamodelWouldwintheACMTuringAwardforthisworkIBMResearchbeginsSystemRprototypeUCBerkeleybeginsIngresprototypeHigh-performance(fortheera)transactionprocessing History(cont.)1980s:ResearchrelationalprototypesevolveintocommercialsystemsSQLbecomesindustrialstandardParallelanddistributeddatabasesystemsObject-orienteddatabasesystems1990s:Largedecisionsupportanddata-miningapplicationsLargemulti-terabytedatawarehousesEmergenceofWebcommerceEarly2000s:XMLandXQuerystandardsAutomateddatabaseadministrationLater2000s:GiantdatastoragesystemsGoogleBigTable,YahooPNuts,Amazon,.. EndofChapter1 Figure1.02 Figure1.04 Figure1.06'