Database Management Study Questions The following questions are to help you focus on the concepts that should

be mastered for the conceptual, in-class, part of the midterm. As you go through the questions, if you find a question that you cannot answer, first ask your classmates or group members. If you still cannot find a satisfactory answer, then ask in class since others are probably also confused. However, do not come to me for answers since I am unwilling to go over thirty or more questions thirty or more times to save you the trouble of studying. I will, however, be happy to answer clarification questions in the event that the point of a question is unclear to you. And I would be happy to answer any questions in class as long as it appears that you have made an effort. ! "hat is data# $ata is an important corporate resource, that it should be treated with respect, like other organi%ational resources. the $ata Administration depatment is responsible for effective management control of corporate of data "hat is a database# Is a fundamental component of the information system and its development and usage should be viewed from the perspective of wider requirement of the organi%ation. $atabase Administration department is responsible for effective management and control of corporate database "hat is a database management system# "hat is concept analysis and why is it relevant to designing databases# "hy is bounded rationality a problem in database design# "hy must databases be designed for a purpose# +enerally, what is that purpose# "hat is a data model# "hy is the selection of a data model important# "hat is the primary benefit of relational and dimensional models over storage and document models# "hat is the difference between a relational database and data warehouse# "hat is the correspondence view of databases# "hat is data independence# "hy is this a good thing# "hy could it not be achieved in file based systems# "hat is correspondence theory in relational databases# "hat do relations, relation instances, rows, attributes and foreign keys correspond to# "hat is a candidate key# "hat two properties must it have# "hat is the difference between a candidate key and a primary key#

&!

'! (! )! *! ,! -! .! /! ! &! '! (! )!

*! "hat is the difference between a primary key and a foreign key#

,! "hat is entity integrity# How is it enforced# -! "hat is referential integrity# $escribe the possible actions that a database can take when enforcing referential integrity and be able to e0plain what those actions mean in a specific application environment. .! "hat is semantic disintegrity# "hy is it a problem for relational databases# &/! "hy is 1null values2 an o0ymoron# & ! "hat are the two relational languages initially introduced by 3.4. 5odd# "hat is the basic difference between them# in ., 3. 4. 5odd introduced 6elational Algebra and 6elational 5alculus as basis for relational languages. 6elational algebra and relational calculus are two halves that constitute 3.4. 5odd7s 6elational 8odel. 9oth are abstract languages. 6elational algebra Is a procedural language Tells $98; how to build a new relation from one or more relations in a database 6elational algebra is used to e0plicitly define table manipulations ;tructured =uery >anguage ?;=>! is an e0ample of an evolution of relational algebra. 6elational calculus Is a non :rocedural language 6elational 5alculus query specifies "HAT is to be retrieved rather than H<" to retrieve it 6elational calculus is used to e0plicitly specify the desired results. 8icrosoft Access is an e0ample of an evolution of relational calculus.

&&! "hat is the closure property with respect to relational algebra# The relational algebra is a theoretical language with operations that work on one or more relations to define another relation without changing the original relation?s!. Thus both the operands and the results are relations, and so the output from one operation can become the input to another operation. This ability allows e0pressions to be nested in the relational algebra, @ust as we can nest arithmetic operations. This property is called closureA relations are closed under the algebra, @ust as numbers are closed under arithmetic operations. &'! "hat is the difference between and inner @oin and an outer @oin#- $raw Benn $iagrams Inner join - 5ombines data from & or more tables, and gives only common values as the result. It ignores all the values of both the tables that do not match with the values of each column. The ICC36 D<IC keyword returns rows when there is at least one match in both tables. If there are rows in ETable AE that do not have matches in ETable 9E, those rows will C<T be listed.. +ives the result A intersection 9

Outer Join - The <uter @oin retains rows that do not satisfy the @oin condition. It does not omit the unmatched rows, unlike the Inner Doin. It helps to to include the unmatched rows in the result table. +ives the result A union 9 there are ' kinds of <uter @oins - >eft, 6ight and 4uller Left Outer Join - Includes all the values of Table A ?left Table! and includes the corresponding values of table 9?right Table!. And for those values of Table A which do not have correspondingFcommon values in table 9. The >eft outer Doin function includes Cull in the Table 9 , in the cell corresponding to unmatched values in Table A Right Outer JOin - Includes all the values of Table 9 ?righ Table! and includes the corresponding values of table A?left Table!. And for those values of Table 9 which do not have correspondingFcommon values in table A. The right outer Doin function includes Cull in the Table A , in the cells corresponding to unmatched values in Table 9. Fuller Outer Joins - Includes all the values of Table A ?left Table! and those of table 9?right Table!. And for those values of Table A which do not have correspondingFcommon values in table 9, the function includes Cull in the Table 9 , and for those values of Table 9 which do not have correspondingFcommon values in table A, the function includes Cull in the Table A. Assuming you7re @oining on columns with no duplicates, which is by far the most common caseA E am!les ;uppose you have two Tables, with a single column each, and data as followsA A 9 ' & ( ' ) ( * Cote that ? ,&! are unique to A, ?',(! are common, and ?),*! are unique to 9. Inner join An inner @oin using either of the equivalent queries gives the intersection of the two tables, i.e. the two rows they have in common. ;3>35T G 46<8 a ICC36 D<IC b on a.a H b.bI aJb --K-'J' (J( Left outer join A left outer @oin will give all rows in A, plus any common rows in 9. ;3>35T G 46<8 a >34T <LT36 D<IC b on a.a H b.bI aJ b --K----J null & J null 'J ' (J ( Full outer join A full outer @oin will give you the union of A and 9, i.e. All the rows in A and all the rows in 9. If something in A doesn7t have a corresponding datum in 9, then the 9 portion is null, and vice versa. ;3>35T G 46<8 a 4L>> <LT36 D<IC b on a.a H b.bI a J b -----K----J null & J null 'J ' (J ( null J * null J )

&(! Mou should be able to perform simple relational algebra operations including union, intersect, product, difference, restrict, and pro@ect. <n the e0am, I will not intentionally give anything tricky. &)! Mou should be able to write ;=> queries of the type found in the ;=> homework " &*! How does the presence of nulls affect the computational results of an ;=> query# &,! How does the presence of nulls affect computations conceptually#

&-! "hat are the different kinds of nulls# How do they impact summary computations# #he different $inds of %&LL are ' The value can be missing for & reasons. These reasons are the & kinds of CL>>;. - Cot Applicable ?CFA! - "hen the questions askedF the data is not applicable to the attribute in question - $on7t know ?$FN! - "hen the value of an attribute e0ists but is not know at that time. 4or e0ample - I ask Dack and Dill, the average mileage of each of their cars# If Dack does not own a car, this question is not applicable to him and there will be no value against his name - CL>>. <n the other hand Dill owns a car but is not aware about her car7s mileage, then this is the case of $on7t Nnow ?$FN! and there will also be a missing value in front of here name - CL>> Im!act of different $inds of %&LLLs on (om!utations Balue K Balue H Balue Balue K CFaH CFa Balue K $FN H $FN Balue K $FNKCFA H CFA &.! "hat is the 6ailroad :arado0 and what are the implications for database design# The foundation of a good database design and implementation is that - all databases must be purpose driven or even better they should be designed to solve a problem. "e should constantly remind ourselves the purposeFproblem for which the $atabase has been created. The railroad parado0 is a good analogy to e0plain this concept. #he railroad !arado Imagine there are three townsA homeville, playville and workville.

Train tracks pass through all three towns. A train passes through homeville in the morning during rush hour, to take commuters to and from homeville to and from playville and workville. $uring hours outside of rush hour ? /am to 'pm say! the train passes through homeville without stopping, and goes straight on to playville and workville. The assumption being that there are no commuters in homeville that need to travel by train to playville and workville during the off-hours. The mayor of homeville wants to change all that. He wants the train to stop in homeville every hour of the day, claiming there is a demand for said train stops, and he addresses his concerns to the train company 53<. The train company 53< says he will look into the issue, and goes down to the homeville train station to see for himself what this EdemandE for homeville train commuters looks like. He gets to the homeville train station at .'/am and there is no one there, and he discerns that the demand therefore does not e0ist, and he re@ects the homeville mayors request for homeville train stops during off -hours. 8orale of the storyA 8any times in database design we perceive a demand for a function, but cannot prove the demand e0ists. "e need to be willing to create the demand, and believe in the function we are proposing enough to convince nay sayers that the demand will in fact be created. In reality, there is no demand for databasesO

Im!lications for Database Design +ood database development can be learned, but it cannot be taught.

It is >earned Through 30perience. It is primarily based on e0perience in implementing design and implementation techniques. "hat 5an 9e Taught Is Lsually Abandoned <nce Mou +et ;ome 30perience cookbook Approach for database design are comfortable but they rarely work in practice.

'/! 9riefly describe the three approaches to database development along with their advantages and disadvantages. ' Approaches in $atabase design are Top-down Approach - Information $riven Traditional ' >evel Approcah - $esign 9ased - 5onceptual, >ogical and :hysical 9ottom- up Approach - 3vent and Transaction driven )ottom'&! *!!roach - Is a 3vent and Transaction driven approach. It is the most a concrete, easiest to understand and the least likely to create a robust system $esign. The 9ottom-up Approach starts with business process transactions and information needs. The transactions are tracked through various business processes. The information needs are then derived from the tracked business processes. The 9ottom-up approach starts as a search and retrieval mechanism and progressedF evolved into an information delivery system. ;ince the focus is always on the business process transactions, most of the time it is not very clear what is the actual problem for which the system is being designed. Advantages It is the much concrete methodology ;ystem $esign information is gathered in the Analysis phase 3asiest to understand $isadvantages The database redesignFremodeling may be needed. The information 30ploitation may be short changed.

>ess likely to create a robust design #he #radition + le,elDesign *!!roach - It is drivenn by the system design. It is the easiest to teach, easiest to learn and also more likely to develop a good database design As the name suggest - the ' level $esign Approach, consist of ' level - 5onceptual >evel - 5onsist of Information 8odeling - >ogical >evel - 6esults in Cormali%ation of the database - :hysical >evel -consist of Inde0ing and :artition ' ! $escribe the three levels of information and how they relate to three levels of information systems and database technology. '&! "hat are the three stages in the traditional three level database design process and what is the ma@or output of each stage# #he #radition + le,elDesign *!!roach - It is drivenn by the system design. It is the easiest to teach, easiest to learn and also more likely to develop a good database design As the name suggest - the ' level $esign Approach, consist of ' level - (once!tual Le,el -Information Modeling. - The 5onceptual database design is a process of constructing a model of data for an enterprise, independent of all physical considerations. It is the first phase in the ' level design and the information modeled forms the source for the ne0t level, i.e. logical level. The data model is developed using the data documented in the user7s requirement specification. The conceptual level is independent of implementation details such as programming language, application programs, hardware platform, $98; software or any physical considerations. Throughout this stage the data model is tested and validated against the user7s requirements - Logical Le,el - %ormali/ation.- The >ogical $atabase $esign is a process of constructing a model of data for an enterprise, based on a specific data model, but independent of the physical considerations. The data model created in the first phase, is refined and mapped to the logical data model. The logical data model is based on the target data model of a $98;. Throughout the process of >ogical $atabase $esign the process is validated against the user7s requirement document and checked for correctness. This process of validation is called Cormali%ation. Cormali%ation helps to ensure that there are no data redundancies and also to ensure that the system supports all the transactions specified by the user. The >ogical data model forms a source for the ne0t level that is physical level by providing the data design developer with an outline to work with. It also serves an important role during the operational maintenance stage of the database system development lifecycle. - 0hysical Le,el -consist of Inde0ing and :artition ''! $atabases are made up of things and events# "hat are these# How are they different# How are they the same# $atabases are made up to things and events Things are ;tatic and in Aggregate describe the Lniverse in $iscourse 3vents are $ynamic and in aggregate describe the changes to the Lniverse in $iscourse '(! "hat kinds of problems are best suited for a database to solve# database can be used to solve problems and e0ploit opportuities ;ome of the problems taht can be answered using datbase are - Target Audiences - "ho are will use the data, $emographics of the people who will use teh data, 4or what purpose will they use this data. - <b@ectives of teh soultion - Helps to identify and resolve the problem. helps to identify the information needs. - ;cope - 9oundaries on the problem domain to control encroaching scope. ')! How do you validate a database design# <nce we have designed all the tables, we should validate the database design against the user requirement document, to make sure that the system meets all the requirement specified by the user. The database design can be validated by performing the operations manually. If we can resolve the transactions this way, then we have checked that all the user erequirements ahve been met. If we are not able to perform manual operation fro any of teh transaction, then it means that there is a problem with the data model which must be resolved. It can be taht we have omitted an entity, relationsip ot an attribute from the data model. '*! "hat are the three myths in database design# How do you overcome these problems# The ' myths of database design are - Fle ibility Myth - ;tates that it is not important to have all the database and design requirements upfront. The selection and the definition of the entity classes is largely based on the Information ob@ectives. The information <b@ectives in turn are based on the problem the we want to solve using the database. If we do not have all the requirements upfront, our ob@ective will not be clear and we will not be able to create a robust system. more over if we are not clear about the problem, we will not be able to know if we have solved it or not. Solution - 4ocus on the ob@ective of the database right from the startI understand the problem statement, and how the solution you are proposing meets this requirement head on.

' Semantics Myth - This 8yth states that if the semantics of the database design is unclear, then there is someone in the organi%ation, who can clarify the semantics. $9 developer is forced to either define the meaning of things on hisFher own, or gets bogged down in semantic refinement by consensus. Solution - ;olve by clearly defining the ob@ectives of the solution and this will determining meanings of things clearly. ' 0rocess -;tates that the process of designing the database is largely technical $ue tothe rigor of developong the entity-relationship model at the conceptual level and Cormali%ation at the logical level, the process of desigining database has been considered very technical. 9ut the fact is that this process is not technical but intellectual because it involves the evolution of shared meanings of things, within a social conte0t. Soultion - 4ocus with your client on the intellectual challenges, not the technical ones.