Introduction to Database Systems Lecture 3 PDF

Introduction to Database Systems Lecture #3  Agenda  Database Users  When Not To Use a DBMS System  Data Models, Schemas, and Instances  Three-Schema Architecture  Data Independence 2  Database Users ▸Users may be divided into: ▹Actors on...

Introduction to Database Systems Lecture #3  Agenda  Database Users  When Not To Use a DBMS System  Data Models, Schemas, and Instances  Three-Schema Architecture  Data Independence 2  Database Users ▸Users may be divided into: ▹Actors on the Scene: those who use and control the content, and ▹Workers Behind the Scene: those who enable the database to be developed and the DBMS software to be designed and implemented. 3  Database Users - Actors on the scene ▸Database administrators: responsible for authorizing access to the database, for coordinating and monitoring its use, acquiring software, and hardware resources, controlling its use and monitoring efficiency of operations. ▸Database Designers: responsible for defining the content, the structure, the constraints, and functions or transactions against the database. They must communicate with the end-users and understand their needs. ▸End-users: they use the data for queries, reports and some of them update the database content. 4  Categories of End-users ▸Casual: access database occasionally when needed. ▸Naïve or Parametric: they are most of the end-user population. They use previously well-defined functions in the form of “canned transactions” against the database. For examples: bank-tellers or reservation clerks. ▸Sophisticated: these include business analysts, scientists, engineers, and others who are familiar with the system capabilities. ▸Stand-alone: mostly maintain personal databases using ready-to-use packaged applications. An example is a tax program user that creates his or her own internal database. 5  When Not To Use a DBMS System ▸It requires high investment. ▸The requirement of DBMS is not a necessity. ▸The access to the multi-user is not provided. ▸If the database is not efficient to handle the complexities of the data. ▸When it does not fulfil the real-time requirements for some application programs due to the overhead embedded systems. ▸When it increases the data redundancy. ▸If it does not provide the security and privacy to the data which is required. 6  Data Models, Schemas, and Instances 7  Data Models ▸Data Model: A set of concepts to describe ▹the structure of a database, ▹the operations for manipulating these structures, and ▹the constraints that the database should obey. ▸Data Model provides proper means to describe the design of a database at the ▹Physical level ▹Logical level ▹View levels 8  Data Models ▸Data Model Structure ▹data and data types and entities (e.g., record, table( ▹relationships among data ▹constraints on data These are restrictions/conditions on valid data; That must be enforced at all times. For example: Each department must have at least 5 employees A student can not have more than one advisor The salary of employee cannot exceed the salary of his/her immediate supervisors 9  Data Models ▸Data Model Operations: are for specifying database retrievals and updates by referring to the concepts of the data model and may include: ▹basic operations, e.g., generic insert, delete, update ▹user-defined operations, e.g., compute student GPA, update inventory. 10  Categories of Data Models Conceptual (high-level, semantic) data models: Describe the database at a very high level to understand the database requirements within the requirements gathering process (e.g., Entity/relationship model or ER model.( Physical (low-level, internal) data models: Provide concepts that describe details of how data is stored in the computer. Implementation (representational) data models: Represent only the logical part of the database to allow focusing on the design part of the database (e.g., Relational model(. 11  History of Data Models ▸Hierarchical Data Model: is the oldest type of the data model. ▹It was developed in a joint effort by IBM and North American Rockwell around.1965 ▹It organizes data in the tree- like structure. Figure1. Example of Hierarchical Data Model 12  Hierarchical Model ▸ADVANTAGES Hierarchical Model is simple to construct and operate on. Corresponds to several natural hierarchically organized domains (e.g., assemblies in manufacturing, personnel organization in companies.( Language is simple; uses constructs like GET, GET UNIQUE, GET NEXT, GET NEXT WITHIN PARENT etc. ▸DISADVANTAGES Navigational and procedural nature of processing. Database is visualized as a linear arrangement of records. 13 Little scope for "query optimization.“  History of Data Models ▸Network Data Model: is the advance version of the hierarchical data model. ▹To organize data it uses directed graphs instead of the tree- structure. ▹In this child can have more than one parent. Figure2. Example of Network Data Model ▹It uses the concept of the two data structures i.e. Records and Sets. 14  Network Model ▸ADVANTAGES Network Model can model complex relationships and represents semantics of add/delete on the relationships. Can handle most situations for modeling using record types and relationship types. Language is navigational; uses constructs like FIND, FIND member, FIND owner, FIND NEXT within set, GET etc. Programmers can do optimal navigation through the database. ▸DISADVANTAGES Navigational and procedural nature of processing Database contains a complex array of pointers that thread through a set of records. 11 Little scope for automated "query optimization”  History of Data Models ▸Relational Data Model: ▹was developed by E.F. Codd in.1970 ▹There are no physical links as in the hierarchical data model. ▹Example of several commercial products (DB2, ORACLE, SQL Server, SYBASE, INFORMIX( Figure3. Example of Relational Data Model 16  History of Data Models ▸Object-Oriented Data Model : is a developed data model that comprise models of persistent O-O Programming Languages. ▹This model can store audio, video, and graphics files. Figure5. Example of Object-Oriented Data Model 17  History of Data Models ▸Object-Relational Data Model: is a combination of an object-oriented data model and a relational data model. ▹It supports objects, classes, inheritance etc. just like O-O models and has support for data types, tabular structures etc. like Relational data model. ▹One of the major goals of Object relational data model is to close the gap between relational databases and the object- oriented practices used in many programming languages such as C++, C#, J ava etc. Figure5. Example of Object-Oriented Data Model 18  Schemas versus Instances Database Schema: The description of a database. Includes descriptions of the database structure and the constraints that should hold on the database. Schema Diagram: A diagrammatic display of (some aspects of) a database schema. Schema Construct: A component of the schema or an object within the schema, e.g., STUDENT, COURSE. Database Instance: The actual data stored in a database at a particular moment in time. Also called database state (or occurrence(. 19  Schemas versus Instances 17 Figure6. Example of Database Schema Figure7. Example of Database Instance  Database Schema Vs. Database State Database State: Refers to the content of a ▸.database at a moment in time Initial Database State: Refers to the database ▹ when it is loaded Valid State: A state that satisfies the structure ▹.and constraints of the database Distinctions ▸ The database schema changes very infrequently ▹ while the database state changes every time the.databa se is updated Schema is also called intension, whereas state ▹ 18.is called extension Figure8. Example of Database State