Chapter Two. DBMS Architecture How should DBS be organized?

Transcription

1 Chapter Two DBMS Architecture How should DBS be organized? 1

2 Agenda (Chapter two) Reality, Data & Metadata The Three Levels of DBS Architecture External View, Conceptual View, Internal View Schemas, Mappings, and Instances The Database Management System (DBMS) Functions of DBMS Requirements of DBMS with Respect to Database Languages (DDL and DML) Roles in Database Environment 2

3 Reality, metadata and data value Reality is what exists in the real world. This reality might be in a physical or logical form. When developing a database or information system, representation of the reality in the computer system is the first step. The representation would be by considering the properties the reality exhibits. When these properties assume a specific value it would represent the real world object for which data is required to be captured for. Thus any data model will be having a representation mechanism for the building blocks of data representation. 3

4 Real world can be represented using its building blocks. The building blocks vary based on the kind of reality we want to represent. When it comes to data representation, the building blocks are: Entities Attributes Relationship 4

5 ENTITIES Real world physical or logical object for which data need to be captured for Persons, places, things etc. which the organization has to deal with. The name given to an entity should always be a singular noun descriptive of each item to be stored in it. E.g.: student NOT students 5

6 Existence Dependency: the dependence of an entity on the existence of one or more entities. Weak entity : an entity that can not exist without the entity with which it has a relationship it is indicated by a double rectangle or dotted line (various modeling approaches) Entity will be realized as relations or tables later Relations can also describe relationships (will be discussed later) Every relation has a schema, which describes the columns, or fields the relation itself corresponds to our familiar notion of a table A relation is a collection of tuples, each of which contains values for a fixed number of attributes 6

7 ATTRIBUTES Properties used to describe each Entity or real world object. These attributes will assume a value to represent a single occurrence of that real world object class The items of information which characterize and describe these entities. Attributes are pieces of information ABOUT entities. The analysis must of course identify those which are actually relevant to the proposed application. Attributes will give rise to recorded items of data in the database 7

8 At this level we need to know such things as: Attribute name (be explanatory words or phrases) The domain from which attribute values are taken (A DOMAIN is a set of values from which attribute values may be taken.) Each attribute has values taken from a domain. For example, the domain of Name is string and that for salary is real 8

9 Whether the attribute is part of the entity identifier (attributes which just describe an entity and those which help to identify it uniquely) Whether it is permanent or time-varying (which attributes may change their values over time) Whether it is required or optional for the entity (whose values will sometimes be unknown or irrelevant) 9

10 Types of Attributes Simple (atomic) Vs Composite attributes Simple : contains a single value (not divided into sub parts) E.g. Age, gender Composite: Divided into sub parts (composed of other attributes) E.g. Name, address 10

11 Single-valued Vs multi-valued attributes Single-valued : have only single value (the value may change but has only one value at one time) E.g. Name, Sex, Id. No. color_of_eyes Multi-Valued: have more than one value E.g. hobby Address, dependent-name Person may have several college degrees 11

12 Stored vs. Derived Attribute Stored : not possible to derive or compute E.g. Name, Address Derived: The value may be derived (computed) from the values of other attributes. E.g. Age (current year year of birth) Length of employment (current date- start date) Profit (earning-cost) G.P.A (grade point/credit hours) 12

13 Null Values (Null Ok attributes) NULL applies to attributes which are not applicable or which do not have values. You may enter the value NA (meaning not applicable) Value of a key attribute can not be null. Default value - assumed value if no explicit value 13

14 Entity Vs Attributes When designing the conceptual specification of the database, one should pay attention to the distinction between an Entity and an Attribute. Consider designing a database of employees for an organization: Should address be an attribute of Employees or an entity (connected to Employees by a relationship)? If we have several addresses per employee, address must be an entity (attributes cannot be set-valued/multi valued) If the structure (city, Woreda, Kebele, etc) is important, e.g. want to retrieve employees in a given city, address must be modeled as an entity (attribute values are atomic) 14

15 RELATIONSHIPS Associations between entities which exist and must be taken into account when processing information. In any business processing one object may be associated with another object due to some event. Such kind of association is what we call a RELATIONSHIP between entity objects A relationship should be named by a word or phrase which explains its function For each RELATIONSHIP, one can talk about the Number of Entities and the Number of Tuples participating in the association. These two concepts are called DEGREE and CARDINALITY of a relationship respectively 15

16 Degree of a Relationship An important point about a relationship is how many entities participate in it. The number of entities participating in a relationship is called the DEGREE of the relationship. 16

17 Among the Degrees of relationship, the following are the basic: UNARY/RECURSIVE RELATIONSHIP: Tuples/records of a Single entity are related withy each other. BINARY RELATIONSHIPS: Tuples/records of two entities are associated in a relationship TERNARY RELATIONSHIP: Tuples/records of three different entities are associated And a generalized one: N-NARY RELATIONSHIP: Tuples from arbitrary number of entity sets are participating in a relationship. 17

18 Cardinality of a Relationship Another important concept about relationship is the number of instances/tuples that can be associated with a single instance from one entity in a single relationship. The number of instances participating or associated with a single instance from an entity in a relationship is called the CARDINALITY of the relationship. 18

19 The major cardinalities of a relationship are: ONE-TO-ONE: one tuple is associated with only one other tuple. E.g. Building Location as a single building will be located in a single location and as a single location will only accommodate a single Building. ONE-TO-MANY, one tuple can be associated with many other tuples, but not the reverse. E.g. Department-Student as one department can have multiple students. 19

20 MANY-TO-ONE, many tuples are associated with one tuple but not the reverse. E.g. Employee Department: as many employees belong to a single department. MANY-TO-MANY: one tuple is associated with many other tuples and from the other side, with a different role name one tuple will be associated with many tuples E.g. Student Course as a student can take many courses and a single course can be attended by many students. What do govern the cardinality and degree of a given relationship? 20

21 21 Three levels/views of DBS

22 Database Architecture DBMSs do not all confirm to the same architecture. The three-level architecture forms the basis of modern database architectures. Agreement with the ANSI/SPARC (American National Standards Institute- Standards Planning and Requirement Committee) study group on Database Management Systems. 22

23 The architecture for DBMSs is divided into three general levels: 1.External-user 2.Conceptual-logical 3.Internal-physical 23

24 3 Level ANSI/SPARC Architecture Proposed to support DBMS characteristics of: Program-data independence. Data definition is separated from the application Data Sharing Support of multiple views of the data 24

25 Three levels of abstractions in describing data For better understanding of DB functionalities Made databases more independent of application Became a standard for the organisation of DBMS 25

26 The Three Levels of DBS Architecture: ANSI-SPARC DB Architecture 26

27 External Level: Users' view of the database. concerned with the way individual users see the data Describes that part of database that is relevant to a particular user. Different users have their own customized view of the database independent of other users. 27

28 Conceptual Level: Community view of the database. Describes what data is stored in database and relationships among the data can be regarded as a community user view a formal description of data of interest to the organisation, independent of any storage considerations. 28

29 Internal Level: Physical representation of the database on the computer. Concerned with the way in which the data is actually stored Storage spacing allocation for data Record description for storage Describes how the data is stored in the database. 29

30 Schema for the level External (Sub) Schema o defines the external view of data as seen by a user or program Conceptual Schema o defines the logical view of data as seen by all users and programs Physical (Internal) Schema o defines the physical view of data as seen by a DBMS 30

31 Purpose 3-Level DB architecture All users should be able to access same data. Since the database is having a shared data feature where all the data is stored in one location and all users will have their own customized way of interacting with the data. A user's view is unaffected or immune to changes made in other views. Since the requirement of one user is independent of the other, a change made in one user s view should not affect other users. 31

32 Users should not need to know physical database storage details. As there are naïve users of the system, hardware level or physical details should be a black-box for such users. DBA should be able to change database storage structures without affecting the users' views. A change in file organization, access method should not affect the structure of the data which in turn will have no effect on the users. 32

33 Internal structure of database should be unaffected by changes to physical aspects of storage. DBA should be able to change conceptual structure of database without affecting all users. In any database system, the DBA will have the privilege to change the structure of the database, like adding tables, adding and deleting an attribute, changing the specification of the objects in the database. 33

34 34 ANSI-SPARC Architecture and Database Design Phases

35 35 Example

36 Three-schema architecture Different people have different views of the database these are the external schema The internal schema is the underlying design and implementation 36

37 Developing the three-tiered architecture 37

38 Example: University Database Conceptual schema: Students(sid: string, name: string, login: string, age: integer, gpa:real) Courses(cid: string, cname:string, credits:integer) Enrolled(sid:string, cid:string, grade:string) External Schema (View): Course_info(cid:string,enrollment:integer) Physical schema: Relations stored as unordered files. Index on first column of Students. View 1 View 2 View 3 Conceptual Schema Physical Schema DB 38

39 View View View External Layer Conceptual Layer Base Tables Physical Layer 39 Stored Tables...

40 Physical View The DBMS must know exact physical location precise physical structure database Employee record A.B.C. De Silva 222, Galle Road, Colombo Name (20 characters) Address (40 characters) V Senior Lecturer NID (10 char) Designation (15 char) 40

41 Logical View The user/application must know existence logical reference Employee database NID V Name A.B.C. De Silva Designation Senior Lecturer Address 222, Galle Road, Colombo 41

42 Table Conceptual Layer Table The conceptual model is a logical representation of the entire contents of the database. The conceptual model is made up of base tables. Base tables are real in that they contain physical records. 42

43 External View The user/application see authorised data own format database Lecturer Name A.B.C. De Silva Department Dept. of Computer Science Designation Senior Lecturer Age 35 43

44 External View cont. 44 External Views Allows to hide unauthorised data e.g. salary, date of birth provide user view e.g. view employee name, designation, department data taken from employee and department files derive new attributes e.g. age derived from date of birth

45 External View cont. External Views Allows to change unit of measurement e.g. show age in years or months define security levels e.g. update access to employee file read-only to department file 45

46 View View External Layer The external model represents how data is presented to users. It is made up of view tables. View tables are "virtual"-- they do not exist in physical storage, but appear to a user as if they did 46

47 Data Independence This is a prime advantage of a database In conventional systems applications are data-dependent For example, if a file is stored in indexed sequential form then an application must know that the index exists the file sequence (as defined by the index), The internal structure of the application will be built around this knowledge. If, for example, the file was to be replaced by another file with different indexing structure major modifications would have to be made to the application. 47

48 48 Cont... Such an application is data-dependent it is undesirable to allow applications to be data-dependent the DBA must have the freedom to change storage structure or access strategy in response to changing requirements without having to modify existing applications. Data independence can be defined as The immunity of applications to change in storage structure and access strategy. Data independence is the ability to change the schema at one level of the database system without changing the schema at the next higher level. There are two types Logical data independence Physical data independence

49 Data Independence Applications insulated from how data is structured and stored. Logical data independence: Protection from changes in logical structure of data. Physical data independence: Protection from changes in physical structure of data. Question: Why are these particularly important for DBMS? View 1 View 2 View 3 Conceptual Schema Physical Schema DB 49

50 Logical Data Independence: Refers to immunity of external schemas to changes in conceptual schema. Conceptual schema changes e.g. addition/removal of entities should not require changes to external schema or rewrites of application programs. The capacity to change the conceptual schema without having to change the external schemas and their application programs 50

51 Physical Data Independence The ability to modify the physical schema without changing the logical schema Applications depend on the logical schema In general, the interfaces between the various levels and components should be well defined so that changes in some parts do not seriously influence others. The capacity to change the internal schema without having to change the conceptual schema Refers to immunity of conceptual schema to changes in the internal schema Internal schema changes e.g. using different file organizations, storage structures/devices should not require change to conceptual or external schemas. 51

52 52 Schemas, Mappings, and Instances

53 Schema Vs data Information in the database is subdivided into two concepts: Schema Data Schema Schema is the concept of how information relates to other pieces of information, and how information should be grouped. Schema describes how data is to be structured - defined at set-up time, rarely changes (part of the "metadata") Comparable to types and variables in programming languages External- different views of data Conceptual- description entities, attributes and r/n ships Internal schema- description of representing fields 53

54 Data Data is actual "instance" of database, may change rapidly Data is the concept of the actual information users want to store in the database. You can only store data in structures which the schema provides, so we must ensure that the schema is correct. 54

55 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). 55

56 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. The database schema changes very rarely. The database state changes every time the database is updated (inserting new data, changing an existing data or deleting an existing data). Schema is also called intension, whereas state is called extension. 56

57 Mappings Mapping is a process of converting one level to another level. Mappings among schema levels are needed to transform requests and data. Programs refer to an external schema, and are mapped by the DBMS to the internal schema for execution There are two levels of mapping The conceptual/internal mapping: defines conceptual and internal view correspondence specifies mapping from conceptual records to their stored counterparts An external/conceptual mapping: defines a particular external and conceptual view correspondence 57

58 A change to the storage structure definition means that the conceptual/internal mapping must be changed accordingly, so that the conceptual schema may remain invariant, achieving physical data independence. A change to the conceptual definition means that the conceptual/external mapping must be changed accordingly, so that the external schema may remain invariant, achieving logical data independence. 58

59 The Database Management System (DBMS)-Functions and Languages 59

60 The DBMS-Functions and Languages Database Management System (DBMS) is a Software package used for providing a systematic method for creating, updating, storing, retrieving data in a database. the service of controlling data access, enforcing data integrity, managing concurrency control, and recovery. EFFICIENT, CONVENIENT and SAFE MULTI-USER (many people/programs accessing same database, or even same data, simultaneously)storage of and access to MASSIVE amounts of PERSISTENT (data outlives programs that operate on it) data. 60

61 A full scale DBMS should at least have the following services to provide to the user Data storage, retrieval and update in the database A user accessible catalogue (metadata) Transaction support service: ALL or NONE transaction, which minimize data inconsistency. Concurrency Control Services: access and update on the database by different users simultaneously should be implemented correctly. Recovery Services: a mechanism for recovering the database after a failure must be available. 61

62 Authorization Services (Security): must support the implementation of access and authorization service to database administrator and users. Support for Data Communication: should provide the facility to integrate with data transfer software or data communication managers. Integrity Services: rules about data and the change that took place on the data, correctness and consistency of stored data, and quality of data based on business constraints. 62

63 Services to promote data independency between the data and the application Utility services: sets of utility service facilities like Importing data Statistical analysis support Index reorganization Garbage collection 63

64 Typical DBMS Functionality (simply) Define a particular database; Construct or Load the initial database Manipulate the database; Process and Share for a set of concurrent users and application programs 64

65 65 Database languages

66 Database languages A DBMS is software package used to develop, manage, and maintain databases. Each DBMS should have facilities to define the database, manipulate the content of the database and control the database. These facilities will help the designer, the user as well as the database administrator to discharge their responsibility in designing, using and managing the database. 66

67 The two major categories of languages are Data Definition Language (DDL) Data Manipulation Language (DML) But there is also a third category Data Control Language (DCL) 67

68 Data Definition Language (DDL): Language used to define each data element required by the organization. Commands for setting up schema or the intension of database These commands are used to setup a database, create, drop and alter table with the facility of handling constraints 68

69 Allows DBA or user to describe and name entities, attributes and relationships required for the application. Specification notation for defining the database schema Example: create table Student ( StudentID FirstNAme LastName Age ) char(10), char(15), char(15), integer 69

70 Some more command examples: CREATE - to create objects in the database ALTER - alters the structure of the database DROP - delete objects from the database TRUNCATE - remove all records from a table, including all spaces allocated for the records are removed COMMENT - add comments to the data dictionary RENAME - rename an object 70

71 Data Manipulation Language (DML): Is a core command used by end-users and programmers to store, retrieve, and access the data in the database e.g. SQL Since the required data or Query by the user will be extracted using this type of language, it is also called "Query Language Provides basic data manipulation operations on data held in the database. Language for accessing and manipulating the data organized by the appropriate data model 71

72 DML can be in two forms Procedural DML: user specifies what data is required and how to get the data. Non-Procedural DML: user specifies what data is required but not how it is to be retrieved SQL is the most widely used non-procedural language query language 72

73 E.g. find the name of the passenger with passport number EP select Passenger.Name from passenger where passenger.passposrtno = EP

74 Some more command examples: SELECT - retrieve data from the a database INSERT - insert data into a table UPDATE - updates existing data within a table DELETE - deletes all records from a table, the space for the records remain CALL - call a PL/SQL or Java subprogram LOCK TABLE - control concurrency 74

75 Still one can consider additional DB languages called: Data Control Language (DCL) Database is a shared resource that demands control of data access and usage. The database administrator should have the facility to control the overall operation of the system. 75

76 Data Control Languages are commands that will help the Database Administrator to control the database. The commands include commands like granting privileges to access the database or particular object within the database and to store or remove database transactions Some examples of Data Control Language (DCL) statements. GRANT - gives user's access privileges to database REVOKE - withdraw access privileges given with the GRANT command 76

77 77 Components of a DB Environment The DBMS is software package that helps to design, manage, and use data using the database approach. Taking a DBMS as a system, one can describe it with respect to it environment or other systems interacting with the DBMS. The DBMS environment has five components. To design and use a database, there will be the interaction or integration of Hardware, Software, Data, Procedure and People.

78 Hardware: are components that one can touch and feel. These components are comprised of various types of personal computers, mainframe or any server computers to be used in multiuser system, network infrastructure, and other peripherals required in the system. 78

79 Software: Collection of commands and programs used to manipulate the hardware to perform a function. These include components like the DBMS software, application programs, operating systems, network software, language software and other relevant software 79

80 80 Cont Data: Since the goal of any database system is to have better control of the data and making data useful, Data is the most important component to the user of the database. There are two categories of data in any database system: that is Operational and Metadata. Operational data is the data actually stored in the system to be used by the user. Metadata is the data that is used to store information about the database itself. The structure of the data in the database is called the schema, which is composed of the Entities, Properties of entities, and relationship between entities.

81 Procedure: The rules and regulations on how to design and use a database. It includes procedures like how to log on to the DBMS, how to use facilities, how to start and stop transaction, how to make backup, how to treat hardware and software failure, how to change the structure of the database. 81

82 People: those people in the organization that are responsible or play a role in designing, implementing, managing, administering and using the resources in the database. This component includes group of people with high level of knowledge about the database and the design technology to other with no knowledge of the system except using the data in the database. 82

83 Development cycle and Roles in Database Envr t 83

84 Roles and Development cycle in DB Environment Roles in database environment will be at different levels of database design and development As it is one component in most information system development tasks, there are several steps in designing a database system. Here more emphasis is given to the design phases of the system development life cycle. 84

85 Steps in DB Design Accordingly the major steps in database design are; 1. Planning: that is identifying information gap in an organization and propose a database solution to solve the problem. 2. Analysis: that concentrates more on fact finding about the problem or the opportunity. Feasibility analysis, requirement determination and structuring, and selection of best design method are also performed at this phase 85

86 3. Design: in database designing more emphasis is given to this phase. The phase is further divided into three sub-phases. Conceptual Logical Physical Conceptual Design Logical Design 86 Physical Design

87 Conceptual Design concise description of the data, data type, relationship between data and constraints on the data. There is no implementation or physical detail consideration. Used to elicit and structure all information requirements Conceptual design is the process of constructing a model of the information used in an enterprise, independent of any physical considerations. It is the source of information for the logical design phase. Mostly uses an Entity Relationship Model to describe the data at this level. After the completion of Conceptual Design one has to go for refinement of the schema, which is verification of Entities, Attributes, and Relationships 87

88 Logical Design: a higher level conceptual abstraction with selected specific data model to implement the data structure. It is particular DBMS independent and with no other physical considerations. Logical design is the process of constructing a model of the information used in an enterprise based on a specific data model (e.g. relational, hierarchical or network or object), but independent of a particular DBMS and other physical considerations. It includes Normalization process Collection of Rules to be maintained Discover new entities in the process Revise attributes based on the rules and the discovered Entities 88

89 Physical Design: physical implementation of the upper level design of the database with respect to internal storage and file structure of the database for the selected DBMS. To develop all technology and organizational specification. Physical design is the process of producing a description of the implementation of the database on secondary storage. -- defines specific storage or access methods used by database It Describes the storage structures and access methods used to achieve efficient access to the data. Tailored to a specific DBMS system -- Characteristics are function of DBMS and operating systems Includes estimate of storage space 89

90 4. Implementation: the testing and deployment of the designed database for use. 5. Operation and Support: administering and maintaining the operation of the database system and providing support to users. 90

91 People in DB environment As people are one of the components in DBMS environment, there are group of roles played by different stakeholders at the different levels of the designing and operation of a database system DB Administrator DB designer Application programmer and system analyst User 91

92 Database Administrator (DBA) Responsible to oversee, control and manage the database resources (the database itself, the DBMS and other related software) Authorizing access to the database Coordinating and monitoring the use of the database Responsible for determining and acquiring hardware and software resources Accountable for problems like poor security, poor performance of the system Involves in all steps of database development 92

93 Cont.. Further classifications of this role in big organizations having huge amount of data and user requirement. Data Administrator (DA) Database Administrator (DBA) Data Administrator (DA) is responsible on management of data resources. Involves in database planning, development, maintenance of standards policies and procedures at the conceptual and logical design phases. Database Administrator (DBA) is more technically oriented role. Responsible for the physical realization of the database. Involves in physical design, implementation, security and integrity control of the database. 93

94 DataBase Designer (DBD) Identifies the data to be stored and choose the appropriate structures to represent and store the data. Should understand the user requirement and should choose how the user views the database. Involve on the design phase before the implementation of the database system. We have two distinctions of database designers, one involving in the logical and conceptual design and another involving in physical design. 94

95 Logical and Conceptual DBD Identifies data (entity, attributes and relationship) relevant to the organization Identifies constraints on each data Understand data and business rules in the organization Sees the database independent of any data model at conceptual level and consider one specific data model at logical design phase. Physical DBD Take logical design specification as input and decide how it should be physically realized. Map the logical data model on the specified DBMS with respect to tables and integrity constraints. (DBMS dependent designing) Select specific storage structure and access path to the database Design security measures required on the database 95

96 Application Programmer and Systems Analyst System analyst determines the user requirement and how the user wants to view the database. The application programmer implements these specifications as programs; code, test, debug, document and maintain the application program. Determines the interface on how to retrieve, insert, update and delete data in the database. The application could use any high level programming language according to the availability, the facility and the required service. 96

97 End Users Workers, whose job requires accessing the database frequently for various purpose. There are different group of users in this category. Naïve Users: Sizable proportion of users Unaware of the DBMS Only access the database based on their access level and demand Use standard and pre-specified types of queries. 97

98 Sophisticated Users Are users familiar with the structure of the Database and facilities of the DBMS. Have complex requirements Have higher level queries Are most of the time engineers, scientists, business analysts, etc Casual Users Users who access the database occasionally. Need different information from the database each time. Use sophisticated database queries to satisfy their needs. Are most of the time middle to high level managers. 98

99 Summary Modeling reality-entity, attributes and relationship Three level DB architecture facilitates data independence and multiple views of the data base Schema Vs data, instance and database state DBMS functions and services: data storage, retrieval, update, security, integrity, transaction support. Database languages: DDL and DML DB environment Components: hardware, software, data, procedure, user Database design and development stages Roles in database environment 99

100 100 End of Chapter Two