DOCSLIB.ORG

The Relational Data Model Data and Its Structure Physical Data Level

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Relational Data Model Data and Its Structure Physical Data Level Data and Its Structure • Data is actually stored as bits, but it is difficult to The Relational Data Model work with data at this level. • It is convenient to view data at different levels of abstraction. Chapter 4 • Schema: Description of data at some abstraction level. Each level has its own schema. • We will be concerned with three schemas: physical, conceptual, and external. 1 2 Three Schemas in the Relational Data Model Physical Data Level • Physical schema describes details of how data is payroll billing records stored: tracks, cylinders, indices etc. Set of relations • Early applications worked at this level – View 1 View 2 View 3 External schemas explicitly dealt with details. • Problem: Routines were hard-coded to deal with Set of tables Conceptual schema physical representation. – Changes to data structure difficult to make. Physical schema – Application code becomes complex since it must deal How data (tables) is stored? with details. – Rapid implementation of new features impossible. 3 4 Conceptual Data Level Conceptual Data Level (con’t) • Hides details. – In the relational model, the conceptual schema presents Conceptual view data as a set of tables. of data • DBMS maps from conceptual to physical schema Application automatically. • Physical schema can be changed without changing application: Physical view of – DBMS would change mapping from conceptual to data physical transparently DBMS – This property is referred to as physical data independence 5 6 1 External Data Level External Data Level (con’t) • In the relational model, the external schema also presents data as a set of relations. • Application is written in terms of an external schema. • An external schema specifies a view of the data • A view is computed when accessed (not stored). in terms of the conceptual level. It is tailored to • Different external schemas can be provided to different the needs of a particular category of users. categories of users. – Portions of stored data should not be seen by some • Translation from external to conceptual done users. automatically by DBMS at run time. • Students should not see their files in full. • Conceptual schema can be changed without changing • Faculty should not see billing data. application: – Information that can be derived from stored data – Mapping from external to conceptual must be might be viewed as if it were stored. changed. • GPA not stored, but calculated when needed. • Referred to as conceptual data independence. 7 8 Data Model • Tools and language for describing: Relational Model – Conceptual and external schema (a schema: • A particular way of structuring data (using description of data at some level (e.g., tables, relations) attributes, constraints, domains) • Data definition language (DDL) •Simple SQL – Integrity constraints, domains (DDL) • Mathematically based – Operations on data – Expressions (≡ queries) can be analyzed by DBMS • Data manipulation language (DML) – Queries are transformed to equivalent expressions – Optional: Directives that influence the physical automatically (query optimization) schema (affects performance, not semantics) • Optimizers have limits (=> programmer needs to know • Storage definition language (SDL) how queries are evaluated and optimized) 9 10 Relation Instance Relation Instance (Example) • Relation is a set of tuples – Tuple ordering immaterial Id Name Address Status – No duplicates – Cardinality of relation = number of tuples 11111111 John 123 Main freshman • All tuples in a relation have the same structure; constructed from the same set of attributes 12345678 Mary 456 Cedar sophmore – Attributes are named (ordering is immaterial) – Value of an attribute is drawn from the attribute’s domain 44433322 Art 77 So. 3rd senior • There is also a special value null (value unknown or undefined), which belongs to no domain 87654321 Pat 88 No. 4th sophmore – Arity of relation = number of attributes Student 11 Student 12 2 Relation Schema Relational Database • Relation name • Finite set of relations • Attribute names & domains • Each relation consists of a schema and an • Integrity constraints like instance – The values of a particular attribute in all tuples • Database schema = set of relation schemas are unique constraints among relations (inter-relational – The values of a particular attribute in all tuples constraints) are greater than 0 • Database instance = set of (corresponding) • Default values relation instances 13 14 Database Schema (Example) Integrity Constraints • Student (Id: INT, Name: STRING, Address: STRING, • Part of schema Status: STRING) • Restriction on state (or of sequence of states) of • Professor (Id: INT, Name: STRING, DeptId: DEPTS) data base • Course (DeptId: DEPTS, CrsName: STRING, • Enforced by DBMS CrsCode: COURSES) • Intra-relational - involve only one relation • Transcript (CrsCode: COURSES, StudId: INT, – Part of relation schema – e.g., all Ids are unique Grade: GRADES, Semester: SEMESTERS) • Inter-relational - involve several relations • Department(Department DeptId: DEPTS, Name: STRING) – Part of relation schema or database schema 15 16 Constraint Checking Kinds of Integrity Constraints • Automatically checked by DBMS • Static – restricts legal states of database • Protects database from errors – Syntactic (structural) • Enforces enterprise rules • e.g., all values in a column must be unique – Semantic (involve meaning of attributes) • e.g., cannot register for more than 18 credits • Dynamic – limitation on sequences of database states • e.g., cannot raise salary by more than 5% 17 18 3 Key Constraint •A key constraint is a sequence of attributes Key Constraint (cont’d) A1,…,An (n=1 possible) of a relation schema, S, with the following property: • Superkey - set of attributes containing key – A relation instance s of S satisfies the key constraint iff at most one row in s can contain a particular set of –(Id, Name) is a superkey of Student values, a1,…,an, for the attributes A1,…,An • Every relation has a key – Minimality: no subset of A1,…,An is a key constraint • Key • Relation can have several keys: – Set of attributes mentioned in a key constraint – primary key: Id in Student (can’t be null) •e.g., Id in Student,Student – candidate key: (Name, Address) in Student • e.g., (StudId, CrsCode, Semester) in Transcript –It is minimal: no subset of a key is a key •(Id, Name) is not a key of Student 19 20 Foreign Key Constraint Foreign Key Constraint • Referential integrity: Item named in one relation must refer to tuples that describe that item in another (Example) – Transcript (CrsCode) references Course(Course CrsCode ) – Professor(Professor DeptId) references Department(Department DeptId) A2 • Attribute A1 is a foreign key of R1 referring to attribute A2 in R2,R2 A1 v3 v1 v5 if whenever there is a value v of A1, there is a tuple of R2 in which A has value v, and A is a key of R2 v2 v1 2 2 v3 v6 – This is a special case of referential integrity: A must be a candidate key 2 v4 v2 of R2 (e.g., CrsCode is a key of Course in the above) R2 Course -- v7 – If no row exists in R2 => violation of referential integrity v3 v4 – Not all rows of R2 need to be referenced: relationship is not symmetric R1 R2 (e.g., some course might not be taught) Foreign key – Value of a foreign key might not be specified (DeptId column of some Candidate key professor might be null) 21 22 Foreign Key (cont’d) Foreign Key (cont’d) • Foreign key might consist of several columns •Names of A1 and A2 need not be the same. –(CrsCode, Semester) of Transcript references – With tables: (CrsCode, Semester) of Teaching Teaching(Teaching CrsCode: COURSES, Sem: SEMESTERS, ProfId: INT) Professor(Professor Id: INT, Name: STRING, DeptId: DEPTS) • R1(R1 A1, …An) references R2(R2 B1, …Bn) ProfId attribute of Teaching references Id attribute of Professor – There exists a 1 - 1 correspondance between A1,…An • R1 and R2 need not be distinct. and B1,…Bn – Employee(Id:INT, MgrId:INT, ….) – Ai and Bi have same domains (although not • Employee(Employee MgrId) references Employee(Employee Id) necessarily the same names) – Every manager is also an employee and hence has a unique – B ,…,B is a candidate key of R2 row in Employee 1 n R2 23 24 4 Inclusion Dependency SQL • Referential integrity constraint that is not a foreign key constraint • Language for describing database schema • Teaching(Teaching CrsCode, Semester) references and operations on tables Transcript(Transcript CrsCode, Semester) • Data Definition Language (DDL): (no empty classes allowed) sublanguage of SQL for describing schema • Target attributes do not form a candidate key in Transcript (StudId missing) • No simple enforcement mechanism for inclusion dependencies in SQL (requires assertions -- later) 25 26 Table Declaration Tables CREATE TABLE Student ( Id: INTEGER, • SQL entity that corresponds to a relation Name: CHAR(20), Address: CHAR(50), • An element of the database schema Status: CHAR(10) • SQL-92 is currently the most supported ) standard but is now superseded by Id Name Address Status SQL:1999 101222333 John 10 Cedar St Freshman • Database vendors generally deviate from 234567890 Mary 22 Main St Sophomore standard, but eventually converge 27 Student 28 Primary/Candidate Keys Null CREATE TABLE Course ( • Problem: Not all information might be known when CrsCode:CHAR(6), row is inserted (e.g., Grade might be missing from CrsName: CHAR(20), Transcript)Transcript DeptId: CHAR(4), • A column might not be applicable for a particular Descr: CHAR(100), row (e.g., MaidenName if row describes a male) PRIMARY KEY (CrsCode),
Load more

Recommended publications
  • Referential Integrity in Sqlite
    CS 564: Database Management Systems University of Wisconsin - Madison, Fall 2017 Referential Integrity in SQLite Declaring Referential Integrity (Foreign Key) Constraints Foreign key constraints are used to check referential integrity between tables in a database. Consider, for example, the following two tables: create table Residence ( nameVARCHARPRIMARY KEY, capacityINT ); create table Student ( idINTPRIMARY KEY, firstNameVARCHAR, lastNameVARCHAR, residenceVARCHAR ); We can enforce the constraint that a Student’s residence actually exists by making Student.residence a foreign key that refers to Residence.name. SQLite lets you specify this relationship in several different ways: create table Residence ( nameVARCHARPRIMARY KEY, capacityINT ); create table Student ( idINTPRIMARY KEY, firstNameVARCHAR, lastNameVARCHAR, residenceVARCHAR, FOREIGNKEY(residence) REFERENCES Residence(name) ); or create table Residence ( nameVARCHARPRIMARY KEY, capacityINT ); create table Student ( idINTPRIMARY KEY, firstNameVARCHAR, lastNameVARCHAR, residenceVARCHAR REFERENCES Residence(name) ); or create table Residence ( nameVARCHARPRIMARY KEY, 1 capacityINT ); create table Student ( idINTPRIMARY KEY, firstNameVARCHAR, lastNameVARCHAR, residenceVARCHAR REFERENCES Residence-- Implicitly references the primary key of the Residence table. ); All three forms are valid syntax for specifying the same constraint. Constraint Enforcement There are a number of important things about how referential integrity and foreign keys are handled in SQLite: • The attribute(s) referenced by a foreign key constraint (i.e. Residence.name in the example above) must be declared UNIQUE or as the PRIMARY KEY within their table, but this requirement is checked at run-time, not when constraints are declared. For example, if Residence.name had not been declared as the PRIMARY KEY of its table (or as UNIQUE), the FOREIGN KEY declarations above would still be permitted, but inserting into the Student table would always yield an error.
    [Show full text]
  • Not ACID, Not BASE, but SALT a Transaction Processing Perspective on Blockchains
    Not ACID, not BASE, but SALT A Transaction Processing Perspective on Blockchains Stefan Tai, Jacob Eberhardt and Markus Klems Information Systems Engineering, Technische Universitat¨ Berlin fst, je, [email protected] Keywords: SALT, blockchain, decentralized, ACID, BASE, transaction processing Abstract: Traditional ACID transactions, typically supported by relational database management systems, emphasize database consistency. BASE provides a model that trades some consistency for availability, and is typically favored by cloud systems and NoSQL data stores. With the increasing popularity of blockchain technology, another alternative to both ACID and BASE is introduced: SALT. In this keynote paper, we present SALT as a model to explain blockchains and their use in application architecture. We take both, a transaction and a transaction processing systems perspective on the SALT model. From a transactions perspective, SALT is about Sequential, Agreed-on, Ledgered, and Tamper-resistant transaction processing. From a systems perspec- tive, SALT is about decentralized transaction processing systems being Symmetric, Admin-free, Ledgered and Time-consensual. We discuss the importance of these dual perspectives, both, when comparing SALT with ACID and BASE, and when engineering blockchain-based applications. We expect the next-generation of decentralized transactional applications to leverage combinations of all three transaction models. 1 INTRODUCTION against. Using the admittedly contrived acronym of SALT, we characterize blockchain-based transactions There is a common belief that blockchains have the – from a transactions perspective – as Sequential, potential to fundamentally disrupt entire industries. Agreed, Ledgered, and Tamper-resistant, and – from Whether we are talking about financial services, the a systems perspective – as Symmetric, Admin-free, sharing economy, the Internet of Things, or future en- Ledgered, and Time-consensual.
    [Show full text]
  • The Relational Data Model and Relational Database Constraints
    chapter 33 The Relational Data Model and Relational Database Constraints his chapter opens Part 2 of the book, which covers Trelational databases. The relational data model was first introduced by Ted Codd of IBM Research in 1970 in a classic paper (Codd 1970), and it attracted immediate attention due to its simplicity and mathematical foundation. The model uses the concept of a mathematical relation—which looks somewhat like a table of values—as its basic building block, and has its theoretical basis in set theory and first-order predicate logic. In this chapter we discuss the basic characteristics of the model and its constraints. The first commercial implementations of the relational model became available in the early 1980s, such as the SQL/DS system on the MVS operating system by IBM and the Oracle DBMS. Since then, the model has been implemented in a large num- ber of commercial systems. Current popular relational DBMSs (RDBMSs) include DB2 and Informix Dynamic Server (from IBM), Oracle and Rdb (from Oracle), Sybase DBMS (from Sybase) and SQLServer and Access (from Microsoft). In addi- tion, several open source systems, such as MySQL and PostgreSQL, are available. Because of the importance of the relational model, all of Part 2 is devoted to this model and some of the languages associated with it. In Chapters 4 and 5, we describe the SQL query language, which is the standard for commercial relational DBMSs. Chapter 6 covers the operations of the relational algebra and introduces the relational calculus—these are two formal languages associated with the relational model.
    [Show full text]
  • Clarion & ANSI SQL Standard Referential Integrity and Referential
    Clarion & ANSI SQL Standard Referential Integrity and Referential Actions November 12, 2018 Whitemarsh Information Systems Corporation 2008 Althea Lane Bowie, Maryland 20716 Tele: 301-249-1142 Email: [email protected] Web: www.wiscorp.com Referential Integrity and Referential Actions Fundamental Definition: Actions resulting from instruction to the database engine created in the dictionary (i.e., schema) associated with “Relationship” specifications. For SQL-engine DBMSs, these relationship-specifications and actions relate to value congruence between the value-set of a primary key’s column(s) and the value-set of a Foreign key’s column(s). When either a Update or Delete action occurs that violates the value congruence, a Referential Action occurs. The actions depend on whether the Referential Action is specified. In ANSI SQL Standards, the four referential integrity actions: No Action, Cascade, or Set Null or Set Default. In Clarion, the five referential integrity actions are: None, Restrict, Cascade, Clear, Cascade Server, ClearServer and Restrict Server. Copyright 2018, Whitemarsh Information Systems Corporation Proprietary Data, All Rights Reserved 2 Referential Integrity and Referential Actions Referential Integrity and Actions Referential Action taken when violation occurs On Update On Delete Referential Action Parent Child Parent Child Function ANSI Clarion Table Table Table Table Parent Table No equivalent None: Instructs the Primary No change Row is Nothing. Primary Key Application Generator not key in the deleted Effect is to Column value can to generate any code to column foreign key make the change. Foreign maintain referential value can value child table Key Column value integrity between any change row an does not change.
    [Show full text]
  • Relational Schema Database Design
    Relational Schema Database Design Venezuelan Danny catenates variedly. Fleeciest Giraldo cane ingeniously. Wolf is quadricentennial and administrate thereat while inflatable Murray succor and desert. So why the users are vital for relational schema design of data When and database relate to access time in each relation cannot delete all databases where employees. Parallel create index and concatenated indexes are also supported. It in database design databases are related is designed relation bc, and indeed necessary transformations in. The column represents the set of values for a specific attribute. They relate tables achieve hiding object schemas takes an optimal database design in those changes involve an optional structures solid and. If your database contains incorrect information, even with excessive entities, the field relating the two tables is the primary key of the table on the one side of the relationship. By schema design databases. The process of applying the rules to your database design is called normalizing the database, which can be conducted at the School or at the offices of the client as they prefer. To identify the specific customers who mediate the criteria, and the columns to ensure field. To embassy the columns in a table, exceed the cluster key values of a regular change, etc. What is Cloud Washing? What you design databases you cannot use relational database designing and. Database Design Washington. External tables access data in external sources as if it were in a table in the database. A relational schema for a compress is any outline of how soon is organized. The rattle this mapping is generally performed is such request each thought of related data which depends upon a background object, but little are associated with overlapping elements, there which only be solid level.
    [Show full text]
  • Relational Schema Relational Integrity
    Relational Schema Relational Integrity Unpassionate and purposeless Orlando never combine his incalculability! Infinitival Oswald signalize canonically or proceed trustingly when Piotr is leery. Orbadiah volatilizes her options bulgingly, she outwalks it amorally. Save my choice for tables can have no parent table, only on data are problems with multiple base tables may be a combination with the! Employee to radio mandatory role of Employee. DBMSs to check important data satisfies the semantics. Filing System, the dummy set add all Counties of all Countries. It does not seriously affect both tables related in relation schema designs the integrity constraints are. RFS, this sin that goes do dot use fresh unique ID to identify value object. Manual is separate horn the Product entity. Overlap constraints: Can Joe be an Hourly_Emps as through as a Contract_Emps entity? Web site which select a few attributes. Was this on helpful? It involves the relational tables that data are shown is an entity and implemented via objects are modified depending on file sharing services can! In relational schema may want to track of your session has gained wide range of moral character. There is our chance for duplication of data. An unknown error occurred. DBMSs but were originally slower. The second sentence to keep only two tables separated. Similarly, data manipulation, enabling them to shelter network traffic and unit run in disconnected mode. Eer object over any data item, delete all enrolled tuple. When there was not refundable and each table should not allowed through views reflects pdf solve mcq quiz yourself, relational integrity risk is called dno in.
    [Show full text]
  • Relational Database Fundamentals
    05_04652x ch01.qxp 7/10/06 1:45 PM Page 7 Chapter 1 Relational Database Fundamentals In This Chapter ᮣ Organizing information ᮣ Defining database ᮣ Defining DBMS ᮣ Comparing database models ᮣ Defining relational database ᮣ Considering the challenges of database design QL (pronounced ess-que-ell, not see’qwl) is an industry-standard language Sspecifically designed to enable people to create databases, add new data to databases, maintain the data, and retrieve selected parts of the data. Various kinds of databases exist, each adhering to a different conceptual model. SQL was originally developed to operate on data in databases that follow the relational model. Recently, the international SQL standard has incorporated part of the object model, resulting in hybrid structures called object-relational databases. In this chapter, I discuss data storage, devote a section to how the relational model compares with other major models, and provide a look at the important features of relational databases. Before I talk about SQL, however, I need to nail down what I mean by the term database. Its meaning has changed as computers have changed the way people record and maintain information. COPYRIGHTED MATERIAL Keeping Track of Things Today, people use computers to perform many tasks formerly done with other tools. Computers have replaced typewriters for creating and modifying documents. They’ve surpassed electromechanical calculators as the best way to do math. They’ve also replaced millions of pieces of paper, file folders, and file cabinets as the principal storage medium for important information. Compared to those old tools, of course, computers do much more, much faster — and with greater accuracy.
    [Show full text]
  • CSC 443 – Database Management Systems Data and Its Structure
    CSC 443 – Database Management Systems Lecture 3 –The Relational Data Model Data and Its Structure • Data is actually stored as bits, but it is difficult to work with data at this level. • It is convenient to view data at different levels of abstraction . • Schema : Description of data at some abstraction level. Each level has its own schema. • We will be concerned with three schemas: physical , conceptual , and external . 1 Physical Data Level • Physical schema describes details of how data is stored: tracks, cylinders, indices etc. • Early applications worked at this level – explicitly dealt with details. • Problem: Routines were hard-coded to deal with physical representation. – Changes to data structure difficult to make. – Application code becomes complex since it must deal with details. – Rapid implementation of new features impossible. Conceptual Data Level • Hides details. – In the relational model, the conceptual schema presents data as a set of tables. • DBMS maps from conceptual to physical schema automatically. • Physical schema can be changed without changing application: – DBMS would change mapping from conceptual to physical transparently – This property is referred to as physical data independence 2 Conceptual Data Level (con’t) External Data Level • In the relational model, the external schema also presents data as a set of relations. • An external schema specifies a view of the data in terms of the conceptual level. It is tailored to the needs of a particular category of users. – Portions of stored data should not be seen by some users. • Students should not see their files in full. • Faculty should not see billing data. – Information that can be derived from stored data might be viewed as if it were stored.
    [Show full text]
  • Accessing a Relational Database Through an Object-Oriented Database Interface (Extended Abstract)
    Accessing a Relational Database through an Object-Oriented Database Interface (extended abstract) J. A. Orenstein D. N. Kamber Object Design, Inc. Credit Suisse [email protected] [email protected] Object-oriented database systems (ODBs) are Typically, their goal is not to migrate data from designedfor use in applicationscharacterized by complex relational databases into object-oriented databases. data models, clean integration with the host ODBs and RDBs are likely to have different programming language, and a need for extremely fast performance characteristics for some time, and it is creation, traversal, and update of networks of objects. therefore unlikely that one kind of systemcan displace Theseapplications are typically written in C or C++, and the other. Instead,the goal is to provide accessto legacy the problem of how to store the networks of objects, and databasesthrough object-orientedinterfaces. update them atomically has been difficult in practice. For this reason, we designed and developed, in Relational databasesystems (RDBs) tend to be a poor fit conjunction,with the Santa Teresa Labs of IBM, the for these applications because they are designed for ObjectStoreGateway, a systemwhich providesaccess to applications with different performance requirements. relationaldatabasesthrough the ObjectStoreapplication ODBs are designedto meet theserequirements and have programming interface (API). ObjectStore queries, proven more successful in pioviding”persistence for collectionand cursor operationsare translatedinto SQL. applicationssuch as ECAD and MCAD.’ The tuple streamsresulting from execution of the SQL Interest in ODBs has-spread be$ond the CAD query are turned into objects;these objects may be either communities, to areas such as finance and transient, or persistent, stored in an ObjectStore telecommunications.
    [Show full text]
  • 8 the Relational Data Model
    CHAPTER 8 ✦ ✦ ✦ ✦ The Relational Data Model One of the most important applications for computers is storing and managing information. The manner in which information is organized can have a profound effect on how easy it is to access and manage. Perhaps the simplest but most versatile way to organize information is to store it in tables. The relational model is centered on this idea: the organization of data into collections of two-dimensional tables called “relations.” We can also think of the relational model as a generalization of the set data model that we discussed in Chapter 7, extending binary relations to relations of arbitrary arity. Originally, the relational data model was developed for databases — that is, Database information stored over a long period of time in a computer system — and for database management systems, the software that allows people to store, access, and modify this information. Databases still provide us with important motivation for understanding the relational data model. They are found today not only in their original, large-scale applications such as airline reservation systems or banking sys- tems, but in desktop computers handling individual activities such as maintaining expense records, homework grades, and many other uses. Other kinds of software besides database systems can make good use of tables of information as well, and the relational data model helps us design these tables and develop the data structures that we need to access them efficiently. For example, such tables are used by compilers to store information about the variables used in the program, keeping track of their data type and of the functions for which they are defined.
    [Show full text]
  • DBMS Keys Mahmoud El-Haj 13/01/2020 The
    DBMS Keys Mahmoud El-Haj 13/01/2020 The following is to help you understand the DBMS Keys mentioned in the 2nd lecture (2. Relational Model) Why do we need keys: • Keys are the essential elements of any relational database. • Keys are used to identify tuples in a relation R. • Keys are also used to establish the relationship among the tables in a schema. Type of keys discussed below: Superkey, Candidate Key, Primary Key (for Foreign Key please refer to the lecture slides (2. Relational Model). • Superkey (SK) of a relation R: o Is a set of attributes SK of R with the following condition: . No two tuples in any valid relation state r(R) will have the same value for SK • That is, for any distinct tuples t1 and t2 in r(R), t1[SK] ≠ t2[SK] o Every relation has at least one default superkey: the set of all its attributes o Basically superkey is nothing but a key. It is a super set of keys where all possible keys are included (see example below). o An attribute or a set of attributes that can be used to identify a tuple (row) of data in a Relation (table) is a Superkey. • Candidate Key of R (all superkeys that can be candidate keys): o A "minimal" superkey o That is, a (candidate) key is a superkey K such that removal of any attribute from K results in a set of attributes that IS NOT a superkey (does not possess the superkey uniqueness property) (see example below). o A Candidate Key is a Superkey but not necessarily vice versa o Candidate Key: Are keys which can be a primary key.
    [Show full text]
  • March 2017 Report
    BCS THE CHARTERED INSTITUTE FOR IT BCS HIGHER EDUCATION QUALIFICATIONS BCS Level 6 Professional Graduate Diploma in IT ADVANCED DATABASE MANAGEMENT SYSTEMS March 2017 Answer any THREE questions out of FIVE. All questions carry equal marks. Time: THREE hours Answer any Section A questions you attempt in Answer Book A Answer any Section B questions you attempt in Answer Book B The marks given in brackets are indicative of the weight given to each part of the question. Calculators are NOT allowed in this examination. Section A Answer Section A questions in Answer Book A A1 Examiner's General Comments This was a fairly popular question, attempted by around half of the candidates, with two-thirds of the attempts achieving pass level marks. Therefore, the performance was generally quite good with a wide range of marks, some candidates producing near correct solutions. The definition of a true distributed database system is that it consists of a collection of geographically remote sites of physical databases, connected together via some kind of communication network, in which a user at any site can access data anywhere in the network exactly as if the data were all stored in one single database at the user’s own site. a) Explain the problems associated with achieving a true distributed database in practice. 12 marks ANSWER POINTER Fragmentation of tables requires maintenance of unique keys across horizontal fragments and consistency of primary keys that are reflected in vertical fragments. Also increased network traffic occurs as many fragments may need to be consulted to perform one query.
    [Show full text]