Part1- Intro- CaseStudyProject 1 f Relational Database Management LIS458 G Benoit Jan 6, 11 The subject of Relational Database Management Systems (RDBMS) is taught in schools of business, library & information science, mathematics, computer science, and in some of the hard sciences as part of organizing the scientists work. As a result, the topic is broader than most people conceive and the degree of detail taught varies. In mathematics and computer science departments, the course covers the fundamental (as we shall) but more emphasis is on the relational algebra and set theory that the SQL commands execute. This approach uses an exceptionally precise vocabulary, arcane for most. In management schools, the emphasis ranges from the more technical approach to more consideration of how to apply RDBMS to management issues, such as efficient record keeping and using data for decision support. In LIS, the content tends to emphasize the broad practice of RDBMS, the user, digital library and other records integration. Any class that claims to teach RDBMS must review the fundamentals, though they vary in depth and use of technical language. In the same way, text books about RDBMS vary. The overwhelming majority of published works teach the commands of SQL (structured query language, pronounced S. Q. L. as individual letters or as sequel and nothing else). Such knowledge is important but without knowing how to determine what the RDBMS should actually do it is rather pointless. We need a text that is not too management-focused nor is laden with mathematics because neither approaches serves the student of LIS. To find a single textbook that provides enough detail, enough scope, but isn t overwhelming technical, and that doesn t cost $100, is almost impossible. Therefore, we will draw from three sources: a book about SQL commands, other texts, these course notes and slides. Note that when an important technical issue arises, I will include it in the text and indicated as such. While notes are optional they re there to ensure both accurate coverage of the topic and to address other students interests. Keep in mind that students in this class come from a range of backgrounds and have a range of career interests and engagement with computers. To ensure that all levels of student learn from the lessons they re divided into the required (basic) level and the optional (intermediate) level. Many folk plan on, and actually do, create digital libraries, management tools, and so on, on their jobs and by the end of class, everyone will be able to participate in the design, creation, evaluation, and future of relational databases. Know your point of view: To take an otherwise complicated field and present it intelligently to all, the whole RDBMS field is divided into parts based on one s perspective. Everyone ought to be aware of the major functions of people who work with RDBMS design. The conceptual area is first. It consists of planning and analysis
Part1- Intro- CaseStudyProject 2 of the organization s information needs, work processes, mission, and documenting the whole at a level of abstraction that focuses on how work processes related. For example, consider an academic library s work functions. At a high level of abstraction, we might divide it into Administration, Technical Services, and Patron Services. At a lower level of analysis, we might divide Technical Services into { original cataloguing, copy cataloguing, systems, user-online services }. Patron Services could be divided into { Reference, Online Reference, Bibliographic Instruction, Class Support }. The Administration might be divided into { Financial, Payroll, Human Resources, Building Maintenance and other activities }. Where should Web Services be placed? Is Patron Services at all dependent upon the work performed by Technical Services? Does the online public access catalogue belong to Technical or Patron services? These kinds of questions, of how people work together, how data are captured, stored, manipulated, output as websites and reports, are all parts of any information system; the time to document an organization s answers to these questions (or requirements analysis) is in the Conceptual Phase of RDBMS, to create the business logic. Once the business practices are identified, we focus on what actions cause data to be collected, changed, delivered in an efficient way that a computer can store the data. Here we design a virtual database system - one created on paper showing the logical design of how data are related. For instance, the library may purchase books and other materials but then what? In the conceptual phase there are professional standards about access, such as at least author, title, and subject tracings to locate materials that we record as important to the design of a system. Next we want to implement this abstract idea of access into something a compute can handle, defining entities and relations, and ensuring ways that will enable us to identify every piece of data in a unique way (called data decomposition). We must consider how the logical system is used, too; the kinds of queries that might be posed to know what kinds of statements are possible. These statements are the actual commands issued to the database software. All RDBMS manufacturers support a similar set of commands for SQL so if you learn on one system you can apply the commands on a new one. These commands are abstracted into concepts, Data Manipulation Language (DML) and Data Creation Language (DCL), leaving the actual computing implementation to the various software programmers. For example, the command to create a new table in a database is part of the DCL; the commands for inserting and selecting data from a table are part of DML. The specific commands, e.g., SELECT * FROM mytable WHERE salary > 50000, are shared among manufacturers; the specific computational interpretation (how to make the commands efficient) are proprietary. Once we have decomposed our data to be efficient through a process called normalization, we can use software to express physically the logical design of our system that fulfills the conceptual needs of our organization. The physical level of RDBMS takes in the actual creation on the computer of the database, implementing it on our network, and maintaining the RDBMS. The people using the system play a role, too!, and do so at all phases. For example, when determining the organization s needs, we might engage in several activities: interviewing the staff, reading email and memos about what is not working well, analyzing the current system, and might
Part1- Intro- CaseStudyProject 3 engage user groups as part of Joint Application Design (JAD) sessions. During a JAD session, the endusers often draw screens and note what kind of data they input. They will also create reports and screen designs of data they want to see (or output). Sometimes the data are not shared between people but between one RDBMS and another. Collectively these activities have been termed the database development lifecycle. Here s one version of it: Planning Analysis Logical Design Physical Design Implementation Maintenance It s important to note that at each phase (conceptual, logical, physical) there are certain documents that are created. These documents answer a number of required questions about the data and their use. Each of these areas has its own vocabulary, thought processes, and work product. The documentation relies heavily on graphic representations both to work out logically the flaws in one s design and to be an explanatory tool, informing others about how your system should work. These diagrams include data flow diagrams, entity-relationship diagrams (ERD) or object-oriented design (OOD) expressions of data as objects or, finally, instead of ERD there may be Unified Modeling Language (UML) diagrams. The graphic work for each area may look similar but it is not: pay close attention to the details. RDBMS work also requires many reiterations and practice! A poorly designed system, whose concepts are not worked out properly and logically, can still be created (the physical area) but such a system will not perform efficiently and ultimately will break down as user needs go unmet. Demonstration Case Study Project Distance Educa:on Demo Project Example RDBMS design. In this course, we will use a single case study to bring us through the main points of all phases of Scenario: We work for a small academic department. That department s management is interested in creating a distance education package. ou ve been asked to document and to build such a system. There are about 300 students, faculty, and 30 classes. We d like to be able to create an efficient and
Part1- Intro- CaseStudyProject 4 effective system that supports work flows in the dept. Also, we d like to be able to link to existing library resources. We don t want to add more work to the faculty or make it difficult for students. So, we want to design a web-enabled information system that combines relational database software, flat files, and other resources. To accomplish this we have to examine the mission of the department, the needs of such a system, available resources, technology requirements and document the whole according to best practices. Whenever possible we want to maintain industry and professional standards. It d be great, too, if our efforts are not bound to a single computing platform, say be able to use our program to serve web sites, ipads, phones. We need to consider who enters data and when, who sees what data and when, who gets to run reports or submit queries and so on. Collectively these actions are expressed as work flow decomposition - that is we break down how a job in the organization is performed. We look at how the data move around in the system, how new data are calculated from other data, etc., all in response to how the job is done. In other words, someone s job triggers the need to capture or manipulate some data. In the parlance of database designers, this is part of defining transaction requirements. What kind of documents will we create? How will identify work processes? Here are two examples. The first applies the idea of actors - who does what in an organization to help identify the work processes (or original use case). The example demonstrates a course enrollment. The second example indicates the next phases (but without all the documentation), using a soccer club as an example. Example 1: Determining who does what (work process decomposition) with an eye to identifying triggers : Actors identified for the Grader System, with original use cases. Actor: Registrar 1. Define course offerings Enter information (dept, number, name and instructor) for each course offering to be held in the current term. 2. Manage course offering roster (initial/add/drop) Initially load the list of all students enrolled in each course offering; then add or drop students, one at a time, to a course offering with existing enrollment. 3. Obtain final grades Registrar requests final grades and the system is to send grade information for all course offerings not previously recorded. For each course offering with status = "final", provide the identity of the course offering (such as course number) followed by a stream of (student, final letter grade) for all students in the course offering, then indicate end-of-students for the course offering. Upon receiving the recorded signal from the registrar, set the status for the course offering to "recorded" and
Part1- Intro- CaseStudyProject 5 begin providing next course offering as above until all course offerings with a state of final have been recorded. Actor: Student 1. View course offering marks (raw scores/grade to date) For selected course offering, display leaf level work items or components, corresponding max scores and this student s raw scores (to date). Display also composite percentage achieved to date (per weightings of the grading policy). 2. View sorted marks for a work item For selected course offering, student selects a work item. (Note that this is for work items only, not for components, if this is a work item with multiple components, system calculates summary score for the work item.) Display all work item scores from the course offering in descending order, highlighting the student s individual score. 3. Assess team contributions Student selects which team-graded work item to assess; system displays members of student s team; student enters text describing teamwork and assessing each team member s contributions. Actor: Grader 1. Enter raw scores (with turn-in date) Grader selects a leaf level work item or component. System displays student names. Grader enters the raw scores and turn-in dates for students. If the turn-in date is missing, later than current date, or later than the too late date, reject the entire entry. If the work item is to be team scored, then the system displays the teams (as a list of students names for the team members, clearly indicating separation of the teams). Grader selects the appropriate team and enters the score for the team with the turn-in date. When the raw score for a team is entered, the system duplicates it as the raw score for each team member for that work item/component. 2. Set max points for work item Grader selects this function and is displayed a table with all work items and max points field for each work item or component (at the leaf level). Grader enters or replaces max points to be entered and OK's changes when done. Actor: Instructor 1. Manage teams For each team, instructor enters or selects the students who are members of that team. To revise teams, select one or more team members to remove from the team, and then enter new teams as above. 2. Manage work items and components Instructor may define work items, define components, set due dates, tag a work item as a team work item, and make any changes desired in existing work items or components. All changes will be reflected in the grading policy, max points, and raw score items to be displayed. 3. Instructor identifies grader for a course offering Instructor authorizes a person to perform grader functions for the selected course offering. Optionally, the system may warn instructor if the designated grader is a student in the course offering. (Note that registrar defines course offerings and identifies instructors, but does not participate in hiring of graders.) 4. Delegate certain functions to grader Instructor may delegate functions to grader. the grader may then perform these delegated functions as if in the role of the instructor actor. Indicate which functions are to be delegated and OK the set of entries. 5. Throw out a work item Instructor may indicate that a work item is thrown out. (This means that the students need not perform this work item and that it will not be assigned a positive weight in any grading policy.) Display will include list of work items or menu of work items. 6. Manage grading policy Instructor may define a grading policy, edit weightings in the grading policy. Display will include a list of work items, with weights that must sum to 100%. 7. Manage raw scores Instructor may edit raw scores (previously entered by grader), adjust a raw score (may
Part1- Intro- CaseStudyProject 6 not be changed by the grader), and enter raw scores. Interface will have matrix of students by work items with raw score values. 8. Manage final course offering grades (letter grades) Using the grading policy, system computes and displays sorted list of numeric final grades. Instructor sets break points for indicated letter grades, and system assigns final letter grade for each student accordingly. 9. Finalize course offering grades (sign off) Instructor selects course offerings to be marked as having final grades, thereby changing the status of the course offering to final. (This course offering will then be in the list of final course offerings the next time the registrar obtains final grades.) 10. Change a final grade (after recorded) Instructor may change a final letter grade for a student in a course offering that has been recorded. The system will change the status of the course offering (back) to final. Actor: All users (student, grader, or instructor) 1. Set user session and set course offering. Example 2: Creating documentation for a Soccer Club: OUTH SOCCER LEAGUE EXAMPLE DATA MODELING INFORMATION ou are to assume the role of a database analyst that has been assigned to develop an entity-relationship diagram (ERD) for a youth soccer league in a small Florida town, preparatory to designing a database for it in the future. The following information has been obtained for use in constructing the ERD: The soccer league consists of nearly two dozen teams, each of which has a unique team name (e.g., Flyers, Strikers, etc.). Each team has one or more sponsors whose names appear on the team uniforms. Each team consists of a number of players. No player belongs to more than one team. Each player is assigned a unique Player ID when they join the league. The league also records each player s name (first name and last name) and phone number. In order to verify that all players are at least 12 years of age and no more than 14 years of age, the league also records each player s date of birth. One player on each team is designated as that team s captain. Teams play one another in a series of scheduled matches. Each match is given a unique Match ID number and is scheduled for a specific date. Each match is between two teams. All teams play a season schedule consisting of twenty matches. The league records the score of each match. In addition, the league records, for each match, the number of minutes played by each player, as well as the number of goals scored by each player, and also the number of penalties assessed against each player. Due to injuries or other reasons, it is possible for a rostered player to not get to participate in any matches. A group of parent volunteers serve as referees for the matches. The league assigns three referees to each match, one head referee and two linesmen. For each match, the individuals serving in each position are recorded. All referees serve at several matches over the course of a season. All of the volunteer referees are assigned a unique Referee ID number when they first register with the league. In addition, the league records each referee s name (first name and last name) and phone number. In addition, each new referee is assigned to one experienced referee for training purposes. Not all of the experienced referees serve as trainers, but those that do often train more than one new referee.
Part1- Intro- CaseStudyProject 7 Matches take place at soccer fields located throughout town. Each field has a unique name. The league records the name and address (street, city, state, and zip) of all the fields where it stages matches. Each match, of course, occurs at a single field. The fields are typically used for multiple matches, but a couple of fields are currently undergoing renovations and no matches are scheduled for them. Document example: Entity-Relational Diagram (ERD) for soccer league: FIELD Field Name Address (Street, City, State, Zip) hosts Score Position TEAM MATCH REFEREE Team Name {Sponsor} plays Match ID Date is assigned Referee ID Name (First Name, Last Name) Phone is captained by consists of trains PLAER Player ID Name (First Name, Last Name) Phone DateOfBirth [Age] plays Minutes Goals Penalties ERD-soccer.ai
Part1- Intro- CaseStudyProject 8 Document example: Relational Schema for soccer league Field FieldName Street City State Zip Match Referee Assignment MatchID Date FieldName MatchID RefereeID Position Soccer Team Relational Schema Referee RefereeID FirstName LastName Phone TrainerID Player Performance MatchID PlayerID Minutes Goals Penalties Player PlayerID FirstName LastName Phone DateOfBirth TeamName Team TeamName Captain TeamSponsor TeamName Sponsor MatchOutcome MatchID TeamName Score RelationalSchema-soccer.ai
Part1- Intro- CaseStudyProject 9 Document example: Data Dictionary for soccer league NOTE: Some of the information in this Data Dictionary is NOT deducible from Soccer League narrative but is provided here for illustrative purposes. SOCCER LEAGUE DATA DICTIONAR Table: Field (Microsoft SQL Server Notation) FieldName Street City State Zip PK; Unique field name Field street Field city Field state Field zip char char 30 25 2 5 Iden1ty Unique Default MA Check LIKE [A- Z][A- Z] LIKE '[0-9][0-9] [0-9][0-9][0-9]' Allow Nulls Index Table: Match MatchID Date FieldName PK; Unique sequen:al match ID number Date match scheduled FK to Field table; loca:on of match smalldate: me Iden1ty Unique Default Check >= GETDATE() Allow Nulls Index Table: MatchOutcome MatchID TeamName Score CPK; FK to Match table CPK; FK to Team table Goals scored in match by team :nyint Iden1ty Unique Default Check >= 0 Allow Nulls Index Table: Player PlayerID FirstName LastName Phone DateOfBirth TeamName PK; Unique sequen:al player number Player first name Player last name Player phone number Player date of birth; player must be at least 12 years of age and no more than 14 years of age FK to Team table; team that player is on char smalldate: me 15 14 Iden1ty Unique Default Check LIKE '([0-9][0-9] [0-9]) [0-9][0-9] [0-9]- [0-9][0-9] [0-9][0-9]' > GETDATE() - (15*365.25) AND <= GETDATE() - (12*365.25) Allow Nulls Index Table: PlayerPerformance Iden1ty Unique Default Check Allow Nulls Index
Part1- Intro- CaseStudyProject 10 MatchID PlayerID Minutes Goals Penal:es CPK; FK to Match table CPK; FK to Player table Minutes played in match by player Goals scored in match by player Penal:es incurred in match by player :nyint :nyint :nyint >= 0 >= 0 >= 0 Table: Referee RefereeID FirstName LastName Phone TrainerID PK; Unique sequen:al referee number Referee first name Referee last name Referee phone number Recursive FK; synonym for RefereeID; referee s trainer char 15 14 Iden1ty Unique Default Check LIKE '([0-9][0-9] [0-9]) [0-9][0-9] [0-9]- [0-9][0-9] [0-9][0-9]' Allow Nulls Index Table: RefereeAssignment MatchID RefereeID Posi:on CPK; FK to Match table CPK; FK to Referee table Posi:on assigned to referee in match 12 Iden1ty Unique Default Linesman Check Head Referee OR Linesman Allow Nulls Index Table: Team TeamName Captain PK; Unique team name FK to Player table; synonym for PlayerID; captain of team Iden1ty Unique Default Check Allow Nulls Index Table: TeamSponsor TeamName Sponsor CPK; FK to Team table CPK; Team sponsor 30 Iden1ty Unique Default Check Allow Nulls Index Table: Vendor VendorName Phone PK; Unique vendor name Vendor phone number char 30 14 Iden1ty Unique Default Check LIKE '([0-9][0-9] [0-9]) [0-9][0-9] [0-9]- [0-9][0-9] [0-9][0-9]' Allow Nulls Index
Part1- Intro- CaseStudyProject 11 FieldName FK to Field table; field served by vendor Table: VendorType VendorName CPK; FK to Vendor table 30 Iden1ty Unique Default Check Allow Nulls Index Type CPK; Vendor type * *** * How much of the above documents can you understand if you read them carefully? Try to associate ideas from the narrative and see how they re interpreted conceptually and graphically in the other documentation. Distance Educa1on Demo Project Example In this class we will apply the ideas to a working, web-enabled information system, the heart of which is the relational database management system we create. For demonstration, it ll be a distance education project. The documents you create for this project are based on the example documents in these notes and in the class. The examples are not complete: they provide enough guidance for the student to complete his or her assignments. After posting the work, the professor s version will be posted. ou will create a live database on one of the Simmons GSLIS servers and interact with it! Advanced or very industrious students are free to elaborate on the basic design, provided, of course, they test and document their work accordingly. The documents listed below help identify the tables, fields, and data specifics you ll need What to do (documents you ll create): 1. Create a website for this course. ou will post all your work on that site according to the syllabus. 2. Mission statement. 3. Mission objectives. 4. Work Flow diagram. 5. Input designs - (sketch design on paper and scan) and final screen designs (as web forms). 6. Output designs - (sketch design on paper and scan) and final screen designs (as web forms). 7. Table list - initial drafts and then final version as part of the Data Dictionary. 8. Field lists - initial drafts and then final version as part of the Data Dictionary. 9. Relational Schema. 10. Entity Relation Diagram - practice (on paper or using software) and final versions.
Part1- Intro- CaseStudyProject 12 a. Optionally: create a UML version. 11. Data Dictionary. 12. Maintenance Plan. 13. Prepared SQL Statements. a. Hands-on practice issuing SQL commands using php-myadmin and the terminal window. b. The prepared statements will be stored in various text files on the server. { end of file; updated Jan 6, 10 }