DB Project Report Scorecard

1 Pages544 Words199 Views

Added on 2019-10-12

About This Document

This scorecard outlines the deliverables and criteria for grading a DB project report for Desklib online library. It includes report text, SQL queries, logical and physical models, and application planning. The scorecard provides guidance for grade estimation and covers various aspects such as project organization, scope, functional requirements, SQL coding standards, post mortem analysis, and more.

DB Project Report Scorecard

Added on 2019-10-12

Related Documents

DB Project Report Scorecard;Outline of deliverables/criteria (with guidance for grade estimation):1.Report text, (0-50)Include in a zipped folder with relevant source/ files representing design andimplementation information1.1 Narrative, including executive summary1.2Project organization [consistent and clear]- team member roles explicitly defined and assigned1.3Scope [precise, concept of operation type with features]1.4Functional Requirements with scenarios1.5Future opportunities/alternatives and [current] project plans 1.6Body of the report (see sections 2-6 below- each to be graded)1.7SQL Coding Standard (team guidelines- style manual)1.8Post Mortem – lessons learned incl. comparative analysis (Oracle/Java vs. SQL Server/C#(VB)1.9References; extra 1.10 Presentation .ppt completed 2Questions/SQL or T-SQL queries PERTINENT AND TESTED (0-50)2.1 Questions (minimum 10 queries): important, clear, non-trivial, and representative, comprehensive set covering DB scope [in case of individual students in a team, scope fits meaningful portion/business function/task] 2.2 T-SQL and SQL, PL/SQL queries written in consistent style, and tested for syntax, semantics and speed-EXPLAIN plan, optimized [statistical etc.] if relevant, reports formatted and printed in a professional format; sufficient test data prepared/generated for validity... 3. Logical Model(s) with related details (0-80)3.1 ER Diagram, professional presence [standard ID text block, visual conventions, sizes etc.]3.2 Attribute set rich, and names carefully chosen; 3.3. Standardized domains/independent attributes, with example sets of data values 3.4 Definitions, descriptions systematic, standardized ‘standardized’, based on use of a template checklists etc. 3.5 Referential integrity options, rationale specified within relationship definition/description 3.6 Extensive use of Erwin features and reports with primary key, alternate keys, secondary keys (IEs) etc. 3.7 Other including views, stored displays, subsystems-models, generalized templates [as app. domain and independent design patterns], business rules for program logic etc.4. Physical Model-Database with related details (0-80)4.1 Data types and sizes carefully selected using independent attributes [domains] and volumetric calculated4.2 Indexes and ‘file’ organization selected, encryption and compression evaluated4.3 Lists of values (LOV) selected [for example: logical only entities, for physical LOV implementation!]4.4 Transaction (isolation levels), Logical Access paths analysis, de-normalization suggested, plus physical schema modifications and related integrity triggers etc.4.5 specific design features, innovative solutions/capture of implied and unstated but desirable requirements including in particular security concerns including access rights, encryption etc.4.6. View Materialization if any, and other concerns, including an assessment of future architectural changes [potential] , robustness, scale ability, distribution etc.5. Application Planning (0-40)5.1 menus, reports, transactions/data entry – updates etc.5.2 environments [development, testing, production], security, DBA aspects, backups, etc.5.3 GUI design layouts etc.1

End of preview

Want to access all the pages? Upload your documents or become a member.